如何管理PLM系统中零部件的生命周期

2020-12-27 17:39:00 行业动态 63

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



1


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


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

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

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

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

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

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



2


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


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

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

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

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

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

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


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

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

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

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



3


建议


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


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

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

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

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

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

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

因为专注,所以专业

广州佳鱼信息科技有限公司(以下简称佳鱼信息)成立于2020年,公司是由拥有制造业信息化咨询服务十多年经验的专业团队组成,致力于数字化产品研发管理及营销领域,拥有全面的行业应用解决方案和专业的实施团队。 作为一家新兴成立的科技公司,佳鱼信息将专注、专业、专心服务每一个位客户,为中国制造贡献一份力量!

产品中心

联系我们

广州市番禺区番禺大道北822号信业悦都汇A3栋831室

156-0165-4900

info@soscad.com

7*24小时服务