零部件的生命周期，如何来管理？

PLM已经是一个广为接受的概念。从字面意思可以看出，PLM系统最核心的任务是进行“产品生命周期的管理”。在PLM系统中，零部件也有生命周期，反映零部件的阶段和状态。而企业实施PLM系统过程中的一个主要任务，就是定义零部件的生命周期构成及演进规则。 

过短的零部件生命周期管理

我曾参与过一些公司PLM系统实施，发现方案中零部件所谓的“生命周期”往往是指零部件的“设计周期”；零部件的发放实际指的是“设计完成”，而非投入生产。

图1 过短的生命周期图

如上图是某公司PLM系统中定义的零部件生命周期图。当零件创建出来时即处于“创建”阶段，这时工程师对零件进行各方面的详细设计。一旦完成，工程师将零件的生命周期状态提升到“审核”，这时启动一个审核流程； 如果审核者发现设计有误，则驳回给工程师，工程师根据审核意见进行修改，然后再提交，如此往复。如果审核通过，则零件生命周期状态提升到“批准”阶段，同时触发一个批准流程。批准流程的签审过程与“审核”一样，只是签审人不同。如果批准通过，则零件生命周期提升到“发放”，零件被冻结。若需要修改，则需要将零件修订一个新版本，然后在新版本上进行修改。

上述整个过程都发生在研究部门内部，工艺和制造部门则不参与。当零件被发放后，工艺和制造部门才在此基础上展开工作。如果工艺或制造部门在后面发现了问题，他们会通知研发部门，于是工程师将零件修订一个新版本，然后根据下游或现场反馈的情况在新版本上进行修改，修改完成后再次进行上述的签审流程，然后发放一个新版本，完成变更。

按照这个模式，零件的一个生命周期实际上指零件在研发部门的一段生命期，如果零件通过了研发部门的审核，即代表生命周期走到了最终点。当下游部门提出零件有缺陷时，零件需要“重生”一次（修订一个新版本），然后经历一个新的生命周期。

我们来看一下一个零件的一般开发过程。一个零件从概念阶段到批量生产，一般要经历如下阶段：

图2 零部件的开发过程

可以看出，零件设计阶段只占全部生命期的一半，后面还有大量的验证工作需要进行。而研究表明，产品80%的修改是在制造阶段以后完成的。从这个角度看，设计阶段的完成实际连整个生命期的一半都不到。这个时候宣布零件“发放”实际上不合适。就如同一个大学生刚完成本科学业就宣布他已经成才一样。

这种情况的发生并非偶然。现在很多制造企业的组织结构仍然是行政式的，研发部门负责产品研发，制造部门负责试制生产。 工作流程也一般是串行的。研发部门将设计签审后的图纸交到下游部门试制生产，出现问题再向上游反馈，而在零件设计阶段他们参与得很少。而PLM系统的实施则往往从研发部门开始，然后再延伸到制造部门。有的甚至只局限在研发部门内部。这样在系统部署之初，对零件的生命周期的定义就只定义到设计阶段，而一般不会从整个过程的角度去定义。同时，一些企业“甩过墙”式的设计习惯也加强了这种情况。所谓“甩过墙”的设计是指“我这个部门完成我的工作后就把结果甩给隔壁的部门，然后没我的事情了”。

零部件生命周期过短的影响

无论这种情况是如何产生的，带来的影响却是相同的——零件实际上没有完整的生命周期。零件在设计阶段被"发放"后， 下游部门提交的变更只能在新版本上进行，这就扭曲了版本本身的作用。

在PLM系统中，版本(revision)一般由大版本(version)和小版本(iteration)构成。小版本标记一次修改，大版本标记一次发放。这里的发放是指零件已经完成设计验证并投入生产。从标记修改的角度看，版本可理解为：小版本标记投入生产之前的修改，大版本标记投入生产之后的修改。由于生产前的验证和准备投入了大量的时间和成本，因此对零件在生产之前和生产之后的变更处理是不同的。

在零件投入生产之前，模具尚未开模，采购订单尚未下发，大量成本尚未发生。这时零产品处于设计或验证阶段，目标之一就是尽可能地发现和消除零件的缺陷，使零件具备高质量。因此这时发生的修改应该是即时生效的。

而零件一旦投入生产，则大量成本已经发生，对修改的处理变的谨慎。 并且投入生产的零件一般是经过验证的，这时发现的问题往往是改进性质的。因此修改一般不会即时生效，而是有可能等到下一款产品才实现，或等现有供货耗完后才使用新设计---当然，也不排除一些致命缺陷需要及时修复，而这在生产后一般要少得多。

因此，二者处理的主要问题一个是纠错型，一个是改进型。最直接的不同就是修改是否要即时生效。

在一般的PLM系统中，零件在未发放之前的修改只增加小版本，并且新的小版本会即时生效，即父级会马上自动引用***小版本；而大版本的增加一般不会即时生效。一般是当父级未被发放时，新版本的子级发放后父级会自动引用新版本：如果父级已发放，则新版本的子级发放后父级不会自动引用新版本。如果要引用，则需要将父级修订一个版本，然后再发放新版本的子级。 这与产品投诸生产后的改进是一致的。如下图：

图3 零部件版本管理

但当零部件的生命周期仅代表其设计周期时， 就打破了上面的规则。

试想，当某一部件设计完成， 研发部门将其及子项悉数“发放”。而后下游部门发现部件或子项存在问题，并提交给研发部门修改。这时工程师需要将部件修订一个新版本然后进行修改。这意味着之前 “发放”的版本实际并未进行生产，这就扭曲了“发放”的本意。

不仅如此，若需要修改的是部件的子项（实际上大部分情况都是修改子项），那么新版本的子项发放后该部件不会自动引用新版本。这样就必须修订该部件。如果部件有父级，则需要依次往上修订。这样一次修改就会产生大量的修订，势必使变更效率变慢。如果不想层层往上修订，则必须把系统开发成“即使父级处于发放状态，子项修订新版本后，父项也会自动引用新版本子项”。这样做产生的问题是：部件永远处在***状态下，这样失去了对历史状态的追溯功能。

因此，无论从那个角度考虑，一旦零部件走出了设计阶段，这个生命周期图就无法在准确描述其生命阶段和状态。

建议

上述问题的产生，是由于零部件的生命周期图只描述到设计阶段完成，而零部件后面的演进则超出了这个阶段。即用较短的生命周期图描述较长的生命期。要解决这个问题，需要将产品的生命期延伸到验证和制造阶段。产品设计阶段的完成只能定义为“设计冻结”，而不能定为“发放”。真正的“发放”定义在产品验证完成后，批量生产之前。如下图：

图4 零部件生命周期管理

上图中，在“设计冻结”之前，零部件处于设计阶段，研发部门工程师可以对零部件进行修改；所有的修改完成后，便可提交审核，并最终进入“设计冻结”。零部件提升到"设计冻结"需要做一个校验:只有当所有子项被提升到"设计冻结"后，父项才能提升到"设计冻结"。 在该阶段，研发部门部门工程师无权再进行修改。

“设计冻结”表示零部件设计阶段的完成，但尚未“发放”。当下游部门发现问题时，便提交给研发部门。研发部门工程师接到修改意见后，可将零部件降级到"创建"状态进行修改。修改完成后零部件增加一个小版本，其父级也自动引用新的小版本。然后零件被提交签审，签审通过后，零件再次提升到“设计冻结”，系统收回工程师的修改权限。 所有对反馈问题的处理都遵循这个模式。当验证阶段反馈的所有问题都被妥善处理后，产品便可以提交发放。同“设计冻结”一样， 产品发放时也要遵循一个原则：只有当所有的子项发布后， 父项才能被发布。

一旦产品进入“发放”阶段，系统便将其冻结，作为历史查询记录。用户若要修改，则需要将其修订新的大版本，然后在新的版本上进行修改操作。 当然，新的版本发放后，其父级不会自动引用。

对于一些特殊情况，即在生产阶段发现的一些严重缺陷因而不得不进行的修改。这时需要提出修改申请，然后由具有管理员权限的账户执行对发布后的修改。 这种情况必须严格控制。因为生产之后的修改必然伴随这高昂的成本。

表面上看，图4与图1中的生命周期只增加了两个生命周期阶段，但实际上却有很大的不同。在图1的生命周期中，设计完成即表示产品“发放”，产品验证和批量生产前的阶段被排除在零部件生命周期之外；而这个生命周期图则将产品设计完成后，批量生产前的阶段也囊括到产品生命周期内，产品只有等全部验证通过后才被认为能够“发放”，因此是将设计和工艺制造视为一个流程内。

现在，咨询机构和厂商更愿意把PLM管理的生命周期延伸到销售和售后阶段，从这个角度看，要实现零部件的全生命周期管理任重而道远！这里面不仅仅只是增加若干个生命周期阶段的问题，而是这些阶段之间是如何演进及需要遵循哪些基本规则。

【编辑推荐】