Vier Muster, an denen KI-Vorhaben versanden

Das Vorhaben ohne Vorgang

Ein Projekt startet mit einer Technologie und sucht danach eine Aufgabe. Erkennbar ist das an der Beschreibung: Sie nennt ein Werkzeug oder eine Fähigkeit, aber keinen Vorgang mit Menge, Dauer und Verantwortlichem. „Wir wollen Wissensmanagement mit KI verbessern“ ist kein Anwendungsfall. „Die Serviceabteilung beantwortet im Monat eine bestimmte Zahl gleichartiger Anfragen und braucht dafür im Schnitt so viele Minuten“ ist einer.

Der Test ist einfach: Frag, wer das Ergebnis benutzen wird, wie oft, und was diese Person heute stattdessen tut. Wenn darauf keine Antwort mit Namen und Zahl kommt, ist das Vorhaben nicht startbereit, egal wie gut die Technologie passt.

Die Daten, die erst nach dem Start zum Thema werden

In der Planung ist von Daten die Rede, im Bau von Zugriff. Zwischen beidem liegen Berechtigungen, Datenschutzprüfung, Verträge mit Anbietern, Qualität und Formate. Werden diese Punkte erst geklärt, während das Team schon gebucht ist, entsteht die typische Lücke von mehreren Wochen, in denen das Vorhaben Geld kostet und nichts entsteht.

Häufiger als fehlender Zugriff ist eine ungeeignete Datenlage. Die Dokumentation existiert, ist aber über Jahre in verschiedenen Ständen abgelegt, ohne Kennzeichnung, welcher der gültige ist. Ein Assistent, der daraus antwortet, gibt veraltete Auskünfte, und der Fehler wirkt wie ein Modellfehler, obwohl er in der Ablage sitzt. Deshalb gehört eine Stichprobe der echten Dokumente in die Bewertung, bevor das Vorhaben freigegeben wird.

Kein Name auf dem Ergebnis

In vielen Vorhaben gibt es eine Projektleitung, einen Lenkungskreis und einen Dienstleister, aber niemanden, dessen eigene Ziele sich ändern, wenn das Vorhaben gelingt oder scheitert. Solange die Fachabteilung das Projekt als etwas betrachtet, das die IT ihr bringt, wird sie es prüfen, aber nicht durchsetzen.

Wirksam ist eine einzige Person aus dem Fachbereich, die den Vorgang verantwortet, die vereinbarte Kennzahl trägt und die Befugnis hat, Arbeitsabläufe zu ändern. Ohne diese Befugnis scheitert die Einführung an Kleinigkeiten, weil jede Anpassung an einem Ablauf zur Verhandlung wird.

Ein verwandtes Muster ist die stille Ablehnung. Beschäftigte, die vermuten, dass die Automatisierung ihre Aufgaben ersetzen soll, arbeiten formal mit und nutzen das Ergebnis nicht. Das lässt sich nicht mit Kommunikation heilen, sondern nur mit einer klaren Aussage dazu, was mit der frei werdenden Zeit passiert, und diese Aussage muss von der Geschäftsführung kommen.

Das Pilotprojekt ohne Tür in den Betrieb

Ein Pilotprojekt läuft erfolgreich, alle sind zufrieden, und dann passiert nichts mehr. Der Grund ist fast immer derselbe: Es war nie geklärt, wer den Betrieb übernimmt, aus welchem Budget die laufenden Kosten kommen, wer Anwenderfragen beantwortet und wer nachzieht, wenn sich das Modell oder das Quellsystem ändert. Für den Pilot gab es Projektmittel, für den Betrieb gibt es keine Zeile im Plan.

Der zweite Grund ist technischer Natur. Ein Pilotprojekt läuft mit einem Datenausschnitt, einer Handvoll Nutzer und einer von Hand gepflegten Konfiguration. Für den Betrieb braucht es Berechtigungskonzept, Protokollierung, Wiederanlauf, Betriebszeiten und eine Ansprechstelle. Wer das nicht von Anfang an einplant, baut das Pilotprojekt ein zweites Mal, diesmal richtig, und das erklärt einen guten Teil der Vorhaben, die nach der Erprobung versanden.

Abbrechen ist eine gültige Entscheidung

Formulier vor dem Start, welches Ergebnis zur Fortsetzung führt und welches zum Abbruch, mit Zahl, Messmethode und Zeitpunkt. Ein Vorhaben ohne Abbruchkriterium hört nie auf, es wird nur immer leiser, bindet weiter Leute und blockiert das nächste, das mehr gebracht hätte.

Ein Abbruch nach acht Wochen mit einer schriftlichen Begründung ist ein gutes Ergebnis. Er hat geklärt, dass dieser Weg nicht trägt, und liefert dem nächsten Vorhaben die Erkenntnisse gleich mit. Teams, in denen das ohne Gesichtsverlust möglich ist, kommen schneller zu den Fällen, die tatsächlich funktionieren.