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




Inhaltsverzeichnis


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


       2.2.3.      Content Management ...........
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


     4.3.      OXID CE ..........................
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Anhangsverzeichnis



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


Abbildungsverzeichnis


Abbildung 1: E-Busines...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Tabellenverzeichnis



Tabelle 1: Geschäftsmod...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Abkürzungsverzeichnis



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




1. Grundlagen von E-Shop Software
In diesem ...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


demnach ein Teilbereich von E-Business und bes...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


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




     1.3.       Geschäftsmodelle im E-Busine...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


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


how ein und agieren innerhalb des Netzwerkes s...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


     §   Große Verhandlungsmacht: Dem Aggregat...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Im Zuge der zunehmenden Verbreitung des Intern...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Grundsätzlich      werden      in     Deutschl...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


auch als Vertriebskanal mit der höchsten Wachs...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


und E-Marketplace eine Unterscheidung von vier...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


andersherum die umfangreichen E-Community Funk...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Shop Software, zu einer vier schichtigen pyram...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Funktionen können u.a. ein Kontaktformular ode...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


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


Benutzeroberfläche er interagiert. Das Back-En...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


more people use them. This is what I've elsewh...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


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


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


     1.9.       Betreibermodelle
Die Nutzung u...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software

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


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


nutzt nur bis zu einem bestimmten Grad externe...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Abbildung 10 zeigt sehr idealistisch und allge...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software



Die in Kapitel 2 aufgeführten Definitionen un...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


      2.1.          Architektur
E-Commerce Lös...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software




       Fu




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


Schichtenmodell, dürfen die Schichten nur mit ...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software

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


Wiederverwendbarkeit (der Services), die Flexi...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


gegenüber Partnern durchsetzen, werden von vie...
Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software


Weitere Technologien, die für eine Datenübertr...
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Evaluierungsmodell
Upcoming SlideShare
Loading in...5
×

Evaluierungsmodell

5,916

Published on

0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,916
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Evaluierungsmodell

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

×