KI im IT-Service scheitert selten am Modell. Sie scheitert an dem, was darunter liegt.
Ein Sprachmodell kann eine Störung nicht zuordnen, wenn niemand weiß, welches System betroffen ist, wer es betreibt und wovon es abhängt.
Es kann keine Lösung vorschlagen, wenn die letzte belastbare Dokumentation im Kopf eines Kollegen liegt, der seit zwei Jahren woanders arbeitet.
Es kann nicht priorisieren, wenn Kritikalität nirgends gepflegt ist.
Vier Voraussetzungen, in dieser Reihenfolge:
1. Bestand. Was existiert überhaupt, wer verantwortet es, wovon hängt es ab? Ohne verlässliches Configuration Management ist jede Automatisierung Raten mit besserer Grammatik.
2. Historie. Sauber kategorisierte Tickets über mindestens zwölf Monate. Ein Modell lernt aus Mustern — nicht aus Freitextfeldern, in denen „geht nicht" steht.
3. Wissen. Dokumentierte Lösungswege. Nicht als Sammlung von Dateien, sondern strukturiert und gepflegt.
4. Prozess. Klar definierte Abläufe. Automatisierung beschleunigt einen Prozess — sie ersetzt ihn nicht. Ein unklarer Prozess wird durch Automatisierung nur schneller unklar.
Erst danach lohnt sich die Frage nach dem Werkzeug.
Die unbequeme Konsequenz: Der größte Teil eines KI-Projekts im Service Management ist kein KI-Projekt. Es ist Datenarbeit, die seit Jahren aufgeschoben wurde.
Deshalb scheitern so viele Piloten — nicht an der Technologie, sondern daran, dass niemand die Grundlage bezahlen wollte.
Wer diese vier Punkte sauber hat, braucht für den Rest überraschend wenig.
Wer an einem dieser vier Punkte unsicher ist: schreibt mir, ich schicke euch die Checkliste.
Dieser Impuls erscheint parallel auf LinkedIn. Diskussion gern dort.
Alle Beiträge