理解功能、业务功能和能力

能力在企业架构中是非常重要的一个概念。初学业务架构的同学可能比较容易混淆功能(functions)、业务功能（Business functions）和能力(capability）这几个词的区别。

功能(functions)

功能是大家比较熟悉的。功能一词如果没有上下文和前缀的活通常是指一个东西能干什么，也就是产品功能，如扫地机器人能自主导航进行扫地。“能自主导航进行扫地”就是扫地机器人这个产品的功能。

​

从价值的角度，功能是消费者愿意为产品付费的理由。

业务功能(Business functions）

业务功能可以理解为企业或单位(在企业架构上下文中统称组织)可以做的事情。业务功能是一个抽象的和自包含的活动分组，它满足组织的一个特定操作目的(例如管理与合作伙伴的关系称为)。业务功能在组织内部是唯一的，不应该重复。一些业务功能可以分解为更小的活动组，因此业务功能视图具有层次结构。

业务功能总是和某个具体的组织或单位关联，也就是这个业务功能所关联活动的执行主体。业务功能图可以映射到一个组织架构图，概念上组织架构代表了人的集合，而业务功能图代表了活动或事务的集合。我们经常说的组织职能和业务功能实际上表达的是同一个意思，都是代表组织或单位可以做什么事情。但业务功能的结构并不总是与组织结构图相同；在许多情况下，一些组织单位可以跨越几个业务功能。此外，组织结构图可能会改变，而该组织对应的业务功能则不会改变。

通常，产品功能和业务功能中的“功能”都是指可以连续执行的东西，功能具有稳定性和可重复性的特点。这是它有别于“活动”“事件”“任务”这类偶发性事务的一个关键特征。例如一个营销部门今天弄一个“618 大促”，明天弄一个“盲盒”这些都是活动，但如果这个部门能可以经常持续的做这些事情，那么这个营销部门就具有了“营销功能”。一个业务功能在其名称中通常有后缀“管理”（例如“客户关系管理”)，但它也可以直接是一个名词(例如“营销)。

从价值的角度，业务功能强调了组织为客户交付价值所做的事情。业务功能在提供者(组织)和消费者之间提供了在一个（业务）事务。

​

从消费者的角度（从内外的角度）来看，事务受到一对“请求和结果”的限制，例如，从下订单到接收货物。从提供者(组织)的角度来看（由内到外），事务是一组几种不同的活动，它们以逻辑和协调的方式一起发挥作用，以满足/取悦消费者。这些活动是为了响应消费者的请求而进行的，这是提供者的一个外部业务事件。

业务组件

业务功能的基本元素是活动，也就是做什么事情。在此基础上，可以进一步叠加人员、流程、技术、信息、绩效方面的元素。可以使用 IDEFO 技术来分析这些元素。IDEFO 是活动模型的缩写，来源于结构化分析与设计技术的一套标准。它以图形表示完成一项活动所需要的具体步骤、操作、数据要素以及各项具体活动之间的联系方式。

• 输入(Input): 实行或完成特定活动所需的资源，置于框图的左侧。

• 输出(Output): 经由活动处理或修正后的产出，置于框图的右侧。

• 控制(Control): 活动所需的条件限制，置于框图的上方。

• 机制(Mechanisms): 完成活动所需的工具，包括人员、设施及装备，置于框图的下方。

​

业务功能在集成了人员、流程、技术、信息、绩效方面的元素后，抽象度更高，已经和它的"同胞兄弟"组织结构大相径庭。集成后的业务功能是我们后续进行业务架构建模和能力建模的一个基本组成单位，称为“业务组件”或“业务构件”，这里的组件的含义和 CBM 中的“组件”的概念是一致的。

​

业务组件的分类

业务组件从不同的维度可以分为这么几类：

• 有动机的人为因素（为什么要做什么）：

愿景和相关的“结果”，目的，目标任务和相关的“指标”，行动方案、战略、战术/项目

• 价值和利润主张组件（要做什么）

价值，价值流，价值链，价值创造，价值体系， 产品或资产（有形和无形）

• 组织组件（谁正在做）

组织结构治理结构、供应商、服务商、客户和其他合作伙伴

• 执行组件（如何执行什么操作）

流程、服务功能

• 知识/信息组件（使用什么资源）

条款、事实、规则、政策等。

• 绩效组件（做得如何）

能力、关键业绩指标

看到了吧，业务架构中相关的元素悉数登场。有了业务组件，业务架构师终于可以开始干活了。所以，理解功能、业务功能和业务组件是业务架构师成长的第一步。

业务组件和流程

业务功能视图强调了整个企业为向客户交付价值所做的事情。通常，业务功能的层次结构是静态的（变化率很低），而业务流程可能会更频繁地更改。

业务功能和流程是企业的不同视图。在某种意义上说，每一个业务功能是一个组织运作活动中的一个环节，一个环节产生的价值总是有限的，真正让这些"环节”串联起来产生更大价值是流程。如果把企业给客户的一个产品或服务交付物比作项链，流程就是串起“珍珠”的绳子，而业务功能就是“珍珠”。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

图示说明了组织、业务功能、活动、流程的关系。组织是业务功能的执行主体，业务功能包含了活动，流程将业务功能串接起来。

业务组件和价值流

在理解了业务组件和流程关系基础上，业务组件和价值流的关系也呼之欲出。我在《流程、价值流和价值链你分的清吗？》一文中讲过流程和价值流的关系。价值流和流程算是同胞兄弟。区别在于价值流在流程基础上叠加了绩效元素。理想情况下，每个价值流都应该与至少一个长期目标及其业务绩效指标(kpi)保持一致。例如，“订单到现金”价值流包括客户下订单-》订单处理-》物流配送-》客户付款这样几个“集成组件”。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

每个“集成组件”内核都是一个业务功能(FUNC1)，我们知道它的输入 WHAT0{资产 0，预期绩效 0}，它的输出 WHAT1{资产 1，展示绩效 1}以及它的操作需求 WHY0。

​

编辑

添加图片注释，不超过 140 字（可选）

FUNC1 的期望绩效是通过其作为“较小”功能协调实现(HOW1)来保证的。在某种程度上，WHAT1 被分解为一组 WHAT2x。WHY0 分解为一组 WHY1x，FUNC1 分解为一组 FUNC2x。下图显示了这种分解关系。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

每个“集成组件”都是一个将业务功能应用于资产的有序行为序列。业务功能序列显性化就是资产流或价值流。与序列相关联的 kpi 和时间线提供了额外的执行细节。价值流视图为业务功能及其组成活动提供了上下文，例如。什么时间、绩效水平等等，这些是达到完整价值流的目标所必需的。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

业务组件视图的作用

理解了业务组件的内涵，自然不难理解业务组件视图的作用：

• 了解组织单位如何支持每个功能，并确定一个功能由几个组织单位支持（或不受任何组织单位支持）的实例；

• 揭示当前功能是如何自动化的，包括应用程序使用过于复杂的地方(例如，多个应用程序)，以及当没有自动化的功能到位时；

• 了解资产（信息）如何在功能之间流动，并绘制出哪些功能产生信息，哪些功能消耗信息，哪些功能对信息移动和所有权没有明确的理解；

• 阐明如何构建业务流程；

• 确定应该使用哪些业务绩效指标。

​

编辑

添加图片注释，不超过 140 字（可选）

能力（capability）

能力和功能也是同胞兄弟。在 TOGAF 中能力（capability）被定义为 组织“做某事的能力”。能力表示业务执行某些操作的能力。更正式的定义为:业务能力是业务为实现特定目的或结果而可能拥有或交换的特定能力或产能。在《Explaining EA:business architecture basics》对能力的定义更能揭示能力的特征：能力是指已证明拥有执行特定服务（以产生特定的结果，其中可能包括所需的绩效）所需的特性，以及该服务所包装的功能。这个定义将能力、服务和功能联系在一起，并且揭示了能力和功能的本质区别：能力是可证明的功能。在此文中，也给出了如何确保服务(或者说功能)是可证明的：

• 通过合同（“主动”方法）-获得具有所需特性的服务，使用它，检查其绩效是否可接受，如果有什么问题则替换它；

• 通过度量（“主动”方法）-实现服务、使用服务、度量服务、改进或重新构建服务等等；

• 通过设计（“主动”方法）-建立服务模型、运行仿真测试、改进模型、构建服务、使用、测量、改进等。

我在《莫把功能当能力！》一文中我用一个例子说明过功能和能力的区别，在烧烤摊上站岗的警察提供的是功能而不是能力，它不符合上述三个可证明的情况。在概念上，功能和能力是不同的，但在形式上，业务功能组件和能力组件没有什么不同，“可证明”这一特征并不在业务功能视图(或者说能力视图)上体现。这也是我在《CBM业务模型是什么和为什么？》一文中认为 CBM 业务组件地图可以作为能力地图使用的原因。

总结

• 功能是一个事物能做什么，通常用于描述产品需求的解决方案。

• 业务功能是一个组织或单位能做什么。业务功能是一个抽象的和自包含的活动分组，它满足组织的一个特定操作目的。

• 业务功能可以叠加人员、流程、技术、信息、绩效方面的内容，形成抽象度更高的业务组件。业务组件是业务架构建模的基础。

• 能力描述组织能做的事情。能力在概念上不同于业务功能，能力是可证明的业务功能。在形式上，业务功能组件可以作为能力组件使用，业务组件地图亦可作为能力地图。

End

欢迎关注涛哥微信公众号“架构领导力”和视频号“数智产品和架构”