In the modern business landscape, leaders are shifting from intuitive process selection to evidence-based approaches where real performance data serves as the foundation for measurable ROI. However, digitalization initiatives often begin with drafting ideal diagrams in graphic editors based on subjective perceptions. This creates a dangerous illusion of control that collapses during actual system implementation.
The "ideal regulation" trap: why paper-based automation fails
Companies often attempt to automate processes based on theoretical descriptions, ignoring real bottlenecks and informal workarounds (shadow processes). When analysts interview managers, they describe the process as it is documented in job descriptions. However, the reality within corporate systems usually looks quite different.
Attempting to automate chaos without first identifying real deviations only preserves inefficiency. If a manual process contains unnecessary steps, function duplication, or artificial delays, transferring it to code will simply result in automated chaos that multiplies errors. Industry estimates show that only about 13% of companies are fully satisfied with their first wave of automation if it was launched solely based on subjective surveys. Conversely, using evidence-based analysis methods reduces the probability of errors in priority selection to 49%.
Analyzing event logs instead of surveys: how process mining reveals shadow processes
The only reliable source of truth regarding how an enterprise functions is the digital footprint left by information systems. Every user action in an ERP, CRM, or document management system is recorded in event logs. Process mining technology allows for the discovery of how a process is actually executed, as opposed to how it was documented, and identifies hidden workarounds (shadow processes).
A typical example from large organizations: process mining reveals that employees consistently ignore the official approval stage, creating a "shadow" route through personal messenger chats. The official system shows excellent KPIs because the document arrives there already approved, but the actual execution time is measured in weeks, and the main bottleneck remains invisible. Analyzing event logs allows for extracting real timestamps for each operation, identifying cyclical returns for rework, and precisely pinpointing where delays occur.
Divide and conquer: why BPMN 2.0.2 and DMN should work separately
For an automated process to be flexible, its architecture must rely on international standards. The BPMN 2.0.2 standard is officially published as the international standard ISO/IEC 19510:2013. It defines graphical notation and semantics for business process modeling. Using executable BPMN 2.0 models allows for simultaneously documenting and managing the process, ensuring visibility of each instance's state through a process engine (orchestration).
However, architects often make a mistake here: they try to "hardcode" decision logic directly into the process structure, creating cumbersome diagrams with dozens of branches. To solve this, the DMN (Decision Model and Notation) standard exists. Separating business decisions (DMN) from the process flow (BPMN) allows for changing decision rules without needing to redesign the entire process structure.
A real-world example: moving discount calculation or credit limit logic into DMN tables allows business analysts to update rules independently without involving developers to change the code. This significantly reduces maintenance costs during frequent internal policy changes.
To build such solutions, large enterprises use specialized low-code tools. For example, the low-code platform Scriptum allows for creating executable process models according to the BPMN 2.0 standard and separating decision logic via DMN. The solution is built on the UnityBase platform (a joint development of the Intecracy Group, an alliance of independent companies linked by partner agreements and share exchanges, where InBase is a key developer). UnityBase ensures high data processing speed due to an asynchronous non-blocking server and built-in ORM, which is critical for orchestrating long-running and high-load processes.
Readiness metrics: signals for choosing the first process to automate
Not every inefficient process should be automated first. To choose a starting point, processes must be evaluated based on several criteria. Processes with low execution frequency or those requiring constant creative intervention should be left out of the first implementation wave.
| Evaluation parameter | High readiness (Automate first) | Low readiness (Requires re-engineering) |
|---|---|---|
| Rule stability | Decision logic is static or easily described via DMN | Rules change chaotically and depend on subjective opinion |
| Standardization level | Process follows BPMN 2.0.2 without hidden deviations | Numerous shadow processes and workarounds detected |
| Data sources | Data is structured and contained in information system event logs | Data is unstructured, transmitted verbally or via personal messengers |
| ROI potential | High frequency of operations with measurable delays | Low frequency of unique operations with unpredictable results |
Calculating ROI: assessing financial impact before development begins
ROI assessment must be based on rigid operational metrics. The basic calculation formula is built on comparing the current cost of process execution with the projected cost after automation, taking into account development and maintenance expenses.
For accurate calculation, data from logs is used: the average duration of each step and the frequency of errors requiring rework. Using orchestration to track the state of long-running processes makes every step automated and transparent for management.
Automation does not guarantee a specific ROI percentage without considering the context and quality of input data. If data is unstructured, maintenance costs may exceed the positive effect. That is why the first step must be log analysis, identifying shadow processes, and building an architecture based on BPMN and DMN standards.
FAQ
How to identify shadow processes before starting automation?
Process mining technology is used, which analyzes digital footprints (event logs) in existing information systems (ERP, CRM, etc.). This allows you to see how the process is actually executed and identify hidden workarounds.
What is the difference between process modeling in BPMN and decision-making in DMN?
BPMN describes the sequence of steps and events (process flow). DMN focuses exclusively on business decision logic. Separating decision logic into DMN tables allows business analysts to update rules without involving developers to change the overall process structure in BPMN.
Which log metrics (event logs) are key for calculating potential ROI?
Key metrics include total process execution time, active processing time at each stage, and the frequency of returns for rework (rework rate). Analyzing this data helps compare the current process cost with the expected savings from automation.