关于产品生命周期管理PLM项目的风险管理

-.z关于产品生命周期管理PLM工程的风险管理产品生命周期管理(ProductLifecycleManagement-PLM)系统已经在国内多家企业实施推广应用。其中既不乏系统推广效果显著，为企业开展直接助力的成功案例;更不乏工程实施过程跌宕起伏，工程超支或严重拖期的案例;还有工程过程轰轰烈烈，结果却无人问津，企业的巨额投入化为乌有的例子。成功的工程总是相似，失败的工程有各自的失败原因。尽管失败的原因各不一样，我们如果对这些工程进展由表及里的分析和总结，仍可以从中总结出在未来PLM工程实施过程中需要躲避的风险和问题。倘如此，这些失败的工程仍不乏其积极的意义。否则就是“后人哀之而不鉴之，亦使后人而复哀后人〞，丧失了这些工程带给我们的借鉴价值。在研究失败工程产生的原因时，可以从工程集成管理，方案管理，本钱管理，质量管理等工程管理的九大管理领域去着手分析。在这其中有一个非常重要的方面就是风险管理。它包括：风险识别、风险分析、风险规划、风险应对策略等假设干步骤。英文所述“Wedon’tgomountainclimbingwitharopebecauseweplantofall,butwe’dbealltoogratefulfortheropeifwedid.〞正可以用来说明工程风险管理的重要性。作为PLM工程的管理者乃至工程的高层决策者，需要经常扪心自问：PLM工程风险管理，我们做得了到吗?PLM工程风险管理的重点不在于事后亡羊补牢的被动应对(当然承受风险带来的结果也是风险管理的对策之一)，而在于在工程执行的整个过程中，始终能对潜在的风险进展有效的掌握与控制：时刻关注风险的识别、分析、方案、记录、应对、乃至对所有能预见到风险的管理与跟踪等。其核心在于“GettingITBeforeITGetsYou〞(用现在时尚的话就是：我们要把它搞定，而不是它把我们搞定)。这意味着在进展PLM工程时，也需要从工程生命周期的启动，规划，执行与控制，结案等阶段来安排工程的风险管理活动。本文也将从上述诸阶段来讨论PLM工程的风险管理工作。PLM工程启动阶段-“不谋全局者，缺乏谋一域〞在PLM工程启动前，一个值得工程经理和工程高层重点关注的问题是：决定工程成败的诸多因素，我们考虑周详了吗?而对这些因素的识别，其实就是工程管理过程中风险识别的过程。在这一过程中，通常可以从如下方面去对风险因素加以归类梳理：1.工程组织PLM系统的实施，其实质是企业业务变革与组织变革过程的一局部，因此识别企业业务变革与组织变革过程中会遇到的问题并加以处理，就成了PLM工程风险管理重要的一局部内容。尽管所有的人都希望看到PLM工程“上下同欲〞的结果，但由于PLM系统的推广与部署会涉及到企业业务的多个方面，不同干系人(stakeholder)的利益不尽一样，其在企业实际业务过程中关注的焦点也不尽一样，因此在工程执行过程中往往容易受到各种组织或人事因素的影响。当这种因素处置不当时，*些风险因素就会逐步变成影响工程正常执行的问题。因此在工程启动之初建立起一套经工程高层决策者批准的高效运做的工程组织架构及附属的正常运做流程就成了决定工程能否成功的一个重要方面。曾几何时，PLM工程组在为所提交的方案没有人签字确认而苦恼时;在为决定工程成败的数据准备工作停滞不前而绞尽脑汁时;在为用户承受测试(UAT)的测试人员似走马灯般难以固定而忧心忡忡时，其实首先应该想到的是：是否是PLM工程控制机制(GovernanceModel)及组织架构出了问题。工程组织带来的问题不仅会影响到工程组参谋方与客户方彼此之间的工作效率，在参谋方内部或客户方内部也容易出现政出多头，前后不一的问题。当这种情况发生时，通常会极大损害工程运作的效率，导致工程工期的拖期或本钱的严重超支。在躲避工程组织先天缺乏对PLM工程带来的危害时，特别需要得到企业高层领导的切实有效的支持，从而建立起高效运作的PLM工程管理体系，在有些情况下甚至可以借鉴“威权政治〞的做法。惟有如此，才可以为PLM启动后工程的运作奠定坚实的根底。2.工程实施*围与预算工程*围，预算和时间是制约工程执行的三个关键要素。当任何一种要素发生变化时，都会导致其它两个要素的变化。这是一个人所共知的工程管理常识。但在具体的工程执行过程中，却仍然会经常因为上述三个要素之间的冲突而影响或羁绊工程的正常执行。这意味着，在工程启动之初就需要对工程实施*围有着全面而又清晰的认识。但要真正做到这一点通常又是一件非常困难的事情。这主要是由于在工程启动之初就在客户与实施参谋之间存在着PLM产品信息的不对称性和客户业务需求信息的不对称性。为躲避该风险带来的问题，在工程实施之初，PLM实施客户不妨以同行业其它实施单位的成功案例作为标杆(Benchmark)，通过参考与本企业类似的成功企业的实施经历，并比照两企业的异同来确定本单位的实际需求*围;同时可以考虑吸纳那些有过类似行业成功经历的参谋组成工程团队(注意是真正有成功与失败两方面实施经历的参谋，而不是*些徒有其表的PLM“感念〞专家或简历包装华美的*些参谋。而甄别其间的差异其实是有章可循的。);此外还需要在工程启动之初就确定客户与参谋彼此之间业务需求与PLM知识的知识传递方案(KTPlan)。从而有效保证上述知识不对称性对工程带来的致命影响，并根本做到在工程实施之初，客户与参谋团队之间就能围绕工程实施的基准*围(BaselineScope)达成初步的一致。3.资源为保证PLM工程真正成功，需要保证在工程执行过程的各个阶段，能有恰当的具备特定能力的资源投入，因此在工程启动之初获得各方对所需资源进展支持的背书是极为重要的。在以往的工程案例中，作为客户方通常会在工程执行之初就会对参谋的能力提出较高的要求，有时还会安排必要的面试或初步筛选。但在工程启动之初，客户方工程管理组时常会忽略对己方业务定义，数据准备，开发实现，用户承受测试乃至系统支持等方面资源的需求，从而在上述方面缺少必要的或完备的资源需求方案。由此带来的后果，要么是在规定的时限内，业务需求的准确定义无法完成;要么是未来系统上线时，关键的业务数据还无法进入到系统中，影响系统的真正切换;要么是工程完毕参谋资源撤出后，双方工程组突然发现客户难以独立承当系统的调整或问题的处理工作并导致PLM系统推广部署的难度加大。实际上，在工程启动之初，工程经理在规划工程资源时，就应该考虑工程所涉及到的全部所需资源，并为此制订在整个工程执行周期内所需的资源需求方案。在此根底上去分析各种可能潜在的资源风险，从而对资源风险进展有效管理和跟踪。这种资源的规划并不意味着在工程启动之初加以定义就万事大吉，相反，工程经理需要在工程执行的各个阶段对涉及资源的风险不断地加以跟踪和管理，才有可能到达工程预期的目的。4.产品和技术在PLM工程启动之初，绝大多数客户对PLM产品和技术怀有浓厚的兴趣——这是天性使然：毕竟所有的客户都希望采用先进的技术来解决自己所面临的实际问题。但在关注先进产品和技术的同时，一定要考虑这些产品或技术是否与客户当前使用的现有产品相匹配，是否与自己的业务实际相匹配。一个典型的案例是：当客户引进PLM产品最新版本后，在工程实施的后期(系统实现阶段)突然发现客户自己的CAD版本无法与当前PLM实施版本相兼容，原来规划的所有CAD集成的方案都变成了泡影;已经发生的很多人力资源投入产生的结果也化为了乌有;局部工程目标也受到了影响，。与此相类似的另一个案例是，工程实施已经如火如荼地进展到后期阶段，客户方采购的关键效劳器设备却始终没有到位，而最终用户验证测试是在一台跟生产效劳器迥异的测试效劳器上进展的。这一方面导致整个工程的拖期，另外一方面在效劳器到货后，所有的测试、问题修改工作需要在与新的效劳器类似的测试环境中重新测试。于是导致系统交付时间延期和前期资源投入的浪费!因此在强调先进的技术或功能完善的产品时，需要重点考虑企业的实际IT架构和工具使用情况并在工程启动之初就给出围绕这些内容的总体评价，从而据此选择适合企业IT开展规划的产品与技术。PLM工程方案阶段-“先胜而后求战〞参与过PLM工程的工程组成员都十分清醒地意识到工程进度方案是工程管理的一个关键指标。但这并不意味者许多PLM工程在工程进度方案方面可以提交一份哪怕是结果尚可的答卷。究其原因，其实在于真正的工程方案决非仅仅是单纯的时间进度管理，工程的实际进度其实更多地应该被视为工程管理方方面面的一个输出结果。在缺乏对工程实施相关领域的工作内容进展管理的情况下，如果仍旧希望工程还能在方案方面有根本令人满意的结果，则该希望其实无疑是不切实际的。墨菲定律所述“如果坏事有可能发生，不管这种可能性多么小，它总会发生，并引起最大可能的损失〞正是对工程方案进度发生拖期现象最好的诠释。当然这并不是说我们对工程进度方案管理束手无措，相反我们通过对工程集成管理，质量管理，沟通管理，本钱管理等9大领域未来会发生的问题进展识别，预测，分析，并在此根底上制订行之有效的应对策略，然后对这些策略进展有效管理、对已出现的问题采取必要的处置措施后，我们才可以真正对工程方案，本钱，*围等内容进展有效的控制。因此我们在工程启动阶段总结得到的工程各种风险的分析后，一个重要的工作，就是分析风险的影响，确定风险的等级，在此根底上我们就可以制订必要的风险躲避方案。从而真正在该阶段做到“先胜而后求战〞。这构成工程方案阶段的一个工作重点。这要求我们需要针对工程启动阶段总结得到的各种风险进展分析，此时不再单纯地分析风险的影响和发生的可能性并利用FMEA方法来确定各种风险的优先级，更重要的就是要针对那些高级别的风险来制订相应的应对策略或方案。1.工程组织在PLM工程的方案阶段，必须从工程组织方面针对围绕工程控制机制(GovernanceModel)发现的潜在风险建立必要的应对策略和跟踪管理方案。需重点考虑如下假设干问题的风险管理方案：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)在风险处置过程中，由于原来风险管理方案中具体风险应对策略的欠缺，导致风险处置不力。而此时如果工程组得不到有力的支持与协助，则给工程管理层带来风险管理的严重挫折感。故此工程管理层难以再投时间和精力在工程风险的管理上。凡此种种，无不是执行层面风险管理“知易行难〞的具体表达，其造成的结果自然是工程管理方案束之高阁。事前风险管理又变化为事后亡羊补牢式的管理。而这又导致客户和实施参谋团队双方都不得不投入更多的时间、人力、物力和财力去化解危机，最终导致事倍功半的消极结果。解决“知易行难〞问题的最好方法其实也是最简单的方法，其实就是采用RISKLOG的方式(也叫RISKREGISTER)对所有已确认的风险进展记录，并定期给出分析从而确定各风险的优先级别，然后对每个风险条目给出建议的处置方案、负责人员、希望解决的完成时间。同时对识别出的新的风险及时记录在案，而对可以关闭的风险，则标记其为“已关闭〞、同时给出关闭确实切时间和风险关闭确实认人。需要指出的是：任何工程成员包括工程经理，在多项任务缠身，必须在任务之间进展取舍时，往往主要精力会关注已经火烧眉毛需要迫切解决的问题，而对于未来才可能发生的风险，会倾向于采用绕过去走捷径的做法。而这势必造成未来有更多紧迫的问题需要解决。其实这种关注眼前任务的做法是人们在压力面前采取的非常自然的一种应对策略。尽管不是工程风险管理中期待看到的做法，但却是大多数人的天性。这一天性尽管无可后非，但在工程风险管理过程中，工程管理层应该予以充分的认识，并在此根底上对其进展有效的躲避。为此，从工程组织的角度建立日常规*的工程风险管理机制(定期会议/沟通/通报等方式)就成了极为重要的工作了。这样可以通过组织的行为去防止个人行为中的薄弱环节，实现组织优势与个人优势的恰当结合，并以组织行为去催促工程管理层能持续不断地对工程各种风险进展有效的管理。PLM工程结案-“行百里者半九十〞工程结案通常会带来一种错觉，似乎只要能把结案会一开，客户方和工程实施参谋方一切就都万事大吉了。但真正做过工程的工程经理都知道，工程结案其实是工程最危险的阶段：此时所有的系统内容都已经展示给最终用户，而此阶段产生的问题更需要以尽可能快的速度予以响应或解决。但此时无论在时间上还是经费上留给工程组的空间已经非常有限。围绕工程结案的工作需要考虑结案前系统上线过程的风险，还需要考虑工程结案后系统运行维护期间可能遇到的风险。但无论是结案前还是结案后的风险都必须事先做好风险识别、分析、制订风险管理方案和对风险加以处置等工作。而如果向前追溯的话，许多应对与规划工作必须在工程启动与方案阶段就加以完成。1.工程结案前：工程结案前的系统上线工作是工程能否成功的重点：处置不当，会导致工程发生严重的拖期乃至于工程的失败。此时需要重点考虑：1)对应既定方案的系统是否与企业的实际业务过程关联在一起，如果没有，工程组应对的策略是什么;2)相关的历史数据准备工作是否完成以及所准备数据的正确性是否通过恰当的评估;3)正式生产效劳器是否已经准备就绪，并经过必要的性能调优;4)是否建立起系统切换的领导机构和问题处理处理机制并经过工程高层管理机构的批准;5)如何安排对最终用户进展必要的培训，如何对培训效果进展必要的考核;6)如何对用户验证测试过程中发现的问题制订必须的处置策略;7)正式系统上线是否经过反复的预演，并根据预演的结果拟订最终确认无误、切实可行的上线切换方案;8)预留的系统切换时间是否足够(对涉及需向ERP系统发数据的情况，此条尤为重要);9)在发生不可预见的问题时，工程组的备份方案是什么2.工程结案后：