风险处置办法及信息化项目范围风险管理

一、前言

上篇介绍信息化项目风险管理的基本概念及管理流程，让大家对信息化项目风险管理有了初步的认识，本篇将从风险的应对策略讲起，并对ERP实施常见风险中影响最大的风--范围风险进行阐述，主要讲述范围风险的识别，并对风险的应对及处置做相应的介绍。

二、  风险应对策略

风险应对策略一般分为四种：风险规避、风险减轻、风险转移、风险保留。

1.      风险规避

风险规避是公司经过评估，主动放弃风险行为，完全避免特定的损失风险。对于信息化项目来说，就是对自己感觉不熟悉、风险很大的领域，觉得失败的概率和失败带来的损失远超公司可接受的范围，采取主动放弃不做，规避此风险。目前信息化项目售前阶段，总部的合同审批时，也会对一些项目采取规避策略，不允许签署。

风险规避是要经过多部门联合评审后，管理层来决策的，是有一套严密的体系的。如果采取简单的风险回避，那是一种消极的风险处理办法，因为公司在放弃风险行为的同时，也放弃了潜在的项目收益或切入某一市场的机会。

2.     风险减轻

风险减轻是我们经常用到的策略，也是一种积极的应对策略。风险减轻不是放弃风险，而是要制定应对预案并按预案采取措施来管控风险。

风险减轻一般从两个方面着手，一是在事前控制，采取一系列的预防措施，降低风险发生的概率；二是风险发生已不可避免，通过实现设定的应急预案，把风险发生的影响程度降到最低，减少对项目范围、进度、成本、资源等的影响。

3.     风险转移

风险转移是指通过合同或保险，将风险转移给其他方承担的行为。通过风险转移可大大降低项目的风险程度。

信息化项目风险转移基本没有通过保险的方式转移风险，一般都是通过合同的方式。比如在多方协作项目中，第三方软硬件带来的风险、甲方数据质量风险等，都需要通过合同来约定，避免他方的问题导致我方项目推进风险的发生。还有，对自己不熟悉的领域，采取外包的方式，也是一种风险转移的策略。

4.     风险保留

风险保留，也就是风险承担。如果风险发生，我方将承受风险，也就类似于很多项目的风险储备金或储备成本。在公司目前的预算体系中，按比例提取的风险成本就是类似的情况，我们实际上很多项目在交付过程中，对于需求超出SOW在5%人天内的，有些项目也采取了风险保留也就是风险承受的策略。

三、  信息化项目常见风险之范围风险

范围风险是信息化项目风险类别中影响最大、发生概率较高的风险，当范围失控时，我们的进度、成本都成倍数的延迟及增加。因此，范围风险是我们项目从商机开始至验收交付一直要识别、更新及关注的风险类别。我们按项目开展的时间维度来对范围风险进行以下解读：

1.      商机至签约：

（1）组织范围不明确：对于多组织客户，一种情况是在调研及方案制作过程中，仅以客户的业务为主线，未明确客户的实施主体到底有多少，哪些业务要在哪些组织实施，导致在蓝图及上线阶段组织数量及各组织的应用范围扩散，成本大幅增加，进度拖延；另一种情况是对一些快速扩张的企业，在签约前已明确了组织及业务范围，但在实施过程中，客户又成立了新的分子公司，而在当初约定中没有对新成立的组织做明确的界定，导致组织范围的扩张；

（2）实施业务范围不明确：在签约前的调研及方案制作过程中，未能充分理解客户的价值主张，解决方案部分内容靠自己的经验及猜想，且对业务方案的描述过于粗犷，对后期实施蓝图不能形成有效的支撑，售前与实施交付完全脱节，导致交付过程业务范围难以界定清楚，项目在实施过程中新增需求较多，业务范围失控；

（3）开发范围不明确：部分项目未做业务需求与产品差异分析，或仅流于形式，很多标准产品不能满足的功能未识别出来，或对客户化开发需求理解不足，部分项目开发需求仅明确到模块级，具体做到什么程度没有界定；

2.     进场至上线前：

（1）实施业务范围扩散：这个阶段造成范围扩散的原因一般在两个时间点，首先，入场交接阶段，实施和售前的交接不充分，实施方案及策略未有效承接售前解决方案，项目实际的交付范围通过实施调研后来确定，而不是渐进明细的继承，导致实际要交付的业务范围超出合同签约的人天评估的假定范围。

其次，项目蓝图设计阶段，项目蓝图过于简单甚至有的项目没有一份完整的蓝图，只能看到几个不怎么规范的流程图，在后续的系统构建及测试、上线阶段，随着系统的落地推推进，源源不断的新的需求接踵而至，项目陷入泥潭，阶段性成果难以得到确认，项目进度和成本因范围的不确定而失控。

（2）开发范围扩散：这个阶段造成范围扩散的原因一般也在两个时间点，首先，开发人员与售前、实施沟通不充分，根据自己的理解进行需求的理解，且缺乏阶段性的沟通及确认，导致范围失控（扩散或返工）；

其次，是开发与实施、客户沟通较少，且沟通工具、内容均达不到明确需求的标准（不符合详细设计说明书，内容太泛），双方理解出现偏差，导致范围失控（扩散或返工）。

3.     上线至验收：

这阶段本合同和SOW内的需求一般都完成了，随着客户对系统应用的熟练，一些超出本合同及SOW范围的需求就浮现了，一般有三类，一类是各模块更深入的应用，第二类是易用性的改善需求，第三类是报表类需求，这阶段如果继续闷头做事，而不去梳理合同、SOW并做此项目收尾相关的工作，那验收又会遥遥无期。

四、  范围风险的应对措施

1.      风险规避

这种情况一般出现在咱们应对不熟悉的领域，特别是一些产品匹配度太低的行业，比如石材加工、服装鞋帽等，因为经验及积累不足，对行业的理解度不足，导致在售前及实施规划阶段，难以摸清楚客户的全部需求，如果冒然开始，必然会陷入泥潭，需求随着项目推进，越来越多且后期不可预估，进入两难的境地，所以这类情况，建议一般采取风险规避的措施，而不是什么合同咱都敢签。

2.     风险减轻

这是最常用的，但也是多数项目做的最不足的，这里建议首先咱们大项目需要建立起风险管理体系，最起码要以SOW和WBS等为主，识别风险并登记在册进行跟踪并采取减轻概率或减轻影响度的措施，SOW关于产品版本、组织范围、实施范围、客户化开发范围要界定清楚，而不是为了审批而做文件；第二，严格按照方法论模板和步骤进行关键交付物的撰写，比如蓝图、详细设计说明书等；第三，将确认沟通的颗粒度细化，不能只等大阶段的确认。第四，严格按照SOW及合同履约，对于超范围的按约定进行PCR变更或登记在册。第五，对于有些需求前期确实无法确定，但识别可能大概率发生需求增加风险的问题，咱们尽量签署一个预备项，例如就叫优化或深化应用，预估人天并签署合同，多退少补，减轻可能带来的范围扩大带来的成本增加。第六，各大阶段的交接要无缝，售前与实施、实施与开发。

3.     风险转移

范围风险转移，咱们目前用的最多的是外包或直签。即对咱们不熟悉或不专业的领域，不如家具行业、设备管理领域等，转包给第三方，已达到风险转移的目的。

4.     风险保留

   风险保留在范围这块，主要应对的是成本可接受范围内的一些需求增加，比如简单的几张报表，简单的一些易用性的问题，一般我们就接受了这类范围扩大带来的人天的增加，建议慎用风险保留策略。

   本篇主要讲述了信息化项目风险管理的应对措施，并就项目中影响最大的范围风险进行了介绍，后期将对信息化项目的其他风险进行解读。