明白了价值和浪费的概念，但改进应从何处入手？毕竟一个工厂里有太多的事情。父亲的办法是先从成品处开始观察，因为成品告诉了我们有多少产品流出这个车间，然后沿价值流逆向回溯，以发现瓶颈所在。这里的价值流指一个产品从概念到实际生产、从订单到交付的过程中所需要的全部活动，包括了增加价值的活动，也包括不增加价值的活动。沿价值流回溯时，经常能观察到瓶颈，瓶颈是整个加工过程中一个缓慢的步骤，因为它不能够满足下游工位的需要，所以在制品会在那里堆积，瓶颈是不能增加价值的一个标志。注意，这里父亲的操作与日常思维习惯相反，我们一般是习惯顺价值流从上往下去考虑问题，先进行需求分析、然后是设计编码、再是测试、最后是版本构建发布，而精益分析则先从版本构建发布开始观察问题，因为只有构建完交付给用户的软件功能块才真正是产生价值的地方。

逆价值流观察完整个工厂后，父亲请菲尔做出选择，请他决定改进从何处开始。菲尔的痛点在于"最主要的问题就是及时把STR型号的订单生产出来，为此我们需要把每周50件的产量扩充到100件”，由于一套STR设备需要四件断路器，也就是说他现在最希望的是工厂的断路器生产能力能由每天40个扩大到每天80个。虽然父亲已经看到工厂中需要改变的东西很多，但他认同改变一定要从某个点开始，所以，他必须在菲尔下定决心，选择这个切入点后，再从此处开启改进之旅。这个问题，在我们今年的敏捷推进过程中也遇到了，任何改进最怕的是一把抓，如果能集中力量从一个点出发，效果要好很多。但是现实中我们总是遇到想改进的东西太多，但资源又极为有限，不同人理解的敏捷及目标也不一致，结果稍不注意就发现实际操作中坑挖了不少，但离真正达成突破还有很远距离，这是值得我们深刻反思的。

菲尔选中改进点后，父亲告诉他，如果想卖更多的STR型产品又不增加固定成本的话， 需要通过提高质量、降低库存、缩短生产周期来提高生产率，也就是说，重点是三个目标数字：质量目标、库存目标（先考虑在制品库存）、生产率目标（断路器个数／人／天）:

质量目标关注生产线上的废品率，比起在客户那里发现的不合格产品数，生产过程中出现多少不合格品的数量更有价值，毕竟越靠近成品的下游工位发现不合格品，付出的代价越大。在这个问题上，追求的目标是零缺陷。这要求生产线上的每一个工人都先被训练能识别上一个工位传下来的不合格品，如果发现了就拒绝接受。为此，需要有将质量建立在系统内部的思想，保证当一个不合格品被发现的时候，不管是什么原因，流水线一定要尽早停下来调查。这个目标如果映射到软件企业中，那就是，比起泄露故障，我们更要关注软件开发过程中内部发现的故障，而且要把质量意识建立在整个开发过程中，而不仅仅是测试处。为了提早发现故障，我们需要有持续集成（CI）系统，并且把该系统和代码审查、各级自动化测试工具连起来，并且要有严格的CI纪律，一旦CI失败，要禁止所有人再签入代码，直到问题解决（此规定是为了避免一些深层次问题被掩盖，后面章节会提到）。

生产率目标关注每个工人每天能生产多少件成品。为提高这个值，需要尽量降低生产周期。这里的生产周期指一件产品从生产开始到生产结束（交付出去）所需要花的时间，计算公式为“周期 ＝ 全部在制品库存 ／ 生产率”.比如，菲尔的工厂中发现生产线上有147个完成的和未完成的断路器库存，而工厂每天大约生产40个断路器，那么装配每一个断路器大概需要的3.7天，也即大约30个工作小时。这和单个断路器的装配时间（约45分钟）相比，价值增加比率极为低下。最理想的情况下，整个生产以单件流方式进行，才可能得到最短的生产周期。比如：一个完整的断路器装配需要45分钟，现在把装配工作分给生产线上的6个工人依序完成，假如每个人工作的任务划分比较均衡，则每个工人的加工时间为8分钟。在按单件流方式生产时，每个工人一次只处理一个零件，那么单个断路器的装配周期就是45分钟；但如果每个工人都是成组的干手上的活，每组包括5个零件，那么在一个工人每次加工1个零件时，其余4个零件会处于等待状态，也即每个工人需要花5*8=40分钟才会把这批零件交到下一个人手上，这样最终下来，每个断路器的实际装配周期将变成40*6=240分钟。这点在软件开发上的意义和制造业是一样的，理想情况下，最好也是单件流，同一时候，每个人手里只做一件事，但软件开发中单件流的威力要发挥，需要解决版本发布问题（版本发布类似于一次交付一组货物），只有做到持续交付，才能形成最短的生产周期（后文章节还会提到）。曾经我统计过一段时间团队需求的生产周期，结果发现，如果以需求规划开始算，到新功能版本发布为生产周期，开发人员投入时间是以3至5天算，而开发周期则是以1至2月算；如果以用户需求提交开始算起点，到新功能版本正式发布为生产周期，则周期更是长达1至6月。这正是为什么开发团队觉得自己已经很卖力，而外面总觉得这边交付速度太慢，两种感觉差异的由来。这个现象在大卫安德森《看板方法》一书开头举的那个微软案例中也有提及。对此问题的解决，目前我们更多是采用特殊补丁方式，即对于外面很紧急的功能，特别安排临时补丁，开发一完成后，就立即通过补丁方式外发，以缩短周期，但是，补丁安排毕竟只是应急流程，当应急流程成为常态，也会对正常的开发流程产生冲击，所以，如何探寻更好的解决办法，很值得我们研究。

库存目标虽然从长远看，是是要降低所有库存，但前期来说，更关注在制品库存的降低。在制品库存多，至少暗示了如下几个问题。一者，在制品多意味着更长的周期时间，这点前文已通过周期公式和单件流案例加以说明，不再赘叙。二者，在制品多，说明作业流程不平衡，我们需要做的是尽量消除这种不平衡，而不是认可这种不平衡，而任由库存增加。比如，A和B两个工位，A在B的上游，A每小时生产10个零件，B每小时使用5个零件，则A和B的工作之间存在不平衡，如果我们不去设法消除这个不平衡，当A和B都全力工作时，在制品库存就会在A处堆积起来。这点在软件开发中的常见案例为，比如A是开发，B是测试，由于软件团队中往往是开发人数远大于测试人数，于是测试经常来不及测试开发完成的功能，这时候如果置之不理，则导致大量开发完毕的功能无法对外发布；如果放任未测试过的功能对外发布，就是降低了质量目标，将来会付出更大的代价。所以，这时候合理的做法就是让开发介入测试工作，以消除不平衡，而不能放任开发对测试不管不顾，又去忙着领新需求。三者，在制品库存多，还意味着存在质量风险，因为太多库存存在，当后面工位工人发现问题时，很难判断是什么原因导致这个问题。这就好比开发一个功能马上测试一个功能（或者CI系统在开发人员小步提交代码后立即触发检查），这时候发现的问题就很好定位，因为存在问题风险的代码量很少，定位原因也快。如果等到开发都做了十几个功能后再进行测试（或者CI两次检查间已经有成百上千行代码提交—对应CI运行速度太低或者开发不习惯原子提交，而是累积大量代码后再一次提交），问题的定位和原因检查代价就大多了。

目标方向制定后，就要考虑具体的细化，后面，父亲将从节拍时间入手引导菲尔的工厂进行深入改善探索，这些将在下一篇读书笔记中继续探讨。

大家可能会问，成本为什么不是目标？父亲的回答是，在忧虑成本之前，应先找到赚钱的方式。首先需要控制交货期（因为客户满意永远是第一位要求），在保证交货的前提下再开始减少库存。在库存能控制时才开始处理成本问题。处理成本时一定要搞清楚哪些成本可以节约，哪些不能碰。毕竟我们要做的是节约成本，而不是削减成本。这一点在制约法理论（TOC）经典的《目标》一书中也有过类似提法，在成本的世界和有效产出的世界中，改善所追求的应该是有效产出上升，而不是单纯的降低成本。这个话题说来话长，这里就不继续分析了。