📄 018.htm
字号:
<HTML><HEAD><meta http-equiv="Content-Type" content="text/html; charset=GB2312"><TITLE>比尔·盖茨-->未来时速-->第十七章</TITLE>
<META NAME="keywords" CONTENT="比尔·盖茨 未来时速 第十七章">
<META NAME="description" CONTENT="比尔·盖茨 - 未来时速 - 第十七章">
<style>
<!--
#page {position:absolute; z-index:0; left:0px; top:0px}
.tt3 {font: 9pt/12pt "宋体"}
.tt2 {font: 12pt/15pt "宋体"}
a {text-decoration:none}
a:hover {color: blue;text-decoration:underline}
-->
</style>
</HEAD>
<body text="#000000" aLink=#9900ff link=#006699 vLink=#006699 bgcolor="#FFFFFF" leftmargin="3" topmargin="3" marginheight="3" marginwidth="3">
<TABLE WIDTH="100%" CELLPADDING=10 CELLSPACING=0 BORDER=0>
<TR>
<TD CLASS="tt3" VALIGN="top" width="8%" bgcolor="#e0e0e0"><strong><A HREF="019.htm">后一页</A><BR>
<A HREF="017.htm">前一页</A><BR>
<A HREF="index.html">回目录</A><BR>
<A HREF="../../../../index.htm">回首页</A><BR>
</strong>
</TD>
<TD class="tt2" bgcolor="#F5F8F8" width="84%"><center><FONT style="FONT-SIZE: 16.5pt" COLOR="#FF6666" FACE="楷体_GB2312"><B>第十七章</B></center></FONT>
<hr color="#EE9B73" size="1" width="94%">
<BR>
正如热门概念往往会引起的后果那样，哈墨和钱丕关于再设计过程的简单但深刻的概念，引发了一股商务研讨会、培训班、大学课程、杂志文章和各种专家出版“效颦”专著的热潮。①在这个过程（一语双关）中，各式各样的商务人员用“再设计”这个词来为几乎任何组织变动做辩解。两年以前，一家大电脑公司开始了“再设计”的努力，把人事部门大部分人都解雇了，没有留下人来合理地处理实际上裁员的后果。这家公司没有人事专家来指导变动，犯了一些错误。它买断了自由打工者的合同，在他们还没干更多工作之前就把他们打发走了——尽管公司已经支付了他们的服务费。新晋升的人本来很受赏识，现在却被解雇了，因为他们在现有等级上是资历最浅的。要把这种行为看作合理化裁员是很难的，而且也绝对不是再设计。迈克尔·哈墨在一次谈话中曾说：“有时再设计几乎是指任何事情，但绝对不是指再设计了。”尽管有些人对这个概念太过热心或利用它来掩饰裁员，但时不时地审视您的过程，使它们更有效，并把低效率排挤出去，这个想法现在却比以往更为重要。
<BR>
<FONT style="FONT-SIZE: 9pt">①1998年10月在因特网上对“再设计”一词的搜寻找出了189940个文件，内容从关于2000年日期计算问题的文章到一个被描述为“玩笑的严肃一面”的研讨班，无所不有。文件数目比其他重要的商务话题大得多——例如，比知识管理的话题多。</font>
<BR>
创建一个新过程是个重大项目。您应该有一个明确的成功定义，在时间和任务方面有明确的开端和结束，有中期成果和一个预算。最好的项目就是：员工们心里有清楚的顾
<BR>
客情况。这也运用于过程项目。顾客可能在公司外或在公司内，但是概念却是同样的：这个人将怎样使用您在开发的产品或过程？这个产品或过程比以前的那个好在哪里？
<BR>
您也需要在各个级别上理解交换。每个项目都有交换。在软件项目里，管理方总想要产品特征多样、小型，并且花费甚少、一夜之间就做好。经理们什么好处都想要，因此必须明白无误地理解交换。如果您善干把产品制作得特征多样，并不得不把它做大些，那么您就不想让管理方过后说，您本来应该牺牲几个特征，把产品做得小一点。如果您限制成本，那么您就不想让您管理方说您本来该花同样的成本但包括更多的特征。一个建造数字过程的项目也是同理。
<BR>
您面对着变化中的要求应该灵活应变，但又不应该缓慢地做修改以使原来的设计目标失效。您应该有果断的决策过程来评估变化，包括重新评价原来项目目标的规定。
<BR>
<BR>
<center><B><FONT COLOR="#CC33CC">更新产品交货过程</B></FONT></center>
<BR>
数年前，在准备妥当以便装载运输的那一天，一次WindowsNT的重要发货几乎被耽搁了。并不是因为畅销产品有缺陷或某种其他产品开发的问题，而是因为一只硬纸箱不见了。产品包装箱的艺术设计留在一个人的桌上，而那人又恰好在那天去度假了。艺术设计图一直在那里，直到箱子完工了还没能按期到达制造部。而离发货最后期限只剩两天了。但包装箱通常需要10天才能生产出来。制造部的操作工日夜加班才给我们生产了足够的箱子以便按期交货——箱子上的油墨都还没干。
<BR>
在这次事故之后，这个小组负责营销材料的经理把大家召集在一起分析毛病出在哪里。这个小组由12名员工组成，是来自公司内两个处和两个外部销售商的人员，经理提了一个问题——也是我在微软公司常提的一个普通问题——“为什么这个房间里有那么多人？”在任何会议上我只想要最重要的决策者参加。其他人都应该离开，去解决其他问题。如果您在房间里发现多于3～4名决策人，那么您就能肯定仅仅是这么多人数就是问题的一个主要部分。
<BR>
这个经理要求小组简化过程并找出该部门其他十几个产品类似的协调问题。“找出一个问题模式来，然后为全部产品解决这个问题。”他说。
<BR>
在短期里，小组建立了“肯定性承认”的原则，意思是，一次工作交接要等流程中的下一个人说：“我拿到了”才算完成。不能再盲目地把东西从门窗横档间扔过去了。
<BR>
这个小组还把交接的次数从5次减到3次。减少交接次数也许不像一个重大步骤，但任何消除“接触”的步骤都会减少犯错误的机会并有助于保证质量。1997年，在一家新工厂里，戴尔电脑公司重新设计了它的生产线，以便削减一半处理硬盘的次数。该公司制造部硬盘的退货率降低了40％，PC总故障率降低了20％。
<BR>
在微软公司，各部门负责把产品组件送到制造部去的人开始召开最佳作法会议。我们在爱尔兰制造销售给欧洲的产品，那里的高级经营主管乘飞机来谈美国惯例给她的公司带来的问题。我们随后找出了给制造准备材料时的一些过程问题。例如，有一次我们在产品包装箱上用了特殊字体，却没有意识到这种字体并不是在全世界都有的。这使得我们好几个产品都投放得晚了，没赶上在澳大利亚的假日消费季节。这就损害了盈利。
<BR>
所有部门的过程拥有者们聚在一起，给一个全球性生产过程下定义，这个过程将利用数字工具来改进协调。我们创造了一个应用程序来追踪所有产品组件，包括箱子、箱子上的标签、艺术设计和实际的软件编码。产品经理和其他雇员们有了网络上关于所有这些组件的信息，就可以容易地追踪他们制造过程的现状。我们有一个单独的、定义清楚的电子生产过程，它除了其他好处之外，还能保证我们在改进流程上的任何步骤，这些步骤会在整个公司里通用。
<BR>
在这个同样的时间框架里，我们也开始给公司的制造部搞外部采购原料。这一变革意味着我们必须给“交钥匙”制造方式提供完整的材料。过程必须更清楚——取决于过程，而不是取决于人。一个目标就是：“经营部不应该总是唱主角”。改进了内部协调的数字工具现在使得协调过程的最后阶段成为可能，即和一个外部制造商实际地制造这个产品。除了内部跟踪产品组件的应用程序外，我们还为销售商开发了另一个工具来断定产品组件的投放现状。销售商，包括外部制造商，也利用这个工具来下载数字材料并在电脑上订购非数字材料。在这里，我们的数字工具不仅使得我们能在内部处理过程问题，而且使得一家专营制造的公司能为我们承担新的工作。
<BR>
一个问题可能就是：我们为什么一开始要搞制造？在我们有数字过程前，我们别无选择。今天我们的信息工具足够先进，能让我们为制造部门搞外部采购，但仍能肯定我们的产品是按我们的规格制造的。我们在公司里保留一套核心专家班子，并把网络当做与外部专家协调的主要方式。
<BR>
在五六个月之后，这些小组不仅把已经引起问题的程序修理好了，而且还发现和拆除了其他几个尚未爆炸的不良程序的定时炸弹。新工具帮助辨认程序中潜在的冲突，并在冲突或遗漏发生之前就让所有的成员都合作解决问题。对一家企业来说，未出现的问题的价值该有多大？
<BR>
<BR>
<center><B><FONT COLOR="#CC33CC">创建分阶段解决问题的过程</B></FONT></center>
<BR>
一个叫做HeadTrax的内部用微软应用程序的开发史，就是个好例子，说明商务需求和技术问的共存关系如何起作用。使得前数字化世界里不可能有的新过程产生作用。HeadTrax是个工作流程应用程序，用于处理人事变化。一次人事变化可能指雇佣员工、晋升、调动或部门内的变动。
<BR>
我们开发HeadTrax的努力表明，有时需要一系列的重复性步骤来理解您想解决的问题，并选择正确的过程和技术。对目标理解不完整，是每个技术项目里令人担心的主要问题。这说明为什么您处理更小的过程并依赖它们发展时，运气要更好。不管您计划有多周密，您经常会发现您对用户的需求并不是完全理解。假如您花了18个月把一个完整的解决方案弄好并交货，却意识到您并没有把它搞对，或在这个期间内商务需求有了变化，那么您的处境就会很糟糕。一个更好的办法就是利用软件工具，它们能使您在不到6个月的时间里就做出能用的程序来，然后等您得到用户反馈后又可以改进解决方案。
<BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -