Viele Serviceorganisationen erwarten von KI zweierlei: weniger Personalbedarf und eine bessere Wissenslogistik. Das erste ist eine Rechnung, das zweite eine Hoffnung. Beide gehen von derselben Annahme aus — dass das Wissen, das gebraucht wird, bereits im System liegt und nur noch gehoben werden muss.
Im technischen Service stimmt diese Annahme selten. Drei Fälle aus der Praxis zeigen, warum — und sie zeigen drei verschiedene Lücken.
- Ein Beispiel aus einem Software- und Hardwarehaus
- Warum der Weg nicht dokumentiert wird
- Der Drucker war der Anlass, nicht die Information
- Auf der Baustelle zählt, was nicht im Auftrag steht
- Drei Arten von Verlust
- Was die Forschung dazu sagt
- Warum das im Service schwerer wiegt
- Mit KI denken, nicht gegen sie
- Was das für Digitalisierungsvorhaben bedeutet
Ein Beispiel aus einem Software- und Hardwarehaus
Ein erfahrener Servicetechniker wechselt die Rolle. Er arbeitet jetzt an der Schnittstelle zwischen Produktmanagement und Service und verantwortet die User Experience. Aus seiner Zeit im Feld kann er sofort sagen, welche Komponenten welche Störungen nach sich ziehen — und woran die Kolleginnen und Kollegen draußen regelmäßig verzweifeln.
Dieses Wissen steht in keiner Datenbank. Und der Grund dafür ist aufschlussreich: Wer improvisiert, findet eine Lösung. Im System landet danach die aufgewendete Zeit und das Ergebnis — der Weg dorthin nicht.
Für die Abrechnung reicht das. Für ein KI-Modell, das aus Falldaten lernen soll, fehlt damit genau der Teil, der die Erfahrung ausmacht.
Warum der Weg nicht dokumentiert wird
Das ist keine Nachlässigkeit, sondern eine Folge davon, wie Servicesysteme gebaut sind und wozu sie gebraucht werden.
Das Ticket fragt nach dem Ergebnis
Pflichtfelder sind Kategorie, Lösungszeit, Status. Ein Feld für „was ich zuerst vermutet habe und warum das falsch war“ gibt es nicht — und niemand hätte im Tagesgeschäft Zeit, es zu füllen.
Improvisation gilt als Ausnahme
Eine Lösung, die vom Standard abweicht, wird als Einzelfall behandelt. Dabei ist sie oft der Hinweis auf ein Muster, das noch niemand beschrieben hat.
Der Verdacht kommt vor dem Symptom
Erfahrene Leute hören am Telefon, dass etwas nicht stimmt, bevor die Symptome zusammenpassen. Diese Mustererkennung stammt aus hunderten Fällen — dokumentiert ist keiner davon als Muster.
Das Bauchgefühl ist selbst Datenverarbeitung — nur unerfasste. Wer es als weiches Wissen abtut, unterschätzt, wie viel Auswertung dahintersteckt.
Der Drucker war der Anlass, nicht die Information
Ein zweiter Fall, aus einer internen IT. Auf dem Tisch liegt ein Ticket zu einem defekten Drucker in einem Fachbereich. Auf die Frage, wen aus seinem Team er hinschickt, antwortet der Teamleiter Client Support: „Das schaue ich mir selber an. Ab und an ist es ganz gut mitzukriegen, was in den Fachbereichen so passiert.“
Bei einem dieser Termine erfuhr er nebenbei, dass bestimmte Produktionslisten häufig nicht aktuell sind — mit der Folge, dass Ware an Kunden ausgeliefert wird, die längst gekündigt haben.
Diese Information hat mit dem Drucker nichts zu tun. Sie stand in keinem Ticket, sie war nicht Gegenstand des Auftrags, und sie wäre über keinen Kanal gekommen, den die IT betreibt. Sie entstand, weil jemand vor Ort war und zugehört hat.
Für das Unternehmen ist sie bares Geld — und ein Anlass zur Ursachenforschung. Für die IT ist sie etwas anderes: ein Stück Verständnis dafür, was das Geschäft gerade umtreibt. Genau das Verständnis, das in jeder Diskussion über Business-IT-Alignment gefordert und selten geliefert wird.
Auf der Baustelle zählt, was nicht im Auftrag steht
Ein dritter Fall, aus dem Field Service. Ein Techniker betreut eine Anlage, die von einer Komponente eines anderen Lieferanten abhängt. Bevor er losfährt, will er zwei Dinge wissen: auf welche Baustelle er kommt und wer beim Kunden vor Ort ansprechbar ist.
Der Grund liegt in dem, was er über die andere Seite weiß. Er kennt die Arbeitsweise des anderen Lieferanten gut genug, um einzuschätzen, was eine Änderung an dessen Komponente für sein eigenes System bedeutet. Und wenn die richtige Person aus Facility Management und Betrieb dabei ist, beschreibt er das so: „Dann kommen wir in einen guten Flow und rufen uns auch Themen zu.“
Wie er das löst, steht in keinem System. Der Auftrag kennt die Anlage, nicht das Umfeld, in dem sie läuft.
Ein Stück dieses Wissens sitzt noch tiefer. Die Geräusche der Maschinen beider Lieferanten sind den Technikern fest im Gehör verankert — sie hören, ob die Systeme rund laufen.
Die Techniker hören, ob die Systeme rund laufen. Da kann ja keine KI etwas sagen.
Servicetechniker im Field Service
Das ist Erfahrungswissen, das nicht zwingend in eine Datenbank wandert — und in Teilen auch gar nicht wandern kann.
Drei Arten von Verlust
Die drei Fälle zeigen unterschiedliche Lücken, und sie brauchen unterschiedliche Antworten.
Was nicht vollständig erfasst wird
Der Weg zur Lösung. Er entsteht im System, oft wird nur sein Ergebnis festgehalten. Hier hilft, das Erfassen zu ändern — ein Feld für den Lösungsweg und Lösungsversuche mehr, bringt erheblich mehr Servicewissen.
Was gar nicht erst ins System gehört
Die Nebenbei-Information aus dem Gespräch. Sie ist kein Teil des Auftrags und wird es auch nie sein. Hier hilft nur, den Anlass für das Gespräch zu erhalten — und einen Weg, das Gehörte weiterzugeben.
Was sich nicht in Daten überführen lässt
Das Klangbild einer Anlage, das Gespür für den richtigen Ansprechpartner. Kein zusätzliches Feld erfasst das. Hier hilft nur die Weitergabe von Mensch zu Mensch — Mitfahren, Tandem, gemeinsame Einsätze.
Die zweite Lücke ist die unauffälligere. Ein Effizienzprogramm würde den Einsatz des Teamleiters streichen: zu teuer für einen Drucker. Er hat ihn als Investition verstanden — und das ist eine Führungsentscheidung, keine Ineffizienz.
Die dritte ist die, über die am seltensten gesprochen wird. Wer Wissenssicherung als Dokumentationsaufgabe versteht, plant für diesen Teil gar nichts ein — obwohl er im technischen Service oft den Unterschied zwischen einem guten und einem durchschnittlichen Einsatz ausmacht.
Hier schließt sich ein Kreis. Wo Remote-Lösung, Self-Service und KI gemeinsam die einfachen Fälle abfangen, verschwindet der Anlass für den persönlichen Kontakt. Mit ihm verschwindet der Kanal, über den diese Informationen kommen — und niemand vermisst ihn, weil er nie in einem Bericht stand. Dasselbe gilt für den Flurfunk, der mit der Verlagerung ins Homeoffice weggefallen ist: eine Quelle, deren Fehlen sich erst bemerkbar macht, wenn Entscheidungen auf dünnerer Grundlage getroffen werden.
Was die Forschung dazu sagt
Jin Gerlach (Universität Passau) und Donald Lange (Arizona State University) haben diesen Zusammenhang 2026 in der Academy of Management Review beschrieben. Ihre Arbeit „Fading Memories“ ist eine Theoriestudie: Sie erhebt keine eigenen Daten, sondern verbindet vorhandene Erkenntnisse aus Organisationsforschung und Informatik zu einem Prozessmodell.
Das Modell beschreibt einen Kreislauf in drei Schritten:
#01
KI übernimmt
Aufgaben wandern an das System. Die menschliche Fachkompetenz, die dafür nötig war, wird seltener gebraucht — und damit weniger geübt.
#02
Wissen verschwindet
Vorhandenes Wissen geht mit den Menschen, die gehen. Neue Mitarbeitende erwerben es gar nicht erst, weil die Situationen, in denen es entstand, nicht mehr bei ihnen landen.
#03
Das Modell altert
Ein KI-Modell braucht menschliche Expertise, um aktuell zu bleiben. Genau die fehlt dann — und die Qualität sinkt, ohne dass es jemandem auffällt.
Verlorenes menschliches Fachwissen kann im Zeitverlauf die Qualität von KI-Modellen beeinträchtigen — im schlimmsten Fall schleichend und unbemerkt.
Gerlach & Lange: Fading Memories. The Role of Machine Learning in Organizational Knowledge Depreciation. Academy of Management Review, 2026
Der dritte Schritt ist der wichtigste, und er wird meist übersehen. Die Frage ist nicht, ob KI dem Menschen schadet. Die Frage ist, woher die Erfahrung kommen soll, aus der das Modell von übermorgen lernt.
Warum das im Service schwerer wiegt
In standardisierten Tätigkeiten ist der Verlust überschaubar — dort ist der Weg zum Ergebnis ohnehin beschrieben. Technischer Service funktioniert anders.
Eine Störung hat selten nur eine Ursache. Es spielen Gerätezustand, Einsatzumgebung, Bedienung, Vorgeschichte und manchmal die Tagesform einer Anlage zusammen. Im vorausschauenden und präventiven Service kommt hinzu, dass die entscheidende Beobachtung gemacht wird, bevor ein Fall überhaupt entsteht — und damit bevor irgendein System ihn erfassen könnte.
Je größer die Situationsvielfalt, desto größer der Anteil des Wissens, der nie in strukturierter Form vorlag. Genau deshalb trifft der beschriebene Kreislauf den Service früher und härter als andere Bereiche.
Mit KI denken, nicht gegen sie
Die Folgerung ist ausdrücklich keine Zurückhaltung bei KI. Sie lautet: Die Art, wie Erfahrungswissen gesichert wird, gehört neu gedacht — und zwar gemeinsam mit den Systemen, nicht als Gegenprogramm.
Den Weg erfassen, nicht nur das Ergebnis
Ein Feld für den ersten Verdacht und ein Feld für das, was nicht funktioniert hat. Zwei Zeilen im Ticket, freiwillig und kurz — aber genau der Teil, der später Muster erkennbar macht.
Improvisation zur Meldung machen
Wer vom Standard abweicht, hat einen Grund. Ein leichter Weg, das zu melden, verwandelt Einzelfälle in Hinweise auf Produkt- und Prozessschwächen.
Rollen schaffen, die übersetzen
Die Position an der Schnittstelle zwischen Service und Produktmanagement ist kein Karriereparkplatz, sondern eine Wissensbrücke. Sie macht Felderfahrung für die Entwicklung nutzbar, solange sie noch da ist.
Neue Leute in echte Fälle bringen
Wenn die KI die einfachen Fälle löst, fehlt Berufseinsteigern die Übung, an der früher Erfahrung wuchs. Das gehört bewusst gestaltet — mit Fällen zum Mitarbeiten statt zum Nachschlagen.
Kontakt bewusst einplanen
Wenn der Anlass für das persönliche Gespräch wegfällt, gehört er neu geschaffen — als Termin im Fachbereich, als Begehung, als regelmäßiger Austausch. Was dabei zu hören ist, braucht außerdem einen Weg zurück in die Organisation.
Den Einsatzkontext mitliefern
Welche Baustelle, welche Nachbarsysteme, wer vor Ort ansprechbar ist. Diese Angaben gehören in die Einsatzvorbereitung — sie entscheiden mit, ob ein Termin in einen guten Ablauf kommt oder in Wartezeit.
Weitergeben, was sich nicht aufschreiben lässt
Klangbilder, Gespür, Umgang mit dem Kundenumfeld entstehen im gemeinsamen Einsatz. Tandems und Mitfahrten sind dafür kein Zusatz, sondern das einzige Übertragungsmedium.
Wissensdatenbank als Arbeitsmittel führen
Eine Datenbank, die niemand pflegt, veraltet schneller als das Produkt. Wer sie als Nebenprodukt behandelt, bekommt die Qualität eines Nebenprodukts.
Die Prüffrage für Ihre Organisation: Wenn Ihre drei erfahrensten Servicekräfte morgen aufhören — wie viel von dem, was sie wissen, steht irgendwo? Und wie viel davon steht so, dass jemand anderes damit arbeiten kann? Der Abstand zwischen beiden Antworten ist Ihr eigentliches Risiko.
Was das für Digitalisierungsvorhaben bedeutet
Die Reihenfolge, die wir in Digitalisierungsprojekten empfehlen — erst standardisieren, dann digitalisieren, dann automatisieren — bekommt durch diesen Befund eine zusätzliche Begründung.
Standardisieren heißt nämlich nicht nur, Abläufe zu vereinheitlichen. Es heißt auch festzulegen, was dokumentiert wird. Wer diesen Schritt überspringt und direkt automatisiert, trainiert ein Modell auf Daten, die den interessanten Teil der Arbeit nie enthalten haben.
