DMR. Kunden lieben es einfach! We make ICT strategies work. Eine durchdachte Omnikanalarchitektur ist das Fundament für erfolgreiche Customer Journeys

Transkript

1 Detecon Management Report DMR Kunden lieben es einfach! Eine durchdachte Omnikanalarchitektur ist das Fundament für erfolgreiche Customer Journeys We make ICT strategies work

2

3 1. 2. Herausforderung: Der wechselhafte Kunde 2 Anforderungen an eine nahtlose Customer Journey 4 Inhalt 3. Interview mit Carsten Klingels, E.ON: Raus aus der verstaubten Technikecke! 6 4. Empfehlungen und Gestaltungsparameter einer Omnikanalarchitektur Interview mit Karin Hausdorf und Guido Sewitza, RWE IT: Übergreifender Kundenservice auf verschiedensten Kanälen Analyse des Product-fit für einzelne Komponenten der Zielarchitektur Interview mit Ulf Adebahr, redcoon GmbH: Prozess-Exzellenz ist das Erfolgskriterium für Omnikanalarchitekturen 26 Empfehlung für die nächsten Handlungsschritte 30 Statements 32 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

4 1. Herausforderung: Der wechselhafte Kunde Daten Funktion Darstellung 2 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015

5 Technology Quelle: Detecon Products Chanels Seamless Omni-Channel- Experience Customer Service Abbildung 1: Problemstellung einer Omnikanalarchitektur Moderne Kunden sind treulose Gesellen, zumindest was Kanäle angeht. Sie erscheinen im Store und lassen sich ausführlich beraten. Dann schauen sie auf der Website vorbei, stöbern über die App im Kundenforum, informieren sich bei anderen Kunden im Social Web über deren Erfahrungen, rufen noch mal eben die Kundenhotline an um am Ende doch im Store das gewünschte Produkt zu kaufen. Eine Customer Journey über alle Kanäle hinweg ist heute keine Seltenheit. Die nahtlose Bedienung des Kunden über alle Kanäle hinweg stellt jedoch Anforderungen an eine einheitliche Bereitstellung von Produktinformationen, übergreifende Prozesse im Customer Service sowie die zugrunde liegende Technologie. Doch die Treulosigkeit in puncto Kanäle hat auch positive Effekte. Die Erfahrung zeigt, dass Omnikanalkunden im Schnitt einen höheren ARPU (Average Revenue per User) verzeichnen, affiner für höherwertige und komplexere Produkte und deutlich Marken-loyaler sind. Einkanalkunden hingegen sind neben Gelegenheitskäufern eher auf der Suche nach dem Best Price. Für die IT ist ein Omnikanal-Ansatz im Sinne eines ubiquitären Zugriffs auf alle relevanten Kundenservices eine große Herausforderung. Zwei Faktoren erschweren die Umsetzung zusätzlich: Während Use Cases für Customer Touch Points rasch gefunden und Anforderungen an die IT schnell formuliert und wieder geändert sind, steigt der Druck auf die IT. Die Vielfalt und der schnelle Wechsel der Anforderungen lässt sie wie gegen Windmühlen kämpfend hinter den Anforderungen der Zeit her entwickeln. Die User Interfaces von Customer Touch Points müssen aktuell, ansprechend und modern sein, eine spezifische, wiedererkennbare User Experience bieten und den Anwender jederzeit schnell bedienen. Aus Sicht der Governance sind zudem sehr klare Anforderungen an jegliche Interaktion mit Kunden und Partnern sowie die zugrunde liegenden Informationstechnologien formuliert, die ein schnelles Reagieren der IT ausbremsen: Die IT muss fachliche Anforderungen an die kohärente Bereitstellung und Governance der kommunikativen Inhalte, Produktinformationen, Preise und Prozesse erfüllen. Die Transaktionssicherheit ist sicherzustellen. Unterschiedlichste Business- und Legacy-Applikationen sind zu integrieren, Datensicherheit sowie Datenschutz zu gewährleisten. Die IT muss Augenmaß und Nachhaltigkeit im Umgang mit Investitionen beweisen und dies im Angesicht von ständig wechselnden und sich neu entwickelnden fachlichen Anforderungen an User Interfaces, Rich Internet Applications, mobilen Apps sowie dem immensen Schub von Consumer und User Driven Computing innerhalb der Unternehmen. Die Auflösung der Spannung zwischen der extremen Dynamik der Fachanforderungen und der vermeintlichen Trägheit der IT ist die zentrale Herausforderung in der Entwicklung einer Omnikanalarchitektur für Unternehmen. DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

6 Wandhaken Vogelhäuschen nur 10,99 Wandgarderobe 7,99 Wandarmatur Vogelhäuschen nur 16,99 Vogelhäuschen 2,99 Bird s best Loggia nur 16,99 Vogelhäuschen nur 3,99 Bird s Loggia Vogelhäuschen nur 3,99 nur 12,99 Wandhaken 6,99 4 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015

7 2.Anforderungen an eine nahtlose Customer Journey Die Implementierung von integrierten und konsistenten Customer Touch Points über alle digitalen Kanäle hinweg sowie deren Bereitstellung für den stationären Handel, Direktvertrieb, Call Center oder den technischen Service bedarf einiger Anpassungen in der klassischen IT-Architektur auf dem Weg zu einer Architektur, welche Zero- Touch -Kundeninteraktion auf verschiedenen Kanälen ermöglicht. Zero-Touch -Kundeninteraktion muss als durchgehende Customer Journey selbsterklärend, ohne Medienbrüche und ohne Barrieren implementiert sein. Die Touch Points müssen beispielsweise auf identischen Prozessen und Systemen aufsetzen, welche die Mitarbeiter in der Kundeninteraktion verwenden, um kohärent Kundenwünsche zu bedienen. Kunden erwarten eine konsistente Betreuung und Bearbeitung ihrer Anliegen über jeden Touchpoint hinweg und nutzen für eine Transaktion den Kanal, der ihnen zur Erreichung des Ziels am effizientesten erscheint. Eine Detecon-Studie 1 hat gezeigt, dass Kunden von Self- Services eine einfache und übersichtliche Bedienung, klare Erfüllung von Datenschutz- und Sicherheitsvorgaben sowie Schnelligkeit erwarten. Zusätzlich müssen für verschiedene Kundensegmente gleichzeitig mehrere Kanäle verfügbar sein. Eine übergreifende Sicht können Unternehmen nur durch eine einheitliche Informationshaltung und transparente Prozesse im Hintergrund sicherstellen. Die individuelle Nutzung für den Kunden ist einfach und sicher zu gestalten, um das Kundenerlebnis erwartungskonform zum gewählten Touch Point zu kreieren. Anwendungen können Channel-Hopping durch übergreifendes Session-Handling und User-Management kanalübergreifend ermöglichen. Ihre Basisanforderung ist aber, äußerst fehlerresistent und robust zu sein. Treten Unsicherheiten im Bearbeitungsprozess auf, müssen Unternehmen ihren Kunden zu jeder Zeit persönliche Hilfe, zum Beispiel durch Click-to-chat oder Callback-Option, anbieten. Der Agent beziehungsweise Store-Mitarbeiter muss technisch in der Lage sein, auf den gleichen Datensatz und Prozessschritt sowie die gleiche Anwendung wie der Kunde zuzugreifen. Über die individuellen Anwendungen hinaus sollte die Unternehmenskommunikation innerhalb der Sozialen Netzwerke zusätzliche Nachfragen beantworten. Der technisch wenig komplexe Einstieg in Soziale Netzwerke ermächtigt Unternehmen, hohe Volumina von Kundeninteraktionen bereits zu einem frühen Zeitpunkt des Kundenanliegens beantworten zu können. 1 Customer Self-Services, Effizienz und Kundenbindung im Zeitalter der Digitalen Transformation, Studie, Andreas Penkert, Patrick Eberwein, Viktoria Salma, Sascha Krpanic, Februar Spannungsfeld zwischen Business und IT überwinden Customer Touchpoints sind aktuell hauptsächlich als klassische Webanwendungen, als optimierte Version für mobile Endgeräte sowie als Fatclients, zum Beispiel für Call-Center-Anwendungen oder Kassensysteme, implementiert. Aufgrund der Nachfrage nach mehr mobilen Nutzungsmöglichkeiten findet eine erweiterte Nutzung von Smartphones und Tablets als native Apps derzeit immer häufiger ihren Einsatz. Der Trend zu nativen Apps hat in den letzten Jahren seinen Höhepunkt erreicht, in Zukunft werden wieder vermehrt plattformneutrale User Interfaces zum Einsatz kommen. Callrouting via Interactive Voice Response (IVR) als eine schon etablierte Maßnahme wird ebenfalls häufig verwendet. Viele Unternehmen betreiben jedoch die Kundeninteraktionskanäle jeweils getrennt voneinander und ordnen sie bestimmten Produkten oder Kundensegmenten zu. Kundeninteraktionen sollten jedoch immer produktübergreifend konsistent und integriert für alle Kanäle aufbereitet sein. Die Integration der unterschiedlichen Hardwarevarianten versteht sich von selbst. DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

8 3. Interview mit Carsten Klingels, E.ON Raus aus der verstaubten Technikecke! Multikanalarchitektur ist für viele ein trockenes, technisches Thema. Für Carsten Klingels ist es eines der wichtigsten Themen überhaupt, denn für ihn steht der Mehrwert, wie man gegenüber dem Kunden auftritt, klar im Vordergrund. Es geht um die Flexibilität, in Zukunft gegenüber dem Kunden anders aufzutreten, als das vielleicht heute noch der Fall ist. DMR: Was sind aus Ihrer Sicht die Kernherausforderungen einer Multikanalarchitektur? KLINGELS: Die Kernherausforderung ist für mich zunächst, das Business / die Fachabteilung für diese abstrakte Thematik zu sensibilisieren. Für die reine Business- Architektur geht es ja eher um die Wertschöpfung in spezifischen Kanälen und Fragen wie Haben wir ausreichend Kanäle? Sind diese richtig ausgeprägt? Müssen wir Optimierungen vornehmen? Wir wollen aber die übergreifende Sicht herausstellen und zeigen, welchen Mehrwert man über Multikanal- oder Omnikanalmanagement erreichen kann, um ein eindeutiges, konsistentes Erleben der Firma in Richtung Kunden zu bewerkstelligen und firmenseitig alle Touchpoints des Kunden mit uns sichtbar zu machen. Das war in der Vergangenheit nicht gegeben. Die Sensibilisierung hierfür ist deshalb für mich eine der Kernherausforderungen. Zweitens handelt es sich doch um ein sehr technisches Thema, wenn man nicht ausschließlich über die nach außen sichtbaren Kanäle spricht, sondern einen Blick unter die Motorhaube wirft. Es ist zwingend erforderlich, ein Verständnis dafür zu schaffen, dass dieses Thema auf einem Reifegradmodell basiert. Man kann nicht von heute auf morgen eine Multikanalarchitektur umsetzen, sondern man benötigt eine gewisse Zeit, Erfahrungen sowie Tätigkeiten, um ein Omnikanalmanagement beziehungsweise die Architektur herstellen zu können. Das Verständnis dafür ist die zweite Herausforderung. Drittens bin ich der Meinung, dass Multi- oder Omnikanalmanagement nicht eine Lösung ist, sondern eine Architektur, die einer Philosophie folgt. Das kann nicht in einer Lösung abgebildet werden. DMR: Sie haben den Anspruch, das Verständnis eines einheitlichen Kundenerlebnis über alle Kanäle hinweg sicherzustellen. Steht der Kunden-Sales-Service vor den gleichen Problemen oder gibt es hier spezifische Herausforderungen? KLINGELS: Sowohl als auch. Spezifisch, weil wir verstehen müssen, was der Kunde als Service wünscht. Wir können nicht vorschreiben, welche Services der Kunde nutzen soll. Welche Services aber wünscht der Kunde? Die Multikanalarchitektur ist hier abstrakter, der Service ist greifbarer. Wie komme ich also an diese Information heran und wie gehe ich dann weiter vor? Was aus meiner Sicht extrem wichtig ist, wenn wir Services anbieten: Sie müssen funktionieren! Und sie müssen eine für den Kunden vernünftige Qualität aufweisen. Das läuft unter dem Stichwort Get the basics right!. 6 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015

9 DMR: Aus vorangegangen Diskusionen im Rahmen dieses Themas habe ich ein Zitat vorliegen: Ohne übergreifende Prozessexzellenz ist die Multikanalarchitektur zum Scheitern verurteilt. Stimmen Sie zu? KLINGELS: Mich stört das Prozess-Wording. Ich würde das nicht mehr als Prozess-Exzellenz beschreiben, sondern als Customer Journey, die übergreifend gestaltet werden muss. Das muss nicht mehr der alten Prozesswelt entsprechen. Die Kundenseite ist doch entscheidend! Man muss auf die Fähigkeiten bauen, die die Customer Journey unterstützen und darauf einzahlen. DMR: Ein weiteres Thema ist das kohärente Datenmanagement: Verschiedene Einheiten halten unterschiedliche Daten vor, Produkte und Produkt- sowie Kundeninformationen stehen oft nicht in Korrelation, in den Kanälen befinden sich Produkte mit verschiedenen Stammdaten. Wie sieht Ihre Sichtweise hierzu aus? KLINGELS: Das ist ein sehr wichtiger Punkt. Aus meiner Sicht ist kohärentes Datenmanagement aber nicht gleich übergreifend über alle Daten nötig, sondern vor allem dort, wo es sich um Kundendaten handelt. Was will der Kunde mit uns machen, welche Vorgänge gibt es hierzu, was ist wichtig für die Customer Journey? Diese Daten sichern den kanalübergreifenden Erfolg und müssen der Kohärenz unterliegen, das muss nicht gleich mit allen Datentöpfen passieren. Man kann mit dieser Sichtweise kleiner anfangen und dann die Dinge ausbauen. DMR: Gibt es ein führendes System aus Ihrer Sicht? Die Telco-Kollegen beispielsweise haben spontan gesagt: CRM. Die Retail-Kollegen nannten Produktinformationen sowie den Kundenkontakt bei der Kaufentscheidung als führend. Wie sieht das bei einem Versorger aus? KLINGELS: Man tendiert natürlich schnell dazu, auch CRM zu nennen, denn das steht auch bei uns im Zentrum. Wenn ich mir aber die Weiterentwicklung anschaue, gibt es garantiert Szenarien, wo der Kunde Anwendungsfälle mit uns als Case hat, in denen ein CRM überhaupt nicht zum Einsatz kommt. Das kann zum Beispiel über Self-Services laufen, in denen Interaktionen des Kunden auch ohne CRM- Einbezug stattfinden können. Ob das in der Zukunft so bleiben wird, bin ich mir nicht sicher, weil der Gedanke einer Multikanalarchitektur bei uns ein Case Management, eine zentrale Sicht auf die Touchpoints mit dem Kunden bildet, und am Ende das datenführende System eine zentrale Rolle spielt. DMR: Je nachdem, in welchem Case man sich befindet, übernimmt also ein bestimmtes System die führende Rolle? KLINGELS: Wir sind bei weitem noch nicht fertig und haben dies noch nicht umgesetzt. Meine Erwartungshaltung ist, dass sich ein Fokusbereich herauskristallisiert, der durchaus bestimmte Fähigkeiten mit sich bringt. Das muss aber nicht ein System sein. DMR: Die Kundensicht ist also der Filter? KLINGELS: Ja. Wir haben eine Outside-in-view auf der Datenseite, aber natürlich auch eine Inside-in-view, es gibt ja auch Interessen von der Company-Seite, etwas zu verkaufen (lacht). Die Dateninhalte sind aber ähnlich wie outside-in. DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

10 DMR: Schauen wir uns einmal gemeinsam den Markt an: Haben die Anbieter im Bereich Multikanalmanagement ein relativ geschlossenes Offering? KLINGELS: Nein. Tatsächlich deckt kein Anbieter am Markt vollständig unsere Anforderungen ab, sondern immer nur Teilbereiche, in denen es aber durchaus sehr gute Lösungen gibt. Bei vielen Anbietern dreht sich alles um den Nukleus Call Center, weil viele Kanäle hier zusammenlaufen. Hier werden etliche Lösungen angeboten. Langfristig bin ich aber nicht sicher, ob das Call Center wirklich der Nukleus ist. Das greift nicht weit genug. DMR: Viele Unternehmen starten ja das Thema Multikanal aus der Call-Center-Brille heraus. KLINGELS: Ich glaube schon, dass das richtig ist, um sich mit einem großen Schritt innerhalb des Reifegradmodells der Thematik zu nähern. Damit ist schon sehr viel gewonnen, denn die Herausforderungen liegen aktuell in diesem Umfeld. In Richtung Zukunft müssen wir dann aber noch einen Schritt weiter gehen, und da sind die Produkte am Markt noch nicht so weit. Integrationsfähige Produkte sind extrem wichtig. DMR: Thema Cloud oder On Premise es gibt Unternehmen, die voll auf die Cloud setzen, andere sind On Premise unterwegs, einige verfolgen aber auch einen hybriden Ansatz. Worauf setzen Sie? KLINGELS: Wir sind derzeit mit einem hybriden Ansatz unterwegs. Jeder versucht, die Vorteile des jeweiligen Ansatzes zu nutzen und das in seine Konzernlandschaft und seine Arbeit effizient zu integrieren. Ich bin nicht von einem Ansatz allein vollständig überzeugt, es gibt Für und Wider für beide Ansätze. DMR: Sie haben also keine klare Zuordnung getroffen in dem Sinne, dass es ein absolutes No Go wäre, in die Cloud zu gehen? Das Beispiel Deutsche Telekom zeigt, dass dort die Daten auf deutschem Boden stehen müssen. KLINGELS: Nein, wir haben noch keine feste Strategie hierzu. Die Sicherheit der Daten steht massiv im Vordergrund. On Premise nutzen wir Dinge, die auf Konzernseite stattfinden. Für die Zukunft müssen wir sehr genau schauen, wo wir es uns erlauben können, in eine Cloud- Lösung tiefer einzusteigen. Es gibt ja verschiedenste Cloud- Ansätze, in denen man die Sicherheit der Daten und den Umgang mit den Daten sicherstellen muss. Aber man muss auch die Flexibilisierungsmöglichkeiten nutzen. Es gibt Business-Modelle oder auch interne Arbeitsprozesse ohne sensible Daten, da kann man mit so einem Ansatz viel mehr Agilität und Schnelligkeit in die Entwicklung von Geschäftsmodellen hereinbringen. DMR: Wo entstehen aus Ihrer Sicht die Kostentreiber? Oder schafft man eine reibungslose Implementierung durch saubere Planung? Worauf achten Sie besonders? KLINGELS: Erstens stehen bei uns agile Projekte im Vordergrund, die inkrementelle Erarbeitung, um zum Beispiel Big Bangs zu vermeiden. Zweitens: Wir brauchen frühes Feedback! Das ist eine ganz wichtige Geschichte, unabhängig davon, ob es Feedback von den Anforderern ist oder eben auch Kundenfeedback. 8 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015

11 Interview mit Carsten Klingels, E.ON DMR: Wie binden Sie die Kunden ein? KLINGELS: Das kommt natürlich immer ganz auf die Situation an. Wenn ich eine direkte Außenschnittstelle zum Kunden habe, kann ich auch direkt sehen, was der Kundenerwartung oder dem Kundenwunsch entspricht. Interne Kunden involvieren wir in den Entwicklungsprozess und lassen sie im Sinne von agilen Projekten mittesten. So erhalten wir frühes Feedback in Form einer Erwartungshaltung, das spart uns sehr viel Geld. DMR: Stichwort Agilität: Haben Sie den gesamten Entwicklungsprozess umgestellt? KLINGELS: Wir haben verschiedene Vorgehensmodelle innerhalb der Entwicklung. In der Vergangenheit waren diese eher Wasserfall-orientiert. Seit zwei Jahren haben wir eine massive Umstellung im Konzern auf agile Projekte. In manchen Teilen haben wir bereits 90 Prozent umgestellt. Wir verfolgen vor allem pragmatische Ansätze. Carsten Klingels ist seit dem 1. Juli 2014 in der Verantwortung des Bereichs Digital Solutions. Dieser Bereich fasst IT-seitig die Experten des E.ON-Konzerns zusammen, um Themenstellungen rund um Customer Experience, Collaboration Content sowie Daten- und Integrationsthemen zusammenzubringen und damit die digitale Transformation zu unterstützen. Digital Solutions umfasst 300 Mitarbeiter in sieben Ländern. DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

12 Empfehlungen und Gestaltungsparameter einer 4.Omnikanalarchitektur Services vor Kunde müssen grundsätzlich als eine Infrastrukturkomponente im Rahmen der Applikationslandschaft begriffen und entwickelt werden. Die einzelnen Architekturkomponenten sind in der zentralen Anwendungsarchitektur zu pflegen. Zusätzlich bedarf es hoher Flexibilität bei der Entwicklung neuer Applikationen und Customer Touchpoints. 10 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015

13 User Interface Konfiguratoren Service Community Service Apps Management Apps TV Themen- & Microsites Vertriebsinfos Kundenservice Plattform etc. Partner Sites Social Media Quelle: Detecon Prosumenten Fat Client Browser Mobile Browser Native Mobile App Interactive TV Smart Home Smart Appliances etc. Bereitstellung & Verteilung Administration & Management Integration Content Management Social Media Daten Master Data Katalog Shopping Bestellung & Aufträge Kundenmanagement Vertriebsdaten Unstrukturierte Daten Zahlung Inventar Benutzer / Profile Kunden Services Analyse & Reporting Metadaten Benutzermanagement & Personalisierung Informationssicherheit & -privacy Konnektivität & Interoperabilität Prozessorchestrierung Produktdaten Analysedaten Workflows Suche Services Abbildung 2: Komponenten einer Omnikanalarchitektur Zielarchitektur Idealtypus Eine zukunftsfähige Onmikanalarchitektur muss als servicebasierte Multi-Layer Architektur aufgesetzt werden, in deren einzelnen Schichten jeweils spezifische Fähigkeiten ausgeprägt sind. In Berührung kommt der Benutzer mit der Architektur an den User Interfaces beziehungsweise den Touchpoints. Diese werden technisch durch eine Reihe von Prosumenten implementiert. Eine Schicht zur Verteilung und Koordinierung der unterschiedlichen Services für die Verwendung in den Prosumenten entkoppelt die Front-Ends von den Applikationen, deren Services die Geschäftsprozesse implementieren. Die Integrationsschicht regelt den Zugriff der Adminstration & Management Services auf die Daten. Querschnittsfunktionen sorgen für ein reibungsloses Zusammenspiel der einzelnen Schichten. Die Module, die einer Omnikanalarchitektur zugrundeliegen, sind als wiederverwertbare Services abzubilden und technisch auszuprägen. Die Services dienen als zentrale und erweiterbare Bibliothek an Funktionen innerhalb der IT-Landschaft und fungieren als Baukasten für Implementierungsprojekte, um beispielsweise Time-to-Market- Zyklen zu verkürzen, Synergien durch die Wiederverwendung von bereits genutzten Anwendungen zu ermöglichen und zuvor getätigte Investitionen zu sichern. Ein konsistentes Integrationsframework stellt sicher, dass die einzelnen Module effizient miteinander kommunizieren können und die Gesamtarchitektur flexibel genug ist, um neuen Anforderungen schnell gerecht zu werden. Daher ist grundsätzlich eine Serviceorientierung der Architektur zu beachten, die außerdem in der Lage ist, eventdriven zu reagieren, und sowohl synchrone als auch asynchrone Nachrichten unterstützt. In der Regel besteht die Herausforderung eher darin, das Integrationsframework auf eine kleine Menge geeigneter Integration-Patterns zu konzentrieren und nicht alle Integrationswege zuzulassen, die möglich sind. DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

14 User Interface Prosumenten User Interface Service Community TV Vertriebsinfos Prosumenten Service Apps Konfiguratoren Kundenservice Plattform Management Apps Themen- & Microsites etc. Partner Sites Social Media Fachliche User Interfaces müssen auf unterschiedlichen technischen Prosumenten abgebildet und aus einer einheitlichen im Vergleich zu den Frontends langlebigeren Infrastruktur gespeist werden. Prosumenten ermöglichen den Benutzern, nicht nur Inhalte zu konsumieren, sondern auch Inhalte und Informationen zurück zu geben. Diese wiederum müssen verarbeitet werden. Häufig lassen sich über einen Prosumenten mehrere Touchpoints realisieren, was die Entwicklungs- und Wartungsaufwände reduziert und es erleichtert, für Konsistenz zwischen den Touchpoints zu sorgen. Fat Client Browser Mobile Browser Interactive TV Smart Home Smart Appliances Abbildung 3: Prosumenten & User Interfaces Native Mobile App etc. Kundenfeedback wie die klassischen Bewertungsmöglichkeiten (Ratings) sowie Empfehlungs- und Kommentarfunktionen sind Kernmerkmale der Nutzerbindung. Grundsätzlich sollten Nutzer unkompliziert Inhalte generieren können (User Generated Content). Nutzergenerierte Inhalte können ausgezeichnet für die Bindung genutzt werden, zum Beispiel durch Beeinflussung von Suchrankings. User Interfaces (intern/extern) unterliegen einem steten Wandel. Der Presentation Layer muss in der Lage sein, aktuelle Frontend-Trends schnell umzusetzen ( Joy of Use ). Wichtig für die Ausgestaltung der User Interfaces sind Designrichtlinien und Vorgaben für eine einheitliche User Experience. Idealerweise findet sich ein Kunde immer sofort zurecht, da er die wichtigen und relevanten Funktionen an jedem Touchpoint in einheitlichem Look & Feel Namensgebung, Layout-Elemente und Farbgestaltung vorfindet. Gleichzeitig sind spezifische Eigenheiten der einzelnen Touchpoints zu beachten, um das jeweilige Potenzial optimal zu heben. Eine besondere Herausforderung ergibt sich dadurch, dass die Touchpoints nicht alle unter der eigenen Kontrolle liegen. Das Bedienen von externen Partnerseiten oder Social-Media-Angeboten muss inhaltlich konsistent zu den selbstkontrollierten Touchpoints gehalten werden. Dies lässt sich nur dann managen, wenn alle Inhalte aus den gleichen Quellen gespeist werden. Dies wird umso relevanter, wenn Serviceprozesse über mehrere Touchpoints hinweg ausgeführt werden müssen. Die Anzahl unterschiedlicher Endgeräte wächst ständig. Sind heute Apps für mobile Endgeräte sehr hip, haben diese das Problem, dass sie plattformabhängig sind. Ähnlich wie bei klassischen Applikationen, die vom Mainframe über den Desktop ins Web gewandert sind, wird die Webevolution auch den mobilen Softwaremarkt verändern. Dank Techniken wie Responsive Design lässt sich eine Webanwendung für die Darstellung auf unterschiedlichen Bildschirmgrößen optimieren und damit der gesamte Wartungsaufwand über alle Touchpoints hinweg deutlich verringern. Bereitstellung und Verteilung Wichtig für die Investitionssicherheit der Omnikanalarchitektur ist die Beantwortung der Frage, wie flexibel und schnell neue Services auf unterschiedlichen Kanälen ausgerollt werden können, ohne tiefe Eingriffe in die eigentliche Infrastruktur vornehmen zu müssen. 12 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015

15 Die Bereitstellung und Verteilung der Kundeninteraktionen in die technischen Kanäle muss deshalb über eine eigene Schicht abstrahiert werden, die Webformate, das native Entwickeln von mobilen Apps, aber auch die Integration in Point-of-Sales und Serviceline-Applikationen ermöglichen. Diese Schicht muss die Inhalte, die kanalunspezifische technische Services der Backends liefern, sehr spezifisch auf die verschiedenen abnehmenden Kanäle mit ihren technischen Spezialanforderungen wie Formatangaben verteilen. Dieses Orchestrieren, Aufbereiten und Verteilen von Inhalten ist eine Aufgabe, die sich durch spezielle Middleware-Applikationen kapseln lässt. Im Kontext der skizzierten Dynamik steht eine Omnikanalarchitektur vor der Herausforderung, an der richtigen Stelle Leistung und Lastvermeidung durch intelligente Nutzung von Caches als Pufferspeicher zu ermöglichen. Im Rahmen der Konzeption ist deshalb klar zu definieren, an welchen Stellen Informationen im Cache abgelegt werden können und wo dynamischer oder statischer Content auszuliefern ist. Administration & Management Administration & Management Content Management Social Media Katalog Kunden- Management Shopping Bestellung & Aufträge Zahlung Inventar Kunden Services Analyse & Reporting Abbildung 4: Bereitstellung & Verteilung / Administration & Management Kundeninteraktionen sollten in einer Managementschicht erstellt, konfiguriert und organisiert werden, welche die Omnikanalarchitektur mit Leben, mit Content und Services, füllt. Zur Unterstützung verschiedener Anwendergruppen, zum Beispiel spezieller Autoren aus der Produktund Shop-Redaktion, sind Cockpits gefordert, die technische Services in fachliche Sichten übersetzt. Eine grundsätzliche Herausforderung für diese Cockpits ist es, Inhalte und Applikationen verschiedenster Liefersysteme zusammenzufügen und den entsprechenden Kanälen zuzuordnen. In dieser Schicht steht und fällt die übergreifende Prozessunterstützung in der Omnikanalarchitektur. Die Prozessorchestrierung und die Individualisierung in den einzelnen Kanälen muss zentral gesteuert werden. Nur so lassen sich Prozessbrüche beim Kanalwechsel vermeiden und individuelle Stärken und Schwächen der einzelnen Kanäle optimal nutzen. Ein sehr relevanter Aspekt sind Anforderungen rund um die Auswertung des Nutzerverhaltens sowie die Möglichkeiten, auf dieses unmittelbar zu reagieren. Hierzu müssen sowohl interne als auch meist umfangreiche externe Quellen aus dem Social Web ausgewertet und in Korrelation gesetzt werden (Social Media Analytics). Die Auswertungen sind für das Customer Experience Management von zentraler Bedeutung: Wo hat der Nutzer seine Trampelpfade durch das System gezogen? Wo hat er den Service verlassen oder den Prozess abgebrochen? Nutzerbindungskonzepte werden mit unterschiedlichen Funktionen wie Heatmaps, Klickpfadanalysen und Recommendation Engines, die komplexe Warenkorbanalysen durchführen können, unterstützt. Grundsätzlich muss jede Omnikanalarchitektur Funktionen bereitstellen, die eine Auswertung des Nutzerverhaltens ermöglichen beziehungsweise für spezialisierte Tools Schnittstellen anbieten, die diese Funktion übernehmen. Aufgrund Touchpoint- und kanalübergreifender Prozesse ist es wichtig, diese Analysen nicht nur auf die Oberflächen zu begrenzen, sondern mit dem prozessführenden System zu verbinden. Eine Suchmaschine spielt im Kontext der Omnikanalarchitektur eine wichtige Rolle. Sie muss sowohl in der Lage sein, die Frontend-Suche für die Nutzer abzubilden als auch Drittsysteme anzubinden. Ein Großteil der Cockpits für Administratoren und Fachanwender ist abfragegesteuert. In Zukunft werden immer mehr Anwendungen auf Basis von Search-Abfragen umgesetzt. Eine Enterprise Search bietet dabei Funktionen, um Daten aus allen relevanten Backendsystemen zu indizieren und rechteabhängig durchsuchbar zu machen. Enterprise Search vermag dabei jedoch keine Wunder zu vollbringen, vielmehr ist sie angewiesen auf einen sauberen Datenbestand und gewissenhafte Indexpflege. DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

16 Integration Daten Master Data Abbildung 5: Datenintegration Produktdaten Vertriebsdaten Analysedaten Unstrukturierte Daten Benutzer / Profile Metadaten Workflows Suche Services Der Zugriff auf die Daten von sowohl generischen Systemen, zum Beispiel CRM-System, als auch spezifischer Self- Service-Systeme, zum Beispiel Web Content, muss über eine einheitliche Integrationsschicht organisiert werden. Eine der wichtigsten Prämissen für die Entwicklung der Omnikanalarchitektur muss sein, möglichst keine Business- Logik im Self-Service nachzubauen oder parallel zu implementieren, sondern stets den Weg zur möglichst abstrahierten und einheitlichen Integration von logikführenden Backend- und Legacy-Systemen zu wählen. Eine zentrale Anforderung an den Self-Service ist die Bereitstellung von Backend-Informationen, Prozessen und Funktionen spezialisierter Softwaretools in konsolidierten Sichten. Ein Unternehmen muss sich unter Architekturgesichtspunkten die folgende zentrale Frage stellen: Wie wollen wir Applikationen in die Omnikanalarchitektur integrieren? Alle weitergehenden Konzepte bezüglich der Konnektivität von Anwendungen, dem Messaging & Routing von Informationen, speisen sich aus der Antwort auf diese Fragen. Grundsätzlich sollte die Architektur durch wiederverwertbare Services mit offenen Interfaces und dem Support von Data Federation Technologien modularisiert werden. Idealerweise kann die Omnikanalarchitektur hier bereits auf eine einheitliche, servicebasierte Integrationslandschaft aufsetzen. Häufig findet man jedoch voneinander unabhängige Silo-Architekturen. Um hier nicht die Zukunftsfähigkeit der Omnikanalarchitektur zu gefährden, ist eine Definition und Bereitstellung von lose gekoppelten Services unumgänglich, die die Zugriffe auf die Bestandssysteme kapseln. Backend Auch das übergreifende, konsistente und kohärente Datenmanagement ist eine zwingende Voraussetzung für das Funktionieren einer übergreifenden Omnikanalarchitektur. Hier ist vor allem eine organisatorische Hürde zu überwinden: Daten werden verteilt, gepflegt und vorgehalten. Um Daten in adäquater Pflegequalität zentral vorzuhalten, sind aufwendige Konsolidierungsschritte notwendig. Hier müssen übergreifende Master-Data- Management-Initiativen aufgesetzt und organisatorisch verankert werden. Analog zur Integration sollte sich die Omnikanalarchitektur grundsätzlich bestehender Datenquellen bedienen und in bestehende Datenpflegeprozesse einfinden. Ein wichtiger Parameter für die kanalübergreifende Nutzung und Wiederverwendung von Inhalten und Daten ist die einheitliche Verwendung von Metadaten, die eine eindeutige Identifizierung des Dokuments (Identifier) ermöglicht. Technische Zusatzinformationen wie Format, Typ und Sprache, eine zusammenfassende und strukturgebende Beschreibung des Inhalts Titel, Subjekt, Beschreibung, Informationen zu Ersteller und Rechten sowie zum Lebenszyklus Zeitstempel, Gültigkeit müssen einheitlich definiert und verwendet werden. Metadaten bieten ungeahnte Möglichkeiten, unstrukturiertem Content einen quasistrukturierten Charakter zu verschaffen und ihn wiederverwertbar und auffindbar zu machen. Eine besondere Funktion und Rolle haben Quelle, Relation und Audience als Metainformationen zur Vernetzung. Hierüber lassen sich die Zuordnung der Services zu Kanälen sowie das Verknüpfen einzelner Services organisieren. Für eine übergreifende Omnikanalarchitektur, welche sich aus verschiedenen Repositories und unterschiedlichen Backend-Systemen bedient, ist übergreifendes Metadata Management die Kernvoraussetzung. Metadaten bieten außerdem eine große Flexibilität in der Erstellung von Taxonomien und alternativen Navigationsbäumen als klassisch hierarchische Verwaltungsmechanismen. Seine volle Kraft kann Metadata Management aber nur entfalten, wenn das Metadatenmodell in Korrelation und Abstimmung mit den oben erwähnten übergreifenden Master-Data-Management-Initiativen entwickelt wird und erweiterbar bleibt. 14 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015

17 Ein weiterer wichtiger Aspekt für eine Omnikanalarchitektur ist die sichere und zuverlässige Unterstützung von Transaktionen. Handelslastige Usecases beispielsweise definieren komplexe Produkte nicht auf der Basis eines Artikelstammpasses, sondern vielmehr als eine Folge verschiedener, sich einander bedingender Prozessschritte mit beispielsweise spezifischen Angeboten und Kalkulatoren für Kunden (Rahmenverträge für spezifische Produkte), Verfügbarkeitsprüfungen (Produkt auf Lager, Produkt regional verfügbar), komplexen Produktabhängigkeiten (Ersatzteilbestellungen, Service Upgrades) und der Anbindung an die Backend-Systeme, in denen Bestellungen prozessiert werden (Produktion, Logistik und Rechnungslegung). Solche Transaktionen sollten in ihrer Komplexität und Spezialisierung niemals in der Self-Service-Infrastruktur nachgebaut, sondern stets über Schnittstellen konsumiert und beliefert werden. Hier liegt sicherlich eine der Kernherausforderungen einer Omnikanalarchitektur: die kontinuierliche Garantie der notwendigen Transaktionssicherheit. Querschnittsfunktionen Spezifische Querschnittfunktionen wie die Orchestrierung der Prozesse, das Sicherheitshandling oder die Personalisierung müssen architekturweit über alle Schichten hinweg zur Verfügung stehen. Sie fassen alle zentral genutzten Services und Anforderungen an die Omnikanalarchitektur zusammen. Diese zentralen Services stellen technische Basisfunktionen bereit, die nach der Erstimplementierung als relativ stabil zu betrachten sind. Bei der Definition und Entwicklung dieser Querschnittsfunktionen ist somit besondere Sorgfalt gefragt, kleine Änderungen im Kern können immer große Auswirkungen auf die peripheren Services und Funktionen haben. Die Anbindung eines Identitätsmanagementsystems, welches das Rechte- und Rollensystem unterstützt, ist für die Ausprägung von Cockpits unerlässlich. Sie ist aber ebenso Grundvoraussetzung für die Umsetzung von AAA (Authentication, Authorization, Accounting)-Konzepten als zentrale Voraussetzung für SSO und die Personalisierung. Beispielsweise muss ein Max Mustermann, der an einem Touchpoint identifiziert wird, im Ordersystem die gleiche Identität haben. Digitale Interaktionen in einer Omnikanalarchitektur bieten viele unterschiedliche Zugriffsmöglichkeiten auf personalisierte Informationen, Services und Prozesse. Diese Eingangstore sind gleichzeitig auch potenzielle Gefährdungsstellen für die Datensicherheit. Eine der Top 3 Anforderungen von Kunden an digitale Interaktionen sind Datensicherheit und Datenschutz. 2 Die Diskussionen rund um die NSA-Affäre haben in Deutschland wie auch in anderen Ländern dieses Thema ganz nach oben gespült. Wichtigstes Ziel ist deshalb die Integrität der Services. Vertrauen der Kunden, das einmal aufgrund unzureichender Sicherheitsvorkehrungen verloren ging, ist nur mit sehr großem Aufwand wieder aufzubauen Eine Omnikanalarchitektur muss deshalb umfangreiche Mechanismen der Eingangssicherung und Zugangskontrolle, zum Beispiel sicheres SSO (Single Sign On), bedienen, die Verbindungen zwischen Endgerät und Servern verschlüsseln und die Daten entsprechend der Vorgaben des Datenschutzes verwalten und ablegen. Anforderungen an die Sicherheit sind aber nicht nur soft- und hardwareseitig, sondern auch prozessual zu definieren und abzuprüfen. Regelmäßige und unabhängige Penetrationstests und Security Audits müssen selbstverständlich durchgeführt werden. 2 Vgl. Customer Self-Services, Effizienz und Kundenbindung im Zeitalter der Digitalen Transformation, Studie, Andreas Penkert, Patrick Eberwein, Viktoria Salma, Sascha Krpanic, Februar DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

18 Benutzermanagement & Personalisierung Informationssicherheit & -privacy Konnektivität & Interoperabilität Prozessorchestrierung Abbildung 6: Core-Services Personalisierte Inhalte sind im Kontext von Omnikanalansätzen eine Selbstverständlichkeit. Doch welche technischen und funktionalen Paradigmen liegen der Personalisierung zugrunde? Wie flexibel können Inhalte und Applikationen auf das Nutzerverhalten hin ausgesteuert werden? Werden Benutzerrechte auf angebundene Inhalte aus Drittsystemen übertragen oder sind diese Systeme weiterhin selbst für das Rechtemanagement verantwortlich? Im Rahmen der Entwicklung einer Omnikanalarchitektur ist zu klären, ob Personalisierung mit den Rules Engines, zum Beispiel einer Portalsoftware oder einem 3rd Party Personalization Framework, umzusetzen ist. Als führendes System muss deshalb zwingend das CRM-System angebunden werden, um die notwendigen Kundenstammdaten zu personalisieren. Bedingungen zum Aufruf sowie Abhängigkeiten enthalten. Ohne eine übergeordnete Prozessorchestrierung kann eine übergreifende Transaktionssicherheit nicht gewährleistet werden. Hier ist das Session Handling eine wichtige Funktion, welche dazu dient, die Nutzer und ihre Aktivität eindeutig im System zu verorten. Session Handling muss die Anforderung erfüllen, Sessions auf einem Kanal zu beginnen und auf einem anderen weiter zu führen. Somit muss das Session Handling abstrahiert vom eigentlichen Kanal funktionieren und ist Kernvoraussetzung für die Transaktionssicherheit. Die Orchestrierung bedarf eines zentralen Repositories, an dem Services angemeldet werden und über welches diese verwaltet werden können. Das Services Repository fungiert quasi als zentrales Telefonbuch für die Omnikanalarchitektur und dient der Orchestrierung der einzelnen Services sowie der dazu gehörigen Präsentationskanäle. Alle Kanäle müssen über Referenzpunkte, zum Beispiel Metadaten, an eine einheitliche Informationshaltung und die Prozesse angebunden werden. Wichtiger Bestandteil einer servicebasierten Architektur ist die Prozessorchestrierung, welche das flexible Kombinieren mehrerer Services zu einer Services-Komposition, einem ausführbaren Geschäftsprozess, beschreibt. Diese Orchestrierung muss eine Beschreibung der Services, ihre 16 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015

19 Klare Zuständigkeiten und Rollen ermöglichen Wiederverwendung und Investitionsschutz Ein ganzheitlicher Ansatz in der Entwicklung der Anwendungsarchitektur für eine Omnikanalarchitektur bedarf einer klaren Definition der Aufgaben der eigentlichen Frontend-Applikationen sowie der Abgrenzung zu spezialisierten Support- und Backend- Systemen. Definierte Regeln für die Weiterentwicklung auf unterschiedlichen Ebenen sind im Zuge dessen bereits vorab festzulegen. Eine wichtige Voraussetzung für die Investitionssicherheit der Omnikanalarchitektur sind standardisierte, stabile und dokumentierte APIs und Interfaces. Customizing und Weiterentwicklung müssen auf der Basis dieser APIs aufgesetzt werden. Idealerweise kann die Omnikanalarchitektur auf einem bereits etabliertes Integrationsframework mit standardisierten APIs aufbauen. Zusätzlich zur Kapselung der Entwicklung auf der Basis von APIs muss eine moderne Infrastruktur in der Lage sein, auf der Basis von Templates und Scripting die Entwicklung von Applikationen auf dem Presentation Layer leichtgewichtig und abstrahiert zur Verfügung zu stellen. Insbesondere Anforderungen, die die Benutzeroberflächen betreffen, lassen sich nur erfüllen, wenn Änderungen auf dem Presentation Layer leicht durchgeführt sowie schnell und ohne Ausfallzeiten abgewickelt werden können. DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys

20 Interview mit Karin Hausdorf und Guido Sewitza, RWE IT Übergreifender Kundenservice 5.auf verschiedensten Kanälen DMR: Wo sehen Sie die Kernherausforderungen einer Multi- oder Omnikanalarchitektur und was treibt Sie bei diesem Thema am meisten um? Sewitza: Die zentrale Datenhaltung. Für mich ist die zusammenhängende Sicht auf die Daten von großer Bedeutung Stichwort 360º-Blick auf den Kunden. Viele Unternehmen haben Insellösungen im Einsatz, bis vor kurzem auch RWE. Man hat beispielsweise ein Onlineportal, in dem der Kunde die Onlineservices der VAG über einen separaten Link aufrufen kann. Die Durchführung der eigentlichen Services wie die Erfassung der Zählerstände, Änderung des Abschlagsbetrags erfolgt jedoch in einer separaten Anwendung. Im Backend-System kann man dann zwar sehen, dass ein Kunde mehrfach angerufen hat, aber man weiß nicht, ob er sich auch über das Internet gemeldet hat. Diese Daten zusammenzuführen, ist für mich die Kernherausforderung. Der Multikanalansatz von RWE beinhaltet eben genau das: Man sieht alles auf allen Kanälen und kann fokussiert darauf reagieren. DMR: In vielen Gesprächen erhielten wir das Feedback, dass neben dem Thema der Datenhaltung auch das Thema der individuellen technischen Anforderungen der unterschiedlichen Kanäle als Herausforderung gesehen wird. Man muss sich jetzt also mit Kanälen auseinandersetzen, die man noch gar nicht so gut kennt und in Folge noch kein Know-how an Bord hat, zum Beispiel beim Thema Kiosksysteme oder auch bei Plattformen mit Partnern, die man bestücken muss. Teilen Sie diese Ansicht? Hausdorf: Ja, absolut. Ich würde es aber sogar noch allgemeiner formulieren: Die wesentliche Herausforderung bei der Inbetriebnahme einer Multikanalarchitektur sind die Schnittstellen der unterschiedlichen Systeme und Kanäle. Was trennt diese Kanäle und was haben sie gemeinsam? Je mehr Gemeinsamkeiten man für die Eingangskanäle identifizieren kann, desto einfacher ist es. Zu Beginn eines Projekts sollte man deshalb möglichst viele Gemeinsamkeiten finden. Und man sollte darauf Wert legen, dass die einzuführende Multichannel-Plattform im Standard alle Kanäle abdeckt auch solche, die man vielleicht zu Beginn noch gar nicht einführen möchte. Sewitza: Wenn man zum Beispiel als Unternehmen über Facebook kontaktiert wird, sollte diese Information auch im CRM-System zur Verfügung stehen, um dann auch von dort aus die Anfragen beantworten zu können. Derzeit erfolgt die Entgegennahme und Bearbeitung der Anfragen über eine separate Facebook-Gruppe. Das sollte man letztendlich zentral steuern können. DMR: Ist Ihre Anforderung an das Multikanalmanagementsystem die an ein System, das alle Kanäle out-of-thebox kann, oder eher an ein System, das eine gewisse Entwicklungsflexibilität in sich trägt und in dem man die Kanäle entsprechend entwickeln kann? Hausdorf: Das Multichannel-System sollte out-of-thebox schon mit allen Kanälen umgehen können. Aber natürlich ist das System in seiner endgültigen Ausprägung eine Projektlösung, die von IT und Fachbereich erarbeitet wird. Es ist ja nicht so, dass man eine CD einlegt und dann ist alles fertig. Die Grundfunktionalität aller Kanäle sollte aber das Produkt schon mitbringen, das unterscheidet ja gerade die Telefonanlage von Multichannel-Plattformen. DMR: Würden Sie mitgehen, wenn ich sage, ohne übergreifende Prozessexzellenz sind Multikanalansätze zum Scheitern verurteilt? Sewitza: Ja. Man benötigt die Rückmeldung des Kunden, um Prozesse zu verbessern, vor allem, um auch die übergreifenden Prozesse zu optimieren. Dafür sind Rückmeldungen vom Kunden sehr wichtig. 18 DMR Impulse Omnikanalarchitektur Fundament für erfolgreiche Customer Journeys 2015