|
很明显，不管是根据传言还是客观来讲，进程改进的失败远比成功多。本文对这一事实进行讨论。转自项目管理者联盟
华特-凯利的“我们遇到敌人，他就是我们自己”是有史以来最着名的漫画名言之一。这句话最初用在1970年的地球日海报上，后来被凯利应用到一个两集漫画中。尽管漫画的观点特别适用于果断的环境广告，它也适合任何人为努力。项目经理圈子
这些年来，我们在进程改进方面投入了大量努力和资源——包括TQM、CMMI、六西格玛、ISO 9001等。但是，很明显，不管是根据传言还是客观来讲，进程改进的失败远比成功多。这是我们自己的错。项目管理者联盟
统计数据PgMp.mypm.net
朱兰研究院(Juran Institute)预计，错误、返工和废料的累计成本合计占公司总支出的25-40%。斯坦利集团(Standish Group)2004年的“混乱报告”(Chaos Report)——根据(至今)对50000多个信息技术(IT)项目调查进行的半年一次的研究——估计，只有29%的软件项目取得了成功，所有项目中有53%的项目没有达到它们预定的成本、进度或性能目标。其它18%的项目在完成或交付前就被取消，或从未被使用。总体失败率达71%。硕士论文代写网专业从事工程硕士论文代写服务，如有业务需求请联系客服人员项目管理论坛
应用在进程改进方面，帕累托原理——常被称之为80-20原则——表明，80%的努力只会带来20%的利益。
有些人可能会反对将这三个现实近似值结合起来。特别是对一些人而言，将IT项目性能方面的发现应用于进程改进性能上可能尤其令人困惑。没有任何证据表明进程改进项目比IT项目更加复杂或是困难。进程改进通常会有一个独立存在的IT组件。更为重要的是，二者的环境与管理背景相同。转自项目管理者联盟
根据我的了解，还没有人尝试量化进程改进的成功率。即使没有其它目的，把这三个统计结果和其它事实结合起来也是一个不错的起点，可能还会更好。项目管理者联盟
一般来讲，单独优化每个子系统的局部优化原理并不能提高对整个系统的优化。改进子系统的行为常常得到与预期相反的结果。bbs.mypm.net
换句话说，整体往往小于各部分的总和。bbs.mypm.net
局部优化内部存在一些严重的操作盲点：项目管理者联盟
忽视了各种子系统彼此交互造成的累积。项目管理者联盟
认为各种子系统输出最大化与整个系统最终输出最大化相同，将二者混淆。bbs.mypm.net
认为最后的输出会达到预计的目标和/或结果。项目管理者联盟
无法证实最终目标确实朝着公司的整体规划发展。项目管理者联盟
NASA(国家航空宇航局)1967年的一份报告指出：项目经理博客
“为避免局部优化，有必要根据系统的总体需求制订出合乎逻辑的设计标准，紧记最大值目标。”项目管理者联盟
抛开工程上的繁文缛节不论，这段话说明：我们往往并未充分了解子系统间的独立性。www.mypm.net
让我们回到80-20原则。在很大程度上，进程改进作为一种企业范围内的解决方案推向市场并完成。通常，这种方法是对以前IT管理严重错误所做出的反应，当时组织不小心采用了一个错误或不完善的再工程策略，并很少注意需求的启发和确认过程。但是，这种企业范围内的方法存在一些严重错误：它认为企业做出的所有规划都能顺利完成。项目管理者联盟
由于改进的成本可能比它们带来的效率改善更加昂贵，并非所有的进程都适于进行改进。而且，80-20原则实际上是一个无效常量。它告诉我们，一个全面的企业进程改进方法极有可能会导致失败。如果80%的努力只会产生20%的利益，那么只有通过剩下20%的努力去寻求80%的利益。你最好去拉斯维加斯发现更高的机率。项目管理者联盟
用80-20原则为起点，我们可以断定，公司20%的进程会产生80%的浪费和返工。LifeStar的Jay Arthru建议我们采用一个不一样的，更为集中式的方法。他指出80-20原则也适用于它本身(即20%的20%和80%的80%)，也就是公司4%的进程会产生64%的浪费和返工。再应用一次80-20原则会得到一个完美的结果：公司1%的进程会产生50%的浪费和返工。PgMp.mypm.net
实际上，进程改进通常会激化为争夺希缺资源引发的内部竞争，这种竞争又可能会诱发意外的个人、商业单元和文化冲突。它还会给组织决策造成意想不到的瓶颈。进程改进的这些难以预料的结果必须由一个组织来处理;这个组织在试图改进方面已经力不从心，同时还要维持日常的职能。bbs.mypm.net
即便如此，公司总裁与资深经理人还在继续“英勇地”追求进程改进方法。那他们为何还要这样做呢?对于这个问题，恐怕我也没有一个正确的答案。项目经理博客 项目管理者联盟
|
