ERP系统实施的可选方案课件

第5章、ERP系统实施的可选方案ERP系统实施的多种可选方案从某个系统供应商那里购买整个ERP系统软件包。从某个系统供应商那里购买ERP系统软件，并加以内部开发修改。采用单项优势原则，从多个系统供应商那里购买不同的模块。从多个系统供应商那里购买不同的模块，并加以内部开发修改。完全内部开发。以完全内部开发为主，某些系统供应商软件为辅。采用应用服务提供商（ASP）。可选方案的评价最简单的方法：不加修改地采用某个系统供应商的整套软件（方法1）。但不一定是费用最低的方案，也不见得能给企业带来最大的收益。采用单项优势原则（方法3），使用不同供应商提供的模块，这是因为在一个领域中，供应商A的相关模块可能是功能最强的，但是在另一个领域中，则是供应商B的模块功能最强。（相对于要实施ERP的企业的特定需求而言）。ERP系统可以完全在企业内部开发（方法5），但是这种方法并不可取。这种方法需要企业在信息系统/信息技术项目管理方面付出大量的努力。以上提到的几种方法也经常混合使用（即方法2、4、6）。ERP还可以外包（方法7），采用应用服务提供商。这可能是成本最低的实施方法。本章后文还会讨论到，这种方法的优点是方便易行，但作为代价，企业需要付出ERP系统的控制权。Mabert（马博特）等人对他们的479个制造企业样本调查了企业实施ERP时采用的战略方法。调查选项中没有包括ASP实施方法。Mabert等人对479个制造企业样本实施策略调查实施策略使用率单个ERP软件包，内部开发进行修改50%单个ERP软件包40多个供应商软件包，内部开发进行修改5单项最优原则4内部开发，加上特定的软件包1完全内部开发<1实施策略调研结果分析在制造行业，依靠单个系统供应商的ERP实施策略占据了统治地位，而且调查样本中有一半的企业会根据内部需求对系统加以修改和补充。单项优势的概念没有得到广泛的应用。极少有公司开发自己的ERP系统。企业基本上依赖于供应商的计划，按照供应商设计和测试过的流程进行实施，在这种情况下，管理实施项目是比较容易的，也避免了信息系统/信息技术（IS/IT）项目的许多缺陷。信息系统/信息技术（IS/IT）项目的管理结果管理一个信息系统项目，使其按时、不超预算、符合计划地完成是非常困难的。KPMG的PeatMarwick：250家公司，大约有30%的信息系统项目超出最初设定的预算和时间期限至少两倍，或者结果与项目计划书的规定不符。1994年，StandishGroup，365个公司的8000多个开发项目，只有16%的项目在预算内按时完成，而项目成功率只有9%。集团的报告同时指出：在软件的最终版本中，原计划的特征和功能只有42%得以实现。1995年，StandishGroup的另一份报告，由大企业发起的软件开发项目中，至少有一半的项目超出最初估计的预算189%以上。AmericanExpressFinancialAdvisors的项目成本竟超出预算500%之多。1997年，StandishGroup又发布一份报告，1996年，美国的软件项目中有73%超出预算、推迟完成或者中途取消，但这个数字比起1995年的84%来已经有所改善。1997年，MetaGroupInc.的报告称，在美国公司新采用的软件项目中，大约有三分之一的项目中途取消，造成了800亿/年的经济损失，这主要是粗劣的项目计划和管理造成的。每两个项目中，就有一个超出预算180%以上，这又造成了590亿美元的经济损失。虽然如此，但是信息系统项目仍然给公司带来了巨大的价值。风险的识别和分析

1982年，一家大型保险公司购买800万美元的计算机系统，并着手进行开发工作。计划在1987年完成系统实施。推迟到1993年才结束，估计所花费的成本高达1亿美元20世纪80年代末期，AmericanBank启动一个预算2500万美元项目，5年过去了，花费8000万美元后，系统被它的目标用户放弃了，因为它会造成会计上的问题，运行速度很慢，而且不能保证用户对数据进行访问。在项目开发过程中，银行已经解雇了许多职员（显然是希望节约成本）。项目实施完成之后，银行的单位结算账户从800个减少到700个，所管理的资产也从380亿美元缩水到340亿美元风险管理Kliem，Ludin，4种活动，通过这些活动，项目经理们就可以理解项目进展如何、风险存在于何处。风险识别，风险识别是一个解释潜在风险事件以避免意外发生的过程”。重点是识别项目的组成部分、项目目标和风险，并为这些因素划分等级。风险分析，尽力去识别风险事件的属性并预见其对项目的影响，将数据转化成对项目风险的理解。风险分析活动需要定量技术的支持，例如模拟实验，同时也需要基于判断的定性方法。风险控制活动，衡量风险和实施控制的活动，目的是减少或者避免风险因素的影响。风险报告，将已经确定的风险传达给别人，再进行讨论和评估。识别风险的主要方法风险辩识是指找出影响项目质量、进度、成本等目标顺利实现的主要风险，是项目风险管理的第一步。这一阶段主要侧重于对风险的定性分析。风险辩识主要有以下几种方法：专家调查法（包括专家会议法和德尔菲法等数１０种方法），幕景分析法，故障树分析法等。Chapman提出了三种不同的风险识别方法：依靠风险分析员的个人工作，对项目团队进行访谈，与更大范围内受到风险影响的人进行讨论，尤其是系统用户。风险辩识的过程分３个步骤：确认不确定性的客观存在，建立风险清单，进行风险分类。头脑风暴法（BrainStorming）又称智力激励法、BS法。美国创造学家A.F.奥斯本于1939年首次提出、1953年正式发表的一种激发创造性思维的方法。它是一种通过小型会议的组织形式，让所有参加在自由愉快、畅所欲言的气氛中，自由交换想法或点子，并以此激发与会者创意及灵感，使各种设想在相互碰撞中激起脑海的创造性“风暴”。头脑风暴应用要点特征：从评估中分离出观点规则不要评价或讨论备选方案鼓励新观点鼓励多出观点鼓励合作头脑风暴法流程1.准备阶段2.热身阶段3.明确问题4.重新表述问题5.畅谈阶段6.筛选阶段1.准备阶段负责人应事先对所议问题进行一定的研究，弄清问题的实质，找到问题的关键，设定解决问题所要达到的目标。同时选定参加会议人员，一般以5－10人为宜，不宜太多。然后将会议的时间、地点、所要解决的问题、可供参考的资料和设想、需要达到的目标等事宜一并提前通知与会人员，让大家做好充分的准备。2.热身阶段这个阶段的目的是创造一种自由、宽松、祥和的氛围，是大家得以放松，进入一种无拘无束的状态。主持人宣布开会后，先说明会议的规则，然后随便谈点有趣的话题或问题，让大家的思维处于轻松和活跃的境界。3.明确问题主持人扼要地介绍有待解决的问题。介绍时须简洁、明确，不可过分周全，否则，过多的信息会限制人的思维，干扰思维创新的想象力。4.重新表述问题经过一段讨论后，大家对问题已经有了较深程度的理解。为了使大家对问题的表述能够具有新角度、新思维，主持人或书记员要记录大家的发言，并对发言记录进行整理。通过记录的整理和归纳，找出富有创意的见解，以及具有启发性的表述，供下一步畅谈时参考。5.畅谈阶段畅谈是头脑风暴法的创意阶段。为了使大家能够畅所欲言，需要制订的规则是：第一，不要私下交谈，以免分散注意力。第二，不妨碍及评论他人发言，每人只谈自己的想法。第三，发表见解时要简单明了，一次发言只谈一种见解。主持人首先要向大家宣布这些规则，随后导引大家自由发言，自由想象，自由发挥，使彼此相互启发，相互补充，真正做到知无不言，言无不尽，畅所欲言，然后将会议发言记录进行整理。6.筛选阶段会议结束后的一二天内，主持人应向与会者了解大家会后的新想法和新思路，以此补充会议记录。然后将大家的想法整理成若干方案，再根据方案设计的一般标准进行筛选。经过多次反复比较和优中择优，最后确定1－3个最佳方案。这些最佳方案往往是多种创意的优势组合，是大家的集体智慧综合作用的结果。名义群体法(nominalgrouptechnique)指在决策过程对群体成员的讨论或人际沟通加以限制，这就是名义一词的含义。像召开传统会议一样，群体成员都出席会议，但群体成员首先进行个体决策。名义群体法的主要优点是，允许群体成员正式地聚在一起，但是又不像互动群体那样限制个体的思维。具体方法是，在问题提出之后，采取以下几个步骤：名义群体法流程1．群体成员聚在一起，但在进行讨论前，每个群体成员写下自己对于解决这个问题的看法或观点。2．在这个安静阶段之后，每个群体成员都要向群体中其他人说明自己的一种观点，一个人挨一个人地进行，每次表达一种观点，直到所表达的观点都被记录下来，通常使用记录纸或记录板。所有的观点都记录下来后再进行讨论。3．现在，群体开始讨论每个人的观点，并进一步澄清和评价这些观点。4．然后每个群体成员独自对这些观点进行排序。最终决策结果是排序最靠前、选择最集中的那个观点。名义群体技术特征：产生观点+评价观点步骤观点悄然产生转圈记录观点讨论观点初步表决最终决定德尔菲法专家直觉预测法20世纪40年代末由兰德公司“思想库”发展而来。由若干专家（并非学术意义上的）对每一问题达成意见。“背靠背”重复3－5次使意见趋于一致，每次归纳后，反馈，并提出修改意见原因。德尔菲法的预测程序：1、作预测筹备2、由专家预测3、进行统计与反馈4、表述预测结果查普曼建议，在项目生命周期的各个阶段均使用一种正式的风险管理流程——项目风险评估方法（PRAM）。PRAM的步骤包括：识别风险；如果发现消极的后果，则评估风险的影响；决定如果消极的后果发生，如何减轻其影响。项目风险的类型对信息系统建设项目来说，项目风险的类型可分为项目的大小与范围、数据处理能力、技术能力与经验、管理模式、项目运作环境几大类。风险评估的模型不是固定的，还没有统一的固定模式，组织可根据自身条件制定适合本公司的模式。下面是一套评估模型，供读者参考。表中提及的“数据处理”是指系统模块开发与代码编写；“公司”是指项目组所属公司；“用户”是指项目完成后的系统用户；“供货商”是指向项目组提供软硬件设备的经销商。每一项问答都有几个选择答案，答案的后面是风险要素因子，将此因子与该项的系数相乘即可得到该项的风险值。回答完所有问题之后，分别得到各项的风险总和，用分项的合计值所占总数的百分比来衡量项目风险的大小。风险有分项风险和总体风险，一般认为，百分比在40%以下为低风险，40-70%为中风险，70%以上为高风险，各公司可根据自己的承受风险的能力，来确定具体控制指标。1、项目大小与范围的风险

2、数据处理经验水平3、技术风险4、管理风险5、项目运作环境风险项目风险汇总表二、风险评估风险评估是指采取科学方法将辩识出并经分类的风险据其权重大小予以排队，有针对性、有重点地管理好风险。在这项模型中，采用层次分析法（简称ＡＨＰ法）进行风险评估。经过风险评估，该模型将风险分为以下几个等级：

Ⅰ级严重风险０.１≤权重≤１

Ⅱ级一般风险０.0１≤权重≤０.１

Ⅲ级轻微风险０≤权重≤０.0１对于以上不同等级的风险，应给予不同程度的重视。三、风险分析风险分析是指应用各种风险分析技术，采用定性、定量或两者相结合的方式处理不确定性的过程。风险分析方法必须与使用这种方法的模型和环境相适应，具体问题具体分析。风险分析是否成功，取决于分析员的个人经验，也取决于分析员对项目计划和历史数据的了解程度。通过对项目团队成员进行访谈，分析员能够了解官企业对项目的正式看法，但是这种方式不一定能明显地暴露风险的存在。与熟悉项目实施的整体环境的人进行更详细的讨论，才可能发现风险。查普曼还比较了头脑风暴（brainstorming）、名义群体技术（nominalgrouptechnique）以及特尔斐方法（Delphi，译者注：又称专家咨询法）。四、风险控制

风险控制是指风险管理者采取各种措施和方法，消灭或者减小风险事件发生的各种可能性，或者风险事件发生时造成的损失。风险管理者进行风险控制所采取的措施和方法主要有：风险回避、风险降低（减轻）、风险抵消、风险分离、风险分散、风险转移、风险自留。风险回避是指项目风险发生的可能性太大，或者一旦风险事件发生造成的损失太大时，主动放弃该项目或改变项目目标。采用这种风险控制方法之前，必须对风险损失有正确的估量，最好是在项目决策阶段。风险降低（减轻）有两方面的含义：一是降低风险发生的概率，二是一旦风险事件发生尽量降低其损失。采用这种风险控制方法对项目管理者是有利的，可使项目成功的概率大大增加。风险抵消是指将一些风险加以合并抵消，以便降低风险损失。如果一个项目遭受了风险损失，还有其他项目可能会带来收益，会全部或部分抵消风险损失。风险分离是指将各个风险分离间隔，以避免发生连锁反应或互相牵连。这种控制风险方法的目的是将风险局限在一定的范围内，即使风险发生，所造成的损失也不会波及此范围之外，以达到减轻风险损失的目的。风险分散是指通过增加承受风险的单位以减轻总体风险的压力，使多个单位共同承受风险，从而使项目管理者减少风险损失。采取这种风险控制措施，在将风险分散的同时，也有可能将利润同时分散。风险转移是指借用合同或协议，在风险事件发生时将损失的一部分或全部转移到项目以外的第三方身上。采取这种方法必须让风险承受者得到一定的好处，并且对于准备转移出去的风险，尽量让最有能力的承受者分担。风险转移主要有两种方式：保险风险转移和非保险风险转移。保险风险转移是指通过购买保险的办法将风险转移给保险公司或保险机构。非保险风险转移是指通过保险以外的其他手段将风险转移出去，主要有：分包、辩护协定、无责任约定、保证、合资经营、实行股份制。风险自留是指项目管理者将风险留给自己承担。该方法通常在下列情况下采用：⑴处理风险的成本大于承担风险所付出的代价；⑵风险发生可能造成的最大损失，项目管理者本身可以安全承担；⑶采用其他的风险控制方法的费用超过风险造成的损失；⑷缺乏风险管理的技术知识，以至于自身愿意承担风险损失；⑸风险降低、风险抵消、风险分离、风险分散、风险转移等风险控制方法均不可行时。这一方法主要运用于控制那些风险损失较小、业主能够承担的风险。系统失败方法在信息系统项目中的应用Fortune和Peters提出了系统失败方法，这是一种系统观察的方法，试图通过研究过去类似情况下的失败，来识别被提议项目的风险。这一方法得到了广泛的应用，其中就包括用于信息系统/信息技术（IS/IT）项目管理。Ormerod举例说明了软件系统建模方法在业务流程重组（作为信息系统战略的一种）中的应用，包括：用于一家连锁超市（1995年），用于两个南非的矿山（1996年、1998年），用于一家英国的能源公司（1999年）。这种方法非常适合考虑实施ERP系统的企业。系统失败方法背后的思想是：通过回顾过去的失败，企业能够避免将来重蹈覆辙。系统失败方法是降低风险的方法中最具吸引力的一种。这一方法试图识别其他组织实施类似项目（例如ERP实施项目）时所有可能出现的情况。分析者收集了尽可能多的关于其他组织出现的问题的信息。对这些过去的案例进行分析之后，分析者就能够洞察可能发生的问题和所要避免的缺陷，这种洞察力是十分宝贵的。从别人的失败之中，我们可以学到很多。系统失败方法的目的是提高项目成功的可能性，它研究过去类似活动的失败过程，以求避开引起失败的原因。这一方法要求我们进行如下工作：首先，将整个过程作为一个系统加以研究；其次，对系统进行建模，找出其中的因果关系。最后，分析者将计划实施的系统与过去类似的系统（不管成功还是失败的）进行比较。系统失败方法的步骤预分析：定义研究目的，确定核心观点，收集原始材料。识别失败原因，选择样本系统。建模：阐明系统的本质。比较：从而得以理解。分析。综合。预分析将被研究的系统概念化，将各种观点和看法都纳入考虑。收集并分析信息，识别系统的组成部分，了解它们是如何交互作用以实现系统目标的，研究系统控制的等级结构是怎样的等等。建模方法采用建模方法，分析员能够将某种行为的可能结果理论化。通过研究类似的系统，可以更好地理解自己的问题。分析员需要归纳系统的组成部分及其相互关系，另外还要包括系统的结构关系（用于描述系统行为）。软件系统方法论软件系统方法论包括七个阶段：定义发生问题时的形势情况。将发生问题时的形势情况结构化。识别人员行为系统。将人员行为系统的模型概念化。将模型与发生问题时的形势情况相比较。识别需要进行的可行更改。投入行动系统失败原因福琼和彼得斯认为，系统的失败通常是由以下原因造成的：组织结构效率低，缺少业绩控制。没有明确地说明系统实施的目的。子系统效率低。子系统之间不能有效地沟通。设计不足。对环境的考虑不够，或者资源不足。资源不均衡，没有充分地进行测试。福琼和彼得斯对所有种类的系统失败都很感兴趣，不仅是信息系统。“没有明确地说明系统实施的目的”这一条出现在他们的失败原因列表中，再一次说明了“明确地说明系统实施的目的”这一原则对项目实施的重要性。系统失败模型与其他系统的链接往往不完善。系统影响环境的能力不强。决策过程通常是孤立的。很少有人能理解系统的期望结果。所需的资源往往不足。系统体系结构和ERP系统体系结构，显示了支持组织的计算机系统的规划设计。传统上，ERP系统主要关注组织内部，这避免了与外部系统交互中的安全性和兼容性等许多问题。通过在专用服务器上使用封闭系统（大型机或客户机－服务器结构）的方式，系统能够严格地控制对组织数据的访问。瀑布模型原型法瀑布模型（WaterfallModel）1970年WinstonRoyce提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型是所有类型的软件开发——包括ERP系统开发——的基本标准。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型能够识别软件开发的不同阶段之间的反馈回路，从而尽可能地避免重新工作，同时，该模型还加入了原型方法，让人们更好地理解新的应用程序表5.2 软件生命周期阶段的瀑布模型阶段反馈系统可行性分析确认软件规划和需求分析确认产品设计检验详细设计检验编码单位测试整合产品检验实施系统测试运行和维护重新确认原型法原型法的过程是：为程序部件或者系统开发一个较小的工作模型，看看它能够实现什么功能。原型是一个学习型的设计，尤其适用于用户对系统的需求不太确定的情况。增量模型（IncrementalModel）与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。螺旋模型1988年，BarryBoehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。螺旋模型是对原型法的反复应用。这一方法是为高风险的软件项目设计的。所以它多半能适用于要进行大量内部开发的ERP实施项目。供应商的ERP软件实施过程基本上是一个反复的过程，每一次反复都包括修改、重新实施和升级。在螺旋模型中，要对系统的每一部分进行风险分析。螺旋模型螺旋模型迭代螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；（3）实施工程：实施软件开发和验证；（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险表5.3 软件开发的螺旋模型第一个周期第二个周期第三个周期第四个周期风险分析风险分析风险分析风险分析原型模型原型模型原型模型运行原型运行概念软件需求软件产品设计详细设计编码需求计划需求确认设计确认和检验单位测试生命周期规划开发计划整合和测试计划整合和测试接收程度测试实施各种模型的比较模型优点缺点瀑布模型文档驱动系统可能不满足客户的需求快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于维护增量模型开发早期反馈及时，易于维护需要开放式体系结构，可能会设计差、效率低螺旋模型风险驱动风险分析人员需要有经验且经过充分训练系统开发的其他可选方案－ASP最普遍的外包ERP及其相关系统的方法是利用应用服务提供商（applicationserviceprovider,ASP）。E