计算机管理信息系统(简称ERP系统)的开发是一项复杂的系统工程。从70年代开始,人们逐渐认识到,为了保证ERP系统开发成功,必须采用工程化的系统开发方法,并研究出一些符合工程化标准的开发方法。这些方法旨在指导开发者进行工程化的系统开发,从而加快ERP系统开发的速度、保证质量、以及降低开发成本。工程化的系统开发方法确实在开发实践中取得了一定的效果。
那么,是不是采用了工程化的系统开发方法便一定能保证ERP系统开发的成功呢?答案是否定的。有许多失败的ERP系统的例子,其开发也是采用了工程化的方法,或声称采用了这种方法。但结果在投入了大量资金后,系统却不能达到预期的目标、满足用户的需求,以致用户方怀疑是否应进行该项目的开发,或者开发所选择的硬件、软件以及开发工具是否得当。究竟问题出在哪里呢?笔者通过对一些失败的ERP系统的分析,发现问题并没有出在开发方法本身,以及硬软件的选择上,而是出在了开发方法的实施过程中,也就是说主要出在开发项目的管理上。
任何一种开发方法最终是要由人来实施的,人们在开发工作实施过程中不可避免地要遇到许多项目管理方面的问题,如何正确对待、解决这些问题,直接关系到ERP系统开发的成败。目前计算机界虽有许多关于ERP系统开发中项目管理方面的问题的讨论,但大多局限于针对理想开发环境中的理想开发模型的讨论。而实际的开发环境和开发模型却各不相同,它受到各种客观因素的影响,忽略这些因素,或者回避、不解决存在的问题,必将导致开发工作的不完善、甚至于失败。本文就是要通过讨论如何处理实际ERP系统开发中一些重要因素之间的关系,分析项目管理中存在的矛盾,来揭示其中存在的问题并探讨解决的方案。
ERP系统开发的项目管理是根据管理科学的理论,联系ERP系统开发的实际,保证工程化系统开发方法顺利实施的管理实践。它包括ERP系统开发中的项目评估及可行性分析、人员管理、进度管理及成本控制等方面。
一个ERP系统的开发需要用户方与开发方的共同协作。在一个ERP系统开发中,开发方人员和用户方人员各自扮演着不同的角色。主要角色有:
用户方的项目管理人员:他是开发项目的组织者,负有开发项目的计划、系统的阶段验收及对系统整体进度的监控、经费的使用、与开发方的项目管理人员工作的协调、用户方的使用人员的组织与培训等职责。
用户方的业务人员:ERP系统的需求的提出者,也是ERP系统的最终用户。他们是对应用系统开发成功与否的最终评判者。
用户方的决策层:ERP系统开发的最终决策机构,决策层要对ERP系统开发的项目的上马、经费的预算以及系统所要达到的总目标等作出决策。其决策直接关系到ERP系统的开发成功与顺利实施。
开发方的项目管理人员:负责项目的计划、开发人员的组织与调度、开发进度的检查、以及与用户方项目管理人员工作的协调。
开发方的软件编程人员:根据用户方的需求、按照项目的计划及进度进行系统开发。
1、用户方与开发方的关系
用户方与开发方是对立的统一体,双方均希望将开发项目做好。但用户方可能对计算机系统工程,如工程组织,缺乏全面的了解;而开发方对用户方的需求、细节了解不充分等因素,使得用户方与开发方对工程的理解从一开始就存在着差异。而这种认识上的差异与理解的不同往往在开发初期并没有表现出来,当系统开发结束时,双方才发现这种差异使开发出的系统与实际需求偏差甚远。因此,ERP系统开发项目管理的重要目标便是建立一个便于开发方与用户方之间进行交流的环境。在系统需求分析阶段,开发方与用户方的深入的交流是项目获得成功的关键。但这种交流却经常由于各种双方的误解而难以沟通。
在需求分析阶段,开发方的分析人员总是先把精力集中在整个系统的总的需求上,而不会对具体细节作过多的考查。当用户方提出一些细节要求时,开发方往往说:“这些问题留待后面讨论”,而糟糕的是以后却可能永远不会再谈及这个问题。当用户方认为已经向开发方提出这些需求时,开发方却根本未予考虑。因此,开发初期,用户方的项目管理人员应该把这些“留待后面讨论”的需求单独记录整理,在开发方做完系统的整体需求分析后,项目管理人员应及时提出对系统进行进一步的、更深入的、细致的、具体的需求分析,以解决那些开发方要“留待后面讨论”的问题。
在某些需求尚未确定时,用户方项目管理人员往往会说:“这部分需求我们还要考虑,不过你们可以先按现在的模式做。”遗憾的是,开发方经常就会把现在的工作模式作为将来的、确定的需求去设计开发系统,而把用户方在此需求上的未确定因素抛在脑后。当后来用户方要求其改变时,开发方便陷入了窘境。因此,用户方管理人员应尽量将需求陈述清楚,对不能确定的因素,应提出几种可能的实施方案供开发方参考,以保证开发方系统设计时,将不确定因素设计成灵活可变的功能。
开发方说:“用户方已经认可了需求分析报告,这表明我们已经彻底了解了用户方的要求。”
用户方说:“尽管我不太明白需求分析报告中的一些技术术语,但他们能写出这个报告,一定是对我们的需求了解得很深入了。”
其实,需求分析报告是对系统需求的书面表达形式。由于需求分析报告是采用软件设计的术语编写的,因此常常令计算机背景知识较少的用户方难以理解,也就很难发现需求报告中与实际需求不符之处,更难提出建设性的意见。特别是那些编写得较差的需求分析报告,用户方更是不知所云。
因此,用户方的项目管理人员一定要要求开发方对需求分析报告进行进一步更详细的解释,以便用户方准确地理解需求分析报告的内容,能及早地发现需求与实际的偏差。这也是对需求分析工作的总结与确认。
用户方说:“计算机应该能实现这个功能,为什么会作不到?”用户方往往容易过高地估计计算机的软件开发工具的能力,总认为它一定能实现任何所需功能,期望值过高,所以经常会对所设计的软件大失所望。其实任何技术均有其一定的局限性,计算机系统也不例外,系统开发的最终结果只能达到有限的目标。因此,双方应详细制定系统最终实现的目标,切不可用一些简单的术语来笼统概括需求,例如:“实现办公自动化”、“建立现代化的ERP系统”这种抽象的术语只能将用户对ERP系统的理解引入误区。
总之,用户方与开发方的关系是项目管理所要处理的最重要的关系之一,增加沟通和减少误解是处理好这个关系的关键。所以项目管理人员要有效地安排开发方软件人员与需求方使用人员的交流,保证有畅通的交流渠道。在交流中用户方要尽量避免含糊不清的需求,而开发方要杜绝敷衍了事、得过且过的行为。
2、用户方项目管理人员与使用人员(业务人员)及决策层的关系
用户方项目管理人员与系统使用人员的关系是十分微妙的。一方面,ERP系统使使用人员减轻工作强度、提高工作效率;而另一方面,ERP系统改变了现行的工作管理模式,使使用人员失去了一定的灵活性和随意性。但是ERP系统的成功与否有赖于使用人员的检验。再好的系统,如果使用人员不愿意用,也不能说获得了成功。特别是在ERP系统的试运行阶段,使用人员对ERP系统的使用实际上是对系统的深入测试,他们将发现许多在软件测试时疏漏的程序错误,从而有助于帮助开发方进一步完善软件功能,提高软件的实用性、稳定性及可靠性。因此,如何鼓励使用人员使用ERP系统,帮助他们克服对新的工作模式的为难情绪,也成为项目管理的任务之一。
用户方的决策人士是用户方项目管理人员领导,由于行政手段是推行ERP系统使用的有力手段之一,他对项目的支持是使ERP系统开发成功关键与顺利实施的保证。因此用户方项目管理人员应随时与决策层沟通,取得其鼎力支持,这也是保证软件开发、使用成功的一个致关重要的因素。
任何一种新的工作方式,均必然有其适应及完善过程,用户方的项目管理人员、决策层及使用人员必须充分认识到这一点。当出现问题时,用户方项目管理人员应迅速分析问题,正确判断哪些问题属于不适应新的工作模式引起的,哪些问题属于操作不当引起的,哪些问题属于ERP系统本身不完善引起的。对于那些由于不适应新的工作模式引起的问题,项目管理人员应引导使用人员迅速适应新的工作模式,必要时也要说服用户方的决策层采用行政手段推动实施;对于那些由于操作方法不当引起的问题,项目管理人员应培训使用人员正确操作系统;而对于那些由于ERP系统本身不完善引起的问题,项目管理人员应迅速与开发方协调,尽快排除系统中的错误。
在系统试运行初期,使用人员常抱怨说:“这个界面不方便,不好用”
在软件界面设计方面,用户方管理人员应注意提醒开发方注重其实用性、简便性、易操作性,要注意现行工作模式的特点,照顾使用人员的工作习惯,以便降低系统的使用难度。这将有利于新系统的顺利实施,有助于工作方式的顺利过渡。
综上所述,项目管理人员时刻注意取得决策层的理解与支持;要帮助使用人员尽快地适应新的工作方式,帮助他们解决使用中遇到的问题;并使系统在使用中不断地得以完善。
3、项目管理人员与软件编程人员的关系
项目管理人员与软件编程人员的关系处理得如何将直接影响软件编程人员的积极性。在ERP项目开发中,项目管理人员经常处在两面夹攻的地位。一面是使用人员,而另一面是软件编程人员。当使用人员对系统提出问题,并要求改动时,除了最简单的界面修改外,软件编程人员往往总是找出各种理由(如影响进度、系统结构会打乱、性能会受影响等)予以否定。而这正是引起开发方与用户方矛盾的最经常的原因。
经常可以听到软件编程人员抱怨:
“用户的需求老是变,我的开发进度又延误了”
“无法增加这个功能了,因为需求分析报告中没有”
“这个错误我们过几天统一作修改。”
作为项目管理人员,既要满足用户方的需求变化,又要充分调动开发人员的积极性。由于系统分析不够准确,用户方业务需求的改变等诸多因素,均会导致要求开发方修改程序。作为项目管理人员应及早提醒开发方程序修改的必然性,在实际运作过程中用户方管理人员应尽早介入开发工作,及时发现问题,解决问题。在系统试运行阶段,将用户方不断提出的需求改动加以归纳整理,集中问题与开发方一起讨论解决方案。这样既满足了用户方对系统改动的需求,又不会不规则地时常打断开发人员的正常开发工作,使开发人员处于不断的修改状态而失去耐心。
4、硬件与软件的关系
ERP系统的硬件与软件都是组成ERP系统的重要部分。但目前在ERP系统的建设中,却经常出现重硬轻软的情况。
总能听到用户方:“设备要最好的、最先进的、一步到位”
“软件开发费怎么会这么贵”
据统计,目前国内用户在硬件(包括网络)方面的投资占总投资额的78%,而软件投资只占22%。确实,先进的设备、优良的技术性能有助于提高ERP系统的性能。而ERP系统的建设是否应追求高、新、尖、一步到位,却是值得商榷的。在计算机技术飞速发展的今天,计算机厂商不断地推出新产品,其性能价格比均极大地优于旧产品。就拿硬盘技术来举例:1994年1个GB的硬盘价格与1997年9个GB的硬盘价格相当,可见一步到位的想法是不切合实际的。同时,系统性能过多地超出应用需求实际上是一种浪费。好比杀鸡用宰牛刀。因此,根据业务需求“统一规划、分步实施”是项目管理人员应注意掌握的原则。在规划时认真考虑业务发展、技术的进步,在实施方面,时刻要将硬件配备的重点放在设备稳定、性能可靠及可扩充可升级方面。
如果说在硬件设备方面存在不惜投入、追求一步到位的现象,那么在软件开发方面,用户方却往往太苛刻了一点。殊不知,一个好的、高质量的ERP系统,是要靠软件编程人员来开发的。这里的高质量是指软件的可用性、使用的方便性以及可维护性、可升级性诸方面,这是软件得以推广的必要条件。如果投入资金过少,必造成开发人员不能全身心地投入到某一个项目的开发工作中,当开发方认为他们的投入已与用户方的付出相当时,便不愿意继续投入精力,从而造成开发工作的虎头蛇尾。ERP系统达不到预期效果,再好的硬件也难能发挥其作用。当然,由于用户方对工程组织、工程量计算、技术含量分析等诸方面开发因素估价困难,很难正确计算出合理的软件开发价格。用户方项目管理人员可以聘请有关专家、或参考同行业国内外开发情况加以核定。
在开发费的控制方面,用户方应合理运用价格这个有力武器,付款方式及付款条件要严格与开发进度、软件质量以及软件维护服务质量挂钩,使其成为督促及约束开发方的手段。
5、性能与灵活的关系
性能与灵活是系统设计中的一对矛盾,似乎是系统设计人员而不是项目管理人员应该考虑的问题。但实际上,由于国内的许多ERP系统的失败都与这个矛盾处理得不当有关,因此,我们认为应该在项目管理中充分考虑性能与灵活的关系,随时提醒系统设计人员处理好这个矛盾。性能是系统可用性的重要因素,很难想象一个响应速度很慢的系统能得到最终用户的认可。而灵活性是系统适应变化能力的重要因素,一个无法适应工作模式变化的系统也是难以推行的。然而,根据传统的ERP系统理论,增加灵活性将增加系统复杂性,降低系统性能。那么,应该如何对待这对矛盾呢?
在目前的情况下,相对系统性能来说,灵活性是矛盾的主要方面,其原因有如下两点:
(1)由于目前大部分单位的管理模式都处在探索阶段,可能引起变动的因素很多,因此根据现行的管理模式设计出的ERP系统将面临使用单位管理模式的变化的考验。所以现在的ERP系统在设计时要充分考虑这些不确定因素,灵活才能适应这些变化。
(2)由于计算机技术的发展,计算机硬件速度飞速提高,系统性能的极大地提高,从而增加灵活性所引起的系统性能的下降并不明显。
当听到软件编程人员说:“为了提高运行速度,我们假设某个参数是不变的”、“如果想加一种查询方式,可能要改动表结构”时,项目管理人员应引起足够的重视。提醒软件编程人员要充分考虑到用户方需求的灵活性,在软件设计中,要尽量避免用牺牲系统灵活性来换取系统性能的提高。而是应在程序设计方面通过优化程序结构来提高系统性能。
ERP系统开发方面已有比较成熟的工程化的方法。但是工程化开发方法仍然不能保证其一定开发成功,还需要有完善的项目管理方法来保证。每个项目的开发环境及实施环境各不相同。因此,在项目管理方面所面临的问题均不尽相同。但是在项目管理中所要处理的关系却基本相同。如何处理好这些关系是项目管理人员的重要任务。本文对项目管理中所要处理的关系及经常遇到的问题进行了讨论,希望能对项目管理人员及系统开发人员有所帮助。笔者相信随着项目管理方法的不断完善,必将为ERP开发的成功提供进一步的保证。
读过这篇文章的人还读过:
4006199527