正如热门概念往往会引起的后果那样，哈墨和钱丕关于再设计过程的简单但深刻的概
念，引发了一股商务研讨会、培训班、大学课程、杂志文章和各种专家出版“效颦”专著的
热潮。①在这个过程（一语双关）中，各式各样的商务人员用“再设计”这个词来为几乎任
何组织变动做辩解。两年以前，一家大电脑公司开始了“再设计”的努力，把人事部门大部
分人都解雇了，没有留下人来合理地处理实际上裁员的后果。这家公司没有人事专家来指导
变动，犯了一些错误。它买断了自由打工者的合同，在他们还没干更多工作之前就把他们打
发走了——尽管公司已经支付了他们的服务费。新晋升的人本来很受赏识，现在却被解雇
了，因为他们在现有等级上是资历最浅的。要把这种行为看作合理化裁员是很难的，而且也
绝对不是再设计。迈克尔·哈墨在一次谈话中曾说：“有时再设计几乎是指任何事情，但绝
对不是指再设计了。”尽管有些人对这个概念太过热心或利用它来掩饰裁员，但时不时地审
视您的过程，使它们更有效，并把低效率排挤出去，这个想法现在却比以往更为重要。
    ①1998年10月在因特网上对“再设计”一词的搜寻找出了189940个文件，内容
从关于2000年日期计算问题的文章到一个被描述为“玩笑的严肃一面”的研讨班，无所不
有。文件数目比其他重要的商务话题大得多——例如，比知识管理的话题多。
    创建一个新过程是个重大项目。您应该有一个明确的成功定义，在时间和任务方面有明
确的开端和结束，有中期成果和一个预算。最好的项目就是：员工们心里有清楚的顾
    客情况。这也运用于过程项目。顾客可能在公司外或在公司内，但是概念却是同样的：
这个人将怎样使用您在开发的产品或过程？这个产品或过程比以前的那个好在哪里？
    您也需要在各个级别上理解交换。每个项目都有交换。在软件项目里，管理方总想要产
品特征多样、小型，并且花费甚少、一夜之间就做好。经理们什么好处都想要，因此必须明
白无误地理解交换。如果您善干把产品制作得特征多样，并不得不把它做大些，那么您就不
想让管理方过后说，您本来应该牺牲几个特征，把产品做得小一点。如果您限制成本，那么
您就不想让您管理方说您本来该花同样的成本但包括更多的特征。一个建造数字过程的项目
也是同理。
    您面对着变化中的要求应该灵活应变，但又不应该缓慢地做修改以使原来的设计目标失
效。您应该有果断的决策过程来评估变化，包括重新评价原来项目目标的规定。

更新产品交货过程
    数年前，在准备妥当以便装载运输的那一天，一次WindowsNT的重要发货几乎被耽搁
了。并不是因为畅销产品有缺陷或某种其他产品开发的问题，而是因为一只硬纸箱不见了。
产品包装箱的艺术设计留在一个人的桌上，而那人又恰好在那天去度假了。艺术设计图一直
在那里，直到箱子完工了还没能按期到达制造部。而离发货最后期限只剩两天了。但包装箱
通常需要10天才能生产出来。制造部的操作工日夜加班才给我们生产了足够的箱子以便按
期交货——箱子上的油墨都还没干。
    在这次事故之后，这个小组负责营销材料的经理把大家召集在一起分析毛病出在哪里。
这个小组由12名员工组成，是来自公司内两个处和两个外部销售商的人员，经理提了一个
问题——也是我在微软公司常提的一个普通问题——“为什么这个房间里有那么多人？”在
任何会议上我只想要最重要的决策者参加。其他人都应该离开，去解决其他问题。如果您在
房间里发现多于3～4名决策人，那么您就能肯定仅仅是这么多人数就是问题的一个主要部分。
    这个经理要求小组简化过程并找出该部门其他十几个产品类似的协调问题。“找出一个
问题模式来，然后为全部产品解决这个问题。”他说。
    在短期里，小组建立了“肯定性承认”的原则，意思是，一次工作交接要等流程中的下
一个人说：“我拿到了”才算完成。不能再盲目地把东西从门窗横档间扔过去了。
    这个小组还把交接的次数从5次减到3次。减少交接次数也许不像一个重大步骤，但任
何消除“接触”的步骤都会减少犯错误的机会并有助于保证质量。1997年，在一家新工厂
里，戴尔电脑公司重新设计了它的生产线，以便削减一半处理硬盘的次数。该公司制造部硬
盘的退货率降低了40％，PC总故障率降低了20％。
    在微软公司，各部门负责把产品组件送到制造部去的人开始召开最佳作法会议。我们在
爱尔兰制造销售给欧洲的产品，那里的高级经营主管乘飞机来谈美国惯例给她的公司带来的
问题。我们随后找出了给制造准备材料时的一些过程问题。例如，有一次我们在产品包装箱
上用了特殊字体，却没有意识到这种字体并不是在全世界都有的。这使得我们好几个产品都
投放得晚了，没赶上在澳大利亚的假日消费季节。这就损害了盈利。
    所有部门的过程拥有者们聚在一起，给一个全球性生产过程下定义，这个过程将利用数
字工具来改进协调。我们创造了一个应用程序来追踪所有产品组件，包括箱子、箱子上的标
签、艺术设计和实际的软件编码。产品经理和其他雇员们有了网络上关于所有这些组件的信
息，就可以容易地追踪他们制造过程的现状。我们有一个单独的、定义清楚的电子生产过
程，它除了其他好处之外，还能保证我们在改进流程上的任何步骤，这些步骤会在整个公司
里通用。
    在这个同样的时间框架里，我们也开始给公司的制造部搞外部采购原料。这一变革意味
着我们必须给“交钥匙”制造方式提供完整的材料。过程必须更清楚——取决于过程，而不
是取决于人。一个目标就是：“经营部不应该总是唱主角”。改进了内部协调的数字工具现
在使得协调过程的最后阶段成为可能，即和一个外部制造商实际地制造这个产品。除了内部
跟踪产品组件的应用程序外，我们还为销售商开发了另一个工具来断定产品组件的投放现
状。销售商，包括外部制造商，也利用这个工具来数字材料并在电脑上订购非数字材
料。在这里，我们的数字工具不仅使得我们能在内部处理过程问题，而且使得一家专营制造
的公司能为我们承担新的工作。
    一个问题可能就是：我们为什么一开始要搞制造？在我们有数字过程前，我们别无选
择。今天我们的信息工具足够先进，能让我们为制造部门搞外部采购，但仍能肯定我们的产
品是按我们的规格制造的。我们在公司里保留一套核心专家班子，并把网络当做与外部专家
协调的主要方式。
    在五六个月之后，这些小组不仅把已经引起问题的程序修理好了，而且还发现和拆除了
其他几个尚未爆炸的不良程序的定时炸弹。新工具帮助辨认程序中潜在的冲突，并在冲突或
遗漏发生之前就让所有的成员都合作解决问题。对一家企业来说，未出现的问题的价值该有
多大？

创建分阶段解决问题的过程
    一个叫做HeadTrax的内部用微软应用程序的开发史，就是个好例子，说明商务需求和
技术问的共存关系如何起作用。使得前数字化世界里不可能有的新过程产生作用。HeadTrax
是个工作流程应用程序，用于处理人事变化。一次人事变化可能指雇佣员工、晋升、调动或
部门内的变动。
    我们开发HeadTrax的努力表明，有时需要一系列的重复性步骤来理解您想解决的问
题，并选择正确的过程和技术。对目标理解不完整，是每个技术项目里令人担心的主要问
题。这说明为什么您处理更小的过程并依赖它们发展时，运气要更好。不管您计划有多周
密，您经常会发现您对用户的需求并不是完全理解。假如您花了18个月把一个完整的解决
方案弄好并交货，却意识到您并没有把它搞对，或在这个期间内商务需求有了变化，那么您
的处境就会很糟糕。一个更好的办法就是利用软件工具，它们能使您在不到6个月的时间里
就做出能用的程序来，然后等您得到用户反馈后又可以改进解决方案。
    我们的人事流动应用程序第一版看上去不错，直到我们的副总裁们的电子邮件收文箱里
收到了许多电子批准表格为止。有些经理们喜欢能在网上处理大部分人事变动，但其他人却
不想观看每一次变动，而更喜欢只看高层雇佣或调动的批准表格。在大科室里的经理们不能
处理这么大的工作量。陈旧的纸张文件系统使得授权更容易，所以我们又需要把授权增加到
这个数字系统里去。这个应用程序的第二版功能齐全，但是流程仍然有值得改进的地方。有
时重要的批准手续在低层走上岔道了，而小的人事变动却仍然时不时出现在一个副总裁的膝
上型电脑中。我们与安德逊咨询公司协作，意识到我们有15个主要组里的12种不同的批准
过程。我们针对过程，把12个减少到3个；这3个过程就是HeadTrax第三版的核心。
    今天，经理们在网上启动所有人事变动程序。任何评审人都能退回一份申请，让原申请
人修改申请并用数字形式把申请重新寄来。评审人也能对申请做修改，然后批准它，并让申
请继续沿着路径前进。所有与这个申请有关的人都会收到电子邮件，并有与变动申请相连的
链接，好让他们审查申请。在过去，大部分人力资源部门对人事变动申请的拒绝都是由于次
要问题或编码错误等问题引起的。HeadTrax几乎淘汰了那种拒绝。
    一种“代替……行使职权”的特征，使得一位经理能够把任何类型的人事申请的批准职
责下放给其他人，这一特征证明是HeadTrax最重要的功能。一位副总裁可能会授权一个行
政助理批准日常的职务变动或人事变动，授权高级经理们批准他们领导的小组的报酬或晋升
申请。“代替……行使职权”的特征赋予经理们一种创造节省时间的例外的办法，并使批准
过程能继续运行。如果一个1000人的分部要变动成本中心，或者在一次调整组织中所有的
小组都要换人，那么一个行政助理就能整体选定这些小组，并在组织结构图上点击一个按钮
来做出所有的变动。
    一个按规定路程发送的特征能增加灵活性。作申请的经理能在把申请上交给人力资源部
之前将一个人加进评审圈。例如，一位高级经理评审某种特殊类型的诸如晋升那样的雇员变
动。
    HeadTrax对于非行政性的工作也是有用的。在开始时，不管您输入哪个雇员的姓名，
HeadTrax都会显示整个组织结构图，从高到低的所有人员都有。HeadTrax也能让您在匆忙
中创建组织结构图，并根据各种特征——如全名、电话号码、办公室号码、部门编号等等来
做特制的图表视图。
    现在HeadTrax这个程序完成了，它就像一个明显的解决办法，是中等规模和大型公司
都能用的一个应用程序。它不仅仅是一种从经理办公桌上清除掉人事文牍的办法，而且在有
组织变动的时候，是把人事变动推进到会计和预算系统里去的一台引擎。它保证我们所有的
商务系统都保持同步运作。
    由于HeadTrax系统刚出台，要拿出它在消除丢失的或不完整的文牍和数据输入时间上
给我们节省的时间和精力的确切数字，是很困难的。但是到1998年年底时，HeadTrax每个
月处理大约8000次人事变动。不再需要人力资源部评审的批准手续占所有人事申请的90
％，在24小时内就反映在这个系统中了。人力资源批准手续要花更长的时间，这是因为一
些与技术无关的过程，例如给一个要离开公司的人举行的辞职面谈。
    HeadTrax使商务和人力资源经理们能够在任何时间审
    查所有未解决的人事变动，从而增进了他们的责任感。一个商务经理通过清点他小组里
的人头数，能够了解他的小组成员在岗位缺人时干得如何。如果这个经理发现他的一个直接
下属经理比本部门其他经理更缺人手时，那么这个高级经理就可以调查一下，看是否需要花
更多时间雇佣一位经理来招聘人员，或者是否需要从公司的招聘小组得到更多的帮助。
    负责人力资源的经理们认识到，把时间花费在批准每一次常规人事变动上，并不是最明
智的。相反，他们开发了一个电子工具来处理日常业务，并收集数据做人事管理趋势分析。
一个高级人力资源经理可以用HeadTrax的审计功能来查看所有被拒绝的人事变动，看是否
有个模式显示出经理们需要在人事问题上接受更多教育，或HeadTrax应用程序是否需要有
附加的一些功能。人力资源部也可以分析一个经营单位是否比其他单位有更高的人员流动
率，还能看员工离开公司的理由中是否有个共同模式。HeadTrax不仅为我们的商务人员提
高过程效率，而且使我们的人力资源人员能重新定义他们的作用。能立即看到关于调动率或
员工流通率这类事情的数据，其价值远远高于降低的成本或节省的时间。
    认准任何过程首要的、中心的目标，这就是开始解决过程问题的办法。不管是生产过程
还是内部商务过程，其目标都应该永远是根本性的简单化：让最少的入做最少的交接。要优
化一个书面过程是极端困难的。数字技术使开发更好的过程成为可能，它不是让您停滞在陈
旧的书面过程的小变动上，那只能让您做渐进性的提高。真正的过程突破来自认真考虑的解
决方案与数字信息流的结合。

利用数字过程解决难题
    在微软公司最棘手的商务过程之一就是雇佣、管理临时工以及给他们付酬。
    对于一家有许多项目、产品投放市场时工作量达到顶峰的公司来说，管理临时工是极为
重要的，临时工帮我们处理高峰期工作负担，从开发、测试、营销到行政支持工作，包罗万
象，无所不有。在我们对临时工的使用中，有5组人员需要协调好：（1）临时工本身；
（2）临时工为之工作的110家机构；（3）在各个部门里使用临时工的经理们；（4）我们
公司内部的临时工管理小组，该小组管理我们与临时工介绍所的关系，跟踪临时工每小时的
工资率；（5）公司采购部，实际上是它们给临时工支付薪水。
    我们的业务问题是多方面的，不仅仅是因为跟许多不同的机构和临时工签约购买服务要
牵涉到大量文件。我们在保证连贯的签约过程，按恰当的小时工资招聘合适的人员，不把临
时工使用在大多的连续项目上或在一个项目上使用临时工大久，以及决定什么时候把临时工
转变成正式工等问题上都有困难。
    几年前制订的一个雇佣人员的政策，在使用临时工问题上建立了严格的指导方针。按政
策规定，所有临时工都应通过职业介绍所来雇佣，任何临时工都不得在各种综合项目上工作
超过340天，他在其间应中断服务至少31天。但是书面的过程使得签约雇佣临时工的经理
——他们中许多人都是新到公司的或新担任这个职务的——很难保证遵循这个指导方针。由
于我们的招聘经理们都有事情逼到头上来才行动的特点，所以我们满足各部门的需求和防止
犯错误的唯一办法就是把许多人投入到要解决的问题上去。人力密集型的过程并不使我们感
到高兴。
    再有就是，书面过程并没有给高级经理们解决预算问题。因为许多经理都雇佣了临时
工，以及临时工经常在多个项目上工作，各部门的高级经理们没法掌握被使用的临时工总人
数，也没法掌握临时工工作的小时总数。我们无法前后一致地预测雇佣临时工的成本。各部
门经理从财会部弄来的关于人数、小时数和成本的财会数据总是姗姗来迟，或只是估计而不
是实际的小时和成本。给临时工支付的工资在有的月份升得很高，有的月份又降得很低。
    在一开始的时候，我们以为这个问题是出在财会部的过程里，但是当我们分析数据时，
我们意识到财会部得到的信息也不全。我们的支付过程控制机制很少。尽管有很多签字——
经理们给临时工签上班时间卡，然后临时工把卡交给他们的职业介绍所，介绍所又给我们寄
来账单，采购部给这些账单付款——但实际上没有财会控制。一个经理无法确定小时工资率
或开了账单的小时总数。一份账单可能会没有签字的时间卡就给我们邮寄来了。一个经理可
能会同意给一个临时工涨薪，但临时工雇佣部却可能得不到这个信息。或者一个临时工会在
一个项目上得到涨薪，但是这笔涨薪却错记在另一个项目上了。我们没有办法制止开来的双
重账单。
    商务小组退后一点从开头到结尾审视整个过程，并判断数字信息能如何帮助我们管理这
个复杂过程。
    一个管理方面的问题就是，经理是否从一开始就有权雇佣临时工。在我们的书面系统
里，没有办法来保证管理人员会审议招聘更多人力资源的最初决定，一旦决定了雇佣一个临
时工，经理们没有足够的信息来了解他们是否在遵循相关的业务规则。例如，该经理有干这
个工作的预算吗？该经理愿意给这个项目批准加班工资吗？此外，招聘经理无法容易地了解
到某项工作合适的小时工资是多少，或哪些有资格的人员能应聘。除非招聘经理心里已经有
一个具体的人选，否则我们就没有一种容易的办法来找出一种可能的资源，不管这个资源是
一家公司、一个介绍所介绍来的临时工，或是一个独立的承包者。我们为了正确的预算，需
要一种自动计算公开招聘全额成本的方法。我们决定我们需要一个新的灵活软件解决方案。
对每一个临时工，我们都必须保证他有一份公开写好并签名的合同。合同一旦被批准，那么
这个人的卡式钥匙、电话和上网权利必须在48小时内准备好。用户必须能够容易地创造相
似职务的多重相同申请，当您准备一个大项目的时候，这是一种典型的局势。当承包者工作
时，经理们需要一种简单的方法来确认工作时数、支付工资级别，以及在采购订单上的余
额。当合同终止日期临近时，招聘经理需要被自动警告。经理需要能自动地延长该临时工的
合同，但条件是预算还有剩余，而且这个人为微软公司工作的日子少于连续的340天。当终
止日期到达时，这个人上网、上电子邮件、使用公司电话和房屋的权利就必须停止。
    我们的新过程必须支持变动，但又不能阻碍工作。当一份合同准备妥当时，假如审批经
理不在，那么招聘经理则必须能够把合同转到另一个有审批权的人手里。假如在工作分派期
间内经理或成本中心有变动，我们就必须能容易地重新分配该项成本。职业介绍所应能自主
给临时工小额加薪，但是大幅度加薪则必须得到招聘经理的同意。

决定是否集中管理
    一种方法就是创建一个巨大的单一应用程序来处理所有这些需求，即所谓的“大程序
法”。我们有一次就这样设计过一个应用程序，是用来使我们内部的十几个服务组织——图
书馆、保安、饮食、出差、公司仓库、公司信用卡集团和其他组织等——能跟踪雇员请求并
做出反应的。最后这个项目是我们所取消的少数项目之一。各个群体的需要是很不相同的，
而商务规章又太复杂，一个应用程序处理不了。我们花了那么多的时间来使这个系统运转起
来，可等我们完成的时候，需求又改变了。我们接受了一个重要的教训：很少的公司应用程
序需要“集中”。我们让每个小组自由建立自己的申请系统。通过缩小解决方案的规模，我
们缩减了大量复杂性和开发时间，今天所有的内部服务小组都有自己的“申请”应用程序，
他们每隔几个月就改进一次。它们都是无纸过程的极好例子，这些过程节省时间，使得跟踪
优质服务的提供更容易。
    我们避免内部应用程序冗长的开发周期。太多的时间消耗往往使优势失效，而商务需求
同时又在发生改变。更小的、非集中的过程通常是最好的。只有少数的应用程序，例如我们
的财务报表系统，需要集中化。我们在承担了内部其他商务解决方案的同时，一直保持小规
模的小组和项目，心里记着我们生产开发小组的座右铭：“及时交货是我们的特色”。
    在检查对临时工的管理时，我们想避免一种单一的办法，但与此同时，又不要弄到未了
有六七种互不相干的应用程序，不能组合在一起来刨建一个总体解决方案。我们的战略就
是，创造一系列模块化应用程序，从开始设计的时候就准备把它们的数字数据互相链接起来。
    我们主要的工具就是Ms Market，即我们内联网上的公司采购应用程序；Ms Invoice，
即因特网或称外联网上的一个网址，它使我们的承包商和其他人能用电子方式递送发票；还
有我们的SAN系统，它处理所有的后台财务来往。由于我们已经有HeadTrax来管理人事，
我们就把它当用户界面来用，不管哪一个应用程序实际上在幕后“拥有密码”。用户只要简
单地在HeadTrax上点击某个特征，正确的应用程序就会开启。
    承包过程从Ms Market里的数字采购开始，我在第三章中已作过全面描述。创建。雇佣
和管理临时工的步骤与HeadTrax为管理正式员工的电子控制功能十分相似。MSInvoice是
便利于电子传送发票的，也提供控制功能来帮助招聘经理和销售商（译注：此处指提供临时
工的机构）不超过预算。在每一张发票上，招聘经理都有一个链接以查看采购订单上的余
额。销售商能看到他们的哪一份账单与哪一份发票匹配。假如一个销售商企图送交一份比采
购订单上的余额更大的发票，那么这份发票就会被拒绝。假如销售商给临时工涨薪，微软公
司的经理可以点击一个按钮来批准或拒绝。
    精明的读者也许想知道，我们为什么还要使用发票呢？不管是电子或其他形式的发票？
归根结底，制造业大户都能够完全取消发票了。典型的例子就是福特公司取消了存货材料订
购发票。当收货部收到了一批零件之后，经手人就在电脑上输入收到这批材料，开始自动给
卖方付款。制造商拿到了零件，供应商收到了付款。谁需要一份发票——即使是数字化发票？
    我们也用一种类似办法做过试验，但是在牵涉到服务而不是实际货物的地方发现了一些
差别。在制造业里，每个零件都有一个零件号。要创造与临时工的时间一对一的关系是更困
难的。因为您“接收”的是花在一个项目上的小时。没有一个另外的参考，即发票号码，销
售商要把一次电子付款与某个工人和某周联系起来是困难的。我们拭目以待，盼望着能为我
们的销售商所用的无发票服务付款系统。我们的大问题就是要把临时工过程完全数字化，以
便让所有的信息能轻易得到。
    一条经验法则就是，一个很差的过程会花掉工作本身所需时间的10倍。文献中的许多
例子都描述再设计如何把30天的过程减少到3天，或把10天的过程减少到1天。一个好的
过程会消除浪费的时间，而技术将会加快剩下的真正工作。但是这种改进并不是最重要的好
处。改进管理方对承包过程的监督，保证每个人都遵循招聘指导方针和预算，这些才是大的
商务利益。更重要的是，我们能把各行业工种的表现联系起来，而且保持与这些工人更好的
关系。

一步一步地改进
    要有所准备，以便试验新过程和技术解决方案。没人能预测一个新过程或新应用程序可
能出现的每一个差错或问题。员工们先要使用程序，然后他们和程序开发者才能决定什么真
正起作用，什么不起作用。用户一旦亲手用了以后，他们就肯定能看到扩展一个应用程序的
新方法。我们直到看到HeadTrax对正式职工起了作用，才意识到我们可以用它来处理临时
工的问题。我们直到看到HeadTrax用于人事变动很管用，才意识到我们可以加上跟踪历史
信息的功能，以便为预算目的比较逐年的人头变动。这个特征将是下一个版本的一部分。
    对于所有再设计项目，尤其是那些牵涉到技术的项目来说，复杂性都是它们的未日。据
《华尔街日报》的一篇文章所说，研究公司斯但迪国际集团1996年对360家公司的一次调
查发现，公司信息项目的42％都在完工前被放弃。据这篇文章说，复杂性通常是罪魁祸
首。文章把浪费称作“惊人的”，并补充说，“项目越大，它们就越频繁地失败，而且花费
更大。”①
    ①小贝尔纳·威索基、《拔掉插头：一些公司对昂贵的电脑失望，从而选择‘非筹
划’》，华尔街日报，1998年4月30日。
    只持续三四个月的项目的失败率却低得多。对于短期项目，您被迫做一些重要的取舍，
追使您做得更简单更集中。您最后的目标是可执行的。假如短期项目失败——由于种种原
因，少数确实会失败——您损失的时间和金钱也少得多。把您的开发小组撤出来搞另一个项
目，这在心理上也要容易承受得多，因为人们没有浪费一年的生命搞一个要被放弃的项目。
    即使那些累计要花好凡年的项目也可以分为一系列更小的项目，每个项目都有确定的核
查点。这样的办法使得项目能平行前进，并使您能享受到许多领域里更快的数字过程，即使
您在一两个领域里卡壳。美国第五大零售连锁店戴顿。哈德逊公司想缩短它1100家百货公
司的商品经营周期——即订购一件商品并将它放置到货架上所需的时间。该公司把每个商务
过程分解成互不关联的步骤——设计。颜色和纺织物的选择、销售商选择，等等。然后快速
地、独立地执行每个步骤。最后的数字过程链接在一起，从而
    把公司下属商店的家用物品进货周期从25天减少到不足10天——这些商店包括戴顿、
哈德逊、塔吉特、梅文和马歇尔·菲尔兹。
    一旦您的数字环境建立起来了，那么您承担的项目就会更成功。假如您的环境主要是纸
张，那么一个新的数字应用程序就会在正常的业务活动之外，而正常的学习应用程序的时间
就会显得非常麻烦，不值得去做。但是，如果您的环境是数字化的，您就将能够快速地普及
这个程序。您可以举债搞许多应用程序的培训。能够很娴熟地使用技术的工人在讲到新应用
程序需要怎样工作时也会很苛刻。一旦有几个成功的应用程序在给您工作了，员工们就会
说，嗨，为什么我们的员工总数系统不像我们的销售系统？我们在这里为什么不能从摘要数
据转到细节去？您意识到这里给员工安装一个电子警报会很容易吗？他们会让您知道您可以
容易地链结的其他应用程序或网页，而您最后就会有一个更完整的解决方案。
    您利用您现有的技术投资就可以花费很少的成本来创建新的数字应用程序，回报却是巨
大的。您已经需要电子邮件来做专门目的的通信。您需要进入万维网来搞到关于全世界的信
息。您需要外联网址来向顾客和合伙人推销自己，您需要内联网址来提供公司信息。为什么
不把这些技术用于每一个商务过程呢？利用技术和您现有雇员的专业知识吧。

拥有过程变化
    在我们1998年的第二次首席执行官高峰会议上，我们组建了一个由首席执行官和首席
信息经理组成的小组，探讨商务需求和技术的交叉作用。向小组成员提出的一个问题就是：
是什么引起了重大的技术故障？强生公司总裁拉尔夫·拉森说，“重大失败”最经常的原因
就是，实业家们干脆把大项目交给他们的信息技术部门或外部咨询公司，“然后就撒手不
管，因为这是很困难的活儿。”拉尔夫说：“绝对不能那么做。您所看到的所有成功都是因
为强有力的商务所有权，不是因为信息技术所有权，有强大的信息技术支持的商务所有权。
项目并不属于顾问或信息部门。项目不属于任何人，只属于企业所有人。”
    没有一个能把商务和技术连接起来的人的监督，就不可能正确地再设计一个利用技术的
过程。这个商务过程拥有者不必是最资深的人或在您的公司的商务部门里最懂技术的人。但
是这个人的确要懂得商务需要，懂得技术是如何在实际工作中被使用的。这个人必须在公司
里受到足够尊重才能让决策坚持下去。这个人最可能有真知的见，知道开发更新的、更简单
的过程，知道在商务和技术要求之间搞平衡。
    拉尔夫的答复得到该小组里首席信息官们的有力支持。阿尔科阿公司的首席执行官员帕
特里夏·希金斯说，她见到再设计项目超支严重的唯一一次，就是因为公司的商务部门没有
负起责来。她说：“绝不要简单地用新信息技术来代替老的商务过程，甚至替换遗留下的好
信息系统。始终要抓住机会来检查和提高过程的效率，问问自己您的业务优先项目是什
么。”许多公司发现，资金浪费来自这个事实：您不把您的过程当作新解决方案的一部分来
重做。您总是不可避免地要随后另请个人来再设计解决方案，使它们生效。
    谁该拥有再设计过程呢？今天做了最大努力或明天能得到最大好处的商界领袖，应该拥
有新过程的开发和支持新过程的技术。

    商务启示

    ◆从各种视角来解决过程问题，并利用技术来创建以前不可能有的流水线过程。周期性
地重新评价所有过程。
    ◆如果您重新设计过程来产生最佳的信息流，那么您就会解决重要的商务问题。
    ◆过程问题说到底就是简单化的问题：让最少的雇员从事最少的工作交换。
    ◆不仅仅是信息技术部门，而且商界领袖也必须拥有关于技术过程的决策。
    ◆一个低劣的过程会消耗掉工作本身所需时间的10倍。一个好的过程会排除掉浪费的
时间；技术会加快剩下的真正工作。
    ◆复杂性是一切再设计项目的未日．尤其是那些牵涉到技术的项目。

    诊断您的数字神经系统

    ◆您的数字系统能使初期解决方案快速实施吗？它能使其他分阶段改进工程快速执行
吗？它们能让每个雇员都很容易地跟踪系统现状吗？它们能使人们很容易地看到需要管理方
采取行动的趋势吗？
    ◆您能用几个独立的小过程建造一个大过程并把它们链接起来创建一个高效率的系统吗？
    ◆您在使用数字信息流来简化一个完整的过程吗？
    ◆您是通过创建更小的、分单元的、从开始就设计为交换数字信息的解决方案来避免长
久的开发周期吗？
    ------------------

其它文库首页