点击链接了解详情

作者介绍

前言

随着越来越多行业的企业开始关注敏捷，业务敏捷（Business Agility）成为一个新的热点。毕竟大部分的行业和组织与软件无关，但是依然要实现业务上的敏捷，所以这个系列会主要谈两点：

• 第一个是：“什么（What）是业务敏捷？”

• 第二个是：“如何（How）从业务架构角度切入业务敏捷？”

第二部分介绍从业务架构中最基础的部分 —— 价值流（value）与能力（capability），切入业务敏捷。这部分会结合一个案例 Air France KLM Cargo Procurement 来说明。

什么是业务敏捷

根据业界的主流观点，再结合自身的经验，我认为业务敏捷比较全面的定义如下：

“业务敏捷是一种组织级的方法，它能帮助业务快速响应市场内外部的变化。这样的组织广泛地应用了敏捷的原则，使得整个公司能够更快地响应变化，加快上市时间，同时在不牺牲质量的情况下降低不必要成本。”

所以，要衡量一个组织是否达到业务敏捷，有几个关键点 ——

1. 响应力（Responsiveness To Change）和上市时间（Time To Market）

这个词是衡量一个组织是否是业务敏捷的关键。首先，响应力意味着内部外的任何变化，组织都能感知到，都能做出必要的调整，这里的调整可能发生在组织内的各方面，不仅仅是业务或数字部门，也可能是 HR，财务，供应链，甚至是供应商。其次，业务敏捷的成果一定会体现在产品或服务上市时间的缩短。也就是说，如果组织内部的变化如果仅仅是降低成本，那么也不能称这个组织达成了业务敏捷。

2. 降低成本同时不牺牲质量

我们都知道要增强响应能力或缩短上市时间，传统地做法是加大资源投入。比如 VIP 客户可以设置专人服务，可以增设专门的服务通道，这样可以可以快速响应 VIP 客户的需求；又比如对于研发增加人手，对生产增加资源都可以一定程度的提升响应力和缩短上市时间。但这些并不是我们这里讨论的业务敏捷范围。

另一个加快 Time To Market 的方法是降低一定的质量，这种情况在软件与互联网行业尤其明显，第一个上市的产品为了抢时间，通常 bug 不断。背后的原因可能是需求分析时间不足，开发时间不足，测试时间不足等等。但通过降低质量与提高成本（相对行业平均）都不是我们所说的业务敏捷组织。

3. 广泛应用敏捷的原则

那么如何做呢？这里是所谓业务敏捷的基本原则，也就是组织内广泛地应用敏捷的 12 条原则（见下）。我把敏捷的 12 条原则做了稍许表述上的调整，以适应业务敏捷的场景，用“项目”和“产品”代替了“软件”。同时扩充了这里“设计”和“架构”的含义，不单指软件架构设计，可以是“产品设计”，“项目设计”，“产品架构”，“项目架构”等等。

在过往项目的落地过程中，我们发现这些原则完全可以适用各类组织，并且毫无违和。

当然要做到业务敏捷的效果，这绝不是一件容易的事情。麦肯锡曾做过一个研究，发现速度（speed）和稳定性（stability）在大部分的相互矛盾的。很多的组织如果一旦提升速度以后，它的 stability 就会下降，它的稳定性就不行了。既能做到又快又好又稳定的只有 12%的组织，即所谓的敏捷组织。

如何实现业务敏捷

所以业务敏捷其实没有那么容易做，甚至是一个组织各要素相互掣肘的过程，是个矛盾体，那我们要怎么做？

在回答这个问题前，给大家一个思考题，业务（Business）到底是个机器（machine）还是一个有机体（organism）？

曾经我看到过类似的问题是“组织是一部机器还是一个生命体？” 这两个类似的问题引发的思考是类似的。该问题背后实际上还有一个延伸问题，即“业务到底是怎么产生的？是严格地按照设计制造出来的，还是生长出来的？” 不同的答案会决定你所在组织的敏捷转型策略（strategy）、设计（desgin）和路线图（roadmap），这就是所谓的“顶层设计”。

我们回顾很多大组织的发展，例如苹果公司，从两个人的创业公司，到遍布全球的各种业务。在几十年的时间里，苹果公司至少发布了大大小小数十个系列的产品（见下图）。

同时你会发现，苹果公司伴随新产品新业务，都在调整组织，以符合它的业务需求，促进它的业务发展。而这些调整通常都发生在新产品新业务推向市场前（下表是苹果公司若干次重大变化）。

1984 年 Macintosh 发布，1985 年史蒂夫·乔布斯离开，产品与业务调整；

1997 年收购 NeXT，史蒂夫·乔布斯回归，大量产品被暂停，研发与发布 iMac；

2000 年产品战略调整，取消部分产品，聚焦发展 ipod 和 Mac 电脑。2001 年推出 iPod 获得重大成功；

2007 年发布 iphone，公司名称从苹果电脑公司改为苹果公司，战略调整；

2011 年史蒂夫·乔布斯离世，蒂姆·库克继任，组织进行重新调整；

2018 年收购芯片公司，2021 年开始包括 Mac 全面采用自研芯片。

.......

所以说，组织要发展某种业务，需要从上到下发生或大或小的重组，这些调整包括组织架构、资源、流程等等）。就好比任何一栋建筑，它都基本的架构，组织为了支撑某种业务，也需要某个架构支撑，也就是业务架构支撑。

从业务架构视角看业务

1.什么是业务架构

业务架构被定义为“企业的蓝图，提供对组织的共同理解，并用于协调战略目标和战术需求” —— 摘自《BIZBOK® Guide v11》

业务架构包含了从客户/用户，产品，战略，度量，政策等等，而要支持所有这些的基础部分离不开 4 个方面（见下图）包括“能力 Capability、信息 Information、价值流 Value Stream、组织 Orginization”。换句话说如果要进行敏捷转型，也离不开它们，我们今天重点谈 2 点，能力 capability 和价值流 value stream。

2.什么是能力

能力（Capability）是“企业为达到某种特定目的或结果而拥有的某种特别能力”。它定义了业务做了什么（what a business does），而不是业务为什么做某事。

下面的例子展示了为了完成某种业务，企业或组织需要具备的能力，这些能力还可以继续拆分。

Sample: Transportation Industry Level 1 Capability Map 摘自《BIZBOK® Guide v11》

3.什么是价值流

价值是组织一切活动的基础，价值流将利益相关方，以及价值项串联起来，最终形成价值主张。

摘录自《BIZBOK® Guide v11》

4.价值流（Value Stream）、能力（Capability）与业务敏捷

刚才我们已经提到所有的业务都需要有架构支撑，其中的基础就包括价值流（Value Stream）和能力（Capability）。** 而一切真正的业务敏捷转型，本质上都会重塑价值流，以及围绕价值流重新构建能力。 **

业务敏捷案例分析

我们先看一个相对简单的业务敏捷的案例，法航货运改变采购招标价值流实现局部业务敏捷的案例。

——注：本案例内容来自 Agile Business Consortium 社区，分析来自笔者

2018 年，法航货运急需一套新的业务预定系统来支撑它日益增长的门到门业务。这套系统能够显著帮助提升产出和控制成本，同时希望该系统在 6 个月内能部署上线。现有的团队来自多家供应商，而且没有足够的技能完成该项目。由此带来的挑战是必须在 6 周内完成最优供应商（即该供应商能够在非常挑战的时间表下交付该系统）的选择和合同。这一举动甚至可能会改变采购规则。

图片来自法航货运网站https://www.afklcargo.com/

1. 传统的采购流程

1）需求定义：明确系统开发的需求和目标。这包括与利益相关者共同讨论和确认。

2）市场调研：调查和评估市场上可用的供应商和系统解决方案。了解不同供应商的产品、技术、服务和价格，并对其能力和可靠性进行评估。

3）初步筛选：根据需求和市场调研的结果，对供应商进行初步筛选。这可以通过评估供应商的技术能力、经验、参考客户、财务稳定性等方面来进行。

4）发出请求：向初步筛选的供应商发出请求，要求他们提交详细的系统开发方案、实施计划和报价。这些请求通常以请求提案（Request for Proposal，RFP）的形式发送。

5）评估提案：对收到的供应商提案进行评估和比较。评估可以包括技术评估、解决方案评估、实施计划评估、价格评估以及与供应商的沟通和合作能力评估。

6）筛选供应商：基于提案评估的结果，选择最具合适的供应商。这可能涉及与供应商的面谈、演示或实验室测试等环节，以更全面地了解其能力和适应性。

7）合同谈判：与选定的供应商进行合同谈判，明确双方的责任、交付时间、付款条件、服务支持等方面的细节。确保合同条款符合预期并保护利益。

可以看到，这是一个长长的流程。所有的环节都可能需要反复的沟通，反复的确认。业务部门是需求方，但采购部门才是执行方，两方的诉求和优先级往往很难完全对齐。同时由于环节众多，仅仅是审批就可能走上数周甚至数月，带来的结果就是非常长的采购流程。

2.法航的敏捷解决方案

第一步: 建立一个跨职能的 LAP（Lean Agile Procurement）团队，包括所有在供应商遴选流程中有发言权的人，以及那些必须每天与未来团队一起工作的人=> 12 人。这是业务团队代表第一次参与到 IT 供应商采购过程中。

第二步: 通过一个为期半天的工作坊使 LAP 团队在共同目标上保持一致（对齐）。

第三步: 通过一个小时的网络研讨会，向四家预先选定的供应商介绍新的遴选流程。

第四步: 举办为期两天的“POCAthlon”选拔工作坊。所有四家供应商带着核心团队（将来真正与法航合作的人员，而不是售前或销售）参加工作坊，产出提案并决定价格。他们（共 45 人）聚集在阿姆斯特丹史基浦机场的一个绝佳地点（在货运调度设施的正上方）工作两天。其目的是通过与每个供应商共同创建提案来评估业务契合度，以及通过黑客马拉松式的团队工作来评估未来系统的棘手特性。

第五步: 选择获胜者。最终决定是在工作坊结束时向所有供应商宣布。

第六步: 启动项目，在供应商选择一周后，新的团队成立完毕。

在上述案例中，我们看到一个不寻常的采购价值流以及采购能力发生的变化。

价值流从原先的 7 个步骤转化成了 6 步，同时时间大大缩短。

原来的价值项并不是被取消了，而是被整合进入了新的价值项中。比如，由于组建了 LAP（Lean Agile Procurement）团队（包含了所有决策者），所以可以将原先的三个环节整合到单一环节，全部发生在 LAP 团队内部。

发出“邀请 RFP”，“评估提案”，“筛选供应商”等环节都被整合到了 POCathlon 环节中，时间也被缩短到了 2 天。

能力 Capability 变化：

新增：组建跨部门 LAP 团队能力 —— 需要能够打通各个部门的工作模式，将所有决策者聚集在一起加快协作和决策。

新增：POCAthlon 工作坊能力 —— 这其中不仅仅是供应商需要在 2 天的时间内拿出提案，同时法航的团队必须能与供应商进行共创，共同探索现有问题的解决方案。所以可以说最终的 proposal 不是供应商单独的产出，里面也结合了法航团队的能力和智慧。在 POCAthlon 期间，由于供应商参加的都是日后真正参加项目的团队成员，也给双方一个提前磨合的机会。供应商方案选择与团队选择相结合，比原先只看方案更加的全面和科学。

增强：与供应商基于互信，更紧密合作的能力 —— 工作坊期间所有 4 家优选供应商都需要带领真实的团队参加，都需要付出比传统方式更大的成本；同时法航也需要将更多内部系统的信息包括优缺点提前暴露；这些都需要更加互信的合作关系。

总结

由于不同行业，不同公司的业务差异很大，很难找到业务敏捷的标准路径。但是所有的企业最核心的部分是共同的，就是为客户交付价值。所以价值流，以及围绕价值流打造的能力是每个组织共同的视角。要实现业务敏捷，需要拥有价值流，以及背后的能力，再围绕第一部分谈及的业务敏捷的关键三个要素（见下），对其进行改造。

1）响应力（Responsiveness To Change）和上市时间（Time To Market）；

2）降低成本同时不牺牲质量；

3）广泛应用敏捷的原则。