对日ITO失败案例的分析与思考

杨欢耸，詹国华，陈永强

(杭州师范大学 杭州国际服务工程学院，浙江 杭州 310012)

一 引 言

ITO是Information Technology Outsourcing的缩写，意思是信息技术外包，是指服务外包发包商委托服务外包提供商向企业提供部分或全部信息技术服务功能，主要包括信息技术的系统、应用管理及技术支持的服务。

最新资料显示，2008年我国的ITO业务中，32.3%的外包业务来自日本，24.6%的业务来自美国，12.9%的业务来自港澳台地区，7.8%的业务来自欧洲，上述4个地区的业务量占我国国际业务接包总量的77.5%。由于中国在文化上具有得天独厚的优势，再加上语言方面胜于其他国家的从业人员，使得日本的海外发包总额的65%外包业务流向我国，其中ITO占据较大份额，因此，我国是日本当之无愧承接信息技术服务的重要国家(数据来源CCID-中国电子报)。

由于我国信息技术服务提供商层次不一，在对日的ITO业务中常常出现一些不成功的案例，这不仅影响了我国外包企业的声誉，而且还增加了外包企业的风险。本文以一个对日ITO不成功的典型案例为例，通过系统的分析，揭示我国外包企业在对日ITO中存在的问题和可能产生风险，并提出系列的措施，以改进我国外包企业的管理水平减少风险。

二 案 例

客户是日本一家著名的大企业，全球500强之一。客户要求的内容很多，也很严格，不仅要求使用指定的技术和工具，而且还自主开发了一个平台，要求在该平台上进行开发、测试，还有各种文档格式要求和技术要求，最重要的是保证在2个半月内提供高质量的、完整的产品。*参见郑雄伟《国际外包全球案例与商业机会》，经济管理出版社,2008年第315页。

A企业竞得该项目40本程序的详细设计、编码以及单体测试工作。项目立项后，成立了项目小组，项目经理是一名对日软件项目方面有多年的开发经验，但他是第一次带项目。项目经理下设三个小组：负责详细设计的AS小组(6名成员)，负责编程的PG小组(5名成员)以及负责测试的PT小组(5名成员)；每一小组设置一名组长。同时，A公司在日方派驻了一名SE(高级分析设计人员)。AS人员具有丰富编程经验，提前一周进入了项目组工作；之后，PG和PT小组成员也开始进入项目。项目正式开始了，经过分析，项目组决定将40本程序分为A、B、C三类，分别为10本、12本、18本程序。其中，A类的难度较低，工作量也很少；B类和C类难度差不多，但比A类高，分别属于不同的业务领域。

一周后，为了保证工期，项目小组决定三个小组同时进行工作。项目经理决定PG小组首先从难度最小的A类程序入手，5名PG小组成员开始着手A类程序；一周后，A类程序全部编码完成，PT组开始测试，测试修改完毕后的10本程序全部交给日方，并顺利通过，得到了日方的极高评价。

项目组此时信心十足，经过仔细分析，剩下的B类和C类程序，并将其划分为人力系、Aatch系、账票系三类，比例大致相当。项目经理也更新了进度计划，每名PG成员分别负责2本人力系、2本Aatch系、2本账票程序。AS小组的工作也进展顺利。

此后，PG小组遇到了大难题——日方提供的开发平台太复杂。进而发现，已经完成的A类程序其实只是一种2层结构的程序，而B类、C类程序是复杂的3层结构，开发这些程序不只需要时间，更需要充足的经验和高超的技能。PG小组成员纷纷卡壳。

一周过去了，原定编写程序的实际进度在5%-10%，而这只是为了表明这些程序的开发工作已经开始，向客户展现一种开发中的姿态(每日都要给客户发送进度报表)，大家开始加班，两周过去了，技术最好的小G进度率达到了40%，而其他成员仍在原地踏步，烦躁、焦虑、疲劳，两名PG成员病倒请了假。三周后，除了10本A类程序全部开发完成，通过实证外，其他只有1本程序的进度率达到了80%。

于是，项目经理开始要求PT组有经验的成员加入PG组以填补空白。小G的程序完成了，可是运行不佳，又经过一周，基本可以运行了，但是还有很多技术问题，测试结果很不理想。

工期已经逼近，不能再等了，于是项目小组开始向公司反映情况。公司立即从其他项目中抽调了2名经验丰富的“技术高手”来协助。鉴于绝大部分程序的详细设计已经完成，召回了在日本的窗口SE——“业务高手”，同时安排大家加班。

为了很好地运用小组中的知识财富，A公司安排小G不再继续开发工作，做专职的问题解决能手。后来，集中大家的智慧，解决了人力系的难题，解决了Aatch系的没有界面而有极多数据复杂处理问题以及账票系的账票问题，快到截止日期时，原有的PG成员中有2名开始长期请病假。

所幸在截止日期的当天，所有程序都开发完毕，只是还有很多问题和错误需要修正，为了保证工期，将所有的测试报告中的“再确认”一栏填写上“OK”。项目经理提交所有预定提交的成果，同时PG和PT人员仍在继续奋战。

一周后，日方发过来大量问题，项目小组继续修正。一个月后，项目终于结束了，项目小组解散。

三 分 析

该项目虽然在规定的时间内完成了，但纵观项目的全过程，项目小组先是欢喜异常，觉得所谓的难度也不过如此，后来却感到惊慌失措，无法前进，原来骁勇善战的精兵猛将也只好当逃兵，称病请假。由此可知，虽然项目工期没有延迟，但是，程序运行问题很多(虽然后来得到补救)，所以说这是一个不成功的ITO案例。

分析原因一：前期分析不够

项目拿到手后才成立项目组，从这里可以看出，项目组对此项目的前期分析几乎为零。

分析原因二：项目经理经验不足、管理混乱、计划欠正确

项目经理在对日软件项目方面有多年开发经验，但这是他第一次带项目，虽然从难度最小的A类程序开始固然可以鼓舞士气，但作为总管，应该从全局出发，按照各种技术类型，即入力系、Batch系、账票系三类中各选较典型的一本,派最强的人员进行攻关，作出样板，然后大队人马开始行动，这样可大大提高开发效率，而一下子铺开，出了问题将付出高昂的代价，从这点来看，项目经理明显带队经验不足。

项目开展三周后，问题就已经很突出；可是，由于刚刚当上项目经理为了证明自己的能力，没有及时向上级汇报问题，而是将责任推给项目组成员，让大家加班加点，完成任务。另外只要一个电话就准假，小G作为高手也没有得到肯定，说明团队的管理较乱，激励和惩罚措施至少是不力。知道离期限不到三周，B类和C类程序的开发工作量还不到1/30的时候，项目经理才向高层汇报情况，说明公司项目管理体系有一定问题，作为高级项目经理，项目在计划上没有对A、B、C类进行逻辑分析，规划出合理的进度网络或里程碑式的管理，人力资源管理也没有计划好，这就出现了所谓的“救火”问题。

分析原因三：项目没有进行WBS分解，任务分配不科学

从项目后续期间产生的问题及项目进度计划看，项目经理根本没有对项目进行WBS分解。比如，项目经理为了鼓舞士气，将最简单的A类程序先完成，而将应该首先解决的技术难点和关键点安排在后续完成，导致项目的严重延期。

另外任务量的分配多少是由量和难度决定的，像A类较为简单，只要1-2人就行，难度较大的B、C类任务，就应组织多人攻关，如果人员不够也应该及时的由DS等技术人员加入解决，而不是让经验不足的PG浪费宝贵的开发时间。

分析原因四：项目风险估计不足

项目经理为了追求一时的“首战告捷”缩短了项目需求分析时间，对A、B、C类内在的联系分析不足，也没有对技术风险进行分析，导致由于平台技术问题，在“工期已经非常逼近，不能再等了”的时候项目经理才向公司求援，明显是项目经理风险意识不够和对风险估计不足。

分析原因五：缺乏沟通

SE在整个项目“工期已经非常逼近，不能再等了”的时候出现，所以SE在项目中没有真正发挥作用；另外，PG成员中的小G认真分析日方的资料，而其他成员均无所适从；再者，在不能再等了的时候向公司求援，这都说明项目组成员之间及项目组与公司沟通不畅。

分析原因六：遮掩问题

为了保证工期，项目经理决定暂时将问题和错误隐蔽，将所有的测试报告中的“再确认”一栏填写上“OK”，这是很不负责任的做法，这样做不仅收款时会困难，而且还会砸自己和公司的饭碗。

四 启 示

启示一：项目计划要符合实际，出现问题要及时与发包商沟通

从这个失败的ITO案例可以看出，项目经理由于经验不足，对项目计划过于乐观，而且计划不切实际，也不合理。在项目早期，项目小组成员对日方的数百页开发手册有些敬畏，都感觉到这个项目的难度，但不知道难度具体有多大。项目经理为了稳住军心，先将难度最小的A类程序排在进度的最前沿，因为按照A类程序的进度，他的乐观推算如下：1名PG用2天完成1本程序，加上B类C类程序的难度，保守估计4天1本。那么完成40本程序的编程大概需要32天(每人8本)。一名测试人员用1天时间设计1本程序的测试书，2天测试完毕。1本程序在PT上大概需要3天时间，保守估计5天，完成40本程序的编程大概需要40天，而且测试不存在较大的难度，总之不会超过总工期44天。但是，他忽略了一点，在项目组成员从对项目的敬畏和担心解脱出来后，忘记了难度分配计划和进度计划，导致后期出现技术瓶颈，而又迫于期限，击垮了项目组成员，吓退了本应神勇的战士。

因此，作为项目经理，在项目进行前要根据发包商的需求与技术专家一起分析各个模块的难度及所需工时，对项目的技术、业务和管理风险进行全面的分析，并做好初步的WBS，使项目计划准确。另外也要计划好人力资源，在计划过程中对出现的问题要及时与发包商沟通。本项目中，项目经理可根据情况，对编程人员及时进行技术培训，对难度较大的B、C类项目要较早地组织DS及SE进行技术重点攻关。

启示二：任务分配要科学

由于忘却了难度和复杂性的威胁，项目经理的任务分配出现了问题。他在A类程序成功完成的情况下，分配每名PG成员分别负责2本人力系、2本Aatch系、2本账票系程序。这样一来，每一名PG成员都需要去学习掌握如何编制人力系、Aatch系、账票系的程序，需要处理这些复杂的程序中潜在的技术难题。

但是，所有的人力系程序都具有相同点，只要写好1本，其他程序就可以仿照。如果写1本需要10天，那么写第2本可能只需3天。同样，Aatch系程序和账票系程序也具有类似的特点。正是由于项目经理忽略了这种学习能力，导致大家去做同样的攻关工作，造成智力和时间的浪费，也影响了大家的情绪。直到后来安排专门的技术专家，集中解决问题，其他成员在技术专家指导下工作，提高了开发效率才得以完成。因此，计划失策、预计不准确、缺乏危机感、任务分配不科学，必将导致ITO项目的失败。所以项目经理除了要制定合理的计划外，更要熟悉软件工程开发中的学习曲线作用。一般情况下，根据学习曲线，开发同类型程序，第二次就会比第一次节约20%以上的时间。

启示三：应引入里程碑管理

里程碑一般是项目中完成阶段性工作的标志。不同类型的项目，里程碑也不同。如在开发项目中，可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。在本项目中，项目经理可以将A、B、C三类程序划分为三个最终里程碑，其间可穿插小的里程碑，然后根据实际情况，实行各个击破。

在里程碑管理中，不管哪一个里程碑，项目经理应与项目组成员一起及时对前段工作进行小结，并对后续工作进行计划调整。对于一些成效明显的部分，可以不必投入较多的精力，而对下一步过程可能会出现问题的部分，应给与较多的关注和组织力量集体攻关。

启示四：应有一定的团队纪律和奖惩措施

一个电话，不管是否真的有病就立即准假。小G作为程序开发的先知者，却不闻不问。这些原因都导致了本项目的失败。因此，制订一定的团队激励机制和惩罚措施，并加强项目组成员的沟通也是项目成功的关键因素。

启示五：项目组应尽早成立，并参与项目的投标

项目拿到手后才成立项目组，说明投标环节中没有项目组人员参加或参加的核心人员很少，以致出现了项目组成员对本项目的技术要求不清楚、需求不明白的情况。所以尽早地成立项目组，并参与整个投标的过程与管理也是项目成功的重要因素。

另外，项目经理可根据本公司以往对日软件承包的历史数据，绘制时间与质量关系的曲线(两维坐标图，数据之一为完成之项目时间5天，结果测试时有15个问题……)，如图1所示，就会得到一些离散的点(不考虑资源的差异)，在考虑项目允许的质量范围内，对照图中数据找出相应的参数，确定适合的进度计划也是很必要的。

图1 质量参数图

启示六：不宜隐藏BUG问题

为了保证工期，项目经理将所有测试报告中的“再确认”一栏填写上“OK”，隐藏了很多BUG问题，这样的做法不可取。如果项目经理碰到了这些问题，应该向日方及时汇报，对延误情况以及存在的问题进行说明，并提交变更申请，对进度进行调整或对资源进行重组，这样做不仅可以取得日方的信任，也有利于公司的声誉，否则会导致公司信誉的丢失。