Herstellung von Omnikanalfähigkeit (Omni-Channel-Kommunikation) – Teil II: Komplikationen

Im vorherigen Beitrag zum Thema Omni-Channel wurde die Notwendigkeit einer Omni-Channel-Kommunikation für Unternehmen im aktuellen Wettbewerbsmarkt dargelegt. Wie bereits erwähnt, sind hierfür grundlegende Veränderungen in der Unternehmensarchitektur äußerst schwierig erfolgreich durchzuführen.

In diesem Beitrag untersuchen wir häufige Komplikationen bei der Umsetzung einer Omni-Channel-Strategie. Im nächsten Beitrag werden diese Herausforderungen mit einschlägigen Richtlinien und Tipps behandelt.

Umfangsüberlauf (Scope overflow)

Die meisten bedeutsamen Veränderungen erfordern oder ergeben sich aus der grundlegenden Umstrukturierung bestehender Organisationsstrukturen und -prozesse. Um ein Unternehmen Omni-Channel-fähig zu machen, sind oft nicht nur Änderungen an der aktuellen Tool-Landschaft, sondern auch an Organisationsstrukturen, Rollen und Verantwortlichkeiten erforderlich.

Das bedeutet, dass sowohl die technische als auch die geschäftliche Ebene einer Unternehmensarchitektur eventuell angepasst werden müssen. Eine konsistente und homogene Anpassung der IT-Landschaft und der begleitenden Prozesse zur Ermöglichung der Omni-Channel-Kommunikation erfordert Expertise in Technologie, Business, Organisation und Menschen (Anwender) und ist i. d. R. eher eine Kunst als eine Wissenschaft.

Jedes System, das mit der Bearbeitung eingehender Anfragen, deren Verarbeitung und dem Versand des entsprechenden Outputs zu tun hat, ist auf dem Weg zur Omni-Channel-Realität unweigerlich Analysen und dazu möglicherweise grundlegenden Veränderungen zu unterwerfen. Zu den betroffenen Bereichen gehören die physische Input/Output-Verwaltung (Post, Fax usw.), das Workflow-/Aufgabenmanagement (Aufgaben-Pipeline), die Terminplanung, das Customer Relationship Management (CRM), die automatische Anrufverteilung (Automatic Call Distribution, ACD), das Skill-Management, das Ressourcen- und Kapazitätsmanagement, die SLA[1] -Konfiguration und -Überwachung, das E-Mail-Gateway, das/die Data Warehouse(s) und BI-Systeme, das Knowledge Repository und die Unternehmens-Webseite.

Abbildung 1 zeigt die gängigen einschlägigen Systeme bezüglich einer Omni-Channel-Lösung.

Abbildung 1 Omni-Channel-relevante Systeme und Module innerhalb einer IT-Landschaft

Über den Umfang einer Rundumlösung sollte daher sorgfältig entschieden werden.

Viele Funktionalitäten können von bestehenden Systemen auf die eine oder andere Weise angeboten werden. Dazu gehören Video-Chat, Terminmanagement, Personal- und Kapazitätsplanung, Kompetenzmanagement, Weiterleitung und Zuweisung von Anfragen (Routing), Berichterstattung, Überwachung und Pipeline (Aufgabenmanagement). Jeder dieser Bereiche kann eine (interne) Out-of-the-box-Funktion einer Omni-Channel-Plattform sein, oder er kann jeweils in einem separaten System behandelt werden, das entsprechend in die bestehende Plattform integriert werden sollte. Beispielsweise kann ein Terminverwaltungssystem, das von der Verkaufsabteilung verwendet wird, ein anderes sein als das, das die Systemagenten oder der Second-Level-Support zur Verwaltung von Terminen verwenden. Diese Redundanzen müssen bei Bedarf behoben werden, was den Umfang des Omni-Channel-Programms erweitern kann.

Die Entscheidung, welche Kanäle die Kernfunktionen einer Omni-Channel-Lösung sein sollten und welche nahtlos integriert werden können, ist nicht ganz so trivial zu treffen. Sie hängt von verschiedenen zusammenhängenden Faktoren ab, darunter die spezifischen Anforderungen an die Kanäle, Lizenzmodelle, technische Einschränkungen (z. B. Netzwerkgeschwindigkeit) und die allgemeine Reife der Hauptplattform. Schließlich hängt es auch davon ab, wie sehr die Entscheidungsträger bereit sind, sich von einem „laufenden“ System zu verabschieden und wie tief ein chirurgischer Eingriff in die Unternehmensarchitektur möglich und erwünscht ist.

Eines ist jedoch sicher: In der Anfangsphase einer Omni-Channel-Initiative sollten diese Fragen beantwortet werden, so dass der Umfang relativ klar und begrenzt ist und die Verantwortlichkeiten und Interdependenzen transparent dargelegt werden. Das Ignorieren dieser – manchmal unbequemen – Fragen führt nur zu weiteren Komplikationen in der Zukunft.

Bewegliche Ziele

In großen Organisationen gibt es immer viele große und unternehmensweite Projekte und Dutzende von kleineren Projekten, die parallel zur Omni-Channel-Initiative laufen. Öfter sind einige dieser Projekte relevant für die Zielarchitektur, die eine Omni-Channel-Kommunikation ermöglichen soll.

Beispielsweise könnte ein Unternehmen planen, innerhalb von zwei Jahren auf Office 365 umzusteigen, auf ein neues CRM- oder OCR[2] -System zu migrieren oder die Webseite auf eine neue Plattform umzustellen. All diese Systeme haben einen direkten Einfluss auf die gewünschte Zielarchitektur und die Fähigkeitsmatrix, auch wenn sie noch nicht verwirklicht sind.

Solche beweglichen Ziele, insbesondere in großen Organisationen, können das Anforderungs- und Architekturdesign noch mühsamer machen. Deshalb sollten in den frühen Phasen diese relevanten Projekte und Pläne identifiziert und untersucht werden, um zukünftige Konflikte zu vermeiden.

In einigen Fällen kann es sich als notwendig erweisen, die Definition einiger Projekte abzubrechen oder radikal zu ändern, wenn sie im Widerspruch zu der geplanten Zielarchitektur stehen. Wenn zum Beispiel die ausgewählte Omni-Kanal-Lösung bereits über eine kompetente OCR-Funktion verfügt, kann ein Projekt, das die bestehende OCR durch ein neues System ersetzen soll, einfach aufgelöst oder in das Omni-Kanal-Programm integriert werden.

Viel zu viele Optionen

Die Auswahl einer Lösung (eine Kombination von Systemen), die zu einer komplexen Landschaft hinzugefügt werden soll, ist an sich schon eine mühsame Aufgabe. Es gibt eine ganze Reihe technischer und rechtlicher Anforderungen, die es zu beachten gilt, ganz zu schweigen davon, dass auf dem Markt Hunderte verschiedener Lösungen existieren können, von denen jede einige verlockende Eigenschaften verspricht.

Es erfordert Sachkenntnis und Einsicht, um über die Fassade dekorierter Software hinauszusehen und zu erkennen, wie technologisch solide, stabil, leicht anzupassen und benutzerfreundlich sie ist und wie gut sie die gesammelten Anforderungen erfüllt. Die Abbildung von Omni-Kanal-Anforderungen und Anwendungsfällen auf die Merkmale und Fähigkeiten eines Systems oder einer Plattform kann recht kompliziert werden.

Darüber hinaus sind Skalierbarkeit und Flexibilität wichtige Merkmale einer modernen IT-Landschaft. Eine moderne Lösung zur Unterstützung der Omni-Kanal-Kommunikation sollte sofort einsetzbare Dienste zusammen mit Konnektoren und APIs für die Interaktion und den Betrieb mit anderen Systemen oder Modulen bieten. So kann es beispielsweise sinnvoll sein, den Betrieb einschließlich OCR[2] , Anforderungsklassifizierung, Kapazitätsmanagement und Routing an ein externes System auszulagern, das sich auf einer Cloud-Plattform befinden kann. Eine moderne Lösung sollte nicht nur webbasiert und browserübergreifend (cross-browser) sein, sondern auch auf einer Plug-and-Play-Architektur mit flexiblen APIs und Konnektoren basieren, um die Interoperabilität mit jedem anderen System zu erleichtern und zu maximieren.

Darüber hinaus sollte das Lizenzmodell eines Systems im Rahmen des Auswahlsprozesses berücksichtigt werden. Eine flexible Lizenzierung ist von größter Bedeutung, insbesondere für eine Omni-Channel-Lösung, die oft verschiedene Arten von Benutzern mit unterschiedlichen Aktivitätsebenen hat. Ein starres Lizenzmodell führt zu enormen Kosten. Diese Kosten können durch unnötig hohe Lizenzgebühren oder durch fragwürdige Workarounds entstehen, wenn nicht jede relevante Rolle als Nutzer in das System aufgenommen werden kann. So oder so, ein flexibles Lizenzmodell ist ein wesentlicher Bestandteil einer modernen Lösung.

Abbildung 2 zeigt eine Zusammenfassung der gemeinsamen Erwartungen an eine gewünschte Lösung.

Abbildung 2 Allgemeine Erwartungen an eine Omni-Channel-Lösung

Dazu ist zu beachten, dass moderne und zukunftsorientierte Tools zusätzliche Mehrwerte bieten, darunter die sogenannte Low-code-Entwicklung, Berichterstattung in Echtzeit und saubere und ausgefeilte APIs, die sich gut in andere Systeme integrieren lassen. Um den richtigen Satz von Werkzeugen zu finden, ist zwangsläufig eine umfassende Untersuchung der prozessbezogenen Anforderungen, der organisatorischen Hürden, der Unternehmensarchitektur, der Technologietrends und schließlich ein methodischer Ansatz für die Marktanalyse zur Bewertung der identifizierten Lösungen erforderlich.

Legacy-Anwendungen

Die Auswahl eines Systems stellt natürlich eine große Herausforderung dar. Dennoch ist es ebenso wichtig, das ausgewählte System effektiv und mit minimalen Kosten zu integrieren und die bestehende Fähigkeitsmatrix (Capability Map od. Matrix) neu anzupassen (Verschiebung von Funktionalitäten von einem System in ein anderes).

Eine Unternehmensarchitektur sollte dynamisch, transparent und erweiterbar sein, wenn sie mit neuen Technologien oder Geschäftsmöglichkeiten konfrontiert wird. Nur so kann man die Integrität und Skalierbarkeit eines Systems sicherstellen. Das Aufzwingen einer Lösung um der Omni-Channel-Kommunikation willen in einer komplexen IT-Landschaft erfordert nicht nur Änderungen der bestehenden Schnittstellen und des Datenflusses, sondern auch eine anfängliche Bereinigung und Austausch der alten Systeme und Schnittstellen.

Solche veralteten und benutzerunfreundlichen Systeme haben sich i. d. R. ad hoc entwickelt, oft ohne eine zentrale Vision und einen Fahrplan. Viele von ihnen sind daher nicht nahtlos miteinander integriert. Veraltete Werkzeuge bieten zwar umfangreiche Funktionen. Dennoch: Wenn es um eine einfache Integration oder eine einfache Anpassung geht, scheitern sie kläglich. Lösungen wie z. B. Genesys, LotusNotes oder SAP neigen manchmal dazu, solche Probleme aufzuzeigen. Einen großen Marktanteil zu haben, weil etwas vor ein oder zwei Jahrzehnten noch gut war, ist nicht unbedingt gleichbedeutend mit einer modernen, skalierbaren und benutzerfreundlichen Technologie; manchmal ist leider genau das Gegenteil der Fall. Aus diesem Grund geben Ihnen bestimmte Analysten wie Gartner vielleicht einen Einblick in die „Big-Players“ auf dem Markt, aber sie enthalten oft weder hoch entwickelte Lösungen, die gerade erst auf dem Vormarsch sind, noch sagen sie Ihnen, wie veraltet und daher kostspielig die zugrunde liegende Technologie sein könnte.

Hier sind einige Symptome eines ineffektiven und überholten Systems:

• ein Veröffentlichungsintervall von mehr als einem Monat für neue Versionen,
• Existenz von Desktop-Anwendungen,
• im Jahr 2020 nicht browserübergreifend[3]  zu sein, und
• lokale Verwaltung der Benutzer (anstatt dass alle Benutzer aller Systeme von einem zentralen Benutzer-Repository aus synchronisiert werden).

Als Faustregel gilt: Wenn Sie ein wichtiges System in Ihrer IT-Landschaft haben, das eines oder mehrere der oben genannten Symptome aufweist, sollten Sie ernsthaft in Erwägung ziehen, es außer Betrieb zu nehmen und zu ersetzen. Die versteckten Kosten für ihre Entwicklung, ihren Betrieb und/oder ihre Wartung sind einfach zu hoch. Es gibt heutzutage zahlreiche Low-Code-Systeme für jede Domäne auf dem Markt, die Desktop-Anwendungen und Silo-orientierte IT-Landschaften glücklicherweise der Vergangenheit angehören lassen. Unternehmen, die solche Systeme auch im dritten Jahrzehnt des 21. Jahrhunderts noch tolerieren, werden sich bald auf dem heutigen wettbewerbsintensiven Markt in einer schwierigen Situation befinden.

Lobby-Widerstand

Bei der Einführung eines neuen Systems sollte zudem die Lobbymacht der Vertreter/Verkäufer bestehender Altsysteme nicht unterschätzt werden.

Kritische Systeme in großen Unternehmen bringen Millionen von Euro an Einnahmen in den Bereichen Lizenzierung, Beratung, Weiterentwicklung und Wartung. Die Stilllegung dieser Anwendungen ist nicht nur eine technische und organisatorische Herausforderung, sondern manchmal auch ein politischer Kampf mit den Vertretern der abzulösenden Systeme. Wo Geld im Spiel ist, sollten die Augen vor möglichen Interessenkonflikten offen sein. Selbst Organisationen in entwickelten oder demokratischen Ländern sind nicht immun gegen den finanziellen Einfluss von Lobbyisten in Unternehmen.

Wenn die Programmleitung der Meinung ist, dass die Vertreter einer bestehenden Lösung einen gewissen Einfluss auf die Entscheidungsträger haben, sollten die Bewertungskriterien und die entsprechenden Vorschläge tadellos formuliert werden. Im nächsten Beitrag werden Ihnen ausführlichere Richtlinien an die Hand gegeben, die Ihnen helfen sollen, dieses Problem mit minimalen Reibungsverlusten handzuhaben und anzugehen.

Lokale Mentalität

Eines der Grundprinzipien einer großen Vision für die Omni-Kanal-Kommunikation ist die Konzeption aller Prozesse mit einer End-to-End-Mentalität, damit die Aktivitäten einheitlich gesteuert und ganzheitlich betrachtet und ausgewertet werden. Dieses „Prozess-Reengineering“ sollte sowohl vor als auch nach der Auswahl einer Lösung durchgeführt werden.

Lokale Mentalität bedeutet, dass Organisationseinheiten (z. B. Abteilungen, Teams, Bereiche, usw.) dazu neigen, bestehende Abläufe aus ihrer eigenen Perspektive zu sehen, anstatt sie als Teil eines größeren Ganzen zu betrachten. Dies ist eines der Hauptprobleme bei der Planung von Customer Journeys. End-to-End-Prozessmanagement bedeutet, dass jeder Prozess mit einem eindeutigen Auslöser beginnt (z. B. wenn ein Kunde eine Anfrage sendet) und mit einem eindeutigen Abschluss endet (z. B. wenn der Kunde ein angefordertes Dokument erhält). Alles, was dazwischen geschieht, sollte als unvollständiger Teil der gesamten Reise betrachtet werden. Diese Art der umfassenden Betrachtung ist dann für die Kommunikation über alle Kanäle notwendig.

Die Neukonzipierung erfordert oft, dass viele Abteilungen die Art und Weise ändern, wie sie die Kommunikationskanäle mit den Kunden nutzen und wie sie ihre Anfragen steuern. Viele von ihnen werden möglicherweise zusammengelegt oder mit neuen Aufgaben und Rollen betraut. Viele kleinere Systeme müssen möglicherweise aufgelöst werden, und neue Verantwortlichkeiten und Verfahren können als notwendig erachtet werden.

Dies ist eine gewaltige Veränderung, insbesondere für große Organisationen, und erfordert ein aufschlussreiches und zielgerichtetes Änderungsmanagement, das von der Führungskraft nachdrücklich unterstützt werden muss.

Starre Organisationsstruktur und lokale Politik

Selbst wenn wir nach ausführlicher Analyse und rigorosem Design festlegen, was auf organisatorischer Ebene geändert werden muss, um z. B. ein End-to-End-Prozessmanagement zu ermöglichen oder ein System zu integrieren, ist das Spiel noch nicht vorbei. Die Planung der Veränderung etablierter Organisationsstrukturen und die Anpassung neuer Rollen und Verantwortlichkeiten sowie die Schulung des Personals zum Erwerb neuer Kompetenzen ist eine weitere beträchtliche Herausforderung, auf die es sich vorzubereiten gilt.

Auf Veränderungen wird oft mit Widerstand und Misstrauen reagiert, und das ist völlig normal. Die Argumente für Veränderungen sollten transparent und häufig dargelegt werden, so dass alle Interessengruppen und Nutzer mit an Bord sind.

Denken Sie aber immer daran: Niemand mag eine veraltete Anwendung, die ihre Benutzer ständig enttäuscht und Irritationen verursacht sowie Zeit und Nerven kostet. Zwar wird das von Ihnen ausgewählte System dann möglicherweise von bestimmten Abteilungen wie Kundendienst, Marketing oder Vertrieb begrüßt. Dennoch sind die Benutzer nicht die einzigen Beteiligten. Abteilungsleiter, Entscheidungsträger und Betriebsrat sind ebenso wichtig. Besonders der Betriebsrat sollte vorsichtig und klug gehandhabt werden, was uns zum letzten Abschnitt bringt.

Die mächtige Betriebsrat

Gewerkschaften an sich sind eine großartige Institution. In einem hochgradig kapitalistischen Markt, der dazu neigt, Arbeitnehmer zu ignorieren oder zu unterschätzen und sich ausschließlich auf Aktienkurse, Einnahmen und Gewinn zu konzentrieren, können die Gewerkschaften ein Korrektiv sein, das Entscheidungen trifft, die sowohl für die Unternehmen als auch für die Arbeitnehmer (Arbeiter) von Nutzen wären. Trotzdem besteht bei Gewerkschaften immer ein gewisser Risikofaktor, wenn es um Innovationen und neue Technologien geht.

In bestimmten Ländern, darunter auch in Deutschland, haben die Gewerkschaften erheblich an Macht gewonnen, wenn es darum geht, in Innovationsinitiativen einzugreifen und mitzubestimmen. Geht man davon aus, dass all diese Bemühungen auf guten Absichten beruhen, so ist eine Spannung unvermeidlich. Moderne Technologien können einer Organisation in einigen Fällen helfen, bestimmte Prozesse zu automatisieren oder den Zeit- und Arbeitsaufwand für bestimmte Verfahren zu reduzieren. In einer perfekten Welt ist eine Organisation dafür verantwortlich, neue Aktivitäten für diejenigen Mitarbeiter zu finden, deren tägliche Arbeit von einer neuen Lösung oder einem neuen Ansatz betroffen ist. Da ein solcher Plan nicht garantiert werden kann oder seine Umsetzung aufgrund des tief verwurzelten Misstrauens zwischen Interessenvertretern und Gewerkschaftsmitgliedern unsicher wäre, neigen die Gewerkschaften dazu, eine Innovation abzuschalten und zu blockieren, anstatt sie zuzulassen und bei der Abfederung der Auswirkungen zu helfen.

Aus diesem Grund muss eine innovationslastige Initiative wie die Einführung einer Omni-Kanal-Strategie sorgfältig mit der Gewerkschaft diskutiert werden. Ein Kompromiss kann immer erreicht werden, solange sich beide Parteien einig sind, dass die Interessen der Arbeitnehmer nicht zugunsten von mehr Profit geopfert werden dürfen.

Umgang mit immenser Komplexität

Wenn man alle oben aufgeführten Komplikationen zusammenfasst, wird klar, dass die Ermöglichung der Omni-Channel-Kommunikation ein komplexes Programm mit vielen Abhängigkeiten und verschiedenen Dimensionen von Aktivitäten (technisch, organisatorisch usw.) ist. Ein solches Programm erfordert einen geeigneten Fundus an Wissen, um Anforderungen und Designkonzepte im Hinblick auf alle relevanten Benutzer, Systeme und Geschäftssegmente gemeinsam zu sammeln, zu formulieren und auszutauschen. Darüber hinaus gibt es viele Aktivitäten, Meilensteine und Ergebnisse, die durchgeführt werden müssen. Diese Aktivitäten reichen von der Definition von Anforderungen und Auswahlkriterien für eine neue Lösung bis hin zum Entwurf verschiedener Konzepte, der Implementierung von Änderungsanforderungen in relevanten Systemen, der Genehmigung der Ergebnisse usw. Dies sind keineswegs triviale und beschränkte To-dos, die man mit Excel oder SharePoint handeln könnte.

Darüber hinaus erfordert die Ermittlung des Status quo und der Entwurf einer soliden Zielarchitektur ein geeignetes EAM-(Enterprise Architecture Management-)Tool. Ein EAM-Tool hilft bei der effizienten Generierung und Anzeige verschiedener Schichten, insbesondere der Geschäfts- und Technologieschichten im Hinblick auf die Entwurfsarchitektur. All dies erfordert moderne Lösungen für PMO [4] und EAM, um Informationen (Wissen) zu verwalten, die Architektur zu dokumentieren und die Aktivitäten effizient und transparent zu steuern.

—————————————

Abbildung 3 zeigt einen Überblick über die gemeinsamen technischen, organisatorischen und politischen Herausforderungen, wenn es darum geht, eine Omni-Kanal-Strategie zu verfolgen.

Abbildung 3 Allgemeine Herausforderungen/Komplikationen bei der Annahme/Implementierung einer Omni-Kanal-Strategie

Im nächsten Beitrag werden Ihnen anwendbare Richtlinien und Tipps an die Hand gegeben, um diesen Herausforderungen zu begegnen und hoffentlich die Risiken und Kosten einer Omni-Channel-Einführung zu reduzieren.

——————————————————————————————-

[1] Service Layer Agreement

[2] OCR-Systeme (Optical Character Recognition) wandeln Bilder von Dokumenten (z. B. empfangene Faxdokumente oder Mails) in Text um, um die Lesbarkeit und automatische Klassifizierung zu ermöglichen.

[3] Cross-Browser bedeutet, dass die Web-Anwendung Browser-agnostisch ist (kann auf allen gängigen Browsern ausgeführt werden und von diesen angesprochen werden)..

[4] Project Management Office