ERP实施项目中的风险管理(翻译材料)

ERP实施项目中的风险管理Henri Latvanen and Reetta Ruusunen目录1.简介 (2)2.风险管理 (3)2.1风险管理的社会技术模型 (4)3.过程实施 (6)3.1项目流程 (6)3.2不同阶段的问题 (7)3.2.1阶段1定义问题 (7)3.2.2阶段2：识别目前状况 (8)3.2.3阶段3：优化未来系统蓝图 (8)3.2.4阶段4：建造和测试 (9)3.2.5一般性问题 (9)4.解决方案 (10)4.1避免风险的实际策略 (10)4.2 制作模型 (12)5结论 (13)6参考文献 (14)7附录 (16)1.简介近年来，有可观数量的组织已经采用了资源管理计划系统。

更多的组织正花费巨资来实施这些系统。

这些组织希望通过功能和业务单元的整合及软件所蕴含的最佳实践来取得竞争优势。

但是，报道出来的结果却是混乱的。

因为ERP是一个宽泛的技术，不同的厂商不同的用户对它都有不同的定义。

Fred Ungerer是SAP美国负责工业过程解决方案的主管。

他说，公司把ERP看成是整个企业从物流系统到财务系统的连接。

它包括了销售，经过生产的订单流程以及资源计划。

通过收集，整理，分析业务数据，公司可以改进他们的业务系统，组织结构，工作习惯和最根本的账本底线。

但是ERP系统只是一种使ERP 过程高效率并有效发挥功能的机制。

ERP系统的益处包括了横跨企业的一整套交流工具，并且整个公司都用同一套数字的工具。

它益处的范围取决于它深入组织的程度和公司是否能够持续更新他们的系统。

ERP通过建设像高级计划和客户关系管理这样的企业级的解决方案来为企业提供一个支柱，从而强化了公司能力。

ERP同时也提供了数据的一致性和数据的全球化视角。

ERP系统必须能够被分块实施，并且它们一旦运行就需要具有灵活性，而不仅仅是在实施阶段。

和工程及工厂应用软件的互操作性也是ERP系统发挥效用的关键。

ERP系统既可以设计成客户定制软件也可以购买现成的标准解决方案。

客户定制软件的开发一般是昂贵的，并且经常遭到不确定性的麻烦，比如选择合适的开发工具，开发周期，和评估成本有关的困难。

同样的，标准ERP系统比如SAP R/3，Oracle和PeopleSoft都有他们的缺点。

巨大的存储需求，网络条件和高层培训都是经常被提及的ERP问题。

和软件实施过程相关的流程再造的范围和客户化任务是导致ERP不满意的主要原因。

有人曾经统计过客户花在ERP实施和相关服务上的费用是购买软件许可证的3到7倍。

购买标准系统的人都必须认识到，因为标准系统是对每个人都是可用的，任何优势都必须来自于实施的质量。

但是，经验调查显示有一半到三分之二的信息系统项目失败了。

大部分ERP 系统软件的安装在可衡量的财务收益上费用大于回报。

美国曾有一个研究，研究了营业额大于5亿美元并且投资于ERP项目的公司。

只有10%的项目准时交货。

55%的项目延时或超预算。

35%被取消。

那些延后和超预算的项目，平均比计划时间延迟230%，平均比初估预算误差178%。

中东欧的Deloitte 和Touche另一项的有关大型信息系统实施项目成功和失败原因的研究得到如下结果：成功---目标完全实现----------------23%失败---终端用户不愿意接受改变------26%失败---没有熟练员工----------------22%失败---预算------------------------35%失败---公司的官僚作风--------------14%失败---没有充分的培训--------------15%失败---没有好的交流----------------17%这一章节的目标是介绍ERP实施项目的风险，给经理们以如何处理风险的建议。

我们相信这将帮助经理们完全理解风险的源头和它牵涉到的方面。

2.风险管理古典决策理论中，风险的概念反映了可能结果的分布状态的变化，它们的喜好的变化，和它们的主观价值的变化（1965）。

风险被用作项目中和不确定的可能结果相关的问题的同义词。

风险管理被解释为控制环境并使事件按照计划的路径发展。

经理们需要确定所有可能结果的概率，并能定量估计出选项的损益。

然后，他们可以选择那些通向最佳预期值的途径。

但是，理论界明白要想完全控制风险是永远不可能的。

经理和决策者们每天感知和处理风险。

对他们来说，风险是导致项目延迟和失败的每一件事。

他们的成功是在正确的时间表和预算内完成既定的目标。

所以经理们需要一个工具来分析项目中的风险并有方法处理风险。

风险管理的概念允许我们检查项目经理们如何获得知识，决定他们寻求控制的环境。

风险管理的战略提供给经理们以帮助。

帮助他们拒绝糟糕的决定，感知他们的境遇，展现减少和避免风险的策略。

这些理论或是基于过往经验的成果，亦或是从环境学习和类似情况的研究得来。

风险管理途径的阐述通向了这些最为重要的问题：-风险项通常是从哪里来的？-哪几种风险解决技术被提出来？-哪些干涉事项有哪些影响？-这些技术的形式化和严格程度的水平怎样？风险管理方法通常由风险项概念，风险解决技术和探索法组成。

风险项和探索法一起构成了风险管理方法的注意事项。

风险项形成了有用的，指示管理注意事项的机制。

比如经理们以风险项目检查清单的形式扫描他们的环境。

下一节，我们将讨论通过一个社会技术系统的变化来区分风险（风险项目）。

社会技术模型拥有对我们目标来说好的特性：它是简单的，广泛的并且是良好定义的。

因而模型在实际中应用时是可行的。

2.1风险管理的社会技术模型在社会技术模型下，组织被看成是由四部分组成的-任务，结构，参与者和技术。

这些组件可以在每个项目中找到。

通过图1 一个系统开发的社会技术模型把特别的主题命名到组件下—比如用户在参与者下，我们可以容易地把它们的意义转换成实际生活中的视角。

这个模型的关键点是四个组件是密切相关的—它们互相影响。

这就意味着一个组件的变化将会影响到其它所有组件。

风险管理的社会技术模型的含义是任何一个组件或关系的更改可以引起变化。

这些变化可最终导致整个项目的失败或者说导致损失。

如果一个组件是不平衡的，它将会导致其它组件的实效乃至整个项目整体的实效。

当一些组件因为环境及相互间的影响改变而持续改变时，整个系统的变化不可避免。

所以，管理应该致力于控制这些变化去维持平衡，而不是努力去维持现状。

我们现将描述每个组件更多的细节。

任务组件可以定义成一套项目交货能力和过程特征。

换句话说，任务是从一个新的信息系统和开发人员那里可以期望得到的那些东西。

任务组件里有一些特征能引起风险，首先是规模，任务的复杂性和不稳定性，任务不确定性，设计特异性，和知识限制。

过程相关风险包括了使系统工作的不切实际的目标和压力。

结构组件包含了系统的交流，权限和工作流程。

在这个组件中我们可以发现两种标准（价值，规范）还有行为尺度（权限行使，行为范式）。

忽视结构尺度将极可能导致系统按时，按预算成本，符合合适要求或系统可接受的交付困难。

参与者是一组人，他们可以影响信息系统项目或从项目的实施中受益。

总体来说，参与者是客户，经理，开发者，维护者和用户。

参与者组件中的风险通常包括：个人缺点，缺少承诺和技巧，参与者的巨大差异，错误的预期和信心，勉强的用户，个人收益和机会。

一些经验源也强调个体才干和经验在减少任务和技术相关风险的重要性。

通过技术我们理解像电脑，笔甚至钻床这样的工具。

通常来说，所有的用来开发和实施软件系统的方法，工具和下部构造都包括在内。

这些技术上的东西可以造成大量的困难，特别是当它们不可靠，低效率，非标准，不调和或功能受限时。

考虑隐藏在这四个组件中的风险时，我们必须同样要检查它们之间的关系。

--任务-参与者相互依赖关系关注于参与者完成任务，指派和分析任务或者“走捷径”的的能力和非能力。

有代表性的是这些风险和参与者关于任务和机会的不同意见相关。

--任务-技术相互关系阐明技术对任务的适合度及这方面的风险如何产生。

由于使用比如电子邮件，CASE工具等技术激活的任务变化是一个重要的问题。

经验证明高水平的技术混合趋向于导致增加任务的复杂度和因此而生的项目风险。

--任务-结构的互动关系考察项目组织和其目标之间的关系。

不恰当的关系的可能事后效应看起来是糟糕或不满意的结果。

--参与者-技术相互关系制造了机器和人不匹配，或者是引入了未经试用的技术而产生的风险。

广为人知的问题出现于无经验的使用者用了又新又复杂的技术而产生的匹配性。

--参与者-结构相互关系关注于结构和参与者的相互作用。

典型的关注是组织机构的激励机制和支持系统，价值和信仰以及他们的通信联系。

有些问题产生于各人员间地理上相距较远。

--技术-结构相互关系强调这种观念：不恰当的结构设定的技术或者不恰当的技术设定的结构可以造成项目中大量的问题。

技术能用在处理权限系统的冲突中或者它们可以防止使用有效的通信线路。

在接下来的章节，我们将应用风险管理的社会技术模型于ERP实施项目。

3.过程实施3.1项目流程如前文所述，ERP实施是一个时间非常长且昂贵的过程。

就因为过程特别长，所以分清项目的不同阶段才显得极端重要。

不同的公司把事实步骤分成不同的步骤。

但是，基本的理念是相同的。

本节我们将贯穿实施过程，并聚焦于不同阶段的问题。

本文我们把ERP实施过程和项目1的待完成任务归为以下：阶段1 定义问题·设定目标·选择项目领导·建立筹划委员会·构建项目组·制定项目计划·形成预算·识别需要的模块·选择实施伙伴阶段2识别目前状况·分析目前的业务流程·业务流程之于ERP系统·识别数据和系统界面·登记造册现有的硬件和软件·开始项目小组培训阶段3 优化未来系统蓝图·发展高水平的设计·定义系统层次·使用者交流和取得认可·制作原型阶段4建造和测试·测试实际数据·建造和测试界面·测试报告·用户测试阶段5用户工作站实施3.2不同阶段的问题项目每个阶段都有异于其他阶段的问题。

阶段里的问题可以以不同按风险管社会技术模型的不同组件归类。

3.2.1阶段1定义问题基本上在过程的早期所犯的错误代价是不大的。

这就是看你是否能在开始时纠正错误。

任务相关的问题必须在非常初级的阶段处理。

也许这太明显了因为当构造新系统的节点时错误是持续产生的。

要把我们需要什么和建造系统满足这些需求装在心里，而不是围绕着我已经有ERP了，它能为我做什么呢这样的问题。

选择一个ERP的实施方法，首先是一些模块或者每个模块应用到一个SBU(小型事务单元)亦或是一个重大步骤，每件事贯穿整个组织。