Sie sind auf Seite 1von 84

Bakkalaureatsarbeit

im Rahmen des T - Praktikums

L LL L
L LL L
i ii i
i ii i
e ee e
e ee e
f ff f
f ff f
e ee e
e ee e
r rr r
r rr r
a aa a
a aa a
n nn n
n nn n
t tt t
t tt t
e ee e
e ee e
n nn n
n nn n
b bb b
b bb b
e ee e
e ee e
w ww w
w ww w
e ee e
e ee e
r rr r
r rr r
t tt t
t tt t
u uu u
u uu u
n nn n
n nn n
g gg g
g gg g
b bb b
b bb b
e ee e
e ee e
i ii i
i ii i

O OO O
O OO O
n nn n
n nn n
l ll l
l ll l
i ii i
i ii i
n nn n
n nn n
e ee e
e ee e
- -- -
- -- -
B BB B
B BB B
e ee e
e ee e
s ss s
s ss s
c cc c
c cc c
h hh h
h hh h
a aa a
a aa a
f ff f
f ff f
f ff f
f ff f
u uu u
u uu u
n nn n
n nn n
g gg g
g gg g
s ss s
s ss s
- -- -
- -- -
T TT T
T TT T
e ee e
e ee e
c cc c
c cc c
h hh h
h hh h
n nn n
n nn n
o oo o
o oo o
l ll l
l ll l
o oo o
o oo o
g gg g
g gg g
i ii i
i ii i
e ee e
e ee e
n nn n
n nn n


WS 2004 / 05




Verfasser: PauI Barborka (0250710)
Betreuer: Dr. MichaeI AIexander
Abteilung fr Wirtschaftsinformatik (Hansen, Neumann)
Lehrstuhl fr Neue Medien
InhaItsverzeichnis Seite 2
1 InhaItsverzeichnis
1 nhaltsverzeichnis ........................................................................................... 2
2 Abbildungsverzeichnis .................................................................................... 5
3 Schlsseldaten des Projekts........................................................................... 7
4 Motivation und Partnerfirma............................................................................ 8
4.1 Motivation................................................................................................. 8
4.2 Die Firma vemap.com.............................................................................. 8
5 nhalt und Aufbau der Arbeit ......................................................................... 10
5.1 nhalt ...................................................................................................... 10
5.2 Aufbau.................................................................................................... 11
6 Literatur zum Thema..................................................................................... 12
6.1 Was ist Lieferantenrating?...................................................................... 12
6.2 Vorteile des Lieferantenratings............................................................... 13
6.3 Kriterien der Lieferantenbewertung ........................................................ 13
6.4 nstrumente des Lieferantenratings........................................................ 16
6.4.1 Einfache nstrumente................................................................... 16
6.4.2 Klassische Controllinginstrumente............................................... 16
6.4.3 Moderne nstrumente................................................................... 25
6.5 Exkurs: Objektivitt der Beurteilung ....................................................... 28
6.6 Organisation des Lieferantenratings....................................................... 29
6.6.1 Prioritten .................................................................................... 29
6.6.2 Organisatorische Vorraussetzungen............................................ 29
6.6.3 Funktionalitt ............................................................................... 30
6.6.4 Optimale Kriterienauswahl ........................................................... 30
6.7 Einflussfaktoren auf das Lieferantenrating ............................................. 31
6.8 Ratingergebnis und Konsequenzen ....................................................... 32
6.9 Technische Umsetzung des Ratings ...................................................... 32
InhaItsverzeichnis Seite 3
7 Problembeschreibung (Aufgabenstellung der Partnerfirma) ......................... 33
7.1 st-Zustand ............................................................................................. 33
7.2 Soll-Zustand ........................................................................................... 34
8 Systemmodell ............................................................................................... 35
8.1 Bewertungsfaktoren (=Bewertungskriterien) .......................................... 36
8.1.1 Objektive (oder aggregierbare) Faktoren..................................... 36
8.1.2 Subjektive Faktoren weitere wichtige Faktoren......................... 37
8.2 verwendete Bewertungsmodelle ............................................................ 38
8.2.1 Exkurs: Mehrfachauktionen & -ausschreibungen......................... 38
8.2.2 Bewertungsmodelle fr die objektiven Faktoren .......................... 40
8.2.3 Bewertungsmodell fr die subjektiven Faktoren .......................... 45
8.3 Lieferantenklassifikation ......................................................................... 47
8.4 Optionale Notenbereiche........................................................................ 48
8.5 Hierarchischer Aufbau............................................................................ 49
9 Systemarchitektur ......................................................................................... 50
9.1 Datenbank.............................................................................................. 50
9.1.1 MySQL......................................................................................... 50
9.1.2 logisches Datenmodell ................................................................. 51
9.1.3 physisches Datenmodell .............................................................. 53
9.1.4 Namenskonventionen der Partnerfirma ....................................... 57
9.2 Designdiagramme .................................................................................. 58
9.2.1 Use Case Diagramm.................................................................... 58
9.2.2 EPK Beispiel ,subjektive Kriterien anlegen"................................. 59
9.2.3 EPK Beispiel ,Auswertung: Lieferantenklasse anzeigen" ........... 59
9.3 Programmiersprache.............................................................................. 60
9.3.1 Was ist PHP?............................................................................... 60
9.3.2 Was kann PHP? .......................................................................... 60
9.3.3 Beispiel eines PHP-Skripts .......................................................... 60
9.4 Webserver .............................................................................................. 61
9.5 Zusammenspiel der Komponenten......................................................... 61
InhaItsverzeichnis Seite 4
10 Screenshots der Applikation......................................................................... 62
10.1 Startseite ................................................................................................ 62
10.2 Kriterium anlegen ................................................................................... 63
10.3 Kriterieninformationen anzeigen............................................................. 64
10.4 Gewichtung und Bewertung ................................................................... 65
10.5 Auswertungen ........................................................................................ 66
10.5.1 Allgemeines ................................................................................. 66
10.5.2 Optionale Notenbereiche ............................................................. 67
10.5.3 Lieferantenklassifikation............................................................... 67
10.5.4 Nutzwertanalyse .......................................................................... 68
10.5.5 Auswertung der objektiven Kriterien ............................................ 69
11 Wesentliche Codeteile.................................................................................. 70
11.1 Allgemeines ber den Code ................................................................... 70
11.2 Einfgen in die DB (nsert) ..................................................................... 71
11.3 Herauslesen aus der DB (Select) ........................................................... 72
11.4 Auswertung der Auktionen ..................................................................... 73
12 Projektmanagement...................................................................................... 75
12.1 Entwicklungsmodell ................................................................................ 75
12.1.1 Projektphasen des Wasserfallmodells ......................................... 75
12.1.2 Ergebnisse der einzelnen Projektphasen..................................... 76
12.1.3 Schlussfolgerung ......................................................................... 77
12.2 Soll-st-Vergleich .................................................................................... 78
12.2.1 Zeitplanung (Termine).................................................................. 78
12.2.2 nterpretation................................................................................ 78
12.2.3 Gant-Chart-Vergleich................................................................... 79
12.3 Risikoanalyse ......................................................................................... 80
13 Kritische Wrdigung...................................................................................... 82
14 Literaturverzeichnis....................................................................................... 84

AbbiIdungsverzeichnis Seite 5
2 AbbiIdungsverzeichnis
Abbildung 1: Soll-st-Vergleich: Anzahl der Lieferanten....................................18
Abbildung 2: Soll-st-Vergleich: Beschaffungsvolumen.....................................19
Abbildung 3: Portfolioanalyse der BCG.............................................................22
Abbildung 4: Produktlebenszyklus ....................................................................24
Abbildung 5: Screenshot vom DB-Bearbeitungstool (phpMyAdmin) .................50
Abbildung 6: logisches Datenmodell .................................................................51
Abbildung 7: physisches Datenmodell ..............................................................53
Abbildung 9: Use Case Diagramm....................................................................58
Abbildung 10: EPK ,subjektive Kriterien anlegen".............................................59
Abbildung 11: EPK ,Auswertung: Lieferantenklasse anzeigen" ........................59
Abbildung 11: Zusammenspiel der Komponenten ............................................61
Abbildung 12: Startseite....................................................................................62
Abbildung 13: Men vergrert.........................................................................62
Abbildung 14: Grenzwert (Klasse) anlegen.......................................................63
Abbildung 15: Kriteriumart anlegen...................................................................63
Abbildung 16: Kriterium anlegen.......................................................................63
Abbildung 17: Kriterien anzeigen ......................................................................64
Abbildung 18: Kriterieninformationen anzeigen (fr ,Qualitt") .........................64
Abbildung 19: subjektive Kriterien gewichten....................................................65
AbbiIdungsverzeichnis Seite 6
Abbildung 20: Einen Lieferanten bewerten (,Lieferant A") ................................65
Abbildung 21: Alle Lieferanten bewerten ..........................................................65
Abbildung 22: Auswertung auswhlen..............................................................66
Abbildung 23: Demonstration der Auswertungsframes.....................................66
Abbildung 24: Lieferantennoten anzeigen (Optionale Notenbereiche)..............67
Abbildung 25: Alle Lieferanten einer Klasse anzeigen (,B-Lieferant")...............67
Abbildung 26: ,Normale Nutzwertanalyse"........................................................68
Abbildung 27: ,adaptierte Nutzwertanalyse" (Punkteaddition) ..........................68
Abbildung 28: Auswertung der obj. Kriterien fr Auktionen (Kriterium 1) ..........69
Abbildung 29: Selbiges fr die Kriterien 2,3 ......................................................69
Abbildung 30: Auflistung der PHP-Files ............................................................70
Abbildung 31: Vergleich von Soll- und st-Gant-Chart.......................................79


SchIsseIdaten des Projekts Seite 7
3 SchIsseIdaten des Projekts
Projektname im vollem
Wortlaut:
Lieferantenbewertung bei Online-Beschaffungs-
Technologien
Verfasser: Paul Barborka
Matrikelnummer d. Verfas-
sers:
0250710
Projektbetreuer: Dr. Michael Alexander
Abteilung fr Wirtschaftsinformatik
Lehrstuhl fr Neue Medien
Projektpartner: CD Company Development Services Ges.m.b.H.
(vemap.com)
Geschftsfhrender Gesellschafter:
Heinz Zimmermann
Projektstart: 12. Mai 2004
Projektende: 13. Oktober 2004
Semester: SS 2004 und Abgabe im WS 2004/2005
Themenvorschlag: Es ist ein Lieferantenbewertungssystem fr die
ASP (Application Service Provision) Services der
Firma vemap.com zu erstellen.
Dies beinhaltet die Literaturrecherche, ein Sys-
temmodell, ein Datenmodell und einen lauffhiger
Prototypen.
Zu diesem Thema ist dann auch eine Bakkalau-
reatsarbeit zu verfassen.

Motivation und Partnerfirma Seite 8
4 Motivation und Partnerfirma
Bevor ich zum eigentlichen Hauptteil dieser Arbeit komme, werde ich ber die
Motivation, d.h. warum diese Arbeit geschrieben wurde, schreiben. Auerdem
werde ich einen kurzen berblick ber den nhalt und den Aufbau geben.
4.1 Motivation
Diese Arbeit ist meine Bakkalaureatsarbeit fr das Studium Wirtschaftsinforma-
tik an der Wirtschaftsuniversitt Wien.
Teil des Studienplans ist es, ein T-Praktikum zu absolvieren, welches aus zwei
Teilen besteht: Erstens aus dem Praktikum selbst, welches bei einem externen
Unternehmen oder mit einem Universittsinstitut als Partner absolviert werden
kann, und zweitens eben aus dieser Arbeit.
ch wollte das Praktikum bei einem externen Unternehmen absolvieren, und
mein Betreuer vermittelte mir die Firma vemap.com, welche mich auch schlie-
lich als Partner akzeptierte, und ich mit dem Praktikum beginnen konnte.
4.2 Die Firma vemap.com
Die Firma CD Company Development Services GmbH ist besser bekannt unter
dem Namen ,vemap.com".
Sie wurde im April 2000 gegrndet und ist seit September desselben Jahres
aktiv ttig.
Meine Kontaktpersonen waren:
Heinz Zimmermann, Geschftsfhrer
Dr. Stefan Frhlich, Leiter der T
Hertha Pfeffer, Assistentin des Geschftsfhrers
Motivation und Partnerfirma Seite 9
,vemap.com entwickelt Softwareapplikationen fr die Beschaffung. Unterneh-
men und ffentliche Organisationen knnen diese zur Abwicklung ihrer Ein-
kaufsprojekte ber nternet fern nutzen." [siehe Vemap04]
Die Firma ist ein Application Service Provider fr den Unternehmensbereich
Beschaffung. Die angebotenen Applikationen knnen als nterface zur Zusam-
menfhrung von einkaufenden Unternehmen und Lieferanten verstanden wer-
den.
,Unter Application Service Provision (Abkrzung engl.: ASP) versteht man das
Anbieten von Anwendungen und Serviceleistungen an Einzelpersonen und Be-
triebe ber das nternet. Dadurch ist es nicht mehr notwendig teure und eventu-
ell selten genutzte Anwendungen lokal zu installieren, sondern man bertrgt
die Verantwortung einem Dienstleister, der sich zustzlich um die Pflege und
Wartung des Systems kmmert. Die Abrechnung erfolgt ber eine Pauschalge-
bhr oder auf Nutzungsbasis." [siehe Hans01, 553]
Mit diesen Applikationen knnen Unternehmen ihre Beschaffungsaktivitten
optimieren. Dazu gehren unter anderen: [Vema04]
Auktionen und
Ausschreibungen fr die strategische Beschaffung sowie
Katalogsysteme fr den operativen Einkauf.
Zu den Kunden zhlen groe Unternehmen mit einem hohen Beschaffungsvo-
lumen wie zum Beispiel Austrian Airlines, OMW, Voestalpine, uvm.
Der Fokus der Services liegt auf den Auktionen.
InhaIt und Aufbau der Arbeit Seite 10
5 InhaIt und Aufbau der Arbeit
5.1 InhaIt
Diese Bakkalaureatsarbeit beschftigt sich mit dem Thema Lieferantenbewer-
tung allgemein und ihren Einsatz in Online-Beschaffungs-Technologien.
Fr jedes einkaufende Unternehmen ist die Lieferantenauswahl eine existentiel-
le Aufgabe. Nur Lieferanten welche mit wiederholt guter Qualitt, pnktlich und
natrlich zu guten Preisen liefern sind gute Partner.
Die Services meiner Partnerfirma verfgen ber einen relativ groen Pool an
Lieferanten, welche von den Kunden ausgewhlt werden knnen. Um eine
mglichst effektive Auswahl zu garantieren, bentigt man eine aussagekrftige
Bewertung der Lieferanten. Genau hier trete ich mit meiner Arbeit ins Spiel: ch
sollte fr meine Partnerfirma ein eben solches Lieferantenbewertungssystem
entwickeln. Vorher sollte ich berlegungen anstellen, welche Bewertungssys-
teme berhaupt sinnvoll sind, welche technisch realisierbar und auch praktisch
einsetzbar sind.
Es wurde von mir ein vielseitiges, lauffhiges Lieferantenbewertungssystem
implementiert, welches meine Partnerfirma jetzt fr hre Online-Services ver-
wenden kann. Mit Hilfe dieses Systems kann man Lieferanten aus mehreren
Gesichtspunkten online bewerten.
Das Praktikum wurde von Anfang bis zum Ende als Softwareentwicklungspro-
jekt behandelt und auch so aufgebaut. Das heit es gab ein Projektmanage-
ment, welches den Ablauf genau regelte. Das Projekt wurde in fnf Phasen ein-
geteilt: in Voruntersuchung, Analyse, Design, mplementierung und Test.
Natrlich wurden die fr jede Phase notwendigen Dokumente erstellt. Beispiele
dafr sind eine Disposition mit einer Zeitplanung, ein Systemmodell, Testproto-
kolle uvm.
InhaIt und Aufbau der Arbeit Seite 11
5.2 Aufbau
Folgende Punkte werden in der Arbeit behandelt:
Zuerst wird auf das Thema ,Lieferantenbewertung" generell eingegan-
gen. Dieser Teil bezieht sich hauptschlich auf die verwendetet Literatur.
Danach wird die Problemstellung der Partnerfirma erlutert, und welche
vorher theoretisch besprochenen Grundlagen auch wirklich umgesetzt
wurden.
Weiters wird die Entwicklung des Systems nher beschrieben, das heit
welche Architektur es verwendet, welche Datenbank, Programmierspra-
che, etc.
Danach wird das System nher betrachtet. Dafr wird zuerst die zugrun-
de liegende Logik nher betrachtet, wichtige Codeteile herausgenommen
und erklrt.
Die Laufzeit des Systems wird anhand von diversen Screenshots gezeigt
und erlutert
Abschlieend wird noch auf das Projektmanagement eingegangen, das
heit welche Dokumente whrend des Projekts erstellt wurden, die wich-
tigsten werden auch abgebildet. Ein Soll-st-Vergleich der Zeiten und
Termine wird auch dargestellt werden.
Eine Kritische Wrdigung schliet die Arbeit ab.

Literatur zum Thema Seite 12
6 Literatur zum Thema
6.1 Was ist Lieferantenrating?
Lieferantenrating ist die regelmige,
strukturierte,
transparente und
grndliche
Analyse potenzieller und vorhandener Lieferanten auf deren Leistungspotential
und fhigkeit anhand definierter Ratingkriterien.
Lieferantenrating wird nicht nur zur Auswahl neuer Lieferanten verwendet, son-
dern es stellt die Leistungsfhigkeit der Lieferanten innerhalb klar definierter
Anforderungen zu einem gewissen Zeitpunkt dar.
Fr das Lieferantenrating ergeben sich zwei Einsatzmglichkeiten:
Auswahl von neuen Lieferanten
Bewertung vorhandener Lieferanten
Der erste Fall wird durch eindeutige und fr alle Parteien nachvollziehbare Fak-
toren (Kriterien) ber die Aufnahme eines neuen Lieferanten (Listung) bzw. -
ber die Ablehnung entschieden. m zweiten Falle werden die vorhandenen Lie-
feranten whrend des Tagesgeschftes anhand einer Vielzahl von Kriterien in
ihrem operativen Verhalten geprft. Fllt ein Lieferant negativ auf, so kommt es
entweder zu einer gemeinsamen Optimierung (Lieferantenentwicklung) oder
wenn keine Lieferantenentwicklung mglich bzw. gewnscht ist zum Abbruch
der Geschftsbeziehungen (Auslistung). [vgl. DiSc04, 16]
Literatur zum Thema Seite 13
6.2 VorteiIe des Lieferantenratings
Lieferantenrating bringt natrlich gewisse Vorteile, welche wiederum Wettbe-
werbsvorteile mit sich bringen. Einige davon sind: [DiSc04]
Vorsorgungssicherheit
Lieferantencontrolling
Professionelle Auswahl neuer Lieferanten
Kostenvorteile
Rentabilittsvorteile
Aktives Lieferantenmanagement
Qualittsvorteile
Vorteile fr die Lieferanten selbst (falls das Rating fr jeden Teilnehmer
transparent gemacht wird)
Eine genaue Beschreibung der einzelnen Vorteile ist ab S. 24 [DiSc04] nachzu-
lesen.
6.3 Kriterien der Lieferantenbewertung
Eine der wichtigsten Aufgaben des Lieferantenratings ist die Auswahl der Krite-
rien, welche berhaupt bewertet werden sollen. Es sind gewisse Soll- und wenn
erwnscht auch KO-Kriterien zu finden.
,Am Beginn dieser Anbieterbeurteilung steht die Definition der relevanten Beur-
teilungskriterien, welche sich aus dem bedarfsorientierten Anforderungsprofil
des zu beschaffenden Gutes, der strategischen Ausrichtung des Unternehmens
und der vorgefundenen Marktstruktur zusammensetzen lassen." [siehe Ho-
Ba04, 79]

Literatur zum Thema Seite 14
Beispiele sind: [RiWe01]
Produktqualitt
Flexibilitt
Maschinenpark, technische Ausstattung
rumliche Entfernung
Hilfsbereitschaft in Strfllen
Finanzkraft des Anbieters
zukunftstrchtige Produkte
Zertifizierungen (z.B. DN EN SO 9000)
nnovationsfreudigkeit
Reaktionszeit im Bedarfsfalle
Umweltfreundlichkeit
Verpackung und Verpackungswiederverwertbarkeit
mage
Der Preis wird hier absichtlich nicht aufgefhrt, da er Teil der jeweiligen Ange-
bote ist, und daher nicht generalisiert werden kann.
Die einzelnen Preise mssen dann separat verglichen werden. (natrlich abzg-
lich Rabatte, Skonto, Frachtkosten, etc) Man kann hchstens ein generelles
Preisniveau bewerten. [RiWe01]
Die Kriterien hngen natrlich stark vom bewertenden Unternehmen ab, Sie-
mens stellte zum Beispiel folgende Kriterien vor: [vgl. DiSc04, S. 65]
Untersttzung im Angebotsstadium
Preisniveau und preisliches Verhalten bei nderungen
Literatur zum Thema Seite 15
Flexibilitt bei nderungen bzw. Verhalten bei Reklamationen
Engagement, Beratung, Service, Erreichbarkeit
nformationsfluss whrend des Projekts
Termintreue
Fehlerfreiheit bei der Auftragsabwicklung
Qualitt
Mglich wre auch noch eine Einteilung der Kriterien nach der Zeit: [vgl. Feic88,
S. 42ff]
vergangenheitsbezogene Kriterien
o Lieferzuverlssigkeit
o Liefertreue
o mage
gegenwartsbezogene Kriterien
o Preisniveau
o Lieferzeit
o Qualitt
zukunftsbezogene Kriterien
o technische, personelle und finanzielle Ausstattung
o Marktmacht
o organisatorische Ausstattung
[DiSc04] ist fr weiteres nteresse sehr zu empfehlen, ab S. 65 werden die
wichtigsten Kriterien wie Qualitt, Lieferservice, Kooperationsfhigkeit, Volumen
und Abhngigkeit, etc genau analysiert und erklrt.
Literatur zum Thema Seite 16
6.4 Instrumente des Lieferantenratings
Eine Einteilung kann folgendermaen getroffen werden: [DiSc04]
Einfache nstrumente
Klassische Controllinginstrumente
Moderne nstrumente
6.4.1 Einfache Instrumente
Beispiele sind [DiSc04]
nterviews mit Lieferanten
Firmenbesichtigung

6.4.2 KIassische ControIIinginstrumente
6.4.2.1 LieferantenkIassifizierung
,Die Lieferantenklassifizierung soll zu dem Ergebnis fhren, dass die Versor-
gung des Unternehmens mit Gtern und Dienstleistungen nur von zuverlssi-
gen, leistungsstarken und innovativen Lieferanten realisiert wird. Das bedeutet
konkret dass Lieferanten, die die entsprechenden Klassifizierungskriterien nicht
erfllen, durch leistungsfhigere Lieferanten (sofern vorhanden) ersetzt wer-
den." [siehe RiWe01, 66]
Die Einteilung erfolgt meistens in A,B und C-Lieferanten. Die A-Lieferanten sind
immer die Besten und zu bevorzugenden. Die meisten Geschfte werden mit
ihnen abgewickelt. Lange Partnerschaften sind anzustreben.
Literatur zum Thema Seite 17
Generalisiert kann man A, B und C-Lieferanten folgendermaen beschreiben:
[vgl. DiSc04, 45]
A-Lieferant kleine Menge und hohes, wertmiges Einkaufsvolumen
B-Lieferant mittlere Menge, mittleres Volumen
C-Lieferant groe Menge und kleines Volumen
,Aus Grnden der Versorgungssicherheit knnen B- und C-Lieferanten als se-
cond oder third source beibehalten werden. So erhalten B- und C-Lieferanten
die Chance und den Ansporn zu A-Lieferanten aufzusteigen, indem sie ihre Ge-
samtleistungsfhigkeit durch entsprechend attraktive Angebote dokumentieren
und gegebenenfalls ihr Angebotsspektrum (Sortimentsbreite und tiefe) erwei-
tern." [siehe RiWe01, 67]
Dafr mssen die einzelnen Lieferanten natrlich wissen, wie das jeweilige Un-
ternehmen sie klassifiziert, es muss also auf sinnvolle Weise transparent ge-
macht werden.
Man will den Zulieferer zu guten Leistungen motivieren, trotzdem sollte man
sich Sanktionsmglichkeiten offen halten. Daher sollte man zustzlich folgen-
den Ttigkeiten durchfhren: [RiWe01]
umfangreiche Beschaffungsmarktforschung
objektive Selbsteinschtzung ob man A, B oder C-Kunde ist
Das Ziel ist es natrlich A Kunde zu werden, dies funktioniert aber meis-
tens nur durch Erhhung des Einkaufsvolumens.

Literatur zum Thema Seite 18
6.4.2.1.1 ABC AnaIyse
Beispiel: EinkaufsvoIumen
1-10.000 C C
10.001 60.000 C B
60.001 und hher A
Ein grundstzliches Ziel des Einkaufs ist es, mit wenigen Lieferanten die Ver-
sorgung zu sichern. Vorteile davon sind: [RiWe01]
weniger Einzelsendungen wegen hherem Bestellvolumen
Anzahl und Aufwand fr Bestellungen, Rechnungswesen (Mahnverfah-
ren, etc.) sinkt deutlich
Beschaffungspreisniveau sinkt und wird vorhersehbarer, da einheitliche
Skonti-, Boni- und Rabattbedingungen festgelegt werden.
ZahIenbeispieI EinkaufsvoIumen:

Abbildung 1: Soll-st-Vergleich: Anzahl der Lieferanten
Literatur zum Thema Seite 19

Abbildung 2: Soll-st-Vergleich: Beschaffungsvolumen
Beispiel: QuaIittsmerkmaIe
Hierzu gehren Kriterien wie z.B. Vertragstreue, Pnktlichkeit, Qualitt, Flexibili-
tt usw. Sie spiegeln die Gesamtleistungsfhigkeit eines Lieferanten wieder.
Genau diese Kriterien mssen vorher bei einer Nutzwertanalyse bewertet, und
ein Ergebnis fr jeden Lieferanten berechnet werden. Jetzt muss man diese
Ergebnisse nur mehr Klassifizieren. [RiWe01]
100-88 Pkt. A
87-80 Pkt B
79 Pkt und weniger C
6.4.2.1.2 XYZ AnaIyse
Die XYZ-Analyse ist eine Analyse der Planbarkeit der Auftrge. Sie zeigt die
Wahrscheinlichkeit auf, inwieweit die Beschaffungsverantwortlichen Bedarf am
Leistungsspektrum des Anbieters haben. [RiWe01]
X hohe Planbarkeit, hohe Auftragswahrscheinlichkeit
Y mittlere (ungenauere) Planbarkeit und Auftragswahrscheinlichkeit
Z geringe bzw. keine Planbarkeit und Auftragswahrscheinlichkeit
Literatur zum Thema Seite 20
6.4.2.1.3 Kombinationen von ABC- und XYZ-AnaIyse
Lieferant Einkaufsvolumen Planbarkeit Qualitt
1 A X A
2 A X C
3 C Z C
Hieraus knnen wir nun folgende Sofortmanahmen schlieen:
Lieferant Manahme
1 ber weitere Vertrge und gnstige Konditionen verhandeln
2 ultimativ zu Qualittsverbesserungen auffordern, parallel einen Er-
satzlieferanten prfen
3 Lieferanten eher aus Kartei entfernen und Ersatzlieferanten suchen
Natrlich kann eine Klassifizierung noch nach vielen weiteren Kriterien getroffen
werden.
Literatur zum Thema Seite 21
6.4.2.2 SWOT-AnaIyse
Die SWOT-Analyse ist eine Weiterentwicklung der Strken-Schwchen-
Analyse. Bei der Strken-Schwchen-Analyse schreibt man alle Strken auf die
linke Seite der Tabelle und alle Schwchen auf die rechte. Diese kann man
dann gegenberstellen und eine Entscheidung treffen. [DiSc04]
Bei der SWOT-Analyse werden 2 Kriterien ergnzt, und zwar Chancen und Ge-
fahren eines Lieferanten. Dann ergibt sich auch der Name: Strengths
Weaknesses Opportunities Threats. [DiSc04]
Beispiel: [vgl. DiSc04, 50]
Strken:
Die angebotene Produktqualitt ist
sehr gut.
Chancen:
Der Lieferant hat ein enormes Um-
satzwachstum, dies kann zu Mengen-
vorteilen in den Einkaufskonditionen
fhren.
Schwchen:
Der Service ist ungengend.

Gefahren:
Das enorme Umsatzwachstum des
Lieferanten kann die Abhngigkeit von
ihm weiter erhhen.

Literatur zum Thema Seite 22
6.4.2.3 PortfoIio AnaIyse
Das klassische Portfoliokonzept der Boston Consulting Group (BCG) betrachtet
strategische Geschftsfelder innerhalb eines Unternehmens. Zu einer solchen
Einheit gehren alle Produkt-Markt-Kombinationen, die aussagen, mit welchen
Produkten ein Unternehmen am Markt vertreten ist. Wenn man nun den Pro-
dukt-Markt mit dem Lieferanten-Markt austauscht, bekommt man ein wirkungs-
volles Portfolio zur Lieferantenbewertung. [DiSc04]
Die X-Achse kennzeichnet den Marktanteil der Lieferanten und die Y-Achse den
Marktwachstum.

Abbildung 3: Portfolioanalyse der BCG,
Quelle: http://www.tutor2u.net/business/images/Boston%20Matrix.gif
Nun zur Analyse:
Fllt ein Lieferant in die Klasse der Stars, ist dies die beste aller Positionen. Er
hat einen hohen Marktanteil in schnell wachsenden Mrkten. Sie verspricht
auch in Zukunft hohe Ertrge. Stars sind aber auch sehr mchtige Partner und
damit schwer steuerbare Geschftspartner. [DiSc04]
Fllt der Lieferant in die Klasse der Question Marks ist noch unklar was aus
ihnen wird, da sie zwar in einem viel versprechenden Markt sind, aber noch zu
geringe Marktanteile haben. Diese Gruppe ist meist innovationsfreudig und ko-
Literatur zum Thema Seite 23
operationsbereit, da fr sie ein hoher Finanzierungsbedarf besteht, und sie da-
her praktisch jeden Kunden brauchen. [DiSc04]
Cash Cows sind erfolgreiche Lieferanten, jedoch auf reifen und damit stagnie-
renden Mrkten. Man sollte die Ertrge akzeptieren (die Geldkhe ,melken")
aber nicht mehr weiter investieren. Cash Cow Lieferanten sind eher trge und
daher nicht mehr innovationsfreudig, bringen keine neue deen usw. Sie sind
dafr gute, klassische Leistungserbringer. [DiSc04]
Die Gruppe der Dogs (oder auch Poor Dogs) haben eine schwache Position in
unattraktiven Mrkten. Der Markt kann jedoch fr den Abnehmer sehr wohl inte-
ressant sein. Dogs-Lieferanten haben eine gute Position in Preis- und Konditi-
onsverhandlungen. Allerdings sollte man trotzdem immer eine Rckzugsstrate-
gie haben, falls der Lieferant aus diesem Markt aussteigt oder zu unattraktiv
wird. [DiSc04]
Natrlich sind noch andere Portfolioanalysen mglich, indem man die Achsen
einfach anders bestimmt. Beispiele wren:
X-Achse: ErfIIungsgrad der Anforderungen: schlecht, mittel
oder gut
(Einkaufspreis, Qualitt, Lieferservice, soziale, kologische und
politische Faktoren)
Y-Achse: EntwickIungspotentiaI: kurz-, mittel- oder langfristig
(nnovationsfhigkeit, Kooperationsbereitschaft)
X-Achse: Fhigkeit zur EntwickIung
Y-Achse: ErfIIungsgrad der Anforderungen
Literatur zum Thema Seite 24
6.4.2.4 LebenskurvenanaIyse
Beinahe jedes Produkt durchlebt einen Produktlebenszyklus, welcher so darge-
stellt werden kann: [DiSc04]

Abbildung 4: Produktlebenszyklus,
Quelle: http://www.aitag.com/image/imageGraf/211Grafik.gif
Fr das Lieferantenrating ist diese Kurve insofern interessant, indem sie zwei
Fragen dient:
1. Wie modern bzw. veraltet sind einzelnen Leistungsangebote des Liefe-
ranten?
2. Wie modern bzw. veraltet ist das gesamte Leistungsangebot des Liefe-
ranten und damit auch er selbst?
Anhand dieser Fragen kann man dann analysieren, ob die einzelnen Produkte
des Lieferanten noch lange interessant fr den Abnehmer sein werden oder ob
sie schon in der Rckgangsphase sind. Falls sich das gesamte Leistungsange-
bot eines Lieferanten schon in der Sttigungsphase befindet, kann man an-
nehmen dass der Lieferant selbst auch unmodern geworden ist, und man muss
sich berlegen, ob man weiter mit ihm kooperiert. [DiSc04]

Literatur zum Thema Seite 25
6.4.3 Moderne Instrumente
6.4.3.1 BaIanced Scorecard
,Das Konzept der Balanced Scorecard (BSC) wurde Anfang der 90er Jahre von
Robert S. Kaplan und David P. Norton in enger Kooperation mit zwlf amerika-
nischen Unternehmen entwickelt. [.] Sie ist ein Kennzahlensystem, welche die
traditionelle und einseitig monetre Perspektive mit ihren finanziellen Kennzif-
fern um weitere unternehmensrelevante Kriterien zu ergnzen." [siehe DiSc04,
57]
Diese Ergnzungen sind eher immaterieller Natur, wobei doch die finanziellen
Kennzahlen eine hhere Prioritt haben. Somit ergeben sich 4 Perspektiven:
Finanzen: traditionell in Jahres oder Quartalsabschlssen, nformationen
ber Vermgens-, Finanz- und Ertragslage
Kunden: liefert nformationen ber Positionierung des Unternehmens in
bestimmten Marktsegmenten, ber Kundenzufriedenheit oder Kunden-
bindung
Geschftsprozesse: Beschreibung des Unternehmens anhand der imp-
lementierten Geschftsablufe (Prozesse)
Lernen / Wachstum: eher weiche Erfolgsfaktoren, z.B. Motivation und
Ausbildungsstand der Mitarbeiter, Organisation des Unternehmens, Zu-
gang zu externem Wissen, etc
Alle 4 Perspektiven haben eine Ursache-Wirkung-Beziehung. Demnach mssen
alle Ziele und Kennzahlen der BSC mit mindestens einem Ziel aus der Finanz-
perspektive verbunden sein, da diese ja an oberster Stelle steht. [DiSc04]
Wie kann die BSC fr die Lieferantenbewertung eingesetzt werden? [DiSc04]
1. Der Abnehmer erhlt vom Lieferanten dessen interne BSC und damit
den vollen Einblick in das Unternehmen.
Literatur zum Thema Seite 26
2. Der Abnehmer erstellt sich selbst nach seinen Kriterien eine BSC fr
einen Lieferanten. Diese Methode ist wahrscheinlich bei normalen ohne
enorme Marktmacht (z.B. Automobilhersteller) die wahrscheinlichere.
Dadurch knnen alle 4 Perspektiven durchleuchtet werden: [DiSc04]
Finanzen: harte Finanzzahlen des Lieferanten (z.B. Liquiditt)
Kunden: berblick ber das Kundenportfolio, eigene Zufrieden-
heit oder Kooperationsfhigkeit
Geschftsprozesse: hier knnen alle Einkaufs- und Folgekosten
dargestellt werden, evtl. auch Soll-st-Vergleich
Lernen / Wachstum: Was macht der Lieferant um seine eigene
Leistungsfhigkeit zu verbessern? Wie kann der Abnehmer davon
profitieren?
Anhand dieser Perspektiven kann man eine Bewertung des Lieferanten durch-
fhren.
6.4.3.2 Ratingmatrix (=NutzwertanaIyse)
,Die NWA ist ein ideales Medium fr die Lieferantenbewertung und dient als
Entscheidungshilfe bei vergleichbaren Alternativen. [.] Die Nutzwertanalyse
strukturiert das zu bewertende Objekt in verschiedene Kriterien, welche dann
objektiv messbar sind." [siehe RiWe01, 49]
Der Ablauf ist folgendermaen:
1. KriterienauswahI: Die zu bewertenden Kriterien mssen ausgewhlt
werden
2. Gewichtung und Benotung: Die unterschiedliche Wichtigkeit der Krite-
rien muss deutlich erkennbar sein. Eine Skala von 1-3 (gering, mittel,
hoch) hat sich bei der Gewichtung bewhrt. Bei der Benotung ist eine
Skala von 1-10 empfehlenswert. Die Benotung erfolgt subjektiv.
Literatur zum Thema Seite 27
3. Ergebnis berechnen: Die Berechnung erfolgt folgendermaen:
P
j
. erreichte Punkte fr bewertete Firma j
m . Anzahl der Attribute
w
i
. Gewichtung Attribut i

=
=



0
*
p
ij
. Benotung Attribut i fr Firma j
Das Ergebnis muss dann mit der maximal erreichbaren Punktezahl verglichen
werden:
P
max
. maximal erreichte Punkte
m . Anzahl der Attribute
w
i
. Gewichtung Attribut i
max
0
max
*


=
=
P
max
. maximal zu vergebende Punkte (z.B. 10)
(d.h. Summe der Gewichtungen * maximal erreichbare Punkte)
Dieses Verfahren wird ein als sehr gutes Verfahren eingestuft, es wird auch
hufig in der Praxis verwendet. Die Nachteile liegen aber auf der Hand: da die
Benotung subjektiv erfolgt kann sie verflscht werden.
Literatur zum Thema Seite 28
6.5 Exkurs: Objektivitt der BeurteiIung
Dadurch dass bei Techniken wie zum Beispiel der Nutzwertanalyse sehr viel
subjektive Faktoren einflieen, und man durch die ,Erfahrung" immer mehr da-
zu neigt Hauslieferanten zu bevorzugen und neue Lieferanten nicht objektiv
genug zu prfen, sollte man objektive Verfahren bevorzugen, da es sonst zum
Verlust von Wettbewerbsvorteilen kommen kann. [HoBa04]
Solche Verfahren sind: [HoBa04]
Selbsteinschtzung durch die Lieferanten (natrlich mit berprfung)
Auditierung
Assessment
Nheres dazu siehe [HoBa04, 80ff]
Literatur zum Thema Seite 29
6.6 Organisation des Lieferantenratings
Das Lieferantenrating ist ein wesentlicher Bestandteil der Beschaffung und
muss daher gut organisiert werden.
6.6.1 Prioritten
Lieferantenratings sind zeitaufwndig und damit teuer. Daher sollten Prioritten
festgelegt werden, wie z.B.: [DiSc04]
Bei welchen Artikeln / Warengruppen ist ein Rating besonders wichtig?
Welche Lieferanten werden bewertet?
Wie umfassend ist eine Bewertung?
Wer und wie oft fhrt sie durch?
6.6.2 Organisatorische Vorraussetzungen
sinnvolle ntegration ins Unternehmen
Unternehmensfhrung (Management) muss dahinter stehen
eigene Leute die sich darum kmmern (z.B. Einkauf)
Lieferantenmanagement muss aktiv betrieben werden, da der Einkauf
ein strategischer Erfolgsfaktor ist
Beschaffung muss als strategische Aufgabe und nicht als operative T-
tigkeit gesehen werden
[DiSc04]
Literatur zum Thema Seite 30
6.6.3 FunktionaIitt
,Ein Ratingsystem muss im Unternehmen verschiedenen teilweise kontrren
Anforderungen gengen. Erwartet werden:
Benutzerfreundlichkeit
Hchste Trennschrfe
Einheitlichkeit
Vollstndigkeit
Mglichkeit der empirischen Validierung" [siehe DiSc04, 212]
6.6.4 OptimaIe KriterienauswahI
Eine der wichtigsten Punkte in einem Ratingsystem sind die zu bewertenden
Kriterien. Einige Kriterien habe ich schon in Punkt 6.3 aufgelistet, doch wie wer-
den die ,Richtigen" sinnvoll ausgewhlt? [DiSc04]
Die Auswahl sollte erfolgen durch: [DiSc04]
Expertenmeinung
Betriebswirtschaftliche Bedeutung
Aufwand bei der Erhebung
Erwarteter Beitrag zur Erkennung von Risiken
Eine sinnvolle Kombination aus all diesen Faktoren gewhrleistet die richtige
Auswahl.
Literatur zum Thema Seite 31
6.7 EinfIussfaktoren auf das Lieferantenrating
Das Rating eines Betriebes wird natrlich auf mehrere Arten beeinflusst. Hier
eine kurze Auflistung der wichtigsten Einflussfaktoren auf die Bewertung. [vgl.
Tane79, S. 52ff]
Allgemeine, unternehmensinterne Einflussfaktoren
o Unternehmensgre
o Leistungsprogramm
o Fertigungstechnologie
o Unternehmens-, Produktions- und Beschaffungsplanung
o Beschaffenheit des Materialflusses
o nformationstechnologie
Unternehmensexterne Faktoren
o konomische
o Technologische
o Rechtlich-politische
o Sozio-kulturelle
Literatur zum Thema Seite 32
6.8 Ratingergebnis und Konsequenzen
Eine Bewertung des Ergebnisses und eventuelle Konsequenzen oder Empfeh-
lungen stehen am Ende jedes Ratings. Ein Beispiel wre die Lieferanten in fol-
gende Klassen zu gruppieren: [vgl. DiSc04, 235]
Preferred Der Lieferant gehrt im betrachteten Zeitraum zu den besten.
Lange, strategische Partnerschaften sollten angestrebt werden.
Er sollte frh in Planung und Entwicklung miteinbezogen werden.
Accepted Die Anforderungen werden weitgehend erfllt, jedoch gibt es
Raum fr Verbesserungen. Verbesserung der Lieferleistung wird
erwartet. Fallweise Einbindung in relevante Einkaufsprozesse.
Restricted Die Anforderungen werden in weiten Teilen nicht erfllt, es gibt
deutliche Schwachstellen. Das Einkaufsvolumen sollte reduziert
werden. Die Einbindung in Geschftsprozesse sollte nur nach
deutlicher Prfung stattfinden.
Desource Der Lieferant verursachte wiederholt Probleme und Mehrkosten.
Bei neuen Auftrgen sollte man ihn nicht mehr bercksichtigen.
Das Einkaufsvolumen sollte so schnell wie mglich gegen 0 redu-
ziert werden und an bessere Lieferanten bergeben werden.
6.9 Technische Umsetzung des Ratings
Einige grere Softwareprogramme bieten fertige Lsung fr die Lieferanten-
bewertung an, wie z.B. SAP, People Soft GmbH, Navision, SAS.
Die Firma vemap.com ist ein eher kleineres Unternehmen, und hat keines die-
ser Unternehmenssoftwarepakete in Verwendung. Daher musste es von mir
entwickelt werden. Dadurch konnte man es gleich an die persnlichen Anforde-
rungen anpassen.
ProbIembeschreibung (AufgabensteIIung der Partnerfirma) Seite 33
7 ProbIembeschreibung
(AufgabensteIIung der Partnerfirma)
7.1 Ist-Zustand
Die Firma vemap.com (Partnerfirma) verkauft ihren Kunden eine ASP-
Beschaffungslsung. Das bedeutet dass die Kunden online ihre Beschaffung
durchfhren knnen, nmlich in Form von
Auktionen (mehrere Arten) sowie
Ausschreibungen fr die strategische Beschaffung, oder einem
Katalogsystemen fr den operativen Einkauf.
Fr jedes einkaufende Unternehmen ist die Lieferantenauswahl eine existentiel-
le Aufgabe. Nur Lieferanten welche mit wiederholt guter Qualitt, pnktlich und
natrlich zu guten Preisen liefern sind gute Partner.
Die Partnerfirma verfgt aufgrund ihrer lngeren Erfahrung im diesem Zweig
ber einen relativ groen Pool an Lieferanten. Doch dieser Pool ist aufgrund
seiner Gre ziemlich unbersichtlich. Auerdem haben die Kunden mit den
meisten Lieferanten keine Erfahrungen. Das heit sie wissen nicht in welcher
Qualitt die Lieferanten liefern, ob sie Pnktlichkeit gro schreiben oder eher
nicht so wichtig nehmen usw. Dies sind aber alles Punkte welche aber natrlich
fr eine Auswahl eines bestimmten Lieferanten sehr wichtig sind. Daher bietet
sich ein Rating der Lieferanten an.
Auerdem wre es wnschenswert die Lieferanten nach gewissen Kriterien
einzuteilen, also zu klassifizieren. Solche Kriterien knnen zum Beispiel Ein-
kaufsvolumen, Qualitt oder hnliches sein. Lieferanten, welche in ,schlechten"
Gruppen angesiedelt sind werden als Partner gar nicht mehr in Betracht gezo-
gen, was die Auftragsvergabe erheblich vereinfacht.
ProbIembeschreibung (AufgabensteIIung der Partnerfirma) Seite 34
7.2 SoII-Zustand
Um den Lieferantenpool fr die einkaufenden Kunden attraktiver und vor allem
effektiver zu gestalten, muss man ihn erweitern, und zwar um eine Lieferanten-
bewertung und auch um eine Lieferantenklassifizierung.
Doch wie schon in Punkt 6 (Literatur zum Thema) beschrieben wird, ist ein Lie-
ferantenrating durchaus keine einfache Angelegenheit. Man muss viele Dinge
beachten und das Rating speziell an die Firma anpassen. Hierbei ergibt sich
noch dazu das Problem, dass die Kunden ihre Ratings auch personalisiert ver-
wenden wollen, was auch zu bedacht werden muss.
Ein weiterer wichtiger Punkt ist dass die einzelnen Lieferanten nicht ohne eige-
nes Verschulden negativ bewertet werden. Ein Beispiel dafr wre: Ein Liefe-
rant verkauft Kohle in ganzen Stcken. Das beschaffende Unternehmen ben-
tigt aber Kohlebriketts. Daher wird eine Ausschreibung fr Briketts gestartet,
jeder bekannte Kohlelieferant wird dazu eingeladen. Der oben beschriebene
Lieferant wrde gerne bei der Auktion teilnehmen, kann aber nicht weil er ein-
fach die Spezifikationen nicht erfllen kann. Das heit er bekommt zwar eine
Einladung, steigert aber nicht mit, was zu einem negativen Rating fhrt. Solche
Flle - und hnliche - mssen natrlich bedacht und ausgeschlossen werden
knnen.
Abschlieend kann man die einzelnen Punkte der Aufgabestellung aufzhlen:
Literaturrecherche der geeigneten Ratingmodelle
Erstellung eines Systemmodells auf Basis der Literaturrecherche. Das
Systemmodell muss aufgrund der Anpassung des Ratings an die einzel-
nen Kunden sehr modular gehalten werden. Dies wirkt sich natrlich
auch auf die folgenden Punkte aus.
Erstellung eines Datenbankmodells
mplementierung eines lauffhigen Prototyps, welcher dann in das Ve-
map-System integriert werden kann.
SystemmodeII Seite 35
8 SystemmodeII
Das Systemmodell besteht aus mehreren Punkten:
Beschreibung der Bewertungsfaktoren
Beschreibung der Bewertungsmodelle
Beschreibung der Lieferantenklassifikation
Beschreibung des hierarchischen Aufbaus des Ratings
Wichtig hierbei ist, dass die einzelnen Punkt sehr modular (das heit erweiter-
bzw. anpassbar) gehalten werden, wie schon in 7.2 beschrieben. Der Grund ist
dass jeder Kunde sein persnliches Rating durchfhren mchte, er mchte es
an seine Bedrfnisse anpassen knnen. Dies muss berall bercksichtigt wer-
den.
Das Systemmodell wurde im Laufe des Projektes immer wieder verndert und
an neue Erkenntnisse angepasst.
Ein Beispiel dafr ist Einfhrung einer Lieferantenklassifikation in das System-
modell, was anfangs berhaupt nicht geplant war. Doch nach Analyse eines
Kunden der Partnerfirma wurde entschieden, dass dies eine sinnvolle Erweite-
rung sei.
Ein weiteres Beispiel ist die Abschaffung des hierarchischen Aufbaus, worauf
ich in Punkt 8.4 noch genauer eingehen werde.
Jede nderung des Systemmodells fhrte auch zu groen nderungen in den
weiteren Punkten wie zum Beispiel im Datenmodell oder im Prototyp. Zu Gute
kam, dass das System sowieso schon modular aufgebaut war, was die nde-
rungen vereinfachte.
SystemmodeII Seite 36
8.1 Bewertungsfaktoren (=Bewertungskriterien)
Das gesamte System beruht auf den Faktoren, welche einzeln bewertet werden
knnen. Sie werden Sinnvollerweise in 2 Kategorien eingeteilt, in
objektive (oder aggregierbare) Faktoren sowie
subjektive Faktoren.
8.1.1 Objektive (oder aggregierbare) Faktoren
Die objektiven Faktoren sind Zahlen und Fakten, welche objektiv vom System
gemessen werden knnen. Die Bewertung kann daher auch automatisiert wer-
den, das heit das Ratingsystem errechnet eine Bewertung und speichert sie
automatisch.
Alle Faktoren, auf die ich noch genauer eingehen werde, sind aggregierbar.
Das heit jede Bewertung wird zu den vorherigen dazuaddiert, und dadurch
wird die Gesamtbewertung eines jeden Lieferanten verndert.
Die Bewertung wird nach dem jeweiligen Ereignis (Auktion oder Ausschreibung)
durchgefhrt. Der Benutzer whlt aus welche Lieferanten bewertet werden sol-
len (zum Beispiel mit Checkboxes). Jene Lieferanten, welche nicht bewertet
werden sollen, werden einfach nicht ausgewhlt.
Dadurch wird gewhrleistet dass niemand negativ beurteilt wird, da der Benut-
zer auswhlt, was in die Bewertung einflieen soll und was nicht. Eben solche
Flle wie das Nicht-Erfllen von Spezifikationen (wie bei den Kohlebriketts)
knnen somit vermieden werden.
Nach der Auswahl der zu bewertenden Lieferanten klickt man einfach nur auf
,Bewerten", und alles wird automatisch ausgerechnet und in der Datenbank
abgespeichert. Der Benutzer braucht sich nicht mehr weiter darum zu km-
mern.
SystemmodeII Seite 37
Die Kriterien fr Auktionen und Ausschreibungen sind folgende:
Anzahl der Einladungen
Anzahl der Teilnahmen
Anzahl der Zuschlge
Diese Faktoren sind alle vorgegeben und knnen vom Benutzer nicht verndert
oder ergnzt werden. Dies hat den einfachen Grund, dass sie vom System
selbst berechnet werden und daher eine nderung der Faktoren auch eine Sys-
temumprogrammierung erfordern wrde.
8.1.2 Subjektive Faktoren - weitere wichtige Faktoren
Diese Faktoren knnen vom Benutzer selbst bewertet werden. Dies muss ma-
nuell geschehen, die ntervalle der Bewertung knnen selbst ausgewhlt wer-
den. Es wird immer ein Bewertungsdatum mitgespeichert. Die alten Bewertun-
gen werden nicht aus dem System gelscht. Daher kann auch so etwas wie
eine Entwicklung des Lieferanten abgelesen werden, also ob er sich verbessert
oder verschlechtert hat, und natrlich auch in welchen Kriterien.
Beispiele fr eine sinnvolle Bewertung bei der Partnerfirma sind:
Lieferqualitt und -service
Einhaltung der Liefertermine
Qualitt der Produkte, Verpackung und Beschriftung
Kooperations- und nnovationsfhigkeit
Das Kapitel der einzelnen Bewertungsfaktoren dieser Art wurde aber in Kapitel
6.3 schon ausreichend behandelt.
Ein paar subjektiven Faktoren sind vom System vorgegeben, sie knnen vom
Benutzer aber beliebig verndert und natrlich erweitert werden.
SystemmodeII Seite 38
8.2 verwendete BewertungsmodeIIe
8.2.1 Exkurs: Mehrfachauktionen & -ausschreibungen
Bei der Bewertung von Auktionen und Ausschreibungen ergibt sich das Prob-
lem der Mehrfachauktionen bzw. ausschreibungen, welche ebenfalls im Pro-
duktsortiment der Partnerfirma vorhanden sind.
Zuerst zu den Mehrfachauktionen: Es gibt ,normale" Auktionen, wo ein einzel-
ner Auftrag (z.B. 10 Tonnen Kohlebriketts) versteigert wird. Doch es gibt auch
so genannte Mehrfachauktionen, bei denen mehrere bestimmte Teile eigen-
stndig auktioniert werden. Ein Beispiel wre, falls ein Unternehmen jeweils 10
Tonnen Briketts in Wien und Linz bentigt, aber auch 5 Tonnen in nnsbruck.
Dafr legt der Kunde eine Mehrfachauktion mit 3 Teilauktionen an, wobei jede
Auktion vllig eigenstndig ist und auch so bewertet werden muss. Bei so einer
Mehrfachauktion kann es durchaus vorkommen, dass 3 verschiedene Lieferan-
ten den Zuschlag bekommen.
Bei den Mehrfachausschreibungen verhlt es sich hnlich, nur sind es keine
Teilauktionen sondern Teilkapitel einer Ausschreibung. Ein Beispiel hierfr wre
eine Ausschreibung fr fnf unterschiedliche Server, wobei jeder Server ein
eigenes Kapitel darstellt. Doch bei den Zuschlgen verhlt es sich anders als
bei den Auktionen: Bei einer Ausschreibung kann nur ein Lieferant den Zu-
schlag erhalten. Dies wird nach den jeweiligen Prferenzen des beschaffenden
Unternehmens ausgewhlt, also wenn z.B. 4 von 5 Servern zufrieden stellend
geliefert werden knnen, der fnfte aber um 10 % teurer als der Mindestbieter
ist, erhlt dieser Lieferant trotzdem den Zuschlag fr die gesamte Ausschrei-
bung.
SystemmodeII Seite 39
8.2.2 BewertungsmodeIIe fr die objektiven Faktoren
Da die einzelnen objektiven Kriterien doch sehr spezifisch sind und nicht wirk-
lich in ein existierendes Bewertungsmodell hineinpassen, haben wir hierfr ein
eigenes Modell entwickeln mssen. Es ist bei Ausschreibungen und Auktionen
relativ hnlich und unterscheidet sich aufgrund der zuvor beschriebenen Prob-
lematik nur bei der Auswertung der Zuschlge. Die Problematik der Mehrfach-
auktionen und ausschreibungen fliet auch in das Modell mit ein.
8.2.2.1 EntwickeItes ModeII fr Auktionen
ch werde das Modell am besten anhand eines Beispiels erklren. Bei diesem
Beispiel gibt es 2 Auktionen. Eine ,normale" und eine Mehrfachauktion, welche
aus drei Teilauktionen besteht.
8.2.2.1.1 AnzahI der EinIadungen
Lieferant Anzahl der Einladungen
A 2
B 2
C 1
Hier wird einfach nur die Anzahl der Einladungen summiert. Hier gilt, wie auch
bei allen anderen Kriterien, dass nur jene Lieferanten bewertet werden, welche
auch fr die Bewertung vom Benutzer explizit ausgewhlt worden sind. Eine
Einladung zu einer Mehrfachauktion zhlt nur als eine einzelne Einladung. A
und B wurden zu beiden Auktionen eingeladen, C nur zu einer.
SystemmodeII Seite 40
8.2.2.1.2 AnzahI der TeiInahmen
Lieferant
Anzahl der Teil-
nahmen bei ,gan-
zen" Auktionen
Teilnahmen bei
Teilauktionen
Gesamtanzahl der
Teilauktionen
A 2 4 4
B 2 2 4
C 1 3 3
Die ,Anzahl der Teilnahmen bei ,ganzen" Auktionen" werden hnlich wie die
Einladungen berechnet, jede Auktion (egal ob Einfach- oder Mehrfachauktion)
zhlt als 1.
,Teilnahmen bei Teilauktionen" gibt die Anzahl der Teilnahmen bei einzelnen
Teilauktionen an. Eine ,normale" Auktion zhlt hier logischerweise als 1.
Die ,Gesamtanzahl der Teilauktionen" erklren sich von selbst.
Lieferant A hat bei beiden Auktionen und auch bei allen Teilauktio-
nen der Mehrfachauktion teilgenommen. Daher 2 (4 von 4).
Lieferant B hat zwar bei beiden Auktionen, jedoch nur bei einer ein-
zigen Mehrfachauktion teilgenommen. Daher 2 (2 von 4).
Lieferant C hat nur bei der Mehrfachauktion teilgenommen (nur 1
,ganze" Teilnahme), dafr bei allen Teilauktionen von dieser. Daher
1 (3 von 3).
SystemmodeII Seite 41
8.2.2.1.3 AnzahI der ZuschIge
Lieferant
Bestbieter bei
,ganzen" Auktio-
nen
Bestbieter bei
Teilauktionen
Gesamtanzahl der
Teilauktionen
A 2 3 4
B 1 1 4
C 0 0 3

Lieferant A war bei 2 Teilauktionen und bei der ,normalen" Auktion
der Bestbieter (insgesamt 3 mal ,Bestbieter bei Teilauktionen"), und
war daher 2-mal Bestbieter bei ,ganzen" Auktionen. Daher 2 (3 von
4).
Lieferant B hat nur eine Teilauktion gewonnen, daher hat er auch
nur 1 ,ganze" Auktion gewonnen. Daher 1 (1 von 4).
Lieferant C hat nur bei der Mehrfachauktion mitgemacht, und keine
einzelne der drei Teilauktionen gewonnen. Daher 0 (0 von 3).
Was hier auffllt ist, dass insgesamt 3 ,ganze" Auktionen gewonnen worden
sind, obwohl es ja eigentlich nur 2 gegeben hat. Dies erklrt sich dadurch, dass
falls jemand auch nur eine einzelne Teilauktion einer Mehrfachauktion gewinnt,
als Bestbieter fr diese Auktion gilt, da er ja fr diesen Teil auch den Zuschlag
erhalten hat. Theoretisch kann es fr die Mehrfachauktion mit 3 Teilauktionen
auch 3 Gewinner bei ,ganzen" Auktionen geben, falls jede Teilauktion von ei-
nem anderem gewonnen worden wre. Bei unserem Beispiel gibt es aber nur
zwei, nmlich Lieferant A und B.

SystemmodeII Seite 42
8.2.2.2 EntwickeItes ModeII fr Ausschreibungen
Auch dieses Modell werde ich anhand eines Beispiels erklren. Bei diesem Bei-
spiel gibt es 2 Ausschreibungen. Eine ,normale" und eine mit 4 einzelnen Kapi-
teln. nsgesamt kann es aber nur 2 Zuschlge geben, und nicht wie bei den
Auktionen mehrere.
8.2.2.2.1 AnzahI der EinIadungen
Hier werden wie bei den Auktionen nur Einladungen summiert. Eine Einladung
zu einer mehrkapiteligen Ausschreibung zhlt auch nur als eine Einladung.
8.2.2.2.2 AnzahI der TeiInahmen
Lieferant
Anzahl der Teilnah-
men bei ,ganzen"
Ausschreibungen
Teilnahmen bei
einzelnen Kapiteln
Gesamtanzahl der
Kapitel
A 2 3 5
B 1 4 4
C 1 3 3
Lieferant A hat bei beiden Ausschreibungen, jedoch bei der Mehr-
fachausschreibung nur bei 2 von 4 Kapiteln. Daher 2 (3 von 5).
Lieferant B hat nur bei der Mehrfachausschreibung bei allen Kapi-
teln teilgenommen. Daher 1 (4 von 4).
C hat auch nur bei der Mehrfachausschreibung teilgenommen. Ob-
wohl es 4 Kapitel gegeben hat, ist die Gesamtanzahl der Kapitel nur
3. Grund: Der bewertende Kunde wollte aus irgendeinem Grund
nicht, dass ein Kapitel in die Bewertung mit einfliet und daher hat
er es einfach nicht fr die Bewertung ausgewhlt. Bei den anderen
Kapiteln hat er aber teilgenommen, daher 1 (3 von 3).
SystemmodeII Seite 43
8.2.2.2.3 AnzahI der ZuschIge
Lieferant
Zuschlge bei
,ganzen" Aus-
schreibungen
Zuschlge bei ein-
zelnen Kapiteln
Gesamtanzahl der
Kapitel
A 1 1 5
B 1 3 4
C 0 1 3

Lieferant A erhielt den Zuschlag fr die einfache Ausschreibung, da
er fr das einzige Kapitel dieser Ausschreibung der attraktivste An-
bieter war. Daher hat er einen ,ganzen" Zuschlag erhalten, und
auch einen Kapitelzuschlag. Daher 1 (1 von 5).
Lieferant B hat den Zuschlag fr die Mehrfachausschreibung erhal-
ten. Er hat 3 der 4 Kapitel gewonnen, und daher auch den Zuschlag
bekommen. Daher 1 (3 von 4).
Lieferant C hat zwar ein Kapitel der Mehrfachausschreibung ge-
wonnen, jedoch reichte dies nicht fr den Gesamtzuschlag. Den hat
ja wie schon gesamt Lieferant B bekommen. Daher 0 (1 von 3).
Hier sieht man dass es bei 2 Ausschreibungen auch nur 2 Gesamtzuschlge
gegeben hat und auch nur geben kann, zum Unterschied bei den Auktionen.

Da die beiden Bewertungssysteme auf den ersten Blick doch relativ kompliziert
sind, mssen sie den Kunden gut erklrt und auch einleuchtend dokumentiert
werden.

SystemmodeII Seite 44
8.2.3 BewertungsmodeII fr die subjektiven Faktoren
8.2.3.1 NutzwertanaIyse
Fr die Bewertung der subjektiven Faktoren verwende ich die Nutzwertanalyse
(NWA), jedoch ein wenig adaptiert. Die Nutzwertanalyse an sich habe ich be-
reits in Punkt 6.4.3.2 vorgestellt und erklrt.
Sie besteht normalerweise aus 3 Teilen:
KriterienauswahI (siehe Punkt 8.1.2)
Gewichtung und Benotung: Jedes Kriterium kann gewichtet werden.
nsgesamt kann man 100% auf die einzelnen Kriterien aufteilen, wobei
die Verteilung dem Benutzer berlassen ist. Nach der Gewichtung kann
benotet, also bewertet werden. Man verteilt Noten (normalerweise von 1-
5 oder 1-10) auf die einzelnen Faktoren, wobei die Skala und die Bedeu-
tung der Skala vorher festgelegt werden muss.
Ergebnisberechnung: Formel:

=
=



0
* (siehe 6.4.3.2)
Beispiel einer Bewertung eines Lieferanten (Skala 1-5):
Kriterium Gewich-
tung
Note Ergebnis
Lieferqualitt 70 % 1 0,7
Termintreue 25 % 2 0,5
Verpackung 5 % 4 0,2
Gesamt 100 % 1,4
Wie man hier erkennen kann ist das Ergebnis innerhalb der definierten Skala.
Die schlechte Note der Verpackung (4) fllt aufgrund der niedrigen Gewichtung
(5%) nicht ins Gewicht. Daher ist die Gesamtnote fr diesen Lieferanten 1,4.
SystemmodeII Seite 45
8.2.3.2 Adaption der NutzwertanaIyse (wg. ModuIaritt)
Da die Modularitt und Anpassbarkeit des Ratings wie schon gesagt einen sehr
hohen Stellenwert einnimmt, wurde die NWA adaptiert.
Der Kunde kann sich selbst aussuchen wie er sie verwenden will. Entweder wie
vorher beschrieben in der Urform oder eben adaptiert, d.h. dass er die SkaIen
der Kriterien frei definieren kann. Das heit er kann fr jedes einzelne Bewer-
tungskriterium eine eigene Skala definieren, natrlich nur wenn er es wnscht.
Dies wrde dann so aussehen:
Kriterium SkaIa Note
Lieferqualitt 1-70 70
Verpackung 1-5 2
Qualitt 1-25 20
Ergebnis max. 100 92
Die Gewichtung im Sinne der Verteilung von 100% hat hier dann natrlich kei-
nen Sinn mehr, sie muss ausgeschaltet werden.
Neue ErgebnisformeI (Gewichtung w
i
fIIt weg):

=
=



0
(hier 92 Punkte)
Neue maximaIe PunktezahI:

=
=



0
max
(hier max 100 Punkte)
Daher ist es keine NWA mehr, sondern eine einfache Punkteaddition.
Der Benutzer kann sich also selbst auswhlen was ihm lieber ist, eine einheitli-
che Skala, wo sich dann das Ergebnis auch in der Skala befindet oder eben
eine einfach Addition von Punkten, ohne Gewichtung.

SystemmodeII Seite 46
8.3 LieferantenkIassifikation
Das nstrument der Lieferantenklassifikation habe ich bereits in Punkt 6.4.2.1
erklrt. Die hufigste Form ist die ABC Analyse.
Bei dem entwickelten System kann man die Klassen vordefinieren, Sinnvoller-
weise eben 3 Klassen: A-Lieferant, B-Lieferant und C-Lieferant.
Diese Klassen mssen dann fr jedes Kriterium definiert werden. Aufgrund der
Anpassbarkeit kann man die Grenzwerte der einzelnen Klassen bei jedem Kri-
terium frei und unabhngig voneinander whlen. Dabei muss man natrlich die
frei whlbaren Skalen beachten.
Ein Beispiel dazu:
Kriterium SkaIa C B A
Lieferqualitt 1-70 1-40 41-64 65-70
Verpackung 1-5 1-2 3-4 5-5
Qualitt 1-25 1-20 21-23 24-25
Nach einer erfolgten Bewertung werden die Lieferanten einer Klasse zugeord-
net. Danach kann man Auswertung erstellen wie zum Beispiel alle A-
Lieferanten anzeigen lassen, oder welcher Lieferant in welche Klasse fllt.
Von der Partnerfirma wurde festgelegt, dass wenn ein Lieferant in der Gesamt-
klassifikation in jene Klasse eingeordnet wird, welche seine schlechteste ist.
Das heit wenn er berall A-Lieferant ist auer in einem Kriterium ein B-
Lieferant, dann ist er insgesamt auch ein B-Lieferant.
Vorraussetzung fr eine Klassifikation ist aber eine obligatorische Eingabe von
Grenzwerten fr jedes einzelne Bewertungskriterium. Dies wird auch von Seiten
der Applikation verlangt. Auerdem hat die Klassifikation nur bei den subjekti-
ven Bewertungen einen Sinn, da sie nicht in das Modell fr die objektiven Krite-
rien hineinpasst.
SystemmodeII Seite 47
8.4 OptionaIe Notenbereiche
Als Zusatzauswertung kann man fr jedes einzelne, subjektive Kriterium auch
Noten vergeben. Auch dies geschieht mit Bereichen.
Die einzelnen Noten sowie die Bereiche knnen auch fr jedes einzelne Kriteri-
um frei gewhlt werden. Falls man fr manche Kriterien keine Noten vergeben
will, kann man sie auch ganz weglassen.
Beispiel fr das Kriterium Verpackung (Skala 1-5):
Note Wertebereich
Sehr Gut 4-5
Schlecht 1-3

Beispiel fr das Kriterium Qualitt (Skala 1-25):
Note Wertebereich
Sehr Gut 21-25
Mittel 16-20
Ausreichend 11-15
Nicht ausreichend 1-10

Diese Notenbereiche knnen dann fr die einzelnen Kriterien sowie fr die ein-
zelnen Lieferanten ausgewertet werden.
SystemmodeII Seite 48
8.5 Hierarchischer Aufbau
Zuerst war geplant, dass das gesamte Bewertungssystem hierarchisch aufge-
baut wird, und zwar in 2 Bereiche, nmlich
Strategische Beschaffung (Auktionen und Ausschreibungen)
Operativer Einkauf (Katalogsystem)
Es war auerdem geplant dass die Bewertungsnoten der einzelnen Lieferanten
insgesamt auf diese beiden Hierarchieebenen hochgerechnet werden, damit
der Kunde sieht welcher seiner Bereiche besser dasteht, und wo er dadurch
weiter optimieren kann.
Dieses Modell wurde jedoch im Laufe der Planung verworfen, und es wurde
beschlossen, dass es nicht implementiert wird.
Da es aber grundstzlich keine schlechte dee war eine weitere Ebene, nach
der man die Bewertung und danach natrlich auch die Auswertung filtern kann,
wurde entschieden dass eine so genannte ,Kriteriumsart" eingefgt wird.
Beispiel fr die Kriteriumsart ist eine Unterteilung der Kriterien in:
Pre Sales und
After Sales.
Danach kann wie gesagt danach ausgewertet werden, und der Kunde sieht
gleich in welchem dieser Bereiche Verbesserungspotential liegt.
Systemarchitektur Seite 49
9 Systemarchitektur
9.1 Datenbank
9.1.1 MySQL
ch hatte die Vorgabe als Datenbank MySQL zu verwenden. Ein Vorteil von
MySQL ist, dass es in der Open-Source Variante Freeware ist.
m Vergleich zu Oracle gibt es bei MySQL unter Anderem den Vorteil von Sub-
selects sowie von Fremdschlsseln nicht, was fr die mplementierung durch-
aus von Vorteil gewesen wre.
Fr die Bearbeitung der Datenbank habe ich das Tool phpMyAdmin Version
2.5.7 verwendet, was ebenfalls Freeware ist, und auf PHP basiert.

Abbildung 5: Screenshot vom DB-Bearbeitungstool (phpMyAdmin)
Systemarchitektur Seite 50
9.1.2 Iogisches DatenmodeII

Abbildung 6: logisches Datenmodell
Anmerkungen zum DB-Modell:
Die gestrichelten Linien sind non-identifying Beziehungen, die durchgezogenen
sind identifying, das heit das Attribut der Beziehung ist Teil des Primary Keys
der referenzierten Tabelle.
Ein schwarzer Punkt bedeutet, dass die Beziehung in diese Richtung geht, das
heit das Attribut der Beziehung befindet sich in jener Tabelle mit dem schwar-
zen Punkt.
Systemarchitektur Seite 51
9.1.2.1 Iogische TabeIIenbeschreibung
TabeIIe Beschreibung
ratGrade Hier werden die optionalen Notenbereiche, wie in Punkt 8.4
beschrieben, fr die einzelnen Faktoren gespeichert.
ratType Dies ist die Art des Kriteriums, wie in Punkt 8.5 beschrieben.
(Pre Sales, After Sales, etc)
ratClass n dieser Tabelle werden die Klassen fr die Lieferantenklas-
sifizierung gespeichert, wie in Punkt 8.3 beschrieben.
ratCriteria Dies ist eine der wichtigsten Tabellen im Datenmodell, man
erkennt dies bereits an seiner zentralen Stellung und dass
dort ,alle Fden zusammenlaufen". Hier werden nmlich alle
Kriterien (Faktoren), welche fr die Bewertung bentigt wer-
den abgespeichert. (objektive und subjektive)
ratClassCriteria Dies ist die Tabelle zur Auflsung der n:m Beziehung zwi-
schen den Kriterien und den Klassen.
ratRating Hier werden alle vom Benutzer durchgefhrten Bewertungen
abgespeichert.
veObjekte Diese Tabelle wird fr die Bewertung der objektiven Faktoren
bentigt. Es wird gespeichert ob ein DB-Objekt eine Auktion
oder eine Ausschreibung ist, und je nachdem werden dann
die richtigen Auswertungen geladen.
veFirmen Hier werden die einzelnen Firmen (bzw. Lieferanten) abge-
speichert.


Systemarchitektur Seite 52
9.1.3 physisches DatenmodeII

Abbildung 7: physisches Datenmodell
m physischen Datenmodell werden auch die einzelnen Attribute sowie die Da-
tentypen - wie sie in der mplementierung verwendet werden - angefhrt.
Systemarchitektur Seite 53
9.1.3.1 direkte Bezugnahme zu den BewertungsmodeIIen
9.1.3.1.1 NutzwertanaIyse
Genauere Beschreibung der NWA siehe Punkt 6.4.3.2
P
j
. erreichte Punkte Firma j wird berechnet, nicht
gespeichert
m . Anzahl der Attribute wird auch berechnet,
alle Attribute in Tabelle
ratCriteria gespeichert
w
i
. Gewichtung Attribut i Tabelle: ratCriteria,
Attribut: Weight

=
=



0
*
p
ij
. Benotung Attribut i fr
Firma j
Tabelle: ratRating,
Attribut: Value

9.1.3.1.2 Bewertung der Auktionen und Ausschreibungen
Genauere Beschreibung der Modelle siehe Punkt 8.2.2
Smtlicher beschriebene Faktor (z.B. Anzahl der Einladungen, Anzahl der Teil-
nahmen) wird in einem Attribut gespeichert:
Tabelle: ratRating, Attribut: Value
Value nimmt immer den Wert 1 (positive Bewertung) oder 0 (negative) an. Kei-
ne Bewertung erfolgt wenn kein Datensatz in die Tabelle eingetragen wird.
Um dann auf die beschriebenen Bewertungsmodell zu kommen werden einfach
nur die Anzahl der positiven Bewertungen addiert.

Systemarchitektur Seite 54
9.1.3.2 physische TabeIIenbeschreibung
TabeIIe Attribut Beschreibung
D Dies ist die D der jeweiligen Tabelle, falls
eine bentigt wird. Der Name besteht aus
D+Tabellenname. Die Tabelle ratClassCri-
teria hat zum Beispiel keine eigene D, weil
sie ber zwei zusammengehngte Fremd-
schlssel identifiziert wird.
Name Die jeweilige Bezeichnung des Datensatzes,
falls bentigt. (z.B. Name in ratCriteria ist die
Bezeichnung fr ein Bewertungskriterium)
Allgemein
Fremdschlssel Fremdschlssel beginnen immer mit der
Bezeichnung FKD+ den Tabellennamen der
Tabelle, die sie referenzieren. (Beispiel:
FKDType ist ein Fremdschlssel mit Refe-
renz auf die Tabelle ,Type")
LowerLimit Unteres Limit fr die Bewertungsskala, (nur
bei subjektiven Kriterien).
UpperLimit Oberes Skalenlimit
AccumuIative st ein Flag, ob das jeweilige Kriterium ein
subjektives (0) oder ein objektives (1) ist.
Der Name accumulative kommt daher, dass
alle objektiven aggregierbar sind.
ratCriteria
Weight jeweilige Gewichtung des Kriteriums (z.B.
0,2 fr 20%) (nur fr subjektive Kriterien)
Systemarchitektur Seite 55
ratClassCriteria LimitValue Ab diesem Limit beginnt eine bestimmte
Klasse, das heit es ist ein unteres Limit.
Alle Lieferanten, welche eine hhere Bewer-
tung haben, fallen in diese Klasse.
Date das Bewertungsdatum (Timestamp) ratRating
VaIue Hier wird der Wert der Bewertung eingetra-
gen. Bei den subjektiven Kriterien ist es der
eingegebene Wert des Benutzers. Bei den
objektiven Kriterien ist es eher mehr ein
Flag, und zwar wird 1 fr eine positive und 0
fr eine negative Bewertung gespeichert.
Falls der Benutzer warum auch immer keine
objektive Bewertung fr einen gewissen Lie-
feranten vornehmen will, dann wird ber-
haupt kein Datensatz gespeichert.
Daher: 1 fr positive, 0 fr negative und
kein Eintrag fr neutraIe Bewertung (bei
den objektiven Kriterien)
veObjekte ObjektTyp Dieses Attribut gibt an, um was fr ein Ob-
jekt es sich handelt. Die Vorgabe der Part-
nerfirma war 13 fr Auktionen und 14 fr
Ausschreibungen. Dies ist sehr wichtig fr
die Auswahl der richtigen Auswertung fr die
objektiven Kriterien.
veFirmen Ansprech-
partner
erklrt sich von selbst...
Anmerkung: Fett geschriebene Attribute sind fr die Logik des Programms be-
sonders wichtig.
Systemarchitektur Seite 56
9.1.4 Namenskonventionen der Partnerfirma
9.1.4.1 TabeIIennamen
Sie beginnen immer mit dem Krzel ,rat", und dann einer sinnvollen Bezeich-
nung. Das Krzel bedeutet ,Rating" und es erlaubt im Nachhinein die Tabellen
fr die einzelnen Module des gesamten Systems auseinander zuhalten.
Ausnahmen sind ,veFirmen" und ,veObjekte", da dies schon vorhandene Tabel-
len aus dem bestehenden Datenmodell sind.
9.1.4.2 IDs
Die Ds der einzelnen Tabellen setzen sich immer folgendermaen zusammen:
D + Tabellenname.
Beispiel: ,DCriteria"
9.1.4.3 FremdschIsseI (Foreign Keys)
Die Fremdschlssel der einzelnen Tabellen setzen sich immer folgendermaen
zusammen: FKD + Name der referenzierten Tabelle.
Beispiel: ,FKDCriteria" in der Tabelle ,ratClassCriteria"
9.1.4.4 Attributnamen
Werden wie Klassennamen in Java geschrieben, das heit alles zusammenge-
schrieben, beginnend mit einem Grobuchstaben und jedes neue Wort beginnt
wieder mit einem Grobuchstaben. Auerdem sollen sie sprechend sein. Das
Namensattribut einer Tabelle soll immer ,Name" heien.
Beispiel: ,LowerLimit" in der Tabelle ,ratCriteria"
9.1.4.5 n:m AufIsungstabeIIen
Beginnend mit ,rat", danach die beiden Tabellennamen aneinander gehngt.
Beispiel: ,ratClassCriteria" ist Auflsung der Beziehung zw. Class und Criteria

Systemarchitektur Seite 57
9.2 Designdiagramme
9.2.1 Use Case Diagramm

Abbildung 8: Use Case Diagramm
Der Akteur ,Administrator" erbt smtliche Funktionalitten vom Akteur ,Benut-
zer". Zustzlich kann er noch objektive Kriterien anlegen. Dies kann der Benut-
zer nicht tun, da sich bei nderung der Anzahl der objektiven Kriterien auch das
Bewertungsmodell ndert. Dies erfordert eine Umprogrammierung des Ratings.
Hingegen knnen subjektive Kriterien beliebig hinzugefgt werden.
Systemarchitektur Seite 58
9.2.2 EPK BeispieI ,subjektive Kriterien anIegen"

Abbildung 9: EPK ,subjektive Kriterien anlegen"
Systemarchitektur Seite 59
9.2.3 EPK BeispieI
,Auswertung: LieferantenkIasse anzeigen"

Abbildung 10: EPK ,Auswertung: Lieferantenklasse anzeigen"
Systemarchitektur Seite 60
9.3 Programmiersprache
9.3.1 Was ist PHP?
,PHP (Akronym fr "PHP: Hypertext Preprocessor") ist eine weit verbreitete und
fr den allgemeinen Gebrauch bestimmte Open Source Skriptsprache, welche
speziell fr die Webprogrammierung geeignet ist, und in HTML eingebettet wer-
den kann." [siehe Php04]
Fr die Programmierung habe ich PHP4 verwendet.
9.3.2 Was kann PHP?
PHP ist auf serverseitige Skripte fokussiert, daher ist es hnlich zu CG-Skripts.
Die Funktionalitten wie Formulardaten verarbeiten, dynamische Websites zu
generieren oder Cookies zu senden und zu empfangen sind damit vorhanden.
Das Hauptfeld von PHP sind serverseitige Skripte. Dazu bentigt man 3 Dinge:
den PHP Parser (CG oder Server-Modul), einen Webserver und einen Web-
browser. Auf dem Webserver muss das lauffhiges PHP-Modul installiert sein,
welches dann fr den Benutzer mit seinem Browser sichtbaren HTML-Code
generiert. [vgl. Php04]
9.3.3 BeispieI eines PHP-Skripts

Systemarchitektur Seite 61
9.4 Webserver
ch verwende Apache als Webserver. Apache ist einer der weltweit hufigsten
eingesetzten Webserver. Er zeichnet sich vor allem durch seine hohe Verfg-
barkeit auf fast allen Betriebssystemen, die hohe Performance und die geringen
Hardwareanforderungen aus. Auerdem ist Apache, genau wie PHP, ein Open-
Source-Projekt und somit kostenlos.
Um PHP unter Apache verwenden zu knnen muss man nur das dazugehrige
Modul installieren, und schon kann man PHP-Skripte ausfhren.
Mehr dazu unter www.apache.org
9.5 ZusammenspieI der Komponenten
Der Client schickt eine HTTP-Anfrage an den Webserver (Apache). Der Web-
server hat das PHP-Modul installiert und ruft daher das vom Client gewnschte
PHP File auf. Er interpretiert es und erstellt ein HTML File, welches er dem
Client als Antwort zurcksendet.
Meistens wird im Zuge der nterpretation des PHP-Skripts auch ein Datenbank-
zugriff stattfinden, welcher auch ber PHP implementiert wird.
Hierzu eine Grafik zur Veranschaulichung:

Abbildung 11: Zusammenspiel der Komponenten
Screenshots der AppIikation Seite 62
10 Screenshots der AppIikation
10.1 Startseite

Abbildung 12: Startseite

Abbildung 13: Men vergrert
Screenshots der AppIikation Seite 63
10.2 Kriterium anIegen

Abbildung 14: Grenzwert (Klasse) anlegen

Abbildung 15: Kriteriumart anlegen

Abbildung 16: Kriterium anlegen
Screenshots der AppIikation Seite 64
10.3 Kriterieninformationen anzeigen

Abbildung 17: Kriterien anzeigen

Abbildung 18: Kriterieninformationen anzeigen (fr ,Qualitt")
objektive Kriterien


subjektive Krit.

Screenshots der AppIikation Seite 65
10.4 Gewichtung und Bewertung

Abbildung 19: subjektive Kriterien gewichten

Abbildung 20: Einen Lieferanten bewerten (,Lieferant A")

Abbildung 21: Alle Lieferanten bewerten
Screenshots der AppIikation Seite 66
10.5 Auswertungen
10.5.1 AIIgemeines

Abbildung 22: Auswertung auswhlen
Anmerkung: Die Auswertungen werden in 2 Frames im Browser geffnet, daher
kann man immer eine Auswertung auswhlen ohne den Zurck-Button betti-
gen zu mssen.

Abbildung 23: Demonstration der Auswertungsframes
Screenshots der AppIikation Seite 67
10.5.2 OptionaIe Notenbereiche

Abbildung 24: Lieferantennoten anzeigen (Optionale Notenbereiche)
Anmerkung: Vorher muss der Lieferant natrlich ausgewhlt werden.
10.5.3 LieferantenkIassifikation

Abbildung 25: Alle Lieferanten einer Klasse anzeigen (,B-Lieferant")
Anmerkung: Dies funktioniert auch vice versa, d.h. man kann die erreichte Klas-
se eines einzelnen Lieferanten anzeigen lassen.
Screenshots der AppIikation Seite 68
10.5.4 NutzwertanaIyse
Zuerst die Auswertung falls alle Wertebereiche der Kriterien gleich sind (hier 1
bis 10). Dies fhrt zu der Anwendung der ,normalen" Nutzwertanalyse.

Abbildung 26: ,Normale Nutzwertanalyse"
Jetzt folgt das Szenario der unterschiedlichen Wertebereiche, was zu einer ein-
fachen Addition der Bewertungspunkte (Punkteaddition) fhrt. Wie man erken-
nen kann, ist auch die maximal erreichbare Punkteanzahl angefhrt.

Abbildung 27: ,adaptierte Nutzwertanalyse" (Punkteaddition)
Screenshots der AppIikation Seite 69
10.5.5 Auswertung der objektiven Kriterien

Abbildung 28: Auswertung der objektiven Kriterien fr Auktionen (Kriterium 1)

Abbildung 29: Selbiges fr die Kriterien 2,3
Anmerkung: Der genaue Ablauf dieser Auswertung wird in Punkt 8.2.2.1 be-
schrieben. Die Auswertung fr Ausschreibungen in Punkt 8.2.2.2. Hierfr habe
ich keinen Screenshot beigefgt, da die Auswertungen relativ hnlich aussehen.
WesentIiche CodeteiIe Seite 70
11 WesentIiche CodeteiIe
11.1 AIIgemeines ber den Code
Der Code wurde wie schon gesagt in PHP programmiert. nsgesamt wurden 35
PHP-Files erstellt, welche alle eine unterschiedliche Funktion haben.

Abbildung 30: Auflistung der PHP-Files
Der Aufbau der Administration (Kriterien hinzufgen, etc) ist folgendermaen:
Es gibt 2 Files fr jede Funktion, eine um das HTML-File zu genieren und eines
um die Eingaben zu verarbeiten. (Beispiel: insert_art.php, do_insert_art.php)
Die Auswertungen fangen entweder mit ,rep_", mit ,show_" oder mit ,info_" an.
ch habe immer versucht sprechende Dateinamen zu verwenden, damit die
Partnerfirma den Code auch versteht und verwenden kann.
WesentIiche CodeteiIe Seite 71
11.2 Einfgen in die DB (Insert)
Die Datenbankzugriffe sind fast die wichtigsten Codeteile der Applikation, daher
erklre ich sie hier etwas genauer. (nsert und Select)
Anbei das Beispiel ,Kriteriumart hinzufgen" (Datei: do_insert_art.php).

Der PHP-Block beginnt immer mit ,<?php" (Zeile 1) und endet mit ,?>" (Zeile
17), damit der Webserver wei, welcher Teil des Codes PHP ist. Der Rest ist
reiner HTML-Code.
Zuerst wird die Verbindung mit der DB aufgebaut mittels mysql_connect() (Zeile
3-4). Danach wird die gewnschte Datenbank ausgewhlt (es knnte ja mehre-
re DB-nstanzen geben) mittels mysql_select_db() (Zeile 5-6). Darauf folgt das
Absetzen einer Query (Abfrage) an die Datenbank mittels mysql_query() (Zeile
9-12). Schlielich muss die Verbindung zur DB geschlossen werden mit der
Funktion mysql_close() (Zeile 15).
Echo bedeutet eine schlichte HTML-Ausgabe (Zeilen 10,16).
WesentIiche CodeteiIe Seite 72
11.3 HerausIesen aus der DB (SeIect)
Zur Erklrung ein Ausschnitt aus der Datei show_lief.php:

Das Herauslesen aus der DB verluft hnlich. Zuerst wird die Query an die DB
geschickt (Zeile 25-27), nun muss aber das Ergebnis ($result) ausgewertet
werden.
Dies geschieht mittels einer Verarbeitungsschleife, in der jeder Datensatz (ent-
spricht einer Zeile in einer Tabelle) in ein Objekt ,gefecht" wird (Schleifenkopf
siehe Zeile 29). Das heit es wird daraus ein Objekt erstellt ($row), auf welches
dann direkt zugegriffen werden kann.
Die Variablen $id, $name und $ap werden aus dem Objekt herausgelesen (Zei-
le 30-32) und nachher mitten im HTML Code als Links (<a href>) in einer Tabel-
le (<tr>,<td>) ausgegeben (Zeile 35-39).
Zu beachten ist, dass es 2 PHP-Blcke gibt. Von Zeile 34 bis 40 ist ein reiner
HTML-Block, in dem nur einzelne Variablen mittels PHP ausgegeben werden.
(z.B. Zeile 36: <?= $id ?> gibt die Variable $id direkt aus)
WesentIiche CodeteiIe Seite 73
11.4 Auswertung der Auktionen
Dies ist eine sehr komplexe Angelegenheit. Das PHP-File
(rep_acc_auctions.php) hat ungefhr 180 Lines of Code, was fr ein PHP-File
sehr viel ist. Es besteht aus 4 wesentlichen Teilen, und zwar: Aufbau der DB-
Verbindung sowie die Auswertung der 3 Faktoren. (siehe 8.2.2.1) Die Auswer-
tungen selbst bestehen wiederum aus mehreren Teilen, und zwar aus 1-2 eige-
nen DB-Zugriffen, mehreren Schleifen und Ausgabe von HTML-Code (meist
Tabellen). Hier werde ich nur die Auswertung des ersten Faktors (Anzahl der
Einladungen) erklren, da er am leichtesten verstndlich ist. Hier ist ein Auszug
aus der Datei:

WesentIiche CodeteiIe Seite 74
Es beginnt mit der Auswahl aller Firmen. (DB Select auf Tabelle veFirmen
Zeile 39-41) Diese werden dann alle durchgelaufen und einzeln ausgewertet
(erste while-Schleife, Schleifenkopf siehe Zeile 44).
Darauf folgt ein relativ kompliziertes SQL Statement, welches alle Einladungen
der gerade zu bearbeitenden Firma mittels der FirmenD ($l_id) aus der DB he-
rausliest (Zeile 50-58). Kompliziert daher, weil es aus einem JON ber 3 Tabel-
len (Zeile 51) und einer Zhlfunktion (count, Zeile 50), welche ein eigenes Grup-
pierungselement (GROUP BY, Zeile 58) bentigt, besteht. Die Art der Auswer-
tung erkennt man an der Zeile ,ObjektTyp = $id_auktionen" (Zeile 54) im SQL
Statement. Die Variable $id_auktionen muss natrlich vorher im Code initiali-
siert werden.
Danach wird dieses SQL Statement in der zweiten Auswertungsschleife in einer
HTML-Tabelle ausgegeben. (Zeile 63-67)
Der Name des Lieferanten wird zustzlich noch in einem 2-dimensionalem Ar-
ray (einl_arr, siehe Zeile 42 und 66) gespeichert und gemerkt, da die Anzahl der
Einladungen fr die weiteren Auswertungen (Zuschlge und Teilnahmen) ben-
tigt werden.
Dieses PHP-File ist eines der kompliziertesten der gesamten Applikation. Wenn
man es nicht auf Anhieb versteht, sollte man sich keine groen Sorgen ma-
chen, es dauerte auch entsprechend lange es zu entwickeln.
Projektmanagement Seite 75
12 Projektmanagement
Abschlieend werde ich noch kurz auf das von mir whrend der Laufzeit des
Projekts betriebene Projektmanagement eingehen. Folgende Punkte erschei-
nen mir als wichtig:
Entwicklungsmodell
Soll-st-Vergleich der Stunden und der Projektdauer
Risikoanalyse
12.1 EntwickIungsmodeII
Die Projektentwicklung lief nach dem Wasserfallmodell ab.
12.1.1 Projektphasen des WasserfaIImodeIIs
Folgende Phasen waren lt. Disposition vorgesehen:
Voruntersuchung
Analyse
Design
mplementierung
Test
Die Phasen wurden per Definition des Wasserfallmodells sequentiell durchlau-
fen. Eine Phase galt erst als abgeschlossen, wenn die definierten Ziele erreicht
und die notwendigen Dokumente erstellt worden waren. Rcksprnge in vorhe-
rige Phasen waren nur in Ausnahmefllen erlaubt, da sie meist mit erheblichen
Problemen einhergehen. Einen Sprung von der mplementierung zurck in das
Design habe ich bereits in Punkt 8.4 beschrieben (Abschaffung des Hierarchi-
schen Systems). Ebenso kompliziert war die anfangs nicht geplante Einfhrung
der Lieferantenklassifikation, welche erhebliche nderungen mit sich brachte.
Projektmanagement Seite 76
12.1.2 Ergebnisse der einzeInen Projektphasen
Jede Phase des Wasserfallmodells hatte lt. Disposition ihre definierten Ziele
und Ergebnisse.
Projektphase TeiIbereich Ergebnis siehe
Literaturrecherche durchfhren Punkt 6
geeignetes Bewertungssystem finden 8.2 8.4
Filtern und Herausarbeiten relevanter
Bewertungsfaktoren
8.1
Voruntersuchung
grobes Systemmodell fr Prsentations-
zwecke erstellen
Disposition 4.2
genaue Beschreibung und Definition der
Bewertungsfaktoren
8.1
Hierarchisches Modell der Faktoren mo-
dellieren
8.5
logisches Datenmodell erstellen 9.1.2
genaues Systemmodell erstellen Punkt 8
Analyse
Risikoanalyse durchfhren 12.3
Systemarchitektur des Prototyps erstel-
len
Punkt 9
Ressourcenverwendung beschreiben 9.1 9.4
Design
physisches Datenmodell erstellen 9.1.3
Projektmanagement Seite 77

Sourcecode erzeugen erzeugter
Sourcecode
mplementierung
Technische Dokumentation schreiben Punkt 10, 11
sowie Kommen-
tare im Code
System testen Fehlerfrei
funktionierende
Applikation
Test
Testprotokolle erstellen Siehe einzelnen
Testprotokolle

12.1.3 SchIussfoIgerung
Es wurden, wie man im vorherigen Punkt erkennen kann, aIIe definierten ZieIe
erreicht sowie einige Mehrarbeit verrichtet.
Beispiele fr die Mehrarbeit sind: Beschreibung der Organisation und der Kon-
sequenzen eines Ratings, Dokumentation des Projektmanagements, mple-
mentierung der Lieferantenklassifikation sowie der optionale Notenbereiche,
uvm.
Projektmanagement Seite 78
12.2 SoII-Ist-VergIeich
12.2.1 ZeitpIanung (Termine)
Task
Startdatum
(SoII)
Startdatum
(Ist)
Dauer in
Tagen
(SoII)
Dauer in
Tagen
(Ist)
Enddatum
(SoII)
Enddatum
(Ist)
Projektmanagement 12.05.2004 12.05.2004 155 140 13.10.2004 28.09.2004
Voruntersuchung 12.05.2004 12.05.2004 15 12 26.05.2004 23.05.2004
Analysephase 27.05.2004 24.05.2004 35 16 30.06.2004 08.06.2004
Designphase 01.07.2004 09.06.2004 25 22 25.07.2004 30.06.2004
mplementierungsphase 26.07.2004 01.07.2004 60 80 23.09.2004 18.09.2004
Testphase 24.09.2004 19.09.2004 10 5 03.10.2004 23.09.2004
Projektabschluss 04.10.2004 24.09.2004 10 5 13.10.2004 28.09.2004
12.2.2 Interpretation
ch habe fr das Projekt insgesamt krzer gebraucht als ursprnglich veran-
schlagt. Die Soll-Dauer war 155 Tage und tatschlich gebraucht habe ich aber
nur 140 Tage (15 Tage oder ein halbes Monat krzer). Dies liegt wahrscheinlich
daran dass die Zeitschtzung mit viel Spielraum ausgelegt war.
Auffallend ist, dass fast alle Phasen krzer gedauert haben. Die Analysephase
hat betrchtlich krzer gedauert (16 statt 35 Tage). Dies ist darauf zurckzufh-
ren dass viele Ttigkeiten bereits in der Voruntersuchungsphase sehr gut vor-
bereitet waren und in der Analysephase nicht mehr viel fr diese Dinge zu tun
war. (z.B. die Untersuchung der Bewertungsfaktoren) Die mplementierungs-
phase hat als einzige lnger gedauert (80 statt 60 Tage). Dies liegt daran, dass
einige Punkte nachtrglich erst aufgetaucht sind, welche einen Rcksprung in
die Designphase erforderten. (siehe 12.1.1)
Die Verfassung dieser Arbeit habe ich zum Zeitpunkt der Planung, aus Grnden
der unbekannten universitren Beanspruchung des folgenden Semesters, we-
der zeitlich noch terminlich geplant.
P
r
o
j
e
k
t
m
a
n
a
g
e
m
e
n
t

S
e
i
t
e

7
9

1
2
.
2
.
3

G
a
n
t
-
C
h
a
r
t
-
V
e
r
g
I
e
i
c
h

1
5
5
1
5
3
5
2
5
6
0
1
0
1
0
1
2
.
5
.
0
4
2
6
.
5
.
0
4
9
.
6
.
0
4
2
3
.
6
.
0
4
7
.
7
.
0
4
2
1
.
7
.
0
4
4
.
8
.
0
4
1
8
.
8
.
0
4
1
.
9
.
0
4
1
5
.
9
.
0
4
2
9
.
9
.
0
4
1
3
.
1
0
.
0
4
P
r
o
j
e
k
t
m
a
n
a
g
e
m
e
n
t
V
o
r
u
n
t
e
r
s
u
c
h
u
n
g
A
n
a
I
y
s
e
p
h
a
s
e
D
e
s
i
g
n
p
h
a
s
e
I
m
p
I
e
m
e
n
t
i
e
r
u
n
g
s
p
h
a
s
e
T
e
s
t
p
h
a
s
e
P
r
o
j
e
k
t
a
b
s
c
h
I
u
s
s

1
4
0
1
2
1
6
2
2
8
0
5
5
1
2
.
5
.
0
4
2
6
.
5
.
0
4
9
.
6
.
0
4
2
3
.
6
.
0
4
7
.
7
.
0
4
2
1
.
7
.
0
4
4
.
8
.
0
4
1
8
.
8
.
0
4
1
.
9
.
0
4
1
5
.
9
.
0
4
2
9
.
9
.
0
4
1
3
.
1
0
.
0
4
P
r
o
j
e
k
t
m
a
n
a
g
e
m
e
n
t
V
o
r
u
n
t
e
r
s
u
c
h
u
n
g
A
n
a
I
y
s
e
p
h
a
s
e
D
e
s
i
g
n
p
h
a
s
e
I
m
p
I
e
m
e
n
t
i
e
r
u
n
g
s
p
h
a
s
e
T
e
s
t
p
h
a
s
e
P
r
o
j
e
k
t
a
b
s
c
h
I
u
s
s

A
b
b
i
l
d
u
n
g

3
1
:

V
e
r
g
l
e
i
c
h

v
o
n

S
o
l
l
-

u
n
d

s
t
-
G
a
n
t
-
C
h
a
r
t
Projektmanagement Seite 80
12.3 RisikoanaIyse
Risiko Geplant Eingetr. Lsungen /
Anmerkungen
Technisches ReaIisierungsrisiko
Kein Arbeitsplatz bei der
Partnerfirma vorhanden
Ja Ja Laptop verwendet
Bugs bei der verwendeten
PHP-Version
Ja Nein
Sicherheitsrisiken Ja Nein
Portabilitt auf das Vemap-
System nicht gewhrleistet
Ja Nein
Datenbankanbindung funk-
tioniert nicht einwandfrei
Ja Nein
PIanungsrisiko
Zeitmangel wg. Uni Ja Ja Verschiebung einer LV
in das nchste Semester
Motivationsmangel Ja Ja Aufgrund des teilweise
fehlenden Feedbacks
der Partnerfirma
Krankheiten Ja Nein
Zielsetzung zu hoch Ja Nein
Ziel zu ungenau definiert Ja Nein
Projektmanagement Seite 81

Verwertbarkeitsrisiko
Applikation wird von der
Partnerfirma nicht akzeptiert
Ja Nein
Zu wenig Literatur zum
Thema auffindbar
Ja Nein
Verfassung der Bakkalau-
reatsarbeit nicht mglich
Ja Nein

Erfreulicherweise sind nur wenige der geplanten Risiken eingetreten. Auch die
Tragweite des Eintretens war nicht so gro, dass das Projekt zu irgendeinem
Zeitpunkt gefhrdet gewesen wre.
Das Hauptproblem war der Zeitmangel aufgrund der anderen universitren
Verpflichtungen und Belastungen. Dieses Problem habe ich durch die Ver-
schiebung einer Lehrveranstaltung in das darauf folgende Semester sowie
durch das Einlegen einiger ,Nachtschichten" gelst.


Kritische Wrdigung Seite 82
13 Kritische Wrdigung
nsgesamt kann ich sagen, dass das T-Praktikum eine sehr positive Erfahrung
fr mich war. Da ich schon einige Berufserfahrung mitbringe und doch eher ein
Mann der Praxis bin, war das Praktikum willkommen neben dem doch eher the-
oretischen Alltag der anderen Lehrveranstaltungen im Studium. Weiters fand
ich es sehr gut, dass das Praktikum mit einer Partnerfirma durchgefhrt wurde,
da ich dadurch einen guten Einblick in das Tagesgeschft einer kleinen, jedoch
erfolgreichen, Firma bekommen konnte.
Auch die Verfassung dieser Arbeit hat mir viel Spa gemacht. Zuerst wusste ich
berhaupt nicht was ich schreiben sollte, doch nach Untersttzung von Dr. Ale-
xander was denn ungefhr zu schreiben wre, sind mir immer mehr Punkte
eingefallen, die ich gerne niederschreiben wollte. Auch das wissenschaftliche
Arbeiten hat mir gefallen. Es hat sich als sehr sinnvoll erwiesen, zu aller erst
eine Literaturrecherche durchzufhren, damit ich auch etwas sinnvolles auf die
Beine stellen konnte.
Die Aufgabenstellung habe ich mir mit Hrn. Zimmermann zusammen ausge-
sucht. ch wollte doch ein eher betriebswirtschaftlich angehauchtes Thema be-
arbeiten, nur eine technische Arbeit alleine wre mir zu wenig gewesen. Da hat
die Problematik der Lieferantenbewertung als Teilbereich des Supply Chain
Managements sehr gut gepasst.
Die Kooperation mit der Partnerfirma verlief im Groen und Ganzen gut. Meine
Betreuer, Hr. Frhlich und Hr. Zimmermann, haben immer schnell auf meine
Fragen geantwortet und untersttzen mich wenn sie konnten. Wir haben uns
relativ oft persnlich getroffen um ber den Projektfortschritt zu sprechen, was
mir auch sehr gut gefallen hat. ch hatte dadurch das Gefhl etwas Wichtiges
fr das Unternehmen zu bearbeiten.
Die Kooperation und Kommunikation mit Hrn. Dr. Alexander verlief ebenfalls
bestens. Als ich bei ihm um das Praktikum ansuchte, hat er sofort zugestimmt
und mir den Kontakt zur Partnerfirma vermittelt. Whrend des Projektes war die
Kommunikation auch sehr gut. Er hat immer wieder den Status erfragt, wodurch
Kritische Wrdigung Seite 83
ich niemals wirklich in Versuchung kam, nicht weiter zu arbeiten. Auerdem
wusste er auf meine Fragen immer eine Antwort. Auerdem half er mir zum
Beispiel bei der Strukturierung dieser Arbeit sehr, und er gab mir auch sonst
einige gute Tipps fr die Entwicklung des Ratings.
Whrend des Projekts hatte ich immer eine klare Vorstellung, wie es weiterge-
hen knnte. Obwohl es ein paar spte nderungen des Designs whrend der
mplementierungsphase gab, war dies kein wirklich groes Problem. Die gr-
ten nachtrglichen nderungen waren erstens die Einfhrung einer Lieferan-
tenklassifikation und zweitens die Abschaffung des hierarchischen Aufbaus.
Das Datenmodell musste gendert werden und einiger Code wurde obsolet,
und musste daher neu geschrieben werden. Dadurch wurde ich zwar zeitlich
etwas zurckgeworfen, jedoch hatte ich trotzdem immer ein klar definiertes Ziel
vor Augen.
Mein grter Vorteil whrend des Projekts war meine bereits gesammelte Er-
fahrung aus der Praxis. ch hatte schon vor dem Praktikum einige T-
Softwareentwicklungsprojekte durchgefhrt und auch erfolgreich abgeschlos-
sen. Auch in der Schule hatte ich eine fundierte T-Ausbildung. Mit den einge-
setzten Ressourcen (PHP und MySQL) hatte ich vorher auch schon gearbeitet,
was mir die Einlernphase groteils ersparte. ch musste mich ,nur" in die Mate-
rie des Lieferantenratings einarbeiten.
Bei der mplementierung gab es auch keine groen Probleme, da ich ja wie ge-
sagt schon vorher mit PHP programmiert habe. Falls doch Schwierigkeiten auf-
traten waren die relativ einfach durch den Einsatz von Newsgroups oder Google
zu lsen.
Zusammenfassend kann ich sagen dass ich whrend des gesamten Praktikums
und whrend des Verfassens der Bakkalaureatsarbeit viel Spa hatte und auch
viel dabei gelernt habe.


Literaturverzeichnis Seite 84
14 Literaturverzeichnis
[DiSc04] Disselkamp Markus, Schller Ralf: Lieferantenrating - nstrumente,
Kriterien, Checklisten. Gabler Verlag, Wiesbaden 2004
[Feic88] Feichtinger, Alois: Lieferantenbewertung in sterreich. Eine empirische
Untersuchung. Diplomarbeit, nstitut fr Unternehmensfhrung, WU-Wien, 1988
[Hans01] Hansen, Hans R.: Wirtschaftsinformatik . Grundlagen betrieblicher
nformationsverarbeitung. 8. Aufl. Lucius & Lucius, Stuttgart 2001.
[HoBa04] Hofbauer, Prof. Dr. Gnter, Bauer, Dipl.-Betriebswirt (FH) Christian:
ntegriertes Beschaffungsmarketing. Der systematische Ansatz im Wertschp-
fungsprozess. Verlag Franz Vahlen, Mnchen 2004
[Php04] diverse Autoren.: PHP-Online Dokumentation.
http://www.php.net/manual/de/index.php, Abruf am 2004-11-18
[RiWe01] Riffner, Bernhard, Weidelich, Ral: Professionelles Lieferantenmana-
gement. So arbeiten Kunden und Lieferanten erfolgreich zusammen. Fachver-
lag Deutscher Wirtschaftsdienst, Kln 2001
[Tane79] Tanew-liitschew, Mag. Dr. Gerhild: Lieferantenbewertung. Dissertati-
on, nstitut fr Unternehmensfhrung, WU-Wien 1979
[Vema04] Firma vemap.com.: nformationshomepage. http://www.vemap.com,
Abruf am 2004-11-01