Projektgruppendokumentation

Transcription

Fakultät II: Department für Informatik - Wirtschaftsinformatik /
Very Large Business Applications (VLBA)
Projektgruppe der Wirtschaftsinformatik
Projektgruppendokumentation
SCRM
5. November 2011
Betreuer:
Ammar Memari (VLBA)
Benjamin Wagner vom Berg (VLBA)
Mitglieder der Projektgruppe:
Xin Huang
Sven Kölpin
Carl Mahnke
Alain Marcel Ngufack Temgoua
Marc Petersen
David Rummel
Daniel Schnieders
Alexander Spennemann
Daniel Stamer
Timo von der Dovenmühle
Yi Wei
Inhaltsverzeichnis
I
Einführung
1
1
Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Motivation der Projektgruppe ...........................................................
1.2 Zielsetzung der Projektgruppe ...........................................................
1.3 Lizenzbedingungen ..........................................................................
1.4 Aufbau der Dokumentation...............................................................
3
3
4
5
7
2
Projektorganisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Projektinterne Aufgabenbereiche........................................................
2.1.1 Projektmanager .....................................................................
2.1.2 Windows-Serveradministrator...................................................
2.1.3 Linux-Serveradministrator .......................................................
2.1.4 Webseitenbeauftragter ............................................................
2.1.5 Testbeauftragter ....................................................................
2.1.6 Dokumentenbeauftragter .........................................................
2.1.7 Finanzbeauftragter.................................................................
2.1.8 Kommunikationsbeauftragter ...................................................
2.2 Vorgehensweise und Roadmap ...........................................................
2.3 Software ........................................................................................
2.3.1 Serverseitige Software .............................................................
Redmine...............................................................................
MYSQL ...............................................................................
SQL Server2008 R2 ................................................................
Microsoft Dynamics CRM Online 2011.......................................
2.3.2 Clientseitige Software..............................................................
Eclipse IDE for Java Developers ...............................................
ArgoUML.............................................................................
Microsoft Project 2010 ............................................................
Microsoft Visual Studio 2010....................................................
SQL Server 2008 Management Studio - SSMS .............................
Protege 4.1 ...........................................................................
SVN Client ...........................................................................
LATEX ..................................................................................
9
9
9
10
10
11
11
12
12
12
13
14
14
14
15
16
16
16
16
17
17
17
18
18
18
18
III
3
II
4
IV
Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Nachhaltigkeit ................................................................................
3.2 Multimodale Mobilität .....................................................................
3.2.1 Motivation für multimodale Mobilität ........................................
3.2.2 Ziele multimodaler Mobilität ....................................................
3.2.3 Begriffliche Abgrenzung...........................................................
3.2.4 Multimodale Mobilität als Basis für die Jinengo Plattform.............
3.2.5 Vorteile multimodaler Mobilität................................................
Anforderungsdefinition
Pflichtenheft Teil A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.0.6 Zweck des Systems .................................................................
4.0.7 Umfang des Systems...............................................................
4.0.8 Ziele und Erfolgskriterien des Projekts .......................................
4.1 Vorhandene Systeme........................................................................
4.1.1 Deutsche Bahn AG (DB).........................................................
4.1.2 Flinc....................................................................................
4.1.3 Klima-Sucht-Schutz.de ............................................................
4.1.4 Sourcemap.org.......................................................................
4.1.5 Car2gether............................................................................
4.1.6 Car2go .................................................................................
4.1.7 Abgrenzung zu Jinengo ...........................................................
4.2 Anforderungen................................................................................
4.2.1 Funktionale Anforderungen......................................................
Architektonische Anforderungen ...............................................
User Model . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adaptation Engine .................................................................
Evolution Chamber . . . . . . . . . . . . . . . . . . . . . . .
CRM-Anbindung . . . . . . . . . . . . . . . . . . . . . . . .
Nutzerfunktion ......................................................................
Agentenfunktion ....................................................................
Agentenkategorien . . . . . . . . . . . . . . . . . . . . . . .
Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Nichtfunktionale Anforderungen ...............................................
Bedienbarkeit ........................................................................
Zuverlässigkeit und Leistung ....................................................
Zuverlässigkeit . . . . . . . . . . . . . . . . . . . . . . . . .
Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rechtliches ...........................................................................
4.3 Anwendungsfälle .............................................................................
4.3.1 Nachhaltige Routenplanung .....................................................
19
19
20
20
21
21
21
22
25
27
27
28
28
28
28
29
30
30
30
31
31
31
31
32
32
32
32
32
33
33
34
34
35
35
35
35
35
36
38
38
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.3.7
4.3.8
4.3.9
4.3.10
4.3.11
4.3.12
5
Neuen Agenten erstellen ..........................................................
Reise planen aus der Sicht des Reisenden....................................
Ergebnis filtern......................................................................
Reise planen aus Sicht der Dienstleister......................................
Filterdefinition aus Dienstleistersicht .........................................
Nutzerprofil ändern ................................................................
Reise bewerten - Reisender ......................................................
Agentenverhalten hinzufügen....................................................
Agent zusammenfügen ............................................................
Agent bestätigen....................................................................
Registrierung ........................................................................
39
39
45
46
47
49
52
55
58
61
63
Pflichtenheft Teil B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Funktionale Anforderungen ...............................................................
5.1.1 CRM ...................................................................................
Business Case........................................................................
Kunde und Mehrwert . . . . . . . . . . . . . . . . . . . . .
Nachhaltigkeitsaspekt . . . . . . . . . . . . . . . . . . . . .
Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Frontend ..............................................................................
Allgemeines zu mobilen Betriebssystemen ...................................
Java2ME-Anwendung .............................................................
5.1.3 Anforderungen an die Verwendung von Bedienelementen ...............
Anforderungen für jede Seite: . . . . . . . . . . . . . . . . .
Login-Seite: . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registrieren-Seite: . . . . . . . . . . . . . . . . . . . . . . .
Reise-Planen-Seite: . . . . . . . . . . . . . . . . . . . . . .
Reise-Ergebnisse-Seite: . . . . . . . . . . . . . . . . . . . . .
Passwort-ändern-Seite: . . . . . . . . . . . . . . . . . . . . .
5.1.4 Backend ...............................................................................
Administrationsoberfläche........................................................
RESTful-Webservice...............................................................
5.1.5 Hatchery ..............................................................................
Dynamisches Hinzufügen von neuen Agenten ..............................
Rekombination der Agenten .....................................................
Rekombination der com.jinengo.Contentrepository Agenten
Rekombination der com.jinengo.AdaptationEngine Agenten
5.2.1 Potentielle Fahrgemeinschaften abrufen ......................................
5.2.2 Neuen Contentrepository-Agenten hinzufügen .............................
5.2.3 Neuen Matchmaker-Agenten hinzufügen .....................................
5.2.4 Matchmaker-Agenten rekombinieren ..........................................
67
67
67
69
69
69
69
69
69
72
76
76
76
76
76
76
76
77
77
78
78
79
79
80
80
81
81
82
83
84
V
6
Pflichtenheft Teil C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Einführung ....................................................................................
6.2 Nicht umgesetzte Anforderungen aus Meilenstein B ...............................
6.2.1 Frontend ..............................................................................
6.2.2 Admin Frontend ....................................................................
6.2.3 CRM ...................................................................................
6.3 Snippets und Messages.....................................................................
6.4 Frontend .......................................................................................
6.5 Backend ........................................................................................
6.6 Data Warehouse .............................................................................
6.7 Berichterstellung .............................................................................
6.8.1 Advise Messaging...................................................................
6.8.2 Data Warehouse Prozess .........................................................
III Entwurf
7
VI
87
87
87
87
89
90
90
91
91
92
92
93
93
95
101
Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.1 Server ........................................................................................... 103
7.1.1 Klassenentwurf ...................................................................... 104
Paket com.jinengo.Environment ................................................ 104
Paket com.jinengo.PresentationComposer ................................... 104
Paket com.jinengo.AdaptationEngine......................................... 104
Paket com.jinengo.UserModelModule......................................... 104
Paket com.jinengo.ContentRepository ........................................ 109
Paket com.jinengo.MessagingModule ......................................... 109
Paket com.jinengo.Hatchery ..................................................... 109
7.1.2 Sequenzdiagramme ................................................................. 109
Sequenzdiagramm: Application Startup...................................... 112
Sequenzdiagramm: Simple User Operations................................. 112
Sequenzdiagramm: LookUpRoute.............................................. 112
Sequenzdiagramm: getMessage ................................................. 121
7.1.3 ER-Modelle .......................................................................... 121
CRM ................................................................................... 121
Data Warehouse .................................................................... 121
7.1.4 Technologieevaluation ............................................................. 121
Kriterien zur Auswahl............................................................. 125
Alternative Technologien ......................................................... 125
Laufzeit- und Entwicklungsumgebung ........................................ 125
Build-System ........................................................................ 126
Testumgebung ....................................................................... 126
Web Services......................................................................... 126
Datenbank............................................................................ 126
CRM-System ........................................................................ 127
7.2 Client ........................................................................................... 127
7.2.1 Design des Frontends .............................................................. 128
7.2.2 Funktionsumfang des Frontends ................................................ 152
7.2.3 Eingesetzte Technologien ......................................................... 155
7.2.4 Adaptives Verhalten des Frontends............................................ 155
7.2.5 Design ................................................................................. 156
7.3 Allgemeine Werkzeuge ..................................................................... 156
7.3.1 Versionskontrollsystem ............................................................ 156
7.3.2 Integrierte Entwicklungsumgebung ............................................ 156
Java Entwicklung ................................................................... 156
ASP.NET Entwicklung............................................................ 156
Business Intelligence ............................................................... 157
MySQL Datenbanken ............................................................. 157
SQL Datenbanken .................................................................. 157
7.3.3 Ontologien ............................................................................ 157
8
Benutzerklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
8.1 Endnutzer...................................................................................... 165
8.2 Administrator................................................................................. 165
8.3 Agent Assembler ............................................................................. 165
8.4 Behaviour Developer........................................................................ 166
9
Klassendiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
9.1 UserModel module .......................................................................... 167
9.1.1 Administrator ....................................................................... 167
9.1.2 AgentAssembler..................................................................... 167
9.1.3 BehaviourDeveloper................................................................ 167
9.1.4 CrmAdapter ......................................................................... 168
9.1.5 CrmProperty......................................................................... 168
9.1.6 Customer ............................................................................. 168
9.1.7 DynamicsAdapter .................................................................. 168
9.1.8 MySqlConnector .................................................................... 170
9.1.9 User .................................................................................... 170
9.1.10 UserManager......................................................................... 170
9.2 AdaptationEngine ........................................................................... 170
9.2.1 AdaptationManager................................................................ 170
9.2.2 MatchMaker ......................................................................... 173
9.2.3 IMatchMaker ........................................................................ 173
9.2.4 SustainableMatchMaker .......................................................... 173
9.2.5 SampleMatchMaker ................................................................ 173
9.2.6 EconomicalMatchMaker .......................................................... 173
VII
9.2.7 SpeedyMatchMaker ................................................................ 173
9.2.8 ShortestDistanceMatchMaker ................................................... 175
9.3 ContentRepository .......................................................................... 175
9.3.1 Modul Contentrepository......................................................... 181
Klasse ContentManager........................................................... 181
Klasse Route......................................................................... 181
Klasse SubRoute.................................................................... 181
Klasse TravelSituation ............................................................ 181
Klasse TransportationType ...................................................... 184
9.3.2 Modul ContentProvider........................................................... 184
ContentProvider .................................................................... 184
BikeProvider ......................................................................... 185
CarProvider .......................................................................... 185
DBProvider .......................................................................... 187
FootProvider ......................................................................... 187
PEVProvider ........................................................................ 187
FahrplanerProvider ................................................................ 189
BusCostCalculator ................................................................. 189
TramCostCalculator ............................................................... 190
TramEmissionCalculator ......................................................... 190
BusEmissionCalculator ........................................................... 190
9.3.3 Modul ContextProvider........................................................... 191
Context................................................................................ 191
ContextProvider .................................................................... 191
WetterDotComProvider .......................................................... 192
TimeProvider ........................................................................ 192
9.3.4 Modul Interfaces .................................................................... 192
ICostCalculator ..................................................................... 192
IEmissionCalculator ............................................................... 192
IRoutePlanner ....................................................................... 194
IWeatherProvider................................................................... 194
9.3.5 Modul Tooling....................................................................... 194
InputCleaner......................................................................... 195
HttpPostRequestor................................................................. 195
9.4 PresentationComposer ..................................................................... 196
9.4.1 IPresentationManager ............................................................. 196
9.4.2 JinengoException................................................................... 199
9.4.3 PresentationManager .............................................................. 200
9.4.4 RestfulPresentationManager..................................................... 200
9.5 MessagingModule............................................................................ 201
9.5.1 MessagingManager ................................................................. 201
9.5.2 IMessagingProvider ................................................................ 202
9.5.3 MessagingProvider ................................................................. 202
VIII
9.5.4 BiddingThread ...................................................................... 202
9.5.5 AdviseMessage ...................................................................... 202
9.5.6 DefaultProvider ..................................................................... 204
9.5.7 MessagingProviderInfo ............................................................ 204
9.5.8 MessagingProviderValidator ..................................................... 204
9.5.9 ProviderRepositoryManager ..................................................... 205
9.6 Frontend - JinengoUI ....................................................................... 205
9.6.1 BaseController....................................................................... 206
9.6.2 HomeController ..................................................................... 206
9.6.3 RouteController ..................................................................... 207
9.6.4 UserController....................................................................... 207
9.6.5 SearchRouteModel ................................................................. 209
9.6.6 RouteUtill ............................................................................ 209
9.6.7 RegisterUserModel ................................................................. 210
9.6.8 RemindUserModel.................................................................. 210
9.6.9 LoginUserModel .................................................................... 211
9.6.10 LogoffUserModel.................................................................... 211
9.6.11 SettingsModel ....................................................................... 211
9.6.12 EmailUserModel .................................................................... 212
9.6.13 PasswordUserModel................................................................ 212
9.6.14 PreferencesUserModel ............................................................. 213
9.6.15 CacheFilterAttribute .............................................................. 213
9.6.16 CompressFilter ...................................................................... 214
9.6.17 LoginForbiddenFilter .............................................................. 214
9.6.18 LoginRequiredFilter ............................................................... 215
9.6.19 CultureHelper ....................................................................... 215
IV Projektabschluss
217
V
221
Anhang
A Protokolle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Projektgruppenprotokoll vom 27.10.2010 ............................................. 224
IX
Projektgruppenprotokoll
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
vom
12.01.2011 ............................................. 245
19.01.2011 ............................................. 247
26.01.2011 ............................................. 250
02.02.2011 ............................................. 253
09.02.2011 ............................................. 255
16.02.2011 ............................................. 259
23.02.2011 ............................................. 261
09.03.2011 ............................................. 263
16.03.2011 ............................................. 265
23.03.2011 ............................................. 267
30.03.2011 ............................................. 270
05.04.2011 ............................................. 272
12.04.2011 ............................................. 274
19.04.2011 ............................................. 277
10.05.2011 ............................................. 279
17.05.2011 ............................................. 282
31.05.2011 ............................................. 285
07.06.2010 ............................................. 287
14.06.2011 ............................................. 289
28.06.2011 ............................................. 291
05.07.2011 ............................................. 293
12.07.2011 ............................................. 295
19.07.2011 ............................................. 297
26.07.2011 ............................................. 299
02.08.2011 ............................................. 301
09.08.2011 ............................................. 303
16.08.2011 ............................................. 305
23.08.2011 ............................................. 307
30.08.2011 ............................................. 309
01.12.2010 ............................................. 311
B Seminararbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Grundlagen zum Einsatz von elektronischen Customer Relationship Management Systemen (eCRM) in Marketing, Vertrieb und Service – am
Beispiel von Microsoft Dynamics CRM................................................ 316
Kosten und Emissionen von Elektroautos – Grundlagen für einen Kostenund Emmissionskalkulator ................................................................ 341
Betrachtung klassischer Kundenbindungsinstrumente und ihrer Eignung
für die Förderung der Nutzung von nachhaltigen Verkehrsmitteln ............ 364
Grundlagen der Erstellung von Geschäftsmodellen und Ansatzpunkte für
die Übertragung des Geschäftsmodells Mobilfunk-Serviceprovider auf einen Mobilitätsservice ......................................................................... 386
Adaptive Applications Reference Models ............................................. 400
X
Using CRM systems for User Modeling ............................................... 420
Grundlagen klassischer Kundenanreizsysteme und Möglichkeiten der Steuerung des Kunden zu einem nachhaltigen Konsum................................. 438
Making It Personal: How to Profit from Personalization without Invading
Privacy ......................................................................................... 455
Encapsulating services in agents......................................................... 470
Untersuchung von Elektroautos unter Nachhaltigkeitsaspekten im Vergleich mit anderen Verkehrsmitteln..................................................... 487
Concepts of (strategic) Customer Relationship Management and An Approach to Sustainability.................................................................... 505
C Handbücher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
C.1 Web-Frontend................................................................................. 525
C.2 Agententwicklung............................................................................ 525
C.3 CRM ............................................................................................ 526
D Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
D.1 Jinengo Datenschutzbestimmungen..................................................... 557
E Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
F
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
G Referenzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
XI
Teil I.
Einführung
1
1. Einleitung
Das vorliegende Dokument enthält die Dokumentation der Projektgruppe Jinengo. Der
interne Arbeitstitel zu diesem Projekt lautet Sustainable CRM for E-Mobility Services
based on SOA.
Das Projekt wird im Rahmen des Masterstudienganges Wirtschaftsinformatik an der
Carl von Ossietzky Universität Oldenburg durchgeführt. Es ist Pflichtbestandteil dieses
Studienganges und erstreckt sich im vorliegenden Fall vom Wintersemester 2010 bis zum
Sommersemester 2011.
Das Projektteam Jinengo besteht aus elf ambitionierten Studenten des Masterstudiengangs Wirtschaftsinformatik. Fachlich wie auch kulturell haben die Studenten unterschiedliche Hintergründe, was dem Projekt eine inspirierende Basis verschafft. Betreut
und angeleitet werden die Elf durch Herrn Dipl. Oec. Benjamin Wagner vom Berg und
Herrn Dipl. Inf. Ammar Memari, die beiderseits Mitarbeiter der Abteilung Wirtschaftsinformatik / Very Large Business Applications sind.
Neben den internen Projektgruppentreffen finden wöchentliche Treffen mit den Betreuern statt, um den Fortschritt des Projektes festzuhalten und zu präsentieren.
Generelles Ziel des Projekts ist die Entwicklung eines nachhaltigen Mobilitätsservice,
der Privatpersonen zum Beispiel in Form einer Website zur Verfügung gestellt wird. Die
Nutzer sind damit in der Lage, nachhaltige Transportmöglichkeiten zu finden und zu
wählen.
Die folgenden Unterkapitel der Einleitung legen die Motivation, die Zielsetzung, die
Lizenzbedingungen, sowie den Aufbau der Dokumentation dar.
1.1. Motivation der Projektgruppe
In der heutigen Gesellschaft hat die individuelle Mobilität einen sehr hohen Stellenwert.
Dieses gehobene Mobilitätsbestreben führt jedoch zu einer Vielzahl negativer Effekte.
Ein Großteil der Mobilität wird durch PKWs erreicht. In der Konsequenz ergeben sich
— inbesondere in Ballungsgebieten — hohe CO2 -Ausstöße und auf globaler Ebene ist
eine bedrohliche Zunahme der CO2 -Konzentration der Atmosphäre zu verzeichnen.
3
1. Einleitung
Gerade bei der individuellen Mobilität ist hohes Optimierungspotential vorhanden, welches derzeit wenig ausgeschöpft wird. So sind z.B. viele PKWs nur mit einer Person
besetzt oder werden unwirtschaftlich auf kurzen Strecken eingesetzt. Viele Personen
sind sich möglicherweise nicht bewusst, dass sie sich unnachhaltig bewegen und es
Möglicheiten zur Verbesserung gibt.
Jinengo richtet sich an diejenigen Menschen, die sich bewusst nachhaltig bewegen möchten, denen jedoch bisher die nötige Informationsgrundlage zu einer fundierten Entscheidung fehlte. Jinengo ist als Web-Applikation überall verfügbar und bietet dem Nutzer die
Möglichkeit, vor Reiseantritt Transportmittel sowie Reiserouten bezüglich ihrer Nachhaltigkeit zu vergleichen.
1.2. Zielsetzung der Projektgruppe
Ziel der Projektgruppe ist die Entwicklung einer Web-Applikation, deren Aufgabe es ist,
Informationen über Reiserouten und mögliche Transportmittel unter Berücksichtigung
von Nachhaltigkeitsaspekten anzubieten.
Dabei ist die Anwendung weit mehr als ein gewöhnlicher Routenplaner. Aufgrund der
verwendeten Softwarearchitektur ist es möglich, nahezu jedes Verkehrsmittel in die Routenplanung mit einzubeziehen. Zu Anfang werden die Transportmittel Bahn, Pkw mit
Verbrennungsmotor als auch Elektroantrieb, sowie der Fußmarsch implementiert, um
die generelle Machbarkeit der Anwendung aufzuzeigen. In einer zweiten Phase wird
diese Auswahl erweitert um z.B. Car-Sharing-Dienste, Autovermietungen, Fahrgemeinschaftsdienste, Segways, Fluggesellschaften uvm. — eben jegliche Transportmittel und
Mobilitätsdienste.
Der Fokus der Anwendung liegt dabei stets auf dem Nachhaltigkeitsgedanken und richtet
sich explizit an Nutzer, die sich bewusst nachhaltig bewegen möchten.
Jeder Nutzer kann durch persönliche Angaben, wie z. B. Abfahrts- und Zielort, Reisedatum, Kostenoptionen, Flexibilität, Bequemlichkeit usw. ein kombiniertes, individuelles
Mobilitätsangebot abfragen. Zu einem Mobilitätsangebot gehören dann auch detaillierte Informationen, bspw. ein Routenplan, Kosten, Brennstoffverbrauch betroffener Verkehrsmittel, CO2 -Emissionen usw., mit deren Hilfe der Anwender einen nachhaltigen
Reiseplan auswählen kann. Die Web-Applikation bildet diese Daten zusammen mit dem
Nutzer in einem CRM-System ab. Mit Hilfe von Business Intelligence Methoden in einem
angeschlossenen Data Warehouse werden die Nutzerdaten analysiert, um den Service für
den Nutzer weiter zu optimieren und eine verbesserte User Experience zu erzielen.
Die Nutzung der Web-Applikation soll für mobile Endgeräte wie Handys und Smartphones, sowie Handhelds optimiert werden, damit der Service auch unterwegs zur Ver-
4
1.3. Lizenzbedingungen
fügung steht, denn gerade dort ist der Nutzer auf kompakte Reiseinformationen angewiesen.
Inhaltlich wie technisch beschreitet das Projekt neue Wege und wir –– das Projektteam
— sind der Überzeugung, dass wir hiermit einen aktiven Beitrag für eine nachhaltigere
Zukunft leisten können. Übrigens: Jinengo ist ein Kunstwort, das sich aus den chinesischen Worten Jie“ und neng“ ableitet. Dies entspricht im Deutschen der Bedeutung
”
”
Energie sparen“.
”
1.3. Lizenzbedingungen
Im Rahmen der Entwicklung umfangreicher Anwendungen wird häufig auf externe Komponenten zurückgegriffen. Gründe hierfür sind Zeitersparnis, Standardisierungsbestrebungen, die Verfügbarkeit getesteter Komponenten oder auch mangelndes Know-how.
Für die Realisierung des Prototypen soll ebenfalls auf vorhandene Technologien zurückgegriffen werden. Bei der Auswahl von Komponenten spielen verschiedene Faktoren eine
Rolle. Auf den Aspekt der Lizenzierung soll an dieser Stelle eingegangen werden:
Grundsätzlich ist zwischen Lizenzen zu unterscheiden, die eingeschränkte bzw. uneingeschränkte Rechte beim Umgang mit einer Komponente erlauben. Im Bereich der Forschung sind hierbei Komponenten mit möglichst geringen Einschränkungen zu bevorzugen, um Einblick in technische Implementierungen zu erhalten und die Übertragbarkeit auf reale Systeme zu gewährleisten. Diese uneingeschränkten oder nur gering eingeschränkten Rechte sind nicht mit Lizenzmodellen gleichzustellen, die im Allgemeinen als
Open Source bezeichnet werden. Für eine Komponente, die in verschiedenen Szenarien
in Verbindung mit verschiedenen Softwaresystemen eingesetzt werden soll, stellen sich
daher diese Anforderungen:
Einsicht in vorhandene Implementierungen (oder eine Reputation des Anbieters,
die eine langfristige Verfügbarkeit gewährleistet), alternativ
Einsicht in vorhandene Implementierung und Recht zur Modifikation und Weiterentwicklung, Recht der kommerziellen Verwendung sowie
Kompatibilität der Lizenz zu anderen verwendeten Lizenzen.
Diese Anforderungen schließen einige verbreitete Lizenzen aus. In Tabelle 1.1 sind einige verbreitete Lizenzen und exemplarisch ihre Kompatibilität zur verbreiteten General
Public Licence (GPL) aufgeführt. Anhand der hohen Anzahl von Inkompatibilitäten ist
die Problematik beim Einsatz z. B. von GPL-lizensierter Software leicht erkennbar.
5
1. Einleitung
Lizenz
Academic Free Licence (AFL)
Apache Licence
Apple Public Source
Licence (APS)
Artistic Licence
Berkeley Database
License
Berkeley
Software
Distribution (BSD)
Common
Development and Distribution
License
(CDDL)
Common Public License (CP)
Eclipse License
European Union Public (EU-PL)
GNU General Public
License (GPL)
GNU Lesser General
Public License (LGPL)
IBM Public License
Intel Open Source
License
LaTeX Project Public License
MIT License X11 License
Mozilla Public License
Open Software License
PHP License
Phython
Software
Foundation
Q Public License
6
Link aus anderer Lizenz
Ja
Lizenzwechsel
Ja
GPL Kompatibilität
Nein
Ja
Ja
Ja
Nein
Nein
Nein
Ja
Nein
Limitiert
Nein
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Nein
Ja
Nein
Nein
Ja
Ja
Nein
Limitiert
Nein
Ja
Nein
Nein
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Limitiert
Nein
Ja
Nein
Nein
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Nein
Nein
1.4. Aufbau der Dokumentation
Lizenz
Sun Industry Standards Source License
(SISS)
Sun Public License
W3C Software License
XFree86 1.1 License
zliblibpng License
Zope Public License
Link aus anderer Lizenz
Ja
Lizenzwechsel
Nein
GPL Kompatibilität
Nein
Ja
Ja
Nein
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Tabelle 1.1.: Übersicht Lizenzen
Aus Tabelle 1.1 ist ersichtlich, dass Komponenten mit einer GPL-Lizenzierung häufig
mit anderen Lizenzen inkompatibel sind. Zusätzlich handelt es sich um eine virulente
Lizenz, die maßgeblichen Einfluss auf die weitere Verwendung hat. Virulent bedeutet,
dass Komponenten, die auf GPL-lizensierte Komponenten linken, selbst unter der GPL
stehen. Aus diesem Grunde wurde als strengste akzeptierte Lizenz die L-GPL gewählt.
Diese Lizenz trennt zwischen der verwendeten und der verwendenden Komponente, sodass die Lizenzierung für die entwickelte Komponente frei gewählt werden kann. Andere
akzeptable Lizenzen für allgemein verwendbare Komponenten sind nach den oben genannten Anforderungen beispielsweise die Berkeley Software Distribution-Licence (BSD)
oder die Microsoft Public Licence (MS-PL).
1.4. Aufbau der Dokumentation
Der Abschlussbericht der Projektgruppe Jinengo ist in die Teile Einführung, Anforderungsdefinition, Entwurf, Projektabschluss und Anhang unterteilt. Die Teile sind durch
römische Ziffern nummeriert. In der Einleitung wird zuerst Allgemein die Projektgruppe
inklusive der Organisation und der Ziele erläutert. Nachfolgend wird kurz ein grober
Überblick über die client- und serverseitig eingesetzte Software, sowie deren Lizenzbedingungen gegeben. Am Ende der Einleitung werden Grundlagen der Nachhaltigkeit und
multimodale Mobilität erklärt, um den Einsatzbereich der Software zu verdeutlichen.
Zu Beginn des Projektes wurden anhand von Interviews mit den Betreuern die Anforderungen an die Software festgehalten und in der Anforderungsdefinition definiert. Diese
stellt den zweiten Teil des Abschlussberichtes dar. In diesem Teil werden funktionale
7
1. Einleitung
und nicht funktionale Anforderungen beschrieben, welche am Ende der Meilensteine erreicht werden sollen. An dieser Stelle sind bereits klar definierte Anwendungsfälle vom
Projektteam skizziert und beschrieben.
Der dritte Teil Entwurf besteht aus der praktischen Umsetzung der in Kapitel II definierten Anforderungen. Im Speziellen wird hier auf die Systemarchitektur anhand der
Unterkapitel Server, ??, Client und ??, sowie auf die ?? und deren Benutzerklassen eingegangen. Anschließend werden die erstellten Klassendiagramme grafisch dargestellt und
beschrieben.
DRU: Links fixen
Teil IV (Projektabschluss), kann ich bis jetzt noch wenig zu schreiben, weil noch kein
Inhalt exisitiert.
DSC: Dieser Abschnitt ist noch
nicht fertig.
Der letzte Teil enthält den Anhang, in dem die Protokolle der wöchentlichen Meetings
sowie die Seminarthemen der Projektmitglieder enthalten sind.
I: Einführung
II: Anforderungsdefinition
III: Entwurf
IV: Projektabschluss
V: Anhang
Motivation der Projektgruppe
Projektorganisation
Grundlagen
Zweck des Systems
Vorhandene Systeme
Anforderungen
Anwendungsfälle
Systemarchitektur
??
Klassendiagramme
Fazit
Protokolle
Seminararbeiten
Tabelle 1.2.: Aufbau des Abschlussberichtes
8
2. Projektorganisation
Dieses Kapitel beschreibt die Organisation der Projektgruppe. Es werden die verschiedenen Rollen innerhalb des Projekt-Teams beschrieben und erläutert. Außerdem wird
die Vorgehensweise bei der Planung und Durchführung der Projektgruppe beschrieben.
Des Weiteren werden die eingesetzten Software-Tools, die zur Unterstützung der Projektorganisation und zur Modellierung und Entwicklung der Software genutzt werden,
vorgestellt.
2.1. Projektinterne Aufgabenbereiche
Zu Beginn der Projektgruppe wurden die nachfolgend beschriebenen Projektrollen ernannt und besetzt, um für spezielle Themengebiete separate Ansprechpartner zu haben.
2.1.1. Projektmanager
Innerhalb eines studentischen Projekts ist die Rolle des Projektmanagers differenziert
zu der eines Projektmanagers in einem Projekt in der Wirtschaft zu sehen. Die soziale
Interaktion zwischen einzelnen Mitgliedern im Projekt ist dadurch geprägt, dass es keine
hierarchischen Unterschiede gibt. Sehr wohl bestehen aber Differenzen in fachlichen und
kommunikativen Kompetenzen. Weiterhin ist nicht allein das Ergebnis des Projekts als
Ziel zu sehen — ein wesentlicher Teil des Gesamtergebnisses ist das Lernen. Arbeiten in
der Gruppe, über einen längeren Zeitraum an einer Aufgabe, die nur durch Zusammenarbeit gemeistert werden kann sind Aspekte, die losgelöst von der fachlichen Qualifikation
vermittelt werden sollen.
Für den Projektmanager bedeuten diese Umstände, dass die Konzentration nicht allein
auf dem Projektergebnis liegen darf. Einzelne Mitglieder der Projektgruppe sollten in
Situationen gebracht werden, in denen sie verschiedene Aspekte des gemeinsamen Arbeitens erfahren. Dies kann den Fortschritt des Projekts verzögern, ermöglicht aber, dass
mehr Erfahrungen gesammelt werden können.
Um diese Ziele zu erreichen, muss der Projektmanager innerhalb eines studentischen
Projekts folgende Aspekte im Besonderen beachten:
9
Der Zeitplan für ein Projekt mit einer Laufzeit von einem Jahr stellt eine besondere
Herausforderung dar. Der Projektmanager muss sicherstellen, dass die Planung so
ausgerichtet ist, dass der Zieltermin eingehalten wird und während des Projektverlaufs eine klare Bestimmung des Ist-Zustands möglich ist. Da die Beteiligten keine
oder nur wenig Erfahrung mit langfristigen Projekten haben, sind Abweichungen
vom eigentlichen Projektziel zu überwachen.
Die Kommunikation innerhalb einer Projektgruppe ist zur zeitnahen Identifikation
von Schwächen relevant. Da die Kommunikationsbereitschaft in hohem Maße durch
die Persönlichkeit der einzelnen Projektgruppenmitglieder beeinflusst wird, ist die
Moderation innerhalb der Projektgruppe eine wesentliche Funktion. Als externe
Schnittstelle zum Auftraggeber (innerhalb eines universitären Projekts die Betreuer) ist die Koordination und Kommunikation über Ziele und Terminierungen, aber
auch über Risiken eine Aufgabe.
Die Auflösung von Konflikten, seien sie zwischenmenschlich oder fachlich bezogen,
ist dann Teil der Arbeit des Projektmanagers, wenn diese die Ziele der Projektgruppe gefährden.
Viele Aufgaben und Tätigkeiten lassen sich nicht eindeutig in einer Kategorie benennen.
Im Idealfall kann der Projektmanager bei der Auflösung von Problemen und Herausforderungen unterstützen. Als Vermittler vermeidet er potenzielle Konflikte, indem mögliche
Konfliktpunkte frühzeitig erkannt und beseitigt werden.
Verantwortlicher: Timo von der Dovenmühle
2.1.2. Windows-Serveradministrator
Aufgabe des Windows-Serveradministrators ist es, alle Windows-Server in der Jinengo
Projektumgebung zu administrieren. Im Wesentlich bezieht sich das auf den Server, welcher ursprünglich das Microsoft CRM-System hosten sollte. Mittlerweile haben wir eine
Cloud-Lösung für das CRM-System und somit besteht die Kernaufgabe darin, administrative Fragen bzgl. des CRM-Systems zu klären. Weiterhin wird das Frontend von
Jinengo auf dem Windows-Server deployed, daher fällt dies ebenfalls in den Aufgabenbereich des Windows-Serveradministrators.
Verantwortlicher: Marc Petersen
2.1.3. Linux-Serveradministrator
Der Serveradministrator für Linux Server administriert alle Linux Server in der Jinengo Projektumgebung. Hierzu zählt die Administration der Server, welche die Projekt-
10
2.1. Projektinterne Aufgabenbereiche
unterstützenden Werkzeuge wie das Projektmanagement-Werkzeug Redmine und das
Versionskontrollsystem Subversion zur Verfügung stellen. Da die Test- und Produktionsumgebungen ebenfalls in einer auf Linux-basierenden Architektur laufen werden, gehört
auch die Administration und das Deployment dieser Servermaschine zu der Rolle des
Linux-Serveradministrators.
Verantwortlicher: Daniel Stamer
2.1.4. Webseitenbeauftragter
Die Aufgabe des Webseitenbeauftragten ist es, eine Website oder einen Blog mit relevantem Inhalt zu füllen, um diesen dem öffentlichem Publikum zugänglich zu machen.
Diese Inhalte werden nicht nur durch den Webseitenbeauftragten selbst generiert sondern stammen auch von den anderen Projektbeteiligten. Daneben wird zu Anfang ein
ansprechendes Layout entworfen, welches sich am Corporate Design der Projektgruppe
orientiert. Neuigkeiten sollten regelmäßig publiziert werden, um die Seite attraktiver zu
machen.
Ein wichtiger Aspekt ist, dass der Webseitenbeauftragte schnell auf Wünsche oder Updates reagiert. Zuletzt ist der Webseitenbeauftragte auch dafür verantwortlich, dass
mögliche Userkommentare auf ihre Angemessenheit überprüft werden.
Verantwortlicher: Carl Mahnke
2.1.5. Testbeauftragter
Im Allgemeinen ist dem Testbeauftragen in dem Jinengo-Projekt die Verantwortung für
eine gewisse Grundqualität der zu entwickelnden Software zugeteilt. Dabei liegen im
Konkreten folgende Aufgabenbereiche vor:
Evaluation eines geeigneten Testframeworks
Evaluation eines geeigneten Vorgehensmodells zum Testen
Entwickeln eines Leitfadens zum Testen
Überprüfung der Einhaltung von Testvorgaben
Verantwortlicher: Sven Kölpin
11
2.1.6. Dokumentenbeauftragter
Der Dokumentenbeauftragte hat die Aufgabe, Vorlagen für die Dokumentationsstruktur
anzufertigen und bereitzustellen. Dies beinhaltet Vorlagen für Protokolle der Projektgruppentreffen, Seminararbeiten und die Projektdokumentation. Ein einheitliches Aussehen der Dokumente, sowie die Berücksichtigung der Vorlagen der Abteilung VLBA
sind hierfür die Grundlage. Eine weitere Aufgabe neben der Erstellung der Vorlagen ist
die Fortschrittskontrolle der Dokumente.
Verantwortlicher: Daniel Schnieders
2.1.7. Finanzbeauftragter
Die Projektgruppenkasse wird vom Finanzbeauftragten verwaltet. Die Aufgabe des Finanzbeauftragten besteht im Einzelnen aus folgenden Tätigkeiten:
Kasse verwalten
Über Kalkulation berichten
Auskunft über aktuellen Kassenbestand geben
Abschlussbericht mit Kassenbelegen nach Abschluss des Projektes geben
Verantwortlicher: Xin Huang
2.1.8. Kommunikationsbeauftragter
Der Kommunikationsbeauftragte ist für die Kommunikation mit externen Firmen und
die Koordination eventueller Veranstaltungen verantwortlich. Die Rolle umfasst folgende
Aufgaben:
Vorstellung unseres Projekts gegenüber Kunden und Partnern und Koordination
eventueller Veranstaltungen, sowie Terminabsprachen
Abstimmung von Workshops
Kommunikation nach außen und rechtzeitige Benachrichtigung aller Gruppenmitglieder
Recherche von Kontakten zu Firmen oder Forschungsinstituten, die potentiell Interesse an unserem Projekt haben
12
2.2. Vorgehensweise und Roadmap
Verantwortliche: Yi Wei
2.2. Vorgehensweise und Roadmap
Ein Projekt mit einer Laufzeit von einem Jahr und einer Gruppengröße von elf Mitgliedern ist eine Herausforderung, weil Risiken der Veränderung und des kontinuierlichen
Fortschritts nur schwer überschaubar sind.
Die Projektgruppe hat daher verschiedene Vorgehensmodelle analysiert und daraus eine
Strategie entwickelt, um das Ziel zu erreichen. Die meisten Modelle gehen entweder davon aus, dass die Anforderungen und Pflichten sehr genau beschrieben sind oder das der
Zieltermin des Projekts eine gewisse Variabilität aufweist. Beides trifft im Rahmen der
Projektgruppe nicht zu. Es existieren grobe Anforderungen und Beschreibungen der Ziele; aus Sicht des Projektmanagements sind diese aber viel zu unscharf ausformuliert. Da
während des Projektverlaufs diese Anforderungen veränderlich sind, muss eine Lösung
gefunden werden, die Flexibilität und Termintreue fördert.
Das gewählte Modell ist ein Sägezahn, d. h. es handelt sich um eine Aneinandereihung
von Wasserfall-Vorgehensmodellen. Zu Beginn einer Phase werden die Anforderungen
mit dem Kunden (dessen Rolle die Betreuer übernehmen) abgestimmt. Nach Abschluss
einer Phase werden die Ergebnisse mit den Anforderungen verglichen und neu entstandene Anforderungen in das Pflichtenheft für die folgende Phase übernommen. Dieses
Vorgehen erlaubt, dass agil auf neue Anforderungen während des Projektverlaufs eingegangen werden kann, während aus Sicht der Projektgruppe klar definierte Meilensteine
die Möglichkeit geben, den Fortschritt genau zu überwachen.
In der konkreten Ausführung werden von der Projektgruppe drei aufeinander folgende
Phasen durchlaufen. Am Ende des ersten Semesters soll ein vertikaler Prototyp vorliegen, der alle Aspekte des Projekts abdeckt. Dies umfasst einen Entwurf der Anwendung,
die Implementierung aller relevanten Komponenten und die vollständige Dokumentation
des Projekts. Das Ergebnis soll dabei dem eines Projektabschlusses entsprechen.
In der Folgephase wird der Prototyp analysiert und neue Anforderungen auf Basis der
existierenden Anwendung identifiziert. Zeitgleich werden Schwächen in der Projektorganisation gesucht, um diese in den folgenden Arbeitsschritten zu minimieren. Das Ziel
der zweiten Phase ist es, die Anwendung soweit zu erweitern, dass auch ein praktischer
Einsatz möglich ist.
Die dritte Phase umfasst jene Anforderungen, die für die Außenwirkung relevant sind.
Dazu gehören erweiterte Dokumentationen, Präsentationen und aus Anwendungssicht
Optimierungen in der Darstellung, Nutzungsfreundlichkeit und Optik. Diese Aspekte liegen deshalb in der letzten Iterationsstufe, weil sie für den gesamten Projekterfolg nicht
13
kritisch sind. Dies bedeutet, dass Schwächen in einem dieser Aspekte nicht zum Scheitern
des Gesamtprojekts führen würden.
2.3. Software
Um das Projekt und die Entwicklung der Software Jinengo zu unterstützen, wird eine breite Palette an Software benötigt. Als Grundlage hierzu dient ein von der Abteilung VLBA zur Verfügung gestellter Server, auf dem die Betriebssysteme Ubuntu Linux
10.04.02 LTS und Windows 2008 R2 virtualisiert werden. Die vom Server bereitgestellten Dienste können von einem Client genutzt werden. Die Konfigurationen sind von
den Serveradministratoren vorzunehmen. Neben diesen Betriebssystemen besteht Bedarf an diverser anderer Software, die entweder die projektinternen organisatorischen
Aufgaben oder das Design und die Entwicklung der Software Jinengo im weiteren Sinne
unterstützen.
Zweckmäßig müssen solche Softwarekomponenten entsprechend auf dem Server oder auf
dem Client installiert werden. Während serverseitige Software zur Nutzung durch alle
Projektgruppenmitglieder dient, wird clientseitige Software auf dem lokalen Rechner des
jeweiligen Projektgruppenmitglied benutzt.
Diese Anwendungen sollen nachfolgend kurz aufgeführt werden.
2.3.1. Serverseitige Software
Als serverseitige Software, für deren Installation der Serveradministrator verantwortlich ist, wird hauptsächlich das Projektmanagement-Tool Redmine eingesetzt. Darüber
hinaus wird die CRM-Lösung Dynamics CRM Online 2011 von Microsoft zur Haltung
und Verwaltung der Jinengo-Kundendaten verwendet, die auf einem externen Server von
Microsoft gehostet wird.
Redmine
Allgemein ist unter Redmine eine webbasierte Projektplanungs- und managementsoftware zu verstehen, die auf Ruby on Rails basiert. [1] Dieses Werkzeug stellt das Ergebnis
eines Auswahlprozesses mit verschiedenen Open-Source-Groupware-Produkten dar. Die
Entscheidung für Redmine ist in erster Linie darauf zurückzuführen, dass es die folgenden Anforderungen der Projektgruppe erfüllt:
14
2.3. Software
Redmine bietet alle grundlegenden Funktionen, die die Projektgruppe benötigt
Redmine ist ein plattformunabhängiges Werkzeug
gute Bedienbarkeit und Erlernbarkeit
Mehrsprachigkeit
zahlreiche Plug-Ins
Durch Redmine ist die Planung eines Projektes bis auf die Ebene der einzelnen Aufgaben
möglich. Die einzelnen Funktionen werden im Folgenden beschrieben. [1]
Issue-Tracking-System. Das integrierte Issue-Tracking-System ermöglicht, den Workflow der Issues für jeden Issue-Typ und jede Rolle beliebig zu konfigurieren. Der
Typ der Issues wird durch Tracker, beispielsweise Fehler, Feature, Unterstützung
usw. bezeichnet. Die Status der Issues können vom Benutzer definiert werden, wie
z.B. Neu, In Bearbeitung, Gelöst, Feedback usw. Somit kann die Bearbeitung der
Aktivitäten verfolgt und deren Erledigung kontrolliert werden.
Respository und Zugriff auf Versionsverwaltungssystem. Das Respository in Redmine dient zur Verwaltung und Versionierung der Dokumente und Dateien. Darüber hinaus bietet Redmine die Möglichkeit, auf unterschiedliche Versionsverwaltungssysteme zuzugreifen, damit die Versionsstände angeschaut bzw. verglichen
werden können. Das von der Projektgruppe verwendete Versionsverwaltungssystem ist Subversion.
Wiki und Forum. Das in Redmine eingebundene Wiki steht für die Bereitstellung
des Projektwissens zur Verfügung. Die Projektgruppe Jinengo verwendet das Wiki
als Lexikon, in dem sowohl organisatorische (z.B. Urlaubplanung, ProjektgruppenKontoauszug), als auch technisch-relevante Informationen für das Projekt enthalten sind. Im Forum können verschiedene Themen diskutiert werden.
DST: die Liste hier ist doch unvollständig. Hier fehlt noch die JVM
MYSQL
Als serverseitige Datenbank wird Mysql verwendet. In dieser Datenbank werden lediglich
die Nutzernamen und Passwörter der Nutzer sowie die beschreibungen der hochgeladenen Agenten gespeichert. Kundenbezogene Daten wie Präferenzen oder ähnliches werden
nicht in der Mysql-Datenbank sondern im CRM hinterlegt.
15
ALL: Fällt noch jemandem hier was ein?
SQL Server2008 R2
Um die kundenbezogene Daten zu bearbeiten und verwalten wird SQL Server 2008 R2
als Datenbanksystem für Jinengo verwendet. SQL Server 2008 R2 ist eine integrierte
Lösung für Datenanalyse und -verwaltung. Als eine sichere, zuverlässige und skalierbare
Datenverwaltungsplattform vereinfacht SQL Server 2008 R2 gleichzeitig die Erstellung
und Verwaltung der Daten.
Microsoft Dynamics CRM Online 2011
Die Software Jinengo soll an mindestens ein customized CRM-System angebunden werden. Die kundenbezogenen Daten werden in diesem CRM-System gehalten und verwaltet, das Ansätze für ein Kundenbeziehungsmanagement unter Gesichtspunkt der Nachhaltigkeit integriert. Als CRM-System wird Microsoft Dynamics CRM Online 2011 genutzt.
Microsoft Dynamics CRM ist eine webbasierte Geschäftssoftwarelösung, die es Unternehmen aller Größen ermöglicht, Kunden- oder Clientinteraktionen zu verfolgen und zu
verwalten, sowie Berichte zu erstellen. [2, S.29f.]
Microsoft Dynamics CRM 2011 muss angepasst werden, indem das Datenmodell für das
Jinengo-System eingeführt wird. Daran anschließend wird dieses CRM-System an das
Jinengo-System durch eine Webservice-Schnittstelle angebunden.
2.3.2. Clientseitige Software
Clientseitige Software wird auf den persönlichen Rechnern der einzelnen Projektgruppenmitglieder installiert. Die hier aufgezeigten Softwarekomponenten unterstützen vorwiegend das Softwaredesign und die Softwareentwicklung im weiteren Sinne. Lediglich
die Komponente LATEXunterstützt das Erstellen der Projektdokumentation.
Folgend wird auf die clientseitigen Softwarekomponenten näher eingegangen.
Eclipse IDE for Java Developers
Eclipse ist ein Open-Source-Programmierwerkzeug zur Entwicklung von Software verschiedenster Art. Aufgrund seiner Erweiterbarkeit wird es für viele unterschiedliche Ent-
16
2.3. Software
wicklungsaufgaben eingesetzt. [3] Eclipse IDE for Java Developers dient der Projektgruppe als Java IDE. Um die Programmierprojekte mit dem Repository auf Redmine zu
synchronisieren, wird das Plugin Subversive SVN benutzt.
ArgoUML
ArgoUML ist ein Java-basiertes, freies, plattformunabhängiges UML-Werkzeug, das die
notwendigen UML-Standarddiagramme abdeckt und zur Beschreibung, Modellierung
und Simulation von Software-Systemen und zur Code-Generierung dient. [4] Dieses Tool
ist nach Erfahrung vieler Projektgruppenmitglieder sehr einfach zu bedienen.
Microsoft Project 2010
Microsoft Project 2010 ist ein Werkzeug für die Planung und Überwachung von Projekten. Die Besonderheit des Produkts ist die Integration in die Microsoft Office-Softwarelandschaft und die Verbindung zu Entwicklungswerkzeugen des Herstellers. Im Idealfall
wird ein Project Server eingesetzt, der mit einer Sharepoint-Instanz, einem Exchange
Server sowie mit einem Team Foundation Server kommuniziert. Auf diesem Wege ist die
Einbindung verschiedenster Kommunikationswege in die Projektüberwachung möglich.
Innerhalb des Projekts Jinengo wird Project 2010 als Einzelplatzlösung durch den Projektmanager verwendet. Die Kommunikation über den Projektfortschritt erfolgt direkt
oder über die Redmine-Lösung. Hintergrund ist die geringe Teamgröße und der Aufwand
zum Betrieb einer vollständigen MS Project-Plattform. MS Project wird eingesetzt, um
eine interne Ressourcenplanung durchzuführen und die Terminierung von Meilensteinen
zu bestimmen.
Microsoft Visual Studio 2010
Microsoft Visual Studio 2010 bietet Entwicklungswerkzeuge für das Entwerfen, Programmieren und Testen von Software und Diensten, die auf Windows-Computern, im Web
oder in der Cloud ausgeführt werden. [5] Das integrierte .NET Framework wird als Entwicklungsplattform für das Frontend der Software Jinengo für mobile Geräte wie z.B.
Smartphones usw. eingesetzt. Des Weiteren wird Visual Studio beim Customizing vom
Microsoft Dynamics CRM Online 2011 genutzt.
17
SQL Server 2008 Management Studio - SSMS
SQL Server 2008 Management Studio ist eine integrierte Umgebung zum Zugreifen,
Konfigurieren, Verwalten und Entwickeln aller Komponenten von SQL Server. [6] Als
ein grafisches Verwaltungsool bietet SQL Server Management Studio eine funktionsreiche
Umgebung zum Verwalten und Entwickeln von Abfragen an. Jinengo verwendet SSMS
auf den Client um die Quelldaten in SQL Server einzuordnen.
Protege 4.1
Protege ist ein frei Ontologie-Editor zur Wissensmodellierung und plattformunabhängig.
Wissensdatenbanken können mit Protege auf zwei Arten angelegt werden:Protege-frames
und Protege-OWL. Protege-frames arbeitet mit dem frame-basierten Ansatz der Wissensrepräsentation, der Informationen über bestimmtes Domänenwissen in einer hierarchischen Struktur von Konzepten, Attributen von Konzepten (Slots) und KonzeptInstanzen (Individuen) vorsieht. [7] Protege-OWL unterstützt OWL Ontolgie und enthält
alle benötigten Module für die Verarbeitung von OWL-Ontologien. Jinengo verwendet
Protege um Ontologie Graph zu zeichnen.
SVN Client
Um auf die serverseitig im Redmine Repository gehaltenen Daten zuzugreifen und sie
bearbeiten zu können, ist es notwendig, auf dem lokalen Rechner einen entsprechenden
SVN-Client zu installieren. Es wurde beschlossen, dass die Projektgruppenmitglieder
die bei ihnen eingesetzte SVN-Client-Software selbst wählen können. Beispielsweise wird
von vielen Projektgruppenmitgliedern das Tool TortoiseSVN eingesetzt, was eine leicht
bedienbare Versionsverwaltungssoftware für Microsoft Windows ist. [8] Unter Linux wird
z.B. RapidSVN verwendet.
LATEX
Die komplette Projektdokumentation, Seminarausarbeitungen sowie die Meetingprotokolle der Projektgruppe werden im LATEX-Format erstellt. LATEXübernimmt die gesamte Formatierung und liefert erstklassige, typographische Ergebnisse. Die Vorlagen der
LATEX-Dateien werden vom Dokumentenbeauftragten bereitgestellt. Das hierzu eingesetzte LATEX-Tool ist z.B. MiKTeX, das eine TeX-Distribution für Microsoft WindowsBetriebssysteme darstellt. [9] Für das Linux-Betriebssystem wird beispielsweise Kile (eine integrierte LATEX-Umgebung) genutzt.
18
3. Grundlagen
Mobilität ist eine wesentliche Grundlage des modernen Lebens, eine elementare Voraussetzung für die Erfüllung menschlicher Bedürfnisse. Ohne Mobilitätssysteme könnten
die Menschen nicht annähernd so leicht Beziehungen zueinander pflegen, wie sie es heute
tun.
Es wird aber auch immer klarer, dass wir den wachsenden Mobilitätsbedarf der Welt
nicht einfach mittels einer Ausweitung der heutigen Transportmittel befriedigen können.
Die Mobilitätssysteme müssen effizienter, gerechter verteilt, umweltfreundlicher und gesellschaftlich verträglicher werden und dabei mehr anstatt weniger Mobilität bieten.
3.1. Nachhaltigkeit
Das Prinzip der Nachhaltigkeit (Sustainability) gilt seit einigen Jahren als Leitbild
für eine zukunftsfähige Entwicklung der Menschheit und wird heute in vielen Zusammenhängen gebraucht. Der Begriff der Nachhaltigkeit wurde vor etwa 300 Jahren vom
Oberberghauptmann Hans Carl von Carlowitz in der Sibelstadt Freiberg in Bezug auf
Waldbewirtschaftung erwähnt. Der ursprüngliche Wortsinn von Nachhaltigkeit wurde
nach Konrad Ott in seinem Buchbeitrag Läßt sich das Nachhaltigkeitskonzept auf Wis”
sen anwenden“ im Jahr 1999 so definiert:
Regenerierbare lebende Ressourcen dürfen nur in dem Maße genutzt werden, wie Be”
stände natürlich nachwachsen.“
Dieser Begriff wurde bei der Suche nach einer geeigneten Übersetzung für die englischen
Wörter sustainable und sustainability zurückbesonnen.
Die 1983 von den vereinten Nationen eingesetzte Weltkommission für Umwelt und Entwicklung unter dem Vorsitz der ehemaligen norwegischen Ministerpräsidentin Gro Harlem Brundtland wurde beauftragt, langfristige Perspektiven für eine Entwicklungspolitik
aufzuzeigen, die zugleich umweltschonend ist. Im Zusammenhang mit dem Prinzip der
Nachhaltigkeit wurde in ihrem Abschlussdokument Unsere gemeinsame Zukunft“, auch
”
Brundtland-Bericht genannt, das Konzept der nachhaltigen Entwicklung folgendermaßen
definiert:
19
3. Grundlagen
Dauerhafte (nachhaltige) Entwicklung ist Entwicklung, die die Bedürfnisse der Gegen”
wart befriedigt, ohne zu riskieren, dass künftige Generationen ihre eigenen Bedürfnisse
nicht befriedigen können. Zwei Schlüsselbegriffe sind wichtig:
der Begriff Bedürfnisse‘, insbesondere die Grundbedürfnisse der Ärmsten der Welt
’
sollen Priorität haben
der Gedanke von Beschränkungen, die der Stand der Technologie und der sozialen
Organisation auf die Fähigkeit der Umwelt ausübt, gegenwärtige und zukünftige
Bedürfnisse zu befriedigen.“
Auf der Konferenz für Umwelt und Entwicklung der vereinten Nationen im Jahr 1992
in Rio de Janeiro wurde Nachhaltigkeit bzw. nachhaltige Entwicklung als normatives,
internationales Leitprinzip anerkannt und als Grundprinzip der Agenda 21 verankert.
Seit dem Rio-Gipfel 1992 bezieht sich Nachhaltigkeit nicht mehr nur vorrangig auf den
langfristigen Schutz von Umwelt und Ressourcen, sondern auch gleichberechtigt auf die
Berücksichtigung sozialer und ökonomischer Gesichtspunkte. Diese drei Aspekte werden
als Drei-Säulen-Modell der Nachhaltigkeit bezeichnet [10]. Heutzutage wird für immer
mehr Bereiche eine nachhaltige Entwicklung postuliert, z.B. für den individuellen Lebensstil oder für ganze Sektoren wie Mobilität und Energieversorgung.
3.2. Multimodale Mobilität
Unter multimodaler Mobilität versteht man die Fortbewegung mit wechselnder Nut”
zung von Verkehrsmitteln über einen bestimmten Zeitraum“. [11] Da das Konzept der
multimodalen Mobilität eine nachhaltige Fortbewegung im vollen Umfang unterstützten
kann, bildet es die Grundlage für die Jinengo-Plattform. Dabei gilt es, eine Verlagerung der klassischen PKW-Kilometer auf öffentliche Verkehrsmittel, Car-Sharing- und
Car-Pooling-Angebote sowie auf die Nutzung von elektrisch betriebenen Fahrzeugen zu
erreichen. So soll eine möglichst nachhaltige Fortbewegung eines Jinengo-Nutzers sichergestellt werden.
Jinengo bietet dem Nutzer dafür die Möglichkeit, eine Strecke durch eine Kombination
der für die spezifische Route nachhaltigsten Verkehrsmittel zu planen. Diese nachhaltige
und multimodale Routenplanung wird durch den Einsatz verschiedenster Routenplanungsagenten ermöglicht.
3.2.1. Motivation für multimodale Mobilität
Die aktuelle Situation der Automobilindustrie ist gekennzeichnet durch eine Konjunkturund Strukturkrise. Hinzu kommen die immer rationalere Betrachtung des Autos und der
20
damit einhergehende, symbolische Bedeutungsverlust als auch die bisherige Missachtung
des Klimawandels und die Nichtbeachtung endlicher fossiler Ressourcen. [12]
Enorme Zuwächse des allgemeinen Verkehrs über die vergangenen Jahrzehnte verbesserten die Verkehrsangebote und bewirkten eine grössere Auswahl an VerkehrsmittelAlternativen. Die Belastung des Verkehrssystems hingegen nimmt zu. Die mittlerweile
zur Verfügung stehende Wahlfreiheit eines Verkehsmittels wird unzureichend genutzt und
lässt hinterfragen, ob die Nachfrage in Bezug auf eine optimierte Verkehrsmittelnutzung
manipuliert werden kann. [13]
3.2.2. Ziele multimodaler Mobilität
Ziele der multimodalen Mobilität lassen sich in dem Maße zusammenfassen, dass ein
hoher Grad an Flexibilität in der Wahl des Verkehrsmittels gewünscht und vor allem
zweckgebunden sein soll. Das bedeutet, einen sinnvollen, optimierten Umgang mit der
Vielzahl an vorhandenen Verkehrsmitteloptionen zu pflegen, der sowohl situativ angemessen ist, als auch Kontextmerkmale berücksichtigt. [12]
3.2.3. Begriffliche Abgrenzung
Die bereits definierte multimodale Mobilität wird neben der intermodalen Mobilität unter
dem Begriff komodale Mobilität zusammengefasst. [14]
Intermodale Mobilität beschreibt das Zurücklegen eines Weges mit mehreren Verkehrsmitteln. Beispiel hierfür ist die Nutzung des Fahrrads zum Zug. [14]
Komodale Mobilität definiert die Europäische Kommission als die effiziente Nutzung
”
einzelner Verkehrsmittel oder ihrer Kombination“. [14] Somit setzt sich die komodale
Mobilität sowohl aus multimodaler als auch intermodaler Mobilität zusammen.
3.2.4. Multimodale Mobilität als Basis für die Jinengo Plattform
Da das Konzept der multimodalen Mobilität eine nachhaltige Fortbewegung im vollen
Umfang unterstützten kann, bildet es die Grundlage für die Jinengo-Plattform. Dabei
gilt es, eine Verlagerung der klassischen PKW-Kilometer auf öffentliche Verkehrsmittel,
Car-Sharing- und Car-Pooling-Angebote sowie auf die Nutzung von elektrisch betriebenen Fahrzeugen zu erreichen. So soll eine möglichst nachhaltige Fortbewegung eines
Jinengo-Nutzers sichergestellt werden. Jinengo bietet dem Nutzer dafür die Möglichkeit,
eine Strecke durch eine Kombination der für die spezifische Route nachhaltigsten Verkehrsmittel zu planen. Diese nachhaltige und multimodale Routenplanung wird durch
21
3. Grundlagen
den Einsatz verschiedenster Routenplanungsagenten ermöglicht.
Die Elektromobilität gilt momentan als das zukunftsträchtigste Verkehrsmittel im deutschen Verkehrssystem. Der Plan der Bundesregierung, bis 2020 mindestens 1 Million
Elektroautos auf die deutschen Straßen zu bringen, zeigt, was für einen enormen Stellenwert diese Fahrzeugklasse in Zukunft haben wird. Natürlich ist die aktuelle Zahl von
Elektroautos auf den Straßen momentan noch verschwindend gering. Gründe dafür liegen momentan noch vor Allem in den hohen Kosten und den geringen Reichweiten dieser
Fahrzeuge. Prognosen von verschiedenen Studien besagen jedoch, dass die Preise für den
Li-Ionen Akku, welcher momentan mit ca. 600Euro/kWh noch eines der teuersten Teile
an einem Elektroauto ist, sich in den nächsten Jahren mindestens halbieren wird. Auch
die Reichweite soll sich in der nächsten Zeit deutlich erhöhen, wie zum Beispiel schon
jetzt das Technologieunternehmen DBM Energy mit ihrer 600-Kilometerfahrt bewiesen
hat.
Die aktive Förderung von Elektroautos durch die Bundesregierung, welche sich zum Beispiel schon jetzt in der Befreiung von der Kfz-Steuer in den ersten fünf Jahren zeigt,
verspricht zukünftig deutliche Kostenvorteile für Elektroautos. Bereits zum jetzigen Zeitpunkt ist das Fahren mit dem Elektroauto bei einem Verbrauch von 20 kWh / 100km
bezogen auf die reinen Energiekosten deutlich billiger als die Fahrt mit einem Benziner
oder Diesel. Zusätzlich lässt die bis zum Jahr 2020 zu erwartende deutliche Erhöhung des
Ölpreises einen weiteren Anstieg der Kosten eines Fahrzeuges mit Verbrennungsmotor
vermuten.
Weiterhin sind die Lebenszyklus-Emissionen eines Elektroautos, zumindest bei der Verwendung von regenerativen Energien zum Aufladen des Akkus, bereits zum jetzigen
Zeitpunkt geringer als die eines Fahrzeuges mit Verbrennungsmotor. In Zukunft ist weiterhin damit zu rechnen, dass die Stromerzeugung durch den Ausbau der regenerativen
Energiequellen sehr viel emissionsärmer wird.
3.2.5. Vorteile multimodaler Mobilität
Multimodale Mobilität bietet Vorteile in den Bereichen der Kosteneinsparungen, Nutzenvorteil, Umweltbeitrag und Verkehrssicherheit. Kosteneinsparungen ergeben sich in Ballungsräumen mit hoher Bevölkerungs- und Arbeitsplatzdichte. So geben Städte beispielsweise weniger Geld für Verkehr aus, in denen Menschen unterschiedliche Verkehrsmittel
in Anspruch nehmen. Einzelne Wege sind tendenziell im öffentlichen Verkehr günstiger
als die Fortbewegung mit dem PKW. Weitere Kostenvorteile ergeben sich durch die Nutzung des Fahrrads oder durch Fußwege. Der Nutzenvorteil ergibt sich aus der Nutzung
an Stelle des Besitzes eines PKWs. Es entfallen der Kauf und der Betrieb eines eigenen
PKWs. Das eigene Auto steht nicht mehr unnötig mehr als die hälfte des Tages herum.
Car-Sharing Autos hingegen werden sehr intensiv betrieben. Haushalte können ihre Ausgaben durch einen optimierten Verkehrsmittelmix, bestehend aus öffentlichem Verkehr,
22
Fahrrad, Taxi und Car-Sharing um mehr als die Hälfte senken. Rund 70 Prozent der
1.297 Millionen Tonnen CO2 -Äquivalente der EU27 lassen sich auf den Strassenverkehr
zurückführen. Alleine in Österreich entspräche eine Senkung der PKW-Fahrleistungen
pro Person und Tag einer Reduzierung von 1,5 Millionen Tonnen CO2 -Ausstoss pro Jahr.
Multimodale Mobilität trägt neben der Reduktion von CO2 -Ausstoss zusätzlich zu einer
Lärmminderung bei, insbesondere in Wohngebieten wo Einkäufe zu Fuss oder mit dem
Rad erledigt werden können. [14]
23
Teil II.
Anforderungsdefinition
25
4. Pflichtenheft Teil A
Elektromobilität ist momentan, als Alternative zu CO2 -ausstoßenden Fahrzeugen mit
Verbrennungsmotor, ein Thema, das ein großes Potenzial aus Sicht der nachhaltigen Mobilität als auch für neue Wirtschaftszweige und Geschäftsmodelle aufweist. Im Rahmen
des Projektes Jinengo wird eine mobile Web-Applikation für einen Elektromobilitätsservice entwickelt. Dieser Mobilitätsservice berücksichtigt neben der Elektromobilität
auch andere Mobilitätsangebote wie z. B. Car-Sharing oder Bahnfahrten. Momentan
gibt es auf dem Markt noch kein multimodales Routenplanungssystem, das dem Kunden unter Berücksichtigung des Nachhaltigkeitsaspektes individuelle Routenvorschläge
anbietet. Ziel dieser Projektgruppe ist es, eine Web-Applikation zu entwickeln, die eine
individuelle, nachhaltige Routenplanung ermöglicht und die Kunden- und Verbindungsanfragen im Sinne einer CRM-Strategie betrachtet. Auf Basis der so gesammelten Daten
soll später ein Modell entstehen, das die Kunden dazu motiviert, sich nachhaltig fortzubewegen. Auf Basis von Interviews mit den Projektbetreuern wurden die Anforderungen
der Anwendung ermittelt und für dieses Dokument aufbereitet.
Die geplante Fertigstellung des Meilenstein A ist auf den 31.03.2011 festgesetzt.
4.0.6. Zweck des Systems
Das System soll dem Endanwender die Möglichkeit bieten, Routen nicht nur nach individuellen Anforderungen, sondern auch unter Betrachtung ökologischer Aspekte, wie
dem Energieverbrauch und der Umweltbelastung über eine Anwendung zu planen. Jeder Endanwender kann durch persönliche Angaben, wie z. B. Abfahrts- und Zielort,
Reisedatum, Kostenoptionen, Flexibilität, Bequemlichkeit usw. ein kombiniertes Mobilitätsangebot abfragen. Zu einem Mobilitätsangebot gehören detaillierte Informationen,
bspw. ein Routenplan, Kosten, Brennstoffverbrauch betroffener Verkehrsmittel, CO2 Emissionen usw., mit deren Hilfe der Anwender einen nachhaltigen Reiseplan auswählen
kann.
Außerdem wird der Anwender in einem CRM-System abgebildet. Die dort hinterlegten
Daten werden analysiert, um Marketingmaßnahmen für ein nachhaltiges Verhalten zu
ermöglichen.
27
4.0.7. Umfang des Systems
Das System soll eine Anwendung bereitstellen, welche verschiedene Mobilitätsservices
bzw. Agenten integrieren kann. Die Applikation ermöglicht den Abruf von Mobilitätsangeboten nach verschiedenen Kriterien und liefert detaillierte Informationen über diese
Angebote unter besonderer Berücksichtigung der Nachhaltigkeit. Die kundenbezogenen
Daten werden in einem CRM-System gehalten und verwaltet, außerdem werden Ansätze
für ein Kundenmanagement unter Gesichtspunkten der Nachhaltigkeit integriert. Die
Hauptfunktion des Systems ist es, nachhaltige Routenpläne anzubieten und die Anwender zur nachhaltigen Mobilität anzuregen.
4.0.8. Ziele und Erfolgskriterien des Projekts
Ziel des Projektes ist es, die in diesem Dokument beschriebene Funktionalität, sowie
weitere, später zu definierende Anforderungen innerhalb des jeweils vorgegebenen Zeitrahmens fertigzustellen. Die von uns festgelegten Meilensteine sollen ebenfalls innerhalb
der vereinbarten Fristen erfüllt werden. Das Projekt wird als erfolgreich angesehen, wenn
alle definierten Iterationen erfolgreich durchgeführt werden.
4.1. Vorhandene Systeme
Zur Einschätzung des potenziellen Marktes der neuen Dienstleistung sollen an dieser
Stelle vorhandene Angebote betrachtet werden, die eine vergleichbare Funktionalität
abdecken wie Jinengo. Anschließend wird beschrieben, inwiefern sich Jinengo von diesen
Angeboten abgrenzt und welchen potenziellen Mehrwert es gegenüber den anderen Angeboten haben soll. Die folgende Auswahl bietet einen Überblick vergleichbarer Angebote
bezogen auf den deutschen Markt.
4.1.1. Deutsche Bahn AG (DB)
Die Hauptleistung der Bahn ist die Personenbeförderung, die hauptsächlich in Deutschland stattfindet. Als zusätzlichen Service bietet die Bahn einen umfangreichen Fahrtenplaner an, der im Folgenden kurz vorgestellt wird.
Der Fahrtenplaner ist über das Internet erreichbar und wird auch als iPhone-Applikation
angeboten. Reiseziele können straßengenau angegeben werden, wobei auch viele europäische Städte erfasst sind. Der Abfahrts- bzw. Ankunftszeitpunkt kann beliebig gewählt werden, muss jedoch in der Zukunft liegen. Als Transportmittel sind neben den
28
4.1. Vorhandene Systeme
unternehmenseigenen Angeboten auch die Dienstleistungen weiterer Anbieter des öffentlichen Personenverkehrs integriert. Dazu zählen die Züge der DB, Privatbahnen wie
die NordWestBahn, sowie ausländische Züge in Europa und teilweise darüber hinaus,
sämtliche Bus- und Straßenbahnlinien der deutschen Verkehrsverbünde, europäische
Fährverbindungen sowie die Möglichkeit, kurze Strecken zu Fuß zurückzulegen. Das
Ergebnis einer Anfrage besteht aus Abfahrts-, Umsteige- und Ankunftszeiten, wobei
zunächst mehrere Alternativfahrten dargestellt werden. Größtenteils kann der Fahrpreis
ermittelt werden. Eine interaktive Karte zeigt den Routenverlauf. Dazu können Informationen zu den Bahnhöfen abgefragt werden. Die Funktion Mobil-Check erlaubt Informationen über diverse alternative Fortbewegungsmittel anzuzeigen. So werden für Fußweg,
Fahrrad, Taxi und Pkw die benötigte Dauer sowie die Streckenlänge in km angezeigt.
Zusätzlich werden zur Pkw-Alternative auch die entstehenden Kosten aufgelistet, wobei
standardmäßig ein Kosten-faktor von 23 Cent/km angelegt wird. Fahrzeugklasse und
Km-Jahresleistung lassen sich dabei nach Wunsch ändern und es kann ein individueller
Km-Kostenfaktor festgesetzt werden.
Der Umwelt-Mobil-Check vergleicht, ähnlich wie der Mobil-Check, die Transportmittel
Bahn, Pkw sowie Flugzeug miteinander. Zusätzlich zur Dauer werden umweltbezogene Faktoren in drei Balkendiagrammen dargestellt. Das Energieressourcenverbrauchsdiagramm zeigt den Rohstoffverbrauch/Primärenergie umgerechnet in Liter Treibstoff
pro Person und Fahrt. Das Kohlendioxiddiagramm zeigt die Emission an Treibhausgas
(CO2 -äquivalent) in kg pro Person und Fahrt und das Feinstaubdiagramm zeigt die
Feinstaubemissionen an. Alle drei genannten Diagramme berücksichtigen die Strom- /
Kraftstoffherstellung. Eine Tabelle fasst die Ergebnisse nochmals zusammen. In einer
erweiterten Option lassen sich zusätzlich Diagramme über Luftschadstoffe einblenden.
Sie geben Aufschluss über entstehendes Schwefeldioxid, Stickoxide sowie Nicht-MethanKohlenwasserstoffe. Weiterhin gibt es ein Diagramm, welches den Energieverbrauch
des Fahrzeugs ab der Tankstelle darstellt, sowie ein Feinstaubdiagramm, welches den
während der Fahrt entstehenden Feinstaub beziffert.
4.1.2. Flinc
Flinc ist ein Dienst, der als Website von PC, mobilen Endgeräten sowie mit Hilfe von
Navigationssystemen genutzt werden kann. Der Dienst zielt darauf ab, spontane Mitfahrten in Echtzeit zu vermitteln. Derzeit (Stand 18.12.2010) ist Flinc nur im Testgebiet
Friedrichshafen im Einsatz. Ab 2011 soll es auf weitere Regionen ausgeweitet werden.
Teilnehmende Pkw-Fahrer geben über ihr Navigationssystem ihre Route bekannt. Mitfahrgelegenheitssuchende geben über die Webseite ihren Wunschort ein, woraufhin zutreffende Mitfahrgelegenheiten ermittelt werden. Der Fahrer wird anschließend zum Mitfahrer gelotst. Vor der Anfrage beim Fahrer wird der Preis für die Mitnahme dem Interessenten angezeigt und nachgefragt, ob er das Angebot annimmt oder ablehnt. In einem
29
Fahrtenbuch können die gefahrenen Kilometer und die entstandenen Kosten festgehalten werden. Fahrer und Mitfahrer können sich nach erfolgter Fahrt bewerten, um auf
diesem Wege Bewertungspunkte zu sammeln. Die Kosten der Nutzung des Dienstes sind
derzeit nicht bekannt. Flinc als Unternehmen wurde von Studenten aus Darmstadt als
universitäre Ausgründung begonnen.
4.1.3. Klima-Sucht-Schutz.de
Diese Webseite ist eine Kampagne, welche durch das Bundesumweltministerium gefördert wird. Es werden Themen zum Klimaschutz sowie Ratgeber zum Energiesparen
kostenlos angeboten. Unter anderem wird die Umweltverträglichkeit von diversen Transportmitteln in redaktionell aufbereiteten Artikeln bereitgestellt. Von Interesse für das
vorliegende Projekt ist der UmweltMobilCheck auf Klima-Sucht-Schutz.de. Dabei handelt es sich um den Service der Bahn (Abschnitt 4.1.1), welcher in die Webseite integriert
ist und teilweise angepasst wurde. In seiner Grundfunktionalität ist dieser Service jedoch
identisch zu dem der Bahn.
4.1.4. Sourcemap.org
Der Webdienst von sourcemap.org ist eine Plattform zur Erforschung und Optimierung
von Wertschöpfungsketten, um diese dann ggf. daraufhin mit anderen Anwendern zu teilen. Der Dienst hat es sich zur Aufgabe gemacht, aufzuzeigen, wo Produkte herkommen
und aus was sie hergestellt wurden. So können Wertschöpfungsketten angelegt werden
und einzelne Teilprodukte je nach Transportmittel und Strecke automatisch mit CO2 Äquivalenten belegt werden. Das Endprodukt erhält somit einen Gesamt-CO2 -Wert der
dem Endbenutzer aufzeigen soll, welche Wirkung das Produkt auf die Umwelt hat.
4.1.5. Car2gether
Car2gether ist ein Webservice, der vergleichbar mit dem Angebot Flinc Fahrgemeinschaften arrangiert. Über eine Webseite geben Fahrer und Mitfahrer ihre Routen ein. Der
Fahrer kann sich daraufhin für Mitfahrer entscheiden. Diese werden per SMS informiert
und können dem Angebot zusagen. Ein Bewertungssystem für Fahrer und Mitfahrer ist
ebenfalls integriert. Die Nutzung ist kostenlos.
30
4.2. Anforderungen
4.1.6. Car2go
Car2go ist ein Car-Pooling-Service, welcher in Ulm bereits verfügbar ist und im ersten Quartal 2011 auf Hamburg ausgeweitet werden soll. Aus einem Car-Pool, bestehend
aus Smart-Pkws, lassen sich Fahrzeuge minutengenau mieten. Das Mietvorhaben kann
telefonisch oder über eine Webseite bis zu 24 Stunden im Voraus erfolgen. Die Fahrzeugrückgabe ist flexibel innerhalb eines festgelegten Stadtbereichs überall möglich. Mit
diesem Modell werden die zur Verfügung stehenden Pkw besser ausgenutzt als Pkw,
welche im Privatbesitz sind. Der Minutenpreis beträgt 19 Cent.
4.1.7. Abgrenzung zu Jinengo
Die oben aufgeführten Dienstleistungen decken bereits ein breites Spektrum ab. So bietet die Bahn CO2 Berechnungen, Flinc nutzt die Möglichkeit der Standortbestimmung
und Car2go bietet ein flexibles Vermietungsmodell für Pkw an. Diese Lösungen bilden
i.d.R. einen Anwendungsfall ab, der an ein bestimmtes Geschäftsmodell gebunden ist.
Das Projekt Jinengo soll die Verschmelzung dieser sehr unterschiedlichen Ansätze realisieren. Dem Nutzer wird die Gelegenheit geboten, eine Route zu planen, es werden
neben einer Vielzahl an Transportmitteln auch die Vorlieben des Nutzers berücksichtigt
und so dem Nutzer die Möglichkeit gegeben, eine Entscheidung auf Basis vielfältiger
Informationen zu treffen. Zudem sind zu jeder Alternative Informationen abrufbar, die
Auskunft über die Nachhaltigkeit geben wie z.B. die CO2 -Diagramme der Bahn. Im
Unterschied zu anderen Anwendungen wird bei Jinengo der Gedanke des Customer Relationship Managements als zentraler Ansatz zur Erfüllung von Kundenanforderungen
beachtet.
4.2. Anforderungen
Dieser Abschnitt fasst die Ergebnisse der Interviews zusammen.
4.2.1. Funktionale Anforderungen
Die funktionalen Anforderungen beschreiben, welche Kriterien aus Anwendungs- sowie
aus architektonischer Sicht an die Anwendung gestellt werden.
31
Architektonische Anforderungen
Die Anwendung soll architektonisch dem von Ammar Memari entwickelten Adaptable
Application Reference Model (AAARM) folgen. In der ersten Iteration werden die Module User Model, Adaptation Engine, Content Manager des Modells prototypisch implementiert und eine CRM-Anbindung realisiert. In späteren Iterationsstufen besteht die
Möglichkeit, diese Module bzw. die Anwendung an sich zu erweitern.
User Model Das User Model module soll Daten über jeden einzelnen Nutzer speichern.
Diese Daten werden genutzt, um das Wissen und die Ziele des Nutzers abzubilden. Dabei
kann es sich sowohl um Stammdaten als auch um Informationen über Interaktionen des
Nutzers, mit der Anwendung handeln.
Adaptation Engine
In der ersten Iteration werden von den in der Adaptation Engine zu definierenden Adaptationregeln mindestens zwei Regeln implementiert.
Evolution Chamber Mit dem Evolution Chamber werden Feedbacks vom Anwender
über die verwendeten Agenten gesammelt und ausgewertet. Weiterhin soll über das Behavior Repository die Möglichkeit gegeben werden, neue Agenten zum System hinzuzufügen. In der ersten Iteration ist eine entsprechende Schnittstelle zu definieren. Als
Nutzerfeedback soll die Vorgabe zur Verwendung oder Ausblendung eines Agenten gespeichert und durch die Genetic Engine umgesetzt werden. In späteren Iterationen kann
das Feedback, z. B. durch Vergabe von Punkten, verfeinert werden und es kann das
Nutzerverhalten anderer Nutzer zur Bewertung einbezogen werden.
CRM-Anbindung Das System soll eine Schnittstelle zur Anbindung von Customer-Relationship-Management-Systemen enthalten. Der Zweck dieser Anbindung ist das Persistieren von Verbindungsanfragen, die an das System gestellt werden. Hierzu werden
sämtliche Details einer Verbindungsanfrage zusammen mit der ID des Endkunden an
das CRM-System übergeben.
Ein weiterer Zweck dieser Anbindung ist das Abfragen von Daten über einen Kunden.
Diese Daten dienen zur Erstellung eines User-Models. Außerdem können diese Daten
genutzt werden, um den Endkunden beispielsweise über seine bisherigen Anfragen zu
informieren.
Aus diesen Anforderungen ergeben sich zwei Hauptfunktionen für die zu erstellende
32
4.2. Anforderungen
Schnittstelle: Eine Funktion muss das Anlegen einer Endkundenanfrage im angebundenen CRM-System erlauben, die zweite Funktion dient dem Abfragen von Daten eines
Kunden.
Weitere Funktionen der Schnittstelle sind das Anlegen eines neuen Endkunden, sowie
das Deaktivieren, bzw. Anonymisieren eines Endkundenkontos.
Die Schnittstelle ist so allgemein zu formulieren, dass unterschiedliche CRM-Systeme
angebunden werden können. Die mit dem CRM-System auszutauschenden Geschäftsobjekte werden durch Jinengo vorgegeben.
Zur Anbindung eines konkreten CRM-Systems wird eine sog. CRM-Komponente erstellt, die o.g. Schnittstelle implementiert. Aufgabe einer solchen Komponente ist die
Interaktion mit dem jeweiligen CRM System, sowie die Abbildung der Geschäftsobjekte
aus Jinengo auf die Daten des CRM-Systems und umgekehrt. Jinengo muss mindestens
ein am Markt relevantes CRM-System unterstützen. Mit der ersten Iteration muss eine
Realisierung zur Anbindung eines CRM-Systems umgesetzt werden.
Nutzerfunktion
In dem System muss zwischen zwei verschiedenen Nutzergruppen unterschieden werden: Zum einen gibt es den Endnutzer, welcher die eigentliche Servicefunktionalität der
Anwendung verwendet. Unabhängig von dem Endgerät kann dieser auf das JinengoWebinterface zugreifen und dort die zur Verfügung gestellten Funktionalitäten nutzen.
Die Kernfunktion für den Nutzer ist dabei die Möglichkeit zur nachhaltigen Routenplanung. Zusätzlich soll bereits in der ersten Iterationsstufe mindestens ein Agent für
die Berechnung von Nachhaltigkeitsaspekten zur Verfügung gestellt werden. Der Nutzer
kann später ein eigenes Profil erstellen und verwalten. Der genaue Umfang eines solchen
Profils ist in dieser Iterationsstufe noch nicht festgelegt.
Die zweite Nutzergruppe beinhaltet die Nutzer des Systems, welche neue Implementierungen von verschiedensten Agententypen vornehmen. Dieser Nutzertyp interagiert
nicht direkt mit dem System und nutzt deshalb nicht die eigentlichen Funktionalitäten.
Aus diesem Grund soll diese Gruppe nur implizit durch die zur Verfügung gestellten
Schnittstellen und Strukturen des Agentenframeworks berücksichtigt werden. Eine explizite Berücksichtigung, zum Beispiel ein eigener Bereich auf der Benutzungsoberfläche,
ist nicht vorgesehen.
Agentenfunktion
Das geplante System wird zur architektonischen Definition das Entwurfskonzept rund
um Software Agenten nutzen. Es wird ein Multi-Agenten System geplant, welches vorerst
33
in drei grobe Kategorien von Software Agenten unterteilt werden soll. Die Kategorien
der administrativen Agenten, der Routenplanungsagenten und der Schnittstellenagenten
sollen im Zusammenspiel die korrekte Ausführung der Software bewirken und somit den
Erfolg der Anwendung realisieren.
Agentenkategorien Zur Umsetzung des Konzepts sind mehrere heterogene Arten von
Softwareagenten einzusetzen. Die Agenten der verschiedenen Kategorien sollen grob nach
ihrem Verhalten und ihrem Beitrag zum Ziel der Anwendung aufgeteilt werden. Zu allererst ist aufzuzeigen, dass eine Gruppe von administrativen Agenten benötigt wird.
Diese Kategorie bildet den Kern der Anwendung und soll als höher gestellte Autorität
den richtigen Ablauf der anwendungsinternen Operationen beaufsichtigen. Viele sicherheitsrelevante Aufgaben werden an diese Kategorie vergeben. Diese administrativen Objekte steuern die Instanzierung der anderen Agenten und überwachen die Quellen von
neuen, mobilen Agenten. Diese Gruppe ist nur sehr geringfügig an den anwendungsdomänenspezifischen Aufgaben des Systems beteiligt.
Als Kernkategorie ist das Agentensystem der Routenplanungsagenten zu betrachten. Die
Aufgabe dieses Subsystems ist die Erstellung von Reiseplänen, welche hinsichtlich der
verschiedenen Kriterien des Endnutzers optimiert werden sollen. Hierbei handelt es sich
um persönliche Agenten, welche dem Benutzer helfen sollen, eine Route zu finden, die
seinen persönlichen Präferenzen entspricht. Hierzu zählt auch die Nachhaltigkeitsbewertung der gefundenen Strecken.
Da das System eine Vielzahl an Informationen aus externen Quellen verarbeiten soll, sind
eine Vielzahl unterschiedlicher Agenten notwendig. Die Aufgabe dieser Agenten wird es
sein, alle benötigten Informationen zu extrahieren, aufzubereiten und der Routenplanung
zur Verfügung zu stellen. Diese Agenten werden in Form von Schnittstellen im nächsten
Abschnitt näher erläutert.
Schnittstellen Die Kategorie der Schnittstellenagenten sammelt Informationen und bereitet diese auf.
Für benutzerbezogene Daten muss eine Schnittstelle zum angebundenen CRM-System
bereitgestellt werden. Darüber hinaus muss eine Menge von Agenten zur Beschaffung
von Informationen über Transportmöglichkeiten von Drittanbietern bereitgestellt werden. Diese Schnittstellenagenten müssen zusätzlich weitere Informationen auswerten, die
Einfluss auf die Wahl der Verkehrsmittel haben. Es sollen Schnittstellen zum Sammeln
von Informationen zur Berechnung der Nachhaltigkeit eingeführt werden. Diese sollen
Daten über den Schadstoffausstoß oder aktuelle Kraftstoffpreise ermitteln, sodass diese
in eine korrekte und vollständige Betrachtung und Bewertung eines Reiseplans einfließen
können und die Situation nutzerzentriert beurteilt werden kann.
34
4.2. Anforderungen
4.2.2. Nichtfunktionale Anforderungen
Nichtfunktionale Anforderungen beschreiben die Voraussetzungen an das zu erstellende
System in Bezug auf den Betrieb und die durchzuführende Entwicklung.
Bedienbarkeit
Die Bedienung Jinengos erfolgt über eine auf mobile Endgeräte angepasste Web-Applikation. Die Web-Applikation gilt dann als allgemein verwendbar, wenn die Mehrheit der im
Umlauf befindlichen Endgeräte den Zugriff auf die Anwendung erlauben. Vorausgesetzt
wird dabei, dass ein mobiles Endgerät mindestens über einen Webbrowser verfügt. Die
Benutzerschnittstelle ist auf die Einschränkungen durch die Bauform aktueller Endgeräte
hin anzupassen. Dem Anwender muss ein Hilfesystem zur Verfügung stehen.
Die Anwendung soll barrierefrei sein, um auch Menschen mit Behinderung den Umgang
mit ihr zu ermöglichen. Dabei sind die Grundsätze der Web Accessible Initiative (WAI)
zu berücksichtigen. Weiterhin ist das Behindertengleichstellungsgesetz (Deutschland) zu
berücksichtigen.
Zuverlässigkeit und Leistung
Im Folgenden wird auf die nichtfunktionalen Anforderungen in Bezug auf Zuverlässigkeit
und Leistung eingegangen.
Zuverlässigkeit Die Anwendung muss tolerant gegenüber Fehlern angebundener Systeme ausgelegt sein. Dies bedeutet, dass logische Fehler in externen Systemen nicht zu
einem Ausfall der Anwendung führen sollen.
Leistung Die Anwendung muss so konzeptioniert sein, dass sie linear zur Benutzerzahl
skaliert. In der ersten Iterationsstufe soll gezeigt werden, dass dieses Verhalten bis zu
einer Anzahl von 20 parallelen Zugriffen erreicht wird. Die zu transferierenden Daten
müssen gering gehalten werden, um auch für mobile Endgeräte eine schnelle Verwendung zu gewährleisten. Sollten Teile der Anwendung nicht verfügbar sein, ist der Nutzer
darüber in Kenntnis zu setzen.
35
Rechtliches
Bevor das System zum Produktiveinsatz kommt, müssen sowohl (a) der Rechtsraum, (b)
der Rechtsrahmen, als auch (c) datenschutzrechtliche Gesetze und Vorschriften berücksichtigt werden. Bezüglich der Webseite zur Präsentation der Projektgruppe und ihrer
Leistungen findet das Bundesdatenschutzgesetz als auch das Telemediengesetz Anwendung. Der Rechtsraum des Produktivsystems beschränkt sich zunächst auf Deutschland
(a), daher greift an dieser Stelle das Bundesdatenschutzgesetz (b). Es folgen die zu beachtenden datenschutzrechtlichen Grundprinzipien (c):
Zweckbindung: Die Daten sind nur dem bei der Beschaffung vorgesehenen Zweck oder
den ersichtlichen Umständen nach zu bearbeiten.
Rechtmäßige Beschaffung: Es liegt ein Rechtfertigungsgrund für die Ansammlung von
Daten vor, wenn sie beispielsweise in unmittelbarem Zusammenhang mit dem Abschluss
eines Vertrages erfolgt. Data-Warehousing und Data-Mining-Konzepte können sich derzeit nicht auf Rechtfertigungsgründe stützen. Das hat den Grund, dass weder die Daten
noch die Ergebnisse eine direkte Notwendigkeit für einen wirtschaftlichen Vorgang mit
einem betroffenen Nutzer aufweisen. Abhilfe verspricht in diesem Fall die Einwilligung
des Kunden.
Einwilligung: Eine Zweckänderung in der Datenbearbeitung ist mit der Einwilligung der
betroffenen Person möglich. Durch die Einwilligung, die zum Beispiel in den Allgemeinen
Geschäftsbedingungen befindlich sein kann, wird Data-Warehousing und Data-Mining
rechtlich sicher. Unklar ist dabei allerdings, ob mit einer Einwilligung eine unbestimmte Verwendung der Kundendaten erfolgen kann. Es ist eher davon auszugehen, dass
eine Vollmacht über die Nutzung der eigenen Daten nur dann rechtsgültig sein kann,
wenn die Datenbearbeitung für die betroffene Person zum Zeitpunkt der Einwilligung
ein Mindestmaß an Transparenz aufweist. Je sensibler die bearbeiteten Daten sind, je
weiter weg vom ursprünglichen Bearbeitungszweck sie sind und je weiter der Zugriffsbereich auf diese Daten ausgedehnt wird, desto höhere Anforderungen sind an eine solche
Einwilligungserklärung in Bezug auf die Transparenz zu stellen.
Transparenz : Der Grundsatz der Transparenz beschreibt den Umfang der Aufklärungspflicht bei Data-Warehousing und Data-Mining Konzepten, welche jedoch nicht allumfassend dargelegt werden kann. Jede Erklärung zur Einwilligung der Verarbeitung personenbezogener Daten muss so transparent sein, dass der Kunde Risiken direkt abschätzen
kann. Ein Rückzug der Einwilligung ist das Recht des Kunden.
Qualität: Da das Konzept des Data-Warehousing die Speicherung von Daten über einen
möglichst großen Zeitraum vorsieht, um ein Verhalten besser beurteilen zu können, ist
gerade hier ein Höchstmaß an Qualität der gesammelten Daten notwendig. Dies stellt eine
große Herausforderung dar, weil viele heterogene Datenquellen existieren und eine stetige
36
4.2. Anforderungen
Kontrolle auf Richtigkeit der Daten aufgrund mangelnder Transparenz nicht zugesichert
werden kann.
§4 Absatz 1, Zulässigkeit der Datenerhebung, -verarbeitung und -nutzung
Die Einwilligung der Nutzer ist obligatorisch. Eine Protokollierung darf nicht ohne weiteres umgesetzt werden: Die Erhebung, Verarbeitung und Nutzung personenbezogener
”
Daten sind nur zulässig, soweit dieses Gesetz oder eineandere Rechtsvorschrift dies erlaubt oder anordnet oder der Betroffene eingewilligt hat.“ [15]
§3a, Datenvermeidung und Datensparsamkeit
Bei der Protokollierung personenbezogener Daten gilt es eine minimale Menge zu speichern. Daraus resultierend sähe die ideale Speicherung so aus, dass maximal die Nutzerkennung gespeichert wird, mit der eine Person eindeutig identifiziert werden kann.
Die Erhebung, Verarbeitung und Nutzung personenbezogener Daten und die Auswahl
”
und Gestaltung von Datenverarbeitungssystemen sind an dem Ziel auszurichten, so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen.
Insbesondere sind personenbezogene Daten zu anonymisieren oder zu pseudonymisieren,
soweit dies nach dem Verwendungszweck möglich ist und keinen im Verhältnis zu dem
angestrebten Schutzzweck unverhältnismäßigen Aufwand erfordert.“ [16]
§28 Absatz 1, Datenerhebung und Datenspeicherung für eigene Geschäftszwecke
Bei der Erhebung von personenbezogenen Daten ist es unabdingbar zu dokumentieren,
welchem Zweck die Datenverarbeitung dient oder wofür die gesammelten Daten genutzt
werden.
(1) Das Erheben, Speichern, Verändern oder Übermitteln personenbezoge”
ner Daten oder ihre Nutzung als Mittel für die Erfüllung eigener Geschäftszwecke ist zulässig,
1. wenn es für die Begründung, Durchführung oder Beendigung eines rechtsgeschäftlichen oder rechtsgeschäftsähnlichen Schuldverhältnisses mit dem Betroffenen erforderlich ist,
2. soweit es zur Wahrung berechtigter Interessen der verantwortlichen Stelle
erforderlich ist und kein Grund zu der Annahme besteht, dass das schutzwürdige Interesse des Betroffenen an dem Ausschluss der Verarbeitung oder
Nutzung überwiegt, oder
3. wenn die Daten allgemein zugänglich sind oder die verantwortliche Stelle sie veröffentlichen dürfte, es sei denn, dass das schutzwürdige Interesse des Betroffenen an dem Ausschluss der Verarbeitung oder Nutzung gegenüber dem berechtigten Interesse der verantwortlichen Stelle offensichtlich
37
Service (Agent) Repository durchstöbern
<<include>>
<<include>>
Service (Agent) wählen, um die Nachhaltigkeit zu berechnen
Service (Agent) wählen um die Route zu planen
<<include>>
<<include>>
<<extend>>
1
1
Login am Webinterface
Neue Abfrage um eine nachhaltige Route zu planen
Jinengo Benutzer
<<include>>
Reisespezifische Benutzerpräferenzen einfügen
<<include>>
<<include>>
Zielort wählen
<<include>>
Transportmittel wählen
Andere Parameter wählen (persönliche Präferenzen)
Abbildung 4.1.: Anwendungsfall: Nachhaltige Routenplanung
überwiegt.“
[17]
Weitere wichtige Rechtsdefinitionen für den Betreiber/Anbieter sind allgemeine Geschäftsbedingungen und das Urheberrecht.
4.3. Anwendungsfälle
Im Folgenden sollen die für die erste Iterationsstufe relevanten Anwendungsfälle genauer
erläutert werden. Sie beschreiben zum einen, wie ein Endnutzer von Jinengo Anfragen
zur nachhaltigen Routenplanung an das System stellen kann. Zum anderen wird der
Anwendungsfall der Erstellung eines neuen Agenten durch die Nutzergruppe der Agentenentwickler dargestellt.
4.3.1. Nachhaltige Routenplanung
Dieser Anwendungsfall, der in Abbildung 4.1 zu sehen ist, beschreibt, wie der Endnutzer
in Jinengo eine nachhaltige Routenplanung vornehmen kann. Die Gestaltung der An-
38
Interfacedefinitionen & Agentenstruktur erhalten
<<include>>
1 1
Neuen Agenten erstellen
Agenten Entwickler
<<include>>
Verhalten implementieren
<<include>>
Agentenspezifikation dem Repository hinzufügen
Abbildung 4.2.: Anwendungsfall: Neuen Agenten erstellen
frage beinhaltet in dieser Evolutionsstufe bereits das Auswählen von Services (Agenten)
zur Planung der Route und zur Berechnung von Nachhaltigkeitsaspekten (z.B. CO2 Emissionen). Die ausgewählten Services (Agenten) sollen dabei abhängig von den vom
Benutzer eingetragenen Parametern wie dem Ziel oder dem gewünschten Verkehrsmittel
agieren.
4.3.2. Neuen Agenten erstellen
Entwickler sollen die Möglichkeit haben, die Jinengo-Plattform durch eigene Implementierungen von Services beziehungsweise Agenten zu erweitern. Damit dies möglich ist,
müssen sich die Autoren an die zur Verfügung gestellten Schnittstellen und Strukturen von Agenten halten. Es können lediglich konkrete Ausprägungen zu den definierten
Agentenkategorien, speziell zu der Kategorie der Routenplanungsagenten, implementiert
werden. Abbildung 4.2 beschreibt das grobe Vorgehen bei der Erstellung und Einbindung
eines Agenten für die Jinengo-Plattform.
4.3.3. Reise planen aus der Sicht des Reisenden
Für die Nutzer des Dienstes Jinengo stellt dies den wichtigsten Anwendungsfall dar.
Start- und Zielpunkt müssen in jedem Fall festgelegt werden. In einem späteren Meilenstein hat der Nutzer die Möglichkeit, seinen Standort als Start- oder Ziel zu verwenden.
39
Nutzerprofil berücksichtigen
Ergebis filtern
<<extend>>
<<include>>
1
1
Reise planen
Reisender <<include>>
<<include>>
Ergebnis wählen
<<include>>
<<include>>
Startpunkt festlegen
Reisezeitraum festlegen
Zielpunkt festlegen
Abbildung 4.3.: Anwendungsfall: Reise planen
40
Dies macht Sinn, da sehr oft der aktuelle Standpunkt auch gleichzeitig der Startpunkt
sein soll. Moderne Smartphones bieten hierzu eine Peilung mittels GPS.
Der Reisezeitraum ist ein Intervall. Der Nutzer legt also zwei Uhrzeiten fest, zwischen denen er gewillt ist, zu reisen. Somit können gewisse Transportmittel bereits ausgeschlossen
werden, die keinen Transport im vorgegebenen Zeitraum bewerkstelligen können. Neben
dem Zeitraum ist es auch möglich lediglich den Startzeitpunkt oder Ankunftszeitpunkt
anzugeben, womit der Reisezeitraum als unendlich gross angenommen wird. Erfolgt keine
Zeitangabe so wird der aktuelle Zeitpunkt als Startzeitpunkt gewählt.
Das Nutzerprofil beherbergt all jene Daten die zum Zeitpunkt der Reise über den Nutzer
vorliegen. Dies sind einerseits vom Nutzer selbst gemachte Angaben über Präferenzen,
sowie Daten, die aus dem Nutzungsverhalten vorheriger Transaktionen hervorgegangen
sind. Diese Daten beeinflussen die Berechnung der Ergebnisliste, indem die Rangfolge
der einzelnen Transportmittel ggf. geändert wird. Ausgeschlossene Transportmittel brauchen nicht berechnet werden. Das Einschränken der Ergebnisliste wird hier als Filtern
bezeichnet.
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Nachbedingung im Sonderfall
Reise planen
Reiseinformation erhalten
Reisender
Reisender ist am System angemeldet
1) Reisedaten eingeben
2) Konkrete Reise auswählen
Die Reiseinformation wurde angezeigt
Der Reisende gibt ungueltige Reisedaten
ein
Eine Fehlermeldung erscheint
Tabelle 4.1.: Anwendungsfall: Reise planen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Startpunkt festlegen
Der Startpunkt der Reise soll festgelegt
werden
Reisender
Reisender gibt Adresse oder POI in Textfeld ein
—
Der Reisende gibt ungültige Zeichen ein
Tabelle 4.2.: Anwendungsfall: Startpunkt festlegen
41
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Zielpunkt festlegen
Der Zielpunkt der Reise soll festgelegt
werden
Reisender
—
Fehlermeldung erscheint
Tabelle 4.3.: Anwendungsfall: Zielpunkt festlegen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Nutzerprofil berücksichtigen
1) Ausgeschlossene Transportmittel sollen
nicht in die Routenberechnung einfliessen
2) Ranking der Transportmittel soll beeinflusst werden
Reisender
1) Reisender ist am System angemeldet
2) Eine Reise wird berechnet
Nutzerprofil wurde berueücksichtigt
Das Nutzerprofil konnte nicht gelesen
werden
Ignorierung des Nutzerprofils
Tabelle 4.4.: Anwendungsfall: Nutzerprofil berücksichtigen
42
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Reisezeitraum festlegen
Der Zeitraum der Reise soll festgelegt
werden
Reisender
Reisender gibt den Zeitraum ein, indem
er gewillt ist zu reisen
—
Tabelle 4.5.: Anwendungsfall: Reisezeitraum festlegen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Ergebnis wählen
Der Reisende wählt ein konkretes Transportmittel aus, welches er vor hat zu benutzen
Reisender
2) System hat erfolgreich eine Reise geplant
3) System hat erfolgreich Alternativen
aufgelistet
Reisender sieht Informationen der Alternativen ein und wählt ein konkretes
Transportmittel aus einer Liste aus
Transportmittel wurde erfolgreich ausgewählt und vom System registriert
Der Reisende wählt kein Transportmittel
—
Tabelle 4.6.: Anwendungsfall: Ergebnis wählen
43
1 1
Ergebnis filtern
<<include>>
Filter auswählen
<<include>>
Services aktualisieren
Reisender
1
1
Jinengo
1
1
DL-Anbieter
Abbildung 4.4.: Anwendungsfall: Ergebnis filtern
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Ergebnis filtern
Die Ergebnisliste soll gefiltert werden
Reisender
2) System hat erfolgreich eine Reise geplant
—
Die Ergebnisliste wurde gefiltert und ggf.
reduziert
—
—
Tabelle 4.7.: Anwendungsfall: Ergebnis filtern
44
4.3.4. Ergebnis filtern
Im folgenden wird der Anwendungsfall Ergebnis filtern aus Sicht des Reisenden erklärt.
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Ergebnis filtern
Ein ausgewähltes Reiseergebnis entsprechend den Bedürfnissen des Reisenden anpassen
Reisender
Der Reisende hat ein Ergebnis seiner Reiseplanung gewählt
1) Der Reisende wählt einen Filter /
Schieberegler aus
2) Der Reisende filtert das Ergebnis seinen Bedürfnissen entsprechend
3) Das Ergebnis wird durch eine Serviceanpassung aktualisiert
Der Reisende hat das ausgewählte Ergebnis gefiltert
—
—
Tabelle 4.8.: Anwendungsfall: Ergebnis filtern
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Filter auswählen
Der Filter für das Reiseergebnis soll definiert werden
Reisender
Reisender hat eine Reise geplant
Reisender bedient Filter / Schieberegler
Reisender hat einen Filter gesetzt
—
—
Tabelle 4.9.: Anwendungsfall: Filter auswählen
45
<<extend>>
Ergebnis filtern
Ergebnis bereitstellen
1
1
DL-Anbieter
1
<<include>>
1
1
1
Reise planen
<<include>>
Strecke
Verkehrsangebote übermitteln
<<include>>
<<include>>
Jinengo
<<include>>
<<include>>
<<include>>
Komfort
Art
Zeit
Kosten
Abbildung 4.5.: Anwendungsfall: Reise planen aus Sicht der Dienstleister
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Services aktualisieren
Das Ergebnis soll den Filterwerten entsprechend angepasst werden
Jinengo, Dienstleister
Reisender hat einen Filter ausgewählt
1) Jinengo leitet neue Anfragewerte an
Dienstleisters weiter
2) Dienstleister verarbeitet neue Anfrage
3) Jinengo erhält und verarbeitet neues
Ergebnis von Dienstleister
4) Reisender sieht aktualisiertes Reiseergebnis
Das Reiseergebnis ist mit dem ausgewählten Filter abgestimmt
—
—
Tabelle 4.10.: Anwendungsfall: Service aktualisieren
4.3.5. Reise planen aus Sicht der Dienstleister
Im Folgenden wird der Anwendungsfall Reise planen aus Sicht der Dienstleister näher
beschrieben.
46
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Reise planen aus Sicht der Dienstleister
Informationen über die Verkehrsangebote müssen für die Reiseplanung zur
Verfügung gestellt werden
Jinengo, Dienstleister
1) Reiseparameter wurden schon festgelegt
2) Die Dienstleister sind bereits ins System integriert
Nach den Reiseparametern werden die
verschiedenen Verkehrsangebote von
Dienstleistern bezüglich Verkehrsmittel, Zeit, Kosten sowie Komfort usw.
übermittelt
Die Verkehrsangebote werden zur Ergebnisfilterung bereitgestellt
Reiseparameter fehlen
Fehlende Reiseparameter werden angefordert
Tabelle 4.11.: Anwendungsfall: Reise planen aus Sicht der Dienstleister
4.3.6. Filterdefinition aus Dienstleistersicht
Die Filterdefinition erlaubt es, auf Basis der individuellen Anforderungen verschiedener
Dienstleister Reisende zu identifizieren, die als Zielgruppe für ein Produkt oder einer
Dienstleistung in Frage kommen. Dienstleister werden in verschiedene Gruppen unterteilt, um individuelle Anforderungen erfüllen zu können.
Die vordefinierten Gruppen lauten Dienstleister, Mobilitätsdienstleister, Fahrzeuganbieter und Individualverkehrsanbieter. Dienstleister sind nicht zwingend der Mobilitätsbranche zuzuordnen. Im Kontext der Filterdefinition sind an dieser Stelle Anbieter gemeint, die ein räumlich bezogenes Angebot haben. Im Sinne der Nachhaltigkeit werden
diese Dienstleister berücksichtigt, wenn dadurch Wegstrecken eines Reisenden reduziert
werden können.
Der Begriff Indiviualitätsdienstleister bezeichnet Anbieter, die Fahrzeuge für einzelne
Reisende oder Kleinstgruppen anbieten.
47
Anbieter-Filter-Definition
Startinvestition
Kosten
Fixkosten
Dienstleister
Fahrzeuganbieter
<<include>>
Zielgruppe
definieren
Individualverkehr-Anbieter
Mobilitätsdienstleister
<<include>>
Bewegungskosten
<<include>>
Komfort
<<extends>>
POI
Mobilitätsangebot
übermitteln
<<refine>>
Parametersatz
konfigurieren
Zeit
<<include>>
DL-Gruppen
Definition
Jinengo
Dienstleistung
beschreiben
Abbildung 4.6.: Anwendungsfall: Ergebnis filtern
48
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Filterdefinition aus Dienstleistersicht
Mithilfe der Filterdefinition legt ein
Dienstleister fest, wie eine Gruppe innerhalb der Reisenden identifiziert werden
soll. Die Filter unterscheiden sich folgend
den Anforderungen des Dienstleisters.
Dienstleister sind in die Kategorien
Dienstleister,
Mobilitätsdienstleister,
Fahrzeuganbieter und Individualverkehrsanbieter unterteilt. Dienstleister
stehen nicht zwingend mit dem Thema
Mobilität im Zusammenhang.
Es wird die Zugehörigkeit zu einer Dienstleistergruppe festgelegt.
Aufgrund der Gruppenzuordnung werden
relevante Filterkriterien mit Voreinstellungen geladen. Der Dienstleister kann
folgend diese Voreinstellungen individualisieren.
Nach Übernahme der Informationen werden diese auf Validität geprüft. Sind alle Informationen innerhalb der definierten
Gültigkeitsbereiche, wird der Dienstleister über die erfolgreiche Datenübernahme
informiert.
Ein Dienstleister ist keiner vordefinierten Gruppe zuzuordnen. In diesem Fall
werden alle möglichen Filterkriterien zur
Auswahl angezeigt. Die Validierung erfolgt nur auf Basis der Datentypen und
der systemweit definierten Wertebereiche.
Es
wird
nach
der
erfolgreichen
Übernahme die Möglichkeit angeboten, eine neue Dienstleistergruppe zu
definieren.
Tabelle 4.12.: Anwendungsfall: Filterdefinition aus Dienstleistersicht
4.3.7. Nutzerprofil ändern
Dieser Anwendungsfall beschreibt, wie ein Nutzer der Jinengo-Plattform seine Nutzerpräferenzen verändern kann. Die angegebenen Präferenzen werden später bei der eigent-
49
Nutzername & Passwort ändern
<<include>>
Profileinstellungen ändern
Emissionskalkulator wählen
<<extend>>
1
Reisender
1
<<include>>
<<extend>>
Nutzerprofil ändern
Services wählen
<<extend>>
<<include>>
Routenplaner wählen
<<include>>
Präferenzen ändern
Kostenkalkulator wählen
<<include>>
<<include>>
Grad des bevorzugten Komforts wählen
Bevorzugte Fortbewegungsmittel wählen
<<extend>>
<<extend>>
<<extend>>
elektrisches Auto wählen
Auto mit verbrennungsmotor wählen
Bahn wählen
Abbildung 4.7.: Anwendungsfall: Nutzerprofil ändern
50
lichen Routenplanung und der Ergebnisauflistung explizit verwendet.
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Nutzerprofil ändern
Der Reisende soll die Möglichkeit erhalten, seine Profileinstellungen zu ändern.
Reisender
Der Reisende ist registriert und eingeloggt.
Das Ändern des Profils besteht im Wesentlichen aus drei Teilaufgaben; Das
Ändern der grundsätzlichen Profileinstellungen, das Auswählen von Services
sowie das Einstellen von bestimmten
Präferenzen.
Der Reisende hat seine Profileinstellungen
geändert.
—
—
Tabelle 4.13.: Anwendungsfall: Nutzerprofil ändern
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Services wählen
In diesem Anwendungsfall wählt der Nutzer die Services aus, die er für die Planung seiner Route, für die Kalkulation
der Nachhaltigkeit sowie für die Kalkulation der Fahrkosten benutzen möchte.
Am Anfang bekommt ein Nutzer automatisch diejenigen Services zugewiesen, die
die höchste Bewertung von der Community erhalten haben.
Reisender
Der Reisende ist auf dem Profileinstellungsformular.
Der Reisende ändert seine bevorzugten
Services und bestätigt.
Der Reisende hat seine bevorzugten Services geändert.
—
—
Tabelle 4.14.: Anwendungsfall: Services wählen
51
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Präferenzen ändern
In diesem Anwendungsfall stellt der Nutzer seine Reisepräferenzen ein. Dazu
gehört neben der Auswahl des bevorzugten Fortbewegungsmittels auch die Einstellung, wie wichtig dem Nutzer Komfort
ist. Die Einstellung des Komforts soll im
ersten Iterationsschritt sehr rudimentär
gehalten werden (z.B. nur die Frage, ob
der Nutzer während der Reise gerne lesen
möchte).
Reisender
Der Reisende ist auf dem Profileinstellungsformular.
Der Reisende ändert seine Präferenzen
und bestätigt.
Der Reisende hat seine Präferenzen
geändert.
—
—
Tabelle 4.15.: Anwendungsfall: Präferenzen ändern
4.3.8. Reise bewerten - Reisender
Der Anwendungsfall Reise bewerten setzt sich immer aus mind. einem der drei Anwendungsfälle Pünktlichkeit bewerten, Füllungsgrad bewerten oder Mitfahrer bewerten
zusammen. Die genaue Zusammensetzung ist abhängig von den zu bewertenden Reiseabschnitten. Beinhaltet die Reise z.B. ausschließlich das Fahrrad als Reisemittel, ist es
nicht möglich Mitfahrer, bzw. den (Über-) Füllungsgrad des Reisemittels zu bewerten.
Bei Reisen bestehend aus verschiedenen Reiseabschnitten kann es hingegen vorkommen,
dass bestimmte Aspekte, z.B. Pünktlichkeit, auch mehrfach bewertet werden sollen.
Diese drei Spezialisierungen von Reise bewerten greifen wiederum auf unterschiedliche Bewertungsarten zurück. Die Bewertung von Pünktlichkeit ist immer eine kardinale Bewertung, in der die mögliche Verspätung als Zeit eingetragen wird. Der (Über-)
Füllungsgrad eines öffentlichen Verkehrsmittels wird mit Hilfe einer ordinalen Skala (z.B.
Sehr voll bis leer ) erfasst. Wenn, z.B. bei einer Fahrgemeinschaft, die Mitfahrer bewertet
werden, ist auf einer ordinalen Skala der Mitfahrer zu bewerten (z.B. positiv – neutral –
negativ) und dazu ein kurzer Freitext (ähnlich dem eBay-Bewertungssystem) zu erfassen.
Um die Bewertung möglichst einfach und unauffällig zu gestalten sind folgende Maß-
52
1
1
1
1
Reise auswählen
Reise bewerten
<<extend>>
Reisender
{Reise beinhaltet
Fahrgemeinschaft}
<<extend>>
{Reise beinhaltet
<<extend>> öffentliche
Verkehrsmittel}
Mitfahrer bewerten
Pünktlichkeit bewerten
Füllungsgrad bewerten
<<include>>
<<include>>
<<include>>
<<include>>
Freitextbewertung
Ordinale Bewertung
Kardinale Bewertung
Abbildung 4.8.: Anwendungsfall: Reise bewerten
nahmen denkbar: Die Verspätung soll, dort wo es möglich und sinnvoll ist, mit Hilfe
von Smart Devices, also i.d.R. dem Mobiltelefon automatisch ermittelt werden. Bei Busfahrten liese sich eine solche Verspätung zuverlässig mit Hilfe des GPS Sensors und der
Uhrzeit ermitteln, ebenso bei der Bahn und dem Flugzeug (wobei bei letzteren solche
Daten evtl. sogar über den Diensteanbieter selbst bereitgestellt werden). Eine weitere
Maßnahme zur einfachen Bewertungsgestaltung ist die Fokusierung auf ordinale Skalen,
die von einem Benutzer ohne großen Aufwand, z.B. per Radio-Button, festgelegt werden
können.
53
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Reise bewerten
Eine Reise, die sich aus mehreren Abschnitten zusammensetzen kann, bewerten.
Reisender
Reisender ist am System angemeldet und
die zu bewertende Reise wurde durchgeführt und noch nicht bewertet.
Der Reisende erhält eine Liste der Abschnitte seiner Reise und kann jeden Abschnitt separat bewerten. Die Art der Bewertung ist dabei abhängig vom jeweiligen Reiseabschnitt. Bei einer Reise mit
einem öffentlichen Verkehrsmittel bewertet der Reisende die Pünktlichkeit und
den Füllungsgrad des Verkehrsmittels, bei
einer Reise mit einer Fahrgemeinschaft
Pünktlichkeit und die Mitfahrer und bei
einer Reise mit eigenem Verkehrsmittel,
z.B. Auto nur die Pünktlichkeit.
Die Reise wurde bewertet.
Der Reisende bricht die Bewertung der
Reise ab.
Die Reise wurde nicht bewertet.
Tabelle 4.16.: Anwendungsfall: Reise bewerten
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Reise auswählen
Ziel des Anwendungsfalls Reise auswählen
ist es, eine zu bewertende Reise aus der
Liste, der bereits getätigten und nicht bewerteten Reisen auszuwählen.
Reisender
Reisender wählt eine Reise aus einer Liste
von ihm getätigter Reisen aus.
—
—
—
Tabelle 4.17.: Anwendungsfall: Reise auswählen
54
Integrität prüfen
<<include>>
<<include>>
Name für Agentenverhalten angeben
SHA1 angeben
Archiv hochladen
<<extend>>
<<include>>
1
1
<<include>>
Agentenverhalten hinzufügen
Verhaltensentwickler
<<include>>
<<include>>
Agentenverhalten konfigurieren
<<extend>>
Kategorie für Agentenverhalten angeben
Agentenverhalten freigeben
Entwickler
Abbildung 4.9.: Anwendungsfall: Agentenverhalten hinzufügen
4.3.9. Agentenverhalten hinzufügen
Im folgenden wird der Anwendungsfall Agentenverhalten hinzufügen näher erklärt.
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Agentenverhalten hinzufügen
Registrierung eines neuen Agentenverhaltensmuster
Agentenverhaltensmuster und SHA1 sind
lokal vorhanden
Verhalten wird hochgeladen, verifiziert
und konfiguriert
Agentenverhaltensmuster ist hochgeladen
und registriert
Archivintegrität ist verletzt
Vorgang wird abgebrochen oder wiederholt
Tabelle 4.18.: Anwendungsfall: Agentverhalten hinzufügen
55
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Archiv hochladen
Das Archiv soll hochgeladen werden
Das Archiv ist lokal vorhanden
Das Archiv wird hochgeladen
Das Archiv ist hochgeladen
Die Übertragung bricht ab.
Der Vorgang wird abgebrochen
Tabelle 4.19.: Anwendungsfall: Archiv hochladen
Name
SHA1 angeben
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
SHA1 Überprüfung soll angeben werden
Die Summe ist lokal vorhanden
Die Summe wird eingegeben
Die Summe ist eingegeben
—
—
Tabelle 4.20.: Anwendungsfall: SHA1 angeben
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Integrität prüfen
Die Archivintegrität soll sicher gestellt
werden
Jinengo
Archiv und SHA1 wurden bereitgestellt
Die Integrität wird errechnet
Die Integrität ist bestätigt
Die Integrität ist nicht gegeben
Das Archiv verfällt
Tabelle 4.21.: Anwendungsfall: Integrität prüfen
56
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Agentenverhalten konfigurieren
Das Verhalten soll konfiguriert werden
Das Archiv wurde hochgeladen und verifiziert
Das Verhalten wird konfiguriert
Das Verhaltensmuster ist konfiguriert
—
—
Tabelle 4.22.: Anwendungsfall: Agentenverhalten konfigurieren
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Name für Agentenverhalten angeben
Das Verhalten soll eindeutig benannt werden
Das Verhalten wird benannt
Das Verhalten hat ein Namen
—
—
Tabelle 4.23.: Anwendungsfall: Name für Agentenverhalten angeben
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Kategorie für Agentenverhalten angeben
Das hochgeladene Verhalten soll kategorisiert werden
Das Verhalten wird kategorisiert
Das Verhalten ist kategorisiert
—
—
Tabelle 4.24.: Anwendungsfall: Kategorie für Agentenverhalten angeben
57
Bestehende Variation laden
<<extend>>
Skelett öffnen
<<include>>
1
1
Agent zusammenfügen
<<extend>>
Verhalten hinzufügen
<<include>>
Variation benennen
Agenten Assembler
<<include>>
Variation freigeben
Entwickler
Abbildung 4.10.: Anwendungsfall: Agenten Zusammenfügen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Agentenverhalten freigeben
Das Verhalten soll überprüft und freigegeben werden
Das Verhalten ist vorhanden und konfiguriert
Das Verhalten wird freigeben
Das Verhalten ist nun im System
verfügbar
Es wurden unzureichend Informationen
durch den Nutzer bereitgestellt
Der Vorgang wird abgebrochen oder (teilweise) wiederholt
Tabelle 4.25.: Anwendungsfall: Agentenverhalten freigeben
4.3.10. Agent zusammenfügen
Im folgenden wird der Anwendungsfall Agent zusammenfügen näher erklärt.
58
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Agent zusammenfügen
Eine neue Agentenvariation kompositionieren
Agenten Assembler
Agentenverhalten sind dem System bekannt
Eine Kombination aus bestehenden Verhalten wird einem Agentenskelett hinzugefügt
Eine neue Agentenvariation wurde dem
System hinzugefügt
—
—
Tabelle 4.26.: Anwendungsfall: Agent zusammenfügen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Skelett öffnen
Eine leeres Skelett für einen Agenten wird
geladen
Agenten Assembler
—
Eine neues leeres Skelett wird geladen
Ein neues leeres Skelett wurde geladen
—
—
Tabelle 4.27.: Anwendungsfall: Skelett öffnen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Bestehende Variation laden
Eine zuvor gespeicherte Agentenvariation
wird in das Skelett geladen
Agenten Assembler
Zuvor wurden bereits Variationen hinterlegt
Eine bestehende Variation wird geöffnet
Eine bestehende Variation wurde geöffnet
Eine bestehende Variation konnte nicht
geladen werden
Der Ladevorgang wird abgebrochen
Tabelle 4.28.: Anwendungsfall: Bestehende Variation laden
59
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Verhalten hinzufügen
Ein passendes Agentenverhalten soll dem
Skelett hinzugefügt werden
Agenten Assembler
Eine Auswahl von Agentenverhalten sind
dem System bekannt
Das gewünschte Verhalten wird an das
Skelett angeheftet
Das gewünschte Verhalten wurde an das
Skelett angeheftet
Das Verhalten kann nicht angeheftet werden, da das Verhalten nicht der passende
Kategorie entspricht
Vorgang wird abgebrochen oder es wird
ein alternatives Verhalten gewählt
Tabelle 4.29.: Anwendungsfall: Verhalten hinzufügen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Variation benennen
Die Variation soll benannt werden, sodass
sie identifiziert werden kann
Agenten Assembler
Die Variation existiert
Die Variation wird benannt
Die Variation ist benannt
Der gewählte Name ist bereits vergeben
Der Name wird geändert
Tabelle 4.30.: Anwendungsfall: Variationen benennen
60
<<include>>
1
1
Neue Agenten anzeigen
Agent-Details prüfen
<<include>>
Agent freischalten / ablehnen
Admin
Abbildung 4.11.: Anwendungsfall: Agent bestätigen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Variation freigeben
Die Agentenausprägung wird aktiviert
und freigegeben
Agenten Assembler
Die Variation ist fertig
Die Variation wird aktiviert
Die Variation ist aktiviert und im System
verfügbar
Die Variation entspricht nicht allen Anforderungen
Der Vorgang wird abgebrochen
Tabelle 4.31.: Anwendungsfall: Variation freigeben
4.3.11. Agent bestätigen
In diesem Abschnitt wird der Anwendungsfall Agent bestätigen näher erklärt.
61
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Neue Agenten anzeigen
Auflistung von noch nicht freigegebenen
Agenten einsehen.
Administrator
Der Benutzer ist als Administrator am
System angemeldet.
Der Administrator nimmt Einsicht in die
Liste der unbestätigten Agenten.
Der Administrator hat die noch nicht freigegebenen Agenten gesehen und kann sich
die Details eines Agenten anzeigen lassen.
—
—
Tabelle 4.32.: Anwendungsfall: Neue Agenten anzeigen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Agenten-Details prüfen
Die Details eines Agenten können
überprüft werden.
Administrator
Der Administrator hat sich einen Agenten
für die Detail-Ansicht ausgewählt.
Der Administrator überprüft die Details
(z.B. Autor, Quellcode, Unit-Tests) des
Agenten anhand verschiedener Kriterien.
Der Administrator kann den Agenten
bezüglich seiner Tauglichkeit für das Jinengo System bewerten.
Der Administrator konnte den Agenten,
z.b. aufgrund mangelnden Wissens, nicht
eindeutig bewerten.
Der Administrator bewertet den Agenten
nicht und lässt diesen für andere Administratoren für die Bewertung offen.
Tabelle 4.33.: Anwendungsfall: Agenten-Details prüfen
62
Benutzerdaten eingeben
<<include>>
1
1
Benutzer registrieren
<<include>>
Benutzerdaten bearbeiten
<<include>>
Benutzer
Benutzerdaten speichern
Abbildung 4.12.: Anwendungsfall: Registrierung
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Agenten freischalten / ablehnen
Ein Agent kann im Jinengo System genutzt werden oder nicht.
Administrator
Die Details des Agenten wurden vom Administrator überprüft.
Der Administrator klickt auf den Button
freischalten oder ablehnen.
Der Agent wird nicht mehr in der Auflistung von neuen Agenten geführt.
Der Agent wurde schon freigeschaltet /
abgelehnt.
Der Agent kann im nachhinein abgelehnt
/ freigeschaltet werden.
Tabelle 4.34.: Anwendungsfall: Agenten freischalten / ablehnen
4.3.12. Registrierung
In diesem Abschnitt wird der Anwendungsfall Registrierung näher erklärt.
63
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Benutzer registrieren
Benutzer im System registrieren
Benutzer
—
1) Benutzerdaten eingeben
2) Eingabe absenden
Registrierung wurde bestätigt
Nutzer gibt ungültige Daten ein
Tabelle 4.35.: Anwendungsfall: Benutzer registrieren
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Benutzerdaten eingeben
Erfassen sämtlicher Registrierungsdaten
Benutzer
Benutzer hat das Registrierungsformular
erfolgreich geöffnet
1) Benutzerdaten eingeben
2) Eingabe absenden
Registrierung wurde bestätigt
Tabelle 4.36.: Anwendungsfall: Benutzerdaten eingeben
Name
Benutzerdaten bearbeiten
Ziel
Ändern oder Erweitern der Benutzerdaten.
Benutzer
Der Benutzer muss registriert sein.
1) Anmelden
2) Bearbeiten
Benutzerdaten
wurden
erfolgreich
geändert
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Tabelle 4.37.: Anwendungsfall: Benutzerdaten bearbeiten
64
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Benutzerdaten speichern
Speichern der Benutzerdaten
Benutzer
Eingabe wurde getätigt
Benutzer initiiert die Speicherung
Speichern wurde bestätigt
Speichern schlägt fehl
Tabelle 4.38.: Anwendungsfall: Benutzerdaten speichern
65
5. Pflichtenheft Teil B
Folgendes Dokument beschreibt die Anforderungen an die zweite Iterationsstufe des
Projekts Jinengo. Auf Basis des ersten Prototypen wurde das vorliegende System auf
Zielerreichung hin untersucht und offene Aspekte identifiziert. Diese Aspekte wurden
klassifiziert und einzelnen Schwerpunkten zugeordnet. Dabei folgt die Zuordnung dem
modularen Charakter des Systems.
Dieses Dokument stellt die Grundlage für den Entwurf des Meilensteins B dar. Grundsätzliche
Anforderungen, die in der Analyse des Meilensteins A identifiziert wurden, werden an
dieser Stelle nicht gesondert aufgeführt. Ausnahme stellen jene Aspekte dar, die im ersten
Prototypen nicht vollständig umgesetzt wurden.
Um die zeitgerechte Umsetzung zu gewährleisten, das hat sich Projektteam in Untergruppen organisiert, die für die Realisierung eines Teilbereichs verantwortlich sind. Diese Organisationsstruktur wird auch genutzt, um die Vollständigkeit der Anforderungen
durch eine gegenseitige Kontrolle zu gewährleisten.
Die Fertigstellung des Meilenstein B ist für den 31.06.2011 geplant. Im Laufe der Arbeiten
wurde dieser angepasst und auf den 31.07.2011 verschoben.
5.1. Funktionale Anforderungen
Dieser Abschnitt fasst die Ergebnisse der Interviews zusammen.
Die funktionalen Anforderungen beschreiben, welche Kriterien aus Anwendungs- sowie
aus architektonischer Sicht an die Anwendung gestellt werden.
5.1.1. CRM
Gemäß den Anforderungen von Meilenstein A existiert eine grundlegende Schnittstelle
zwischen dem CRM-System und Jinengo, über die die Matchmaker-Komponente bereits
Daten vom CRM-System anfordern kann. In Meilenstein B soll diese Schnittstelle weiter
an das Jinengo-System angepasst und integriert werden. Hierbei wird weiterhin Microsoft
67
Dynamics 2011 Online als CRM-System verwendet. Es sind drei verschiedene Gruppen
von CRM-Funktionen zu realisieren:
Front-End-Funktionen. Die im CRM-System gehaltenen Daten sollen zur optimierten Routenberechnung und der Verwaltung eines Kundenprofils genutzt werden.
Markting-Kampagne. Es sollen Marketingaktivitäten im Rahmen des CRM-Systems bspw. mit Hilfe der Marketingliste und Marketingkampagnen erstellt und
durchgeführt werden können, um Kunden zu nachhaltigem Verhalten zu bewegen.
Es soll hierbei auch nicht der finanzielle Aspekt außer Acht gelassen werden. Daher
sollten solche Marketingaktivitäten auch Kundengruppen zu Tage fördern können,
die für Partner interessant sein können. Dabei gilt es aber auch, datenschutzrechtliche Einschränkungen zu beachten und einzuhalten.
BI-Funktionen. Es sollen relevante Daten, die im CRM-System gespeichert sind, in
ein Data-Warehouse exportiert werden, um bspw. Daten für eine Berichtserstellung
bzw. Datenanalyse bereitzustellen. Diese Funktionen können auch vorgelagert zu
einer Marketingkampagne ausgeführt werden.
Um diese Funktionen zu realisieren, ist es notwendig, das Datenmodell des CRM-Systems
zu erweitern. Insbesondere wird die contact-Entität erweitert, um das User-Modell abzubilden und benutzerbezogene Daten zu speichern. Es werden aber auch neue Entitätstypen erstellt, beispielsweise um komplexe Routenanfragen und Emissionsdaten zu
speichern.
Weiterhin sollen am Ende von Meilenstein B angepasste Formulare im CRM-System zur
Verfügung stehen, die einen Überblick über die gespeicherten, relevanten Daten geben.
Dazu ist es notwendig, die relevanten Daten zu identifizieren und hinterher die Formulare anzupassen, so dass nur solche Daten eines Entitättyps angezeigt werden. Die
anderen Daten werden hierbei weiterhin im Hintergrund gespeichert, jedoch vor dem
CRM-Anwender versteckt.
Eine weitere Anforderung ist die Anbindung an ein soziales Netzwerk, wodurch der
Endanwender in die Lage versetzt wird, sein Profil auf einfache Art und Weise mit
Daten zu versorgen, die zur Anwendung des unten beschriebenen Business Cases von
Interesse sein können.
Im Folgenden wird ein konkreter Business Case beschrieben, der eine konkrete Vorgehensweise zur Durchführung einer Marketingkampagne beschreibt, deren Ziel es ist,
einen Mehrwert für einen Anbieter von Fahrgemeinschaften zu bieten und gleichzeitig die
Jinengo-Endanwender zu nachhaltigerem Verhalten zu bewegen. Die hierfür notwendigen
Daten und Methoden sollen im Rahmen von Meilenstein B erhoben und implementiert
werden.
68
Business Case
Ziel ist es, die Nutzung von Car-Pooling-Angeboten zu optimieren, indem Nutzer mit
ähnlichen Interessen, die regelmäßig ähnliche Routen bereisen, identifiziert werden, damit
diesen Kunden gezielte Fahrgemeinschaftangebote gemacht werden können. Dabei ist
vorstellbar, dass diese Kunden(gruppen)datensätze an einen Fahrgemeinschaftsmittler
weitergegeben werden, damit dieser die Marketingaktion eigenverantwortlich ausführen
kann, es ist aber auch denkbar, dass Jinengo selber diese Aktion ausführt, um gezielt
einen bestimmten Car-Pooling Anbieter zu unterstützen.
Kunde und Mehrwert Der primäre Kunde ist ein Car-Pooling Anbieter. Dieser bezahlt
für die Leistung von Jinengo, Kunden zu identifizieren, die potentiell geeignete Fahrgemeinschaften bilden können. Diese Kunden, die bereits in mögliche, passende Fahrgemeinschaften gruppiert sind, können vom Car-Pooling Anbieter gezielt angesprochen
werden. Dabei kann neben der passenden Route auch mit den Interessen / Merkmalen
der potentiellen Mitfahrer argumentiert werden. Beispielsweise können Pendler, die die
selbe Route reisen möchten, anhand von z.B. Musikgeschmack (wegen Radio) weiter
unterteilt werden.
Nachhaltigkeitsaspekt Übergeordnetes Ziel ist es, neben dem Geschäft mit dem Fahrgemeinschaftsvermittler, mehr Menschen dazu zu bewegen, eine Fahrgemeinschaft zu
nutzen. Dabei ist es möglich, sich nur auf Kunden zu fokussieren, die z.B. bislang alleine mit dem Auto fahren, um so nicht beispielsweise die Nutzung anderer nachhaltiger
Verkehrsmittel zu gefährden. Durch die Attraktivitätssteigerung der Fahrgemeinschaft
und die damit einhergehende erhöhte Nutzung wird ein positiver Effekt für die Umwelt
erzielt.
Vorgehensweise Für die Realisierung des Business Cases soll ein geeignetes Tooling
evaluiert werden (bspw. Microsoft SQL Server) dessen Business Intelligence Methoden
geeignet sind, um die notwendigen Daten (Gruppen von Kunden mit ähnlichen Routen
und Interessen) zu erheben.
5.1.2. Frontend
Allgemeines zu mobilen Betriebssystemen
Der Markt für Smartphones und ihren Betriebssystemen ist noch relativ jung und dynamisch und somit einem stetigen Wandel unterworfen. Dieser Abschnitt der Anforderungsdefinitionen widmet sich jenen Anforderungen, die sich aus der Heterogenität des
69
Smartphone-Markts ergeben. Das Ziel dabei ist das User-Frontend auf einer Vielzahl
unterschiedlicher Endgeräte optimal darzustellen. Eine optimale Darstellung umfasst
Fragen des Designs als auch der Bedienung. Im Gegensatz zum PC-Markt zeichnet sich
der mobile Sektor dadurch aus, dass kein Anbieter von mobilen Endgeräten eine marktbeherrschende Stellung einnimmt. Als Folge sind viele verschiedene Zielplattformen zu
berücksichtigen. Das Leistungsspektrum der Endgeräte reicht von einfachen Geräten mit
rudimentären Internetfähigkeiten bis hin zu Geräten, die eine Leistung vergleichbar mit
einfachen Notebooks haben. Aus der Bestimmung der Zielgruppe leitet sich ab, dass eine
Eingrenzung auf eine einzelne Zielplattform nicht möglich ist. Dies bedeutet, dass die
Anwenderschnittstelle plattformunabhängig arbeiten muss. Die folgende Grafik zeigt die
Verteilung mobiler Betriebssysteme in der Gerätekategorie Smartphones im U.S.-Markt
für das Jahr 2010. Es wird davon ausgegangen das diese Verteilung auch auf den deutschen und allgemein den europäischen Markt zutrifft. Zwei wichtige Erkenntnisse können
aus der Grafik entnommen werden. Erstens decken die drei Betriebssysteme Android,
Blackberry OS sowie Apple iOS bereits 80,5 % des gesamten Smartphone-Marktes ab.
Zweitens sind die Anteile sehr gleichmäßig verteilt, sodass kein Betriebssystem eine vorherrschende Stellung besitzt. Hieraus wird eine Anforderung an das Jinengo-Frontend
abgeleitet, die besagt, dass die Darstellung auf die drei oben erwähnten Betriebssystemen
optimiert sein muss. Daneben soll das derzeit aufkommende mobile Betriebssystem von
Microsoft mit dem Namen Phone 7 unterstützt werden. Der Marktanteil der Endgeräte,
die nicht in die Kategorie Smartphone fallen, beträgt weiterhin über 70%. Dies bedeutet,
dass ein großer Teil der Zielgruppe über Endgeräte verfügt, die keine Installation von
Software zulassen oder auf die Java-ME-Plattform eingeschränkt sind. Diese Endgeräte
lassen sich in zwei weitere Kategorien unterteilen: Geräte mit einer minimalen Auflösung
von 240 x 320 Punkten und Geräte mit geringerer Auflösung. Für die letztgenannten
Geräte muss eine Anwendung entwickelt werden, die unter Berücksichtigung der Einschränkungen eine Verwendung von Jinengo ermöglicht. Dies soll als Java-ME-Lösung
realisiert werden. Die Gruppe der Smartphones und jene ohne Erweiterungsmöglichkeiten
gleichen sich i.d.R. in den Darstellungsmöglichkeiten. Weiterhin bieten alle Plattformen
die Möglichkeit, Inhalte per Web-Browser darzustellen. Aus diesem Grund wird die Umsetzung der Anwendersoftware als Web-Applikation gefordert, da so eine möglichst große
potenzielle Nutzergruppe angesprochen werden kann.
Die Darstellung des Jinengo-User-Frontends erfolgt stets über einen Browser. Die oben
erwähnten mobilen Betriebsysteme bringen in der Regel einen so genannten Standardbrowser mit. Daneben steht es den Benutzern jedoch theoretisch frei andere Browser zu
verwenden. Eine Optimierung von Jinengo für jegliche Browser ist hingegen zu aufwendig. Daher erfolgt die Optimierung stets an den Standardbrowser. Details der einzelnen
Betriebssystem und Browser werden sodann im Folgenden abgehandelt.
Neben einer Darstellung die auf allen Endgeräten identisch ist besteht auch die Möglichkeit
das Frontend in der Hinsicht anzupassen, dass es den jeweiligen Design- und HandlingRichtlinien der einzelnen Betriebssysteme entspricht. Für den Meilenstein B soll für ein
mobiles Betriebssystem, vorzugsweise Apple iOS, eine solche Anpassung erfolgen. Das
70
Abbildung 5.1.: (Quelle: http://blog.nielsen.com/nielsenwire/online_mobile/
apple-leads-smartphone-race-while-android-attracts-most-recent-customers/
)
Jinengo-Frontend soll damit den Charakter einer App“ bekommen. Technisch gesehen
”
ist das Frontend jedoch immer noch eine Webseite.
Weiterhin sind folgende spezielle Anforderungen einzuhalten:
Ein Frontend was keinen Prototyp Charakter mehr aufweist
Online-Verfügbarkeit für alle Interessenten
Zugriff auf alle essentiellen Einstellungsmöglichkeiten (eigenes Auto usw.)
Validierung aller Eingaben auf Ebene regulärer Ausdrücke und Wertebereiche
Fehlerabhängige Rückmeldungen, welche für den Menschen verständlich sind.
Möglichkeit zur Laufzeit verschiedene User-Controls tauschen zu können (um z.B.
die Ergebnisdarstellung zu beeinflussen (z.B. Liste, Bubbles, ...))
Möglichkeit für den Endanwender Designs zu wechseln
71
Bewertungsmöglichkeit für Pages und Designs
Bewertungsmöglichkeit des Contents
Einbindung einer AGB in das Web-Frontend, um mit anonymisierten Kundendaten
Geschäfte machen zu können
In Tabelle 5.1.2 werden die Minimalen Browseranforderungen aufgelistet, um den kleinsten gemeinsamen Nenner für die verschiedenen Technologien zu finden:
Bei Mobilen Endgeräten ist zu beachten, dass Browser zwei verschiedene Cachetypen
besitzen.
Der Komponenten-Cache (auch Objekt-Cache genannt) speichert alle individuellen Files
wie HTML, CSS, JavaScript und Bilder. Wenn der Browser einer dieser Komponenten
benötigt, schaut er zuerst im Komponenten-Cache bevor er einen Netzwerk-request startet.
Der Page-Cache (auch back/forward Cache genannt) speichert die komplette Seite mit
allen Komponenten sowie deren aktuellen Zustand. Wenn man den Zurück oder Vorwärts
Button benutzt, versucht der Browser die Seite aus dem Cache zu laden.
Java2ME-Anwendung
In diesem Meilsenstein besteht die Anforderung, ein Java2ME (Java 2 Microedition)Frontend zu entwickeln. Die Verwendung von Java2ME ermöglicht es, Java-Programme
für Mobiltelefone zu entwickeln. Da ein Großteil der akutell auf dem Markt befindlichen
Handys Java2ME unterstützen, können sehr viele Endnutzer erreichet werden.
Da das Datenmodell des derzeit bereits bestehenden SOAP-Webservices zu komplex
für die Java Microedition ist, besteht als besondere Anforderung, dass eine RESTWebservice Schnittstelle zur Verfügung gestellt wird. Die Daten eines REST-Webservices
können leicht von einer J2ME-Anwendung interpretiert und verwendet werden.
Weiterhin besteht auf Grund des Sicherheitskonzeptes von J2ME die Anforderung, dass
der bereits erwähnte REST-Webservice auf dem Port 80 oder 81 zur Verfügung gestellt
wird. Andernfalls können die Daten des Services nicht von dem J2ME-Frontend empfangen werden.
Als letzte Anforderung ist zu nennen, dass die J2ME-Anwendung auf allen Handys mit
Java-Unterstützung ausführbar sein soll. Das Bedeutet, dass die Anwendung im Design
nur sehr rudimentär gehalten werden kann, da andernfalls eine universelle Einsetzbarkeit
der Anwendung nicht garantiert ist.
72
Mobile Safari
IE Mobile
Adroid
Browser
(Chrome)
Blackberry
Browser
Symbian
Browser /
Series 40
Symbian
Browser /
S60 OSS
Blazer
Apple
Opera Mobile
Polaris
Browser
Skyfire Mobile Browser
x
Opera
Software
Infraware
Minimum
Skyfire
Firefox Mobile
Mozilla
Palm
Nokia
Nokia
RIM
Microsoft
Google
Name
Creator
x
4.0 Android/2.1 iOS
7
4.0
für
Android/Maemo
11
4
7.3
6th Edition
unbekannt
iOS
4.0
(iPhone 4)
9
unbek.
Version
n
j
n
(Opera
Presto)
j (Ver. 7.X)
n (Gecko)
n
(NetFront)
j
j
j (ver 6.0+)
n
j
j
Webkit
4.01
5
5
5
5
4.01
4.01
4.01
5
5
5
5
1
unbek.
3
3
1.0
(teilw.
2.0)
3
<3
CSS2.1
3
<3
3
3
HTML CSS
1.5
j
j
j
j
1.5
unbek.
1.5
j
unbek.
j
j
n
nur android
Flash
Lite
j
n
n
Flash
Lite
3.0
j
n
n
teilwe.
n
JavaScript
Flash
j
j
j
j
j
j
j
j
j
j
j
100 KB
unbek.
unbek.
unbek.
unbek.
1MB
unbek.
unbek.
unbek.
unbek.
2MB
Ajax Component
Cache
j
102,399KB
Tabelle 5.1.: Fähigkeiten unterschiedlicher Webbrowser für Mobilgeräte
73
74
Android 2.1 (Nexus
One)
Mobile Safari, iOS
3.1.3 (1st-gen iPhone)
Mobile Safari, iOS
3.2 (iPad)
Mobile Safari, iOS
4.0 (iPhone 3GS)
Mobile Safari, iOS
4.0 (iPhone 4)
webOOS 1.4.1 (Palm
Pre Plus)
Browser / OS / Device
25.6KB
(26,214b)
51.199KB
(52,428b)
102.399KB
(104,857b)
1MB
( 1,048,576)
Single
Component
Limit
2MB
( 2,048,000b)
0b
281.6KB
( 288,354b)
1.05MB
( 1,100,988b)
1.9MB
( 1,992,283b)
n/a
Total
Component
Limit
2MB
( 2,048,000b)
0b
Yes
Yes
Yes
No
unlimited
1MB
( 1,048,576)
No
Yes
Yes
No
Yes
No
unlimited
Yes
Supports
ETag
25.6KB
(26,214b)
unlimited
Yes
Supports
Last
Modified
unlimited
Page Cache
Size
Limit
Yes
No
No
No
No
Yes
Survives
Power
Cycle
Tabelle 5.2.: Caching auf mobilen Endgeräten
Browser / OS / Device
Android 2.1 (Nexus
One)
Mobile Safari, iOS
3.1.3 (1st-gen iPhone)
Mobile Safari, iOS
3.2 (iPad)
Mobile Safari, iOS
4.0 (iPhone 3GS)
Mobile Safari, iOS
4.0 (iPhone 4)
webOOS 1.4.1 (Palm
Pre Plus)
No
No
Yes
4MB+
4MB+
0.99MB ( 1,023KB)
No
Survives Power Cycles
Yes
No
Component
4MB+
4MB+
Single
Limit
2MB
Tabelle 5.3.: Caching auf mobilen Endgeräten
75
5.1.3. Anforderungen an die Verwendung von Bedienelementen
Da die Darstellung von ein und derselben Seite unterschiedlich sein kann, sowohl was die
Anordnung als auch die Verwendung von Bedienelementen angeht, werden im Folgenden
die minimalen Anforderungen von verschiedenen Seiten geschildert. Ein Beispiel hierfür
wäre die Anzeige von verschiedenen Reisezielen über ein Grid, eine Textbox oder über
Grafiken.
Anforderungen für jede Seite: Jede Seite benötigt eine Art von Hyperlink um sowohl
zur vorherigen Seite als auch zum Hauptmenü zu gelangen.
Login-Seite: Die Login-Seite erfordert mindestens Elemente zur Eingabe einer E-Mail,
eines Passworts sowie einer Möglichkeit, die eingegebenen Daten abzuschicken. Optional
wäre in diesem Fall z.B. ein Button um die eingegebenen Daten zu löschen oder eine
Möglichkeit, um zur Passwort vergessen“ Seite zu gelangen.
”
Registrieren-Seite: Die Seite zum Registrieren eines Benutzers erfordert mindestens
ein Element für die Eingabe der E-Mail, sowie zwei Eingabemöglichkeiten für ein Passwort und ein Bedienelement um die Registrierung abzuschließen.
Reise-Planen-Seite: Die Seite zum Planen einer Reise erfordert mindestens Eingabemöglichkeiten für Start- und Endpunkt, Start und Endzeitpunkt und eine Möglichkeit,
die Anfrage abzusenden.
Reise-Ergebnisse-Seite: Zur Darstellung der Reiseergebnisse wird mindestens ein Bedienelement benötigt, welches mindestens 10 Routen mit jeweils 10 Subrouten anzeigen
kann. Die Sortierung der Ergebnisse liefert bereits der Webservice und muss nicht weiter
beachtet werden.
Passwort-ändern-Seite: Es werden mindestens zwei Eingabemöglichkeiten zur Eingabe und Wiederholung des neuen Passworts sowie die Möglichkeit zum Ausführen der
Transaktion benötigt.
76
5.1.4. Backend
Administrationsoberfläche
Die Administrationsoberfläche stellt im Wesentlichen Funktionen zur Verwaltung von
Agenten bereit.
Folgende Benutzergruppen haben Zugriff auf die Administrationsoberfläche: Administrator, Verhaltensentwickler, Agentenkonstrukteure.
Agentenkonstrukteuren stehen folgende Funktionen zur Verfügung:
– Hochladen von Agenten über ein Formular, welches ein Feld zum Dateiupload
enthält und ein Textfeld um den Namen des Agenten einzugeben.
– Auflistung aller Agenten innerhalb des Systems.
– Starten, Stoppen, Löschen und Ersetzen/Updaten der eigenen Agenten.
* Agenten, die Teil eines Verhaltensmusters sind können nicht gelöscht,
gestoppt oder ersetzt werden. Das Ersetzen eines Agenten erfolgt in dem
Fall durch Bereitstellung einer weiteren/neuen Version von dem Agenten.
– Informationen über eigene Agenten einsehen: Hochgeladen am, Läuft seit,
Aufrufe/Anfragen seit erstem Start.
– Status-Information: Freigeben, In Prüfung, Abgelehnt (mit Angabe eines Grundes).
– Hochladen von MessagingProvidern über ein Formular, welches ein Feld zum
Dateiupload enthält und ein Textfeld, um die Beschreibung des MessagingProviders einzugeben.
– Anzeigen, Bearbeiten und Löschen von MessagingProvidern.
Verhaltensentwicklern stehen alle Funktionen der Agentenkonstrukteure bereit und
folgende Funktionen:
– Auflistung aller Verhaltensmuster.
– Anlegen, Freigeben, Sperren, Löschen, Ersetzen/Updaten von eigenen Verhaltensmustern.
– Verhaltensmuster basieren auf der Zusammenstellung von Agenten, die von
Agentenkonstrukteuren bereitgestellt werden.
77
– Der Verhaltensentwickler erhält eine Informations-Meldung, wenn eine neue
Version eines Agenten aus seinem Verhaltensmusters erschienen ist.
– Informationen über eigene Agenten einsehen: Erstellt am, Freigegeben seit,
Aufrufe/Anfragen seit erster Freigabe.
Administratoren stehen folgende Funktionen Verfügung
– Importieren von Daten aus dem CRM System in die Staging Area und Erstellen des Data Warehouses
– Definieren, Bearbeiten und Entfernen von KPIs
– Exportieren von KPIs aus dem Data Warehouse ins CRM System
– Ausführen von Sparql-Queries
RESTful-Webservice
Das Jinengo-System soll neben der Unterstützung der Kommunikation mobiler J2ME
Endgeräte als Schnittstelle für Webentwickler, zum Beispiel Android-Entwickler, dienen. Hierzu soll die Webservice-Technologie RESTful zum Einsatz kommen. RESTful
Webservices sind dadurch gekennzeichnet, dass jede zur Verfügung gestellte Ressource
über den Uniform Resource Identifier (URI) erreichbar ist, wodurch angebotene Webservices standardisiert von einer Vielzahl an Clients genutzt werden kann. Weiterhin ist
REST flexibel und kann über eine der Ressource zugeordneten Adresse sowohl HTMLals auch XML-Repräsentationen liefern. REST ist zustandslos, was sich wiederum positiv auf die Skalierbarkeit des Webservices auswirkt. So ist es zum Beispiel möglich, bei
erhöhten Anfragen, eine Lastverteilung ohne weitere Probleme auf mehrere Maschinen
vorzunehmen, weil jeder Request in sich geschlossen ist und Anwendungsinformationen
ausschließlich auf Clientseite gegeben werden. Weiterhin können einzelne Ressourcen untereinander verlinkt werden, ohne dass anderweitige Infrastruktur notwendig ist. Operationen die unter REST umgesetzt werden können sind typische HTTP-Operationen
wie GET, POST, PUT und DELETE, da dass Transportprotokoll Hypertext Transfer
Protocol (HTTP) zum Einsatz kommt.
5.1.5. Hatchery
In diesem Meilenstein soll das Modul Hatchery implementiert werden. Dieses Paket
ermöglicht das dynamische Hinzufügen von neuen Agenten zur Laufzeit sowie die Rekombination einzelner Agententypen und Methoden von Agenten untereinander.
78
Sowohl das dynamische Hinzufügen von Agenten zur Laufzeit, als auch die Rekombination der Agenten soll eine höchstmögliche Adaption der Funktionalität der Software an
die Wünsche des einzelnen Endnutzers von Jinengo ermöglichen. Im Folgenden sollen
die einzelnen Merkmale dieses Moduls genauer erläutert werden.
Dynamisches Hinzufügen von neuen Agenten
Das Hauptziel dieser Funktionalität ist, dass bei Jinengo registrierte Agentenentwickler
eigene Implementierungen von einzelnen Agententypen (z.B. Routenplanungs-Agenten)
vornehmen können und diese dann zur Laufzeit zum Programm hinzugefügt werden. Das
hat den Vorteil, dass es später viele verschiedene Agenten zur Lösung des gleichen Problems geben wird. So wird nicht nur die Gesamtqualität der Software gesteigert, sondern
es werden ganz neue Möglichkeiten für den jeweiligen Endnutzer eröffnet. Jinengo wählt
später die für den Nutzer am sinnvollsten agierenden Agenten aus und rekombiniert diese
mit anderen Agenten.
Das dynamische Hinzufügen von Agenten kann nur dann richtig funktionieren, wenn diese vorher auf ihre Funktionalität hin überprüft werden. Deshalb besteht die Anforderung,
dass zwei verschiedene Überprüfungsmechanismen implementiert werden.
Zunächst muss nach dem Hochladen eine automatische Überprüfung des Quellcodes erfolgen. Dieser Schritt soll automatisch vom System durchgeführt werden und ist ein
erstes Kriterium dafür, ob der Agent in das Jinengo-System geladen werden darf. Anschließend soll eine nicht automatische Überprüfung der eigentlichen Funktionalität des
Agenten erfolgen. Diese Überprüfung soll von einem Administrator des Jinengo-Systems
durchgeführt werden. Eine automatische Überprüfung der Funktionalität ist auf Grund
der hohen Komplexität der Agenten nicht sinnvoll.
Rekombination der Agenten
Wie bereits erwähnt, soll in diesem Meilenstein die Rekombination von Agenten ermöglicht werden. Diese Rekombination soll abhängig von den Präferenzen des jeweiligen Jinengo-Nutzers vorgenommen werden, sodass dieser die für ihn idealen Ergebnisse
erhält.
Eine Rekombination von Agenten soll auf zwei verschiedene Arten stattfinden. Zum einen
können die verschiedenen Agententypen aus dem Paket com.jinengo.Contentrepository
so miteinander kombiniert werden, dass die Ergbnisliste an die Präferenzen des Nutzers
angepasst wird.
Zum anderen sollen verschiedene Implementierungen der Matchmaker-Agenten aus dem
Paket com.jinengo.AdaptationEngine so gekreuzt werden, dass ein für den Nutzer idealer
79
MatchMaker-Agent entsteht. Im Folgenden sollen diese Ideen näher erläutert werden.
Rekombination der com.jinengo.Contentrepository Agenten Die Idee ist, die bei einer Routenabfrage verwendeten Agenten aus den Agentengruppen Routenplaner, Emissionskalkulator und Kostenkalkulator für jedes Transportmittel jeweils so zu kombinieren,
dass das Ergebnis für den Jinengo-Nutzer die maximale Zufriedenstellung ermöglicht.
Die folgende Abbildung verdeutlicht dies.
Abbildung 5.2.: Rekombination der Agenten des Contentrepository
Diese Rekombination findet innerhalb der Matchmaker statt und kann somit automatisch, d.h. ohne das Eingreifen eines Administrators vorgenommen werden.
Rekombination der com.jinengo.AdaptationEngine Agenten Ein Matchmaker-Agent,
welcher die eigentliche Rekombination der Contentrepository-Agenten abhängig von den
Nutzerpräferenzen vornimmt, soll ebenfalls rekombiniert werden. Dazu sollen verschiedene, als public-gekennzeichnete Methoden aus verschiedenen Matchmakern in einem
neuen Matchmaker rekombiniert werden. Die folgende Abbildung zeigt das Vorgehen.
Diese Rekombination findet nicht automatisch statt, sondern wird von einem Nutzer der
Nutzergruppe Agent-Assembler durchgeführt.
80
Abbildung 5.3.: Rekombination der Agenten der Adaptationengine
1
1
Dienstleister
1
Potentielle Fahrgemeinschaften abrufen
1
Mobilitätsdienstleister
Abbildung 5.4.: Anwendungsfall: Potentielle Fahrgemeinschaften abrufen
Die folgenden Abschnitte beschreiben die Anwendungsfälle, die in Iteration B des Projektes neu hinzugekommen sind.
5.2.1. Potentielle Fahrgemeinschaften abrufen
Dieser Anwendungsfall erlaubt es, Mobilitätsdienstleistern, wie z.B. Mitfahrzentrale.de
potentielle Partner für Fahrgemeinschaften abzurufen, damit diese dann von dem Dienstleister gezielt angesprochen werden können, um Werbung für eine Fahrgemeinschaft zu
81
Abbildung 5.5.: Anwendungsfall: Neuen Contentrepository-Agenten hinzufügen
machen.
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Potentielle Fahrgemeinschaften abrufen
Passende Fahrgemeinschaftspartner erhalten
Dienstleister
—
1) Anfrage stellen
—
—
—
Tabelle 5.4.: Anwendungsfall: Potentielle Fahrgemeinschaften abrufen
5.2.2. Neuen Contentrepository-Agenten hinzufügen
Dieser Anwendungsfall beschreibt, wie neue Contentrepository-Agenten zum System hinzugefügt werden.
82
Abbildung 5.6.: Anwendungsfall: Neuen Matchmaker-Agenten hinzufügen
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Neuen Contentrepository-Agenten hinzufügen
Contentrepository-Agenten zur Laufzeit
hinzufügen
Agenten Entwickler
Der neue Contentrepository-Agent muss
entwickelt worden sein
1) Agenten hochladen
Der Agent kann im System verwendet
werden
Der Agent ist fehlerhaft
Der Agent wurde nicht zum System hinzugefügt
Tabelle 5.5.: Anwendungsfall: Neuen Contentrepository-Agenten hinzufügen
5.2.3. Neuen Matchmaker-Agenten hinzufügen
Dieser Anwendungsfall beschreibt, wie neue Matchmaker-Agenten zum System hinzugefügt werden.
83
Abbildung 5.7.: Anwendungsfall: Matchmaker-Agenten rekombinieren
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Neuen Matchmaker-Agenten hinzufügen
Matchmaker-Agenten zur Laufzeit hinzufügen
Agenten Entwickler
Der neue Matchmaker-Agent muss entwickelt worden sein
1) Agenten hochladen
Der Agent kann im System verwendet
werden
Der Agent wurde nicht zum System hinzugefügt
Tabelle 5.6.: Anwendungsfall: Neuen Matchmaker-Agenten hinzufügen
5.2.4. Matchmaker-Agenten rekombinieren
Dieser Anwendungsfall beschreibt, wie Matchmaker-Agenten untereinander rekombiniert
werden.
84
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Matchmaker-Agenten rekombinieren
Matchmaker-Agenten zur Laufzeit rekombinieren
Agent Assembler
Es müssen mindestens zwei MatchmakerAgenten im System vorhanden sein
1) Agenten rekombinieren
Der rekombinierte Agent kann im System
verwendet werden
Ein neuer Agent kann nicht rekombiniert
werden
Tabelle 5.7.: Anwendungsfall: Matchmaker-Agenten rekombinieren
85
6. Pflichtenheft Teil C
6.1. Einführung
Die folgenden Abschnitte beschreiben die Anforderungen an die dritte Iterationsstufe
des Projekts Jinengo. Auf Basis des zweiten Prototypen wurde das vorliegende System
auf Zielerreichung hin untersucht und offene Aspekte identifiziert. Diese Aspekte wurden
klassifiziert und einzelnen Schwerpunkten zugeordnet. Dabei folgt die Zuordnung dem
modularen Charakter des Systems.
Dieses Dokument stellt die Grundlage für den Entwurf des Meilensteins C dar. Grundsätzliche
Anforderungen, die in der Analyse der Meilensteine A und B identifiziert wurden, werden an dieser Stelle nicht gesondert aufgeführt. Ausnahme stellen jene Aspekte dar, die
im vorangegangenen Prototypen nicht vollständig umgesetzt wurden.
Um die zeitgerechte Umsetzung zu gewährleisten, hat sich das Projektteam in Untergruppen organisiert, die für die Realisierung eines Teilbereichs verantwortlich sind. Diese Organisationsstruktur wird auch genutzt, um die Vollständigkeit der Anforderungen
durch eine gegenseitige Kontrolle zu gewährleisten.
6.2. Nicht umgesetzte Anforderungen aus Meilenstein B
ALL: Pflichtenheft B durchlesen und nicht umgesetzte Anforderungen (oder Anforderungen die erst in MS C fertig wurden mit Begründung aufschreiben
6.2.1. Frontend
An dieser Stelle sollen nochmal die Anforderungen des Frontends aus Meilenstein B
hinsichtlich ihres Realisierungsgrades betrachtet werden. Aus unterschiedlichen Gründen
wurden tatsächlich nicht alle Anforderungen umgesetzt. Siehe hierzu die nachfolgende
Tabelle:
87
Gesetzte Anforderungen
Ein Frontend was keinen Prototyp Charakter mehr aufweist
Online-Verfügbarkeit für alle Interessenten
Zugriff auf alle essentiellen Einstellungsmöglichkeiten (eigenes Auto usw.)
Fehlerabhängige Rückmeldungen, welche
für den Menschen verständlich sind.
Möglichkeit zur Laufzeit verschiedene
User-Controls tauschen zu können (um
z.B. die Ergebnisdarstellung zu beeinflussen (z.B. Liste, Bubbles, ...))
Möglichkeit für den Endanwender Designs
zu wechseln
Bewertungsmöglichkeit für Pages und Designs
Bewertungsmöglichkeit des Contents
Einbindung einer AGB in das WebFrontend, um mit anonymisierten Kundendaten Geschäfte machen zu können
88
Realisierte Anforderungen
Realisiert
Realisiert
Verschiedene Präferenzen können aus dem
CRM abgefragt und geändert werden.
Weitere Einstellungsmöglichkeiten stehen
noch aus
Teilweise realisiert
Weitestgehend realisiert
Wird aufgrund eines Change-Requests der
Betreuer nicht weiter verfolgt
Nicht realisiert
Wird aufgrund eines Change-Requests der
Betreuer nicht weiter verfolgt
Realisiert
Realisiert
6.2. Nicht umgesetzte Anforderungen aus Meilenstein B
6.2.2. Admin Frontend
Hochladen von Agenten über ein Formular, welches ein Feld zum Dateiupload
enthält und ein Textfeld um den Namen
des Agenten einzugeben.
Auflistung aller Agenten innerhalb des
Systems.
Starten, Stoppen, Löschen, Ersetzen und
Updaten der eigenen Agenten.
Agenten, die Teil eines Verhaltensmusters sind können nicht gelöscht, gestoppt
oder ersetzt werden. Das Ersetzen eines
Agenten erfolgt in dem Fall durch Bereitstellung einer weiteren/neuen Version von
dem Agenten.
Informationen über eigene Agenten einsehen: Hochgeladen am, Läuft seit, Aufrufe
oder Anfragen seit erstem Start.
Status-Information:
Freigeben,
In
Prüfung, Abgelehnt (mit Angabe eines Grundes).
Auflistung aller Verhaltensmuster.
Anlegen, Freigeben, Sperren, Löschen, Ersetzen oder Updaten von eigenen Verhaltensmustern.
Der Verhaltensentwickler erhält eine Informations-Meldung, wenn eine
neue Version eines Agenten aus seinem
Verhaltensmusters erschienen ist.
Informationen über eigene Agenten einsehen: Erstellt am, Freigegeben seit, Aufrufe/Anfragen seit erster Freigabe.
Realisiert
Realisiert
Nein, kein Bedarf.
Nein, kein Bedarf
Realisiert
Realisiert
Realisiert
Teilweise
Nein, kein Bedarf.
Teilweise
89
6.2.3. CRM
Front-End-Funktionen
Marketing-Kampagne
BI-Funktionen
Realisiert. Die Jinengo Endnutzer-Daten
und Routen-Daten befinden sich im CRM
auf Basis des Ontologie-Ansatzes.
Nicht realisiert. Aufbau des Data Warehouses erstreckte sich vom Zeitaufwand
höher als erwartet. Marketing-Liste und
Kampagnen-Funktion sind jedoch bereits
nativ im CRM integriert und daher schnell
zu realisieren.
Realisiert. Relevante Daten werden
zunächst in eine Staging Area übertragen,
anschließend transformiert und in eine
Basisdatenbank geladen. Von hier aus
erfolgt nochmals eine Transformation
und das Laden relevanter Daten in Data
Marts des Data Warehouses.
6.3. Snippets und Messages
In Meilenstein C soll das Jinengo-Frontend um Snippets erweitert werden, in denen Werbebotschaften oder allgemeine Nachrichten angezeigt werden können. Diese Nachrichten
werden sind entweder reine Textnachrichten oder können als Link zu einer Bildresource
interpretiert und angezeigt werden.
Auf Backendebene wird die Bereitstellung solcher Nachrichten (AdviseMessages) über
eine neue Agentenklasse, sog. MessagingProvider realisiert, die auf Basis von einem
gegebenen Kontext (z.B. User-ID und betrachtete Seite) entscheiden, welche Nachricht
angezeigt werden soll. Um diese Entscheidung zu fundieren, kann der Agent über die
bestehende Sparql-Schnittstelle weitere Daten über den User beziehen. Anschließend
entscheidet jeder Agent, wie viel ihm die Platzierung der Nachricht wert ist.
Die Nachricht des höchstbietenden Agents wird daraufhin auf der Website berücksichtigt
und im Snippet angezeigt.
Weiterhin sollen Messagingklassen eingeführt werden, die Nachrichten bspw. in Werbung,
Statusmeldungen und allgemeine Informationen unterteilen. Diese Klassifizierung kann
beispielsweise herangezogen werden, um Statusmeldungen immer Werbung vorzuziehen,
unabhängig von der Gebotshöhe.
90
6.4. Frontend
6.4. Frontend
Im Meilenstein C soll das Frontend primär optisch aufgewertet werden. Neue Funktionen
sind hingegen nicht vorgesehen. Jedoch sollen noch Punkte abgearbeitet werden, die im
Meilenstein B nicht vollendet wurden. Hierzu zählen:
Fehlerabhängige Rückmeldungen, welche für den Menschen verständlich sind
Zu den optischen Anforderungen für den Meilenstein C zählen folgende Punkte:
Einbindung des JQuery Mobile Framworks zur Einführung eines App-mäßigen Designs
Einbindung des MVC 3 Pattern zur besseren Codestrukturierung
6.5. Backend
Das Backend soll im Meilenstein C um Funktionen erweitert werden, welche es dem
Endnutzer ermöglichen, die gelieferten Ergebnisse zu bewerten und somit eine Adaption
des Backends an die Bedürfnisse des Kunden zu erreichen. Dazu soll zum einen eine
Methode implementiert werden, die die gelieferte Ergebnismenge (also alle Routen zu
einer Anfrage) als Ganzes bewertet und so die Agenten, welche das Ergebnis berechnet
haben, in ihrer Qualität zu beurteilen.
Zum anderen soll eine Methode zur Verfügung gestellt werden, welche eine implizite
Anpassung des Systems an die Kundenbedürfnisse ermöglicht. Diese Methode wird im
Frontend immer dann aufgerufen, wenn ein Nutzer sich die Details zu einer Route anschaut. Aus dem Wissen, welche expliziten Präferenzen der Nutzer im CRM-System
angegeben hat und aus dem Wissen, welche wahren Präferenzen er bei der Nutzung
Systems hat, kann das Backend dann eine Adaption durchführen.
Als weitere Anforderung besteht, dass das Backend mit dem CRM-System über die
RDF-Anfragesprache SPARQL kommunizieren kann. So soll ermöglicht werden, dass
die Nutzerspezifischen Daten, welche im CRM gespeichert werden, im Backend für die
Adaption genutzt werden kann.
Weiterhin soll ein Software-Development-Kit (SDK) für die Agentenentwickler erstellt
werden, sodass eine problemlose und einfache Entwicklung von neuen Agenten für die
Plattform möglich ist. Die letzte Anforderung für diesen Meilenstein ist die optimierung
des Codes und der Geschwindigkeit des Systems. So soll zum Beispiel eine maximale Abfragedauer für eine Route eingestellt werden können, um die Nutzbarkeit des Systems
zu erhöhen.
91
6.6. Data Warehouse
Die Jinengo Endnutzer werden während des studentischen Projekts im Microsoft Dynamics CRM 2011, dem operativen Customer Relationship Management - System, verwaltet. Die Erweiterung des operativen Systems, um die Komponente Microsoft SQL Server
2008 R2 Enterprise Edition, einem analytischem CRM - System, erlaubt es, komplexe
Fragestellungen an das Nutzerverhalten zu stellen und diese konkret zu beantworten.
Die Auswertungen finden in der von Microsoft vorgeschlagenen Standard Definition für
Berichte statt, der sogenannten Report Definition Language (RDL). Auf Basis der gelieferten Berichte und dem Entdecken bestimmter Muster in den Daten (Data Mining)
sollen sowohl die Jinengo-Services optimiert als auch die Jinengo Endnutzer zu intensiverer Nutzung nachhaltiger Mobilität angeregt werden bei gleichzeitiger Berücksichtigung
individueller Bedürfnisse und Präferenzen.
Die Kopplung von Microsoft Dynamics CRM 2011 und Microsoft SQL Server 2008 R2
Enterprise Edition soll über Web Services realisiert werden.
Die Kopie der operativen Daten in das Data Warehouse, sowie anschließende Extract,
Transform und Load (ETL) - Prozesse und das Historisierungskonzept Slowly Changing
Dimensions (SCD) Typ 2 sollen per One-Click über das Jinengo Control Panel (Admin
GUI) umgesetzt werden. Ebenso soll die Möglichkeit bestehen per One-Click gewünschte
Kennzahlen zurück zum operativen CRM zu laden und dort zu aktualisieren.
Die Report-Erstellung soll zur größtmöglichen Flexibilität über Microsoft SQL Server
Business Intelligence Development Studio (BIDS) erfolgen.
6.7. Berichterstellung
Jinengo verwendet MS CRM 2011-Berichterstellungserweiterung um benutzerdefinierte
Berichte mithilfe von Business Intelligence Development Studio(BIDS) zu erstellen. BIDS
synchronisiert die Quelldaten mit MS CRM 2011 Online nach der Eingabe von entsprechende connection string und credentials. Die von BIDS erstellten Berichte werden als
.rdl Datei gespeichert und wieder in MS CRM 2011 Online importiert. Als Beispiel wurden drei Berichte erstellt,die sind User CO2 Emission per Route.rdl, User KPI Total.rdl,
User KPI Value based on ArrivalDate.rdl.
User CO2 Emission per Route.rdl. Der Bericht stellt eine Übersicht der CO2Emission
von Kunden nach einzelne Route dar, siehe Abbildung 6.1 6.2
User KPI Total.rdl. Der Bericht stellt total KPI Value von Kunden nach KPI
Typen dar, siehe Abbildung 6.3 6.4
92
User KPI Value based on ArrivalDate.rdl. Der Bericht stellt eine Übersicht der KPI
Value nach KPI Typen basiert auf Ankunftdatum von Route dar, siehe Abbildung
6.5 6.6
Abbildung 6.1.: User CO2 Emission per Route
Die folgenden Abschnitte beschreiben die Anwendungsfälle, die in Meilenstein C des
Projektes neu hinzugekommen sind.
6.8.1. Advise Messaging
Dieser Anwendungsfall beschreibt den Prozess des AdviseMessagings.
93
Abbildung 6.2.: User CO2 Emission nach Route
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
94Sonderfall
AdviseMessaging
Kontextsensitive Informationen anzeigen
MessagingProvider Agent
Der entsprechende Agent muss im Wettbewerb mit anderen Agenten eine Auktion gewonnen haben
1) Ein Agent bietet um eine Anzeigemöglichkeit seiner kontextbezogenen
Informationen
2) Der Agent bekommt den Zuschlag
3) Der Agent darf nun kontextsensitive
Informationen anzeigen
Der Agent zeigt kontextsensitive Informationen an
Der Agent ist nicht Höchstbietender
Derjenige Agent mit dem höchsten Gebot bekommt den Zuschlag und darf seine eigenen kontextsensitiven Informationen anzeigen
Tabelle 6.1.: Anwendungsfall: AdviseMessaging
6.8.2. Data Warehouse Prozess
Dieser Anwendungsfall beschreibt, wie der Data Warehouse Prozess aussieht:
Name
Ziel
Akteur
Vorbedingung
Ablauf
Nachbedingung
Sonderfall
Data Warehouse Prozess
Operative Datenbestände langfristig zur
Analyse persistieren
Jinengo Admin
Es existieren operative Datenbestände
1) Die operativen Datenbestände werden
in eine temporäre Datenbank geladen
2) Der erste ETL-Prozess wird ausgeführt
und Daten von der temporären Datenbank in eine Basisdatenbank übertragen
3) Der zweite ETL-Prozess wird ausgeführt und Daten von der Basisdatenbank werden zur Analyse in die Zieldatenbank geladen
4) Kennzahlen werden berechnet
5) Berechnete Kennzahlen werden in das
operative CRM-System zurückgeladen
Die operativen Datenbestände wurden erfolgreich persistiert, ETL-Prozesse erfolgreich ausgeführt und Daten gegebenenfalls historisiert. Weiterhin wurden Kennzahlen kalkuliert und zum operativen
CRM-System zurückgeladen.
1) Es existieren keine operativen Daten
2) Es existieren bereits Kennzahlen
1) Es erfolgt keine Ausführung des Data
Warehouse Prozesses
2) Existierende Kennzahlen werden
überschrieben
Tabelle 6.2.: Anwendungsfall: Data Warehouse Prozess
95
Abbildung 6.3.: User KPI Total
96
Abbildung 6.4.: User KPI Total nach Typen
97
Abbildung 6.5.: KPI Value based on ArrivalDate
98
Abbildung 6.6.: KPI Value based on ArrivalDate nach User
99
Abbildung 6.7.: Anwendungsfall: AdviseMessaging
Abbildung 6.8.: Anwendungsfall: Data Warehouse Prozess
100
Teil III.
Entwurf
101
7. Systemarchitektur
Dieses Kapitel beschäftigt sich mit der grundliegenden Systemarchitektur der Jinengo
- Anwendungsplattform. Es soll einen Überblick über den Entwurf zeigen und die Modellierung der Software erläutern. Zu diesem Zweck werden Sequenzabläufe und Klassendiagramme gezeigt, welche die Bestandteile von Jinengo zeigen und ihre einzelnen
Bedeutungen herausstellen. Die Modellierung wird in die Komponenten Server und Client unterteilt.
Zudem wird die Auswahl der verwendeten Kerntechnologien erläutert. Hierzu zählen alle eingebundenen Bibliotheken und Anwendungen, welche direkt von der Anwendungsplattform genutzt werden. Solche sind zum Beispiel Datenbanksysteme. Es ist zu beachten, dass auch Software, welche im Implementierungsprozess unmittelbar mit der
Anwendungsplaattform in Kontakt tritt, aufgeführt wird. Zu diesen indirekt genutzte
Anwendungen gehören zum Beispiel Build-Werkzeuge. Alle verwendeten Technologien
wurden analysiert und anhand der schwerwiegendsten Kriterien, welche für die Anwendungsplattform relevant sind, ausgewählt. Abschließend wird die Anbindung der Anwendungsplattform an ein Customer Relationship System gezeigt. In diesem Abschnitt wird
erläutert, in welchem Kontext eine generische Anbindung von CRM-Systemen ermöglicht
wird und die Implementierung einer konkreten Anbindung an ein Microsoft CRM-System
realisiert wird.
Zuletzt wird gezeigt, welche allgemeinen Werkzeuge genutzt worden sind. Hierzu gehört
zum Beispiel die Auswahl eines Versionskontrollsystems.
7.1. Server
Dieser Abschnitt widmet sich dem Entwurf der serverseitigen Anwendungskomponente.
Im Folgenden werden UML-Modelle, welche den Aufbau der Klassen und Softwareteile
beschreiben, vorgestellt. Darüber hinaus wird eine Technologieevaluation erklärt, welche
die optimale Technologie zur Realisierung des Entwurfs sucht. Die daraus resultierende
Menge von konkreten Technologien wird dann zur Implementierung der Anwendung
eingesetzt.
103
7.1.1. Klassenentwurf
Im folgenden wird eine Gesamtübersicht über den akutellen Stand des Klassendiagrammes gegeben. Dabei werden die einzelnen Komponenten dargestellt und deren Gesamtfunktionalität erläutert.
Paket com.jinengo.Environment
Dieses Paket enthält Klassen für die Konfiguration und das Starten der Anwendung.
Dabei werden beim Start die nicht austauschbaren Agenten PresentationManager, UserManager, ContentManager und Adaptationmanager in die Agentenumgebung geladen.
Des Weiteren wird an dieser Stelle der PresentationManager als JAX-Webservice aktiviert. Abbildung 7.1 gibt einen Überblick über dieses Paket.
Paket com.jinengo.PresentationComposer
Dieses Paket enthält das Interface IPresentationManger, welches alle Methoden für den
Webservice und damit für die Schnittstelle des Systems nach außen definiert. Die Klasse
PresentationManager ist eine konkrete Implementierung des Interfaces. Zusätzlich ist
diese Klasse als Agent definiert. Des Weiteren existiert die Klasse RestfulPresentationManager, welche den einen REST-WebService zur Verfügung stellt. Abbildung 7.2 und
Abbildung 7.3 geben einen Überblick über dieses Paket.
Paket com.jinengo.AdaptationEngine
Dieses Paket enthält die für die Adaption notwendigen Klassen. Dabei verwaltet der
AdaptationManager als Agent die verschiedenen konkreten Instanzen der abstrakten
Klasse MatchMaker. Der Matchmaker stellt zum Beispiel Methoden zum Sortieren der
Ergebnislisten zur Verfügung. Die Klasse SustainableMatchmaker ist eine beispielhafte
konkrete Ausprägung eines Matchmakers. Abbildung 7.4 gibt einen Überblick über dieses
Paket.
Paket com.jinengo.UserModelModule
Dieses Paket enthält Klassen, welche die Verwaltung der Benutzer des Systems ermöglichen. Dazu gehört neben der UserManager-Klasse, welche als Agent die grundlegende
Verwaltung der verschiedenen User-Objekte übernimmt, auch das Interface ICRMAdapter. Eine Implementierung des ICRMAdapter-Interfaces ermöglicht die Anbindung eines
104
7.1. Server
Abbildung 7.1.: Paket com.jinengo.Environment
105
106
Abbildung 7.2.: Paket com.jinengo.PresentationComposer Teil 1
7.1. Server
Abbildung 7.3.: Paket com.jinengo.PresentationComposer Teil 2
107
Abbildung 7.4.: Paket com.jinengo.AdaptationEngine
108
7.1. Server
CRM-Systems an das Jinengo-System. Der DynamicsAdapter stellt eine solche konkrete
Implementierung für die Anbindung an ein Microsoft Dynamics 2011 CRM-System dar.
Abbildung 7.5 gibt einen Überblick über dieses Paket.
Paket com.jinengo.ContentRepository
Dieses Paket ist für die Verwaltung der verschiedenen Agententypen zuständig. Zu den
Agententypen gehören unter anderem Routenplanungsagenten, Emissionskalkulatoren
und Kostenkalkulatoren. Weiterhin werden in diesem Paket die notwendigen Interfaces,
welche als Vorlage für die Agenten genutzt werden, gespeichert. Abbildungen 7.6, 7.7,
7.8, 7.9 und 7.10 geben einen Überblick über dieses Paket.
Paket com.jinengo.MessagingModule
Dieses Paket verwaltet die Agenten, die zur Generierung von kontextabhängigen Nachrichten für das Jinengo-Frontend zuständig sind. Die Aufgabe dieser Agenten ist es,
anhand eines gegebenen Kontextes eine passende Nachricht zu generieren und ein Gebot
für einen freien Nachrichtenplatz abzugeben. Abbildung 7.11 gibt einen Überblick über
dieses Paket.
Paket com.jinengo.Hatchery
Dieses Paket ist dafür zuständig, dass zur Laufzeit neue Agenten zum Jinengo-System
hinzugefügt werden können. Neben Funktionen zum Kompilieren und Einbinden der
neuen Agenten existieren auch automatische Mechanismen zum Überprüfen der syntaktischen Richtigkeit der hochgeladenen Agenten. Die Abbildung 7.12 gibt einen Überblick
über die Klassen und Methoden dieses Pakets.
7.1.2. Sequenzdiagramme
In den folgenden vier Unterabschnitten werden der Systemstart, eine einfache Nutzerabfrage vom Frontend bis zum CRM-System, eine Routenabfrage und eine Abfrage einer
AdviseMessage vom Frontend bis zu den MessagingProvidern anhand von Sequenzdiagrammen beschrieben.
109
Abbildung 7.5.: Paket com.jinengo.UserModelModule
110
7.1. Server
Abbildung 7.6.: Paket com.jinengo.ContentRepository
111
Abbildung 7.7.: Paket com.jinengo.ContentRepository.interfaces
Sequenzdiagramm: Application Startup
Das Sequenzdiagramm in Abbildung 7.13 beschreibt die Objektinitialisierungen beim
Systemstart.
Sequenzdiagramm: Simple User Operations
Das Sequenzdiagramm in Abbildung 7.14 und 7.15 beschreibt wie einfache Benutzeroperationen in dem System behandelt werden.
Sequenzdiagramm: LookUpRoute
Das Sequenzdiagramm in Abbildung 7.16 beschreibt, wie eine Routenanfrage durch das
System gereicht wird. Wichtig ist dabei zu beachten, dass die Komponenten untereinander teilweise über das vom JADE-Framework vorgebene ACL-Message-Protokoll
kommunizieren, um so eine höchstmögliche Modularität der Agentenkomponenten zu
erreichen.
112
7.1. Server
Abbildung 7.8.: Paket com.jinengo.ContentRepository.contentprovider
113
Abbildung 7.9.: Paket com.jinengo.ContentRepository.contextprovider
Abbildung 7.10.: Paket com.jinengo.ContentRepository.tooling
114
<<interface>>
IMessagingProvider
<<interface>>
<<realize>>
serialVersionUID : long
MessagingProvider
MessagingManager
BiddingThread
run()
BiddingThread(reference : UUID,customer : Customer,page : Page,contextData : Object,provider : IMessagingProvider)
customer : Customer
page : Page
contextData : Object
provider : IMessagingProvider
bid : double
reference : UUID
getInstance() : MessagingManager
getMessage(customer : Customer,page : String,contextData : Object) : SnippetMessage
setup() : void
MessagingManager()
<<realize>>
<<realize>>
getBid(reference : UUID,customer : Customer,page : Page,contextData : Object) : double
getResult(reference : UUID) : SnippetMessage
DefaultProvider
instance : MessagingManager
messagingProviders : ArrayList<IMessagingProvider>
<<realize>>
java.lang.Thread
com.jinengo.MessagingModule.Provider
java.io.Serializable
com.jinengo.MessagingModule
jade.core.Agent
defines whether a SnippetMessage
is an ad, status message etc.
defines whether the returned
snippet is a simple String, an
URI to an image resource etc.
MessagingProviderValidator
ProviderRepositoryManager
MessagingProviderValidator()
unitTestAgent(provider : MessagingProvider) : boolean
testIMessagingProviderMethods(provider : MessagingProvider) : boolean
checkSuperClass(MessagingProvider : provider,s : String) : boolean
getInstance() : MessagingProviderValidator
instance : MessagingProviderValidator
getInstance() : ProviderRepositoryManager
setup() : void
ProviderRepositoryManager()
deleteMessagingProvider(messagingProviderName : String) : void
uploadMessagingProvider(agentFile : byte,author : AgentDeveloper,fileName : String,description : String) : void
deleteClassFileFromRepo(className : String) : void
moveClassFile(startDir : File,destDir : File,className : String) : void
findClassName(source : String,className : String) : String
moveDirectory(srcFile : File,destFile : File) : boolean
getSourceCodeFromFile(sourceCode : File) : String
upload(agentFile : byte[],sourceFolder : String) : File
compileAgent(javaFile : File,directory : String) : void
loadAllAgentsFromRepoIntoRuntime() : void
ts2mysqldatestring(timeInMillis : long) : String
loadAllAgentInfosFromDatabase() : void
instance : ProviderRepositoryManager
mySql : MySqlConnector
messagingProviderInfos : ArrayList<MessagingProviderInfo>
MessagingProviderInfo
com.jinengo.MessagingModule.Provider.Repository
com.jinengo.Hatchery.AgentInfoj
adviseType : String
content : Object
adviseClass : String
AdviseMessage
com.jinengo.MessagingModule.Advise
7.1. Server
Abbildung 7.11.: Paket com.jinengo.MessagingModule
115
Abbildung 7.12.: Paket com.jinengo.Hatchery
116
7.1. Server
Abbildung 7.13.: Sequenzdiagramm Application Startup
117
Abbildung 7.14.: Simple User Operations - Teil 1
118
7.1. Server
Abbildung 7.15.: Simple User Operations - Teil 2
119
Abbildung 7.16.: Sequenzdiagramm LookUpRoute
120
7.1. Server
Sequenzdiagramm: getMessage
Das Sequenzdiagramm in Abbildung 7.17 beschreibt, wie eine Anfrage nach einer Nachricht durch das System gereicht wird. Wichtig ist dabei zu beachten, dass die Komponenten untereinander teilweise über das vom JADE-Framework vorgebene ACL-MessageProtokoll kommunizieren, um so eine höchstmögliche Modularität der Agentenkomponenten zu erreichen.
7.1.3. ER-Modelle
Dieser Abschnitt beschreibt die Datensicht des Jinengo-Systems anhand von EntityRelationship Modellen, sowohl mit Bezug auf die Nutzerverwaltung als auch hinsichtlich
der BI-Funktionen.
CRM
Das CRM-System persistiert sämtliche Daten über die Jinengo Endanwender und deren
Eigenschaften, sowie angefragte Routen etc. Abbildung 7.18 7.19 zeigt die zu erstellenden
Entitäten im CRM-System.
Data Warehouse
Das Data Warehouse dient der losen Kopplung von BI-Funktionen an das CRM-System.
Hierdurch wird ein geringer Grad an Abhängigkeit erzielt, Änderungen können schnell
realisiert werden und komplexe Fragestellungen individuell, schnell und flexibel beantwortet werden. Das Data Warehouse setzt sich aus drei Ebenen zusammen: Der Staging–
Area, der Basisdatenbank und dem Data Warehouse. Die Staging–Area wird hier nicht
graphisch aufgezeigt, da sie lediglich eine Spiegelung der Entitäten Resourcen, Triples
und JinengoUser aus dem CRM-System darstellt. Die übrigen beiden Ebenen Basisdatenbank und Data Warehouse werden folglich in Abbildung C.4 und Abbildung C.5
aufgezeigt, wobei die Staging–Area die Datenquelle für die Basisdatenbank und diese
wiederum Datenquelle für die Ebene Data Warehouse darstellt.
7.1.4. Technologieevaluation
Dieser Abschnitt dient zur Auswertung verschiedener Technologien zur Realisierung des
oben aufgeführten Entwurfs.
121
122
Abbildung 7.17.: Sequenzdiagramm getMessage
getResult()
join()
run()
/instance:MessagingManager
AdviseMessage()
getMessage()
:PresentationManager
getBid()
:BiddingThread
:IMessagingProvider
7.1. Server
Abbildung 7.18.: MS CRM Ontology Model
Abbildung 7.19.: MS CRM Model
Abbildung 7.20.: ER-Model Basisdatenbank
123
Abbildung 7.21.: ER-Model Datawarehouse
124
7.1. Server
Kriterien zur Auswahl
Als vorrangiges Kriterium bei der Auswahl einer konkreten Technologie ist die Unterstützung von Multi-Agenten Systemen (MAS) zu wählen. Es ist ein Framework zu
finden, welches die Entwicklung von MAS unterstützt und eine Orientierung des zu entwickelnden System in diese Richtung fördert. Als wichtige Ausprägung der Technologie
ist die Abdeckung der Spezifikationen der Foundation for Intelligent Physical Agents zu
nennen. Der Einsatz von standardisierten Frameworks zur Entwicklung und Ausführung
von Agenten ist Schlüssel für das erfolgreiche Transferieren von standardisierten Agenten
zwischen unterschiedlichen Agenten-Runtimes. Darüberhinaus ist die Vertrautheit der
Projektgruppenmitglieder mit der Entwicklungsumgebung wichtig. Wenn schon Kenntnisse vorhanden sind, kann viel an Einarbeitungszeit gespart werden.
Alternative Technologien
Die erste Technologiealternative ist das auf Java basiernde JADE (Java Agent Development Framework). Diese Plattform entspricht den Spezifikationen der FIPA und stellt
alle geforderten Funktionalitäten des Entwurfs bereit. Als zusätzlicher Bonus ist JADE
in Java implementiert. Java wird von den meisten Projektgruppenmitgliedern beherrscht
und muss daher nicht erneut erlernt werden.
Die zweite Alternative ist das ADF (Agent Development Framework). Das ADF ist
ähnlich wie JADE in Java implementiert und bietet daher ebenfalls ausreichend Entwicklungskomfort für alle beteiligten Projektgruppenmitglieder. Im Gegensatz zu JADE
verfügt das ADF nicht über einen vollständigen Abdeckungsgrad der FIPA-Spezifikationen. Daher ist JADE hier im Vorteil und gewinnt im direkten Vergleich gegen JADE.
Die dritte untersuchte Alternative ist JACK Intelligent Agents. Diese Framework ist
das einzige kommerzielle Framework, das untersucht wurde und hat daher gewisse Einschränkungen. Eine erste Untersuchung der Funktionsübersicht ergab, dass die Abdeckung der benötigten Funktionen ungefähr dem Abdeckungsgrad von JADE entspricht.
Auch in diesem direkten Vergleich gewinnt JADE, da hier keine kommerziellen Einschränkungen entstehen. Zudem ist der Quelltext offen einsehbar, sodass dieser im Zweifelsfall als Referenz genutzt werden kann.
Aufgrund dieser Eigenschaften fällt die Entscheidung der Agententechnologie auf JADE.
Laufzeit- und Entwicklungsumgebung
Die Auswahl von JADE zieht einige Konsequenzen nach sich. So wird als Entwicklungsumgebung und Runtimeplattform Java in der aktuellen Version 1.6 gewählt. Als
125
Entwicklungsumgebung ist somit das Java Development Kit (JDK6) zu benutzen.
Build-System
Als Build- und Deployment- System wird Ant genutzt, da es im Gegensatz zu seinem
Konkurrenten Maven fest in die für Java in Frage kommenden, integrierten Entwicklungsumgebungen (IDEs) integriert ist. Der Einsatz von Ant bedeutet somit keinen
zusätzlichen Aufwand.
Testumgebung
JUnit ist das wohl bekannteste Test-Framework für Java. Die Entscheidung für dieses
Test-Framework resultiert vor allem aus der Tatsache, dass für die Entwicklung der
Jinengo-Software das Vorgehen einer testgetriebenen Entwicklung angestrebt wird. JUnit
bietet eine volle Unterstützung für ein solches Vorgehensmodell. Weiterhin ist JUnit
standardmäßig in den meisten integrierten Entwicklungsumgebungen für Java installiert.
Somit fallen bei der Nutzung von JUnit keine zusätzlichen Belastungen, zum Beispiel für
das Einrichten der Testumgebung, an. Als letztes Argument lässt sich die Bekanntheit
des Testframeworks innerhalb des Projektteams nennen. Da fast jedes Teammitglied
bereits praktisch mit JUnit gearbeitet hat, ist bei dem Einsatz dieses Testframeworks
kein zusätzlicher Lernaufwand zu erwarten.
Web Services
Da der Server über eine Web Services Schnittstelle verfügen soll, muss auch hierfür ein geeignetes Framework gefunden und bewertet werden. Da das Paket javax.jws.WebService
schon in dem JDK6 enthalten ist, ist die Benutzung des Pakets zu favorisieren. Auf diese
Art und Weise wird eine Überladung durch zusätzlich eingebundene Bibliotheken verhindert. Es ist zu beachten, dass sich alle genutzten Funktionen zum Verfassungszeitpunktes
dieses Dokuments ebenfalls im Umfang des OpenJDK finden lasse.
Datenbank
Zur persistenten Speicherung von Nutzerdaten soll hauptsächlich ein CRM-System eingesetzt werden. Aus diesem Grund müssen nur wenige Anwendungsdaten vom System
in einer zusätzlichen Datenbank gespeichert werden. Zu diesen Daten gehören zunächst
nur die Stammdaten eines Jinengo-Nutzers. Diese beinhalten die E-Mailadresse, ein Passwort, die Rolle (Kunde, Administrator oder Agent-Entwickler) sowie einen Schlüssel, der
126
7.2. Client
den Nutzer in dem jeweiligen CRM-System identifiziert.
Weiterhin werden in dieser Datenbank Informationen über Agenten, sogenannte AgentInfos abgelegt. Diese beinhalten die Daten, wie den Agententyp, den Agentenquelltext,
den Ersteller des Agenten, sowie ein Erstellungsdatum und weitere Metadaten über die
Agenten, die von der Hatchery und dem MessagingModule genutzt werden, um Agenten
dynamisch zur Laufzeit in das Jinengo-System zu integrieren.
Da also nur wenige Daten in einer zusätzlichen Datenbank hinterlegt werden müssen,
bestehen keine besonderen technischen Anforderungen an das einzusetzende DBMS.
Auf Grund der einfachen Installation und der komfortablen Administrationsoberfläche
fiel die Wahl auf den MySQL-Server. Da vom Hersteller auch eine Bibliothek zur Einbindung einer MySQL-Datenbank in eine Java-Anwendung zur Verfügung gestellt wird,
ist zusätzlich der Aufwand bei der Verwendung dieses Systems nur sehr gering.
CRM-System
CRM-System wird im Jinengo-Projekt als Operativer Datenspeicher verwendet, in dem
alle nötigen Informationen und relevante Daten von Kunden sowie die Wege und Verkehrmitteln gespeichert sind. Diese ermöglicht auf der CRM eine Auswertung und Darstellung
von verschiedenen Kennzahl zu ermittelt. Die Füllung von CRM-System erfolgt durch
eine generische definierte Anbindung an Jinengo. Dafür wurde die Klassen CrmAdapter
(Abschnitt 9.1.5) und CrmProperty (Abschnitt 9.1.5)erstellt.
Hierbei dient CrmAdapter als abstrakte Basisklasse, die die notwendigen Methoden zur
Interaktion mit einem CRM-System definiert. CrmProperty beschreibt eine Eigenschaft
eines Objekts, das im CRM-System abgebildet werden muss.
Für Jinengo wurde ein DynamicsAdapter entwickelt, der eine konkrete Implementierung
eines CrmAdapters darstellt und die Verbindung zu einem Microsoft Dynamics 2011
Online CRM-System herstellt.
7.2. Client
Die Zielsysteme der Anwender sind primär mobile Endgeräte. Dies bedeutet, dass die Anwendung mit höchst unterschiedlich leistungsfähigen Endgeräten arbeiten können muss.
Im Gegensatz zum PC-Markt existieren keine marktbeherrschenden Betriebssysteme,
was zur Folge hat, dass unterschiedlichste Plattformen betrachtet werden müssen.
Mobile Endgeräte weisen gegenüber handelsüblichen PC wesentliche Einschränkungen
127
auf. Die Bildschirmauflösungen sind geringer, sie verfügen über geringere Rechenleistung
und Programme müssen auf die Mobilität im Sinne des Energieverbrauchs Rücksicht
nehmen.
Auf mobilen Endgeräten ist der Einsatz spezialisierter Anwendungen, sogenannter Apps,
sehr verbreitet. Dieses Vorgehen erlaubt es, die individuelle Leistungsfähigkeit eines Endgeräts in optimierter Weise zu nutzen. Als Nachteil ist aus Projektsicht zu sehen, dass
eine Vielzahl dieser Anwendungen geschrieben werden müssten, um einen signifikanten
Teil des Markts abzudecken. Zugleich sind einige Plattformen mit Zugangsbeschränkungen verbunden, so dass die Umsetzung erschwert wird.
Aus diesem Grunde wird als primäres Ausgabesystem eine Web-Applikation verwendet,
die auf die Bedürfnisse mobiler Endgeräte hin optimiert ist. Ziel ist es, möglichst geringen Ressourcenbedarf auf Seiten des Endgeräts zu realisieren und die Einschränkungen
und Aufwendungen durch verschiedenste Endgerätetypen zu umgehen. Im Folgenden
wird auf die Web-Applikation, dass Web-Frontend, im Detail eingegangen.
7.2.1. Design des Frontends
Das folgend dargestellte Komponentenmodell stellt die logische Gliederung des Frontends
dar. Wesentliches Detail ist die Unterteilung in Formular (Screen) und Benutzerelement
(Control). Die zugrundeliegende Logik inklusive der Validierung von Nutzereingaben
erfolgt im Formular. Die geprüften Daten lösen dann eine folgende Aktion über die
Schnittstelle (JinengoService) aus. Das Formular hat aber entgegen dem üblichen Vorgehen keine Kontrollelemente für Nutzerinteraktionen implementiert.
Sämtliche Darstellungselemente sind im Benutzerelement eingebettet. Das Benutzerelement kommuniziert über das Formular–es existiert keine direkte Kommunikation zu
weiteren Diensten. Die öffentlich verfügbaren Methoden und Attribute des Formulars
können vom Element genutzt werden. Das Benutzerelement kann frei bezüglich der Informationensdarstellung entwickelt werden. Es ist dann valide, wenn das Validationssystem des Formulars die Eingaben akzeptiert. Auf diese Weise ist bei der Entwicklung
neuer Nutzeroberflächen eine hohe Flexibilität ohne Gefährdung der Stabilität gegeben.
Benutzerelemente können dynamisch in ein Formular geladen werden. Dies erlaubt es,
dass während der Laufzeit unterschiedliche Darstellungen realisiert werden können.
128
7.2. Client
Abbildung 7.22.: Frontend Komponentenmodell
129
Design des Frontends
Formulare
Home Das Formular Home wird als Ausgangsbildschirm für einen angemeldeten Anwender genutzt. Von hier aus lassen sich die weiteren Formulare erreichen.
Abbildung 7.23.: Formular Home
LogIn Das Formular Log–In bietet die Funktionalitäten zur Anmeldung sowie eine Weiterleitung zum Registrierungs-Formular für neue Anwender.
Registrierung Das Formular Registrierung ist ein Unterformular das Log–Ins. Neue
Anwender können sich hier für den Dienst registrieren.
Nutzer–Präferenzen Das Formular Nutzer–Präferenzen erlaubt es dem Anwender,
grundlegende Einstellungen zu seinen Reiseplanungen zu treffen. Hier können bevorzugte
Verkehrsmittel, die Kosten oder persönliche Vorlieben registriert werden.
Startbildschirm Das Formular Startbildschirm wird aufgerufen, wenn ein Anwender
die Nutzung von Jinengo beginnt. Dieses Formular wird auch dann angezeigt, wenn
130
7.2. Client
Abbildung 7.24.: Formular LogIn
aufgrund von Inaktivität der Anwender vom Server abgemeldet wurde.
Routenplanung Das Formular Routenplanung dient zur Planung einer neuen Reise.
Start- und Ziel werden angegeben und die Informationen aus den persönlichen Präferenzen
genutzt, eine individuelle Planung zu realisieren.
Routenergebnisse Das Formular Routenergebnisse listet die gefundenen Reisealternativen auf.
Route–Bewertung Das Formular Routen–Bewertung dienst dem Anwender dazu, eine
persönliche Bewertung der vorgeschlagenen Route durchzuführen.
Routen ohne Bewertung Das Formular Routen ohne Bewertung listet dem Anwender
alle Reisen auf, die er bisher noch nicht bewertet hat.
131
Abbildung 7.25.: Formular Registrierung
Nutzerpräferenzen
Impressum Das Formular Impressum stellt die die Informationen über den Dienstanbieter bereit.
Allgemeine Geschäftsbedingungen Das Formular Allgemeine Geschäftsbedingungen
zeigt abhängig vom Ort des Aufrufs die lokalisierten Nutzungsbedingungen an.
Information Das Formular Information stellt allgemeine Daten über die Plattform
Jinengo bereit. In dieser Version sind die Daten auf den Endnutzer bezogen
132
7.2. Client
Abbildung 7.26.: Formular Nutzer–Präferenzen
133
Abbildung 7.27.: Formular Startbildschirm
134
7.2. Client
Abbildung 7.28.: Formular Routenplanung
Abbildung 7.29.: Formular Routenergebnisse
135
Abbildung 7.30.: Formular Route–Bewertung
Abbildung 7.31.: Formular Routen ohne Bewertung
136
7.2. Client
Abbildung 7.32.: Formular Nutzerpräferenzen
Abbildung 7.33.: Formular impressun
137
Abbildung 7.34.: Formular Allgemeine Geschäftsbedingungen
Abbildung 7.35.: Formular Information
138
7.2. Client
Benutzerdefinierte Darstellungskomponenten
Abbildung 7.36.: Benutzerelement Home
139
Abbildung 7.37.: Benutzerelement Log–In
Abbildung 7.38.: Benutzerelement Registrierung
140
7.2. Client
Abbildung 7.39.: Benutzerelement Benutzerinformation ändern
Abbildung 7.40.: Benutzerelement Startbildschirm
141
Abbildung 7.41.: Benutzerelement Routenplanung
Abbildung 7.42.: Benutzerelement Routenbewertung
142
7.2. Client
Abbildung 7.43.: Benutzerelement unbewertete Routen
Abbildung 7.44.: Benutzerelement Nutzerpräferenzen
143
Abbildung 7.45.: Benutzerelement Impressum
Abbildung 7.46.: Benutzerelement Information
144
7.2. Client
Datenschnittstelle
145
146
7.2. Client
Abbildung 7.48.: Agent Information
Abbildung 7.49.: Behaviour Information
147
Abbildung 7.50.: Matchmaker Information
Abbildung 7.51.: Subrouten–Objekt
148
7.2. Client
Abbildung 7.52.: User Information
149
Hilfsklassen
Abbildung 7.53.: Hilfklasse Validierung
150
7.2. Client
Abbildung 7.54.: Hilfsklasse Log
151
7.2.2. Funktionsumfang des Frontends
Das Frontend ist eine umfangreiche Web-Applikation. Das Frontend richtet sich an Endbenutzer, welche mit Jinengo (nachhaltige) Routenplanungen vornehmen wollen. Dazu
gehören sowohl grundlegende Funktionen wie Registrierung und Anmeldung als auch die
Möglichkeit der Routenbewertung. Im Folgenden werden alle Funktionen des Frontends
im Detail dargestellt.
Benutzer Registrierung: Der Endanwender hat die Möglichkeit, sich einen Account
zu registrieren. Hierfür benötigt er eine E-Mail Adresse, welche gleichzeitig den Benutzernamen darstellt und ein Passwort, welches aus mindestens sechs Zeichen bestehen
muss. Zusätzlich muss er noch die AGBs von Jinengo akzeptieren. Abbildung 7.55 zeigt
einen Screenshot dieser Maske.
Benutzer Login: Sofern der Benutzer einen Account hat kann er sich über seine E-Mail
und sein zugehöriges Passwort an dem System anmelden. Bei einem erfolgreichen Login
erhält der Benutzer eine Session, mit dem der Nutzer identifiziert wird und bis zum
Schließen des Browserfenster eingeloggt bleibt. Abbildung 7.56 zeigt einen Screenshot
dieser Maske.
Menü: Nachdem der Benutzer sich eingeloggt hat erscheint das Menü, welches dem
Nutzer verschiedene Funktionen von Jinengo bietet. Dieses Hauptmenü kann jederzeit
wieder durch einen Klick auf den Jinengo-Schriftzug in der Titelleiste erreicht werden.
Folgende Menüpunkte werden geboten:
Routenplanung
Einstellungen
Präferenzen
Reisen bewerten
Über Jinengo
Ausloggen
Abbildung 7.57 zeigt einen Screenshot dieser Maske.
Routenplanung: Die Hauptfunktionalität der Anwendung wird durch die Routenplanung abgedeckt. Hier bekommt der Benutzer die Möglichkeit durch Angabe von Start
und Zielpunkt eine Vielzahl von Routenvorschlägen geliefert zu bekommen. Bei der Eingabe von Start und Zielpunkt werden folgende Parameter verstanden:
Straße und Hausnummer
152
7.2. Client
Haltestelle
PLZ
Ort
Land
CMA: Was heißt verstanden? Bitte gucken ob das vollständig ist
(z.B. Haltestelle geht doch auch?) DONE
Um eine Route zu planen ist mindestens eine von den oben genannten Parametern nötig.
Nach absenden der Informationen werden mittels Agenten Routen berechnet. Die Ergebnismenge kann je nach Anzahl und Art der eingesetzten Agenten variieren. Weiterhin
werden die Ergebnisse anhand von eingestellten Präferenzen unterschiedlich dargestellt.
Dieses wird nachfolgend im Punkt Adaptives Verhalten des Frontends näher erläutert.
Eine Route besteht immer aus einer oder mehreren Subrouten. Jede Subroute hat dabei
folgende Eigenschaften:
Startpunkt / Startdatum / Startzeit
Endpunkt / Enddatum / Endzeit
Verkehrsmittel
Entfernung
Dauer
CO2 -Emission
Kosten
Typischerweise erfolgt in der Ausgabe eine Zusammenfassung der Subrouten zu einer
Gesamtroute. Abbildung 7.58 zeigt die Ergebnismaske einer solchen Routenplanung.
153
Einstellungen: Die Einstellungen Seite erlaubt es dem Benutzer-Account-spezifische
Einstellungen vorzunehmen. Ein Beispiel hierfür ist das ändern der aktuellen E-MailAdresse.
Präferenzen: Hier kann der Benutzer folgende Präferenzen einstellen:
Nachhaltigkeit
Distanz
Kosten
Time
Sub-Routen
Transportmittel
Hier kann der Benutzer für Präferenz einen Wert von 0-15 vergeben. Die 0 drückt aus,
dass die Präferenz dem Benutzer sehr unwichtig ist. Mit steigenden Werten drückt der
Benutzer ein gesteigertes Interesse an der jeweiligen Präferenz aus. Diese Präferenzen
werden herangezogen um das Frontend für den Benutzer adaptiv zu gestalten. Dies wird
nachfolgend im Punkt adaptives Verhalten des Frontends genauer beschrieben. Die Parameter Nachhaltigkeit, Distanz, Kosten und Zeit dürfen zusammen nicht die Summe
30 übersteigen. Dies dient dazu, dass der Anwender einen Schwerpunkt setzt und nicht
alle Präferenzen auf das Maximum von 15 setzt. Diese Präferenzen werden durch die Benutzung von Jinengo beeinflusst und automatisch abgeändert um die Anwendung besser
an das Nutzungsverhalten des Anwenders anzupassen. Die Präferenzen Sub-Routen und
Transportmittel nehmen eine Sonderstellung ein und sind deshalb separat dargestellt.
Sie unterliegen nicht der automatischen Anpassung. Subrouten meint hierbei die Information der Anzahl der Umstiege einer Route. Abbildung 7.59 zeigt einen Screenshot
dieser Maske.
CMA: Gab es keine Regel insgesamt nicht mehr als XX Punkte? Was
bedeutet die Präferenz Sub-Route, was bedeutet Transportmittel?
DONE
154
7.2. Client
Über Jinengo: Hier werden allgemeine Informationen über Jinengo angezeigt. Diese
Seite kann der Benutzer auch betrachten, wenn er noch keinen Account hat oder nicht
eingeloggt ist. Weiterhin ist ein Verweis auf das Impressum vorhanden.
Logout: Bei dem betätigen dieses Punktes wird der Benutzer ausgeloggt und gelangt
auf die Startseite, wo er unter anderem wieder die Möglichkeit hat, sich einzuloggen.
Wird das Browser-Fenster geschlossen, erfolgt ebenfalls ein Logout.
7.2.3. Eingesetzte Technologien
Das Frontend wird in der Entwicklungsumgebung von Microsoft Visual Studio unter Verwendung der Technologien ASP.NET in Kombination mit C# entwickelt. Die Hostumgebung ist hierbei ein Microsoft Server mit der Diensteplattform Internet Information
Services (IIS). Über einen Webservice besteht die Möglichkeit der Kommunikation mit
dem Backend. Vorteil ist hierbei, dass Frontend und Backend in verschiedenen Sprachen
auf verschiedenen Plattformen betrieben werden können. So ist im Falle von Jinengo
das Backend in JAVA umgesetzt. Der Webservice stellt sodann diverse Methoden zur
Verfügung, denen sich das Frontend bedienen kann. Um die Webseite interaktiver zu
gestalten, wird JavaScript bzw. AJAX eingesetzt. Ein Beispiel hierfür ist das Senden
und Empfangen von Daten, ohne dass der Browser die Seite neu laden muss. Zum Gestalten des Designs und Layouts wird auf CSS zurückgegriffen. Gekapselte CSS-Dateien
erlauben es, das gesamte Design leicht austauschbar zu gestalten. Insbesondere wird
das Layout durch ein angepasstes 960-Grid-System verwaltet. Dieses hat sich schon auf
diversen Webseiten profiliert.
7.2.4. Adaptives Verhalten des Frontends
Das Webfrontend bietet die Möglichkeit, eine dem Benutzer angepasste Darstellung bereitzustellen. Dabei erfolgt die Anpassung der Darstellung vollautomatisch anhand der
angegeben Präferenzen. Grundgedanke der adaptiven Darstellung ist, dass die Darstellung verschiedener Seiten und Inhalte dem Benutzer entsprechend seiner Präferenzen
aufbereitet werden. Durch eine angepasste Darstellung findet der Benutzer sich leichter zurecht. Das System bietet die technische Möglichkeit, die Präferenzen auf Basis
des Benutzerverhaltens intern zu verändern. Ein Beispiel hierfür wäre, wenn der Benutzer regelmäßig auf nachhaltige Routen klickt und das System automatisch die Priorität
Nachhaltigkeit erhöht. Die Folge dessen wäre, dass die Nachhaltigkeit z.B. weiter vorne
oder in einem anderen Schriftgrad angezeigt werden würde.
155
7.2.5. Design
Beim Design wurde darauf geachtet, die Corporate Identity von Jingneo zu übernehmen.
Dies spiegelt sich insbesondere in verwendeten Farben und Formen wider.
7.3. Allgemeine Werkzeuge
ALL: Hier gehören doch noch mehr Werkzeuge hin?!? Oder gehört
das nicht zu den Client- /Serverseitigen Tools aus Kapitel 2/3?
7.3.1. Versionskontrollsystem
Als Versionskontrollsystem wird Subversion genutzt, da die Projektgruppenmitglieder
die meiste Erfahrung mit diesem Werkzeug haben. Außerdem lässt es sich nahtlos in
verschiedene IDEs zur Entwicklung von Java Anwendungen integrieren, so dass der Entwicklungsprozess durch den Einsatz des Versionskontrollsystems nur minimal beeinflusst
wird. Als weiteres Argument für Subversion ist der Einsatz von vorhandenen Schnittstellen zur Benutzung von anderen Versionskontrollsystemen. Subversion bietet eine Reihe
von Schnittstellen zur Integration von beispielsweise Git oder Mercurial, welche genutzt
werden können falls Projektgruppenmitglieder eine alternatives Frontend bevorzugen.
7.3.2. Integrierte Entwicklungsumgebung
Java Entwicklung
Bei der Java Entwicklung wird Eclipse benutzt, das ein quelloffenes Programmierwerkzeug zur Entwicklung von Software verschiedenster Art ist. Ursprünglich wurde Eclipse
als integrierte Entwicklungsumgebung für die Programmiersprache Java genutzt, aber
mittlerweile wird es aufgrund seiner Erweiterbarkeit auch für viele andere Entwicklungsaufgaben eingesetzt. Für Eclipse gibt es eine Vielzahl von Erweiterungen sowohl quelloffen als auch von kommerziellen Anbietern. Eclipse selbst basiert auf Java-Technik, seit
Version 3.0 auf einem so genannten OSGi-Framework namens Equinox.
ASP.NET Entwicklung
Microsoft Visual Stuido 2010 wird für die Entwicklung der Graphical User Interfaces
(GUIs) auf Basis des .NET Frameworks genutzt. Die dynamischen Inhalte der GUIs
156
werden über Webservices bezogen.
Business Intelligence
SQL Server Business Intelligence Studio benötigt Microsoft Visual Studio 2008, um ausgeführt zu werden. Aus diesem Grund ist neben der aktuellen Microsoft Visual Stuido
2010 Version auch die 2008 Version unabdingbar und wird zur Query-Erstellung aufsetzend auf dem Data Warehouse genutzt.
MySQL Datenbanken
Die Administration der MySQL Datenbanken erfolgt über das in Hypertext Preprocessor (PHP) geschriebene Administrationstool phpMyAdmin. Es unterstützt eine Vielzahl
häufig genutzter Nutzeroperationen, wie beispielsweise die Verwaltung von Datenbanken, Tabellen, Feldern, Beziehungen, Indizes, Nutzern, Berechtigungen, etc. Weiterhin
existieren zu diesem Werkzeug multilinguale Online-Dokumentationen, die sehr umfangreich sind und stetig gepflegt werden.
SQL Datenbanken
Die integrierte Umgebung SQL Server Management Studio ermöglicht das Zugreifen,
Konfigurieren, Verwalten und Entwickeln aller Komponenten von Microsoft SQL Server.
SQL Server Management Studio kombiniert eine umfassende Gruppe an grafischen Tools
mit einer Reihe von funktionsreichen Skript-Editoren, um Entwicklern und Administratoren mit unterschiedlichen Fähigkeiten Zugriff auf SQL Server zu ermöglichen.
SQL Server Management Studio kombiniert die Funktionen von SQL Server Enterprise
Manager, Query Analyzer und dem Analysis-Manager aus den vorherigen Versionen von
SQL Server in einer einzigen Umgebung. Darüber hinaus kann SQL Server Management
Studio mit allen Komponenten von SQL Server verwendet werden, z. B. Reporting Services, Integration Services und SQL Server Compact 3.5 SP2.
7.3.3. Ontologien
Zur Erstellung, Visualisierung und Manipulierung von Ontologien wird der in Java geschriebene Ontologie Editor Protege der Stanford University verwendet. Das Werkezug
157
kann dahin gehend angepasst werden, dass es domain-freundliche Unterstützung leistet
für die Erstellung von Wissensmodellen und Dateneingaben. Eine Ontologie beschreibt
durch ein gegebenes Vokabular das Konzept und die Beziehungen, welche innerhalb einer
bestimmten Domain von Bedeutung sind. Die Spannweite einer Ontologie kann sich hierbei von Taxonomien und Klassifikationen, über Datenbank Schemata, bis hin zu völlig
unanzweifelbaren Theorien erstrecken.
158
Abbildung 7.55.: Benutzer Registrieren
159
Abbildung 7.56.: Benutzer Login
160
Abbildung 7.57.: Hauptmenü
161
Abbildung 7.58.: Ergebnis der Routenplanung
162
Abbildung 7.59.: Präferenzen
163
8. Benutzerklassen
Im Folgenden soll die Unterscheidung der verschiedenen Benutzer der Anwendung näher
erläutert werden. Im Kontext des Systems gibt es vier verschiedene Gruppen von Nutzern, welche sich maßgeblich durch ihr Handeln im System unterscheiden. Neben der
wichtigsten Gruppe — den Endnutzern — gibt es zunächst die systeminternen Administratoren, welche für die korrekte Ausführung der Plattform sorgen.
Darüberhinaus gibt es Agent Assembler und Behaviour Developer, welche in Kooperation
neue Agentenverhalten in das System einspeisen können.
8.1. Endnutzer
Diese Benutzergruppe stellt die Benutzer dar, welche die Anwendung nutzen. Hierzu gehören Kunden im klassischen Sinne, welche die Anwendung benutzen, um eine
Reiseplanung durchzuführen, welche an ihre persönlichen Wünsche und individuellen
Präferenzen angepasst ist. Die Endnutzer sind die zentrale Zielgruppe der Anwendung.
8.2. Administrator
Die Administratorengruppe bezeichnet die internen Nutzer, die über übergeordnete
Rechte verfügen und somit entscheidende Änderungen am System durchführen können.
Die Benutzerklasse der Administratoren hat die meisten Privilegien im Anwendungskontext und sorgt für die Konfiguration der Plattform. Es ist ihre Aufgabe, dafür zu sorgen,
dass das System in einem sicheren und lauffähigen Zustand bleibt.
8.3. Agent Assembler
Die Agent Assembler sind Benutzer, welche aus der vorhandenen Auswahl von Verhaltensmustern für Agenten neue Kombinationen bilden. Diese Aufgabe soll später automatisiert von einem Algorithmus übernommen werden. Auch diese Nutzergruppe wird
165
8. Benutzerklassen
über eine grafische Nutzeroberfläche mit der Plattform in Berührung kommen, so dass
der Prozess der Erzeugung neuer Verhaltenskombinationen schnell und kompakt effizient
werden kann.
Weiterhin können Agent Assembler auch Messaging Provider für das Jinengo MessagingModule hinzufügen so dass zur Laufzeit dynamisch Nachrichten des Agent Assemblers,
bzw. der Organisation, die der jeweilige Agent Assembler vertritt im Jinengo Frontend
angezeigt werden können.
8.4. Behaviour Developer
Bei der Anwendergruppe der Behaviour Developer handelt es sich um Benutzer, die
neue Verhaltensmuster für Agenten erstellen, um die Vielfalt der einsetzbaren Agenten
im System zu erhöhen. Für diese Nutzergruppe wird eine grafische Benutzerschnittstelle
zur Verfügung gestellt, so dass neue Verhaltensmuster schnell und einfach an das System
übermittelt werden können.
166
9. Klassendiagramme
9.1. UserModel module
Die folgenden Abschnitte beschreiben die Klassen des UserModel Module. Dieses Modul
verwaltet die verschiedenen Nutzer und Nutzergruppen und stellt eine Persistenzschicht
durch Einsatz einer Datenbank, bzw. Anbindung eines CRM-Systems zur Verfügung.
9.1.1. Administrator
Spezialisierung eines Users. Repräsentiert einen Jinengo-Administrator. Die Attribute
dieser Klasse werden in Tabelle 9.1 dargestellt.
9.1.2. AgentAssembler
Spezialisierung eines Users. Repräsentiert einen Agenten Assembler. Die Attribute dieser
Klasse werden in Tabelle 9.2 dargestellt.
9.1.3. BehaviourDeveloper
Spezialisierung eines Users. Repräsentiert einen Behaviour Developer. Die Attribute dieser Klasse werden in Tabelle 9.3 dargestellt.
Attribute
Eindeutige Identifikationsnummer zur Serialisierung
Tabelle 9.1.: Klasse Administrator
167
9. Klassendiagramme
Attribute
Tabelle 9.2.: Klasse AgentAssembler
Attribute
Tabelle 9.3.: Klasse BehaviourDeveloper
9.1.4. CrmAdapter
Abstrakte Basisklasse, die alle Eigenschaften eines Users definiert, die im CRM-System
gespeichert werden müssen. Konkrete Implementierungen, die von dieser Klasse ableiten,
müssen alle Jinengo Eigenschaften abbilden. Die Attribute und Methoden dieser Klasse
werden in Tabelle 9.4 dargestellt.
9.1.5. CrmProperty
CrmProperty stellt eine Eigenschaft eines Customer-Objekts dar, die im angebundenen
CRM-System gespeichert wird. Ein CrmProperty repräsentiert eine Eigenschaft, wie
sie in Jinengo definiert ist. Das konkrete Mapping auf eine Eigenschaft im CRM-System
findet in der konkreten Implementierung des jeweiligen CrmAdapters statt. Die Attribute
9.1.6. Customer
Spezialisierung eines Users. Stellt einen Endanwender von Jinengo dar. Die Attribute
9.1.7. DynamicsAdapter
Konkrete Implementierung eines CrmAdapters zur Anbindung an ein Microsoft Dynamics 2011 Online CRM-System.
168
9.1. UserModel module
Attribute
Property : enum
properties : ArrayList<CrmProperty>
customer : Customer
Methoden
CrmAdapter (Customer customer)
addCustomer() : void
deleteCustomer() : void
GetCustomer() : Customer
getCustomerProperty (String propertyName) : Object
lookupCrmProperty (String propertyName) : CrmProperty
setCustomerProperty (String propertyName, Object propertyValue) : void
Definiert verfügbare Nutzer Properties in
einer Enumeration.
Eine Liste, die alle zu implementierenden
CRM-Properties enthält.
Dieses Attribut binhaltet das Customer
Objekt.
Initialisiert ein CrmAdapter-Objekt und
verknüpft den CrmAdapter mit dem gegebenen Customer-Objekt.
Erzeugt das Customer-Objekt des CRMAdapters im CRM-System.
Entfernt das Customer-Objekt des CRMAdapters aus dem CRM-System.
Liefert das aktuelle Customer Objekt.
Gibt den Wert einer CrmProperty eines
konreten Customers zurück.
Sucht eine CrmProperty nach Name und
gibt sie zurück.
Speichert einen neuen Wert einer CrmProperty eines Customers.
Tabelle 9.4.: Klasse CrmAdapter
Attribute
name : String
type : String
Name der Eigenschaft in Jinengo.
Datentyp der Eigenschaft.
Tabelle 9.5.: Klasse CrmProperty
Attribute
crmID : String
crmAdapter : CrmAdapter
ID, über die ein Customer im CRMSystem identifiziert wird.
Ein konkretes CrmAdapter-Objekt, über
das das Customer-Objekt persistiert
wird.
Tabelle 9.6.: Klasse Customer
169
9. Klassendiagramme
Attribute
userID : UUID
mail : String
password : String
hashedPassword : String
salt : String
registered : long
Methoden
User()
save() : void
Eindeutiger Identifikator eines UserObjekts.
eMail-Adresse eines User-Objekts.
Klartext-Kennwort eines User-Objekts.
Kennwort-Hashwert eines User-Objekts.
Kennwort-Salt. Wird vor dem Hashen an
das Kennwort angehängt.
Registrierungsdatum eines Users.
Initialisiert ein User-Objekt.
Persistiert den Zustand eines
Objekts.
User-
Tabelle 9.7.: Klasse User
9.1.8. MySqlConnector
Diese Klasse verwaltet die Verbindungen zur Datenbank.
9.1.9. User
Repräsentation eines Users in Jinengo. Basisklasse für die verschiedenen Rollen Endanwender, Behaviour Developer und Agent Assembler. Die Attribute und Methoden dieser
9.1.10. UserManager
Singleton Managerklasse, die alle User von Jinengo verwaltet. Die Attribute und Methoden dieser Klasse werden in Tabelle 9.8 dargestellt.
9.2. AdaptationEngine
9.2.1. AdaptationManager
Der AdaptationManager übernimmt die Funktion einer Fassade und ist als singleton
realisiert. Die Attribute und Methoden dieser Klasse werden in Tabelle 9.9 dargestellt.
170
Attribute
instance : UserManager
mySql : MySqlConnector
users : ArrayList<User>
Methoden
UserManager()
Instanzvariable des UserManagers.
MySqlConnector Objekt.
Liste aller Jinengo-User.
getInstance() : UserManager
setup() : void
loginUser (user : User) : UUID
logoutUser (user : User) : void
registerUser (user : User) : void
deleteUser (user : User) : void
lookupUser (token : UUID) : User
lookupUser (mail : String) : User
updateUserMail(User user, String newMail) : void
Konstruktor der Klasse UserManager, der
die Liste aller Jinengo-User sowie den
MySqlConnector initialisiert.
Gibt die Instanz des UserManagers
zurück.
Initialisiert den Agenten.
Loggt das gegebene User-Objekt in Jinengo ein und gibt eine SecurityToken
zurück.
Loggt das gegebene User-Objekt aus Jinengo aus.
Registriert ein neues User-Objekt.
Entfernt ein gegebenes User-Objekt.
Sucht einen User anhand eines SecurityTokens und gibt diesen zurück.
Sucht einen User anhand einer eMailAdresse und gibt diesen zurück.
Aktualisiert die E-Mail Adresse eines
Nutzers.
Tabelle 9.8.: Klasse UserManager
171
9. Klassendiagramme
Attribute
instance : AdaptationManager
Instance hält die aktuelle Instanz des AdaptationManagers.
Eine Liste mit Instanzen von konkreten
Implementierung eines MatchMaker. Diese werden benutzt um die eigentliche adaptive Routenabfrage auszuführen.
matchMakers : ArrayList<MatchMaker>
Methoden
AdaptationManager()
getInstance() : AdaptationManager
setup() : void
matchRoute(customer : Customer, start :
TravelSituation, end : TravelSituation) :
ArrayList<Route>
chooseBestSuitableAgent(customer : Customer) : String
voteLastMatchMaker(customer : Customer, positive : boolean)
compareInterestAndVoting(interest
double[], voting : double[]) : double
:
Das ist der default Konstruktur. Da es
sich um eine singleton Implementierung
handelt, ist der Kontstruktur private.
Gibt eine Instanz der Klasse AdaptationManager wieder. Falls die Variable instance noch keine Instanz der Klasse enthält,
wird diese erzeugt.
Override der setup() von Agents.
Die matchRoute Methode entscheidet im
Wesentlichen anhand der Parameter welcher MatchMaker aus matcherMakers zur
Routenabfrage genutzt wird.
Diese Methode wählt anhand der Bewertung eines Agenten und den Präferenzen
eines Nutzers den Agenten aus, welcher
am besten zum dem customer passt. Der
identifizierende Name des Agenten wird
dann als String zurückgegeben.
Die Methode voteLastMatchMaker wird
genutzt um eine Bewertung zu dem
MatchMaker-Agenten abzugeben, welcher als letztes vom customer genutzt
wurde. Der bool’sche Parameter positive
entscheidet darüber hinaus, ob die Bewertung positiv oder negativ ausfällt.
Diese Methode vergleicht die Präferenzen
eines Customers mit der Bewertung eines
Agenten. Zurückgegeben wird der Unterschied zwischen den Werten der Arrays
als double.
Tabelle 9.9.: Klasse AdaptationManager
172
9.2.2. MatchMaker
MatchMaker ist eine abstrakte Klasse, die Basislogik enthält und definiert, was konkrete Implementierungen eines MatchMakers enthalten müssen, damit eine Routenabfrage
ausgeführt werden kann. Die Attribute und Methoden dieser Klasse werden in Tabelle
9.10 dargestellt.
9.2.3. IMatchMaker
IMatchMaker ist ein Interface, welches die Methoden zusammenfasst, welche von dem
Entwickler eines Agenten selbst noch überschrieben werden müssen. Die zu überschreibenden
Methoden dieser Klasse werden in Tabelle 9.11 dargestellt.
9.2.4. SustainableMatchMaker
SustainableMatchMaker ist eine konkrete Implementierung vom MatchMaker und berücksichtigt den Faktor der Nachhaltigkeit. Die Attribute und Methoden dieser Klasse werden in Tabelle 9.12 dargestellt. Die Implementierung geht über die Standardimplmentierungen der Beispiel-MatchMaker hinaus, das sie persönliche Präferenzen des
Nutzers mit in ihre Kalkulation einbezieht. Die anderen Beispielimplementierungen der
MatchMaker tun dies nicht.
9.2.5. SampleMatchMaker
SampleMatchMaker ist die denkbar simpelste Implementierung eines MatchMaker Agenten. Die Attribute und Methoden dieser Klasse werden in Tabelle 9.13 dargestellt.
9.2.6. EconomicalMatchMaker
EconomicalMatchMaker ist eine einfache Implementierung eines MatchMaker Agenten,
welche nach wirtschaftlichen Kriterien präferiert. Die Attribute und Methoden dieser
9.2.7. SpeedyMatchMaker
SpeedyMatchMaker ist eine einfache Implementierung eines MatchMaker Agenten, welche nach Kriterien sucht, welche schnelles Reisen ermöglichen. Die Attribute und Me-
173
9. Klassendiagramme
Attribute
—
Methoden
calculateRoutes(customer
:
Customer, start : TravelSituation, end :
TravelSituation, planners : ArrayList<IRoutePlanner>) : ArrayList<Route>
sortByTotalXXX(routes
:
ArrayList<Route>, enumXX : XXXEnum)
: ArrayList<Route>
removeNegativeValues(routes : ArrayList<Route> ) : ArrayList<Route>
removeRouteFromResult(route : Route,
ArrayList<Route> ) : ArrayList<Route>
generateNewSubRoute(start : TravelSituation, destination : TravelSituation, type : TransportationType) : SubRoute
calculateAllTotals(result
:
generatePermutations(customer : Customer, routes : ArrayList<Route> ) ArrayList<Route>
mergeByTotals(leftList
:
ArrayList<Route> , rightList : ArrayList<Route>
, type : TotalType) ArrayList<Route>
sortByTotals(routes : ArrayList<Route> ,
type : TotalType) ArrayList<Route>
setup()
—
Enthält die Logik zur adaptiven Suche
von Routen.
Sortiert die Liste von Routen aufsteigend
nach deren XXX. Nutz den Mergesort Algorithmus zur Sortierung.
Diese Methode entsorgt alle Routen, welche negative Werte aufweisen von der Ergebnisliste und gibt diese zurück.
Diese Methode wird genutzt um eine
bestimmte Route von der Ergebnisliste zu entfernen. Danach wird die Liste
zurückgegeben.
Diese Methode wird zum erzeugen einer
neuen SubRoute genutzt, welche danach
zurückgegeben wird.
Die Methode calculateAllTotals berechnet alle bewertenden Dimensionen von allen Routen der Ergebnisliste.
Diese Methode wird genutzt, um nach
möglichen neuen Routen innerhalb der
Ergebnisliste zu suchen. Diese neuen Routen werden durch Permutationen zwischen bestehenden Routen erzeugt und in
die Ergebnisliste eingefügt.
Diese Methode ist Teil des MergeSortAlgorithmus.
Diese Methode sortiert die Ergebnisliste
nach einem bestimmten TotalType und
gibt sie zurück. Hierzu wird das Verfahren des MergeSort genutzt.
Diese Routine wird bei der Instanzierung
des MatchMakers ausgeführt und meldet
den Agenten im System an.
Tabelle 9.10.: Klasse MatchMaker
174
9.3. ContentRepository
Methoden
selectRoutePlanners()
List<IRoutePlanner>
:
Array-
Durch die Implementierung dieses Methodenkopfes sollen die benötigten IRoutePlanner vom MatchMaker erfragt werden.
additionalChanges(customer : Customer, Diese Methode bietet der implementierenroutes : ArrayList<Route> ) : Array- den Klasse die Möglichkeit die ErgebnislList<Route>
site der Routen nachträglich zu bearbeiten.
findAdditionalMatchingSubRoutes(customerDas Überschreiben dieses Methodenkop: Customer, subRouteToMatch : SubRou- fes soll dazuführen, dass zusätzliche
te, route : Route) : ArrayList<SubRoute> SubRoute-Objekte, welche nicht durch
einen IRoutePlanner definiert worden
sind, gefunden werden können.
sortRoutes(customer : Customer, routes : Eine implemetierende Klasse muss dieArrayList<Route> ) : ArrayList<Route>
se Methode überschreiben, um ein Sortierung der Ergebnisliste durchzuführen,
welche ihrem Kontext gerecht wird.
Tabelle 9.11.: Interface IMatchMaker
thoden dieser Klasse werden in Tabelle 9.15 dargestellt.
9.2.8. ShortestDistanceMatchMaker
ShortestDistanceMatchMaker ist eine einfache Implementierung eines MatchMaker Agenten, welche Routen bevorzugt, bei welchen der Reiseweg möcglichst kurz ist. Die Attribute und Methoden dieser Klasse werden in Tabelle 9.16 dargestellt.
Die folgenden Abschnitte beschreiben die Klassen des ContentRepository-Moduls. Dieses
Modul verwaltet Mobilitätsdienstleistungen in Form von Agenten, welche zum einen inhaltsorientierte und zum anderen kontextorientierte Ausprägungen besitzen. Inhaltsorientierte Agenten bieten Routenplanungen für bestimmte Verkehrsmittel unter Berücksichtigung
der Emissionen, Kosten und Zeit an. Kontextorienterte Agenten binden kontextsensitive Daten an die Routenplanung, wie zum Beispiel Wettervorhersagen, woraufhin beispielsweise bei hoher Niederschlagswahrscheinlichkeit von der Nutzung des Fahrrades
als mögliches Verkehrsmittel abgesehen wird.
Dieses Modul besteht aus vier Sub-Modulen, welche im Folgenden genauer beschrieben
175
9. Klassendiagramme
Attribute
—
Methoden
List<IRoutePlanner>
—
:
Array-
Diese Methode wählt die IRoutePlanners
aus, welche der MatchMaker für seine
Kalkulation benutzen möchte. Diese ergeben sich meist aus dem Kontext des Agenten.
additionalChanges(customer : Customer, Mit dieser Methode hat der Entwickroutes : ArrayList<Route> ) : Array- ler des MatchMakers die Möglichkeit
zusätzliche Änderungen an der ErgebnisList<Route>
liste des Agenten durchzuführen.
findAdditionalMatchingSubRoutes(customerDiese Methode wird genutzt, um weitere
: Customer, subRouteToMatch : SubRou- passende, alternative SubRoute zu einer
te, route : Route) : ArrayList<SubRoute> Route zu finden.
sortRoutes(customer : Customer, routes : Diese Methode übernimmt die Sortierung
der Ergebnisliste anhand von Faktoren,
welche zu dem Kontext des MatchMakers passen. In diesem Fall wird besonders
Nachhaltig sortiert. Das bedeutet, dass
Routen, welche nur geringfügig Schadstoffe emittieren besser bewertet werden als
andere.
Tabelle 9.12.: Klasse SustainableMatchMaker
176
Attribute
—
Methoden
List<IRoutePlanner>
—
:
Array-
Kalkulation benutzen möchte. Diese ergeben sich meist aus dem Kontext des
Agenten. Im Falle des SampleMatchMakers werden die IRoutePlanner der Systems nicht weiter gefiltert.
List<Route>
zusätzliche Änderungen an der Ergebnisliste des Agenten durchzuführen. In
diesem Fall werden keine besonderen
Änderungen durchgeführt.
te, route : Route) : ArrayList<SubRoute> Route zu finden. Auch in dieser Methode
passiert nichts, da es sich um eine simple
Beispielimplementierung handelt.
welche zu dem Kontext des MatchMakers
passen. Die Ergebnisliste wird in diesem
Fall nicht sortiert.
Tabelle 9.13.: Klasse SampleMatchMaker
177
9. Klassendiagramme
Attribute
—
Methoden
List<IRoutePlanner>
—
:
Array-
List<Route>
passen. Die Ergebnisliste wird nach den
anfallenden Kosten der Routen sortiert.
Routen, welche weniger Kosten, werden
bevorzugt.
Tabelle 9.14.: Klasse EconomicalMatchMaker
178
Attribute
—
Methoden
List<IRoutePlanner>
—
:
Array-
List<Route>
passen. In diesem Fall wird die Ergebnisliste nach der anfallenden Reisezeit sortiert. Routen, welche schneller zum Ziel
kommen werden nach oben sortiert.
Tabelle 9.15.: Klasse SpeedyMatchMaker
179
9. Klassendiagramme
Attribute
—
Methoden
List<IRoutePlanner>
—
:
Array-
List<Route>
passen. Die Ergebnisliste wird so sortiert,
dass Routen welche über einen überaus
langen Reiseweg verfügen negativ bewertet werden.
Tabelle 9.16.: Klasse ShortestDistanceMatchMaker
180
werden.
9.3.1. Modul Contentrepository
In diesem Modul liegen zum einen die Klassen, welche die zentrale Verwaltung aller
Contentrepository-Agenten übernehmen. Zum anderen sind hier die Klassen hinterlegt,
die die Informationen zu den von den Agenten geplanten Routen und die Informationen
zu den genutzten Verkehrsmitteln speichern.
Klasse ContentManager
Diese Klasse ist die zentrale Verwaltungsklasse für alle Agenten dieses Moduls. Hier werden Aufgaben wie das Hinzufügen und das Entfernen von Agenten durchgeführt. Auch
die Berechnung der totalen Kosten, Emissionen und der gesamten Distanz einer spezifischen Route wird von dieser Klasse durchgeführt. Die Tabelle 9.17 gibt eine Übersicht
über die Klasse und ihre öffentlichen Methoden.
Klasse Route
Diese Klasse ist die Datenstruktur zum Speichern einer von einem Agenten geplanten
Route. Die Tabelle 9.18 gibt eine Übersicht über die Klasse und ihre öffentlichen Methoden.
Klasse SubRoute
Diese Klasse ist die Datenstruktur zum Speichern einer von einem Agenten geplanten
Subrouten. Die Tabelle 9.19 gibt eine Übersicht über die Klasse und ihre öffentlichen
Methoden.
Klasse TravelSituation
Diese Klasse ist die Datenstruktur zum Speichern des Ortes und des Zeitpunktes einer
Route. Die Tabelle 9.20 gibt eine Übersicht über die Klasse und ihre öffentlichen Methoden.
181
9. Klassendiagramme
Attribute
Diese Klasse besitzt keine öffentlichen Attribute.
Methoden
calculateDefaultTotalCosts(Route route)
: void
calculateDefaultTotalEmissions(Route
route): void
calculateTotalDistance(Route route):void
Diese Methode berechnet Gesamtkosten
einer Route
Diese Methode berechnet Gesamtemissionen einer Route
Diese Methode berechnet die Gesamtdistanz einer Route
calculateTotalTravelTime(Route route) : Diese Methode berechnet die Gesamtreivoid
sezeit einer Route
getAllCostCalculators(TransportationDiese Methode liefert alle registrierten
Type transportationType) : ArrayList
Agenten, welche die Kosten für ein gegebenes Transportmittel berechnen können.
getAllEmissionCalculators(Transportation- Diese Methode liefert alle registrierType transportationType) : ArrayList
ten Agenten, welche die Emissionen für
ein gegebenes Transportmittel berechnen
können.
getDefaultCostCalculator(Transportation- Diese Methode liefert einen StandardType transportationType) : ICostCalcu- agenten welcher die Kosten für einen
lator
gegebenenes Transportmittel berechnen
kann. Der Standardagent ist in der Konfiguration zu bestimmen.
Diese Methode liefert einen StandardgetDefaultEmissionCalculator(TransportationType transportationType) : agenten welcher die Emissionen für einen
gegebenenes Transportmittel berechnen
IEmissionCalculator
kann. Der Standardagent ist in der Konfiguration zu bestimmen.
setup() : void
Diese
Methode
registriert
die
Contentrepository-Agenten.
Tabelle 9.17.: Klasse ContentManager
182
Attribute
subRoutes : ArrayList
Dieses Attribut speichert alle Sub-Routen
dieser Route.
Dieses Attribut speichert die Gesamtemissionen der Route.
Dieses Attribut speichert die Gesamtkosten der Route.
Dieses Attribut speichert die Gesamtdistanz der Route.
Dieses Attribut speichert die Gesamtreisezeit der Route.
totalEmission : float
totalCost : float
totalDistance : float
totalTravelTime : float
Methoden
containsTransportationType(TransportationType
transportationType):
booelan
Diese Methode überprüft, ob die Route
das gegebene Transportmittel enthält.
Tabelle 9.18.: Klasse Route
Attribute
transportation : TransportationType
start : TravelSituation
destination : TravelSituation
emissions : float
costs : float
distance : float
traveltime : float
Dieses Attribut speichert das Verkehrsmittel dieser Subroute.
Dieses Attribut speichert den Startort
und den Startzeitpunkt dieser Subroute.
Dieses Attribut speichert den Zielort und
den Endzeitpunkt dieser Subroute.
Dieses Attribut speichert die Emissionen
der Subroute.
Dieses Attribut speichert die Kosten der
Subroute.
Dieses Attribut speichert die Distanz der
Subroute.
Dieses Attribut speichert die Reisezeit der
Subroute.
Methoden
Diese Klasse besitzt keine öffentlichen
Methoden.
Tabelle 9.19.: Klasse SubRoute
183
9. Klassendiagramme
Attribute
longitude : float
Dieses Attribut speichert die Longitude
eines Ortes.
Dieses Attribut speichert die Latidue eines Ortes.
Dieses Attribut speichert den Ortsnamen.
Dieses Attribut speichert die Emissionen
der Subroute.
Dieses Attribut speichert den Startzeitpunkt.
Dieses Attribut speichert den Endzeitpunkt.
latitude : float
name : String
emissions : float
startTime : float
endTime : float
Methoden
updateGeocodes() : void
isDueSituation() : boolean
isStartSituation() : boolean
Diese Methode sucht die Longitude und
Latiude für einen Ortsnamen.
Diese Methode prüft, ob es sich um den
Endpunkt einer Subroute handelt.
Diese Methode prüft, ob es sich um den
Startpunkt einer Subroute handelt.
Tabelle 9.20.: Klasse TravelSituation
Klasse TransportationType
Diese Klasse ist die Datenstruktur zum Speichern eines Verkehrsmittels. Die Tabelle 9.21
gibt eine Übersicht über die Klasse und ihre öffentlichen Methoden.
9.3.2. Modul ContentProvider
In diesem Modul liegen alle Agenten, welche die Berechnung von Routen und deren
Emissionen und Kosten durchführen.
ContentProvider
Die Klasse ContentProvider erbt von jade.core.Agent und ist eine abstrakte Klasse die als
Chain of Responsibility implementiert ist. Ein konkreter ContentProvider kann konkrete Routenplanungsaufgaben annehmen, wie zum Beispiel DBProvider für die Deutsche
Bahn oder PEVProvider für einen konkreten Public Electronic Vehicle Anbieter. Die
Attribute und Methoden dieser Klasse werden in Tabelle 9.22 dargestellt.
184
Attribute
name : String
Dieses Attribut speichert den Namen eines Verkehrsmittels.
Dieses Attribut speichert die Art der
Energie die das Verkehrsmittel verwendet.
powersource : String
Methoden
Diese Klasse besitzt keine öffentlichen
Methoden
Tabelle 9.21.: Klasse TransportationType
Attribute
transportation : Transportation
Methoden
getTransportationType() : TransportationType
Transportation Objekt, das ein konkretes
Verkehrsmittel beinhaltet
Diese Methode liefert den Namen des Verkehrsmittels
Tabelle 9.22.: Klasse ContentProvider
BikeProvider
Die Klasse BikeProvider implementiert die Interfaces IRoutePlanner, IEmissionCalculator und ICostCalculator und ist eine Spezialisierung der Klasse ContentProvider. Sie
realisiert die Routenplanung für Fahrräder. Die Attribute und Methoden dieser Klasse
werden in Tabelle 9.23 dargestellt.
CarProvider
Die Klasse CarProvider implementiert die Interfaces IRoutePlanner, IEmissionCalculator, ICostCalculator und ist eine Spezialisierung der Klasse ContentProvider. Sie realisiert die Routenplanung für Autos basierend auf fossilen Energien. Die Attribute und
185
9. Klassendiagramme
Attribute
Methoden
calculateEmissions(SubRoute subRoute)
: float
calculateCosts(SubRoute subRoute) :
float
lookupRoute(TravelSituation start, TravelSituation destination) : Route
getNavikiKMLURL(String startName,
String endName) : URL
getResultDoc(URL navikiKMLURL) :
String
getDistance(String resultDoc) : float
getDuration(float distanceFloatInMetres)
: float
Diese Methode berechnet die Emissionen
einer SubRoute
Diese Methode berechnet die Kosten einer
SubRoute
Diese Methode berechnet eine Route mit
gegebenem Start- und Endpunkt
Diese Methode erfragt die notwendige
URL zur Abfrage des KML Dokuments
mit den Ergebnisparametern.
Diese Methode schneidet den relevanten
Informationsausschnitt (Tabelle mit Parameter Distanz) aus dem erfragten KML
Dokument aus.
Diese Methode berechnet die Anzahl an
Metern für eine Route.
Diese Methode berechnet die Reisezeit auf
Basis der Anzahl von Metern der jeweiligen Route.
Tabelle 9.23.: Klasse BikeProvider
Attribute
Methoden
: float
float
einer SubRoute
SubRoute
Tabelle 9.24.: Klasse CarProvider
186
Attribute
Methoden
Methoden
: float
float
einer SubRoute
SubRoute
Tabelle 9.25.: Klasse DBProvider
DBProvider
Die Klasse DBProvider implementiert die Interfaces IRoutePlanner, IEmissionCalculator, ICostCalculator und ist eine Spezialisierung der Klasse ContentProvider. Sie realisiert die Routenplanung für die Deutsche Bahn. Die Attribute und Methoden dieser
FootProvider
Die Klasse FootProvider implementiert die Interfaces IRoutePlanner, IEmissionCalculator, ICostCalculator und ist eine Spezialisierung der Klasse ContentProvider. Sie realisiert die Routenplanung für Fußwege. Die Attribute und Methoden dieser Klasse werden
in Tabelle 9.26 dargestellt.
PEVProvider
Die Klasse PEVProvider implementiert die Interfaces IRoutePlanner, IEmissionCalculator, ICostCalculator und ist eine Spezialisierung der Klasse ContentProvider. Sie realisiert die Routenplanung für einen Public Electronic Vehicle Anbieter. Die Attribute und
187
9. Klassendiagramme
Attribute
Methoden
Methoden
: float
float
einer SubRoute
SubRoute
Tabelle 9.26.: Klasse FootProvider
Attribute
Methoden
float calculateEmissions(SubRoute subRoute)
float calculateCosts(SubRoute subRoute)
Route
lookupRoute(TravelSituation
start, TravelSituation destination)
TransportationType getTransportationType()
einer SubRoute
SubRoute
Tabelle 9.27.: Klasse PEVProvider
188
Attribute
Methoden
: float
float
einer SubRoute
SubRoute
Tabelle 9.28.: Klasse FahrplanerProvider
Attribute
Methoden
float
SubRoute
Tabelle 9.29.: Klasse BusCostCalculator
FahrplanerProvider
Die Klasse FahrplanerProvider implementiert die Interfaces IRoutePlanner, IEmissionCalculator und ICostCalculator und ist eine Spezialisierung der Klasse ContentProvider.
Sie realisiert die Routenplanung für Bus und Bahn. Die Attribute und Methoden dieser
BusCostCalculator
Die Klasse BusCostcalculator implementiert das Interface ICostCalculator und ist eine
Spezialisierung der Klasse ContentProvider. Sie realisiert die Kostenberechnung für das
Tranportmittel Bus. Die Attribute und Methoden dieser Klasse werden in Tabelle 9.29
dargestellt.
189
9. Klassendiagramme
Attribute
Methoden
float
SubRoute
Tabelle 9.30.: Klasse TramCostCalculator
Attribute
Methoden
calculateEmission(SubRoute subRoute) :
float
einer SubRoute
Tabelle 9.31.: Klasse TramEmissionCalculator
TramCostCalculator
Die Klasse TramCostCalculator implementiert das Interface ICostCalculator und ist
eine Spezialisierung der Klasse ContentProvider. Sie realisiert die Kostenberechnung für
das Tranportmittel Strassenbahn. Die Attribute und Methoden dieser Klasse werden in
Tabelle 9.30 dargestellt.
TramEmissionCalculator
Die Klasse TramEmissionCalculator implementiert das Interface IEmissionCalculator
und ist eine Spezialisierung der Klasse ContentProvider. Sie realisiert die Emissionsberechnung für das Tranportmittel Strassenbahn. Die Attribute und Methoden dieser
BusEmissionCalculator
Die Klasse BusEmissionCalculator implementiert das Interface IEmissionCalculator und
ist eine Spezialisierung der Klasse ContentProvider. Sie realisiert die Emissionsberech-
190
Attribute
Methoden
calculateEmission(SubRoute subRoute) :
float
einer SubRoute
Tabelle 9.32.: Klasse BusEmissionCalculator
Attribute
Der Name des Kontextes
name : String
Tabelle 9.33.: Klasse Context
nung für das Tranportmittel Bus. Die Attribute und Methoden dieser Klasse werden in
9.3.3. Modul ContextProvider
In diesem Modul liegen alle Agenten, welche die Berücksichtigung von Kontext bei der
Routenberechnung ermöglichen.
Context
Die Klasse Context erbt von der Klasse Serializable und stellt einen Kontext dar. Die
Attribute und Methoden dieser Klasse werden in Tabelle 9.33 dargestellt.
ContextProvider
Die Klasse ContextProvider erbt von jade.core.Agent und ist eine abstrakte Klasse die
als Chain of Responsibility implementiert ist. Ein konkreter ContextProvider nimmt
irgendwann konkrete kontextbezogene Ausprägungen an, wie zum Beispiel WetterDotComProvider für aktuelle konextbezogene Wetterdaten oder TimeProvider für aktuelle
kontextbezogene Zeitdaten. Die Attribute und Methoden dieser Klasse werden in Tabelle
9.34 dargestellt.
191
9. Klassendiagramme
Attribute
Context Objekt, das einen konkreten
Kontext beinhaltet
context : Context
Tabelle 9.34.: Klasse ContextProvider
WetterDotComProvider
Die Klasse WetterDotComProvider ist eine Spezialisierung der Klasse ContextProvider.
Sie stellt aktuelle kontextbezogene Wetterdaten zur Verfügung. Die Attribute und Methoden dieser Klasse werden in Tabelle 9.35 dargestellt.
TimeProvider
Die Klasse TimeProvider ist eine Spezialisierung der Klasse ContextProvider. Sie stellt
aktuelle kontextbezogene Zeitdaten zur Verfügung. Die Attribute und Methoden dieser
9.3.4. Modul Interfaces
Dieses Modul beinhaltet alle Interfaces, welche in dem gesamten Paket von den Agenten
genutzt werden.
ICostCalculator
Das Interface ICostCalculator stellt eine Methode zur Verfügung, die die Berechnung der
Kosten einer SubRoute ermöglicht. Die Methoden dieses Interfaces werden in Tabelle
9.37 dargestellt.
IEmissionCalculator
Das Interface IEmissionCalculator stellt eine Methode zur Verfügung, die die Berechnung
der Emissionen einer SubRoute ermöglicht. Die Methoden dieses Interfaces werden in
192
Attribute
projectName : String
APIKey : String
Methoden
generateChecksum(String searchTerm) :
String
searchRequest(String
searchTerm)
:
String
weatherRequest(String cityCode) : String
lookUpCityCode(String searchTerm) :
String
lookUpWeather(String cityCode) : HashMap<String,Float>
calcTemperature(Route route) : float
calcChanceOfRain(Route route) : float
calcWindSpeed(Route route) : float
getContextType() : ContextType
Der Projektname, der als Projekt auf wetter.com angegeben ist
Der API Schlüssel von wetter.com
Diese Methode liefert den von wetter.com
vordefinierten MD5 hash code
Diese Methode liefert die URL als String
für eine Suchanfrage auf wetter.com
Diese Methode liefert die URL als String
für eine Wetteranfrage auf wetter.com
Diese Methode liefert einen City Code für
einen Stadtnamen
Diese Methode liefert Wetterdaten als
HashMap
Diese Methode berechnet die Temperatur
für eine gegebene Route
Diese Methode berechnet die Regenwahrscheinlichkeit für eine gegebene Route
Diese Methode berechnet die Windgeschwindigkeit für eine gegebene Route
Diese Methode liefert den ContextType
WEATHER
Tabelle 9.35.: Klasse WeatherDotComProvider
Attribute
Methoden
lookUpCurrentTime()
Map<String,String>
:
getContextType() : ContextType
Hash-
Diese Methode liefert eine HashMap mit
folgenden Zeitangaben: Jahr, Monat, Tag,
Stunde, Minuten, Sekunden und Millisekunden
Diese Methode liefert den ContextType
TIME
Tabelle 9.36.: Klasse TimeProvider
193
9. Klassendiagramme
Methoden
calculateCosts(subRoute : SubRoute) :
float
Berechnet die Kosten einer SubRoute
Tabelle 9.37.: Interface ICostCalculator
Methoden
calculateEmissions(subRoute : SubRoute) : float
Berechnet die Emissionen von einer SubRoute
Tabelle 9.38.: Interface IEmissionCalculator
IRoutePlanner
Das Interface IRoutePlanner stellt eine Methode zur Verfügung, die die Berechnung
einer geplanten Route ermöglicht. Die Methoden dieses Interfaces werden in Tabelle
9.39 dargestellt.
IWeatherProvider
Das Interface IWeatherProvider stellt Methoden zur Verfügung, die die Berechnung der
Temperatur, Regenwahrscheinlichkeit und Windgeschwindigkeit zu einer gegebenen Route ermöglichen. Die Methoden dieses Interfaces werden in Tabelle 9.40 dargestellt.
9.3.5. Modul Tooling
Dieses Modul beinhaltet Klassen, welche von den Agenten zur Erleichterung der Aufgaben genutzt werden können. Die Tabelle 9.42 zeigt die Methoden der Klasse.
Methoden
lookupRoute(start : TravelSituation, destination : TravelSituation) : Route
Erfragt eine Route mit Start- und Endpunkt
Tabelle 9.39.: Interface IRoutePlanner
194
Methoden
calcTemperature(Route route) : float
calcChanceOfRain(Route route) : float
calcWindSpeed(Route route) : float
Diese Methode berechnet die Temperatur
zu einer gegebenen Route
Diese Methode berechnet die Regenwahrscheinlichkeit zu einer gegebenen Route
Diese Methode berechnet die Windgeschwindigkeit zu einer gegebenen Route
Tabelle 9.40.: Interface IWeatherProvider
Attribute
Diese Klasse hat keine öffentlichen Attribute
Methoden
cleanInput(String string): String
Diese Methode befreit einen String von
Sonderzeichen.
Tabelle 9.41.: Klasse InputCleaner
InputCleaner
Diese Klasse bietet eine Methode um die Eingaben eines Nutzers von Sonderzeichen zu
befreien.
HttpPostRequestor
Diese Klasse bietet eine Methode um einen HTTP-Post-Request an eine URL abzusetzen.
Sie kann von Screen-scraping-Agenten genutzt werden.
Attribute
Diese Klasse hat keine öffentlichen Attribute
Methoden
PostRequest(String requestUrl,Hashtable
postParameters): String
Diese Methode setzt einen HTTP-PostRequest an eine URL ab.
Tabelle 9.42.: Klasse InputCleaner
195
9. Klassendiagramme
9.4. PresentationComposer
Dieses Modul ist die Schnittstelle des Jinengo-Systems mit der Außenwelt. Es beinhaltet
einen SOAP- und einen REST-Webservice sowie die Interfaces, welche diese Webservices
beschreiben.
9.4.1. IPresentationManager
Das Interface IPresentationManager stellt Methoden bereit, die vom PresentationManager implementiert werden. Dieses Interface beschreibt den SOAP-Webservice. Die Methoden des IPresentationManager-Interfaces werden in Abbildung 9.43 gezeigt.
Methoden
deleteUser(String token) : void
login(String mail, String password) : String
Diese Web-Methode löscht einen eindeutigen Nutzer
anhand eines Tokens.
Diese Web-Methode ermöglicht den Login für einen
eindeutigen Nutzer anhand seiner E-Mail Adresse und
seinem Passwort.
logout(String token) : void
Diese Web-Methode ermöglicht den Logout für einen
eingeloggten Nutzer anhand eines Tokens.
lookupCustomerRoute(String Dieser Methode wird der Usertoken übergeben. Weitoken,TravelSituation startSi- terhin werden auch zwei Objekte vom Typ Travelsituation, TravelSituation end- tuation übergeben die einersite die Startposition soSituation) : ArrayList<Route> wie die Endposition repräsentieren. Neben der Position können diese Objekte weitere Parameter enthalten.
Die Rückgabe ist sodann eine Arraylist die Objekte
vom Typ Route enthält, da eine Reise aus mehrerern
Teilrouten bestehen kann.
registerAgentAssembler(String Die Parameter dieser Methode sind identisch mit demail, String password, String nen der registerCustomer Methode. Sie wird verwenpasswordConfirmation) : void det um diejenigen Personen zu registrieren die dann
anschließend die Möglichkeit haben Softwareagenten
neu zu komponieren.
registerBehaviourDeveloperDie Parameter dieser Methode sind identisch mit de(String mail, String password, nen der registerCustomer Methode. Sie wird verwenString passwordConfirmati- det um diejenigen Personen zu registrieren die dann
on) : void
anschließend die Möglichkeit haben das Verhalten von
Softwareagenten zu entwickeln.
196
registerCustomer(String mail,
String password, String passwordConfirmation)
remindUserPassword(String
mail) : void
showUserMail(String token) :
String
updateUserMail(String token,
String mail) : void
updateUserPassword(String
token,
String
password,
String passwordConfimation)
: void
showAllCustomerProperties(String token) : ArrayList
showUserRole(String token) :
String
updateCustomerProperty(String
token,
String
propertyName,String propertyValue) : void
showRouteDetails(String token, String routeID) : void
rateRoutes(String token, boolean positive) : void
Dieser Methode werden die Emailadresse des Nutzers
und sein gewähltes Passwort sowie das Confirmation
Passwort mit gegeben. Diese Daten liegen als String
vor. Das Passwort wird zur Bestätigung als Confirmation Passwort zweifach mitgegeben. Diese Methode
wird angewendet wenn sich normale User registrieren
möchten, die später als reguläre Nutzer des Dienstes
auftreten.
Diese Web-Methode erlaubt registrierten Nutzern die
erneute Anforderung ihres Passwortes anhand ihrer EMail Adresse.
Der Aufruf dieser Methode liefert die Mailadresse
des aktuell eingeloggten Users in Form eines Strings
zurück.
Diser Methode wird der Securitytoken des Nutzers
sowie eine Mailadresse mitgegeben. Sodann wird die
Emailadresse des Users mit dem neuen Wert ersetzt.
Diser Methode wird der Securitytoken des Nutzers sowie ein neues Passwort und dessen Bestätigung mitgegeben. Sodann wird das Passwort des Users mit dem
neuen Wert ersetzt.
Diese Methode liefert alle für einen Kunden registrierten Eigenschaften aus dem CRM (z.B. Der Kunde bevorzugt Routen mit wenigen Emissionen)
Diese Methode gibt die Rolle eines Benutzers zurück
(z.B. Kunde, Agentenentwickler etc.)
Diese Methode erstellt bzw. aktualisiert eine Eigenschaft für einen Kunden im CRM. (z.B. Der Kunde
bevorzugt Routen mit wenigen Emissionen)
Diese Methode sollte aufgerufen werden, sobald ein
Kunde die Details einer Route betrachtet. Ein Aufrufen dieser Methode bewirkt, dass das System an die
Wünsche des Nutzers angepasst werden kann (Adaption).
Diese Methode wird zur Bewertung einer Menge von
Routen benutzt. Die Bewertung wirkt sich auf die Bewertung der Agents aus, welche die Route berechnet
haben.
197
9. Klassendiagramme
uploadMatchMakerAgent(String token, byte[]
file, String fileName, String
description) : void
uploadContentRepositoryAgent(String token, byte[]
description) : void
uploadMessagingProvider(String
token,
byte[]
description) : void
showAllContentRepositoryAgentInfo(String token) :
ArrayList
showAllMatchMakerAgentInfo(String token) : ArrayList
showAllMessagingProviderInfo(String token) : ArrayList
generateNewMatchMaker(String token, String
name, String description,
ArrayList behaviours, AgentDeveloper author) : void
reviewContentRepositoryAgentInfo(String
token,
String repoAgentID, boolean
passed, String reviewComment) : void
reviewMatchMakerAgentInfo(String token, String
matchmakerAgentID,
boolean passed, String reviewComment) : void
getTransferToDWState(String token) : String
198
Diese Methode ermöglicht es, einen MatchmakerAgenten zu dem Jinengo-System hinzuzufügen. Nachdem der Agent hochgeladen wurde, wird er automatisch auf syntaktische Richtigkeit überprüft. Die
semantische Richtigkeit wird von einem Menschen
überprüft.
Diese
Methode
ermöglicht
es,
einen
Contentrepository-Agenten (z.B. ein RoutenplanerAgent) zu dem Jinengo-System hinzuzufügen.
Nachdem der Agent hochgeladen wurde, wird er
automatisch auf syntaktische Richtigkeit überprüft.
Die semantische Richtigkeit wird von einem Menschen
überprüft.
Diese Methode ermöglicht es, einen Messagingprovider
zum Jinengo-System hinzuzufügen. Ein solcher Agent
ermöglicht es, individuelle Nachrichten auf dem Frontend anzuzuzeigen.
Diese Methode gibt die Infos zu allen bereits hochgeladenen Contentrepository-Agenten zurück.
Diese Methode gibt die Infos zu allen bereits hochgeladenen MatchMaker-Agenten zurück.
Diese Methode gibt die Infos zu allen bereits hochgeladenen MessagingProvider-Agenten zurück.
Diese Methode ermöglicht es, aus einen neuen
Matchmaker aus bereits hochgeladenen Matchmakern
zu generieren.
Diese Methode wird aufgerufen, wenn eine Person
einen hochgeladenen Contentrepository-Agenten auf
seine semantische Richtigkeit überprüft hat.
Diese Methode wird aufgerufen, wenn eine Person
einen hochgeladenen Matchmaker-Agenten auf seine
semantische Richtigkeit überprüft hat.
Diese Methode kopiert semantische Triplets vom CRM
in das Datawarehouse.
triggerTransferToDW(String
token) : String
getCustomerRoutes(String
token) : ArrayList
getAdviseMessage(String token,String page,Object contextData) : AdviceMessage
addKPI(String token, String
KpiUri, String[] crmIDs,
String[] routeIDs, String[]
timeValues, double[] baseValues, double[] baseUnits) :
void
removeAllKPIValues(String
token) : void
removeAllKPIValues(String
token, String kpiURI) : void
getAddKpiState(String
token) : String
sparqlQuery(String
token,
String query) : ArrayList
Diese Methode kopiert semantische Triplets vom CRM
in das Datawarehouse.
Diese Methode liefert alle Routen, welche ein Kunde
bereits gefahren ist.
Diese Methode liefert einen Hinweistext, welche von
einem MessagingProvider-Agenten generiert und angeboten wird. Dieser Text kann dann auf dem Frontend angezeigt werden.
Diese Methode fügt eine KPI zu einer Liste von Kunden hinzu.
Entfernt KPI-Werte vom CRM-System.
Entfernt KPI-Werte vom CRM-System.
Diese Methode gibt den Status von allen aktiven KPIs
zurück.
Ermöglich die Ausführung einer SPARQL-Query an
das CRM-System und gibt anschließend das Ergebnis
zurück.
Tabelle 9.43.: Interface IPresentationManager
9.4.2. JinengoException
Die Klasse JinengoException ist die systemweite Jinengo-Fehlerklasse. Die Attribute und
Methoden dieser Klasse werden in Abbildung 9.44 gezeigt.
Attribute
message : String
Methoden
JinengoException(String
rorMessage)
getMessage() : String
Das Attribut beinhaltet die Fehlernachricht.
er-
Konstruktor der JinengoException Klasse, der eine
Fehlernachricht übergeben wird.
Diese Methode liefert die Fehlernachricht.
Tabelle 9.44.: Klasse JinengoException
199
9. Klassendiagramme
9.4.3. PresentationManager
Die Klasse PresentationManager ist eine konkrete Ausprägung des IPresentationComposerInterfaces. Die Methoden der Klasse sind in der Tabelle 9.43 beschrieben.
9.4.4. RestfulPresentationManager
Der RestfulPresentationManager ist der REST-Webservice des Jinengo-Systems. Die
Antworten dieses Services sind auf XML-basiert. Die Attribute und Methoden der Klasse
RestfulPresentationManager werden in Abbildung 9.45 gezeigt.
Attribute
instance : RestfulPresentationManager
parameterForOperations
:
HashMap
wsContext : WebServiceContext
Methoden
RestfulPresentationManager()
getInstance() : RestfulPresentationManager
checkParameterForOperation(String
operationName,HashMap query) :
String
invoke(Source source) : Source
createMapFromQuery(String
query) : HashMap
Dies ist eine Instanz des RestfulPräsentationmanagers
um das Singletonpattern zu realisieren.
HashMap, die notwendige Parameter für Operationen
beinhaltet.
Ressourcen-Objekt.
Konstruktor des RestfulPresentationManagers.
Diese Methode liefert die eigene Instanz zurück
und wird für die Realisierung des Singletonpatterns
benötigt.
Diese Methode prüft, ob Parameter für eine Operation
existieren.
Diese Methode ermöglicht das Aufrufen verschiedener
Operationen. Beispielsweise Login oder Lookup Route.
Diese Methode erstellt eine HashMap auf Basis einer
Query.
Tabelle 9.45.: Klasse RestfulPresentationManager
200
9.5. MessagingModule
Attribute
instance : MessagingManager
messagingProviders
:
ArrayList<MessagingProvider>
Methoden
getInstance() : MessagingManager
getMessage(Customer
customer,String
page,Object contextData) : AdviseMessage
statische Instanzvariable, die die einzige Instanz der MessagingManager Klasse
speichert.
Liste, in der alle verfügbaren MessagingProvider gespeichert werden.
Diese statische Methode liefert eine Referenz auf die einzige Instanz der MessagingManager Klasse
Diese Methode ermittelt eine AdviseMessage, die auf der Jinengo-Website angezeigt werden kann. Das Customer Objekt
enthält den angemeldeten Nutzer, page
ist eine Referenz auf die aktuell betrachtete Seite innerhalb Jinengos und contextData kann weiteren Kontext (z.B. die gerade betrachtete Route o.ä.) enthalten
Tabelle 9.46.: Klasse MessagingManager
Die folgenden Abschnitte beschreiben die Klassen des MessagingModule. Dieses Modul stellt Benachrichtigungen und Werbung durch Agenten bereit, welche auf Basis des
gegebenen Kontexts (Benutzer, besuchte Seite innerhalb Jinengos) generiert werden.
Die MessagingAgenten stehen dabei in Konkurrenz zueinander und müssen daher ein
Gebot abgeben. Um zu bestimmen, welcher Agent den Zuschlag erhält, wertet der MessagingManager die Gebotshöhe, aber auch die angebotene Nachrichtenklasse aus. Die
Nachrichtenklasse definiert, ob es sich bei dem jeweiligen Angebot um Werbung, Statusmeldungen o.ä. handelt.
9.5.1. MessagingManager
Die Klasse MessagingManager ist eine Singleton-Klasse, die die MessagingProvider verwaltet und den Bietvorgang organisiert. Sie bietet den Einstiegspunkt, um eine neue
Nachricht anzufordern. Tabelle 9.46 zeigt die öffentlichen Methoden und Attribute dieser Klasse.
201
9. Klassendiagramme
Methoden
getBid(UUID reference, Customer customer, String page, Object contextData) :
double
getResult(UUID reference) : SnippetMessage
Diese Methode liefert das Angebot des aktuellen MessagingProviders als EUR Wert
für den gegebenen Nutzer auf der gegebenen Seite mit dem gegebenen Kontext zurück. Der Referenzparameter wird
verwendet, um eine Korrelation zwischen
dem getBid() und dem getResult() Aufruf
herzustellen
Diese Methode liefert die SnippetMessage
zurück, die für das vorher durch reference
identifizierte Gebot erstellt wurde.
Tabelle 9.47.: Interface IMessagingProvider
9.5.2. IMessagingProvider
Das Interface IMessagingProvider definiert eine Schnittstelle, die von allen MessagingProvidern implementiert werden muss, damit er am Bietprozess um einen freien AdviseMessagePlatz teilnehmen kann. Tabelle 9.47 zeigt die öffentlichen Methoden und Attribute dieser
Klasse.
9.5.3. MessagingProvider
Die Klasse MessagingProvider implementiert die Schnittstelle IMessagingProvider, und
ist die Basisklasse aller MessagingProvider.
9.5.4. BiddingThread
Die Klasse BiddingThread wird vom MessagingManager genutzt, um die getBid() Methode der verfügbaren MessagingProvider parallel aufzurufen und dann auf die Beendigung
aller Threads zu warten. Tabelle 9.48 zeigt die öffentlichen Methoden und Attribute
dieser Klasse.
9.5.5. AdviseMessage
Die Klasse AdviseMessage stellt eine Nachricht dar, die an das Jinengo-Frontend zurückgeliefert
wird, um dort dargestellt zu werden. Tabelle 9.49 zeigt die öffentlichen Methoden und
Attribute dieser Klasse.
202
Attribute
provider : IMessagingProvider
bid : double
reference : UUID
Methoden
run() : void
Der IMessagingProvider, dessen getBid()
Methode aufgerufen wird.
Das Ergebnis der getBid() Methode, das
zur weiteren Verwendung vom MessagingManager ausgelesen werden kann.
Die Referenz UUID, die genutzt wird,
um zwischen einem getBid()- und einem
getResult()-Aufruf zu korrelieren.
Geerbt von der Thread-Klasse. Initiert die
Ausführung des Threads.
Tabelle 9.48.: Klasse BiddingThread
Attribute
adviseType : String
adviseClass : String
content : Object
Der Typ der AdviseMessage. Gibt dem
Frontend einen Hinweis darauf, wie die
Message zu rendern ist.
Die Klasse der Message. Gibt dem MessagingManager einen Hinweis zur Auswertung des Bietvorgangs.
Enthält die eigentliche Nachricht, die
gemäß dem adviseType interpretiert werden muss.
Tabelle 9.49.: Klasse AdviseMessage
203
9. Klassendiagramme
Methoden
getBid(UUID reference, Customer customer, String page, Object contextData) :
double
getResult(UUID reference) : SnippetMessage
Diese Methode liefert das Angebot des aktuellen MessagingProviders als EUR Wert
für den gegebenen Nutzer auf der gegebenen Seite mit dem gegebenen Kontext zurück. Der Referenzparameter wird
verwendet, um eine Korrelation zwischen
dem getBid() und dem getResult() Aufruf
herzustellen
Diese Methode liefert die SnippetMessage
zurück, die für das vorher durch reference
identifizierte Gebot erstellt wurde.
Tabelle 9.50.: Klasse DefaultProvider
9.5.6. DefaultProvider
Die Klasse DefaultProvider stellt eine Implementierung eines MessagingProviders dar,
die immer dann einspringt, wenn die dynamisch zur Laufzeit hinzugefügten MessagingProvider kein Gebot für einen AdviseMessage Platz abgegeben haben, oder noch keine
weiteren MessagingProvider zur Jinengo-Laufzeit hinzugefügt wurden. Tabelle 9.50 zeigt
die öffentlichen Methoden und Attribute dieser Klasse.
9.5.7. MessagingProviderInfo
Die abstrakte Klasse MessagingProviderInfo stellt alle Metadaten zu einem zur Laufzeit
zum Jinengo-System hinzugefügten MessagingProvider wie das Erstellungsdatum, den
Ersteller und den Quellcode des Providers. Diese Klasse erbt alle Eigenschaften der
Superklasse AgentInfo.
9.5.8. MessagingProviderValidator
Die Klasse MessagingProviderValidator ist eine Singletonklasse, die Methoden zur Validierung eines MessagingProviders bereitstellt. Tabelle 9.51 zeigt die öffentlichen Methoden und Attribute dieser Klasse.
204
9.6. Frontend - JinengoUI
Methoden
unitTestAgent(MessagingProvider provider) : boolean
checkSuperClass(MessagingProvider provider,String className) : boolean
getInstance() : MessagingProviderValidator
Diese Methode führt einen Unittest mit
dem gegebenen MessagingProvider durch
und liefert das Resultat des Tests zurück.
Prüft, ob die Superklasse des gegebenen
MessagingProviders der gegebenen Klasse
entspricht und gibt das Ergebnis zurück.
Liefert die einzige Instanz des MessagingProviderValidators zurück.
Tabelle 9.51.: Klasse MessagingProviderValidator
Methoden
deleteMessagingProvider(String
der) : void
provi-
uploadMessagingProvider(byte[] agentFile,AgentDeveloper author, String fileName, String description) : void
getInstance() : ProviderRepositoryManager
Diese Methode entfernt den gegebenen MessagingProvider aus der JinengoLaufzeit.
Fügt einen MessagingProvider mit
den
gegebenen
Metadaten
zum
MessagingProvider-Repository hinzu.
Liefert die einzige Instanz des ProviderRepositoryManager zurück.
Tabelle 9.52.: Klasse ProviderRepositoryManager
9.5.9. ProviderRepositoryManager
Die Klasse ProviderRepositoryManager verwaltet das MessagingProvider Repository
und erlaubt es, MessagingProvider zur Laufzeit zum Jinengo-System hinzuzufügen und
zu entfernen. Tabelle 9.52 zeigt die öffentlichen Methoden und Attribute dieser Klasse.
VDD: Was ist mit den Frontendklassen?
Die folgenden Klassenbeschreibungen beschreiben die Klassen, Methoden und Attribute
des JinengoUI Projekts.
CMA: Bitte Klassenbeschreibung überprüfen
205
9. Klassendiagramme
9.6.1. BaseController
Die Klasse BaseController erbt von Controller und bildet die Basis-Klasse, von welcher
jeder Controller des Projektes erbt. Die Attribute und Methoden dieser Klasse werden
in der Tabelle 9.53 gezeigt.
Attribute
–
–
Methoden
OnActionExecuted(ActionExecutedContext
Bei jedem Seitenaufruf wird diese Methode aufgerufen.
filterContext) : void
Hier wird die aktuelle Sprache ermittelt und gesetzt.
Ebenfalls wird hier die Nachricht vom MessageProvider geholt.
ExecuteCore() : void
Hier wird versucht die Sprache anhand des gespeicherten Cookies auszulesen.
Tabelle 9.53.: Klasse BaseController
9.6.2. HomeController
Die Klasse HomeController erbt von BaseController und verarbeitet die Anfragen zu
den Home-Views. Die Attribute und Methoden dieser Klasse werden in der Tabelle 9.54
gezeigt.
Attribute
–
Methoden
Index() : ActionResult
–
About() : ActionResult
Impressum() : ActionResult
Agbs() : ActionResult
Error() : ActionResult
GET-Anfragen an die URL /Home/ werden verarbeitet und an das View weitergegeben.
GET-Anfragen an die URL /Home/About/ werden
verarbeitet und an das View weitergegeben.
GET-Anfragen an die URL /Home/Impressum/ werden verarbeitet und an das View weitergegeben.
GET-Anfragen an die URL /Home/Agbs/ werden verarbeitet und an das View weitergegeben.
GET-Anfragen an die URL /Home/Error/ werden
verarbeitet und an das View weitergegeben. Dabei
wird diese Methode genutzt um jegliche Art von Fehlermeldung anzuzeigen.
Tabelle 9.54.: Klasse HomeController
206
9.6.3. RouteController
Die Klasse RouteController erbt von BaseController und verarbeitet die Anfragen zu
den Route-Views. Die Attribute und Methoden dieser Klasse werden in der Tabelle 9.55
gezeigt.
Attribute
–
Methoden
Search() : ActionResult
–
Search(SearchRouteModel
model) : ActionResult
Rate() : ActionResult
History() : ActionResult
GET-Anfragen an die URL /Route/Search werden
verarbeitet und an das View weitergegeben. Das Anfrageformular für Reiserouten wird generiert.
POST-Anfragen an die URL /Route/Search werden
verarbeitet. Ist das model valide so werden die Reiserouten vom Backend angefragt und anschließend ausgegeben.
GET-Anfragen an die URL /Route/Rate werden verarbeitet. Dabei muss der GET-Anfrage der Parameter
routeID mitgegeben werden um eine einzelne Route zu
bewerten, ansonsten wird das gesamte letzte Ergebnis
bewertet. Weiterhin muss rating (true oder false) zu
Bewertung angegeben werden.
GET-Anfragen an die URL /Route/History werden
verarbeitet.. Alle bisher angetretenen Routen werden
angefragt und angezeigt.
Tabelle 9.55.: Klasse RouteController
9.6.4. UserController
Die Klasse UserController erbt von BaseController und verarbeitet die Anfragen zu den
User-Views. Die Attribute und Methoden dieser Klasse werden in der Tabelle 9.56 gezeigt.
Attribute
–
Methoden
SetCulture(string culture) :
ActionResult
–
Setzt die Sprache des Benutzers. Wird nicht über eine
URL angesprochen, sondern direkt aus dem Code.
207
9. Klassendiagramme
Login() : ActionResult
Login(
LoginUserModel model) : ActionResult
LogOff() : ActionResult
Register() : ActionResult
Register(
RegisterUserModel model) :
ActionResult
PasswordLost() : ActionResult
Settings() : ActionResult
SettingsSetEmail(
EmailUserModel model) : ActionResult
SettingsSetPassword(
PasswordlUserModel model) :
ActionResult
Preferences() : ActionResult
Preferences(
PreferencesUserModel model)
: ActionResult
Remind() : ActionResult
Remind(RemindUserModel
model) : ActionResult
208
GET-Anfragen an die URL /User/Login werden verarbeitet und an das View weitergegeben. Das LoginFormular wird angezeigt.
POST-Anfragen an die URL /Route/Login werden
verarbeitet. Der Benutzer wird eingeloggt.
GET-Anfragen an die URL /User/LogOff werden verarbeitet. Der eingeloggte Benutzer wird ausgeloggt.
GET-Anfragen an die URL /User/Register werden
verarbeitet. Ein Formular zur Registrierung wird angezeigt.
POST-Anfragen an die URL /User/Register werden
verarbeitet. Ein neuer Benutzer wird registriert.
GET-Anfragen an die URL /User/PasswordLost werden verarbeitet. Ein Formular zur Passwort-Anfrage
wird angezeigt.
GET-Anfragen an die URL /User/Settings werden
verarbeitet. Drei Formular zum Ändern des Passwortes, der Email-Adresse und der Sprache werden angezeigt.
POST-Anfragen an die URL /User/SettingsSetEmail
werden verarbeitet und die Email-Adresse des Benutzers geändert.
POST-Anfragen an die URL /User/SettingsSetPassword werden verarbeitet und das Passwort des Benutzers geändert.
GET-Anfragen an die URL /User/Preferences werden verarbeitet und ein Formular zum Ändern der
Präferenzen angezeigt.
POST-Anfragen an die URL /User/Preferences werden verarbeitet und die Nutzer-Präferenzen geändert.
GET-Anfragen an die URL /User/Remind werden
verarbeitet und ein Formular zur Passwort-Anfrage
angezeigt.
POST-Anfragen an die URL /User/Remind werden
verarbeitet und der Passwort-Anfrage-Prozess eingeleitet.
Tabelle 9.56.: Klasse UserController
9.6.5. SearchRouteModel
Die Klasse SearchRouteModel bildet das Model zur Suchanfrage und befindet sich in der
Datei RouteModels. Die Attribute und Methoden dieser Klasse werden in der Tabelle
9.57 gezeigt.
Attribute
From : string
To : string
Type : string
Abfahrtsort der Reiseanfrage.
Ankunftsort der Reiseanfrage.
Arrival oder Depature. Definiert ob es sich bei der Reisezeit um Ankunft oder Abfahrt handeln soll.
Datum des Reisezeitpunkts der Reiseanfrage.
Zeit des Reisezeitpunkts der Reiseanfrage.
Anzahl der reisenden Personen.
Date : string
Time : string
Persons : Int32
Methoden
–
–
Tabelle 9.57.: Klasse SearchRouteModel
9.6.6. RouteUtill
Die Klasse RouteUtil wird im Zusammenhang mit Routenergebnissen benutzt um Daten
zu formatierer oder zu konvertieren und befindet sich in der Datei RouteModels. Die
Attribute und Methoden dieser Klasse werden in der Tabelle 9.58 gezeigt.
Attribute
–
Methoden
ConvertFromUnixTimestamp(
double timestamp) : DateTime
SecToStr(float sec) : string
CostsToStr(float costs) :
string
MToKm(string meter) : string
–
Konvertiert einen Timestamp des BackendWebservices in ein .Net kompatibles Datumsformat.
Formatiert Sekunden als String.
Formatiert Kosten zu einem String.
Rechnet Meter in Kilometer um und formatiert dies
als String.
209
9. Klassendiagramme
GetSustainableColor(double
co2) : string
Basierend auf dem CO2-Wert wird eine entsprechende
Farbe für die Nachhaltigkeit errechnet und als HexWert zurückgegeben.
Tabelle 9.58.: Klasse RouteUtil
9.6.7. RegisterUserModel
Die Klasse RegisterUserModel bildet das Model zur Registrierung von Benutzern und
befindet sich in der Datei UserModels. Die Attribute und Methoden dieser Klasse werden
in Abbildung 9.59 gezeigt.
Attribute
Email : string
Password : string
ConfirmPassword : string
Agbs : Boolean
Methoden
Validate(
ValidationContext validationContext) : IEnumerable
Email-Adresse des neuen Benutzers.
Passwort des neuen Benutzers.
Zur Sicherheit muss der Benutzer des Passwort erneut
angeben.
AGBs müssen vom Benutzer akzeptiert werden.
Validiert das Passwort und, dass die AGB akzeptiert
wurde.
Tabelle 9.59.: Klasse RegisterUserModel
9.6.8. RemindUserModel
Die Klasse RemindUserModel bildet das Model zur Passwortanfrage von Benutzern und
befindet sich in der Datei UserModels. Die Attribute und Methoden dieser Klasse werden
in der Tabelle 9.60 gezeigt.
Attribute
Email : string
Methoden
–
Email-Adresse des Benutzers.
–
Tabelle 9.60.: Klasse RemindUserModel
210
9.6.9. LoginUserModel
Die Klasse LoginUserModel bildet das Model zum Einloggen von Benutzern und befindet
sich in der Datei UserModels. Die Attribute und Methoden dieser Klasse werden in der
Tabelle 9.61 gezeigt.
Attribute
Email : string
Password : string
Methoden
–
Email-Adresse des Benutzers.
Passwort des Benutzers.
–
Tabelle 9.61.: Klasse LoginUserModel
9.6.10. LogoffUserModel
Die Klasse LoginoffModel bildet das Model zum Ausloggen von Benutzern und befindet
sich in der Datei UserModels. Die Attribute und Methoden dieser Klasse werden in der
Tabelle 9.62 gezeigt.
Attribute
Token : string
Methoden
–
Aktueller Token des noch eingeloggten Benutzers.
–
Tabelle 9.62.: Klasse LogoffModel
9.6.11. SettingsModel
Die Klasse SettingsModel bildet setzt sich zusammen aus den beiden Modellen EmailUerModel und PasswordUserModel und befindet sich in der Datei UserModels. Die
Attribute und Methoden dieser Klasse werden in der Tabelle 9.63 gezeigt.
Attribute
EmailUserModel : EmailUserModel
PasswordUserModel : PasswordUserModel
Methoden
Instanz der Klasse EmailUserModel.
Instanz der Klasse PasswordUserModel
211
9. Klassendiagramme
–
–
Tabelle 9.63.: Klasse SettingsModel
9.6.12. EmailUserModel
Die Klasse EmailUserModel bildet das Model zum Ändern der Email-Adresse von Benutzern und befindet sich in der Datei UserModels. Die Attribute und Methoden dieser
Klasse werden in der Tabelle 9.64 gezeigt.
Attribute
EmailOld : string
EmailNew : string
Methoden
–
Aktuelle Email-Adresse des Benutzers.
Neue Email-Adresse des Benutzers.
–
Tabelle 9.64.: Klasse EmailUserModel
9.6.13. PasswordUserModel
Die Klasse PasswordUserModel bildet das Model zum Ändern des Passwortes von Benutzern und befindet sich in der Datei UserModels. Die Attribute und Methoden dieser
Klasse werden in der Tabelle 9.65 gezeigt.
Attribute
PasswordOld : string
PasswordNew : string
RepeatNewPassword : string
Methoden
–
Das aktuelle Passwort des Benutzers.
Das neue Passwort des Benutzers.
Wiederholung des neuen Passworts, welches zur Sicherheit mit PasswordNew übereinstimmen muss.
–
Tabelle 9.65.: Klasse PasswordUserModel
212
9.6.14. PreferencesUserModel
Die Klasse PreferencesUserModel bildet das Model zum Einstellen der Präferenzen von
Benutzern und befindet sich in der Datei UserModels. Die Attribute und Methoden dieser
Klasse werden in der Tabelle 9.66 gezeigt. Anmerkung: CodingStyle nicht eingehalten,
ggf. refactoren!
MPE: soll die anmerkung so stehenbleiben?
Attribute
allpreferences : Int32
distance : Int32
sustainability : Int32
costs : Int32
time : Int32
subroutes : Int32
transportation : Int32
Methoden
–
Das Backend erfordert, dass die Präferenzen Sustainability, Distance, Costs und Time nicht größer als 30
Punkte sind. Dies wird hiermit abgebildet.
Wertigkeit für die Distance-Preferenz. Wert muss zwischen 0 und 15 liegen.
Wertigkeit für die Sustainability-Preferenz. Wert muss
zwischen 0 und 15 liegen.
Wertigkeit für die Costs-Preferenz. Wert muss zwischen 0 und 15 liegen.
Wertigkeit für die Time-Preferenz. Wert muss zwischen 0 und 15 liegen.
Wertigkeit für die SubRoutes-Preferenz. Wert muss
zwischen 0 und 15 liegen.
Wertigkeit für die TransportationType-Preferenz.
Wert muss zwischen 0 und 15 liegen.
–
Tabelle 9.66.: Klasse PreferencesUserModel
9.6.15. CacheFilterAttribute
Die Klasse CacheFilterAttribute erbt von ActionFilterAttribute und ist ein Filter um die
Cache-Dauer eines Views explizit zu setzen und befindet sich in der Datei CacheFilter.
Die Attribute und Methoden dieser Klasse werden in der Tabelle 9.67 gezeigt.
Attribute
Duration : int
Methoden
CacheFilterAttribute()
Gibt die Caching-Dauer in Sekunden an.
Der Konstruktor setzt die Caching-Dauer per Default
auf 10 Sekunden fest.
213
9. Klassendiagramme
OnActionExecuted(
ActionExecutedContext
Beinhaltet die eigentliche Logik für das Caching.
Tabelle 9.67.: Klasse CacheFilterAttributel
9.6.16. CompressFilter
Die Klasse CompressFilter erbt von ActionFilterAttribute und ist ein Filter um die
Kompression eines Views bzw. der generierten HTML-Seite einzustellen. Die Attribute
und Methoden dieser Klasse werden in der Tabelle 9.68 gezeigt.
Attribute
–
Methoden
OnActionExecuted(
–
Beinhaltet die Logik um den generierten HTML-Code
als gzip oder deflate auszuliefern.
Tabelle 9.68.: Klasse CompressFilter
9.6.17. LoginForbiddenFilter
Die Klasse LoginForbiddenFilter erbt von ActionFilterAttribute und ist ein Filter um
eine Seite nur auszuliefern, wenn der Benutzer nicht eingeloggt ist. Die Attribute und
Methoden dieser Klasse werden in der Tabelle 9.69 gezeigt.
Attribute
–
Methoden
OnActionExecuted(
–
Wenn der Benutzer eingeloggt ist, wird er an dieser
Stelle auf die Home-Seite zurückverwiesen. Andernfalls wird die Seite normal ausgeliefert.
Tabelle 9.69.: Klasse LoginForbiddenFilter
214
9.6.18. LoginRequiredFilter
Die Klasse LoginRequiredFilter erbt von ActionFilterAttribute und ist ein Filter um
eine Seite nr auszuliefern, wenn der Benutzer eingeloggt ist. Die Attribute und Methoden
dieser Klasse werden in der Tabelle 9.70 gezeigt.
Attribute
–
Methoden
OnActionExecuted(
–
Wenn der Benutzer nicht eingeloggt ist, wird er an
dieser Stelle auf die Home-Seite zurückverwiesen. Andernfalls wird die Seite normal ausgeliefert.
Tabelle 9.70.: Klasse LoginRequiredFilter
9.6.19. CultureHelper
Die Klasse CultureHelper ist eine Hilfs-Klasse um die Multilanguage-Fähigkeit zu ermöglichen.
Die Attribute und Methoden dieser Klasse werden in der Tabelle 9.71 gezeigt.
Attribute
cultures : Dictionary
Beinhaltet die Sprach-Codes, welche von der Website
unterstützt werden sollen.
Methoden
GetValidCulture(string name) : string
GetDefaultCulture() : string
IsViewSeparate(string name)
: bool
Mapped eine Sprachangabe auf einen gültigen SprachCode, z.B. de nach de-DE.
Gibt die Default-Sprache wieder. In dem Fall immer
das erste Element aus cultures.
Gibt true zurück, wenn der angegebene View separat implementiert wurde, z.B. About.cshtml und
About.de-DE.cshtml.
Tabelle 9.71.: Klasse CultureHelper
215
Teil IV.
Projektabschluss
217
ALL: Wer möchte damit mal anfangen?
Klassischer Projektabschluss nach Manfred Burghardt (ohne Kostenkalkulationen):
Produktabnahme
Abnahmetest
Produktabnahmebericht
Projektabschlussanalyse
Abweichungsanalyse
Kundenbefragung
Erfahrungssicherung
Erfahrungsdaten
Kennzahlensysteme
Erfahrungsdatenbank
Projektauflösung
219
Teil V.
Anhang
221
A. Protokolle
ALLE: Dieser Abschnitt ist noch
nicht fertig.
223
A. Protokolle
Projektgruppenprotokoll vom 27.10.2010
Carl von Ossietzky Universität Oldenburg
[email protected]
Protokoll des PG-Meetings
Moderation: Ammar Memari, Benjamin Wager-vom Berg
Anwesend: Huang, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Sperling, Stamer, Temgoua, von der Dovenmühle,Wei
Abwensend (entschuldigt): keiner
Abwensend (unentschuldigt): keiner
Beginn der Meetings: 14:00 Uhr
Verteiler: [email protected]
Themen und Ablauf
Die Inhalte der Projektgruppe und damit verbundene Aufgaben wurden von den Projektgruppenbetreuern vorgestellt. Details sind der entsprechenden Präsentation zu entnehmen.
Getroffene Entscheidungen und Absprachen
Termin der Projektgruppenbesprechung: Mittwochs, 12:00 - 13:30, Raum A4 3-319
Moderation und Protokollfuhrung: Jedes Gruppenmitglied muss die Aufgaben Moderation und Protokollfuhrung ubernehmen. Diese Aufgaben werden alphabetisch
der Nachnamen sortiert abgearbeitet. Fur den 03.11.2010 wird das Protokoll demzufolge von Xin Huang erstellt, die Moderation Timo von der Dovenmuhle.
E-Mail: Fur die Projektgruppe wird ein E-Mail-Verteiler eingerichtet. Im Betreff
der Nachricht ist unbedingt der Prafix [PG-SCRM] zu nutzen, um eine klare Identifikation zu ermoglichen.
Schwerpunktverantwortlichkeit: Wahrend des Verlaufs der Projektgruppe mussen
verschiedene Aufgaben von einzelnen Teilnehmern betreut werden. Die Verantwort-
224
lichkeit fur eine Aufgabe bedeutet nicht, dass alle damit verbundenen Tatigkeiten
nur von dieser Person ausgefuhrt werden. So wird der Verantwortliche fur die Dokumentation auch fur dessen Qualitat verantwortlich sein, nicht aber die Aufgabe
haben, samtliche Fehler eigenstandig abzuarbeiten.
Im Stud.IP wird in den nachsten Tagen eine Liste mit Aufgaben veroffentlicht. Bis
zum nachsten Treffen soll sich jeder fur eine Aufgabe, fur die er die Verantwortung
ubernehmen mochte, entscheiden. Bitte diese Information an die Betreuer senden,
damit wir den Verteilungsprozess schnell abarbeiten konnen.
Seminarthemen: In dem Foliensatz zur Einfuhrungsveranstaltung wurden verschiedene Seminarthemen vorgestellt. Jeder Teilnehmer nennt drei der Prioritat nach
geordnete Themen als Themenwunsch und sendet diese Information an die Betreuer. Die endgultige Zuordnung der Seminarthemen erfolgt durch die Betreuer beim
nachsten Treffen.
Kommunikation in der Gruppe: Die primar verwendete Sprache in Besprechungen
ist Englisch.
Folgetermin
Das nächste Projektgruppentreffen findet am 03.11.2010 um 12:00 s.t. im Raum A4-3
319 statt.
225
A. Protokolle
Sven Kölpin
[email protected]
Moderation: Timo von der Dovenmühle
Anwesend: Huang, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Stamer, Temgoua, von der Dovenmühle,Wei
Verteilung der Rollen
-
Projektmanager: Timo von der Dovenmühle
Assistent Projektmanager: Marc Petersen
Dokumentationsbeauftragter: Daniel Schnieders
Serveradmin MS: Marc Petersen
Serveradmin Linux: Daniel Stamer
Webseitenbeauftragter: Carl Mahnke
Testbeauftrater: Sven Kölpin
Finanzbeauftragter: Xin Huang
Kommunikationsbeautragte: Wei Yi
Seminarthemen
-
Carl Mahnke: Topic Nr. 5
Daniel Schnieders:Topic Nr. 7
Daniel Stamer:Topic Nr. 10
Timo von der Dovenmühle: Topic Nr. 1
Wei Yi: Topic Nr. 3
226
-
Xin Huang: Topic Nr. 6
Alain Marcel: Topic Nr. 4
David Rummel:Topic Nr. 11
Marc Petersen:Topic Nr. 9
Alexander Spennemann:8
Sven Kölpin: Topic Nr. 2
Interviews
Gruppe: S-CRM
Timo, Alexander, Carl, Yi
CRM-FEAT
Daniel Schn., Xin, Marc
TECH
David, Marcel, Sven, Daniel St
Die Termine für die Interviewbesprechungen wurden gruppenintern festgelegt.
Groupware
Einstimmige Einigung auf REDMINE.
Aufgaben für die Woche
- Jeder sollte zu seiner Rolle eine kleine Email verfassen (was sind die Aufgaben etc.)
- Daniel Schn. bereitet eine Protokollvorlage vor
- Die Interviewgruppen treffen sich und machen ein Brainstorming. Ergebnisse werden
im internen Mailverteiler bekannt gegeben.
227
A. Protokolle
Xin Huang
[email protected]
Moderation: Sven Kölpin
Themen und Ablauf
Interview
Die Interviews wurden in den drei vorgesehenen Themenbereichen durchgeführt. Die
wesentlichen Antworten wurden jeweils von der betroffenen Gruppe dokumentiert.
Diskussion: Redmine - Projekt Struktur
Timo hat den Vorschlag gemacht, in Redmine 1 Projekt mit mehreren (aktuell: 3) SubProjekten gestalten zu werden.
öffentliche Fragen
Es wurden noch weitere öffentliche Fragen/Themen diskutiert:
Revision-Control-System
Tracking System
228
Workshop für Latex-Textsatzsystem (Timo)
Workshop für Technischen Teil (Ammar)
Workshop für die Firma BTC
Beschlüsse aus dem Meeting
Daniel Schnieders erstellt eine Vorlage für das Protokoll der Interviews. Jede Interviewgruppe dokumentiert die Antworten in dieses Protokoll. Diese Informationen
werden für die Erstellung des Pflichtenhefts genutzt.
Abstimmung der Redmine Projekt Struktur: 1 Projekt mit mehreren Subprojekten
News, Wiki und Forum für das gesamte Projekt
Projektdokumentation: Die primär verwendete Sprache in Dokumentation ist Deutsch.
Timo sollte über das Seminarthema Nr. 12 kurz referieren.
Es wird ein Workshop für das Latex-Textsatzsystem nach dem nächsten Meeting
von Timo veranstaltet.
Es wird ein Workshop für den technischen Teil (z.B. Agent) veranstaltet. Marcel
sollte eine Anfrage bei Doodle zur Koordination des Termins für diesen Workshop
eröffnen.
Aufgaben der Projektrollen werden beim nächsten Meeting präsentiert und diskutiert.
Termin für den Workshop für BTC wird beim nächsten Meeting diskutiert.
Folgetermin
Das nächste Projektgruppenmeeting findet am 17.11.2010 um 12:00 s.t. im Raum A4-3319 statt. Moderator: Xin Huang Protokollführer: Carl Mahnke
229
A. Protokolle
Carl Mahnke
[email protected]
Moderation: Xin Huang
Themen und Ablauf
Diskussion über die Erstellung des Pflichtenheftes
Timo schlägt vor die Deadline für ein finales Pflichtenheft auf den 20.12 zu setzen.
Des Weiteren schlägt Timo eine Tabelle vor, die die Prioritäten jeder Anforderung
festhält. Ein zusätzliches Treffen vor dem 24.11 soll hierfür abgehalten werden.
Timo wird hierzu eine Doodle-Umfrage starten.
Benjamin schlägt vor, dass das besagte Treffen als (interne) Gesamtgruppe stattfinden soll.
David wirft ein, dass er bereits eine Struktur im Wiki geschaffen hat um das
Pflichtenheft voranzutreiben.
Timo fordert, dass wir das Pflichtenheft nicht zu schnell durchwinken.
Benjamin hält fest, dass die Präsentationen möglicherweise Auswirkungen auf das
Pflichtenheft haben werden.
Ammar betont, dass die Features nicht eingefrohren werden dürfen. Daneben fordert er, dass das Pflichtenheft entweder ganz oder garnicht im Wiki entsteht.
230
Sven hält fest, dass wir Ideen im Wiki sammeln und nächste Woche ein Treffen
abhalten zur Diskussion.
Ammar schlägt vor 2 Wikiseiten zu haben. Eine definiert die Musts und eine weitere
um die Anforderungen zu definieren. Die Arbeitsflüsse müssten umgehend starten.
Timo bekräftigt, dass wir uns um einen festen, zusätzlichen, wöchentlichen Termin
kümmern werden.
Vorgehensweise für das Projekt
Timo hat sich Gedanken gemacht und schlägt eine mögliche Projektvorgehensweise vor.
Zusammenfassung von Timo’s Vorstellung: Am 30.09 haben wir unsere Deadline. Das
Problem ist das wir noch keine Meilensteine haben. Das Problem der agilen Entwicklung ist, dass wir keine Deadline haben. Wir machen uns deshalb nicht eine Deadline
sondern drei Deadlines. Meilenstein 1 beinhaltet das Kernprojekt und beinhaltet alle Basisfunktionen. Es wäre ein vertikaler Prototyp. Das wäre unserer Mussblock. Wir achten
darauf, dass wir alles dazugehörige wie Dokumentation mit abgeschlossen haben. Wenn
sich bei Meilenstein 2 die Anforderungen ändern bleibt Meilenstein 1 davon unbeeinflusst. Meilenstein 2 und 3 verbessern dann sozusagen die Note. Der Vorteil ist, dass,
wenn am Ende was schiefgeht, brauchen wir nicht in Panik ausbrechen. Wenn wir uns
bei Meilenstein völlig verschätzen, so haben wir trotzdem alle “Must Haves“ drin. Sobald
wir einen Prototypen haben kann man gut was zeigen z.B. Industriepartnern, die uns
dann Daten bereitsstellen. Meilenstein 1 könnte Ende März fertig sein. Ein Meilenstein
beinhaltet alles. Wenn wir richtig modellieren, dann ist das auch schon die halbe Softwaredokumentation.
Benjamin: Gehen wir auf jeder stufe das Wasserfallmodell durch?
Timo: Ja. Die Großen machen das auch so. Wenn wir jetzt merken sollten, dass es nicht
so läuft, so merken wir es spätestens am Ende des Semesters. Das bedeutet natürlch es
muss sich an bestimmte Verfahrenweisen gehalten werden. Z.B. Issues richtig verarbeiten. Was haltet ihr von diesem Vorgehen?
Benjamin beteuert, dass es psychologisch ungeschickt wäre, wenn das Kernprojekt
bereits im März fertig wäre.
Ammar wünscht sich, dass die Agents bereits in einem frühen Stadium implementierbar sind. Daneben fodert Ammar die Meilensteine in Iterationen zu unterteilen.
Jeder Monat ist dabei eine Iteration für die jedesmal neue Requirements definiert
werden. Ammar hält fest, dass Anfoderungen sich schnell ändern können und wir
vermeiden sollten Requirements zu definieren, die später dann obsolet sind.
Benjamin meint, dass ein Monat pro Iteration zu kurz ist. Er macht folgenden Vorschlag: Wir hatten (bei seinem vorigen Arbeitgeber) eine generelle Anforderungs-
231
A. Protokolle
Spezifikation. Danach kamen weitere Anforderungen. Für Features wurde ein sogenanntes Kochbuch geschrieben - eine detaillierte Spezifikation. Vielleicht sollten
wir zum Beginn einen größeren, zeitlich längeren, Schritt vollziehen und kleinere
Schritte zum Ende hin. Ihr braucht eine sichere Idee von dem was ihr wollt. Dafür
brauchen wir mehr Zeit. Es ist eine Kombination aus beiden Ansätzen. An der
grundlegenden Infrastruktur sollte es keine Zweifel geben.
Ammer bekräftigt, dass wir hierüber morgen (18.11.10) sprechen werden.
Ammar stellt ein staatlich gefördertes Entrepreneurship Programm vor.
Um daran teilzunehmen benötigt man ein Produkt sowie einen Businessplan. Daraufhin kann man finanzielle Unterstützung erlangen.
Wir könnten damit in der Lage sein eine Firma zu gründen. Ebenfalls wäre eine
Studenten-Firma denkbar.
Am Ende des Projektes wäre hiefür ein guter Zeitpunkt.
Rollenvorstellung und -Diskussion
Xin ist der Meinung, dass die Rollen bereits im Forum ausreichend vorgestellt wurden
und schließt diesen Punkt ab.
Vorstellung von Redmine
Daniel St. stellt mit hilfe des Beamer Readmine vor.
Daniel Schn. Beschwert sich über das Forum, dass man nicht gleich sieht was neu
ist.
Benjamin hält fest, dass Emailbenachrichtungen nicht deaktiviert werden sollten.
Marc gibt als Ratschlag, dass jeder zuerst auf den Activity-Buttton klickt um sich
zu informieren.
Timo fordert, das Tasks immer jemanden zugewiesen werden müssen. Andernfalls
kommt es ins Forum.
Timo stellt das Buch “Getting things done“ vor, welches er gerne an andere Teilnehmer verleiht.
232
Timo stellt sich weiterhin als Issue-Moderator bereit.
Daniel St. wünscht sich von Timo, dass dieser einen Issue-Knigge in Redmine stellt.
Ammar stellt klar, dass die Person die einen Issue startet auch die Person ist, die
diesen wieder schließt. Marc fragt, ob er das Assignment von Issues ändern soll,
wenn er sich um fremde Issues kümmert. Die Frage wird von Ammar verneint.
Seminarthemen (Fragen und Hinwese)
Benjamin bittet alle Studenten sich bei ihm oder Ammar zu melden um die Seminarthemen zu besprechen, sofern dies noch nicht geschehen ist.
Open Fragen (Titel/Logo, Workshop BTC, etc.)
Benjamin schlägt vor einen Workshop für Unternehmen abzuhalten um die Kommunikation in gang zu bringen: Die Leiter der CRM-Abteilungen von BTC und Microsoft haben
eine Academic Alliance. Sie sind deshalb sehr interessiert. Wir wollen ihnen erstmal
nur ein Zeichen geben und zeigen, dass wir an der Sache arbeiten - gerade auch jetzt in
dieser frühen Phase. Möglicherweise hat dies Auswirkungen auf das gesammte Projekt.
Folgetermin
Das nächste Projektgruppenmeeting findet am 24.11.2010 um 12:00 s.t. im Raum A4-3319 statt. Moderator: Carl Mahnke Protokollführer: Marc Petersen
233
A. Protokolle
Marc Petersen
[email protected]
Moderation: Carl Mahnke
Projektname
Jinengo ist nun unser offizieller Projektname.
– Deadline für letzte Einwände gegen den Projektnamen ist der 1. Dezember.
– Nach Ablauf der Frist wird Timo die Domain jinengo.com registrieren.
Jeder ist damit einverstanden.
In naher Zukunft müssen wir über einen Slogan nachdenken. Dieser sollte etwas
mit CRM und/oder Sustainability zu tun haben.
Organisatorische Fragen zum Pflichtenheft
Bis zum 8. Dezember werden wir unsere Aufmerksamkeit den Präsentation schenken.
Anschießend werden wir das Pflichtenheft schreiben.
Das Pflichtenheft muss bis zum 21. Dezember alle Anforderungen für den ersten
234
Milestone enthalten und den Betreuern vorgelegt werden.
Das letzte Meeting in diesem Jahr wird Dienstag der 21. Dezember sein - NICHT
der 22.!
Jeder ist mit diesen Punkten einverstanden.
Präsentation
Benjamin: Die Präsentation soll den aktuellen Stand unserer Ausarbeitung repräsentieren. Das Thema muss nicht komplett durchdrungen worden sein, jedoch
sollte das Basiswissen vorhanden sein, um jedem Gruppenmitglied konkrete Informationen über das Thema mitzuteilen.
Ammar: Die Präsentationen sollen unsere Vorstellungen (unser Bild im Kopf) vom
Projekt ergänzen.
Die Dauer einer einzelnen Präsentation wird 30 Minuten betragen. (15 Min. Pränsentation
und 15 Min. Diskussion)
Die Reihenfolge der Präsentationen entspricht der Auflistung in den Kickoff-Folien.
Wir werden die Präsentationen an 2 Tagen in jeweils 3 Stunden halten.
Die genauen Termine werden via Doodle abgestimmt.
Die Seminararbeit sollte aus maximal 20 Seiten bestehen. (Ohne Quellen)
Sowohl für Präsentation als auch für die Ausarbeitung müss die VLBA Vorlagen
verwendet werden.
Daniel wird die Vorlagen demnächst in unser Repository integrieren.
Formale Spezifikationen zum Pflichtenheft
Das Wasserfallmodell wird für die Erstellung des Pflichtenhefts für Milestone 1
akzeptiert.
Erklärungen unserer Entscheidungen sind im Pflichtenheft durchaus erwünscht.
235
A. Protokolle
Statusreport der einzelnen Rollen
Xin: Beim nächsten Meeting muss jeder 10 Euro für unsere Projektkasse mitbringen.
Auszahlungen aus der Projektkasse sind nur gegen Vorlage eines Kassenbons möglich.
Carl stellt die aktuelle Wordpress-Homepage vor und alle akzeptieren, dass wir mit
Wordpress arbeiten.
Yi warte auf die Fertigstellung des Homepage-Designs und Logos um potentielle
Projektparnter per E-Mail zu kontaktieren.
Wir denken über die Möglichkeit nach, auf der Cebit 2011 einen Vortag oder Workshop abhalten zu können.
Das CRM-System muss bis spätestens Januar 2011 installiert sein.
Social Event
Am 21. Dezember werden wir unsere Weihnachtsfeier veranstalten.
Ein Vorschlag wäre, dass wir ein Kicker-Turnier veranstalten.
Weitere Vorschläge können noch gemacht werden.
Ende des Meetings um 13:15 Uhr. Das nächste Meeting findet am 01.12.2010 statt.
Moderator: Marc Petersen, Protokollant: Alain Marcel Nguefack Temgoua.
236
Alain Marcel Nguefack Temgoua
[email protected]
Moderation: Marc Petersen
Abwensend (entschuldigt): Daniel Stamer
Themen und Ablauf
Präsentationsdatum
08.12.2010 11 - 14 Uhr Raum A4-3-319
09.12.2010 18 - 21 Uhr Raum A4-3-319
Xmas Party
21.12.2010 19 Uhr
Ort : Marvins
Organisiert von : Marcel
regelmäßige Treffen
wird durch doodle abgestimmt werden
237
A. Protokolle
Projektname und Domain
jinengo.com
Logo
timo und David verbessert das Logo und schickt es an Ammar
mögliche Partnerschaft
DB Online Marketing-Gesellschaft.
DB Web-Interface Rail & FLY & RIT und Kosten sind von dem Art der Partnerschaft.
DB Web Client Buchung
Implementierung des Interfaces :
start.de
Webseite
Artikel Moderator von Carl
Jeder ist ein Autor
Webseite in mehreren Sprachen
15.12.2010
15.12.2010
03.12.2010
03.12.2010
Webseite mit Struktur, Layout und Inhalt online verfügbar von Carl
Kontakt Car2go Car2gether(Daimler, Fraunhof)
Finanz in WIKI anzeigen lassen : Xin
frühen Nachmittag Logo Vorschläge
Folgetermin
Das nächste Projektgruppenmeeting findet am 08.12.2010 um 11:00 s.t. im Raum A4-3319 statt.
Moderator : Alain Marcel Nguefack Temgoua
Protokollführer : David Rummel
238
David Rummel
[email protected]
Moderation: Alain Marcel Nguefack Temgoua
Anwesend: Huang, Kölpin, Mahnke, Rummel, Schnieders, Spennemann, Stamer, Temgoua, von der Dovenmühle, Wei
Abwesend (entschuldigt): Petersen
Abwesend (unentschuldigt): keiner
Seminarpräsentationen
Es werden die ersten fünf Seminar-Themen vorgestellt.
Organisatorisches
Ende des Meetings um 14:15 Uhr. Das nächste Meeting findet am 15.12.2010 um 11:00
Uhr statt. Moderator: David Rummel, Protokollant: Daniel Schnieders.
239
A. Protokolle
Daniel Schnieders
[email protected]
Moderation: David Rummel
Anwesend: Huang, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Stamer, Temgoua,Wei
Abwesend (entschuldigt): von der Dovenmühle
Seminarpräsentationen
Es wurden die Topics 6-11 vorgestellt.
Organisatorisches
Ende des Meetings um 14:15 Uhr. Das nächste Meeting findet am Dienstag den 21.12.2010
um 10:00 Uhr statt. Moderator: Daniel Schnieders, Protokollant: Alexander Spennemann.
240
[email protected]
Moderation: Daniel Schnieders
Anwesend: Huang, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Stamer, Temgoua, von der Dovenmühle, Wei
Abwesend (entschuldigt): keiner
Beginn des Meetings: 10:00 Uhr
Pflichtenheft
Die Spezifikationen des Pflichtenheftes sind im zeitlichen Rahmen final entworfen.
Webseite
Das CMS Wordpress ist für die Webseite okay. Die Multi-Language Unterstützung funktioniert. Das Design ist soweit okay und darf in Absprache verbessert werden. Der Reitername Blog wird in den Reiternamen Journal abgen̈dert. Links die keinen Inhalt besitzen
werden entfernt.
Social Event
Das Social Event wurde vorwärtsterminiert auf 20 Uhr. Die Biergutscheine bitte mitbringen. Es wird ein Kicker-Turnier geben!
241
A. Protokolle
[email protected]
Moderation: Max Mustermann
Anwesend: Huang, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Temgoua,
von der Dovenmühle,Wei
Abwesend (entschuldigt): Kölpin, Stamer
Review des Jahres 2010
Die im vergangenen Jahr definierten Anforderungen wurden betrachtet. Vorrangige Fragestellung war, ob der Detailgrad der Anforderungsdefinition für den Entwurf ausreichend ist. Dies wurde bestätigt.
Diskussion: Erhöhung des CRM-Anteils aus strategischer Sicht. Die bisherige Ausrichtung ist noch zu sehr auf den Endanwender konzentriert.
Benjamin und Ammar bieten an, ein Buchkapitel zur Verfügung zu stellen.
Business Model
Diskussion: Was ist eigentlich unser Geschäftsmodell und wie sind die Einflüsse auf den
weiteren Entwicklungsprozess.
Im Rahmen der Diskussion haben sich folgende Fragestellungen ergeben. Diese Fragen
konnten nicht vollständig beantwortet werden, haben aber für den nächsten Meilenstein
eine besondere Bedeutung:
Trade-off zwischen Anbietern und Konsumenten, je nachdem, wer für den Dienst
zahlt. Wie kann man das auflösen?
242
Wer ist der bevorteilte Teilnehmer?
Indirekt betroffene Akteure (wer hat noch einen Vorteil) und wer verdient damit
Geld?
Organisation
Im folgenden sind die Punkte dokumentiert, die organisatorische Fragen der Projektgruppe betreffen.
Ausarbeitung Seminar
Die Ausarbeitungen müssen bis zum 21.02.2011 fertiggestellt werden. Die Abgabe erfolgt
via E-Mail an den Themen-Betreuer.
Urlaubsplanung
Für die Urlaubsplanung wurde ein spezieller Bereich im Projektgruppen-Wiki eingerichtet. Urlaubswünsche sind hier bitte langfristig einzutragen, sodass wir intern vernünftig
planen können.
Projektgruppentreffen intern
Alle weiteren internen Projektgruppentreffen werden bis zum Ende des Vorlesungszeitraums im Rollverfahren durchgeführt. Beginnend mit dem Termin Donnerstag, 06.01.2011,
findet das Treffen um 08:00 statt. Das Folgetreffen ist der Montag, 10.01.2011.
243
A. Protokolle
UML-Workshop
Um die Phase des Entwurfs zügig durchführen zu können, wird ein interner UMLWorkshop durchgeführt. Hierbei werden zuerst Aktivitäts-, Sequenz- und Klassendiagramme betrachtet. Die Durchführung wird von Timo organisiert und vorbereitet.
244
Daniel Stamer
[email protected]
Moderation: Timo von der Dovemühle
Anwesend: Huang, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Stamer, von der Dovenmühle, Wei
Abwesend (unentschuldigt): Temgoua
Raum für die Projektgruppe
Wie müssen und eventuell selber um einen Raum kümmern. Dies ist die gängige Vorgehensweise.
Projektplan für die 1. Iterationsstufe
Timo wird diese Woche noch einen detaillierten Projektplan zu Papier bringen. In Zuge
dessen werden Verantwortlichkeiten.
Fragestellung; Wer macht was?
Akteure des Systems (Anwendungsfälle)
Endkunde (Reisender)
Mobilitätsanbieter(Bahn, Kfz, Fahrrad)
Dataminer (Datenauswertung)
245
A. Protokolle
Entwickler (Einspeisung von Agenten)
Klärung des CRM Prinzips durch Benjamin
Klarstellung der CRM Funktionen im System am Vergleich mit der Amazon Recommender Engine. Mögliche Integration in Filterung der Tradeoffs der Suchergebnissen.
Oberstes Ziel ist Nachhaltigkeit, sowie der Profit im Kapitalismus.
”Verkaufe dem Nutzer, dass er sich nach seinen Präferenzen bewegt. In Wirklichkeit
jubelt man ihm nachhaltige Bewegung unter.“ -Benjamin
Stichwortartiges Festhalten von Ideen
Striche für Mehrfachnennungen.
Erfahrungswissen (Parkplatzdilemma) — ///
Kriterienpriorisierung — //
Vergleich von Kombinationen/Routen in mehreren Dimensionen
Gruppenplanung
Transportbedarf von Gepäck
Qualität der Routenplanung
Spass an der Reise
Lachende GUI ;-)
Diskussion Openness vs. Sustainability
Die Agenten-basierte Architektur kann nicht nachhaltig genannt werden. Es wird nur
in Verbiundung mit den Nachhaltig-orientierten Agenten der Jinengogruppe zu einer
Nachhaltig-orientierten Gesamtanwendung.
246
Yi Wei
[email protected]
Moderation: Daniel Stamer
Anwesend: Huang, Kölpin, Petersen, Rummel, Schnieders, Spennemann, Stamer, Temgoua, von der Dovenmühle,Wei
Abwensend (entschuldigt): Mahnke
Beginn der Meeting: 12:00 Uhr
Organisatorisches
Die krankheitsbedingten Abwesenheit der regulären Meetings muss dem Betreuer
rechtzeitig benachrichtigt bzw. begründet werden.
Die Agenda jedes regulären Meetings soll ergebinisorientiert sein.
Zum Beginn jedes Meetings sollen die Ergebnisse von letzten Woche kurz vorgestellt werden.
Urlaubsantrag ist bei Betreuer zu melden.
Deutsch wird als offizielle Sprache festgelegt.
Diskussioin - Systemabgrenzung
In der Zukunft werden zwei ggf. mehrere Gruppen gebildet. Nach Daniel soll eine Gruppe
für Beschreiben und definieren des Systems zuständig sein,während die andere Gruppe
mit Konzipieren und Konstruieren von Schnittstellen beschäftigen soll.
247
A. Protokolle
Schwerpunkte in der Diskussion:
Semantische Beschreibung der Schnittstellen, z.B.
– Wie können Schnittstellen realisiert werden(z.B.screen scraping)?
– Welche Daten werden via Schnittstellen in unseres System übertragen?
– Was könnte Agent uns anbieten?(z.B. kostenlos Code fuer Studenten von
DB?)
Recherchieren und Evaluieren von Service
Entwicklung und präzise Darstellung der Problemstellung, z.B
– Was brauche ich um unseres Modell zu realisieren?
– welche Wirkungen sollen berücksichtigt werden?
– Welche immobile Faktoren sollen mitberücksichtigt werden.
– Wie werden die Kriterien aufgebaut?
– Welche Funktionalität muss realisiert werden?
– Wie kann die Transportation ontologische dargestellt werden.
– Wie ist die Domainontologie?
Aufzeichnen von Anwendungsdiagramm bzw. Sequencediagramm
CRM soll die Daten generieren, die überall stehen.
Schlussfolgerung:
Die Teilnehmer werden nach Aufgaben in Gruppen geteilt. Die Ergenisse werden im
nächsten Meeting presentiert.
248
Aufgabenverteilung
Anwenderabhängig Reisenden — Provider
Reiseplan (Blickwinkel Reisender) CARL
– Ergibnisfiltern (Blickwinkel Reisender) Alexander
Reiseplan (Blickwinkel Provider) Xin
– Ergibnisfiltern (Blickwinkel Provider) TIMO
Reise bewerten (Blickwinkel Reisender) DAVID
Nutzerprofil ändern (Blickwinkel Reisende) SVEN
– Bewertung auswerten(Blickwinkel Provider) Daniel SCH
Agent hinzufügen (Blickwinkel Entwickler)DANIEL
– Agent bestätigen(Blickwinkel Provider) Marc
Benutzer registieren (Blickwinkel Reisender) Marcel
Sonderaufgabe-Kommunikation Yi
Abgabe
Jeder Teilnehmer muss vor Di. um 18:00 Uhr die Ergenisse an Moderatorin Yi von
Nächsten Meeting per E-mail schicken.
Folgetermin
Das nächste Projektgruppenmeeting findet am 26.11.2010 um 12:00 s.t. im Raum A4-3319 statt. Moderatorin: Yi Wei Protokollführer: Xin Huang
249
A. Protokolle
Xin Huang
[email protected]
Moderation: Yi Wei
Beginn der Meeting: 12:00 Uhr
Organisatorisches
Der Arbeitsaufwand gesamter Projektgruppe wird aufgrund der Klausurvorbereitung in den ersten zwei Wochen in Februar (5. und 6. KW) auf Minimal reduziert.
Ab der 7. KW, insbesondere in den Semesterferien in März, soll intensiver gearbeitet werden und die Zeit für das Projekt ausgenutzt werden.
Es wird festgelegt, am Anfang jedes Meeting ein Review vom letzten Meetingsprotokoll durchzuführen, um die Arbeitsergebnisse in letzter Woche zu kontrollieren.
Kommunikationsstatus mit externen Partnern
Die Kommunikationsbeauftragte Yi hat den Kommunikationsstatus mit externen
Partnern mit ppt-Folien berichtet.
Beschlüsse
– Es wird ein Workshop für die Software MS Dynamic CRM gewünscht.Yi soll
mit Microsoft Academic Alliance Kontakt nehmen.
250
– Es wird sich auf Car2go und Carpooling als Car-sharing Sevices konzentriert.
– Es sind weitere sich für unser Projekt interessierende Firmen in der 2. Iteration
zu suchen.
Anwendungsfälle
Präsentation der Anwendungsfälle
Die Teilnehmer haben die von ihnen modellierten Anwendungsfalldiagramme vorgestellt
und mit den anderen diskutiert.
Reise planen (Blickwinkel Reisender) CARL
– Ergibnis filtern (Blickwinkel Reisender) ALEXANDER
Reise planen (Blickwinkel Provider) XIN
– Ergibnis filtern (Blickwinkel Provider) TIMO
Reise bewerten (Blickwinkel Reisender) DAVID
Nutzerprofil ändern (Blickwinkel Reisende) SVEN
– Bewertung auswerten(Blickwinkel Provider) DANIEL SCH
Agent hinzufügen (Blickwinkel Entwickler)DANIEL
– Agent bestätigen(Blickwinkel Provider) MARC
Benutzer registieren (Blickwinkel Reisender) MARCEL
Überarbeitung
Jeder Teilnehmer soll das von ihm modellierte Anwendungsfalldiagramm unter Berücksichtigung
der Diskussionsergebnisse bis das interne Treffen am Donnerstag überarbeiten und die
Anwendungsfälle textuell beschreiben.
251
A. Protokolle
Abschluss der Analysenphase
Die Analysenphase wird bis nächstes Meeting mit der Dokumentation der Anwendungsfälle
abgeschlossen.
Folgetermin
Das nächste Projektgruppenmeeting findet am 02.02.2011 um 12:00 s.t. im Raum A4-3319 statt. Moderatorin: Xin Huang Protokollführer: Sven Kölpin
252
Sven Kölpin
[email protected]
Moderation: Xin Huang
Organisatorisches
Unser PG-Raum (A4-3-326) kann ab jetzt genutzt werden (Ammar kümmert sich
um den Zugang)
Martin Tröschel am 2.3. Treffen muss vorbereitet werden(Yi)
Timo Kontakt zu Nico Brehm
Internetseite: Idee und Ziel muss unbedingt überarbeitet werden
Beim Treffen am 16.2 sollen die Webseiteninhalte diskutiert werden
Kontostand
Aktueller Kontostand: 130 EUR
Jinengo.com-Domain von Timo gesponsort
253
A. Protokolle
Weiteres Vorgehen
Daniel und Sven sammeln Links zum Thema Designpattern u. schicken sie rum
Anschließend gemeinsame Diskusion über die Pattern am 17.2 16-18 Uhr
ArgoUML
Code conventions müssen gefunden werden
Export der Diagramme ab jetzt in *.SVG
CRM-Installation
Wurde angefangen, ist allerdings schwer
YI wendet sich an Microsoft, Marc liest die Dokumentation
Folgetermin
Das nächste Projektgruppenmeeting findet am 09.02.2011 um 12:00 s.t. im Raum A4-3319 statt. Moderatorin: Sven Kölpin Protokollführer: Carl Mahnke
254
Carl Mahnke
[email protected]
Moderation: Sven Kolpin
Anwesend: Huang, Kölpin, Mahnke, Rummel, Schnieders, Spennemann, Stamer, von
der Dovenmühle,Wei
Abwensend (entschuldigt): Temgoua, Petersen(Urlaub)
Organisatorisches
Es wird das Treffen mit Tröschel diskutiert. Das Treffen bleibt jedoch am 03.02.2011.
David und Timo bereiten eine Präsentation vor. Ein Grossteil der Studenten wird jedoch
aufgrund des Seminars BI abwensend sein.
Review Protokoll der letzten Woche + Statusberichte
Der Stand der Website wird kurz vorgestellt. Benjamin ist noch nicht zufrieden mit der
Page Ïdee und Ziel”. Hier fehlt das Buzzword ”Multimodale Mobilität”. Carl wird dies
nachbessern. Ebenfalls ist Benjamin nicht mit der Page ”Mulitimodale Mobilitätßufrieden,
weil hier lediglich von Elektromobilität erzählt wird. Carl wird hierfür eine Issue verteilen.
YI stellt den Stand mit Partner Microsoft und den damit verbundenen Workshop vor.
Timo weisst darauf hin, dass wir ein Grundverständnis vom CRM brauchen und Beschränkung auf das technische Fundament erfolgen sollte.
Benjamin stellt fest, dass es besser wäre wenn der Workshop von einem Microsoftmitarbeiter erfolgt. Der kann dann auch mehr über die Anbindung von Webservices erzählen.
255
A. Protokolle
Des weiteren stellt Benjamin fest, dass wir eine kurze Agende fur den Workshop brauchen. Diese muss dann an Frau Schorp gesendet werden.
Die Dauer des Workshops ist noch nicht endgültig klar jedoch soll ein CRM-Expertenteam
gebildet werden. Die gesamte Gruppe nimmt teil an dem Workshop, jedoch erhält das
Expertenteam eine Verlängerung um vertiefende Fragen abzuarbeiten.
Das Datum des Workshops steht noch aus.
Weiteres Vorgehen Entwurf
Timo sagt, dass wir die Komponenten identifizieren müssen.
Sven schlägt vor mit dem Agentenframework zu starten und im März alles runterzuschreiben.
Timo: ”Ja, wir definieren aber nur die Grundarchitektur mit Schnittstellen. Inhalt der
Komponenten erfolgt erst im zweiten Schritt. Die Kommunikation der Komponenten ist
hierbei wichtig. Wir sollten noch nicht im Detail rumfrickeln sondern auch Dummies
einbauen um am Ende den Prototyp vorzeigen zu können.”
Sven meint wir können erst starten wenn das Framework steht.
Timo findet, dass das Komponentendiagramm allein reicht nicht. Die Schnittstellen
müssen definiert sein für die Gruppenbildung.
Sven hält fest, dass wir nächste Woche mit dem Komponentenentwurf und den Schnittstellen starten müssen.
(Anderes Thema)
Sven schlägt vor Teams zu bilden. Wie etwa Client/Server mit Deadlines. Am besten
sollten wir diese schon Anfang nachster Woche definieren.
Timo: ”Der 28.02 ist Deadline für den Entwurf. Dann hat man die Woche darauf um für
eine Komponente die Basisimplementierung zu entwerfen, sodass die 1. Itereationstufe
auch umgesetzt werden kann. Pro Team haben wir dann 2-3 Leute. Pro Komponente
brauchen wir dann auch ein vernünftiges Klassendiagramm. Im März können wir dann
alles implementieren.”
Sven schlägt vor, dass jede Gruppe einen Teamleiter bestimmt um Timo zu entlasten.
Timo findet es wäre gut einen Ansprechpartner pro Gruppe zu haben. Im Notfall kann
immernoch ein Subgruppendiktator bestimmt werden.
(Anderes Thema)
Sven findet, dass nächste Woche die Code-Konventionens getroffen werden müssen. Das
ist jedoch abhängig von der Technologieevaluation.
Daniel Stamer meint, dass das Problem ist, dass die Agentenframeworks Java verlangen.
Für CRM bietet sich jedoch .NET an.
Timo sagt wir sollten Problemabhängig den Code wählen.
Sven sagt, dass das Agentenframework das Herzstück ist worauf alles aufbaut.
Timo hält fest, dass Komponenten technologieunabhängig kommunizieren sollten. Für
Spezielle Komponenten ist eine andere Technologie evtl. sinnvoller. Dafür brauchen wir
256
klare Komponentengrenzen. Die Frage wäre ob dass unsere Auftraggeber erlauben.
Daniel Stamer favorisiert Java aus drei Gründen: 1. SOA-Websevices werden von Java
unterstützt. 2. Die Agenten werden auf Java basieren 3. Unsere Leute haben am meisten
Ahnung von Java. Andere Technologien seien kaum notwendig.
Timo ist einverstanden. .NET kann mit seiner Flexibilität auch Schwierigkeiten bereiten
und wir wären mit Java weniger Plattformabhängig.
Stand des Testframworks
Sven: Ës gibt verschiedene Möglichkeiten zum Testen: z.B. erst Tests schreiben, dann
coden oder andersrum oder andere Leute testen fremde Codes.”
Timo: SSelbst testen macht keinen Sinn. Es muss konkurrierend getestet werden. Wir
machen Test-Driven-Developement nur über die aufzurufenden Methoden.”
Daniel Stamer schlägt die Pair-Programming vor.
Sven findet, dass das zu viel Kommunikation erfodert.
Timo meint, dass das einen hohen Qualitätsstandard fördert. Man muss sich ohnehin
abstimmen.
Daniel Stamer meint, dass wir in einem Monat zeitlich kein Test-Driven-Developement
schaffen.
Timo sagt, dass wir aber nicht das interne testen.
Sven: ”Wir machen also Test-Driven-Developement nur mit Komponententests.”
Daniel Stamer: Äber selbst das ist noch aufwendig: Bspw. Gelieferte Routen Testen.”
Timo: ”Wir testen aber nicht den Blob.”
Daniel Stamer: ”Das Problem ist, dass wir keine Anwendung schreiben, die valide Mailadressen liefert. Strings auf Format testen ist leicht, aber die Richtigkeit unser Geschäftslogik
ist viel komplexer.”
Timo: ”Das ist aber ein anderes Level. Wir wollen aber erstmal zeigen, dass die Komponenten untereinander richtig kommunizieren.”
David meint, dass wir die Routenplanung trotzdem testen müssen.
Timo findet, dass wir erstmal die Komplexität herausziehen.
Sven will sich ein Konzept überlegen.
Raum
Ammar hält fest, dass Gomez leider in Mexico ist. So lange der Raum aber offen ist
können wir ihn jedoch nutzen. Ammar kann ihn auch aufmachen. Wir können ihn theoretisch ab heute nutzen.
257
A. Protokolle
CRM
Benjamin: ”Wir haben eine neue CRM Version. Die steht bis September. Das erspart
uns arbeit.”
Daniel Stamer: ”Läuft das über Webservices?”
Timo bejaht die Frage.
Sven: ”Wir müssten dann noch wissen wie man die Webservices nutzt.”
Benjamin: ”Das wäre was für den Workshop. Wir brauchen dann noch eine Agende für
Frau Schorp.”
Timo meint die Expertengruppe sollte die Agenda stellen.
Benjamin möchte die Agenda bitte bis Ende dieser Woche haben. Die Schnittstellen
ms̈sen dabei spezifiziert werden. Wir müssen also konkret werden.
Sven: ”Dazu müssen wir aber wissen, was für Schnittstellen wir brauchen.”
Ammar meint, dass David dazu bestimmt was erzählen kann wegen seinem Seminarthema.
David ist der erste Teilnehmer der Expertengruppe.
Timo macht auch mit.
Sven überlegt es sich noch.
Folgetermin
Das nächste Projektgruppenmeeting findet am 16.02.2011 um 12:00 s.t. im Raum A4-3319 statt. Moderatorin: Carl Mahnke Protokollführer: Marc Petersen
258
Marc Petersen
[email protected]
Anwesend: Huang, Kölpin, Rummel, Mahnke, Spennemann, Stamer, Petersen, Wei,
Temgoua
Abwesend (entschuldigt): Schnieders(Urlaub), von der Dovenmühle(Urlaub)
Fortschritt der Website
Carl weist darauf hin, dass immer noch nicht alle von ihm verteilten Issues bzgl. der
Website erledigt wurden. Noch ist dies aber nicht so schlimm, da die vorherige Woche
noch zu der ruhigeren Phase, aufgrund der Klausuren, gezählt wurde.
Da Benjamin nicht am Treffen teilnehmen konnte, wird die Präsentation der Website
auf nächstes Treffen verschoben.
Fortschritt der Modellierung
Carl stellt das Architektur- bzw. Komponentendiagramm für den ersten Meilenstein vor.
Daniel St. erklärt die Gedanken, die hinter der Archtitektur stecken und merkt an, dass
die Komponente Extraction Storage mittlerweile Content Repository heißt.
Folgend werden die Klassendiagramme für die Komponenten Content Repository, User
Model Module und Adaptation Engine kollaborativ erläutert. Das Diagramm für den
Presentation Composer wurde noch nicht modelliert.
Ammar macht die Anmerkungen, dass alle Diagramme generell noch mal auf Design
Patterns geprüft werden sollten und, dass die Zeitangabe bei der Methode matchRoute
in der Adaptation Engine fehlt. Weiterhin wird über die Darstellungsmöglichkeiten der
Routen für den Benutzer diskutiert. Es gäbe die Möglichkeit, dass die Suchergebnisse
259
A. Protokolle
quasi live in die Ergebnisliste im Frontend gepusht werden. Demnach würde sich die
Liste immer updaten, sobald eine neue Route berechnet wurde. Diese Idee wird allgemein
abgelehnt, da die Benutzerfreundlichkeit dadurch beeinträchtigt werden würde.
Allgemein stimmt Ammar den angefertigten Modellen, besonders im Hinblick auf sein
Reference Model, zu.
Raum
Aktuell besteht Unklarheit über die weitere Nutzung des Gruppenraumes, da in der
Folgewoche Gäste in dem Raum arbeiten werden. Ammar klärt dies mit Prof. Goméz
ab.
Folgetermin
Das nächste Projektgruppenmeeting findet am 23.02.2011 um 12:00 s.t. im Raum A4-3319 statt. ModeratorIn: Marc Petersen Protokollführer: Alain Marcel Nguefack Temgoua
260
Alain M. Nguefack T.
[email protected]
Anwesend: Schnieders, Kölpin, Rummel, Mahnke, Spennemann, Stamer, Petersen, von
der Dovenmühle, Temgoua
Abwesend (entschuldigt): Huang(Urlaub),Wei(Urlaub)
Aktuelles und Organisation
kühlschrank:
Kühlschrank wird noch heute von M. Petersen abgeholt werden
Geldstraffe/Nachsitzen:
wer nicht rechzeitig zum internen Treffen kommt und keine entschuldigung vorgelegt hat, wird pro Stunde 1 Euro zahlen
Die Entschuldigung muss einen Tag vorher an den Tütoren per Email zugeschickt
werden.
Ausarbeitung:
Der Frist der Abgabe von Seminarhausarbeit wurde von 21.02.2011 auf 24.02.2011
verschoben.
jeder muss seine Hausarbeit als pdf-datei an den Tütor per Email senden.
Cebit:
keine richtige Entscheidung wurde an dieser Stelle getroffen
261
A. Protokolle
Weitere:
Wei muss finden, wann genau der Work-schop von CRM stattfinden soll. Dazu soll
Benjamin einpaar Leute einladen.
Eine Vorstellung der Projektgruppe(Plattform, CRM Gedanke, Technik, ElectroMobilität). Ziel wäre zum Beispiel eine Zusammenarbeit.
Folie der Präsentation muss bis Montag an den Tütoren verschickt werden.
Dauer der Präsentation: 20 - 30 minuten
Eine Vorschlag der User-Interface wurde von Timo vorgestellt und wird nicht angenommen. Grund dafür war nicht professionel gemacht und muss auf die Jineno-seite
professionnel gemacht werden.
Jinengo Webseite
Der Stand der Jinengo Webseite wird von Carl vorgestellt werden und einige anmerkungen wurden angenomme z.B Oracle muss von der Webseite raus. CRM muss noch
detailliert geschrieben werden.
Folgetermin
Das nächste Projektgruppenmeeting findet am 02.03.2011 um 12:00 s.t. im Raum A4-3319 statt. ModeratorIn: Alain Marcel Nguefack Temgoua Protokollführer: David Rummel
262
David Rummel
[email protected]
Moderation: Alain Marcel Nguefack Temgoua
Anwesend: von der Dovenmühle, Huang, Kölpin, Mahnke, Rummel, Schnieders, Spennemann, Stamer, Temgoua, Wei
Abwesend (entschuldigt): Petersen (Urlaub)
Bericht Treffen mit Martin Tröschel und CeBiT-Besuch
Die Zusammenarbeit mit dem OFFIS und EWE soll weiter forciert werden. Andere
Kooperationen sind nice-to-have, stehen aber nicht im Vordergrund.
Sonstiges
Informationsseite über CRM wird erstellt und auf jiengo.com geladen
Interner Termin mit den Betreuern zur Präsentation des 1. Prototypens wird auf
den 06.04.2010 festgelegt
Fragen zu Jinengo
Es wird entschieden, dass in Jinengo Default-Agenten zur Berechnung von Kosten und
Emissionen je Transporttyp von den Administratoren festgelegt werden können.
263
A. Protokolle
CRM Workshop Plan
Die Agenda für den Workshop wird wie folgt festgelegt:
0,5h Kurze Präsentation Jinengo
1,0h Grundfunktionalität CRM
0,5h Datenmodellierung
1,5h Schnittstellen
0,5h BI
0,5h Diskussion / Abschluss
Folgetermin
Das nächste Projektgruppenmeeting findet am 16.03.2011 um 12:00 s.t. im Raum A043-319 statt. Moderator: David Rummel Protokollführer: Daniel Schnieders
264
Daniel Schnieders
[email protected]
Aufgabenverteilung
Die Aufgabenverteilung wurde geändert:
Carl und Daniel Sch. sind vom LaTeX Team ins Frontend Team gewechselt
David ist vom Content - Agent Team ins CRM-Team gewechselt.
Für die Dokumentation ist nun jeder verantwortlich
Fortschritt
Der Stand für den Projektfortschritt ist der folgende:
Die ersten Agents für Bahn, Elektroauto und Wetter.com sind fertiggestellt
Ein Bus-Agent ist in Planung
Agenten müssen in Zukunft parallel laufen, um Anfragen schneller bearbeiten zu
können
265
A. Protokolle
Caching für Wetter.com ist sinnvoll
Das Frontend-Team hat die Grundfunktionen wie Login, Logout, Change-Details,
etc. fertig gestellt und arbeitet aktuell an der Routenplanung. Ebenfalls wurde die
Grundlage für Multi-language und Corporate Identity geschaffen.
Der Presentation-Composer ist mit ca. 80% relativ weit
Sonstiges
David hat nun die Rolle des Qualitätsbeauftragten, welcher verantwortlich für die Kontrolle der Inhalte und Rechtsschreibung ist.
Ammar hat die Realisierung und Austauschbarkeit der Module sowie die Adaptivität
und Wartbarkeit des Codes als wichtig für die nächste Iteration angesehen.
266
[email protected]
Anwesend: Huang, Kölpin, Petersen, Rummel, Schnieders, Spennemann, Stamer, Temgoua, von der Dovenmühle, Wei
Abwesend (entschuldigt): Mahnke
Protokoll der letzten Woche / Aufgaben
David hat in seiner Rolle als Qualitätsbeauftragter die Dokumentation auf Korrekturen gepüft und notwendige Änderungen rot markiert. Die markierten Stellen sind von
den jeweiligen Autoren zu korrigieren. Siehe auch https://134.106.13.85/redmine/
projects/scrm/wiki/Dokumentation
Bezüglich der Seminarausarbeitungen wurde geäußert, dass die deutschen Ausarbeitungen nochmals durchzusehen und im *.tex Code richtig zu formatieren sind. Die englischen
Ausarbeitungen seien nicht betroffen.
Diesen Donnerstag Nachmittag Statusbericht der Projektmitglieder über Arbeit (Fehler, Fortschritt, etc.) an Timo und David. Arbeitsblöcke bis morgen Abend abgeschlossen
haben.
Koordination Projektgruppe / BI Klausur
Es finden keine internen Powertreffen für die BI-Teilnehmer an folgenden Terminen statt:
Dienstag, 29.03.2011
267
A. Protokolle
Mittwoch, 30.03.2011
Das offizielle Meeting hingegen ist für alle Projektmitglieder obligatorisch. Siehe hierzu
den Punkt ’Folgetermin’.
Projektfortschritt
Zur Performance Optimierung und der Umsetzung eines merklich schnelleren Systems
wurde Multi-Threading eingeführt.
Daniel Stamer arbeitet aktuell am Adaptation Manager.
Sven und Alexander arbeiten am Content Repository / Agenten, insbesondere an kombinierten Lösungen wie Fahrrad und Bahn. Google Maps macht aktuell Probleme aufgrund
einer Anfragebegrenzung. Der WetterDotCom Provider ist nachwievor sehr unperformant, soll jedoch vor dem Erreichen des ersten Meilensteins kein Augenmerk mehr auf
Optimierung und Performance-Verbesserung gelegt werden. Dies könne ab April / Mitte
Mai geschehen. Jetzt sei zunächst Qualität und Refactoring wichtig.
Die Anbindung zum CRM wurde erfolgreich durch eine Library (lib) mit relevanten
Funktionalitäten umgesetzt. Ein JUnit Test existiert ebenfalls bereits.
Das Frontend ist weiter in Bearbeitung.
Zur Trennung von Geschäftslogik und Präsentation wurde ein MVC nachgebildet. Zudem existieren bereits vollständige Validierungen für die Schnittstellenzugriffe. Die Anbindung an die Services ist okay. Heute bis morgen wird die Routenplanung dargestellt.
Sonstiges
Zusammensetzung der Gesamt-Note der Projektgruppe wird noch mitgeteilt.
Folgetermin
Agenda Punkte werden unter anderem sein:
Einzelgespräche (Zwischenstand Seminarausarbeitungen), Terminabsprache für Treffen
im nächsten Semester
268
Das nächste Projektgruppenmeeting findet statt am 30.03.2011 um 12:00 s.t. im Raum
A04-3-319 statt. Moderator: Alexander Spennemann Protokollffürhrer: Daniel Stamer
269
A. Protokolle
Daniel Stamer
[email protected]
Moderation: Alexander Spennemann
Rückblick auf letztes Protokoll
Prototyp mit GUI-Unterstützung bis nächste Woche fertig. Einfache Ergebnisse werden
bereits dargestellt.
Projektstatus
AdaptationEngine
Optimierung der bestehenden Routen durch Permutation der Ergebnisse wurde implementiert.
ContentRepository
Die Web Service Schnittstelle wird momentan um eine RESTful API erweitert.
270
UserModelModule
Das CRM wurde eingehängt und die Schnittstelle wird momentan aktiv weiter entwickelt.
Gruppen-Organisation
Begleichungen der Strichliste für verspätetes Erscheinen. Verbindlichkeiten sollen nächste
Woche beglichen werden.
Auf Alexanders Vorschlag hin, wurde beschlossen Geldmittel an die Opfer der Erdbebenkatastrophe in Japan zu spenden. Es werden 50 Euro aus der Projektkasse gespendet.
Die Modulplanung wird doppelt ausgeführt. Zum einen im heutigen Treffen und im
Treffen nächste Woche.
Einzelgespräche
Terminplanung steht noch aus. Die Gespräche finden voraussichtlich in 3 Wochen statt
(KW 16, 18.04.2011-24.04.2011).
Sonstiges
Keine weiteren Punkte.
271
A. Protokolle
[email protected]
Anwesend: Huang, Kölpin, Petersen, Rummel, Schnieders, Spennemann, Stamer, Temgoua, von der Dovenmühle,Wei
Abwesend (entschuldigt): Mahnke
Protokoll des letzten Treffens
Das Protokoll des vorigen Treffens wurde vorgestellt und auf Vollständigkeit hin betrachtet.
Weiteres Vorgehen
Im Verlauf des Meilensteins A haben sich verschiedene Themenbereiche entwickelt, die
nicht direkt mit der Entwicklung von Jinengo zu tun haben. Diese Themen werden aber
mit hoher Wahrscheinlichkeit Einfluss auf die folgenden Meilensteine haben. Im Detail
hat sich zu den Themen folgender Sachstand entwickelt.
IBMFujitsu: Der Erstkontakt wurde von Timo und David auf der CeBIT hergestellt. Um den weiteren Verlauf des Kontakts kümmern sich beide. Ziel ist eine
Kooperation mit Projekten im Bereich Green-IT und Mobility.
OFFIS: Der Erstkontakt wurde hergestellt und eine Projektpräsentation vor Mitarbeitern des OFFIS durchgeführt. Hierbei hat sich die Thematik der erweiterten
Zielgruppendefinition ergeben. Ziel des Kontakts soll es sein, dass bisher nicht
betrachtete Zielgruppen wie z. B. die EWE angesprochen werden.
272
Deutsche Bahn: Die Deutsche Bahn (DB) hat sich bisher nicht kooperationsbereit gezeigt. Aus diesem Grunde müssen alternative Wege gefunden werden, Produkte und Dienstleistungen dieses Unternehmens in Jinengo zu integrieren. Dies
betrifft neben dem Bahnverkehr:
Car Sharing (DB): Alternative Möglichkeiten wären wie bei
Fahrräder (DB): eine eigene Datenbank, in der Standorte verzeichnet sind.
Frontend: Die Entwicklung eines Web-Frontends, dass verschiedenste mobile Zielplattformen erreicht, hat sich als aufwendiger dargestellt, als es anfänglich eingeschätzt wurde.
Daher werden weitere Kapazitäten für die Weiterentwicklung in den folgenden Meilensteinen benötigt.
Verschiedenes
Aufgrund des erfolgreichen Abschlusses des Meilensteins A wird ein ProjektgruppenTreffen der geselligen Art geplant. Als Termin hierfür wurde der 13.04.2011 ab 19:00
festgelegt.
Spende: Die Projektgruppe Jinengo hat aus internen Mitteln eine Geldspende an die
Japan-Hilfe durchgeführt. Die Überweisung wurde von Xin getätigt.
Einzelgespräche: Als Termin für die Einzelgespräche mit den Betreuern wurde der
20.04.2011 von 14:00 – 17:00 festgelegt.
273
A. Protokolle
Xin Huang
[email protected]
Anwesend: Huang, Kölpin, Petersen, Rummel, Schnieders, Spennemann, Stamer, von
der Dovenmühle,Wei
Abwesend (entschuldigt): Temgoua
Abwesend (unentschuldigt): Mahnke
Rückblick auf Meilenstein A
Die Ziele für den Meilenstein A wurden erfolgreich erreicht.
Die Vorgehensweise im Meilenstein A funktioniert gut.
Alle Rollen sind gut akzeptierbar.
Das intensive interne Powertreffen im März halten alle Teilnehmer für effektiv und
effizient. Im weiteren Verlauf soll aber die Koordination der einzelnen Entwicklungsgruppen berücksichtigt.
Einblick auf Meilenstein B
Einleitung
Die gesamte Infrastruktur wurde im Meilenstein A bereits realisert.
Die drei Bereiche sollen im Meilenstein B genau betrachtet: CRM, Datenanalyse,
Externe Interessenten.
274
Es wurde über das Thema Semantic kurz gesprochen, das bei der Anforderungsdefinition für den Meilenstein B detailliert diskutiert werden soll.
Zeitplan
Meilenstein A: Dezember - Ende März
Meilenstein B: April - Ende Juni
Meilenstein C: Juli - Ende August
Meilenstein D als Puffer: September
Darunter wird der Meilenstein B in 3 Phasen untergliedert.
Bis Ende April: Anforderungen
Bis Ende Mai: Entwurf und Dokumentation
Bis Ende Juni: Realisierung
Interviews
Um die neuen Anforderungen für den Meilenstein B bzw. auch für die weiteren Meilensteine zu definieren, werden im nächsten Meeting die Interviews mit den Betreuern
durchgeführt.
Sonstiges
Statt des wetterabhängigen Grillens feiert die Projektgruppe am Mittwoch, 13.04.2011
nach dem internen Treffen in der Kneipe Carls (Adresse: Artillerieweg 56, 26129
Oldenburg).
Beim nächsten Meeting muss jeder 10 Euro für unsere Projektkasse mitbringen.
275
A. Protokolle
Folgetermin
A04-3-319 statt. Moderator: Xin Huang Protokollffürhrer: Yi Wei
276
Svne Kölpin
[email protected]
Moderation: Yi Wei
Anwesend: Huang, Petersen, Rummel, Schnieders, Stamer, Wei, Temgoua, Mahnke,
Kölpin, Spennemann
Abwesend (entschuldigt): Schnieders, VDD
Organisatorisches
Einzelgespräche: Mittwoch, 11.05 ab 13 Uhr
Pro Person 20min
Benjamin schickt Mail mit Zeiten rum
Raum: Benjamins Büro
Pflichtenheft für Meilenstein B
CRM-Teil ist soweit fertig (zu klären: BI-Teil)
Frontend-Teil: Blackberry ausgeklammert, Weboberfläche die wie eine App aussieht, zu klären: J2ME und SMS-Service
Backend-Teil: fertig
277
A. Protokolle
Sonstiges
Weiteres Vorgehen wird im interenen Treffen besprochen
Weiteres Vorgehen für die Webseite wird im internen Treffen besprochen
Backend-Teil: fertig
Folgetermin
A04-3-319 statt. Moderator: Sven Kölpin Protokollführer: Carl Mahnke
278
Carl Mahnke
[email protected]
Moderation: Sven Kölpin
Anwesend: Huang, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Stamer, Temgoua, Wei
Abwesend (unentschuldigt): Spennemann
Allgemeines
Benjamin hat das Geld nicht dabei.
Review vom letzten Protokoll
Die Einzelgespräche sollen alphabetisch nach Nachnamen sortiert stattfinden. Sie finden
statt am Mittwoch, den 11.05.2011, ab13:00 Uhr. Benjamin wird hierzu noch eine Liste
per Mail rumschicken.
Timo wollte sich um den Jinengo-eigenen Server kümmern. Da Timo abwesend war blieb
der aktuelle Status ungeklärt.
279
A. Protokolle
Pflichtenheft - Diskusion und finales Review mit den Betreuern
CRM
David erklärt, dass nun ein ”Microsoft SQL-Server-Export” eingeplant ist. Ebenso ist
eine Rückkopplung für den Matchmaker (Hatchery) nun vorgesehen.
Benjamin beschließt, dass das Pflichtenheft am Freitag geschlossen wird. Die PG stimmt
zu. Bis dahin werden die Betreuer das Pflichtenheft (Meilenstein B) nochmal lesen.
Frontend
Der Frontendteil war noch nicht abgeschlossen, da Timo ausgefallen war. Ebenso muss
noch Davids Datenschutzrichtlinie integriert werden. Das Frontendteam erklärte sich
bereit den fehlenden Inhalt bis Dienstag 20:15 nachzutragen.
Backend
Zum Backend gab es keine Anmerkungen.
Sobald das Pflichtenheft komplett ist wird Marc eine Mail an die Betreuer senden.
Weiteres Vorgehen Entwurf (Gruppen? Wer macht was bis
wann?)
Sven fragt, ob die Modellierung so granular wie im ersten Meilenstein zu erfolgen hat. Es
stellt sich heraus, dass lediglich Änderungen bzw. enige wenige Ergänzungen gegenüber
dem Meilenstein A vorzunehmen sind. Die Anwendungsfalldiagramme sollen innerhalb
der Teams bearbeitet werden und weniger als eine Woche Zeit in Anspruch nehmen. Der
gesamte Entwurf soll bis Ende des Monats fertig sein.
Sonstiges
Benjamin erzählt vom DRL. Dort hat er in der Runde ”Automotive” das Jinengo-Projekt
vorgestellt. Prof. Lemmert war mit dabei. Die Schnittmenge zwischen den Jinengo und
280
dem Projekt ”AIM” sei sehr groß und das DRL könnte sich theoretisch vorstellen Jinengo mit einzubinden. Unklar ist bisher jedoch, wie offen die Plattform von ”AIM”
ist. Weiterhin verwies Benjamin auf die Probleme des Vorgängerprojektes STORM. Das
Problem von Storm ist, dass die Implementierung noch ein mal gemacht werden muss.
Das sollte Jinengo verhindern.
Des weiteren verwies Benjamin auf eine neue Professur an der Universität Oldenburg. Sie
wird zum 1. August besetzt und wird sich ”Intelligenten Transportsystemen” (embedded
systems) verschreiben. Für Jinengo könnte sich hieraus eine Zusammenarbeit enwickeln.
Der Termin mit der EWE hat bisher kein Feedback hervorgebracht. Benjamin will daher
den Martin Tröschel noch ein mal kontaktieren.
Sven fragt, ob die PG ein Präsent für den neugeborenen Sohn von Timo besorgen soll.
Die PG ist einverstanden. Veranschlagt wird eine Obergrenze von fünf Euro pro Person.
Carl hält das für zuviel. David ist beauftragt einen Stofftier-Pandabären zu besorgen.
281
A. Protokolle
Marc Petersen
[email protected]
Anwesend: Huang, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Temgoua,
Wei
Abwesend (entschuldigt): von der Dovenmühle, Stamer, Kölpin
Abwesend (unentschuldigt): Beginn der Meetings: 10:00 Uhr
Allgemeines
Eigentlich sollte Timo über den aktuellen Stand des Servers berichten, wegen seiner
Abwesenheit wird dies auf nächste Woche verschoben.
Anmerkungen zum Pflichtenheft
CRM
– David berichtet, dass fast alle Anmerkungen zum CRM ins Pflichtenheft aufgenommen wurden.
– Es ensteht eine Diskussion darüber, dass es sinnvoll wäre Soziale Netzwerke
ans CRM anzubinden und die gewonnenen Daten z.B. im Matchmaker zu
berücksichtigen.
Frontend
– Auf die Anmerkung, dass der volle Funktionsumfang abgebildet werden solle, antwortet Daniel Sch., dass der Funktionsumfang eigentlich vom Gerüst
”
dahinter“ kommen müsste.
282
– Betont wird hierbei die Einstellungsmöglichkeit für das eigene Fahrzeug, hierzu muss Sven zur Machbarkeit befragt werden.
– Es ensteht eine Diskussion über den Stand der Möglichkeit zur Bewertung
von Reisen und dass dies implementiert werden solle. Vor längerer Zeit wurde
schon mal besprochen, dass das Bewerten von Reisen ermöglicht werden solle,
die Bewertung sollte simpel und schnell für den Benutzer machbar sein.
– Es wird von Benjamin auch betont, dass die Darstellung der Routen gut strukturiert und lesbar sein muss und hier sicherlich einiges an Gerhinschmalz“
”
investiert werden müsse.
– Backend
* Das manuelle Klicken des Administrators hinsichtlich semantisch identischer Interessen ist nicht akzeptabel. (Zur Zeit 1.3.2 im Pflichtenheft)
Anwendungsfälle
Es werden die beiden neuen Anwendungsfälle vorgestellt, ersterer bzgl. des Abrufens
potentieller Fahrgemeinschaften wird von David erklärt und akzeptiert. Der zweite Anwendungsfall ist auf Grund der Anmerkung am Backend (siehe oben) obsolet.
Datenflussdiagramm: SQLServer und CRM
Yi und Xin schlagen vor, dass die zentrale Datenhaltung im SQL Server erfolgt und
stellen hierzu ein Datenflussdiagramm vor. Daraufhin wird über deren Vorschlag und
die Aufgabe, wo alle“ Daten gehalten werden können diskutiert. Größtenteils wird der
”
Vorschlag abgelegt, er bedarf einer Überarbeitung auf Basis dieser Diskusion und das
zu erweiternde BI-Werkzeug soll noch recherchiert werden. Allgemein wurde in der Diskussion noch mal klar gestellt, dass quasi alle Daten, die im CRM System gespeichert
werden auf Kunden bezogen sind.
Weitere Anmerkungen in der Diskussion waren, dass der User Model mindestens hierarisch, bestenfalls ontologisch sein soll.
283
A. Protokolle
Website und Multilanguage
Carl berichtet kurz über den aktuellen Multitlanguage Stand unserer Website. Benjamin
schlägt vor, dass alle Übersetzungen bis Ende diesen Monats abgeschlossen sind und alle
akzeptieren dies.
Tätigkeitsberichte
Carl wurde von Benjamin angesprochen, dass wir Tätigkeitsberichte schreiben sollen,
demzufolge spricht Carl dies nun an. Wir einigen uns darauf, dass in jedem internen
Meeting jeder zu Beginn des Meetings im Stehen vorträgt, was er in der vergangenen
Woche für die Projektgruppe geleistet hat. Zusätlich ist dies in schriftlicher Form (4-5
Spiegelstriche) von jedem im Repository zu hinterlegen.
Sonstiges
Carl schälgt vor, dass wir das Grillen nachholen. Alle sind einverstanden und wir haben
vorerst Mittwoch, den 25.05.2011 ab 19 Uhr festgehalten. Ob das Grillen tatsächlich
stattfindet wird von der Wetterlage abhängig gemacht und spätestens im internen Treffen
nächsten Dienstag besprochen.
284
David Rummel
[email protected]
Moderation: Alain Marcel Ngufack Temgoua
Anwesend: von der Dovenmühle, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Stamer, Spennemann, Temgoua, Wei
Abwesend (entschuldigt): Huang
Abwesend (unentschuldigt): Beginn der Meetings: 10:00 Uhr
CRM
Diskussion über die Speicherung des Usermodels mit Hilfe einer Ontologie im CRM
System. Benjamin möchte, dass ihm das CRM-Team ein ER-Modell der vorgeschlagenen
Hilfs-Datenbank, die die Ontologie enthalten soll, bis Freitag, 03.06.2011, zusendet.
Des Weiteren wird beschlossen, dass das CRM Team mit der Modellierung fortfährt
und dabei den Idealzustand modelliert, unabhängig davon, ob dies mit den genutzten
Technologien implementierbar ist.
Es wird entschieden, dass das CRM-Team bei connectiv nachfragt, ob das Ontologieproblem dort schon einmal gelöst wurde.
Website
Es wird festgelegt, dass die Website seriös bleiben soll, daher sind Spaßbeiträge auf
Facebook zu unterlassen.
Fotos sollen in einer Fotosektion auf jinengo.com veröffentlicht werden, facebook soll
zusätzlich genutzt werden, hierbei ist jedoch zu beachten, dass Fotos, von Personen, die
nicht auf Facebook erscheinen möchten, dort nicht veröffentlicht werden.
285
A. Protokolle
Dokumentation
Es wird festgestellt, dass bislang kein Benutzerhandbuch erstellt wird, bzw. nur in Teilbereichen (z.B Tutorial für Agentenentwickler). Die Erstellung eines solchen Handbuches
soll zeitnah beginnen.
Sonstiges
Die Anfrage an IBM bzgl. eines möglichen Hardwaresponsorings soll von Timo und David
zeitnah in die Wege geleitet werden. Benjamin erklärt sich bereit, Prof. Marx-Gomez zu
bitten, die eMail abzusenden, um ihr mehr Gewicht zu verleihen.
Benjamin hat noch eine abschließende Ergänzung zum Pflichtenheft. Es soll festgelegt
werden, dass das Gesamtsystem so nah wie möglich an die Einsetzbarkeit kommt.
Es wird diskutiert, dass die Gruppenaufteilung geändert wird, allerdings soll darüber
erst nach Beendigung des Designs diskutiert werden.
286
Daniel Schnieders
[email protected]
Handbücher
Es wird eine Vorlage für die verschiedenen Handbücher benötigt. Die Ausarbeitung der
Vorlage übernimmt Daniel Schnieders.
IBM
Timo und David entwickeln eine Anfrage an IBM bzgl. Sponsoring. Benjamin schaut
sich den Text an und gibt die Anfrage dann an Prof. Gomez weiter, welche die Anfrage
an IBM verschicken soll.
CRM – Semantic Ontology-based User Model
David hat das CRM – Semantic, Ontology-based User Model vorgestellt.
Ressourcen haben verschiedene Eigenschaften, welche in menschlich lesbarer Form
abgebildet werden, so kann man leicht im CRM danach filtern
287
A. Protokolle
Optinales Feld gibt eine Referenz zu einem CRM Kontakt an, somit behalten
wir die CRM-Tabelle aus dem CRM bei, welche den Kunden bereits ausreichend
abbildet
Die vorgestellte Lösung basiert auf dem relationalen Datenbankmodell, was schnelle Abfragen als Vorteil bietet
Abfragen mit dem CRM eigenem Tool wurden getestet, es ist grundsätzlich möglich,
jedoch nicht mehr ganz so intuitiv. Es ist ein höherer Aufwand zur Berichterstattung
nötig. Als Antwort werden Referenzen auf CRM eigene Kontexte wiedergegeben.
Zusammenfassung der Diskussion:
Yi hat die entworfene Ontologie vorgestellt, welche erweiterbar ist
Ammar hat angemerkt, dass Transportation noch erweitert werden sollte
Benjamin merkt an, dass er sich das Modell genauer anschauen möchte, um evtl.
einige Änderungen vorzuschlagen
Timo fordert jeden dazu auf, im Bereich der Ontologie mitzudiskutieren, um möglichst
viele Sichtweisen zu bekommen, da es sich nicht auf eine Technologie beschränkt
Die Statusberichte der Teams Frontend GUI, Backend GUI, Hatchery und CRM
sehen gut aus. Jedes Team ist voraussichtlich gut im Zeitplan
Die Integration von Facebook wurde etwas nach hinten gestellt and als weniger
wichtig empfunden
288
[email protected]
Anwesend: Huang, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Temgoua, von der Dovenmühle, Wei
Abwesend (entschuldigt): Stamer
Ontologie
Content Ontology und User Ontology müssen seperat betrachtet werden.
TotalCosts ist immer die Summe von Costs einer SubRoute (ändern). TotalDistance ist
immer die Summe von Distance einer SubRoute (ändern).
Sustainability nur anhand von CO2 berechnen und unterteilen in Emission und Consumption. EnergyEmission in EnergyConsumption (fossil-¿gas,benzin,...) umbenennen,
Berechnung muss transparent für User sein.
Location beinhaltet sowohl Longitude, Latitude als auch Name, und nicht Name alleine.
Frontend Reisebewertungsvorschlag
Wenn ein Nutzer eine Route gut bewerten möchte bewertet dieser die gesamte Route. Wenn ein Nutzer eine negative Bewertung abgeben möchte, sollen alle SubRouten
betrachtet werden können.
289
A. Protokolle
960 Grid (Layout Diskussion)
Neues Spaltenlayout wurde vorgestellt und akzeptiert
Sonstiges
Milestone 3: Facebookanbindung?
290
Daniel Stamer
[email protected]
Anwesend: Huang, Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Temgoua, von der Dovenmühle,Stamer, Wei
Deadline
Die Deadline wird per Mehrheitsentscheid vier Wochen nach hinten verschoben, um eine
einwandfreie Codebasis zu garantieren.
CRM Datawarehouse
Datawarehouse Konzept von Xin Huang und Yi Wei erarbeitet. Das periodisches Extrahieren und Analysieren von Kundenbezogenen Daten aus dem CRM zur Generierung
von gezielten Berichten soll um gesetzt werden. Dennoch soll zunächst getestet werden,
ob die Daten nur auf Nachfrage aus dem CRM gelesen werden können. Dieser Test soll
durch Lasttests auf einer laufenden CRM Instanz. Die Erstellung der Berichte wurde
getestet und ist mit wenig Aufwand zu schaffen.
Diskussion zu Kennzahlenmodellen
Das Berichtswesen muss auf Kennzahlensystemen basieren. Es wurde eine eingehende
Diskussion zur Bestimmung der Kennzahlen geführt, welche für das Jinengo System
291
A. Protokolle
relevant und kritisch sind.
Sonstiges
Es gibt keine weiteren Punkte.
292
Xin Huang
[email protected]
Moderation: Yi Wei
Anwesend: Huang, Mahnke, Petersen, Rummel, Schnieders, Temgoua,Wei
Abwesend (entschuldigt): Kölpin, Spennemann, von der Dovenmühle, Stamer
Diskussion zum Kennzahlenmodell
Das optimiertes Kennzahlsystem von Xin Huang und Yi Wei wurde diskutiert.Zwei neue
Verhältnis-Kennzahlen wurden ins System hinzugefügt.
Frontend
Daniel Schnieders hat das neue Layout für den Frontend vorgestellt. Die Teilnehmer hielten das Layout für schön. Es soll den Usern möglich sein, dass sie bei der Routenplanung
beim Frontend nicht nur Start- und Zielort, sondern auch z.B. ihre Favorites einstellen
können.
Backend (GUI)
Marc Petersen hat den Designstatus von Backend (GUI) vorgestellt. Ammar ist mit der
bisherigen Arbeit zufrieden.
293
A. Protokolle
Berichtswesen
Yi hat einen Bespielsbericht durch Selektion der Daten aus zwei Tabellen in BIDS vorgestellt.Mit der Berechnung der Kennzahlen wird in dieser Woche angefangen.
Sonstiges
294
Daniel Stamer
[email protected]
Moderation:
Anwesend: Huang, Kölpin, Mahnke, Petersen, Spennemann, Stamer, Temgoua, Wei
Abwesend (entschuldigt): von der Dovenmühle, Rummel, Schnieders
Diskussion zum Kennzahlenmodell
Die Diskussion über das Kennzahlen-System wurde fortgesetzt. Wünschenswert wäre
eine Berichtsübersicht in Form eines Dashboards.
Backend
Die Hatchery läuft soweit, allerdings gibt es momentan noch rücklaufende Entwicklungen in der Kernfunktionalität. Diese wird hauptsächlich durch die Ontologie-basierte
Anbindung an das CRM-System verursacht.
Frontend
Carl Mahnke erläutert Visualisierungsmöglichkeiten um die Nachhaltigkeit von konkreten Routen auf dem Web-Interface intuitiv darzustellen. Die Darstellungsmöglichkeiten
beinhalten grafische Elemente wie Farben, Ampeln (als Piktogramme) und verschiedene
Schriftformen und Effekte.
295
A. Protokolle
Sonstiges
296
Sven Koelpin
[email protected]
Anwesend: Kölpin, Mahnke, Petersen, Spennemann, Stamer, Wei, Schnieders, Rummel, Huang
Datenschutz
Webservice um Akzeptanz des Datenschutzes erweitern
Situation Timo
Marc wechselt ins Frontendteam um Timo zu ersetzen
Raumsituation
PG-Raum für das Powertreffen ist wieder der gewohnte Raum!
Powertreffen
Daniel u. David: CRM-Anbindung, Matchmaker, Testdaten für Kunden
297
A. Protokolle
Sven: Webservice erweitern (Datenschutz, UserModelModule, Darstellungspräferenzen)
Daniel S., Carl, Marc: Routendarstellung
Daniel Zweite Instanz der Head-Rev. für Marc
David u. Alex: Testdaten für Kunden
Xin: DW für Reporting
Frontend-Adaptierung
Für unser Frontend wird Stretchtext, Annotations und Page Fragments benutzt.
Ontologien
Alles ist langsamer geworden. Eventuell das CRM doch nochmal lokal installieren?
298
Marc Petersen
[email protected]
Anwesend: Mahnke, Petersen, Spennemann, Wei, Schnieders, Rummel, Huang, Nguefack
Abwesend (entschuldigt): von der Dovenmühle, Stamer, Kölpin
CRM-Frontend-Verbindung
Daniel Sch. stellt den technischen Fortschritt im Frontend vor. Mittlerweile gelangen die
Daten aus dem CRM über das Backend zu Frontend, sowie umgekehrt, sind im Frontend
änderbar und werden zur adaptiven Darstellung genutzt.
Adaptive Frontend
Carl und ich stellen das Design für die Routenansicht vor, welches wir entworfen und
größtenteils schon implementiert haben.
Routenbewertung
Carl stellt stichpunktartig die Folien zur Routenbewertung vor und das ein Großteil
davon in den nächsten Meileinstein verschoben wurden. Eigentlich stammen die von
Daniel St. und können aufgrund seiner Abwesenheit heute nicht ausführlich behandelt
werden.
299
A. Protokolle
Ammar merkt an, dass die Routenbewertung schon ziemlich wichtig ist, wir am besten
jedoch einfach nur simple Dummies implementieren und dafür Wert auf die Offenheit
bzgl. der Community legen.
Sonstiges
Xin stellt die Fortschritte zum Data Warehouse vor und Ammar findet diese sehr gut.
In einer kurzen Diskussion über den Fortschritt in diesem Meilenstein, stellt sich heraus,
dass es im Allgemein gut aussieht, das Reporting im CRM aber eventuell noch ein wenig
Zeit benötigt.
Anschließend zeigt Carl noch kurz den aktuellen Stand in einer Live Demo.
Zum Abschluss macht Carl noch Anmerkungen, dass wir uns in ferner Zukunft noch
mal Gedanken über ein Social Event machen sollten, z.B. wenn wir den Meilenstein
abgeschlossen haben. Weiterhin regt Carl noch dazu an, dass wir mal wieder spenden
sollten, z.B. nach Somalia.
300
Marcel Temgoua
[email protected]
Anwesend: Petersen, Wei, Schnieders, Mahnke, Huang, Nguefack
Abwesend (entschuldigt): Blockvorlesung , Spennemann, Stamer, Kölpin, Rummel
Meilenstein: Status
da die geplante Aufgabe in Meileinstein B bei manche Teamgruppe nicht vollständig
implementiert wurde oder Teile ausgenommen wurde wegen ZB. nicht mögliche Umsetzung, Das System nicht dafür geeignet ist oder lohnt es sich nicht mehr wegen igendwelche
Grunde zu implementieren, ist es irgendwie schwierig den Meileinstein C zu definieren.
Darauf ist es dazu gekommen, dass alle Teamgruppe nicht implementierte Aufgabe und
den Grund dokumentieren sollen.
Powertreffen
hier wurde keine Entscheidung getroffen. da es nur 6 Mitglieden anwensend gab
Routenbewertung
aufgrund von Abwesenheit von Daniel St. wurde es auf nächste Woche verschoben.
301
A. Protokolle
JQueryMobile und Frontend
der aktuellen Stand der Frontend soll in JQueryMobile umgesetzt werden, wobei eine
Abstimmung mit Timo noch nächste Woche durchgeführt werden soll.
Endpräsentation
es soll in Endpräsentation Projektvorstellung und Produktvorstellung eindeutig getrennt
werden und den Inhalt werden wir in dem kommenden Meeting noch mal diskutieren.
ob wir eigenlisch eine Video brauchen oder nicht. wenn ja wo sollen wir es anwenden.
CRM Team
Xin hat DWH für das CRM Team vorgestellt und nach Benjamin soll noch die KPI in
CRM nicht als Report sondern als Daten zurückgespielt werden.
Social Event
das Social Event soll voraussichlich am Mittwoch den, 17.08.2011 stattfinden und darüber
wird noch nächste Woche diskutiert.
302
David Rummel
[email protected]
Moderation: Marcel Nguefack Temgoua
Anwesend: von der Dovenmühle, Huang, Kölpin, Mahnke, Nguefack Temgoua, Petersen, Rummel, Schnieders, Stamer, Wei
Abwesend (entschuldigt): BUIS Blockveranstaltung: Spennemann
Was wurde in Meilenstein B nicht geschafft?
Admin GUI: Starten/Stoppen von Agenten im Frontend
CRM: Marketingkampagne umsetzen
Vorgehensweise Meilenstein C
Feature Freeze ab Ende August
Anforderungen aus nicht erfüllten Anforderungen Meilenstein B definieren
September muss für Präsentation und Dokumentation reserviert bleiben
Neue Anforderungen CRM
Was gibt es für alternative Marketing Aktivitäten / Social CRM
Snippets im Frontend
konkrete / komplexere Anwendungsfälle für BI (optional)
303
A. Protokolle
Neue Anforderungen GUI
Umstellung auf ASP.NET MVC3 und jQuery Mobile
Neue Anforderungen Hatchery
Codequalität erhöhen
J2ME Client updaten (optional)
SDK bauen
Powertreffen
Powertreffen finden vom 15.08. - 17.08. statt
Modul Entrepreneurship
Das Projekt kann im Rahmen des Moduls Entrepreneurship bei Prof. Dr. Fichter als
Beispielunternehmung genutzt werden
Social Event
Das nächste Social Event findet am 17.8. um 19 Uhr statt. Bei schönem Wetter wird an
der Uni gegrillt, sonst Treffen im Marvins
Spende Somalia
Am Ende der Projektgruppe wird übriggebliebenes Geld an Somalia gespendet.
304
Alexander Spennemannl
[email protected]
Moderation: Marcel Nguefack Temgoua
Anwesend: von der Dovenmühle, Huang, Kölpin, Mahnke, Nguefack Temgoua, Petersen, Rummel, Schnieders, Stamer
Abwesend (entschuldigt): Wei
Social CRMl
Das Konzept ’Snippets’ für Meilenstein C wurde vorgestellt. Es beinhaltet die Programmierung von Agenten sowohl von Jinengo Seite als auch seitens Dritter/Anbieter,
welche je nach aktuellem Kontext und Nutzern Sustainability Messages / Strings über
einen Webservice anzeigen. Die Agenten bieten jeweils um einen Werbeplatz. Diejenigen
Parameter eines Agenten, die am wichtigsten sind, werden am höchsten beworben oder
entsprechend niedriger beziehungsweise gar nicht. Ein Auktionator-Agent entscheidet
hierbei über denjenigen Agenten, der letztlich den Werbeplatz zugesprochen bekommt.
Ergebnisverwertung/Zukunftsperspektivel
Als eine weitere Betrachtung von Jinengo nach Abschluss des studentischen Projekt
könnte ein junges Start-Up erwogen werden, sofern sich genug Mitwirkende finden. Ehemalige Investmentbanker mit eigener Unternehmensberatung (http://www.ifridge.com)
könnten hierbei als Investoren fokussiert werden. Weiterhin kann der EWE Kontakt weiterverfolgt werden. Eine Marktanalyse und eine Kalkulation sind hierbei unumgänglich.
Im Redmine WIKI findet sich zum Thema Entrepreneurship eine Seite, auf der Meinungen zu einm Start-Up geschrieben werden können und diese Perspektive weiter diskutiert
werden kann.
305
A. Protokolle
Social Event
Eine konkrete Absprache über ein weiteres Social Event findet während der Powertreffen
statt.
306
Daniel Stamer
[email protected]
Moderation: Alexander Spennemann
Anwesend: von der Dovenmühle, Huang, Kölpin, Mahnke, Nguefack Temgoua, Petersen, Rummel, Stamer, Wei
Abwesend (entschuldigt): - Schnieders
Abwesend (unentschuldigt):
Vorstellung des Data Warehouse
Vorstellung der Umsetzung des Data Warehouse Konzepts durch Xin Huang.
Vorstellung des Messaging Dienstes
Vorstellung des Konzepts und der Umsetzung des Messaging Dienstes durch David Rummel.
Vorstellung des SDK
Vorstellung des Inhalts und der Vorgehensweise in der Entwicklung mit dem Jinengo SDK durch Daniel Stamer. Zusätzlich sollten noch die Messaging Agenten im SDK
berücksichtigt werden.
307
A. Protokolle
Vorstellung der J2ME Anwendung
Die J2ME Anwendung ist wieder lauffähig. Vorstellung im Emulator durch Sven Kölpin.
Vostellung des Web Frontends
Vorstellung des aktuellen Standes des Web Frontends durch Marc Petersen. Hier ist
eventuell eine Anleitung nötig. Es existieren mehrere View im Frontend, welche sich
nicht explizit an das Konzept des MVC-Pattern halten. Diese sollten refactored werden.
308
Daniel Schnieders
[email protected]
Anwesend: Huang, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Stamer, Wei
Abwesend (entschuldigt): Kölpin, Temgoua, von der Dovenmühle
Abwesend (unentschuldigt):
Feature Freeze
Feature Freeze wurde von Daniel kurz erläutert und als nun gültig beschlossen.
Benjamin erläutert den Unterschied zwischen der Endpräsentation vor Prof. Marx
Gomez und eingeladenen Gästen und der Präsentation bei der Vorstellung der
neuen Projektgruppen.
Ein möglicher Termin wäre Freitag der 30. September (11Uhr; 14-15 Uhr). Hierfür
muss abgeklärt werden, ob Prof. Gomez an diesem Termin Zeit hat.
Weiterhin benötigen wir eine Liste an Personen, welche wir einladen möchten.
Zusätzlich müssen wir uns darum kümmern, dass wir einen größeren Raum bekommen.
Carl wurde damit beauftragt, ein kleines Video für die Homepage zu erstellen.
Weiterhin soll Carl die Anwendung in einer guten Art und Weise auf der Homepage
einbinden. Ein Beispiel hierfür wäre die Einbindung in ein HandyDesign.
Alex wurde damit beauftragt das Jinengo Mobile Android 2.2 App fertigzustellen.
Nachfolgend soll die App auf der Webseite bereitgestellt werden.
GPS Tracking wurde als Problem angesehen. Wir wissen im Endeffekt nicht, welche
Route der Benutzer wirklich benutzt hat.
309
A. Protokolle
Die Dokumentation muss auf Lücken geprüft werden. Daraufhin müssen todo’s
erstellt werden.
David hat erläutert wie der User personalisierte und unpersonalisierte Nachrichten
/ Werbung bekommen kann.
Daniel Stamer möchte die Endpräsentation in Etappen aufbauen.
Marc erstellt eine Doodle Umfrage zum Thema Grillen.
310
[email protected]
Anwesend: Kölpin, Mahnke, Petersen, Rummel, Schnieders, Spennemann, Stamer,
Temgoua, von der Dovenmühle,Wei
Abwesend (entschuldigt): Huang
Allgemein
Einladungsliste: Die einzuladenden Personen für die Abschlusspräsentation müssen
angeschrieben werden. In einer Liste (verfasst von Benjamin, Pflege durch die Projektgruppe wahrgenommen von Timo) werden diese Personen aufgeführt. Die Liste
muss bis nächste Woche finalisiert werden, damit die Einladungen zeitnah versendet werden können.
Einladungstext: Der Einladungstext wird bis zum nächsten Treffen durch Timo
vorbereitet.
Raumbüro: Sven Kölpin setzt sich mit dem Raumbüro in Verbindung, um einen
Raum für den 12.10.2011 mit einer Kapazität von 50 Personen zu reservieren.
Ergebnis: A05 0-054 für den 12.10.2011 von 15-16 Uhr.
Video
Das Video von Carl wurde besprochen. Die Reaktion war sehr positiv. Die Positionierung
auf der Startseite vereinfacht die Kommunikation mit externen Personen über Sinn und
Zweck von Jinengo. Der Stil des Videos entspricht den Anforderungen an eine gute
Endkundenansprache.
311
A. Protokolle
Präsentation
Es wurde beschlossen, dass die Endpräsentation durch Daniel Stamer und Timo durchgeführt wird. Beide sind für das grundlegende Konzept verantwortlich. Das Präsentationskonzept
wird den Projektgruppenmitgliedern vorgestellt. Die Gewichtung verschiedener Aspekte
wird im folgenden Treffen besprochen.
Probleme und Herausforderungen
Folgende Probleme und Herausforderungen bestehen aktuell im Projekt:
Die Administrationsoberfläche deckt noch nicht alle Funktionalitäten ab.
Die Benutzerverwaltung muss angepasst werden.
Die CRM-Verbindung ist noch nicht vollständig implementiert
Das Vorgehen zur Adaption neuer Agents ist teilweise offen.
Einzelgespräche
Die Betreuer führen die Einzelgespräche mit den Projektgruppenmitgliedern am Dienstag, den 13.09.2011 durch. Folgende Termine wurden festgelegt:
1. 08:00–08:15: David Rummel
2. 08:15–08:30: Xin Huang
3. 08:30–08:45: Sven Kölpin
4. 08:45–09:00: Carl MAhnke
5. 09:00–09:15: Alain Marcel Ngufack Temgoua
6. 09:15–09:30: Marc Petersen
7. 09:45–10:00: Daniel Schnieders
8. 10:00–10:15: Alexander Spennemann
9. 10:15–10:30: Daniel Stamer
312
10. 10:30–10:45: Timo von der Dovenmühle
11. 10:45–11:00: Yi Wei
313
B. Seminararbeiten
nicht fertig.
315
Grundlagen zum Einsatz von elektronischen
Customer Relationship Management Systemen
(eCRM) in Marketing, Vertrieb und Service –
am Beispiel von Microsoft Dynamics CRM
Xin Huang
[email protected]
Zusammenfassung Unternehmerisches Denken und Handeln orientieren sich bereits immer an den Aufbau und Erhalt einer langfristigen
profitablen Kundenbeziehung. Gleichzeitig erweitern neue Informationsund Kommunikationstechnologien die bestehenden Wege bei der Gestaltung von Kundenbeziehung. Electronic Customer Relationship Management (eCRM) stellt eine Modifikation des klassischen CRM-Begriffs dar,
dass das CRM um eine elektronische Komponente durch Unterstützung
neuer Technologien erweitert wird. Der folgende Beitrag zielt darauf ab,
Einsatz von eCRM-Systemen im Marketing, Vertrieb und Service am
Beispiel der Standardsoftware Microsoft Dynamics CRM zu untersuchen,
und gliedert sich in 5 Kapiteln. Nach der Einführung werden die Grundlagen zu eCRM-Systemen im zweiten Kapitel präzisiert. Die aus Sicht
dieser Arbeit wichtigen Themen der eCRM-Systeme werden in diesem
Kapitel diskutiert. Den Schwerpunkt des dritten Kapitels stellt die Untersuchung von Microsoft Dynamics CRM hinsichtlich ihres Einsatzes
im Marketing, Vertrieb und Service dar. Die Beispielsstandardsoftware
Microsoft Dynamics CRM wird am Anfang dieses Kapitels einführend
vorgestellt. Das vierte Kapitel widmet sich, das Thema über Erweiterungen für Microsoft Dynamics CRM zu behandeln. Dieser Beitrag schließt
sich mit einer kurzen Zusammenfassung und einem Fazit.
Schlüsselwörter eCRM, eCRM-System, Microsoft Dynamics CRM,
Marketing, Vertrieb, Service, Erweiterungen
316
Einführung
In den letzten Jahren hat sich gezeigt, dass das Kundenbeziehungsmanagement eine
deutlich höhere wahrgenommene Bedeutung für die Steigerung der Kundenorientierung
zuerkannt wird, die eine Voraussetzung für die dauerhafte Sicherung der Wettbewerbsvorteile der Unternehmen darstellt. Die Aufgaben, Kundenbeziehungen gezielt abzubilden, zu vertiefen und langfristig zu pflegen, werden in der Unternehmenspraxis als Customer Relationship Management (CRM) bezeichnet. Wird das bestehende CRM durch
die neuen Möglichkeiten moderner Informations- und Kommunikationstechnologien um
eine elektronische Komponente erweitert, kommt es zu einer Modifikation des klassischen
CRM-Begriffs zum Electronic Customer Relationship Management (eCRM). [18, S.89]
Unter dem Schlagwort eCRM sind die Unternehmen bestrebt, die Kunden über verschiedenste Kommunikationskanäle, möglichst personalisiert und bedürfnisorientiert zu
behandeln, um auf diese Weise die Orientierung an langfristigen Kundenbeziehungen zu
erhöhen und schließlich den dauerhaften Unternehmenserfolg zu erreichen und sicherzustellen. [19, S.30]
Im Rahmen der Projektgruppe Sustainable CRM für Elektromobilität-Services mit
”
SOA“ wird eine Software entwickelt, die eine individuelle nachhaltige Routenplanung
ermöglicht und die Kunden- und Verbindungsanfragen im Sinne des CRM betrachtet.
Diese Software soll mit mindestens einem customized eCRM-System angebunden werden.
Die Kundenbezogenen Daten werden in diesem eCRM-System gehalten und verwaltet,
das Ansätze für ein Kundenbeziehungsmanagement unter Gesichtspunkt der Nachhaltigkeit integriert.
Die vorliegende Arbeit wurde in der Seminarphase der Projektgruppe verfasst. Diese Seminararbeit zielt erstens darauf ab, Einsatz von eCRM-Systemen im Marketing, Vertrieb
und Service zu untersuchen. Es wird in der Arbeit anhand des Beispiels der Standardsoftware Microsoft Dynamics CRM ausgeführt. Darüber hinaus wird das Thema über
das Customizing dieser Softwareanwendung am Rande behandelt.
Grundlagen zu eCRM-Systemen
In diesem Kapitel sollen die theoretischen Grundlagen zu eCRM-Systemen aufgezeigt
werden. Zunächst werden die Themengebiete CRM bzw. eCRM anhand der Definition der Begrifflichkeit einführend erläutert. Anschließend wird das eCRM-System im
Abschnitt 2.2 in Bezug auf Aufgaben, Klassifikation, Architektur sowie Vorteile usw.
317
betrachtet.
Einführung in CRM und eCRM
Die Unternehmen im heutigen Wirtschaftsleben sind durch verschiedene wettbewerbsstrategische Herausforderungen gezwungen, dem Aufbau und Erhalt einer langfristigen
Kundenbeziehung eine hohe Priorität im unternehmerischen Denken und Handeln zuzuweisen. Es ist heute zweifellos, dass die Kundenbeziehung einen der wertvollsten und
dauerhaftesten Wettbewerbsvorteile eines Unternehmens darstellt. [19, S.30] Als ein unternehmensweit integrierendes Führungs- und Organisationsprinzip umfasst das Kundenbeziehungsmanagement (CRM) alle Maßnahmen, langfristig profitable Kundenbeziehungen aufzubauen, aufrecht zu erhalten und zu penetrieren.
In der Literatur finden sich zahlreiche unterschiedliche Auffassungen über und Definitionen von CRM. Als Beispiel wird hier die Definition von Shaw zitiert: Customer
”
relationship management is an interactive process for achieving the optimum balance
between corporate investments and the satisfaction of customer needs to generate the
maximum profit.“ [20, S.23] Im Jahr 2000 hat das DDV (Deutscher Direktmarketing Verband e.V.) eine merkmalbezogene umfassende Definition von CRM erarbeitet: CRM ist
”
ein ganzheitlicher Ansatz zur Unternehmensführung. Er integriert und optimiert auf der
Grundlage einer Datenbank und Software zur Marktbearbeitung sowie eines definierten
Verkaufsprozesses abteilungsübergreifend alle kundenbezogenen Prozesse in Marketing,
Vertrieb, Kundendienst, Forschung und Entwicklung, u.a. Zielsetzung von CRM ist die
gemeinsame Schaffung von Mehrwerten auf Kunden- und Lieferantenseite über die Lebenszyklen von Geschäftsbeziehungen.“ [21, S.307]
Der Begriff des eCRM wird durch das CRM mit der Unterstützung der IT geprägt.
Sowohl in der Fachwelt als auch im kommerziellen Bereich wird dieser Begriff nicht
eindeutig definiert. Eggert und Fassot haben daraus zwei grundlegende Interpretationen
festgestellt:
eCRM in engerer Sichtweise als Ergänzung im Instrument der Marketingfunktion.
Demnach beschäftigt sich eCRM mit den elektronischen Möglichkeiten des Mana”
gements von Kundenbeziehungen.“ So ist das Neue am eCRM durch die spezifische
Kopplung zwischen Kundenbindung und den neuen Möglichkeiten im Bereich der
kundenorientierten Informationssysteme repräsentiert. [22, S.308]
eCRM in weitergehender Sichtweise als umfassende Unternehmensphilosophie. In
diesem Sinne stellt eCRM die Ausrichtung des Unternehmens auf den Kunden, die
”
318
ohne informationstechnologische Unterstützung nicht zu realisieren ist“ dar. [23,
S.4]
Diese beiden eCRM-Konzeptionen zielen gemeinsam darauf ab, Kundenorientierung des
Unternehmens zu steigern, wodurch ein dauerhafter Unternehmensprofit ermöglicht werden soll. Integriert haben Eggert und Fassot den eCRM-Begriff folgendermaßen definiert:
eCRM umfasst die Analyse, Planung und Steuerung der Kundenbeziehungen mit Hil”
fe elektronischer Medien, insbesondere des Internet, unter dem Ziel einer umfassenden
Ausrichtung des Unternehmens auf ausgewählte Kunden.“ [24, S.5]
Bei der Definition gilt es zu betrachten, ob eCRM ausschließlich durch ein internetfähiges
CRM repräsentiert werden kann. Forrester Research hat eCRM als A Web-centric ap”
proach to synchronizing customer relationships across communication channels, business
functions, and audiences.“ definiert. [25] Jedenfalls setzen zwar die Netzwerktechnologien Unternehmen in die Lage, umfangreiche Interaktionen mit Kunden zu pflegen,
andererseits ermöglichen es weitere modernen Computertechnologie sowie der Datenverarbeitung und -verwaltung aber auch, mehr über den Kunden zu erfahren und so den
Kontakt zu diesem zu vertiefen, um die Erschließung und Ausschöpfung von Kundenpotentialen zu sichern bzw. zu verbessern. [19, S.43f.]
So verstanden bringt eCRM bestehendes Wissen über den Kunden eines Unternehmens mit Hilfe technologischer Möglichkeiten in ein modernes und kraftvolles Führungsund Organisationsprinzip. Um dies zu realisieren, haben Schögel und Schmidt ein Phasenmodell zum erfolgreichen Management von Kundenbeziehungen im Umfeld neuer
Informations- und Kommunikationstechnologien entwickelt, das dabei unterstützen kann,
den ganzen eCRM-Prozess in einzelne Teilschritte zu unterteilen und so die verschiedenen
Aktivitäten des eCRM zu systematisieren, zu koordinieren und an der Unternehmensstrategie ausgerichtet zu integrieren. [19, S.31]
Bei diesem Phasenmodell, das in der Abbildung B.1 veranschaulicht wird, handelt es
sich um ein dreistufiges Schema, das aus den Phasen Identifikation, Selektion und Interaktion sowie den parallel zu diesen Phasen verlaufenden Komponenten IT-Systeme
und Integration besteht. Die erste Phase der Identifikation zielt grundsätzlich darauf
ab, Daten und Informationen über Kunden, Märkte und relevante Rahmenbedingungen
zu erfassen. In der zweiten Phase der Selektion sind zunächst aktuelle und potenzielle
Kunden entsprechend ihrem Kundenwert und ihren Bedürfnissen zu differenzieren und
anschließend die Kundenbeziehungen entsprechend abzubilden. Nach diesen zwei Phasen,
in welchen die Voraussetzungen für ein erfolgreiches eCRM geschaffen werden, lässt sich
in der Interaktionsphase eine profitable Anbieter-Kunden-Beziehung gestalten. Die Aufgaben des Unternehmens in dieser Phase bestehen darin, das Leistungsspektrum an den
319
Abbildung B.1.: Phasenmodell des eCRM [19, S.46]
Bedürfnissen der Kunden auszurichten, deren Vertrauen zu gewinnen und ihnen durch
kundenspezifische Aktivitäten einen Mehrwert zu bieten. Ziel dabei ist, die drei Faktoren
Mehrwert, Vertrauen und Transaktionen so zu optimieren, dass eine idealtypische Wirkungskette aus diesen Faktoren realisiert wird. Die integrierten IT-Systeme unterstützen
alle Beteiligten über alle drei Phasen wirkungsvoll, indem sie die notwendigen Informationen und Instrumente im richtigen Umfang, mit der richtigen Qualität, in der richtigen
Menge, zur richtigen Zeit und am richtigen Ort zur Verfügung stellen. [19, S.45ff.]
eCRM-Systeme
Nachdem die Grundbegriffe und die Konzepte des CRM sowie eCRM im letzten Abschnitt beschrieben wurden, handelt es sich im Folgenden um die Grundlagen der eCRMSysteme.
Einführung in eCRM-Systeme
Bis vor ca. 20 Jahren wurden normalerweise ausschließlich die Abkürzungen VIS (Vertriebsinformationssystem) und SFA (Sales-Force-Automation), die in erster Linie die
Vertriebs- und Außendiensttätigkeiten in der Unternehmenspraxis unterstützen, rationalisieren und überwachen, bei der Diskussion um das eCRM-System betroffen. Seit den
320
letzten zehn Jahren kommt es zu einer Wandlung, dass die weiteren kundennahen Bereiche des Unternehmens bspw. Marketing, Key-Account-Management und Service in den
Fokus des eCRM-Systems eingezogen werden. [26, S.201]
Ein eCRM-System hat heutzutage im Wesentlichen folgende Aufgaben: [27, S.363]
Synchronisation und operative Unterstützung der zentralen Customer Touch Points
Einbindung aller Kommunikationskanälen zwischen Unternehmen und Kunden
Zusammenfassung und Auswertung aller Kundeninformationen
eCRM-Systeme können nach Kunden- oder Unternehmensperspektive unterschiedlich
klassifiziert werden. Aufgrund der Tatsache, dass dem Kunden gewisse Aktivitäten (z.B.
Erfassung der Daten oder Steuerung der Kampagnen) nicht erkennbar sind, ist die Unterteilung von Kundensicht nicht schlüssig möglich und daher nicht sinnvoll. Im Gegensatz
dazu ist die Klassifikation nach Unternehmenssicht umfassender. Daraus ergeben sich
wiederum zwei Unterscheidungen nach
selektiven Systemen, welche lediglich spezielle Teilprozesse und bestimmte Aufgaben unterstützen und
integrierten Systemen, wobei der komplexe CRM-Prozess berücksichtigt wird und
die Teilprozesse zusammengeführt werden.
Die Implementierung der selektiven Systeme ist in der Regel einfacher und schneller,
während eine umfassende Lösung bei integrierten Systemen oft zu teuer und nicht notwendig wäre. Jedoch bringen die selektiven Systeme als Insellösung die Nachteile insbesondere bezüglich der Daten und Informationen über Kunden mit sich, wie z.B. keine
vereinheitliche Datenhaltung, und sodurch unvollständige, veraltete sogar falsche Informationen über Kunden usw. Solche Probleme sollten durch die Verwendung von integrierten Systemen reduziert sowie behoben werden. [28, S.124ff.]
Die Komponenten der integrierten Systeme werden im folgenden Abschnitt näher erläutert.
Architektur der eCRM-Systeme
Im vorherigen Abschnitt wurde die integrierte Aufgabenstellung der eCRM-Systeme genannt. Um solche Aufgaben zu unterstützen, werden die Systeme in zwei zentrale Bereiche unterteilt, welche ständig in einer engen Beziehung zueinander stehen. In der
321
Abbildung B.2.: Architektur der eCRM-Systeme [27, S.364]
Abbildung B.2 wird die Architektur der eCRM-Systeme mit ihren Komponenten veranschaulicht.
Operatives CRM Operatives CRM umfasst alle Funktionsbereiche, die direkten Kontakte mit Kunden stehen (Front Office: Marketing, Vertrieb und Service), und dient
zur gesamten Steuerung und Unterstützung aller Customer Touch Points, Kommunikationskanäle und deren Synchronisation. Neben den strukturierten Informationen einer Kundendatenbank werden die unstrukturierten Informationen in Form
von Text, Bild, Video usw. ergänzend mit dem Einsatz der Content-ManagementSysteme integriert und zur Unterstützung der CRM-Prozesse zur Verfügung gestellt. Die vorhandenen Back Office-Lösungen werden angebunden, um verlässliche
Aussagen über z.B. Verfügbarkeit der Liefertermin usw. machen zu können.
Analytisches CRM Im Aufgabenbereich des analytischen CRM werden die Kundendaten (Kundenkontakte und Kundenreaktionen) systematisch in Data Warehouse
aufgezeichnet und zur kontinuierlichen Optimierung der kundenbezogenen Geschäftsprozesse
mit OLAP und Data Mining ausgewertet. Somit wird eine sog. Closed Loop Architecture aufgebaut, in der Kundendaten systematisch genutzt werden, um die
Maßnahmen des Kundenbeziehungsmanagement auf fein differenzierte Kundenwerte und -bedürfnisse stetig zu verbessern. [27, S.363f.]
322
Vorteile der eCRM-Systeme
Die eCRM-Systeme bieten durch die modernen IT-Technologien und die mit ihnen eng
verbundenen elektronischen Medien eine Reihe von Vorteilen gegenüber den traditionellen CRM-Systemen. [29]
Höhe Verfügbarkeit und aktuelle Daten Elektronische Medien weisen im Vergleich zu
den klassischen Kommunikationskanälen (z.B. Telefonie) eine sowohl zeitliche als
auch räumliche höhere Verfügbarkeit auf. Mehr Daten können schneller und aktueller ausgetauscht werden.
Breite Integration und maximale Flexibilität Im eCRM-System sind verschiedenste Interaktionen und Kanäle zu integrieren, was dem Unternehmen ein einheitliches
Bild gegenüber dem Kunden (One Face to the Customer) ermöglicht. Die Anwender können über jeden beliebigen Internetzugang auf ein webfähiges eCRM-System
sowie auf die Daten zugreifen. Der weitere Flexibilitätsvorteil ergibt sich aus der
Möglichkeit, neuen oder bereits aktiven Anwendern zusätzliche Funktionalität zur
Verfügung zu stellen.
Weitergehende Automatisierung Viele Prozesse lassen sich im eCRM-System mithilfe
der IT-Technologien automatisieren.
Einfache Individualisierung Die Personalisierung von Informationen und Angeboten wird
wesentlich vereinfacht, indem sie nach einmaliger Konzeption und Umsetzung ohne
weiteren großen Aufwand durchgeführt werden kann.
Geringe Kosten Integration und Automatisierung stellen für das eCRM-System ein
großes Potential zur Kosteneinsparung dar. Zudem können Installations- sowie
Wartungsaufwand reduziert sogar ggf. vermieden werden.
Am aktuellen Markt ist die Anzahl der Anbieter von eCRM-Lösungen zwar sehr groß,
jedoch hat jedes Produkt sein spezifisches Anwendungsgebiet und Funktionalität sowie
seine Stärken und Schwächen. Der Marktanteil des jeweiligen Produktes unterscheidet
sich je nach der Unternehmensgröße und dem Einsatzgebiet stark. Die großen Systemanbieter sind bspw. Microsoft, SAP, Oracle usw. Im folgenden Teilen dieses Beitrags wird
die eCRM-Lösung von Microsoft, der Marktführer für Großunternehmen und Mittelstand
im Jahr 2010, vorgestellt. [30]
Einsatz von Microsoft Dynamics CRM
Nach der Vermittlung der zu grundlegenden Erkenntnisse des eCRM sowie der eCRMSysteme wird nachfolgend in diesem Kapitel Microsoft Dynamics CRM als Beispiel für
323
eCRM-Lösungen detailliert vorgestellt. Zunächst wird im Abschnitt 3.1 ein Überblick
über die Produkteigenschaften von Microsoft Dynamics CRM gegeben. Daran anschließend wird sein Einsatz im Bereich Marketing, Vertrieb und Service jeweils in den Abschnitten 3.2 bis 3.5 erläutert. Zum Schluss dieses Kapitels wird auf die mobilen Erweiterungen für Microsoft Dynamics CRM näher eingegangen.
Überblick über Microsoft Dynamics CRM
Microsoft Dynamics CRM, ein Teil der Marke Microsoft Dynamics für die Automatisierung der verschiedenen Operationen wie Finanzanalyse, Verwalten von Zuliefern,
Fertigung, Personalwesen usw., ist eine webbasierte Geschäftssoftwarelösung, die es Unternehmen aller Größen ermöglicht, Kunden- oder Clientinteraktionen zu verfolgen und
zu verwalten sowie Berichte zu erstellen. [2, S.29f.] Durch diese durchgängige Lösung,
die schnell verfügbar, flexibel anpassbar und leicht zu pflegen ist, können Unternehmen
bei Marketing, Vertrieb und Service effektiv und effizient unterstützt werden. [31]
Typischerweise liegen die konkreten Aufgaben von Microsoft Dynamics CRM darin, [2,
S.28]
ein Gesamtbild der Kundenbeziehungen abzubilden,
allgemeine Geschäftsvorgänge zu automatisieren, um manuelle Aufgaben zu reduzieren,
eine einheitlichere Kundenerfahrung zu ermitteln, indem Kundeninteraktionen vereinfacht werden, und
den Führungskräften zu ermöglichen, die Schlüsselkennzahlen zu messen und in Berichten zu interpretieren, wodurch bessere Strategie- und Geschäftsentscheidungen
getroffen werden können.
Microsoft Dynamics CRM ist die einzigartige Softwarelösung in der eCRM-Welt, weil
diese Anwendung den Unternehmen erlaubt, die Software in verschiedener Weise zu
installieren und bereitzustellen. Die drei Bereitstellungsoptionen für Microsoft Dynamics
CRM sind folgendermaßen aufgezeigt. [31]
Microsoft Dynamics CRM On Premise Microsoft Dynamics CRM wird von einem Unternehmen vor Ort in seinem lokalen Netzwerk installiert.
Microsoft Dynamics CRM Online Ein Unternehmen verwendet die online bereitgestellte Microsoft Dynamics CRM-Software über das Internet auf Servern, die von Mi-
324
crosoft gehostet werden.
Microsoft Dynamics CRM Partner Hosted Die Software wird in einer Hosting-Umgebung
eines zertifizierten Microsoft-Partners bereitgestellt.
Es werden ebenfalls mehrere Zugriffsmöglichkeiten geboten. Benutzer können auf nahezu
die gesamte Microsoft Dynamics CRM-Systemfunktionalität entweder vom Webclient
oder von Microsoft Dynamics CRM für Outlook aus zugreifen.
Windows IE Aufgrund seiner Architektur ist Microsoft Dynamics CRM über den Windows Internet Explorer-Webbrowser ab Version 6 mit SP 1 zugänglich. [32]
Microsoft Dynamics CRM für Outlook Neben der Webclient-Benutzungsoberfläche bietet Microsoft Dynamics CRM eine integrierte Outlook-Bedieneroberfläche. Benutzer können direkt mit ihren Microsoft Dynamics CRM-Daten in Outlook arbeiten,
ohne eine weitere Anwendung öffnen zu müssen. Des Weiteren kann eine Synchronisation mit dem Kalender, E-Mails, Kontakten und Aufgaben automatisch durchgeführt werden, um somit die oft bei der Pflege der Daten entstehenden Fehler zu
umgehen.
Microsoft Dynamics CRM für Outlook mit Offlinezugriff Diese Version ermöglicht den
Benutzern, mit ihren Microsoft Dynamics CRM-Daten auch dann zu arbeiten,
wenn keine Verbindung zum Server besteht. Wenn die Benutzer offline gehen, kopiert die Anwendung eine Teilmenge der Microsoft Dynamics CRM-Datenbank
auf ihren Computer. Können sie sich wieder mit dem Server verbinden, wird die
Änderung der lokalen Datenbank mit der Hauptdatenbank auf dem Server synchronisiert. [2, S.116f.]
Darüber hinaus kann auf Microsoft Dynamics CRM durch mobile Erweiterungen mit jedem internetfähigen mobilen Endgerät zugriffen werden. Neben der Integration mit Outlook arbeitet Microsoft Dynamics CRM mit mehreren anderen Microsoft- und Fremdsoftwareanwendungen zusammen, z.B. Microsoft Office Excel, Communications Server,
SAP usw. Das aktuelle Release der Software ist Microsoft Dynamics CRM 2011, die seit
September 2010 in Deutschland als Beta-Version verfügbar ist. [33]
Grundlagen für die Hauptmodule in Microsoft Dynamics CRM
Im letzten Abschnitt wurde eine Menge Hintergrundinformationen über Microsoft Dynamics CRM gegeben. Bevor die drei Funktionsmodule jeweils detailliert vorgestellt
werden, bildet zunächst dieser Abschnitt die Grundlagen für die Nutzung der Module in
Bezug auf wichtige Kundendatensätze im System.
325
Abbildung B.3.: Microsoft Dynamics CRM-Technologie [34]
Zu Microsoft Dynamics CRM als eine vollständige CRM-Suite gehören die folgenden drei
Hauptmodule: Marketing, Vertrieb und Service, wie in der Abbildung B.3 dargestellt
wird.
Innerhalb jedes Moduls erlaubt Microsofts Dynamics CRM Unternehmen, die verschiedenen Kundeninformationen zu verfolgen, wie sie in der folgenden Tabelle beispielsweise
aufgeführt sind.
Möglicherweise sind manche Daten für das Unternehmen nicht relevant, und es wird deshalb nicht alle solchen Daten verfolgen. Andererseits können die Unternehmen das System erweitern, um andere Typen von verwandten Daten zu erfassen und zu verfolgen, beispielsweise Projekte, Statusberichte, Ereignisse und Einrichtungen usw. Neben den Kundendaten können Unternehmen Informationen über die Interessenten, Geschäftspartner,
Hersteller, Lieferanten usw. im System erfassen. Dadurch ermöglicht die Flexibilität der
Microsoft Dynamics CRM-Plattform Unternehmen, nahezu jede Art von Daten zu erfassen, die für ihre Kunden relevant sind. [2, S.29f.]
Grundlegende Datensatztypen: Firmen und Kontakte
In der vorherigen Tabelle ist ersichtlich, dass einige Datensätze modulübergreifend im
System verwendet werden. Die zwei der wichtigsten und am häufigsten verwendeten Typen von Datensätzen (Entitäten) über Kunden in Microsoft Dynamics CRM sind Firmen
und Kontakte.
326
Vertrieb
Firmen
Kontakte
Leads
Verkaufschancen
Marketinglisten
Mitbewerber
Produkte
Vertriebsdokumentation
Angebote
Aufträge
Rechnungen
Marketing
Firmen
Kontakte
Leads
Marketinglisten
Kampagnen
Produkte
Vertriebsdokumentation
Schnellkampagnen
Service
Firmen
Kontakte
Servicekalender
Anfragen
Wissendatenbank
Verträge
Produkte
Sercives
Tabelle B.1.: Die drei Hauptmodule in Microsoft Dynamics CRM [2, S.29f.]
Unter einer Firma wird hier ein Unternehmen verstanden, mit dem eine Organisation
möglicherweise Geschäfte abwickeln wird, z.B. Artikel und Dienste an dieses Unternehmen verkaufen. Im Gegensatz dazu werden die konkreten Personen in Microsoft Dynamics CRM durch Kontakte bezeichnet. Ein Gesamtüberblick über jede Firma und jedes
Person, die (das) mit einem Unternehmen in Verbindung steht, wird dadurch entwickelt,
dass so viele Daten wie möglich über Firmen und Kontakte erfasst werden.
Die erfassten Firmen und Kontakte können durch unterschiedliche Beziehungen im System verknüpft werden.
Übergeordneter Kunde repräsentiert eine Arbeitsgeber-Arbeitsnehmer-Beziehung
zwischen einer einzelnen Firma und mehreren Kontakten.
Übergeordnete/zugehörige Firma weist normalerweise auf eine rechtliche Eigentümerschaft
zwischen den Firmen hin, z.B. Konzern und Niederlassung.
Mithilfe von Kundenbeziehungen werden zusätzliche Beziehungen zwischen Firmen
und Kontakten erstellt, z.B. Firma A ist der Netzwerkberater für Firma B. Solche
Typen von Beziehungen, die Unternehmen verfolgen werden, können Systemadministrator bei Bedarf konfigurieren.
In Microsoft Dynamics CRM können Unternehmen nicht nur Kunden, sondern auch
andere Organisationen sowie Personen, die mit ihnen in Beziehungen stehen, wie z.B.
Mitbewerber, Berater, Partner, Lieferanten usw. nachverfolgen [35, S.179f.]
327
Die doppelten Datensätze über Kunden innerhalb des Systems können mit der Funktion der Zusammenführung zu einem einzigen Datensatz konsolidiert werden. Dabei wird
ein Datensatz als Masterdatensatz spezifiziert, während der andere als untergeordneter
Datensatz behandelt wird, dessen verbundene Datensätze (Aktivitäten, Verkaufschancen usw.) in den Masterdatensatz kopiert werden und anschließend deaktiviert werden
müssen. [2, S.58ff.]
Grundlegender Datensatztyp: Aktivitäten
Mit dem Begriff Aktivität beschreibt Microsoft Dynamics CRM geschäftliche Interaktion mit Kunden, Interessenten usw. Die wesentlichen Typen von Aktivitäten werden
folgendermaßen aufgeführt. [35, S.156]
Aufgabe
Fax
Telefonanruf
E-Mail
Brief
Termin
Serviceaktivität
Kampagnenreaktion
Für jede Aktivität im System werden verschiedene Informationen über beispielsweise
Status, Dauer, Startzeit, Fälligkeitsdatum usw. erfasst. Mit dem Datenfeld Bezug (Regarding) kann ein Kunde oder anderer Datensatz spezifiziert werden, dem diese Aktivität
zugeordnet wird.
Aktivitäten können zwar in Microsoft Dynamics CRM einzeln erstellt werden, doch lassen sie sich mit den Workflow-Regeln automatisch erstellen und zuweisen, die in der Regel
durch Systemadministrator eingerichtet werden, um Aktionen bei den Geschäftsvorgängen
zu automatisieren. [2, S.79]
328
In den folgenden Abschnitten wird auf die drei Hauptmodule in Microsoft Dynamics
CRM näher eingegangen.
Funktionsmodul Vertrieb
Die Fähigkeiten der Vertriebsverwaltung in Microsoft Dynamics CRM ermöglichen Unternehmen, Umsatz generierende Aktivitäten im Vertrieb zu optimieren bzw. zu automatisieren und eine Rundumsicht über Kunden zu schaffen, um den kürzeren Vertriebszyklus, die höhere Abschlussraten und die bessere Loyalität der Kunden zu erreichen.
Da einige Entitäten im Modul Vertrieb den weiteren zwei Modulen zu Grunde liegen,
wird dieses Modul zuerst vorgestellt.
Stichwortartig werden die Vertriebsfunktionen folgendermaßen beschrieben. [36]
Erstellung einer zentralen und anpassbaren Ansicht von Präferenzen, Beziehungen
und Verkaufshistorie der Kunden, um ihre Bedürfnisse besser zu erkennen und zu
erfüllen.
Füllung der Verkaufspläne mit qualifizierten Leads, Verkaufschancen und Angeboten und Aufträgen.
Einsatz der Sofortkampagnen, um neue Produkte an Neu- und Bestandskunden
weiterzuleiten.
Unterstützung und Automatisierung der Stufen des Verkaufsprozesses durch WorkflowRegeln, um Verkaufschance konsistent und effektiv zu steuern.
Einsatz der Analyse- und Berichtswerkzeuge, um Umsätze zu prognostizieren,
Geschäftsaktivitäten und ihre Performance zu messen sowie Trends und Marktchancen zu erkennen.
Es werden die wichtigen Funktionen in diesem Modul im Folgenden erläutert.
Leads und Verkaufschance
Zunächst werden zwei grundlegende Entitäten im Vertrieb erklärt. Leads repräsentieren
potenzielle Kunden, die erst noch zu qualifizieren oder zu disqualifizieren sind. Leads
können aus vielen unterschiedlichen Quellen stammen, wie z.B. Websiteanforderungen,
Messekontakten oder eingehenden Telefonaten usw. Jedes Unternehmen kann seine eigenen Kriterien zur Qualifizierung eines Lead definieren, wobei die typischen Qualifizie-
329
rungsfragen folgendermaßen aussehen:
Hat der Lead Bedürfnis an unseren Produkten oder Diensten?
Passt der Lead in das finanzielle Profil der Kunden, an die wir verkaufen?
Ein qualifizierter Lead, der den Vertriebskriterien entspricht, kann in einen oder mehrere
der nachfolgenden Datensatztypen in Microsoft Dynamics CRM konvertiert werden:
Firma
Kontakt
Verkaufschance
Wird ein Lead disqualifiziert, kann ein Grund dafür angegeben werden, was später besser
ermöglicht, Berichte auszuwerten und Analysen durchzuführen.
Durch Verkaufschancen werden potenzielle Umsatz generierende Ereignisse (Verkäufe)
für Unternehmen repräsentiert. Eine Verkaufschance umfasst Daten über den potenziellen Verkauf, wie z.B. potenzieller Kunde, geschätztes Abschlussdatum, geschätzter
Umsatz, die Wahrscheinlichkeit zum Verkauf und die Bewertung für diese Verkaufschance. Verkaufschancen werden in erster Linie deshalb eingesetzt, um Management und
Leistungskräfte zu ermöglichen, unmittelbar bevorstehende Geschäfte und zukünftige
Anforderungen zu prognostizieren. Außerdem können sie durch Überwachung der Daten
für die Verkaufschancen besser in der Lage sein, die Verkaufspipeline zu verstehen und
die Leistung einzelner Verkaufsmitarbeiter zu bewerten.
Um die Verkaufsinformationen zu analysieren, umfasst Microsoft Dynamics CRM vier
vordefinierte Verkaufschancenberichte:
Verkaufspipeline
Leadursprungseffektivität
Mitbewerber
Aktivitäten
Mit dem Berichts-Assistenten können spezifischen Anforderungen entsprechend neue Berichte erstellt werden. Die Verkaufschancendaten können auch nach Microsoft Office Ex-
330
cel exportiert werden, um die Ad-hoc-Berichte und Prognosen zu erstellen. [2, S.136]
Nachdem die Entscheidungen der Kunden bereits ermittelt wurden, können die Verkaufschancen entsprechend mit dem Status Gewonnen oder Verloren geschlossen werden.
Die geschlossene Verkaufschance wird nicht vom System gelöscht, sondern desaktiviert
und kann erneut geöffnet werden.
Angebote
Angebote (Vorschläge) geben einen Überblick über die Produkte oder Dienste, die Unternehmen dem Kunden verkaufen möchten, zusammen mit den dazugehörigen Informationen beispielsweise: Kundenname, Rechnungsadresse, Lieferinformationen, Preis, Menge,
Umsatzsteuer und Rabatte sowie Gesamtbetrag usw. Angebote können entweder einzeln
oder vom Verkaufschancendatensatz aus erstellt werden.
Das erstellte aktive Angebot wird dem Kunden zur Überprüfung gesandt. Entscheidet
er sich für einen Kauf, kann ein Auftrag in Microsoft Dynamics CRM generiert werden,
um die Transaktion zu erfassen. Allerdings hat Microsoft Dynamics CRM die Auftragsund Rechnungsdatensätze für eine Integration in Back Office-Systeme (z.B. Finanz- und
Buchhaltungssysteme) konzipiert, d.h. die Auftragserfüllung und die Rechnungserstellung erfolgen in den mit Microsoft Dynamics CRM angebundenen Back Office-Systemen
und die dort erstellten Datensätze werden durch einen Integrationsprozess in Microsoft
Dynamics CRM übertragen. [2, S.148f.]
Wie bei Verkaufschancen liefern Berichtserstellung und Analyse der Angebotsdaten ebenfalls wertvolle Informationen über die Verkaufspipeline und die Leistung der einzelnen
Verkaufsmitarbeiter.
Funktionsmodul Marketing
Marketing wird normalerweise als Prozess bezeichnet, in dem ein Unternehmen Kunden
über zahlreiche Kommunikationskanäle davon überzeugt, sein Produkte oder Dienstleistungen zu kaufen. Microsoft Dynamics CRM stellt eine umfassende Lösung dar, die den
strategischen und operativen Aufgaben im Marketing gerecht wird. Marketingspezialisten stehen damit ganzheitliche und umfassende Marketingfunktionen zur Verfügung, mit
denen wirksame Kundenansprache optimal geplant und effektiv umgesetzt werden kann,
331
wodurch es dem Unternehmen ermöglicht, dem Kunden bedürfnisspezifische Leistungen
anzubieten und gleichzeitig relevante Informationen über den Kunden zu sammeln. Diese
Marketingfunktionen umfassen: [37]
Entwicklung von Marketinglisten mit präzisen Selektionswerkzeugen, um zielgruppengerechte Kundenansprache zu ermöglichen
Erstellung der Marketingkampagnen und -aktivitäten sowie Zugriff auf gespeicherte
Kampagnenvorlage
Steuerung der Marketingaktivitäten und -kampagnen für den gesamten Kampagnenzyklus, um mit Kunden effizienter zu kommunizieren und mehr Verkaufschancen in kürzerer Zeit zu qualifizieren.
Berichts- und Analysefunktion zur Beurteilung der Performance jeder Marketingaktion durch Ermittlung z.B. der Reaktionsquoten, der Anzahl der gewonnenen Verkaufschancen und der Kosten für die Marketingkampagnen.
Im Folgenden werden diese Marketingfunktionen genauer betrachtet.
Marketingliste
Unternehmen nutzen Listen von Kunden und Interessenten, um in geeigneter Weise
die Vorteile ihrer Produkte oder Dienstleistungen für das Zielpublikum bekannt zu machen. Mit Marketinglisten wird komfortable erreicht, Firmen, Kontakte oder Leads in
Microsoft Dynamics CRM zu gruppieren, damit sie in Marketingkampagnen und für
verschiedene geschäftliche Zwecke verwendet werden, z.B. eine Marketingliste der neuen
Firmen erstellen, um rationell Briefe oder Emails zu verschicken oder wichtige Kunden und Interessenten, die zu einem Seminar eingeladen wurden, in einer Marketingliste
nachverfolgen. [2, S.166ff.]
Bevor die Mitglieder in eine Liste hinzugefügt werden, muss sie standardmäßig mit Angaben von Namen und Mitgliedstyp definiert werden. Der Mitgliedstyp muss entweder
Firma, Kontakt oder Lead sein, wobei jede Liste nur einen Mitgliedstyp enthalten kann,
was auf die Unterschiedlichkeit der Attribute von diesen drei Typen von Datensätzen
zurückzuführen ist. Außerdem kann eine Liste durch benutzerdefinierte Attribute weiter
definiert werden. [35, S.284]
Die Aufgabe der Marketingliste liegt in erster Linie darin, mehrere Listenmitglieder einer
332
oder mehreren Marketingkampagnen zuzuordnen. Nach der Definition der Marketingliste
müssen ihre Mitglieder ausgewählt und in die Liste hinzugefügt werden. Das Hinzufügen
erfolgt in der Regel durch einfache Suche nach einzelnen Mitgliedern oder das Feature erweiterter Suche nach mehreren Mitgliedern mit gemeinsamen Interessen oder Attributen
durch die Abfragebedingungen. Solche Suchabfragen können im System gespeichert werden, um später zusätzliche Mitglieddatensätze schnell hinzufügen zu können. [35, S.286ff.]
Wie beim Hinzufügen der Mitglieder zu einer Liste können sie einzeln oder mithilfe der
erweiterten Suche basierend auf gemeinsamen Auswahlkriterien gruppenweise aus der
Liste entfernt werden. Darüber hinaus kann eine Marketingliste durch die Bewertungsoption mithilfe der Abfrage aktualisiert werden. Dabei werden alle Mitglieder, die den
Abfragekriterien nicht entsprechen, aus der Liste entfernt, ohne neue Mitglieder hinzuzufügen.
In Microsoft Dynamics CRM ist es auch möglich, neue Verkaufschancen oder Seriendruckdokumente mit personalisierten Daten direkt aus einer Marketingliste zu generieren.
Nachdem die Kunden- oder Interessentengruppen in Marketinglisten definiert wurden,
können Marketingkampagnen in Microsoft Dynamics CRM erstellt und verwaltet werden, um mit jeder Gruppe zu kommunizieren und nachverfolgen.
Kampagnen
Eine Marketingkampagne umfasst eine Reihe von Aktivitäten, in deren Unternehmen sowie deren Produkte oder Dienstleistungen für das Zielpublikum bekannt gemacht werden.
Für eine erfolgsorientierte Marketingkampagne müssen viele Teilnehmer, Begleitmaterialen und Aufgaben koordiniert werden. Microsoft Dynamics CRM ermöglicht es, Marketingprogramminformationen wie z.B. Angebots-, Planungs- und Finanzinformationen
zur Kampagne in einem Kampagnendatensatz zu speichern und zu verwalten. [2, S.188ff.]
Um eine Kampagne auszuführen, wird eine Menge von allgemeinen Aufgabenaktivitäten,
die als Planungsaufgaben bezeichnet werden, abgeschlossen. Zu diesen Aktivitäten gehören
z.B. Erstellen einer Zielliste, Drucken von Begleitmaterialen, Akzeptieren der Offerte
usw.
333
Für jede Kampagne werden eine und mehrere Zielmarketinglisten ausgewählt, die bereits
definiert wurden. Sie verbinden die Marketingkampagne und den Kunden oder Interessenten und liefern die Informationen darüber, die für Kampagnenaktivitäten vorgesehen
sind.
Für Kampagnen, die Produkte oder Dienstleistungen eines Unternehmens fördern oder
verständlich machen, müssen die Zielprodukte oder -dienste spezifiziert werden. Außerdem kann die sogenannte Vertriebsdokumentation, die Präsentationen, Produkt- und
Preislisten, Firmenhandbücher usw. umfasst, mit einer Kampagne in Beziehung gesetzt
werden.
Microsoft Dynamics CRM erlaubt es dem Marketingmanager, die Kampagnenvorlage
für die ähnlichen Marketingkampagnen zu erstellen, in denen meistens gleiche Planungsaufgaben und Aktivitäten durchgeführt werden. Die Kampagnenvorlage speichert Kerndetails und verknüpfte Informationen über die Kampagnen und funktioniert genau wie
Kampagne.
Kampagnenaktivitäten und -reaktionen
Wenn die Marketingkampagnen richtig geplant und eingerichtet werden, können sie ausgeführt und nachverfolgt werden. Microsoft Dynamics CRM vereinfacht die Ausführung
und Nachverfolgung der Marketingkampagnen mit Hilfe von Kampagnenaktivitäten und
-reaktionen. [2, S.208ff.]
Kampagnenaktivitäten sind spezielle Kommunikationsaktivitäten, wie z.B. Briefe, Faxe
und Telefonanrufe usw., die mit Marketingkampagnen verbunden sind. Alle der Kampagne zugeordneten Marketinglisten können automatisch mit einer Aktivität verbunden
werden. Es bietet sich an, lediglich ausgewählte Marketinglisten für spezifische Kampagnenaktivität zu verwenden, oder weitere Marketingliste hinzuzufügen.
Eine Kampagnenaktivität wird ausgeführt, indem sie verteilt wird. Dabei werden die
Aktivitäten im System erzeugt und den Besitzern von Kundendatensätzen zur Fertigstellung zugewiesen, z.B. bei E-Mail-Kampagnenaktivitäten können idealweise E-Mails
sofort an Kunden oder Interessenten, die in den Marketingliste spezifiziert sind, gesandt
334
werden, wenn sie verteilt werden. Wird eine Telefonanruf-Kampagnenaktivität verteilt,
wird eine Aktivität für beispielsweise den Besitzer der Datensätzen von Mitgliedern der
Marketinglisten mit dem vorgegebenen Fälligkeitsdatum erstellt.
Die sowohl positiven als auch negativen Antworten auf die Mitteilungen durch verteilte
Kampagnenaktivitäten können mithilfe von Kampagnenreaktionen aufgezeichnet werden. Eine Kampagnenreaktion kann auf verschiedene Weise erstellt werden. Neben dem
manuellen Erstellen kann eine Kampagnenaktivität direkt zu einer Kampagnenreaktion
heraufgestuft werden, indem sie als Reaktion geschlossen wird. Durch das Nachverfolgen
von Reaktion von Mitgliedern der Marketingliste ist es möglich, ihm mit einer weiteren
Aktion weiter nachzugehen. Für eine positive Antwort kann die Kampagnenreaktion so
geschlossen werden, dass sie in einen anderen Datensatztyp (z.B. Lead, Verkaufschance,
Angebot usw.) konvertiert wird.
Im Rahmen des Moduls Marketing definiert Microsoft Dynamics CRM mehrere Berichte,
mit denen ein Einblick in die Kampagnenaktivitäten und die Ergebnisse der Kampagnen
angezeigt werden kann. Die äußerst wichtige Datenpunkte wären beispielsweise:
Geschwindigkeit, mit der Aktivitäten geschlossen wurden
noch geöffnete Aktivitäten
Anzahl der erhaltenen Reaktion
Verhältnis der positiven und negativen Antworten usw.
Die typischen Beispiele der Standardberichte hierfür sind Kampagnenresultate und Status der Kampagnenaktivität.
Funktionsmodul Service
Die Beziehung des Unternehmens zu Kunden endet noch nicht, nachdem ein Verkauf abgeschlossen wurde. Um sicherzustellen, ob der Kunde mit dem Kauf zufrieden ist, müssen
die Kundenserviceteams mit den während der Marketing- und Verkaufsprozesse zusammengetragenen Informationen die Beziehung mit dem Kunden nach dem Verkauf weiter
pflegen. Mit Hilfe der Funktionalität im Modul Service von Microsoft Dynamics CRM
können Unternehmen konsistenten und effizienten Service leisten, um die Kundenzufriedenheit zu verbessern. Zusammenfassend werden die Servicefunktionen folgendermaßen
aufgezeigt. [38]
335
Ab dem ersten Kundenkontakt können die Serviceanforderungen erfasst werden
und sie bis zur Problemlösung verwaltet werden.
Die zur Problemlösung wichtigen Themen werden in einer Wissensdatenbank gespeichert, auf die Service-Mitarbeiter zugreifen können, um auf die individuellen
Kundenwünsche eingehen und auch Fragen beantworten zu können.
Die Serviceanfragen können durch ein Weiterleitungsmechanismus den richtigen
Bereichen zugeordnet und dort ohne großen Zeitverlust behandelt werden.
Die verfügbaren Ressourcen können mithilfe der Einsatzplanung nach Verfügbarkeit,
Einsatzort und Know-How für den Kundendienst optimal eingesetzt werden.
Es wird durch die Analyse- und Berichtswerkzeuge ermöglicht, die abgeschlossenen
Serviceanfragen auszuwerten, um ein Gesamtbild der häufig auftretenden Probleme
zu erhalten und die passenden Gegenmaßnahmen zu ergreifen. Darüber hinaus lassen sich die Kundenzufriedenheit, die Fallbearbeitungszeit sowie die Erfolgsquote
nach Erstkontakt in Echtzeit messen.
Es beschäftigt sich folgend mit den wesentlichen Funktionen im Service-Modul.
Serviceanforderungen
In Microsoft Dynamics CRM werden Serviceanforderungen als Anfragen bezeichnet. Eine
Anfrage stellt einen Anforderungs- oder Supportvorgang für einen Kunden dar und umfasst die Beschreibung des Serviceproblems und die dazugehörigen Informationen sowie
die Aktivitäten, um das Problem zu lösen. Eine erstellte Anfrage muss zu der Warteschlange oder einem Servicemitarbeiter zugewiesen.
Die Bearbeitung einer Anfrage kann durch eine Reihe von Nachverfolgungsaktivitäten
schrittweise erledigt werden. Es kann sich bei solchen Aktivitäten um eine einfache Aufgabe wie z.B. einen Produktkatalog verschicken oder um eine komplexe Angelegenheit
(mehrmals Telefonanrufe bei Kunden) handeln. Die Dauer jeder abgeschlossenen Aktivität in einer Anfrage wird beim deren Abschließen automatisch zur Gesamtzeit summiert, welche für die Anfrage aufgewendet werden muss.
Standardmäßig muss einer Anfrage ein Wert für das Feld Betreff zugewiesen werden. Unter Betreffen werden hier Kategorien verstanden, mit deren Hilfe Produkte, Vertriebsdokumentationen, Anfragen und Artikel in der Wissensdatenbank organisiert werden
können. Mit Betreffen wird eine hierarchische Struktur als Index von Themen abgebil-
336
det, die sich auf die geschäftliche Tätigkeit eines Unternehmens bezieht. Die Festlegung
der Betreffstruktur lässt sich vom Systemadministrator durchführen, wenn er das Microsoft Dynamics CRM-System konfiguriert. [2, S.246ff.]
Die Anfragedaten können vom Kundenservicemanager analysiert werden, um häufig auftauchende Probleme bei Kunden zu erkennen, die Zeit für die Problemlösung zu kalkulieren sowie die Bearbeitung der Probleme rationeller zu gestalten.
Wissensdatenbank
Die Wissensdatenbank in Microsoft Dynamics CRM ist eine Sammlung nützlicher Produktund Serviceinformationen sowie andere Ressourcen als Artikel, welche die Kundenservicemitarbeiter leicht suchen und recherchieren können. [35, S.328f.]
Die Artikel der Wissensdatenbank können alle Informationen, die nützlich dafür sind, die
Kundenanfragen schnell und genau zu beantworten, beispielsweise Benutzerhandbücher
für Produkte, Zusammenfassung wiederkehrender Kundenprobleme mit deren Lösungen
und häufig gestellte Fragen (FAQs), enthalten. Durch die Wissensdatenbank wird das
kollektive Know-how des Kundenserviceteams erfasst.
Um die Artikel den anderen Benutzern für die Suche und Recherchiere zur Verfügung
zu stellen, müssen sie nach der Genehmigung durch das Kundenservicemanagement
veröffentlicht werden. Zur Bereitstellung für das Formatieren der Wissensdatenbankartikel können mehrere Vorlagen vom Kundenservicemanager erstellt und ggf. modifiziert
werden.
Verträge und Warteschlange
Bietet Unternehmen seine Kunden Supportdienste an, sind Serviceverträge sinnvoll, da
sie den Servicemitarbeitern ermöglichen, die Anspruchsberechtigung jedes Kunden auf
Service zeitgerecht zu identifizieren. Serviceverträge repräsentieren Vereinbarungen mit
dem Kunden über die Servicebedingungen, wie z.B. Dauer der Vereinbarung, die Anzahl der Anfragen oder Servicestunden (Diese drei Diensteinheiten werden als Vertragspositionen bezeichnet.), die Preisberechnung, die Rechnungsinformationen usw. Einem
erstellten Vertrag können eine oder mehrere Vertragspositionen hinzugefügt, um die Details der Vereinbarung zu speichern. Jeder Vertrag in Microsoft Dynamics CRM kann
337
Datenzugriff
Funktionalität
Anpassung
Unterstützte Geräte
Bereitstellung
Microsoft CRM Mobil Express
Online
Vertrieb, Marketing, Service
Alle Felder, Standard- und eigene Objekte
Jedes internetfähige mobile Endgerät
Keine Installation auf dem Gerät notwendig
Tabelle B.2.: Übersicht über Microsoft CRM Mobil Express [39]
verschiedene Status (z.B. Entwurf, Aktiv) besitzen. Die Kundenanfragen sind ausschließlich bei aktiven Verträgen als Anspruch zu erstellen.
Die vom Servicemitarbeiter erstellte Anfrage kann entweder direkt an ihn selbst oder
einem anderen Benutzer zugewiesen werden oder an die Warteschlange gesandt werden. Eine Warteschlange dient als ein Aufnahmebehälter für die offenen Anfragen und
Aktivitäten, die abzuschließen sind, um sie an korrekten Bearbeiter weiterleiten und
rechtzeitig erledigen zu können. Die einer Warteschlange zugewiesenen Anfragen verbleiben dort, bis sie von einem Benutzer zur Bearbeitung akzeptiert werden oder an
einen weiteren Mitarbeiter weitergeleitet werden.
Mobile Lösung
Damit den Mitarbeitern in Vertrieb und Service beispielsweise von außerhalb des Büros
oder von unterwegs Zugriff auf Microsoft Dynamics CRM ermöglicht wird, bietet diese Softwareanwendung eine erweiterte mobile Lösung. Mit dieser mobilen Erweiterung,
Microsoft Dynamics CRM Mobile Express, können die Mitarbeiter mit jedem internetfähigen mobilen Endgerät jederzeit aktuelle Informationen zu Kunden, Verkaufschancen, Produkte abrufen und auf Geschäftsvorgänge zugreifen. Eine Übersicht von Microsoft Dynamics CRM Mobile Express wird in der nachfolgenden Tabelle gegeben.
Erweiterungen für Microsoft Dynamics CRM
Microsoft Dynamics CRM kann durch zwei Möglichkeiten erweitert werden: [40, S.7]
Customizing mit den Anpassungswerkzeugen, die beim Anwendungsbereich Einstellungen im System zu finden sind, ohne zu programmieren
338
Modifikation durch Programmierung
Wie im vorherigen Kapitel schon verdeutlicht wurde, lassen sich die Kundeninformationen durch verschiedene Typen von Datensätzen wie z.B. Firmen, Kontakte Leads, Auftrag usw. in Microsoft Dynamics CRM repräsentieren. Solche Typen von Datensätzen
werden im System als Entitäten bezeichnet. Es bestehen über 150 vordefinierte Entitäten
in Microsoft Dynamics CRM. [41, S.23] Nahezu alle dieser Entitäten können an die unternehmensspezifischen Erfordernisse in verschiedener Weise angepasst werden. [35, S.549ff.]
Um Geschäftsprozess zu automatisieren, wird in Microsoft Dynamics CRM das WorkflowModul eingesetzt, das auf Regel, Logik und Aktivitäten basiert. Es bietet sich mit dem
Workflow-Regel ein Instrument, mit dem die im Workflow enthaltenen Aktivitäten nacheinander ausgeführt werden. Typische, in Microsoft Dynamics CRM definierte Aktivitäten sind beispielsweise das Senden einer E-Mail, das Erstellen einer Aufgabe, das
Aufhören eines Workflows usw. [41, S.387ff.] Ebenfalls ermöglicht Microsoft Dynamics
CRM, unternehmensindividuelle Aktivitäten in Form von ausführbarem Programmcode
zu erstellen. Microsoft Dynamics CRM bietet außerdem den besonderen Vorteil, durch
die flexible, serviceorientierte Architektur mit dem zentralen Set an Webservices andere
Unternehmenslösungen, Systeme, insbesondere von Microsoft, und Prozesse zu integrieren. [42] Neben dem Office System können in Microsoft Dynamics CRM beispielsweise
folgende Produkte sowie Technologien eingebunden werden:
Microsoft PerformancePoint Server mit Dashboards und anderen Business IntelligenceFunktionen
Microsoft Server SQL Reporting Services zur Berichterstellung
Microsoft Office SharePoint Server zur Visualisierung und zum Austausch der Kundendaten
Microsoft Office Communications Server zur Verbesserung der Team-Zusammenarbeit
Microsoft BizTalk Server Adapter zur Einbindung in die Systemlandschaft im Unternehmen
Fazit
Um die Beziehung zu Kunden zu pflegen, zu intensivieren und ihn immer stärker an
das Unternehmen zu binden, rückt Customer Relationship Management den Kunden in
den Fokus aller unternehmerischen Aktivitäten. Neue Informations- und Kommunikationstechnologien eröffnen Unternehmen neue Kommunikations- und Absatzkanäle und
339
ermöglichen eine direkte und individualisierte Kundenansprache.
Vor allem seit den späten 90er Jahren stellt Electronic CRM als integrativer Ansatz die
Verknüpfung des CRM aus dem betriebswirtschaftlichen Bereich mit einer IT-technologischen
Komponente dar. Das heißt, erst durch die informationstechnologische Unterstützung
kann das Potential einer CRM-Lösung ausgeschöpft werden. Inzwischen haben sich schon
etliche Software-Hersteller etabliert, die CRM-Softwarelösungen anbieten.
Microsoft Dynamics CRM ist eine vollständige CRM-Suite mit Anwendungen für Marketing, Vertrieb und Service, die Unternehmen beliebiger Größe dabei unterstützt, profitable Kundenbeziehungen abzubilden, zu entwickeln und auszubauen.
Durch mehrere Bereitstellungsoptionen und Zugriffsmöglichkeiten wird eine flexible Bedienbarkeit von Microsoft Dynamics CRM gewährleistet. Indem zahlreiche weitere bestehende Produkte von Microsoft und den dritten Anbietern integriert werden, lassen sich
die Funktionalitäten von Microsoft Dynamics CRM erweitern, die von Unternehmen
bedürfnisspezifisch eingesetzt werden können. Die Anpassungsmöglichkeiten der Systemanwendung werden durch viele mitgelieferten Customizing-Werkzeuge sowie Microsoft Dynamics CRM SDK unterstützt, was ebenfalls deren Anbindung mit dem JinengoSystem ermöglicht.
340
Kosten und Emissionen von Elektroautos –
Grundlagen für einen Kosten- und
Emmissionskalkulator
Sven Kölpin
[email protected]
Zusammenfassung Diese Seminararbeit befasst sich mit der Entwicklung eines Kosten- und Emissionskalkulators für elektrisch betriebene
Fahrzeuge.
Schlüsselwörter Emission, Kosten, Kalkulation, Elektromobilität
341
Einleitung
Die Elektromobilität gilt momentan als das zukunftsträchtigste Verkehrsmittel im
deutschen Verkehrssystem. Der Plan der Bundesregierung, bis 2020 mindestens 1 Million Elektroautos auf die deutschen Straßen zu bringen, zeigt was für einen enormen
Stellenwert diese Fahrzeugklasse in Zukunft haben wird.
Im Rahmen der Projektgruppe Sustainable Customer Relationship Management für
”
EMobility Services mit SOA“ wird eine Software zur nachhaltigen Mobilitätsplanung
entwickelt, in welcher auch das Elektroauto als Fortbewegungsmittel zur Verfügung steht.
Deshalb gilt es herauszufinden, in welcher Höhe Kosten und Emissionen für ein solches
Fahrzeug anfallen. Die in dieser Seminararbeit zu entwickelnden Berechnungen sollen es
ermöglichen, ein elektrisch betriebenes Fahrzeug mit anderen Verkehrsmitteln auf Basis
von Daten zu Kosten und zur Nachhaltigkeit zu vergleichen.
Als erstes sollen dazu alle Faktoren ermittelt werden, welche einen Einfluss auf die
Lebenszyklusemissionen eines Elektroautos haben. Zusätzlich gilt es zu ermitteln, welche
konkreten Werte für die einzelnen Parameter verwendet werden können.
Weiterhin müssen diejenigen Parameter, die die Lebenszykluskosten eines Elektrofahrzeuges beeinflussen, untersucht werden. Dabei sollen, neben den bereits von herkömmlichen
Fahrzeugen bekannten Kosten, auch noch für Elektroautos spezifische Ausgaben beachtet werden.
Auf Basis der untersuchten Parameter und deren Werte werden anschließend Kosten
– und Emissionsformeln für ein Elektroauto entwickelt. Dabei werden sowohl statische
Parameterwerte als auch dynamische Werte, welche bei der Nutzung des Kalkulators
explizit vom Nutzer angegeben müssen, in den Formeln berücksichtigt.
Zur leichteren Nutzung des Kalkulators wird weiterhin eine auf JAVA basierende Anwendung entwickelt, welche die Berechnung der Kosten – und Emissionen komfortabler
gestaltet. Die Anwendung wird dabei lediglich als Anhang dieser Arbeit ausgeliefert und
ist kein expliziter Bestandteil der Ausarbeitung.
342
Emissionen von Elektroautos
Im Folgenden soll untersucht werden, in welchem Maße Emissionen von Elektroautos
produziert werden. Dazu wird der gesamte Lebenszyklus eines Elektroautos betrachtet,
um so die komplexen Zusammenhänge zwischen den zahlreichen Einflussfaktoren zu
untersuchen. Ziel des Kapitels ist es, eine möglichst genaue Berechnungsgrundlage für
den Emissionskalkulator zu liefern.
Analyse der Einflussfaktoren
Auf den ersten Blick hat die Idee der Elektromobilität einen sehr sauberen Anschein.
Autos, welche komplett ohne Abgase und Lärm auskommen, klingen wie ein Rettungsanker in Zeiten, in denen die Verringerung von CO2-Emissionen eine immer höhere
Priorität erhält.
Der Unterschied von elektrisch betriebenen Autos zu den herkömmlichen Kraftfahrzeugen liegt offensichtlich darin, dass diese während ihres Betriebes nur passiv zu Emissionen
führen, während Benzin- und Dieselfahrzeuge aktiv emittieren. Die Emissionsfreiheit von
Elektroautos ist also nur auf lokaler Ebene gegeben, weshalb für eine genaue Analyse der
Emissionen von elektrisch betriebenen Fahrzeugen eine globale Betrachtung stattfinden
muss. Dazu sollen zunächst alle diejenigen Einflussfaktoren bestimmt werden, welche
bei der Betrachtung des gesamten Lebenszyklus eines Elektroautos zu CO2-Emissionen
führen.
Als erstes wird untersucht, wie viel CO2-Emissionen bei der Erzeugung von Energie
für den Antrieb eines elektrischen Fahrzeuges entstehen. Dies beinhaltet vor allem eine
Betrachtung der verschiedenen Möglichkeiten zur Stromerzeugung in Deutschland.
Weiterhin muss der Wirkungsgrad von Elektroautos genauer untersucht werden. Die
Energieeffizienz eines elektrisch betriebenen Autos stellt eine wichtige Grundlage für die
Berechnung der Emissionen dar.
Als letztes müssen für eine genaue Betrachtung der Emissionen von Elektroautos auch
diejenigen Emissionen, welche bei der Produktion, Nutzung und Entsorgung der für den
Betrieb eines Elektroautos nötigen Akkumulatoren entstehen, mit in Betracht gezogen
werden.
343
Abbildung B.4.: Aktueller Strommix in Deutschland [44]
CO2-Emissionen bei der Stromerzeugung
Die Emissionen eines Elektrofahrzeuges hängen entschieden von dem eingesetzten Primärenergieträger
ab [43]. Aus diesem Grund sollen an dieser Stelle die in Deutschland üblichen Energiegewinnungskonzepte sowie deren Emissionswerte vorgestellt werden.
Der aktuelle Energiemix in Deutschland ist in Abbildung B.4 dargestellt.
Es lässt sich erkennen, dass die Stromgewinnung aus fossilen Brennstoffen noch deutlich
über die Hälfe der Gesamtstromerzeugung in Deutschland ausmacht. Zu knapp einem
Viertel wird die Energie zum jetzigen Zeitpunkt in Kernkraftwerken erzeugt, dicht gefolgt
vom Strom aus erneuerbaren Energiequellen wie Wind, Sonne und Wasser.
Für die Untersuchung der Auswirkungen der verschiedenen Stromquellen auf die CO2Emissionen von Elektroautos ist nun vor allem von Relevanz, wie viel Emissionen durch
die verschiedenen Arten der Stromerzeugung generiert werden. Dazu wird nun aufgezeigt,
wie die CO2-Emissionen der einzelnen Kraftwerkstypen berechnet werden.
344
CO2-Emissionen
(g
CO2/kWh)
Kraftwerksbau und Abriss
Brennstoffbereitstellung
Brenn- und Betriebsstoffe
Gesamt
Braunkohle
17
39
998
1045
Tabelle B.3.: CO2-Emissionswerte/kWh für die Erzeugung von Strom aus Braunkohle
Genau wie bei Ermittlung der Emissionen von Elektroautos darf bei der Bestimmung
der Kraftwerkemissionen nicht nur eine Betrachtung der aktiven Schadstofferzeugung
stattfinden. Vielmehr muss eine Analyse des gesamten Lebenszyklus unternommen werden. Dazu wurde 1970 eine Lebenszyklusanalyse entwickelt, die neben den direkten auch
die indirekten Emissionen berücksichtigt. Indirekte Emissionen sind dabei solche, welche zum Beispiel bei der Gewinnung und Aufbereitung des Brennstoffes und bei der
Entsorgung der Reststoffe entstehen.
Das Vorgehen bei der Bestimmung der Lebenszyklusemissionen von Kraftwerken lässt
sich grob in drei Schritte unterteilen [45]:
Bestimmung der direkten Emissionen: Erfassung des Energieverbrauchs (z.B. Brennstoffeinsatz) beim aktiven Betrieb und daraus resultierende CO2-Emissionen
Bestimmung der indirekten Emissionen durch Brennstoffbereitstellung: Erfassung der
CO2-Emissionen, welche bei der Gewinnung, Aufbereitung, Entsorgung und beim
Transport entstehen
Bestimmung der indirekten Emissionen durch den Kraftwerksbau: Erfassung der CO2Emissionen, welche beim Bau und bei dem Abriss eines jeweiligen Kraftwerkes
entstehen. Dazu gehören zum Beispiel die Emissionen, die bei der Erzeugung der
notwendigen Baustoffe wie Stahl anfallen.
Aus dieser Vorgehensweise zu Analyse der Gesamtemissionen der jeweiligen Kraftwerkstypen ergeben sich beispielsweise folgende CO2-Emissionswerte pro kWh für die Erzeugung von Strom aus Braunkohle [46]:
Es lässt sich erkennen, dass Braunkohle mit einer sehr hohen CO2-Emission/kWh belastet ist. Die direkten Emissionen, also die Emissionen aus den Betriebsstoffen, fallen
am meisten ins Gewicht.
345
Abbildung B.5.: CO2-Emissionen der verschiedenen Kraftwerkstypen [45]
Der Deutsche Bundestag hat in einer Studie im Jahr 2007 Werte für CO2-Emissionen
bezogen auf den Stromverbrauch veröffentlicht. Diese sind in der Abbildung B.5 dargestellt.
Grundsätzlich kann man aus der Abbildung erkennen, dass Strom aus erneuerbaren
Energiequellen über den gesamten Lebenszyklus gesehen die geringsten CO2-Emissionen
pro Kilowattstunde aufweist. Die hohen CO2-Emissionen bei der Stromgewinnung aus
Photovoltaikanlagen lassen sich mit der aufwändigen Herstellung von Solarzellen auf
Basis von Silizium erklären.
Aktuelle Berechnungen des Umweltbundesamtes zeigen, dass der durchschnittliche
CO2-Ausstoß bei dem derzeitigen Strommix in Deutschland bei ungefähr 575g/kWh
liegt [47].
In Deutschland kann ein Haushalt den Strom entweder aus fossilen oder erneuerbaren Energiequellen beziehen. Für die weiteren Berechnungen ist es deshalb sinnvoll, die
durchschnittlichen Emissionen aus erneuerbaren sowie die durchschnittlichen Emissionen aus fossilen Energiequellen (inkl. der Kernkraft) zu berechnen. Auf Basis der Werte
aus der Abbildung B.5 ergeben sich durchschnittlich 55g CO2/kWH für erneuerbare
Energien, sowie 641,38g CO2/kWh für die fossilen Energiequellen und der Kernenergie.
346
Abbildung B.6.: Wirkungsgrad moderner Kraftwerke [43]
Wirkungsgrad eines Elektroautos
Für eine genaue Untersuchung der Emissionen von Elektroautos ist es von großer Bedeutung, den Wirkungsgrad eines Elektroautos zu bestimmen. Unter dem Wirkungsgrad
wird das Verhältnis von abgegebener Leistung zu zugeführter Leistung verstanden. Das
bedeutet, dass bestimmt werden muss, wie viel der über den Akku zugeführten Leistung
der Elektromotor in Bewegungsenergie umsetzen kann. Oder einfach ausgedrückt, wie
viel Strom ein durchschnittlicher Elektromotor heutzutage für eine bestimme Strecke
verbraucht.
Aktuelle Zahlen zeigen, dass ein herkömmlicher Dieselmotor maximal 40% der im
Kraftstoff vorhandenen Energie in Bewegungsenergie umsetzen kann. Und selbst dieser
Wert ist im Realen nur in den seltensten Fällen zu erreichen, da der Motor nicht immer
im optimalen Bereich läuft [48].
Ein moderner Elektromotor hingegen kann bis zu 90% der ihm zugeführten Energie in
Bewegungsenergie umsetzen [48]. Diese Zahlen versprechen auf den ersten Blick eine sehr
hohe Energieeffizienz eines Elektroautos. Für eine korrekte Bestimmung des gesamten
Wirkungsgrades muss allerdings der Wirkungsgrad der Kraftwerke bei der Stromerzeugung mit einbezogen werden. Dieser liegt beim derzeitigen Strommix in Deutschland bei
ungefähr 40% [43].
347
Das heißt, dass der gesamte Wirkungsgrad eines Elektroautos, also der Wirkungsgrad des Elektromotors bezogen auf den Wirkungsgrad der Stromenergieerzeugung, bei
unter 40% liegt. Die Energieeffizienz eines Elektroautos, das mit dem deutschen Strommix betrieben wird, ist also vergleichbar mit der Energieeffizient eines herkömmlichen
Dieselfahrzeuges.
Trotzdem ist der reine Energieverbrauch eines Elektroautos durch den hohen Wirkungsgrad des Elektromotors sehr viel geringer als bei einem Dieselfahrzeug. Ein Elektroauto verbraucht zum jetzigen Zeitpunkt ohne den eingerechneten Netzverlust durch die
Kraftwerke im Schnitt 15-20 kWh/100 km, was ungefähr 2 Litern Benzin entspricht [43].
Dieser Wert berücksichtigt sowohl die durch Bremskraft zurückgewonnene Energie, als
auch den Energieverlust, welcher durch die Benutzung der Bordelektronik entsteht.
Es gilt allerdings zu beachten, dass der Wert von 15-20 kWh/100km stark vom Modell des Elektroautos abhängig ist. Das Bundesministerium für Umwelt, Naturschutz
und Reaktorsicherheit rechnet im Jahr 2010 mit einem durchschnittlichen Wert von 18
kWh/100km [49].
Durch Akkumulatoren verursachte Emissionen
Das Herzstück eines Elektroautos ist der Energiespeicher. Hierfür hat sich eine LiIonen-Batterie als am effizientesten herausgesellt. Diese Art des Akkus hat eine Menge
Vorteile gegenüber den sonst noch üblichen Blei- und Nickel-Metallhydrid-Akkumulatoren
[50]:
sie sind leichter
sie können mehr Energie speichern
sie haben keinen Memory Effekt
sie haben eine geringe Selbstentladung
sie sind langlebig
Diese Vorzüge eines Li-Ionen-Akkumulators wurden zum Beispiel auch schon vor langer
Zeit von der Computer- und Handyindustrie erkannt. Heutzutage nutzen fast alle Mobilfunkgeräte und Laptops einen Li-Ionen-Akku für die Energiespeicherung. Da auf Grund
dieser genannten Vorteile der Trend bei Elektroautos klar zu den Li-Ionen-Akkus geht,
soll für die weitere Analyse ausschließlich dieser Batterietyp betrachtet werden.
348
Das größte Problem der derzeitig auf dem Markt befindlichen Li-Ionen-Akkus ist zum
einen die begrenzte Kapazität zur Energiespeicherung und zum anderen das dadurch verursachte hohe Gewicht. Ein momentan erhältlicher Li-Ionen-Akku hat eine Energiedichte
von ungefähr 0,12kWh/kg [43]. Verglichen mit einem Liter Dieselkraftstoff, welcher es auf
ca. 11,9kWh/kg bringt, ist dieser Wert erschreckend gering. Zwar muss an dieser Stelle
auch auf den geringen Wirkungsgrad eines Verbrennungsmotors hingewiesen werden dieser ist fast dreimal geringer als bei einem Elektromotor. Trotzdem hat die deutlich
geringere Energiedichte zum Nachteil, dass der Akku ein sehr hohes Gewicht aufweist.
Allein für die Speicherung von 10kWh legt ein Akku bereits ein Gewicht von mindestens
100kg auf die Waage, obwohl mit einem solchen Energiespeicher je nach Fahrzeugtyp und
Fahrzeuggröße gerade einmal eine Strecke zwischen 50km und 100km gefahren werden
kann.
Für eine korrekte Betrachtung der Lebenszyklusemissionen eines Elektroautos müssen
nun an dieser Stelle die Emissionen des Li-Ionen-Akkumulators berücksichtigt werden.
In einer von der EMPA durchgeführten Studie wurde untersucht, inwiefern sich ein
im Elektroauto eingebauter Li-Ionen-Akku negativ auf dessen Umweltbilanz auswirkt.
Dabei wurde der gesamte Lebenszyklus eines Akkus, also von der Produktion über
die Nutzung bis zur Entsorgung, betrachtet. Das in der Studie betrachtete Elektrofahrzeugfahrzeug war vergleichbar mit dem Golf-Modell von VW und verbrauchte im
Schnitt 17kWh/100km. Als Lebensdauer wurde für das Elektroauto eine Kilometerzahl von 150000 angenommen, die Kapazität des verbauten Li-Ionen-Akkus betrug ca.
30kWh [50].
Das Ergebnis der Arbeit zeigt, dass die meiste Umweltbelastung anders als erwartet
nicht durch die Förderung und Verarbeitung des für den Akku notwendigen Lithiums
verursacht wird, sondern vielmehr durch die Gewinnung und Herstellung der für die Kathoden, Anoden und Kabel nötigen Rohstoffe Kupfer und Aluminium. Auf die durch ein
Elektroauto verursachten Gesamtbelastungen bezogen machen die Umweltbelastungen
des gesamten Lebenszyklus des Li-Ionen-Akkumulators ungefähr 15% aus.
Die CO2-Emissionen, welche für die Produktion, Nutzung und Entsorgung des 30kWh
Li-Ionen-Akkus über die gesamte Lebensdauer anfallen, liegen bei 1800kg [51]. Das entspricht 60 kg CO2/kWh. Bei der angenommenen Gesamtlebensdauer von 150000 Kilometer lassen sich also bei dem in der Studie verwendeten Elektroauto ungefähr 12g
CO2/km (1800/150000 * 1000) Emissionen für den 30kWh Li-Ionen-Akku berechnen.
Eine andere, vom Central Research Institute of Electric Power Industry in Japan
durchgeführte Studie kam auf einen Belastungswert von 75kg CO2/kWh für den Le-
349
benszyklus eines Li-Ionen-Akkus [52]. Das entspricht bei einen 30kWh Akku einem Gesamtemissionswert von 2250kg CO2/150000km beziehungsweise 15g CO2/km.
Diesen beiden Werten steht der Wert einer im Jahr 2009 von dem Ökobilanzierer
Rolf Frischknecht [53] durchgeführten Untersuchung entgegen. Er berechnete für einen
20kWh Li-Ionen-Akku eine Belastung von rund 48g CO2/km, was einem Wert von 360kg
CO2/kWh für den Lebenszyklus eines Li-Ionen-Akkus entspricht.
Es lässt sich also erkennen, dass an dieser Stelle noch kein eindeutiger Wert für die
CO2-Emissionen eines in einem elektrisch betriebenen Fahrzeug verwendeten Li-IonenAkkumulators gefunden werden kann. Für die weitere Berechnung soll allerdings der
in der EMPA-Studie ermittelte Wert von 60kg CO2/kWh verwendet werden, da diese
Studie im Juni 2010 veröffentlicht wurde und damit die Aktuellste aller untersuchten
Studien ist.
Fazit Emissionen von Elektroautos
Bei den Untersuchungen zur Berechnung der CO2-Emissionen von Elektroautos hat
sich gezeigt, dass die einzelnen Parameter nicht ohne weiteres zu bestimmen sind. Eine
Ausnahme ist hier die Bestimmung der Emissionen der verschiedenen Energiequellen. Da
hierzu relativ genau dokumentierte Werte von verschiedenen Institutionen des Bundes
vorliegen, können Aussagen zu den derzeitigen Emissionen der einzelnen Energiequellen
getroffen werden. Für den Kalkulator ist es von enormer Wichtigkeit, dass die Art der
Stromquelle (erneuerbar oder fossil) als Parameter einstellbar ist.
Die Bestimmung des Wirkungsgrades von Elektroautos als Basis für die Verbrauchsrechnung ist hingegen nur sehr schwer vorzunehmen. Hier haben sehr viele Parameter,
wie zum Beispiel das Modell des Autos, das Gewicht, die zusätzliche Ausstattung (Klimaanlage etc.) oder der Fahrstil einen großen Einfluss. Auch die teilweise rasante technische
Entwicklung lässt hier keine allgemeingültige Aussage zu. Aus diesem Grund wird dieser
Wert bei der Entwicklung des Kalkulators höchst flexibel dargestellt.
Die Emissionen, welche durch die in Elektroautos befindlichen Akkumulatoren verursacht werden, schwanken in den untersuchten Studien teilwiese sehr stark. Deshalb
wird von nun an ein statischer Wert von 60kg CO2/kWh angenommen. Zusätzlich sind
die Emissionswerte der Akkus von der Gesamtnutzungsdauer des Fahrzeuges abhängig.
Für alle weiteren Berechnungen wird deshalb eine Lebensdauer von 150000 Kilometern
angenommen.
350
Verbrauch
100km
Energiepreise
auf
Elektroauto – Modell wie Golf
20kWh
Ca. 0,2369EUR/kWh
Gesamtpreis/100km Ca. 4,74EUR
VW
Golf
(Benzin)
6,4 Liter
5
Ca. 1,35EUR/Liter
Ca. 8,46EUR
Tabelle B.4.: Einfacher Kostenvergleich Benzinauto - Elektroauto
Kosten von Elektroautos
Im Folgenden soll untersucht werden, wie sich die Kosten für ein Elektroauto zum
aktuellen Zeitpunkt zusammensetzen. Dazu wird, wie schon bei der Untersuchung zu
den Emissionen, der komplette Lebenszyklus betrachtet. Auf Basis der in diesem Kapitel
gewonnenen Erkenntnisse soll eine möglichst flexible Berechnungsgrundlage für einen
Kostenkalkulator abgeleitet werden können.
Analyse der Einflussfaktoren
Ähnlich wie bei der Betrachtung der Emissionen eines Elektroautos lässt eine oberflächliche Analyse darauf schließen, dass elektrisch betriebene Fahrzeuge, abgesehen vom
Anschaffungspreis, im Betrieb um ein vielfaches günstiger sind als herkömmliche Benzin
– oder Dieselfahrzeuge. Immerhin hat ein Elektroauto, wie im vorherigen Kapitel gezeigt,
einen weitaus höheren Wirkungsgrad als ein mit Brennkraftstoff betriebenes Auto.
Aus dem daraus resultierenden geringeren Verbrauch an Energie und den aktuellen
Strompreisen lässt sich leicht errechnen, dass für ein Elektroauto auch schon zur heutigen
Zeit sehr viel weniger Geld für eine Strecke von 100 Kilometern gezahlt werden muss.
Eine simple Beispielrechnung zeigt, dass man mit einem elektrisch betriebenen Auto gut
die Hälfte der Kosten einsparen kann.
Diese Rechnung lässt allerdings sehr viele Faktoren, welche den eigentlichen Preis
pro Kilometer stark beeinflussen, außer Acht. Um eine korrekte Berechnung der Kilometerkosten eines Elektroautos vornehmen zu können, müssen zunächst alle wichtigen
Einflussfaktoren bestimmt werden.
351
Dazu sollen als erstes die Anschaffungskosten für ein Elektroauto untersucht und dargestellt werden. Es gilt eine Klassifizierung der am Markt befindlichen Elektrofahrzeuge
vorzunehmen und anschließend deren Durchschnittpreise zu errechnen. Ziel dieses Teils
der Arbeit ist es, eine allgemeingültige Aussage über den Anschaffungspreis eines elektrisch betriebenen Autos zum aktuellen Zeitpunkt treffen zu können.
Weiterhin müssen die laufenden Kosten für die Energiebereitstellung berücksichtigt
werden. Dies beinhaltet die Untersuchung der Preise für verschiedene Stromquellen, sowie die Prüfung von Einflussfaktoren wie die aktuelle Stromlast auf die Energiepreise.
Zuletzt sollen weitere laufende Kosten wie die Verschleißkosten, welche zum Beispiel
beim Akkumulator anfallen, berücksichtigt werden. Außerdem soll an dieser Stelle die
Betrachtung von Steuer- und Versicherungskosten vorgenommen werden.
Anschaffungskosten eines Elektroautos
Elektroautos haben zur jetzigen Zeit noch einen sehr viel höheren Anschaffungspreis
als herkömmliche Fahrzeuge. Dies ist zum einen dadurch zu erklären, dass bisher noch
kein elektrisch betriebenes Fahrzeug in großer Stückzahl gefertigt wurde. Bisher wurden
allenfalls Kleinserien am Markt angeboten. Aus diesem Grund ist ein Elektroauto derzeit
noch ein Nischenprodukt.
In B.7 lässt sich erkennen, wie groß die Preisunterschiede zwischen einem Elektroauto und einem herkömmlichen Auto sind. Dadurch, dass noch kein Elektroauto in Serie
gefertigt wird, sind die Herstellungskosten des elektrisch betriebenen Fahrzeugens mehr
als doppelt so hoch wie die eines in Serie befindlichen Fahrzeuges mit Verbrennungsmotor. Zusätzlich erhöhen die Mehrkosten im Vertrieb und im Handel den letztendlichen
Listenpreis deutlich. Es ist an dieser Stelle wichtig zu beachten, dass diese Grafik eine
Preisannahme ab dem Jahre 2012 darstellt. Für eine Untersuchung der aktuellen Preise
für Elektroautos müssen schon am Markt befindliche Fahrzeuge betrachtet werden.
In Deutschland sind bisher nur wenige Elektrofahrzeuge zu kaufen. Die Preise der
bisher auf dem weltweiten Markt erhältlichen Elektrofahrzeuge sind stark abhängig von
der Ausstattung und vor allem von dem Fahrzeugmodell. Für einen allgemeingültigen
Kostenrechner ist es wichtig, zu verschiedenen Fahrzeugmodellen die aktuellen Neuwagenpreise zu kennen. Da es zum jetzigen Zeitpunkt die meisten Elektroautos in den
Fahrzeugklassen Kleinstwagen, Kleinwagen und Kompaktwagen beziehungsweise Mittelklassewagen gibt, wird für den Kalkulator nur zwischen diesen drei Fahrzeugmodellen
352
Abbildung B.7.: Herstellungkosten eines Elektroautos [49]
353
Kleinstwagen
Fahrzeugname
City EL
Hotzenblitz
Think City
Durchschnittlicher Preis
Preis in EUR
10.000 [54]
15.000 [55]
30.000 [56]
18.333
Tabelle B.5.: Preisermittlung eines Kleinstwagens
Kleinwagen
Fahrzeugname
Mitsubishi i MiEV
Luis Free
REVA
Preis in EUR
34.000 [57]
15.000 [58]
23.000 [59]
24.000
Tabelle B.6.: Preisermittlung eines Kleinwagens
unterschieden.
Um eine einigermaßen realistische Annahme über die durchschnittlichen Preise eines zu einer bestimmten Fahrzeugklasse gehörenden Elektrofahrzeuges zu bestimmen,
wurden in den folgenden Tabellen die Preise der momentan gängigsten Fahrzeuge in
den jeweiligen Klassen aufgelistet. Der Durchschnittswert der Kosten soll von nun an
repräsentativ für die Kosten einer Elektrofahrzeugklasse genutzt werden.
Mittelklasse
Fahrzeugname
Opel Ampera
Nissan Leaf
Chevrolet Volt
Tesla Model S
Preis in EUR
42.900 [60]
35.000 [61]
42.900 [62]
42.500 [63]
40.825
Tabelle B.7.: Preisermittlung eines Mittelklasse-Wagens
354
Stromanbieter
Naturwatt
EWS-Schönau
Lichtblick
Greenpeace-Energy
Die Strommixer
Naturstrom
Durchschnittlicher Energiepreis
Energiepreis EUR/kWh
bei 3500kWh
0,245
0,262
0,267
0,278
0,254
0,239
0,2575
Tabelle B.8.: Energiepreis für erneuerbare Energien
Laufende Kosten für die Energiebereitstellung
Für die Aufladung eines Akkus muss Energie von verschiedenen Energieversorgern
bezogen werden. Wie bereits im vorherigen Kapitel dargestellt, gibt es im derzeitigen
Strommix in Deutschland sehr viele verschiedene Energiequellen. Bei den Tarifen für eine
Kilowattstunde kann bei den deutschen Stromanbietern grundsätzlich zwischen Strom
aus fossiler Energie beziehungsweise Kernenergie und Strom aus erneuerbarer Energie
unterschieden werden. Die Strompreise sind dabei sehr dynamisch und von vielen Faktoren wie zum Beispiel dem Jahresverbrauch oder der Region abhängig. Es wird für die
weiteren Berechnungen deshalb mit Durchschnittstrompreisen für das Jahr 2010 gerechnet.
Der derzeitige durchschnittliche Strompreis in Deutschland liegt laut dem BDEW
für einen jährlichen Stromverbrauch von 3500 kWh bei 0,2369EUR/kWh. Nach eigenen
Berechnungen fallen bei einem jährlichen Stromverbrauch von 3500kWh für Strom aus
erneuerbaren Energien im Schnitt 0,2575EUR/kWh an. Das Bedeutet im Umkehrschluss,
dass Strom aus fossilen Energieträgern und der Kernenergie derzeit mit einem Preis von
ungefähr 0,2346EUR/kWh zu berechnen ist, wenn man beachtet, dass zur Zeit ungefähr
10% der Verbraucher ihren Strom aus Erneuerbaren Energien beziehen [64]. Diese beiden
Werte sollen für die weitere Berechnung repräsentativ für die jeweiligen Preise für Strom
aus erneuerbaren- beziehungsweise fossilen Energieträgern dienen.
Die folgende Tabelle zeigt die Energiepreise der sechs bekanntesten Anbieter von Strom
aus erneuerbarer Energie. Die Zusammensetzung des Stroms schwankt dabei zwischen
Anteilen aus der Windenergie, Wasserenergie und Photovoltaik.
355
Es ist sehr wahrscheinlich, dass diese Kosten in Zukunft immer mehr von der Lastsituation des Stromnetzes abhängig sind. Da aber momentan noch zu wenig elektrisch
betriebene Fahrzeuge existieren und damit noch keine spürbare Veränderung der Stromlast zu vermerken ist, wird dieser Aspekt im weiteren Verlauf nicht beachtet.
Verschleißkosten & Wertverlust
Wie bereits erwähnt, machen die Akkumulatoren bei heutigen Elektroautos noch einen
Großteil der Gesamtkosten bei der Anschaffung aus. Gründe dafür liegen vor allem darin,
dass die Forschung und Entwicklung an Akkumulatoren Mitte der 90er Jahre nach einem
fehlgeschlagenen Modellversuch mit Elektroautos auf Rügen deutlich zurückgefahren
wurde [65]. Die Herstellung Leistungsfähiger Li-Ionen-Akkus ist dadurch momentan noch
sehr teuer.
Ein weiteres Problem der aktuellen Akkus ist, dass sie einen deutlichen Verschleiß
während der Nutzung zeigen. Im Schnitt schaffen sie heutzutage maximal 1500 Ladezyklen [66].
Geht man nun davon aus, dass der Preis eines Akkus momentan bei ungefähr 600
EUR/kWh [67] liegt und ein Elektroauto aus der Mittelklasse mit einem 20kWh-Akku
ausgestattet ist, so kostet der Akku 12000 EUR. Das bedeutet, dass momentan bei jedem
Ladevorgang mit Verschleißkosten 8 EUR / Ladezyklus (12000 EUR/1500 Ladezyklen)
zu rechnen ist. Abhängig vom Verbrauch des Fahrzeuges lassen sich dann die Verschleißkosten pro Kilometer berechnen. Liegt der Verbrauch eines Fahrzeuges beispielsweise bei
15kWh/100km, so liegen die Akkuverschleißkosten bei 0,06EUR/km (8 EUR / (20kWh
/ (0,15kWh/km)).
Laut [68] kann der Wertverlust eines Elektrofahrzeuges, ohne den Verlust des Akkus
miteinzubeziehen, mit dem Wertverlust eines herkömmlichen Autos verglichen werden.
Der durchschnittliche Wertverlust eines Neuwagens liegt bei einer Jahreskilometerleistung von 15.000 km/Jahr nach dem ersten Jahr bei ungefähr 24,2%, in jedem darauffolgenden Jahr verliert es zusätzlich 6% an Wert. Diese Werte sollen von nun an als
allgemeingültige Werte für den Wertverlust eines Elektroautos/Jahr gelten. Dabei wird
eine durchschnittliche Jahreskilometerleistung von 15.000 Kilometern angenommen.
356
Fahrzeugklasse
Kleinstwagen (bis 1t)
Kleinwagen (über 1t ,
unter 1.5t)
Mittelklassewagen
(über 1.5t)
Kfz-Steuer/Jahr in EUR (fällig
ab 5. Jahr)
unter 28
über 28, unter 45
über 45
Tabelle B.9.: Kfz-Steuer im Jahr für ein Elektroauto [69]
Wartungskosten & Fixkosten
Deutliche Vorteile zeigt ein elektrisch betriebenes Fahrzeug in der Wartung. Zum Beispiel ist kein Ölwechsel mehr nötig und Kosten für eine Abgasuntersuchung entfallen
komplett. Insgesamt können für die Wartung eines Elektroautos ungefähr 1,2 Cent/Kilometer berechnet werden [68].
Auch bei den Kraftfahrzeugsteuern hat ein Elektroauto gegenüber einem klassischen
Auto Preisvorteile. Bei einem Elektroauto entfallen die Kfz-Steuern in den ersten fünf
Jahren ab dem Tag der Erstzulassung, vorausgesetzt es handelt sich um ein Personenkraftfahrzeug. Die folgende Tabelle zeigt die bei einem Elektroauto ab dem fünften Jahr
zu zahlenden Kraftfahrzeugsteuern.
Zusätzlich muss für ein Elektroauto genau wie für ein herkömmliches Kraftstoffbetriebenes Fahrzeug die Versicherung gezahlt werden. Da es hier viele verschiedene Modelle
gibt (Teilkasko, Vollkasko) und die Versicherungspreise zusätzlich vom Autotyp und vom
Fahrzeughalter abhängen, kann an dieser Stelle keine allgemeingültige Annahme zu den
Versicherungskosten gemacht werden.
Zuletzt ist es zu erwarten, dass in naher Zukunft die Steuern auf Strom deutlich erhöht
werden. Da die Bundesregierung bei einer wachsenden Anzahl an Elektroautos entsprechend weniger Einnahmen durch die Mineralölsteuer bekommt, müssen diese Ausfälle
an anderer Stelle ausgeglichen werden. Eine Steuer auf Fahrstrom ist damit sehr wahrscheinlich, wird allerdings in dieser Kalkulation noch nicht berücksichtigt.
357
Fazit Kosten eines Elektroautos
Die Kosten von Elektroautos sind wie die Emissionen aus verschiedenen Parametern
zusammenzusetzen. Für eine allgemeingültige Darstellung der Anschaffungskosten der
am Markt befindlichen Elektroautos ist eine Unterteilung in verschiedene Fahrzeugklassen notwendig. Die durchschnittlichen Kosten für die Anschaffung sowie die für KfzSteuern anfallenden Kosten lassen sich mit einer solchen Unterteilung einigermaßen genau bestimmen.
Die Energiekosten pro Kilometer sind von der Art der Stromquelle mit dem das Auto
aufgeladen wird, sowie von dem Verbrauch des Autos abhängig. Eine grundsätzliche Unterscheidung zwischen Strom aus erneuerbaren Quellen und Strom aus fossilen Quellen
sowie die Ermittlung deren für 2010 gültigen Durchschnittspreise ist bei den höchst flexiblen Preisstrukturen am Strommarkt die sinnvollste Grundlage für eine allgemeingültige
Kostenberechnung.
Verschleißkosten, welche bei einem Elektroauto in erster Linie für die Akkumulatoren
anfallen, sind vor allem von der Leistungsfähigkeit des Akkus abhängig. Die Annahme
einer begrenzten Anzahl von 1500 Ladezyklen hingegen ist vorerst als allgemeingültig
anzunehmen.
Allgemein lässt sich festhalten, dass Elektrofahrzeuge im Vergleich zu konventionellen
Fahrzeugen in der Anschaffung durchschnittlich teurer sind [70]. Der Plan der Bundesregierung, bis zum Jahr 2020 mindestens 1 Mio. Elektroautos auf Deutschlands Straßen
zu bringen, könnte für die Zukunft aber einen enormen Einfluss auf die Preisentwicklung
haben: Sobald Elektroautos in Serie produziert werden, kann man mit einem starken
Rückgang der Herstellungskosten rechnen. Allerdings muss durch den Wegfall an Mineralölsteuern auch mit einer Erhöhung der Steuern für Strom gerechnet werden.
358
Gewicht
Kleinstwagen 900kg
Kleinwagen 1250kg
Mittelklasse 1500kg
Anschaffungskosten KfzSteuerbeitrag
pro Jahr
18333EUR
28EUR
24000EUR
36,5EUR
40825EUR
45EUR
Tabelle B.10.: Attributwerte der verschiedenen Autoklassen
Grundlagen für einen Kosten- und Emissionskalkulator
Der Kalkulator basiert auf den in den vorherigen Kapiteln ermittelten Werten und
geht von folgenden Annahmen aus:
Ein Elektroauto hat eine Jahresfahrleistung von 15000 Kilometern
Ein Elektroauto hat eine Lebensdauer von 10 Jahren, also 150000 Kilometern
Ein Elektroauto hat bei der angenommenen Jahresfahrleistung einen Wertverlust
von 24,2% im ersten Jahr und jeweils 6% in den darauffolgenden Jahren
Diese Werte entsprechen denen eines durchschnittlichen deutschen PKWs mit Verbrennungsmotor.
Auf Basis der im Rahmen dieser Arbeit vorgenommenen Recherchen werden zudem
folgende statische Parameterwerte verwendet:
Die Kosten für einen Li-Ionen-Akku belaufen sich auf 600EUR/kWh
Die Lebenszyklusemissionen eines Li-Ionen-Akkus liegen bei 60kg CO2/kWh
Die Wartungskosten für ein Elektroauto liegen bei 1,2 Cent/km
Weiterhin wird davon ausgegangen, dass sich derzeit grundsätzlich drei Klassen von
Elektroautos am Markt befinden. Die Eigenschaften dieser Elektroautoklassen zeigt die
Tabelle B.10. Die in dieser Tabelle aufgeführten Werte der einzelnen Attribute dienen
als Berechnungsgrundlage für den Kalkulator.
Zusätzlich zeigt die Tabelle B.11 die statischen Annahmen für die beiden verschiedenen
Arten der Stromversorgung.
359
Strom aus fossilen
Energieträgern
&
Kernenergie
Strom aus erneuerbaren Energien
durchschnittliche durchschnittliche
Kosten
Emissionswerte
0,2346 EUR/kWh 641,38g
CO2/kWh
0,2575EUR/kWh
55g CO2/kWh
Tabelle B.11.: Attributwerte der verschiedenen Stromklassen
Parameter
Autoklasse
Bezeichnung
CARC
ACAP
DIST
INSCO
CAGE
Beschreibung
Kleinstwagen, Kleinwagen, Mittelklasse
Strom aus erneuerbaren Energiequellen,
Strom
aus
fossilen
Brennstoffen
In kWh auf 100 Kilometer
In kWh
In Kilometern
In EUR pro Jahr
Jahre
Stromquelle
PSO
Verbrauch des Elektroautos
Akkukapazität
Fahrstrecke
Versicherungskosten
Anzahl Jahre seit
Erstzulassung
Zusatzlast
CON
ADDW
In Kilogramm
Tabelle B.12.: Vom Nutzer angegebene Parameter
Neben den statischen Werten gibt es noch solche, welche auf Grund ihrer hohen Flexibilität nicht allgemeingültig definiert werden konnten. Diese Parameter müssen bei der
Verwendung des Kalkulators stets vom Nutzer angegeben werden. Sie sind in der Tabelle
B.12 dargestellt.
Aus allen definierten Parametern lassen sich nun Formeln für die Berechnung der Kosten
und der Emissionen eines Elektroautos auf einer bestimmten Strecke entwickeln.
Der Verbrauch eines Elektroautos berechnet sich wie in Formel B.1 dargestellt.
V erbrauch
360
kW h
CON kW h CARC.W EIGHT + ADDW
=
×
km
100km
CARC.W EIGHT
(B.1)
Formeln für den Emissionskalkulator
Im Folgenden werden die Formeln für die Berechnung der Emissionen eines Elektroautos aufgezeigt. In der Formel B.2 werden die Emissionen pro Kilometer bezogen auf
den Verbrauchswert des Elektroautos berechnet.
EmissionV erbrauch
gCO2
kW h
gCO2
= V erbrauch
× P SO.EM ISSION
km
km
kW h
(B.2)
Die Formel B.3 berechnet die vom Akkumulator verursachten Emissionen bei einer Gesamtlebensdauer von 150.000km.
60 kgCO2
gCO2
kW h × ACAP kW h
EmissionAkku
=
× 1000
km
150.000km
(B.3)
Die Gesamtemissionen eines Elektroautos pro Kilometer werden in der Formel B.4 berechnet.
EmissionGesamt
gCO2
gCo2
gCO2
= EmissionV erbrauch
+ EmissionAkku
(B.4)
km
km
km
Die Formel B.5 ist eine Zusammenfassung aller vorherigen Formeln. Sie berechnet die
Gesamtemissionen eines Elektroautos auf einer vorgegeben Strecke.
EmissionStrecke
gCO2
gCo2
= EmissionGesamt
× DIST
km
km
(B.5)
Formeln für den Kostenkalkulator
Die nächsten Formeln ermöglichen die Berechnung der Kosten eines Elektroautos auf
einer vorgegebenen Strecke. Die Formel B.6 berechnet die Kosten in EUR bezogen auf
den Verbrauchswert.
KostenV erbrauch
kW h
EU R
EU R
= V erbrauch
× P SO.COST
km
km
kW h
(B.6)
In Formel B.7 werden die Verschleißkosten des Akkus bei einer maximalen Akkulebensdauer von 1.500 Ladezyklen berechnet.
EU R
=
KostenAkkuV erschleiß
km
R
ACAP kW h×600 EU
kW h
1500
ACAP kW h
h
V erbrauch kW
km
(B.7)
Die Berechnung des Wertverlustes bei einer Gesamthaltungsdauer von 150.000km wird
in der Formel B.8 dargestellt.
W ertverlust
EU R
CARC.COST EU R − (CARC.COST EU R × (0, 242 + (9 × 0, 06)))
=
km
150.000km
(B.8)
361
Die Wartungskosten eines Elektroautos liegen bei einer Jahresfahrleistung von 15.000km
bei 0,012EUR. Formel B.9 stellt das dar.
W artungskosten
EU R
EU R
= 0, 012
km
km
(B.9)
Formel B.10 berechnet die Versicherungskosten pro Kilometer bei einer Jahresfahrleistung von 15.000km.
KostenV ersicherung
IN SCOEU R
EU R
=
km
15.000km
(B.10)
Die pro Kilometer anfallenden Kfz-Steuern werden mit der Formel B.11 berechnet.
EU R
CARC.T AXESEU R
= if (CAGE > 5)T HEN
ELSE0
km
15.000km
(B.11)
Die Fixkosten berechnen sich aus den Werten der Formeln Wartungskosten, KostenKfzSteuer und KostenVersicherung. Dies ist in Formel B.13 dargestellt.
KostenKf zSteuer
KostenF ix1
EU R
EU R
EU R
= W artungskosten
+ KostenV ersicherung
km
km
km
EU R
EU R
EU R
= KostenF ix1
+ KostenKf zSteuer
km
km
km
Die Gesamtkosten pro Kilometer werden in der Formel B.16 berechnet.
KostenF ixKosten
KostenG1
EU R
EU R
EU R
= KostenV erbrauch
+ KostenAkkuV erschleiß
km
km
km
(B.12)
(B.13)
(B.14)
EU R
EU R
EU R
= W ertverlust
+ KostenF ixKosten
(B.15)
km
km
km
EU R
EU R
EU R
= KostenG1
+ KostenG2
(B.16)
KostenGesamt
km
km
km
Für die letztendlichen Kosten pro Strecke werden die Gesamtkosten pro Kilometer mit
der zu fahrenden Strecke multipliziert. Dies ist in Formel B.17 dargestellt.
KostenG2
KostenStrecke
EU R
EU R
= KostenGesamt
× DIST
km
km
(B.17)
Die hier aufgeführten Formeln wurden in einer JAVA-Anwendung integriert. Diese
Anwendung stellt eine erste Version des Emissions- und Kostenkalkulators dar und kann
in der Beilage zu dieser Ausarbeitung gefunden werden.
362
Fazit
Die Berechnung von Kosten und Emissionen eines Elektroautos ist zum jetzigen Zeitpunkt nicht ohne weiteres möglich, da eine Menge verschiedener Faktoren einen Einfluss
haben. Dabei können viele der Parameter auf Grund der bisher verschwindend geringen
Anzahl an Elektroautos auf den deutschen Straßen nicht eindeutig bestimmt werden.
Aus diesem Grund basieren sie teilweise auf den Werten herkömmlicher Fahrzeuge oder
müssen auf Basis von Berechnungen, welche in diversen wissenschaftlichen Studien vorgenommen wurden, angenommen werden.
Die hier entwickelten Formeln verbinden also Faktendaten, wie zum Beispiel die Anschaffungskosten der Elektroautos oder die durchschnittlichen Emissionen aus den einzelnen Energiequellen, mit denjenigen Daten, welche zum jetzigen Zeitpunkt noch nicht
genau bestimmt werden können. Zu diesen Daten gehören zum Beispiel die durch den
Akkumulator verursachten Emissionen.
Aus diesem Grund ist die absolute Richtigkeit der Berechnungen nicht gewährleistet,
da zum aktuellen Zeitpunkt noch zu viele unsichere Faktoren eine Rolle spielen. Weiterhin liefern die verschiedenen Studien für diese unsicheren Werte teilweise sehr unterschiedliche Ergebnisse, je nachdem welche Ziele die Auftraggeber der Studien verfolgt
haben. Eine Überprüfung der Kalkulationsergebnisse ist auf Grund des fehlenden praktischen Einsatzes von Elektroautos zum aktuellen Zeitpunkt noch nicht möglich.
Es lässt sich also festhalten, dass die Ergebnisse dieser Arbeit einen Richtwert für den
durchschnittlichen Verbrauch und für die durchschnittlichen Kosten eines Elektroautos
zum jetzigen Zeitpunkt liefern. Allerdings ist zu erwarten, dass die sehr dynamische Technologieentwicklung eine stetige Anpassung der verwendeten Parameterwerte erfordert,
damit auch in Zukunft zuverlässige Werte errechnet werden können.
363
Betrachtung klassischer
Kundenbindungsinstrumente und ihrer Eignung
für die Förderung der Nutzung von
nachhaltigen Verkehrsmitteln
Carl Mahnke
[email protected]
Zusammenfassung Diese Seminararbeit zeigt die in der Literatur vorherschenden klassischen Kundenbindungsinstrumente auf und nimmt
daraufhin konkrete Adaptionen für den Dienst Jinengo vor.
Schlüsselwörter Kundenbindung, Kundenzufriedenheit, Kundenbeziehung, CRM, Kundenbindungsinstrumente
Einleitung
Diese Arbeit geht der Frage nach in wie fern mittels der klassischen Kundenbindungsinstrumente eine Kundenbindung für den Dienst Jinengo erreicht werden kann. Jinengo
ist ein geplanter Webdienst zur nachhaltigen Mobilitätsplanung.
In der Literatur ist ständig von der Bedeutung der Kundenbindung zu lesen, da die
Kosten zur Kundenbindung wesentlich unter denen der Kundenakquise liegen. Dieser
Rechnung folgend kann je nach Kundenakquisitionskosten und Marktgegebenheiten bares Geld gespart werden. Die Frage, wer denn woran gebunden wird, soll bereits hier in
der Einleitung geklärt werden. Nach dem Arbeitstitel dieser Arbeit müsste davon ausgegangen werden, dass Kunden direkt an nachhaltige Verkehrmittel gebunden werden
sollen. Dies wäre der Fall wenn sich der Kunde eine Monatskarte für den ÖPNV besorgt.
Da diese Sichtweise nicht ganz zweckmäßig für die Entwicklung des Dienstes Jinengo ist
erfolgt an dieser Stelle eine Uminterpretation. Ziel soll es sein den Kunden an den Dienst
Jinengo und dessen Nutzung zu binden. Hierüber kann, und das liegt sodann an der Ausgestaltung des Dienstes selbst, eine Förderung der Nutzung nachhaltiger Verkehrmittel
erreicht werden. Das ist sodann vor allem davon abhängig welche Transportmittel vermittelt werden und wie deren Nachhaltigkeit einzustufen ist. Denkbar ist beispielsweise,
dass der Dienst Jinengo auch Pkw-Mobilität als Alternative auflistet. Daraus wird ersichtlich, dass die Nutzung des Dienstes nicht zwangsweise zu nachhaltiger Mobilität
führt. Dieses Problem ist jedoch nicht Bestandteil dieser Arbeit und wird nicht weiter
behandelt.
364
Im Fokus wird die Kundenbindung an den Dienst Jinengo stehen. Der erste Teil dieser
Arbeit legt den theoretischen Grundstein zur Kundenbindung während der zweite Teil
konkrete Ideen für den Dienst Jinengo vorbringt.
Teil I – Theorieteil
Allgemeines zur Kundenbindung
Der Begriff der Kundenbindung beschreibt Zustand und Methode zugleich [71, S. 99ff.].
Einerseits sind Kunden aus unterschiedlichsten Gründen an Produkte oder deren Anbieter gebunden und befinden sich damit im Zustand der Bindung. Andererseits steht der
Begriff Kundenbindung für ein betriebswirtschaftliches Konzept nach dem es ökonomisch
erstrebenswert ist Kunden in eine Bindung zu bringen. Dazu brachte die Betriebswirtschaftslehre neben theoretischen Basen 1 auch eine Vielzahl von praktischen Kundenbindungsinstrumenten hervor. An ein Produkt oder Anbieter gebunden zu sein meint
in diesem Zusammenhang, dass der Kunde regelmäßig bzw. ausschließlich Produkte von
diesem Anbieter in der Vergangenheit erworben hat und die Absicht hat dies auch in
Zukunft zu tun.
Seit den 1990er Jahren ist das Konzept der Kundenbindung paradigmatisch. Vor dieser
Zeit und besonders seit den 1960er Jahren, lag der Fokus von Unternehmen hauptsächlich
in der Kostenorientierung. Der Wandel und damit die Abkehr von diesem Konzept wurde
durch steigenden Wettbewerb ausgelöst. 2 Nach dieser Beobachtung müsste man konstatieren: Je mehr Wettbewerber auf einem Markt teilnehmen, desto größer ist die Gefahr
der Kundenabwanderung. Diese Aussage soll an späterer Stelle nochmals untersucht
werden.
Auf den ersten Blick scheint der Kunde mit einer Bindung stets Nachteile zu erfahren. Dabei bietet die Kundenbindung jedoch zwei Sichtweisen an. Die Anbietersicht
beleuchtet die Vorteile einer Bindung für den Anbieter wohingegen die Nachfragersicht
die Vorteile des Kunden aufgreift. Aus informationsökonomischer Sicht bindet sich beispielsweise ein Kunde selbst und freiwillig wenn er mit der aktuellen Leistung zufrieden
ist und die Leistungen anderer Anbieter im Falle eine Erfahrungsgutes im Vorfeld nicht
beurteilen kann. Dazu später mehr. Zum Abschluss sowie als Leitbild für alle folgenden
Abschnitte soll hier noch die Lehrbuchdefinition der Kundenbindung dargeboten werden:
Kundenbindung umfasst sämtliche Maßnahmen eines Unternehmens, die
”
1
Wie noch an späterer Stelle ausgeführt stammen diese Basen aus unterschiedlichen Theoriezweigen,
hauptsächlich jedoch aus der Verhaltenswissenschaft sowie aus der Informationsökonomik. Nach Dieter Schneider, welcher sich stets für die Abkehr der Betriebswirtschaftslehre von der Verhaltenswissenschaft einsetzt, wäre dieses Theoriengemenge wenig zweckmäßig. [72]
2
Dies geschah und geschieht vor allem durch Globalisierung.
365
darauf abzielen, sowohl die Verhaltensabsichten als auch das tatsächliche
Verhalten eines Kunden gegenüber einem Anbieter oder dessen Leistungen
positiv zu gestalten um die Beziehung zu diesem Kunden für die Zukunft zu
stabilisieren bzw. auszuweiten.“ [73, S.8]
Typologisierung von Bindungsursachen
In der Literatur herrschen diverse Typologisierungen von Kundenbindungsursachen, die
mehr oder minder zweckmäßig sind und starke Deckungsgleichheit aufweisen [73, S. 10f.].
3 Bliemel/Eggert beschreiben eine Zweiteilung von Bindungsursachen mittels Differenzierung von Verbundenheit und Gebundenheit.4 Bei der Verbundenheit führen psychologische Prozesse dazu, dass eine Zuneigung zum jeweiligen Unternehmen bzw. Produkt aufgebaut wird und somit ein Wechsel unterbleibt. Grundlage ist also ein Nicht”
wechseln-wollen“. Verbundenheit entsteht demnach wenn mit zurückliegenden Kaufentscheidungen positive Erfahrungen gemacht wurden und sich somit Zufriedenheit beim
Käufer einstellt. 5 Im Gegensatz dazu führt die Gebundenheit zu Einschränkungen der
Handlungsalternativen. Solche Restriktionen werden zumeist durch den Anbieter initiiert und binden den Kunden durch ein Nicht-wechseln-Können“. Der Kunde begibt sich
”
in diese Art der Bindung da die Nachteile durch entsprechende Vorteile kompensiert werden [71, S. 104f.].
Eine Ähnliche Typologisierung zeigen Bruhn/Homburg auf [73, S. 10]. Demnach lassen
sich Bindungsursachen in habituelle, freiwillige und unfreiwillige unterscheiden. Während
die freiwillige Bindung dem Konzept der Verbundenheit und unfreiwillige Bindung dem
Konzept der Gebundenheit entspricht wird dieser Ansatz durch die Idee der habituellen
Bindung erweitert. Habituelles Verhalten steht dabei für Gewohnheitshandeln. Diese,
psychisch bedingte Gewohnheit veranlasst Käufer ebenfalls einen Wechsel zu unterlassen.
Weitaus praktischer angelegt und maßgebend für diese Arbeit ist eine Gliederung der
Kundenbindungsursachen in 5 Bereiche [73, S. 10]. Es handelt sich dabei um:
Situative Bindungsursachen
Vertragliche Bindungsursachen
Ökonomische Bindungsursachen
Technisch-funktionale Bindungsursachen
Psychologische Bindungsursachen
3
Vgl. ebenfalls [74, S. 48] und [75, S. 748].
Vgl. Bliemel/Eggert 1998, S. 37ff. zit. in [76, S. 7]
5
Von Bedeutung ist hierbei nicht nur der Aufbau einer positiven Einstellung gegenüber dem Produkt
und dem Anbieter sonder auch gegenüber Marken. Siehe hierzu [77].
4
366
Diese Bindungsursachen seien im Folgenden kurz ausgeführt [73, S. 10f.]. Eine situative Bindung liegt vor wenn zumeist räumliche oder zeitliche Gegebenheiten den Kunden zu einem Wiederkauf bewegen. Genereller ausgerückt bindet hier die Beschaffenheit
des Marktes den Kunden an ein Angebot. Kunden die beispielsweise nachts einkaufen
möchten sind zumeist auf das Angebot von Tankstellen angewiesen.
Die vertragliche Bindung stellt die klassische und auch die stärkste Form der Kundenbindung dar. Dabei hat der Kunde i.d.R. für einen gewissen Zeitraum keine rechtliche
Möglichkeit den Anbieter zu wechseln oder es fallen Vertragsstrafen an. Obwohl diese
Form der Kundenbindung starke Einschnitte in die Entscheidungsfreiheit des Kunden
macht ist diese Art auch heute noch sehr häufig anzutreffen.
Unter ökonomischen Bindungsursachen versteht man jene, die die Käufer aufgrund von
Kosten, welche bei Beendigung der Geschäftsbeziehung anfallen am Wechseln des Anbieters oder des Produktes hindern. Dieses Konzept greift sehr weit und je nachdem
wie ebendiese Beendigungskosten geartet sind lässt sich beinahe jede, nicht psychische
Bindung damit erklären. Bei der technisch-funktionalen Bindung wird eine Abhängigkeit
zu bereits erworbenen Gütern unterstellt. So sind Systemkomponenten unterschiedlicher
Anbieter teilweise inkompatibel zueinander. Hat sich der Kunde erst einmal für einen
Anbieter eines Systems entschieden so ist er in der Hinsicht an ihn gebunden als dass er
mit einem Anbieterwechsel die alten Systemkomponenten nicht weiter verwenden könnte.
Zuletzt seien die psychologischen Bindungsursachen erwähnt. Hierunter fallen beispielsweise die Bindung durch Zufriedenheit, persönliche Beziehungen sowie durch Gewohnheit. Verglichen mit der vorigen Typologisierung fällt umgehend auf, dass die psychologische Bindung weitestgehend einer freiwilligen Bindung entspricht während situative,
vertragliche, ökonomische und technisch-funktionale Bindung einer unfreiwilligen Bindung entsprechen. In der Literatur ist man sich einig darüber, dass, sofern möglich, die
freiwillige der unfreiwilligen Bindung vorzuziehen ist. Diese freiwillige Bindung, oder
auch Gebundenheit, wird insbesondere durch Zufriedenheit 6 hervorgebracht [78, S. 95
ff.]. 7
Theorien zur Kundenbindung
Zunächst soll betrachtet werden welche Erklärungsansätze die Neue Institutionenökonomik zu bieten hat. Zu ihren Teildisziplinen zählen unter anderem die Principal-AgentTheorie, die Informationsökonomik sowie die Transaktionskostentheorie. Im Gegensatz
zur Neoklassik werden hier Annahmen wie Unsicherheit, Informationsasymmetrien, be6
Sooft der Begriff Zufriedenheit“ auch genannt wird so unklar ist auch sein eigentliches Wesen. Oft”
mals bleibt eine Definition aus. Für diese Arbeit gilt folgendes Verständnis: Zufriedenheit tritt ein,
sofern die erworbene Leistung der Erwartung entspricht oder diese übertrifft. Das Konzept ist, im
Verständnis dieser Arbeit, verhaltenswissenschaftlich als auch ökonomisch anwendbar.
7
Vgl. ebenfalls [73, S. 11 ] sowie [76, S. 7 ] sowie [71, S.100ff.].
367
schränkte Rationalität sowie Opportunismus explizit mit berücksichtigt [79, S. 54].
8
Transaktionskosten nehmen im Transaktionskostenansatz die zentrale Rolle ein, wobei
es konkret um die Ausgestaltung von Institutionen unter Kostenaspekten geht [75, S.
92ff.].9 Die optimale Koordinationsform einer Transaktion bewegt sich im Spannungsfeld
zwischen Markt und Hierarchie und wird dabei maßgeblich durch die Höhe der Transaktionskosten determiniert. Letztere lassen sich gliedern in Anbahnungs-, Aushandlungsund Kontrollkosten sowie Kosten der Durchsetzung von Verträgen. Die Transaktionskosten steigen mit Unsicherheit, Spezifizität und Häufigkeit, sodass die Koordinationsform Markt ungünstiger und die Hierarchie günstiger wird. Hierarchie kann in diesem
Zusammenhang den Abschluss von Verträgen bedeuten was einer Bindung entspricht.
Jedoch wird rückblickend deutlich, dass die Transaktionskostentheorie eher bei komplexen Kaufentscheidungen, welche im Business-to-Business-Bereich anzutreffen sind, Erklärungspotenzial bietet. Dennoch ist die Verbindung zum bereits vorgestellten Konzept
der ökonomischen bzw. vertraglichen Bindung unverkennbar. Die Wahl der Hierarchie
als Koordinationsform in Form von Verträgen um Transaktionskosten einzusparen führt
in eine Bindung. Fraglich bleibt inwiefern dieser Theorieansatz für private Kaufentscheidungen gilt.
Die Informationsökonomik gibt Aufschluss über das Maß an Unsicherheit, welche bei der
Kaufentscheidung vorliegt, indem Leistungseigenschaften einer Beurteilungskategorie zugewiesen werden [81, S. 811]. Sucheigenschaften sind logisch vor dem Kauf bzw. Vertragsabschluss vom Nachfrager direkt beurteilbar und verändern sich durch den Erwerb der
Leistung nicht. Beispielhaft sei hier auf die Farbe eines Autos oder die Verarbeitungsqualität einer Armbanduhr verwiesen. Von Erfahrungseigenschaften wird gesprochen,
wenn die Leistungsmerkmale logisch erst nach dem Kauf oder Vertragsabschluss bzw.
während der Erstellung sichtbar und beurteilbar werden. Die letzte Kategorie beinhaltet
Leistungsmerkmale die logisch weder vor noch nach dem Kauf vom Nachfrager beurteilt
werden können, d.h. eine Überprüfung durch den Nachfrager niemals möglich ist. Man
spricht hier von Vertrauenseigenschaften [82, S. 104ff.]. Im Fokus der Kundenbindung
sind insbesondere Vertrauenseigenschaften interessant. Ein optimistischer Käufer wird
nach dem Erstkauf und nach der Beurteilung der Leistung annehmen er habe eine gute
Qualität erhalten und wird den Anbieter beim Wiederholungskauf nicht wechseln. Er
bindet sich somit selbst. Ein pessimistischer Käufer wird dagegen solange den Anbieter
wechseln bis er der Meinung ist den Marktdurchschnitt erkannt zu haben. Danach wählt
der die Leistung mit der höchsten, ihm bislang bekannten Qualität. Fraglich bleibt auch
hier inwieweit diese Erkenntnisse praktisch genutzt werden können um den Zustand der
Kundenbindung herbeizuführen.
Aus verhaltenswissenschaftlicher Sicht lassen sich insbesondere die Risikotheorie, die
Lerntheorie sowie die Dissonanztheorie nennen [73, S. 14f.]. Nach der Risikotheorie sind
Individuen bestrebt ihr subjektives Risiko zu minimieren wobei zwischen funktionalen,
8
9
Siehe hierzu ebenfalls [80, S. 4]
Grundlegend geht dieser Ansatz auf Williamson (1975) zurück.
368
physischen, psychologischen und sozialen Risiken unterschieden wird. Kunden binden
sich demnach an Leistungen oder Anbieter um Risiken zu entgehen die bei einem Wechsel bestehen könnten, da Unsicherheit besteht 10 . Die Lerntheorie besagt hingegen, dass
Verhalten, welches positive Wirkungen hatte, vom Individuum selbst verstärkt wird und
somit erneut angewendet wird. Tritt nach einem Kauf also Zufriedenheit (im Sinne eines positiven Gefühls) auf, so ist ein Wiederkauf nach dieser Theorie wahrscheinlich.
Der Kunde bindet sich damit selbst. Bei der Dissonanztheorie versucht das Individuum
Dissonanzen, also innere Spannungen, abzubauen indem es dissonanzabbauende Informationen vermehrt sucht und aufnimmt und dissonanzerhöhende Informationen meidet.
Langfristige Beziehungen könnten hierdurch erklärbar sein. Insgesamt hingegen bieten
die verhaltenswissenschaftlichen Ansätze keine zufrieden stellenden Theorien bezüglich
der Kundenbindung an.
Interessant hingegen, und hier besitzt die Verhaltenswissenschaft einen Vorteil gegenüber
ökonomischen Theorie, ist der Ideelle Nutzen der Marke [83, S. 13].11 Diese symbolische
Funktion der Marke ist ein soziales Phänomen. Marken(-artikel)-Konsumenten betreiben über den mehr oder weniger sichtbaren Konsum eine Kommunikation der eigenen
Persönlichkeit oder aber sie internalisieren diejenigen Werte für die die Marke steht, um
ihr Eigenbild erst zu definieren [77, S. 12].12 Marken binden also auch Kunden wobei
man vereinfachend den Markennutzen dem globalen Produktnutzen zurechnen kann.
Ebenso bieten sich Erklärungsversuche aus sozialpsychologischer und interaktionsorientierter Perspektive an die in dieser Arbeit jedoch nicht weiter betrachtet werden sollen [73, S. 12ff.].13 Am Ende bleibt festzuhalten, dass es keine geschlossene Theorie der
Kundenbindung gibt. Vielmehr bedient sich die Wissenschaft einer Vielzahl von Partialtheorien wodurch mitunter der Eindruck eines Flickenteppichs entsteht. Andererseits
scheinen die Gründe der Kundenbindung derart vielfältig, dass die Suche nach einer
Einheitstheorie an dieser Stelle vergebens wäre.
Kundenbindungsinstrumente
Instrumente der Kundenbindung kommen im operativen Kundenbindungsmanagement
zum Einsatz. Dabei ist in der Praxis häufig zu beobachten, dass Instrumente isoliert,
also ohne Abstimmung zueinander, verwendet werden [73, S. 20ff.]. Das führt oftmals
dazu, dass das Potenzial der Instrumente weniger ausgeschöpft wird. Wie auch Marketinginstrumente lassen sich die Bindungsinstrumente den Bereichen der Produkt-, Preis, Kommunikations- und Distributionspolitik zuordnen. Im Bereich der Produktpolitik
konzentrieren sich die Instrumente auf Faktoren wie Produktqualität und Value-Added10
Implizit wird hier das Konzept der Informationsökonomik, insbesondere das der Vertrauensgüter zu
Gunde gelegt.
11
Siehe außerdem [84, S. 44] sowie [85, S. 3].
12
Vgl. ebenfalls [86, S. 68ff].
13
Tatsächlich lassen sich diese Ansätze ebenfalls zur Verhaltenswissenschaft zählen.
369
Services. Preispolitische Bindungsinstrumente schaffen eine Bindung über spezielle Preissysteme unter Zuhilfenahme von Preisgarantien und Preisdifferenzierungen. Im Feld der
Kommunikation sind jene Instrumente angesiedelt, welche den Dialog zwischen Anbieter
und Kunden ermöglichen oder intensivieren. Hier liegt die Vermutung nahe, dass mittels
CRM-Systeme die Kommunikation noch wirkungsvoller gestaltet werden kann, weshalb
hierzu ein eigenes Kapitel an späterer Stelle angeführt wird. Distributionspolitisch sind
Instrumente eingeordnet, welche Kundenbindung durch die Art der Distribution bewirken. Hierzu zählen bequeme Bestellmöglichkeiten oder Abonnements.
Die Wirkungen der hier Vorgestellten Instrumentenbereiche lassen sich nach den drei
Fokussen Interaktion, Zufriedenheit sowie Wechselbarrieren einteilen, je nachdem wie
die primäre Wirkung des jeweiligen Instrumentes geartet ist. Damit lässt sich nun eine
Matrix aufspannen wie in Abbildung B.8 dargestellt. Die dort aufgeführten Instrumente
sind lediglich als exemplarisch zu betrachten, da eine fülle weiterer Instrumente daneben
bestehen. Homburg/Bruhn betonen ganz besonders, dass diese Instrumente aufeinander
abgestimmt werden müssen wobei eine Kundenbindungsstrategie als Grundlage dient [73,
S. 23].
Kundenbindung in unterschiedlichen Marktsituationen
Dieser Abschnitt betrachtet Einwirkungen auf die Kundenbindung die sich in Abhängigkeit von der Marktsituation ergeben. So ist eine Differenzierung in alte und neue Märkte
sinnvoll, wobei gerade letztere für diese Arbeit von Interesse sind [87, S. 145ff.].
Neue Märkte entstehen dort, wo Anbieter gänzlich neue Produkte in neuen Marktsegmenten anbieten oder, in abgeschwächter Form, in neuartige Produkte in bereits bestehenden Marktsegmenten anbieten. Man spricht hier auch von jungen Märkten. Ebenso
ist es denkbar, dass durch den Beitritt neuer Wettbewerber die Spielregeln eines Marktes
derart neu gestaltet werden, dass auch hier von einem neuen Markt gesprochen werden
kann. Dies ist insbesondere der Fall wenn einstige, staatliche, monopolistische Märkte
liberalisiert werden. Diese Märkte werden auch als aufbrechende Märkte bezeichnet. Laker/Pohl/Dahlhoff unterscheiden demnach drei Fälle [87, S. 147]. Auf der einen Seite
stehen die etablierten Märkte bei denen alte Anbieter alten Kunden alte Produkte anbieten. Auf der anderen Seite hingegen stehen die neuen Märkte, gegliedert in jungeund aufbrechende Märkte.
Abbildung B.9 zeigt auf welche Merkmale Kunden aufweisen, je nachdem in welchem
Markt sie agieren. Hieraus ergeben sich sogleich Auswirkungen auf die Kundenbindung
sowie Kundenbindungsmaßnahmen.
Einige Punkte der Abbildung B.9 sollen hier kurz diskutiert werde. Die möglicherweise
wichtigste Erkenntnis ist jene, dass auf neuen Märkten eine erhöhte Wechselbereitschaft besteht. Laker/Pohl/Dahlhoff erklären diese damit, dass Kunden keine Erfahrung
370
Abbildung B.8.: Kundenbindungsinstrumente im Überblick [73, S. 10]
371
Abbildung B.9.: Merkmale von Kunden in alten und neuen Märkten [87, S. 149]
372
bezüglich des Anbieters bzw. deren Produkt haben [87, S. 148]. 14 Wechselbereitschaft
stellt einen Gegenpol zur (freiwilligen) Kundenbindung dar, wo ein Wechsel nur möglich
ist, sofern Alternativanbieter existieren.
Die Angebote sowie die Kundenansprache erfolgen auf neuen Märkten undifferenziert,
da noch keine Kenntnisse bezüglicher der Kunden oder ihrer Präferenzen vorliegen. Als
Konsequenz erfolgt daher eine einheitliche Kundenansprache. Interessant ist in diesem
Zusammenhang welchen Einfluss ein CRM-System im Verlauf der Geschäftsbeziehung
gewinnen kann. Das nachfolgende Kapitel wird sich unter anderem mit dieser Frage
beschäftigen.
Markenimages von Produkten und Anbietern sind i.d.R. auf neuen Märkten noch nicht
geprägt. Somit kann die Marke anfangs wenig zur Kundenbindung beitragen, da sie sich
noch nicht in den Köpfen der Kunden festgesetzt hat. Umso wichtiger ist es jedoch von
Anfang an eine zielführende Markenpolitik zu betreiben.
Für junge Märkte ergibt sich zudem noch die Besonderheit, dass Kunden zumeist eine
Erstkaufentscheidung treffen. Bei dieser Erstentscheidung kann das Bild des Anbieters
oder des Produktes maßgeblich geprägt werden. Ist der Kunde dabei bspw. wegen der
Qualität des Produktes nicht zufrieden so wird er den Anbieter wechseln. Eine Kundenbindung wäre dann für diesen Kunden ausgeschlossen.
Zu bedenken gilt auf jungen Märkten außerdem das Prinzip der kritischen Masse. Der
Wettbewerber, der es versteht schnell möglichst viele Kunden an sich zu binden kann
daraus eine marktbeherrschende Stellung einnehmen. Besonderes Gewicht hat solch eine
Position, wenn der Nutzen des Produktes mit Nutzerzahl steigt oder es sich bei dem Kauf
um eine Systementscheidung handelt. Die Kundenbindung hätte in einem solchen Fall
einen selbstverstärkenden Effekt. In dieser Markteroberung spielt die Kundenakquisition
eine mindestens genau so große Rolle wie die Kundenbindung.
Lake/Pohl/Dahlhoff ziehen am Ende drei Punkte als Schlussfolgerung für Kundenbindung auf neuen Märkten.15 Erstens raten sie von klassischen Kundenbindungsinstrumenten ab, da Kunden diesen skeptisch gegenüberstehen und sie als Köderversuch“
”
bewerten. Die Folge wäre sodann eine Meidung des Angebots. Vielmehr sollten Anbieter
versuchen den Kunden zu binden indem er zufrieden gestellt wird. Dies geschieht, indem
die Produktqualität entsprechend hoch ist und ggf. entsprechende Value-added-Services
geboten werden.
Zweitens wird Anbietern geraten bereits frühzeitig eine umfassende Kundenbindungsstrategie auszuarbeiten, damit ein späterer Einsatz von klassischen Kundenbindungsin14
Diese Erklärung deckt sich auch mit den Erkenntnissen der Informationsökonomik die im Vorfeld
dargelegt wurden.
15
Im Original sind es vier Punkte wobei zwei Punkte davon für diese Arbeit aufgrund ihrer Ähnlichkeit
zusammengefasst wurden.
373
strumenten reibungslos erfolgen kann.
Besonderes gewicht, und das ist der dritte Punkt, ist der ersten Marktphase einzuräumen,
da hier auch über den langfristigen Erfolg mit entschieden wird. Markenimage und
Marktposition erfahren in dieser Phase eine wichtige Prägung.
Kundenbindung im Kontext von CRM
Das Akronym CRM steht ausgeschrieben für Customer Relationship Management und
könnte im Deutschen mit Kundenbeziehungsmanagement übersetzt werden. Der Kern
dieses Konzeptes ist also die Beziehung des Kunden zum Unternehmen [88, S. 437 ff.].
In der Praxis wird CRM häufig auf eine technische Lösung reduziert. Dies ist jedoch
unzulänglich. CRM ist die ganzheitliche Abbildung des Kunden im Unternehmen sowie
die gezielte Ausrichtung sämtlicher Prozesse auf den Kunden. Technische Lösungen wie
Soft- und Hardware sowie Infrastruktur sind in diesem Zusammenhang als CRM-Tools
anzusehen, die dem Ziel der ganzheitlichen Abbildung unterstützend dienen.
Mehrwerte generierte das CRM auf Unternehmens- wie auch auf der Kundenseite. Das
Unternehmen sammelt und gewinnt Kundenpräferenzen durch die zentrale Speicherung von Kundendaten. Durch diese Zentralisation können Prozesse ebenfalls effizienter
gestaltet werden. Zuletzt kann auch die Kundenzufriedenheit und damit seine Loyalität gegenüber dem Unternehmen gesteigert werden indem das Unternehmen individuelle Leistungen gemäß den jeweiligen Kundenpräferenzen anbietet. Solch eine MassCustomization ist je nach Leistungsart von unterschiedlicher Relevanz.
Der Kunde profitiert vom CRM indem das Unternehmen bei Kundenanfragen stets alle Kundendaten vorliegen hat, unabhängig davon welchen Kommunikationskanal der
Kunde wählt. Ebenso erhält der Kunde sodann auf seine Präferenzen abgestimmt Kundenansprachen, welche für ihn besonders nützlich sind. Im Falle der Mass-Customization
kann die Zufriedenheit des Kunden gesteigert werden indem das Produkt möglichst den
Wünschen des Kunden entspricht. Richtig eingesetzt bewirkt das CRM somit eine WinWin-Situation.
Teil II – Adaption an Jinengo
Einführung zu Jinengo
Im Rahmen der studentischen Projektgruppe mit dem Titel Sustainable Customer Re”
lationship Management für EMobility Services mit SOA“ entwickeln die Teilnehmer über
den Zeitraum von zwei Semestern eine Anwendung zur nachhaltigen Reiseplanung sowie
374
Abbildung B.10.: Kundenbindung im Kontext von CRM [89, S. 20]
ein adäquates Geschäftsmodell. Diese Anwendung wird über das Internet distribuiert
und kann mittels Browser auf PC sowie Handhelds genutzt werden. Kernleistung ist
die Reiseplanung, wobei nach Eingabe eines Anfangs- und Endpunktes dem Nutzer eine
Auswahl an unterschiedlichen Transportmitteln gegeben werden soll. Diese Auswahlalternativen als Information stellen das Kernprodukt von Jinengo dar. Besonderheit und
ebenfalls zur Kernleistung gehörend sind spezielle Informationen der Transportmittel
hinsichtlich ihrer Nachhaltigkeit. Der Nutzer kann sodann, je nach seinen Präferenzen,
eine freie Auswahl des Transportmittels treffen und die Umwelt schützen.
Klassifizierung Jinengo als Dienstleistung
An dieser Stelle soll nun Jinengo als Dienstleistung klassifiziert werden, da sich hieraus
Konsequenzen für das folgende Kundenbindungskonzept ergeben. So sind beispielsweise
gewisse Bindungsmaßnahmen aufgrund der Beschaffenheit der Dienstleistung von vorne
herein ausgeschlossen.
Hierzu soll die Dienstleistung Jinengo aus dienstleistungstheoretischer Sicht betrachtet
werden. Einen Einstieg vermittelt Abbildung B.11, die die Dienstleistung in ihre Phasen
zerlegt. Daraus folgen bereits Konsequenzen.
Die Qualität des erstellten Gutes ist abhängig von den einzubringenden Faktoren. Hierzu zählen die Potenzialfaktoren des Anbieters sowie die Fremdfaktoren des Nachfragers.
Kundenbindungspolitisch ist dies von Belang, da bindungsfördernde Kundenzufriedenheit maßgeblich über die erreichte Leistungsqualität erzielt wird.
Weiterhin wird ersichtlich, dass das Gut, welches erstellt wird, am Ende eine immaterielle Information ist. Diese ist flüchtig, nicht lagerfähig und kann mit dem Zeitverlauf
ihren Wert verlieren. Nicht als Gut deklariert werden kann hingegen der Leistungserstellungsprozess, der hier vielmehr eine zeit- und aufmerksamkeitskostende Notwendigkeit
375
Abbildung B.11.: Phasenbezogene Definition der Dienstleistung Jinengo [90, S. 15]
darstellt.16 Nachfragerkosten sollten möglichst gering gehalten werden um die Kundenzufriedenheit zu steigern.
Detailliertere Einblicke liefert das mehrdimensionale Eigenschaftsprofil von Jinengo in
Abbildung B.12. Einige Punkte mit wichtigen Auswirkungen seien kurz vorgestellt.
Da der Service aufgrund seiner Automatisiertheit ausschließlich über Endgeräte wie
Handhelds und Personalcomputer bezogen wird ist er als sehr unpersönlich einzustufen.
Eine Kundenbindung über eine persönliche Mensch-zu-Mensch-Beziehung, wie sie die
Verhaltenswissenschaft voraussagt, ist somit im Hauptgeschäftsprozess nicht gegeben.
Wie oben bereits angeführt sind der Leistungserstellungsprozess sowie auch die Leistung später selbst immateriell und flüchtig. Eine technisch-funktionale Kundenbindung
im Sinne einer Systemlösung ist daher ebenfalls ausgeschlossen, weil zu späterer Zeit
erworbene Leistungen nicht an früher erworbene Leistungen anknüpfen können, da diese
verflüchtigt sind.
Konsumtiv bedeutet in diesem Zusammenhang, dass der Kunde die Leistung zu seinem
eigenen Nutzen verzehrt und dass die Leistung somit nicht Bestandteil einer weiteren
Leistung wird. Dies wäre der Fall wenn die Leistung investiv wäre und von institutionellen Buyern beschafft würde. Während jedoch diese Buyer ihre Beschaffungsentscheidung
gegenüber Vorgesetzten rechtfertigen müssen, sind private Konsumenten nur gegenüber
sich selbst verantwortlich. In der Literatur gibt es deshalb die Vermutung, dass private
Käufer eher emotional und weniger rational entscheiden, da sie keinem Rechtfertigungszwang unterliegen. Solche emotionalen Beeinflussungen sind insbesondere im modernen
Markenmanagement anzutreffen, womit sich hier ein Anknüpfungspunkt zur Kundenbindung ergeben würde.
16
Den Leistungserstellungsprozess als Gut kann man beispielsweise im Theater beobachten.
376
Individualität ist bei der Leistung von Jinengo bedingt gegeben. Die Informationen die
der Nachfrager bei dem Leistungserstellungsprozess mit einbringt sind im als Parameter
zu verstehen wobei das Leistungsergebnis sodann sehr Individuell ist. Auf der anderen
Seite bleibt das Ergebnis stets in einem engen Schema, womit sich die Individualität stets
auf den Sach- bzw. Informationscharakter des Ergebnisses beziehen. Eine Individualität
im Sinne der Äußerung eines Wunsches“ oder kreativen Elementen im Ergebnis“ ist
”
”
im Kern der Leistung nicht vorgesehen. Dabei könnte gerade mit dieser Art der Individualität die Kundenzufriedenheit gesteigert werden und somit auch die Kundenbindung.
Zuletzt sei noch auf das Stichwort Diskretheit“ eingegangen. Die vorliegende Dienstleis”
tung Jinengo wird diskret bezogen, das heißt, dass stets ein ganzer Leistungserstellungsprozess vollzogen werden muss, jedoch nicht mehr und nicht weniger. Ein kontinuierlicher Konsum, also in kleineren oder größeren Mengen ist nicht möglich. Kundenbindung
bedeutet in diesem Fall, dass der Nachfrager in dem Sinne gebunden ist, dass er Folgetransaktionen unternimmt und nicht, dass er die Leistung intensiver bzw. länger an
einem Stück nutzt.
Konkretes Kundenbindungskonzept
Dieser Abschnitt soll nun ein ganzheitliches Kundenbindungskonzept darlegen. Dazu
werden erst mögliche und sinnvolle Kundenbindungsmaßnahmen, aufgeschlüsselt nach
ihrem Instrumentenbereich, aufgezeigt und im Anschluss ein abgestimmtes Konzept daraus gebildet. Maßgeblich für die Kategorien ist Abbildung B.8.
Preispolitische Instrumente
Für die Dienstleistung Jinengo und ihre mögliche Preispolitik ergibt sich eine Besonderheit. Zum Zeitpunkt der Anfertigung dieser Arbeit war noch nicht abschließend klar wie
das Preismodell aussehen wird. Dabei ist es auch eine Variante, dass die Leistung für
den Endkunden kostenlos zur Verfügung gestellt wird. Damit könnten die klassischen
preispolitischen Instrumente nicht angewendet werden.
Lihotzky stellt dabei fest, dass aber auch kostenlose Angebote an sich eine bindende Wirkung haben. Der Nachfrager wird von der Suche nach günstigeren Anbietern entbunden
und spart dadurch Zeit und kognitive Anstrengungen. Dies gilt jedoch nur, sofern der
Nachfrager mit der Leistung des Anbieters zufrieden war [91, S. 124]. Für kostenlose
Angebote wäre demnach die Kundenakquise bzw. die Ersterreichung der Kunden von
hoher Bedeutung.
Für den Fall, dass dennoch eine Bepreisung des Dienstes Jinengo in Erwägung gezogen
wird seien im Folgenden mögliche Instrumente hierzu vorgestellt. Denkbar und realistisch
377
Abbildung B.12.: Mehrdimensionales Eigenschaftsprofil für Jinengo [75, S. 47]
378
Abbildung B.13.: Beispiel für regressives Preismodell (Quelle: Eigene Darstellung)
ist der Kontingentkauf von Transaktionen. Eine Transaktion ist in diesem Zusammenhang die einmale, vollständige Inanspruchnahme des Dienstes. Koste der Dienst demnach
einzeln abgerufen 50 Cent, so könnten Kontingente mit 20, 50 und 100 Transaktionen
angeboten werden, wobei der Stückpreis der einzelnen Transaktion mit der Größe der
Kontingente abnimmt. Die Bindung würde dadurch hervorgebracht werden, dass der
Kunde bereits in Vorleistung tritt und sich aufgrund eines Preisvorteils selbst bis zum
Aufbrauchen des Kontingents an den Anbieter bindet. Das Kontingentverfahren setzt
jedoch Vertrauen des Nachfragers in den Anbieter voraus, da er sich in eine ökonomische
Bindung begibt.
Eine eher freiwillige Bindung könnte durch eine regressive Preisgestaltung erreicht werden. Mit steigender Inanspruchnahme sinkt der Preis der Leistung automatisch. Hierzu
müsste der Kunde nur genau identifizierbar sein, damit man ihm seine vorigen Transaktionen anrechnen kann.
Ein weiteres preispolitisches Instrument ist die Preisdifferenzierung, nach der die Preise
für unterschiedliche Kundengruppen angepasst werden. Mögliche Gruppen wären hierbei
Kinder, Jugendliche, Studenten, Erwachsene, Rentner, Behinderte, Beamte usw. Für
einen Webdienst wie Jinengo stellt die Überprüfung dieser Angabe auf den ersten Blick
ein Problem dar, wenn jedoch noch alle Tarife gewinnbringend laufen, so könnte ein
Missbrauch in diese Richtung sogar erwünscht sein, wenn hierdurch Kunden gebunden
werden. Die Bindung entsteht durch den Preisvorteil für den Kunden.
Prinzipiell gibt es noch eine Vielzahl weiterer Preismodelle, die hier jedoch außer Acht
gelassen werden sollen. Wichtiger ist hingegen die Erkenntnis, dass derjenige Anbieter
mit dem niedrigsten Preis i.d.R. bei qualitativ gleichwertiger Leistung die beste Kunden-
379
bindung erzielt. Der Preis ist dabei stets eine relative Größe und im Bezug zu den Konkurrenten zu sehen. Ein Anbieter hat keine Chance über unterschiedlichste Preismodelle
Kunden zu binden wenn es einen weiteren Anbieter gibt der gleichwertige Leistungen
kostenlos anbietet.
Produktpolitische Instrumente
Als wichtigster Parameter der Produktpolitik zur Kundenbindung kann die Leistungsqualität gesehen werden. Dabei handelt es sich tatsächlich jedoch nicht um ein Instrument der Kundenbindung sondern betrifft die Hauptgeschäftsprozesse. Wie bereits weiter oben erwähnt bestimmt sich die Qualität der Leistung aus den Potenzialfaktoren,
den Fremdfaktoren sowie vom eigentlichen Erstellungsprozess. Über Qualitätsstandards
und Leistungsgarantien kann dem Nachfrager jedoch signalisiert werden, dass er eine
Qualität, welche er beim Ersterwerb erhalten hat, auch bei Folgetransaktionen erwarten
kann. Dies könnte ihn binden. Fraglich könnte sein, wie Nutzer des Dienstes Jinengo
die immaterielle Leistung beurteilen und welche Bedeutung sie der Qualität in diesem
Zusammenhang beipflichten. Dass die Information, welche sie als Endergebnis erhalten,
korrekt ist, muss als Basisfaktor betrachtet werden, d.h. diese Art von Qualität setzen
sie als selbstverständlich voraus.
Ein weiteres Instrument stellen Value-Added-Services (VAS) bzw. Zusatzleistungen dar.
Es sind all jene Leistungen, die nicht Kernleistungen darstellen und theoretisch einzeln betrachtet kaum bis gar nicht vermarktungsfähig wären. Kernleistung von Jinengo
ist aus Kundensicht die Routenplanung unter Nachhaltigkeitsgesichtspunkten. Die Zusatzleistungen seien bestenfalls mit der Kernleistung schematisch verwandt, sodass ein
Leistungsbündel entsteht. Eine mögliche Auswahl an Zusatzleistungen ist in Tabelle
B.13 dargestellt, die jedoch keineswegs erschöpfend ist. Durch ebendiese Zusatzleistungen kann die Kundenzufriedenheit gesteigert und die Bindung gefestigt werden.
VAS1
VAS2
VAS3
VAS4
Zusatzinformationen über Zielort (Geschäfte, Parkmöglichkeiten, Wetter. . . )
Umfassender Hilfedienst
Durchstöbern von Bewertungen
Mein Reiseprofil“
”
Tabelle B.13.: Value Added Services (Quelle: Eigene Darstellung)
Ein besonderer Zusatzservice sei an dieser Stelle kurz beschrieben. Gerade im Bereich
der Webanwendungen hat sich das spielerische Prinzip des Punkte bzw. Trophäen sam”
meln“ als wirksam herausgestellt. Im Kern zielt dieses Anreizsystem auf den Urtrieb des
Menschen des Jagens und Sammelns“ ab. Für eingespartes CO2 könnten im Falle von
”
Jinengo Punkte vergeben werden, die der User sammelt. Vorteilhaft ist es wenn sodann
User untereinander ihre Punkte einsehen können oder Ranglisten existieren.
380
Kommunikationspolitische Instrumente
Bei diesen Instrumenten steht das Ziel im Fokus einen dauerhaften Dialog zwischen Anbieter und Nachfrager aufzubauen. Klassischerweise werden aber auch jene Instrumente
hier mit hinzugezählt die eher monologisch ablaufen.
Als erstes Kommunikationsinstrument zur Kundenbindung sei die Kundenzeitschrift
bzw. der Kundennewsletter. Von ihrer physischen Art her sind diese Medien zwar sehr
unterschiedlich, jedoch seien sie hier präsentationstechnisch als gleichwertig angesehen,
weswegen an dieser Stelle keine Differenzierung zu beiden vorgenommen wird.
Der Kundennewsletter kann in bestimmten Zeitabständen dem Kunden zugesandt werden und erfüllt aus Unternehmenssicht eine Reminder-Funktion. Aus Kundensicht sind
die Inhalte des Newsletters, sofern sie gewisse qualitative Standards erfüllen, nutzenstiftend. Im Falle von Jinengo würde es sich anbieten über thematisch verwandte Aspekte
wie Elektromobilität, Nachhaltigkeit, Umwelt, Verkehr aber auch über den Dienst an
sich zu berichten. Mit Hilfe der richtigen Argumentation und mittels Überzeugungsarbeit
innerhalb der Berichte könnte auch die Nachfrage nach Nachhaltigen Transportmöglichkeiten erhöht werden.
Mit Hilfe des Internets besteht weiterhin die Möglichkeit eine interaktive Kommunikationsplattform einzurichten in der echte Dialoge ablaufen können. Über ein Forum
könnten sämtliche Themen abgehandelt werden die den Service Jinengo, dessen Funktionen aber auch verwandte Themen anführen. Durch den Community-Effekt würde eine zusätzliche Kundenbindung geschaffen werden. Doch während Foren und Chats eher
typische Web 1.0 Anwendungen darstellen sollten auch potenziale der Web 2.0 Anwendungen ausgeschöpft werden. Ein Blog bzw. Microblog kann beispielsweise helfen, den
Service zu personalisieren, indem Nachrichten und Ereignisse aus subjektiver Sicht einer Person geschrieben werden und auch Emotionen einfließen können. Interessant sind
auch die Möglichkeiten die mit dem Einbinden der Social-Plattform Facebook entstehen. Ein Jinengo-Nutzer könnte beispielsweise nach einer abgeschlossenen Reise, welche
er mit Jinengo geplant hat, seine Bewertung der Reise als Statusupdate auf Facebook
veröffentlichen. Damit würde der Nutzer in seinem Freundeskreis signalisieren, dass er
sich nachhaltig fortbewegt und gleichzeitig die Bekanntheit des Dienstes Jinengo steigern.
Die Kundenbindung würde in diesem Fall über die Zufriedenheit des Nutzers gestärkt
werden, da der Nutzer solche Funktionen als Begeisterungsfaktoren auffassen könnte.
Ebenfalls genannt sei das proaktive Vorgehen, bei dem Briefe, Emails oder SMS dem
Nutzer ohne sein Zutun übersandt werden. Diese Sendungen können als Reminder fungieren und den Nutzer zur erneuten Nutzung veranlassen. Andererseits kann auf diesem
Wege sehr schnell eine Verärgerung des Kunden erreicht werden.
Das Beschwerdemanagement nimmt einen wichtigen Stellenwert ein. Sofern man unzufriedenen Kunden nicht die Möglichkeit der Beschwerde einräumt oder diese nicht
381
Abbildung B.14.: Cover eines Newsletters (Quelle: Eigene Darstellung)
Abbildung B.15.: Facebook Status (Quelle: Eigene Darstellung)
382
ernst nimmt, besteht die Gefahr, dass einzelne verärgerte Kunden durch Kommunikation mit weiteren Kunden großen Schaden anrichten. Dies kann unter Umständen zu
einer Massenabwanderung der Kunden führen. Wenn hingegen Beschwerden ordentlich
verarbeitet werden und evtl. auch Entschädigungen geleistet werden kann der einst unzufriedene Kunde gänzlich umgestimmt werden und am Ende doch noch zufrieden sein,
da er gesehen hat, dass sein Anliegen ernst genommen wurde. Wichtig für den Dienst
Jinengo ist es deshalb Kanäle für Beschwerden einzurichten. Eine Besonderheit hier ist,
dass nicht nur technische Probleme mit dem Dienst selbst eingereicht werden könnten,
sondern dass Kunden beschwerden über Verkehrsmittelbetreiber einreichen. Hier müsste
man im Vorfeld ein Konzept ausarbeiten, wie diese Beschwerden zu verarbeiten sind.
Distributivpolitische Instrumente
In diese Kategorie fallen Gewinnspiele/Samplings, Distributionswege sowie die generelle
Verfügbarkeit. Bei dem vorliegenden Dienst Jinengo ist der Handlungsspielraum bereits
dadurch eingeschränkt, dass der Dienst bereits überall verfügbar ist. Eine Ubiquität ist
damit gegeben, da mittels Handheld der Service überall und jederzeit erreichbar ist.
Sofern der Service jedoch kostenpflichtig angeboten wird, würde die Möglichkeit bestehen mittels Coupons Frei-Transaktionen zu vergeben. Obwohl Bruhn/Homburg dieses
Vorgehen als Kundenbindungsmaßnahme bezeichnen vertritt der Autor die Auffassung,
dass es sich eher um ein Kundenakquisitionsinstrument handelt.
Kundenbindungsmix für Jinengo
Abbildung B.16 stellt nochmals den gesamten Kundenbindungsmix für Jinengo vor. Dabei sind hauptsächlich die klassischen Kundenbindungsinstrumente aufgeführt. Auf CRM
basierende Methoden sind explizit nicht mit in diesem Mix aufgefasst, weil sie nicht klassisch sind und werden deshalb im nächsten Kapitel gesondert behandelt. Obwohl Laker/Pohl/Dahlhoff gegen eine frühe Einführung von Kundenbindungsinstrumenten sind,
wird für den Dienst Jinengo eine frühe Einführung empfohlen. Denn abgesehen von den
proaktiven Mailings sind die aufgeführten Aktivitäten kundeninduziert, d.h. der Kunde
bekommt den Newsletter erst nachdem er ihn abboniert hat und er kommt erst mit dem
Beschwerdemanagement in Berührung, nachdem er es kontaktiert hat usw.
Nutzung eines CRMs zur Kundenbindung
Dieser Abschnitt soll nun konkrete Kundenbindungschancen eines CRMs für Jinengo
aufzeigen. Der Ansatz, den Kunden ins Zentrum aller Aktivitäten zu legen ist auch für
Jinengo ein gangbarer Weg. Die Dienstleistung Jinengo impliziert ein gewisses Maß an
383
Abbildung B.16.: Kundenbindungsmix klassischer Bindungsinstrumente (Quelle: Eigene
Darstellung)
Ich-Beteiligung womit Wissen über den Kunden einen besonderen Stellenwert einnimmt.
Dieses Kundenwissen sollte im CRM hinterlegt werden.
Zwei Ansätze werden dabei verfolgt. Zum einen dienen diese Daten dem Kunden eine optimale Leistung anzubieten. Kundeninformationen werden dabei explizit durch den Kunden selbst übermittelt, wenn dieser beispielsweise die Präferenz Segway-Fahren“ angibt.
”
Daneben können implizit Kundeninformationen abgeleitet werden. So ist es denkbar,
dass aus dem bisherigen Nutzungsverhalten wie beispielsweise gewählte Transportmittel
und Strecken gewisse Schlüsse gezogen werden. Oder es werden Cluster von Kundengruppen gebildet die ebenfalls neue Erkenntnisse über Kunden und deren Wünsche enthüllen.
Genau hier können CRM-Tools einen Beitrag leisten, indem sie Analysetools anbieten.
Der Kunde profitiert sodann von Angeboten die seinen Bedürfnissen entsprechen. Mit
steigender Zufriedenheit reduziert sich sodann seine Wechselbereitschaft. Diese Art der
Personalisierung betrifft jedoch nicht nur die Kernleistung. Es ist auch denkbar den
Leistungserstellungsprozess an den Kunden anzupassen, indem Optionen ausgeblendet
werden, die niemals gewählt werden. Zuletzt können auch die Ansprachen, wie Newsletter oder Directmailings an Kunden oder Kundengruppen angepasst werden, womit dem
Kunden nur diejenigen Informationen präsentiert werden die ihn weitestgehend interessieren und betreffen.
Der zweite Ansatz betrifft das Geschäftsmodell von Jinengo. Sofern man sich dazu entscheidet Kundendaten zu vermarkten könnte es für Jinengo von Interesse sein besonders
384
wertvolle Kundendaten zu sammeln bzw. zu generieren. Dazu wird an dieser Stelle angenommen, dass ein Kundenprofil umso wertvoller ist je vollständiger und umfassender
es ist. So ist das Kundenprofil eines Intensivnutzers mit detaillierten Präferenzen als
besonders wertvoll zu erachten. Lange Transaktionshistorien entstehen somit, wenn der
Dienst Jinengo über längeren Zeitraum kontinuierlich genutzt wird. Hier setzt genau das
Konzept der Kundenbindung an. Starke Kundenbindung führt demnach im Allgemeinen zu wertvolleren Kundenprofilen. Differenzen ergeben sich jedoch dadurch, dass der
Dienst auf unterschiedliche Art und Weise genutzt wird. Sofern dieses Geschäftsmodell
tatsächlich auserwählt wird kommt der Kundenbindung eine besondere Bedeutung zu.
Teil III – Fazit und Ausblick
Diese Arbeit hat gezeigt, dass es für die Dienstleistung Jinengo tatsächlich, wenn auch
eingeschränkte Instrumente zur Kundenbindung gibt. Eine Schwierigkeit besteht darin,
dass es sich, wie bei vielen klassischen Webdiensten auch, aller Wahrscheinlichkeit nach
um ein kostenloses Angebot handeln wird. Demnach kommen vertragliche Bindungen sowie Preis-/Tarifmodelle nicht in betracht. In den Fokus muss also die freiwillige Bindung
rücken, welche über Kundenzufriedenheit erreicht werden kann. Wichtigster Stellparameter ist hier die Leistungsqualität, die als notwendige Bedingung zur Kundenbindung
betrachtet werden kann. Hinreichend sind dann die, eher begleitenden, klassischen Instrumente. Ihr Einfluss ist jedoch ungleich geringer.
Die Dienstleistung Jinengo ist prototypisch und ein erster Versuch Menschen dazu zu
bewegen nachhaltigere Transportmittel zu verwenden. Das Oberziel, nämlich CO2 einzusparen, kann jedoch nur in dem Maße erreicht werden wie auch entsprechende Transportmittel zur Verfügung stehen. Ohne CO2-freundliche Transportmittel kann selbst der
Dienst Jinengo keinen Beitrag zur CO2-Reduktion liefern.
CRM stand in der Vergangenheit häufig für den Ansatz möglichst viele Produkte beim
Kunden abzusetzen. Bezogen auf Mobilität stellt man hingegen fest, dass der kleinste
CO2-Ausstoß durch die Vermeidung von Mobilität erreicht wird. Hier befindet sich der
Dienst Jinengo in einer Zwickmühle. Rät der Dienst zum Nicht-Mobil-Sein, so entzieht
er sich selbst seine Kundengrundlage. Es werden jedoch noch etliche Jahre vergehen bis
das vorherrschende Mobilitäts-Paradigma (Menschen müssen immer mobiler werden)
überholt wird. Das derzeitige Paradigma geht Hand in Hand mit dem Wachstumsparadigma des Kapitalismus. Es ist nicht auszuschließen, dass es in Zukunft Gegenbewegungen geben wird die eine so genannte Entschleunigung anstreben. Bis dahin hat der
Dienst Jinengo allemal seine Berechtigung.
385
Grundlagen der Erstellung von
Geschäftsmodellen und Ansatzpunkte für die
Übertragung des Geschäftsmodells
Mobilfunk-Serviceprovider auf einen
Mobilitätsservice
Alain Marcel Nguefack Temgoua
[email protected]
Zusammenfassung Hier wird die Zusammenfassung der Seminarausarbeitung mit einer Länge von ca. 150 Wörtern eingetragen.
Schlüsselwörter Schlüsselwort 01, Schlüsselwort 02, Schlüsselwort 03,
Schlüsselwort 04, Schlüsselwort 05
Einleitung
Seit geraumer Zeit ist ein grundlegender, informationstechnologieinduzierter Wandel in
Wirtschaft und Gesellschaft zu beobachten. Dieser Wandel wird durch die Veränderung
bestehender Strukturen in Telekommunikation, der Computer-, der Unterhaltungs- und
der Medienindustrie bewirkt [92]. Diese fortschreitende technologische Entwicklung, insbesondere der Internettechnologie, ermöglicht neue Strukturen in Wirtschaft und Gesellschaft. Die Folge sind neue, netzwerkartige Formen der Zusammenarbeit zwischen
Unternehmen, ihren Kunden und Lieferanten. Die vorliegende Arbeit beschäftigt sich mit
Geschäftsmodellen im Ansatzpunkt für die übertragung des Geschäftsmodells MobilfunkServiceprovider auf einen Mobilitätsservice.
Das Ziel dieser Arbeit ist die Entwicklung eines formalen Beschreibungsmodells für Gesellschaftsmodelle Mobilfunk-Serviceprovider auf einen Mobilitätsservice. Die Analyseeinheit ist dabei nicht das einzelne Unternehmen, sondern das einem Geschäftsmodell
zugrunde liegende Geschäftsnetzwerk. Dementsprechend findet eine Konzentration auf
unternehmensexterne Aspekte statt. Das Modell soll zur allgemeinen Beschreibung von
Geschäftsmodelle sowohl Handys als auch Verkehrsmittel dienen, eine Konzentration auf
einzelne Typen wie die Bahn oder das Flugzeug wird nicht vorgenommen.
Im Rahmen dieser Hausarbeit wird zunächst das verwendete Modellverständnis expliziert und anschliessend der Begriff des Geschäftsmodells definiert. Ebenso werden die
allgemein mit der Konstruktion von Geschäftsmodellen verfolgten Ziele und die Vorgehensweise zur Gestaltung eines Geschäftsmodells untersucht. Daran anschließend werden
die für die Beschreibung wesentlichen Merkmale Mobilitätsservice der Geschäftsmodelle
386
und formale Anforderungen an ein Beschreibungsmodell dargestellt. Eine Zusammenfassung schließt die Arbeit.
Begriff des Geschäftsmodells
Modellbegriff
Für die Beantwortung der Frage, was ein Geschäftsmodell ist oder sein sollte, ist zunächst
eine Analyse des zugrunde liegenden Modellbegriffs notwendig. Der Begriffs Modell lässt
sich zurückverfolgen auf das griechische Wort med/mod (erwägen, an etwas denken,
für etwas sorgen) und das lateinische Modus( Maß, Form, Vorschrift) [93]. In seiner einfachsten Form wird ein Modell als vereinfachte Abbildung realer oder gedachter Systeme
verstanden [94].
Abbildung B.17.: Modelle als Hilfsmittel im Theoriebildungs-und Theorieverfeinerungsprozess [94]
In diesem so genannten Abbildung B.17 Modellverständnis bestehen Modelle aus einem
zu modellierenden Objektsystem, dem Modellsystem und der Modellabbildungsfunktion.
Wesentliche Forderungen an Modelle beinhalten die Struktur- und Verhaltentreue, die
jeweils dann gegeben sind, wenn die Modellabbildungsfunktion homomorph bezüglich
der Struktur bzw. des Verhaltens ist.
Die oft geübte Kritik am abbildungsorientierten Modellbegriff bezieht sich insbesondere auf die Rolle des Modellierers. Der Modellierer nimmt im abbildungsorientierten
Modellbegriff eine passiv rezeptive Position ein, sodass der Modellierungsprozess subjektunabhängig durchgeführt werden könnte. Demgegenüber sieht der konstruktivistisch
orientierte Modellbegriff Modelle als Konstruktion eines Modellierers an. Zudem sind
387
Modelle ihren Originalen nicht per se eindeutig zugeordnet. Sie erfüllen ihre Ersetzungsfunktion für bestimmte Subjekte zu einem bestimmten Zweck. Nach Steinmüller bestehen Modellsysteme daher aus vier Elementen, dem modellerzeugenden oder benutzenden Subjekt, dem für ihn abbildende Modellobjekt, dem repräsentierten Original sowie
den möglicherweise beeinflussten Adressaten [95]. Für die Beurteilung von Modellen ist
nicht die Abbildung der Realität entscheidend, vielmehr wird die Zweckorientierung herangezogen. Die Qualität eines Modells sinkt demnach mit der Differenz zwischen den
Anforderungen des Modelladressaten und der Eignung des Modells zur Problemlösung.
Nach Ulrich lassen sich Modelle nach ihrem Verwendungszweck einteilen in Beschreibungs, Erklärungs-, Entscheidungs-, und Gestaltungsmodelle. Das Ziel von Beschreibungsmodellen besteht darin, interessierende Tatbestände und Geschehnisse der Wirklichkeit
mithilfe einer Reihe allgemeiner Grundbegriffe zu beschreiben. Erklärungsmodelle versuchen, die interessierende Wirklichkeit kausal analytisch zu erklären. Durch Umformung
der mithilfe der Erklärungsmodelle gewonnenen Erkenntnisse können Entscheidungsmodelle entstehen, die sich für ein zielgerichtetes menschliches Handeln zur änderung der
Wirklichkeit einsetzen lassen [96].
Ausgehend von der Frage, ob die Erfassung der komplexen betriebswirtschaftlichen
Wirklichkeit über Erklärungsmodelle notwendig oder überhaupt möglich ist, entwickelt
er die Kategorie der Gestaltungsmodelle. Diese dienen weniger zur Erklärung der gegenwärtigen Wirklichkeit als vielmehr zur Eröffnung von Vorstellungen über mögliche
künftige Wirklichkeiten und Handlungsmaximen für deren Realisierung [96].
Die Auswirkungen dieser Überlegungen auf die Betrachtung von Geschäftsmodellen lassen sich für diese arbeit wie folgt zusammenfassen:
Es existiert keine subjektneutrale Abbildungsvorschrift, vielmehr müssen Geschäftsmodelle
konstruiert werden. Es ist also eine Eigenleistung des Modellierers erforderlich.
Unterschiedliche Modellierer können zu unterschiedlichen Modellen desselben zugrunde liegende Objekts gelangen.
Geschäftsmodelle können nicht subjekt- und zweckunabhängig werden. Eine Beurteilung lässt sich nur unter Berücksichtigung der Modelladressaten und des Modellierungszweckes vornehmen.
Definition des Begriffs Geschäftsmodell
Im Schrifttum wird der Begriff des Geschäftsmodells sehr uneinheitlich verwendet. Eine
übergreifend anerkannte Definition existiert noch nicht. Aus dem vielfachen Gebrauch
des Terminus Geschäftsmodell kann jedoch geschlossen werden, dass der Begriff zumeist auf die Fragen nach dem Schwerpunkt der unternehmerischen Aktivitäten und der
Erlöserzielung beschränkt wird [92]. Eine der am häufigsten zitierten Definition stammt
388
von Timmers: A business model is defined as the organization (or architectur) of product, service and information flows, and the source of revenues and benefits for suppliers
and customers. [97] Ein Geschäftsmodell besteht demnach aus:
einer Architektur für die Produkt-, Dienstleistungs-, und Informationsflüsse, zusammen mit einer Beschreibung der verschiedenen Akteure und ihre Rollen,
einer Beschreibung der Nutzungspotenziale für die einzelnen Akteure sowie
einer Beschreibung der Erlösquellen [97].
Aufbauend auf Timmers definiert versteht Wirtz unter dem Begriff des Geschäftsmodells
eine Abbildung des betrieblichen Produktions- und Leistungssystems einer Unternehmung bezeichnet. Durch ein Geschäftsmodell wird in stark vereinfachter und aggregierter Form abgebildet, welche Ressourcen in die Unternehmung fließen und wie dies durch
den innerbetrieblichen Leistungserstellungsprozess in vermarktungsfähige Informationen, Produkte und/ oder Dienstleistungen transformiert werden. Ein Geschäftsmodell
enthält damit Aussagen darüber, durch welche Kombination von Produktionsfaktoren
die Geschäftsstrategie eines Unternehmens umgesetzt werden soll und welche Funktionen den involvierten Akteuren dabei zukommen [92]. Im Gegensatz zu Timmer, der ein
Geschäftsmodell nicht auf einzelnes Unternehmen beschränkt, bezieht sich die Definition
von Wirtz jeweils auf ein einzelnes Unternehmen und dessen direkte Beziehung.
Noch deutlicher in Richtung Vernetzung ist der Ansatz von Tapscott/Ticoll/Lowy ausgerichtet. Die Autoren definieren nicht direkt Geschäftsmodelle, sie benutzen das Konzept
des Business Webs. Business Webs stellen Geschäftsmodelle auf dem Internet dar und
bestehen aus einem klar umrissenen System von Lieferanten, E- Commerce- Dienstleistern, Infrastrukturanbietern und Kunden, die das Internet für den wesentlichen Teil ihrer
Geschäftskommunikation verwenden [98].
Insgesamt lässt sich eine Reihe von Gemeinsamkeiten identifizieren, die in den einzelnen
Definitionen unterschiedlich stark zum Ausdruck kommen.
Es handelt sich um hoch aggregierte Darstellungen.
Die Betrachtung ist auf einen bestimmten Zeitpunkt bezogen
Die Betrachtung erfolgt aus der Perspektive eines fokussierten Akteurs.
Das Netzwerk der wesentlichen Akteure, mit denen der fokussierte Akteur im Austausch steht, wird in Betrachtung einbezogen.
Eine Konzentration auf organisationsendogen beeinflussbare Aspekte erfolgt.
Die Darstellung konzentriert sich auf organisationsexterne Aspekte. Die organisationsinterne Abwicklung bei den einzelnen Akteuren wird vernachlässigt.
389
Daraus abgleitet wird für diese Arbeit folgende Definition zugrunde gelegt:
Unter einem Geschäftsmodell wird ein zeitpunktbezogenes aggregiertes Modell der Akteure eines Geschäftsnetzwerkes, ihrer Rollen und Austauschbeziehungen sowie ihrer
Nutzungspotenziale aus Sicht eines fokussierten Akteurs verstanden.
Der Begriff des Akteurs wurde für die Definition gewählt, um zu verdeutlichen, dass die
einzelnen Teilnehmer in einem Geschäftsnetzwerk unterschiedliche, teilweise gegensätzliche
Interessen haben und aktiv verfolgen.
Ziele der Geschäftsmodellkonstruktion
Traditioneller Untersuchungsgegenstand der strategischen Geschäftseinheiten und das
Unternehmen als übergeordnete Instanz sowie die Branche, in der ein Unternehmen
tätig ist. Diese Analyseeinheiten vermögen jedoch nur einen Teil der geschaffenen Werte
zu erklären. Das Konzept Geschäftsmodell ermöglicht eine Einbeziehung des Netzwerkes,
in dem eine strategische Geschäftseinheit tätigt ist [99].
Geschäftsmodelle beschreiben Analyseeinheiten, mit denen die durch das Zusammenwirken mehrerer Quellen generierte Wertschöpfung erfasst werden kann.
Nach Wirtz besteht die wesentliche Intention, die mit der Geschäftsmodellbildung verfolgt wird, in der Aggregation wesentlicher, relevanter Aspekte aus den betriebswirtschaftlichen Teildisziplinen, um hierdurch zu einem komprimierten überblick der Geschäftsaktivitäten
in Modellform zu gelangen [92]. Weil und Vitale weisen auf die komplexen Probleme bei
der Entwicklung von E- Business- Projekten hin. Manager können Geschäftsmodelle
nutzen, um diese Komplexität und das Risiko von teuren Korrekturmaßnahmen zu verringern. Geschäftsmodelle helfen einerseits dabei, die Essenz von E- Business- Initiativen
zu erkennen und anderseits bei der Identifikation der kritischen Erfolgfaktoren und notwendigen Kernkompetenzen [100].
Zusammengefasst lassen sich als Hauptziele, die mit der Konstruktion von Geschäftsmodellen
verfolgt werden, festhalten:
Die Einbeziehung von Netzwerkaspekten in das strategische Management
Die Komplexitätsreduktion bei der Planung und Bewertung von E- Business Initiativen
Die Unterstützung der Kommunikation von Geschäftsaktivitäten
390
Einordnung in das strategische Management
Das Problem der Entwicklung und Verwirklichung erfolgreicher Unternehmensstrategien
steht heute im Mittelpunkt der Managementliteratur.
Strategisches Management kann nach Ulrich definiert als Prozess, in dessen Mittelpunkt
die Formulierung und Umsetzung von Strategien in Unternehmen steht [96]. Das strategische Management besteht aus den Teilsystemen strategische Planung, strategische Kontrolle, Information, Organisation, Unternehmenskultur und Leistungspotenziale. Aufgabe des strategischen Managements ist die Kontrolle dieser Führungssysteme.
Die Begriffe Strategie und Geschäftsmodell werden häufig gemeinsam gebraucht, teilweise werden sie sogar Synonym. Dennoch bestehen zwischen den durch die beiden Begriffe
repräsentierten Konzepten signifikante Unterschiede.
In einer Analyse von vierzig Definitionen des Strategiebegriffs im deutschsprachigen
und angloamerikanischen Raum identifizieren Welge und Al- Laham die Darstellung
grundsätzlicher, langfristiger Verhaltenweisen und Maßnahmenkombinationen der Unternehmung und relevanter Teilbereiche gegenüber ihrer Umwelt als übergreifendes Merkmal von Strategien [101].
Das erste Abgrenzungskriterium zwischen den Konzepten Strategie und Geschäftsmodell
liegt demnach in ihrer zeitlichen Gültigkeit. Während eine Strategie langfristige Maßnahmenkombination zur Zielerreichung beinhaltet, ist die Beschreibung eines Geschäftsmodells
an einen bestimmten Zeitpunkt gebunden. Die strategischen Maßnahmen können zur
Veränderung von Geschäftsmodellen über die Zeit führen, etwa um einer veränderten
Wahrnehmung der Umwelt Rechnung zu tragen.
Dementsprechend können Geschäftsmodelle als Ausgangs- oder Zielzustände bei der
Abstimmung strategischer Maßnahmen helfen. Die änderungen des Geschäftsmodells
können sowohl durch geplante strategische Maßnahmen als auch durch ursprünglich
nicht intendierte Maßnahmen erfolgen [102].
Das zweite Unterscheidungsmerkmal betrifft die Einbeziehung von Wettbewerbern. Während
die Betrachtung von Konkurrenten als konstituierendes Merkmal von Wettbewerbstrategien angesehen werden kann, betrachten Geschäftsmodelle jeweils nur ein Wertschöpfungsnetzwerk.
Zwar können die teilnehmenden Unternehmen durchaus gleichzeitig auf einigen Gebieten
Partner und auf anderen Wettbewerber sein, ihre Rolle als Wettbewerber wird aber in
Geschäftsmodellen nicht thematisiert.
Neben diesen Unterschieden verbinden Strategien und Geschäftsmodelle eine Reihe von
Gemeinsamkeiten. Beide beziehen sich auf organisationsendogen determinierbare Entscheidungen. Die Entscheidung für eine auszuwählende Strategie oder ein Geschäftsmodell
wird zwar unter anderem durch Umweltaspekte beeinflusst, ist aber letztendlich eine
Aufgabe des strategischen Managements. Ebenso handelt es sich bei beiden um schlecht
strukturierte Entscheidungen, bei denen es eine große Fälle an Entscheidungsmöglichkeiten
gibt und nicht alle notwendigen Informationen zu Beginn des Entscheidungsprozess vorliegen. Eine weitere Gemeinsamkeit von Strategien und Geschäftsmodellen liegt in ihrem
möglichen Gültigkeitsbereich. Beide Konzepte können sowohl für die gesamte Unternehmung als auch nur für einzelne Unternehmensbereiche Geltung besitzen [100].
391
Aufgrund dieser Gemeinsamkeiten und Unterschiede werden beide Konzepte als komplementär betrachtet.
von Geschäftsideen zum Produkt
Ausgangspunkt jedes Leistungserstellungsprozesses oder jeder Leistungserbringung ist
eine Produkt- oder Geschäftsidee. Dies könnte beispielsweise die idee sein, Kunden die
Teilnahme an oder die Veranstaltung von Auktionen anzubieten -über beliebige Endgeräte hinweg, Orts- und zeitunabhändig [103]. Um ein Geschäftsmodell im Einsatz
umzusetzen, werden drei wichtige Bereiche untersucht.
Produkt- / Markt- Kombination
Produkt wird hier eigentlich zu unterscheiden, welcher Art von Dienst man im Geschäft
auf dem Markt bringen möchte. Sei es eine Dienstleistung dazu gehört zum Beispiel:
Eine ausgeführte Tätigkeit an einem Kunden gelieferte materielle Produkte
Eine ausgeführte Tätigkeit an einem Kunden gelieferte immaterielle Produkte.
Danach welcher Art von Produkt handel es sich, physisches oder nicht physisches Produkt. Oder die Leute beraten.
Unter dem Markt versteht man zuerst an welche Art von Personen das Geschäft eingerichtet wird zum Beispiel private oder Geschäftsleute. Danach wo man sein Produkt
einsetzen möchte und über welchen Vertriebskanal soll es laufen.
Durchführung und Konfiguration der Wertschöpfungsaktivitäten
Innerhalb und im Umfeld des Geschäftsmodell findet eine Vielzahl von Wertschöpfungsaktivitäten
statt. im Abbildung B.18 werden verschiedene Modelle der Wertschöpfungsaktivitäten
im Geschäftsmodell dargestellt.
392
Abbildung B.18.: Durchführung und Konfiguration der Wertschöpfungsaktivitäten [104]
1. Verkauf der Lizenz/des Patents.
Hier wird die Geschäftsidee entwickelt und Lizenz odre Patent dafür verkauft. Vor
-und Nachteile solche Ansatz wäre Zum Beispiel.
Vorteile
Kaum Investitionen
Geringes Risiko
Sofortiger Cash-in
Nachteile
Kleiner Gewinn
Keine Vision für die Zukunft
Kein Kontakt mit dem Markt
2. Kooperation im Vertrieb.
Zusammenarbeit mit der Entwicklung und Produktion, um gemeinsam die jeweils
gestreckten Ziele durchzusetzen.
3. Alleingang.
Hier wird die Geschäftsidee allein entwickelt, produziert und auf dem Markt gebracht.
Vorteile
Hohes Gewinnpotenzial
Unabhängigkeit
Unternehmerischer Freiheitsgrad
Nachteile
Hohe Investitionen erforderlich
Großes Risiko
Markzutritt und Marketingkenntnisse fehlen
Ertragsmechanik
man unterscheidet zwei unterschiedlische Arten von Ertragsmachaniken. Die direkt -und
indirektsertragsmechanik
393
Abbildung B.19.: Ertragsmechanik [104]
1. direkte Ertragsmechanik.
direkte transaktionsabhängige Ertragsmechanik können ereignisabhängige Zahlungen und private/gewerbliche Internetnutzung, Z.B. für den Abruf einer Information
oder Download einer Datei [103].
direkte transaktionsunabhängige Ertragsmechanik entsteht einmalig z.B im Gebühren
der Dekoration, Anschlussgebühren und Lizengebühren. regelmäßigwiederkehrend
im Abonnement und Grundgebühren.
2. indirekte Ertragsmechanik.
indirekte Ertragsmechanik entsteht durch dritte, die sowohl abhängige -und unabhängige Transaktionen ausführen können. Dies kann z.B via Endverbraucher
in prämiensysteme, via Unternehmen in werbung und kommission, via Staat in
Subventionierung.
394
Merkmale von Geschäftsmodellen internetbasierter Mobilfunk
auf einen Mobilitätsservice
Überblick
Die Merkmale von Geschäftsmodellen internetbasierter Mobilfunk auf einen Mobilitätsservice
werden häufig im Zusammenhang mit Schlagworten wie New Economy, Digital Economy,
Electronic Commerce, Electronic Business oder ähnlich diskutiert. Diese Begriffe werden
jedoch, sowohl in der Wissenschaft als auch in der Praxis, sehr unterschiedlich verwendet
und oft nur unzureichend operationalisiert. Teilweise wurde suggeriert, Geschäfte im Internet würden, losgelöst von der übrigen Welt, eigenen Gesetzmäßigkeiten folgen. Viele
dieser Annahmen gelten inzwischen als überholt [105].
Geschäftsmodelle internetbasierter Mobilfunk auf einen Mobilitätsservice zeichnen sich
durch eine Reihe von Merkmale aus. Diese Merkmale treffen einzeln auch Geschäftsmodelle
anderer Unternehmen zu, sind aber in ihrer Kombination typisch für inernetbasierte Unternehmen und werden im Folgenden beschrieben.
Open-Source-Kommunikationsplattform
Das Internet bietet wie kein anderes kommunikationsmittel die Möglichkeit zu einem
schnellen und globalen Informationsaustausch und stellt damit für Open Source Projekte nicht nur die dringend benötigte Entwicklungs- und Kommunikationsumgebung,
sondern auch die Quelle neuer Ideen und neuer Mitglieder dar [106].
Die verschiedenen Wege der Kommunikation und Präsentation im Bereich der Open
Source Softwareentwicklung, die die Internetinfrastruktur bietet, sind Web-seiten, MailingListen, Newsgroups, Entwicklerwerkzeuge.
Eine der neuen entwickelten Open-Source-Kommunikation wäre zum Beispiel die von
Asterisk SCF.
Asterisk SCF ist ein Framework, das Entwicklern die Kommunikation in Echtzeit-Anwendungen,
Voice, Video und Text gehören zu schaffen und die den Anforderungen einer vollständigen
Palette von Einsatzmöglichkeiten, von Embedded-Anwendungen auf Enterprise-und CarrierLösungen ermöglicht. Asterisk SCF ist konzipiert, dass es höchste Verfügbarkeit, Skalierbarkeit, Erweiterbarkeit, Fehlertoleranz und Leistung bieten.
Asterisk SCF wird als ein System von verteilten Komponenten, die in Clustern auf einem
einzigen System oder auf vielen Systemen eingesetzt werden können, transparent geliefert werden. Der Asterisk SCF-Plattform zu unterstützen, als Teil ihrer grundlegenden
Architektur, die gesamte Palette von Echtzeit-IP-Kommunikation, einschließlich Videound Multi-Channel Breitband und Ultra-Wideband-Audio, Chat, Desktop Sharing und
andere Medien-Typen, die entstehen können die Zukunft.
395
Technologie von Asterisk
Asterisk verbindet sich mit der welt des VoIP mit einer Unterstützung einer Reihe von
Protokollen wie SIP, IAX, H.323 und ist auch in der Lage eine Verbindung mit der traditionellen telefonie-Schnittstellen wie Analoge Leitungen und Telefone, ISDN-Leitungen
und T1/E1-Leitungen zu unterstützen.
wenn eine Telefongespräch über ein digitales Netzwerk platziert wird, ist die menschliche
Stimme von der analogen Form in eine digitale Form umgewandelt. Dieser Rendering der
Rede Sound in digitaler Form verwendet einen Computer-Algorithmus, um das Signal
verschlüsseln - Kompression. Die Entschüsselung des digitalen Signals ist Dekompression.
Eine Vor -und Nachteile von Asterisk wäre Beispielsweise einen teueren Bandbreite,
billiger MIPS-Prozessor, günstiger Nähe zu erfinden Alorithmen in der lage hohe komprimierung von Audio. Eine Interne-Verbindung ist notwendig.
Geschäftsmodell internetbasierte informationelle Portal
Service werden in der Form einer Webseite an den Kunden bereitgestellt. Dies wird von
Kunde unter bestimmte Bedindungen verwendet. Ein Beispiel wäre in diesem Fall
Ein Service, der Fahrer und Mitfahrer schnell und einfach zusammen bringt und vermittelt so Fahrten und Mitfahrten.
Die Nutzung solche Portal könnte kostenlose für alle Nutzer sein aber zum Ausgleich
müssen sich alle Portalnutzer registriert sein und dies kann durch einen Computer oder
Mobiltelefon gemacht werden.
Dadurch tragen wir zum schütz der Umwelt, in dem jede Vermittelte Fahrt dabei hilft, die
vorhandenen Ressourcen effizienter einzusetzen und Emissionen entsprechend zu reduzieren. Bei privaten Nutzern werden für die Vermittlung von Transportmöglichkeiten keine
Gebühren erhoben. Dementsprechend müssen der Fahrer der Benzinpreis gleichmäßig
den Kilometerstrecke aufgeteilt. Der Interessent ist verpflichtet, seine persönlichen Passwörter
und Login-Kennungen vor dem Zugriff Dritter zu schützen. Bei unberechtigter Nutzung
durch dritte Personen haftet der Interessent für einen eventuellen Missbrauch bis zu dem
Zeitpunkt zur Sperrung aufgefordert wird.
Man kann durch den Verkauf durch Daten und Werbung erwirtschaften, in dem man
das Portal attraktiv erstellt. Je mehr Besucher auf das Portal desto kann der Portal wie
ein Fernsehen aussehen.
396
Geschäftsmodell einer Mobilitätsservice als Autoleasing
Das Autoleasing wird wie folgt definiert: Überlassung und Nutzung des Autos für eine
vereinbarte Zeit gegen eine monatliche Leasingrate. Die Kosten für Reparaturen und
Instandhaltung gehen zu Lasten des Leasingnehmers. Deshalb ist der Abschluss einer
Vollkaskoversicherung vorgeschrieben. Eigentümerin des Autos bleibt die Leasinggesellschaft. Die Leasingrate umfasst folgende Komponenten [107]:
Leasinggebühr
Abschreibung des Autos
Vertragserstellungskosten
Verbuchung und Inkasso während der Leasingdauer
Provision für den Verkäufer (zum Beispiel Garage)
Gewinn der Finanzierungsgesellschaft
Privatleasing
Der private Kunde, der ein Fahrzeug haben will, kann selbst für Sie die optimale Laufzeit von 24 bis zu 72 Monaten auswählen. Die Leasingrate werden Sie selbst auf der
Grundlage eines individuellen Restwertes des Fahrzeugs bestimmen.
Grundlage der Mietberechnung sind die tatsächlichen Gesamtkosten zuzüglich eventueller Investitionssteuer [107].
Man kann auch den Kund eine Restschuldgarantie anbieten. Falls der Mieter auf folgende
Grunde nicht mehr bezahlen kann. Zum Beispiel längere Arbeitsunfähigkeit, Invalidität
oder Tod. Falls eine des genannten Grunds Sie zutrifft, übernimmt ihre Restschuldgarantie der weiteren monatlichen Rate bis Sie einen neuen Job finden.
Eine Zusammenarbeit mit einem Versicherungspartner wäre auch sinnvoll, die alle schade das Fahrzeug übernimmt. Insofern dass der Mieter nicht mehr Gedanke macht eine
Versicherung zu suchen. Dadurch erweitert man seine Erwirtschafte mit neuen Kunden
an die Versicherung und man kann die Versicherungspartner eine Provision anfordern.
Geschäftleasing
Geschäftsleute, die das Fahrzeug nur für kurze Zeit mieten möchten, werden an Kilometervertrag berechnen. Beim Kilometervertrag werden die Leasingkosten auf die Kilometerleistung des Fahrzeugs verteilt. Basis des Vertrags ist die voraussichtliche Fahrleistung
397
während der Vertragsdauer und die nicht genutzten Kilometer werden ihnen erstattet.
Mehr Kilometer werden nach vorher vereinbarten Kilometer-Sätzen in Rechnung gestellt.
Beim Restwertvertrag wird die Leasingrate auf der Grundlage eines individuellen Restwertes des Fahrzeugs berechnet. Beim Verkauf des Fahrzeuges wird ein Mehrerlös erzielt.
Sie erhalten gemäß dem Teilamortisationserlass 75% dieses Betrages und die verbleibenden 25% können als Mehrerlösbeteiligung in einen Vertrag eingebracht werden [107].
Geschäftsmodell als Verkehrsmittel übergreifen
Wir bringen nicht nur neue Kunden zum Beispiel an der deutschen Bahn sondern auch
wir machen ihre Werbung und Marketing, dadurch können wir an die deutsche Bahn
eine Provision verlangen.
Man kann auch eine Mengen von Aktionspreis Ticket ( Z.B: Ab 29,- Euro ganze Deutschland kaufen und an unseren Kunden anbieten).
Technologieorientierung
Ein wesentliches Merkmal von Geschäftsmodellen internetbasierter Unternehmen ist ihre
Technologieorientierung. Sie ergibt sich bereits aus der Eingrenzung auf Unternehmen,
die wesentliche Teile ihrer Austauschbeziehungen über das Internet abwickeln. Dementsprechend sind diese Geschäftsmodelle nicht nur auf eine funktionierende Übertragungstechnologie
angewiesen. Vielmehr schafft de fortschreitende technologische Entwicklung ständig neue
Möglichkeiten, auf welche das Unternehmen zu regieren hat. Eine Richtung dieser Entwicklungen betrifft die Art der Internetzugänge, sowohl des fokussierten Akteurs selbst
als auch der anderen Akteure. Hier können in Abhängigkeit der Bandbreite Schmalund Breitbandverbindungen unterscheiden werden. Diese Zugänge determinieren die
möglichen Angebote, Distributionsformen und letztlich die ansprechbaren Kundensegmente für digitale Güter. Während für multimediale Angebote, insbesondere hochauflösende
Videoübertragung, ein breitbandiger Zugang erforderlich ist, reichen für kurze Textinformationen auch kostengünstige Schmalbandzugünge. Ebenso lässt sich zwischen stationären und mobilen Zugüngen unterscheiden. Zugangspunkte, von denen aus die Verbindung zum Internet aufgebaut werden kann, sind in zunehmenden Maß nicht mehr
nur herkömmliche Personalcomputer, sondern auch Geräte wie Fernseher mit Set- TopBoxen, Mobiltelefone, PDAs(Personal Digital Assistant) und öffentliche Terminals.
Wesentlich für das Funktionieren der unterschiedlichen Technologien und der darauf
aufbauenden Geschäftsmodelle ist die Orientierung an Standards [108]. Dazu zählen unter anderem Übertragungsprotokolle wie TCP/IP(Transfer Control Potocol/ Internet
Protocol), Sprachen zur Seitenbeschreibung wie HTML( Hypertext Markup Langauge)
oder zur Strukturierung von Informationen wie XML (Extensible Markup Language).
Erst die Nutzung dieses Standards ermöglicht eine Kommunikation zwischen den am
Geschäftsnetzwerk beteiligten Akteuren und eine Kompatibilität der Produkte, auch
398
wenn der betreffende Standard aus Sicht einzelner Akteure suboptimal ist. Eine weitere
Konsequenz der Orientierung an der Entwicklung der Internettechnologie und der damit verbundenen Redundanten Übertragungswege ist die räumlich und zeitlich nahezu
uneingeschränkte Verfügbarkeit der durch internetbasierte Geschäftsmodelle offerierten
Angebote, selbst bei Ausfall einiger Knote [109]. Infolge der Nutzbarkeit rund um die Uhr
und mobiler bwz. öffentlicher Zugünge kann der Kunde beispielsweise E- Mail- Dienstleistungen ortsflexibel nutzen, er ist nicht wie beim traditionellen Postversand an eine
bestimmte Adresse gebunden. Diese Ubiquität bringt neben einer Reihe von Vorteilen
auch Nachteilen mit sich. So ist die Nutzung bestimmter Angebote teilweise nationalen
Gesetzen unterworfen, die sich grenzüberschreitend nur schwer durchsetzen lassen. Beispiele dafür sind die Steuererhebung für Internetdienstleistungen oder die Versuche der
Landesregierung Nordrhein- Westfalen zur Sperrung von Webseiten mit rechtsradikaler
Propaganda [110].
Zusammenfassung
Für den Begriff Geschäftsmodell existiert bisher keine übergreifende anerkannte Definition. Im Rahmen dieser Arbeit soll darunter ein zeitpunktbezogenes aggregiertes Modelle der Akteure, Rollen und Austauschbeziehungen eines Geschäftsnetzwerkes sowie
ihrer Nutzungspotenziale aus Sicht eines fokussierten Akteurs verstanden werden. Dieser Definition liegt ein konstruktivistisches Modellverständnis zugrunde. Die Ziele der
Geschäftsmodellkonstruktion liegen neben der Einbeziehung von Netzwerkaspekten in
das strategische Management vor allem in der Komplexitätsreduktion und Kommunikation von Geschäftsaktivitäten.
Die Entscheidung über zu realisierende Geschäftsmodelle ist Aufgabe des strategischen
Managements. Das Konzept Geschäftsmodell ergänzt dabei das der Strategie, bei haben sowohl Gemeinsamkeiten als auch Unterschiede. Die Merkmale internetbasierter
Geschäftsmodelle ergeben sich vor allem aus der Orientierung an der Vernetzung und der
Entwicklung der zugrunde liegenden Technologie, aber auch aus den Eigenschaften digitaler Güter, den Trends zur Nutzung indirekter Erlösformen und zur Konvergenz sowie
der hohen Dynamik. Voraussetzung für die erfolgreiche Teilnahme an internetbasierten
Geschäftsmodellen ist eine Transformation von traditionellen Unternehmensstrukturen.
Dabei spielen insbesondere die Netzwerkfähigkeit und der Umgang mit Wissen eine Rolle.
Um den Zielen der Geschäftsmodellkonstruktion zu entsprechen und die Qualität der
Modellierung sicherzustellen wird als Framework für die formalen Anforderungen das
Konzept der Grundsätze ordnungsmäßiger Modellierung gewählt.
399
Adaptive Applications Reference Models
Marc Petersen
[email protected]
Zusammenfassung Within these paper the adaptive applications reference model from Ammar Memari is explored. First of all, to understand adaptive hypermedia and reference models in general, the basic
knowledge about the adaptivity of applications and about components
in reference models is reviewed. Thus the adaptation methods and techniques are summarized following by a description of the most known
components, extracted out of existing reference models. Based on that
the focused reference model is declared and mapped to a real world
example, the facebook.com FriendFinder and Ads Engine. Finally the
Jinengo project, which is a system build on top of the reference model,
will be presented under the emphasis of adaptation.
Schlüsselwörter Adaptive Hypermedia, Adaptive Application, Reference Model, Adaptation Techniques, AAARM, facebook, Jinengo
Introduction
An adaptive applications reference model is a model for adaptive hypermedia systems17 .
Nowadays adaptive systems are more and more important, because they can protect
the users from getting lost in hyperspace [112]. These paper has been written as a
research part of a students project group at the C.v.O. university of Oldenbourg. Thus
its main target is to analyze the adaptive application reference model developed by
Ammar Memari and to get the knowledge for developing an adaptive system. As far as
the project group is concerned, the adaptive system is a project called Jinengo.
This paper is structured into five chapters, whereas the first chapter is just these
introduction.
Chapter two starts by defining an adaptive system and provides basic informations about
adaptive hypermedia, at the end the methods and techniques for developing an adaptive
application are pointed out.
Within chapter three the most known adaptation models are explained. Based on that
17
Adaptive application and adaptive hypermedia system are used synonymously [111]
400
knowledge the adaptive application reference model18 will be described.
After the explanation of the reference model chapter four first maps the reference model
to components from facebook.com and then presents the Jinengo project with its ideas
of adaptivity and how the reference model will be implemented.
At the end chapter five comes up with a conclusion.
Adaptive Application
Adaptability versus Adaptivity
By talking about the adaptability of applications or systems it is first needed to know
what exactly is meant by adaptivity and what not. During this seminar paper, especially
in chapter B, a clear distinction between adaptability and adaptivity is essential.
Following the definition from Goy [113] which goes along with De Bra [114] and Brusilovsky [112] and is based on Oppermann [115]:
In adaptable systems the adaptation is decided by the user, who explicitly customizes
the system to receive a personalized service.
In adaptive systems, the adaptation is autonomously performed by the system, without
direct user intervention.
Thus an example for an adaptable system would be a functionality where the user
can specify the preferred display language and based on that the system will change
the display language into the users chosen language. As for example an adaptive system
would change the user’s display language by recognizing the preferred language through
location lookup with the user’s IP address or by reading out the language settings of the
operating system.
To extend the definition towards an adaptive (hypermedia) application - an adaptive
system will most of the times also include an adaptable part, however an adaptable
18
Within these seminar paper the focus is on the adaptive applications reference model from Ammar
Memari, therefore adaptive application reference model and reference model are used as synonymous
for Memari’s reference model.
401
Abbildung B.20.: Adaptive Hypermedia Classification [116]
system is often not adaptive19 . Mapping this fact to the previous example would mean,
that the adaptive system will also have a user option for directly choosing the language
preference which would override the automatically recognized language.
Adaptive Hypermedia
An adaptive application is a kind of subset of Adaptive Hypermedia (AH). Each technique or method for adaptation is connected to a classification. At least each classification
leads into a model and therefore the classification forms the basic structure of a reference
model. Figure B.20 shows the classification of methods and techniques for an AH system
and will be described in these section by following the ideas of [116].
Where: Basically an AH system can be categorized by its application area, which are
educational hypermedia, online information, online help, information retrieval hyperme19
The analysis of real world adaptive systems in chapter B will come up with implementations of
adaptivity and adaptability.
402
dia, institutional hypermedia or personalized views. Detailed information about these
types of systems can be read in [116] and [117]. The intention of where is to identify, in
dependency of the application area, in which context the adaptation will be processed.
Why: Each of the mentioned application areas has its problems which might be solved
through adaptation techniques. Identifying the problems, a specific system has, automatically leads to the answer why to use adaptation and which goals the system could
reach through these.
To what: Now after identifying the issues, the system requires information about its
users. Especially it is needed to know their degree of knowledge about the application
and its content and their target by using the specific application as good as possible.
Therefore adapting to what means representing user features which could be important
as a source for adaptation within an application.
What: Based on the knowledge about the user features the next step is to analyze the
system features and how they can be changed to be adaptive. The question what can
”
be adapted in an AH system“ is quite important for the further analysis of a reference
model and its mapping to real world examples. Because of this reason the following
chapter B will take a closer look at the types of adaptation techniques and through that
showing possible features of such a system.
How : The collected information from previous questions leads now to the whole process
of how to perform the adaptation. These step is divided into two parts, methods and
techniques. Methods are in general possibilities of adaptation and techniques are the
concrete implementation of these methods - detailed explanations also in chapter B.
Adaptation Techniques and Methods
These section sums up what techniques are existing to realize an adaptive application.
Basically the adaptation technologies are divided into two groups, the adaptive presentation and the adaptive navigation support [112] [116]. Both have in common that they
use the user model from a specific user, e.g. current knowledge and goals, to adapt the
page20 to the users needs as good as possible.
20
By talking about a page it is not only meant as a web site, rather as a kind of graphical user interface.
403
Abbildung B.21.: Adaptation technologies
Adaptive Presentation
The main idea behind the adaptive presentation technique is to adapt the content of
the current page, therefore it could also be called content-level adaptation. The primary
application area of this technology are systems which need to serve users with different
types or deepness of knowledge. Actually a page is not only composed out of textual
elements, at least nowadays, there is a lot of multimedia content, and of course both
types of content can be adaptive. Therefore the adaptive presentation techniques are
split into adaptive text presentation and adaptive multimedia presentation techniques.
Unfortunately the adaptive multimedia presentation is not as good researched as the
textual presentation, thus most of the adaptive presentation is about the latter. Figure
B.21 shows a listing of the existing adaptation technologies, which will be considered in
these chapter.
Following the classification of adaptive hypermedia systems from chapter B, the adaptive presentation consists of techniques and methods. As far as content-level adaption
is concerned the methods are additional, prerequisite and comparative explanations as
well as explanation variants and sorting. The package for implementation of these methods are the techniques conditional text, stretchtext, fragment variants, page variants
and frame-based technique.
404
Methods
Additional explanation is a type of adaptation which has hiding of irrelevant information from the user as target. The method is based on the users level of knowledge, which
e.g. could be separated in professional and beginner. By that the page could include, beside the basic content, parts with additional explanations for the beginner and detailed
informations for the professional. The latter information is hided for the beginner and
the former is hided for the professional user.
Prerequisite explanation is based on prerequisite links between concepts. As a precondition of presenting an explanation of a concept, the system adds explanations of all its
prerequisites concepts which might not be known to the user.
Through comparative explanations the similarity links between concepts are used for
adaptation. This means if the current concept has a similar concept which is known to
the user, then the current concept will be explained by pointing out the similarities and
differences between the known concept.
The explanation variants method is a result of the consideration, that a user could
need a completely different explanation than another user. Thus these method stores
two or more variants for some components of a concept and based on the users model
one of the variants is displayed.
The sorting method just evaluates the relevance of an component on a page based on
the user model and sorts them descending by the relevance of components.
Techniques
The conditional text technique divides a page into components, each component is
connected to a condition which influences its visibility. Thus running with the user preferences through the conditions compiles the page, each component where the condition
is true will be included.
Stretchtext is just the term for information parts which can be collapsed or uncollapsed
by clicking on a so called hot word. With the method the relevant information will be
uncollapsed and the irrelevant information collapsed. The advantage is that the content
can additionally be adapted through the user with ease.
405
Fragment variants and page variants are techniques to implement the explanation
variants. By storing different variants of a whole page the page variants technique is
a coarser realization. Instead of whole pages, the fragment variants technique stores
different variants for components of a page.
The use of the mighty frame-based technique is to turn information components into
fluent text through natural language generation techniques [114].
Navigation Support
Navigation support, which is also known as link-level adaptation, groups all techniques
which refer to adapt the links on the current page towards the goals, knowledge and
other properties of the user. Its main target is to prevent the user from getting lost
”
in hyperspace“ and thus its use is spread in information retrieval systems. Relevant
methods of navigation support are global and local guidance, local orientation support
towards goal and towards knowledge as well as global orientation support. Implementation
of these methods could be done through direct guidance, sorting, hiding, annotation
and map adaptation.d in information retrieval systems. Relevant methods of navigation
support are global and local guidance, local orientation support towards goal and towards
knowledge as well as global orientation support. Implementation of these methods could
be done through direct guidance, sorting, hiding, annotation and map adaptation.
Methods
Guidance itself provides adaptation by showing the next relevant links. The difference
between global and local guidance is that the former needs to have a global information goal which should be reached in the shortest way. The latter method undertakes
suggestions for the relevance of links just by information from the user model.
The aim of local orientation support and global orientation support is to provide a
link structure which helps to identify the users current position in the whole context.
This could be done through limiting the number of links or by providing additional
information for each link.
Another method is the management of personalized views which adapts e.g. the visibility of links to documents within a daily working-place and limits the list of links just
to the important ones for the current working goal.
406
Techniques
Most of the navigation support techniques are somehow self explaining and therefore
simply listed below.
Direct guidance
Adaptive sorting of links
Adaptive hiding of links
Adaptive annotation of links (colors as indicators for relevance)
Map adaptation (personalized views)
Reference Models
A reference model is providing a set of models and how they interact with each other.
Therefore this chapter starts with explaining existing types of models, which are summed
up from components of important existing adaptive hypermedia reference models. This
leads to a detailed description of a new adaptive application reference model designed
by Ammar Memari21 .
Adaptation Models
The following collection of models was gathered and merged from the existing reference
models, most of them are summarized in [118].
The domain model is a result from the previous referred classification of what“.
”
Therefore it is a definition of the knowledge for a specific domain and describes the
interrelation between those [114] [117].
The user model represents the knowledge of a concrete user and describes which
information about the user will be continuously monitored [117]. Thinking in an object
oriented world, the domain model would represent a class and the user model is an
instantiation of this class [119] [120] [121] which holds e.g. preferences, knowledge, goals
and navigation history of the user [122].
21
Because Memaris’ paper with the description of the reference model has not been published until
know, it should be said at this point, that the description is mostly based on Memaris’ paper.
407
An adaptation model is a compilation of adaptation rules. These rules define the
adaptation, by combining the domain and user model, and the process of updating the
user model [122], sometimes it is also called teaching model [114] [120].
Basically a user can interact with an application in different situations, e.g. at work
or at home even in the train or while driving. The task of a context model is to reflect
these situations. In [113] the context model is broken down into two types, the physical
context and the social context. The physical context includes information like the user
location, current weather and other measurements. The social context tries to arrange
the user into social groups he or she belongs to and models the relationship to other
people. Often it is also possible to include the users device within the context model.
Also there is no clear definition of a context model and between the separation of user
and context model, it may defer from case to case [123].
The goal model, also known as goal and constraints model, stores the aim of the application from the perspective of e.g. a teacher, as far as a learning environment is concerned.
Also pedagogic information or the business logic of a commercial site could be stored in
the goal model [118].
The process model is the result from the question How to adapt?“ which was explained
”
in chapter B and deepened in B. Thus the adaptation methods are implemented in the
process model.
In the context of a learning environment the narrative model includes rules from
experts which can be used to generate new courses [124].
An activity model represents the activities which can be undertaken, e.g. for an ecommerce site this could be buy, rate and recommend [125].
Adaptive Applications Reference Model
The following adaptive applications reference model is provided by Ammar Memari and
therefore it is abbreviated with AAARM (Ammar’s Adaptive Applications Reference
Model)22 . In the context of reference models this seminar paper puts its main focus on
22
The reference model is a current part of his PhD research and its not named until now. Because of
that, I as an author introduced the abbreviation AAARM (tripple A RM) for simplicity, without
having any claims on that.
408
Abbildung B.22.: Ammar’s Adaptive Application Reference Model (AAARM)
this model. Based on the principles and informations presented so far the model will be
described in this chapter. Later on, in chapter B are analyses performed on transferring
this model to well known existing real world examples.
The reference model in figure B.22 shows the following essential components: User
Model Module, Adaptation Engine with a matchmaker in it, Context Manager, Content
Manager, Neighborhood Manager and the Evolution Chamber.
The central piece of the model is the adaptation engine. It consists of the model
core, the matchmaker, which is splittet into the content-content, user-content and useruser matchmaker. Each of these matchmakers has at least one link to an ontology, the
user-user matchmaker to the user model ontology, the user-content matchmaker to the
domain and user model ontology and the content-content matchmaker connects only to
the domain ontology. The context ontology is also connected, but its accessible through
the whole matchmaker. The adaptation is enabled by the fact that the adaptation rules
are connected with every single matchmaker.
409
In conjunction with the adaptation models presented in chapter B, the adaptation
engine is a bit comparable with the adaptation model, however it is a lot more detailed, because of the matchmaker and its characteristics. Compared with other reference
models, only the adaptation rules would fill the adaptation model.
Having a look at the mentioned ontologies, all of them are populated through a manager. The context manager and the content manager are actually the same as the context
model and the domain model, whereas the neighborhood manager would be a new type
of model. The task of the neighborhood manager is to explore the relationship between
the user and the users around the specific user, the neighbors. Based on the results of
this analysis, the neighborhood manager builds groups of users, so called clusters, which
leads to a reduced granularity.
A completely new component is the evolution chamber, it contains a score calculator,
genetic engine and a hatchery. Its main target is the second-order adaptation, which
means adapting the adaptation and it is based on a score given by the user.
The user has the possibility to give a feedback for an adaptation process or rule, these
feedback will be evaluated by the score calculator. This is an important feature for agent
based systems, e.g. based on the score an agent with a specific task will be replaced by
another agent which provides the same desired results but with a different solution or
algorithm. However it can be used in non-agent based systems, thinking of the example
from the beginning, see chapter B. The adaptive system has performed an automatic
language detection, but if the user is not satisfied with the selected language, than the
user could override these setting from the adaptation by directly setting the language
preferences.
The genetic engine has the mission to evolve the system based on the output from
the score calculator. Starting from the fact that each agent fulfills a concrete task and a
mission consists of several different tasks, thus to fulfill a mission agents with different
tasks are required. However there can be different agents for the same task. In this case
the genetic engines compiles a set of agents to fulfill a concrete mission. These set is
based on the user feedbacks and should be the best solution for solving the mission.
Because the score for an agent could change, the best set of agents could have another
arrangement at another time.
Somehow the agents need to be created somewhere, these happens through agent
assemblers. An agent consists of different behaviors, each behavior is located in the
behavior repository. An agent assembler chooses several behaviors to create an agent,
410
then the hatchery comes up and takes these information, which is called DNA, and builds
a runnable agent out of it.
Mapping the Adaptive Application Reference Model
These chapter will provide ideas and attempts how the previous presented adaptive
application reference model matches to the real world. For this purpose, well known
existing systems are analyzed and tested towards their adaptivity and if these systems
can be mapped to the AAARM.
Intention. The intention of these tests is on one site of course to see if these systems
fit into the model. But first of all the adaptivity of the system needs to be identified and
therefore the adaptive functions are pointed out. Last but not least, in case the model
might not be perfect, it is interesting to check at which points the model might have a
lack.
Procedure. In fact it is most of the times not possible to get a deep look into the
whole architecture of a foreign system. In addition the analysis of a whole system would
be beyond the scope of this paper. However it is possible to have a look at specific
components which are important as far as adaptivity is concerned.
To fulfill the intentions above, the following guideline has been developed:
1. Components (Identification and description of the examined components.)
2. Adaptation (Pointing out the adaptation process.)
3. Mapping (Mapping the example to the reference model.)
4. Conclusion (Conclusion of the mapping.)
There will no description of the general functionality of the examined systems be done,
because of their awareness it would totally be obsolete.
facebook.com
Components. Each social network has obviously somehow the functionality to connect
users with each other. This could be done through direct search by e.g. typing the name
411
Abbildung B.23.: facebook.com - FriendFinder [126]
of the specific user. In this scenario a deeper look at the friendfinder engine of facebook
is undertaken. The reason for this is that a users gets recommendations from the system
which users he or she may know and thus could add as a friend23 .
Further an examination of facebook’s ads engine is undertaken, because it has some
adaptive features which are not implemented in the friendfinder. The ads engine is a
simple sidebar which displays commercial ads as a banner with a short text.
FriendFinder Engine
Adaptation. The intention of the friendfinder engine is that the user adds people to his
or her list of friends. To help the user with this issue the system starts guessing which
people the user might know. Figure B.23 shows a screenshot with a very small extract
of the guessing list and additional search filters24 . The system starts guessing from the
point on when the user is registered. Its guesses are at least based on user preferences
like hometown, current city, high school, university, employer and of course on friends of
the user’s friends. The list of guesses can easily filtered by choosing some filter criteria
through direct user input.
Mapping. Comparing the FriendFinder functionality with the model several components
are matching. Of course an adaptation engine is existing, in this case it contains the adaptation rules and only one matchmaker, the user-user matchmaker. There is also a
neighborhood manager existing, which clusters the users which have the same friends or
similar user preferences, thus there is obviously a user model. However in this case there
is no user analyzer to provide somehow a feedback, therefore the evolution chamber is
also missing. Having a look at the context manager, the FriendFinder seems also to be
23
Of course a lot of other social networks do have somehow the same functionality, but I personally have
chosen facebook because I think it is the most famous one.
24
Due to privacy issues the screenshot was manually modified.
412
accessible from a mobile device25 . However the border between user model and context
model is fluid and some of the filter preferences like employer or current city could also
be a part of the context manager. Last but not least regarding the domain model, in
this scenario the content contains only the internal user data, thus the FriendFinder is
dealing with a closed corpus and does not need a content manager.
Conclusion. The facebook.com FriendFinder Engine plainly fits into the reference model. Mostly because the engine is not using that many possible adaptation methods as
the model suggests, some of the components are not implemented within the FriendFinder. The visualization of the mapping is skipped and will be done after considering the
Ads Engine.
Ads Engine
Adaptation. The exploration of facebook’s ads engine starts with the left picture in
figure B.24 which shows three different commercial ads. Those were presented during
browsing the personal user profile26 . Comparing the displayed ads with the preferences
of the user and current information on the whole page leads to following matches. First
of all at the top of the ads section a game banner is displayed and it is written below the
banner, that a friend of the current user has played this game. In addition the current
page shows a status message, that the current user has started playing a game. The
second ad is displaying a smartphone, actually the last post on the profile page is about
a smartphone application. Last sponsored banner is an advertise for a vacation job and
it may matches with the user preferences, because the current user is a student and does
have vacations.
If the user does have any reason for not willing to see a kind of banner anymore, it is
possible to close a specific ad. This is shown in the right picture of figure B.24. The user
has the possibility to choose between different reasons why to remove the ad. Based on
this selection at least the specific ad will not be displayed any more and it could also
effect that a certain type of advertisement will be hided in the future27 .
Mapping. By mapping the facebook.com Ads Engine to the AAARM some more components can be mapped compared to the FriendFinder Engine. Because the FriendFinder
Engine and the Ads Engine are both part of the same system, this mapping will just
25
I know it is possible to access facebook from a smartphone, but I am not able to test the functionality
by myself. However I hardly guess, that it is possible to use the FriendFinder.
26
The personal user profile contains for example all the messages a specific user has posted.
27
The hiding of a certain type of advertisement is just an obvious supposition. It could not be tested in
detail within this seminar paper.
413
Abbildung B.24.: facebook.com - Ads Engine [126]
expand the FriendFinder mapping. The displayed game ad is obviously at least the result of the user-user matchmaker. The other ads, smartphone and vacation job, could
have been influenced by the content-content matchmaker as well as by the user-content
matchmaker. Also the job banner is connected to a specific context, the vacations in the
year 2011.
A very interesting point is the fact that in this scenario the second-order adaptation
is enabled. The user has the possibility to change the adaptation process by evaluating
the displayed ads. Therefore the Ads Engine makes use of the user analyzer with its user
actions log and the score calculator from the evolution chamber is used.
Conclusion. After reviewing the facebook.com Ads Engine it can be ascertained that
it is also very well fitting into the reference model. Joining the FriendFinder with the
Ads Engine and regarding it as a whole system leads to figure B.25, which shows an
overlay on top of the AAARM with a red highlighting of the matching components.
Except that facebook is dealing with a closed corpus and therefore not needing a content
manager, the only not fully implemented component is the evolution chamber. Probably
it is not easy to determine this components within a foreign system, because it could be
a process deeper within the system and might not be visible to the normal user.
Overall the mapping of the explored facebook components to the AAARM has been
reached successfully. An interesting point is that comparing the real world system with
414
Abbildung B.25.: facebook.com mapped to AAARM
415
the reference model could easily lead to detection of areas within the system where
adaptation could be better implemented, but that is not the focus in this paper.
Jinengo
Components. As mentioned at the beginning of these paper the Jinengo project is an
adaptive system which will be build on top of the AAARM. The main issue of Jinengo
is to provide a route planner service which helps the user to travel sustainable. Actually
the project is under development and it is still in the design phase, which means the
architecture of the system, which will be shown later, is not final yet. However, the main
target of this chapter is to explain the main ideas of adaptivity within these application
by implementing the AAARM.
Most of the system is an agent based software and the basic idea for providing the
sustainable route planning service is to have different agents for looking up a possible
route and several other values like the weather forecast and costs as well as a emission
calculation. Each agent can be replaced by another agent which may calculate the desired
result in a better way.
Adaptation. Thinking of the possible adaptive functionalities of Jinengo starts with
agents. Because of the fact that the system is open to the community, users can also
develop and provide agents. This will probably lead to the case, that some agents are
developed by different developers, but for the same use-case, e.g. providing the weather
forecast. Then it could be the case, that these agents will differ in the quality of their
results, e.g. agent one is providing a better weather forecast than agent two. To measure
the results quality of an agent, the user will have the opportunity to give a feedback for
a result. Based on the users’ feedback the system will start using the agent with the best
feedbacks. It might also be possible for a user or at least for agent assemblers to choose
specific agents. This is the main adaptation functionality.
A next important feature is the presentation of the calculated routes. As explained
already, the system tries to make the user traveling sustainable. Therefore it is needed
to somehow convince the user to take one of the most sustainable routes. This issue will
be reached through the implementation of adaptation methods. The important adaptive
navigation support techniques are adaptive sorting and hiding of links, as well as the
annotation.
Of course the application will have more adaptive functionalities, but most of them are
not concretely planned until now.
416
Abbildung B.26.: Architecture of the Jinengo system
Mapping and Conclusion. Because Jinengo is build on top of the AAARM its architecture is very similar. Each component of the reference model will very likely be covered,
some might be more distinctive than others. The current arichtecture of Jinengo for
milestone one, broken down to the main components, is shown in figure B.26.
Each of the purple components will be realized as agents. Of course the application
has a user model module, which is the same as it is in AAARM, however it provides an
interface for synchronization with a CRM System. The content repository will include
the components context and content manager. The adaptation engine will use the informations from the user model and content repository and merges them with the included
components for adaptation rules and of course the matchmaker. With the presentation composer everything is assembled and accessible through web services which will be
called from the user interface.
417
Abbildung B.27.: Jinengo on top of AAARM
As a result figure B.27 shows Jinengos architecture mapped to the AAARM. The light
green components, evolution chamber and neighborhood manager, are not modeled until
now, but they will be implemented in further milestones.
Conclusion
Within these paper the focus was on the AAARM. To understand these reference model
the following steps were done. First of all we have discussed the general issues of adaptive applications for getting knowledge about the progress which is needed to build an
adaptive application. That has leaded to the introduction of adaptation techniques and
methods which is necessary to recognize adaptive applications and to be clear about how
to to implement adaptivity. In the middle of these paper the AAARM itself has been
explored after having the knowledge about components from previous reference models.
At the end the AAARM has been mapped to the facebook.com FriendFinder Engine
and Ads Engine. As a result the mapping to these real world example was successful.
Last but not least Jinengo, our students project groups application, has been explained
418
towards its adaptive functionalities.
419
Using CRM systems for User Modeling
David Rummel
[email protected]
Abstract. The term paper at hands addresses the use of CRM systems
in conjunction with a user model. It discusses the general structure
of CRM systems and how they can be used to infer a user model. It
presents a simple user model and proposes a method to fill this user
model using an arbitrary CRM system.
In the second part a method will be presented that encourages users
to behave sustainable by influencing them to preferably choose a
sustainable transportation method when planning a trip. This part will
bridge with the Jinengo project.
Finally the usage of a CRM system as a storage for user models and
related data will be examined and discussed.
Key words. Customer Relationship Management, CRM, User Modeling, Sustainability
Introduction
User modeling and applications that adapt to a user’s preferences and expectations attracted much attention lately and are subject to many different research efforts these
days. The sources for user models are very different and in this area many approaches
exist for creating user models for different purposes.
On the other hand more and more enterprises concentrate information about their customers in Customer Relationship Management (CRM) systems. Obviously a CRM system
is a interesting candidate for sourcing a user model.
The term paper at hands proposes a simple user model that can be sourced by virtually any CRM system. To substantiate the claim that virtually any CRM system can be
used as a source for the proposed user model, three wide-spread CRM systems have been
examined. It has been checked, whether these CRM systems deliver the required data
structures in order to be a potential candidate for the user model. Obviously this does
420
not prove that the user model proposed fits with every CRM that exists but the three
CRM systems, which all suffice the requirements, are a hint that the described CRM
structure can be called generic for at least most CRM systems.
The second part of this term paper focuses on how user models can be used to influence
a user’s behaviour. The approaches presented in this part can be implemented to encourage a user to act more sustainable.
The third part discusses the ability of CRM systems to store user models. With the help
of the three aforementioned CRM systems the possibilities for extending a customer
record will be identified and their ability to store a user model will be evaluated.
Related work
In the user modeling domain many research efforts have been made and also many
research efforts are in progress currently. In literature many different approaches are
described focusing on many different aspects and domains, e.g. approaches for adaptive
navigation support in tutoring systems [127], approaches for predicting search engine
usage [128], approaches for interweaving web profiles [129] amongst many others.
Still, to the knowledge of the author the use of CRM systems as a source for user models
has not been explicitly described by now. However, there exist many useful approaches
and algorithms, like the Add-A-Tag-algorithm described in [130], that have been adapted
to the needs of the methods described in this term paper.
User Modeling
User modeling relates to a process that aims to construct a user model or –profile. A user
model contains data of a specific user that has been collected previously and can be used,
for instance, by an adaptive application to match a user’s preferences and expectations.
To achieve this goal a user model can be filled with data from different sources. In literature two main types of data sources are being differentiated: the first one is called
User Actions. This data source offers any kind of data that occurs when a user interacts
with a system. An example for this kind of data is a list of buttons the user clicked in a
system. Another example is the record of the movement of a mouse cursor on a systems
421
window. [131]
User actions are also being referred to as implicit data because this kind of data is being
gathered without actively enforcing the user to provide this data. This data usually is
being generated automatically while the user is interacting with a system. [131]
The second data source type is called User Data. User data – contrary to user actions –
is data the user explicitly provides to the user model and therefore is also being referred
to as explicit data. User data virtually can be any data an user usually provides when
completing her user profile on a website, like e.g. her name, date of birth, residence and
so on. See [131] for a more detailed classification of these two types of data sources.
It is obvious that the approach using implicit data for filling a user model needs more
sophisticated algorithms in order to extract interesting information about a user. The
benefit from constructing a user model based on implicit gathered data however might be
a more valueable user model as it may contain much more detailed and exact information
about a users preferences than she would provide in a user profile when explicitly asked.
Another benefit of the implicit approach is that the amount of data being collected is
much higher than with the explicit amount. This is because in the implicit approach the
user just needs to use the system and while doing this is generating the data for the user
model automatically.
Description of a generic CRM System
These days many different implementations of CRM systems exist in the field. They all
are different in many aspects, however, it is possible to identify properties that virtually
all CRM systems have in common. In order to keep the approach described in this term
paper as generic as possible, we will focus on this set of properties. To substantiate the
generic character of the properties suggested here, three different CRM systems were
checked for their counterpart of each property. The CRM systems examined are Microsoft Dynamics CRM 2011, SuperOffice SIX and SugarCRM. In the following subsections
we will describe the identified common properties in detail.
An overview of the generic CRM system model described here can be seen in figure B.28
422
key word 1
customer record
1
0...n
key word 2
key word 3
.doc
correspondence
key word 4
0...n
correspondence
0%
0...n
key word 6
key word 7
sales chance
100%
key word 8
key word 5
Fig. B.28.: Generic CRM structure
423
Customer Record
The major property that exists in virtually any CRM system is the customer record. The
exact structure of this record differs between the different CRM systems, however, there
are common properties like the customer’s name, address and phone that we consider
to exist in every CRM system. Also, the user model proposed in this term paper, does
not rely on the properties of the customer record, but only requires the record itself to
exist.
The customer record counterparts are called customers (Dynamics CRM and SIX) and
contacts (SugarCRM).
Correspondence
In virtually any CRM system we can identify records that represent types of correspondence of an employee (of the CRM owner) with a customer. This record ususally has a
type (e.g. email, letter, phone call or fax) and further properties, e.g. date and time a
phone call was made. In case of letters, emails and faxes there is also often a document
(e.g. Microsoft Word, PDF) attached. All three examined CRM systems support such
types of correspondence.
In Dynamics CRM they can be represented for instance by offers and bills, SIX allows
to add emails, phone calls and different types of letters (which can include offers and
bills). SugarCRM also allows some types of correspondence, for instance email.
Sales Chance
Another property found in virtually any CRM system is the sales chance record. This
record combines all correspondence related to a sales chance and allows for planning further steps for interacting with the customer to push the sales chance to an successful end.
The counterpart to this property is called opportunity in Dynamics CRM and SugarCRM
and sales chance in SIX.
424
Key words
A further generic property that can be found in CRM systems is the key word property.
This property allows to attach keywords to an object, e.g. a sales chance or a correspondence in order to classify it and to make it easier to find.
In Dynamics CRM the counterpart of this property is the notes field, in SIX there is a
tags property. SugarCRM can tag any object with the SugarTAGS extension.
The generic User Model
In this section the properties identified in section B are used to describe a user model.
The goal is to infer the values of the properties of the user model for a specific user.
Design of the generic user model
The general design of the simple generic user model is shown in figure B.29. The user
model describes two properties. The first one is a value that indicates the preferred
communication channel of a user. This property determines, whether a user prefers to
be contacted for instance via email instead of getting a phone call.
The second property is a list of interests. This list represents topics, tags or keywords
that a user is interested in. An entry in such a list could be for instance a location or a
product.
Inferring the preferred communication channel of a user
In this section we will focus on how to infer the preferred communication channel property of a specific user by using the data from a CRM system. The idea behind this
process is to put all correspondence related to a user (for instance emails sent to a user
or received from a user) into a total order. The requests the company made to a user
are called pitches. If a message can be identified that is directly related to a pitch, for
instance because of a similar subject between two emails or because two correspondences
are assigned to the same project in the CRM then it is called an answer.
In the next step all answers from the user are identified and put into a list that contains
the type of the preceeding pitch and the time span between each pitch and its answer.
425
preferred communication
channel
interests
interest a
interest b
interest c
interest n
Fig. B.29.: Generic user model
426
When this list is completed the average time span between pitch and answer is being
calculated for each pitch type. Based on the results of this calculation the the different
pitch types can be ordered, starting with the pitch type with the shortest average time
span between pitch and answer. The pitch type having the minimum average time span
corresponds to the users preferred communication channel.
An example for inferring this property is shown in figure B.30. On the upper left side
there is an outgoing letter the company sent to the user. This outgoing letter is called
the pitch. Below an email reply to this letter can be identified. Because both correspondences are related to the same sales chance in the CRM system this incoming email is
considered to be the answer to the pitch. The send and receive dates are marked with
dotted circles and a time span of 23 days can be identified. The list can now be appended
by an entry containing pitch type letter and a time span of 23 days.
On the right side of figure B.30 an outgoing email is shown. The answer to this pitch can
easily be determined by looking at the sales chance the email is attached to. Obviously
the incoming email below is the answer. The send and receive dates of this pitch and its
answer are marked with solid circles. The list can now be appended by an entry that
contains the pitch type email and a time span of 3 days.
As the list contains only two entries of two different pitch types the step of calculating
average time spans for each pitch type is unneccessary in this example. We can easily see
that this specific user responded much quicker to an email request than to a letter and
therefore in this example the preferred communication channel of this user is considered
to be email.
Inferring the list of interests of a user
In this section a list of interests for a specific user in a CRM system will be inferred.
The process of inferring this list is made up of the following steps: the first steps consists
of determining all sales chances related a user that have been realized. In the next step
all tags that are related to these sales chances are being collected and added to a list.
The third step counts the amount of occurences of each tag and stores it with the tag.
When this process is finished the list is being sorted, beginning with the tag that occured
most. This tag list can then be considered a list of interests of a specific user, sorted by
importance of interest.
This process is being shown in figure B.31. In this example sales chance A and sales
chance C are considered realized as with both sales chances a positive response from
427
the user has been received. When further examining these two sales chances the tags
Seminar, DB and Hamburg are found being attached. The corresponding table from
processing this customer record is shown in table B.14.
Tag
Seminar
DB
Hamburg
Occurences
2
2
1
Table B.14.: Tags related to user with and the amount of their occurence
This list can be applied to the user model of the customer as her prioritized list of
interests. Further refinements that can be applied to this process in order to make this
list more accurate and meaningful can be found in section B.
Encouraging users to act sustainable
The Jinengo project group aims to offer a mobility service that encourages its users to
behave sustainable. In the Jinengo context behaving sustainable means that its users
choose a sustainable transportation method from a list of transportation offerings. For
instance, if an user got offered to travel a specific route by airplane or by train, the
sustainable choice is (probably) to travel this route by train. The most obvious method
to achieve sustainable behaviour with the user would be to simply hide the option to use
the airplane. However, this is not the way Jinengo wants to encourage users to behave
sustainable, as this approach has some drawbacks. The major drawback is that with this
approach Jinengo is cheating on the user. A user who is well aware of her options for
traveling a specific route may recognize the missing options and may find Jinengo an
unreliable source for planning her travels.
Therefore Jinengo’s approach is to find ways to make sustainable choices appear more
attractive to a user. This approach is supported by Jinengo’s CRM system that contains
a repository of user related data that is being used in order to achieve this goal.
The following section introduces an approach that benefits car pooling which can be a
sustainable transportation method.
428
Seminar
Outgoing Letter
Sales Chance A
Sales Chance A
Date: 03.02.2010
DB
Outgoing eMail
Incoming eMail
Sales Chance C
Date: 12.10.2010
Sales Chance A
Date: 26.02.2010
Result: positive
Incoming eMail
Outgoing eMail
Sales Chance B
Date: 08.07.2010
Sales Chance C
Date: 15.10.2010
Result: positive
Seminar
Sales Chance C
Hamburg
DB
Port
Sales Chance B
Boat
Hamburg
Fig. B.30.: Inferring the preferred communication channel of a customer
Seminar
Outgoing Letter
Sales Chance A
Sales Chance A
Date: 03.02.2010
DB
Outgoing eMail
Incoming eMail
Sales Chance C
Date: 12.10.2010
Sales Chance A
Date: 26.02.2010
Result: positive
Incoming eMail
Outgoing eMail
Sales Chance B
Date: 08.07.2010
Sales Chance C
Date: 15.10.2010
Result: positive
Seminar
Sales Chance C
Hamburg
DB
Port
Sales Chance B
Boat
Hamburg
Fig. B.31.: Inferring the list of interests of a customer
429
Matching users for car pooling
When looking for a car pool, usually the only information available to a potential car
passenger (from now on called requestor ) is the offered route and the date when this
route is being driven by the car owner (from now on called driver ). Some car pooling
sites have recently started to integrate more detailled user profiles that allow requestors
to get some information about a driver in advance28 , but those user profiles can only be
considered after a car pool search and by now this needs to be done manually by the
requestor for each potential car pool offering.
The goal of this approach is to match drivers and requestors who “fit” each other. The
idea behind is, that if a user enjoys her car pool ride, in future she might more often pick
a car pool option. So in this approach making the car pool ride as attractive as possible
is the key to encouraging a user to behave sustainable by herself.
Overview
The approach described in this section searches for potential car pools for a specific
route. The result is a list of matching potential car pools that is not only sorted by
closeness of the car pool to the route the requestor searched for but also by how “well”
the requestor and the driver match. This process can be divided into three steps.
In the first step all car pool offerings that match the requested route and date are being
retrieved from the data provider. They are being scored then, regarding how well the
search parameters of the requestor match the car pool offering. This step is already
implemented in todays car pooling sites and therefore it is not being explained in more
detail in this term paper.
The second step then examines the drivers of the returned car pool offerings and matches
them with the requestor. The result is a score that indicates how close requestor and
driver are, regarding their interests.
In the last step the score of the car pool offering from step 1 gets rated and incorporated
with the user matching score from step 2. The result is an order of car pool offerings
that reflects how well each car pool offering meets the search criteria of the requestor
and how well driver and requestor fit together. The driver and requestor can rate each
other afterwards in order to improve the results of the user matching process in future.
28
e.g. see http://www.mitfahrzentrale.de
430
Scoring closeness of driver and requestor
This section describes an algorithm to match two users, in this context the driver and
the requestor. The algorithm is based on the Nearest Neighbor (NN) algorithm and is
an adaption of the algorithm for modeling short-term interests described in [132]. In this
adaption the news stories that get classified in the aforementioned paper are mapped to
drivers. The actor in the paper, who reads and rates the news maps to the requestor.
The first time a requestor is looking for a car pool the only thing the system can do is try
to find a driver with similar interests because the system has no feedback received from
the requestor yet. Still it knows about the requestors and drivers interests and can select
the best-fitting driver by calculating a matching score. A simple algorithm to achieve
this goal works as follows:
The algorithm merges the interests of a requestor r and a driver d into a list and splits
this list into two groups. Group g1 contains all interests that r and d have in common,
group g2 contains the remaining properties. Then the ratio between these two groups is
being calculated by dividing the amount of items in g1 by the amount of items in g2.
This score then gets calculated for each potential driver. In the end the driver with the
highest score is considered to be the best match for the requestor. See figure B.32 for an
example of this scoring method.
After her first car pool ride, the requestor can rate the driver of this ride. In [132] the
user is asked to rate a news story interesting or not interesting. Then answer then gets
multiplied by the amount of the story the user read. In the end the score is a value
between 0 and 1. This method does not apply to the approach described in this section.
Therefore another way must be used to rate a driver. The solution is simple: the requestor classifies the driver into one category, e.g. interesting, indifferent, tedious. Each of
these categories maps to a score between 0 and 1. This approach considers one dimension
less than the approach described in [132], still we choose this rating method as there is
no further dimension that can be measured easily in order to sharpen the rating of the
requestor.
After each rating a representation of the driver along with the score gets stored in the
user model of the requestor. The representation of the driver is later being used to rate
other drivers, the requestor does not yet know. Therefore a similarity measure between
two drivers representations must be introduced. This similarity measure can either be
the algorithm described above to match two users or the approach described in [132].
The approach there uses TF-IDF (term-frequency / inverse-document-frequency) vectors which is a commonly used method for measuring similarity between two natural
language texts. In this context the approach can be applied to the list of interests of a
431
Interests
B
A
AB 2
CD 2
1
D
Driver d1
Interests
B
1
ACDEZ 5
B
D
E
Z
0.2
Driver d2
Interests
Requestor r1
A
ABC 3
0
B
C
Driver d3
C
ABC 3
Z
1
Interests
3
A
B
C
Z
Driver d4
Fig. B.32.: Matching a requestor and a driver based on their interests
432
B
A
8
Interests
t_min = 1.5
r1
Previous ratings
similarity
2.3
potential
driver
similarity
0.5
d1
d2
scores:
0.9
0.1
similarity
1.8
d4
d3
0.3
weightes scores:
2.07
0.54
predicted score:
(2.07 + 0.54) / 2 = 1.305
Fig. B.33.: Prediciting a score for a potential driver based on previous ratings
driver. See [133] for an exact definition of this algorithm. Both approaches can be used
at this place, however, it is not possible to switch between those two once the decision
has been made.
The next time, the requestor is looking for a car pool, an algorithm based on the requestors previous ratings is being used to match potential drivers with the requestor.
The algorithm works as follows: in the first step the similarity measure of the potential
driver gets calculated. The driver then gets compared to the drivers the requestor rated
previously. All rated drivers who are closer to the new potential driver than t min then
get selected as voters. When the list of voters is complete, the score of the potential
driver gets predicted by calculating a weighted average over the score of all voters where
the weight is the similarity between the voter and the potential driver. See figure B.33
for an overview on how to predict the score of a potential driver.
433
This process gets repeated for all potential drivers so that in the end each of these drivers
has a predicted score. The potential driver with the highest score is then considered to
be the best match for the requestor.
Drawbacks
Obviously, one drawback of this scenario is that it requires a significant amount of participants. Even when examining major car pooling sites like http://www.mitfahrzentrale.
de there often are not many options a user can choose from and therefore a user-user
matching approach will not always lead to an improved car pooling experience. This is
especially true for routes that do not connect two major cities.
However, for routes between major cities this approach might indeed be feasible as on
such routes often a certain amount of potential car pools exist.
Marketing based on CRM
Another approach that aims to encourage a user to choose a more sustainable transportation method is the use of a CRM system to enable the sustainable CRM strategy of
Jinengo. This approach consists of using the analytical CRM system to segment customers into groups that can be addressed with customized marketing campaigns in order
to push customers to a more sustainable behaviour. In [134] there is a comprehensive discussion that addresses this approach, including motivation and background, a fuzzy-logic
approach to segment customers and some examples.
Using the CRM system for storing a user model
In the previous sections the term paper at hands focused on using the data that exists
in a CRM system to infer a user model. This section will discuss whether a CRM system
can be used to store a user model and the raw data used to infer the values of the user
model.
Data types
As already mentioned in the previous section it is necessary to differentiate between two
different types of data.
434
The first type of data is the user model. The user model can contain data about a user
that can be classified as human-interpretable. Such data can be:
Preferences
Interests
But a user model also can contain data that is not human-interpretable. Such data can
be for instance the TF-IDF vectors described in section B which are being used to measure the similarity between two users.
The other type of data that needs to be discussed is the raw data type. This kind of
data usually can be classified non-human-interpretable. Among this kind of data are:
Measurements indicating how long a user watched a specific website
Records of mouse-movements
Navigation elements the user used
This kind of data usually is not part of the user model. However, it might be used to
infer a user model. Further, after using it to infer a user model value, this kind of data
can not always be removed as it might be needed again, for updating the user model.
Storage in a CRM system
Technically it is possible to store all this different kinds of data inside a CRM system.
The systems examined for this term paper all were extendable in one or the other way.
However, it is necessary to differentiate between two types of extensibility:
The first type extends the customer record inside a CRM system with specified properties. These properties then are part of each customer in the CRM system and show up in
views that display the details of a customer. This extension type has a static character
and therefore it is suitable to be used with well-defined properties that should be stored
for each user. An example for such a extension is a customer type that is being used to
classify all customers into customer groups like Platinum, Gold and Silver. This property
is considered static as it has a defined value-range where all customers will fit in one
of those categories. All three examined CRM systems did support such an extension of
a customer record in one or the other way, therefore this can be considered a generic
CRM function. However, since the extension of a customer record shows up in the view
(so a human user of the CRM is being presented these properties) this extension is
435
not suitable for storing user models or even raw data since most of these data are not
human-interpretable and lead to confusion with the CRM user. Further, the static nature of these extensions stands against the dynamic structures that are required to store
a user model or raw data. For instance, in SIX it is only possible to extend a customer
record by simple types like Integers, Dates, Strings and Enums.
The second type allows to extend a customer record in a more dynamic way. Basically
some CRM allow to arbitrarily extend their data model. This is especially true for
SugarCRM. SIX does not seem to support this type of extension while it is still necessary
to evaluate this with Dynamics CRM. The dynamic nature of this extension makes it
interesting for storing user models and raw data. Since this data is not being displayed
to a CRM user by default, the drawback of the first extension type is also compensated
with this extension.
Outlook
The user model proposed in this term paper and the algorithms to construct this user
model from a CRM system are kept very simple. There already exist more sophisticated
algorithms that can be partly applied to the user model construction process in order to
get a more meaningful user model. In the following section some possible enhancements
for the process of inferring the list of interests of a specific user will be shown that are
based on already existing algorithms and approaches. Also, necessary follow-on work will
be presented.
Enhancing the algorithm to infer a list of interests
The first improvement can be achieved by applying the Add-A-Tag algorithm described
in [130]. This algorithm introduces among others the following improvements: Measuring
co-occurences of tags and considering older tags less than newer tags. Applying this to
the example from section B means that the table for storing tags and their occurence
now contains tupels of tags. The new major interest would now be Seminar – DB. This
improvement helps for instance sorting out very general tags. By only considering tags
that occur together the chance for having very general interests, like e.g. Web, is being
lowered. To consider the temporal dimension of this algorithm we can simply use date
of object we retrieve the tags from.
A second improvement can be introduced by using so called WordNets to normalize
tags. WordNets can be used for identifying different words that have the same meaning.
436
An example for such a word-pair is Web and Internet. By pre- or postprocessing the
list of interests the amount of interests can be reduced resulting in a more distinct and
meaningful list of interests.
Follow-on work
A more detailed investigation on Dynamics CRM needs to be done, as this is the chosen
CRM system for the Jinengo project. This is especially interesting for the BI module
new in Dynamics CRM 2011 which very likely offers new opportunities with regards to
user modeling.
Conclusion
In this term paper a generic structure of a CRM system has been discussed that was
deduced from examining three different CRM systems. A user model has been presented
that can be sourced by this generic CRM structure. Algorithms and possible enhancements to those algorithms have been shown that can be used to fill such a user model.
In the authors opinion those approaches are feasible. The generic CRM structure is substantiated by the examination of three different CRM systems. The algorithms to fill the
user model are an adaption of previously known algorithm.
Further, it has been discussed how a CRM system can be used to encourage a user to
act more sustainable. An approach has been presented that tries to predict how well
two users sharing a car pool match. Even if the method for matching car pool users
is an adaption of a well-known algorithm it still is necessary to evaluate whether this
approach as a whole is feasible. Section B already mentions some potential drawbacks
which may constrain this approach to some special use cases.
A discussion was held that focuses on how suitable a CRM system is for storing user
models and raw data. In this section two different types of data extensions for CRM
system have been identified. In the authors opinion the second extension type is suitable
for storing a user model while the first type should not be used for storing user models
or raw data. Unfortunately it seems, not all CRM systems allow for extending their data
model using the second extension type.
437
Grundlagen klassischer Kundenanreizsysteme
und Möglichkeiten der Steuerung des Kunden
zu einem nachhaltigen Konsum
Daniel Schnieders
[email protected]
Zusammenfassung: Nachhaltigkeit hat in den letzten Jahren verstärkt
an Bedeutung gewonnen und ist mittlerweile in vieler Munde. Die
folgende Ausarbeitung beschäftigt sich mit den Begriffen Nachhaltigkeit und Konsum. Es wird hinterfragt in Wie weit Nachhaltiger Konsum überhaupt denkbar und erreichbar ist und welche ökonomischen,
ökologischen und sozialen Aspekte eine Rolle spielen. Weiterhin soll
die Steuerung des Kunden zu einem Nachhaltigen Konsum betrachtet werden. Um einen Kunden zu einem nachhaltigen Konsum steuern
zu können, muss man ihn zuvor als langfristigen“ Kunden gewinnen.
”
Hierfür gibt es eine Reihe von Instrumenten zur Kundengewinnung und
Kundenbindung, welche im Folgenden näher betrachtet werden. Je nach
Markt oder Wettbewerbssituation kann es sinnvoll sein, die Marketinganstrengungen auf die Neugewinnung von Kunden zu konzentrieren oder
die bisherigen Kunden verstärkt zu steuern. Anschließend sollen Beispiele für einen nachhaltigen Konsum hervorgebracht werden. Zum Schluss
wird auf die Steuerung des Kauf- und Konsumverhaltens von Kunden
eingegangen und eine Verbindung zum Jinengo Projekt hergestellt.
Schlüsselwörter: Nachhaltigkeit, nachhaltiger Konsum, Kundenakquisation, Kundenbindung, Kundensteuerung, Jinengo
438
Einleitung
Nachhaltigkeit hat in den letzten Jahren verstärkt an Bedeutung gewonnen und ist
mittlerweile in vieler Munde. Nachhaltigkeit findet man in vielen Bereichen des Lebens
wieder, weshalb der Begriff genauer erklärt und abgegrenzt werden muss. Nachfolgend
soll der Begriff mit dem Konsumverhalten von Menschen in Verbindung gebracht werden.
Es ist zu untersuchen ob Nachhaltigkeit und Konsum überhaupt zusammenpassen“ und
”
ob ein nachhaltiger Konsum tatsächlich erreichbar ist.
Im Rahmen der Projektgruppe Sustainable Customer Relationship Management für
”
EMobility Services mit SOA”wird eine Software namens Jinengo”
”
zur Reiseplanung entwickelt, welche dem Benutzer erlauben soll, sich möglichst Nachhaltig zu bewegen. Um eine Abgrenzung zu einem normalen Routenplaner zu schaffen,
gilt es herauszufinden, mit welchen Mitteln sich Kunden beeinflussen und steuern lässt,
ein nachhaltigeres Fortbewegungsmittel zu nutzen. Ein Beispiel wäre die Nutzung eines
Car-Pooling Services für den täglichen Arbeitsweg anstelle des eigenen Autos zu nutzen,
um sowohl Kosten zu sparen als auch die CO2 -Emissionen zu vermindern.
Anschließend soll Car-Sharing als praktisches Beispiel für einen nachhaltigen Konsum
aus der Nutzersicht thematisiert werden. Hier sollen typische Motive für die Nutzung eines nachhaltigen Konsumgutes herausgefiltert werden, um auf Basis der Motive, Kunden
besser steuern zu können. Nachfolgend soll am Beispiel Amazon praktisch konkretisiert
werden, wie Kunden sich durch ein personalisiertes Marketing leiten lassen.
439
Begriffsdefinition
In diesem Kapitel sollen kurz die Begriffe Konsum und nachhaltiger Konsum erklärt werden, um ein gleiches Verständnis der Begriffe für den weiteren Verlauf der Ausarbeitung
zu schaffen.
Konsum
Unter Konsum werden sämtliche Aktivitäten von Einzelpersonen oder privaten Haus”
halten verstanden, die auf die Entnahme von Gütern oder Dienstleistungen aus dem
Markt gerichtet sind. [...] Soziologisch gesehen ist Konsum soziales Handeln mit umfassenden gesellschaftlichen und individuellen Funktionen.” [135]
Produkte und Dienstleistungen werden heute konsumiert um die verschiedensten Wünsche
und Bedürfnisse zu befriedigen. Konsum ist heutzutage nicht mehr nur die Grundlage zur
Deckung des täglichen Bedarfs an beispielsweise Lebensmitteln, sondern dient auch der
sozialen Teilhabe. Heutzutage sind Konsumentscheidungen auf Faktoren wie Prestige,
Individualität oder auch Langeweile zurückzuführen.
Nachhaltiger Konsum
Der Ursprung des Begriffs stammt aus der Agenda 21 [135], welche 1992 auf dem Weltgipfel in Rio verabschiedet wurde. Das Kapitel 4 der Agenda befasst sich vor allem mit
den Änderungen der Konsumgewohnheiten, welche für eine nachhaltige Entwicklung notwendig sind.
Zehn Jahre später fand in Johannesburg der Weltgipfel für nachhaltige Entwicklung (eng:
World Summit on Sustainable Development, WSSD) [136]statt. Hier wurde der sogenannte Marrakesch-Prozess beschlossen, auf dessen Grundlage ein 10-Jahres Programm
zur Stärkung nachhaltigen Konsums entwickelt wurde. Der Prozess soll von führenden
Industrieländern angeführt und finanziert werden.
Eine bis heute stark verbreitete Definition von Nachhaltigem Konsum stammt aus 1994:
Unter nachhaltigem Konsum versteht man also den Konsum (von Gütern und Dienst”
leistungen), der die Bedürfnisse der Konsument(Innen) erfüllt, Umwelt und Ressourcen
schont und sowohl sozialverträglich als auch ökonomisch tragfähig ist.“ [137]
Die Begriff nachhaltiger Konsum steht eng im Kontext mit einer Nachhaltigen Entwicklung. Unter Nachhaltiger Entwicklung verstehen wir eine Entwicklung, welche zukünftigen
Generationen erlaubt, ihre eigenen Bedürfnisse zu befriedigen. Holger Rogall hat in
440
seinem Buch Ökonomie der Nachhaltigkeit: Handlungsfelder für Politik und Wirt”
schaft”die Ziele der Nachhaltigen Entwicklung ökologisch, ökonomisch und sozial-kulturell
betrachtet:
Ökologische Ziele
1. Schutz der Erdatmosphäre
2. Schutz des Naturhaushalts (inkl. Flächenverbrauch und Artenschutz)
3. Ressourcenschonung (Ressourcenverbrauch ¡ Regenerationsrate, Ausnahme:
unerschöpfliche Ressourcen)
4. Schutz der Menschlichen Gesundheit (inkl. Lärm und Schadstoffe)
5. Mobilität in den Grenzen des Umweltraumes
Ökonomische Ziele
1. Vollbeschäftigung bei akzeptabler Arbeitsqualität
2. angemessene Einkommen und wirt. Entwicklung in den Grenzen des Umweltraumes
3. außenwirtschaftliches Gleichgewicht und Entwicklungszusammenarbeit
4. Preisstabilität
5. ausgeglichener Staatshaushalt bei ausreichender Ausstattung mit meritorischen (kollektiven) Gütern
Sozial-kulturelle Ziele
1. soziale Sicherheit
2. Demokratie und Rechtsstaat
3. innere und äußere Sicherheit (Frieden)
4. soziale Integration und gerechte Lebenschancen (inkl. Gleichberechtigung der
Geschlechter)
5. Lebens- und Gesundheitsqualität
(Quelle: Ziele entnommen aus [138], Eigene Darstellung)
441
Die Ziele zeigen, dass Nachhaltigkeit keinesfalls nur die eigene Einstellung beinhaltet,
sondern auch von Politik und Wirtschaft stark beeinflussbar ist. Nachhaltigkeit ist ebenfalls stark ethisch begründet und beruht auf den Grundprinzipien der Gerechtigkeit und
der Verantwortung zwischen Menschen der Gegenwart und zwischen den Generationen.
Weitere grundlegende und umfassende Darstellungen der ethischen Prinzipien findet man
in [138].
Anreizsysteme
Im Folgenden werden kurz einige gängige Definitionen von Anreizsystemen vorgestellt.
Ein Anreizsystem ist“.. die Summe aller bewusst gestalteten Arbeitsbedingungen, die
bestimmte Verhaltensweisen etc.) verstärken, [sowie] die Wahrscheinlichkeit des Auftretens anderer dagegen mindern (negative Anreize, Strafen)...” [139]. Die Wirkung ist die
Verstärkung bestimmter Verhaltensweisen und Minderung anderer. Die zu ergreifenden
Ma
ss nahmen sind die bewusste Gestaltung von Arbeitsbedingungen durch positive und
negative Anreize, Belohnungen und Strafen.
Ein Anreizsystem besteht “aus einer Menge von Anreizen und einer Menge von Kriterien, die jeweils durch Relationsvorschriften unter Einblendung der Zeit miteinander
verknüpft werden, um die Erreichung von Unternehmenszielen zu unterstützen.” [140]
Das Ziel ist hier die Unterstützung der Erreichung von Unternehmenszielen. Hierzu werden Anreize mit Kriterien verknüpft.
“Von einem Anreizsystem ist zu sprechen, wenn mehrere Anreize mit der Funktion von
Belohnungen angeboten und so aufeinander abgestimmt werden, dass sie im Wirkungsverbund erwünschte Verhaltensweisen auslösen und unerwünschte Verhaltensweisen unterstücken oder zurückdrängen.” [141] Ziel ist die Auslösung erwünschter Verhaltensweisen und Unterdrückung unerwünschter Verhaltensweisen. Die Maßnahmen hierfür sind
Anreize mit der Funktion von Belohnungen.
“Anreizsysteme werden als geplante, funktional eindeutig definierbare, formalisierte Beziehungen zwischen Kriterien (Bemessungsgrößen) und Belohnungen/Bestrafungen (Anreizen) im betrieblichen Kontext verstanden.” [142] Hierfür müssen Beziehungen zwischen Kriterien und Belohnungen (Anreizen) geschaffen werden.
Die vorgestellten Anreizsysteme zeigen, dass die Zielerreichung in erster Linie über Anreize erreicht werden soll. Die Systeme sind teilweise auf Arbeitgeber- und Arbeitneh-
442
Abb. B.34.: Phasen des Kundenbeziehungslebenszyklus [143]
merbeziehungen definiert, können aber auch für Unternehmens- und Kundenbeziehungen
verwendet werden. In der Literatur gibt es drei unterschiedliche Funktionen von Anreizsystemen: Motivationsfunktion, Koordinationsfunktion, Selektionsfunktion. Sie haben
eine Motivationsfunktion, wenn sie zur Motivation der Mitarbeiter / Kunden beitragen.
Um diese zu lenken besitzen sie eine Koordinationsfunktion und um die richtigen Mitarbeiter und Kunden auszuwählen besitzen sie eine Selektionsfunktion. Auf den speziellen
Einsatz der Anreizsysteme am Beispiel von Jinengo wird später in Kapitel B näher
eingegangen.
Kundenakquisition
Phasen der Kundenakquisition
Im Rahmen des Kundenbeziehungslebenszyklus werden drei Phasen unterschieden:
[143]
Kundenakquisition
Kundenbindung
Kundenrückgewinnung
443
Die Abbildung beschreibt auf der X-Achse die Dauer der Kundenbeziehung und auf
der Y-Achse die Starke / Intensität der Kundenbeziehung. Anfangs ist die Intensität 0
und steigert sich im Laufe der Kundenbeziehung. Der Größte Anstieg ist in der Phase
der Kundenbindung festzustellen, welche aber im Folgenden nicht weiter erläutert wird,
da sie nicht Thematik der Ausarbeitung ist. Weiterhin ist festzustellen das die drei
vorgestellten Phasen des Kundenbeziehungslebenszyklus jeweils in weitere Teilphasen
unterteilt werden.
Nachfolgend soll lediglich die Phase der Kundenakquisition näher erläutert werden. Die
Phase der Kundenakquisition ist das Fundament der Beziehung zwischen Anbieter und
Nachfrager. Ökonomisch gesehen ist dieses Phase schlecht für das Unternehmen, da die
Kundengewinnung mit hohen Startkosten verbunden ist. [143]
Sie ist unterteilt in die Anbahnungs- und Sozialisationsphase.
In der Anbahnungsphase haben der Anbieter und der Nachfrager noch keinen Kontakt.
Hier bemüht sich meist der Anbieter den Kontakt zum Nachfrager herzustellen. Er versucht ihn von der Vorteilhaftigkeit seiner Produkte oder Dienstleistungen zu überzeugen
und stimuliert ihn, das Angebot erstmals von diesem Anbieter zu nutzen. [143] Die Sozialisationsphase beginnt, wenn der Anbieter mit dem Nachfrager in Kontakt getreten
ist. Das Ziel des Anbieters ist es, seine Leistungen an den Kunden heranzuführen und
ihn an das Leistungsangebot zu gewöhnen. [143]
444
Instrumente der Kundenakquisition
Im Jahr 2002 wurden 686 Unternehmen aus den Branchen Konsumgüter-Hersteller,
Konsumgüter-Handel, Banken/Sparkassen/Versicherungen, TIME (Telekommunikation,
Information, Media, Entertainment), Automotive (Hersteller und Zulieferer und Multi
Utility anhand eines standardisierten Fragebogens hinsichtlich ihrer Instrumente der
Kundenakquisition telefonisch befragt. [144]
Die folgende Auflistung zeigt die Einsatzhäufigkeit (Anzahl der Unternehmen) von klassischen Instrumenten zur Kundenakquisition:
Systematische Analyse über potentielle neue Kunden / Zielgruppen (621)
Systematische Kontaktaufnahme mit potentiellen Kunden (585)
Hohe Flexibilität bei Erstkunden / Neuverträgen (569)
Nutzung von Referenzkunden (532)
Preisnachlässe / Sonderangebote für Erstkunden (481)
Probierangebote / Einstiegspakete für potentielle Neukunden (428)
Großzügige Rücktrittsmöglichkeiten für Erstkunden (419)
[144]
Von den aufgelisteten Instrumenten setzen die Unternehmen am meisten auf eine Systematische Analyse über deren Kunden und gleichzeitig auch auf die direkte Kontaktaufnahme dieser Kunden. Relativ wenige Unternehmen bieten jedoch dem Kunden Probierangebote, Preisnachlässe oder großzügige Rücktrittsmöglichkeiten.
Nachhaltigkeit und Konsum
Die Betrachtung von Nachhaltigkeit und Konsum im Zusammenhang kann zu einigen
Spannungsfeldern führen. Zum einen ist das erwerben und konsumieren von Produkten
und Dienstleitungen der zentrale Motor unseres Wirtschaftssystems, zum anderen tragen
die Produktion, der Transport und der Vertrieb, sowie die Nutzung und Entsorgung von
Produkten und Dienstleistungen maßgeblich zu Umweltbelastungen bei (Vgl. [145]).
Hier stellt sich die Frage in wie weit sich eine Änderung oder Anpassung unseres Konsumverhaltens auf die wirtschaftliche Lage zurückverfolgen lässt. Der Konsum von Gütern
hat sowohl positive wie auch negative Seiten. Weiterhin sollte der Konsum nicht nur rein
funktional betrachtet werden. Der Konsum hat auch eine soziale Seite.
445
Weiterhin ist der Konsum keine Privatsache mehr, denn alle (als Individuen, als Haushaltsmitglieder, als Angehörige einer Organisation, ...) nehmen Güter in Anspruch.
Diese Gegensätze lassen auf die folgende Frage schließen: Wie ist Konsum aus der Perspektive der Nachhaltigkeit zu beurteilen?
Die Idee der Nachhaltigkeit gemäß der UN besagt, dass sich die globale, regionale und
”
nationale Entwicklung der menschlichen Gesellschaft am umfassenden, übergeordneten
Ziel auszurichten hat, die (Grund-) Bedürfnisse aller Menschen – gegenwärtiger wie
künftiger – zu befriedigen und allen Menschen ein gutes Leben zu gewährleisten.”(Vgl.
[146] [147])
Im Folgenden soll beschrieben werden, was unter dem Begriff gutes Lebenßu verstehen
”
ist. Laut Antonietta Di Giulio lässt sich der Begriff der Guten Lebens in folgende Punkte
untergliedern:
Pflicht zur Gewährleistung für Individuen, Staaten und Staatengemeinschaft”
”
Globaler und langfristiger (generationsübergreifender) Anspruch”
”
Verträglichkeit mit Vorstellungen von Freiheit und Demokratie, mit kulturellen
”
Unterschieden”
Fähigkeitenansatz”
”
(Quelle: [148])
Der Begriff des guten Lebens ist also unabhängig von individuellen Vorlieben, Neigungen
und Wünschen sowie dem subjektivem Wohlbefinden. Der Fähigkeitenansatz beschreibt
ausgehend von Eigenschaften und Fähigkeiten, die als universal kennzeichnend für den
Menschen erachtet werden die Bedingung eines (individuell guten Lebens und bietet die
Möglichkeit, diese im eigenen Leben zu konkretisieren und zu entfalten. (Vgl. [148])
Martha Nussbaum’s Fähigkeitenansatz zeigt, dass zum Leben mehr als nur das Lebensnotwendige wichtig ist. Nachfolgend ein kleiner Ausschnitt aus dem Fähigkeitenansatz
welcher als Grundlage für ein Nachhaltiges Leben angesehen werden kann:
1. Fähig zu sein, bis zum Ende eines vollständigen menschlichen Lebens leben zu
”
können, soweit es möglich ist; nicht frühzeitig zu sterben oder zu sterben, bevor das
Leben so vermindert ist, da es nicht mehr lebenswert ist.
2. Fähig zu sein, eine gute Gesundheit zu haben; angemessen ernährt zu werden; angemessene Unterkunft zu haben; Gelegenheit zur sexuellen Befriedigung zu haben; fhig zu
sein zur Ortsveränderung. [...]
446
7. Fähig zu sein, für und mit anderen leben zu können, Interesse für andere Menschen
zu zeigen, sich auf verschiedene Formen familialer und gesellschaftlicher Interaktionen
einzulassen.
8. Fähig zu sein, in Anteilnahme für und in Beziehung zu Tieren, Pflanzen und zur Welt
der Natur zu leben”
[149]
Demzufolge dient der Besitz, die Nutzung und der Verbrauch von Gütern nicht dem
Selbstzweck, sondern ist auf Bedürfnisse bezogen.
Die folgende Abbildung zeigt Schematisch den Bezug zwischen Konsumgütern und den
Individuellen Konstrukten des Wollens”: Sie beschreibt die Verwendung von natürlichen
”
Ressourcen für die Erstellung / Herstellung von Konsumgütern. Verschiedene Konsumgüter wie Produkte und Dienstleistungen befriedigen individuelle Konstrukte des
Wollens und erzeugen subjektive Wünsche. Zusätzlich geben die Konsumgüter eine Vorstellung über den Grad und den Umfang der Befriedigung, welche sie erzeugen. Aus
den subjektiven und objektiven Bedürfnissen entsteht nun ein Anspruch, welcher an die
Konsumgüter gestellt ist.
447
Abb. B.35.: Nachhaltigkeit und Konsum (Quelle: [148])
448
Beispiele für Nachhaltigen Konsum
Trotz der teilweise schwierigen Verbindung von Nachhaltigkeit und Konsum gibt es immer wieder neue Ideen und Entwicklungen, welche diese beiden Teilgebietet miteinander
vereinen. Im Folgenden werden einige Beispiele kurz erläutert.
Car-Sharing als Beispiel für Nachhaltigen Konsum
Um das Beispiel Car-Sharing zu verdeutlichen, müssen zunächst verschiedene Formen
der (geteilten) Autonutzung verglichen werden.
Die verbreitetste Form ist der klassische Autobesitz. Sie ist gekennzeichnet durch eine
dauerhafte Verfügbarkeit des Autos und ist zu gleich auch die teuerste Variante. Sie ist
gekennzeichnet durch die hohen Fixkosten beim Kauf und durch die Haltung des Fahrzeugs. Allerdings rentiert sich laut dem Münchner Umwelt-Institut die Eigenanschaffung
eines Autos ab ca. 10.000 km pro Jahr im Gegensatz zum Car-Sharing.
Die zweite Form ist die klassische Autovermietung. Hierbei handelt es sich um einen
temporären Besitz eines Autos. Finanziell lohnt sich diese Art der Autonutzung meist
nur bei langen Strecken, da sich der Preis meist kilometerunabhängig berechnet.
Car-Pooling ist die dritte Form und zeichnet sich durch eine gleichzeitige Nutzung mehrerer Personen zur gleichen Zeit aus. Die Nutzung eignet sich für Regelmäßige Fahrten
wie zum Arbeitsplatz. Eine verwandte Form des Car-Poolings sind Sammeltaxis.
Car-Sharing hingegen ist vor allem für einzelne Fahrten gedacht. Der Preis ist in den
meisten Fällen sowohl Zeit- als auch Kilometerabhängig. Daher können lange Strecken
oder die Nutzung über eine komplette Nacht vergleichsweise teuer ausfallen. Es wird
unterschieden zwischen privatem und Car-Sharing und dem Car-Sharing als Unternehmen, welcher meist von Geschäftskunden genutzt wird. Die Geschäftsidee hinter dem
ganzen Car-Sharing basiert auf einer großen Anzahl von Nutzern, denn je mehr Nutzer
mitmachen, desto größer ist der Nutzen für den einzelnen. Die Grundidee ist auch unter
dem Begriff Nutzen statt Besitzen bekannt.
Der ökonomische Hauptvorteil liegt in der Verteilung der hohen Fixkosten der Autohaltung auf einen möglichst großen Kreis von Mitzahlenden. Die ökologische Bedeutung
”
des Car-Sharings liegt vor allem in der Stärkung eines multimodalen (die Verkehrsteilnehmenden nutzen verschiedene Verkehrsmittel für verschiedene Wege) beziehungsweise
intermodalen (mehrere Verkehrsmittel für die verschiedenen Etappen eines komplexen
Weges) Verkehrsverhaltens. Dadurch vermindern sich Autonutzung und Umweltbelastung wesentlich.” [150]
Um den Kunden zu einem Nachhaltigen Konsum steuern zu können, müssen zuerst einige Motive betrachtet werden, warum Menschen sich für einen nachhaltigen Konsum
449
entscheiden.
Baum und Pesch veröffentlichten 1994 eine Befragung über die Beitrittsgründe von deutschen Car-Sharing-Kunden.
Beitrittsgründe
Umweltschutzaspekte
Ergänzung zum ÖV
Eigener Pkw zu teuer
Seltene Pkw-Nutzung
Parkprobleme für eigenen Pkw
Bessere Pkw-Verfügbarkeit
Car-Sharing-Nutzer in %
70,7%
43,3%
38,7%
27,6%
17,3%
5,1%
Tabelle B.15.: Beitrittsgründe deutscher Car-Sharing-Kunden (1994) (Quelle: [151])
Beitrittsgründe
Ökologische Aspekte
Ökonomie und Kostenargumente
Bequemlichkeitsgründe
Car-Sharing-Angebot
Mobilitätsbedürfnisse
Car-Sharing-Nutzer in %
19%
26%
23%
14%
63%
Tabelle B.16.: Beitrittsgründe schweizer Car-Sharing-Kunden (1998) (Quelle: [152])
Wie den Tabellen zu entnehmen ist, waren 1994 die ökologischen Gründe Hauptbeitrittsgrund für Car-Sharing-Kunden. Inzwischen haben diese Motive aber immer mehr an
Wert verloren und werden durch Kostenargumente und Mobilitätsbedürfnisse verdrängt.
Wenn man einen Kunden also in Richtung eines nachhaltigen Konsum lenken möchte,
ist es wichtig, dass die Dienstleistung oder das Produkt nicht oder nur geringfügig teurer ist, als ein vergleichbares nicht nachhaltiges Produkt. ökologische Aspekte können
gut im Bereich des Marketings für die Produkte eingesetzt werden. Inzwischen wird die
Verfügbarkeit der Produkte auch immer wichtiger. Wenn ein Kunde beispielsweise für
ein nachhaltiges Produkt einen längeren Weg in Kauf nehmen muss, wird er vermutlich
durch den erhöhten Zeitaufwand abgeschreckt.
Steuerung des Kauf- und Konsumverhaltens
Unter dem Kaufverhalten (auch Käuferverhalten, Konsumentenverhalten oder Kunden”
verhalten) versteht man das Verhalten des Käufers in Bezug auf den Warenkauf.” [153]
Bei dem Begriff Kaufverhalten muss zwischen verschiedenen den Akteuren unterschieden
werden. Das Kaufverhalten von Kaufleuten unterscheidet sich z.B. maßgeblich von dem
Kaufverhalten von Nichtkaufleuten, seien es z.B. Einrichtungen oder Privatpersonen. Die
folgende Tabelle zeigt die Beziehungskonstellation zwischen Konsumenten, Unternehmen
450
und öffentlichen Organisationen, wobei jeder Akteur sowohl in die Rolle der Käufers als
auch der Verkäufers schlüpfen kann. Hieraus ergeben sich 9 verschiedene Konstellationen
zwischen den Teilnehmern. (Vgl. [153])
Konsument
(Consumer)
Konsument
Unternehmen
öffentliche Organisation
C2B
B2C
A2C
Unternehmen öffentliche
(Business)
Organisation
(Administration)
C2B
C2A
B2B
B2A
A2B
A2A
Tabelle B.17.: Anbieter und Nachfrager Beziehungen (Quelle: [154])
Im Folgenden soll auf den Punkt Business to Consumer (abgekürzt B2C oder BtC) näher
eingegangen werden. Der Business to Consumer Bereich besteht aus einer Transaktion
zwischen Unternehmen und Privatpersonen. Der Transaktionsvolumen sind verhältnismäßig
niedrig, dafür ist die Anzahl der Kunden verhältnismäßig hoch. Dem Konsumenten werden in der Regel viele verschiedene Produkte angeboten. Die Beziehung ist in der Regel
kurzfristig.(Vgl. [155] )
Online-Shops sind ein häufiges Beispiel für Business to Consumer Beziehungen. Im Folgenden soll die Beziehung am Beispiel des Onlineshops Amazon.de erläutert werden.
Amazon nutzt zwar nicht nur die B2C Beziehung, jedoch wird der Fokus im Folgenden
darauf liegen.
Beim Onlineshop gibt es einen Multimediakatalog, welcher Informationen über Preis,
Verfügbarkeit, Hersteller, Anbieter, Lieferzeit und vielen anderen Attributen der Produkte informiert. Produkte können so vom Konsumenten betrachtet und gegebenenfalls
in den Warenkorb gelegt und gekauft werden. Neben den Basisfunktionen eines Onlineshops bietet Amazon noch einige weitere Interessante Aspekte für den Kunden. So
kann dieser sich z.B. jederzeit über den Bearbeitungszustand informieren oder über eine
DHL-Schnittstelle den Weg des Paketes verfolgen. Neben dem normalen Verkauf bietet
Amazon auch einen Marktplatz, auf dem so genannte zShopsëigene Produkte und auch
”
gebrauchte Ware verkaufen können.
Wie steuert Amazon das Kauf- und Konsumverhalten der Kunden? Amazon
empfiehlt dem Besucher der Webseite diverse Artikel, welche aufgrund des Kauf- und
Surfverhaltens des einzelnen zusammengestellt werden. Betrachtet oder kauft der Benutzer z.B. einen Kriminalroman von Agatha Christie, so kann es sein, dass Amazon dem
Benutzer nun sowohl andere Bücher von Agatha Christie oder aber andere Kriminalromane vorschlägt. Betrachtet man einen bestimmten Artikel, erscheint direkt eine Liste
von Artikeln, welche von anderen Konsumenten ebenfalls gekauft wurden, welche auch
den betrachteten Artikel gekauft haben.
Weiterhin erhält ein Kunde, je nach Häufigkeit der Benutzung von Amazon diverse
451
personalisierte Marketing-Mails, welche einem z.B. auf neue Produkte oder Rabatte aufmerksam machen sollen. Hat man beispielsweise das Bürgerliche Gesetzbuch (BGB) in
der 65. Auflage gekauft, informiert einen Amazon, sobald die 66. Auflage zum Verkauf
bereit steht.
Amazon bietet z.B. auch Services an, wobei sich der Amazon Account z.B. mit einem
Facebook Account verknüpfen lässt. Auf diese Art kommt Amazon an weitere Vorlieben
und Profildaten des Benutzers heran, welche z.B. aus Gruppenzugehörigkeiten gefiltert
werden.
Mit Hilfe eines solchen Empfehlungssystems, wie Amazon es verwendet, könnte man z.B.
einem Benutzer auch nachhaltige Produkte empfehlen. Schaut sich ein Kunde z.B. einen
Kühlschrank an, könnte man dem Kunden auch nachhaltigere Kühlschränke mit weniger
CO2 -Emissionen empfehlen.
Eine weitere Möglichkeit wäre ein Nachhaltigkeitsranking einzuführen, welches besonders Umweltfreundliche Benutzer bei der Produktauswahl beeinträchtigen könnte. Das
Ranking würde Produkte einem Vergleich von Kaufpreisen, jährlichen Folgekosten (z.B.
Strom) oder Ergebnissen von Qualitätstests unterziehen. Ein weiterer Indikator könnten
Umweltbelastungspunkte sein. Ein Verfahren zur Berechnung der Umweltbelastungspunkte (UBP - auch Ökopunkte genannt) ist die UBP-Methode. Die UBP werden
berechnet durch die Multiplikation von Bilanzmengen und einem Umweltbelastungsfaktor (UBF). Für den UBF werden zwei Arten ökologischer Knappheit unterschieden
(Vgl. [156]):
Die Ratenknappheit bezieht sich auf Güter, die durch die Medien Wasser, Bo”
den oder Luft innerhalb eines bestimmten Zeitraumes wieder regeneriert werden
können. Dabei ist das Regenerationsvermögen nach oben begrenzt. Diese Obergrenze wird kritische Fracht Fk bzw. kritischer Stofffluss genannt.” [156]
Die Kumulativknappheit gilt für nicht-regenerative Güter. Bei diesen Gütern muss
”
man davon ausgehen, dass sie nach einer bestimmten Zeitspanne aufgebraucht
sind. Liegt diese Zeitspanne innerhalb von 30 Jahren (d. h. einer Generation),
dann wird ein Gut als knapp angesehen. Die kumulative Knappheit berechnet
sich dann aus dem Verhältnis zwischen bekannten Vorräten und dem auf 30 Jahre
hochgerechneten durchschnittlichem Jahresverbrauch.” [156]
Es gibt noch weitere Verfahren zur Berechnung der UBP, welche hier nur der Vollständigkeit
halber aufgeführt werden sollen:
Relativbewertungsverfahren
SETAC-Methode (Society for Environmental Toxicology and Chemistry)
MIPS-Methode (MIPS = Materialintensität pro Serviceeinheit)
Generell ist der Kunde also durch folgende praktische Umsetzungen zu einem nachhal-
452
tigen Konsum anzuregen:
Immaterielle Mehrwerte
Materielle Mehrwerte
Im konkreteren Fall von Jinengo wären die immateriellen Mehrwerte z.B. Gewinnung an
Flexibilität, Zeitgewinn, erhöhtes Wohlbefinden oder ein leichteres Erreichen des Ziels.
Ein erhöhtes Wohlbefinden könnte z.B. durch die Reise mit der Bahn erreicht werden,
denn hier ist der Benutzer in der Lage, z.B. während der Fahrt zu lesen, was er bei einer
Reise mit dem PKW nicht könnte.
Materielle Mehrwerte könnten leicht über andere Verkehrsmittel erreicht werden. Eine
regelmäßige Anreise mit dem Bus zur Arbeit wäre, ohne ein Rechenbeispiel zu geben,
vermutlich nachhaltiger und günstiger als die Anreise mit dem PKW. Dafür würden die
gerade genannten immateriellen Mehrwerte deutlich an Wert verlieren.
Im Bereich der Webtechnologien gibt es immer “ranking-basierende” Modelle, in denen der Benutzer virtuelle Punkte, Tropäen, Medallien oder Titel erhält. Diese Modelle
sind meistens als eine Art Spiel konzeptioniert und dienen dazu, dass dem Benutzer
nicht “langweilig” wird. Am Beispiel von Jinengo könnte man z.B. für eingesparte CO2 Emissionen Punkte vergeben. Diese Punkte müssten in einer Rangliste von den Benutzern einsehbar sein. Ab einer bestimmten Anzahl an Punkten könnte man einem Benutzer auch ein bestimmtes Gimmick freischalten, welches aber für den normalen Betrieb
der Software nicht von Relevanz ist.
Fazit
Diese Arbeit hat gezeigt, dass es verschiedene Motive gibt, warum Menschen nachhaltige
Produkte oder Dienstleistungen in Anspruch nehmen. Das stärkste Motiv ist hierbei der
Preis. Bei den Produkten haben also die herstellenden Firmen den meisten Einfluss auf
den Grad der Nachhaltigkeit und den Preis. Mit Jinengo soll aber eine Art Dienstleistung kostenlos vermarktet werden. Hier ist ganz klar bei der Qualität der Dienstleistung
ein hohes Maß an Steuerbarkeit gegeben. Wenn die Anwendung einem Benutzer zeigen
kann, dass man sich mit einem nachhaltigeren Verkehrsmittel evtl. sogar schneller und
dabei noch nachhaltiger bewegen kann, dann wird dieser stark dazu angeregt, sein Verkehrsmittel zu wechseln.
Neben den genannten Qualitäten wurde am Beispiel Amazon gezeigt, dass personalisierte Empfehlungen ebenfalls einen Kunden beeinflussen und steuern können. Hier sollte
453
Abb. B.36.: (Quelle: [157])
Abb. B.37.: (Quelle: [157])
Jinengo aber nicht unbedingt dazu beitragen das der Kunde mehr reist, sondern anders
und nachhaltiger reist. Der zukünftige Fokus bei der Entwicklung der Anwendung sollte
also klar auf den immateriellen Mehrwerten liegen.
Die Verbindung von Nachhaltigkeit und Konsum hat viele Betrachtungsweisen. Hier
sollte primär beachtet werden, dass Menschen nicht primär Ressourcen verbrauchen,
sondern Wünsche und Bedürfnisse befriedigen wollen. Die Mittel und der Grad der
Bedürfnisbefriedigung sind jedoch von Mensch zu Mensch unterschiedlich. Eine Leitlinie
soll hier der Fähigkeitenansatz von Martha Nussbaum bieten. Die Steuerung des Konsums in eine nachhaltige Richtung hat viele Ansatzpunkte. Neben den Produkten der
Anbieter und den Dienstleistungen von Firmen kann auch von Seiten der Politik und
der Werbung stark Einfluss genommen werden.
Zukünftig könnte eine Auswertung der Nutzerdaten sehr interessant sein, da es aktuell
keine vergleichbare Software gibt, welche nachhaltige Reiseempfehlungen ausspricht. Abschließen möchte ich diese Ausarbeitung mit einer Karikatur zum Thema Nachhaltigkeit.
454
Making It Personal: How to Profit from
Personalization without Invading Privacy
[email protected]
Zusammenfassung: The elaboration about the proper usage of personalization introduces the reader to the context of the topic, investigates
which objects can be personalized, describes the psychology of personalization, presents legal aspects that have to be focused when personalization becomes practice, shows the implementaion of personalization
and focalises risks and chances of personalization. Last but not least a
conclusion will round off the seminar work.
Schlüsselwörter: personalization, customer loyalty, customer needs,
profiling, privacy, privacy borders, laws
Introduction
When talking about personalization, first of all there must be a common understanding
for this term. It appears increasingly everywhere and has a lot of meanings whereas in the
following we will consider it in context of electronic commerce [158]. In a strict sense it
would be more correct to say individualization because this means customizing an object
to the needs of an individual. Personalization - more precise - stands for the adaptation
of information, products, offers, performances or pieces of a website to the needs of one
identified person. Individualization of performances is also called mass customization.
It targets to provide relevant and interesting information, products and offers to each
customer on basis of gathered, analyzed and aggregated customer-oriented information.
By this, computer-transmitted communication becomes humanized. However, incentives
are necessary to get the relevant information from the customer. Based on historical
data, the provider has the possibility to create customer profiles and to use them for
individualized sales approach and differentiated services.
Personalization can be captured as treating different people differently by using information about them [159]. This means not to look at a group or segment with common
interests but to address each person as an individual and thus offering unique, unimitable performances which are difficult to compare. It aims at building long-term customer
relationship where the company as well as the customer benefit from each other - a
455
learning relationship process. This is being enabled by modern information technology
especially the Internet.
Todays companies often misunderstand or even abuse personalization: Instead of focussing on win/win situations that benefit both, the company and the customer, personalization is used as a method for gaining more profit, which is known as cross- and
up-selling in marketing. They even obtain added economic value by the usage of a technology but not by the technology itself. The central question that should be kept in mind
is: How can personalization be used to add value for different kinds of customers? How
can it improve their lives by making things easier and/or less expensive and/or more
convenient?
A major challenge is to find the right balance of personalization. If it is done too fast or
too intensively many people will be frightened because they perceive it as an inadequate
attack to their privacy. Otherwise if it is done too slowly, it’s less efficient and the risk
to loose the best individuals to more aggressive competitors will grow. A conflict which
will be discussed in detail in the chapter ’Risks and Chances’.
What can be personalized?
For an overview which objects can be personalized, the performance system of personalization will be explained as well as personalization options in online marketing [158].
The performance system of personalization which is derived from Belz performance system, contains the three major layers:
product and performance
website
communication
These layers are based on different sublayers that build on one another for classifying
performances. At this the core performance or core product is the centerpiece surrounded
by additional performances up to management and communication performances. Layer
one and two represent personalization of products and services, layer three stands for
interaction with the customer.
456
Abb. B.38.: Personalization Performance System [158]
457
The first layer ’personalization of products and performances’ demonstrates mass customization as individual production of products and services for a great market whereas
the needs of each individual customer are met to costs of mass production of a standard
product. It can be distinguished between soft and hard customization. Soft customization describes service individualization or customization by the customer himself. The
producer doesn’t change anything concerning the production of the product. In contrast, hard customization affects the physical product. The customer is involved in the
production process and has influence on it. In this case it has to be distinguished between modularization and mass production of individual items. In case of modularization
the customer builds his product from a limited number of standardized and compatible
pieces. Mass production of individual items, on the other hand, takes place when the
customer-specific production passes the entire value chain.
The second layer ’website’ clarifies personalization of website content, website navigation and website layout. The customer can decide which information should be displayed
considering its relevance to him. Navigation personalization just serves a better usability. Through website layout adaptation the content and information can be prepared
user-specific to meet the customer needs.
The third layer ’communication’ states the possibility to personalize the communication channel, e.g. E-Mail, Website, etc. and to adapt the communication content in order
to meet the needs of the customer. Moreover the customers should be free to determine
further parameters for communication to control the intensity of interaction or consulting that fits their personal needs best. The personal sales approach can be divided into
different graduations: Either the provider takes all known information about the customer to address him actively or in case of response, he communicates pseudo-personal
in an automatically generated email. The degree of the personal approach is situational
and should be selectable by the customer.
Personalization options in online marketing have to be understood as additional perspective to the performance system discussed above. These options can be seen in the
figure below:
The earlier mentioned measures of individualization of products, services and offers have now to be assigned to product and price policy. Website personalization has to be
split into the area of product policy and the field of process because the website content
belongs to the product and price policy of a provider and the design of navigation and
layout defines the interaction process. And of course personalization of communication
belongs to communication policy, above seen as Promotion. Distribution policy (Placement) owns fewest personalization potential of all which adapts logistics options to the
customer needs.
458
Abb. B.39.: Personalization in online marketing [158]
An example for relevant customization within the projectgroup are personalized offers
that select and bundle mobility services which can be compared to a provider of mobile
communications who gives the customer a proposal for his right mobile agreement and
mobile device. In addition to that, personalization potential lies in suggesting most
sustainable locomotion to each customer based on an emission calculator and history
data of other users. Another option is value-based pricing which means customers get
different adapted prices based on various user and consumption behaviour. The more
frequently and sustainable a customer moves the more discount he gets. The option
of filtering a mobility service request to the needs of a customer represents the above
mentioned website layer personalization concept. For example the user interface could
include slide controls with which the customer gets full control over the mobility results
fitting to his notions.
Psychology of personalization
People have different needs that they pursue. If they reached what they have pursued
they start thinking about higher level needs. The psychologist Abraham Maslow designed
for this phenomenon a model which contains eight levels of needs, The Personalization
Ladder [159]. Also it enables classifying the needs of people it only indicates the scope
459
Abb. B.40.: The Personalization Ladder [159]
where a company can meet the individuals needs or the level at which an individual might
be valuable. However this framework is essential because personalization is no end in itself
and only successful if personalization potentials and customer needs are coordinated.
The special feature of this model is that it outlines common behavioral tendencies while
there are differences in the people needs. It offers a comparison of the needs of an
individual to the capabilities of a company to satisfy this individual. Relationships are
most personal when the higher level needs are reached. Normally companies should limit
their personalization efforts to the needs they are at or lower to the level they already
satisfy. This means for companies always to move the rungs downwards, not upwards,
otherwise it might be dangerous because moving upwards requires a company to change
virtually everything about the way its people, processes, and technologies work.
460
An example for the usage of this ladder would be taking a look at an upscale retailer [159].
The upscale retailer provides the customers more than just basic necessities but supports
people to look and feel great which in turn evokes approval and recognition. So in this
case the retailer would meet the level of ’Approval and recognition’. One could also argue
that the retailer meets the runge of ’Order, beauty, symmetry’ but it would be difficult
to denote that the upscale retailer helps the people to explore and understand. On this
account the retailer should be allocated at the lower level and not the higher level. The
retailer would definitely fail above the determined runge because he has never before
supported such a service like being a provider of customized stock market research and
collecting or managing personal information. Moreover it would be possible to get more
personalization by introducing any services that save the customers time and that fit
the basic necessities of life.
Legal aspects
Before personalization is realized with the right balance, the legal area, the legal framework and common basic principles of data protection law should be viewed to prevent
violating valid laws and to create confidence as well as loyality and transparence for the
customers. Regarding the website which represents the projectgroup and their performances, the Bundesdatenschutzgesetz (BDSG) and the Telemediengesetz (TMG) have
to be focussed. Besides the provider identification, called imprint, the provider has to
publish a privacy policy to make clear if user data is being collected and if so, what
happens to these data. A disclaimer is useful for the provider’s own safety to exclude
liability for third parties. The legal area for the productive system is initially bound
to Germany wherefore the Bundesdatenschutzgesetz is effective exactly in this place.
The requisite paragraphs are compatible to the international recommendations which
are therefore anchored in the European legislation [160]:
1. Earmarking
The collected data have only to be handled for the determined purpose or the
obvious circumstances.
2. Lawful procurement
There is a justification for the collection of data, if made, for example, in direct
connection with the conclusion of a contract. Data warehousing and data mining
approaches can not currently rely on justifications. The reason is that neither the
data nor the results have a direct need for a business transaction with an interested
user. The remedy in this case, the approval of the customer.
3. Approval
A change of purpose in the data processing is possible with the consent of the
461
individual. By consent, which may, for example located in the terms and conditions,
data warehousing and data mining is legally secure. However it is unclear whether a
consent enables uncertain use of customer data. It should be assumed that a power
of attorney over the use of their own data will only be valid if the data processing
for the recipient at the time of consent has a minimum level of transparency. The
more sensitive the data processed, the farther away from the original processing
purposes they are and the more the range is extended to handle that data, the
higher the requirements to be placed on such a consent in respect to transparency.
4. Transparency
The principle of transparency describes the scope of the duty of disclosure in data
warehousing and data mining concepts, which however can not be explained encompassing. Any declaration to consent to the processing of personal data must be
sufficiently transparent to allow the customer to assess risks directly. A withdrawal
of consent is the right of the customer.
5. Quality
In context of data warehousing and data mining the highest quality of data is
necessary. This is a great challenge because there are many heterogeneous data
sources and a continuous control of correctness of data due to lack of transparency
can not be guaranteed.
These first principles get encouraged by the Global Security Intelligence with its EU
Privacy Directive 95/46/EC [161] as well as by Bruce Kasanoff, an expert on personalization, who extended the universally accepted Fair Information Practices (FIP) [159].
You will find them here:
Collection Limitation
This principle says that there should be limitations to the collection of personal
data and when getting these data this has to take place lawfull and by fair means
and where appropriate with the knowledge or consent of the customer.
Data Quality
This principle says that personal data should be relevant to the purposes for which
they are used to be and have to be accurate, complete, and kept to be up-to-date.
Purpose Specification
This principle says that before data is being collected there have to be specified
the purposes and the fulfillment of those purposes.
Use Limitation
This principle says that personal data should not be disclosed, made available or
used for purposes that have not been specified, except with the consent of the
462
customer or by the authority of law.
Security Safeguards
This principle says that personal data should be reasonable protected, for example
against unauthorized access, destruction, modification or disclosure of data.
Openness
This principle says that there has to be a general policy of openess about developments, practices and policies with respect to personal data. The customer should
be able to read about the usage of personal data and get to know where it is stored
and which trails it takes.
Individual Participation
This principle says among other things that a customer:
- has the right to request a confirmation whether personal data of him is stored or
not
- to challenge data relating to him and if records exist, to have the data erased,
rectified, completed or amended
Accountablility
This principle says that a data controller should be accountable for complying with
measures that give effect to the already stated principles
All in all personalization leads to profit when companies strictly care for the customer’s
individual privacy and don’t undermine his interests, don’t exploit his interests and don’t
betray his secrets. Privacy borders are where law or even better the individual defines
them. The customer needs to have full control about his privacy and the possibility
granted to have influence on it. A good example is Diaspora which can be visited at
http://joindiaspora.com. Diaspora aims at being a decentralized alternative to social
network services like Facebook. [162] Users can set up there own servers that are named
“pods”. These pods can share status updates, photographs and other social data. The
software is being written on Ruby on Rails and will be free for everyone to test and
experiment. The official website itself advertises with three major concerns belonging
to privacy and personalization on the home page: user’s own decision, user’s absolute
ownership and simplicity. The principles affirm that user content will only be shared
to people that have the permission. Everything which is shared on Diaspora resides as
property to the owner with full control about the distribution. And Diaspora makes
sharing clear and simple just as the safeguard for the user’s privacy. It is private itself
and doesn’t need any configuration for pages to avouch safety for each profile.
463
Implementation of personalization
Personalization works on two different types [158]:
On the one hand the customer can take influence on objects and individualize them
himself with his own configuration based on predefined parameters. On the other hand
he isn’t aware of personalization processes in the background that compare his needs
to available products or knowledge about other customers (matching with customer
profiles). The first type is called explicit, the second one implicit personalization.
Explicit personalization
Explicit personalization takes place when configuration is done by the customer himself.
Mass customization is a good example at this point: Regarding Apple Store with its
online configurator, the customer can select from predefined parameters and thus is able
to order a completely personalized computer with individual storage, individual random
access memory and a lot of accessories while meeting the costs of mass production of a
standard product.
Implicit personalization
Implicit personalization doesn’t require the customer himself to adapt the personalization objects to his needs. A software system assumes this for him based on user profiles.
This kind of personalization distinguishes between the data mining and the matching
process to generate profiles for later usage. The matching process can either be rulebased matching where personalization objects get classified with the help of rules or
collaborative filtering which compares an action, e.g. product selection, with data and
knowledge about other customers.
Data mining
The knowledge about the customer can be obtained in many different ways. In the following list already existing possibilities are shown:
Clickstream-Analysis: Analyse the behavior of a customer on the webinterface
Market basket analysis: Analyse already done purchases
Data mining technologies: Gain patterns and regularities from existing amounts of
data
Customer touch points: Data about the customer can be collected at all contact
points, e.g. call center, e-mail, whereas it is important to transfer the data into a
corporation-wide valid profile
464
Offer the customer the possibility to express his wishes and preferences explicit or
to enhance his profile with his preferences based on direct statements
Concerning customer touch points, the idea behind it is to get a standardized sales
approach based on identical data. The continuous collection of profile data across all
transactional phases, in sense of a learning relationship, can apply to a targeted, crosschannel address of the customer. In doing so the customer profile becomes subtilized so
that the quality of the data within the customer life-cycle can be improved with each
transaction. The last point from the list contains the problem that no customer would
ever give his personal information if there are no incentives or benefits given to him.
Moreover the purpose of the usage of the data and the reliability of the provider are
important aspects associated with it.
Rule-based matching
Rule-based matching, also known as content-based matching, describes content connections based on rules. Such rules enable identifying products or services meeting the
preferences and attributes of a customer. They are formulated as if-then-rules. An example would be: If the customer likes products of category A and usually buys products
valued higher than X units of money then also offer products of category Z. These rules
can frequently be observed at Amazon.com where each visitor gets individual suggestions for products that might be fitting to him. The profile is built by Amazon by the
requests of the recent visit whereas the suggested product is interconnected to the recent
requested product over a content based rule. Please have a look at the figure below to
get to know how the regular procedure of rule-based matching goes:
Collaborative filtering
In contrast to rule-based matching, collaborative filtering does matching resting upon
profile data of other customers. Here the visitor gets product suggestions that have a
conjunction to a profile of another customer who has done the same action before, e.g.
product selection. But there are a lot of other actions with which collaborative filtering
is possible, like invoking web pages, reading articles or rating products. Again, best
example for collaborative filtering based on product selection is Amazon.com where it
says: Customers who bought this, also bought that. Collaborative filtering becomes really
effective concerning products which are bought based on preferences like attitudes and
tastes. Otherwise, if products are only bought from the convenience point of view and
interconnections between particular products are not based on tastes then it might be
that the calculated results become nonsense. The following figure shows the procedure
of collaborative filtering:
465
Abb. B.41.: Rule-Based Matching [158]
Abb. B.42.: Collaborative Filtering [158]
466
Risks and chances
Personalization is subject to certain risks resulting from a high degree of complexity.
These risks are the natural result of mixing technology and business because of personalization. [159] Effective personalization depends on simplicity which can be achieved by
modularity. Read more in the next paragraph. As a follow-up chances of personalization
will explained, too.
Complexity can be managed by modularity that makes personalization possible. Modularity describes therefore separate but interconnected pieces of a system. The more
modules the better unique solutions and services are provided. The paradox:
The more modules the more flexibility but the more modules the more complexity
[159]. Special characteristics of complexity that can lead to unintended consequences
are its tendency to fail, its unpredictable or unintended behavior, its less secureness, its
difficulty for users to understand and trust, its difficulty to be maintained and supported,
its expensiveness and its unlikeness to produce the promised return on investment.
Besides the complexity from the general point of view, the next points shall explicitly
outline why individuals incline to negate personalization:
1. Prefered Anonymity
People do not want to be identified for many reasons. People do not want to be
X-rayed by marketing experts and to be bombarded with offers they haven’t asked
for.
2. Lack of Relevance
People do not want to stay in contact with companies which have no relevance to
them.
3. Untrustworthy
People do not want to deal with companies that have no good intentions.
4. Lack of Security
People will not share anything of value with companies if these companies fail to
protect its assets, and those of its stakeholders.
5. Impossible
People are not capable of doing all the tasks a company expects them to do. For
467
example, when a company optimizes a standardised product which works in a so
far unknown way, consumers do not know how to use it.
6. Infrequent Contact
People do not want to establish relationships with companies with which they have
one or just a few transactions.
7. Little Value Placed on Potential
Today, most personalization is still superficial and targeted towards mainly personalized marketing.
Opportunities that arise with personalization including the resulting advantages and
benefits for individuals are the next step that will be discussed [159]:
When recurrently cyclic tasks are eliminated, transactional data is remembered and due
to recognizing habits the path is shortend to engage in such habits, the customer can be
saved time.
At Amazon.com it can be seen as One-Click ordering.
If redundant work is prevented, service components are eliminated that are unnecessary
to a person and lower-cost solutions are identified that meet all other specifications, then
money can be saved.
At Amazon.com it can be seen as up to 40 percent off.
When training is provided, information is filtered that is unimportant to the customers
interests, the reliability of information is increased and especially normal information is
replaced with specific information for that customers environment, better information
is given.
At Amazon.com it can be seen as remembering the customers preferences.
If ongoing needs, challenges, or opportunities are addressed then customers can occupy
one-stop services.
At Amazon.com it can be seen as many other services besides the regular book sales,
e.g. music offers.
By means of personalization unique and unimitable performances can be implemented
which are difficult to compare. [158] It provides an optimized alignment on the needs
of the customers and for this reason their satisfaction and an increment of customer
loyalty as well as raising trust. Moreover computer-transmitted communication becomes
468
humanized and operates against the unpersonality of the medium Internet.
Conclusion
The seminar elaboration described personalization as a complex theme, due to many
risks and chances. In general, as part of electronic commerce, personalization means customizing an object to the needs of an individual. Customized objects can be products
and services, websites or even communication itself. Personalization can be implemented in two ways: The first is explicit personalization where the customer himself defines
parameters. The second is implicit personalization where data about the customer is
collected by rule-based matching or collaborative filtering. From the economical point of
view personalization is great for mass customization. Individualized offers can be provided at costs of mass production of a standard product. When personalization takes
place it is highly recommended to serve with experienced capabilities to meet the customers needs successfully. Personalization is done properly when legal aspects, e.g. EU
Privacy Directive 95/46/EC, are minded and the customer is seen as uppermost estate.
He defines privacy borders and has the right to get full control about his privacy.
469
Encapsulating services in agents
Daniel Stamer
[email protected]
Zusammenfassung: This seminar gives an overview of modern agents,
especially agent components, and explains the advantages and disadvantages of using these technologies. General possibilities of designing agents
and also multi-agent system are shown. The main topics on the use of
agents, such as communications and interactions are being explained. Finally, this document provides an overview on pratical implementations
of agents and agent components.
Schlüsselwörter: agents, agent components, FIPA, multi-agent systems, agent communication language, BDI, services
Introduction
Today services can be provided in many forms. In the area of computer science a
service is an interface with an underlying functionality. A user might access a service via
it’s interface an request the underlying functions to do a specific job for him.
Very popular ways of providing a service are through web services, which are commonly
based on implementation models and protocols such as REST or SOAP, through other
network-based calls, as with the RPC protocol, or directly on a single physical machine.
The history of research on intelligent software agents dates back to the early 1990s.
The research began on the question about how to organize a set of distributed bots to
efficiently work together in groups [163]. It really became popular around 1994/95 when
the term ’agent’ spread through literature in computer science world wide. At that point
in time the concept of using agents instead of traditional software components created a
hype. This hysteria about agents did only last for about five years until the acceptance
of the technology droped back again [164].
Today we can see yet another change in the interest for agent-based software and agentbased software engineering. The hype has settled and people started to really consider
using agents; but in a different, more powerful way. When combining agents with services,
which have been traditionally provided by software constructs known as components, a
new very powerful and reusable construct is being created. This construct is able to
combine the advantages of agents and the functionality of multiple services.
470
This document will show a way to encapsulate services in agents. To do so, we must
first clarify some definitions on what an actual agent is. The definition of an agent will
include the distinction between agents themselves, components and agent components.
Further analysis will contain models on how these partially different entities can communicate and cooperate with each other to fulfil a (common) task. The introduction
of specialized multi-agent systems has the purpose to show ways of dealing with these
heterogenous intelligent pieces of software.
In addition to multi-agent systems the Foundation for Intelligent Physical Agents (FIPA)
will be introduced. A few specifications on the use of agents are important for understanding agents and might show how a future standardization of the agent technology
might look like. These specifications are mentioned along with the organization itself.
The following section will cope with the basics of agent’s interoperability itself. The
language in which standardized agents communicate with each other and surrounding
software modules is explained. This section will provide a deeper look at how the language works, what grammatics it contains and how a typical conversation between two
or more agents is like.
The theoretical part ends with a transition into the more practical fields around agents.
When it comes to the process of designing agents, we can observate, that it slighty differs
from the designing of other software units. This section aims to provide information on
design models for agents.
The end will include an overview on concrete technical shapes of the agent technology. It
will contain a set of development frameworks to support the building process of agents,
a list of agent-oriented programming languages specifically created to build agent-based
software and a more detailed insight of one of the most powerful frameworks in agentoriented software engineering.
What is an agent?
The following section should give a clear overview of what is meant when using the
term ’agent’.
First of all, one has to distinguish between agents and components. After a clear distinction between those two concepts has been found, we can specify the link between the two
units. An agent component unifies the advantages of both models into one composition.
Components
Component-based software engineering utilizes a concept of components to design
and implement software. When compared to agents, one is safe to say, that the idea
of the component is the more traditional one. It is a matured model, which relies on
a specific system to work with. Hence it is not system-independent. A component is a
471
logical unit of software within a larger system. It focuses on providing certain services,
which are a part of the larger system’s functionality. All components combined will make
up the whole system, assuming that it is entirely component-based. These Systems are
design with a centralized form of organization, so that the whole set of components will
need a core structure in addition. This core’s purpose is to control the behaviour of all
subcomponents and to redirect calls to their interfaces.
A component traditionally runs on some form of logical or physical application server.
It’s execution is very similar to other software units or small programs.
Components perceive their environment through events and event-handling. This
means that all changes that occur to the environment or the component itself are seen
as the occurence of a specific event. A change of the outside world triggers a specific
trigger within the component’s perception.
The standard forms of communication among components and/or the core system
are direct method calls from the code itself. Traditional components provided a set of
interfaces to the rest of a system, which allowed other components to inform themselves
about provided services and ways to request them. Each service method of a component
is described in such an interface. Further, very detailed information about parameters
and return types are also given.
Components are designed in a traditional way. Requirements of the software are being
evaluated and the system, which should be implemented, is decomposed into smaller
subsystems. This decomposition will eventually reach a very detailed level. At this level
a single service can be isolated. The component will now include this single service and
will concentrate on providing it in the least acceptable or best possible way.
Agents
To define what an agent actually is, it is preferable to start with an existing definition
of the term itself. Since the early 1990s scientists have come up with lots of different
definitions of what an agent is. Most of these definitions only differ in counting attributes
of agents; some list more and some find it useful to leave a few to the reader. This
definition of an autonomous agent leaves up space for personal interpretations.
“An autonomous software agent is a component that interacts with it’s environment
and with other agents [...]” [165]
472
Agent-based software engineering shares common concepts with component-based
software engineering. It also uses lots of small units to fulfil a higher task. Yet there
are a lots of very important differences between agents and components.
The main difference between agents and components is that agents are (mostly) intelligent. Agents are autonomous entities that can take care of themselves. Agents have
their own beliefs and desires and act on their own behalf.
The main focus of an agent is not on providing a specific service to it’s user. Instead it is
on the communication with other agents an the core system. An agent communicates on
the base of standardized languages and conversation protocols. A lot of tasks a group of
agents have to solve depend on their ability to communicate efficiently. Swarm algorithms
use a raw mass of agents in the swarm to solve a specific problem. As a conclusion of
this you can say that agents are able to operate in a very flexible way.
When compared to components, agents are considered to be the next generation model
to design and implement complex software systems that rely on many smaller units.
Agents do not directly run on an application server. A special environment, which is
called a FIPA-platform, is needed for an agent to live. This requirement results in initial
development overhead, but it will repay by providing reusable, highly flexible software
units.
An agent’s perception of it’s environment and itself is handled by it’s own belief. The
agent contains an internal conscience of the outside world. It will constantly update and
evaluate this belief, because it is and will be the basis for it’s actions.
Mobile agents
A certain subset of the whole group of agents are made up by mobile agents. Software
agents can be implemented in a way, which keeps them transferable from one system
to another. A traditional component is usually deeply integrated with it’s sibling components. The loosely-coupled architecture, in which agents live, can be torn apart, so
one agent is able to move to another system. This is possible since an agent is defined
as a concrete entity, which has clear borders between itself and the surrounding system.
Therefore an agent can be isolated and than transfered over a network or run in a different logical runtime environment on the same physical machine.
The agent may do this in a variety of forms. He may be compiled, and probably running,
into a blob. Such an assembly could be a .JAR - file (Java) or an .DLL - dynamically
473
Abb. B.43.: Basic structure of an agent component [164]
linked library (.NET/COM). He may also be in clear source code, which has not yet
been compiled. The target runtime must than provide a service to built the agent before
it is about to be run.
Transfering an agent in such a manner is a huge security risk for the target environment.
It is therefore highly recommended to cross-check the signatures of incoming agents. An
agent should remain in quarantine before he or his source is declared to be trustworthy.
Agent components
A recent step in agent and component technology’s research is to unite the two concepts. The idea behind this is very simple. An agent is linked to a specific component
so the agent can provide communications for the component and the component can
provide the agent with useful services. This fusion can be seen as a form of symbiosis,
since both parties benefit from it.
At this point the service is encapsulated by an agent.
Such an encapsulated service is called an agent component. An AC is an isolated entity of it’s own that combines all non-funtional advantages of an agent, such as mobility,
flexibility, reliability, security, privacy, customizability and composability, with the functional aspects of the component’s services.
It is of vital importance to understand the difference between an agent and a service in
order to understand the innovative concept of agent components. The purpose of figure
B.43 is to state the basic idea and model of such an agent component.
This newly generated complementary concept is attached to several new design methods. Applications can be quickly assembled by choosing from a variety of agent components, which fit the current application domain. Therefore the process of generating
software has increased in speed.
Additionally, the adaption of the agent-based behaviour ensures a certain level of interoperability among the used AC software units and the surrounding system modules.
Integration of existing services can be done very easily as soon as the existing components are encapsulated by agents.
Last but not least it is to mention, that developers, who are unfamiliar with agents, but
474
do know which services they want to use, may still select them from the pool of available
ACs. Since the use of the services have not necessarily changed, the agent component
will still be able to fulfil the desired tasks in the application, which should be developed.
What is a multi-agent system?
The purpose of this section is to clarify the definition of a multi-agent system (MAS).
A multi-agent system is a system that solves a certain problem from a specific application
domain by using multiple agents.
The idea behind swarms is based on exploiting the natural analogy with ants or bees.
This analogy is especially obvious when comparing a multi-agent system, which includes
lots of mobile agents, to a bee hive or an ant colony.
This concept can be used to design swarm algorithms. These algorithms, which rely on
a huge quantity of homogenous agents, are utilzed to solve lots of problems like finding
the best sources for flowers, which are rich of nectar.
Another way of seeing this analogy is the comparison to a gravitational pull on a liquid
element. Water will always find the spot, which has the lowest altitude, when poured on
a plain surface. This behaviour of nature has proven reliable for a long time in human
history. Systems like air levers could be seen as MAS, when water drops are seen as
agents.
Regarding the fact, that water drops are not really communicating with each other, it
might not me a very good example. A dancing bee or an ant, that lays out a chemical
trail, would serve this purpose much better.
All agent components within the MAS are loosely-coupled entities. That means the
ACs are communicating with each other using a specific language other than calling each
other’s methods by direct system calls.
“The key is to treat an agent as a collection of reactive behaviours, not just a
collection of methods.” [165]
Most MAS additionally have the ability to genetically alter the agents within their
system. This is a crucial requirement to adapt to new environments.
A huge variety of different multi-agent systems has been developed in software engineering. It’s now important to understand the concepts of MAS, which have been especially
475
Abb. B.44.: Multi-agent system for agent components [166]
design for agents.
MAS in an agent component-oriented environment
A MAS, which is exclusively matched on agent components, needs to cope with different units when compared to usual multi-agent system.
Figure ?? shows a suggestion for the structure of such a MAS.
The core of the architecture is made up by an entity named virtual agent. It is virtual
because it looks like an agent to the others, but it lacks certain properties an agent has.
The core agent can not move or leave the system since itself is the heart of it. It is also
very unlikely that the core agent can be considered reusable in any way.
The inner (dashed) circle’s hull is formed by a barrier of agents. These are pure agents
and their task is to built up an interface to the core in case they have to connect to
a component, which has not yet been encapsulated by an agent. Their purpose is to
ensure, that the given level of communications is being held.
All business logic, which would usually be divided as services among the components,
is now spread across components and agent components. The actual service or logic is
executed here exclusively.
476
The advantage of such an architecture is that the development process can be increased
in speed. Once the core system is set up, further agent components and even traditional
components can be connected to the system. The development process will mainly select
ACs and insert them into the system.
The FIPA
The Foundation for Intelligent Physical Agents (FIPA) is an independent organization
that aims to improve standardized specifications on agents. It was founded in 1996
and has different international members, which are mostly institutes or companies. The
German university RWTH Aachen is also a member of the foundation.
The adjective ’physical’ is an inappropriate part of the FIPA’s name since it deals with
software agents only. Robotics are not included.
The FIPA is a part of the Institute of Electrical and Electronics Engineers (IEEE) since
2005.
Specifications
This section points out important specifications approved by the FIPA. These specifications include definitions on languages agents should use to communicate with each
other and models on how the object structure of an agent should look like.
Only a few of the 25 approved standards of the FIPA will be explained.
Language
The most popular languages for agents to communicate with each other are the Knowledge Query and Manipulation Language and the FIPA-ACL (FIPA’s Agent Communication Language). The last one is officially proposed by the FIPA. The language is
specified in the “FIPA ACL Message Structure Specification” [167]. This general specification is also available in more specific shapes. It is separately released to work as
string, xml-strings and more bit-efficient notations.
The documents contains very detailed information on how to construct an ACL message.
In order for two agents to understand each other it is important that both of the
agents do not only speak the same language, which mostly is FIPA-ACL, they also have
to share a common ontology, which should contain all the semantic information that is
needed. That is why the FIPA has a second specification on the ontology, which should
477
be used by the agents to communicate. The name of this specification is “FIPA Ontology
Service Specification” [168].
Agent Communication Language
The following part aims to give further insight into the way how agents communicate
with each other.
As mentioned before, the FIPA has developed a standardized specification for an Agent
Communication Language: The FIPA-ACL. It is mostly based on the KQML language,
but it adds a few new structures, which were missing to complete the language. The
second huge difference to KQML is, that ACL uses the language SL to express the
agents beliefs, desires and intentions. The SL language has specialized itself for making
such expressions [169]. It has a FIPA specification itdelf.
Structure
This section is meant to explain the structure of the FIPA Agent Communication
Language Message Structure as shown in Figure B.45.
It will only provide a mere overview on the structure. In order to get further insight on
the topic, one should read the specification itself [167].
A FIPA ACL message consists of four major divisions. The first and the last are the
header and the end of a message. These are used to envelope the message itself.
The header contains mostly meta information on the message. It contains a Message ID,
which is used to identify the message and provides the message with a stamp, which is
unique in the environment of the message. Further information on the specific language
version, which is used, is also given.
The end of the message’s only purpose is to signal just as it’s name suggests. The content
of the message is divided into the type and additional parameters.
The type can either be a predefined type or a user defined type. However the type
expresses the category of the communicative act. These can be “propose”, “request”,
“inform” or a whole lot more. The set of predefined types contains 22 elements [170].
A developer can also decide to create a type on his own. He must then be sure that all
agents understand that type of message.
The parameters of the message are dependent on the given type, but certain parameters can be applied to nearly all types of messages. A very common parameter is the
information on the “conversation participants”, the “semantics” of the message or the
478
Abb. B.45.: [170]
“control” attribute, which shows the flow of the communication process. Notice that
message parameters can also be user defined as well.
Designing agents and MAS
The following section aims to provide the reader with basic models and patterns on
how to design intelligent software agents. The complexity of such a design task is in the
design of larger systems (MAS), which contain multiple agents in different forms and
numbers.
Designing agents: Beliefs, Desires and Intentions
The BDI model is a very common concept of designing software agents. Its starts by
describing the agents in three different attributes of his future character. The software
designer defines sets of beliefs, desires and intentions that will have influence on the
agents behaviour. A huge advantage, which BDI agents benefit from, is that the agents
are able to divide the time spent on choosing a plan and actually executing a plan.
The concept of BDI is based on Michael Bratman’s theory of human practical reasoning
[171].
Beliefs
The beliefs of an agent are his representation of it’s environment and itself. It is called
belief, because it doesn’t have to match the truth or the reality. In order to develop
certain intentions, an agent has to know how the outside world looks like at the moment
of forming that intention.
479
Abb. B.46.: The cyclic behavior of the BDI-model.
The entity, which expressed the beliefs of an agent, is called beliefset. It is contained
within the agent and lists all the beliefs an agent currently has.
Adding a belief to the beliefset is comparable with triggering an event in traditional
software development.
Desires
The motivational state of an agent is expressed through his desires. It is what an agent
’wants’ to do in a certain situation. Again the perception of a certain situation is entirely
based on the agent’s beliefs at that moment. These desires can be compared to human
desires. An agent might find it desirably to find the best price for a book, calculate the
shortest route to venice or find the next party in paris.
The agent’s entities to represent it’s desires are goals. After the agent’s beliefs about his
anvironment have changed, he might develop new goals, which he likes to achieve. These
entities do not yet deal with ways to accomplish such a goal.
Intentions
Intentions are an individual agent’s deliberative state. Unlike beliefs and desires, this
is not a mental attribute, but a conduct-controlling pro-attitude. At this point the agent
has committed itself to one of it’s goals. It will now attempt to achieve this goal by
selecting a plan, which will serve this purpose the best possible way.
Obviously the intention’s entity is a plan. A plan contains ways to achieve a certain goal
and it’s effectiveness is based on the initial situation. The beliefs of an agent will then
again be altered, since the execution of a plan will eventually change the environment
of an agent.
This behaviour leads to a simple but distinct conclusion. All components in the BDI
model are linked and depend on each other. Figure
480
Abb. B.47.: Overview of the Gaia methodology [172]
Designing MAS: Gaia
The principle of designing huge systems with software agents is mostly based on one
method. Through sequential decomposition of larger systems into smaller and even smaller agent components.
One of the most widely-accepted models is Gaia. Gaia’s analysis process follows a topdown idea as in Figure B.47.
At first, requirements are evaluated and divided into different organizational structures. At this point the software designer can choose, whether certain subsystems are
important enough to form autonomous MAS entities on their own.
Subsystems, which are ready to be further decomposed, are now being included in the
process of designing a roles and an interactions model.
The roles model contains all roles that should be given in the system. These roles can
be compared to offices in real life. A role could be something like “prime minister”,
“secretary of state for defenses” or “HR manager”. The definitions of a role consists of
it’s permissions and it’s responsibilities [172].
The interactions model is the result of the design of realtionships between the different roles. It contains cross links within the different roles concerning communication,
dependencies and other interconnections.
481
The last step is called ’design’. The roles and interactions models are now translated
into agents, services and acquiantance models.
The agent model aims to provide the modelling for all the different agent types, that
will occur in the system. An agent type is best thought of as a number of agent roles.
The model contains the non-functional requirements of the specified roles model.
The services model is the counter part to the agent model. It includes the functional
requirements associated with each role in the system.
At last the acquiantance model defines the connections between agents and services.
It’s ultimate source is the interactions model. It is used to create the link between the
different components in the system.
Practical implementations
This part is a rather practical-oriented one. It should give a brief overview on concrete
implementations and technologies associated with the idea of software agents. At first it
will present a set of the most important frameworks for developing agents. After that,
the focus shifts on actual programming languages, that have been exclusively developed
to fit the need of agent-oriented software engineering. The last subsection will provide
further insight on one of the most important development frameworks.
Overview on agent frameworks
Since the rise of the agent technology many frameworks to simplify agent development
have been created. The focus of these frameworks is on object-oriented programming
environments. The idea is that a type of agent is defined as a class and a concrete
instantiation of an agent is an object. The containment of an object is the perfect capsule
in which an agent can live as an autonomous entity.
This subsection is meant to provide a short overview on agent frameworks.
Zeus
Jade
ADF
The Agent Development Framework (ADF) and Java Agent Development Framework
(Jade) are comparable to each other. Both are frameworks used to built agents and
both are runtimes (so called FIPA-platforms) to run agents in a hosted environment.
Both ADF and Jade are developed as open-source software. However, this fact does not
include that both applications are entirely free.
482
The Zeus toolkit is a set of applications used to design MAS in an organized way. It
provides tools to construct agents that are supposed to work with other agents.
Overview on agent programming languages
To further support agent development not only frameworks exist, but also whole programming languages. The following list should provide an overview.
GOAL
AGENT0
AgentSpeak
2APL
Golog
JACK Intelligent Agents
Jadex
Jason
The advantages of such programming languages is that the developer is able to use
features of the modeling process directly. Agent-based Programming Languages(AOP)
are built to support features from Agent-Based Models (ABM). The main difference
to general purpose modern programming languages is, that agent-based languages are
based on reactive rules. This basis allows a programmer to use clear semantics and
knowledge representing features. However, he has to relinquish other features such as
high reusability of code and modularity [173].
The Jade framework
This part will give a more detailed focus on the Java Agent Development Framework.
Jade is written in the Java language for Java environments. It’s sole purpose is to support
java agent development and to provide a runtime for those agents. It can therefore be
seen as a middleware solution built to host a runtime for agents.
The framework is being developed by the University of Parma, where people started to
work on the project in 2001. Today it is property of Telecom Italia.
The current versions of Jade have reached a very sophisticated level of design. Listing
C.4 shows how to implement a sample agent within Jade.
483
Besides the agents the user of Jade is going to develop, there is a pair of agents, which
will always be running in a Jade environment.
At first there is the Agent Management System (AMS) agent. This entity can best be
described as an administrative force among the agents. The AMS is the only agent that
is allowed to instanciate and destroy other agents. This agent is also capable of killing
whole containers full of agents or shutting down the entire MAS application.
The Directory Facilitator (DF) agent can be seen as being similar to the UDDI approach,
which has been developed for web services. It provides a yellow pages service, which
agents can use to find other ones in the system. Agents can use the service to look
up names, functionality and other criteria in order to match search results. All agents
running in the system are registered with the DF.
Another important aspect of Jade is that it is highly FIPA compliant. In fact it
supports the FIPA Agent Communication Language in FIPA’s own SL language and
in XML notation. The support for this is “built-in”, so the developer does not need
to handle it himself. Listing C.4 shows how to use these integrated language support
components.
Listing B.1: Sample Implementation of a Jade agent
package de . stamer . a g e n t s ;
import j a d e . c o n t e n t . ContentElement ;
import j a d e . c o n t e n t . l a n g . Codec ;
import j a d e . c o n t e n t . l a n g . s l . SLCodec ;
import j a d e . c o n t e n t . onto . Ontology ;
import j a d e . c o r e . AID ;
import j a d e . c o r e . Agent ;
import j a d e . c o r e . b e h a v i o u r s . OneShotBehaviour ;
import j a d e . l a n g . a c l . ACLMessage ;
import de . stamer . o n t o l o g y . MASOntology ;
public c l a s s SampleAgent extends Agent {
/* *
*
* A sample i n s t a n c e o f a JADE a g e n t .
*
* @author D a n i e l Stamer
<d a n i e l @ s t a m e r . i n f o >
*/
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = 1L ;
private Codec c o d e c = new SLCodec ( ) ;
private Ontology o n t o l o g y = MASOntology . g e t I n s t a n c e ( ) ;
protected void s e t u p ( ) {
484
System . out . p r i n t l n ( ”SETTING UP SAMPLE AGENT : ” + t h i s . getAID
( ) . getLocalName ( ) ) ;
getContentManager ( ) . r e g i s t e r L a n g u a g e ( c o d e c ) ;
getContentManager ( ) . r e g i s t e r O n t o l o g y ( o n t o l o g y ) ;
addBehaviour (new OneShotBehaviour ( t h i s ) {
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = 1L ;
public void a c t i o n ( ) {
doWait ( 1 0 0 0 ) ;
AID admin = new AID ( ) ;
admin . setLocalName ( ”admin” ) ;
ACLMessage msg = new ACLMessage ( ACLMessage . SUBSCRIBE) ;
msg . s e t S e n d e r ( getAID ( ) ) ;
msg . a d d R e c e i v e r ( admin ) ;
msg . s e t C o n t e n t ( getAID ( ) . getLocalName ( ) ) ;
send ( msg ) ;
}
}) ;
}
protected void takeDown ( ) {
System . out . p r i n t l n ( ”TAKING DOWN: ” + t h i s . getAID ( ) .
getLocalName ( ) ) ;
}
}
Jade has a few extensions, which are able to extend the functionality of the framework.
The most important extension is Wade.
The Workflows and Agents Development Environment (Wade) integrates into the Eclipse Rich Client Platform (RCP) by providing a plugin for the Integrated Development
Environment (IDE). Wade is very useful for implementing multi-agent systems. It provides the developer with an development environment for agents, which has been enhanced
with a graphical tool to visualize workflows and communications among agents. A developer can switch between multiple perspectives to view the interplay of agents that
are envolved in the MAS.
The Wolf component of Wade is the GUI plugin, which is visible in Eclipse.
Another important extension is blueJade, which aims to provide the use of Jade within
a J2EE architecture. It’s use is recommended in larger business applications.
485
Conclusion
The very first hype on the technology around agents is over. People have calmed down
and are able to gain a sobering, yet realistic view on the technology.
Lots of indicators show advantages in encapsulating services with agents. Adding nonfunctional abilities to the core features of an application is a good idea in general, since
it allows high reusability of the agent components. Encapsulated services are highly
modular entities, which can be used to construct new MAS just by selecting these agent
components from a set of existing ones. Lots of preferable attributes increase the value of
the service, such as increased mobility, reliability, security, privacy, customizability and
composability. Agent components, especially mobile ones, are an interesting and very
promising approach in refashioning the common understanding of services.
486
Untersuchung von Elektroautos unter
Nachhaltigkeitsaspekten im Vergleich mit
anderen Verkehrsmitteln
[email protected]
Zusammenfassung: Der Begriff der Nachhaltigkeit bzw. Sustainability wird unterschiedlichst definiert. Um eine belastbare Bewertung der
Nachhaltigkeit von alternativen Antriebskonzepten wie der Elektromobilität zu realisieren, muss der Begriff definiert werden.
Elektromobilität steht im Ruf, eine besonders nachhaltige Form der Fortbewegung darzustellen. Dies muss unter verschiedenen Aspekten geprüft
werden: So stellt sich die Frage, ob die Bindung bestimmter Ressourcen
einen Nachteil darstellt. Ein weiterer wichtiger Aspekt stellt der sogenannte Energiemix dar. Die Umweltbelastung eines Elektroautos hängt
direkt vom Produktionsprozess ab.
Diese Arbeit beschäftigt sich mit der Frage, ob Elektromobilität den
Nachhaltigkeitsaspekt in dem Maße erfüllen kann, der für diese Technologie in Anspruch genommen wird.
Schlüsselwörter: Nachhaltigkeit, Sustainability, Dimensionen der
Nachhaltigkeit
487
Einleitung
Elektromobilität wird mittlerweile als Synonym für nachhaltigen Verkehr betrachtet. Die
Eigenschaften, die man ihr zuspricht, lassen vermuten, dass diese Technologie alle aktuellen Probleme der Mobilität lösen kann. Es besteht keine Abhängigkeit mehr zu fossilen
Energieträgern, die Bewegung ist ohne Emissionen möglich und löst Abhängigkeiten zu
instabilen Staaten auf.
In dieser Arbeit wird die Elektromobilität unter verschiedenen Aspekten der Nachhaltigkeit betrachtet, um abschließend eine Aussage darüber treffen zu können, ob dieser
technologische Ansatz den Erwartungen gerecht werden kann. Der Begriff der Nachhaltigkeit wird in verschiedenen Dimensionen betrachtet um eine differenzierte Abbildung
des Einflusses auf diesen zu erhalten.
Nachhaltigkeit soll nicht auf die ökologische Dimension beschränkt bleiben. Für die Bewertung einer Technologie sind die ökonomische Dimension und die gesellschaftliche
Dimension ebenso zu betrachten. Der Schritt hin zu einer praktischen Betrachtung soll
erreicht werden, indem diese Dimensionen auf die Thematik Elektromobilität abgebildet
werden.
Neue Technologien verändern die Umwelt, in der sie eingesetzt werden. Sie verdrängen
vorhandene Technologien, können aber auch als Enabler die Verbreitung bereits eingeführter Technologien fördern. In dieser Arbeit wird deshalb der mögliche Einfluss der
Elektromobilität auf den Einsatz verschiedener Kraftwerkstechnologien untersucht, um
Wechselwirkungen aufzuzeigen, die Einfluss auf die Nachhaltigkeit haben.
Hinweis: In diesem Artikel werden Begriffe wie Energieverbrauch oder erneuerbare Energien benutzt. Aus physikalischer Sicht sind diese Begriffe wenig sinnvoll [174]. Im allgemeinen Sprachgebrauch wird der Energieverbrauch als Synonym für Energieformumwandlungsprozesse genutzt und erneuerbare Energien als Menge jener Energiequellen,
die nicht auf fossilen Rohstoffen basieren. Im Sinne der Lesbarkeit werden die Formulierungen des allgemeinen Sprachgebrauchs verwendet. Dem Autor ist die Ungenauigkeit
dabei sehr wohl bewusst. . .
Dimensionen der Nachhaltigkeit
Nachhaltigkeit kann nicht nur als Einfluss einer Handlung oder Technologie auf die Umwelt im Sinne der Ökologie betrachtet werden. Ökonomische Fragen und gesellschaftliche
Auswirkungen sind mindestens genauso schwer zu gewichten, um einen nachhaltigen
Effekt zu erreichen.
488
Dimension Ökologie
Die ökologische Dimension berücksichtigt Verbrauch und Zerstörung vorhandener Ressourcen [+++]. Der Begriff Nachhaltigkeit wurde sehr früh durch die Forstwirtschaft
eingeführt. Der Forstwirt bezeichnet die Nutzung eines Waldes dann als nachhaltig,
wenn der Holzschlag geringer oder gleich der Wachstumsrate ist. Das bedeutet, dass
maximal der Prozentsatz an Waldfläche geschlagen wird, der mit der durchschnittlichen
Wachstumsdauer korrespondiert.
Durch diese Strategie ist sichergestellt, dass ein Wald langfristig wirtschaftlich genutzt
werden kann. Es stellt sich die Frage, ob diese Betrachtung nicht als ökonomische Dimension betrachtet werden sollte. Da die Motivation der Erhalt eines Wirtschaftsguts
ist, wäre die Einstufung als ökonomische Dimension gerechtfertigt. Da das Wirtschaftsgut Wald bei einer intensiven Nutzung nicht vollständig verbraucht wird, sondern sein
Wesen verändert – z. B. als Ackerfläche nutzbar wäre, ist ist nicht alleinstehend gültig.
Die ökologische Dimension ist dadurch auch in diesem Beispiel zu erkennen, wenn man
die Langfristigkeit der Handlungsstrategie berücksichtigt. Der Vorteil der nachhaltigen
Nutzung tritt erst nach mehreren Dekaden auf.
Dimension Ökonomie
Der Begriff der Nachhaltigkeit spielt in der Ökonomie eine wesentliche Rolle. Die verfolgten Ziele sind nicht weit von jenen Zielen der ökologischen Dimension entfernt: Die Nutzung einer Ressource bei geringstmöglichen Verbrauch und unter dem Anspruch, diese
Nutzung über einen möglichst langen Zeitraum zu ermöglichen. Der Unterschied liegt im
Zielsystem: Während in der ökologischen Dimension hauptsächlich die Umwelt betrachtet wird, liegt in der ökonomischen Dimension der Fokus auf dem eigenen Objekt, z. B.
der Unternehmung. Eine nachhaltig geführte Unternehmung ist daher gewinnorientiert
und zukunftsorientiert, sichert also nicht nur das eigene Überlebensfähigkeit, sondern
auch die der Geschäftspartner.
Dimension Gesellschaft
Die Einführung neuer Technologien kann einen großen Einfluss auf die Lebensbedingungen der Gesellschaft haben. Dieser Einfluss ist schwer bewertbar. Unterschiedlichste
Lebensbedingungen sorgen für sehr differenzierte Auswirkungen, direkt oder indirekt,
der Einführung neuer Technologien.
Plakative Beispiele hierfür sind die Informations- und Kommunikationstechnologien (IKT).
Der Zugang zu Informationen hat sich durch diese Technologien vereinfacht. Dies hat
die Art zu arbeiten, zu lernen und das Privatleben beeinflusst. Umfassend betrachtet
489
wird dies als positiv bewertet. Die rasante Verbreitung mobiler Endgeräte hat aber
auch den weltweiten Bedarf seltener Erden ansteigen lassen. Ein besonders wichtiger
Rohstoff stellt dabei das Tantal dar. Hauptlieferant für Tantal ist die Republik Kongo.
Das bürgerkriegszerrüttete Land finanziert die Konflikte über die Einnahmen aus der
Tantalförderung, die unter fragwürdigen Bedingungen für die Arbeiter betrieben wird.
Der positive gesellschaftliche Einfluss der IKT für die Gesamtheit der Menschen ist also
überschattet durch die Konsequenzen für einzelne Länder.
Betrachtet man die gesellschaftlichen Auswirkungen, die der erhöhte Einsatz von Elektrofahrzeugen hat, ergibt sich ein positives Bild. Durch die steigende Bevölkerungsdichte
erhöht sich die Wirkung des Handelns eines Individuums auf die Gesellschaft. Emissionen belasten in höherer Konzentration mehr Individuen. Wenn eine Technologie es
ermöglicht, diese Emissionsbelastung zu reduzieren oder das Auftreten der Emissionen
aus den Ballungsräumen hinaus zu verlagern, hat dies einen positiven Einfluss auf die
Lebensqualität einer Gesellschaft insgesamt.
Nachhaltigkeit als Technologie-Attribut
Selbst eine kurze Einführung in den Begriff Nachhaltigkeit zeigt, dass die häufig beklagte
Unschärfe des Begriffs damit zu begründen ist, dass sehr viele verschiedene Themenbereiche hineinspielen. In dieser Arbeit wird Nachhaltigkeit als Kriterium verstanden, dass
die Aspekte Ökologie, Ökonomie und Gesellschaft in Wechselwirkung betrachtet. Technologien können in dieser Definition nur dann Nachhaltigkeit sein, wenn einerseits ein
positiver Einfluss auf die Natur gegeben ist, weiterhin aber auch die Realisierung aus
ökonomischer Sicht sinnvoll und aus gesellschaftlicher Sicht wünschenswert ist.
Verkehrsmittelbetrachtung
Im vorigen Abschnitt wurden die verschiedenen Ausprägungen des Begriffs Nachhaltigkeit betrachtet. Eine vergleichende Betrachtung zwischen der Elektromobilität und
weiteren Mobilitätsformen unter Berücksichtigung der vorgestellten Aspekte der Nachhaltigkeit soll es erlauben, Aussagen über die Nachhaltigkeit an sich und im Speziellen
der Elektromobilität zu treffen.
Die Verkehrsmittelbetrachtung als Hilfsmittel zur Entscheidungsunterstützung für die
Auswahl eines Mobilitätstyps stellt den Nutzer vor Herausforderungen. Als wesentliches
Problem ist die Umlage der Ressourcenbindung und des Energieverbrauchs auf den Nutzer zu nennen. Fahrzeuge im Individualverkehr werden i. d. R. bezogen auf das Fahrzeug
bewertet, während öffentliche Verkehrsmittel auf den Nutzer bezogen betrachtet werden.
Üblicherweise wird hauptsächlich die -Emission bei der Nutzung als Indikator verwendet.
490
Dies ist problematisch, weil die Belastungen der Umwelt durch den Einsatz verschiedener
Technologien unterschiedliche Ausprägungen haben. Als Hilfsmittel hat sich für dieses
Problem die Nutzung einer -Äquivalenz etabliert. Dies bildet aber die Effekte außerhalb
der ökologischen Dimension der Nachhaltigkeit nur unzureichend ab.
Im Folgenden werden die Eigenschaften einzelner Mobilitätsformen betrachtet, um jene
Situationen zu bestimmen, in denen eine Form am nachhaltigsten genutzt werden kann.
Individualverkehr
Als Individualverkehr werden Mobilitätsformen bezeichnet, bei denen ein Fahrzeug, dass
sich i. d. R. im Besitz des Nutzers befindet, für den Mobilitätsbedarf des Nutzers eingesetzt wird. Die Belastung des Ökosystems und der Gesellschaft im Allgemeinen wird
wesentlich durch die Technologien beeinflusst, die bei der Realisierung eingesetzt werden.
Im Folgenden werden Fahrzeuge für den Individualverkehr in Hinblick auf die verwendete
Antriebstechnologie betrachtet.
Fahrzeuge mit Verbrennungsmotoren
Kraftfahrzeuge mit Verbrennungsmotoren gelten als sehr umweltbelastend. Diese Aussage muss genau geprüft werden. Es ist richtig, dass der Kraftfahrzeugverkehr nach
der Industrie ein Hauptverursacher für klimabelastende Emissionen ist. Dies ist leicht
nachvollziehbar: Aus der Verbrennung resultieren Gase, die den Treibhauseffekt der Atmosphäre unterstützen.
Diese allgemeine Aussage ist aber dann nicht mehr gültig, wenn nachwachsende Rohstoffe für die Herstellung der Treibstoffe verwendet werden. Die emittierten Gase wurden
vorher von den Pflanzen aus der Atmosphäre aufgenommen. Im Gegensatz zu Treibstoffen aus fossilen Quellen werden daher keine langfristig der Atmosphäre entzogenen Gase
neu emittiert. Die Herausforderung liegt hier in der gesellschaftlichen Dimension. Landwirtschaftlich nutzbare Flächen sind eine nur eingeschränkt vorhandene Ressource. Es
ist gesellschaftlich fragwürdig, wenn durch die Nutzung dieser Flächen zur Produktion
von Kraftstoffen Nahrungsmittel verknappt werden. Die Belastung hieraus müssten die
wirtschaftlich schwachen Bevölkerungsgruppen tragen. Ein weiterer Aspekt sind lokale
Emissionen. Die Luftbelastung wird nicht geringer. Feinstaubkonzentrationen in urbanen Räumen werden durch den Einsatz von Bio- Kraftstoffen weiterhin ein Problem
darstellen.
Als Sonderform sind Fahrzeuge zu betrachten, die mit Wasserstoff betrieben werden. Der
Wasserstoff kann mittels Elektrolyse aus Wasser gewonnen werden. Wird die dazu notwendige Elektrizität aus erneuerbaren Energiequellen gewonnen, ist die Klimabilanz mit
491
der eines rein elektrisch betriebenen Fahrzeugs vergleichbar. Die bei der Verbrennung
entstehenden Emissionen stellen reinen Wasserdampf dar. Der praktische Einsatz von
Wasserstoff als Kraftstoff wird seit langer Zeit erprobt. Die Herausforderungen sind im
Wesentlichen ökonomischer Natur: Die sichere Lagerung und Betankung von Fahrzeugen
mit dem hoch entzündlichen Wasserstoff ist nur mit erheblichen technischen Aufwand
realisierbar. Wasserstoff hat weiterhin den Nachteil, dass die Emission, Wasserdampf,
ein sehr potentes Treibhausgas darstellt. Dieser Aspekt wird allerdings nur dann berücksichtigt, wenn entweder dem Wasserdampf ein -äquivalent entgegengestellt oder die
eine umfassende Betrachtung der Emissionen durchgeführt wird.
Aus Herstellersicht ist die Optimierung nicht das primäre Problem, sondern die Nachfrage am Markt. Die Effizienz moderner Verbrennungsmotoren lässt extrem geringe Verbrauchswerte zu. Tatsächlich bleibt der Verbrauch aber relativ konstant, während die
durchschnittliche Leistung bei Pkw kontinuierlich ansteigt. Fahrzeuge, welche die technischen Möglichkeiten zur Effizienzsteigerung nutzen, sind noch sehr schwer am Markt
positionierbar. Das Potenzial ist aber verfügbar: Bei Verbrauchswerten um einen Liter
”
wird niemand mehr über Elektroantriebe sprechen [. . . ]“29
Fahrzeuge mit hybriden Antrieben
Kfz mit hybriden Antrieben haben neben dem klassischen Verbrennungsmotor zusätzlich einen elektrischen Antrieb zur Verfügung. Ziel ist es, den Verbrauch des primären
Energieträgers zu reduzieren, indem die Energie möglichst effizient genutzt wird. So wird
z. B. die Bremsenergie nicht in Wärme, sondern in Elektrizität umgewandelt, um diese
bei einem Beschleunigungsvorgang unterstützend zu nutzen. Der zusätzliche technische
Aufwand ist gerade dann lohnend, wenn sich das Bewegungsprofil des Fahrzeugs durch
ungleichmäßige Fortbewegung (Stadtverkehr) auszeichnet. In der Praxis kann durch den
Einsatz von hybriden Antrieben der durchschnittliche Verbrauch im urbanen Bereich auf
Werte gesenkt werden, die mit herkömmlichen Motoren nur im Überlandbetrieb erreicht
werden.
Die Auslegung des Verhältnisses zwischen Verbrennungs- und Elektromotor bestimmt,
ob man ein derartiges Fahrzeug als Elektrofahrzeug bezeichnen kann. Dominiert die
Leistung des Elektroantriebs und der Verbrennungsmotor wird als Generator für die
Stromversorgung verwendet, ist die Bezeichnung Elektrofahrzeug legitim. Das Fahrzeug
hat zwar offensichtlich Emissionen, dies trifft allerdings auch auf ein Fahrzeug mit reinem
Elektroantrieb zu, wenn man den gesamten Kraftwerk- Lebenszyklus der Stromquelle
berücksichtigt.
Insgesamt stellt ein Hybridfahrzeug einen Kompromiss zwischen dem Effizienzanspruch
und der Flexibilitätserwartung des Nutzers dar. Die aufwendige Technik erhöht das Fahr29
Piech auf einer Pressekonferenz zum Volkswagen L1 2010
492
zeuggewicht und dadurch den Energiebedarf. Optimierte Fahrzeuge mit Verbrennungsoder Elektromotoren erreichen meist geringere Verbrauchswerte. Diese optimierten Ergebnisse sind aber mit großen Einschränkungen des Nutzers verbunden. Schlußendlich
ist der reale Verbrauch für den Endverbraucher dann schwer zu identifizieren, wenn es
sich um sogenannte Plug-In Hybridfahrzeuge handelt. Bei diesen Fahrzeugen ist es möglich, die Akkumulatoren über das Stromnetz aufzuladen und kurze Strecken vollständig
ohne Unterstützung durch den Verbrennungsmotor zurückzulegen. Die Verbrauchsangaben dieser Fahrzeuge berücksichtigen diese extern eingespeiste Energie nicht. Aus dieser
Vorgehensweise resultieren auf dem ersten Blick sehr geringe Verbrauchswerte, da innerhalb des Testzyklus nur ein Teil der verbrauchten Energie gemessen wird.
Fahrzeuge mit Elektromotor
Fahrzeuge mit reinem Elektroantrieb können viele Ansprüche realisieren, die an ein Fahrzeug mit geringer Umweltbelastung gestellt werden. Bei Einsatz elektrischer Energie aus
erneuerbaren Energiequellen wird die Atmosphäre nicht weiter belastet. Der Antrieb ist
wesentlich leiser als ein klassischer Verbrennungsmotor, was Lärmemissionen in urbanen
Gebieten erheblich reduziert. Die Leistungsfähigkeit moderner Elektromotoren und deren
Abgabecharakteristik erfüllen alle Anforderungen an den Antrieb eines Kraftfahrzeuges.
Am Markt sind dennoch kaum nennenswerte Marktanteile zu verzeichnen. Die Herausforderung der Elektromobilität stellt die Akkumulatoren-Technologie30 dar. Die Energiedichte, d. h. die Menge gespeicherter Energie je Kilogramm Energieträger, ist im Vergleich zu Kraftstoffen sehr gering. Die Akkumulatoren stellen daher einen großen Teil
des Gesamtfahrzeuggewichts dar. Zusätzlich sind die Akkumulatoren sehr teuer in der
Anschaffung. Als Folge übersteigen die Kosten für die Energiespeicherung leicht die restlichen Materialkosten beim Fahrzeugbau, wenn heutzutage gewohnte Reichweiten realisiert werden sollen. Im Gegensatz zu Verbrennungsantrieben dauert das Wiederbefüllen
des Energiespeichers sehr lange. In Abhängigkeit der verwendeten Speichertechnologie
dauert das Laden zwischen 30 Minuten bis hin zu mehreren Stunden.
Die Akzeptanz rein elektrischer Antriebe ist daher von der Reichweite, der Dauer der
Ladezyklen und der Abdeckung des individuellen Bewegungsmusters ab. Ökonomisch
sind rein elektrische Antriebe gerade dann interessant, wenn keine langen Strecken zurückgelegt werden müssen. Dies erlaubt vergleichsweise geringe Akku-Kapazitäten und
reduziert die Fixkosten. Im laufenden Betrieb sind die Energiekosten vergleichsweise gering, da bislang keine verkehrsbedingten Steuern auf elektrische Energie erhoben werden.
Das Bewegungsmuster des Nutzers muss sich verändern, um die Vorteile dieser Technologie in vollem Maße nutzen zu können. Der wesentliche Aspekt ist hierbei die Bereitschaft,
30
Es handelt sich nicht um Batterien. Batterien sind Primärzell-Elemente, die nicht wieder aufladbar
sind. Akkumulatoren arbeiten mit Sekundärzellen und können wiederholt aufgeladen werden. (DIN
40729)
493
zugunsten eines geringeren Bedarfs an Speicherkapazität alternative Verkehrsmittel zu
wählen.
Öffentliche Verkehrsmittel
Öffentliche Verkehrsmittel können verschiedenste Antriebskonzepte umsetzen. Der Nachhaltigkeitsaspekt wird primär durch die hohe Auslastung der einzelnen Ressource erreicht. Im Gegensatz zum Individualverkehr wird der Energieverbrauch auf die einzelnen
Nutzer verteilt und nicht fahrzeugbezogen berechnet.
Bahn
Die Eisenbahn hat den Ruf, ein sehr umweltfreundliches Verkehrsmittel zu sein. Im
Verhältnis zu den Nutzerzahlen besteht nur ein geringer Flächenbedarf. Dies reduziert
den Anteil versiegelter Flächen. Bezogen auf die Fahrzeuglänge werden wesentlich mehr
Personen transportiert als beim Individualverkehr.
Die Entwicklung hin zu Hochgeschwindigkeitszügen hat allerdings einen Vorteil der Eisenbahn minimiert: Den Energiebedarf. Moderne Züge wie der ICE verbrauchen je Nutzer ein Energieäquivalent von 2,7 Litern Benzin auf 100 Kilometern [175]. Das ist geringer
als bei Pkw, diese werden jedoch auf das Fahrzeug bezogen betrachtet. Erhöht man die
Auslastung von Pkw auf das Niveau von Zügen (ca. 80durchschnittliche Auslastung),
dann wird der Verbrauchswert der Bahn wesentlich unterschritten.
Die Vorzüge der Bahn sind dann nutzbar, wenn das Verkehrsmittel eine möglichst hohe Auslastung hat. Dieses Ziel kollidiert leider mit dem Wunsch Reisender, flexibel den
eigenen Anforderungen entsprechend zu reisen. Infolge dieses Interessenkonflikts ist die
Kapazitätsplanung und die Verbindungsfrequenz als eigentliches Problem im Bahnverkehr zu sehen. Die Attraktivität steigt mit der Flexibilität, ökonomisch und ökologisch
sind hoch ausgelastete, lange Züge, die seltener fahren aber nachhaltiger.
Die Nachteile für den Nutzer sind weniger gewichtig, wenn die zurückgelegte Strecke
anwächst. Über lange Strecken überwiegt die Planungssicherheit über Reisedauern den
Nachteil der Unflexibilität.
Bus
Der Busverkehr ist in Deutschland hauptsächlich auf den Nahverkehr und als Mittel
der Bereitstellung eines öffentlichen Verkehrsnetzes in strukturschwachen Regionen beschränkt. Dies ist durch Gesetze begründet, die als Schutz eine Konkurrenz zwischen
494
Bahn und Bus unterbinden.
Busse eignen sich insbesondere für die Einrichtung neuer öffentlicher Transportangebote, da keine neue Infrastruktur31 aufgebaut werden muss. Aufgrund der Baugröße lassen
sich alternative fossile Brennstoffe wie Erdgas leichter einsetzen. Überraschenderweise
sind Busse wesentlich sparsamer beim Energieverbrauch als Züge. Im Fernverkehr reduziert sich der Aufwand auf ca. 1,6 Liter auf 100 Kilometer je Nutzer. Technisch lässt sich
dies mit der geringeren Geschwindigkeit erklären [175].
Damit Busse als nachhaltiges Verkehrsmittel ihren Anteil am Gesamtaufkommen erhöhen können, muss nicht die Technik, sondern das gesellschaftliche Umfeld angepasst
werden: Gesetze, die bisher einen Linienbetrieb parallel zu vorhandenen Bahnverbindungen untersagen, müssen geändert werden. Des Weiteren ist im Sinne des flexiblen
Einsatzes und der optimierten Auslastung ein Weg zu finden, wie aus individuell Reisenden Gruppen gebildet werden können, ohne die individuellen Interessen in hohem Maße
einzuschränken.
Mischformen
Die vorangegangenen Erläuterungen veranschaulichen, dass die betrachteten Verkehrsmittel für sich allein betrachtet nicht die Mobilitätsansprüche erfüllen können, die sich
durch fossil betriebene Pkw etabliert haben. Reichweite, Verfügbarkeit, individuelle Kosten oder Komfort sind Aspekte, die kein angesprochenes Verkehrsmittel abdecken kann.
Ein Weg aus dieser Situation heraus wäre die Veränderung des Mobilitätsanspruchs. Eine derartige Veränderung hätte aber zur Folge, dass die Organisation von privaten und
beruflichen Leben erheblich verändert werden müsste. Dies wird nur schwer durchsetzbar
sein.
Eine Alternative zur umfassenden Anspruchsänderung wäre es, den Nutzer beim Mischen
verschiedener Mobilitätsangebote zu unterstützen. Anhand seines primären Bewegungsprofils können Empfehlungen für das geeignete Fahrzeug zur Befriedigung der individuellen Mobilitätsansprüche gebildet werden, während für die sekundären Bewegungsprofile
Lösungen durch die Kombination mit anderen Mobilitätsangeboten angeboten werden.
Individualverkehr kann außerhalb von Ballungszentren nur unter erheblichen Einbußen
für die Nutzer unterbunden werden. Aus gesellschaftlicher und ökonomischer Sicht wäre
dies kaum wünschenswert. Ein schlecht ausgelasteter öffentlicher Nahverkehr ist ökologisch bedenklich – im Extremfall bedenklicher als optimierter Individualverkehr.
Daraus lässt sich schließen, dass die Einschränkungen der Elektromobilität bei einem
zielgerichteten Angebot zusätzlicher Mobilitätsangebote keinen Nachteil darstellen. Das
individuelle Interesse kann über das Mischen mit weiteren Verkehrsmitteln abgedeckt
31
Schienennetz
495
werden, während das Interesse der Allgemeinheit, den Individualverkehr insgesamt zu
reduzieren, durch die technischen Einschränkungen wirksam durchgesetzt wird.
Im Folgenden wird der Gedanke der Kombination verschiedener Verkehrsmittel als Lösung des Mobilitätsproblems näher betrachtet. Dabei stellt nicht das Verkehrsmittel
selbst, sondern der Nutzer als Individuum die organisatorische Herausforderung dar.
Kombinatorische Verkehrsmittelbetrachtung
Aus den vorigen Abschnitten wird ersichtlich, dass ein Wechsel des Energieträgers allein
den Anspruch der Nachhaltigkeit bei der Befriedigung von Mobilitätsbedürfnissen nicht
ausreicht. Die Vorzüge einzelner Technologien sind nur unter eng definierten Anwendungsszenarien in vollem Maße nutzbar. Sinkt dieses Maß, wird mindestens eine Dimension des Nachhaltigkeitsbegriffs in hohem Maße missachtet. Die Folge wäre ein geringerer
positiver ökologischer Einfluss oder negative Einflüsse auf die ökonomische Nachhaltigkeit. In beiden Szenarien wird das Ziel der reduzierten Umweltbelastung nicht erreicht:
Entweder direkt durch die Emissionen und Ressourcenbindungen oder indirekt dadurch,
dass ein Mobilitätsangebot nicht angenommen wird.
Folgend werden Methoden und Aspekte erläutert, die eine Zuordnung von Mobilitätsbedürfnissen zu Technologien erlauben, um die nachhaltige Wirkung der Elektromobilität
zu maximieren.
Identifikation von Nutzungsprofilen
Der hohe Anteil des Individualverkehrs am Gesamtverkehrsaufkommen ist nicht ökonomisch begründet. Die Kosten sind für das Individuum immens. Die Aufwendungen für
ein Kraftfahrzeug gelten nach den Investitionen für eine Immobilie als größte finanzielle
Belastung für Privatpersonen. Ein Grund für die hohe Investitionsbereitschaft ist in den
sehr individuellen Ansprüchen der Nutzer von Mobilitätsangeboten zu sehen. Als weiterer Grund ist anzunehmen, dass die realen Kosten für den individuellen Nutzer nicht
offensichtlich sind. Die Zusammensetzung aus hohen Investitionskosten, Fixkosten und
Betriebskosten ist nicht so leicht nachvollziehbar, als dass ein Nutzer die tatsächlichen
Kosten auf einen zurückgelegten Kilometer umlegen könnte. Als Folge wird der Einsatz
eines privaten Kfz, dass alle eventuellen Anwendungsszenarien erfüllt, günstiger eingeschätzt, als es tatsächlich ist. Es wird daher eine Unterstützung für die Planung und
Bewertung des Einsatzes verschiedener Verkehrsmittel benötigt.
Im ersten Schritt muss dem Nutzer ein Profil zugeordnet werden. Dieses Profil dient dazu, die Kategorisierung vornehmen zu können. Exemplarisch sollen hier einige mögliche
Profile erläutert werden:
496
Kurzstrecken-Pendler: Ein Kurzstrecken-Pendler legt nur sehr kurze Distanzen zurück.
Typischerweise fährt er vielleicht fünf Kilometer zur Arbeit und legt am Wochenende
vergleichbare Strecken für private Besorgungen zurück. Längere Strecken stellen eine
Ausnahme dar und fallen einmal monatlich an.
Regional-Pendler: Als Regional-Pendler liegt der Lebensmittelpunkt außerhalb der Stadt,
in der gearbeitet wird. Die Jahreskilometerleistungen sind insgesamt hoch, die täglichen
Strecken aber unter 200km.
Diese Beispiele zeigen, dass technisch gesehen sehr unterschiedliche Ansprüche an die
Mobilität gestellt werden. Die korrekte Klassifizierung in eine Gruppe ist für das Individuum nicht einfach. Um die nachhaltige Wirkung der Elektromobilität zu erhöhen, sollte
dem Nutzer eine Hilfe zur Kategorisierung und der folgenden Auswahl des geeigneten
Transportmittels angeboten werden.
Auswahl profilabhängiger Transportmittel
Die Auswahl eines geeigneten Verkehrsmittelmixes stellt den Nutzer vor eine große Herausforderung. Jede Alternative lässt den Entscheidungsbaum anwachsen. Wird im Sinne
der Optimierung die Möglichkeit gegeben, die zurückzulegende Strecke mit verschiedenen
Verkehrsmitteln zu bewältigen, ist ein expotenziell anwachsender Entscheidungsbaum die
Folge. Dieser Entscheidungsbaum kann in seiner Komplexität reduziert werden, wenn die
Anforderungen des Nutzers und vorhandene Infrastrukturelemente als Filter die Wahlmöglichkeiten einschränken.
Im Abschnitt wurden verschiedene Nutzerprofile identifiziert. Aus den Nutzerprofilen
lassen sich Zielgruppen einerseits für bestimmte Angebote der Elektromobilität identifizieren, andererseits für erweiternde Angebote, die den Bewegungsradius eines Individuums erweitern.
Fahr- und Fahrzeuggemeinschaften
Aus den vorhergehenden Abschnitten ist ersichtlich geworden, dass der Energieverbrauch
beim Reisen in hohem Maße durch die Ressourcenbindung beeinflusst wird. Das Kombinationsmodell hat dabei gezeigt, wie ohne wesentliche Einschränkungen für das Individuum durch Technologien wie der Elektromobilität im Verbund mit anderen Verkehrsmitteln die Effizienz gesteigert werden kann.
Die Auslastungsoptimierung kann weiter erhöht werden, wenn Fahrgemeinschaften gebildet werden. Die hohen Fixkosten bei der Anschaffung und der eingeschränkte Aktionsradius eines Elektroautos lassen den Schluss zu, dass der Besitzer eines derartigen
Fahrzeugs regelmäßig bestimmte Strecken zurücklegt. Durch eine Unterstützung beim
497
der Bildung einer Fahrgemeinschaft kann die ohnehin schon geringe Umweltbelastung auf
weitere Personen umgelegt werden, so dass unter Nachhaltigkeitsaspekten eine optimale
Mobilitätsform umgesetzt wird.
Verfolgt man den Gedanken der individuellen Ressourcenbindung weiter, dann kann die
Nachhaltigkeit für einen Pkw noch weiter erhöht werden: Wird die Ressource Fahrzeug
nur während der Nutzung einem Individuum zugeordnet und danach anderen Individuen
zur Verfügung gestellt, ist der fahrzeugbezogene ökologische Fußabdruck auf wesentlich
mehr Strecke umlegbar. Als praktische Umsetzung sind hier Car-Sharing- Angebote zu
nennen.
Schlussfolgerung
Aus den vorhergegangenen Abschnitten ist abzuleiten, dass eine nachhaltige Mobilität nicht durch den ausschließlichen Einsatz eines Fortbewegungsmittels umsetzbar ist.
Die Kombination verschiedener Verkehrsmittel führt erst zu einer nachhaltigen Mobilität. Elektromobilität kann seine Vorzüge in diesem Szenario umfassend zur Wirkung
bringen. Als Lösung für die individuellen Bedürfnisse im Kurzstreckenbereich stellen
Elektro-Automobile eine sinnvolle Alternative, speziell in urbanen Bereichen, dar. Die
Gruppe der Plug-In-Hybriden bzw. Fahrzeuge mit Range-Extendern sind zwar streng genommen keine Elektro-Automobile, können aber aufgrund der höheren Akzeptanz beim
Endverbraucher den Anteil elektrisch zurückgelegter Wegstrecken erhöhen.
Die im direkten Vergleich zu identifizierenden Vorteile sind von hohem Gewicht. Um
aber die Nachteile aufzuwiegen, sind weitere Aspekte zu berücksichtigen, die eine höhere Verbreitung dieser Antriebsform mit sich bringt. Im folgenden Abschnitt wird auf
die Energieversorgungssituation in Deutschland eingegangen. Die Entwicklungen bei der
Elektrizitätsversorgung und neue Herausforderungen, denen sich Energieversorger stellen
müssen, begründen einen Bedarf auf steuerbare Lasten. Diese Rolle kann durch Elektromobilität wahrgenommen werden.
Wechselwirkung der Elektromobilität mit einer nachhaltigen
Energieversorgung
Die Elektromobilität für sich allein betrachtet würde nicht die Erwartungen erfüllen,
die an die Technologie gerichtet sind. Der Gesamt-Energieverbrauch ist nicht wesentlich
geringer und mit einem erheblichen Ressourcen-Bedarf verbunden. Im Folgenden werden
Aspekte betrachtet, die diese eher negative Einschätzung entkräften und Chancen durch
den Einsatz darstellen.
498
Unabhängigkeit von der Primärenergieform
Die Ausrichtung einer Infrastruktur auf einen einzelnen Primärenergieträger ist langfristig mit großen Herausforderungen verbunden. Sinkt die Verfügbarkeit des Energieträgers, ist ein Wechsel mit erheblichen Eingriffen in die nutzende Infrastruktur notwendig.
Aktuell ist dies bei der Versorgung mit Kraftstoffen auf Mineralölbasis zu beobachten.
Politische Unruhen in einigen Produktionsländern lassen die Kosten in einem Maß steigen, dass der Zusammenhang zwischen realer Versorgungssituation und Preisentwicklung
verloren geht. Alternative Kraftstoffe können aber nicht eingesetzt werden, weil die konsumierenden Fahrzeuge diese nicht nutzen können. Wie eng der Toleranzbereich bei Kfz
ist zeigt sich bei der Beimischung von Alkoholen in Benzin. Der neue E10-Treibstoff kann
von vielen älteren Fahrzeugen nicht genutzt werden. Ähnliche Probleme sind bei dem
Einsatz von Bio-Diesel zu beobachten.
Die Besonderheit eines Elektroautos ist die Unabhängigkeit von der ursprünglichen Energiequelle. Bei Versorgungsengpässen oder Preissteigerungen einer Energiequelle ist ein
Wechsel hin zu einer anderen Energiequelle möglich.
Unterstützung einer Versorgung mit erneuerbaren Energien
Die Umorientierung der Elektrizitätsversorgung weg von fossilen und nuklearen Quellen hin zu erneuerbaren Ressourcen bedeutet, dass sich die Versorgungssituation mit
elektrischer Energie verändert. Bisher wurde die Produktion von Elektrizität nachfrageorientiert gesteuert. Dieser Ansatz ist bei einer Erhöhung des Anteils erneuerbarer
Energien nicht weiter verfolgbar. Es wird notwendig, dass die Nachfrage gesteuert wird.
Die Etablierung eines Push-basierten Marktszenarios setzt voraus, dass der Verbraucher
einen nachvollziehbaren Vorteil hat und diesen auch nutzen kann. Ein Werkzeug zur
Realisierung ist das Smart Grid. Ein Problem bei der praktischen Einführung ist aber
die Größe der verfügbaren Verbrauchskapazitäten, die angebotsgesteuert genutzt werden
können [176].
In Deutschland werden jährlich ca. 600 Milliarden kWh elektrische Energie erzeugt. Dabei stellen Kohle- und Kernkraftwerke aus Kapazitätssicht die wichtigsten Kraftwerkstypen dar. In den letzten zehn Jahren hat sich die Kapazitäts-Verteilung zwischen den
Kraftwerkstypen erheblich verschoben. Stellte die Atomkraft 1997 noch 31% der Gesamtleistung zur Verfügung, so hat sich der Anteil bis 2007 auf 22% reduziert. Die Reduktion
auf dieser Seite entspricht dem erhöhten Anteil der erneuerbaren Energien - von 4%
1997 auf 14% 2007. Insgesamt werden aber weiterhin mehr als 2/3 des Energiebedarfs
aus Kohle- und Atomkraft gedeckt [177].
Aus Versorgersicht wird zwischen Grundlast, Mittellast und Spitzenlast unterschieden.
Grundlast bezeichnet dabei den Bedarf an elektrischer Energie, der kontinuierlich durch
499
Abb. B.48.: Verfügbarkeit
angeschlossene Verbraucher erzeugt wird. Mittellast stellt einen Bedarf dar, der zwar
nicht kontinuierlich, aber mit gut vorhersagbar generiert wird. Spitzenlasten bezeichnen
jenen Bedarf, der maximal (kurzfristig) durch die angeschlossenen Verbraucher erzeugt
wird. Für die Grundlast werden Kraftwerke eingesetzt, die aus technischen Gründen
höhere Reaktionszeiten haben, dafür aber geringe Betriebskosten aufweisen [178]. Der
Nachteil der hohen Reaktionszeit ist irrelevant, da die Grundlast kontinuierlich vorliegt.
In Deutschland wird diese Grundlast mittels Braunkohle- und Kernkraftwerken erzeugt.
Obwohl beide Kraftwerksarten nur ca. 30% der verfügbaren Kapazitäten darstellen, wird
mit ihnen 50% des Energiebedarfs gedeckt. Der Mittellast-Bedarf wird durch Kraftwerke
gedeckt, die innerhalb von Stunden in Betrieb genommen werden können. Dazu gehören
z. B. Steinkohlekraftwerke. Diese Kraftwerkstypen werden nicht für die Grundlastversorgung eingesetzt, weil die Betriebskosten deutlich über denen der Grundlast- Versorgungskraftwerke liegen. Für kurzfristige Spitzenlasten werden Kraftwerke eingesetzt, die eine
geringe Reaktionszeit vorweisen. Dazu gehören Gas-, Öl- und Pumpspeicherkraftwerke.
Diese Kraftwerkstypen können innerhalb von Minuten in Betrieb genommen werden und
eigen sich daher sehr gut zum Ausgleich von Nachfragespitzen. Die hohen Betriebskosten erlauben es nicht, diese Kraftwerke ökonomisch sinnvoll zur Grundlastversorgung zu
nutzen.
Die bisher betrachtete Infrastruktur zur Versorgung mit elektrischer Energie ist darauf
ausgelegt, eine Nachfrage zu erfüllen. Das Angebot wird im Sinne der Wirtschaftswissenschaften Pull-gesteuert. Die Produktion folgt der Nachfrage.
Nachfolgend wird auf die Einbindung alternativer Kraftwerkstypen eingegangen. Diese
Kraftwerkstypen eignen sich größtenteils nicht für ein Pull-gesteuertes Marktszenario.
Mit einigen Ausnahmen wie Wasserkraft, Geothermie oder auch Biomasse stellen erneuerbare Energieträger eine schwer planbare Größe dar. Die Bereitstellung der Leistung
500
Abb. B.49.: Kapazitäts-/Produktionsverhältnis
ist wesentlich von den Witterungsverhältnissen abhängig. So sind 16% aller verfügbaren Kapazitäten durch Windkraftanlagen realisiert, der Anteil an der Versorgung beträgt
aber nur 7% [179]. Dies bedeutet, dass konventionelle Kraftwerke zur Überbrückung dieser Versorgungsengpässe bereitstehen müssen. Die Auslastung der Kraftwerkstypen wird
in Jahres-Volllaststunden gemessen. Auf Basis von 8760 Jahresstunden wird berechnet,
wie lange ein Kraftwerk bei maximaler Volllast laufen müsste, um seine durchschnittliche
Jahresproduktion zu erreichen. Je größer die Abweichung von der Basis ist, je geringer
ist die Planbarkeit der Energieerzeugung.
Bei den erneuerbaren Energien werden verschiedene Technologien eingesetzt. Diese haben, abweichend von der Präsenz in der öffentlichen Wahrnehmung, folgende Anteile an
der Erzeugung von Strom (2007) [180]:
Aus den Planungen für die zukünftige Ausgestaltung der Kraftwerks-Infrastruktur geht
hervor, dass der Anteil der planbaren Kraftwerkskapazitäten sinkt. Dennoch muss sichergestellt werden, dass die Versorgung mit elektrischer Energie zuverlässig besteht. Um dies
zu erreichen, sind zwei Ansätze als erfolgsversprechend zu betrachten: Einerseits müssen
die Speicherkapazitäten für erzeugte, aber nicht abgerufene elektrische Energie ausgebaut werden. Eine hierfür etablierte Technik sind Pumpspeicher-Wasserkraftwerke. Zum
anderen wird der Ansatz verfolgt, aus dem Pull- gesteuerten Marktszenario zu einem
Push-gesteuertem Szenario überzugehen. Dies bedeutet allgemein, dass die Nachfrage
durch den Produzenten gesteuert wird. Im Anwendungsfall würde dies heißen, dass Verbraucher aktiv durch den Produzenten gesteuert werden, z. B. ein Elektrofahrzeug dann
geladen wird, wenn Windkraftanlagen große Leistung abgeben.
Die angestrebten Reduzierungen vom -Ausstoß Deutschlands dürfen nicht isoliert von
weiteren Auswirkungen betrachtet werden. Der Einsatz regenerativer Energiequellen zur
Stromerzeugung ist nicht -neutral. Wird der gesamte Lebenszyklus eines Kraftwerks, also auch der Bau und die anschließende Demontage und Entsorgung mit einberechnet,
sind eingesetzte Technologien differenziert zu bewerten: Eine Windkraftanlage kann eine
501
Abb. B.50.: Kapazitäts-/Produktionsverhältnis
kWh Strom mit 10% der -Emissionen gegenüber einer Solaranlage erzeugen. Würde bei
der Technologie-Auswahl neu zu installierender Kraftwerke nur auf den -Ausstoss geachtet, würde ein Kernkraftwerk bis zu fünfmal umweltfreundlicher als der Einsatz von
Photovoltaik-Anlagen sein. Es sind daher noch weitere Faktoren zu berücksichtigen:
Der Bau neuer Kraftwerke und Energieverteilnetze ist mit einem hohen Einsatz an Ressourcen verbunden. Viele der eingesetzten Rohstoffe sind allerdings sehr selten. Für
Generatoren, Gleichrichteranlagen, Steuerelektronik und Energiespeichern werden
sogenannte Seltenerden benötigt. Die Förderung einiger dieser Stoffe (z. B. Lithium) ist
schon heute an Kapazitätsgrenzen angekommen. Andere Stoffe wie z. B. Tantal werden
unter inakzeptablen Bedingungen in Kriegsgebieten wie dem Staat Kongo gewonnen.
Die Kernkraft als Schlüsseltechnologie zur Grundlastversorgung bei gleichzeitig geringer
-Belastung, vergleichbar mit der Belastung durch Windenergie, lässt andere ökologische
Aspekte völlig außer Acht. So existiert bis heute keine Endlagermöglichkeit für die extrem giftigen Abfallstoffe weltweit. Des Weiteren sind die schürfbaren Vorkommen des
Rohstoffs Uran sehr begrenzt und der Abbau ist mit erheblichen Umweltbelastungen verbunden. Das hohe Gefahrenpotenzial lässt daher diese Form der Elektrizitätsgewinnung
im Sinne der Nachhaltigkeit nicht als akzeptabel erscheinen.
Beim Einsatz alternativer Kraftwerkstypen ist zu prüfen, ob die Technologie über den
gesamten Lebenszyklus hinweg tatsächlich die gestellten Erwartungen erfüllen kann.
Da bei diesen Kraftwerken Umweltbelastungen nicht durch den Betrieb, sondern bei
der Produktion und der anschließenden Entsorgung entstehen, ist der Einsatz in einer
bestimmten Region genau zu prüfen. So liegt der rechnerische -Ausstoß einer Photovoltaik-Anlage in Deutschland nahezu viermal höher als in Spanien.
502
Verbrauchsmusteränderung im Bereich Elektrizität
Die heute vorhandenen elektrischen Energienetze sind auf eine zentralisierte Energieerzeugung durch Großkraftwerke hin optimiert. Diese Energienetzgestaltung ist sinnvoll,
da die Effizienz fossil betriebener Kraftwerke mit ihrer Größe steigt. Eine wesentliche
Herausforderung liegt in der Übertragung großer Energiemengen aus dezentral angeordneten Kraftwerken auf der Nord-Süd-Achse sowie die Energieübertragung in die neuen
Bundesländer. Das Lösungen nur dann akzeptabel sind, wenn die langfristig ihre Gültigkeit behalten, ist durch die Schwäche der Höchstspannungsvernetzung zwischen alten
und neuen Bundesländern illustriert, dessen Grundlage seit mehr als 20 Jahren seine
Gültigkeit verloren hat.
Die Netzinfrastruktur erlaubt es heute nicht, dass viele Endverbraucher große Leistungen
parallel abfragen. Im Anwendungskontext Elektromobilität schränkt dieser Umstand die
Möglichkeiten zur Schnellladung von Fahrzeugen erheblich ein. Es müssen daher Ansätze
entwickelt werden, die auf die Kapazitäten des Energienetzes Rücksicht nehmen ohne
den Mobilitätsanspruch der Nutzer zu weit einzuschränken.
Der Anteil regenerativ erzeugter elektrischer Energie ist in Norddeutschland am Höchsten. Aufgrund der geophysikalischen Eigenschaften der Region sind kaum Speicherkraftwerke verfügbar. Die hohen Kapazitäten witterungsabhängiger Stromerzeugung fordern
allerdings einen Ausbau der regional verfügbaren Speicher, so dass neben dem Umbaus des Höchstspannungsverteilnetzes die Entwicklung neuartiger Speichertechniken
notwendig erscheint.
Bedeutung für die Elektromobilität
In diesem Abschnitt wurden die Herausforderungen der langfristigen Versorgung mit
Elektrizität dargestellt. Obgleich der Fokus auf der Infrastruktur liegt ist der Zusammenhang zur Elektromobilität erkennbar. Die Effizienzsteigerungen bei Haushaltsgeräten in
Privathaushalten und die Schwierigkeit, dass Produktionsanlagen kaum Push-gesteuert
mit Energie zu versorgen sind, begründen einen Bedarf an Großverbrauchern, die keinen
direkten zeitlichen Zusammenhang zwischen Energieaufnahme und Verbrauch aufweisen.
Elektromobilität bedeutet hier, dass ein Anwendungsfall für erneuerbare Energien geschaffen werden kann, der viele Probleme, die mit dem Wandel der Kraftwerkstechnologien verbunden sind, löst. Beide Technologien zusammen haben ein höheres Potenzial als
jeweils für sich allein betrachtet. Verluste wie z. B. Abschaltungen von Windkraftanlagen wegen temporärer Überangebote können vermieden werden. Durch den dezentralen
Verbrauch werden zusätzlich die überregionalen Versorgungsnetze entlastet [181] 32 .
32
Paper angenommen: Veröffentlichung im Juli 2011
503
Berechnungen, die heutzutage einen -Ausstoß von 100g/km dem Elektroauto zuordnen,
berufen sich auf den aktuellen Strommix. Dieser Wert wird sich in Zukunft erheblich
verändern. Sollten Verbraucher wie die Elektromobilität den asynchronen Verbrauch
unterstützen, kann mit erneuerbaren Energien dieser Wert reduziert werden. Wird das
Zusammenwirken von Erzeugern und Verbrauchern nicht erreicht, könnte sich der Wert
langfristig sogar verschlechtern: Durch den mittelfristigen Wegfall der Kernkraftanlagen
steigert sich der -Anteil im Strommix.
Der -Ausstoß umgelegt auf elektrische Energie macht deutlich, dass eine alleinige Betrachtung dieses Parameters keine belastbare Aussage über die Nachhaltigkeit zulässt.
Erst durch die Hinzunahme der Dimensionen Ökonomie und Gesellschaft werden auf den
ersten Blick positiv zu bewertende Energiequellen wie die Kernenergie disqualifiziert.
Fazit
Die Ergebnisse dieser Betrachtung lassen die Schlussfolgerung zu, dass Elektromobilität
nicht den Grad der Nachhaltigkeit erreicht, der dieser Technologie im Allgemeinen nachgesagt wird. Die einzelnen Dimensionen für sich betrachtet zeigen, dass offensichtlich die
positive Einschätzung dadurch entsteht, dass negative Einflüsse weniger offensichtlich
erscheinen. Der Energieverbrauch ist nicht niedriger. Allerdings wurde in dieser Arbeit
dargelegt, dass die Besonderheit die Unabhängigkeit von der primären Energiequelle ist.
Dies ermöglicht es, dass der Übergang von fossilen hin zu regenerativen Energieträgern
keinen direkten Einfluss auf die eingesetzten Fahrzeuge hat.
Die Ressourcenbindung ist sehr hoch. Seltene Rohstoffe und Einschränkungen in Schlüsseltechnologien wie den Akkumulatoren sind aber auch hier Nachteile, die als Chance
gesehen werden können: Unter den vorhanden technischen Möglichkeiten wird es nicht
weiter möglich sein, Fahrzeuge für den Individualverkehr in Bauart und Größe wie aktuell üblich ökonomisch sinnvoll zu realisieren. Die geänderten Rahmenbedingungen geben
neuen Entwicklungsrichtungen eine Chance. Fahrzeuge werden kleiner, im Verhältnis
leichter und sind schwächer motorisiert.
Der Grad der Nachhaltigkeit bestimmt sich im Falle der Elektromobilität durch die
Wechselwirkung mit anderen Bereichen. Elektromobilität erzeugt eine Nachfrage für additive Mobilitätsangebote im Fernverkehr. Energieversorger werden in immer höheren
Maße darauf angewiesen sein, dass Regellasten im Netz verfügbar sind, um den Anteil erneuerbarer Energien im Stromnetz anzuheben. Die nachhaltige Wirkung ist also
nicht allein der Elektromobilität direkt zuzuordnen, sondern als indirektes Resultat einer
durch neue Technologien veränderten Umvwelt zuzuordnen.
504
Concepts of (strategic) Customer Relationship
Management and An Approach to
Sustainability
Yi Wei
[email protected]
Zusammenfassung: This seminar presents basic concept of Customer
Relationship Management and a strategic-sustainabe approach to Customer Relationship Management. The first chapter introduces the fundamentals of CRM that include what is CRM, different types of CRM.
The sencond chapter focuses on the concept of strategic CRM, especially the framework of strategic CRM. In the third chapter there are
a few sustainabe approaches to be listed. and at the end it is a short
conclusion.
Schlüsselwörter: CRM, Strategic CRM, Sustainable CRM
505
Abb. B.51.: company with customer centric [184]
Introduction
In recent years, the term CRM has become a buzzword. Especially in today’s dynamic
business environment, many firms have identified that it is hard to sustain international
competitive advantages in the global economic landscape without changing strategy to
customer centric. Namely it is to put customers at the centre of business strategy and
best serve customers. With integrating customer relationship management it makes possible for firms to use the specific methods to communicate the right messages to the right
customers at the right time [182]. It is an essential way to determine which customers
provide the best long-term opportunities for profitable relationships.
And furthermore, with the business globalisation and inconceivable development of ECommerce in the last twenty years the markets have changed from mass marketing to
relationship marketing. The competition comes from everywhere around the world and
customers have started demanding products that fulfill the different needs. In this environment the product quality and features are now undifferentiated in many industries
and the product centric business model ’It’ll sell, We’ll grow’ [183] is no longer competitive. To survive in highly competitive markets the company is forced to shift from focusing
on cutting costs and lower price to a customer focus: Treat Customers as individuals
and follow along ’Only when the customer is successful, that I will be successful’ [183].
In a word, customer relationship management provides the fundamental approach to
putting customers at center of company (Figure B.51) and helping company forwarding
to a customer-driven businesses and sensing the needs of customers as well as providing
high-quality customer services.
506
What is CRM?
Since 90s there have many attempts to define customer relationship management, but
there is still no unified definition. Some people emphasize the significance of IT in CRM,
some stress the customer-centric organization, and other highlight that it is primarily a
business strategy or a functional (Marketing) strategy as described below [185]:
Information industry term
“CRM is an information industry term for methodologies, software and usually Internet capabilities that help an enterprise manage customer relationships
in an organized and efficient manner. ” [186]
Functional (Marketing) Strategy
“CRM is the process of managing all aspects of interaction a company has
with its customers, including prospecting, sales and service. CRM applications attempt to provide insight into and improve the company / customer
relationship by combining all these views of customer interaction into one
picture. ” [187]
Business Strategy
“CRM is a business strategy that maximizes profitability, revenue and customer satisfaction by organizing around customer segments,fostering behavior
that satisfies customers and implementing customer-centric processes. ” [188]
Customer Centric Organization
“CRM is an integrated approach to identifying, acquiring and retaining customers. By enabling organizations to manage and coordinate customer interactions across multiple channels, departments,lines of business and geographies, CRM helps organizations maximize the value of every customer
interaction and drive superior corporate performance.” [189]
Concisely CRM stands for managing customer relationships and helps company to gain
and retain customers, satisfy customers, provide services to them effectively and efficiently. Fundamentally, CRM consists of three essential components: customer, relationship
and management shown in figure B.52:
Customer: The customer is the one who obtains value from the goods or services. A
507
Abb. B.52.: Components of CRM [190]
good customer provides more profit with less resource. But sometimes it is difficult
to distinguish who is the real customer because the buying decision is frequently a
collaborative activity among participants of the decision-making process. [190] By
implementing CRM in company it is liable to distinguish customer and manage
related information.
Relationship: The relationship means a connection, an association or an involvement between companies and their customers. As a bi-directional interaction,
the relationship can be a short-term or long-term, one-time or continuous. CRM
aims to help company to acquire and retain the long-term stable connection with
customers.
Management: Management comprises handling, directing or controlling the people
to accomplish a goal with restricted resources proficiently. CRM collects all the
customer information, analyze the behavior of customers and retain customers to
gain a long-term profit.
Based on these essential components there are three other major components categorized
by researcher - Technology, people, business Process. CRM [191]
Technology refers to IT infrastructure as well as computing capabilities. It supports
company to collect, analyze, save and use customer related data and information.
In CRM the concept of IT includes data warehouse, software customization, process
automation, help desk, Internet influence etc. With integrating technology, it helps
company to improve the capabilities of understanding customer behavior, build
effective communication channels, develop better relationships and achieve the
CRM objectives.
508
The term people means not only customers also employees. Customer is no doubt
the core of CRM, the whole concept is around how to translate customer information into products and services, gain their loyalty by meeting the changing needs and
make long-term benefits. However, the valuable employs and effective management
are the key roles to best serve and satisfy customers.
The third component is business process, business culture and business relationship. As a business strategy CRM helps company to approach customer-centric
and in the meantime it has a wide organizational impact for firms. All business
processes involving interaction with customers direly and indirectly will be assessed and allocated, the process with direct interaction should be deal with as first
priority when integrating business processes. The main business processes to be
addressed are Marketing, sales and services.
CRM Functions
Because of the diversity of definitions CRM is subdivided into four segments by researcher. These different types of CRM are: strategic CRM, operational CRM, analytical
CRM and collaborative CRM. [192]
Strategic CRM: Strategic CRM is a top down perspective on CRM, which views CRM
as a core customer centric business strategy that aims at winning and keeping profitable customers and concentrates the knowledge about customers. This knowledge
forms the basis for a long-term relationship with customers and unique competitive
advantage. This will be discussed in more detail in the next chapter.
Operational CRM: Operational CRM focuses on automating customer facing and customer supporting business processes like marketing, sales and customer service.
CRM software applications enable to integrate and automate all these functions
such as Marketing automation33 , Sales force automation34 , Customer service and
self-service35 etc. Besides operational CRM also deals with interactions with customers in the form of websites, blogs, direct mail, phone sales typically. The entire
customer information including each interaction with company will be saved into
33
Marketing automation is designed to automate all marketing processes. It helps marketing department
improving marketing activities efficiently.
34
Sales force automation (SFA) is the most widely used sales tools to automate all sales related processes.
It is basically used to improve the productivity of sales department and company’s sales process.
35
Customer service and support is responsible for automating service processes like product complaints,
product returns.
509
a client database methodically. In this way the customer information can be later
retrieved as necessary by separate departments directly, meanwhile the customer
do not need to mention their personal information every time when they interact
with different people in a company.
Analytical CRM: Analytical CRM focuses on the intelligent mining of customer-related
data for strategic purposes. It aims at storing and analyzing customer information
captured from different channels and processes of organization. It utilizes data
warehouse to extract appropriate data regarding different customers. This can help
company to decide selling strategy between customer groups for instance. Typically
higher potential value customers may be offered face-to-face selling; lower value
customers may be contacted by telesales.
Collaborative CRM: Collaborative CRM facilitates the interaction with customers through
all channels and applies technology across organizational boundaries with a view
to optimizing company, partner and customer value. This enables organizations to
serve their customers separately and share valuable customers’ information along
the whole supply chain.
To make it more clear here’s an example from a short case study of a B2B information
provider [193]: ”Link customer objectives to broad tactics and build up new skills and
capabilities.”
In strategic level: Start with understanding their customer base and keeping all
customers for cash-flow purposes, then gradually build up the customer asset base.(Strategic CRM)
In operational level: Improve and integrate contact channels. (Operational CRM)
In analytical level: Start to differentiate services and products by customer values
using information management system across the whole organization. (analytical
and strategic CRM)
In the aspect of collaboration: Improve the business model to deliver more customer
value and collaborate across the product supply chain. (collaborative CRM)
510
Abb. B.53.: The value of customer value [194]
Strategic CRM
At the strategic level customer relationship management is a business philosophy which
delivers a vision for better understanding customers’ needs and supports effective marketing, sales and service activities. The aim of CRM strategy is to increase the acquisition,
growth and retention of profitable customers efficiently and effectively. As in last chapter mentioned strategic CRM focuses on the development of a customer-centric business
culture. In the customer-centric culture the resource will be allocated to enhance the customer value and maximize the profitable relationships with customers. Before discussing
details of strategic CRM it is necessary to understand the value of customer value firstly.
Figure B.53 shows clearly that 15 percent customers will generate for 45 percent of revenues and 70 percent of a company’s profits. [194] It means the more the number of
valuable customers company retains, the more margin earned. In fact, from company’s
perspective not all customers are created equal. By integrating CRM the high value
customers would be identified and served in the way to keep them loyal. From customer’s perspective, customers are looking for the company who understands their needs
and provides relevant offers to meet their needs. The value of the relationship between
customer and firm is traditionally interrelated to ’four Ps’ - price, product, place and
promotion - and also the quality of customers’ interactions with company added. [194]
Therefore meeting customer demands and managing the customer relationship is becoming more important and complex in current business environment. Company will
only succeed if they adopt a customer-centric approach and treat customer contacts as
interactions in a long-term relationship over time.
511
Abb. B.54.: Customer Life Cycle [193]
What is a CRM strategy
A CRM strategy is the blueprint for how to build value for customers and plan the toplevel road-map for retaining valuable customers, as well as understand how to convert
customer base to a company asset. It implies the importance of recognizing the whole
customer life cycle and the relations to achieve financial goals. As shown in figure B.54
the Customer life cycle in CRM consists of four phases: target, acquire, develop and
retain.
Seeking the target group, getting potential customers’ attention and creating awareness of what the firm offers to potential customers.
Acquiring valuable customers who will also value the firm and turning them into
paying customers.
Developing the customers’ loyalty36 and value by providing creditable reputation and keeping them as loyal customers who are satisfying with the products or
services.
Retaining and winning back valued customers.
In addition, customer life cycle describes the progress a customer goes through when
considering, purchasing, using, and maintaining loyalty to a product or service. For a
36
Loyal customers choose products or services from a certain company because it offers a superior value
proposition even there are competitive alternatives. Loyal customers differ from captive customers.
Captive customers are those who are reluctant to select products or services, they have no choice
because no alternative exists or because of high cost or discount or advertising or some other reasons.
[195]
512
firm it is always trying to keep customers staying within the cycle when they change
their needs over time. This is exactly the task of an effective CRM. Instead of concentrating product life cycle conventionally strategic CRM helps company to concentrate
the life cycle of customers and focuses on developing products to meet the future needs
of customers and creating compatible services to lengthen customer life cycles. Moreover
strategic CRM has the following objectives:
Reducing the cost of acquisition of new customers and new Market
Strengthening the customer loyalty and reducing customer fluctuation
Increasing customer satisfaction
Maximizing the value of an existing customer
Optimization of business process
Sustaining competitive advantage
To build up such capabilities and achieve the planned business benefits there are number of comprehensive models of strategic CRM developed. Next, there are two illustrious
Models to be introduced. They are strategic framework for CRM from Payne(2001) and
Gartner’ Model.
Strategic frameworks for CRM
Model from Payne
In year 2001 Payne developed a strategic framework which built on the representation
of the META Group who early identified different perspectives on CRM. The model of
Payne consists of five generic cross-functional processes:
Strategic Development Process
Value Creation Process
Multi Channel Integration Process
Information Management Process
Performance Assessment Process
513
Abb. B.55.: Strategic CRM Framework from Payne (2011) [196]
Four of these 5 processes are classified by strategic, operational and analytical CRM. As
shown in figure B.55, the part of analytical CRM focuses on exploitation of customerrelated data. It is the foundation of providing the right information at the right time for
other components. The part operational CRM focuses on the management of virtual and
physical communication channels, and strategic CRM comprises the strategy development process and the value creation process. Payne’s model illustrates the interactive set
of strategic processes that starts with strategy development process and concludes with
the performance assessment process. On the left side, strategic CRM is trying to explain
the type of business, the cluster of customer and indicate the way to create value to
customer. It directs how to act in operational level and integrate with analytical CRM.
In this model the component strategic CRM focuses on a dual strategy [197] - business strategy and customer strategy. The business strategy process begins on reviewing
business vision and competitive characteristics in terms of customer relationship management. To consider the business strategy it must be first to determine how the customer
strategy developed. Customer strategy involves identifying the existing and potential
customer and identifying the appropriate forms of segmentation. Typically customer
strategy is the responsibility of marketing department and business strategy is usually
responsibility of CEO and strategy director. In general the strategy development process
contains a detailed assessment of business strategy and the development of an applicable
customer strategy. This provide a platform for company to develop and implement its
CRM activities. The value creation process transforms the results from the strategy development process into value creation process. In this process the value from both sides will
514
be determined as the value provided to customers and the value received from customers.
The value the customer receives draws on the concept of benefits that can be integrated
in the form of a value proposition. Additionally it also involves the management of value
exchange and process of maximizing the lifetime value of valuable customer segments.
The value assessment is undertaken to quantify the various attributes of products which
customer are interested in. The value organization receives concentrates on customer value received. In the concept of customer value there are two key elements: the one is the
variation of existing and potential customer profitability across different customers, the
other is to comprehend the economics of customer acquisition and customer retention.
Therefore the value creation process is the key component of Strategic CRM because
it translates business and customer strategies into specific value proposition, explains
what value is to be delivered and to be received, how to lengthening customer lifetime
and increase customer lifetime value.
Operational CRM of this Model takes the outputs of the business strategy and value
creation processes, turn them into value-adding activities with customers through different processes such as sales force, e-commerce. The main part multichannel integration
process focuses on combinations of communicating channels and the positive interaction
with customers. Analytical CRM concerns with collecting and analyzing the customer
data and information. The key elements of this part are data warehousing and data
mining solutions. The last part performance assessment process ensure that the goals of
the organization’s strategic in view of CRM are being delivered and a basis for future
improvement is established.
Gartner’ Model
Gartner defines CRM as maximizing profitability, revenue and customer satisfaction.
Gartner’ framework emphasizes the balance between the requirements of companies and
customers. The heart of this framework are the eight building blocks. This eight building
blocks ensure programs are approached on a strategic and integrated basis. As shown
in figure B.56, eight building blocks of CRM includes vision, strategy, valued customer
experience, organizational collaboration, processes, information, technology and metrics.
Vision: The CRM vision is how the customer-centric company will look like. The key
elements are the customer value proposition and the corporate brand values. A
successful CRM vision is the foundation for generating customer loyalty, building
a competitive market position and gaining greater market share.
Strategy: A CRM strategy is developed to turn customer base into an asset by delivering
customer value propositions and take direction for building customer loyalty. The
objectives of a CRM strategy are to target, acquire, develop and retain valuable
515
Abb. B.56.: The Gartner competency model [198]
customers to achieve financial goals.
Valued customer experience: Customers’ experiences affect the value of the enterprise
provides and the importance of the relationship in between. Good customer experiences excite the customer satisfaction and long-term loyalty; in the opposite, poor
customer experiences harm the relationships. Valued customer experience ensure
that the enterprise’s interactions deliver positive value to customers consistently.
Organizational collaboration: The term organizational collaboration changes organizational structures, cultures and behaviors and ensure the employees, suppliers
and partners work seamless together to deliver customer value. Although many
companies believe that CRM bring them to a customer-centric organization by
implementing it, but they ignore to change themselves. Successful CRM drives all
related functions in an enterprise to shift to a customer-centric. The key element
is Ongoing change management.
Processes: Processes are also called re-engineering. It focuses on reworking key processes
relate to customer and finding which processes customers concern. Successful re-
516
engineering creates processes that not only meet customers’ expectations, but also
support the customer value proposition.
Information: It is about collecting right data and information at right time to right
place. Efficient customer information flow is the basis of effective interaction cross
the organization.
Technology: CRM technology is an essential part for any CRM business strategy. It is
taken in three areas: customer-facing applications, architectural issues and integration. Integrated technology supports a seamless customer-centric processes across
the whole company.
Metrics: Metrics are criterion to measure internal and external indications of CRM success and failure. To assess other building blocks it is necessary for company to set
measurable CRM objectives and CRM indicators. There are four levels created to
measure enterprises’ success with CRM performance metrics: corporate, customer
strategic, operational and process. Without performance management it is difficult to integrate CRM successfully. Particularly each company should have unique
metrics adapting to their situation. The possible applications could be: setting
and gauging the level of success in meeting CRM objectives; providing feedback
to modify the CRM strategy and implementation; monitoring the customer experience; acting as a tool for change management; changing the way employees are
compensated and given incentives and communicating how an enterprise wants to
be evaluated compared to the competition [199].
The strategic CRM frameworks are very conceptual and general. It shows a way to
structure the strategy for firms. Each company should have particular design or construct
of the framework to fit itself. These are a base or as a starting point for assessing CRM
initiatives.
517
An Approach to Sustainability
So far the first two chapters discusse a lot about the basic concept of CRM and Strategic
CRM. As a business strategy, CRM is becoming increasingly important in today’s transparent and globalization market. In the wake of market changing the concept of CRM
is upgrading all along. During the recent years new vision of market - green market37 is
growing greatly and meanwhile the message of sustainability represents a major market
turn. Therewith CRM is coerced toward sustainability to adapt to the market changes.
What is sustainability
’Sustainability has been defined as meeting the needs of the present without compromising the ability of future generations to meet their needs.’ [201]. Base on this concept
there are kinds of definitions in different aspects for sustainability. For instance, ’Sustainability could be defined as an ability or capacity of something to be maintained or
to sustain itself.(Wikipedia)’ Even though, most definitions are defined in environmental,
social, economic context and include:
Living within the limits of what the environment can provide
Understanding the many interconnections between economy, society and the environment
The equal distribution of resources and opportunities [201]
In concept of customer relationships management sustainability means using CRM to
help organizations reducing the cost of business process, increasing revenues, retaining
the long-term customer relationships, providing environmental friendly products or services and fostering the company eco-image.
37
Green marketing is the marketing of products that are presumed to be environmentally safe [200].
It refers to the process of selling products or services based on their environmental benefits, such
products or services themselves are environmentally friendly or their production/packaging process
is in an environmentally friendly way.
518
Approaches to Sustainability
As the next big issue in CRM there are a lot of discussion about how to adapt sustainability on CRM and how to develope a CRM sustainability roadmap. From strategic level
there are a few concepts illustrated: [202]
Long-term customer relationships Long-term customer relationships refer to build customer loyalty and stronger customer relationships in a long term.
Green Product development process Green product development process means to improve products or services regarding specific needs of customers, and turn the value
of sustainability into functional value of the core product.
Carbon footprint business processes Carbon footprint business process will help company to reduce carbon footprints38 , guide customers and employees to reduce carbon footprints, and minimize the costs of energy development. By integrating such
processes in CRM it is possible to take these costs out of the business processes.
Integrate multiple, disparate database Try to integrate multiple, disparate databases
and gain a clear, single customer view for acquisition campaigns, retention and
growth initiatives. As example, Microsoft CRM provides such solution like Microsoft Dynamics NAV and Share point to integrate with the back office applications.
Utilize CRM data Improve the accuracy of the marketing targets with propensity to
get information and life stage segmentation. The more information gathering with
the better segmentation, the better results of marketing and sales will be. The
information gained from customers drives continuous and sustainable innovation
in products, services and even messages.
Digital Marketing Provide opportunity to enhance relationships with customers in the
form of emails, newsletters, SMS messaging, online surveys, automated email acknowledgments and RSS news-feeds. Seek services to make green printing and eservices, such as e-documentation, digital invoicing, e-service requests etc. And
eliminate all paper based discounts including coupons and rebates to implement
paperless discounts.
38
A carbon footprint is ”the total set of greenhouse gas (GHG) emissions caused by an organization,
event, product or person” [203] It is a measure of the impact the activities have on the environment,
and in particular climate change.
519
Drive to eBusiness Make real time and web-based selling available. Prevent customers
from making unnecessary trips by providing up to date in store inventory.
Offer Webversion Apply SaaS39 model for CRM products. With visualization, more
powerful servers and web-based technologies are used, the amount of energy will
be decreased inside the organization.
Open Service portals Open service portals to engage customers in ongoing conversation
about sustainable issues like sustainability goals of customers and occasionally
publish certain related articles for free downloading as well as provide remote
diagnostics for troubleshooting.
Integrate rules in term of sustainability Integrate rules such as regulations and legislation in term of sustainability to improve product performance, marketing performance and company performance, certainly always keep rules updating.
In all forms, sustainability will be a big theme onward and gives a smarter context
for social media. Managing sustainability performance has become a mainstream task in
business, that implies “end-to-end” closed loops to be integrated in CRM. In present-day
there are some CRM vendors providing sustainable solution, such as Microsoft CRM.
39
Saas is software as a service, it is a software delivery method that provides access to software and its
functions remotely as a web-based service. SaaS allows organizations to access business functionality
at low cost. [204]
520
Conclusion
Customer Relationship Management is used in organizations to manage customer relationships proficiently, as a core business strategy it integrates and coordinates all customer
facing processes, channels, and interactions to improve sales, profitability, and customer
satisfaction. A successful CRM helps company to retain the global competitive advantages, maximize the lifetime value of customers, build customer loyalty and reconcile the
economic value of customers to the company with the expectations from the company.
In other words, it facilitates the company to be best at understanding, communicating,
delivering and developing existing customer relationship in addition to creating and keeping new customers. Even though there are many different interpretations of CRM, it
still exists a number of common misunderstandings described below: [192]
CRM is database marketing Database marketing focuses on developing and building
high quality marketing customer databases. It helps company to collect data and
store them in data warehouses for market segmentation, market targeting and
customer communication. CRM is much wider than database marketing, but analytical CRM has the appearance of database marketing.
CRM is a marketing process CRM applications include a lot of functions for marketing
purposes such as customer acquisition, customer retention and customer development(crossselling and up-selling). And the gathered customer-related data is widely used by
different departments not only marketing throughout the company internally and
externally. For insance, operations management use these data to produce customized products and services; human resources use customer preference data to recruit
and train employees for the front-line jobs; research and development management
use them to develop new product.
CRM is an IT issue Many CRM implementations require the deployment of IT solutions. On base of proper IT solutions customer relationships would be improved and
be possible to gather vast amounts of customer data and to analyze, interpret and
utilize it constructively. In fact IT is a part of CRM strategies.
CRM is about loyalty schemes Loyalty schemes are one side of CRM, they play two
roles in CRM implementations which are generating data for customer acquisition,
retention and serving as an exit barrier. In some areas such as food retail, airline
the loyalty schemes are important, but there are a lot of other concerning points
in CRM for other purposes.
521
CRM can be implemented by any company Not all types of CRM can be implemented
by any company, strategic CRM and operational CRM can, but analytical CRM
not. Strategic CRM can be implemented in any company and help the company
to bring the customer into the core of the business by constructing a vision and
strategy. Operational CRM can also be implemented in any company because
each company has marketing or service processes. Analytical CRM is different,
it is based on customer-related data, but not all company concerns these data,
when the data are not available, there is no use of analytical CRM. That is to say,
analytical CRM is specially adapted to those companies who are in close touch
with customers.
Against this background, it is to say, CRM is a technology-enabled approach to manage
customer interface. The purpose of CRM is to increase the acquisition and retention of
profitable customers by building and maintaining appropriate relationships efficiently
and effectively. With the exploration of new technology, customer relationship management will move in the direction of sustainability, software-as-a-service (SaaS), CRM
cloud computing in the near future.
522
Eidesstattliche Erklärung
Hiermit versichern wir an Eides statt diese vorliegende Arbeit ohne unzulässige Hilfe
Dritter und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt zu haben; die aus anderen Quellen direkt oder indirekt übernommen Daten und Konzepte sind
unter Angabe des Literaturzitats gekennzeichnet. Weiterhin versichern wir, dass wir die
allgemeinen Prinzipien wissenschaftlicher Arbeit und Veröffentlichungen, wie sie in den
Leitlinien guter wissenschaftlicher Praxis der Carl von Ossietzky Universität Oldenburg
festgelegt sind, befolgt haben.
Oldenburg, den 5. November 2011
NAME
523
C. Handbücher
nicht fertig.
C.1. Web-Frontend
Einleitung
...
Funktionen
...
Entwicklung von User-Controlls
...
C.2. Agententwicklung
...
2
...
525
3
...
C.3. CRM
Dies ist das Benutzerhandbuch zur Verwendung des Customer Relationship Management
(CRM) - Systems, insbesondere mit Kopplung des Data Warehouses zur Realisierung
komplexer Business Intelligence (BI) - Funktionen. Da Jinengo eine generische Schnittstelle zur Anbindung unterschiedlichster CRM - Systeme besitzt, ist es an dieser Stelle
unmöglich auf alle auf dem Markt existierende Systeme einzugehen. Aus diesem Grund
wird explizit auf das während der Projektphase genutzte Microsoft Dynamics CRM 2011
Online mit dem in Verbindung stehenden Microsoft SQL Server 2008 R2 als Grundlage
für das Data Warehouse eingegangen.
Microsoft Dynamics CRM 2011 Online
Das CRM - System Microsoft Dynamics CRM ist eine webbasierte Geschäftssoftwarelösung,
die es Unternehmen aller Größen ermöglicht,Kunden- oder Clientinteraktionen zu verfolgen und zu verwalten sowie Berichte zu erstellen. Das aktuelle Release der Software
ist Microsoft Dynamics CRM 2011. Microsoft Dynamics CRM erlaubt den Unternehmen, die Software in verschiedener Weise zu installieren und bereitzustellen. Die drei
Bereitstellungsoptionen für Microsoft Dynamics CRM sind folgendermaßen aufgezeigt.
Microsoft Dynamics CRM On Premise Microsoft Dynamics CRM wird von einem Unternehmen vor Ort in seinem lokalen Netzwerk installiert.
Microsoft Dynamics CRM Online Ein Unternehmen verwendet die online bereitgestellte Microsoft Dynamics CRM-Software über das Internet auf Servern, die von Microsoft gehostet werden.
Microsoft Dynamics CRM Partner Hosted Die Software wird in einer Hosting-Umgebung
eines zertifizierten Microsoft-Partners bereitgestellt.
Microsoft Dynamics CRM 2011 untergliedert sich in die drei Teilbereiche Vertriebsfunktionen, Kundendienstfunktionen und Marketingfunktionen.
Stichwortartig werden die Vertriebsfunktionen folgendermaßen beschrieben.
Erstellung einer zentralen und anpassbaren Ansicht von Präferenzen, Beziehungen
und Verkaufshistorie der Kunden, um ihre Bedürfnisse besser zu erkennen und zu
526
erfüllen.
Füllung der Verkaufspläne mit qualifizierten Leads, Verkaufschancen und Angeboten und Aufträgen.
Einsatz der Sofortkampagnen, um neue Produkte an Neu- und Bestandskunden
weiterzuleiten.
Unterstützung und Automatisierung der Stufen des Verkaufsprozesses durch WorkflowRegeln, um Verkaufschance konsistent und effektiv zu steuern.
Einsatz der Analyse- und Berichtswerkzeuge, um Umsätze zu prognostizieren,
Geschäftsaktivitäten und ihre Performance zu messen sowie Trends und Marktchancen zu erkennen.
Die Marketingfunktionen umfassen:
Entwicklung von Marketinglisten mit präzisen Selektionswerkzeugen, um zielgruppengerechte Kundenansprache zu ermöglichen
Erstellung der Marketingkampagnen und -aktivitäten dafür sowie Zugriff auf gespeicherte Kampagnenvorlage
Steuerung der Marketingaktivitäten und -kampagnen für den gesamten Kampagnenzyklus, um mit Kunden effizienter zu kommunizieren und mehr Verkaufschancen in kürzerer Zeit zu qualifizieren.
Berichts- und Analysefunktion zur Beurteilung der Performance jeder Marketingaktion durch Ermittlung der Reaktionsquoten, der Anzahl der gewonnenen Verkaufschancen und der Kosten für die Marketingkampagnen.
Die Servicefunktionen werden folgendermaßen aufgezeigt.
Ab dem ersten Kundenkontakt können die Serviceanforderungen erfasst werden
und sie bis zur Problemlösung verwaltet werden.
Die zur Problemlösung wichtigen Themen werden in einer Wissensdatenbank gespeichert, auf die Service-Mitarbeiter zugreifen können, um auf die individuellen
Kundenwünsche eingehen und auch Fragen beantworten zu können.
Die Serviceanfragen können durch automatische Weiterleitungs- und Eskalationsregeln den richtigen Bereichen zugeordnet und dort ohne großen Zeitverlust behandelt werden.
Die verfügbaren Ressourcen können mithilfe der Einsatzplanung nach Verfügbarkeit,
527
Einsatzort und Know-How für den Kundendienst optimal eingesetzt werden.
Es wird durch die Analyse- und Berichtswerkzeuge ermöglicht, die abgeschlossenen
Serviceanfragen auszuwerten, um ein Gesamtbild der häufig auftretenden Probleme
zu erhalten und die passenden Gegenmaßnahmen zu ergreifen. Darüber hinaus lassen sich die Kundenzufriedenheit, die Fallbearbeitungszeit sowie die Erfolgsquote
nach Erstkontakt in Echtzeit messen.
Erweiterungen
Das CRM System wurde von der Projektgruppe um vier Entitäten erweitert. Diese sind:
Resourcen
Die Entität Resourcen beinhaltet die Attribute cleanValue, URI, Namespace,
Vollständiger Name (Kontakt), Jinengo ID (Kontakt), Kontakt, Erstellt am . Die
Entität beinhaltet alle kontaktrelevanten Daten.
Triples
Die Entität Triples beinhaltet die Attribute Subject, Predicate, Object . Die Entität integriert das Jinengo Ontologie-Modell und dient im Wesentlichen als Datenquelle für das Data Warehouse.
KPIs
Die Entität KPIs beinhaltet die Attribute Kunde, KPI Typ, Kennzahlwert, route ID, time, basic unit . Die Entität persistiert kalkulierte Kennzahlen, die vom
Data Warehouse zum CRM - System zurückgeladen werden.
KPI Typen
Die Entität KPI Typen besitzt die Attribute KPI Typ, KPI URI . Die Entität
dient dem komfortableren Selektieren des KPI Typs während der Berichterstellung.
Weitere individuelle Entitäten können hinzugefügt werden, indem der Menüpunkt “Einstellungen”¿´Ánpassung”-¿´Ánpassungen”-¿´´System anpassen”-¿´Éntitäten”-¿´Ńeu” gewählt
wird. Es öffnet sich ein neues Fenster, wo zunächst Informationen zu der neuen Entität
(Entitätsdefinition) angegeben und gespeichert werden müssen. Die Attribute der Entität können dann über die Navigation unter dem Punkt ´´Felder” definiert werden.
Berichterstellung
... - Berichterstellung im CRM auf Basis zurückgelieferter Werte vom SQL Server in die
KPIs Entität im CRM
528
Microsoft SQL Server 2008 R2 - Enterprise Edition
Die Einsatzbereiche des Microsoft SQL Servers erstrecken sich von Business Intelligence
über Data Warehousing, Applikationsentwicklung, Online Transaction Processing und
Serverkonsolidierung und umfassen damit ein weites Spektrum. Die Vorteile sind im
einzelnen:
Kostenfokus
SQL Server 2008 R2 Enterprise kann Kosten reduzieren, Mehrwert liefern und die
Effizienz im gesamten Unternehmen vorantreiben.
Performance und Skalierbarkeit
Microsoft SQL Server 2008 R2 stellt wachsenden Datenbanken die Tools und Funktionen zur Verfügung, die zur Performanceoptimierung, zum Scale-up einzelner
Server sowie zum Scale-out sehr großer Datenbanken erforderlich sind.
IT Effizienz
Die IT war noch nie so stark gefordert, zusätzliche Mehrwerte innerhalb der Grenzen der bestehenden Budgets und Ressourcen bereitzustellen wie heute. SQL Server
2008 R2 baut auf einer langen Tradition von neuen Tools und Funktionalitäten für
die Produktivität der DBAs und Entwickler auf.
Self-Service BI
SQL Server 2008 R2 wird mit einer Vielzahl von Self-Service Business IntelligenceKomponenten geliefert, die mit vertrauten und intuitiv zu bedienenden Tools die
Reichweite von BI auf das ganze Unternehmen ausdehnen. Dies trägt dazu bei, das
Return-On-Investment zu maximieren und die IT-Effizienz zu steigern.
Hochverfügbarkeit - Always On
Die Always On-Technologien von SQL Server 2008 R2 bieten Ihnen umfassende Möglichkeiten zur Minimierung von Ausfallzeiten und zur Einhaltung Ihres
benötigten Verfügbarkeitslevels.
Sicherheit und Verwaltbarkeit.
Microsoft SQL Server 2008 R2 bietet ein richtlinienbasiertes System zur Verwaltung einer oder mehrerer SQL-Serverinstanzen. Tools zur Performanceüberwachung,
Fehlersuche und Abstimmung ermöglichen es Administratoren, ihre Datenbanken
und SQL Serverinstanzen effizienter zu verwalten.
Dem SQL Server System wurden von der Projektgruppe drei essentielle Datenbanken
hinzugefügt, die zusammen das Data Warehouse bilden. Die drei dem Data Warehouse
zugehörigen Datenbanken sind ´´StagingArea”, ´´Basisdatenbank” und ´´DataWarehouse”,
welche im Folgenden genauer hinsichtlich ihrer Funktion betrachtet werden sollen. Vorerst jedoch soll das Gesamtkonzept einmal visualisiert werden:
529
Abb. C.1.: Jinengo DataWarehouse Konzept
Das operative CRM System stellt Microsoft Dynamics CRM 2011 Online und das Analytische CRM stellt Microsoft SQL Server 2008 R2 Enterprise Edition dar. Die im operativen System anfallenden Daten werden unmittelbar mittels Web-Service in die Datenbank “StagingArea” übertragen, sofern der Ladeprozess im Jinengo Admin Control
Panel angestoßen wurde. Die Abbildung zeigt das Control Panel, wo der Reporting Prozess angestoßen wird:
Es folgt der erste ETL-Prozess, der die Daten aus der “StagingArea” extrahiert, transformiert und die “Basisdatenbank” lädt. Es folgt der zweite ETL-Prozess, der Daten aus
der “Basisdatenbank” extrahiert, transformiert und in die Datenbank “DataWarehouse” lädt. Die “Basisdatenbank” dient hierbei als Daten-Hub für die Datenbank “DataWarehouse”. Von der Datenbank “DataWarehouse” ausgehend werden die kalkulierten
Kennzahlen wieder zurück in das operative System gespeist, um dort entsprechende Berichtgestaltung vornehmen zu können. Das Anstoßen der Übertragung der Kennzahlen
aus dem DataWarehouse zurück zum operativen CRM geschieht ebenfalls über das Jinengo Admin Control Panel. Auch hier soll eine Graphik des Control Panels gezeigt
werden, wo durch Aktualisieren der Kennzahlen entweder ein Kennzahlentyp, zum Beispiel CO2Emission pro Kilometer, oder alle Kennzahlentypen für alle Jinengo Nutzer
zum CRM übertragen werden können:
Nachdem das Gesamtkonzept vorgestellt worden ist, soll nun auf die drei Teilbereiche
´´StagingArea”, ´´Basisdatenbank” und ´´DataWarehouse” eingegangen werden:
StagingArea
Die Datenbank “StagingArea” wird hier nicht graphisch in Form eines ER-Models aufgezeigt, da sie lediglich eine Spiegelung der Entitäten ´ÁktiveResourcen”, ´ÁktiveTriples”
und “JinengoUser” aus dem operativen CRM - System (Microsoft Dynamics CRM 2011
Online) darstellt. Die Daten in der Datenbank “StagingArea” werden nach erfolgreicher Befüllung in die Datenbank “Basisdatenbank” extrahiert, transformiert und geladen
(ETL-Prozess).
Basisdatenbank
Die Datenbank “StagingArea” stellt die Datenquelle für die Datenbank “Basisdatenbank” dar. Der Aufbau der “Basisdatenbank” soll anhand eines ER-Models aufgezeigt
werden, von wo aus der zweite ETL-Prozess zur Datenbank “DataWarehouse” startet:
530
Abb. C.2.: Jinengo Control Panel Reporting
531
532
Abb. C.3.: Jinengo Control Panel KPI
Abb. C.4.: ER-Model Basisdatenbank
533
Gespeicherte Prozeduren In der Datenbank “Basisdatenbank” sind insgesamt vier
relevante Prozeduren gespeichert, die näher betrachtet werden sollen, weil diese beim Anstoßen des Reporting Prozesses im Control Panel ausgeführt werden. Die vier relevanten
Prozeduren sind:
[Basisdatenbank].[dbo].[CREATE BASE DB]
[Basisdatenbank].[dbo].[REMOVE FOREIGN KEY]
[Basisdatenbank].[dbo].[CREATE DW SCD]
[Basisdatenbank].[dbo].[CREATE DW FAKTEN]
[Basisdatenbank].[dbo].[CREATE BASE DB]
Diese Prozedur löscht alle vorhandenen Daten der Datenbank “Basisdatenbank” und
befüllt diese mit aktuellen Daten der Datenbank “StagingArea”. Der Prozedur-Code
sieht wie folgt aus:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Listing C.1: Prozedur CREATE BASE DB
USE [ B a s i s d a t e n b a n k ]
GO
/ * ***** O b j e c t : S t o r e d P r o c e d u r e [ dbo ] . [ CREATE BASE DB]
S c r i p t Date : 08/30/2011 1 5 : 5 0 : 4 5 ***** * /
SET ANSI NULLS ON
GO
SET QUOTED IDENTIFIER ON
GO
−− =============================================
−− Author :
Jinengo
−− C r e a t e d a t e : 2011−08−30
−− D e s c r i p t i o n : Procedure c r e a t e s b a s e DB
−− =============================================
ALTER PROCEDURE [ dbo ] . [ CREATE BASE DB ]
−− Add t h e p a r a m e t e r s f o r t h e s t o r e d p r o c e d u r e h e r e
−− <@Param1 , sysname , @p1> <Datatype For Param1 , , i n t > = <
D e fa u l t V a lu e F o r P a ra m 1 , , 0>,
D e fa u l t V a lu e F o r P a ra m 2 , , 0>
AS
BEGIN
−− SET NOCOUNT ON added t o p r e v e n t e x t r a r e s u l t s e t s FROM
−− i n t e r f e r i n g w i t h SELECT s t a t e m e n t s .
SET NOCOUNT ON;
−− I n s e r t s t a t e m e n t s f o r p r o c e d u r e h e r e
534
24
25
26
27
28
29
30
31
32
33
34
35
36
−− A l l e D a t e n t a b e l l e n z u e r s t ö l s c h e n
DELETE FROM
DELETE FROM
DELETE FROM
DELETE FROM
DELETE FROM
[ Basisdatenbank
[ Basisdatenbank
[ Basisdatenbank
[ Basisdatenbank
[ Basisdatenbank
] . dbo . Subroute ;
] . dbo . Route ;
] . dbo . V e r k e h r s m i t t e l ;
] . dbo . I n t e r e s s e ;
] . dbo . J i n e n g o U s e r ;
−−D a t e n t a b e l l e : J i n e n g o U s e r
INSERT INTO [ B a s i s d a t e n b a n k ] . dbo . J i n e n g o U s e r
( [ J i n e n g o I D ] , [ Name ] , [ S t a d t ] , [LAND] , [ StrASse ] , [ P o s t l e i t z a h l
] , [ Email ] , [ User URI ] )
37 SELECT [ J i n e n g o I D ] , [ Name ] , [ S t a d t ] , [LAND] , [ StrASse ] , [
P o s t l e i t z a h l ] , [ Email ] , [ URI ]
38 FROM [ S t a g i n g A r e a ] . dbo . J i n e n g o U s e r ju , [ S t a g i n g A r e a ] . dbo .
AktiveResourcen ar
39 WHERE j u . J i n e n g o I D = a r . Kontakt ;
40
41 −−D a t e b e n t a b e l l e : I n t e r e s s e
42
43 SELECT S u b j e c t AS ju , Object AS i n t i d INTO #i n t I D
44 FROM [ S t a g i n g A r e a ] . dbo . A k t i v e T r i p l e s
45 WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ u s e r#h A S I n t e r e s t ’ ;
46
47 SELECT S u b j e c t AS i n t i d , Object AS i n t d e s c INTO #i n t d e s c
49 WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ u s e r#h A S D e s c r i p t i o n ’ ;
50
51 SELECT S u b j e c t AS i n t d e s c , Object AS i n t V a l u e INTO #i n t v a l u e
53 WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ u s e r#h A S I n t e n s i t y ’ ;
54
55 INSERT INTO [ B a s i s d a t e n b a n k ] . dbo . I n t e r e s s e ( J i n e n g o I D ,
I n t e r e s s e I D , Bewertung Typ , Bewertung Wert )
56
SELECT j u . J i n e n g o I D , i d . i n t i d , de . i n t d e s c , va . i n t V a l u e
57
FROM [ B a s i s d a t e n b a n k ] . dbo . J i n e n g o U s e r ju , #i n t I D id ,#
i n t d e s c de ,# i n t v a l u e va
58
WHERE j u . User URI = i d . j u AND i d . i n t i d = de . i n t i d AND de .
i n t i d= va . i n t d e s c ;
59
60 / * N u l l −Wert durch 0 e r s e t z e n
535
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
UPDATE [ B a s i s d a t e n b a n k ] . dbo . I n t e r e s s e
SET Bewertung Wert = 0
WHERE Bewertung Wert IS NULL
*/
−−D a t e n t a b e l l e : V e r k e h r s m i t t e l
−− H i l f s t a b e l l e n e r s t e l l e n
SELECT S u b j e c t AS Subroutes , Object AS trID INTO #t r a n s i d
FROM [ S t a g i n g A r e a ] . dbo . A k t i v e T r i p l e s
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ t r a v e l#
useTransportation ’
SELECT s u b j e c t AS trID , OBJECT AS t e r r a i n INTO #t e r r
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ t r a n s p o r t#
hASTransportationTerrain ’
SELECT s u b j e c t AS trID , OBJECT AS name INTO #name
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ t r a n s p o r t#hASName ’
SELECT s u b j e c t AS trID , OBJECT AS po INTO #power
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ t r a n s p o r t#
hASPowerSource ’
SELECT S u b r o u t e s , t . trID , t e r r a i n , name , PO INTO #t r a n s
FROM #t r a n s i d t ,# t e r r t r ,#name n,#power p
WHERE t . trID = t r . trID AND t . trID = n . trID AND t . trID = p .
trID
ORDER BY name
88
89
90 INSERT INTO [ B a s i s d a t e n b a n k ] . dbo . V e r k e h r s m i t t e l (Name , T e r r a i n
, Antrieb )
91 SELECT DISTINCT name , t e r r a i n , po
92 FROM #t r a n s
93
94
95 −−B e r e i t s t e l l u n g ü f r d i e D a t e n t a b e l l e n Route und S u b r o u t e
96
97
SELECT S u b j e c t AS r o u t e s , Object AS s u b r o u t e s INTO #
routeHASSubroute
536
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
WHERE P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#hASSubroute ’ ;
SELECT S u b j e c t AS latiURL , Object INTO #l a t i
WHERE P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#l a t i t u d e ’ ;
SELECT S u b j e c t AS longiURL , Object AS Value INTO #l o n g i
WHERE P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#l o n g i t u d e ’ ;
SELECT a . S u b j e c t AS s u b r o u t e s , b . Value AS d e p a r t l o n g i , c .
Object AS d e p a r t l a t i INTO #d e p a r t I n f o
FROM [ S t a g i n g A r e a ] . dbo . A k t i v e T r i p l e s a , #l o n g i b , #l a t i c
WHERE a . P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#DepartFROM ’ AND
a . Object=b . longiURL AND a . Object=c . latiURL ;
SELECT a . S u b j e c t AS s u b r o u t e s , b . Value AS a r r i v a l l o n g i , c .
Object AS a r r i v a l l a t i INTO #a r r i v a l I n f o
FROM [ S t a g i n g A r e a ] . dbo . A k t i v e T r i p l e s a , #l o n g i b , #l a t i c
WHERE a . P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#h AS De sti na ti on ’
AND a . Object=b . longiURL AND a . Object=c . latiURL ;
SELECT S u b j e c t AS s u b r o u t e , Object AS costURI INTO #c o s t
WHERE P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#hASCost ’ ;
SELECT S u b j e c t AS costValueURI , Object AS c o s t s INTO #
costvalue
FROM S t a g i n g A r e a . dbo . A k t i v e T r i p l e s
WHERE P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#I t C o s t s ’ ;
SELECT S u b j e c t AS s u b r o u t e , Object AS DistanceURI INTO #d i s
WHERE P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#hASDistance ’ ;
SELECT S u b j e c t AS disURI , Object AS d i s t a n c e INTO #d i s v a l u e
WHERE P r e d i c a t e= ’ h t t p : / / j i n e n g o . com/ t r a v e l#D i s t a n c e I s ’ ;
SELECT S u b j e c t AS s u b r o u t e , Object AS seURI INTO #s e
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ t r a v e l#
537
hASSustainabilityEffect ’ ;
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
SELECT S u b j e c t AS seURI , Object AS e m i s s i o n INTO #em
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ s u s t a i n a b i l i t y#
hASEmission ’ ;
SELECT S u b j e c t AS e m i s s i o n , Object AS emValue INTO #emValue
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ s u s t a i n a b i l i t y#
hASEmissionValue ’ ;
SELECT S u b j e c t AS s u b r o u t e , Object AS s t t i m e INTO #s t t i m e
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ t r a v e l#s t a r t D a t e ’ ;
SELECT s u b r o u t e , DATEADD(SECOND,CAST(CAST( s t t i m e AS BIGINT)
/1000 AS INT) , ’ 19700101 ’ ) AS s t a r t t i m e
INTO #s t a r t t i m e
FROM #s t t i m e ;
SELECT S u b j e c t AS s u b r o u t e , Object AS e t i m e INTO #e t i m e
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ t r a v e l#EndDate ’ ;
SELECT s u b r o u t e , DATEADD(SECOND,CAST(CAST( e t i m e AS BIGINT)
/1000 AS INT) , ’ 19700101 ’ ) AS endtime
INTO #endtime
FROM #e t i m e ;
SELECT s . s u b r o u t e ,
t r a v e l t i m e INTO
FROM #s t a r t t i m e s ,
WHERE s . s u b r o u t e =
D a t e d i f f (MINUTE
#t r t i m e
#endtime e
e . subroute ;
, s t a r t t i m e , endtime ) AS
162
163
164
165
SELECT t . S u b r o u t e s AS r i d , name AS transname INTO #t r a n s p o r t
166
FROM #t r a n s t , #routeHASSubroute r
167
WHERE t . s u b r o u t e s = r . s u b r o u t e s
168
169 −− H i l f s t a b e l l e ü f r Route und S u b r o u t e
170
SELECT a . s u b r o u t e s ,
171
a . r o u t e s AS Route ID ,
172
e . d e p a r t l a t i AS S u b r o u t e S t a r t L a t i t u d e ,
538
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
e . d e p a r t l o n g i AS S u b r o u t e S t a r t L o n g i t u d e ,
f . a r r i v a l l a t i AS S u b r o u t e E n d L a t i t u d e ,
f . a r r i v a l l o n g i AS Subroute End Longitude ,
d . d i s t a n c e AS S u b r o u t e D i s t a n z ,
h . c o s t s AS Subroute Kosten ,
v . emValue AS Subroute CO2Emission ,
s t . s t a r t t i m e AS S u b r o u t e S t a r t z e i t ,
e t . endtime AS S u b r o u t e E n d z e i t ,
t t . t r a v e l t i m e AS S u b r o u t e R e i s e z e i t ,
t r . transname AS S u b r o u t e V e r k e h r s m i t t e l
INTO #s u b r o u t e
FROM #routeHASSubroute a , #d e p a r t I n f o e ,# a r r i v a l I n f o f ,# d i s c
,# d i s v a l u e d,# c o s t g ,
#c o s t v a l u e h , #s e s , #em t , #emValue v , #s t a r t t i m e s t , #
endtime et , #t r t i m e t t , #t r a n s p o r t t r
WHERE e . s u b r o u t e s=a . s u b r o u t e s
AND f . s u b r o u t e s=a . s u b r o u t e s
AND c . s u b r o u t e=a . s u b r o u t e s
AND c . DistanceURI=d . disURI
AND g . s u b r o u t e=a . s u b r o u t e s
AND h . costValueURI=g . costURI
AND s . s u b r o u t e = a . s u b r o u t e s
AND t . seURI = s . seURI
AND v . e m i s s i o n = t . e m i s s i o n
AND s t . s u b r o u t e = a . s u b r o u t e s
AND e t . s u b r o u t e = a . s u b r o u t e s
AND t t . s u b r o u t e = a . s u b r o u t e s
AND t r . r i d = a . s u b r o u t e s ;
−−D a t e b e n t a b e l l e : Route
SELECT s u b j e c t AS ju , Object AS r i d INTO #r o u t e
FROM [ S t a g i n g A r e a ] . dbo . A k t i v e T r i p l e s at
WHERE P r e d i c a t e = ’ h t t p : / / j i n e n g o . com/ u s e r#hASRoutes ’ ;
−−SELECT DISTINCT Route ID AS r i d INTO #r o u t e FROM #s u b r o u t e
SELECT Route ID AS r i d ,SUM(CAST( Subroute CO2Emission AS f l o a t ) )
AS re ,
210
SUM(CAST( S u b r o u t e D i s t a n z AS f l o a t ) ) AS rd ,
211
SUM(CAST( S u b r o u t e K o s t e n AS f l o a t ) ) AS rk ,
212
SUM(CAST( S u b r o u t e R e i s e z e i t AS f l o a t ) ) AS f z INTO #t o t a l
539
213 FROM #s u b r o u t e
214 GROUP BY Route ID ;
215
216 SELECT Route ID AS r i d , min( S u b r o u t e S t a r t z e i t ) AS s r t s t , max(
S u b r o u t e E n d z e i t ) AS s r t e t INTO #r t i m e
218 GROUP BY Route ID ;
219
220 SELECT r i d , DATEDIFF(MINUTE, s r t s t , s r t e t ) AS t r t i m e INTO #
traveltime
221 FROM #r t i m e ;
222
223 SELECT b . r i d AS r i d , ( t r t i m e −f z ) AS umsttime INTO #u m s t i e g t i m e
224 FROM #t r a v e l t i m e a , #t o t a l b
225 WHERE a . r i d = b . r i d ;
226
227 SELECT Route ID AS r i d ,MIN( S u b r o u t e S t a r t z e i t ) AS szmin INTO #
szmin
229 GROUP BY Route ID
230
231 SELECT Route ID , S u b r o u t e S t a r t L a t i t u d e AS s t l a ,
S u b r o u t e S t a r t L o n g i t u d e AS s t l o INTO #s t a r t o r t
232 FROM #s u b r o u t e s r t , #szmin s z i
233 WHERE s r t . Route ID = s z i . r i d AND s r t . S u b r o u t e S t a r t z e i t = s z i .
szmin
234
235 SELECT Route ID AS r i d ,MAX( S u b r o u t e S t a r t z e i t ) AS szmax INTO #
szmax
237 GROUP BY Route ID
238
239 SELECT Route ID , S u b r o u t e E n d L a t i t u d e AS e d l a ,
S u b r o u t e E n d L o n g i t u d e AS e d l o INTO #e n d o r t
240 FROM #s u b r o u t e s r t , #szmax s z a
241 WHERE s r t . r o u t e I D = s z a . r i d AND s r t . S u b r o u t e S t a r t z e i t = s z a .
szmax
242
243 −−ü B e f l l u n g Route
244
245 INSERT INTO [ B a s i s d a t e n b a n k ] . dbo . Route ( Jinengo ID , Route ID ,
246
Rou te Di sta nz , Route CO2Emission , Route Kosten , R o u t e F a h r z e i t ,
247
R o u t e S t a r t z e i t , Route Endzeit , R o u t e R e i s e z e i t ,
540
248
249
250
251
252
253
Route Umsteigzeit ,
Route Abfahrt Latitude , Route Abfahrt Longitude ,
Route Ankunft Latitude , Route Ankunft Longitude )
SELECT Jinengo ID , r . r i d , t . rd , t . re , t . rk , t . f z , r t . s r t s t ,
rt . srtet ,
t t . t r t i m e , ut . umsttime , s o . s t l a , s o . s t l o , eo . e d l a , eo . e d l o
FROM [ B a s i s d a t e n b a n k ] . dbo . J i n e n g o U s e r j , #r o u t e r , #t o t a l t
, #s t a r t o r t so ,
#e n d o r t eo , #r t i m e r t , #t r a v e l t i m e t t , #u m s t i e g t i m e ut
WHERE j . User URI = r . j u
AND t . r i d = r . r i d
AND r t . r i d = r . r i d
AND t t . r i d = r . r i d
AND ut . r i d = r . r i d
AND s o . Route ID = r . r i d
AND eo . Route ID = r . r i d ;
254
255
256
257
258
259
260
261
262
263 −−ü B e f l l u n g S u b r o u t e
264
265 INSERT INTO [ B a s i s d a t e n b a n k ] . dbo . Subroute
266
( Subroute ID , Route ID ,
267
Subroute Start Latitude , Subroute Start Longitude ,
268
Subroute End Latitude , Subroute End Longitude ,
269
S u b r o u t e D i s t a n z , S u b r o u t e K o s t e n , Subroute CO2Emission ,
270
S u b r o u t e S t a r t z e i t , Subroute Endzeit , Subroute Reisezeit ,
Subroute Verkehrsmittel )
271
272
SELECT *
273
FROM #s u b r o u t e
274
WHERE Route ID IN (SELECT Route ID FROM [ B a s i s d a t e n b a n k ] .
dbo . Route )
275
276 −−Drop Ta bl e
277
278 −− H i l f s t a b e l l e n ü f r I n t e r e s s e
279 DROP TABLE #intID , #i n t d e s c , #i n t v a l u e ;
280
281 −− H i l f s t a b e l l e n ü f r V e r k e h r s m i t t e l
282 DROP TABLE #t r a n s i d ,# t e r r ,#name ,#power , #t r a n s
283
284 −− H i l f s t a b e l l e n ü f r Route
285 DROP TABLE #r o u t e , #t o t a l , #s t a r t o r t , #endort ,
541
286 #rtime , #t r a v e l t i m e , #umstiegtime , #szmin , #szmax
287
288 −− H i i l f s t a b e l l e n ü f r S u b r o u t e
289 DROP TABLE
290
#routeHASSubroute ,# d i s ,# d i s v a l u e ,# l a t i ,# l o n g i ,# d e p a r t I n f o ,#
a r r i v a l I n f o ,# c o s t ,# c o s t v a l u e ,
291
#se , #em , #emValue , #s t t i m e , #etime , #s t a r t t i m e , #endtime , #
t r t i m e , #t r a n s p o r t , #s u b r o u t e
292
293 END
textbf[Basisdatenbank].[dbo].[REMOVE FOREIGN KEY]
Diese Prozedur hat die Funktion eines technischen Workarounds zur Realisierung des
Konzeptes Slowly Changing Dimensions mit dem Typ 2. Die Prozedur löscht temporär
alle Foreign Keys der Entitäten “Jinengo User”, “Interesse”, “Route”, “Subroute”. Der
Prozedur-Code sieht wie folgt aus:
Listing C.2: Prozedur REMOVE FOREIGN KEY
1 USE [ B a s i s d a t e n b a n k ]
2 GO
3 / * ***** O b j e c t : S t o r e d P r o c e d u r e [ dbo ] . [ REMOVE FOREIGN KEY]
S c r i p t Date : 08/30/2011 1 5 : 4 2 : 3 1 ***** * /
4 SET ANSI NULLS ON
5 GO
6 SET QUOTED IDENTIFIER ON
7 GO
8 −− =============================================
9 −− Author :
Jinengo
10 −− C r e a t e d a t e : 2011−08−30
11 −− D e s c r i p t i o n : Procedure removes f o r e i g n k e y s
12 −− =============================================
13 ALTER PROCEDURE [ dbo ] . [ REMOVE FOREIGN KEY]
14
15
16
17 AS
18 BEGIN
19
20 −−öLsche F o r e i g n Key J i n e n g o U s e r
21 ALTER TABLE [ Datawarehouse ] . dbo . KundenKennzahlen
22 DROP CONSTRAINT FK KundenKennzahlen Jinengo User
542
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
ALTER TABLE [ Datawarehouse ] . dbo . RoutenKennzahlen
DROP CONSTRAINT FK ROUTENKE RELATIONS JU
ALTER TABLE [ Datawarehouse ] . dbo . SubroutenKennzahlen
DROP CONSTRAINT FK SRouteKE RELATIONS JU
−−öLsche F o r e i g n Key I n t e r e s s e
ALTER TABLE [ Datawarehouse ] . dbo . KundenKennzahlen
DROP CONSTRAINT FK KundenKennzahlen Interesse
DROP CONSTRAINT FK ROUTENKE RELATIONS INTERESS
DROP CONSTRAINT FK SRouteKE RELATIONS INTE
−−öLsche F o r e i g n Key Route
DROP CONSTRAINT FK ROUTENKE RELATIONS ROUTE
−−öLsche F o r e i g n Key S u b r o u t e
DROP CONSTRAINT FK SRouteKE RELATIONS SUBR
END
textbf[Basisdatenbank].[dbo].[CREATE DW SCD]
Diese Prozedur erstellt das Slowly Changing Dimensions (SCD) Konzept mit dem Typ 2
und fügt die zuvor entfernten Fremdschlüssel-Beziehungen wieder hinzu. Das bedeutet,
dass Historisierungen der Entitäten “Jinengo User”, “Interesse”, “Route” und “Subroute” vorgenommen werden. Der Prozess der Historisierung des SCD Typs 2 funktioniert
so, dass die entsprechenden Entitäten um drei weitere Attribute ergänzt werden, nämlich
“GueltigVon”, “GueltigBis” und “GueltigStatus”. Wird die jeweilige Entität erstmals
befüllt, so erhalten die drei Attribute in der genannten Reihenfolge die Werte ’Datum
des Ladeprozesses’, ’NULL’ und ’Aktiv’. Wird die jeweilige Entität nochmals befüllt
und sollte sich ein Datensatz ändern, so wird dieser nun in der Form historisiert, dass
der vorhandene Datensatz zunächst bestehen bleibt, aber die Attribute “GueltigBis”
und “GueltigStatus” mit den Werten ’Datum des neuen Ladeprozesses’ und ’Inaktiv’
gesetzt werden. Zusätzlich wird der zughörige neuere Datensatz übernommen, wobei
die Attribute “GueltigVon”, “GueltigBis” und “GueltigStatus” nun die Werte ’Datum
des Ladeprozesses’, ’NULL’ und ’Aktiv’ bekommen. Der Wert ’Null’ bedeutet, dass der
Datensatz solange gültig ist, bis eine Änderung an diesem Datensatz vorgenommen wird.
543
Listing C.3: Prozedur CREATE DW SCD
2 GO
3 / * ***** O b j e c t : S t o r e d P r o c e d u r e [ dbo ] . [ CREATE DW SCD]
S c r i p t Date : 08/30/2011 1 6 : 0 5 : 5 7 ***** * /
4 SET ANSI NULLS ON
5 GO
7 GO
8 −− =============================================
9 −− Author :
Jinengo
10 −− C r e a t e d a t e : 2011−08−30
11 −− D e s c r i p t i o n : Procedure c r e a t e s SCD f o r DW
12 −− =============================================
13 ALTER PROCEDURE [ dbo ] . [ CREATE DW SCD]
14
15
16
17 AS
18 BEGIN
19
20 −−J i n e n g o U s e r
21
22 INSERT INTO [ DataWarehouse ] . dbo . J i n e n g o U s e r ( Jinengo ID , Name ,
GueltigVon , G u e l t i g S t a t u s )
23
24
SELECT j J i n e n g o I D , jUserName ,SYSDATETIME( ) , ’ Aktiv ’
25
26
FROM
27
28
( MERGE [ DataWarehouse ] . dbo . J i n e n g o U s e r du
29
30
USING [ B a s i s d a t e n b a n k ] . dbo . J i n e n g o U s e r bu
31
32
ON du . j i n e n g o i d = bu . j i n e n g o i d
33
34
WHEN MATCHED AND du . G u e l t i g S t a t u s = ’ Aktiv ’ AND ( du . Name
<> bu . Name) THEN
35
36
UPDATE SET du . G u e l t i g B i s = SYSDATETIME( ) , du .
GueltigStatus = ’ Inaktiv ’
544
37
38
39
40
41
42
43
44
45
WHEN NOT MATCHED THEN
INSERT ( Jinengo ID , Name , GueltigVon , G u e l t i g S t a t u s )
VALUES ( bu . Jinengo ID , bu . Name ,SYSDATETIME( ) , ’ Aktiv ’ )
WHEN NOT MATCHED BY SOURCE AND du . G u e l t i g S t a t u s = ’ Aktiv ’
THEN
UPDATE SET du . G u e l t i g B i s = SYSDATETIME( ) , du .
G u e l t i g S t a t u s = ’ ö G e l s c h t ’
46
47
OUTPUT bu . Jinengo ID , bu . Name , $ACTION
48
49
) CHANGES ( j J i n e n g o I D , jUserName , ChangeAction )
50
51
WHERE ChangeAction = ’UPDATE ’ and j J i n e n g o I D IS NOT NULL
52
53 −−I n t e r e s s e
54
55
−− H i l f s t a b e l l e n e r s t e l l e n
56
SELECT j i n e n g o i d AS j i d , b e w e r t u n g w e r t AS d i s INTO #d i s
57
FROM [ B a s i s d a t e n b a n k ] . dbo . I n t e r e s s e
58
WHERE Bewertung Typ = ’ d i s t a n c e ’ ;
59
60
SELECT j i n e n g o i d AS j i d , b e w e r t u n g w e r t AS s u s INTO #s u s
61
62
WHERE Bewertung Typ = ’ s u s t a i n a b i l i t y ’ ;
63
64
SELECT j i n e n g o i d AS j i d , b e w e r t u n g w e r t AS c o s t INTO #c o s t
65
66
WHERE Bewertung Typ = ’ c o s t s ’ ;
67
68
SELECT j i n e n g o i d AS j i d , b e w e r t u n g w e r t AS tim INTO #tim
69
70
WHERE Bewertung Typ = ’ time ’ ;
71
72
SELECT j i n e n g o i d AS j i d , b e w e r t u n g w e r t AS s r t INTO #s r t
73
74
WHERE Bewertung Typ = ’ s u b r o u t e s ’ ;
75
76
SELECT j i n e n g o i d AS j i d , b e w e r t u n g w e r t AS t r a INTO #t r a
77
545
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
WHERE Bewertung Typ = ’ T r a n s p o r t a t i o n ’ ;
SELECT j i n e n g o i d , s u s AS N a c h h a l t i g k e i t , tim AS Z e i t ,
c o s t AS Kosten , s r t AS Subroute , d i s AS Distanz ,
t r a AS T r a n s p o r t a t i o n INTO #i n t e
FROM [ B a s i s d a t e n b a n k ] . dbo . J i n e n g o U s e r j u
l e f t outer j o i n #s u s s ON j u . j i n e n g o i d = s . j i d
l e f t outer j o i n #tim t ON j u . j i n e n g o i d = t . j i d
l e f t outer j o i n #c o s t c ON j u . j i n e n g o i d = c . j i d
l e f t outer j o i n #s r t s r ON j u . j i n e n g o i d = s r . j i d
l e f t outer j o i n #d i s d ON j u . j i n e n g o i d = d . j i d
l e f t outer j o i n #t r a t r ON j u . j i n e n g o i d = t r . j i d ;
−− NULL−Wert durch 16 e r s e t z e n , w e l c h e nun den NULL−Wert
ä r e p r s e n t i e r t
UPDATE #i n t e
SET N a c h h a l t i g k e i t = 16
WHERE N a c h h a l t i g k e i t IS NULL
94
95
96
97
98
UPDATE #i n t e
99
SET Z e i t = 16
100
WHERE Z e i t IS NULL
101
102
UPDATE #i n t e
103
SET Kosten = 16
104
WHERE Kosten IS NULL
105
106
UPDATE #i n t e
107
SET Subroute = 16
108
WHERE Subroute IS NULL
109
110
UPDATE #i n t e
111
SET D i s t a n z = 16
112
WHERE D i s t a n z IS NULL
113
114
UPDATE #i n t e
115
SET T r a n s p o r t a t i o n = 16
116
WHERE T r a n s p o r t a t i o n IS NULL
117
118
119 INSERT INTO [ DataWarehouse ] . dbo . I n t e r e s s e ( Jinengo ID ,
546
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
Nachhaltigkeit , Zeit ,
Kosten , Subroute , Distanz , T r a n s p o r t a t i o n , GueltigVon ,
GueltigStatus )
SELECT i J i n e n g o I D , i N a c h h a l t i g k e i t , i Z e i t , iKosten ,
iSubroute , iDistanz ,
i T r a n s p o r t a t i o n , SYSDATETIME( ) , ’ Aktiv ’
FROM
( MERGE [ DataWarehouse ] . dbo . I n t e r e s s e d i
USING #i n t e b i
ON d i . j i n e n g o i d = b i . j i n e n g o i d
WHEN MATCHED AND d i . G u e l t i g S t a t u s = ’ Aktiv ’ AND
( d i . N a c h h a l t i g k e i t <> b i . N a c h h a l t i g k e i t OR d i . Z e i t <>
b i . Z e i t OR
d i . Kosten <> b i . Kosten OR d i . Subroute <> b i . Subroute OR
d i . D i s t a n z <> b i . D i s t a n z OR d i . T r a n s p o r t a t i o n <> b i .
T r a n s p o r t a t i o n ) THEN
UPDATE SET d i . G u e l t i g B i s = SYSDATETIME( ) , d i .
INSERT ( Jinengo ID , N a c h h a l t i g k e i t , Z e i t , Kosten ,
Subroute , Distanz ,
T r a n s p o r t a t i o n , GueltigVon , G u e l t i g S t a t u s )
VALUES ( b i . Jinengo ID , b i . N a c h h a l t i g k e i t , b i . Z e i t , b i .
Kosten , b i . Subroute ,
b i . Distanz , b i . T r a n s p o r t a t i o n ,SYSDATETIME( ) , ’ Aktiv ’ )
WHEN NOT MATCHED BY SOURCE AND d i . G u e l t i g S t a t u s = ’ Aktiv ’
THEN
UPDATE SET d i . G u e l t i g B i s = SYSDATETIME( ) , d i .
OUTPUT b i . Jinengo ID , b i . N a c h h a l t i g k e i t , b i . Z e i t , b i .
Kosten ,
547
b i . Subroute , b i . Distanz , b i . T r a n s p o r t a t i o n , $ACTION
152
153
154
) CHANGES ( i J i n e n g o I D , i N a c h h a l t i g k e i t , i Z e i t , iKosten ,
i S u b r o u t e , i D i s t a n z , i T r a n s p o r t a t i o n , ChangeAction )
155
156
WHERE ChangeAction = ’UPDATE ’ and i J i n e n g o I D IS NOT NULL
157
158
−− H i l f s t a b e l l e n w i e d e r ö l s c h e n
159
DROP TABLE #c o s t ,# d i s ,# s r t ,# s u s ,#tim ,# t r a , #i n t e ;
160
161 −−Route
162
163 INSERT INTO [ DataWarehouse ] . dbo . Route ( Route ID , Distanz ,
Kosten , CO2Emission ,
164
R e i s e z e i t , U m s t i e g z e i t , F a h r z e i t , Jinengo ID , Abfahrt ,
Ankunft , GueltigVon , G u e l t i g S t a t u s )
165
166
SELECT rRoute ID , r D i s t a n z , rKosten , rCO2Emission , r R e i s e z e i t
, rUmstiegzeit ,
167
r F a h r z e i t , r J i n e n g o I D , rAbfahrt , rAnkunft , SYSDATETIME( ) ,
’ Aktiv ’
168
169
FROM
170
171
( MERGE [ DataWarehouse ] . dbo . Route dr
172
173
USING [ B a s i s d a t e n b a n k ] . dbo . Route br
174
175
ON dr . r o u t e i d = br . r o u t e i d
176
177
WHEN MATCHED AND dr . G u e l t i g S t a t u s = ’ Aktiv ’ AND
178
179
( dr . D i s t a n z <> br . R o u t e D i s t a n z OR
180
dr . Kosten <> br . Route Kosten OR
181
dr . CO2Emission <> br . Route CO2Emission OR
182
dr . R e i s e z e i t <> br . R o u t e R e i s e z e i t OR
183
dr . U m s t i e g z e i t <> br . R o u t e U m s t e i g z e i t OR
184
dr . F a h r z e i t <> br . R o u t e F a h r z e i t OR
185
dr . J i n e n g o I D <> br . J i n e n g o I D OR
186
dr . Abfahrt <> br . Route Abfahrt
187
OR dr . Ankunft <> br . Route Ankunft ) THEN
188
189
UPDATE SET dr . G u e l t i g B i s = SYSDATETIME( ) , dr .
548
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
INSERT ( Route ID , Distanz , Kosten , CO2Emission ,
Reisezeit , Umstiegzeit ,
F a h r z e i t , Jinengo ID , Abfahrt , Ankunft , GueltigVon ,
GueltigStatus )
VALUES ( br . Route ID , br . R out e Di sta nz , br . Route Kosten ,
br . Route CO2Emission ,
br . R o u t e R e i s e z e i t , br . R o u t e U m s t e i g z e i t , br .
R o u t e F a h r z e i t , br . Jinengo ID ,
br . Route Abfahrt , br . Route Ankunft ,SYSDATETIME( ) , ’
Aktiv ’ )
WHEN NOT MATCHED BY SOURCE AND dr . G u e l t i g S t a t u s = ’ Aktiv ’
THEN
UPDATE SET dr . G u e l t i g B i s = SYSDATETIME( ) , dr .
OUTPUT br . Route ID , br . Rout e Di sta nz , br . Route Kosten , br
. Route CO2Emission ,
br . R o u t e R e i s e z e i t , br . R o u t e U m s t e i g z e i t , br .
R o u t e F a h r z e i t , br . Jinengo ID ,
br . Route Abfahrt , br . Route Ankunft , $ACTION
) CHANGES ( rRoute ID , r D i s t a n z , rKosten , rCO2Emission ,
rReisezeit , rUmstiegzeit ,
r F a h r z e i t , r J i n e n g o I D , rAbfahrt , rAnkunft , ChangeAction )
208
209
210
WHERE ChangeAction = ’UPDATE ’ and rRoute ID IS NOT NULL
211
212 −−S u b r o u t e
213
214 INSERT INTO [ DataWarehouse ] . dbo . Subroute ( Subroute ID , Route ID
, Verkehrmitteltyp ,
215
Anbiete r , D i s t a n z , Kosten , CO2Emission , F a h r z e i t , Abfahrt ,
Ankunft , GueltigVon , G u e l t i g S t a t u s )
216
217
SELECT sSubroute ID , sRoute ID , s S u b r o u t e V e r k e h r s m i t t e l ,
sSubroute Anbieter ,
218
s S u b r o u t e D i s t a n z , s S u b r o u t e K o s t e n , sSubroute CO2Emission ,
549
219
s S u b r o u t e R e i s e z e i t , s S u b r o u t e S t a r t , sSubroute End ,
SYSDATETIME( ) , ’ Aktiv ’
220
221
222
223
224
225
226
227
228
229
230
FROM
( MERGE [ DataWarehouse ] . dbo . Subroute ds
USING [ B a s i s d a t e n b a n k ] . dbo . Subroute bs
ON ds . S u b r o u t e i d = bs . S u b r o u t e i d
WHEN MATCHED AND ds . G u e l t i g S t a t u s = ’ Aktiv ’ AND
( ds . Route ID <> bs . Route ID OR ds . V e r k e h r m i t t e l t y p <>
bs . S u b r o u t e V e r k e h r s m i t t e l OR
ds . A n b i e t e r <> bs . S u b r o u t e A n b i e t e r OR ds . D i s t a n z <> bs
. S u b r o u t e D i s t a n z OR
ds . Kosten<>bs . S u b r o u t e K o s t e n OR ds . CO2Emission <> bs .
Subroute CO2Emission OR
ds . F a h r z e i t <> bs . S u b r o u t e R e i s e z e i t OR ds . Abfahrt <>
bs . S u b r o u t e S t a r t OR
ds . Ankunft<>bs . Subroute End ) THEN
231
232
233
234
235
236
UPDATE SET ds . G u e l t i g B i s = SYSDATETIME( ) , ds .
237
238
239
240
INSERT ( Subroute ID , Route ID , V e r k e h r m i t t e l t y p ,
Anbi eter , Distanz , Kosten , CO2Emission ,
F a h r z e i t , Abfahrt , Ankunft , GueltigVon , G u e l t i g S t a t u s
)
VALUES ( bs . Subroute ID , bs . Route ID , bs .
Subroute Verkehrsmittel ,
bs . S u b r o u t e A n b i e t e r , bs . S u b r o u t e D i s t a n z , bs .
Subroute Kosten , bs . Subroute CO2Emission ,
bs . S u b r o u t e R e i s e z e i t , bs . S u b r o u t e S t a r t , bs .
Subroute End ,SYSDATETIME( ) , ’ Aktiv ’ )
241
242
243
244
245
246
WHEN NOT MATCHED BY SOURCE AND ds . G u e l t i g S t a t u s = ’ Aktiv ’
THEN
247
248
UPDATE SET ds . G u e l t i g B i s = SYSDATETIME( ) , ds .
550
249
250
251
252
253
254
255
256
OUTPUT bs . Subroute ID , bs . Route ID , bs .
Subroute Verkehrsmittel ,
bs . S u b r o u t e A n b i e t e r , bs . S u b r o u t e D i s t a n z , bs .
Subroute Kosten , bs . Subroute CO2Emission ,
bs . S u b r o u t e R e i s e z e i t , bs . S u b r o u t e S t a r t , bs .
Subroute End , $ACTION
) CHANGES ( sSubroute ID , sRoute ID ,
sSubroute Verkehrsmittel ,
sSubroute Anbieter , sSubroute Distanz , sSubroute Kosten
, sSubroute CO2Emission ,
s S u b r o u t e R e i s e z e i t , s S u b r o u t e S t a r t , sSubroute End ,
ChangeAction )
257
258
WHERE ChangeAction = ’UPDATE ’ and s S u b r o u t e I D IS NOT NULL
259
260 −−Dimension : Z e i t
261
262 DECLARE @Von s m a l l d a t e t i m e ,
263
@bis s m a l l d a t e t i m e ,
264
@Quartal integer ,
265
@i integer ,
266
@Jahr integer ,
267
@Date Date
268 BEGIN
269
SET @i = 1
270
SELECT @Von = MAX(Datum) FROM [ DataWarehouse ] . dbo . Z e i t
271
SELECT @Date = max( R o u t e E n d z e i t ) FROM [ B a s i s d a t e n b a n k ] . dbo .
Route ;
272
273
IF @Von i s null
274
SET @Von= ’ 3 0 . 0 6 . 2 0 1 1 ’
275
276
IF @Date > GETDATE( )
277
SELECT @bis= @Date
278
ELSE
279
SELECT @bis= g e t d a t e ( )
280
281
WHILE @Von+@i <= @bis+1
282
BEGIN
283
SET @Quartal = (month(@Von+@i ) −1)/3 + 1 ;
284
SET @Jahr = year (@Von+@i ) ;
551
285
286
287
288
289
290
291
292
293
294
INSERT INTO [ DataWarehouse ] . dbo . ZEIT VALUES( @Jahr , @Quartal
, month(@Von+@i ) ,
CONVERT( Date , @Von+@i , 1 1 2 ) )
SET @i = @i + 1 ;
END
END
−−Re−Add FOREIGN KEY JinengoUser
ALTER TABLE [ Datawarehouse ] . dbo . Kundenkennzahlen
ADD CONSTRAINT FK KundenKennzahlen Jinengo User
FOREIGN KEY ( JU SK ) REFERENCES [ Datawarehouse ] . dbo . J i n e n g o U s e r
( JU SK )
295
296 ALTER TABLE [ Datawarehouse ] . dbo . Routenkennzahlen
297 ADD CONSTRAINT FK ROUTENKE RELATIONS JU
298 FOREIGN KEY ( JU SK ) REFERENCES [ Datawarehouse ] . dbo . J i n e n g o U s e r
( JU SK )
299
300 ALTER TABLE [ Datawarehouse ] . dbo . S u b r o u t e n k e n n z a h l e n
301 ADD CONSTRAINT FK SRouteKE RELATIONS JU
302 FOREIGN KEY ( JU SK ) REFERENCES [ Datawarehouse ] . dbo . J i n e n g o U s e r
( JU SK )
303
304 −−Re−Add FOREIGN KEY I n t e r e s s e
305 ALTER TABLE [ Datawarehouse ] . dbo . Kundenkennzahlen
306 ADD CONSTRAINT FK KundenKennzahlen Interesse
307 FOREIGN KEY ( I n t e r e s s e S K ) REFERENCES [ Datawarehouse ] . dbo .
Interesse ( Interesse SK )
308
310 ADD CONSTRAINT FK ROUTENKE RELATIONS INTERESS
312
313 ALTER TABLE [ Datawarehouse ] . dbo . S u b r o u t e n k e n n z a h l e n
314 ADD CONSTRAINT FK SRouteKE RELATIONS INTE
316
317 −−Re−Add FOREIGN KEY Route
319 ADD CONSTRAINT FK ROUTENKE RELATIONS ROUTE
320 FOREIGN KEY ( Route SK ) REFERENCES [ Datawarehouse ] . dbo . Route (
552
Route SK )
321
322
323
324
325
−−Re−Add FOREIGN KEY S u b r o u t e
ALTER TABLE [ Datawarehouse ] . dbo . S u b r o u t e n k e n n z a h l e n
ADD CONSTRAINT FK SRouteKE RELATIONS SUBR
FOREIGN KEY ( Subroute SK ) REFERENCES [ Datawarehouse ] . dbo .
Subroute ( Subroute SK )
326
327 END
textbf[Basisdatenbank].[dbo].[CREATE DW FAKTEN]
Diese Prozedur hat die Funktion die Faktentabellen “KundenKennzahlen”, “Routenkennzahlen” und “SubroutenKennzahlen” zu befüllen. Hierzu werden die im GalaxieSchema vorhandenen Faktentabellen gelöscht und anschließend auf Basis des DatenHubs der Datenbanktabelle “Basisdatenbank” befüllt. Der Prozedur-Code ist wie folgt
definiert:
Listing C.4: Prozedur CREATE DW FAKTEN
2 GO
3 / * ***** O b j e c t : S t o r e d P r o c e d u r e [ dbo ] . [ CREATE DW FAKTEN]
S c r i p t Date : 08/30/2011 1 5 : 4 5 : 4 8 ***** * /
4 SET ANSI NULLS ON
5 GO
7 GO
8 −− =============================================
9 −− Author :
Jinengo
10 −− Create d a t e : 2011−08−30
11 −− D e s c r i p t i o n : Procedure c r e a t e s KPIs f o r DW
12 −− =============================================
13 ALTER PROCEDURE [ dbo ] . [ CREATE DW FAKTEN]
14
15
Defa u l t V a lu e F o r P a ra m 1 , , 0>,
16
Defa u l t V a lu e F o r P a ra m 2 , , 0>
17 AS
18 BEGIN
19
20 −−F a k t e n t a b e l l e n ö l s c h e n
21 DELETE FROM [ DataWarehouse ] . dbo . KundenKennzahlen ;
22 DELETE FROM [ DataWarehouse ] . dbo . Routenkennzahlen ;
553
23 DELETE FROM [ DataWarehouse ] . dbo . SubroutenKennzahlen ;
24
25
26 −− Fakten : Route
27 INSERT INTO [ DataWarehouse ] . dbo . RoutenKennzahlen
28
SELECT Route SK , Zeit SK , JU SK , I n t e r e s s e S K ,
29
r . CO2Emission , r . Kosten , R e i s e z e i t , U m s t i e g z e i t , F a h r z e i t , r .
Distanz
30
FROM [ DataWarehouse ] . dbo . J i n e n g o U s e r ju ,
31
[ DataWarehouse ] . dbo . Route r ,
32
[ DataWarehouse ] . dbo . Z e i t z ,
33
[ DataWarehouse ] . dbo . I n t e r e s s e i ,
34
[ B a s i s d a t e n b a n k ] . dbo . Route br
35
WHERE j u . J i n e n g o I D = r . J i n e n g o I D
36
AND j u . J i n e n g o I D = i . J i n e n g o I D
37
AND r . Route ID = br . Route ID
38
AND CONVERT( Date , z . Datum , 1 1 2 ) = CONVERT( date , br .
Route Endzeit , 1 1 2 )
39
AND j u . G u e l t i g S t a t u s = ’ Aktiv ’
40
AND r . G u e l t i g S t a t u s = ’ Aktiv ’
41
AND i . G u e l t i g S t a t u s = ’ Aktiv ’
42
43
44 −−Fakten : S u b r o u t e
45 INSERT INTO [ DataWarehouse ] . dbo . SubroutenKennzahlen
46
SELECT JU SK , I n t e r e s s e S K , Zeit SK , Subroute SK , s r .
CO2Emission ,
47
s r . Kosten , s r . F a h r z e i t , s r . Distanz , s r . V e r k e h r m i t t e l t y p ,
sr . Anbieter
48
49
[ DataWarehouse ] . dbo . Subroute s r ,
50
51
52
[ B a s i s d a t e n b a n k ] . dbo . Subroute bsr ,
53
54
WHERE s r . Subroute ID = b s r . Subroute ID
55
AND s r . Route ID = b s r . Route ID
56
AND br . Route ID = b s r . Route ID
57
AND j u . J i n e n g o I D = br . J i n e n g o I D
58
59
AND CONVERT( Date , z . Datum , 1 1 2 ) = CONVERT( date , b s r .
Subroute Endzeit , 112)
60
554
61
AND s r . G u e l t i g S t a t u s = ’ Aktiv ’
62
63
64
65 −−Fakten : Kunden
66
67 INSERT INTO [ DataWarehouse ] . dbo . KundenKennzahlen
68
SELECT JU SK , I n t e r e s s e S K , Zeit SK ,
69
Round ( (sum( CO2Emission ) /sum( r . D i s t a n z ) * 1 0 0 0 ) , 2 ) ,
70
Round (sum( r . Kosten ) /sum( r . D i s t a n z / 1 0 0 0 ) , 2 ) ,
71
Round (sum( U m s t i e g z e i t ) /sum( R e i s e z e i t ) * 1 0 0 , 2 ) ,
72
Round (sum( r . D i s t a n z / 1 0 0 0 ) /sum( R e i s e z e i t / 6 0 ) , 2 )
73
74
[ DataWarehouse ] . dbo . Route r ,
75
76
77
78
WHERE j u . J i n e n g o I D = r . J i n e n g o I D
79
80
AND r . Route ID = br . Route ID
81
AND CONVERT( Date , z . Datum , 1 1 2 ) = CONVERT( Date , GETDATE( ) ,
112)
82
83
AND r . G u e l t i g S t a t u s = ’ Aktiv ’
84
85
GROUP BY j u . JU SK , I n t e r e s s e S K , Zeit SK
86
87 END
DataWarehouse
Die Datenbank “DataWarehouse” bezieht ihre Daten von dem Daten-Hub “Basisdatenbank”.
Der Aufbau der Datenbank ist durch die Strukur eines Galaxie-Schemas charakterisiert
und soll anhand eines ER-Models aufgezeigt werden:
555
Abb. C.5.: ER-Model Datawarehouse
556
D. Sonstiges
nicht fertig.
D.1. Jinengo Datenschutzbestimmungen
Ihr Vertrauen in den korrekten Umgang mit Ihren Daten ist für Jinengo eine wichtige Grundvoraussetzung. Aus diesem Grund stellt der Schutz Ihrer Daten eine große
Bedeutung für Jinengo dar. Die Erhebung, Verarbeitung (umfasst die Speicherung,
Veränderung, Übermittlung, Sperrung und Löschung) und Nutzung Ihrer Daten geschieht ausschließlich unter Beachtung der geltenden datenschutzrechtlichen Vorschriften.
Die Informationen über die Erhebung, Verarbeitung und Nutzung Ihrer Daten sollen
durch die im Folgenden benannten einzelnen Themen dargelegt werden:
1. Datenvermeidung und Datensparsamkeit 2. Zulässigkeit der Datenerhebung, -verarbeitung
und -nutzung 2.1 Identität Jinengos 2.2 Erhebung, Verarbeitung und Nutzung von
personenbezogenen Daten 2.3 Erhebung, Verarbeitung und Nutzung von Nutzungsdaten 2.4 Kategorien von nicht direkt ersichtlichen Beteiligten 3. Weitergabe Ihrer Daten 4. Änderung Ihrer Daten und Widerruf 5. Datensicherheit und Datengeheimnis 6.
Änderung der Datenschutzbestimmungen
Der Endnutzer sei im folgenden mit Jinengo Nutzer bezeichnet. Kategorien von nicht
direkt ersichtlichen Beteiligten sei im folgenden ein Synonym für mit Jinengo kooperierende bzw. an Jinengo beteiligte Unternehmen.
1. Datenvermeidung und Datensparsamkeit
Jinengo erhebt, speichert, verändert und übermittelt die minimale Menge an personenbezogenen Daten und nutzt diese soweit sie für die eigenen Geschäftszwecke notwendig
sind, sofern das schutzwürdige Interesse des Jinengo Nutzers bezüglich der Verarbeitung
und Nutzung gewahrt wird.
557
2. Zulässigkeit der Datenerhebung, -verarbeitung und -nutzung
Die Erhebung, Verarbeitung und Nutzung von personenbezogenen und Nutzungs-Daten
findet beim Jinengo Nutzer statt, indem dieser über die Identität Jinengos, die Erhebung,
Verarbeitung und Nutzung seiner personenbezogenen Daten, die Erhebung, Verarbeitung und Nutzung seiner Nutzungsdaten und Kategorien von nicht direkt ersichtlichen
Beteiligten informiert wird.
Durch die Registrierung bei Jinengo und die Nutzung der Services akzeptieren Sie die
Erhebung, Verarbeitung und Nutzung Ihrer personenbezogenen Daten durch Jinengo
und aller beteiligten Unternehmen entsprechend den Regelungen dieser Datenschutzbestimmungen.
2.1 Identität Jinengos Jinengo ist die studentische Projektgruppe SSustainable CRM
für E-Mobility Services mit SOA”der Universität Oldenburg aus dem Fachbereich Wirtschaftsinformatik. Angeleitet wird die Projektgruppe durch Herrn Dipl. Oec. Benjamin
Wagner vom Berg und Herrn Dipl. Inf. Ammar Memari. Abteilungsleiter ist Herr Prof.
Dr.-Ing. habil. Jorge Marx Gomez.
E-Mail Kontakt: [email protected]
2.2 Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten Bei
personenbezogenen Daten handelt es sich um Informationen zur Identität einer Person, wie etwa Name, Anschrift, Geburtsdatum oder E-Mail Adresse. Derartige Daten
fallen beispielsweise an, wenn Sie sich bei Jinengo registrieren (Jinengo Nutzer). Routenabfragen werden hingegen bei Jinengo pseudoanonymisiert. Das bedeutet, dass keine
Rückschlüsse auf einen eindeutigen Jinengo Nutzer möglich sind.
a. Bei der Abfrage von Routen werden pseudoanonymisierte Daten erhoben Jinengo
verarbeitet und nutzt diese Daten dann, soweit dies für die Routenplanung und die
Weiterverarbeitung notwendig ist.
b. Nutzung der Daten eines Jinengo Nutzers für das Kundenbeziehungsmanagement
(CRM) Jinengo nutzt diese Daten soweit wie es für die individuelle, personalisierte Kundenansprache notwendig ist.
c. Nutzung der Daten zur Optimierung und Verbesserung des Jinengo Angebots Data
Warehousing und Data Mining findet in dem Maße statt, wie es für die Optimierung
und Verbesserung des Jinengo Angebots erforderlich ist.
2.3 Erhebung, Verarbeitung und Nutzung von Nutzungsdaten Bei Nutzungsdaten handelt es sich um Daten, die der Jinengo Nutzer nicht aktiv zur Verfügung stellen,
sondern die passiv erhoben werden können, während der Jinengo Nutzer sich z.B. auf
einer Website bewegt. Beim Besuch der Jinengo Plattform speichert der Provider für die
Dauer von fünf (5) Arbeitstagen den Domain-Namen oder die IP-Adresse des anfragen-
558
den Rechners, die Dateianfrage des Clients (Dateiname und URL), den http-AntwortCode, die Internetseite, von der der Jinengo Nutzer die Jinengo Plattform besucht, sowie das Datum und die Dauer des Jinengo Nutzer - Besuches. Die Speicherung erfolgt
zur Ermittlung von Störungen oder Missbrauch des Online-Angebots und der Jinengo
Telekommunikationsdienste/-anlagen, soweit sie zum Aufbau weiterer Verbindungen und/oder zu Abrechnungszwecken erforderlich ist. Eine Auswertung Ihrer Nutzungsdaten
zur Erstellung personenbezogener Nutzungsprofile findet nicht statt, sofern Sie einer solchen Nutzung nicht ausdrücklich zugestimmt haben. Im Falle von Störungen oder eines
Missbrauchs behalten wir uns eine Anzeige bei den Strafverfolgungsbehörden vor. Eine
darüber hinausgehende Nutzung oder Weitergabe Ihrer Nutzungsdaten an Dritte erfolgt
nicht.
2.4 Kategorien von nicht direkt ersichtlichen Beteiligten Microsoft ist Partner von Jinengo bezüglich der CRM-Anwendungssoftware Dynamics CRM 2011. Eine
vollständige Auflistung aller beteiligten Unternehmen stellen wir Ihnen auf Anfrage zur
Verfügung.
3. Weitergabe Ihrer Daten Für die Durchführung des Kundenbeziehungsmanagements werden Ihre Daten in der Microsoft Cloud mittels speziell für Jinengo registriertem Dynamics CRM 2011 System verarbeitet. An Jinengo beteiligte VerkehrsmittelServiceanbieter oder sonstige Dritte werden Ihre Daten nicht weitergegeben, es sei denn,
es liegt Ihr ausdrückliches Einverständnis vor,
ein Dritter weist Jinengo gegenüber nach, dass Sie durch Einstellung von Inhalten (Texten, Bildern usw.) in unser Online-Angebot gegen seine Rechte verstoßen
haben und fordert Jinengo zur Herausgabe Ihrer Daten auf oder
Jinengo ist zur Herausgabe dieser Daten verpflichtet, beispielsweise aufgrund einer
gerichtlichen Verfügung oder behördlichen Anordnung.
4. Änderung Ihrer Daten und Widerruf Jinengo ist bemüht, Ihre personenbezogenen Daten korrekt zu speichern. Sie können Ihre Daten allerdings jederzeit ändern
(d.h. aktualisieren, korrigieren und/oder ergänzen) oder löschen. Wenn Sie der Nutzung
Ihrer Daten für die Zukunft widersprechen und/oder eine erteilte Einwilligung widerrufen, werden wir sämtliche gespeicherten Daten von Ihnen unverzüglich löschen. Bitte
berücksichtigen Sie, dass es aus technischen oder organisatorischen Gründen zu einer
Überschneidung zwischen Ihrem Widerspruch und der Nutzung Ihrer Daten im Rahmen einer bereits laufenden Kampagne kommen kann. Einen Widerruf können Sie hier
einlegen: [email protected]
5. Datensicherheit und Datengeheimnis
Wir fühlen uns der Sicherheit Ihrer Daten verpflichtet. Um einen unbefugten Zugang oder
eine unbefugte Offenlegung zu verhindern, die Richtigkeit der Daten zu gewährleisten
559
und die berechtigte Nutzung der Daten sicherzustellen, haben wir entsprechende technische und organisatorische Verfahren eingerichtet, um die Daten, die wir internetbasiert
erfragen, zu sichern und zu schützen. Dennoch kann Jinengo für die Offenlegung Ihrer
Daten aufgrund von Fehlern bei der Datenübertragung und/oder unberechtigtem Zugriff durch Dritte keine Verantwortung oder Haftung übernehmen. Die Mitglieder der
Projektgruppe Jinengo werden zu keinem Zeitpunkt personenbezogene Daten unbefugt
erheben, verarbeiten oder nutzen.
Für Internetseiten beteiligter Unternehmen kann Jinengo keine Haftung übernehmen,
weil diese in der Regel eigene Datenschutzerklärungen pflegen. Wir bitten Sie, sich dort
über die jeweilige Datenschutzpraxis zu informieren.
6. Änderung der Datenschutzbestimmungen Jinengo behält sich das Recht vor,
diese Datenschutzbestimmungen jederzeit unter Beachtung der geltenden Datenschutzvorschriften zu ändern. Für die Nutzung der Jinengo-Services gilt immer die zum Zeitpunkt Ihres Besuchs online abrufbare Fassung der Datenschutzbestimmungen. Sofern Sie
uns anlässlich der Nutzung von Diensten personenbezogene Daten von sich aus mitgeteilt
haben, werden wir Sie über die geänderten Bedingungen in geeigneter Weise (z.B. per
E-Mail) spätestens vier Wochen vor ihrem Inkrafttreten informieren. Widersprechen Sie
diesen Änderungen nicht innerhalb von vier Wochen nach Zugang der Mitteilung, gelten
die geänderten Datenschutzbestimmungen als angenommen. Wir werden Sie in unserer
Mitteilung auf die Bedeutung dieser Vierwochenfrist gesondert hinweisen.
Bei Fragen zu unseren Datenschutzbestimmungen oder zu Ihren personenbezogenen Daten können Sie sich per E-Mail an uns wenden: [email protected]
Diese Richtlinie wurde zuletzt aktualisiert am 17.07.2011.
560
E. Abbildungsverzeichnis
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Nachhaltige Routenplanung . . . . . .
Neuen Agenten erstellen . . . . . . . .
Reise planen . . . . . . . . . . . . . . .
Ergebnis filtern . . . . . . . . . . . . .
Reise planen aus Sicht der Dienstleister
Ergebnis filtern . . . . . . . . . . . . .
Nutzerprofil ändern . . . . . . . . . . .
Reise bewerten . . . . . . . . . . . . . .
Agentenverhalten hinzufügen . . . . . .
Agenten Zusammenfügen . . . . . . . .
Agent bestätigen . . . . . . . . . . . .
Registrierung . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
40
44
46
48
50
53
55
58
61
63
5.1
5.2
5.3
5.4
5.5
5.6
5.7
(Quelle: http://blog.nielsen.com/nielsenwire/online_mobile/apple-leads-smartphone-race
) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Rekombination der Agenten des Contentrepository . . . . . . . . . . . . . 80
Rekombination der Agenten der Adaptationengine . . . . . . . . . . . . . 81
Anwendungsfall: Potentielle Fahrgemeinschaften abrufen . . . . . . . . . . 81
Anwendungsfall: Neuen Contentrepository-Agenten hinzufügen . . . . . . 82
Anwendungsfall: Neuen Matchmaker-Agenten hinzufügen . . . . . . . . . 83
Anwendungsfall: Matchmaker-Agenten rekombinieren . . . . . . . . . . . . 84
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
User CO2 Emission per Route . . . . . . . .
User CO2 Emission nach Route . . . . . . .
User KPI Total . . . . . . . . . . . . . . . .
User KPI Total nach Typen . . . . . . . . .
KPI Value based on ArrivalDate . . . . . .
KPI Value based on ArrivalDate nach User
Anwendungsfall: AdviseMessaging . . . . .
Anwendungsfall: Data Warehouse Prozess .
7.1
7.2
7.3
7.4
7.5
Paket
Paket
Paket
Paket
Paket
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
94
96
97
98
99
100
100
com.jinengo.Environment . . . . . . . .
com.jinengo.PresentationComposer Teil
com.jinengo.PresentationComposer Teil
com.jinengo.AdaptationEngine . . . . .
com.jinengo.UserModelModule . . . . .
.
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
105
106
107
108
110
561
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21
7.22
7.23
7.24
7.25
7.26
7.27
7.28
7.29
7.30
7.31
7.32
7.33
7.34
7.35
7.36
7.37
7.38
7.39
7.40
7.41
7.42
7.43
7.44
7.45
7.46
7.47
7.48
562
Paket com.jinengo.ContentRepository . . . . . . . . .
Paket com.jinengo.ContentRepository.interfaces . . . .
Paket com.jinengo.ContentRepository.contentprovider
Paket com.jinengo.ContentRepository.contextprovider
Paket com.jinengo.ContentRepository.tooling . . . . .
Paket com.jinengo.MessagingModule . . . . . . . . . .
Paket com.jinengo.Hatchery . . . . . . . . . . . . . . .
Sequenzdiagramm Application Startup . . . . . . . . .
Simple User Operations - Teil 1 . . . . . . . . . . . . .
Simple User Operations - Teil 2 . . . . . . . . . . . . .
Sequenzdiagramm LookUpRoute . . . . . . . . . . . .
Sequenzdiagramm getMessage . . . . . . . . . . . . . .
MS CRM Ontology Model . . . . . . . . . . . . . . . .
MS CRM Model . . . . . . . . . . . . . . . . . . . . .
ER-Model Basisdatenbank . . . . . . . . . . . . . . . .
ER-Model Datawarehouse . . . . . . . . . . . . . . . .
Frontend Komponentenmodell . . . . . . . . . . . . . .
Formular Home . . . . . . . . . . . . . . . . . . . . . .
Formular LogIn . . . . . . . . . . . . . . . . . . . . . .
Formular Registrierung . . . . . . . . . . . . . . . . . .
Formular Nutzer–Präferenzen . . . . . . . . . . . . . .
Formular Startbildschirm . . . . . . . . . . . . . . . .
Formular Routenplanung . . . . . . . . . . . . . . . .
Formular Routenergebnisse . . . . . . . . . . . . . . .
Formular Route–Bewertung . . . . . . . . . . . . . . .
Formular Routen ohne Bewertung . . . . . . . . . . .
Formular Nutzerpräferenzen . . . . . . . . . . . . . . .
Formular impressun . . . . . . . . . . . . . . . . . . .
Formular Allgemeine Geschäftsbedingungen . . . . . .
Formular Information . . . . . . . . . . . . . . . . . .
Benutzerelement Home . . . . . . . . . . . . . . . . . .
Benutzerelement Log–In . . . . . . . . . . . . . . . . .
Benutzerelement Registrierung . . . . . . . . . . . . .
Benutzerelement Benutzerinformation ändern . . . . .
Benutzerelement Startbildschirm . . . . . . . . . . . .
Benutzerelement Routenplanung . . . . . . . . . . . .
Benutzerelement Routenbewertung . . . . . . . . . . .
Benutzerelement unbewertete Routen . . . . . . . . .
Benutzerelement Nutzerpräferenzen . . . . . . . . . . .
Benutzerelement Impressum . . . . . . . . . . . . . . .
Benutzerelement Information . . . . . . . . . . . . . .
Kommunikationsschnittstelle . . . . . . . . . . . . . .
Agent Information . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
112
113
114
114
115
116
117
118
119
120
122
123
123
123
124
129
130
131
132
133
134
135
135
136
136
137
137
138
138
139
140
140
141
141
142
142
143
143
144
144
146
147
7.49
7.50
7.51
7.52
7.53
7.54
7.55
7.56
7.57
7.58
7.59
Behaviour Information . . . .
Matchmaker Information . . .
Subrouten–Objekt . . . . . .
User Information . . . . . . .
Hilfklasse Validierung . . . .
Hilfsklasse Log . . . . . . . .
Benutzer Registrieren . . . .
Benutzer Login . . . . . . . .
Hauptmenü . . . . . . . . . .
Ergebnis der Routenplanung .
Präferenzen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
147
148
148
149
150
151
159
160
161
162
163
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
B.10
B.11
B.12
B.13
B.14
B.15
B.16
Phasenmodell des eCRM [19, S.46] . . . . . . . . . . . . . . . . . . . . . .
Architektur der eCRM-Systeme [27, S.364] . . . . . . . . . . . . . . . . . .
Microsoft Dynamics CRM-Technologie [34] . . . . . . . . . . . . . . . . .
Aktueller Strommix in Deutschland [44] . . . . . . . . . . . . . . . . . . .
CO2-Emissionen der verschiedenen Kraftwerkstypen [45] . . . . . . . . . .
Wirkungsgrad moderner Kraftwerke [43] . . . . . . . . . . . . . . . . . . .
Herstellungkosten eines Elektroautos [49] . . . . . . . . . . . . . . . . . .
Kundenbindungsinstrumente im Überblick [73, S. 10] . . . . . . . . . . . .
Merkmale von Kunden in alten und neuen Märkten [87, S. 149] . . . . . .
Kundenbindung im Kontext von CRM [89, S. 20] . . . . . . . . . . . . . .
Phasenbezogene Definition der Dienstleistung Jinengo [90, S. 15] . . . . .
Mehrdimensionales Eigenschaftsprofil für Jinengo [75, S. 47] . . . . . . . .
Beispiel für regressives Preismodell (Quelle: Eigene Darstellung) . . . . .
Cover eines Newsletters (Quelle: Eigene Darstellung) . . . . . . . . . . . .
Facebook Status (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . .
Kundenbindungsmix klassischer Bindungsinstrumente (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelle als Hilfsmittel im Theoriebildungs-und Theorieverfeinerungsprozess [94] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Durchführung und Konfiguration der Wertschöpfungsaktivitäten [104] . .
Ertragsmechanik [104] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adaptive Hypermedia Classification [116] . . . . . . . . . . . . . . . . . .
Adaptation technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ammar’s Adaptive Application Reference Model (AAARM) . . . . . . . .
facebook.com - FriendFinder [126] . . . . . . . . . . . . . . . . . . . . . .
facebook.com - Ads Engine [126] . . . . . . . . . . . . . . . . . . . . . . .
facebook.com mapped to AAARM . . . . . . . . . . . . . . . . . . . . . .
Architecture of the Jinengo system . . . . . . . . . . . . . . . . . . . . . .
Jinengo on top of AAARM . . . . . . . . . . . . . . . . . . . . . . . . . .
Generic CRM structure . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generic user model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
320
322
326
344
346
347
353
371
372
375
376
378
379
382
382
B.17
B.18
B.19
B.20
B.21
B.22
B.23
B.24
B.25
B.26
B.27
B.28
B.29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
384
387
393
394
402
404
409
412
414
415
417
418
423
426
563
B.30
B.31
B.32
B.33
B.34
B.35
B.36
B.37
B.38
B.39
B.40
B.41
B.42
B.43
B.44
B.45
B.46
B.47
B.48
B.49
B.50
B.51
B.52
B.53
B.54
B.55
B.56
Inferring the preferred communication channel of a customer . . .
Inferring the list of interests of a customer . . . . . . . . . . . . . .
Matching a requestor and a driver based on their interests . . . . .
Prediciting a score for a potential driver based on previous ratings
Phasen des Kundenbeziehungslebenszyklus [143] . . . . . . . . . .
Nachhaltigkeit und Konsum (Quelle: [148]) . . . . . . . . . . . . .
(Quelle: [157]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(Quelle: [157]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Personalization Performance System [158] . . . . . . . . . . . . . .
Personalization in online marketing [158] . . . . . . . . . . . . . . .
The Personalization Ladder [159] . . . . . . . . . . . . . . . . . . .
Rule-Based Matching [158] . . . . . . . . . . . . . . . . . . . . . .
Collaborative Filtering [158] . . . . . . . . . . . . . . . . . . . . . .
Basic structure of an agent component [164] . . . . . . . . . . . . .
Multi-agent system for agent components [166] . . . . . . . . . . .
[170] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The cyclic behavior of the BDI-model. . . . . . . . . . . . . . . . .
Overview of the Gaia methodology [172] . . . . . . . . . . . . . . .
Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kapazitäts-/Produktionsverhältnis . . . . . . . . . . . . . . . . . .
Kapazitäts-/Produktionsverhältnis . . . . . . . . . . . . . . . . . .
company with customer centric [184] . . . . . . . . . . . . . . . . .
Components of CRM [190] . . . . . . . . . . . . . . . . . . . . . . .
The value of customer value [194] . . . . . . . . . . . . . . . . . . .
Customer Life Cycle [193] . . . . . . . . . . . . . . . . . . . . . . .
Strategic CRM Framework from Payne (2011) [196] . . . . . . . . .
The Gartner competency model [198] . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
429
429
432
433
443
448
454
454
457
459
460
466
466
474
476
479
480
481
500
501
502
506
508
511
512
514
516
C.1
C.2
C.3
C.4
C.5
Jinengo DataWarehouse Konzept
Jinengo Control Panel Reporting
Jinengo Control Panel KPI . . .
ER-Model Basisdatenbank . . . .
ER-Model Datawarehouse . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
530
531
532
533
556
564
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F. Tabellenverzeichnis
1.1
1.2
Übersicht Lizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau des Abschlussberichtes . . . . . . . . . . . . . . . . . . . . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
4.31
4.32
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Reise planen . . . . . . . . . . . . . . . .
Startpunkt festlegen . . . . . . . . . . . .
Zielpunkt festlegen . . . . . . . . . . . .
Nutzerprofil berücksichtigen . . . . . . .
Reisezeitraum festlegen . . . . . . . . . .
Ergebnis wählen . . . . . . . . . . . . . .
Ergebnis filtern . . . . . . . . . . . . . .
Ergebnis filtern . . . . . . . . . . . . . .
Filter auswählen . . . . . . . . . . . . . .
Service aktualisieren . . . . . . . . . . .
Reise planen aus Sicht der Dienstleister .
Filterdefinition aus Dienstleistersicht . .
Nutzerprofil ändern . . . . . . . . . . . .
Services wählen . . . . . . . . . . . . . .
Präferenzen ändern . . . . . . . . . . . .
Reise bewerten . . . . . . . . . . . . . . .
Reise auswählen . . . . . . . . . . . . . .
Agentverhalten hinzufügen . . . . . . . .
Archiv hochladen . . . . . . . . . . . . .
SHA1 angeben . . . . . . . . . . . . . . .
Integrität prüfen . . . . . . . . . . . . . .
Agentenverhalten konfigurieren . . . . .
Name für Agentenverhalten angeben . .
Kategorie für Agentenverhalten angeben
Agentenverhalten freigeben . . . . . . . .
Agent zusammenfügen . . . . . . . . . .
Skelett öffnen . . . . . . . . . . . . . . .
Bestehende Variation laden . . . . . . . .
Verhalten hinzufügen . . . . . . . . . . .
Variationen benennen . . . . . . . . . . .
Variation freigeben . . . . . . . . . . . .
Neue Agenten anzeigen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
41
41
42
42
43
43
44
45
45
46
47
49
51
51
52
54
54
55
56
56
56
57
57
57
58
59
59
59
60
60
61
62
565
4.33
4.34
4.35
4.36
4.37
4.38
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
Anwendungsfall:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
62
63
64
64
64
65
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Fähigkeiten unterschiedlicher Webbrowser für Mobilgeräte . . .
Caching auf mobilen Endgeräten . . . . . . . . . . . . . . . . .
Caching auf mobilen Endgeräten . . . . . . . . . . . . . . . . .
Anwendungsfall: Potentielle Fahrgemeinschaften abrufen . . . .
Anwendungsfall: Neuen Contentrepository-Agenten hinzufügen
Anwendungsfall: Neuen Matchmaker-Agenten hinzufügen . . .
Anwendungsfall: Matchmaker-Agenten rekombinieren . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
74
75
82
83
84
85
6.1
6.2
Anwendungsfall: AdviseMessaging . . . . . . . . . . . . . . . . . . . . . . 94
Anwendungsfall: Data Warehouse Prozess . . . . . . . . . . . . . . . . . . 95
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12
9.13
9.14
9.15
9.16
9.17
9.18
9.19
9.20
9.21
9.22
9.23
9.24
9.25
9.26
Klasse Administrator . . . . . . . . .
Klasse AgentAssembler . . . . . . . .
Klasse BehaviourDeveloper . . . . .
Klasse CrmAdapter . . . . . . . . .
Klasse CrmProperty . . . . . . . . .
Klasse Customer . . . . . . . . . . .
Klasse User . . . . . . . . . . . . . .
Klasse UserManager . . . . . . . . .
Klasse AdaptationManager . . . . .
Klasse MatchMaker . . . . . . . . .
Interface IMatchMaker . . . . . . . .
Klasse SustainableMatchMaker . . .
Klasse SampleMatchMaker . . . . .
Klasse EconomicalMatchMaker . . .
Klasse SpeedyMatchMaker . . . . .
Klasse ShortestDistanceMatchMaker
Klasse ContentManager . . . . . . .
Klasse Route . . . . . . . . . . . . .
Klasse SubRoute . . . . . . . . . . .
Klasse TravelSituation . . . . . . . .
Klasse TransportationType . . . . .
Klasse ContentProvider . . . . . . .
Klasse BikeProvider . . . . . . . . .
Klasse CarProvider . . . . . . . . . .
Klasse DBProvider . . . . . . . . . .
Klasse FootProvider . . . . . . . . .
566
Agenten-Details prüfen . . . . .
Agenten freischalten / ablehnen
Benutzer registrieren . . . . . .
Benutzerdaten eingeben . . . .
Benutzerdaten bearbeiten . . .
Benutzerdaten speichern . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
167
168
168
169
169
169
170
171
172
174
175
176
177
178
179
180
182
183
183
184
185
185
186
186
187
188
9.27
9.28
9.29
9.30
9.31
9.32
9.33
9.34
9.35
9.36
9.37
9.38
9.39
9.40
9.41
9.42
9.43
9.44
9.45
9.46
9.47
9.48
9.49
9.50
9.51
9.52
9.53
9.54
9.55
9.56
9.57
9.58
9.59
9.60
9.61
9.62
9.63
9.64
9.65
9.66
9.67
9.68
9.69
Klasse PEVProvider . . . . . . . .
Klasse FahrplanerProvider . . . . .
Klasse BusCostCalculator . . . . .
Klasse TramCostCalculator . . . .
Klasse TramEmissionCalculator . .
Klasse BusEmissionCalculator . . .
Klasse Context . . . . . . . . . . .
Klasse ContextProvider . . . . . .
Klasse WeatherDotComProvider .
Klasse TimeProvider . . . . . . . .
Interface ICostCalculator . . . . .
Interface IEmissionCalculator . . .
Interface IRoutePlanner . . . . . .
Interface IWeatherProvider . . . .
Klasse InputCleaner . . . . . . . .
Klasse InputCleaner . . . . . . . .
Interface IPresentationManager . .
Klasse JinengoException . . . . . .
Klasse RestfulPresentationManager
Klasse MessagingManager . . . . .
Interface IMessagingProvider . . .
Klasse BiddingThread . . . . . . .
Klasse AdviseMessage . . . . . . .
Klasse DefaultProvider . . . . . . .
Klasse MessagingProviderValidator
Klasse ProviderRepositoryManager
Klasse BaseController . . . . . . .
Klasse HomeController . . . . . . .
Klasse RouteController . . . . . . .
Klasse UserController . . . . . . .
Klasse SearchRouteModel . . . . .
Klasse RouteUtil . . . . . . . . . .
Klasse RegisterUserModel . . . . .
Klasse RemindUserModel . . . . .
Klasse LoginUserModel . . . . . .
Klasse LogoffModel . . . . . . . . .
Klasse SettingsModel . . . . . . . .
Klasse EmailUserModel . . . . . .
Klasse PasswordUserModel . . . .
Klasse PreferencesUserModel . . .
Klasse CacheFilterAttributel . . .
Klasse CompressFilter . . . . . . .
Klasse LoginForbiddenFilter . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
188
189
189
190
190
191
191
192
193
193
194
194
194
195
195
195
199
199
200
201
202
203
203
204
205
205
206
206
207
209
209
210
210
210
211
211
212
212
212
213
214
214
214
567
9.70 Klasse LoginRequiredFilter . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.71 Klasse CultureHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
B.10
B.11
B.12
B.13
B.14
B.15
B.16
B.17
568
Die drei Hauptmodule in Microsoft Dynamics CRM [2, S.29f.] . . . . . .
Übersicht über Microsoft CRM Mobil Express [39] . . . . . . . . . . . .
CO2-Emissionswerte/kWh für die Erzeugung von Strom aus Braunkohle
Einfacher Kostenvergleich Benzinauto - Elektroauto . . . . . . . . . . .
Preisermittlung eines Kleinstwagens . . . . . . . . . . . . . . . . . . . .
Preisermittlung eines Kleinwagens . . . . . . . . . . . . . . . . . . . . .
Preisermittlung eines Mittelklasse-Wagens . . . . . . . . . . . . . . . . .
Energiepreis für erneuerbare Energien . . . . . . . . . . . . . . . . . . .
Kfz-Steuer im Jahr für ein Elektroauto [69] . . . . . . . . . . . . . . . .
Attributwerte der verschiedenen Autoklassen . . . . . . . . . . . . . . .
Attributwerte der verschiedenen Stromklassen . . . . . . . . . . . . . . .
Vom Nutzer angegebene Parameter . . . . . . . . . . . . . . . . . . . . .
Value Added Services (Quelle: Eigene Darstellung) . . . . . . . . . . . .
Tags related to user with and the amount of their occurence . . . . . . .
Beitrittsgründe deutscher Car-Sharing-Kunden (1994) (Quelle: [151]) . .
Beitrittsgründe schweizer Car-Sharing-Kunden (1998) (Quelle: [152]) . .
Anbieter und Nachfrager Beziehungen (Quelle: [154]) . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
327
338
345
351
354
354
354
355
357
359
360
360
380
428
450
450
451
G. Referenzen
[1] Wikipedia. (2011) Redmine. [Online]. Available: http://de.wikipedia.org/wiki/
Redmine
[2] M. Snyder, J. Steger, K. O’Brien, and B. Landers, Microsoft Dynamics CRM 4.0
Grundlagen. Unterschleißheim: Microsoft Press Deutschland, 2010.
[3] Wikipedia. (2011) Eclipse. [Online]. Available: http://de.wikipedia.org/wiki/
Eclipse
[4] ArgoUML. (2011) Argouml. [Online]. Available: http://argouml.tigris.org/
[5] Microsoft. (2011) Visual studio 2010. [Online]. Available: http://msdn.microsoft.
com/de-de/vstudio/dd582936
[6] ——. (2011) About. [Online]. Available: http://msdn.microsoft.com
[7] (2011) Protégé (software). [Online]. Available: http://de.wikipedia.org/wiki/
Protege
[8] TortoiseSVN. (2011) About tortoisesvn. [Online]. Available: http://tortoisesvn.
net/
[9] MikTex. (2011) About. [Online]. Available: http://miktex.org/about
[10] (2011,
March)
To
better
understand
the
word
sustainability. [Online]. Available: http://www.generation-europe.eu/forum/2010/10/
to-better-understand-the-word-sustainability/
[11] VCO. (2011). [Online]. Available: http://www.vcoe.at/start.asp
[12] (2011, March) Mobilität - automobility to multimodality. [Online]. Available:
http://www.dynamoeffect.org/public/trasmission/documents/125.pdf
[13] (2006, April) Multimodale mobilität - schritte zur förderung von mehr flexibilität in
der verkehrsmitelwahl. [Online]. Available: http://www.stadt-zuerich.ch/content/
dam/stzh/ted/Deutsch/taz/Fachunterlagen/Publikationen und Broschueren/
Verkehr/Erhebungen und Analysen/Spezialanalysen Mobilitaetsformen/
569
MultimodaleMobilitaet.pdf
[14] (2011, March) Multimodale mobilität als chance. [Online]. Available: http:
//www.vcoe.at/start.asp?id=6252
[15] J. Informationsdienst. (2011). [Online]. Available: http://dejure.org/gesetze/
BDSG/4.html
[16] ——. (2011). [Online]. Available: http://dejure.org/gesetze/BDSG/3a.html
[17] ——. (2011). [Online]. Available: http://dejure.org/gesetze/BDSG/28.html
[18] A. Eggert, “Konzeptionelle Grundlagen des elektronischen Kundenbeziehungsmanagements,” in Electronic Customer Relationship Management: Management der
Kundenbeziehungen im Internet - Zeitalter, G. Eggert, A.and Fassott, Ed. Stuttgart: Schäffer-Poeschel Verlag Stuttgart, 2001.
[19] M. Schögel and I. Schmidt, “E-CRM – Management von Kundenbeziehungen im
Umfeld neuer Informations- und Kommunikationstechnologien,” in E-CRM – mit
Informationstechnologien Kundenpotenziale nutzen, I. Schmidt and M. Schögel,
Eds. Düsseldorf: Symposion Publishing, 2002.
[20] R. Shaw, “CRM Definitions – Defining customer relationship marketing and management,” in Customer Relationship Management – The Ultimate Guide to the
Efficient Use of CRM, S. E. B.V., Ed. Braunschweig/Wiesbaden: Friedr. Vieweg
& Sohn Verlagsgeschellschaft, 2001.
[21] P. Winkelmann, Marketing und Vertrieb: Fundamente für die Marktorientierte
Unternehmensführung. München: Oldenbourg Wissenschaftsverlag, 2010.
[22] J. Link and N. Gerth, “eCRM als strategische und organisatorische Herausforderung,” in Electronic Customer Relationship Management: Management der Kundenbeziehungen im Internet - Zeitalter, A. Eggert and G. Fassott, Eds. Stuttgart:
Schäffer-Poeschel Verlag Stuttgart, 2001.
[23] C. Frielitz, H. Hippner, S. Martin, and K. Wilde, “CRM – Erfahrungen,
Einschätzungen und Bedürfnisse aus Anwendersicht ,” in CRM 2000, Sonderpublikation Absatzwirtschaft, H. Hippner and K. Wilde, Eds. Düsseldorf: Verlagsgruppe
Handelsblatt, 2000.
[24] A. Eggert and G. Fassott, “Elektronisches Kundenbeziehungsmanagement
(eCRM),” in Electronic Customer Relationship Management: Management der
Kundenbeziehungen im Internet - Zeitalter, A. Eggert and G. Fassott, Eds. Stuttgart: Schäffer-Poeschel Verlag Stuttgart, 2001.
570
[25] F. Research, “Forrester Glossary,” Website, avalible online at http://
www.forrester.com/ER/Glossary/Item/1,2425,312,00.html?Alpha=E; visited on
2011.02.20.
[26] B. Kay-Enders and A. Enders, “eCRM-Systeme in der Unternehmenspraxis,” in
Electronic Customer Relationship Management: Management der Kundenbeziehungen im Internet - Zeitalter, A. Eggert and G. Fassott, Eds. Stuttgart: SchäfferPoeschel Verlag Stuttgart, 2001.
[27] H. Hippner, “Komponenten und Potenziale eines analytischen Customer Relationship Management,” in Analytische Informationssysteme, 3rd ed., P. Chamoni and
P. Gluchowski, Eds. Berlin/Heidelberg: Springer, 2006.
[28] M. Schumacher, J.and Meyer, Customer Relationship Management - strukturiert
dargestellt - Prozesse, Systeme, Technologien. Berlin/Heidelberg: Springer, 2004.
[29] wikipedia.org, “Electronic Customer Relationship Management,” Website, avalible online at http://de.wikipedia.org/wiki/Electronic Customer Relationship
Management; visited on 2011.02.20.
[30] E.
of
CRM
magazine,
“CRM
Magazine
Announces
Winners
of
2010
CRM
Market
Awards,”
Website,
avalible
online
at
http://www.destinationcrm.com/Articles/CRM-News/Daily-News/
CRM-Magazine-Announces-Winners-of-2010-CRM-Market-Awards-68708.aspx;
visited on 2011.02.20.
[31] M. D. GmbH, “Microsoft Dynamics CRM,” Website, avalible online at http://
www.microsoft.com/germany/dynamics/produkte/crm/ueberblick/default.aspx;
[32] ——, “Systemanforderungen von Microsoft Dynamics CRM,” Website, avalible
online at http://www.microsoft.com/germany/dynamics/produkte/crm/details/
systemanforderungen.aspx; visited on 2011.02.20.
[33] ——, “Microsoft Dynamics CRM 2011 bietet integrierte Funktionen zur Entwicklung neuer Cloud-Dienste,” Website, avalible online athttp://www.microsoft.
com/germany/presseservice/news/pressemitteilung.mspx?id=533205; visited on
2011.02.20.
[34] ——, “Überblick über die Eigenschaften von Microsoft Dynamics CRM,” Website,
avalible online at http://www.microsoft.com/germany/dynamics/produkte/crm/
eigenschaften/default.aspx; visited on 2011.02.20.
[35] M. Wolenik and D. Sinay, Microsoft Dynamics CRM Unleashed.
Peason Education, Inc., 2008.
Indianapolis:
571
[36] M. D. GmbH, “Microsoft Dynamics CRM: die optimale Software für Ihren Vertrieb,” Website, avalible online at http://www.microsoft.com/germany/dynamics/
produkte/crm/eigenschaften/vertrieb.aspx; visited on 2011.02.20.
[37] ——, “Microsoft Dynamics CRM: Software für effezientes Marketing,” Website,
eigenschaften/marketing.aspx; visited on 2011.02.20.
[38] ——, “Microsoft Dynamics CRM: Software für verbesserten Service,” Website,
eigenschaften/service.aspx; visited on 2011.02.20.
[39] ——, “Microsoft Dynamics CRM: Software für mobiles Arbeiten,” Website,
eigenschaften/mobile.aspx; visited on 2011.02.20.
[40] M. Wolenik and R. Bhaiya, Microsoft Dynamics CRM 4 Integration Unleashed.
Indianapolis: Peason Education, Inc., 2010.
[41] M. Snyder and J. Steger, Working with Microsoft Dynamics CRM 4.0. Washington: Microsoft Press, 2008.
[42] M. D. GmbH, “Integration von Microsoft-Technologien und Microsoft Dynamics CRM,” Website, avalible online at http://www.microsoft.com/germany/
dynamics/produkte/crm/details/crm-office-integration.aspx?seite=1; visited on
2011.02.20.
[43] G. Frey, U. Leprich, and J. Horst, “Auswirkungen von Elektroautos auf den Kraftwerkspark und die CO2-Emissionen in Deutschland,” pp. 7 – 38, 2009.
[44] Umweltbundesamt, “Strommix Deutschland,” 2008.
[45] D. Lübbert, “CO2-Bilanzen verschiedener Energieträger im Vergleich,” pp. 8 – 30,
2007.
[46] W. Breyer, “Treibhausgase und Kernenergie,” argumente, vol. 05/2007, p. 2, 2007.
[47] Umweltbundesamt, “Entwicklung der spezifischen Kohlendioxid-Emissionen des
deutschen Strommix 1990-2008 und erste Schätzung 2009,” 2010.
[48] E. Raupach, “Elektro-Autos umweltfreundlich?” 2009.
[49] M. Samson, “Elektromobilität - Die Strategie der Bundesregierung,” pp. 1 – 38,
2010.
[50] D. Notter, M. Gauch, and R. Widmer, “Contribution of Li-Ion Batteries to the
572
Environmental Impact of Electric Vehicles,” Envin. Sci. Technol., vol. 44, pp. 6550
—- 6556, 2010.
[51] ——, “Supporting Information to the article Contribution of Li-ion batteries to
the environmental impact of electric vehicles,” Envin. Sci. Technol., vol. 44, pp.
6550 —- 6556, 2010.
[52] K. ISHIHARA, N. KIHIRA, N. TERADA, and T. IWAHORI, “Environmental
Burdens of Large Lithium-Ion Batteries Developed in a Japanese National Project
,” 2002.
[53] R. Frischknecht, “Elektroauto... Königsweg oder Sackgasse? Fragen und Antworten
der Ökobilanz von Elektroautos,” pp. 1 – 51, 2009.
[54] A. Ehinger, “City EL Preise,” Website, Nov. 2010, avalible online at http://www.
cityel-center-bodensee.de/; visited on 2010.11.23.
[55] wikipedia.org, “http://de.wikipedia.org/wiki/Hotzenblitz,” Website, Feb. 2010,
avalible online at http://de.wikipedia.org/wiki/Hotzenblitz; visited on 2010.11.23.
[56] forhandlere.think.no, “http://forhandlere.think.no,” Website, Nov. 2010, avalible
online at http://forhandlere.think.no; visited on 2010.11.23.
[57] Autobild, “Stromer in Serie,” Website, Jun. 2009, avalible online at http://www.
autobild.de/artikel/preis-mitsubishi-i-miev-917457.html; visited on 2010.11.23.
[58] t online, “Auslieferung des Luis free gestoppt,” Website, Sep. 2009, avalible online
at http://auto.t-online.de/auslieferung-des-luis-free-gestoppt/id 20013410/index;
[59] wikipedia.org, “http://de.wikipedia.org/wiki/REVA,” Website, Mar. 2010, avalible online at http://de.wikipedia.org/wiki/REVA; visited on 2010.11.23.
[60] O. Ampera, “http://www.opel-ampera.com,” Website, Nov. 2010, avalible online
at http://www.opel-ampera.com; visited on 2010.11.23.
[61] spiegel.de, “Das Fünf-Milliarden-Dollar-Baby,” Website, Nov. 2010, avalible online at http://www.spiegel.de/auto/fahrberichte/0,1518,726061,00.html; visited on
2010.11.23.
[62] wikipedia.org, “http://de.wikipedia.org/wiki/ChevroletVolt,” Website, Sep.
2010, avalible online at http://de.wikipedia.org/wiki/ChevroletVolt; visited on
2010.11.23.
[63] spiegel.de, “Tesla Model S verkauft sich prächtig,” Website, Apr. 2009, avalible
online at http://www.spiegel.de/auto/aktuell/0,1518,617271,00.html; visited on
573
2010.11.23.
[64] S. Bundesamt, “Entwicklung des Anteils erneuerbarer Energien am gesamten Endenergieverbrauch von 1998 bis 2009,” Website, Mar. 2010,
avalible online at http://de.statista.com/statistik/daten/studie/2849/umfrage/
anteil-erneuerbarer-energien-am-gesamten-primaerenergieverbrauch/; visited on
2010.11.23.
[65] J. Tillmetz, W.;Garche, “Auf dem Weg zu einer Batteriestrategie für Deutschland,”
p. 1, 2007.
[66] D. Asendorpf, “Die Mär vom emissionsfreien Fahren,” Die Zeit, vol. 39, 2009.
[67] A. Probst, “Wie teuer sind Lithium Ionen Batterien im Elektroauto?” Website,
Jun. 2010, avalible online at http://wissen-elektroauto.de; visited on 2010.11.23.
[68] J. van den Bulk, “A cost- and benefit analysis of combustion cars, electric cars and
hydrogen cars in the Netherlands,” pp. 22–30, 2009.
[69] T. Rode, “kfz-steuer.de,” Website, Aug. 2010, avalible online at http://kfz-steuer.
de; visited on 2010.11.23.
[70] J. Mayer, J.; Mühlenhoff, “Erneuerbare Energien und Elektromobilität - Finanzielle Hürden zur Markteinführung bis 2020,” p. 4, 2010.
[71] U. Mueller, Kundenbindung im E-Commerce : Personalisierung als Instrument des
Customer Relationship Marketing. DUV, 2005.
[72] D. Schneider, Betriebswirtschaftslehre - Band 4: Geschichte und Methoden der
Wirtschaftswissenschaft, 2001.
[73] C. Homburg and M. Bruhn, Kundenbindungsmanagement – Eine Einführung in
die theoretischen und praktischen Problemstellungen, in: Bruhn, M./Homburg, C.
(Hrsg.) (2005): Handbuch Kundenbindungsmanagement. Gabler, 2005.
[74] I. Masche, Kundenbindung: Geschäftsbeziehungen im Business-to-Business Marketing. VDM, 2007.
[75] H. Meffert and M. Bruhn, Dienstleistungsmarketing – Grundlagen – Konzepte –
Methoden. Gabler, 2006.
[76] K. Matzler, H. Stahl, and H. Hinterhuber, Die Customer-based View der Unternehmung, in: Hinterhuber, H./Matzler, K.(Hrsg.) (2002): Kundenorientierte Unternehmensführung. Gabler, 2002.
[77] H. Meffert, C. Burmann, and M. H. Koers, Markenmanagement - Iden-
574
titätsorientierte Markenführung und praktische Umsetzung.
Gabler, 2005.
[78] C. Homburg, A. Becker, and F. Hentschel, Der Zusammenhang zwischen Kundenzufriedenheit und Kundenbindung, in: Bruhn, M./Homburg, C. (Hrsg.) (2005):
Handbuch Kundenbindungsmanagement. Gabler, 2005.
[79] D. Aufderheide and K. Backhaus, “Institutionenökonomische Fundierung des Marketing: Der Geschäftstypenansatz,” Kontrakte, Geschäftsbeziehungen, Netzwerke Marketing und Neue Institutionenökonomik, Zeitschrift für betriebswirtschaftliche
Forschung, vol. 35, pp. 43–60, 1995.
[80] R. Richter and F. E.G., Neue Institutionenökonomik - Eine Einführung und kritische Würdigung, 2003.
[81] M. Kleinaltenkamp, “Investitionsgüter-Marketing aus informationsökonomischer
Sicht,” Zeitschrift für betriebswirtschaftliche Forschung, vol. 44, 1992.
[82] M. Schölling, Informationsökonomische Markenpolitik, 2000.
[83] M. Caspar, A. Hecker, and T. Sabel, “Markenrelevanz in der Unternehmensführung
- Messung, Erklärung und empirische Befunde für B2B-Märkte,” Marketing Centrum Münster, Arbeitspapier Nr. 4., vol. 4, 2002.
[84] P. Kotler and W. Pfoertsch, B2B Brand Management, 2006.
[85] W. Pfoertsch and M. Schmid, B2B - Markenmanagement - Konzepte Methoden Fallbeispiele, 2002.
[86] P. Kotler and W. Pfoertsch, Die Relevanz der Unternehmensmarke, 2003.
[87] M. Laker, A. Pohl, and D. Dahlhoff, Kundenbindung auf neuen Märkten, in: Hinterhuber, H./Matzler, K.(Hrsg.) (2002): Kundenorientierte Unternehmensführung.
Gabler, 2002.
[88] C. Homburg and F. Sieben, Customer Relationship Management (CRM) – Strategische Ausrichtung statt IT-getriebenem Aktivismus, in: Bruhn, M./Homburg, C.
(Hrsg.) (2005): Handbuch Kundenbindungsmanagement. Gabler, 2005.
[89] H. Hippner and K. Wilde, Grundlagen des CRM : Konzepte und Gestaltung, 2004.
[90] W. Hilke, Dienstleistungs-Marketing : Banken und Versicherungen - freie Berufe
- Handel und Transport - nicht-erwerbswirtschaftlich orientierte Organisationen,
1989.
[91] N. Lihotzky, Kundenbindung im Internet, 2003.
575
[92] B. Wirtz, “Electronic business, 2. vollst. Überarb. und erw.: Au .” Wiesbaden,2001.
[93] B. Bailer, “Geschäftsmodelle: Methoden und qualität,” 1997.
[94] F. e. a. Lehner, “Wirtschaftsinformaik: theoretische grundlagen,” 1995.
[95] Steinmüller, “Geschäftsmodelle: Methoden und qualität, dissertation,” 1993.
[96] H. Ulrich, “Management,” 1984.
[97] P. Timmers, “Electronic commerce- strategies and models for business- to- business
trading,” 1999.
[98] Tapscott/Ticoll/Lowy, “al., digital capital, campus,” 2001.
[99] P. Stähler, “Merkmale von geschäftsmodellen in der digitalen Ökonomie,” 2001.
[100] P. Weil and M. R. Vitale, “Place to space: Migrating to ebusiness models, harvard
business school press,” Boston, 2001.
[101] M. K. Welge and Al-Laham, “Planung- prozesse, strategien, maÿnahmen, gabler,”
Wiesbaden,1992.
[102] M. K. Welge and A. Al-Laham, “Planung- prozesse, strategien, maÿnahmen,
gabler,” Wiesbaden,2007.
[103] K. T. and K. P., “Mobile commerce: Grundlagen und techniken,” 2004.
[104] P. D. A. Nicolai, “Skrip :stiftungsprofessur entrepreneurship strategie und entrepreneurship,” WS 2010/2011.
[105] M. Porter, “Strategy and the internet in: Harvard business review,” pp. 63– 78,
2001.
[106] J. e. a. Becker, “Grundsätze ordnungsmäßiger moellierung(gom)- schlussbericht,”
2000.
[107] “Comparis.” [Online]. Available: http://www.comparis.ch/leasing/info/glossar/
leasing.aspx
[108] J. Friese, “O ene standards- technologische basis des internets,” pp. 25–46, 2002.
[109] T. Arens, J. Biethahm, and M. H. Nomikos, “Ganzheitliches e- business, oldenburg
wissenschaftsverlag,” pp. 93– 114, 2002.
[110] K. Petzke, “Nrw: Streit um sperrung von websites verschärft sich.” [Online].
Available: http://www.teltarif.de/arch/2002/kw06s7192.html
576
[111] N. Koch and M. Wirsing, “The munich reference model for adaptive
hypermedia applications,” Lecture Notes in Computer Science, vol. 2347, no.
May, pp. 213–222, 2002. [Online]. Available: http://www.springerlink.com/index/
4G5VUMEQ8UB16XYU.pdf
[112] P. Brusilovsky, “Efficient techniques for adaptive hypermedia,” Intelligent Hypertext, vol. 1326/1997, pp. 12–30, 1997. [Online]. Available: http://www.springerlink.
com/content/d4445498h2847507/?p=e386261816c0457c8756cc37b4d3fc87&pi=20
[113] A. Goy, L. Ardissono, and G. Petrone, “Personalization in e-commerce
applications,” The adaptive web LNCS 4341, pp. 485–520, 2007. [Online].
Available: http://www.springerlink.com/index/n90314486406njn2.pdf
[114] P. D. Bra, G.-J. Houben, and H. Wu, AHAM: a Dexter-based reference
model for adaptive hypermedia. ACM, 1999, pp. 147–156. [Online]. Available:
http://portal.acm.org/citation.cfm?id=294508
[115] R. Oppermann, Adaptive user support: ergonomic design of manually and
automatically adaptable software, R. Oppermann, Ed. Lawrence Erlbaum
Associates, Inc., 1994. [Online]. Available: http://portal.acm.org/citation.cfm?
id=213146
[116] P. Brusilovsky, “Methods and techniques of adaptive hypermedia,” User Modeling
and UserAdapted Interaction, vol. 6, no. 2-3, pp. 87–129, 1996. [Online]. Available:
http://www.springerlink.com/index/10.1007/BF00143964
[117] ——, “Adaptive hypermedia: An attempt to analyze and generalize,” Multimedia
Hypermedia and Virtual Reality, vol. 1077, pp. 288–304, 1996. [Online]. Available:
http://www.springerlink.com/index/y13877q0rx5p7x46.pdf
[118] F. Ghali and A. I. Cristea, “Social reference model for adaptive web learning,”
Learning, pp. 162–171, 2009. [Online]. Available: http://www.springerlink.com/
index/L623717121837P15.pdf
[119] P. T. De Vrieze, P. Van Bommel, and T. Van Der Weide, “A generic adaptive model
in adaptive hypermedia,” Adaptive Hypermedia and Adaptive WebBased Systems,
pp. 344–347, 2004. [Online]. Available: http://eprints.bournemouth.ac.uk/13482/
[120] H. Wu, P. De Bra, A. Aerts, and G.-J. Houben, Adaptation Control in
Adaptive Hypermedia Systems. Springer, 2000, pp. 250–259. [Online]. Available:
http://www.springerlink.com/content/j8ay3wcnu3f8fgbd/
[121] M. Bielikova and J. Kuruc, “Sharing user models for adaptive hypermedia
applications,” 5th International Conference on Intelligent Systems Design and
Applications ISDA05, vol. 05pages, pp. 506–513, 2005. [Online]. Available:
577
http://mapekus.fiit.stuba.sk/misc/isda2005-bielik.pdf
[122] H. Wu and P. D. Bra, “Sufficient conditions for well-behaved adaptive hypermedia
systems,” Language.
[123] I. Torre, “Adaptive systems in the era of the semantic and social web,
a survey,” User Modeling and UserAdapted Interaction, vol. 19, no. 5, pp.
433–486, 2009. [Online]. Available: http://www.springerlink.com/index/10.1007/
s11257-009-9067-3
[124] O. Conlan, V. P. Wade, C. Bruen, and M. Gargan, Multi-model, metadata driven
approach to adaptive hypermedia services for personalized elearning. Springer,
2006, vol. 2347, pp. 100–111. [Online]. Available: http://www.springerlink.com/
content/jnvjeb6rdgc93why/
[125] W. Eamsinvattan, V. Dimitrova, and D. Allen, Activity-based Adaptive
Mobile Learning in Fire and Rescue Services. Springer, 2008, pp. 37–45.
[Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.
164.1560&rep=rep1&type=pdf
[126] F. Inc., “http://www.facebook.com,” 2011.
[127] G. Weber and M. Specht, User Modeling and Adaptive Navigation Support in
WWW-Based Tutoring Systems. Springer, 1997, pp. 289–300. [Online]. Available:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.1139
[128] R. W. White, A. Kapoor, and S. T. Dumais, “Modeling Long-Term Search Engine
Usage,” Lecture Notes in Computer Science, pp. 28–39, 2010.
[129] F. Abel, N. Henze, E. Herder, and D. Krause, “Interweaving Public User Profiles
on the Web,” Lecture Notes in Computer Science, pp. 16–27, 2010.
[130] E. Michlmayr and S. Cayzer, Learning user profiles from tagging data
and leveraging them for personal (ized) information access. Citeseer, 2007.
[Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.
72.8101&rep=rep1&type=pdf
[131] A. Brun, A. Boyer, and L. Razmerita, “Compass to Locate the User Model I Need:
Building the Bridge between Researchers and Practitioners in User Modeling,”
Lecture Notes in Computer Science, pp. 303–314, 2010.
[132] D. Billsus and M. J. Pazzani, “A hybrid user model for news story classification,”
COURSES AND LECTURES INTERNATIONAL CENTRE FOR MECHANICAL SCIENCES, pp. 99–108, 1999. [Online]. Available: http://citeseerx.ist.psu.
edu/viewdoc/download?doi=10.1.1.66.5846&rep=rep1&type=pdf
578
[133] G. Salton, Automatic text processing: the transformation, analysis, and retrieval
of information by computer. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1989.
[134] B. Wagner vom Berg, A. Racet, A. Memari, N. Barakat, R. Espin, and J. M.
Gómez, “Customer segmentation based on compensatory fuzzy logic within a sustainable crm,” Unpublished, 2011.
[135] K. der Vereinten Nationen für Umwelt und Entwicklung, “AGENDA 21,”
http://www.un.org/Depts/german/conf/agenda21/agenda 21.pdf, 1992.
[136] H. Böll, “WORLD SUMMIT ON SUSTAINABLE DEVELOPMENT,” Website, Nov. 2010, available online at http://www.worldsummit2002.org/; visited on
2011.02.17.
[137] O. Symposiums, 1994.
[138] H. Rogall, Ökonomie der Nachhaltigkeit: Handlungsfelder für Politik und Wirtschaft. Verlag für Sozialwissenschaften, 2004.
[139] J. Wild, Organisation und Hierarchie, 1973.
[140] M. Wehling, Anreizsysteme im Multi-Level-Marketing - Erscheinungsformen und
Gestaltungsoptionen, 1999.
[141] H. J. Drumm, Personalwirtschaft - 4. überarbeitete und erweiterte Auf., 2000.
[142] C. Rothhaar, Führung und Motivation im Kundenbeziehungsmanagement, 2001.
[143] M. Bruhn, Relationship Marketing. Das Management von Kundenbeziehungen,
2001.
[144] H. Hipner and K. Wilde, Grundlagen des CRM - Konzepte und Gestaltung.
Gabler, 2006.
[145] P. D. M. Täuber, “Nachhaltigkeit im Konsum: Neue Lebensstile, innovative Produkte oder Wertewandel,” PDF, 2010, available online
at
http://www.ikaoe.unibe.ch/veranstaltungen/hs10/vortragsreihe/
Programm VR 2010 Nachhaltigkeit im Konsum.pdf; visited on 2011.02.17.
[146] D. Giulio, Die Idee der Nachhaltigkeit im Verständnis der Vereinten Nationen.
Anspruch, Bedeutung, Schwierigkeiten. Gabler, 2004.
[147] U. Bern, “Nachhaltigkeit,” Website, 2010, available online at http://www.ikaoe.
unibe.ch/ikaoe nachhaltigkeit.html; visited on 2011.02.17.
579
[148] A. D. Giulio, “Konsum und Nachhaltige Entwicklung: Passt das überhaupt
zusammen?” PDF, 2010, available online at http://www.ikaoe.unibe.ch/
veranstaltungen/hs10/vortragsreihe/referatsfolien digiulio.pdf;
visited
on
2011.02.17.
[149] M. Nussbaum, Menschliches Tun und soziale Gerechtigkeit, 1998.
[150] P. D. U. Haefeli, “Autos teilen – Car-Sharing als Beispiel für nachhaltigen Konsum,” PDF, 2010, available online at http://www.ikaoe.unibe.ch/veranstaltungen/
hs10/vortragsreihe/referatsfolien haefeli.pdf; visited on 2011.02.17.
[151] H. Baum and S. Pesch, Untersuchung der Eignung von Car-Sharing im Hinbkick
auf Reduzierung von Stadtverkehrsproblemen, 1994.
[152] P. Muheim, CarSharing - der Schlüssel zur kombinierten Mobilität, 1998.
[153] Wikipedia, “Kaufverhalten,” PDF, 2010, available online at http://de.wikipedia.
org/wiki/Kaufverhalten; visited on 2011.02.17.
[154] A. Meier and H. Stormer, eBusiness and eCommerce - Managing the Digital Value
Chain, 2009.
[155] M. Merz, Electronic Commerce: Marktmodelle, Anwendungen und Technologien,
2. Aufl. Heidelberg, 2002.
[156] C. Rautenstrauch, Betriebliche Umweltinformationssysteme: Grundlagen, Konzepte und Systeme. Springer, 1999.
[157] H. Pfister, “Pfuschi Cartoon,” Website, 2010, available online at http://www.
pfuschi-cartoon.ch; visited on 2011.02.17.
[158] D. Ahlert, J. Becker, R. Knackstedt, and M. Wunderlich, Customer Relationship
Management im Handel. http://www.springer.com: Springer, 2002.
[159] B. Kasanoff, making it personal.
Publishing, 2001.
http://www.perseusbooksgroup.com: Perseus
[160] D. des Bundes und der Länder,
datenschutzbeauftragten des bundes
in Data Warehouse, Data Mining
anhalt.de/LPSA/index.php?id=20368,
“Entschließung der 59. konferenz der
und der länder vom 14./15.03.2000,”
und Datenschutz, http://www.sachsen2000.
[161] G. S. Intelligence. (2010) Eu privacy directive. [Online]. Available: http:
//globalseci.com/?page id=48
[162] Wikipedia. (2010) Diaspora (software). [Online]. Available: http://en.wikipedia.
580
org/wiki/Diaspora (software)
[163] L. Steels, “Cooperation between Distributed Agents Through Self-organization,”
Decentralized AI, vol. 01, pp. 175 – 196, 1990.
[164] H. Nwana and D. Ndumu, “A Perspective on Software Agents Research,” The
Knowledge Engineering Review, vol. 14, pp. 1 – 18, 1999.
[165] M. Griss and R. Kessler, “Achieving the Promise of Reuse with Agent Components,” SELMAS, vol. 14, pp. 139 – 147, 2003.
[166] Y. Qu, C. Wang, L. Zhong, H. Zou, and H. Liu, “Research for an Intelligent
Component-Oriented Software Development Approaches,” JOURNAL OF SOFTWARE, vol. 4, pp. 1136 – 1144, 2009.
[167] F. for Intelligent Physical Agents, “FIPA ACL Message Structure Specification,”
2002.
[168] ——, “FIPA Ontology Service Specification,” 2001.
[169] M. Wooldridge, An Introduction to MultiAgentSystems.
Limited: Chichester, 2002.
John Wiley and Sons
[170] M. Meisinger, “Fipa acl message structure,” Website, Jul. 2009, available online at http://oceanobservatories.org/spaces/display/CIDev/FIPA+ACL+
Message+Structure.
[171] M. Bratman, Intention, Plans, and Practical Reason.
CSLI Publications, 1999.
[172] M. Wooldrigde, N. Jennings, and D. Kinny, “The Gaia Methodology for AgentOriented Analysis and Design,” Autonomous Agents and Multi-Agent Systems,
vol. 3, pp. 285 – 312, 2000.
[173] P. Novak and J. Dix, “Adding structure to agent programming languages,” lfl
Technical Report Series, vol. 06-12, pp. 2 – 20, 2006.
[174] Eletrotechnik - Elektropraxis - Werkstoffkunde (4. Ausg.). [Handwerk und Technik.
[175] G. Ilgmann, “Die Bahn im Klima-Test,” Frankfurter Allgemeine Sonntagszeitung,
vol. 41, p. 72, 2007.
[176] T. von der Dovenmühle, T. Mahmoud, and J. Marx Gómez, “Energy Saving
Through User Scheduled Load Balancing Within Service Oriented Architectures,”
in Proceedings of the International Society for Ecological Economics (ISEE) : 11th
Biennial Conference: Advancing Sustainability in a Time of Crisis, 2010, p. 147.
581
[177] (2010,
12)
DENA
Netzstudie
II.
[Online].
Available: http://www.dena.de/fileadmin/user upload/Download/Dokumente/Studien
Umfragen/Endbericht dena-Netzstudie II.PDF
[178] M. Hoppe-Kilpper, G. Czisch, C. Ensslin, K. Rohrig, B. Emonts, and W. Kleinkauf,
“Integration erneuerbarer Energien und dezentrale Energieversorgung,” in Jahrestagung des Forschungs-Verbunds Sonnenenergie Integration Erneuerbarer Energien
in Versorgungsstrukturen. Institut für Solare Energieversorgung e. V., 2001, pp.
1–12.
[179] D. Ohlhorst, Windenergie in Deutschland – Konstellations- und Policy-Analyse
des Innovationsverlaufs. Springer, 2009, pp. 83–233.
[180] (2010,
04)
Energiemarkt
Deutschland
Zahlen
und
Fakten
zur
Gasund
Stromversorgung.
[Online].
Available:
http:
//www.bdew.de/bdew.nsf/id/DE Energiemarkt Deutschland - Sommer2008/
$file/Energiemarkt%20Deutschland%20Sommer%202008.pdf
[181] T. von der Dovenmühle and J. Marx Gómez, “Distributed Computing As Business Model Within Smart Grids,” in ITEE 2011: 5th International Symposium on
Information Technologies in Environmental Engineering. Heidelberg, Germany:
Unpublished, 2011.
[182] J. Dyché, The CRM handbook:a business guide to customer relationship management. www.addison-wesley.de: Addison Wesley, 2002.
[183] siriwon, “Customer relationship management: from product to customer centric,”
2007. [Online]. Available: www.marketingworks.com
[184] SalesAgility, “Introduction to crm,” 2006. [Online]. Available: http://www.
sugarforge.org
[185] 12Manage, “Customer Relationship Management,” Website, avalible online at =
http://www.12manage.com/methods customer relationship management.html; visited on 02.2011.
[186] M. Alexandrou, “CRM Definition,” Website, avalible online at
http://www.mariosalexandrou.com/definition/crm.asp; visited on 02.2011.
=
[187] N. Udupa, “Customer Relationship Management and Customer Managed Relationship-Need of the hour,” Website, avalible online at =
http://www.pharmainfo.net/reviews/customer-relationship-management-andcustomer-managed-relationship-need-hour; visited on 02.2011.
[188] J. Radcliffe, J. Kirkby, and E. Thompson, “The eight building blocks of crm,” pp.
582
1–Note 1, 2001. [Online]. Available: http://www.gartner.com
[189] J. Parker, “CDI complements and extends CRM,” Website, avalible online at =
http://www.cdistation.com/2005/08/cdi-vs-crm.html; visited on 02.2011.
[190] G. A. Wyner, “Customer relationship measurement,” Marketing Research, vol. 11,
pp. 39 – 41, 1999.
[191] M. Almotairi, “A framework for successful crm implementation,” in European and
Mediterranean Conference on Information Systems 2009, www.iseing.org/emcis,
2009.
[192] F.
Buttle,
Customer
Relationship
Management.
http://www.elsevierdirect.com/index.jsp: Butterworth-Heinemann, 2008.
[193] J. Ogden, “Developing a crm vision and strategy,” 2002. [Online]. Available:
http://www.mycustomer.com
[194] A. Origin, “Customer relationship management,” 2002. [Online]. Available:
http://www.es.atosorigin.com
[195] P. Sue and P. Morin, “A strategic framework for crm,” 2001. [Online]. Available:
http://v5.books.elsevier.com/bookscat/
[196] R. Iriana and F. Buttle, “Strategic, operational and analytical customer
relationship management:attributes and measures,” 2005. [Online]. Available:
http://www.mgsm.edu.au/research
[197] A. Payne and P. Frow, “A strategic framework for customer relationship
management,” 2005. [Online]. Available: https://www.mosarcorp.com
[198] J. Radcliffe, “Eight building blocks of crm: A framework for success,” 2001.
[Online]. Available: www.gartnerpress.com/
[199] E. Y., “The eight building blocks of crm,” 2003. [Online]. Available:
www.gartnerpress.com/executivereports
[200] Wiki,
“Green
Marketing,”
Website,
avalible
online
http://en.wikipedia.org/wiki/Green marketing; visited on 02.2011.
[201] DECCW, “What is sustainability,” Website, avalible
http://www.environment.nsw.gov.au/sustainability/index.htm;
02.2011.
at
=
online at =
visited
on
[202] C. Tiger, “Green/Sustainable CRM,” Website, avalible online at =
http://crmtiger.blogspot.com/2009/07/greensustainable-crm.html; visited on
583
02.2011.
[203] Wiki,
“Carbon
footprint,”
Website,
avalible
online
http://en.wikipedia.org/wiki/Carbon footprint; visited on 02.2011.
at
=
[204] P. Education, “Building e-commerce applications and infrastructure,” pp. 19–16,
2008. [Online]. Available: http://wps.prenhall.com/bp turban ec 2008/79/20298/
5196418.cw/index.html
[205] A. Groschke, M.; Eßer, “Neue Anforderungen an optimierende Energiesystemmodelle für die Kraftwerkseinsatz- und Zubauplanung bei begrenzten Netzkapazitäten,” Zeitschrift für Energiewirtschaft, vol. 02, pp. 14 – 22, 2009.
[206] T. Arens, J. Biethahm, and M. H. Nomikos, “Ganzheitliches e- business, oldenburg
wissenschaftsverlag,” pp. 93– 114, 2002.
[207] Eclipse. (2011) Eclipse. [Online]. Available: www.eclipse.org
[208] G. Ilgmann, “FAZ: Der Traum von der elektrischen Mobilität,” FAZ, vol. 35, 2009.
[209] J. Büren, “Instrumente der Kundenbindug,” PDF, 2001, available online at http:
//www.themanagement.de/pdf/kundenbindung1.pdf; visited on 2011.02.17.
[210] H. H. Hintenhuber, Kundenorientierte Unternehmensführung: Kundenorientierung, Kundenzufriedenheit, Kundenbindung. Gabler, 2009.
[211] J. Haag, Kundendeckungsbeitragsrechnungen, in: Die Betriebswirtschaft, 1992.
[212] S. Rosenkranz, Doris, Konsum - Soziologische ökonomische und psychologische
Perspektiven. Gabler, 2000.
[213] P. Kotler, Marketing Management, Millenium Editon, Prentice Hall, 2001.
[214] G. Uchyigit and M. Y. Ma, Personalization Techniques and Recommender Systems.
http://www.worldscientific.com: World Scientific Pub Co, 2008.
[215] M. Wallace, M. Angelides, and P. Mylonas, Advances in Semantic Media Adaptation and Personalization. http://www.springer.com: Springer, 2007.
[216] U. Müller, Kundenbindung im E-Commerce: Personalisierung als Instrument des
Customer Relationship Marketing. http://www.gabler.de: Gabler, 2005.
[217] P. E. Agre and M. Rotenberg, Technology and Privacy: The New Landscape.
http://mitpress.mit.edu: The MIT Press, 1998.
[218] M. Sonntag. (2010) Untersuchungen zur personalisierung. [Online]. Available: http:
584
//www.fim.uni-linz.ac.at/Publications/Aussendung10.98/Personalisierung.htm
[219] M.
Bick.
(2010)
Personalisierung.
[Online].
Available:
http:
//www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/
daten-wissen/Wissensmanagement/Wissensmanagement--Strategien-des/
Personalisierung
[220] dotSource GmbH. (2010) Wie viel personalisierung verträgt der ecommerce? [Online]. Available: http://www.socialcommerce.de/2010/08/27/
wie-viel-personalisierung-vertragt-das-e-commerce/
[221] F. G. F. . PARTNER. (2010) Personalisierung. [Online]. Available: http:
//www.contentmanager.de/magazin/artikel thema cm crm personalization.html
[222] D. Bundesvorstand. (2009) Arbeitnehmerdatenschutz. [Online]. Available:
https://www.dgb-bestellservice.de/besys dgb/pdf/DGB31098.pdf
[223] B.
Baeriswyl.
(1999)
Data
mining
und
data
warehousing:
Kundendaten
als
ware
oder
geschütztes
gut?
[Online]. Available: http://www.datenschutz.ch/fileadmin/user upload/datenschutz/
04 Publikationen/Data Mining und Data Warehousing.PDF
[224] D. B. für den Datenschutz und die Informationsfreiheit. (2010) Datenschutz,
informationsfreiheit, datenschutzforum. [Online]. Available: http://www.bfdi.
bund.de
[225] F. T. Commission. (2010) Fair information practice principles. [Online]. Available:
http://www.ftc.gov/reports/privacy3/fairinfo.shtm
[226] P. R. Clearinghouse. (2010) A review of the fair information principles: The
foundation of privacy public policy. [Online]. Available: http://www.privacyrights.
org/ar/fairinfo.htm
[227] Warren
and
Brandeis.
(1999)
The
right
to
privacy. [Online]. Available: http://www.abolish-alimony.org/content/privacy/
Right-to-Privacy-Brandeis-Warren-1890.pdf
[228] K. Sycara, “Multi-Agent Compromise via Negotiation,” Distributed Artificial Intelligence, vol. 02, 1989.
[229] Q. You-Tian, B.-Y. J, H. X., and X.-T. Y., “A Structured Data Object Based,
Agent Component Oriented Approach to Software Development,” Machine Learning and Cybernetics, vol. 2005, 2005.
[230] S. Awerbuch, “Nur Erneuerbare reduzieren ökonomische Risiken,” Neue Energien,
585
G. Referenzen
vol. 04, pp. 58–61, 2006.
[231] J. Büchner, “Kommentar: Versorgungsqualität“,” zemw – Zeitschrift für Energie,
”
Markt, Wettbewerb, vol. 02, pp. 69–70, 2006.
[232] J. Büchner and T. Türkucar, “Optionen zur Weiterentwicklung der Regelenergiemärkte in Deutschland,” ew, vol. 01, pp. 54–57, 2005.
[233] W. Elsenbast, “Anreizregulierung in der Energiewirtschaft,” Wirtschaftsdienst,
vol. 06, pp. 398–403, 2008.
[234] B. Utz and J. Vetter, “Strom für Verbraucher – Visionen und Zukunftsentwicklungen,” e&i: Elektrotechnik und Informationstechnik, vol. 10, pp. 364–366, 2004.
[235] (2010, 12) Gesetz für den Vorrang erneuerbarer Energieträger. [Online]. Available:
http://bundesrecht.juris.de/bundesrecht/eeg/gesamt.pdf
[236] H. Hinterhuber and K. H. Matzler, Kundenorientierte Unternehmensführung.
www.gabler.de: Gabler, 2009.
[237] Wiki,
“Sustainability,”
Website,
avalible
online
http://en.wikipedia.org/wiki/Sustainability; visited on 02.2011.
586
at
=

Projektgruppendokumentation

Transcription

Similar documents

o-,f ,ru.f,