Predictive process monitoring

What is predictive process monitoring?

Predictive process monitoring looks at a case while it is still running and estimates how it is likely to end. It reads the events recorded so far, adds what is known about the case and its context, and produces a forecast that can be refreshed every time a new event arrives.

The part of the case seen so far is called a prefix. After each new step the prefix grows and the prediction can be updated. Common targets are the final outcome, the next activity, the remaining throughput time, or the chance that something unwanted happens before the case closes.

The technique sits on top of process mining. Instead of studying finished cases after the fact, it uses the same event data to make live predictions about work in progress. The order and timing of activities carry real signal here, not just a flat row of attributes.

What it predicts

Most work falls into three groups.

Outcome prediction estimates a final result, such as on time versus late, approved versus rejected, or whether a case will need rework.

Next-activity prediction estimates which step is likely to come next. Chaining these forecasts can sketch a possible path to the end of the case, but the uncertainty adds up with every step, so a long predicted sequence is less reliable than the next step alone.

Remaining-time prediction estimates how much longer a case will take. A single average hides how wide the spread is, so a range or a set of quantiles is usually more useful for planning than one number.

From event log to training data

The model learns from historical cases that have already finished. Each completed case is cut at several points, and every prefix becomes a training example paired with the value you want to predict, for example the time that actually remained from that point onward.

The prefix then has to be turned into something a model can read. Options range from simple aggregations of what has happened so far, to the last recorded state, to sequence models that process the event order directly. Recurrent networks and transformers are common when the sequence itself matters.

Case attributes such as customer type or product can help. So can dynamic attributes that change during the case, like the open amount, the number of handovers, or the time since the last event.

An example from customer service

A service team wants to spot tickets that are likely to blow past their agreed resolution time. Right after a ticket is logged there is little to go on. Once it has been classified, given a first diagnosis, and passed to a second team, the prediction sharpens.

The model returns a probability of breaching the deadline and a band for the time still needed. A planner can also see which facts pushed the prediction in that direction.

The score is not used to escalate every risky ticket automatically. The team first checks which action would actually help. An extra handover, for instance, can lengthen the wait rather than shorten it.

How it differs from ordinary predictive analytics

A classic predictive analytics model usually works from one snapshot per customer, order, or file. Predictive process monitoring works from the running history and can issue a fresh prediction after every event.

Because of that, one model rarely performs equally well at every prefix length. Early predictions are useful for acting in time but carry more uncertainty. Late predictions are sharper but leave less room to change the outcome.

Evaluation has to reflect this. Report accuracy per process stage or prefix length, not only a single overall score.

Avoiding data leakage

Data leakage happens when the training data contains information that would not be available at the moment of prediction. A closing code, a final invoice status, or an amount that was corrected later can make the model look far better than it will be in practice.

Split training and test data by time so future cases cannot slip into training indirectly, and keep every event from the same case on the same side of the split. Watch for fields that quietly reveal the outcome: a column may exist technically but only get filled in reliably after the decision has already been made.

What to watch out for with predictive process monitoring

Processes drift. Policy, seasonality, systems, and staffing all change how work flows, so measure data drift, calibration, and performance per segment after go-live, not just once during the build.

Calibration matters more than a single accuracy figure. A well-calibrated probability of 0.7 means that similar predictions come true about seven times out of ten. Without calibration it is hard to defend where you set a risk threshold.

Interventions change the data. If every high-risk case gets extra help, their good endings can make the original risk score look wrong, which then teaches the next model the wrong lesson. Log the prediction, the information available at the time, the action taken, and the result as separate facts.

Beat a simple baseline first. Compare against something plain, such as the average remaining time for the current activity. A complex model that barely improves on that baseline may cost more to run and explain than it is worth.