Digitale Transformation ist ein Service-Design-Problem, kein Technikproblem

Digitale Transformation geht schief, wenn sie als Technologieprogramm läuft: eine Plattform auswählen, die Formulare online stellen, die gestarteten Systeme zählen. Die Kundschaft trifft weiterhin auf dieselben Übergaben, dieselben Dokumente und dasselbe Warten – nur jetzt auf einem Bildschirm. Behandeln Sie sie stattdessen als Service-Design-Problem. Gestalten Sie neu, was die Person erledigen will, von Anfang bis Ende, Frontstage und Backstage, und entscheiden Sie erst dann, was die Technologie leisten muss.

Die Überzeugung, fair formuliert

Die Überzeugung lautet: Unsere Services sind langsam, weil unsere Systeme alt sind. Ersetzen wir die Systeme und bringen die Services online, verbessert sich das Erlebnis von selbst.

Das ist keine törichte Überzeugung. Alte Systeme bremsen tatsächlich. Papier geht tatsächlich verloren. Viele Services sind online wirklich besser, und manche lassen sich nur so skalieren. Technologieausgaben sind außerdem leicht zu planen, zu genehmigen und zu berichten. Es gibt Anbieter, Meilensteine und einen Starttermin. Eine Geschäftsleitung kann zusehen, wie es passiert.

Der Reflex, mit der Technologie zu beginnen, ist also verständlich. Das Problem ist, was er auslässt.

Warum das in der Praxis scheitert

Digitalisiert wird der Prozess, nicht das Ergebnis

Der erste Schritt der meisten Programme: das bestehende Formular nehmen und online stellen. Jedes Feld, jeder Anhang, jeder Unterschriftsschritt übersteht den Umzug. Der Kunde, der früher am Schalter anstand, lädt jetzt dieselben sieben Dokumente in ein Portal hoch und wartet dann, bis dieselben drei Abteilungen nacheinander zustimmen. Der Service ist digital. Besser ist er nicht.

Services queren Abteilungen, Programme nicht

Die Kundschaft erlebt einen Service: „meine Lizenz verlängern“, „ein Konto eröffnen“, „mein Kind an der Schule anmelden“. Innerhalb der Organisation läuft dieser Service durch mehrere Abteilungen, jede mit eigenem System, eigenem Budget und eigenen Zielen. Technologieprogramme werden meist Abteilung für Abteilung zugeschnitten. So wird jeder Teil modernisiert, und die Nahtstellen dazwischen, wo die meiste Verzögerung sitzt, bleiben unberührt.

Melvin Conway beobachtete 1968, dass Organisationen dazu neigen, Entwürfe hervorzubringen, die ihre eigenen Kommunikationsstrukturen abbilden. Digitale Services bestätigen ihn täglich. Wenn drei Abteilungen nicht miteinander reden, hat auch das Portal drei Bereiche, die nicht miteinander reden.

Niemand gestaltet den Backstage

Der Bildschirm, den die Kundschaft sieht, ist die Frontstage. Dahinter stehen die Menschen, Regeln, Freigaben und Systeme, die das Ergebnis tatsächlich liefern. G. Lynn Shostack beschrieb den Service Blueprint 1982 erstmals und machte ihn 1984 mit einem Artikel in der Harvard Business Review einem breiten Wirtschaftspublikum bekannt – genau, um diesen verborgenen Teil sichtbar zu machen. Die meisten Transformationsprogramme gestalten die Frontstage im Detail und lassen den Backstage, wie er war. Das Ergebnis ist eine polierte App auf einem Prozess, der immer noch eine Unterschrift der Vorgesetzten auf Papier braucht.

Erfolg wird als Lieferung gemessen, nicht als Veränderung

„Gestartete Systeme“, „Services online“ und „Digitalisierungsgrad“ sind Aktivitätskennzahlen. Sie können alle steigen, während die Zeit bis zum Ergebnis, die Zahl wiederholter Kontakte und die Abbruchquote gleich bleiben. Wenn die Scorecard Starts belohnt, starten Teams. (Wie man das Richtige misst, behandelt Transformation an Ergebnissen messen, nicht an Aktivität.)

Was stattdessen funktioniert

Machen Sie den Service, nicht das System, zur Einheit der Transformation. In der Praxis heißt das fünf Gewohnheiten.

1. Das Ergebnis benennen, das die Person will. Nicht „Antrag einreichen“, sondern „meinen Laden eröffnen dürfen“. Schreiben Sie es in den Worten der Kundschaft. Das legt die Grenze der Arbeit fest, und sie ist fast immer weiter als eine Abteilung.
2. Den ganzen Service kartieren, wie er heute läuft. Nutzen Sie eine Experience Map, um ihn aus Sicht der Kundschaft zu sehen, und dann einen Service Blueprint, um den Backstage zu sehen: wer den Fall anfasst, was geprüft wird, worauf gewartet wird. Durchlaufen Sie den Service selbst; kartieren Sie ihn nicht aus dem Verfahrenshandbuch.
3. Jeden Schritt hinterfragen, bevor Sie ihn digitalisieren. Fragen Sie bei jedem Dokument, jeder Freigabe und jedem Feld: Warum ist das hier, wer nutzt es, und was passiert, wenn wir es streichen? Änderungen an Regeln und Abläufen sind meist die günstigsten und größten Verbesserungen, und sie kosten keine Zeile Code.
4. Den neuen Service testen, bevor Sie das System bauen. Führen Sie die neu gestaltete Journey einige Wochen lang mit einer kleinen Gruppe von Hand durch – ein Concierge-Test – oder setzen Sie eine einfache Oberfläche auf Menschen, die die Arbeit manuell erledigen – ein Wizard-of-Oz-Test. Sie lernen, was die Technologie tatsächlich leisten muss, und das ist meist weniger, als das Lastenheft sagte.
5. Einer Person den ganzen Service geben. Benennen Sie eine verantwortliche Person für den Service mit Befugnis über alle beteiligten Abteilungen hinweg und messen Sie den Service an dem, was die Kundschaft bekommt: Zeit bis zum Ergebnis, Schritte, wiederholte Kontakte, Abbrüche.

Technologie wird dann zu dem, was sie sein sollte: der Weg, auf dem der neu gestaltete Service im großen Maßstab erbracht wird – nicht die Neugestaltung selbst.

Ein Beispiel

Zur Veranschaulichung. Die Stadtverwaltung einer mittelgroßen europäischen Stadt führte ein dreijähriges Programm durch, um „Gewerbegenehmigungen online zu bringen“. Das neue Portal ging pünktlich live. Anträge dauerten weiterhin ungefähr gleich viele Wochen, und die Anrufe im Kundenservice nahmen zu, weil Antragstellende nicht erkennen konnten, welche von vier Abteilungen gerade ihre Akte hatte.

Ein kleines Team sollte sich das noch einmal ansehen. Es blueprintete eine einzige Journey – eine Café-Betreiberin, die eine Eröffnung beantragt – und fand elf Übergaben zwischen Bauplanung, Lebensmittelüberwachung, Brandschutz und Gewerbeamt, wobei jede auf den Abschluss der vorherigen wartete. Drei der angeforderten Dokumente lagen bereits einer anderen Abteilung vor. Zwei Freigaben liefen nur aus Gewohnheit nacheinander.

Das Team führte für einen Stadtbezirk einen manuellen Pilot durch: eine Sachbearbeiterin, die jeden Antrag von Anfang bis Ende verantwortete, parallele Prüfung durch die Abteilungen und der Verzicht auf doppelte Dokumente. Das Portal blieb, aber seine Aufgabe änderte sich: Es zeigte den Antragstellenden nun eine verantwortliche Person und einen Status. Der Pilot zeigte der Stadt genau, welche Integrationen sich zu bauen lohnten und welche überhaupt nicht nötig waren.

Was Sie tun und was Sie lassen sollten

Tun

• Mit einem Service mit hohem Aufkommen beginnen, nicht mit der ganzen Organisation.
• Die Menschen in den Raum holen, die den Service erbringen, nicht nur die, die ihn managen.
• Den Backstage blueprinten, bevor irgendeine technische Anforderung geschrieben wird.
• Regeln und Verfahren als Gestaltungsmaterial behandeln, nicht als feste Vorgaben.
• Die neue Journey von Hand testen, bevor Sie sich auf den Bau festlegen.

Lassen

• Ein Papierformular Feld für Feld online stellen.
• Die Arbeit nach Abteilung oder System zuschneiden.
• „Digitalisierte Services“ als Erfolg berichten.
• Die Form des Anbieterprodukts bestimmen lassen, wie der Service funktioniert.
• Die Neugestaltung allein der IT oder allein dem Service Design übergeben. Es braucht beide, unter Führung der fachlich verantwortlichen Person.

Häufige Fragen

Ist Service Design einfach Customer Experience unter anderem Namen? Nein. Customer-Experience-Arbeit konzentriert sich oft darauf, was die Kundschaft sieht und fühlt. Service Design umfasst das und den Backstage: die Mitarbeitenden, Regeln, Systeme und Übergaben, die das Erlebnis hervorbringen. Bei einer Transformation muss der größte Teil der Veränderung im Backstage passieren. Wenn Sie zwischen den beiden Maps wählen, lesen Sie Customer Journey Map oder Service Blueprint?

Brauchen wir trotzdem eine Technologie-Roadmap? Ja, aber sie sollte der Neugestaltung des Service folgen, nicht vorangehen. Sobald Sie wissen, wie der Service funktionieren soll, beschreibt die Roadmap, was die Systeme leisten müssen, um ihn zu unterstützen. Viele Organisationen stellen fest, dass die Liste kürzer wird.

Wo fangen wir an, wenn alles repariert werden muss? Wählen Sie den Service mit dem höchsten Aufkommen und den meisten Beschwerden, kartieren Sie ihn von Anfang bis Ende und reparieren Sie zuerst die Nahtstellen zwischen den Abteilungen. Ein richtig gemachter Service lehrt die Organisation mehr als zehn halb gemachte. Bevor Sie irgendetwas neu zeichnen, hilft es, das System zu kartieren, bevor Sie es verändern.

Wie es weitergeht

Dieser Beitrag gehört zum Hauptartikel des Themenbereichs, Transformation scheitert an der Tür der Kundschaft. Für die praktische Arbeit beginnen Sie mit dem Service Blueprint und der Experience Map, nutzen eine System Map, um zu sehen, welche Abteilungen und Regeln den Service prägen, und eine Touchpoint-Matrix, um jeden Kanal zu sehen, den die Kundschaft durchquert.