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