#星空云诊所#:信息化项目风险管理 -风险应对措施及范围风险管理

栏目:云星空知识作者:金蝶来源:金蝶云社区发布:2024-09-16浏览:1

#星空云诊所#:信息化项目风险管理
                   -风险应对措施及范围风险管理

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

一、前言

上篇介绍信息化项目风险管理的基本概念及管理流程,让大家对信息化项目风险管理有了初步的认识,本篇将从风险的应对策略讲起,并对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.     风险保留

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

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


#星空云诊所#:信息化项目风险管理 -风险应对措施及范围风险管理

风险处置办法及信息化项目范围风险管理一、前言上篇介绍信息化项目风险管理的基本概念及管理流程,让大家对信息化项目风险管理有了初步的认...
点击下载文档
确认删除?
回到顶部
客服QQ
  • 客服QQ点击这里给我发消息