ERP实施项目中的风险管理资料

【最新资料，WORD档，可编辑修改】ER咬施项目中的风险管理HenriLatvanenandReettaRuusunen目录.简介.风险管理风险管理的社会技术模型.过程实施项目流程不同阶段的问题阶段1定义问题阶段2:识别目前状况阶段3:优化未来系统蓝图阶段4:建造和测试一般性问题.解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 避免风险的实际策略制作模型5结论6参考文献7附录1.简介近年来，有可观数量的组织已经采用了资源管理 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 系统。更多的组织正花费巨资来实施这些系统。这些组织希望通过功能和业务单元的整合及软件所蕴含的最佳实践来取得竞争优势。但是，报道出来的结果却是混乱的。因为ER%一个宽泛的技术，不同的厂商不同的用户对它都有不同的定义。FredUngerer是SAP美国负责工业过程解决方案的主管。他说，公司把ERPt成是整个企业从物流系统到财务系统的连接。它包括了销售，经过生产的订单流程以及资源计划。通过收集，整理，分析业务数据，公司可以改进他们的业务系统，组织结构，工作习惯和最根本的账本底线。但是ERP系统只是一种使ERPS程高效率并有效发挥功能的机制。ER添统的益处包括了横跨企业的一整套交流工具，并且整个公司都用同一套数字的工具。它益处的范围取决于它深入组织的程度和公司是否能够持续更新他们的系统。ERPS过建设像高级计划和客户关系管理这样的企业级的解决方案来为企业提供一个支柱，从而强化了公司能力。ERFW时也提供了数据的一致性和数据的全球化视角。ER添统必须能够被分块实施，并且它们一旦运行就需要具有灵活性，而不仅仅是在实施阶段。和工程及工厂应用软件的互操作性也是ERP系统发挥效用的关键。ERPK统既可以设计成客户定制软件也可以购买现成的标准解决方案。客户定制软件的开发一般是昂贵的，并且经常遭到不确定性的麻烦，比如选择合适的开发工具，开发周期，和评估成本有关的困难。同样的，标准ERP系统比如SAPR/3,Oracle和PeopleSoft都有他们的缺点。巨大的存储需求，网络条件和高层 培训 焊锡培训资料ppt免费下载焊接培训教程 ppt 下载特设培训下载班长管理培训下载培训时间表下载 都是经常被提及的ERP问题。和软件实施过程相关的流程再造的范围和客户化任务是导致ERP不满意的主要原因。有人曾经统计过客户花在ER&施和相关服务上的费用是购买软件许可证的3到7倍。购买标准系统的人都必须认识到，因为标准系统是对每个人都是可用的，任何优势都必须来自于实施的质量。但是，经验调查显示有一半到三分之二的信息系统项目失败了。大部分ERP系统软件的安装在可衡量的财务收益上费用大于回报。美国曾有一个研究，研究了营业额大于5亿美元并且投资于ERP1目的公司。只有10%勺项目准时交货。55%勺项目延时或超预算。35%皮取消。那些延后和超预算的项目，平均比计划时间延迟230%，平均比初估预算误差178%。中东欧的Deloitte和Touche另一项的有关大型信息系统实施项目成功和失败原因的研究得到如下结果：成功---目标完全实现23%失败---终端用户不愿意接受改变26%失败---没有熟练员工22%失败---预算35%失败---公司的官僚作风14%失败---没有充分的培训15%失败---没有好的交流17%这一章节的目标是介绍ERP实施项目的风险，给经理们以如何处理风险的建议。我们相信这将帮助经理们完全理解风险的源头和它牵涉到的方面。风险管理古典决策理论中，风险的概念反映了可能结果的分布状态的变化，它们的喜好的变化，和它们的主观价值的变化（1965）。风险被用作项目中和不确定的可能结果相关的问题的同义词。风险管理被解释为控制环境并使事件按照计划的路径发展。经理们需要确定所有可能结果的概率，并能定量估计出选项的损益。然后，他们可以选择那些通向最佳预期值的途径。但是，理论界明白要想完全控制风险是永远不可能的。经理和决策者们每天感知和处理风险。对他们来说，风险是导致项目延迟和失败的每一件事。他们的成功是在正确的时间 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 和预算内完成既定的目标。所以经理们需要一个工具来分析项目中的风险并有方法处理风险。风险管理的概念允许我们检查项目经理们如何获得知识，决定他们寻求控制的环境。风险管理的战略提供给经理们以帮助。帮助他们拒绝糟糕的决定，感知他们的境遇，展现减少和避免风险的策略。这些理论或是基于过往经验的成果，亦或是从环境学习和类似情况的研究得来。风险管理途径的阐述通向了这些最为重要的问题：风险项通常是从哪里来的？哪几种风险解决技术被提出来？-哪些干涉事项有哪些影响？这些技术的形式化和严格程度的水平怎样？风险管理方法通常由风险项概念，风险解决技术和探索法组成。风险项和探索法一起构成了风险管理方法的注意事项。风险项形成了有用的，指示管理注意事项的机制。比如经理们以风险项目检查清单的形式扫描他们的环境。下一节，我们将讨论通过一个社会技术系统的变化来区分风险（风险项目）。社会技术模型拥有对我们目标来说好的特性：它是简单的，广泛的并且是良好定义的。因而模型在实际中应用时是可行的。2.1风险管理的社会技术模型在社会技术模型下，组织被看成是由四部分组成的-任务，结构，参与者和技术。这些组件可以在每个项目中找到。通过图1一个系统开发的社会技术模型把特别的主组命名到组件下一比如用户在参与者下，我们可以容易地把它们的意义转换成实际生活中的视角。这个模型的关键点是四个组件是密切相关的一它们互相影响。这就意味着一个组件的变化将会影响到其它所有组件。风险管理的社会技术模型的含义是任何一个组件或关系的更改可以引起变化。这些变化可最终导致整个项目的失败或者说导致损失。如果一个组件是不平衡的，它将会导致其它组件的实效乃至整个项目整体的实效。当一些组件因为环境及相互间的影响改变而持续改变时，整个系统的变化不可避免。所以，管理应该致力于控制这些变化去维持平衡，而不是努力去维持现状。我们现将描述每个组件更多的细节。任务组件可以定义成一套项目交货能力和过程特征。换句话说，任务是从一个新的信息系统和开发人员那里可以期望得到的那些东西。任务组件里有一些特征能引起风险，首先是规模，任务的复杂性和不稳定性，任务不确定性，设计特异性，和知识限制。过程相关风险包括了使系统工作的不切实际的目标和压力。结构组件包含了系统的交流，权限和工作流程。在这个组件中我们可以发现两种标准（价值，规范）还有行为尺度（权限行使，行为范式）。忽视结构尺度将极可能导致系统按时，按预算成本，符合合适要求或系统可接受的交付困难。参与者是一组人，他们可以影响信息系统项目或从项目的实施中受益。总体来说，参与者是客户，经理，开发者，维护者和用户。参与者组件中的风险通常包括：个人缺点，缺少承诺和技巧，参与者的巨大差异，错误的预期和信心，勉强的用户，个人收益和机会。一些经验源也强调个体才干和经验在减少任务和技术相关风险的重要性。通过技术我们理解像电脑，笔甚至钻床这样的工具。通常来说，所有的用来开发和实施软件系统的方法，工具和下部构造都包括在内。这些技术上的东西可以造成大量的困难，特别是当它们不可靠，低效率，非标准，不调和或功能受限时。考虑隐藏在这四个组件中的风险时，我们必须同样要检查它们之间的关系。-任务-参与者相互依赖关系关注于参与者完成任务，指派和分析任务或者“走捷径”的的能力和非能力。有代表性的是这些风险和参与者关于任务和机会的不同意见相关。-任务-技术相互关系阐明技术对任务的适合度及这方面的风险如何产生。由于使用比如电子邮件，CASE：具等技术激活的任务变化是一个重要的问题。经验证明高水平的技术混合趋向于导致增加任务的复杂度和因此而生的项目风险。-任务-结构的互动关系考察项目组织和其目标之间的关系。不恰当的关系的可能事后效应看起来是糟糕或不满意的结果。-参与者-技术相互关系制造了机器和人不匹配，或者是引入了未经试用的技术而产生的风险。广为人知的问题出现于无经验的使用者用了又新又复杂的技术而产生的匹配性。-参与者-结构相互关系关注于结构和参与者的相互作用。典型的关注是组织机构的激励机制和支持系统，价值和信仰以及他们的通信联系。有些问题产生于各人员间地理上相距较远。-技术-结构相互关系强调这种观念：不恰当的结构设定的技术或者不恰当的技术设定的结构可以造成项目中大量的问题。技术能用在处理权限系统的冲突中或者它们可以防止使用有效的通信线路。在接下来的章节，我们将应用风险管理的社会技术模型于ER我施项目。过程实施项目流程如前文所述，ERa施是一个时间非常长且昂贵的过程。就因为过程特别长，所以分清项目的不同阶段才显得极端重要。不同的公司把事实步骤分成不同的步骤。但是，基本的理念是相同的。本节我们将贯穿实施过程，并聚焦于不同阶段的问题。本文我们把ERP实施过程和项目1的待完成任务归为以下：阶段1定义问题设定目标选择项目领导建立筹划委员会构建项目组制定项目计划形成预算识别需要的模块选择实施伙伴阶段2识别目前状况分析目前的业务流程业务流程之于ERP系统识别数据和系统界面登记造册现有的硬件和软件开始项目小组培训阶段3优化未来系统蓝图发展高水平的设计定义系统层次使用者交流和取得认可制作原型阶段4建造和测试测试实际数据建造和测试界面测试 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 用户测试阶段5用户工作站实施不同阶段的问题项目每个阶段都有异于其他阶段的问题。阶段里的问题可以以不同按风险管社会技术模型的不同组件归类。基本上在过程的早期所犯的错误代价是不大的。这就是看你是否能在开始时纠正错误。任务相关的问题必须在非常初级的阶段处理。也许这太明显了因为当构造新系统的节点时错误是持续产生的。要把我们需要什么和建造系统满足这些需求装在心里，而不是围绕着我已经有ERP了，它能为我做什么呢这样的问题。选择一个ERP勺实施方法，首先是一些模块或者每个模块应用到一个SBU。」、型事务单元）亦或是一个重大步骤，每件事贯穿整个组织。少有足够的里程碑保持对团队的推动。最后期限很难设定。预先思考如果团队突破了期限将会发生什么是明智的。同样的，预算也趋向于被突破所以要保证你的预算是现实的，不管顾问们如何说。从ERP项目的开始将遇到结构-参与者相关的问题。内部的政策和层级可容易导致选不到最能胜任的项目领导。因为ERP项目是如此昂贵而难以推动，所以真正的功夫应该下在寻找最好的项目经理而把权限问题放在一边。同时，那些没有被选为项目领导的经理们如没有随着项目而引导可能会出问题。当组建项目团队时我们必须记住ERP不是信息系统部门一家的事情，而是作为整体的公司的事情。这就是为什么一个没有交叉功能代表的团队将会使项目的代表性太窄。还有团队成员需要他们正式职位的替代者。太多的公司相信他们的职员可以同时处理他们的常规职责和ERP项目。这会导致ERP项目的失败。选择正确的卖主和实施伙伴是在项目之初必须处理的任务-参与者相关的问题。如果你选型错误，你将至少在接下来的5年里出问题。即使你认为你已经选择了最好品种的软件你也许会发现这是不适合你的组织的。保持目标的清晰可以帮助你选择正确的软件。选择一个实施伙伴将会是比选型更复杂的任务。通常那些出售实施服务的和来帮你实施的并不是同一个人。选择一个知名的经验丰富的伙伴将会有助益但不会保证任何事。你永远不能从组织之外确保任何事。当你认为你第一阶段已经准备好了话，就移到第二阶段但得随时准备回到开头。在这个阶段你须保持任务的清晰并不给走捷径以任何空间。企业资源计划系统应用到业务流程后变得严格是广受诟病的。一旦你将业务流程固化到系统中后再改是很难的。如果你对实施过程所涉人员理解你的业务流程并且你所选的ERP系统是否可能模仿不确定话，你将会有麻烦。糟糕的业务流程定义看来是ER我施文献最为广泛报道的问题。没有明白像变动和低估变动管理困难这类任务-参与者相关问题同样是项阶段重要的缺陷。在这个阶段系统开始成形，越来越多的结构-参与者问题出现。反对转变的有组织抵制是难以明了的问题，但当你选择去寻找时又看不见了。因为ERP将在组织内发挥如此广泛的影响，你将预期到非常广泛的抵制。尽管在项目的全过程中都得注意员工抵制但是在这个阶段当一些具体事情完成时尤其如项。员工的抱怨必须倾听和认真对待，因为他们是系统的使用者也是整个项目的客户。项目团队需要聪明地判断哪些抱怨会引起系统的反复。系统必须得到使用者的认可，无论这样的方法或那样的方法。一个无人使用的系统是毫无用处的。这是每本软件实施的教科书中非常经典的论述，但不能得到使用者认可一直是经常发生的事情。在项阶段的另一个风险是项目组脱离于组织。项目必须是整个组织的项目而不仅是项目组的。这就意味着交流必须在每个业务单元中进行，尤其要和那些感觉因新系统而地位受威胁的业务单位经理去沟通。忙于外部竞争而不是内部竞争是至关重要的。当新系统设计完成，你就可以让它上线运行了。这个阶段的问题通常是和技术有关的。不充分注意数据清理和转换可导致系统因为很少的数据而瘫痪。这时可以测试软件卖方对运用跨模块整合的软件能力的承诺和测试实施伙伴整合追加和遗传系统的能力。如果系统看起来能处理一些事情时就要进行压力测试，测试系统是否可以处理最大容量的实际数据。如果系统能够通过所有的测试这时可以祝贺你自己了。工作还没完成但大部分问题解决了。一个ERP系统的结构性问题是任务的复杂性。因为有太多的复杂任务而几乎不可能跟踪每一个对系统的改变。因为这种复杂性，做出一种和旧系统类似的新系统是诱惑人的。这会重蹈覆辙。新系统同样要注意来自未来的挑战。项目的长度让领导项目更困难了。很有可能一些关键人员或参与者因为项目的压力或其它原因将离开公司到其它公司去。冗长的项目同样妨碍了和高层管理的交流。有项目的发起人和拥护者是至关重要的。如果项目太冗长让经理们保持兴趣也是很难的。一些外部问题同样也是存在的。外部顾问们也许比他们承认的要懂得少或者他们不想分享他们的知识。这可理解但不可接受。解决方案这一节，我们首先描述最习惯的策略来避免前面小节提出的各种风险。然后我们将提出另外一种有用的方法来使ERP®施项目的风险最小化。避免风险的实际策略任务风险主要是任务复杂性的结果。减少复杂性是一个自然的避免此类问题的方法。这可以通过把项目分成几个部分或者使项目的要求要窄一些并有所选择来解决。另外几种问题来自于任务的不确定性。可以通过保持系统的简单，减小项目的范围，使用节点和使用向导演示系统的价值来减小系统的不确定性。同样测试系统的广泛性也可以帮助看清它。管理过程同样可以减小不确定性。仔细的计划和合适的里程碑定义将在这一点上带来更多的好处。结构风险可以用改进交流系统来减轻。通过使用者参与，使用者调查，召开有使用者充当领导的团队会议就可以得到进步。通过监控过程和同几个小组开放的讨论来创造合作和一致目标的氛围。同样的聚焦于成功关键因素和话题带来了对ERP项目合适部分的关注权限系统被证明是非常严格并且是任何信息系统项目困难的障碍物。层级可以通过项目组织重组来克服。这可以通过外部合约，外购，通过形成使用者委员会和通过培养好的用户和开发者/实施者关系来完成。定义正式的程序和使用定义良好的成本分配方案同样被发现是有用的。工作流程上的缺陷可以通过改变来避免。如果时间表能在规则的基础上合适地制定、检查和更新的话它们将是现实可行的。当持续成本和进度表估计及优化措施发生时和当增加的途径使用后，风险被最小化了。路线分析作为一种正式的控制工具和自然的安排提供了项目开发和时间表履行的密集的控制。参与者风险可以通过简单提高参与者能力来避免。非常接近于人力资源管理话题，应该使用合适的管理和领导艺术。为了避免和最小化风险，最有才干的员工必须放在关键岗位上，应该表扬和激励使用者中的拥护者，为扩展员工技能应该进行跨功能的培训。在最小化风险的事情上，公司文化也是一个重要角色，比如使用者承诺，高的士气和专心地工作。通过培训，使用实施游戏和接受反馈来教育员工能更深地减小参与者风险。技术风险可以通过用技巧改进技术来应对。用任务组织分析方法和设定基准有助于跟踪过程和吸取早前的错误教训。某一水平的信息提取和信息隐藏可以帮助认清细节问题，甚至可以用来制作原型和模拟演示。任务-技术风险将在技术不能满足项目承诺的需求时出现。可以通过可能性软件开发模型和仔细检查技术管理选项来选择好的技术体系。任务-结构风险。当任务结构关系不能正确工作时，有两个明显解决问题的可能性。其中一个是通过比如收窄任务或更好的定义来改变任务使之适合于结构，甚至改变需求。第二个明显的方法是改变结构来适应任务。也许最好的方法是配合权威和决策结构并改进过程模型。参与者-技术风险。改善参与者和技术的适合关系会变成一个非常困难的任务。制作模型，技术分析，或者技术方案可以被用来增加使用者对技术的经验和信心。雇佣顶尖人才在员工中工作并提供广泛的技术培训也可以改善参与者的适应度。参与者-结构风险。得到管理支持会解决和缺少轻松许诺相关问题。这样做了后，就可以讨论合适的领导战略并容易地执行它。管理层可以帮助设置建造程序的团队并聘请到在员工中能很好合作的专家。技术-结构风险。再一次，当技术没有和权限及工作流程结合时，你有两种可能性可以选取。第一，你可以改变权限来配合工作流程。或者改变流程来配合权限。新的技术也可获得或者通过组织来设定。成功实施ERP的秘密就是要致力于在组织如何做业务的问题上做出基础性的转变。如此，项目就应该是业务团体所有并由其推动的项目，而仅不是IT部门的事。和基本业务流程及公司组织结构的转变相比，由技术造成的挑战是黯然失色的。业务流程和组织结构的改变及配置实施队伍和方法所涉及的组织重整将会给项目实施过程和以后带来极大的益处。制作模型建模方法，体系结构和工具变得越来越受欢迎，它们可以帮助减少软件实施的费用，同时增加使用者ER啾件接受度。ER我施应该包括现有的业务流程分析和流程再造的机会，而不是设计一个坏的流程的最好应用系统。（Scheer-Habermann2000.）可以有下面几个建模方法：通过参考已有模型的最佳实践知识的杠杆作用减少创造目标概念的必要努力。通过用来详细描述的模拟技术的杠杆作用创作需求定义。通过概念模型方法来文献化系统需求定义，使得业务逻辑更能被理解。杠杆概念模型是一个最大的自动化系统和客户化配置的起点。ERPS统是改进业务流程的工具，比如制造，采购，发货。所以ERP®施和BPR业务流程再造）活动应该紧密结合。因为业务流程太复杂的事实，许多案例不能直接在实际应用上直接分析。这样，模拟目的就在于减少实体复杂性以便于更好理解业务流程和所需的软件支持。我们可以关注于业务流程的不同方面（所涉组织单位的交互作用，输入输出关系，通讯和信息流的数据结构等）。模拟方法支持这个创造性过程。一个模拟方法是一套组件和如何使用这些组件来建造模型的描述。如果业务流程是合适地重新设计的而且业务流程模型做了相应改进，可以通过这些概念模型来配置ERP系统。但是，这就要求过程模型要和各自的ERP系统的知识库相联接。建模工具，概念模型和应用系统之间的直接相互作用修改了ERP软件的实施战略。伴随着对极微小的任何潜在缺点的原样分析，刚性的阶段概念被客户化了。使用客户化技术，ER啾件的独立目标概念发展和实施起来。现在这些阶段被越来越多地同时交互执行。这让业务和实施员工紧密合作，同时做业务和实施的事情。在一个大型组织的ER■施中使用模拟技术提供了几个优点：因为ER添统总是多语言的，人们对外国业务术语，过程管理概念，法律约束和文化个性的理解是非常困难的。因为模型包括了根据正式半正式的文法可以使用的图像符号，它们提供了一个可以减少甚至解决问题的表现媒介。地理上的分布式协作比如国际业务合并或虚组织，不透明过程的问题是显而易见的。为了建立一个成功的伙伴关系，业务流程必须在非常细节的水平上设计。业务流程模型可以帮助清晰地定义目标，流程边界和组织内部合作的组织职责。在业务到业务应用比如供应链管理中我们必须用ERP4接所有的商业伙伴。这就意味着我们必须不仅为有着成千个伙伴的单个ERP系统而奋斗，而是两倍甚至更多。商业伙伴使用不同供应商的ERP系统也是有可能的。在这种情况下，一个业务流程模型可以被用来定义概念上的价值链。这个概念上的模型是和某个具体软件供应商相独立的。它可以和不同ER添统的知识库相连接来客户化一个完整的软件解决方案。5结论企业资源计划系统正迅猛地在全球范围内安装。但经验表明却不都是正面的。类如“ERP黑洞''"ERPW训臭”“忘了ERP信息技术的钱了转向客户应用”这样的问题最近被报道出来。另一方面，“给ER屋个机会”这样的文章提供了许多如何实现一个成功的ER颜目的教科书。如果你想要一个如何完美管理项目的理论，你只需拎起一个看起来不错就行了。仍然会有大量的项目失败。为何？用我们的观点看，有三个主要原因：1)项目的持续时间。即使你可以集好的团队和最好的软件于一身，时间会让你的努力变成徒劳。2)规模。你有成千的伙伴，但你不可能全部处理它们。人类的脑力是有限的。3)许多的参与者。当处理人的事情时，未知的事情就来了。ERP5大例行性地接触到广泛的人员，它不可能使他们全满意。即使是一个字处理程序的改变也会因被当作整个组织的工作方法的改变而遭到抵制。即使你做到最好项目也有可能失败。尽管假设你有好的团队，好的计划，没有不合适的期待和一些常识，项目看起来要超出你的能力范围，你还是有可能成为一个作为ERP项目经理的着名英雄。6参考文献Booker,E.(2000),"EnterpriseSoftwareProjectsRarelySatisfy”,Internetweek,Apr3Challener,C.(2000),"LeveragingERPinvestmentsinthe21stcentury"，ChemicalMarketReporter,Jan24,24-26Cliffe,S.(1999),"ERPImplementation,"HarvardBusinessReview,January-February,16-17Davenport,T.H(1998)."PuttingtheEnterpriseintotheEnterpriseSystem"HarvardBusinessReview,July-August,121-131GartnerGroup,Ed.NextGenerationEnterpriseApplications,9/1997,andSystemsSoftwareArchitectureScenarios,10/1997.Glover,S.M.,Prawitt,D.F.,andRomney,M.B.(1999),”ImplementatingERP,”TheInternationalAuditor56,1,February,40-47.Harney,J.(2000),”HostedERP:Whoofferswhat?Andhow?”,Inform,Jan-Feb,38-40Hauru,J.(2000),”Toiminnanohjausj?rjestelm?nImplementointi”,Turku,TurunKauppakorkeakouluKirby,H.(2000),”Whenimplementationstartstowobble”,WorksManagement,Nov2000,1619Koh,Christine-Soh,Christina-Markus,M.Lynne,AProcesstheoryApproachtoAnalyzingERPimplementationandImpacts:TheCaseofRevelAsia.Kremers,M.,Dissel,H.V.(2000),”ERPsystemmigrations”,CommunicationsofACM,Apr,52-56Kumar,K.,Hillegersberg,J.V.(2000),”ERPexperiencesandevolution”,CommunicationsofACM,Apr,22-26Laughlin,S.P.(1999),”AnERPGamePlan,”JournalofBusinessStrategy,Jan-Feb,32-37.Lozinsky,S.(1998),”Enterprise-WideSoftwareSolutions”,Massachusets,Addison-WesleyLyttinen,K.-Hirscheim,R.Informationsystemsfailures-AsurveyandclassificationoftheempiricalLiterature,OxfordSurveysinInformationTechnology,4/1987,Compass,Ed.,ThecompassWorldITStrategyCensus1998-2000;HYPERLINK"http://www.compass-analysis.de"www.compass-analysis.de.Mendel,B.(1999),”OvercomingERPprojecthurdles”,InfoWorld,Jul19,87-89Mullin,R.(1999),ERPuserssayitspaybackispasse,ChemicalWeek,February24,47-48.Renfrow,C.(2000),”Changemanagemen”,tChainStoreAge,Jan,108Scheer,W.,Habermann,F.(2000),”MakingERPasuccess”,CommunicationsofACM,Apr,57-61Schottmiller,Paul.Yournewrisk-anunresponsiveITinfrastructure,Bobbin,ColumbiaSep1998.Stedman,C.(1999),”ERPProjectsCostmorethanTheirMeasurablePayback,StudySays”,Computerworld,March29.Teresko,J.(1999),”ERPOutsourcing”,IndustryWeek,Sep6.,38-45Taylor,J.C.(1998),ParticipativeDesign:LinkingBPRandSAPwithanSTSApproach,JournalofOrganizationalChangeManagement,11,37附录