在我们做业务架构/业务分析的过程中，能力、流程、功能、活动等等概念经常使用。但是在各种上下文环境中，我们都表达什么，这些概念之间有什么区别和联系，这是困扰了我很久的问题。
对于常见的方法论来说，如TOGAF、BizBok以及下文提到的EBPM等，都有自己的阐述，下面节选了公众号“流程管理道可道”（gh_fe072f3febd5）的文章。文章精彩，链接如下：
先粘贴结论
- 什么是“能力”？就是完成某件事项应具备的综合素质。
- 什么是“业务能力”？就是完成与企业业务(business) 相关的某件工作事项应具备的综合素质。
- 什么是“业务功能”？是“业务流程”的构成要素，描述如何交付业务能力也就是如何完成业务事项。
- 什么是“业务活动”？是构成“业务流程”的基本单元。
- “功能”和“活动”是什么关系？“活动”和“功能”是两类不同的要素，“活动”基于“流程”进一步细化描述要“做什么”；“功能”针对“活动”描述“怎么做”。
- 为什么华为和 EBPM 内容元模型图中都没有“功能”而只有“活动”？因为实际建模时都是基于“活动”自动生成“活动树”，而“功能分配图”是直接挂接在“活动”对象上而不是“功能”对象上。所以在实际模型中确实没有“功能”这一独立的元模型，通常是将“活动”这类要素通过“活动树”的方式独立出来作为一类元模型进行管理和优化分析。因此，“功能”元模型作为概念是存在的，但在实际模型通常并不存在。
=======================================================================
业务能力
01
—
TOGAF 对 ”业务能力“ 的定义
TOGAF 给出了 “能力(capability)” 和 “业务能力(business capability)” 两个定义。
机械工业出版社出版的《TOGAF 标准 9.1 版》 3.26 节中对能力的定义如下：“能力”是组织、个人或系统拥有的能力。An ability that an organization, person, or system possesses.
从上述定义的中文看，这似乎是一个自我论证，什么是 “能力”? 组织、个人或系统拥有的 “能力” 是 “能力”。其实，上述定义只讲了“能力”拥有的主体是哪些，但完全没有讲什么是 “能力”。这样的定义，常人一定是越看越晕的。
但是，仔细看一下英文原文可以发现，中文定义中的同一个词 “能力”，在英文中是两个词，分别是“ablility” 和 “capability”。所以，英文原文中不是说 “能力” 是 “能力”，而是说 “ablility” 是 “capability”。
那么，“ablility” 和 “capability” 有何区别呢？
- ability 常用于表示某人可以将某件事做好。
- capability 指做成某件事所需的素质。
所以，更容易理解的翻译似乎应是：“能力(Capability)” 是组织、个人或系统完成某个事项应具备的综合素质。
机械工业出版社出版的《TOGAF 标准 9.1 版》 3.26 节中对能力的定义还附有一段说明，全文如下：
能力常常以一般且高度概括的术语表达，并且，能力通常需要组织、人员、流程和技术结合起来才能达成。例如：市场营销、客户联络或推式电话营销等。Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.
这样的说明，看了一定有一种说不出的感觉。说不出什么呢？就是还是说不出什么叫能力。倒是定义中举的例子倒是还能看出一些端倪。比如：<市场营销Marketing>、 <客户职络 customer contact> 、<电话销售 outbound telemarketing> 都是一项能力。只不过定义中举的三个例子，其颗粒度很明显是不同的。
以上是 TOGAF 对 “能力(capability)” 的定义。下面再来看看，TOGAF 对 “业务能力(business capability)” 的定义。
TOGAF 官方网站上关于 “业务能力” 的定义是：企业为达到特定目的而拥有或交换的一种特定的能力。A particular ability that a business may possess or exchange to achieve a specific purpose.
总之，“业务能力” 是一种特定的 “能力”。但具体是如何“特定”呢？是“企业为达到特定目的而拥有或交换”。
那么，看了上段文字，您理解“特定” 二字的含义了吗？估计你还是没看懂！
02
—
华为对 ”业务能力“ 的定义
再来看看华为关于“业务能力”的定义。首先要对“华为”这个概念给出一个定义。现在市面上到处都是 “华为说什么什么”，其实
- 有的是“为华为提供过咨询服务的第三方管理咨询公司说”；
- 有的是“曾在华为工作过的员工说”；
- 有的是“还在华为工作的员工说”；
- 有的是“去华为参观过的人听华为的员工说”；
- 有的是“提供所谓华为经验的培训老师说”；
林林总总，五花八门。所以，所谓 “华为说” 一定要搞清楚具体是谁在说。不然你会发现，同一问题华为有很多不同的说法，莫衷一是。其实不是华为的说法不一样，而是代表华为来说的人不一样。都是 “如是我闻”，但 “闻” 对象是不同的。
本文提到的 “华为” 是指华为公司对外提供管理咨询服务的团队。所谓 “华为的定义” 是指这个咨询服务团队给其所服务的企业提供管理咨询服务时就 “业务能力” 给出的定义。
华为认为：业务能力是企业为达到特定目的而拥有或交换的一种特定的能力，例如产品开发、订单管理等。业务能力关注做什么，而不是怎么做。
从上述定义来看，华为完全引用了 TOGAF 的定义，同时也给出了例子。比如：产品开发、订单管理都是一项能力。同样可以发现，产品开发和订单管理也完全不在一个颗粒度的层面上。<产品开发>的内涵明显大于<订单管理>。
但是，相较于 TOGAF 的定义，华为的定义中增加了一段说明：业务能力关注做什么，而不是怎么做。这句话很关键，即业务能力是在讲要做什么事。
03
—
EBPM 方法论对 ”业务能力“ 的定义
综合分析 TOGAF 英文版定义中两个关键词：
- ability：常用于表示某人可以将某件事做好。
- capability：指做成某件事所需的素质。
再结合华为定义中最后加的那句话：业务能力关注做什么，而不是怎么做。
可以看出关于 “能力” 的定义和说明包含了两个关键词: “做事” 和 “素质”，即 “能力” 是 “做事” 的 “素质”。而 “业务能力” 无非就是做企业业务 (business) 事项的应有的素质。
所以，要 “做什么事” 和 “做这件事的素质” 构成了 “能力” 这个概念的完整内涵。
因此，EBPM 方法论给出的定义是：“能力” 是组织、个人或系统完成某个事项所需的综合素质。 “业务能力” 就是组织完成某个 “业务事项” 所需的综合素质。
本定义中用组织代表企业作为完成事项的主体。那么，“综合素质”又具体指什么呢？通常包括 TOGAF 定义中所说的：组织、人员、流程和技术。
也就是说，“业务能力” 是组织完成某个 “业务事项” 在组织、人员、流程和技术方面应具备的素质。
所以，要理清楚企业总共应该有哪些 “业务能力”，首先要理清楚企业总共应完成哪些 “业务事项”；而完成所有这些 “业务事项” 的综合素质就是企业应具备的所有 “业务能力”。
有了上述理解后，再来看 TOGAF 的定义，是否能看懂点了呢？大致明白了，但还有点模糊对吗？
那么，我们再介绍一下 EBPM 方法论中关于能力的解析过程。
如上图所示，在EBPM 方法论中对接两大战略模型解析出企业的一级业务能力，所谓 “一级业务能力” 可以理解为企业应完成的 “业务事项“ 的一级分类。即支撑两大战略模型企业应完成哪些业务事项。照华为的说法，业务能力关注的是要做什么事。
如上图所示，在EBPM 方法论中，基于一级能力项应按 PDCA 、生命周期或者事项罗列这三种方法中的一种再进行细分，得到二级能力项，也就是能力的二级分类。二级能力项本质上是企业应完成哪些业务事项的二级分类。
如上图所示，在 EBPM 方法论中基于每一个二级能力项，比如<采购需求与计划管理> 应再往下细分，此时细分的方式是一个矩阵。
纵轴是末级能力事项，拆分的方式仍然可以在 PDCA、生命周期、事项罗列这三种分类法中选择一种。
横轴是业务场景。“业务能力”关注的是做哪些事，而怎么一步步把事完成则是用 “职能流程” 来描述的。所以，一个末级<能力事项>通常至少有一条<职能流程>来承接。但是当不同的 “业务场景” 下，同一件事有不同的做法时则会解析出不同的<职能流程>。即一个末级<能力事项>也可能对应多条<职能流程>。这取决于不同的 “业务场景” 下，同一件事是否有不同的做法。
如上图所示，在EBPM 方法论中，<职能流程>再往下展开是<职能流程图>，<职能流程图>由<业务活动>构成，而每一个<业务活动>可以再往下展开为组织、人员、系统等管理要素。业务活动、组织、人员、系统等要素都是在描述一件事应如何完成，也可以认为在描述完成一件事应具备什么样的素质。这也就是 TOGAF 定义为什么说，能力通常需要组织、人员、流程和技术结合起来才能达成。只不过，完成一件事所应具备的全部素质可能不止组织、人员、流程和技术。
总之，EBPM方法论认为： “业务能力” 就是组织完成某个 “业务事项” 所需的综合素质。这个定义与 TOGAF 和华为的定义没有什么本质区别，但至少比 “能力” 是 “能力” 的说法更能让人容易看懂一点点。
业务功能
01
—
TOGAF 对 “业务功能” 的定义
机械工业出版社出版的《TOGAF 标准 9.1 版》 3.23 节中对业务功能的定义如下：
“业务功能”是交付与组织密切协调一致的业务能力，但这些能力并非必须由该组织明确治理。
Delivers business capabilites closely aligned to an organization, but not nesessarily explicitly governed by the organization.
这段定义的中文译本很容易使读者按标红文字进行理解：业务功能是交付与组织密切协调一致的业务能力，但这些能力并非必须由该组织明确治理。即“业务功能”是“业务能力”。
如果这样理解，会得到这样的逻辑链路：
- 什么是“能力”？你拥有的 “能力” 就是 “能力”。
- 什么是“业务能力”？一种 “特定” 的 “能力” 是“业务能力”。
- 什么是“业务功能”？“业务功能” 是 “业务能力”。
这就变成一个以自我定义为起点的循环定义，绕一圈下来等于什么都没说。要将这三段话变成常人能看懂的“人话”，或者有点意义的 “定义”，需要进行如下的解读和改造。
首先，关于 “业务功能” 的定义还是要回到英文原文：
Delivers business capabilites closely aligned to an organization, but not nesessarily explicitly governed by the organization.
很明显，英文原文中 Deliver 是一个动词，中文译为 “交付”。“交付” 什么呢？交付 “业务能力 business capabilites“。所以，应按如下方式理解这段文字：
业务功能是交付与组织密切协调一致的业务能力，但这些能力并非必须由该组织明确治理。即 “业务功能” 是 “交付业务能力”。
“能力” 是描述 “需要做哪些事”；而 “功能” 是描述 “怎么做这些事”。“做事” 就是 “交付” 的意思。
总结一下：
- “能力” 是要做的 “事”，“业务能力” 就是 “企业要做的事”。
- “功能” 是 “交付能力” 也就是 “完成事项”；“业务功能 ”就是 “交付业务能力” 也就是 “完成业务事项”。
因此，关于“业务功能” 的定义似乎这样描述更能突出上述逻辑，避免误解。
“业务功能” 就是交付 “业务能力”，这些能力应与组织密切相关但不一定由该组织明确治理。
02
—
华为对 “业务功能” 的定义
一言以蔽之，华为对于 “业务功能” 的定义就是没有定义！
在上图所示的TOGAF业务架构内容元模型中有“功能”这一要素。
但是，如上图所示的华为业务架构内容元模型中，没有“业务功能”。华为业务架构元模型与 TOGAF 内容元模型有以下几处明显不同。
- 明显简化掉了很多要素。
- 明确将<业务能力>放到<业务架构>中作为一个要素。
- 没有<功能>这个要素， 多了<活动>这个要素。
为什么没有 “功能” 这个要素？为什么要增加 “活动” 这个要素？没有 “功能” 会不会对后续基于业务架构的分析、优化和驱动信息化建设带来问题？
EBPM 方法论认为，“业务功能” 这个概念可以有，但在构建业务架构模型时，确实没有必要将其单独显性化为一类要素。总之，EBPM 方法论认同华为的处理方法。关于这一点，在下一篇讨论 “活动” 这个要素的文章中会详细说明。
03
—
EBPM 对 “业务功能” 的定义
基于本文第一小节的分析，再结合《TOGAF、华为及EBPM 对 “业务能力” 的理解》一文中对于“业务能力”中文定义的优化。EBPM 方法论的关于“业务功能”的理解可以概括为以下三段话：
- 什么是 “能力”？就是完成某件事项应具备的综合素质。
- 什么是 “业务能力”？就是完成与企业业务(business) 相关工作事项应具备的综合素质。
- 什么是“业务功能”？就是交付业务能力即完成业务事项。
总之，“业务能力” 描述要 “做什么事”，而 “业务功能” 描述 “怎么做” 这些事。这种说法，是否感觉与 “流程” 和 “能力” 的关系有点相似？是的，下一篇文章会讨论一下 “活动”，只有将 “能力”、“功能” 、“流程”、 “活动” 这四者放在一起辨析，才能真正理清楚这些概念的区别和关系。
业务活动
讨论 “业务活动” 不可避免的要涉及 “业务流程”。因此，本文是将 “能力”、“功能”、“流程”、“活动” 这四个要素放在一起进行辨析。为简化起见，除非有特别说明，本文后续谈及的 “能力”、“功能”、“流程”、“活动” 都是指 “业务能力”、“业务功能”、“业务流程”、“业务活动”。
01
—
TOGAF 对 ”业务活动“ 的定义
在上图所示的机械工业出版社出版的《TOGAF 标准9.1 版》 的内容元模型中，业务架构中并没有 “活动” 这一要素，而是只有 “功能” 这一要素。
上图是 TOGAF 10 版本内容元模型图。可以发现，与 9.1版本的区别是<业务架构>中增加了<业务能力>，另外还是没有出现<活动>。总之，<活动> 在 TOGAF 中不是元模型级别的要素，而是 <流程> 这个元模型的构成要素。
《TOGAF 标准 9.1 版》 1201 页对 “流程” 给出了如下定义：
流程代表一连串可共同取得某种特定结果的活动，可以被分解成若干个子流程，还可以表明某项功能或服务(更详细)的运行。流程也可用于连接或组成组织、功能、服务和流程。
A process represents a sequence of activities that together achieve a specified outcome,can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail). Processes may also be used to link or compose organizations, functions, services, and processes.
不妨再来看看 TOGAF 10 版本中对于 “流程” 的定义，此信息来自 TOGAF 官网：
流程表示一系列活动，这些活动共同实现了特定的结果，可以分解为子流程，并可以描述业务能力或服务的交付操作（在下一级进行详细描述）。流程也可以用于连接组织、业务能力、服务和流程。
A process represents a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a business capability or service (at next level of detail). Processes may also be used to link organizations, business capabilities, services, and processes.
不管是 TOGAF 9.1 版本还是 TOGAF 10 版本都没有给出 “活动” 的具体定义，但在 “流程” 的定义中明确了一组 “活动” 构成了 “流程”，“流程” 就是一组 “活动”。
02
—
华为对 “业务活动” 的定义
如上图所示，在华为的业务架构中，有一类元模型叫 “活动”。本人与华为对外提供管理咨询服务的团队合作时，此团队对我们共同的客户说，华为对 “业务流程” 的定义如下：
“业务流程” 是在特定企业环境及资源保障下，为实现客户价值和企业商业目标而形成的一套规范业务运作规则和机制，即通过一系列可重复、有逻辑顺序的活动，按照相关的政策和业务规则，将一个或多个输入转换成明确的、可度量的、有价值的输出。
华为就 “业务流程” 的定义与 TOGAF 以及流程管理领域中的传统定义没有什么本质区别，大家都强调并认可 “流程” 就是一组 “活动”。只不过不同机构和人员对这一组活动的说明有所区别而已。
另外，与 TOGAF 不同，华为就 “业务活动” 还单独给出了如下的定义：
“业务活动” 是组成流程的基本单元，是一组相互联系的、有明确成果和输出的任务。一般以动宾结构来命名（动词+名词），如确认订单、发货等。
总之，华为对 “流程” 和 “活动” 分别给出了定义，同时也认为 “流程” 由一组 “活动” 构成。如上图所示，华为认为 “活动” 还可以拆分成 “任务”，即 “活动” 是由一组 “任务” 构成的。当然，有时可能只有一个 “任务” 构成。这一点在 TOGAF 中并没有提及，但却是流程管理领域中早已有之，且被广泛接受的概念。
下一篇文章将谈谈 EBPM 方法论对 “活动” 的理解。会将 “能力”、“功能”、“流程”、“活动” 这四者放在一起进行辨析。
另外，本文中给出 TOGAF ９.1 和 TOGAF 10 两个版本对于“流程”的定义，您发现两者的差异了吗？绝对是 “微言大义” 级别的差异。
以下是 TOGAF ９.1 对于流程的定义：
A process represents a sequence of activities that together achieve a specified outcome,can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail). Processes may also be used to link or compose organizations, functions, services, and processes.
以下是 TOGAF 10 对于流程的定义：
A process represents a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a business capability or service (at next level of detail). Processes may also be used to link organizations, business capabilities, services, and processes.
对于 “流程” 的定义，TOGAF 10 对 9.1 版本有重大的修正。我们以英文版为准来进行分析。
以下是 9.1 版本，与 10.0版本的差异之处进行了标红处理。
A process represents a sequence of activities that together achieve a specified outcome,can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail). Processes may also be used to link or compose organizations, functions, services, and processes.
以下是 10.0 版本，与 9.1版本的差异之处进行了标红处理。
A process represents a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a business capability or service (at next level of detail). Processes may also be used to link organizations, business capabilities, services, and processes.
可以看到，有三处重大变化：
1）将 “流程可以描述功能或服务的操作” 修正为可以 “流程可以描述业务能力或服务的操作”，将 “功能” 换成了 “业务能力”。即 TOGAF 认为：“流程” 是描述 “业务能力” 的操作过程 (operation)，不是 “功能” 的操作过程 （operation)。
2）将“流程可以连接（link）和组成（compose）组织、功能、服务和流程” 修正为 “流程可以连接（link）组织、功能、服务和流程”，即将 “组成compose”这个动词去掉了。“流程” 与组织、能力、服务和流程之间是 “连接 Link” 关系，不存在 “组成 Compose” 关系。
3）将 “连接组织、功能、服务和流程” 修正为 “连接组织、业务能力、服务和流程”，同样将 “功能” 换成了 “业务能力”。
上述三处重大修正，可以概括为以下两点：
1）TOGAF 将 “功能function” 全部替换成 “业务能力business capability” 了。
2）TOGAF 认为 “流程” 与别的要素之间的关系不再是 “连接link” 和 “组成compose”，而仅仅是 “连接link”。
这就对了！本人原本正在收集材料，想好好写一篇文章 “喷” 一下 TOGAF 中这一逻辑错误。看了 TOGAF 10 版本的修正，心有戚戚焉，这回也没什么好 “喷” 了，完全认同！
这里的关键点是：在业务架构模型中 “业务功能” 就是 “业务活动”，“业务活动” 就是 “流程步骤”，这三者是同一个模型对象。所以，“业务流程” 由 “业务活动（流程步骤）” 也就是 “业务功能” 组成。也就是说，“业务流程” 就是一组 “业务活动（业务功能）”。
因此，说 “业务流程” 可以描述 “业务功能” 的操作过程，就好比在说 “一组业务功能” 可以描述 “业务功能” 的操作过程。这又变成了自我说明了，等于在说 “你” 可以描述 “你”，就是一句废话！
另外，TOGAF 9.1 版本的定义中还有<流程> “组成compose” <功能> 这一说法，这又相当于在说：“业务功能” 由一组 “业务功能” 组成，等于在说 “你” 组成了 “你”，还是一句废话！
如果我们将 “operation” 这个词直接翻译成 “交付过程” ，那么基于 TOGAF 10 对于流程的定义，可以得到如下的逻辑链路：
- “流程” 是描述 “能力” 的交付过程，
- “流程”=“一组活动”，所以 “一组活动” 交付 “能力”，
- “活动” = “功能”，所以 “一组功能” 交付 “能力”。
- 什么是“业务功能”？“业务功能” 就是 “交付业务能力”。
圆满自洽，完美的逻辑！
行文至此，有心者可能会发现，在上述所谓完美的逻辑链路中， “活动”=“功能” 这一点并没有论证过，而是直接给出了结论。那么 “业务活动” 和 “业务功能” 真是完全一样的概念吗？
不是！
为什么说 “活动(流程步骤)” 和 “功能” 就是同一个对象，但又是不同的概念？
01
—
“活动” 和 “功能” 都是构成流程的要素
我们先回到 TOGAF 的内容元模型图，如上图所示，不管是左侧的10版本还是右侧的9.1 版本，都明确 “流程” 分解成 “功能”；而 TOGAF的 “流程” 定义中又明确 “流程” 由 “一组活动” 构成。所以，“功能” 和 “活动” 都是 “流程” 解构而来的要素，二者的颗粒度在同一层级上，且都是包含在 “流程” 这个元模型中的要素。
上图所示的大名鼎鼎《ARIS 房式结构》概念图。图中清晰地表示流程中的流程步骤也就是<活动>是来自 <功能树>中的<功能>。
02
—
活动描述做什么，功能描述怎么做
那么，既然 “功能” 和 “活动” 都是构成 “流程” 的要素，两者究竟是什么关系呢？
我们需要再回顾一下《TOGAF、华为及 EBPM对“业务能力”的理解》一文。
商业模式至一级能力
二级能力-末级能力事项-职能流程
职能流程-流程步骤-流程步骤关联的要素
上面三张图清晰地展示了从 “战略模型-一级能力-二级能力-末级能力事项-职能流程-流程步骤-流程步骤关联的要素” 这样一个层层往下的解析过程，这一过程最终解析出 “流程步骤” 和 “流程步骤关联的要素”。
如上图所示，“流程步骤” 和 “流程步骤关联的要素” 其实就是两类不同的要素：“流程步骤” 就是<活动>，“流程步骤关联的要素”就是<功能>。每一个<活动>对应一个<功能>，即<活动>和<功能>是一 一对应的。
“能力”是描述要“做什么事”；“流程”是描述“怎么做”这些事。继续解构“流程”会发现还是要继续描述要 “做什么” 和 “怎么做” 这两方面的内容。
<活动>就是基于某个末级<能力事项>继续解析要做什么事。<功能>就是基于每一件颗粒度更小的工作事项即<活动>来描述怎么做这件事。由于每一个事项都应描述怎么做，所以每一个<活动>都要对应一个<功能>，因为<功能>才是描述交付。正是由于<活动>和<功能>是一 一 对应的，所以建模时<活动>及其对应的<功能>名称是完全一样的。
如上图所示，作为 “活动”，<提交采购申请>是在描述完成<设备采购审批>这件事的第一个细分工作事项。而作为 “功能”，<提交采购申请>是在描述 “怎么做” 提交采购申请这件事。那么，如何描述 “怎么做” 呢？通过 <功能分配图（Function allocation diagram）> 这个模型来描述。TOGAF 认为功能分配图中至少要包括组织、人员和技术几个方面；EBPM 方法论认为应包括输入输出的管理记录、所用到的系统、相关管理规则和要求、负责执行的组织及人员等要素。
如上图所示，如果 “活动”继续往下解析到“任务”这一层级，本质上也是在继续描述“做什么”和“怎么做”两方面的内容。也就是说，每一个“作业任务”上也可以通过“功能分配图”来描述“怎么做”。
对应到数字化流程系统，描述要“做什么事”的模型，也就是<能力-流程-活动-任务>这套模型应驱动系统完成“任务派发”；而<功能分配图>模型应驱动系统来“完成任务”。
03
—
为什么只构建 “活动树” 模型
综上，“活动”和“功能”是两类不同概念的要素。但是，由于两者的名称是完全一样的，且两者是一 一对应的。所以，在实际构建流程体系或者业务架构模型时，没有人会费时费力地进行如下操作：
1）先做一套 <流程模型>，通常基于 EPC 或者 BPMN 规范来构建。
2）再做一套<功能模型>，通常包括<功能树>和<功能分配图>两个模型。
3）再将<功能模型>中的每一个<功能>与<流程模型>中的每一个流程步骤也就是<活动>逐一建立连接关系。
这样的操作绝对会把建模人员逼疯的！试想一下，如果有800条流程，每个流程有5个步骤，那就是要先建一套包括800条流程和4000个活动的<流程模型>；然后，再建一套有4000个功能的<功能树模型>。然后，针对<功能树>模型中的4000个功能逐一构建<功能分配图>模型，通过关联管理记录、系统、绩效、制度、组织、人员等要素来描述这件事应怎么做。最后，还要把每一个<功能>与每一个<活动>逐一建立对接关系，4000个就要关联4000次。
20年前，本人刚开始给企业基于《ARIS 房式结构模型》构建流程体系时，还真这样干过。差点儿把客户和自己都搞得“怀疑人生”了。
如上图所示，正确建模方式是只建一套<流程模型>，不再另外构建<功能树>模型。然后，在每一个流程步骤也就是“活动”上直接构建<功能分配图>来描述这件事“怎么做”。
这样建模，描述的内容没有任何缺失，对后续使用模型也没有任何影响，更为重要的是，没有冗余和重复的操作。总之，这样的建模方式效率高且无信息缺失，早已成为企业构建流程模型时的通用操作规范。
但是，这样操作后会发现《功能树》模型没了，即 “功能” 不再作为一套独立的元模型出现在业务架构或者说流程体系模型中了。由于“功能分配图”模型直接挂接在“活动”上，所以通常会将“活动”作为一类元模型“要素”显性化出来形成所谓的“活动树”模型。需要指出的是，“活动树”模型在ARIS中通常通过编写脚本的方式自动抽取生成；在 EBPM 平台中则是通过系统内置的功能自动生成的。
这也是为什么，在华为的业务架构内容元模型图和 EBPM 企业架构内容元模型图中，都没有“功能”这类要素，而是有“活动”这类要素。
华为也是在“活动”上直接挂接“功能分配图”来描述“功能”即描述“怎么做”的逻辑的？
是的！
这一点是10多年前华为引入 ARIS 时我们的建议，几个月前有机会看到华为 PDMC+ 平台上的业务架构建模规范，还是这样规定的。
04
—
总结：能力、功能、流程、活动的区别与关系
下面，基于上图所示的 EBPM 架构内容元模型图，总结一下关于能力、功能、流程、活动这四篇文章的内容。
- 什么是“能力”？就是完成某件事项应具备的综合素质。
- 什么是“业务能力”？就是完成与企业业务(business) 相关的某件工作事项应具备的综合素质。
- 什么是“业务功能”？是“业务流程”的构成要素，描述如何交付业务能力也就是如何完成业务事项。
- 什么是“业务活动”？是构成“业务流程”的基本单元。
- “功能”和“活动”是什么关系？“活动”和“功能”是两类不同的要素，“活动”基于“流程”进一步细化描述要“做什么”；“功能”针对“活动”描述“怎么做”。
- 为什么华为和 EBPM 内容元模型图中都没有“功能”而只有“活动”？因为实际建模时都是基于“活动”自动生成“活动树”，而“功能分配图”是直接挂接在“活动”对象上而不是“功能”对象上。所以在实际模型中确实没有“功能”这一独立的元模型，通常是将“活动”这类要素通过“活动树”的方式独立出来作为一类元模型进行管理和优化分析。因此，“功能”元模型作为概念是存在的，但在实际模型通常并不存在。