Abstract
It is a typical scenario that many organisations have their business processes specified independently of their business obligations (which includes contractual obligations to business partners, as well as obligations a business has to fulfil against regulations and industry standards). This is because of the lack of guidelines and tools that facilitate derivation of processes from contracts but also because of the traditional mindset of treating contracts separately from business processes. This chapter will provide a solution to one specific problem that arises from this situation, namely the lack of mechanisms to check whether business processes are compliant with business contracts. The chapter begins by defining the space for business process compliance and the eco-system for ensuring that process are compliant. The key point is that compliance is a relationship between two sets of specifications: the specifications for executing a business process and the specifications regulating a business. The central part of the chapter focuses on a logic based formalism for describing both the semantics of normative specifications and the semantics of compliance checking procedures.
Top1. Introduction
The term compliance is applied in many disciplines such as management, standards development, regulations, medical practice and so on. It is often used to denote and demonstrate adherence of one set of rules (we refer to them as ‘source rules’ hereafter) against other set of rules (we refer to them as ‘target rules’ hereafter). Typically, target rules represent an established or agreed set of guidelines, norms, laws, regulations, recommendations or qualities which, if obeyed, will deliver certain effect or value to those to whom they can apply, or to those with whom they interact. In some way, the target rules are intended for a global or broad community of participants in a specific universe of discourse. On the other hand, source rules are developed to apply to participants and their behaviours in certain local contexts, and adherence of source rules to the target rules then ensures that both local and global expectations or requirements can be met.
In management for example, target rules represent policies that need to be obeyed by companies, their staff or executives, while undertaking their normal course of actions to meet their goals. Examples of such rules are the US regulations such as Sarbanes-Oxley Act1 or Health Insurance Privacy Act (HIPPA)2. In standards development, compliance requirements are stated to ensure necessary consistency of one set of requirements with some broader set of requirements, e.g., a compliance of the ODP Enterprise Language with ODP-RM3. Note that in standards communities, the term conformance has a different meaning: it is used to relate an implementation to a standard specification. Finally, in health sector, compliance is referred to a patient’s (or doctor’s) adherence to a recommended course of treatment.
Similarly, we apply this interpretation of compliance as a metaphor to discuss adherence or consistence of a set of rules in business processes against a set of rules regulating a particular business. This set of rules can stem from different sources, legislation, standards, best practices, internal guidelines and policies, contracts between the parties involved in the process and so on. We will refer to the source of these as normative documents, and to the rules themselves as norms or normative specifications. So, ensuring compliance of business processes with a normative document means ensuring consistency of norms stated in normative documents and rules covering the execution of business processes. In other words, to check that the specification of a business process complies with a normative document regulating the domain of the process, one has to verify that all execution paths of the process, possible according to the specification of the business process, comply with the normative specification. This means that no execution path is in breach of the regulation. This consistency, for example, is necessary to satisfy commitments that parties typically state in their agreements or business contracts while carrying out their mutually related internal business activities. Such compliance also leads to benefits to both parties, e.g., minimisation of costs or damages to either party whether these are associated with potentially inadvertent behaviour or deliberate violations while seeking more opportunistic engagements.
Key Terms in this Chapter
Compliance: Compliance, also know as regulatory compliance, is the process by which an organisation ensures that the specifications for implementing business processes, operations and practise are in accordance with a prescribed and/or agreed set of norms.
Deontic Logic: Deontic logic is the branch of logic that studies the formalisation and properties of normative notions such as obligation, permission, prohibitions, violations and so on. Typically a deontic logic is an extension of classical propositional logic with modal (deontic) operators modelling normative concepts, i.e., obligations, permissions, prohibitions.
Formal Contract Logic (FCL): Formal Contract Logic is obtained from the combination of Defeasible logic (extended with deontic operators) and a Deontic logic of violation. The logic offers two main reasoning mechanisms, one mechanism to combine and to derive new norms (rules) from existing ones, and the second mechanism to derive the normative position in force for a particular case.
Defeasible Logic: Defeasible logic is a simple and efficient rule based non-monotonic formalism. The key idea of the logic is to derive (tentative) conclusions, i.e., conclusions that can be retracted when new piece of information become available, with a minimum amount of information.
Normative Position: A normative position regulates the (prescribed) behaviour of a group of actors in an institution (described by a set of norms). A one-agent normative position regulates the act of one actor; a two-agent normative positions regulate the (possibly joint) acts of two agents, and so on. Typically, obligations, permissions, prohibitions are basic normative positions, complex normative positions, e.g., delegation, power, are obtained by combination of simplex normative positions and actions.
Business Process Model: A business process model (BPM) describes the tasks to be executed (and the order in which they are executed) to fulfil some objectives of a business. BPMs aim to automate and optimise business procedures and are typically given in graphical languages. A language for BPM usually has two main elements: tasks and connectors. Tasks correspond to activities to be performed by actors (either human or artificial) and connectors describe the relationships between tasks.