产品生命周期管理项目风险管理
品生命周期管理(Product Lifecycle Management-PLM)系统已经在国内多家企业实施推广应用。其中既不乏系统推广效果显著，为企业发展直接助力的成功案例;更不乏项目实施过程跌宕起伏，项目超支或严重拖期的案例;还有项目过程轰轰烈烈，结果却无人问津，企业的巨额投入化为乌有的例子。成功的项目总是相似，失败的项目有各自的失败原因。尽管失败的原因各不相同，我们如果对这些项目进行由表及里的分析和总结，仍可以从中总结出在未来PLM项目实施过程中需要规避的风险和问题。倘如此，这些失败的项目仍不乏其积极的意义。否则是“后人哀之而不鉴之，亦使后人而复哀后人”， 丧失了这些项目带给我们的借鉴价值。
在研究失败项目产生的原因时，可以从项目集成管理，计划管理，成本管理，质量管理等项目管理的九大管理领域去着手分析。在这其中有一个非常重要的方面是风险管理。它包括：风险识别、风险分析、风险规划、风险应对策略等若干步骤。英文所述“We don’t go mountain climbing with a rope because we plan to fall， but we’d be all too grateful for the rope if we did.”正可以用来说明项目风险管理的重要性。作为PLM项目的管理者乃至项目的高层决策者，需要经常扪心自问：PLM项目风险管理，我们做得了到吗?
PLM 项目风险管理的重点不在于事后亡羊补牢的被动应对(当然接受风险带来的结果也是风险管理的对策之一)，而在于在项目执行的整个过程中，始终能对潜在的风险进行有效的掌握与控制：时刻关注风险的识别、分析、计划、记录、应对、乃至对所有能预见到风险的管理与跟踪等。其核心在于“Getting IT Before IT Gets You”(用现在时尚的话是：我们要把它搞定，而不是它把我们搞定)。这意味着在进行PLM项目时，也需要从项目生命周期的启动，规划，执行与控制，结案等阶段来安排项目的风险管理活动。本文也将从上述诸阶段来讨论PLM项目的风险管理工作。
PLM项目启动阶段-“不谋全局者，不足谋一域”
在PLM项目启动前，一个值得项目经理和项目高层重点关注的问题是：决定项目成败的诸多因素，我们考虑周详了吗?而对这些因素的识别，其实是项目管理过程中风险识别的过程。在这一过程中，通常可以从如下方面去对风险因素加以归类梳理：
1. 项目组织
PLM 系统的实施，其实质是企业业务变革与组织变革过程的一部分，因此识别企业业务变革与组织变革过程中会遇到的问题并加以处理，成了PLM项目风险管理重要的一部分内容。尽管所有的人都希望看到PLM项目“上下同欲”的结果，但由于PLM系统的推广与部署会涉及到企业业务的多个方面，不同干系人(stakeholder)的利益不尽相同，其在企业实际业务过程中关注的焦点也不尽相同，因此在项目执行过程中往往容易受到各种组织或人事因素的影响。当这种因素处置不当时，某些风险因素会逐步变成影响项目正常执行的问题。因此在项目启动之初建立起一套经项目高层决策者批准的高效运做的项目组织架构及附属的正常运做流程成了决定项目能否成功的一个重要方面。曾几何时，PLM项目组在为所提交的方案没有人签字确认而苦恼时;在为决定项目成败的数据准备工作停滞不前而绞尽脑汁时;在为用户接受测试(UAT)的测试人员似走马灯般难以固定而忧心忡忡时，其实首先应该想到的是：是否是PLM项目控制机制(Governance Model)及组织架构出了问题。项目组织带来的问题不仅会影响到项目组顾问方与客户方彼此之间的工作效率，在顾问方内部或客户方内部也容易出现政出多头，前后不一的问题。当这种情况发生时，通常会极大损害项目运作的效率，导致项目工期的拖期或成本的严重超支。
在规避项目组织先天不足对PLM项目带来的危害时，特别需要得到企业高层领导的切实有效的支持，从而建立起高效运作的PLM项目管理体系，在有些情况下甚至可以借鉴 “威权政治”的做法。惟有如此，才可以为PLM启动后项目的运作奠定坚实的基础。
2. 项目实施范围与预算
项目范围，预算和时间是制约项目执行的三个关键要素。当任何一种要素发生变化时，都会导致其它两个要素的变化。这是一个人所共知的项目管理常识。但在具体的项目执行过程中，却仍然会经常因为上述三个要素之间的冲突而影响或羁绊项目的正常执行。
这意味着，在项目启动之初需要对项目实施范围有着全面而又清晰的认识。但要真正做到这一点通常又是一件非常困难的事情。这主要是由于在项目启动之初在客户与实施顾问之间存在着PLM产品信息的不对称性和客户业务需求信息的不对称性。为规避该风险带来的问题，在项目实施之初，PLM实施客户不妨以同行业其它实施单位的成功案例作为标杆(Benchmark)，通过参考与本企业类似的成功企业的实施经验，并比照两企业的异同来确定本单位的实际需求范围;同时可以考虑吸纳那些有过类似行业成功经验的顾问组成项目团队(注意是真正有成功与失败两方面实施经验的顾问，而不是某些徒有其表的PLM“感念”专家或简历包装华丽的某些顾问。而甄别其间的差别其实是有章可循的。);此外还需要在项目启动之初确定客户与顾问彼此之间业务需求与PLM知识的知识传递计划(KT Plan)。从而有效保证上述知识不对称性对项目带来的致命影响，并基本做到在项目实施之初，客户与顾问团队之间能围绕项目实施的基准范围(Baseline Scope) 达成初步的一致。
3. 资源
为保证 PLM项目真正成功，需要保证在项目执行过程的各个阶段，能有恰当的具备特定能力的资源投入，因此在项目启动之初获得各方对所需资源进行支持的背书是极为重要的。在以往的项目案例中，作为客户方通常会在项目执行之初会对顾问的能力提出较高的要求，有时还会安排必要的面试或初步筛选。但在项目启动之初，客户方项目管理组时常会忽略对己方业务定义，数据准备，开发实现，用户接受测试乃至系统支持等方面资源的需求，从而在上述方面缺少必要的或完备的资源需求计划。由此带来的后果，要么是在规定的时限内，业务需求的准确定义无法完成;要么是未来系统上线时，关键的业务数据还无法进入到系统中，影响系统的真正切换;要么是项目结束顾问资源撤出后，双方项目组突然发现客户难以独立承担系统的调整或问题的处理工作并导致PLM系统推广部署的难度加大。实际上，在项目启动之初，项目经理在规划项目资源时，应该考虑项目所涉及到的全部所需资源，并为此制订在整个项目执行周期内所需的资源需求计划。在此基础上去分析各种可能潜在的资源风险，从而对资源风险进行有效管理和跟踪。这种资源的规划并不意味着在项目启动之初加以定义万事大吉，相反，项目经理需要在项目执行的各个阶段对涉及资源的风险不断地加以跟踪和管理，才有可能达到项目预期的目的。
4. 产品和技术
在PLM 项目启动之初，绝大多数客户对PLM产品和技术怀有浓厚的兴趣——这是天性使然：毕竟所有的客户都希望采用先进的技术来解决自己所面临的实际问题。但在关注先进产品和技术的同时，一定要考虑这些产品或技术是否与客户当前使用的现有产品相匹配，是否与自己的业务实际相匹配。一个典型的案例是：当客户引进 PLM产品新版本后，在项目实施的后期(系统实现阶段)突然发现客户自己的CAD版本无法与当前PLM实施版本相兼容，原来规划的所有CAD集成的计划都变成了泡影;已经发生的很多人力资源投入产生的结果也化为了乌有;部分项目目标也受到了影响，。与此相类似的另一个案例是，项目实施已经如火如荼地进行到后期阶段，客户方采购的关键服务器设备却始终没有到位，而终用户验证测试是在一台跟生产服务器迥异的测试服务器上进行的。这一方面导致整个项目的拖期，另外一方面在服务器到货后，所有的测试、问题修改工作需要在与新的服务器类似的测试环境中重新测试。于是导致系统交付时间延期和前期资源投入的浪费!因此在强调先进的技术或功能完善的产品时，需要重点考虑企业的实际IT架构和工具使用情况并在项目启动之初给出围绕这些内容的总体评价，从而据此选择适合企业IT发展规划的产品与技术。
