产品生命周期管理项目风险管理
作者: 来源: 文字大小:[大][中][小]
品生命周期管理(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发展规划的产品与技术。
PLM项目计划阶段-“先胜而后求战”
参与过PLM项目的项目组成员都十分清醒地意识到项目进度计划是项目管理的一个关键指标。但这并不意味者许多PLM项目在项目进度计划方面可以提交一份哪怕是结果尚可的答卷。究其原因，其实在于真正的项目计划决非仅仅是单纯的时间进度管理，项目的实际进度其实更多地应该被视为项目管理方方面面的一个输出结果。在缺乏对项目实施相关领域的工作内容进行管理的情况下，如果仍旧希望项目还能在计划方面有基本令人满意的结果，则该希望其实无疑是不切实际的。墨菲定律所述“如果坏事有可能发生，不管这种可能性多么小，它总会发生，并引起最大可能的损失” 正是对项目计划进度发生拖期现象最好的诠释。
当然这并不是说我们对项目进度计划管理束手无措，相反我们通过对项目集成管理，质量管理，沟通管理，成本管理等9大领域未来会发生的问题进行识别，预测，分析，并在此基础上制订行之有效的应对策略，然后对这些策略进行有效管理、对已出现的问题采取必要的处置措施后，我们才可以真正对项目计划，成本，范围等内容进行有效的控制。因此我们在项目启动阶段总结得到的项目各种风险的分析后，一个重要的工作，就是分析风险的影响，确定风险的等级，在此基础上我们就可以制订必要的风险规避计划。从而真正在该阶段做到“先胜而后求战”。这构成项目计划阶段的一个工作重点。
这要求我们需要针对项目启动阶段总结得到的各种风险进行分析，此时不再单纯地分析风险的影响和发生的可能性并利用
FMEA方法来确定各种风险的优先级，更重要的就是要针对那些高级别的风险来制订相应的应对策略或计划。
1. 项目组织
在PLM项目的计划阶段，必须从项目组织方面针对围绕项目控制机制(Governance Model)发现的潜在风险建立必要的应对策略和跟踪管理计划。需重点考虑如下若干问题的风险管理计划：
1) 项目能否得到高层领导的关注，如何保证在项目重大问题发生时，能持续得到高层领导必要与恰当的支持;
2) 如何引导客户各部门对项目目标和范围有着相同的认识和期望，项目组如何跟相关部门建立起密切合作的关系;
3) 项目的沟通机制和签字确认机制如何以书面的方式为各相关部门所接受;
4) 对项目各阶段历程碑的达成标准，如何保证各方都有着清晰的共识;
5) 围绕项目问题的处理机制如何以可行的方式持续地被项目各方所接受
2. 项目实施范围与预算
在项目进入到实施阶段前，项目管理组需要运用“二十/八十原则”把握项目的真正业务目标和拟解决的业务问题。这意味着整个项目需要有所为有所不为，取舍的原则一定要取决于引入PLM系统究竟是要解决何种业务问题，在此基础上再努力考虑如何避免实施范围的渐变与扩大以及由此引起的项目预算的超支。在此过程中，项目组需要重点考虑如下问题：
1) 项目关注的重点问题恰恰就是项目最终用户关注的业务问题，在两者存在偏差时，如何使前者与后者相一致;
2) 实施顾问如何能在规定的时间内了解企业的业务过程，并据此定义项目的实施方案;
3) 客户项目组如何能在项目需求调研和方案定义前，能了解系统的功能，术语和PLM项目实施的成功经验，从而保证与实施顾问进行交流时，能有更多的共同语言;
4) 客户团队与实施顾问团队彼此围绕项目范围发生认识上的偏差时，通过怎样的流程与机制消弭这样的偏差，或者实现彼此意见在更高层次上的统一;
5) 如何把项目的实施方案转化成客户的实际业务过程，既实现方案与拟解决业务问题的统一，同时又实现项目范围的最终固化
3. 资源
PLM 项目成败的一个重要方面在于关键资源是否到位。这一资源既是指实施顾问方合格的资源是否到位(尤其是实施顾问方合格项目经理和业务顾问是否到位)，更是指客户必要的资源是否到位。由于资源的需求涉及项目的整个过程，因此围绕资源的风险管理计划就显得异乎寻常的重要。在这一过程中与如下问题相关的风险处置措施需要项目组予以高度的重视：
1) 熟悉产品数据(BOM信息和CAD数据等)的数据准备组如何保证按照项目组既定的时间计划开展工作;
2) 如何保证熟悉产品研发全过程同时熟悉PLM系统的客户业务专家(对熟悉PLM系统这一要求，可以通过短期培训来实现)同项目组一道完成业务方案定义与审核工作;
3) 如何保证熟悉
产品开发的客户业务人员能在需要完成用户接受测试时，按照测试计划参与到测试过程中，并确认测试的最终结果;
4) 如何通过资源的调动保证业务方案能落实到企业实际的业务过程中;
5) 如何保证客户的技术资源能参与到系统实现的整个过程中，从而实现技术知识的有效转移;并建立起客户自己的系统支持与维护团队;
6) 如何保证客户能建立起一支向最终用户进行PLM知识传递和培训的团队
4. 产品与技术
如前所述，在PLM项目中，产品与技术是客户和实施顾问团队都十分关注的一个重点内容，但这并不意味着在这方面我们能遇到比其它方面更少的问题。而当围绕产品与技术方面的问题发生时，如果处置不力，会立即变成一个引人注目的问题。这意味着项目组仅仅关注先进的技术和产品，关注已经发生的产品和技术问题还是远远不够的，更重要的是预见未来可能发生的产品问题和技术问题，从而实现以管理压力换时间节点压力，或以管理压力换成本压力的突破。在项目计划阶段，围绕产品与技术风险需重点关注的问题如下：
1) 如何避免或降低采用最新产品版本带来的风险(俗称的第一个吃螃蟹的风险);
2) 如何处置引进的PLM产品版本与现有软件产品可能存在的系统冲突问题;
3) 如何确保测试用系统与上线用系统的可类比性，以及两系统之间存在差异时，项目组采取怎样的解决措施;
4) 如何确保硬件性能可以满足企业未来若干年业务发展的要求，同时硬件采购周期能与项目进展周期相匹配;
5) 如何保证系统软件配置管理(代码管理措施)的有效性和正确性;
6) 如何确保系统的开发与调整能适应系统未来升级的要求和企业未来业务调整的需求;
对有PLM实施经验的用户，很容易理解上述围绕项目组织/范围与预算/资源/技术与产品等方面在项目计划阶段制订风险管理计划的重要性。只有针对上述方面可能发生的问题建立起必要的应对计划和策略，才有可能做到事前风险管理，而不是事后问题管理。做到未雨绸缪，而不是亡羊补牢。尽管亡羊补牢也是风险管理的策略之一，但PLM项目管理强调的更多的是在未雨绸缪的基础上，再做亡羊补牢抑或其它更积极主动的决策。
PLM项目执行与控制阶段-“非知之艰，行之惟艰”
在项目启动阶段，对项目风险进行了识别分析;以此为基础，项目规划阶段制订了项目风险管理计划，从理论上讲，项目在执行与控制阶段，只要严格按照项目风险管理计划来开展工作就应该取得令人满意的结果。但在项目实际运作过程中，这恰恰是最容易出问题的阶段。究其原因可以总结如下：
1) 项目执行是一个动态的过程，一些原本存在的风险可能会随着其存在基础的消失而湮灭;一些原本低优先级别的风险会因其发生的可能性或带来影响的变化而变成高优先级别的风险;一些原本不存在的风险也会随之而产生。这无疑加大了风险管理的难度;
2) 项目管理组在项目执行过程中通常会陷入到项目日常管理的琐碎工作中。项目执行过程已经把项目经理折磨得苦不堪言，项目经理纵有控制未来风险的强烈愿望，无奈项目执行自身的压力导致其必须先着手眼前的项目布局，至于未来项目中潜在的风险，权且不闻/不问才好。当然项目经理还是会经常想想未来潜在的风险的，但应对策略是且等风险变成问题找上门再说;
3) 在风险处置过程中，由于原来风险管理计划中具体风险应对策略的欠缺，导致风险处置不力。而此时如果项目组得不到有力的支持与协助，则给项目管理层带来风险管理的严重挫折感。故此项目管理层难以再投时间和精力在项目风险的管理上。
凡此种种，无不是执行层面风险管理“知易行难”的具体体现，其造成的结果自然是项目管理计划束之高阁。事前风险管理又变化为事后亡羊补牢式的管理。而这又导致客户和实施顾问团队双方都不得不投入更多的时间、人力、物力和财力去化解危机，最终导致事倍功半的消极结果。
解决“知易行难”问题的最好办法其实也是最简单的办法，其实就是采用RISK LOG的方式(也叫RISK REGISTER)对所有已确认的风险进行记录，并定期给出分析从而确定各风险的优先级别，然后对每个风险条目给出建议的处置计划、负责人员、希望解决的完成时间。同时对识别出的新的风险及时记录在案，而对可以关闭的风险，则标记其为“已关闭”、同时给出关闭的确切时间和风险关闭的确认人。
需要指出的是：任何项目成员包括项目经理，在多项任务缠身，必须在任务之间进行取舍时，往往主要精力会关注已经火烧眉毛需要迫切解决的问题，而对于未来才可能发生的风险，会倾向于采用绕过去走捷径的做法。而这势必造成未来有更多紧迫的问题需要解决。
其实这种关注眼前任务的做法是人们在压力面前采取的非常自然的一种应对策略。尽管不是项目风险管理中期待看到的做法，但却是大多数人的天性。这一天性尽管无可后非，但在项目风险管理过程中，项目管理层应该予以充分的认识，并在此基础上对其进行有效的规避。为此，从项目组织的角度建立日常规范的项目风险管理机制(定期会议/沟通/通报等方式)就成了极为重要的工作了。这样可以通过组织的行为去避免个人行为中的薄弱环节，实现组织优势与个人优势的恰当结合，并以组织行为去督促项目管理层能持续不断地对项目各种风险进行有效的管理。
PLM项目结案-“行百里者半九十”
项目结案通常会带来一种错觉，似乎只要能把结案会一开，客户方和项目实施顾问方一切就都万事大吉了。但真正做过项目的项目经理都知道，项目结案其实是项目最危险的阶段：此时所有的系统内容都已经展示给最终用户，而此阶段产生的问题更需要以尽可能快的速度予以响应或解决。但此时无论在时间上还是经费上留给项目组的空间已经非常有限。
围绕项目结案的工作需要考虑结案前系统上线过程的风险，还需要考虑项目结案后系统运行维护期间可能遇到的风险。但无论是结案前还是结案后的风险都必须事先做好风险识别、分析、制订风险管理计划和对风险加以处置等工作。而如果向前追溯的话，许多应对与规划工作必须在项目启动与计划阶段就加以完成。
1. 项目结案前：
项目结案前的系统上线工作是项目能否成功的重点：处置不当，会导致项目发生严重的拖期乃至于项目的失败。此时需要重点考虑：
1) 对应既定方案的系统是否与企业的实际业务过程关联在一起，如果没有，项目组应对的策略是什么;
2) 相关的历史数据准备工作是否完成以及所准备数据的正确性是否通过恰当的评估;
3) 正式生产服务器是否已经准备就绪，并经过必要的性能调优;
4) 是否建立起系统切换的领导机构和问题处理处理机制并经过项目高层管理机构的批准;
5) 如何安排对最终用户进行必要的培训，如何对培训效果进行必要的考核;
6) 如何对用户验证测试过程中发现的问题制订必须的处置策略;
7) 正式系统上线是否经过反复的预演，并根据预演的结果拟订最终确认无误、切实可行的上线切换计划;
8) 预留的系统切换时间是否足够(对涉及需向ERP系统发数据的情况，此条尤为重要);
9) 在发生不可预见的问题时，项目组的备份方案是什么
2. 项目结案后：
以往项目执行过程中，一个常见的误区在于：项目结案会一开，所有的事情就万事大吉了。其实项目的结案只能标记着项目执行的结束，而不能说PLM项目就一定能平稳地投入到后续运行中了。系统的维护和技术支持工作是一个持续不断的过程。对一些成熟的客户，自己的队伍在项目结束时，就已经可以承担起系统正常运维的工作了，而在项目结束后，通过正常渠道延展客户方与顾问方的支持服务关系也不失为一种可行的做法。此时需要重点考虑如下问题：
1) 客户是否具备独立支持系统正常运作的能力和做系统改进调整的能力，如果没有(倘如此，一定是在前期的风险管理中已经出现问题了)，如何在短期具备这样的能力;
2) 基于已有的运行维护与支持能力，是否建立了一套行之有效的运行维护的管理过程，避免因系统未及时备份而带来的严重损失(知易行难，很多企业在这方面都有过惨痛的教训);
3) 如何保证在客户遇到涉及产品本身问题，而不是开发订制问题时，能够从原厂商处得到必要的技术支持(一个典型案例：系统在正常运行1年半后，基于成本的考虑客户没有再购买必要的技术支持服务，当他们遇到系统问题时，所需的花费要比及早购买技术支持的花费大了许多，因为它包括了系统宕机带来的实际损失)
这里有一条重要的现象需要指出：系统维护的早期正常投入，其代价通常会远比问题发生后再加以解决所带来的成本低得多。因此在项目结案后，客户的系统运维支持部门需要时刻提醒自己：未来有一天当系统发生问题时，我们的对策是什么以及如何才能把对最终用户的影响降到最低?这其实仍然是风险管理手段在项目结束后的继续应用。
结语
回到本文开头那句英文“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项目的风险管理何尝不是我们登顶企业信息化巅峰时的救命绳索呢?