PLM项目之三大纪律八项注意Word格式文档下载.docx
《PLM项目之三大纪律八项注意Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《PLM项目之三大纪律八项注意Word格式文档下载.docx（11页珍藏版）》请在冰点文库上搜索。
如前所述，在强化管理,结果导向的企业，信息化项目无不是为了贯彻企业自身所特有的管理理念，支撑企业的商业价值，从而达成企业的商业目标。
抛开企业的业务目标，而奢谈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：
项目组织模型示例
在以往一些项目中，项目的组织模型要么停留在了口头上，要么没有真正得到有效的遵循，因此出现的问题往往不能在其早期被发现，被解决。
直至问题一发而不可收拾最终酿成项目的重大损失。
可以说在绝大多数出问题的项目中，其根本原因都可以归咎为项目组织模型方面的缺失。
从项目管理的角度来看，项目组织模型其实就是项目管理计划（ProjectManagementPlan）的体现，只有将项目管理计划切实落实到实处，才有可能确保项目沿着健康的方向前进。
避免那种问题到来时，进退失据的情形。
通常，在具体项目的执行过程中，项目管理层如果深深纠结于如下若干典型问题而不能自拔时，这些项目的负责人就需要扪心自问自己是否在项目组织模型上中招了：
1.项目计划停留在纸面上，真正计划的执行却在是“有一搭，没一搭”地在跟着感觉走，而且这种情况无法改变；
2.在需求收集阶段，讨论需求的业务部门的人不固定，需求的搜集过程如同打出的拳头，却不知最终会打到什么。
更可怕的是这种情况无从改善；
3.方案确认时，却发现交付的结果始终无法确认，这种情况迟迟无法改变直至影响项目的进度；
4.在系统实现阶段，测试没有最终用户的有效介入，所发现的问题迟迟无法收敛，但却不能从根本上扭转这种颓势；
5.项目中的风险、问题、待办事项在执行过程中无法得到有效的跟踪和处理，很久以前提出的问题在时过境迁后竟似甩不掉的膏药般如影随形；
套用某企业总结的一句话，如果项目发生“会而不议、议而不决、决而不行、行而
不果”的现象时，可以断定的是，这个PLM项目就已经发生项目组织模型的问题了。
八项注意之三：
供方选择
失败项目的原因往往千差万别，但成功项目的要素却通常大抵相同。
在最终成就PLM项目成功的诸多因素中，一个须高度关注的要素就是：
在成功的PLM项目背后，一定有一支卓越的PLM服务供方团队。
这支队伍能经受项目执行过程中技术和业务的考验，切身想客户之所想，急客户之所急。
更重要地，能从方案的角度，系统实现的角度，从既往成功的经验和失败的教训中去引导客户。
一支合格的PLM供方团队，在客户PLM项目实施过程中，不仅发挥布道者和推动者的作用，更会起到合作者和规划者的作用。
因此在国际权威组织CIMDATA在对PLM的定义中，明确提出了其中的要素之一是“面向业务/行业的解决方案和咨询服务”。
这其实是对PLM项目供方团队明确的而又很高的专业要求。
具体而言，优秀的供方团队需要在项目的执行过程中以项目能真正服务于企业的管理要求为最终目标；
以面向产品全寿期核心业务过程的切实改进为行动方向；
这支队伍需要拥有成功/失败正反两个方面的长期实践经验和行业知识的积淀；
拥有卓越的项目规划、执行、监控能力；
并能通过自己以往的经验和在企业现场卓有成效的工作与客户团队包括最终用户形成良性互动关系。
唯有如此，企业的PLM项目才可能少走弯路，少犯错误，最终项目的交付结果才可能真正服务于为企业的管理目标。
图2：
合格供方需具备的要素
某从事电力电子及其相关控制技术产品的研发、制造、销售和服务企业在实施PLM项目时，引进了某外部实施团队来作为实施方。
受到项目进度、成本等方面的压力，同时也可能是由于该供方对客户业务过程和管理目标了解的欠缺，因此整个项目进行到后期，项目交付的功能始终与客户的实际业务之间存在严重的两张皮现象，项目的结案也成了一个问题。
客户投入了巨大的人力物力资源，但引入的系统在很大程度上却没有达成企业在项目规划之初既定目标的要求，成为又一个“半拉子”工程。
对供方而言，项目后期的合同款项难以收回自然会带来一定程度上的经济损失，但从客户角度来看，无论是从成本、资源的投
入来看，还是从系统无法达成企业的业务目标来看，其带来的岂不是更大的损失？
八项注意之四：
方案与测试
PLM项目解决方案等同于ERP项目的蓝图；
其核心作用就是基于对企业的业务过程和需求的了解，形成在PLM系统中切实可行的技术路线。
因此PLM的方案是指导项目成功推进的关键交付之一。
而为了保证方案能够真正落实到位，在系统实现工作完成后，还需安排必要的用户验证测试（UAT），以此确认所完成系统与所定义方案的一致性。
在项目执行过程，往往遇到的问题是，要么是方案是对系统功能的生搬硬套或功能堆砌，难以与前文“三大纪律”中所述的业务目标和业务过程相匹配，从而导致了类似系统交付了，项目悲剧了这样的结果；
要么做的方案细致程度不够，导致方案无法指导后续工作的开展，或需要不断进行更改修订，导致成本、范围、进度的巨大风险。
此外在方案执行过程中还存在企业个性化需求与采用“削足适履”的方法适应行业解决方案的冲突。
当该类冲突发生时，一种可行的做法就是要深入考虑某些个性化需求能否暂时搁置一下；
同时仔细斟酌“削足适履”时要怎么“削”，怎么“适”，也就是要尽量多地考虑如何将企业的需求与系统或行业推荐做法相结合。
这既是对企业的考验（在解决方案定义过程中，必须保证业务专家深度参与到讨论和决策的过程中来），更是对PLM方案供方的考验。
有可能差之毫厘的决策，最终导致项目失之千里的结局。
从测试（UAT）的角度讲,由于它被用来验证系统实现的功能与所定义方案的一致性，因此必须从业务过程的角度，用详细的测试场景和测试脚本来切实进行充分的测试与验证工作。
如果此时的工作陷入简单的定制功能测试或系统功能验证中，则在测试完成后，往往仍会在上线过程中存在巨大的风险。
对具备项目常识的管理者而言，最终用户在方案和测试验证阶段的深度参与至关重要。
但在实际执行过程中，往往又会因种种原因在这两个方面的工作中大打折扣，究其根源，其实是由于人们对这种重要性的认识仍然停留在表面，或者当实际工作与项目工作发生“冲突”时，项目管理团队对业务团队的一种没有原则的妥协。
这种妥协直接又反过来对业务团队借助PLM系统开展工作的目标带来不利的影响。
因此知易行难，如何在项目执行过程中切实将这样的原则贯彻始终，是项目各方干系人必须在项目执行过程中反复思考并切实关注的问题。
八项注意之五：
标准功能抑或开发
在业务方案确定后，实施的主要工作为按照既定方案的相关配置工作。
涉及流程、编码、分类、存储、权限等一系列的内容。
除非万不得已，否则不建议对标准系统功能及界面（UI）进行调整。
这样做主要是基于如下的考虑：
1.UI和易用性功能往往是最终用户一个适应和接受的过程，所谓的“法无定法，式无定式”，今天因为对系统缺乏足够的了解而认为不方便的功能与操作，在最终用户熟悉后和了解后，可能就会发现是自然和理所应
当的了。
2.由于该部分调整通常会涉及对标准功能的调整，因此除了带来许多额外的工作量外，还会带来未来诸如系统补丁部署，升级调整的困难；
3.之所以在很多用户处存在各种各样的开发工作，其缘由往往在于项目组把系统当成一个无所不能的开发平台。
因此整个项目也就随之成为软件开发项目。
但实际上，与SAP/ORACLE等ERP软件系统一样，PLM系统尤其是国内外广为应用的PLM系统其实已经在以往应用过程中，形成了内容丰富、，涵盖许多客户实际经验的体系框架。
如果抛丢弃这一体系框架，而陷入具体开发的细节，势必成为本末倒置、缘木求鱼的项目。
但对此的深刻体会往往需要走过了很多弯路，经历了许多反复，付出很大的代价后才能被慢慢地领悟到，被充分的认识到。
导致这种抛弃标准功能，倾向于大量开发定制工作的本质，是人们强调自身个性化结果的必然产物，这也符合人们认识发展过程的内在规律。
但问题是每当我们钟情于这种个性化开发而欲罢不能时，建议多想想：
这种开发必须要做吗？
原本系统的功能是否有其内在的合理性？
如果纠结于类似多点一个链接、少点一个链接的易用性问题时，建议先想想其它企业，尤其是国外企业为什么能够接受这样的做法，在此基础上考虑这些期望的个性化开发定制工作是否可以先放放；
如果一定要做，能否在后续实施项目中来做。
这样在本期项目完成时，回头总结时，也许会发现自己原来的想法已经发生了巨大的变化。
当然当通过开发定制切实能够解决企业某一业务过程涉及的核心问题时，则这种开发定制的尝试还是值得肯定的，此时才能彰显这种开发定制工作的内在合理性的。
但PLM项目执行过程中任何较大规模的开发工作前，务必经过充分的利弊评估尤其是优先级评估后方可以付诸实施。
八项注意之六：
宣贯与知识传递
作为项目，PLM实施工作必然会有其最终结束的一天。
但从PLM系统推广应用角度来看，系统的使用和推广，则是只有开头，没有结束。
因此如何在项目实施过程中，建立企业自身的业务队伍和技术队伍就成了一个非常关键的问题。
根据那些成功项目的经验，这里建议在项目启动阶段组建企业自己的一个项目实施团队，并随供应商项目实施团队一道参与到项目整个实施过程中。
这意味着在项目的执行过程中，需要密切关注系统知识、业务知识在实施方和承建方彼此之间按照既定项目节点要求进行知识传递；
为此目的，，一方面需要承建方需尽快了解客户固化的需求（但不是在实施过程中，始终渐变或开口的需求），另外一方面更需要企业的项目参与人员能尽快了解PLM的概念、了解系统关键与核心功能、在项目实施过程中逐步深化对系统的认识，并掌握如何将特定业务需求映射为系统方案再转化为技术实现结果的技能。
因此在项目的执行过程中，企业的实施力量，应该包括业务方案设计人员、技术方案设计人员、开发人员、测试人员、系统管理人员等。
这些角色的人员在项目准备阶段被指派出来后，需要尽早参与到项目的筹划和准备工作中，从而能按照团队的力量来推动PLM项目相关工作按照既定计划的切实展开并确保这些成员在这些具体工作中完成对必要知识和技能的传承。
在这一过程中，最终用户的提前参与，尤其是种子用户的提前参与尤显重要。
只有在项目执行过程中真正把最终用户纳入到项目的方案、测试过程中，认真倾听他们的意见，使其有一个对既定系统逐步熟悉的过程，才能避免对系统突兀被动的接受，避免系统上线后的负面反弹，并进而通过这些种子用户的影响力和推动力从而达到系统切换水道渠成的目的。
需要指出的是，在业务、系统、开发、测试、推广过程中，必要的培训是必不可少的环节。
而围绕培训的考试和测试工作又显得极为重要。
这些测试不仅是提高培训效果，保证各阶段工作质量的绝佳机会，更是避免项目风险、确保在项目执行过程中不被反常现象或问题所迷惑的重要手段。
【案例】某船舶企业,引入基于某IT系统确定的工作模式后，来自最终用户的反馈显得非常负面。
企业领导也深深地为如此的反馈所困扰。
整个项目后期工作面临骑虎难下，难以收场的窘境。
此时来自培训讲师的培训测试报告为企业探究问题的深层原因指明了方向。
原来，培训效果好的最终用户在培训完毕后，竟然没有再去参与这个项目，也没有作为关键用户去引导系统的使用。
整个系统由那些培训成绩不理想的成员所左右。
于是任由怀疑、迷茫气氛的滋生和蔓延。
企业领导在认识到该问题的原因后，主动采取了成员调整的手段，于是整个项目后期执行也因此而柳暗花明。
图3知识传递过程
八项注意之七：
系统的切换与上线
PLM项目的所有努力，归根结底是为了保证项目组交付的功能够支撑企业业务过程的开
展。
也就是既定的项目目标、方案此时要变成最终用户触手可及的具体操作，并将这些操作融入具体的实际业务中来。
以往经常存在的一个误区是，系统交付的时候，就成了企业和供方项目组最终庆祝的时刻，但欢宴之后，供方实施团队撤退了，企业的项目则陷入了进退维谷的窘境。
其实上线切换工作是整个项目成败与否的临门一脚，“行百里者半九十”其实正是项目这个阶段的真实写照。
此时项目往往受困于两个基本的截然相反的问题。
第一个是系统上线，但原先业务模式照旧，于是两条腿走路的双轨制（比如仅有一两个试点型号或产品在系统中尝试运行）导致系统对业务影响力的降低，更导致系统中数据的正确性难以得到有效保障，并最终导致系统的无人问津。
对此种情形，必须要保证系统是业务开展的唯一出口，坚决杜绝所谓两腿走路的情况发生。
为达此目的，一个经常用到的方式就是系统上线后的问题追踪和应用追踪，从而通过“扶上
升级会员 