本文重点介绍 ARIS 房式结构中的《功能视图》，并介绍 EBPM 架构是如何继承 ARIS 房式结构并融合 TOGAF 企业架构的。

提及《功能视图》，首先需要明确什么是 “功能”。为了避免翻译所导致的理解偏差，特将ARIS 操作手册中的英文原文也附上。

功能是一个需要执行的对象，是一项支持一个或多个公司目标的技术任务或活动。（请参阅Scheer《ARIS集成的信息系统架构》1992，p.63）。A function is a technical task or activity performed on an object in support of one or more company objectives (see Scheer, Architecture of integrated Information Systems 1992, p. 63)

通常成为一个功能对象的标准是一个信息对象，例如<客户询价单>或<生产订单>。Usually, the criterion for establishing such a function is an information object such as a customer inquiry or a production order. (e.g. Procurement logistics, production, sales)

上述规则在描述一个功能对象时也得到了充分体现。比如：《确认客户询价单》，<客户询价单> 是一个信息对象，<确认> 这个动词描述了对此信息对象的操作。所以，从更高层次的抽象来说，功能可以抽象为一个名词。This should also be expressed in the description of a function. Customer inquiry defines the object, and Verify defines the operation that will be performed on this object. On a higher level, only a noun is used to describe functions。

上述三段话可概括理解如下：

1）功能、流程步骤（活动或任务）是同一颗粒度的概念。

2）功能是一个需要执行的对象，执行则由一个动词来描述。

3）一个功能对应一个信息对象，也就是输出一套管理记录。这个信息对象（管理记录）由一个名词来描述。

4）所以，功能即流程步骤（活动或任务）的命名规则是动词+名词。

01

—

需求定义类模型

如上图所示，描述企业需要有哪些功能的需求定义类模型主要有三种，即功能树模型、Y 模型、目标图模型。

1) 功能树模型：在不同的抽象层级上分类描述功能。

功能树模型有基于流程、基于对象（名词）、基于执行（动词）三种。

上图所示是基于流程（process-oriented）展开的功能树模型。图中根级代表流程的范围，比如本组织所有的职能流程或者某一条端到端流程；二级是此流程范围内总共有哪些信息对象（名词）；三级即末级功能对象描述了在本流程范围内对此信息对象总共有哪些处理方式，也就是此信息对象（名词）总共有多少种不同的处理动作（动词）。

上图所示是基于对象（Object-oriented）的功能树模型。图中根级是一个信息对象（名词）；二级末级功能描述了对此信息对象在本组织的所有职能流程中有哪些处理方式，也就是此信息对象（名词）加上各种不同的处理动作（动词）。

上图所示是基于对象（Object-oriented）的功能树模型。图中根级是一个处理方式即动词；二级即末级功能描述了这样的处理方式在本组织所有职能流程中有哪些不同的处理对象也就是信息对象（名词）。

2）Y模型

功能视图需求定义类模型的第二类元模型就是著名的 Y 模型。相关内容请参见本公众号前期的相关文章：《从 ARIS 到 EBPM | Y 模型（上）》、《从 ARIS 到 EBPM | Y 模型（中）》、《从 ARIS 到 EBPM | Y 模型（上）》。需要强调的是，在企业建模的实践中 Y 模型现在用的很少。

3）目标模型

上图所示的目标模型用来是功能视图需求定义类模型的第三种元模型。目标模型就是对于企业流程体系运营目标的描述，这个模型很容易理解，不过多描述了。只不过，需要注意的是这里描述的是目标，不是定量的绩效指标。也可以这样理解目标模型，其根级是目标(Goals)，二级开展是实现此目标的成功因素（Success Factors）。当然，如果根级目标是企业的战略级目标，那么成功因素也就是关键成功因素（Critical Success Factors）。

02

—

设计说明类模型

应用系统类型图 （Application Type Diagram）：此模型描述应用系统和模块类型的规范的模块化结构的规范、单个事务步骤的草案以及列表和屏幕草案形式的输入和输出演示文稿的定义。The design specification of the function view contains the specification for the application system and module types, as well as the modular structure of the application system type, an outline of individual transaction steps, and the definition of input and output presentations in the form of draft lists and screen design。

上图所示是 ARIS 中应用系统类别图模型示例，表示某一类系统由哪些类型的功能模块构成。

上图所示也是应用系统类别图模型，表示某一类系统由哪些类别的子系统构成。

03

—

实施执行类模型

应用系统图 （Application System Diagram）：应用系统（模块）是应用系统类型（模块类型）的单个样本，可以通过许可证号等唯一标识。可以将特定的应用系统和模块分配给设计规范中描述的应用系统（模块）类型图模型。

应特别注意，一个应用系统是指拥有同一个许可证的系统。比如，购买并安装了两套 EBPM 软件，应用系统图模型中应构建两个应用系统对象而不是一个。但在《应用系统类型图模型》中只应构建一个对象，因为这两套（两个独立的软件许可）EBPM 系统属于同一类型系统。

上图是《应用系统图模型》的示例。可以这样理解，《应用系统图模型》是对《应用系统类型图模型》的细化，进一步描述具体的功能模型，以及此模型执行过程中会用到的《系统屏幕》或者输入输出的《清单》。《系统屏幕》和《清单》模型中都描述了具体的数据项和特性值。

小结

—

总结一下。《ARIS 房式结构》中的《功能视图》主要包括上图右侧所示的5 类元模型。在实践中，Y 模型用的很少。《目标图》模型主要用来描述流程运营和优化的方向，并不直接描述功能而是描述功能执行的效果。类此，直接用来描述功能的主要是三大元模型，即《功能树模型》、《应用系统类型图模型》和《应用系统图模型》。

《应用系统图模型》是对《应用系统类型图模型》的细化，可以认为描述的是同一类对象，即“应用系统”。

那么，“功能”和“应用系统”如何建立关联呢？在 ARIS中用《功能分配图》模型来完成两者之间的关联。

在上图所示的《功能分配图模型》中，可以将“功能”和“应用系统“建立关联，从而描述清楚此流程步骤是由信息系统中的哪个模块或者应用系统执行的。如果 “应用系统”这个对象已细化到《应用系统图模型》，那么也可将某个具体的《系统屏幕》和输入输出《清单》与此“功能”建立关联。

如上图所示，如果 “应用系统”这个对象只构建到《应用系统类型图模型》这个细度，那么就只能将应用系统类型或者模块类型与“功能”建立关联了。

下篇文章介绍 EBPM 架构是如何实现 ARIS 功能视图，同时又融合 TOGAF 企业架构中的相关模型的。