erp系统变更怎么处理

  • 时间:
  • 浏览:193
  • 来源:成都艾邦软件开发

在ERP项目实施过程中,项目管理所要面对的经常发生而又最令人头疼的恐怕就是需求变更了。需求变更是ERP项目与生俱来的特性,ERP企业管理系统,所谓制造执行系统就是跟生产现场的管理密切相关,生产现场需求本身也存在很大的不固定性,为了优化各方面的管理或者为了简化现场的操作等一系列的原因都会导致需求变更的果。 从个人理解角度阐述一下发生需求变更的原因和如何管理发生的需求变更。

导致需求变更的根源之一:合同签订时的需求范围不明确

这个要从销售身上说起,在销售阶段签订合同时缺乏对客户需求认真对待,导致需求描述不清,为后期的实施工作带来困惑。为了尽早的让客户签订合同,往往草率决定和片面同意客户提出的需求。 该问题的关键是合同签署的太烂,没有把需求明确再签合同,而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚,后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围,同时明确的定义需求变更的流程,这样可以为以后各项实施工作的开展奠定深厚的基础。

根源之二:需求调研阶段没有详细理解客户需求

在项目的需求调研阶段,实施顾问和客户的深入沟通,了解客户的详细需求是减少需求变更的主要动能。在需求调研阶段常常会有实施顾问仅仅根据用户提出的描述性、总结性的只言片语去制定方案,这样得到的方案和Function Spec简直会让人崩溃。当需求会议一天几个接着开的时候,可能当时客户或者领导的思路也会偶尔发生混乱提出新的需求时,实施顾问往往不去区分客户真正需求和非真正需求。在需求分析阶段项目组对需求的细节了解的不够充分,双发对需求的理解就会产生很大的差异,而很多项目实施的过程中如果不存在一个Function Spec再次确认的过程(很多项目为了进度可能仅仅确认一下分析文档结果的方案架构),就会导致在上线阶段很多问题暴露出来,没有办法客户只能贫乏的提出需求变更。

根源之三:需求变更管理流程不够明确

没有明确的需求变更管理流程,就会使需求变更变得更加泛滥,客户更会毫无顾忌的提出各种各样的需求变更,甚至有很多时候仅仅是某个人的操作习惯就知道几个需求变更的产生。所有的需求变更都要有一个变更流程,有一个优先级。并不是所有的变更都要修改,也不是所有变更都要立刻修改,需求变更管理流程的目的是为了决定什么类型的变更需求修改和在什么时候修改,以及由此需求变更所产生的人力和时间耗费对项目进度的影响。对于一些界面上的优化问题,或者一些个人操作习惯上的问题,完全可以作为上线后的优化项目进行处理。需求变更的管理流程中针对核心模块的变更处理要把重要程度提到一个很高的级别,因为对于核心模块的变更,某个小需求看起来工作量不大,实际修改起来不仅仅对于实施人员的时间和人力浪费很大,而且往往极大可能产生一些附属的问题。同时需求变更管理流程中要将最后的需求变更结果报告给双方的领导层,让双方领导明确的清楚在项目实施的过程中由于多少的需求变更产生了多少的人力和时间的付出。

针对如此多的导致需求变更的原因,该如何解决呢?

由于需求变更对项目最终的成败会产生极大的影响,所以不能一律的拒绝所有的客户需求,也不能一味地接受客户所有的需求变更,所以实施需求变更之前必须做好控制。 用户需求的变更总是不可避免的,所以我们要以积极的心态去接受和控制用户的需求,而不仅仅是埋怨。对待客户频繁的需求变更,应采取有效办法应对,避免事态蔓延,不让客户养成随意变更的毛病。

随着开发运维概念的出现,软件工程师和运维工程师将具有相似的能力,而且他们的技术集合也更加接近。系统管理员必须像专业软件开发人员一样知道如何编写应用程序。这是因为,这两个团队都需要使用同一种语言,软件工程师必须了解运维人员的操作方式,理解系统管理员反对变化的心态;运维人员必须学习如何接受快速变更,然后学习如何创建能够适应这种变更的系统,降低风险并提早发现问题,而不是试图限制变更。

随着开发运维概念的出现,软件工程师和运维工程师将具有相似的能力,而且他们的技术集合也更加接近。系统管理员必须像专业软件开发人员一样知道如何编写应用程序。这是因为,这两个团队都需要使用同一种语言,软件工程师必须了解运维人员的操作方式,理解系统管理员反对变化的心态;运维人员必须学习如何接受快速变更,然后学习如何创建能够适应这种变更的系统,降低风险并提早发现问题,而不是试图限制变更。

以往,软件工程师和系统管理员隶属于两个完全不同的部门,他们互相之间几乎没有互动。这可以追溯到盒装软件开发的时期,那时产品都采用瀑布方式开发,然后通过物理介质交付给客户。USENIX ;login杂志主编Rik Farrow介绍了Web开发出现之前的系统管理员工作。

我曾经加入到一个开发团队中,我的系统管理工作主要包括创建各种不同的工作站,帮助他们将软件安装到这些工作站上。我只需要支持从工作站供应商获取的软件包,不需要支持其他软件包。

当我从事系统管理咨询工作时,情况也是完全一样的。我的工作就是让Unix系统保持正常运行,完全不需要理会已安装的软件。由于我是一位雇佣枪手,所以我需要解决各种难题,而且他们没有使用任何商业软件。

话虽如此,但是我负责的Unix是一个非常有用的软件平台,它适合运行那些要求支持多用户或连网协作的软件。例如,牙科诊所广泛使用SCO作为监控系统。不过,他们自己几乎都不知道自己使用的是一种Unix。

数据库也运行在Unix上,同样是要求支持多用户访问。另一个例子是出版软件,如FrameMaker。在所有的应用中,从没有人要求我简化底层系统的管理,我自己也从没有想过这件事情。我只是努力保证系统能够可靠运行。

当Windows NT出现之后,我曾经合作过的许多系统用户都抛弃了Unix系统,他们认为Windows更容易管理。如果更容易管理指的是用户界面(GUI),那么确实是这样的。用户界面隐藏了复杂性,但是如果要执行一些用户界面不支持的操作,那么我们一样会遇到困难。据我所知,在使用Windows系统后,没人会向工作组管理员询问关于软件设计的问题。不过,那是上世纪90年代末的事情了,所以我在这里介绍的经历也只是传闻。

开发运维是一个新概念。像Facebook那样,由于需要每周发布一次或两次新版本,所以开发人员最好与系统管理员协作,否则新版本上线对于他们而言就是一种灾难。过去,人们购买的软件可以使用很长时间。例如,始于上世纪90年代的USENIX数据库就是这样(确实很恐怖)。自Web应用出现之后,其使用模式和功能每天都会发生变化,如果开发人员不与系统管理员沟通,就擅自执行较大变更,那么他们的新系统可能就会出错,因为他们还不知道新的变更是否能够得到支持。当然,试验性上线会有一定的帮助,但是,这种活动也必须与系统管理员合作才能完成。

互联网完全改变了软件的使用方式。在出现USENET之后,人们开始通过连网的计算机共享文件和信息。随后,万维网面世。Web是第一种成功的软件即服务。随着Web技术的成熟,Web 标准和浏览器开始提供越来越多模拟桌面应用的功能。随着HTML5、 CSS3、JavaScript 和Flash这些技术得以运用,现在的许多Web应用都实现了以前桌面应用才有的相同特性。以前仅限于在桌面上使用的应用,现在都可以在Web上实现,这其中包括了金融、银行、出版、通信方面的应用,甚至连图形图像处理与设计都可以在Web上实现了。

这意味着,对于将网站(通常是一个复杂Web应用)作为业务主要入口的公司而言,他们现在不需要向成百上千的客户包装和运送软件,软件更新周期也不需要以年为单位,应用程序的修改可以在一周、一天或几小时内完成。现在代码的更新速度远远快于20世纪90年代,甚至也比本世纪初都快很多。敏捷开发逐渐成长起来并替代了盒装软件的瀑布开发方法,因为后者已经不适用于Web开发了,Web现在已经成为开展商务与共享信息的事实载体。Web开发团队必须调整他们的流程,适应Web增长,这样才能根据客户要求快速发布新产品(即新网站)。

敏捷宣言规定,团队应该自我组织,因此要开始打破开发与运维之间的壁垒。开发与运维团队必须开始协作,才能实现他们的共同目标支持越来越大和越来越复杂的Web应用,其中包括保证系统的一致性、稳定性和可用性。这是一种新的工作方式,但是和许多文化转变一样,这个过程需要多年时间才能完成。

网站建设开发运维代表了一种新的文化视点,它促使开发人员与运维工程师展开协作,共同支持网站与Web应用中更快速和更复杂的变化一当然,这些原则也适用于盒装或非Web软件。公司现在能够以惊人的速度发布新产品,这种加速是由软件开发团队实现的。运维人员必须保证系统能够可靠地运行和很好地扩展,并且要通过使用自动化、配置管理,以及其他工具与实现方法,尽可能加快软件开发周期。