在 TOGAF《企业核心元模型图》中，如上图所示有一类元模型要素叫 “Control (控制)”。 

01—什么是 “Control (控制)"

在《TOGAF Standard - Introduction and Core Concepts》中并没有给出明确的定义。EBPM 方法论推荐采用如下的定义：

控制是一种管理风险的手段，包括行政性、技术性、管理性或法律性的政策、程序、指南、实践或组织结构。A means of managing risk, including policies, procedures, guidelines, practices, or organizational structures, which can be of an administrative, technical, management, or legal nature.

基于上述定义，可以得到以下两个要点：

1. Control（控制）是一种风险管理的手段。

Control（控制）是一种监管和保证机制，这种机制的存在是为了回答以下问题：

“我们如何确保这个流程按照既定的方式运行？”

“我们如何防止流程中出现错误或违规行为？”

“我们如何保证流程产出的质量？”

2. Control（控制）在现实中可以表现为多种形式。

Control（控制）的形式是多样的，以下是几种常见的形式：

政策/策略（Policies）：例如，“所有软件上线前必须通过安全代码扫描策略”。这个策略控制着“软件部署流程”。

标准/规范（Standards）：例如，“数据接口必须符合 RESTful API 标准”。这个标准控制着“系统集成流程”。

程序/规程（Procedures）：例如，“月度财务对账规程”控制着“财务结算流程”中的关键节点；“成品安装操作手册 SOP”是“现场安装管理流程”必须遵从的操作规程。

合规性要求（Compliance Requirements）：例如，“个人数据处理流程”必须包含符合 GDPR 的“用户同意获取”控制点。

授权规则（Authorization Rules）：例如，规定“超过一定金额的合同必须由CFO审批”，这个职责分配也是一种控制形式。

02—Control (控制) 与 Process (流程）的关系

如上图所示，Control（控制）与 Process (流程) 相连接，Control（控制）对 Process (流程) 的作用是 “Ensures correct operation of”即 “确保…正确执行”；Process (流程) 对 Control（控制）的作用是“被…指导”。

Process（流程）定义 了“做什么”（What）和 “谁来做”（Who）。它是一个为了实现特定目标而设计的一系列有组织的步骤或活动。例如，“采购付款申请流程”、“软件开发生命周期流程”。

Control（控制）定义了 “如何正确地做”（How Correctly）。它附着在 Process（流程）上，约束和指导流程的执行方式。一个 Process（流程）通常会被一个或多个 Control（控制）所约束。反过来，一个 Control（控制）（如“公司信息安全政策”）也可能应用于多个 Process（流程）。

如上图所示的 APQC 流程框架所示，Process (流程) 是由 Activiey (活动) 构成的，因此 Control（控制）与 Process (流程) 的关系，可以通过细化分析 Control（控制）与 Activiey (活动) 的关系来理解。

1）Control（控制）是附着在Activity（活动）上的治理机制（Mechanism）

如上图所示，Control（控制）类的要素，比如：风险及控制措施、制度、标准、程序、指导、知识、管控模式等与流程中的Activity（活动）相关联，即控制类要素附着在 Activity（活动）上，表示完成这些 Activity（活动）时必须遵从这些控制要求。

2）Control（控制）本身就是 Activity（活动）

在 TOGAF 10 版本《TOGAF Standard - Architecture Content》中指出了 Control（控制）与 Activity（活动）另一种关系：

Control（控制）是一项带有配套决策逻辑的决策步骤，用于确定流程的执行方式，或确保流程符合治理标准。A decision-making step with accompanying decision logic used to determine execution approach for a process or to ensure that a process complies with governance criteria.

也就是说，有时 Control（控制）并不是附着在某一流程步骤（Activity）上的，Control（控制）本身就是一个有配套决策逻辑的流程步骤（Activity）。

上图所示的《采购付款管理流程》中，<执行三单匹配>、<财务经理审批付款申请>、<财务总监审批付款申请> 这三个流程步骤（Activity）本身就是 Control（控制）。这些控制类的活动（Activity）是有配套决策逻辑的决策步骤。决策什么呢？主要决策两类事：

第一种是确定流程的执行方式。比如<执行三单匹配>这个控制类活动，要决策是正常往下走流程，还是要走右侧的<付款异常处理流程>。

第二种是判断流程是否符合治理标准。比如：<财务经理审批付款申请>、<财务总监审批付款申请>这两个控制类活动就是要基于《采购付款管理制度》、《供应商管理政策》、《付款风险控制措施》来决策本次付款申请是否符合治理标准，符合治理标准的才可以付款。

3）Control（控制）既是 Activity（活动）又是机制（Mechanism）

第三种情况是 Control（控制）本身是一个流程步骤（Activity），而且这个步骤上还附着（关联）了控制类的要素，两者共同构成了一套 “治理机制”。上图所示的 <财务经理审批付款申请>、<财务总监审批付款申请> 这两个流程步骤（Activity）关联了《采购付款管理制度》、《供应商管理政策》、《付款风险控制措施》这些控制类的要素，通过 “控制类活动+控制类要素” 共同构成了一套 “治理机制” 来决策本次付款申请是否符合治理标准。

03—Control (控制）在架构设计中的重要性

上图所示是 《EBPM 企业架构元模型关系图》，EBPM 方法论将 “Control (控制)” 这个元模型要素放在红框所示的位置。构建业务架构模型时，理解并明确定义 Control（控制）对于企业架构治理有如下的重要意义：

保证一致性：确保不同的业务流程都遵守统一的公司规则和外部法规。

管理风险：通过内置的控制点，主动识别和降低业务运营和 IT 运营中的风险。

提高质量：通过内置的控制机制确保流程产出的质量。

实现治理：Control（控制）是企业治理框架在具体业务流程中的落地体现。架构师需要确保设计的目标架构中包含了必要的控制措施。

支持审计：明确记录的控制项是内部和外部审计的重要依据。

综上，在 TOGAF 元模型中， Control（控制）是附着在 Process上的，用于确保其执行符合业务规则、标准、策略和法规的治理机制。正确识别和设计  Control（控制）是实现有效企业治理和风险管理的重要环节。