Prädiktives Prozessmonitoring (Vorhersage von Verzug und Ergebnis einzelner Vorgänge aus Ereignisprotokollen)

Process Mining zeigt, was im letzten Quartal schiefgelaufen ist; prädiktives Prozessmonitoring sagt Ihnen, welcher der heute offenen Vorgänge gleich schiefzugehen droht. Modelle, die auf historischen Ereignisprotokollen aus ERP-, CRM- und Workflow-Systemen trainiert wurden, bewerten jeden laufenden Kundenauftrag, jede Bestellung, jeden Schadenfall oder jeden Genehmigungsantrag nach Restzeit, SLA-Verletzungsrisiko und Ergebnis (Nacharbeit, Stornierung, Ablehnung). Gefährdete Vorgänge landen mit den Gründen auf einer priorisierten Arbeitsliste oder lösen eine automatisierte Maßnahme aus — so wird die Prozessanalyse vom Blick in den Rückspiegel zu einem Frühwarnsystem.

Problem & Nutzen

• Heute: Verzögerungen werden erst sichtbar, wenn sich ein Kunde beschwert, ein Liefertermin verstrichen ist oder eine SLA bereits verletzt wurde. Process-Mining-Dashboards und ERP-Berichte blicken zurück und erfordern manuelle Analyse; Terminverfolger jagen „allem, was verspätet aussieht", statt den Vorgängen, auf die es ankommt.
• KI-Nutzen: Frühwarnung auf Vorgangsebene (verspätete Kundenaufträge, verspätete Lieferantenlieferungen, Schadenfälle, die Service-Level verletzen, Genehmigungsverfahren, die gesetzliche Fristen überschreiten), priorisierte Arbeitslisten und eine Grundlage für präskriptive Maßnahmen (beschleunigen, Spediteur wechseln, Lieferanten anrufen, eskalieren). Der Nutzen entsteht nur, wenn die Prognose an eine Maßnahme gekoppelt ist.
• Belege: Celonis berichtet von Kundenprojekten, in denen der Prediction Builder Aufträge markiert, die voraussichtlich verspätet sind, damit Teams früh eingreifen können, und schätzt die Wahrscheinlichkeit, dass offene Vertriebs- chancen in ein späteres Quartal rutschen [1]. Apromore bietet Laufzeit-Dashboards, die Ergebnis, Restzeit und SLA-Risiko jedes offenen Vorgangs schätzen, auch aus einem Live-Ereignisstrom der Schadenbearbeitung [2]. Veröffentlichte, herstellerunabhängige ROI-Zahlen sind selten — messen Sie Ihre eigene Ausgangslage.

Varianten

• Order-to-Cash: Risiko verspäteter und teilweiser Lieferung je Kundenauftragsposition; Risiko von Kreditsperre oder Rechnungsstreit; Verknüpfung mit der Priorisierung im Forderungsmanagement (PRED-021).
• Procure-to-Pay: Risiko verspäteter Lieferung je Bestellposition (das Szenario „prognostizierte Lieferverzögerung" mit eingebettetem ML in SAP S/4HANA), Risiko verspäteter Rechnungen oder gesperrter Zahlungen.
• Versicherung & Bankwesen: Bearbeitungsdauer von Schadenfällen und SLA-Verletzung, Durchsatz bei KYC-/Kreditanträgen, Wahrscheinlichkeit von Nacharbeitsschleifen oder Abbruch durch den Kunden.
• IT-Service-Management / Kundenservice: Lösungszeit von Tickets und Risiko der Wiedereröffnung (ergänzt AGENT-016).
• Öffentlicher Sektor: Genehmigungs- und Leistungsverfahren (Bauantrag, Elterngeld, OZG-Leistungen) — Vorhersage, welche Anträge gesetzliche Bearbeitungsfristen überschreiten werden und warum.
• Fertigungsauftragsfluss: Vorhersage der Durchlaufzeit von Fertigungsaufträgen über MES-/ERP-Ereignisse (die physische Transport-ETA ist PRED-018; Projektterminpläne sind PRED-023).
• KMU: meist über das Prognosemodul eines Process-Mining- oder ERP-Anbieters statt über eigene Modelle.

So funktioniert es

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

• Prognoseaufgaben: Klassifikation des Ergebnisses (verspätet, Nacharbeit, storniert, abgelehnt), Regression oder Überlebenszeitanalyse für die Restzeit, Sequenzvorhersage für nächste Aktivität und Zeitstempel.
• Die Kodierung zählt mehr als das Modell: Der akademische Benchmark von Teinemaa et al. verglich elf ergebnisorientierte Methoden an 24 Aufgaben aus neun realen Ereignisprotokollen und zeigte, dass die Wahl von Präfix- Gruppierung und Kodierung die Ergebnisse bestimmt [3]; Gradient-Boosted Trees auf aggregierten Präfix- Merkmalen bleiben starke, günstige Basislinien.
• Präskriptive Schicht: Uplift- bzw. Kausalmodelle schätzen, ob eine Maßnahme (beschleunigen, Anruf) das Ergebnis tatsächlich verändert, und vermeiden vergeudeten Aufwand bei Vorgängen, die sich ohnehin erholen würden.
• Mensch-in-der-Schleife (Human-in-the-Loop): Prognosen erzeugen Arbeitslisten und Empfehlungen; Menschen (oder eng umrissene Agenten mit Freigabe) entscheiden über Maßnahmen. Rückmeldungen zu ergriffenen Maßnahmen werden protokolliert, damit spätere Modelle nicht blind aus ihren eigenen Eingriffen lernen.

Datenaufbereitung

Prädiktives Prozessmonitoring braucht ein Ereignisprotokoll: Zu jedem Vorgang eine ID, einen Aktivitätsnamen, einen Zeitstempel und optional eine Ressource sowie Attribute wie Wert oder Kundentyp. Das Rohmaterial liegt in ERP-Tabellen (SAP, Dynamics), Ticket- oder Workflow-Werkzeugen, im CRM und teils in Mail- oder Papierschritten. Typische Lücken sind fehlende Vorgangs-IDs über Systeme hinweg, Zeitstempel, die die Buchung statt der tatsächlichen Arbeit festhalten, manuelle Schritte ohne Spur und je Abteilung unterschiedlich benannte Aktivitäten.

Schritte der Aufbereitung: einen Prozess und eine Vorgangsdefinition wählen, dann das Ereignisprotokoll mit Standardkonnektoren extrahieren (PREP-005), Aktivitätsnamen über ein Glossar vereinheitlichen (PREP-012), Papierschritte dort digitalisieren, wo sie eine Rolle spielen (PREP-008), Ergebnisse wie „verspätet abgeschlossen" aus geschlossenen Vorgängen labeln (PREP-020) und Benutzerkennungen vor der Analyse pseudonymisieren (PREP-022). Vereinbaren Sie mit PREP-024, was analysiert werden darf.

Grober Aufwandsanteil: 50 bis 60 Prozent des Projekts, da der Aufbau des Ereignisprotokolls der schwierige Teil ist. Einige tausend abgeschlossene Vorgänge sind ein sinnvolles Minimum. Eine Bereitschaftsprüfung finden Sie in GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A. Mit einem Standard-ERP bieten Process-Mining-Produkte fertige Konnektoren und Dashboards zu überschaubaren Preisen, und der Prozess selbst ist Standard.
• Großunternehmen: Weg B. Prozessdaten sind zentral und die Volumina machen Lizenzkosten pro Nutzer hoch, daher skaliert der Aufbau der Prognose auf den eigenen Ereignisprotokollen über Cloud-KI-Dienste oder eine interne Plattform besser.
• Entwickler: Weg C. Die Open-Source-Bibliothek PM4Py und Standard-ML-Pakete laufen auf HW1 und geben volle Kontrolle über den Umgang mit Ereignisprotokollen.
• Öffentlicher Sektor: Weg C. Vorgangsdaten von Bürgern und Beschäftigten sind sensibel, und das Vergaberecht begünstigt einen souveränen, selbst betriebenen Betrieb.

Weg A — Kaufen (empfohlen für die meisten KMU und Großunternehmen mit Standard-ERP)

• Process-Intelligence-Plattformen mit Prognose: Celonis (DE, München; Prediction Builder, Annotation Builder, Action Flows) [1]; SAP Signavio Process Intelligence (DE; KI-gestützte Ursachen- analyse, generative Q&A, What-if-Simulation) [4]; Apromore (Zusatzmodul für prädiktives Monitoring mit Trainings- und Laufzeitmodulen) [2]; IBM Process Mining (SaaS auf AWS oder On-Premises auf Red Hat OpenShift) [5]; weitere Optionen sind ARIS Process Mining (DE), mpmX (DE), UiPath Process Mining, Microsoft Power Automate Process Mining und ServiceNow Process Mining.
• In das ERP eingebettet: intelligente Szenarien in SAP S/4HANA (eingebettetes ML zur Prognose von Lieferverzug bei Bestellungen), Pega Process AI für SLAs in der Fallbearbeitung.
• Wählen Sie A, wenn: der Prozess in einem gängigen ERP mit Standardkonnektoren läuft, ein Process-Mining-Programm besteht oder geplant ist und On-Premises nicht zwingend ist (oder die On-Premises-Optionen von IBM/ARIS passen).

Weg B — Auf Cloud-KI-Diensten aufbauen

• Daten- und ML-Plattform: Databricks, Snowflake, Azure Machine Learning, Google Vertex AI oder AWS SageMaker in EU-Regionen; STACKIT (DE) oder IONOS (DE) für den souveränen Betrieb des ML-Stacks.
• Modellierung: AutoML für Tabellen-/Time-to-Event-Ziele (Vertex AI Tabular, Azure AutoML) oder verwaltetes XGBoost/LightGBM; Ereignisextraktion über SAP Datasphere / Fabric-Pipelines.
• LLM-Schicht (optional): ein in der EU gehostetes LLM (Mistral oder Claude/GPT/Gemini über Endpunkte in EU-Regionen) macht aus SHAP-Treibern eine lesbare Erklärung und entwirft die Nachricht zur Maßnahme; ein Agenten-Framework mit MCP-Werkzeugen kann die ERP-Transaktion öffnen oder dem Lieferanten schreiben, hinter Freigabeschritten.
• Wählen Sie B, wenn: Prozesse mehrere Systeme umfassen, Sie eigene Zielgrößen/Merkmale brauchen und eine Datenplattform bereits existiert.

Weg C — Selbst betreiben (Open Source)

• Ereignisprotokolle & Process Mining: PM4Py (Python; AGPL-3.0 oder kommerzielle Lizenz; aus einem Spin-off von Fraunhofer FIT; unterstützt OCEL) [6]; Protokolle in IEEE XES [7] oder OCEL 2.0 [8].
• Werkzeuge für prädiktives Monitoring: Nirdizati (Webanwendung predict-python aus der Forschung, MIT- Lizenz) [9]; scikit-learn, XGBoost/LightGBM/CatBoost, scikit-survival/lifelines für Überlebenszeit- modelle, PyTorch für LSTM-/Transformer-Sequenzmodelle (z. B. ProcessTransformer [10]); SHAP für Erklärungen; MLflow für das Modellregister.
• Streaming & Integration: Debezium-CDC aus ERP-Datenbanken → Apache Kafka / Flink für die Bewertung je Ereignis; n8n oder Camunda leiten Warnungen und Maßnahmen weiter.
• Hardware: HW1 genügt — Gradient-Boosting-Modelle trainieren und bewerten auf CPU-Servern selbst bei Millionen von Ereignissen. HW2 nur ergänzen, wenn Sie ein lokales LLM betreiben (z. B. der Klasse Mistral Small oder Qwen3 über vLLM) für Erklärungen oder agentische Folgeschritte oder große Transformer-Modelle trainieren.
• Tabellen-Foundation-Modelle: TabPFN (Prior Labs, DE) kann starke Basislinien bei wenigen Daten liefern, beachten Sie aber, dass neuere Gewichte (2.5 und später) nicht kommerzielle Lizenzen tragen, sofern keine Enterprise- Lizenz gekauft wird [11].

Weg D — Eigenes Training

Eigene Modelle sind in Weg C ohnehin die Regel; „eigenes Training" bedeutet hier die Investition in Sequenz-/Transformer- oder objektzentrierte Graphmodelle, vorgangsübergreifende Merkmale und kausale (präskriptive) Modelle. Es lohnt sich bei langen, stark variablen Prozessen mit vielen interagierenden Objekten (Aufträge, Lieferungen, Rechnungen) und >10.000 abgeschlossenen Vorgängen je Prozess, oder wenn Sie die Fähigkeit als Produkt verkaufen. Das Feintuning von LLMs auf Ablaufspuren ist ein aktives Forschungsthema, hat sich aber im Produktivbetrieb noch nicht als besser als gut konstruierte Tabellenmodelle erwiesen.

Stand der Technik (2026)

• Benchmarks: klassische Übersichten und Benchmarks decken Ergebnisvorhersage (elf Methoden, neun Protokolle [3]), Restzeitvorhersage [12] und Deep Learning (zehn Ansätze auf zwölf öffentlichen Protokollen [13]) ab. ProcessTransformer berichtete rund 80 % durchschnittliche Genauigkeit bei der nächsten Aktivität auf neun realen Protokollen [10]. Die öffentlichen BPI-Challenge-Protokolle (Finanz-, Bestell- und Reisekostenprozesse) bleiben die Standard-Testdaten [14].
• Was sich zuletzt geändert hat: Übergang von Protokollen mit einem einzigen Vorgangsbegriff zu objektzentrierten Ereignisprotokollen (OCEL 2.0), die Aufträge, Positionen, Lieferungen und Rechnungen gemeinsam darstellen und die Verzerrungen durch Abflachen vermeiden [8]; kommerzielle Plattformen binden Prognosen plus „Action Flows" und LLM-Agenten ein, die auf Prognosen reagieren [1]; Tabellen-Foundation-Modelle bieten Basislinien ohne Training.
• Bewährte Praxis: Gradient-Boosted Trees mit aggregierter Präfix-Kodierung und vorgangsübergreifenden Merkmalen, zeitlicher Trennung von Trainings- und Testdaten, Wahrscheinlichkeitskalibrierung und einem Uplift-Modell für die Wahl der Maßnahme.
• Grenzen & Fehlerbilder: Konzeptdrift nach Prozessänderungen oder ERP-Releases; Label-Leckage (Nutzung von Attributen, die erst am Vorgangsende bekannt sind); Rückkopplungsschleifen, wenn Maßnahmen Ergebnisse verändern; geringe Genauigkeit bei frühen Präfixen (Prognosen werden mit fortschreitendem Vorgang schärfer); Datenqualitätsprobleme bei der Ereignis- extraktion (fehlende Zeitstempel, Sammelbuchungen). Benchmarks auf öffentlichen Protokollen überschätzen die Genauigkeit bei unordentlichen realen ERP-Daten.

Gemeinsame Bausteine & Kombinationen

• Dieselbe Ereignisprotokoll-Pipeline: DATA-013 Process & Task Mining (beschreibende Schicht — einmal aufbauen, für beides nutzen), AGENT-018 fortlaufende Kontrollüberwachung, DATA-008 Datenqualitätsüberwachung.
• Derselbe Tabellen-ML-Stack (CPU, HW1): PRED-021 Zahlungsverhalten, PRED-023 Projektüberschreitung, PRED-003 Kundenabwanderung, PRED-011 Auslastungsprognose (Prognosen des Vorgangsvolumens speisen vorgangsübergreifende Merkmale), PRED-016 Cashflow (erwartete Zahlungstermine aus O2C-Prognosen).
• Nachgelagerte Maßnahmen: AGENT-004 Auftragserfassung, AGENT-005 Einkaufsagent (Lieferantennachverfolgung), AGENT-023 Order-to-Cash-Agent, AGENT-014 Schadenbearbeitung, AGENT-016 ITSM, AGENT-026 Fallbearbeitung in der öffentlichen Verwaltung — Prognosen entscheiden, welche Vorgänge diese Agenten zuerst anfassen.
• Physische ETA: PRED-018 ergänzt die ETA auf Transportebene für die Versandstrecke eines O2C-Vorgangs.
• Gemeinsame Bausteine: CDC-/Kafka-Streaming, Feature Store, MLflow, eine optionale HW2-GPU für ein lokales LLM, die mit anderen LLM-Anwendungsfällen geteilt wird.

Aufwand, Kosten & Kennzahlen

• Weg A: 2–4 Monate, wenn bereits ein Process-Mining-Datenmodell existiert; die Lizenzkosten skalieren mit Ereignissen/Prozessen/Nutzern (IBM nennt für seine On-Premises-Plattform ab 2.885 USD/Monat für 20 Millionen Ereignisse [5]); Celonis/Signavio liegen auf Großunternehmensniveau.
• Weg B/C: 3–6 Monate für den ersten Prozess (die Ereignisextraktion ist meist der größte Aufwand), danach Wochen je weiterem Prozess; die Infrastrukturkosten sind niedrig (CPU).
• Kostentreiber: Extraktion der Ereignisprotokolle und Datenqualität, Integration der Warnungen in Arbeitslisten, Veränderungsmanagement für die Teams, die eingreifen, Modellüberwachung auf Drift.
• Kennzahlen: AUC / Brier-Score und Kalibrierung nach Präfixlänge; mittlerer absoluter Fehler der Restzeitvorhersage; Frühzeitigkeit (wie viele Tage im Voraus das Risiko gemeldet wird); Anteil der gefährdeten Vorgänge, bei denen gehandelt wurde; Quote termingerechter Lieferung / SLA-Einhaltung; durchschnittliche Durchlaufzeit; Kosten der Beschleunigung je gerettetem Vorgang.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsführung und dem Prozessverantwortlichen (Bereichsleitung), die einen Prozess und ein Geschäftsziel wie weniger verspätete Aufträge benennen müssen. Binden Sie die IT und die Datenverantwortlichen früh für die Protokollextraktion und die Zugriffsrechte ein, und die IT-Sicherheit, wenn Protokolle das Unternehmen verlassen. Ereignisprotokolle halten fest, wer wann was getan hat; daher muss die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte von Anfang an beteiligt sein: Rechtsgrundlage, ein AVV mit jedem Anbieter und, weil das Verhalten der Beschäftigten systematisch ausgewertet wird, wahrscheinlich eine DSFA.

Betriebsrat: ja. Ereignisprotokolle mit Ressourcenangaben sind objektiv geeignet, Verhalten oder Leistung zu überwachen, daher gilt § 87 Abs. 1 Nr. 6 BetrVG, da das Bundesarbeitsgericht (BAG) die objektive Eignung genügen lässt; § 90 Abs. 1 Nr. 3 und, falls nötig, § 80 Abs. 3 (Sachverständiger) sprechen für eine frühe Beteiligung. Schließen Sie eine Betriebsvereinbarung, die die Analyse auf Prozessebene begrenzt und die Bewertung individueller Leistung ausschließt. Öffentliche Stellen beteiligen den Personalrat.

Starten Sie den Pilot mit einem Prozess und einem Team, mit pseudonymisierten Ressourcen, und teilen Sie die Ergebnisse offen mit dem Team. Typische Bedenken sind Überwachung und Arbeitsplatzverlust. Begegnen Sie ihnen, indem Sie Vorgänge statt Personen analysieren, den Zweck veröffentlichen und Entscheidungen über Maßnahmen bei Menschen belassen. Bieten Sie eine Schulung zur KI-Kompetenz an (KI-Verordnung Art. 4). Siehe GUIDE-004, GUIDE-005 und GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Bei Auftrags-, Bestell- und Logistikprozessen ist die Nutzung minimales Risiko (Pflicht zur KI-Kompetenz, Art. 4). Die Einstufung wird hochriskant, wenn Prognosen genutzt werden, um die Leistung von Beschäftigten zu bewerten oder Aufgaben auf Grundlage persönlichen Verhaltens zuzuweisen (Anhang III Nr. 4 Buchst. b), um die Anspruchsberechtigung für öffentliche Unterstützungsleistungen oder Dienste zu prüfen (Anhang III Nr. 5 Buchst. a) oder um die Kreditwürdigkeit natürlicher Personen zu beurteilen (Anhang III Nr. 5 Buchst. b) [15]. Die Vorhersage der Prozessverzögerung eines Leistungsantrags zur Priorisierung der Arbeit liegt wohl außerhalb von Nr. 5 Buchst. a, solange sie die Entscheidung über die Anspruchsberechtigung nicht beeinflusst — dokumentieren Sie diese Begründung nach Art. 6 Abs. 3. Daher depends.
• DSGVO & Beschäftigtendaten: Ereignisprotokolle enthalten Benutzerkennungen von Sachbearbeitern (das Attribut „Ressource") und oft Kundendaten. Pseudonymisieren oder entfernen Sie Ressourcenkennungen, sofern sie nicht nötig sind; in Deutschland hat der Betriebsrat Mitbestimmungsrechte bei technischen Systemen, die zur Überwachung von Beschäftigten geeignet sind (§ 87 Abs. 1 Nr. 6 BetrVG), und § 26 BDSG gilt — schließen Sie vor dem Produktivstart eine Betriebsvereinbarung. Auftragsverarbeitungsverträge und EU-Hosting bei SaaS.
• Öffentlicher Sektor: Beachten Sie das Verwaltungsverfahrensrecht (keine automatisierten Entscheidungen ohne Rechts- grundlage, § 35a VwVfG) und Transparenz gegenüber Antragstellern, wo Prognosen die Bearbeitungsreihenfolge beeinflussen.
• Branchenregeln: DORA-Risiko durch IKT-Drittanbieter, wenn eine Bank SaaS-Process-Intelligence für kritische Prozesse nutzt; GoBD, wenn Prognosen in buchhaltungsrelevante Prozesse einfließen.
• Gegenmaßnahmen: zeitlich getrennte Validierung, Drift-Überwachung, Protokollierung der Maßnahmen, Erklärungen je Warnung, keine automatisierten nachteiligen Entscheidungen über Personen.

Erste Schritte

1. Wählen Sie einen Prozess mit einem klaren, teuren „schlechten Ergebnis" (z. B. verspätete Lieferung eines Kundenauftrags oder Lieferantenverzug) und mindestens einem Jahr Historie im ERP.
2. Extrahieren Sie ein Ereignisprotokoll (oder nutzen Sie Ihr Process-Mining-Datenmodell weiter) und legen Sie das Label und den Entscheidungszeitpunkt fest, zu dem eine Prognose noch Handeln erlaubt.
3. Bauen Sie eine Basislinie: Gradient-Boosting-Modell auf Präfix-Merkmalen mit zeitlicher Trennung; messen Sie Genauigkeit nach Präfixlänge und Frühzeitigkeit — oder führen Sie ein Anbieter-PoC (Weg A) auf denselben Daten durch.
4. Entwerfen Sie die Maßnahme: wer die Arbeitsliste erhält, was er tun kann und wie Aktionen protokolliert werden; binden Sie Betriebsrat und Datenschutzbeauftragte früh ein.
5. Pilotieren Sie 2–3 Monate mit einer Kontrollgruppe und messen Sie Termintreue und Durchlaufzeit, bevor Sie skalieren.

Quellen

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/