我曾经试过将他们的意见综合成一个合乎逻辑的体系，然而当我在丰田公司描述这些概念时，丰田在日本和美国的员工的反应却截然不同。日本员工通常会说“第48张幻灯片上你说的做法X，现在我们已经改为Y了”，而美国员工则会告诉你“哦，现在我清楚了”。
精益开发比精益制造更精深、复杂，超越了传统的“并行工程”方法。实际上，丰田很少使用诸如实验设计、分布在不同地点但分工合作的团队、质量功能展开图表或面向制造的设计软件等并行工程方法。但总体来说，丰田的方式创造了非凡的成绩。正如我们在第1章将要看到的那样，丰田与其美国竞争对手相比，速度是他们的2倍，使用的资源是他们的一半，而盈利则比他们多一倍。
又好又快，并且更省——既然如此，为什么还会有人要按照其他方式做事呢？这是因为过去并没有从整体上去解读这个体系。
。 想看书来
为什么你需要这本书
许多美国公司曾经尝试过运用精益开发的方法，每一个美国汽车公司都研究过丰田的开发方法。莱克、我和我们的学生曾经为《哈佛商业评论》和《斯隆管理评论》写过文章，这些文章获得了新乡奖（Shingo Prize，源于美国的、有全球性影响的卓越经营大奖），并且被广泛地阅读。克莱斯勒公司曾经尝试应用以多套方案为基础的方法。美国三大汽车制造商都采用了丰田的项目管理方法。通用汽车公司曾尝试将工程工作“标准化”，他们相信这是模仿丰田的做法。然而，设计的质量有问题、项目的周期长、开发的成本高等问题依旧持续着，美国汽车公司的利润和市场份额仍然快速下降。
过去4年里，我曾与客户们一起工作；并取得了一些成功。但我一离开，传统系统似乎又悄悄地潜回来了。我们曾采用精益系统的一些工具，开始时行之有效（通常如此），但是，那些效果很快地又烟消云散了。
我认为这些失败源于大家并未理解整个系统，而且对那些片段式的工具应用也存在种种误解。例如，福特汽车公司和通用汽车公司都任命了重量级的项目负责人——“像丰田一样”——然而却没有理解为什么丰田的项目负责人首先必须有系统设计师的经验。所以，这些美国公司的项目经理们仅仅是公司官僚体系大机器上的另一个螺丝钉而已。
吉姆·勒克曼在德尔福汽车系统公司的罗切斯特技术中心领导了在丰田系统以外实施最成功的精益开发系统。对于前面说的那种先成功后失败的现象，他这样说：“除非你持续地散播‘精益’的病毒，否则组织的免疫系统迟早会将它排挤出去。”
本书的主旨是提供一个全面的精益开发系统的概念，而不再只是片面地实施精益开发工具，又被现有的系统绊倒，退回到传统的开发模式。你可以从精益开发系统里你最感兴趣的地方开始变革，坚持不懈。精益开发的成功秘诀就在于你坚持学习如何做得更好，永远如此！
在这个过程中，你需要放弃的知识和你需要学习到的一样多。举个例子说，在肯塔基州的丰田乔治城工厂（Toyota motor manufacturing，Kentucky，TMMK）的一个美国经理说：“我花了三年才停止对别人喊叫。”对别人喊叫是他之前一贯的做事方式，而且这种方式看似有效果，但丰田的管理方式却要求他停止这种做法，去学习应用完全不同的方法。
此刻，你和你的公司可能都没有意识到自身在精益开发上的欠缺，也就是说，并不知道自己不知道什么。当你读完这本书时，你将认识到自己的欠缺，发现自己必须学习的新知识。你将订出一个学习的计划，每次学习一个概念。经过一段时间的努力后，将会自觉地、慢慢地和小心地应用每一个概念。你将会在不知不觉中得心应手，然后继续学习更多的新概念，如图01所示。
图01学习是一个四阶段的螺旋式上升的过程
。 想看书来
这本书是如何组织的
第1章奠定基础，核心问题是“开发活动的价值是什么”。一旦我们明白开发的价值是什么，我们就可以设计出系统的其他部分。同时还提供给你一些方法去衡量目前的情况，并估计可以改进的地方。这些都有助于你证明精益开发改革的必要性（在你完成改革之前，你需要说服许多人）。
第2章介绍“知识浪费”。一旦你理解了传统开发中的浪费，你将更容易理解精益开发，并将会很渴望去实施。
第3章详细介绍了整个精益开发系统，让你能建立起愿景，也就是说，你希望你的开发系统将变成怎样？这是本书篇幅最长的一章。
第4章提供了进行变革的方法，避免精益开发变成另一个“月度项目”。
本书中有多处像下面一样的阴影文字框，是对读者的行动建议。
有阴影的文字框
框内是作者建议你应该做的事情，这些文字刻意写得简单明了，只要积极去做就好了，你将发现你能完成这个任务。不要试图一下子做完所有的事——但是我建议你在阅读时就建立一个行动计划，以便于一有可能时就付诸执行。
精益开发系统的确有效，它可以帮你赚钱而且让你聚焦于创造价值，而不是管理浪费，因此也非常有趣。一旦你理解了它，你就会发现其实这比传统方法要简单并直接得多。它建立在普遍适用的合理原则上，它适用于各种活动，从浪漫的艺术创作到残酷的军事战争。
让我们开始吧。
价值和绩效
开发系统能创造什么样的价值？你如何告诉别人自己的开发系统有多好？它可以变得多好？
在《精益思想》一书中，沃麦克和琼斯告诉我们，需要搞清楚“价值”是什么——客户真正想要的东西，并且聚焦于“价值流”——创造价值的一系列相互联系的活动。传统公司经常过于关注内部组织，以至于失去了对价值的关注，造成了许多浪费。精益的公司则关注其价值流，努力消除非增值的活动。这里，我们将关注两个价值流——开发价值流和营运价值流。
营运价值流包括将原材料转换成客户手中产品的所有活动，即在客户需要的时候生产出高质量的产品。如果某个活动能够将材料转变为客户愿意付钱的产品，就是创造价值。
开发价值流则包括了从识别一个商机到付诸制造的所有过程。
以下是本书第1章的观点概览：
开发价值流创造了营运价值流。营运部门是开发部门的主要客户。一个好的开发系统能创造出一个盈利的价值流。
开发活动创造出两种价值：制造系统和可用的知识。
开发系统的绩效可以通过三个方面来衡量：营运价值流的持续盈利能力、消耗的资源、产生可用知识的速度。
精益公司在这些方面都表现得更好，它们的开发活动进行得更好、更快、更可靠、成本更低。
创造盈利的营运价值流
首先，一个基本的问题是：开发活动的“产品”是什么？当我问这个问题时，开发人员给出了各种相互冲突和令人费解的答案。（我用“开发人员”这个词，意指任何参与开发过程的人：经理、工程师、造型以及工业设计师、程序员和项目经理们。）有些人说开发系统创造出图纸和分析，的确如此，但消费者们是否为此付钱？如果不是，那么开发有什么好处？有些人说开发系统创造产品，但我所买的所有产品都来自工厂，而非开发部门。（当然，对于少数只有单件的产品来说，开发和营运的价值流是合在一起的。）
难怪这些传统公司的开发工作做得不是很好，因为他们甚至不知道自己在努力开发什么！图11所示为开发活动和营运活动的关系。
图11开发活动与营运活动的关系
开发价值流的产出是营运价值流。营运价值流从供应商开始，经过工厂得到产品功能，然后到达消费者。营运价值流并非一开始就存在，是开发活动创造了它们。
开发价值流的客户是营运价值流，营运价值流从原材料供应商开始，通过工厂制造成产品，再交付到客户手中。如果没有开发过程，这些都不存在。开发过程中的绘图、分析和测试工作，只有在能创造出有质量的营运价值流时，才产生价值。因此，营运部门是开发价值流的主要客户。开发只是在营运部门向终端客户交付出满意的产品时，才有价值。
在传统开发体系中，营运部门处在整个图腾柱的最底端。市场营销部门制定出性能参数要求；产品工程部门设计出满足这些性能参数的产品；制造工程部提出如何制造这些产品；工厂则努力执行这些制造计划。整个过程中各方都抱怨下游做得不好。有时会听到这样的说法：“这真是个好的产品，但是制造部无法持续地、高质量地生产。”什么？！如果不能维持质量，让客户满意，怎么还能算是一个好产品？
txt小说上传分享
将营运部门变成你的客户（1）
向每个有必要听到的人解释：“在客户购买我们的产品之前，我们都不赚钱。开发部门存在的意义在于为营运价值流创造价值。营运部门是开发部门的客户。我们应该听取营运部门的意见，为营运部门服务，就像为外部的客户服务一样。”
一个好的开发价值流能持续一致地为营运价值流创造盈利。“等等！”你说，“不公平！如果我们的行业处于市场衰退之中怎么办？如果厂长是个白痴怎么办？你不能要求开发部门对那些事情负责！”
好吧，为了宽容地评估开发系统，不妨将注意力集中在“持续一致性”上。将所有项目的平均投资回报率与最好的一个项目做个对比，你往往会发现市场部门和营运部门有能力产生高投资回报，而现实中影响项目投资回报率的各种波动因素却源自开发部门。如果你处于一