Individualisierung von Angeboten in einer Electronic Shopping Mall

(1)

Individualisierung von Angeboten in einer Electronic Shopping Mall

Dipl.-Kfm. Petra Schumann Bayerisches Forschungszentrum für

Wissensbasierte Systeme Am Weichselgarten 7

91058 Erlangen

Tel. 09131/691-216, Fax 09131/691-185 E-Mail: schumann@forwiss.uni-erlangen.de

1 Einleitung

Mit der beginnenden Kommerzialisierung des Internets Mitte der neunziger Jahre tauchte auch der Begriff der Electronic Shopping Mall (ESM) erstmals in den Medien auf. Aus Sicht der partizipierenden Unternehmen bestehen ihre primären Aufgaben - ähnlich wie bei einem her- kömmlichen Einkaufszentrum - darin, für die notwendige Infrastruktur zu sorgen, so daß sich der Online-Vertrieb durchgängig abwickeln läßt, sowie durch entsprechende Marketing-Maßnahmen eine angemessene Besucherzahl (Zugriffshäufigkeit) und damit Nachfrage innerhalb der Mall si- cherzustellen. Insbesondere für kleine und mittlere Unternehmen stellen ESM eine interessante Al- ternative dar, denn um einen erfolgreichen „Alleingang“ durchzuführen, fehlen ihnen im Gegensatz zu großen und international renommierten Unternehmen in der Regel die nötigen finanziellen Mit- tel, das technische Know-how sowie der erforderliche Bekanntheitsgrad.

Aus Kundensicht kann eine Mall wesentlich dazu beitragen, das Online-Angebot besser zu strukturieren, indem sie beispielsweise ein ausgewogenes Sortiment zusammenstellt, die verschiedenen Online-Shops in übersichtlicher und ansprechender Form präsentiert sowie komfortable Suchfunktionen bereithält. Der Einkaufsvorgang selbst ist in einer Mall wesentlich bequemer, denn anbieterübergreifende Mall-Dienste wie Warenkorb, Electronic Cash oder Heimlieferung ersparen dem Kunden eine Reihe von Transaktionen.

Aufgrund der enormen Fortschritte bei den Internet-Technologien sind die Anforderungen der Online-User erheblich gestiegen, so auch die Anforderungen an die Funktionalität einer virtuellen Mall. Die Tatsache allein, daß das Einkaufen dort leichter fällt, Transaktionskosten spart und vielleicht auch einen gewissen Unterhaltungswert hat, reicht vielen Kunden offensichtlich nicht mehr aus. Presseberichte über „Schließungen“ von Online-Malls (z. B. World Avenue von IBM) oder über enttäuschende Umsatzzahlen (z. B. bei my-world von Karstadt) zeugen davon, daß das Lei- stungsangebot heutiger ESM weder die auf Kunden- noch die auf Anbieterseite vorhandenen Be- dürfnisse ausreichend befriedigt. Man sucht nach einer neuen Qualität des Ein- bzw. Verkaufens, nach Möglichkeiten also, die das traditionelle Shopping/Selling nicht bieten kann. Dafür bedarf es innovativer Konzepte für die Funktionalität einer ESM, etwa neuartiger Beratungsleistungen oder Dienste zur kundenindividuellen Zusammenstellung von Angeboten.

(2)

2 Bündelung von Leistungen zu Objektsystemen

Das Internet trägt wesentlich dazu bei, daß der einzelne Kunde aus der Masse der Verbraucher verstärkt als Individuum hervortritt. Damit ist auch ein Trend vom Massen- zum Individualangebot vorgezeichnet.

Eine Möglichkeit, wie ein Anbieter seine Leistungen an die spezifischen Bedürfnisse eines Kunden anpassen kann, stellen sogenannte Objektsysteme dar. Aus standardisierten Einzelkompo- nenten läßt sich nach dem Prinzip eines Baukastens eine Vielzahl maßgeschneiderter Problemlö- sungen konfigurieren. Wie sich dieses Prinzip auf den Online-Vertrieb über eine ESM übertragen läßt, soll im folgenden untersucht werden.

2.1 Definition von Objektsystemen

Neben Waren, Dienstleistungen und ökonomische Chancen treten als vierte Gruppe der Ver- sorgungsobjekte die sogenannten Objektsysteme [Meye90, 17]. Diese setzen sich wiederum aus mindestens zwei gleich- oder verschiedenartigen Versorgungsobjekten zusammen.

Werden die einzelnen Objekte so miteinander verbunden, daß sie zwar erkennbar, nicht aber austauschbar sind, entsteht ein Objektverbund; bleiben sie austauschbar, spricht man von einer Ob- jektkombination. Aus der Verknüpfung von mindestens zwei Objektsystemen kann ein komplexes Super-Objektsystem hervorgehen [Brec91, 87].

In allen Fällen entsteht aus der Verknüpfung einzelner Versorgungsobjekte ein neues Objekt, das über eine reine Addition der Versorgungsobjekte, die seine Elemente bilden, nicht erreicht werden könnte.

2.2 Verkauf von Objektsystemen über das Internet

Der Bedarf eines Kunden (z. B. Ausrichtung einer Feier) läßt sich sehr häufig nur durch das Zusammenspiel einer Reihe von Leistungen eines oder mehrerer Anbieter befriedigen (z. B. Party- service von Feinkostladen A, Tischdekoration von Blumenhändler B und Unterhaltungsprogramm von Diskjockey C). Der Kunde benötigt also kein isoliertes Versorgungsobjekt, sondern eine Kom- bination aus unterschiedlichen, aufeinander abgestimmten Gütern und/oder Dienstleistungen (Ob- jektsystem). Werden die entsprechenden Teilleistungen von mehreren Anbietern erbracht, so muß der Kunde im Normalfall viele Einzelaktionen - etwa für jeden Anbieter Produktsuche, Vertragsab- schluß, Geschäftsabwicklung - und damit hohe Transaktionskosten in Kauf nehmen.

Die Online-Beschaffung hat hier zwar den Vorteil, daß der Kunde sämtliche Aktionen unmit- telbar an seinem Rechner ausführen kann, doch muß er nach wie vor mehrere Angebotsseiten aufru- fen und dann pro Produkt eine Bestellung und einen Bezahlungsvorgang auslösen. Darüber hinaus bleibt es weiterhin ihm überlassen, dafür Sorge zu tragen, daß die verschiedenen Komponenten gut aufeinander abgestimmt sind.

Anders sieht es bei einem sogenannten Systemgeschäft aus. In diesem Fall stellt ein einziger Anbieter, der Systemführer, im Auftrag des Kunden die verschiedenen Elemente eines Objektsy- stems zusammen. In der Regel fungiert derjenige Anbieter als Systemführer, welcher für die Her- stellung bzw. Lieferung der Hauptkomponente(n) des Objektsystems zuständig ist. In seinen Ver- antwortungsbereich fällt die komplette Durchführung des Systemgeschäfts, von der Kommunika- tion mit dem Kunden über die Auswahl der geeigneten Systemkomponenten sowie deren Lieferan- ten bis hin zur Integration der Teilleistungen. Der Kunde hat somit nur noch einen Ansprechpartner und reduziert in erheblichem Maße seine Transaktionskosten sowie das Risiko der Inkompatibilität.

Die Funktion des Systemführers könnte im Online-Vertrieb eine Electronic Mall übernehmen.

In ihrer Funktion als Cybermediär [SaBS95] integriert sie eine Vielzahl von Online-Shops, die - bei entsprechender Vorauswahl durch den Mall-Betreiber - gemeinsam in der Lage wären, ein be-

(3)

stimmtes Themengebiet abzudecken (z. B. „Alles rund ums Heiraten“) und damit auch Objektkom- binationen anzubieten, die ein komplexes Kundenproblem lösen (z. B. Organisation einer Hoch- zeit). In einer solchen Mall müßte der Kunde das Produktbündel zwar immer noch selbständig zusammenstellen, doch fände er die jeweiligen Informationen und Produkte „unter einem Dach“;

ein internetweites Suchen bliebe ihm somit erspart.

Daneben gibt es im Internet bereits einige Online-Beratungssysteme, die mehr oder weniger intelligent (z. B. mittels einfacher Fragen oder unter Einsatz wissensbasierter Elemente) den Bedarf des Kunden ermitteln, dazu passende Produkte aus dem Sortiment der angeschlossenen Anbieter selektieren und diese Auswahl dann in Form eines Ranking präsentieren (z. B. Personalogic [Pers98], Online-Produktberatung [PBK98]). Eine solche Dienstleistung hilft dem Kunden, seinen Informations- und Entscheidungsprozeß erheblich zu vereinfachen und zu verkürzen.

Verbindet man die Idee der „Problemlösungs-Mall“ mit der Funktionalität eines anbieter- übergreifenden Beratungssystems, so ergibt sich ein völlig neuartiges Konzept, wie es bisher im Internet noch nicht zu finden ist: eine Mall, die über das Sortiment und das notwendige „Wissen“

verfügt, um komplexe Kundenprobleme durch die automatische Kombination bzw. Bündelung von Produkten zu Objektsystemen zu lösen. Die Mall ist in diesem Fall der Systemführer, also die allei- nige Anlaufstelle für den Kunden (One-Stop-Shopping), und erledigt automatisch Transaktionen, die dieser ansonsten selbst ausführen müßte. Darüber hinaus erhält der Kunde eine fachkundige Be- ratung, beispielsweise dahin gehend, welche Komponenten das Produktbündel enthalten sollte (Konfiguration), welche Ausprägungen dieser Komponenten die spezifischen Bedürfnisse des Kun- den am besten erfüllen (Individualisierung) oder wie das erworbene Objektsystem später eingesetzt bzw. angewandt werden kann (After-Sales-Service). Das folgende Kapitel beschreibt das Konzept für einen solchen Mehrwertdienst.

3 Konzept eines Mehrwertdienstes zur Produktbündelung in einer Electronic Shopping Mall

Mittlerweile ist es kaum mehr möglich, den Überblick zu behalten, wie viele und welche Ar- ten von Electronic Malls bzw. Shopping Centers es im Internet gibt. Die Suchmachine „YAHOO!“

beispielsweise verzeichnet unter der Rubrik Online Shopping Centers weltweit ca. 1.000 Einträge, davon immerhin 80 in Deutschland [Yaho98]. Diese große Zahl legt eigentlich die Vermutung nahe, daß man als Online-Surfer bereits auf das eine oder andere innovative Mall-Konzept stoßen müsse, das neben den üblichen Standardmodulen etwas Besonderes, also einen Mehrwert, zu bieten hat. Doch in den meisten Fällen ist die Ausstattung der Malls eher bescheiden (z. B. nur Links auf ansonsten selbständige Shopping Sites, gewöhnliche Stichwortsuche, einfacher Warenkorb mit Be- stellfunktion). Einen entsprechenden Überblick zum State of the Art bei Electronic Malls geben [Stell98] und [Heid98].

Am FORWISS (Bayerisches Forschungszentrum für Wissensbasierte Systeme) entstand daher das Konzept für einen Mehrwertdienst, der dem Besucher einer ESM automatisch und unabhängig von den jeweiligen Interessen der Anbieter ein Produktbündel konfiguriert, welches das Problem dieses Kunden zu lösen vermag. Das System wurde so konzipiert, daß es sich als Zusatzdienst auf eine bereits vorhandene Mall aufsetzen läßt [ScHM98].

3.1 Die Wissensbasis des Event Advisory System (EASY)

Ein Fachverkäufer ist imstande, ausgehend von der Problembeschreibung seines Kunden für diesen ein Bündel aus Produkten und Dienstleistungen ganz unterschiedlicher Bereiche zusammen- zustellen. Er verfügt über das notwendige Standardwissen, um sowohl die Abstimmung der einzelnen Komponenten untereinander als auch mit den Wünschen des Kunden zu gewährleisten.

Ein besonders guter Verkäufer zeichnet sich darüber hinaus dadurch aus, daß er auch dann kompetent berät, wenn er mit einem Problem das erste Mal konfrontiert wird bzw. wenn sein Kunde

(4)

nt-neu pone nt-Klass Event-Typen ind vidualisierte Eve t

(Standard-)Events

technischer Kern Feier/Party

Reeis

Starter Pack Sonstige

Fest-Typ A ("Großer- eignis")

Fest-Typ C ("Traute Zweisam-

keit") Fest-Typ B ("Geselliges Beisammen-

sein") Fest-Typ D

("Business")

Reise-Typ A ("Happy Holiday")

Reise-Typ B ("Geschäfts- reise")

Paket-Typ C ("Sport")

Paket-Typ B ("Tierisches")

Paket-Typ A ("Mensch-

liches") Paket-Typ D

("Hobby") ...

Tau fe Kon

firmation Ho chze

it ...

Brun ch

Grillp arty

Sp iele aben

d

... Rendez-vous Versöhnung Jahrestag Jub

iläu

m

lgrfoE _W

n.f eih

reie ...

...

Abb. 1 – Kern-Schalen-Modell der Wissensbasis des Event Advisory System

ein „Individualist“ ist. In dieser Situation reicht ihm sein „normales“ Standardwissen nicht mehr aus, er muß menschliche Intuition und Kreativität einbringen. Eine Möglichkeit wäre beispielsweise, daß er seine Erfahrungen aus früheren, in Bezug auf das Problem und/oder die Person ähn- lich gelagerten Beratungsfällen aufgreift und damals vorgeschlagene Lösungskomponenten zu einem völlig neuen und individuellen Produktbündel zusammenfügt.

Will man einen ähnlichen Service in ein Online-Beratungssystem integrieren, so läßt sich dies für den Part des Fachverkäufers noch vergleichsweise einfach bewerkstelligen. Sein Standardwissen muß in einer Weise abgebildet werden, daß es sich auf möglichst viele Beratungsfälle anwenden läßt. Zu beachten ist dabei, daß die Wissensbasis aus Gründen der Rechenzeit nicht zu groß oder komplex sein darf und daß sie sich jederzeit möglichst einfach verändern bzw. erweitern läßt.

Um die zu erwartende Vielfalt potentieller Problemvarianten auf ein handhabbares Maß zu reduzieren, wurde das Hilfskonstrukt des Event eingeführt. Es handelt sich dabei um möglichst all- gemein gehaltene, mehr oder weniger komplexe Problemfälle, die man auch als Szenarios „norma- ler“ Kundenprobleme bezeichnen könnte. Über die Definition von Problemklassen und -typen lassen sich die Events in eine hierarchische Ordnung bringen. Diese Hierarchie verkörpert die Struktur der Wissensbasis des Beratungssystems und wird im folgenden in Form eines sogenannten Kern- Schalen-Modells dargestellt (siehe Abb. 1):

Im Zentrum befinden sich die Event-neutralen Komponenten, also beispielsweise der Event- Editor (siehe Abschnitt 3.2), der Such-Agent oder die Benutzerprofile. Es handelt sich hier sozusa- gen um den technischen Kern des Systems, auf dem sämtliche Events aufbauen.

Die Konkretisierung der Events beginnt auf der Stufe von Event-Klassen, die noch eine sehr grobe Granularität aufweisen. Auf dieser Ebene lassen sich solche Event-Eigenschaften festlegen, die später für sämtliche Events einer Klasse, also über alle Hierachiestufen hinweg, gelten sollen.

Beispiele für Event-Klassen sind „Feier/Party“, „Reise“ oder „Starter Pack“. Für die Klasse „Reise“

würde man auf dieser Stufe als spezifische Eigenschaft beispielsweise die Zusammensetzung des späteren Objektsystems festlegen, etwa aus „Transportmittel“, „Unterkunft“ und „Unterhaltungs- programm“. Diese Eigenschaft wird automatisch auf alle Events der Klasse „Reise“ weitervererbt.

Bei Bedarf lassen sich Eigenschaften aber auch zwischen den Klassen austauschen.

Die Event-Klassen un- terteilen sich weiter in Event-Typen, wie z. B.

„Großes Fest“, „Geselliges Beisammensein“, „Traute Zweisamkeit“ oder „Busi- ness“ innerhalb der Klasse

„Feier/Party“. Die verschiedenen Cluster dieser Stufe unterscheiden sich anhand ihrer spezifischen Eigen- schaften. So plant beispielsweise der Event-Typ

„Traute Zweisamkeit“ automatisch für ein Paar, wohin- gegen das „Große Fest“

nach näheren Angaben be- züglich der Zahl der Teil- nehmer bzw. Gäste verlangt.

(5)

Innerhalb der nächsten Schale findet man schließlich die konkreten (Standard-) Events, welche die Schnittstelle zwischen dem EASY und den Benutzern bzw. den Anbietern bilden. Beim Start des Beratungsdialoges werden diese Events initialisiert, also mit vom Event-Ersteller vorgegebenen Standardwerten versehen. Schritt für Schritt nimmt der Benutzer dann eine Anpassung bzw. Individualisierung des Events vor, indem er ihn „bearbeitet“ (siehe Abschnitt 3.3).

Der angepaßte Event liefert am Ende ein Anforderungsprofil, welches die Grundlage bei der Produktsuche in den Datenbanken der Anbieter ist.

Den äußeren Ring des Kern-Schalen-Modells bilden die Ergebnisse der Beratungsarbeit des EASY, d. h. die individualisierten (historischen) Events. Diese werden in einer Fallbasis abgespei- chert und dienen dem System als zusätzliches, kundenspezifisches Wissen, das ständig aktualisiert und erweitert wird. Auf die Fallbasis kann das Beratungssystem immer dann zurückgreifen, wenn ein Kunde ein vom Standard abweichendes Objektsystem kaufen möchte. Sie stellt eine Möglich- keit dar, wie man mittels wissensbasierter Elemente die Kreativität eines besonders guten Verkäu- fers in gewissem Umfang nachempfinden kann.

3.2 Aufbau und Pflege der Wissensbasis mit dem Event-Editor EVE

Der Aufbau der Wissensbasis erfolgt sukzessive, d. h., je nach Sortiment der Mall werden neue Events hinzugefügt oder alte Events entfernt. Damit das Beratungssystem weiterhin zuverläs- sig arbeitet, ist bei Änderungen immer darauf zu achten, daß die einmal festgelegte Struktur der Events bei- bzw. eingehalten wird.

Weiterhin ist davon auszugehen, daß an der Gestaltung der Wissensbasis verschiedene Perso- nen bzw. Institutionen mit unterschiedlichem inhaltlichen und technischen Know-how beteiligt sind. So ist es beispielsweise vorstellbar, daß der Mall-Betreiber den Kern des Systems (bis hin zu den Event-Typen) pflegt und daß sich einzelne Anbieter - je nach Fachbereich - um die Erstellung und Verwaltung der Standard-Events kümmern.

Das EASY verfügt deshalb über eine grafikgestützte und menügesteuerte Entwicklungs- und Verwaltungskomponente, den sogenannten Event-Editor (EVE). Das Tool ähnelt in seiner Bedie- nung und Funktionalität einem herkömmlichen Grafik- oder Textverarbeitungsprogramm und erlaubt es somit auch Personen ohne Programmierkenntnisse, einen Event anzulegen. Durch den Editor bleibt das Beratungssystem flexibel, denn es läßt sich jederzeit erweitern oder modifizieren.

Die Entwicklung eines Events vollzieht sich üblicherweise in zwei Schritten. Dementspre- chend umfaßt der Editor zwei unterschiedliche Komponenten: das Präsentations- und das Logikmo- dul.

Mit Hilfe des Präsentationsmoduls werden das Layout (Benutzungsoberfläche) und die äu- ßere Struktur eines Events festgelegt. Beispielsweise definiert der Event-Ersteller Seiten, Abschnitte und Seitenkomponenten, um einzelne Themenbereiche voneinander abzugrenzen und den Event übersichtlich zu gliedern. Einzelne Seiten gestaltet er, indem er dort Texte, Grafiken und Bilder plaziert.

Das Logik- oder Semantikmodul sorgt für das eigentliche Problemlösungswissen und damit für die „Intelligenz“ des Systems. Als Kernstück jeder Beratung werden hier die Fragen und Ant- worten des späteren Beratungsdialoges festgelegt. Zu unterscheiden ist dabei zwischen Kann- und Mußfragen (siehe Abschnitt 3.3).

Stellt man einem Kunden zu viele Fragen, so läuft man als Verkäufer schnell Gefahr, ihn zu verärgern oder gar zu vertreiben. Ein guter Verkäufer fragt folglich nur wenige, für seinen Bera- tungserfolg ganz wesentliche Informationen ab und leitet aus den Antworten weitere Sachverhalte implizit ab. Diese Verhaltensweise läßt sich beim EASY durch die Definition von Abhängigkeiten zwischen den Fragen nachbilden (siehe Abb. 2).

(6)

Frage 1 Antwort 1a Antwort 1b Antwort 1c

Frage 4

Antwort 4a Antwort 4b vom System

vorbesetzt

Frage 5 Antwort 5a Antwort 5b Antwort 5c Antwort 5d (1) Einfache Abhängigkeit

Frage 1 Antwort 1a Antwort 1b Antwort 1c

Frage 4

vorbesetzt Frage 6

Antwort 6a Antwort 6b Antwort 6c Antwort 6d (2) Mehrfache Abhängigkeit

vom System vorbesetzt

Frage 1 Antwort 1a Antwort 1b

Antwort 1c Frage 4

vorbesetzt

Frage 3 Antwort 3a Antwort 3b Antwort 3c Antwort 3d

(3) Gekoppelte Abhängigkeit

und

Abb. 2 – Abhängigkeiten innerhalb des Fragennetzes

Abb. 3 – Festlegung der Anforderungsprofile

Abhängigkeit bedeutet in diesem Fall: Die Beantwortung einer (entscheidenden) Frage führt dazu, daß eine oder mehrere andere (weniger wichtige) Antworten vom System automatisch mit dazu korrespondierenden Werten vorbesetzt werden (regelbasierter Ansatz). Gibt eine Kundin beispielsweise an, daß sie ein blaues Kostüm kaufen möchte, so setzt das System die Art der Schuhe auf elegante Pumps sowie deren Farbe ebenfalls auf blau. Voraussetzung ist jedoch immer, daß der Kunde die betroffenen Fragen nicht schon explizit beantwortet hat (hätte unsere Kundin also bereits angegeben, daß sie gelbe Halbschuhe möchte, würde das System dies nicht mehr ändern). Auch darf der Benutzer automatisch vorbesetzte Ant- worten jederzeit an seine eigenen Wünsche anpassen. Harmonieren einzelne Antworten nicht miteinander (z. B. Kundin wählt zum roten Kostüm gelbe Schuhe), so beschränkt sich das System auf einen entsprechenden Hinweis. Auch bei nicht-op- timalen Konfigurationen soll der Kunde nur bera- ten, nicht aber „bevormundet“ werden.

Weiterhin dient das Logikmodul des Editors dazu, die sogenannten Anforderungsprofile fest- zulegen. Die Antworten des Benutzers müssen später in konkrete Produkteigenschaften umgesetzt werden, damit der Such-Agent die Datenbanken der Anbieter nach geeigneten Produkten „durchfor- sten“ kann. Der Event-Ersteller legt also fest, auf welche Produktattribute sich eine bestimmte Ant- wort auswirkt und welche Ausprä-

gungen die Attribute dann anneh- men sollen (siehe Abb. 3). Die entsprechenden Werte werden in Anforderungsprofilen abgelegt, und zwar diejenigen Ausprägun- gen, die nur eine einzige Produkt- gruppe betreffen, im jeweiligen Gruppenprofil (z. B. Schuhgröße

„39“ nur im Profil für Schuhe) und diejenigen Werte, die den gesamten Event betreffen, im Gesamtlösungsprofil (z. B. Hoch- zeitsstil „klassisch“, da u. a. rele- vant für Ausstattung von Braut und Bräutigam oder Unterhal- tungsprogramm).

Der Event-Editor läßt sich völlig unabhängig vom restlichen System als (Offline-)Stand-alone- Anwendung einsetzen. Der fertige Event wird in Form einer Skript- datei auf den Server übertragen und dort automatisch in die Wis- sensbasis integriert.

(7)

Abb. 4 – Abschnitte und Seite des Events „Hochzeit“

3.3 Ablauf eines Beratungsdialoges mit dem Advanced Advising Module ADAM

Dieser Abschnitt soll zeigen, wie ein typischer Beratungsprozeß mit dem Advanced Advising Module (ADAM) abläuft. Zum besseren Verständnis sind die einzelnen Schritte anhand eines Bei- spiels erklärt: Organisation einer Hochzeitsfeier.

Nach Aufruf der EASY-Shopping-Home-Page erscheint im Internet-Browser auf dem Client- Rechner das Hauptmenü. Daraus wählt der Benutzer den Event „Hochzeit“ aus. Die entsprechenden Event-Seiten werden als Applet in den Browser geladen, der Client holt sich die zur Ausführung benötigten Java-Klassen, und die Anwendung startet. Bei seiner Initialisierung baut das Programm anschließend eine Verbindung zum Server auf und greift auf die Wissensbasis zu. Von dort erhält der Client alle benötigten Präsentations- und Logikinformationen.

Der Event „Hochzeit“ umfaßt gegenwärtig die Themenbereiche (Abschnitte) „Allgemeines“,

„Garderobe der Braut“, „Garderobe des Bräutigams“, „Trauringe“ sowie „Fahrt zur Kirche“ (siehe Abb. 4). Je nach Komplexität des zu behandelnden Themas (z. B. Garderobe der Braut) umfaßt ein Abschnitt eine oder mehrere Seiten, auf denen der Kunde die Fragen (z. B. zu Brautkleid, Brautschuhen, Kopfschmuck und Accessoires) findet. Als Orientierungshilfe für den Benutzer spie- geln die Art und die Reihenfolge der Fragen ihre Bedeutung für das Beratungsergebnis wider:

• Sogenannte Mußfragen, die der Kunde unbedingt beantworten sollte, sind farb- lich besonders gekenn- zeichnet (z. B. Stil der Hochzeit, verfügbares Bud- get). Ohne diese Informa- tionen ist eine individuelle Beratung nicht möglich. Das System kann lediglich einen Standardvorschlag unterbrei- ten.

• Wichtige Fragen sind so auf den Seiten plaziert, daß sie der Benutzer jederzeit ein- sehen kann. Es bleibt jedoch ihm überlassen, welche An- gaben er machen möchte.

Für unbeantwortete Fragen übernimmt das System ent-

weder die Standardeinstellungen oder aber Werte, die sich aufgrund von Abhängigkeiten aus den Antworten auf hoch korrelierte Fragen ableiten lassen (siehe Abschnitt 3.2). Entscheidet sich eine Kundin beispielsweise für eine klassische Hochzeit, so muß sie Fragen zur Garderobe der Braut eigentlich nicht mehr beantworten. Das System setzt automatisch die Art des Braut- kleides auf „langes Kleid“, die Farbe auf „weiß“ und den Kopfschmuck auf „Schleier“. Ände- rungen seitens der Kundin sind aber jederzeit erlaubt (siehe Abschnitt 3.2). Je mehr Fragen ein Benutzer beantwortet, desto besser kann das System das Produktbündel auf seine individuellen Bedürfnisse zuschneiden.

• Detailfragen haben die niedrigste Priorität und erscheinen deshalb nur auf Anforderung des Be- nutzers in einem Pop-up-Fenster (siehe Abb. 4). Sie dienen ausschließlich dem „Feintuning“ des Produktbündels.

(8)

Hat der Anwender das gesamte oder einen Teil des Fragennetzwerkes bearbeitet, kann er einen Lö- sungsvorschlag abrufen. Man muß aber immer damit rechnen, daß Kunden besonders wenig Zeit haben oder sehr ungeduldig sind. Folglich sollte die Beratung auch dann zu einem Ergebnis kom- men, wenn wichtige Informationen noch fehlen. In diesen Fällen greift das System auf eine Fallba- sis (MS-Access-Datenbank) zurück, in der sämtliche historische (individualisierte) Events abge- speichert sind, und sucht dort mit Hilfe der Methode des Nearest Neighbor Matching nach mög- lichst ähnlichen Beratungssituationen (Case-based Reasoning), aus denen es dann die fehlenden In- formationen übernimmt.

Im nächsten Schritt übersetzt das Beratungssystem die Antworten des Benutzers in die entsprechenden Anforderungsprofile (siehe Abschnitt 3.2). Wünscht der Kunde lediglich eine Pro- duktsuche, so übergibt ADAM nur das Profil der betroffenen Produktgruppe an den Such-Agenten (z. B. für Produktgruppe Trauringe „gelbgold“, „poliert“, „diamantenbesetzt“). Wurde dagegen ein Systemvorschlag (Produktbündel) angefordert, erstellt das System sämtliche Gruppenprofile sowie ein Gesamtlösungsprofil.

Zur Verkürzung der Rechenzeit konsultiert die Anwendung zunächst die Fallbasis, um dort einen identischen oder aber zumindest sehr ähnlichen Beratungsfall zu finden, dessen Ergebnis sie übernehmen kann. Nur wenn diese Suche erfolglos bleibt, wird der Such-Agent aktiviert. Er über- nimmt die aus den Anforderungsprofilen abgeleiteten Produktattribute und führt auf dieser Basis die entsprechenden Datenbankabfragen durch.

Anschließend werden das fertige Produktbündel sowie Alternativen zu den einzelnen Kom- ponenten am Bildschirm präsentiert. Der Kunde kann den Lösungsvorschlag entweder akzeptieren oder ihn noch besser an seine Vorstellungen anpassen, indem er bestimmte Teilleistungen des Bün- dels entfernt bzw. austauscht.

In den meisten Fällen ist der Beratungsdialog mit der Präsentation des endgültigen Produkt- bündels beendet. Jedoch kann ein Event so umfangreich oder komplex sein, daß der Kunde weiter- gehende Dienstleistungen wünscht. Im Fall der Hochzeitsvorbereitungen könnte das Beratungssy- stem beispielsweise um Module für das Management der verschiedenen Termine oder für die Pla- nung der Tischordnung ergänzt werden. Darüber hinaus bieten sich hier vor allem „Tips und Tricks“ rund um das Thema Hochzeit oder Expertenbefragungen per E-Mail als Zusatzdienste an.

Die Planung und Organisation einer Hochzeit erstreckt sich - wie andere Events möglicher- weise auch - über einige Wochen oder gar Monate. Deshalb ist es durchaus wahrscheinlich, daß die Zusammenstellung eines Produktbündels nicht innerhalb einer einzigen Sitzung, sondern mit mehreren Iterationen erfolgt. Ein erster Beratungsdialog könnte sich etwa mit der Auswahl geeigneter Räumlichkeiten für die Hochzeitsfeier sowie der Suche nach einem Brautkleid beschäftigen. Mit weiteren Sitzungen dazwischen würde der ganze Beratungsprozeß dann vielleicht mit der Zusam- menstellung der Blumendekorationen und der Entscheidung für einen Fotografen enden. Eine solche schrittweise Konfiguration eines Objektsystems macht es erforderlich, daß „Zwischenzustände“

für die weitere Verwendung in den folgenden Sitzungen erhalten bleiben. Setzt der Benutzer zu einem späteren Zeitpunkt die Beratung fort, kann er sich über den aktuellen Zustand seines Produkt- bündels informieren und hat die Gewißheit, daß - falls bereits Teilkomponenten bestellt wurden - auch alle weiteren Leistungen dazu passen werden.

(9)

WWW- Server WWW- Server

Client

Auswahl des Event 1

Applet 3

Wissens- basis

Anforderungsprofil 4

Produkt- attribute

Suchagent

Fallbasis

Lösungsbündel 8

Suche nach ähnlichen Fällen 2 5

Such- 6 ergebnisse 7

Logik des Event

Abb. 5 – Architektur des Event Advisory System

Abbildung 5 zeigt die Architektur des Prototypen und faßt den gesamten Prozeß des EASY bzw. Event Shopping noch einmal zusammen. Das System wurde mit dem Java Language Kit sowie einem zu- sätzlichen grafischen Toolkit von SUN Microsystems entwickelt. Das Front-end- Applet kann mit jeder neueren Browser- Software (z. B. Netscape Navigator ab Ver- sion 4.0x) geladen werden.

Sämtliche Datenbankaktivitäten, nämlich Zugriffe auf die Wissens- und die Fallbasis, finden auf dem Server statt. Zu diesem Zweck wurde eine Client-Server- Architektur realisiert, die auf einem Nativ JDBC-SQL Pathway basiert. Werden die Event-Klassen durchsucht oder editiert, erfolgt jeweils ein interaktiver Reload der betroffenen Datenbankinhalte.

4 Erste Erfahrungen und weitere Forschung

Zum gegenwärtigen Zeitpunkt umfaßt der Prototyp des Event Advisory System den voll funktionsfähigen Event-Editor sowie das Beratungsmodul (ohne Fallbasis) mit den drei Events

„Hochzeit“, „Reitausrüstung“ und „Geschäftsreise“.

Der Editor erwies sich als ein sehr mächtiges Tool, mit dessen Hilfe sich die besagten Events - trotz ihrer völlig unterschiedlichen Themenbereiche - relativ einfach und schnell anlegen ließen. Allerdings sollte sich der Event-Ersteller gerade wegen dieser „Mächtigkeit“ die Mühe machen, seinen Event vorher genau zu planen (z. B. Aufbau der Seiten, Abhängigkeiten zwischen den Fragen), da es ihm dann wesentlich leichter fällt, eine übersichtliche Struktur sowie eine klare Lo- gik zu erreichen.

Ein zentrales Anliegen bei der Umsetzung des Beratungssystems war es, Einzelheiten über den Bedarf eines Kunden abzufragen und ein entsprechendes Produktbündel für ihn zusammenzu- stellen, ohne ihn dabei mit zu vielen Fragen (beispielsweise zu jeder einzelnen Komponente des Bündels) „behelligen“ zu müssen. Es galt also, das Verhältnis zwischen Fragen, die der Benutzer explizit beantworten muß, und Fragen, auf deren Antworten das System aufgrund seines Wissens schließen kann, möglichst ausgewogen zu gestalten. Dieses Ziel konnte mit Einführung von Abhän- gigkeiten (siehe Abschnitt 3.2) erreicht werden. Bereits mit wenigen Auskünften seitens des Kun- den ist das System in der Lage, einen Lösungsvorschlag zu generieren. Mit Fertigstellung der Fall- basis soll sich die Leistungsfähigkeit der Anwendung in dieser Hinsicht noch weiter verbessern.

Das Konzept des Kern-Schalen-Modells wurde für die Wissensbasis in Form einer hierarchi- schen Event-Bibliothek umgesetzt. Der Event-Ersteller wählt ein fertiges Objekt aus den verfügba- ren Klassen bzw. Typen aus und paßt es dann mit Hilfe des Editors an seine spezifischen Bedürf- nisse an. Die Entwicklungsarbeit beschränkt sich somit auf ein absolutes Mindestmaß, und es ist gewährleistet, daß jeder Event im Kern über eine einheitliche Struktur verfügt.

Das Event-Shopping-System befindet sich noch nicht im praktischen Einsatz, d. h., es konnte bisher nicht adäquat evaluiert werden. Dennoch hoffen wir, daß es uns gelungen ist, eine Online- Anwendung zu entwickeln, die einige der momentanen Probleme von Electronic Shopping Malls (siehe Abschnitt 1) überwinden hilft. Als potentielles Einsatzgebiet scheint uns beispielsweise ein regionaler elektronischer Marktplatz (etwa im Städtedreieck Nürnberg-Fürth-Erlangen) mit über-

(10)

wiegend kleinen und mittelständischen Anbietern geeignet. Speziell für diesen Anwendungsbereich wurde der Hochzeits-Event entwickelt. So führen beispielsweise Brautmodengeschäfte in der Regel nur einen kleinen Bruchteil einer bestimmten Kollektion vor Ort. Eine Kundin ist also darauf angewiesen, sich anhand von Papierkatalogen und Prospekten einen Überblick zu verschaffen und eine erste Vorauswahl zu treffen, die ein Laden dann erst für sie bestellen muß. Mit dem EASY-Be- ratungsmodul kann diese Vorselektion bequem zu Hause erfolgen. Anschließend teilt die Mall der Kundin mit, welches (physische) Geschäft die ausgewählten Kleider für sie zur Anprobe bereithal- ten wird, nachdem diese vom Hersteller eingetroffen sind. Der entsprechende Laden vereinbart dann einen Termin mit der Kundin. Im Falle des Hochzeits-Events findet also eine Vermischung statt von Einkaufsvorgängen, die noch einer physischen Begutachtung bedürfen (z. B. Garderobe), und solchen, die völlig virtuell abgewickelt werden können (z. B. Reservierung einer Lokalität, Vereinbarung eines Termins beim Fotografen, Buchung eines Mietwagens). Eine regionale Aus- richtung der Mall entschärft in gewisser Weise auch das Problem, wie am besten zu verfahren ist, wenn mehrere Anbieter im elektronischen Einkaufszentrum dasselbe Produkt zu ähnlichen Kondi- tionen anbieten. Das System stellt dann diese Anbieter (bzw. ihre Produkte) gleichrangig neben- einander und überläßt dem Kunden die Entscheidung für eine der Alternativen. Als Entschei- dungshilfe bieten sich hier detaillierte Informationen über den jeweiligen Anbieter an, etwa Garan- tiefristen, Kundenservice oder Liefergeschwindigkeit.

Der Hauptvorteil des EASY-Systems dürfte für den Kunden darin bestehen, daß er eine kom- petente Online-Beratung nicht mehr nur zu einer bestimmten Produktkategorie erhält, sondern zu einem ganz konkreten Problem, also völlig losgelöst von den jeweiligen Produkten und Anbietern.

Es handelt sich hier um eine Form der Beratungsleistung, die man beim traditionellen Einkauf nur in Fachgeschäften oder aber gegen ein entsprechendes Beraterhonorar erhält. Einzige Vorausset- zung für eine erfolgreiche Nutzung des Systems ist die Bereitschaft des Kunde, etwas Zeit zu inve- stieren sowie einige Informationen hinsichtlich seiner Person und seines Problems preiszugeben.

Ein Anbieter, der sich am EASY Shopping (bzw. in diesem Fall EASY Selling) beteiligt, hat die Chance, seine Umsätze durch Kaufprozesse zu steigern, die eigentlich von einem anderen Mit- glied der Mall „getriggert“ wurden. Nutzt beispielsweise ein Kunde das Beratungsmodul, um über das virtuelle Reisebüro der Mall den Flug für seine Geschäftsreise zu buchen, so macht ihn das Sy- stem zudem auf die Dienste eines „House Sitter“ oder auf die knitterfreien Anzüge eines Herren- ausstatters aufmerksam. Um die Entscheidung des Kunden für das komplette Bündel positiv zu be- einflussen, könnten sich die drei Anbieter darauf einigen, ihm einen entsprechenden Preisnachlaß zu gewähren.

Im weiteren Verlauf des Projektes sollen die Wissensbasis ausgebaut und das Beratungsmo- dul mit einer Case-based-Reasoning-Komponente sowie einer Fallbasis ausgestattet werden. Um den Beratungsdialog noch besser an die individuellen Bedürfnisse der Kunden anzupassen, wollen wir das EASY um Elemente der Benutzermodellierung erweitern. Auf diese Weise lassen sich In- formationen über das Kaufverhalten der Kunden sowie über die Produkte, die sie in der Vergan- genheit gekauft haben, in ihren Benutzerprofilen abspeichern und neu zu konfigurierende Bündel darauf abstimmen. Darüber hinaus können die Profile verschiedener Benutzer auf mögliche Ähn- lichkeiten hin untersucht und daraus entsprechende Empfehlungen abgeleitet werden, mit denen das System dann einen Event initialisiert (Recommender System; vgl. [Mert97]).

(11)

Literatur

[Brec91] Brecheis, D.: Marketing für Objektsysteme, Augsburg 1991.

[Heid98] Heidingsfelder, M.: State of the Art (SOTA) zu Electronic Shopping Malls, Diplomar- beit, Nürnberg 1998.

[Mert97] Mertens, P.: Recommender Systems, WIRTSCHAFTSINFORMATIK 39 (1997) 4, S.

401-404.

[Meye90] Meyer, P. W.: Der integrative Marketingansatz und seine Konsequenzen für das Mar- keting, in: Meyer, P. W. (Hrsg.): Integrierte Marketingfunktionen, 2. Aufl., Stuttgart u.

a. 1990, S. 13-30.

[PBK98] Online-Produktberatung, http://131.188.180.167/www_pbk, 15.5.98.

[Pers98] Personalogic Product Showcase, http://www.personalogic.com/home/demo/demo.stm, 31.5.98.

[SaBS95] Sarkar, M. B., Butler, B. und Steinfield, C.: Intermediaries and Cybermediaries: A Continuing Role for Mediating Players in the Electronic Marketplace, in: Journal of Computer-Mediated Communication 1 (1995) 3, http://jcmc.huji.ac.il/vol1/issue3/sarkar.html, 15.5.98

[ScHM98] Schumann, P., Horstmann, R. und Mertens, P.: Event-Shopping: A Value-Added Service for Electronic Malls, in: Lee, J., Kim, S., Whinston, A. und Schmid, B.

(Hrsg.): ICEC '98, Proceedings of the First International Conference on Electronic Commerce '98, 6.-9. April 1998 in Seoul, Korea, S. 98-104.

[Stell98] Steller, T.: Entwicklung einer Beratungskomponente zur Lösung komplexer Kunden- probleme in einer Electronic Shopping Mall, Diplomarbeit, Erlangen 1998.

[Yaho98] Yahoo!, http://www.yahoo.com/Business_and_Economy/Companies/Shopping_Centers/

Online_Shopping, 15.5.98.