Upload
buituyen
View
223
Download
0
Embed Size (px)
Citation preview
COMMERCE4 | E-Commerce Architekturen Seite: [1]
Whitepaper
E-Commerce Architekturen
Komplexe Prozesslandschaften
Autor: André Menzel
Version: 1.3
Stadtlohn, 17.09.2014
COMMERCE4 | E-Commerce Architekturen Seite: [2]
A: Impressum
Herausgeber: COMMERCE4 GmbH
Dufkampstrasse 40
48703 Stadtlohn
Tel.: +49 (0) 2563 90 555 79
Fax.: +49 (0) 2563 90 555 76
www.commerce4.de
Ansprechpartner: Markus Weber
Geschäftsführender Gesellschafter
Copyright: COMMERCE4 2014
Gestaltung: w+ Werbe- und Internetagentur GmbH
www.w-plus.de
Erklärung: Diese Publikation stellt eine unverbindliche und allgemeine Information zur
Themenrecherche dar. Die Inhalte geben Erfahrungswerte aus den Projekt-
geschehen der COMMERCE4 und ihrer Mandanten wider und spiegeln die
Auffassung und Motivation der COMMERCE4 zum Veröffentlichungszeitpunkt.
Die dargestellten Informationen wurden mit gegebener Sorgfalt unter Einbe-
ziehung der verfügbaren Quellen erstellt. Bedingt durch das Unternehmen-
Klienten-Verhältnis unterliegen diese teilweise den Bindungen an getroffene
NDA-Vereinbarungen und sind daher anonymisiert.
Es besteht kein Anspruch auf sachliche Richtigkeit, Vollständigkeit und/oder
Aktualität, insbesondere kann diese Publikation als Verallgemeinerung nicht
auf beliebige Einzelfälle übertragen werden. Eine Verwendung liegt daher in
der eigenen Verantwortung des Lesers. Jegliche Haftung wird ausgeschlossen.
Alle Rechte, inklusive der auszugsweisen Vervielfältigung, liegen bei der
COMMERCE4 GmbH. Bei Fragen bzw. Bitten um Weiterverwertung der Inhalte
wenden Sie sich an die oben dargestellte Adresse des Impressums.
COMMERCE4 | E-Commerce Architekturen Seite: [3]
B: Inhaltsverzeichnis
A: IMPRESSUM 2
B: INHALTSVERZEICHNIS 3
C: VERSIONIERUNG 5
EINLEITUNG 6
A) Der Eisberg-Effekt - 7/8 der Komplexität des digitalen Handels liegt im Verborgenen. 6
B) Ineinander greifende Rädchen 6
PROZESSSTRUKTUREN 8
Eine einheitliche Strategie über alle Absatzkanäle 9
PROZESSE RICHTIG STEUERN 11
A) ERP 11
B) PIM 11
C) CMS 11
D) LVS 12
E) FIBU 12
F) PSP 12
G) ESB 12
H) Kundenservice / CRM 13
I) Reporting 13
J) Frontend (Der Online-Shop) 13
K) Monitoring 13
L) BI 14
WIE BEKOMMT MAN DIE PROZESSBETEILIGTEN SYSTEME UNTER EINEN HUT? ACHT SYSTEMISCHE ANSÄTZE FÜR E-COMMERCE ARCHITEKTUREN 15
COMMERCE4 | E-Commerce Architekturen Seite: [4]
A) Systemkonzeption 1: All-In-One 17
B) Systemkonzeption 2: abhängige Prozesssteuerung in Shop-Plattform-Lösungen 18
C) Systemkonzeption 3: abhängige Prozesssteuerung in den großen ERP-Lösungen 19
D) Systemkonzeption 4: Architektur rund um PIM und ERP-Lösungen 20
E) Systemkonzeption 5: An Services gebundene Prozesssteuerungen 22
F) Systemkonzeption 6: Modulare Konzepte auf ERP-Basis-Software 23
G) Systemkonzeption 7: Modulkomplexe aus unabhängigen Teilsystemen 25
H) Systemkonzeption 8: Prozesssteuerung in ESB/ Middleware Komplettlösungen. 26
INDEX 28
COMMERCE4 | E-Commerce Architekturen Seite: [5]
C: Versionierung
GenerierungGenerierungGenerierungGenerierung
AutorAutorAutorAutor/ Name/ Name/ Name/ Name Processing UnitProcessing UnitProcessing UnitProcessing Unit DatumDatumDatumDatum KommentarKommentarKommentarKommentar André Menzel COMMERCE4 Beratung & Konzeption 24.04.2014 -
VersVersVersVersionierungionierungionierungionierung
Version Version Version Version DatumDatumDatumDatum AutorAutorAutorAutor Processing UnitProcessing UnitProcessing UnitProcessing Unit ErweiterungErweiterungErweiterungErweiterung KommentarKommentarKommentarKommentar 0.10.10.10.1 26262626.04.04.04.04.2014.2014.2014.2014 André MenzelAndré MenzelAndré MenzelAndré Menzel COMMERCE4 Beratung &
Konzeption Initialisierung -
0.20.20.20.2 04.06.201404.06.201404.06.201404.06.2014 André MenzelAndré MenzelAndré MenzelAndré Menzel COMMERCE4 Beratung & Konzeption
Basis-Strukturen -
0.30.30.30.3 05.06.201405.06.201405.06.201405.06.2014 André MenzelAndré MenzelAndré MenzelAndré Menzel COMMERCE4 Beratung & Konzeption
Erweiterung PIM -
1.01.01.01.0 11.06.201411.06.201411.06.201411.06.2014 André MenzelAndré MenzelAndré MenzelAndré Menzel COMMERCE4 Beratung & Konzeption
Erweiterung Performanz, Korrektur
-
1.11.11.11.1 20.06.201420.06.201420.06.201420.06.2014 André MenzelAndré MenzelAndré MenzelAndré Menzel COMMERCE4 Beratung & Konzeption
Erweiterung Messe-ergebnisse 2014 und PIM
-
1.21.21.21.2 26.08.201426.08.201426.08.201426.08.2014 André MenzelAndré MenzelAndré MenzelAndré Menzel COMMERCE4 Beratung & Konzeption
Erweiterung Projektergebnisse
-
1.31.31.31.3 17.09.201417.09.201417.09.201417.09.2014 André MenzelAndré MenzelAndré MenzelAndré Menzel COMMERCE4 Beratung & Konzeption
Reworking Layouts
-
COMMERCE4 | E-Commerce Architekturen Seite: [6]
Einleitung
A) Der Eisberg-Effekt - 7/8 der Komplexität des digitalen Handels liegt im Verborgenen.
Der eigentliche Versandprozess (Fulfillment) ist für den Online-Kunden nicht zu sehen. Was alles passieren muss,
damit die Warensendung erfolgreich an der Haustür ankommt, wird in seiner Komplexität nicht wahrgenommen.
Dies ist einer der Gründe, warum viele Betreiber, Umsetzer und Endkunden gleichermaßen E-Commerce
unterschätzen und ihn mit Online-Shops gleichsetzen:
Siehe C4-WP02-Kategorisierung-E-COMMERCE-SYSTEME, erhältlich auf der www.commerce4.de .
Der Online-Shop ist aber nur der offensichtliche Part (Frontend), in dem Angebot und Portfolio präsentiert und die
Auftragsprozesse angestoßen werden. Die im Frontend getroffenen Maßnahmen gewinnen die Kunden, faktisch
aber sind es die im Hintergrund stattfindenden Prozesse, die die Kundenaufträge umsetzen und damit das
wirtschaftliche Ergebnis erzielen. Nicht selten ist es darum so, dass mit großem Marketing-Aufwand Kunden zum
Frontend geführt und in die Conversion überführt werden – aber dann mangelndes Fulfillment den Auftrag
belasten und damit den Kunden enttäuschen und wieder verlieren. Umgekehrt haben nicht wenige Shopsysteme
gerade durch ein überaus zuverlässiges Fulfillment großen Erfolg, während das eigentliche Frontend – also der
sichtbare Shop – nicht als der attraktivste bewertet wird.
Maßgeblich für ein erfolgreiches E-Commerce-Geschäft ist daher die Verknüpfung der datenführenden Systeme
in der ganzen Prozesslandschaft. Hier liegen hohe Potentiale, Vorgänge zu automatisieren, um eine Belastung
der Personalressourcen zu vermeiden oder zu reduzieren.
B) Ineinander greifende Rädchen
E-Commerce stellt die IT vor komplexe Aufgaben. Viele verschiedene Prozesse müssen im täglichen Geschäft
harmonisch ineinandergreifen und auch dann noch reibungslos funktionieren, wenn in einem Prozess
Änderungen notwendig werden.
Eine moderne funktionale Lösung sollte hier acht Aufgaben effizient leisten:
1. Einprägsame und geschäftsfördernde Präsentation von Angebot und Services
( Abbildung des Portfolios )
2. Schnelle und möglichst störungsfreie Erfüllung des Kundenauftrags
( Abbildung des Geschäftsziels )
3. Korrekte und auf die Zahlungsoptionen abgestimmte Abwicklung des Finanzverkehrs
( Abbildung des wirtschaftlichen Ziels )
4. Transparente und ausreichend umfassende Abwicklung der Kundenkommunikation
( Abbildung des Kommunikationsziels )
5. Auswertung des Geschäftsergebnisses in Umsatz und Gewinnermittlung
( Abbildung des strategischen Ziels )
6. Auswertung der Maßnahmen und Kundenbindung
( Abbildung des Marketingziels )
7. Anbindung vielfältiger Online-Absatzkanäle neben dem eigentlichen Online-Shop
(Abverkaufsplattformen/ Marktplätze)
8. Deviveunabhängige Funktionalität auch auf mobilen Endgeräten
COMMERCE4 | E-Commerce Architekturen Seite: [7]
Jede der aufgezeigten Prozessinstanzen fordert
eigene Datenstrukturen und Inhalte. Entsprechend
ergibt sich die Forderung an die IT-Lösung, diesen
unterschiedlichen Anforderungen gerecht zu werden
und die entsprechenden Inhalte am Prozessstandort
auszuliefern.
Doch dies reicht als Bedingung nicht aus: Die
geforderten Dateninhalte müssen die notwendigen,
verschiedenen Datenstränge
• Produktdaten, Beschreibung
• Produktdaten, Logistik
• Produktdaten, Preise
• Kundendaten
• Auftragsdaten, Warenfluss
• Auftragsdaten, Finanzen
• Marketing Maßnahmendaten
aktuell und für den Umsetzungsprozess vollständig ausliefern. Diese Bedingungen würden idealerweise ein
zentralisiertes System präferieren, jedoch führt die Komplexität der Aufgabe E-Commerce zu spezialisierten
Teilsystemen, die zudem weitaus besser den Anforderungen an Performanz gewachsen sind.
Die Folge ist die Herausforderung, dass verschiedene Teilsysteme auf denselben Daten operieren, so dass die
gewählte Architektur der Verbindung dieser Teilsysteme sicherstellen muss, welches System zu jedem Zeitpunkt
den maßgeblichen Datensatz führt.
Das klingt trivial, die Projekterfahrung aber zeigt, dass E-Commerce-Systeme in gewachsene Landschaften
eingepasst werden müssen. Situationen, die eine einheitliche All-In-One-Lösung sowohl technisch als auch
wirtschaftlich gestatten, sind nicht die Regel. Darum ist die Herausforderung, eine Systemarchitektur von
interagierenden Teilsystemen zu schaffen, eine der wichtigsten Entscheidung über Investitionen bei der
Bewertung von E-Commerce-Strategien.
COMMERCE4 | E-Commerce Architekturen Seite: [8]
Prozessstrukturen
Aus den prinzipiellen Datenanforderungen der sieben aufgezeigten Datenstränge können die Systeme identifiziert
werden, die als Datenquellen in Frage kommen. Deren Anordnung ist Aufgabe der Architektur in der Abbildung
der Prozessstrukturen unter wirtschaftlichen Vorgaben.
Die IT-Basis ist im Regelfall aus dem stationären Geschäft gewachsen: Die IT im Handel hat ihre Prozesse in aller
Regel umfassend im Griff. ERP- und Warenwirtschaftssysteme führen die lebenswichtige Warenversorgung und
die anhängenden Verwaltungs- und Abrechnungsvorgänge reibungslos durch. Lagerlogistik und Fulfillment sowie
Payment, Debitorik, Kundenservice und Reporting sind eingebunden.
E-Commerce erweitert diese Prozesslandschaft um eine neue Dimension. Denn es geht um wesentlich mehr, als
den einfachen Anschluss z.B. einer weiteren Filiale, die eben online operiert. So müssen zum Beispiel Dinge, die
Mitarbeiter in den Filialen intuitiv erledigen, automatisiert in die Systeme integriert werden. Und natürlich gibt es
auch für Versandhandel spezifische Besonderheiten, die für einen stationären Händler gänzlich neu sind,
insbesondere in der Content-Bereitstellung für Produktdaten und Produktinszenierung Online.
COMMERCE4 | E-Commerce Architekturen Seite: [9]
Eine einheitliche Strategie über alle Absatzkanäle
Ungeachtet aller Neuerungen muss der Onlineshop als Filiale möglichst eng in die Gesamtheit des
unternehmerischen Wirkens eingebunden sein und mit den bestehenden Prozessen interagieren – nur dann
lassen sich die vorhandenen Synergie-Potenziale ausschöpfen. Das Unternehmen kann nicht mehr einfach in
verschiedenen Vertriebslinien planen – es muss alle Kanäle einheitlich in eine Gesamtstrategie bündeln. Egal,
wie der moderne Begriff dafür ausfällt: Multichannel, Polichannel, Oligochannel: Es ist eine Strategie notwendig,
die alle Vertriebsaktivitäten bündelt – und dafür die aufeinander abgestimmte Systemwelt bereitstellt, damit alle
Kanäle einheitlich über alle notwendigen Daten verfügen kann.
Zugleich gilt es, die Umsetzung der Strategie auf die Anforderungen des jeweiligen Kanals hin zu optimieren: Die
Tätigkeiten des Retails sollen dort in seiner Kanalumgebung perfektioniert werden, ebenso die Prozesse im
Fulfillment des Versandhandels in seinem Umfeld.
Die Konsequenz für die IT-Architektur ist klar:
Voneinander unabhängige Insellösungen nur für einen jeweiligen Vertriebskanal sind nicht zielführend, da
potentiell gleichlautende Vorgänge redundant und damit kostenlastig auftreten. Alle einzelnen Maßnahmen und
Systeme müssen für die Gesamtheit der Prozesskette funktionieren. Dass indes die Prozesse im E-Commerce auf
den Versandhandel spezialisiert sind, stellt die bestehenden ERP(Enterprise Ressource Planning)-Systeme vor
große Herausforderungen, beeinträchtigt bestehende Prozesse erheblich und steigert den Komplexitätsgrad zum
Teil unverhältnismäßig. Dieses Dilemma aus ganzheitlicher Verzahnung der IT und der für den Versandhandel
spezifische Prozesskette zu lösen, ist eine der zentralen Aufgaben.
COMMERCE4 | E-Commerce Architekturen Seite: [10]
Dabei soll die Prozesssteuerung hinter dem Onlineshop Routinevorgänge in hohem Maße automatisieren und
komplexe Informationszusammenhänge zwischen den beteiligten Systemen realisieren. Dies erfordert hohe
Intelligenz in der Verwaltung der Prozesse.
COMMERCE4 | E-Commerce Architekturen Seite: [11]
Prozesse richtig steuern
Die Herausforderung für die IT im E-Commerce ist, die richtigen Andockstellen an bestehende Prozesse zu
identifizieren und die für den Online-Versandhandel notwendige Spezialisierung umzusetzen, ohne die
bestehende Prozesslandschaft der anderen Fachbereiche aufzuweichen.
Alle im folgenden aufgezählte Prozesse sind in ihrer Weise für E-Commerce relevant. Aber nicht jeder Prozess ist
auch in jedem E-Commerce-Szenario durch ein eigenständiges System repräsentiert: Abhängig von den zu
prozessierenden Volumina sind manuelle und organisationelle Umsetzungen möglich. Dennoch - damit ein
Onlineshop reibungslos funktioniert, müssen die viele Prozesse in sich geschlossen funktionieren und deren
prozessierenden Systeme miteinander verzahnt werden:
A) ERP
(Enterprise Resourc(Enterprise Resourc(Enterprise Resourc(Enterprise Resource Planning)e Planning)e Planning)e Planning)
ERP-Systeme ermöglichen Unternehmen die Abbildung ihrer Geschäftsprozesse. Im Customizing werden ERP-
Systeme an Kundenanforderungen angeglichen, große Anbieter bieten neben dem System standardisierte
Vorgehensmodelle an die, die Prozesse mit der Einführung ausgerichtet werden. Bei der Instanziierung von E-
Commerce ist das ERP ein zentraler Dreh- und Angelpunkt. Meist sind die bestehenden Prozesse eng mit der ERP
verknüpft und jede Änderung erzeugt hohe Entwicklungsaufwände. Daher ist genau zu betrachten, ob und wie E-
Commerce in das ERP integriert werden kann oder ob es wirtschaftlicher ist, z.B. die B2C-Prozesse in einer
eigenen Versandhandelslösung auszulagern und nur die Wirtschaftsergebnisse im ERP wieder
zusammenzuführen.
B) PIM
(Product(Product(Product(Product----InformationInformationInformationInformation----Management)Management)Management)Management)
Hinter der Forderung nach einheitlichem Multichannel-Management steht vor allem die zentrale Bereitstellung
von Produktbeschreibungen, die unter Umständen auch gerätespezifisch abweichen können. Eine intelligente
Aussteuerung nach Attributen und Media-Assets verlangt nach einer PIM-Lösung. Die Content-Entwicklung und
Verwaltung ist ein wichtiger Kostenfaktor, der durch eine zentrale Steuerung reduziert werden kann. Dies macht
ein System zum Product-Information-Management notwendig. Gleichzeitig muss das PIM die Inhalte für
verschiedene Kanäle aussteuern können.
C) CMS
(Content(Content(Content(Content----ManagementManagementManagementManagement----System)System)System)System)
In den meisten E-Commerce-Shoplösungen sind CMS-Ansätze verwirklicht. Die Verwaltung von Content-Inhalten,
Navigation und Datencontainern erfolgt aus dem Shop-Backend heraus.
Anders als in lizenzseitig sehr investitionsintensiven Highend-Enterprise-Systemen sind diese CMS-
Verwaltungen rudimentär. Nutzern mit wenig Entwicklungskompetenz bieten sie kaum Unterstützung. Es
COMMERCE4 | E-Commerce Architekturen Seite: [12]
empfiehlt sich dann die Kopplung mit einer standardisierten CMS-Lösung und dem Shop. Die Setup-Aufwände
sind erfreulich gering. Die Vorteile für den Pflegebetrieb sind indes enorm. Zudem bekommt man leichter gute
Leute für die Pflege von Standard-CMS-Lösungen wie Typo3. Meist sind auch die betreuenden Agenturen mit der
Software bestens vertraut. COMMERCE4 hat eine Integrationslösung zunächst für das Shopsystem OXID
geschaffen: Dazu mehr Details siehe COMMERCE4 Whitepaper C4-WP03-CMS-E-COMMERCE unter
www.commerce4.de.
D) LVS
(Lagerverwaltungssystem(Lagerverwaltungssystem(Lagerverwaltungssystem(Lagerverwaltungssystem))))
Das LVS verwaltet das Lagersystem, steuert die Logistikprozesse sowie Kommission und Versand. Je nach
Logistik-Konfiguration leisten diese mehr oder weniger Prozessunterstützung in der Auftragsverwaltung, so dass
die Anforderungen des LVS gegenüber dem E-Commerce eine wichtige Instanz zum Beispiel über Inhalte und
Status der Auftragsdatensätze ausmachen.
E) FIBU
(Finanzbuchhaltung)(Finanzbuchhaltung)(Finanzbuchhaltung)(Finanzbuchhaltung)
Oft ist die Fibu Bestandteil der ERP-Systemumgebung, aber auch spezialisierte Systeme sind verbreitet. Die
Aufgabe der Fibu ist das Rechnungswesen des Unternehmens und daher angewiesen, die notwendigen Daten
über Umsätze, Zahlungsvorgänge, offene Forderungen und Buchungen zu erhalten.
Die dafür notwendige Kontierung von Debitorenkonten im B2C-E-Commerce kann eine hohe Herausforderung für
Personal und Systeme sein, da gerade bei hohen Neukundengewinnen hier konstant zum Auftragsvolumen hohe
Aufwände anfallen. Lösungen, in denen die Debitorik als Sammeldebitorik durch ESB oder PSP geleistet werden,
können hier Aufwände begrenzen. Der Umfang ist abhängig von der gewählten IT-Architektur und Infrarstruktur
des Unternehmens.
F) PSP
(Payment(Payment(Payment(Payment Service Provider)Service Provider)Service Provider)Service Provider)
Zahlarten wie Kreditkarten erfordern zur Verwaltung der hochsensiblen Kundendaten besonders abgesicherte
Systeme und Verwaltungsprozesse, die dem PCI-Zertifikat genügen und in regelmäßigen Audits immer wieder
nachgewiesen werden müssen. Da dies für die meisten Unternehmen wirtschaftlich nicht tragbar ist, haben sich
Dienstleister etabliert, die diese Services anbieten: Die Payment Service Provider (PSP).
Aber Payment Services umfassen mehr: Internationale Märkte benötigen entsprechende nationale
Zahlungssysteme, die der PSP anbieten kann. Zahlarten, die Risiken für Zahlungsausfälle beinhalten können,
benötigen zur Absicherung ein Riskmanagement über Prüfungen und Bewertungen der Kundenaufträge. Services
in der Debitorik und im Reporting fallen hierunter, ebenso wie Dienstleistungen im Mahnwesen und Inkasso.
G) ESB
(Enterprise Service Bus)(Enterprise Service Bus)(Enterprise Service Bus)(Enterprise Service Bus)
COMMERCE4 | E-Commerce Architekturen Seite: [13]
Auch gerne als Middleware bezeichnet, stellt der ESB die Datendrehscheibe dar. ESB‘s sind eine Lösung, um
Synchronisierung von Daten zwischen Teilprozessen zu optimieren, den jeweils aktuellsten Datenstand
auszuliefern und Dateninhalte in die jeweils benötigten Schnittstellenformate auszuliefern. Für Multichannel-
Strategien sind ESB wichtige Instanzen, da die ERP als solche mit den Zusatzaufgaben der Datenzuteilung nicht
belastet werden soll bzw. die Lizenzmodelle der ERP's ein solches Vorgehen auch wirtschaftlich nicht
unterstützen.
H) Kundenservice / CRM
(Customer Relations Management)(Customer Relations Management)(Customer Relations Management)(Customer Relations Management)
Auch der Kundenservice braucht eigene Abläufe, die – natürlich – mit den Informationen und Prozessen im
Payment und der Debitorik ebenso verbunden sein müssen wie mit der Warenwirtschaft beziehungsweise der
Logistik. Dabei sind die Presale-Informationen, also wie der Kunde zur Conversion gelangt ist, genauso
bedeutungsvoll wie die Auswertung der Aufträge selbst. Ohne ein entsprechendes Monitoring (s.u.) ist hierfür die
Datensammlung nur schwer zu generieren.
I) Reporting
Eine Bewertung der E-Commerce-Vorgänge kann nur getroffen werden, wenn die relevanten Ergebnisdaten in
einem zieloptimierten Reporting bereitgestellt werden. Es ist im Projektgeschäft stets erstaunlich, wie viele
Online-Shops wirtschaftlich praktisch im Blindflug geführt werden, weil die notwendigen Daten nicht erhoben
werden oder es als zu aufwändig erscheint, dies zu tun.
J) Frontend (Der Online-Shop)
Ein Online-Shop ist definiert als das Online-verfügbare System, in dem das Produkt- oder Dienstleistungsangebot
beworben und dargestellt wird, dem Endkunden Zugang zu Bestelloptionen gewährt und über einen
Bestellprozess Aufträge sowie deren Bezahloptionen generiert. Das stellt auch klar, woraus Online-Shops
minimal bestehen müssen:
- Produkt/ Angebotskatalog
- Navigation ( Menue / Suche)
- Warenkorb
- Bestellvorgang
- Kundenverwaltung
- Informationsdarstellung
Mehr Details dazu siehe das COMMERCE4-Whitepaper C4-WP02-Kategorisierung-E-COMMERCE-SYSTEME unter
www.commerce4.de.
K) Monitoring
Wenn Kunden einen Online-Shop benutzen, folgen sie verschiedenen angebotenen Pfaden zu den Angeboten.
Dies beinhaltet Einstiege in den Shop aus verschiedenen Marketing Maßnahmen, ebenso wie die Nutzung der
verschiedenen Navigationsoptionen und Suchangebote im Shop selbst.
COMMERCE4 | E-Commerce Architekturen Seite: [14]
Sowohl für die Wirksamkeit und Ergonomie der Seitenelemente als auch als Datensammlung für die Effekte der
Marketingmaßnahmen ist die Einrichtung eines umfangreichen Monitorings notwendig.
L) BI
(Business Intelligence)(Business Intelligence)(Business Intelligence)(Business Intelligence)
Die BI wertet die Datenmengen aus und bereitet sie nach strategischen Vorgaben aus. Ihr Ziel ist der
Erkenntnisgewinn über Effekte und Faktoren, die in den Prozessen die wirtschaftlichen Ergebnisse verändern.
Damit liefert die BI Entscheidungsgrundlagen für die strategische Weiterentwicklung der E-Commerce-
Umgebung.
COMMERCE4 | E-Commerce Architekturen Seite: [15]
Wie bekommt man die prozessbeteiligten Systeme unter einen Hut?
Acht systemische Ansätze für E-Commerce Architekturen
Muss man das alles haben?
Muss es wirklich dieser Komplexitätsgrad sein, „nur“ um E-Commerce zu betreiben?
Aber klar: Jain!
In jeder Unternehmung sind die im vorherigen Kapitel aufgezählten Prozesse/ System-Instanzen in der ein oder
anderen Form vorhanden. Eventuell sind es auch Aspekte von Tätigkeiten, die an einem Arbeitsplatz anfallen, die
vielleicht auch in ihrer Bedeutung gar nicht so ausschlaggebend wahrgenommen werden. Wachsende Volumen
im Sortiment, in Marketingmassnahmen und gerade in den zu verarbeitenden Transaktionen steigern auch die
Bedeutung der einzelnen Prozesskomponenten – und damit auch der Aufwand, der betrieben werden kann, um
dort Automatisation zu betreiben bzw. die Vorgänge durch Systemunterstützung zu optimieren.
Das ist die entscheidende Herausforderung in der Auswahl einer in sich stimmigen IT-Architektur:
- Wie ist das Business-Ziel für das E-Commerce-Vorhaben?
- Welche Prozesseinheiten sind schon vorhanden?
- Welchen Anteil nehmen diese Vorgänge am Gesamtkonzept E-Commerce im definierten Projekt?
- In welche anderen Kanäle und strategischen Konzepte sind die bestehenden Prozessinstanzen bereits
eingebunden?
- Ergeben sich daraus Restriktionen, die beachtet werden müssen?
Sind z.B. in Bezug auf Personalresourcen, Schnittstellenformate, Synchronisationszeitpunkte
Einschränkungen gegeben, damit die Einrichtung E-Commerce bestehende Kanäle nicht beeinträchtigt?
- Wie ist der wirtschaftliche Impact bei der Einrichtung von Prozessinstanzen?
Ist es z.B. günstiger, einen externen Logistikdienstleister zu nutzen oder ist ein eigenes Lager die
günstigere Option, da es schon vorhanden ist?
Um diese Fragen zu beantworten, sind zwei Dinge entscheidend:
1. Eine klare strategische Zieldefinition
2. Eine IST-Aufnahme der bestehenden Prozesse und Systeme
Dazu ein Beispiel:
Nehmen wir z.B. an, der Mandant sei ein Hersteller aus dem Bereich Kleidung. Bisher bedient der Mandant in
seinen B2B-Prozessen den stationären Handel und schleust Restanten über ebay ab. Strategisch wird
entschieden, dass zur Stärkung der Marke eine Markenpräsentation online geschaffen werden soll. Da der
Aufwand der Contenterstellung für die sich schnell ändernden Sortimente hoch ist und der Online-Abverkauf
erschlossen werden soll, soll hier ein Online-Shop der Marke eingerichtet werden.
Es wird schnell im Unternehmen deutlich, dass ein eigener Einkaufsprozess nur für Online keinen Sinn macht, da
die saisonalen Verkaufszyklen denen im stationären Handel folgen. Das bedeutet, Listung und Content-Prozess
für den neuen Online-Kanal sind mit den bestehenden Einkaufs- und Warenwirtschaftsprozessen zu verbinden.
Das Unternehmen besitzt ein ERP-System, hatte bisher aber keine Notwendigkeit für ein allgemeines PIM-System
gesehen, so dass die Artikel-Stammdaten zwar vorliegen, aber trotzdem eine Veredelung zum Nutzen gegenüber
COMMERCE4 | E-Commerce Architekturen Seite: [16]
B2C-Kunden vorgenommen werden muss. Zwar verfügt das Unternehmen über ein Lager, aber dieses ist nicht für
Einzelkommission ausgerichtet. Hier gilt es abzuklären, ob die Einrichtung von B2C-geeigneten Versandstrassen
günstiger ist als die Nutzung eines Logistikdienstleisters. Nehmen wir an, die Zahlen sprechen für den externen
Logistiker. Gleichzeitig hat der Mandant in seinem Unternehmen zwar einen Kundendienst, aber dieser ist
personell nicht darauf eingestellt, umfangreiche B2C-Anfragen zu beantworten. Auch die Finance kann im
Rahmen des geplanten Transaktionsvolumens personell die Buchungen nicht manuell vornehmen – hier ist
Automatisierung gefragt.
Von dieser Ausgangslage aus kann man anhand der aufgeführten Prozesse ersehen, welche es bereits im
Unternehmen gibt und welche zu erweitern sind. Es empfehlen sich vielleicht zwei der unten aufgeführten
Lösungen:
Lösung E: An Services gebundene Prozesslandschaft
Der Logistiker bietet z.B. auch ein Call-Center für den 1st Level Kundensupport an und betreibt eine eigene
Prozessplattform, die z.B. auch Finanzdienstleistungen anbietet. Das bedeutet, der Logistiker müsste neben der
Einbindung in den Warenfluss auch Schnittstellen für Abverkaufsreportings und Buchungsinformationen
einrichten.
Lösung H: Einrichtung einer Middleware / ESB-Lösung
Der Auftragsverwaltungsprozess und die Paymentsteuerung erfolgt weitestgehend automatisiert durch die
eingesetzte Middleware, der Logistiker setzt die kommissionsfähigen Versandaufträge um und reportet den
Versandstatus. Aus der Middleware werden Abverkaufsreportings und ggf. Buchungsinformationen gegenüber
der ERP generiert.
Für welche der beiden Lösungen sich der Mandant letztendlich entscheidet, hängt von den konkreten Angeboten
der Dienstleister Logistik bzw. Middleware ab. Hier kann auch entscheidend sein, welche Payments angebunden
und verarbeitet werden können bzw. für welchen Paymentanbieter bereits standardisierte Schnittstellen
vorliegen.
Das Beispiel sollte deutlich aufzeigen,
A) wie wichtig die definierte strategische Zielsetzung,
B) und die richtige Vorarbeit in der IST-Aufnahme ist,
C) wie entscheidend die auf den ermittelten Anforderungen basierenden wirtschaftlichen Fakten/
Angebote sind, die systemisch aufeinander abgestimmt sein müssen.
Die folgenden Systemkonzeptionen zeigen farblich abgesetzt, welche Systeminstanz führend die E-Commerce-
Prozesse verwaltet und welche Systeme extern hinzugefügt werden müssen (siehe Farblegende in den
Architektur-Schemata). Um die Architekturansätze als Entscheidungshilfe zu nutzen, sollten die vorhandenen
Systeme und Prozesse gegen die aufgezeigten Ansätze gegen geprüft werden. Es kann auf der Basis der
Vorannahmen keine endgültige Empfehlung erwartet werden, aber aus den Konzeptionen können Hinweise
abgeleitet werden, in welche Richtung Planung gehen können.
Die Konzepte sind in ihrer Natur sehr komplex, das machen schon alle verbundenen Teilprozesse aus dem
vorhergehenden Kapitel deutlich. Der beste Weg ist, dazu eine fundierte Beratung in Anspruch zu nehmen. Die
Kosten für eine solche Beratung sind aufgrund der potentiellen Einsparung im späteren Projektverlauf gut
investiert.
COMMERCE4 | E-Commerce Architekturen Seite: [17]
A) Systemkonzeption 1: All-In-One
Wie schon in der Einleitung dargestellt, so stellt natürlich eine komplett für das E-Commerce-Geschäft
individualisierte Lösung in seiner Weise das Optimum dar, in der keine anderen Prozesse des Unternehmens
beeinflusst werden.
Gleichzeitig ist der All-In-One-Ansatz auch der wirtschaftlich aufwändigste, da hier kaum Anteile bestehender
Prozessstrukturen integriert sondern alle Prozesse für die Online-Verwendung individuell aufgesetzt werden.
Dies geschieht auch, wenn dabei Strukturen, Einrichtungen, Organisationseinheiten und Vorgänge doppelt
aufgesetzt werden.
In dieser Form ist dieser Ansatz verbreitet als Outsourcing-Angebote von E-Commerce-Dienstleistern, die bis auf
die Business-steuernde Instanz das gesamte E-Commerce Geschäft von eine Mandanten übernehmen, meist
auch unter Einsatz eigenen Risikos, d.h. über eine Beteiligung an den erwirtschafteten Ergebnissen.
• Geeignet für:
Unternehmen, deren eigene Ressourcen keine eigene Umsetzung im Rahmen bestehender Prozesse
ermöglichen oder deren Organisation eine eigene Umsetzung erfordern und deren Sortimente die
zusätzliche wirtschaftliche Belastung eine solche Umsetzung zulassen.
• Vorteile:
Keine Beeinflussung bestehender Systeme und Prozesse, insbesondere die kostenintensive Anpassung
COMMERCE4 | E-Commerce Architekturen Seite: [18]
von ERP-Umgebungen wird vermieden.
• Nachteile:
Potentielle wirtschaftliche Belastung des wirtschaftlichen Ergebnisses durch redundante Prozesse.
B) Systemkonzeption 2: abhängige Prozesssteuerung in Shop-Plattform-Lösungen
Das Frontend-System ist die Prozesse eingebunden. Die Shop-Software hat direkten Anteil an den
Prozessfunktionen und steuert Vorgänge sowie verwaltet deren Datenflüsse.
Eine solche Lösung erfordert eine Shop-Software, die diese Prozessunterstützung abbilden kann wie z.B. Hybris,
Demandware (als SAAS) oder Intershop Enfinity. Die dahinter liegende Prozesslandschaft wird überwiegend
durch das ERP/Warenwirtschaftssystem, das Lagerverwaltungs-System (LVS) und das Customer Relationship
Management (CRM) bestimmt.
• Geeignet für:
Unternehmen mit entsprechend großem Potential, großen Transaktionsvolumen/ Umsatzstrukturen und
einer ausgeprägten eigenen ERP-IT-Infrarstruktur. Hier sind eigene Entwicklungsressourcen von Vorteil,
da die Inanspruchnahme der Dienstleistungsangebote für die betreffenden E-Commerce-Umgebungen
ein hohes Investitionsvolumen erzeugen kann. Dies gilt um so mehr, je weniger die eigene ERP-
Umgebung die Anforderungen des Online-Versandhandels nicht abbilden kann.
COMMERCE4 | E-Commerce Architekturen Seite: [19]
• Vorteile:
Keine Beeinflussung bestehender Systeme und Prozesse, insbesondere die kostenintensive Anpassung
von ERP-Umgebungen wird vermieden.
• Nachteile:
Potentielle wirtschaftliche Belastung des wirtschaftlichen Ergebnisses durch redundante Prozesse.
Nicht nur wegen der erforderlichen mächtigen Shop-Software, die alle zentralen Prozesse steuert, sondern auch
wegen der eher kleinen Entwicklergemeinde für diese Systeme, sind solche Szenarios oft kostenintensiv und
aufwändig.
C) Systemkonzeption 3: abhängige Prozesssteuerung in den großen ERP-Lösungen
Integrierte Lösungen für die Prozesssteuerung auf Basis der „Großen“ ERP-Systeme. SAP, IBM und Microsoft
bieten für ihre ERP-Umgebungen modulare Erweiterungen, mit denen sich der komplette Prozessraum abbilden
lässt. Diese erweitern die Basisfunktionen des ERP, um die Versandhandelsprozesse abzubilden.
Bereits die Basis-ERP birgt bereits ein großes Investitionsvolumen. Hinzu kommen die Kosten für die
Modulerweiterungen. Allein das Consulting für diese Bereiche kostet nicht selten soviel wie das Setup eines
geeigneten ESB/Middleware-Systems. Weiterer Nachteil: Diese Lösungen sind hochspezialisiert und komplex.
Und sie sind abhängig von der Basis-IT und deren Betriebsorganisation.
COMMERCE4 | E-Commerce Architekturen Seite: [20]
• Geeignet für:
Unternehmen mit entsprechend großem Potential, großen Transaktionsvolumen/ Umsatzstrukturen und
einer ausgeprägten eigenen ERP-IT-Infrarstruktur, die für den Online-Versandhandel ausgelegte
Systemerweiterungen anbietet. Als reine Frontend-Extensionen können lizenzseitig günstigere
Shopsysteme aus dem professionell oder Enterprise-Segment, wie z.B. OXID, Magento, xt-commerce,
shopware, etc… verwendet werden.
Der Einsatz der entsprechend mächtigen Frontend-Plattformen wie unter B) Hybris, Demandware,
Intershop enfinity ist hier differenziert zu betrachten, da diese einerseits auch ein hohes Kostenvolumen
mitbringen, andererseits viele Prozesstrukturen gegenüber der ERP-Umgebung redundant vorhanden
sind.
• Vorteile:
Sämtliche Warenbewegungsprozesse für alle Unternehmensbereiche und Absatzkanäle werden in
einem System abgebildet und ausgesteuert. Gerade in kanalübergreifenden Optionen wie der
Rabattierung sind hier klare Lösungsstrukturen vorgegeben, die in anderen Architekturen durch
aufwändige Schnittstellen und Interpretationsvorgänge nachgebildet werden müssen.
• Nachteile:
Die Anbindung des E-Commerce als neuem Vertriebskanal mit allen Besonderheiten erfordern die
Anpassung der ERP-Landschaft. Das beinhaltet oft die Beeinträchtigung bereits bestehender und
optimierter Prozesse, so dass die daraus entstehenden Kompromisse nicht selten weder für das E-
Commerce noch die bestehenden Kanäle optimale Situationen ergeben. Die Folge können Performanz-
Verluste sein oder auch hohe Aufwände in Beratung und Entwicklung nach sich ziehen.
Diese Lösungen sind allgemein hochspezialisiert und komplex, daher teuer und beratungsintensiv.
D) Systemkonzeption 4: Architektur rund um PIM und ERP-Lösungen
Der Datentransfer wird in entsprechend dimensionierten IT-Umgebungen gerne durch den Einsatz eines Systems
zur Datenverteilung (ESB – Enterprise Service Bus, siehe Lösung H) realisiert.
Gleichzeitig haben Anbieter von PIM (Product Information Management) den gleichen Bedarf erkannt, nämlich
dass die Dateninhalte der PIM-Umgebung an verschiedene Folgesysteme synchronisiert verteilt werden müssen.
Als Folge aus dieser Erkenntnis haben einige PIM-Systeme ähnliche Mechanismen zur Datenverteilung
entwickelt, so dass diese gegenüber den Frontend-Systemen die Position von ESB einnehmen können und der
ERP-Landschaft die Fulfillment-Abwicklung überlassen können. Diese Lösung kann sehr elegant sein, wenn z.B.
der Payment Service Provider auch die nötigen Debitorik-Vorgänge verwaltet, so dass für das ERP keine
spezialisierten Prozesse anfallen.
COMMERCE4 | E-Commerce Architekturen Seite: [21]
• Geeignet für:
Unternehmen, die nur über eine bedingt versandhandelsfähige ERP verfügen, aber das Volumen haben,
um in eine entsprechend geeignete PIM-Umgebung investieren zu können.
• Vorteile:
Die ERP-Landschaft wird auf den Warenflussprozess reduziert und nur in geringerem Maße durch
spezielle Online-Teilprozesse belastet.
• Nachteile:
Hohe Auftragsvolumen können die Performanz der PIM-Umgebung belasten, die oft für so hohe
Anfragefrequenzen nicht ausgelegt sind. Gleichzeitig ist im Projektrahmen eine Erweiterung der PIM-
Umgebung um artfremde Daten wie Auftragsdaten und Kundendaten notwendig, was die Höhe der
Projektinvestitionen beeinträchtigen kann.
COMMERCE4 | E-Commerce Architekturen Seite: [22]
E) Systemkonzeption 5: An Services gebundene Prozesssteuerungen
Fullservice-, Logistik-und andere Dienstleister bieten vermehrt eigene Interface-Systeme an, die ähnlich wie ESB
(Enterprise Service Bus) in einigem Umfang die Möglichkeit zum Datenaustausch ermöglichen:
Sie bieten die Funktionalität einer Middleware für die Prozesssteuerung im Zusammenspiel mit möglichen
Partnersystemen und natürlich den eigenen nachgelagerten Dienstleistungsprozessen - also beispielsweise zur
Lagerverwaltung und zum Fulfillment des Logistikers oder möglichen Call-Center Services für die
Kundenkommunikation. Oft decken diese Systeme auch die Auftragsverwaltung im Zusammenhang mit
Logistikservices ab, kommunizieren mit den Systemen des Payment Service Providers oder mit CRM-Lösungen
verschiedener Call-Center-Anbieter.
Zu einem gewissen Grad bestimmen die nachgelagerten Dienstleisterprozesse auch die notwendige Ausrichtung
und Konfiguration der Systeme, die an den Serviceblock angeschlossen sind: Bedingt durch die Bereitstellung
der Services für viele Mandanten können diese nicht einfach in jeder Hinsicht individuell angepasst werden. Als
Vorteil für den Mandanten kann der Dienstleister eine entsprechende Performanz und Skalierbarkeit durch
Verteilung der Services auf viele Mandanten weitaus wirtschaftlicher darstellen als ein Mandant für sich alleine
es könnte.
• Geeignet für:
Unternehmen, denen elementare Ressourcen (z.B. Logistik) für ein E-Commerce Business fehlen und
COMMERCE4 | E-Commerce Architekturen Seite: [23]
deren Anforderungen an Fulfillment durch Standard-Prozesse abbildbar sind.
• Vorteile:
Die Auslagerung von Services an Dienstleister erspart die Bereitstellung von Ressourcen im
Unternehmen des Mandanten. Insbesondere die Anforderung an die mandanteneigene IT ist potentiell
geringer als in andere Setups.
• Nachteile:
Outsourcing schmälert immer den eigenen Ertrag durch die zusätzlichen Kostenstrukturen des
Outsourcing-Dienstleisters. Die Prozesse des Dienstleisters sind häufig in den Möglichkeiten der
Individualisierung beschränkt, bzw. erzeugen einen entsprechenden Aufwand, um Extras für Mandanten
zu entwickeln.
Diese Konzeption macht ihren Nutzer abhängig von den Servicedienstleistung und deren Kostenstruktur.
Das heißt, andere, zusätzliche Services anderer Dienstleister lassen sich oft nicht flexibel anbinden, und
die Kosten sind nur in begrenztem Umfang flexibilisierbar.
F) Systemkonzeption 6: Modulare Konzepte auf ERP-Basis-Software
In der Marktsituation der ERP-Anbieter haben Systemhäuser erkannt, dass die hohen Investitionsvolumen, wie
sie in der Lösung C) dargestellt sind, für viele Mandanten ein Hinderungsgrund sind, um eine solche
Lösungskonzeption umsetzen zu lassen. Systemhäuser entwickeln ERP-Lösungen auf der Basis von etablierten
ERP-Standards (z.B. MS Dynamics NAV, ehemals Navision) eigene Gesamtkonzeptlösungen, sowohl für
Branchen und Marktbereiche als auch für Anwendungsfälle wie E-Commerce. Beispielhaft zu nennen wären zum
Beispiel Mac-IT, KatarGO. Sie setzen als Basis Microsoft Dynamics NAV voraus.
Ist eine solche ERP-Lösung in einem Unternehmen etabliert, dann ist der Anschluss des Kanals E-Commerce
weniger aufwändig und wird von einer einheitlichen Systemumgebung gestützt, so dass sich hier eine Abbildung
der positiven Effekte des All-In-One-Ansatzes ( Setup A) finden läßt.
Jedoch haben natürlich auch diese Konzepte ihre Grenzen in der Individualisierbarkeit und natürlich auch in den
Einschränkungen, die funktions- und performanzseitig mit dem verwendeten Basis-System einhergehen.
COMMERCE4 | E-Commerce Architekturen Seite: [24]
Ist das betreffende ERP bereits im Unternehmen verwendet oder soll ohnehin ein ERP neu eingeführt werden,
dann bleibt die Erweiterung E-Commerce einem meist akzeptablen Kostenrahmen. Allerdings ist eine solche
Konzeption wie die unter Setup C) nicht unabhängig von der Basis-IT-Lösung.
Ist im Unternehmen bereits eine andere ERP erfolgreich im Einsatz, dann ist diese Konzeption ein sehr
aufwändiger Ansatz, der zudem vielfältige Redundanzen schafft, weil die ERP-Basis-Funktionen in beiden
Systemen vorhanden sind und mit echten Daten arbeiten müssen. Hier ist im Detail eine aufwändige
Synchronisation nötig, die das Projektvolumen erheblich erhöhen kann.
• Geeignet für:
Unternehmen, die das passende ERP bereits einsetzen oder ohnehin ein ERP neu einführen wollen.
Hier ist es wichtig, sich über die notwendigen Anforderungen der Prozesse im Klaren zu sein, um den
Grad der notwendigen Individualisierung bestimmen zu können.
• Vorteile:
Die komplette Integration der E-Commerce-Prozesse in das ERP bei gleichzeitig freier Wahl des
Frontends ermöglicht einen hohen Grad der Zentralisierung.
• Nachteile:
Beschränkungen entstehen oft aus der Modulstandardisierung gegenüber individuellen Anforderungen
und funktionalen Beschränkungen des verwendeten Basis-ERP-Systems.
COMMERCE4 | E-Commerce Architekturen Seite: [25]
G) Systemkonzeption 7: Modulkomplexe aus unabhängigen Teilsystemen
Architekturen aus unabhängigen und über die Datenbasis in den Schnittstellen synchronisierte Teilsysteme sind
im Projektalltag erstaunlich oft anzutreffen. Diese entstehen durch das langsame Anwachsen von Prozessen, die
nicht als einheitliches Ganzes konzipiert werden. Für die einzelnen Prozessschritte werden zu einem
Einführungszeitpunkt Einzelsysteme eingeführt, die dann für den dann gültigen Nutzungsgrad mit Daten versorgt
werden müssen.
Die meisten unabhängigen Systeme verwalten Teile der Prozesskette, decken aber nicht einheitlich alles ab und
kommunizieren auf Schnittstellenbasis mit den anderen Teilmodulen. Hier ist die Komplexität der Verknüpfungen
allgemein recht hoch: Das PIM(Product Information Management)-System kommuniziert mit ERP und
Kanalsteuerung, diese mit dem Shop, beziehungsweise den Online-Kanälen, die wiederum mit dem Payment
Service Provider und der Auftragsverwaltung, und diese mit dem Lagerverwaltungssystem und so weiter...
Hier besteht die Herausforderung darin, den richtigen Modulmix zu erstellen, der die Prozesskette am besten
abdeckt und zugleich den geringsten Schnittstellenaufwand und Synchronisationsbedarf erzeugt. Zu beachten
ist, dass sich in einer solchen Konstellation Funktionen häufig überschneiden. Dies bringt gegebenenfalls
zusätzliche Komplexität in der Frage, welches System in welcher Funktion führt. Außerdem entstehen fast
zwangsläufig Redundanzen, was allerdings in der Regel zu beherrschen ist und sich nicht stark in Kosten
niederschlägt.
Ein Vorteil ist, dass die Teilsysteme unterschiedlichen Typs sein können, es können z.B. Software-as-a-Service
(SaaS) Angebote auch mit Open-Source-Teilsystemen verknüpft werden. Es können IT-Systeme erworben und
selbst gehostet werden, was für einige Unternehmen von hoher Bedeutung ist. Nachteil: Ein solches Konglomerat
aus unabhängigen Systemen ist hoch komplex, daher schwer zu handeln und mit einem hohen Aufwand an
Schnittstellenpflege verbunden.
COMMERCE4 | E-Commerce Architekturen Seite: [26]
• Geeignet für:
Unternehmen, die in einer eigenen IT ausreichend Ressourcen haben, um die unterschiedlichen
Teilsysteme administrieren und synchronisieren zu können.
• Vorteile:
Die schrittweise Umsetzung von Prozessen in Systeme erzeugt in jedem Einzelschritt geringere
Investitionsaufwände, weswegen gerade Unternehmen, die mit manuellen Prozessen starten, diesen
Weg gehen, um nach und nach mit dem Wachstum die Prozesse systemseitig zu unterstützen.
• Nachteile:
Der Aufwand, die Schnittstellen zu pflegen und zu synchronisieren, ist sehr hoch. Oft werden
Datenbestände in mehreren Systemen vorgehalten, bei denen klar definiert werden muss, welcher
Datenbestand zu welchem Zeitpunkt der aktuellste ist. Hiervon ausgehend ist die Synchronisation
einzurichten.
Wird darauf nicht geachtet und eine Synchronisation findet nicht statt, erfolgt die Arbeit mit
verschiedenen Datenbeständen bzw. Daten in verschiedenen Zuständen. Dies führt zu relevanten
Seiteneffekten wie z.B. möglichen Ausverkäufen, wenn Bestandswerte zwischen Teilsystemen nicht
synchronisiert sind.
Ein solches Konglomerat aus unabhängigen Systemen ist hoch komplex, daher schwer zu verwalten
und mit einem hohen Aufwand an Schnittstellenpflege und Administration verbunden.
H) Systemkonzeption 8: Prozesssteuerung in ESB/ Middleware Komplettlösungen.
Eine ESB (Enterprise Service Bus) ist definiert als ein Systemlayer, der den Datenaustausch zwischen den
angeschlossenen Systemen verwaltet. Durch die Lage zwischen den jeweiligen Peripherien wird dieser Layer
bzw. das diese Funktion ausfüllende System auch Middleware genannt. Beispiele für solche Lösungsansätze sind
etwa eFullfilment, commercetools oder auch plentymarkets.
Middlewarelösungen, die für E-Commerce angeboten werden, bieten weit über den Datenaustausch hinaus
reichende Funktionen mit einem hohen Automatisierungspotential: Sie verwalten für andere Teilsysteme den
Datenfluss, sammeln die Dateninhalte, übersetzen für die notwendigen Schnittstellen und leiten sie an die jeweils
richtige Stelle in den anderen Partnersystemen weiter. Die in der Middleware abgebildeten Prozesse sind an die
direkt ausführenden Systeme beim Mandanten angebunden.
COMMERCE4 | E-Commerce Architekturen Seite: [27]
Diese Lösung bietet den großen Vorteil gegenüber allen anderen genannten Systemkonzeptionen, dass sie sich
allen Anforderungen dynamisch anpassen lässt. Insbesondere sind nachgelagerte Teilsysteme, Prozesse und
deren Dienstleister relativ einfach ab- und anzukoppeln, ohne das Gesamtkonstrukt zu beeinträchtigen.
Da die Middleware als führendes System alle Prozesse im Griff hat und zwischen ihnen vermittelt, sind
Änderungen in einzelnen Prozessen unproblematisch.
• Geeignet für:
Unternehmen aller Geschäftsgrößen, insbesondere ideal für kleinere bis mittlere E-Commerce-
Aufgaben, in denen keine komplexe Eigen-IT die Aufgaben verwalten kann.
• Vorteile:
Middlewarelösungen vereinigen hohe Dynamik und individuelle Flexibilität mit der einheitlichen
zentralen Datenführung, die kennzeichnend für die kostenintensiven Lösungen A), B) und C) sind bei
weitaus geringeren Investitionsaufwänden.
• Nachteile:
Während Teilsysteme und Dienstleister einfach austauschbar sind, ist eine starke Bindung an die
Middleware/ ESB gegeben. Dabei sind die meisten Geschäftsmodelle der Anbieter SaaS-Modelle, die
oft transaktionsbasierte Komponenten oder Umsatzbeteiligungen in den Mietmodellen aufweisen.
COMMERCE4 | E-Commerce Architekturen Seite: [28]
Index
Architektur 7, 8, 9, 12, 15, 16, 20
Auftragsdaten 7, 21
B2B 15
B2C 11, 12, 16
BI 14
Call-Center 16, 22
CMS 11
Contenterstellung 15
Conversion 6, 13
CRM 13, 18, 22
Debitorik 8, 12, 13, 20
ebay 15
E-Commerce 1, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16,
17, 18, 20, 22, 23, 24, 26, 27
Einkaufsprozess 15
Einzelkommission 16
ERP 8, 9, 11, 12, 13, 15, 16, 18, 19, 20, 21, 23, 24,
25
ESB 12, 13, 16, 19, 20, 22, 26, 27
FIBU 12
Filiale 8, 9
Frontend 6, 13, 18, 20
Fulfillment 6, 8, 9, 20, 22, 23
Fullservice 22
Inkasso 12
IST-Aufnahme 15, 16
Kundendaten 7, 12, 21
Kundenservice 8, 13
Lagerlogistik 8
Lagerverwaltungssystem 12, 25
Logistik 7, 12, 13, 16, 22
LVS 12, 18
Mahnwesen 12
Marke 15
Marketing 6, 7, 13
Middleware 13, 16, 19, 22, 26, 27
Monitoring 13
Multichannel 9, 11, 13
Oligochannel 9
Onlineshop 9, 10, 11
Online-Shop 6, 13, 15
Open-Source 25
Payment 8, 12, 13, 20, 22, 25
PCI 12
Personalresourcen 15
PIM 5, 11, 15, 20, 21, 25
Polichannel 9
Produktdaten 7, 8
Prozesse 6, 8, 9, 10, 11, 15, 16, 17, 18, 19, 20, 23,
24, 26, 27
Prozessstrukturen 8, 17
Prozesstrukturen 20
PSP 12
Reporting 8, 12, 13
Restriktionen 15
Riskmanagement 12
SaaS 25
Schnittstellenformate 13, 15
Stammdaten 15
Synchronisationszeitpunkte 15
Systemarchitektur 7
Versandprozess 6
Warenwirtschaftssysteme 8
Zahlarten 12