Lehren aus der Entwicklung einer Omnichannel-Verkaufsplattform in der Telekommunikation 

Die Bereitstellung einer echten Omnichannel-Plattform in der Telekommunikation, die sowohl den Kunden als auch den Mitarbeitern über alle Touchpoints und Verkaufsprozesse dient, ist eine gewaltige Aufgabe. Im Rahmen eines typischen Telco-Angebots können Verträge mit oder ohne Gerät gekauft oder verlängert werden, mit Barzahlung, Ratenzahlung, zusätzlichen TV-Abonnements und VAS-Bundles. Oftmals können Sie zusätzlich noch Versorgungs- und
Finanzdienstleistungen bündeln. Dies kann über mehrere Kanäle erfolgen, mit unterschiedlichen Varianten für Individuen und Unternehmen. Deshalb ist es im Vergleich zu einem Standard-E-Commerce im Einzelhandel ein viel komplexeres Transformationsprojekt. 

In diesem Artikel teile ich unsere Erfahrungen aus unseren Projekten zur Implementierung von Omnichannel-Plattformen mit, die sowohl Vertriebskanäle als auch kundenorientierte Systeme umfassen. Unser typischer Kunde verfügte über eine große Anzahl von Altsystemen, die jeweils für einen separaten Vertriebskanal und eine Produktlinie bestimmt waren, was zu einer langsamen Markteinführung, hohen Kosten und Wartungsproblemen führte. Der gewählte Ansatz war eine Migration der meisten Prozesse und Produkte auf eine einzige Omnichannel-Plattform, um die Kosten zu senken und dem Kunden ein besseres Erlebnis zu bieten. 

Geschäftsprozessdesign 

Während die Omnichannel-Prämisse als Konzept recht einfach erscheint, ergeben sich mit den neuen Möglichkeiten viele schwierige Geschäftsfragen. Es ist besser, diese Fragen zu beantworten, bevor man mit der Umsetzung beginnt, denn die Änderung der bestehenden Geschäftsstruktur und der Backend-Prozesse (zum Beispiel Logistik oder Finanzen) ist nicht trivial und dauert in der Regel länger als geplant. Nachfolgend finden Sie typische geschäftliche Schlüsselfragen im Zusammenhang mit dem Omnichannel-Vertrieb, die in einem frühen Stadium des Projekts geklärt werden sollten. 

Wer in der Organisation wird für die Konfiguration und Entwicklung der zentralisierten Omnichannel-Plattform verantwortlich sein, da sich die zuvor getrennten Channel-Abteilungen jetzt auf gemeinsame Richtlinien einigen müssen? Unabhängig von der
konkreten Antwort ist eine einzelne Plattform für ein Team aus mehreren Channel-Managern schwieriger zu verwalten. Von der technischen Seite her sollte es eine starke Architektur-Governance geben, um die Zunahme redundanter Funktionen zu vermeiden, aber dennoch die Entwicklung und den Einsatz des Systems entsprechend den spezifischen Anforderungen eines jeden Touchpoints und einer Roadmap zu ermöglichen. Andernfalls wird die neue Lösung als ein Hindernis statt als Ermöglicher behandelt. 

Ein konvergenter Mehrproduktwarenkorb wirft in der Regel mehrere interessante Gestaltungsfragen auf. Ein gängiger Fall ist die Fähigkeit, ein Bündel von Services und Produkten zu bestellen, von denen einige möglicherweise Installationsservices benötigen, während andere einen Besuch in einem Ladengeschäft zur Abholung erfordern. Solche
Bestellungen beginnen als einzelner Warenkorb mit möglichen speziellen Gesamtrabattpreisen, müssen jedoch in separate Unterbestellungen aufgeteilt und auf unterschiedliche Weise abgeschlossen werden, normalerweise in verschiedenen Backend-Bestellverwaltungssystemen. Dies verkompliziert die Logik der Kundenauftragsabwicklung, da jedes Problem mit einem Teilauftrag zu technischen Kopfschmerzen führen kann. Wie ist
mit dem Gesamtrabatt zu verfahren, der dem Kunden in einem Abrechnungssystem bereits gewährt wurde, wenn einer der Teilaufträge storniert wurde? Die Kosten für die manuelle Lösung solcher Fälle sollten in Betracht gezogen werden, oder es sollte ein automatisierter
Prozess designt werden. Ein weiteres Beispiel für eine Komplikation bei der gleichzeitigen Bestellung mehrerer Produkttypen wäre die Zulassung verschiedener Zahlungsarten, was die Logik der Auftragserfassung noch weiter verkompliziert. 

Die Kosten für die Implementierung eines solchen vollwertigen Mehrproduktwarenkorbs müssen berücksichtigt werden, da die unvermeidliche Systemkomplexität die Vorteile überwiegen könnte. Der Rat hier wäre, zuerst zu überprüfen, ob die Kunden alle diese Optionen tatsächlich benötigen und nutzen werden und ob dies einen echten Mehrwert bringt. Ein weiteres gutes Beispiel für die mit Omnichannel verbundene Komplexität sind Provisionen aus Verkäufen - insbesondere aus Bestellungen, die in einem Kanal begonnen, aber in einem anderen abgeschlossen werden. Solche Regeln können für das Verkaufspersonal schwer zu verstehen sein und führen zu der technischen Frage, wie der
Flow des Warenkorbs, der ausgesetzt, wieder aufgenommen und Produkte in verschiedenen Kanälen hinzugefügt wurde, verfolgt werden kann, um aussagekräftige Berichte für die Provisionsberechnungsregeln zu erstellen. Bevor Sie mit der Entwicklung eines benutzerdefinierten Systems und einer Logik beginnen, ist es wiederum besser, die Anzahl
solcher Fälle zu überprüfen und zu überlegen, ob einfachere Regeln implementiert werden könnten, um einige Probleme insgesamt zu vermeiden. 

All dies scheint im Nachhinein offensichtlich zu sein, aber wenn man ein großes, ehrgeiziges Programm startet, stellen sich viele solcher Fragen, und ohne eine starke Aufsicht über die Architektur können sich übereilte Entscheidungen in der Konzeptphase später als sehr kostspielig erweisen. Der Wert aller Omnichannel-Funktionen sollte von den Product Ownern vor Beginn der Implementierung validiert und diskutiert werden. 

Herausforderung Produktkatalog 

Der Produktkatalog ist wahrscheinlich der wichtigste Faktor für eine erfolgreiche E-Commerce-Transformation, da er die Grundlage für alle darauf aufbauenden Handelsfunktionen bildet. In der Regel gibt es mehrere Designaspekte, die berücksichtigt werden müssen: 

• Mehrere Produktlinien mit unterschiedlichen Konfigurationsmodellen 

• Integration und Abbildung bestehender Abrechnungsservices und Produkte aus separaten Systemen in einem einzigen Verkaufskatalog 

• Unterschiedliche Preisgestaltungsalgorithmen pro Produktlinie und eine breite Palette von Preis- und Rabatttypen 

• Komplexität der Konfiguration gegenüber schneller Markteinführung und Leistung der endgültigen Lösung. 

Die Bereitstellung mehrerer Produktlinien auf einer einzigen Plattform, die aus komplexen Bündeln von Telekommunikationsabonnements, Geräten, VOD-Paketen und anderen VAS-Services besteht, geht in der Regel über die bestehenden Basisfunktionen der Handelsplattform hinaus und kann die Implementierung einer speziellen Produktkataloglösung erfordern. Natürlich müssen die Anpassungen so gestaltet sein, dass sie den zukünftigen Upgrade-Pfad des Systems nicht blockieren. Unternehmen, die ihr Angebot vereinfachen - weg von komplexen, verwirrenden Angeboten, hin zu einfachen Angeboten - werden ein viel leichteres Leben haben. 

Die Integration eines Vertriebsproduktkatalogs mit Konfigurationsquellen - wie bestehenden CRM- oder Abrechnungssystemen - bedeutet ein Aufeinanderprallen zweier völlig unterschiedlicher Welten, Marketing kontra Abrechnung. Es ist eine heikle Aufgabe, verschiedene Modelle auf ein gemeinsames Modell abzubilden, das dann mit Marketinginformationen angereichert wird. Insbesondere Kabelfernsehanbieter wachsen in der Regel durch die Übernahme kleinerer Konkurrenten und bauen eine unübersichtliche Architektur mit technischen Schulden auf, wobei jeder Katalog und jedes Produkt anders definiert ist. Viele verschiedene Modelle und komplexe Preisfindungsalgorithmen erhöhen die
Gesamtkomplexität und wirken sich auf die endgültige Leistung aus, wenn zum Beispiel versucht wird, eine Liste mit verschiedenen Produkttypen zu präsentieren. Eine Möglichkeit zur Entschärfung des Problems der alten Komplexität besteht darin, auf Unternehmensseite zu versuchen, die Anzahl der möglichen Angebotsmodelle zu verringern und die Migration der Kunden zu neuen, vereinfachten Angeboten zu forcieren, um so die Gesamtkomplexität des Systems zu reduzieren. Dies kann natürlich für das Marketingteam schwer zu akzeptieren sein. 

Frontend-Architektur 

Entgegen Marketingbehauptungen ist es schwer, eine E-Commerce-Lösung auf dem Markt zu finden, die fertige, sofort einsatzbereite Schnittstellen für alle Verkaufskanäle auf integrierte Weise bietet. Die meisten der bestehenden Lösungen zielen tatsächlich auf das eine oder andere ab und erfordern einen großen Anpassungsaufwand. Bei der Entwicklung einer
gemeinsamen Frontend-Architektur sollte berücksichtigt werden, inwieweit sich die Schnittstellen der mitarbeiterorientierten Kanäle wie POS, Call Center und Kunden (eSHOP) ähneln werden. 

Intelligentes Komponentendesign 

Um eine zentrale Plattform zu schaffen, die zahlreiche Prozesse unterstützt, begannen wir mit der Identifizierung von Teilen der Customer Journeys, die allen Kanälen gemeinsam sind - zum Beispiel sind die Produktsuche, die Warenkörbe oder das Sammeln von Einwilligungen an allen Touchpoints nahezu identisch. Im nächsten Schritt haben wir die neuen Flows um diese Interaktionspunkte herum entworfen. Das Ziel war es, wiederverwendbare Interaktionsteile zu kreieren, die für einen Kunden konsistent sind und gleichzeitig die Flexibilität ermöglichen, spezifische Formen und Aktionen zu haben, die für jede Produktlinie
erforderlich sind. 

Am Anfang mag die Idee, gemeinsame Elemente überall wiederzuverwenden und eine gemeinsame Codebasis für das Frontend zu verwenden, vernünftig erscheinen. Es stellt sich jedoch heraus, dass sich die kundenorientierten Touchpoints viel schneller ändern als die verkaufsorientierten, was einen etwas anderen und ausgewogeneren Ansatz erfordert. Langfristig ist es besser, die Entwicklung dieser Touchpoints getrennt zu behandeln und vom Headless-Ansatz zu profitieren, der eine bessere, saubere und getrennte Entwicklung der Frontends ermöglicht, obwohl sie immer noch auf einer gemeinsamen zugrunde liegenden API basieren. 

Für eine echte Omnichannel-Handelsplattform ist ein gut durchdachtes API-Design von entscheidender Bedeutung, das dann von zukünftigen Verkaufs- und Self-Service Schnittstellen wie mobilen Apps, Chat-Clients, Beschilderung, Sprache usw. wiederverwendet werden kann. Eine API, die auf Industriestandards wie TM Forum basiert, sollte verwendet werden - sie verringert nicht nur den Design- und Integrationsaufwand, sondern bietet auch eine gute Architekturgrundlage. 

UX-Design skalieren 

Allzu oft muss mit der Entwicklung gewartet werden, bis das gesamte UX-Design fertiggestellt, überprüft und genehmigt ist, oder das erstellte UX-Design ist technisch nicht machbar, nicht performant oder entspricht nicht den gesetzlichen Vorschriften oder den Anforderungen der Barrierefreiheit. Bei Großprojekten (mit mehr als tausend Wireframes) ist ein systematischer Ansatz erforderlich, da die schiere Komplexität, der Umfang und die Kommunikationsprobleme das gesamte Projekt zum Scheitern bringen können. Der rein agile Ansatz, bei dem jeder Kanal separat von einem kleinen Team entwickelt wird, wird sich in der Praxis ebenfalls als schwierig erweisen, da eine solche schrittweise Entwicklung bedeuten würde, dass jeder Kanal völlig anders wird, ohne dass die Kosten gesenkt werden. 

Um den Designprozess zu rationalisieren, begann das Team in unserem Fall mit einer Vereinbarung über die wichtigsten Annahmen und Designregeln, aus denen sich ein weiteres detailliertes Systemdesign ergibt, damit parallele Implementierungsarbeiten beginnen können, ohne befürchten zu müssen, später Änderungen vorzunehmen. Das erste Designprodukt war ein Prototyp ausgewählter Omnichannel-Flows, der ausgiebig mit Nutzern verifiziert wurde. 

In einem nächsten Schritt wurden die Interaktionen für Produktlinien über alle Kanäle und Prozesse hinweg analysiert, um ein flexibles Designsystem auf der Grundlage wiederverwendbarer atomarer Komponenten zu erstellen. Dies reduzierte den Implementierungsaufwand, sorgte für eine einheitliche User Experience über alle Touchpoints hinweg und ermöglichte dennoch individuelle Markenunterschiede. Die Herausforderung bestand darin, eine einheitliche visuelle Sprache zu entwickeln, da ein Kunde mehrere verschiedene Artikel - ein mobiles Handset mit Versicherung, ein Internetabonnement oder einen Energietarif - in einem Warenkorb bestellen konnte, während ihm die Vorteile eines solchen Pakets präsentiert wurden. Solche Produkte mussten im Auftragserfassungsprozess einheitlich präsentiert werden. 

Meiner Meinung nach ist es bei solch großen Projekten entscheidend, das Kerndesignteam nicht zu groß zu halten und Experten einzubeziehen, die über ein breiteres Kompetenzspektrum verfügen - die sowohl das technische System kennen als auch die CX- und Telco-Geschäftsaspekte verstehen. Das Wissen in mehreren Bereichen – wie
Telekommunikationsangebote, rechtliche Aspekte des E-Commerce und Einhaltung der Barrierefreiheit – führt direkt zu einer besseren Produktqualität und einem schnelleren Fortschritt mit weniger Aufwand für den Wissenstransfer. Es ist immer besser, ein Designteam zu vermeiden, das von den Liefer- und Produktkonfigurationsteams getrennt ist - dies führt zu Missverständnissen und kostspieligen Fehlern, bei denen Ideen, die auf Wireframes großartig schienen, später überarbeitet und neu entworfen werden müssen, da sie für die Endnutzer zu komplex werden, um sie zu verstehen oder zu managen. 

Nicht zuletzt ist ein wichtiger Erfolgsfaktor der erfahrene Produktmanager, der in erster Linie motiviert ist, eine funktionierende E-Commerce-Lösung zu liefern. Er muss bereit sein, die Tatsache zu akzeptieren, dass die erste Iteration der Produktsuche möglicherweise
unvollständig ist und eine schrittweise Umsetzung erfordert, anstatt um jeden Preis auf alle möglichen Optionen zu drängen, die zu Beginn des Systems verfügbar sind. 

Zum Schluss 

Die Entwicklung einer echten Omnichannel-Plattformin der Telekommunikation erfordert einen erheblichen Aufwand durch ein erfahrenes, interdisziplinäres Team. Die Vorteile können enorm sein, aber es ist eigentlich ziemlich schwierig, alle Aspekte von Anfang an richtig hinzubekommen. Deshalb ist es besser, Veränderungen zu erwarten und zu akzeptieren, als an der ursprünglichen Vision festzuhalten. Das Erreichen eines großartigen Customer- und Employee Experience erfordert harte Entscheidungen von verschiedenen Geschäftsinteressenten, da es sich nicht nur um eine weitere IT-Systemimplementierung handelt, sondern um eine Geschäftsumwandlung, bei der die tatsächlich verwendete Technologie im Vergleich zu den Designentscheidungen eine untergeordnete Rolle spielt.