IT-Architektur: Diese Prozesse stellen die Weichen für den Shop-Erfolg

Beim Thema Digitale Transformation geht die Arbeit nicht aus. Landauf, landab sind Heerscharen von CDOs, CMOs und Digital-Berater damit beschäftigt, Unternehmen fit für die digitale Zukunft zu machen. Das Thema ist vielschichtig und komplex: Digitale Geschäftsmodelle wollen verstanden, Mitarbeiter mitgenommen, Unternehmensstrukturen aufgebrochen werden. Und immer stellt sich auch die Frage, wie die neuen Prozesse in der Unternehmens-IT umgesetzt werden können.

Letztere Frage mag in diesem Zusammenhang schon fast ein wenig nebensächlich klingen. Tatsächlich ist sie aber nicht zu unterschätzen. Nicht nur, weil für IT-Umstrukturierungen gerne beachtliche Investitionssummen in die Hand genommen werden müssen. Mehr noch, weil mangelhafte Prozesse in der IT ein erhebliches Bremsmoment entwickeln.

IT-Fehlentscheidungen können in der Praxis dramatische Ausmaße annehmen. In einem modernen Unternehmen sind schließlich alle geschäftskritischen Prozesse in der IT festgelegt - und damit auch der Service, den das Unternehmen bieten kann. Die IT ist der Beton, aus dem die Service-Leistungsfähigkeit eines Unternehmens gegossen ist. Extrem nützlich, wenn man ihn zu nutzen weiß. Aber äußerst schwierig zu entfernen, wenn er im Weg ist. Wie nutzlos es ist, gegen falsch angelegte IT-Prozesse anzuarbeiten, weiß jeder, der schon einmal an der Hotline einer Telefongesellschaft gescheitert ist.

Prozesse sind der Beton der Customer Experience

Eine funktionierende, agile und kostengünstige IT-Architektur ist daher ein wesentlicher Faktor der digitalen Transformation. Wenn Geschäftsmodelle umgewälzt werden, müssen schließlich auch die Prozesse neu gestaltet werden. Wie unterschiedlich die Anforderungen sind, die sich in der digitalen und traditionellen Geschäftslogik stellen, zeigt ein Vergleich im Handelsgeschäft. Kaum ein Geschäftsparameter bleibt gleich, wenn der Kanal gewechselt wird:

Kaufhaus versus Web-Shop: Die wichtigsten Geschäftsparameter
	Stationäres Kaufhaus	Online-Handel
Traffic / Besucher	Lage und Einzugsgebiet	SEO, Marketplaces
Kundenbeziehung	Anonym	Individuell
Werbung	Print, Plakat, Reichweitenmedien	Mail, SEA, PLA/AMS, (Re-)Targeting, One-to-One-Marketing
Kaufreiz	Produktverpackung	Artikeldaten, Artikelbild
Zahlung	Bar, Karte	Online-Payment, Rechnung
Artikelübergabe	Selfservice	Persönliche Lieferung
Lagerhaltung	Vor-Ort-Lager	Zentrallager

Die Auflistung ließe sich beliebig fortsetzten. Doch schon der kurze Vergleich zeigt, dass ein Verkaufsprozess, der für einen der beiden Kanäle gestaltet ist, unmöglich im anderen Kanal genutzt werden kann. Mehr noch: Die IT-Systeme des bestehenden Prozesses wären gar nicht in der Lage, die erforderlichen Daten des neuen Prozesses zu verarbeiten.

Da eine komplette Umgestaltung aufwändig ist, wird in der Praxis oft versucht, einen neuen Prozess behelfsweise anzuflanschen. Ein Online-Shop wird dann in der Zentrallogistik einfach als neue Filiale geführt. Oder eine Click-&-Collect-Lösung wird umgesetzt, indem die Filialen in der Online-Logistik als Endkunden-Adresse geführt werden. Mit verheerenden Ergebnissen:

• Home-Delivery: Ist ein Produkt in der Filiale vor Ort nicht vorrätig, können Händler es dem Kunden nicht nach Hause liefern. Schließlich ist der Web-Shop als eigene Filiale abgebildet. Bezahlung, Verbuchung des Umsatzes, Lieferung und Retoure müssen dort abgewickelt werden.
  
• Click-&-Collect: Bei mancher Lösung namhafter Warenhäuser werden die Produkte per Post(!) an die gewünschte Filiale geschickt, wenn sie dort nicht vorrätig sind. Dort kann sie der Kunde abholen - bezahlen musste er sie aber im Online-Shop. Bei Nicht-Gefallen kann der Artikel auch nicht einfach ins Regal gelegt werden. Im Hintergrund wird ein kompletter Retouren-Prozess abgewickelt. Letztlich fungiert die Filiale lediglich als Paketshop mit Umkleidekabine.

Unterschiedliche Ausgangssituationen

Die allermeisten Prozessfehler sind für den Kunden zwar weniger sichtbar als die genannten Beispiele, für das Unternehmen aber nicht weniger schmerzlich. Sie resultieren in:

• Mehrarbeit für Mitarbeiter (weil Daten manuell übertragen werden),
  
• Mehrkosten fürs Unternehmen (weil Rabatt- und Umsatzstaffeln im Einkauf nicht genutzt werden) oder
  
• Umsatzverlust im Shop (weil Konversionsraten unter ungenügendem Marketing, schlechtem Service, langen Lieferfristen oder fehlenden Bezahlarten leiden).

Zwar gilt für alle Onlinehändler gleichermaßen der Grundsatz, dass die Geschäftsprozesse - und damit die IT-Landschaft - den verfügbaren Service-Level zementieren. Grundlegend unterschiedlich ist allerdings die Ausgangsbasis, mit der die Online-Händler den Markt betreten. Dies hat oft einerseits historische Gründe, teils liegen aber auch strategische Überlegungen zugrunde.

Händlertyp: Vom Erfolg überrollt

Dieser Onlinehändler hat einen kleinen Shop mit Eigenmitteln aufgezogen. Inzwischen hat er durch organisches Wachstum eine respektable Größe erreicht, der Shopbetreiber hat sich mit Investitionen jedoch stets zurückgehalten. Die Strukturen im Shop sind mit der Zeit von selbst gewachsen. Hier gibt es in der Regel einen hohen Optimierungsbedarf. Zumal sich - Stichwort: Amazon Marketplace - die Anforderungen an den Händler inzwischen stark geändert haben.



Händlertyp: Im Hype gestartet

Gerade bei Shops, die zu Anfang dieses Jahrzehnts in den E-Commerce gestartet sind, waren Euphorie und Umsatzerwartungen oft sehr hoch. Doch nicht jeder Shop hat es geschafft, zur Gelddruckmaschine zu werden. Vielfach müssen die ehrgeizig gestarteten Projekte mit einem Bruchteil des ursprünglich erwarteten Umsatzes auskommen. Die überdimensionierte IT entwickelt sich nun zu einem gefährlichen Kostenfaktor. Hier sind pragmatische Lösung und Downsizing gefragt.



Händlertyp: Im Transformationsprozess verstrickt

Etablierte Händler, Hersteller und Marken kommen mit Millionenumsätzen aus der Offline-Welt und erschließen sich die digitale. Diese Unternehmen verfügen meist über eine ausgefeilte IT-Landschaft im Backend, die über die Jahrzehnte gewachsen ist und alle Handelsprozesse der Offline-Welt abbildet. Allerdings: Die neuen Prozesse des Onlinehandels - und hier noch einmal die speziellen Anforderungen des Multichannels - lassen sich kaum befriedigend abbilden.

Bevor sich die nun Händler daran machen, einzelne Geschäftsvorfälle zu gestalten, sind grundlegende Fragen zu klären. Zum Beispiel, wie der Online-Shop in die IT-Infrastruktur eingebunden werden soll. Die Frage ist weniger trivial, als sie zunächst klingt. Schließlich wird in diesem Schritt festgelegt, in welchem System die Prozesse gestaltet werden und welche Restriktionen sich draus ergeben. Vier Modelle dafür:

1. Prozesse werden durch die Shop-Software abgebildet

Bei diesem Ansatz wird der Shopsoftware zugleich die Prozesssteuerung zugeordnet.

Der Vorteil liegt darin, dass das Shop-System naturgemäß schon auf EBusiness-Prozesse spezialisiert ist und wenig Implementierungsaufwand nötig ist. Der Nachteil liegt darin, dass die Software meist ausschließlich Online-Handel kann. Sofern der Händler kein Pureplayer ist, muss er den Online-Shop in seine bestehende Prozesskette integrieren. Je nach Geschäftsfall kann das mühselig, teuer und umständlich werden.

Außerdem unterscheiden sich die Shopsysteme sehr deutlich in ihrer Flexibilität: Manche bieten eine große Schnittstellenvielfalt und verstehen sich schon fast als eine ECommerce-Plattform (siehe unten). Andere Lösungen sind monolithisch und nach außen eher geschlossen.

Vorteile:

• Die Systeme sind speziell auf die Erfordernisse des E-Business hin entwickelt,
  
• alle Einzelkomponenten sind perfekt verzahnt,
  
• es gibt keine Schnittstellen-, Anpassungs- oder Updateprobleme,
  
• es entstehen wenig Dienstleister-Abhängigkeiten, da eine Standardlösung verwendet wird.

Nachteile:
Die Shop-Software muss einen relativ großen Funktionsumfang bereitstellen. Oft stößt sie dabei an Grenzen. Folge:

• Bestimmte Tätigkeiten können nicht automatisiert werden (zum Beispiel weil der Funktionsumfang bei der Verwaltung von Marktplatz-Artikeln limitiert ist)
• Prozesswissen wird durch Mitarbeiterwissen kompensiert (zum Beispiel die Rabattstaffeln und Mindestbestellmengen beim Lieferanten bestimmter Produkte).
  
• Außerdem: Da die Lösung vorrangig auf E-Commerce spezialisiert ist, wird häufig die On-/Offline-Kanaltrennung noch zementiert.
  
• Kommen neuen Kanäle/Anforderungen hinzu (Sprachassistenten, IoT-Commerce, B2B-Kunden) muss der Händler auf eine Umsetzung durch den Hersteller des Shopsystems warten - oder das gesamte System wechseln.

2. Prozesse werden über eine monolithische ERP-Software abgebildet

Mittels eines ERP-Systems (etwa IBM, Microsoft oder SAP) werden die gängigen ECommerce-Prozesse abgebildet. Alle namhaften Hersteller bieten dafür bereits vorgefertigte Module - die sich allerdings noch zu den Kosten des Basis-Systems addieren.



Vorteile:

• Die Lösung ist flexibel, zahlreiche Subsysteme (Shop-Frontend, Marketing, Warenwirtschaft, PIM, Payment, Logistik) lassen sich einbinden - oder im ERP nachbilden. Ganz nach belieben.
  
• Alle wichtigen Prozesse liegen in einem System und sind übersichtlich gegliedert. Der Online-Shop ist nur eine mögliche Ausspielstation.
  
• Auch andere digitale Prozesse (Online-Marketing, Marktplätze) und nicht-digitale Prozesse (stationärer Handel) lassen sich im ERP steuern und können sich dort auch überkreuzen.
  
• Die Subsysteme müssen wenig Eigenintelligenz mitbringen, können aber auch Teilbereiche des Prozesses übernehmen und steuern.

Nachteile:

• Die Kosten für eine solche Lösung sind sehr hoch. Selbst wenn auf einem weißen Blatt Papier geplant werden kann, addieren sich Basis-ERP, Module und Consulting.
  
• Kann bereits auf ein bestehendes ERP-System aufgesetzt werden, müssen zumeist viel Prozesse grundlegend modifiziert werden. Die Projektlaufzeiten und -kosten sind dadurch ebenfalls sehr hoch.
  
• Für kleine Projekte ist die Lösung zu schwergewichtig und teuer.

3. Prozesse werden über eine Middleware abgebildet

Die Middleware steuert als Verwaltungsebene die Einzelprozesse (Logistik, Payment, etc.) und vermittelt zwischen Front- und Backend-Software. Eine solche Lösung ist deutlich schlanker als ein ERP-Ansatz, kann aber in weniger komplexen Fällen, dieselbe Leistung entfalten. Im Gegensatz zu einer ERP-Lösung werden die Einzelprozess auf den Subsysteme ausgeführt (während eine ERP-lösung die Prozesse komplett übernehmen kann). Viele Dienstleister (z.B. Marktplätze, Logistiker, Paymentanbieter) bieten selbst entsprechende (Teil-)Funktionalitäten an.



Vorteile:

• Der geringere Implementationsaufwand schlägt sich nicht nur in den Einmalkosten nieder, sondern auch im laufenden Betrieb.
  
• Der Shopbetreiber kann dadurch die die Möglichkeiten des Systems leichter auszuschöpfen. Die so gewonnene Bewegungsfreiheit kann die - auf dem Papier höhere - Flexibilität einer ERP-Lösung in der Praxis leicht überkompensieren.
  
• Alle wichtigen und typischen Prozesse sind bereits vorgesehen beziehungsweise lassen sich miteinander verknüpfen. Zentrale Updates erleichtern den Wartungsaufwand.
  
• Noch einfacher wird die Implementation, wenn die gesamte Middleware von Diensleistern erbracht wird. Logistik, Payment, Mail, Marketing, Fulfillment werden in der Cloud miteinander verknüpft. Der Händler muss lediglich die passenden Services miteinander verbinden.

Nachteile:

• Absolut betrachtet ist eine Middlewarelösung nicht so leistungsfähig und flexibel wie eine ERP-Lösung.
  
• Zudem schafft sie Abhängigkeiten von den Subsystemen, da die Einzelprozesse noch immer dort ablaufen. Bei einer ECommerce-Bestellung läuft beispielsweise der Bestellvorgang noch immer im Shopsystem ab, der Versand der Bestellbestätigung mit korrekter Anrede wird von der Mailing-Anwendung erledigt. Die Middleware verknüpft die Prozesse lediglich.
  
• Noch kritischer wird diese Abhängigkeit, wenn die Middleware an Dienstleister (wie Marktplätze) ausgelagert wird. In solchen Fällen sollte gründlich geprüft werden, ob genügend Kontrolle im eigenen Unternehmen verbleibt und ob die Geschäftsinteressen der Partner kompatibel sind.

4. Prozesse werden verteilt abgebildet

Dieser Ansatz kann Fluch und Segen zugleich sein. Im schlechtesten Fall kommen die verhassten, historisch gewachsenen, kaum mehr durchschaubaren IT-Infrastrukturen heraus. Im besten Fall sind die Prozesse aber klar strukturiert auf verschiedene Teilsysteme verlagert, die über genau definierte Schnittstellen kommunizieren. Dieser Ansatz erfordert eine hohe Prozessreife vom Unternehmen, kann dann aber zu einer sehr schlagkräftigen Lösung führen.



Vorteile:

• Richtig aufgesetzt kann sich eine passgenaue Anwendung ergeben, die aufgrund der Aufteilung in handliche Einzelmodule sehr flexibel und agil anpassbar ist.
  
• Einzelne Prozessketten lassen sich sehr flexibel an bestehenden Geschäftsfälle anpassen.
  
• Subsysteme (z.B. Shopsysteme) müssen wenig "Eigenintelligenz" mitbringen und können daher leicht ausgetauscht, günstig beschafft oder schnell neu entwickelt werden.
  
• Unter dem Stichwort "Microservcices" (siehe iBusiness Wie Microservices mehr Innovationsfähigkeit in Digitalunternehmen bringen) hat sich diese IT-Architektur sogar zu einem Trend entwickelt, bei dem selbst die Einzelapplikationen noch weiter zerlegt werden. Ziel: Jeder Einzelprozess ist eine Micro-Applikation, die sich über ihre Schnittstellen zu beliebigen Prozessketten verknüpfen lassen.

Nachteile:

• Unübersichtlichkeit, schlechte Dokumentation und gegenseitige Abhängigkeiten können die Administratoren in die Verzweiflung und das Unternehmen in die Unbeweglichkeit treiben.
  
• Bei Updates von Einzelkomponenten können sich Schnittstellenprobleme ergeben.
  
• Der hohe Synchronisationsaufwand kann zu doppelter Datenhaltung und Datensilos führen.
  
• Die Einzelapplikationen bleiben zwar übersichtlich - Entwicklung und Testing gestalten sich entsprechend einfach - das Gesamtsystem kann aber sehr komplex werden.
  
• Bei schlechter Dokumentation ergeben sich unter Umständen Abhängigkeit Dienstleistern.