3. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
4.3. OXID CE ............................................................................................................. - 98 -
4.3.1. Evaluierung .................................................................................................. - 99 -
4.4. Magento ............................................................................................................ - 103 -
4.4.1. Evaluierung ................................................................................................ - 104 -
4.5. Zusammenfassung der Evaluierung von xt:Commerce, OXID CE und Magento- 109
-
5. Fazit und Ausblick ................................................................................................. - 111 -
Anhang ........................................................................................................................... - 114 -
Literaturverzeichnis ...................................................................................................... - 115 -
-3-
4. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Anhangsverzeichnis
Anhang 1: Gartner TCO Modell ....................................................................................... - 114 -
-4-
5. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Abbildungsverzeichnis
Abbildung 1: E-Business und E-Commerce ........................................................................ - 9 -
Abbildung 2: Elektronische GeschÀftsbeziehungen .......................................................... - 10 -
Abbildung 3: Aggregator kombiniert Produkte und diktiert Preise ..................................... - 13 -
Abbildung 4: Struktur der B2C InternetumsÀtze in Deutschland ....................................... - 16 -
Abbildung 5: E-Commerce Schichtenpyramide ................................................................. - 19 -
Abbildung 6: E-Commerce Plattform ................................................................................. - 21 -
Abbildung 7: Beispielhafte Darstellung der E-Shop Softwarekomponenten ..................... - 22 -
Abbildung 8: Die zwei Dimensionen des Internets ............................................................ - 25 -
Abbildung 9: WertbeitrĂ€ge-Modell fĂŒr E-Shop Lösungen .................................................. - 29 -
Abbildung 10: Einsatz der E-Shop Distributionsmodelle in AbhÀngigkeit zum Wertbeitrag- 30
-
Abbildung 11: Auf die Entwicklung einer Softwarearchitektur wirkende Faktoren ............ - 34 -
Abbildung 12: Transaktionsphasen im B2C E-Commerce ................................................ - 41 -
Abbildung 13: Ein Modell fĂŒr Katalogdatenbereiche ......................................................... - 45 -
Abbildung 14: Optimierungsproblem von SicherheitsmaĂnahmen ................................... - 58 -
Abbildung 15: Risikomanagement Model .......................................................................... - 59 -
Abbildung 16: Die einzelnen Schritte des SchlĂŒsseltausch ............................................... - 64 -
Abbildung 17: Services zur Generierung von Werten ....................................................... - 67 -
Abbildung 18: Struktureller Aufbau des Evaluierungsmodells ........................................... - 76 -
Abbildung 19: Ăber- oder Untergewichtung von Zielkriterien je nach Betreibermodell ..... - 83 -
Abbildung 20: Systemlebenszyklus und relevante Kosten ................................................ - 86 -
Abbildung 21: Kosten der Anpassung einer E-Shop Software .......................................... - 88 -
Abbildung 22: Netz-Darstellung der StÀrken und SchwÀchen ........................................ - 110 -
Abbildung 23: E-Shops der Otto Group im Kontext zum BetreibermodellFehler! Textmarke
nicht definiert.
-5-
6. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Tabellenverzeichnis
Tabelle 1: GeschÀftsmodelle nach Tapscott, Ticoll und Lowy .......................................... - 12 -
Tabelle 2: B2C GeschÀftsmodelle nach dem Typ Aggregator .......................................... - 14 -
Tabelle 3: B2C E-Commerce Umsatzzahlen fĂŒr Deutschland im Vergleich in Mrd.⏠........ - 17 -
Tabelle 4: Trends und EinflĂŒssen mit Relevanz fĂŒr E-Shop Software ............................... - 26 -
Tabelle 5: Vergleich CSV-, EDI- und XML-basierter Datenformate .................................. - 38 -
Tabelle 6: Transaktionsphasen, AktivitÀten des Besuchers und E-Shop Funktionen ....... - 43 -
Tabelle 7: Sicherheitsmechanismen ................................................................................. - 60 -
Tabelle 8: Aufbau des Evaluierungsmodells ..................................................................... - 77 -
Tabelle 9: ErklÀrung zur Tabelle 8 .................................................................................... - 77 -
Tabelle 10: Ziel- und Hilfskriterien fĂŒr die Kategorie Architektur ....................................... - 79 -
Tabelle 11: Ziel- und Hilfskriterien fĂŒr die Kategorie Funktionen ....................................... - 80 -
Tabelle 12: Ziel- und Hilfskriterien fĂŒr die Kategorie Sicherheit ........................................ - 80 -
Tabelle 13: Zielkriterien fĂŒr die Kategorie Strategie .......................................................... - 80 -
Tabelle 14: Die Gewichtung der Zielkriterien-Kategorien .................................................. - 81 -
Tabelle 15: Die Gewichtung der Zielkriterien .................................................................... - 82 -
Tabelle 16: FĂŒr eine E-Shop Software relevante Kostenfaktoren ..................................... - 87 -
Tabelle 17: Serverdaten .................................................................................................... - 91 -
Tabelle 18: Links zu dem Front- und Back-Ends der E-Shops ......................................... - 91 -
Tabelle 19: Login Informationen ........................................................................................ - 91 -
Tabelle 20: Serveranforderungen der E-Shop Software ................................................... - 92 -
Tabelle 21: Ladezeiten-Test .............................................................................................. - 93 -
Tabelle 22: FĂŒr die Tests genutzte Dienstleister ............................................................... - 93 -
Tabelle 23: Bedingungen der Ladezeiten-Tests ................................................................ - 94 -
Tabelle 24: Ladezeitentest mit 100 Artikeln und vier Kategorien ...................................... - 94 -
Tabelle 25: Wertung der Zielkriterien-Kategorie Architektur von xt:Commerce ................ - 95 -
Tabelle 26: Wertung der Zielkriterien-Kategorie Funktionen von xt:Commerce ................ - 97 -
Tabelle 27: Wertung der Zielkriterien-Kategorie Sicherheit von xt:Commerce ................. - 97 -
Tabelle 28: Wertung der Zielkriterien-Kategorie Strategie von xt:Commerce ................... - 98 -
Tabelle 29: Wertung der Zielkriterien-Kategorie Architektur von OXID CE ....................... - 99 -
Tabelle 30: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE .................... - 102 -
Tabelle 31: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE .................... - 103 -
Tabelle 33: Teilnutzwerte der Zielkriterien ...................................................................... - 109 -
Tabelle 34: Teilnutzwerte der Zielkriterien-Kategorien und der Gesamtnutzwerte ......... - 110 -
Tabelle 35: Zielkriterien-Kategorien ohne die Gewichtung der Kategorien ..................... - 110 -
-6-
7. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
AbkĂŒrzungsverzeichnis
B2B Business to Business
B2C Business to Consumer
CE Community Edition
CMS Content Management Seite
CRM Customer Relationship Management
ERP Enterprise Resource Planning
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
SEO Search Engine Optimization
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
UDDI Universal Description, Discovery and Integration
URL Uniform Resource Locator
WSDL Web Service Description Language
-7-
8. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
1. Grundlagen von E-Shop Software
In diesem Kapitel werden Begriffe des elektronischen Handels abgegrenzt und nÀher
erlĂ€utert. Weiterhin werden die Grundlagen fĂŒr die Entwicklung des Evaluierungsmodells
gebildet. Es werden bestehende Theorien und ErklÀrungsansÀtze aus verschiedenen
Disziplinen herangezogen, um ein solides VerstĂ€ndnis fĂŒr das E-Commerce im allgemeinen
und E-Shop Software im Speziellen zu gewinnen.
1.1. Definition von E-Business und E-Commerce
Der Begriff Electronic Commerce wird sowohl in der wissenschaftlichen als auch in der
praxisorientierten Literatur seit Mitte der 90er Jahre diskutiert und sehr unterschiedlich
verwendet. 1 In einer frĂŒhen Phase des Internets wurde unter E-Commerce, der Verkauf von
Dienstleitungen und GĂŒtern ĂŒber elektronische Netzwerke verstanden. 2 In diesem Sinne wird
der Begriff E-Commerce von Herrmanns und Sauter auch als Electronic Shopping oder
Online Shopping bezeichnet. 3
Allerdings ist dieser Begriff damit sehr eng gefasst, um alle kommerziellen AktivitÀten des
Internets zu erfassen. In der Literatur schlagen deshalb eine Reihe von Autoren vor, den
Begriff E-Commerce weiter zu fassen und die UnterstĂŒtzung aller kommerzieller AktivitĂ€ten
wie GeschÀftsprozesse, GeschÀftstransaktionen, sowie die Beziehungen zu sÀmtlichen
internen und externen Partnern eines Unternehmens durch Informations- und
4
Kommunikationstechnologien in die Definition einzubeziehen. Nach dieser breiten Definition
umfasst der Begriff E-Commerce de facto jegliche kommerzielle AktivitÀt im Internet.
Da jedoch mit dem Einzelbegriff Commerce vordergrĂŒndig Handel gemeint ist, schlagen das
mcm Institute und PwC vor, fĂŒr alle kommerziellen AktivitĂ€ten im Internet den Begriff E-
Business zu verwenden: âE-Business ist die Integration von Systemen, Prozessen,
Organisationen, Wertschöpfungsketten und ganzen MÀrkten durch die Anwendung von
internetbasierten und âverwandten Technologien und Konzepten. Electronic Commerce ist
1
Vgl. Schmeken, 2007, S. 11; Choi / Stahl / Whinston, 1997, S. 1-4; Clement / Peters / PreiĂ, 1999,
S.49-53.
2
Vgl. Kalakota / Whinston, 1996, S. 1-3.
3
Vgl. Hermanns / Sauter, 1999, S. 14.
4
Vgl. Wigand, 1997, S. 5; Turban / McLean / Wetherbe, 1999, S. 3,5; StÀhler, 2002, S. 53; Haertsch,
2000, S. 13;
-8-
9. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
demnach ein Teilbereich von E-Business und beschrÀnkt sich im Wesentlichen auf die
Marketing- und Verkaufsprozesse.â 5
In diesem Sinne, findet sich laut Heinemann, der Online Handel im GeschÀftskonzept E-
Commerce wieder, weil hier die Anbahnung, Aushandlung und Abwicklung von
geschĂ€ftlichen Transaktionen ĂŒber Netzwerke erfolgt, d.h. dass ein Leistungsaustausch
zwischen Marktteilnehmern mit Hilfe öffentlicher oder privater Netzwerke, wie dem Internet,
mit dem Ziel der Wertschöpfung stattfindet. 6
Die nachfolgende Abbildung 1 stellt die Unterscheidung von E-Business und E-Commerce
dar und setzt diese gleichzeitig in Relation zu elektronischen GeschÀftsbeziehung.
Business to Business (B2B) Business to Concumer (B2C)
GeschÀftspartner Extranet Unternehmen Internet Kunde
E-Commerce E-Commerce
E-Business
Abbildung 1: E-Business und E-Commerce 7
1.2. Elektronische GeschÀftsbeziehungen
FĂŒr die systematische Ableitung der Einsatzmöglichkeiten des E-Commerce, bietet sich die
nachfolgende Abbildung 2 an, die neun Markt- und Transaktionsbereiche beschreibt. Damit
werden die drei wichtigsten Gruppen von Marktteilnehmern und ihre möglichen
GeschÀftsverbindungen dargestellt.
5
mcm institute & PwC, 1999, S. 4.
6
Heinemann, 2009, S. 27.
7
In Anlehnung an StÀhler, 2002, S. 54.
-9-
10. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Nachfrager der Leistung
Consumer Busines Administration
Consumer
Consumer to Business Consumer to Administration
Consumer to Consumer
Z.B. Jobbörsen mit Anzeigen von Z.B. Steuerabwicklung von
Z.B. Internet-Kleinanzeigenmarkt
Arbeitssuchenden Privatpersonen
Business to Business
Anbieter Business to Consumer Business to Administration
Busines
der Z.B. Bestellung eines
Z.B. Bestellung eines Kunden bei Z.B. Steuerabwicklung von
Leistung einem E-Shop
Unternehmens bei einem
Unternehmen
Zulieferer
Administration
Administration to
Administration to Consumer Administration to Business
Administration
Z.B. Abwicklung der Z.B. Beschaffung von
z.B. Transaktionen zwischen
Einkommenssteuer Lizenzrechten bei Behörden
Behörden
Abbildung 2: Elektronische GeschÀftsbeziehungen 8
Als Anbieter und Nachfrager einer Leistung können sowohl private Konsumenten
(Consumer), Unternehmen (Business) als auch öffentliche Institutionen (Administration)
auftreten.
Mit Business to Consumer (B2C) und Business to Business (B2B), bieten Unternehmen
Produkte und Dienstleistungen fĂŒr Kunden oder weitere Unternehmen an. Auf diese beiden
Bereiche geht der GroĂteil der UmsĂ€tze zurĂŒck. 9
Weitere Austauschbeziehungen gehen von der öffentlichen Hand (Administration) aus und
fĂŒhren zu weiteren Optionen A2A, A2B und A2C. Bei Administration to Administration
werden Kommunikation- und Informationstechnologien verwendet, um verwaltungsinterne
AblÀufe elektronisch zu gestalten. Dies kann innerhalb einer oder zwischen mehreren
Verwaltungsebenen geschehen. AuĂerdem können Behörden Angebote an BĂŒrger (A2C)
oder Unternehmen (A2B) richten.
Personen können grundsÀtzlich sowohl als Leistungsanbieter als auch als
Leistungsnachfrager auftreten. Die Option C2C (Consumer to Consumer) beschreibt eine
elektronische GeschĂ€ftsbeziehung zwischen Einzelpersonen, wie sie beispielsweise ĂŒber
elektronische MarktplÀtze zustande kommen kann. Des Weiteren können Personen auch
Leistungen fĂŒr Unternehmen oder Verwaltungseinheiten erbringen.
8
In Anlehnung an Hermanns / Sauter, 1999, S. 23.
9
Vgl. Hermanns / Sauter, 1999, S. 22.
- 10 -
11. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
1.3. GeschÀftsmodelle im E-Business und E-Commerce
Der Begriff des GeschÀftsmodells im E-Business wird in der Literatur sehr uneinheitlich
verwendet. 10 Folglich fehlt auch eine allgemein anerkannte Definition. Nach Wirtz, definiert
ein E-Business GeschÀftsmodell die Schwerpunkte von Unternehmungen und ihrer
Erlöserzielung. Timmers schlĂ€gt dazu die folgende Definition vor: âA business model is
defines as the organization (or architecture) of product, service and information flows, and
the sources of revenues and benefits for suppliers and customers.â 11 Nach Trimmers
Definition, beschreibt ein GeschÀftsmodell im E-Business also Organisationsstrukturen, die
Erlöserzielung und Vorteile, die sich fĂŒr Anbieter und Kunde ergeben.
Ein GeschÀftsmodell erlaubt es in einer sehr vereinfachten und zusammengefassten Weise,
die fĂŒr eine Unternehmung einflieĂenden Ressourcen und die Transformation zu
vermarktungsfÀhigen Produkten und Dienstleistungen darzustellen. Aus einem
GeschĂ€ftsmodell geht die Kombination der Produktionsfaktoren hervor, die fĂŒr die
Umsetzung der GeschÀftsstrategie notwendig ist. Weiterhin werden auch die Rollen
einzelner Akteure beschrieben. GrundsÀtzlich werden in der Literatur eine Vielzahl
unterschiedlicher E-Business GeschÀftsmodelle beschrieben. Allerdings entwickelt sich der
E-Business Markt auch fortwÀhrend weiter und verhÀlt sich dynamisch, weswegen
kontinuierlich neue GeschÀftsmodelle entstehen und alte an Bedeutung verlieren.
Timmers identifiziert elf E-Business GeschÀftsmodelle, die in der Literatur vielfach
12
aufgegriffen werden. Rappa beschreibt neun E-Business GeschÀftsmodelle aus der
Perspektive der Umsatzgenerierung. 13 Im Folgenden werden fĂŒnf fĂŒr das E-Business
relevante GeschÀftsmodelle nach Tapscott, Ticoll und Lowy beschrieben, die sich durch ihre
hohe Abstraktion und BeschrÀnkung auf grundlegende Prozesse von denen anderer Autoren
im Bereich des E-Business unterscheiden und wesentlich weniger unter dem Einfluss von
Modeerscheinungen stehen.
Die folgende Tabelle stellt eine Ăbersicht der fĂŒnf Typen nach Tapscott, Ticoll und Lowy dar,
die anschlieĂend nĂ€her erlĂ€utert werden, wobei nur der Typ Aggregator in seinem Wesen,
eine reine B2C E-Commerce GeschÀftsbeziehung beschreibt und daher detaillierter erlÀutert
wird. 14
10
Vgl. Wirtz, 2001, S. 210f.
11
Vgl. Timmers, 1999, S. 31.
12
Vgl. Timmers, 1998, S. 3-7.
13
Vgl. Rappa, 18.12.2009.
14
Vgl. Tapscott / Ticoll / Lowy, 1999, S. 198-208.
- 11 -
12. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Agora Aggregator Integrator Allianz Distributor
Ziel- Marktplatz fĂŒr Digitaler Optimierte selbst organi- Austausch von
setzung Waren und Supermarkt Wertschöpfung sierender Informationen,
Werte skette Wert- Waren und
schöpfungs- Diensten
raum
Merk- § Markt- § Auslage von § gezielte § Innovation § Netz-
male information Produkten Lieferanten- § Vertrauensbil optimierung
§ Verhandlung § fester Preis auswahl dung § unein-
sprozess § einfache § Prozess- § Verzicht auf geschrÀnkte
§ dynamische ErfĂŒllung optimierung hierarchische Nutzung
Preisfindung § Produkt- Kontrolle § Logistik-
integration prozess
Kunden- Markt- KÀufer Wertmotor Beitragender EmpfÀnger
rolle teilnehmer
Nutzen Verhandelbare Bequeme Kundenspezifis Kreative und Zeitgerechte
Marktleistung Auswahl und ches Produkt gemeinschaftli Lieferung
ErfĂŒllung che Lösung
Tabelle 1: GeschÀftsmodelle nach Tapscott, Ticoll und Lowy 15
Der aus der Antike stammende Begriff Agora, ist ein elektronischer Marktplatz auf dem
KĂ€ufer und VerkĂ€ufer zusammenkommen, um ĂŒber die angebotenen GĂŒter und Preise zu
verhandeln. Demnach, gehört die dynamische Preisfindung zu den Hauptmerkmalen. Des
Weiteren können unterschiedliche Anbieter Produkte und Dienstleistungen offerieren,
weswegen das Angebot theoretisch sehr vielfÀltig und nicht vorhersehbar sein kann. Indes
ist die Werteintegration vergleichbar eingeschrÀnkt, wobei gleichzeitig die Marketing und
Vertriebskosten gering ausfallen. 16
Ein Integrator kontrolliert eine Wertschöpfungskette mit allen seinen Komponenten in Form
externer Partner und integriert ihre WertbeitrÀge. Damit kontrolliert der Integrator die
Gestaltung des Produktes bzw. der Dienstleistung, indem er unterschiedliche Hersteller zu
einer Wertschöpfungskette zusammenfĂŒgt. Der AnstoĂ geht i.d.R. vom Kunden aus, der eine
komplexe und individuelle Lösung nachfragt. 17
Eine Allianz besteht aus eigenstÀndigen in einer Gemeinschaft organisierten Partnern, die
gemeinsame Lösungen entwickeln. Mitglieder des Netzwerks bringen ihr spezifisches Know-
15
Vgl. Tapscott / Ticoll / Lowy, 1999, S. 198.
16
Vgl. Meier / Stormer, 2008, S. 35.
17
Vgl. Meier / Stormer, 2008, S. 35-37.
- 12 -
13. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
how ein und agieren innerhalb des Netzwerkes sowohl als Nachfrager als auch als
Anbieter. 18
Ein Distributor gewÀhrleistet einen Austausch von Dienstleistungen, Waren und
Informationen. Damit stellt er ein Verteilungsnetzwerk zur Bedienung unterschiedlicher
Anbieter und Nutzer dar. 19
Aggregatoren ĂŒbernehmen eine Vermittlerfunktion zwischen Endkunden und
Warenlieferanten, wobei der Warenlieferanten i.d.R GroĂhĂ€ndler oder Hersteller ist. Der
Aggregator wĂ€hlt die Produkte und Dienstleistungen, entscheidet ĂŒber die Preise und
20
kontrolliert die Abwicklung. Die folgende Abbildung stellt die Konstellation eines
Aggregators abstrakt dar.
Hersteller
KĂ€ufer
Hersteller
Aggregator KĂ€ufer
Hesteller
KĂ€ufer
Abbildung 3: Aggregator kombiniert Produkte und diktiert Preise
Dabei greift der Aggregator auf mehrere Hersteller zurĂŒck und bietet insgesamt eine groĂe
Auswahl an Produkten bzw. Dienstleistungen an. Zu den Kernfunktionen gehört damit die
Auslage der Produkte fĂŒr den Kunden, der seinen Nutzen aus der bequemen
Auswahlmöglichkeit und ErfĂŒllung zieht. Aus der ErfĂŒllung der reinen Vermittlerfunktion geht
allerdings nur eine geringe Werteintegration hervor.
Der Aggregator hat nach Meier und Stormer folgende Vorteile: 21
18
Vgl. Meier / Stormer, 2008, S. 36-38.
19
Vgl. Meier / Stormer, 2008, S. 36-38.
20
Vgl. Meier / Stormer, 2008, S. 37.
21
Vgl. Meier / Stormer, 2008, S. 34-37.
- 13 -
14. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
§ GroĂe Verhandlungsmacht: Dem Aggregator obliegen die Produktauswahl und die
Bestimmung der Preiskonditionen
§ Einsatz digitaler Berater: Softwareagenten helfen bei Such- und VergleichsvorgÀngen
und erfĂŒllen eine Beratungsfunktion
§ UnabhÀngige Produktbewertung: Vor- und Nachteile von Produkten werden von den
Kunden erfasst und durch den Aggregator als Entscheidungshilfe publiziert
§ Stimulierung des Verkaufs: ProduktbĂŒndelungen, Cross-Selling MaĂnahmen und
diverse andere Instrumenten der Promotion können realisiert werden
Da im Kern Produkte bzw. Dienstleistungen von Unternehmen (Business) an Konsumenten
(Consumer) weitergereicht werden, eignet sich der Typ Aggregator seiner Definition nach fĂŒr
die Beschreibung von B2C E-Commerce GeschÀftsmodellen, die im Fokus der
nachfolgenden Arbeit stehen.
GrundsÀtzlich können die Funktionen des Aggregators, wie nach Tapscott, Ticoll und Lowy
definiert, in der Praxis von verschiedenen Typen von Unternehmen erfĂŒllt werden. Laudon
und Traver identifizieren vier B2C E-Commerce GeschÀftsmodelle, die in der folgenden
Tabelle dargestellt werden und dem Typ Aggregator entsprechen: 22
Variation Beschreibung Beispiele
Internet Pure Player HĂ€ndler, die nur das Internet als Amazon.com
Absatzkanal nutzen Notebooksbilliger.de
EinzelhÀndler- EinzelhÀndler, die das Internet als Walmart.com
Versender zusÀtzlichen Absatzkanal nutzen Schlecker.de
KataloghÀndler- KataloghÀndler, die das Internet als Otto.de
Versender zusÀtzlichen Absatzkanal nutzen Neckermann.de
Hersteller- Hersteller, die ihre Produkte ĂŒber das Dell.com
Versender Internet direkt an Endkonsumenten Sony.com
vertreiben
Tabelle 2: B2C GeschÀftsmodelle nach dem Typ Aggregator 23
Diese praxisnahe Sicht gibt bereits einen Hinweis darauf, dass ursprĂŒnglich E-Commerce
fremde Unternehmen, das Internet als weiteren Absatzkanal nutzen.
Als Internet Pure Player werden Unternehmen bezeichnet, die ausschlieĂlich das Internet als
Vertriebskanal nutzen. Oftmals sind diese Unternehmen auf bestimmte Marktsegmente
konzentriert und können flexibel auf VerÀnderungen reagieren. 24
22
Vgl. Laudon / Traver, 2009, S. 2,14- 2,17.
23
In Anlehnung an Laudon / Traver, 2009, S. 2,14- 2,16.
24
Vgl. Heinemann, 2009, S. 69.
- 14 -
15. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Im Zuge der zunehmenden Verbreitung des Internets haben auch EinzelhÀndler und
KataloghÀndler ihre Unternehmensstrategie angepasst und das Internet als Absatzkanal
entdeckt. Da diese Unternehmen mindesten zwei AbsatzkanÀle nutzen, werden sie auch als
Multi-Channel HĂ€ndler bezeichnet. 25 Allerdings gibt es auch den umgekehrten Fall, dass ein
ursprĂŒnglicher Internet Pure Player im EinzelhandelsgeschĂ€ft aktiv wird und damit ebenfalls
der Kategorie Multi-Channel Handel zugeordnet werden kann.
Die Hersteller Versender zeichnen sich durch die Beherrschung der kompletten Supply-
Chain aus und nutzen den Online Handel als Instrument zur vertikalen Integration, indem sie
das Internet als Direktvertriebskanal verwenden. 26
Neben diesen Unternehmenstypen lassen sich insbesondere zwei innovative
AusprÀgungstypen des Aggregators identifizieren, die insbesondere auf Internet Pure Player
zurĂŒckgehen, aber auch verstĂ€rkt von anderen Marktteilnehmern adaptiert werden:
§ Liveshopping: Eine sehr begrenzte Produktpalette, in aller Regel nur ein Produkt, fĂŒr
einen begrenzten Zeitraum, in aller Regel nur fĂŒr einen Tag, zu einen sehr deutlich
reduzierten Preis angeboten. Das Konzept wurde inzwischen von einer Vielzahl von
etablierten Unternehmen wie z.B. Otto mit dem HAPPY PREIS des Tages, LIDL mit
Highlight des Tages und QVC mit Tagesangebot ĂŒbernommen, die jeweils ein
Produkt pro Tag besonders gĂŒnstig anbieten. Als allgemein bekannte Beispiele reiner
Liveshopping Unternehmen können die iBOOD GmbH 27 oder die Live Shopping
GmbH 28 genannt werden.
§ Clubverkauf: Der Besucher muss sich zunÀchst anmelden, bevor ihm Einblick in das
Produktsortiment gewÀhrt wird, wobei die Zahl der möglichen Anmeldungen begrenzt
ist. Die ExklusivitÀt steht im Vordergrund. 29 Die Verkaufsaktionen sind zeitlich
begrenzt. Ăblich sind fĂŒnf Aktionen je Woche, die jeweils ĂŒber ein bis zwei Tage
gehen. 30 Als allgemein bekannte Beispiele reiner ClubverkÀufer können die Private
Sale GmbH oder BuyVIP GmbH geannt werden. 31
1.4. Entwicklung des B2C E-Commerce
Der GroĂteil der UmsĂ€tze des Online Handels ist auf die Bereiche B2B und B2C
zurĂŒckzufĂŒhren. Da jedoch alleine der B2C fĂŒr diese Arbeit von Interesse ist, werden andere
Marktzahlen vernachlÀssigt.
25
Vgl. Heinemann, 2009, S. 70.
26
Vgl. Heinemann, 2009, S. 75.
27
Vgl. iBOOD GmbH, 20.02.2010.
28
Vgl. Live Shopping GmbH, 20.02.2010.
29
Vgl. Heinemann, 2009, S. 69.
30
Vgl. Heinemann, 2009, S. 69.
31
Vgl. Krisch, 20.02.2010.
- 15 -
16. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
GrundsÀtzlich werden in Deutschland sehr unterschiedliche Marktzahlen seitens
verschiedener Organisationen publiziert, die unterschiedliche Detailgrade und
Betrachtungsweisen aufweisen und z.T. im Kontrast zueinander stehen, wie die
nachfolgende Untersuchung nÀher erlÀutert.
Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.
(BITKOM) weist fĂŒr 2006 einen B2C Online Umsatz in Deutschland von 46 Mrd. EUR aus
und gibt eine durchschnittliche Wachstumsrate von 33 Prozent zwischen 2004 und 2007
an. 32 FĂŒr das Jahr 2010 wird ein Umsatz von 145 Mrd. EUR prognostiziert. 33
Die
Gesellschaft fĂŒr Konsumforschung (GfK) weist fĂŒr das gleiche Jahr einen Umsatz von nur
15,4 Mrd. EUR aus. 34 Aufgrund der deutlichen Unterschiede soll hier ein kurzer direkter
Vergleich erfolgen.
Anders als bei den BITKOM Zahlen, berĂŒcksichtigen die GfK Umsatzzahlen keine Online
ReiseumsÀtze, Online Kraftfahrzeug UmsÀtze und weitere Bereiche, wie Online Apotheken
und kommerzielle Onlineinhalte. 35 Zieht man jedoch auch diese Umsatzzahlen in Betracht,
dann ergibt sich ein schlĂŒssigeres Bild, wie die nachfolgende Abbildung zeigt.
Sonstiges:
§ Pharma Kraftfahrzeug
Online-Einzelhandel § kostenpflichtiger Online-Handel Online-Reisen
Content (z.B. online
Zetungsartikel)
46 Mrd.âŹ
15,4 Mrd.⏠14,2 Mrd.⏠8,4 Mrd.⏠8 Mrd.⏠B2C-Umsatz
Deutschland 2006
Abbildung 4: Struktur der B2C InternetumsÀtze in Deutschland 36
Wie Tabelle 3 zeigt, weisen trotz der sehr unterschiedlichen Marktzahlen, alle aufgefĂŒhrten
Organisationen eine zweistellige jÀhrliche Wachstumsrate auf. Online einkaufen wird immer
beliebter. 2008 haben 42 Prozent der Deutschen im Internet Waren oder Dienstleistungen
bestellt. 37 Aufgrund dieser schnellen Marktentwicklung bezeichnet Heinemann das Internet
32
Vgl. BITKOM, 18.02.2010.
33
Vgl. BITKOM, 18.02.2010.
34
Vgl. GfK, 14.02.2010, S. 2.
35
Vgl. Heinemann, 2009, S. 69.
36
In Anlehnung an Heinemann, 2009, S. 10.
37
Vgl. BITKOM, 2009, S. 11.
- 16 -
17. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
auch als Vertriebskanal mit der höchsten Wachstumsdynamik, der inzwischen einen
Massenmarkt bildet. 38
2003 2004 2005 2006 2007 2008 JĂ€hrliche
Wachstumsrate
39
BITKOM 22 32 46 27,87%
40
GfK 5,8 7,6 9 10,2 11,4 13,6 15,26%
HDE 41 11 13 14,5 16,3 18,3 20 10,48%
bvh 42 3,6 5,3 7,4 10 10,9 13,4 24,49%
Tabelle 3: B2C E-Commerce Umsatzzahlen fĂŒr Deutschland im Vergleich in Mrd.âŹ
Ăber den Markt fĂŒr technische Lösungen fĂŒr die Nutzung des B2C E-Commerce liegen keine
zuverlÀssigen Zahlen vor, was einerseits auf die Intransparenz des Marktes und andererseits
auf den komplexen Kostenbegriff 43 zurĂŒckzufĂŒhren ist. Zudem mĂŒssen alleine fĂŒr die
Bereitstellung einer E-Shop Software u.U. Leistungen unterschiedlicher Unternehmen in
Anspruch genommen werden. 44 AuĂerdem besteht eine E-Commerce Plattform aus sehr
unterschiedlichen Komponenten, wie die nachfolgenden Kapitel nÀher erlÀutern werden.
Dadurch wird die Erfassung monetĂ€rer GröĂen ungleich schwieriger.
Allerdings weisen die genannten B2C Marktzahlen indirekt auf eine hohe Nachfrage nach
technischen E-Commerce Lösungen hin. Diese Vermutung wird durch eine Umfrage von
Forrester Research bestÀtigt, die zu dem Ergebnis kommt, dass im Jahr 2009 26 Prozent
aller befragten Unternehmen beabsichtigten eine neue E-Shop Software einzusetzen oder
die bestehende deutlich weiterzuentwickeln. Trotz Finanzkrise, haben nur vier Prozent aller
befragten Unternehmen geplant ihre Investitionen in eine E-Shop Software zurĂŒckzufahren. 45
1.5. E-Commerce Plattform
In der Literatur wird zwischen verschiedenen Plattformen im E-Business unterschieden.
Sowohl Kollmann als auch Roumois schlagen mit E-Procurement, E-Shop, E-Community
38
Vgl. Heinemann, 2009, S. 11.
39
Vgl. BITKOM, 18.02.2010.
40
Vgl. GfK, 14.02.2010, S. 2.
41
Vgl. HDE, 14.02.2010.
42
Vgl. Bundesverband des Deutschen Versandhandels e.V., 26.12.2009.
43
Vgl. Kapitel 4.5.
44
Vgl. Kapitel 2.9.
45
Vgl. Forrester Research, 2009b, S. 4.
- 17 -
18. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
und E-Marketplace eine Unterscheidung von vier Plattformen fĂŒr die Abwicklung von
elektronischen GeschÀftsprozessen vor. 46
E-Procurement bezieht sich auf den Einkauf von Produkten und Dienstleistungen durch
Unternehmen. Als zentrale Plattform erlaubt es die Integration von Kommunikations- und
Informationstechnologien, um die elektronische Abwicklung bzw. UnterstĂŒtzung in der
Beschaffung, möglich zu machen. 47
E-Marketplace bezeichnet einen elektronischen Marktplatz auf dem KÀufer und VerkÀufer
zusammenkommen, um ĂŒber die angebotenen GĂŒter und Preise zu verhandeln. 48 Demnach,
gehört die dynamische Preisfindung zu den Kernprozessen eines E-Marketplaces.
Eine E-Community ermöglicht den Kontakt zwischen Personen bzw. Institutionen ĂŒber
elektronische KanÀle durch die Integration innovativer Kommunikationstechniken. Diese
Plattform dient primÀr dem Wissens- und Datenaustausch. 49
Ein E-Shop ermöglicht den elektronischen Vertrieb von Produkten und Dienstleistungen.
Damit geht eine âIntegration innovativer Informations- und Kommunikationstechnologien zur
UnterstĂŒtzung bzw. Abwicklung von operativen taktischen und strategischen Aufgaben im
Absatzâ einher. 50 Ein E-Shop kann als ein virtueller Verkaufsraum beschrieben werden und
als ein eigenstÀndiges System aus Hard- und Software beschrieben werden, das einem
51
HĂ€ndler erlaubt, seine WirtschaftsgĂŒter ĂŒber Rechnernetze anzubieten. Das Gabler
Wirtschaftslexikon bezeichnet E-Shops in diesem Zusammenhang auch als Plattform, âauf
der Anbieter ihre Waren oder Dienstleistungen prÀsentieren und der Interessent die
Handhabe besitzt, Produktinformationen einzuholen.â 52
Allerdings muss hier kritisch angemerkt werden, dass diese in der Literatur verbreitete
Unterscheidung der Plattformen E-Shop und E-Community z.T. im Widerspruch zur Praxis
steht, da es durch den Web 2.0 Trend und hier insbesondere der Zunahme von User
Generated Content, 53 es zur Entwicklung hybrider Modelle gekommen ist. 54 Als Beispiele
55
können die Integration von E-Shops in die E-Community Plattform Facebook oder
46
Vgl. Kollmann, 2007, S. 38; Roumois, 2007, S. 99.
47
Vgl. Meier / Stormer, 2008, S. 34.
48
Vgl. Meier / Stormer, 2008, S. 34.
49
Vgl. Kollmann, 2007, S. 39-41.
50
Kollmann, 2007, S. 165.
51
Vgl. ZwiĂler, 2002, S. 32, S. n. zitiert nach Kollmann, 2007, S. 189, S. m. .
52
Gabler Wirtschaftslexikon, 12.02.2010.
53
Vgl. Kapitel 2.8.
54
Vgl. Hahn, 08.12.2009.
55
Vgl. Wauters, 08.12.2009.
- 18 -
19. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
andersherum die umfangreichen E-Community Funktionen in den E-Shops der Internetstores
AG 56 und Kolibrishop GmbH 57 genannt werden.
Die fĂŒr den B2C E-Commerce relevante Plattform ist, analog zum GeschĂ€ftsmodell Typus
Aggregator, der E-Shop, da nur dieser auf einen reinen B2C Handel fokussiert ist.
Gleichwohl ist nach Definition auch auf der Plattform E-Marketplace ein B2C Handel möglich,
was dem Typ Agora entsprechen wĂŒrde. Allerdings sind E-Marketplaces fĂŒr den B2C in der
Praxis fĂŒr mittelstĂ€ndische und insbesondere GroĂunternehmen von minimaler Relevanz.
Dies ist insbesondere auf ImagegrĂŒnde und dem daraus resultierenden Boykott seitens
Markenherstellern zurĂŒckzufĂŒhren. 58 Alle nachfolgenden AusfĂŒhrungen beziehen sich somit
auf die Plattform E-Shop.
Nach Kollmann besteht jede Plattform aus weiteren Bausteinen, die betriebswirtschaftlicher
und technischer Natur sind, und zwanglĂ€ufig fĂŒr die Umsetzung notwendig sind. Demnach
stellt die Plattform E-Shop, ein Fundament fĂŒr Technologien und Produkte dar. 59 Laudon und
Traver beschreiben eine praxisorientiertere Sichtweise aus der Perspektive eines Betreibers
und identifizieren sechs Komponenten, aus denen eine E-Shop Plattform bestehen kann:
Hardware Architektur, Software, Telekommunikations-Infrastruktur, Site-Design, personelle
60
Ressourcen und organisatorische Ressourcen. Diese sechs Komponenten stehen
grundsÀtzlich in gegenseitiger AbhÀngigkeit zueinander, wobei ein wesentlicher Einfluss von
der Wahl der E-Shop Software ausgeht.
Internet-
verbindung
E-Shop
Software
Server Software
Server Betriebssystem
Web Server Hardware
Abbildung 5: E-Commerce Schichtenpyramide 61
Eine Betrachtungsweise nach Reynolds und Stair fĂŒhrt, mit den technischen
SchlĂŒsselkomponenten Server Hardware, Server Betriebssystem, Server Software und E-
56
Vgl. internetstores AG, 08.12.2009a; vgl. internetstores AG, 08.12.2009b.
57
Vgl. Kolibrishop GmbH 08.12.2009.
58
Vgl Krisch, 20.02.2010; Greif, 20.02.2010; Höschl, 20.02.2010.
59
Vgl Loshin / Vacca, 2005, S. 3.
60
Vgl Laudon / Traver, 2009, S. 4,5f
61
In Anlehnun an Reynolds / Stair, 2003, S. 192.
- 19 -
20. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Shop Software, zu einer vier schichtigen pyramidenartigen Gliederung, wie Abbildung 5
zeigt. 62 Die E-Shop Software bildet dabei die oberste Schicht der E-Commerce Plattform und
steht im Mittelpunkt der nachfolgenden Arbeit.
1.6. E-Shop Software
Das vorherige Kapitel 2.5 und insbesondere die darin aufgefĂŒhrten Betrachtungsweisen nach
Laudon und Traver, sowie Reynolds und Staire, weisen bereits daraufhin, dass die E-Shop
Software zu den Hauptbestandteilen einer E-Shop Plattform gehört. Mit der Definition der E-
Shop Plattform wurde somit auch ein Teil der Definition der E-Shop Software bereits vorweg
genommen.
FĂŒr alle weiteren AusfĂŒhrung, wird der E-Shop Besucher, d.h. also der potentielle online
Besteller, als Endkunde bezeichnet. Das in Kapitel 2.3 als Aggregator definierte
Unternehmen, das ein E-Shop fĂŒr die Teilnahme am online Handel betreibt wird nachfolgend
als E-Shop Betreiber bezeichnet.
Im Unterschied zu den anderen nach Reynold und Stair definierten Bausteine einer E-Shop
Plattform, wie z.B. der Server Hardware, sieht der Endkunde die E-Shop Software bzw.
dessen Front-End 63 und fĂŒhrt ĂŒber diese Transaktionen aus. Somit nimmt der Endkunde
subjektiv auch nur die E-Shop Software bzw. dessen Front-End direkt wahr. Daher
bezeichnet Tassabehji eine E-Shop Software auch als Schnittstelle zwischen E-Shop
Betreiber und Endkunde. 64
In der Literatur werden unterschiedliche Begriffe zur Bezeichnung von E-Shop Software
verwendet. Verbreitet sind insbesondere die aus dem englischen ĂŒbernommenen
Bezeichnungen Online Shop Software, Shopping Cart Software, Shopsystem oder Webshop.
Seltener wird der abstraktere Begriff E-Commerce Software verwendet. Der Begriff
Shopsystem kann folglich als Synonym fĂŒr E-Shop Software verwendet werden.
Goluchowski, Filipczyk und Malgotzta definieren drei Kernaufgaben einer E-Shop Software: 65
§ Ăbermittlung und Austausch von Informationen
§ Kommunikation
§ Verkaufstransaktion
Die Ăbermittlung und der Austausch von Informationen können beispielsweise durch einen
Newsletter oder eine Produktbewertung erfolgen. Als Beispiele fĂŒr kommunikative
62
Vgl Reynolds / Stair, 2003, S. 3.
63
Vgl. Kapitel 2.7.
64
Vgl Tassabehji, 2005, S. 102.
65
Vgl. Goluchowski / Filipczyk / Jablonska, 2007, S. 16f.
- 20 -
21. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Funktionen können u.a. ein Kontaktformular oder Live Chat mit dem Service, genannt
werden. Verkaufstransaktionen können z.B. mit Hilfe eines virtuellen Warenkorbes oder einer
Bezahlfunktion realisiert werden.
Nach Reynolds und Stair bilden die Elemente Katalog, Kunden und GeschÀftsprozesse den
Kern einer E-Shop Software, wie die Abbildung 6 darstellt. Folglich gehören typischerweise
mindestens das Produktkatalogmanagement, Kundenmanagement und die zugehörigen
GeschÀftsprozesse zur Abwicklung von Transaktionen zu den Komponenten einer E-Shop
Software. 66
Katalog Kunden
GeschÀftsprozesse
Abbildung 6: E-Commerce Plattform
Die Funktionen können von einer oder mehreren Softwares erfĂŒllt werden. 67 Der Betreiber
muss die Möglichkeit haben, die GeschÀftsprozesse nach Bedarf zu modellieren und zu
automatisieren, wie viele unterschiedliche Softwares eingesetzt werden mĂŒssen, hĂ€ngt von
dem individuellen Bedarf ab.
Im Mittelpunkt steht jedoch stets eine zentrale Software, die in allen weiteren AusfĂŒhrungen
als E-Shop Software bezeichnet wird, da alle weiteren E-Shop Softwarekomponenten i.d.R.
ihr angehÀngt werden oder zumindest in direkter AbhÀngigkeit zu ihr stehen. Jede durch
einen Endkunde elektronisch angestoĂene Transaktion geht prinzipiell von der E-Shop
Software aus.
66
Vgl. Reynolds / Stair, 2003, S. 193.
67
Vgl. Illik, 2002, S. 131.
- 21 -
22. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
1.7. E-Shop Softwarekomponenten
Eine E-Shop Software besteht i.d.R. aus verschiedenen Komponenten. 68 In diesem Sinne,
wird insbesondere in der amerikanischen Literatur manchmal auch die Begriff Softwaresuite,
d.h. also zu Softwaresammlung, gebraucht. 69 Wodurch deutlicher darauf hingewiesen wird,
dass eine E-Shop Software aus einer Vielzahl von Komponenten bestehen kann. Allerdings
wird in der Literatur oftmals nicht nÀher diskutiert, ob diese sog. Komponenten in der Praxis
integrierte Bestandteile der E-Shop Software oder z.B. eigenstÀndige Software mit
entsprechenden Schnittstellen zur E-Shop Software darstellen. Gleichwohl trÀgt die rein
theoretische Betrachtung der Komponenten unter VernachlÀssigung der Integrationstiefe, zur
ĂŒbersichtlicheren Darstellung und damit besserem VerstĂ€ndnis bei.
Abbildung 7 zeigt in diesem Sinne den abstrakten Aufbau einer möglichen E-Shop
Softwarelösung, welches wie in bei diesem Beispiel das Katalog-, Kunden- und
Transaktionsverwaltung als SchlĂŒsselkomponenten beinhalten kann. Jedem dieser drei
Komponenten, können prinzipiell weitere Komponenten angehÀngt werden, wie Abbildung 7
darstellt.
Marketing
Werbeinstrumente gezielte Kundenansprache
Content
Management
User Generated Content Kunden-
Katalog
ERP Produktempfehlungen management
Anbindung
VerfĂŒgbarkeit Kommunikation mit Kunden
La
g
un
ge
d
rve
bin
rw
en
a
nd
ltu
Ku
ng
Liefermanegement Retourenmanagement
Transaktions-
verwaltung
Zahlungsabwicklung
Abbildung 7: Beispielhafte Darstellung der E-Shop Softwarekomponenten 70
GrundsÀtzlich kann eine E-Commerce Software in ein sog. Front-End und Back-End
71
unterteilt werden. Der Endkunde sieht jedoch nur das Front-End, mit dessen
68
Vgl. Laudon / Traver, 2009, S. 4,1- 4,29; Bigdoli, 2007, S. 138-140.
69
Vgl. Laudon / Traver, 2009, S. 4,26- 4,28.
70
In Anlehnung an Walker, 2009, S. 10.
- 22 -
23. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
BenutzeroberflÀche er interagiert. Das Back-End dient im Gegensatz dazu, der internen
Abwicklung der Prozesse und der Administration der Plattform. 72
Zu den Funktionen im Front-End-Bereich gehören insbesondere 73:
§ Produktkatalog (Kapitel 3.2.1)
§ Kundenkonto (Kapitel 3.2.8)
§ Produktwarenkorb (Kapitel 3.2.2.1)
§ Bestellformular (Kapitel 3.2.2.2)
§ After-Sales-Funktionen (Kapitel 3.2.8)
Zu den wesentlichen Funktionen im Back-End-Bereich gehören 74:
§ Content Management System (Kapitel 3.2.3)
§ Kundenmanagement (Kapitel 3.2.8)
§ Web Analytics (Kapitel 3.2.5)
§ Produktkatalog (Kapitel 3.2.1)
Die aufgefĂŒhrten Komponenten sind, sofern vorhanden, entweder integrierte Bestandteile
der E-Shop Software oder stehen zumindest im Datenaustausch. Die einzelnen
Komponenten des Front- und Back-Ends werden in Kapitel 3 im Detail erlÀutert.
1.8. E-Shop Softwaretrends
Auch nach ĂŒber dreizehn Jahren des Online Handel, eines Internetbooms, dem Niedergang
der New Economy und der Wiederauferstehung dessen, kann eine dynamische
Innovationskraft beobachtet werden, die maĂgeblichen Einfluss auf E-Shop Software hat.
Diese EinflĂŒsse sind nicht nur technischer, sondern durchaus vielfĂ€ltiger Natur und folgen
z.T. dem Zeitgeist der Gesellschaft.
Social Software, neue Internettechnologien und die VerÀnderung der NutzeraktivitÀten im
Internet werden zusammenfassend auch als Web 2.0 bezeichnet. Bis heute gibt es keine
eindeutige Definition des Begriffes. 75 OâReilly definiert den Begriff Web 2.0 wie folgt: âWeb
2.0 is the business revolution in the computer industry caused by the move to the internet as
platform, and an attempt to understand the rules for success on that new platform. Chief
among those rules is this: Build applications that harness network effects to get better the
71
Vgl. Kollmann, 2009, S. 213.
72
Vgl. Kollmann, 2009, S. 213.
73
Vgl. Kollmann, 2009, S. 213-215.
74
Vgl. Kollmann, 2009, S. 213-215.
75
Vgl. Deans, 2009, S. 5.
- 23 -
24. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
more people use them. This is what I've elsewhere called harnessing collective
intelligence.â 76 Trotz unscharfer Definition verbirgt sich hinter dem Begriff die konkrete
Vorstellung von einer neuen Art des Internets. Sie basiert auf der Annahme, dass das
Platzen der Internetblase (Dot-Com-Kollaps) Ende des letzten Jahrzehnts zu einem
Zusammenbruch des Internets in der damaligen Form gefĂŒhrt hat. Erfolgreich fortbestehen
konnten nur diejenigen, die in der Lage waren, sich weiter zu entwickeln und einen neuen
Ansatz fĂŒr den Umgang mit dem Internet zu finden. 77
Der Benutzer dieser neuen Form des Internets ist nicht nur Konsument, sondern zugleich
auch Inhaltslieferant. DafĂŒr findet er im Gegenzug aber auch besser auf seine BedĂŒrfnisse
abgestimmte Inhalte vor. Daraus kann sich eine kollektive Intelligenz im Internet formen, die
im Wesentlichen auf der VerknĂŒpfung bzw. Vernetzung der Inhalte durch seine Benutzer
mittels Hyperlinks beruht. Dynamische Inhalte haben statische Homepages abgelöst und
bieten vielfÀltige Dialog- und Interaktionsmöglichkeiten mit anderen Nutzern des Internets. 78
Da die Anwendungen auf den Nutzer zugeschnitten werden, wird ein besonderes
Augenmerk auf ihre Benutzerfreundlichkeit gerichtet und Wert auf Feedbacks der Nutzer
gelegt. 79
Da es sich bei der Entwicklung von Web 1.0 zu Web 2.0 nur um eine wahrgenommene
Entwicklung und nicht um eine neue Version des Webs handelt, zeigt die folgende Abbildung
8 die Art und Weise der Betrachtung. 80
76
O'Reilly, 07.01.2010.
77
Vgl. O'Reilly, 08.01.2010.
78
Vgl. Beckert, 2007, S. 7f.
79
Vgl. Ebersbach et al., 2008, S. 24.
80
Vgl. Trump et al., 2007, S. 9.
- 24 -
25. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
gestaltend
Web 2.0
Kommunikation
Kommunikation
individuelle
öffentliche
Web 1.0
betrachtend
Aktiv partizipierende Nutzer
Passiv partizipierende Nutzer
Abbildung 8: Die zwei Dimensionen des Internets 81
Die Betrachtungsweisen gehen hier von rein betrachtend und individuell kommunizierend bis
zu gestaltend und öffentlich kommunizierend. Die Dimension Gestaltungsgrad erstreckt sich
von rein betrachtender Nutzung, z.B. durch das Lesen eines Artikels, bis zur gestaltender
82
Nutzung, z.B. durch Verfassen von Texten im Internet. Die zweite Dimension
Kommunikationsgrad erstreckt sich vom Bereich der individuellen Kommunikation, z. B.
versenden von privaten E-Mails, bis zum Bereich der öffentlichen Kommunikation. 83
Bei der Evaluierung und Auswahl von E-Shop Software ist es unabdingbar diese EinflĂŒsse
zu berĂŒcksichtigen, da sie sich in den BedĂŒrfnissen des Endkunden widerspiegeln. Dieses
Kapitel soll eine Ăbersicht dieser EinflĂŒsse und Trends aufzeigen, die innerhalb der nĂ€chsten
Kapitel aufgegriffen und z.T. im Detail behandelt werden. In diesem Sinne gewÀhrt die
folgende Tabelle eine Ăbersicht ĂŒber heutige Trends und EinflĂŒsse auf Grundlage von
Walkers VorschlĂ€gen, die relevant fĂŒr E-Shop Software sind. 84
Perso- Die Beziehung zwischen E-Shop Betreiber und Endkunden âweicht,
nalisierung getrieben von einer Verlagerung der Endkundenerwartungen, zunehmend
einer stÀrkeren Integration des Nachfragers in die Angebotserstellung von
Personalisierung und Individualisierung der Angebote.â 85 Dazu eignen sich
81
In Anlehnung an Trump et al., 2007, S. 9.
82
Vgl. Trump et al., 2007, S. 10.
83
Vgl. Trump et al., 2007, S. 10.
84
Vgl. Walker, 2009, S. 6.
85
Wirtz, 2001, S. 289.
- 25 -
26. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Produktempfehlungsfunktionen, wie z.B. Cross- oder Up-Selling
86
Funktionen. Beim Up-Selling werden Produkte auf Basis der bisherigen
Wahl, passende Produkte mit einem höheren Preis angeboten. 87 Cross-
Selling kann als sinnvolle Produktempfehlungen, ĂŒber Produktkategorien
hinweg definiert werden. 88
Multiple Eine zunehmende Anzahl an AusprÀgungstypen des GeschÀftsmodells
GeschÀfts-
Aggregator, wie z.B. Clubverkauf und Liveshopping, 89 stellen besondere
modelle
Anforderungen an die E-Shop Software flexibel fĂŒr unterschiedliche
AusprÀgungstypen verwendbar zu sein.
Inter- International aufgestellte E-Shop Betreiber sehen sich gefordert in den
nationalisierung
ZielmÀrkten regionalspezifisch angepasst, andererseits aber
wiedererkennbar und mit den gleichen Daten aufzutreten und das
möglichst zentral zu steuern. 90 Globale E-Commerce Lösungen sollten
unterschiedliche lokale Gepflogenheiten hinsichtlich Sprache,
Adressformate, Workflows, Mehrwertsteueranzeige etc. unterstĂŒtzen und
die unterschiedlichen lokalen E-Commerce Varianten in einem System
konsolidieren und betreiben. Die UnterstĂŒtzung von internationalen E-
Commerce AktivitÀten durch die E-Shop Software wird in Kapitel 3.2.5
nÀher erlÀutert.
User Generated Mediale Inhalte, wie z.B. Text, Fotos und Videos, die vom Nutzer
Content
bereitgestellt werden, können als User Generated Content bezeichnet
werden. 91 Bei E-Shops findet man diese insbesondere in Form von E-
Shop-Bewertungen, Produktbewertungen und produktbezogenen
Diskussionen wieder. Dies kann innerhalb des E-Shops, z.B. durch
entsprechende Bewertungsformulare je Produkt, die Integration von Foren
und Blogs, sowie Anbindung von Bewertungssysteme Dritter, realisiert
werden. User Generated Content stellt eine zusÀtzliche Informationsquelle
fĂŒr potenzielle Endkunden dar, bindet Endkunden und fĂŒhrt zu einer
verbesserten Suchmaschinenfreundlichkeit.
Tabelle 4: Trends und EinflĂŒssen mit Relevanz fĂŒr E-Shop Software 92
86
Vgl. Panniello / Gorgoglione / Palmisano, 2009, S. 248-250.
87
Vgl. Bustos, 08.01.2010.
88
Vgl. Netessine / Savin / Xiao, 2004, S. 2-3.
89
Vgl. Kapitel 2.3.
90
Vgl. BITKOM, 2009, S. 26.
91
Vgl. Tapp, 2008, S. 302-303.
92
Vgl. Walker, 2009, S. 6.
- 26 -
27. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
1.9. Betreibermodelle
Die Nutzung und Verbreitung von Software unterliegt als Ausdruck einer schöpferischen
Leistung dem urheberrechtlichen Schutz. Entsprechend des deutschen Urhebergesetzes
kann der geistige Schöpfer eines Werkes bezĂŒglich der Nutzung und Verbreitung
entscheiden. 93 Die genaue Ausgestaltung der vom Urheber gewÀhrten Nutzungsrechte, wird
in der Softwarelizenz festgehalten. Dabei unterscheiden sich je nach Distributions-Modell,
die Nutzungsrechte und Möglichkeiten sehr deutlich.
Nach der ibi research an der UniversitÀt Regensburg GmbH, kann aus Sicht eines E-Shop
Software Nachfragers grundsÀtzlich zwischen vier E-Shop Software-Distributionsmodell
unterscheiden: 94
§ quelloffene Software
§ Miet-Software
§ Eigenentwicklung
§ Kauf-Software
Als quelloffen, im Englischen auch Open Source genannt, werden Programme bezeichnet,
deren Quellcodes offen zugÀnglich sind, die uneingeschrÀnkt genutzt, verÀndert und
erweitert werden können, sowie âin modifizierter wie in nichtmodifizierter Form
lizenzkostenfrei vervielfĂ€ltigt und verbreitet werden dĂŒrfen.â 95 Folglich kann sie i.d.R. beliebig
weiterentwickelt und je nach Anwendungszweck angepasst werden. Quelloffene E-Shop
Software ist ihrer Definition nach, grundsÀtzlich kostenlos beziehbar.
Miet-Software basiert auf dem Grundsatz, dass die Software von einem externen
Dienstleister betrieben wird. Miet-Software fĂŒr E-Shops, wird somit i.d.R. auf dem Servern
des Anbieters installiert und lÀsst sich nach einem Baukastensystem einrichten und
erweitern. Allerdings kann i.d.R. nur das Partnerunternehmen, das die Miet-Software
anbietet auch weitreichende Ănderungen am Softwarecode vornehmen, da die
Anpassungsmöglichkeiten seitens des Nachfrager begrenzt sind. In der Literatur und der
Industrie werden z.T. unterschiedliche Begriffe wie ASP (Application Service Providing),
SaaS (Software as a Service) oder on demand Solutions verwendet.
Dabei beschreiben diese Begriffe unterschiedliche Varianten von Miet-Software, die sich
oftmals durch ihren Standardisierungsgrad unterscheiden und nicht selten zu
93
Vgl. Mundhenke, 2007, S. 40.
94
Vgl. ibi research an der UniversitÀt Regensburg GmbH, 2009, S. 45-47.
95
Mundhenke, 2007, S. 15.
- 27 -
28. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
96
Marketingzwecken genutzt werden. An dieser Stelle soll auf diese Varianten der Miet-
Software verwiesen werden, wobei auf eine tiefere Diskussion dieser verzichtet wird. 97
Intern entwickelte E-Shop Software ist i.d.R. sehr individuellen BedĂŒrfnissen zugeschnitten
und wird als Eigenentwicklung bezeichnet. Theoretisch sind der Entwicklung keine Grenzen
gesetzt. In der Praxis hĂ€ngt die Entwicklung jedoch von verfĂŒgbaren Ressourcen ab.
Kauf-Software basiert entweder auf eine Eigenentwicklung oder quelloffener-Software. In der
Literatur wird Kaufsoftware auch als Fertigsoftware oder kommerzielle Standardsoftware
bezeichnet. 98 Kauf-Software wird oftmals in Kombination mit zusÀtzlichen Dienstleistungen,
wie z.B. SupportvertrÀgen, erworben. Die Nutzung der Software kann seitens des Herstellers
auf verschiedenste Weise, wie z.B. zeitlich, funktional oder nach Anzahl der Administratoren
bzw. Mitarbeiter, eingeschrĂ€nkt werden. Ebenso können Ănderungen am Code untersagt
99
sein. GrundsÀtzlich hÀngen die Rechte des E-Shop Betreibers von dem jeweils
vereinbarten Kaufvertrag ab.
Die unterschiedlichen Distributionsmodelle zeigen, dass der E-Shop Betreiber, abhÀngig
vom gewÀhlten Modell, ein unterschiedliches Maà an Ressourcen selber bereitstellen bzw. in
unterschiedlichem MaĂe externe Unternehmen einbeziehen muss. Kollmann greift diese
Problematik auf und unterscheidet mit dem Betreiber-, Dienstleister- und Partner-Modell,
zwischen drei Modellen, die sich durch unterschiedliche WertbeitrÀge unterscheiden, wie die
Abbildung 9 verdeutlicht. 100
96
Vgl. Lassmann, 2006, S. 130; Schaffry, 04.01.2010; Grobmann, 2008, S. 15-17.
97
FĂŒr weitere Informationen sei auf folgende Literatur verwiesen: Beinhauer / Herr / Schmidt, 2008;
Buxmann / Diefenbach / Hess, 2008; Grobmann, 2008.
98
Vgl. Henning, 2004, S. 11.
99
Vgl. GlĂ€Ăer, 2004, S. 19f.
100
Vgl. Kollmann, 2007, S. 319-321.
- 28 -
29. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Betreiber Dienstleister Partner
E-Shop Individual- Standard-
Software lösung lösung
Eigen-
Administration Partner
verantwortung
Resourcen-
hoch niedrig
bedarf
Strategischer
hoch niedrig
Einfluss
Abbildung 9: WertbeitrĂ€ge-Modell fĂŒr E-Shop Lösungen 101
Mit Abbildung 9 wird E-Shop Software in Relations zum Wertbeitrag seitens des E-Shop
Betreibers, idealistisch betrachtet.
Charakteristisch fĂŒr das Betreiber-Modell ist die hohe Eigenverantwortung des E-Shop
Betreiber, da sie eine Lösung gröĂtenteils bis vollstĂ€ndig im eigenen Haus entwickelt und
selber alle notwendigen Dienstleistungen, wie die Administration und Instandhaltung erbringt.
Dem entsprechend ist das Modell sehr individuell. Allerdings muss das jeweilige
Unternehmen auch weitreichende Ressourcen, wie z.B. Know-how, bereitstellen. 102 DafĂŒr
behÀlt der E-Shop Betreiber einen hohen strategischen Einfluss.
Das Partner-Modell bildet das andere Extrem innerhalb der Skala. Charakteristisch fĂŒr diese
Modelle ist die ĂŒberwiegende bis vollstĂ€ndige Ăbertragung aller Aufgaben auf ein
Partnerunternehmen, das sÀmtliche Dienstleistungen, wie die Administration, Installation der
E-Shop Software und Bereitstellung der technischen Infrastruktur gewÀhrleistet. Ebenso ist
diese i.d.R. fĂŒr die Wartung und den Support verantwortlich. Folglich fallen die Startkosten
geringer aus als bei den anderen beiden Modellen. Auch fÀllt der Ressourcenbedarf
vergleichbar gering aus, da das Partnerunternehmen weitreichende Aufgaben erfĂŒllt. 103
Allerdings verfĂŒgt das Unternehmen, das diese Dienstleistungen nachfragt ĂŒber einen nur
geringen strategischen Einfluss und ist stark abhÀngig vom externen Dienstleister.
Das Dienstleister-Modell befindet sich innerhalb der Skala zwischen dem Betreiber- und
Partner-Modell. Dem entsprechend stellt es eine Mischung aus beiden Modellen dar. Es
101
In Anlehnung an Kollmann, 2007, S. 321.
102
Vgl. Kollmann, 2007, S. 319-321.
103
Vgl. Kollmann, 2007, S. 319-321.
- 29 -
30. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
nutzt nur bis zu einem bestimmten Grad externe Dienstleister und nutzt auch eigene
Ressourcen. Folglich verfĂŒgt es ĂŒber einen deutlichen strategischen Einfluss. 104
Da das Betreiber-Modell auf eine sehr individuelle Lösung setzt, eignet sich sowohl eine
Eigenentwicklung, als auch eine quelloffene E-Shop Software, da dessen Quellcode beliebig
verÀndert werden darf.
FĂŒr das Dienstleister-Modell eignet sich Kauf-Software, da der E-Shop Betreiber damit einen
vorgefertigten Shop erwirbt, der je nach seinen BedĂŒrfnissen insbesondere optisch
angepasst werden muss.
Beim Partner-Modell wird eine Miet-Software angeboten, da das Partnerunternehmen sehr
weitreichende Aufgaben erfĂŒllt und selbst hostet. Die Miet-Software an sich kann auf andere
Distributionsmodelle basieren und z.B. eine Eigenentwicklung sein. Aber aus Sicht des E-
Shop Betreiber handelt es sich um eine Miet-Software.
Allerdings kann die Miet-Software an sich ein E-Shop Software sein die vom Partner-
Unternehmen auf Basis eines quelloffenen E-Shops entwickelt wurde oder eine Kauf-
Software eines anderen Herstellers darstellt.
Diese drei Szenarien stellen typische Beispiele dar. Da es sich jedoch um eine Skala
handelt, sind diverse Mischformen denkbar. FĂŒr den Bereich zwischen Betreiber- und
Dienstleister-Modell kann sich z.B. eine quelloffene Software anbieten, wobei diverse
Dienstleistungen, z.B. zur Anpassung der Software, eingekauft werden
Die nachfolgende Abbildung verbildlicht die VerknĂŒpfung der Distributionsmodelle mit dem
WertbeitrÀge-Modell.
Abbildung 10: Einsatz der E-Shop Distributionsmodelle in AbhÀngigkeit zum Wertbeitrag
104
Vgl. Kollmann, 2007, S. 319-324.
- 30 -
31. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Abbildung 10 zeigt sehr idealistisch und allgemein, welche bis zu welchem Grad E-Shop
Software Distributionsmodelle externe Dienstleister einbinden, ohne Anspruch auf
VollstÀndigkeit zu erheben.
2. Anforderungen an E-Shop Software
Thayer und Dorfman definieren Anforderungen als eine vom Anwender benötigte FÀhigkeit
des Systems, um ein Problem zu lösen oder ein Ziel zu erreichen, oder eine FÀhigkeit, die
das System besitzen muss, damit es einen Vertrag, einen Standard, eine Spezifikation oder
ein anderes formelles Dokument erfĂŒllt. 105 Thayer und Dorfmans Definition aufgreifend, muss
an dieser angemerkt werden, dass im Falle von E-Shop Software zwei Anwendertypen
berĂŒcksichtigt werden mĂŒssen. Der Endkunde, der einmal spĂ€ter Produkte und
Dienstleistungen ĂŒber den E-Shop beziehen soll, sowie der Betreiber, der den E-Shop zum
Vertrieb seiner Produkte oder Dienstleistungen nutzt. Dabei ist eine einseitige Betrachtung
der Anforderungen, wie z.B. nur aus Sicht des Endkunden oder E-Shop Betreibers nicht
sinnvoll, da gegenseitige AbhÀngigkeiten bestehen.
Eine E-Shop Software, die nahtlos in das bestehende Informationssystem eines E-Shop
Betreibers eingebunden werden kann, aber wegen mangelnder Funktionen wenig
kundenfreundlich ist, stellt keinen Idealzustand dar. Ebenso wenig erfolgreich wÀre
voraussichtlich ein aus Endkundensicht komfortabel zu bedienender E-Shop, der jedoch
aufgrund von fehlenden Schnittstellen, fĂŒr den E-Shop Betreiber sehr hohe Kosten in der
Abwicklung von Transaktionen verursacht.
Opuchlik z.B. definiert mit Produkten, Verkaufsförderung, Service, Komfort und Navigation,
Warenkorb und Bezahlung, sowie Sicherheit, sieben Anforderungen aus Endkundensicht,
die jedoch nur sehr bedingt relevante Anforderungen fĂŒr die Evaluierung von E-Shop
Software darstellen. SchlieĂlich hĂ€ngt die Verkaufsförderung beispielsweise vom
Unternehmensmarketing ab, die Bezahlung von der Unternehmenspolitik und der Service
sind abhÀngig vom Liefer- und Kundenservice. Freilich sind das Unternehmensmarketing,
die Unternehmenspolitik oder der Liefer- und Kundenservice keine Faktoren, die maĂgeblich
abhÀngig von der E-Shop Software wÀren. Folglich bedarf es zwar eine gesamtheitliche
Betrachtung der Anforderungen, sowohl aus Endkunden- als auch E-Shop Betreiber Sicht,
wobei Anforderungen ohne Relevanz fĂŒr die Evaluierung einer E-Shop Software von der
Betrachtung ausgeschlossen werden mĂŒssen.
105
Vgl. Thayer, Richard H.; Dorfman, Merlin; Baili, 1997, S. 23-28.
- 31 -
32. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Die in Kapitel 2 aufgefĂŒhrten Definitionen und Diskussionen des GeschĂ€ftsmodell Typus
Aggregator, der E-Commerce Plattform E-Shop und der E-Shop Software, werden in diesem
Kapitel als Grundlage fĂŒr die Identifizierung, Definition und Gruppierung der Anforderungen
an E-Shop Software, seitens E-Shop Betreiber und Endkunden verwendet. Des Weiteren
werden die nachfolgenden Unterscheidungen verschiedener Autoren berĂŒcksichtigt.
Reynolds und Staire schlagen mit Katalog Management, Produktwarenkorb und
Produktmanagement eine dreigliedrige Gruppierung vor. 106 Schneider schlÀgt mit Katalog,
Produktwarenkorb und Transaktionsverwaltung eine sehr Àhnliche Unterscheidung vor. 107
Schneider sieht anders als Reynolds und Staire, das Produktmanagement als Teil des
Katalog Managements, wobei er die Abwicklung von Transaktionen nicht der Gruppe
Produktwarenkorb getrennt betrachtet. Insgesamt basieren die Unterschiede zwischen
Reynolds und Staire sowie Schneiders Betrachtung, also auf unterschiedliche Definitionen.
Opuchlik schlÀgt mit der Gruppierung der Anforderungen in Architektur, Administration,
Sicherheit und Skalierbarkeit eine weitergehende Unterscheidung vor, wobei unter dem
Begriff Administration im Grunde Back-End Funktionen 108 zusammengefasst werden. 109 Die
bisher erwÀhnten Autoren definieren Anforderungen an eine E-Shop Software ohne jedoch
den Einfluss des Herstellers fĂŒr die zukĂŒnftige Entwicklung der E-Shop Software zu
berĂŒcksichtigen. Die BITKOM bleibt bei der Formulierung von Anforderungen sehr allgemein,
weist jedoch auf verschiedene Betreibermodelle hin und unterstreicht die Bedeutung des
Herstellersupports. 110 Die Einbeziehung des E-Shop Softwareherstellers, stellt aufgrund der
z.T. hohen AbhÀngigkeit je nach Betreibermodel, ein wichtiges Kriterium dar. 111
Aufbauend auf die hier dargestellten VorschlÀge verschiedener Autoren, werden
nachfolgend die Anforderungen an E-Shop Software, bei einer Gliederung in die Teilbereiche
Architektur, Funktionen, Sicherheit und Strategie, im Detail erlÀutert.
106
Vgl. Reynold / Staire, 2003, S.193f.
107
Vgl. Schneider, 2004, S. 361.
108
Vgl. Kapitel 2.7.
109
Vgl. Opuchik, 205, S. 117.
110
Vgl. BITKOM, 2009, S. 29-32.
111
Vgl. Turban / Rainer Jr., 2009, S. 14,47-14,51; Reynolds, 2004, S. 200f; Korper / Ellis, 2001, S.
172-175.
- 32 -
33. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
2.1. Architektur
E-Commerce Lösungen mĂŒssen in der Position sein, wachsende Benutzerzahlen bewĂ€ltigen
zu können und Dienste auch bei einer hohen Auslastung zuverlÀssig bereitstellen zu können.
Sich schnell verĂ€ndernde Anforderungen, bedĂŒrfen die zuverlĂ€ssigen, interaktiven und
sicheren Zusammenarbeit interner und externer Ressourcen, bei gleichzeitiger Wahrung der
FlexibilitÀt. 112
Die Architektur beschreibt die Struktur eines Systems, dessen Bausteine, Schnittstellen und
deren Zusammenspiel. 113 Die Architektur besteht aus PlÀnen und enthÀlt i.d.R. Hinweise und
Vorschriften, nach denen das System zusammengebaut werden sollte. 114 Damit kann die
Software-Architektur auch als Plan eines Systems gesehen werden.
Durch die Architektur wird die KomplexitÀt eines Systems besser erfassbar und
verstÀndlicher. Tom DeMarco bezeichnet die Architektur auch als framework of change, d.h.
sie kann einen Rahmen darstellen innerhalb dessen die Software entwickelt werden kann. 115
Bass, Clements und Kazman definieren Software-Architektur als die Struktur eines Systems,
das Softwarekomponenten, die Eigenschaften dieser Komponenten sowie deren
116
Beziehungen aufzeigt. Der in dieser Definition genannte Begriff Komponente, kann
beispielsweise eine Datenbank oder ein Server sein. Durch die Beziehung der Komponenten
untereinander und der Eigenschaften dieser Beziehungen entsteht eine Struktur, die man
Software-Architektur nennt. 117
Entsprechend der sich mit der Zeit verÀndernden Anforderungen an Software, unterliegt
auch die Architektur VerÀnderungen. Die Anforderungen können sich grundsÀtzlich sowohl
wÀhrend der Entwicklungsphase als auch danach Àndern. Die folgende Abbildung stellt die
Einflussfaktoren in Bezug auf die Architektur dar.
112
Vgl. Strobel, 2004, S121.
113
Vgl. Starke / Hruschka, 2009, S. 2.
114
Vgl. Starke / Hruschka, 2009, S. 3.
115
Vgl. DeMarco,1995, S. 128; Eichinger, 2003, S. 66.
116
Vgl. Bass / Clements / Kazman, 2003, S. 3.
117
Vgl. MĂŒller, 2005, S. 59.
- 33 -
34. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Fu
Ă€t
nk
lit
tio
ua
ne
Q
n
Software Architektur
Te
ch
ni
g
un
sc
hr
he
fa
As
Er
pe
kt
e
Abbildung 11: Auf die Entwicklung einer Softwarearchitektur wirkende Faktoren 118
Wie in der Abbildung 11 dargestellt, können vier unterschiedliche Einflussfaktoren
unterschieden werden. Die funktionalen Faktoren beziehen sich die Clienten und andere
Nutzergruppen. Zu den qualitativen Faktoren können insbesondere die Erweiterbarkeit,
Performance und Wiederverwendbarkeit gezÀhlt werden. Ein technische Aspekt kann z.B.
das Betriebssystem sein. Der Einflussfaktor Erfahrung bezieht sich z.B. auf das
Projektmanagement und Erfahrungswerten aus bestehenden Softwarearchitekturen. 119
In den nachfolgenden Unterkapiteln werden Softwarearchitekturen mit Fokus auf E-Shop
Software nÀher erlÀutert.
2.1.1. Architekturmuster
Eine bewÀhrte Form der Dokumentation von Software-Architekturstrukturen ist das
Schichten-Architekturmuster. 120 Mit dieser kann die Anordnung von Systembausteinen auf
unterschiedlichen Ebenen dokumentiert werden. Unter einer Schicht kann ein abgekapseltes
Objekt oder eine Komponente verstanden werden. 121 Durch die Schichten-Architektur wird
eine klare Trennung der Funktionen und Aufgaben erreicht. GrundsÀtzlich sind
unterschiedliche Merkmale der Trennung möglich. In Anlehnung an das ISO-
118
Vgl. Eichinger, 2003, S. 67.
119
Vgl. Eichinger, 2003, S. 67.
120
Vgl. Vogel u.a., 2005, S. 34.
121
Vgl. Strobel, 2004, S. 122.
- 34 -
35. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Schichtenmodell, dĂŒrfen die Schichten nur mit den benachbarten Schichten kommunizieren,
d.h. mit den Schichten, die ĂŒber oder unter ihnen liegen. 122
2.1.2. Zwei- und n-Schichten Architektur
Eine Client/Server Lösung stellt eine typische zwei-Schichten-Architektur dar. 123 Der Server
beherbergt die Datenbank und realisiert die Zugriffe auf die Daten, die vom Client initiiert
werden. Diese Architektur basiert auf einem einfachen Anfrage- /Antwort Konstrukt.
GrundsĂ€tzlich ist sie fĂŒr einfache Anwendungen geeignet und funktioniert bei einer
bestimmten Anzahl an Clienten gut, wobei jedoch, die Leistung bei hohen Nutzerzahlen stark
abnimmt. 124
Strobel identifiziert dazu weitere Nachteile 125:
§ Der Entwicklungsprozess der Anwendung geschieht auf einem Computersystem, das
die Informationen darstellt und verarbeitet. Dadurch wird der Anwendungscode aus
den verschiedenen Teilen miteinander vermischt und das individuelle Programm lÀsst
sich schwer warten.
§ Es ist eine Entwicklungsgruppe notwendig, die sich mit der grafischen und der
Verarbeitungslogik auskennt, da sich die Verarbeitungslogik und PrÀsentation der
Daten in der gleichen Schicht befinden.
§ âDie Wiederverwendung der Anwendungsteile ist wegen IndividualitĂ€t des Codes
schwierig.â 126
§ Der Datenbankserver muss zusĂ€tzlich gesichert werden, um nicht fĂŒr jede
Benutzergruppe zugÀnglich zu sein.
Eine n-Schichten oder Mehr-Schichtenarchitektur setzt bei den Schwachstellen der zwei-
Schichtenarchitektur an und sieht mit einer PrÀsentationsschicht, Business-Logik-Schicht
und Datenschicht, mindestens drei Schichten vor. Weitere Schichten können beispielsweise
hinzugezogen werden, um Ausfallsicherheitsanforderungen zu begegnen oder zur
Lastverteilung durch die Verteilung der Clientanfragen an verschiedene Server. 127
Die Schichten arbeiten getrennt voneinander und besitzen eigene Eigenschaften und
Methoden. Jede Schicht verfĂŒgt ĂŒber Kommunikationsschnittstellen zu seinen
122
Vgl. MĂŒller, 2005, S. 62.
123
Vgl. MĂŒller, 2005, S. 64.
124
Vgl. Vogel u.a., 2005, S. 212; MĂŒller, 2005, S. 64.
125
Vgl.Strobel, 2004, S. 123-125.
126
Strobel, 2004, S. 123.
127
Vgl. Vogel u.a., 2005, S. 212f.
- 35 -
36. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
128
Nachbarschichten. Folglich ist es möglich, dass die Schichten auf jeweils
unterschiedlichen physikalischen Servern arbeiten.
Strobel identifiziert folgende Eigenschaften von n-Schichtenarchitekturen 129:
§ Die Trennung der Schichten erlaubt den Austausch von Modulen
§ Es können Entwicklungsgruppen gebildet werden, die sich auf einen
Anwendungsbereich spezialisieren
§ Die Anwendungslogik muss nur einmal implementiert werden
Im Vergleich zu zwei-Schichtigen Lösungen haben n-schichtige Architekturen also deutliche
Vorteile im E-Commerce Bereich. 130 Die StÀrken zeigen sich z.B. durch wiederverwendbare
Komponenten, verteilte Ressourcen, standardisierte Schnittstellen und
TransaktionsĂŒberwachungen.
2.1.3. Service orientierte Architekturen
Eine Service orientierte Architektur (SOA) beschreibt den Aufbau einer
Anwendungslandschaft, bestehend aus einzelnen Anwendungsbausteinen, die verbunden
131
sind und einander ihre Services anbieten. In diesem Sinne ist ein Service eine definierte
Leistung, die âals Element eines oder mehrerer VerarbeitungsablĂ€ufe verwendet werden
kann.â 132
Eine einheitliche und allgemein anerkannte Definition des Begriffe SOA besteht jedoch
nicht. 133 Forrester Research definiert SOA als Art und Weise, wie Anwendungen und
134
Software-Infrastruktur gestaltet, bereitgestellt und verwaltet werden. GemÀà dem
Unternehmen IBM bestimmt SOA die Art und Weise wie man Software baut und erlaubt eine
Software Services fĂŒr eine andere Software bereitzustellen. Somit wird als Basis der Service
als wiederholbarer Arbeitsschritt innerhalb einer GeschÀftsprozesses verstanden. 135
Zu den Charakteristiken einer SOA zÀhlen die verteilte Architektur, die lose Kopplung von
Services und standardisierte Schnittstellen. Zu den Vorteilen zÀhlen die
128
Vgl. Web-Technologien, C.Strobel, S. 123.
129
Vgl. Web-Technologien, C.Strobel, S. 131.
130
Vgl. Strobel, 2004, S. 135.
131
Vgl. Richter / Haller / Schrey, 2005, S. 413-416.
132
Richter / Haller / Schrey, 2005, S. 413.
133
Vgl. Liebhart, 2007, S. 6.
134
Vgl. Liebhart, 2007, S. 6.
135
Vgl. Liebhart, 2007, S. 6.
- 36 -
37. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Wiederverwendbarkeit (der Services), die FlexibilitÀt, Kosteneffizienz, Transparenz und hohe
KompatibilitÀt. 136
Der modulare Aufbau verringert im Allgemeinen die KomplexitÀt der IT Struktur. Module zur
Erweiterung von E-Shop Software werden in der Literatur auch als Plugins bezeichnet. Da
ein Modul theoretisch beliebig oft fĂŒr eine E-Shop Software verwendet werden kann, lassen
sich durch diese Wiederverwendbarkeit Kosten senken. Zudem stellt dies einen zusÀtzlichen
Anreiz fĂŒr externe Dienstleister dar, Module zu entwickeln.
Die Erweiterbarkeit durch Module ist insbesondere fĂŒr E-Shop Software von sehr groĂer
Wichtigkeit, weil hier z.T. sehr viele externe Anwendungen angebunden werden mĂŒssen, wie
Kapitel 2.7 detaillierter zeigt. In diesen FĂ€llen kann es von bedeutendem Vorteil sein Module,
wie z.B. Content Management Systeme 137 oder der Web Analytic Software 138 einfach
anbinden zu können, und nach Möglichkeit von Herstellern Standardmodule bereitgestellt zu
bekommen. Bereits die Wiederverwendbarkeit von Standardmodule kann externe
Dienstleister motivieren, Softwaremodule zu entwickeln und am Markt anzubieten.
Allerdings mĂŒssen bei individuellen Projekten neben den eigenen Anforderungen auch die
möglichen zukĂŒnftigen Anforderungen anderer Bausteine berĂŒcksichtigt werden, was eine
vorausschauenden Vorgehensweise bedarf. Folglich setzt SOA ein tiefes VerstÀndnis der
GeschÀftsprozesse voraus. 139
2.1.4. Datenaustausch
Um den Datenaustausch im E-Business und damit auch mit der E-Shop Software effizienter
und kostensparender zu machen, sind nutzbare Standards notwendig. Der Datenaustausch
kann sowohl zwischen Unternehmen, als auch zwischen unterschiedlichen Anwendungen
innerhalb eines Unternehmens erfolgen, . Im Allgemeinen bezieht sich der Datenaustausch
auf produkt oder kunden-bezogene Daten. Als Beispiele können der Import von
Produktdaten von einem ERP Software, der Export von Bestelldaten an eine ERP Software
oder der Export von Produktdaten zu Marketingzwecken z.B. fĂŒr Preisvergleichsportale oder
Affiliate-Netzwerke genannt werden.
Der Datenaustausch erfolgt dabei stets auf Grundlage definierter Datenformate. 140 Dabei
lassen sich Standards im Vergleich zu proprietÀren Formaten grundsÀtzlich leichter
136
Hermann Krallermann u.a., 2007, S. 16.
137
Vgl. Kapitel 3.2.3.
138
Vgl. Kapitel 3.2.6.
139
Vgl. Holtkamp, 2009, S. 14.
140
Vgl. Leukel, 2004, S. 67f.
- 37 -
38. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
gegenĂŒber Partnern durchsetzen, werden von vielen Unternehmen unterstĂŒtzt und benötigen
141
kein schwer zu akquirierendes Wissen. Des Weiteren sind E-Business Standards
142
konvertierbar. D.h. die Daten eines z.B. XML-basierten Formats, lassen sich mit Hilfe der
entsprechenden Transformationsregel stets in ein anderes XML-basiertes Format
umwandeln.
Zu den bedeutendsten Standards gehören die Datenformate CSV, EDI und XML, die in der
Tabelle 5 miteinander verglichen werden. 143
CSV-Formate EDI-Formate XML-Formate
ĂbertragungsgröĂe Minimal Gering Hoch
Formale Spezifikation Nein Nein Ja
Multimediadaten Nein Nein Ja
PlattformunabhÀngig Nein Nein Ja
144
Tabelle 5: Vergleich CSV-, EDI- und XML-basierter Datenformate
Der Vergleich von XML Dokumenten mit der zugehörigen, formalen Spezifikation stellt die
GĂŒltigkeit der Dokumente und damit die KonformitĂ€t zum definierten Format sicher. Dadurch
keine fehlerhafte Daten, z.B. weil sie falsche Datentypen oder nicht definierte Datenelemente
beinhalten, verarbeitet. Dies ist beim CSV- und EDI-Format nicht gegeben. 145 Die Aufnahme
von Multimediadaten, wie z.B. Abbildungen, ist ebenso nur mit dem XML Format möglich.
FĂŒr die Kommunikation eines E-Shops mit externen Anwendungen, bedarf es i.d.R. weiterer
Technologien. Insbesondere das Netzwerkprotokoll SOAP (Simple Object Access Protocol),
mit dessen Hilfe Daten zwischen zwei Systemen ausgetauscht werden können, gilt als ein
Industriestandard und wird u.a. von IBM, Hewlett-Packard, Sun Microsystems
(Tochterunternehmen von Oracle) 146 und Microsoft unterstĂŒtzt. 147 Die UnterstĂŒtzung von
SOAP seitens einer E-Shop Software, gehört somit bereits aufgrund der Verbreitung von
SOAP zu den Grundvoraussetzungen fĂŒr einen Datenaustausch mit unterschiedlichen
Anwendungen. 148
141
Vgl. Quantz / Wichmann, 2003, S. 10.
142
Vgl. Kollmann, 2007, S. 67.
143
Vgl. Leukel, 2004, S. 78.
144
Vgl. Leukel, 2004, S. 78.
145
Vgl. Leukel 2004, S. 77.
146
Vgl. Oracle, 04.01.2010.
147
Vgl. Blakey, 05.01.2010; Amor, Daniel, 2004, S. 358-360.
148
Vgl. Hawk / Zheng, 2008, S. 2208-2211; Papazoglou, 2008, S. 120.
- 38 -
39. Keyvan Karimi - Entwicklung eines Evaluierungsmodells fĂŒr E-Shop Software
Weitere Technologien, die fĂŒr eine DatenĂŒbertragung relevant sein können und auf die sich
SOAP z.T. stĂŒtzt, sind u.a. Web Service Description Language (WSDL), Hypertext Transfer
Protocol (HTTP), HyperText Transfer Protocol Secure (HTTPS), 149 und Universal
Description, Discovery and Integration (UDDI), auf die hier nur verwiesen werden soll. 150
ZusÀtzliche Funktionen, die eine Verwaltung- und Automatisierung des Datenaustausches
ĂŒber eine BenutzeroberflĂ€che erlauben, können helfen, den Datenaustausch zu vereinfachen
und transparenter zu gestalten.
Alternativ können Export- und Import-AblÀufe beispielsweise durch i.d.R. eigenentwickelte
Skripte realisiert werden, sofern die Rahmenbedingungen es erlauben. Bei diesem Beispiel
könnte der Datenaustausch durch die Einstellung von sog. Cron Jobs, einer Software zur
AusfĂŒhrung von Kommandos zu einer festgesetzten Zeit oder in festgelegten AbstĂ€nden,
automatisiert werden. 151
2.1.5. Ladezeit
Aufgrund der enormen Informationsflut im Internet, hat der Nutzer das BedĂŒrfnis, in wenigen
Schritten zur gewĂŒnschten Information zu gelangen. Folglich stellt die Ladezeit eines E-
Shops einen wichtigen Erfolgsfaktor dar. 152
Tests bei der Firma Amazon haben gezeigt, dass eine Erhöhung der Ladezeit von
amazon.com um 100ms zu einem UmsatzrĂŒckgang von einem Prozent fĂŒhrt. 153 Google
stellte fest, dass die Umstellung von der Anzeige von zehn Suchergebnissen je Seite bei
einer Ladezeit von 0,4s hin zur Anzeige von 30 Suchergebnissen je Seite bei einer Ladezeit
von 0,9s, zu einem RĂŒckgang der Besucherzahlen und einem UmsatzrĂŒckgang von 20%
fĂŒhren kann. 154
Eine Studie in den USA kommt zu dem Schluss, dass eine Ladezeit von lÀnger als drei
Sekunden fĂŒr 40 Prozent aller Befragten nicht akzeptabel sei. 155 Dauert der Aufbau lĂ€nger,
verlassen die Nutzer den Shop und suchen einen anderen Online-HĂ€ndler.
Allerdings hÀngt die Ladezeit von zahlreichen unterschiedlichen Faktoren ab, worauf die
Betrachtung von Laudon und Traver oder Stair und Reynolds in Kapitel 2.5 schlieĂen
149
Vgl. Kapitel 3.3.4.
150
FĂŒr weitere Informationen sei auf folgende Literatur verwiesen: Lee u.a., 2003, S. 186-1992; Hawk
/ Zheng, 2008, S. 2208f; Papazoglou, 2008, S. 120-122.
151
Vgl. Lexitron, 05.01.2010.
152
Vgl. BITKOM, 2009, S. 26f; MĂŒller, 2004, S. 97-101; GroĂ, 04.01.2010.
153
Vgl. Kohavi / Longbotham, 2007, S. 103â105.
154
Vgl. Mayer, 19.12.2010.
155
Vgl. Forrester Research, 2009a, S. 7f.
- 39 -