Transformation scheitert an der Tür der Kundschaft: wie Sie Veränderung gestalten, die Menschen spüren

Transformation gelingt, wenn sich an einem gewöhnlichen Arbeitstag zwei Dinge ändern: wie die Menschen an der Front ihre Arbeit machen und was die Kundschaft in dem Moment erlebt, in dem sie mit Ihnen zu tun hat. Die meisten Programme ändern Struktur, Systeme und Foliensatz und hören vor diesen beiden Orten auf. Die Abhilfe: die Veränderung vom Moment der Kundschaft aus rückwärts gestalten, das System kartieren, das diesen Moment hervorbringt, und die Teams, die die Arbeit machen, Roadmap und Kennzahlen selbst verantworten lassen.

Dies ist der Grundlagenartikel unserer Reihe zur Transformation. Er kartiert das ganze Thema und verweist zu jedem Teil auf die vertiefenden Beiträge.

Warum Transformation stehen bleibt, bevor sie irgendjemanden erreicht

Stellen Sie sich ein typisches Programm vor. Ein neues Operating Model wird verabschiedet. Abteilungen werden umbenannt. Eine Plattform wird gekauft und konfiguriert. Die Dashboards stehen auf Grün. Achtzehn Monate später ruft ein Kunde mit demselben Problem an wie vorher, wird zwischen denselben drei Teams hin- und hergereicht und wartet genauso viele Tage. Die Mitarbeiterin, die den Anruf annimmt, nutzt immer noch einen Workaround, weil das neue System die Fälle nicht abbildet, die sie jede Woche sieht.

Nichts in dieser Geschichte ist ein Mangel an Einsatz. Es ist ein Fehler darin, wohin der Einsatz gezielt hat. Programme werden meist von oben nach unten gestaltet: Strategie, Struktur, Technologie, Prozess, Menschen. Die Kundschaft taucht am Ende auf, als Zufriedenheitsziel. Bis die Veränderung die Front erreicht, ist sie so oft übersetzt worden, dass niemand mehr sagen kann, was sich am Dienstagmorgen anders anfühlen soll.

Drei Muster tauchen immer wieder auf:

• Die Veränderung ist nach Abteilungen organisiert, aber die Kundschaft bewegt sich quer durch die Abteilungen. Jede Einheit verbessert ihren eigenen Teil. Die Übergaben dazwischen, wo der meiste Schmerz sitzt, gehören niemandem.
• Gemessen wird Aktivität statt Ergebnis. Gezählt werden durchgeführte Schulungen, gestartete Systeme und veröffentlichte Richtlinien. Ob auch nur eine Kundin weniger wartet, nicht.
• Die Menschen, die die Arbeit machen, werden informiert, nicht beteiligt. Sie bekommen den neuen Prozess in einer Einweisung. Sie wissen genau, warum er in den schwierigen Fällen nicht funktionieren wird – und niemand hat sie gefragt.

Das zweite und dritte Muster betrachten wir ausführlich in Warum Transformationsprogramme Berichte produzieren und niemand anders arbeitet.

Die vier Ebenen einer Transformation, die Menschen spüren

Es hilft, Transformation als vier Ebenen zu denken, von außen nach innen. Veränderung muss auf allen vier gestaltet werden, und zwar in dieser Reihenfolge der Aufmerksamkeit.

1. Was die Kundschaft spürt. Die Momente, in denen Kundschaft, Bürgerinnen und Bürger oder Mitarbeitende auf Ihren Service treffen: das Formular, der Anruf, der Schalter, die Nachricht, das Warten. Das ist die einzige Ebene, die irgendjemand außerhalb der Organisation erlebt.
2. Wie Menschen arbeiten. Die Frontstage- und Backstage-Handlungen, die jeden Moment hervorbringen: wer was tut, mit welchen Informationen, in welcher Reihenfolge und mit wie viel Ermessensspielraum.
3. Das System darunter. Richtlinien, Freigaberegeln, IT-Systeme, Daten, Anreize, Budgets und Berichtswege. Diese Ebene entscheidet, was Menschen tun dürfen und können.
4. Wie die Veränderung gesteuert wird. Roadmap, Verantwortung, Governance und Kennzahlen, die das Programm über Monate und Jahre lenken.

Die meisten Programme beginnen auf Ebene vier und verbrauchen ihre Energie auf Ebene drei. Die Kundenebene wird als Ergebnis behandelt, das schon folgen wird. Das tut es selten, weil niemand die Verbindung zwischen einer neuen Richtlinie und einem anderen Moment am Schalter gestaltet hat.

Customer-Experience-Arbeit beginnt am anderen Ende. Wenn Ihre Organisation diese Gewohnheit noch aufbaut, lesen Sie Kundenzentrierung ist eine Praxis, kein Slogan: Wo man anfängt parallel zu diesem Beitrag. Transformation ist der Ort, an dem diese Praxis über die ganze Organisation skalieren muss.

Veränderung gestalten, die Menschen spüren: sieben Schritte

Diese Schritte funktionieren für organisatorische wie digitale Transformation. Sie ersetzen kein Programmmanagement. Sie sind das, was Sie hineinlegen, damit es ankommt.

1. Journeys wählen, nicht Abteilungen

Wählen Sie drei bis fünf Customer Journeys, die für den Zweck der Organisation am meisten zählen und mehrere Einheiten durchqueren: „eine Genehmigung bekommen“, „einen Schaden melden“, „als neue Mitarbeiterin anfangen“, „einen Zahlungsplan ändern“. Organisieren Sie die erste Welle der Transformation um diese Journeys. Jede Journey bekommt ein kleines funktionsübergreifendes Team mit einer benannten verantwortlichen Person, die die Befugnis hat, über Abteilungsgrenzen hinweg etwas zu verändern.

Wählen Sie Journeys, zu denen Sie bereits wiederholt Beschwerden hören, bei denen die Nachfrage hoch ist oder bei denen ein strategisches Ziel auf dem Spiel steht. Beginnen Sie nicht mit der politisch sichersten Journey; sie lehrt die Organisation, dass Transformation Kosmetik ist.

2. Hingehen und ansehen, bevor Sie irgendetwas gestalten

Vor jedem Workshop erlebt das Journey-Team den Service so, wie die Kundschaft ihn erlebt, und schaut zu, wie er erbracht wird. Eine Service Safari schickt Teammitglieder selbst durch die Journey. Kontextbeobachtung heißt, sich zu Mitarbeitenden an der Front zu setzen, während sie arbeiten, und jeden Workaround, jede Tabelle und jeden Anruf zu notieren, die im offiziellen Prozess nicht vorkommen.

Dieser Schritt verändert, was das Programm glaubt. Führungskräfte stellen regelmäßig fest, dass der Prozess, den sie freigegeben haben, nicht der Prozess ist, der läuft.

3. Das Erlebnis und die Arbeit dahinter kartieren

Zeichnen Sie die aktuelle Journey mit einer Experience Map: Phasen, Handlungen, Gedanken, Gefühle und Pain Points aus Sicht der Kundschaft. Zeichnen Sie dann darunter den Service Blueprint, das Werkzeug, das G. Lynn Shostack in den 1980er-Jahren einführte. Er zeigt Frontstage-Handlungen, Backstage-Handlungen und unterstützende Prozesse, getrennt durch die Sichtbarkeitslinie.

Im Blueprint wird Transformation konkret. Sie können auf die genaue Übergabe zeigen, an der ein Fall vier Tage wartet, oder auf den Schritt, an dem Mitarbeitende Daten neu eingeben, weil zwei Systeme nicht miteinander sprechen. Wenn Sie unsicher sind, welche der beiden Maps Sie zuerst brauchen, lesen Sie Customer Journey Map oder Service Blueprint.

4. Das System kartieren, bevor Sie es verändern

Der Blueprint zeigt die Arbeit. Er zeigt nicht, warum die Arbeit so ist, wie sie ist. Dafür brauchen Sie eine System Map der Regeln, Anreize, Datenflüsse und Entscheidungen, die das heutige Muster an seinem Platz halten, und eine Stakeholder-Map darüber, wer gewinnt, wer verliert und wer zustimmen muss.

Ergänzen Sie eine Kraftfeldanalyse, Kurt Lewins Werkzeug, um die Kräfte aufzulisten, die für und gegen eine Veränderung wirken. Oft zeigt sich, dass die stärkste hemmende Kraft eine einzelne Freigaberegel oder eine Berichtskennzahl ist – kein Widerstand von Menschen. Die vollständige Anleitung finden Sie in Das System kartieren, bevor Sie es verändern.

5. Die neuen Momente und die neue Arbeit gemeinsam gestalten

Jetzt gestalten Sie die künftige Journey: welche Momente sich ändern, was die Kundschaft in jedem spüren soll und was jede Person hinter der Sichtbarkeitslinie anders machen wird. Gestalten Sie Ebene eins und Ebene zwei in derselben Sitzung, mit Mitarbeitenden von der Front im Raum. Ein neues Kundenversprechen ohne neue Arbeitsweise dahinter ist ein Slogan.

Testen Sie die neuen Momente, bevor Sie irgendetwas bauen. Ein Rollenspiel des neuen Gesprächs am Schalter, mit echten Mitarbeitenden und einigen echten Kundinnen und Kunden, legt an einem Nachmittag Lücken offen, die ein Systemaufbau erst nach sechs Monaten zeigen würde. Die ganze Palette günstiger Tests finden Sie in Ein Erlebnis testen, bevor Sie es bauen.

6. Eine Roadmap bauen, die die Teams verantworten

Übersetzen Sie die gestalteten Änderungen in eine Roadmap, organisiert nach Journey und Ergebnis, nicht nach System-Release. Jeder Eintrag sagt, welchen Moment er verbessert, welches Team ihn verantwortet und was abgeschaltet wird, wenn er umgesetzt ist. Nutzen Sie eine RACI-Matrix für abteilungsübergreifende Entscheidungen, damit Übergaben eine verantwortliche Person haben.

Verantwortung ist der Kern. Eine Roadmap, die ein Programmbüro schreibt und den Teams übergibt, ist ein Zeitplan. Eine Roadmap, die die Journey-Teams selbst geschrieben haben und jedes Quartal überarbeiten, ist eine Verpflichtung. Wie Sie das aufsetzen, lesen Sie in Eine Transformations-Roadmap, die die Teams verantworten.

7. Messen, was Menschen spüren, und abschaffen, was sie nicht mehr brauchen

Bauen Sie einen KPI-Baum, der das strategische Ziel mit Ergebnissen der Journey verbindet (Zeit bis zur Lösung, wiederholte Kontakte, beim ersten Mal abgeschlossene Fälle, Aufwand) und weiter nach unten mit den operativen Kennzahlen, die Teams bewegen können. Berichten Sie diese, nicht die Zahl der Workshops oder Go-Lives. Die Methode finden Sie in Transformation an Ergebnissen messen, nicht an Aktivität.

Führen Sie dann eine Stop-Doing-Liste. Jeder neue Prozess sollte ein altes Formular, einen alten Bericht, eine alte Freigabe oder ein altes System abschalten. Transformation, die nur hinzufügt, führt dazu, dass in Organisationen der neue und der alte Weg nebeneinander laufen – und die Mitarbeitenden beides machen.

Wo digitale Transformation hingehört

Digitale Transformation ist die häufigste Spielart dieses Problems und die teuerste, wenn sie schiefgeht. Eine neue Plattform bildet den alten Prozess auf einem Bildschirm nach oder zwingt der Front einen Prozess auf, mit dem sie nicht arbeiten kann – und die Kundschaft sieht eine schönere Oberfläche über derselben Verzögerung.

Behandeln Sie jede digitale Initiative als Neugestaltung eines Service, bei der zufällig Technologie im Spiel ist. Beginnen Sie bei Journey und Blueprint, entscheiden Sie, welche Momente und Übergaben sich ändern sollen, und spezifizieren Sie erst dann das System. Die vollständige Argumentation steht in Digitale Transformation ist ein Service-Design-Problem.

Wenn Sie wissen müssen, wie bereit die Organisation für diese Art von Arbeit ist, gibt Ihnen eine Bewertung der Innovationsreife einen Ausgangspunkt. Wenn die Transformationsagenda selbst unklar ist, beginnen Sie mit Eine Innovationsstrategie in wenigen Workshops entwickeln.

Beispiel zur Veranschaulichung: das neue Abrechnungssystem eines Versorgers

Zur Veranschaulichung. Ein regionaler Wasserversorger in einem mittelgroßen europäischen Land steckt seit zwei Jahren in einem Transformationsprogramm. Herzstück ist eine neue Abrechnungs- und Kundenplattform. Sie ist planmäßig live gegangen. Die Beschwerden über Rechnungen sind nicht gesunken, und die Bearbeitungszeiten im Callcenter sind gestiegen.

Die Programmdirektorin bittet für eine Journey um einen anderen Ansatz: „Meine Rechnung sieht falsch aus“. Ein Team aus sechs Personen wird gebildet: zwei Callcenter-Beraterinnen, ein Abrechnungsanalyst, ein Techniker aus dem Außendienst, eine IT-Product-Ownerin und ein Kundenservice-Manager als Verantwortlicher für die Journey.

Sie verbringen eine Woche mit einer Service Safari und an der Seite der Beraterinnen. Sie stellen fest, dass die Beraterinnen in der neuen Plattform den Verlauf der Zählerstände nicht sehen können und deshalb für jede Anfrage ein Ticket an die Abrechnung stellen. Die Abrechnung bearbeitet die Tickets gesammelt. Der Kundschaft wird ein Rückruf innerhalb von fünf Tagen versprochen, oft kommt stattdessen ein Brief.

Der Blueprint zeigt drei Übergaben, an denen Fälle warten. Die System Map zeigt, warum: Eine Datenschutzregel war so ausgelegt worden, dass Zählerdaten dem Abrechnungsteam vorbehalten blieben, und das Ziel der Abrechnung zählt geschlossene Tickets, nicht beim ersten Kontakt gelöste Anfragen.

Das Team gestaltet einen neuen Moment: Die Beraterin erklärt die Rechnung beim ersten Anruf. Dahinter bekommen die Beraterinnen Lesezugriff auf den Zählerverlauf, abgestimmt mit dem Datenschutzbeauftragten, und einen kurzen Gesprächsleitfaden für die drei häufigsten Ursachen. Sie spielen das mit zehn freiwilligen Kundinnen und Kunden durch, bevor irgendeine Konfiguration geändert wird. Das Ziel der Abrechnung wechselt zu beim ersten Mal gelösten Anfragen. Der Rückrufbrief kommt auf die Stop-Doing-Liste.

Der Roadmap-Eintrag gehört dem Callcenter-Team, nicht der IT. Die Kennzahl, die an die Geschäftsleitung berichtet wird, ist der Anteil der Rechnungsanfragen, die beim ersten Kontakt gelöst werden, monatlich erhoben.

Was Sie tun und was Sie lassen sollten

Tun

• Mit wenigen abteilungsübergreifenden Journeys beginnen und jeder eine einzige verantwortliche Person mit echter Befugnis geben.
• Mitarbeitende von der Front in jede Gestaltungssitzung holen, nicht nur in die Einweisung danach.
• Die Arbeit ansehen, bevor Sie sie neu gestalten. Der offizielle und der tatsächliche Prozess sind selten derselbe.
• Regeln, Anreize und Datenflüsse kartieren; dort ist die Veränderung meist blockiert.
• Neue Momente mit Rollenspiel oder einem manuellen Pilot testen, bevor Systeme konfiguriert werden.
• Für jeden Roadmap-Eintrag ein Pre-Mortem durchführen: sich vorstellen, er sei in einem Jahr gescheitert, und auflisten, warum.
• Jedes Mal, wenn Sie etwas einführen, etwas anderes abschaffen.
• Mit jedem Journey-Team jedes Quartal eine Retrospektive abhalten und die Roadmap daraufhin anpassen.

Lassen

• Erfolg nicht an Go-Lives, Schulungsstunden oder der Zahl dokumentierter Prozesse messen.
• Nicht zuerst das Organigramm neu gestalten und hoffen, dass das Kundenerlebnis folgt.
• Das Programmbüro die Roadmap nicht allein schreiben lassen.
• Keinen Prozess digitalisieren, den Sie sich nicht angesehen haben; Sie automatisieren sonst das Warten.
• Customer-Experience-Arbeit nicht als separaten Strang neben der Transformation laufen lassen. Sie ist der Test der Transformation dafür, ob sich irgendetwas verändert hat.
• Kein neues Kundenversprechen ankündigen, bevor sich die Arbeit dahinter verändert hat.

Häufige Fragen

Warum scheitern die meisten Transformationen? Selten aus Mangel an Einsatz oder Geld. Sie scheitern, weil die Veränderung auf der Ebene von Struktur und Systemen gestaltet und gemessen wird und nie bis hinunter zu den konkreten Momenten, die Kundschaft und Mitarbeitende erleben. Die Übergaben zwischen Abteilungen, wo die meisten Verzögerungen und der meiste Frust sitzen, gehören niemandem, also bleiben sie, wie sie sind.

Was ist der Unterschied zwischen Transformation und Change Management? Change Management dreht sich meist darum, Menschen zu helfen, eine bereits beschlossene Veränderung anzunehmen. Gut gemachte Transformation bezieht diese Menschen schon in die Entscheidung ein, was sich überhaupt ändert. Die Methoden hier machen das möglich: Mitarbeitende helfen beim Beobachten, Kartieren, Gestalten und Testen der neuen Arbeitsweise, sodass die Annahme kein separates Problem ist, das später gelöst werden muss.

Woran erkennt man, dass eine Transformation wirkt? Schauen Sie auf die Kundschaft und die Front, nicht auf das Programm. Sind Journeys schneller oder einfacher, gemessen an Kennzahlen, die die Kundschaft wiedererkennen würde? Sinken wiederholte Kontakte? Haben Mitarbeitende aufgehört, Workarounds zu nutzen? Wurde irgendetwas Altes abgeschaltet? Wenn die Antwort auf alle vier Nein lautet, ist das Programm beschäftigt, aber es wirkt nicht.

Wie es weitergeht

Beginnen Sie mit einer Journey. Nutzen Sie eine Service Safari, um sie zu sehen, wie die Kundschaft sie sieht, einen Service Blueprint, um die Arbeit dahinter zu sehen, eine System Map, um zu sehen, was sie an ihrem Platz hält, und einen KPI-Baum, um festzulegen, woran Sie erkennen, dass sie sich verändert hat. Alle 75 Methodenleitfäden finden Sie in der Leitfaden-Bibliothek.