INSIGHTS

03

GOVERNANCE

AI-Projekte brauchen einen Business-Owner

AI-Projekte brauchen einen Business-Owner

AI-Projekte brauchen einen Business-Owner

Zwei Fälle aus der Praxis: warum funktionierende AI-Systeme am Kundenweg scheitern und wer die Verantwortung trägt.

Zwei Fälle aus der Praxis: warum funktionierende AI-Systeme am Kundenweg scheitern und wer die Verantwortung trägt.

Titelbild INSIGHTS 03: AI-Projekte brauchen einen Business-Owner

INSIGHTS

03

GOVERNANCE

AI-Implementierung ist längst kein Pilotprojekt mehr, über das einzelne Fachbereiche für sich entscheiden. Sie ist eine Frage geworden, die auf Vorstandsebene gehört. Trotzdem liegt sie in den meisten Unternehmen noch dort, wo sie historisch immer lag.

"63 Prozent der Unternehmen im Consumer-&-Retail-Sektor geben an, dass ihre IT-Funktion die Umsetzung von AI-Anwendungen federführend verantwortet."

— KPMG Global Tech Report 2026: Consumer & Retail

Das klingt zunächst nach Effizienz. Die IT kennt die Systeme, kann integrieren, kann skalieren. In der Praxis entsteht daraus regelmäßig ein anderes Muster: Die Technologie funktioniert. Das Geschäft dahinter nicht.

Der Chatbot, der alles wusste, aber nichts davon weitergab

Ich war vor Kurzem sehr lange im Chat von Vodafone unterwegs. Ausführlich, mit vielen Details zu meinem Anliegen. Der Chatbot funktionierte gut, ich kam an mehreren Stellen weiter. Irgendwann brauchte ich dann aber doch einen Menschen und wurde an die Hotline weitergeleitet.

Dort begann alles von vorn: die reguläre Warteschleife, die reguläre Wartezeit. Als der Agent schließlich dran war, musste ich sämtliche Informationen erneut eingeben. Nichts aus dem vorherigen Chat war für ihn sichtbar. Und als die Verbindung ausgerechnet in dem Moment abbrach, in dem der Agent den Anruf annahm, war das nur noch die Pointe auf ein Muster, das sich so oder ähnlich ständig wiederholt.

Weder der Chatbot noch die Hotline waren dabei fehlerhaft. Beide funktionierten für sich genommen einwandfrei. Der Bruch entstand exakt an der Schnittstelle zwischen beiden Systemen. Dort hätte mein Kontext mitwandern müssen, eine Verbindung dafür gab es schlicht nicht.

Die CRM-Strecke, die den Streik nicht kannte

Ein anderes Beispiel liefert Lufthansa. Rund 24 Stunden vor dem Abflug meines Mannes verschickte die Airline eine Upgrade-Mail, den regulären Touchpoint kurz vor Reisebeginn, gedacht, um den Flug durch Zusatzservices angenehmer zu machen. Zu genau diesem Zeitpunkt war wegen eines Streiks aber bereits öffentlich bekannt, dass völlig offen war, ob der Flug überhaupt stattfindet. Am Ende fiel er aus.

Eine gesonderte Krisenkommunikation dazu gab es nicht. Die reguläre Marketing-Strecke lief einfach weiter, unberührt von einer Information, die zu diesem Zeitpunkt öffentlich bekannt und für die Airline selbst zentral war. Auch hier blieb die Technologie fehlerfrei: Ein System folgte treu seiner eigenen Logik, obwohl sich die Realität der Kundschaft bereits verändert hatte.

Beide Erlebnisse haben denselben blinden Fleck: An genau der Stelle, an der ein Wechsel zwischen Systemen (Vodafone) oder ein Wechsel in der äußeren Realität (Lufthansa) stattfindet, geht der Kontext verloren, der vorher entweder mühsam aufgebaut oder ohnehin öffentlich verfügbar war.

Warum das kein Zufall ist

McKinsey beschreibt in einer aktuellen Untersuchung zu agentenbasierter Kundenerfahrung ein Playbook für Unternehmen, die aus AI tatsächlich Wirkung ziehen. Einer der sechs Punkte:

O-Ton (aus dem Englischen übersetzt): Kundenkontext muss zu jedem Entscheidungspunkt mitreisen, damit Kunden sich nicht wiederholen müssen und Systeme mit dem vollständigen Bild statt mit Teilausschnitten arbeiten.

— McKinsey & Company, "Rewiring Customer Experience for the Agentic Era", Juli 2026

Genau an dieser Stelle scheitern sowohl der Chatbot-Übergang als auch die CRM-Strecke. Die Technologie funktioniert einwandfrei. Verantwortlich gemacht wurde nur niemand dafür, dass der Kontext tatsächlich mitreist.

Das ist strukturell erklärbar, nicht zufällig. Wenn eine IT-Funktion eine AI-Anwendung federführend verantwortet, wird sie zwangsläufig nach den Maßstäben bewertet, die ihr vertraut sind: Lieferzeit, Stabilität, Integration, Kosten. Ob der Kunde über eine Systemgrenze hinweg als dieselbe Person wiedererkannt wird, taucht in diesen Maßstäben nicht auf. Das ist keine Kritik an der IT: Sie liefert genau das, wofür sie beauftragt wurde. Die Lücke entsteht, weil niemand außerhalb der IT den Auftrag präzisiert hat, dass Kundenkontext eine eigenständige, zu schützende Größe ist.

Ein Beispiel aus eigener Erfahrung

Vor einigen Jahren habe ich über einen Arbeitgeber eine betriebliche Altersvorsorge bei einer der größten Versicherungen Deutschlands abgeschlossen, einem Unternehmen mit weltweit rund 97 Millionen Kundinnen und Kunden. Seit ich selbstständig bin, seit etwa eineinhalb Jahren, zahle ich nicht mehr ein. Aufgefallen ist das bislang niemandem.

Kürzlich erhielt ich ein reguläres Schreiben zum Vertragsstand: die voraussichtliche Rente, falls ich nicht weiter einzahle. Ein automatisierter Lifecycle-Trigger, technisch einwandfrei ausgelöst, pünktlich verschickt.

Was in diesem Schreiben fehlte, war der eigentlich interessante Moment: Eine Person hat ihren Erwerbsstatus grundlegend verändert. Für mich als Kundin wäre das ein Beratungsanlass. Für den Versicherer ein mögliches Zusatzgeschäft. Beides bleibt bislang ungenutzt. Rechnet man diesen einen Fall auf eine Kundenbasis dieser Größenordnung hoch, entsteht eine erhebliche Reserve an Potenzial, die schlicht niemand systematisch sucht.

Wenn Silos mehr sind als ein Datenproblem

Der naheliegende Verdacht: Silos. Datentöpfe, die technisch nicht miteinander verbunden sind. Diese Erklärung greift vermutlich zu kurz. Wo Kundenbeziehungen an Provisionsmodelle gekoppelt sind, wird die Frage, wer eine Veränderung beim Kunden erkennen und darauf reagieren darf, schnell auch zu einer Frage von Zuständigkeit und Vergütung.

Eine Silostruktur kann rein technisch bedingt sein und mit der nächsten Systemintegration verschwinden. Sie kann aber auch deshalb bestehen bleiben, weil sie gewachsene Zuständigkeiten und Anreize stabilisiert. Dann löst sie sich durch bessere Technologie allein nicht auf. Beide Fälle sehen von außen zunächst gleich aus. Sie brauchen aber unterschiedliche Lösungen: der eine eine Systementscheidung, der andere eine Führungsentscheidung.

Wer die Lücke schließen müsste

Die Konsequenz daraus ist nicht, AI-Projekte aus der IT herauszulösen und irgendwo neu aufzuhängen. Die Konsequenz ist, ihnen eine Instanz zur Seite zu stellen, die den Kundenweg über Abteilungsgrenzen hinweg versteht und die Befugnis hat, ihn zu gestalten. Diese Instanz muss entscheiden können, welcher Kontext an welcher Schnittstelle verfügbar sein muss. Sie muss außerdem die Zuständigkeit haben, das notfalls gegen einzelne Abteilungsinteressen durchzusetzen.

O-Ton (aus dem Englischen übersetzt): Das Business kennt das Geschäft am besten. Im Kern geht es dabei nicht um eine Technologie-Transformation, sondern um bessere Customer Experience, höhere Produktivität und bessere Umsetzung. Das Business muss die angestrebten Ergebnisse selbst festlegen und formulieren; erst dann wird es zur gemeinsamen Aufgabe von CIO und IT-Funktion, sie umzusetzen.

— Dr. Puneet Mansukhani, Head of Global Retail Digital Technology and Transformation, KPMG International

Das ist im Kern die Ownership-Frage, die auch in meiner eigenen Arbeit mit Kundenorganisationen regelmäßig auftaucht. Ich fasse sie als CX Decision Architecture: wie Kundensignale systematisch in Entscheidungen und messbare Veränderungen übersetzt werden. Vier strukturelle Voraussetzungen tragen diesen Kreislauf, und sie lassen sich an beiden Fällen von oben durchdeklinieren.

Grafik CX Decision Architecture: sechs Schritte eines Zyklus von Kundensignalen zur Entscheidung (Signale erfassen, Zusammenhänge verstehen, Relevanz bewerten und priorisieren, Entscheidung treffen, Umsetzung steuern, Wirkung messen). Darunter die Wirkungsebene Customer & Business Impact und die vier strukturellen Voraussetzungen KPI Framework, Ownership, Steering Rhythm und Transparenz.

Ein KPI Framework hätte den Vodafone-Fall messbar gemacht: Wie oft wird ein Anliegen nach einem Kanalwechsel neu aufgenommen, statt nahtlos fortgesetzt? Diese Kennzahl existiert in den meisten Organisationen schlicht nicht, weil Chat und Hotline getrennt gesteuert werden. Ownership hätte im Lufthansa-Fall bedeutet: eine Instanz, die sowohl die reguläre Marketing-Automatisierung als auch öffentlich bekannte Betriebsstörungen im Blick hat und die Befugnis besitzt, eine laufende Kampagne im Zweifel zu pausieren. Ein fester Steering Rhythm, ein regelmäßiger Termin, auf dem genau solche Kontext-Brüche systematisch besprochen werden, statt nur zufällig aufzufallen, hätte beide Fälle vermutlich schon vor der Auslieferung gestoppt. Und Transparenz darüber, dass die reguläre Kampagne gerade auf einen aktuellen Streik trifft, hätte diese Information sichtbar gemacht, statt sie irgendwo unverbunden liegen zu lassen.

Keine dieser vier Voraussetzungen ist in erster Linie eine technische Frage. Alle vier laufen ins Leere, wenn niemand die Verantwortung dafür trägt, dass sie tatsächlich angewendet werden. Technologie kann sie unterstützen. Sie kann die Ownership-Frage aber nicht für ein Unternehmen beantworten.

Was das für die Steuerung bedeutet

Für Unternehmen, die gerade in AI investieren, heißt das konkret: Vor der nächsten Tool-Entscheidung sollte feststehen, wer die Ownership für den Kundenkontext über das jeweilige Projekt hinaus trägt, unabhängig von der technischen Umsetzung. Diese Ownership gehört auf eine Ebene, die Abteilungsgrenzen überblicken und Priorität durchsetzen kann, nicht in die Projektleitung eines einzelnen Tools.

Der erste Schritt dahin ist meist eine ehrliche Bestandsaufnahme, noch bevor eine neue Rolle im Organigramm entsteht: An welchen drei bis fünf Stellen der eigenen Customer Journey wechselt der Kunde heute das System, den Kanal oder die Zuständigkeit, und was genau geht an diesen Stellen verloren? Diese Liste lässt sich in den meisten Unternehmen in wenigen Workshop-Stunden erstellen, sie wird nur selten erstellt, weil jede einzelne Systemgrenze für sich genommen gut funktioniert und deshalb niemandem auffällt.

Das bedeutet auch, bestehende Anreizstrukturen ehrlich zu prüfen. Wenn eine Silostruktur deshalb fortbesteht, weil sie eine bestehende Vergütungslogik schützt, wird sie sich nicht durch bessere Technologie auflösen. Sie braucht eine bewusste Entscheidung auf Managementebene: wer für den gesamten Kundenweg verantwortlich ist, und wie diese Verantwortung honoriert wird, ohne bestehende Anreize einfach zu untergraben.

Die eigentliche Erkenntnis

Der Chatbot, der Kontext bei der Weiterleitung verliert, und die CRM-Strecke, die an geänderten Lebensumständen vorbeiläuft, sind kein Zeichen dafür, dass die eingesetzte Technologie schlecht wäre. Sie zeigen, dass niemand mit ausreichend Überblick und Durchsetzungskraft dafür verantwortlich gemacht wurde, den Kunden über Systemgrenzen hinweg als eine Person zu behandeln.

Der Preis dafür ist selten ein sichtbarer Beschwerdefall. Er ist unsichtbar: ein Geschäft, das nie entsteht, weil niemand den richtigen Moment erkannt hat.

NEWSLETTER AUF LINKEDIN

The Future is Customer Centric

Neue INSIGHTS erscheinen einmal im Monat auf LinkedIn.

Auf LinkedIn abonnieren