PLM项目之三大纪律八项注意Word文档下载推荐.docx

PLM项目之三大纪律八项注意Word文档下载推荐.docx

《PLM项目之三大纪律八项注意Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《PLM项目之三大纪律八项注意Word文档下载推荐.docx（11页珍藏版）》请在冰豆网上搜索。

其实在失败项目的关键干系人中，这些PLM项目的亲历者也会经常扪心自问自己是如何与项目的成功失之交臂的？

尽管有些项目的管理者会萌发“PLM项目实施找死抑或等死”的喟叹，但更多企业则是在反思如何总结经验教训以图来日东山再起，从而真正将PLM理念融入企业的管理实践中。

那么对一个正在规划的PLM项目，究竟怎样才能借鉴成功项目的经验，站在巨人的肩头，并汲取失败项目的教训呢？

这里根据笔者多年PLM实践所获得的正反两方面经验从PLM项目的“三大纪律，八项注意”说开去。

PLM项目的三大纪律

PLM项目的“三大纪律”，其核心解决的是目标和方向的问题。

套用一句多年前经典语录的话，就是“思想上政治上的路线正确与否是决定一切的”。

只有把握住项目的目标和方向，才能在项目执行过程中始终能统揽项目的大局，不容易为项目执行过程中的各类局部问题所困扰。

其涉及的是“做正确事”的问题。

因此需要被首先论及。

三大纪律之一——“面向业务目标

如前所述，在强化管理,结果导向的企业，信息化项目无不是为了贯彻企业自身所特有的管理理念，支撑企业的商业价值，从而达成企业的商业目标。

抛开企业的业务目标，而奢谈PLM的丰硕成果，通常只能是“无源之水，无本之木”。

落实到具体项目，其结局必然是

轰轰烈烈的前奏，无声无息的结局。

或者是历尽苦难，还不得不重头再来。

尽管“面向业务目标”是信息化项目的一个基本常识，但执行起来却往往会堕入“只见树木、不见森林”的怪圈。

个中原委，既存在对信息化项目本身或企业业务目标尤其是两者之间的内在关系缺乏深入了解之故，也存在悄然作祟的“屁股决定脑袋”之类本位主义的原由，还存在将PLM项目变成简单软件工程开发工作的误区。

于是，在项目招标阶段，各方不由自主地将项目局限到了功能上；

在需求调研与方案设计阶段，对需求的把握则成了眉毛胡子一把抓；

在实施过程中，追求个性化开发或系统内部逻辑的强制关联超过对如何借力PLM提升内在管理水平的诉求；

在项目执行过程中，各方纠结于局部利益的最大化。

于是整个项目迷失在日常的执行过程中，这个过程按部就班、风平浪静也好；

红红活活、冲突不断也罢，但它与项目的真正的往往又是潜在的业务目标却是渐行渐远，项目也就成了水中的浮萍，丧失了坚实基础的支撑。

【案例】

某IT企业，在并购国外某著名品牌，整合集团级的信息系统时，PMO的目标是努力降低项目成本；

业务部门的目标是努力将各式各样的需求向项目中填压；

IT部门的目标是尽量短的项目周期；

但项目的总体目标，取代原来诸多的LEGACY系统，建立基于新系统的完整的E2E（EndtoEnd）过程却在项目执行的中前期为相关各方或多或少所忽视。

于是项目挣扎于项目三角形“范围-成本-时间”的矛盾中，直至各方历尽千辛万苦最终统一到达成共识的企业管理目标上来后，项目的执行才开始纳入正轨。

三大纪律之二：

“面向业务过程”

在很多PLM项目的立项阶段，招标文件中往往会涵盖许许多多的功能需求，甚至到了“事无巨细”的程度，但在这所有的繁杂需求中，被漏下的往往却是通过项目来提升企业哪些关键业务过程的能力，以及如何提升这些业务过程的能力。

于是在项目的前期，尤其是供方选择阶段，相关的服务提供商或产品供应商被面向功能而非面向业务过程的指挥棒所驱使，无不竭尽其能地在展示自己功能上所谓的“零”偏差能力，而如何通过完整解决方案助力业务过程的提升则往往在此时被抛在了九霄云外。

因此当大幕落下，当初的承诺也许做到了，但PLM项目所交付的结果却仍难以融合到企业的业务过程中，这些承诺的功能陷入不知如何真正为企业所用的尴尬境地；

最终交付的大部分结果仍然难逃束之高阁的厄运。

于是尽管对很多需求方案进行了规划和定义，系统实现过程中也做了大量的工作，但系统最终仍不免沦为类似简单文档管理的平台，即便系统管理了其它的一些业务数据，但这些数据的正确性也无从得到有效的保障。

此时，相关的供方在功能测试完成准备上线后闪身了（这往往很多项目经常遇到的情形，也是项目难以收尾的原因之一），“和我追逐的梦擦肩而过”的故事就这样不断地在许多客户处周而复始地上演着。

导致这种“和我追逐的梦擦肩而过”的缘由也许有很多，但其中一个重要的原因就是没能真正以产品开发端到端的业务过程为导向，并将与PLM系统结合在一起的业务过程作为引领项目推进的核心工作来抓（例如与后端系统从功能角度上也集成了，但更改结果却无法在前后两个关联系统中有效地传递），于是PLM项目终究还是无法避免可惊可叹却不得不从

头再来的宿命。

三大纪律之三：

“面向业务数据”

面向过程的背后，其实隐含着另外一个“面向什么对象的过程”的话题；

PLM缘自产品数据管理的理念，因此数据的重要性在PLM项目中的重要性不言而喻。

但产品开发过程中涉及的数据林林总总，既涉及需求论证数据、又涉及计划管理数据、设计数据，试验数据、仿真数据、工艺制造数据、投入使用的电子手册、以及运维过程中的各类保障数据等。

究竟什么才是PLM项目关注的核心数据又成了一个必须面对并在项目策划阶段就需要达成共识的问题。

从诸多成功项目的经验来看，考虑产品实际技术状态，面向端到端业务过程的BOM数据，是形成“面向生产进行设计，依据技术指导生产”业务过程的关键。

通过建立BOM数据（及其更改结果）的面向制造（或后端其它环节）的发布体系，从而形成产品设计结果在产品开发过程中的依序流转，是既往那些PLM成功项目之所以成功的关键之一。

这意味着在PLM项目中，针对既有产品的数据准备工作，就成了项目成败的另外一个关键因素。

也就是当系统投入运转的时候，一方面新开发设计的结果直接在PLM系统中进行管理并发布到后端业务系统；

另外一方面，既有数据更改工作，也须通过PLM涉及的更改过程发布到后端系统中。

从而保证前后端系统中数据的及时同步和最终的一致性。

从根本上说，PLM涉及的业务过程可以形象地比喻成企业的高速公路，上述的数据可以理解为高速公路上依序流转的车辆，这些数据借助高速公路高效运转，才能最终达成企业的业务目标。

此外数据范围的确定也有赖于PLM项目拟达成的业务目标：

消除设计与制造环节的壁垒的项目目标与建立产品全寿期产品支持保障体系的目标自然会决定两者的数据范围会存在巨大的不同。

因此需要针对前文中所述的业务目标来决定项目必须直面解决的数据问题。

PLM项目的八项注意

基于上述三大纪律的认知，我们是否就一定能在项目执行过程中畅行无阻了呢？

答案其实仍然是否定的。

这是因为三大纪律解决的是做正确事的问题，属于战略层的范畴，但落实到具体的项目中，仍然必须从战术的角度，考虑如何“正确地做事”的问题，这就构成了本文“八项注意”讨论的内容。

八项注意之一：

业务规划

在项目诸多成功要素中，一个核心要素就是项目启动前对项目合理的业务规划。

“饭要一口一口吃，路要一步一步地走”是人所共知的道理。

但落实到具体的执行层面，往往要么陷入“只见树木、不见森林”怪圈；

要么纠结与“知易行难”的窘境。

因此这里仍要首先来予以述及。

其实人们之所以纠结于“知易行难”的窘境，其原因要么是对“三大纪律”中涉及的具体目标、过程等难以从优先级上加以割舍，要么就是在项目规划过程中难以真正从执行层落

地。

在这一点上，一些成功客户定义的“顶天立地，小步快跑”“大处着眼，小处着手”等原则都是一些值得借鉴参考的做法。

“顶天立地”意味着需要从企业业务过程、IT规划的全局去指导具体项目的开展；

反过来“小步快跑”则用来保障“顶天立地”的规划可以在分期项目实施过程中切实逐步落地；

“顶天立地”与“小步快跑”结合在一起就形成了企业信息化目标通过分期项目逐步推进的路线图。

“小步快跑”其核心要义是基于“顶天立地”的思路分期实施，每期的规模不一定很大，但要能切实解决“顶天立地”规划中的一个或若干个（但不是很多）关键问题。

通过每期项目的尽快见效，推动整个PLM系统在最终用户处的接受度，最终达到润物细无声的效果。

“小步快跑”的做法其实是与某些企业“贪大求全”（当然主观上没有人认为自己是“贪大求全”）做法截然不同的两个思路：

尽管每期项目不一定很宏大，但跬步相积，小流相汇，若干年后那些不起眼的努力最终却化作助力企业业务提升的关键动力。

而我们看到那些“贪大求全”的企业，要么是在项目推进过程中付出了巨大的代价，要么是在经过艰辛尝试后再次调整为“小步快跑”的方式。

对后者当然是反映了企业信息化过程中相关人员认识逐步升华的过程，只是这种认识的升华是以基于既往工作的教训为代价。

【案例】：

无锡某研究所领导在项目启动会上明确提出了本期项目从业务上是要“100分”还是“60分”的问题。

他真知灼见地指出当时如果就要100分，那就是在拿项目的成败开玩笑。

他认为项目首先要解决的是系统在企业业务过程中生根发芽的问题，因此当时项目的首要目标，就是解决若干的关键业务问题，拿到60分。

至于100分，可以在未来的项目中逐步积累以致达成。

他的思路尽管没有用“顶天立地、小步快跑”的说法。

但其精髓却与这样的思路不谋而合。

八项注意之二：

正确的项目组织模型

项目在执行过程中，不可避免会出现各种各样的技术问题、业务问题和管理问题。

在出现这些问题时，必须要有正确的问题处理机制，并切实保证这些机制能切实落实到位。

因此项目的组织模型（GovernanceModel）在项目启动之初就应加以明确的定义并在项目启动之初就加以严格的执行。

由于项目组织模型的有效建立与切实执行事关项目执行的效率（正确地做事），更事关项目的方向是否与企业的发展方向相吻合（做正确的事）。

因此，明确定义项目组的管理执行过程和角色职责分工并将其落实到人，然后严格保证能够按照既定的项目组织模型去开展工作就成了项目酝酿之初非常紧迫的工作之一。

是关乎项目成败的关键。

应该通过对PLM项目重要性和迫切性的宣贯，尽快确立相关的项目组织架构并明确相关角色所应承担的责任以及项目开展工作的相关流程，从而将整个PLM项目纳入到制度化，组织化、规范化的管理模式中。

图1给出了某企业PLM项目实施的项目组织模型示例。

需要指出的是上述角色职责定义和工作流程确定后，务必需要相关领导审批，并在审批后正式发布出去，从而使其成为相关人员必须遵循的项目工作强制性要求和规范。

图1：

项目组织模型示例

在以往一些项目中，项目的组织模型要么停留在了口头上，要么没有真正得到有效的遵循，因此出现的问题往往不能在其早期被发现，被解决。

直至问题一发而不可收拾最终酿成项目的重大损失。

可以说在绝大多数出问题的项目中