友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
让企业养成节约的习惯:精益产品和流程开发-第2部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
首先，一个基本的问题是：开发活动的“产品”是什么？当我问这个问题时，开发人员给出了各种相互冲突和令人费解的答案。（我用“开发人员”这个词，意指任何参与开发过程的人：经理、工程师、造型以及工业设计师、程序员和项目经理们。）有些人说开发系统创造出图纸和分析，的确如此，但消费者们是否为此付钱？如果不是，那么开发有什么好处？有些人说开发系统创造产品，但我所买的所有产品都来自工厂，而非开发部门。（当然，对于少数只有单件的产品来说，开发和营运的价值流是合在一起的。）
难怪这些传统公司的开发工作做得不是很好，因为他们甚至不知道自己在努力开发什么！图11所示为开发活动和营运活动的关系。
图11开发活动与营运活动的关系
开发价值流的产出是营运价值流。营运价值流从供应商开始，经过工厂得到产品功能，然后到达消费者。营运价值流并非一开始就存在，是开发活动创造了它们。
开发价值流的客户是营运价值流，营运价值流从原材料供应商开始，通过工厂制造成产品，再交付到客户手中。如果没有开发过程，这些都不存在。开发过程中的绘图、分析和测试工作，只有在能创造出有质量的营运价值流时，才产生价值。因此，营运部门是开发价值流的主要客户。开发只是在营运部门向终端客户交付出满意的产品时，才有价值。
在传统开发体系中，营运部门处在整个图腾柱的最底端。市场营销部门制定出性能参数要求；产品工程部门设计出满足这些性能参数的产品；制造工程部提出如何制造这些产品；工厂则努力执行这些制造计划。整个过程中各方都抱怨下游做得不好。有时会听到这样的说法：“这真是个好的产品，但是制造部无法持续地、高质量地生产。”什么？！如果不能维持质量，让客户满意，怎么还能算是一个好产品？
txt小说上传分享
将营运部门变成你的客户（1）
向每个有必要听到的人解释：“在客户购买我们的产品之前，我们都不赚钱。开发部门存在的意义在于为营运价值流创造价值。营运部门是开发部门的客户。我们应该听取营运部门的意见，为营运部门服务，就像为外部的客户服务一样。”
一个好的开发价值流能持续一致地为营运价值流创造盈利。“等等！”你说，“不公平！如果我们的行业处于市场衰退之中怎么办？如果厂长是个白痴怎么办？你不能要求开发部门对那些事情负责！”
好吧，为了宽容地评估开发系统，不妨将注意力集中在“持续一致性”上。将所有项目的平均投资回报率与最好的一个项目做个对比，你往往会发现市场部门和营运部门有能力产生高投资回报，而现实中影响项目投资回报率的各种波动因素却源自开发部门。如果你处于一个开发项目之中时，那就试着将你的项目与行业里最好的项目比较。
评估开发绩效的工具
我们现在开始接触一些评估开发工作绩效的工具。大部分评估工具将以成对的方式介绍给大家：一个回顾性的工具供你认识过去的问题，一个前瞻性的工具供你做未来的决策。
1计划和实际的投资回报率
有很多方法可以计算项目的投资回报率（ROI）式（11）做了以下假设：所有的“投资”（工程、开发、设备成本）在项目开始时一起发生，所有的“收益”在项目结束时一起结束，利息不作复合计算。如果项目的生命周期超过1年，ROI将被计算到年度值。这些假设使得ROI比较保守。 ，这些方法的主要差别在于你是否将税收、利息率因素等考虑在内。
这里有一个简单的公式：
ROI＝收益－投资整个产品生命周期×投资（11）
式中，收益＝（整个产品生命周期中的销售量）×（价格－成本）；成本包括分摊到每件产品上的制造、运输、质量保证和销售佣金等费用；整个产品生命周期从项目开始计算，直到产品停止销售为止；投资包括工程和设备的成本。
更详尽的考虑因素包括支出和收入的时间、资金的成本、价格和成本的变化等。而更重要的是，估计整个产品生命周期里的销售量是件有学问的事。可以参考唐纳德G赖纳特森（Donald GReinertsen）的《管理设计工厂》（Managing the Design Factory），从中找到一些方法。
然而，无论你如何做，有三点是很重要的：
将开发成本当做一种投资。
将项目的ROI当做一个观察开发系统和指导决策的工具，而不是一个评估和奖励个人业绩的指标（实际上ROI可以用于开发人员的绩效评估）。
将ROI的模型做得简单些，以便于开发人员理解，且能用于日常工作中。
让我们详细地看一下这几点：
开发投资包括购买设备、设计工程成本、选择供应商的成本、工厂设备安装的成本以及销售成本（如果产品在制造出来之前就已经被预售的话）。不必去考虑太多不会影响决策的因素，这样可以使得模型简单些。国家的税法和“公认会计准则”将大多数的成本都视为当期费用，而不是投资。但是不管IRS（美国国税局）怎么说，它们确实是投资。如果不期望在未来获得回报，我们是不会做这些开发投入的。同样地，除非将开发活动的投入看做投资，否则将无法明智地管理产品开发。
将营运部门变成你的客户（2）
很多公司基于单位利润做决策，也就是销售价格减去制造成本，可能还包括设备折旧。但是，这样的决策没有考虑我们需要管理的产品开发活动的成本。
项目团队和开发经理们应该将项目的预期盈利能力作为在考虑产品特性、时间和资源分配时的首要决策工具。但不要为了产出一个高ROI值，或者“完成一个商业项目”而给开发团队施加压力。因为如果那样的话，他们将会屈从于评价指标的压力，反而使这一工具失去意义。
用预估的结果，作为开发过程中可能遇到问题的一种预警信号。要求项目团队成员找出预期利润低的根本原因，以改进预期的盈利能力。如果得出的ROI还是低的话，就应该取消该项目。（将已经花掉的钱当做沉没成本，当你做决策时必须忽略。）
在一个精益的企业里，我们希望员工看到自己工作的绩效，而不必去告诉他们应该做什么。很简单的是，天下通行的利润核算方法为我们创建了一个信息平台，引导大家去做正确的事。
既然如此，丰田的开发过程在创造盈利性的营运价值流方面表现得如何呢？实际上，年复一年，丰田在每辆车上赚取的钱都比任何竞争者要多。这是令人震惊的，因为：这些论断是作者在写作本书时的理解。
丰田公司的本土市场连续多年处于深度经济衰退之中，以至于除丰田和本田以外的所有日本汽车制造商都几乎破产。相比之下，丰田却在银行里存有大约400亿美元存款，比所有美国汽车公司存款的总和还多。
直到最近，丰田在大型皮卡和SUV（运动型多用途汽车）方面一直处于落后地位——这些车型比轿车的利润率要高。没有哪家美国汽车制造商在轿车上获得可观的利润，而对SUV和轻型卡车的热情，是过去几年里美国公司获得高利润率的原因。（在我写本书的时候，丰田已经引进Tundra（丰田坦途）进入了巨大的轻型卡车市场，并已在美国建立了工厂以避开贸易保护壁垒。过去这些年里，丰田在美国的销售额上升了16％，而美国汽车公司的销售额则下降了6％。）
整个汽车业都在努力复制丰田的精益制造系统，因此，丰田制造的优势正在下降。
但是，我们不能孤立地考虑ROI，一个公司可以为实现高的ROI根本不做投资。因此，一个更有效的前导性指标是市场份额。
2计划和实际的市场份额
丰田的开发系统除了持续地产生高利润外，相伴而行的是平稳地增加公司在世界市场的份额。丰田的主要供应商，以电装公司（Denso）为例，同样在维持高利润的同时，平稳地提高了在全球市场的份额。他们是如何做到的呢？
之所以获得高利润和市场份额成长，是因为他们的开发系统有较少的“不合格”项目。这里所说的“不合格”项目具体表现为：超过了时限或资金预算，有显著的质量或成本问题，或错失了市场机会。
运用项目的ROI和市场份额指标来管理开发活动
许多公司并不跟踪项目的ROI，这样你可能不得不粗略地估算工程投资。把ROI作为你在项目中或项目之间做投资决策时的首要指引。（不要只把目标对准可接受的最低ROI，而要一直跟踪、监测你的决策，以实现最大的ROI。）
丰田和供应商们对少数的没有达到目标的项目进行分析，并改进整个系统的项目以持续地保证成功。他们保持着高昂的士气，却少有混乱，导致项目持续一致地获得成功。
相比之下，大多数传统项目却有严重的问题，一个偶尔的本垒打（home run）棒球术语，是指击球员将对方来球击出后（通常击出外野护栏），击球员依次跑过一、二、三垒，并安全回到本垒的进攻方法。 使公司得以生存。救火是公司的典型状态。很难分辨出谁工作得好，更难分辨出问题的原因是什么。各种干扰从公司里四面而来，如项目被取消，资金或时间超出预算，或者必须加速前进以弥补其他方面的失败。所有员工一直都在担心。这样，我们又有了另外一个工具，如图12所示。
图12开发项目中的各种缺陷导致无法实现最高的ROI
项目缺陷率
如果在公司里能够消除项目的缺陷，你将会获得什么？重申一遍，你知道一个营运价值流——工厂、供应商和客户——设计得很好的话，它将能带来行业里最佳的项目盈利能力。项目ROI不佳是开发活动有问题的自然结果，而缺陷正是精益系统应该消除的。精益的开发流程应该将平均ROI移向这些传统项目的最佳ROI的水平。如果最佳项目获得20％的ROI，而平均水平只有5％，那么仅仅通过消除项目缺陷，你就应该能够提升盈利能力达4倍之多。
用项目缺陷率指标去激发变革（1）
明确你的项目缺陷率。画出你最近项目的ROI分布图，用不同的颜色标出有缺陷的和完全成功的项目。计算出如果所有项目都获得最高的ROI，应该能盈利多少。在内部媒体上将这个结果公布出来，或者在公司大厅里张贴出来，用它来激发精益开发的变革。
我需要在此强调一件事。改进系统以防止缺陷，并不意味着增加更多的测试、分析、批准、关卡，或者对系统的控制。这些措施将增加开发人员的工作量，目的是防止一个特定的问题再次发生。但基本的问题是：开发人员都已工作得非常辛苦，所以难免出错。改进系统应该意味着对开发人员更容易，而非更辛苦。图13所示为传统开发方式和精益开发方式项目的ROI对比。
图13传统开发方式和精益开发方式项目的ROI对比
为了评估你对精益开发方式消除缺陷项目的信心，让我们看看各种特定失败模式的数据吧。
错失市场机会。因为开发团队没有很好地理解客户，或者因为不具足够的创新性，市场机会被错失了。精益开发在创新方面的可靠数据，来自德尔福罗切斯特技术中心的一个团队，在专利申请量方面，该团队实现了传统开发模式的10倍。我们知道丰田有能力在满足市场需求的同时，实现非常强的创新：
丰田第一辆雷克萨斯（Lexus）轿车瞄准的是其从未涉及的豪华车市场，在全球市场却被公认为最好的汽车。
普锐斯（Prius）汽车的混合动力模式是过去一个世纪里汽车技术方面最大的创新。
电装公司（Denso）展示了创新方面不同寻常的能力。例如，一个电装团队设定了开发的目标：将散热器的重量减少50％，同时能够在同一台机器上制造各种尺寸的散热器芯体，他们成功了！
成本和质量问题。这些问题往往在制造的工厂和使用的现场发现，但是，原因通常是由于糟糕的开发工作导致的。我们知道：
丰田持续地拥有全球最好的品质。
电装公司从来没有发生过一次产品召回这是作者在写作本书时的理解。 。
当然，以新产品缺陷调查结果为指标来衡量的质量水平，大多与制造系统方面的原因有关，然而，部分也受到面向制造的设计（design for manufacturing，DFM）以及制造系统开发与产品开发集成程度的影响。但是，长期质量的问题则完全是由开发所决定的。这方面，即使是低成本的丰田产品也拥有突出的耐久性和可维护性。
时间和资金的预算超支。丰田员工告诉过我，他们从没有延误过一次产品发布的期限，尽管偶尔也调整过一两次！从第一辆车下线到全速量产，丰田通常仅允许花费两个星期时间来实现，而美国汽车制造商则可能需要6个月。丰田的项目总能以惊人的一贯性，在计划时间和资金预算范围内完成；美国的情况则没有这么理想，这也突显了传统方式的缺点。
我曾请所有共过事的开发团队对产品缺陷的概率做一个估算。运用传统方法，成功的概率几乎低于30％。经验显示，80％的传统项目经历过至少一次的严重缺陷。
于是我们有了另一个工具：
估计失败概率
下面这些估计是比较容易做的：
1如果可能的话，将整个系统分解成子系统或部件。
2识别每个子系统以及整体系统的失败模式。
3估计每个子系统的失败模式不导致整体项目失败（尽管子系统失败，但项目整体仍然成功）的概率。
用项目缺陷率指标去激发变革（2）
4将这些子系统概率乘起来，得到一个整体的成功概率。
举例
子系统和失败模式成功的概率
整个系统
部件不适合09
装配缺陷09
子系统A
客户不喜欢08
供应商延误了项目09
子系统B
不够周全08
总体成功的概率047
实际上，这个方法还高估了成功的概率，因为总会有一些失败模式没有被考虑进去。
开始运用估计的失败概率指标
让你的项目团队们使用估计的失败概率指标来指导行动和方案。他们通过使用多套方案为基础的并行工程，能够（并应该）将失败的概率降低到5％以下。（这些将在第3章探讨。）
你已经学习了评估系统的知识，现在可以更深一步对盈利不佳的原因进行分析了。
关注于创造知识价值
缺陷项目导致了较低的ROI和下降的市场份额，造成了错失市场机会，带来了制造成本或质量上的问题，或者超过了资金或时间的预算。但是，是什么原因导致了缺陷项目呢？
几乎所有的缺陷项目都是由于不能在正确的时间、正确的地点拥有正确的知识造成的。因此，可用的知识是开发活动创造出的基本价值。可用的知识能预防缺陷，取悦客户，创造出盈利的营运价值流。
可用的开发知识是由三种基本类型的学习创造的：
集成学习包括学习客户、供应商、合作伙伴以及产品的实际使用环境，它帮助我们理解如何将设计与各方面的需求集成到一起——其中最重要的便是客户的需要。
创新学习创造新的解决方案。
可行性学习使我们能在可能的、新的解决方案中做出更好的决策，避免成本和质量以及项目超出预算等问题。
正如我们将要在第3章中看到的，将学习和可行性集成的过程是一个非常关键的部分。公司花了大量人力、财力和物力将数据提炼成以“权衡曲线”的形式表达出来的可用知识，如图14所示。
图14可用的知识是开发活动创造的重要价值
随着可用知识的增加，设备投资的需求将会下降。精益企业将大部分的开发精力用于创造知识，只将较少部分用于创造硬件。对于可用知识的关注是精益开发的核心。本书第2章的重点是识别知识的浪费，第3章展示精益系统如何创造知识及其过程中的浪费，第4章则以一个学习的过程来探讨如何实施变革。
我们明白了价值是什么后，就可以问一个显而易见的问题了：我们的时间，有多少被用于创造价值？
开发人员将多少时间用于创造价值？
大多数美国工程师用了10％～30％的时间来创造价值，大多数经理则少于5％。开发人员喜欢那些创造价值的部分，经常因为厌倦时间被浪费在不创造价值的活动中而选择了退出，这是因为整个开发系统在浪费开发人员的
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！