, I briefly present a motivation scenario and the applied research method. Then, I introduce the method MIA, its demonstration in a software proto-type and evaluation, as well as possible implications and further research.
2. Motivation Scenario and Research Method 2.1. Motivation Scenario
Figure 1 shows a purchase to pay process that is supported by IT components, which are in turn
connected to each other. On top of that, compliance requirements linked together, place demands
against both business activities and IT-components. The compliance process “check invoice,” in turn,
helps to satisfy the compliance requirement “internal policy payment.” In the case of replacement or
removal of an element, the impact on compliance must be determined to further achieve compliance.
In case of replacing “ERP MM,” which can be, e.g., the case of outsourcing, all compliance
requirements that directly or indirectly place demands on this IT component must be observed. In the
case of removing an element, all possible compliance violations must be determined, as well. An
unplanned failure of “ERP MM” corresponds, for example, to a removal of this IT component [
Logical Access
Send Purchase Requisition
Delivery has arrived
Check Invoice
Execute Payment
Physical
Access Legal Obligation to Keep
Records Internal Payments Policy Create Payment
Order Hardware ERP MM
ERP FI
Replace ERP MM
Logical Access (CR)
Hardware (IT) Physical Access (CR)
Check invoice (CP) Internal Payments Policy (CR)
Delete ERP MM Check Invoice (CP) Internal Payments
Policy (CR)
Logical Access (CR) place
place
IT is prerfeoqruisite activity CR dempalancdes to activity
IT is prerequisite IT
for cp hsealptissfyto CR CP: compliance process | CR: compliance requirement | IT: IT component IT is prerequisite for
cp setnadrteevveenntt, egxacteluwsaivye cehleamngeendt redliareticotn cehleamngeendt trraenlastiitoivne impact element impact element violated CP/ CR obsolete element
Following the design science research paradigm [12] different artifacts have been developed, which
can be orchestrated to the method MIA (see Figure 2). The basis is a conceptual domain model [
Model a common Model basis for
Identify Impact on
Compliance supports basis for supports
Conceptual Domain Model supports 3. Achieving Compliance in Flexible and IT Supported Business Processes
Step 1: Model a common model. To analyze the impacts on compliance when replacing and removing either a compliance requirement, business activity, and IT component, a common model, such as the one shown in Figure 1, must be modelled. These common models are based on a previously modelled IT-architecture model (e.g., a TOGAF model), a business process model (e.g., a BPMN Compliance Process
Taxonomy supports
Adapt Business Processes Artefact
Relation
model) and compliance requirement model. Further, the common model is defined as a direct graph, in
which each node represents either a single IT component of the IT architecture mod-el, an event,
activity, and gateway of the process model or a compliance requirement. Additionally, these nodes can
be linked to each other, e.g., to define the de-pendency between activities and IT components,
compliance requirements and activities, or different compliance requirements [
Step 2: Identify impact on compliance. The impact on compliance due to changes differs by the type
of change. In case of replacing “ERP MM” by another IT component, all compliance requirements must
be determined, which affects “ERP MM” directly and transitively (see Figure 1). In case of removing
“ERP MM,” all violated and obsolete compliance requirements must be determined to further achieve
compliance. In the motivation scenario, the compliance requirement “internal policy payment” and the
higher-level compliance requirement “legal obligations to keep record” are violated because the
compliance process can no longer be executed. Both analyses require different search strategies, which
are executed on the common model from Step 1 [
Step 3: Adapt business processes. In case of a compliance violation, e.g., removing “ERP MM” as
a necessary IT component of the compliance process within the business process, the business process
must be adapted to remain compliant. Since more than one compliance process can satisfy a compliance
requirement, a business process can be adapted through the integration of an alternative compliance
process. Thus, a prerequisite is the modelling of alternative compliance processes that satisfies the same
compliance requirement. Alternative compliance processes are differentiated by their properties such
as requirements for execution and type of execution [
Alternative compliance processes and their related compliance requirements are modelled in a graph
structure separately from the business process. Within these graph structures, the search for alternative
compliance processes is completed. In case various alternative compliance processes are identified,
MIA proposes all com-pliant business process [
XOR
Check Trigger: Create Payment Order payment order
ERP MM
To demonstrate the feasibility of MIA, I implemented the method in the software prototype BCIT [11]. BCIT allows for importing compliance requirements, business processes and IT components. Once these models are linked together, the impact by replacing or deleting any of the mentioned elements on compliance can be deter-mined automatically. If alternative compliance processes have been defined, BCIT can also propose alternative compliant business processes through the integration of alternative compliance processes.
An addition, I evaluated the perceived usefulness of BCIT in case studies which were conducted
with domain experts in the field of process management, compliance management, and IT architecture
management. The data collection was done via questionnaires asking about the perceived usefulness of
software artefacts. [
For research, there are implications to the descriptive and prescriptive knowledge bases [13]. The contribution to the descriptive knowledge base are the identified research gap, and the compliance metamodel to conceptualize our domain. The contribution to the prescriptive knowledge base includes the methods to identify compliance violations and propose compliant business process models. In addition, MIA has general implications for practice. As stated by the domain experts during the case studies, MIA opens up new potentials for detailed root cause analyses, which can result in a competitive advantage.
On the one hand, further research can be done by the process adaption. In addition to BPMN process models, formal process representations, e.g., scripting languages can also be considered. On the other hand, the idea of modelling alternative compliance processes that satisfies the same compliance requirement can also applied to IT architectures. In this way, alternative IT components that meet the same business requirements can be modelled, e.g., in the form of different cloud service models and cloud service providers.
[11] Seyffarth, T., Raschke, K.: BCIT. A Tool to Recommend Compliant Business Processes based on Process Adaption. Proceedings of the Best Dissertation Award, Doctoral Consortium, and Demonstration & Resources Track at BPM 2020, 107–111 (2020) [12] Peffers, K., Tuunanen, T., Gengler, C., Rossi, M., Hui, W., Virtanen, V., Bragge, J.: The Design Science Research Process. A Model for Producing and Presenting Information Systems Research. 1st International Conference on Design Science in Information Systems and Technology (DESRIST), 83–106 (2006) [13] Gregor, S., Hevner, A.R.: Positioning and Presenting Design Science Research for Maximum Impact. MIS Quarterly 37 (2013)