让企业养成节约的习惯:精益产品和流程开发-第7章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
我推荐你用资源消耗时间进度图（见图23）这个工具，就像这个例子里，我们描述一个典型的、完整的产品开发流程时所用的一样。你也可以对其中的一部分工作分析其时间进度，如制造原型产品的工作。
图23资源消耗的时间进程图
横轴代表项目在发布之前的时间，以日期或其他时间单位，从小时到年。纵轴代表花费的工作量（资源消耗）。典型情况下，这里的单位是FTE（fulltime equivalent；相当于全职人员的工作量）。两个人工作，每人花1/2时间在一个项目上，花费的工作量是一个FTE。
你是否观察到由于工作负荷波动而导致的散乱失序？不同部门花在同一个项目上的资源分配不同，因此他们不得不努力跟上多个不同项目中不同的工作进度要求。如果一个项目没有跟上，那么干扰就可能没完没了。你可以在时间进度图上工作负荷发生剧烈变化的点上，标上一个散乱失序的标志，作为提醒。
如果你已经有了某种用图标绘制的流程图（如关键路径图、工序流程图或者工厂的价值流图），就运用它们去分析现有系统中的各种浪费。然而，你需要理解这些工具存在的问题：
这些图上通常没有显示资源的工作负荷，因此无法帮你实现均衡负荷或规划资源的功能。
这些图强迫你使用顺序思考的方式，一个在前一个在后的次序，不能反映开发活动实际进行的方式。实际上，顺序式思维正是我们想要努力避免的。
这些图强迫你采用通道化的思考方式，这个人得与那个人沟通，这一点也是我们想要避免的（在我们提倡的拉动系统中，知识是随处可得的）。
图24并行的资源消耗——时间进程图
当我们消除浪费和迈向精益开发系统的时候，顺序流程就变得并行了。并行流程（见图24）运行得更加平顺，更容易和其他流程相协调，结果是形成了更有效率的多途径沟通。
画出你的流程，识别浪费
你可以选择画出：
一个实例项目；
一个产品系列的通用流程；
流程的一部分，如“工程更改”的流程或者“模型和仿真”的流程。
根据你对流程的了解，画出一个时间进度图。例如，“工程更改”这样的小规模流程往往包括了很多散乱失序，体现为通道化的知识流动等。在图上把它们标注出来。当你学到更多浪费的时候，可以逐步在图上标出来，尤其是交接脱节、等待以及主观臆测等。
之后，标注其他的图表。将图表挂在各个部门，公布出来，并用它们去激发变革。
交接脱节
更深一步观察，什么是公司里最根本的浪费呢？最多的是交接脱节。
每当将知识、责任、行动和反馈分隔开时，就会出现交接脱节。交接脱节是一种灾难，因为它会导致决策人在没有足够知识的情况下做出可能无法实施的决策。
例如：你的公司里谁对项目盈利负责？他们是否具备需要的知识？他们是否有效地执行这些工作？他们是否从市场上得到有效的反馈？
许多公司里，只有总裁对开发的项目是否盈利负责。销售人员提出性能或规格要求，工程人员尽力满足和实现那些要求，项目经理管理项目，各职能部门的主管提供专门技能指导——但是，只有总裁对利润负责。
然而，总裁并不了解项目的技术细节，不会去执行关系到项目成败的具体工作。他也不会充分参与到来自市场和生产经验的学习中去。这样，公司就把知识、责任、行动和反馈分隔开了，因而造成了交接脱节，如图25所示。
图25交接脱节示意图
将这种情况与我在一个小型的专用设备设计公司里担任总裁、所有者以及总工程师的角色作对比：我要就项目的成功对客户负责（实际上，我的办公室就在客户的生产线边上）。从某种角度上说，我并不是业务方面的行家，但是我对各个方面都足够了解，包括系统设计的原则以及如何将各部分集成为一个有效的系统。我设计整个系统，包括选择人员去设计其中的子系统。我要对机器进行测试，观察它们在客户那里的使用情况。在这个反馈流程中，我学到了很多。在这个过程中，因为我个人的全程参与，所以几乎不存在交接脱节的情况。
为什么交接脱节有如此大的影响？因为，最好的老师，在最好的情况下，最多也只能将30％的知识传授给学生。因此，交接脱节意味着会有超过70％的知识在传授给执行人员的过程中丢失了。更糟糕的是，那些传统意义上做关键决策的负责人往往太忙了，以至于传授不到10％的知识。因此一般来讲，没有人有机会真正学到很多，人员的变换和责任的扩散也阻止了有效的反馈。
美国军队将知识、责任、行动和反馈结合起来
1973年，当我还是一个陆军少尉时，在贝宁堡的课堂里，军队教给我很多管理理论。我在自己的排里领导40个人，我学会了如何运用我的权威以及心理学的理论，设立奖惩制度，以此来激发下属的主动性。
幸运的是，当大家对越南战败的教训有进一步的了解后，军队也在改变。有人指出：士兵们愿意追随的上级是一个知道如何完成任务，而又能保存部属生命的领导者。那么，对于一个陆军排长来说，他需要知道什么？如何射击（这样他可以教授射击和保护部属）；如何去阅读地图；如何勘查地形以尽量保护部属不被敌人的子弹击中，并且有利于向敌人开火。而这些技能只能在战场上学到，一旦犯了错误会立刻暴露出来。简而言之，排长需要将知识、责任、行动以及反馈组合起来——如果他确实这样做了，他可以不必担心自己的权威。
让我们继续看几个交接脱节的例子：
让项目经理去负责执行由他人制定的规格。
在开发过程中撤换开发人员，而没有让他们自始至终参与。
将工程设计的工作划分为工程师、CAD操作员和分析员的不同工作。
让制造工程师对新产品的制造负责，却没有让他们与产品工程师就产品的可制造性有良好的沟通。
为什么会发生这些事？这是科学管理的本质所导致的：
一个人（经理）决定做什么（责任）。
另一个人（专家）制定做这件事的流程和规则（知识）。
第三个人（操作员）执行（行动）。
按同样的方法一直实施下去（“最好的方法”），并没有去学习反馈得来的信息。
科学管理制造了交接脱节！大多数公司运用的计划和控制开发活动的关键路径图，都围绕着开发人员必须完成的“任务”展开。这意味着开发人员需要负责完成的是“任务”，而不是盈利。图中用箭头将任务连接起来，责任从一个开发人员转移到另一个开发人员身上，因此也就造成了许多脱节。
交接脱节打造了一个真正的死结，它可以被称为传统公司里死结之母。一旦科学管理做出最初的破坏，大家就倾向于躲避责任和知识。为什么不呢？当你没有机会将知识用于工作，也不对结果负责（和信任）时，为什么还要费心学习？既没有知识和能力，却要负责实施，又有谁会想要承担这种责任呢？只有少数热衷于权威的人才会如此，因为传统管理理论把责任赋予了他们。但事实上，权威并不意味着能承担起责任，只有知识、行动和反馈才能做到。
我们可以在开发图上标注出交接脱节的浪费，如图26所示：
图26交接脱节示意图
预先研制后的交接脱节，因为预先研制选择了概念设计方案，而概念设计方案必须由产品开发来执行；
销售和确定规格与产品开发之间的交接脱节，因为产品开发必须执行由销售团队决定的规格；
产品开发和制造开发之间的交接脱节，因为制造工程必须实施产品开发确定的设计；
制造工程和工厂之间的交接脱节，因为工厂必须使用制造工程设计的系统。
于是，交接脱节导致了相互指责，这也是传统管理下的解决办法。指责式的管理——要求对问题的解释，采取行动重新定义问题，这样它们就变成了其他人的责任，并且需要报告、报告、再报告——将成为中层管理的主要活动。（精益开发的一个大的回报，是终结了这种“指责游戏”。）那些擅长于玩这种游戏的人升到了高层经理，更让这个流程永存不朽。许多公司都死于这种“顽疾”。
向交接脱节的浪费开战（1）
只要你追求精益开发，你就一直和交接脱节作战。现在，把你对这个问题的理解张贴在走廊里，传播给大家，在开发图上（时间进度图，或是现有的流程图）上用红色标出交接脱节的浪费，并将它张贴出来。对照以下的清单，如果你的公司也存在这种浪费，就请在前面的空格处打个钩。把你们自己的例子也添加到清单里，把它们也贴出来。
由不同的设计人员制定部件的形状和尺寸，分析并做决策，但制造工程却不能有效地约束产品设计。
项目经理不需要对利润和系统设计负责，而系统设计对利润的影响最大。
职能部门的经理不对项目经理负责。
人事系统没有追踪记录已被证实的技能、开发人员工作过的项目（以及每个人对项目的贡献以及项目的成功与否）。
在项目发布前，工厂没有很好地把握与项目开发人员的沟通。
由办公室职员组成的小组制定开发的流程，并强制执行。
“预先研制”选定了基本概念，产品工程师执行到生产过程。
销售部门、高级经理或者报价团队定下合同，而项目经理和其他团队成员必须执行它。
经理们为开发团队制定决策（如要达到什么样的规格）。
无用的信息
时间花到哪里去了？为什么开发人员花费到增值活动中的时间只有20％？
由于散乱失序，许多时间被花在寻找有用的信息上。更多的时间则由于交接脱节，而用于制造、寻找和接受无用的信息。
如果某条信息不能有助于对客户的了解或者其他集成工作，不能有助于创新，或者不能为一个好的决策提供基础，那么它就是无用的。无用的信息不能帮助改进营运价值流，但会被创造出来，是因为有人想要它。
交接脱节常常会引起无用信息的产生。开发人员拥有知识，实施具体的工作。经理们有责任，并需要信息以控制局面。一旦出现问题，经理们需要更多的信息。很多开发工作的目的反倒产生了那些无用的信息，目的只是使经理们相信局面仍在掌控之中，同时避免或转移可能的指责。
此类无用的信息有一些例子：
大多数以PPT形式做的演示报告。
进程报告：开发人员庄严地宣称，他们正在按照计划进度工作。
完全形式主义的FMEA（失败模式和效果分析），没有产生出新的知识。
还有一些无用信息的产生，是因为某些工作人员的喜好，而不是为了公司的盈利。例如：
有些工程师喜欢做一些没完没了的优化，对于这种情况甚至有一种说法：“�
