PLM已经是一个广为接受的概念。从字面意思可以看出，PLM系统的核心任务是进行“产品生命周期管理”。在PLM系统中，零部件也有生命周期，反映零部件的阶段和状态。而企业实施PLM系统过程中的一个主要任务，就是定义零部件的生命周期构成及演进规则。
二、过短的零部件生命周期
PLM系统对于零部件的“生命周期”管理应用，很容易被实施得过于简单，其“生命周期”过程往往是指零部件的“设计周期”管理过程，零部件的发放实际指的是“设计完成”，而非投入生产。
图1 过短的生命周期过程管理
如上图是某公司PLM系统中定义的零部件生命周期过程管理图。当零部件创建出来时即处于“拟制”状态，这时研发工程师对零部件进行各方面的详细设计。设计完成之后，研发工程师将启动一个审批流程，提交流程后，审批流程进入到“审核”环节，零部件的生命周期状态处于“流程中”；如果审核人员发现设计有误，则驳回给研发工程师，研发工程师根据审核意见进行修改，然后再提交，如此往复。
如果审核通过，则将进入到“批准”环节，“批准”环节的签审过程与“审核”一样，只是签审人员不同。如果批准通过，则将进入放到“发放”环节，此时，零部件的生命周期提升到“归档”，零部件被冻结；批准后的“发放”环节主要是将零部件图纸及技术资料发放给生产制造部门，过程提交通过之后，审批流程完成。
上述整个过程都发生在研发部门内部，工艺和制造部门则不参与。当零部件被发布后，工艺和制造部门才在此基础上展开工作。如果工艺或制造部门在后面发现了问题，他们会通知研发部门，于是研发工程师将零部件修订一个新版本（申请变更或申请取消归档），然后根据下游或现场反馈的情况在新版本上进行修改，修改完成后再次进行上述的审批流程，然后发放一个新版本，完成变更。
按照这个模式，零部件的一个生命周期实际上指的是零部件在研发部门的一段生命期，如果零部件通过了研发部门的审核，即代表生命周期走到了终点。当下游部门提出零部件有缺陷时，零部件需要“重生”一次（修订一个新版本），然后经历一个新的生命周期。我们来看一下一个零部件的一般开发过程。一个零部件从概念阶段到批量生产，一般要经历如下阶段：
图2 零部件设计开发基本过程
可以看出，零部件设计阶段只占全部生命周期的一半，后面还有大量的验证工作需要进行。而研究表明，产品80%的修改是在制造阶段以后完成的。从这个角度看，设计阶段的完成实际连整个生命期的一半都不到。这个时候宣布零部件“发布”实际上不合适，就如同一个大学生刚完成本科学业就宣布他已经成才一样。
这种情况的发生并非偶然。现在很多制造企业的组织结构仍然是行政式的，研发部门负责产品研发，制造部门负责试制生产；工作流程也一般是串行的，研发部门将设计签审后的图纸交到下游部门试制生产，出现问题再向上游反馈，而在零部件设计阶段他们参与得很少。
而PLM系统的实施则往往从研发部门开始，然后再延伸到制造部门，有的甚至只局限在研发部门内部。这样在系统部署之初，对零部件的生命周期的定义就只定义到设计阶段，而一般不会从整个过程的角度去定义。同时，一些企业“甩过墙”式的设计习惯也加强了这种情况。所谓“甩过墙”的设计是指“我这个部门完成我的工作后就把结果甩给隔壁的部门，然后没我的事情了”。
三、零部件生命周期过短的影响
无论这种情况是如何产生的，带来的影响却是相同的——零部件实际上没有完整的生命周期。零部件在设计阶段被“归档”后，下游部门提交的变更只能在新版本上进行，这就扭曲了版本本身的作用。
在PLM系统中，版本信息一般由版本和版次构成。版次标记一次修改，版本标记一次发放。这里的发放是指零部件已经“归档”，即：完成设计验证并投入生产。从标记修改的角度看，版本可理解为：版次标记投入生产之前的修改，版本标记投入生产之后的修改。由于生产前的验证和准备投入了大量的时间和成本，因此对零部件在生产之前和生产之后的变更处理是不同的。
在零部件投入生产之前，模具尚未开模，采购订单尚未下发，大量成本尚未发生。这时零部件处于设计或验证阶段，目标之一就是尽可能地发现和消除零部件的缺陷，使零部件具备高质量，因此这时发生的修改应该是即时生效的。
而零部件一旦投入生产，则大量成本已经发生，对修改的处理变得谨慎。并且投入生产的零部件一般是经过验证的，这时发现的问题往往是改进性质的，因此修改一般不会即时生效，而是有可能等到下一款产品才实现，或等现有供货耗完后才使用新设计。当然，也不排除一些致命缺陷需要及时修复，而这在投入生产后一般要少得多。因此，二者处理的主要问题一个是纠错型，一个是改进型。直接的不同就是修改是否要即时生效。
在一般的PLM系统中，零部件在未归档之前的修改只增加版次，并且新的版次会即时生效，即部件会马上自动引用新版次，而版本的增加一般不会即时生效。一般是当部件未归档时，新版本的零件归档后部件会自动引用新版本零件。当然，如果部件也已归档时，则新版本的零件归档后部件不会自动引用新版本零件，如果要引用，则需要将部件修订一个版本，然后再一起归档。这与产品投放生产后的改进是一致的。不过，当零部件的生命周期仅代表其设计周期时，就打破了上面的规则。
试想，当某一部件设计完成，研发部门将其一起“归档”。而后下游部门发现部件或零件存在问题，并提交给研发部门修改。这时研发工程师需要将部件修订一个新版本然后进行修改，这意味着之前“发放”的版本实际并未进行生产，这就扭曲了“发放”的本意。
不仅如此，若需要修改的是部件下的零件（实际上大部分情况都是修改零件），那么新版本的零件发放后该部件不会自动引用新版本，这样就必须修订该部件。如果部件有父级，则需要依次往上修订，这样一次修改就会产生大量的修订，势必使变更效率变慢。如果不想层层往上修订，则必须把系统开发成“即使父项处于发放状态，子项修订新版本后，父项也会自动引用新版本子项”。这样做产生的问题是：部件永远处在新状态下，这样失去了对历史状态的追溯功能。
因此，无论从那个角度考虑，一旦零部件走出了设计阶段，这个生命周期过程图就无法再准确描述其生命周期阶段和状态。
四、零部件生命周期管理的一般性建议
上述问题的产生，是由于零部件的生命周期图只描述到设计阶段完成，而零部件后面的演进则超出了这个阶段，即：用较短的生命周期图描述较长的生命期。要解决这个问题，需要将产品的生命周期管理延伸到设计验证和制造阶段。产品设计阶段的完成只能定义为“设计冻结”，而不能定为“发放”。真正的“发放”定义在产品验证完成后，批量生产之前。如下图：
图3 零部件长生命周期过程管理
上图中，在“设计冻结”之前，零部件处于设计阶段，研发工程师可以对零部件进行修改，所有的修改完成后，便可提交审核，并进入“设计冻结”环节。零部件审批流程进入到“设计冻结”环节，在此该阶段，研发工程师无权再进行修改。
“设计冻结”环节表示零部件设计阶段的完成，但尚未“归档”。当下游部门发现问题时，便提交给研发部门。研发工程师接到修改意见后，可将回退流程到“创建”环节进行修改，修改完成后零部件增加一个版次，其父级也自动引用新版次子项。提交审批流程经签审人员批准通过后，零部件审批流程再次进入到“设计冻结”环节。所有对反馈问题的处理都遵循这个模式。当验证阶段反馈的所有问题都被妥善处理并经过项目组评审通过后，产品数据（包含零部件及关联图纸）便可以提交“归档”。
一旦产品数据进入“归档”阶段，系统便将其冻结，作为历史查询记录。用户若要修改，则需要将提交变更审批流程，将其修订新的版本，然后在新的版本上进行修改操作。
对于一些特殊情况，即在生产阶段发现的一些严重缺陷因而不得不进行的修改。这时需要提出变更申请（ECR）审批流程，经由相关部门会签通过后方可进行修改与下发（ECN）。这种情况必须严格控制，因为生产之后的修改必然伴随这高昂的成本。
表面上看，图3相比与图1中的生命周期管理过程只增加了两个生命周期阶段，但实际上却有很大的不同。在图1的生命周期中，设计完成即表示产品“归档”，产品验证和批量生产前的阶段被排除在零部件生命周期之外；而这个长生命周期过程图则将产品设计完成后批量生产前的阶段也囊括到产品生命周期内，产品只有等全部数据验证通过后才能够“归档”并“发布”。
现在，咨询机构和厂商更愿意把PLM管理的生命周期延伸到销售、生产和售后阶段，从这个角度看，要实现零部件的全生命周期管理依然任重道远！这里面不仅仅只是增加若干个生命周期阶段的问题，而是这些阶段之间是如何演进及需要遵循哪些基本规则。
来源：网络 侵权删