Guten Morgen Sven,
Danke für deinen Hinweis bzw. deine Idee. Ja, mit ProCheck könnten wir einiges machen. Ich spreche mal mit den Kollegen.
Allerdings bemerke ich jetzt, dass "Kundenprozesse" zu kurz greift. ProCheck beschreibt den Arbeitsprozess. Die Customer Journey nimmt den Arbeitsprozess und links, in der Mitte und rechts davon auch noch ganze Abschnitte, bspw. Beschaffung, Ersteinrichtung, Außendienst-Kontakt, Service-Kontakt, Suche in der Info-DB, usw.
Es geht also nicht nur um den Arbeitsprozess, sondern um das ganzheitliche Kundenerlebnis im Produktlebenszyklus.
Die Prozesse aus ProCheck könnten eine gute Anfangsbasis sein, greifen aber insgesamt zu kurz. Außerdem betrachten sie ja eher die "technischen" Prozesse und Workarounds, und viel weniger völlig menschliche Bedürfnisse (Angst, Verärgerung, Frustration, Langeweile, Stress, usw.).
***
Ich mache mal ein Beispiel aus einer anderen Branche:
Ein Hausbesitzer hat einen Wasserschaden am Haus. Sein Versicherer hat eine neue Servicestrategie entwickelt: "Scheck & Weg." Wer im Service anruft erhält folgenden Service: Der Mitarbeiter entschuldigt sich, die Schadenssumme wird innerhalb von 2-3 Tagen ausbezahlt und um alles andere kann sich der Hausbesitzer selbst kümmern (keinerlei Vorgaben).
Die Umfrageergebnisse des Versicherers zeigen: Die Kunden sind hochgradig zufrieden. Zitate wie "Mir wurde sehr schnell geholfen!" fallen.
Betrachten wir diese Reise (Customer Journey) mal aus der Sicht des Hausbesitzers:
Schmerz: Verdammt! Wasserschaden!
Unsicherheit: Wird die Versicherung bezahlen?
Verärgerung: Beseitigung der gröbsten Schäden
Frust: 27 Minuten in der Warteschleife des Versicherers
Freude: Juhu, die Versicherung hat sofort und sehr kulant überwiesen!
Verunsicherung: Was wenn ich jetzt einen Handwerker rufe und der kostet mich doch mehr?
Frust: Lange Suche nach einem Handwerker der zeitnah Kapazitäten hat
Frust: Langes Warten auf den Handwerker
Frust: Der Handwerker sagt, dass die Baustelle vier Wochen dauern wird!
...
Was die Geschichte veranschaulichen soll: Nur weil Kunden sagen, dass sie zufrieden sind, bedeutet es nicht, dass man nichts lernen kann. Und es reicht eben auch nicht, wenn man sich nur den "idealtypischen" (=ProCheck) Prozess anschaut, sondern Impulse bekommt, in Richtung:
Was passiert wirklich?
Wie geht es Ihnen dabei?
Wo haben Sie Ängste / Sorgen / Nöte / Frust / Wut / Freude / Erleichterung / ... ?
Welche Hilfsmittel setzen Sie dabei ein? (andere Checklisten, Internetrecherche, Anruf im Service, Außendienst-Kontakt, ...)
Wie gut wird Ihnen dadurch geholfen? Was genau hat Ihnen im konkreten Fall geholfen? usw.
Was ich auch sagen will:
Aus Sicht des Versicherers ist die Journey kurz: Anruf Kunde - Aufnahme des Falls - Bearbeitung und Überweisung - Nachkontakt und Abfrage der Zufriedenheit
Aus Sicht des Hausbesitzers ist die Journey viel länger.
***
Es passieren so viele Dinge, die der Versicherer aus den Augen verliert, wenn er nicht die Kundenbrille aufsetzt. Und wenn er sich dabei nur auf den idealtypischen Prozess verlässt.
Achtung: Die Flughöhe hier ist natürlich auch sehr hoch. Der Anspruch ist gar nicht, dass dann jeder kleinteilige Prozessbruch erkannt wird. Sondern, dass man die größten Baustellen im Gesamterlebnis aufdeckt und ins Bewusstsein bringt. Ich glaube, dass das was Du beschreibst, bei uns User Journey heißt. Also wie sich ein Anwender konkret im Produkt bzw. durch mehrere Produkte arbeitet, um seine Ziele möglichst effizient und zufriedenstellend zu erreichen.
Das mag für Außenstehende jetzt ähnlich klingen, aber die Zielsetzung für die Organisation ist eine völlig andere. Nehmen wir wieder das Gesetz von Conway: Wenn Software so aussieht und sich so anfühlt, wie die Organisation intern aufgebaut ist ("Kommunikationsstrukturen"), dann bedeutet das auch, dass das "Entwicklungsteam" eben kein reines Entwicklungsteam mehr sein kann, sondern das gesamte Kundenerlebnis im Blick haben muss (Anschaffung, Service, Außendienst, Community, usw.), wenn wir diese Brüche aus Kundensicht an unseren internen Grenzen aufbrechen wollen.
Früher (bitte nicht ganz ernst nehmen ich überspitze sehr bewusst!): Ein Service-Mitarbeiter musste einem Entwickler erklären, was unsere Kunden hier in der Community von sich geben. Der Service-Mitarbeiter konnte sein Wissen in erster Linie in Hilfe-Dokumenten einbringen. Die Verantwortlichkeiten waren klar getrennt.
Heute: Ein Wertschöpfungsteam verantwortet den gesamten Produktlebenszyklus. Wenn es z.B. im Service brennt, weil das Team etwas Unschönes ausgeliefert hat, dann brennt es auch beim Team und nicht nur "woanders." Dadurch kommt die Lösung im Produkt statt nur in Hilfedokumenten deutlich näher in den Lösungsraum. Natürlich wird weiterhin der Service von spezialisierten Mitarbeitern erledigt. Aber diese frühere Distanz wird durch den Blick auf bzw. die Verantwortung für die Customer Journey (hoffentlich) abgebaut. Wenn jemand bei DATEV von End-to-End-Verantwortung spricht, dann ist in der Regel das gemeint.
Und noch ein abschließender Gedanke zum Schluß, weil ich das Thema gerne auch beenden würde: Natürlich kann weder ich, noch sonst jemand aus der Organisation - und auch nicht Du - sagen, welche Auswirkungen diese Änderungen tatsächlich haben werden. Und natürlich klingt das für den einen oder anderen nach "DATEV beschäftigt sich nur mit sich selbst." Aber das ist aus meiner Sicht völliger Quatsch. Wir sind eine Organisation mit gut 8.000 Menschen. Die Art wie wir zusammenarbeiten ist maßgeblich entscheidend für die Frage, wie unsere Produkte aussehen, sich anfühlen und Wert für unsere Kunden ausliefern. Und natürlich ist das auch ein langwieriger Prozess, der sich nicht sofort auf die eigentlich hier diskutierte Frage zu DUo durchschlagen wird.
Aber wir sind auf einem Weg. Und ich glaube, dass es der richtige ist: Ausrichtung der Organisation an Customer Journeys ("Kundenerlebnis-Reisen") statt an Produkten.
Liebe Grüße bzw. hoffentlich "Over and Out" 😉
Alper
Mit freundlichem Gruß
Alper
UX Research (Kundeneinbezug) | DATEV eG
#GernePerDu
