伦敦救护中心项目是一个非常复杂的大型项目，源于救护中心提高服务水平和服务可靠性的需要。这个项目想要引进一个计算机系统，这个系统能自动处理紧急求救电话，并指示救护人员迅速到大字目的地。
背景
伦敦救护服务中心成立于1930年，到1965年，中心进一步扩大并全部或部分兼并了另外的8个救护服务机构，同时大伦敦理事会也在这年成立了。从1974年到1990年，中心由代表国家卫生服务机构的南泰晤士地区卫生局管理。救护中心是一个有一定自主权的机构，有自己的董事会，地区卫生局对它的管理有限。在1990年之前的10年中，救护中心的动作变化不大。救护中心服务的地理范围超过600平方英里，有大约680万的居住人口，不过白天的人口还会增加不少，尤其是在伦敦的中心区域。救护中心每天收到2000到2500个电话呼叫，其中有1300到1600个急救电话999。在伦敦地区，救护中心为80家医院和社区组织提供运送病人服务。每年，中心处理50万次急救事故，运送病人130万次。救护中心有2700员工和750多辆救护车，在1992年到1993年的预算是6970万英镑，是世界上最大的救护服务机构。其组织结构见表。
组织文化
在伦敦救护服务中心，管理层和职员之间有一种根深蒂固的互不信任感受。上层管理人员用一种完全军事化的态度来发布命令，希望下属能够完全遵照执行。许多经理人员和职员都认为上层管理者规定的时间期限太苛刻，缺乏灵活性，难以胜任。至于救护小组的成员，他们认为能够快速赶到现场、救助伤病人员，尽快把他们转到医院去是一件值得骄傲的事，他们更关注病人的需要，对他们的行动给救护中心的其他部门产生的影响并不在意。
人工急救电话处理系统
人工系统的处理过程如下：
- 救护报务控制中心接受999急救电话。
- 控制助理员把电话中告诉的细节填在一张表格里，根据一本地图册找到事故地点并提供参考战略。
- 填好的表格由输送带送到一个集成中心。
- 集成中心的人员仔细检查送来的表格，并辨别出是否有重复呼叫的，然后以伦敦的三个分部，东北、西北的南部为基础，把表格送到资源分配人员的手中。
- 资源分配人员有一个“活动箱”，是不断由无线联络人员提供的有关救护车的情况以及位置等信息。资源分配人员仔细检查属于他负责地区的表格，决定调动哪一辆救护车。
- 资源分配人员把调动的情况记录在表格上，然后给调度员安排。
- 调度员打电话通知有关救护站或把调动指令传送给无线联络人员通知移动中的救护车。
完全人工处理系统的一些明显的问题：
——如果打急救电话的人没有提供完整的准确的信息，要找到事故的准确位置有一定的难度，因为需要在地图册上查找好些地方。
——在控制室中用传送带传送表格显然是没有效率的。
——了解救护车状况和位置是一个费劲的缓慢过程，它依靠资源分配人员的直觉和无线联络员的报告。
——和救护车的声音联络很费时间，在高峰期的时候，调动会出现排队等候的现象。
——依靠人的判断和记忆来识别重复呼叫很容易出错。
——不能有效处理呼叫取消，因为电话处理人员要离开他的岗位去通知资源分配人员。
——完全靠人工判断来决定事帮是否需要快速反应部门、特殊处理小组以及直升飞机等。
服务状况
国内得到认同的救护服务标准是运作研究咨询机构发布的。这个标准要求，从接电话到对救护站或移动的救护车发布指令不能超过3分钟，救护车要在14分钟内到达事故地点。对伦敦救护服务中心来说，使用现有的人工系统处理急救电话，难以达到这个艰巨的要求。而且，使情况更麻烦的是，中心缺乏每一辆救护车的状况及位置方面的信息，对那些离开救护站在外的救护小组，很难进行有效的联络。救护中心的上层管理人员意识到，要提高救护中心的服务水平，他们需要采取措施改进当前的状况。
救护服务中心很清楚他们使用的完全人工系统的缺陷，在20世纪80年代早期的时候，就曾经试图引进一个计算机辅助调度系统。这个调度系统包括一个新的无线呼叫设施。并进一步扩大到包括一个移动数据终端。然而，当测试发现该系统不能处理预想的要求时，这个项目于1990年被取消了。
1990年秋季，在支持服务部门主管的带领下，重新成立一个小组来引进一个全自动的系统。要大幅度提高救护中心的效率对新的小组来说是一个艰巨的任务，小组要承受很大的压力。他们面对的是一个救护反应速度很低，和国内认可的救护标准相距甚远的局面。
目标
小组的目标是引进一个全自动的计算机系统，让大部分的急救电话可以通过救护控制中心负责接电话的人员调动恰当的救护资源进行处理。只有在非常复杂的情况下，才需要资源分配人员来识别和调度资源。所有别的高度都由负责接电话的人自行处理，并且从接电话开始，直至整个事件处理完毕，一直由他负责。开发的计算机调度系统需要自动提供下列功能：
——电话受理并验证事故细节和地点。
——资源识别，决定派出哪一辆救护车。
——资源调度，把事故的细节告诉要派出的救护小组。
——救护资源管理。主要是确定有合适设备和人员的救护车的位置，尽量减少反应时间。
——为评估服务水平提供管理信息，并协助中长期资源管理和计划。
计算机调度系统要提供计算机辅助调度，电子地图显示，自动的车辆定位系统，而且这些要素需要和已有的移动数据终端连接。在原来那个被取消的项目中，移动数据终端已经安装在救护车辆内了，同时系统可能通过一新的无线联络系统进行联系。
尽管英国有别的救护机构使用了计算机辅助的电话呼叫受理装置，有的还有车辆位置确定并考虑在救护车内安装移动数据终端来提高反应能力，但伦敦救护服务中心要开发的这个系统是前所未有的，系统的实现将会使中心的服务水平发生质的飞跃。无论如何，伦敦救护服务中心做点什么来帮助他们面对伦敦地区日趋严重的挑战。中心管理层也把这个系统看成是可以优化管理过程的手段，并能使服务水平达到认可的标准。
需求建议书的制定
中心成立了一个小组准备需求建议书，小组的组成不员有：支持报务部的主管（主持小组工作），系统经理，一位合同分析人员，控制室的服务经理，以及培训、联络和其它领域的员工代表。小组没有包括救护人员在内。
需求建议书十分详细，对系统如何动作有很准确的描述，这反映了组织的文化，对潜在的供应商来说，几乎没有可以变动的范围，更不能有一些自己附加的想法。当然，和别的需求建议书一样，该建议书也存在没有充分定义的地方。系统开发建设的时间期限为一年，初步预算为150英镑。
开始的时候，小组曾接触过一些别的救护机构，如West Midlands，Oxford和Surrey等，看他们的系统能否满足需求，后来这些系统都放弃了。Surrey的系统只是他们想要的系统的一部分，小组认为要对它进行扩展的费用很高。Oxford的系统最初是由麦道公司提供给消防队使用的。而目前麦道公司没有兴趣把他们的系统进行修改以满足伦敦救护中心的要求。West Midlands的系统比较接近要求，但他们却没有多余的能力来开发支持伦敦的系统。
合同招标
包括分析人员、系统经理和地区卫生局采购部的一位供应经理在内的小组为系统从事采购工作。通过广告邀请投标，有35家公司对该系统或系统的一部分表示感兴趣。在和这些潜在的供应商开会讨论的过程中，许多供应商对项目所建议的时间表示关注。这个时间表是参考管理顾问1990年的一份报告制订的。该报告针对以前那个被废止的系统提出了一些措施，如该报告建议放弃旧的项目，采取行动着手拟订一个新系统的说明书，进行收购或开发新的系统。该报告指出，一个一揽子解决方案将花费150万英镑，从说明书到实现需19个月。如果一揽子解决方案不可行的话，在时间和费用上还需有大幅度的增加。小组认为，对于新系统的开发，一揽子解决方案的成本和时间足够了。
17家供应商对系统或系统的一部分提供了建议书。采购小组对救护服务中心的主要要求列了一个包括时间和成本在内的清单，并用一个得分系统来对建议书进行评估。
只有一份建议书满足所有的需求，包括成本和时间表。这份建议书是由三家公司组成一个团体提供的，报价略低于100万英镑。这三家公司分别是Apricot Computers,Systems Options（一有小型软件公司）和Datatrak（做车辆自动定位系统）。地方卫生局的采购条例规定，除非有非常充分的理由，否则只能接受的时间期限内提供符合要求的系统，但由于成本上的原因没有考虑他们。
和别的建议书相比，Systems Options的软件开发报价非常低。事后证明，Systems Options公司严重低估了系统软件开发的难度和复杂性。对建设项目书筛选过程的审查应该充分重视投标书中的技术部分，但参与审查的人中，没有一个有相关的项目管理或合同管理的经验。审查最终批准了采购小组的决策。
项目管理
对于系统的开发，项目小组采用的是Prince项目管理方法，但对这种方法怎么应用并没有明确的指示，小组中也没有人有过这方面的应用经验。尽管搞了一个短期培训，但事实证明是远远不够的，管理过程中并没有遵循Prince的原则。
在筛选承包商的过程中，对承包商的项目协调管理职责没有一个明确的定位。救护服务中心本希望由承包团体中硬件设备制造商来牵头，然而事实上却是Systems Options这家小型软件公司领头负责签订合同，然后把硬件部分包括了硬件制造商。因此，这家设备制造商并没有采取任何准备措施领头人的角色，很快退出了这方面的事务。全面协调的工作转到了支持服务主管那里，因为没有中层管理人员替他承担工作，支持服务主管的压力很大。他不仅要花越来越多的时间在低层次的协调和进度追踪上，同时还要继续从事自己的本职工作。尽管Systems Options是牵头承包商。但是除了为早期的项目集体会议提供计划进度表外，该公司几乎没有承担过任何职责。
系统开发
1991年6月到7月期间，承包商准备好了系统设计的说明书。然而，过了两个月，Systems Options才开始编写程序，与另一家公司独立签订了无线系统合同，这时离预想的系统实施只剩4个月，但这家公司也延迟了说明书和协议的交付。10月份的时候，救护服务中心新招募了一位系统经理，尽管没有直接参加该项目，但他还是对项目的进展进行了调查，并写了一份建议。建议中指出，为了对承包商施加压力，原定的实施日期应该保持不变，在系统技术质量方面，也要有足够的重视。但该报告也没什么什么实质性的结论。到了12月中旬，项目小组意识到，在1992年1月份系统全部完工显然是不可能的，于是接受了先部分实施的方案。
最称实施的部分是电话呼叫受理程序，该程序把呼叫报告打印出来以供资源分配和调度人员使用。程序中还包括了电子地名词典，控制助理员可以从中很快查找和识别事故地点的位置。尽管运行中出现了不少问题，如屏幕锁定、打印机错误关闭导致遗漏事故、服务器失灵等，使得职员对该系统的信心不足，但总的来说，这部分的运行基本上还是正常的。
系统开发工作仍旧在进行，并对各个部分陆续进行测试，在西北部地区，对车辆定位和联络系统进行测试。在测试的过程中，发现了下述问题：
——由于缺乏培训，联系出现问题以及所谓的操作不当，救护人员频繁报告不完备的车况。
——由于不完善的设备、传输盲点和软件错误，Ddatartak车辆定位系统不准确，移动数据终端出现问题。
——联络渠道负担过重，尤其是在救护人员换班变化的时。
——硬件不断出现问题，特别是工作站瘫痪和明显的系统运行缓慢。
在1992年的前9个月，系统在伦敦救护三个不同的分区陆续零星进行实施，总的来说，分成三个阶段：
阶段1：使用电话受理软件和电子地图来帮助纪录事故和确定地点。资源分配人员得到打印好的信息，并使用他们传统的方法通过无线联络或电话派遣救护小组。
阶段2：和阶段1一样，但是有Datatrak车辆定位系统报告的车辆位置，可以通过移动数据终派遣救护小组。资源分配人员可以像以前那样决定最优秀的资源使用。
阶段3：全面实施，如果自动资源配置提供的方案可以让救护小组在11分钟到达事故地点，电话受理人员可以使用这种方式，否则的话，资源配置人员要识别和找到最合适的车辆。阶段3的运作是无纸化的。
在这几个月中，系统从来就没有稳定过，软件也不断地进行修改和完善。项目小组没有机会进行全面测试，决定在1992年10月26日全面实施系统。然而这时至少有两个项目报告指出一些严重的问题，如果这些问题没有解决的话，会影响系统在运作中的功能实现。同时有差不多44份报告指出运作上的问题以及这些问题会导致服务质量降低。
系统的失败
在系统正式运行前作出的一些调整：
——重新配置控制室，将资源分配人员和无线联络人员分开。
——停止使用工人“活动箱”备份各级系统。
——在整个伦敦地区进行。
——只使用系统分配资源，但是如果救护车到事故地点不到11分钟的情况下，资源分配资源可以直接派遣。
——对于999电话、医生急救中呼叫和病人运送服务，分别有专门处理的资源分配人员。
1992年10月26日，救护车的回应时间经常让人难以接受。尽管系统基本上还是像设计的那样运行，但仍然存在着导致其完全失灵的缺陷。系统实施后，要求最大限度减少无线联络。控制室的变化意味着职员在不熟悉的环境工作，没有纸张备份，也难以和从前经常讨论和解决问题的同事一起工作。系统需要完备的信息，然而，由于联络、车况和位置报告方面的问题，系统所知道其准确状况和位置越来越少。控制室的变化使得职员介入非常困难。而且，对于无线联络方面的限制，丧失了对真实信息的必要反馈。26日结果是，当正常的工作负荷增加时，整个系统很快就不能使用了。系统的分配不正确，有时，派了好几辆车到同一地点，有时没有派最近的救护车，未加纠正的例外信息派生了更多的例外信息，使得系统变慢和阻塞，直至不得不回到半人工方式。此后，系统运行到11月4日，在速度明显变慢后，最终被锁定，关闭后重新启动工作站也无济于事，伦敦救护服务中心的管理层建议，重新使用人工系统，用低张纪录。通过无线联络派遣救护车。
事后的调查证明，在技术上导致系统出现问题的是一个小的程序错误，一个程序员无意中在系统里留下了一个程序代码，使得一部分服务器的内存被用完，每次派遣救护车之后都不能释放，运行3周之后，可用的内存逐渐被用完，导致了系统的崩溃。
案例评析
救护服务中心的计算机信息系统故障，从技术上的直接原因看，似乎是一个程序错误，然而，这并不是根本的原因。从项目一开始，时间表的制定，承包商的选择及项目的管理等等，都存在隐患。在承包商的选择上，强调了公开招标和价格成本，却忽视了质量方面的要求。把项目交给一家小的软件开发商牵头的团体，失败的风险很高。救护服务中心尽管采纳了Prince管理方法，但项目小组没有这方面的经验，在管理的过程中也没遵循这方面的原则。系统开发中的协调和合作也没有明确的一方来负责。
|
