Whitepaper E-Commerce Architekturen · COMMERCE4 | E -Commerce Architektu ren Seite: [6] Einleitung A) Der Eisberg-Effekt - 7/8 der Komplexität des digitalen Handels liegt im Verborgenen

COMMERCE4 | E-Commerce Architekturen Seite: [1]

Whitepaper

E-Commerce Architekturen

Komplexe Prozesslandschaften

Autor: André Menzel

Version: 1.3

Stadtlohn, 17.09.2014


A: Impressum

Herausgeber: COMMERCE4 GmbH

Dufkampstrasse 40

48703 Stadtlohn

Tel.: +49 (0) 2563 90 555 79

Fax.: +49 (0) 2563 90 555 76

[email protected]

www.commerce4.de

Ansprechpartner: Markus Weber

Geschäftsführender Gesellschafter

[email protected]

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.


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


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


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 -


Erweiterung PIM -


Erweiterung Performanz, Korrektur

-


Erweiterung Messe-ergebnisse 2014 und PIM

-


Erweiterung Projektergebnisse

-


Reworking Layouts

-


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


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.


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.


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.


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.


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


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)


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.


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.


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


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.


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


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.


• 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.


• 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.


• 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.


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


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.


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.


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.


• 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.


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.


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

Documents

Whitepaper E-Commerce Architekturen · COMMERCE4 | E -Commerce Architektu ren Seite: [6] Einleitung A) Der Eisberg-Effekt - 7/8 der Komplexität des digitalen Handels liegt im Verborgenen