Compliance is a relationship
between two sets of specifications, business processes and regulations. To be
able to determine the compliance one needs to have: a formal representation of
the business process, a formal representation of the regulations, and a common
framework to interface the two formal languages. Enterprises are more dependent
on PAIS (process aware information systems), and business processes are
increasingly constrained by the legislative and regulatory framework in which
they operate. Research should “address the issue of how to incorporate techniques
to handle normative requirements, and these techniques should be conceptual, in
the sense that they should provide notions and construction as close as
possible to the concepts they intend to models”.
The author believes that
there are three important features to be able to model compliance, which are
defeasibility, the deontic effect of a norm, and whether the effects of a norm
are persistent. “Defeasibility, the notion that a conclusion can be withdrawn,
in case of additional information that allow to conclude the opposite, is very
important in modelling normative reasoning where we can combine different
sources for norms. This is particularly suitable for processes, where we can
derive plausible conclusion based on the information provided, but when more
data becomes available the conclusion can be changed. The deontic effects
(obligations, permissions, prohibitions) are essential to capture compliance.
They specify what is permitted, forbidden and required to fulfill the normative
requirements. Finally the features about the persistency of normative effects
allow us to define different types of obligations, with different conditions
for their fulfillment of violation. These features have the effect that we are
able to model different types of common scenarios”.
The paper proposed a new language
“Process Compliance Language (PCL)” based on enhancing an older solution FCL
(formal contract language) from another paper (“An algorithm for business
process compliance”), it generalizes and extend FCL. First it distinguishes
between achievement obligation (happen at least once before deadline) and
maintenance obligation (continues). It also shows that achievement obligations
can be persistent (must happen even after deadline) or non-persistent (once the
deadline occur the obligation no longer holds). Also achievement obligations
can be preemptive (can happen before the trigger) or non-preemptive (must only
happen after the trigger). PCL provides a way of writing regulations that if an
obligation was violated the rule will show what to do next it uses the
non-boolean connective ‘⊗’ to link the obligation to
another obligation that would be enforced if the first one was violated (e.g. Oa,π
A ⊗ OpB ⊗ OmC means that the primary provision is an achievement, persistent,
obligation to do A, but if A is not done, then we have a punctual obligation to
do B. If B fails to be realised, then we obtain a maintenance obligation to do
C). The language also provides superiority relation (≺) determines the
relative strength of two rules, to solve potential conflicts. The process to
build the rules model in PCL is: 1- write regulations using the formal language
represented in here, 2- remove any redundant rules, 3- label and detect
conflicts.
The paper then explained
business process models and it main components, and gave an example process
from the banking field and showed it process model and how to write the related
rules using PCL. Then finally gave a procedure to check wither execution paths
of a process are compliant with the PCL and thus with the normative system
modeled by the PCL specifications. The procedure is: first identify set of
effects for all the tasks in the process. Second, for each task determine the
normative position (obligations, permissions, prohibitions). Finally, for each
task compare the effects of the tasks and the obligations accumulated up to the
task. If an obligation is fulfilled by a task, discharge the obligation, if it
is violated signals this violation. If it is not fulfilled nor violated, keep
the obligation in the stack of obligations and propagate the obligation to the
successive tasks.
Governatori in this paper presented a new language PCL, which can
be used to write regulations and rules. The language has the ability to show
different types of obligations and also handle violations. The language can
also be used to avoid conflict if they were detected in the writing stage,
using the consistent writing process. The paper only showed how this language
can handle rules that say what must be done, but do not have the ability to
follow a rule that say how to do it (the author claim that the language has the
ability and will be explained in another paper). The paper also provided an
algorithm that detects compliance between a business process and regulations
written in PCL. Although PCL can handle various types of obligations it did not
show how to handle permissions and prohibitions.
No comments:
Post a Comment