译/朱筱丹

编者按：商业科技的复杂性可以构筑从业人员的职业地位，当然也可以在一夜之间毁掉它。高调的商业应用光鲜外表下包含着无数需要重视的细节，其中IT细节尤为关键。没有对于技术能力的充分估计，缺乏足够的预先风险测试，没有完善的灾备方案，不考虑如何对待正常用户和恶意用户等都可能导致重大的商业灾难。

在我们这座商业科技耻辱殿堂上，除了麦当劳公司1.7亿美元的企业资源计划(ERP)项目的惨败；电力公司的软件缺陷导致加拿大和美国东北地区的大规模断电以外，还有更多案例。阅读了解这些黯淡的细节，能够帮助企业找到避免类似惨剧的出路。

贪多嚼不烂

麦当劳公司(McDonald，下称麦当劳)的这个项目规模和覆盖范围极广，以致最终变成了不可能完成的任务。2001年的时候，快餐连锁业巨头打算开展一个项目，建立一个连接总部和遍布各地餐厅的企业内部网(Intranet)，以提供实时的运营信息。在这个代号为“创新”(Innovate)的项目里，公司在伊<!>利诺伊州奥克布鲁克(Oak Brook)总部的经理能实时了解在佛罗里达州奥兰多(Orlando)特许经营店里的销售情况正在变缓，或者伦敦餐厅里的烤架温度不够热。麦当劳一直对“创新”项目守口如瓶——该公司对本文的采访不予回应——但它的覆盖范围之广勿庸置疑。根据受麦当劳聘用负责早期策划和技术选型的顾问公司Mpower公司的白皮书资料，这个计划的目标是创立“一个逐渐深入到每一家麦当劳店铺的全球ERP应用。”换而言之，这包括超过120个国家里的3万多家餐厅。这样的工程真的易如反掌吗？

根据麦当劳提交给美国证交会的季度报告，他们在顾问和初始实施阶段花费了1.7亿美元之后才意识到这个项目实在过于庞大。麦当劳终于在2003年给美国证交会的财物报告中宣判了“创新”项目的死刑，项目被注销，管理层决定终止这个长期技术项目。

财务报表中的补充揭示了一条绝大多数有经验的IT项目经理从一开始就能给麦当劳提出的忠告：企图在上千家门店之间创建传递实时信息的全球网络，它们中有的还缺乏基础网络建设，注定会失败。财务报告显示，“尽管这个终止项目原本的目标是长期效益，但在当前环境下，并不是最好的资金使用方式，因为预期在几年内整个系统的开销将超过10亿美元。”

这场需要耗费上10亿美元、过于超前的IT项目重蹈了McDLT汉堡(20世纪80年代一种双层包装、把热食与冷食两部分分开置放汉堡)的覆辙：因为大多数人一次吃不掉那么大的汉堡。

谨慎对待错误

有时候技术灾难的影响远远不止于出问题的公司本身。美国俄亥俄州的第一能源公司(First Energy，下称第一能源)为450万客户提供电力，3年前就因为一个与电源失效有关的软件缺陷，使美国东北部和部分加拿大地区大面积

陷于停电。

这次停电的原因是俄亥俄州砍伐树木切断了平衡东北电网出入电流的电线引起的连锁反应。但真正的问题在第一能源的计算机部门，它的IT经理们好像忘了一个基本操作原则：无论引入多少自动化处理或员工经验多么的丰富，应用程序都必须遵从必要的IT管理协议，如IT基础设施库(Information Technology Infrastructure Library，ITIL)的规定。

如果第一能源的软件报警系统能正确地对不稳定情况向工程人员提出报警的话，停电原本可以局限在很小范围内。报警系统的关键在于：当你发现系统不工作的时候，一切已经太晚了。“不稳定的状况原本不会直接导致停电，但是第一能源没能及时做出响应是事故的主要原因。”北美电力可靠性协会(North America Electric Reliability Council)负责基础架构安全的经理史丹·约翰逊(Stan Johnson)总结道。

2003年8月13日下午2点左右，该公司的IT人员发现运行General Electric XA/21管理系统的服务器上的报警模块停止了工作。工作人员重启机器试图修复该问题，但服务器重启后，报警模块仍然无法正常工作。通用电气公司(GE，下称通用电气)在其后的一篇声明里表示，这是因为一个软件代码错误引起报警程序进入死循环而无法重新在线工作。而第一能源在俄亥俄工厂控制室里的操作人员没意识到这条防御线已失效，因为他们的IT架构在重启之后不会校验相关的系统是否都已恢复工作。同时，不稳定的电力状态在迅速恶化。

因为忽略了IT管理里最重要的原则，员工也不愿意与终端用户确认检查，确保他们的关键系统已能完全正常使用。IT基础设施库尤其建议IT部门建立一个受影响用户的确认列表，在重启关键性系统后，管理员必须与他们一一联系。在北美电力可靠协会关于这次停电的最后一份报告里，它指责第一能源的IT部门缺乏沟通意识。

第一能源谢绝关于此事件的采访，但约翰逊表示协会的最后一份报告里该公司已遵从了必要的建议。尤其是，协会敦促第一能源建立必要的规章，书面的管理测试、部署和备份关键硬件或软件系统准则，包括执行系统升级、补丁包管理、备份恢复和维护的方法。它还建议该公司必须建立一套系统发生故障时必须明确的交流规程。事实上，这些良好的建议适用于所有的公司。

注重细节

想象一下，在一家没有财会系统的公司里担任会计职务的滋味。这正是德尔·欣斯基(Dale Shinskey)的遭遇。他是一名财务专业人员，欣斯基的前任雇主是全球燃料服务公司(World Fuel Services)的子机构国际石油公司(International Petroleum)，在2000年被废油循环再生公司Earthcare公司用3,500万美元购并，欣斯基也因此加入了Earthcare公司。不幸的是，欣斯基表示：“Earthcare公司完成了购并，却忽略了细节。”

这项交易显示，仍由全球燃料服务公司维护欣斯基团队用来记账的Oracle财会系统。但是出现了一个问题：欣斯基宣称Earthcare公司忘了向全球燃料服务公司支付该系统的维护费，在短暂的使用之后，系统被终止。欣斯基抱怨道：“那3个月我们手头什么也没有。”在这期间，Earthcare公司只是简单地评估该机构的财务状况，估计财务数据，这些数字后来证明都是错的。“他们想把财务系统自己运作起来，但根本没法做到。”欣斯基指出。

糟糕的财务管理让Earthcare公司遇到了更大的麻烦。2001年公司被迫向全球燃料服务公司支付175万美元用于解决与收购国际石油公司相关的争端。当年6月，Earthcare公司又把国际石油公司卖给了美国过滤恢复服务公司(U.S. Filter Recovery Services)，这样欣斯基也随之离开了Earthcare公司。

但故事并没有完结，在过滤恢复服务公司工作一年之后，欣斯基和他的财务部门被要求从赛捷软件(Sage Software)的MAS 200应用程序向一套名为 Uptime from Uptime的软件迁移。“情况糟糕透了，我们管那段时间叫停工期。”欣斯基回忆道。原因是美国过滤恢复服务公司使用一套20世纪80年代初开发的落伍系统，并且不愿意出钱把欣斯基部门的财会系统整合到公司的Oracle应用环境中去。“这套系统没有下拉菜单。如果不在计算机里加上一大堆附注说明，你简直没法使用这套系统。”欣斯基抱怨道。

情形令人如此头痛，以致部门的财务和会计断断续续地离职以逃避困境。而现在已并入Siemens公司(Siemens)的美国过滤恢复服务公司拒绝了《InformationWeek》的访问要求。

欣斯基表示，他们获得的教训是：实施购并的公司应该对购并后的各种运作方式有周详的考虑，其中需要确保有合适的工具支持公司的管理。

拒绝“金钱婚姻”

有的公司企图通过把IT外包以摆脱困境。一家非常着迷于外包概念的保险和金融机构甚至为此专门购并了一家外包公司。但这个决定，最后却令购并者懊悔无比。

仅仅从2001年到2002年的15个月期间，美国印第安那波利斯的康赛可公司(Conseco，下称康赛可)先是购并了印度外包商ExlService公司，继而又反悔转手卖掉了该外包公司。ExlService公司当时处于起步阶段，在印度提供低成本呼叫中心客户服务。当时康赛可总裁兼首席执行官(CEO)加里·韦特(Gary Wendt)还在通用电气工作时，就以提倡外包客户服务而著名。对他来说，这家企业无疑很诱人。在韦特的决策下，康赛可用5,200多万美元购并了ExlService公司。

韦特认为ExlService公司能在一夜之间为康赛可提供低成本高质量的客户服务。他对美国印第安那州本土的人力资源不是很有信心。在《波利斯明星报》(Indianapolis Star)问他为什么把公司的客户服务搬到海外去时，他表示“我很确信印度能提供更好的客户服务。而美国本土的(公司)不行。”

这只是其中一个理由，韦特在这桩交易里也获得了利益；他成了ExlService 公司的联合创始人，并在交易中获得ExlService公司20%的股票期权。根据美国证交所的文件显示，韦特和他的妻子在这桩交易里纯获利692,567 股康赛可股票，共价值970万美元。但兑现这些股票是有条件的，必须等康赛可确认能从这笔购并交易中获得良好收益才能生效。康赛可没有回应《InformationWeek》采访的请求。

在购并之后，康赛可就把2,000个客户服务职位转移到在印度的ExlService公司。在一份管理法规补充报告里，康赛可宣布在2002年11月放弃ExlService公司，损失达2,000万美元。自然韦特的股票期权也随即化为乌有。

根据波利斯明星报的报道，康赛可的一些高层把投资失败归咎于时机错误。因为康赛可的印度呼叫中心上线的日子是2001年9月10日。第二天就发生了“9·11“恐怖袭击，带外国口音的呼叫中心自然立刻蒙受负面影响。

这件事的教育意义是什么？警惕外包陷阱？足够充分理由，谨慎选择合作伙伴？不要低估本土人力资源？也许上面这些都包括。

各取所需导致消化不良

英国全国医疗保健系统(National Health Service，下称NHS)的IT 现代化项目也许是现存的最大规模的IT灾难。该项目比预期时间滞后2年，超支100亿美元，在花钱规模上它和美国波士顿的大隧道计划(Big Dig，美国迄今为止耗资最大也是最复杂的高速公路)项目不分伯仲。它的其中一个主要厂商——以医疗健康程序开发为主业的iSoft公司已在破产的边缘，因为该公司一直无法在这个网络上部署自己的软件。如果应用程序不能部署，iSoft就无法获得收益，所以延时无疑会拖垮他们。各种技术问题包括要整合不兼容的系统，而抵触的医生们则认为该项目没有事前充分咨询他们的意见，厂商之间就程序的功能互相指责，彼此推卸责任。

负责这个项目的IT高层和政府官员们已经挣扎了好几年，企图把项目拉上正轨。但问题依然严重并仍然持续。一台应该今年报废的大型计算机就使英格兰西北部和中英格兰北部地区的80家医疗结构停业4天。错误的起因是NHS管理下的一台存放有上百万病人记录和医疗数据的服务器出现问题。那几天里受影响区域的医生们没法获得病人的预约信息，导致对病人的服务严重延误。在一份报告中，NHS声称病人的安危并没

有受损害。

深入研究过NHS项目的剑桥大学(Cambridge University)计算机科学系罗斯·安德森(Ross Anderson)教授表示，更严重的问题是政府官员把这个现代化项目分割给许多厂商，而他们之间的协调却非常糟糕。“完全不同的软件、不同的标准，一切都是各自为政。” 安德森教授指出，他主管的信息与政策研究基金会(Foundation for Information Policy Research)一直对这个现代化项目提出批评。NHS的官员隐瞒了项目的问题，而坚称项目的最终成果能提高对病人的服务。

安德森评论到，很多情况下安装的系统之间彼此根本不兼容。“这不单单是浪费数十亿英镑的问题，而且它很可能危及病人的生命。”他警告说。当然也许就这样放任下去，随着厂商的减少，这个系统反而会变得比较兼容。因为其中一家厂商埃森哲咨询公司(Accenture，下称埃森哲)9月已经退出，并把自己的合同份额转给了美国计算机科学公司(Computer Sciences Corp.)。而埃森哲不得不拨出4.5亿美元抵消在这个项目中的损失。

大型外包项目的潮流是把任务分包给不同的厂商。本意是为了减低风险，在厂商间引入竞争机制。NHS现代化项目中包括转包商共有10多个厂商参与。这简直是在重建巴比伦塔(Tower of Babel)。分担风险固然重要，但多个厂商的介入也会引起严重的问题。

墨菲定律仍然适用

[编者注：墨菲定律(Murphy’s Law)缘于美国一位名叫墨菲的上尉。墨菲认为他的某位同事是个倒霉蛋，不经意地说了句笑话：“如果一件事情有可能被弄糟，让他去做就一

定会弄糟。”]

不是每个人都讨厌IT失误。比如在税务问题上弄虚作假的美国人就肯定会对美国内务财政收入局(Internal Revenue Service)失败的IT策略暗自窃喜。这个失败的策略就是年初美国内务财政收入局对欺诈行为检测软件进行的拙劣升级。“如果哪里会出问题，那么必然会是这个项目。”财政部审计处的检查员玛格丽特·贝格(Margaret Begg)明确指出。

内务财政收入局原本计划在一月让系统上线，这样正好能赶上2006年税季开始。而且这也正是项目实施整一年的日子。万众期待之下，税务署的IT人员终止了旧系统。新版本由计算机科学公司开发完成，除了内务财政收入局的主数据库，新系统的数据库资料比任何其他内务财政收入局的系统都更庞大，结果却完全无法正常运作。对于一个从2001年就开始设计的软件而言实在是说不过去。根据财政部审计处的估算，因为缺少了防欺诈系统，每年要多花3.18亿美元填补由于漏税导致的税收漏洞。

一场为期4个月、由美国众议院筹款委员会(House Ways and Means Committee)组织的调查发现这个系统“在方方面面都不合格。” 委员会主席参议员比尔·托马斯(Bill Thomas)在八月致美国财政部长(Treasury Secretary)亨利·保尔森(Henry Paulson)的信里这样写到。特别引人注目的是内务财政收入局的IT负责人错误地把这个项目归为维护而不是一次重大升级，这直接导致没有足够的监管和资助。托马斯指出，“这套系统涉及到国家的税收，非常重要。”这套系统是内务财政收入局19项被美国联邦政府列明为国家重要基础设施，防恐怖袭击重点保护对象。

到一月系统该上线的时候，还有由测试人员提交的534项问题列表。其中一个问题是欺诈检测系统项目组和这套系统最主要的使用者内务财政收入局的犯罪调查科之间完全没有沟通。事实上，沟通问题处处存在。其中一个研发小组修改了内容，却没有周知，这会影响相关的研发小组。因此内务财政收入局的系统适用性测试(System Acceptability Testing)小组每换一个地方就会碰到新的问题。贝格的报告表明，系统适用性测试小组不得不再提交一项错误报告，返回到开发商那里，又需要修改一次软件。在采访中，贝格指出内务财政收入局缺乏完成这样重要应用所必需的项目管理守则。“他们的测试不够严格，也没有引入足够的项目管理活动，所以没有确定的计划可依据执行。”她分析说。

这当然这不是内务财政收入局第一次把IT系统弄得一团糟。在过去8年里，这个机构花费80亿美元试图升级它的整体网络运算基础架构。美国国家审计总署(Government Accountability Office)复查了这个项目，发现多处出现资金超支、铺张浪费和效率低下等问题。部分原因是内务财政收入局的IT员工正在陆续退休，而合格的接替人员却很难找到。“如果需要推行某个计划，他们没有所需要的稳定性和连续性。”贝格评论道，并补充表示他们的IT管理层更替特别频繁。内务财政收入局正计划在2007年税季来临之前把旧系统恢复上线，同时还计划开发基于Web的系统。人们少不了要替他们捏把汗啊！

注重技术生命周期

2005年，美国联邦调查局(Federal Bureau of Investigation)扔掉了它那千疮百孔的虚拟案例系统(Virtual Case File System)，这套定制软件能在追查罪犯的时候为调查人员提供检索多个犯罪数据库的功能。这套软件的功能对联邦调查局来说是个难解的情结了，因为软件公司Inslam公司曾指责司法部剽窃了该公司的Promis 案例管理(Promis Case Management)软件，修改后给联邦调查局使用。Inslaw公司最后输了官司。但是在“9·11”恐怖袭击之后，对这种系统的需求又再度急迫起来。

这个价值1.7亿美元的失败的虚拟案例系统项目，是联邦调查局现代化三部曲中的一部分，虽然没有像上次那样遭遇剽窃指控，但这个项目实施过程中联邦调查局却犯了一个IT界的大忌：如果一个长期项目完成之时，所用技术也将过时，那么就要避免实施这样的项目。项目设计者应该考虑到当他的想法付诸实现之日，将来的技术环境是怎样的，哪些技术会被广泛使用。

在2001年计划虚拟案例系统项目的时候，联邦调查局选择了定制软件的方式，尽管当时许多大公司都能够提供更便宜、更通用的现成应用程序。“技术的革新一下子就超过了我们最初版本的虚拟案例系统，现在已经涌现了许多项目初始阶段没有的新产品。”联邦调查局无奈地在去年一份终止项目的报告上承认这点。

而虚拟案例系统在这非常不顺利的4年中共任命过9位项目经理和5位首席信息官(CIO)。

该项目的贡献是为联邦调查局带来了教训，让它抛弃了虚拟案例系统项目而转向信息管理系统Sentinel。Sentinel系统采用先进的技术，有比较长的生命周期：它是基于网络(Web-Based)和服务导向架构(SOA)的，因此可以和其他外部执法数据库以及其他支持Web服务标准的数据库相连。

Sentinel系统在第一阶段会向联邦调查局特工和分析员提供门户站点，让他们访问快要被替换的自动案例支持系统，日后数据会转到新的案例管理系统上。该系统还会包括一个案例管理“工具箱”，其中汇聚了使用者的所有工作(特工或者分析员正在处理的案例文件)，并可根据案例文件的人物、地点、时间进行检索。

今年3月，联邦调查局与洛克希德·马丁公司(Lockheed Martin)签订了高达 3.05亿美元的Sentinel系统合同。合同分包商包括埃森哲和计算机科学公司。计算机科学公司的Dyncorp 部门曾是美国司法部Promis项目的合作厂商。期望这次合作会比前次更顺利。

提防仓促上马的项目

在上世纪90年代，提供电视收视统计的尼尔森媒介研究公司(Nielsen Media Research，下称尼尔森)的技术高层因为贸然开展一项重要的项目而吃尽了苦头。该公司想重写自己的核心评估系统。这可不是随便更替一个办公室外围设备的问题，它是尼尔森数以10亿美元计的业务核心引擎。不幸的是，IT高管们盲目加快进度，导致编码一塌糊涂，浪费了数百万美元，还把其中的主要开发商告上了法庭，到现在已经过去10年了，尼尔森还在试图完成这个项目。项目的参与者之一评价说：“他们希望尽快完成，其结果就是他们到今日还在为此付出代价。”

这个项目的目标是把原来用于大型主机上的基于编译器代码的评估系统转换成客户-服务器架构，期望以此提高用户友好度和灵活性，尼尔森也能更准确地分离数据，卖给它那些传媒业客户们。因为这是个复杂的项目，尼尔森的技术人员原本预计需要3年完成，正好就在千禧年来临之际。

但高管对这个时间表不满意，据消息人士称他们希望系统能在一年之内上线。工程开始匆忙上马启动。

即便你希望找个机器人来管理你的 IT部门，市场上也立刻会有人表示他们能够供货。所以尼尔森找到一个外包商担保能在一年内完成这个项目也不足为奇。1997年，尼尔森和TenFold公司签订了一份软件开发合同。“他们拍了板，我们只能跟进。”相关人士表示。TenFold公司和尼尔森都谢绝了对此进行评论的要求。

尼尔森的底层技术人员从一开始就对这个项目报怀疑态度，很快就有迹象显示他们是有道理的。其后几个月对项目的检查发现，TenFold公司的评估系统使用的是文本格式文件而不是合同里要求的基于对象的开发方式。

这背后的理由是TenFold公司没有足够的时间正常地完成工作。据说在一次代码检查中，尼尔森的一位IT经理发现在一名TenFold公司开发人员的笔记本上写着：“我们只能写这些垃圾，因为我们没有时间正确地完成它。”

尽管情形令人担心，但尼尔森的IT高管要求内部员工全力支持TenFold公司。内部人员表示，“我们被要求不要干扰他们，以免引起不愉快。”

但是到最后，尼尔森的IT决策者们也受够了TenFold公司的迟缓进展。他们在2000年6月终止了该项目，控告TenFold公司并要求赔偿450万美元。双方最后达成保密的和解，但尼尔森的问题并没有得到解决。在项目开始10年之后，尼尔森还在试图把评估系统的升级拉上正轨。