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-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 4.3. OXID CE ............................................................................................................. - 98 - 4.3.1. Evaluierung .................................................................................................. - 99 - 4.4. Magento ............................................................................................................ - 103 - 4.4.1. Evaluierung ................................................................................................ - 104 - 4.5. Zusammenfassung der Evaluierung von xt:Commerce, OXID CE und Magento- 109 - 5. Fazit und Ausblick ................................................................................................. - 111 - Anhang ........................................................................................................................... - 114 - Literaturverzeichnis ...................................................................................................... - 115 - -3-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Anhangsverzeichnis Anhang 1: Gartner TCO Modell ....................................................................................... - 114 - -4-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Abbildungsverzeichnis Abbildung 1: E-Business und E-Commerce ........................................................................ - 9 - Abbildung 2: Elektronische Geschäftsbeziehungen .......................................................... - 10 - Abbildung 3: Aggregator kombiniert Produkte und diktiert Preise ..................................... - 13 - Abbildung 4: Struktur der B2C Internetumsätze in Deutschland ....................................... - 16 - Abbildung 5: E-Commerce Schichtenpyramide ................................................................. - 19 - Abbildung 6: E-Commerce Plattform ................................................................................. - 21 - Abbildung 7: Beispielhafte Darstellung der E-Shop Softwarekomponenten ..................... - 22 - Abbildung 8: Die zwei Dimensionen des Internets ............................................................ - 25 - Abbildung 9: Wertbeiträge-Modell für E-Shop Lösungen .................................................. - 29 - Abbildung 10: Einsatz der E-Shop Distributionsmodelle in Abhängigkeit zum Wertbeitrag- 30 - Abbildung 11: Auf die Entwicklung einer Softwarearchitektur wirkende Faktoren ............ - 34 - Abbildung 12: Transaktionsphasen im B2C E-Commerce ................................................ - 41 - Abbildung 13: Ein Modell für Katalogdatenbereiche ......................................................... - 45 - Abbildung 14: Optimierungsproblem von Sicherheitsmaßnahmen ................................... - 58 - Abbildung 15: Risikomanagement Model .......................................................................... - 59 - Abbildung 16: Die einzelnen Schritte des Schlüsseltausch ............................................... - 64 - Abbildung 17: Services zur Generierung von Werten ....................................................... - 67 - Abbildung 18: Struktureller Aufbau des Evaluierungsmodells ........................................... - 76 - Abbildung 19: Über- oder Untergewichtung von Zielkriterien je nach Betreibermodell ..... - 83 - Abbildung 20: Systemlebenszyklus und relevante Kosten ................................................ - 86 - Abbildung 21: Kosten der Anpassung einer E-Shop Software .......................................... - 88 - Abbildung 22: Netz-Darstellung der Stärken und Schwächen ........................................ - 110 - Abbildung 23: E-Shops der Otto Group im Kontext zum BetreibermodellFehler! Textmarke nicht definiert. -5-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Tabellenverzeichnis Tabelle 1: Geschäftsmodelle nach Tapscott, Ticoll und Lowy .......................................... - 12 - Tabelle 2: B2C Geschäftsmodelle nach dem Typ Aggregator .......................................... - 14 - Tabelle 3: B2C E-Commerce Umsatzzahlen für Deutschland im Vergleich in Mrd.€ ........ - 17 - Tabelle 4: Trends und Einflüssen mit Relevanz für E-Shop Software ............................... - 26 - Tabelle 5: Vergleich CSV-, EDI- und XML-basierter Datenformate .................................. - 38 - Tabelle 6: Transaktionsphasen, Aktivitäten des Besuchers und E-Shop Funktionen ....... - 43 - Tabelle 7: Sicherheitsmechanismen ................................................................................. - 60 - Tabelle 8: Aufbau des Evaluierungsmodells ..................................................................... - 77 - Tabelle 9: Erklärung zur Tabelle 8 .................................................................................... - 77 - Tabelle 10: Ziel- und Hilfskriterien für die Kategorie Architektur ....................................... - 79 - Tabelle 11: Ziel- und Hilfskriterien für die Kategorie Funktionen ....................................... - 80 - Tabelle 12: Ziel- und Hilfskriterien für die Kategorie Sicherheit ........................................ - 80 - Tabelle 13: Zielkriterien für die Kategorie Strategie .......................................................... - 80 - Tabelle 14: Die Gewichtung der Zielkriterien-Kategorien .................................................. - 81 - Tabelle 15: Die Gewichtung der Zielkriterien .................................................................... - 82 - Tabelle 16: Für eine E-Shop Software relevante Kostenfaktoren ..................................... - 87 - Tabelle 17: Serverdaten .................................................................................................... - 91 - Tabelle 18: Links zu dem Front- und Back-Ends der E-Shops ......................................... - 91 - Tabelle 19: Login Informationen ........................................................................................ - 91 - Tabelle 20: Serveranforderungen der E-Shop Software ................................................... - 92 - Tabelle 21: Ladezeiten-Test .............................................................................................. - 93 - Tabelle 22: Für die Tests genutzte Dienstleister ............................................................... - 93 - Tabelle 23: Bedingungen der Ladezeiten-Tests ................................................................ - 94 - Tabelle 24: Ladezeitentest mit 100 Artikeln und vier Kategorien ...................................... - 94 - Tabelle 25: Wertung der Zielkriterien-Kategorie Architektur von xt:Commerce ................ - 95 - Tabelle 26: Wertung der Zielkriterien-Kategorie Funktionen von xt:Commerce ................ - 97 - Tabelle 27: Wertung der Zielkriterien-Kategorie Sicherheit von xt:Commerce ................. - 97 - Tabelle 28: Wertung der Zielkriterien-Kategorie Strategie von xt:Commerce ................... - 98 - Tabelle 29: Wertung der Zielkriterien-Kategorie Architektur von OXID CE ....................... - 99 - Tabelle 30: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE .................... - 102 - Tabelle 31: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE .................... - 103 - Tabelle 33: Teilnutzwerte der Zielkriterien ...................................................................... - 109 - Tabelle 34: Teilnutzwerte der Zielkriterien-Kategorien und der Gesamtnutzwerte ......... - 110 - Tabelle 35: Zielkriterien-Kategorien ohne die Gewichtung der Kategorien ..................... - 110 - -6-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Abkürzungsverzeichnis B2B Business to Business B2C Business to Consumer CE Community Edition CMS Content Management Seite CRM Customer Relationship Management ERP Enterprise Resource Planning HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure SEO Search Engine Optimization SOA Service Oriented Architecture SOAP Simple Object Access Protocol UDDI Universal Description, Discovery and Integration URL Uniform Resource Locator WSDL Web Service Description Language -7-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 1. Grundlagen von E-Shop Software In diesem Kapitel werden Begriffe des elektronischen Handels abgegrenzt und näher erläutert. Weiterhin werden die Grundlagen für die Entwicklung des Evaluierungsmodells gebildet. Es werden bestehende Theorien und Erklärungsansätze aus verschiedenen Disziplinen herangezogen, um ein solides Verständnis für das E-Commerce im allgemeinen und E-Shop Software im Speziellen zu gewinnen. 1.1. Definition von E-Business und E-Commerce Der Begriff Electronic Commerce wird sowohl in der wissenschaftlichen als auch in der praxisorientierten Literatur seit Mitte der 90er Jahre diskutiert und sehr unterschiedlich verwendet. 1 In einer frühen Phase des Internets wurde unter E-Commerce, der Verkauf von Dienstleitungen und Gütern über elektronische Netzwerke verstanden. 2 In diesem Sinne wird der Begriff E-Commerce von Herrmanns und Sauter auch als Electronic Shopping oder Online Shopping bezeichnet. 3 Allerdings ist dieser Begriff damit sehr eng gefasst, um alle kommerziellen Aktivitäten des Internets zu erfassen. In der Literatur schlagen deshalb eine Reihe von Autoren vor, den Begriff E-Commerce weiter zu fassen und die Unterstützung aller kommerzieller Aktivitäten wie Geschäftsprozesse, Geschäftstransaktionen, sowie die Beziehungen zu sämtlichen internen und externen Partnern eines Unternehmens durch Informations- und 4 Kommunikationstechnologien in die Definition einzubeziehen. Nach dieser breiten Definition umfasst der Begriff E-Commerce de facto jegliche kommerzielle Aktivität im Internet. Da jedoch mit dem Einzelbegriff Commerce vordergründig Handel gemeint ist, schlagen das mcm Institute und PwC vor, für alle kommerziellen Aktivitäten im Internet den Begriff E- Business zu verwenden: „E-Business ist die Integration von Systemen, Prozessen, Organisationen, Wertschöpfungsketten und ganzen Märkten durch die Anwendung von internetbasierten und –verwandten Technologien und Konzepten. Electronic Commerce ist 1 Vgl. Schmeken, 2007, S. 11; Choi / Stahl / Whinston, 1997, S. 1-4; Clement / Peters / Preiß, 1999, S.49-53. 2 Vgl. Kalakota / Whinston, 1996, S. 1-3. 3 Vgl. Hermanns / Sauter, 1999, S. 14. 4 Vgl. Wigand, 1997, S. 5; Turban / McLean / Wetherbe, 1999, S. 3,5; Stähler, 2002, S. 53; Haertsch, 2000, S. 13; -8-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software demnach ein Teilbereich von E-Business und beschränkt sich im Wesentlichen auf die Marketing- und Verkaufsprozesse.“ 5 In diesem Sinne, findet sich laut Heinemann, der Online Handel im Geschäftskonzept E- Commerce wieder, weil hier die Anbahnung, Aushandlung und Abwicklung von geschäftlichen Transaktionen über Netzwerke erfolgt, d.h. dass ein Leistungsaustausch zwischen Marktteilnehmern mit Hilfe öffentlicher oder privater Netzwerke, wie dem Internet, mit dem Ziel der Wertschöpfung stattfindet. 6 Die nachfolgende Abbildung 1 stellt die Unterscheidung von E-Business und E-Commerce dar und setzt diese gleichzeitig in Relation zu elektronischen Geschäftsbeziehung. Business to Business (B2B) Business to Concumer (B2C) Geschäftspartner Extranet Unternehmen Internet Kunde E-Commerce E-Commerce E-Business Abbildung 1: E-Business und E-Commerce 7 1.2. Elektronische Geschäftsbeziehungen Für die systematische Ableitung der Einsatzmöglichkeiten des E-Commerce, bietet sich die nachfolgende Abbildung 2 an, die neun Markt- und Transaktionsbereiche beschreibt. Damit werden die drei wichtigsten Gruppen von Marktteilnehmern und ihre möglichen Geschäftsverbindungen dargestellt. 5 mcm institute & PwC, 1999, S. 4. 6 Heinemann, 2009, S. 27. 7 In Anlehnung an Stähler, 2002, S. 54. -9-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Nachfrager der Leistung Consumer Busines Administration Consumer Consumer to Business Consumer to Administration Consumer to Consumer Z.B. Jobbörsen mit Anzeigen von Z.B. Steuerabwicklung von Z.B. Internet-Kleinanzeigenmarkt Arbeitssuchenden Privatpersonen Business to Business Anbieter Business to Consumer Business to Administration Busines der Z.B. Bestellung eines Z.B. Bestellung eines Kunden bei Z.B. Steuerabwicklung von Leistung einem E-Shop Unternehmens bei einem Unternehmen Zulieferer Administration Administration to Administration to Consumer Administration to Business Administration Z.B. Abwicklung der Z.B. Beschaffung von z.B. Transaktionen zwischen Einkommenssteuer Lizenzrechten bei Behörden Behörden Abbildung 2: Elektronische Geschäftsbeziehungen 8 Als Anbieter und Nachfrager einer Leistung können sowohl private Konsumenten (Consumer), Unternehmen (Business) als auch öffentliche Institutionen (Administration) auftreten. Mit Business to Consumer (B2C) und Business to Business (B2B), bieten Unternehmen Produkte und Dienstleistungen für Kunden oder weitere Unternehmen an. Auf diese beiden Bereiche geht der Großteil der Umsätze zurück. 9 Weitere Austauschbeziehungen gehen von der öffentlichen Hand (Administration) aus und führen zu weiteren Optionen A2A, A2B und A2C. Bei Administration to Administration werden Kommunikation- und Informationstechnologien verwendet, um verwaltungsinterne Abläufe elektronisch zu gestalten. Dies kann innerhalb einer oder zwischen mehreren Verwaltungsebenen geschehen. Außerdem können Behörden Angebote an Bürger (A2C) oder Unternehmen (A2B) richten. Personen können grundsätzlich sowohl als Leistungsanbieter als auch als Leistungsnachfrager auftreten. Die Option C2C (Consumer to Consumer) beschreibt eine elektronische Geschäftsbeziehung zwischen Einzelpersonen, wie sie beispielsweise über elektronische Marktplätze zustande kommen kann. Des Weiteren können Personen auch Leistungen für Unternehmen oder Verwaltungseinheiten erbringen. 8 In Anlehnung an Hermanns / Sauter, 1999, S. 23. 9 Vgl. Hermanns / Sauter, 1999, S. 22. - 10 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 1.3. Geschäftsmodelle im E-Business und E-Commerce Der Begriff des Geschäftsmodells im E-Business wird in der Literatur sehr uneinheitlich verwendet. 10 Folglich fehlt auch eine allgemein anerkannte Definition. Nach Wirtz, definiert ein E-Business Geschäftsmodell die Schwerpunkte von Unternehmungen und ihrer Erlöserzielung. Timmers schlägt dazu die folgende Definition vor: „A business model is defines as the organization (or architecture) of product, service and information flows, and the sources of revenues and benefits for suppliers and customers.“ 11 Nach Trimmers Definition, beschreibt ein Geschäftsmodell im E-Business also Organisationsstrukturen, die Erlöserzielung und Vorteile, die sich für Anbieter und Kunde ergeben. Ein Geschäftsmodell erlaubt es in einer sehr vereinfachten und zusammengefassten Weise, die für eine Unternehmung einfließenden Ressourcen und die Transformation zu vermarktungsfähigen Produkten und Dienstleistungen darzustellen. Aus einem Geschäftsmodell geht die Kombination der Produktionsfaktoren hervor, die für die Umsetzung der Geschäftsstrategie notwendig ist. Weiterhin werden auch die Rollen einzelner Akteure beschrieben. Grundsätzlich werden in der Literatur eine Vielzahl unterschiedlicher E-Business Geschäftsmodelle beschrieben. Allerdings entwickelt sich der E-Business Markt auch fortwährend weiter und verhält sich dynamisch, weswegen kontinuierlich neue Geschäftsmodelle entstehen und alte an Bedeutung verlieren. Timmers identifiziert elf E-Business Geschäftsmodelle, die in der Literatur vielfach 12 aufgegriffen werden. Rappa beschreibt neun E-Business Geschäftsmodelle aus der Perspektive der Umsatzgenerierung. 13 Im Folgenden werden fünf für das E-Business relevante Geschäftsmodelle nach Tapscott, Ticoll und Lowy beschrieben, die sich durch ihre hohe Abstraktion und Beschränkung auf grundlegende Prozesse von denen anderer Autoren im Bereich des E-Business unterscheiden und wesentlich weniger unter dem Einfluss von Modeerscheinungen stehen. Die folgende Tabelle stellt eine Übersicht der fünf Typen nach Tapscott, Ticoll und Lowy dar, die anschließend näher erläutert werden, wobei nur der Typ Aggregator in seinem Wesen, eine reine B2C E-Commerce Geschäftsbeziehung beschreibt und daher detaillierter erläutert wird. 14 10 Vgl. Wirtz, 2001, S. 210f. 11 Vgl. Timmers, 1999, S. 31. 12 Vgl. Timmers, 1998, S. 3-7. 13 Vgl. Rappa, 18.12.2009. 14 Vgl. Tapscott / Ticoll / Lowy, 1999, S. 198-208. - 11 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Agora Aggregator Integrator Allianz Distributor Ziel- Marktplatz für Digitaler Optimierte selbst organi- Austausch von setzung Waren und Supermarkt Wertschöpfung sierender Informationen, Werte skette Wert- Waren und schöpfungs- Diensten raum Merk- § Markt- § Auslage von § gezielte § Innovation § Netz- male information Produkten Lieferanten- § Vertrauensbil optimierung § Verhandlung § fester Preis auswahl dung § unein- sprozess § einfache § Prozess- § Verzicht auf geschränkte § dynamische Erfüllung optimierung hierarchische Nutzung Preisfindung § Produkt- Kontrolle § Logistik- integration prozess Kunden- Markt- Käufer Wertmotor Beitragender Empfänger rolle teilnehmer Nutzen Verhandelbare Bequeme Kundenspezifis Kreative und Zeitgerechte Marktleistung Auswahl und ches Produkt gemeinschaftli Lieferung Erfüllung che Lösung Tabelle 1: Geschäftsmodelle nach Tapscott, Ticoll und Lowy 15 Der aus der Antike stammende Begriff Agora, ist ein elektronischer Marktplatz auf dem Käufer und Verkäufer zusammenkommen, um über die angebotenen Güter und Preise zu verhandeln. Demnach, gehört die dynamische Preisfindung zu den Hauptmerkmalen. Des Weiteren können unterschiedliche Anbieter Produkte und Dienstleistungen offerieren, weswegen das Angebot theoretisch sehr vielfältig und nicht vorhersehbar sein kann. Indes ist die Werteintegration vergleichbar eingeschränkt, wobei gleichzeitig die Marketing und Vertriebskosten gering ausfallen. 16 Ein Integrator kontrolliert eine Wertschöpfungskette mit allen seinen Komponenten in Form externer Partner und integriert ihre Wertbeiträge. Damit kontrolliert der Integrator die Gestaltung des Produktes bzw. der Dienstleistung, indem er unterschiedliche Hersteller zu einer Wertschöpfungskette zusammenfügt. Der Anstoß geht i.d.R. vom Kunden aus, der eine komplexe und individuelle Lösung nachfragt. 17 Eine Allianz besteht aus eigenständigen in einer Gemeinschaft organisierten Partnern, die gemeinsame Lösungen entwickeln. Mitglieder des Netzwerks bringen ihr spezifisches Know- 15 Vgl. Tapscott / Ticoll / Lowy, 1999, S. 198. 16 Vgl. Meier / Stormer, 2008, S. 35. 17 Vgl. Meier / Stormer, 2008, S. 35-37. - 12 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software how ein und agieren innerhalb des Netzwerkes sowohl als Nachfrager als auch als Anbieter. 18 Ein Distributor gewährleistet einen Austausch von Dienstleistungen, Waren und Informationen. Damit stellt er ein Verteilungsnetzwerk zur Bedienung unterschiedlicher Anbieter und Nutzer dar. 19 Aggregatoren übernehmen eine Vermittlerfunktion zwischen Endkunden und Warenlieferanten, wobei der Warenlieferanten i.d.R Großhändler oder Hersteller ist. Der Aggregator wählt die Produkte und Dienstleistungen, entscheidet über die Preise und 20 kontrolliert die Abwicklung. Die folgende Abbildung stellt die Konstellation eines Aggregators abstrakt dar. Hersteller Käufer Hersteller Aggregator Käufer Hesteller Käufer Abbildung 3: Aggregator kombiniert Produkte und diktiert Preise Dabei greift der Aggregator auf mehrere Hersteller zurück und bietet insgesamt eine große Auswahl an Produkten bzw. Dienstleistungen an. Zu den Kernfunktionen gehört damit die Auslage der Produkte für den Kunden, der seinen Nutzen aus der bequemen Auswahlmöglichkeit und Erfüllung zieht. Aus der Erfüllung der reinen Vermittlerfunktion geht allerdings nur eine geringe Werteintegration hervor. Der Aggregator hat nach Meier und Stormer folgende Vorteile: 21 18 Vgl. Meier / Stormer, 2008, S. 36-38. 19 Vgl. Meier / Stormer, 2008, S. 36-38. 20 Vgl. Meier / Stormer, 2008, S. 37. 21 Vgl. Meier / Stormer, 2008, S. 34-37. - 13 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software § Große Verhandlungsmacht: Dem Aggregator obliegen die Produktauswahl und die Bestimmung der Preiskonditionen § Einsatz digitaler Berater: Softwareagenten helfen bei Such- und Vergleichsvorgängen und erfüllen eine Beratungsfunktion § Unabhängige Produktbewertung: Vor- und Nachteile von Produkten werden von den Kunden erfasst und durch den Aggregator als Entscheidungshilfe publiziert § Stimulierung des Verkaufs: Produktbündelungen, Cross-Selling Maßnahmen und diverse andere Instrumenten der Promotion können realisiert werden Da im Kern Produkte bzw. Dienstleistungen von Unternehmen (Business) an Konsumenten (Consumer) weitergereicht werden, eignet sich der Typ Aggregator seiner Definition nach für die Beschreibung von B2C E-Commerce Geschäftsmodellen, die im Fokus der nachfolgenden Arbeit stehen. Grundsätzlich können die Funktionen des Aggregators, wie nach Tapscott, Ticoll und Lowy definiert, in der Praxis von verschiedenen Typen von Unternehmen erfüllt werden. Laudon und Traver identifizieren vier B2C E-Commerce Geschäftsmodelle, die in der folgenden Tabelle dargestellt werden und dem Typ Aggregator entsprechen: 22 Variation Beschreibung Beispiele Internet Pure Player Händler, die nur das Internet als Amazon.com Absatzkanal nutzen Notebooksbilliger.de Einzelhändler- Einzelhändler, die das Internet als Walmart.com Versender zusätzlichen Absatzkanal nutzen Schlecker.de Kataloghändler- Kataloghändler, die das Internet als Otto.de Versender zusätzlichen Absatzkanal nutzen Neckermann.de Hersteller- Hersteller, die ihre Produkte über das Dell.com Versender Internet direkt an Endkonsumenten Sony.com vertreiben Tabelle 2: B2C Geschäftsmodelle nach dem Typ Aggregator 23 Diese praxisnahe Sicht gibt bereits einen Hinweis darauf, dass ursprünglich E-Commerce fremde Unternehmen, das Internet als weiteren Absatzkanal nutzen. Als Internet Pure Player werden Unternehmen bezeichnet, die ausschließlich das Internet als Vertriebskanal nutzen. Oftmals sind diese Unternehmen auf bestimmte Marktsegmente konzentriert und können flexibel auf Veränderungen reagieren. 24 22 Vgl. Laudon / Traver, 2009, S. 2,14- 2,17. 23 In Anlehnung an Laudon / Traver, 2009, S. 2,14- 2,16. 24 Vgl. Heinemann, 2009, S. 69. - 14 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Im Zuge der zunehmenden Verbreitung des Internets haben auch Einzelhändler und Kataloghändler ihre Unternehmensstrategie angepasst und das Internet als Absatzkanal entdeckt. Da diese Unternehmen mindesten zwei Absatzkanäle nutzen, werden sie auch als Multi-Channel Händler bezeichnet. 25 Allerdings gibt es auch den umgekehrten Fall, dass ein ursprünglicher Internet Pure Player im Einzelhandelsgeschäft aktiv wird und damit ebenfalls der Kategorie Multi-Channel Handel zugeordnet werden kann. Die Hersteller Versender zeichnen sich durch die Beherrschung der kompletten Supply- Chain aus und nutzen den Online Handel als Instrument zur vertikalen Integration, indem sie das Internet als Direktvertriebskanal verwenden. 26 Neben diesen Unternehmenstypen lassen sich insbesondere zwei innovative Ausprägungstypen des Aggregators identifizieren, die insbesondere auf Internet Pure Player zurückgehen, aber auch verstärkt von anderen Marktteilnehmern adaptiert werden: § Liveshopping: Eine sehr begrenzte Produktpalette, in aller Regel nur ein Produkt, für einen begrenzten Zeitraum, in aller Regel nur für einen Tag, zu einen sehr deutlich reduzierten Preis angeboten. Das Konzept wurde inzwischen von einer Vielzahl von etablierten Unternehmen wie z.B. Otto mit dem HAPPY PREIS des Tages, LIDL mit Highlight des Tages und QVC mit Tagesangebot übernommen, die jeweils ein Produkt pro Tag besonders günstig anbieten. Als allgemein bekannte Beispiele reiner Liveshopping Unternehmen können die iBOOD GmbH 27 oder die Live Shopping GmbH 28 genannt werden. § Clubverkauf: Der Besucher muss sich zunächst anmelden, bevor ihm Einblick in das Produktsortiment gewährt wird, wobei die Zahl der möglichen Anmeldungen begrenzt ist. Die Exklusivität steht im Vordergrund. 29 Die Verkaufsaktionen sind zeitlich begrenzt. Üblich sind fünf Aktionen je Woche, die jeweils über ein bis zwei Tage gehen. 30 Als allgemein bekannte Beispiele reiner Clubverkäufer können die Private Sale GmbH oder BuyVIP GmbH geannt werden. 31 1.4. Entwicklung des B2C E-Commerce Der Großteil der Umsätze des Online Handels ist auf die Bereiche B2B und B2C zurückzuführen. Da jedoch alleine der B2C für diese Arbeit von Interesse ist, werden andere Marktzahlen vernachlässigt. 25 Vgl. Heinemann, 2009, S. 70. 26 Vgl. Heinemann, 2009, S. 75. 27 Vgl. iBOOD GmbH, 20.02.2010. 28 Vgl. Live Shopping GmbH, 20.02.2010. 29 Vgl. Heinemann, 2009, S. 69. 30 Vgl. Heinemann, 2009, S. 69. 31 Vgl. Krisch, 20.02.2010. - 15 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Grundsätzlich werden in Deutschland sehr unterschiedliche Marktzahlen seitens verschiedener Organisationen publiziert, die unterschiedliche Detailgrade und Betrachtungsweisen aufweisen und z.T. im Kontrast zueinander stehen, wie die nachfolgende Untersuchung näher erläutert. Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM) weist für 2006 einen B2C Online Umsatz in Deutschland von 46 Mrd. EUR aus und gibt eine durchschnittliche Wachstumsrate von 33 Prozent zwischen 2004 und 2007 an. 32 Für das Jahr 2010 wird ein Umsatz von 145 Mrd. EUR prognostiziert. 33 Die Gesellschaft für Konsumforschung (GfK) weist für das gleiche Jahr einen Umsatz von nur 15,4 Mrd. EUR aus. 34 Aufgrund der deutlichen Unterschiede soll hier ein kurzer direkter Vergleich erfolgen. Anders als bei den BITKOM Zahlen, berücksichtigen die GfK Umsatzzahlen keine Online Reiseumsätze, Online Kraftfahrzeug Umsätze und weitere Bereiche, wie Online Apotheken und kommerzielle Onlineinhalte. 35 Zieht man jedoch auch diese Umsatzzahlen in Betracht, dann ergibt sich ein schlüssigeres Bild, wie die nachfolgende Abbildung zeigt. Sonstiges: § Pharma Kraftfahrzeug Online-Einzelhandel § kostenpflichtiger Online-Handel Online-Reisen Content (z.B. online Zetungsartikel) 46 Mrd.€ 15,4 Mrd.€ 14,2 Mrd.€ 8,4 Mrd.€ 8 Mrd.€ B2C-Umsatz Deutschland 2006 Abbildung 4: Struktur der B2C Internetumsätze in Deutschland 36 Wie Tabelle 3 zeigt, weisen trotz der sehr unterschiedlichen Marktzahlen, alle aufgeführten Organisationen eine zweistellige jährliche Wachstumsrate auf. Online einkaufen wird immer beliebter. 2008 haben 42 Prozent der Deutschen im Internet Waren oder Dienstleistungen bestellt. 37 Aufgrund dieser schnellen Marktentwicklung bezeichnet Heinemann das Internet 32 Vgl. BITKOM, 18.02.2010. 33 Vgl. BITKOM, 18.02.2010. 34 Vgl. GfK, 14.02.2010, S. 2. 35 Vgl. Heinemann, 2009, S. 69. 36 In Anlehnung an Heinemann, 2009, S. 10. 37 Vgl. BITKOM, 2009, S. 11. - 16 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software auch als Vertriebskanal mit der höchsten Wachstumsdynamik, der inzwischen einen Massenmarkt bildet. 38 2003 2004 2005 2006 2007 2008 Jährliche Wachstumsrate 39 BITKOM 22 32 46 27,87% 40 GfK 5,8 7,6 9 10,2 11,4 13,6 15,26% HDE 41 11 13 14,5 16,3 18,3 20 10,48% bvh 42 3,6 5,3 7,4 10 10,9 13,4 24,49% Tabelle 3: B2C E-Commerce Umsatzzahlen für Deutschland im Vergleich in Mrd.€ Über den Markt für technische Lösungen für die Nutzung des B2C E-Commerce liegen keine zuverlässigen Zahlen vor, was einerseits auf die Intransparenz des Marktes und andererseits auf den komplexen Kostenbegriff 43 zurückzuführen ist. Zudem müssen alleine für die Bereitstellung einer E-Shop Software u.U. Leistungen unterschiedlicher Unternehmen in Anspruch genommen werden. 44 Außerdem besteht eine E-Commerce Plattform aus sehr unterschiedlichen Komponenten, wie die nachfolgenden Kapitel näher erläutern werden. Dadurch wird die Erfassung monetärer Größen ungleich schwieriger. Allerdings weisen die genannten B2C Marktzahlen indirekt auf eine hohe Nachfrage nach technischen E-Commerce Lösungen hin. Diese Vermutung wird durch eine Umfrage von Forrester Research bestätigt, die zu dem Ergebnis kommt, dass im Jahr 2009 26 Prozent aller befragten Unternehmen beabsichtigten eine neue E-Shop Software einzusetzen oder die bestehende deutlich weiterzuentwickeln. Trotz Finanzkrise, haben nur vier Prozent aller befragten Unternehmen geplant ihre Investitionen in eine E-Shop Software zurückzufahren. 45 1.5. E-Commerce Plattform In der Literatur wird zwischen verschiedenen Plattformen im E-Business unterschieden. Sowohl Kollmann als auch Roumois schlagen mit E-Procurement, E-Shop, E-Community 38 Vgl. Heinemann, 2009, S. 11. 39 Vgl. BITKOM, 18.02.2010. 40 Vgl. GfK, 14.02.2010, S. 2. 41 Vgl. HDE, 14.02.2010. 42 Vgl. Bundesverband des Deutschen Versandhandels e.V., 26.12.2009. 43 Vgl. Kapitel 4.5. 44 Vgl. Kapitel 2.9. 45 Vgl. Forrester Research, 2009b, S. 4. - 17 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software und E-Marketplace eine Unterscheidung von vier Plattformen für die Abwicklung von elektronischen Geschäftsprozessen vor. 46 E-Procurement bezieht sich auf den Einkauf von Produkten und Dienstleistungen durch Unternehmen. Als zentrale Plattform erlaubt es die Integration von Kommunikations- und Informationstechnologien, um die elektronische Abwicklung bzw. Unterstützung in der Beschaffung, möglich zu machen. 47 E-Marketplace bezeichnet einen elektronischen Marktplatz auf dem Käufer und Verkäufer zusammenkommen, um über die angebotenen Güter und Preise zu verhandeln. 48 Demnach, gehört die dynamische Preisfindung zu den Kernprozessen eines E-Marketplaces. Eine E-Community ermöglicht den Kontakt zwischen Personen bzw. Institutionen über elektronische Kanäle durch die Integration innovativer Kommunikationstechniken. Diese Plattform dient primär dem Wissens- und Datenaustausch. 49 Ein E-Shop ermöglicht den elektronischen Vertrieb von Produkten und Dienstleistungen. Damit geht eine „Integration innovativer Informations- und Kommunikationstechnologien zur Unterstützung bzw. Abwicklung von operativen taktischen und strategischen Aufgaben im Absatz“ einher. 50 Ein E-Shop kann als ein virtueller Verkaufsraum beschrieben werden und als ein eigenständiges System aus Hard- und Software beschrieben werden, das einem 51 Händler erlaubt, seine Wirtschaftsgüter über Rechnernetze anzubieten. Das Gabler Wirtschaftslexikon bezeichnet E-Shops in diesem Zusammenhang auch als Plattform, „auf der Anbieter ihre Waren oder Dienstleistungen präsentieren und der Interessent die Handhabe besitzt, Produktinformationen einzuholen.“ 52 Allerdings muss hier kritisch angemerkt werden, dass diese in der Literatur verbreitete Unterscheidung der Plattformen E-Shop und E-Community z.T. im Widerspruch zur Praxis steht, da es durch den Web 2.0 Trend und hier insbesondere der Zunahme von User Generated Content, 53 es zur Entwicklung hybrider Modelle gekommen ist. 54 Als Beispiele 55 können die Integration von E-Shops in die E-Community Plattform Facebook oder 46 Vgl. Kollmann, 2007, S. 38; Roumois, 2007, S. 99. 47 Vgl. Meier / Stormer, 2008, S. 34. 48 Vgl. Meier / Stormer, 2008, S. 34. 49 Vgl. Kollmann, 2007, S. 39-41. 50 Kollmann, 2007, S. 165. 51 Vgl. Zwißler, 2002, S. 32, S. n. zitiert nach Kollmann, 2007, S. 189, S. m. . 52 Gabler Wirtschaftslexikon, 12.02.2010. 53 Vgl. Kapitel 2.8. 54 Vgl. Hahn, 08.12.2009. 55 Vgl. Wauters, 08.12.2009. - 18 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software andersherum die umfangreichen E-Community Funktionen in den E-Shops der Internetstores AG 56 und Kolibrishop GmbH 57 genannt werden. Die für den B2C E-Commerce relevante Plattform ist, analog zum Geschäftsmodell Typus Aggregator, der E-Shop, da nur dieser auf einen reinen B2C Handel fokussiert ist. Gleichwohl ist nach Definition auch auf der Plattform E-Marketplace ein B2C Handel möglich, was dem Typ Agora entsprechen würde. Allerdings sind E-Marketplaces für den B2C in der Praxis für mittelständische und insbesondere Großunternehmen von minimaler Relevanz. Dies ist insbesondere auf Imagegründe und dem daraus resultierenden Boykott seitens Markenherstellern zurückzuführen. 58 Alle nachfolgenden Ausführungen beziehen sich somit auf die Plattform E-Shop. Nach Kollmann besteht jede Plattform aus weiteren Bausteinen, die betriebswirtschaftlicher und technischer Natur sind, und zwangläufig für die Umsetzung notwendig sind. Demnach stellt die Plattform E-Shop, ein Fundament für Technologien und Produkte dar. 59 Laudon und Traver beschreiben eine praxisorientiertere Sichtweise aus der Perspektive eines Betreibers und identifizieren sechs Komponenten, aus denen eine E-Shop Plattform bestehen kann: Hardware Architektur, Software, Telekommunikations-Infrastruktur, Site-Design, personelle 60 Ressourcen und organisatorische Ressourcen. Diese sechs Komponenten stehen grundsätzlich in gegenseitiger Abhängigkeit zueinander, wobei ein wesentlicher Einfluss von der Wahl der E-Shop Software ausgeht. Internet- verbindung E-Shop Software Server Software Server Betriebssystem Web Server Hardware Abbildung 5: E-Commerce Schichtenpyramide 61 Eine Betrachtungsweise nach Reynolds und Stair führt, mit den technischen Schlüsselkomponenten Server Hardware, Server Betriebssystem, Server Software und E- 56 Vgl. internetstores AG, 08.12.2009a; vgl. internetstores AG, 08.12.2009b. 57 Vgl. Kolibrishop GmbH 08.12.2009. 58 Vgl Krisch, 20.02.2010; Greif, 20.02.2010; Höschl, 20.02.2010. 59 Vgl Loshin / Vacca, 2005, S. 3. 60 Vgl Laudon / Traver, 2009, S. 4,5f 61 In Anlehnun an Reynolds / Stair, 2003, S. 192. - 19 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Shop Software, zu einer vier schichtigen pyramidenartigen Gliederung, wie Abbildung 5 zeigt. 62 Die E-Shop Software bildet dabei die oberste Schicht der E-Commerce Plattform und steht im Mittelpunkt der nachfolgenden Arbeit. 1.6. E-Shop Software Das vorherige Kapitel 2.5 und insbesondere die darin aufgeführten Betrachtungsweisen nach Laudon und Traver, sowie Reynolds und Staire, weisen bereits daraufhin, dass die E-Shop Software zu den Hauptbestandteilen einer E-Shop Plattform gehört. Mit der Definition der E- Shop Plattform wurde somit auch ein Teil der Definition der E-Shop Software bereits vorweg genommen. Für alle weiteren Ausführung, wird der E-Shop Besucher, d.h. also der potentielle online Besteller, als Endkunde bezeichnet. Das in Kapitel 2.3 als Aggregator definierte Unternehmen, das ein E-Shop für die Teilnahme am online Handel betreibt wird nachfolgend als E-Shop Betreiber bezeichnet. Im Unterschied zu den anderen nach Reynold und Stair definierten Bausteine einer E-Shop Plattform, wie z.B. der Server Hardware, sieht der Endkunde die E-Shop Software bzw. dessen Front-End 63 und führt über diese Transaktionen aus. Somit nimmt der Endkunde subjektiv auch nur die E-Shop Software bzw. dessen Front-End direkt wahr. Daher bezeichnet Tassabehji eine E-Shop Software auch als Schnittstelle zwischen E-Shop Betreiber und Endkunde. 64 In der Literatur werden unterschiedliche Begriffe zur Bezeichnung von E-Shop Software verwendet. Verbreitet sind insbesondere die aus dem englischen übernommenen Bezeichnungen Online Shop Software, Shopping Cart Software, Shopsystem oder Webshop. Seltener wird der abstraktere Begriff E-Commerce Software verwendet. Der Begriff Shopsystem kann folglich als Synonym für E-Shop Software verwendet werden. Goluchowski, Filipczyk und Malgotzta definieren drei Kernaufgaben einer E-Shop Software: 65 § Übermittlung und Austausch von Informationen § Kommunikation § Verkaufstransaktion Die Übermittlung und der Austausch von Informationen können beispielsweise durch einen Newsletter oder eine Produktbewertung erfolgen. Als Beispiele für kommunikative 62 Vgl Reynolds / Stair, 2003, S. 3. 63 Vgl. Kapitel 2.7. 64 Vgl Tassabehji, 2005, S. 102. 65 Vgl. Goluchowski / Filipczyk / Jablonska, 2007, S. 16f. - 20 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Funktionen können u.a. ein Kontaktformular oder Live Chat mit dem Service, genannt werden. Verkaufstransaktionen können z.B. mit Hilfe eines virtuellen Warenkorbes oder einer Bezahlfunktion realisiert werden. Nach Reynolds und Stair bilden die Elemente Katalog, Kunden und Geschäftsprozesse den Kern einer E-Shop Software, wie die Abbildung 6 darstellt. Folglich gehören typischerweise mindestens das Produktkatalogmanagement, Kundenmanagement und die zugehörigen Geschäftsprozesse zur Abwicklung von Transaktionen zu den Komponenten einer E-Shop Software. 66 Katalog Kunden Geschäftsprozesse Abbildung 6: E-Commerce Plattform Die Funktionen können von einer oder mehreren Softwares erfüllt werden. 67 Der Betreiber muss die Möglichkeit haben, die Geschäftsprozesse nach Bedarf zu modellieren und zu automatisieren, wie viele unterschiedliche Softwares eingesetzt werden müssen, hängt von dem individuellen Bedarf ab. Im Mittelpunkt steht jedoch stets eine zentrale Software, die in allen weiteren Ausführungen als E-Shop Software bezeichnet wird, da alle weiteren E-Shop Softwarekomponenten i.d.R. ihr angehängt werden oder zumindest in direkter Abhängigkeit zu ihr stehen. Jede durch einen Endkunde elektronisch angestoßene Transaktion geht prinzipiell von der E-Shop Software aus. 66 Vgl. Reynolds / Stair, 2003, S. 193. 67 Vgl. Illik, 2002, S. 131. - 21 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 1.7. E-Shop Softwarekomponenten Eine E-Shop Software besteht i.d.R. aus verschiedenen Komponenten. 68 In diesem Sinne, wird insbesondere in der amerikanischen Literatur manchmal auch die Begriff Softwaresuite, d.h. also zu Softwaresammlung, gebraucht. 69 Wodurch deutlicher darauf hingewiesen wird, dass eine E-Shop Software aus einer Vielzahl von Komponenten bestehen kann. Allerdings wird in der Literatur oftmals nicht näher diskutiert, ob diese sog. Komponenten in der Praxis integrierte Bestandteile der E-Shop Software oder z.B. eigenständige Software mit entsprechenden Schnittstellen zur E-Shop Software darstellen. Gleichwohl trägt die rein theoretische Betrachtung der Komponenten unter Vernachlässigung der Integrationstiefe, zur übersichtlicheren Darstellung und damit besserem Verständnis bei. Abbildung 7 zeigt in diesem Sinne den abstrakten Aufbau einer möglichen E-Shop Softwarelösung, welches wie in bei diesem Beispiel das Katalog-, Kunden- und Transaktionsverwaltung als Schlüsselkomponenten beinhalten kann. Jedem dieser drei Komponenten, können prinzipiell weitere Komponenten angehängt werden, wie Abbildung 7 darstellt. Marketing Werbeinstrumente gezielte Kundenansprache Content Management User Generated Content Kunden- Katalog ERP Produktempfehlungen management Anbindung Verfügbarkeit Kommunikation mit Kunden La g un ge d rve bin rw en a nd ltu Ku ng Liefermanegement Retourenmanagement Transaktions- verwaltung Zahlungsabwicklung Abbildung 7: Beispielhafte Darstellung der E-Shop Softwarekomponenten 70 Grundsätzlich kann eine E-Commerce Software in ein sog. Front-End und Back-End 71 unterteilt werden. Der Endkunde sieht jedoch nur das Front-End, mit dessen 68 Vgl. Laudon / Traver, 2009, S. 4,1- 4,29; Bigdoli, 2007, S. 138-140. 69 Vgl. Laudon / Traver, 2009, S. 4,26- 4,28. 70 In Anlehnung an Walker, 2009, S. 10. - 22 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Benutzeroberfläche er interagiert. Das Back-End dient im Gegensatz dazu, der internen Abwicklung der Prozesse und der Administration der Plattform. 72 Zu den Funktionen im Front-End-Bereich gehören insbesondere 73: § Produktkatalog (Kapitel 3.2.1) § Kundenkonto (Kapitel 3.2.8) § Produktwarenkorb (Kapitel 3.2.2.1) § Bestellformular (Kapitel 3.2.2.2) § After-Sales-Funktionen (Kapitel 3.2.8) Zu den wesentlichen Funktionen im Back-End-Bereich gehören 74: § Content Management System (Kapitel 3.2.3) § Kundenmanagement (Kapitel 3.2.8) § Web Analytics (Kapitel 3.2.5) § Produktkatalog (Kapitel 3.2.1) Die aufgeführten Komponenten sind, sofern vorhanden, entweder integrierte Bestandteile der E-Shop Software oder stehen zumindest im Datenaustausch. Die einzelnen Komponenten des Front- und Back-Ends werden in Kapitel 3 im Detail erläutert. 1.8. E-Shop Softwaretrends Auch nach über dreizehn Jahren des Online Handel, eines Internetbooms, dem Niedergang der New Economy und der Wiederauferstehung dessen, kann eine dynamische Innovationskraft beobachtet werden, die maßgeblichen Einfluss auf E-Shop Software hat. Diese Einflüsse sind nicht nur technischer, sondern durchaus vielfältiger Natur und folgen z.T. dem Zeitgeist der Gesellschaft. Social Software, neue Internettechnologien und die Veränderung der Nutzeraktivitäten im Internet werden zusammenfassend auch als Web 2.0 bezeichnet. Bis heute gibt es keine eindeutige Definition des Begriffes. 75 O’Reilly definiert den Begriff Web 2.0 wie folgt: „Web 2.0 is the business revolution in the computer industry caused by the move to the internet as platform, and an attempt to understand the rules for success on that new platform. Chief among those rules is this: Build applications that harness network effects to get better the 71 Vgl. Kollmann, 2009, S. 213. 72 Vgl. Kollmann, 2009, S. 213. 73 Vgl. Kollmann, 2009, S. 213-215. 74 Vgl. Kollmann, 2009, S. 213-215. 75 Vgl. Deans, 2009, S. 5. - 23 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software more people use them. This is what I've elsewhere called harnessing collective intelligence.“ 76 Trotz unscharfer Definition verbirgt sich hinter dem Begriff die konkrete Vorstellung von einer neuen Art des Internets. Sie basiert auf der Annahme, dass das Platzen der Internetblase (Dot-Com-Kollaps) Ende des letzten Jahrzehnts zu einem Zusammenbruch des Internets in der damaligen Form geführt hat. Erfolgreich fortbestehen konnten nur diejenigen, die in der Lage waren, sich weiter zu entwickeln und einen neuen Ansatz für den Umgang mit dem Internet zu finden. 77 Der Benutzer dieser neuen Form des Internets ist nicht nur Konsument, sondern zugleich auch Inhaltslieferant. Dafür findet er im Gegenzug aber auch besser auf seine Bedürfnisse abgestimmte Inhalte vor. Daraus kann sich eine kollektive Intelligenz im Internet formen, die im Wesentlichen auf der Verknüpfung bzw. Vernetzung der Inhalte durch seine Benutzer mittels Hyperlinks beruht. Dynamische Inhalte haben statische Homepages abgelöst und bieten vielfältige Dialog- und Interaktionsmöglichkeiten mit anderen Nutzern des Internets. 78 Da die Anwendungen auf den Nutzer zugeschnitten werden, wird ein besonderes Augenmerk auf ihre Benutzerfreundlichkeit gerichtet und Wert auf Feedbacks der Nutzer gelegt. 79 Da es sich bei der Entwicklung von Web 1.0 zu Web 2.0 nur um eine wahrgenommene Entwicklung und nicht um eine neue Version des Webs handelt, zeigt die folgende Abbildung 8 die Art und Weise der Betrachtung. 80 76 O'Reilly, 07.01.2010. 77 Vgl. O'Reilly, 08.01.2010. 78 Vgl. Beckert, 2007, S. 7f. 79 Vgl. Ebersbach et al., 2008, S. 24. 80 Vgl. Trump et al., 2007, S. 9. - 24 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software gestaltend Web 2.0 Kommunikation Kommunikation individuelle öffentliche Web 1.0 betrachtend Aktiv partizipierende Nutzer Passiv partizipierende Nutzer Abbildung 8: Die zwei Dimensionen des Internets 81 Die Betrachtungsweisen gehen hier von rein betrachtend und individuell kommunizierend bis zu gestaltend und öffentlich kommunizierend. Die Dimension Gestaltungsgrad erstreckt sich von rein betrachtender Nutzung, z.B. durch das Lesen eines Artikels, bis zur gestaltender 82 Nutzung, z.B. durch Verfassen von Texten im Internet. Die zweite Dimension Kommunikationsgrad erstreckt sich vom Bereich der individuellen Kommunikation, z. B. versenden von privaten E-Mails, bis zum Bereich der öffentlichen Kommunikation. 83 Bei der Evaluierung und Auswahl von E-Shop Software ist es unabdingbar diese Einflüsse zu berücksichtigen, da sie sich in den Bedürfnissen des Endkunden widerspiegeln. Dieses Kapitel soll eine Übersicht dieser Einflüsse und Trends aufzeigen, die innerhalb der nächsten Kapitel aufgegriffen und z.T. im Detail behandelt werden. In diesem Sinne gewährt die folgende Tabelle eine Übersicht über heutige Trends und Einflüsse auf Grundlage von Walkers Vorschlägen, die relevant für E-Shop Software sind. 84 Perso- Die Beziehung zwischen E-Shop Betreiber und Endkunden „weicht, nalisierung getrieben von einer Verlagerung der Endkundenerwartungen, zunehmend einer stärkeren Integration des Nachfragers in die Angebotserstellung von Personalisierung und Individualisierung der Angebote.“ 85 Dazu eignen sich 81 In Anlehnung an Trump et al., 2007, S. 9. 82 Vgl. Trump et al., 2007, S. 10. 83 Vgl. Trump et al., 2007, S. 10. 84 Vgl. Walker, 2009, S. 6. 85 Wirtz, 2001, S. 289. - 25 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Produktempfehlungsfunktionen, wie z.B. Cross- oder Up-Selling 86 Funktionen. Beim Up-Selling werden Produkte auf Basis der bisherigen Wahl, passende Produkte mit einem höheren Preis angeboten. 87 Cross- Selling kann als sinnvolle Produktempfehlungen, über Produktkategorien hinweg definiert werden. 88 Multiple Eine zunehmende Anzahl an Ausprägungstypen des Geschäftsmodells Geschäfts- Aggregator, wie z.B. Clubverkauf und Liveshopping, 89 stellen besondere modelle Anforderungen an die E-Shop Software flexibel für unterschiedliche Ausprägungstypen verwendbar zu sein. Inter- International aufgestellte E-Shop Betreiber sehen sich gefordert in den nationalisierung Zielmärkten regionalspezifisch angepasst, andererseits aber wiedererkennbar und mit den gleichen Daten aufzutreten und das möglichst zentral zu steuern. 90 Globale E-Commerce Lösungen sollten unterschiedliche lokale Gepflogenheiten hinsichtlich Sprache, Adressformate, Workflows, Mehrwertsteueranzeige etc. unterstützen und die unterschiedlichen lokalen E-Commerce Varianten in einem System konsolidieren und betreiben. Die Unterstützung von internationalen E- Commerce Aktivitäten durch die E-Shop Software wird in Kapitel 3.2.5 näher erläutert. User Generated Mediale Inhalte, wie z.B. Text, Fotos und Videos, die vom Nutzer Content bereitgestellt werden, können als User Generated Content bezeichnet werden. 91 Bei E-Shops findet man diese insbesondere in Form von E- Shop-Bewertungen, Produktbewertungen und produktbezogenen Diskussionen wieder. Dies kann innerhalb des E-Shops, z.B. durch entsprechende Bewertungsformulare je Produkt, die Integration von Foren und Blogs, sowie Anbindung von Bewertungssysteme Dritter, realisiert werden. User Generated Content stellt eine zusätzliche Informationsquelle für potenzielle Endkunden dar, bindet Endkunden und führt zu einer verbesserten Suchmaschinenfreundlichkeit. Tabelle 4: Trends und Einflüssen mit Relevanz für E-Shop Software 92 86 Vgl. Panniello / Gorgoglione / Palmisano, 2009, S. 248-250. 87 Vgl. Bustos, 08.01.2010. 88 Vgl. Netessine / Savin / Xiao, 2004, S. 2-3. 89 Vgl. Kapitel 2.3. 90 Vgl. BITKOM, 2009, S. 26. 91 Vgl. Tapp, 2008, S. 302-303. 92 Vgl. Walker, 2009, S. 6. - 26 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 1.9. Betreibermodelle Die Nutzung und Verbreitung von Software unterliegt als Ausdruck einer schöpferischen Leistung dem urheberrechtlichen Schutz. Entsprechend des deutschen Urhebergesetzes kann der geistige Schöpfer eines Werkes bezüglich der Nutzung und Verbreitung entscheiden. 93 Die genaue Ausgestaltung der vom Urheber gewährten Nutzungsrechte, wird in der Softwarelizenz festgehalten. Dabei unterscheiden sich je nach Distributions-Modell, die Nutzungsrechte und Möglichkeiten sehr deutlich. Nach der ibi research an der Universität Regensburg GmbH, kann aus Sicht eines E-Shop Software Nachfragers grundsätzlich zwischen vier E-Shop Software-Distributionsmodell unterscheiden: 94 § quelloffene Software § Miet-Software § Eigenentwicklung § Kauf-Software Als quelloffen, im Englischen auch Open Source genannt, werden Programme bezeichnet, deren Quellcodes offen zugänglich sind, die uneingeschränkt genutzt, verändert und erweitert werden können, sowie „in modifizierter wie in nichtmodifizierter Form lizenzkostenfrei vervielfältigt und verbreitet werden dürfen.“ 95 Folglich kann sie i.d.R. beliebig weiterentwickelt und je nach Anwendungszweck angepasst werden. Quelloffene E-Shop Software ist ihrer Definition nach, grundsätzlich kostenlos beziehbar. Miet-Software basiert auf dem Grundsatz, dass die Software von einem externen Dienstleister betrieben wird. Miet-Software für E-Shops, wird somit i.d.R. auf dem Servern des Anbieters installiert und lässt sich nach einem Baukastensystem einrichten und erweitern. Allerdings kann i.d.R. nur das Partnerunternehmen, das die Miet-Software anbietet auch weitreichende Änderungen am Softwarecode vornehmen, da die Anpassungsmöglichkeiten seitens des Nachfrager begrenzt sind. In der Literatur und der Industrie werden z.T. unterschiedliche Begriffe wie ASP (Application Service Providing), SaaS (Software as a Service) oder on demand Solutions verwendet. Dabei beschreiben diese Begriffe unterschiedliche Varianten von Miet-Software, die sich oftmals durch ihren Standardisierungsgrad unterscheiden und nicht selten zu 93 Vgl. Mundhenke, 2007, S. 40. 94 Vgl. ibi research an der Universität Regensburg GmbH, 2009, S. 45-47. 95 Mundhenke, 2007, S. 15. - 27 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 96 Marketingzwecken genutzt werden. An dieser Stelle soll auf diese Varianten der Miet- Software verwiesen werden, wobei auf eine tiefere Diskussion dieser verzichtet wird. 97 Intern entwickelte E-Shop Software ist i.d.R. sehr individuellen Bedürfnissen zugeschnitten und wird als Eigenentwicklung bezeichnet. Theoretisch sind der Entwicklung keine Grenzen gesetzt. In der Praxis hängt die Entwicklung jedoch von verfügbaren Ressourcen ab. Kauf-Software basiert entweder auf eine Eigenentwicklung oder quelloffener-Software. In der Literatur wird Kaufsoftware auch als Fertigsoftware oder kommerzielle Standardsoftware bezeichnet. 98 Kauf-Software wird oftmals in Kombination mit zusätzlichen Dienstleistungen, wie z.B. Supportverträgen, erworben. Die Nutzung der Software kann seitens des Herstellers auf verschiedenste Weise, wie z.B. zeitlich, funktional oder nach Anzahl der Administratoren bzw. Mitarbeiter, eingeschränkt werden. Ebenso können Änderungen am Code untersagt 99 sein. Grundsätzlich hängen die Rechte des E-Shop Betreibers von dem jeweils vereinbarten Kaufvertrag ab. Die unterschiedlichen Distributionsmodelle zeigen, dass der E-Shop Betreiber, abhängig vom gewählten Modell, ein unterschiedliches Maß an Ressourcen selber bereitstellen bzw. in unterschiedlichem Maße externe Unternehmen einbeziehen muss. Kollmann greift diese Problematik auf und unterscheidet mit dem Betreiber-, Dienstleister- und Partner-Modell, zwischen drei Modellen, die sich durch unterschiedliche Wertbeiträge unterscheiden, wie die Abbildung 9 verdeutlicht. 100 96 Vgl. Lassmann, 2006, S. 130; Schaffry, 04.01.2010; Grobmann, 2008, S. 15-17. 97 Für weitere Informationen sei auf folgende Literatur verwiesen: Beinhauer / Herr / Schmidt, 2008; Buxmann / Diefenbach / Hess, 2008; Grobmann, 2008. 98 Vgl. Henning, 2004, S. 11. 99 Vgl. Gläßer, 2004, S. 19f. 100 Vgl. Kollmann, 2007, S. 319-321. - 28 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Betreiber Dienstleister Partner E-Shop Individual- Standard- Software lösung lösung Eigen- Administration Partner verantwortung Resourcen- hoch niedrig bedarf Strategischer hoch niedrig Einfluss Abbildung 9: Wertbeiträge-Modell für E-Shop Lösungen 101 Mit Abbildung 9 wird E-Shop Software in Relations zum Wertbeitrag seitens des E-Shop Betreibers, idealistisch betrachtet. Charakteristisch für das Betreiber-Modell ist die hohe Eigenverantwortung des E-Shop Betreiber, da sie eine Lösung größtenteils bis vollständig im eigenen Haus entwickelt und selber alle notwendigen Dienstleistungen, wie die Administration und Instandhaltung erbringt. Dem entsprechend ist das Modell sehr individuell. Allerdings muss das jeweilige Unternehmen auch weitreichende Ressourcen, wie z.B. Know-how, bereitstellen. 102 Dafür behält der E-Shop Betreiber einen hohen strategischen Einfluss. Das Partner-Modell bildet das andere Extrem innerhalb der Skala. Charakteristisch für diese Modelle ist die überwiegende bis vollständige Übertragung aller Aufgaben auf ein Partnerunternehmen, das sämtliche Dienstleistungen, wie die Administration, Installation der E-Shop Software und Bereitstellung der technischen Infrastruktur gewährleistet. Ebenso ist diese i.d.R. für die Wartung und den Support verantwortlich. Folglich fallen die Startkosten geringer aus als bei den anderen beiden Modellen. Auch fällt der Ressourcenbedarf vergleichbar gering aus, da das Partnerunternehmen weitreichende Aufgaben erfüllt. 103 Allerdings verfügt das Unternehmen, das diese Dienstleistungen nachfragt über einen nur geringen strategischen Einfluss und ist stark abhängig vom externen Dienstleister. Das Dienstleister-Modell befindet sich innerhalb der Skala zwischen dem Betreiber- und Partner-Modell. Dem entsprechend stellt es eine Mischung aus beiden Modellen dar. Es 101 In Anlehnung an Kollmann, 2007, S. 321. 102 Vgl. Kollmann, 2007, S. 319-321. 103 Vgl. Kollmann, 2007, S. 319-321. - 29 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software nutzt nur bis zu einem bestimmten Grad externe Dienstleister und nutzt auch eigene Ressourcen. Folglich verfügt es über einen deutlichen strategischen Einfluss. 104 Da das Betreiber-Modell auf eine sehr individuelle Lösung setzt, eignet sich sowohl eine Eigenentwicklung, als auch eine quelloffene E-Shop Software, da dessen Quellcode beliebig verändert werden darf. Für das Dienstleister-Modell eignet sich Kauf-Software, da der E-Shop Betreiber damit einen vorgefertigten Shop erwirbt, der je nach seinen Bedürfnissen insbesondere optisch angepasst werden muss. Beim Partner-Modell wird eine Miet-Software angeboten, da das Partnerunternehmen sehr weitreichende Aufgaben erfüllt und selbst hostet. Die Miet-Software an sich kann auf andere Distributionsmodelle basieren und z.B. eine Eigenentwicklung sein. Aber aus Sicht des E- Shop Betreiber handelt es sich um eine Miet-Software. Allerdings kann die Miet-Software an sich ein E-Shop Software sein die vom Partner- Unternehmen auf Basis eines quelloffenen E-Shops entwickelt wurde oder eine Kauf- Software eines anderen Herstellers darstellt. Diese drei Szenarien stellen typische Beispiele dar. Da es sich jedoch um eine Skala handelt, sind diverse Mischformen denkbar. Für den Bereich zwischen Betreiber- und Dienstleister-Modell kann sich z.B. eine quelloffene Software anbieten, wobei diverse Dienstleistungen, z.B. zur Anpassung der Software, eingekauft werden Die nachfolgende Abbildung verbildlicht die Verknüpfung der Distributionsmodelle mit dem Wertbeiträge-Modell. Abbildung 10: Einsatz der E-Shop Distributionsmodelle in Abhängigkeit zum Wertbeitrag 104 Vgl. Kollmann, 2007, S. 319-324. - 30 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Abbildung 10 zeigt sehr idealistisch und allgemein, welche bis zu welchem Grad E-Shop Software Distributionsmodelle externe Dienstleister einbinden, ohne Anspruch auf Vollständigkeit zu erheben. 2. Anforderungen an E-Shop Software Thayer und Dorfman definieren Anforderungen als eine vom Anwender benötigte Fähigkeit des Systems, um ein Problem zu lösen oder ein Ziel zu erreichen, oder eine Fähigkeit, die das System besitzen muss, damit es einen Vertrag, einen Standard, eine Spezifikation oder ein anderes formelles Dokument erfüllt. 105 Thayer und Dorfmans Definition aufgreifend, muss an dieser angemerkt werden, dass im Falle von E-Shop Software zwei Anwendertypen berücksichtigt werden müssen. Der Endkunde, der einmal später Produkte und Dienstleistungen über den E-Shop beziehen soll, sowie der Betreiber, der den E-Shop zum Vertrieb seiner Produkte oder Dienstleistungen nutzt. Dabei ist eine einseitige Betrachtung der Anforderungen, wie z.B. nur aus Sicht des Endkunden oder E-Shop Betreibers nicht sinnvoll, da gegenseitige Abhängigkeiten bestehen. Eine E-Shop Software, die nahtlos in das bestehende Informationssystem eines E-Shop Betreibers eingebunden werden kann, aber wegen mangelnder Funktionen wenig kundenfreundlich ist, stellt keinen Idealzustand dar. Ebenso wenig erfolgreich wäre voraussichtlich ein aus Endkundensicht komfortabel zu bedienender E-Shop, der jedoch aufgrund von fehlenden Schnittstellen, für den E-Shop Betreiber sehr hohe Kosten in der Abwicklung von Transaktionen verursacht. Opuchlik z.B. definiert mit Produkten, Verkaufsförderung, Service, Komfort und Navigation, Warenkorb und Bezahlung, sowie Sicherheit, sieben Anforderungen aus Endkundensicht, die jedoch nur sehr bedingt relevante Anforderungen für die Evaluierung von E-Shop Software darstellen. Schließlich hängt die Verkaufsförderung beispielsweise vom Unternehmensmarketing ab, die Bezahlung von der Unternehmenspolitik und der Service sind abhängig vom Liefer- und Kundenservice. Freilich sind das Unternehmensmarketing, die Unternehmenspolitik oder der Liefer- und Kundenservice keine Faktoren, die maßgeblich abhängig von der E-Shop Software wären. Folglich bedarf es zwar eine gesamtheitliche Betrachtung der Anforderungen, sowohl aus Endkunden- als auch E-Shop Betreiber Sicht, wobei Anforderungen ohne Relevanz für die Evaluierung einer E-Shop Software von der Betrachtung ausgeschlossen werden müssen. 105 Vgl. Thayer, Richard H.; Dorfman, Merlin; Baili, 1997, S. 23-28. - 31 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Die in Kapitel 2 aufgeführten Definitionen und Diskussionen des Geschäftsmodell Typus Aggregator, der E-Commerce Plattform E-Shop und der E-Shop Software, werden in diesem Kapitel als Grundlage für die Identifizierung, Definition und Gruppierung der Anforderungen an E-Shop Software, seitens E-Shop Betreiber und Endkunden verwendet. Des Weiteren werden die nachfolgenden Unterscheidungen verschiedener Autoren berücksichtigt. Reynolds und Staire schlagen mit Katalog Management, Produktwarenkorb und Produktmanagement eine dreigliedrige Gruppierung vor. 106 Schneider schlägt mit Katalog, Produktwarenkorb und Transaktionsverwaltung eine sehr ähnliche Unterscheidung vor. 107 Schneider sieht anders als Reynolds und Staire, das Produktmanagement als Teil des Katalog Managements, wobei er die Abwicklung von Transaktionen nicht der Gruppe Produktwarenkorb getrennt betrachtet. Insgesamt basieren die Unterschiede zwischen Reynolds und Staire sowie Schneiders Betrachtung, also auf unterschiedliche Definitionen. Opuchlik schlägt mit der Gruppierung der Anforderungen in Architektur, Administration, Sicherheit und Skalierbarkeit eine weitergehende Unterscheidung vor, wobei unter dem Begriff Administration im Grunde Back-End Funktionen 108 zusammengefasst werden. 109 Die bisher erwähnten Autoren definieren Anforderungen an eine E-Shop Software ohne jedoch den Einfluss des Herstellers für die zukünftige Entwicklung der E-Shop Software zu berücksichtigen. Die BITKOM bleibt bei der Formulierung von Anforderungen sehr allgemein, weist jedoch auf verschiedene Betreibermodelle hin und unterstreicht die Bedeutung des Herstellersupports. 110 Die Einbeziehung des E-Shop Softwareherstellers, stellt aufgrund der z.T. hohen Abhängigkeit je nach Betreibermodel, ein wichtiges Kriterium dar. 111 Aufbauend auf die hier dargestellten Vorschläge verschiedener Autoren, werden nachfolgend die Anforderungen an E-Shop Software, bei einer Gliederung in die Teilbereiche Architektur, Funktionen, Sicherheit und Strategie, im Detail erläutert. 106 Vgl. Reynold / Staire, 2003, S.193f. 107 Vgl. Schneider, 2004, S. 361. 108 Vgl. Kapitel 2.7. 109 Vgl. Opuchik, 205, S. 117. 110 Vgl. BITKOM, 2009, S. 29-32. 111 Vgl. Turban / Rainer Jr., 2009, S. 14,47-14,51; Reynolds, 2004, S. 200f; Korper / Ellis, 2001, S. 172-175. - 32 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 2.1. Architektur E-Commerce Lösungen müssen in der Position sein, wachsende Benutzerzahlen bewältigen zu können und Dienste auch bei einer hohen Auslastung zuverlässig bereitstellen zu können. Sich schnell verändernde Anforderungen, bedürfen die zuverlässigen, interaktiven und sicheren Zusammenarbeit interner und externer Ressourcen, bei gleichzeitiger Wahrung der Flexibilität. 112 Die Architektur beschreibt die Struktur eines Systems, dessen Bausteine, Schnittstellen und deren Zusammenspiel. 113 Die Architektur besteht aus Plänen und enthält i.d.R. Hinweise und Vorschriften, nach denen das System zusammengebaut werden sollte. 114 Damit kann die Software-Architektur auch als Plan eines Systems gesehen werden. Durch die Architektur wird die Komplexität eines Systems besser erfassbar und verständlicher. Tom DeMarco bezeichnet die Architektur auch als framework of change, d.h. sie kann einen Rahmen darstellen innerhalb dessen die Software entwickelt werden kann. 115 Bass, Clements und Kazman definieren Software-Architektur als die Struktur eines Systems, das Softwarekomponenten, die Eigenschaften dieser Komponenten sowie deren 116 Beziehungen aufzeigt. Der in dieser Definition genannte Begriff Komponente, kann beispielsweise eine Datenbank oder ein Server sein. Durch die Beziehung der Komponenten untereinander und der Eigenschaften dieser Beziehungen entsteht eine Struktur, die man Software-Architektur nennt. 117 Entsprechend der sich mit der Zeit verändernden Anforderungen an Software, unterliegt auch die Architektur Veränderungen. Die Anforderungen können sich grundsätzlich sowohl während der Entwicklungsphase als auch danach ändern. Die folgende Abbildung stellt die Einflussfaktoren in Bezug auf die Architektur dar. 112 Vgl. Strobel, 2004, S121. 113 Vgl. Starke / Hruschka, 2009, S. 2. 114 Vgl. Starke / Hruschka, 2009, S. 3. 115 Vgl. DeMarco,1995, S. 128; Eichinger, 2003, S. 66. 116 Vgl. Bass / Clements / Kazman, 2003, S. 3. 117 Vgl. Müller, 2005, S. 59. - 33 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Fu ät nk lit tio ua ne Q n Software Architektur Te ch ni g un sc hr he fa As Er pe kt e Abbildung 11: Auf die Entwicklung einer Softwarearchitektur wirkende Faktoren 118 Wie in der Abbildung 11 dargestellt, können vier unterschiedliche Einflussfaktoren unterschieden werden. Die funktionalen Faktoren beziehen sich die Clienten und andere Nutzergruppen. Zu den qualitativen Faktoren können insbesondere die Erweiterbarkeit, Performance und Wiederverwendbarkeit gezählt werden. Ein technische Aspekt kann z.B. das Betriebssystem sein. Der Einflussfaktor Erfahrung bezieht sich z.B. auf das Projektmanagement und Erfahrungswerten aus bestehenden Softwarearchitekturen. 119 In den nachfolgenden Unterkapiteln werden Softwarearchitekturen mit Fokus auf E-Shop Software näher erläutert. 2.1.1. Architekturmuster Eine bewährte Form der Dokumentation von Software-Architekturstrukturen ist das Schichten-Architekturmuster. 120 Mit dieser kann die Anordnung von Systembausteinen auf unterschiedlichen Ebenen dokumentiert werden. Unter einer Schicht kann ein abgekapseltes Objekt oder eine Komponente verstanden werden. 121 Durch die Schichten-Architektur wird eine klare Trennung der Funktionen und Aufgaben erreicht. Grundsätzlich sind unterschiedliche Merkmale der Trennung möglich. In Anlehnung an das ISO- 118 Vgl. Eichinger, 2003, S. 67. 119 Vgl. Eichinger, 2003, S. 67. 120 Vgl. Vogel u.a., 2005, S. 34. 121 Vgl. Strobel, 2004, S. 122. - 34 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Schichtenmodell, dürfen die Schichten nur mit den benachbarten Schichten kommunizieren, d.h. mit den Schichten, die über oder unter ihnen liegen. 122 2.1.2. Zwei- und n-Schichten Architektur Eine Client/Server Lösung stellt eine typische zwei-Schichten-Architektur dar. 123 Der Server beherbergt die Datenbank und realisiert die Zugriffe auf die Daten, die vom Client initiiert werden. Diese Architektur basiert auf einem einfachen Anfrage- /Antwort Konstrukt. Grundsätzlich ist sie für einfache Anwendungen geeignet und funktioniert bei einer bestimmten Anzahl an Clienten gut, wobei jedoch, die Leistung bei hohen Nutzerzahlen stark abnimmt. 124 Strobel identifiziert dazu weitere Nachteile 125: § Der Entwicklungsprozess der Anwendung geschieht auf einem Computersystem, das die Informationen darstellt und verarbeitet. Dadurch wird der Anwendungscode aus den verschiedenen Teilen miteinander vermischt und das individuelle Programm lässt sich schwer warten. § Es ist eine Entwicklungsgruppe notwendig, die sich mit der grafischen und der Verarbeitungslogik auskennt, da sich die Verarbeitungslogik und Präsentation der Daten in der gleichen Schicht befinden. § „Die Wiederverwendung der Anwendungsteile ist wegen Individualität des Codes schwierig.“ 126 § Der Datenbankserver muss zusätzlich gesichert werden, um nicht für jede Benutzergruppe zugänglich zu sein. Eine n-Schichten oder Mehr-Schichtenarchitektur setzt bei den Schwachstellen der zwei- Schichtenarchitektur an und sieht mit einer Präsentationsschicht, Business-Logik-Schicht und Datenschicht, mindestens drei Schichten vor. Weitere Schichten können beispielsweise hinzugezogen werden, um Ausfallsicherheitsanforderungen zu begegnen oder zur Lastverteilung durch die Verteilung der Clientanfragen an verschiedene Server. 127 Die Schichten arbeiten getrennt voneinander und besitzen eigene Eigenschaften und Methoden. Jede Schicht verfügt über Kommunikationsschnittstellen zu seinen 122 Vgl. Müller, 2005, S. 62. 123 Vgl. Müller, 2005, S. 64. 124 Vgl. Vogel u.a., 2005, S. 212; Müller, 2005, S. 64. 125 Vgl.Strobel, 2004, S. 123-125. 126 Strobel, 2004, S. 123. 127 Vgl. Vogel u.a., 2005, S. 212f. - 35 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 128 Nachbarschichten. Folglich ist es möglich, dass die Schichten auf jeweils unterschiedlichen physikalischen Servern arbeiten. Strobel identifiziert folgende Eigenschaften von n-Schichtenarchitekturen 129: § Die Trennung der Schichten erlaubt den Austausch von Modulen § Es können Entwicklungsgruppen gebildet werden, die sich auf einen Anwendungsbereich spezialisieren § Die Anwendungslogik muss nur einmal implementiert werden Im Vergleich zu zwei-Schichtigen Lösungen haben n-schichtige Architekturen also deutliche Vorteile im E-Commerce Bereich. 130 Die Stärken zeigen sich z.B. durch wiederverwendbare Komponenten, verteilte Ressourcen, standardisierte Schnittstellen und Transaktionsüberwachungen. 2.1.3. Service orientierte Architekturen Eine Service orientierte Architektur (SOA) beschreibt den Aufbau einer Anwendungslandschaft, bestehend aus einzelnen Anwendungsbausteinen, die verbunden 131 sind und einander ihre Services anbieten. In diesem Sinne ist ein Service eine definierte Leistung, die „als Element eines oder mehrerer Verarbeitungsabläufe verwendet werden kann.“ 132 Eine einheitliche und allgemein anerkannte Definition des Begriffe SOA besteht jedoch nicht. 133 Forrester Research definiert SOA als Art und Weise, wie Anwendungen und 134 Software-Infrastruktur gestaltet, bereitgestellt und verwaltet werden. Gemäß dem Unternehmen IBM bestimmt SOA die Art und Weise wie man Software baut und erlaubt eine Software Services für eine andere Software bereitzustellen. Somit wird als Basis der Service als wiederholbarer Arbeitsschritt innerhalb einer Geschäftsprozesses verstanden. 135 Zu den Charakteristiken einer SOA zählen die verteilte Architektur, die lose Kopplung von Services und standardisierte Schnittstellen. Zu den Vorteilen zählen die 128 Vgl. Web-Technologien, C.Strobel, S. 123. 129 Vgl. Web-Technologien, C.Strobel, S. 131. 130 Vgl. Strobel, 2004, S. 135. 131 Vgl. Richter / Haller / Schrey, 2005, S. 413-416. 132 Richter / Haller / Schrey, 2005, S. 413. 133 Vgl. Liebhart, 2007, S. 6. 134 Vgl. Liebhart, 2007, S. 6. 135 Vgl. Liebhart, 2007, S. 6. - 36 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Wiederverwendbarkeit (der Services), die Flexibilität, Kosteneffizienz, Transparenz und hohe Kompatibilität. 136 Der modulare Aufbau verringert im Allgemeinen die Komplexität der IT Struktur. Module zur Erweiterung von E-Shop Software werden in der Literatur auch als Plugins bezeichnet. Da ein Modul theoretisch beliebig oft für eine E-Shop Software verwendet werden kann, lassen sich durch diese Wiederverwendbarkeit Kosten senken. Zudem stellt dies einen zusätzlichen Anreiz für externe Dienstleister dar, Module zu entwickeln. Die Erweiterbarkeit durch Module ist insbesondere für E-Shop Software von sehr großer Wichtigkeit, weil hier z.T. sehr viele externe Anwendungen angebunden werden müssen, wie Kapitel 2.7 detaillierter zeigt. In diesen Fällen kann es von bedeutendem Vorteil sein Module, wie z.B. Content Management Systeme 137 oder der Web Analytic Software 138 einfach anbinden zu können, und nach Möglichkeit von Herstellern Standardmodule bereitgestellt zu bekommen. Bereits die Wiederverwendbarkeit von Standardmodule kann externe Dienstleister motivieren, Softwaremodule zu entwickeln und am Markt anzubieten. Allerdings müssen bei individuellen Projekten neben den eigenen Anforderungen auch die möglichen zukünftigen Anforderungen anderer Bausteine berücksichtigt werden, was eine vorausschauenden Vorgehensweise bedarf. Folglich setzt SOA ein tiefes Verständnis der Geschäftsprozesse voraus. 139 2.1.4. Datenaustausch Um den Datenaustausch im E-Business und damit auch mit der E-Shop Software effizienter und kostensparender zu machen, sind nutzbare Standards notwendig. Der Datenaustausch kann sowohl zwischen Unternehmen, als auch zwischen unterschiedlichen Anwendungen innerhalb eines Unternehmens erfolgen, . Im Allgemeinen bezieht sich der Datenaustausch auf produkt oder kunden-bezogene Daten. Als Beispiele können der Import von Produktdaten von einem ERP Software, der Export von Bestelldaten an eine ERP Software oder der Export von Produktdaten zu Marketingzwecken z.B. für Preisvergleichsportale oder Affiliate-Netzwerke genannt werden. Der Datenaustausch erfolgt dabei stets auf Grundlage definierter Datenformate. 140 Dabei lassen sich Standards im Vergleich zu proprietären Formaten grundsätzlich leichter 136 Hermann Krallermann u.a., 2007, S. 16. 137 Vgl. Kapitel 3.2.3. 138 Vgl. Kapitel 3.2.6. 139 Vgl. Holtkamp, 2009, S. 14. 140 Vgl. Leukel, 2004, S. 67f. - 37 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software gegenüber Partnern durchsetzen, werden von vielen Unternehmen unterstützt und benötigen 141 kein schwer zu akquirierendes Wissen. Des Weiteren sind E-Business Standards 142 konvertierbar. D.h. die Daten eines z.B. XML-basierten Formats, lassen sich mit Hilfe der entsprechenden Transformationsregel stets in ein anderes XML-basiertes Format umwandeln. Zu den bedeutendsten Standards gehören die Datenformate CSV, EDI und XML, die in der Tabelle 5 miteinander verglichen werden. 143 CSV-Formate EDI-Formate XML-Formate Übertragungsgröße Minimal Gering Hoch Formale Spezifikation Nein Nein Ja Multimediadaten Nein Nein Ja Plattformunabhängig Nein Nein Ja 144 Tabelle 5: Vergleich CSV-, EDI- und XML-basierter Datenformate Der Vergleich von XML Dokumenten mit der zugehörigen, formalen Spezifikation stellt die Gültigkeit der Dokumente und damit die Konformität zum definierten Format sicher. Dadurch keine fehlerhafte Daten, z.B. weil sie falsche Datentypen oder nicht definierte Datenelemente beinhalten, verarbeitet. Dies ist beim CSV- und EDI-Format nicht gegeben. 145 Die Aufnahme von Multimediadaten, wie z.B. Abbildungen, ist ebenso nur mit dem XML Format möglich. Für die Kommunikation eines E-Shops mit externen Anwendungen, bedarf es i.d.R. weiterer Technologien. Insbesondere das Netzwerkprotokoll SOAP (Simple Object Access Protocol), mit dessen Hilfe Daten zwischen zwei Systemen ausgetauscht werden können, gilt als ein Industriestandard und wird u.a. von IBM, Hewlett-Packard, Sun Microsystems (Tochterunternehmen von Oracle) 146 und Microsoft unterstützt. 147 Die Unterstützung von SOAP seitens einer E-Shop Software, gehört somit bereits aufgrund der Verbreitung von SOAP zu den Grundvoraussetzungen für einen Datenaustausch mit unterschiedlichen Anwendungen. 148 141 Vgl. Quantz / Wichmann, 2003, S. 10. 142 Vgl. Kollmann, 2007, S. 67. 143 Vgl. Leukel, 2004, S. 78. 144 Vgl. Leukel, 2004, S. 78. 145 Vgl. Leukel 2004, S. 77. 146 Vgl. Oracle, 04.01.2010. 147 Vgl. Blakey, 05.01.2010; Amor, Daniel, 2004, S. 358-360. 148 Vgl. Hawk / Zheng, 2008, S. 2208-2211; Papazoglou, 2008, S. 120. - 38 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Weitere Technologien, die für eine Datenübertragung relevant sein können und auf die sich SOAP z.T. stützt, sind u.a. Web Service Description Language (WSDL), Hypertext Transfer Protocol (HTTP), HyperText Transfer Protocol Secure (HTTPS), 149 und Universal Description, Discovery and Integration (UDDI), auf die hier nur verwiesen werden soll. 150 Zusätzliche Funktionen, die eine Verwaltung- und Automatisierung des Datenaustausches über eine Benutzeroberfläche erlauben, können helfen, den Datenaustausch zu vereinfachen und transparenter zu gestalten. Alternativ können Export- und Import-Abläufe beispielsweise durch i.d.R. eigenentwickelte Skripte realisiert werden, sofern die Rahmenbedingungen es erlauben. Bei diesem Beispiel könnte der Datenaustausch durch die Einstellung von sog. Cron Jobs, einer Software zur Ausführung von Kommandos zu einer festgesetzten Zeit oder in festgelegten Abständen, automatisiert werden. 151 2.1.5. Ladezeit Aufgrund der enormen Informationsflut im Internet, hat der Nutzer das Bedürfnis, in wenigen Schritten zur gewünschten Information zu gelangen. Folglich stellt die Ladezeit eines E- Shops einen wichtigen Erfolgsfaktor dar. 152 Tests bei der Firma Amazon haben gezeigt, dass eine Erhöhung der Ladezeit von amazon.com um 100ms zu einem Umsatzrückgang von einem Prozent führt. 153 Google stellte fest, dass die Umstellung von der Anzeige von zehn Suchergebnissen je Seite bei einer Ladezeit von 0,4s hin zur Anzeige von 30 Suchergebnissen je Seite bei einer Ladezeit von 0,9s, zu einem Rückgang der Besucherzahlen und einem Umsatzrückgang von 20% führen kann. 154 Eine Studie in den USA kommt zu dem Schluss, dass eine Ladezeit von länger als drei Sekunden für 40 Prozent aller Befragten nicht akzeptabel sei. 155 Dauert der Aufbau länger, verlassen die Nutzer den Shop und suchen einen anderen Online-Händler. Allerdings hängt die Ladezeit von zahlreichen unterschiedlichen Faktoren ab, worauf die Betrachtung von Laudon und Traver oder Stair und Reynolds in Kapitel 2.5 schließen 149 Vgl. Kapitel 3.3.4. 150 Für weitere Informationen sei auf folgende Literatur verwiesen: Lee u.a., 2003, S. 186-1992; Hawk / Zheng, 2008, S. 2208f; Papazoglou, 2008, S. 120-122. 151 Vgl. Lexitron, 05.01.2010. 152 Vgl. BITKOM, 2009, S. 26f; Müller, 2004, S. 97-101; Groß, 04.01.2010. 153 Vgl. Kohavi / Longbotham, 2007, S. 103‐105. 154 Vgl. Mayer, 19.12.2010. 155 Vgl. Forrester Research, 2009a, S. 7f. - 39 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software § 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 Vgl. ibi research an der Universität Regensburg GmbH, 2009, S. 109-127. - 41 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Kollmann, 2007, S. 71. - 43 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Schneider, 2004, S. 361. 174 Vgl. Kollmann, 2007, S. 170. 175 Vgl. Kollman, 2007, S. 170. 176 Vgl. Leukel, 2004, S. 12. - 44 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Kollmann, 2007, S. 71. - 45 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Kollmann, 2007, S. 171. 184 Vgl. Kollmann, 2007, S. 171. - 46 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Kollmann, 2007, S. 171. 186 Vgl. Hass / Walsh / Kilian, 2008, S. 294-298. - 47 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Schneider, 2004, S. 365. 189 Vgl. Schneider, 2004, S. 365. 190 Vgl. Verch, 06.01.2010. - 48 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Kollmann, 2007, S. 175. 193 Vgl. Dolson, 06.01.2010. 194 Vgl. Lenz / Moeller, 2004, S. 108. - 49 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. ibi research an der Universität Regensburg GmbH, 2009, S. 2. 197 Vgl. ibi research an der Universität Regensburg GmbH, 2009, S. 166. 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. ibi research an der Universität Regensburg GmbH, 2009, S. 120-124. 204 Vgl. Schneider, 2004, S. 387. 205 Vgl. Stair / Baldauf, 2009, S. 453. - 51 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Schneider, 2004, S. 387. 207 Vgl. Kapitel 2.8. 208 Vgl. Krisch, 13.01.2010. - 52 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Kollmann, 2007, S. 200. 229 Vgl. Schwarze / Schwarze, 2002, S. 119. 230 Vgl. Kollmann, 2007, S. 201. - 57 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Schneider, 2004, S. 419. 243 Schneider, 204, S. 419. 244 Swoboda / Spitz / Pramateftakis, 2008, S. 2. - 61 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Schneider, 2004, S. 419. 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Haenni, 2006, S. 155f. 254 Vgl. Haenni, 2006, S. 155f. 255 Vgl. Haenni, 2006, S. 155f. 256 Vgl. Witt, 2007, S. 147 - 63 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software § 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Windley, 2001, S. 5-8. 272 Vgl. Windley, 2001, S. 5-8. - 68 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Zielkriterium Gewichtung KA1 GA1 Gewichtung Zielkriterien- der Zielkriterium Gewichtung Kategorie Zielkriterien- KA2 GA2 ZKA Kategorie . . . . . . ZKGA Zielkriterium Gewichtung KAn GAn Zielkriterium Gewichtung KB1 GB1 Gewichtung Zielkriterien- der Zielkriterium Gewichtung Gesamt Kategorie Zielkriterien- KB2 GB2 Nutzwert ZKB Kategorie . . ZKGB . . . . . . . . Zielkriterium . Gewichtung . KBn GBn . . . . . . . . . . . . . . . . . . Gewichtung Zielkriterien- der Zielkriterium Gewichtung Kategorie Zielkriterien- 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 ) Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Σ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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Zielkriterien der Hilfskriterien Zielkriterien-Kategorie 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 Zielkriterien der Hilfskriterien Zielkriterien-Kategorie 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Zielkriterien der Hilfskriterien Zielkriterien-Kategorie 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 Zielkriterien der Hilfskriterien Zielkriterien-Kategorie 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Zielkriterien-Kategorie 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Laudon / Traver, 2009, S.4,11. - 87 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Laudon / Traver, 2009, S.4,17. 329 Vgl. Kapitel 2.9. 330 Vgl. Bullinger, Hans-Jörg u.a., 1998, S.14. - 88 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Mindestanforderungen an den Server: xt:Commerce OXID CE Magento 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 xt:Commerce OXID CE Magento 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Zielkriterium Kommentar Wertung 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 § persistenter Warenkorb 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Zielkriterium Kommentar Wertung 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 Zielkriterium Kommentar Wertung 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 4.3.1.1. Architektur Zielkriterium Kommentar Wertung 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 Zielkriterium Kommentar Wertung 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, die zu manuellen Cross-Selling Zwecken genutzt werden können. Suchfunktion § Schließt Attribute, Meta-Tags, 2,5 Produktbeschreibungen sowie über das Content 343 Vgl. OXID eSales AG, 21.01.2010a; OXID eSales AG, 21.01.2010b. 344 Vgl. OXID eSales AG, 22.01.2010c. - 99 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Management erstellte Seiten mit ein § 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 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 § grundlegender Informationen werden dargestellt 2 § persistenter Warenkorb Bestellformular § Erfassung der Kundendaten und Bestätigung der 2 Bestellung bei gleichzeitiger Speicherung der IP- 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software § Metadaten können über eine Benutzeroberfläche 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 § Über das Front-End hat der Endkunde die Möglichkeit, seine Kundendaten einzusehen und zu ändern, die Bestellhistorie sowie den aktuellen 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software schon im Standard vorintegriert 345 Tabelle 30: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE 4.3.1.3. Sicherheit Zielkriterium Kommentar Wertung Administratorenrec § Es können beliebig viele Nutzer Administratoren 0 hte und - sein; eine Einschränkung der Rechte ist jedoch überwachung nicht möglich 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. 4.3.1.4. Strategie Zielkriterium Kommentar Wertung 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Varien Inc., 24.02.2010a. - 103 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 4.4.1. Evaluierung 4.4.1.1. Architektur Zielkriterium Kommentar Wertung 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 Zielkriterium Kommentar Wertung Produktkatalog § Magento Commerce verfügt über ein dynamisches 2 konstruierendes Produktkatalog, das von sich aus bereits zahlreiche Attribute voreingestellt hat, attributseitig beliebig erweitert werden kann und 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 Produktbeschreibungen sowie über das Content Management erstellte Seiten mit ein § Endkunde und Admin können Schlagworte eingeben, die ebenfalls gesucht werden können. § Einstellbar, ob Produkt in Suchergebnis erscheinen - 104 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software darf § 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 § Darstellung grundlegender Informationen 2,5 § Cross-Selling möglich § persistenter Warenkorb Bestellformular § Erfassung der Kundendaten und Bestätigung der 3 Bestellung bei gleichzeitiger Speicherung der IP- 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software block_id=" Ident_der_CMS_Seite "}}) aufgerufen werden. § Metadaten können über eine Benutzeroberfläche 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 § Über das Front-End hat der Endkunde die Möglichkeit, seine Kundendaten einzusehen und zu ändern, die Bestellhistorie sowie den aktuellen Bestellstatus abzurufen, sein im E-Shop abgegebenen Produktbewertungen und Kommentare einzusehen und eine sog. Wunschliste - 106 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Zielkriterium Kommentar Wertung 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. Sicherheitsmechan § Es wird ein hash code genutzt, der bei der 3 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 Zielkriterium Kommentar Wertung 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 Vgl. Varien Inc., 04.02.2010a. 355 Vgl. Varien Inc., 24.02.2010b. 356 Vgl. Varien Inc., 24.02.2010b. - 108 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software ZKm ZKGm xt:Commerce OXID CE Magento (Variante a) (Variante b) (Variante c) [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 (Variante a) (Variante b) (Variante c) [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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software Anhang Anhang 1: Gartner TCO Modell - 114 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software 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.xtcommerce.com/forum/ am 24.02.2010. - 127 -

http://www.kassenzone.de	377
http://www.wiro-consultants.de	4
http://static.slidesharecdn.com	2
http://webcache.googleusercontent.com	1
http://www.health.medicbd.com	1

Evaluierungsmodell

by oneduphine on Apr 21, 2010

Accessibility

Tags

Upload Details

Usage Rights

5 Embeds 385

Statistics

Evaluierungsmodell — Document Transcript