Predictive process monitoring (case delay & outcome prediction from event logs)

Process mining shows what went wrong last quarter; predictive process monitoring tells you which of today's open cases is about to go wrong. Models trained on historical event logs from ERP, CRM and workflow systems score every running sales order, purchase order, claim or permit application for remaining time, SLA-breach risk and outcome (rework, cancellation, rejection). At-risk cases land on a prioritised worklist with the reasons, or trigger an automated intervention — turning process analytics from a rear-view mirror into an early-warning system.

Problem & value

• Today: delays become visible only when a customer complains, a delivery date passes or an SLA is already breached. Process-mining dashboards and ERP reports are retrospective and need manual analysis; expediters chase "everything late-looking" instead of the cases that matter.
• AI value: case-level early warning (late sales orders, late supplier deliveries, claims breaching service levels, permit procedures exceeding statutory deadlines), prioritised worklists, and a basis for prescriptive actions (expedite, switch carrier, call supplier, escalate). Benefits are realised only when the prediction is wired into an action.
• Evidence: Celonis reports customer projects where Prediction Builder flags orders likely to be late so teams can intervene early, and estimates the probability that open sales opportunities slip to a later quarter [1]. Apromore offers runtime dashboards that estimate the outcome, remaining time and SLA risk of each open case, including from a live claims-management event stream [2]. Published vendor-independent ROI figures are scarce — measure your own baseline.

Variants

• Order-to-cash: late-delivery and partial-delivery risk per sales-order item; credit block or invoice-dispute risk; links to collections prioritisation (PRED-021).
• Procure-to-pay: supplier late-delivery risk per purchase-order line (the SAP S/4HANA embedded-ML "predicted delivery delay" type of scenario), late-invoice or blocked-payment risk.
• Insurance & banking: claim cycle-time and SLA breach, KYC/loan-application throughput, likelihood of rework loops or customer abandonment.
• IT service management / customer service: ticket resolution time and reopen risk (complements AGENT-016).
• Public sector: permit and benefit procedures (Bauantrag, Elterngeld, OZG services) — predicting which applications will exceed statutory processing deadlines and why.
• Manufacturing order flow: production-order lead-time prediction across MES/ERP events (physical transport ETA is PRED-018; project schedules are PRED-023).
• SMB: usually via the predictive module of a process-mining or ERP vendor rather than own models.

How it works

1. ERP/CRM/workflow tables
2. event-log extraction (XES / OCEL 2.0, object-centric)
3. historical cases: prefix generation + labelling (remaining time, late yes/no, outcome)
4. feature encoding (last state, aggregated counts, durations, case/object attributes, inter-case context: queue length, workload, supplier history)
5. model training (GBDT / survival model / LSTM-transformer), calibration, validation by time split
6. live event stream
7. per-case scoring on every new event
8. explanation (SHAP top drivers, optional LLM narrative)
9. worklist / alert / workflow or agent trigger
10. human decision
11. outcome feedback

• Prediction tasks: outcome classification (late, rework, cancelled, rejected), regression or survival analysis for remaining time, sequence prediction for next activity and timestamp.
• Encoding matters more than model: the academic benchmark by Teinemaa et al. compared eleven outcome-oriented methods on 24 tasks from nine real event logs and showed that prefix bucketing and encoding choices drive results [3]; gradient-boosted trees on aggregated prefix features remain strong, cheap baselines.
• Prescriptive layer: uplift / causal models estimate whether an intervention (expedite, phone call) actually changes the outcome, avoiding wasted effort on cases that would recover anyway.
• Human-in-the-loop: predictions create worklists and recommendations; humans (or tightly scoped agents with approval) decide on interventions. Feedback on actions taken is logged so that later models do not learn from their own interventions blindly.

Data preparation

Predictive process monitoring needs an event log: for every case an ID, an activity name, a timestamp and optionally a resource and attributes such as value or customer type. The raw material sits in ERP tables (SAP, Dynamics), ticketing or workflow tools, CRM and sometimes mail or paper-based steps. Typical gaps are missing case IDs across systems, timestamps that record posting rather than real work, manual steps that leave no trace, and activities named differently per department.

Preparation steps: pick one process and one case definition, then extract the event log with standard connectors (PREP-005), harmonise activity names via a glossary (PREP-012), digitise paper steps where they matter (PREP-008), label outcomes such as "finished late" from closed cases (PREP-020), and pseudonymise user IDs before analysis (PREP-022). Agree what may be analysed with PREP-024.

Rough share of effort: 50 to 60 percent of the project, since event-log building is the hard part. Several thousand completed cases are a useful minimum. See GUIDE-003 for a readiness check.

Implementation paths

Which path for whom

• SMB: Path A. With a standard ERP, process-mining products offer ready connectors and dashboards at manageable prices, and the process itself is standard.
• Enterprise: Path B. Process data is core and volumes make seat costs high, so building prediction on your own event logs via APIs or an internal platform scales better.
• Developer: Path C. The open-source PM4Py library and standard ML packages run on HW1 and give full control over event-log handling.
• Public: Path C. Case data of citizens and staff is sensitive and procurement rules favour sovereign, self-hosted operation.

Path A — Buy (recommended for most SMBs and enterprises with standard ERP)

• Process-intelligence platforms with prediction: Celonis (DE, Munich; Prediction Builder, Annotation Builder, action flows) [1]; SAP Signavio Process Intelligence (DE; AI-assisted root cause analysis, generative-AI Q&A, what-if simulation) [4]; Apromore (predictive monitoring add-on with training and runtime modules) [2]; IBM Process Mining (SaaS on AWS or on-premises on Red Hat OpenShift) [5]; further options include ARIS Process Mining (DE), mpmX (DE), UiPath Process Mining, Microsoft Power Automate Process Mining and ServiceNow Process Mining.
• ERP-embedded: SAP S/4HANA intelligent scenarios (embedded ML for delivery-delay prediction on purchase orders), Pega Process AI for case-management SLAs.
• Choose A when: the process runs in a mainstream ERP with standard connectors, a process-mining programme exists or is planned, and on-prem is not mandatory (or IBM/ARIS on-prem options fit).

Path B — Build on cloud APIs

• Data & ML platform: Databricks, Snowflake, Azure Machine Learning, Google Vertex AI or AWS SageMaker in EU regions; STACKIT (DE) or IONOS (DE) for sovereign hosting of the ML stack.
• Modelling: AutoML for tabular/time-to-event targets (Vertex AI Tabular, Azure AutoML) or managed XGBoost/LightGBM; event extraction via SAP Datasphere / Fabric pipelines.
• LLM layer (optional): an EU-hosted LLM (Mistral, or Claude/GPT/Gemini via EU-region endpoints) turns SHAP drivers into a readable explanation and drafts the intervention message; an agent framework with MCP tools can open the ERP transaction or write to the supplier, behind approval steps.
• Choose B when: processes span several systems, you need own targets/features, and a data platform already exists.

Path C — Self-host (open source)

• Event logs & process mining: PM4Py (Python; AGPL-3.0 or commercial licence; from a Fraunhofer FIT spin-off; supports OCEL) [6]; logs in IEEE XES [7] or OCEL 2.0 [8].
• Predictive monitoring tooling: Nirdizati (predict-python research web application, MIT licence) [9]; scikit-learn, XGBoost/LightGBM/CatBoost, scikit-survival/lifelines for survival models, PyTorch for LSTM/transformer sequence models (e.g. ProcessTransformer [10]); SHAP for explanations; MLflow for model registry.
• Streaming & integration: Debezium CDC from ERP databases → Apache Kafka / Flink for per-event scoring; n8n or Camunda to route alerts and interventions.
• Hardware: HW1 is sufficient — gradient-boosted models train and score on CPU servers even for millions of events. Add HW2 only if you run a local LLM (e.g. Mistral Small or Qwen3 class via vLLM) for explanations or agentic follow-up, or train large transformer models.
• Tabular foundation models: TabPFN (Prior Labs, DE) can give strong small-data baselines, but note that recent weights (2.5 and later) carry non-commercial licences unless an enterprise licence is bought [11].

Path D — Custom training

Custom models are the norm in Path C anyway; "custom training" here means investing in sequence/transformer or object-centric graph models, inter-case features and causal (prescriptive) models. Worth it when you have long, highly variable processes with many interacting objects (orders, deliveries, invoices) and >10k completed cases per process, or when you sell the capability as a product. Fine-tuning LLMs on traces is an active research topic but not yet proven to beat well-engineered tabular models in production.

State of the art (2026)

• Benchmarks: classic reviews and benchmarks cover outcome prediction (eleven methods, nine logs [3]), remaining-time prediction [12] and deep learning (ten approaches on twelve public logs [13]). ProcessTransformer reported about 80% average next-activity accuracy on nine real logs [10]. Public BPI Challenge logs (financial, purchase-order and travel-expense processes) remain the standard test sets [14].
• What changed recently: move from single-case-notion logs to object-centric event logs (OCEL 2.0), which represent orders, items, deliveries and invoices together and avoid the distortions of flattening [8]; commercial platforms embed prediction plus "action flows" and LLM agents that act on predictions [1]; tabular foundation models offer zero-training baselines.
• Practical best practice: gradient-boosted trees with aggregated prefix encoding and inter-case features, temporal train/test split, probability calibration, and an uplift model for intervention choice.
• Limits & failure modes: concept drift after process changes or ERP releases; label leakage (using attributes only known at case end); feedback loops when interventions change outcomes; poor early-prefix accuracy (predictions sharpen as cases progress); data-quality issues in event extraction (missing timestamps, batch postings). Benchmarks on public logs overstate accuracy for messy real ERP data.

Shared resources & combinations

• Same event-log pipeline: DATA-013 process & task mining (descriptive layer — build once, use for both), AGENT-018 continuous controls monitoring, DATA-008 data-quality monitoring.
• Same tabular-ml stack (CPU, HW1): PRED-021 payment behaviour, PRED-023 project overrun, PRED-003 churn, PRED-011 workload forecasting (case-volume forecasts feed inter-case features), PRED-016 cash-flow (expected payment dates from O2C predictions).
• Downstream actions: AGENT-004 order entry, AGENT-005 procurement agent (supplier chasing), AGENT-023 order-to-cash agent, AGENT-014 claims handling, AGENT-016 ITSM, AGENT-026 public-administration case processing — predictions decide which cases these agents touch first.
• Physical ETA: PRED-018 adds transport-level ETA for the shipping leg of an O2C case.
• Shared building blocks: CDC/Kafka streaming, feature store, MLflow, one optional HW2 GPU for a local LLM shared with other LLM use cases.

Effort, cost & KPIs

• Path A: 2–4 months when a process-mining data model already exists; licence cost scales with events/processes/users (IBM lists its on-prem platform from USD 2,885/month for 20 million events [5]); Celonis/Signavio are enterprise-priced.
• Path B/C: 3–6 months for the first process (event extraction is typically the largest effort), then weeks per additional process; infrastructure cost is low (CPU).
• Cost drivers: event-log extraction and data quality, integration of alerts into worklists, change management for intervention teams, model monitoring for drift.
• KPIs: AUC / Brier score and calibration by prefix length; MAE of remaining-time prediction; earliness (how many days ahead risk is flagged); share of at-risk cases acted on; on-time delivery / SLA-compliance rate; average cycle time; cost of expediting per saved case.

People & change

Start with management and the process owner (department lead), who must name one process and a business goal such as fewer late orders. Involve IT and data owners early for the log extraction and access rights, and IT security if logs leave the company. Event logs record who did what and when, so the data protection officer must be involved from the beginning: a legal basis, an AVV with any vendor and, because staff behaviour is systematically evaluated, probably a DPIA.

Works council: yes. Event logs with resource information are objectively suitable to monitor behaviour or performance, so §87(1) no. 6 BetrVG applies as the Federal Labour Court (BAG) accepts objective suitability; §90(1) no. 3 and, if needed, §80(3) (expert) support early involvement. Conclude a works agreement that limits analysis to process level and excludes individual performance evaluation. Public bodies involve the Personalrat.

Pilot with one process and one team, with pseudonymised resources, and share findings openly with the team. Typical concerns are surveillance and job loss. Address them by analysing cases rather than people, publishing the purpose, and keeping decisions on interventions with humans. Offer AI literacy training (AI Act Art. 4). See GUIDE-004, GUIDE-005 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: for order, purchase-order and logistics processes the use is minimal risk (AI literacy duty, Art. 4). Classification becomes high risk if predictions are used to evaluate employee performance or allocate tasks based on personal behaviour (Annex III 4(b)), to evaluate eligibility for public assistance benefits or services (Annex III 5(a)), or to assess creditworthiness of natural persons (Annex III 5(b)) [15]. Predicting process delay of a benefits application to prioritise work is arguably outside 5(a) as long as it does not influence the eligibility decision — document this Art. 6(3) reasoning. Hence depends.
• GDPR & employee data: event logs contain user IDs of clerks (the "resource" attribute) and often customer data. Pseudonymise or drop resource IDs unless needed; in Germany, the works council has co-determination rights over technical systems suitable for monitoring employees (§87(1) no. 6 BetrVG) and §26 BDSG applies — conclude a works agreement before go-live. Data processing agreements and EU hosting for SaaS.
• Public sector: respect administrative-procedure law (no automated decisions without legal basis, §35a VwVfG), transparency to applicants where predictions affect handling order.
• Sector rules: DORA ICT third-party risk if a bank uses SaaS process-intelligence for critical processes; GoBD if predictions feed bookkeeping-relevant processes.
• Mitigations: time-split validation, drift monitoring, intervention logging, explanations per alert, no automated adverse decisions on persons.

Getting started

1. Pick one process with a clear, costly "bad outcome" (e.g. late sales-order delivery or supplier delay) and at least a year of history in the ERP.
2. Extract an event log (or reuse your process-mining data model) and define the label and the decision point at which a prediction would still allow action.
3. Build a baseline: gradient-boosted model on prefix features with a temporal split; measure accuracy by prefix length and earliness — or run a vendor PoC (Path A) on the same data.
4. Design the intervention: who receives the worklist, what they can do, and how actions are logged; involve the works council and DPO early.
5. Pilot for 2–3 months with a control group, then measure on-time rate and cycle time before scaling.

Sources

1. Celonis — Innovation in action: real-world solutions from Celonis AI Lab in the Bay Area — https://www.celonis.com/blog/innovation-in-action-real-world-solutions-from-celonis-ai-lab-in-the-bay-area
2. Apromore — Predictive process monitoring — https://apromore.com/predictive-process-monitoring
3. Teinemaa, Dumas, La Rosa, Maggi — Outcome-Oriented Predictive Process Monitoring: Review and Benchmark (ACM TKDD) — https://arxiv.org/abs/1707.06766
4. SAP Signavio — Process Intelligence — https://www.signavio.com/products/process-intelligence/
5. IBM — IBM Process Mining (product and pricing) — https://www.ibm.com/products/process-mining
6. PM4Py — process mining library for Python — https://github.com/process-intelligence-solutions/pm4py
7. IEEE Task Force on Process Mining — XES standard — https://www.tf-pm.org/resources/xes-standard
8. OCEL 2.0 — Object-centric event log standard — https://www.ocel-standard.org/
9. Nirdizati — predict-python — https://github.com/nirdizati-research/predict-python
10. Bukhsh, Saeed, Dijkman — ProcessTransformer: Predictive Business Process Monitoring with Transformer Network — https://arxiv.org/abs/2104.00721
11. Prior Labs — TabPFN — https://github.com/PriorLabs/TabPFN
12. Verenich et al. — Survey and cross-benchmark comparison of remaining time prediction methods in business process monitoring — https://arxiv.org/abs/1805.02896
13. Rama-Maneiro, Vidal, Lama — Deep Learning for Predictive Business Process Monitoring: Review and Benchmark — https://arxiv.org/abs/2009.13251
14. IEEE Task Force on Process Mining — BPI Challenge — https://www.tf-pm.org/competitions-awards/bpi-challenge
15. Regulation (EU) 2024/1689 (AI Act), Annex III — https://artificialintelligenceact.eu/annex/3/