1 Balancing Flexibility and Compliance

Beyond doubt, business process management (BPM) has driven many innovations in companies and is still massively changing traditional organization forms. By standardizing processes and separating execution of activities from its control on a conceptual level, higher process transparency, efficiency, and customer satisfaction are now within reach. Thus, to remain competitive, many companies decided to actively manage their processes and to use information systems (IS) to support these. In particular, enterprise resource planning systems (ERP) or workflow management systems (WfMS) have been implemented and successfully used by many companies.

A very welcome “side effect” of applying ERP or WfMS is that such systems support not only process design by arranging activity sequences, assignment of predefined resources, realizing IS support of functionalities, etc., they also provide a way to technically enforce process execution as planned and to realize so-called compliance-aware process engines (Cabanillas, Resinas, & Ruiz-Cortes, 2011). The capability to enforce execution of workflows exactly in an ex-ante specified way does, in turn, not only maintain the achievement of “pure” or “original” business goals. It also has raised the interest of other management fields, since integration (and automated enforcement) of additional control activities provide powerful mechanisms and tools for realizing effective internal control systems (Sackmann, Hofmann, & Kühnel, 2013) that are an essential part of any risk and compliance management. For example, enforcing separation of duty or monitoring (and logging) actual execution states of each activity doubtlessly support achievement and validation of compliance to relevant laws, rules, and regulations like, e.g., Sarbanes Oxley Act (SOX), laws and regulations issued by the Basel Committee on Banking Supervision, Health Insurance Portability and Accountability Act (HIPAA), German Freedom of Information Act and many others more. So far, efficiently and effectively realizing both original process goals and compliance goals in one single workflow is a challenging issue that quickly turns into a real problem when either processes or compliance requirements (or, worse, both) change very frequently.

For actively managing the balance between flexibility and compliance, a methodical approach called FlexCom is presented in this paper. FlexCom has also been prototypically implemented within the adaptive workflow management system AristaFlow, demonstrating the general functionality of the approach. The remainder of this contribution is organized as follows: initially, some background information on the “trade-off” between flexibility of workflows and validation of compliance by controls together is given in the following section. Afterwards, the developed method FlexCom (third section) followed by a demonstration of its prototypical implementation called KitCom (fourth section) are presented and explained by means of a continuous workflow example. A short discussion and conclusion completes the contribution.

2 Flexibility XOR Compliance?

Achieving flexibility and compliance does, in general, not involve an inherent or insolvable contradiction. In practice, however, aiming for both goals usually means searching for an efficient and effective balance between flexible but (possibly) non-compliant workflows and compliant but (mostly) inflexible workflows. Thus, achieving both goals together frequently seems out of reach. Since achieving compliance (and also risk management) is substantially based on internal control systems, i.e., controls non-detachably integrated into workflows (e.g., approval to pay an invoice given by a supervisor), every change within the workflows should be validated against several management goals and requirements.

In doing so, current compliance approaches quickly reach their limits (Kittel, 2013): so-called hard-wired controls that are integrated on the level of workflow schemes have to be checked and validated, in principal, for each change of the process specification with regard to their effects on process performance as well as on compliance validation. Since validation is the core of compliance (Cannon & Byers, 2006) and it is usually a “manual” task requiring noteworthy time and effort, either flexibility or compliance can be achieved. For example, when important production parts for a time-critical order are ruined by accident late in the night and there is no person to authorize a necessary re-ordering, either the order can be executed by skipping the authorization process to the next morning (flexibility) or the workflow/production has to halt until all required persons are available and give their approval (compliance). Thus, changing a workflow (instance) in real-time and validating that the integrated controls are still achieving relevant compliance requirements appears as an inherent trade-off in many situations. Otherwise, if process designers aim at integrating necessary controls for all thinkable situations in advance, the convenient side effect results immediately in a plethora of conditional branches and control activities leading to a state that some authors already named “process pollution” (Schumm, Leymann, Ma, Scheibler, & Strauch, 2010).

Although more advanced approaches like the so-called repository solutions are usually capable of relieving the situation by defining for each foreseeable situation a single version of a compliant workflow scheme, enriched with adequate controls (see, e.g., Sadiq, Governatori, & Namiri, 2007), they usually bring their own complexity and do not solve the issue on a methodical or general level. Further methods and tools like the so-called (rule-based) monitors or ex post auditing approaches, e.g., process mining, also reveal several disadvantages in the light of the (typically) conflicting goals of business process management and compliance management (for a more detailed discussion see, e.g., Kittel, 2013): while the former is usually capable of enforcing compliance without adequately taking economic risk (e.g., interrupting a process instance) into consideration, the latter is usually capable of providing high flexibility of process execution, but this is inherently combined with a high risk of violating compliance goals (Sackmann, 2011). For realizing the opportunities for both business process and compliance management, it becomes obvious that both have to work together and, in practice, companies have to find a balance between flexibility and compliance and the required controls integrated into their workflows.

As extensively discussed in the literature, a flexible adaptation of ongoing workflows to new demands or changing contexts is challenging (see, e.g., Smith & Fingar, 2003; van der Aalst, Weske, & Grünbauer, 2005). Indeed, it is actually achievable on the level of workflow design or modelling (see, e.g., Weske, 2012) as well as on the technical level (see, e.g., Krafzig, Banke, & Slama, 2005) within so-called adaptive workflow management systems (see, e.g., Reichert, Rinderle, Kreher, & Dadam, 2005; Rinderle, Reichert, & Dadam, 2004). However, this available flexibility has not yet been exploited to its full potential, but the momentum to do so can be expected to become more pressing and serious when progressive methods, tools, and technologies in the fields of, e.g., cyber physical systems, big data analysis, business intelligence approaches, or process mining provide more and more results in real-time. Such developments will change the landscape of BPM further and form a promising basis for innovation, process improvement, and adaptation according to the actual execution context, quasi in real-time (some impressive examples are presented in other chapters of this book). Existing approaches towards solving the apparent trade-off and, in turn, the achievable “balance” can be expected to become increasingly unsatisfactory. Thus, it is not really surprising that the development of new methods and tools for changing workflows at run-time in accordance with actual environmental conditions and without violating compliance requirements is an emerging field of research (see, e.g., Ly, Rinderle-Ma, Knuplesch, & Dadam, 2011; Sadiq et al., 2007).

3 FlexCom: An Approach for Integrating Control Activities into Workflow Instances at Run-Time

The basic idea of our FlexCom approach is, at first, to allow managers of business processes to change the workflows if necessary. However, each change is actively monitored by FlexCom and analyzed according to its meaning for compliance management: if required and feasible, the change is allowed and the (ongoing) workflow is automatically adapted by controls in accordance with the compliant requirements. Thus, FlexCom does not focus on flexibility already provided by advanced WfMS but provides the methodic basis for identifying and adapting effective control activities in real-time for ongoing and changing workflows. FlexCom is based on a separation of controls and processes on the conceptual level (design time, see Fig. 1) and, thus, does not focus on the level of workflow schemes. In fact, this conceptual separation is the basis for our automated integration of control processes directly into single workflow instances during their execution (for more details see also Kittel, 2013; Kittel & Sackmann, 2011, 2012; Kittel, Sackmann, Betke, & Hofmann, 2013a). At least for several types of compliance requirements, this approach facilitates validation of compliance before workflow execution while still maintaining the possibility to adapt workflow instances at run-time.

Fig. 1
figure 1

FlexCom: a general approach for integrating control processes into workflow instances at run-time (Kittel & Sackmann, 2012)

Full size image

On a general level, the FlexCom approach can be separated into three main areas: firstly, the formal definition of reference controls that show how control activities can be executed to achieve a given compliance requirement; secondly, for each reference control, the identification and selection of integration points at which it is possible or, rather, reasonable to integrate them into workflow instances; and thirdly, the integration of control activities into workflows at run-time.

3.1 Defining Reference Controls

The generic starting point for a methodic integration of control activities into workflows is to define (formal) compliance requirements. For each compliance requirement, at least one or a set of general reference controls has to be defined. Such reference controls can be seen as a template where the activities and objects involved, as well as the general structure of the controls, are already designed (Kittel, Sackmann, & Göser, 2013b). For instance, the “second set of eyes” principle (compliance requirement) can be performed in several ways: it can be realized as a sequential execution of control activities or with two control activities in parallel. Furthermore, it can be performed executing two control activities successively or with other workflow activities in between. This template has to be substantiated at the moment when the reference control is instantiated. Thus, reference controls are similar to the scheme of workflows which can produce several instances if executed (van der Aalst & van Hee, 2004) and can be modeled with the same tools (Betke, Kittel, & Sackmann, 2013).

Furthermore, several parameters that are typical for workflows (and WfMS) can be used for the specification of reference controls and the conditions for their integration (integration parameters), e.g., data elements, values, organizational units, or temporal characteristics. Finally, similar to classical “by design” approaches, reference controls should be validated ex ante and before workflow instances are actually executed. In addition to the classical validation on the level of the workflow scheme, reference controls have also to be evaluated with regard to their integration parameters, i.e., the conditions that trigger its integration into a workflow instance. When all relevant reference controls are defined and validated, the identification and selection of appropriate controls as well as their technical integration into workflow instances are the next consecutive steps.

3.2 Identification and Selection of Integration Points

A dynamic integration of reference controls in the form of actual control processes into workflow instances during their execution has a significant advantage: there is more information available than at design time. This information can be used for flexibly adapting a workflow as well as control activities to the actual process context, for instance to implement (control) activities. Furthermore, integration at run-time allows control activities to be integrated only if they are actually needed in a specific instance and, consequently, can reduce the complexity of business process execution.

In order to realize such integration at run-time, all entities that can be used in a process model could be taken into account as relevant parameters. Based on the parameters identified by Sadiq et al. (2007), control integration parameters are assigned to three categories: structural, validity, and conditional control integration parameters. Within these categories, concrete information like the validity period, activities as precondition, and/or activities as post-condition have to be defined (Kittel et al., 2013b). This additional information is also part of our reference controls and named control parameters (see above). Then, using all these pieces of information it becomes possible to identify points for integrating concrete control activities into workflows. This can be realized by having automated search algorithms check the actual control parameters against the workflow instance information.

Since there might be a large number of different points in a workflow where integration is theoretically possible, a reduction to efficient control points is necessary. This reduction can be achieved by several methods, e.g., by calculating the so-called critical path and selecting an integration point that is not an active part of it. In our prototype KitCom, we decided to integrate the controls as early as possible, following a prudence principle [for a detailed description of the identification and selection algorithm see Kittel (2013)]. While the identification of possible integration points works on a general level, this selection is only a first heuristic. However, a method for finding the economically optimal integration point is not yet available and still part of current research [see, e.g., Sackmann et al. (2013)].

3.3 Integration of Controls into Workflows at Run-Time

Last but not least, the identified and selected reference control(s) have to be technically integrated as control processes into the workflow instance at the identified points. How integration actually takes place depends mainly on the WfMS engine that is used for executing and enforcing the workflow instances. Since workflow engines of specific WfMS are constructed with different capabilities and modus operandi, a general discussion of technical integration seems not to be appropriate. Therefore, in the following, we demonstrate the integration (as well as the definition of reference controls) by means of a prototypical implementation within the adaptive WfMS AristaFlow (see http://www.aristaflow.com).

4 Prototype KitCom: Integrating Controls at Run-Time

A prototype called KitCom, originally presented at the CeBIT 2013 and published by Kittel et al. (2013b), was created to integrate reference controls at run-time into ongoing workflow instances. Following the FlexCom approach, the prototype requires two parts: firstly, reference controls, including the definition of situations in the workflow instance (status of integration parameters) where an integration of a control process becomes necessary, have to be modeled, e.g., by a compliance officer. Secondly, the execution engine of a workflow management system needs to be extended to automatically perform the modeled actions and integrate the modeled reference controls. Therefore, we extend the Aristaflow BPM Platform (for more details see, e.g., Dadam et al. (2009) and http://www.aristaflow.com): on the client side, the Process Template Editor is extended for modeling reference controls. On the server side, the LogManager is extended for intercepting execution events (see Fig. 2, where white/blue fields are the original components of AristaFlow, grey/yellow fields are the extensions characterizing KitCom).

Fig. 2
figure 2

The two conceptual parts of KitCom

Full size image

To easily follow the working of KitCom, an exemplary workflow is modeled that describes activities if an invoice is received. In a first step, a process designer has to create and develop the workflow in the Process Template Editor as shown in Fig. 3.

Fig. 3
figure 3

Exemplary workflow created with the AristaFlow process template editor

Full size image

Due to compliance requirements, all orders above 5,000€ which are captured by user “Meyer13” must be checked. Thus, in a second step, a compliance officer has to define a corresponding reference control. In this simplified example, only one control activity is defined: an accounts clerk has to compare the invoice amount with the condition of the contract (see Fig. 4). Since the AristaFlow Process Template Editor is implemented using Eclipse RCP, it can be easily extended with additional plug-ins (Reference Control Editor, Control Process Repository, Control Parameter). Therefore, a separate view in the AristaFlow Process Template Editor was created.

Fig. 4
figure 4

Exemplary reference control modeled with KitCom

Full size image

Subsequently, the definitions of the control parameters have to be specified in the extended Process Template Editor (see Fig. 5).

Fig. 5
figure 5

Control parameter specification in KitCom

Full size image

When all three elements are specified (Figs. 3, 4, and 5) and the reference control with its integration parameters is validated, that is, confirming that compliance is enforced, as required by the compliance officer, the workflow can be executed in a compliant manner throughout its execution. To enforce the integration of the control process, all events regarding the execution and adaptations of an ongoing workflow instance are monitored by KitCom. Therefore, all events within the AristaFlow Platform are monitored, i.e., start of a new workflow instance, finishing a workflow step, etc. All these events are centrally logged in the Execution History using the inbuilt Log Manager Service of the platform. The Execution History is updated synchronously and the Log Manager Service is extensible. Therefore, the execution/server side was chosen as an ideal place for integrating the extending elements of KitCom. The information of execution events in the extended Log Manager is used for identifying relevant reference controls. If the requirement of a control is detected, the execution of the workflow instance is suspended. Using the API for ad hoc-deviations (Rinderle, 2004), the control process is integrated into the workflow instance. Figure 6 shows an overview of the architecture of our KitCom prototype (light grey fields are the original components of AristaFlow, dark grey fields are the extensions characterizing KitCom). After the integration of the control process or, rather, the corresponding control activities, the execution of the workflow instance is resumed.

Fig. 6
figure 6

KitCom architecture extending AristaFlow BPM server

Full size image

Resuming the simplified exemplary workflow from above, a new instance of a workflow for paying out an invoice is started. The instance is started as a “pure” business process without any control at the beginning (see Fig. 7).

Fig. 7
figure 7

Usual workflow execution with the software AristaFlow

Full size image

Secondly, if the user “Meyer13” captures an invoice with an amount over 5,000€, the reference control will automatically be integrated as a sub-process called “control” shown in Fig. 8, following the definition of reference controls and control parameters (Figs. 4 and 5).

Fig. 8
figure 8

Automatic integration of the reference control into the workflow instance by KitCom

Full size image

While only one demonstration example is shown in this chapter, a lot of other information can be integrated with KitCom. Known approaches on business process compliance provide several criteria for modeling controls, such as the COMPAS project (Compas, 2008) which identifies generic criteria on the basis of a comprehensive compliance legislation review. Other authors, such as Sadiq et al. (2007), Goedertier and Vanthienen (2006), or Pitthan and Philipp (1997) identify generic criteria, too. As aggregated in Kittel et al. (2013a), all these control parameters can be defined as control parameters in KitCom.

Although the underlying control model of the approach presented is very general and obviously requires a more detailed analysis, the prototype has the general functionality for integrating control activities into workflows during execution, satisfying both the need for flexibility by ad-hoc changes of processes-schemes and the compliance with policy rules through dynamic integration of required reference controls.

5 Discussion and Conclusion

For many companies, remaining competitive means remaining flexible, i.e., rapidly, effectively, and efficiently adapting their business processes to changing demands from markets, customers’ individual needs, requirements of business networks, or changing laws. Current technological progress and the ongoing trends to analyze business data quasi in real-time will, in the near future, allow direct reactions to the actual context, e.g., by adapting ongoing business processes “on the fly”. Such flexibility, however, is challenging the ability to control workflow execution in an efficient and effective manner. In particular, validating compliance with regard to relevant laws, regulations, or contracts becomes difficult in the light of high flexibility and the methods and tools that are available today are not able to provide both flexibility and compliance at the same time. Research for finding solutions in this area, thus, is expected to drive innovation in BPM further. Compliance management becomes a necessary companion to other current BPM-relevant issues that mainly address the “business view”, e.g., process design, intra-organizational business processes, integrating emerging technologies or social media, real-time adaptation to changing workflows to execution context, advanced process analytics results, or management decisions, etc.

Addressing this research gap, we presented a novel approach called FlexCom in this contribution. FlexCom aims at solving this practical trade-off between achieving compliance and remaining flexible within process execution in a systematic and automated manner. To achieve both aims, FlexCom enables companies on the level of single workflow instances to react to process changes from the business side with an automatic process adaptation from the compliance side.

While the functioning of the approach and the prototypical implementation called KitCom were only shown with one simple demonstration example in this contribution, KitCom is a promising application for integrating any kind of control activities into workflows during execution. In principal, the tool is independent of the implementation of a Workflow Client since it is integrated directly into the process engine. The screenshots show the AristaFlow Workflow Client. However, the prototype implementation also works for any custom Workflow Client implementation. Thus, KitCom is seen as a promising next step in automating compliance, that is, an aide to reacting in an automatic manner—if business processes need to remain flexible.

Although there are many open research questions, in particular in the field of how efficiently and effectively reference controls can be modelled and how an economically optimal integration point for control processes can be evaluated, it can already be shown for at least a small set of compliance requirements that it is possible on the level of workflow instances to combine the advantages of ex ante validation and flexible enforcement.

Last but not least, current research suggests that the FlexCom approach is not only valid for compliance but also offers new opportunities for other domains to use WfMS that are dependent on flexibility and on achieving multiple goals, e.g., from the health-sector or the field of disaster response management. Exploiting these opportunities provided by BPM in the long run can be expected to drive innovation further in our digital world.