成功完成Oracle ERP最终转变

日期: 2009-12-27 作者:Carol Francum翻译:曾少宁 来源:TechTarget中国 英文

在第一部分:发动引擎中,我们确定了一组公认的ERP项目关键成功因数。首要的ERP成功因数包括精确的需求定义、良好的项目计划、股东承诺、用户参与和详细过程。在第二部分中,我们提出了维护一致的ERP项目管理进展的指导方法。然而,一个ERP项目开发的最重要因数是它的成功完成和交付。

  这个最终的ERP转变包括各种功能和整合测试、用户接受度测试、部署,以及常见的一段时间的新部署系统支持。通常,这其中还包括一段时间的性能优化过程以便为持续的系统管理建立性能测量基准。   现在让我们作一些基本的假设。为了良好地跟踪我们的“赛车”,我们小心使用ERP实现专家和用户专家的组合团队。

我们同时细化了“AS-IS……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

在第一部分:发动引擎中,我们确定了一组公认的ERP项目关键成功因数。首要的ERP成功因数包括精确的需求定义、良好的项目计划、股东承诺、用户参与和详细过程。在第二部分中,我们提出了维护一致的ERP项目管理进展的指导方法。然而,一个ERP项目开发的最重要因数是它的成功完成和交付。

  这个最终的ERP转变包括各种功能和整合测试、用户接受度测试、部署,以及常见的一段时间的新部署系统支持。通常,这其中还包括一段时间的性能优化过程以便为持续的系统管理建立性能测量基准。

  现在让我们作一些基本的假设。为了良好地跟踪我们的“赛车”,我们小心使用ERP实现专家和用户专家的组合团队。我们同时细化了“AS-IS”和“TO-BE”过程和工作流以完全理解业务需求,并且我们文档化了所有业务和用户需求。我们也确定了相关的风险和问题,消除或解决这些问题,并在决策制定过程中同时引入我们的股东和重要用户来保证产生正确的决定和足够的客户份额。

  在开发过程中,我们是通过与用户一起进行数据转换和对适用的业务规则进行验证,以及积极地让他们参加方案是否符合他们要求的评估来保持项目的跟踪。在开发阶段,应用被安装、文档化和进行必要的调整,以提供正确的方案。类似地,项目DBA和其他技术人员会复查和执行应用、服务器和数据库补丁和开发(文档化)定制方案或Oracle扩展。重要的是这些信息要保持更新和准确,这样生产环境的准备就可以平衡进行,并且用户社区也能够做好准备转变。

  为了使项目最后成功,我们需要验证我们的结果符合用户需求。它们应该同时在形式和功能上符合用户和股东的预期,以便将应用和环境的控制转交给业务用户,并作好在其环境中进行日常维护工作的准备。我提供了部分提及到的一些任务的模板。请查阅“Project Transition and Closeout Activities。

  用户社区需要参与计划的Acceptance Tests。这包括测试的范围和测试使用的数据。测试数据的准备将可能在数据转换脚本中使用过滤器以产生正确类型的数据,但这不是与生产数据完全一样的数据。测试应该覆盖特定应用的每一种事务。在测试准备期间,项目需求应该与测试对比以保证所有需求都被正确覆盖。你的Software Quality Assurance人员能够提供一些测量指导以及覆盖的数据数。此外,测试脚本应该包括一个Pass/Fail字段、Actual Results字段和一个Comments字段来解释任何有疑问的行为或问题。

  试图由一些测试新手来成功地完成一个测试是不太现实的。在开始Acceptance Tests之前,用户测试人员应该接受应用的第一手培训,以熟悉它们的功能。一定要定义用户接受度测试基准备。导致测试失败的详细原因将因组织对问题的容忍不同而不同。例如:

  对于有15个场景的测试,多少个步骤的失败是可接受的?

  如果出现的并不是预期的消息,那么它是一个失败或者只是间断情况?(消息失败通常被认为是最小的异常并且很容易改进。)

  是否有一些测试用例对于项目成功很重要,而其它一些则不是?

  如果一个定制报表的域顺序错误, 但所有域都出现了,是整个测试失败了还是只是报表失败了呢?可以考虑每天召开一个测试总结会议来确定可能发生的问题,以初步评估问题,并决定应该采用什么额外的动作。

  一旦你的用户接受度测试已经完成,并且所有回归测试都执行了,就应该完成一个最终的测试总结报告。这个报告可能会作为项目的一个交付项,它说明了适当的股东和签字人对项目的基本接受度。

  新生产系统的完成日期必须小心选择。月份和年份的结束时间是一个极为紧张的时间。在这种时间段给用户做一个新系统的交付会带来很大的附加工作压力。明智的转变经理都会考虑到推翻“旧”系统可能需要的时间。仔细考虑在一个财务重要时间点上系统失败的严重后果。如果系统的一个特定地方不能像预期那样工作,是否会对企业客户群造成额外的风险?你将如何处理这样的状况?

  我曾经看到过许多“很好的”ERP转变,但是我从没见过任何一个重大实现不出现一点问题就能成功运行的。这其中体现了你与用户和股东所建立的良好关系的不同之处。与项目团队一起工作的用户更可能将问题看作是消除最后一些缺陷的机会,而不是一个间断情况。一般情况下,经过一段时间的转变过程,这些问题就会被修复。此外,在ERP转变过程中,技术人员可能能够执行一些额外的应用、数据库或性能优化以产生正式的一组基线,这可以实现性能的持续对比。

  最后,一个好的实践方法是执行一个“经验教训”检查,并执行一个用户-股东检查来决定用户/股东是否跟你一样认可最终的输出。所有这些都应该被记录,并包含在最终的文档中。 Project Assessment Review给出了一组你可能希望向用户提出的问题,以判断用户对于项目和项目团队的反应。这些问题将需要根据你的实际项目进行裁剪。

  至此你完成了这个ERP项目,你可以进行下一个项目了。

翻译

曾少宁
曾少宁

TechTarget中国特约技术编辑,某高校计算机科学专业教师和网络实验室负责人,曾任职某网络国际厂商,关注数据中心、开发运维、数据库及软件开发技术。有多本关于思科数据中心和虚拟化技术的译著,如《思科绿色数据中心建设与管理》和《基于IP的能源管理》等。

相关推荐