Blog Details

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

Posted by Marbenz Antonio on May 19, 2022

As-is process models are manually generated representations of how individuals – experts or process participants who deal with the process daily – believe a process truly functions in conventional Business Process Management (BPM). To-be models, on the other hand, explain how a process should, ideally or pragmatically, run in the future. The differences between the as-is and to-be models of the same process may then be used to determine the adjustments that must be made to the existing process to attain the intended future behavior. The emergence of process mining presents certain concerns with this viewpoint:

1. Can a manually constructed process model that is not based on execution data still be regarded as an as-is model, given that we can generate process models from event logs?
2. Even though such a process model may still be treated as-is, isn’t it inferior to a mining model, and shouldn’t the name reflect this?

We set out to clarify these problems in this blog article, while also considering comparable difficulties around the concept of a to-be process model.

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

The goal of as-is process models is to capture how a process works in practice. However, as-is models do not have to replicate all of the intricacies of real-world behavior of all process instances. Given the famous George Box comment that “all models are flawed, but some are helpful,” an as-is model may, for example, merely reflect the happy path through a process to provide readers with a basic idea of how the process works at a glance. As-is process models can be developed using expert input, feedback from process participants, event log data, or a combination of the three:

• Experts may specify how a process is probably carried out by one or more IT systems.
• A group of process participants can share their subjective experiences of performing the process in collaboration with IT systems and human actors. These participants may be internal (typically employees) or external (generally customers) (e.g., customers or suppliers).
• An event log of the process may be pulled from the necessary IT systems to build a process diagram automatically.

In all cases, the type of model is a stand-alone model with different strengths and weaknesses:

• While the experts may have a good understanding of the process and related IT systems and roles, their model may not accurately capture the aspects of IT system behaviors, as well as human decision-making and cooperation “on the ground.” It just represents the experts’ opinions on the procedure.
• Participants in the process help the development of a model that reflects human experiences, which must be acknowledged. However, people may report process behavior from the perspective of their subjective human biases, such as their own career goals. Additionally, complicated IT system behavior may not be understood or even obvious to participants.
• Event logs may accurately represent process behavior that occurs in specific IT systems, but they ignore important aspects of human behavior, such as workarounds humans may use outside of the context of the IT systems to speed up the process or facilitate process outcomes that are desirable for human participants. Also, judgments about the abstraction level of the process must be made both when extracting data for event log creation and when evaluating event log data: first concerning event granularity and subsequently about the number of variations that should be necessitated by the model.

Models that primarily use expert and process participant feedback are based on beliefs and experiences, whereas data-driven models are based on records. Only by integrating human-centered and data-driven viewpoints can we secure process knowledge; and, in any event, the amount of trust we have in a process model changes from instance to situation. The value of human experience is reflected in SAP Signavio’s Journey Modeler and Journey-to-Process Analytics tools.

To-Be: Standardized Reference and Individualized Target Behavior

We discussed above how well an as-is model reflects real-world process behavior. Therefore, we may analyze how well a potential model captures desired, attainable, and viable target process behavior. A future process model, for example, may represent the standard process that an enterprise software module implements or it could mirror an organization’s heritage process, although with a higher degree of automation. As a result, to objectively analyze the condition of a future process model, one might look at how well the model reflects:

• How to process participants and stakeholders would want to work (desirability).
• How the organization may function while taking into account technological and socio-organizational restrictions (feasibility).
• How the organization should function while keeping business restrictions and objectives in mind (viability).

Additionally, we must evaluate the to-be model’s use case, which influences the planned granularity and breadth. To-be models with the use case of automation, for example, may have more technological features than models produced for risk and compliance purposes, which may include descriptions of risks and controls that an ‘automation’ model does not. The use case consideration also extended to existing process models.

Naming

There are alternative name pairings for as-is and to-be. Current and future states, in particular, are commonly employed. For the following reasons, we advocate using as-is and to-be:

• It is commonly used terminology.
• It is pretty interesting.
• It does not employ the term state, which in engineering language usually refers to the state of running instances, i.e., to instance-level properties rather than model-level attributes.

Conclusion

To determine whether a process model is indeed fit for its purpose, we recommend analyzing its limitations, i.e., whether the human or data-based input for as-is models accurately reflects reality, and whether the technological, socio-organizational, and business contexts of a process have been fully considered when developing a to-be process model. In a data-driven environment, we have presented a set of guidelines for how to think about as-is and to-be process models. We especially advise utilizing as-is and to-be as descriptors of a model’s purpose rather than its information origins.

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com