项目实施方法是每个PLM项目实施之初项目团队需要考虑的问题。传统的“瀑布式”实施方法是很多实施团队的首选。该方法将整个项目阶段分为需求分析、方案设计、系统设计、系统开发、系统测试、系统上线、用户培训等阶段，每一阶段完成一定任务，交付若干规定的交付物，直至交付最终系统。对于一些全新开发的系统项目，因为没有现成系统可供客户参考，因此多采用传统开发方法。从分析客户需求开始，经过系统设计和开发，最后交付客户测试。
但对于一些配置化和商业化程度较高的PLM系统，如ENOVIA，系统本身就包含了一套行业实践。系统实施的过程的焦点主要集中在应用系统标准功能，同时针对客户企业的实际流程辅助一些额外功能的客制。对于这种情况，项目团队可考虑原型法进行实施，以提高项目成功率。
一、传统PLM实施方法讨论
传统实施方法是一个典型的串行模式。项目启动后，项目团队展开需求调研，分析客户需求。根据分析结果撰写需求分析报告，作为后续方案设计的依据。需求分析结束后，负责方案设计的顾问根据需求分析报告设计系统方案，期间客户会展开一定讨论;方案定稿后，系统设计工程师和开发工程师展开系统开发和单元测试。系统各单元功能开发完毕后，项目团队组织客户进行系统集成测试，完成测试报告。最后组织系统上线。整个实施过程如图1所示。
图1 传统实施过程
实施方法的优势在于，整个实施过程简洁明了，环环相扣，节点分明。便于客户理解。并且各节点任务分明，项目范围容易界定。
从项目合同执行方面看，这种实施方法也有利于合同的执行。因为各阶段任务和交付物定义都比较明确，合同双方很容易就系统交付和合同款支付方面达成共识。实际上，很多实际项目合同中都有明确规定到什么阶段乙方交付哪些交付物，甲方支付多少合同款的条款。
然而，这种实施方法也存在明显缺点。在需求分析和方案设计阶段，客户并没有接触到实际的系统，对未来系统的场景都是通过个人想象，因此每个人的理解都是不一致的;对于系统方案，也多是停留在纸面上，客户这时并不能理解到这些方案以后在系统中到底是如何实现的，只能选择信任实施团队;实施团队则希望系统开发完成后，客户参与系统测试时能够理解和接受方案和最终系统。这样做的结果是将风险推到了系统测试阶段。
在最好的情况下，客户在测试系统时发现系统实现的正是当初自己设想的，于是顺利的完成系统上线和验收。然而这种情况很少发生。原因如下：
1)在整个项目实施中，客户除了在需求分析和方案设计阶段有参与外，中间其他阶段(系统设计，系统开发，单元测试)参与的机会则很少，客户并没有太多的机会接触实际系统。在最终参与测试前，客户对系统的认识更多的停留在自己的想象或PPT演示中。在这种情况下，如何能保证最终系统与客户头脑中设想的系统正好一致呢?
2)在需求分析和方案设计阶段，实施团队与客户的讨论是脱离实际系统进行的。实施团队了解系统却不了解客户的实际业务过程;客户了解自己的业务过程却不了解系统;在这种情况下，双方缺乏一个共同切入点。因此在讨论和沟通过程中使用的语言和术语很可能理解不一致，最终导致双方对形成的“共识”实际上理解并不相同。
以上原因可能最终导致客户发现测试的系统与当初自己设想的系统不相符。这时，系统开发已经完成，而客户则反馈系统并不是他们想要的。这对于项目实施团队来说无疑是一场灾难，但又是顺理成章发生的结果。
二、快速原型法探讨
之所以会发生以上的结果，是因为客户前期参与时接触不到实际系统，因此陷入“空对空”的讨论;中期又缺乏参与，无法对系统进行深入了解;后期参与时才发现实际与设想大相径庭。所有的风险被一路后推，最终导致项目陷入僵局。
打破这种僵局，我认为需要让客户自始至终中都参与进来，对系统进行评价和反馈。快速原型法可以满足这一要求。
快速原型法即在系统开发之初，尽快给客户构建一套系统模型(原型)，然后反复演示原型并征求客户意见，开发人员根据用户意见不断修改完善原型，直到基本满足客户要求的一种系统实现方法。
对于一些配置化和商业化程度较高的PLM系统， 系统本身就包含了一套行业实践，即OOTB(Out Of The Box)功能。这些功能基本可以满足企业的一般业务需求。实施团队可以以系统标准功能为基础，对客户进行系统基础培训。然后分析客户的特殊需求，开展多轮迭代开发。
在项目启动后，实施方首先对客户核心用户进行系统标准功能培训，使客户对系统有基本了解。在此基础上，实施团队与客户展开需求分析。实际上，由于客户对系统已经有了了解，需求分析过程基本也就完成了方案设计。
实施团队将客户需求根据重要性进行优先度排序。先将客户最关注的若干功能在系统中进行配置或开发，交给客户进行测试，并根据客户的反馈意见进行调整和修改，直至客户测试通过;然后实施次关注的功能，如此进行迭代开发。最终结果是客户的所有需求都在系统中得到实现，并通过客户测试。如图2。
图2 快速原型法实施过程
这种方法使客户全程参与到项目中。在需求分析之前，客户核心用户已经接受系统标准功能培训，对系统有了基本了解，因此避免了需求分析阶段的“空对空”模式，使需求分析更能反映客户的实际愿望;
在系统设计和开发阶段，客户也并没有被排除在外。传统方式是将系统所有功能开发完成后，客户才参与进来。这样带来的风险是，如果开发的功能与客户设想的功能不一致，不能及时进行调整。这里通过将客户的需求分步分阶段进行开发，使客户可以及时进行测试，开发人员及时进行调整，从而实现系统功能与客户期望差异最小化;
以上的结果是系统实施的风险在需求分析和系统开发阶段即得到控制，从而增大了风险管控的力度，提高项目的成功率;
从客户培训方面看，这种方法使客户能够得到最充分的培训。因为客户在项目伊始就接受了系统基本培训，在项目过程中又参与测试，亲自操作系统。因此在系统最终交付时，参与的客户应该对系统掌握会比较深入，甚至可能可以解决一下系统常见问题，为后续系统维护奠定良好基础。实施团队也不需要另外单独花时间对核心用户进行培训。
但是，这种方法并非没有缺点。由于系统实施过程中，客户的需求是分步分阶段逐步实现的，并且每一次迭代都需要通过客户的测试。这就有可能发生客户需求不断蔓延，实施团队发现客户需求永远也得不到满足，系统交付遥遥无期;
同时，系统开发和测试不像传统实施方法那样有明确边界，给项目合同执行带来一定模糊性。为合同执行和付款带来一定的障碍。
针对以上问题，我认为需要从以下方面进行控制：
(1)项目经理需要有较强的项目范围把握能力。项目实施中应始终围绕项目目标和方案，抓住客户主要需求。对于客户提出的超出项目范围的需求，需要与客户进行充分沟通，做好解释工作;
(2)签订合同时双方应就合同执行阶段里程碑做好明确规定，以便后续合同的顺利执行;
(3)客户方应授予核心用户充足的时间资源，保证核心用户能全程及时参与。同事核心用户应具有一定的决策权，以便对每一阶段功能测试是否通过做出决定。
三、总结
PLM项目实施中采用的实施方法对项目的成败起着关键性的作用。无论是传统的实施方法，还是快速原型法，最终的目的都是保证项目实施成功，双方合作愉快。然而这两种方法也各有优劣，传统实施方法过程清晰，阶段分明。实施团队容易把握项目实施范围，但是却将项目风险推到了项目后期，不利于项目的风险控制。快速原型法可以使客户全程参与项目，将项目风险点提前，有利于风险控制，但却容易用户需求蔓延，不利于项目范围控制。在实际项目中，实施团队需要在项目之初根据实际情况选择一种最佳的的实施方法，以保证项目顺利实施。
（转载）
