业务架构解构与实践

往期回顾 >>

CIO要懂业务架构，再谈业务架构的定义与作用，附业务架构教程下载
为什么要坚持先业务后IT？附71页PPT:企业架构及典型设计
为什么说“业务架构师”是ITBP的最佳人选？
业务架构之建模方法
业务架构的伴侣：业务模型
业务架构与DDD协同落地
业务架构与其他架构的协作关系

第一部分架构总述

第1章企业架构的概念及发展历程简述

随着各行各业对数字化的逐步重视及数字化转型的逐步深入，企业架构逐步走进了我们的视野，我们经常面对大量的新名称、新术语、新概念，这些新名称、术语与概念代表了什么、他们之间的关系是什么，他们之间是如何配合的，对于多数人造成了不同程度的困扰。很多人都希望能有一个总体认知，了解企业架构的整体视图，企业架构的构成要素，各要素的位置及相互配合关系等。

企业架构的英文是Enterprise Architecture,往往简称为EA。

本章涉及的主要内容有：

企业架构的概念；
企业架构的作用；
全球企业架构发展的时间轴；
4大主流架构框架之Zachman；
4大主流架构框架之TOGAF；
4大主流架构框架之DoDAF；
4大主流架构框架之FEA；

1.1 企业架构的概念和作用

不同人对企业架构的定义和作用有不同的理解，希望读者通过以下介绍，对相关定义和作用形成基本的了解和共识。

1.1.1 企业架构的概念

顾名思义，“企业架构”是“企业”的“架构”，我们需要分别了解“企业”和“架构”的定义。

企业的定义

这里的“企业”，是指具有一系列共同目标的任何组织的集合。

可以是整个集团公司或政府机构；

可以是某个子公司或事业部。

架构的定义

关于“架构”，ISO/IEC 42010：2011给出了定义：一个系统在其环境中的基本概念或属性，体现在其元素、关系及其设计和演化的原则中。架构主要包含3个组成部分，如图1-1所示。

图1-1 架构的定义

延展：ISO/IEC所给出的这个定义，不仅仅适应于我们所探讨的“企业架构”，我们在思考和解构任何“复杂系统”时，都可以参考。

1.1.2 企业架构的作用

为了便于理解企业架构的作用，我么可以先了解下“架构”在一个“企业”中的大体位置和角色，然后结合业务实践给出一些参考。

架构的位置

图1-2是业内关于架构比较有共识的一个示意图。在图中，架构处于中间的位置。简单来讲，架构扮演着一个“承上启下”的角色。

图1-2 架构的位置及角色

企业架构的作用

基于上图示意的位置和角色，结合企业实践，我们给出企业架构的参考作用：
架构是从战略到项目落地的桥梁；
架构是IT与业务对齐的关键；
企业架构是企业整体能力建设的基础；
企业架构是IT规划的核心；
企业架构是整合信息孤岛、沉淀企业级数据资产的利器；
企业架构能有效指导IT治理与管控、减少IT重复投资；
企业架构是数字化转型顶层规划设计的有效指导方法。

1.2 企业架构的发展历程及4大主流架构框架介绍

从1987年由John Zachman提出的第一个企业架构的框架理论，发展到今天，已经有30多年的时间。在这30多年的发展历程中，全球业内提出的大大小小的框架有近百种，如此众多的架构框架，大多是从4套主流架构框架发展和衍生出来的。

我们将通过时间轴来了解主流架构的演进过程，然后针对4大主流架构框架进行简要介绍。

1.2.1 企业架构的发展历程

“企业架构”最初是由于信息系统的复杂性不断提高（熵增），人们的理解难度越来越大而出现的。为了便于理解和管理这种“复杂系统”，需要隐藏系统的局部细节信息，从中抽象出高层次的结构和交互关系，以便于通过更简洁的方式，以一套共同的语言来理解复杂的系统，利于相互沟通和交流。

企业架构的演进有两条主线，一条是起源于20世纪70年代美国启动的C4ISR计划（Command,Control,Communications,Computers,Intellingence,Surveillance and Reconnaissance）。这一计划的目标是把美军的战略决策及军队指挥、控制、管理所用的设备、器材、程序关联到一起，形成美军现代军队的神经中枢。经过多场战争的磨炼，逐步构建出跨多领域复杂系统的方法论体系，在此基础上逐步发展出TOGAF、DoDAF相关架构框架。

另一条主线起源于1987年John Zachman在IBM内部期刊撰写的著名论文《信息架构框架》（“A framework for information systems architecture”），首次提出了“信息系统架构框架”这一概念。这篇论文被业界奉为企业架构框架理论的开山之作，Zachman本人也被称为企业架构框架理论之父。以此为基础，后续逐步发展出Zachman、FEA等相关架构框架。

图1-3给出了两条主线牵引下的4大主流企业架构的发展历程。经过20多年的发展，到21世纪10年代，相关的企业架构框架基本上相对稳定了，版本更新趋向平缓。

图1-3 企业架构的发展历程

1.2.2 4大主流架构框架介绍

大致对架构框架的发展时间轴、两大演进路线了解后，下面简单了解下4大主流架构框架的关键内容。

Zachman 框架(企业领域)

Zachman 框架是由JohnZachman先生在1987年提出、第一个得到公认的架构框架，如图1-4所示。该框架主要表现为一个6*6的矩阵，一个是基于5W1H的分类，即Why(动机)、What(数据)、Who(角色)、When(时间)、Where(分布)、How(功能)6个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展示、功能系统这6个层次，将企业架构分为36个组成部分，完成从抽象概念到实例的转换(识别、定义、表示、详述、配置、实例化)，描述了一个完整的企业架构需要考虑的内容。经过20多年的发展，Zachman框架从2011年开始基本稳定在3.0版本。

图1-4 Zachman 框架

正如Zachman框架官网所强调的，该框架是一套元模型，而不是实施方法论。它给出的是企业架构内容的描述和分类，确保每个干系人的每个关注点都被照顾到、并有效地串联成一个完整的体系，提供了一种有效分解复杂企业系统的方法。

该框架提供了一张“静态”的全景图，但对于如何来创建这些内容，却没有给出具体的指导。可以认为这是一个参考框架，真正要一步一步的开发企业架构，需要借助于其他架构框架，比如TOGAF.

延展：Zachman框架所采用的5W1H,是一种用途非常广泛的思考方法，如果你在工作中遇到难题、不知道如何突破时，可以尝试使用5W1H进行分解，把问题展开，或许有助于开拓思路。

TOGAF框架（企业领域）

TOGAF (The Open Group Architectures Framework)由欧洲著名的The Open Group在1995年开发出第一个版本。在此过程中，很多厂商参与了该体系的构建，这种形成机制在一定程度上较好地保障了该体系的适用性和可推广性。无论在国际上，还是在中国国内，目前 TOGAF都已成为企业架构方面的主流框架体系。

TOGAF体系的6大部分内容及其关系如图1-5所示。

Part1:引言(EA关键概念及术语定义)。
Part2:架构开发方法。
Part3:ADM指南和技术。
Part4:架构内容框架。
Part5:企业连续统一体和工具。
Part6:架构能力框架。

图1-5 TOGAF体系的内容及其关系

在TOGAF 体系的6大部分内容中，架构开发方法(ADM)提供了一个流程化开发

业架构的思路，如图1-6所示，用户可参考相关步骤逐步推进企业架构的开发和实践。

预备阶段: 为架构项目进行初期准备。

阶段A: 明确企业架构愿景。
阶段B: 详述业务架构(开发基线和目标业务架构，并分析差距)。
阶段C: 设计数据和应用架构(开发基线和目标数据和应用架构，并分析差距)。
阶段D: 设计技术架构(开发基线和目标技术架构，并分析差距)。
阶段E: 机会及解决方案(阐述目标架构的机会及解决方案)。
阶段F: 迁移计划(根据优先级，进行路标规划)。
阶段G: 实施治理(形成架构监管及治理机制，确保架构交付合规)。
阶段H: 架构变更管理(提供变更管理流程，确保架构能持续响应业务需要)。

图1-6 TOGAF架构开发方法

注意：企业用户在参考TOGAF ADM进行架构开发时，可以结合企业自身情况进行适当裁剪。

DoDAF（军事领域）

DoDAF (The Department of Defense Architecture Framework)是美国国防部建立的企业架构框架，源自1970年代美国军方启动的C4ISR计划，该计划主要为了解决各军兵种独立建设、无法互联互通、无法进行一体化协同作战的问题。经过多场战争的不断积累，C4ISR 架构框架逐渐发展成为更加成熟的DoDAF架构框架，并于2003年8月正式发布DoDAF v1.0。又经过了5年多的发展和完善，美国国防部于2009年5月发布了最新版本DoDAF v2.0。

DoDAF架构框架由一系列视角所组成，在v1.0版，提供了4种视角，涉及全景视角、运营视角、系统视角和技术标准视角。到了v2.0版，扩展为包括全景视角、数据与信息视角、标准视角、能力视角、运营视角、服务视角、系统视角及项目视角在内的8大视角，如图1-7所示。

图1-7 DoDAF架构框架的8大视角

每个视角下都会包含若干模型，DoDAF架构框架基于上述8大视角可进一步分解为52 个模型，如表1-1所示。

上述8大视角与52个模型是DoDAF架构框架v2.0的核心，在具体应用时，这52个模型可以根据实际需要有选择地使用。

表1-1 DoDAF架构框架 8大视角与52个模型

FEA（政府领域）

美国联邦政府总共拥有300多个职责不同、规模不一的组织机构，这些机构的雇员数量超过 200万人，每年的年度预算都超过3万亿美元，其中每年各种形式的IT投入超过800亿美元。为确保对巨额IT投入的有效管控，1996年美国国会通过了一个有关信息技术管理改革的《克林格-科恩法案》，授权联邦政府相关机构开发和维护IT架构，以促进各个机构之间的信息共享、提升IT预算相关的投资收益。

在1999年，美国联邦政府CIO委员会发布了第一版的FEAF(Federal Enterprise Architecture Framework)。在此之后，由美国管理和预算办公室(OMB)负责管理和协调美国联邦企业架构建设，并于2002年成立了专门从事联邦企业架构开发的项目管理办公室(FEA-PMO)。为了能在不同联邦机构之间建立通用业务语言，加强沟通和协同，在2007年左右推出FEA参考模型的早期综合版本，如图1-8所示。这个早期版本中包含5个参考模型，除了强调绩效和业务驱动，也强调了要构建基于构件的架构。

图1-8 FEA参考模型（2007版）

又经过5年左右的积累和完善，FEAFv2.0于2013年发布，里面所涉及的参考模型更新版如图 1-9所示。

对比图1-8和图1-9可以看出，相比2007年的FEA参考模型早期版本，2013年的参考模型更新版本主要在下述3个方面进行了调整。

（1）从参考模型的数量角度看：

早期版本包含5个参考模型;
更新版本包含6个参考模型，多了“安全参考模型”，该模型与另外5个参考模型都有关联。

（2）从参考模型的命名来看：

早期版本中提到了“服务构件参考模型”；
更新版本中改成了“应用参考模型”。

（3）从参考模型的梳理顺序上看：

早期版本先考虑“服务构件参考模型”，然后考虑数据参考模型和技术参考模型；
更新版本则先考虑“数据参考模型”，然后输出给应用参考模型和技术参考模型，把数据参考模型的梳理提到了前面，进一步强调了数据参考模型的重要性。

图1-9 FEA参考模型（2013版）

近几年来，国内越来越多的企业开始探索企业架构的实际应用。除了来自企业领域的Zachman 框架和 TOGAF架构框架知识体系，来自军事领域的DoDAF架构框架和来自政府领域的FEA架构框架，对于企业架构的实际应用都可以有一定的参考和指导作用。

网上有不少与这些主流架构框架相关的中文材料和文章，考虑到不同译者有各自偏好且水平参差不齐，读者通过网上的中文材料进行学习时要注意对比和甄别。建议有一定英文基础的读者朋友直接查阅相关主流架构框架的官网、学习英文原版材料，有条件的可参加正规授权机构的专业培训，并通过企业实践加强对企业架构的理解和应用能力。

第2章业务架构的概念及发展历程简述

通过上一章学习，我们知道业务架构并非软件工程中新诞生的领域，业界提及的人很少，随着数字化转型的逐步开展，这个偶尔走进读者视线的概念，经常带着一种“花非花、雾非雾”的“朦胧感”，很多人对业务架构究竟在数字化转型中发挥什么作用，有什么好处，以及业务架构和IT架构的关系、价值链、流程、价值流、业务能力等基本概念说不清、道不明。本章将从业务架构的基本概念及发展历程讲起，让读者对业务架构有个基本的了解。

在了解了企业架构的概念及发展历程后，包括对4大主流的架构框架的了解，我们弄清楚了业务架构是隐藏在企业架构中的。Zachman架构框架虽然没有明确提出业务架构这个概念，但已经包含了业务架构关注的一些主要内容：如流程模型、数据、组织角色等，既然没有提出业务架构的概念，自然也没有包含构建方法，所以，Zachman架构框架应该算是业务架构的启蒙，同时，它也表明了这一工具或技术的最佳使用场景—面向复杂系统构建企业架构。

TOGAF进一步定义企业架构分为两大部分：业务架构和IT架构，大部分企业架构方法都是从IT架构发展而来的。TOGAF强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。TOGAF提供了一个详细的架构工件模型，从中我们可以明确看到业务架构阶段的交付物，这些内容也清楚地说明了业务架构在企业架构中的位置。对TOGAF架构框架感兴趣的读者可以认真地学习TOGAF模型，此处不再赘述。

在TOGAF之后，有先后诞生了FEA（联邦企业机构）和DoDAF（美国国防部体系架构框架）。前者虽然没有明确业务架构的定义，但是很好地应用了业务架构的思维（见图1-9 FEA参考模型）。后者体系比较复杂，共有8个视点和52个模型（见表1-1 DoDAF架构框架 8大视角与52个模型），但是实用性不错，这些能力视点和作战视点就是我们开展企业架构开发时通常关注的业务部分。对这两个模型感兴趣的读者，不妨查阅相关资料以进一步学习。

在清楚了企业架构的基本内容及其与业务架构的包含关系后，我们可以看到，业务架构从诞生之初就很清楚地定义了自己的使命：面向复杂系统构建。接下来我们一起了解下业务架构的基本概念及发展历程。业务架构的英文是Business Architecture，往往简称为BA。

本章涉及的主要内容有：

业务架构的概念；
业务架构的作用；
业务架构发展历程；
业务架构的主流体系一：价值链+流程；
业务架构的主流体系二：价值流+能力。

2.1 业务架构的概念和作用

相比于企业架构，业界人员对业务架构的了解会更生疏一些，业务架构方面尚未形成广泛统一的理解和共识。我们希望通过下面的介绍，让读者对业务架构的相关定义和作用形成基本的了解。

2.1.1 业务架构的概念

参考第1章对“企业架构的拆解”逻辑，可以对业务架构进行拆解，“业务架构”是由“业务”和“架构”这两部分组成的，我们需要分别了解“业务”和“架构”的定义。

业务的定义

本书中的“业务”，是指在企业运行过程中，为了实现企业目标所涉及的一些列生产经营活动。

架构的定义

关于“架构”，前面已提到了ISO/IEC 42010:2011给出了定义：一个系统在其环境中的基本概念或属性，提现在其元素、关系及其设计和演化的原则中。这个定义不仅适应于企业架构，也适应于业务架构。

业务架构的定义

不同组织、人员对业务架构的不同理解。在2007年，OMG（Object Management Group,对象管理组织）曾把业务架构定义为：

“企业的蓝图，它提供了对组织的共同理解，并用于校准战略目标和战术需求。”

在2017年，包括BA Guild在内的FEAPO组织众多成员对业务架构的定义进行了重新审视，将业务架构描述为：

“业务架构代表整体的、多维的业务视图，包括能力、端到端价值交付、信息、组织、以及这些业务视图和战略、产品、政策、计划和利益相关者之间的关系。”

考虑到国际上有多套业务架构体系，不同业务架构体系的侧重要素有所不同（有的侧重“流程”，有的侧重“能力”），为了方便理解，结合上方ISO/IEC对架构给出的定义，本书建议可将“业务架构”简单理解为“围绕业务的架构”，其具备架构的3个主要特征，涉及“业务要素”、“业务要素之间的关系”及“架构设计及演进的原则和指南”。

简而言之，回归到架构的本质，不管是基于“业务流程”来解构业务，还是基于“业务能力”来解构业务，亦或基于“能力+流程”相结合来解构业务，只要在解构业务时说清楚涉及哪些业务要素、业务要素之间什么关系及其演进原则，就可以认为它就是“业务架构”。

那么，我们尝试把“业务架构”定义如下：“业务架构就是把业务要素及要素之间的关系进行结构化表达、并给出了其设计和演化的原则与指南的一套框架。”

在实际的企业运作过程中，涉及很多与“业务”相关的名词和术语，可以列出上百项，在这里不做展开。当涉及元素过多时，元素之间的关系就会变得异常复杂。有很多组织都在尝试梳理、提炼和抽象主要业务要素，其中BA Guild （业务架构工会）的相关创始人（William Ulrich & Whynde Kuehn）和团队一起梳理出10个主要业务元素（如图2-1所示），里圈是业务架构核心要素，外圈是业务架构扩展要素，这套架构对业务拆解得相对清晰，是非常值得学习和借鉴的。

图2-1 业务架构要素

2.1.2 业务架构的作用

为方便理解业务架构的作用，首先了解下“业务架构”在“企业架构”中的大体位置和角色，然后结合业务实践给出一些参考。

业务架构所处的位置

在The Open Group的 TOGAF体系中，企业架构涉及4个主要部分，分别是业务架构(BA)、数据架构(DA)、应用架构(AA)、技术架构(TA)。在第1章中，我们在探讨企业架构所处位置时，把架构简单分为两类：一类是业务架构，另一类是IT架构，其中IT架构包含数据架构、应用架构、技术架构。架构要为业务服务，在针对具体企业进行架构分析时，业务架构是切入点，我们首先要确保业务架构是可靠、可信的，然后以业务架构为指导，逐步分析数据架构、应用架构和技术架构，这样才能确保相关架构能真正服务于业务并协同落地。图1-2 架构的位置及角色、图2-2业务架构在企业架构体系中的位置，简要表明了业务架构在企业架构体系中的位置及牵引作用。关于企业架构体系中4A之间的关系在第7章会进一步丰富和细化。

图2-2业务架构在企业架构体系中的位置

业务架构的作用

基于图2-2所示的业务架构所处的位置和角色，结合BIZBOK、O-BA等理论与企业实践，业务架构可以发挥的作用总结如下：

业务架构是企业整体业务能力的基础，是业务决策的重要参考依据；
业务架构是业务战略到业务执行的桥梁；
业务架构提供统一业务语言、驾驭复杂性、降低风险；
业务架构牵引企业架构其他关键要素（数据架构、应用架构、技术架构）；
业务架构强调整体协同和充分复用，有效减少IT重负投资。

2.2 两大主流业务架构体系介绍

关于业务架构体系,大家经常听到或接触到的有BIZBOK、O-BA、CBM、PCF(APQC)、ODBA等。不同的知识体系侧重点有所不同，其中PCF(APQC)、ODBA等更侧重“流程”视角，而BIZBOK、O-BA、CBM等更强调“能力”视角。

下面我们通过时间轴来看看主流业务架构体系的演进过程。

2.2.1 业务架构体系的发展历程

基于我们对“业务架构”的基本理解——它是利用业务要素及要素间关系来结构性表达业务的一套框架，我们可以看看基本符合该特征的相关主流业务架构体系的发展历程。图2-3是截止到2021年相关主流业务架构体系的演进情况及最新版本。

业务架构体系仍在不断地发展和完善，本书后续章节会逐步介绍目前较为主流的“价值链+流程”及“价值流+能力”这两大业务架构体系。这两套体系有一个共同点--它们都涉及“价值”。从上方时间轴可以看出，以价值为导向的理念，始于1985年美国哈佛大学商学院教授迈克尔·波特(MichaelE.Porter)在《竞争优势》(Competitive Advantage)里所提出的价值链分析框架。如果在企业架构领域(EA)，我们认为John Zachman是鼻祖的话(1987年，首次提出架构框架)，那么在业务架构领域，笔者认为迈克尔·波特是当之无愧的鼻祖(1985年，首次提出业务分析框架)。

“以价值为导向”的理念，也是本书相关理论及实践的一个基石。与此同时，当人们在谈论价值时会涉及具体给谁(利益相关者)提供价值的问题，考虑到利益相关者众多、容易造成重复和混淆，本书建议以外部的“客户”为源头来探讨企业的整体业务价值。本书后续内容中所谈到的企业，默认指市场化导向的企业，这些企业运行整体业务的出发点是“以客户为中心、以价值为导向”。

图 2-3主流业务架构体系的演进情况及最新版本

关于利用“价值链+流程”这套体系来分析和梳理业务，自从美国生产力与质量中心(American Productivity and Quality Center,APQC)在1992年正式推出流程分类框架(PCF)以来，已有近30年时间，相关理论及知识普及较广，本书会在本章进行汇总介绍。

相对而言，“价值流+能力”这套体系是近10年才推出的新体系(仍在持续完善),在国内的探索也是近3~5年的事，这套体系更有利于理解企业运作过程中的业务元素及元素问关系，它是本书要重点介绍和推广的内容，在本章仅做简单介绍，将在后续章节逐步展开。在围绕“价值流+能力”体系展开的过程中，我们也会尝试把两套主流体系的内容进行关联和融合，形成相互融合的业务架构体系，以便读者理解和参考。

期望通过本书的介绍，对企业整体业务运作感兴趣的朋友(尤其是对于需要服务业务用户，但又不太了解业务的IT管理人员及技术人员)，可以快速理解“业务相关的主要概念”“业务概念间的主要关系”等，快速形成对业务的基本认知。

2.2.2 主流架构一：波特价值链+流程

在业务架构的发展过程中，价值链(Value Chain)、流程分类框架(PCF)及业务流程建模符号(BPMN)都发挥了重要的作用，从各自方向上以结构化的形式进行业务描述，进而清晰表达业务架构的整体体系。

2.2.2.1 波特价值链

1. 价值链的提出

价值链的名称最初是由美国哈佛大学商学院教授迈克尔·波特于1985年在其所著的《竞争优势》中提出来的。作为一种强有力的战略分析框架，不断发展创新并被财务分析、成本管理、市场营销等专门领域广泛吸收和融入。

2. 价值链的含义

企业要生存和发展，必须为企业的股东和其他利益相关者包括员工、顾客、供货商及所在地区和相关行业等创造价值。

如果把“企业”这个“黑匣子”打开，我们可以把企业创造价值的过程分解为一系列互不相同但又相互关联的经济活动，或者称之为“增值活动”，其总和构成企业的“价值链”，企业从事价值链活动，一方面创造顾客认为有价值的产品或服务，另一方面也需要负担各项价值链活动所产生的成本。企业经营的主要目标，在于尽量增加顾客对产品或服务所愿支付的价格与价值链活动所耗成本间的差距（即利润）。价值链是企业在一个特定产业内的各种业务活动的组合。波特价值链如图2-4所示。

图2-4 波特价值链

图 2-4 中的价值链包括业务活动和利润，企业的业务活动是企业所从事的物质上和技术上的界限分明的各项作业，它可分为基本活动和支持性活动两大类。

关于基本活动，主要包含5种活动类型。

（1）进货物流：与接收、存储和分配相关联的各种活动，如原材料搬运、仓储、库存控制、车辆调度和向供应商退货等。

（2）生产运营：与将投入转化为最终产品相关的各种活动，如机械加工、包装、组装、设备维护、检测等。

（3）出货物流：与集中、存储和将产品发送给买方有关的各种活动，如产成品库存管理、原材料搬运、送货车辆调度等。

（4）营销销售：与提供买方购买产品的方式和引导它们进行购买相关的各种活动，如广告、促销、销售队伍、渠道建设等。

（5）售后服务：与提供服务以增加或保持产品价值有关的各种活动，如培训、安装、维修、零部件供应等。

关于支持性活动，主要包含4种活动类型。

（1）采购：指购买用于企业价值链各种投入的相关活动，采购既包括企业生产原料的采购，也包括各种支持性活动所需要的采购(如研发设备的购买等)及物料管理作业等。

（2）技术开发：每项价值活动都包含着技术成分，无论是技术诀窍、程序，还是在工艺设备中所体现出来的技术。

（3）人力资源管理：包括涉及所有类型人员的招聘、雇佣、培训、开发和报酬等各种活动。人力资源管理不仅对基本活动和支持性活动起到辅助作用，而且支撑着整个价值链。

（4）企业基础设施：企业基础设施支撑了企业的价值链条。如会计制度、行政流程等。

企业价值链进一步又可以和上游供应商、下游买主的价值链相连，进而构成一个产业价值链。波特(1985)认为每个企业都处在产业链中的某个环节，一个企业要赢得和维持竞争优势，不仅取决于其内部价值链，而且取决于在一个大的价值系统(即产业价值链)中一个企业的价值链同其供应商、销售商及顾客价值链之间的紧密连接。产业链企业在竞争中执行完成的一系列经济活动，即产业价值链。它更加突出“创造价值”这一最终目标，描述价值在产业链中的传递、转移和增值过程。

价值链分析的通常步骤如下。

（1）识别价值活动:包括活动的内容、发生的阶段及不同的活动类型等。

（2）价值链的确定:即为在一个特定产业竞争而定义企业的价值链。

（3）明确价值链内部的联系:虽然价值活动是构筑竞争优势的基石，但是价值链必须是一个由不同活动相互联系而构成的系统。

（4）了解不同企业间的价值链纵向联系:必须同时关注存在于企业价值链与供应商、渠道等价值链之间的纵向联系。

（5）考虑买方价值链:买方也有价值链，企业的产品可理解为买方价值链的外购投入。

3. 价值链理论的发展

价值链理论被波特提出之后，迅速得到广泛推崇、应用与发展，相继出现了新价值链理论、价值网理论和全球价值链理论。英国学者海因斯(Peter Hines)是新价值链理论的主要代表之一，他将价值链概念延伸至产业总体范围，将顾客和原料供应商纳入价值链，并将波特的价值链重新定义为“集成物料价值的运输线”。价值网的概念是由美国美世(Mercer)顾问公司的亚德里安·斯莱沃斯基(AdrianJ.Slywotzky)于1998年在《发现利润区》(Profu Zone)一书中首次提出的，2000年美国学者大卫·波维特(David Bovet)在《价值网:打破供应链、挖掘隐利润》(Value Nets:Breaking the Supply Chain to UnlockHidde Profits)一书中进一步发展了价值网。价值网的本质是在专业化分工的生产服务模式下，通过一定的价值传递机制，在相应的治理框架下，由处于价值链上不同阶段和相对固化的彼此具有某种专用资产的企业及相关利益体组合在一起，共同为顾客创造价值。世界经济一体化与跨国公司生产经营全球化成为全球价值链(GlobalValue Chain)理论产生的催化剂，成为当前研究跨国生产经营活动开展和利益分配的有效分析工具。格里芬(Gereffi)等人在对美国零售业价值链研究的基础上，将价值链分析法与产业组织研究结合起来，提出了全球商品链分析法。

随着各国企业国际化步伐进一步加快，国际生产进一步扩张，特别是发展中经济体和转型期经济体跨国公司进一步发展，将推动价值链理论的进一步发展。

2.2.2.2 流程分类框架

1. PCF简介

流程分类框架(ProcessClassification Framework,PCF)由美国生产力与质量中心(APQC)提出。

APQC创立于1977年，是一个以会员为基础的非营利机构，致力于各种改善手法的研究开发，确定产业标杆与最佳实践，并及时地向相关会员组织发布新知识、训练课程及关键成功工具。APQC服务全球超过500个横跨各种产业的营利企业、教育机构与政府单位。2003 年、2004年及2007年荣获由Teleos公司及欧洲知名研究机构KNOW Network联合评选的北美地区“最受赞赏的知识企业(MAKE)”殊荣(MAKE 指Most Admired Knowledge Enterprise)。

PCF 一开始被想象设计成为一种企业的流程分类法则，最初由APQC的一群会员在1992年共同创建，参与设计的组织单位希望能创造出前瞻性的标杆并运用于全球各地。目前的最新版本是2018年发布的v7.2.1。

APQC 提供两种PCF：跨行业和特定行业。跨行业PCF是最通用的PCF,可以应用于任何组织。特定行业PCF是根据不同行业的独特需求而定制的。

跨行业PCF最初被设想为一种业务流程的分类法，以及一种可以使APQC成员组织们进行基准测试的通用语言，APQC和80多家有兴趣推动在美国和全球使用基准测试的企业组织参与到初步设计中来。自1992年提出以来，PCF已经实现了其大部分内容的更新。

特定行业 PCF 使组织能够以适合其所执行工作的方式来构建和定义流程。特定行PCF还允许与行业同行进行更具体和详细的基准测试。但重要的是，特定行业PCF的结构与跨行业PCF相同，这使得组织能够在使用特定行业PCF的同时与其他行业进行基准测试。

各种行业、各种规模的企业或个人，都可以通过APQC官网免费获得PCF资料。

2. PCF层级

PCF 分成5个层级，如图2-5所示。

图 2-5 PCF 流程分类框架

第1层级——流程分类;代表企业中最高级别的流程，如管理客户服务、管理供应链、管理财务组织和管理人力资源。
第2层级——流程组:表示下一级流程，代表一组流程。售后维修执行、采购、应付账款、招募/采购、销售战略制定均为流程组的示例。
第 3 层级——流程:一系列相互关联的活动，将投入转换为成果(产出)。流程的每个活动都会消耗资源，需要不断优化、可重复履行的标准。
第4层级——活动:表示在执行流程时履行的关键事件，如客户请求接收、客户投诉解决、采购合同谈判。
第5层级——任务:表示活动后的下一级分解，任务通常更加细致，可能在不同行业存在较大差异，如创建商业计划、获得融资、设计激励方案。

不同企业涉及的业务规模、业务复杂度不同，企业在进行业务梳理时，最大的挑战之一就是如何基于不同的颗粒度进行分层。APQC所推出的PCF，在这方面做出了非常大的贡献，为各个行业的企业都提供了很好的参考。为方便国内读者理解和使用，本书基于PCF 的英文分层描述分别给出了对应的中文描述，如图2-6所示，供大家参考。

图 2-6 PCF L1~L5层级的中英文描述

本书在后续章节(如业务能力分层)会借鉴相关分层思路，并进一步结合国内企业使用习惯进行适当补充和调整，以确保相关分层体系有更好的通用性和可扩展性。

下面我们来看一下较为常见的企业流程分类(L1层级)的情况，如图2-7所示。

图2-7 企业流程分类（L1层级）

图2-7中的L1层级流程分类，包含两大部分。

（1）运营流程(Operating Process)。

（2）管理和支撑流程(Management and Support Process)。

把PCF 框架图和波特价值链图进行对比，很容易发现PCF的“运营流程”“管理和支持流程”与波特价值链的“基本活动”“支持性活动”的主体思路是一致的。把价值链与流程结合起来，可形成一整套业务架构体系。

2.2.2.3 业务流程建模符号

1. BPMN 简介

我们现有的 IT 系统大多数都承载着业务流程管理的功能，比如供应链领域的仓储管理WMS、物流管理 TMS，以及订单管理OMS、SRM、CRM等，主要就是用来管理企业自身纷繁复杂的业务关系及业务流程的。

为了能清晰地描述问题，我们通常对已经存在的复杂问题进行模型化的抽象，通过模型来推导解决问题的方案。因此，对于业务关系和业务流程也需要进行建模，这一过程被称为业务流程建模(Business Process Modeling，BPM)。BPM有很多种建模语言，BPMN(Business Process Modeling Notation，业务流程建模符号)是其中的一种主流建模语言。

在 BPMN 的发展过程中，基于BPMN的一些特性与业务流程管理中常见的一些情况，总结提炼出了一套标准。这套标准在2004年5月由BPMI(业务流程管理倡议组织,The Business Process Management Initiative)Notation Working Group对外发布，这就是BPMN1.0 规范。其后，BPMI并入OMG。OMG在2006年2月发布了BPMN规范文档。后续BPMN 的 2.0 版本对BPMN进行了重新定义，该版本从2010年开始开发，于2013年12月正式发布.BPMN的最新版本(2.0.2)已由ISO 正式发布为2013 版标准:ISO/IEC 19510。

2. BPMN 2.0元素和模型

BPMN 代表业务流程模型与符号。它是一套流程建模的标准，主要目标是提供一套被所有业务用户容易理解的符号，支持从创建流程轮廓的业务分析到这些流程的最终实现，直到最终用户的管理监控。BPMN提供了清晰而精准的执行语义来描述元素的操作。

BPMN规范还确保设计为业务流程执行的XML语言(如WS-BPEL),能够用这套以业务为中心的符号进行可视化表示。BPMN的相应说明文档可以从OMG 官网获取。

BPMN定义了5个基础的元素类别。

（1）流对象(FlowObjeet):用来操作数据流的对象，包括事件(Event)、活动(Activity)、网关(Gateway)3种流对象，是BPMN中的核心元素。

（3）数据(Data):用于描述活动所需要或者产生的数据，包括数据对象(Data Object)输入数据(DataInput)、输出数据(DataOutput)和数据存储区(Data Store)4种元素。

（4）连接对象(Connecting Object):将流程对象连接起来组成业务流程的结构，有3种连接对象，分别是序列流(SequenceFlow)、消息流(Message Flow)和关联(Association),

（5）泳道(Swimlane):用以区分不同的参与者、功能和职责，有两种类型的泳道，分别是池(Pool)和道(Lane)。

（6）描述对象(Artifact):为了扩展基本符号，提供描述额外的上下文,包括组(Group)、注释(Annotation)。

BPMN提供了3种基本类型的模型，涉及不同类型的业务流程。

（1）协作流程模型:又称协作流程图、共有流程，用池的方式描述两个或更多业务实体(流程)之间可视活动的交互作用。

（2）独立流程模型:又称私有流程、内部业务流程，用泳道表示特定组织内部的独立、私有业务流程。

（3）组合流程:又称公共流程，表示私有业务流程与其他流程或参与者之间的交互。相关规范的具体内容可以参看官方说明文档，多个软件工具已经将BPMN2.0规范落实在软件功能中。

2.2.3 主流架构二:价值流+能力

以价值流和能力为基础的业务架构体系，主要是BAGuild(OMG成员)和The OpenGroup(简称TOG)作为主要推动者。该体系是由成立于2010年的BAGuild率先推动的，于2011年推出BIZBOKv1.0，每年都会结合相关理论和实际发展进行持续更新，截至2022年，最新版本是于2022年5月发布的BIZBOK v11.0。TOG方面分别在2016年发布O-BA Part l，在2017年发布O-BAPart1I，目前只有这一个版本。本书后续会以BIZBOK为主进行介绍。

1. 价值流

在BIZBOK 中，价值流的定义是:为客户创建结果的端到端活动集合，客户可能是价值流的最终客户或内部使用用户。它来源于Ralph Whittle和Conrad Myrick在2005年给出的定义.

图2-8是一个简单的例子，价值流是一个端到端的价值增值活动集合，向利益相关者交付价值(能解决特定客户需求的产品或服务)。在一个价值流中，会涉及多个价值流阶段，每个阶段都会为利益相关者提供相应阶段的价值项，各个阶段的价值项汇总来实现对目标客户的整体价值交付。价值流相关的具体内容将在第3章进行介绍。

图2-8 酒店住宿价值流示意图

2. 业务能力

目前主流的业务架构体系，如BIZBOK、O-BA，其业务能力的相关定义，都是参考Ulrich Homann在2006年给出的定义，指“一项业务为达成特定目的或结果所拥有或交换的特定能力和产能”。

业务能力是一个非常重要的概念，不同人对业务能力的解读会差异较大，本书会在第3章先介绍业务能力相关的一些基本概念，在第5章进一步解析业务能力与业务架构其他核心要素之间的关系，并在第8章介绍业务能力相关的关键交付物。

在后续章节围绕价值流、能力等内容进行展开的过程中，本书会尝试关联“价值链+流程”的相关要素，并形成一整套融合的业务架构体系，以期读者能看到业务架构全景图，对业务形成整体认知。

第二部分业务架构基础知识

通过第一部分的介绍，我们已经基本清楚企业架构是什么、业务架构是什么、业务架构与企业架构之间的关系，以及业务架构和数据架构、应用架构、技术架构之间的基本关系。也初步介绍了业务架构的发展历程和两大主流业务架构体系，并强调“价值流+能力”这套业务架构体系是本书希望重点介绍和推广普及的内容。

在对“价值流+能力”这套业务架构体系进行展开介绍时，我们会按照循序渐进的思路进行。

先掌握基础知识：对于国内人员而言，“价值流+能力”这套业务架构体系可以说是一门新兴学科，我们需要先了解并确保对关键概念和业务术语的理解。本书会分成两部分介绍10个主要业务要素，第3章介绍4个核心要素，第4章介绍6个扩展要素。在所有要素中,“业务能力”是重中之重，在介绍过程中会进行充分扩展。
再深入进阶：掌握了基础知识后，我们会进一步梳理和介绍业务架构各要素之间的协同关系(第5章和第6章)、业务架构与其他架构的关系(第7章)。通过第三部分的贯通和剖析来加深对业务架构自身及周边要素的全面理解。

第二部分将介绍基础知识相关内容，主要涉及两方面：

第3章，业务架构核心要素；
第4章，业务架构扩展要素。

第3章业务架构的核心要素

第2章所提到的以“价值流+能力”为基础的这套业务架构知识体系，其所包含的 10个业务要素分布在两个圈里(里圈和外圈)，本章将会介绍里圈4个业务架构核心要素的基本概念，尤其会针对“价值流”和“业务能力”进行重点介绍。

本章涉及的主要内容有:

价值流;
业务能力;
信息;
组织。

3.1 价值流

对于一个市场化的企业，基本都会强调“以客户为中心、以价值为导向”的理念。价值流这个概念的导入，对于牵引和体现这个理念有重大帮助。在此我们一起了解与价值流业务架构解构与实践相关的主要概念:

价值主张；
价值流；
价值流阶段。

3.1.1 价值主张的基本概念

价值主张是指某种产品、服务或组合，能帮助客户解决问题或给客户带来体验或收益，客户因而也愿意为所获取的价值支付一定的费用。人们日常生活中涉及的吃、穿、住、行、学习、娱乐等事宜，都需要有各种各样的产品和服务来满足相应的生活所需。

战略大师卡普兰和诺顿曾说过,“战略是基于差异化的客户价值主张，让客户满意是可持续价值创造的源泉。”"对于一个市场化的企业，企业负责人需要通过特定的产品和服务向外部客户提供价值，与此同时，需要确保企业所付出的成本低于客户所能支付的费用(投入产出比)，进而保障企业可以良性可持续地运转，持续向客户交付价值。

价值主张一般是站在企业角度而言的，其目的是满足客户角度的价值诉求。在商业画布九宫格中，价值主张处于中心位置;与此同时，在谈论价值主张时，一定会结合目标客群来谈。当一个企业要决策是否在某个产品或服务上进行投入时，首先需要分析和明确相关的产品和服务，到底服务哪个客群、到底提供什么样的价值，以及相关产品和服务的定价是否是目标客群所能承受的。

关于如何创造客户真正需要的产品和服务，亚历山大·奥斯特瓦德(Alexander Osterwalder)、伊夫·皮尼厄(Yves Pigneur)等在2014年出版的《价值主张设计》(ValueProposition Dexign)一书中进行了详细的介绍和说明，有兴趣的读者尤其是从事“产品”相关工作的人士可以进一步学习和了解。

3.1.2 价值流的基本概念

前面第2章中提到过，BIZBOK给出的价值流定义是:为客户创造结果的端到端活动的集合，客户可能是价值流的最终客户或内部使用用户。

图3-1是一个酒店服务的例子，表明价值流是一个端到端的价值增值活动集合，是为了向利益相关者交付价值(能解决特定客户需求的产品或服务)。一个价值流会涉及多个价值流阶段，每个阶段都会为利益相关者贡献相应阶段所产出的价值项，通过各阶段的价值项汇总来实现对目标客户的整体价值交付。

图3-1酒店住宿的价值流及价值阶段示意图

价值流有以下3方面关键特征：

需要向特定利益相关者交付价值(针对特定目标客群):
需要达成目标客群的特定价值诉求:
价值流的每个阶段，都需要带来价值增量。

基于价值流的上述3方面关键特征，我们来了解一下价值流的优势及现存的一些不足之处。

1. 价值流的优势

当我们引入“价值流”这个概念时，经常被拿来和流程进行比较。相比于平常所说的“流程”，价值流的优势如下。

（1）价值流会更有针对性，它针对的是特定目标客群、特定的价值主张，目标明确。

（2）价值流的结果导向及价值增量的诉求会更加强烈，依据价值流分析，更容易辨出哪些环节对于交付客户价值诉求是增值的、哪些环节是不增值的。无价值增量的环节目论上可以去掉或弱化，这将有利于避免“流程越做越重、疲于应付而收效甚微”的情况。

2、价值流应用目前存在的不足

在企业中实际应用“价值流”时，经常会碰到下面两类典型问题。

（1）价值创造重复的问题:目前给出的价值流定义，可以由不同的利益相关者(Stakeholder)来触发，利益相关者可以是外部的，也可以是内部的，这容易导致内、外价值流所创造的价值出现重复和混淆的问题。理论上来说，我们要把企业当成一个整体来看，企业所创造的价值应该是所有交付给外部客户的价值。企业内部的所有活动，都是在为外部客户服务，内部活动的价值增量会体现在为外部客户创造的价值上，可以简单理解为企业内部活动是外部客户价值流的一个组成部分。

（2）价值流的数量控制问题:一个企业有多少条价值流比较合适?理论上来说，围绕1个目标客群的1个价值诉求，就可以触发1条价值流；1个目标客群如果有n个价值诉求(如需要电脑、需要打印机、需要音箱、需要手机等)，就可以有n条价值流。与此同时，如果目标客群有多个(比如m个)，这么一来，理论上可能会有m*n条价值流。

对于上述典型问题（1）的处理，笔者个人的建议是回归初心一既然我们强调以客户为中心，我们谈的“价值”主要是针对外部客户的，那么在考虑价值流时，只考虑外部客户触发的价值流，除了战略相关活动，企业内部的其他各种活动，只是一个个用来直接或间接支撑外部客户价值流实现的组成部分，这样的解构逻辑会比较清晰，避免重复和混淆。

对于上述典型问题（2），比较常见的处理方式是，一方面对目标客群，进行适当归类

(比如，分为ToB客户和ToC客户，或者分为“大客户”“中小客户”“个人消费客户”); 另一方面可对目标客群的价值诉求进行提炼合并，类似的价值诉求可以归为一类(比如，需要的话可以考虑把电脑、打印机、音箱等需求都归为一类——“电脑及配套产品”)。进行上述处理后，如果价值流数量还是比较多，那么可以基于对业务的理解，识别出有哪几条是企业的核心价值流，对于非核心的价值流可以适当弱化或忽略，以确保企业的有限资源聚焦在核心价值流的实现上。BIZBOK给出的基本参考建议是：价值流属于相对高阶的概念，一个企业的主要价值流数量一般不超过20条。

3.1.3 价值流阶段的基本概念

下面我们继续以酒店住宿价值流为例，进一步分解该价值流的主要组成。

1. 价值流阶段的概念和特征

在图 3-1中，酒店服务的整个价值流由4个主要阶段组成:预订房间、入住、享受酒店服务、离店，这4个阶段我们称之为“价值流阶段”。整个价值流，是为了整体交付特定客群的价值诉求。而其中的每个价值流阶段，都会贡献相应的价值增量，以确保客户所需整体价值的逐步实现和完整交付。

价值流阶段的3个主要特征如下。

（1）每个价值流阶段都有对应的“价值项”，可理解为它是该阶段为客户带来的价值增量。若某个阶段无法为实现客户所需价值带来增量或做出贡献，理论上这样的价值流阶段可以舍弃。

（2）每个价值流阶段都有进入条件。只有满足特定前提条件才能进入某个环节，通过对前提条件的确认和保障，有利于该价值流阶段顺利实现该阶段对应的价值项。

（3）每个价值流阶段都有退出条件。设立明确的退出条件或退出要求，可以快速验证该阶段是否顺利完成该阶段的任务，并相应触发下一个环节。

2. 价值流阶段示例

结合上方所描述的价值流阶段的概念和特征，基于酒店住宿场景给出价值流阶段示例如表 3-1所示。

表3-1 价值流阶段示例

表3-1所给出的是一个基本的价值流阶段描述模板，一般会包括价值流阶段名称、描述、利益相关者、进入条件、退出条件、价值项这6个要素。企业在具体应用时可根据需要考虑是否增加下面这些补充列。

（1）可将利益相关者拆为两列，一列是触发型利益相关者(Triggering Stakeholder),另一列是参与型利益相关者(Participating Stakeholder)。特定的价值流往往是由于触发型利益相关者的特定价值诉求而产生的，而在价值流的各个阶段会有内部、外部众多利益相关者参与进来，主要是为了共同实现触发型利益相关者的价值诉求。

（2）当我们罗列“价值项”时，默认是站在客户角度来看的。如果需要，可拆为两列，一列描述客户所获得的价值(必填项)，另一列描述企业所获得的价值(非必填项)。

（3）为了便于判断某个价值流阶段的完成质量，可引入适当的指标来衡量该阶段的产出效果(非必填项)。相关指标如果需要也可拆为两列，一列描述从客户角度需要完成什么考核指标，另一列描述从企业角度如何进行考核。在定义企业内部的考核指标时，建议先了解客户角度有什么考核指标，以确保企业内部的指标完成的确有助于客户侧相关指标的完成。

3.2 业务能力

BIZBOK、O-BA等业务架构体系，都是以“价值流”和“业务能力”两大核心要素的交叉映射为基石的，而业务能力则是真正支撑“价值主张落地”的最关键要素。业务能力是本书最为核心的一部分内容，本节将展开介绍业务能力相关基础知识。

3.2.1 业务能力的定义和命名

目前主流的业务架构体系，如BIZBOK、O-BA，其关于业务能力的定义，都是参考Ulrich Homann在2006年给出的定义，指“一项业务为达成特定目的或结果所拥有或交换的特定能力和产能”。

笔者认为The Open Group把业务能力定义为“做某事的能力”，这种表述方式更加简单易懂。比如，某个企业或部门“有管理客户的能力”“有管理合作伙伴的能力”“有管理产品的能力”。为便于表述，往往我们会将相关能力表达成“客户管理能力”“合作伙伴管理能力”“产品管理能力”等。这些表达形式的特点是通过“名词+动词”来命名某项业务能力的。

3.2.2 业务能力的识别

越来越多企业开始强调“能力建设”，期望通过加强或打造“核心能力”以逐步形成企业的核心竞争力。那么企业要关注哪些能力、如何来识别“能力”，就成了必须要解决的问题。识别业务能力的常见方法有下面几种。

（1）基于企业运行所涉及的业务对象来识别。

比如，围绕“客户”“合作伙伴”“产品”“合同”“项目”等，可识别出“客户管理”“合作伙伴管理”“产品管理”等业务能力。

（2）利用企业已有流程来识别。

尤其对于流程基础比较好的企业，可以基于价值流各阶段快速识别对应的相关流程，进而梳理识别相关业务能力。

（3）参考业界最佳实践或成熟模型。

比如产品领域有PACE模型(产品及周期优化相关)，供应链领域有SCOR模型(供应链运作相关)等，均可作为参考。

（4）利用成熟软件包中相关分类进行识别。

软件包一般是基于特定场景、特定业务逻辑开发出来的，业内成熟的软件包往往包含了特定领域较成熟的业务管理逻辑及相关业务能力，可供参考。

其中第1种方法是最为基本的梳理方法，也是业务架构协会(BA Guild)比较推荐的方法。业务对象是一个非常重要的抓手，本书后续在第3.3.2节也会进一步阐述业务能力与信息如何围绕业务对象进行关联。

3.2.3业务能力的构成

近年来，“能力”这个词的使用热度很高，经常会在各种场合被提到。能力可以针对个人，也可以针对企业组织，本书主要针对企业/组织层面来定义和探讨能力。对于企业/组织的业务能力，在不同语境下其所涵盖的内容有所不同，不同理论体系、不同人对业务能力的理解也会有差异。接下来我们会尝试通过分析业务能力构成，来梳理业务能力的关键组成要素。

目前已有多个知识体系涉及业务能力的构成要素问题。比如，The Open Group 在“TOGAF 系列指南一业务能力”中，提到了业务能力由4部分构成：

（1）角色(Roles)；

（2）流程(Processes)；

（3）信息(Information)；

（4）资源(Resources)。

Amit Tiwary和Bhuvan Unhelkar在Outcome-Driven Business Architecture一书里描述了业务能力由下述要素组成:

（1）人员(People)；

（2）流程(Process)；

（3）技术(Technology)；

（4）资源(Resources)；

（5）信息管理(Information Management)；

（6）知识管理(Knowledge Management )。

在这两套理论体系中，都提到了“资源”。近些年,“资源”在国内也成为了一个热词，企业运作所涉及的方方面面在一定程度上都可以理解为资源，比如资金、品牌、人力、名户、IT、信息/数据、平台、技术、专利、公共关系等。由此可见，在国内提到“资源”时，可涵盖的内容很多，当我们把它和“人员、技术、信息”等构成要素放在一起时，区分边界不太清晰，比较容易引起混淆。

为了能更好地理解业务能力是什么并进行深入解构，我们先从企业老板的角度思考和解读一下，然后进一步探讨和梳理业务能力的构成要素。

一般来说，企业老板要的是“最终结果”，要求相关负责人能把某事干好、干成。事情能否干成，影响因素很多，比如：

没有原材料或原材料供应不足，比如房地产企业建房出售需要“地块”;
没有好的工具/设备，比如生产半导体芯片需要“光刻机”;
没有合理、固化的流程;
没有稳定、易用的IT系统;
没有合格、足量的人才。
.......

上述示例中的相关要素都可能导致事情办不成、最终结果无法落地，都可作为业务能力的构成要素之一。我们要把“业务能力”全景要素看清楚，需要有个相对合适的分类，并尽可能做到不重复、不遗漏，这将有利于大家的理解和掌握。

其实我们所说的“把事做成”，可以理解为一个“劳动生产”的过程。本书倾向于借鉴和参考生产力相关的要素来进行业务能力解构。比如，在特定的业务场景下(针对某类客户，生产或提供特定产品和服务)，将会涉及下列要素:

（1）劳动者(相关组织/人员)；

（2）劳动对象(各种原材料)；

（3）劳动资料(各种技术、工具、设备)；

（4）劳动过程(各种流程)；

（5）劳动产品(生产出来的产品或服务)。

上述5个要素的基本关系，如图3-2所示。

图3-2 业务能力构成要素关系图

图 3-2 中我们引入“劳动产品、劳动对象、劳动资料、劳动过程、劳动者”这些术语，主要是为了方便大家理解“把事做成”背后的关键要素和逻辑关系。采用这些词来描述业务能力的组成相对更好理解一些，但“劳动对象”和“劳动资料”这两个词仍然比较容易混淆。真正在企业里梳理业务能力的时候，我们建议采用更具象化的术语，比如“原材料”“技术/工具/设备”，更便于大家进行区分和理解，具体可参见表3-2。

对于业务能力，除了考虑由哪些要素来构成，后续章节还会涉及能力的分层或分级。按照能力颗粒度不同，可分为一级能力(L1)、二级能力(L2)、三级能力(L3)等。对不同层级的业务能力进行具体描述时，会存在一定差别。比如，在描述表3-2 中第5部分“组织/人员”时:

当能力层级较高、颗粒度较粗时(比如L1、L2层级能力)，可对应到“相关组织或部门”进行描述;
当能力层级较低、颗粒度较细时(比如L3层级能力)，这一部分的描述可对应到“具体的岗位、角色或个体人员”。

与此同时，在具体描述“组织/人员”时，由于不同企业的现有基础不同，也可能带来能力描述上的差异，我们可以因地制宜、找到较切合实际的描述方式，比如:

·对于流程体系很成熟、很规范的企业，往往已经清晰定义流程中各环节的角色，以及相关角色主要由哪些部门、哪些岗位的人员来执行:具备这种前提条件的，可考虑通过相关角色来描述“组织/人员”;
·如果一个企业的流程体系还不是很成熟，角色和不同部门、不同岗位之间也尚未形成清晰的对应关系，在描述“组织/人员”时，建议直接列出相关的部门/岗位，这种描述方式有利于更具象化、更准确地理解某个能力要执行落地，到底和“谁”有关。

另外，“数字化”对于大多数企业的发展而言，已逐渐成为关键驱动要素。在数字化转型过程中，对于业务能力的描述往往会侧重于“流程、组织、IT、数据”这几方面，我们在表3-2 中标注了(*)号，供参考。

3.2.4 业务能力卡片

基于上节对业务能力构成要素的梳理(5大部分)，我们可以利用业务能力卡片来具体描述相关能力，并持续更新版本，如表3-3所示。

表 3-3 的业务能力卡片模板较完整地反映了业务能力的主要构成要素。若这些主要构成要素中有一个做得不到位，就有可能导致整个业务能力无法落地。

具体在使用业务能力卡片过程中，可结合特定项目的目标及侧重点进行适当地裁剪和调整。

若某个企业要重点梳理和打造企业核心竞争力，建议用上述5个大的方面、11个分项来完整分析相关业务能力的方方面面，以便看清特定业务能力的全景要素，进行全盘考虑，减少决策风险。在描述某个特定能力时，若某个方面或某个子项不涉及，可标识为“NA”，表示“不适用”。如果对特定行业、特殊业务进行业务能力分析时，发现表3-3中的11个分项不够用或部分分项不太适用，则可根据企业具体情况进行适当补充和调整。
·若某个企业在做数字化转型相关项目，往往会侧重数字化相关的重点要素，可绕“流程、信息、组织、IT”对业务能力卡片进行适当剪裁和简化。

表3-3 完整版业务能力卡片(示例)

3.2.5 业务能力分类

当我们所面对的某个系统或体系规模很小，或者里面的要素很简单时，我们很容易就能把这个体系看得清清楚楚。但如果我们面对的是一个有一定规模和体量的复杂体系，就需要引入一些方法对复杂体系进行解构。对于企业而言，尤其是一些多事业部多业务并行、员工规模上万的集团型企业，涉及方方面面的能力，能力与能力之间也会存在包含或依赖的关系，往往需要采用分类、分层的手段对其进行梳理和解构，才能真正把企业级的整体业务架构看清楚。

本节将会重点探讨业务能力分类的问题。

对业务能力进行分类的维度很多，本节主要探讨较为常见的分类维度。

在1985年，迈克尔·波特推出价值链理论，首次推出了“纵横叠加”的两大活动分类:纵向列出的是“PrimaryActivity"，是核心业务活动，国内往往翻译为“基本活动”;横向列出的是“SupportActivity”，被称为“支持性活动”，辅助基本活动的顺利开展。该理论产生了非常巨大的影响，很多主流知识体系中都可以看到波特价值链的印记。比如APQC组织推出的PCF将L1层级流程分成两大类:一类是运营流程(Operating Process ),另一类是管理和支持流程(Management and Support Process)，这两大分类基本参考了波特价值链的基本分类逻辑。

在 2008 年，IBM发布了CBM(Component Business Model)方法。该模型把业务能力分为 3类:引导(Direct)、控制(Control)、执行(Execute)。这3类业务能力能较好地区分和对应企业内不同人员的责任级别，这种分类方式对于强调责任级别的企业，有一定的参考作用。

在 2011 年，随着BIZBOK的推出和不断完善，业务架构协会(BA Guild)给出的建议是把业务能力分成3大类:战略能力(StrategicCapability)、核心能力/面向客户的能力(Core/Customer Facing Capability)、支持能力(SupportingCapability)。笔者认为，核心能力及支持能力在一定程度上继承了波特价值链两大分类的思路，在此基础上增加了战略力，以强调其指挥及牵引作用。这种解构方式值得参考，尤其是大型企业在进行L1层级业务能力解构时可适当借鉴。

考虑到“价值流-业务能力”业务架构知识体系是相对新兴的学科，国内也是近几年才起步的，各个行业的业务能力框架参考资料也较少。本书会围绕制造行业进行一定的探索和输出，抛砖引玉。我们在融合国内外多套业务能力框架的基础上，结合了多个制造企业的实际情况，尝试给出制造行业参考性L1层级业务能力框架，如图3-3所示。

图3-3 制造行业企业L1层级业务能力参考

图 3-3 列出了制造行业企业的12个L1层级业务能力，其中中间4个能力是面向客户的核心能力:产品管理(Product)、营销与销售管理(M&S)、供应链管理(SC)、服务管理(Service)，这4个能力支撑了制造企业的主业务流。最上方的4个能力属于战略能力:战略管理(Strategy)、研究与创新管理(R&I)、客户管理(Customer)、全面质量管理(TQM),主要起牵引作用。最下方的4个能力属于支持能力:财务管理(FIN)、人力资源管理(HR)、业务变革及IT管理(BT&IT)、管理支撑(BMS)。各个企业实际涉及的支持能力很多，其中的财务管理、人力资源管理、业务变革及IT管理对于现代化制造企业影响很大，所以把这3块单独罗列出来，其他很多能力比如“法务”“风控合规”“项目管理”“行政后勤”等暂时合并归入管理支撑(BMS)部分。实际梳理和设计业务能力框架时，各个企业可以根据自己的需要进行适当调整。

3.2.6 业务能力分层

在第2章介绍PCF时，我们提到了5级流程体系。考虑到国内企业在表达L1层级时，比较习惯使用“XX域”“XX领域”的字眼，我们在进行中文翻译时，倾向于将PCF的L1~L3层级翻译为“流程域”“流程组”“流程”，如图3-4所示。

图3-4 流程分层(中文描述示例)

与此同时，在企业里推行EA体系时，不仅仅涉及业务流程分层、业务能力分层，还会涉及“数据架构分层”“应用架构分层”等。不同架构理论体系、不同企业在描述不同架构的不同层级时，会给出各种各样的名称。即使同一个企业在描述不同架构的不同层次时，相关的取名逻辑也不尽相同，企业里的人员仅仅是记这些名词、记不同名词的层级关系，就要费一番脑筋，个人认为这是一种“内耗”，非常不利于EA在企业内的宣贯、应用和推广。

考虑到建立企业架构体系，其中的一个关键目的就是要在企业内建立一套统一的语言，以便大家理解和互通。笔者强烈建议，企业在引入各种术语或名称时，要以方便广大企业人员的理解和记忆为出发点，尽量统一和简化相关术语的名称，比如对于L1~L3层级，都是用“XX域”“XX组”“XX”来统一表达，如图3-5所示。

图 3-5 业务能力分层(中文描述示例)

图 3-5 中的业务能力分层，建议L1~L3层级的命名为“能力域”“能力组”“能力”，统一分层命名逻辑，方便记忆。

3.2.7 业务能力热力图

我们前面对业务能力的构成要素进行了解构，后续对业务能力情况进行评估时，就可以根据各个要素的成熟度进行打分，然后汇总形成对业务能力的整体评估。我们可简单理解为做两次评分，第一次是对业务能力各分项情况进行评分(分项)，第二次是对整体业务能力进行评分(总体)。

在对各个业务能力进行评分时，就会发现有的业务能力得分较高，有的得分较低，这是我们期望看到的效果。对于业务能力评分，国内外会有多种评分及表达方式。BIZBOK在对业务能力进行评估的时候，首先分成两类，一类是已评估的业务能力，一类是未评估的业务能力。对于已评估的能力按5档划分:1.工作良好；2.较好；3.有问题但不严重；4.问题严重；5.能力缺失。

对于业务能力的评分，较为普遍、较为简化的办法是分为3档:1.问题严重(含能力缺失);2.有问题但不严重;3.能力良好，分别用不同颜色来表示。不同能力模块配上颜色后形成简单直观的业务能力热力图，如图3-6所示。

图3-6 业务能力热力图(示例)

通过图3-6的业务能力热力图，可以简单直观地暴露出整个企业的主要能力短板，便于集团及事业部高层快速发现各层级的业务能力问题、便于快速定位和决策。与此同时，建议在能力热力图上标识另外两个维度的信息;一是该能力“是否是核心能力”，二是该能力“对IT 的依赖度”。如果是核心能力，那就需要重点关注，尽早提升相关能力水平。

如果对 IT 依赖度较高，那么在规划信息化、数字化、智能化战略时，就需要重点覆盖和加强。

关于能力热力图，本章提供了基本说明，先让大家有一个初步的概念，关于业务能力热力图的深化使用，我们在第8章会进一步介绍。

3.3 信息

近 10年来，随着IT、DT技术的不断普及，越来越多人开始重视信息或数据。我们一起快速了解一下信息的概念、信息与能力的关系，以及信息架构分层等相关内容。

3.3.1 信息的概念

有多个组织和多套理论体系对“信息”给出了各自的定义。我们在本书介绍“信息”的主要目的是方便大家理解“信息是什么、信息与能力的关系是怎样的”。这里参考BIZBOK 所引用的定义，“信息是经验证为准确及时的数据，它针对特定目的而组织、在赋予它涵义和相关性的上下文中呈现，用以增加理解和减少不确定性。”

信息和数据是紧密相关的，很多场合都会把信息和数据等同起来。对于架构而言，有些企业称为信息架构(Information Architecture，IA)，有些企业则称为数据架构(Data Architecture,DA)，表示的是相似的含义。在本书中，不对“信息架构”和“数据架构”做严格区分，在进行相关描述时可以相互替代。

3.3.2 信息与能力的关系

关于信息架构或数据架构的部分，不是本书的重点，大家如果希望体系化地了解“信息或数据”的知识体系，建议可以看一下DAMABoK2.0;如果希望重点了解企业中对氢据的管理和使用，可以看一下《华为数据之道》，应该能获得不少启发。

在本书中，主要希望描述清楚信息与能力的主要关系，以及信息架构与业务架构的关系。企业在实际业务运作过程中，会涉及很多与业务相关的人、事、物，比如客户、合同、项目、产品、设备等。围绕某个业务对象，会有一系列业务活动与之相关。对于某个特定业务对象及相关业务活动的管理，我们称之为“业务能力”。与此同时，该业务对象需要通过一定方式来描述或表示，我们称之为“信息”。由此可见，业务能力和信息都与特定业务对象相关，通过业务对象，可快速形成两者的对应和映射关系，如图3-7 所示。

图 3-7 业务能力、信息与业务对象的关系

以客户为例，客户是每个企业都会涉及的典型业务对象，客户管理是一项关键业务能力，而客户信息则是客户相关的关键业务信息，如图3-8所示。

图3-8 客户相关的业务能力及信息(示例)

3.3.3 信息架构或数据架构的分层

参考上方业务能力的分层，为了简化和统一不同层级的命名逻辑，建议在描述信息架构或数据架构时，对于L1~L3层级，也采用“XX域”“XX组”“XX”来统一表达。在描述数据时，人们比较习惯于用“主题(Subject)”来描述，数据架构L1~L3层级的中文命名建议，可参见图3-9。

图 3-9 数据架构分层中文命名建议(示例)

在此补充说明一下，图3-9中对于业务流程、业务能力、数据主题按照统一的命名逻辑对 L1~L3层级进行命名，主要是方便记忆及理解不同术语的层次关系。按照这种方式来处理以后，不同架构之间(比如业务架构vs.数据架构)，在多数情况下，在层级上是能够对应的(如 L3层级的业务能力，对应L3层级的数据主题)。与此同时，也会存在一些情况，不同架构相互对应时，在层级上会有一些偏差(如L3.5层级的业务子流程，对应L3 层级的数据主题)，这都是正常情况。

3.4 组织

3.4.1 组织的概念

大多数人对于组织应该都比较熟悉，多套理论体系都对“组织”给出了各自的定义。我们在本书介绍“组织”，主要目的是方便大家理解“组织是什么，以及组织和能力的关系”，这里参考BIZBOK所引用的定义,“组织是由人组成的一种社会单位，进行系统地组织和管理以持续满足特定需求或达成集体目标。”

3.4.2 组织与能力的映射图

组织与能力的落地是紧密相关的，企业的各种能力都需要由内部或外部的组织来支撑或承载。图3-10给出了组织与能力映射的一个示意图。

图3-10 组织与能力映射图(示例)

图3-10 中方框表示企业的各种能力，分别用浅蓝色、蓝色、深蓝色来表示战略能力、核心能力(面向客户)、支持能力。椭圆相关的表示各种组织，白底蓝框代表的是整个企业，浅灰色代表业务部门，深灰色代表合作伙伴。企业的内部业务部门与外部合作伙伴，都会关联特定的业务能力。

第4章业务架构扩展要素

第3章介绍了里圈的4个业务架构核心要素，尤其针对“价值流”“业务能力”进行了重点介绍。本章会简要介绍外圈6个扩展要素的相关概念，让读者对相关要素快速形成基本认知。对于有兴趣进一步了解各个要素具体细节的从业者，笔者建议深入学习BIZBOK 知识体系。

本章涉及的主要内容有：

战略；
利益相关者；
产品；
举措；
政策；
指标。

4.1 战略

4.1.1 战略的概念

参考BIZBOK 所引用的定义：战略是一种模式或规划，它将组织的主要目标、政策和行动举措整合成一个有凝聚力的整体。

通俗地理解，战略需要澄清和解决下面3个问题：

将来要去哪？
目前在哪？
怎么去？

4.1.2 战略相关方法论

与战略规划相关的方法和工具很多，如安索夫矩阵、波士顿矩阵、SWOT 分析、五力模型、战略定位分析(SPAN)等，这里会简单介绍国内外比较主流的两套战略分析方法。

1. BLM方法论

BLM指的是业务领导力模型(Business Leadership Model)。该方法在2003 年由IBM和哈佛商学院合作开发，对IBM的战略能力提升起到了重大作用，国内华为等公司从IBM引入BLM方法，并进一步完善和推广。

图4-1 业务领导力模型

从图 4-1 可以看出，BLM 包含上、中、下 3 部分共11个模块，其中BLM的主体内容是中间部分。企业以差距为导向，通过战略制定的4个模块(市场洞察、战略意图、创新焦点、业务设计)和战略执行相关的4个模块(关键任务、人才、氛围与文化、正式组织)以达成所期望的市场结果。

下面我们简要了解一下战略制定和战略执行的8个模块。

与战略制定相关的有4个模块。

（1）市场洞察(Market Insight):对宏观、行业、客户、竞争及合作伙伴等进行前瞻

性洞察，理解趋势变化及相关变化对本企业意味着什么，识别相关机会与风险。

（2）战略意图(StrategicIntent):为企业设定未来的总体方向和目标，它包含但不限

于使命、愿景和战略目标。

（3）创新焦点(Innovation Focus):根据绩效差距和机会差距探索创新，创新包括技

术创新、商业模式创新、管理创新等。在创新投入时需要聚焦，将企业的核心资源投放在业务的关键创新点上。

（4）业务设计(Business Design)：是战略制定的关键落脚点。在对外部环境及内部资源深入理解和把握的基础上，通过业务设计来帮助企业抓住战略机会点。在早期的BLM原始版本中，业务设计包含5个要素，涉及客户选择(Customer Selection)、价值主张(Value Proposition)、价值获取(ValueCapture)、主要活动(Scope of Activities)、可持续战略控制(Sustainability)。这套业务设计思路的推出，也为商业画布九宫格体系（参考图4-2）奠定了基础。有兴趣的读者，可以进一步了解商业画布(BusinessCanvas)的内容。

与战略执行方案相关的有4个模块。

（1）关键任务(CriticalTasks):是满足业务设计和它的价值主张的要求所必须采取的措施和行动。

（2）正式组织(Formal Organization):为确保关键任务有效执行，需要建立相应的组织结构、管理和考核标准，以便指导、控制和激励个人和集体去完成企业的重要任务。正式组织是战略的载体。

（3）人才(Talent):指在重要岗位上或扮演重要角色且能完成出色业绩的人员，人才的选、育、用、留是每个市场化企业都需要重视的事项。

（4）氛围与文化(Climateand Culture):好的工作环境、积极的氛围能激发人们的活力，使企业员工更加努力，创造出色业绩。

2. 商业模式画布

商业模式是指为实现各方价值最大化，把能使企业运行的内外各要素整合起来，形成一个完整的、高效率的、具有独特核心竞争力的运行系统，并通过最好的实现形式来满足客户需求、实现各方价值（各方包括客户、员工、合作伙伴、股东等利益相关者），同时使系统达成持续赢利目标的整体解决方案。

一个成功的商业模式，可以帮助企业更高效赢得市场竞争，实现快速增长。那么，一个成功的商业模式，都包括哪些要素呢？商业模式设计的流程又是怎样的？设计商业模式的一个思维管理工具——商业模式画布可以帮助我们快速理清创业思路，规避项目风险，寻找合适的目标用户群体，建立起科学合理的商业模式。

商业模式画布主要由客户群体、价值服务、渠道通路、客户关系、收入来源、核心资源、关键业务、重要合作、成本结构九大模块组成。如图4-2 商业画布9宫格所示。

客户群体：组织机构的服务对象。
价值服务：组织机构为客户解决的问题或满足的需求。
渠道通路：组织机构沟通和交付价值的不同方式。
客户关系：组织机构和客户建立和维持的不同关系。
收入来源：客户为价值服务支付的钱。
核心资源：组织机构创建和交付上述服务所需的资产。
关键业务：组织机构创建和交付上述服务所做的工作。
重要合作：有些业务要外包，有些资源要从组织机构外部获得。
成本结构：组织机构获取核心资源、实施关键业务、展开重要合作时产生的费用。

图4-2 商业画布9宫格

商业模式是个很好的思考辅助工具，它帮助我们思考的更全面，尽早发现当下问题所在，深入思考，从而解决问题。无论是对于企业还是个人来说，利用商业模式来调整当下，规划未来都是非常重要的。

3. 战略地图

战略地图是《平衡计分卡》的作者卡普兰和诺顿输出的一套方法论。他们于1990年推出“平衡计分卡”知识体系之后，服务过很多客户，包括IBM。经过10多年的实践和沉淀，他们又于2004年推出《战略地图》。

战略地图分为4个层面：财务层面、客户层面、内部层面、学习与成长层面，每一层面都会设定相关目标，各层之间相互关联、层层递进，以确保战略目标得以承接和落地，如图 4-3所示。

图4-3 战略地图

BLM 体系从战略制定到战略执行，需要有一个战略解码的过程。而战略地图及平衡计分卡体系在战略解码方面具有一定优势，很多企业在战略实践中经常会把这两套方法结合起来使用。

战略要素会整体牵引企业的发展，国内近几年有很多企业在推动数字化转型，要实现企业的转型首先需要战略的引领。战略是一门复杂的学科，经过国内外几十年的发展，积累了很多战略分析方法和分析工具，感兴趣的读者朋友可进一步学习研究，逐步识别、融合，并在实践探索中不断迭代优化，逐步形成适合自身企业的战略管理方法论及实践。

4.2 利益相关者

在不同的理论体系里，我们经常会看到与“利益相关者”类似的词语，比如“利益相

关方”“相关方”“利益关系人”“干系人”“涉众”等，这其实是中文翻译的问题，背后对

应的英文术语都是“Stakeholder”。本书之所以倡导介绍某个中文术语时，最好把对应的

英文术语附上，一则方便大家更好地理解，二则方便学有余力的同学自己进一步追溯和探

究原文或一手资料。本节我们一并了解一下利益相关者的相关概念及关系:

·利益相关者;
·触发型利益相关者;
·参与型利益相关者;
·利益相关者地图。

4.2.1 利益相关者的概念

1. 利益相关者 (Stakeholder)

对于“Stakeholder”，在PMBOK的中文版本中，之前的版本会翻译成“干系人”，在第六版中调整为“相关者”。本书倾向于将“Stakeholder”翻译为“利益相关者”。

这里引用业务架构协会所给出的一个定义:“一个内部或外部的个人或组织，通过特定的产出/成果来获取自己感兴趣的价值。”

2. 触发型利益相关者(Triggering Stakeholder)

前面我们已经探讨过，企业中的“价值流”是为了服务目标客户的特定价值诉求而导入的。这里所说的“目标客户”就是我们所说的“触发型利益相关者”，整个价值流就是由它触发的，比如酒店服务的价值流，其触发型利益相关者就是“房客”。

3. 参与型利益相关者(Participating Stakeholder)

为了满足或实现“目标客户”的价值诉求，往往需要很多的内部、外部人员或组织共同参与进来，我们称之为“参与型利益相关者”。仍以酒店服务的价值流为例，为了满足“房客”的餐饮住宿诉求，企业内部的各个部门(如采购、房务部、餐饮部、保安部等)与外部的各种供应商都会协同配合，确保房客的诉求得以实现和落地。

各种内部、外部的参与型利益相关者，在满足和实现“房客”需求的同时，自身也会获得相应的回报。

4. 触发型和参与型利益相关者的关系

触发型利益相关者和参与型利益相关者的基本关系主要是“供需关系”。在图 4-3 中，基于“触发型利益相关者”的价值诉求导入特定价值流，在价值流各阶段，内部及外部多个部门参与其中，提供所需产品及服务。

图 4-3 触发型利益相关者和参与型利益相关者的关系图

需要补充说明的是，触发型利益相关者触发某个特定价值诉求后，它也会在某些价值流阶段参与其中。

4.2.2 利益相关者地图

利益相关者除了与价值流紧密相关，与其他业务要素也有关联。图4-4表达了利益相关者和价值流、能力及信息之间的协同关系。

图4-4 利益相关者与价值流、能力、信息关系图

4.3 产品

4.3.1 产品的概念

产品，是某种是商品、服务或者两者的组合，他所提供的的整体体验可满足客户的需要。

可以是油性的（如实物商品、一台电脑），也可以是无形的（如咨询服务）。

可以是标准型的产品或服务，也可以是定制化的产品或服务。

我们在前面讲到的客户价值诉求，最终的满足形式就是要提供相应的产品和服务。从这个角度来讲，我们可以认为产品或服务是最终价值实现的一个载体。

4.3.2 产品生命周期

产品生命周期(Product Life Cycle)理论是由美国哈佛大学教授雷蒙德·弗农(Raymond

Vernon) 于 1966年提出的。一种新产品从开始进入市场到被市场淘汰，就像人的生命一样，要经历从生到死的多个阶段。

典型的产品生命周期一般分为4个阶段，即引入期、成长期、成熟期和衰退期，如图 4-5 所示。

图4-5 产品生命周期

产品生命周期的每个阶段都有自己的特点。

1. 引入期

当一个企业推出一款新产品时，这个阶段是投入最大、最具挑战的。一方面，在新产品上需要投入大量的人力、物力进行研发和测试;另一方面，新产品刚刚投入市场需要投入大量推广费用，而同期的产品销量相对有限。

2. 成长期

在成长阶段，随着市场的逐步打开，产品销量开始强劲增长。与此同时，受益于生产规模的提升，各种生产资料的成本会被摊薄，产品利润在这一阶段也开始逐步增长。

3. 成熟期

到了成熟期，市面上会出现大量的同类产品，一般来说这会是竞争最激烈的时期，企业的目标是保持已经建立的市场份额。企业不仅需要考虑在市场销售方面的投入策略，也需要考虑产品及服务如何持续改进、持续保持竞争优势。

4. 衰退期

最终一个产品的市场会开始萎缩，进入衰退阶段。这可能是由于市场趋于饱和(所有需要购买该产品的客户都已经购买)，或者是消费者开始转向另一种类型的产品。虽然这种衰退可能是不可避免的，但企业仍有可能通过转向成本更低的生产方式和更廉价的市场来赚取一些利润。

4.3.3 产品地图

了解了产品生命周期后，我们可以简单了解一下产品与战略、利益相关者(客户)、价值流之间的基本关系，如图4-6所示。

图4-6 产品与战略、利益相关者、价值流的关系

4.4 举措

4.4.1 举措的概念

BIZBOK 给出的举措定义是:正在执行或已选定要执行的一套行动方案。当企业明确了战略方向和战略目标后，相关战略目标需要通过执行特定举措加以实现。

一般来说，相关举措真正在执行的时候，往往是借助“项目”的形式进行落地的。与项目相关，会涉及几个常用术语:项目(Project)、项目集(Program)、项目组合(Portfolio)，这三者的关系如图 4-7所示。

4.4.2 举措与战略、业务能力的关系

为牵引业务战略的落地，企业会设定明确的战略目标。相关战略目标得以达成，往往需要依赖新的业务能力或提升现有业务能力。企业会根据自己的节奏在特定时间节点设定一系列对应举措，来支撑战略目标的实现及业务能力的提升。而举措的落地，往往会涉及一系列项目或项目集，具体完成情况如何，往往会与特定指标挂钩，如图4-8所示。

图 4-7 项目、项目集与项目组合的关系

图4-8 举措/项目与战略、目标及业务能力的基本关系

在梳理举措地图时，除了了梳理与其战略目标、业务能力之间的基本关系，也可以考虑列出其价值流、价值流阶段及业务单元的映射关系。

4.5 政策

4.5.1 政策的概念

政策是用来在组织中确立方向的一些指导原则，是结合特定场景、特定目标框架及管理理念，由高级管理人员设定的指导方针。它可以是一套行动要求，用于指导和影响决策。

政策、规则等可以设计企业各方面的业务。比如，很多企业都会制定和出台相关的“差旅政策”，明确说明不同层级的人员在不同国家、不同地区所能享受的差旅标准。

4.5.2 政策与业务能力、业务组织的关系

企业的政策及规则等，往往是结合特定业务单元的情况、围绕特定业务能力相应制定的，主要是为了确保企业的业务运作更规范、更合理、更高效。图4-9展示了政策与业务能力及组织之间的协同关系。

图4-9 政策与业务能力、业务组织的关系

4.6 指标

4.6.1 指标的概念

参考BIZBOK所引用的定义，指标（Metric）是一种度量标准，通过它可以评估计划、过程或产品的效率、性能、进展或质量。

企业在日常运作过程中，通过对方方面面指标的监控，来了解业务运作状态是否健康。与指标的使用和管控相关，《平衡计分卡》一书中提到了两种类型的指标，一种是“滞后指标”，对应的英文是“Lag Indicators”;另一种是“领先指标”，对应的英文是“Lead Indicators”。

国内有很多从业者将“Lag Indicators”翻译为“结果性指标”，主要指“指销售收入”、“利润”等最终指标。同时将“Lead Indicators”翻译为“过程性指标”，可以理解为为了产生收入和利润在前置业务过程中需要看的指标，比如“目标客户”、“目标客户覆盖率”、“商机金额”等。“结果性指标”、“过程性指标”这种叫法，对业务人员而言更容易理解。

4.6.2 指标与战略、行动的关系

在前面介绍“举措”与其他要素的关系时，已经涉及“指标”。图4-10参考了卡普兰的《平衡计分卡》，描述了“指标”与业务战略、战略目标、举措行动之间的关系。

图4-10 指标与业务战略、战略目标及举措行动的关系

围绕指标，很多国内企业都在构建数字化运营体系。为了能让指标体系真正发挥作用，有下面五点建议可以参考：

指标需要能反映“目标”；
指标可以快速判断“好坏”；
指标体系含内在关联、可分解；
指标可多维展示并灵活下钻；
指标可指导、触发“行动”；

第三部分业务架构进阶

通过第二部分的介绍，我们基本了解了业务架构的核心要素及扩展要素有哪些，也基本清楚了每个业务要素的概念和大体的作用。

有了第二部分的铺垫之后，我们要在第三部分对业务架构各要素做进一步贯通与剖析，来加深对业务架构自身及周边要素的全面理解。

先掌握业务架构核心要素间的关系:业务架构核心要素是我们掌握和应用这套知识体系的关键所在，我们会围绕“价值流”“业务能力”“信息”“组织”这4个核心要素并结合“流程”分析和梳理这些核心要素之间如何有效协同。
再探讨业务架构核心要素与扩展要素的整体协同:在理解核心要素配合关系的基础上，进一步关联其他扩展要素(如战略、利益相关者、产品、举措等)，形成业务架构核心要素与扩展要素的整体协同视图。
最后深入探讨业务架构与其他架构的关系:在企业架构中，除了业务架构，还包含其他架构(如数据架构、应用架构、技术架构等)。在掌握了业务架构内部要素之间的关系后，我们需要进一步了解业务架构与其他架构的关系。

第5章业务架构核心要素之间的关系与协同

前面我们介绍了4个业务架构核心要素的基本知识，本章会重点梳理和明晰相关核心要素之间的关系。尽管在BIZBOK知识体系中，没有把“流程”当作一个独立的要素，但我们在分析要素间关系时，会适当结合“流程”一起梳理。

大家对酒店住宿的场景比较熟悉，也容易理解，本章仍会围绕酒店住宿的示例逐步进行展开，涉及的主要内容有:

价值流;
价值流+能力;
价值流+端到端流程;
价值流+端到端流程+能力;
价值流+端到端流程+能力+信息;
价值流+端到端流程+能力+信息+业务对象。

5.1 酒店住宿示例：价值流

对于酒店住宿场景的客户而言，他们想要的是一享受酒店服务，这是酒店的基本“价值”所在。围绕客户的这个价值诉求，可引出一个简单的价值流，包括“预订房间”“入住”“享受酒店服务”“离店”4个价值流阶段，如图5-1所示。每个价值流阶段，都会以结果为导向，实现某个“价值项”。比如“预订房间”阶段，给客户带来的价值点是“我订上房间了，放心了”;比如“入住”阶段，给客户带来的价值点是“我拿到了房间钥匙，我有房间可以住了”，等等。如果在每个价值流阶段都能顺利交付“价值项”，那么各阶段合在一起就能交付整体价值。

站在企业角度，该价值流所要实现的价值主张是“让顾客享受优质的酒店服务”。当我们从价值流出发来设计或分析业务时，全程都以实现特定客群的特定价值诉求为目标，

避免走偏。

图5-1 酒店住宿的价值流及价值流阶段示意图

5.2 酒店住宿示例：价值流+业务能力

为了实现价值流各阶段的“价值项”，背后需要企业的“业务能力”提供支撑。比如，在“入住”环节，要快速核实客户信息，需要“客户管理功能”;要核对清楚预约房型的具体要求，需要“订单管理或协议管理功能”;要快速判断有没有房间，需要“房间管理功能”;要收押金或预付金，需要“支付管理功能”，等等。

业务架构协会(BAGuild)认为，要开始业务架构相关实践，梳理“价值流+业务能力”交叉映射图是最基础的要求。“价值流+业务能力”交叉映射图其实也是一个相对高阶(High Level)的展示，比较方便向高层管理者进行汇报。比如，快速看清某个业务涉及哪几个阶段，每个阶段都对应哪几个能力。基于不同颜色(如红/黄/绿)的业务能力热力图，可以让管理者很直观地看到哪些能力须加强、哪些能力须新建。图5-2是酒店住宿“入住”环节的价值流阶段与业务能力映射图示例。

图5-2 价值流阶段与业务能力映射图示例

从图 5-2 可以看出，某个价值流阶段要实现特定“价值项”，需要有一个或多个业务能力来承载或支撑其真正落地。

5.3 酒店住宿示例：价值流+端到端流程

对于业务逻辑、业务场景比较简单的业务，我们把一些“能力”按照一定的顺序放在一起，相关人员“脑补”一下，就能大概知道业务整体涉及几个环节，如何相互配合并闭环落地。但对于有一定复杂性的业务，或者是把能力拆解得比较细的业务，把一个个能力模块放在上面，相互之间还是比较“离散”的，并没有一条清晰的线把它们串起来，也无法确保每个环节都责任到人，进而无法确保端到端有效落地。

而“端到端流程”能够把业务过程的相关要素(多个具体事项、相关信息、责任人等，有序地串在一起，能够清晰地展示各个环节如何流转，以及各环节对应的具体负责人，利于确保某个事项端到端闭环落地，如图5-3所示。

图5-3 价值流阶段与相关流程对应关系

图5-3基于“入住”阶段，对流程活动进行了展开说明，对于希望了解整体业务过程的人员而言，这种表达方式提供了更完整、更具象化的业务过程闭环信息。

5.4 酒店住宿示例：价值流+端到端流程+能力

端到端流程的不同环节，需要有相应的业务能力来支持，有的可能只需要纯业务方面的支持，有的还需要IT方面的支持，共同组成“价值流+端到端流程+能力”的映射图。

同一个能力，尤其是IT 部分的能力，可以被多个不同业务场景的端到端流程所复用。企业下沉和积淀的公共能力越多，可被各个流程复用的就越多，可大大提升企业在能力建设方面的投入产出比(ROI)。与此同时，抽象和沉淀公共能力，也有利于企业快速使能、快速启动新业务。(我们经常听到“中台”这个概念，其关键落脚点也是在“能力复用”上。)

图 5-4表达了特定价值流阶段(“入住”)所涉及的相关业务能力及具体流程活动。

图5-4 价值流阶段与流程及能力的对应关系

5.5 酒店住宿示例：价值流+端到端流程+能力+信息

上面提到了流程需要能力来支持，有的能力是纯业务方面的能力(人工)，有的会涉及IT 方面的能力。过去几十年，多数企业以“信息化”为主导，典型场景是“流程自动化”，利用 IT技术实现“自动化”。近5~10年，有很多企业开始考虑“数字化”“智能化",信息和数据越来越成为构建企业能力的关键要素，进而促进企业流程优化、降本增效。

图5-5 示意性地表达了特定价值流阶段(“入住”)所涉及的流程、能力与信息之间的对应关系。

5.6 酒店住宿示例：价值流+端到端流程+能力+信息+业务对象

实际的企业业务活动，每天都是围绕“业务对象”发生的。对于能力、信息而言，只有围绕“业务对象”来构建，才能确保相关业务建模、数据建模能紧扣业务实际，符合业务本质。

图5-5 价值流阶段与流程、能力及信息之间的对应关系

尤其当一个企业的业务逻辑、业务流程、业务能力错综复杂的时候，围绕“业务对象”进行梳理和发力，相对容易快速捋顺业务当中的主要业务实体及实体间的相互关系，更容易实现统筹考虑、分工负责、能力复用和数据复用。

图5-6示意性地表达了特定价值流阶段(“入住”)所涉及的端到端流程、业务能力、信息和业务对象之间的基本对应关系。

在图 5-6 中通过箭头来示意“业务能力”、“信息/数据”和“业务对象”之间如何关联，

方便理解三者之间的关系。

图5-6 价值流阶段与流程、能力、信息及业务对象之间的对应关系

第6章业务架构核心要素与扩展要素之间的整体协同

清楚了4个核心要素之间的关系，接下来我们进一步了解业务架构核心要素与扩展

素之间如何整体协同。

本章所涉及的主要内容有:

业务架构整体要素全景图;
战略与其他业务要素的关系;
Where 相关视角及主要业务要素;
What 相关视角及主要业务要素;
How 相关视角及主要业务要素;
整体监控及优化的相关视角和要素。

6.1 业务架构整体要素与全景图

对于一个企业的整体运作，除了价值流、业务能力、信息、组织这4个核心要素，还会涉及战略、利益相关者、产品、举措、指标等业务要素，所有这些业务要素只有实现整体协同，才能确保企业的高效运转。图6-1表达了业务架构主要元素的整体关系。

图6-1 业务架构主要元素的整体关系

6.2 战略与其他业务要素的关系

对于企业的负责人或管理者，可以通过多个视角来观察和推动企业的整体业务运行实现“战略从制定到执行”的整体落地。

企业的高效发展，需要从战略视角来整体牵引，进而分解落地并紧密监控。

首先需要考虑“Where”的问题一确定企业的发展方向、目标客群和产品组合等。
紧接着要考虑“What”的问题一识别实现战略目标所须完成的关键任务及年度重要工作。
最后要解决“How”的问题一确保相关举措/项目能够顺利执行、交付落地。
在企业运行的整个过程中，需要通过合适的指标体系进行整体监控，以便及时感知企业战略执行落地情况，并根据企业需要适当地对战略进行调整和优化。

6.3 Where相关视角及主要业务要素

一个企业要获得长期可持续的发展，首先要解决企业发展方向、战略目标的问题一将来要去哪?

对于一个市场化的企业，其生存之本是服务客户并获得价值回报。要实现这一点，须具备两方面条件。

（1）企业有能力针对目标客群的价值诉求，提供相应的产品和服务。

（2）在供大于求的市场竞争环境下，企业有能力提供有竞争力的产品和服务。

上述第一点是基础，如果做不到，企业根本无法进入特定市场或特定领域。而对于能进入特定市场的企业，如果做不到第二点，依然会出局、被市场淘汰。所以上述两个方面需要在进行市场洞察时同时考虑。

在考虑上述两方面条件时，主要会涉及两个业务架构扩展要素，如图6-2所示。

图6-2 Where相关视角及业务要素

（1）利益相关者(Stakeholder);利益相关者有外部的，有内部的，可以包含多种角色。

首先我们需要从外部客户视角进行洞察和分析，确保企业充分了解相关目标客群及其价值诉求，了解周边环境、行业发展情况及价值转移趋势。
同时我们需要从对手/伙伴视角进行竞争及合作分析，找到合适的竞合思路和机会。

（2）产品(Product):这里所说的产品，可以是有形的产品，也可以是无形的服务。在产品能满足客户的基本价值诉求的基础上，通过差异化特征，增强对客户的吸引力。

6.4 What相关视角及主要业务要素

企业在识别和定位了目标客群后，需要围绕特定目标客群的价值诉求来新建或优化主业务流，以确保能实现和满足客户的价值诉求。为方便理解，我们可以认为“价值流”就是从客户的价值诉求出发，通过各个价值流阶段不断创造和实现客户价值的高阶主业务流。相比于日常所说的“流程”而言，“价值流”的目标导向更强、更清晰，它的存在就是为了实现客户的价值诉求，如果相关环节无法带来“价值增量”，那么该业务环节就可以弱化甚至去除，有利于避免企业里流程越做越繁重、内耗越来越严重的问题。

各个价值流阶段要产出“价值增量”或“价值项”，就需要相关“业务能力”支撑才能真正落地。本书在第3章中介绍了业务能力解构的相关内容，业务能力包含5个要素，不同方面的能力构建离不开各业务单元在组织层面提供的相应支持。

通过对企业整体的业务能力进行分析，可以识别有哪些业务能力是达成战略目标亟须新建或提升的，尤其是和企业核心竞争力相关的业务能力，需要通过战略举措或重点项目进行打造和提升。

图 6-3 展示了 What相关的4个主要视角、业务要素及要素间基本关系。

图 6-3 What相关视角及业务要素

6.5 How相关视角及主要业务要素

通过Where环节确定了企业发展方向和战略目标，并通过What环节找出了关键能力差距，识别出了重要举措及重点项目，接下来需要通过“执行与交付视角”，确保相关举措及项目顺利执行落地。

在具体实施项目过程中，除了考虑业务架构，同时需要考虑数据架构、应用架构及技术架构等相关内容，确保各个架构之间能够有效协同并指导项目落地，如图6-4所示。

图6-4 How 相关视角及业务要素

首先须提供融合4A的整体解决方案。
基于相关解决方案，进行有效实施。
实现产品或服务的交付，并提供让客户满意的售后支持。

这个环节主要解决如何把事做正确-Dothings right，确保整体项目高效交付，向内部、外部客户提供有竞争力的产品和服务。

6.6 整体监控及优化的相关视角及要素

企业的战略从制定到执行，整体链条中涉及的环节很多，周期也很长。

（1）在战略制定过程中，有可能会因为市场洞察不足或判断失误，未能识别出特定时期的某些战略机会点。

（2）在战略执行过程中，某些业务部门可能会出现动作变形、执行效果与战略目标有偏差的现象，这是多数企业必须面对的一个现实风险。

无论是战略制定还是战略执行，企业都可以通过“指标视角”(图6-5)梳理并设计出合理的指标体系及监控机制，及时发现机会差距，及时感知企业战略执行落地的绩效差距，并根据企业需要适当地对战略进行调整和优化。通过及时纠偏，让企业发展重回正轨。

图6-5 整体监控及优化的相关视角和要素

第7章业务架构与其他架构的关系

我们首先通过第5章了解了业务架构核心要素间的关系，进而通过第6章了解了业务架构核心要素与扩展要素的整体协同，接下来我们进一步探讨一下业务架构与其他架构的关系。

关于企业架构的主要组成部分，业内目前有多种理解，有的认为企业架构应以“业务架构、应用架构、技术架构”为主要框架，“数据”相关内容融入这3个框架中；有的认为企业架构主要是4A，分别是业务架构(BA)、数据架构(DA)、应用架构(AA)、技术架构(TA)；有的认为企业架构需要考虑5A，在4A的基础上还要考虑解决方案架构；有的认为还需要把安全架构结合起来，考虑6A。

目前来说，4A是国内相对比较主流的提法，我们会基于4A来探讨业务架构与其他架构的关系:

业务架构与其他架构的基本协作关系；
架构分层及中文命名建议。

7.1 业务架构与其他架构的基本协作关系

业务架构是企业架构的一个重要组成部分，为了能对整体有一个更全面、更清晰的了解，我们先看看企业架构的位置，然后探讨企业架构中主要架构的基本协作关系。

7.1.1 企业架构的位置

在前面的章节中我们提到，企业架构是贯通企业战略和具体落地项目的桥梁。利用企业架构能更好地理解和承接业务战略的相关诉求，并指导具体举措及项目落地。与此同时，在具体项目执行过程中，也需要复核相关项目是否遵循企业架构的原则和要求，以确保项目落地时不走偏，高效准确地支撑业务战略实现，如图7-1所示。

图7-1 战略一企业架构一项目的基本关系示意图

7.1.2 企业架构中主要架构的基本写作关系

前面我们提到，关于企业架构的主要组成，4A是目前相对主流的提法。关于4A之间的配合关系，笔者结合多套理论知识体系及实践感悟，融合输出了业务架构(BA)与数据架构(DA)、应用架构(AA)、技术架构(TA)之间的基本协作关系图，如图7-2所示。

图7-2 BA与DA、AA、TA的基本协作关系

图 7-2 中的各个要素用圆圈表示，各个要素之间的连线表示要素间的关系。该图主要表达了5点。

（1）围绕业务对象(Business Object):典型的业务对象有“产品”“客户”“合作伙伴”“合同”“订单”等，企业的实际业务都是围绕这些业务对象展开的，相应的业务架构、数据架构、应用架构也应该围绕“业务对象”来设计，这也会有利于企业架构各组成部分的整体协同。业务对象可以根据实际情况分出不同层次，分别进行定义和描述。比如产品从大到小可分出3个层次，如“产品族”“产品组”“产品”;比如合同可分出两个层次，第一层是“合同”，第二层根据合同的不同特点可分解为“销售合同”“采购合同”等。

（2）业务架构(BA)整体牵头：总的来说，数据、应用、技术等都是为业务服务的，要想让其他要素服务好业务，那么首先需要先说清楚业务。在这四者中，业务架构起到整体牵头的作用；否则，各干各的，无法真正实现基于业务的整体协同，实际效果会很差。

（3）数据架构(DA)全局拉通：数据已经成为一个重要的生产要素，各个企业需要沉淀企业级数据资产并挖掘数据价值、赋能业务。数据，尤其是“主数据”，会贯穿多个业务单元、多个业务环节，起到全局拉通的作用。

（4）应用架构(AA)合理呈现：应用架构的主要作用是呈现。把业务对象所涉及的相关业务活动，通过线上化的方式呈现给业务用户，以便更高效地执行业务活动。

（5）技术架构(TA)有效支撑：在业务架构牵头之下，形成与业务架构协同的数据架构、应用架构之后，需要技术架构进行统一支撑。

7.2 业务架构分层级中文命名建议

7.2.1 目前架构分层级命名相关的主要问题

当我们谈论企业架构时，任何一个企业的架构体系都会有一定的深度和复杂性，不可能通过一个层级就把问题说清楚，我们需要面对“如何分层”的问题。

以流程为例，国内各个企业在流程分层方面可以说是百花齐放。

各个企业甚至同一企业的不同事业部都有各自的分层逻辑，有的分5级流程，有的分6级流程，有的甚至拆解到了7级流程。
各企业不同层级流程的中文命名的具体名称及命名逻辑也各不相同，比如L1层级流程，经常看到“流程分类”“类别”“流程域”“业务领域”等;到了L2层级流程，会看到“流程组”“流程子域”“业务子领域”等。

上面的例子说的是流程分层，可以理解为是业务架构(BA)范畴内的问题。与此同时，除了业务架构(BA)，数据架构(DA)、应用架构(AA)等也会涉及分层命名的问题。经常会发现同一企业的不同架构，在处理层级命名关系的时候，缺乏基本一致性，甚至每一套架构都有各自的分层命名。前面的章节也提到过，我们不能说这种分层命名方式是错的，但的确给相关使用者增加了很大的记忆难度，非常不利于用户对架构知识体系的快速认知和推广使用。

7.2.2 业务架构分层建议

为方便企业架构在企业内的导入和逐步推广，本书建议尽量统一并简化分层逻辑。对于已经有成熟架构命名规则及配套体系的企业，可以继续沿用已有的分层命名体系。而对于暂不具备成熟企业架构体系的企业，在准备引入或新建企业架构体系时，下述分层思路可以作为一种参考选项。

（1）在第2章，我们简单介绍了PCF，它是由APQC组织上百家企业共同推出的，是一套比较成熟的流程分层框架。在对业务架构进行分层时，我们建议参考PCF的5层基础分层。对于 L1层级的中文命名，前面的章节也曾提到，如果对应PCF的英文原文“Category”，从字面角度正常会翻译为“流程分类”。但国内有不少人员习惯将高阶的层次称为“XX域”或“XX领域”，笔者建议将流程的L1层级命名为“流程域”。对于L2层级的命名，对应英文原文“ProcessGroup”可正常翻译为“流程组”。对于L3层级的命名，对应英文原文“Process”可正常翻译为“流程”。相应地，L4层级的“Activity”翻译为“活动”，L5 层级的“Task”翻译为“任务”。图7-3给出了参考PCF的5级流程及各层级建议的中文名称。

图7-3 参考 PCF5级流程的各层级建议的中文名称

（2）随着企业的不断发展，业务体系会越来越庞大、越来越复杂，企业可以根据实际需要适当进行扩展，比如流程域(L1)，可以扩展出流程子域，层级为L1.5;流程组(L2)，可以扩展出流程子组，层级为L2.5;以此类推，子流程为L3.5，子活动为L4.5，子任务为L5.5。理论上可以5层为基础，每层加入0.5的扩展层，总共可以分出10层，应该可以满足所有企业的需要。

（3）另外一个可扩展机会是，如果需要在原先L1层级的基础上，向上合并，可以加设LO层级及L0.5扩展层。

上述3点结合起来，形成一个“基础分层+扩展分层”的弹性分层体系总体结构。通过5层基础分层，能确保流程分层的基本稳定性，利用扩展分层可以根据企业的发展情况适当扩展。既能满足各行各业绝大多数企业的基本分层需要，且方便与国际主流分层框架对接，与此同时，也能较好地满足企业动态发展、后续灵活扩展的需要，确保整个架构是相对稳定、可持续扩展的。

7.2.3 弹性分层体系的典型应用

在具体应用弹性业务分层体系时，不同规模的企业可以结合企业自身需要进行考虑，下述典型应用可以作为一种参考建议。

1. 对于中小企业

5层基础分层基本上就能满足中小企业的需要，层次过多反而容易把流程或能力做得过重，以流程视角为例，这5层分别是“流程域、流程组、流程、活动、任务”，和APQC推出的PCF5层框架保持一致。基于该分层结构，无论是和国内其他企业对接，还是和国际企业合作对接，都可以有基本的共同语言。随着企业的不断发展壮大，企业的业务体系、组织结构、人员规模都会进行扩展、变得更加复杂。为了更好地伴随、助力企业发展，利用“弹性业务分层结构”可以进行针对性灵活扩展，这种应对方式既能保持企业流程有一定的继承性和稳定性，也能实现较好的可扩展性。

2. 对于大型企业

对于大型企业，往往已经在业务流程体系方面形成了一定的积累。有很多企业会在PCF的基础上，结合自身业务的复杂性进行一定的拓展和调整。对于国内大型企业，比较主流的是6层流程体系。对于已经构建了6层成熟体系的企业，可以继续保持和完善。其实，通过图 7-4 的对应关系容易看出国内企业6层结构所增加的一层(L4层级，子流程)是在PCF5层结构的第3层扩展出来的。

图7-4国内常见的6层流程体系与弹性分层体系的对应关系

通过图7-4的对应关系，可以看出本书建议的“5层基础分层+扩展分层”弹性分层体系是可以涵盖6层流程分层体系的。实际上，在企业发展过程中，各事业部、各领域并不是均衡发展的，往往是某几个业务领域在某个时期会更加深入、更加复杂，需要分解为更多层次，而某些领域则相对简单。基于这种情况，我们可以在5层基础分层之上，根据企业发展的需要或者结合特定业务领域的情况对L1、L2、L3 或L4、L5层级进行有针对性的扩展，以灵活应对、满足实际业务需要。

7.2.4 统一和简化各架构的各层级中文名称

前面章节也部分提及，除了业务架构涉及分层和命名的问题，数据架构、应用架构也会涉及。为便于记忆、便于推广企业架构，建议统一、简化相关架构的各层级中文名称：对于L1层级，统一命名为“XX域”;对于L2 层级，统一命名为“XX组”。图7-5是笔者建议的业务架构、数据架构、应用架构的各层级中文名称。

图7-5 业务架构一数据架构一应用架构的各层级中文名称

需要补充说明的是，不同架构之间会存在对应关系。上述命名方式有利于统一理解和记忆各架构的各层级名称，在多数情况下，某个层级的业务架构基本都能对应上相同层级的数据架构和应用架构，但少数情况下不同架构间的层级对应也可以不一致。

第四部分业务架构落地

通过第三部分的介绍，我们已经了解了业务架构里圈、外圈所包含的10个主要业务要素之间的整体配合关系，也进一步理解了业务架构(BA)与数据架构(DA)、应用架构(AA)、技术架构(TA)的协同关系。从本部分开始，我们会介绍业务架构落地及实践相关的内容，部分实践探索会在第四部分介绍，更多的实践内容会在第五部分进行展现。

有了前面铺垫的基础，我们接下来分两方面介绍业务架构落地相关内容。

1. 业务架构的关键交付物：业务架构涉及的要素很多，核心的交付物主要是企业级的流程框架体系或企业级业务能力框架体系。相关的框架体系一般都会是一个层级结构。本篇会结合制造行业企业的情况，给出L1、L2层级参考性业务能力框架及部分 L3 层级能力分解示意图。

2. 业务架构与 DDD协同落地：业务架构的产出物输出以后，会面临如何具体落地的问题。DDD(领域驱动设计)体系可以和业务架构体系形成优势互补，协同落地。

第8章业务架构的关键交付物

在业务架构的众多要素中，业务能力或业务流程是最主要、最核心的要素。业务架构最关键的交付物可以是一套企业级流程框架体系，也可以是一套企业级业务能力框架体系，或者是业务能力与流程融合而成的一套框架体系。

本章涉及的主要内容有：

流程视角与能力视角的比对分析；
不同视角业务架构落地所须解决的共性问题；

业务能力视角的业务架构梳理(以制造行业企业为例)。

8.1 流程视角与能力视角的比对分析

本书在前面第2章提到，目前有两套主流业务架构体系，一套是以流程为主的框架体系，一套是以能力为主的框架体系。我们在本节会对两者进行进一步比对分析，以期形成更深入、更清晰的理解。

8.1.1 能力视角

我们在第3章介绍过，可以把能力简单理解为“做事”的能力。在本质上，它是一个劳动生产的过程，并基于生产力的相关要素对“业务能力”进行了解构，要素更完整、更清晰。

简而言之，业务能力包含了“劳动对象、劳动者、劳动资料、劳动产品、劳动过程”这5方面(如图8-1所示)。这里的劳动过程描述的是劳动对象怎么一步一步地由劳动者利用相关工具设备把它加工成产品或服务，这个过程其实就是我们平常所说的“流程”。

图8-1 业务能力之构成要素关系图

一般来说，这5方面都具备而且分别达到一定质量水平，才能确保整体业务能力达到较高水平。只有5方面都得到保障，企业才能在真正意义上具备该业务能力，才有机会进一步将某些关键能力逐步打造成企业的核心竞争力。

8.1.2 流程视角

和流程相关，我们会看到各个企业一般都有各种流程图。对于流程图而言，大家普遍认可的是通过业务流程建模符号体系(BPMN)来表达整个流程。比较典型的流程图往往会包含以下3方面信息。

（1）会有多个泳道，每个泳道对应的都是特定的部门、角色或参与方，在泳道里面会有多个业务活动，相关活动都有特定部门/角色来负责。

（2）不同泳道之间及同一泳道的多个业务活动，一般会通过带箭头的连线进行连接，来表达每个活动的先后顺序和配合关系。

（3）每个业务活动都可以标注对应的IT系统。

从狭义的角度来理解，我们上面所说的流程图，就是我们所说的“流程”。流程告诉大家，某件事或某个产品是怎么一步一步做出来的。对于一个企业而言，首先要解决流程“有没有”的问题，如果连流程都没有梳理出来，往往代表该企业在特定业务领域的积累沉淀及专业水平比较有限。

当企业有了业务流程以后，接下来就会涉及“流程执行落地”的问题。当我们真正在执行某个业务生产流程时，如果原材料供应不上，流程跑不起来;如果某个流程角色没有人到岗，流程跑不起来;如果生产所需的工具或设备不到位，流程跑不起来，或者生产出来的产品，质量很差。

通过上面的介绍，大家可以了解到，当我们谈“流程”的时候，狭义上的流程就是一张流程图或流程文档，告诉大家一步一步怎么做。广义上的流程，指的是“流程的整体执行”，可以关联或包含流程所触及的方方面面。

8.1.3 流程视角与能力视角的对比

通过上方对业务能力、业务流程的进一步解析，我们不难发现，我们所说的“业务能力”和广义的“流程”(流程的整体执行)所涉及的东西是类似的：都会涉及干活的组织/人员、原材料和相关工具/技术、干活的具体步骤，以及做出来的产品或半成品。

我们可以从“业务能力”视角把企业的业务说清楚；也可以从“流程执行”的视角把企业的业务说清楚，来确保某件事能真正落地。所以用这两种视角来描述业务框架体系，都说得通。但相对来说，笔者认为“业务能力”所包含的要素更为全面，理解起来也更加通顺。

与此同时，这里也简单提一下两者的主要差异。

流程的“连续性”特点是比较突出的，无论是中高阶流程(L1~L3层级)还是低阶流程(L4~L5层级)，它都会强调相关步骤的连续性，强调事情怎么一步一步做出来。它的不利之处在于，流程比较强调“埋头做事”，容易迷失方向。很多企业在构建流程体系以后，流程会越做越繁重，很多流程也容易交织在一起造成混乱，甚至有些部门在执行流程的过程中迷失了业务的初衷，为了流程而流程。
能力的“离散性、模块化”特点相对突出。利用“模块化”的特点，对复杂体系的不同部分进行拆解、设立边界会相对容易。比较容易快速定位哪个模块出了问题、相关责任人是谁。相比于流程，能力的确不容易反映出“流”的特征。但这个方面可以发挥“价值流”的优势来弥补。价值流的一个突出优势是，业务指导方向很清晰，始终以客户“价值诉求”为目标来考虑业务、对“客户价值实现”没有帮助的事都应该简化或去掉，这有利于避免业务流程越做越繁重的问题。由“价值流+业务能力”构成的交叉映射图，可有效指导整体业务的构建和良性发展。

8.2 不同视角下业务架构落地所需解决的共性问题

无论是构建业务流程框架体系，还是构建业务能力框架体系，都须解决一些共性问题：

业务架构原则；
业务架构盘点与分层；
构成要素及描述卡片；
流程/能力框架热力图；

8.2.1 业务架构原则

在进行业务架构梳理和设计时，需要考虑业务架构的特点并结合企业的情况先确定业务架构原则，如图8-1所示。业务架构原则可指导业务架构工作的具体开展，尤其是在分层或分模块过程的过程中遇到不太好判断的问题，可以回归到架构原则进行思考和决策。

表8-1业务架构原则（示例）

不同的企业或同一个企业的不同发展阶段，业务架构的指导原则可能不同，表8-1提供了部分业务架构原则供参考。在具体实践过程中，每个企业都需要结合自身情况制定出适合自身的架构指导原则。

8.2.2 业务架构盘点与分层

关于架构分层及命名问题，本书已在第7章进行了探讨和介绍。这里我们探讨一下从业务架构实践角度出发，无论是业务流程分析，还是业务能力分析，都会涉及的盘点及分层问题。

一个企业在进行业务架构梳理时，往往会涉及两个方向的问题，一个是广度，一个是深度。

（1）广度方面：主要考虑梳理时的业务覆盖范围，我们可以对单个事业部进行业务架构梳理，可以对多个事业部进行梳理，也可以对全集团进行整体的业务架构梳理。

（2）深度方面：指业务架构的梳理层级。比较常见的业务架构交付是梳理到L3 层级，形成 L1~L3层级业务能力框架体系或业务流程框架体系。在实际执行过程中，可以根据企业的实际需要进行相应调整和扩展。比如，有些企业希望能梳理到L4层级，有的企业甚至希望梳理细化到L6层级，细化到不同层级所需要投入的资源也会相应增加。

8.2.3 构成要素及描述卡片

基本解决了分层问题以后，每个层级都会有一些业务流程或业务能力。对于这些流程或能力，需要基于构成要素、以一定的方式对它们进行结构化描述，我们称之为业务流程卡片或业务能力卡片。完整、高质量的流程卡片或能力卡片，对企业而言是一种有价值的资产，它有利于统一老员工的共识，也利于新员工快速了解企业特定领域的业务。

流程卡片或能力卡片，比较常见的有两种表达方式。

（1）通过行式结构来表达(EXCEL):每个流程或能力都会形成一行，不同的列代表该卡片的各种属性，同一行的不同单元格对应的是各列的属性值，通过EXCEL表的行式结构来表达，方便汇总及整体分析，也有利于后续与其他架构(数据架构、应用架构)进行对应和标识。它的不便之处在于，当列比较多时，描述某个流程或能力的这一行会跨好几屏，需要来回拖动鼠标才能看完整。

（2）通过方框式结构来表达(EXCEL/PPT):这种方式像卡片，以这种方式进行输出，我们一般称为“XX卡片”，卡片方式便于可视化呈现单个流程或能力的整体情况。当卡片的结构确定以后，以EXCEL或PPT形式来进行记录都可以，梳理出相关卡片之后，便于团队内部的沟通、评审及向上汇报。

8.2.4 流程/能力框架热力图

无论是流程视角还是业务能力视角，我们的目的都是有效解构业务，有效反映整体业务状况，需要让领导及相关人员简单、清晰地了解企业哪些方面做得好、哪些方面需要提升。热力图是一种行之有效的表现方式，通过它不同颜色的展现，能简单直观地把业务全景及局部问题暴露出来。

利用前面所提到的流程卡片或业务能力卡片，基于卡片中相关要素的实际情况，可参照特定指导规则进行评估或打分，然后结合相应的标准对应出不同颜色。我们对不同能力或流程用颜色进行标识以后形成热力图，便于企业高层或相关负责人在一个全景图中快速看清有哪些主要流程或能力及哪些模块有问题，可高效辅助决策。

8.3 业务能力视角的业务架构梳理（以制造行业企业为例）

关于流程视角的实践案例会在后续章节介绍。本节会结合制造行业企业的例子，从业务能力视角，分别介绍下述3方面主要内容:

企业级业务能力梳理；
业务能力热力图；
业务能力建设/提升思路。

8.3.1 企业级业务能力梳理

1.业务能力识别

关于业务能力的识别，前面已经提过，有下述4种常见方法。

（1）基于企业运行所涉及的业务对象来识别。

（2）利用企业已有流程来识别。

（3）参考业界最佳实践或成熟模型。

（4）利用成熟软件包中相关分类进行识别。

其中上述第1种方法是最基本的方法，也是业务架构协会(BA Guild)比较推荐的方法。

2.业务能力卡片：全景卡片+简化卡片

全景化的能力卡片，其好处是能把特定业务能力的方方面面看清楚，方便识别各方面表现，看清问题出在哪方面。但它的不利之处也比较明显，就是需要梳理的内容较多(目前列了 11个分项，参见表8-2)，做起来会比较“重”。往往在针对特定能力进行全面、深入分析时，可以考虑使用完整的全景卡片来描述。

表8-25要素全景业务能力卡片

在很多情况下，集团企业或事业部可根据实际需要对上述模板进行剪裁或调整。比如近些年随着国内“两化融合”等政策的推动和发展，很多企业都在推进数字化转型工作。对于数字化转型项目，侧重数字化相关内容，主要考虑“流程”“组织”“数据”“IT应用这4方面，我们可以将能力卡片进行简化和裁剪，如表8-3所示。

表8-3 数字化项目参考业务能力卡片（简化版）

3.业务能力整合

对于大型集团企业，很可能多个事业部涉及相同或类似能力，需要考虑整合复用。

不同事业部，甚至同一事业部的不同业务线，涉及相同能力但业务能力水平参差不齐。
较为理想的应对方式是上升到集团层面，统一评估业务能力状况并统筹安排。

在梳理业务能力的过程中，结合相关指导，可大体判断出某一个能力在不同业务块的表现。当某个能力涉及多个事业部或业务线时，比较建议在集团层面统一整合考虑。具体的整合能力建设，有的可以由集团牵头，有的可以在相关业务部门中找出该能力相关度或比重最高的业务部门及负责人来牵头。

图 8-2 表示某集团的3个事业部都涉及某个特定的能力(能力C)。有可能在不同事业部的名称或叫法会有差异，通过拉通梳理，有利于企业识别不同事业部所涉及的相同能力

或近似能力，为进一步整合打下基础。

图8-2 多事业部业务能力整合分析示意图

一般来说，在某个事业部内部比较容易全盘拉通分析该事业部涉及哪些核心价值流、多少能力及能力复用情况。当我们要在集团层面跨事业部进行分析比对时，相对来说推动难度会大一些。

8.3.2 业务能力热力图

关于业务能力热力图，涉及两方面，一是能力评估，二是热力图展现。在介绍热力图展现时，我们会循序渐进地给出“全景图”“局部分解图”和“能力细化图”，层层细化，以便理解和参考。

1. 业务能力评估

基于上方提到的业务能力卡片，各企业可根据各项目需要进行剪裁和调整。确定一个基本模板后，就可以开始梳理和描述业务能力卡片。

一个大型企业往往会包含多个事业部，可以个别事业部先行梳理，也可以进行企业整体梳理，在具体应用业务能力卡片时可结合企业所需的节奏来进行实施，图8-3简单展现了两个步骤开展业务能力梳理的示意图(先确定卡片模板，再推动各事业部梳理)。

图8-3 业务能力梳理示意图

在梳理业务能力卡片的基础上，参考指导标准，可判断各个业务能力模块所处的水平。把能力水平分为3档并用不同颜色来表示，是比较常见、是简单易用的操作方式。不同企业对这3档可能有不同的命名，只要能较为显性地表示和区分不同能力水平就可以。图8-4给出了一个能力的参考分类，并用不同颜色进行标识。其中，红色背景表示某模块的整体能力问题严重，黄色背景表示该能力有问题但不严重，绿色背景代表该模块能力水平良好。

图8-4 业务能力分档示意图

2. 业务能力热力图-1：全景图

在对业务能力进行整体梳理和评估后，可汇总形成一个全景业务能力热力图,如图 8-5所示。

通过图 8-5的业务能力热力图，可以简单直观地展示特定企业的整体业务能力框架，便于高层管理者快速识别哪些能力问题严重、哪些能力仍须提升。业务能力热力图可用来反映事业部层面的整体业务能力情况，也可用来反映集团层面的全盘业务能力情况。在制定业务战略及IT战略的研讨过程中，利用业务能力热力图，有助于业务组织和CIO组织之间快速达成共识。

图8-5 全景业务能力热力图(制造行业企业示例)

3. 业务能力热力图-2：包含局部分解图

在图8-5的全景业务能力热力图中，整体包含了12个L1层级能力。在看清全局业务能力状况后，管理者可进一步针对特定L1层级能力展开到L3层级看局部能力热力图。

图8-6是一个制造行业企业的“营销与销售管理”能力局部展开后的热力图。可以看出，在L3层级的能力中,“商机管理”“产品配置”“合同管理”等模块的能力问题较严重,相关业务能力亟须加强。

4. 业务能力热力图-3:业务能力细化图

图8-5的热力图能够快速展示能力全景图，快速识别哪些能力模块有问题。但是，并不能反映出某个能力模块的短板具体在哪个方面。而对于务实型的管理者，往往希望通过层层分解，找到问题关键所在，进而识别解决特定问题的具体抓手。图8-7对相关L3层级业务能力做了进一步细化。

图8-6 能力热力图局部展开示意图

图8-7 能力热力图细化示意图

通过图 8-7，我们可以快速了解某个业务能力之所以问题严重，具体是由哪方面原因造成的。由上方细化的业务能力热力图可以看到,“产品配置”“合同管理”的整体能力水平都是“问题严重”，但产品配置模块的问题主要出在“数据和IT应用”方面，而合同管理模块的问题则主要是由“组织/人员”的因素导致的。了解到这一层面，相关管理层就能基本定位关键问题所在及相应负责部门、责任人，就可以有针对性地安排相关举措进行改进。

8.3.3 业务能力建设及提升基本思路

在上方的业务能力卡片的右上角，包含了两个重要信息，一个关于战略影响，一个关于该能力对IT或数字化的依赖度，对于不同战略影响、不同IT 依赖度的业务能力，可采取不同的提升策略。

我们首先要判断哪些是关键能力，哪些是非关键能力。对于关键能力，企业需要充分重视并投入较充足的内部资源进行提升和强化，以期逐步打造出企业的核心竞争力，构建护城河。而对于非关键能力，除了重视度、优先级方面可以适当降低，在能力构建上也可以考虑依托外力，通过外包的方式来解决特定能力不足的问题。

考虑到“数字化”要素越来越成为影响企业生存发展的关键因素，在了解关键能力、非关键能力的基础上，我们需要进一步识别，哪些业务能力对IT 依赖度较高、哪些依赖度较低。对于IT 依赖度较高的业务能力，说明IT或数字化可以发挥重要作用，在进行IT规划时需要重点考虑，尤其是针对“对IT依赖度较高的关键业务能力”需要优先解决能力不足的问题。

综合考虑上方所述，业务能力提升的基本思路如图8-8所示。

在具体进行能力建设时，“能力复用”是一个关键指导和考量因素，简单来讲，就是要避免重复造轮子。每个人都有自己的长处和短处，每个企业、每个业务单元也都一样。如果所有的“轮子”都要自己造一遍，不仅会花费大量的人力、财力，而且很有可能企业在某些领域造出来的轮子是低于行业水平的，反而会影响企业的整体发展。

图8-8 业务能力提升的基本思路

尤其是业务能力各组成部分中的IT相关能力，更需要重视能力复用，在条件允许的情况下，无论是内部能力，还是外部能力，都可以通过复用来提升特定方面的专业水平和成熟度，进而更高效地支撑业务发展。图8-9是IT相关的能力建设基本思路，供参考。

图 8-9 业务能力中IT相关能力建设的基本思路

未完待续~完整版请加入知识星球：数字藏经阁，获取完整版