新CIO如何对“烂尾工程”进行价值重建？

　　一个企业、CIO最不愿意看到的情况，就是自己IT的项目悄无声息的“烂尾”，成了烂摊子——工期遥遥无期，费用远超预算，大部分功能闲置，领导不满意，员工漠视，甚至陷入投资黑洞，进退维谷，形成瘫痪状态，不知如何处理，而一些IT项目即使在换了供应商，仍无起色，难于启动，厂商进入一种恐慌性的混乱状态。

　　烂尾的IT项目三个案例

　　下举三个失败、曾处于烂摊子状态的IT项目，以飨业界：

　　1、××汽车公司于2006年开始着手MRPII(物料需求计划和制造资源计划)项目的大规模建设，目标是实现全公司订单、生产、库存、销售、人事、财务等统一管理，以提高公司运行效益，增进企业经济效益。

　　然而遗憾的是，由于该公司属于中德合资，外方起决定作用，他们照搬德国的模式，使该公司MRPII洋味太浓，水土不合，不适国情，企业MRPII陷入进退两难的境地。主系统十几个功能模块，已经启用的仅有非生产件的库存管理模块MHF，不到该软件内涵的十分之一，2006年后一直没有多大进展;MACH7财务系统仅完成凭证录入、过帐、对帐、关帐等功能，报表只能用微机处理;PMS人事系统准确地说只是一个数据库，只有输入、修改、删除功能，报表及各种统计均靠微机进行。

　　投下巨额资金，信息化的作用却与当初的宏图大略相去甚远，没有有效提高企业管理效益，MRPII成了“半拉子”工程。

　　2、××电气公司于2005年初，采用国内一家大型ERP厂商的产品来实施ERP，一开始包括数据整理、业务流程重组，以及物料清单的建立都很顺利。厂商的售后服务工作也还算到位，基本完成了产品的知识转移。

　　然而，计划赶不上变化。到了2006年底，该公司发生并购大事，组织结构重大调整。但是该公高层在调整的过程中，显然没有认真考虑企业结构调整对ERP项目的影响。企业经营结构变了，而当时所用的ERP软件流程却已经定死了，此家ERP厂商也似乎无能为力，想不出很好的解决方案，显然继续运行已经失去了意义。如推倒重来，则要增加50%以上费用。于是该公不得不与此家ERP商协调，项目暂停。

　　3、××大型饮料公司于2006年3月与一家大型ERP厂商签订了ERP实施合同。合同中ERP商承诺6个月内完成实施，如不能按规定时间交工，违约金按千分之五来赔偿。

　　合作的双方，一方是饮料行业的著名企业，一方是国内IT业领头羊的直属子公司。这场本应美满的“婚姻”，然而就因为该ERP软件产品汉化不彻底，造成了一些表单无法正确生成等问题出现了“婚变”。后虽经再次的实施、修改和汉化，包括软件产品提供商也派人来该厂解决了一些技术问题。但是由于汉化、报表生成等关键问题仍旧无法彻底解决，最终导致项目的失败。

　　由以上三例，我不想起“上ERP找死，不上ERP等死”这句业界常言。其实何止ERP如此，即是中小型的IT项目如OA、CRM等，其成功率也不足45%，客户满意率不到30%，有不少项目照样成了“食之无味，弃之可惜”的烂尾工程。

　　IT建设“烂尾楼”的分类

　　1、从内容可分为：产品性烂尾、策略性烂尾、人员性烂尾三大种。产品性烂尾是指产品因自身功能、质量问题，难于发挥作用，无法为客户单位提供有效的信息化服务，最终失败;策略性烂尾指IT供应商提供的产品价格过高、服务收费用昂贵，最终超过客户单位所能承受的能力而无法继续下去;人员性烂尾是指供求双方的人员由于种种原因，造成双方无法合力，使IT项目无疾而终。

　　2、从程度可分为：轻度性烂尾、中度性烂尾、重度性烂尾。轻度性烂尾是指IT项目陷入短期困境，出现“溃脓”现象，但经过“急诊”，项目可救活，可恢复运作;中度性烂尾，是指IT项目出现较长时间的大面积“溃脓”，但经过“抢救”，项目可救活恢复，但厂商为此元气大损;重度性烂尾，是IT项目已病入膏方，死气沉沉，即使抢救，已毫无意义。

　　3、烂尾从时间可分为：间歇性烂尾、长期性烂尾。间歇性烂尾是指IT运营时故障有偶发性、突发性、时间短的特点，有可能加剧也有可能恢复常状;长期性烂尾是指IT项目故障或停滞在三月以上，“病发期长”，已难于根治。

　　4、从范围可分为：局部性烂尾、区域性烂尾、全局性烂尾。这里不再赘述。

　　目前全国信息化建设有多少烂尾市场？每家企业有多少烂摊子？这些烂尾市场对厂商的影响又是多大？清理收拾这些烂尾项目又要花费多少钱财？也许谁的心里也没人准确数，但这些数字肯定是惊人，普遍存在的。

　　烂尾就如厂商脸上的疥疤，难看又难受。但非SARS、HTV，决非不可治之症，也非一点价值之处也没有。烂尾，有专家用“鸡肋”喻之，食之无味弃之可惜，也有比之似垃圾，但可进行“变废为宝”、“变旧为新”的处理，使之由烂变鲜，起死为生，烂尾工程变成“金包银”工程。包括以上三例的烂尾工程，如今通过新任的CIO种种努力，也“柳暗花明又一村”了。

　　新CIO如何对“烂尾工程”进行价值重建？

　　凡此种种，引发今日的主题：后任CIO如何收拾“临阵下马”、“半途而废”的烂尾IT项目，实现“变旧为新”、“变废为宝”的价值重建？

　　勇于面对“烂摊”。对上任留下的“烂摊子”，新CIO不要全盘否定，要学会扬弃，去除糟粕汲取精华，同时对原有IT部员工的工作要适当给予肯定，充分调动他们的信心和创造性，重启新征程。烂尾项目历经几位前任CIO的耕耘，也有一定的管理、布置、网络基础，巧做烂市，善收烂尾，死机也会变商机。因此只要处理得当，对于后任CIO反而是体现自身新价值的良机。

　　制定严格IT管理制度。后续项目要重新启动，注入新活力，保质保量如期完成，CIO就必须设立清晰的目标和实现目标的进度表进行统领：按各项任务按照轻、重、缓、急列出计划表，逐一落实;目标一定要可衡量、可检查，不能含糊空洞;目标一旦确定，一定要层层分解落实，加以实现。而要有效实现绩效目标，CIO需要制定有严格完善的管理制度，明确责权利，律令得当，赏罚分明，以有效引导员工的工作，保证执行效率。而实现以任务执行为中心的绩效考核机制，将是一个非常有力的激励杠杆，能提升IT员工执行力的一个有效的催化剂，能起到价值导向的功能，并将团队的优秀价值观和核心理念加以强化。

　　比如，CIO可对相关技术人员的每天工作进度、周工作量、月工作汇报、半年工作总结，以及参与团队协作的任务数量与质量等方面进行统计与考核，用制度保证效果，从而把信息化建设与制订企业经营发展战略、推动企业管理现代化进程和CIO、技术员的业绩考核有机结合起来，促使他们在感受外部压力的同时都认真投入到项目重建中来。

　　CIO要加强自省自察力。CIO加强自省自察力的主要表现为“三省五察”：“三省”就是(反)省己省人省势，“五察”就是“察天察地察人察事察岗”，一日三省五察，抓紧不放松，防止不良率提高与烂尾再次发生。CIO应仔细分析研究烂尾的原因----是宏观大环境(企业管理基础不好)还是微观调控(实施操作、推广培训)造成，是策略性失败(选型)还是投入性不足引起？是我方原因还是供应商、实施方原因？烂尾事件为何悄然不觉发生？等等。总之，CIO应知己知彼，对症下药，纠正原来信息化建设模式，采用新开发管理模式，比如建议健全企业管理制度，完善管理流程，提高软件选型能力，做好预算计划，搞好IT培训，引进竞争机制等，以此修善完复烂尾工程。

　　突破原方案束缚。新CIO接手一个未完成的项目，本来就有一定的风险。但是，既然接手，那就要对整个项目仔细分析，找出其中有用的东西。同时也要对其中的问题改进和调整，对进度做必要地调整，大胆创新完善，跳出原有的框架，不能被原有的方案和合同所束缚，否则将陷入已有的烂摊子，重启项目就很难了。

　　建立有效的解决冲突机制。项目萎了，烂了，一个重要原因，就是甲方、乙方在实施IT项目过程中难于配合，发生冲突，造成IT建设偏离轨道。甲方CIO与乙方供应商冲突是难免的，关键是事先是否有明确的项目目标和项目要求，是否建立起有效的冲突解决机制。主要是要明确今后双方责权利关系，可对将来可能发生重大事件或不可抗拒事件所引发可能的实施超期、费用超支、产品价格调整以及服务收费超标等事项、行为及其权责做出预测，并有效约定，从而使IT项目从一开始就按预定的规道行驶，避免再发意外。因此要快速查找以前问题所在，既然上次合约没有明确细节，也就意味着可以增加内容，明确细节和进度，从合同中挑出对方的问题，与对方补签合约，保证重建项目有效进行。

　　以质量、成本为中心管控项目。项目实施的质量是公司和CIO最为关注的问题。项目质量控制不力会使项目再度无法推进，“烂尾”现象也难于“鲜活”了;再者，一个项目难于为继，是因为财力无法继续支撑，甚至远超预算而又没有很好的实施效果，就会造成直接经济损失而成了烂尾项目，这在大型ERP项目尤为明显。因此再度启动老项目，在收拾烂尾、激活烂项目时，CIO一定要算计好在一定的时间范围内，一定要紧抓质量、成本这一“牛鼻子”不放，综合考虑项目环境和项目价值，以便投入合理的人力、物力以尽可能低的成本完成项目。

　　力求技术补救。在IT建设中，一些管理软件要么功能不强，要么性能不匹配，或是技术构架不好，中看不中用，成了摆设。因此采用技术升级完善，补救弱项，以激发全项目正常运作就显得重要。

　　某饮料企业采用某开发商的CRM系统采集汇总各地分公司的销售数据，却发现出现这样的大问题：输入销量时，要从每个零售店的界面中选择弹出一个窗口，再一个机型一个机型地录入，假设一个分公司管理二百个零售店、十个机型，意味着要进入二千次界面。

　　采用几个月后，各地统计员、录入员怨声载道，纷纷罢用。如果这问题不解决，该CRM还不如一个简单的EXCEL电子表格，等于白买废用了。后来该企业新来的CIO灵机一动，对CRM系统进行升级补救，小改小革，使该CRM “变废为宝”：

　　只需把零售店界面改成一个窗口，设立一个可输入零售店编号的控件，然后根据所输入的零售店编号再在下部的输入框中输入相应的数据予以保存，保存成功后再输入下一零售店编号即可。这样一来，可大大提高工作效率，更不需要进入二千次之多的繁琐操作。

　　权衡二次开发必要性。信息化建设少不了二次开发和实施，这在烂尾的IT项目更为明显。比如，ERP软件原来提供的报表功能很通用，但是却可能碰到需要特殊格式报表的企业，而这无法通过调节参数来完成;或随着企业的发展、变革、改组，导致报表样式、内容要改变，这些情况就必须通过二次开发来实现。但是不少不合要求的项目“二次开发”后，系统变得越来越复杂，甚至完全“变味”了。因此，CIO把握二次开发的原则很重要：一是不要过多的强调企业自身特点，不要一味修改软件以适应不合理的流程;二是在二次开发中，应把“不要修改核心代码”作为基本原则;三是修改不宜过多，以防最终导致项目不可控，使项目延期，再成烂摊子;四是二次开发的时间性应控制好，也要谨防过度追加预算，导致再陷投资黑洞。二次开发是技术补救的完善。

　　再次强化验收。验收是最后关键的环节。比如ERP项目，由于其软件的复杂性、规模性，人们可能更多地关注它多变的需求定义、个性化解决方案，却轻视了项目的验收工作，而验收需要大量数据测试、自定义扩展、长时间运行等后才能明辨优劣、成效，但是由于供需双方受种种原因的影响急需“结账”，从而使项目验收从时间、内容、范围、数量、人员等投入均显不足，而且由于多数信息化项目的验收评估标准难以具体量化，更使验收常流于形式，形成一个个延期工程或烂尾项目。上述××汽车ERP就是验收失位而造成的。因此新CIO在收拾重启烂摊时，一定要重新明确、制定每个阶段验收标准和项目总体验收标准，时刻维护验收的严谨性、权威性和准确性，必要时可请第三方咨询顾问机构来帮忙把脉把关。

　　敢于釜底抽薪。为何资金一投再投，建设工期仍一拖再拖，可企业仍陷于进退两难之境，除了忧柔寡断，“死马当活马医”仍是用户根深蒂固的想法，就是因为害怕已经投资的那些钱都打水漂了。可是难道没有想过，继续执行一个不良、劣质的项目对IT部门和业务来说都将有长期的、深远的不良财务影响？因此CIO当发现IT项目已是“死机”状态，就要敢于釜底抽薪，果断停止项目再进行，而不能抱着侥幸的心理而使项目陷于无底洞，大伤企业元气。否则越陷越深，终为困死。当然这是万不得已的最后一招。抽身而退，并非终身而退，也是权宜之计，在企业发展壮大之时，可重起炉灶，东山再起。

　　厦门某一机关单位三年前采用上海某供应商的OA软件，然而在不断应用和推广过程中，暴露了不少的问题，如“信息鸿沟”、“知识分布不均匀”、“应用水平低”、“技术跟不上”等，该OA系统已远不能满足政府现代化办公需求，甚至一度出现停用的状况，该单位CIO为此挨批。

　　这些问题和原购于上海某供应商的OA系统有很大关系。当时此OA系统采用的是Client/Server(客户机/服务器)结构。此结构把数据库内容放在远程的服务器上，而在客户机上必须安装相应软件。这种结构的程序是针对性开发，变更不够灵活，维护和管理的难度较大，不利于扩展。

　　这促使该单位起了更换系统的念头。同时，基于Web系统、采用最新的B/S结构的第三代协同OA开始兴起，比原有C/S模式的OA，界面更加美观，操作更加简便，数据交互性能有较大的提升，可维护性强，可靠性、稳定性高。2007年1月，通过切换、调整和升级，该单位果断停止使用了原OA系统，而改采用B/S架构的某新开发商OA系统，从而使OA系统焕然一新，大大提高了行政办公效率。

　　烂尾项目虽烂，但并非一点价值也没有，也决非无法攻取。CIO只要树立让“鸡肋”变为“香饽饽”的坚定信念，有勇有谋、敢作敢为，烂尾的IT项目也能“由烂变鲜，变废为宝，起死为生”，成了“金包银”工程，让企业、供应商最终双赢!