|
背景 长久以来，PLM系统的实施一直遵循以下的过程：
这是典型的阶段切分，是瀑布式和V型开发流程的体现，瀑布模型产生的历史背景可以追溯到20世纪70年代，而V模型是基于瀑布模型的改进衍生，瀑布模型试图将各个阶段进行分离，V模型尝试在分离的阶段间增加回溯，总之这两种模型属于一个相似风格。
我们无需对其优缺点详细展开分析，最显而易见的的往往就是其最致命性缺陷：比如我们熟悉的需求调研，有些项目会调研的无边无界，和项目目标毫无关联，还有时候把用户的期望吊的高高，仿佛做成一场高大上的咨询项目。很多时候在知识不对等的情况下，调研采集到的详细需求会有较大偏差，如果还要用户签署确认，这种模式初期就埋下了后续变更冲突的风险。
“敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。”
敏捷开发一定已经不是一个陌生的词汇，但是敏捷开发绝不是我们日常所认为的边看边做那么简单和随性。
迭代是敏捷的核心词汇，在汽车系统，移动终端系统，随着OTA技术的实现，系统迭代升级变得非常容易,这也将促使其向敏捷转变。从空乏的陈述，回归我们专注的主题，PLM的实施该如何调整为敏捷实施，这需要具备两个要素：需要对PLM功能的引入策略的修正，从下面的敏捷模式可以看到最佳的切入点一定不在右半部区域。对以上的四个划分区域，可以对照绘制一张通用的PLM功能矩阵，毫无疑问，从简单到复杂是学科更综合，业务更广泛，数据越复杂...
如果你倒过来做或者一下子全开足马力，那将一定陷入泥潭。
实施方法策略的第二个改变就是调整新的实施步骤向敏捷过程靠拢，从固化到改进，从小改善到大改善，构建持续改善的众多小过程。
要实现PLM的敏捷化，平台性选择也是重要因素，CIM Database作为一个庞大的PLM平台，具备了平台化必备的基础服务功能和模块化组合功能，更加重要的是其具备了经验化的标准实践。我们都知道模块化是敏捷系统的一个表现，可以让用户进行灵活的模块组合，以满足不同时期的系统部署需求。经验化的标准实践绝不仅仅模块化这种IT层面的敏捷，而是要在不进行任何初始模型的干扰下实现业务的开箱即用。我们用CIM Database的基础业务模型来做示例：
不要操心文档应该怎么分类，经验模型默认会给出一套完整的分类系统，直接套用可以满足大部分企业业务需求。
不再一一列举，仅借此说明经验模块化系统与普通模块化系统的区别
总结
一个系统的实施周期如果大于四个月，将是一场对企业和服务双方俱耗的拉锯战，在信息化快速发达的今天，企业需要更快的系统导入，服务方需要更加清晰的实施目标。 PLM通过敏捷化的过程和经验平台的优化整合，将改变传统的实施策略和平台选型。
|
