无论这种情况是如何产生的，带来的影响却是相同的——零部件实际上没有完整的生命周期。零部件在设计阶段被“归档”后，下游部门提交的变更只能在新版本上进行，这就扭曲了版本本身的作用。
而零部件一旦投入生产，则大量成本已经发生，对修改的处理变得谨慎。并且投入生产的零部件一般是经过验证的，这时发现的问题往往是改进性质的，因此修改一般不会即时生效，而是有可能等到下一款产品才实现，或等现有供货耗完后才使用新设计。当然，也不排除一些致命缺陷需要及时修复，而这在投入生产后一般要少得多。
因此，二者处理的主要问题一个是纠错型，一个是改进型。直接的不同就是修改是否要即时生效。
在一般的PLM系统中，零部件在未归档之前的修改只增加版次，并且新的版次会即时生效，即部件会马上自动引用新版次，而版本的增加一般不会即时生效。一般是当部件未归档时，新版本的零件归档后部件会自动引用新版本零件。当然，如果部件也已归档时，则新版本的零件归档后部件不会自动引用新版本零件，如果要引用，则需要将部件修订一个版本，然后再一起归档。这与产品投放生产后的改进是一致的。不过，当零部件的生命周期仅代表其设计周期时，就打破了上面的规则。
试想，当某一部件设计完成，研发部门将其一起“归档”。而后下游部门发现部件或零件存在问题，并提交给研发部门修改。这时研发工程师需要将部件修订一个新版本然后进行修改，这意味着之前“发放”的版本实际并未进行生产，这就扭曲了“发放”的本意。
不仅如此，若需要修改的是部件下的零件（实际上大部分情况都是修改零件），那么新版本的零件发放后该部件不会自动引用新版本，这样就必须修订该部件。如果部件有父级，则需要依次往上修订，这样一次修改就会产生大量的修订，势必使变更效率变慢。如果不想层层往上修订，则必须把系统开发成“即使父项处于发放状态，子项修订新版本后，父项也会自动引用新版本子项”。这样做产生的问题是：部件永远处在新状态下，这样失去了对历史状态的追溯功能。
因此，无论从那个角度考虑，一旦零部件走出了设计阶段，这个生命周期过程图就无法再准确描述其生命周期阶段和状态。
四、零部件生命周期管理的一般性建议
上述问题的产生，是由于零部件的生命周期图只描述到设计阶段完成，而零部件后面的演进则超出了这个阶段，即：用较短的生命周期图描述较长的生命期。要解决这个问题，需要将产品的生命周期管理延伸到设计验证和制造阶段。产品设计阶段的完成只能定义为“设计冻结”，而不能定为“发放”。真正的“发放”定义在产品验证完成后，批量生产之前。如下图：
图3零部件长生命周期过程管理
上图中，在“设计冻结”之前，零部件处于设计阶段，研发工程师可以对零部件进行修改，所有的修改完成后，便可提交审核，并进入“设计冻结”环节。零部件审批流程进入到“设计冻结”环节，在此该阶段，研发工程师无权再进行修改。
“设计冻结”环节表示零部件设计阶段的完成，但尚未“归档”。当下游部门发现问题时，便提交给研发部门。研发工程师接到修改意见后，可将回退流程到“创建”环节进行修改，修改完成后零部件增加一个版次，其父级也自动引用新版次子项。提交审批流程经签审人员批准通过后，零部件审批流程再次进入到“设计冻结”环节。所有对反馈问题的处理都遵循这个模式。当验证阶段反馈的所有问题都被妥善处理并经过项目组评审通过后，产品数据（包含零部件及关联图纸）便可以提交“归档”。
一旦产品数据进入“归档”阶段，系统便将其冻结，作为历史查询记录。用户若要修改，则需要将提交变更审批流程，将其修订新的版本，然后在新的版本上进行修改操作。
表面上看，图3相比与图1中的生命周期管理过程只增加了两个生命周期阶段，但实际上却有很大的不同。在图1的生命周期中，设计完成即表示产品“归档”，产品验证和批量生产前的阶段被排除在零部件生命周期之外；而这个长生命周期过程图则将产品设计完成后批量生产前的阶段也囊括到产品生命周期内，产品只有等全部数据验证通过后才能够“归档”并“发布”。
现在，咨询机构和厂商更愿意把PLM管理的生命周期延伸到销售、生产和售后阶段，从这个角度看，要实现零部件的全生命周期管理依然任重道远！这里面不仅仅只是增加若干个生命周期阶段的问题，而是这些阶段之间是如何演进及需要遵循哪些基本规则。