目录
Content

- 掌握主动—— 与其等死，不如找死(1)

- 掌握主动—— 与其等死，不如找死(2)

- 掌握主动—— 与其等死，不如找死(3)

- 走出混沌— 从三边工程到实施方法论(1)

- 走出混沌— 从三边工程到实施方法论(2)

- 前车之鉴—“六拍”项目的深度思(1)

- 前车之鉴—“六拍”项目的深度思(7)

- 前车之鉴—“六拍”项目的深度思(8)

- 失败归因—IT项目四大败因分析(1)

- 失败归因—IT项目四大败因分析(10)

- 痛定思痛— ERP项目失控的九大原因(1)

- 痛定思痛— ERP项目失控的九大原因(2)

- 痛定思痛— ERP项目失控的九大原因(3)

- 痛定思痛— ERP项目失控的九大原因(4)

- 痛定思痛— ERP项目失控的九大原因(5)

- 痛定思痛— ERP项目失控的九大原因(6)

- 斗转星移—信息系统在管理中地位变迁(1)

- 斗转星移—信息系统在管理中地位变迁(2)

- 数字说话—— 效益才是硬道理(1)

- 数字说话—— 效益才是硬道理(2)

- 数字说话—— 效益才是硬道理(3)

- 数字说话—— 效益才是硬道理(4)

- 谋定后动— 信息化规划势在必行(1)

- 谋定后动— 信息化规划势在必行(2)

- 错落有致—集团企业信息化规划原则(1)

- 错落有致—集团企业信息化规划原则(2)

- 掌握规律— ERP实施项目的六大特点(1)

- 掌握规律— ERP实施项目的六大特点(2)

- 驾轻就熟—成熟软件背后的四重内涵(1)

- 驾轻就熟—成熟软件背后的四重内涵(2)

- 驾轻就熟—成熟软件背后的四重内涵(3)

- 准确度量—软件项目规模估计有法可效(1)

- 准确度量—软件项目规模估计有法可效(2)

- 科学估算—应用PERT估计项目工期(1)

- 科学估算—应用PERT估计项目工期(2)

- 一将难求—四种人不适合当项目经理(1)

- 一将难求—四种人不适合当项目经理(2)

- 团队建设—搭班子，还要带队伍(1)

- 团队建设—搭班子，还要带队伍(2)

- 团队建设—搭班子，还要带队伍(3)

- 同曲异奏—高效能项目团队的五大特点(1)

- 同曲异奏—高效能项目团队的五大特点(2)

- 因势利导—掌握团队表现的规律(1)

- 因势利导—掌握团队表现的规律(2)

- 合文齐武—项目激励和约束(1)

- 合文齐武—项目激励和约束(2)

掌握主动—— 与其等死，不如找死(1)

一谈到ERP项目，有一句广为流传的话不容回避，那就是：不上ERP等死，上ERP找死。这句话在业界流传很久，影响很大，以至于几乎所有涉足ERP的人都知道这句话。据我后来了解，这句话大概是柳传志先生在总结联想ERP项目实施经验时讲的，从这句话诞生到现在的近十年时间里，有很多很多企业界同仁，也有很多很多ERP项目实施顾问，更有很多很多个项目，都在用其真实的经历验证或是反驳这个论点。

说上ERP是找死的道理是什么？如果这句话成立，为什么明知道上ERP是找死，还有那么多企业要上？这句话常让我想起吴广在大泽乡起义上讲的那句：“今亡亦死，举大计亦死，等死，死国可乎？”大概不上ERP就相当于“亡亦死”，与其不上ERP而坐以待毙，还不如主动撞上去找死试试，所以上ERP就相当于“举大计”了，举大计还是有成功希望的。

上ERP就一定是找死吗？我们要分析一下这句话背后的逻辑，或者说支撑它的依据有哪些？追溯到20世纪90年代，那时候企业上ERP是一个什么样的背景和环境，在当时那个环境下，上ERP是找死说得也有道理，也确实有不少企业为此投入的数百万的巨资打了水漂。不过，时过境迁，今天的形势与往昔有了什么变化？我们要重新审视一下。

首先，十年前我们是怎样做项目的，十年后的今天我们又应该如何做项目？在当时，国内企业管理还很不成熟、不规范，甚至计划经济的影子还没有完全消退。当时的企业管理根本没有很多先进的理念，很多决策是盲目的，甚至是按上级计划简单执行，当时所谓的ERP理念与企业实际的管理距离也相差很远。现在的ERP实施过程有标准的实施方法论指点，整个过程分几个步骤，每个步骤有哪些作业，每个作业中甲方应该做什么，乙方应该做什么，应该有哪些阶段性成果以及如何检验这些成果等都有了非常具体的规定。特别是最近几年在国内掀起项目管理热潮，各行各业项目管理的意识和水平都大有提高，ERP实施领域也不例外。

其次，ERP是空降到国内的，就像当年的马列主义思想传入中国一样，有一个被大家学习和接受的过程。ERP的概念是IT企业率先在国内推广的，并且有“ERP”这三个英文字母的洋称呼，也使其一开始就戴上了高科技的神秘面纱，企业界人士也因此误以为ERP是庞然大物，并没有把它和企业业务、事务紧密联系起来，这也是我们当年走弯路的主要原因。直到2007年，用友公司提出“懂业务，就懂ERP”的口号，才拉近了ERP和企业管理事务的距离。我前不久拜访了一个早在2003年就认识了的客户，听这位老总讲，他20岁时就开始在工厂做计划员兼采购，那时候应该是20世纪70年代。厂里那时没有计算机，他只能整天拿着一个算盘，算来算去。然后按订单排生产计划，再查库存量，核定库存空缺，再下采购订单。每天要花几个小时算账，算完就在小本子上记下，拟好订单后，采购人员就照单抓药，该采购的采购，该领料的领料。当时他就想能否借助什么工具来替他完成这些工作。2003年，他在我们的邀请下做了一次ERP沙盘模拟后，才知道自己一直想要的工具就是ERP，只不过起了个神乎其神的名字而已。后来他说，其实20年前他就懂得ERP，所以ERP本质上是业务。

掌握主动—— 与其等死，不如找死(2)

第三，还要有政府的大力推动。当年我们国家的CMIS工程、863计划，都是政府投入巨大的资金帮助一些企业实施信息化的。虽然这些企业最后没有几个非常成功的，但是客观上还是起到理念普及和人才培养的作用，当然，负面的教训就是使得一些企业过早地尝到了ERP实施失败的经历，成了惊弓之鸟，以至于当年投巨资上ERP失败的企业，至今仍没有勇气面对失败，重新选型实施。“十五”期间，我们国家就已经提出“用信息化带动工业化，以工业化促进信息化”的重要战略。这些年来，各级政府机构，如各地生产力促进中心、科技局企业信息化办公室等都花了大量的财力物力组织企业学习培训，树立了不少示范企业，政府的导向作用对推动ERP的普及起了很大的作用。

第四，从企业来讲，随着市场经济的深入和竞争的加剧，企业强化内部管理和控制的意识在不断加强，越来越多的企业已经意识到，借助现代信息化技术手段打造企业内部运营管控体系才是应对国际竞争的法宝！但在十年前，很少有人能认识到这一点。

最后，就是实施ERP的人员基础，十年前企业上的ERP普遍掌握在少数人手中，第一代实施ERP的人都是企业中的IT大腕，使得企业的ERP系统只有少数人能够操作和维护。另外，当时的IT从业人员比较浮躁，第一代从事ERP实施的人后来很快就被进入中国的外企挖走，当时的ERP项目失败与企业关键人员流失有很大关系。前几年，我在一个企业讲ERP的时候，这个企业的老总说：我什么都不担心，就担心一点，担心ERP实施成功了，培养了一批人，这些人走了，ERP又坍塌了。因为他们企业以前的项目就是因为这个失败的，当时从事该领域的人员特别少，而且非常浮躁，搞IT的又好找工作，都能拿高薪，所以一不如意就辞职。现在中国的很多大中城市，电脑的普及率已经超过50%，中国网民数量也已经超过一亿，电脑的普及为企业信息化奠定了很好的人才基础。

掌握主动—— 与其等死，不如找死(3)

在以上五个因素的作用下，如今的形势已经不再是上ERP找死了，反倒是不上ERP等死成了大家的共识。尤其是入世六年以来，越来越多的企业意识到不上ERP没法面对国际化竞争。

现在的ERP普及到了什么程度？我举两个例子。一个是我最近几个月遇到的案例。有一位企业老总，他买了我们的ERP，我闲聊中问他：“你为什么想起要上ERP？”他说：“坦率地讲，到现在也没有完全想清楚为什么要买ERP，但是我周围的企业，我的同行企业、上下游企业都上了ERP，以我多年做企业的经验，隐约觉得我的企业不能在这方面落后，就像您家的小孩到了六七岁还没上学，尽管不识字的家长不完全理解孩子为什么要上学，但别人家的孩子都上学，咱们的孩子就要上学。”可见在政府、供应商的大力推动下，ERP普及已经深入人心。还有一家企业之所以找我们买ERP软件，是因为他是国内一家知名制造企业的原配件提供商，这家知名制造企业就要求他说：“你要是再不上ERP，就停止给我们供货！”所以，很多事情就是大势所趋，周围的环境可能逼着你来上ERP。

再举一个例子，有一个采掘业企业，信息化水平相当低。他们的一把手上了EMBA，在EMBA课堂上参与了一个信息化与企业管理的案例讨论。这个老总后来跟我交流的时候说：“在EMBA班上，我有很多次讨论都显得出类拔萃，突然在这节课上，我发现自己跟傻子似的，觉得自己跟其他同学差距很大，坐不到一个班里。回来以后，我的第一个念头就是赶紧得上信息化！”可见，企业的内外部环境、国际的竞争、上下游企业，甚至高校的管理课堂，都在探讨信息化管理的话题，不上信息化几乎是等于与世隔绝！

前几年，业界都在讲，信息化是一个是非题而不是一个选择题。不少企业领导者还存在上ERP就是找死的心理阴影，同时，也存在不上ERP就是等死的竞争压力和推动力。现在看来，上ERP是必然，就像一位老总讲的：“你不上，竞争对手上，你的客户要求你上。”不用ERP武装自己的企业，在国际竞争中，就像当年大清朝用木船土炮和外国列强的坚船利炮对垒一样！

最后还借用柳传志先生的话来说明主动找死比坐着等死要好得多。他在谈联想收购IBM的PC业务时说道：“如果联想没有经过ERP的整合，没有一系列的重大改革措施，还是个比较老旧的企业，那么不管我们怎么努力，双方(指和IBM)是没法磨合的。”

走出混沌— 从三边工程到实施方法论(1)

关于IT项目管理，在网上流传很广的说法是“三边六拍”项目，虽说这是对IT项目的揶揄，却也总结得非常经典，切合当时的实际。但是网上没有一篇文章对“三边”和“六拍”作详细注解的，现在这里对“三边”工程作些详细的注解。

所谓的“三边”，就是指项目实施过程中“边计划，边实施，边修改”。我最早听到这种说法是在1997年，当时给一个招投标机构作内部管理MIS，他们的领导揶揄说现在不少项目做成了“三边”工程，并详细诠释了“三边”的含义，当时就令我咂舌称叹，说实话，那时候的IT项目基本上都是“三边”工程。

首先，第一个环节就是不规划先行动起来，叫做“边计划”。其实现在想来，这也符合事物发展的必然规律，谁第一次做项目就能规划得滴水不漏，头头是道？我想应该都是摸着石头过河！在当时，管理过较大IT项目，尤其是软件开发类项目的人非常少，也没有几个成功的项目案例值得借鉴，没有人知道规划阶段究竟要想清楚哪些东西才可以动手。通常在项目计划的过程中，项目经理并不知道要达到什么具体的目标，要形成一个什么样的最终成果，也不知道这件事情该如何做。多数情况是范围不清、目标不明，盲目地、朦胧地凭感觉来做，在规划阶段给项目经理再多的时间他也想不清楚到底要规划哪些方面，规划到什么程度，所以只能是边走边计划。

第二个环节是边走边看，叫做“边实施”。实施过程就像傻女子和面，面多了加水，水多了加面，最后把人都糊到面团里了。我们经常讲哥伦布式的管理，项目实施也有哥伦布式的项目。所谓哥伦布式的管理就是：走的时候不知道要去哪里，去的时候不知道到了哪里，回来的时候不知道去过哪里。整个过程是一种布朗运动，完全是一个无序的混沌态。

第三个环节是边做边改，称为“边修改”。做项目的人都知道，计划赶不上变化，项目是在复杂多变的环境下进行的，注定要发生很多始料未及的事情。情况变了，就要随需应变，就改吧。改来改去改成什么样子谁也不知道，反正最终的结果是什么样大家都不清楚，就顺其自然吧。

走出混沌— 从三边工程到实施方法论(2)

“三边”工程的结果是未知的，全是凭运气，运气好就成功，但是成功了也是撞大运撞上的。后来经历的项目多了，人们才逐渐从“三边”工程的阴影中走出来，结合多个项目的功过得失，总结形成ERP项目的实施方法论。所以说，实施方法论背后应该是一部血泪史—— 其中不少弥足珍贵的经验或原则是人们在诸多项目失败的痛苦中总结出来的。有人说，方法论来自失败和恐惧，是诸多ERP实施的先驱们痛定思痛的结果，是实施专家经过理论研究并在总结了无数企业实施案例和成功经验的基础上提炼而成的，是产品成熟度的标准，也是企业管理软件供应商拥有完整应用解决方案的标志。因此，实施方法论有资格成为指导IT供应商进行系统实施的纲领。

ERP实施方法论是在项目管理普遍思想的指导下，汲取诸多ERP项目实施过程中的经验和教训，逐步形成的一整套用以指导ERP项目实施的方法、过程、工具和模板的集合。不管哪家的实施方法论，不管他把项目分成多少个步骤，总体的思想和要求都是一致的。ERP实施方法论至少应该在以下方面对项目执行者进行明确的规定：

对项目范围界定和工作任务书有严格的定义；

对项目目标进行详细的分解，把目标分解为若干个可以单独执行的任务；

对各个阶段做了明确的划分；

对项目组织有明确的要求，双方责任界定清楚；

对每一个标准任务都有明确的目的、责任人、成果及检验标准的定义；

每个任务的开展都有指导性的描述；

有详细的变更控制机制；

对各类风险有详细的描述和处理建议；

各类中间文档都有模板定义。

总之，从“三边”工程到实施方法论是历史演进的必然，也是ERP项目实施从高风险、不确定态演进到低风险、稳定态的保障。有人说：“领先一步叫先进，领先三步叫先烈。”大约先烈们在做事情的时候是没有方法论的，他们只能靠“三边”的方法，所以大都失败，因此成为先烈。后人只有汲取先烈的经验教训，总结出一种叫方法论的东西，才能提高实施的成功率，降低失败的风险，有机会成为先进。所以，到今天实施ERP项目还蛮干的人，不仅对自己不负责任，而且着实对不起以前的“先烈”！

前车之鉴—“六拍”项目的深度思(1)

说完“三边”再说“六拍”。“六拍”项目给我的印象非常深，用“六拍”对项目实施过程进行总结非常精辟。

第一拍叫拍脑门决策。就是说一个项目的决策过程非常随意，没有量化的投资回报分析，就是凭感觉。感觉项目有前途就上，或者看别人上咱也上。很多项目在决定上马之前，没有投资回报分析，很少考虑其中的困难和风险，一味地想着项目实施成功后的收益。就像前面讲的那位上了EMBA的老总，在课堂上受了刺激就决定要上信息化，虽说这一决策并不能说是错的，但是作决定时多少有点冲动。在上信息化之前，缺少一些结合企业实际的分析和考虑，究竟信息化能带来什么效益，应该先上什么，后上什么，都没有考虑清楚。甚至有的项目的上马并不是效益驱动的，尤其是前几年国家资助的一些项目，反正国家给了一批钱，企业还要配套一笔钱，于是凭感觉赶紧上个项目试试。所以说，很多项目在决策阶段就决定了其注定失败的命运。从第一拍就拍出后遗症，这个项目该不该上？如何上？上哪些？它的投资回报周期有多长？拍脑门拍出来的项目目标一般不清楚，决策者一味地想项目成功美好的一面，所以这是我们典型的“六拍”项目的第一拍，对项目后续的风险和困难估计不足，加大了失败的风险。

既然事情的决策过程是感性的，没有投资效益分析，决策者也不知道该投入多少，在找供应商洽谈价格时，一些决策者心目中甚至认为ERP就是一张光盘，不应该值很多钱的。有一个企业老总曾经跟我讲：“你们那个ERP不就是五元钱一张光盘的成本吗，干吗卖那么贵呢？你卖一万个也是卖，卖一百万个也是卖，你便宜点，多卖几套不就完了吗？”在他们心目中只有一个想法，就是压价。而前几年的ERP供应商对ERP软件的成本也不甚清楚，对实施成功所要付出的工作量也没有明确的概念，在激烈的竞争环境下，面对不是很理性的客户，要拿下订单只有一种选择，就是降价。殊不知，任何东西的价格都是有成本底线的，到成本底线附近，价格每降低一分就意味着失败的风险增大一分。所以，那时候很多项目都陷入了供应商和客户双输的悲惨境地，这是不合理的价格所造成的必然结局。

第二拍叫拍肩膀信任。项目拿下来总是要实施的，供应商的老总也许并不能物色到合适的项目经理，没办法只好拿椽子当檩子来用，选一个并不一定能胜任的员工去硬撑。把他叫来，拍拍肩膀语重心长地说：“小李啊，你是咱们公司最有发展潜力的骨干员工，有技术又肯钻研，这个项目就交给你吧，我相信你能干得非常出色！”一般在项目签约后要开一个隆重的项目启动会，会后，甲方代表、乙方代表甚至监理方代表要一起吃饭。席间难免要多喝几杯酒，几杯酒下肚后，供应商老总就把项目经理小李隆重推荐给客户方的老总，说：“小李是我们公司最优秀的顾问，这个项目交给他没问题。”大约这位老总每次都会给客户这么讲。于是，客户方老总就要给小李敬酒：“小李，这个项目就交给你了，你带领大家好好干，我相信你们的水平。”

前车之鉴—“六拍”项目的深度思(7)

其实这种信任带有很大的盲目性，这种盲目性也是第一拍的后遗症。因为决策者对信息化并不是非常的了解，所以他只能把项目全权托付给他认为了解的人，至于这个人是不是能胜任，老总并没有深入考察，甚至说也没有能力去深入考察。这就是所托非人，授权的人不一定能完成这项工作，更可怕的是授权基本没有跟踪和监督，因为自己不懂，所以授权出去就完事了。这种盲目的信赖更大的危害在于这是一种错误的激励，错误的激励措施激励着错误的行为。

第三拍叫拍胸脯承诺。小李可能以前并没有做过这么大的项目，正在忐忑不安呢，经双方的老总这么一动员，加上喝了几杯酒，就酒壮英雄胆了，隐隐约约觉得自己还是蛮能干的。于是就一身是胆，觉得领导都信任自己，虽然项目有多方面的困难，但还是要大胆尝试，迎难而上。试想一下，如果你是这个项目经理小李，一位刚参加工作不久的大学毕业生，也没有相关的工作经验，突然双方的领导都信任你，给你一个当项目经理的机会，获取了前所未有的信任，你是一个什么样的感觉？

于是，项目经理小李受到领导如此的激励，为了让领导放心，不管前面是万丈深渊还是地雷阵，就豁出来了，一拍胸脯：“请两位老总放心吧，这事包在我身上了。”其实他说这句话的时候，仅凭一腔热情，是缺乏实力依据的。项目经理的承诺缺乏底气和把握，也带有一定的盲目性。所以说，盲目乐观只会使项目在前进的方向上偏离目标越来越远。自此，三拍之后，我相信这位很帅的项目经理，就穿上一双红舞鞋，或者干脆说被推进了焦油坑，接下来的故事怎么演绎，我想大家都很清楚。

第四拍叫拍桌子骂娘。因为没有关注过程，项目经理在项目中的苦苦挣扎双方公司领导都没有觉察，项目演变成什么样子也没人过问。终有一天，有一方领导忽然发现项目进展情况与自己的预期相去甚远，其实领导本来就没有一个清晰的目标，只是心中隐约有一个项目成果的画像。当他突然觉得项目演绎的样子跟他心中的画像大相径庭的时候，就难免要大发雷霆。拍桌子大骂：“你们都在搞什么名堂？这么长时间了，项目搞成这个样子！”我也曾经作为实施方高层参与一个项目的“救火”，客户方的老总就非常不客气地对我讲：“你们的ERP项目实施了这么长时间，你们的实施顾问像《皇帝的新装》里那两个裁缝一样，整天闷在屋子里对着电脑搞来搞去，我都不知道在搞些什么。”这时候，项目组的成员都满腹委屈，因为在这个过程中他们做了很多工作，遇到了前所未有的困难，领导却全然不知，只看到一个不理想的结果。项目经理小李曾经在酒桌上拍胸脯做过承诺，却没料到现在是这样一个尴尬的局面。仔细想来，这种尴尬局面的出现是必然的，从开始就注定了会有老板拍桌子的这一天。

前车之鉴—“六拍”项目的深度思(8)

所以有很多项目经理习惯采取鸵鸟战术，就是隐瞒问题和困难，得过且过，使得问题和困难日复一日地积累，越来越大，等大到爆发的时候已经无可挽回。项目经理曾经为得到老板信任而高兴，却没想到最后换来的却是更大的不信任和批评！项目目标不明确，进度落后，缺乏必要的组织保障和资源支撑，缺乏必要的计划和里程碑，缺乏必要的沟通，没有足够的风险意识都是造成今天这个尴尬局面的因素。老板拍案而起是因为他不了解过程，也是一种鸵鸟战术，还美其名曰“交钥匙工程”。

第五拍叫拍屁股走人。老板的满腔怒火并不能解决问题，结果恐怕会让事情越来越糟。老板不分青红皂白地发脾气、拍桌子，着实拍痛快了，过了把老板瘾，但是作为项目经理和员工，他们也有他们的对策，那就是拍屁股走人。为什么拍屁股走人？现在这个社会，谁也不是包身工，IT行业又这么好找工作，老板不欣赏就走人呗。据了解IT行业尤其是技术人员的跳槽非常频繁，有人甚至一年跳槽好几次，这也是行业的浮躁，IT企业之间互相挖墙角，挖来挖去把薪资水平挖上去了，烂尾工程却越挖越多，把从业人员的心态越挖越糟糕，形成糟糕的人才环境。

受到严厉批评的项目经理小李可能会有两种选择：一是干脆辞职，这个事情没干好失去老板信任，再待下去也没有很好的前途，干脆跳槽到其他单位，重新寻找机会；或者从此消极怠工，把自己的能力收起来，不再当出头鸟，干脆混日子了。

还有一些技术人员，缺乏必要的责任心和使命感，做项目是为了钻研新技术，钻研新技术是为了更好的跳槽，把项目的成败放到次要地位，甚至在项目的最关键时候提出辞职以此要挟老板涨工资。拍屁股走人是项目经理小李最好的选择，因为项目做得一团糟，硬撑下去可能还会有更多更大的困难，还会有更多更大的来自客户和自己老板的责难，但是只要拍屁股辞职走人，所有这一切烦恼都会烟消云散，所有的困难、所有的烦恼就能推得非常干净，就像我们把硬盘格式化了，所有的目录都重建，一切都重头再来，那多轻松。

可怕的是，拍屁股走人会成为习惯，因为拍屁股走人会推掉所有的责任，一下子就脱掉红舞鞋，而且跳槽还可能获得高薪，所以一个动不动就拍屁股走人的项目经理，在新的工作单位遇到困难后还可能拍屁股走人。

第六拍叫拍大腿后悔。五拍之后的项目结果必然令所有人大失所望。项目经理的拍屁股走人使得整个过程中最大的损失者就是我们可怜的老板，他只能拍大腿后悔。这个时候，从决策层到项目经理再到项目组成员，大家都痛心不已，却又无可奈何。双方的老板都会拍着大腿说：“哎呀，早知如此，何必当初！”这就是典型的“六拍”项目。

问题是，“六拍”过后却不吸取教训，在随后的项目又再次重复“六拍”运动……

这个“六拍”运动非常典型，大家可以回顾一下自己前些年做过的项目，那些项目是不是按照这种“六拍”的模式进行的，或者你是不是正在经历着类似的“六拍”项目；或者有的企业曾经经历过这样的一个“六拍”项目，然后成为惊弓之鸟，很长时间不能忘记项目失败的痛苦，从此对ERP敬而远之。

失败归因—IT项目四大败因分析(1)

前些年，ERP项目失败的案例很多，至于为什么失败？究其原因则众说纷纭，这就引来一个问题，叫做ERP项目失败归因。归因是心理学上的说法，就是为事件找原因，错误的归因就会得出错误的结论，错误的归因更容易成为错误的行为导向。比如说，有同学大学四级考试没通过，却归因到眼镜度数不够高，没抄上前排同学的答案，这就是错误的归因。以前大家对ERP项目实施失败存在很多错误的归因，原因找错了，所以后来采取的行动也会是错误的，而错误行动又会使企业信息化沿着错误的方向走得越来越远。人都有一个通病，就是一件事情一旦发生，第一个想法就是逃避责任，寻找客观理由，对自身的不足讳莫如深，其实这就是片面的归因。比如讲实施失败，大多会归因为软件不好操作，成熟度不高，甚至归因为供应商配合不好等等，却很少有归因为客户方自己贯彻不力、投入不够的，即使有，也是轻描淡写。

我想“上ERP是找死”的说法，也在客观上给了很多人一个归因的理由，而且这个理由是一个很好的推卸责任的台阶。有人就讲了，本来上ERP就是找死，于是就轻而易举地找到台阶并就势而下，把所有的责任和过错都抹平了，一切跟没有发生过一样。那些曾经实施ERP失败却又没有找到正确原因的企业，再次上ERP时就产生了疑虑，因为当年归因的那些客观理由还存在，所以就成了惊弓之鸟，不敢决策了。

因此，不管ERP实施的情况如何，希望大家都能有一个正确的归因。正确的归因太重要了，这个归因直接决定企业信息化在后续阶段还能不能健康发展。项目失败或者部分失败，一定要找到失败的真实全面的原因，这样找得的原因才是正确的归因，而不是盲目地讲产品的成熟度，讲业界的大环境不好。甚至于有一些不负责任的记者也在撰写一些错误归因的文章，使得情况越来越糟。

其实从某种意义上来讲，中国从来没有一个失败的ERP。失败的标准是什么？怎么衡量失败？至今还没有一个统一的判断成败的标准。即使在大家公认的失败项目中，也存在成功之处，比如说借助项目锻炼了一批人，为他们灌输了ERP管理的思想和意识，甚至也锻炼出一批懂软件的操作人员。从这个意义上来讲，其实也有成功的一面，至少没有完全失败。

那么，对ERP项目失败的普遍原因能否做一个正确的归因呢？美国Gartner Group公司在2000年发表了有关IT项目的调查结果，该调查把项目失败的原因总结为四大类。

第一类是项目组织原因。包括项目经理是否称职、项目组织构架是否合理、人员是否安排到恰当的位置、是否执行有效的激励制度、是否处理好各方利益以及冲突等等。ERP项目组成员一般都是跨组织的，项目组中既有实施方的实施顾问和项目经理，又有客户自己的各级领导、应用人员和项目经理，甚至还有监理方代表，所有组织成员几乎都是兼职参与项目。鉴于此，有几点需要非常重视：

(1) 组织成员职责明确，每一个任务都要落到实处，每一个人都要对自己分担的工作负责；

(2) 项目组成员之间相互支持，相互信任；

(3) 以客户方为主体，因为他们迟早要独立操作和维护；

(4) 建立组织沟通和协调机制。

失败归因—IT项目四大败因分析(10)

第二类原因是需求缺乏管理。包括需求分析草率、对需求变更的危害认识不足、变更缺乏规范化和必要的流程、普遍缺乏定量指标控制等因素。在ERP实施项目中范围管理很重要，范围不明确，就是目标不明确。没有明确的范围，根本谈不上项目的成功与否，时间和预算也都是空谈。所以需要重视以下几点：

(1) 范围锁定，范围不明确就不能开始实施；

(2) 要充分评估变更对项目各个方面的影响，需求变更甚至要引发合同的变更和项目整体进度与投资的变更；

(3) 需求变更要走严格的流程，变更后要通知到与之所有相关的人，各块作业同时采用变更措施。

第三类原因就是缺乏计划和控制。包括计划以定性代替定量、目标责任制不清、沟通渠道不畅通、缺乏动态跟踪的工具，不能应付变化、无风险储备等。计划的作用虽然不能立竿见影，但没有计划所引起的混乱却显而易见。这里需要注意几点：

(1) 计划的全面周到性；

(2) 计划对变化和风险的预先考虑；

(3) 计划的跟踪和反馈；

(4) 计划的滚动和调整。

最后一类原因就是估算错误。软件本身的复杂性、不同企业还有不同的企业文化和背景，使得对项目的工期很难估算准确。客观上来讲，信息化项目要估算准确非常困难，就算是两个企业买了同样一套软件，上同样的模块，上同样的站点数，实施的周期和难易程度仍然可能差别很大。因为企业文化不一样，有些企业文化非常好，大家做事都积极负责；有些企业的文化不是很好，凡事都是被动应付。如果是后者的话，实施的周期就会延长，失败的风险就会加大；如果是前者的话，实施成功的系数就会增大，而周期也会缩短，这是影响估算的因素。在这里切记以下几点：

(1) 参考同类型项目实施的历史数据；

(2) 运用科学的估算方法和工具；

(3) 充分考虑文化、环境等外围因素；

(4) 工期估算避免外界干扰，有的企业不顾实际状况，预先把完工日期卡死，使得估算失去意义。

对ERP项目的失败分析，当然还有更多的原因分类方法，但是我觉得都能归类到以上四大类之中。

痛定思痛— ERP项目失控的九大原因(1)

前面讲系统论和项目管理，说到项目经理要牢牢抓住项目的控制权。项目失控就如同风筝断线、火车出轨，发展的趋势完全不可预知，是非常可怕的事情。项目失控是项目管理者永远的痛。然而，究竟是哪些原因导致项目失控呢？这个问题很难回答，不幸的项目各有各的不幸。以笔者的经验和直觉而言，以下这些因素虽然不是造成项目失控的全部，但绝对是项目经理需要高度警惕的、最有可能造成项目失控的危险因素。

1. 目标不明，范围不清

目标不明、范围不清的项目永远都不可能实施成功。所以项目一开始就应该把目标和范围界定清楚，否则就不宜开始实施。如果不知道项目要达成什么目标，那最好的办法是索性不干，等目标明确了再干。如实施的软件到底包括哪些功能模块？覆盖到哪些部门和用户？管理层需要哪些报表和信息？这些问题都是范围界定的问题。

目标不明、范围不清在很多人看来是很滑稽的问题，甚至会问，目标都没想清楚为什么还要上？这应该是IT项目比较突出的问题，因为IT项目是无形的，很多时候客户的需求是朦胧的。比如客户看到或听说沃尔玛的信息化很好，能在一小时内实现全球近四千家分店的盘点，自己也心向往之，想借助信息化达到这种目的，这就是他的业务需求。但这个目标太大、太不确定，然而你要让客户把他的需求表达得更具体一点也很困难，他甚至说不出具体需要哪些功能模块。客户往往不能明确表达他的需求是信息化项目最大的特点和难点，所以供应商要不断探索、引导、激发客户的需求。

情形经常是这样的，在项目刚开始的时候目标和范围都是有的，只不过这时目标和范围因为客户对ERP的理解不到位而具有不确定性和局限性。有些时候，实施方的实施顾问试图修正客户理解的这种具有不确定性和局限性的需求，却因为客户那种防范供应商投机取巧的心理而拒绝接受实施顾问的建议。但随着项目的进行，客户在实施的过程中有了对ERP的全面体验和直接的感受，他的需求才真正得到激发。于是，就强烈要求范围变更和目标再定义，在原来范围的基础上增加很多功能，范围不断扩大。而且，往往以客户就是上帝的有利地位逼迫供应商无条件答应，甚至工期还不能拖延。这就造成一个很大的矛盾，范围扩大，甚至目标改变，而投资不能追加，工期不能拖延，这样的项目不失控才怪。很多IT项目失败就是因为陷入了这个需求的怪圈。

痛定思痛— ERP项目失控的九大原因(2)

我想应该从三个方面入手来化解这个矛盾。

首先，客户要在签约前尽可能深入了解供应商以及软件的功能，甚至多考察一些案例，我曾经提出过项目选型的“五实”模型(实力、实例、实际、实践和实施)。事前多了解一些，定位就更精准一些。

其次，实施方的顾问还要作出努力，尽量引导客户的需求，甚至激发客户的需求，尤其是核心需求。这就像盖房子必须要有洗手间一样，不管客户有没有明确提出，有洗手间都是核心需求，客户没有提出，顾问就要引导。有的顾问为了减少工作，对客户没有明确提出的核心需求也装聋作哑，敷衍搪塞。殊不知，这种需求迟早是要实现的，等到客户省悟过来再去实现，就会造成很大的被动。

第三，就是双方都要作出努力，范围是项目的自变量，投资、工期是因变量。范围改变，投资和工期不改变是违反客观规律的自欺欺人的做法。所以，范围和目标的小范围变更是难免的，问题是和这种变更相配套的投资追加、工期延长也需要跟上，这需要双方都作出让步，共同实现目标。这一点很多客户不理解，误以为强压供应商实现额外的需求是一种胜利，遗憾的是，使用这种手段的结果往往会导致项目失败并造成巨大损失，ISO9000标准中提出的八大质量管理原则很重要的一条就是与供应方互利的原则。有人讲，把ERP卖贵了是欺骗客户，把ERP卖便宜是更阴险、更潜在的欺骗客户。因为，当供应商的收益不足以支撑他实施好该项目应有的投入时，就会徒增项目失败的风险。

2. 实施策略错误

实施策略的失误是一种方法论上的错误，常见的有以下几种类型。

贪大求全：总想一步到位，摊子铺得太大，顾此失彼，结果到不了位。

先难后易：没有采纳先易后难、循序渐进的原则，一上来就打攻坚战。比如有人选择先实施BOM，觉得这是最关键的。但问题是，实施BOM所需要的很多基础数据是要从其他模块中来，这些基础模块不到位，实施BOM就很困难，所以还要遵循ERP123的原则，退回到基础的进销存管理。如果一上来就试图解决难题，就会碰钉子，受打击，进而丧失了信心，没积累到经验反倒积累了教训，这种惨痛的教训会让你害怕ERP，远离ERP。

缺乏统筹：工作安排缺乏统筹，前后衔接有问题。有的项目做了一半进行不下去了，原因是前一道更紧急的工序没做完，后面只能停工等待了。这种缺乏统筹安排的策略失误也经常会导致一个项目的失控，至少也会导致工期的拖延。

痛定思痛— ERP项目失控的九大原因(3)

估计的错误：对项目工作量估算不足，没有留有余地，经不起节外生枝，某一环节耽误引起连锁反应，延误整个工期。

盲目赶工：快并不总比慢好。我非常反感有一些项目盲目赶进度，应付上级检查的做法。这些项目后墙不倒，一定要赶到某一天验收，所以就盲目地赶工。有时候慢反而把握大一点，一味地追求速度，难免会因为速度而忽视质量。然而，欲速则不达，等发现质量问题的时候再返回来，就会造成项目失控。

3. 过程监控不力

有的企业领导人把一把手工程做成大撒手工程、交钥匙工程。他们想：反正我又不懂，就交给懂的人去干，到时候你给我一个结果就行了。这种大撒手的做法实际上是一种不负责任的授权，是项目管理的大忌。因为从项目开始到产生结果是一个很长的中间过程，这过程中有太多的岔道和歧路，所以，过程监控的作用就是及时把项目从岔道和歧路上拽回来，使其重新走向正轨。如果缺乏这个环节，那么，当企业领导发现项目走向歧途的时候就为时已晚，无能为力了，项目已经陷入失控状态。

所以，企业高层对项目阶段性的评审非常重要。高层哪怕对ERP不懂，也要经常过问。同样，项目组也要阶段性地主动向高层汇报项目进展状况，让他们了解每一步，知其然，也知其所以然。如果高层不知其所以然，他们就可能是一个定时炸弹，不知道哪天可能会因为项目结果与其所预期的强烈反差而暴跳如雷，拍案而起。

过程评审是最常见的过程监控手段，目的是阶段性地检查项目是不是偏离了目标，过程的中间结果和预期有什么差异，如果出现差异需要通过什么样的手段来纠正和弥补。因为IT项目的中间结果是无形的，所以只有具备专业知识的专家才能对中间结果给予恰当的评价，这就给阶段评审带来一定的难度。

阶段评审不力的后遗症就是容易把错误的东西投入复制。一旦错误的方案被实施发布，再修复的代价就会很高。一个有潜在问题的东西，你复制得越多，潜在的危险就越多，纠正或修复的成本就越大。微软的Windows设计缺陷导致冲击波病毒，为修复这个缺陷，微软要付出很大的代价。经常看到某款汽车因设计缺陷被厂家招回，这个招回的成本也是高得惊人的。所以，把有缺陷的方案投入复制，会导致项目的运行处于不可控的发散状态，是非常危险的。

痛定思痛— ERP项目失控的九大原因(4)

4. 逃避问题，鸵鸟战术

鸵鸟战术我也强调过多次，项目成员或项目经理因为担心受批评或责难，就把问题藏着掖着，等到实在兜不住的时候爆发出来，就错过了解决问题的最好时机，甚至造成了不可挽回的损失，严重的会导致项目失控。有很多项目经理采取息事宁人、和稀泥的绥靖政策，过分讲求和谐，总在粉饰一团和气的太平景象。对项目中暴露出来的问题，因为怕得罪人、怕受指责而视而不见，使得问题如雪球般越滚越大，越积累越严重，到了爆发的时候就一发不可收拾。

比如，项目进行的关键时刻需要高层领导出面推动或作出决策，项目经理总是找不到领导，或者怕耽误领导更重要的工作，把事情一拖再拖，使得整个项目组处于低效率的待命状态，使项目推动不力。所以，有问题及时暴露，有矛盾及时化解，敢于直面困难，迎难而上是项目经理必备的品质。

5. 畏惧变革

我说过，ERP项目实施常常伴随着企业的管理变革。害怕变革是人的共性，从心理学的角度讲，人们对自己所不熟悉的领域天生存在一种防御心理和畏惧心理。这种心理就使得一些人在ERP实施过程中缩手缩脚、踯躅不前。常见的表现有以下几种。

经验主义：一味地让产品适应企业，甚至完全定制。举一个例子，我曾经参与过一个实施用友EHR的项目，在上系统前，他们的考勤管理是每个月要把所有人的出勤情况打一张表，然后各业务部门经理在表上签字，最后依据这张表核算工资。

上了EHR之后，每个人的每次外出都要在EHR系统中走电子流审批，审批之后就会在电脑里形成记录，这样月底领导在表上签字的环节就可以省略了。因为所有的请假、外出都逐一经过了电子流审批，月底打印出来就行了。可这么一来，企业的领导接受不了，他必须要产品客户化，开发一个能让他签字的考勤表，他签完字才算有效，要不，你这产品就不适合我们企业。后来，我给他解释说，每一次考勤事件的发生，都经过了你的审批，这最后的结果无非就是每一笔审批过的记录汇总，你为什么还要再签字呢？他恍然大悟。这就是经验主义，因为企业在上ERP之前一直是这么运作的，对ERP有一个适应过程，客户要根据需要变革以前的制度。就像陈启申先生讲的：习以为常的事情不一定是合理的事情。事实上，企业很多环节在信息化以后是可以改变和优化的，而且跟手工处理相比，也不失严谨性，还更加快捷。

痛定思痛— ERP项目失控的九大原因(5)

打退堂鼓：受一点挫折，就怀疑产品不合适，把责任全部推托到软件身上，说软件不好用是掩饰自己不努力学习、打心里排斥ERP的最好借口。操作人员以此为借口给自己不上ERP找台阶下，而这个台阶是轻易不能下的，因为这是一种错误的归因，认为ERP产品不合适，换一个供应商的产品还是不合适，问题的本质在于畏惧变革。

保守的企业文化：一些企业文化过于保守，也会影响ERP项目的成功实施。接受新事物的态度和能力是相辅相成的，态度端正，能力迟早会锻炼出来，态度不端正，自然不会投入时间锻炼，也就谈不上能力提不提高了。用户缺乏创新精神，接受新事物阻力很大，失败的风险也很大。

6. 组织不实，纪律涣散

项目的实施一定要有组织保障，有两个因素会使得ERP实施项目很容易造成组织不实和纪律涣散。一方面，项目组是跨组织的，企业方和实施方之间的约束关系是较松散的合作关系，谁也不好命令谁；另一方面，项目实施是阶段性、一次性的任务，不管是企业方还是实施方的成员都是兼职参与项目，他们本身还有其他的工作在做。

造成组织不实的主要因素如下。

用人不当：所托非人。如果项目经理不具备应有的素质，就很容易出现整个项目推进把握不住要领，工作落不到实处，或逃避责任等情况；关键用户不熟悉业务也可能影响调研、方案和后期维护；实施顾问对产品的把握程度或对企业的理解程度会影响方案的质量；等等。

人手不足：人人都负责，人人都不负责。有时候看起来人挺多，但实际上很多人是靠不住的。既然大家都是兼职做项目，每个人都很容易忙自己的事情，那么项目就落不到实处，工作没有执行力度，项目经理就只能坐等时间一天天流失，等着有一天老板的拍桌子臭骂。

其他资源如硬件、网络等障碍：比如硬件迟迟不能到位，缺乏最基本的基础数据等。这实际上也是组织方面的原因。

组织纪律涣散会导致项目失控。没有组织纪律的项目组是一群乌合之众，尤其是这种跨组织的、多数人兼职参与的项目，如果没有一个强有力的组织纪律保障，整个项目失败的风险就非常大。

举例来说，项目组没有一个严肃的纪律来保证执行力，每一个人对项目的承诺不能按时兑现，每次例会，大家都不能按时完成上周的工作。这时，如果项目经理仍没有措施，一味采用鸵鸟战术，这种不及时完成任务也无所谓的作风将形成一种文化。一旦项目组里存在这样一种文化，项目的执行力就会大打折扣，可以预见，项目几乎处于半失控状态。

痛定思痛— ERP项目失控的九大原因(6)

7. 数据错误

数据错误对项目的影响是在项目前期不易觉察的，等到问题爆发的时候又常常使项目团队措手不及。信息系统就是把快捷网络技术和现代化的管理手段结合起来实现企业内部管控和各块业务数据的共享，从而提高企业业务的运转效率。但是有一点绝对不能忽视，这种网络技术也同时能够使错误的信息被迅速传播，如果企业以错误信息为依据所作出的决策也必然是错误的。正如陈启申先生所讲：垃圾数据得出的结论也是垃圾，数据错误可能使得企业因上ERP系统而犯更大的错误，蒙受更大的损失。

在ERP系统中，一旦出现账实不符，ERP就变成了数字游戏，一点应用的价值都没有。而且，一旦发现数据错误，要找原因就像大海捞针一样，非常困难，你会发现找数据错误的时间比整理基础数据的时间还要长，投入的精力还要大。如果项目陷入不断整理与核对基础数据的漩涡中，正常的进度安排就会受到很大的影响。我见过一个企业把他们的BOM清单理过七遍，试想，面对几十种产品和几十年的数据资料，整理七遍的工作量有多大？所要投入的工作量和时间足以把一个项目组搞崩溃。所以，数据正确非常重要。

数据错误所造成的返工与核查在项目实施中是一项预料之外的工作。所以，项目组一定要严密组织、严格要求，争取一次性把数据整理好。

8. 内部斗争

内部权力斗争有时候对ERP实施项目的影响是致命的。因为ERP实施过程不可避免地涉及权力再分配，透明化的管理也有可能触动一些人的既得利益。于是，很多企业通常会借助ERP项目来进行内部管理的变革和权力的再分配，这一点往往是企业高管层希望看到的效果，同时也是需要慎之又慎的工作。

在这个过程中，往往会出现项目组成员都不希望看到、也不能控制的情景，甚至把双方的项目经理都逼到进退两难、不知所措的境地。更严重的是借题发挥，借ERP来搞内部斗争，这也是不好的现象。

9. 外部风险

外部风险有时候是不可抗力，影响项目的因素有政治的、社会的、经济的、技术的等诸多方面的因素，有些情况的发生甚至意味着项目叫停。比如说，项目实施过程中，出现企业被另外一个财团收购的情形。在新的形势下，控股的财团在管理上可能有新的要求，或者迫使企业上另外一套软件。还有，因为政策等外界因素的影响，一些原本政府支持的项目资金不能到位，导致项目难以为继。这一点，在本书第3章的“项目管理中的放弃艺术”一文中将有相关的论述。

所以，做项目还要时刻关注外部情况发生了哪些变化，并时刻分析这些变化对项目有什么影响以及这些影响意味着什么。

斗转星移—信息系统在管理中地位变迁(1)

追溯起来，国内企业的信息系统建设早在20世纪90年代初就开始了。最初几年，政府推动力度很大，政府给企业很大的资金支持和其他帮助。遗憾的是，当时上ERP系统的企业几乎没有几个成功的，这从某种意义上来讲也是一种必然。总结其原因，不外乎三点：其一，当时的ERP根本不考虑企业管理实际，拿一套理想的MRPII模型生搬硬套，当时企业管理的实际水平远远达不到MRP所定义的那种标准，管理基础太差；其二，当时信息化管理的群众基础太差，20世纪90年代初期，在企业中会操作电脑的人都不多，即使企业上了ERP系统，其使用者也仅仅局限于少数几个懂电脑的专业人才，而日常开展业务的绝大部分人不具备电脑的基础知识，更何况操作ERP软件；其三，囿于企业领导的认识水平，企业实际的重视程度是不够的，信息技术部门在企业中的地位和行政人事一样，属于从属部门、二线部门，信息系统根本没有得到企业领导层在战略层面的重视。这些情况在当时都是实实在在的环境和历史背景，信息系统失败怨不得任何一位个人，只能一句话概括：条件不具备。

再后来，情况好了一些。首先是国产ERP软件的崛起，把企业上ERP软件的总体成本大大降低，ERP从中小企业开始做起，产品的成熟度和灵活性相对得到了很好的改善；其次，Windows和互联网的普及，使电脑在中国和电视一样，成为每个家庭必备的家电，更何况铺天盖地的网吧也对电脑基础操作的普及起了很大的推动作用，人员基础差的问题自然解决；第三，企业自身的管理水平在提高，软件的功能和成熟度也在提高，企业领导层的认识水平在提高，上ERP不再是一哄而上，而是先从最基础的管理模块做起，步步为营，渐入佳境。这个阶段，国内ERP厂商、政府和高等院校都在ERP理念普及、ERP推广和宣传上下了很大的工夫，付出了很多的心血。一些勇于创新的企业和在激烈竞争下求生存和发展的企业率先一步上ERP，在经历了漫长的艰苦奋斗过程之后，开始尝到了甜头。也非常感谢这些企业的模范带头作用，它们给同类的企业做了很好的示范，通过这些企业的项目，ERP厂商也锻炼了一批专业的顾问。

斗转星移—信息系统在管理中地位变迁(2)

2005年，用友软件不失时机地提出ERP普及的口号，全面推动ERP在企业中的普及，同时推出适合中小企业的普及版。普及版的特点是价格低，功能标准，易实施。再后来，干脆有了适合更小企业的通序列产品，定位是小型成长性企业的ERP软件。于是，ERP彻底揭去以前蒙在脸上那层神秘的面纱，放下高贵的架子，“旧时王谢堂前燕，飞入寻常百姓家”。与此同时，此类ERP的销售也不再是顾问式销售，其交付也多半是培训交付。到了现在，几乎可以这样讲，简单的ERP系统(其实这里的ERP是代名词，更多的企业就上财务、采购、库存、销售等基本模块)已经成为一个企业的必备品了，就像电脑成为家用电器的必需品一样。

最近两年，我深入广大企业，有了更深刻的体会和认识。有一家外资企业投资了一个水泥厂，在整个水泥厂还没有正式投产之前，他们首先进行ERP系统的选型，该厂CIO告诉我：办厂最首要的工作是有厂房、设备和信息系统。把信息系统和厂房、设备摆在同等重要的位置简直让人惊讶，可是仔细一想，却非常在理。他们说：“一个企业首先要考虑的是它的控制神经系统。就像一个人，最重要的是大脑和神经中枢，ERP就是企业的神经系统，上传下达，信息集中和分发是最重要的。”

所以，有时候想，在一个还没有完全投产的企业实施ERP比在一个经营了很多年的企业上ERP要容易很多，而一投产就用了ERP系统的企业，以后的扩张、并购也会容易一些。相对应的，因为信息系统被摆在企业战略支持的重要位置上，自然信息技术部门在企业中的地位得到很大的提升。我认识很多企业的高管都是因为在信息系统建设上作出卓越的贡献而得到晋升。真是斗转星移，信息部门已经彻底从幕后走向前台。

更让人欣慰的是，企业对信息系统的实施有了更好的认识。归根结底，ERP的实施过程是一个服务过程，企业上ERP就像我们去驾校学开车，学生上英语班学语言一样，是一个类似的教学过程。企业买的是一系列服务，而不是软件本身。软件再好实施不起来也发挥不了作用，软件不算太好，实施起来，在企业管理中发挥了作用也算是物有所值。有远见的企业已经开始这么看问题：首先是找咨询公司为其做战略或者企业流程优化咨询，把ERP当做咨询结果固化的工具。

信息化在企业中地位变迁的过程反映了企业管理发展的轨迹，也揭示了在国际化和信息化两大背景下，未来企业发展的必然趋势。社会发展了，就像有了电子邮件和电话后人们不再愿意写纸质信件一样，企业信息系统从一个新生事物发展到今天的企业管理必备工具也是必然的发展趋势，没有人能够阻挡，谁阻挡就会把谁甩在历史潮流的后面。

数字说话—— 效益才是硬道理(1)

ERP项目的经济效益分析是一个难题。无论是在上ERP之前的投资回报分析环节，还是在之后的项目总结环节，谈论ERP的经济效益，可能还是片面的、拍脑门、凭感觉的定性分析居多，全面的、科学的定量分析居少。甚至有人讲，信息化项目是根本没办法衡量经济效益的，反正大家都信息化，不信息化就落后，落后了就要挨打，所以要信息化。我想，导致信息化项目经济效益分析困难的因素大概有两点：一是信息化的目标没有与企业的战略结合起来；二是信息化缺乏进行经济效益分析的有效方法和思路。下文试图在这方面做一些探讨，以期理清ERP项目经济效益分析的思路。

1. 从问题入手

很多企业根本找不到自身存在的问题，自然就找不到上信息化的理由。那么，要回答企业为什么上信息化，我的建议是从找企业存在的问题入手，并分析这些问题带来的牵连影响，然后再看如果借助信息化的手段能够解决哪些问题、消除哪些牵连影响，这就是信息化的意义。

(1) ERP项目联结企业战略目标

很多ERP项目的经济效益无法衡量的原因可以追溯到企业战略目标不清楚或无法衡量。根据迈克尔·波特的战略理论，企业的战略可以分为三种类型。

产品领先型：将公司提供的产品或服务差异化，树立起一些全产业范围中具有独特性的产品品牌，比如英特尔、索尼就是此类公司。

流程卓越型：优化内部流程，建立高效的、规模化的生产设施，全力以赴降低成本，严格控制费用，确保总成本低于竞争对手，比如沃尔玛、DELL就是这样的公司。

客户亲密型：主攻某个特殊的顾客群，能够以较高的效率、更好的效果为某一狭窄的战略对象服务，从而超过较广范围内的竞争对手，比如IBM就把客户目标群锁定在高端客户上。

企业的战略不同，其在市场、销售、研发、生产、供应、人力资源甚至财务上的策略就不同，而包括信息化在内的所有项目投资都应该服从并服务于企业战略目标的达成。所以，有清晰的战略目标是信息化的第一步，沃尔玛的战略意图是让普通百姓买到有钱人用的东西。它就致力于通过优化内部流程，减少商品流通的中间环节，从而给消费者以最大的实惠，使信息化为它的这个战略目标服务。今天，沃尔玛有自己的通讯卫星，一小时内能实现全球4000家分店的盘点，这些都是借助现代信息化的手段实现的。

数字说话—— 效益才是硬道理(2)

(2) 目标的关键成功要素

企业战略目标清晰了之后，各项业务的策略也就清楚了。具体而言，企业的战略目标要逐层分解为若干个关键任务，称之为关键成功要素(Critical Success Factors，CSF)。CSF是指企业为了达成业务目标，必须要做成功、不容失败的事项，是目标达成的充分必要条件。企业要达到某项目标，就必须具备某几个关键成功要素，反过来，如果具备了某几个关键成功要素，达成目标是一种必然。

比如说，传统制造业的关键成功要素可以这样概括：

识别新的市场及产品需求；

掌握竞争对手状况；

树立品牌；

改进市场营销及企业服务的支持；

减少新产品的开发时间；

发展供应链中上下游关系；

更新生产流程；

降低成本；

控制产能；

降低物流成本；

维护设备的正常运行；

保证质量，降低维护成本；

保证产品及工作环境的安全。

这些CSF是从市场、研发、生产、供应、服务等产品形成的价值链角度概括的，是构成企业战略目标的充分必要条件。

数字说话—— 效益才是硬道理(3)

(3) 关键成功要素的障碍和问题

关键成功要素是在未来时间要完成的关键工作。接下来的任务就是找出这些关键成功要素的障碍和问题，列举出阻碍我们达成CSF的种种现状。例如，过时的手工记录和电话沟通方式是不及时的信息传递方式的障碍之一。这些障碍被去除后，企业应该可以顺利地完成计划目标。为了搞清楚有什么样的困难和问题阻碍CSF的实施，管理者要回答以下问题：

过去的困难、问题是哪些？

及时反馈销售的状况对你是否重要？

物流和分配是否畅通？

成本的结构是否清楚？

新产品的推广是否顺利？

客户的需求是否明确？

未来的困难、问题会不同吗？有哪些不同？

(4) 障碍的牵连影响

更深一步的分析是找出这些障碍的牵连影响，牵连影响的意思是说，如果障碍不去除，它还会有哪些牵连的负面影响。例如，不及时的信息传递方式的牵连影响是：给客户的服务不及时、发现问题不及时、生产周期长、返工多等。

于是，我们又可以针对每一个障碍来深究它是如何在其他方面牵连影响公司业务的？试从以下方面寻找牵连影响：

这些障碍会不会需要增加库存？

机器设备是否因此而停工？

会不会影响交货期？

成本会不会增加？

是否会影响企业的某些认证资格或执照？

客户的满意度或忠诚度是否会被影响？

数字说话—— 效益才是硬道理(4)

2. 寻找解决方案

(1) 解决方案

基于以上分析，我们可以找出一个发现问题的逻辑链环。它们是：确立企业战略目标；分解实现战略目标的关键成功要素；找出制约关键成功要素实现的问题和障碍；挖出这些问题和障碍。这样，企业就大致能够把自己要解决的问题罗列出来。

现实一点讲，这些问题并不能一夜之间全部解决，企业经营管理过程就是不断发现问题和解决问题的过程，所以这些问题要分轻重缓急，分为紧急重要的、重要不紧急的、紧急不重要的等几个级别。

当然，这些问题有部分是可以借助信息系统来解决的，信息化的解决方案正是从这些可以借助信息化解决的问题入手，这里的问题便转化成信息化的需求，也就是：疼痛和憧憬构成的需求。

所以，信息化的解决方案一般从需求分析开始，导出项目的目标。这些目标一般跟各块业务有紧密的结合，再提出这些目标的针对性解决方案，形成企业信息化的整体规划，必要的话，再把项目规划成几个步骤，分步实施。

(2) 3P模型

以字母P开头的英文单词很多，所以营销上有4P、6P的说法。在这里，我们介绍一种3P模型，这个模型描述问题、解决方案和企业投资额三者之间的关系。

首先是Problem，企业存在的困难、问题及其牵连影响，也就是第一步所锁定的问题；其次是Proposal，解决方案，具体阐述ERP是如何解决企业存在的这些问题的，以及解决这些问题能给企业带来哪些效益；第三个P是Price，也就是企业的投资额。这3个P之间存在着一种联动关系：企业存在并发现的问题越多、越严重，如果ERP能解决这些问题的话，则解决方案的价值越大，自然，企业愿意投入的项目费用也会越大；相反，企业存在的问题越少，解决方案的价值就越小，客户愿意投入的费用也会越小，它们之间的关系如图1-1所示。

谋定后动— 信息化规划势在必行(1)

项目为什么要规划？这个问题很有意思，因为人们并不是天生就懂得规划，而是在现实中吃了很多苦头之后，才知道凡事需要提前规划。比如说城市规划，以前很多城市都是在盲目发展，之后才发现路窄了、管道没铺好、供电设计有问题等。所以，规划并不是人类与生俱来的本领，而是在经历了若干痛苦之后，才想到要这样做。

记得三年前，我拜访一家半垄断行业客户，主管信息化的张总讲：“我们企业什么都缺，就是不缺钱。每年都要投入大量的资金给各个科室添加很多硬件和网络设备，但是各个科室都只建设自己的信息系统，之后各科室之间产生信息孤岛。我为这件事情深感头疼，如果没有统一规划的话，就会迅速蔓延，这样盲目蔓延下去，将来再整合的难度就会更大。可即便现在让我去整合，也是一件难度很大的事情。例如，现在我都不知道各个科室到底有多少台机器，装了多少个应用软件？”他接着说：“现在我们单位的信息化发展到一个两难的地步—— 整合工作量巨大，可不整合的话，蔓延下去将来会更难。”这就是一个没有规划盲目蔓延的例子。

另外还有一种类型，是贪大求全。例如，曾经有一家企业，在ERP选型中，凡是ERP领域里所涉及的应用软件，如MRP、SCM、CRM、CAPP、HR等，统统都上。然后还把价格压得非常低，总体投入就80万，但可悲的是，在那个恶性竞争的年代，就有供应商签单。结果这个项目的命运可想而知。这类项目，在还没有签约的时候它已经失败了，不管你派多强的项目经理来执行，它的命运都是一样的。

基于以上考虑，信息化必须有一个较完整的规划，也就是要有一个蓝图。这里，我们可以把项目规划分为五大步骤，如图2-1所示。

第一步叫做联结战略。信息系统是为实现战略目标而服务的，孰重孰轻，孰先孰后，与企业的战略定位关系很大。比如对商业企业来讲，CRM很重要，但是对一个简单的零件加工或者配套品加工的企业来讲，CRM就不是很重要，因为它的客户是相对固定的，比如给丰田汽车提供零配件，客户是少数固定的几个。对它们来讲，CRM就不是那么重要，而生产计划管理、车间管理、成本管理对它们就非常重要了。所以，企业战略定位不同、战略不同，竞争策略不一样，信息化的侧重点也应不一样。不同战略类型的企业(如客户亲密型、技术领先型、流程卓越型)，信息化的侧重点都各不相同。

谋定后动— 信息化规划势在必行(2)

第二步叫做立足现状。这里的现状包括企业网络环境的实际情况、企业的人员储备状况、IT人员的素质状况等等。企业有什么样的信息化基础，以及企业允许投资信息化的资金状况，都需要考虑。立足现状的规划，才更具可行性，更能落到实处。

第三步叫做分析需求。企业要对自身的需求进行全面的分析，要了解自身哪一块需要信息化、如何信息化、什么时候信息化、要信息化到什么程度等问题，有的信息化需求是核心需求，如果不实现，一些战略就无法落实；有的需求则是镀金需求，可有可无。

第四步叫做确立蓝图。需求分析之后应该能够确立一个企业信息化的蓝图，这张蓝图就像一张图纸，描述出两三年后企业的信息化大概是什么样子。为了便于观察，在这张蓝图上可以把今年要实现的涂成绿色，明年要实现的涂成黄色，后年要实现的涂成紫色等等。

最后一步是确定顺序。确立顺序也很关键，因为信息化失败的风险之一就是实施策略上的风险。有的企业错误地采用了先难后易的策略，认为BOM是最重要的，一上来就从BOM做起，结果一实施就碰到钉子。因为实施BOM的很多基础的工作没有做起来，在没有积累实施的经验之前，先得到的是失败的教训。之后，全厂上下对信息化的认识发生了偏差，这是一种非常危险的途径。一般来讲，通过两个维度来共同确定实施的顺序是比较科学的：一个维度是难易程度，另一个维度是实施效果。一般而言，第一优先实施的应该是实施起来容易的，见效又快又明显的应用；第二优先实施的是对企业运行效率有明显提升，但实施有一定难度的应用；那么第三优先实施的就是容易实施，但见效不是很大的应用；第四优先实施的则是实施有难度，见效也不快的应用。曾经有老总对我讲：“我现在特别想实施车间管理，我想一步到位就做车间管理。”我就问他：“你实施车间管理想要达到什么效果？车间作业数据第一时间录入到你的系统，对你来讲又有多大的作用？能不能提高生产线的效率？”事实上，这两者之间没有必然的联系，因为这里有一个明显的道理：越控制到神经末梢，可提升的空间越小，在中枢神经还没有控制好的时候，过分强调控制末端神经是没有意义的。所以管理者要做的是，首先管控住主要结构，然后再逐步实现精细化管理，事物发展本来就要符合这个自上而下、从粗到细的规律。

错落有致—集团企业信息化规划原则(1)

大型集团企业的信息化规划是令企业CIO比较头疼的事情。原因有二：一是很难把错综复杂的业务关系理顺，把犬齿交错的多个应用有机地整合起来；二是CIO不知道哪些事情该抓，哪些事情该放，抓多了管不过来，抓少了又怕失控。这两个问题在多业态、多元化经营的集团企业中表现尤为突出。最近参与了几个大型集团企业的信息化规划，在集团企业信息化的统筹整合、分层分级上有一点体会，我想可以作为集团企业信息化规划的一般原则供大家参考。

一个大型集团企业，其内部的信息系统通常会有几十个甚至上百个。没有一个企业的信息部门有这么大的能力和精力承担这么多系统的设计、建设和维护的浩繁工作，而企业的规模和管理需要决定了这些应用又一个都不能少，这个矛盾该如何解决呢？有的企业制订了“统一规划、统一标准、分级负责、分步实施”的原则，把信息系统分级分层、有机地整合起来。如何分级分层呢？我认为，集团企业的信息系统可以分为四个大类：全局应用、垂直应用、局部应用和水平应用。不同大类的责任主体不同，总部信息中心对其管控审查的力度也不同。

1. 全局应用

全局应用是指集团下属所有成员企业都必须使用的，属于企业级的信息系统。比如企业门户、企业协同办公平台、多媒体会议系统、线上学习系统、网络安全系统等。集团内各个成员企业共享其资源和信息，在这些平台上协同工作，这些应用一旦发生故障，将会影响整个集团范围内的正常工作和通信，所以对其安全性、可靠性要求最高。

这类应用必须由集团总部信息部门集中规划、建设和维护，各成员企业不能另行建设，必须遵循全局应用的使用要求和管理制度。

2. 垂直应用

集团总部设有专门归口管理部门，而业务管理垂直渗透到所有成员企业相应部门的业务，如集团财务部垂直管理各个成员企业的财务部，集团人力资源管理垂直管理各个成员企业的人力资源部，类似的还有集团资产管理、集团预算管理等，这类业务的管理信息系统称之为垂直应用。很多大型集团企业实行矩阵式管理，垂直应用就是满足矩阵式管理中垂直管理业务线对成员企业约束和管理需求的一类应用。这类应用一旦发生故障，集团企业某一方面的数据就集中不起来，影响某一块业务的正常管理，所以对其安全性、可靠性要求也比较高。

这类应用由集团总部相关业务归口管理部门牵头，总部信息中心配合进行规划、建设和维护，下属企业的相应业务部门和信息中心自然也要参与和配合。各个成员企业要做到以下几点：

错落有致—集团企业信息化规划原则(2)

按照总部垂直业务部门管理要求使用和汇报某些信息；

可以根据企业自身的管理需要，在垂直管理应用的基础上扩展某些应用；

保持企业自身局部应用系统和垂直管理系统的数据一致性(最好有数据自动传输接口)。

3. 局部应用

局部应用属于各成员企业内部业务开展和管理需要的信息系统。在集团企业中，各个成员企业可能因为业务模式不同，管控的重点不同，只能根据业务需求进行个性化建设。比如有的多元化企业，商场业务需要商业POS系统、餐饮服务业务需要餐饮管理系统、房地产开发业务需要项目管理等。这类应用只对局部业务开展和管控有影响，和具体业务的结合很紧密，因而要求建设者应具备专业知识，供应商必须是专业领域应用软件的提供商。集团总部既没有精力，也没有能力来管理这些项目。

一般说来，总部信息部门对这些信息系统的管控应该做到：

审批和监督其规划、建设过程，重点监察专项资金的应用状况；

要求专业业务系统根据管理需要提供对外数据接口，以便集团总部采集相关数据；

要求成员企业提供业内专业人士对其系统可行性的评价和应用效果鉴定等；

如果此类应用要使用公共信息资源(如网络、存储设备等)，则需要监控其对公共资源的消耗状况和安全性的影响。

4. 水平应用

水平应用是指那些专业性不强、应用面很广、价值不大的通用性应用软件，比如各个成员企业都要使用的数据库系统、操作系统、办公软件、CAD绘图软件等。总部信息部门对这些应用软件的管控应该做到以下几点：

集团信息部门统一品牌、版本或供应商，以方便集团内部电子文档的相互传递和阅读；

由成员企业申报采购计划，集团信息部门根据计划统一组织采购，以发挥集团采购优势，降低采购成本；

统一版本升级。

如果集团企业的信息中心遵循以上这些原则，对纷杂的信息系统按类管理，便能够在集团企业信息化管理上做到“管而不死，放而不乱”。

掌握规律— ERP实施项目的六大特点(1)

我最近的两次演讲中都谈到ERP实施项目的特点，一次是在6月10日西安交通大学软件学院的专题报告中，另一次是在西安高科理化的项目启动会上。我想ERP实施项目实际上是在项目的前面加了一个“ERP实施”的定语，所以要找寻其特点也必然从这一定语入手。其中“ERP”三个字母决定了此类项目需要和企业业务实际结合紧密，“实施”二字又唤醒人们对IT项目共性的思考。

归纳起来，ERP实施项目有六大特点。

1. 目标柔韧

IT项目最大的特点就是其需求规格不容易完整确切地表述。不像盖大楼，所有的东西事先都有确切的设计图纸；也不像机械加工，螺钉、螺母的规格都有很好的约定和国家标准，事先还会有非常具体的设计，完工后又有非常好的验收标准，甲方乙方有共同的约定可遵循。而IT项目则不同，其目标的柔性很大，项目的范围不容易界定，用户所理解的ERP系统实施成功的标准和供应商所理解的标准往往有很大的出入。这是因为：第一，用户经常受到经验和专业能力的限制，很难确切地、完整地表达自己的需求，换句话说，客户往往不知道自己想要什么；第二，ERP项目实施过程本质上是一种服务过程，实施顾问给客户提供的是服务，而客户得到的则是一种体验，客户体验的感受成为对供应商实施顾问服务的一种客观评价，这个评价中掺杂着很大的感性成分和个性成分。比如说，关于产品易用性的评价，客户学会了，操作熟练了，他可能就说好用；客户没学会，操作别扭，他可能就说不好用。这个案例告诉我们，软件的易用性在很大程度上存在感性成分，但扎实的客户培训能够有效地弥补软件设计上的易用性曲线。

目标柔韧对所有项目管理者来讲都是很头疼的事情。所以，这类项目要实施成功，项目经理就要更加注重除满足软件固有功能之外的影响—— 客户评价的因素，这个因素有时候会起到决定性作用。业内有一个不争的事实：软件产品很难做到无懈可击，客户只要存心找茬，总是能找出来的，可见，目标柔韧这个固有的特性本身是造成很多软件项目失败的原因。

2. 综合性强

IT行业具有很强的渗透性和带动作用，是国民经济发展的带动力量。所以，国务院机构改革把信息产业部归并为工业与信息化部。信息化已逐步渗透到国民经济第一、第二、第三产业以及社会生活的各个领域，有效地推动了产业结构调整，促进了产业技术改造，提高了人们的生活水平，为产业发展和整个社会生活带来了革命性的变化。

软件产品和信息技术都是为推动企业管理进步或者技术改进的工具。因此，这个工作必须和其所服务的对象紧密结合，脱离了具体业务的信息系统只能当做一种游戏。也就是说，信息技术项目需要的人才一般要有一定的行业背景，对项目经理和业务骨干的综合素质要求很高，优秀的项目经理必须是既有计算机专业知识又有行业知识的复合型人才。如果ERP项目经理对所服务企业的行业背景不甚了解，对企业商业模式的理解不够深刻，是很难帮助企业提升管理水平的。

掌握规律— ERP实施项目的六大特点(2)

3. 跨组织性

ERP项目组最大的特点是由两个甚至更多的组织组成。项目组中既有供应商的实施顾问和项目经理，又有客户自己的各级领导、应用人员和项目经理，有时候还会有项目监理等第三方。这类项目中，项目经理是临时性的，团队成员是兼职参与项目的，如果没有当前这个项目的实施，所有的团队成员都有他们自己本职的工作，ERP项目实施的工作任务是凭空添加出来的，这就给项目组的协调和项目任务的落实带来一定困难。

在跨组织项目组中，要顺利推进项目，严格的工作分工和责任指派、严肃的纪律保障和团队成员间的相互信任非常重要。

4. 过程不易监控

ERP实施项目和传统的实施项目最大的不同是其中间结果的质量很难鉴定，而且中间结果和最终结果之间的联系不直接。譬如盖房子，从打地基起到盖完五层，人人都能看见和看懂它的进度。ERP项目实施则不同，比如调研阶段的结果就是一个几十页的Word文档，这些文档的优劣只有专家才能评价，所以，软件开发和实施的过程只有具备专业知识的人才能够真正看懂。这就使得ERP实施项目的过程检视和过程评审有一定难度，因为外行是看不懂的，甚至客户方也是看不懂的。

正因为ERP实施项目过程不易监控，过程管理就显得至关重要，稍有不慎，就会造成大量返工或工作遗漏，从而影响整个项目的进度、质量和投资。

5. 伴随着管理变革

ERP实施项目失败率很高的另一个原因却在项目之外，那就是ERP项目实施常常伴随着企业的管理变革。相当比例的失败项目，与其说是ERP项目实施的失败，还不如说是企业内部管理变革的失败。

因为ERP本身是一个新的信息化管理手段，使用这种管理手段和办公方式必然会冲击企业固有的管理模式。信息化的管理手段和传统管理手段之间的冲突，通常是很剧烈的。有时甚至会涉及企业内部高层权利的再分配，触动一部分人的既得利益。ERP项目实施顾问动辄会有意无意地卷入企业内部的这些矛盾中。从这个意义上讲，ERP实施过程就是企业内部的管理模式变更过程。

6. 受文化影响大

每个项目都是在一种或多种企业文化形式的背景下运行的，所以企业文化会影响ERP项目的实施成败。最为明显的就是企业的执行力文化，企业良好的执行力会对ERP项目顺利实施起到推波助澜的作用，而在执行力不好的企业实施ERP，则如逆水行舟，举步维艰。有时候，企业文化对项目成败的影响甚至可以是决定性的，在保守的企业文化笼罩下，中层干部和基层人员缺乏创新能力，几十年如一日地干同样的事情，从来没有改变过，也从来没有怀疑过它的合理性，更不打算优化现有的流程和制度。遇到这种情况，ERP要想落地生根，阻力就会较大，失败的风险就会大一些。

驾轻就熟—成熟软件背后的四重内涵(1)

驾轻就熟的意思是驾轻车，走熟路，比喻对某事有经验，很熟悉，做起来容易。对马而言，驾轻车，则其足以负荷车辆重量；走熟路，则行走路上的崎岖险夷尽在掌握。在ERP实施中，“驾轻”是对实施顾问而言的，“就熟”是对产品而言的。大多数客户在选型ERP中都隐约或笼统地有一个信条：要选择成熟的产品。问题是，“成熟”两个字背后的含义非常深广，笼统说说容易，要真正对“成熟”有一个全面的描述却比较难。我觉得，对想选择ERP的客户而言，谈成熟产品，离不开以下四个方面的含义。

1. 功能

首先是功能的成熟。诸如ERP之类的大型综合管理软件，其功能的成熟确实需要一个过程。因为在软件研发过程中，研发人员对客户管理实际需求进行了归纳和建模，但其归纳和建模的过程有一定的片面性，既不能代表客户需求的全部，又很难囊括不同类别的应用模型，甚至有很多功能是根据研发人员所假设的客户需求做的开发。因此，刚发版的软件拿到企业中实际去用，必然会有很多不适应。所以，我认为好的应用软件不是研发人员开发出来的，而是客户用出来的。应用软件只有在应用过程中结合客户实际反复修改完善，才能臻于成熟。因此，一款软件从发版到真正成熟需要一段时间。这个与客户切磋琢磨的过程不能短，越是复杂的应用软件越是如此。从这个意义上讲，打造好的应用软件如同酿酒，窖藏时间越长，酿出来的酒越好。如SAP这样的老牌知名ERP软件提供商，其最大的核心竞争力正是在不同行业、不同业务领域中几十年的经验积累。

功能成熟是客户的基本需求，也最容易被客户感知到。遗憾的是，在选型过程中，客户往往把功能需求泛化。比如客户通常会问：系统支持不支持库存多种计价方式？几家供应商都回答：支持。于是，客户就想当然地认为：在这个功能点上几家都能满足。把需求笼统到这种程度来比较功能我认为是没什么意义的，因为这种比较方式只能比较功能的有无，不能比较功能的成熟与否。换句话说，没法考察ERP产品与客户长时间如切如磋、如琢如磨的打造工艺过程。我甚至认为，在应用软件这个特殊的领域，不同供应商的产品间并没有完全的可比性。但现实生活中，因客户采购的制度、习惯等原因，又不得不把大相径庭的两个产品放在一起比，而比的过程又极其笼统粗糙，最后得出“千里马和一般马都是马，都能用”的结论。不同的是，千里马贵，一般马便宜，于是当然选便宜的，演变出IT界劣币驱逐良币的格局。所以对功能深入考察，坚持理性的合理投资是ERP选型过程中头等重要的事情。一旦因选型不慎造成项目失败，客户的损失可就大了，购买软件和实施的损失仅仅是冰山之一角，客户配套的软硬件投资、人员投入损失要大得多。如果算上项目失败给客户方相关人员的心理阴影和机会成本那就更大了。至今，我们偶尔还能觉察到20世纪90年代那些过早上ERP的国营大厂的经营管理者在经历了项目失败后所残留的防御心理。

驾轻就熟—成熟软件背后的四重内涵(2)

2. 性能

性能的问题是容易被人忽视的问题，就像年轻人容易忽视健康问题一样。客户最先关注并且重点关注的是功能，往往费了很大的力气来解决功能问题，蛮以为从此可以一劳永逸了。但始料未及的是，随着客户使用时间的推移，数据越积累越多；随着客户业务的发展，并发用户越来越多；随着应用的逐步深入，客户对应用系统的依赖越来越大；随着客户业务的对外扩张，对系统的开放性有了新的要求……这时候，客户会发现性能问题悄悄地从幕后走向前台，上升为主要矛盾，成为困扰客户的主要问题，诸如系统的开放性、可靠性、效率、易用性等方面的问题纷至沓来。

所以，在选型的开始就要考虑这些问题。以开放性为例，现在的应用软件提供商都非常注重统一平台的打造。比如用友，花费大量的力气打造一个应用平台，U9、NC都是如此，平台上定义了统一的接口标准，其作用就像兼容机的主板，不同的应用模块遵循接口标准开发，就能够像兼容机的网卡、显卡等板卡一样可随时插拔，把各个应用模块作为插件集成到同一平台上，就实现了应用的集成。这样的软件在开放性上有了明显的改进，企业可以用同一个平台实现整个企业的应用集成。平台也提供一些接口功能，以方便与那些先期的应用以及其他专业应用的对接。

可靠性也是一个随时间的推移会越来越凸显的问题，包括系统健壮运行的可靠和数据的可靠。用户对系统健壮性的要求随用户业务的发展而越来越高，比如原来要求知道每周的库存数据，但随着业务的发展，可能需要随时知道库存数据，这一业务的要求对系统的健壮性就提出新的要求。数据的可靠性更是如此，功能再好，数据不可靠仍是致命的问题。

随着客户的业务发展，客户数据的积累，效率问题日益突出。比如说，在一两百个并发的情况下，PC服务器、SQL SERVER数据还能提供稳定的支持，但是如果客户业务发展到上千个并发，恐怕数据库和服务器都要升级，这时候原有的应用软件能否支持小型机和大型数据库就会是一个很大的问题。还有，在应用不复杂的时候，中间件服务器的效率问题是隐性的，一旦应用复杂，访问量大，中间件服务器就成为应用瓶颈。如用友的NC在3.5版本之后就宣告不再用自己研发的中间件服务器，而全面OEM更专业的IBM的WAS中间件，就是出于效率的考虑，也只有这样才能有效解决效率问题。

驾轻就熟—成熟软件背后的四重内涵(3)

3. 顾问

选择功能全面、性能良好的应用软件并不是ERP项目选型的全部，因为买ERP并不像我们买电视、沙发，拿回来就能用，倒更像买了一架钢琴、一部汽车，只有学会弹琴、开车才能有效使用。ERP项目的实施顾问犹如驾校的教练或教琴的老师，他的职责是帮助企业顺利导入ERP。所以，第三个成熟的内涵就是供应商或实施方有成熟的顾问。我们经常会看到，同样的软件，类似的企业，不同顾问的实施效果会有很大差别，所以，ERP实施成功的关键要素很多，顾问无疑是较重要的一个因素。

成熟的顾问应该体现在三个方面。一是对客户业务的深入理解。如果缺乏业务的理解，和客户沟通起来会比较困难，难免拿现成的软件对客户的业务生搬硬套，很难灵活变通，效果自然打折。二是对产品以及产品相关技术的熟悉程度。所谓熟能生巧，只有熟悉产品才能巧妙变通，熟悉技术就敢于在现有软件的基础上做一些改造，以适应个性化的客户需求。客户的个性化需求是客观存在的，想拿一套软件覆盖很多客户的年代已经一去不复返，这种格局就更加需要实施顾问在实施过程中充分考虑客户的个性化需求，能够在应用上实现变通或者适当的客户化开发。三是在项目推进控制上的成熟，也就是项目管理能力，实施顾问要有能力指挥和指导大家工作，要能合理安排好各方面的工作，有效协调资源，及时梳理问题，做好高层沟通，营造团队氛围，推进项目顺利进行。

这三个方面的成熟是需要在项目实践中不断锻炼的，项目管理是实践性最强的学科，实施顾问只有在项目中反复摸索，才能少走弯路，越做越好。一个顾问，不经历三五个项目，很难谈得上成熟。就算产品功能成熟、性能可靠，没有成熟的实施顾问，实施效果仍然具有很大的不确定性。

4. 过程

第四个方面的成熟是指实施过程的成熟。现在每家ERP项目提供商都有自己的实施方法论，实施方法论是项目管理理论在ERP实施项目中的具体应用、扩展和丰富。好的实施方法论严格地定义了实施的目标、阶段、组织、活动，对每个活动的输入条件、主要工作、工作责任主体、时间、输出成果、风险等都做了全面的定义，就像一本实施地图册，照着地图册规定的路线走，就会少走弯路。

所以过程的成熟也至关重要，科学的过程编排蕴含了运筹学、管理科学、学习方略等多方面的道理。好的过程能有效控制返工，能很好地防范工作遗漏，甚至还会考虑到节奏变化、团队心理等方面的因素，以提高工作效率。

本书中有多篇关于过程和结果的论述，这里便不多赘述。

准确度量—软件项目规模估计有法可效(1)

软件项目的规模估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远。

因此，估算错误已被列入软件项目失败的四大原因之一。

软件工程师经常会被问到，编一个什么样的软件需要多长时间、多少资金。对于这个问题，不少人会犯难，原因有两个：一是用户的需求太不具体，二是自己缺乏一个科学的估计方法。这里向大家介绍几种软件项目规模的估计方法。

概念介绍

先介绍一个衡量软件项目规模最常用的概念—— LOC(line of code)，LOC指所有的可执行的源代码行数，包括可交付的工作控制语言(JCL：job control language)语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一行代码(1LOC)的价值和人月均代码行数可以体现一个软件生产组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行代码价值。

例如，某软件公司统计发现该公司每一万行C语言源代码形成的源文件(.c和.h文件)约为250K。某项目的源文件大小为3.75M，则可估计该项目源代码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10&#8197;000元(包括人均工资、福利、办公费用公摊等)，则该项目中1LOC的价值为：

(240×10&#8197;000)/150&#8197;000＝16元/LOC

该项目的人月均代码行数为：

150&#8197;000/240=625LOC/人月

方法一：Delphi法

Delphi法是目前最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来、新技术与特定程序之间的差别，但专家“专”的程度以及对项目的理解程度是工作中的难点，尽管Delphi技术可以减少这种偏差，但通常在评定一个新软件的实际成本时用得不多，这种方式在决定其他模型的输入时特别有用。Delphi法鼓励参加者根据问题进行相互讨论。这个技术要求有多种软件相关经验的人参与，互相说服对方。

准确度量—软件项目规模估计有法可效(2)

Delphi法的步骤是：

(1) 协调人向各专家提供项目规格和估计表格；

(2) 协调人召集小组会的各专家讨论与规模相关的因素；

(3) 各专家匿名填写迭代表格(如下图2-2所示)；

(4) 协调人整理出一个估计总结，以迭代表的形式返回专家；

(5) 协调人召集小组会，讨论较大的估计差异；

(6) 专家复查估计总结并在迭代表上提交另一个匿名估计；

(7) 重复(4)～(6)步骤，直到最低和最高估计达到一致。

Delphi法规模估计迭代表

项目名称：

估计日期：

估计者：

估计论次：

结果：

代码行 LOC；周期： 月；工作量： 人月；费用 元。

理由：

图2-2 Delphi法规模估计迭代表样例

方法二：类比法

类比法适合评估一些与历史项目在应用领域、环境和复杂度相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。

其基本步骤是：

(1) 整理出项目功能列表和实现每个功能的代码行；

(2) 标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；

(3) 通过步骤(1)和(2)得出各个功能的估计值；

(4) 产生规模估计。

软件项目中用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式来计算等价新代码行：

等价代码行 = [(重新设计% +重新编码% +重新测试%)/3]× 已有代码行

例如，有10&#8197;000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为：

[ (30% + 50% + 70%)/3 ]× 10&#8197;000 = 5&#8197;000 等价代码行

也就是说，重用这10&#8197;000代码相当于编写5&#8197;000代码行的工作量。

科学估算—应用PERT估计项目工期(1)

PERT(计划评审技术，Program Evaluation an Review Technique)是20世纪50年代末美国海军部开发北极星潜艇系统时为协调3000多个承包商和研究机构而开发的。其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。PERT可以估计整个项目在某段时间内完成的概率。由于PERT和CPM在项目的进度规划中应用非常广，因此，下面我将通过一个项目实例对此技术加以介绍。

1. 活动的时间估计

PERT对各个项目活动的完成时间按三种不同情况估计：

(1) 乐观时间(Optimistic Time)—— 任何事情都顺利的情况下，完成某项工作的时间；

(2) 最可能时间(Most Likely Time)—— 正常情况下，完成某项工作的时间；

(3) 悲观时间(Pessimistic Time)—— 最不利的情况下，完成某项工作的时间。

PERT认为以上三个估算值服从β分布，因此可算出每个活动的期望ti：

其中：ai表示第i项活动的乐观时间，mi 表示第i项活动的最可能时间，bi表示第i项活动的悲观时间。

根据β分布的方差计算方法，第i项活动的持续时间方差为：

例如，某政府OA系统的建设可分解为需求分析、设计编码、测试、安装部署等四个活动，各个活动顺次进行，没有时间上的重叠，活动的完成时间估计如图2-3所示：

科学估算—应用PERT估计项目工期(2)

图中每个箭头下给出的3个数字分别代表ai、mi和bi的数值。

则各活动的期望工期和方差为：

2. 项目周期估算

PERT认为整个项目的完成时间是各个活动完成时间之和，且服从正态分布。整个项目完成的时间t的数学期望T和方差σ2分别等于：

标准差为：

据此，可以得出正态分布曲线，如图2-4所示。

因为图2-4是正态曲线，根据正态分布规律，在±σ范围内，即在47.258～54.742天之间完成的概率为68%；在±2σ范围内，即在43.561～58.484天完成的概率为95%；在±3σ范围内，即39.774～62.226天完成的概率为99%。如果客户要求在39天内完成，则可完成的概率几乎为0，也就是说，项目有不可压缩的最小周期，这是客观规律。

图2-4 OA项目的工期正态分布图

通过查标准正态分布表，可得到整个项目在某一段时间内完成的概率。例如，如果客户要求在60天内完成，那么可能完成的概率为：

如果客户要求再提前7天，则完成的概率为：

3. 结语

实际上，大型项目的工期估算和进度控制非常复杂，往往需要将CPM和PERT结合使用，用CPM求出关键路径，再对关键路径上的各个活动用PERT估算完成期望和方差，最后得出项目在某一时间段内完成的概率。

PERT还告诉我们，任何项目都有不可压缩的最小周期，这是客观规律，千万不能不顾客观规律而对用户盲目承诺，否则必然会受到客观规律的惩罚。

一将难求—四种人不适合当项目经理(1)

项目管理和一般的管理相比，有非常独特的一面。表面上看，项目管理和企业管理相比面很窄，领域很专。项目经理的目标很单一，就是保质保量按时达成项目目标，远没有企业管理者那么多头绪；但话又说回来，要想保质保量按时达成项目目标，项目经理需要关注项目的方方面面，需要很宽的知识面、很强的沟通协调能力和目标意识。正因为项目的一次性和目标专一性，决定了项目管理者和企业管理者的不同，我认为有几种管理风格和性格倾向的人不适合担任项目经理。

1. 好好先生

可以把管理者的日常工作划分为两大类：管人和管事。不同的管理者有不同的倾向，一般而言，越是高阶的管理者管人的比重越大，越是低阶的管理者管事的比重越大，管人和管事要有一个合理的配比，管理才会真正有成效。而不同的人在管人和管事上有先天的偏向，有人更重管人，管理风格就是关系导向；有人更重管事，管理风格是任务导向。好好先生是指关系导向型的领导，这类领导更关心团队的关系，注重和睦相处，竭力维系团队和谐氛围，这类人被称为“和事佬”。和事佬把多数精力用到防止冲突和维系人际关系上，不知不觉就把任务放到次要位置。

项目管理属于目标管理，这一特点决定了这类好好先生不适合担任项目经理。在项目管理中，当然也要注重任务导向和人际导向的配比，但作为项目经理是绝对需要偏重任务导向的，因为项目是为既定任务所作的一次性的努力，项目团队是临时的，任务是一次性的，所以任务导向比关系导向更重要。任务导向为主，适当兼顾团队关系的领导最适合当项目经理，纯粹的关系导向的领导，几乎很难胜任项目经理。

关系导向的项目经理常常会因为维系人际关系的和睦而牺牲原则，一再妥协退让，导致项目目标严重偏离；还有一种倾向就是为了维持和谐相处的氛围，工作汇报的时候报喜不报忧，隐瞒不好的消息，却贻误了处理问题的最好时机。

2. 先锋勇士

和好好先生相反的另一个极端情况就是先锋勇士型的项目经理，这类经理是典型的任务导向性，并且能做到以身作则，亲自冲锋陷阵。这类项目经理可能是因为业务能力过硬被提拔为项目经理，通常自己干活干脆麻利，效率比较高，所以习惯事必躬亲，把其他成员沦为看他表演的“观众”。这样的项目经理本质上并不是管理者，绝大部分任务是靠项目经理亲自动手完成的，而管理的重点是透过他人的努力完成既定的任务，这类项目经理更像一个业务骨干。遗憾的是，这种管理风格会使其他项目成员非常迷茫且没有成就感，得不到应有的锻炼和提高。事实上，任何一个项目组成员参与到项目中来都有一个潜在的需求，就是通过参与项目来积累经验、锻炼自己、提高自己，当一个项目结束时，项目组成员是否得到长足的锻炼和提高也是考量项目经理是否优秀的一个软指标。很显然，先锋勇士型项目经理是不考虑这些的。

一将难求—四种人不适合当项目经理(2)

不可否认，这类管理风格在一两个人参与的小项目中比较奏效，但项目规模稍微大一点，涉及面稍微复杂一点，弊端就非常明显了。

3. 马虎大王

第三类我称之为马虎大王，主要特点是凡事计划性不强、考虑不周全、丢三落四。项目经理是整个项目的核心和舵手，整个团队的人都唯项目经理的马首是瞻。这就要求项目经理有很强的规划能力和事件驱动能力，要有很好的全局观和协调能力，而“马虎大王”型的项目经理，论做事，他可能非常积极投入也有能力，比“先锋勇士”型并不逊色；论管人，也并不比“好好先生”差，也能很好地把团队凝聚在一起，但他仍然不能胜任项目经理，原因是缺乏对项目的整体把握和规划，经常会顾此失彼，把项目陷入尴尬的境地。

项目实施是变设计为实体，化蓝图为具体的过程。因此，要求项目经理在做项目时就胸有成竹，并且会做好统筹工作，知道先做什么，后做什么，能更好地分工，把合适的工作指派给合适的人干，最后还要把不同过程产生的中间结果组合起来。所以，不懂业务的项目经理实际上很难管控好项目，同样是国际认证的项目管理师，IT行业的项目管理师绝对不能胜任建筑项目的项目管理，而不懂具体业务的企业管理者却未必管理不好一个企业。从这个意义上讲，对项目管理者的素质要求很高，要懂业务、懂规划、会做事、能管人，方方面面，林林总总。所以，西安工业大学赛云秀教授说，项目管理一尺深，一丈宽，需涉猎广博，然后能规划周到。在很多时候，尽管事前有周密的计划，也难免百密一疏，遇到一些意外。这时，如果之前的计划不够周密，到执行阶段就会千疮百孔，整个项目必然处于失控状态。

所以，“张飞”、“李逵”式的人是不可能胜任项目经理的。

4. 艺术大师

第四类我称作艺术大师型。这类人沉迷技术，有把项目看成一种艺术品的倾向，喜欢精雕细琢，过分强调细节，追求完美。我始终认为，在项目中，唯美求全往往要付出沉重的代价，甚至偏离目标更远。项目具有时限性，更有资源限制性，项目投资者更希望得到的是合适的投入产出比和性能价格比，项目投资需要项目快速投入使用以便快速收回成本，赚取利润。所以，做项目不是做工艺品，最重要的一条是实用。优秀的项目经理都是现实主义者，懂得用最经济的手段得到最实惠的回报，而不会投入很大的精力像艺术家一样追求卓越。

沉迷技术的人担任项目经理，要防止两种倾向：一是片面追求新技术、高难度，而实际上新技术往往意味着高风险，高难度往往意味着项目成果难以被人接受，因此，追求高新技术和追求实用经常会产生矛盾；二是追求完美，不管什么事情都追求尽善尽美，没有成本意识，过分沉溺于细节，导致工期拖延和成本增大。在项目组中需要艺术大师式的人物，但这类人绝对不能担任项目经理。

人无完人，全面优秀的项目经理非常难找，但是明显有以上四种倾向的人是不适合当项目经理的。同时作为项目经理，也要时刻警惕在项目管理过程中犯以上四种类型的错误。

团队建设—搭班子，还要带队伍(1)

联想集团总裁柳传志先生曾经讲过：管理就是定战略、搭班子、带队伍。对ERP实施项目来讲，搭班子和带队伍非常重要。

一般而言，ERP实施项目组至少是横跨两个机构的临时团队。这就决定了ERP项目组具有两个特性。

第一，项目各方因为一纸合同走到一起，甚至在合作之前他们互不相识，他们可能是客户方、实施方、监理方甚至政府代表。因此，项目组是一个临时性组织。

第二，在这种临时组成的项目组织中，多数人是兼职工作，他们在开展ERP实施项目的时候，还有自己的日常岗位工作。这两大特性是ERP实施项目组形成的客观规律，它不以人的意志为转移，项目经理要运用好这个客观规律，而不能不顾这些规律蛮干！

因此，ERP项目组织要处理好以下几个问题。

1. 项目实施以谁为主体

答案是一定要以客户方为主体。很多对ERP实施项目不甚了解的客户很不以为然，他们经常有这样的疑问：“我掏了实施费，花钱买了软件，实施还要以我为主体？”这其实也是前些年很多项目实施失败的症结，即客户过于依赖实施方的实施顾问。实施方的项目经理和实施顾问在项目实施过程中，因为交付项目需要在企业里待三个月、半年，有时甚至一两年。但是，一个不可回避的事实是他总有一天要离开企业，那么，当他离开的时候，企业方的人会不会使用，会不会维护这套系统，客观上就成为检验这个项目成功与否的标准。这个标准和项目验收与否、尾款付完与否都没关系。如果实施方的项目顾问前脚刚从项目中撤走，而客户方的使用人员和维护人员依然不会使用这套系统，那么这个项目的失败是必然的。所以，从这个意义上讲，ERP实施项目就是一个ERP软件安装、数据装载、使用和维护培训的过程。客户方的使用者和维护者越早学会使用和维护，就能越早独立使用，项目就会早一天成功。其实这一点和学习汽车驾驶一样，做ERP实施，实施方的顾问就好比驾校的教练，他教你学驾驶，在这个过程中，需要坐在驾驶位上的是你自己而不是教练。而且这里还有一个误区，就是客户不能太像客户！很多人通常认为：我是客户，我是上帝，你必须听我的。同样的例子，如果驾校的老师在教你学车的时候，因为你缴钱学车就是客户，于是什么都听你的，那么你肯定能把车开到沟里去，甚至撞墙。

所以从这个角度来讲，客户方一定要从一开始就树立以客户自己为主体的观念，而且要多听取实施顾问的意见，因为他是老师。

团队建设—搭班子，还要带队伍(2)

2. 建立信任关系

在一个大多数成员都是兼职工作的组织中，要实现既定的项目目标，有一种精神非常重要，就是信守承诺，或者叫诚信—— 即互相对这个项目做出的承诺一定要如期保质保量地兑现。企业领导和项目经理要在项目组中营造一种气氛，即项目组中客户方和实施方都必须如期保质保量地完成自己对项目组所承诺的工作！这一点对项目的成功实施很重要，而且这种项目信守承诺的逐渐积累，会建立起项目组内的信任关系。比如说，一开始项目组约定早上9:00开会，8:55大家都到了，那么这种信任关系就得到一点点积累，经过多次积累后，来自不同组织的项目组成员就会建立起可靠的信任关系。这种信任关系对双方来说，既是一种依托，也是一种约束。信任关系还可以逐渐放大，举例说，如果我刚认识你，就向你借一千元，你肯定是不愿意借的，因为我们之间还没有积累到这种信任程度。假如我只向你借五元钱，你多半会借给我，如果第二天我就还给你，时间再长一点，我向你借一百元钱的时候，你可能也会毫不犹豫地借给我，因为上次的及时还钱逐渐积累了这种信任关系，这一百元我还如期偿还，以后再借你一千元钱，你可能就会借给我了，因为你觉得我是个有诚信的人。所以，如果合作各方每次都能兑现各自的承诺的话，信任关系就会有正向的积累，久而久之，各方都有一个心灵的契约，这个契约可能就是实施主计划约定的那些任务和完成时间。相反，项目组成员间一旦缺乏这种信任关系的话，这个项目的问题就很大，小小的违约也是违约，一旦有一方违约，就是在破坏这种信任关系，如此下去，项目将会越来越糟。所以，项目经理一定要警惕这种行为的出现，一旦发现有人破坏项目组中的信任关系，哪怕是一点点的小问题，都要高度重视，及时纠正，因为这种情况一旦成为习惯，这种大家都是兼职参与的项目根本就难以继续。

另外，我认为在项目实施结束后，跨组织的项目组成员之间的私人关系也能从侧面反映项目的成功度。一个真正成功的项目，项目组会糅合成一个很好的团体。成功的项目在项目实施结束时，项目组成员间的私人关系也能达到一种好朋友般的信任关系，这种信任关系往往会拓展到其他方面。

团队建设—搭班子，还要带队伍(3)

3. 融合的速度、广度和深度

还有一点要注意，就是跨组织的项目组融合速度和深度在某种程度上反映了项目的成功度。跨组织团队中来自客户方和顾问方不同成员之间的关系是一种相互监督与合作的关系。这种关系既是合作关系，也是监督关系。合作关系就是要双方配合协作完成一项工作，它同时也是监督关系，因为如果双方没有监督关系，很有可能使得整个项目的方向走偏，或者达不到目标。在这个过程中，由于各方角色扮演的需要以及代表不同利益的需要，双方要互相监督，比如说监督各自按项目组的实施计划约定时间的工作完成情况，这种监督可以使项目中每个过程的质量都有保障。这种监督和合作的关系，既有合同的约束，是甲乙双方，又有共同的目标追求，即大家因为同一个事情走在一起，为实现同一目标而奋斗，项目成功对双方来说都是利益最大化！但是，我们也会经常看到，项目组有一些来自客户方的成员，往往只看到这种关系的一个方面，只把自己当成甲方，没有意识到自己同时还是项目组成员，而作出一些不利于项目顺利进行的决策。其实这种关系是时隐时现的，有时候为了维护甲乙双方各自的利益，就各自扮演自己的角色，代表自己的企业，但更多的时候，还是要融合成一个团队，为一个共同的目标而奋斗！

除上述三点以外，项目经理一定要重视团队能力的建设。每一个项目组成员参与项目都有一个必然的诉求，那就是他们希望能在项目中学习一点技能，积累一点经验。尽管我们说项目管理是目标管理，但项目经理绝对不能只盯着项目目标，不能简单地把团队成员当成实现目标的工具，完全以做事为导向。每个管理者都有一份天职，就是为下属的职业发展和能力提升负责，要关注他们的成长和发展，只有这样的项目经理才能带出配合默契、高效率的团队，项目经理才会逐渐具备个人魅力，团队成员才能够真正稳定下来，才愿意一直追随他。任何一个组织都承担着培养其组织成员的义务，越是成功的企业在这方面做得越出色，这恐怕是成功企业凝聚力强的最重要的原因。因此，管理者要努力做到：让每一个团队成员，在回首往事的时候，不因虚度年华而悔恨，不因碌碌无为而羞耻。如果团队成员在项目中只是挣了一点养家糊口的钱，而没有其他的成长和成就，他总有一天会醒悟过来，怨恨他曾经的领导像利用工具一样利用了他。越是高科技的项目团队，其成员渴望成长和发展的诉求越强烈，项目经理要特别注意这一点。

同曲异奏—高效能项目团队的五大特点(1)

在管理类的书籍中，不管花多大的篇幅讨论团队建设都不为过。项目团队管理是要把来自不同单位和从事不同工作的人员组织起来，为实现项目目标而共同奋斗。成为高效能的项目团队是项目经理和项目团队成员共同的职责。

就如项目本身的独特性一样，没有哪两个项目团队会一模一样。但是，项目团队能否高效地开展项目工作，主要体现在以下五个方面。

1. 共同的目标

每个组织都有自己的目标，项目团队也不例外，正是在这一目标的感召下，项目成员凝集在一起，并为之共同奋斗。为使项目团队工作富有成效，就必须明确目的和目标，并且对于要实现的项目目标，每个团队成员必须对此及其带来的收益有共同的思考。因为成员在项目里扮演多种角色，做多种工作，还要完成多项任务，而任务的确定要以明确目标和了解相互关系为基础。这就像一个交响乐队，团队中有拉小提琴的，有吹萨克斯的，还有敲打击乐器的，他们虽然分工不同，但演奏的是同一首曲子。所以，项目目标就是项目团队成员要协作演奏的乐谱，这个乐谱的一致是演奏成功的基本保障。

项目团队必须有一个明确的共同目标，这一目标是共同憧憬在客观环境中的具体化，并随着环境的变化而有着相应的调整，但每个队员也都了解它，认同它，都认为共同目标包容了个人目标，充分体现了个人的意志与利益，并且具有足够的吸引力，能够引发团队成员的激情。

2. 合理分工与协作

与第一条相对应的就是在共同目标的前提下，每个成员都应该明确自己的角色、权力、任务和职责，就像乐队中拉小提琴的必须明确自己的角色定位和演奏环节。在目标明确之后，还必须明确各个成员之间的相互关系。如果每个人彼此隔绝，大家都埋头做自己的事情，就不会形成一个真正的团队。因为每个人的行动都会影响到其他人的工作，所以团队成员都需要了解为实现项目目标而必须做的工作及其与其他人所承担的工作之间的关系。项目团队在建立初期，在团队成员的全体参与下花一定的时间明确项目目标和成员间的相互关系，可以在以后项目执行过程中少花许多时间和精力去处理各种误解。这就像交响乐队或合唱团要彩排一样。

同曲异奏—高效能项目团队的五大特点(2)

5. 有效的沟通

高效的项目团队还需要具有高效沟通的能力，项目团队必须装备有先进的信息技术系统与通讯网络，以满足团队的高效沟通。团队拥有全方位的、各种各样的、正式的和非正式的信息沟通渠道，能保证沟通直接高效、层次少、无官僚习气、基本无滞延。团队适合运用会议、座谈这种直接的沟通形式。沟通不仅是信息的沟通，更重要的是情感上的沟通。每个队员不仅应具有很好的交际能力，而且应拥有很高的情商，团队内要充满同情心和融洽的情感。项目团队具有开放、坦诚的沟通气氛，队员在团队会议中能充分沟通意见，倾听、接纳其他队员的意见，并经常能得到有效的反馈。

实践证明，团队成员之间相互了解越深入，团队建设就越出色。项目经理要确保个体成员能经常相互交流沟通，并为促进团队成员间的社会化创造条件，团队成员也要努力创造出这样的条件。

一般的ERP实施项目都会在项目实施期间安排团队成员在同一个办公环境下工作。当来自不同单位的团队成员被安排到一起工作时，他们就会有许多机会走到彼此的工作区进行交谈，也会在公共场所经常碰面，从而有机会在一起交流。当然，谈论的话题未必总是围绕工作。另外，团队成员有必要在不引起反感的情况下，多了解彼此的个人情况，项目过程中会建立起许多个人的友谊。安排整个团队在一起工作，就不会出现因为团队一部分成员在大楼或工厂的不同地方工作而产生“我们对他们”的想法。这种情形会导致项目团队分散为一些小组，而非一个实际的团队。

项目团队可以举办社交活动庆祝项目工作中的事件，例如取得重要的阶段成果—— 系统通过测试或与客户的设计评审会成功，也可以是为放松压力而定期举办的活动。团队为促进社会化和团队建设，可以组织各种活动。例如，下班后的聚餐、会议室的便餐、周末家庭野餐、观看一场体育活动或剧院演出等，一定要让团队中的每个人都参加这类活动。也许有些成员无法参加，但一定要邀请到每个人，并鼓励他们参加。团队成员要利用这个机会，尽量与其他团队成员(包括参加活动的家庭成员)相互结识，增进了解。一个基本规律是试图与不太熟悉的人在一起聊天，提出一些问题，听他谈论，发现共同兴趣。

要尽量避免让团队内部形成几个人组成的小团体，在每次活动中老是聚集在一起。参加社会活动，不仅有助于培养起忠诚友好的情感，也能使团队成员在项目合作中更容易进行开放、坦诚的交流沟通。除了组织社交活动外，团队还可以定期召开团队会议—— 相对项目会议而言。团队会议的目的是广泛讨论下面这些类似问题：作为一个团队，我们该怎样工作？有哪些因素妨碍团队工作(比如像工作规程、资源利用的先后次序或沟通)？我们如何克服这些障碍？我们怎样改进团队工作？如果项目经理参加团队会议，对他(她)应一视同仁。团队成员不应向经理寻求解答，经理也不能利用职权，否决团队的共识。因为这是团队会议，而不是项目会议，只讨论与团队相关的问题而与项目无关

因势利导—掌握团队表现的规律(1)

一个项目团队从开始到终止，是一个不断成长和变化的过程，这个发展过程可以描述为四个时期：形成期、震荡期、正规期、表现期。几乎所有的项目都经历过大家被召集到一起的形成期，这是一个较为短暂的时期。很快会进入震荡期，这时成员之间互相还不了解，时常感到困惑，有时成员间甚至会产生敌对心理。接下来在项目经理强有力的领导下，团队的工作方式在正规期得以统一，随后团队以最大成效开展工作，直至项目结束，项目团队解散。这一过程如图2-5所示。

图2-5 项目团队各阶段的团队精神、工作绩效和调控力度

1. 形成期

任何项目在形成时期总是带着一点试验性质的，因而团队环境就成为新思想、新方案最佳的试验场。每个方案都应当加以仔细检验，给予它们公平争取成功的机会。大量的团队工作是诸如怎样尽早发现错误和怎样能在不引起恼火和责难的情况下改正错误。如何对待失败的方案是团队在“组建期到成效期”的发展过程中应当学习的内容。在团队发展的不同阶段，需要有不同的方案。

在形成期，团队成员从原来不同的组织聚集在一起，大家从陌生到相识相知，这一时期的特征是队员们既兴奋又焦虑，而且还有一种主人翁感，他们必须在承担风险前相互熟悉。一方面，团队成员收集有关项目的信息，试图弄清项目是干什么的和自己应该做些什么；另一方面，团队成员谨慎地研究和学习适宜的举止行为。他们从项目经理处寻找或相互了解，以期为自己进行合适的定位。

当成员了解并认识到有关团队的基本情况后，就为自己找到了适合的角色，并且有了自己作为团队不可缺少的一部分的意识，当团队成员在项目中找到归属感时，他们就会承担起团队的任务，并确定自己在完成这一任务中的参与程度。解决了定位问题后，团队成员就不会感到茫然不知所措，从而有助于其他各种关系的建立。

2. 震荡期

团队发展的第二阶段是震荡期。团队形成之后，队员们已经明确了项目的工作以及各自的职责，于是开始执行分配到的任务。在实际工作中，各方面的问题逐渐显露出来，这预示着震荡期的来临。但现实很可能与当初的期望发生较大的偏离，于是，队员们可能会消极地对待项目工作和项目经理。在此阶段，工作气氛趋于紧张，问题逐渐暴露，团队士气较形成期明显下沉。

团队的冲突和不和谐是这阶段的一个显著特点。成员之间由于立场、观念、方法、行为等方面的差异而产生各种冲突，人际关系陷入紧张局面，甚至出现敌视、强烈情绪以及向领导者挑战的情形。冲突可能发生在领导与个别团队队员之间，领导与整个团队之间以及团队成员相互之间。这些冲突可能是情感上的，或是与事实有关的，或是建设性的，或是破坏性的，或是争辩性的，或是隐瞒的。不管怎样，应当力图采用理性的、无偏见的态度来解决团队成员之间的争端，而不应当采用情感化的态度。

在这一时期，团队队员与周围的环境之间也会产生不和谐，如队员与项目技术系统之间的不协调，团队队员可能对项目团队采用的信息技术系统不熟悉，经常出差错。另外，项目在运行过程中，与项目外其他部门要发生各种各样的关系，也会产生各种各样的矛盾冲突，这需要进行很好的协调。

因势利导—掌握团队表现的规律(2)

3. 正规期

经受了磨合期的考验，团队成员之间、团队与项目经理之间的关系已确立好了。绝大部分个人矛盾已得到解决。总的来说，这一阶段的矛盾程度要低于磨合时期。同时，随着个人期望与现实情形—— 即要做的工作、可用的资源、限制条件、其他参与的人员相统一，队员的不满情绪也就减少了。项目团队接受了这个工作环境，项目规程得以改进和规范化。控制及决策权从项目经理移交给了项目团队，凝聚力开始形成，有了团队的感觉，每个人觉得自己是团队的一员，也会接受其他成员作为团队的一部分。每个成员为取得项目目标所做的贡献得到认同和赞赏。

这一阶段，随着成员之间开始相互信任，团队的信任得以发展—— 大量地交流信息、观点和感情，合作意识增强，团队成员互相交换看法，并感觉到他们可以自由地、建设性地表达他们的情绪及评论意见。团队经过这个社会化的过程后，建立了忠诚和友谊，也有可能建立超出工作范围的友谊。

4. 表现期

经过前一阶段，团队确立了行为规范和工作方式。项目团队积极工作，急于实现项目目标。这一阶段的工作绩效很高，团队有集体感和荣誉感，信心十足。项目团队能开放、坦诚、及时地进行沟通。在这一阶段，团队根据实际需要，以团队、个人或临时小组的方式进行工作，团队相互依赖度高。队员们经常合作，并在自己的工作任务外尽力相互帮助。团队能感觉到高度授权，如果出现问题，就由合适的团队成员组成临时小组，解决问题，并决定如何实施方案。随着工作的进展并得到表扬，团队获得满足感。个体成员会意识到为项目工作会使他们获得职业上的发展。

相互的理解、高效的沟通、密切的配合、充分的授权，这些相对宽松的环境加上队员们的工作激情使得这一阶段容易取得较大成绩，实现项目的创新。团队精神和集体的合力在这一阶段得到了充分的体现，每位队员在这一阶段的工作和学习中都取得了长足的进步和巨大的发展，这是一个“1+1>2”的阶段

合文齐武—项目激励和约束(1)

在项目组中，激励非常重要。只有你了解你的团队，了解他们的需求，才能有效激励你的团队，相反，如果你不知道他们的需求和想法，就没有办法改变他们的态度，也就没有办法激励他们。

所以，我觉得作为项目经理一定要了解你的下属—— 项目组成员，我们经常强调项目经理要懂得运用马斯洛的人类需求分析理论对下属来分析。生理需求和安全需求是最低层次需求，我想IT项目组成员这两个方面的需求还是能保障的，这里就多谈了；社交需求(或者要有归属感)是第三个层次，因此项目经理如何给团队成员以归属感就非常重要，这也是营造团队氛围的难题。另外，团队成员除了在项目组中有归属感，还应该在社会其他社团中有归属感，如家庭的归属感的满足也是项目经理必须考虑的问题；第四层是受尊重的需求，这一点也很重要，让每一个团队成员认识到自己所承担的那部分工作的重要性，明确他们的工作和贡献是受人尊重的，而项目经理也确实要营造团队成员间相互尊重的环境，就容易满足这一层的需求；最上层就是要让团队成员有成就感，分享项目成功的喜悦，把项目成果分解并传递到每一个成员身上，让每一个人感受到因为深度参与项目而获得了自我超越。

很多时候，项目经理缺乏很好的激励员工的办法，往往是因为项目经理并不清楚他们的成员到底需要什么，只清楚自己需要他们干什么，项目经理只知道要求团队成员做好项目，做好配合，却不能回答一些问题：他为什么要做好项目，或者他凭什么做好这个项目？做完这个项目他能得到什么？能满足他的什么需求？有的项目经理只知道一种单纯、简单的激励方式—— 发奖金。殊不知，人的需求是复杂的，人生的目标是多样的，人生的追求是多样的，人的价值观是各不相同的。在这样一种背景下，项目经理必须懂得多样化的、个性化的激励方式，给不同的人不同的东西，让他们在项目中各得其所，得到其所想要的东西，他才会受到最大限度的激励，这种激励才会让他努力工作，释放潜能。

我以前主管研发的时候，就经常讲两句话。第一句话是“态度决定一切”。你的团队成员在项目中是一个什么样的工作心态很重要。有些人来项目组是为了学习新的技能，有些人来项目组则是为了改善收入，不同的人参加项目组的动机不同，需求也各不相同。那么，项目经理如何想办法差异化地满足每一个个体的需求，是改变项目组成员投入程度和工作态度的关键。我们经常会遇到这样的情形：一些能力很强的人在某一个项目组中却表现平平，这时候作为项目经理，就要挖掘、探索造成这种情形的真正原因，是什么原因导致他现在的表现和两年前大相径庭？找到这个原因之后，项目经理才能对症下药，才能有效激励。

合文齐武—项目激励和约束(2)

另一句话是“激情才是生产力”。项目一般要在相对紧张的节奏下进行，工作要求紧迫、强度也大，团队成员如果没有激情根本不可能有效推动项目。因此，我始终认为根本不能接受在IT项目中充人天，充人数的成员。

激励是正向的引导和激发团队成员的潜能，但是光正向的激励还是不够的，项目的正常进行还要有足够的纪律保证，甚至需要负激励。“合之以文，齐之以武，是谓必取。”用今天的话来讲，就是要用文化(愿景、感情等)把大家聚集在一起，还要用武力(纪律约束)让大家步伐整齐。所以，除了要有明确的激励之外还要有严明的纪律，如同革命时期，既提出了“打土豪，分田地”这样明确的激励口号，也明确了“三大纪律，八项注意”的纪律要求，这两者是相辅相成的，都是项目成功的关键要素。

尤其针对一些跨组织的松散项目组，严明的纪律尤为重要。因为松散组织的项目组中，每一个人除了项目工作外，本身还有自己的工作，如果项目经理没有明确的纪律要求和压力传递的话，项目组的工作恐怕在每个成员的时间表中都成为最低优先级的工作，那么项目目标的实现就会变得异常困难。所以，滥好人或者不愿意得罪人的人是不适合当项目经理的。

除了要有严明的纪律要求之外，执法也是一个问题，有的项目有明确成文的纪律要求，甚至有详细的处罚条例，但在执行过程中，项目经理手软，有法不依，造成项目纪律形同虚设，各项工作照样很难推进。故“卒未亲而罚之，则不服，不服则难用。卒已亲附而罚不行，则不可用”。也就是说，当团队成员还没有融入项目组，你处罚他，他就不服，不服就很难用；当团队成员跟项目经理非常亲近，这时候则往往容易徇私情，有罚不行，那么这个人也不好使用。所以项目经理和团队成员之间还要有适度的距离，既不能太远而以至于“卒未亲”，又不能太近而以至于“罚不行”。