浅谈企业管理信息系统的成功与失败 杨松 几乎每个组织的信息系统建设中都不同程度地遇到过类似的问题。有的花费了比预期计划多得多的金钱利时间，使公司没法收回投资。有的系统不能正确地实现设计功能，使组织中的问题不能获得有效的解决。因而，使用者、设计者和开发者都应该对系统的成功和失败原因及方式加以研究。 技术因素只是新系统成败的原因之一，管理和组织的因素往往起到更大的作用。因为系统建设过程正是一个组织变动的过程。本文将说明管理、组织和技术因素如何影响着系统的成功与失败。 第一部份 信息系统的失败 据调查约有百分之七十五的大系统是失败的，尽管这些系统可能也在运行。 它们或者是大大超出了预计的时间和经费，或者是没能实现预期的功能。研究表明，有许多项目处在不良状态。有的设计不良，有的数据不准确、不完整，有的交付以后没有使用，有的超过预算并且严重拖期，更严重的需要返工重来。甚至不了了之。 系统失败，并不一定指系统彻底崩溃。它们或者是明显地不能按约定方式使用；或者是根本就不能用，用户不得不开发一些手工过程与系统一起运行；或者是产生出的各种报告对决策者没有帮助，根本就没有人去看；或者是因为系统内所用的数据不准确，使人们感到系统不可靠；或者是系统不够“健壮”经常“死机”，需要重新启动，使系统的维护人员总是处于处理和应付日常操作当中发生的各种意外，修补程序和数据的问题。所有这些情形，都可以发生的各种意外，修补程序和数据的问题。所有这些情形，都可以看做系统失败的表现。 系统为什么会失败呢? 一、信息系统的问题 引起信息系统失效的问题是多元的，主要可以归为设计、数据、费用和运行四个方面。这些问题的产生不仅有技术上的原因，也有许多非技术因素，尤其是组织方面的因素。 设计问题 设计中容易产生两类问题。一类与技术有关，另一类是非技术问题。比较明显的技术问题是功能问题。由于设计上的缺陷，系统功能不能满足用户的基本需求。比如，响应速度慢，达不到用户要求；提供的信息不明确，不便于理解和使用；系统不能提高组织的运转效率，也不能改进管理的质量。用户接口设计不良也是常见的技术问题。有些用户界面设计得过于复杂，屏幕排列混乱，容易误操作；还有的菜单嵌套层次太探．排列不合理，操作顺序烦琐，造成用户不便于使用，甚至不愿意使用。数据库设计不良是更为严重的技术问题，存在有害的数据冗余，缺少数据完整性控制，代码设计不周全等等都会成为系统潜在的威胁。 非技术性的设计问题与管理和组织理论有关。管理和组织理论认为，信息系统是组织的密不可分的一个组成部分，它与组织中的其他要素，如结构、任务、目标、人员、文化等都有着内在的紧密的联系，应该完全相容。当组织中的信息系统发生变化时，必然会影响到组织的结构、任务、人员、文化等等发生相应的变化，系统建立的过程就是一个组织再设计的过程。如果新的信息系统不能与组织中的其他要素相容，这个系统也被视做是失败的。人们总是倾向于对系统设计中的技术问题持别给予较多的关注，后果是会产生一些技术上先进但与组织的结构、文化和目标却不相容的系统。这种系统没有能给组织带来协调和高效，而是产生了紧张、不安、抵触和冲突。 数据问题 数据方面的问题容易被开发人员所忽略。到正式运行以后才越来越严重，最后可能导致系统失败。系统中数据的不准确(含有错误)、不确切(有二义性)、输入不完整(缺项)、不一致等都会导致系统不能正常工作。这些问题如果不能及时地得到解决，用户会丧失对系统的信任，最终将放弃使用。首次开发的新系统和新录入的数据更容易发生数据问题。 费用问题 有些系统开发得很好，运行得也很好，但是运行成本过高，超过了原来的预算；还有些系统在开发时就产生了超支现象，最后因为财务经费不堪重负而下马。这两种情况都不能算做成功。 运行问题 系统运行得不好是最令人烦恼的。经常性的死机，重启动会导致用户不能及时获得信息。在线联机系统如果响应时间过长，也会有类似的后果。尽管这些系统功能的设计可能是正确的、完美的，最后也会被这些运行问题拖垮。 二、成功的标准 如何判定一个信息系统是否成功，这是一个较难回答的问题。因为系统成功与失败的问题是一个多元化、多视角的问题。对同一个系统，高层领导与低层立接用户的评价不会一样，刚毕业的MBA学生与有着多年工作经验的管理人员的意见有可能相悖，甚至同一个组织中的不同管理人员，因为他们的决策风格不同(比如，一个习惯于靠经验和直觉，而另一个倾向于靠数据)，也会得出不同的结论。尽管如此信息系统专家们还是总结出了若干评价的准则。 (1)系统的使用率：可以通过用户调查、发放问卷、统计在线完成事务处理的数量(例如，联机订票量)等方式加以测量。 (2)用户对系统的满意度：通过问卷或面谈，了解用户对系统性能的意见，它包括信息的准确性、及时性和实用性，是否提高了工作的效率和质量。另外，还要特别注意管理者们的意见，他们认为系统在多大程度上满足了他们的信息笛求。 (3)用户对系统的态度：用户是否对系统以及系统的工作人员持肯定的和积极的态度。 (4)实现目标的程度：运行新系统后，用户组织运营的绩效与决策过程的改进，都能够反映出系统达到预期目标的程度。 (5)财务上的收益：包括降低成本、增加产量和利润等等。 需要注意的是第五项准则要恰当地运用，不是系统所有的效益都能量化成财务收益。人们对系统的评价已经越来越多地看重系统对组织运营以及组织中的成员所产生的影响等无形效益。 第二部分 信息系统成败的原因 信息系统的建立动因来自于组织内部的需求与外部环境的压力；信息系统的失败也同样源于内部与外部的抵制。 一个组织一旦引入了一套信息系统，该系统就会对这个组织的管理和行为产生重大的影响。组织内个人与团体之间的人际关系会发生变化，为管理组织的各种资源所需要的信息处理方式也会发生变化，这些变化最终将导致权力的再分配，并引起一些内部工作人员对系统的抵制，严重时会使一个各方面都不错的信息系统搁浅。这些系统都有一个共同的特点：为实现某个特定的系统功能，系统要求它的使用者必须改变他们的行为，即改变他们原有的工作方式和工作习惯。 除了由于内部的抵制会引起系统失败以外，还有一些其他的原因。我们常常会发现．在一些十分类似的组织中，同样的一个系统，在有些组织中获得了成功，而在另一些组织中却失败了。这又是为什么呢？一种解释是，他们采用了不同的实施方式。 一、实施的概念 实施是一个组织将一项创新或建议从概念转化成现实的全部活动。包括对创新的采纳、管理和例行化三个阶段。不同的学派对实施活动研究有不同的侧重点，他们从不同侧面研究了实施的成功要素。表1反映了三种学派对实施活动的研究。 表1 三种学派对实施活动的研究 不同学派的侧重点 实施的三个阶段   采纳 管理 例行化  人的作用 × ×   策略 × ×   组织因素  × ×  一些学者认为，实施的效果主要依靠人的作用。要成功地实施一个系统，首先必须精心挑选出一些实施活动的骨干，这些人应在组织中有一定的地位，有较高的学历，有良好的技术素养和丰富的社会与组织经验。他们能在纠织中积极而又稳妥地推进改革，确保实施的成功。这些骨干的带动作用在实施的前两个阶段(采纳与管理)尤为重要。 另一些学者则关心改革的策略。一个系统的实施，可能是自上而下贯彻，也可能由基层开始推广，但不论是哪一种情况，如果缺少上层领导的支持，系统从实施的开始阶段就注定了失败的命运。这已经被大量的实例所证明。我国学者在80年代末提出的“一把手原则”就是强调了高层领导的作用。另一方面，如果缺少基层的最终用户的参与，也会导致信息系统的失败。 第三种观点认为，一个成功的信息系统的实施，取决于组织的一系列关键活动。这些活动都是对创新内容能否变成该组织长期的例行行为有决定意义(表2)。 某些学者在研究了系统分析人员在整个实施过程中的作用以后认为，他们是变革的某种催化剂。系统分析员不仅要提出新系统的技术方案，而且要提出新的组织方案。他们要提出新系统环境下机构应如何设置、每个人的职务与职责有什么变化、各部门之间应如何制约、权力应如何调整。系统分析人员要在各部门以及最终用户之间不断进行沟通，以确保新系统带来的组织上的各种变化能最终让所有部门和成员接受。显然这是一个十分艰巨的任务。这 不仅对系统分析人员提出了很高的学识和能力上的要求，也说明了为什么系统实施会有那么多的失败。 另有些学者通过建立一些描述实施的不同阶段当中系统设计人员、用户、决策者之间相互关系的模型对实施过程进行研究。尽管他们的模型各不相同，但归纳起来主要集中于下列几个问题： ·技术人员以技术为中心和用户以业务和组织为中心的观念的冲突； ·信息系统对组织结构、工作群体和行为的影响； ·系统开发活动的计划与管理； ·用户在系统设计与开发过程中参与的程度。 表2 成功的实施所需要的活动和标志 有专用基金的支持 改变组织内的权力分配  更新组织机构 培训由组织内部完成  稳定的供应与维护 能不断地更新系统  调整人员的级别 对关键人员进行鼓励  得到广泛的适用 系统的生存不依赖于最初的开发者  二、实施成功与失败的原因 人们已经认识到系统的失败不能简单地用单一的原因来解释，它的成功也没有一个唯一的方法和模式。实施的最后结果在很大程度上是由下述四项因素决定的： ·用户在实施过程中的作用； ·管理层在实施中给予的支持程度； ·实施项目本身的复杂程度和风险的大小； ·对实施过程进行管理的质量。 1.用户的参与与影响 用户参与信息系统的设计与操作有许多好处。首先，用户如果能较深入地介入系统设计，他们就能使设计出的模型更符合业务要求；其次，由于他们自己已经成为变革过程的活跃参与者，所以他们会对整个系统持积极的态度。 虽然多听取用户的意见能改进系统的设计，但是也应该注意到用户的局限性。他们受过去自己工作经验的束缚可能难以提出如何利用信息系统对原有的业务流程做重大改进的方案。这时候，专业系统设计人员的作用就显得更为重要了。 用户参与的另一个老问题是用户与设计人员的交流障碍问题。用户与专业设计人员有不同的背景、不同的兴趣，他们分别隶属于不同的组织。当他们共同开发—个信息系统的时候，仍然会有本同的考虑问题、讨论问题和解决问题的方式，不同的词汇和语言，不同的组织忠诚态度。例如，专业系统设计人员总是倾向于提出复杂的技术解决方案，向用户讲述该方案的软硬件效率是如何的高，使用起来是如何的方便快捷；而用户则要求系统能解决业务中的实际问题，促进组织达到预期的目标。双方常常会各执一词，互不相让，都不愿意也不能够用对方的观点和词汇来讨论问题。 表3列出了双方考虑问题的不同思路与视角。 表3 用户与专业设计人员的交流障碍 用户关注的 设计人员关注的  该系统能够提供我所需要的信息码？ 访问数据有多快？ 提取数据有多容易？ 要多少人来录入数据？ 系统的操作是否符合我的日常业务？ 主文件要占用多少外存空间？ 为完成此项功能要写多长程序代码？ 运行系统是怎样才能减少占用CPU的时间？ 存储某类数据最有效的方式是什么？ 应该采用哪种数据库系统？  这种交流障碍会导致系统不能比较完整地反映出用户的要求，严重时会将用户“挤出”整个系统实施的过程。参与系统实施是很花费时间的，这会影响用户正常的业务工作。如果用户在参与过程中经常发现他们不能理解专业设计人员在说些什么，就会影响他们的热情。他们会认为自己不懂系统开发，这些工作还是留给专业设计人员去做吧。他们会消极地敷衍专业人员，最终退出设计，当整个实施过程都是由清一色的计算机专业人员完成的时候，系 统的失败就难免了。 2.管理层的支持 如果一个信息系统项目在各个层次上都能得到管理人员的支持，那么该系统就很可能被用户和专业开发人员从正面给予理解。他们都会感到，参与开发过程会受到高层领导的注意和重视，他们的努力和付出都会得到回报。管理层的重视还会保证项目能够获得足够的资金和其他必要的资源支持。 当系统要改变原有的工作习惯和流程的时候，尤其是要重新改组原有的组织结构的时候，领导层的支持就更不可缺少，如果缺少这种支持或支持的力度不够，都会造成失败。 3.复杂性和风险 信息系统依照其规模、范围、复杂度、技术含量和组织要素的不同而有很大的不同。它们实施的成功可能性也因其风险的大小而异。影响系统风险的要素主要可以从三个方面来进行考察： 项目规模 规模可以由项目所需要的资金、实施项目所需要人员的数量和时间、项目所影响到的单位和部门的数量来衡量。显然规模越大的项目风险也越大。 系统的结构化程度 系统的结构化程度是指系统输入输出以及数据处理过程的确定性。结构化程度高的系统有明确的输入输出定义和处理过程定义。结构化程度低的系统则相反，用户常常说不清楚究竟需要什么，或者需求常常随着用户不同、时间不同和情况不同而不断改变。结构化程度高的系统风险就小。 技术经验 如果开发小组缺乏技术经验，项目将面临较大的风险。如果开发小组不熟悉所需要的硬件、软件和数据库，他们将可能为了熟悉这些内容而耗用额外的时间，使项目拖期。 表4给出了不同情况下的项目风险。 表4 项目风险的三个方面 结构化程度 技术水平 项目规模 风险程度  高 低 大 低  高 低 小 很低  高 高 大 中  高 高 小 中偏低  低 低 大 低  低 低 小 很低  低 高 大 很高  低 高 小 高  4.实施过程的管理 项目的实施过程需要有效的管理，由于项目实施中有相当多的不确定因素和人的因素，使得这一过程的管理变得异常困难。如果管理不当，就会造成许多后果： ·投资严重超过预算； ·工期大大地超出了计划； ·技术缺陷导致得不到预期的效果； ·没有能获得预期约收益。 项目实施的管理中经常遇到的困难有以下五种： 用户需求难以确定 不仅不同的用户对同一信息可能有不同的理解和解秤，从而会产生不同的需求，有时同一用户也会因时间地点的不同而提出不同的要求，使得用户需求的定义难以具体地确定。 工作量难以确定 用户需求不确定是引起工作量难以确定的原因之一，更重要的原因是迄今为止仍然缺少有效的技术与方法事先估算系统分析与系统设计所需要的时间。理论研究与教学中只是分析了一些比较简单的小系统，大系统的估算仍然缺少方法。实践经验也难以借鉴，因为信息技术发展很快，许多大型甚至小型系统也都是“首次开发”，并且没有先期经验可供借鉴。估算的计划往往与实际相差很大，不准确的计划会直接影响到实施过程的控制，导致时间的拖 期、预算的突破甚至系统的失败。 实施难以按期完成 系统不能按期交付是引起用户抱怨的最常见的原因之—。大多数系统都不能如期交付，或者留有“尾巴”，常常许诺用户“未完成的功能将在下一版中完成”。实施工作不能按计划完成的原因有两个方面：计划制订得不合理；实施中遇到了意外，但是又无法有效地“赶工”，以弥补延误的工期。 系统实施的计划工期常常订得偏短，这可能是迫于用户的压力，因为用户一般很难接受过长创开发周期；也可能是由于计划的制订者的盲目乐观，现代信息系统购技术在快速地更新，规模也越来越大。网络的普及又增加了复杂程度，这些都使得计划者的经验不断过时。他们在估算工期时普遍有盲目乐观的倾向。系统越大倾向也越严重。 即使计划工期订得比较合理，还是可能因各种意外而产生拖期。与许多工程项目的实施不同，信息系统项目的实施一旦发生延误，就很难加以弥补。对于工作量一定的工程项目(一般用人·月表示)通常只要增加实施过程的人员，就可以有效地缩短工期和进行赶工。但是在信息系统项目中靠增加人力来缩短工期效果十分有限。因为所有参加开发的人员之间总是需要经常地大量地进行沟通，这种沟通所耗费的资源(时间、经费)，随人数的增多会按指数关系上升，有时增加入以后反而会产生更多的混乱与返工，最后造成更大的延迟，除非对这些人经过长期的很好的培训。我们可以设想让五个业余运动员加入到一个冠军篮球队当中一起去打比赛会有什么结果？起码在短期内他们更加难以赢球。 高层领导难以及时地了解问题 坏消息向上传递速度较侵，报喜不报忧，几乎是所有组织中都存在的通病。实施中各阶段发生的问题往往会被中层滤掉，不能及时反映到管理和决策的高层中去。这使出现的一些错误得不到及时纠正，继续发展扩大直至积累到难以纠正时，才报告给高层领导。这样的案例国内外都有很多。 用户的感受和态度容易被忽视 尽早地对用户进行系统的功能与开发方法的讲解、培训和说明，让他们深人地理解系统所有潜在的功能和可能产生的组织结构与职务、岗位、职责的变化、鼓励他们支持并参与系统的开发，会有力地保证项目的成功。这一点常常被忽视。由于重视不够和缺少足够的经费与资源而使得培训工作做得不充分和完全没有做的情况时有发生，在项目开始阶段缺少培训更是常见。 三、业务再造工程的挑战 业务再造是信息系统建设的一种高级形式，它要求将组织中的业务过程做比较彻底的再设计，组织本身也会产生深刻的变化。组织可以从中获得更大的收益，也同时承担了更大的风险。调查表明，70％的业务再造工程项目未能获得预期的结果。对项目完全满意的只占16％，68％的主管报告说产生了许多意外的副作用，解决旧问题的同时又产生了新问题。 在失败的案例中只有一小部分是由于对业务再造工程本身的理解不充分造成的。高层管理人员未能提出需要通过业务再造来解决的关键问题，没有能理解对主要业务过程做彻底的根本改造与做简单改良的区别，他们在实施过程中只是对原有的业务流程做了一些改良、改进，并没有从根本上进行再设计，当然也就没有能取得明显的效果。 更多的失败却是来自于不良的实施过程和对实施过程的管理不当。尤其是如果不能处理好实施过程中组织内普遍存在的不安心与担心情绪，将会导致员工对改革的抵制。统计表明，这种内在的抵制是造成失败的重要因素。一项调查的被调查者可以在诸多失败因素中选出几项最重要的因素，结果60％的人认为抵制是再造工程项目成功的最大障碍。 如果系统实施过程管理不善，系统开发的各个阶段都有可能出现问题。下面列出的是一些典型问题。 1.分析阶段 ·没有为研究存在的问题分配足够的时间、经费、人力等资源，因而问题仍然不能很好地定义，项目实施的目标含混不清，效益也无法衡量。 ·初步规划过于草率，对项目所需时间与经费的估计缺乏标准。 ·项目组组织不当。没有足够的专职人员，系统的最终用户在项目组里也没有代表。 ·一些开发组成员向用户承诺了一些不可能完成的任务。 ·用户需求来自于原系统不完善的文档和来自于不完备的系统分析活动。 ·用户拒绝向项目组提供必要的信息。 ·项目分析人员缺乏与别人交流的能力与技巧，不能与用户恰当地交谈，不会对用户提出适当的问题，不能与用户做深入的交流。 2.设计阶段 ·用户没有参与设计，设计方案完全是计算机专业人员完成的。受这些人员个人偏好的影响，设计方案与组织原有的结构、活动、文化吻合得不好。 ·设计只考虑了当前的需要而没有能够顾及组织未来的需要。 ·业务流程及人员必须要做重大改变的设计中，缺乏这些改变可能对组织产生哪些影响的考虑与分析。 ·工程设计的说明书不完善。 3.编程阶段 ·对软件开发所需要的时间与费用的预算被低估。 ·对程序员提供的说明书不完备。 ·大量时间花在编写程序代码上，用于研究程序之间逻辑的时间不足。 ·程序员没有充分利用结构化和面向对象的编程方法的优点，他们编写的程序难于修改和维护。 ·程序缺少完整的文档。 ·机时等必要的资源没有做出计划。 4.测试阶段 ·正常的测试所需要的时间与费用被低估。 ·项目组没有制定有组织的测试计划。 ·用户没有充分地参与测试。他们不愿提供测试用的数据样本，不愿意检验测试的结果，不愿意为测试耗费时问。 ·项目组没有为高层管理人员提供验收测试的办法，管理人员不能审核和签署测试的结果。 5.转换阶段 ·转换所需要的时间与经费估计不足，特别是数据的转换。 ·转换开始以前用户从未接触过新系统，到系统要安装的时候才开始对用户进行培训。 急于投入运行。 ·系统和用户文档不完整。 ·绩效评估没有进行，没有建立评价的标准，也没有把系统运行的结果同早先的目标相比较。 ·对系统维护工作的预见性不足。受过维护培训的专业信息系统维护人员不够。