Process Mining and Process Modeling in One Loop

The Model Is the Yardstick

Process models lose value when design and reality drift apart. Closing the loop between process modeling, process mining and conformance checking turns the model from documentation into a measurable standard for improvement.

Ask a process owner when their as-is process model was last accurate, and watch the pause.

It was accurate on the day it was approved. The owners were named, the version was signed off, the diagram went up on the intranet. Then the business kept moving. A system was replaced. A step was added to keep an auditor happy. Someone found a quicker way around an approval, and within a month everyone was using it.

The model stayed where it was. Nobody decided to let it go stale; it simply stopped keeping up. Six months later someone opens it to plan a change and finds a careful, well-drawn picture of a company that no longer exists.

Design and reality live in different houses

It is tempting to call this a discipline problem: if people simply updated their models, the models would be right. But the process teams we work with rarely lack discipline. What they lack is a way to see the gap.

In most mature organizations, process work is split in two. One team looks at what actually happens, usually through process mining. They pull data from systems such as SAP and rebuild the real flow of work: the variations, the waiting times, the rework, the places where cases pile up. Another team looks after what should happen: the target processes, the architecture, the owners and the controls.

Both teams do valuable work, and both usually have a budget. What nobody owns is the space between them. Comparing the model with reality means someone doing it by hand, in a spreadsheet or a workshop. So it happens once a year, or just before an audit, or not at all.
Plenty of organizations have only one of the two. Some keep a careful process library with no data behind it; others run process mining with nothing to measure the findings against. That is not a weaker place to start. It means the connection can be built in from day one, instead of being retrofitted between two teams that have learned to work apart.

The cost is easy to miss because it never appears as a line item. Models go out of date the day the process changes. Skilled architects and analysts spend their weeks translating between tools. And when analysis does find something worth fixing, the finding has to be carried across to the design side by hand. That hand-off is where most of the value quietly leaks away.

Closing the loop between process mining and process modeling

The usual answer is an integration project: connect tool A to tool B and hope the data stays in sync. That treats the symptom. The better answer is to change the shape of the work.

Picture a loop rather than two separate jobs. In closed-loop process intelligence, the model you design is the yardstick, process mining shows what actually happens, and conformance checking measures the gap between the two. What you learn then improves either the process or the model, and the updated model becomes the yardstick for the next round.

In QPR's products the loop is built in rather than bolted on. QPR EnterpriseArchitect holds the designed side: capabilities, process models, the application landscape and who owns what.

QPR ProcessAnalyzer shows the real side, rebuilt from data your systems already record.
The two work on the same process diagrams. A flow discovered in the data can be saved straight into the architecture repository as a model. A model drawn by an architect can be opened in ProcessAnalyzer and checked against what actually happened. Either team can edit the same diagram in its own tool.

Because both products share one repository and one way of describing processes, nothing has to be exported, reshaped and loaded back in between vendors. There is no translation tax, and nobody whose job is to pay it.

Conformance checking: measuring design against reality

A loop is only worth closing if it produces numbers someone can act on. This is where conformance checking earns its place.

You choose a model as the reference for how the process should run. Actual execution can then be compared against that model, showing where cases conform, where they deviate and how those deviations affect performance. When a step is skipped or done twice, you see not only that it happened but how much longer those cases took.

The reference model does not need to be perfect to begin with. You can draw it, import one you already have, or let the system propose a baseline from the paths your cases actually took. The most common checks come ready to use: whether service levels were met, whether steps happened in the right order (invoicing before delivery is the classic), and whether decisions that need two people really had two.

QPR also tracks the conformance rate over time: the share of cases that follow the design, and how much longer the deviating ones take. That matters more than it might seem. “People aren’t following the process” is difficult to manage. A measurable gap between design and execution is different: it can be tracked over time, assigned to an owner and tied to an improvement target.

Metsä Board shows what this looks like in practice. When the company analyzed its order-to-cash process from SAP data, only 40% of order lines followed the defined process. The system was not the problem; the process simply was not being followed consistently. Instead of paying for SAP changes, Metsä Board focused on how people worked, raised conformance to 80% and grew order line volume by 60% without adding headcount. In loop terms, the model was right and reality had to move.

Why the loop is practical now

For years the closed loop was something you drew on a strategy slide. Two changes have turned it into something you can run.

The first is who gets to take part. Process modeling used to mean specialist software installed on an expert’s laptop. In QPR EnterpriseArchitect, full process modeling now also runs in the browser, straight from the shared repository. The people who actually do the work can help keep the model current, instead of sending requests to the one person with a licence.

The second is a shared language. Both products read and write process models in BPMN, the industry-standard format. The diagram the architects maintain is exactly the diagram that conformance checking runs against. No copies, and no versions slowly drifting apart.
Put together, the loop now runs on open standards, in a browser, against live data.

Where to start on Monday

If you recognize the drift in your own organization, or have only one half of the loop today, the first step is not choosing a platform. It is choosing a process.

1. Pick one end-to-end process that already has reliable data in your systems and a named owner.

2. Set the baseline. Use the model you already have, or generate one from the paths your cases actually take.

3. Switch on conformance checking and look at where cases deviate and what those deviations cost.

4. Update the model where reality has legitimately moved on. Where it hasn’t, you now have the evidence to act.

Get one process running end to end. Then let the loop keep it current, and add the next one.

A drawing or a yardstick

The value of process intelligence was never just the ability to analyze processes. It is that analysis and design stop being two separate jobs with a manual hand-off in the middle. The real gain is removing the point where insight has to be translated, transferred and reconstructed before anyone can act on it.

A model that is never compared with reality is a drawing. A model compared with reality every month is a yardstick. What separates the two is not the software. It is whether anyone has closed the loop.

FAQ

What is the difference between process mining and process modeling?
Process modeling describes how a process is designed or intended to work. Process mining reconstructs how the process actually runs from operational event data. Used together, the model provides the reference point and process mining shows where real execution follows it or deviates from it.

What is conformance checking in process mining?
Conformance checking compares actual process execution with a reference process model. It identifies where cases follow the intended process, where they deviate and how those deviations affect outcomes such as lead time, compliance or rework.

Why do process models become outdated?
Processes change continuously as systems, responsibilities, controls and working practices evolve. If the process model is maintained separately from operational data, these changes may not reach the model until somebody updates it by hand. Connecting process modeling with actual execution makes that drift easier to detect.

How can process mining and BPMN be used together?
A BPMN model describes the intended process in a standard notation. Process mining can use that model as the reference for conformance checking, and process flows discovered in the data can in turn be saved as BPMN to update the model. Because both sides use the same standard, the model and the analysis stay in step.