MIA - A Method for Achieving Compliance in Flexible and IT Supported Business Processes (Extended Abstract)

Keywords

• business process
• compliance
• change
• IT architecture

-

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 method. Then, I introduce the method MIA, its demonstration in a software prototype and evaluation, as well as possible implications and further research. 2 2.1

Motivation Scenario and Research Method

Motivation Scenario

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 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 ].

Model a common Model basis for

Identify Impact on

Compliance supports basis for

supports

Conceptual Domain Model supports

Compliance Process

Taxonomy

supports

Adapt Business Processes

Artefact

Relation

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 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 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 ].

Internal Payments Policy XOR

N-Way-Match

Check Invoice ChMecaknIunavlloyice

Trigger: Delivery has arrived Further Requirement: ERP MM Trigger: Delivery has arrived Further Requirement: none

Trigger: Create PaymCehnetcOkrder payment order

Further Requirement:

ERP FI ...

Send purchase requisition

Send purchase requisition

Send purchase requisition

Delivery has arrived

Check Invoice ERP MM Create payment order Delivery has arrived

Manually

Check Invoice Delivery has arrived

Create payment order Create payment order

Check Payment Order 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. 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 )

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 . GIJahrestagung , 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 )