《精益产品与流程开发》连载十二
第三章 观察开发活动中的浪费（3/4）
交接脱节
该是观察得更深一些的时候了。什么是传统公司里最根本的浪费呢？
是交接脱节。
当将知识、责任、行动和反馈分隔开时，就会出现交接脱节。交接脱节是一种灾难，因为它会导致决策是由那些没有足够知识的人做出，以至于无法做出足够好的决策，或者决策根本无法实施。
例如：在你所在的公司里，谁对项目盈利与否负责？他们是否具备所需要的知识？他们是否实际执行这些工作？他们是否从市场上得到有效的反馈？
许多公司里，实际上只有总裁才对从开发项目中盈利与否负责。销售人员提出规格参数的要求，工程人员尽力满足和实现这些要求，项目经理管理项目，各职能部门的主管提供指导——但是只有总裁一个人对利润负责。然而，总裁并不了解项目的技术细节，不会去执行关系到项目成败的具体工作。他也不会充分参与到来自于市场和生产的经验的学习。这样，公司就把知识、责任、行动和反馈给分隔开了，这种方式就造成了交接脱节。
将这种情况与我在一个小型专用设备公司里的角色作对比，我是这家公司的总裁、所有者以及总工程师。我要就项目的成败对客户负责（实际上，它关系到我家的房子是否属于我）。从某种角度上说，我并非在业务的各个方面都是行家，但是我对各个方面都足够了解——关于系统设计的原则，以及如何将各部分集成为有效的系统。我要设计系统，包括选择人员去设计子系统。我测试机器，观察客户的使用情况。在这个反馈流程中，我学到了很多。而这个过程中不存在交接脱节的情况。
为什么交接脱节是如此有害？因为最好的老师在他们最好的时期，也只能将不到30%的知识真正传授给学生。因此，脱节意味着至少70%的知识在传授给执行人员过程中失去了。更糟糕的是，那些传统意义上对最关键决策负责的人往往太忙了，以至于他们甚至无法学到哪怕是10%的知识。因此一般来讲，没有人有机会真正学到很多，人员的变故和责任的扩散也阴止了有效的反馈。
让我们继续看几个脱节的例子：
- 让项目经理负责满足由其他人制定的规格。
- 在开发过程中让人员进进出出，而不是让他们自始至终参与。
- 将工程设计工作划分工程师、cad操作员和分析员。
- 让制造工程师对新产品的制造负责，而不教他们如何约束产品工程师使产品具有可制造性。
（图：第54页）
为什么会发生这样的事？科学管理的本质导致这种情况的发生：
- 一个人（经理）决定做什么（责任）。
- 另一个人（专家）制定做这件事的流程和规则（知识）。
- 第三个人（操作员）执行（行动）。
- 这会被按同样的方法一直实施下去（“最好的方法”），而没有反馈。
科学管理的原理就会导致制造交接脱节现象。大多数公司用来计划和控制开发活动的基本工具——关键路径图，也是如此。它围绕开发人员必须完成的“任务”而制定。这意味着开发人员需要负责任完成的是任务，而不是盈利。它用依赖关系箭头将各个任务连接起来——这些箭头代表着责任从一个开发人员转移到另一个开发人员身上。
交接脱节打造了一个真正的死结，它可以被称这为传统公司里的“死结之母”。一旦科学管理作出了最初的破坏，人们就开始积极地躲避责任和知识。为什么不呢？
美国军队的案例：将知识、责任、行动和反馈结合起来
1973年，当我还是一个新的陆军少尉时，在本宁堡军事基地的课堂里，军队教给我很多管理理论。我在自己的排里拥有领导40个人的权利，我学会了如何运用自己的权威和心理学理论去奖惩他们，以此来激发他们的主动性。
幸运的是，当越南战争战败的教训在其后几年里被了解后，军队也在改变。有人指出：士兵们愿意追随的是一个知道如何完成任务，同时又能保存尽可能多人的生命的领导者。那么，对于一个陆军排长来说，他需要知道什么？如何去射击（这样他可以教授射击，并保护自己）；如何去阅读地图；如何勘查地形，以知道在哪里能够保护自己的下属不被敌人的子弹击中，并且有利于向敌人开火。而这些技能只能在战场上学到，在战场上，错误会立刻被暴露出来。简而言之，排长需要将知识、责任、行动以及反馈组合起来——如果他确实这样做了，他可以不必担心自己的权威。
当你没有机会将知识实际用于工作，也不用对结果承担责任（和信用）时，为什么还要费心学习？还有，没有知识和能力去采取行动，却不得不去实施，又有谁会想要承担这种责任呢？只有那些热衷于权威的少数人会如此。传统理论将权威与责任联系在一起，但事实上，权威并不能使我们负起任何一项责任，只有知识、行动和反馈才能做到。
这样，交接脱节导致了指责，这也是传统管理的解决办法。指责管理——要求对问题的解释，采取行动重新定义问题，这样“问题”就成为了其他人的责任，并且报告、报告、再报告——将成为中层管理者们的主要活动。（精益开发带给中层管理者们的一个大回报，是终结了指责游戏。）那些最擅长于玩这种游戏的人升到了最高层，让这个过程永存不朽。许多公司就死于这种“顽疾”。
有两种浪费是与交接脱节相关的，分别是无用的信息和等待。让我们来看一下。动手做：向交接脱节开战
只要你追求精益开发，你就将一直和交接脱节作战。现在，要让更多人意识到这个问题的存在。将定义张贴在走廊里。在开发工作流程图上（时间进度图，或是现有的方框箭头式的流程图）上用红色将交接脱节浪费标识出来，并将它张贴出来。依次阅读以下清单，如果你的公司也存在这种浪费，就请在前面的空格处打个钩。加入你自己的例子。把它们也贴出来。 - 由不同的人分头去定义部件的几何尺寸、分析和做决策。制造工程不能有效地约束产品设计。
- 项目经理没有对利润和系统设计负责，而系统设计对利润的影响最大。
- 职能部门经理不需要对支持项目经理的工作负责。
- 人事记录系统不追踪记录这些事项：被证明了的技能，开发人员工作过的项目，他们对项目的贡献，以及项目的成功程度。
- 在产品正式发布前，工厂没有很好地派人参与到开发项目的团队中去。
- 由办公室职员组成的小组制定和强制实施产品开发的流程。
- “预先研制”部门选择了基本的概念设计方案，产品工程部门负责执行它，直到投入生产。
- 销售部门、高级经理，或者报价团队，定下了合同，而项目经理和团队必须执行合同。
- 经理们为开发团队制定决策（诸如，要达到什么样的规格）。
无用的信息
时间花到哪里去了？为什么开发人员花费到增加价值活动中的时间只有20%？许多时间被花在寻找有用的信息上，背后的原因是散乱失序。还有更多的时间被用于产生、寻找和接受无用的信息，背后的原因则是交接脱节。当信息不能帮助了解客户或者其他整合方面的事情，不能产生创新，不能为一个好的决策制定提供基础，那么它就是无用的。无用信息无助于改进营运价值流，它之所以被创造出来，只是因为有人想要它。
交接脱节导致了无用信息的产生。开发人员拥有知识，实施具体的工作。经理们承担着责任，并要求开发人员提供信息，以维持局面的“受控感”。一旦出现问题，经理们就要求提供更多信息。很多开发工作于是变成了产生信息，其目的仅仅是为了向经理们再次保证，或使经理们相信，或者避免或转移指责。
例如：
- 大多数powerpoint式的演示。
- 进程报告：开发人员庄严地宣称，他们正在按照计划进度工作。
完全形式主义的fmea（失败模式和效果分析），没有产生出新的知识。
有些无用信息之所以产生，是因为实施工作的人员的个人喜好，而不是为了改进盈利性。例如：
有些工程师喜欢做一些没完没了的优化，这引起了一种说法：“干掉工程师，然后发布产品”。
创造出的新产品并不比旧产品更加具有盈利性。（一名实际负责开发项目的经理问：“旧的控制电路已经能满足客户的要求时，你为什么还要设计一个新的呢？”工程师回答：“我已经设计过那个旧的了。”）
动手做：减少无用信息的浪费
最开始的一些步骤是比较容易的。只需要：
- 问问那些在工作中的开发人员，他们被要求提供哪些无用的信息？
- 应用在讨论散乱失序浪费时用过的流程图，来消除和替代那些被要求的信息。
- 引入新的管理概念和系统，使它们能真正起到本该起到的作用，这是最难的部分。
等待
大多数公司曾经不时地发生过这样的情况：某条产品线遇到太多的问题，以至于不得不运转得比平时快得多。于是，公司组建一支精干的团队，让他们放下各自的其它职责，不必担心是否遵照了标准流程，将他们搬到同一个地点；那么毫无疑问，必然会发生的是，这个团队的速度变成了平常的两倍。
但是这些公司发现，他们很难重复这个流程。一旦他们重新强调了标准流程，进展就会变慢。然而我们知道，丰田确实遵循一套标准（如果简单来说的话）的流程，并没有将所有人搬到一起，或者是让开发人员仅专注于单个项目，但在每个项目上丰田都能以两倍快的速度进行。
为什么会这样？因为标准的传统计划、组织和控制项目方法——pert、关键路径图（即使有时被修改为“关键链”方法）和阶段门方法（phase-gates）——引起了等待的浪费。顺序——在开始那件事之前先完成这件事——是它们共同的关键！所以，过去十年里一直在重复并行工程的口号，给大多数公司带来的好处其实相对很有限，这一点儿也不足为奇。因为那些工具本来就是与目标是背道而驰的！顺序在开发中并不能奏效！很难发现，开发工作中的某个上游工序必须在下游工序开始前完成。（下游工序经常不能在上游工序结束之前完成，但这又如何？）这是在产品开发和制造之间的一个重要差别，也是在开发和建筑之间的重要差别（pert图方法就是为类似建筑工程的环境而设计的）。顺序化思维创造了一个批量性的流程，在这样的流程里，所有关于一个特定种类的决策和学习都必须在某个时间里瞬时发生。
这： - 减慢了流程的速度，因为人们在开始前等待的时间比需要得更长。
- 创造了单方向而不是多方向的信息流动：上游工序不能从下游工序那里得到足够的信息输入。
- 上游工序的开发人员比下游工序拥有更多的权力，这导致了质量问题。
- 引起工作负荷的大幅波动，从而导致了散乱失序的浪费。
图（原书第59页）（自左至右：确定规格，系统设计，部件设计，制造设计）
这里举几个实践中的例子：
- 工程部门在开始设计之前，要等待规格确定。然而，规格难免会不合理。这些规格要求要么使设计工作变得非常困难，导致了成本和质量问题；要么无法利用到设计工作开始之后出现的机会。
- 制造工程在生产系统设计之前等待产品设计。于是，产品不得不按照老的制造系统的特点进行设计，某种程度上就像为了这个制造系统而设计一样，这阻止了产品和制造系统的联合创新和优化。
- 在等待制造工程确定制造系统之前，工厂不能参与其中。
- 供应商在开发流程的后期才被选择参与其中，这阻止了产品、子系统和供应商制造系统的联合创新和优化。
- 为了应对广泛变动的工作负荷，有些公司尝试用任务排程的方法来管理；有些公司甚至不去尝试。而这些任务排程，在墨水还没干的时候就被扔到了一边。
开发活动中有太多的不确定性了，因此，批量化导致了可怕的资源冲突。后面我们将会发现，精益开发的概念（也就是，以多套方案为基础的并行工程，以及拉动/流动的计划方式）使得相当大程度的并行工作、多方向信息流动以及均衡化的资源需求都成为可能。
顺序化的成功[此部分为新增加的内容]
一个公司里，发明项目的建议文件曾经需要等待长达6个月的时间来评估和做出结论。已提交的文件要累积到50件才安排一次批准，并作为一个批次来组织评审。而当对评审流程执行单件流方式时，耽搁的时间被缩短到两个星期以内。工程师们很高兴，因为他们能得到更快的反馈，这也使他们愿意提交更多的主意。此外，公司也能够更容易地“向前移动”，朝着正式地评审概念方案的重要步骤而前进。
动手做：减少等待的浪费
开始动手吧。举办跨职能部门的研讨会，问问大家他们做什么。在时间进度图上画出这些信息。问问他们为什么等待。不幸的是，真实的答案几乎总是“因为我非常忙，这件事目前还不算很糟糕。”你将需要拉动、流动以及节奏化的工具，来将你的公司从灾难模式中解脱出来。