PLM

PLM（Product Lifecycle Management，产品生命周期管理），对应业务系统统称为PLM系统，主要包括产品数据管理、研发业务管理，比如研发项目管理等。

在开始讲PLM（Product Lifecycle Management，产品生命周期管理）之前，我们需要先引入另一个概念-IPD（Integrated Product Development，集成产品开发）。

在研发型企业中，IPD不是一个陌生的概念，国人了解这个概念大部分是通过华为的业务管理变革开始的。而最早通过IPD取得成功的是科技界的蓝色巨人IBM，它通过实施IPD项目成功走出了困境并获得了巨大成功。1998年，华为邀请IBM对业务管理变革提供咨询服务，IPD就是当时针对研发业务领域变革的指导思想。

时至今日，华为也在向中国的科技企业提供IPD管理咨询服务，希望把IPD的成功经验给更多的研发企业。针对IPD的详细内容，可以参考下图以及之前发表的IPD相关文章。

PLM系统与IPD的关系

那IPD和我们今天要讲的PLM是什么关系呢？简单理解，PLM系统是IT系统，是IT工具，是IPD思想落地的载体。但是IPD和PLM其实并没有强绑定关系，并不是企业引入了一套PLM系统，就会了IPD。

企业如果能够很好的使用IPD的思想来管理产品和研发体系，没有PLM系统也是可以的。而PLM作为一个系统工具，可以在IPD落地的过程中，对运作规范，数据可靠、协同效率等方面起到较好的帮助，这点希望大家能够认识清楚。

PDM系统与PLM系统的关系

普遍认为，PLM系统的前身是产品数据管理系统（PDM）。企业在产品研发过程中产生的各种图纸、软件、物料、技术文档等，统称为产品数据。

在没有数据管理系统之前，这些产品数据散落在各研发人员电脑或服务器上，需要使用或交付给下游生产或客户的时候，难以快速获取准确资料，不能确保所有资料的配套关系。企业也无法通过持续的研发知识积累，提升研发水平和效率。

PDM系统的出现，帮助企业解决了研发数据管理的问题；并且随着研发管理模式和理念的进步，研发数据管理逐渐扩展到了产品研发的整个生命周期的范围，形成了今天大家所认知的PLM系统。

PLM与上下游系统的关系

一个套完整的PLM系统应该涵盖从产品概念、研发、制造、配置、维护、服务到报废的整个生命周期，将上述这些阶段中的研发数据结构化，驱动这些阶段的研发活动的开展。下图能够概要显示PLM系统在产品全生命周期的关系，PLM与上下游系统的关系

其中CRM系统主要管理的是销售端的业务（将在下一章节介绍），主要包括销售机会、订单和销售工作的过程管理。其中和PLM的关联主要体现在产品概念阶段，CRM中的销售机会可以转化成产品研发的需求。

SCM是供应链管理系统，或者ISC集成供应链管理系统，重点业务是用来做供应商的引入、评估、协同等工作，在产品设计和研发阶段，需要考虑产品使用到的零部件的供应链情况，委外加工成本等。

ERP是企业资源计划系统，相对来说大家比较熟悉，主要管理的业务是生产计划、订单执行、库存、出货、收付款等业务。其中生产计划和生产需要使用到PLM中的产品BOM和工艺。

所以PLM系统在企业的IT应用架构中，有着非常重要的地位。

常见的PLM系统厂商

目前市场上可选的商用PLM产品较多，但产品能力各有偏向，没有一款产品能覆盖所有公司的业务，所以企业在选型PLM系统时，需要明确企业的重点诉求，以求所选产品能够适配重点业务，非核心业务，可以通过实施定制来满足。

根据我们自己的选型经验和对这个行业的了解，大概介绍下市场上PLM产品情况，供大家参考，不作为选型依据。

从产品的成熟度来讲，还是要看海外供应商的产品，其中西门子的Teamcenter、PTC的winchill和达索的ENOVIA牢牢占据了top3的位置。

但这些产品的技术栈复杂，导入难度大，市面上有能力实施teamcenter、winchill和达索的ENOVIA的乙方公司和顾问资源不多。

PLM系统常见功能

        1、产品管理

        2、Part管理

        3、BOM管理

        4、图文档管理

        5、变更管理

        6、工作流管理

其中，项目管理更多的是对产品研发过程的管控，将市场需求和产品需求，按照产品规划的节奏，通过项目的方式进行跟踪。项目过程中产生的设计图、零部件、产品配套资料等数据，一旦产品达到量产成熟度，就需要作为产品的基线数据，进行版本管控。这些产品数据就可以支撑生产，外发给供应商或终端客户。在量产之后的任何产品的缺陷修复、功能升级，都需要通过系统进行变更管控。

产品管理

当企业产品逐渐丰富，依靠个人来或某个团队，线下维护企业的产品目录及相关配套信息，会变得越来越困难，出错概率变大，效率变低。如何规范产品规划、产品创建和产品数据使用，都将会是企业面临的问题。

基于PLM对产品进行规范管理，可以很好的解决这个问题。为了实现对企业产品的高效管理，我们可以搭建产品基本信息(Product Basic Information-PBI）模块，其中包含了产品的分类结构和产品对应的管理团队的分层分级。

简单讲，我们需要在PLM系统中建立两棵树-产品分类树、产品团队树，在研发过程中产生的部件、图纸、文档、流程都将和这两棵树进行关联，从而实现产品数据的端到端追溯。

1、产品分类

产品分类是为了解决企业产品庞杂、管理无序的现状，参考行业产品分类标准并结合企业实际情况，搭建起来的结构清晰，分类明确的产品结构树。为了让大家对产品结构树有具体的印象，我们可以类比电商网站上的商品导航

        企业有了这样的产品结构树后，销售人员想知道公司有没有匹配客户需求的产品，不用到处找研发或其他团队收集信息，直接在PLM系统的产品分类管理中就可以查询产品信息，了解产品特性及资料。采购同事可以在产品结构树中快速获取产品引用的外购件信息，找到可选供应商及联系方式。生产同事对生产工艺有疑问，可以直接上PLM找到产品的工艺资料。研发同事可以基于产品结构树快速找到之前类似产品的研发资料，重用组件以提升开发效率。

您可能会说，要搭建这样的产品结构树，只要有个Office文档或思维导图等类似的工具就可以了，企业内部的员工想要了解公司的产品情况，直接找到维护产品结构的同事申请阅读即可，没有必要在PLM系统搭建这么一棵树。如果我们深入到实际业务的场景中就会发现，我们要的东西远不是一份文档能解决的。其中涉及到产品数据权限的管理，如何根据团队的变化、产品密级的变化，实现动态赋权。如何打通产品规划到立项，研发到量产，生产到销售的业务协同过程，要满足这些业务场景，需要一个灵活的系统功能来组织串联，而产品分类结构树就是这个角色。                       

如何搭建产品结构树

如何为企业搭建一棵产品结构树，对于不同的行业会有不同的**实践；但有些通用的原则，是可以供大家借鉴的。

首先，产品分类一定要结合企业业务的实际情况。综合考虑企业各领域的认知、内部环境和外部影响等因素，不要照搬所谓的成功标杆企业。

目前市面上很多的乙方实施公司，是不具备咨询服务能力的，拿着一套大企业的成功方案，照猫画虎的帮甲方落地，但往往是橘生淮南则为橘，生于淮北则为枳的尴尬结果。甲方企业有没有对应的执行力，领导层有没有足够的支持力度等都会影响方案的落地结果。

其次，产品分类要具备可扩展性。产品数量和领域会随着企业发展而发生变化，在产品分类方案中要充分考虑企业将来的产品品类、层级的扩展。

我们常见的产品分类为如下的4层结构：产品线→产品族→产品系列→产品。

以该产品分类结构为例，产品线是企业一个领域中的不同产品集合；产品族是满足不同客户个性化需求的一组相关产品；产品系列是基于同一架构的系列品；产品是满足外部客户需求都完成交付，包含硬件、软件和配套的产品资料及服务。

产品分类结构既要体现企业当下产品基本情况，也得考虑发展后的可扩展能力。

产品分类数据模型

为了确保产品划分清晰，布局合理，企业应该综合市场和企业内部各领域情况，建立一套规范的管理流程数据标准，确定如何进行产品规划，并将流程电子化落地到PLM系统中，与产品结构管理关联，实现业务流程与产品数据的无缝衔接。

其中产品线、产品族和产品系列是对产品的不同层级的分类，本质上是一样的数据，在落地方案上可以采用同样的数据模型；

而产品是企业具体交付给终端客户端内容，向上衔接产品分类，向下关联Part、BOM、图文档和变更等产品数据，需要有单独的数据模型。

确定数据模型后，企业还需要考虑数据如何进入系统，什么时候进入系统，谁来产生这些数据等一系列问题。

推荐的方案是，可以结合企业的实际运作情况，建立产品分类创建流程、产品分类维护流程、产品创建流程、产品维护流程、产品生命周期变更流程，通过流程来定义谁可以产生、修改数据，谁来审批并确认数据的合理性，审批通过的数据，由系统直接写入到数据模型。

通常情况下，产品分类结构数据由企业的产品管理团队来规划和产生，经过领导审批，由专门的产品数据管理工程师确认数据的准确性。产品数据一旦在系统中生成，将作为企业产品数据的**源头，在后续的研发、制造、销售、服务等业务环境中被调用，确保产品基础语言全流程保持一致。

产品管理团队

在IPD的管理体系中，需要打通企业的行政组织架构，形成跨部门的矩阵式产品管理团队，每个团队都有明确的使命，角色和职责，它们通过灵活、有效的沟通，确保相关的所有部门都参与进来，相互协作，并在产品开发的各个阶段提供功能部门的贡献和输入，我们把这样的团队称为重量级团队。

重量级团队按照具体的分工，分成了很多具体的角色，企业可以参考IPD的标准来定义这些角色，规定每个角色的职责及管理方法；但我们更建议根据自身的实际情况来组建自己的重量级团队，在行业案例中出现最多的团队有IPMT、SPDT和PDT，以下是普遍的认可的团队职责的说明。

IPMT

IPMT（Integrated Product   Management Team，集成产品管理团队）代表了公司的决策层，是一个高层管理者组成的跨部门团队，代表公司制定产品发展规划、对产品开发项目进行投资决策、培育市场管理和产品开发流程，并挑选合适的人选来保证整个过程的有效落实。

SPDT

SPDT（Solution Program Development Team，产品解决方案开发团队）是一个跨功能部门的解决方案开发组织，负责对解决方案开发的整个开发的过程管理，从立项，到解决方案开发，到将解决方案推向市场。负责管理解决方案的上市。其主要目标是根据IPMT项目任务和要求，保证解决方案能按时保质开发出来，保证在财务和市场上取得成功。

PDT

PDT（Product Development Team，产品开发团队）是产品开发的具体实施团队，也是一个由各职能部门代表组成的跨部门团队，在项目开始时成立、产品上市或项目取消时解散。产品开发团队对客户需求进行汇总和分析、并通过分解反映在具体的设计当中。产品开发团队对产品的市场成功和财务成功负责。

在系统创建产品团队

各重量级团队中会定义具体的角色，如PDT团队中，需要负责产品开发的开发代表，负责生产评估的制造代表，负责成本控制的财经代表，硬件工程师，软件工程师等。

企业需要定义这些团队、角色及成员的维护规则，并形成标准化的流程，确保重量级团队能够及时并准确的进入到系统中，参与各项业务活动。

例如，在产品分类数据管理规则中，企业可以确定哪个层级的产品分类需要哪个层级的重量级团队审核，在产品结构分类相关流程中固化各团队角色的职责，通过业务流程驱动各角色参与到产品分类结构管理的工作中。以下是供参考的重量级团队维护的业务规则：

为了方便用户的使用，在PLM系统要能将产品分类结构和重量级团队以灵活的方式展示出来，我们建议通过树形结构展示，并提供搜索能力，让用户能够索引到具体产品，并获取产品关联的数据资料。

产品数据是企业的核心资产，在系统方案层面需要充分考虑数据安全的管控。例如，产品分类树可以全员开放，所有人都可以查询到产品，但只有在这个产品团队中的成员才能查阅该产品关联的Part、BOM和图文档资料，其他人需要查阅要在系统上申请。另一种更为灵活的方法是，根据产品的生命周期进行相关数据的开放范围的控制，产品生命周期为计划阶段，完全不开放；产品进入开发阶段，对PDT开放；产品量产后，对销售和市场人员开放。最终要采用哪种控制方式，取决于系统的灵活性和企业的安全要求。

产品团队数据包含团队、角色，及其成员，除了可以应用到为团队及成员设置产品权限，还需要用于为系统流程定位到角色、人员。

思普   思普PLM