How Far Off Are Process Diagrams from Actual Processes? —— A Five-Step Method to Reveal the Truth Using Process Mining from System Logs

Conclusion first: The difference between the process diagrams most companies draw and the actual processes running in their systems is between 30% and 60%.

This figure is not an estimate. By pulling out the operation logs from ERP, MES, OA, and work order systems and stringing them together as "a business object from initiation to completion," you will see dozens or even hundreds of different paths—while the process diagram usually shows only one.

The most difficult statement for a COO to accept is: "The process you think exists is a policy, the actual process is a habit." The process diagram represents "how it should be done," while the logs show "how it is actually done." The gap between these two is the first thing that process digitalization aims to address.

Why Process Diagrams Are Inherently Unreliable

It's not that no one draws them, but once drawn, they are bound to be inaccurate. There are three structural reasons:

First, the diagram is an ideal state, while the actual process is an exception state. The person who draws the process diagram is doing "standard design," while the person who executes it is dealing with "special cases every day." Exceptional paths do not make it into the diagram—because if they did, they would need to be explained, and explaining them would mean admitting that the standard is not applicable.

Second, the approval chain only grows, never shrinks. Adding an approval node requires just one meeting, but removing one can offend someone. Over three years, the number of approval steps can increase from 4 to 11, while the process diagram remains the same as it was three years ago.

Third, the system and the process are two separate accounts. Process documents are stored in the shared drive of executives, while actual constraints are in the system configuration. Changing the process does not always mean changing the system, and changing the system even less often means updating the process documents.

So, don't waste time trying to "get the process diagram right"—acknowledge that it is inaccurate and use the logs to measure.

What Process Mining Essentially Does

Convert system logs into "process paths," and then count how many times each path has been taken.

Technically, it involves three elements:

With these three columns, the "sequence of activities a case goes through, sorted by time," forms a path. The frequency of each path's occurrence represents the actual distribution of the process.

It sounds simple, but the real challenges lie in the following five steps.

Five-Step Method

Step 1: Select the Process and Define Case Boundaries

Focus on one process, not the entire factory. It is recommended to choose from two options: Order to Delivery (OTD) or Purchase Request to Warehouse Entry.

The most overlooked aspect when defining a case is the start and end points. The choice of the starting point can directly affect the conclusion:

• Start from "receiving the order" or "contract review approval"?—If you start from the former, you will include the internal sales waiting time in the delivery cycle, which can be a stark but factual conclusion.
• End at "shipping" or "customer sign-off"?—The former can mask issues in the logistics phase.

Criterion: The start and end points must align with the questions you want to answer. To answer "why is delivery slow," you must calculate from order acceptance to customer sign-off, without cutting any part.

Step 2: Extract Logs

Three essential fields: case key, activity name, and timestamp. Four highly recommended fields: operator/position, values before and after status changes, document type, and whether there was manual intervention.

Common data sources:

| System | Available Logs | |---|---|---| | ERP | Document status change history, approval flow records | | MES | Work order reporting, process station passing, rework records | | OA | Approval node pass/reject times | | Email/IM | Informal communications (hardest to obtain, but often the real bottlenecks) |

The most easily overlooked part is the offline steps—visiting customers, waiting for drawings, waiting for sample inspections. These are not recorded in any system but often take up the majority of the cycle. Handling method: Start with a purely system-based process, run a version; then add 3-5 offline milestones (filled in by the parties involved on a daily basis), don't try to add all of them.

Step 3: Data Cleaning

This step can determine the success or failure of the entire project, yet it is often skipped.

Four essential cleaning tasks:

1. Merge activities with the same name: The same action may have multiple expressions in the system (e.g., "review approved," "approval completed," "verified"), which must be unified.
2. Standardize time zones and formats: Inconsistent timestamp formats across multiple systems are common, especially in factories spanning different time zones, where an 8-hour discrepancy can easily occur.
3. Identify and handle backdating: Records that are backdated (e.g., concentrated at the end of the month, batch-entered on the same day) cannot be used as actual occurrence times. They should either be removed or marked separately.
4. Mark rework paths: If a case passes through the same activity multiple times, it should be marked as rework, not as part of the normal path.

Criterion: After cleaning, the time series of any case must be strictly monotonically increasing. If there is a time regression, it indicates backdating or system time discrepancies, and this data cannot be directly used for analysis.

Step 4: Reconstruct Paths and Analyze Distribution

Don't rush to create beautiful Sankey diagrams. Start by looking at three numbers:

1. Number of path variants: How many different sequences of activities have appeared in this process?
2. Main path proportion: What percentage of all cases does the most frequently occurring path represent?
3. Length of the long tail: How many paths are needed to cover 80% of the cases?

An empirical benchmark (not absolute, but useful for reference):

A main path proportion below 40% means: This company does not have a "standard process," only "different handling methods each time." In such a case, implementing a BPM system first is a waste of money—the system will solidify a non-existent standard.

Step 5: Quantify the Gap and Identify the True Bottlenecks

Only at this point can you say "there is a problem with the process." Provide four numbers, each of which must be calculable:

① Number of approval steps and cumulative waiting time

Break down the "dwell time" of each case into two parts: processing time (when someone is actually working) and waiting time (when the document is idle). A typical result is that waiting time accounts for 80% to 95%.

② Rework rate

Rework = the same case passing through the same activity multiple times. For processes with a rework rate exceeding 15%, address the rework first before discussing cycle optimization.

③ First-time-through rate (FTT)

The proportion of cases that complete the process without rejection, modification, or resubmission. This metric is much more honest than "timeliness."

④ The bottleneck is not where you think it is

Sort the cumulative waiting time for each activity. The top three activities are the true bottlenecks. Empirically, the top one is often not the busiest department, but rather a place "waiting for a signature" or "waiting for a confirmation."

Three Common Pitfalls

Pitfall 1: Turning process mining into log visualization. Pulling out a bunch of beautiful process diagrams and heat maps, but no one can answer "so where should we make changes?" The compliance definition is: each conclusion must be specific to a particular activity + an executable change.

Pitfall 2: Focusing only on the main path, ignoring the long tail. The main path accounts for 65%, which looks healthy; but the remaining 35% of cases consume 70% of overtime. The long tail is the major cost, while the main path is just the most efficient part vouching for the entire process.

Pitfall 3: Calculating only processing time, not waiting time. Optimizing processing time by 20% is impressive, but if waiting time accounts for 85%, the improvement in delivery cycle is less than 3%. Cut waiting time first, then improve efficiency—reversing this order will result in a poor return on investment.

Practical Advice: Run Through One Process in Two Weeks

Here is a timetable you can follow:

The step from Day 9-10 cannot be skipped. Ask stakeholders why a particular case was delayed in finance for 6 days using the log conclusions. The answers you get will often overturn your previous assumptions and provide insights you can never get from the system alone.

In a Nutshell

Process digitalization is not about first drawing an accurate process diagram and then implementing the system, but about first using system logs to reveal the actual process, and then deciding which steps to cut and which to automate. Skipping the measurement and directly implementing the system means solidifying a non-existent standard process into the software—this is the most common reason such projects fail.

This article belongs to the "Digitalization and AI Zone · Process Digitalization" section. The accompanying process mining data extraction checklist and path variant statistics template are being organized and can be viewed in the resource library.

Knowledge code: 16.1.1 Author: QTank Version: v20261026