Das Ziel dieser Projektgruppe ist es, ein System zu konzipieren und realisieren, das personalisierte, internetbasierte Handelsszenarien abbildet

Situation

Wir wollen uns vorstellen, wir wären ein Kartenanbieter (analog zu Payback, Miles&More) oder ähnlichem. Wir wollen ein neues Szenario für die Nutzung von Kundenkarten realisieren, die von mehreren Händlern genutzt werden, um dieses später einem Händler "zu verkaufen".

Kartensysteme

Kartensysteme bieten Vorteile für Händler, die Anbieter von Kartensystemen sowie für den Kunden. Kunden haben die Möglichkeit, ein personalisiertes Informations- und Warenangebot in Anspruch zu nehmen. Dieses wird dadurch ermöglicht, dass Handelstransaktionen von partizipierenden Kunden von den Händlern an den entsprechenden Kartenanbieter (Card-Provider) übermittelt werden. Dafür erhält der Händler vom Card-Provider ein Entgelt. Der Kartenanbieter analysiert nun die Kundendaten . Heute beschränken sich die von den Kartenanbietern durchgeführte Analysen auf die Segmentierung von Kunden in Kundengruppen (Bsp.: Amazon). Händler sind bestrebt, Ihren Kunden ein möglichst gutes Angebot zu machen. Dies können sie heute leisten, indem sie von Kartenanbietern Analyseergebnisse in Form von Kundengruppenbeschreibungen und Kundengruppenbeschreibungen einkaufen. Dies kann z.B. unter Verwendung eines Publish/Subscribe Ansatzes erfolgen. Diese gekauften Informationen kann der Händler nun nutzen, um Kunden kundengruppenzentrierte Angebote z.B. über das Internet unterbreiten zu können.

Für alle partizipierenden Gruppen ergeben sich Vorteile hieraus: die Kunden erhalten ein auf sie zugeschnittenes Informations- und Warenangebot, der Händler kann seine Kunden besser an sich binden (?gläserne Kunden?) und der Kartenanbieter verdient durch Verkauf seiner Analyseergebnisse. Wirklich verdienen jedoch in der Regel und die Kartenanbieter und die Händler, da die Kunden ihre Daten für eine geringe Gegenleistung bereitstellen. Für den Kunden ergibt sich als weiteren Nachteil, dass er u.U. keine Geheimnisse vor seinem Händler haben kann. Der Händler hingegen begibt sich durch die Einführung von Kartensystemen in eine Abhängigkeit zu dem mit ihm kooperierenden Kartenanbieter. Für Kunden und Händler kann es ferner von Nachteil sein, dass ihre Daten nun in einem Informationsverbund gespeichert werden, auf den sie nur beschränkt Einfluss nehmen können. Wenn z.B. ein Kartenanbieter einer Branche mit einem Händler kooperiert, sollte er z.B. (auch schon technisch) daran gehindert werden, diese Daten einem Konkurrenten dieses Händlers zukommen zu lassen. Nachteile für den Kartenanbieter ergeben sich eigentlich nicht. Aus diesem Grunde wollen wir uns in die Rolle eines Kartenanbieters versetzen.

Ein Handelsszenario, wie wir es betrachten wollen, kann den hier eingesehen werden.

Um ein System entwickeln zu können, dass von einem Kartenanbieter angeboten wird, ist es nötig, sowohl die Seite des Kartenproviders als auch die Rolle des Händlers zu betrachten . Aus diesem Grund wollen wir diese Rollen einmal genauer untersuchen:

Händler

Ein Händler partizipiert in der Architektur, die wir betrachten wollen, in zweierlei Formen von Handelsbeziehungen. Er handelt einerseits mit Kunden durch den Verkauf von Gütern. Andererseits verkauft er dem Kartenanbieter Informationen und kauft Analyseergebnisse von diesem .Er sammelt, und speichert alle Daten (Verkaufsdaten, Interessenten, Web-logs, etc.), die mit seinem Geschäft zu tun haben. Einen kleinen Teil dieser Daten (die Daten, die mit der angebotenen Karte zu tun haben, i.d.R. die Informationen des Kassenbons) übermittelt er an den Kartenanbieter. Ihm stehen jedoch weit mehr Informationen zur Verfügung, die er zu Individualisierung seines Angebotes nutzen könnte. Hierbei könnte er z.T. auf die vom Kartenanbieter gelieferten Analyseergebnisse zurückgreifen. Kennt er die Präferenzen seines Kunden als Individuum (Tante-Emma-Laden-Metapher), so kann er z.B. in einem elektronischem Shopsystem eine personalisierte Präsentation seiner Waren vornehmen.

Kartenanbieter

Der Händler geht Handelsszenarien mit Händlern und Endkunden ein. Um an die Daten zu kommen, die für die Identifikation von Kundengruppen benötigt werden, ?bezahlen? Kartenanbieter Kunden in Form von Prämien (Punktesysteme, Prämien, u.ä.). An die Daten von Kunden kommen die Kartenanbieter durch die Händler, die einen Entgelt (z.B. in Form von Analyseergebnissen) für das Processing der Daten erhalten. Der Kartenanbieter sammelt die Daten, integriert und bereinigt sie und speichert sie dauerhaft. Anhand dieser aufbereiteten Daten ist der Kartenanbieter in der Lage, Analysen verschiedener Art durchzuführen .Hierzu zählen die Warenkorbanalyse, die Kundengruppierung, die Konzeptbeschreibung sowie die Herleitung von Regeln. Ein Beispiel für solch eine Regel (fiktiv!?): ?Ein junger Vater Ende 20, der in einem Supermarkt Pampers kauft, kauft mit einer Wahrscheinlichkeit von x % auch einen 6er Träger Bier?. Die Ergebnisse dieser Analysen kann er nun Händlern zu Kauf anbieten. Die an diesem Handel teilnehmenden Personen können hierbei andere sein als die, die sich an der Datenlieferung beteiligt haben.

Ziele der Projektgruppe

Die Aufgaben der Projektgruppe gliedern sich in zwei Aufgabengebiete:

• Herleitung personalisierter Daten
  • Kundensegmentierung: Wie kann ich (integrierte) Kundendaten mehrerer Händler nutzen, um Kunden in Gruppen einzuteilen? (Card-Provider)
  • Individualisierung: Wie kann ich aus den Daten individuelle, interessante Angebote für den Kunden erstellen? (Händler)
• Internetbasierte, individualisierte Präsentation von Daten
  • Wie können Händler individuelle Angebote unterbreiten? Der Kunde soll hierbei personalisierte Angebote erhalten.
  • Für einen Händler wollen wir exemplarisch ein ?Shopsystem? konzipieren und realisieren.

Was bieten wir?

Spaß, spannendes Thema und das Arbeiten mit aktuellen Techniken.

• H.-J. Appelrath
• Heiko Tapken
• Ralf Krause

• Aktive Mitarbeit bei der Analyse, Konzeption und Implementierung
• Erfüllung übertragender Aufgaben
• Präsentation und Ausarbeitung von Seminarvorträgen
• Erstellung von Zwischen- und Endbericht sowie anfallenden Dokumentationen

• SUN-Workstations
• DEC-Workstations
• PCs unter WindowsNT und Windows 2000

• Netscape Navigator
• Microsoft Explorer
• Java Developers Kit 1.3 (JDK)
• Bean Developers Kit (BDK)
• JBuilder 4 bzw. JDeveloper 9i
• Oracle 9i, Oracle 9i Application Server
• CVS (Versionskontrolle)
• Rational Rose (UML)
• Perl (zur Realisierung von CGI-Skripten, soweit notwendig)
• LaTeX (für die Dokumentation)

• www.diko-project.de