„KI-fähige Daten“ heißt nicht, dass Ihre Tabellen digital sind, Ihr CRM in der Cloud läuft oder Sie ein Data Warehouse haben. Es heißt, dass der Prozess, der diese Daten erzeugt, einheitlich, dokumentiert und realitätsnah genug abgebildet ist, damit ein KI-System darauf aufsetzen kann, ohne jede undokumentierte Behelfslösung zu übernehmen, die Ihr Team über Jahre still aufgebaut hat. In jedem Readiness-Audit, das ich dieses Jahr durchgeführt habe, war genau dieser zweite Punkt — nicht der erste — die eigentliche Lücke.
Was „KI-fähig“ tatsächlich bedeutet
Vier Dinge müssen zutreffen, bevor Daten wirklich bereit für ein KI-Projekt sind — und keines davon sieht man in einer Tabelle. Das Format muss über den gesamten Workflow einheitlich sein, nicht nur in einer Ecke einer Abteilung. Es darf keine undokumentierten manuellen Ausnahmen geben — den Schritt „den machen wir einfach anders“, den alle kennen und niemand aufgeschrieben hat. Es muss eine nachvollziehbare Herkunft geben, damit Sie sagen können, woher eine Zahl stammt, und darauf vertrauen können, dass sie sich zwischen Systemen nicht verändert hat. Und der Prozess selbst muss so abgebildet sein, wie er tatsächlich abläuft — nicht so, wie es die Einarbeitungsfolien behaupten.
Beim letzten Punkt liegen fast alle Unternehmen falsch — und eine späte Erkenntnis kostet hier am meisten: nachdem ein KI-Tool bereits auf einem Prozess aufgebaut wurde, den niemand wirklich überprüft hatte.
Wo Process Mining die Lücke offenlegt
Process Mining rekonstruiert den Prozess, den Ihr Unternehmen tatsächlich lebt — anhand von Zeitstempeln und Systemprotokollen statt des Flussdiagramms, das vor drei Jahren jemand gezeichnet hat. Füttern Sie es mit Ereignisdaten — wer hat wann was bearbeitet — und es zeigt Ihnen jeden Pfad, den ein Fall tatsächlich genommen hat, nicht die drei oder vier Pfade, die man annimmt.
Das Muster ist bemerkenswert beständig. Ein Prozess, der als saubere dreistufige Freigabe beschrieben wird, entpuppt sich nach dem Mining als ein Dutzend oder mehr reale Varianten — Fälle, die einen Schritt übersprungen haben, Fälle, die zur Nacharbeit zurückliefen, und Fälle, die informell per E-Mail eskaliert wurden und das System, das sie erfassen sollte, nie berührt haben. Nichts davon ist in einem Organigramm oder einer Richtlinie sichtbar. Sichtbar ist es nur in den Daten, die der Prozess tatsächlich hinterlassen hat.
Das Muster, das ich immer wieder finde
Bei meinen Readiness-Mandaten in diesem Jahr zeigt sich immer wieder dasselbe Fehlermuster: eine Übergabe zwischen zwei Abteilungen, bei der das empfangende Team Informationen neu eingibt, die das sendende Team bereits hatte — weil die beiden Systeme nie wirklich verbunden waren, sondern das nur angenommen wurde. Jeder Schritt der Neueingabe ist eine Stelle, an der die Daten still von der Quelle abweichen, und genau diese Art Lücke bleibt unsichtbar, bis man versucht, die Übergabe selbst zu automatisieren.
Die Ausnahmepfade sind der andere beständige Befund. Jeder Prozess hat einen „Idealpfad“, der gestaltet und dokumentiert wird, und eine Reihe von Ausnahmen, die erledigt, wer gerade Zeit hat, so wie es im Moment sinnvoll erscheint. KI, die nur auf dem Idealpfad aufbaut, scheitert beim ersten Kontakt mit einer Ausnahme — und Ausnahmen machen meist 20–30 % des tatsächlichen Volumens aus, nicht die Rundungsdifferenz, die man vermutet.
Was vor jedem KI-Projekt geprüft werden sollte
Für den Einstieg braucht es keine teuren Tools. Bevor Sie ein KI-Projekt beauftragen, lohnt sich eine kurze Prüfliste — am tatsächlichen Prozess, nicht am dokumentierten:
- Durchläuft derselbe Falltyp mehr als zwei oder drei wirklich unterschiedliche Pfade im System?
- Gibt es irgendwo eine manuelle Neueingabe zwischen zwei Systemen, die als verbunden gelten?
- Können Sie schriftlich benennen, was auf dem Ausnahmepfad passiert — nicht nur auf dem Standardpfad?
- Hat in den letzten zwölf Monaten jemand den Prozess tatsächlich von Anfang bis Ende beobachtet, oder arbeiten alle nach dem ursprünglichen Design?
Über den Autor — Dr. Mahdi Seify, PhD, MBA, Engr.
Berater für KI-Strategie und KI-Governance mit Sitz in Milton Keynes. Gründer & Chief AI Officer von VisionXY7 sowie Senior Lecturer und Programme Leader des MSc Business Analytics an der University of Northampton. PhD (KI-gestützte Business Analytics, University of Liverpool) · MBA · ISO/IEC 27001 Lead Auditor & Implementer · über 25 Jahre Erfahrung in IT und Umsetzung aus mehr als 100 Projekten.