
2.3 精益理论体系解读
本节将就精益理论体系进行说明和解读。
2.3.1 精益产生背景
精益的概念诞生于工业时代,此时工厂的大批量生产催生了任务分工,以及遵循标准操作规范和流程的生产协作关系。丰田公司成立于20世纪30年代,二战后,日本国内资源稀缺,因此丰田必须节约,使用有限的原料来生产汽车。在这个过程中,丰田发现不仅可以让负责生产制造的工程师贡献个人的体力来操作机器,还可以让他们了解生产的整体流程,并通过不断优化生产流程来节约成本,不断地进行产品创新和升级,生产出客户最想要的产品。由于全员参与改善与创新,到20世纪60年代,丰田的汽车销量已排名世界第一。丰田总结出来两个最根本的原则:尊重人和持续改进。随着全员参与创新和不断优化一线的操作流程,丰田创造出了丰田生产系统(Toyota Production System,简称为TPS),该生产系统获得了世界不同行业的认可。
TPS包括两大支柱:即时生产和自动化。即时生产(Just In Time,简称为JIT)要求每一个上游工序生产的零部件刚好满足下一步骤的生产需求。其原理是,当下游零部件用完时会自动发送信号,协调上一道工序供应商提供所需的零部件。这种方式虽然能解决积压库存而产生的浪费,但同时也带来了风险(当缺少某一个零部件时就会造成全面停工)。经过不懈的努力,丰田摸索出了行之有效的生产协调技术,并取得成功。甚至可以根据客户订单不断变化的需求来生产客户想要的产品。自动化的“动”字指的是人与机器的互动,丰田着眼于改善人与机器的工作方式,减少操作过程中的人与负荷的不均衡、搬运等不必要的浪费,并提出将品质保障前移,融入日常的生产和工作中,如果生产线上出现不合格产品,停下来第一时间修复,从而避免了残次品的产生。这两个方面是互补的,并由此实现了精益转型的最终目标:为企业及其客户创造价值。
2.3.2 精益IT及其原则
精益IT是精益生产和服务原则在IT环境下的延伸,在本质上与其他质量系统相似,兼顾效率和质量,还提供了实用性强的工具和方法。精益IT与其他方法的不同是,它同时关注人为因素,团队成员的行为和态度是成功的重要组成因素。鼓励组织中的每个人不断思考,关注如何优化IT组织为客户提供更多价值,而不是采用精英管理的思维,由少数人决定他们的工作习惯,这是一种深刻的文化和行为变革。这一变革对团队和组织提出了重大挑战,实施精益IT是一个持续和长期的过程,可能需要几年才能使精益思想成为组织内部的文化。
精益IT的实施原则如图2-10所示。

图2-10 精益IT的实施原则
1.从客户角度定义产品价值
价值是什么?从客户角度来说,价值就是客户想要某种产品或服务,并且愿意为其付费,可以称之为VOC(Voice of Customer,客户之声)。
谁是我们的客户呢?是使用IT服务的人还是购买IT产品的组织?他们都有可能是客户。例如,航空公司为其会员提供网络机票销售的服务平台,那么航空公司的会员是机票销售平台的真正用户(或者称之为终端客户),而航空公司是机票销售平台的客户。在精益中,这两种客户都可以定义产品和服务的价值,因此用户和客户细分是很重要的。要基于不同群体来收集用户和客户的需求和愿望,这对需求人员和产品经理提出了更高的要求:使用用户体验式设计技术(User experience,简称为UX),基于场景和用户角色的信息定义需求,以类似讲故事的方式描述,不断地关注最终客户的需求,获得他们的价值认可。随着时间的推移,客户的要求和愿望也会随着新的见解和期望的出现而改变。明确价值是什么,是进行价值流分析的第一步。
2.识别价值流
价值流指的是客户参与的、贯穿从产品或服务请求提出到服务交付全生命周期的所有任务和活动。无论是组织内部还是外部供应商,客户之间的信息沟通形成的信息流都是价值流的一部分,价值流还包括工作流和物料流。价值流改进需要具有跨职能的视角,从个人、工作组和部门局部优化的思维中抽离出来,从客户的角度系统地思考整体过程,分析IT开发活动中哪些是增值的,哪些是非增值的,具体说明如表2-2所示。
表2-2 增值、非增值、必要的非增值比较说明

我们要计算每个步骤的等待时间和周期,分析哪些是有价值的,哪些是无价值的。
软件开发价值流如图2-11所示,IT项目增值活动包括需求分析、架构设计、代码开发、测试与验收、系统部署/交付。非增值活动包括客户等待、业务审批、过度设计的架构、设计审批、开发人员在其他项目的活动、功能的过度实现、因需求产生的返工、修改Bug。

图2-11 软件开发价值流示例
由图2-12可知,软件开发流水线中存在大量浪费,真正对客户产生价值的活动占整体的比例很低。
设计软件开发价值流图的步骤如下。
● 明确改善目标,选择涉及的流程节点。
● 从用户视角梳理当前状态的价值流图。
● 观察并收集流程各个节点的输入、输出,以及执行活动时间和等待的时间。
● 分析价值流中有哪些浪费,如不必要的活动、任务和不必要的等待时间,计算有价值的流程节点所占的百分比。
● 分析收集的数据,找出影响流程价值、产生流程浪费等问题的根本原因。
● 绘制出改进后的流程图,从根本上解决问题。
● 制定一套改善措施。
3.保证价值流的流动性
为使价值传递,价值流必须具有流动性。这意味着价值流中的活动必须紧密编排,通过最少的中断和数量最少的在制品实现产品和服务的交付。在细化每个工作单元的过程中,一条生产线可以生产不同型号的产品,可以基于客户需求定制开发,从而减少批量生产交付的浪费(批量生产在跨越职能或不同阶段时会出现长时间的等待,批量的需求变更会带来更长时间的评审,形成在制品的积压,而这些都是浪费)。而流动效应能够确保在合适的时间、正确的地点,运用正确的技能,使用正确的输入提供满足客户要求的正确的输出。追求客户价值最大化,各部门之间保持服务或产品横向顺畅地流向消费者,是对组织结构的一种很大的优化。
4.拉动系统
客户的需求可能因为新的见解和期望而改变,由客户来触发价值流动是至关重要的,这就是拉动系统所要解决的问题。拉动系统基于订单或下游实际需求来决定流水线上游的生产过程,流水线中所有的步骤都是基于下游需求产生的,这就是拉动系统与推动系统(Push System)的区别,而推动系统一般基于计划和预测来减少延迟。比如,拉动系统下的服务,一般都是基于客户请求的,只有在客户下单时才开始产生“价值流动”,即客户驱动了产品或服务的生产。拉动系统实现了即时生产,自然减少了库存,也不会出现瓶颈。在拉动系统中,当接收到客户的订单时,产品流水线中的每一个环节都只完成这个订单的所需工作任务,这就是 DevOps 实践中所提倡的单件流。而传统的推动系统则通过上游进行生产,然后“推”给用户,这时库存很容易成为问题:库存过多造成浪费,库存不足容易导致供应能力不足。而诸如这样的问题在拉动系统中会得到良好地解决,因为在拉动系统中是由客户来触发价值流动的。
5.持续改进日臻完美
精益生产的目标是追求完美,持续改进直到接近“完美”,但这并不意味着需要实施多重质量控制,造成延误,而是意味着价值流中的每个角色必须知道自身的任务和相关的质量要求。完美的本质是第一次就把事情做对,这就需要不断提高交付价值的能力。保持透明有助于我们实现完美目标,因为透明能确保有用的反馈,这些反馈可以让我们发现不合格产品的问题所在,我们需要创造一个从错误中吸取教训并持续改进的氛围。提供更接近客户真正想要的产品的同时,追求高效,避免时间、空间、成本和缺陷修复的各种浪费。