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