CIO 下课之后

IT 出现事故后，让CIO 下课成为很多企业的习惯做法，但却少有企业关注CIO 出局后的诸多问题。
点击此处查看全部科技图片

　　周源 杨小薇

　　今年1 月6 日上午，国内某证券公司总工程师M先生在去北京机场的路上，得知公司的集中交易系统出现了故障，股民买卖股票的交易速度非常慢，近乎于瘫痪。闻讯后，他立刻赶到公司的机房，现场指挥排除故障，约1小时后故障终于排除，原因是开发商修改数据库造成的。

　　当天，股市正好有波行情，由于不能及时下单，这家证券公司的部分股民情绪比较激动。这个消息不久就在证券业界传开，大家觉得这位总工很可能会为这次事故承担责任。因为券商的交易系统直接与股民口袋中的钱相关，系统出了问题，券商一定要给股民一个交代，这个节骨眼上，公司的技术负责人“在劫难逃”，M先生也做好了充分的思想准备。

　　春节后，这位总工离开了这家证券公司。证券界很多人都没有想到他所承担的“说法”如此严重。如果1 月6 日系统没出现故障，M先生能顺利抵达上海，他将在春节前把最后一家营业部的交易系统挂到集中交易系统上，完成公司的“大集中”项目。然而很多事情在1月6日发生了改变，他在自己的“大集中”项目表上写下了“饮恨1 月6 日”的字样。

　　被动出局

　　M先生的出局让很多券商的CIO 开始掂量自己所承担的责任和压力。

　　目前，国内的券商几乎都开始了“大集中”项目，有些券商甚至已经完成了集中交易系统等诸多总部集中的信息系统。身处项目前线的CIO们很清楚，证券公司通过信息系统将以前分散于各个营业部的业务和管理风险集中到了总部。信息系统作为经营和管理风险集中后的载体，既是风险重地，又是不能出任何差池的地方。而很多经营和管理资源却是CIO无法调用和支配的，但由此产生的风险却有可能让他们承担。正是这个原因让不少人为M先生的际遇鸣不平。

　　在M总工承担了系统故障“说法”离开公司后，证券界曾有CIO找到公司总经理，希望公司能够划分出他们所该承担的技术责任，并且期望公司能在一些人力不可控的技术环节上给予免责认定。

　　在权利和资源不到位的条件下，承担不对等的责任，以至于出局是任何CIO不愿承受的。不过，这种情况在现实中并不少见。

　　4月30日，西南某省电信公司综合营账系统二期工程招标结束，原项目总集成商全线退出，只负责二期工程的咨询业务，另一家国内总集成商将全盘接手该项目的二期工程。

　　按照原总集成商的说法，虽然一期项目取得了一些成绩，新系统在全省21 个地市，实施了4 个本地网。但这和局方最初“1 年之内全省全面上线”的期望相差甚远，一期工程基本可以认定为不成功。在这样的更替中，原局方主要项目负责人和原总集成商直接出局，成为责任承担者。

　　此后，业内开始流传该项目一期工程实施不力的幕后原因，比较集中的说法是该电信公司采用的国外套装软件并不适用于国内电信运营商，存在“无法落地”的困难。事实上，从2004 年4 月项目启动，该项目就肩负要“超英赶美”的使命，局方决策层对“采用国外成熟套装软件”的方案寄予高度期望，希望借此在电信各省公司同期试点项目中率先做出成绩来。过高的期望值最终演化成“通气口堵塞的高压锅”，新系统在未经某些必要步骤的情况下强行上线，此后局方又不断提出增加新功能的需求。

　　在这样的背景下，该项目的局方负责人短时间内三易其人，从网络发展部移交到市场部，接着又转给了经营支撑中心。整个过程中，来自不同部门的负责人对项目存在不同的理解，对项目责任和部门职能问题一直无法达成共识。一位内部员工透露道：“当时，大家都明白，事情到最后一定要找一个说法。”于是，谁都不愿成为这个项目最后的责任人。

　　虽然原局方主要项目负责人和原总集成商表示在出局前，他们已经尽力弥补“软件不适用”所导致的问题，大量的系统缺陷已经悉数修补。“项目搁浅的最关键原因不在套装软件层面上”，公司领导层变动、项目相关业务部门权责边界模糊、本地网对新系统的抱怨等“桌面下的博弈”才是真正导致项目搁浅的原因。然而，这些技术之外的原因显然已经超出了一套软件系统或IT 部门可以控制的范围，但板子最终却落到了IT 部门负责人身上。

　　“分流”责任

　　近几年，随着信息化对企业作用的深入，信息系统已经由替代手工快速转换为整个企业运作、管理，甚至是变革的载体，由此“IT 推动战略转型”“IT 驱动业务变革”之类的话不绝于耳。因此，IT 项目的边际越来越延伸到企业的业务层面，需要更多IT之外的资源配合才可能成功。“IT项目绝对不是IT部门的项目。”M总工说道。

　　“我们的压力也非常非常大。”中国电信一级省份公司的企业信息化部负责人Z先生在得知兄弟公司综合营账系统陷于停滞、相关负责人出局后如是说。目前，这家电信公司的计费系统、CRM系统和经营分析系统同属全集团的信息化试点项目，也同样正面临着诸多困难。他坦承：“我现在最需要的不是资金，而是理解和支持。”

　　目前，他正在实施的几大系统因涉及到计费账务、业务运营，这等同于企业的“生产系统”，所以经不起任何闪失。对于这家电信一级大省的省公司来说，由于承担了集团信息化试点工程项目，近两三年所投入的IT 资金达几亿元，加上信息化部门人员、局方其他部门调配人员及实施方人员，常规动用的人力就超过千人。如何对这个投入巨大的项目进行高效的内部管理，获得各方资源并打通各种障碍，对这位CIO而言，显然是一个不小的难题。除了重新划定责任人之外，他想方设法尽可能地为信息化部门争取各种缺乏的“硬”资源，通过增加人员、资金来强化对风险的承受能力。在他看来，信息化就像是吃中药，“见效慢、政策性强、业务持久”，CIO 必须要有耐得住寂寞的心态。

　　在资源难以完全到位的情况下，他不得不通过“分流风险”的方式来处理技术与业务责任边界难以界定的问题。目前，Z 先生在推进各个IT项目时，首先由业务部门提出全部项目需求，再由业务部门调配人

　　员担任项目经理，他所领导的企业信息化部人员只担任项目副经理。他希望通过把责任人划归到业务部门，以降低信息化部门所需承担的风险。

　　对于这种问题，中国移动信息化工作负责人之一的N先生说：“为了把事情做好，我们不得不承担必要的风险。”中国移动集团曾在5 年前以信息化部门名义向各省公司下发“业务运营支撑系统(BOSS)改造指导意见”。这是一份“越权”下发的文件，其背后原因是当时主管“下文”的计划部门对此不认同。事实上，虽然N 先生今天所取得的成绩已经证明了那次“越权”非常值得，但在当年，这样的行为还是有点“壮士一去不复返”的悲壮色彩。

　　如果CIO 缺乏资源、权利，决策层和业务部门的“理解”不到位，CIO往往会陷于“不做等死，做了找死”的境地

　　因此，在目前实施IT系统的过程中，中国移动信息化部门同样采取了“分流”责任的做法。为此，他们定义了“无条件服从于市场部门”的基本原则，对市场部门无论任何需求“先说Yes”，在项目方向出现较大偏差或完全无法实现的情况下“再说No”。

　　从表面看，这些做法增加了信息化部门的工作难度，但实际上采用的是一种“服从风险”替换“组织风险”的迂回策略，从“分流”责任中博弈与责任匹配的资源。

　　在不得不“分流”责任的同时，有些CIO还不约而同地将成绩“分流”给业务部门，以期通过这样的置换，逐步获得业务部门的认可、支持，为IT 项目的顺利展开“牟取”资源。

　　近几年，“大集中”可谓国内CIO 们提及频率最高的词汇之一，越来越多的金融、电信、能源和集团化企业开始上马集中管理、集中业务等系统。在大势所趋之下，如果CIO缺乏资源、权利，决策层和业务部门的“理解”不到位，让CIO陷于“不做等死，做了找死”的境地，CIO很可能会选择“分流”责任的极致做法——完全被动地配合业务部门的需求或者干脆不作为。这样的话，最终承受损失的将是整个企业。

　　责任倒推机制

　　在采访中，几乎所有出局CIO都对其承担责任背后的真实原因不愿多谈，同时也不希望刊出他们所在企业和自己的真实姓名。

　　对此，国信证券公司技术总监廖亚滨认为这是由于国内尚缺乏完善的责任倒推机制，很多责任的背后可能直指企业环境、要害人物和要害部门，于是，并没有人想认真追究原因。的确，在各种事故面前，我们已经习惯找到几个责任人或者替罪羊、给出一些说法的处理方式。但当事故阴影过后，真正潜心倒推

　　事故出现的原因，并将其“扑杀”的企业并不多。

　　国外曾有一家航空公司的维修工在维修驾驶舱玻璃时，用的螺母比飞机原配件少几个毫米。就是这几个毫米的误差在空中酿成了大祸，使得飞机在飞行途中驾驶舱玻璃脱落，机长被强大的气流吸出飞机窗外。最终，紧紧抓住飞机的机长凭着他的沉重冷静和别的驾驶人员的配合，飞机顺利降落，幸好没有造成人员伤亡事故。其后，这家航空公司并没有急于处理责任人，而是请来专家一点点倒推事故出现的原因，首先堵住了飞机配件管理的漏洞。

　　接着，他们请来心理专家和那名维修工进行细致的谈话，让他回忆当时的所有细节，最终找出了维修工失误的两大原因：由于飞机维修场地狭窄，维修工是以一个比较别扭的姿势完成了螺母安装，因此他没有感觉到配件尺寸有问题；由于公司工作时间安排不合理，维修工经常处于疲劳工作状态，这也是他没有察觉配件有误的原因。找出原因后，这家航空公司马上扩大了飞机维修场地、缩短了维修工的工作时间，并请来心理医生给所有维修工做心理辅导，缓解他们的压力。

　　科学的责任倒推机制，让这家航空公司把出现同样事故的几率缩小到最低。这样的做法比仅仅处理几名责任人更加有效，企业为事故付出的代价也能真正起到交“学费”的作用。“其实，处理责任人只是手段，而不是目的。”廖亚滨说。

　　2003 年，业界广为流传着这样一个故事：一家以网络运营为主营业务的公司交换机出现故障，公司高层责令支撑中心负责人必须在12 小时内恢复网络。这位支撑中心负责人组织人力连续排障6小时，依然没能解决问题。最后在设备供应商的帮助下，他断然决定连夜将机房中的交换机柜全数运走，替换上新的交换机，这才逃过一劫。这位支撑中心负责人能如此神速地将事故化解，为业内人士所称道，其幸运也被同行羡慕。

　　任何CIO 都不知道这样的事故会不会在自己身上上演。一旦上演，并不是所有的CIO都有这份幸运。如果企业不引入科学的责任倒推机制，只是不断处理责任人、更换CIO并不能保证企业总有这样的幸运，这样的幸运里包含了太多偶然因素。一个好的机制才可能将偶然最大地必然化，这才是企业在让CIO出局后最该做的事，而不是把脚步仅止于CIO下课之时。