这是一个基于模式的新框架， 它通过业务流程的充分自动化和持续审计，来捕获并管理业务流程的合规需求。

在现如今以IT为中心的业务环境中，对法规、法律和其命令的合规性管理已成为成功的关键。指令几乎控制着业务经营的各个方面，要求组织为监管机构、利益相关者、客户和业务合作伙伴提供保证。

1.保证整个企业的合规性迫切需要一个整体的、易实施的、自律的方法，用它来定义一个完整、一致的流程和系统层的内部控制集。内部控制尤其应帮助组织达成它的目标，这些目标涉及有效和高效运营、可靠的对内和对外报告，并遵从适用的法律、法规和内部政策。2000年早期一连串大型公司的丑闻导致各种法律法规的产生，例如Sarbanes–Oxley Act （SOX）和 Basel I–III。为达成这些监管措施，许多公司采取措施把控制整合到他们业务流程和企业制度中。然而，他们所做的大多数尝试形成了一个个极具自身特色、孤立的解决方案，其中包括对实现跨多系统的合规需求的控制进行硬编码。这些分离的结构难以适应不断变化的业务环境以及越来越多的法律、法规和标准。

2.我们走向业务流程合规性综合管理的第一步，是开发了基于模式的方法，通过此方法来捕获和管理业务流程合规需求。本方法作为对业务流程进行充分自动化和不断审计的起点。在管理业务流程内部控制管理方面，业务流程合规性主流方法也面临着一些挑战，它们过于分散孤立，而且只关注了回顾性报告。

3.但是，这样会产生被动的风险防范，因而经常需要付出昂贵的代价,诸如Oracle GRC（治理、风险和合规性）Accelerators的现有工具和SAP Business Objects GRC解决方案提供的解决方法仅能用于一体式应用（比如企业资源计划系统，或ERP系统）。这严重影响了这些解决方案在现代业务流程及以此为支撑的企业系统中的可用性，因为这些系统高度分散并互联互通的。

因为业务流程合规性和规格说明书伴随于不同的生命周期，而且它们通常由不同的利益相关者制定,所以应该将它们解耦，作为单独的实体进行管理。通过把流程规格说明书中的合规需求进行逻辑解耦，我们可以更好地管理它们历经的演变和所做的改写。为了达到这个目标，我们应该在合规需求和业务流程规格说明书之间建立双向追溯。回溯合规需求的最初来源、经历的过程、已经实现和实施的业务系统,以分析变更合规需求的影响。用这种方法，我们也可以避免在不同的应用程序中重复地实现处理合规信息的方法。

通过部分或完全地自动化质量保证任务，我们可以很大程度上避免在昂贵的人工过程检验中产生的错误和遗漏，从而降低合规性质量保证的整体成本。自动化程度取决于捕获并形式化合规需求的能力。但很不幸地是，业务用户很难使用形式化语言去捕获需求，因为他们不具备这些语言技能和相关经验。

我们的框架和模型

与业务流程合规性相关的问题，包括适应性和演变、被动风险管理和自动化（包含形式化），需要一个可重复的、可预见的、整体的方法，该方法可以横跨所有业务流程生命周期。为了解决这些问题，我们首先开发了一个业务流程合规性管理（BPCM）框架，它整合了业务流程生命周期的合规性管理实践。然后，我们为集中式合规资源库开发了一个概念模型（紧密结合上述框架），该模型用于捕获和管理合规需求以及相关的概念。（此前发表了一篇论文介绍了该框架和概念模型的基础。图1：业务流程合规性管理（BPCM）框架（a）运维组件。（b）合规资源库概念模型的关键元素。该框架整合了业务流程生命周期的合规性管理实践。该模型捕获和管理合规需求以及相关的概念。

图 1：业务流程合规性管理（BPCM）框架。

（a）运维组件。

（b）合规资源关键元素的概念模型。该框架整合了针对业务流程生命周期的合规性管理实践。该模型捕获和管理合规需求和相关的概念。

图1a描绘了框架的一张运维视图；关键运维模型的说明可查阅侧栏（译注：在论文编排中，此部分内容位于侧栏，在本文中，出于编辑的便利，放到了文章底部。下同。）的“业务流程合规性管理框架”。该图说明了业务流程生命周期中的主要阶段如何与合规性管理实践紧密关联以达成需求的合规性。这些实践以COSO（全美反舞弊性财务报告委员会发起组织）框架为基础，该框架是建立内部控制的事实标准。图1b展示了从合规性管理实践中出现的关键概念和相互关系，它包含合规资源库的构件。该框架结合了模式，以更具业务用户友好度的方式，采用半正式（图形化）符号定义常见的合规需求的内部控制。这有助于自动化生成统一格式的规格说明书，因为它帮助业务和合规性专家屏蔽了语言的复杂性。我们在不同的方向扩展和增强该基于模式的方法，使其可以处理更大范围的控制规则。为了研究方法的适用性，我们实现了一组完整的软件应用套件，并在两个案例研究中试验了套件的三个关键组件。

控制和过程

控制模式

控制可以分为预防性的或检测性的。预防控制有助于防止缺陷，示例包括认证、职责分离和监管审批等。检测控制常常产生已发生缺陷的有关信息，这些信息帮助人们理解产生缺陷的原因，示例包括管理评审和对账等。我们也可以按照控制的适用之处对它们进行分类。流程控制适用于与业务流程设计和执行相关的政策与实践，这种控制包括认证、审批、检查和职责分离等。控制也可分为技术控制和物理控制，技术控制涉及设备和系统的使用，它们主要用于认证、加密或安全目标，这种控制包括防火墙和入侵防护或检测系统等。物理控制主要用来保护关键资产，这种控制包括锁、围栏和警报器等。

控制与业务流程

业务流程同时接受预防和检测过程控制的约束。这些控制的自动化极为重要，因为从长远来看，定期地设计和检验手工控制成本极高。在企业系统内实现流程的自动化保障，要采用形式化方式定义用于流程控制的规则。我们应该只形式化那些可以节约检查成本的控制，并通过自动化技术进行监控。一条控制规则通常是一份声明命题，由一组条件及其对应的一个（或多个）结论组成。在语句规则块中构建业务流程元素和它们的属性。例如，我们可以使用线性时序逻辑（LTL）形式化地说明一个控制，使其检查“客户贷款请求超过100万美元由主管审批”的规则：

促进形式化

将合规性自动化保障形式化为具体规则为合格性管理带来了巨大的价值。然而，由于形式化语言的复杂性及其固有的易有性问题，使用户很难上手使用。我们开发的过程控制模式可以帮助合规性专家和业务专家以结构化和半正式的形式表示过程控制，然后自动生成用于后续合规性评估活动的形式化规则。控制模式是高层次的、特定于领域的模版，模版描述了应用于流程规格中的必要内容。例如，Receive_Invoice(收到支票)Leads To Make_Payment（支付），它使用了Leads To模式来表达此控制，用于检查在Receive _Invoice（收到支票）之后是否执行了Make_Payment(支付)逻辑。表达式使用模式和过程元素、元素属性或基于属性的条件。为了处理规格说明书中复杂的合规性控制，我们可以使用布尔操作（比如“与”、“或”和“异或”）组成嵌套表达式。

我们应该只形式化那些通过自动化技术能够有效地检查和监控的控制。

识别模式

为了发现可用于常见控制类型的模式，我们分析了大量的法规、标准和框架（例如，COSO、 COBIT（信息控制对象和相关技术）、OCEG（开放合规性及伦理组） GRC（治理、风险与合规）、ISO/IEC 27000和SOX）以及在各种课题中研究的合规需求。我们还学习研究了基于模式的方法，这些方法用于为过程指定不同的需求（查阅侧栏的“合规性自动化相关工作”）。在识别模式时，我们专注于预防性过程控制，我们可以用它做设计期自动化验证和运行期监控。我们将此分成如下四类模式：

命令模式涉及过程操作的行为面，例如活动排序。

事件模式处理流程规格说明书中现有的某些结构或条件的规则。

资源模式解决认证、任务分派和职责分离的需求。例如，Verify_Banking_Privilage SegregatedFrom Check_Credit_Worthiness（从信贷可靠性检查中验证银行业务权限控制的隔离）指定了一条职责分离规则，表示这些活动必须分配给不同的角色，而且，必须由不同的用户执行。

时间模式与命令和事件模式一起使用，用来处理全部过程中的临时规则。例如，Receive_Invoice LeadsTo Make_Payment_Within 5(days)（收到发票引发5天内应付款）在流程活动上明确了时间限制。

表1列出了我们已识别的模式。

我们把这些模式分为基本和高级两类，以区分经常使用的模式和不常使用的模式，不常使用的模式通常用于处理更加复杂的控制。

映射

接下来基于模式的方法，我们可以使用模式抽象表示控制，然后在模式和适当的形式化语言之间使用一个映射方案，把模式映射为一组形式化语句。我们将线性时序逻辑（LTL）和度量时序逻辑（MTL）作为形式化语言，主要的原因是因为它们有较好的表达能力，并且已广泛应用于研究和实践。MTL能让我们形式化基于时间模式的表达式；LTL不支持这样的特性。

我们针于每种模式开发了LTL或MTL的映射图，用以自动化生成相应格式的语句。例如，

Verify_Banking_Privilege SegregatedFrom Check_Credit_Worthiness

会生成以下LTL语句：

1）F(Verify_Banking_Privilege) ^ F(Check_Credit_Worthiness) 检查规格说明书中是否存在这两个活动。

2）G(Verify_Banking_Privilege.Role(Role1) ?(Check_Credit_Worthiness.Role(Role1))) 检查这两个活动是否赋予了不同的角色。

3）G(Verify_Banking_Privilege.User(User1) ?(Check_Credit_Worthiness.User(User1))) 检查是否由不同的用户执行这两个活动。

我们可以把这些语句作为合规性验证和监测的输入。

实现

图2显示了我们软件集中的三个关键组件。（操作演示请见http://eriss.uvt.nl/compas。）。合规性需求管理能帮助合规性和业务专家更好地定义和管理合规性信息，并建立这些信息与业务流程的关系。需求、指令、风险、控制和特定的形式化规则是这些信息的关键元素。我们把这个组件实现为一个Web应用，把它作为合规性资源库的接口。合规性规则建模器（参考图3）是一个独立工具，它以图形化的方式设计基于模式的表达式，并自动生成相应格式的语句。它从业务流程资源库中检索有助于创建表达式的流程元素，在合规性资源库中保存表达式和已生成的形式化语句。两个资源库共享同一个数据库环境。设计期合规性验证管理也是一个Web应用，它可以静态验证流程规格的形式化规则。首先，它从业务流程资源库中检索需要检验的流程模型（以业务流程执行语言定义的）。然后，它使用集成的Web服务分析工具（WSAT：www.cs.ucsb.edu/~su/WSAT）把这些流程模型转换成形式化的表现方式，以便于Spin model checker（http://spinroot.com）检查它们的形式化控制规则。WSAT和Spin都已被广泛应用。接下来，该组件从模型检查器中检索结果，并把结果报告到仪表盘上。

图 2。BPCM套件的三个关键组件，包括业务流程资源库和合规性资源库。

案例研究

下面有银行和电子商务的两个案例研究；我们选择它们的主要原因是它们应用严格的、高度多样化的法规。第一个案例研究与贷款流程相关。第二个与一个网络代理公司相关，包括诸如订货单处理、发票、付款和交货等这样的流程。我们观察了参与者如何应用我们的方法和三个工具套件组件，并且在源于真实需求的捕获控制中测试了模式表达式。在案例研究中我们提及的流程总计有59条高层次合规性需求约束；这些需求涉及诸如职责划分、管理评审和认证等关注点。它们主要来源于ISO/IEC 27000、SOX和内部政策。这两个案例的研究团队包括3名合规性专家和2名业务专家，在我们框架的各阶段他们紧密配合开展工作。该案例研究组织已经明确他们打算遵循哪些指令。团队充分考虑源于这些指令的需求和已有的流程定义，识别和评估满足这些需求的风险。然后，他们为了规避风险定义了必要的控制，生成了形式化规则，针对这些控制验证了流程规格说明书。

表2展示了风险评估的控制类型和数量。

其中大多数是预防性过程控制，包含的规则主要关注职责划分、基于条件的活动序列和认证。检测过程控制主要包括管理评审和对账。换句话说，技术控制是预防性的，涉及了用于数据加密、数据保留和认证机制的特定技术。

我们对预防性控制充满兴趣，因为基于模式表达和形式化的主要目标就是预防性控制。参与者能够用规则建模器表达72个控制（全部有82个），但却没有有效的模型来表达另外10个预防性流程控制。那10个控制主要涉及在流程中所操作数据的结构和完整性的相关规则。它们通常要求业务对象应进行唯一性编号，比如订单或发票。模式对此类控制没有什么作用。同样，模式也不支持技术控制、物理控制和检测过程控制的表达和形式化，因为它们经常需要采用手工检查验证的方式作为保证手段。排除这些限制，模式可以有效地表达和形式化控制，以用于自动化地保证手段。特别是，它们还可以精确地捕获并验证与控制流程、资源和流程时序相关的关注点。最常见的是PLeadsTo命令模式，然后是SegregatedFrom资源模式和Exists事件模式。在时间模式中，最常见的是Within k。在那72个流程控制中，这四个模式出现在了其中的60个流程控制中。

图 3.这是合规性规则建模器的一张截图，它展示了基于模式表达式的图形化实例。它从业务流程资源库中检索流程元素，这些元素有助于创建表达式。在合规性资源库中保存表达式和已生成的形式化语句。

我们正持续不断的在各个方向开展研究工作，以增强乃至完全支持合规性管理框架。现在我们正在开发、实验合规性监控以及运行期合规性管理的解决机制。此外，为了满足特定行业（比如医疗保健、环境、能源、工业等领域）的合规性需求，我们正在定义垂直合规性管理解决方案。最终，我们将把合规性管理解决方案移植到云中，在开放的合规性即服务（compliance-as-aservice）的平台上提供这些服务。

致谢

我们在此向PricewaterhouseCoopers（荷兰）、Thales Services（法国）和COMPAS（适用于服务的合规性驱动模型、语言和架构）项目的合作伙伴表示衷心的感谢，他们为我们的研究案例和场景提供了大力的支持与协助，并提出了非常有价值的反馈意见。

业务流程合规性管理框架

业务流程合规性管理框架具有以下关键操作组件。（查阅正文中的图1可了解它们之间的组合关系。）

目标设置和边界识别

设置目标和识别边界是提升理解力并确立合规性的第一个步骤。边界即包括强制像法律法规这样的命令（例如，SOX—the Sarbanes-Oxley Act），也包括一些自我规定，比如最佳实践、标准、政策和商务合同。在合规性透视图中引入了两个本阶段的关键概念，分别是命令（合规性来源）和合规性需求。可以从抽象的约束或控制目标中获取需求，比如通过COBIT（信息及相关技术的控制目标）框架做出的那些定义。

风险评估与响应

组织目标的落实存在许多内在不确定性，基于风险的方法可以更好地理解和管理这些不确定性。综合考虑合规性目标和当前设计流程，必须识别、评估关键事件并进行排序，它们有可能破坏流程合规性。

控制定义与实现

控制是减少可能的合规性风险的关键。它们规避风险并为满足合规需求提供合理地保证。在此阶段，合规性专家（内部审计师）通常与法律专家和业务流程专家在一起工作。这是因为，在流程上分析风险并定义需要的控制不仅需要合规性知识，而且也需要业务流程领域知识。

设计期合规性验证

设计期合规性验证是预防性的，是确保所设计的流程能够合规执行的关键。这通常包括使用模型检查的方法针对形式化控制规则静态验证流程规格，可以在业务流程生命周期中的设计阶段检查这些规则。一旦流程规格通过验证、测试，达到了一个稳定的状态，那么它们就可以用来部署和执行。

运行期合规性监控

在设计期，不可能针对所有适用的需求进行流程验证，因为一些规则需要运行期的信息或可变的实例，这些实例此时是无法得到的。有些规则取决于运行期的条件，我们在运行期针对这些规则观察正在执行的流程实例。就像设计期验证，运行期合规性监控也是预防性的，它的目的是在它们发生之前就找出可能的违规操作。例如，职责分离需求可以预防一个特定的用户批准他（她）自己创建的订单。

离线合规性分析与监控

为了确保业务流程全生命周期的合规性，在预防性保证活动之前补充了这个检测步骤。该阶段主要涉及流程执行数据的分析，通过分析检测可能的缺陷和趋势。仪表盘以合规性指示灯的方式呈现检验结果。如果监测表明流程执行偏离或违反了要求,那么流程定义可能就需要进行矫正调整了。

合规性自动化相关工作

在业务流程和企业系统合规性保证的自动化研究中，通常会用到形式化技术1–3，该研究专门针对特定的业务流程关注点或业务流程生命周期中的某一阶段。为了使用户层规则更加规范，一些研究人员已经习惯使用基于模式的方法或图形化语言。例如，Kioumars Namiri和Nenad Stojanovic专门用于于业务流程执行阶段，提出了一组在运行期监控合规性的模式。Linh Thao Ly及其同事们随后提出一个类似的方法，该方法使用合规性规则图(一种关于事件发生和排序4的规则建模语言) 针对指定的需求监控业务流程的执行。Wil van der Aalst及其同事们在流程事件日志或流程行为实时数据监控上应用了流程挖掘技术5。

针对设计期的静态业务流程验证，Jian Yu和同事们6扩展了Matthew Dwyer及其同事们提出的模式。Volker Gruhn和Ralf Laue也研究了那些模式的扩展，以表现实时相关的内容8。Ahmad Awad及其同事们引进了一种可视化语言，BPMN-Q（业务流程建模符号-查询），它实现了表达业务流程控制流和数据流9合规性需求的基本模式集。BPMN-Q把CTL(计算树逻辑)作为它的基本形式。Andreas Speck和同事们提出了G-CTL，这是一种CTL的图形化语言，用这种语言在设计期详细说明要验证的流程需求。但是，它们没有采用模式进行规格说明。在业务流程中的建模资源分配与授权也是重要的研究领域，特别是在信息系统安全中。Christian Wolter和Andreas Schaad提出了一组用于建模的模式，比如在BPMN模型中的约束11。这些模式通常用于在此讨论的研究中，正文中表1里大多数模式的构成都是以这些模式为基础的。我们合并并扩展了这些模式，使它们在不同方向覆盖广泛的规则、考虑不同的合规性指令。接下来我们在现实案例中研究它们的用途和能力。