=Paper=
{{Paper
|id=Vol-2966/paper6
|storemode=property
|title=MIA – A Method for Achieving Compliance in Flexible and IT Supported Business Processes
|pdfUrl=https://ceur-ws.org/Vol-2966/paper6.pdf
|volume=Vol-2966
|authors=Tobias Seyffarth
}}
==MIA – A Method for Achieving Compliance in Flexible and IT Supported Business Processes==
https://ceur-ws.org/Vol-2966/paper6.pdf
MIA - A Method for Achieving Compliance in Flexible
and IT Supported Business Processes
(Extended Abstract)
Tobias Seyffarth1
1Martin Luther University Halle-Wittenberg, Chair of Information Management,
Halle (Saale), Germany
tobias.seyffarth@wiwi.uni-halle.de
Keywords: business process; compliance; change; IT architecture
1 Motivation
Compliance describes the adherence to compliance requirements, which can be derived
from laws, norms, and contracts [1]. In addition to business processes, compliance
requirements can also place demands on IT components, which in turn may be
necessary for the execution of activities [2]. To satisfy compliance requirements and
thus ensure compliance, so-called compliance processes can be used. A compliance
process is an independent process (part) consisting of at least one compliance-related
activity that ensures compliance. In addition, compliance processes can be integrated
in business processes to ensure business process compliance [3].
Many factors, such as new technologies, improvement of business processes, and
outsourcing decisions can lead to the replacement or removal of activities, IT
components, and compliance requirements. In dynamic markets, the impact on
compliance due to these changes should be determined automatically. In case of a
compliance violation, the business process must also be adapted [2, 4].
There are approaches that queries the relations between compliance requirements,
and business processes (e.g. [5]), compliance requirements and IT components (e.g.,
[6, 7]) and interrelated compliance requirements (e.g., [7]). In addition, there are also
approaches that adapts the business process through the integration of separate
modelled compliant process fragments (e.g., [10]). However, current approaches
neither distinguish between the change patterns, replace and delete, nor do they
consider IT components in both identification and adaption [8, 9].
Thus, the goal is a method to achieve compliance in flexible and IT-supported
business processes. MIA supports the achievement of compliance in IT-supported
business processes in two steps. On the one hand, MIA identifies the impact on
compliance by removing and replacing either a compliance requirement, business
activity, or IT component. On the other hand, MIA provides recommendations for a
business process adaption in case of a compliance violation. In the remainder of this
extended abstract, I briefly present a motivation scenario and the applied research
16th International Conference on Wirtschaftsinformatik,
March 2021, Essen, Germany
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
93
method. Then, I introduce the method MIA, its demonstration in a software prototype
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 [2].
Replace ERP MM Delete ERP MM
Legal Obligation to Keep
Logical Access (CR) Check Invoice (CP)
Records
Legal Obligation to Keep Internal Payments
Records (CR) Policy (CR)
Logical Internal Physical
Access Payments Hardware (IT) Legal Obligation to Keep
Policy Access Records (CR)
Delivery
has arrived Physical Access (CR) Logical Access (CR)
Send Create
Check Invoice Execute Legal Obligation to Keep
Purchase Payment
Payment Records (CR)
Requisition Order
Check invoice (CP)
ERP ERP Internal Payments Policy
MM FI (CR)
Legal Obligation to Keep
Hard- Records (CR)
ware
place is prerequisite is prerequisite is prerequisite cp changed direct impact violated
CR demands to CR IT for activity for for element relation element CP/ CR
IT IT IT
place place cp helps to changed transitive impact obsolete
CR demands to CR activity CR element relation element element
IT demands to satisfy
start event, exclusive
CP: compliance process | CR: compliance requirement | IT: IT component end event gateway
Figure 1. Purchase to pay process and impact on compliance due to
a replacement and removal of an IT component [11]
2.2 Research Method
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 [3], which describes the relations between compliance
requirements, IT components, and business compliance processes. Essentially, MIA
consists of three steps, and each of it is a separate method. First, a common model that
consists of a business process model, IT components, and compliance requirements is
modelled. Second, the impacts on compliance by replacing and removing any element
in the previously defined common model are determined [2]. Third, to achieve business
process compliance, MIA proposes recommendations for an adaption of the business
94
process through the integration of alternative compliance processes [4]. To distinguish
compliance processes, a compliance process taxonomy was developed to describe the
properties of compliance processes [3].
Compliance Process
Taxonomy
supports
basis Identify Impact on basis
Model a common Model for Adapt Business Processes
Compliance for
supports
supports Conceptual Domain Model supports
Artefact Relation
Figure 2. Artefacts of MIA
3 Achieving Compliance in Flexible and IT Supported Business
Processes
3.1 A Brief Introduction to MIA
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 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 model, 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 dependency between activities and
IT components, compliance requirements and activities, or different compliance
requirements [2, 8].
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 [2].
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
95
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 [3].
Delivery
Internal Payments Policy has arrived
Send Check Create
Execute
XOR purchase Invoice payment
payment
requisition order
N-Way-Match
Trigger: Delivery ERP MM ERP FI
has arrived
Check Invoice
Further Requirement: Delivery
ERP MM has arrived
Send Manually Create
Execute
Trigger: Delivery purchase Check Invoice payment
payment
Manually requisition order
has arrived
Check Invoice Further Requirement:
none ERP FI
Trigger: Create Delivery
Check payment order has arrived
Payment Order
Further Requirement: Send Create Check Execute
ERP FI purchase payment Payment Order
payment
requisition order
...
ERP FI
Each of the related Generalization / Specialization
Compliance Properties of the Compliance
compliance process Process Compliance relation between Compliance
Process Process (refer to the
XOR patterns or compliance Pattern Process Patterns and Compliance IT Component
Compliance Process
processes can statisfy the Processes Taxonomy)
compliance requirement
Figure 3. Adaptation of the purchase to pay process through alternative compliance processes
(based on [4])
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 compliant business
process [4] as shown in Figure 3.
3.2 Demonstration and Evaluation
To demonstrate the feasibility of MIA, we 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 determined
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. [8]. The
majority of the participants find BCIT useful for their jobs. Further, they stated that
BCIT gives them a greater control over their work, because of the modelling the
relations between compliance requirements, business processes, and IT components.
96
They also mentioned that the integrated model increases the transparency of their
workflow as well as the associated technical and legal dependencies. Nevertheless,
some participants pointed out that the effort for both modelling of the common model
and the alternative compliance processes might be too high in comparison to the
expected effort.
4 Implications and Further Research
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 meta- model 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 satisfy the same compliance requirement can also be 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 [14].
References
1. Sadiq, S., Governatori, G., Namiri, K.: Modeling Control Objectives for Business Process
Compliance. In: Alonso, G., Dadam, P., Rosemann, M. (eds.) Business Process
Management, 4714, pp. 149–164. Springer Berlin Heidelberg, Berlin, Heidelberg (2007)
2. Seyffarth, T., Kühnel, S., Sackmann, S.: Business Process Compliance and Business Process
Change. An Approach to Analyze the Interactions. Business Information Systems. BIS
2018. Lecture Notes in Business Information Processing, 176–189 (2018)
3. Seyffarth, T., Kühnel, S., Sackmann, S.: A Taxonomy of Compliance Processes for Business
Process Compliance. 15th International Conference on Business Process Management,
Business Process Management Forum. In: Lecture Notes in Business Information
Processing (LNBIP), 71–87 (2017)
4. Seyffarth, T., Kühnel, S., Sackmann, S.: Business Process Compliance despite Change.
Towards Proposals for a Business Process Adaption. Information Systems Engineering in
Responsible Information Systems. CAiSE 2019. Lecture Notes in Business Information
Processing, vol 350., 227–239 (2019)
5. Fdhila, W., Rinderle-Ma, S., Knuplesch, D., Reichert, M.: Change and Compliance in
Collaborative Processes. 12th IEEE International Conference on Services Computing (SCC
2015), 162–169 (2015)
97
6. Knackstedt, R., Eggert, M., Heddier, M., Chasin, F., Becker, J.: The Relationship Of Is And
Law - The Perspective Of And Implications For IS Research. ECIS 2013 Completed
Research (2013)
7. Sillaber, C., Breu, R.: Managing legal compliance through security requirements across
service provider chains. A case study on the German Federal Data Protection Act. GI-
Jahrestagung, 1306--1318 (2012)
8. Seyffarth, T., Kühnel, S.: Maintaining business process compliance despite changes. a
decision support approach based on process adaptations. Journal of Decision Systems (2020)
9. Sackmann, S., Kühnel, S., Seyffarth, T.: Using Business Process Compliance Approaches
for Compliance Management with regard to Digitization. Evidence from a Systematic
Literature Review. International Conference on Business Process Management (BPM)
(2018)
10. Kittel, K., Sackmann, S., Göser, K.: Flexibility and Compliance in Workflow Systems. The
KitCom Prototype. Proceedings of the CAiSE'13 Forum at the 25th International Conference
on Advanced Information Systems Engineering (CAiSE), 154–160 (2013)
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 co-located with the 18th
International Conference on Business Process Management (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)
14. Seifert, M., Kühnel, S.: HySLAC. A Conceptual Model for Service Level Agreement
Compliance in Hybrid Cloud Architectures. Informatik (2020)
98