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