Universität Leipzig, Institut für Informatik, Abteilung Datenbanken

Problemseminar WS 99/00

 

 

 

E-Commerce

 

Vortrag 1: Einführung

 

 

 

 

 

Bearbeiter:

Betreuer:

Leiter:

Frank Herklotz

Dipl. Inf. Stöhr

Prof. Dr. Rahm

 

 

Wichtiger Hinweis:

Zur idealen Betrachtung des folgenden Textes stellen Sie bitte die Breite Ihres Browsers so ein, daß das Inhaltsverzeichnis korrekt angezeigt wird.

 


Inhaltsverzeichnis

 

1. Einleitung................................................................................................................................................................. 3

1.1. Definition E-Commerce............................................................................................................................................ 3

1.2. Allgemeine Ziele....................................................................................................................................................... 3

1.3. Voraussetzungen...................................................................................................................................................... 3

1.4. Klassifikation aus Unternehmenssicht................................................................................................................. 4

1.5. Geschichtlicher Abriß.............................................................................................................................................. 5

2. Elektronischer Datenaustausch............................................................................................................. 7

2.1. Der Standard Electronic Data Interchange........................................................................................................... 7

2.2. Ein praktischer Ansatz für Web-basiertes EDI.................................................................................................... 8

3. Bereiche des E-Commerce....................................................................................................................... 9

3.1. Elektronische Kataloge............................................................................................................................................ 9

3.2. Finanzgeschäfte........................................................................................................................................................ 9

3.2.1. Elektronische Zahlungsmittel........................................................................................................................ 9

3.2.2. Smart Cards...................................................................................................................................................... 9

3.2.3. Ein Web-basiertes System für Finanztransaktionen................................................................................ 10

3.3. Workflow-Management........................................................................................................................................ 12

3.4. Brokering................................................................................................................................................................. 13

3.5. Auktionen................................................................................................................................................................ 13

3.6. Software-Agenten.................................................................................................................................................. 14

4. Standardisierungsbemühungen............................................................................................................ 16

4.1. Open Buying on the Internet (OBI)..................................................................................................................... 16

4.2. Open Service Model (OSM)................................................................................................................................. 17

5. Rahmenbedingungen................................................................................................................................... 19

5.1. Sicherheit................................................................................................................................................................. 19

5.1.1. Sicherheit in Rechnernetzen........................................................................................................................ 19

5.1.2. Kryptographie................................................................................................................................................ 19

5.2. Gesetze..................................................................................................................................................................... 20

5.2.1. Globale Problematik....................................................................................................................................... 20

5.2.2. Verbrauchersituation in Deutschland........................................................................................................ 20

6. Ausblick................................................................................................................................................................. 21

6.1. Zukünftige Online-Shops...................................................................................................................................... 21

6.2. Mobile Commerce................................................................................................................................................... 21

7. Literatur.................................................................................................................................................................. 23

 

 

1.       Einleitung

 

In diesem Kapitel wird der Begriff E-Commerce definiert. Weiterhin erfolgt eine Darstellung allgemeiner Ziele beim Einsatz von E-Commerce-Anwendungen und eine Übersicht über die notwendigen Voraussetzungen, um einen Einsatz überhaupt zu ermöglichen. Nach der Vorstellung einer Unternehmenssichtweise wird abschließend ein kurzer Überblick über die geschichtliche Entwicklung gegeben.

1.1.  Definition E-Commerce

Die Definition nach [KÖ98] faßt E-Commerce als Abwicklung von Geschäftsprozessen jeglicher Art über öffentliche oder private Kommunikationsnetze auf. In [HS99] wird allerdings erklärt, daß äsich bisher keine eindeutige und allgemein akzeptierte Definition von E-Commerce herausgebildetô hat. Keinesfalls sei eine Reduzierung auf Online-Shopping ausreichend, da man ädas gesamte Potential der elektronischen Geschäftsabwicklung zwischen Unternehmen, Kunden und öffentlichen Institutionen berücksichtigen muß, will man die umbruchartigen Veränderungen verstehen, denen Wirtschaft und Gesellschaft weltweit ausgesetzt sindô.

In der Regel betrachtet man verschiedene Klassen des E-Commerce. Eine häufig verwendete Klassifikation nach [GO99] zeigt die folgende Übersicht:

Business-to-Business

Geschäftsverkehr zwischen Unternehmen

Business-to-Consumer

Verkauf von Waren, Dienstleistungen von Firmen an Kunden

Consumer-to-Consumer

Handel zwischen Konsumenten

Es gibt jedoch auch viele andere Einteilungen. Ein Beispiel dafür ist die separate Betrachtung des Administration-Sektors in [EC99]. Weiterhin sei auf das Unterkapitel 1.4. verwiesen, in dem die Sichtweise eines Unternehmens dargestellt wird.

1.2.  Allgemeine Ziele

In [AD98] werden allgemeine Ziele des Einsatzes von E-Commerce-Anwendungen aufgeführt. Wie jede Neuerung in einem marktwirtschaftlichen Umfeld muß auch E-Commerce Geschäftsprozesse effizienter gestalten, um Akzeptanz zu erreichen. Aus der Sicht eines Produzenten bedeutet dies die Reduzierung von Produkt- und Servicekosten, während sich Konsumenten kürzere Antwortzeiten und bessere Qualität versprechen. Damit einher geht eine Verbesserung der Wettbewerbsfähigkeit von Unternehmen, besonders auf hart umkämpften Märkten.

Auf der anderen Seite setzen auch staatliche Einrichtungen Hoffnungen in die E-Commerce-Entwicklung. Neben vor allem politisch motivierten Erwartungen bezüglich der Entstehung neuer Jobs und einem höheren Wirtschaftswachstum sind Verwaltungsbehörden prädestiniert für den Einsatz elektronischer Datenverarbeitung. Mit einer Erweiterung bisheriger Systeme um E-Commerce-Technologien ließen sich nochmals enorme Kosten durch die mögliche Reduzierung der Anzahl staatlicher Angestellter erreichen.

1.3.  Voraussetzungen

Ebenfalls in [AD98] finden sich wichtige Anforderungen an die bereitzustellenden Dienste. Zunächst müssen Informationen digitalisiert werden. Hierbei handelt es sich zum Beispiel um Kataloge, Bücher, Karten, Filme und Audiodaten, welche unter Berücksichtigung der technischen Möglichkeiten und der anfallenden Kosten auf einem ausreichenden Qualitätslevel elektronisch bereitzustellen sind. Dazu ist sowohl die Unterstützung verschiedener Datenformate wie auch ein effektiver Zugriff auf diese Daten notwendig. Um das Auffinden selektierter Daten für einen Nutzer zu ermöglichen, sind elektronische Kataloge, Filtermechanismen, Suchmaschinen und Softwareagenten unabdingbar. Ist die gewünschte Ware lokalisiert, muß der Zahlungsverkehr geregelt werden. Aktuell realisierte Formen nutzen Smart Cards, Kreditkarten, elektronische Schecks oder Cybergeld. Spätestens zu diesem Zeitpunkt fordert jeder Nutzer gewisse Sicherheiten, um vor materiellen Verlusten geschützt zu sein. All diese Aktionen benötigen auch reale Verbindungen zwischen zwei Parteien, also ein zugrundeliegendes Kommunikationsnetzwerk. Durch die bestehende Hardware-Vielfalt stellt Interoperabilität in diesem Zusammenhang ein wichtiges Schlagwort dar.

Schließlich müssen alle Geschäfte auf einem fundierten politischen und gesetzlichen Rahmen aufsetzen. Hierbei ist die praktische Nichtexistenz von Ländergrenzen ein besonderes Problem.

Nachfolgend wird eine Übersicht verschiedener Aspekte, die im Zusammenhang mit E-Commerce stehen und damit einzelne Voraussetzungen bedingen, angegeben.

Technik

Wirtschaft

Gesetz

-         Netzwerke, Telekommunikation

-         Sicherheit

-         Laden / Speichern / Suchen von Multimedia-Daten

-         Marketing

-         Ressourcenbeschaffung

-         Verkauf

-         Buchhaltung

-         Bezahlung

-         Lieferung / Vertrieb

-         Datenschutz

-         geistiges Eigentum

-         Besteuerung

-         Verträge

Selbstverständlich existieren vielfältige Wechselwirkungen zwischen einzelnen Aspekten, so ist z.B. ein effektiver Datenschutz ohne eine entsprechende Sicherheitsarchitekur unmöglich.

1.4.  Klassifikation aus Unternehmenssicht

Ein Ansatz zur Beschreibung von E-Commerce aus der Sicht eines Unternehmens findet sich in [RR98]. Unter Einschränkung auf die Bereiche Business-to-Business, Customer-to-Business und Intraorganizational, den Geschäftsverkehr innerhalb eines Unternehmens, betrachtet man zwei Dimensionen. Die erste Dimension definiert den Standpunkt eines Nutzers einer Anwendung bezüglich des Unternehmensnetzwerkes. Entweder handelt es sich um einen externen Zugriff, z.B. um einen Kunden eines Online-Shops, oder um einen internen Zugriff, speziell um den Informationsfluß innerhalb eines Unternehmens. Auf der anderen Seite betrachtet man die Beziehung zum Nutzer der Anwendung. So können bestehende feste Beziehungen unterstützt und verbessert werden, beispielsweise durch die Einführung von elektronischem Datenaustausch zur engeren Integration von Handelspartnern. Andererseits werden auch neue oder lose gebundene Nutzer angesprochen. Die Kombination beider Dimensionen ergibt die in Abb. 1.1 dargestellte Matrix.

 

 

 

 

 


Abb. 1.1:

Electronic Commerce

Domain Matrix [RR98]

 

 

 

 

 

 

 

 

Viele der ersten kommerziellen Internet-Anwendungen waren zur Neukundengewinnung durch die Präsentation eines Unternehmens auf einer Web-Seite gedacht. Diese Customer-to-Business-Anwendungen befinden sich folglich in Zelle 4. Zur effizienteren firmeninternen Kommunikation werden mit steigender Anzahl Rechnernetze, sogenannte Intranets, eingesetzt. Auch wenn es sich dabei speziell bei kleineren Firmen häufig nur um eine Menge zugriffsbeschränkter Internet-Seiten handelt, werden Intranets in Zelle 1 eingeordnet.

Neuere Ansätze erweitern Intranets um Verbindungen zwischen Unternehmen und deren Zulieferern, Kunden und Handelspartnern. Diese sogenannten Extranets (Extended Intranets) können nun nochmals unterschieden werden. Handelt es sich um Teile proprietärer Systeme, auf die bewährte Handelspartner kontrollierten Zugriff erhalten, so spricht man von Intronets, welche hauptsächlich in Zelle 3 angesiedelt sind. Eine mögliche Realisierung besteht in einer Zugriffserlaubnis für einen externen Handelspartner auf Teile einer Unternehmensdatenbank, um diesen mit Up-to-Date-Informationen zu versorgen. Supranets hingegen sind neue Verbindungsnetze zur verbesserten Kommunikation mit engen Partnern, etwa neuen Team-Mitgliedern, und werden Zelle 4 zugeordnet. Damit können z.B. verschiedene mit einem neuen Produkt-Design beschäftigte Gruppen kosten- und zeiteffizienter arbeiten. Abb. 1.2 verdeutlicht, daß Extranets somit die bisherige Lücke zwischen Intranets und dem Internet schließen.

 

 

 

 

 


Abb. 1.2:

A unified view of

e-commerce [RR98]

 

 

 

 

 

 

 

 

1.5.  Geschichtlicher Abriß

Die Geschichte des E-Commerce begann vor mehr als 20 Jahren mit dem Einsatz neuer Techniken der Datenverarbeitung und ûübertragung speziell im Bankwesen. Zu den wichtigsten Neuerungen gehörten Electronic Data Interchange (EDI) und Electronic Funds Transfer (EFT). In den 80er Jahren erweiterte sich der Nutzerkreis um kleinere Unternehmen und Privatpersonen durch den Einsatz von Kreditkarten, Kassierautomaten und die Einführung von Telefon-Banking. Ein wichtiger Dienst in Deutschland stellte und stellt heute noch der von der Deutschen Telekom angebotene Bildschirmtext (BTX) dar, welcher sich vor allem als Informationsdienst etabliert hat. Da es sich um ein geschlossenes Netz handelt und die Bezahlung über die Telefonrechnung erfolgt, gibt es kaum Sicherheitsprobleme. Die stärkste Entwicklung vollzog sich freilich in diesem Jahrzehnt aufgrund der stark ansteigenden Nutzung von Internets, wobei das WWW hier sicher eine tragende Rolle spielt.

Trotz radikaler Effekte innerhalb bestimmter Märkte ist dennoch kein allgegenwärtiger Durchbruch festzustellen. So scheuen z.B. viele Small- and Medium-sized Enterprises (SMEs) den hohen Initialaufwand und die entstehenden Wartungskosten beim Einsatz von EDI. Somit bleibt die Nutzung von EDI weiter auf Großunternehmen beschränkt. Außerdem verfügt bisher nur ein geringer Teil der Privatpersonen über einen Internet-Zugang, laut einer Studie der Europäischen Kommission und des Verbandes der deutschen Internet-Wirtschaft (ECO) lag die Internet-Verbreitung in europäischen Haushalten Ende 1998 bei 8,3 Prozent. Allerdings entspricht das einer Verdopplung gegenüber Ende 1997 und verdeutlicht damit die Wachstumsaussichten auf diesem Sektor. Diese und weitere Ergebnisse der Studie finden sich in [EC99].

Momentan wird ein Großteil der Waren und Dienstleistungen im Business-to-Business umgeschlagen. So rechnet die OECD für die nächsten 4 Jahre mit einem Umsatzanteil der Business-to-Business-Transaktionen von 80% europaweit. Business-to-Consumer-Geschäfte, und damit insbesondere Online-Shopping, nehmen also vorläufig nur einen geringen Stellenwert im E-Commerce bezogen auf ihre Umsätze ein. Der Bereich Consumer-to-Consumer kann in dieser Hinsicht vorerst vernachlässigt werden.

Prognosen für die zukünftige Entwicklung gibt es zwar viele, sie unterscheiden sich aber zum Teil erheblich in den absoluten Zahlenwerten. So sagt Frost & Sullivan für 2001 einen Umsatz von ca. 2,5 Mrd. DM im E-Commerce europaweit voraus, während Forrester Research 64,4 Mrd. Dollar erwartet. Allerdings stimmen alle Prognosen darin überein, daß E-Commerce eine große Zukunft bevorsteht. Zur Verdeutlichung dienen Abb. 1.3 und 1.4. Ausführliche statistische Untersuchungen, darunter auch eben genannten, werden in [GO99] vorgestellt.

 

 

 

 


Abb. 1.3:

Umsatzentwicklung

im E-Commerce

(Quelle: Frost & Sullivan)

 

 

 

 

 

 


Abb. 1.4:

Wachstumsraten

im E-Commerce

(Quelle: Frost & Sullivan)

 

 

 


 

2.       Elektronischer Datenaustausch

 

Nachfolgend wird der elektronische Datenaustausch anhand des seit mehr als zwei Jahrzehnten standardisierten EDI-Formats erläutert und ein Forschungsbeispiel kurz vorgestellt.

2.1.  Der Standard Electronic Data Interchange

Laut [AD98] ist EDI ein standardisiertes Austauschformat für strukturierte Informationen zwischen den Datenverarbeitungseinheiten zweier Handelspartner in maschineller Form. Strukturell handelt es sich um eine Hierarchie ineinandergeschachtelter Komponenten. Hier eine grobe Übersicht dieser Komponenten:

Data Element

individuelle Informationseinheit

Data Segment

eine Zeile mit mehreren Data Elements

Transaction Set

spezifisches Dokument bestehend aus mehreren Data Segments

Functional Group

Gruppe ähnlicher Transaction Sets

Die Standardisierung erfolgt seit 1979 in den USA durch ANSI ASC X12. Im Jahr 1998 enthielt dieser Standard mehr als 90 Transaction Sets. Seit 1985 existiert mit EDIFACT ein weiteres von der UN initiiertes Standardisierungskomitee.

Folgende Arbeitsschritte sind zum Durchführen einer EDI-Transaktion nötig:

Mapping

Abbildung: Datenbankschema => EDI-Komponenten

Extraction

Extraktion von Daten aus einer DB, Speicherung i.a. in einer flachen Datei (Struktur abhängig von verwendeter EDI-Software)

Translation

Generierung eines EDI-Dokuments durch EDI-Software

Communication

softwareunterstützte Übermittlung einer Nachricht

Der Einsatz von EDI hat mehrere wichtige Vorteile. Zum einen müssen Daten nur noch einmalig eingegeben werden, wodurch die Fehleranfälligkeit besonders im Hinblick auf Inkonsistenz verringert wird und Personalkosten gespart werden. Weiterhin ist die Datenübermittlung papierlos und schnell. Somit können Geschäftsprozesse rationalisiert werden, indem beispielsweise Just-In-Time-Lieferung (JIT) eingeführt wird.

Nachteilig wirkt sich vor allem die Inflexibilität des Standards aus. Es lassen sich keine eigenen Dokumente definieren, d. h. man ist zwingend an die Verwendung vorgefertigter Transaction Sets gebunden. Besonders für SMEs sind die Kosten für die Anschaffung und Wartung der EDI-Software sowie die Mitarbeiterschulung zu hoch. Schließlich können auch die Kosten für die Datenübertragung nicht vernachlässigt werden. Momentan sind sogenannte Value Added Networks (VANs) recht populär. Diese Rechnernetze werden meist von Dritten verwaltet und bieten neben der verläßlichen Datenübertragung weitere Dienste wie z.B. die Umwandlung von EDI-Dokumenten in einen anderen Standard an. Neben einem monatlichen Grundpreis entstehen zusätzliche Kosten für jede Transaktion sowie jeden value-added Service.

Um die bestehenden Inflexibilitäten zu beseitigen, beschäftigen sich nach [GO99] und [FC99] neuere Modelle mit dem Einsatz der Extensible Markup Language (XML) zur Gestaltung von EDI-Dokumenten. Durch die Trennung von Daten und Präsentation kann sowohl ein individueller Dokument-Stil erreicht werden als auch eine leichte Konvertierung in einen anderen Stil oder ein anderes Format erfolgen. Als potentielles Problem stellt sich allerdings die Möglichkeit der Definition eigener Sprachelemente in XML dar, da dies zu Inkompatiblitäten führen könnte.

Als Übertragungsmedium für EDI-Dokumente läßt sich natürlich auch das Internet verwenden. Durch die Benutzung spezieller Multipurpose Internet Mail Extensions (MIME-Typen) können Dokumente verschlüsselt transportiert werden. Neben den geringen Kommunikationskosten ergeben sich als weitere Vorteile globale Erreichbarkeit und Plattformunabhängigkeit. Problematisch ist jedoch der fehlende Quality of Service (QoS). So kann weder eine bestimmte Bandbreite noch eine bestimmte Weglänge für ein Datenpaket garantiert werden, was gerade bei zeitkritischen hochvolumigen Datenübertragungen nicht akzeptabel ist.

2.2.  Ein praktischer Ansatz für Web-basiertes EDI

Der dritte genannte Nachteil, die Anschaffungskosten für EDI-Software, läßt sich nicht prinzipiell abschaffen. In [FC99] befindet sich ein Vorschlag aus dem IBM IAC (Institute of Advanced Commerce), der dieses Problem zumindest für SMEs, die mit Großunternehmen zusammen arbeiten, löst. Prädestiniertes Einsatzgebiet ist somit die Zulieferindustrie. Es wird davon ausgegangen, daß ein Großunternehmen EDI intern und zum Datenaustausch mit anderen (großen) Handelspartnern einsetzt, dies aber auf Zulieferer kleiner und mittlerer Größe ausweiten will. Abb. 2.1 zeigt die vorgeschlagene Architektur.

 

 

 

 

 

 

 


Abb. 2.1:

System Architecture [FC99]

 

 

 

 

 

 

 

 

 

Im Backend-System des Hubs werden Bestellungen generiert, die der Supplier erfüllen muß. Im Translator werden diese Dokumente ins EDI-Format konvertiert und mit Hilfe eines verläßlichen Transportnetzes in einer Mailbox oder einem Repository gespeichert. Ist der Supplier nicht auf dem Web-Server eingeloggt, informiert ihn das Repository. Schließlich wird das EDI-Dokument mittels eines Java-Applets im Browser angezeigt. Erteilt der Supplier eine entsprechende Zugriffserlaubnis, so kann das Applet die Daten ins Backend System des Suppliers transferieren. Weitergehend kann das Applet noch ein Antwortformular beinhalten, indem z.B. die Auftragsbestätigung und Rechnung durch den Kunden eingegeben werden. Diese Daten können vom Applet dann über den Web-Server im Repository abgelegt werden. Von da aus gelangen sie ins Backend-System des Hubs und werden in die bestehenden Geschäftsabläufe integriert. Als Erweiterung wird dem Supplier ein Adapter vorgeschlagen, um die Formatkonvertierung für den automatischen Import der ankommenden Dokumente in sein Backend-System vorzunehmen.

Somit entstehen für den Supplier wesentliche Kosten höchstens für den Adapter. Da der Hub bereits EDI-Software benutzt, dürften die Kosten für das benötigte Applet akzeptabel ausfallen. Weiterhin werden bestehende EDI-Systeme nicht beeinträchtigt und die Beziehung zum Supplier durch die EDI-Vorteile effektiviert.


 

3.       Bereiche des E-Commerce

 

Dieses Kapitel beschäftigt sich mit ausgewählten Bereichen des E-Commerce. Hierzu gehören elektronische Kataloge, elektronische Zahlungsmittel, Workflow-Management, Brokering, Auktionen und Software-Agenten. Da diese Themen z.T. in anderen Vorträgen detaillierter behandelt werden, erfolgt jeweils nur eine kurze Einführung. Ein Forschungsbeispiel aus dem Bereich der Börsengeschäfte wird ausführlicher vorgestellt.

3.1.  Elektronische Kataloge

Wohlbekannt sind Kataloge in gedruckter Form. Elektronische Kataloge können als evolutionäre Weiterentwicklung der Papierform aufgefaßt werden. Sie beinhalten das gleiche Konzept, verändern und verbessern aber die Funktionalität. Dies geschieht z.B. durch einen höheren Informationsgehalt und eine einfachere Produktlokalisation. Als wesentliche Unterschiede zu geduckten Katalogen sind in [AD98] folgende Punkte aufgeführt:

-         Interaktivität, z.B. Echtzeitkommunikation zwischen Firmen und Kunden

-         dynamisches Update, z.B. Preisanpassung

-         Hypertextfähigkeit, z.B. Verweis auf ähnliche Ressourcen

-         globale Präsenz => Chance für SMEs

Ein EDI-basierter Katalog wird durch das ANSI X12 Transaction Set Nummer 832 definiert. Da aber die Inflexibilität des Standards zu enge Grenzen setzt und dieser auch lediglich obigen ersten Punkt unterstützt, fehlen praktische Implementierungen.

Weitere Möglichkeiten ergeben sich durch die Zusammenfassung mehrerer thematisch verschiedener Kataloge zu sogenannten Malls. Diese Variante ist aus wirtschaftlicher Sicht natürlich sehr interessant, da Kunden dann ein vielfältiges Produktangebot begutachten können ohne einen begrenzten Bereich im WWW zu verlassen.

3.2.  Finanzgeschäfte

3.2.1.     Elektronische Zahlungsmittel

Charakteristisch für elektronisches Geld sind laut [KÖ98] die Wertschöpfung aus der Funktion, nicht dem Materialwert, und das Bestehen aus rein digitaler Information, d.h. die dingliche Unfaßbarkeit. Ersteres ist auch bei herkömmlichem Geld wohlbekannt, letzteres jedoch nicht.

Grundsätzliche Anforderungen an elektronisches Geld finden sich in [AD98] und [KÖ98]:

-         Persistenz

-         Fälschungssicherheit (evtl. nachlässigere Behandlung von Kleinstbeträgen)

-         Akzeptanz (großes Akzeptanzstellennetz unter Einschluß staatlicher Institutionen)

-         Transferierbarkeit in unterschiedlicher Stückelung

-         Entstehung geringer Zusatzkosten

-         Käuferanonymität

Etablierte Formen sind Kreditkarten und Geldkarten (Stored Value Cards). Eine Erweiterung dieser beiden Konzepte stellen Smart Cards dar, welche unten erläutert werden. Im Bereich der Micropayments, d.h. Beträgen zwischen 50 Pfennig und 20 DM, existieren auch Implementierungen des Electronic Cash.

3.2.2.     Smart Cards

Neben Geldwerten ermöglichen Smart Cards auch die Speicherung vielfältiger weiterer Informationen wie Personendaten oder Zutrittsberechtigungen. Sicherheitsmechanismen sorgen dafür, daß jedes Lesegerät nur auf die benötigten Informationen zugreifen kann.

Nach [CW98] sieht eine Smart Card fast wie eine gewöhnliche Plastikkarte aus, enthält aber einen Mikroprozessor. Der Aufbau einer solchen Karte wird in Abb. 3.1 verdeutlicht.

 

 

 


Abb. 3.1:

Aufbau einer Smart Card [CW98]

 

 

 

 

Damit eröffnet sich ein breites Anwendungsgebiet. Smart Cards dienen z.B. zur Bezahlung und zur Identifikation oder als Informationsträger im Gesundheitswesen, siehe auch Abb. 3.2.

 

 

 

 


Abb. 3.2:

Nutzung einer Smart Card [CW98]

 

 

 

Ein Praxisbeispiel ist die Student Identity Card der Universität Leipzig. Neben der momentan vorrangigen Funktion als Zutrittsberechtigung für Informatikstudenten zum CIP-Pool sind weitere Funktionen geplant bzw. bereits realisiert. Dazu gehören beispielsweise die Bezahlung in der Mensa oder die Überweisung des Semesterbeitrags.

3.2.3.     Ein Web-basiertes System für Finanztransaktionen

Finanzmärkte dienen dazu, Käufer und Verkäufer von Finanztiteln zusammenzubringen und Preise für die einzelnen Titel festzulegen. Häufig werden Anlagen zur Risikominderung gestreut, ein wichtiges Beispiel sind Aktienfonds. Eine gewichtete Zusammenstellung verschiedener Finanztitel wird als balanciertes Portfolio bezeichnet. Werden weitere Anteile gekauft oder einige Anteile abgestoßen, so möchte man in der Regel die Wichtung der einzelnen Finanztitel beibehalten. Heutige Finanzmärkte, egal ob automatisiert oder nicht, erlauben aber nur den separaten Handel von Finanztiteln. Dadurch kann sich die Balance des Portfolios leicht ändern, wie Abb. 3.3. zeigt.

 

 

 

 

 

 

 

 

 

 

 

 


Abb. 3.3: Balanceänderung eines Portfolios [FS99]

Zur automatisierten Lösung dieses Problems wurde am Center for Research in Electronic Commerce der University of Texas at Austin ein FBTS (Financial Bundle Trading System) entwickelt, welches in [FS99] beschrieben wird. Kernstück ist der Automated Matching Mechanism, dessen mathematische Grundlage das in Abb. 3.4 dargestellte lineare Optimierungsproblem ist.

 


p

limit price vector

x

proportion vector

B

share matrix: order j contains bij shares of asset i (pos. ... buy, neg. ... sell)

 

(1)

goal: to maximize market surplus

(2)

buy <= sell

(3)

Standardization

(4)

only positive proportions

 

Abb. 3.4: Optimierungsproblem [FS99]

Die Gesamtarchitektur des Systems wird in Abb. 3.5 dargestellt.

 

 

 

 

 

 


Abb. 3.5:

Architektur des

FBTS [FS99]

 

 

 

 

 

 

 

Der Exchange-Bereich enthält neben einem Web-Server und einem Datenbank-Server noch einen Naming and Directory Service. Dieser dient zum Auffinden einzelner Objekte im Gesamtsystem, welches mittels einer Common Object Request Broker Architecture (CORBA) realisiert wird. In der Limit Order Table werden alle offenen Orders gespeichert. Wird eine Order erfüllt oder widerrufen, so erfolgt ein Log-Eintrag in die Datenbank vor ihrer Streichung aus der Limit Order Table. Das Order Routing and Notification System fungiert als Monitor für die Limit Order Table und informiert beteiligte Händler über aktuelle Veränderungen. Das Automated Bundle Matching Program schließlich berechnet in Echtzeit Matchings, indem es nach jedem kompletten Durchlaufen des Algorithmusæ einen neuen Schnappschuß der Limit Order Table zugrundelegt. Die für den Händler relevanten Informationen werden über ein Java-Applet dargestellt und mittels Remote Method Invocation (RMI) ständig aktualisiert. Neue Order oder Cancels werden ebenfalls über das Applet versandt.

Aus technischer Sicht entschieden sich die Autoren für die Verwendung von CORBA und RMI statt des Common Gateway Interface (CGI). Folgende Gründe waren ausschlaggebend:

 

CORBA/RMI

CGI

Update

automatisch

manuell (Reload)

Übertragung

Variablenwerte

komplettes HTML-Dokument

Weiterentwicklung/Wartung

Interface Definition

Änderung CGI-Script

Es verbleibt die Untersuchung der verwendeten Synchronisationsverfahren. Zum einen erfolgt die Eintragung neuer Limit Orders synchron (Mutual Exclusion), d.h. die Limit Order Table erlaubt nur die Manipulation durch maximal einen Prozeß gleichzeitig. Damit wird eine eindeutige ID-Vergabe gewährleistet. Wird eine Order widerrufen, so erfolgt die Stornierung asynchron, da eine Zugriffssperrung der Limit Order Table während der Ausführung des Matching-Algorithmusæ nicht akzeptabel ist. Damit kann eine Order nach dem Start des Matching-AlgorithmusÆ nicht mehr storniert werden. Zur Verdeutlichung dieses Sachverhalts ist der Pseudo-Code in Abb. 3.6 dargestellt:

 

 

 

 

 

 


Abb.3.6:

asynchrone Stornierung [FS99]

 

 

 

 

 

 

 

 

 

 

 

 

Aktuell befindet sich dieses Projekt im experimentellen Stadium. Einige Aufgaben werden noch zu lösen sein, so z.B. die Realisierung von Sicherheitsmechanismen und die Verhinderung von Arbitrage (risikoloser Gewinn).

3.3.  Workflow-Management

Klassische Informationssysteme integrieren logische Abläufe von Geschäftsprozessen und die zugehörigen Anwendungen. Damit lassen sich Änderungen dieser Prozesse nur mit einigem Zeitaufwand vornehmen. Gerade in der heutigen Zeit müssen Unternehmen aber sehr flexibel sein, um sich schnell veränderten Bedingungen anzupassen oder Optimierungsmöglichkeiten umzusetzen.

Die Idee der Workflow-Technologie besteht nun darin, die Ablauflogik vom Anwendungscode zu trennen, was bei stark strukturierten Prozessen möglich ist. Damit lassen sich auch komplexe Geschäftsprozesse flexibel und wartungsfreundlich gestalten und logische Fehler leichter erkennen. Nachteilig wirkt sich der hohe Initialaufwand bei der Einführung eines solchen Systems aus, da tiefe Eingriffe in die Unternehmensstruktur notwendig sind. Außerdem können Mitarbeiter besser überwacht werden, was nicht immer akzeptiert wird.

Zunächst bietet sich der Einsatz der Workflow-Technologie im Rahmen von E-Commerce-Systemen vor allem innerhalb eines Unternehmens an. Ein weitergehender firmenübergreifender Ansatz wird am Swiss Federal Institute of Technology im Rahmen des Projektes Workflow based Internet Services (WISE) untersucht. Die zugrundeliegende Idee ist die Integration der einzelnen Dienste, welche von verschiedenen Unternehmen angeboten werden, in einen virtuellen Gesamtprozeß. Die Hauptaufgabe besteht dann darin, eine Workflow-Engine zur Ausführung der Workflows über mehrere reale Unternehmen hinweg zu entwickeln. Da das WISE-Projekt bereits im Rahmen des Problemseminsars äDatenbankeinsatz im Internetô im SS99 vorgestellt wurde, wird hier auf weitergehende Erläuterungen verzichtet.

3.4.  Brokering

Speziell im WWW steht man vor der Aufgabe, Anbieter relevanter Produkte überhaupt erst einmal zu lokalisieren, da man natürlich deren Internet-Adresse kennen muß. Zusätzlich ist meist die Auswahl des preiswertesten oder billigsten Anbieters erwünscht, was ohne Hilfsmittel wohl nur selten möglich sein dürfte.

Eine Lösung ist die Zwischenschaltung von Brokern. Hierbei unterscheidet man laut [MG99] zwei verschiedene Formen analog der eben gemachten Ausführungen. Product Brokering ist die Suche nach geeigneten Produkten entsprechend einer Merkmalsliste, wobei der Nutzer dies ggf. mehrmals durch Hinzufügen weiterer einschränkender Merkmale wiederholt. Die andere Variante ist das Merchant Brokering, bei dem die prinzipielle Produktauswahl abgeschlossen ist und nach dem preisgünstigsten Anbieter gesucht wird. Oftmals, z.B. bei PCs, gibt man nur eine grobe Produktspezifikation an, um sich und dem Händler einen gewissen Spielraum zu lassen.

Die einfachste Form von Brokern ist schon seit längerem im WWW verfügbar. Es handelt sich um die bekannten Suchmaschinen, welche den Nutzer bei der Suche nach Produkten oder Dienstleistungen unterstützen. Häufig enthält die Ergebnisliste jedoch große Mengen irrelevanter Verweise und einige richtige Ergebnisse fehlen, da die zugehörigen Web-Seiten nicht in der Datenbank der Suchmaschine gespeichert sind.

Komplexere Brokering-Mechanismen lassen sich, wie in Abb. 3.7 dargestellt, durch Software-Agenten realisieren.

 


Abb. 3.7:

Brokering mittels

Software-Agenten [MG99]

 

Der Kunde beauftragt einen Shopping Agent mit dem Einkauf verschiedener Produkte. Dieser verhandelt dann mit den Sales Agents der verschiedenen Händler. Solche Szenarien bedürfen aber einer deutlichen Weiterentwicklung im Bereich der Software-Agenten, auf den im Unterkapitel 3.6. noch näher eingegangen wird. In Zukunft werden Broker aber durch unaufhaltsame Verbreiterung des Produktangebots und der anbietenden Händler im WWW unverzichtbar sein.

3.5.  Auktionen

In herkömmlichen Online-Shops werden Produkte in der Regel zu Festpreisen angeboten. Im Gegensatz dazu bieten Auktionen einfache Verhandlungsmöglichkeiten. Zunächst erfolgt eine Klassifikation der verschiedenen Auktions-Typen nach [KF99], wobei nur die gewöhnlichsten berücksichtigt werden. Die wohl bekannteste Form sind die Open-Cry-Auctions oder auch English Auctions. Die Bieter befinden sich gemeinsam zu einer bestimmten Zeit an einem bestimmten, ggf. virtuellen, Ort. Die abgegebenen Gebote sind allen Teilnehmern zugänglich, es existiert ein Zeit-Limit zur Abgabe eines höheren Gebots. In der Regel wird zu Beginn ein Mindestgebot vorgegeben. Eine andere Variante sind die Sealed Bid Auctions, bei denen alle Gebote bis zum Erreichen einer Deadline geheim bleiben, öffentliche Aufträge in Deutschland werden teilweise nach dieser Methode vergeben. Bei den Dutch Auctions hingegen wird mit einem sehr hohen Preis gestartet und es erfolgt eine sukzessive Dekrementierung proportional zum aktuellen Preis. Den Zuschlag erhält entweder der Bieter, der als erster zum Kauf bereit ist, oder die Bieter spezifizieren die Anzahl der Produkteinheiten, die sie aktuell kaufen würden.

Es existieren zahlreiche Variationen. So können Bieter anonym bleiben oder auch nicht und die Auktionsdauer reicht von wenigen Minuten bis zu mehreren Wochen. Schließlich muß noch der Preis des Produkts ermittelt werden. Bei Discriminative Auctions (Yankee Auctions) ist der zu zahlende Preis gleich dem Gebot, bei Non-discriminative Auctions ist er gleich dem niedrigsten Höchstgebot. Eine weitere Variante ist die Preisfestsetzung entsprechend dem zweithöchsten Gebot. Man spricht dann von Vickrey Auctions.

Der Auktionsprozeß selbst unterteilt sich in verschiedene Schritte. Zunächst müssen sich Käufer und Verkäufer registrieren, um im Falle eines Zuschlags die Abwicklung des Geschäfts zu gewährleisten. Danach ist das Auktionsereignis durch die Festlegung von Zeit, Ort und Regeln genau zu bestimmen. Um auch weniger attraktive Produkte zu verkaufen, werden häufig mehrere Produkte gemeinsam versteigert. Weiterhin ist Werbung zu betreiben, um möglichst viele Personen von der bevorstehenden Auktion in Kenntnis zu setzen. Hat die Auktion begonnen, so erfolgt die Abgabe der Gebote. Nach dem Abschluß dieser Prozedur ist die Auktion beendet, die Gebote werden überprüft und die Gewinner festgelegt. Schließlich kommt es zu einer Handelsvereinbarung, in der Bezahlungs- und Lieferungsmodalitäten festzuhalten sind. Dieser Prozeß erfordert also einigen Aufwand und ist durch die vielfältigen Regelvarianten ggf. recht komplex. Damit liegt eine Automatisierung durch Software-Agenten nahe. Nähere Erläuterungen dazu erfolgen, wie bereits erwähnt, im Unterkapitel 3.6.

Auktionen erfreuen sich laut [GO99] zunehmender Beliebtheit. Für Unternehmen stellen sie eine ideale Möglichkeit zur Räumung von Lagerbeständen dar, besonders bei kurzen Produktzyklen wie z.B. in der Elektronik-Branche. Eine weitere Möglichkeit ist die Verteilung ungenutzter Einkäufe oder überschüssigen Materials innerhalb der äCorporate Familyô, d.h. dem Kreis der engeren Handelspartner. Nicht zuletzt sind Auktionen auch ideal zur Platzierung von Werbung, da Bieter die entsprechenden Web-Seiten häufig zur Überprüfung des aktuellen Höchstgebots aufsuchen. Auktionen stellen die momentan einzige nennenswerte Form des E-Commerce im Consumer-to-Consumer-Bereich dar. Viele Privatpersonen nutzen diese Möglichkeit zum Verkauf von Gebrauchtwaren oder zum Ersteigern von Sammlerstücken. Das erste Auktionshaus im Internet, das 1995 eröffnete Ebay, ist beispielsweise ausschließlich auf Consumer-to-Consumer-Auktionen fixiert.

Besonders bei Auktionen wird die Notwendigkeit rechtlicher Grundlagen deutlich. So gibt es in den USA schon Auktionen, bei denen Emissionsrechte versteigert werden.

3.6.  Software-Agenten

Nach [AD98] sind Software-Agenten Programme, die selbständig verschiedene Aufgaben ohne direkte menschliche Manipulation durchführen. Mehrere in einer lose verbundenen Gruppe zusammenarbeitende Software-Agenten bezeichnet man als Multi-Agenten-System.

Zur Realisierung eines Software-Agenten, der Kauf- und Verkaufsprozesse im E-Commerce unterstützt, ist zunächst ein Modell dieser Prozesse notwendig. Es existieren verschiedene Ansätze, deren Grundmerkmale im Buying Behavior Model, welches in [MG99] erläutert wird, zusammengefaßt sind. Abb. 2.11 zeigt eine Übersicht der verschiedenen Schritte und aktueller Implementierungen.

 

 

 

 


Abb. 3.8:

aktuelle

Implementierungen

[MG99]

 

 

 

 

Momentan werden Software-Agenten vor allem zum Brokering, d.h. der Suche nach Produkten und preisgünstigen Anbietern, und bei Verhandlungen eingesetzt. Dabei beschränken sich Verhandlungen in der Regel auf die einfache Form der Auktion. Solche Agenten treten dann als Bieter auf und handeln entsprechend vorgegebener Parameter, z.B. einer Inkrementierungsfunktion. Ein weiteres Einsatzgebiet ist die Identifizierung unbefriedigter Bedürfnisse. So informieren beispielsweise Monitore über aktuelle Lagerbestände und weisen ggf. auf zur Neige gehende Ressourcen hin. Eine andere Möglichkeit ist das Vorschlagen neuer Produkte entsprechend einem Nutzerprofil, z.B. ein Hinweis auf das Erscheinen einer neuen CD mit bevorzugten Musikstücken.

Es existieren verschiedene Ansätze, wie relevante Informationen gefunden werden sollen. Nachfolgend wird eine Übersicht aus [MG99] wird dargestellt:

Filtermethode

Beschreibung

Beispiel

Content-based

Suche nach Schlüsselwörtern (Produkteigenschaften)

BargainFinder

Collaborative-based

Vorschlag von Produkten, die Konsumenten mit ähnlichem Profil bevorzugen

Firefly

Constraint-based

harte und weiche Merkmale, Product u. Merchant Constraints

Tete-a-Tete

Auch für die Verhandlungsführung gibt es verschiedene Methoden. Auf der einen Seite können Software-Agenten kooperieren, d.h. das Erreichen eines gemeinsamen Ziels verfolgen. Zum anderen können Agenten ausschließlich eigene Interessen verfolgen, also im Wettbewerb gegeneinander stehen. Die letztere Form ist in einem marktwirtschaftlichen Umfeld natürlich realistischer und damit auch häufiger implementiert, z.B. bei AuctionBot.

Essentielle Voraussetzung zum Einsatz von Software-Agenten ist die Kommunikationsmöglichkeit mit anderer Software. Problematisch ist hierbei sowohl die Hardware- als auch die Software-Interoperabilität. In der Regel werden momentan sogenannte Wrapper, d.h. auf verschiedene Plattformen angepaßte Übersetzer, eingesetzt. Neben der traditionellen Implementierung per Hand, z.B. bei BargainFinder, finden sich auch zumindest teilweise automatisierende Methoden. So verschickt Jango beispielsweise Testanfragen an Web-Seiten und überprüft den Sinngehalt der Antwort.

Neuere Ansätze untersuchen die Möglichkeiten von XML im Hinblick auf die Produktbeschreibung, da hier nicht nur die Präsentation sondern auch der Inhalt eines Absatzes beschrieben wird. Beispielsweise führt das Konsortium CommerceNet dazu Studien durch. Eine andere Variante ist die Einführung einer eigenen Sprache für Software-Agenten. So existiert z.B. die deklarative Sprache Knowledge Query Manipulation Language (KQML) mit dem zugehörigen Vokabular Knowledge Interchange Format (KIF).

Insgesamt muß festgestellt werden, daß heutige Software-Agenten viele Möglichkeiten noch nicht nutzen (können). Zur Weiterentwicklung sind vor allem Standardisierungen in den Bereichen Produktbeschreibung, Datenformate und Bezahlsysteme nötig. Weit voraus gedacht könnten Software-Agenten auch im Business-to-Business vielfältig eingesetzt werden, z.B. wären dynamische Firmenpartnerschaften durch strategische Koalitionen von Agenten denkbar.

 

 

4.       Standardisierungsbemühungen

 

Nachfolgend werden die Standardisierungansätze zweier Konsortien betrachtet. Zunächst erfolgt die Vorstellung eines praktischen Ansatzes für Business-to-Business-Anwendungen, der auf vorhandenen Standards aufsetzt. Danach wird eine Referenzarchitektur für verteilte objektorientierte Umgebungen betrachtet, die sich nicht auf eine einzelne Klasse des E-Commerce beschränkt.

4.1.        Open Buying on the Internet (OBI)

Laut [OB99] wurde das OBI-Konsortium im Oktober 1996 mit dem Ziel gegründet, einen offenen, händlerneutralen, skalierbaren, interoperablen und sicheren Standard für den Business-to-Business-Bereich des E-Commerce zu entwickeln. Großunternehmen wie BASF, Ford, General Electric und National Semiconductor gehörten zu den Gründungsmitgliedern. Heute zählt das Konsortium mehr als 60 Mitglieder, darunter z.B. auch IBM und Oracle.

Abb. 4.1. zeigt die OBI-Architektur.

 

 

 

 

 

 

 

 

 

 

 

 


Abb. 4.1: OBI Architecture [OB99]

Das zugrundeliegende Modell des Business-to-Business E-Commerce beinhaltet einen Requisitioner, welcher i.a. der Buying Organization angehört. Er verbindet sich mit dem Purchasing Server der Buying Organization und wählt entsprechend der einzukaufenden Waren eine Selling Organization aus (1). Im Online-Katalog dieses Unternehmens legt der Requisitioner die gewünschten Waren in seinen Einkaufskorb (2). Daraus generiert die Selling Organization zusammen mit den Identifizierungsinformationen des Requisitioners eine EDI-kompatible Order Request. Diese wird in ein OBI Object eingekapselt und an die Buying Organization gesendet (3). Dort wertet man die Daten aus und fügt zusätzliche Informationen wie die Zahlungsart hinzu (4). Dann wird eine wiederum EDI-kompatible OBI Order generiert, die eingekapselt in ein OBI Object an die Selling Organization zurückgesendet wird (5). Diese überprüft bei der Payment Organization die Zahlungsfähigkeit der Buying Organization und erfüllt den Auftrag (6). Schließlich stellt die Payment Organization eine Rechnung aus und die Buying Organization begleicht diese (7). Alle teilnehmenden Organisationen authentifizieren sich jeweils über digitale Zertifikate und unterschreiben Dokumente optional mit digitalen Signaturen. Zur Übertragung von Objekten über das Internet wird HTTP mit SSL benutzt.

Durch OBI werden folgende Aspekte standardisiert:

-         Zugriff des Requisitioners auf den Katalog der Selling Organization (Web-Browser)

-         Format von Order Request und OBI Order (ANSI X12 Transaction Set 850)

-         Benutzung optionaler digitaler Signaturen

-         Einkapselung von Order Request und OBI Order in OBI Objects

-         sichere Übertragung von OBI Objects (HTTP und SSL)

-         Authentifizierung durch digitale Zertifikate (X.509 V3)

OBI setzt, wie aus obigen Punkten ersichtlich, auf vielen bereits vorhandenen Standards auf und spezifiziert die einheitliche Verwendung dieser Standards. Eine aktuelle Implementierung besteht in den Add-Ons OBI/Sell und OBI/Buy für das System Net.Commerce von IBM. Zukünftig möchte man auch Dokumente basierend auf EDIFACT und/oder XML unterstützen.

4.2.        Open Service Model (OSM)

Auch die OMG (Object Management Group) beschäftigt sich mit der Entwicklung standardisierter verteilter Plattformen für elektronische Märkte. Hierzu wurde die ECDTF (Electronic Commerce Domain Task Force) ins Leben gerufen, zu der neben vielen Großunternehmen wie IBM, Sun, Oracle und AT&T das OSM-Konsortium gehört. Im Gegensatz zu OBI möchte man eine komplette objektorientierte Lösung anbieten, die sich nicht auf den Business-to-Business-Sektor beschränkt.

Zur Zusammenarbeit vielfältiger Hardware-Plattformen ist das Vorhandensein transparenzerzeugender verteilter Software-Umgebungen fundamental. Ein wichtiges Beispiel stellt das von das OMG entwickelte CORBA dar. Entsprechend ihrer Philosophie hat die OMG eine CORBA-basierte Modellarchitektur für E-Commerce spezifiziert, das in Abb. 4.2 dargestellte Open Service Model.

 

 

 

 

 

 

 

 


Abb. 4.2:

Reference

Architecture

[OS99]

 

 

 

 

 

 

 

 

 

Im Rahmen von Marktuntersuchungen identifizierte man einzelne Facilities, welche zur Durchführung von Geschäftsprozessen im E-Commerce notwendig sind. Diese Facilities werden entsprechend ihrer Funktion in drei prinzipielle Gruppen unterteilt.

Eine Übersicht der Facilities nebst ihrer Gruppenzuordnung wird in der folgenden Tabelle dargestellt:

Low Level Facilities

Payment

Integration verschiedenster Protokolle, z.B. SET

Semantic Data

standardisierte Beschreibung von Produkten, Diensten, Inhalten;

dynamische Änderungsmöglichkeit dieser Beschreibungen

Selection / Negotiation

Auswahl einer bestimmten allgemeinen Verfahrensweise, z.B. für Verhandlungen

Commerce Facilities

Service / Contract

Anbieten von Diensten, Abschluß von Verträgen

Desktop

Einbindung externer Objekte, Navigation

Market Facilities

Catalogues

Übersicht über angebotene Dienste

Brokerage

Suchanfragen, Vermittlung von Diensten

Agency

Schnittstelle für allgemeine Informationen, z.B. über einen Händler

Der wesentlichste Entwicklungsaufwand liegt bei der Implementierung der Negotiation und Brokerage Facilities. Dementsprechend existieren die Arbeitsgruppen Brokerage Working Group und Agent Working Group. Als dritte Arbeitgruppe ist die Reference Model Working Group für die Anpassung des Referenzmodells an neue Entwicklungen zuständig.

Da man sich momentan noch in der Implementierungsphase befindet, sind einige Änderungen im Detail und bei den Bezeichnungen zu erwarten bzw. schon erfolgt.


 

5.       Rahmenbedingungen

 

Das folgende Kapitel 5 beschäftigt sich mit den Themen Sicherheit und gesetzliche Grundlagen, wobei auch auf die Verbrauchersituation in Deutschland eingegangen wird.

5.1.  Sicherheit

5.1.1.     Sicherheit in Rechnernetzen

Alle E-Commerce-Anwendungen benutzen ein Rechnernetz zur Datenübertragung. Dadurch entstehen potentielle Angriffsmöglichkeiten für Dritte. Speziell im globalen Internet sind Unternehmens-Server meist durch Firewalls abgeschirmt, während die PCs kleiner Kunden, insbesondere von Privatpersonen, oft nur geringe Schutzmechanismen aufweisen. Allerdings ist der wirtschaftliche Wert dieser Rechner und damit der mögliche Schaden in der Regel eher gering. Entscheidend ist vor allem die Übertragung über einen Kommunikationskanal. Hierbei ergeben sich folgende Angriffsmöglichkeiten:

Passive Angriffe

Abhören von Identitäten, Nachrichten sowie Verkehrsflußanalysen

aktive Angriffe

Verändern, Duplizieren, Löschen von Nachrichten

Eine Zusammenfassung der wichtigsten Dienste zum wirksamen Schutz von E-Commerce-Transaktionen findet sich in [AD98]:

-         Authentizität (Nachweisbarkeit der wahren Identität)

-         Authorisation (nutzerspezifische Zugriffserlaubnis auf Daten)

-         Vertraulichkeit (Verhinderung unerlaubter Zugriffe auf Daten)

-         Integrität (physische und logische Unversehrtheit von Daten)

-         Nachweisbarkeit (Nachweisbarkeit aller durchgeführten Transaktionen)

5.1.2.     Kryptographie

Um obige Dienste anbieten zu können, sind offensichtlich Mechanismen zur Verschlüsselung von Daten notwendig. Unter Chiffrierung versteht man die Anwendung einer i.a. injektiven Transformationsfunktion auf eine Nachricht. Das Resultat ist abhängig von der Nachricht selbst und einem individuellen Parameter (Schlüssel). Die heute verwendeten Funktionen haben Einwegcharakter, d.h. die Dechiffrierung ist praktisch nur unter Kenntnis eines weiteren Parameters möglich.

Symmetrische Verfahren zeichnen sich dadurch aus, daß zum Chiffrieren und Dechiffrieren der gleiche Schlüssel verwendet wird. Es ergibt sich das Problem der Schlüsselübergabe, welche über einen sicheren Kommunikationskanal erfolgen muß. Asymmetrische Verfahren umgehen dieses Problem, indem zwei verschiedene Schlüssel verwendet werden. Einer ist öffentlich zugänglich, der andere privat. Wird eine Nachricht mit dem öffentlichen Schlüssel kodiert, so ist sie nur mit Hilfe des privaten Schlüssels dekodierbar. Auf der anderen Seite können mit dem privaten Schlüssel kodierte Nachrichten nur mit dem öffentlichen Schlüssel dekodiert werden.

Lassen sich durch Verschlüsselung von Daten zunächst nur Authorisation, Vertraulichkeit und Integrität realisieren, so wird durch asymmetrische Verfahren beispielsweise auch Authentifikation möglich. So kann eine mit dem privaten Schlüssel kodierte Nachricht zwar von jedem dekodiert werden, aber nur vom Besitzer des privaten Schlüssels erzeugt worden sein. Darauf setzen dann die sogenannten digitalen Signaturen auf.

Häufig verwendet man heute das asymmetrisches RSA-Verfahren (nach den Entwicklern Rivest, Shamir und Adleman) zum sicheren Austausch der gemeinsamen Schlüssel für das symmetrische Verfahren Data Encryption Standard (DES). Ursache ist die durch den höheren Berechnungsaufwand von asymmetrischen Verfahren entstehende längere Verzögerungszeit beim Versenden und Empfangen von Nachrichten. Eine Beispielrealisierung im Internet ist das in der Transportschicht angesiedelte Protokoll SSL (Secure Socket Layer). Es handelt sich dabei um den einzigen Sicherheitsstandard, der im E-Commerce momentan weltweit etabliert ist, was nicht zuletzt an der Integration in die aktuellen Browser liegt.

5.2.  Gesetze

Die Ausführungen in diesem Unterkapitel entstammen sämtlich [GO99].

5.2.1.     Globale Problematik

Im Internet gibt es im wesentlichen zwei rechtliche Probleme, die zu lösen sind. Zum einen stellt sich die Frage, wie man Inhalte von Web-Seiten auf ihre Zulässigkeit hin kontrollieren kann. Andererseits wird der Handel von Waren und Dienstleistungen in der Regel mit Steuern bzw. Zöllen belastet, wobei gerade letzteres durch die teilweise nicht eindeutige Zuordnung einer Web-Seite zu einem bestimmten Land unklar ist.

Da es sich beim WWW um ein globales Medium handelt, ist eine einheitliche globale Gesetzgebung unerläßlich. Viele Länder haben jedoch eigene Gesetze verabschiedet, wodurch ein Angleichungsprozeß notwendig wird. Hierbei stoßen besonders die verschiedenen Philosophien der größten Industrieregionen USA und Europa aufeinander. Seitens der USA fordert man unter Zustimmung der Industrie, das Internet als Freihandelszone aufzufassen. Weiterhin sollen sich Unternehmen nach dem Vorbild z.B. in der Filmindustrie bestehender Regelungen selbst kontrollieren. Demgegenüber stehen staatliche Regulierungsbedürfnisse in vielen europäischen Ländern. Zunehmend setzt sich jedoch auch in Europa die Einsicht durch, daß im Internet staatliche Kontrollmechanismen an ihre Grenzen stoßen. Somit setzt man auf eine marktwirtschaftliche Expansion des E-Commerce.

Besonderen Wert legen alle Staaten auf die Schaffung allgemein akzeptierter Sicherheitsstandards, um einen ausreichenden Schutz der Internetnutzer zu gewährleisten. Handlungsbedarf besteht vor allem seitens der USA, die Kryptographie bisher als Waffe einstufen und entsprechenden Produkten damit harte Exportbeschränkungen auferlegen. Allerdings ist diese Regelung nicht schlüssig, da nur Implementierungen und nicht die zugehörigen Quellcodes betroffen sind. Drastische Lockerungen sind jedoch in Aussicht gestellt. Noch in diesem Jahr soll die erlaubte Schlüssellänge für genehmigungsfreie Produkte von 40 Bit auf 64 Bit angehoben werden. Alles andere bedarf der Genehmigung durch die zuständigen Regierungsbehörden, um bestimmte nach Meinung der USA terroristische Staaten als Empfänger auszuschließen.

5.2.2.     Verbrauchersituation in Deutschland

Beim Handel im Internet stellt sich zunächst die Frage, ab wann dieser bindend ist. Nach deutschem Recht sind Verträge grundsätzlich auch formlos gültig, der berühmte äHandschlagô genügt. Damit reicht z.B. eine E-Mail ohne Unterschrift aus. Im Falle einer gerichtlichen Auseinandersetzung liegt die Beweisnot jedoch beim Kläger und Inhalte von Webseiten sind beispielsweise sehr schnell geändert oder entfernt. Abhilfe ist aber in Sicht, da sich digitale Signaturen immer mehr durchsetzen.

Wichtig ist ebenfalls, daß das Haustürwiderrufsgesetz keine Anwendung finden kann, weil dazu mündliche Verhandlungen vorausgesetzt werden. Dem soll mit dem äFernabsatzgesetzô begegnet werden, welches nach EU-Bestimmungen bis zum 4. Juni 2000 zu verabschieden ist. Nach aktuellem Stand wird dem Käufer einer Ware dann eine Widerspruchsfrist von 7 Werktagen zugestanden.

Insgesamt gestaltet sich die Situation recht verbraucherfreundlich und innerhalb der EU weitestgehend sicher. Problematisch sind aber Einkäufe aus Nicht-EU-Staaten, da z.B. die Frage des Gerichtsstandes bei Zivilverfahren sehr unterschiedlich in internationalen oder bilateralen Übereinkommen geregelt ist. Hier bleibt also noch viel Abstimmungsarbeit zu leisten.


 

6.       Ausblick

 

Abschließend werden zukünftige Entwicklungen im E-Commerce vorgestellt. Neben fortgeschrittenen Online-Shops gehört dazu die Migration von E-Commerce in Mobilfunknetze.

6.1.  Zukünftige Online-Shops

Bisher bieten Online-Shops eher funktionelle als attraktive Warenpräsentationen in Form von Listen. Die Erfahrung mit herkömmlichen Einkaufszentren haben aber gezeigt, daß man Einkaufserlebnisse bieten muß, um Kunden zu gewinnen. Zunächst ist vor allem mehr Realitätsnähe erforderlich, wozu z.B. eine dreidimensionale Darstellung von Objekten gehört.

Die Idee einer 3D-Einkaufswelt wird nach [GO99] und [VR99] beispielsweise innerhalb eines Projektes des Fraunhofer IAO (Institut Arbeitswirtschaft und Organisation) untersucht. Dort arbeitet man an der Implementierung eines Virtual-Reality-Shops (VR-Shops). Im Vordergrund steht die Möglichkeit der Interaktion mit dreidimensionalen Nachbildungen von Produkten. Der Computer dient somit nur als Visualisierungsinstrument. Desweiteren möchte man die Isolation einzelner Nutzer beseitigen. Hierzu dienen sogenannte Avatare, virtuelle dreidimensionale Personennachbildungen. Diese Software-Agenten repräsentieren jeweils herkömmliche Verkäufer. Insgesamt fühlt man sich also wie ein Kunde in einem wirklichen Kaufhaus.

Andere Ansätze beschäftigen sich mit der Einbindung realer Personen in den Kaufprozeß. Dies resultiert aus der Erfahrung, daß Kunden nicht vollständig auf menschliche Beratung verzichten wollen. Eine Variante ist das Push-to-Talk-Konzept, bei dem reale Verkäufer auf Abruf per Videokonferenz zur Verfügung stehen.

6.2.  Mobile Commerce

In [GO99] wird Mobile Commerce (M-Commerce) ausführlich betrachtet, hier folgt lediglich eine kurze Zusammenfassung. Viele Mobilfunkbetreiber bieten ihren Kunden bereits heute eine Reihe von Dienstleistungen über ihre jeweiligen Call-Center an. Das Produktangebot ist zwar oft vielfältig, erfolgreich ist dieses Geschäftsmodell jedoch bisher nicht. Besonders die Auftragseingabe stellt sich als recht aufwendig dar, egal ob über Call-Center-Agenten oder per SMS (Short Message Service). Erst neuere Geräte schaffen hier Abhilfe durch eine komfortable menügesteuerte Bedienung.

Gute Chancen sich durchzusetzen haben insbesondere solche Anwendungen, die bereits existierende E-Commerce-Services mit den spezifischen Eigenschaften des Mobilfunks verbinden. Folgende Qualitätsmerkmale sind von Interesse:

-         always ready: zeitaufwendiges Einwählen entfällt

-         Erreichbarkeit: Handys bleiben in der Regel ständig angeschaltet und sind zumindest in Gebieten höherer Bevölkerungsdichte einsatzbereit

-         Sicherheit: eindeutige Identifizierung per Subscriber Identfication Module (SIM-Karte), Zahlungstransaktionen bleiben in einem einzigen geschlossenen Netz

-         Mobilität: zeitsensitive Märkte, z.B. Börse, nicht beeinträchtigt

-         Lokalisierung: der Ort des Nutzers ist Mobilfunkbetreiber bekannt

Damit ergeben sich als prädestinierte Einsatzgebiete des M-Commerce beispielsweise Informationsdienste und Finanzgeschäfte. Klare umsatzmäßige Dominanz übt zu Beginn der Entwicklung wieder der Business-to-Business-Bereich aus.

Die Mobilfunkbetreiber werden sich in Zukunft immer weniger von Internet Service Providers (ISPs) unterscheiden. Allerdings sind sie auch zum Umdenken gezwungen, da sie ihre Netze gegenüber Dritten öffnen müssen. Momentan geschieht dies nicht oder nur sehr widerwillig. Dazu gibt es aber keine Alternative, gerade Banken und Versicherungen möchten ihre Kundenbeziehungen erhalten.

Neben dem Internet entsteht mittels des GSM-Systems (Global Services for Mobiles) somit ein weiteres weltumspannendes Kommunikationsnetz, welches sich z.B. durch seine Echtzeit-Funktionalität auszeichnet. Zur Verdeutlichung dient Abb. 6.1.

 

 

 

 

 

 

 

 


Abb. 6.1:

GSM [CW98]

 

 

 

 

 

 

 

 

 

 

 


 

7.       Literatur

 

[AD98] Adam, N.R.; Dogramaci, O.; Gangopadhyay, A.; Yesha, Y.: Electronic Commerce: Technical, Business and Legal Issues, Prentice Hall, 1998

 

[CP98] Cunningham, J.; Paurobally, S.; Diacakis, A.; Lorenzen, L.; Gross, G.; McConnell, S.: Satisfying Requirements for Electronic Commerce, In W.Lammersdorf and M.Merz (eds), Trends in Dirtributed Systems for Electronic Commerce (Proceedings TRECÆ98, Hamburg), Springer LNCS 1402, 1998

 

[CW98] Choi, S.; Whinston, A.B.: Smart Cards: Enabling Smart Commerce in the Digital Age, Center for Research in Electronic Commerce, The University of Texas at Austin, White Paper, Mai 1998, http://cism.bus.utexas.edu

 

[EC99] Web-Seiten des Verbandes der deutschen Internet-Wirtschaft, http://www.eco.de

 

[FC99] Fu, S.; Chung, J.; Dietrich, W.; Gottemukkala, V.; Cohen, M.; Chen, S.: A Practical Approach to Web-Based Internet EDI, IBM IAC, Mai 1999, www.ibm.com/iac

 

[FS99] Fan, M.; Stallaert, J.; Whinston, B.: A Web-based Financial Trading System, Center for Research in Electronic Commerce, The University of Texas at Austin, 1999, http://cism.bus.utexas.edu

[GO99] cÆt special: Geld online, Verlag Heinz Heise, Hannover, 1999

[HS99] Hermanns, A.; Sauter, M.: Management-Handbuch Electronic Commerce, Verlag Franz Vahlen, München, 1999

 

[KF99] Kumar, M.; Feldman, S.I.: Internet Auctions, IBM IAC, November 1998, www.ibm.com/iac

[KÖ98] Köhler, T.: Electronic Commerce: Konzipierung, Realisierung und Nutzung in Unternehmen, Addison Wesley Longman, Bonn, 1998

 

[MG99] Maes, P.; Guttman, R.H.; Moukas, A.G.: Agents that Buy and Sell: Transforming Commerce as we Know It, MIT Media Laboratory, Software Agents Group, März 1999, http://ecommerce.media.mit.edu

 

[OB99] OBI Technical Specifications V2.0, Juni 1999, http://www.openbuy.org

 

[OS99] The OMG/CommerceNet Joint Electronic Commerce Whitepaper, Juli 1997, http://www.osm.net

 

[RR98] Riggins, F.J.; Rhee, H.S.: Toward a Unified View of Electronic Commerce, Communications of the ACM, 41(3), Oktober 1998

 

[VR99] Projekt VR-Shop des Fraunhofer IAO, http://www.vr-shop.iao.fhg.de