Lead-To-Activation (Fernwärmeanschluss)
Hinweis zur Demo: Die in diesem Beitrag gezeigten Kennzahlen stammen aus einem synthetischen Demonstrationsdatensatz. Sie dienen dazu, Analysewege und methodische Zusammenhänge zu veranschaulichen, und sind keine Produktivkennzahlen eines Kunden.
Wenn man einen Fernwärmeanschluss aus Kundensicht beschreibt, klingt der Ablauf zunächst einfach: Interesse, Angebot, Vertrag, Bau, Anschluss und schließlich Wärmeversorgung.
In der Realität ist der Prozess deutlich komplexer. Schon vor dem Auftrag liegen Informationen in unterschiedlichen Systemen und Objekten. Nach dem Auftrag verzweigt der Ablauf in mehrere parallele Stränge: Tiefbau beziehungsweise Fremdleistung, Materialbeschaffung, Hausanschluss und kaufmännische Voraussetzungen. Später müssen diese Stränge wieder zusammengeführt werden, bevor Bau, Inbetriebnahme, Abrechnung und Lieferbeginn möglich sind.
Genau an solchen Prozessen zeigt sich eine Grenze klassischer Process-Mining-Darstellungen: Eine einzige Prozesskarte beantwortet nicht jede fachliche Frage. Noch problematischer wird es, wenn die Prozessrealität bereits beim Datenimport auf eine einzelne Case-ID und einen flachen Eventlog reduziert wird.
Die zentrale Frage lautet deshalb nicht nur: Wie visualisieren wir den Prozess?
Sondern: Wie erhalten wir die Beziehungen und die Granularität des realen Prozesses – und reduzieren die Komplexität erst dann, wenn wir eine konkrete Fachfrage beantworten wollen?
1. Die gemeinsame Basis: ein Event Knowledge Graph
Im Demonstrationsmodell werden Vertriebsinformationen, Auftrag, Auftragspositionen, Projektstrukturen, Tiefbau, Materialbeschaffung, Lieferungen, Rechnungen und Zahlungen, Bauaktivitäten, Anlage, Zählersetzung, Inbetriebnahme, Wärmeliefervertrag und Übergabeprotokolle miteinander verbunden.
Der entscheidende Punkt ist nicht die Visualisierung des Graphen selbst. Entscheidend ist, dass die Beziehungen zwischen den Geschäftsobjekten erhalten bleiben.
Je nach Fragestellung kann die fachlich relevante Einheit nämlich eine andere sein: ein Lead, ein Auftrag, ein PSP-Element, eine Bestellung, eine Bauaktivität, eine Anlage oder ein Übergabeprotokoll.
Noreja reduziert den Prozess deshalb nicht bereits beim Datenimport auf eine einzige Case-ID. Die Beziehungen zwischen den Objekten bleiben erhalten und können später je nach Prozessfrage unterschiedlich interpretiert werden.
Das führt zu einem einfachen Grundprinzip:
Komplexität wird bei der Analyse reduziert – nicht bereits beim Datenimport.
2. Perspektiven: unterschiedliche Fachfragen auf demselben Prozesswissen
Aus demselben Event Knowledge Graph können unterschiedliche Perspektiven gebildet werden. Eine Perspektive ist dabei nicht einfach ein anderer Filter. Sie beschreibt eine fachliche Hypothese darüber, welche Aktivitäten, Zustände und Abhängigkeiten für eine bestimmte Fragestellung relevant sind.
Vertrieb: vom Lead bis zum Auftrag
Für den Vertrieb interessieren zunächst weder Materialbeschaffung noch Tiefbau oder Inbetriebnahme. Relevant ist die kommerzielle Strecke vom Lead über Qualifizierung und technische Kalkulation bis zu Angebot, Vertrag und Auftrag.
Damit lassen sich Fragen untersuchen wie:
- Wo verlieren wir Leads?
- Wo entsteht Nacharbeit im Angebotsprozess?
- Wie lange dauert die technische Kalkulation bis zum Angebot?
- Welche Abweichungen sind echte Fehlermuster und welche lediglich zulässige Varianten?
Gewerkekoordination: welche Voraussetzungen müssen gemeinsam erfüllt sein?
Für die Bau- und Projektsteuerung ist eine andere Sicht notwendig.
Hier geht es um die Frage, welche Voraussetzungen erfüllt sein müssen, bevor die Baudurchführung beginnen kann. Tiefbau, Hausanschluss und unterschiedliche Materialstränge laufen parallel und münden in einen gemeinsamen Folgeschritt.
Übergabeprotokoll: Prozesszustände statt nur Zeitstempel
Für die Übergabe ist wiederum eine stark reduzierte Sicht sinnvoll.
Die relevante Frage lautet hier: Welche Zustände des Übergabeprotokolls müssen erreicht sein, bevor die Lieferung beginnen darf?
End-to-End: vom Lead bis zum Lieferbeginn
Für Management- oder End-to-End-Fragen wird wieder eine größere Perspektive benötigt.
Damit wird sichtbar: Die unterschiedlichen Perspektiven greifen auf dasselbe Prozesswissen zurück. Sie reduzieren lediglich die Komplexität auf die jeweilige Fachfrage.
Der Event Knowledge Graph bewahrt die Granularität und Beziehungen des realen Prozesses; Perspektiven reduzieren diese Komplexität anschließend auf die konkrete Fachfrage.
3. Die Prozessrealität: vom Gesamtbild bis zum einzelnen ERP-Objekt
Die End-to-End-Perspektive zeigt zunächst das Big Picture des Fernwärmeanschlusses.
Auf dieser Ebene lassen sich Übergangszeiten zwischen Aktivitäten, Start- und Endzeiten, Änderungszeiten und Zustände betrachten. Interessant wird es jedoch erst, wenn eine Auffälligkeit sichtbar wird und der Anwender tiefer gehen möchte.
Ein Beispiel ist die Beschaffung technischer Anlagen.
Detailansicht des Beschaffungsstrangs an der Aktivität „Equipment ordered“
Im Demonstrationsdatensatz sind an der Aktivität „Equipment ordered“ insgesamt 1.758 Beschaffungsobjekte sichtbar. 550 davon werden in der gezeigten Prozesssicht nicht bis zur anschließenden Lieferung fortgeführt.
Die Zahl bleibt jedoch nicht als abstrakte Kennzahl stehen. Ein Klick auf die Aktivität führt direkt zu den zugrunde liegenden Objektdaten.
Dort können unter anderem Lieferant, Bestelldatum, PSP-Element, Menge und Grund analysiert werden. In der synthetischen Demo ist modelliert, dass ein Teil der Beschaffungsobjekte bei einem ersten Lieferanten mit dem Grund „Nicht lieferbar“ endet und der erfolgreiche Pfad über einen anderen Lieferanten weiterläuft.
Der Anwender kann anschließend bis auf den einzelnen Geschäftsfall heruntergehen.
Auf dieser Ebene wird sichtbar, wie verschiedene Beschaffungsobjekte innerhalb desselben Geschäftsfalls zusammenhängen. Einzelne Bestellversuche können ausfallen, während ein späterer Bestellpfad erfolgreich bis zur Lieferung und Zahlung weiterläuft.
Damit lässt sich eine Auffälligkeit vom Gesamtprozess über den betroffenen Prozessabschnitt bis auf die konkreten Objekte und ihre Beziehungen zurückverfolgen.
Eine Kennzahl ist damit nicht das Ende der Analyse. Vom Prozessbild kann der Prozessmanager bis zu den betroffenen ERP-Objekten, ihren Attributen und ihren Beziehungen zurückgehen.
4. Fehlermuster statt Variantenexplosion
Eine Prozessanalyse wird schnell unübersichtlich, wenn jede Abweichung automatisch als neue Variante behandelt wird. Für einen Prozessverantwortlichen ist jedoch weniger entscheidend, ob eine Ausführung formal Variante 127 oder Variante 342 ist.
Die fachlich interessantere Frage lautet:
Welches wiederkehrende Fehlermuster steckt hinter diesen Ausführungen?
Ein Beispiel ist die Nachbearbeitung im Angebotsprozess.
Zwischen der Erstellung und dem Versand eines Angebots zeigt die Demo 154 Nachbearbeitungen bei 1.208 betrachteten Vorgängen. Das entspricht rund 13 Prozent und deckt sich mit der im synthetischen Datensatz modellierten Rework-Logik.
Noreja behandelt diese Wiederholung nicht einfach als neue Prozessvariante, sondern interpretiert sie fachlich als Nachbearbeitung.
Dasselbe Prinzip zeigt sich später im Prozess bei der Faktura.
Hier ist bei 106 von 1.089 Vorgängen eine spätere Änderung beziehungsweise Nachbearbeitung sichtbar. Auch hierfür enthält der Demonstrationsdatensatz ein eigenes Rework-Muster.
Auf diese Weise lassen sich unterschiedliche Abweichungen in fachlich verständliche Kategorien übersetzen, beispielsweise:
- Abbruch,
- Nachbearbeitung,
- Ignorieren beziehungsweise Übersprung,
- Reihenfolgefehler,
- Bündelung.
Der Vorteil liegt nicht nur in einer übersichtlicheren Darstellung. Die Analysefrage verändert sich:
Nicht mehr: „Welche Variante ist das?“
Sondern: „Welches Fehlermuster liegt vor, warum entsteht es und welche Auswirkung hat es?“
5. Von der Einzelverzögerung zum wiederkehrenden Zeitmuster
Eine lange Durchlaufzeit in einem einzelnen Geschäftsfall sagt noch wenig darüber aus, ob ein strukturelles Problem vorliegt.
Deshalb kann dieselbe Aktivität zunächst über alle betroffenen Prozessinstanzen betrachtet werden.
In diesem Beispiel betrachten wir Start und Ende der Baudurchführung. Jeder Punkt bleibt einem konkreten Geschäftsfall zuordenbar.
Die nächste Frage lautet:
Handelt es sich bei langen Bauzeiten um einzelne Ausreißer oder um ein wiederkehrendes Muster?
Dafür lässt sich aus denselben Prozessdaten eine Zeitreihe erzeugen.
Im synthetischen Datensatz wird ein deutliches saisonales Muster sichtbar. Während die Baudurchführung in den wärmeren Monaten überwiegend kürzer ist, steigt die Dauer ab November deutlich an und bleibt über die Wintermonate erhöht. Ab April geht sie wieder zurück.
Der Nutzen liegt weniger in der konkreten Demo-Zahl als im Analyseweg:
Nicht nur: „Ist unser Gesamtprozess im Winter langsamer?“
Sondern:
„Welcher konkrete Teil des Prozesses wird langsamer, wann beginnt der Effekt, wie stark ist er und wiederholt er sich?“
Damit bleibt auch eine Zeitreihe mit der Prozessstruktur verbunden und kann wieder auf konkrete Zeiträume, Fälle und Objekte zurückgeführt werden.
6. Kausale Prozesslogik: nicht nur wann, sondern warum
Die bisherige Analyse zeigt, was im Prozess passiert. Für Prozessverbesserung reicht Transparenz jedoch nicht aus. Entscheidend ist die Erklärung.
Beispiel Übergabeprotokoll
In der gezeigten Perspektive betrachten wir Geschäftsprozesse, bei denen ein Übergabeprotokoll angelegt wurde. Ein Teil erreicht anschließend nicht alle fachlich erwarteten Zustände, bevor der Lieferbeginn erfolgt.
Damit wird die Frage wichtiger als die reine Eventfolge:
Waren zum Zeitpunkt des Lieferbeginns alle fachlichen Voraussetzungen erfüllt?
Im Prozesswissen kann hinterlegt werden, welche Zustände notwendig sind, bevor ein Folgeschritt fachlich zulässig ist. Dadurch lässt sich zwischen regulärem Ablauf, Übersprung, Reihenfolgefehler und möglicherweise nur verspäteter digitaler Dokumentation unterscheiden.
Gerade bei Vor-Ort-Prozessen ist diese Unterscheidung wichtig. Ein verspäteter Zeitstempel im ERP-System muss nicht bedeuten, dass der reale Prozess ebenfalls verspätet stattgefunden hat. Fehlende Konnektivität oder eine spätere Synchronisierung können dasselbe sichtbare Symptom erzeugen.
Das führt zu einer wichtigen Erkenntnis:
Ein Prozessfehler und ein Datenfehler können im Eventlog gleich aussehen – benötigen aber völlig unterschiedliche Maßnahmen.
7. Parallele Gewerke: der nächste Schritt hängt von mehreren Voraussetzungen ab
Nach dem Auftrag wird die eigentliche Komplexität besonders sichtbar.
Mehrere Stränge laufen parallel: Hausanschluss und Bauplanung, Fremdleistungen sowie Materialbeschaffung für Rohre, Kabel und technische Anlagen.
Die Teilprozesse besitzen unterschiedliche Laufzeiten, Objekte und Kardinalitäten. Ein einzelner Fernwärmeanschluss kann mehrere Bestellungen, Lieferungen oder Rechnungen erzeugen. Ein Geschäftsfall ist deshalb nicht dasselbe wie ein einzelnes Geschäftsobjekt.
Der gemeinsame Baustart wird zur fachlichen Synchronisationsstelle:
Nicht eine einzelne Aktivität bestimmt, wann gebaut werden kann. Mehrere Voraussetzungen müssen gemeinsam erfüllt sein.
Damit verändert sich auch die klassische Bottleneck-Frage.
Nicht: „Welche Aktivität dauert am längsten?“
Sondern:
„Welche Voraussetzung hält den gemeinsamen nächsten Schritt zurück?“
Gefilterte Fallgruppe
In dieser gefilterten Sicht sind mehrere Voraussetzungen bereits weit fortgeschritten. Trotzdem wird der gemeinsame nächste Schritt nicht erreicht.
Damit wird aus der Aktivitätsanalyse eine kausale Frage: Welche fachliche Voraussetzung fehlt noch?
Einzelinstanz: vom Symptom zur konkreten Ursache
In diesem Geschäftsfall sind Planung, Fremdleistung und mehrere Materialstränge bereits abgeschlossen oder weit fortgeschritten. Trotzdem startet die Bauausführung nicht.
Im hinterlegten Prozesswissen ist der Baustart jedoch als AND-Abhängigkeit mehrerer Voraussetzungen modelliert. In diesem konkreten Demonstrationsfall fehlt die erforderliche Kundenanzahlung.
Damit kann zwischen einer zeitlichen Beobachtung und einer fachlichen Erklärung unterschieden werden:
Beobachtung: Der Baustart erfolgt nicht.
Erklärung: Der Baustart erfolgt nicht, obwohl mehrere technische Voraussetzungen erfüllt sind, weil eine notwendige kaufmännische Voraussetzung fehlt.
Das ist der Kern der kausalen Prozesslogik:
Noreja kennt nicht nur, was passiert ist, sondern auch, welche Voraussetzungen erfüllt sein müssen, damit etwas passieren kann.
8. Bündelung: wenn die Ursache außerhalb des einzelnen Falls liegt
Die Logik kann noch einen Schritt weitergehen.
Stellen wir uns drei Fernwärmeanschlüsse in derselben Straße vor. Für jeden Anschluss existieren eigene Planungen, Materialbedarfe, Genehmigungen und Hausanschlüsse. Operativ wäre es jedoch wenig sinnvoll, dieselbe Straße für jeden Anschluss separat aufzugraben.
Der Netzbetreiber kann deshalb mehrere Anschlüsse zu einer gemeinsamen Tiefbaumaßnahme bündeln.
Dann kann Anschluss A vollständig bereit sein – und trotzdem warten. Vielleicht fehlt bei Anschluss B noch eine Genehmigung oder bei Anschluss C eine andere Voraussetzung.
Aus der isolierten Historie von Anschluss A wäre nur eine unerklärliche Liegezeit sichtbar.
Erst wenn die Beziehung zur gemeinsamen Tiefbaumaßnahme und zu den anderen Anschlüssen bekannt ist, wird die Ursache verständlich:
Anschluss A wartet nicht wegen eines Fehlers innerhalb seines eigenen Prozesses, sondern aufgrund einer Abhängigkeit zu anderen Prozessinstanzen.
Dieses Beispiel ist bewusst theoretisch und kein gemessenes Finding des gezeigten synthetischen Datensatzes. Es illustriert jedoch einen wichtigen methodischen Punkt:
Nicht jede Ursache eines Prozessproblems liegt innerhalb derselben Prozessinstanz.
Gerade solche Cross-Instance-Beziehungen sind ein starkes Argument für einen Event-Knowledge-Graph-Ansatz.
9. Minerva: mit der Fachfrage beginnen statt mit View und Filter
Je mehr Perspektiven, Objekte, Fehlermuster und Zeitreihen verfügbar sind, desto mächtiger wird die Analyse – aber auch desto komplexer kann die Bedienung werden.
Ein Prozessmanager sollte deshalb nicht zuerst wissen müssen, welche View, welchen Filter oder welche Visualisierung er benötigt.
In der gezeigten Demo wird Minerva nach einer übergreifenden Analyse von Vertrieb, Gewerkekoordination sowie Anschluss und Inbetriebnahme gefragt. Die Übergabeprotokolle werden separat betrachtet.
Minerva erzeugt daraus eine Management-Zusammenfassung, vergleicht verschiedene Prozessbereiche und identifiziert die größten Zeithebel. In der Demo treten unter anderem längere Zeiten im Vertrieb, in der Gewerkekoordination und vor beziehungsweise rund um die Bauausführung auf.
Der entscheidende Nutzen ist nicht, dass KI den Prozessmanager ersetzt.
Sondern:
Der Anwender kann mit einer fachlichen Frage beginnen, anstatt zuerst wissen zu müssen, welche Ansicht, welcher Filter und welche Visualisierung dafür benötigt werden.
Minerva nutzt das im Knowledge Graph hinterlegte Prozesswissen, die Perspektiven und den verfügbaren Kontext, um daraus einen Analyseweg und mögliche Handlungsoptionen zu erzeugen.
10. Vom Finding zur priorisierten Verbesserungsinitiative
Ein Finding verbessert noch keinen Prozess.
Deshalb endet die Analyse nicht bei der Erkenntnis. Die nächste Frage lautet: Welche Maßnahme lohnt sich tatsächlich?
Im Impact Board werden Findings nach Wirkung, Umsetzungsaufwand und Ungewissheit bewertet. Dadurch lassen sie sich als Quick Wins, strategische Initiativen, Low-Priority-Themen oder zu verschiebende Maßnahmen einordnen.
Ein Finding kann zusätzlich mit der Evidenz aus der Analyse dokumentiert werden.
Aus einer Prozessauffälligkeit wird damit eine konkrete Verbesserungsinitiative. Für die Bewertung können unterschiedliche Kosten- und Wirkungskategorien genutzt werden, beispielsweise Wartezeit, Ressourcenverschwendung, SLA-Verletzung, Kapitalbindung, entgangener Umsatz, Compliance-Risiko oder Nacharbeit.
Minerva kann mögliche Maßnahmen vorschlagen. Die Entscheidung bleibt jedoch beim Menschen.
Process Excellence und Fachbereich bewerten gemeinsam, welche Maßnahme wirtschaftlich und organisatorisch sinnvoll ist.
Damit wird aus analytischer Evidenz eine priorisierbare Entscheidung.
11. Der eigentliche Kreislauf: Insight, Action, Impact, Feedback
Der vollständige Verbesserungsprozess endet nicht bei der Umsetzung.
Nach einer Maßnahme muss erneut geprüft werden:
- Hat sich die Durchlaufzeit tatsächlich verbessert?
- Ist ein Fehlermuster seltener geworden?
- Hat sich der betroffene Prozessabschnitt stabilisiert?
- Ist die erwartete Wirkung tatsächlich eingetreten?
Damit entsteht ein geschlossener Kreislauf:
Insight → Action → Impact → Feedback
Oder aus Sicht des Prozessmanagers:
Erkennen → verstehen → bewerten → umsetzen → messen.
Gerade mit zunehmendem KI- und Automatisierungseinsatz wird dieser letzte Schritt wichtiger. Die Frage lautet nicht nur: „Haben wir jetzt KI oder Automation eingesetzt?“
Sondern:
„Ist der Prozess dadurch tatsächlich schneller, stabiler oder qualitativ besser geworden?“
Fazit: Nicht mit dem Tool beginnen, sondern mit der Prozessfrage
Der Fernwärmeanschluss zeigt, warum komplexe Prozesse selten mit einer einzigen Prozesskarte verstanden werden können.
Die End-to-End-Perspektive zeigt das Gesamtbild. Die Vertriebsperspektive macht Abbrüche und Nacharbeit sichtbar. Die Gewerkekoordination erklärt parallele Voraussetzungen und gemeinsame Meilensteine. Die Übergabeprotokolle zeigen, dass reale Prozesszustände und digitale Zeitstempel auseinanderfallen können.
Alle Perspektiven greifen jedoch auf dasselbe Prozesswissen zurück.
Daraus ergeben sich vier zentrale Prinzipien:
- Granularität erhalten: Geschäftsobjekte und ihre Beziehungen werden nicht frühzeitig in einen flachen Eventlog wegaggregiert.
- Komplexität fachlich reduzieren: Perspektiven beantworten konkrete Prozessfragen, ohne die zugrunde liegenden Informationen zu verlieren.
- Ursachen statt nur Auffälligkeiten analysieren: Prozessverhalten wird gegen fachliche und kausale Abhängigkeiten bewertet.
- Erkenntnisse operationalisieren: Findings werden zu Maßnahmen, wirtschaftlich bewertet und anschließend wieder gegen die Prozessdaten gemessen.
Die vielleicht wichtigste Erkenntnis lautet deshalb:
Transparenz allein reicht nicht. Für Prozessverbesserung braucht man eine Erklärung – und anschließend den Nachweis, dass die gewählte Maßnahme tatsächlich wirkt.