Detecting temporal workarounds in business processes – A deep-learning-based method for analysing event log data

ABSTRACT

Business process management distinguishes the actual “as-is” and a prescribed “to-be” state of a process. In practice, many different causes trigger a process’s drifting away from its to-be state. For instance, employees may “workaround” the proposed systems to increase their effectiveness or efficiency in day-to-day work. So far, ethnography or critical incident techniques are used to identify how and why workarounds emerge. We design a deep-learning-based method that helps detect different workaround types in event logs. Our method tracks indications of potential workarounds in the early stages of their emergence among deviating behaviour. Our evaluation based on four real-life event logs reveals that our method performs well and works best for business processes with fewer variations and a higher number of different activities. The proposed method is one of the first information technology artefacts to bridge the boundaries between the complementing research disciplines of organisational routines and business processes management.

KEYWORDS:

• Workaround
• business process
• deep learning
• process mining
• routines

1. Introduction

Aligning information systems and business processes is challenging because processes frequently change, for example, by adopting new digital technologies (Beerepoot & van de Weerd, 2018). Previous research has focused on investigating alignment in the implementation phase of information systems (Ignatiadis & Nandhakumar, 2009). However, considering the post-implementation phase is equally important, as employees frequently deviate from predefined business processes and organisational routines, thus adapting their day-to-day work over time. One type of behaviour that often occurs in organisations to overcome, bypass, or minimise the impact of obstacles or structural constraints are workarounds (Alter, 2015). They are “adaptions of work activities that are not expected or specified to be changed in this manner” (Laumer et al., 2017, p. 335), and they play an important role in almost all organisations (Alter, 2015; Röder et al., 2015b). For instance, nurses spend approximately 12% of their time overcoming operational failures and constraints (Tucker et al., 2014).

Even though workarounds can disrupt a business process’s efficiency and quality, they can also trigger innovation. Disruptions may manifest themselves as cumbersome (Alter, 2015) and inefficient processes that deviate from standard operating procedures (Röder et al., 2014). If workarounds remain undetected, they may become unofficially institutionalised in an organisation and may be difficult to change (Tucker et al., 2014). As a positive deviation, workarounds can lead to performance improvements (Röder et al., 2014) and thus provide profound opportunities to analyse and redesign a business process (Alter, 2015; Beerepoot et al., 2019).

Workarounds are complex phenomena that prime employees’ activities in business processes – and the closely related concept of organisational routines (Beverungen, 2014). Understanding workarounds and their effect on business processes and information systems might enable organisations to innovate their processes to establish and maintain a competitive advantage. Previous research has focused on categorising workarounds and explaining how and why employees perform workarounds (Röder et al., 2015b). Workarounds are often detected using qualitative empirical approaches, such as semi-structured interviews, direct observations, or document analysis (Beerepoot et al., 2018). Even though these methods can provide empirical evidence regarding the identification and emergence of workarounds, they presuppose that informants are aware of their workarounds and are willing to expose their deviation from standard business processes (Beerepoot et al., 2018), such that they are limited to identify a subset of all workarounds. Moreover, manual detection methods appear to be excessively labour-intensive and do not allow for large-scale identification of workarounds.

In digitised business processes, workarounds leave data traces in event logs that can be automatically identified and analysed. In business process management (BPM), a plethora of methods have been developed to, more generally, detect anomalies (e.g. Nolle et al. (2018), Nolle et al. (2019), and Pauwels and Calders (2019)) or deviations (e.g. Lu et al. (2016), Cuzzocrea et al. (2016), and Folino et al. (2020)) in business processes. However, even though workarounds, anomalies and deviations are related, they differ conceptually – i.e., in terms of subject, scope and effect – such that existing process mining (PM) methods cannot effectively detect them in event log data (Outmazgin, 2012). Nevertheless, initial research indicates that PM, particularly conformance checking or compliance checking (i.e. a rule-driven derivative of conformance checking (Dunzer et al., 2019; Ramezani et al., 2012)) may be suitable for detecting workarounds (Beerepoot et al., 2021; Beerepoot & van de Weerd, 2018; Outmazgin & Soffer, 2013, 2016), but shows limitations because these methods require either a “to-be” process model or use static rules. We set out to design a new method for automatically detecting potential workarounds that helps in the analysis of real-life event log data. For this purpose, we apply deep neural network (DNN) models with multiple levels of representation to detect workaround patterns in high-dimensional data (LeCun et al., 2015).

The contribution of this paper is twofold. First, following the design science research (DSR) paradigm as outlined by Hevner et al. (2004) and Gregor and Hevner (2013), we design a method that relies on deep learning (DL), enabling researchers and practitioners to detect and analyse workarounds automatically in a digitised business process. This method is a novel data analysis application that facilitates the innovation, exploration, and exploitation of business processes through workarounds. Second, by applying a BPM approach to identify workarounds in organisations, we contribute to spanning the boundaries between the two research streams of organisational routines and PM.¹

The remainder of this paper is organised as follows. In Section 2, we present related research on workarounds and PM. In Section 3, we describe and justify our research method. In Section 4, we present the proposed method for identifying workarounds from event logs. In Section 5, we describe the evaluation of our method by analysing four public data sets. Subsequently, in Section 6, we present the results of the evaluation. While Section 7 discusses our method’s results, managerial implications, related work and limitations, Section 8 concludes the paper.

2. Theoretical background

2.1. Conceptual foundations of detecting workarounds

The concept of workarounds emerged in information systems (IS) research in the mid-1980s to describe the apparent mismatch between work requirements and design (Gasser, 1986). Workarounds are omnipresent in organisations and frequently occur when employees use digital technology for their day-to-day work (Röder et al., 2015b). Workarounds represent unexpected employee behaviour (Ejnefjäll & Ågerfalk, 2019) and manifest as “deviations from defined business processes that are carried out in the employees’ performances of routines in a work system” (Wolf & Beverungen, 2019, p. 1). Research about workarounds can be organised into literature that examines “why” workarounds are performed and “how” this happens.

Regarding “why” workarounds occur, the main rationale is to bypass misfits, do troubleshooting, avoid rules or limitations, mitigate poor information system design, or simply to cut time (Röder et al., 2016). Hence, employees perform workarounds to achieve specific organisational or individual goals (Ejnefjäll & Ågerfalk, 2019). Related research regarding “how” workarounds are performed points out that they are temporary deviations enacted by individuals (Azad & King, 2012). Occasionally, workarounds have been found to become a part of an employee’s daily routines, even if they conflict with established rules (Azad & King, 2012). As they become institutionalised over time, workarounds can unofficially spread across employees’ routines and affect the day-to-day work of other employees in an organisation (Röder et al., 2016; Wolf & Beverungen, 2019). Hence, it is essential to identify and resolve the root causes behind workarounds so that the corresponding business processes may be continuously understood, improved, adapted, or redesigned (Röder et al., 2015b).

Workarounds are performed to change information technology (IT) artefacts or business processes (Wolf & Beverungen, 2019; Zainuddin & Staples, 2016) (Figure 1). Regarding a deviant use of IT artefacts (Azad & King, 2012; Ignatiadis & Nandhakumar, 2009), workarounds are invoked through humans using an artefact in a manner that is inconsistent with the artefact’s original purpose (Azad & King, 2012). Through a workaround, employees attempt to adapt an IT artefact to their needs, compensating for its perceived deficiencies or offsetting their ignorance of system features (Boudreau & Robey, 2005). Even though deviance in using an IT artefact may conflict with the spirit of the artefact’s feature set (DeSanctis & Poole, 1994), it may also be a viable form of enacting it (Azad & King, 2012). Workarounds directed towards an IT artefact may be expressed by a violation of one’s responsibilities if they contradict pre-defined roles (Alter, 2014; Ignatiadis & Nandhakumar, 2009; Outmazgin, 2012; Zainuddin & Staples, 2016) or become apparent by generating manipulated data (Alter, 2015; Ignatiadis & Nandhakumar, 2009; Outmazgin & Soffer, 2013; Zainuddin & Staples, 2016). Regarding business processes, employees may apply workarounds to overcome dysfunctional or ill-defined standard operating procedures to complete tasks they deem essential for their day-to-day work (Outmazgin, 2012). Here, workarounds manifest themselves in handling exceptions, addressing grey spaces, or deviating from routines, processes, or methods (Alter, 2014). Employees may repeat activities (Alter, 2014), substitute activities (Alter, 2015; Laumer et al., 2017), interchange steps in a sequence of activities (Zainuddin & Staples, 2016), bypass activities (Alter, 2014; Outmazgin & Soffer, 2013, 2016; Röder et al., 2014), or add activities to a business process (Alter, 2015; Koopman & Hoffman, 2003; Laumer et al., 2017).

Workarounds can impact a business process in different ways, i.e., a process might continue with the most frequent path, an alternative path, or branch into a new path, leading to process drift (Pentland et al., 2020). If they remain undetected, workarounds may cause negative effects, such as a loss of control (Lapointe & Rivard, 2005), compliance issues (Da Cunha & Carugati, 2009) or inferior process quality (Boudreau & Robey, 2005). However, recent research emphasises that workarounds can also be a source of innovation, as they may remedy misfits and inefficiencies between IT artefacts and business processes (Wolf & Beverungen, 2019). For example, workarounds have been argued to be a vital element in software engineering (Safadi & Faraj, 2010). Workarounds may diffuse through an organisation if they affect the work of other employees (Leonardi, 2011; Pentland et al., 2017; Wolf & Beverungen, 2019); their diffusion amplifies their potential to affect organisations (positively or negatively). In any case, it is important to discover workarounds early so that the necessary actions may be taken (Outmazgin & Soffer, 2013), preventing undesirable consequences and promoting process innovation. Thus, detecting workarounds can result in multiple consequences, including process redesign, system improvement, employee training, or disciplinary actions (Outmazgin & Soffer, 2013).

Figure 1. Taxonomy of workarounds.

Workarounds are subject to temporality (Alter, 2014), establishing a kind of life-cycle. Workarounds may occur temporarily as an adaptation to a business process performed by an individual employee (Grisold et al., 2020). Over time, they can be routinised and might eventually stabilise as an established practice, transforming a business process’s nature. This life-cycle can span from months to years and might vary in its scope (Alter, 2014).

Subject to this life-cycle, PM seems suitable to detect workarounds in some stages but not in others. In the first phase of improvisation (Figure 2), a workaround will manifest as a temporal change from a standard process. In the second phase of dynamic change, a workaround will be one variant that co-exists with a standard process and other variants, making it difficult to trace which variant is either standard or a deviation. If a workaround reaches the third stage and becomes the “new normal”, other variants – including the process constituting the old standard – will appear as retrograde deviations from the “new normal”. Since the nature of a workaround changes over time, we posit that methods for detecting workarounds can be used to identify innovative changes as well as old habits in performing a business process, while their detection might come with conceptual challenges in periods of dynamic change.

Figure 2. Temporality of workarounds (adapted from Alter (2014)).

2.2. Process mining for detecting workarounds

PM is a prevalent process analysis method in BPM that involves the data-driven discovery, monitoring, and enhancement of processes (van der Aalst et al., 2011). However, even though detecting deviant or non-compliant behaviour in event log data has gained considerable attention, only Outmazgin and Soffer (2016) and Beerepoot et al. (2021) have addressed the automated detection of workarounds in event log data.

Besides workarounds, the concepts of anomaly and deviation seem similar at first glance but differ conceptually from workarounds in terms of their subject, scope, and effect, as shown in Table 1.

Table 1. Conceptual difference of workarounds from anomalies and deviations.

	Workaround	Anomaly	Deviation
Subject	Humans’ intention	(Un-)intentional human/machine error
Scope	Life-cycle with different phases	No life-cycle
Effect	Positive/negative	Negative	Positive/negative

Workarounds have a strong human focus, which manifests intentionally in the behaviour of persons (Beerepoot et al., 2021) as goal-directed, flexible, and individually constructed work patterns to remedy misfits (Alter, 2014; Ejnefjäll & Ågerfalk, 2019; Röder et al., 2014). In contrast, anomalies and deviations refer to specific patterns that may be caused by dysfunctional machine actions that are primarily unintentional (Breuker et al., 2016; Chandola et al., 2009; Guo et al., 2019; Pimentel et al., 2014). Workarounds pass multiple learning and diffusion phases that can be concatenated to a life-cycle (Safadi & Faraj, 2010). Thereby, workarounds are interconnected with goals, activities, obstacles, and opportunities in every phase (Alter, 2014). In the beginning, workarounds may occasionally occur due to obstacles or be triggered by shocks. Through learning mechanisms of actors, workarounds can establish in routines and improve business processes. These properties set workarounds apart from deviations, anomalies, and non-compliant behaviour (Malaurent & Karanasios, 2020), all of which represent dysfunctional states that require corrective intervention. While workarounds and deviations can have positive or negative effects, anomalies are negative since they refer to non-compliance with general rules, methods, specifications, or results. As humans perform workarounds, the actual performance of workarounds is dependent on employees’ cognition and decisions. Hence, the spectrum and degree of deviance from business processes are much broader through the performance of workarounds, highlighting that workarounds are more complex and have a different scope compared to the other concepts. Since anomalies and deviations are generally not subject to temporality, they manifest as deviation patterns, which can be identified by analysing event logs. In contrast, workarounds are subject to a life-cycle that shifts the roles of standard processes and workarounds over time, provided that a workaround diffuses through an organisation. As an early paper to investigate the role of PM in workaround detection, we focus on workarounds’ first life-cycle phase.

To detect workarounds, Outmazgin and Soffer (2016) develop a backward compliance checking method that uses six static rules; specifically, they propose one rule per workaround type. Nevertheless, this method is ineffective in detecting workarounds in (sequential) event log data because the rules are static, and workarounds belonging to a specific type can vary considerably (Bishop, 2006). For example, an employee may bypass not only a single step but ten or even more process steps when performing a business process; this highlights the need to detect workarounds that are highly flexible patterns. Beerepoot et al. (2021) apply a multi-perspective conformance checking method requiring a “to-be” process model to detect workarounds in event log data. The authors differ between 51 workarounds, identified by observations and interviews with healthcare professionals in previous research. By applying their method, the authors detect eight of the 51 workarounds in event log data. As this approach checks the conformance of process instances in terms of control-flow, resource, time and data, concrete workaround patterns are not considered in the conformance check.

To detect anomalies, it is a common approach to apply conformance or compliance checking. To detect anomalies without a static process model or rules, that is, with higher flexibility, current research has proposed using neural networks, such as autoencoders (AEs) (Nolle et al., 2018) and recurrent neural networks (Nolle et al., 2019), or dynamic Bayesian networks (Pauwels & Calders, 2019), to determine whether a finished process instance includes an anomaly or not. Beyond binary classification, for example, Nolle et al. (2019) use static rules to classify each process instance by a concrete anomaly type. Besides anomaly detection, a different research stream performs outlier detection. An outlier is conceptually similar to an anomaly, and the detection is based on classification and clustering techniques (Ghionna et al., 2008). Sub-types of anomalies are exceptions (abnormal or unusual execution but can be supported by business), noise (possibly caused by system failure or error in data input), or fraud (unusual executions that lead to undesirable results from a business point of view) (Bezerra et al., 2009). Depending on the conceptual properties of anomalies and workarounds, the underlying patterns differ from each other. Therefore, anomaly detection approaches seem only partially applicable for workaround detection.

In deviation detection, it is common to detect deviations on the process-instance-level or rely on a normative process model to locate deviating behaviour on the event-level. Since a process model cannot be available and the discovery from actual behaviour results in inaccurate diagnostics, methods (e.g. Lu et al. (2016), Cuzzocrea et al. (2016), and Folino et al. (2020)) have been designed to detect deviations on event-level without discovering any normative model. However, since these approaches only differentiate normal and deviating behaviour, they cannot detect workaround patterns.

3. Research method

To organise the development of our IT artefact, we follow the DSR IS research paradigm outlined by Hevner et al. (2004) and Gregor and Hevner (2013). More specifically, our research process is led by the seven DSR guidelines outlined by Hevner et al. (2004), and the structure of our paper follows the publication schema proposed by Gregor and Hevner (2013).

As DSR is inherently a problem-solving process, we review the first step of descriptive and prescriptive knowledge in the area of interest (Hevner et al., 2004) and recognise that IS research lacks an automatic method for workaround detection. Consequently, as our research’s objective, we define the design of a DL-based method for detecting and classifying different types of workarounds in digitised business processes. Further, we identify seven types of workarounds from literature and examine existing workaround and related anomaly and deviation detection approaches in PM. Subsequently, we proceed with the design phase, in which we develop a workaround detection method that serves to detect all seven types of workarounds in an event log. After the instantiation, we evaluate the method in three regards. First, we apply our method to four public data sets – supplied for the business process intelligence (BPI) challenges 2012 (van Dongen, 2012), 2013 (Steeman, 2013), 2019 (van Dongen, 2019), and 2020 (van Dongen, 2020) – to quantitatively evaluate its detection quality. Second, we demonstrate our method based on the event log from the BPI challenge 2020 to evaluate its usefulness in an argumentative way. Third, we perform five expert interviews to evaluate our method’s usefulness in a naturalistic way. Through our evaluation, we justify our method’s ability to solve the previously identified problem of an automated workaround detection (Hevner et al., 2004). Finally, we offer prescriptive design knowledge regarding methods for workaround detection in event logs by presenting our results in this article.

4. Deep learning for detecting workarounds in event logs

We design a DL-based workaround detection method that comprises five phases (Figure 3). For each process instance of a real-life event log, the method detects if a workaround of a particular type is present.

Figure 3. Five phases of the DL-based workaround detection method.

Initially, a vector-oriented data set, which is based on an event log, is generated to apply DNNs. In the second phase, noisy data (e.g. a workaround type and/or conspicuities such as simple typing errors caused by inattentive process participants) are removed from the data set using an AE, a specific type of DNN. In this phase, the noisy process instances removed from the data are compensated for process instances randomly selected from the remaining non-noisy data. In the third phase, workaround variations from a predefined set of workaround types are randomly added to the existing process instances in the data set. In the next phase, a classifier is learned using a convolutional neural network (CNN). The classifier maps a process instance to a workaround class. Finally, the learned classifier is applied to a left-out subset of the initial data set, in which noisy data have not been removed. Before we present, explain, and justify each phase of the proposed method, we introduce a set of preliminaries.

4.1. Preliminaries

The DL algorithms in the proposed method process data, which can be structured into vectors, matrices, and tensors. Thus, we first define these data structures.

Definition 4.1 (Vector). A vector $\mathbf{x}=(x_1,x_2,\dots ,x_v)$ is an array of numbers, in which the $i$^th number is identified by $\mathbf{x}[i]$. If each number in vector $\mathbf{x}$ lies in $\mathbb{R}$, and the vector $\mathbf{x}$ contains $v$ numbers, then $\mathbf{x}$ lies in ${\mathbb{R}}^v$, and its dimension is $v$.

Definition 4.2 (Matrix). A matrix $\mathbf{M}=({\mathbf{x}}_1,{\mathbf{x}}_2,\dots ,{\mathbf{x}}_b{)}^T$ is a two-dimensional array of numbers, where $\mathbf{M}\in {\mathbb{R}}^{b\times v}.$ We denote the $i$^th row of a matrix by $\mathbf{M}[i,:],$ and the $j$^th column by $\mathbf{M}[:,j].$

Definition 4.3 (Tensor). A tensor $\mathrm{T}$ is an $n$-dimensional array of numbers. If $n=3$, $\mathrm{T}$ is a tensor of the third order with $\mathrm{T}=\left({\mathbf{M}}_1,{\mathbf{M}}_2,\dots ,{\mathbf{M}}_b\right)$, where $\mathrm{T}\in {\mathbb{R}}^{b\times q\times z}$. We denote the $i$^th matrix by $\mathrm{T}[i,:,:].$

Further, the proposed PM method identifies workarounds in event log data. An event log is structured into traces, which are in turn structured into events. Thus, based on Polato et al. (2014), we define the terms event universe, event, trace, and event log as follows:

Definition 4.4 (Event universe). $\mathcal{E}=\mathcal{A}\times C\times \mathcal{T}\times \mathcal{U}$ is the event universe in which:

• $\mathcal{A}$ is the set of process activities,

• $\mathcal{C}$ is the set of process instances (cases),

• $C$ is the set of case IDs with the bijective projection $f_{id}:C\to \mathcal{C}$,

• $\mathcal{T}$ is the set of timestamps, and

• $\mathcal{U}$ is the set of data attributes.

Definition 4.5 (Event). An event $e\in \mathcal{E}$ is a tuple $e=(a,c,t,U)$, where $a\in \mathcal{A}$ is the process activity, $c\in C$ is the case ID, $t\in \mathcal{T}$ is its starting timestamp, and $U\in \mathcal{U}$ are the data attributes. Given an event $e$, we define the projection functions $F_p=\{f_a,f_c,f_t,f_U\}$: $f_a:e\to a,f_c:e\to c$, $f_t:e\to t$, and $f_U:e\to U$.

Definition 4.6 (Trace). A trace is a non-empty sequence ${\sigma }_c=⟨e_1^{(c)},\dots ,e_{|{\sigma }_c|}^{(c)}⟩\in {\mathcal{E}}^{\ast }$ of events such that $f_c(e_i)=f_c(e_j)\wedge f_t(e_i)\le f_t(e_j)$ for $1\le i<j\le |{\sigma }_c|$. A trace can also be considered a sequence of vectors, in which a vector contains all or part of the information relating to an event (e.g., the activity of an event). Formally, $\sigma =⟨{\mathbf{x}}_1,\dots ,{\mathbf{x}}_{|\sigma |}⟩,$ where ${\mathbf{x}}_i\in {\mathbb{R}}^n$ is a vector, and the index denotes the time-ordering of the vectors.

Definition 4.7 (Event log). An event log ${\mathcal{L}}^{(\tau )}$ for time instant $\tau$ is the set of traces such that $\mathrm{\forall }{\sigma }_c\in {\mathcal{L}}^{(\tau )}$, there exists $c\in \mathcal{C}$ so that $\mathrm{\forall }e\in {\sigma }_c$, we have $f_{id}(f_c(e))=c$ and $f_t(e)\le \tau$ (i.e., all events of the observed cases that have already happened).²

Finally, the proposed method uses a labelled data set for training. Thus, we define the term label.

Definition 4.8 (Label). Given a trace $\sigma =⟨e_1,\dots ,\dots ,e_{|\sigma |}⟩$, we can define its label as $f_l(\sigma )=l_{\sigma }$. In this paper, the label reflects a set of workaround classes.

4.2. Setting up an initial data set

The first phase of the method transforms the data representation of the event log and generates an initial data set that is to be used by DNNs. Thereby, we follow a well-established generation process consisting of three steps as in the work of Weinzierl et al. (2020)): load the event log, transform the event log into a data set, and encode the data attributes of the data set.

In the first step, an event log $\mathcal{L}$ is loaded. Subsequently, a trace ${\sigma }_i$ of $\mathcal{L}$ can be expressed as:

(1) $\begin{array}{cc}{\sigma }_i=& ⟨⟨e_1^{(i)}⟩,⟨e_2^{(i)}⟩,⟨\dots ⟩,⟨e_n^{(i)}⟩,\end{array}$(1)

where $1\le i\le |\mathcal{L}|$. Such a trace contains all information about its events. However, for detecting workarounds, information about the activity and the data attributes is sufficient. Thus, we apply to the events of each trace of $\mathcal{L}$ the projection functions $f_a(\cdot )$ and $f_D(\cdot )$ to retrieve the activity and additional data attributes. Thereby, we retain the temporal order of the events in each trace. After these functions have been applied, a trace ${\sigma }_i$ of the event log $\mathcal{L}$ can be expressed as:

(2) $\begin{array}{cc}{\sigma }_i=& ⟨⟨a_0^{(i)},u_{0,1}^{(i)},\dots ,u_{0,m}^{(i)}⟩,⟨a_1^{(i)},u_{1,1}^{(i)},\dots ,u_{1,m}^{(i)}⟩,⟨\dots ⟩,\\ \hspace{0.17em}& ⟨\dots ⟩⟨a_n^{(i)},u_{n,1}^{(i)},\dots ,u_{n,m}^{(i)}⟩⟩,\end{array}$(2)

with $1\le i\le |\mathcal{L}|$. In Equation (2)(2) $\begin{array}{cc}{\sigma }_i=& ⟨⟨a_0^{(i)},u_{0,1}^{(i)},\dots ,u_{0,m}^{(i)}⟩,⟨a_1^{(i)},u_{1,1}^{(i)},\dots ,u_{1,m}^{(i)}⟩,⟨\dots ⟩,\\ \hspace{0.17em}& ⟨\dots ⟩⟨a_n^{(i)},u_{n,1}^{(i)},\dots ,u_{n,m}^{(i)}⟩⟩,\end{array}$(2) , $a_j^{(i)}$ ($1\le j\le n$) represents the activity of the $j$^th event of trace ${\sigma }_i$, and $u_{j,m}^{(i)}$ is the $m$^th data attribute associated with the $j$^th event. Typically, the number of data attributes associated with an event, and the number of events per process instance vary. In addition, we assume that the events have an explicit reference to a process instance; this assumption is often made in PM, and it has been reported to be typically satisfied in real-world event logs (van der Aalst, 2016). Subsequently, we use the event log ${\mathcal{L}}_1=\{{\sigma }_1,{\sigma }_2,{\sigma }_3,{\sigma }_4\}$, as shown in Equation (3)(3) $\begin{array}{rl}& {\mathcal{L}}_1=\{\\ & ⟨⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{P}\mathrm{O}{ }^{"},{ }^{"}\mathrm{H}\mathrm{u}{ }^{"},{ }^{"}\mathrm{P}\mathrm{O}{ }^{"}⟩,⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"},{ }^{"}\mathrm{A}\mathrm{n}{ }^{"},{ }^{"}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"}⟩,\\ & ⟨{ }^{"}\mathrm{P}\mathrm{a}\mathrm{y}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{P}\mathrm{D}{ }^{"}⟩⟩,\\ & ⟨⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{P}\mathrm{O}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{O}\mathrm{r}\mathrm{d}\mathrm{e}\mathrm{r}{ }^{"}⟩,⟨{ }^{"}\mathrm{P}\mathrm{a}\mathrm{y}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{P}\mathrm{D}{ }^{"}⟩⟩,\\ & ⟨⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{P}\mathrm{O}{ }^{"},{ }^{"}\mathrm{H}\mathrm{u}{ }^{"},{ }^{"}\mathrm{P}\mathrm{O}{ }^{"}⟩,⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"},{ }^{"}\mathrm{Y}\mathrm{i}{ }^{"},{ }^{"}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"}⟩,\\ & ⟨{ }^{"}\mathrm{P}\mathrm{a}\mathrm{y}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{P}\mathrm{D}{ }^{"}⟩⟩,\\ & ⟨⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{P}\mathrm{O}{ }^{"},{ }^{"}\mathrm{H}\mathrm{u}{ }^{"},{ }^{"}\mathrm{P}\mathrm{O}{ }^{"}⟩,⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"},{ }^{"}\mathrm{A}\mathrm{n}{ }^{"},{ }^{"}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"}⟩,\\ & ⟨{ }^{"}\mathrm{P}\mathrm{a}\mathrm{y}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{P}\mathrm{D}{ }^{"}⟩⟩\\ & \}.\end{array}$(3) , as an example to demonstrate our artefact.

(3) $\begin{array}{rl}& {\mathcal{L}}_1=\{\\ & ⟨⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{P}\mathrm{O}{ }^{"},{ }^{"}\mathrm{H}\mathrm{u}{ }^{"},{ }^{"}\mathrm{P}\mathrm{O}{ }^{"}⟩,⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"},{ }^{"}\mathrm{A}\mathrm{n}{ }^{"},{ }^{"}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"}⟩,\\ & ⟨{ }^{"}\mathrm{P}\mathrm{a}\mathrm{y}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{P}\mathrm{D}{ }^{"}⟩⟩,\\ & ⟨⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{P}\mathrm{O}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{O}\mathrm{r}\mathrm{d}\mathrm{e}\mathrm{r}{ }^{"}⟩,⟨{ }^{"}\mathrm{P}\mathrm{a}\mathrm{y}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{P}\mathrm{D}{ }^{"}⟩⟩,\\ & ⟨⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{P}\mathrm{O}{ }^{"},{ }^{"}\mathrm{H}\mathrm{u}{ }^{"},{ }^{"}\mathrm{P}\mathrm{O}{ }^{"}⟩,⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"},{ }^{"}\mathrm{Y}\mathrm{i}{ }^{"},{ }^{"}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"}⟩,\\ & ⟨{ }^{"}\mathrm{P}\mathrm{a}\mathrm{y}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{P}\mathrm{D}{ }^{"}⟩⟩,\\ & ⟨⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{P}\mathrm{O}{ }^{"},{ }^{"}\mathrm{H}\mathrm{u}{ }^{"},{ }^{"}\mathrm{P}\mathrm{O}{ }^{"}⟩,⟨{ }^{"}\mathrm{C}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"},{ }^{"}\mathrm{A}\mathrm{n}{ }^{"},{ }^{"}\mathrm{I}\mathrm{n}\mathrm{v}.{ }^{"}⟩,\\ & ⟨{ }^{"}\mathrm{P}\mathrm{a}\mathrm{y}{ }^{"},{ }^{"}\mathrm{A}\mathrm{l}{ }^{"},{ }^{"}\mathrm{P}\mathrm{D}{ }^{"}⟩⟩\\ & \}.\end{array}$(3)

In the second step, the event log $\mathcal{L}$ with a log-oriented representation is transformed into a data set $\mathbf{D}\in {\mathbb{R}}^{b\times v}$ with a vector-oriented representation (Weinzierl et al., 2019), where $b$ indicates the number of process instances, and $v$ is the number of attributes. In most cases, event logs are encoded using a log-oriented representation, in the case of the popular XES format (Verbeek et al., 2010). However, the DNNs considered in this paper require a data set with a fixed-size structure as input (LeCun et al., 2015). For example, Table 2 shows ${\mathbf{D}}_1\in {\mathbb{R}}^{4\times 9}$ (obtained from ${\mathcal{L}}_1$) in the form of a two-dimensional data structure, in which each row has the same number of columns.

Table 2. Data set ${\mathbf{D}}_1$ with a fixed-size structure.

$a_0$	$u_{0,0}$	$u_{0,1}$	$a_1$	$u_{1,0}$	$u_{1,1}$	$a_2$	$u_{2,0}$	$u_{2,1}$
“Create PO”	“Hu”	“PO”	“Create Inv.”	“An”	“Inv.”	“Pay”	“Al”	“PD”
“Create PO”	“Al”	“Order”	“Pay”	“Al”	“PD”
“Create PO”	“Hu”	“PO”	“Create Inv.”	“Yi”	“Inv.”	“Pay”	“Al”	“PD”
“Create PO”	“Hu”	“PO”	“Create Inv.”	“An”	“Inv.”	“Pay”	“Al”	“PD”

In the last step of this phase, discrete values of activities and data attributes of the data set are transformed into numeric values. The DNNs used in this work are fully differential and require numerical data to compute forward and backward propagation (LeCun et al., 2015).

We first handle missing values. On the one hand, missing values of the activity attribute and each categorically scaled data attribute are replaced by the global constant “0” (Han et al., 2011). This constant does not affect the results of the DNNs because it differs from the existing values of a categorical attribute. On the other hand, we replace the missing values of each numerically scaled data attribute with the median of existing values (Han et al., 2011). In addition, the median does not affect the result of the DNNs because it represents the “middle” of the distribution of a numerically scaled data attribute. This step is necessary because a DNN, as used here, cannot handle missing values. Further, for each numerically scaled context attribute with a value range that is not equal to $[0,1]$, a min-max normalisation is performed. Then, we apply binary encoding for the activity attribute and for each categorically scaled data attribute. Since attributes in event log data (especially context attributes like the resource) can have many values, a sparse encoding (e.g. one-hot encoding) results in data sets, which cannot be processed efficiently. Table 3 shows the resulting data set ${\mathbf{D}}_1\in {\mathbb{R}}^{4\times 18}$. Each categorical data attribute now has two different values.³

Table 3. Initial data set ${\mathbf{D}}_1$ with a vector-oriented representation.

$a_0$		$u_{0,0}$		$u_{0,1}$		$a_1$		$u_{1,0}$		$u_{1,1}$		$a_2$		$u_{2,0}$		$u_{2,1}$
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1
0	1	1	0	0	1	1	1	1	0	1	1	0	0	0	0	0	0
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1

In the last step, the initial data set $\mathbf{D}$ is divided into two subsets: ${\mathbf{D}}_{train}$ and ${\mathbf{D}}_{detect}$. The data set ${\mathbf{D}}_{train}$ is transferred to the subsequent step of the method, whereas ${\mathbf{D}}_{detect}$ is left out for the last phase, in which workaround classification is performed. Regarding the running example ${\mathbf{D}}_1\in {\mathbb{R}}^{4\times 18}$, we assign its first three process instances to ${\mathbf{D}}_{1,train}$, and the last to ${\mathbf{D}}_{1,detect}$.

4.3. Removing noisy data from the data set

We assume that not only workarounds but also other forms of deviance (such as fraud, sabotage, or interpretive flexibility) of (un-)intentional divergent behaviour may be present in an event log, which we define as “noisy data”.⁴ Thus, in our method, all noisy data (i.e. workarounds and other deviations) are removed using an AE. Then, the removed data are compensated for normal data that are randomly selected from the remaining non-noisy data. This step is necessary to determine an appropriate threshold for noisy data removal through the AE. In the subsequent phase, we generate and reintegrate noisy data that are consistent with workarounds.

In general, a complete AE is a neural network trained to attempt copying its input to its output (Goodfellow et al., 2016). It comprises two components. The first is the encoder function $f_{enc}(\cdot )$, which maps the input $\mathbf{X}$ to an internal representation $\mathbf{h}$. The second is the decoder function $f_{dec}(\cdot )$, which maps the internal representation $\mathbf{h}$ to the reconstruction $\mathbf{R}$.

Given the data set ${\mathbf{D}}_{train}$, the encoder function $f_{enc}(\cdot )$, and the decoder function $f_{dec}(\cdot )$, the reconstruction errors $\mathbf{s}$ as elements of the loss function are minimised during the learning process (Goodfellow et al., 2016). A formalism of the AE’s loss function, which first calculates the reconstruction error of each process instance to subsequently determine the overall normalised reconstruction error (for all process instances), can be found in Appendix A.

After the learning process is completed, the function $f_{out}(\cdot )$, as shown in Equation (4)(4) $f_{out}({\sigma }_i,s_{{\sigma }_i},\theta )=\left\{\begin{array}{cc}{\sigma }_i\in {\mathbf{D}}_{train},& \mathrm{i}\mathrm{f}{s}_{{\sigma }_i}\le \theta ,\\ {\sigma }_i\notin {\mathbf{D}}_{train},& \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}.\end{array}\right.$(4) , is applied to each process instance ${\sigma }_i\in {\mathbf{D}}_{train}$ (with $1\le i\le |{\mathbf{D}}_{train}|$) to identify and remove noisy process instances from ${\mathbf{D}}_{train}$.

(4) $f_{out}({\sigma }_i,s_{{\sigma }_i},\theta )=\left\{\begin{array}{cc}{\sigma }_i\in {\mathbf{D}}_{train},& \mathrm{i}\mathrm{f}{s}_{{\sigma }_i}\le \theta ,\\ {\sigma }_i\notin {\mathbf{D}}_{train},& \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}.\end{array}\right.$(4)

In Equation (4)(4) $f_{out}({\sigma }_i,s_{{\sigma }_i},\theta )=\left\{\begin{array}{cc}{\sigma }_i\in {\mathbf{D}}_{train},& \mathrm{i}\mathrm{f}{s}_{{\sigma }_i}\le \theta ,\\ {\sigma }_i\notin {\mathbf{D}}_{train},& \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}.\end{array}\right.$(4) , $s_{{\sigma }_i}$ is the reconstruction error of the process instance ${\sigma }_i$, whereas $\theta$ is the reconstruction error threshold. As proposed by Borghesi et al. (2019), we select as threshold value the $k$^th percentile of the reconstruction errors (i.e. for all process instances) $\mathbf{s}$ of the data set ${\mathbf{D}}_{train}$. For example, in the case $k=70$, in which the value of the threshold $\theta$ could be equal to $0.005$, 70% of the process instances in the data set have a reconstruction error that is less than or equal to this value. The value of the parameter $k$ can be automatically retrieved through parameter search (e.g. grid or random search) or can be manually set by a domain expert. After applying the function $f_{out}(\cdot )$, the resulting data set ${\mathbf{D}}_{1,train}\in {\mathbb{R}}^{2\times 18}$ is shown in Table 4, where the second process instance is removed because its reconstruction error exceeds the threshold. The reconstruction error of this process instance is higher because the resource “Al” bypassed the activity “Create Inv.”.

Table 4. Data set ${\mathbf{D}}_{1,train}$ without noisy data.

$a_0$		$u_{0,0}$		$u_{0,1}$		$a_1$		$u_{1,0}$		$u_{1,1}$		$a_2$		$u_{2,0}$		$u_{2,1}$
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1

In the last step, the noisy process instances removed from the data set ${\mathbf{D}}_{train}$ are compensated for randomly selected process instances from the same data set. Accordingly, different values of the reconstruction error threshold can be tested with the same data set size for ${\mathbf{D}}_{train}$ and the same number of added workarounds (see next section). Table 5 shows the data set ${\mathbf{D}}_{1,train}\in {\mathbb{R}}^{3\times 18}$, where the third process instance is a copy of the first.

Table 5. Data set ${\mathbf{D}}_{1,train}$ with augmented data.

$a_0$		$u_{0,0}$		$u_{0,1}$		$a_1$		$u_{1,0}$		$u_{1,1}$		$a_2$		$u_{2,0}$		$u_{2,1}$
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1

4.4. Adding workarounds to the data set

In this phase, noisy data related to workarounds are integrated into ${\mathbf{D}}_{train}$. We follow Nolle et al. (2019), Böhmer and Rinderle-Ma (2016), and Bezerra and Wainer (2013), who detect anomalies in event logs, and add noisy data (representing anomalies) to $30$% of the process instances randomly selected from the data set ${\mathbf{D}}_{train}$. Thus, we leave 70% of the process instances unchanged and assign them to the class No workaround (0) that does not represent a workaround type. We integrate a workaround representing one of the seven workaround types into each of the other $30$% of the process instances, and assign each process instance to a class that corresponds to the workaround type. Based on the workaround taxonomy presented in Figure 1 and inspired by Nolle et al. (2019), we define the seven workaround types as shown in Table 6.

Table 6. Technical specification of the seven workaround types.

Id	Type	Description
1	Violated responsibility	Randomly select any other value of a resource attribute.
2	Manipulated data	Randomly select any other value of a data attribute.
3	Repeated activity	Repeat a randomly selected activity (and its context attributes) of a process instance $\sigma$ three up to ten times.
4	Substituted activity	Replace a randomly selected activity of a process instance $\sigma$ by an activity that is not yet included. Given this activity, the values of its context attributes are retrieved from another randomly selected process instance, of which the activity is part.
5	Interchanged activity	Interchange a randomly selected activity (and its context attributes) of a process instance $\sigma$ (except the last one) with its subsequent activity (and its context attributes).
6	Bypassed activity	Skip one or more activities of a process instance $\sigma$, where the start and the bypassed steps are randomly selected.
7	Added activity	Add an activity that is not part of a process instance $\sigma$. Given this randomly selected activity, values of its context attributes are retrieved from another randomly selected process instance, of which the activity is part.

As shown in Table 7, a workaround of the type bypassed activity is integrated into the second process instance of the data set ${\mathbf{D}}_{1,train}\in {\mathbb{R}}^{3\times 18}$. Additionally, the last column of this table represents the label specifying the eight different workaround classes, which is not part of the data set ${\mathbf{D}}_{1,train}$. The first class of the eight workaround classes is No workaround, and the other seven classes refer to the seven workaround types from Table 6.

Table 7. Data set ${\mathbf{D}}_{1,train}$ without noisy data and the label specifying the workaround class.

$a_0$		$u_{0,0}$		$u_{0,1}$		$a_1$		$u_{1,0}$		$u_{1,1}$		$a_2$		$u_{2,0}$		$u_{2,1}$		Workaround
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1	0
0	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	6
0	1	0	1	0	1	1	0	1	1	1	0	1	1	1	0	1	1	0

4.5. Learning a classifier

To learn a classifier represented by a function that maps each process instance of ${\mathbf{D}}_{train}$ to a workaround type, we use a CNN (LeCun, 1989), which is a neural network that includes at least one convolutional layer, consisting of three stages: convolutional, detection, and pooling stage (Goodfellow et al., 2016).

In the first stage, several convolutions are performed in parallel to produce a set of linear activations based on the input, for example, a sequence. A convolution is a filtering operation performed by a feature map. All units in a feature map share the same filter bank, in which the weights for this filter are stored (this principle is called parameter sharing). For each feature map, only one linear activation is calculated by element-wise multiplication of the filter-sized batch of the input and the filter bank, followed by summation. In the second stage, each linear activation is run through a nonlinear activation function. In the third stage, a pooling function is used to merge semantically similar features (LeCun et al., 2015) and to remove irrelevant features.

We opted for a CNN for two reasons. First, a CNN can process input data using a one-dimensional, sequential representation (LeCun et al., 2015); thus, it is suitable for the proposed method because the process instances of the data set ${\mathrm{D}}_{train}$ have such a representation. After reshaping, the matrix ${\mathbf{D}}_{train}\in {\mathbb{R}}^{b\times v}$ can be represented as a third-order tensor ${\mathrm{D}}_{train}\in {\mathbb{R}}^{b\times q\times z}$, where $b$ indicates the number of process instances, $q$ is the number of the time steps of the longest process instance, and $z$ is the number of attributes per time step. Second, a CNN typically provides the capability of sparse interactions by making the kernel (called filter) smaller than the input (Goodfellow et al., 2016). For example, a process instance of ${\mathrm{D}}_{train}$ featuring low-level encoded activities and data attributes may have more than 1,000 elements. However, we can detect specific workaround types that occupy only 10 or 100 of these elements.

4.6. Applying a classifier

In the last phase, the learned CNN model $f_{CNN}(\cdot )$ is applied to the subset ${\mathbf{D}}_{detect}$ of the initial data set $\mathbf{D}$, generated in the first phase. To apply the trained CNN model, the data set ${\mathbf{D}}_{detect}$, represented as a two-dimensional matrix, should be transformed into a third-order tensor ${\mathrm{D}}_{detect}$. Concerning ${\mathrm{D}}_{detect}$, noisy data in the data set remain unchanged. For each process instance ${\sigma }_i\in {\mathbf{D}}_{detect}$, the CNN model returns a classification output in the form of a probability distribution ${\mathbf{o}}_i$, where $1\le i\le |\mathrm{D}[:,0,0{]}_{detect}|$. The most likely workaround type for ${\sigma }_i$ is determined through the function $f_{max}(\cdot )$. For example, for the process instance in the detection set ${\mathrm{D}}_{1,detect}\in {\mathbb{R}}^{1\times 3\times 6}$ (third-order tensor generated from the matrix ${\mathbf{D}}_{1,detect}\in {\mathbb{R}}^{1\times 18}$), shown in Figure 4, the CNN model returns a probability distribution in which the value for the class No workaround (0) has the highest probability value.

Figure 4. Data set ${\mathrm{D}}_{1,detect}$ for workaround detection.

5. Evaluation

5.1. Event logs

We used for the evaluation the following four real-life event logs. The main properties of the event logs are exhibited in Table 8.

Table 8. Characteristics of the event logs used for the evaluation.

Event log	# process instances	# process instance	# events	# activities	# data attributes	Dimension of con. attributes	Instance length [min; max; mean]
		variants
bpi2019	16,060	1,284	78,060	31	3	[290; 3; 2]	[1; 297; 4.86]
bpi2013i	7,554	2,278	65,533	13	3	[1,440; 25; 24]	[2; 123; 8.68]
bpi2012w	9,658	2,263	72,413	6	2	[60; 530]	[1; 74; 7.50]
bpi2020p	7,065	1,262	69,193	48	2	[7; 2]	[3; 56; 9.79]

The bpi2019 (van Dongen, 2019) event log was acquired from a large multinational coating and paints company operating in the Netherlands. The data represent a mass transaction process, more specifically, a purchasing process. As the event log had an original size of 1,595,923 events, we used a sample of the first 80,003 events from activities performed by human actors to make the data set’s size comparable with those supplied in the bpi2013i, bpi2012w, and bpi2020p event logs. For two reasons, we removed process instances that included more than $300$ events (the longest sequence in the original event log is $924$). First, longer sequences could not be efficiently computed with the given resources. Second, longer sequences appeared unrealistic and were considered as exceptions. Finally, we selected the data attributes Event Org:Resource (human actor), Case Document Type, and Case GR-Based Inv. Verif (flag indicating if goods-receipt-based invoicing is required) for our evaluation.

The bpi2013i (Steeman, 2013) event log was supplied by Volvo IT in Belgium and contains data related to incident and problem management processes. More specifically, the Handle Incident Process describes the control flow from the emergence and reporting of a variety of IT-related incidents to their resolution on different service levels. For our evaluation, we used the data of all 7,554 process instances in this event log, comprising 65,533 events. We selected the data attributes Owner First Name (human actor), Involved ST Function Div (functional division of IT organisation), and Involved Org line 3 (business area of the user reporting the problem to help-desk) for the evaluation.

The bpi2012w (van Dongen, 2012) event log contains data from an application process for commercial products of a large financial institution. This process consists of three sub-processes, containing 13,087 instances and 262,200 events in total. For this paper, we considered the work item sub-process because it is the only sub-process in this data set that includes activities performed by humans rather than by machines. To evaluate the detection of different types of workarounds, we also selected the data attributes Org:Resource_Event (human actor) and Amount_Req_Trace (amount of money requested by the customer) for the evaluation. Additionally, we filtered out all events that did not exhibit the type complete, resulting in a data set comprising 9,658 instances and 72,413 events.

The bpi2020p (van Dongen, 2020) event log documents the travel permit process of a Dutch university. More specifically, it describes the process from issuing an application for a travel permit by employees to the applications’ approval by their supervisors to reimbursement handling. In total, the event log contains 7,065 instances and 86,581 events. We used all instantiated processes, but since the bpi2020p event log also contains activities performed by an information system (System), we only selected events for which the attribute Resource exhibited the value Staff Member, leading us to remove 17,388 events, while keeping 69,193 events in the data set. Here, we selected the data attributes org:role (human actor) and (case) overspent for our evaluation.

5.2. Evaluation procedure

For each of the four real-life event logs, a $10$%-subset of the process instances was randomly selected as a hold-out detection set for the last phase of the method. From the other $90$% process instances, noisy data were removed, while normal data were augmented and workarounds were added. Subsequently, as recommended by Haykin (1998) for neural networks, the remaining $90\mathrm{\%}$ of process instances were randomly split into a training set ($80\mathrm{\%}$) and a test set ($20\mathrm{\%}$).

In line with phase two of the proposed method, noisy data were removed from the $90$%-subset of the original event log by using an AE. To better adjust the hyper-parameters of the AE model to the underlying training set during the training procedure, we performed a hyper-parameter optimisation method. Specifically, we selected tree-structured Parzen estimator (TPE), a sequential model-based optimisation approach, which was demonstrated to be more reliable for training DNNs than traditional approaches (e.g. random search) (Bergstra et al., 2011). We ran the TPE method ten times to obtain appropriate values for the hyper-parameters. For each run, the training set was randomly split into a training subset ($90$%) and a validation set ($10$%). After ten runs, the trained model with the lowest mean squared error was selected and then applied to analyse the testing set. Further details on the hyper-parameter configuration of the AE are documented in Appendix B.

In line with phase four of the method, a CNN was used to learn a mapping from the process instances of the training set ${\mathbf{D}}_{train}$ to the workaround labels. As in the previous phase, we applied TPE with ten runs and the same random split to train the CNN. Here, the CNN model with the highest f1-score was selected. Further details on the hyper-parameter configuration of the CNN are provided in Appendix C.

After learning the CNN models in phase four, we tested their detection quality based on the test set. To this end, we used all four states provided by the confusion matrix to present and discuss the detection quality of the four classification models, in which we differentiated between the classes workaround and no workaround. The four states of the confusion matrix included true positives (TPs), true negatives (TNs), false positives (FPs), and false negatives (FNs). Moreover, we calculated the average accuracy, (macro) precision, (macro) recall, and (macro) f1-score of all workaround classes (seven workaround types and the class no workaround). All of these machine learning (ML) metrics are well-established in the PM community and in the IS literature, too (Breuker et al., 2016). In phase five, the trained and tested CNN models were applied to analyse the detection set, which included noisy data.

Finally, we implemented the proposed method using Python 3.6.8; we used the DL framework TensorFlow 2.3.0 (Abadi et al., 2016) to facilitate the process of constructing DL models. We published the source code on GitHub to make our approach transparent and replicable.⁵

6. Results

6.1. Determining a threshold for noisy data removal

To determine the noisy data removal threshold for which the CNN model achieves the highest f1-score, we conducted five experiments for each of the four data sets; one per reconstruction error threshold. We performed a grid search in addition to the TPE hyper-parameter search. To this end, we set the value of the reconstruction error threshold $\theta$ to the ${50}^{\mathrm{t}\mathrm{h}}$, ${60}^{\mathrm{t}\mathrm{h}}$, up to the ${90}^{\mathrm{t}\mathrm{h}}$ percentile of the reconstruction errors $\mathbf{s}$. We did not investigate threshold values lower than the ${50}^{\mathrm{t}\mathrm{h}}$ percentile because these values would have removed an excessive amount of data from our event logs. Further, the case in which the threshold was set to the ${100}^{\mathrm{t}\mathrm{h}}$ percentile is not reported here since we used this setting as the baseline for workaround detection when no process instances were removed by the AE. Figure 5 exhibits the f1-scores for each event log and threshold value.

Figure 5. F1-Score of the CNN for different reconstruction error thresholds and data sets.

For the bpi2020p and bpi2019 event logs, the highest f1-score ($0.823$ and $0.756$) was achieved at the ${70}^{\mathrm{t}\mathrm{h}}$ percentile of reconstruction errors $\mathbf{s}$. The threshold indicates that the AE removed less than half of the process instances from the training sets of the event log. Then, per event log, the removed process instances were compensated for normal process instances that were randomly selected from the remaining training set. In contrast, for bpi2013i and bpi2012w, the highest f1-score ($0.593$ and $0.440$) was achieved at the ${50}^{\mathrm{t}\mathrm{h}}$ percentile of the reconstruction errors $\mathbf{s}$. Hence, the AE clearly removed more process instances from the training sets of the event log than in the case of bpi2020p and bpi2019. Consequently, more process instances were compensated for normal process instances that were randomly selected from the remaining training set.

Further, the identified reconstruction error threshold $\theta$, indicating which process instances were removed or retained, differs for each event log. In the bpi2012w event log, the value of the error threshold $\theta$, representing the ${50}^{\mathrm{t}\mathrm{h}}$ percentile of the reconstruction errors $\mathbf{s}$, is $0.00018$. It was the lowest value across all data sets. In bpi2013i, the error threshold $\theta$, which is also the ${50}^{\mathrm{t}\mathrm{h}}$ percentile of the reconstruction errors $\mathbf{s}$, exhibited the second-lowest value of $0.00051$ among the event logs. Concerning bpi2019, the error threshold value $\theta =0.00054$ was slightly higher than in bpi2013i and significantly higher than in bpi2012w. It represented the ${70}^{\mathrm{t}\mathrm{h}}$ percentile of the reconstruction errors $\mathbf{s}$. Finally, in the bpi2020p event log, the threshold value was $0.00114$, which was the highest among the event logs. Here, the threshold is also the ${70}^{\mathrm{t}\mathrm{h}}$ percentile of the reconstruction errors $\mathbf{s}$.

6.2. Test results for workaround detection

We trained a classifier based on each training set, and these classifiers were subsequently tested using the corresponding test sets. Table 9 presents the quality metrics for each classifier. In the following, we focus on the results obtained using the AE (for noise removal), as they are the best across all data sets and in terms of all metrics.

Table 9. Test results for workaround detection in four data sets.

Event log	AE	Percentile	TPs	TNs	FPs	FNs	Accuracy	Precision	Recall	F1-Score
bpi2019	Yes	${70}^{\mathrm{t}\mathrm{h}}$	379	1,096	36	72	0.903	0.766	0.793	0.756
	No	${100}^{\mathrm{t}\mathrm{h}}$	333	1,091	29	130	0.865	0.687	0.781	0.654
bpi2013i	Yes	${50}^{\mathrm{t}\mathrm{h}}$	275	935	12	138	0.847	0.607	0.661	0.593
	No	${100}^{\mathrm{t}\mathrm{h}}$	167	952	29	212	0.789	0.437	0.559	0.397
bpi2012w	Yes	${50}^{\mathrm{t}\mathrm{h}}$	254	1230	19	236	0.810	0.466	0.529	0.440
	No	${100}^{\mathrm{t}\mathrm{h}}$	180	1,193	36	330	0.757	0.350	0.462	0.333
bpi2020p	Yes	${70}^{\mathrm{t}\mathrm{h}}$	362	844	47	19	0.904	0.804	0.802	0.823
	No	${100}^{\mathrm{t}\mathrm{h}}$	304	848	45	75	0.859	0.705	0.742	0.684

The method correctly detected 379 process instances as workarounds in the case of bpi2019 and 362 process instances in bpi2020p. In contrast, it correctly detects fewer workarounds for the bpi2013i (275) and bpi2012w (254) event logs. Further, the number of false classifications is smaller for bpi2020p (66) and bpi2019 (108) than for bpi2013i (150) and particularly bpi2012w (255). We also obtain higher accuracy, precision, recall, and f1-score values for the bpi2020p and bpi2019 event logs than for bpi2013i and bpi2012w, even though more noisy data are removed from bpi2013i and bpi2012w. Figure 6 reports the detection quality for each workaround class based on the bpi2020p event log.

Figure 6. Test results for detecting each workaround class based on the bpi2020p event log.

Regarding differentiating between a workaround (comprising the different workaround classes (1) to (7)) and no workaround (representing the class (0)), the number of FPs (47) was higher than the number of FNs (19) and included two erroneous classifications. First, the CNN incorrectly detected 29 process instances of the class no workaround to include a workaround, in particular a violated responsibility. Similarly, 18 process instances with no workaround were falsely classified as a workaround, particularly manipulated data. The number of FNs, however, was low and primarily consisted of not-detected workarounds referring to the types violated responsibility (9) and manipulated data (6).

In the entire group of TPs (i.e. the workaround classes (1) to (7)), there were only two obvious misclassifications. First, a substituted activity was occasionally misclassified as an interchanged activity (13) and vice versa (9). Second, 11 workarounds of the type added activity were misclassified as an interchanged activity. Overall, repeated activities were classified most reliably.

6.3. Results for workaround detection

The classifiers were applied not only to analyse the testing set but also to analyse the detection set itself. Table 10 reports the results of this step. Again, in the following, we primarily focus on the results obtained using the AE since they were generally better across all data sets. The differences between the results obtained with and without the removal of noisy data were particularly extreme for bpi2013i and bpi2012w. Without using an AE, the number of detected workarounds dropped from 304 to 34 (dropping 89%) for the bpi2013i event log, and from 573 to 247 (dropping 57%) for the bpi2012w event log. In contrast, the drop for bpi2019 was from 162 to 34 (dropping 79%), whereas for bpi2020p it was 195 to 39 (dropping 80%).

Table 10. Results for workaround detection.

Event log	AE	Percentile	No workaround (0)	Violated responsibility (1)	Manipulated data (2)	Repeated activity (3)	Substituted activity (4)	Interchanged activity (5)	Bypassed activity (6)	Added activity (7)	Sum
bpi2019	Yes	${70}^{\mathrm{t}\mathrm{h}}$	717	4	3	70	10	13	42	20	879
	No	${100}^{\mathrm{t}\mathrm{h}}$	845	3	0	6	1	9	15	0
bpi2013i	Yes	${50}^{\mathrm{t}\mathrm{h}}$	452	0	3	190	7	38	4	62	756
	No	${100}^{\mathrm{t}\mathrm{h}}$	722	1	0	4	2	16	4	7
bpi2012w	Yes	${50}^{\mathrm{t}\mathrm{h}}$	393	0	0	257	9	22	269	16	966
	No	${100}^{\mathrm{t}\mathrm{h}}$	719	0	0	20	1	3	221	2
bpi2020p	Yes	${70}^{\mathrm{t}\mathrm{h}}$	512	25	1	44	30	29	19	47	707
	No	${100}^{\mathrm{t}\mathrm{h}}$	668	12	0	6	4	2	14	1

Overall, the detection of workarounds was effective across different workaround types, with the exception of manipulated data and violated responsibility, which were detected infrequently. Next to no workaround, repeated activities were detected most frequently by far, followed by bypassed activities.

Just like the results regarding the test set, the quality in the detection set varied across the event logs analysed. As before, we noticed differences between the event logs of bpi2012w and bpi2013i, and bpi2019 and bpi2020p in several regards. First, the number of process instances with no workaround appeared to be lower in the first two event logs. Second, the number of process instances classified as a repeated activity was distinctly higher than in the last two event logs. Also, the bpi2012w event log exhibited a particularly large number of instances that were classified as bypassed activities compared with the other event logs. We interpret that this is followed by removing noisy data.

In general, detecting workarounds in event logs using the proposed DNN-based method was particularly effective for the bpi2020p and bpi2019 event logs since their analysis revealed a larger number of workarounds detected for the former (195) than for the latter (162). Even though cases of manipulated data were detected infrequently in both event logs, bpi2020p exhibited by far the highest number of process instances classified as violated responsibilities. Generally, the proposed method detected more workarounds in the bpi2020p event log across most classes, except for repeated activities, bypassed activities, and manipulated data, which were more frequently discovered in the bpi2019 data set.

6.4. Demonstration of workaround detection

Besides the quantitative evaluation of our method, we evaluate the method’s usefulness. To this end, we present an exemplary process instance per workaround type detected with our method in the bpi2020p event log and provide an explanation as to why the example includes a certain type of workaround. Additionally, we discuss the benefit of detecting this specific workaround.

6.4.1. Violated responsibility

The declaration was rejected by the role missing (Table 11). This indicates a violated responsibility because no concrete role, such as employee or supervisor, was entered. It seems that someone who rejected the permit was not allowed to do it. Therefore, the role is missing, and the declaration had to be submitted again by an employee. Hence, the detection of this workaround can be considered as violated user rights.

Table 11. Exemplary process instance of bpi2020p with violated responsibility.

Case ID	Activity	Timestamp	org:role	overspent
Travel permit 74,375	Permit SUBMITTED by EMPLOYEE	2017/03/17 16:34:06.000	EMPLOYEE	true
Travel permit 74,375	Permit FINAL_APPROVED by SUPERVISOR	2017/03/22 13:59:11.000	SUPERVISOR	true
Travel permit 74,375	Start trip	2017/05/29 0:00.000	EMPLOYEE	true
Travel permit 74,375	End trip	2017/06/08 0:00.000	EMPLOYEE	true
Travel permit 74,375	Declaration SUBMITTED by EMPLOYEE	2017/07/04 15:58:33.000	EMPLOYEE	true
Travel permit 74,375	Declaration FINAL_APPROVED by SUPERVISOR	2017/07/04 16:00:54.000	SUPERVISOR	true
Travel permit 74,375	Declaration REJECTED by MISSING	2017/07/07 10:01:48.000	MISSING	true
Travel permit 74,375	Declaration SUBMITTED by EMPLOYEE	2017/07/11 14:17:26.000	EMPLOYEE	true
Travel permit 74,375	Declaration FINAL_APPROVED by SUPERVISOR	2017/07/11 14:17:32.000	SUPERVISOR	true

6.4.2. Manipulated data

The data attribute overspent has the value “false” although the budget owner is involved (Table 12). This indicates that data manipulation took place because the budget owner is typically involved when the budget is overspent. As this workaround is detected, it can be checked why the budget owner approved this declaration even though not too much budget was spent.

Table 12. Exemplary process instance of bpi2020p with manipulated data.

Case ID	Activity	Timestamp	org:role	overspent
Travel permit 76,026	Permit SUBMITTED by EMPLOYEE	2017/03/23 10:11:09.000	EMPLOYEE	false
Travel permit 76,026	Permit FINAL_APPROVED by SUPERVISOR	2017/03/23 10:11:15.000	SUPERVISOR	false
Travel permit 76,026	Start trip	2018/02/25 0:00.000	EMPLOYEE	false
Travel permit 76,026	End trip	2018/03/10 0:00.000	EMPLOYEE	false
Travel permit 76,026	Declaration SUBMITTED by EMPLOYEE	2018/03/12 14:59:22.000	EMPLOYEE	false
Travel permit 76,026	Declaration APPROVED by ADMINISTRATION	2018/03/15 11:04:28.000	ADMINISTRATION	false
Travel permit 76,026	Declaration APPROVED by BUDGET OWNER	2018/03/15 14:21:30.000	BUDGET OWNER	false
Travel permit 76,026	Declaration FINAL_APPROVED by SUPERVISOR	2018/03/19 12:22:53.000	SUPERVISOR	false

6.4.3. Repeated activity

The permit was submitted and approved twice. This indicates a repeated activity (Table 13). A viable explanation for this repetition may be the rejection of the initial permit because some details were missing. It can be argued that an employee submitted an incomplete permit on purpose. Typically, it is time-consuming to figure out all information, and in most cases, not all information is required. Therefore, only if the permit is rejected, the employee takes the time to find out the missing information. Based on this workaround, relevant details for permits can be discussed to avoid or reduce activity repetitions.

6.4.4. Substituted activity

The director performed the final approval of the permit instead of the supervisor (Table 14). This indicates a substituted activity because a supervisor typically approves the permit of an employee. However, a possible explanation could be that this trip is of high relevance, and therefore, the director approved the permit directly. Based on this information, we can see that the director intervenes to avoid possible rejection of this trip by the supervisor. As this workaround is detected in an organisation, the type of final approval should be discussed. Further, more transparency should exist, which can be achieved when supervisors only approve permits.

6.4.5. Interchanged activity

The permission was submitted and approved after the trip starts (Table 15). This indicates an interchanged activity. It seems that an employee forgot to submit the permit prior to the trip because the employee submitted it on the second day of the trip. However, based on this workaround, the employee can be asked why the permit was submitted with a delay of one day. This way, more context information can be gathered, e.g., if an employee got an oral confirmation from his supervisor before the trip, saving time by performing this workaround.

6.4.6. Bypassed activity

Although the permit was neither approved by the pre-approver and employee nor approved by the supervisor, the employee carried out the trip (Table 16). This indicates a bypass of activities. However, a possible explanation could be that the employee is also a supervisor. Consequently, the employee did not require approval from the supervisor as he can approve his own trips. As this workaround is detected, the organisation should allow switching roles from employee to supervisor within the system. This would increase transparency because the supervisor’s role can be documented.

6.4.7. Added activity

The employee requested pre-payment before the trip starts (Table 17). Therefore, three request-for-payment activities were added. It could be that this trip was very expensive, and the employee did not have sufficient funding to cover the travel expenses or cannot wait until the refund. Based on this workaround, we can see that employees with low liquidity will send a request for payment. Otherwise, they cannot carry out the trip.

7. Discussion

With our method for detecting workarounds, we specifically address a research gap identified by Breuker and Matzner (2013). We demonstrate that event logs can be a valuable data source for studying workarounds – intentional deviations from organisational routines and business processes performed by humans. While related research centres on explaining how and why employees perform workarounds (Beerepoot & van de Weerd, 2018), an automatic detection method might identify additional information undiscoverable with empirical research methods and remedy biases that limit their applicability (Beerepoot et al., 2018; Röder et al., 2015a). Inspired by anomaly and deviation detection methods, we provided a new and highly requested approach for detecting and analysing workarounds in event logs.

7.1. Results

A quantitative evaluation with empirical data documented that the proposed method was capable of detecting most workarounds in the event logs. However, our results also show that detecting workarounds with high quality requires applying sound strategies for noisy data reduction. Noisy data represents any form of deviance in an event log and, therefore, may lead to a method to discover false positives and false negatives. For all event logs considered in the evaluation, the proposed method detected workarounds more accurately if noisy data was previously removed by using an AE. Unsurprisingly, we conclude that noisy data, which is inherently present in real-life event log data, can adversely affect the learning process of the CNN model for workaround classification.

Distinguishing two classes – workarounds and no workarounds – enabled us to achieve the highest detection quality for workarounds in the bpi2020p and bpi2019 event logs. In the former log, 379 process instances were correctly detected as workarounds, whereas 362 were detected in the latter log. Regarding the number of false classifications, 66 process instances were falsely detected in bpi2020p, compared with 150 in bpi2019. As we distinguished eight workaround classes, we achieved an accuracy of 90.40% (90.30%), a precision of 80.40% (76.60%), a recall of 80.40% (79.30%), and a f1-score of 82.30% (71.60%) for bpi2020p (bpi2019). All four metrics highlight that the method was effective in identifying workarounds in these two event logs.

In contrast, only 254 and 275 workarounds were correctly detected in the bpi2012w and bpi2013i event logs, respectively. The number of false classifications was also much higher for both event logs than for bpi2020p and bpi2013. Regarding the detection of different workaround types, the most noticeable difference in the bpi2020p and bpi2019 event logs was in terms of precision, recall, and f1-score. For bpi2020p (bpi2019), precision was more than 19% (15%) higher than for bpi2012w and bpi2013i. Likewise, the recall for bpi2020p (bpi2019) exceeded that for the other two logs by at least 14% (13%). The f1-score for bpi2020p (bpi2019) is also more than 23% (16%) higher than for the other two event logs.

Concerning our method’s main purpose – detecting potential workarounds – we conclude that it is riskier to misclassify process instances as false negatives than false positives. A false negative represents a process instance with a workaround that has been falsely detected as a normal process instance. This means that a potential workaround remains hidden in the event log data and is not explored further by a process analyst. In this case, the workaround will not lead to a formal improvement of a business process, while it will remain undiscovered and, potentially, misclassified as an anomaly or deviation. In contrast, a false positive is a normal process instance falsely classified to contain a workaround. While we assume that a process analyst will identify the false classification manually when inspecting the data, the approach would serve to filter out all instances not containing workarounds.

Further, the test detection results for the bpi2020p event log demonstrated that the proposed method occasionally misinterpreted no workarounds as violated responsibilities. This could be accounted for by the resource attribute’s semantic granularity, as the resource attribute differs between abstract roles and specific actors performing the activities. Moreover, the results demonstrated that workarounds of the type substituted activity were often mixed with workarounds of the type interchanged activity. This observation can be explained by the similarity of these workaround types, which is difficult to distinguish automatically without further context information.

Interestingly, concerning the detection results, two workaround types appeared to have lower detection rates. First, violated responsibility may be quite difficult to detect. Considering real-life scenarios of daily work, it is reasonable to assume that violated responsibility may not always be documented in event logs. For instance, an employee might provide a co-worker with access to a database, PC workstation, or other resources (e.g. by sharing their password), and this would not be detected by the system. In other processes, activities may be assigned to user roles such that they are mapped to a group of employees, complicating the detection of violations if an access control list is unavailable. Second, the detection rate of manipulated data is lower than the average detection rate of other workarounds. We conclude that this workaround type is not likely to occur in structured processes in which the control flow is strictly defined.

Our results demonstrate that workarounds can be detected very well in mass-transaction data and highly structured processes that exhibit fewer variations in the control flow of a process, such as the travel permit process documented in bpi2020p or the purchase-to-pay process documented in bpi2019 (Table 8). This finding can be attributed to the fact that employees often have relatively clear instructions, limited flexibility, and restrictive software tools limiting their ability, and maybe their need, to perform workarounds in these processes. In the case of processes with greater variability, employees are expected to instantiate process instances differently each time; in this case, the processes’ comparability is reduced and, therefore, distinguishing a workaround from the usual variance in a process is more complex. The event logs bpi2013i and bpi2012w (Table 8), which we used to evaluate our method, represent service processes that, by definition, need to be conducted cooperatively with customers. Therefore, it appears straightforward to assume that training a DNN requires significantly more data before an algorithm can distinguish a workaround from other deviations in a process.

Finally, data richness in an event log can, of course, affect the detection quality of workarounds. As shown in Table 8, the number of activities in the bpi2013i and bpi2012w event logs is lower than in bpi2020p or bpi2019. Hence, we assume that employees have fewer options to perform workarounds in these processes.

7.2. Managerial implications

Besides their scientific contribution as the first method guiding the detection of workarounds in event logs and their classification, our results provide profound value to managers. By detecting workarounds with our method, management has new opportunities to establish bottom-up process innovation in organisations. In a hyper-connected world, organisations are faced with an increasing need to innovate their processes, while the processes also become increasingly complex, involving unstructured data, additional participants, and, perhaps, even data from physical devices that are digitally networked (Beverungen et al., 2021). Resolving this paradox requires organisations to apply agile principles, e.g., by establishing teams of process managers and process participants that improve business processes in iterative cycles (Beverungen et al., 2021).

To inform cooperation and knowledge exchange for process improvement, workaround detection may be a useful tool to complement process participants’ tacit insights with hard field evidence, based on which workarounds, their consequences on a process, and their implications for the organisation can be assessed. Both interpersonal and data-driven aspects can enable workshop formats in which process managers and process participants decide if a workaround is accepted as a standard procedure, defined as a fallback solution, or discarded.

Besides process innovation, our method can also be used in organisations to trigger product innovation. For example, as employees or customers perform workarounds by using an information system differently than designed, managers can detect this deviation and deviate implications for a new system’s design with higher user-friendliness.

To further elicit our workaround detection method’s potential and limitations, we conducted expert interviews with employees from GEA,⁶ Process Inc.,⁷ Process&,⁸ Celonis⁹ and Software AG¹⁰ (Table 18). All interviews took place via video conferencing systems, were recorded, and transcribed.

Table 13. Exemplary process instance of bpi2020p with repeated activities.

Case ID	Activity	Timestamp	org:role	overspent
Travel permit 81,539	Permit SUBMITTED by EMPLOYEE	2017/06/23 15:51:30.000	EMPLOYEE	false
Travel permit 81,539	Permit FINAL_APPROVED by SUPERVISOR	2017/06/23 15:51:38.000	SUPERVISOR	false
Travel permit 81,539	Permit REJECTED by MISSING	2017/07/07 08:54:06.000	MISSING	false
Travel permit 81,539	Permit SUBMITTED by EMPLOYEE	2017/07/14 14:56:24.000	EMPLOYEE	false
Travel permit 81,539	Permit FINAL_APPROVED by SUPERVISOR	2017/07/14 14:56:27.000	SUPERVISOR	false
Travel permit 81,539	Start trip	2017/09/25 0:00.000	EMPLOYEE	false
Travel permit 81,539	End trip	2017/09/29 0:00.000	EMPLOYEE	false
Travel permit 81,539	Declaration SUBMITTED by EMPLOYEE	2017/10/25 15:50:13.000	EMPLOYEE	false
Travel permit 81,539	Declaration FINAL_APPROVED by SUPERVISOR	2017/10/25 16:02:32.000	SUPERVISOR	false

Table 14. Exemplary process instance of bpi2020p with substituted activity.

Case ID	Activity	Timestamp	org:role	overspent
Travel permit 81,818	Permit SUBMITTED by EMPLOYEE	2017/09/29 18:18:59.000	EMPLOYEE	false
Travel permit 81,818	Permit APPROVED by SUPERVISOR	2017/09/29 18:21:08.000	SUPERVISOR	false
Travel permit 81,818	Permit FINAL_APPROVED by DIRECTOR	2017/10/03 08:48:45.000	DIRECTOR	false
Travel permit 81,818	Request For Payment SUBMITTED by EMPLOYEE	2017/10/05 13:57:30.000	EMPLOYEE	false
Travel permit 81,818	Request For Payment FINAL_APPROVED by SUPERVISOR	2017/10/12 16:54:25.000	SUPERVISOR	false
Travel permit 81,818	Start trip	2017/12/02 0:00.000	EMPLOYEE	false
Travel permit 81,818	End trip	2017/12/08 0:00.000	EMPLOYEE	false
Travel permit 81,818	Declaration SUBMITTED by EMPLOYEE	2017/12/15 11:46:07.000	EMPLOYEE	false
Travel permit 81,818	Declaration FINAL_APPROVED by SUPERVISOR	2017/12/15 12:12:43.000	SUPERVISOR	false

Table 15. Exemplary process instance of bpi2020p with interchanged activity.

Case ID	Activity	Timestamp	org:role	overspent
Travel permit 73,049	Start trip	2017/01/26 0:00.000	EMPLOYEE	false
Travel permit 73,049	Permit SUBMITTED by EMPLOYEE	2017/01/27 20:58:18.000	EMPLOYEE	false
Travel permit 73,049	Permit FINAL_APPROVED by SUPERVISOR	2017/01/27 20:58:22.000	SUPERVISOR	false
Travel permit 73,049	End trip	2017/02/06 0:00.000	EMPLOYEE	false
Travel permit 73,049	Declaration SUBMITTED by EMPLOYEE	2017/02/20 21:08:03.000	EMPLOYEE	false
Travel permit 73,049	Declaration FINAL_APPROVED by SUPERVISOR	2017/02/20 21:08:15.000	SUPERVISOR	false

Table 16. Exemplary process instance of bpi2020p with bypassed activity.

Case ID	Activity	Timestamp	org:role	overspent
Travel permit 78,100	Permit SUBMITTED by EMPLOYEE	2017/04/25 14:39:32.000	EMPLOYEE	false
Travel permit 78,100	Permit REJECTED by PRE_APPROVER	2017/04/25 14:39:40.000	PRE_APPROVER	false
Travel permit 78,100	Permit REJECTED by EMPLOYEE	2017/04/25 15:24:06.000	EMPLOYEE	false
Travel permit 78,100	Start trip	2017/08/27 0:00.000	EMPLOYEE	false
Travel permit 78,100	End trip	2017/09/01 0:00.000	EMPLOYEE	false

Table 17. Exemplary process instance of bpi2020p with added activity.

Case ID	Activity	Timestamp	org:role	overspent
Travel permit 77,875	Permit SUBMITTED by EMPLOYEE	2017/01/11 18:02:47.000	EMPLOYEE	true
Travel permit 77,875	Permit FINAL_APPROVED by SUPERVISOR	2017/01/11 18:04:54.000	SUPERVISOR	true
Travel permit 77,875	Request For Payment SUBMITTED by EMPLOYEE	2017/03/07 09:22:00.000	EMPLOYEE	true
Travel permit 77,875	Request For Payment APPROVED by PRE_APPROVER	2017/03/07 09:22:48.000	PRE_APPROVER	true
Travel permit 77,875	Request For Payment FINAL_APPROVED by SUPERVISOR	2017/03/13 11:30:21.000	SUPERVISOR	true
Travel permit 77,875	Start trip	2017/05/21 0:00.000	EMPLOYEE	true
Travel permit 77,875	End trip	2017/05/24 0:00.000	EMPLOYEE	true
Travel permit 77,875	Declaration SUBMITTED by EMPLOYEE	2017/06/02 13:50:38.000	EMPLOYEE	true
Travel permit 77,875	Declaration APPROVED by PRE_APPROVER	2017/06/02 13:50:52.000	PRE_APPROVER	true
Travel permit 77,875	Declaration FINAL_APPROVED by SUPERVISOR	2017/06/05 08:14:06.000	SUPERVISOR	true

Table 18. Details on interview partners.

ID	Company	Employees	Interviewee	Duration
I1	GEA	18,000	Leading process manager	35 min
I2	Process Inc.	$>$ 1,000	Software engineer for PM solutions	28 min
I3	Process&	35	Data scientist for analytics solutions	30 min
I4	Celonis	1,300	High-level process manager	19 min
I5	Software AG	5,000	Product manager for PM solutions	26 min

An initial observation we derived from our interviews is a conscious distinction between workarounds and anomalies by our informants. For example, I1 distinguished workarounds from anomalies, emphasising that his understanding is that anomalies can, for example, be related to technical changes in a software that cannot be anticipated, whereas he consider[s] a workaround to be a deviation performed consciously by participants, leading them to, for example, do something differently or skip an activity. In a similar vein, I3 confirmed the idea that workarounds are typically human-driven. In light of the long-standing tradition of business process modelling and management in many companies, I4 assumed that there are few anomalies left. […] It’s more like a single person saying “I have my own workaround here”. […] That’s primarily where we see things pop up that deviate from the standard.

Thus, from the perspective of process managers, detecting and classifying workarounds, as done with our approach, is considered an important tool for improving business processes in close cooperation with process participants. Currently, workarounds are used to improve processes, but no tool-supported method is in place. Even so, workarounds are viewed as valuable input for implementing process innovation. As I1 stated, they introduced a new process to the participants. Then, somebody sitting in the last row said “I always do it that way”, and this was a much better process than the one we defined, such that we updated our process. On the other hand, people also deviate from processes for their own reasons, sometimes even resisting standard processes in a creative way. This creativity inherent in the concept of workarounds is also stressed by I4, mentioning the importance of differentiating between the creative deviations from the standard process and the intentionally malicious deviations.

This somewhat ambiguous nature of workarounds, which we stress in our conceptualisation, is also recognised by practice. On the one hand, workarounds may be expressions of employees’ reluctance to process innovation, resulting in using old ways of working instead of standard processes (e.g. I1 mentioned employees keeping documenting their working hours using the standard transaction KB21N in SAP instead of using SAP CATS; or using MS Project, while they were unable to use another project management tool). Interestingly, I2 shared the impression that usually, anomaly detection focuses on this negative side. On the other hand, in line with the previously discussed temporality of workarounds, several of the practitioners we consulted also acknowledged the innovative capacity provided by workarounds. A recurring theme in this regard was the impetus for the redesign of processes provided by the identification of best practices by people who live the process as part of their day-to-day work leading to adaptations of a process that may potentially be outdated and reality has moved on (I5).

Importantly, however, the assessment of whether a workaround is positive or negative is always in the eye of the beholder, as pointed out by I4, with the evaluation of workarounds never being black or white (I3). Workarounds can have consequences on other activities carried out in a process. Sometimes, their negative consequences can even outweigh their local advantages for a participant. Indeed, another informant (I1) stated that they often realised that local improvements could have adverse effects on a process level that manifest down the road. Thus, it is important to manage workarounds on a process level beyond the local context in which they are performed. For this purpose, GEA, for example, has established procedures to identify the consequences of individual changes on a process level.

While practitioners are typically well aware of workarounds, there is no structured approach for identifying and classifying them, even if such a method is highly desired. I1 highlighted that it is not easy to make workarounds visible. However, practitioners still employ different approaches to detect workarounds, with I5 stating that without such a data-driven method, a process analyst would probably only conduct a few interviews or only grasp a small slice of reality. As a result, the experts we consulted overall acknowledged the usefulness of our proposed method. For example, GEA has established Lean Boards as regular meetings to discuss improvements in their organisation. Sometimes, these meetings are used for knowledge exchange in process improvements (people learn from each other, and we (as process managers) learn how we can improve our processes (I1)). An approach such as the one introduced in this paper could enable GEA to introduce workarounds into their Lean Board meeting in a more complete and structured way since it can help to identify workarounds early, bring people together to discuss their ideas with a clear reference to a process, and back up practice with data on workarounds and their consequences on a process. Thus, I1 stated that it would be nice to have a tool in which we can see workarounds, such that we can talk to people to find out why they work differently. Classifying the type of workarounds – as done by our method – could help to focus these discussions, since sometimes we do not realise that people establish access rules to perform a process entirely, violating our standard processes. Similarly, I5 emphasised the importance of being able to differentiate between different classes of workarounds, thus stating that as a process mining vendor, I could definitely see us embed this into our offerings.

7.3. Related work

In line with the research gap identified by Breuker and Matzner (2013), that is, the missing connection between PM methods and research on organisational routines, our intended knowledge contribution resides at the intersection of exaptation and invention (Gregor & Hevner, 2013). It can partly be classified as exaptation because dedicated ML-based methods for the detection of anomalies and deviations have already been developed in the field of PM. We transfer the core idea behind these ideas to the application domain of workarounds. However, our work also goes beyond pure exaptation, because our proposed workaround detection method displays differences to these related methods conceptually and in terms of its concrete design.

Conceptually, the starting point of our method is the peculiarities of workarounds, which differ from anomalies and deviations in three regards. As a first conceptual difference ($C{D}_1$), workarounds are driven by humans’ intentions, as opposed to concepts that describe (un-)intentional errors made by humans or machines. For this reason, workarounds are intention-driven, more complex to discover, and can manifest in other ways than anomalies and deviations. Second ($C{D}_2$), workarounds evolve through a life-cycle spanning from their first appearance to their institutionalisation, whereas anomalies and deviations might re-appear over time but do not constitute temporal drift in a business process. Over time, the roles of a workaround and a standard process can shift if a workaround diffuses through an organisation and is adopted as the new standard process. This shift implies that workaround detection methods should consider the life-cycle stage of a workaround to deliver interpretable results, while methods for detecting anomalies and deviations are time-invariant. Because this paper is an early investigation of the role of PM in workaround detection, we only consider workarounds’ first phase of the life-cycle, focusing on the detection of temporal changes. Third ($C{D}_3$), workarounds can yield positive effects in an organisation, while anomalies are per se undesirable deviations from pre-specified standard processes. Thus, process managers need to decide if unusual behaviour is a workaround that can provide process innovation or an undesirable deviation.

These conceptual peculiarities of workarounds guided the design of our method. Thus, they are reflected in some choices we made in contrast to other, state-of-the-art anomaly and deviation detection methods, such as the anomaly detection method by Nolle et al. (2019) and the deviation detection method by Folino et al. (2020). More specifically, these choices are related to data input, phases, and detection classes (Table 19). In view of the still-nascent character of our research endeavours to build a bridge between organisational routines and BPM, not all the conceptual differences are entirely integrated into our method. Nevertheless, we refer to them for guidance in the following to indicate the lines of thought that led us to deviate from existing approaches.

Table 19. Differentiation of our workaround detection method’s design from state-of-the-art anomaly and deviation detection methods.

Method	Workaround detection	Anomaly detection	Deviation detection
	(Ours)	(e.g. Nolle et al. (2019))	(e.g. Folino et al. (2020))
Data input	Real-life event logs only with activities performed by humans	Synthetic/real-life event logs	Real-life event logs
Phases	(1) Setting up an initial data set	(1) Pre-processing	(1) Pre-processing
	(2) Removing noisy data	(2) Learning a classifier	(2) Learning a classifier
	(3) Adding workarounds	(3) Calculating anomaly scores	(3) Applying a classifier
	(4) Learning a classifier	(4) Classifying anomalies
	(5) Applying a classifier
Detection classes	- No workaround	- Normal	- Normal
	- Manipulated data	- Normal attribute	- Deviant
	- Violated responsibility	- Attribute
	- Repeated activity	- Rework
	- Substituted activity	- Skip
	- Interchanged activity	- Insert
	- Bypassed activity	- Early
	- Added activity	- Late
		- Shift

$C{D}_1$, for example, is reflected in our method in terms of data input, as our method requires event log data with activities performed by human actors to detect workarounds. While such a limitation would theoretically also be possible through adaptations of other methods, the anomaly detection method of Nolle et al. (2019) and the deviation detection method of Folino et al. (2020) do not set such a focus but instead include other types of activities as well ($C{D}_1$).

Especially $C{D}_1$ also guided the design of several phases of our method in which we deviate from related work. More specifically, our conceptual focus on workarounds is primarily reflected in three differences with regard to the work of Nolle et al. (2019) and Folino et al. (2020). First, in the second phase, our method removes noisy data (i.e. all forms of divergent behaviour) using an AE. This is especially important for workaround detection because other forms of divergent behaviour, intentional or not, may blur workaround patterns. In contrast, Nolle et al. (2019)’s anomaly and Folino et al. (2020)’s deviation detection method do not include such a noisy-data-removal phase.

Second, in the third phase, our method adds workarounds to $30\mathrm{\%}$ of the process instances that are randomly selected from the training set. To create these workarounds, the method uses rules with randomised elements to create complex workaround patterns that may be expected as a result of human behaviour. In contrast, Nolle et al. (2019)’s anomaly and Folino et al. (2020)’s deviation detection methods do not include a phase for adding anomalies and deviations to the training set. While Nolle et al. (2019) evaluated their method with synthetic and anomaly-enriched real-life data sets, Folino et al. (2020)’s method received as input real-life data sets with deviation labels created based on values of single data attributes (static rules).

Third, in the fourth phase, our method learns a CNN classification model to classify process instances directly based on eight concrete workaround classes. This enables our method to classify complex, temporal workaround patterns that, again, are the result of human behaviour. Whereas other state-of-the-art approaches also partially rely on ML, they often turn to static rules for the step of classification. For example, Nolle et al. (2019) learned a multi-task DNN model with gated recurrent units to predict next events (i.e. activities and next values for all data attributes). Based on the probability distribution of predictions, the authors calculated scores to detect which attributes of a process instance indicate an anomaly or not. The classification of process instances into specific anomaly classes was subsequently achieved via static rules based on these scores. Further, Folino et al. (2020) learned a meta classification model, including an ensemble of sub-classification models, to detect whether a process instance is a deviation or not. Deviations were not further classified by specific deviation classes.

Fourth and importantly, a meaningful assessment of workarounds along with their impact requires a rather granular classification. Thus, whereas many existing methods (e.g. Folino et al., 2020) merely rely on binary classification, our method uses a more differentiated approach. Of course, there have also been valuable approaches, such as the method proposed by Nolle et al. (2019), which offer a more granular classification. Still, whereas some of the detected classes such as attribute (manipulated data), rework (repeated activity), skip (bypassed activity), and insert (added activity) are similar to our approach, we attempted to reflect the importance of workaround differentiation in additional classes and an implicit focus on intentional behaviour as opposed to, for example, machine errors.

Despite the guiding character of the conceptual differences between workarounds, anomalies, and deviations for our work, not all of the factors are evident in our method at first glance. Whereas $C{D}_1$ is prominently reflected in the choices we made that are described above, $C{D}_2$ and $C{D}_3$ are nevertheless discernible in our method’s design. For example, the randomised addition of workarounds is, to a certain extent, intended to mimic the temporality of workarounds. Similarly, the premise of an unbiased assessment of workarounds as both potentially positive or negative guided the conceptualisation of our detection classes.

7.4. Limitations

Even though the proposed workaround detection method’s results and implications are encouraging, our method is subject to some limitations. First, the evaluation suggests that some workaround types may be more difficult to detect than others using PM methods (Outmazgin & Soffer, 2016). For instance, if employees use a mix of different information systems to perform a task, workarounds may no longer be detected based on event logs from one system only. Therefore, a triangulation of data from multiple sources provides a new lens for understanding workarounds. Second, we focused exclusively on workarounds that can be detected in an event log. Hence, we did not consider manual workarounds because such workarounds leave no digital data traces. Third, our method detects workarounds in event logs that do not include a ground truth workaround label. To the best of the authors’ knowledge, such a labelled event log does not exist yet. In addition to such an event log, a to-be process model for the underlying process could be beneficial because it facilitates the assessment of workarounds. However, event logs with a missing label are a common problem in PM, especially in the sub-field of anomaly detection (Nolle et al., 2019). To overcome this problem, developed methods were evaluated based on synthetic and/or manipulated event logs representing reality to a certain degree. Since our method’s CNN model is trained based on event log data with artificially added workarounds, the CNN can learn to recognise these patterns but not causal representations that could be learned from real-life event log data with a ground truth workaround label. Fourth, due to the absence of qualitative insights about the process instances performed by employees, it cannot be assured whether workarounds exist in the noisy data removed from the event logs, whether workarounds exist in the remaining normal portion of the event log data, or whether the noisy data include regular variations of a process that are not workarounds. Fifth, the implemented specification of the workaround types is subject to design decisions that were made during neural network training; these decisions may distort the nature of particular workarounds to a certain degree (Figure 1), as workarounds may manifest themselves differently depending on the specific behaviour in an event log. As suggested by Nolle et al. (2019), we alleviate this problem by using randomised elements in the specification of the different workaround types. As another, the imbalance of workaround classes can decrease the detection quality of the proposed method. In particular, the learning process of a CNN, as used here, can be negatively affected by class imbalance (Buda et al., 2018). Finally, despite the positive assessment of our proposed method by the consulted practitioners, stressing the importance of detecting workarounds at an early stage, it also became apparent that there is a need for further methodological support along the workaround life cycle.

8. Conclusion

Drawing on PM and ML, we designed the first DNN-based method for the automatic detection of the complex phenomenon of workarounds in event logs. An evaluation involving four public event logs demonstrated that the proposed method is capable of detecting workarounds with high accuracy, precision, recall, and f1-score, especially for business processes with fewer variants and a higher number of different activities. Workarounds are ubiquitous in organisations and frequently occur when information systems are used. Often, workarounds remain undetected because employees do not report deviations regarding a business process or the use of an IT artefact. A failure to detect a workaround can lead to an undesirable, gradual manifestation of the workaround in organisational structures (Tucker et al., 2014), exerting positive or negative consequences. Also, adding to the unawareness of the actions of their employees, managers often lack easily applicable methods and tools to analyse and improve their business processes. By providing a method for automatically detecting potential workarounds, we make a significant contribution to research and practice, as workarounds can be easily identified, and actions can be taken to either counteract or leverage them.

In summary, our work strengthens the connection between research on organisational routines and PM. Both disciplines prove to remain astonishingly separated, even if they investigate similar phenomena (Breuker & Matzner, 2014). Additional research is required to further study and establish a nexus between both disciplines. To extend our method’s scope of detection, additional workaround types can be specified. To further increase the detection quality of our method, the utility of more elaborated methods removing noisy data (e.g. an AE with long short-term memory cells (Hochreiter & Schmidhuber, 1997)) can be investigated, “traditional” ML algorithms (e.g. a “shallow” neural network) or other types of DL algorithms (e.g. a generative adversarial network, a transformer network or a graph neural network) can be used for workaround classification, or the class-imbalance problem of the CNN can be addressed (e.g. by applying an oversampling method (Buda et al., 2018)). Researchers can further analyse the noisy data that are removed from the event logs by using the AE to better understand the considered workaround types, or to identify additional workaround types or other forms of deviation. Another direction for future research is to decompose the learning problem of workaround classification. The present method uses a single CNN model for that purpose. Instead, workaround classification could be performed by two ML models; the first would detect whether a workaround occurs in a process instance or not, whereas the second would detect the concrete workaround type in the case of a workaround occurrence. Further, researchers can investigate the utilisation of methods from explainable artificial intelligence to determine which parts of a process instance constitute a detected workaround. For example, such a method can calculate a relevance value for each attribute of a process instance, describing the attribute importance regarding a detected workaround type (Stierle et al., 2021). This would be beneficial for the analysis of detected workarounds, especially in long process instances. Finally, researchers can extend the present method to detect multiple workarounds per process instance, even if the workaround types are different. To this end, a CNN, as used in this work, may be a promising solution because of its shared parameter capability, which enables using the same weight vector in a feature map to determine the same patterns at different positions in the event log data.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Correction Statement

This article has been republished with minor changes. These changes do not impact the academic content of the article.

Additional information

Funding

This work was supported by the Federal Ministry of Education and Research (BMBF) within the framework Software Campus (www.softwarecampus.de) under the funding code 01IS17045 and the project Digivation (www.digivation.de) under the funding code 02K14A220.

Notes

1. This paper is an extended and revised version of a previous work published in the proceedings of the 28^th European Conference on Information Systems (Weinzierl et al., 2020). This paper mainly differs from its previous version in three ways. First, we extended the theoretical background in this research by providing more in-depth insights regarding the temporality of workarounds and the difference between related concepts, such as anomalies and deviations. Second, we added a formalism to the artefact section to improve the traceability of our method’s phases and extended the evaluation by heuristically determining the threshold for removing noisy data and adding a demonstration for workaround detection to provide further evidence for our method’s usefulness. Third, this paper provides a broader discussion regarding results, managerial implications, differentiation from related work, and limitations.

2. Note: For better readability, we denote ${\mathcal{L}}^{(\tau )}$ as $\mathcal{L}$.

3. Note: In our running example, which is shown in Table 3, each column (e.g. $a_0$) represents two separate columns in a matrix.

4. Note: “Noisy data” is not equivalent to “noise”. “Noise” is a sub-type of anomalies (Section 2).

5. https://github.com/fau-is/wdwdl

6. GEA Group AG is one of the world’s largest systems suppliers for the food, beverage and pharmaceutical sectors. The informant is a leading process manager in GEA’s central business process management office. He is responsible for tracing and improving end-to-end processes in the entire organisation.

7. Process Inc. is a pseudonym used for confidentiality reasons. The informant is a software engineer for PM solutions.

8. Process& GmbH is a software and consulting company focusing on PM and analytics. The informant is a data scientist responsible for the development of advanced analytics solutions.

9. Celonis SE is one of the world’s largest providers of PM solutions. The informant is a high-level manager responsible for the identification and realisation of value potentials through PM.

10. Software AG is a large provider of software solutions focusing to a large extent on the design and analysis of business processes. The informant is a high-level product manager for PM solutions.

Appendix

A: Mean squared error calculation of the AE

Algorithm 1 formulates the calculation of the mean squared error through the loss function of the AE. Here, the reconstruction error per process instance $s_{\sigma }$ refers to the mean squared error, whereas the overall normalised reconstruction error $s_{D_{train}}$ corresponds to the normalised mean squared error.

Algorithm 1: Mean squared error of the AE’s loss function.

Given: ${\mathbf{D}}_{train}\in {\mathbb{R}}^{b\times v},f_{enc}(\cdot ),f_{dec}(\cdot ).$

1 ${\hat{\mathbf{D}}}_{train}\leftarrow f_{dec}(f_{enc}({\mathbf{D}}_{train})).$// generated model output

2 ${\mathbf{D}}_{delta}\leftarrow {\mathbf{D}}_{train}-{\hat{\mathbf{D}}}_{train}.$// difference of matrices

3 $\mathbf{s}\leftarrow []$// reconstruction errors

4 $v\leftarrow |{\mathbf{D}}_{delta}[0,:]|.$// number of attributes

5 $b\leftarrow |{\mathbf{D}}_{delta}[:,0]|.$// number of process instances

6 for $i\leftarrow 1$ to $b$ do

7 $s_{{\sigma }_i}\leftarrow \frac{1}{v}{\sum }_{x=0}^v({\mathbf{D}}_{delta}[i,x]{)}^2.$// reconst. error (per instance)

8 $\mathbf{s}.append(s_{{\sigma }_i}).$

9 end

10 $s_{D_{train}}=\frac{1}{b}{\sum }_{x=0}^b\mathbf{s}[x].$// reconst. error (all instances).

B: Hyper-parameter configuration of the AE

Table B1 summarises the optimised hyper-parameters (and their values) in the training phase of the AE.

Table B1. Hyper-parameter configuration for the AE.

Hyper-parameter	Values
Number of layers ($n$)	[3; 5; 7]
Number of units ($k$)	[64; 128; 256]
Kernel initialiser	[glorot_normal; glorot_uniform]
Activation function	[linear; tanh; relu]
Optimiser	[adam; nadam]

Inspired by the work of Hinton and Salakhutdinov (2006), the architecture of the AE consists of two components: an encoder and a decoder, where each component can be represented by dense layers. Thus, we check in the hyper-parameter optimisation AE architectures with three different settings of dense layers. In each setting, with $n$ layers, $(n-1)/2+1$ layers are used for encoding, and $(n-1)/2$ layers for decoding. Further, we vary the number of units (i.e. neurons) of all dense layers, except for the first and the last, through the parameter $k$. The value of $k$ can be either set to $64$, $128$, or $256$. To ensure that the architecture has a balanced structure, we set the number of neurons of the first and the last layer to the number of attributes $v$ of the receiving training set ${\mathbf{D}}_{train}\in {\mathbb{R}}^{b\times v}$, the number of neurons of the second and penultimate layer to $k$, and halve the number of neurons for the remaining layers. For example, if $k$ has been assigned to the value $64$, and the architecture comprises five layers, the number of units assigned to the five layers are $v$, $64$, $32$, $64$, and $v$. Therefore, to reconstruct the input, the number of neurons in the input layer is equal to the number of neurons in the output layer. By default, the weights of the layers (i.e. kernels) are initialised with normal distributed values. In addition, we initialise the weights with uniformly distributed values. Regarding the activation function of the dense layers, we apply the three variants: linear, tanh, and relu, with tanh being the default. For optimisation, we use either adam or nadam for the AE models with a mean squared error loss. Regarding the other parameters of these algorithms (e.g. learning rate), we use the default values. Finally, to train the AE models, we set the batch size to $128$, where the gradients are updated after each 128^th process instance because larger sizes tend to sharp minima, and generally, a sharp minimum results in reduced generalisability (Keskar et al., 2017).

C: Hyper-parameter configuration of the CNN

Table B2 summarises the optimised hyper-parameters (and their values) in the training phase of the CNN.

Table B2. Hyper-parameter configuration for the CNN.

Hyper-parameter	Values
Number of layers	[5; 6; 7; 8]
Number of filters	[32; 64; 128; 256]
Kernel size	[8; 16; 32; 64]
Padding	[same; causal]
Number of units	[50; 100; 150]
Kernel initialiser	[glorot_normal; glort_uniform]
Activation function	[linear; tanh; relu]
Optimiser	[adam; nadam]

We first optimise the number of convolutional layers in the CNN architecture. In addition, to the input layer and the two dense layers at the end of the architecture, the number of convolutional layers could be two, three, four, or five. From a technical perspective, a flatten layer is used to transform the three-dimensional output of the last convolutional layer to a two-dimensional representation for the subsequent dense layer. However, the number of layers in Table 21 does not include the flatten layer because it is a technical operation for transforming data structures rather than a neural network layer. Hence, the deepest CNN architecture consists of eight layers, whereas the shallowest has five layers. In line with Al-Jebrni et al. (2018), we investigate deeper architectures with two or more convolutional layers to better discover structures in event log data that may indicate different workaround types. Further, each convolutional layer can be decomposed into a convolution, a detector, and a pooling stage (Goodfellow et al., 2016). Regarding the convolutional stage, we optimise the number of filters (i.e. $32$, $64$, $128$, or $256$), the kernel size (i.e. $8$, $16$, $32$, or $64$), and the padding (i.e. same or causal). In the detector stage (and the penultimate dense layer), the activation functions linear, tanh, and relu are considered. Concerning the last layer, we apply the activation function sigmoid to obtain probability distributions that correspond to different workaround classes. In the pooling stage, we use the pooling function max-pooling. For the penultimate dense layer, we optimise the number of neurons, which varies between $50$, $100$, and $150$. By contrast, we do not vary the number of neurons in the last layer because those neurons represent the workaround classes. For the CNN, we use either the adam or the nadam optimisation algorithm and calculate the categorical cross-entropy loss. As in the case of the AE, we use the default values for other parameters of the optimisation algorithms and set the batch size to $128$.