为什么业务与IT必须融合，走向业务敏捷！

自从2001年敏捷宣言诞生以来，敏捷在全球的发展非常迅速，敏捷在很多国家的科技企业已经普遍应用。但遗憾的是，很多科技企业对于敏捷的应用仍旧局限于IT团队，没有将敏捷转型的范围突破拓展到对客户交付价值的全部环节，导致是IT团队与业务之间仍旧存在巨大的协作鸿沟：一方面，即使业务部门具备快速感知市场变化和新兴机遇的能力，也无力借助IT的力量迅速响应外界的机遇；另一方面，IT团队交付的产品与客户的真实需求之间经常出现不吻合的情况。

业务部门

图：业务与IT的鸿沟

下图是一个典型的产品全价值链示意图，团队在深入洞察用户和研究市场后诞生产品的创意，之后经过了产品定义→需求分析→产品设计→开发→测试→部署→上线的环节。在产品上线后，用户使用产品，提出反馈意见。用户的反馈可能是关于产品新功能的创意，也可能是对已经上线的功能的优化意见。团队将用户的反馈意见转换为需求后，继续进入产品的价值链流动。

图：产品的全价值链(Full value chain)

当前在大部分企业里，敏捷转型只是覆盖到了整个价值链的研发环节，如图1-5中的从开发到测试之间的环节。

案例

某家位于深圳的中国民营科技企业是世界知名独角兽企业，公司员工上万人，其IT部门承担了全公司绝大部分的数字化系统建设，包括HR、财务、工厂生产、销售、采购、公司电商平台等。IT部门的最高领导者迫于提高效率和应对业务变化的压力，在IT部门开展了敏捷转型。但是，IT部门的业务方，也就是IT系统的需求方不在部门内部，而是遍布在HR、财务、工厂、销售、采购、电商业务等各个部门。IT部门经过敏捷转型，研发效率有明显的提升，IT系统的上线速度加快，质量也更加稳定，各业务方对IT部门的满意度提高。但是，从整个公司的范围内仍旧不能解决以下问题： ●     交付的一些数字化产品没有客户价值，导致产品最终以失败告终 ●     对用户使用数字化产品的情况掌握不足，导致很多时候在闭门造车做产品 ●     企业内部需求传递环节多，导致企业对用户的需求响应周期长，上线后的功能与用户的诉求有较大偏差。 ●     业务方与IT部门有极深的部门壁垒，造成严重的协作问题，比如，业务方经常抱怨IT部门效率低、质量差，需求开发慢；IT部门抱怨业务方需求不清晰、需求变化多，没有价值排序等等。 产生以上问题的根本原因是，该企业只在IT部门开展了敏捷转型，而IT部门本身只能控制产品价值链的交付环节，用户研究、产品定义、产品设计、用户运营等环节不在IT部门内。在这种情况下，不论IT部门自身的敏捷转型做得有多好，其上游、下游、及其他合作团队仍旧按照原有的方式运作。由于各个部门有自己的利益，组织结构的壁垒没有打破，因而从整个组织来看，其对用户和市场的响应仍旧有很大的提升空间。

这些问题多年来一直存在，但是在IT信息化时代，并没有引起足够的重视，，直到数字化时代和敏捷的到来才引起重视，我认为原因有二，也欢迎同学留言探讨：

1. 时代迁移。做IT系统的思维与以做数字化产品的思维有很大不同。打造客户喜爱的数字化产品赋能企业的业务发展，需要以客户为中心，洞察客户场景，理解客户需求，并且快速响应客户和市场的变化。这个诉求随着数字化时代的到来愈加迫切。

2. 根据约束理论，每个系统都有一个或多个瓶颈，整个系统的能力取决于瓶颈，不取决于其他环节。在IT部门开始敏捷之前，IT采用瀑布开发模式，IT系统交付周期漫长，系统的瓶颈在IT，而当IT敏捷之后，业务方仍旧按照瀑布的模式提需求和验收产品，因此系统的瓶。

近些年来，无数企业和上面的案例一样，在IT部门或研发团队内部开展了轰轰烈烈的敏捷转型运动，产生了效率提升的初步效果。但是即便如此，从市场的视角来看，企业对用户需求的变化和市场机遇的响应能力并没有显著增强。

系统思考学告诉我们：只要不触动系统的内在连接和总目标，即使替换掉所有的要素，系统也会保持不变，或者只是发生缓慢的变化。因此，只在某一些环节优化，其结果对这些植入改善的环节有了一定的优化作用，但是这点优化效果对于整个系统来说，并不明显。从另一个角度看，由于与改善的环节相互作用的其他环节没有变化，导致被改善的环节的优化作用不能够做到最优。

因此，对于企业来说，如果你想通过IT打造客户喜爱的数字化产品，从而赋能企业的业务发展，而不只是为了做系统而做IT，只在IT导入敏捷是远远不够的，必须对从用户端洞察到需求，到交付给用户，并获取到用户反馈的全价值链当作一个整体应用敏捷思想，让PDCA（Plan-Do-Check-Act)循环在每个环节持续运转，才能够让组织具备快速响应市场需求和新兴机遇的能力。这正是业务敏捷得以取得成效的核心。

图：戴明PDCA环

后续文章介绍业务与IT融合，走向业务敏捷的四条路径。