End-to-End-Prozess · Einkauf im Sondermaschinenbau

Purchase-to-Pay

Vom internen Bedarf bis zur Zahlung: wie Causal Process Mining Freigabeumgehungen, Nacharbeit, Kapazitätsabhängigkeiten und Lieferantenperformance im Purchase-to-Pay-Prozess sichtbar und erklärbar macht.

Was ist Purchase-to-Pay?

Purchase-to-Pay (P2P) beschreibt den End-to-End-Prozess vom entstehenden Beschaffungsbedarf bis zur Bezahlung einer Rechnung. Im Sondermaschinenbau umfasst er Bestellanforderung und Freigabe, Bestellung und Bestellpositionen, die physische oder digitale Bereitstellung, Wareneingang und Prüfung sowie Rechnung, Freigabe und Zahlung. Auf einer Prozessfolie wirkt das linear – in den operativen Daten ist P2P ein Netz aus verbundenen Geschäftsobjekten. Noreja übernimmt diese Daten granular in den Event Knowledge Graph und leitet erst für eine konkrete Fachfrage die passende Prozessperspektive ab.

Hinweis: Alle Kennzahlen stammen aus einem synthetischen Demonstrationsdatensatz. Sie veranschaulichen Analysewege, fachliche Zusammenhänge und Methoden von Causal Process Mining und sind keine Produktivkennzahlen eines Kunden.

Event Knowledge Graph des Purchase-to-Pay-Prozesses: Bestellanforderung, Freigaben A und B, Bestellung, Bestellpositionen für Hardware und Software, Wareneingang, Prüfung, Rechnung, Rechnungslauf und Zahlung als verbundene Objekte
Event Knowledge Graph des Purchase-to-Pay-Prozesses: Geschäftsobjekte und ihre Beziehungen bleiben erhalten.

Auf einen Blick

1.145

Maverick Buying

26,3 % der freigabepflichtigen Bestellanforderungen umgehen den vorgesehenen Freigabepfad

647

Rechnungsnacharbeit

Fälle in zwei sichtbaren Wiederholungsschleifen mit 554 und 93 Fällen

92

Prüfkapazität überschritten

1,62 % von 5.670 Wareneingangsprüfungen

2.209

Zahlungen nach Skontofrist

gegenüber 2.717 Zahlungen innerhalb der Skontofrist

≈ 1,02 Mio. €

Modellierter Skontoverlust

perspektivweiter Demonstrationswert über alle Zahlungen außerhalb der Skontofrist

3

Auffällige Lieferantengruppen

rund 14 bis 15,5 Tage statt überwiegend rund 5,5 bis 6,2 Tage bei den übrigen Lieferanten

Der Prozess in vier Phasen

Die End-to-End-Perspektive verbindet die für die Fachfrage relevanten Teile des gemeinsamen Prozesswissens. Sie reduziert die Komplexität für den Prozessmanager, ohne die zugrunde liegenden Objektbeziehungen zu verlieren.

End-to-End-Perspektive des Purchase-to-Pay-Prozesses von der Bestellanforderung mit und ohne Freigabe über Bestellung, Wareneingang und Prüfung bis zu Rechnung und Zahlung innerhalb bzw. außerhalb der Skontofrist
End-to-End-Perspektive des Purchase-to-Pay-Prozesses.

Phase 1

Bedarf & Freigabe

Eine Bestellanforderung wird angelegt. Abhängig von Wert und Beschaffungskontext läuft sie direkt weiter oder durchläuft einen mehrstufigen Freigabepfad. Erst danach wird die Bestellung erzeugt.

Geschäftsobjekte

  • Bestellanforderung
  • Freigabe A
  • Freigabe B
  • Bestellung
  • Anforderer
  • Kostenstelle
  1. Bestellanforderung erstellt
  2. Freigabebedarf bestimmen
  3. Freigabe A
  4. Freigabe B
  5. Bestellung erstellt

Leitfrage

Werden die für diesen konkreten Bedarf vorgesehenen Freigaben tatsächlich durchlaufen?

Phase 2

Bestellung & Erfüllungsweg

Nach der Bestellung entstehen Bestellpositionen. Je nach Produktgruppe unterscheiden sich die weiteren Wege: Physische Beschaffung benötigt Lieferung und Wareneingang, Software kann über eine Bereitstellung geführt werden.

Geschäftsobjekte

  • Bestellung
  • Bestellposition
  • Material
  • Lieferant
  • Vertrag
  • Lieferung
  • Software-Bereitstellung

Physische Ware

  1. 1Bestellposition angelegt (HW)
  2. 2Lieferung
  3. 3Wareneingang
  4. 4Wareneingangsprüfung

Software

  1. 1Bestellposition angelegt (SW)
  2. 2Software-Bereitstellung

Leitfrage

Welcher Beschaffungsweg ist für die jeweilige Position fachlich vorgesehen – und wo entstehen Unterschiede in Laufzeit oder Verhalten?

Prozessgraph mit physischem Pfad über Wareneingang, geplante und gebündelte Prüfung sowie Software-Pfad über Software-Bereitstellung, die beide in die Rechnungserfassung münden
Physischer Pfad und Software-Pfad bis zur Rechnung.

Phase 3

Wareneingang & Prüfung

Physische Waren werden nach dem Eingang geprüft. Dabei arbeitet nicht jeder Vorgang für sich: Viele Wareneingänge teilen sich gemeinsame Prüfressourcen und werden in gebündelten Prüfläufen verarbeitet.

Geschäftsobjekte

  • Wareneingang
  • Wareneingangsprüfung
  • Prüfplatz
  • Prüf-Batch
  1. Wareneingang eingegangen
  2. Wareneingangsprüfung geplant
  3. Prüfung gebündelt durchgeführt

Leitfrage

Wartet ein Vorgang wegen seines eigenen Ablaufs – oder weil mehrere Vorgänge dieselbe Ressource und denselben Prüflauf teilen?

Phase 4

Rechnung, Freigabe & Zahlung

Nach Erfüllung der Bestellung wird die Rechnung erfasst, freigegeben und im Rechnungslauf verarbeitet. Fachliche Abweichungen können eine manuelle Klärung oder Nachbearbeitung auslösen. Für die Zahlungssteuerung ist außerdem relevant, ob die Zahlung innerhalb der Skontofrist erfolgt.

Geschäftsobjekte

  • Rechnung
  • Rechnungsfreigabe
  • Rechnungslauf
  • Zahlung
  • Lieferantenklärung
  • Skontofrist
  1. Rechnung erfasst
  2. Rechnung freigegeben
  3. Rechnungslauf durchgeführt
  4. Zahlung ausgeführt

Leitfrage

Welche Prozessbedingungen erzeugen Nacharbeit, Wartezeit oder einen messbaren finanziellen Effekt?

Eine Bestellanforderung kann unterschiedliche Freigabelogiken auslösen, eine Bestellung mehrere Positionen enthalten, mehrere Wareneingänge teilen sich Prüfkapazitäten, und Rechnungen stehen in Beziehung zu Bestellung, Wareneingang, Konditionen und Zahlung. Genau diese Beziehungen bleiben im Event Knowledge Graph erhalten.

Fünf Findings entlang des Purchase-to-Pay-Prozesses

Die Findings beantworten unterschiedliche Fachfragen. Entscheidend ist nicht nur, was auffällig ist, sondern warum es passiert, welche Bedingungen dahinterstehen und welcher Hebel sich daraus ableiten lässt.

Finding 1 · Compliance

Der schnellste Pfad ist der falsche

Nicht jedes Prozessproblem zeigt sich als Verzögerung. Im Einkauf kann ein Vorgang sogar besonders schnell sein, weil notwendige Kontrollschritte fehlen. Der Analyzer interpretiert den direkten Übergang deshalb nicht als zusätzliche Prozessvariante, sondern klassifiziert ihn fachlich als Ignorieren eines vorgesehenen Freigabepfads.

Der Direktpfad benötigt im Mittel nur rund 15 Minuten bis zur Bestellung, der reguläre Weg über die Freigaben mehrere Stunden. Genau darin liegt der Konflikt: Was aus Performance-Sicht attraktiv wirkt, ist aus Governance- und Compliance-Sicht problematisch.

1.145

freigabepflichtige Bestellanforderungen führen direkt zur Bestellung (26,3 %)

Statt „Welche Variante ist besonders schnell?“

fragt die Analyse: „Welche fachlich notwendige Kontrolle fehlt – und bei welchen Geschäftsobjekten konzentriert sich das Verhalten?“

Prozessgraph Bestellanforderung: roter Direktpfad von der Bestellanforderung mit Freigabepflicht zur Bestellung (1.145 Fälle, 26 %, rund 15 Minuten) an Bestellfreigabe A und B vorbei
Maverick Buying als Fehlermuster „Ignorieren“: der Direktpfad umgeht Bestellfreigabe A und B.

Von 1.145 Fällen zu einer konkreten Ursachenhypothese

Im nächsten Schritt werden die betroffenen Geschäftsobjekte nach gemeinsamen Merkmalen untersucht. Von den 1.145 Fällen entfallen 597 auf den Anforderer Kaya und 515 auf Braun – zusammen rund 97 % der sichtbaren Maverick-Buying-Fälle. Die Kostenstellen sind dagegen wesentlich gleichmäßiger verteilt.

Aus einem abstrakten Compliance-Finding wird so eine konkrete organisatorische Hypothese: Warum konzentriert sich die Freigabeumgehung auf diese Anforderergruppe? Mögliche Erklärungen – Berechtigungen, Zeitdruck, lokale Arbeitsweisen oder nicht dokumentierte Sonderregeln – müssen fachlich geprüft werden. Die Analyse grenzt die relevante Population ein, ohne den organisatorischen Grund zu erfinden.

Attributverteilung der 1.145 Maverick-Buying-Fälle: Anforderer Kaya 52,14 % und Braun 44,98 %, Kostenstellen KS-100 bis KS-400 nahezu gleich verteilt
Attributverteilung der Maverick-Buying-Fälle: zwei Anforderer, gleichmäßig verteilte Kostenstellen.

Finding 2 · Rechnungsbearbeitung

Nacharbeit ist ein Symptom, Kontext liefert die Erklärung

Lange Rechnungsdurchlaufzeiten können durch Wartezeit, Freigabe, Klärung oder echte Nacharbeit entstehen. Deshalb wird nicht nur die Dauer gemessen, sondern das beobachtete Verhalten als Fehlermuster klassifiziert: Zwei Nachbearbeitungsschleifen umfassen 554 beziehungsweise 93 Fälle.

Die Aussage „Rechnungen werden nachbearbeitet“ reicht für eine Verbesserung aber noch nicht aus. Entscheidend ist, warum eine manuelle Klärung notwendig wird.

647

Fälle in zwei sichtbaren Wiederholungsschleifen (554 und 93 Fälle)

Statt „Wo ist die Durchlaufzeit lang?“

fragt die Analyse: „Welche fachliche Inkonsistenz erzeugt die Nacharbeit – und welche Informationen außerhalb der operativen Prozessdaten erklären sie?“

Prozessgraph Rechnungsbearbeitung mit aktivem Fehlermuster „Nachbearbeitung“: rote Schleifen von der Rechnungserfassung über die manuelle Klärung (554 Fälle) und vom Rechnungslauf zurück (93 Fälle)
Nachbearbeitung in der Rechnungsbearbeitung: zwei sichtbare Wiederholungsschleifen.

Prozessdaten plus Fachkontext

In der Demo wurden zusätzliche Informationen aus einem IT-/Support-Ticketsystem in Noreja Context eingebunden. Minerva verbindet die betroffenen Rechnungen über ihre Rechnungs-ID mit diesem Kontext. Sichtbar werden konkrete Klärungsgründe: Abweichung zwischen Rechnung und Bestellung, unklare Rechnungspositionen und Preisabweichung zu hinterlegten Konditionen.

Die Aussage verändert sich damit zu: „Diese fachlichen Gründe lösen die Nacharbeit aus.“ Das ist für die Maßnahmenableitung entscheidend – Mengen- oder Bestellabweichungen verlangen andere Gegenmaßnahmen als unklare Rechnungspositionen oder falsche Konditionsdaten.

Minerva-Antwort neben dem Prozessgraphen: Tabelle mit den Rechnungs-IDs 1669, 1945 und 2644 und ihren Klärungsgründen – Abweichung zur Bestellung, unklare Positionen, Preisabweichung
Minerva verbindet Rechnungsnacharbeit mit Kontext aus dem Ticketsystem.

Finding 3 · Shared Capacity

Wenn mehrere Vorgänge dieselbe Ressource teilen

Wareneingangsprüfungen sind nicht nur isolierte Schritte einer einzelnen Bestellung. Mehrere Prüfungen können demselben Prüflauf zugeordnet sein und teilen sich die verfügbaren Ressourcen. Ein Vorgang kann fachlich korrekt sein und trotzdem warten, weil andere Vorgänge denselben Prüfslot beanspruchen.

Die Zeitperspektive macht diese Logik sichtbar: Während Bestellungen und Wareneingänge über die Zeit verteilt entstehen, konzentrieren sich die gebündelt durchgeführten Prüfungen auf wiederkehrende Zeitpunkte.

92

Wareneingangsprüfungen mit überschrittener Prüfkapazität (1,62 % von 5.670)

Statt „Die Prüfung ist langsam.“

fragt die Analyse: „Welche gemeinsame Ressource hält diese konkreten Vorgänge zurück – und unter welchen Bedingungen entsteht der Rückstau?“

Prozessgraph von „Wareneingangsprüfung geplant“ zu „Prüfung gebündelt durchgeführt“ mit Zeitachse
Geplante Wareneingangsprüfungen und gemeinsame Prüf-Batches.
Punktdiagramm über die Zeit: Bestellungen verteilt, gebündelt durchgeführte Prüfungen konzentriert auf wiederkehrende Zeitpunkte
Zeitmuster der gebündelten Wareneingangsprüfung.

Kapazitätsüberschreitung gezielt isolieren

Im synthetischen Lauf lassen sich 92 Wareneingangsprüfungen identifizieren, bei denen die verfügbare Prüfkapazität zum vorgesehenen Zeitpunkt überschritten war. Aus dem allgemeinen Zeitmuster wird so ein konkretes operatives Finding: Die Wartezeit ist mit einer dokumentierten Prozessbedingung verknüpft – die gemeinsam genutzte Kapazität reichte für diese Vorgänge nicht aus.

  • Sind die Prüfintervalle passend dimensioniert?
  • Müssen bestimmte Warengruppen priorisiert werden?
  • Ist zusätzliche Kapazität sinnvoll?
  • Können Prüfregeln differenziert werden?
  • Welche Objekte verursachen wiederkehrend den Backlog?

Finding 4 · Zahlung

Vom sichtbaren Zusammenhang zur geprüften Wirkung

Im End-to-End-Prozess ist sichtbar, ob Zahlungen innerhalb oder außerhalb der Skontofrist erfolgen. Der Skontoverlust wird als eigenes Zahlungsattribut bis auf Euro-Ebene quantifiziert; für die 2.209 Zahlungen außerhalb der Frist ergibt sich ein modellierter Gesamtwert von rund 1,02 Mio. €.

Damit entsteht eine wirtschaftlich relevante Frage: Welche Prozessbedingungen tragen tatsächlich dazu bei, dass die Skontofrist verfehlt wird?

2.209

Zahlungen außerhalb der Skontofrist (gegenüber 2.717 innerhalb) · modellierter Skontoverlust rund 1,02 Mio. €

Statt „Wo sehen wir gleichzeitig Wartezeit und Kosten?“

fragt die Analyse: „Welche veränderbare Bedingung erklärt den wirtschaftlichen Effekt tatsächlich?“

Prozessgraph ab dem Rechnungslauf: Verzweigung in „Zahlung außerhalb Skontofrist“ (2.209) und „Zahlung innerhalb Skontofrist“ (2.717)
Zahlungen innerhalb und außerhalb der Skontofrist.
Attributauswertung skonto_verlust_eur über 2.209 Zahlungen mit Verteilung und Summe von 1.022.005,75 €
Modellierter Skontoverlust als Zahlungsattribut: Summe 1.022.005,75 € im Demodatensatz.

Kausalität bedeutet auch, Hypothesen zu schärfen

Eine plausible erste Hypothese: Der Rückstau in der Wareneingangsprüfung verzögert spätere Zahlungen. Noreja verfolgt deshalb die tatsächlich kapazitätsüberschrittenen Prüfungen entlang ihrer Beziehungen bis zur Zahlung.

Die Analyse trennt dabei zwei Dinge, die in einer reinen End-to-End-Sicht leicht verwechselt werden: Ein operativer Engpass kann real sein, ohne automatisch der alleinige Treiber eines später sichtbaren finanziellen Effekts zu sein. Der Prüfstau bleibt ein relevantes operatives Finding; für den Skontoverlust müssen zusätzlich Rechnungslauf, Zahlungssteuerung, fachliche Klärungen und weitere Bedingungen betrachtet werden.

Prozessgraph der kapazitätsüberschrittenen Prüfungen: von „Prüfung gebündelt durchgeführt“ über Rechnungserfassung, Freigabe und Rechnungslauf bis „Zahlung außerhalb Skontofrist“
Kapazitätsüberschrittene Prüfungen, verfolgt bis zur Zahlung.

Finding 5 · Lieferantenperformance

Derselbe Standardprozess, andere Laufzeit

Nicht jede Verzögerung entsteht im eigenen Prozess. Die Lieferantenanalyse vergleicht dieselbe Beschaffungslogik entlang der verbundenen Lieferantenobjekte. Die zusätzliche Zeit konzentriert sich vor allem auf den Übergang Bestellung erstellt → Wareneingang eingegangen.

Gleichzeitig folgen die langsamen Lieferanten überwiegend dem normalen Prozesspfad, und auch eine außergewöhnlich hohe Nacharbeitsrate erklärt ihre längere Dauer nicht. Ein interner Workflow-Umbau adressiert keine externe Lieferverzögerung – stattdessen rücken Lieferzeiten, Disposition, Vereinbarungen und Lieferantensteuerung in den Fokus.

≈ 2×

so lange bei drei Lieferantengruppen: rund 14 bis 15,5 Tage statt überwiegend 5,5 bis 6,2 Tage

Statt „Warum ist unser P2P-Prozess langsam?“

fragt die Analyse: „Warum benötigt derselbe Standardprozess bei bestimmten Lieferanten deutlich länger?“

Lieferantenanalyse: Prozessgraph Bestellung erstellt → Wareneingang eingegangen neben einer Minerva-Auswertung mit drei Lieferanten bei rund 14 bis 15 Tagen Durchlaufzeit
Analyse der Lieferantenperformance: die Verzögerung liegt zwischen Bestellung und Wareneingang.

Von einzelnen Findings zu einem Ursachenbild

Die Findings gehören zum selben End-to-End-Prozess, haben aber unterschiedliche Wirkmechanismen. Minerva führt die Ergebnisse aus den verschiedenen Perspektiven zusammen – nicht, um eine universelle „Root Cause“ zu konstruieren, sondern um die Ursache-Wirkungs-Mechanismen sauber zu trennen.

BereichBeobachtungWeiterführende Fachfrage
Freigabe1.145 Maverick-Buying-FälleWarum konzentriert sich die Umgehung auf bestimmte Anforderer?
Rechnung647 sichtbare Rework-FälleWelche fachlichen Klärungsgründe wiederholen sich?
Wareneingangsprüfung92 KapazitätsüberschreitungenWelche gemeinsame Ressource erzeugt den Backlog?
Zahlung2.209 Zahlungen außerhalb SkontofristWelche Prozessbedingungen treiben den monetären Effekt?
Lieferantendrei deutlich langsamere GruppenLiegt der Hebel intern oder beim externen Partner?
Minerva-Analyse der Prozessauslassungen: Tabelle struktureller Defekte im P2P-Prozess, angeführt von Maverick Buying (1.145) und Rechnungsnacharbeit (554)
Minerva fasst strukturelle Abweichungen im P2P-Prozess zusammen.
Minerva-Auswertung: Tortendiagramm der pausierten Objekte und Ursachendiagramm mit Maverick Buying, Rechnungsnacharbeit, gebündelter Bearbeitung und Zahlung außerhalb der Skontofrist
Minerva verdichtet die Findings zu einem Ursachenmodell.
Kernursachen laut Minerva: Maverick Buying als größtes strukturelles Risiko, Rechnungserfassung als wichtigste Nacharbeitsquelle, gebündelte Prüfung und Rechnungslauf als Verzögerungsursache
Verdichtete Kernaussagen aus der Minerva-Analyse.

Die Business-Frage steht am Anfang – nicht die Bedienlogik des Analysewerkzeugs.

Vom Finding zur priorisierten Maßnahme

Ein Finding verändert noch keinen Prozess. Im Business Impact Board werden Findings nach Wirkung, Umsetzungsaufwand und Unsicherheit bewertet – Process Excellence und Fachbereich entscheiden gemeinsam, welche Verbesserungsinitiative zuerst umgesetzt wird und welche bewusst später folgt.

Beispielhafte Maßnahmenfelder
FindingMögliche VerbesserungsrichtungZu bewertende Wirkung
Maverick BuyingBerechtigungen und legitime Sonderregeln prüfen, Bypass-Verhalten gezielt adressierenCompliance, Governance, Risiko
RechnungsnacharbeitValidierungen zwischen Bestellung, Rechnung und Konditionen früher ausführenNacharbeitsaufwand, Durchlaufzeit, Qualität
Prüfkapazität / BatchingPrüfintervalle, Priorisierung und Ressourcensteuerung optimierenWartezeit, Ressourcennutzung, Stabilität
SkontoverlustRechnungslauf und Zahlungslogik auf vermeidbare Verzögerungen untersuchenKosten, Cashflow, Skontonutzung
LieferantenperformanceLangsame Lieferantengruppen gezielt mit Lieferzeit- und Dispositionsdaten analysierenVersorgungssicherheit, Durchlaufzeit

Die Priorisierung ist eine fachliche Entscheidung. Minerva bereitet Analysewege, Kontext und Handlungsoptionen vor; die Verantwortung für die Maßnahme bleibt beim Prozessverantwortlichen und Fachbereich.

Der Kreislauf: Insight → Action → Impact → Feedback

Die Analyse endet nicht mit dem Finding und auch nicht mit der Umsetzung einer Maßnahme. Entscheidend ist, ob sich das Prozessverhalten danach tatsächlich verändert.

  1. 1

    Insight

    Fehlermuster, Zeitmuster, fehlende Voraussetzung oder auffällige Objektgruppe erkennen

  2. 2

    Action

    Ursache verstehen, Verbesserungshypothese formulieren, Wirkung und Aufwand bewerten und priorisieren

  3. 3

    Impact

    Maßnahme umsetzen und den erwarteten fachlichen bzw. wirtschaftlichen Effekt definieren

  4. 4

    Feedback

    Wirkung erneut mit denselben granularen Daten und derselben Prozesslogik messen

Nach jeder Maßnahme prüfen

  • Wird Maverick Buying tatsächlich seltener?
  • Sinkt die Rechnungsnacharbeit bei den adressierten Klärungsgründen?
  • Geht der Backlog an der Wareneingangsprüfung zurück?
  • Werden Lieferzeiten bei den betroffenen Lieferanten stabiler?
  • Verbessert sich die Skontonutzung tatsächlich?
  • Hat sich das Problem verschoben oder wurde es wirklich gelöst?

Fünf Prinzipien für die Analyse

Granularität erhalten

Bestellanforderung, Freigabe, Bestellung, Position, Wareneingang, Prüfung, Rechnung und Zahlung bleiben mitsamt ihren Beziehungen erhalten – nicht vorab auf eine lineare Prozesssicht reduziert.

Komplexität fachlich reduzieren

Für eine konkrete Fachfrage entsteht eine passende Perspektive auf den Event Knowledge Graph – einfacher, ohne die Beziehungen zu verlieren.

Kausale Hypothesen prüfen

Auffälligkeiten werden nicht automatisch als Ursache interpretiert, sondern entlang derselben Geschäftsobjekte gegen den beobachteten Effekt geprüft.

Kontext einbeziehen

Tickets, Kommentare, Qualitätsmeldungen oder andere Fachinformationen werden mit den betroffenen Geschäftsobjekten verbunden.

Erkenntnisse operationalisieren

Findings werden zu Verbesserungshypothesen, nach Wirkung, Aufwand und Unsicherheit priorisiert und nach der Umsetzung erneut gemessen.

Häufige Fragen zu Purchase-to-Pay

Was ist ein Purchase-to-Pay-Prozess?

Purchase-to-Pay ist der End-to-End-Prozess vom entstehenden Beschaffungsbedarf bis zur Zahlung. Im gezeigten Sondermaschinenbau-Szenario umfasst er Bestellanforderung, Freigaben, Bestellung und Bestellpositionen, physische bzw. digitale Erfüllung, Wareneingang und Prüfung sowie Rechnung, Freigabe und Zahlung.

Warum ist P2P für Causal Process Mining besonders interessant?

Weil viele fachlich unterschiedliche Geschäftsobjekte und Abhängigkeiten zusammenspielen. Eine Bestellung kann mehrere Positionen enthalten, physische und digitale Beschaffung folgen unterschiedlichen Wegen, Prüfressourcen werden von mehreren Vorgängen gleichzeitig genutzt und Rechnungen beziehen sich auf Bestellung, Wareneingang und Konditionen. Ursachen sind deshalb nicht immer dort sichtbar, wo ihre Wirkung später auftritt.

Was ist Maverick Buying?

Maverick Buying bezeichnet hier den Fall, dass eine eigentlich freigabepflichtige Bestellanforderung direkt zur Bestellung führt und vorgesehene Freigabeschritte umgangen werden. Im synthetischen Demo-Run betrifft das 1.145 Fälle bzw. 26,3 % der freigabepflichtigen Anforderungen.

Warum ist eine kurze Durchlaufzeit nicht automatisch positiv?

Weil Geschwindigkeit nur eine Dimension von Prozessqualität ist. Der Maverick-Buying-Pfad ist deutlich schneller als der reguläre Freigabepfad, gerade weil Kontrollen fehlen. Ein schneller Prozess kann damit fachlich schlechter sein als ein langsamerer, aber regelkonformer.

Wie hilft zusätzlicher Kontext bei Rechnungsnacharbeit?

Der Analyzer zeigt zunächst, dass Nacharbeit oder manuelle Klärung stattfindet. Über Noreja Context werden zusätzliche Fachinformationen – etwa aus einem Ticketsystem – mit der betroffenen Rechnungs-ID verbunden. So werden konkrete Gründe wie Bestellabweichungen, unklare Rechnungspositionen oder Konditionsprobleme sichtbar.

Was bedeutet Cross-Case-Abhängigkeit bei der Wareneingangsprüfung?

Mehrere Wareneingänge teilen sich gemeinsame Prüfressourcen und werden in denselben Batchläufen verarbeitet. Ein einzelner Vorgang kann deshalb warten, obwohl in seiner eigenen Historie kein Fehler erkennbar ist – die Ursache liegt in einer gemeinsam genutzten Ressource außerhalb dieses einen Vorgangs.

Verursacht der Prüfstau automatisch den Skontoverlust?

Nein. Die Wareneingangsprüfung kann ein realer operativer Engpass sein. Für die wirtschaftliche Wirkung muss aber separat geprüft werden, ob dieselben betroffenen Geschäftsobjekte später tatsächlich überproportional die Skontofrist verfehlen. Causal Process Mining trennt sichtbare Korrelationen von geprüften Ursache-Wirkungs-Hypothesen.

Welche Rolle spielt Minerva?

Minerva unterstützt den Prozessmanager dabei, fachliche Fragen über Prozesswissen, Analyseergebnisse und zusätzlichen Kontext hinweg zu untersuchen. Sie führt Findings zusammen, bildet Vergleichsgruppen, strukturiert Ursachenhypothesen und bereitet Analysewege vor. Die Entscheidung über Maßnahmen bleibt beim Menschen.

Wie werden Findings priorisiert?

Prozessverantwortliche bewerten Findings beispielsweise nach Wirkung, Umsetzungsaufwand und Unsicherheit. So wird aus einer analytischen Auffälligkeit eine priorisierte Verbesserungsinitiative, deren Wirkung nach der Umsetzung erneut gegen die granularen Prozessdaten gemessen wird.

Stammen die Kennzahlen von einem echten Sondermaschinenbauer?

Nein. Alle Kennzahlen stammen aus einem synthetischen Demonstrationsdatensatz. Sie machen Analysewege, kausale Fragestellungen und die Verbindung von Prozessdaten mit fachlichem Kontext nachvollziehbar.

Die vollständige Case-Beschreibung

Event Knowledge Graph, End-to-End-Perspektive, alle fünf Findings mit ihren Analyseschritten, das Minerva-Ursachenmodell und der Weg zur priorisierten Maßnahme – Schritt für Schritt im Noreja Help Center.

Case im Help Center lesen

Eigenen Prozess analysieren? Sprich mit uns.

Bereit zum Start

Deinen End-to-End-Prozess kausal verstehen — sprich mit uns

Schließe dich Unternehmen an, die mit intelligenter Prozessanalyse Wachstum und Effizienz neu definieren.