Trends: Das müssen B2C-Shopsysteme der Zukunft leisten

Handel ohne Onlinestrategie ist heute kaum noch denkbar. Die ganz wilden Tage des Onlinehandels, in denen gefühlt jeden zweiten Tag ein Category Killer startete, ein Handelsgigant seine Omnichannel-Strategie verkündete oder ein Start-up gleich eine ganze Produktkategorie aufschließen wollte, mögen vorüber sein. Abseits der spektakulären Hypes legt der Onlinehandel aber weiterhin kräftig zu. Um durchschnittlich 13 Prozent soll der Onlinehandel weiterhin pro Jahr wachsen, schätzt die Unternehmensberatung Arthur D. Little   und der Internetverband Eco    in der Studie Die deutsche Internetwirtschaft 2015-2019   . 2019 soll dann erstmals die Marke von 70 Milliarden Euro Umsatz durchbrochen werden.

Und auch die Investitionsbereitschaft der Händler ist ungebrochen: In einer iBusiness-Umfrage (siehe In welche Geschäftsfelder Shopbetreiber 2017 investieren) haben über die Hälfte der befragten Onlineshops (52 Prozent) jüngst angegeben, dass sie 2017 ihre Investitionen im Vergleich zum Vorjahr steigern wollen. Etwas weniger - 40 Prozent - wollen 2017 ihre Investitionen auf dem gleichen Niveau wie im vergangenen Jahr belassen. Und nur eine Minderheit von acht Prozent der Shopbetreiber rechnet für dieses Jahr mit rückläufigen Investitionen (siehe Chart).

Neben Marketing und dem Sortiment bilden dabei die Investitionen rund um IT-, Shopsysteme, Prozessmanagement und Shop-Usability einen Schwerpunkt unter den befragten Onlinehändlern.

Das sind die Herausforderungen für Onlineshops

Geändert haben sich in den vergangenen Monaten allerdings die Herausforderungen, vor denen Onlinehändler stehen. Nach einer euphorischen Aufbruchsphase müssen sich die Investitionen nun in der Realität beweisen. Nachdem vor zwei bis drei Jahren die Herausforderung des Handels darin bestand, den Schwenk in den Onlinehandel zu vollziehen oder überhaupt zu starten, sind die Unternehmen nun im Alltag angekommen. Es geht darum, die Neuausrichtung zu verwirklichen und auszubauen. Die großen Herausforderungen des Handels sind:

• Marketing: Der Onlinehandel ist gereift und hat sich weiter professionalisiert. Viele Unternehmen haben in Marketing-Tools investiert und sind in der Lage, auf den Kunden zugeschnittene Kampagnen zu fahren. In dieser Situation steigen die Ansprüche an den Onlineshop. Eine einfach zu bedienende Schnittstelle oder bereits integrierte Marketing-Logik wird zu einer zentralen Herausforderung. Die Richtung weisen Systeme wie SAP Hybris    oder Salesforce   / Demandware   , die an einer nahtlosen Verknüpfung von ECommerce-Lösung und Marketing-Suite arbeiten.
  
• Kundenbindung: Händler sind darauf angewiesen, mit ihren Kunden zu wachsen und die bestehende Kundenbindung zu intensivieren. Nachdem im Onlinehandel eine ganze Weile lang expansives Wachstum durch Erschließung neuer Märkte, Preisaggressivität und der damit verbundenen Neukundengewinnung im Vordergrund stand, geht es inzwischen darum, bestehende Potenziale besser auszuschöpfen, das Kundenerlebnis zu verbessern. Grundlage ist ein reibungsloser Ablauf aller grundlegenden Prozesse wie Order Management, Fulfillment, Logistik, Payment. Nachdem dies bei vielen Händlern inzwischen geübte Praxis ist, werden Kundenbindungsmaßnahmen zu den wichtigsten Aufgaben.
  
• Agilität: Die Innovationsgeschwindigkeit ist nach wie vor ungebrochen, der Onlinehandel noch lange nicht ausentwickelt. Wie hoch das Tempo ist, haben in der jüngsten Vergangenheit Themen wie Mobile, Programmatic Advertising oder Social Networks gezeigt. Künstliche Intelligenz (KI), Sprachassistenten, Chat-Bots und Messenger sowie Internet-of-Things (IoT) sind die derzeitigen Trends, die den (Online-)Handel bestimmen. Neue Trends lösen dabei keineswegs alte ab, die Anforderungen an Händler werden also komplexer. Sie müssen nicht einfach nur andere, sondern vielfältigere Berührungspunkte mit ihren Kunden abbilden. Vor diesem Hintergrund ist es entscheidend, auf eine agil entwickelbare ECommerce-Plattform zu setzen.

Händler sind gezwungen, tiefer in die Materie einzusteigen, gründliche Analysen vorzunehmen, längere und komplexere Customer Journeys zu verstehen. Diese Anforderung zwingt Hersteller von Shopsoftware dazu, neue Kapazitäten sowohl im Backend (Fulfillment und Integration) als auch im Frontend (nahtlose und innovative Customer Journeys) anzubieten. Dazu müssen die Systeme dafür taugen, sich an die hohe Geschwindigkeit in der Online-Evolution anzupassen.

Eine zukunftsfähige Plattform muss sich flexibel in eine bestehende oder kommende IT-Umgebung einfügen können. Einerseits verfügen viele Händler - gerade im Omnichannel-Handel - über gewachsene Legacy-Systeme. Im Sinne eines nahtlosen Kundenerlebnisses hat es sich als Irrweg erwiesen, den E-Commerce als Parallelprozess abzubilden. Im Gegenteil: Viele bestehende Prozesse müssen unter Berücksichtigung der Fähigkeiten des neuen Kanals neu modelliert werden. Dazu müssen bestehende Warenwirtschafts-, ERP-, Logistik- oder Bezahlprozesse nahtlos integrierbar sein. Das Thema ist so komplex, das iBusiness dieser Herausforderung eine eigene ausführliche Analyse gewidmet hat (siehe iBusiness: Zukunftsfähigkeit - Fünf Backend-Strategien für den E-Commerce).

Flexibles Szenario: Headless und Mircoservices

Zumindest für Shopbetreiber, die ihre ECommerce-Hausaufgaben bereits erledigt haben, gewinnt daher eine grundlegende Neuausrichtung der Software-Architektur an Bedeutung: Weg von monolithischen Einzelsystemen, hin zu einer hochflexiblen Architektur, in der die einzelnen Softwarekomponenten in möglichst kleine Einheiten zerlegt werden. Diese lassen sich über eine leistungsfähige API-Schnittstelle zu einer beliebig komplexen Anwendung verbinden. Zugleich können einzelne Funktionen schnell ausgetauscht oder weiterentwickelt werden, zu neuen Geschäftsvorfällen zusammengestellt und von kleinen Entwicklerteams betreut werden.

Diese Architektur findet derzeit unter dem Namen Microservices Verbreitung und wird unter anderem von Commercetools   , SAP Hybris oder Spryker   vorangetrieben. Es handelt sich dabei um die komplette Zerlegung einer (serverbasierten) Anwendung in ihre einzelnen Funktionen. Jedes einzelne Feature (etwa: Suche, Warenkorb, Navigation etc.) wird dabei als eigene Anwendung konzipiert, die über APIs kommuniziert. Ein typischer Microservice ist so klein und übersichtlich, dass er von einem überschaubaren Team (etwa fünf bis sechs Entwickler) und in einem kurzen Zeitraum (etwa einem Monat) komplett neu entwickelt werden kann.

Die Eigenständigkeit und Unabhängigkeit der einzelnen Microservices ist so hoch, dass sogar problemlos die Programmiersprache von Microservice zu Microservice gewechselt werden kann und die Anwendungen auf unabhängigen Systemen (natürlich auch als Service in der Cloud) laufen können. Weitere Vorteile:

• Microservices lassen sich unabhängig voneinander entwickeln, testen und live schalten. Dadurch wird Continuous Delivery möglich.
  
• Die Skalierbarkeit des Gesamtsystems gewinnt deutlich, da sich jeder Service unabhängig von anderen Services skalieren lässt.
  
• Die Architektur unterstützt die Arbeit in unabhängigen Teams, die sich flexibel auslagern lassen.
  
• Der geringe Entwicklungsaufwand erleichtert Experimente - sei es eine neue Sprache, ein neues Framework oder eine neue Funktion.
  
• Unbrauchbare Lösungen lassen sich jederzeit mit vertretbarem Aufwand durch eine Neuentwicklung ablösen, ohne dass der Betrieb leidet.
  
• Die klare API-Struktur erleichtert es, Applikationen und Services aus fremden IT-Systemen zu integrieren.

Die strategische Bedeutung einer solchen Architektur wird besonders deutlich, wenn der technologische Wandel einbezogen wird, der sich ringsherum vollzieht. Immer mehr Dienste und Geräte werden mit dem Internet vernetzt und müssen auf entsprechende Services zugreifen und benötigen einen möglichst niederschwelligen Zugang. Eine Microservice-Architektur ist für eine solche Integration prädestiniert, da sich an jeder Stelle des Geschäftsvorgangs eine beliebige Vernetzung via API realisieren lässt. Im Gegensatz dazu bleiben monolithische Systeme verschlossen und geben ein Ergebnis nur über die ursprünglich vorgesehene Schnittstelle aus - nicht selten ist das lediglich eine von einem Webserver ausgegebene, formatierte HTML-Seite.

In einer Microservice-Architektur lässt sich dagegen jede einzelne Funktion des Gesamtsystems jederzeit per Schnittstelle headless, also nahtlos und ohne überflüssigen Funktionsüberbau, ansprechen. Auf diese Weise bleibt das Gesamtsystem in vielerlei Hinsicht höchst flexibel:

• Distributed Computing. Eine Microservice-Architektur ermöglicht es, selbst Dienste anzubieten oder auf Drittdienstleistungen zuzugreifen. So kann etwa eine Fahrplanabfrage oder eine Recommendation-Engine per externem Microservice angeboten oder eingebunden werden, als wäre sie Bestandteil der eigenen Applikation.
  
  
• Internet der Dinge. Auf API-Ebene lassen sich Informationen aus einer Vielzahl von Quellen entnehmen. So können IoT-Geräte in die eigene Applikation eingebunden werden und eine Bestellung beispielsweise durch den Druck auf einen physischen Knopf - à la Dash Button - entgegennehmen. Sensoren aus vernetzten Maschinen, Smarthome-Geräten, Connected Cars oder Wearables können problemlos in die Applikation eingewoben werden.
  
  
• Headless-Service. Umgekehrt wird auch die Informationsbereitstellung und -aufbereitung getrennt. Ein Shopsystem kann den Lieferstatus beispielsweise über Microservice und API direkt aus seiner Datenbank an eine Smartwatch-Applikation ausliefern. So kann die Anfahrt des Lieferdienstes sogar kontinuierlich aktualisiert werden, ohne dass jedesmal ein Visit ausgelöst werden muss. Der Microservice stellt nur die Daten für das Frontend bereit, die Aufbereitung übernimmt die Applikation.
  
  
• Agenten-Schnittstelle. Auf dieselbe Weise lassen sich auch sehr leicht Schnittstellen schaffen, auf die Software-Agenten zugreifen können - sei es für eine Reiseplanung, das Kinoprogramm oder um die Bestellung einer Tintenpatrone zu platzieren. Der Austausch mittels API erfolgt dabei deutlich schneller und schlanker, als wenn ein Webinhalt geparst werden soll.
  
  
• Prozesslogik. Da mit Microservices ein Geschäftsvorgang optimalerweise ohnehin schon in seine einzelnen Prozessschritte zerlegt ist, können sehr einfach neue Geschäftsmodelle modelliert werden. Wenn ein Shopbetreiber beispielsweise ein Abo-Modell ausprobieren möchte, muss er die bestehenden Microservices nur neu gruppieren und nur sehr wenige (Aboverwaltung) neu programmieren. Auf diese Weise kann sehr flexibel auf neue Geschäftsvorfälle reagiert werden.

Die Auflistung zeigt, dass ein konsequenter Einsatz von Microservices nicht nur die Performance der Entwicklungsabteilung beschleunigt und die Time-to-Market verkürzt, sondern zusätzlich die Vernetzung von internen und externen Prozessen deutlich vereinfacht. Gerade in letzterer Eigenschaft liegt ein besonderer strategischer Vorteil. Sowohl auf der Backend- als auch auf der Frontend-Seite werden beide Fähigkeiten in naher Zukunft wichtiger. Im Frontend, weil die Gerätevielfalt der Kunden drastisch zunimmt. Die Fähigkeit von Microservices, Daten headless bereitzustellen, erleichtert die Integration neuer Plattformen erheblich. Auf der Backend-Seite zählen dagegen die Flexibilität bei der Verknüpfung und Umgestaltung von Anwendungen zu den großen Vorzügen.

Vier Händlerszenarien

Zusammenfassend lassen sich mindestens vier sehr verschiedene Händlertypen ausmachen, die jeweils grundverschiedene Anforderungen an die Shopsysteme haben und jeweils einer eigenen Systemlandschaft zugeneigt sein werden. Eine gute Entscheidungshilfe bei der System-Evaluierung kann daher darin liegen, zunächst sein eigenes Geschäftsmodell nach diesem Schema zu klassifizieren.

1. Typ Eigenentwickler:

Je stärker das Geschäft skaliert - entweder, weil der Händler mehrere Shops unter verschiedenen Marken betreiben will, ein sehr großes Volumen anstrebt oder gar einen Marktplatz betreiben will - desto näher liegt es, die Shoplösung selbst zu programmieren. Dasselbe gilt, wenn bereits eine aufwändige IT-Infrastruktur besteht und erhalten bleiben soll oder wenn der Händler ein sehr spezielles Geschäftsmodell verfolgt (beispielsweise Mass Customization). In allen anderen Fällen sollte man ein dickes Fragezeichen hinter diese Entscheidung setzen.

2. Typ Enterprise-Suite:

Je schneller der Händler dagegen mit einem ECommerce-Angebot auf den Markt kommen will, das aus dem Stand höchsten Ansprüchen genügen muss, desto eher wird er auf eine Standard-Lösung zurückgreifen. Selbst auf die Gefahr hin, dass durch die Integration in die bestehende IT-Infrastruktur höhere initiale Kosten oder (zunächst) Parallelprozesse entstehen. Da es sich dabei allerdings in den meisten Fällen um ein Übergangsszenario handeln dürfte, sollte bei der Kaufentscheidung bereits die weitere Entwicklung und Integration berücksichtigt werden.

3. Typ Modularlösung

Dieser Händlertyp befindet sich strategisch zwischen dem Eigenentwickler und der Enterprise-Suite und verfolgt einen Best-of-Breed-Ansatz oder verfügt bereits über eine starke Middleware, die nun um ECommerce-Funktionalität erweitert werden soll. Der Aufwand für eine solche Lösung dürfte sich knapp unterhalb einer Eigenentwicklung bewegen, weshalb ihn dieselben Motive treiben sollten. Dieser Typ ist gut beraten, seine Systeme intensiv in Richtung eines Microservice-Ansatzes weiterzuentwickeln. Die Gefahr ist groß, sonst in selbstgemachten Abhängigkeiten und Komplexitäten zu ersticken.

4. Typ Mittlere Shop-Software

Für Händler mit einfachem Geschäftsmodell und mittlerer Shopgröße sind Standardlösungen ebenfalls das Mittel der Wahl. Um die Abhängigkeit vom Hersteller zu minimieren, lohnt es sich ein Produkt mit breiter Entwicklergemeinde zu bevorzugen, das unter Umständen sogar als Open Source verfügbar ist. Händler dieses Typs sollten bei der Auswahl des Shopsystems insbesondere auf die Bedienbarkeit der Software achten. Sie soll den Händler insbesondere im Marketing schneller, flexibler und effizienter machen.