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