Evaluierungsmodell

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software

Inhaltsverzeichnis

Anhangsverzeichnis ......................................................................................................... - 4 -

Abbildungsverzeichnis ..................................................................................................... - 5 -

Tabellenverzeichnis .......................................................................................................... - 6 -

Abkürzungsverzeichnis .................................................................................................... - 7 -

1. Grundlagen von E-Shop Software ............................................................................ - 8 -

1.1. Definition von E-Business und E-Commerce ........................................................ - 8 -

1.2. Elektronische Geschäftsbeziehungen ................................................................... - 9 -

1.3. Geschäftsmodelle im E-Business und E-Commerce .......................................... - 11 -

1.4. Entwicklung des B2C E-Commerce .................................................................... - 15 -

1.5. E-Commerce Plattform ....................................................................................... - 17 -

1.6. E-Shop Software ................................................................................................. - 20 -

1.7. E-Shop Softwarekomponenten ........................................................................... - 22 -

1.8. E-Shop Softwaretrends ....................................................................................... - 23 -

1.9. Betreibermodelle ................................................................................................. - 27 -

2. Anforderungen an E-Shop Software ...................................................................... - 31 -

2.1. Architektur ........................................................................................................... - 33 -

2.1.1. Architekturmuster ......................................................................................... - 34 -

2.1.2. Zwei- und n-Schichten Architektur ............................................................... - 35 -

2.1.3. Service orientierte Architekturen .................................................................. - 36 -

2.1.4. Datenaustausch ........................................................................................... - 37 -

2.1.5. Ladezeit ....................................................................................................... - 39 -

2.2. Funktionen .......................................................................................................... - 40 -

2.2.1. Produktkatalog und Suchfunktion ................................................................ - 43 -

2.2.2. Bestellfunktion ............................................................................................. - 48 -

2.2.2.1. Produktwarenkorb .................................................................................... - 48 -

2.2.2.2. Bestellformular ......................................................................................... - 49 -

-1-


2.2.3. Content Management .................................................................................. - 51 -

2.2.4. Multi-Shop Funktion ..................................................................................... - 52 -

2.2.5. Unterstützung für Lokalisierungen und Mehrsprachigkeit ............................ - 53 -

2.2.6. Web Analytics .............................................................................................. - 53 -

2.2.7. Suchmaschinenfreundlichkeit ...................................................................... - 54 -

2.2.8. Kundenmanagement ................................................................................... - 55 -

2.3. Sicherheit ............................................................................................................ - 56 -

2.3.1. Sicherheitsmechanismen ............................................................................. - 59 -

2.3.2. Kryptografie ................................................................................................. - 60 -

2.3.2.1. Hash Coding Kryptografie ........................................................................ - 61 -

2.3.2.2. Asymmetrische und symmetrische Kryptografie ...................................... - 61 -

2.3.3. Digitale Zertifikate ........................................................................................ - 62 -

2.3.4. Hypertext Transfer Protocol ......................................................................... - 63 -

2.3.5. Administratorenrechte und -überwachung ................................................... - 64 -

2.4. Strategie.............................................................................................................. - 65 -

2.4.1. Service ......................................................................................................... - 66 -

2.4.2. Finanzkraft ................................................................................................... - 69 -

2.4.3. Marktpräsenz ............................................................................................... - 70 -

3. Evaluierungsmodell ................................................................................................. - 73 -

3.1. Ermittlung der Ziele ............................................................................................. - 78 -

3.2. Gewichtung der Ziele .......................................................................................... - 81 -

3.3. Vergabe von Punkten für die Varianten .............................................................. - 84 -

3.4. Punkttotale .......................................................................................................... - 84 -

3.5. Einführung der Total Cost of Ownership als weitere Dimension ......................... - 85 -

3.6. Kritische Betrachtung der Methodik .................................................................... - 89 -

4. Beispiele aus quelloffenen Shopsystemen ........................................................... - 90 -

4.1. Evaluierungsbedingungen .................................................................................. - 91 -

4.1.1. Messung der Ladezeit ................................................................................. - 93 -

4.2. xt:Commerce....................................................................................................... - 94 -

4.2.1. Evaluierung .................................................................................................. - 95 -
-2-


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-


Anhangsverzeichnis

Anhang 1: Gartner TCO Modell ....................................................................................... - 114 -

-4-


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-


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-


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-


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-


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-


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 -


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 -


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 -


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
19
20
21
- 13 -


§ 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 -


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
26
27
Vgl. iBOOD GmbH, 20.02.2010.
28
Vgl. Live Shopping GmbH, 20.02.2010.
29
30
31
Vgl. Krisch, 20.02.2010.
- 15 -


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
36
In Anlehnung an Heinemann, 2009, S. 10.
37
Vgl. BITKOM, 2009, S. 11.
- 16 -


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


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
48
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 -


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 -


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 -


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 -


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 -


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
73
Vgl. Kollmann, 2009, S. 213-215.
74
Vgl. Kollmann, 2009, S. 213-215.
75
Vgl. Deans, 2009, S. 5.
- 23 -


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 -


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
83
84
Vgl. Walker, 2009, S. 6.
85
Wirtz, 2001, S. 289.
- 25 -


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 -


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 -


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 -


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 -


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 -


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 -


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 -


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 -


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 -


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
123
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 -


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
135
- 36 -


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 -


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
143
Vgl. Leukel, 2004, S. 78.
144
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 -


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 -


156
lässt. Bezogen auf Stair und Reynolds pyramidenhafte Darstellung der
157
Schlüsselkomponenten in Kapitel 2.5, ist neben der E-Shop Software insbesondere die
Auswahl der Web Server Hardware hervorzuheben. Bei der Auswahl der anderen
Komponenten besteht weniger Spielraum, da z.T. die Auswahlmöglichkeiten begrenzt sind,
wie z.B. bei der Wahl des Betriebssystems und zudem die Voraussetzungen der E-Shop
Software beachtet werden müssen.

Neben der Auswahl der Komponenten ist auch die Konfiguration relevant für die Ladezeit. 158
Des Weiteren ist die Ladezeit abhängig vom Web Design des E-Shops, wie mehrere Autoren
betonen. 159 In der Literatur werden zahlreiche Vorschläge zur Verkürzung der Ladezeit
gemacht, 160 allerdings sind die Optimierungsmöglichkeiten von E-Shop Software zu E-Shop
Software z.T. sehr unterschiedlich, weswegen pauschale Aussagen nur begrenzt möglich
sind.

Insgesamt ist die Ladezeit, insbesondere aus Sicht des E-Shop Besuchers, ein wichtiger
Faktor im E-Commerce, jedoch ist die Ladezeit wie hier erläutert, abhängig von sehr vielen
Faktoren und nicht nur von der Auswahl des E-Shops.

2.2. Funktionen
Für die Erarbeitung der funktionalen Anforderungen, die an eienn E-Shop gestellt werden,
eignet sich die Betrachtung der Transaktionsphasen aus Sicht des Endkunden. In der
Literatur ist insbesondere eine vereinfachte Unterteilung in drei Phasen, Information,
161
Vereinbarung und Abwicklung weit verbreitet. Opuchlik definiert mit Information,
Vermittlung, Verhandlung, Vertragsschluss und Abwicklung sechs Transaktionsphasen. 162
Grimm unterscheidet ebenso zwischen sechs Transaktionsphasen: 163

§ Offer Goods, die Angebotsphase
§ Browse, die unverbindliche Orientierungsphase des Endkunden
§ Order, das verbindliche Angebot des Endkunden
§ Payment, die Bezahlung der Ware
§ Deliver, die Auslieferung der Ware

156
Vgl.Laudon / Traver, 2009, S. 4,5f; Stair / Reynolds, 2003, S. 192.
157
Vgl. Stair / Reynolds, 2003, S. 192.
158
Vgl. King, 2003, S23-25.
159
Vgl. Flavian / Gurrea / Orus, 2008, S31; vgl. King, 2003, S27-32.
160
Vgl. King, 2003, S23-25; Pate / Helwig, 2006, S. 1.
161
Vgl. Baeumle-Courth / Nieland / Schröder, 2004, S. 128; Schubert / Selz / Haertsch, 2003, S. 15.
162
Vgl. Opuchlik, 2005, S. 25.
163
Vgl. Grimm, 2006, S. 7f.
- 40 -


§ Dispute, die anschließende Kundenbindungsphase in Form von Reklamationen, aber
auch weitergehenden Angeboten

Die Transaktionsphasen stehen im Einklang zu den drei nach Goluchowski, Filipczyk und
Jablonska definierten Kernfunktionen einer E-Shop Software in Kapitel 2.6. Allerdings muss
164
kritisch infrage gestellt werden, wie Grimm selbst erkennen lässt, ob der
Transaktionsphase Browse, tatsächlich schon die Phase Order folgt. Schließlich stellt dies in
der Praxis mehr als einen Schritt dar. Nach der Phase Browse muss der Endkunde zunächst
ein Produkt auswählen, d.h. in den Warenkorb legen, bevor er in die Phase Order übergehen
kann. In der nachfolgenden Abbildung wurde diese Phase als Select Goods bezeichnet und
entsprechend positioniert.

Eine Übertragung der sechs Transaktionsphasen nach Grimm, auf ein dreigliedriges Model,
wie z.B. nach Schubert, Selz und Haertsch, verdeutlicht nochmals die Lücke zwischen
Browse und Order und erzeugt ein vollständigeres theoretisches Modell:

Information Vereinbarung Abwicklung

Offer Select Pay-
Browse Order Delivery Dispute
Goods Goods ment

Abbildung 12: Transaktionsphasen im B2C E-Commerce 165

Bei physischen Waren, wie z.B. Büchern oder Kleidung, muss die Auslieferung auf
physischem Wege erfolgen, folglich spricht Bullinger auch in diesem Fall vom
unvollständigen E-Commerce, da nicht alle Prozesse elektronisch ablaufen. 166 Für die
Evaluierung von E-Shop Software ist der Transaktionsprozess Deliver, d.h. die physische
Auslieferung, jedoch zunächst zweitrangig und wird daher nicht ausdrücklich berücksichtigt.

Die Transaktionsphase Payment ist sehr wichtig und ebenso komplex. Aufgrund dessen,
werden i.d.R. je nach dem welche Bezahlverfahren angeboten werden, externe Dienstleister,
die je nach Dienstleistungsangebot auch Akzeptanzstellen genannt werden, hinzugezogen.
Für die Verarbeitung der Bezahlung wird i.d.R. folglich auch Software Dritter verwendet. Zu
den wichtigsten Bezahlverfahren gehören Vorkasse, Nachnahme, Lastschrift, Kreditkarten,
Zahlung per Rechnung und elektronische Bezahlverfahren, wie z.B. PayPal. 167 Die in der

164
Vgl. Grimm, 2006, S. 7f.
165
In Anlehnung an Schubert / Selz / Haertsch, 2003, S. 15; Grimm, 2006, S. 8.
166
Vgl. Grimm, 2006, S. 8.
167
- 41 -


Literatur bereits sehr ausführlich geführte Diskussion über Bezahlverfahren im E-Commerce,
168
soll hier jedoch nicht wiederholt werden.

In Bezug auf die Transaktionsphase Payment hat die E-Shop Software in erster Linie die
Aufgabe die Informationen, die für die Bezahlung notwendig sind, zu sammeln und
weiterzuleiten. Somit beschränken sich alle weiteren Ausführungen auch auf diese
Kernaufgaben, die in Kapitel 3.2.2.2. näher beschrieben werden.

Innerhalb der jeweiligen Transaktionsphasen führt der E-Shop Besucher unterschiedliche
Aktivitäten aus, wie die folgende Tabelle darstellt. Um diese Aktivitäten und damit
Transaktionsphasen zu ermöglichen, muss die E-Shop Software, die dafür notwendigen
Funktionen bereitstellen, die in der folgende Tabelle in der rechte Spalte zu finden sind und
den einzelnen Transaktionsphasen, wie sie zuvor diskutiert wurden, zugeordnet werden.

Transaktionsphase Beispiele für Aktivitäten aus E-Shop E-Shop Funktion
Besuchersicht
Information: Offer, § Produkte suchen § Produktkatalog
Browse § Produktrelevante Informationen § Suchfunktion
einsehen § Content
§ Zusätzliche bzw. ergänzenden Management
Produkte vorgeschlagen bekommen
§ Kommunikationsmöglichkeiten (z.B.
virtuelle Verkaufsperson, Telefon, Live
Chat etc.)
§ Abruf zusätzlicher Informationen (z.B.
Versandkosten, Versanddauer,
Rückgaberecht etc.)
Vereinbarung: § Hinzufügen von Artikel in den § Produktwarenkorb
Select Goods, Order Warenkorb § Bestellformular
§ übersichtliche Einsicht in die bisherige § Kundenmanagement
Auswahl
§ Explizite Einsicht bestellrelevanter
Informationen, wie z.B. Versandkosten
und -dauer
§ Eingabe von Kundendaten

168
Für einen Einstieg in das Themengebiet von Bezahlverfahren im E-Commerce vgl. ibi research an
der Universität Regensburg GmbH, 2009, S. 108-154; BITKOM, 2009, S. 20-44; Dannenberg / Ulrich,
2004.
- 42 -


Abwicklung: § Abwicklung der Bezahlung § Bestellformular
Payment, Dispute § Zugriff auf Bestellinformationen und § Kundenmanagement
Kundendaten
Tabelle 6: Transaktionsphasen, Aktivitäten des Besuchers und E-Shop Funktionen

Grundsätzlich muss bedacht werden, dass mit der Definition von idealistisch dargestellten
Transaktionsphasen künstliche Grenzen gezogen werden, die für die wissenschaftlich
theoretische Betrachtung wichtig sind, jedoch nicht uneingeschränkt die Wirklichkeit
abbilden, wie die drei folgenden Beispiele verdeutlichen.

Ein Besucher kann z.B. völlig unterschiedliche Transaktionsphasen einer externen Seite, wie
z.B. eines Social Networks wie Facebook, durchlaufen und sofort zur Endphase der
Abwicklung zum E-Shop weitergeleitet werden. Die Kundendaten werden dann bei diesem
Beispiel von Facebook automatisch nach entsprechender Autorisierung übertragen.

Ein weiteres Beispiel sind Preissuchmaschinen, über die ein Besucher mittels eines direkten
Links sofort zur Abwicklung zum E-Shop weitergeleitet wird und die ersten
Transaktionsphasen des E-Shops somit überspringt.

Tätigt ein E-Shop Betreiber, einen Verkauf über einen elektronischen Marktplatz und möchte
zugleich das Kundenmanagement des E-Shops nutzen, dann kann es den Endkunden nach
dem getätigten Kauf zum E-Shop weiterleiten, indem der Endkunde seine Daten ggf.
überprüfen, ändern oder anderweitig nutzen kann. In diesem Fall können die Kundendaten
z.B. über eine entsprechende Schnittstelle übertragen werden. Somit würde bei diesem
Beispiel nur die Transaktionsphase Dispute über den E-Shop vollzogen.

Diese drei Beispiele verdeutlichen, dass die Transaktionsphasen unterschiedlich durchlaufen
werden können und die Technik des E-Shop letztendlich zu unterschiedlichen Zwecken
verwendet werden kann.

Die nachfolgenden Unterkapitel beschreiben die Anforderungen, die an eine E-Shop
Software gestellt werden, um die u.a. in Tabelle 6 dargestellten Transaktionsphasen und
Aktivitäten seitens des Besuchers zu ermöglichen.

2.2.1. Produktkatalog und Suchfunktion
Mit Hilfe eines Produktkataloges können Informationen über angebotene Produkte abgerufen
werden. 169 In der Literatur gibt viele und z.T. sehr unterschiedliche Definitionen des Begriff
(elektronischer) Produktkatalog. Der Begriff Produktkatalog wird in der Literatur

169
- 43 -


weitestgehend einheitlich als ein Aufbau oder eine Darstellung von Sortiments- und
Produktinformationen definiert. 170 Nichtsdestotrotz, werden Produktkataloge aufgrund ihrer
vielseitigen Verwendbarkeit, je nach Anwendungsbereich, aus sehr unterschiedlichen
Perspektiven im Detail beschrieben. Häufig wird der Begriff zur Beschreibung von
Katalogsystemen im B2B verwendet. Andere Autoren verwenden den Begriff zur
Beschreibung von Systemen zur internen Informationsbereitstellung. 171 Allerdings muss
kritisch angemerkt werden, dass Produktkataloge für den B2C Handel in der Literatur, in nur
unzureichender Tiefe diskutiert werden. Insbesondere die kritische Auseinandersetzung mit
der Klassifizierung von Produktkatalogen wird oft vernachlässigt.

Ein sehr einfacher statischer Produktkatalog kann bereits durch eine Liste mit HTML
realisiert werden. 172 Für jede Änderung muss dann der HTML Code entsprechend manuell
verändert werden. Bei einem dynamischen Produktkatalog werden die Informationen
173
hingegen in einer Datenbank gespeichert. Dadurch können z.B. umfangreiche
Suchfunktion und Produktbeschreibungen, sowie flexible Anbindungen zu anderen
Systemen umgesetzt werden. Dynamische Produktkataloge stellen inzwischen einen
allgemeinen Standard dar.

Die Katalogdaten können z.B. Vertriebstexte, Preise, Klassifizierungen, Merkmale oder
Geometriedaten sein. Neben Inhalten im klassischen Textformat, ist die Einbindung von
multimedialen Inhalten, wie z.B. Fotos, Videos oder Anwendungen, z.B. zur Nutzung extern
gelagerter Geo-Karten (z.B. google Maps), Realisierung von 3D Produktansichten oder um
ein Customization des Produktes zu erlauben. Vor diesem Hintergrund ist die Forderung der
Medienneutralität von Relevanz, die eine Trennung von Inhalt, Struktur und Präsentation
ermöglicht. 174

Die Katalogdaten speisen sich aus den Material- und insbesondere Produktdaten. 175 Die
Produktdaten setzen sich aus Informationen aus dem Produktlebenszyklus zusammen, der
aus Planung, Entwicklung, Arbeitsvorbereitung, Herstellung, Vertrieb, Nutzung und
Recycling/Entsorgung eines Produktes besteht. 176 Die Materialdaten fassen Informationen
bezüglich der bei der Produktion eingesetzten Materialien zusammen.

170
Vgl. Meier / Stormer, 2008, S. 73f; Wannenwetsch, 2005, S. 97-99; Kollmann, 2007, S. 170.
171
Vgl. Wannenwetsch, 2005, S. 99.
172
Schneider, 2004, S. 361.
173
174
175
Vgl. Kollman, 2007, S. 170.
176
- 44 -


Dabei kann der Produktkatalog als eine Menge von logisch zusammenhängenden
Katalogdaten betrachtet werden. Die folgende Abbildung zeigt ein Modell für
Katalogdatenbereiche.

Katalogmetadaten

Katalog-
Kataloggruppensystemdaten Produktklassifikationssystemdaten
strukturdaten

Identifikations-/ Spezifikations- Bestell- und
Produktdaten Preisdaten
Beschreibungsdaten daten Logistikdaten

Produkt-
Referenzierungsdaten Parametrisierungsdaten Konfigurationsdaten
strukturdaten

Abbildung 13: Ein Modell für Katalogdatenbereiche 177

Die Katalogstrukturdaten dienen der Systematisierung der Produkte, die im Katalog
enthalten sind. Damit werden die Kataloggruppen beschrieben und das Produktsortiment
strukturiert, indem gleichartige Produkte zusammengefasst werden. Einer Kataloggruppe
können weitere Kataloggruppen untergeordnet werden, sodass eine hierarchische Struktur
entsteht.

Das Produktklassifikationssystem hingegen ordnet jedes Produkt eindeutig einer definierten
178
Produktklasse zu. Eine Produktklasse kann aus einer Menge bestimmter
Produktmerkmale wie z.B. Maße, Gewicht, Farbe etc. bestehen.

Die Produktdaten enthalten Daten zur eindeutigen Identifikation und Beschreibung von
Produkten. Des Weiteren sind spezifizierte Produktmerkmale (Spezifikationsdaten), Bestell-
und Logistikdaten (z.B. Versanddauer, mögliche Bestelleinheiten oder enthaltene Mengen)
und Preisdaten (z.B. Rabatt oder Finanzierungsmöglichkeiten) Teil der Produktdaten.

Die Produktstrukturdaten können Referenzierungsdaten, Parametrisierungsdaten und
Konfigurationsdaten als Unterbereiche beinhalten. Referenzierungsdaten dienen dazu,
Beziehungen zwischen Produkten zu beschreiben, die über die hierarchischen
Katalogstrukturen hinausgehen können. Dadurch wird es möglich, passende
Produktvorschläge, wie z.B. Zubehör-, Ersatzteil-, Alternativ- oder Zusatzartikel, zu

177
In Anlehnung an Leukel, 2004, S. 23.
178
- 45 -


unterbreiten. Parametrisierungsdaten definieren variante Merkmale und unterscheiden sich
insofern von festen Merkmalen, als das der Endkunde zwischen den Variationen des
Merkmales innerhalb vordefinierter Grenzen wählen kann (z.B. Farb- oder Größenwahl).
Bildet sich ein Produkt aus einer Auswahl und Spezifikation von Komponenten, dann werden
Konfigurationsdaten für die Abbildung der Produktzusammenstellung benötigt. Als Beispiel
für eine Produktkonfiguration können Desktop Computer genannt werden, bei denen der
Endkunde die Komponenten, wie Gehäuse, Prozessor, Festplatte, etc., konfigurieren kann.

Die Katalogdaten sind i.d.R. bereits als Artikelstammdaten im Informationssystem des
jeweiligen E-Shop Betreibers vorhanden und können durch je Möglichkeiten des
Datenaustausches übernommen werden.

Die Bereitstellung und der Aufbau dieser Hilfsmittel müssen ein gewisses Maß an
Bedienungskomfort mit sich bringen und sollten eine möglichst intuitive Produktsuche
ermöglichen. Kollmann schlägt dazu, auf Grundlage der Arbeiten von Handschuh, Schmid
und Stanoevska-Slabeva, 179 die folgende Klassifizierung von Produktkatalogen vor: 180

§ Attributbasierte Kataloge: Attribute dienen als Suchbegriffe und Klassifikationen bei
der Produktsuche.
§ Konstruierende Kataloge: „Unterstützung einer kombinierten Suche mehrerer
komplementärer Produkte.“ 181 Die Produkte beinhalten Referenzierungsdaten, die auf
ergänzende oder verwandte Produkte verweisen. Folglich können sinnvolle
Produktkombinationen vorgeschlagen werden. Charakteristisch dafür sind z.B. Up-
und Cross-Selling Funktionen. 182
§ Natürlichsprachige Kataloge: Auf Spracherkennungssystemen basierende Kataloge.
Diese beinhalten oftmals virtuelle Verkaufspersonen, wie z.B. Anna auf ikea.de und
bieten Möglichkeiten mit dem Kundenservice direkt zu kommunizieren. 183
§ Beratende Kataloge: Diese Kataloge bieten neben der Darstellung der Produkte auch
eine Personalisierung des Angebots mit Hilfe einer Bedürfnisanalyse, die mittels der
Zuhilfenahme künstlicher Intelligenz, unterstützend für die Beratung bei der
184
Produktauswahl wirkt. Die Bedürfnisanalyse kann z.B. auf Basis der Ermittlung des
Surfverhaltens erfolgen, welches durch das Auslesen von Cookies oder der
Auswertung vergangener Einkäufe und Produktsuchen sofern der Besucher

179
Vgl. Handschuh / Schmid / Stanoevska-Slabeva, 1997, S. 32-35.
180
Vgl. Kollmann, 2007, S. 170-172.
181
Vgl. Netessine / Savin / Xiao, 2007.
182
Vgl. Netessine / Savin / Xiao, 2007; S. 2f; Bustos, 08.01.2010.
183
184
- 46 -


eingeloggt ist und entsprechenden Datenbeständen zugeordnet werden kann. Des
Weiteren kann der Besucher mittels seiner IP Adresse geografisch lokalisiert werden.
Solche Funktionen werden auch als Behavioral Targeting bezeichnet und sind
insbesondere in der Internet Werbeindustrie weit verbreitet.

Die vier dargestellten Arten von Produktkatalogen können in Kombination miteinander
eingesetzt werden und schließen sich nicht gegenseitig aus. 185 In der Praxis haben aus
heutiger Sicht natürlichsprachige Kataloge, die auf Spracherkennung basieren keine
Relevanz, da die Technologie nicht ausgereift genug ist und ein Mikrofon für den Einsatz
nötig ist, was für den potenziellen Nutzer eine Nutzungsbarriere darstellen kann.

Allerdings kann aber muss die E-Shop Software nicht alle Katalogarten von Haus aus
integriert haben. Beratende und natürlichsprachige Kataloge können u.U. durch
Erweiterungen realisiert werden.

Als eines der Charakteristika für konstruierende Kataloge, wurden Cross- und Up-Selling
Funktionen bezeichnet, wobei hier zwischen einer automatisierten und manuellen Zuordnung
von Produkten unterschieden werden muss. Bei einer automatisierten Zuordnung, werden
Cross- oder Up-Selling Produkte automatisch anhand der vergangenen Verkaufstatistik
ermittelt. Bei der manuellen Zuordnung, müssen für die jeweiligen Produkte, Cross- oder Up-
Selling Produkte manuell zugeordnet werden. Eine automatisierte Ermittlung von möglichen
Cross- oder Up-Selling Produkten führt folglich zu einer grundsätzlichen Verminderung des
Administrationsaufwandes. Die Unterstützung der Personalisierung des Produktangebotes
im E-Shop geht damit im wesentlichen vom Produktkatalog aus.

Produktkataloge vereinfachen nicht nur die Navigation durch einen E-Shop und schaffen
Transparenz für den Endkunden, sondern ermöglichen auch eine unterstützende und
gezielte Suche. Der Produktkatalog liefert jedoch nicht nur Informationen an den Besucher,
sondern kann auch bewusst eingegebene Informationen seitens des Besuchers, d.h. also
User Generated Content, speichern und anderen Besuchern zur Verfügung stellen. Damit
übernimmt der Endkunde eine gestaltende Rolle und partizipiert gemäß der Definition von
Web 2.0 in Kapitel 2.8, an der öffentlichen Kommunikation. Die von Besuchern
eingegebenen Informationen können beispielsweise produktbezogene Erfahrungen oder
Bewertungen sein. Dadurch werden die Informationen, die der E-Shop Betreiber zur
Verfügung stellt mit denen der Besucher ergänzt. Ein prominentes Beispiel dafür stellen die
Kundenrezensionen und sog. Kunden-diskutieren-Funktionen von amazon.de dar. 186

185
186
Vgl. Hass / Walsh / Kilian, 2008, S. 294-298.
- 47 -


Des Weiteren trägt ein strukturierter Produktkatalog, z.B. mit den Bausteinen
Katalogstrukturdaten, Produktdaten und Produktstrukturdaten, wie hier vorgestellt wurde
dazu bei, durch die Konzentration und Strukturierung produktbezogener Informationen die
Basis für eine verbesserte Suchmaschinenfreundlichkeit zu schaffen.

Es ist dem entsprechend notwendig, dass die E-Shop Software es in ausreichendem Maße
erlaubt, eine sinnvolle Katalogstruktur aufzubauen, Artikelattribute und die Konfiguration
derer zu unterstützen.

2.2.2. Bestellfunktion
Im Anschluss an die Auswahl der Produkte, muss er diese in einem Produktwarenkorb
hinterlegen und anschließend ein Bestellformular ausfüllen, um eine Bestellung auszulösen.
Folglich kann die Bestellfunktionalität analog zum Ablauf der Bestellung in ein
Produktwarenkorb und Bestellformular aufgeteilt werden.

2.2.2.1. Produktwarenkorb
Es können Produkte zum Warenkorb hinzugefügt als auch daraus gelöscht, Mengenangaben
verändert und Produktinformationen abgerufen werden. Der Endkunde sieht mit Hilfe des
Produktwarenkorbes die von Ihm hinzugefügten Produkte mit allen wichtigen Informationen,
wie z.B. Produktattribute, Endsumme, Steuern, Lieferzeit und Versandkosten in einer
Übersicht. Zudem sollte der Endkunde die Möglichkeit haben Gutscheincodes einzugeben.
In diesem Sinne stellt der Warenkorb eine virtuelle Kasse dar, die u.a. als Zwischen- und
Kontrollspeicher der Produktauswahl dient. 187

Die E-Shop Software muss dazu in der Lage sein, Besucher eindeutig zu identifizieren und
ihnen einen Warenkorb zuzuordnen. 188 Dies kann mittels Cookies oder Session-IDs erfolgen.
Eine Session-ID ist eine vom System zufällig gewählte Zahlenfolge, zur Identifikation von
Besuchern. 189

Wird die Session ID in der URL gespeichert, kann dies zu erheblichen Sicherheitsrisiken und
der Beeinträchtigung der Suchmaschinenfreundlichkeit führen. Sobald der Besucher die
Webseite verlässt, wird seine vollständige URL an den nächsten Webserver übertragen,
wodurch die Session ID an Dritte geraten kann, die mit der Session ID z.B. die Kundendaten
einsehen oder eine Fehlbestellung tätigen. 190 Das speichern der Session ID in der URL kann

187
Vgl. Kollmann, 2007, S. 175-177.
188
189
190
Vgl. Verch, 06.01.2010.
- 48 -


bei Suchmaschinen zu Problemen führen, da Session IDs nach Ablauf einer Session (z.B.
nach dem Abmelden oder Verlassen der Seite) ihre Gültigkeit verlieren. Folglich kann es
vonseiten einer Suchmaschine zu der Erfassung von einer Vielzahl an URLs kommen, die
alle auf die gleiche Seite verweisen und zu einer negativen Bewertung der Webseite durch
Suchmaschinen führen. 191

Suchmaschinenfreundliche URL:
www.beispiel.de/kategoriename/unterkategoriename/produktname.html

URL mit Session ID: www.beispiel.de/?PHPSESSID=183249712347012374871234872314

Das Problem kann z.B. dadurch gelöst werden, dass die Session ID im Cookie gespeichert
wird und nicht in der URL. Durch die Nutzung eines Cookies wird es außerdem möglich, den
Besucher bei einem erneuten Besuch wieder zu identifizieren, ohne dass der Endkunde sich
anmelden müsste. In diesem Fall spricht man von einem persistenten Warenkorb. 192

Durch die automatische Beendigung einer Session, z.B. weil der Besucher vergessen hat
sich abzumelden, kann die Sicherheit verbessert werden. Aus den genannten Gründen,
sollte die E-Shop Software den beschriebenen Sicherheitsbedenken durch eine geeignete
Lösung entgegen wirken und die URLs bereits von sich aus suchmaschinenfreundlich
darstellen. Insgesamt hat die Art und Weise, wie der Endkunde identifiziert wird sowohl
Einfluss auf die Suchmaschinenfreundlichkeit als auch Sicherheit.

Nachdem der Endkunde identifiziert wurde und ein Produkt in den Produktwarenkorb
abgelegt hat, können ihm zusätzliche Produkte, wie z.B. Zubehör zu den im Warenkorb
befindlichen Produkten, mittels Cross- und Up-Selling Funktionen aktiv angeboten werden.

2.2.2.2. Bestellformular
Bevor der Endkunde eine Bestellung auslösen kann, muss er nachdem er Produkte in den
Warenkorb gelegt hat, seine Daten in ein Bestellformular eingeben. Die Eingabe der
Kundendaten und die Bestätigung der Bestellung bilden die Grundfunktionen des
Bestellformulares. 193 Die einzugebenden Daten bestehen zumindest bei der Erstbestellung
aus persönlichen Angaben (z.B. Name und E-Mail Adresse), Versandinformationen (z.B.
Versandadresse und Wahl des Versandunternehmens) und dem Bezahlverfahren (z.B. per
Rechnung oder Kreditkarte). 194 Außerdem ist es i.d.R. sinnvoll und teilweise zwingend
notwendig, die IP-Adresse des Endkunden zu speichern, da diese z.B. für die Ermittlung des
191
Vgl. Enge / Spencer / Fishkin / Stricchiola, 2009, S. 235-238.
192
193
Vgl. Dolson, 06.01.2010.
194
Vgl. Lenz / Moeller, 2004, S. 108.
- 49 -


Zahlungsausfallrisikos je nach Zahlungsverfahren hinzugezogen werden müsste, 195 die zur
Identifizierung des Endkunden zu Web Analytic Zwecken, 196 oder um z.B. beim Eingang
zweier identischer Bestellungen von der gleichen IP-Adresse innerhalb weniger Sekunden,
ein mögliches Versehen des Endkunden zu erkennen. 197

Grundsätzlich verlassen gerade in dieser Endphase der Bestellung sehr viele Besucher den
E-Shop. Eine Studie der Fachzeitschrift Internet –World-Business weist darauf hin, dass 9%
aller Besucher Produkte in den Warenkorb legen, aber nur rund ein Drittel von diesen auch
ihre Daten eingeben und eine Bestellung auslösen. 198

Prinzipiell ist eine einfache und intuitive Bedienung gefordert, der es erlaubt, einen
199
Bestellvorgang mit möglichst wenigen Mausklicks erfolgreich zu realisieren. Zur
Vereinfachung und Beschleunigung der Bestellabwicklung wird vielfach das Anbieten einer
sogenannten als Gast kaufen Option empfohlen. 200 Damit hat der Endkunde die Option eine
Bestellung zu tätigen, ohne einen Benutzernamen und Passwort wählen zu müssen.

Allerdings kann die Gast Kauf Funktion in einigen Fällen, je nach Geschäftsmodell, irrelevant
sein, wenn der Besucher sich als Kunde registrieren muss, bevor er jegliche Produkte
einsehen kann und damit in den Warenkorb legen kann. Dies ist insbesondere bei Private
Shopping E-Shops, wie z.B. www.vente-privee.com oder www.brands4friends.de, der Fall. In
diesem Fall verfügt der Besucher zum Zeitpunkt der Bestellung bereits über ein
Kundenkonto und muss nur noch wenige Daten, wie z.B. bezügl. des Bezahlverfahrens,
eingeben bzw. ergänzen. Grundsätzlich stellt dieser Fall jedoch eine Ausnahme dar.

Des Weiteren lässt sich durch eine sogenannte single page Lösung die Bestellabwicklung
kundenfreundlicher gestalten, da es mit Hilfe der Ajax Technologie dem Besucher ermöglicht
wird, seine Daten innerhalb einer Seite einzugeben, ohne dass die Seite vollständig nach
jedem Zwischenschritt neu geladen werden muss. 201 Dadurch kann die Grundlage für
weitere Vereinfachungen gelegt und die Bestellabwicklung aus Endkundensicht beschleunigt
werden.

Die Ursachen für die Konversionsrate, d.h. die Zahl aller Besucher, die einen Kauf getätigt
haben im Verhältnis zu der Anzahl der Besucher insgesamt 202, sind sehr vielfältig. Neben der
Gestaltung spielen insbesondere auch die angebotenen Bezahlverfahren eine Rolle, wie

195
Vgl. ibi research an der Universität Regensburg GmbH, 2009, S. 178.
196
197
198
Vgl. IntraMedia, 06.01.2010.
199
Vgl. Kollmann, 2007, 175ff
200
Vgl. Magill, 09.01.2010; Bustos, 09.01.2010; Palmer, 09.01.2010.
201
Vgl. Goldberg, 09.01.2010.
202
Vgl. Schneider / Hennig, 2008, S. 170.
- 50 -


eine Studie der ibi Research an der Universität Regensburg nachweist. 203 Weitere Faktoren
könnten beispielsweise die Art und Weise wie Fehlermeldungen dargestellt werden,
unerwartete Zusatzgebühren, die Ankündigung langer Lieferzeiten, fehlerhafte Verlinkungen
und viele weitere Faktoren sein, die jedoch auf die Ausgestaltung seitens des Betreibers des
E-Shops zurückgehen.

Die E-Shop Software kann an dieser Stelle folglich nur eine Grundlage liefern indem sie
einen Standardwarenkorb und –Bestellformular auf hohem Niveau, mit Features wie Ajax
basiertem Single Page Bestellformular und Gast Kauf Option anbietet, der hauptsächlich
gestalterisch angepasst werden muss.

2.2.3. Content Management
Aus Kundensicht, d.h. also im Front-End Bereich, verfügt eine E-Shop Software i.d.R. über
die folgenden Seitentypen:

§ Startseite
§ Produktkategorie- und Produktdetailseiten (Kapitel 3.2.1)
§ Produktwarenkorbseite (Kapitel 3.2.2.1)
§ Bestellformular (Kapitel 3.2.2.2)
§ Kundenkontoseiten (Kapitel 3.2.8)

Das Content Management verwaltet die Texte, Grafiken und andere Mediadaten des E-
Shops. 204

Da innerhalb der Administration von E-Shops auch Personen mit weniger technischen
Fähigkeiten arbeiten, ist ein einfach zu bedienendes Seitenmanagement von Vorteil.
Integrierte grafische webbasierte Editoren, sog. WYSIWYG (what-you-see-is-what-you-get)
Editoren, erlauben es beispielsweise innerhalb des Content Management Seiten zu
bearbeiten, ohne jedoch über erweitere Programmierkenntnisse verfügen zu müssen. 205
Gleichzeitig sollte das Rechtemanagement insoweit greifen, als dass eine Benutzergruppe
Seiten anlegen bzw. bearbeiten kann, die in einem zweiten Schritt seitens einer zweiten
Benutzergruppe überprüft und veröffentlicht werden. Die Seiten können dann z.B.
hierarchisch angelegt werden. Weitere Funktionen, we z.B. Drag und Drop, können die
Verwaltung weiter vereinfachen.

203
204
205
Vgl. Stair / Baldauf, 2009, S. 453.
- 51 -


Des Weiteren sollte es über das Content Management für jeden Mitarbeiter möglich sein,
einfache HTML Codes, wie die Meta Tags und -Titles, Seitentitel, Alt-Tags und Überschriften
(z.B. <h1></h1>) über eine Benutzeroberfläche zu bearbeiten. Insbesondere die
letztgenannte Funktion, kann die Grundlage für eine verbessere
Suchmaschinenfreundlichkeit darstellen, wenn sie effektiv genutzt wird.

Grundsätzlich kann auch eine externe Content Management Software verwendet werden,
vorausgesetzt sie lässt sich an den E-Shop anbinden. Folglich muss ein komplexes
Seitenmanagement nicht zwangsläufig Bestandteil einer E-Shop Software sein, wenn eine
externe Software integriert bzw. angebunden werden kann. 206

2.2.4. Multi-Shop Funktion
Ein weiteres Feature kann eine Multi-Shop Funktion darstellen, die die Verwaltung von
mehreren E-Shops über eine zentrale Administration erlaubt. Dadurch kann der
Administrationsaufwand vermindert werden, da z.B. zahlreiche Einstellungen global
vorgenommen werden können und nicht individuell für einzelne E-Shop durchgeführt werden
müssen. Außerdem brauchen einzelne Module, wie z.B. Bezahlverfahren oder die ERP
Anbindung, nur einmal bereitgestellt zu werden, unabhängig davon wie viele E-Shops mit
Hilfe der Multi-Shop Funktion verwaltet werden.

Die Multi-Shop Funktion kann damit dem Trend multipler Geschäftsmodelle 207 Rechnung
tragen, indem über ein Back-End verschiedene E-Shops mit unterschiedlichen
Ausprägungstypen des Geschäftsmodells Aggregator verwaltet werden. D.h. es ist damit
theoretisch möglich, über einen Back-End einen Liveshopping und einen Clubverkauf E-
Shop zu verwalten. Grundsätzlich ist die Multi-Shop Funktion ist insbesondere für E-Shops
geeignet, die über ein ähnliches Produktsortiment, Geschäftsmodell und Features verfügen.

Allerdings wirkt sich ein Funktionsausfall oder Defekt der Multi-Shop Administration auch auf
alle verwalteten E-Shops aus. Außerdem muss berücksichtigt werden, dass der Multi-Shop
die Transaktionen aller E-Shops abwickeln muss und damit eine wesentlich größere Last
bewerkstelligen können muss.

Als Beispiel dafür kann die Preisbock GmbH genannt werden, die die Seiten
www.preisbock.de, www.stylebock.de und www.gadgetbock.de über eine Administration
steuert. 208

206
207
Vgl. Kapitel 2.8.
208
Vgl. Krisch, 13.01.2010.
- 52 -


2.2.5. Unterstützung für Lokalisierungen und Mehrsprachigkeit
Solle ein E-Shop auch Endkunden außerhalb des Heimatlandes ansprechen, dann bedarf es
umfangreicher Umstellungen bzw. Erweiterungen, da je nach Land, Sprache und Währung
unterschiedliche Anforderungen gestellt werden. 209 Um diesen Anforderungen zu begegnen,
muss der E-Shop grundsätzlich unterschiedliche Sprachen, Schriftzeichen und Währungen
unterstützen, sowie eine Steuersatzverwaltung bieten. Für Unternehmen mit einer
internationalen Belegschaft ist es zudem i.d.R. notwendig, dass eine Mehrsprachigkeit
gerade auch im Administrationsbereich unterstützt wird.

Z.B. muss in Deutschland, anders als in den meisten anderen Ländern, der Grundpreis
210
zusätzlich zum Endpreis auf Artikelseiten in E-Shops angezeigt werden und in
Großbritannien wird die Hausnummer z.B. vor dem Straßennamen geschrieben.

Die manuelle Anpassung der E-Shop Software kann u.U. mit einem hohen Aufwand
verbunden sein. Folglich sind vorgefertigte Lokalisierungspakete für eine E-Shop Software,
die Standardübersetzungen, Währungsumstellungen, sowie rechtliche Aspekte, wie die
Anzeige von Steuersätzen an bestimmten Stellen beinhaltet von Vorteil.

2.2.6. Web Analytics
Web-Analytics beschäftigt sich mit der Messung, Sammlung, Analyse und Auswertung von
Internetdaten. 211 Die Web Analytics Association definiert Web Analytics wie folgt: „Web
Analytics is the measurement, collection, analysis and reporting of Internet data for the
purposes of understanding and optimizing Web usage.“ 212

Zu den Zielen der Web Analytics gehören:
§ die Verbesserung der Navigation
§ die Optimierung der Online Marketingkampagnen
§ die indirekte Erfolgsmessung von Offline-Kampagnen
§ die Verbesserung von Bestell- und Registrierungsprozessen
§ die Erkennung von Problemfeldern innerhalb der Webseite
§ die Vorbereitung möglicher Testszenarien
§ die Anpassung der Webseite an die technische Ausstattung der User

209
Vgl. Gutzman, 13.01.2010.
210
Vgl. Föhlisch, 13.01.2010.
211
Vgl. Aden, 2009, S. 13.
212
Web Analytics Association, 14.01.2010.
- 53 -


Die E-Shop Software kann zum Erfolg der Web Analytics beitragen, indem sie nutzbare
Kennzahlen ermittelt und zur Analyse und Auswertung beiträgt.

I.d.R. werden im Bereich der Web Analytics weitere spezialisierte Produkte wie z.B. von den
Unternehmen Omniture oder etracker eingesetzt. Des Weiteren können andere Kennzahlen,
wie z.B. Finanzkennzahlen, wie beispielsweise der Umsatz je Kundengruppe, Umsatz nach
Tageszeit oder Produktgruppe, über die jeweilige ERP (Enterprise Resource Planing)
Software ermittelt werden. Folglich sind die Web Analytics Funktionen der E-Shop Software
auch nur optional und kein in jedem Fall notwendiges Feature.

2.2.7. Suchmaschinenfreundlichkeit
Da ein großer Teil aller E-Shop Besucher, i.d.R. über eine Suchmaschine Zugang zum E-
Shop findet, stellt die Suchmaschinenfreundlichkeit des E-Shops ein wichtiges Kriterium dar.
Laut einer Studie von ComScore, wurden im März 2008 in Deutschland 3,9 Milliarden
Suchen von insgesamt 36 Millionen verschiedenen Internetnutzern durchgeführt. Pro Nutzer
einer Suchmaschine sind das gerundet 109 Suchen pro Monat bzw. über drei Suchen pro
Tag. 213 Einer weiteren Studie zufolge wurden 2004 74% aller Internetnutzer durch eine
Suchmaschine bzw. Suchkatalog, auf eine Internetseite aufmerksam. 214 Aufgrund dieser
Bedeutung von Suchmaschinen, hat sich die Disziplin der Suchmaschinenoptimierung,
oftmals auch als search engine optimization (SEO) bezeichnet, entwickelt. 215

Da jedoch die Algorithmen der Suchmaschinen geheim gehalten und stetig weiterentwickelt
werden, ist es prinzipiell sehr aufwendig zuverlässige Kriterien für eine
Suchmaschinenoptimierung zu ermitteln, womit auch die Schwierigkeit der
Suchmaschinenoptimierung begründet wird. Verschiedene Autoren weisen auf weit über 100
Kriterien für die Suchmaschine Google hin, wobei nur ein Bruchteil dieser einen direkten
Bezug zur E-Shop Software hat. 216Allerdings muss die Zuverlässigkeit diverser Aussagen
und Auflistungen von Kriterien aufgrund ihres oftmals spekulativen Charakters mit Vorsicht
betrachtet werden. Nichtsdestotrotz, weisen sie auf die z.T. hohe Komplexität einer
Suchmaschinenoptimierung und die mangelnde Transparenz hin.

Grundsätzlich wird mit on-page und off-page Optimierung zwischen zwei Verfahren der
217
Suchmaschinenoptimierung unterschieden. Wenn Eingriffe zu
Suchmaschinenoptimierungs-Zwecken an einer Webseite selbst vorgenommen werden, d.h.

213
Vgl. comScore, 14.01.2010.
214
Vgl. Wirth, 2006, S. 25.
215
Vgl. Chaffey u.a., 2008, S. 509.
216
Vgl. Chaffey u.a., 2008, S. 509f; North, 2009, S. 196f; Smarty, 15.01.2010.
217
Vgl. Chaffey u.a., 2008, S. 509-511.
- 54 -


am Quellcode, dann spricht man von on-page Optimierung und andernfalls von off-page
Optimierung. Da die off-page Optimierung durch online Marketing Aktivitäten über externe
Webseiten erfolgt, ist sie für die Evaluierung von E-Shop Software nicht relevant. Somit steht
nachfolgend lediglich die on-page Optimierung im Vordergrund.

Theoretisch kann eine on-page Optimierung an jeder beliebigen Webseite vorgenommen
werden, jedoch wird der Arbeitsaufwand erheblich vermindert, wenn bereits
suchmaschinenfreundliche Strukturen vorhanden sind. Dies kann u.a. durch
218
suchmaschinenfreundliche Produktkataloge, URLs ohne Session IDs oder die effektive
Ausnutzung von HTML Codes, wie Meta Tags, Alt-Tags, oder Seitentitel 219 erfolgen. Ein E-
Shop Software kann also den Arbeitsaufwand für einen Teilbereich der
Suchmaschinenoptimierung erheblich verringern und damit die Grundlage für einen
kontinuierliche Verbesserungsprozess stellen.

2.2.8. Kundenmanagement
Die Aufgabe des Kundenmanagements ist es, die Beziehung zwischen E-Shop Betreiber
und Endkunden zu pflegen. 220 Brink und Berndt argumentieren in diesem Sinne, dass es
nicht ausreicht eine Geschäftsbeziehung herzustellen, wenn sie anschließend nicht effektiv
gepflegt wird und sehen E-Commerce als wichtigen Interaktionspunkt zwischen Endkunden
und E-Shop Betreiber. 221 Für das effektive Management der Kundenbeziehungen empfiehlt
sich ein sog. Customer Relationship Management (CRM) System. 222

Die Kundenverwaltungsfunktionen stellen einen wichtigen Bestandteil einer E-Shop Software
dar. Allerdings kann das CRM z.B. ein Teil des ERP (Enterprise Resource Planing) oder
auch eine eigenständige Anwendung innerhalb des Informationssystems eines
223
Unternehmens darstellen. Eine E-Shop Software kann eine spezialisierte CRM
Anwendung i.d.R. nur schwer ersetzen, zumal die weiterführende Kundenpflege nicht zu den
Kernaufgaben einer E-Shop Software gezählt werden muss.

Da der E-Shop die erste Anlaufstelle für den Endkunden darstellt und dieser hier seine Daten
eingibt, erwartet er auch seine Kundendaten hier zu einem späteren Zeitpunkt wieder
abrufen, ggf. bearbeiten oder weitere Information, wie z.B. den Bestellstatus abrufen zu
können. Für den Endkunden stellt das Kundenmanagement damit einen zusätzlichen

218
Vgl. Kapitel 3.2.2.
219
Vgl. Kapitel 3.2.3.
220
Vgl. Meier / Stormer, 2009, S. 142; Wan, 2009, S. 166.
221
Vgl. Brink / Berndt, 2009, S. 149-152.
222
Vgl. Wan, 2009, S. 165f
223
Vgl. Wolenik / Sinay, 2008, S. 18f
- 55 -


Service zum reinen Erwerb eines Gutes dar, welches zu weitergehenden
Kundenbindungszwecken, wie auch in Kapitel 3.2 mit der Transaktionsphase Dispute
beschrieben, verwendet werden kann.

Folglich müssen die Kundendaten sowohl über den E-Shop Back-End als auch Front-End
abruf und bearbeitbar sein. Der Zugriff auf individuelle Kundendaten muss, sofern nötig, z.B.
für die Bearbeitung von Serviceanfragen möglich sein, für Marketingzwecke verwendet
werden können oder für die Erstellung der Statistik abrufbar sein.

2.3. Sicherheit
Die Sicherheit des E-Shops ist eine unabdingbare Voraussetzung für das Vertrauen der
Endkunden. Die E-Shop Sicherheit richtet sich dabei in besonderem Maße an die
Transaktionssicherheit. 224

Im Internet sind i.d.R. nicht alle transaktionsbezogenen Parteien (wie z.B. Logistik- oder
Kommunikationsdienstleister) wechselseitig bekannt. Folglich besteht auch kein
umfassendes Vertrauensverhältnis. Daher bedarf es eines Konzeptes, dass die Sicherheit
aller Parteien berücksichtigt, was insbesondere für die Betrachtung der E-Shop
Transaktionssicherheit wichtig ist. 225

Kollmann beschreibt in Anlehnung an Schwarze und Schwarze 226 folgende Gefahren: 227

§ Schwachstellen in der Informationsinfrastruktur: Gefahren, die z.B. durch technische
Fehler, menschliches Versagen, Programmfehler oder Systemfehler entstehen und
das System i.d.R. nur vorübergehend unterbrechen.
§ Schwachstellen in der Umgebung: Gefahren, die in der Umgebung der
Informationsinfrastruktur, z.B. durch Erdbeben, Unwetter, Feuer, etc., entstehen.
§ Schwachstellen durch Delikte: Gefahren, die durch kriminelle Handlungen, wie z.B.
Diebstahl, Datenmanipulation oder Datenvernichtung entstehen.
§ Gefahren durch Social Engineering: Gefahren, die durch den unerlaubten Zugriff auf
vertrauliche Daten entstehen, wobei der Zugriff über den direkten Kontakt zu
Mitarbeitern entsteht.

Diese Schwachstellen müssen für die Gewährleistung der Sicherheit des E-Shops
fortwährend überprüft werden. 228 Für die Einschätzung der Gefahren für den weiteren

224
Vgl. Kollmann, 2007, S. 199
225
Vgl. Grzebiela, 2002, S. 21-24.
226
Vgl. Schwarze / Schwarze, 2002, S. 116.
227
Vgl. Kollmann, 2007, S. 199-2002.
- 56 -


Unternehmensverlauf, wird anhand von verschiedenen Kriterien eine Prioritätenliste erstellt.
Diese zur Bewertung der Gefahren dienenden Kriterien können z.B. die Schadenshöhe,
Schadensumfang, Schadensdauer und Schadenswirkung sein. Auf Basis der
Gefahreneinschätzung erfolgt die Ausgestaltung von Sicherheitsmaßnahmen.

Entsprechend der beschriebenen Schwachstellen, greift Kollmann auf ein Sicherheitskonzept
nach Schwarz und Schwarz 229 und beschreibt die folgenden Anforderungen, die bei der
Umsetzung eines Sicherheitskonzeptes beachtet werden müssen: 230

§ Vertraulichkeit: Der Austausch persönlicher Daten darf nur unter der Aufsicht
bestimmter, autorisierter und vertrauenswürdiger Personen geschehen. Das Risiko
des unbefugten Informationsgewinns soll also mit der Absicherung der Vertraulichkeit
minimiert werden. Grundsätzlich werden der Schutz der Daten und das Auffinden der
Schwachstellen für die Nachprüfbarkeit von Datenmissbrauch umso schwieriger, je
mehr Personen auf wichtige Daten zugreifen können.
§ Verfügbarkeit: Die Sicherheitsmaßnahmen müssen ständig und überall verfügbar
sein, um einen gesicherten Datenaustausch zu jeder Zeit zu unterstützen. Eine
eingeschränkte Verfügbarkeit kann negative materielle und immaterielle
Auswirkungen, z.B. in Form von Umsatz- und Imageverlusten, haben.
§ Integrität: Die Transaktionssicherheit muss durch die Integration des
Sicherheitskonzeptes in allen Schichten der Unternehmensstruktur gegeben sein.
§ Authentizität: Der Datenzugang für autorisierte Personen muss durch
Authentifizierung sichergestellt sein. Folglich muss die autorisierte Person bekannt
sein und sich ausreichend erkennbar machen.
§ Verbindlichkeit: Die Verbindlichkeit der Daten muss durch das Sicherheitskonzept
gewährleistet werden, so geht der Käufer beim Kauf beispielsweise eine
Verbindlichkeit ein.
§ Wirtschaftlichkeit: Das Prinzip der Wirtschaftlichkeit unterstellt eine Ausgewogenheit
von Aufwand und Nutzen des Sicherheitskonzeptes. Dem entsprechend müssen die
Ausgaben für die Sicherheitsmaßnahmen den Schadenskosten angemessen sein.

Die Absicherung elektronischer Systeme verursacht jedoch teilweise sehr hohe Kosten. Vor
der Betrachtung der Sicherheitsmechanismen im E-Commerce wird hier deshalb ein Konzept
vorgestellt, mit dem die optimalen Kosten für ein Sicherheitskonzept bestimmt werden
können. Meist ergibt sich das Dilemma, dass zunehmende Sicherheit mit überproportionalen

228
229
Vgl. Schwarze / Schwarze, 2002, S. 119.
230
- 57 -


Kosten verbunden ist. 231 Gleichzeitig, steigt der Nutzen der Sicherheit mit der Zunahme des
Umfangs der Sicherheitsmaßnahmen, was zu geringeren Schadenskosten führt. In diesem
Sinne zeigt die Abbildung 14 den Verlauf der Kosten für Sicherheitsmaßnahmen und
Schadenskosten. Um das Prinzip der Wirtschaftlichkeit nach Schwarz/Schwarz zu wahren,
sollte das System so gesichert werden, dass die Gesamtkosten möglichst gering sind.

Kosten

Gesamtkosten

Kosten für
Sicherheitsmaßnahmen Schadenskosten

Umfang der
Optimum
Sicherungsmaßnahmen

Abbildung 14: Optimierungsproblem von Sicherheitsmaßnahmen 232

Diesem Konzept nach, ist eine vollkommene Absicherung aus Kostengründen nicht
anstrebenswert. Es sollte zwischen den Kosten für Sicherungsmaßnahmen und den zu
erwarteten Kosten im Schadensfall abgewogen werden. Aus den idealtypischen
Kostenfunktionen lässt sich eine aggregierte Kostenfunktion errechnen (fett gezeichnet),
deren Minimum das kostenoptimale Sicherungsniveau auszeichnet. Allerdings ist in der
Realität jedoch dieses Konzept nur sehr bedingt anwendbar, da die Kosten der
Schadensfälle i.d.R. nicht vollständig bestimmt werden können. Außerdem ist es fraglich, ob
Unternehmen ihre Präferenzen modellgerecht formulieren können oder ob man
Maßnahmenpakete zur Systemabsicherung tatsächlich so genau abstimmen kann.

Das Risikomanagement Model nach Schneider (Abbildung 15) ermöglicht eine detailliertere
Betrachtungsweise und setzt die Kosten und Wahrscheinlichkeit eines Risikofalls in
Beziehung zueinander, um vier Handlungsoptionen zu empfehlen. Diesem Modell nach
würden Erdbeben als Risikofaktor, z.B. beim Serverstandort San Francisco in den zweiten
Quadranten fallen, wobei dieser Risikofaktor beim Serverstandort Hamburg dem vierten

231
Schwarz/Schwarz, 2002 S. 119.
232
Übernommen aus Schwarze / Schwarze, 2002, S. 119.
- 58 -


Quadranten zugeordnet werden könnte, da schwere Erdbeben in Hamburg anders als in San
Francisco unwahrscheinlich sind.

hohe
Wahrscheinlichkeit

in Kauf
nehmen und Prevention
kontrollieren

geringfügige
Auswirkungen

Absicherung
Ignorieren oder
Notfallplan

geringe
Wahrscheinlichkeit

Abbildung 15: Risikomanagement Model 233

2.3.1. Sicherheitsmechanismen
Für die Umsetzung einer Sicherheitsstrategie bedarf es unterschiedlicher
Sicherheitsmechanismen, die im Folgenden dargestellt werden.

Die folgende Tabelle stellt die wichtigsten Abwehrmechanismen im Bereich der E-Commerce
Sicherheit in einer Übersicht dar.

Mechanismus Beschreibung Schutzzweck 234
Kryptografie Kryptografie beschäftigt sich mit der Vertraulichkeit,
Informationsverschlüsselung sowie der Integrität und
Informationsentschlüsselung Authentizität
Digitale Zertifikate Digitale Zertifikate dienen zur Integrität und
Identifikation von Authentizität
Kommunikationspartnern
Firewalls Firewalls bestehen aus einer oder Verfügbarkeit und
mehreren Komponenten, welche Vertraulichkeit

233
In Anlehnung an Schneider, 2004, S. 398.
234
Vgl. Mertens, Peter, 2001, S. 274; Wölfl, 2006, S. 10; Alexander, 2006, S. 203-207.
- 59 -


zwischen mindestens zwei Netzen den
Zugriff auf Hosts und Netze
überwachen und beschränken.
Virtual Private Ein VPN ist ein Netzwerk von Vertraulichkeit
Networks mindestens zwei Rechnern über
Tunnels, welches öffentliche Netze
verwendet und in der Regel durch
kryptografische Verfahren gesichert ist.
Instrusion-Detection- Intrusion-Detection-Systeme (IDS) Verfügbarkeit
System erkennen und reagieren automatisch
auf Eindringlinge in ein geschütztes
Netzwerk.
Tabelle 7: Sicherheitsmechanismen 235

Nicht alle dargestellten Sicherheitsmechanismen stehen jedoch in direktem Bezug zur E-
Shop Software und sind nicht gleichermaßen relevant. Da die E-Shop Software nach
Reynolds und Staires Betrachtungsweise in Kapitel 2.5, abhängig von den
Schlüsselkomponenten Server Hardware, Server Betriebssystem und Server Software ist,
sind diese neben der E-Shop Software maßgeblich relevant für die Sicherheit.

In den nachfolgenden Kapiteln werden die Sicherheitsmechanismen Kryptografie und
Zertifikate näher erläutert, da diese sehr gängige Schutzmechanismen im E-Commerce
darstellen. 236

2.3.2. Kryptografie
Der Begriff Kryptografie setzt sich aus den griechischen Wörtern krypto und grapho
zusammen, die als Geheimnis und schreiben übersetzt werden können. Die Kryptografie ist
also eine Wissenschaft, die sich mit dem Erstellen von Nachrichten beschäftigt, die nur
237
Sender und Empfänger lesen können. Mit Hilfe der Kryptografie soll eine
vertrauenswürdige Verbindung hergestellt werden. 238

235
Vgl. Alexander, 2006, S. 203-207.
236
Vgl. Patton / Josang, 2003, S. 79-81; Thomson / Welling, 2009, S. 407-410.
237
Vgl.Schneider, 2004, S. 418.
238
Vgl.Janowicz, 2006, S. 249.
- 60 -


Die Kryptografie unterscheidet sich insofern von der Steganografie, als dass bei der
Steganografie die Verwendung der Daten nicht bemerkt werden soll und damit die
Übertragung der Daten für Dritte nicht erkannt wird. 239

Grundsätzlich können mit Hash Coding, asymmetrischer Kryptografie und symmetrische
Kryptografie zwischen drei Kryptografie Typen unterschieden werden. 240 Eine E-Shop
Software kann diese Schutzmechanismen sehr vielfältig nutzen, z.B. für die Verschlüsselung
von Zugangsdaten oder den sensiblen Kundendaten innerhalb des E-Shops.

Trotz sicherer Übertragungsmöglichkeit, kann mit reiner Verschlüsselung noch keine
Authentizität gewährleistet werden, da man nicht sicher sein kann, dass das Gegenüber
derjenige ist, welcher er behauptet zu sein. 241 Diese Problematik wird in 3.4.2. Digitale
Zertifikate näher behandelt.

2.3.2.1. Hash Coding Kryptografie
Hash Coding ist ein Prozess, der einen Hash Algorithmus nutzt, um einen sogenannten
242
Hash Wert aus einer Nachricht heraus zu generieren. Es ist dabei höchst
unwahrscheinlich, dass aus zwei unterschiedlichen Nachrichten jeweils der identische Hash
Wert generiert wird. 243 Diese Methode eignet sich insbesondere, um zu überprüfen, ob eine
Nachricht während der Übertragung verändert wurde, da der Hash Code der vom Empfänger
generiert wird nicht mit dem des Versenders übereinstimmt.

2.3.2.2. Asymmetrische und symmetrische Kryptografie
Die Sicherheit der Kryptografie liegt nicht darin möglichst komplexe Verfahren zu entwickeln
und diese geheim zu halten. 244 Vielmehr liegt die Sicherheit darin, dass die Menge der
möglichen Schlüssel so groß ist, dass ein Angreifer sie nicht durchprobieren kann. Bei einer
Schlüssellänge von z.B. 128 bit gibt es 280 (zwei hoch 80) mögliche Schlüssel. Wenn ein
Angreifer nun je Sekunde eine Milliarde Schlüssel durchprobieren kann, dann benötigt er
also ca.38 Millionen Jahre. Jede Verlängerung des Schlüssels um einen Bit, verdoppelt
jeweils den Aufwand für den Angreifer.

239
Vgl.Swoboda / Spitz / Pramateftakis, 2008, S. 1.
240
Vgl.Schneider, 2004, S. 419.
241
Dustdar / Gall / Hauswirth, 2003, S. 413.
242
243
244
Swoboda / Spitz / Pramateftakis, 2008, S. 2.
- 61 -


1976 veröffentlichten Diffie und Hellman einen wegweisenden Artikel zur asymmetrischen
Krypthographie. 245 Darauf aufbauend, haben 1977 Ronald Rivest, Adi Shamir und Leonard
Adleman das RSA Verfahren erfunden. 246

Die asymmetrische Kryptografie nutzt für die Codierung ein Schlüsselpaar, das aus einem
geheimen und einem nicht geheimen Teil besteht. Der nicht geheime Teil ist i.d.R. öffentlich
verfügbar, wohingegen der nicht öffentliche Teil vom Besitzer geheim gehalten wird. Bei der
symmetrischen Kryptografie hingegen wird derselbe Schlüssel für die Codierung und
Decodierung genutzt und muss folglich sowohl Sender als auch Empfänger bekannt sein.
Gelingt es einem Angreifer in den Besitz des Schlüssels zu kommen, dann kann er die
gesamte Kommunikation mitlesen. 247

Asymmetrische Verfahren haben zum einen den Vorteil, dass kein geheimer Schlüssel
übertragen werden muss, da der Sender den nicht geheimen Schlüssel des Empfängers
nutzt. Zum anderen, erlauben asymmetrische Schlüssel die Nutzung von digitalen
Signaturen. Dazu benutzt die unterschreibende Person ihren eigenen geheimen Schlüssel.
Mit seinem öffentlichen Schlüssel kann jeder diese digitale Signatur nachprüfen. Da nur die
unterschreiende Person Zugang zu ihrem geheimen Schlüssel hat, kann sie die digitale
Signatur nicht abstreiten.

2.3.3. Digitale Zertifikate
Digitale Zertifikate dienen dazu, Angriffe mittels einer gefälschten Identität zu vermeiden. 248
Im Prinzip kann jede Person ein Zertifikat abfassen und signieren, das angibt eine gewisse
Person bzw. Organisation zu sein. 249 Folglich wird i.d.R. eine dritte Partei, eine sog.
Zertifizierungsstelle, hinzugezogen, die Zertifikate nur nach einer Identitätsprüfung
signiert. 250 Damit bescheinigt, die als seriös geltenden Zertifizierungsstelle dem jeweiligen
Computer, dass er tatsächlich der ist, der er vorgibt zu sein. Dazu schickt der Server dem
Client sein Zertifikat, sodass der Benutzer die Echtheit überprüfen kann.

Da Informationen grundsätzlich nur so vertrauenswürdig, wie der Unterzeichner des
Zertifikats selbst sind, werden insbesondere im E-Commerce von seriösen
Zertifizierungsstellen signierte Zertifikate genutzt. 251

245
Informatik-Handbuch Von Peter Rechenberg, S. 248.
246
247
Janowicz, 2006, S. 248.
248
Vgl. Janowicz, 2006, S. 149.
249
Vgl. Thomson / Welling, 2009, S. 407.
250
Vgl. Thomson / Welling, 2009, S. 407f.
251
Vgl. Thomson / Welling, 2009, S. 407f; Dustdar / Gall / Hauswirth, 2003, S. 413.
- 62 -


Digitale Zertifikate werden üblicherweise für verschlüsselte Übertragungen verwendet, da
durch die Kombination beider Mechanismen ein deutlicher Beitrag zur Verbesserung der
Vertraulichkeit, Integrität und Authentizität geleistet wird. Dafür ist es jedoch notwendig, dass
die E-Shop Software diese Mechanismen, soweit wie möglich unterstützt. Das nachfolgende
Kapitel stellt dazu ein Beispiel dar.

2.3.4. Hypertext Transfer Protocol
Hypertext Transfer Protocol Secure (HTTPS) dient der sicheren Kommunikation zwischen
Web-Browser und Web-Server. Der Begriff HTTPS stellt eine Zusammenfassung von Secure
Sockets Layer (SSL) und Hypertext Transfer Protocol Secure (HTTP) dar. 252 SSL wurde
1994 von der Firma Netscape entwickelt und wurde drei Jahre später von der IETF zum
internationalen Standard TLS (Transport Layer Security) erklärt. Man spricht, allerdings auch
heute noch von SSL, obwohl eigentlich TLS gemeint ist. Das Ziel von SSL besteht darin,
einen Tunnel zwischen zwei Anwendungen zu schaffen.

HTTPS basiert auf asymmetrischen Verschlüsselungsmethoden für die Authentifizierung und
auf symmetrischen Verschlüsselungsmethoden für die Verschlüsselung der
Kommunikation. 253 Unter Verwendung eines sog. Handshake-Protokolls findet zunächst eine
geschützte Identifikation und Authentifizierung der Kommunikationspartner statt. Während
dieser Prozedur wird dem Client, d.h. in diesem Fall dem Web Browser, u.a. das digitale
Zertifikat vorgezeigt. 254

Anschließend wird mit Hilfe asymmetrischer Verschlüsselung oder des Diffie-Hellman-
Schlüsselaustauschs ein gemeinsamer symmetrischer Sitzungsschlüssel ausgetauscht.
Dieser wird schließlich zur Verschlüsselung der Daten verwendet. 255

Der Diffie-Hellman-Schlüsselaustausch oder Diffie-Hellman-Merkle-Schlüsselaustausch ist
ein Protokoll aus dem Bereich der Kryptografie. Mit ihm erzeugen zwei
256
Kommunikationspartner einen geheimen Schlüssel, den nur diese beiden kennen. Die
nachfolgende Abbildung zeigt dazu die einzelnen Schritte des Schlüsselaustauschs.

252
Vgl. Haenni, 2006, S. 155f.
253
254
255
256
Vgl. Witt, 2007, S. 147
- 63 -


Client Server

ClientHello
ServerHello
Zertifikat
Server Schlüsselaustausch
ServerHelloDone
Client Schlüsselaustausch
Finished
Finished

SSL-gesicherter Datenverkehr

Abbildung 16: Die einzelnen Schritte des Schlüsseltausch 257

HTTPS stellt ein Anwendungsbeispiel der Kryptografie und ein digitales Zertifikat im E-
Commerce dar und ist insbesondere für den Schutz sensibler Bereiche von E-Shops, wie
dem Back-End oder des Bestellformulars geeignet. Da die Verwendung von HTTPS im E-
258
Commerce mittlerweile zum allgemeinen Standard gehört, wird die Unterstützung auch
von E-Shops erwartet.

2.3.5. Administratorenrechte und -überwachung
Die Klassifizierung von Mitarbeitern, die im Bereich des E-Shop Back-Ends arbeiten, und die
entsprechende Vergabe von Rechten, kann dazu beitragen, den Anforderungen der
Vertraulichkeit gerecht zu werden. Mitarbeitern würden dann bei den Zugriffsmöglichkeiten
insofern eingeschränkt, als das sie keine Administrationsrechte hätten, um bewusst oder
unbewusst auf sicherheitssensible Daten zuzugreifen. Zudem kann durch die Einschränkung
der Rechte vermieden werden, dass die betreffenden Mitarbeiter unbefugt auf Daten
zugreifen können, die in keinem Zusammenhang zu ihrer Arbeit stehen.

Des Weiteren können automatisch erstellte Aufzeichnungen von Arbeitssitzungen einzelner
Mitarbeiter, zur Analyse von sicherheitsrelevanten Ereignissen verwendet werden.

257
Vgl. Haenni, 2006, S. 157.
258
Vgl. Jowers, 2006, S. 112
- 64 -


2.4. Strategie

Das Wertbeiträge-Modell in Kapitel 2.9 hat gezeigt, dass je mehr ein E-Shop Betreiber
Leistungen externer Dienstleister in Anspruch nimmt, desto stärker es auch strategisch
abhängig von diesem Dienstleister ist. Grundsätzlich besteht bei allen Distributions-
Modellen, außer bei Eigenentwicklungen eine strategische Abhängigkeit von individuellen
Unternehmen in Bezug auf die E-Shop Software. Dieses Kapitel befasst sich in erster Linie
mit der Bewertung von E-Shop Softwarehersteller. I.d.R. ist eine vollständige strategisch
Abhängigkeit eines E-Shop Betreiber zum Softwarehersteller unvermeidbar. Externe
Dienstleister, die nur Teilarbeiten erledigen können u.U. einfacher ausgetauscht werden.
Somit besteht zu diesen eine ungleich geringere strategische Abhängigkeit. Gleichwohl kann
das Vorhandensein einer Vielzahl an Dienstleistern für eine E-Shop Software, als ein
unterstützender Faktor betrachtet werden.

Wie insbesondere die Kapitel 2.5 und 2.6 gezeigt haben, stellt die E-Shop Software einen
sehr wichtigen Bestandteil einer E-Shop Plattform dar und wird i.d.R., soweit vorhanden, mit
weiteren Applikationen, wie z.B. der Warenwirtschaft verbunden. Daher ist ein vollständiger
Wechsel der E-Shop Software mit einem entsprechend großen Aufwand verbunden. Aus
diesem Grund sind langfristige Kooperationen aus Kostengründen vorteilhaft, weswegen die
strategische Bewertung des E-Shop Softwareherstellers, nicht unterschätzt werden sollte.

Jedes Unternehmen, das vor dem Problem der Evaluierung eines E-Shop
Softwareherstellers steht, muss im ersten Schritt festlegen, welche Kriterien für die
Entscheidung von Bedeutung sind. 259 Klassische Lieferantenmanagement-Methoden eignen
sich jedoch nur bedingt, da sie i.d.R. Kriterien vorschlagen, die nicht vorbehaltlos auf IT
Dienstleister im E-Commerce Umfeld anwendbar sind. Appelfeller und Buchholz schlagen
Kriterien vor, die sie den Kategorien Qualität, Strategie und Organisation, Wirtschaftlichkeit,
Logistik, Technologie und Ökologie zuordnen. 260 Die Kriterien sollen allgemein anwendbar
sein und Unternehmen als Ganzes bewerten. 261 Für E-Shop Softwaredienstleister entfällt
jedoch die Kategorien Logistik und auch die Kategorie Ökologie kann vernachlässigt werden,
da es zu keinen direkten nennenswerten Umweltbelastungen kommt.

Stoyan schlägt in diesem Sinne die folgenden Kriterien vor: 262

§ Stabilität des Anbieters
§ Größe und damit Lieferfähigkeit

259
Janker, 2008, S. 77-86.
260
Vgl. Appelfeller / Buchholz, 2005, S. 47.
261
Vgl. Appelfeller / Buchholz, 2005, S. 47.
262
Vgl. Stayon, Robert, 2007, S. 132-135.
- 65 -


§ Referenzen
§ Reputation am Markt
§ Technische oder auch branchenspezifische fachliche Fokussierung

Die sinnvolle Verknüpfung der Kriterien nach Stoyan mit den Kriterien nach Appelfeller und
Buchholz führt zum folgendem Kriterienschema:

Service Finanzkraft Marktpräsenz
Supportleistungen, Umsatzwachstum, Umsatz, Kundenbasis, Fokussierung,
Dokumentation Unternehmensgröße Reputation, Dienstleister,
Community

2.4.1. Service
Service kann als eine professionelle Tätigkeit definiert werden, die von einem
Geschäftspartner für einen anderen vollbracht wird und den Zustand des anderen, gemäß
seinen Wünschen, verändert. 263 Diese Services können z.B. Presales- oder Aftersales
Unterstützungen darstellen. 264

Allerdings hängt der Wert des Services stark vom subjektiven Eindruck der Person oder
Organisation ab, die Services in Anspruch nimmt. Van Bon greift zur Beschreibung des
Wertes eines Services, auf eine Definition der Information Technology Infrastructure Library
(ITIL) auf, die mit Utility und Warranty, d.h. also mit Nutzen und Absicherung, zwei
beschreibende Größen definiert. 265 Utility bezeichnet die positiven Effekt eines Services, d.h.
als was real erbracht wurde. Die Utility steigert entweder die Leistungsfähigkeit oder
verringert die Beschränkungen. 266 Die Warranty hingegen, beschreibt die Absicherung der
267
positiven Effekte die erzielt wurden. Abbildung 17 stellt die beschriebenen
Zusammenhänge visuell dar und zeigt die Auswirkungen von Sevices auf die Leistung.

263
Vgl. Hehl, 2008, S. 105.
264
Vgl. Hehl, 2008, S. 105.
265
Vgl. van Bon, 2007, S. 24f.
266
Vgl. Ebel, 2008, S. 97f.
267
Vgl. Ebel, 2008, S. 97f.; van Bon, 2007, S. 24f.
- 66 -


Ausbalanciert,
hochwertig

ity
H

til
ig

U
h

h
W

ig
ar

H
ra
nt
y

Minimaler Einfluss auf die Nennenswerter Einfluss auf
Leistung, aber die Leistung, aber
weitreichende Absicherung gerinfügige Absicherung
Lo
w
ity

W
til

ar
U

r
an
w

ty
Lo

geringwertig

Abbildung 17: Services zur Generierung von Werten 268

Zu den wesentlichen Leistungen des Softwareherstellers gehört die kontinuierliche
Weiterentwicklung der E-Shop Software, die je nach Distributions-Modell auch nur durch
diesen erfolgen kann. Allerdings müssen Support Dienstleistungen im allgemeinen nicht
zwangsläufig vom Softwarehersteller erbracht werden, sondern können auch von externen
Dienstleistern und online Communities erbracht werden. Allerdings muss darauf hingewiesen
werden, dass das Vorhandensein von externen Dienstleistern und aktiven Communities vom
Betreibermodell 269 einer E-Shop Software abhängt, da ein z.B. bei einer Miet-Software
bereits wesentliche Leistungen erbracht werden und die Eingriffsmöglichkeiten auch nur
begrenzt sind. Bei quelloffener Software z.B. ist die Nachfrage nach externen Dienstleistern
und einer aktiven Community ungleich größer, wobei eine breite Dienstleisterlandschaft
grundsätzlich ist positiv zu sehen ist, wie in Kapitel 3.4.3.2 näher erläutert wird.

268
In Anlehnung an van Bon, 2007, S. 26.
269
Vgl. Kapitel 2.8.
- 67 -


2.4.1.1. Supportleistungen
Grundsätzlich können Support Dienstleistungen in vielfältiger Form bereitgestellt werden.
Dabei können die Supportleistungen als eigenständige Dienstleistungsprodukte angeboten
werden, deren Preis je nach Dienstleistungsumfang variiert.

Das Support leistende Unternehmen kann z.B. Ticket- und Bug Tracking Systeme, sowie
CRM Systeme nutzen, um eine hohe Supportqualität sicherzustellen. 270

Bei Ticket Systemen wird für jeden Supportfall, ein elektronisches Ticket erstellt, auf das
i.d.R. die ganze Support Abteilung Einsicht hat. Die Tickets werden in der Regel für einen
gewissen Zeitraum gespeichert, so dass stets auf die vergangenen Supportfälle eines
Endkunden zurückgegriffen werden kann. 271 Bug Tracking Systeme unterscheiden sich
insofern vom Ticket System, als dass unterschiedliche Supportfälle in Form von Tickets, u.U.
auf einen einzigen Bug zurückgeführt werden könnten, weswegen die Trennung der
Systeme vorteilhaft sein kann. Jeder Bug kann einer Prioritätsstufe und einem Grad der
Schwere zugeordnet werden. CRM Systeme speichern die vollständige Kommunikation mit
einem Endkunden, wobei die Informationen oft nicht nur vom Support sondern z.B. auch von
Marketing und Vertriebsabteilungen genutzt werden. Allerdings können Ticket und Bug
Tracking Systeme auch Module eines CRM Systems darstellen. 272

Diese drei dargestellten Systeme garantieren keinen hochwertigen Support, jedoch weisen
sie zumindest auf ein professionelles Supportmanagement hin.

Die Kommunikation sollte neben dem Internet auch telefonisch und persönlich erfolgen
können. Als weitere Kriterien können z.B. die erreichbaren Arbeitszeiten des Supports, die
unterstützten Sprachen und die garantierten Reaktions- bzw. Antwortzeiten hinzugezogen
werden.

2.4.1.2. Dokumentation
Dokumentationen werden i.d.R. von der E-Shop Software entwickelnden Firma bereitgestellt
und sollten möglichst verständlich, umfangreich, aktuell und in verschiedenen Sprachen
verfügbar sein. In einigen Fällen werden Dokumentationen auch von Communities erarbeitet
bzw. zusammengetragen.

Eine vollständige Dokumentation kann helfen, Fehler und damit auch zusätzlichen
Arbeitsaufwand von vorneherein zu vermeiden. Allerdings hat auch eine gute Dokumentation

270
Vgl. Windley, 2001, S. 5-8.
271
272
- 68 -


eng gesetzte Grenzen, da sie nur schwer die z.T. sehr hohe Komplexität individueller Fehler
erfassen kann. Eine hohe Komplexität kann durch das Zusammenspiel von Server und E-
Shop Software, die Einbindung externer Software und die individuellen Wertbeiträge 273 durch
externe Dienstleister und das eigene Unternehmen, entstehen. Hier kann u.a. externer
Support oder der Erfahrungsaustausch durch online Communities helfen.

2.4.2. Finanzkraft
Die Betrachtung des Umsatzwachstums, Umsatzes und der Unternehmensgröße, dient in
erster Linie dazu, die wirtschaftliche Zukunftsfähigkeit und Stabilität des Softwareherstellers
und damit auch dessen Produktweiterentwicklung, in die Evaluierung mit einzubeziehen.

Die Kriterien Umsatz und Umsatzwachstum können auf den finanziellen Erfolg eines
Unternehmens und seiner Produkte schließen lassen. Ein langfristiger Erfolg spricht
Grundsätzlich für zufriedene E-Shop Betreiber und gibt einen Hinweis darauf, dass die E-
Shop Software auch in Zukunft weiterentwickelt wird und werden kann.

Langfristige, zuverlässige Umsatzzahlen zu einer E-Shop Software sind allerdings nicht
immer ermittelbar. Auch ist es, je nach Unternehmensgröße und Produktvielfalt, nur bedingt
möglich, den finanziellen Erfolg eines Gesamtunternehmens auf die im Interesse stehende
E-Shop Software zu beziehen. Des Weiteren bedarf es langfristiger Zahlen, da ein
kurzfristiger finanzieller Erfolg keine stichhaltigen Interpretationen bezüglich eines
nachhaltigen Erfolges zulässt, wobei viele Unternehmen erst seit wenigen Jahren am Markt
bestehen und somit aus dem Raster fallen würden.

Folglich müssen, wenn die Kriterien Umsatzwachstum und Umsatz nicht sinnvoll
herangezogen werden können, andere Kriterien, wie die Gesellschafterstruktur,
Investorenziele, Investitionsvorhaben und besondere Ereignisse, wie Auslandsexpansion,
Unternehmenskäufe und -verkäufe, in der Evaluierung berücksichtigt werden. Verfügt das
betroffene Unternehmen über eine stabile Gesellschafterstruktur und ist finanzkräftig und
langfristig orientiert, dann ist das i.d.R. von Vorteil. Sind die Investoren jedoch kurzfristig
orientiert und beabsichtigen z.B. das Unternehmen zu zerschlagen oder drängen auf hohe
Dividendenzahlungen, die eine finanzielle Belastung für den Softwarehersteller darstellen,
dann ist das negativ zu bewerten.

Als weiteres Kriterium für die Finanzkraft kann die Unternehmensgröße herangezogen
werden. Ein Großunternehmen, das über diversifiziertes Produktportfolio verfügt, ist eher in

273
Vgl. Kapitel 2.9.
- 69 -


der Position langatmige Investitionen durchzuführen und kurzfristige Misserfolge
wegzustecken, als ein Kleinunternehmen.

Allerdings ist die Unternehmensgröße als Kriterium mit großer Vorsicht heranzuziehen, da
die Zusammenarbeit u.U. zu anderen Nachteilen führen kann. Die Fachzeitschrift monitor
argumentiert, dass man bei kleineren Softwareherstellern als Abnehmer bedeutend wichtiger
ist, als bei Großunternehmen. 274

2.4.3. Marktpräsenz
Relevant für die die Ermittlung der Marktpräsenz sind die Kriterien Kundenbasis,
Fokussierung, Reputation und Referenzen.

Nach Schiele empfiehlt es sich zu hinterfragen, wie gut eine Software von Community,
Markt, Unternehmen angenommen wurde, sowie bei wie vielen Unternehmen die Software
eingesetzt wird. 275 Sauer, Beeck und Hollmann zählen die Kundenbasis und Referenzen
sogar als eines der wichtigsten Auswahlkriterien. 276 Hollmann sagt dazu: „Sich Referenzen
anzuschauen, ist in der Tat unverzichtbar. Dabei zählt nicht nur das jeweilige
Geschäftsmodell des Abnehmers, sondern auch die Vergleichbarkeit von Größe und Umsatz
der Unternehmen sowie der Traffic des Online-Shops.“ 277

Allerdings muss diese Aussage, aufgrund Hollmanns Position als Vorstandvorsitzender
eines der größten E-Shop Softwarehersteller Deutschlands, 278 das seit 18 Jahren bereits am
Markt ist, 279 kritisch betrachtet werden, da bei diesem Kriterium Softwarehersteller, die sich
seit kürzerer Zeit am Markt befinden das Nachsehen haben. Nichtsdestotrotz stellt die
Erfahrung eines Unternehmens ein wichtiges Kriterium dar 280 und wird durch die Kriterien
Kundenbasis, Reputation und Referenzen berücksichtigt.

Im Betrieb befindliche E-Shops sind im Internet frei einsehbar, wodurch es i.d.R. ohne sehr
großen Aufwand möglich ist, den Softwarehersteller der jeweiligen E-Shops zu ermitteln.
Dadurch kann z.B. u.U. ermittelt werden, welche E-Shop Software vergleichbare bzw.
konkurrierende Unternehmen einsetzen, wenn diese Informationen nicht bereits allgemein
bekannt sind. Beeck empfiehlt weiterhin sich die Budgetgröße der Referenzen nennen zu

274
Vgl. Weiss, 2005, S. 18.
275
Vgl. Schiele, 18.01.2010.
276
Vgl. Schinagl, 18.01.2010.
277
Schinagl, 18.01.2010.
278
Vgl. Buenstorf / Fornahl, 2006, S. 350-358.
279
Vgl. Intershop AG, 18.01.2010, S. 2.
280
Vgl. Hutzschenreuter, 2009, S. 220.
- 70 -


lassen. 281 Ein dadurch verschaffter Gesamteindruck kann durch die Hinzuziehung einer
Referenzliste unterstützt werden.

2.4.3.1. Online-Community
Der Begriff Online-Community wird heutzutage häufig und vielfältig verwendet und steht
oftmals für Synonyme wie virtuelle Community, virtuelle Gemeinschaft oder virtuelle
Gruppe. 282 Figallo beschreibt eine Community als ein Geflecht gegenseitiger Beziehungen
von Mitgliedern mit ähnlichen Interessen. 283

Howard Rheingold definiert eine virtuelle Gemeinschaft als „soziale Zusammenschlüsse, die
dann im Netz entstehen, wenn genug Leute diese öffentlichen Diskussionen lange genug
führen und dabei ihre Gefühle einbringen, so dass im Cyberspace ein Geflecht persönlicher
Beziehungen entsteht“. 284 Gemäß der Definition von Web 2.0, 285 nehmen die Teilnehmer
einer Online Community damit eine gestaltende Rolle ein und beteiligen sich an öffentlicher
Diskussionen.

Durch die Gemeinsamkeiten einer Community fühlen sich die Teilnehmer miteinander
verbunden. Verfolgen die Teilnehmer aufgrund ihrer gemeinsamen Interessen ein
bestimmtes Ziel, nennt man sie auch Community of Practice (COP). Innerhalb einer COP
findet eine intensive Kommunikation und ein reger Austausch von Informationen statt.
Vergleichbar mit einer betrieblichen Organisation nur mit dem Unterschied, dass kein
übergeordnetes Management oder ähnliche Hierarchieform besteht. 286 Entsprechend der
unterschiedlichen Interessen und Ziele können sehr vielfältige Online Communities
entstehen, die sehr verschiedene Zielgruppen ansprechen.

Aus Sicht von E-Shop Betreiber bietet sich zusammenfassend die Möglichkeit an, auf
bestehende Erfahrungswerte zurückzugreifen und mit Personengruppen, die ähnliche
Interessen verfolgen zu kommunizieren. Aufgrund dieser Vorteile betreiben diverse E-Shop
Softwarehersteller eigene online Communities an, wie z.B. IBM WebSphere, 287 Intershop, 288

281
Schinagl, 18.01.2010.
282
Vgl. Herstatt, 2004, S. 3.
283
Figallo, 1998, S. 15.
284
Rheingold, 1994, S. 16.
285
Vgl. Kapitel 2.8.
286
Vgl. Walcher, 2007, S. 36-37.
287
Vgl. IBM, 24.02.2010.
288
Vgl. Intershop, 24.02.2010.
- 71 -


ORACLE iStore 289 und insbesondere auch Anbieter quelloffener E-Shop Software, wie z.B.
Magento, 290 OXID eSales 291 oder xt:Commerce. 292

Da Softwarehersteller ein bestimmtes Interesse daran, dass kein negativer öffentlicher
Eindruck durch offene Fragen und Sachverhalte entsteht.

insbesondere wenn die Zielgruppe übersichtlich ist

Unternehmen erhalten in den Nutzern hoch qualifizierte Akteure, die sie in ihre
Wertschöpfungsprozesse integrieren. Communities ermöglichen eine neue Art von
Kollaboration, wodurch das Web 2.0 auch aus Sicht der Wirtschaft an Bedeutung gewinnt.

2.4.3.2. Externe Dienstleister
Das Vorhandensein vieler Dienstleister stellt für eine E-Shop Software ein wichtiges
Kriterium dar. Das Angebotsspektrum von spezialisierten Dienstleistern kann von Modul
Entwicklungen, Supportdienstleistungen, speziell abgestimmten Serverlandschaften bis zum
vollständigen Management von E-Shops reichen. Externe Dienstleister haben daher ein
starkes Interesse am Erfolg und der Weiterentwicklung einer E-Shop Software. Somit kann
eine aktive und dynamischer Dienstleisterlandschaft als ein unterstützender Faktor
betrachtet werden. Oftmals kooperieren die E-Shop entwickelnden Unternehmen mit
Dienstleistern, indem sie diese bewerben und teilweise gemeinsam auftreten. Z.T werden
auch Dienstleistern kostenpflichtige Partnerschaften seitens des E-Shop Softwareherstellers
angeboten.

Insgesamt kann durch eine breite Dienstleisterlandschaft die strategische Abhängigkeit zum
Softwarehersteller verringern, da verschiedene Dienstleistungen u.U. von externen
Dienstleistern bezogen werden können. Folglich ist es insgesamt positiv zu beurteilen, wenn
der Softwarehersteller aktiv die Entstehung einer Dienstleisterlandschaft unterstützt, indem
er entsprechend dafür wirbt und sich kooperativ zeigt. Andersherum ist es aus Sicht der E-
Shop Betreiber negativ, wenn der Softwarehersteller externe Dienstleister blockiert, um z.B.
keine Konkurrenz zu seinen eigenen Serviceprodukten entstehen zu lassen.

289
Vgl. ORACLE, 24.02.2010.
290
Vgl. Magento Commerce, 24.02.2010.
291
Vgl. OXID eSales, 24.02.2010.
292
Vgl. xt:Commerce, 24.02.2010.
- 72 -


3. Evaluierungsmodell
Dem digitalen Handbuch der Bibliothekswissenschaft nach, wird der Begriff Evaluation als
„die Abschätzung von Leistungen, die nicht exakt messbar sind, und daher nach jeweils
vorgegebenen Kriterien eingestuft werden“ definiert. 293

Die Gesellschaft für Evaluation e.V. liefert eine noch umfangreichere Definition: „Evaluation
ist die systematische Untersuchung des Nutzens oder Wertes eines Gegenstandes. Solche
Evaluationsgegenstände können z.B. Programme, Projekte, Produkte, Maßnahmen,
Leistungen, Organisationen, Politik, Technologien oder Forschung sein. Die erzielten
Ergebnisse, Schlussfolgerungen oder Empfehlungen müssen nachvollziehbar auf empirisch
gewonnenen qualitativen bzw. quantitativen Daten beruhen.“ 294

In diesem Hauptkapitel wird im Wesentlichen die Methodik für die E-Shop Software
Evaluierung entwickelt und diskutiert. Die Methodik stellt im Prinzip die Hülle des
Evaluierungsmodells dar. In diesem Sinne stellen die Anforderungen und Grundlagen die in
den vorherigen Kapiteln erarbeitet wurden, die empirische Basis für die inhaltliche
Ausgestaltung des Evaluierungsmodells dar. Gleichzeitig werden auf Basis der vorherigen
Kapitel konkrete Kriterien definiert.

Die Methodik für die Evaluierung wird in den folgenden Kapiteln systematisch durch eine
theoretische Auseinandersetzung und praktische Anwendung erarbeitet. Nachdem bisher
jegliche Diskussionen weitestgehend isoliert von Kostenaspekten geführt wurden, werden in
Kapitel 4.5 die Total Costs als zusätzliche Dimension herangezogen.

Grundsätzlich muss das Evaluierungsmodell es erlauben, E-Shop Software sowohl
alleinstehend als auch vergleichend evaluieren zu können. Zu diesem Zweck werden zwei
Verfahren vorgestellt, die nachfolgend als Nutzwertanalyse und einfaches
Punktbewertungsverfahren bezeichnet werden. Die Nutzwertanalyse macht eine
vergleichende Evaluierung möglich und erlaubt es u.a. die Stärken und Schwächen einzelner
E-Shops gegenüberzustellen. Das einfache Punktbewertungsverfahren dient hingegen der
Evaluierung einer einzelnen E-Shop Software.

Dabei handelt es sich sowohl beim einfachen Punktbewertungsverfahren als auch der
295
Nutzwertanalyse im Allgemeinen um ein Punktbewertungsverfahren.
Punktbewertungsverfahren sind für Entscheidungsprobleme entwickelt worden, deren
optimale Lösung nicht nur von Kosten- und Erlösaspekten, sondern vorrangig von

293
Umstätter, 18.01.2010.
294
Gesellschaft für Evaluation e.V., 18.01.2010.
295
Vgl. Volkmann, 18.01.2010; vgl. Günther / Tempelmeier, 2005, S. 71.
- 73 -


qualitativen Überlegungen geprägt wird. 296 Die Einbeziehung von monetären Zielkriterien
würde zu erheblichen Zielkonflikten führen, wie in Kapitel 4.5 näher erläutert wird. Daher
werden sie zunächst außen vor gelassen.

Für die Evaluierung einer einzelnen E-Shop Software, eignet sich ein einfacheres
Punktbewertungsverfahren. Das hier dargestellte einfache Punktbewertungsverfahren dient
jedoch anders als die Nutzwertanalyse nicht vorrangig zu Vergleichszwecken und
unterscheidet sich insofern von der Nutzwertanalyse, als dass die Zielgrößen allein in
Relation zu den zuvor definierten allgemeinen Anforderungen, unter Beachtung eigener
spezifischer Anforderungen bewertet werden. Zu einem direkten Vergleich mit
Handlungsalternativen, sprich anderer E-Shop Softwares, kommt es somit nicht.

Die Nutzwertanalyse stellt eine Variante des Punktbewertungsverfahrens dar. 297 Dabei
handelt es sich um eine Methode zur Bewertung von Alternativen, die insbesondere dann
von Vorteil ist, wenn viele Kriterien für die Entscheidung von Bedeutung sind. 298 Feyhl
bezeichnet die Nutzwertanalyse als „eines der probatesten Entscheidungstechniken“ und
sagt weiterhin in Bezug auf die Auswahl von Software, dass eine Entscheidung „mit keinem
anderen Verfahren so effektiv, transparent und objektiv erledigt werden kann.“ 299 Die
Nutzwertanalyse ist aber freilich nicht frei von Kritik, wie in Kapitel 4.6 näher erläutert wird.

Der Begründer der Nutzwertanalyse, Zangemeister 300 definiert die Nutzwertanalyse als
„Analyse einer Menge komplexer Handlungsalternativen mit dem Zweck, die Elemente
dieser Menge entsprechend den Präferenzen des Entscheidungsträgers bezüglich eines
multidimensionalen Zielsystems zu ordnen.“ 301 Die Ordnung wird durch die Berechnung von
Nutzwerten für die Alternativen hergestellt. 302 Folglich werden bei der Nutzwertanalyse
mehrere, entsprechend ihrer Bedeutung für den Entscheidungsträger gewichtete Zielgrößen
berücksichtigt.

Der Funktionswert dient hier der Einordnung der Alternativen, wodurch eine ordinale
Rangfolge entsteht. 303 Die hier entwickelte Nutzwertanalyse weicht jedoch vom theoretisch
definierten Modell insofern ab, als dass Punkte primär in Relation zur Erfüllung der
Anforderung vergeben werden und nicht nur durch den reinen Vergleich der Varianten.
Gleichwohl trägt der Vergleich der zu evaluierenden E-Shop Software zu einer objektiveren

296
Vgl. Schierenbeck, 2004, S. 166.
297
Vgl. Volkmann, 18.01.2010; vgl. Günther / Tempelmeier, 2005, S. 71.
298
Vgl. Bullinger / Scheer, 2006, S. 437.
299
Feyhl, 2004, S. 94.
300
Götze, 2008, S. 180.
301
Zangemeister, 1970, S. 45.
302
Vgl. Götze, 2008, S. 180.
303
Adam, 1996, S. 412-415.
- 74 -


und eindeutigeren Bewertung einzelner Zielkriterien bei. Dieser Vorteil entfällt beim
einfachen Punktbewertungsverfahren, da es hier zu keinem Vergleich kommt.

Die Vorgehensweise bei Punktbewertungsverfahren ist im Allgemeinen durch sechs Stufen
gekennzeichnet: 304

1. Ermittlung der Ziele
2. Gewichtung der Ziele
3. Vergabe von Punkten für die Varianten
4. Multiplikation von Gewichten mit zugehörigen Punkten
5. Ermittlung der gewichteten Punkttotale
6. Sensibilitätsanalyse

Die nachfolgende Abbildung 18 stellt die Struktur des Evaluierungsmodells vereinfacht dar
und verdeutlicht zudem, dass das Evaluierungsmodell auch den direkten Vergleich einzelner
Zielkriterien und Zielkriterien-Kategorien ermöglicht.

304
Götze, 2008, S. 181
- 75 -


Zielkriterium Gewichtung
KA1 GA1

Gewichtung
Zielkriterien- der
Kategorie Zielkriterien-
KA2 GA2
ZKA Kategorie
. .
.
. .
. ZKGA

KAn GAn

KB1 GB1

Gewichtung
Zielkriterien- der
Zielkriterium Gewichtung Gesamt
KB2 GB2 Nutzwert
ZKB Kategorie
. . ZKGB
. .
.
. .
. .
.
Zielkriterium
. Gewichtung
.
KBn GBn

. . .
.
. .
.
.
.
.
. .
.
.
.
. . .
Gewichtung
Zielkriterien- der
Kmn Gmn
ZKm Kategorie
ZKGm

Abbildung 18: Struktureller Aufbau des Evaluierungsmodells

Der Aufbau, wie in Abbildung 18 dargestellt entspricht grundsätzlich dem von
305
Punktbewertungsverfahren. Mit der nachfolgenden Tabelle 8 wird die oben dargestellte
Struktur auf eine Tabelle übertragen und anhand von Variablen beschrieben. Gleichzeitig
wird nun auch der Teilnutzwert der Zielkriterien einbezogen.

Zielkriterien Gewichtung Variante Vj
Wertung Teilnutzwert
ZA1 GA1 WA1j NA1j = WA1j * GA1 * ZKGA

ZA2 GA2 WA2j NA2j =WA2j * GA2 * ZKGA
. . . .
. . . .
. . . .

305
Vgl. Götze, 2008, S. 180; vgl. Adam, 1996, S. 412-416.
- 76 -

( �( W )

z

GAn *ZKGA
ZAn GAn WAnj N Anj =WAnj * GAn * ZKGA

n=1
ZKA ZKGA ZKWA NAj= Anj *

ZB1 GB1 WB1j NB1j = WB1j * GB1 * ZKGm

ZB2 GB2 WB2j NB1j = WB2j * GB2 * ZKGm

( �( W )
. . . .
. . . .
. . . .
z

GBn *ZKGB
ZBn GBn WBnj N Bnj =WBnj * GBn * ZKGm

n=1
ZKB ZKGB ZKWB NBj= Bnj *

. . . .
. . . .
. . . .

( �( W )
. . . .
. . . .
. . . .

z
Zmn Gmn W mnj N mnj = W mnj * Gmn * ZKGm

Gmn *ZKGm
n=1
ZKm ZKGm ZKWm Nmj= mnj *

Tabelle 8: Aufbau des Evaluierungsmodells

Der Gesamtnutzwert Nj ist die Summe aller Zielkriterien-Kategorien Nutzwerte Nmj

Variable Bedeutung Variable Bedeutung

ZKm m-te Zielkriterien-Kategorie ZKGm Gewichtung der m-ten
Zielkriterien- Kategorie

Zmn n-tes Zielkriterium der m- Gmn Gewichtung des n-ten
ten Zielkriterien-Kategorie Zielkriteriums der m-ten
Zielkriterien-Kategorie

Wmnj Wertung des n-ten Nmnj Teilnutzwert des n-ten
Zielkriteriums der m-ten Zielkriteriums der m-ten
Zielkriterien-Kategorie von Zielkriterien-Kategorie von
Variante j Variante j

Nj Gesamtnutzwert der Nmj Wertung der m-ten Zielkriterien-
Variante j Kategorie
Tabelle 9: Erklärung zur Tabelle 8

Grundsätzlich sei für alle Summen in der Tabelle 8 ein allgemeiner Bereich definiert:
n = 1, . . . , z

- 77 -


ΣZKGm =1
Die Summe der Gewichtungen aller Zielkriterien-Kategorien ergibt die Zahl Eins, d.h.

ΣGAi =1.
und die Summe aller Gewichtungen der Zielkriterien innerhalb einer Zielkriterien-Kategorie
ergibt ebenfalls die Zahl 1, d.h. bei Zielkriterien-Kategorie A z.b.

Das hier entwickelte Evaluierungsmodell unterscheidet sich in seiner Methode von typischen
Nutzerwertanalysen, wie sie in der Literatur vorgestellt werden, indem es jeweils zweimal ein
Kriterium mit einer Gewichtung multipliziert. Zunächst wird jedes einzelne Zielkriterium mit
seiner zugeordneten Gewichtung multipliziert und anschließend wird der Teilnutzwert jeder
Zielkriterien-Kategorie mit der jeweils zugeordneten Gewichtung multipliziert.

Dadurch wird die Berechnung zwar aufwendiger, allerdings wird es erst dadurch möglich,

neben dem Gesamtnutzwert auch den Nutzwert jeder einzelnen Zielkriterien-Kategorie ZKm
und Zielkriteriums Zmn für weitere Analysen zu erhalten.

3.1. Ermittlung der Ziele
Die Bestimmung der Zielkriterien Zmn stellt i.d.R. den ersten Schritt einer Nutzwertanalyse

dar. 306 Die Zielkriterien müssen operational formuliert werden und auf einem nominalen,
ordinalen oder kardinalen Skalenniveau gemessen werden können. 307 Die Zielkriterien
stellen Ansprüche dar, die z.B. die Entscheidungsträger formulieren können. 308 Anschließend
können die Ziele durch die Erstellung eines hierarchischen Strukturplans systematisiert
werden. Überschneidungen und Abhängigkeiten sollten grundsätzlich vermieden werden. 309
Eine vollkommene Nutzenunabhängigkeit lässt sich aber sehr häufig nicht erzielen. 310

Um eine möglichst hohe Objektivität zu gewährleisten, ist es notwendig die Zielkriterien und
ihre Bewertung möglichst genau zu beschreiben. Als Grundlage dient das vorhergehende
Kapitel 3., worauf die nachfolgenden Zielkriterien basieren. Mit den nachfolgenden Tabellen
10 bis 13 werden Zielkriterien und Hilfskriterien definiert. Anhand der Zielkriterien werden die
Punktevergaben durchgeführt, wobei die Hilfskriterien die Punktevergabe stützen und damit
möglichst transparent und objektiv gestalten sollen.

306
Götze, 2008, S. 181f.
307
Götze, 2008, S. 181.
308
Schulte, 2001, S. 235.
309
Schulte, 2001, S. 235.
310
Götze, 2008,S.180.
- 78 -


Zielkriterien der Hilfskriterien
Architektur
Architekturstruktur § Zwei Schichten Architektur / n-Schichten Architektur /
Service orientierte Architektur

Schnittstelle § Schnittstellenunterstützung
§ Unterstützung von Standarddatenformaten
§ Datenaustausch-Management

Ladezeit § =<1Sek. / <2Sek. / <2Sek.
Tabelle 10: Ziel- und Hilfskriterien für die Kategorie Architektur

Funktionen

Produktkatalog § Dynamischer Produktkatalog
§ Medienneutralität
§ Attributbasierte- / Konstruierende- / Beratende Kataloge

Suchfunktion Die Suche erkennt:
§ Artikelnamen und -beschreibungen
§ Attribute und Schlagworte
§ Synonyme
Produktwarenkorb § Darstellung grundlegender Informationen
§ Cross- und Up-Selling Funktionen
§ persistenter Warenkorb
Bestellformular § single page Bestellformular oder vergleichbare
Vereinfachungen des Bestellprozesses
§ als Gast kaufen Option
Content Management § Verwaltung von Webseiten
§ erweitertes Rechtemanagement
§ einfache Bearbeitung ohne Programmierkenntnisse
§ WYGIWYS Editor
§ Metadaten können über eine Benutzeroberfläche
eingegeben werden.
Web Analytics § Möglichkeiten zur Datenerhebung
§ Umfangreiche Reports

- 79 -


Suchmaschinen- § suchmaschinenfreundliche Seitenbezeichner
freundlichkeit § Meta-Description und Keywords können über eine
Benutzeroberfläche eingegeben werden.
Kundenmanagement

Multi-Shop Funktion
Interntionalisierung
Tabelle 11: Ziel- und Hilfskriterien für die Kategorie Funktionen

Sicherheit
Back-End Benutzerrechte § Gruppierung von Benutzern
und -überwachung § individuelle Vergabe von Rechten
Sicherheits-mechanismen § Einsatz von Verschlüsselungstechnologien
§ HTTPS Unterstützung
Tabelle 12: Ziel- und Hilfskriterien für die Kategorie Sicherheit

Strategie
Support § Dienstleisterlandschaft
§ Dokumentation
§ Community
§ Supportleistungen
Finanzkraft § Umsatz
§ Unternehmensgröße
Marktpräsenz § Kundenbasis
§ Fokussierung
§ Reputation
§ Referenzen
Tabelle 13: Zielkriterien für die Kategorie Strategie

- 80 -


3.2. Gewichtung der Ziele
Aufgrund der Tatsache, dass nicht alle Zielkriterien Zmn gleich bedeutend für die Erreichung
des Gesamtzieles sind, wird jedem Zielkriterium eine Gewichtung Gmn zugeordnet. 311 Somit
gibt die Gewichtung der Ziele an, wie viel das Erreichen des jeweiligen Ziels zum Nutzwert

beitragen soll. Dazu ist es erforderlich Zmn nicht nur mit der Gewichtung Gmn zu

multiplizieren, sondern auch mit der Gewichtung der jeweiligen Zielkriterien-Kategorie,
daraus ergibt sich dann der Teilnutzwert des Zielkriteriums N mnj .

Die Herleitung der Gewichtungen ist auf Basis der Vorschläge und Definitionen
verschiedener Autoren und die daraus hergeleiteten Anforderungen aus Kapitel 3 erfolgt, wie
die Tabellen 14 und 15 darstellen.

Zielkriterien-Kategorie Gewichtung
Architektur 20%
Funktionen 40%
Sicherheit 20%
Strategie 20%
Tabelle 14: Die Gewichtung der Zielkriterien-Kategorien

Zielkriterien Gewichtung
Architektur:
Architekturstruktur 60%

Schnittstelle 20%

Ladezeit 20%
Funktionen:
Produktkatalog 20%
Suchfunktion 10%
Produktwarenkorb 10%
Bestellformular 10%
Internationalisierung -
Content Management 20%
Web Analytics 10%
SEO Funktionen 10%

311
Vgl. Schulte, 2001, S. 237.
- 81 -


Kundenmanagement 10%
Multi-Shop Funktion -
Sicherheit:
Back-End Benutzerrechte und -überwachung 50%
Sicherheitsmechanismen 50%
Strategie:
Service 50%
Finanzkraft 25%
Marktpräsenz 25%
Tabelle 15: Die Gewichtung der Zielkriterien

Die Zielkriterien Internationalisierung und Multi-Shop Funktion sind nur für Projekte mit einem
entsprechenden internationalen Hintergrund bzw. der Absicht mehrere E-Shops mit
ähnlichen Sortimenten zu betreiben relevant. Daher werden beide Zielkriterien zunächst
vernachlässigt indem sie mit null Prozent gewichtet werden.

Optional können Zielkriterien zudem als KO-Kriterien definiert werden, in diesem Fall führt
ihre Nichterfüllung zum Ausschluss einer weiteren Betrachtung der jeweiligen Variante bzw.
312
in diesem Fall der E-Shop Software. Mit der Definition von KO-Kriterien können
individuelle Bedürfnisse berücksichtigt werden. 313

Theoretisch kann jedes beliebige Kriterium als KO-Kriterium definiert werden. Eine
pauschale Aussage darüber, welche Kriterien sich besonders als KO-Kriterien eignen ist
prinzipiell nicht möglich, weil dies von individuellen Rahmenbedingungen abhängt.

Das Zielkriterium Back-End Benutzerrechte und -überwachung kann z.B. ein KO-Kriterium
sein, wenn eine Vielzahl von Mitarbeitern mit jeweils unterschiedlichen Aufgabenbereichen,
direkt am Back-End Veränderungen vornehmen sollen und die Benutzerrechte aus
Sicherheitsgründen eingeschränkt werden müssen. Ansonsten könnten Mitarbeiter mit
redaktionellen Aufgaben z.B. versehentlich Kundenbestellungen löschen.

Die in der Tabelle 15 aufgeführten Gewichtungen stellen Vorschläge, insbesondere für Kauf-
und quelloffene Software dar, 314 wobei je nach Unternehmen und Rahmenbedingungen eine
Anpassung der Gewichtung notwendig sein kann. Für eigenentwickelte- und Miet-Software
sind je nach dem in wieweit externe Dienstleistungen in Anspruch genommen werden,
deutliche Anpassungen notwendig. Wenn ein Unternehmen z.B. zwei eigenentwickelte E-
Shops evaluieren möchte, dann sind die strategischen Kriterien Finanzkraft und
312
Vgl. Informatik Forum Simon GmbH, 20.01.2010.
313
Vgl. Labonde, 1986, S. 101f.
314
Vgl. Kapitel 2.9.
- 82 -


Marktpräsenz irrelevant und können vernachlässigt werden. Für die Evaluierung von Miet-
Software, die nach Kollmann der Kategorie Partner-Modell zugeordnet werden kann, 315 ist
die Architekturstruktur aus Sicht eines E-Shop Betreibers zunächst irrelevant, da das
Unternehmen, dass die E-Shop Software anbietet, nach Definition des Betreibermodells in
Kapitel 2.9 sämtliche Dienstleistungen, wie die Administration, Bereitstellung der E-Shop
Software und das Hosting erbringt. Durch die hohe strategische Abhängigkeit, rücken
gleichwohl die strategischen Kriterien verstärkt in den Vordergrund und können höher
gewichtet werden. Insgesamt kann also festgestellt werden, dass die Gewichtung von der
strategischen Abhängigkeit, d.h. also der Position beim Wertbeiträge-Modell bzw.
letztendlich dem Distributionsmodell der E-Shop Software abhängt.

Aufgrund diesem nicht zu vernachlässigen Einflussfaktor für die Bestimmung der
Gewichtung, wird an dieser das Wertbeiträge-Modell aus Kapitel 2.9 aufgegriffen und für die
Beschreibung der Auswirkungen der strategischen Abhängigkeit für die Bestimmung der
Gewichtung instrumentalisiert.

Betreiber Dienstleister Partner

Untergewichten: Übergewichten:
§ Alle strategischen § Alle strategischen
Zielkriterien Zielkriterien
Untergewichten:
§ Alle Zielkriterien
der Kategorie
Architektur

Abbildung 19: Über- oder Untergewichtung von Zielkriterien je nach Betreibermodell

Freilich handelt es sich um eine sehr allgemeine Betrachtung der Abhängigkeiten zwischen
Betreibermodell und der Zielkriterien Gewichtung. Z.B. kann die Betrachtung der
strategischen Zielkriterien einer Eigenentwicklung im Vergleich zu anderen
Betreibermodellen gerade auch zu Grundsatzdiskussionen genutzt werden, da eine solche
Evaluierung zwangsläufig zu Fragen nach der Auslagerung von Kompetenzen führt.

Die aufgeführten Beispiele und Diskussionen zeigen, dass die Möglichkeit die Gewichtung zu
variieren, das Evaluierungsmodell sehr flexibel machen und den jeweiligen
Rahmenbedingungen Rechnung tragen können, was je nach Distributionsmodell auch
zwingend notwendig sein kann.

315
Vgl. Kapitel 2.9.
- 83 -


3.3. Vergabe von Punkten für die Varianten
Je nach Erfüllungsgrad wird jedem Zielkriterium eine bestimmte Wertung Wmnj
zugeordnet. Theoretisch kann das Evaluierungsmodell aus sowohl quantitativen als auch
qualitativen Kriterien bestehen, wobei gerade bei letzteren die Gefahr einer subjektiven
Bewertung groß ist. 316 Da die hier vorgestellten Kriterien für das Evaluierungsmodell nahezu
vollständig qualitativer Natur sind, ist es besonders wichtig, subjektive Einflüsse möglichst
einzudämmen, indem die in Kapitel 4.1 definierten Hilfskriterien für die Vergabe von
Wertungen einbezogen werden. Da es jedoch stets verschiedene Wege gibt, um bei einem
Kriterium sehr gut bzw. besser als eine bei der Evaluierung konkurrierende E-Shop Software
abzuschneiden, kann es von Fall zu Fall empfehlenswert sein, über die vorgeschlagenen
Hilfskriterien hinaus auf besondere Merkmale zu achten.

Z.B. kann es sein, dass eine E-Shop Software Mängel aufgrund einer bestimmten fehlenden
Funktion aufweist. Wenn jedoch dieser Mangel erwiesenermaßen durch die nachträgliche
Integration eines externen Moduls ohne ersichtliche Nachteile behoben werden kann, dann
sollte dies positiv für die Wertung berücksichtigt werden. Wie das Beispiel zeigt, können die
Ziel- und Hilfskriterien i.d.R. keinen Anspruch auf absolute Vollständigkeit stellen.

3.4. Punkttotale

( �( W )
Die Summe aus den Multiplikation von Gewichtung und Wertung für jedes Zielkriterium einer

z

Gmn *ZKGm
n=1
Nmj= mnj *

( �( W )
und die anschließende Multiplikation dieser Summe mit der Zielkriterien-Kategorie

Gewichtung ZKGm führen zum Teilnutzwert einer Zielkriterien-Kategorie:

z

Gmn *ZKGm
n=1
Nmj= mnj *

Der Gesamtnutzwert Nj ist die Summe der Teilnutzwerte aller Zielkriterien-Kategorien Nmj .

316
Götze, 2008, S. 207.
- 84 -


3.5. Einführung der Total Cost of Ownership als weitere
Dimension
Die Kosten einer E-Shop Software stehen in Abhängigkeit verschiedener Faktoren, die z.T.
bereits diskutiert wurden. Dazu können z.B. die strategischen Zielkriterien und hier
insbesondere die Serviceleistungen, bestimmte Features wie die Multi-Shop Funktion oder
die eines vorintegrierten Content Management Systems, oder auch die Architekturstruktur
wenn z.B. Erweiterungen notwendig sind gezählt werden.

Folglich würde die Einbeziehung der Kosten als eigenes Zielkriterium zwangsläufig zu einer
Vielzahl von Abhängigkeiten der Kriterien untereinander führen. Gleichwohl, kann zuerst der
Nutzwert ausgerechnet und dann in einem zweiten Schritt den jeweiligen Kosten gegenüber
gestellt werden. 317

Der Kostenbegriff bedarf im Zusammenhang mit einer E-Shop Software und bei IT
Anschaffung im Allgemeinen, einer eindeutigeren Definition, weil unterschiedliche Kosten
über den Lebenszyklus einer E-Shop Software anfallen. 318

Im Jahr 1987 stellte das amerikanische IT-Marktforschungsunternehmen Gartner Group fest,
dass i.d.R. primär die finanziellen Anschaffungskosten berücksichtigt werden, wobei die im
laufenden Betrieb entstehenden Kosten zu intransparent betrachtet und insgesamt
vernachlässigt werden. 319 Daher entwickelte die Gartner Group mit dem als Total Costs of
Ownership (TCO) bezeichneten Ansatz ein Model zur Betrachtung der Gesamtkosten, d.h.
aller direkten und indirekten Kosten eines Datenverarbeitungssystems, die während seiner
Nutzungsdauer anfallen. 320 Insgesamt bezieht das TCO Modell nach Gartner mehr als 50
Einflussfaktoren ein, wie Anhang 1 zeigt.

Das TCO Model stellt somit eine Weiterentwicklung der reinen
Anschaffungskostenperspektive dar. Als weiteres TCO Model kann u.a. das Modell von
Forrester Research genannt werden, dass sich im Wesentlichen durch eine weniger starke
Beachtung der Wertverluste während der Nutzungsdauer, von Gartners Modell
unterscheidet. 321 Verschiedene andere TCO Modelle, wie z.B. von der META Group,
basieren ebenso wie das Model von Forrester Research auf dem TCO Model der Gartner
Group. 322

317
Vgl. Kopacek / Zauner, 2004, S. 188.
318
Vgl. Henning, 2004, S. 29-31.
319
Vgl. Wild / Herges, 2000, S. 3.
320
Vgl. Brügge u.a., 2004, S. 116.
321
Vgl. Wild / Herges, 2000, S. 17.
322
Vgl. Wild / Herges, 2000, S. 16-19.
- 85 -


Krcmar greift das TCO Modell auf und kombiniert es mit dem typischen Lebenszyklus eines
Systems, wobei er Gartner's Modell deutlich vereinfacht darstellt, wie Abbildung 20 zeigt. 323

Upgrade / Neu-
Beschaffung Einführung Betrieb
beschaffung

Hardware Migrationsplanung Administration
Software Softwareverteilung Wartung
Overhead: Schulung Weiterentwicklung
Lizenz IT-Personal Externer Support
Management, Anwender
Inventory, Externe Beratung
Einkaufs- Datenübernahme
abwicklung Softwareanpassung

Abbildung 20: Systemlebenszyklus und relevante Kosten 324

Wie bereits Kollmanns Betrachtung eines E-Shops als Plattform und die pyramidenartigen
Gliederung der Schichten einer E-Shop Plattform nach Reynolds und Staire in Kapitel 2.5.,
ebenso wie die Darstellung der Softwarekomponenten in Kapitel 2.7. gezeigt hat, stellt die E-
Shop Software ein einzelner Baustein innerhalb eines Systems dar. Folglich ist eine
vollständig isolierte Betrachtung der Kosten einer E-Shop Software losgelöst von seiner
Umwelt, wie das TCO Modell von Gartner bereits erkennen lässt, nicht sinnvoll. Vielmehr
bedarf es also einer umfangreichen TCO Analyse zur individuellen Erfassung der Kosten für
die jeweilige E-Shop Software unter Einbeziehung aller relevanten Einflussfaktoren.

Gleichwohl kann eine vollständige Analyse nach Gartner's Modell je nach Unternehmen und
Projekt sehr aufwendig sein. Folglich muss abgewogen werden, ob die Einbeziehung aller
Faktoren notwendig ist oder eine Vereinfachung in Kauf genommen werden soll.

Für die Identifizierung besonders relevanter Kostenfaktoren zum Zwecke einer einfacheren
Kostenerfassung, eignet sich die Verknüpfung des TCO Modells von Gartner mit dem
wesentlich einfach gestalteten E-Shop Kostenmodell nach Laudon und Traver. Laudon und
Traver schlagen die Unterscheidung der folgenden Kosten vor: inhaltliche und optische
Gestaltung, Software, Hardware, Telekommunikation, Systementwicklung und -wartung. 325
Allerdings gehen Laudon und Traver nicht sehr in die Tiefe und lassen damit Raum für eine
flexible Ausgestaltung des Kostenmodels. Die folgende Tabelle stellt zum Zwecke der
Identifizierung von Kostenfaktoren mit besonderer Relevanz in Bezug auf die Auswahl von E-

323
Vgl. Krcmar, 2004, S. 279-282.
324
Übernommen von Krcmar, 2004, S. 279.
325
Vgl. Laudon / Traver, 2009, S.4,17.
- 86 -


Shop Softwares, Faktoren aus dem TCO Modell von Gartner unter Einflussnahme der
Vorschläge von Laudon und Traver dar:

Pfad des Kostenfaktors Kostenfaktor
Direkte Kosten >> Hardware- und Software >> Anwendungssoftware
Direkte Kosten >> Technischer Support >> Konfiguration der Hardware
Direkte Kosten >> Technischer Support >> Software Installation
Direkte Kosten >> Verwaltung >> Schulung der Endanwender
Direkte Kosten >> Verwaltung >> Schulung der Mitarbeiter der EDV-
Abteilung
Indirekte Kosten >> End-User-Operations >> Lernen im Arbeitsalltag
(Produktivitätsverluste - entgangene Löhne
und Gehälter)
Indirekte Kosten >> End-User-Operations >> Self Support, Peer-to-Peer Support
Indirekte Kosten >> End-User-Operations >> Schulungsmaßnahmen (formales Lernen)
Tabelle 16: Für eine E-Shop Software relevante Kostenfaktoren

Aus Abbildung 21 nach Krcmars sowie Laudon und Travors Kostenfaktoren geht hervor,
dass die Software-Installation und die damit einhergehende Softwareanpassung innerhalb
der Einführungsphase zu den relevanten Kostenfaktoren gezählt werden können. Schließlich
muss bedacht werden, dass eine E-Shop Software den spezifischen Anforderungen des
jeweiligen Geschäftskonzeptes sowohl in Bezug auf die Optik als auch Funktionalität
angepasst werden muss. Dazu stellen Laudon und Traver einen Graphen vor, der die
Relation der Kosten zu den Anpassungen idealistisch darstellt: 326

326
- 87 -


Kostenfaktor

12

10

8

6

4

2

0
Prozensatz des
0 2 4 6 8 10 12
Quellcodes, das
angepasst wird

Abbildung 21: Kosten der Anpassung einer E-Shop Software 327

Laudon und Traver beziffern die typischen Kosten für die optische und funktionale
Anpassung auf 37% der Gesamtkosten, 328 wobei wie mehrfach erläutert, kritisch angemerkt
werden muss, dass sowohl die Zeichnung eines vermeintlich typischen Szenarios und damit
auch der Begriff Gesamtkosten sehr relativ sind und von einer Vielzahl von Faktoren
abhängen, wie u.a. das TCO Modell und die Darstellung der Betreibermodelle zeigen.
Deswegen wird an dieser Stelle Abstand von weiteren u.U. vermeintlich typischen
Zahlenangaben genommen.

Außerdem muss beachtet werden, dass je nach Betreibermodell, unterschiedliche Faktoren
berücksichtigt werden müssen. Z.B. können bei einer Miet-Software alle Hardware
bezogenen Faktoren vernachlässigt werden. 329

Freilich sind die Kosten ebenso ein elementarer Bestandteil für die Auswahl der E-Shop
Software, wie der Nutzwert. Jedoch ist die vollständige Ermittlung der Kosten jedoch recht
komplex und individuell. Der hohe Aufwand für die Implementierung und Anwendung des
TCO Modells wird insbesondere vor dem Hintergrund kritisiert, dass TCO Modelle, wie die
von Gartner, von IT-Analysten mit dem Ziel entwickelt werden, die Modelle inklusive
Beratungsdienstleistungen zu verkaufen. 330 Für eine einfachere Analyse können die hier
ermittelten und in Tabelle 16 dargestellten Faktoren herangezogen werden.

327
In Anlehnung an Laudon / Traver, 2009, S.4,11.
328
329
Vgl. Kapitel 2.9.
330
Vgl. Bullinger, Hans-Jörg u.a., 1998, S.14.
- 88 -


3.6. Kritische Betrachtung der Methodik
Die Methodik des Evaluierungsmodells dient prinzipiell dem Zwecke, die Evaluierung
möglichst objektiv zu gestalten. Somit kann für die Identifizierung der Schwächen und
Stärken an diesem Punkt angesetzt werden und kritisch hinterfragt werden, ob ein
ausreichendes Maß an Objektivität tatsächlich gewährleistet wird.

Letztendlich vergibt eine Person oder eine Gruppe von Personen die Punkte für jedes
Zielkriterium. Somit hängt die Bewertung zwangsläufig auch von den Fähigkeiten und
Präferenzen des Individuums oder Gruppe von Individuen ab. Gleichzeitig können
unkalkulierbare persönliche Faktoren zu einer subjektiven Einflussnahme führen. Im
Extremfall wird für ein deutlich subjektiv beeinflusstes Resultat eine falsche Objektivität mit
Verweis auf die systematische Vorgehensweise bescheinigt.

Zur Eingrenzung subjektiver Einflüsse wird in der Literatur vielfach die Bewertung in einem,
nach Fähigkeiten unterschiedlich besetztem Team vorgeschlagen. 331 Das hier entwickelte
Evaluierungsmodell hat den Anspruch durch die Definition von Zielkriterien und Hilfskriterien,
die in Kapitel 3 ausführlich diskutiert werden Objektivität zu gewährleisten. Das entwickelte
Evaluierungsmodell unterscheidet sich insofern von typischen Punktbewertungsverfahren,
als dass es jedes Zielkriterium durch nachvollziehbare Hilfskriterien stützt. Zudem wird
gerade bei der Nutzwertanalyse, durch die Gegenüberstellung mehrerer E-Shop Softwares
eine bessere Bewertungsgrundlage geschaffen, was jedoch beim einfachen
Punktbewertungsverfahren freilich nicht möglich ist.

Eine weiterer Kritikpunkt liegt in der nicht immer möglichen Vergleichbarkeit von E-Shop
Softwares. In Kapitel 4.2 wurde begründet, warum und wie die Gewichtung je nach
Distributionsmodell variiert werden muss. Daher ist es auch schwierig bis nicht möglich, E-
Shop Softwares verschiedener Distributionsmodelle zu vergleichen.

Dem kann jedoch entgegengesetzt werden, dass das Evaluierungsmodell es auch
ermöglicht einzelne Zielkriterien-Kategorien, wie Funktionen oder Architektur, isoliert zu
evaluieren und damit die Stärken und Schwächen einzelner Kategorien zu vergleichen. Ein
Vergleich der Zielkriterien-Kategorie Funktionen, ist z.B. bei allen Distributionsmodellen
möglich. Zudem kann gerade der Vergleich von Zielkriterien-Kategorien über
Distributionsmodelle hinweg helfen, ein besseres Verständnis für die Stärken und
Schwächen verschiedener Distributions-Modelle zu gewinnen.

331
Vgl. Kuster / Huber / Lippman, 2008, S.371-375; Bullinger / Scheer, 2006, S.437-439.
- 89 -


In der Literatur wird betont, dass die Zielkriterien grundsätzlich unabhängig voneinander sein
sollten, gleichwohl ist eine vollständige Unabhängigkeit in der Praxis oftmals nicht möglich. 332
Insbesondere aufgrund der Komplexität einer E-Shop Software stellt dies eine besondere
Herausforderung dar. Um dem gerecht zu werden, wurden auf Basis der Kernaufgaben einer
E-Shop Software, grundlegende Zielkriterien definiert. Dadurch ist es möglich, durch die
Kombination von Zielkriterien weitere Untersuchungen durchzuführen. Z.B. könnte durch die
Betrachtung der Zielkriterien Architekturstruktur, Ladezeit, Produktkatalog, Suchfunktion
sowie u.U. die benutzerrechte Verwaltung, Internationalisierung und Multi-Shop Funktion, die
Möglichkeiten der Skalierbarkeit der E-Shop Software untersucht werden. Umgekehrt würde
die Skalierbarkeit als Zielkriterium für das Evaluierungsmodell zu deutlichen Abhängigkeiten
zu den besagten Zielkriterien führen. Folglich kann das Evaluierungsmodell auch als
Grundlage für weitere Untersuchungen genutzt werden.

4. Beispiele aus quelloffenen Shopsystemen
In den nachfolgenden Kapiteln werden mit xt:Commerce, OXID CE und Magento drei
quelloffene E-Shop Softwares mit dem zuvor entwickelten Evaluierungsmodell evaluiert,
wobei alle drei sehr unterschiedliche Hintergründe haben, die vor jeder Evaluierung jeweils
kurz erläutert werden. Vorweg soll jedoch angemerkt werden, dass die drei E-Shop
Softwares am Markt als Konkurrenten gelten, wobei gerade Magento und OXID CE damit
werben, auch höchsten Ansprüchen gerecht werden zu können. Insbesondere die junge E-
Shop Software Magento hat zu sehr vielen kontroversen Diskussionen in der Industrie
geführt, da sie sich offen gegen etablierte Produkte positioniert hat. 333

Zweck der drei Evaluierungen ist die praktische Demonstration des entwickelten
Evaluierungsmodells. Für die Beispielevaluierungen wird angenommen, dass die E-Shop
Software für den deutschen Markt eingesetzt wird und keine besonderen Bedürfnisse zu
beachten sind. Folglich können die Zielkriterien Internationalisierung und Multi-Shop-
Funktion für dieses künstlich gezeichnete Szenario vernachlässigt werden. Gleichwohl
werden die E-Shop Software anhand dieser beiden Zielkriterien analysiert aber mit null
Prozent gewichtet, wodurch die Ergebnisse keine Berücksichtigung für das Ergebnis finden.

Zur besseren Nachvollziehbarkeit wurden alle drei E-Shop Softwares auf einem Server
installiert, wie in Kapitel 5.1 näher erläutert wird.

332
Vgl. Schulte, 2001, S. 235; vgl. Götze, 2008,S. 180.
333
Vgl. Krisch, 08.02.2010; vgl. Hedemann, 08.02.2010; vgl. Ringsdorff, 08.02.2010.
- 90 -


Für das Zielkriterium Finanzkraft wurde im Rahmen dieser Diplomarbeit auf eine
Bonitätsprüfung seitens einer Wirtschaftsauskunft verzichtet. Aufgrund des
Informationsmangels wird dieses Kriterium zugunsten der anderen strategischen Zielkriterien
vernachlässigt und mit null gewichtet.

4.1. Evaluierungsbedingungen
Alle hier durchgeführten Evaluierungen wurden über den identischen Server und unter
identischen Bedingungen durchgeführt. Beim Server handelt es sich um einen Dedicated
Server, d.h. dass er nicht geteilt wird und vollständig zu diesen Evaluierungszwecken genutzt
werden konnte.

Serverstandort: Welserstrasse 14, 51149 Köln
Server IP: 87.230.46.142
Server Hardware:
Dell PowerEdge™ R200
CPU: 1 x Quad-Core Intel®Xeon® X3330
Arbeitsspeicher: 4 GB
Festplatte: 1 x 250 GB SATA
Garantierte Bandbreite: 500 Mbit/s
Tabelle 17: Serverdaten

Die Shops können wir folgt aufgerufen werden:

xt:Commerce:
Front-End
Back-End
OXID CE:
Front-End
Back-End
Magento:
Front-End
Back-End
Tabelle 18: Links zu dem Front- und Back-Ends der E-Shops

Login Daten:

xt:Commerce OXID CE Magento
Benutzername
Passwort
Tabelle 19: Login Informationen
- 91 -


Mindestanforderungen an den Server:

Server k.A. § Apache Version 1.3 § Apache Version 1.3
oder höher oder höher
§ Mindestens 100 MB
freier Webspace
§ Ability to run
§ Installierte
scheduled jobs
mod_rewrite
(crontab) with PHP
Erweiterung
5
PHP § PHP 4.1.3 § PHP mindestens § PHP mindestens
(empfohlen >4.3.0 Version 5.2.0 Version 5.2
für 3.0.4)

PHP § GDlib mit gif § LIB XML2 § PDO_MySQL
Support § DOM § simplexml
Erweiterung
§ cURL library § JSON § mcrypt
§ ICONV § hash
§ Tokenizer § GD
§ MySQL Modul für § DOM
MySQL 5 § iconv
§ GDlib v2 [v1] incl. § curl
JPEG § SOAP (if
Unterstützung Webservices API is
§ mbstring to be used)
§ BCMath
PHP § allow_url_fopen § Safe_mode off
oder fsockopen auf § Memory_limit no
Konfiguration
Port 80 less than 256Mb
§ Zend (preferably 512)
Kompatibilitätsmod
us muss
ausgeschaltet sein
§ REQUEST_URI
vorhanden
§ ini_set erlaubt
§ register_globals
muss ausgeschaltet
sein
§ PHP Memory limit
(min. 14MB, 30MB
empfohlen)
§ UTF-8
Unterstützung
Datenbank § MySQL Datenbank § MySQL 5.0.33 oder § 4.1.20 or newer
ab >3.23.xx höher § InnoDB storage
engine
Tabelle 20: Serveranforderungen der E-Shop Software

- 92 -


4.1.1. Messung der Ladezeit
Die Ladezeiten der drei E-Shops können aus den in Kap.3.1.5. erläuterten Gründen, lediglich
zur Ermittlung einer Tendenz herangezogen werden. Um für die Ermittlung dessen, eine
möglichst hohen Grad an Objektivität zu gewährleisten wurden folgende Punkte für die
Ermittlung der Ladezeit beachtet:

§ Durchführung der Tests bei drei unterschiedlichen Dienstleistern
§ je ein Test für die Startseite (Zeile A), Kategorieseite (Zeile B) und eine Artikelseite
(Zeile C) von jedem E-Shop
§ jede Artikelseite verfügt über ein 25Kilobyte Artikelbild und 500 Zeichen Text

D1 D2 D3 D1 D2 D3 D1 D2 D3
A 1,22s 0,37s 1,11s 1,65s 0,83s 1,22s 3,82s 2,95s 1,42s
B 1,23s 0,4s 1,21s 1,75s 0,9s 1,39s 4,45s 3,19s 2,13s
C 1,26s 0,46s 1,17s 2,12s 1,08s 1,97s 4,55s 3,76s 2,42s
Gesamtdurchschnitt 0,94s 1,43s 3,19s
Tabelle 21: Ladezeiten-Test

Abkürzung Name des Serverstandort Link zur Dienstleister
Dienstleister
D1 OctaGate 334 Schweden, Stockholm http://www.octagate.com/servic
e/SiteTimer/
335
D2 1&1 Internet AG Deutschland, http://webtool.1und1.de/analyze
Montabaur /?ladezeit
D3 Projekt von Michael Australien, Melbourne http://webwait.com/
Mahemoff 336
Tabelle 22: Für die Tests genutzte Dienstleister

334
Vgl. OctaGate, 25.02.2010.
335
Vgl. 1&1 Internet AG, 25.02.2010.
336
Vgl. Projekt von Michael Mahemoff, 25.02.2010.
- 93 -


Ab- Seitentyp Xt:Commerce OXID CE Magento
kürzung
A Startseite siehe Tabelle 18 siehe Tabelle 18 siehe Tabelle 18
B Kategorieseite */index.php?cat=c1_ */Kategorie-A/ */kategorie-a.html
Kat-A.html
C Artikelseite */product_info.php?i */Kategorie- */kategorie-a/artikel-
nfo=p107_Artikel- A/Artikel-1.html 1.html
3.html
Tabelle 23: Bedingungen der Ladezeiten-Tests

Eine Erhöhung der Anzahl der Artikel und Kategorien, unter ansonsten identischen
Bedingungen führt zu keinem signifikant anderen Ergebnis, wie ein Test mit 100 Artikeln und
vier Kategorien mit dem E-Shop xt:Commerce vermuten lässt (Tabelle 24).

xt:Commerce
100 Artikel A 1,23s 0,32 1,15
verteilt auf vier B 1,24s 0,66 1,72
Kategorien C 1,24s 0,44 1,22
Tabelle 24: Ladezeitentest mit 100 Artikeln und vier Kategorien

Für eine effektivere Messung, bedarf es eines praxisnahen Testumfelds. Je besser das
Testumfeld ein realistisches Szenario simuliert, umso effektiver kann auch die Ladezeit
gemessen werden. Dazu müsste z.B. ermittelt werden in welchem Umfang unterschiedliche
Medien wie z.B. Videos, Bilder, Audio oder Text für den E-Shop genutzt werden sollen. Dem
entsprechend müssten diese Medien beispielhaft eingespielt werden. Zudem müsste eine
Vielzahl an Benutzern gleichzeitig und realitätsnah den E-Shop benutzen und Transaktionen
ausführen. Weiterhin muss beachtet werden, dass sich die hier ermittelten Ladezeiten zur
Identifizierung einer Tendenz, ausschließlich auf das Front-End beziehen.

4.2. xt:Commerce
xt:Commerce wurde 2003 von der xt:Commerce GmbH mit Sitz in Innsbruck auf Basis der
international bekannten und quelloffenen E-Shop Software osCommerce entwickelt und
gehört zu den meistgenutzten E-Shop Softwares in Deutschland. 337

osCommerce entstand im März 2000 und hatte damals noch den Namen The Exchange
Project, das als Beispielstudie für das zu der Zeit recht neue PHP entwickelt wurde. Die

337
Vgl. Zenner, 2009 S.319.
- 94 -


Software gewann in kürzester Zeit auf der ganzen Welt Anhänger und wies eine sehr aktive
Community aus. Die letzte Version 2.2 RC 2a von osCommerce wurde Januar 2008
veröffentlicht. Neben xt:Commerce, basiert auch die international verbreitete E-Shop
Software ZenCart auf osCommerce aus. 338

Bis zur Version 3.x steht xt:Commerce unter der GNU General Public Licence und ist daher
quelloffen. Der Nachfolger, die Version 4, liegt jedoch nicht mehr als quelloffene Version
vor. 339 Daher ist auch die Weiterentwicklung der quelloffenen Version fragwürdig, da die
xt:Commerce GmbH als treibende Kraft fehlt. Jedoch wird Software noch von zahlreichen
Agenturen weiterentwickelt und unter eigenem Namen vertrieben.

4.2.1. Evaluierung

4.2.1.1. Architektur

Zielkriterium Kommentar Wertung
Architekturstruktur § verfügt über eine n-Schichten Architektur; Module 2
zur Erweiterung der E-Shop Software müssen
manuell implementiert werden
Schnittstelle § SOAP Schnittstelle wird unterstützt 1,5
§ nur das Datenformat CSV wird unterstützt
§ das Datenaustausch-Management beschränkt sich
auf den Import und Export von Artikeldaten ohne
jeglichen Variationsmöglichkeiten
Ladezeit Siehe Ermittlung der Ladezeit in Kapitel 5.1.1 3
Tabelle 25: Wertung der Zielkriterien-Kategorie Architektur von xt:Commerce

4.2.1.2. Funktionen
Produktkatalog § dynamisches konstruierendes Produktkatalog, das 2
attributseitig beliebig erweitert werden kann und
medienneutral ist. Dabei handelt sich insofern um
ein konstruierendes Katalog, als dass Produkte mit
Referenzierungsdaten versehen werden können,

338
Vgl. Daeschner, 2005.S. 25-31.
339
Vgl. Willkommer, 24.02.2010.
- 95 -


die zu manuellen Cross-Selling Zwecken genutzt
werden können

Suchfunktion § Schließt Attribute, Meta-Tags, 2
Produktbeschreibungen sowie über das Content
Management erstellte Seiten mit ein
§ Synonyme müssen manuell eingegeben werden.
Die Suchfunktion erkennt von sich aus keine
Synonyme bzw. reagiert nicht tolerant bei
minimalen Abweichungen vom Suchbegriff, wie das
folgende Beispiel es verdeutlicht: Wenn der
Besucher das Produkt iPod Touch sucht und itouch
oder i-touch in die Suchmaske eingibt, wird er kein
Ergebnis geliefert bekommen. Jedoch besteht die
Möglichkeit, über die Administration manuell
Synonyme einzugeben.
Produktwarenkorb § grundlegende Informationen werden dargestellt 1
Bestellformular § Erfassung der Kundendaten und Bestätigung der 1
Bestellung bei gleichzeitiger Speicherung der IP-
Adresse
Content § WYGIWYS Editor vorhanden 1
Management
Multi-Shop Nicht möglich.
Funktion
Web Analytics § Es werden mit der Ermittlung von fünf 1
unterschiedlichen Statistiken (Werbekampagnen-,
Umsatz-, Kunden-Bestell-, verkaufte Artikel- und
besuchte Artikel-Statistik), nur sehr grundsätzliche
Daten ermitteln.
SEO Funktionen § Title-Tag, Meta-Description und -Keywords können 1
pro Produkt oder Kategorie, nicht aber CMS Seiten
festgelegt werden.
Kunden- § Es können Kundengruppen mit besonderen 2
management Rechten und Vorteilen, z.B. in Bezug auf
Produktpreise, Zahlungsverfahren und Versandart

- 96 -


eingerichtet werden. Weiterhin können alle
Kundendaten über das Back-End abgerufen und
verändert werden.
§ Über das Front-End hat der Endkunde die
Möglichkeit, seine Kundendaten einzusehen und zu
ändern, die Bestellhistorie sowie den aktuellen
Bestellstatus abzurufen
Inter- § es werden 12 Sprachpakete angeboten, worunter -
nationalisierung die gängigen europäischen Sprachen sind;
deutsche und englische Sprachpakete sind bereits
im Standard integriert
Tabelle 26: Wertung der Zielkriterien-Kategorie Funktionen von xt:Commerce

4.2.1.3. Sicherheit
Administratorenrec Es können Benutzer mit unterschiedlichen Rechten 2
hte und - erstellt werden. Es können insgesamt die Rechte für 62
überwachung unterschiedliche Aktivitäten eingeschränkt werden.
Sicherheitsmechan § Es wird ein hash code genutzt, der bei der 3
ismen Installation frei gewählt oder vom System generiert
werden, um Kennwörter und nach Bedarf,
Passwörter zu verschlüsseln.
§ Unterstützung von HTTPS Verbindungen für den
Back-End und das Bestellformular.
Tabelle 27: Wertung der Zielkriterien-Kategorie Sicherheit von xt:Commerce

4.2.1.4. Strategie
Service § xt:Commerce Version 3 wird nur noch von der 1
Community weiterentwickelt, jedoch nicht mehr vom
Softwarehersteller
§ letzte offizielle Version stammt vom 24.04.2008; es
werden regelmäßig neue kleinere Updates seitens
der Community veröffentlicht
§ es werden ein nur sehr eingeschränkte

- 97 -


Supportleistungen angeboten:
o Support-Reaktionszeit von 72 Std.
o Programmierdienstleistungen werden
ausdrücklich nicht angeboten
§ sehr umfangreiche offizielle Dokumentation ist
nebst zahlreichen inoffiziellen Dokumentationen
vorhanden
Finanzkraft Die Finanzkraft der Herstellers ist irrelevant, um -
Aussagen über die zukünftige Entwicklung zu machen,
da das getestete Produkt nicht mehr weiterentwickelt
wird.
Marktpräsenz § Laut Hersteller gibt es über 100.000 Installationen 2
§ in Deutschland grundsätzlich sehr weit verbreitet
§ eine offizielle Liste mit Dienstleistern wird nicht
geführt, allerdings ergab deutete eine eigene kurze
Recherche auf sehr viele Dienstleister hin
Tabelle 28: Wertung der Zielkriterien-Kategorie Strategie von xt:Commerce

4.3. OXID CE
Die OXID eSales GmbH wurde im März 2003 gegründet und hat ihren Sitz in Freiburg.
Neben einer quelloffenen E-Shop Software, der sog. Community Edition (OXID CE), bietet
sie noch mit einer Enterprise und Professional Edition, zwei weitere Produkte an. Allerdings
unterscheidet sich die quelloffenen OXID CE alleine durch die fehlende SOAP-Schnittstelle
von der OXID Professional Edition. Die Community Edition wurde Oktober 2008 unter
der GPL 3.0 veröffentlicht. 340

Aufgrund der längeren rein kommerziellen Historie und den nach eigenen Angaben mehr als
2.500 OXID PE und EE Lizenzen, verfügt das Unternehmen bereits über Erfahrung und
möchte, wie der Gründer und Vorstandsmitglied Roland Fesenmayr sagt, auf „Basis und mit
dem Know-how vieler fähiger Leute aus der Community eine der vielversprechendsten
Open-Source-Shop-Lösungen schaffen.“ 341 Von einigen Autoren wird dieser Schritt als eine
Kampfansage an Magento Commerce und einem Strategiewechsel hin zu neuen
Erlösformen, wie z.B. zusätzlichen Dienstleistungen gesehen. 342

340
Vgl. Krisch, 21.01.2010.
341
OXID eSales AG, 21.01.2010.
342
Vgl. Krisch, 21.01.2010; Höschl, 22.01.2010.
- 98 -


In diesem Sinne bietet die OXID eSales AG neben einer breiten Palette an
Beratungsdienstleistungen, mit eFire einen Marktplatz für Schnittstellen zu ihrer E-Shop
Software. 343

4.3.1. Evaluierung

Architekturstruktur § OXID eShop Community Edition verfügt über eine 3
Service orientierte Architektur, die sich mit Hilfe von
Plugins einfach erweitern lässt.
Schnittstelle § Eine SOAP-Schnittstelle für die Anbindung an 1
externe Systeme fehlt in der quelloffenen Version.
Dazu muss die Professional Edition bei ansonsten
gleichem Funktionsumfang erworben werden. 344
§ nur das Datenformat CSV wird unterstützt
§ das Datenaustausch-Management beschränkt sich
auf den Import und Export von Artikeldaten mit
minimalen Variationsmöglichkeiten
Performance Siehe Ermittlung der Ladezeit in Kapitel 5.1.1 2
Tabelle 29: Wertung der Zielkriterien-Kategorie Architektur von OXID CE

4.3.1.2. Funktionen
Produktkatalog § dynamisches konstruierendes Produktkatalog, das 2
medienneutral ist. Dabei handelt sich insofern um
ein konstruierendes Katalog, als dass Produkte mit
Referenzierungsdaten versehen werden, die zu
manuellen Cross-Selling Zwecken genutzt werden
können.
Suchfunktion § Schließt Attribute, Meta-Tags, 2,5

343
Vgl. OXID eSales AG, 21.01.2010a; OXID eSales AG, 21.01.2010b.
344
Vgl. OXID eSales AG, 22.01.2010c.
- 99 -


§ Endkunde und Admin können Schlagworte
eingeben, die ebenfalls gesucht werden können
§ Einstellbar, ob ein Produkt in den Suchergebnis
erscheinen soll oder nicht
Synonyme bzw. reagiert nicht tolerant bei
minimalen Abweichungen vom Suchbegriff, wie das
folgende Beispiel es verdeutlicht: Wenn der
Besucher das Produkt iPod Touch sucht und itouch
oder i-touch in die Suchmaske eingibt, wird er kein
Ergebnis geliefert bekommen. Jedoch besteht die
Möglichkeit, über die Administration manuell
Synonyme einzugeben.
Produktwarenkorb § grundlegender Informationen werden dargestellt 2
Adresse
§ als Gast kaufen Option möglich
Content § OXID Community verfügt in dieser getesteten 2
Management Version über kein integrierten WYSIWYG Editor.
Allerdings kann ein WYSIWYG Editor relativ einfach
über das Plugin System integriert werden.
§ Die einzelnen Webseiten werden ohne die
Berücksichtigung von Hierarchien aufgelistet, wobei
sie jedoch als Ordner zusammen gefasst werden
können
§ für angelegte Seiten können automatisch Links im
Hauptmenü oder einer zweiten OXID CE
spezifischen Menübox eingerichtet werden;
wahlweise können Seiten über sog.Snippet
aufrufbar gemacht werden, d.h. durch einen
einzeiligen Code ([{ oxcontent
ident=Ident_der_CMS_Seite }]) an beliebiger Stelle
kann die Seite aufgerufen werden

- 100 -


eingegeben werden
Multi-Shop Nicht möglich -
Funktion
Web Analytics Es werden mit der Ermittlung von sieben 1
unterschiedlichen Statistiken (Bestellabbrüche,
Conversion Rate, Endkunden nach Benutzergruppen,
Suchwörter, Top angesehene Artikel und top geklickte
Artikel), überwiegend sehr grundsätzliche Daten
ermittelt.
SEO Funktionen § Neben dem Seitentitel kann innerhalb des Content 2,5
Management Systems ein
suchmaschinenfreundlicher Seitenbezeichner
gewählt werden (www.e-
shop.de/kategorie1/seitenbezeichner.html).
§ Die Kategorienbezeichnungen werden in der URL
übernommen.
§ Es können eine Meta-Description und Keywords für
jede Seite, d.h. Produkt-, Kategorie- sowie CMS-
Seite, über das Content Management System
eingetragen werden.
Kunden- § es sind im Standard bereits 16 Kundengruppen, wie 3
management z.B. Blacklist, Auslandskunde oder Powershopper
angelegt; es können beliebig viele Kundengruppen
angelegt werden, Endkunden können Gruppen
zugeordnet werden, alle Kundendaten inklusive der
Bestellhistorie können abgerufen werden
Bestellstatus abzurufen und auf vier mögliche
Produktlisten (Merkzette, Wunschzettel,
Artikelvergleich und Lieblingslisten) zuzugreifen, die
er möglichweise zuvor angelegt hat
Inter- § es werde Sprachpakete für französisch, dänisch, -
nationalisierung russisch, spanisch, italienisch, und niederländische
Sprache angeboten. Englisch und deutsch sind

- 101 -


schon im Standard vorintegriert 345
Tabelle 30: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE

4.3.1.3. Sicherheit
Administratorenrec § Es können beliebig viele Nutzer Administratoren 0
hte und - sein; eine Einschränkung der Rechte ist jedoch
überwachung nicht möglich
ismen Installation frei gewählt oder vom System generiert
werden, um Kennwörter und nach Bedarf,
Passwörter zu verschlüsseln.
§ Unterstützung von HTTPS Verbindungen für den
Back-End und das Bestellformular.

4.3.1.4. Strategie
Service § wird sehr aktiv weiterentwickelt; im Jahr 2009 3
wurden zehn Updates veröffentlicht 346
§ Es werden sowohl individuelle
Beratungsdienstleistungen als auch Standard-
Supportverträge angeboten. Die
Dienstleistungspallete ist sehr umfangreich und
reicht von der Mitarbeiterschulungen bis zur
Entwicklung Betriebsfertiger E-Shops
§ ein umfangreiches Dokumentationshandbuch wird
vom Hersteller bereitgestellt
Finanzkraft § das Produkt OXID CE/PE stellt eines von zwei -
Softwareprodukten der OXID eSales AG mit Sitz in
Freiburg dar
§ die Acceres Beteiligungsmanagement GmbH & Co.
KG und LBBW Venture Capital GmbH sind mit

345
Vgl. xt:Commerce, 24.01.2010.
346
Vgl. OXID eSales AG, 24.01.2010.
- 102 -


einem siebenstelliges Investitionsvolumen an der
OXID eSales AG beteiligt 347
Marktpräsenz § bereits seit 2003 am Markt, 60 Mitarbeiter und nach 3
eigenen Angaben über 3000 Kunden
§ Bundesweit insgesamt 61 offizielle Solutions-
Partner, darunter Unternehmen wie die T-Systems
Multimedia Solutions GmbH und TWT Interactive
GmbH - sieben Hosting Partner
§ zahlreiche Referenzen mit Enterprise Shops, wie
edeka24.de und fressnapf.de
Tabelle 31: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE

4.4. Magento
Magento wurde von dem amerikanischen E-Commerce-Unternehmen Varien entwickelt,
welches im Jahr 2001 als Webagentur in Los Angeles gegründet wurde. Varien entwickelt
seit 2003 Projekte im E-Commerce Bereich, die auch vor Magento auf quelloffene E-Shop
Software basierten. 348

Die Entwicklung der E-Shop Software Magento begann das Unternehmen im Jahr 2007.
Ende März 2008 erschien die erste produktiv nutzbare Version 1.0 auf dem internationalen
Markt. Magento ist eine komplette Neuentwicklung, die den Anspruch erhebt, kostengünstig
erweiterbar und individuell anpassbar zu sein. Die Software steht unter der GNUGeneral
Public License zur Verfügung. Magento gewann im Jahr 2008 den Preis des besten
Newcomers bei den SourceForge.net Community Choice Awards. 349

Magento ist in der Programmiersprache PHP geschrieben und verwendet die Datenbank
MySQL. Die Nutzung von weiteren Datenbanken wie PostgreSQLund Oracle sind durch
entsprechende Schnittstellenanpassungen möglich. 350

347
Vgl. Krisch, 24.01.2010.
348
Vgl. Varien Inc., 24.02.2010a.
349
Vgl. Varien Inc., 24.02.2010b.
350
- 103 -


4.4.1. Evaluierung

Architekturstruktur § Magento Commerce verfügt über eine service 3
orientierte Architektur, die sich mit Hilfe eines Plugin
Systems einfach erweitern lässt. Dazu bietet der
Hersteller einen eigenen online Marktplatz für
Plugins und ein eigenes E-Shop Modul, namens
Magento Connect, für die Verwaltung von Plugins.
Schnittstelle § SOAP Schnittstelle wird unterstützt 3
§ Unterstützung der Datenformate CSV und XML
§ umfangreiches Datenaustausch-Management mit
vielfältigen Variations- und Automatisierungs-
Möglichkeiten

Ladezeit Siehe Ermittlung der Ladezeit in Kapitel 5.1.1 0

4.4.1.2. Funktionen

Produktkatalog § Magento Commerce verfügt über ein dynamisches 2
konstruierendes Produktkatalog, das von sich aus
bereits zahlreiche Attribute voreingestellt hat,
medienneutral ist. Dabei handelt sich dabei insofern
um ein konstruierendes Katalog, als dass Produkte
mit Referenzierungsdaten versehen werden können
und zu manuellen Cross- und Up-Selling Zwecken
genutzt werden können
Suchfunktion § Schließt Attribute, Meta-Tags, 2,5
§ Endkunde und Admin können Schlagworte
eingeben, die ebenfalls gesucht werden können.
§ Einstellbar, ob Produkt in Suchergebnis erscheinen

- 104 -


darf
Synonyme bzw. reagiert nicht tolerant bei minimalen
Abweichungen vom Suchbegriff, wie das folgende
Beispiel es verdeutlicht: Wenn der Besucher das
Produkt iPod Touch sucht und itouch oder i-touch in
die Suchmaske eingibt, wird er kein Ergebnis
geliefert bekommen. Jedoch besteht die Möglichkeit,
über die Administration manuell Synonyme
einzugeben.
Produktwarenkorb § Darstellung grundlegender Informationen 2,5
§ Cross-Selling möglich
Adresse
§ als Gast kaufen Option möglich
§ Single page Bestellformular bei Verwendung der
Ajax Technologie
Content § Magento verfügt in dieser getesteten Version über 2
Management keinen integrierten WYSIWYG Editor. Allerdings ist
dieser in der neueren Magento Version 1.4
integriert, die sich zu diesem Zeitpunkt allerdings
noch in der beta Phase befindet. 351 Zudem kann
auch ein WYSIWYG Editor über das Plugin System
kostenlos in die hier getestete Version integriert
werden.
§ Die einzelnen Webseiten werden ohne die
Berücksichtigung von Hierarchien aufgelistet, wobei
sie nach einigen Faktoren, wie z.B.
Einstellungsdatum oder Name, sortiert werden
können.
§ Es können sog. statische Blöcke angelegt werden,
die z.B. innerhalb verschiedener Seiten durch einen
einzeiligen Code ({{block type="cms/block"

351
Vgl. Varien Inc., 02.02.2010.
- 105 -


block_id=" Ident_der_CMS_Seite "}})
aufgerufen werden.
eingegeben werden.
Multi-Shop Es können beliebig viele E-Shops über eine einzige -
Funktion Back-End eingerichtet und verwaltet werden
Web Analytics § Es können 22 unterschiedliche Kennzahlen ermittelt 2
werden. Unter anderem Kennzahlen, wie z.B. nicht
bestellte Warenkörbe, Kundenmeinungen oder
Meinungen zu Produkten, die über eine externe
Software nur sehr schwer messbar wären.
SEO Funktionen § Neben dem Seitentitel kann innerhalb des Content 3
Management Systems ein
suchmaschinenfreundlicher Seitenbezeichner
gewählt werden (www.e-
shop.de/kategorie1/seitenbezeichner.html).
§ Die Kategorienbezeichnungen werden in der URL
übernommen.
§ Es können eine Meta-Description und Keywords für
jede Seite, d.h. Produkt-, Kategorie- sowie CMS-
Seite, über das Content Management System
eingetragen werden.
§ automatische Generierung einer
suchmaschinenfreundlichen Google Sitemap
Kunden- § Es können Kundengruppen angelegt werden, wobei 1,5
management sich die Kundengruppen lediglich in Bezug auf die
Steuerklasse unterscheiden können. Dies ist jedoch
lediglich für E-Shops relevant, die sowohl Privat- als
auch Geschäftskunden bedienen.
Weiterhin können alle Kundendaten über das Back-
End aufgerufen und verändert werden
Bestellstatus abzurufen, sein im E-Shop
abgegebenen Produktbewertungen und
Kommentare einzusehen und eine sog. Wunschliste

- 106 -


abzurufen, die er im E-Shop anlegen kann.
Inter- § es können Sprachpakete für 68 Sprachen über das -
nationalisierung Plugin System integriert werden. 352
§ Für einige Länder, wie z.B. Deutschland, Frankreich,
oder Großbritannien, können weitergehende Pakete,
die die lokale Gesetzgebungen und andere
Länderspezifischen Charakteristika anpassen,
integriert werden (für die USA schon im Standard
voreingestellt).
Für Deutschland wird von der symmetrics GmbH im
Auftrag von der in Deutschland allgemeinbekannten
Qualitätszertifizierungsunternehmen Trusted Shops
GmbH, eine umfangreiches Lokalisierungs-Paket
kostenlos angeboten. 353

4.4.1.3. Sicherheit
Administratorenrec § Es können Benutzergruppen mit unterschiedlichen 2
hte und - Rechten erstellt werden. Insgesamt umfasst die
überwachung Rechtevergabe 133 unterschiedliche Aktivitäten
innerhalb des Back-End.
ismen Installation frei gewählt werden kann, um
Kennwörter und nach Bedarf, Passwörter zu
verschlüsseln. HTTPS Verbindung werden für das
Back-End und Front-End Bestellformular
unterstützt.

4.4.1.4. Strategie
Service § wird aktiv weiterentwickelt; im Jahr 2009 wurden 17 2
Updates veröffentlicht, wobei es sich bei in vier

352
Varien Inc., 03.02.2010a.
353
Varien Inc., 03.02.2010b.
- 107 -


Fällen um offizielle Alpha oder Beta Version
gehandelt hat 354
§ Es werden sowohl individuelle
Beratungsdienstleistungen als auch Standard-
Supportverträge angeboten. Die
Dienstleistungspallete ist sehr umfangreich und
reicht von der Mitarbeiterschulungen bis zur
Entwicklung Betriebsfertiger E-Shops. Allerdings
werden alle Services seitens des Herstellers nur in
englischer Sprache angeboten.
§ eine lückenhafte Dokumentation wird online
bereitgestellt
Finanzkraft § Magento Commerce ist das einzige -
Softwareprodukt der Varien Inc. mit Sitz in Los
Angeles und über 100 Mitarbeitern. 355 Dazu gehört
das Tochterunternehmen Irubin Consulting Inc., die
Beratungsdienstleistungen anbietet.
Marktpräsenz § bereits seit März 2001 am Markt 356 2
§ Varien Inc. zählt weltweit 82 und deutschlandweit
14 offizielle Solutions-Partner, d.h. kooperierende
Dienstleister die auf die Entwicklung von Magento
E-Shops spezialisiert sind, sowie weltweit 5 offizielle
Hosting Partner, die auf Magento ausgerichtete
Hosting Dienstleistungen anbieten und 8 offizielle
sog. Industry-Partner, die diverse andere
Dienstleistungen, wie z.B. Bezahlverfahren,
anbieten. Jedoch muss angemerkt werden, dass
Varien Inc. Gebühren für die Kooperation verlangt
und die Gesamtzahl der Unternehmen, die Magento
spezifische Dienstleistungen anbieten somit aller
Wahrscheinlichkeit nach wesentlich höher liegt.
§ zahlreiche deutsche und internationale Referenzen
mit Enterprise Shops, wie jack-wolfskin.com,
alpedia.de, lodgerfootwear.com und homedics.com

354
355
356
- 108 -


4.5. Zusammenfassung der Evaluierung von xt:Commerce, OXID
CE und Magento
Die nachfolgende Tabelle zeigt die Zusammenfassung der Evaluierung der E-Shop
Softwares OXID, Magento und xt:Commerce.

Zmn Gmn xt:Commerce OXID CE Magento
(Variante a) (Variante b) (Variante c)
W mna N mna W mnb N mnb W mnc N mnc
Architektur:

Architekturstruktur 60% 2,00 0,24 3,00 0,36 3,00 0,36
Schnittstelle 20% 1,50 0,06 1,00 0,04 3,00 0,12
Ladezeit 20% 3,00 0,12 2,00 0,08 0,00 0,00
Funktionen:
Produktkatalog 20% 2,00 0,16 2,00 0,16 2,00 0,16
Suchfunktion 10% 2,00 0,08 2,50 0,10 2,50 0,10
Produktwarenkorb 10% 1,00 0,04 2,00 0,08 2,50 0,10
Bestellformular 10% 1,00 0,04 2,00 0,08 3,00 0,12
Internationalisierung 0% - - - - - -
Content 20% 1,00 0,08 2,00 0,16 2,00 0,16
Management
Web Analytics 10% 1,00 0,04 1,00 0,04 2,00 0,08
SEO Funktionen 10% 1,00 0,04 2,50 0,10 3,00 0,12
Kunden- 10% 2,00 0,08 3,00 0,12 2,50 0,10
management
Multi-Shop Funktion 0% - - - - - -
Sicherheit:
Back-End 50% 2,00 0,20 0,00 0,00 2,00 0,20
Benutzerrechte und
-überwachung
Sicherheits- 50% 3,00 0,30 3,00 0,30 3,00 0,30
mechanismen
Strategie:
Service 50% 1,00 0,10 3,00 0,30 2,00 0,20
Finanzkraft 25% - - - - - -
Marktpräsenz 25% 2,00 0,10 3,00 0,15 2,00 0,10
Tabelle 32: Teilnutzwerte der Zielkriterien

- 109 -


ZKm ZKGm xt:Commerce OXID CE Magento
[Nma] [Nmb] [Nmc]
Architektur 20% 0,42 0,48 0,48
Funktionen 40% 0,56 0,84 0,94
Sicherheit 20% 0,50 0,30 0,50
Strategie 20% 0,20 0,45 0,30
Gesamtnutzwert: 1,68 2,07 2,22

Tabelle 33: Teilnutzwerte der Zielkriterien-Kategorien und der Gesamtnutzwerte

Für die Untersuchung der Stärken und Schwächen eignet sich die Betrachtung der
Zielkriterien-Kategorien ohne die Gewichtung der Kategorien, d.h. also die Summe aller
Teilnutzwert der Zielkriterien der jeweiligen Zielkriterien-Kategorie einer Variante, wie Tabelle
35 zeigt:

ZKm ZKGm xt:Commerce OXID CE Magento
[Nma / ZKGm] [Nmb / ZKGm] [Nmc / ZKGm]
Architektur 20% 0,42 0,48 0,48
Funktionen 40% 0,56 0,84 0,94
Sicherheit 20% 0,50 0,30 0,50
Strategie 20% 0,20 0,45 0,30
Tabelle 34: Zielkriterien-Kategorien ohne die Gewichtung der Kategorien

Die Übertragung der Daten aus Tabelle 35 in eine Netz-Darstellung, verschafft eine
verbesserte Sicht der Stärken und Schwächen der E-Shop Software.

Architektur
xt:Commerce
OXID CE
Magento

Strategie Funktionen

Sicherheit

Abbildung 22: Netz-Darstellung der Stärken und Schwächen
- 110 -


Aus Abbildung 22 geht deutlich hervor, dass xt:Commerce in allen Kategorien bis auf die
Sicherheit das Nachsehen hat. Magento erzielt in der Kategorie Funktionen mehr Punkte als
OXID CE, zeigt jedoch in Vergleich zu OXID CE deutliche Schwächen im strategischen
Bereich.

Eine nähere Betrachtung von OXID CE zeigt, dass die E-Shop Software bei den Zielkriterien
Back-End Benutzerrechte und -überwachung sowie Schnittstelle sehr schwach abschneidet,
die für größere Unternehmungen bzw. eine Skalierung notwendig wichtig sind. Hintergrund
könnten unternehmenspolitische Gründe sein, da der Hersteller auf eine Enterprise Software
vertreibt.

Das aus den USA stammende Magento zeigt besondere Schwächen im strategischen
Bereich, was auf die Evaluierung aus deutscher Sicht zurückzuführen ist.

Auf die Untersuchung der Kostenaspekte der drei E-Shop Software wird an dieser Stelle
verzichtet, weil als Anschaffungskosten bei quelloffenen Software nicht anfallen und alle
weiteren Kosten wie aus Kapitel 4.5 hervorgeht, von individuellen Faktoren, wie z.B. Anzahl
Mitarbeiter, Schulungsbedarf, technische Infrastruktur etc. abhängen. Eine sinnvoller
Vergleich wäre folglich nicht möglich.

5. Fazit und Ausblick
Die Zielsetzung der vorliegenden Arbeit war es, ein Evaluierungsmodell zu entwickeln und
dieses mit Beispielen aus quelloffenen Shopsystemen zu demonstrieren. Insgesamt haben
die Untersuchungen gezeigt, dass eine E-Shop Software ein komplexes Gebilde darstellt,
dass nur durch eine breit angelegte Untersuchung und Verknüpfung von Theorie und Praxis
erfasst werden kann.

Diese Arbeit führt den Leser in die Grundlagen des E-Commerce ein und zeigt insbesondere
die Bedeutung der E-Shop Software in diesem Kontext auf. Die umfassende Erarbeitung der
Grundlagen auf sowohl technischer als auch betriebswirtschaftlicher Ebene, sowie die
gezielte Einführung in die Untersuchung von E-Shop Software, verschaffen dem Leser ein
solides Gesamtbild. Die breite Grundlagenuntersuchung führt insgesamt zu der Erkenntnis,
dass die E-Shop Software ein Baustein innerhalb eines Komplexes darstellt, auf dem
zahlreiche Einflussfaktoren wirken, die Schritt für Schritt erfasst werden.

Die Diskussion und Darstellung verschiedener E-Shop Betreibermodelle, gibt dem
Evaluierungsmodell von Grund auf eine mehrdimensionale Struktur noch bevor spezifische
Anforderungen erarbeitet werden. Mit den Total Costs wird eine weitere Dimension
- 111 -


eingeführt, die nochmals deutlich aufzeigt, dass die Evaluierung einer E-Shop Software nicht
geradlinig verläuft und eine mehrdimensionale Betrachtung zwangsläufig notwendig macht.

Die kritische Betrachtung bereits vorhandener, theoretisch gefußter Kriterien-Vorschläge zur
Evaluierung von E-Shop Software in Kapitel 3, hat deutlich erkennen lassen, dass die
meisten bestehenden Modelle perspektivisch eingeschränkte Kriterien vorschlagen, auf
deren Basis eine umfassende praxistaugliche Evaluierung nicht möglich wäre. Diese Defizite
konnten erst durch die sinnvolle Kombination verschiedener Modelle, eine breit angelegte
Untersuchung und die mehrdimensionale Betrachtungsweise behoben werden.

Die Untersuchungen der Einzelaspekte der E-Shop Software in Kapitel 3 führen zur
Entwicklung einer fundierten Basis, für die in Kapitel 4.1 hergeleiteten Zielkriterien. Zu den
Herausforderungen der vorliegenden Arbeit gehört die Überleitung von der breit gefassten
theoretischen Basis in die anwendungsnahe Wissenschaft und die Ableitung von
anwendungsnahen Hilfs- und Zielkriterien. Damit wird dem Leser nicht nur ein konkretes
Instrument zur Hand gegeben, sondern auch eine nachvollziehbare und wiederholbare
Vorgehensweise beschrieben.

Die theoretische bis anwendungsnahe Beschreibung von relevanten Softwaretrends in
Kapitel 2.9 und die gezielte Aufarbeitung der Trends in Kapitel 3, machen das
Evaluierungsmodell verstärkt praxistauglich. Insgesamt werden sowohl die Interessen von E-
Shop Betreibern als auch Endkunden zur Zeichnung eines gesamtheitlichen Bildes
berücksichtigt. Eine Untersuchung aus singulärer Perspektive, die in der Literatur verbreitet
ist, wie zu Beginn kritisiert, wird damit, wie in Kapitel 3 näher erläutert, vermieden.

Die Berücksichtigung unterschiedlicher Anwendungsszenarien und -aspekte bei der
Erarbeitung der Grundlagen und der fortgeführten Diskussionen, tragen zur Flexibilität und
Anpassbarkeit des Evaluierungsmodells bei. Konkrete Beispiele dafür stellen die
Diskussionen von Bestellformularen dar, die bei vereinzelten Geschäftsmodellen nur
eingeschränkt notwendig sind oder die Multi-Shop Funktion, die ein sehr effektives Feature
für bestimme Unternehmungen darstellen kann. Weiterhin trägt die Variabilität der
Zielkriterien-Gewichtung, welche u.a. in Relation zum Betreibermodell diskutiert wird, zu
einer verbesserten Flexibilität bei. Schließlich macht insbesondere die Trennung von
Methode, d.h. also dem Punktbewertungsverfaren, und Inhalt, d.h. der Zielkriterien, das
Evaluierungsmodell sehr flexibel und verleiht ihm den Charakter eines anpassbaren
Rahmenmodells.

Die empirische Herleitung macht das Entwicklungsmodell insgesamt nachvollziehbar,
wiederholbar und bildet die Grundlage für eine objektive Evaluierung, wobei, wie in Kapitel

- 112 -


4.6 kritisch zusammengefasst wird, die Objektivität von sehr unterschiedlichen Faktoren
abhängen kann.

Teil der Evaluierung ist die Betrachtung von Kostenaspekten, wobei diese, wie in dieser
Arbeit festgestellt wird, zunächst vom Evaluierungsmodell getrennt untersucht werden
müssen und in einem zweiten Schritt dem Nutzwert der jeweiligen E-Shop Software
gegenüber gestellt werden können. Die Diskussion der Kosten führt zu der Erkenntnis, dass
die vollständige Anwendung eines TCO Modell sehr aufwendig sein kann, weswegen für
einen alternativen Ansatz besonders relevante Kostenkriterien identifiziert werden.

Für die praxisnahe Demonstration des Evaluierungsmodells werden drei verbreitete
quelloffene E-Shop Softwares einer Evaluierung unterzogen, deren Resultat in Kapitel 5.5
zusammengefasst werden.

Das Evaluierungsmodell im Allgemeinen, sowie die Diskussion der Resultate der drei
Beispielevaluierungen und die Handlungsempfehlungen für OTTO haben im Besonderen
erkennen lassen, dass sich das Evaluierungsmodell als Grundlage für weitere
Untersuchungen eignet.

Das Evaluierungsmodell kann in Zukunft dazu beitragen, den Einfluss von theoretisch
hergeleiteten Aussagen für die Praxis näher zu untersuchen und mögliche Diskrepanzen
aufzuzeigen. Das Evaluierungsmodell macht es möglich Perspektiven verschiedener
Disziplinen zusammenzuführen und ihren Einfluss auf die Evaluierungsergebnisse von E-
Shop Softwares zu untersuchen. Das Evaluierungsmodell weist auf die Vorteile der
Kombination unterschiedlicher Perspektiven hin und berücksichtigt die in der Literatur oft
vernachlässigten strategischen Faktoren.

Die Diskussion der strategischen Abhängigkeiten zwischen E-Shop Betreiber und externen
Unternehmen in Abhängigkeit zum Wertbeitrag in Kapitel 2.9, zeigt deutlich, dass die
Evaluierung der E-Shop Software auch eine strategische Frage ist. Eine isolierte
Betrachtung oder die Vernachlässigung strategischer Faktoren ist somit nicht
empfehlenswert. Die Evaluierung einer E-Shop Software stellt folglich keine rein
informationstechnische Analyse dar, wie in der Industrie und Literatur oftmals angenommen.

Aus Sicht der Industrie zeigt das Evaluierungsmodell insbesondere dann seine Stäken, wenn
eine Vielzahl von E-Shop Softwares untersucht werden sollen, die ähnliche
Rahmenbedingungen aufweisen. Die Untersuchungen können zur Identifizierung von
Stärken und Schwächen genutzt werden, aus denen konkrete Handlungsempfehlungen
hergeleitet werden können. Gleichzeit kann durch die Anwendung des Evaluierungsmodell
die Grundlage für weitere Untersuchungen und Diskussion gelegt werde.

- 113 -


Anhang

Anhang 1: Gartner TCO Modell
- 114 -


Literaturverzeichnis

Adam, Dietrich (1996): Planung und Entscheidung: Modelle, Ziele, Methoden, 4. Aufl.,
Wiesbaden 1996.

Aden, Timo (2009): Google Analytics - Implementieren Interpretieren Profitieren, München
2009.

Meier, Andreas / Stormer, Henrik (2008): eBusiness & eCommerce, Berlin, Heidelberg 2008.

Amor, Daniel (2004): E-Business - Trends, Prozesse und Technologien Im Unternehmen,
Weinheim 2004.

Appelfeller, Wieland / Buchholz, Wolfgang (2005): Supplier Relationship Management -
Strategie, Organisation und IT des modernen Beschaffungsmanagements,
Wiesbaden 2005.

Baeumle-Courth, Peter / Nieland, Stefan / Schröder, Hinrich (2004): Wirtschaftsinformatik -
Wirschafts- und Sozialwissenschaftliches Repetitorium, München 2004.

Baldauf, Kenneth J. / Stair, Ralph M. (2009): Succeeding with Technology - Computer
System Concepts for Real Life, 3. Aufl., Boston 2009.

Bass, Len / Clements, Paul / Kazman, Rick (2003): Software Architectures in Practice,
Boston 2003.

Beckert, Thomas (2007): Web 2.0 und Ajax - ein erster Einstieg ins neue Internet, Konstanz
2007.

Beinhauer, Wolfgang / Herr, Michael / Schmidt, Achim (2008): SOA für Agile Unternehmen,
Düsseldorf 2008.

Bigdoli, Hossein (2004) The Internet encyclopedia, Volume 3, New Jersey 2004.

BITKOM (2009): Praxisleitfaden E-Commerce, Berlin 2009.

Brink, Annekie / Berndt, Adele (2009): Relationship Marketing & Customer Relationship
Management, Lansdowne 2009.

Brügge, Bernd u.a. (2004): Open Source Software - Eine ökonomische und technische
Analyse, Berlin und Heidelberg 2004.

Buenstorf, Guido / Fornahl, Dirk (2006): B2C- bubble to cluster: the dot-com boom, spin-off
entrepreneurship, and regional agglomeration, Max Planck Institute of
Economics Jena, Nr. 2006-20, S.349-378.

Bullinger, Hans-Jörg / Scheer, August-Wilhelm (2006): Service Engineering: Entwicklung und
Gestaltung innovativer Dienstleistungen, 2. Aufl., Berlin et al. 2006.

Bullinger, Hans-Jörg u.a. (1998): Praxisorientierte TCO-Untersuchung - Ein
Vorgehensmodell, in: Information Management, 2/1998, S.14.

- 115 -


Buxmann, Peter / Diefenbach, Heiner / Hess, Thomas (2008): Die Softwareindustrie -
Ökonomische Prinzipien - Strategien - Perspektiven, Berlin, Heidelberg 2008.

Chaffey, Dave (2008) Internet Marketing - Strategy, Implementation and Practice, 3. Aufl,
Essex 2008.

Choi, Soon-Yong / Stahl, Dale O. / Whinston, Andrew. B. (1997): The Economics of
Electronic Commerce, Indianapolis 1997.

Clement, Michel / Peters, Kay / Preiß, Fritz (1999): Electronic Commerce, in: Marketing mit
Interaktiven Medien - Strategien zum Markterfolg, hrsg. von Sönke Albers,
Michel Clement und Kay Peters, Frankfurt am Main 1999, S. 49-64.

Daeschner, Tobias (2005): Einstieg in osCommerce & xt:Commerce, Bonn 2005.

Deans, Candace (2009) Social Software and Web 2.0 Technology Trends, Hershey 2009.

demandware Inc. (2008): The Evolving and Changing Face of the eCommerce Platform,
White Paper.

DeMarco, Tom (1995): Why does software cost so much? - and other puzzles of the
Information Age, New York 1995.

Dustdar, Schahram / Gall, Harald / Hauswirth, Manfred (2003): Software-Architekturen für
verteilte Systeme, Berlin, Heidelberg und New York 2003.

Enge, Eric / Spencer, Stephan / Fishkin, Rand / Stricchiola, Jessie (2009):The Art of SEO,
Sebastopol 2009.

Ebersbach, Anja u.a. (2008): Social Web, Konstanz 2008.

Eichinger, Christian (2003): Web Applilcation Architectures, in: Web Engineering, hrsg. von
Gerti Kappel, Heidelberg 2003, S.65-84.

Feyhl, Achim W. (2004): Management und Controlling von Softwareprojekten, 2. Aufl.,
Wiesbaden 2004.

Figallo, Cliff (1998): Hosting Web communities, New York 1998.

Flavian, Carlos / Gurrea, Raquel / Orus, Carlos (2008): Analysing the Key Factors of Web
Design - A Heuristic Evaluation, in: E-commerce and web technologies, 9th
International Conference, hrsg. von Giuseppe Psaila und Roland Wagner,
Berlin, Heidelberg 2008, S.31-40.

Forrester Research (2009a): eCommerce Web Site Performance Today, unter:
http://hospitality.resourcecenteronline.com/resource_center/asset/1909-
eCommerce_Web_Site_Performance_Today_An_Updated_Look_At_Consum
er_Reaction_To_A_Poor_Online_Shopping_Experience.

Gläßer, Lothar (2004): Open sources Software - Projekte, Geschäftsmodelle, Rechtsfragen,
Anwendungszenarien, Erlangen 2004.

Goldhammer, Klaus u.a. (2008): Goldmedia Mobile Life Report 2012: Mobile Life in the21st
century, Goldmedia GmbH und BITKOM, unter:
http://www.bitkom.org/files/documents/081009_BITKOM_Goldmedia_Mobile_
Life_2012.pdf.
- 116 -


Goluchowski, Jerzy / Filipczyk, Barbara / Jablonska, Malgotzta (2007): eCommerce
Applications Design, Karol Adamiecki University of Economics in Katowice.

Götze, Uwe (2008): Investitionsrechnung: Modelle und Analysen zur Beurteilung von
Investitionsvorhaben, Berlin, Heidelberg 2008.

Grimm, Rüdiger (2006): E-Commerce - Technik, Entwicklung und Anwendung, Institut für
Wirtschafts- und Verwaltungsinformatik, Universität Koblenz, unter:
http://www.uni-koblenz.de/~grimm/texte/E-Commerce-lang.pdf.

Grobman, Jewgenij (2008): ERP-Systeme on Demand - Chancen, Risiken, Anforderungen,
Hamburg 2008.

Grzebiela, Torsten (2002): Internet-Risiken − Versicherbarkeit und Alternativer
Risikotransfer, Wiesbaden, Karlsruhe, 2006.

Günther, Hans-Otto / Tempelmeier, Horst (2005): Produktion und Logistik, 6.Aufl., Berlin et
al. 2005.

Haenni, Rolf (2006): Kryptographie in Theorie und Praxis, Universität Bern, unter:
http://www.iam.unibe.ch/~run/crypto_06-07/scripts/script.pdf.

Haertsch, Patrick (2000): Wettbewerbsstrategien für Electronic Commerce, Reihe Electronic
Commerce, Vol. 2, Lohmar 2000.

Handschuh, Siegfried / Schmid, Beat F. / Stanoevska-Slabeva, Katarina (1997): The
Concept of a Mediating Electronic, University of St.Gallen, Vol.7, No.3, unter:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.1518&rep=rep1&
type=pdf.

Hass, Berthold H. / Walsh, Gianfranco / Kilian, Thomas (2008): Web 2.0 - Neue Perspektiven
für Marketing und Medien, Berlin, Heidelberg 2008.

Hawk, Stephen / Zheng, Weijun (2008): E-Commerce Standards - Transforming Industry
Practice, in: Electronic commerce: concepts, methodologies, tools and
applications, Vol.1, hrsg. von Annie Becker, London, Hershey 2008, S.2200-
2070.

Hehl, Walter (2008): Trends in der Informationstechnologie, Zürich 2008.

Heinemann, Gerit (2009): Der neue Online Handel, Wiesbaden 2009.

Henning, Stephan (2009): Open Source-software für mittelständische Unternehmen,
Hamburg 2009.

Hermanns, Arnold / Sauter, Michael (1999): Management Handbuch Electronic Commerce,
München 1999.

Herstatt, Cornelius (2004): Produktentwicklung mit virtuellen Communities - Kundenwünsche
erfahren und Innovationen realisieren, Wiesbaden 2004.

Holtkamp, Bernhard (2009): SOA – Serviceorientierte Architektur Definition- Marktpotenzial
und Perspektiven, Fraunhofer-Institut für Software und Systemtechnik ISST,
Dortmund 2009.

- 117 -


Kohavi, Ron / Longbotham, Roger (2007): Online Experiments - Lessons Learned, in:
Computer, Volume 40, Issue 9, 2007, S. 103‐105.

Krallermann, Hermann u.a. (2007): B2B-Modellierungssprachen und -methodologien im
Kontext der Konzeption und Implementierung Service Orientierter
Architekturen, in: Architekturen und Prozesse - Strukturen und Dynamik in
Forschung und Unternehmen, hrsg. von Peter Loos und Helmut Krcmar,
Berlin, Heidelberg 2007, S.13-32.

Howe, Jeff (2008): Crowdsourcing - How the power of the crowd is driving the future of
business, London 2008.

Hutzschenreuter, Thomas (2009): Allgemeine Betriebswirtschaftslehre - Grundlagen mit
zahlreichen Praxisbeispielen, 3. Aufl., Wiesbaden 2009.

ibi research an der Universität Regensburg GmbH (2009): E-Commerce-Leitfaden, 2. Aufl.,
Regensburg 2009.

Illik, Anton (2002): Electronic Commerce - Grundlagen und Technik für die Erschließung
elektronischer Märkte, München 2002.

Schneider, Willy / Hennig, Alexander (2008): Lexikon Kennzahlen für Marketing und Vertrieb
- Das Marketing Cockpit von A- Z, 2. Aufl., Berlin, Heidelberg 2008.

Janker, Christian G. (2008): Multivariate Lieferantenbewertung - Empirisch gestützte
Konzeption eines Anforderungsgerechten Bewertungssystems, 2. Aufl.,
Wiesbaden 2008.

Janowicz, Krzysztof (2006): Sicherheit im Internet, Köln 2006.

Schwarze, Jochen / Schwarze, Stephan (2002): Electronic Commerce - Grundlagen und
praktische Umsetzung, Herne, Berlin 2002.

Jowers, Tim (2006): The Business Guide to Free Information Technology, Boston 2006.

Kalakota, Ravi / Whinston, Andrew (1996): Electronic Commerce - A Manager's Guide, New
York 1996.

King, Andrew B. (2003): Speed up your site - Eeb Site Optimization, Berkeley 2003.

Kollmann, Tobias (2007): E-Business - Grundlagen elektronischer Geschäftsprozesse in der
Net Economy. 2. Aufl. Wiesbaden 2007.

Kopacek, Peter / Zauner, Martin (2004): Leitfäden der technischen Informatik und
Kommunikationstechnik, Wien, New York 2004.

Korper, Steffano / Ellis, Juanita (2001): The E-commerce book: building the E-empire, 2.
Aufl., San Diego 2001.

Krcmar, Helmut (2004): Informationsmanagement, 4. Aufl., Heidelberg 2004.

Kuster, Jürg / Huber, Eugen / Lippman, Robert (2008): Handbuch Projektmanagement,
Berlin, Heidelberg 2008.

Labonde, Bernhard (1986): Nutzwert-Wirtschaftlichkeits-Analyse, Wuppertal 1986.

- 118 -


Laudon, Kenneth C. / Traver, Carol Guercio (2009): E-Commerce - Business - Technology -
Society, 5. Aufl., New Jersey 2009.

Lassmann, Wolfgang (2006): Wirtschaftsinformatik - Nachschlagwerk für Studium und
Praxis, Wiesbaden 2006.

Lee, Sung-Min u.a. (2003): TY Secure WS - An Integrated Web Service Security Solution
based in Java, in: E-commerce and web technologies, 4th International
Conference, hrsg. von Kurt Bauknecht, A Min Tjoa und Gerald Quirchmayr,
Berlin et al. 2003, S.186-195.

Leukel, Jürgen (2004): Katalogdatenmanagement im B2B E-Commerce, in: Electronic
Commerce, Band 30, hrsg. von Norbert Szyperski u.a., Lohmar 2004.

Lenz, Gunther / Moeller,Thomas (2004): .NET: a complete development cycle, Boston 2004.

Liebhart, Daniel (2007): SOA goes Real - Service-orientierte Architekturen erfolgreich Planen
und Einführen, München, Wien 2007.

Loshin , Peter / Vacca, John (2005): Electronic Commerce, 4. Aufl., New Delhi 2005.

Dannenberg, Marius / Ulrich, Anja (2004): E-payment und E-billing - Elektronische
Bezahlsysteme für Mobilfunk und Internet, Wiesbaden 2004.

mcm institute & PwC (1999): E-Business - made in Switzerland, PricewaterhouseCoopers,
Zürich 1999.

Meier, Andreas / Stormer, Henrik (2008): eBusiness & eCommerce. Management der
Digitalen Wertschöpfungskette. 2. Aufl., Heidelberg 2008.

Meier, Andreas / Stormer, Henrik (2009): eBusiness & eCommerce - Managing the Digital
Value Chain, Berlin, Heidelberg 2009.

Mertens, Peter (2001): Lexikon der Wirtschaftsinformatik, Berlin et al. 2001.

Müller, Joachim (2005): Workflow Based Integration, Heidelberg 2005.

Müller, Ulrich (2004): Kundenbindung im E-commerce - Personalisierung als Instrument des
Customer Relationship Marketing, Wiesbaden 2005.

Mundhenke, Jens (2007): Wettbewerbswirkungen von Open-Source-Software und offenen
Standards auf Softwaremärkten, Berlin, Heidelberg 2007.

Netessine, Serguei / Savin, Sergei / Xiao, Wenqiang (2004): Revenue Management through
Dynamic Cross-Selling in E-commerce Retailing, working paper, University of
Pennsylvania und Columbia University, November 2004.

North, Barrie M. (2009): Joomla! 1.5 a User's Guide, 2.Aufl., Boston 2009.

Opuchlik, Adam (2005): E-Commerce Strategie, Norderstedt 2005.

Panniello, Umberto / Gorgoglione, Michele / Palmisano, Cosimo (2009): Comparing Pre-
filtering Approach in a Collaborative Contextual Recommender System - An
Application to E-Commerce, in: E-Commerce and Web Technologies, 10th
International Conference, hrsg. von Tommaso Di Noia und Francesco
Buccafurri, Berlin, Heidelberg 2009, S.348-360.
- 119 -


Papazoglou, Michael P. (2008): Web services - Principles and Technology, Essex 2008.

Pate, Brad / Helwig, Shawn (2006): Top 10 Website Speed Optimization Tips, University of
Wisconsin-Madison.

Patton, Marry Anne / Josang, Audun (2003): Technologien und Strategien zum Aufbau von
Vertrauen im Electronic Commerce, in: Trust in the network economy, hrsg.
von Otto Petrovic u.a., Wien 2003, S.73-88.

Petrovic, Otto (2003): Trust in the network economy, Wien 2003.

Quantz, Joachim / Wichmann, Thorsten (2003): E-Business Standards in Deutschland, Berlin
2003.

Range, Michael (2005): Aufbau und Betrieb konsumorientierter Websites im Internet,
Göttingen 2005.

Rechenberg, Peter (2006): Informatik-Handbuch, 4. Aufl., München 2006.

Remenyi, Dan u.a. (2003): The effective measurement and management of IT costs and
benefits, Oxord 2003.

Reynolds, George W. / Staire, Ralph (2003): Fundamentals of Information Systems, 2. Aufl.,
Boston 2003.

Reynolds, Janice (2004): The complete e-commerce book: Design, Build & Maintain a
Successful Web-Based Business, 2 Aufl., New York 2004.

Rheingold, Howard (1994): Virtuelle Gemeinschaft: soziale Beziehungen im Zeitalter
des Computers, Bonn 1994.

Richter, Jan-Peter / Haller, Harald / Schrey, Peter (2005): Service orientierte Architektur, in:
Informatik Spektrum, Vol.28, Nr.5, 2005, S.413-416.

Roumois, Ursula Hasler (2007): Studienbuch Wissensmanagement, Zürich 2007.

Schierenbeck, Henner (2004): Grundzüge der Betriebswirtschaftslehre, 9. Aufl., München
2004.

Schmeken, Gregor Mark (2007): Erfolgreiche Strategien für E-Commerce, Integrierte Kosten
und Leistungsführerschaft als Orientierungsmuster, Wiesbaden 2007.

Schneider, Gary P.(2004): Electronic Commerce -The Second Wave, 5. Aufl., Boston 2004.

Schubert, Petra / Selz, Dorian / Haertsch, Patrick (2003): Digital erfolgreich: Fallstudien zu
strategischen E-Business Konzepten, 2. Aufl., Berlin et al. 2003.

Schulte, Gerd (2001): Material- und Logistikmanagement, München 2001.

Schwickert, Axel C. (2001): Web Site Engineering - Ökonomische Analyse und
Entwicklungssytematik für eBusiness Präsenzen, Stuttgart et al. 2001.

Schwinger, Wieland / Koch, Nora (2003): Modelling Web Applications, in: Web Engineering,
hrsg. von Gerti Kappel u.a., Heidelberg, 2003, S.39-64.

- 120 -


Shuen, Amy (2008): Web 2.0 - A Strategy Guide, Sebastopol 2008.

Starke, Gernot / Hruschka, Peter (2009): Software-Architektur Kompakt, Heidelberg 2009.

Strobel, Claus (2004): Web Technologien, in: E-Commerce Systemen, München 2004.

Stoyan, Robert (2008): Management von Webprojekten, 2.Aufl., Heidelberg 2007.

Strobel, Claus (2004): Web Technologien, in: E-Commerce Systemen, München 2004.

Swoboda, Joachim / Spitz, Stephan / Pramateftakis, Michael (2008): Kryptographie und IT-
Sicherheit - Grundlagen und Anwendungen, Wiesbaden 2008.

Stähler, Patrick (2002): Geschäftsmodelle in der digitalen Ökonomie, Reihe Electronic
Commerce, Band 7, hrsg. von Norbert Szyperski u.a., 2. Aufl., Zürich 2002.

Tapp, Alan (2008): Principles of direct and database marketing, 4. Aufl., Essex 2008.

Tapscott, Don / Ticoll, David / Lowy, Alex (1999): Digital capital: harnessing the power of
business webs‎, Boston 1999.

Tassabehji, Rana (2005): Applying e-commerce in business, London et al. 2005.

Thayer, Richard H. / Dorfman, Merlin / Baili, Sidney C. (1997): Software Requirements
Engineering, 2. Aufl., Los Alamitos 1997.

Thomson, Laura / Welling, Luke (2009): PHP 5.3 & MySQL 5.1-Kompendium: Dynamische
Webanwendungen von Einstieg bis E-Comerce, München 2009.

Timmers, Paul (1998) Business Models for Electronic Markets, in: European Commission,
Directorate-General 3, Vol.8 - No.2, S.3-8, unter:
http://www.electronicmarkets.org/issues/volume-8/volume-8-issue-
2/businessmodels0.pdf.

Timmers, Paul (1999): Electronic commerce - Strategies and Models for Business-to-
Business Trading, West Sussex 1999.

Trump, Thilo u.a. (2007): Web 2.0 - Begriffsdefinition und eine Analyse der Auswirkungen auf
das allgemeine Mediennutzungsverhalten, Berlin, Heidelberg 2007.

Turban, Efraim / King, David / Lang, Judy (2009): Introduction to Electronic Commerce, 2
Aufl., New Jersey 2009.

Turban, Efraim / McLean, Ephraim R. / Wetherbe, James C.(1999): Information technology
for management, 2. Aufl., New Jersey 1999.

Turban, Efraim; Rainer Jr., Kelly (2009): Introduction to Information Systems, 2.Aufl., New
Jersey 2009.

van Bon, Jan u.a. (2007): Foundations of IT Service Management based on ITIL, 3 Aufl.,
Zaltbommel 2007.

Vogel, Oliver u.a. (2005): Software-Architektur: Grundlagen - Konzepte - Praxis, Heidelberg
2009.

- 121 -


Walker, Brian K. (2009): The Future of E-Commerce Platform, Forrester Research Inc., Mai
2009.

Walcher, Dominik (2007): Der Ideenwettbewerb als Methode der aktiven Kundenintegration,
Wiesbaden 2007.

Wan, Yun (2009): Comparison-Shopping Services and Agent Designs, Hershey, London
2009.

Wannenwetsch, Helmut (2005): Vernetztes Supply Chain Management - SCM Integration
über die gesamte Wertschöpfungskette, Berlin, Heidelberg 2005.

Weiss, Christoph (2005): Evaluierung von ERP- und Business Software Lösungen, monitor
Österreich, 5. Ausgabe, Mi 2005, Wien 2005, S.18-19.

Wigand, Rolf (1997): Electronic Commerce, Volume 13, London 1997.

Wigder, Zia Daniell u.a. (2008): Global Online Retail, Jupiter Research, Vol. 1, GLB08-V01.

Wild, Martin / Herges, Sascha (2000): Total Cost of Ownership - Ein Überblick, Universität
Mainz, Arbeitspapiere WI, Nr.1/2000.

Windley, Phillip J. (2001):Delivering High Availability Services Using a Multi-Tiered Support
Model, State of Utah, unter:
http://www.windley.com/docs/Tiered%20Support.pdf.

Wirtz, Bernd W. (2001) Electronic Business, 2. Aufl., Wiesbaden 2001.

Wirth, Markus (2006): Die Bedeutung von Suchmaschinen für E-Business, Kompetenz-
Zentrum Electronic Commerce Schwaben, Heidenheim 2006, unter:
http://www.heilbronn.ihk.de/ximages/1397379_wirth.pdf

Witt, Kurt-Ulrich (2007): Algebraische Grundlagen der Informatik: Strukturen - Zahlen -
Verschlüsselung - Codierung, 3. Aufl., Wiesbaden 2007.

Wolenik, Marc J. / Sinay, Damian (2008): Microsoft Dynamics CRM 4.0 Unleashed, Indiana
2008.

Wölfl, Thomas (2006): Formale Modellierung von Authentifizierungs- und
Autorisierungsstrukturen, Wiesbaden 2006.

Zangemeister, Christoph (1976): Nutzwertanalyse in der Systemtechnik, München 1976.

Zenner, Roman (2009): Online-shops mit Magento, Köln 2009.

Online Quellen:

BITKOM (18.02.2010): Der elektronische Handel boomt, unter:
http://www.bitkom.org/de/presse/49919_43665.aspx am 18.02.2010.

Björn Greif (20.02.2010): Markenartikel-Hersteller dürfen Handel auf Ebay verbieten, unter:
http://www.zdnet.de/news/wirtschaft_telekommunikation_markenartikel_herste
- 122 -


ller_duerfen_handel_auf_ebay_verbieten_story-39001023-39188958-1.htm
am 20.02.2010.

Blakey, Elizabeth (05.01.2010): Microsoft, IBM Settle E-Commerce Standards Battle, unter:
http://www.ecommercetimes.com/story/7733.html am 05.01.2010.

Bundesverband des Deutschen Versandhandels e.V. (26.12.2009): Rekordentwicklung des
E-Commerce in Deutschland hält an, unter:
http://www.versandhandel.org/Pressemitteilung.96+M54d324bae4d.0.html am
26.12.2009.

Bustos, Linda (08.01.2010): Cross-Selling Tips for Online Retailers, unter:
http://www.getelastic.com/cross-selling-tips-ecommerce/ am 08.01.2010.

Bustos, Linda (09.01.2010): Checkout Inspiration From Top Converting Sites, unter:
http://www.getelastic.com/no-required-registration/ am 09.01.2010.

comScore (14.01.2010): comScore Releases March 2008 European Search Rankings, unter:
http://www.comscore.com/Press_Events/Press_Releases/2008/05/Top_Europ
ean_Search_Engines am 14.01.2010.

Detecon International (04.01.2010): Detecon-Prognose: Wachstum im IPTV-Markt stärker als
erwartet, unter: http://www.portel.de/nc/nachricht/artikel/37292-detecon-
prognose-wachstum-im-iptv-markt-staerker-als-erwartet/ am 04.01.2010.

Dolson, Joseph C. (06.01.2010): Accessibility and the Checkout Process, unter:
http://www.practicalecommerce.com/articles/1229-Accessibility-and-the-
Checkout-Process am 06.01.2010.

Föhlisch, Carsten (13.01.2010): Abmahngefahr: Grundpreis muss unmittelbar beim Endpreis
stehen, unter: http://www.shopbetreiber-blog.de/2009/08/20/abmahngefahr-
grundpreis-muss-unmittelbar-beim-endpreis-stehen/ am 13.01.2010.

Gabler Wirtschaftslexikon (12.02.2010): Electronic Shop, unter:
http://wirtschaftslexikon.gabler.de/Definition/electronic-shop.html am
12.02.2010.

Gesellschaft für Evaluation e.V. (18.01.2010): Was ist Evaluation und welche Bereiche
umfasst sie?, unter:
http://www.degeval.de/index.php?class=Calimero_Webpage&id=9048, am
18.01.2010.

GfK (14.02.2010): GfK Panel Services Deutschland, unter:
http://www.gfk.com/imperia/md/content/presse/pm_webscope_2008_dfin.pdf
am 14.02.2010.

Goldberg, Aaron (09.01.2010): Benefits of Single Page Checkout, unter:
http://ezinearticles.com/?Benefits-of-Single-Page-Checkout&id=1979945 am
09.01.2010.

Groß, Olaf (04.01.2010): Wie lange die Ladezeit einer Webseite maximal sein darf, unter:
http://www.shopbetreiber-blog.de/2009/09/29/ladezeit-einer-webseite/ am
04.01.2010.

- 123 -


Gutzman, Alexis D. (13.01.2010): Chapter 10: Globalization and Multicurrency Capability,
unter: http://www.ecommerce-guide.com/solutions/building/article.php/724311
am 13.01.2010.

Hahn, Tim (08.12.2009): Social Commerce, unter:
http://www.contentmanager.de/magazin/artikel_1849_social_commerce.html
am 08.12.2009.

HDE (14.02.2010): E-Commerce-Umsätze, unter:
http://www.einzelhandel.de/pb/site/hde/node/9365/Lde/index.html?QUERYST
RING=e-commerce+umsatz am 14.02.2010.

Hedemann, Falk (08.02.2010): Intershop vs. Magento – Closed vs. Open Source,
t3n Magazin, unter: http://t3n.de/news/e-commerce-intershop-vs-magento-
closed-vs-open-source-255626/ am 08.02.2010.

Höschl, Peter (22.01.2010): Rumble in the jungle: OXID vs. Magento, unter:
http://www.shopanbieter.de/news/archives/1901-rumble-in-the-jungle-OXID-
vs-magento.html am 22.01.2010.

Höschl, Peter (20.02.2010): Etailer kämpfen gegen das Verkaufsverbot, unter:
http://www.shopanbieter.de/news/archives/2317-etailer-kaempfen-gegen-das-
verkaufsverbot.html am 20.02.2010.

IBM (24.02.2010): Forums and community, unter:
http://www.ibm.com/developerworks/websphere/community/ am 24.02.2010.

iBOOD GmbH (20.02.2010): iBOOD, unter: http://www.ibood.com/ am 20.02.2010.

Informatik Forum Simon GmbH (20.01.2010): Nutzwertanalyse mit Sensitivitätsanalyse,
unter:
http://www.infforum.de/themen/projektmanagement/thema_PM_nutzwertanaly
se.htm am 20.01.2010.

internetstores AG (08.12.2009a): fahrrad.de, unter http://www.fahrrad.de am 08.12.2009a.

internetstores AG (08.12.2009b): fitness.de, unter http://www.fahrrad.de am 08.12.2009b.

Intershop AG (18.01.2010): E-Commerce-Lösungen für erfolgreiche Online-Händler, unter:
http://www.intershop.com/uploads/media/2009-Intershop-Image-de.pdf am
18.01.2010.

Intershop (24.02.2010): Intershop Community, unter: http://forum.intershop.com am
24.02.2010.

IntraMedia (06.01.2010): Onlineshop optimieren, unter: http://www.seo-
woman.de/onlineshop-optimieren/ am 06.01.2010.

Kolibrishop GmbH (08.12.2009): kolibrishop.com, unter http://www.kolibrishop.com/ am
08.12.2009.

Krisch, Jochen (13.01.2010): http://www.excitingcommerce.de/2009/10/preisbock-
expandiert-mit-stylebock-und-gadgetbock.html am 13.01.2010.

- 124 -


Krisch, Jochen (21.01.2010): OXID tritt mit Open Source Version gegen Magento & Co. an,
unter: http://www.excitingcommerce.de/2008/10/OXID-bringt-ope.html am
21.01.2010.

Krisch, Jochen (24.01.2010): pick!t today: Venture Capital für OXID eSales, unter:
http://ecommerce.typepad.com/exciting_ecommerce/2007/12/pickt-today-v-
1.html am 24.01.2010.

Krisch, Jochen (04.02.2010a): Fressnapf nimmt neuen E-Commerce Anlauf mit OXID-
Lösung, unter: http://www.excitingcommerce.de/2009/11/fressnapf.html am
04.02.2010a.

Krisch, Jochen (04.02.2010b): Systemwechsel: Globetrotter will auf Magento umsteigen,
unter: http://www.excitingcommerce.de/2009/06/globetrotter-setzt-auf-
magento.html am 04.02.2010b.

Krisch, Jochen (08.02.2010): Auf Konfrontationskurs: Magento gegen Intershop und Hybris,
unter: http://www.excitingcommerce.de/2009/07/magento-vs-intershop.html
am 08.02.2010.

Krisch, Jochen (20.02.2010): Brands4 Friends und BuyVIP mit Rekordumsätzen für 2009,
unter: http://www.excitingcommerce.de/2010/01/brands4-friends-buyvip-
2009.html am 20.02.2010.

Krisch, Jochen (20.02.2010): Shop.org Highlights: Kann Gilt Groupe Ebay gefährden?, unter:
http://www.excitingcommerce.de/2009/09/shoporg-highlights-gilt-groupe-vs-
ebay.html am 20.02.2010.

Lexitron (05.01.2010): Cron-Job, unter:
http://www.lexitron.de/main.php?detail=true&eintrag=1100&PHPSESSID_nets
h83516=2efde84a362a6abfb018ef71769f5dc7 am 05.01.2010.

Linda Bustos, http://www.getelastic.com/cross-selling-tips-ecommerce/.

Live Shopping GmbH (20.02.2010): guut, unter http://guut.de/ am 20.02.2010.

Magento Commerce (24.02.2010): Magento Community, unter:
http://www.magentocommerce.com/boards am 24.02.2010.

Magill, Ken (09.01.2010): Great expectations, unter:
http://multichannelmerchant.com/crosschannel/great_expectations_5/ am
09.01.2010.

Mayer, Marissa (19.12.2009): Marissa Mayer at Web 2.0, unter:
http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html am
19.12.2010.

Oracle (04.01.2010): Oracle Completes Acquisition of Sun, unter:
http://www.oracle.com/us/corporate/press/044428 am 04.01.2010.

ORACLE (24.02.2010): ORACLE Forum E-Commerce (iStore), unter:
http://forums.oracle.com/forums/forum.jspa?forumID=109&start=0 am
24.02.2010

- 125 -


O'Reilly, Tim (07.01.2010): What Is Web 2.0, unter:
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-
20.html am 07.01.2010.

O'Reilly, Tim (08.01.2010): Web 2.0 Compact Definition: Trying Again, unter:
http://radar.oreilly.com/2006/12/web-20-compact-definition-tryi.html am
08.01.2010.

Otto Group (02.12.2009): Bilanzpressekonferenz der Otto Group für das Geschäftsjahr
2007/2008, unter: http://www.ottogroup.com/june202008.html?&L=1 am
02.12.2009.

OXID eSales AG (21.01.2010): Interview Roland Fesenmayr zu OXIDs Open-Source-
Strategie, unter: http://www.OXID-
esales.com/de/unternehmen/presse/pressespiegel/interview-roland-
fesenmayr-zu-OXIDs-open-source-strategie-t3n am 21.01.2010.

OXID eSales AG (22.01.2010a): OXID eXchange, unter: http://www.OXID-
esales.com/de/exchange am 21.01.2010.

OXID eSales AG (22.01.2010b): E Commerce Services für den Onlinehandel, unter:
http://www.OXID-esales.com/de/produkte/OXID-efire am 22.01.2010.

OXID eSales AG (22.01.2010c): OXID eShop Community Edition, unter: http://www.OXID-
esales.com/de/produkte/community-edition am 22.01.2010.

OXID eSales AG (24.01.2010): Download OXID eShop Community Edition 4.1.6, unter:
http://www.OXIDforge.org/wiki/Downloads/4.1.6 am 24.01.2010.

OXID eSales (24.02.2010): OXID Community Forum, unter: http://www.OXID-
esales.com/forum/index.php am 24.02.2010.

Palmer, Justin (09.01.2010): 25 eCommerce Checkout Best Practices, unter:
http://ezinearticles.com/?25-eCommerce-Checkout-Best-Practices&id=771024
am 09.01.2010.

Rappa, Michael (18.12.2009): Business Modeles on the Web, unter:
http://digitalenterprise.org/models/models.html am 18.12.2009.

Ringsdorff, Alexander (08.02.2010): Entwicklungsmodelle: Magento vs. Intershop, unter:
http://ringsdorff.net/2009/07/15/entwicklungsmodelle-magento-vs-intershop/
am 08.02.2010.

Schaffry, Andreas (04.01.2010): Software-Mietmodelle im Vergleich, unter:
http://www.computerwoche.de/subnet/oracle/1883375/ am 04.01.2010.

Schiele, Veit (18.01.2010): Einführung in Software Avaluationen, unter: http://www.veit-
schiele.de/profil/artikel/software-evaluierung/2-kategorien am 18.01.2010.

Schinagl, Ulrike (18.01.2010): E-Commerce Software: Open oder Closed Source?, unter:
http://www.heise.de/open/artikel/E-Commerce-Software-Open-oder-Closed-Source-
828439.html am 18.01.2010.

Smarty, Ann (15.01.2010): Let’s Try to Find All 200 Parameters in Google Algorithm, unter:
http://www.searchenginejournal.com/200-parameters-in-google-
algorithm/15457/ am 15.01.2010.
- 126 -


Umstätter, Walter (18.01.2010): Digitales Handbuch der Bibliothekswissenschaft-
Definitionen, unter: http://www.ib.hu-
berlin.de/~wumsta/wistru/definitions/dk6.html am 18.01.2010.

Varien Inc. (02.02.2010): Release Notes, unter:
http://www.magentocommerce.com/download/release_notes am 02.02.2010.

Varien Inc. (03.02.2010a): Magento Connect, unter:
http://www.magentocommerce.com/magento-connect/filter/all/languages-
locales/p/1/ am 03.02.2010.

Varien Inc. (03.02.2010b): Market Ready Germany, unter:
http://www.magentocommerce.com/extension/1764/market-ready-germany/
am 03.02.2010.

Varien Inc. (04.02.2010a): Download Magento Community, unter:
http://www.magentocommerce.com/download am 04.02.2010.

Varien Inc. (24.02.2010a): About Us, unter: http://www.varien.com/company/ am 24.02.2010.

Varien Inc. (24.02.2010b): Company, unter: http://www.magentocommerce.com/company/
am 24.02.2010.

Verch, Marco (06.01.2010): Shop-Risiken: Falscher Umgang mit Session-ID, unter:
http://www.shopbetreiber-blog.de/2009/01/14/shop-risiken-falscher-umgang-
mit-session-id/ am 06.01.2010.

Volkmann, Martin (19.01.2010): Punktbewertungsverfahren - Wirtschaftwissenschaftliche
Fakultät der Universität Karlsruhe, unter: http://imihome.imi.uni-
karlsruhe.de/npunktbewertungsverfahren_b.html am 19.01.2010.

Wauters, Robin (08.12.2009): 1-800-FLOWERS.COM Sets Up Shop Inside Facebook, unter:
http://techcrunch.com/2009/07/29/1-800-flowerscom-sets-up-shop-inside-
facebook/ am 08.12.2009.

Web Analytics Association (14.01.2010): The Official WAA Definition of Web Analytics, unter:
http://www.webanalyticsassociation.org/?page=aboutus am 14.01.2010.

Willkommer, Josef (24.02.2010): xt:Commerce Veyton - Tschüss Open Source, unter:
http://blog.techdivision.com/xtcommerce-veyton-tschuss-open-source/ am
24.02.2010.

xt:Commerce GmbH (24.01.2010): Sprachpakete, unter: http://www.xtcommerce-
shop.com/index.php/cat/c7_Sprachpakete.html am 24.01.2010.

xt:Commerce (24.02.2010): xt:Commerce Webshop Shop Support, unter: http://www.xt-
commerce.com/forum/ am 24.02.2010.

- 127 -

Evaluierungsmodell

Weitere ähnliche Inhalte

Was ist angesagt?

Andere mochten auch

Ähnlich wie Evaluierungsmodell

Evaluierungsmodell