How to Drive Business Transformation in a Data-Driven World: As-Is vs. To-Be Process Models

[TimotheusKampik]

In traditional Business Process Management (BPM), as-is process models are manually crafted representations of how people – experts or process participants who interact with the process on a day-to-day basis – think a process actually runs. In contrast, to-be models specify how a process should, ideally or pragmatically, run in the future. As-is and to-be models of the same process can then be used to determine the changes that need to be made to the current process to achieve the desired future behavior. The advent of process mining raises some questions about this perspective: 

1. Given we can generate process models from event logs, can a manually created process model that is not based on execution data still be considered an as-is model? 


2. Even if such a process model can still be considered an as-is model, isn’t it inferior to a mined model and shouldn’t this be reflected by the naming we use for it? 

In this blog post, we set out to answer these questions, while also discussing similar ambiguities around the notion of a to-be process model. 

As-Is: Beliefs, Experiences, Data, and Knowledge 

The purpose of as-is process models is to capture how a process actually runs. However, as-is models do not necessarily need to reflect all nuances of the real-world behavior of all process instances. Considering the famous George Box quote that “all models are wrong but some are useful”, an as-is model may, for example, only reflect the happy path through a process in order to give readers a rough intuition of how the process works at a glance. As-is process models can be created based on expert input, process participant feedback, event log data, or a mix thereof: 

• Experts may provide a specification of how a process is presumably executed by one or several IT systems. 


• A group of process participants may provide insights into their subjective experiences of executing the process in cooperation with IT systems and human actors. These participants may be internal (typically employees) or external (e.g., customers or suppliers). 


• An event log of the process can be extracted from the relevant IT systems to then auto-generate a process diagram. 

In all cases, the resulting model is an as-is model, albeit with different strengths and weaknesses: 

• While the experts may have a reasonably good understanding of the process and related IT systems and roles, their model may neither correctly represent all details of IT system behaviors, nor the human decision-making and collaboration ‘on the ground’. It merely reflects the experts’ beliefs about the process. 


• The process participants help create a model that reflects human experiences, which are important to take into account. Still, the participants may report process behavior from the perspective of their subjective human biases, for example considering their own career ambitions. Also, complex IT system behavior may not be understood by and may possibly be not even visible to the participants. 


• Event logs may precisely represent process behavior that occurs in specific IT systems, but ignore important aspects of human behavior, such as work-arounds humans may use outside of the IT systems’ context to speed-up the process or to facilitate process outcomes that are desirable for the human participants. Also, both when extracting data for event log generation and when analyzing event log data, decisions about the abstraction level of the process need to be made: first with respect to event granularity and then regarding the number of variants that should be entailed by the model. 

We can say that models that primarily consider expert and process participant feedback are based on beliefs and experiences, whereas event log-based models are based on data. Only the integration of both – combining human-centered and data-driven perspectives -- ensures that we have process knowledge; and in any case, the level of confidence we have in a process model differs from case to case. At SAP Signavio, the importance of human experience is reflected in the Journey Modeler and Journey-to-Process Analytics products. 

To-Be: Standardized Reference and Individualized Target Behavior 

Above, we have questioned to what extent an as-is model reflects real-world process behavior. Analogously, we can examine how well a to-be model represents desirable, feasible, and viable target process behavior. For example, a to-be process model may represent the standard process that an enterprise software module implements, or it may reflect an organization’s legacy process, merely with a higher degree of automation. Hence, to critically assess the state of a to-be process model, one can examine to what extent the model reflects: 

• How the process participants and stakeholders want to work (desirability). 


• How the organization can run, considering technological and socio-organizational constraints (feasibility). 


• How the organization should run, considering business constraints and objectives (viability). 

In addition, we need to consider the use case of the to-be model, which in turn informs the intended granularity and scope. For example, to-be models whose use case is automation may contain more technology details than models created for risk and compliance purposes, which may in turn include specifications of risks and controls that an ‘automation’ model omits. The consideration of the use case also applied to as-is process models. 

Naming 

Alternative name pairs for as-is and to-be exist. In particular, current state and future state are frequently used. We recommend using as-is and to-be for the following reasons: 

• It is widely used terminology. 


• It is relatively concise. 


• It does not make use of the term state, which in engineering terminology typically refers to the state of running instances, i.e., to instance-level and not to model-level properties. 

Conclusion 

To assess to what extent a process model is indeed fit for its purpose, we recommend analyzing its limitations, i.e., to what extent the human or data-based input for as-is models reflects the complete reality and whether the peculiarity of a process’ technological, socio-organizational, and business contexts have been fully considered when creating a to-be process model. We have provided a set of recommendations of how to think about as-is and to-be process models in a data-driven world. In particular, we recommend using as-is and to-be as descriptors of a model’s purpose and not of its information origins.