Process Mining in Practice: Read Your Real Process from the Event Log and Run a First Pilot

Every company has a process chart on the wall: order comes in, gets approved, goes to production, ships, gets invoiced. Clean boxes, straight arrows. Then you ask why some orders take three days and others take three weeks, and nobody can really say. The real process lives somewhere else: in the timestamps your ERP and other systems record every day. Process mining is the way to read them.

In my 24 years in industry, a big part of my work has been mapping processes, and I'll be honest: the maps we drew in workshops were always a little too tidy. People describe the process as it should be, not as it happens. Process mining changes the conversation, because it starts from data that already exists instead of from opinions.

In this article I'll explain what process mining really is, walk through a small worked example with an event log you can rebuild in a spreadsheet, and give you a practical way to run a first pilot on a single process.

What process mining actually is

Process mining, a field developed largely by Wil van der Aalst and described in the IEEE Task Force's Process Mining Manifesto, uses event logs to discover, check and improve real processes. An event log only needs three things for each step:

• Case ID: which order, invoice or work order the step belongs to.
• Activity: what happened, for example "Order created" or "Credit check".
• Timestamp: when it happened.

Add a resource (who or which department did it) if you have it. With just these columns, a process mining tool draws the process as it really ran, counts every path (called a variant), and shows where time is lost. The manifesto describes three main uses: discovery (draw the real process), conformance checking (compare it with the intended one) and enhancement (add times, costs and bottlenecks to the map).

Worked example: one order-to-cash process, read from its event log

Here is a tiny event log for three customer orders. The data is an illustrative example, not from a real company.

Even three cases show the pattern. SO-101 and SO-103 follow the "happy path" and are invoiced in about three days. SO-102 has a price change after the credit check, which forces a second credit check, and the order takes 14 days. Now scale it up. Suppose, as an example, a full year's log has 4,000 orders and shows this:

Weighted average: 0.62 × 3.2 + 0.23 × 12.5 + 0.15 × 8.0 ≈ 6.0 days. If you removed most of the price-change loop, say cutting that variant from 23% to 5% of orders (moving the rest to the happy path), the average drops to about 0.80 × 3.2 + 0.05 × 12.5 + 0.15 × 8.0 ≈ 4.4 days. That's roughly 1.6 days faster cash for every order, without a new system, just by fixing the root cause of late price changes (for example, price agreed before the order is entered). For a company invoicing, say, 50 million a year, 1.6 days less is about 50,000,000 × 1.6 ÷ 365 ≈ 219,000 of cash freed once from working capital. Again, these are example numbers; the method is what matters.

How to run your first pilot, step by step

• Step 1 – Pick one process and one question. Order-to-cash, purchase-to-pay or work-order execution are good starts. Ask one thing, such as "Why do some orders take three times longer?"
• Step 2 – Extract the event log. Most ERP systems store status changes or document dates with timestamps. Export case ID, activity, timestamp and, if possible, resource for 6–12 months.
• Step 3 – Clean it. Fix time zones, remove test records, give activities consistent names. In my experience this step takes the most time, so plan for it.
• Step 4 – Discover the process. Load the log into a tool. The open-source PM4Py library for Python or a free academic tool is enough for a pilot; commercial platforms come later if the value is proven.
• Step 5 – Find the top two or three variants and the loops. Look for rework (activities that repeat), long waiting times between steps and paths that skip required checks.
• Step 6 – Go to the people. The data shows where; the people who do the work explain why. Then agree on one change and measure again after a month.

The payoff

The biggest change I expect from process mining is that arguments about the process end quickly. Instead of "I think approvals are slow", you see exactly which step waits, for how long and in what share of cases. Improvement projects become smaller and more targeted, and you can prove afterwards whether they worked by running the same analysis again. It also fits naturally with other work: a live operations dashboard can track the variants you care about, a capability map tells you which systems hold the logs, and the delays you find are often the same places where a bottleneck hides.

Checklist for your first process mining pilot

• Choose one process with a clear, measurable pain (lead time, rework, late payments).
• Write down one business question the pilot must answer.
• Confirm the ERP or other system records timestamps for the key steps.
• Export 6–12 months of case ID, activity, timestamp and resource.
• Clean activity names and time zones before analysis.
• Identify the top variants, the loops and the longest waits.
• Validate the findings with the people who run the process.
• Agree on one change, then re-run the analysis after a month.

Want to see how your own process really runs?

If you have a process where some cases fly through and others get stuck for weeks, I'd be glad to help. We can extract the event log from your system together, discover the real process, and turn the findings into one or two practical changes you can measure.

Contact me Read: the role of enterprise architecture

Sources

• IEEE Task Force on Process Mining. Process Mining Manifesto (2011): definitions of event logs, discovery, conformance checking and enhancement.
• Wil van der Aalst. Process Mining: Data Science in Action, 2nd edition, Springer, 2016.
• Fraunhofer FIT. PM4Py, an open-source process mining library for Python.