前序
想当年…学了机械专业，大学毕业后觉得念工科就是应该要实战一下，不然闭门造车只学理论都不知道在念什么；再来，我也觉得动手比念书有趣多了（OS：其实是不爱念书）。刚进PLM行业时，听到实施方法论，是很嗤之以鼻的，尤其当年的实施方法论，比较偏重理论和项目管理层面，对于技术层面怎么落地并没有太多着墨。
初次研究实施方法论是在2005年实施某个整车厂PLM项目时，客户要求所有的交付物产出要符合CMII标准，只好去研究CMII在讲什么；到2007年，某个模具厂客户要求提供详细的实施方法论和实施模板来证明实施能力，我应公司领导的要求汇整了几年项目实施的经验，并上网研究软件工程/系统工程方法论，初步编写了瀑布式方法论对应的PLM实施模板（OS：所以先有实务才映射理论，终于明白理论还是有点道理的）。
图1. How Projects Really Work
图1是一张很有名的漫画，调侃了交付的IT系统和客户需求之间因过程控制不力导致的巨大偏差，我从第一次做方案设计开始就把这张图贴在桌上警示自己。2008年我转了团队从台湾来到上海，担任PLM团队的技术经理，按领导的要求围绕实施服务质量的提升进行变革。我当时一直在思考要怎样做项目才不会造成上图的结果，决定首先要有明确的实施方法论和规范。我整合了自己以往的项目经验，将2007年做的项目实施模板映射到当时公司实施方法学（VDM）所定义的项目阶段，花了几个月时间完成了针对每个阶段的活动内容定义以及总计28份技术文档模板，这个过程也让我对于实施方法论有了更深刻的认识。后来，在自己参与主导的某轮胎厂PLM项目中，在各个阶段按照活动定义深入应用了这些交付件模板，取得了非常好的实施效果（OS：该轮胎厂的PLM实施方案已成行业标竿，当初要是申请个专利我可能就可以提早退休了）。
在后续5年中，我在执行团队方案内审的过程中，也有意识地强化项目组对交付件模板的应用，多个项目的实施结果也证明了规范性工作方针及交付件定义确实能提高项目的整体实施质量（OS：没念过硕博，但也审核了清交硕博的项目，心里平衡了！）。后来公司总部开始重视技术方面的实施方法，负责此事的团队来上海进行交流时，更是对此实施交付物模板赞许有加，直言希望能拿去参考交流（OS：并不是国外的月亮就比较圆的）。
图2. VDM各阶段技术活动和交付件模板清单
2014年，我转换了跑道开始接触PERFORM实施方法论，结合软件平台的不同特点，我又重新定义了与PERFORM方法论对应的本地化技术文档模板，并结合项目的复杂度和实施周期定义了哪些是关键交付件需要客户签字（红色），哪些是辅助文档（黑色）可根据项目实际情况灵活裁减。如图3所示。
图3. PERFORM各阶段交付件模板清单
经历了两大PLM原厂商的历练，同时也在网上研究了各家友商提出的实施方法论，我发现各大厂商或咨询公司的方法论虽然在命名、阶段划分以及检查标准方面有所差异，但基本上都遵循着从前往后的瀑布模型原理。虽然也有提出在方案阶段就装好原型系统，让用户提前进行了解的，但除此之外似乎也没有再多能改进优化的地方了。
原型方案设计法
1、缘起
2016年，在转换跑道后我接手的第一个大型项目是某汽车集团技术中心的PLM实施项目，当时该客户已经花大量时间与金钱进行过咨询，也有一整套流程改进的文档。在项目启动前，客户方项目经理提出了一个挑战，他说我们有完整的流程体系，也特别挑选了你们比较有经验的实施团队，那你们能不能不用开展冗长耗时的业务调研（讲一堆已经知道的东西）而直接开始实施，但又能保障系统对需求的满足呢？
2、过程
于是，我进行了一个大胆的试验，提出了原型方案设计的实施方法。
图4. 基于原型方案设计法的工作路线
即在方案设计阶段进行实施方法的调整：不开展冗长耗时的业务调研，而是在对用户进行OOTB功能培训让用户对软件有所初步认知后，由实施方结合OOTB功能和行业解决方案，基于实施方顾问的经验，直接给用户提供详细到操作界面的方案文档。然后通过多轮讲解和研讨，与客户一起分析数据差异以及业务需求的满足程度，反复修改详细方案以保证其可行性，如图4所示。在方案审批确认后，后续项目阶段采用瀑布式方式继续进行。
原型方案可以采用按功能模块的方式描述业务场景，但必须包括一个整体业务流程图，并在明确定义各功能模块之间的接口和职责以及整体业务流程清晰后，进行分模块的分工。每个功能模块的原型方案应描述关键业务场景和功能说明，并阐明其亮点，如图5和图6所示。在描述业务场景和功能时，应尽可能地展示未来系统的使用界面，以便让用户了解未来的操作场景。
图5. 基于原型方案设计法的方案编制过程
图6. 原型方案的模块分工样例
原型方案设计法的优点显而易见：
√ 取消了调研、简化了方案讲解及审核，降低了项目执行过程中对关键业务用户时间的占用。
√ 方案已经包含场景步骤并细到系统界面展现，可避免在讲解方案的过程中，用户方与实施方鸡同鸭讲，因理解不一致而产生偏差。
√ 方案针对真实的实例数据进行调整，可避免在上线后使用的需求偏差。
应用
原型方案设计法适用于两种情况下的企业：一是能够明确定义需求并已了解PLM系统的企业用户；二是新兴企业用户，没有成熟的业务流程和规范，希望借鉴行业最佳实践。这种方法非常依赖于实施方对用户所在行业的业务流程熟悉程度以及在该行业中实施PLM项目的经验。
我们已经在某汽车集团的的研发技术中心PLM项目、某商用车PLM项目、某医疗科技PLM项目以及某民用航空PLM项目中成功地采用了原型方案设计法。
敏捷聚焦迭代法
1、缘起
在实施一家合资车企PLM项目时，合资的外方分享他們的实施经验，非常自豪地说使用了Agile方法，却又说各业务板块的实施负责人自己做自己的，导致系统在数据模型方面一团乱，数据流也不顺畅（OS：这不是显而易见的结果吗？）。不过外方的实施经验仍有可以学习的地方，比如写用例场景的方式等等。
后来，我有机会去了解某新能源车厂的PLM实施。客户非常强调使用者体验为最高优先。但是深入了解后我也看到了一些不太理想的情况：比如没有事先规划整体场景蓝图，想到什么需求就开发什么需求，相同的数据管理场景可以因为不同的车型项目而不一致；过份强调使用者易用而定义的一系列自动化操作，在真的需要人为交互时反而更麻烦；过份强调使用者友善性，导致多个系统间反覆交互，影响性能及数据正确性；每个迭代周期太短，时间都用在功能代码开发和测试上，没有更新整体场景和整体系统逻辑，最终没人说得清楚当前系统里哪些开发是有效的，以及用户最新使用场景是怎样的等等。由于上述这些因素，整个敏捷实施变成了一个不断打补丁、叠床架屋的过程（OS：互联网造车，不表示互联网思维可以原样照搬到工业软件的实施呀！）。
2、过程
最近我有机会开始负责某新能源车企的PLM实施，客户要求采用敏捷迭代法实施，我思考良久，要怎么才能规避之前看到的两个敏捷迭代实施项目的问题？（OS：终于有机会应用并改进敏捷式实施）。
采取以下作法：
先对整个PLM系统进行整体业务场景蓝图设计，然后根据优先级排序划分每个迭代需要实现的业务板块，接着细化每个业务板块的功能需求，再进行优先级排序。最终，得到该迭代需要实现的详细业务场景与功能清单，并使用敏捷开发进行系统落地和实现，如图7所示。
在每个迭代结束后、下一个迭代开始之前，重新审视PLM系统的整体业务场景是否需要调整或更新，再根据业务优先排序确定下一个迭代需要实现的业务板块和功能清单。这个过程需要不断循环迭代。敏捷聚焦迭代法中“聚焦”一词的核心要义，就是指迭代的划分和实施必须基于统一的整体方案及数据架构，每一次迭代的实施结果又作为输入来审视整体方案和数据架构是否需要调整和优化，两者互为因果、循环往复，螺旋式上升。每一次迭代后的审视让方案和架构愈发完善，而每一次方案的优化又可以更好地指导下一个迭代的实施。不同轮次的迭代方案之间相互融合，互为补充。
图7. 总体业务场景图和拆分迭代实施样例
为了减少编写交付物的时间，方案可用Word、PowerPoint甚至AVI形式等灵活展示，只要能解释清楚场景用例即可，如图8所示例。
图8. 场景用例样例
系统相关配置部署，可以简单地用Excel表格记录，但是必须跟生产系统保持一致。
方案、开发规格逻辑及用户操作场景在多次迭代的过程合并成一份文档，可同时看到方案、开发规格逻辑及用户操作场景，而且清楚地记录了变化过程，并让最新版本始终和生产系统保持一致。比如一个数据发布流程有许多检查项，在多轮迭代中因为需求变化，可能删除了一些检查点、可能增加了一些检查点，而这些检查点之间又存在耦合关系，如果没有做好场景及规格记录，或是仅单独记录每个迭代做的事情，可能到最后没人说得清楚到底在整个数据发布过程中系统检查了哪些点。
截止目前为止，参照这种做法我们已经顺利完成了几轮迭代开发，配置及功能逻辑规格清楚，用户场景也保持在最新的状态。系统运行、用户使用及运维支持均没有大问题。
依照事先构想的改进措施，切身经历此项目后，我感觉在未来的项目里还有很大的改善空间，比如可以仿照之前瀑布式整理一套适合于敏捷聚焦迭代法的规范性工作方针及交付件模板定义，让此种实施方式可以更加易于复制和执行。（OS：永远是下一个会更好）。
3、应用
敏捷聚焦迭代法适用于两种情况的企业：一是基于成熟行业业务流程的新兴行业，比如新能源汽车；二是非传统制造业企业，没有成熟行业解决方案可以参照，比如基础设施行业。这种方法非常依赖于实施方的总方案顾问对系统的全面性和系统化的把控程度（OS：可以顺便看看如何炼就优秀的PLM方案顾问）。
结束语
虽然理论是必备的，但因地制宜将其灵活地应用到实际项目中更为关键。因此，在实施PLM项目时，选择一个合适的实施方法论和一支能将该实施方法论灵活运用并加以完善的实施团队是确保项目成功的关键。
达索系统 C&SI 合作伙伴
达索系统开发合作伙伴
