信息系统的管理与控制.doc

第9章信息系统的管理与控制引例 加州的机动车管理局1965年，加州的机动车管理局（DMV）的联机系统还是热门技术，25年以后，他们已经用该系统处理了五千万个驾驶执照和车辆登记，同时还处理每年五十二亿美元的税收。虽然这个系统已经在升级后的IBM主机上，每天能处理一百万笔业务了，它的软件却赶不上时代的发展，它们是用汇编语言写成的，非常难以维护。为了在执照和登记上加上一项“社会保障号码”，需要用18个人年去编制程序。虽然它在旧式的文件系统中仍能够很快地提取数据，但是却不能完成有条件的搜索和查询。机动车管理局的地方机构用的是一些已经有十年役龄的IBM系列小型机和与主机相连接的一些简易终端，这些设备也都有些过时了。1987年，机动车管理局启动了一个雄心勃勃的项目，他们把系统转换到SQL关系数据库上，该系统在24台协力公司的计算机上运行。为了在这个新的技术平台上开发应用软件，他们又雇佣了E.Y.咨询公司，该公司用COBOL与第四代开发工具工作。后来，这个项目搁浅了，E.Y.公司也于1990年退出了该项目。取而代之的是管理局自己的人员。他们打算靠自己的力量用德州仪器公司的CASE开发工具IEF完成应用软件的开发。不幸的是，他们内部的开发人员没有能克服学习新的开发工具所遇到的巨大困难。七年过去了，这个管理局在花了四千四百万美元以后终于停止了再向该项目注入资金。他们开始明白，这并不单单是一个编写应用软件的问题。他们可能还要再投入一亿美元和四年的时间才能使该项目完成。经过一段调查后，管理局的一位发言人解释说，我们决定采用的这个数据库并没有经过检验，它无法处理我们每天来自三万个用户的业务数据。协力公司却认为，自己已经完全尽了职责，并把失败的原因归咎于E.Y.公司退出后项目管理的混乱。E.Y.公司说，我们介入了还不到一年，不能对失败负责。机动车管理局一筹莫展，只好凑合着用那套已经陈旧的技术和花了四千四百万美元更新来的却并不好用的数据。9.1信息系统的成功与失败据加州有关部门介绍，车辆管理局的项目并不是唯一的一个管理不善的大中型项目。实际上，加州有许多项目，一直被计算机系统互不兼容、各部门数据库难以互访、缺乏共同标准等问题所困扰。车辆管理局的例子不是个别的现象，几乎每个组织的信息系统建设中都不同程度地遇到过类似的问题。有的花费了比预期计划多得多的金钱和时间，使公司没法收回投资。有的系统不能正确地实现设计功能，使组织中的问题不能获得有效的解决。因而，使用者、设计者和开发者都应该对系统的成功和失败原因及方式加以研究。技术因素只是新系统成败的原因之一，管理和组织的因素往往起到更大的作用。因为系统建设过程正是一个组织变动的过程。本节将说明管理、组织和技术因素如何影响着系统的成功与失败，讨论实施过程的重大意义、对实施过程的正确管理及实施正确的内部控制机制。一、信息系统的失败据调查约有百分之七十五的大系统是失败的，尽管这些系统可能也在运行。它们或者是大大超出了预计的时间和经费，或者是没能实现预期的功能。对美国联邦政府项目的研究表明，有许多项目处在不良状态。有的设计不良，有的数据不准确、不完整，有的交付以后没有使用，有的超过预算并且严重拖期，更严重的需要返工重来，甚至不了了之。系统失败，并不一定指系统彻底崩溃。它们或者是明显地不能按约定方式使用；或者是根本就不能用，用户不得不开发一些手工过程与系统一起运行；或者是产生出的各种报告对决策者没有帮助，根本就没有人去看；或者是因为系统内所用的数据不准确，使人们感到系统不可靠；或者是系统不够“健壮”经常“死机”，需要重新启动，使系统的维护人员总是处于处理和应付日常操作当中发生的各种意外，修补程序和数据的问题。所有这些情形，都可以看做系统失败的表现。系统为什么会失败呢？（一）信息系统的问题引起信息系统失败的问题是多元的，主要可以归为设计、数据、费用和运行四个方面。这些问题的产生不仅有技术上的原因，也有许多非技术因素，尤其是组织方面的因素。设计问题设计中容易产生两类问题。一类与技术有关，另一类是非技术问题。比较明显的技术问题是功能问题。由于设计上的缺陷，系统功能不能满足用户的基本需求。比如，响应速度慢，达不到用户要求；提供的信息不明确，不便于理解和使用；系统不能提高组织的运转效率，也不能改进管理的质量。用户接口设计不良也是常见的技术问题。有些用户界面设计得过于复杂，屏幕排列混乱，容易误操作；还有的菜单嵌套层次太深，排列不合理，操作顺序烦琐，造成用户不便于使用，甚至不愿意使用。数据库设计不良是更为严重的技术问题，存在有害的数据冗余，缺少数据完整性控制，代码设计不周全等等都会成为系统潜在的威胁。非技术性的设计问题与管理和组织理论有关。管理和组织理论认为，信息系统是组织的密不可分的一个组成部分，它与组织中的其他要素，如结构、任务，目标、人员、文化等都有着内在的紧密的联系，应该完全相容。当组织中的信息系统发生变化时，必然会影响到组织的结构、任务、人员、文化等等发生相应的变化，系统建立的过程就是一个组织再设计的过程。如果新的信息系统不能与组织中的其他要素相容，这个系统也被视做是失败的。人们总是倾向于对系统设计中的技术问题特别给予较多的关注，后果是会产生一些技术上先进但与组织的结构、文化和目标却不相容的系统。这种系统没有能给组织带来协调和高效，而是产生了紧张、不安、抵触和冲突。数据问题数据方面的问题容易被开发人员所忽略。到正式运行以后才越来越严重，最后可能导致系统失败。系统中数据的不准确（含有错误）、不确切（有二义性）、输入不完整（缺项）、不一致等都会导致系统不能正常工作。这些问题如果不能及时地得到解决，用户会丧失对系统的信任，最终将放弃使用。首次开发的新系统和新录入的数据更容易发生数据问题。费用问题有些系统开发得很好，运行得也很好，但是运行成本过高，超过了原来的预算；还有些系统在开发时就产生了超支现象，就像本章篇首中介绍的机动车管理局的项目那样，最后因为财务经费不堪重负而下马。这两种情况都不能算做成功。运行问题系统运行得不好是最令人烦恼的。经常性的死机，重启动会导致用户不能及时获得信息。在线联机系统如果响应时间过长，也会有类似的后果。尽管这些系统功能的设计可能是正确的、完美的，最后也会被这些运行问题拖垮。（二）成功的标准如何判定一个信息系统是否成功，这是一个较难回答的问题。因为系统成功与失败的问题是一个多元化、多视角的问题。对同一个系统，高层领导与低层直接用户的评价不会一样，刚毕业的MBA学生与有着多年工作经验的管理人员的意见有可能相悖，甚至同一个组织中的不同管理人员，因为他们的决策风格不同（比如，一个习惯于靠经验和直觉，而另一个倾向于靠数据），也会得出不同的结论。尽管如此信息系统专家们还是总结出了若干评价的准则。（1）系统的使用率：可以通过用户调查发放问卷、统计在线完成事务处理的数量（例如，联机订票量）等方式加以测量。（2）用户对系统的满意度：通过问卷或面谈，了解用户对系统性能的意见，它包括信息的准确性、及时性和实用性，是否提高了工作的效率和质量，另外，还要特别注意管理者们的意见，他们认为系统在多大程度上满足了他们的信息需求。（3）用户对系统的态度：用户是否对系统以及系统的工作人员持肯定的和积极的态度。（4）实现目标的程度：运行新系统后，用户组织运营的绩效与决策过程的改进，都能够反映出系统达到预期目标的程度。（5）财务上的收益：包括降低成本、增加产量和利润等等。需要注意的是第五项准则要恰当地运用，不是系统所有的效益都能量化成财务收益。人们对系统的评价已经越来越多地看重系统对组织运营以及组织中的成员所产生的影响等无形效益。二、信息系统的成功信息系统的建立动因来自于组织内部的需求与外部环境的压力；信息系统的失败也同样源于内部与外部的抵制。一个组织一旦引入了一套信息系统，该系统就会对这个组织的管理和行为产生重大的影响。组织内个人与团体之间的人际关系会发生变化，为管理组织的各种资源所需要的信息处理方式也会发生变化，这些变化最终将导致权力的再分配，并引起一些内部工作人员对系统的抵制，严重时会使一个各方面都不错的信息系统搁浅。这些系统都有一个共同的特点：为实现某个特定的系统功能，系统要求它的使用者必须改变他们的行为，即改变他们原有的工作方式和工作习惯。除了由于内部的抵制会引起系统失败以外，还有一些其他的原因。我们常常会发现，在一些十分类似的组织中，同样的一个系统，在有些组织中获得了成功，而在另一些组织中却失败了。这又是为什么呢？一种解释是，他们采用了不同的实施方式。（一）实施的概念实施是一个组织将一项创新或建议从概念转化成现实的全部活动。包括对创新的采纳、管理和例行化三个阶段。不同的学派对实施活动研究有不同的侧重点，他们从不同侧面研究了实施的成功要素。表9-1反映了三种学派对实施活动的研究。表9-1 三种学派对实施活动的研究不同学派的侧重点实施的三个阶段采纳管理例行化人的作用策略组织因素一些学者认为，实施的效果主要依靠人的作用。要成功地实施一个系统，首先必须精心挑选出一些实施活动的骨干，这些人应在组织中有一定的地位，有较高的学历，有良好的技术素养和丰富的社会与组织经验。他们能在组织中积极而又稳妥地推进改革，确保实施的成功。这些骨干的带动作用在实施的前两个阶段（采纳与管理）尤为重要。另一些学者则关心改革的策略。一个系统的实施，可能是自上而下贯彻，也可能由基层开始推广，但不论是哪一种情况，如果缺少上层领导的支持，系统从实施的开始阶段就注定了失败的命运。这已经被大量的实例所证明。我国学者在80年代未提出的“一把手原则”就是强调了高层领导的作用。另一方面，如果缺少基层的最终用户的参与，也会导致信息系统的失败。第三种观点认为，一个成功的信息系统的实施，取决于组织的一系列关键活动。这些活动都是对创新内容能否变成该组织长期的例行行为有决定意义（表9-2）。某些学者在研究了系统分析人员在整个实施过程中的作用以后认为，他们是变革的某种催化剂。系统分析员不仅要提出新系统的技术方案，而且要提出新的组织方案。他们要提出新系统环境下机构应如何设置。每个人的职务与职责有什么变化、各部门之间应如何制约、权力应如何调整。系统分析人员要在各部门以及最终用户之间不断进行沟通，以确保新系统带来的组织上的各种变化能最终让所有部门和成员接受。显然这是一个十分艰巨的任务。这不仅对系统分析人员提出了很高的学识和能力上的要求，也说明了为什么系统实施会有那么多的失败。表9-2 成功的实施所需要的活动和标志有专用基金的支持改变组织内的权力分配更新组织机构培训由组织内部完成稳定的供应与维护能不断地更新系统调整人员的级别对关键人员进行鼓励得到广泛的使用系统的生存下依赖于最初的开发者有些学者通过建立一些描述实施的不同阶段当中系统设计人员、用户、决策者之间相互关系的模型对实施过程进行研究。尽管他们的模型各不相同，但归纳起来主要集中于下列几个问题：技术人员以技术为中心和用户以业务和组织为中心的观念的冲突；信息系统对组织结构、工作群体和行为的影响；系统开发活动的计划与管理；用户在系统设计与开发过程中参与的程度。（二）实施成功与失败的原因人们已经认识到系统的失败不能简单地用单一的原因来解释，它的成功也没有一个唯一的方法和模式。表9-3给出了企业成功实施系统的关键因素表9-3 企业成功实施系统的关键因素影响因素重要性高层领导的支持明确的目标和方向数据的准确性和完整性各部门之间的相互合作人员的教育与培训各部门之间的相互沟通人员的激励与责任合适的硬件和软件企业对信息技术的熟悉程度4.934.744.674.564.414.374.114.074.00同时，实施的最后结果在很大程度上是由下述四项因素决定的：用户在实施过程中的作用；管理层在实施中给予的支持程度；实施项目本身的复杂程度和风险的大小；对实施过程进行管理的质量。1用户的参与与影响用户参与信息系统的设计与操作有许多好处。首先，用户如果能较深入地介入系统设计，他们就能使设计出的模型更符合业务要求；其次，由于他们自己已经成为变革过程的活跃参与者，所以他们会对整个系统持积极的态度。虽然多听取用户的意见能改进系统的设计，但是也应该注意到用户的局限性。他们受过去自己工作经验的束缚可能难以提出如何利用信息系统对原有的业务流程做重大改进的方案。这时候，专业系统设计人员的作用就显得更为重要了。用户参与的另一个老问题是用户与设计人员的交流障碍问题。用户与专业设计人员有不同的背景、不同的兴趣，他们分别隶属于不同的组织。当他们共同开发一个信息系统的时候，仍然会有不同的考虑问题、讨论问题和解决问题的方式，不同的词汇和语言，不同的组织忠诚态度。例如，专业系统设计人员总是倾向于提出复杂的技术解决方案，向用户讲述该方案的软硬件效率是如何的高，使用起来是如何的方便快捷；而用户则要求系统能解决业务中的实际问题，促进组织达到预期的目标。双方常常会各执一词，互不相让，都不愿意也不能够用对方的观点和词汇来讨论问题。表9-4列出了双方考虑问题的不同思路与视角。表9-4 用户与专业设计人员的交流障碍用户关注的设计人员关注的该系统能够提供我所需要的信息吗？主文件要占用多少外存空间？访问数据有多快？为完成此项功能要写多长的程序代码？提取数据有多容易？运行系统时怎样才能减少CPU的时间？要多少人来录入数据？存储某类数据最有效的方式是什么？系统的操作是否符合我的日常业务？应该采用哪种数据库系统？这种交流障碍会导致系统不能比较完整地反映出用户的要求，严重时会将用户“挤出”整个系统实施的过程。参与系统实施是很花费时间的，这会影响用户正常的业务工作。如果用户在参与过程中经常发现他们不能理解专业设计人员在说些什么，就会影响他们的热情。他们会认为自己不懂系统开发，这些工作还是留给专业设计人员去做吧。他们会消极地敷衍专业人员，最终退出设计，当整个实施过程都是由清一色的计算机专业人员完成的时候，系统的失败就难免了。2管理层的支持如果一个信息系统项目在各个层次上都能得到管理人员的支持，那么该系统就很可能被用户和专业开发人员从正面给予理解。他们都会感到，参与开发过程会受到高层领导的注意和重视，他们的努力和付出都会得到回报。管理层的重视还会保证项目能够获得足够的资金和其他必要的资源支持。当系统要改变原有的工作习惯和流程的时候，尤其是要重新改组原有的组织结构的时候，领导层的支持就更不可缺少，如果缺少这种支持或支持的力度不够，都会造成失败。3复杂性和风险信息系统依照其规模、范围、复杂度、技术含量和组织要素的不同而有很大的不同。它们实施的成功可能性也因其风险的大小而异。影响系统风险的要素主要可以从三个方面来进行考察：项目规模规模可以由项目所需要的资金、实施项目所需要人员的数量和时间、项目所影响到的单位和部门的数量来衡量。显然规模越大的项目风险也越大。系统的结构化程度系统的结构化程度是指系统输入输出以及数据处理过程的确定性。结构化程度高的系统有明确的输入输出定义和处理过程定义。结构化程度低的系统则相反，用户常常说不清楚究竟需要什么，或者需求常常随着用户不同、时间不同和情况不同而不断改变。结构化程度高的系统风险就小。技术经验如果开发小组缺乏技术经验，项目将面临较大的风险。如果开发小组不熟悉所需要的硬件、软件和数据库，他们将可能为了熟悉这些内容而耗用额外的时间，使项目拖期。表9-5给出了不同情况下的项目风险。表9-5 项目风险的三个方面结构化程度技术水平项目规模风险程度高低大低高低小很低高高大中高高小中偏低低低大低低低小很低低高大很高低低小高4实施过程管理的难题项目的实施过程需要有效的管理，由于项目实施中有相当多的不确定因素和人的因素，使得这一过程的管理变得异常困难。如果管理不当，就会造成许多后果：投资严重超过预算；工期大大地超出了计划；技术缺陷导致得不到预期的效果；没有能获得预期的收益。项目实施的管理中经常遇到的困难有以下五种：用户需求难以确定不仅不同的用户对同一信息可能有不同的理解和解释，从而会产生不同的需求，有时同一用户也会因时间地点的不同而提出不同的要求，使得用户需求的定义难以具体地确定。工作量难以确定用户需求不确定是引起工作量难以确定的原因之一，更重要的原因是迄今为止仍然缺少有效的技术与方法事先估算系统分析与系统设计所需要的时间。理论研究与教学中只是分析了一些比较简单的小系统，大系统的估算仍然缺少方法。实践经验也难以借鉴，因为信息技术发展很快，许多大型甚至小型系统也都是“首次开发”，并且没有先期经验可供借鉴。估算的计划往往与实际相差很大，不准确的计划会直接影响到实施过程的控制，导致时间的拖期、预算的突破甚至系统的失败。实施难以按期完成系统不能按期交付是引起用户抱怨的最常见的原因之一。大多数系统都不能如期交付，或者留有“尾巴”，常常许诺用户“未完成的功能将在下一版中完成”。实施工作不能按计划完成的原因有两个方面：计划制订得不合理；实施中遇到了意外，但是又无法有效地“赶工”，以弥补延误的工期。系统实施的计划工期常常订得偏短，这可能是迫于用户的压力，因为用户一般很难接受过长的开发周期；也可能是由于计划的制订者的盲目乐观，现代信息系统的技术在快速地更新，规模也越来越大。网络的普及又增加了复杂程度，这些都使得计划者的经验不断过时。他们在估算工期时普遍有盲目乐观的倾向。系统越大倾向也越严重。即使计划工期订得比较合理，还是可能因各种意外而产生拖期。与许多工程项目的实施不同，信息系统项目的实施一旦发生延误，就很难加以弥补。对于工作量一定的工程项目（一般用人月表示）通常只要增加实施过程的人员，就可以有效地缩短工期和进行赶工。但是在信息系统项目中靠增加人力来缩短工期效果十分有限。因为所有参加开发的人员之间总是需要经常地大量地进行沟通，这种沟通所耗费的资源（时间、经费），随人数的增多会按指数关系上升，有时增加人以后反而会产生更多的混乱与返工，最后造成更大的延迟，除非对这些人经过长期的很好的培训。我们可以设想让五个业余运动员加入到一个冠军篮球队当中一起去打比赛会有什么结果？起码在短期内他们更加难以赢球。高层领导难以及时地了解问题坏消息向上传递速度较慢，报喜不报忧，几乎是所有组织中都存在的通病。实施中各阶段发生的问题往往会被中层滤掉，不能及时反映到管理和决策的高层中去。这使出现的一些错误得不到及时纠正，继续发展扩大直至积累到难以纠正时，才报告给高层领导。这样的案例国内外都有很多。用户的感受和态度容易被忽视尽早地对用户进行系统的功能与开发方法的讲解、培训和说明，让他们深入地理解系统所有潜在的功能和可能产生的组织结构与职务。岗位、职责的变化，鼓励他们支持并参与系统的开发，会有力地保证项目的成功。这一点常常被忽视。由于重视不够和缺少足够的经费与资源而使得培训工作做得不充分和完全没有做的情况时有发生，在项目开始阶段缺少培训更是常见。（三）业务再造工程的挑战业务再造是信息系统建设的一种高级形式，它要求将组织中的业务过程做比较彻底的再设计，组织本身也会产生深刻的变化。组织可以从中获得更大的收益，也同时承担了更大的风险。对350个企业主管的调查表明，70%的业务再造工程项目未能获得预期的结果。对项目完全满意的只占16%，68的主管报告说产生了许多意外的副作用，解决旧问题的同时又产生了新问题。在失败的案例中只有一小部分是由于对业务再造工程本身的理解不充分造成的。高层管理人员未能提出需要通过业务再造来解决的关键问题，没有能理解对主要业务过程做彻底的根本改造与做简单改良的区别，他们在实施过程中只是对原有的业务流程做了一些改良、改进，并没有从根本上进行再设计：当然也就没有能取得明显的效果。更多的失败却是来自于不良的实施过程和对实施过程的管理不当。尤其是如果不能处理好实施过程中组织内普遍存在的不安心与担心情绪，将会导致员工对改革的抵制。统计表明，这种内在的抵制是造成失败的重要因素。一项调查的被调查者可以在诸多失败因素中选出几项最重要的因素，结果60的人认为抵制是再造工程项目成功的最大障碍。（四）实施过程中的问题如果系统实施过程管理不善，系统开发的各个阶段都有可能出现问题。下面列出的是一些典型问题。1分析阶段没有为研究存在的问题分配足够的时间、经费、人力等资源，因而问题仍然不能很好地定义，项目实施的目标含混不清，效益也无法衡量。初步规划过于草率，对项目所需时间与经费的估计缺乏标准。项目组组织不当。没有足够的专职人员，系统的最终用户在项目组里也没有代表。一些开发组成员向用户承诺了一些不可能完成的任务。用户需求来自于原系统不完善的文档和来自于不完备的系统分析活动。用户拒绝向项目组提供必要的信息。项目分析人员缺乏与别人交流的能力与技巧，不能与用户恰当地交谈，不会对用户提出适当的问题，不能与用户做深入的交流。2设计阶段用户没有参与设计，设计方案完全是计算机专业人员完成的。受这些人员个人偏好的影响，设计方案与组织原有的结构、活动、文化吻合得不好。设计只考虑了当前的需要而没有能够顾及组织未来的需要。业务流程及人员必须要做重大改变的设计中，缺乏这些改变可能对组织产生哪些影响的考虑与分析。工程设计的说明书不完善。3编程阶段对软件开发所需要的时间与费用的预算被低估。对程序员提供的说明书不完备。大量时间花在编写程序代码上，用于研究程序之间逻辑的时间不足。程序员没有充分利用结构化和面向对象的编程方法的优点，他们编写的程序难于修改和维护。程序缺少完整的文档。机时等必要的资源没有做出计划。4测试阶段正常的测试所需要的时间与费用被低估。项目组没有制定有组织的测试计划。用户没有充分地参与测试。他们不愿提供测试用的数据样本，不愿意检验测试的结果，不愿意为测试耗费时间。项目组没有为高层管理人员提供验收测试的办法，管理人员不能审核和签署测试的结果。5转换阶段转换所需要的时间与经费估计不足，特别是数据的转换。转换开始以前用户从未接触过新系统，到系统要安装的时候才开始对用户进培训为了补偿开发工作的超支与超时，系统还没有完全就绪就急于投入运行。系统和用户文档不完整。绩效评估没有进行，没有建立评价的标准，也没有把系统运行的结果同早先的目标相比较。对系统维护工作的预见性不足。受过维护培训的专业信息系统维护人员不够。9.2实施过程的风险控制采取正确的策略使用适当的工具和方法能够较好地解决实施中的一些问题，有助于提高实施的成功率。下面介绍一些可供选用的方法与策略。一、控制风险因素每个系统的开发项目都有许多不确定的因素，因而会有不同程度的风险。根据产生风险的原因可以将风险分成不同的类型和级别，并采取不同的管理策略与工具，对风险进行控制。有四种项目管理的策略与技术可以用来控制风险因素。它们是外联策略、内聚策略、正规计划工具和正规控制工具。表9-6给出了在不同风险等级下，应如何选取这些策略与工具。表9-6 控制实施风险应采取的策略与工具结构化程度技术水平项目规模风险程度应采用的策略与工具高低大低充分利用正规计划和控制工具高低小很低充分利用正规计划工具适当利用正规的控制工具高高大中适当利用正规计划和控制工具高高小中偏低采用高度的内聚策略低低大低采用高度的外联策略充分利用正规计划和控制工具低低小很低采用高度的外联策略充分利用正规控制工具低高大很高采用高度的外联策略采用高度的内聚策略低高小高采用高度的外联策略采用高度的内聚策略1外联策略外联策略是将项目开发组的工作在组织内各个层次上都与用户紧密相联系的一种策略。对于结构化程度较低的系统，实施过程中需要广泛动员用户参与到系统设计中去，将组织变动和用户需求中的各种不确定因素降到最低，这时就可以采取这种外联策略。外联策略包括下述基本内容：用户代表参与项目领导班子，可以直接担任项目组组长或副组长。建立用户方的项目领导小组，对系统设计方案进行评审。用户可以成为项目组当中的骨干。项目的规格说明都可以要求用户正式地审批。与设计有关的重要会议记录在用户间广为散发。给关键用户经常发放项目备忘录。可以委托用户去负责系统的安装和培训工作。用户进行变革的控制。最后的系统设计一经完成，用户便可以负责控制变革的过程。对一些不重要的变动，也可以延缓或者是取消。2内聚策略内聚策略要求项目组全体工作人员要高度集中，紧密配合，协调一致，凝聚成一个整体来完成整个实施活动。这种策略适用于那些技术含量较高的项目。高技术含量项目的成功主要依靠对技术复杂性的良好管理与协调。这要求项目的领导者既懂技术又懂管理。既能与项目组共同探讨技术问题，又能够理顺以技术人员为主的项目组成员之间的相互关系。这种策略的要点如下：项目组成员都应该是富有经验的行家。项目组的领导应该有很高的技术水平和丰富的项目管理经验。项目组应经常开会沟通，重要的会议记录和设计方案要分发给有关的人员。项目组要经常检查自身的技术状况。项目组中大部分成员都有过良好的相互配合工作的历史。项目组成员应该参与各项工作目标和完成期限的计划制定。项目组缺少的重要技术和技巧，必须有办法从外部来获得。3正规计划与控制工具项目的计划工作包括将项目分解成各项任务，确定这些任务的完成顺序，估计完成这些任务的所需时间与所需资源，分派人力、经费、技术等各项资源到各项任务。项目的控制工作包括对项目进展的监督以及必要的调整。计划与控制工具可以直接采用项目管理中常用的正规管理技术，如网络计划（PERT）、横道图（Ganttcharts）、系统说明标准、可行性研究说明、项目批准过程等。这些工具特别适合于管理那些结构化程度高。技术又不很复杂的规模很大的项目。这些项目没有技术难点，需求相对都比较确定，只要利用这些管理工具排定计划，就比较容易获得成功。4克服用户的阻力用户的阻力是项目实施中普遍存在的一种风险。阻力可能是由于对用户的教育、培训、说明不当而引发的，也可能是因为用户个人的原固。前面已多次论述过用户参与实施过程的好处，例如，能使系统更真实地反映用户的需求，使用户感到他们能够驾驭该系统而增加对系统的信任和支持等等。用户的参与除了能带来好处以外，也可能产生一些负面的影响。研究表明，当用户参与设计过程时，有时用户会利用自己的地位按个人的喜好来设计系统，或者希望新系统能够扩大自己的权力。无论新系统最后方案设计成什么样，在受到一部分人支持时，也常常会引起另一些人的反对。这可能是新系统影响了他们的利益，影响了他们的权力或仅仅是因为改变了他们惯有的工作方式与习惯。如果新系统的使用是自愿的，反对者将选择不使用新系统。如果新系统使用不是自愿的，反对者就会以各种不同的方式表现他们的抵触。常见的有日益增多的出错率、经常性的中断、不断地抱怨“太麻烦”，“太不合理了”，甚至会故意破坏。显然只靠用户参与是不能完全解决用户抵制问题的。为解决这类抵制实施的问题，学者们提出三种理论来解释制抵制产生原因：基于人的理论认为产生抵制的原因完全来自于用户本身，他们不能克服人的缺点。例如他们懒惰，不愿意学习新的工作方法。基于系统的理论认为产生用户抵制的原因来自于系统设计不良。例如用户界面混乱、学习操作困难等。交互理论认为用户的抵制是系统因素与人的因素交互作用的结果。例如，一个设计良好的系统只得到一部分人的欢迎，另外一些人因为担心新系统会消弱自己的特权和取代自己的位置，因而采取抵制态度。克服用户阻力的策略可以有如下几种：基于人的：对用户进行良好的培训用法令和行政手段强制执行说服教育鼓励用户参与并承担一些义务。基于系统：对用户进行教育改进人机界面用户参与设计的改进必要时对系统进行修改以满足组织的要求。交互的：应用新系统前先解决好组织问题重新设计用户的激励办法与制度重新确定用户与设计者之间的关系在适当的时候鼓励用户参与实施。显然用户参与的效果并不都是积极的，把握好鼓励用户参与的时机与条件，是克服用户阻力的策略之一。（二）设计中的组织因素和人的因素由于开发新系统的最终目的是为了提高组织的绩效，所以我们把全部系统开发的过程看做是一个有计划的组织变革过程。新系统建立的同时，也必须明确提出组织变革的方式与内容。除了指出业务流程会发生哪些变化以外（这在许多系统开发中都做到了），还要说明每个岗位职责的变化，组织结构的调整与变化，人员之间制约关系的变化，每个人权力的变化以及人们行为上的变化。要对这些变化的时机、方式、后果做出仔细的计划，才能保证实施的成功。尽管在系统分析与设计活动中应该完成系统对组织的冲击和影响的分析，但是迄今为止，这方面的分析仍然常常被忽视。完整的组织冲击分析应说明新系统将怎样影响到组织的结构、态度、决策以及日常运作。为了使新的信息系统能与它所服务的组织完美地协调统一成一个整体，组织的冲击分析的工作就必须得到加强。系统设计中另一个容易被忽视的问题是人的因素的考虑。可以通过吸收用户中受新系统影响最大的那些人来参与设计过程的方式来减弱忽视人的需要的倾向。这种联合设计的方法已经越来越多地引起了设计人员的重视。系统质量的评价应该根据用户的标准而不应像有些系统那样仅根据系统技术人员提出的标准来进行。标准中除了含有诸如存储器容量、存取速率、计算速度等技术指标以外还应该包括用户从使用方面提出的一些要求。例如，某一项指标可能是“系统应提供方便简易的录入界面，使一个普通职员能够在半天之内学会四个屏幕界面的数据录人工作。”用户与系统打交道的界面接口特别要认真设计，除考虑到各项技术要求以外，还要从工效学的角度充分考虑人与机器之间的交互影响和作用，认真分析各个岗位的工作内容、对用户健康的影响、工作的舒适性、工作范围以及强度对用户的影响等因素。一份对美国社会保障局620名工作人员的调查结果显示，利用更快速、更直接的在线系统处理客户申报数据的职员，普遍感到使用新系统要比使用原有的顺序地处理客户数据的电传打字机系统紧张得多。由于他们的抵制，新系统受到了挫折。如果系统设计时考虑到利用新系统以后会使工作人员因为每天要处理更多的顾客数据，工作量将大量增加这一因素，并采取相应的措施，结果将会是另外的样子。用户界面的设计伦敦路透社70的收入来源于出售它们的国际新闻以及金融信息等基于信息的产品。这些产品是通过它的市场显示系统向用户展示的。为改进市场显示系统的可用性，使其能更容易、更方便地满足顾客的要求，路透社让加里森去负责一个最高优先权的项目，任务是改进显示系统的用户界面。为此，加旦森组建了“可用性小组”。这实际上是一个“虚拟小组”，除包括加里森及三名路透社成员之外，还包括一些有关的技术公司，如交互图形公司、人力因素公司、微软公司、逻辑公司等等的代表。该组还与500多名专家保持联系，其中一位是“符号学专家”，专门负责把计算机的动作翻译威像Windows的图标那样的一些符号。该小组并不通过市场调查，去问顾客想要一些什么，而是在他们建立的“可用性实验室”中观察客户们怎样利用路透社的显示系统来查找他们想要的信息产品。可用性实验室有两个房间，一个给用户们用。用户在路透社助理人员的伴随下完成一系列应用系统的实验。另一间房间被玻璃隔成一些小间，各放有一台显示器，显示内容与用户屏幕上的内容相同，并用可视信号或者是内部通信系统与用户保持联系。实验时，要求客户完成一系列的操作。例如，可以要求用户去查询某支股票的价格，画出它在一定期间内的走势日，找出一些相关的消息和公司的财务数据。随着用户的操作，可用性小组的人员就在监视器上观察用户在什么地方发生了问题，测试出完成每项操作的时间，留意引起用户工作中断的过程。用户操作过程还被录像，从录像带上能够更精确地测量所用的时问。该实验室每个月能完成100个用户的三项四项主要测试。实验室还要去了解路透社服务机构接听的用户求助电话，将用户求助的问题分类，录入数据库并进行统计分析，找出用户遇到的主要问题并设法改进。例如，1994年4月有34%的电话是有关RT工作站的，20是有关RT工作站反映出的可用性问题的，进一步分析表明28%的电话是关于报价单问题的，于是路透社就将报价单在工作站上的显示形式进行了改进。可用性小组最后制订了一套规范，要求所有路透社开发小组开发的软件产品都要经过可用性小组的审查，相同的功能要用相同的图标，图标也必须在可用性小组开发出的一套标准图标集中选用。这些图标，开发小组可以在网络上得到。（三）社会技术设计方法社会技术设计方法（SociotechnicalDesign）是信息系统设计的一种方法，它强调在设计中要瘵技术因素与组织因素和人的需要综合起来，产生一个满意度比较高的设计方案。具体步骤如下：设计者除首先提出一些系统的技术指标之外，还要提出一些能增加人的工作满意度的指标。根据这两类指标先分别设计出一些技术设计方案和一些社会设计方案。社会设计方案中要考察各种可能的不同工作组合的结构，工作任务的分配和人员岗位的设计。然后将各种技术方案与社会设计方案一一对照，将能够相互结合的方案结合到一起作为社会技术设计方案的候选方案提出。设计者与用户对所有的社会技术候选设计方案评审以后，挑出最能同时满足技术要求与社会目标的方案作为最终方案。根据该方案就有可能产生出一个能同时满足技术与社会目标的信息系统。该系统应有较高的用户满意度，因为它既考虑了技术的效率又考虑了组织与人的需要。尽管这种方法早在70年代未就已经被提出，但是一直没有得到很好的贯彻。许多系统的开发者都承认最终用户在系统设计中的重要作用，但是与那些专业的设计员和管理人员相比，用户又总是处在从属的被动的地位上。用户作用发挥得不当、忽略了组织和人的需求、缺乏社会技术设计的观念是造成系统满意度低和因非技术因素而失败的主要原因。9.3信息系统的内部控制过去，人们把信息系统的控制看做是事后的事，只在实施阶段的后期，系统快要安装运行时才提出来。但现在组织愈来愈依赖于信息系统，必须尽早地找出系统的薄弱环节，并制定相应的控制措施，信息系统的控制必须成为系统设计中不可或缺的内容。系统的用户和开发者都应在系统生命周期的各个阶段对控制问题予以足够的重视。为使系统发生错误、灾难、计算机犯罪或安全受到破坏的可能性最小，必须在信息系统设计和实施的过程中就考虑并制定专门的规章制度。所谓控制是指采取人工和自动化相结合的措施，保护信息系统，确保系统按照管理的标准运行。或者说，控制就是所有确保组织财产安全、记账资料准确可靠、管理标准贯彻落实的方法、政策和组织规程。一、控制对象的特性在了解控制的内容时，我们要先了解一下我们控制对象的特性。为了完整起见，这里不仅对硬件软件的特性进行介绍还对信息系统的其他组件进行介绍，即数据集、作业过程及人员。每个组件都有自已的特性，这些特性反映了内部控制的实际情况。例如，硬件都有会有一个散热器，还必须有一个冷却器。由于与硬件的特定关系，软件不可能安装在每一台计算机上。在开发过程中，数据集都定义了一定的范围的结构，它们决定了数据存储能力和维护的需求。信息系统用户必须操作和程序，可能是对用户十分友好而且容易使用的，也可能会不时出现一些错误。使用信息系统的人员可能接受过充分培训，也可以有没有接受过任何培训。硬件和软件及其特性信息系统的控制对象主要取决于硬件和软件的大量特性，这些特性与信息系统的安装、运行和维护有关。首先将硬件和软件分为以下几类：计算机依赖于机器的软件（基础软件、数据库管理软件、编程工具）安全工具通信设施（通信设备、连接设备）外围设施（存储设备、输出设备、输入设备、终端处理设备）面向应用的软件（应用软件、管理工具）它们的特性可用表9-7来表述：表9-7 硬件、软件的分类及其特性种类子类特性计算机超级计算机小型超级计算机大型机超级微型计算机个人计算机工作站掌上计算机处理器每秒可处理指令的最大数目处理器的数目以及分配和影响工作量的方式主存容量及其最大扩展额外主存的功能及扩展的可能性可用工作存储器的范围缓冲区的大小和数量基础软件操作系统远程处理监视器分时系统最新修改版本发布的方式和频率所需的主存的大小与其他软件的接口数据库管理软件数据库管理系统字典系统最新修改版本发布的方式和频度备份设备数据库恢复的方式编程工具解释器编译器第四代语言软件生成器测试系统测试生成器CASE资源I-CASE资源IPSE资源生成器主存的大小规范化及标准化水平运行方式错误诊断方式安全工具认证软件加密系统解密系统防辐射设备软、硬件和数据集访问及检索的参数机制回叫设施可能性检测辐射防护通信设备前端-后端处理器调制解调器多路复用器路由器网关交换机通信软件规范化及标准化水平与其他设备的接口信号的放大和衰减连接设备同轴电缆双绞线光缆无线传送器卫星电路容量速度可靠性存储设备磁盘光盘软盘录音带磁带存储能力磁盘的逻辑路径数据访问速度读写属性与只读属性的对比电力消耗包括温度、湿度及空气纯度的环境条件输出设备行式打印机激光打印机喷墨打印机复印机绘图仪技术打印速度打印质量纸张尺寸输出设备扫描仪条形码扫描仪敏感度终端处理设备分类机封装机切口机操作方式能源供应声音强度应用软件管理软件包技术科学软件包工业软件包决策支持软件包技术支持软件包安装方法最新修改版本发布的方式和频率所需主存的大小对应于其他名称的术语操作方式管理工具注册软件包报警软件安装方法所需主存的大小数据集的特性在信息系统开发期间，形成了一些数据模型，这些模型构成了数据库结构的基础。在存储设备中创建的数据库是属于信息系统数据的一个存储区域。于是，接受和实现数据集将以数据库或数据文件的形式进行使用的控制。这里内部控制遇到了在信息系统设计中的某些特性。因此，管理工作必须按照数据处理程序对这些特性加以考虑。需要考虑的数据集的特性包括：范围由变化引起的静态/动态行为数据结构存储数据的存储设备应用数据库管理软件分布可访问性程序特性信息系统的“程序”组件是指能够使用的信息系统的功能。随着信系统的实现和使用，用户面临的问题是如何使用信息系统的相关程序。这些程序的使用和使用的程序无疑将会影响信息系统的内部控制。这不只依赖于程序的质量，而且也依赖于使用这些程序的人员素质。程序需要重视的特性包括：数量范围用户的友好程度表述程序所使用的语言人员的特性信息系统的“人员”组件是指直接或间接使用信息系统的人。“人员”是指那些使用信息系统进行工作，以及参与控制/支持实际系统的人。使用信息系统时表明，为了更好地改进信息系统，可能会要求管理工作提前介入。因此，有可能同时使用信息系统的人数会超过规定，于是导致只能排队处理个人的数据。同时，人员的培训也是非常重要的。如果操作信息系统的人员培训不足，不仅会导致错误行为，而且不能充分使用信息系统功能。任何新用户都需要接受教育和培训以掌握信息系统的所有细节。使用者经常会引起无用的开发。用户根据来自教育和实际使用的经验而提出的信息系统需求是完全不同的。人员的特性包括。信息系统的特性前面几点分别介绍了信息系统各组件的特性，它们是实际存在的特性和属性。当管理工作中遇到这些特性时，就必须对它们加以考虑。除此之外，还有另一个问题：一旦信息系统的组件表明它们属于信息系统，并且它们可以运行了，这个信息系统就会以确定的方式运行。除了各独立的特性外，相互间和外部的影响也决定了信息系统的行为，同时，还决定信息系统的性能。信息系统组件最初的静态特性已经转化为信息系统的动态特性。这些特性决定了信息系统的行为及性能，表现为行为和性能特性。信息系统表现出下列特性：有效性、可靠性、安全性、兼容性、连续性、可检验性、灵活性、用户友好性、完整性、互操作性、可维护性、可携带性、性能（功能性）、强壮性、安全性和保密性。下面通过几个例子来说明硬件、软件及处理程序共同工作时可能会出现的情况。这些例子在性质上并不具有普遍性，然而它们确实在实践中多次出现。例1一个教育和科研机构在各院系的建筑大楼中安装了一个容量为5Mb/s的主干网（宽带网）。与主干网相连的还有容量为10Mb/s的以太网，它们负责本地的数据传输。主干网负责院系间的数据传输。此外，院系可以通过主干网访问其他的国内网和国际网。在计算所需的传输容量方面，国际数据流量考虑得非常少。因此，很少或者说根本没有对这方面进行考虑。然而，一旦连接到因特网上，主干网上的数据流量就会大大增加。E-mail和文件传输逐渐成为一种负担，并大大超过计算的传输容量。这时就会决定扩大容量，有迹象显示，在一个相当短的时间内，容量就可变得不足。所有这些情况说明，在预期使用基础上恰当地设计学院网络所需的容量并不是一件很轻松的工作，甚至在许多情况下是不可能做到的。这就是为什么在明确趋势的基础上要用超量的传输容量来解决爆炸性的网络使用。这说明网络和用户的特性必须及时地（有时是频繁地）适应情况的变化。例2信息系