业务架构设计：价值流与业务能力

Posted 2023-04-05 老罗-Mason

一、价值流

价值流是TOGAF业务架构中核心概念之一。 

01 价值是商业模式的核心 

业务架构中价值的概念是非常宽泛的，是指某物是有用的、能带来利益的、能满足诉求的，而不是仅指某物的货币价值。 

商业模式描述的是企业是怎么赚钱。企业存在的核心在于为客户提供价值，即其价值主张。企业通过为客户提供价值来赚取利润。 

02 价值流是业务架构的价值分析方法 

价值流是对企业创造价值方式的描述，是业务架构的价值分析方法。 

业务架构中的价值流不同于价值链、价值网络和精益价值流等类似提法的工具。事实上业务架构价值流主要是借鉴了价值链的思路，主要改变有二：一是不只是关注经济价值的增加，而是关注特定利益相关者（比如客户）需求的满足，关注价值的创造、获取和交付，是一个端到端的视角；二是只关注主价值链的内容，舍弃了支持活动。事实上在埃森哲的方法中将这种工具称为Prime Value Chain Analysis（PVCS）。 

到这里我们应该给出业务架构价值流的定义。业务架构价值流是一个端到端的增值活动集合，为客户、利益相关者或最终用户创造整体结果。这些增值活动由价值流阶段表示，每个阶段都会为利益相关者，创造和增加从一个阶段到下一个阶段的价值。 

 一条价值流为特定利益相关者创造和交付一定的价值。业务架构价值流的组成要素包括：名称、描述、利益相关者和价值。 

以图1获取零售商品价值流为例，分为广告渠道、展示商品、促成选择、付款流程和交付商品等五个价值阶段，每个价值阶段都提供一定增值，比如展示商品是告诉客户有这样的商品，促成选择是促使客户选择该商品，但对客户来说都不是提供了完整的价值。只有完整了整个价值流的所有步骤，客户才会得到商品，从而满足客户的需求，向提供完整的价值。 

价值流是一个较为宏观视角的工具，便于审视企业为特定利益相关者创造价值的一系列活动。相比于价值流，业务流程过于细致，偏重于对运营模式的描述。运营模式描述的是企业怎么运作，是企业运用人力、财务、技术各种资源完成营销、销售、生产、交付等各种经营活动的过程。 

03 业务架构价值流与其他业务架构概念的关系 

1.价值流的分解

价值流可以分解为多个价值流阶段，每个价值流阶段都是一个增值活动，都给利益相关者带来价值的增加。 

2.价值流与业务能力 

业务能力为价值流提供支撑，每个价值流阶段由一个或多个业务能力支持。下图就是价值流和业务能力的映射关系的示例。下图是员工招聘价值流，分为定义岗位、沟通岗位、评估回应、面试候选人和入职员工五个价值阶段，提供的价值是满足用户部门的用人需求。以沟通岗位这个价值阶段为例，涉及到人力资源管理和财务管理的相关业务能力，比如确定该岗位的编制和薪酬成本等。  

进一步通过热力图可以分析业务能力现状与价值流对业务能力要求之间的差距。 

价值流和业务能力是业务架构最重要的两个产出。 

3.价值流与业务流程

价值阶段进一步落实到运营层面，就细化为业务流程。一个价值阶段可以对应一个或多个业务流程。 

价值流相当于企业的业务用例，聚焦于价值的创造、获取和交付本身，屏蔽了价值流如何实现的细节，因而更加稳定。如果企业的商业模式不变化，则价值流也不会变化。 

业务流程是价值流的在运营层面的具体实现方式。业务流程每三到五年都需要根据组织架构的调整、技术的革新变化等进行流程再造和优化工作。 

事实上，价值流-价值阶段-业务流程可以构成三级流程架构的基本框架。

二、业务能力

业务能力（Business Capability）是TOGAF业务架构的核心概念。 

01 什么是业务能力？ 

在TOGAF中，能力（capability）被定义为 “做某事的能力”。业务能力表示业务执行某些操作的能力。 

定义业务能力包括识别和描述该业务需要完成什么来支持其总体任务。定义业务能力的第一步是命名，通常用复合名词来表示，比如“战略规划”、“保单承保”、“信贷审批”等。定义业务能力的第二步是用一句话来描述业务能力。业务能力的描述不需要说明事情需要在多大程度上完成，只是表明业务能力的存在是有需要的。比如，“信贷审批”可以描述为“对贷款申请进行风险判断以决定是否接受的能力”。 

业务能力是粗粒度的概念，角色、流程、信息和工具的组合可以实现业务能力，业务能力的构建是为了关注业务的行为。关键的区别在于，业务能力的组件会定期更改，但业务能力将在更长的时间跨度内持续。比如，同样是“信贷审批”能力，过去是信贷审批人员（角色）人工审批（流程），现在大量的小额信贷可以由信贷系统（角色）通过审批模型（工具）自动审批（流程），角色、流程、信息、工具都发生了变化，但这个业务能力还是存在的，核心的信息也长期存在。 

02 什么是业务能力模型？ 

业务能力模型是业务能力的集合，用于描绘一组完整的、稳定的业务能力，这些能力涵盖了相关的业务和组织，代表了企业运行其业务所拥有的全部能力。建模过程的最终产出物通常是一个业务能力地图（Business Capability Map）。 

一个组织通常有很多个业务能力，业务能力的层次、颗粒度都不太一样。为了便于整体审视业务能力，并针对不同的利益相关者呈现，可以将业务能力进行分层分级。 

分层方面，一般是将业务能力分为战略、核心业务和支持三类。这方面应该是借鉴和继承了IBMCBM组件化业务模型方法。顶层，通常是与战略执行相关的业务能力，比如业务规划、市场规划、资本管理、风险偏好管理等。中间层表示核心业务操作、与面向客户提供服务直接有关的能力，比如保单承保、内部评级、保费缴纳等。底层是为中间层提供支撑，但不直接参与对客服务的能力，比如人力资源管理、财务管理、采购管理、信息技术管理等。IT也是一种业务能力，需要放到业务能力地图里。 

 分级方面，可以将一级能力向下持续分解到3-6级，具体根据组织的业务复杂程度来确定。一般它在适当的分解级别上提供所有业务能力的可视化描述（或蓝图）。不同的利益相关者对业务能力的关注的颗粒度是不一样的，高层管理者可能看1-2级能力就可以了，中层管理者可能要关注到3-4级能力，到具体执行层面就是掌握具体的5-6级能力了。 

03 为什么需要业务能力？ 

上文讲到了价值流，价值流描述了组织是如何创造价值的。业务能力关注价值流是如何实现的，业务能力为价值流提供支撑，每个价值流阶段由一个或多个业务能力支持。 

业务能力的描述稍微粗粒度一些，不像业务流程已经具体到如何运营，但是从架构层面上知道大体是什么样的能力，需要什么角色、运用什么工具、执行什么流程、处理什么信息。这样对于决策者决定是否建设这个能力已经够用，对于执行者以此作为行动的目标也已经够用，后需要做的就是具体的项目实施了。 

业务能力地图是一组完整的能力，描述了组织到底需要具备哪些业务能力才能支撑价值流、实现组织的价值主张，从而能够实现战略目标。可以说，业务能力地图是一张蓝图，指引着具体的项目实施和日常运营，很好地衔接了从战略到落地的全过程。 

04 如何梳理出业务能力模型？ 

第一步，梳理出一共有哪些业务能力。 

业务能力的梳理有自上而上和自下而上两种方法。自上而下的方法需要组织的高层参与首先确定一级业务能力，再进一步向下细化分解到更详细的级别。自下而上的方法则可以以战略规划、商业模式、组织架构、管理制度等作为输入，进行结构化的拆解分析，形成业务能力。 

梳理业务能力模型要遵循一定的原则，关键是要做到相互独立，不重不漏。 

第二步，对业务能力进行分层分级建模。

对于4-6级业务能力，可能看起来像业务流程和活动。 

05 如何使用业务能力模型？

形成业务能力地图，保证一个组织有一张业务组件地图，从而确定出成为一家组件化组织所必须面对的差距和冗余。

可以使用热点映射图来表示业务能力的成熟度。绿色表示已经满足业务需要，黄色表示存在一定差距，红色表示存在很大差距，紫色表示当前不存在，即能力缺失。

 接下来要做的就是做差距分析，形成实施路径和项目组合，通过具体项目的实施来增强和补齐业务能力。

业务应用中台与架构设计

我曾经说过无数次，产业价值链是：产供销研售后。每个价值环节的资源是：物料、设备、人、钱。每个价值环节的资源从所有权来说都是三种：自有资源、战略合作资源、社会化资源。

（1）行业

昨天看到一个IT项目，客户是酒店行业资源整合者。

我想起两个事：

一个事是酒店行业在2006-2010年被资本+现代企业管理制度重构了一次。当时如家、桔子..，崛起了很多统一连锁的平价酒店。

一个事是酒店行业在2010年后被电商平台又教育了一次，当时携程、艺龙、途牛、飞猪、美团...，好多酒店电商销售平台。

所以，做酒店业，大家对资本、现代企业统一管理、在线电子商务与IT，都有一定的认知。

但是，中国很多产业，还没有被资本、现代企业统一管理、在线电子商务与IT教育过，所以中国很多产业的数字化其实还是信息化，还是线下获客线下签单线下付款，事后录入到IT系统中，只不过IT系统可能是在公有云部署、订阅付费使用。

（2）项目Case介绍

这个客户呢，自己有一些自营酒店资源，也有自己的多端官网：Web官网、官方App、官方小程序。

当然，更多的是合作，加盟合作了许多酒店资源，也合作了很多销售平台：如携程、途牛、美团。

而且面向的顾客呢，有个人住酒店的，也有团体住酒店的，两种顾客类型都有，处理流程略有差异。

（3）IT：业务应用中台

这个客户，除了各个酒店的自身酒店管理系统（前台接待系统、客房管理系统、餐饮管理系统...），到底还需要什么系统呢？这么多销售口子，这么多加盟酒店商，怎么统一管理。

所以，他们需要的是：

• 统一营销促销

• 统一订单

• 统一库存

• 统一支付

这四个统一，可以把多口子销售都收拢管理起来。

为了配合这个最小的价值链，我们还需要一块：统一产品主数据。

完成销售端，就需要多方分利了，给销售平台（携程美团）怎么分利，给自己怎么提成，给加盟酒店资源商怎么分利？所以还需要两个统一：

• 统一合同：和销售平台的分利政策合同，和加盟酒店的分利政策合同

• 统一清分结算对账：和销售平台怎么自动分利计算/结算支付转账/对账，和加盟酒店怎么自动分利计算/结算支付转账/对账

最后，为了自动化省事，可搞个财务总账开放接口，让这么多统一来的业务数据，自动生成记账凭证，统一插入到财务总账系统中。

我这只是讲完了酒店资源的采-销两个环节，至于说酒店的装修工程管理与结算、酒店物料的采购供应与结算，这些方面不在咱们今天的讨论范围。

（4）落地IT架构设计

落地方法论很清晰，但落地的执行难度，除了架构设计难度外，还有实现的细碎工作量。咱们今天主要讲架构设计难度。

这个项目，需要三个架构：

• 应用架构

• 数据架构

• 技术架构

一、应用架构

需要梳理和各个具体酒店的酒店管理系统、各个酒店加盟商、各个销售平台的系统之间的接口现状。

然后设计统一接口族：

统一营销促销接口族

统一订单接口族

统一库存接口族

统一支付接口族

甚至还包含：

统一清分结算对账接口族

统一财务自动记账凭证接口族

设计接口可是个难题，要满足各利益方使用的IT系统的统一兼容，还要满足各利益方使用的IT系统不断修改但是接口还要保持稳定，更要保持向下兼容。否则，你这接口不稳定，你要修改接口，那所有系统都要跟着你修改了。那协调难度和工作量，真是恐怖的不可想象。

所以这应用架构的价值到底有多高？大家知道了吧。这就是IT咨询。

二、数据架构

这个项目的数据架构包含：

• 酒店产品主数据的识别

• 酒店产品主数据的规范制定

• 酒店产品主数据的变更（增加/修改/删除）方法

• 酒店产品主数据的映射方法、复制分发制度、接口设计/接口访问方法/接口访问权限

过去主数据在主要业务系统中。现在主数据被独立了出来，所以各个系统都要对着主数据重新对接集成开发或者数据映射同步一遍。

三、技术架构

酒店行业由于受电子商务的洗礼已久，所以酒店行业的业务交易与支付，大多已经在线、实时。也就是说，一旦IT系统出了问题，那是真正的失去生意、丢掉了钱。这和传统IT截然不一样。传统IT即使系统瘫痪、即使系统出现了BUG，照样开门做生意，反正是事后人工录入。

所以，对于酒店行业数字化，对于技术架构，一定是和电子商务的技术架构一样高的：

• 高性能：这要遇到节日、大促，系统堵塞了，这损失的就是真正的钱

• 高弹性伸缩：为了应对节日、大促，就得在节日大促前进行弹性扩容，过了高峰后再缩小。如果能做到根据运维数据进行预测，进而自动伸缩资源，那就更牛了

• 高稳定：这要真计算错账、是真正计算错钱的，这怎么赔偿啊

• 高可用性：一旦出现计算存储网络问题，业务照样不受影响看不出仍然异样，这高可用就太牛了

这技术架构的难度高不高？有没有价值？这就是IT咨询。

这才是硬对硬拼核心竞争力的。

（5）最后

最后我想说两点：

我想说的第一点是：今天我讲的，都不是特指酒店行业的。其实只要在产供销研售后的某个环节，存在多个外部合作利益方，那么都需要这套产品：

统一营销促销中心

统一订单中心

统一库存中心

统一支付中心

不知道，中国的IT厂商们把这些业务中台独立出来没有，成为可独立部署独立报价独立销售的产品没？

我想说的第二点是：做了这么多统一业务中台，做了这么多集成对接开发，做了这么多架构设计，这复杂性、这高门槛性，这个IT项目，你说值不值1000万以上？

开发者涨薪指南 48位大咖的思考法则、工作方式、逻辑体系