Post on 12-Aug-2019
transcript
HNI-VERLAGSSCHRIFTENREIHEProf. Dr.-Ing. habil. Wilhelm Dangelmaier (Hrsg.)
Mohamed Hamady
Ein Ansatz zur Gestaltung des operativen
Fertigungsmanagements innerhalb der Lieferkette
Umsetzung am Beispiel eines Fertigungsmanagement-
Informationsystems für einen Automobilzulieferer
(Serienfertiger)
HEINZ NIXDORF INSTITUTUniversität Paderborn
Mohamed Hamady
Ein Ansatz zur Gestaltung des operativen Fertigungsmanagements innerhalb der
Lieferkette
Umsetzung am Beispiel eines Fertigungsmanagement-Informationssystems
für einen Automobilzulieferer (Serienfertiger)
CIP-Kurztitelaufnahme der Deutschen Bibliothek
Heinz Nixdorf Institut, Universität-GH Paderborn – Paderborn – 2003.
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwer-tung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmungdes Herausgebers und des Verfassers unzulässig und strafbar. Das gilt insbesonderefür Vervielfältigung, Übersetzungen, Mikroverfilmungen und die Einspeicherung undVerarbeitung in elektronischen Systemen.
Satz und Gestaltung: Mohamed Hamady
Herstellung: 21.01.2003, Paderborn
Printed in Germany
Hamady, Mohamed
Ein Ansatz zur Gestaltung des operativen Fertigungsmanagement innerhalbder Lieferkette/ Hamady, Mohamed – 1. Aufl. – Paderborn: HNI-Verlagsschrif-tenreihe, 2003
(HNI-Verlagsschriftenreihe, Bd. ; Wirtschaftsinformatik, insb. CIM; Herausge-ber: Dangelmaier, Wilhelm) Zugl.: Paderborn, Univ.-GH, Diss., 2003
ISBN
Ein Ansatz zur Gestaltung des operativen Fertigungsmanagements innerhalb der
Lieferkette
Umsetzung am Beispiel eines Fertigungsmanagement-Informationssystems
für einen Automobilzulieferer (Serienfertiger)
Dissertation zur Erlangung der Würde eines Doktors
der Wirtschaftswissenschaften (Dr. rer. pol.)der Universität Paderborn
vorgelegt vonDipl.-Inform. Mohamed Ould Hamady
33098 Paderborn
Paderborn, Januar 2003
Referent: Prof. Dr.-Ing. habil. Wilhelm DangelmaierKorreferent: Prof. Dr. Otto Rosenberg
Inhaltsverzeichnis i
Inhaltsverzeichnis
Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Symbolverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII
1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Problemdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Gegenstand der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.3 Ein Ansatz zur Gestaltung des operativen Fertigungsmanagements innerhalb der Lieferkette . . . . 18
2.2 Anforderungen an die Problemlösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Anforderungen an eine Strukturierung der Fertigung entlang der Lieferkette . . . . . . . . . . . . . . . . . 192.2.2 Anforderungen an die Gestaltung der Informationsflussbeziehungen . . . . . . . . . . . . . . . . . . . . . . . 222.2.3 Anforderungen an das Fertigungsmanagement-Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Arbeiten zur Strukturierung der Fertigung entlang der Lieferkette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 Arbeiten zur Klassifizierung der Erscheinungsformen der Fertigung . . . . . . . . . . . . . . . . . . . . . . . . 273.1.2 Modellierung der Fertigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.3 Supply Chain Operations Reference-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Arbeiten zur Gestaltung des operativen Fertigungsmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 Manufacturing Resource Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.2 Ansätze für die lieferkettenübergreifende Abstimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2.1 Fortschrittszahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
3.2.2.2 Just-in-Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393.2.2.3 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
3.2.3 Ansätze für die überbetriebliche Abstimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.3.1 Efficient Consumer Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423.2.3.2 Continuous Replenishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
3.2.3.3 Vendor Managed Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
3.2.3.4 Quick Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473.2.3.5 Collaborative Planning, Forecasting and Replenishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
3.2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Standards und Systeme zur Umsetzung des operativen Fertigungsmanagements . . . . . . . . . . . . . . . . . . . . 52
3.3.1 Integration von Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.1.1 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
3.3.1.1.1 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
ii Inhaltsverzeichnis
3.3.1.1.2 Open Application Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.3.1.2 Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
3.3.1.2.1 Enterprise Application Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.1.2.2 Application Linking Enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.2 Überbetriebliche Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.2.1 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
3.3.2.1.1 Electronic Data Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.2.1.2 Computer-aided Acquisition and Logistics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.2.2 Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
3.3.2.2.1 SCM-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.3.2.2.2 Lieferabrufsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3.2.2.3 Virtuelle Dispositionsdatenbank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.3 Die Internet-Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4 Zu leistende Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1 Strukturierung der Fertigung entlang der Lieferkette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1.1 Herleitung von Merkmalen der Dispositionseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.1.2 Prozessstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.1.3 Ablaufrichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.1.4 Informationsstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.1.4.1 Statische Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
5.1.4.1.1 Erzeugnisstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.4.1.2 Ressourcenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.1.4.1.3 Transformationsstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.1.4.2 Dynamische Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
5.1.4.2.1 Zeitmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.1.4.2.2 Ereignisse und Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.1.5 Herleitung von Sichten auf die Informationsstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.1.5.1 Elementare Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .995.1.5.2 Kombinierte Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
5.2 Gestaltung der Beziehungen entlang der Lieferkette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2.1 Merkmale der Interdependenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.2.2 Management der Interdependenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.2.2.1 Formen des Informationsaustausches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
5.2.2.2 Herleitung von Informationsflusstypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1125.2.2.2.1 Administrative Informationsflüsse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.2.2.2.2 Dispositive Informationsflüsse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.2.2.2.3 Instruktive Informationsflüsse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.2.2.3 Individuelle Gestaltung der Informationsflüsse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
5.2.2.4 Konstrukte zur Durchführung von Interaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
5.3 Architektur des Fertigungsmanagement-Informationssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.3.1 Komponenten der Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235.3.2 Fallbeispiel eines Automobilzulieferers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
5.3.2.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1285.3.2.2 Bildung der Dispositionseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
5.3.3 Komponenten zum Stammdatenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Inhaltsverzeichnis iii
5.3.3.1 Entwurf des Datenmodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1375.3.3.1.1 Spezifikation der Struktur einer Dispositionseinheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3.3.1.2 Spezifikation der Beziehungen zu den Dispositionseinheiten . . . . . . . . . . . . . . . . . . . . . . . 141
5.3.3.2 Schnittstelle zur Stammdatenübernahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1445.3.3.3 Umsetzung am Fallbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
5.3.4 Komponenten zum Bewegungsdatenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515.3.4.1 Entwurf des Datenmodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1515.3.4.2 Komponente zum Planungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
5.3.4.2.1 Bildung von Disponentensichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.3.4.2.2 Belegungsplanung am Fallbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1595.3.4.3 Komponente zum Bestandsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
5.3.4.4 Schnittstellen zum Bewegungsdatenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
5.3.5 Komponenten zum Kooperationsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685.3.5.1 Entwurf der Interaktionskomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
5.3.5.1.1 Informationsmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.3.5.1.2 Auswahl der Kommunikationstechnologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1725.3.5.1.3 Kommunikationskomponente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.3.5.1.4 Szenario „Supplier“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.3.5.2 Webbasierte Informationskomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1795.3.5.2.1 Erstellung der Informationsprofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
5.3.5.2.2 Szenario „Customer“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
7 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8 Anhang. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
8.1 UML-Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
8.1.1 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2018.1.2 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
8.2 Fertigungsprozessmodell des Automobilzulieferers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
8.3 Ablauf dispositiver Abstimmungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Abbildungsverzeichnis v
Abbildungsverzeichnis
Abbildung 1: Typen vernetzter Organisationen ....................................................................... 4
Abbildung 2: Merkmalsausprägung der Netzwerktypen ......................................................... 6
Abbildung 3: Skizze einer möglichen Lieferkette .................................................................... 7
Abbildung 4: Der Bullwhip-Effekt ........................................................................................ 12
Abbildung 5: Anschauliche Darstellung der Vorgehensweise von MRP-II-basierten ERP/PPS-
Systemen ................................................................................................................................. 14
Abbildung 6: Modellierung der Fertigung mittels MFERT ................................................... 32
Abbildung 7: Eigenschaften der Ereignisse ........................................................................... 32
Abbildung 8: Die Prozess-Grundtypen nach SCOR .............................................................. 34
Abbildung 9: Schematische Darstellung der Pull- und Push-Steuerung am Beispiel einer drei-
stufigen Fertigung ................................................................................................................... 36
Abbildung 10: Informationsfluss bei MRP-II ........................................................................ 37
Abbildung 11: Fortschrittzahlen und Kontrollpunkte ............................................................ 38
Abbildung 12: Regelkreissystem nach Kanban ..................................................................... 41
Abbildung 13: Bausteine des ECR ......................................................................................... 42
Abbildung 14: Zentrale Erfolgsfaktoren des ECR ................................................................. 44
Abbildung 15: Integrationstiefen des Continuous Replenishment ......................................... 46
Abbildung 16: EAI Integrationsmatrix .................................................................................. 57
Abbildung 17: Standards für den überbetrieblichen Datenaustausch .................................... 60
Abbildung 18: Beispiel eines EDIFACT-strukturierten Nachrichtenaustausches ................. 61
Abbildung 19: Funktionen von SCM-Systemen .................................................................... 66
Abbildung 20: Entwicklungstendenzen für den Einsatz von SCM-Systemen ....................... 67
Abbildung 21: Lieferabrufsystem als Bindeglied in der Lieferkette ...................................... 68
Abbildung 22: Typologie der zwischenbetrieblichen Internet-Nutzungsformen ................... 71
Abbildung 23: Vom FMI-System abzudeckende SCM-Funktionalitäten .............................. 77
Abbildung 24: Modellierung der Fertigungs- und Logistikprozesse ..................................... 81
Abbildung 25: Prozessstrukturen der Dispositionseinheiten ................................................. 84
Abbildung 26: Brutto-/Netto-Bedarf/Angebot Informationsflüsse ........................................ 85
Abbildung 27: Beispiele der Ablaufrichtung ........................................................................ 87
Abbildung 28: Dokumentation des Ablaufs in den Prozesstypen .......................................... 96
vi Abbildungsverzeichnis
Abbildung 29: Mögliche Zuordnung Ereignistypen - Sachlicher Bezug ............................... 97
Abbildung 30: Interpretationen der Ab- und Zugangsereignisse ........................................... 98
Abbildung 31: Selektion eines Ausschnittes des Ereignisraumes .......................................... 99
Abbildung 32 : Informationsflussbeziehungen einer Dispositionseinheit ........................... 105
Abbildung 33: Verbrauchsorientierte Auslösungsarten ....................................................... 108
Abbildung 34: Grundlegende Formen der Kommunikation ................................................ 111
Abbildung 35: Das Kanalkonzept ........................................................................................ 112
Abbildung 36: Änderungsereignisse der Bedarfe bzw. Angebote ....................................... 115
Abbildung 37: Push-/Pull-Mechanismen des Informationsflusses ...................................... 117
Abbildung 38: Umsetzung der Kooperationsmerkmale durch die Gestaltung der Informations-
flüsse ...................................................................................................................................... 119
Abbildung 39: Gestaltungsmerkmale individueller Informationsflüsse .............................. 119
Abbildung 40: Informationsflusstypen ................................................................................. 120
Abbildung 41: Schematischer Aufbau der Architektur ........................................................ 125
Abbildung 42: Szenarien zur informationstechnischen Integration der Dispositionseinheiten .
127
Abbildung 43: (Vereinfachtes) Fertigungsprozessmodell des Pilotwerkes ......................... 131
Abbildung 44: (Grober) Informationsfluss bei der Planung ................................................ 132
Abbildung 45: Reduziertes Fertigungsprozessmodell im Pilotwerk .................................... 135
Abbildung 46: Mögliche und tatsächliche Positionen zur Erfassung des Fertigungszustandes
136
Abbildung 47: Dispositionseinheiten im Pilotwerk ............................................................. 136
Abbildung 48: Klassenmodell zur Beschreibung der Struktur einer Dispositionseinheit .... 138
Abbildung 49: Klassen des Zeitmodells ............................................................................... 139
Abbildung 50: Klassenmodell zur Spezifikation der externen Beziehungen ....................... 141
Abbildung 51: Klassenmodell zur Abbildung der Auslösungsarten .................................... 143
Abbildung 52: Benutzungsschnittstelle zur Stammdatenübernahme ................................... 145
Abbildung 53: Hauptfenster zum Stammdatenmanagement ................................................ 146
Abbildung 54: Stages Editor ................................................................................................ 147
Abbildung 55: Parts Editor ................................................................................................... 149
Abbildung 56: Customer Editor ........................................................................................... 150
Abbildung 57: Customer Information Editor ....................................................................... 150
vii Abbildungsverzeichnis
Abbildung 58: Klassenmodell zur Abbildung der Bewegungsdaten ................................... 152
Abbildung 59: Zuordnung der Klassen zu den Ereignissen ................................................. 153
Abbildung 60: Realisierte Dispositionseinheiten ................................................................. 154
Abbildung 61: Klassenmodell zur Bildung einer bedarfsorientierten Sicht ........................ 155
Abbildung 62: Erzeugnisstruktur am Fallbeispiel ................................................................ 156
Abbildung 63: Planungsoberfläche einer bedarfsorientierten Sicht ..................................... 157
Abbildung 64: Klassenmodell zur Bildung einer angebotsorientierten Sicht ...................... 158
Abbildung 65: Planungsoberfläche einer angebotsorientierten Sicht .................................. 159
Abbildung 66: Planungsablauf am Fallbeispiel ................................................................... 160
Abbildung 67: Grober Aufbau der Heuristik ....................................................................... 161
Abbildung 68: Skizze des Schnittstellenmanagements ........................................................ 165
Abbildung 69: Import-Management der Bewegungsdaten .................................................. 166
Abbildung 70: Klassenmodell zur Erstellung der „Informationspools“ .............................. 170
Abbildung 71: Klassenmodell zur Darstellung der Informationspools ................................ 171
Abbildung 72: Aufbau der Interaktionskomponente ............................................................ 173
Abbildung 73: Klassenmodell zur Realisierung des räumlich entfernten Objektzugriffs ... 174
Abbildung 74: Erstellung der Bedarfe an die Lieferanten ................................................... 176
Abbildung 75: Zuteilung der Bedarfe an die Lieferanten .................................................... 177
Abbildung 76: Abruf der Bedarfe beim Lieferanten ............................................................ 178
Abbildung 77: Disposition der Kundenbedarfe beim Lieferanten ....................................... 179
Abbildung 78: Grober Aufbau der webbasierten Informationskomponente ........................ 180
Abbildung 79: Editor zur Erstellung und Zuordnung der Informationsprofile .................... 181
Abbildung 80: Frontend zur Spezifikation der Parameter zur Informationsaufbereitung ... 182
Abbildung 81: Darstellung der Ergebnisse .......................................................................... 183
Tabellenverzeichnis ix
Tabellenverzeichnis
Tabelle 1: Charakterisierungsmerkmale für Produktionsnetzwerke .......................................... 5
Tabelle 2: Merkmale und Ausprägungen der Informationsflüsse ............................................ 10
Tabelle 3: Gegenüberstellung der „kapazitätsbasierten“ und der „informationsbasierten“ Ferti-
gung.......................................................................................................................................... 17
Tabelle 4: Konstrukte des Modells der Fertigung ................................................................... 30
Tabelle 5 : Abgrenzung der Ansätze zur überbetrieblichen Abstimmung ............................... 51
Tabelle 6: Ontologie der Zeit ................................................................................................... 93
Tabelle 7: Einordnung der Informationsflüsse ....................................................................... 113
Tabelle 8: Betriebstypologie des Pilotwerkes ........................................................................ 129
Tabelle 9: Grundoperationen auf dem Zeitmodell ................................................................. 140
Abkürzungsverzeichnis xi
Abkürzungsverzeichnis
ALE Application Link Enabling
APICS American Production and Inventory Control Society
APS Advanced Planning and Scheduling
BOD Business Object Document
CALS Computer aided Acquisition and Logistics Support
CORBA Common Object Request Broker
CPFR Collaborative Planning, Forecasting and Replenishment
CR Continuous Replenishment
DBMS Datenbankmanagementsystem
DCOM Distributed Component Object Model
DIN Deutsches Institut für Normung
DTF Domain Task Force
EAI Enterprise Application Integration
EDI Electronic Data Interchange
EDIFACT Electronic Data Interchange for Administration, Commerce and Transport
ECR Efficient Consumer Response
ERP Enterprise Resource Planning
HTML Hypertext Markup Language
IGES Initial Graphics Exchange Specification
IIOP Internet Inter-ORB Protocol
IOS Interorganisationssysteme
ISO International Standard Organization
i.w. im wesentlichen
JIT Just in Time
Abkürzungsverzeichnis xii
JRMP Java Remote Invocation Protocol
MES Manufacturing Execution System
MFERT Modell der Fertigung
MRP Material Requirements Planning
MRP-II Manufacturing Ressource Planning
OAG Open Application Group
ORB Object Request Broker
PDM Product Data Management
PPS Produktionsplanung und -steuerung
POS Point of Sale
QR Quick Response
QRM Quick Response Manufacturing
RFC Remote Function Call
RMI Remote Methode Invocation
SCM Supply Chain Management
SCOR Supply Chain Operations Reference-model
SGML Standard Generalized Markup Language
STEP Standard for Exchange of Product Model Data
TCP/IP Transmission Control Protocol/ Internet Protocol
URL Uniform Resource Locator
VDDB Virtuelle Dispositionsdatenbank
VM Virtual Machine
WFMS Workflow Management System
XML Extensible Markup Language
ZBI Zwischenbetriebliche Informationssysteme
Symbolverzeichnis XIII
Symbolverzeichnis
die Menge der natürlichen Zahlen(inklusive 0)
Q die Menge der rationalen Zahlen
die Menge der reellen Zahlen
die Menge der positiven reellen Zahlen
Menge der ganzen Zahlen
Potenzmenge einer Menge M
Kardinalität einer Menge M
Menge aller n-Tupel über eine Menge M
eine Schicht
Dauer der Schicht
die gegenwärtig aktueller Schicht
ℵ
ℜ
ℜ′
ℑ
2M
M
Mn
Si
∆ Si( ) Si
Saktuell
Kapitel 1: Einleitung 1
1 Einleitung
In den letzten Jahren haben dramatische Veränderungen des wirtschaftlichen Umfeldes dazu
geführt, dass viele Industrieunternehmen unter Druck geraten sind. Insbesondere das alte
Image des Industrieunternehmens als Massenproduzent von Standardprodukten für einen
ebensolchen Markt ist nicht mehr allgemeingültig. Die moderne Industrieproduktion findet in
komplexen Produktionsnetzwerken kleiner und großer Unternehmen statt, die gemeinsam ein
virtuelles Unternehmen bilden. Darüber hinaus besteht ein Trend der Konzentration auf die
Kernkompetenzen, komplexere Erzeugnisse, Kundenorientierung, auf immer kürzere Liefer-
zeiten und höhere Qualität, was dazu führt, dass die Beziehungen zwischen den Beteiligten im
Produktionsnetzwerk mehr und mehr zu den wichtigsten Wettbewerbsfaktoren zählen.
Um flexibel und effizient agieren zu können, muss jeder Knoten im Produktionsnetzwerk in
der Lage sein, einerseits die Transparenz des internen Fertigungsgeschehens zu verbessern und
andererseits den beteiligten Partnern relevante, auf die aktuelle Fertigungsplanung bezogene
Informationen bereitzustellen, um somit die zur partnerschaftlichen und vertrauensvollen
Abstimmung erforderliche Transparenz herbeizuführen. Hierzu ist ein Fertigungsmanage-
ment1 erforderlich, das einerseits der Planung und Steuerung der ggf. rechtlich unabhängigen
autonomen Organisationseinheiten innerhalb der Lieferkette Rechnung trägt und andererseits
die Kunden-Lieferanten-Beziehungen zwischen diesen Organisationseinheiten berücksichtigt.
Insbesondere im operativen Bereich würde ein solch dezentraler Ansatz zu einer Erhöhung der
Flexibilität, beispielsweise hinsichtlich der Reaktionsfähigkeit auf kurzfristige Änderungen
oder schwankende Kapazitätsbedarfe führen. Die (meisten) heutigen Systeme für das Ferti-
gungsmanagement2 sind aufgrund des von ihnen verfolgten zentralen Planungsansatzes3 und
einer vorrangigen Ausrichtung auf die innerbetrieblichen Fertigungsbelange mit der o. g.
Situation überfordert.4
Im Rahmen der vorliegenden Arbeit soll ein Ansatz zur Gestaltung des operativen Fertigungs-
managements innerhalb der Lieferkette entworfen werden, der dazu beitragen soll, die Trans-
parenz des Fertigungsgeschehens zu erhöhen und die Reaktionsfähigkeit zu verbessern. Der
Ansatz soll am Fallbeispiel eines Automobilzulieferers evaluiert werden. Die weitere Arbeit
1. Vgl. Kapitel 2 und [Zäpf00].2. Im Folgenden, aufgrund der häufigen Bezeichnungen in der Literatur, ERP/PPS-Systeme genannt
(Enterprise Resource Planning /Produktionsplanung und -steuerung).3. Auf der Basis von MRP-II (Manufacturing Ressource Planning). Siehe auch Kapitel 2.4. Vgl. [DBHHL99].
2 Kapitel 1: Einleitung
gliedert sich nun wie folgt: In Kapitel 2 wird zunächst auf die zentralen Begriffe der Problem-
stellung eingegangen. Darüber hinaus werden die Ausgangssituation und die Zielsetzung der
Arbeit vorgestellt. Anschließend werden die Anforderungen an eine Problemlösung hergelei-
tet. In Kapitel 3 wird der Stand der Technik entsprechend der in Kapitel 2 identifizierten
Untersuchungsaspekte behandelt. Dazu werden zunächst in Kapitel 3.1 Arbeiten zur Struktu-
rierung der Fertigung vorgestellt. Danach beschäftigt sich Kapitel 3.2 mit den Ansätzen zur
operativen Abstimmung der Fertigung innerhalb der Lieferkette. Zum Schluss werden in Kapi-
tel 3.3 die Systeme und Standards zur Unterstützung des operativen Fertigungsmanagements
betrachtet. In Kapitel 4 findet auf der Basis der Auswertungen von Kapitel 3 eine kurze
Zusammenfassung der zu leistenden Arbeiten statt. Das Kapitel 5 befasst sich zunächst mit
einer Strukturierung der Elemente der Lieferkette und der Modellierung ihrer Eigenschaften.
Aufbauend darauf werden in Kapitel 5.2 die Beziehungen zwischen den Elementen der Liefer-
kette untersucht und Merkmale zu ihrer Charakterisierung angegeben.
Im letzten Abschnitt dieses Kapitels wird die Architektur des Fertigungsmanagement-Informa-
tionssystems entworfen und prototypisch realisiert sowie dessen Einsatz am Beispiel eines
Automobilzulieferers aufgezeigt. Das abschließende Kapitel 6 bietet eine Zusammenfassung
und einen Ausblick auf mögliche weiterführende Arbeiten.
Kapitel 2: Problemstellung 3
2 Problemstellung
In diesem Kapitel wird zunächst der Untersuchungsgegenstand dieser Arbeit, d.h. die Gestal-
tung des operativen Fertigungsmanagements innerhalb der Lieferkette, betrachtet. Dazu ist es
erforderlich, die im Rahmen der Arbeit benutzten Begriffe (Lieferkette, operatives Fertigungs-
management und die damit verbundenen Begriffe Information und Informationsfluss (ferti-
gungsrelevant, operativ)) problemspezifisch zu definieren. Anschließend werden die
Dimensionen des Untersuchungsraumes herausgearbeitet. Dabei sollen die Problemfelder auf
dem Weg zu einer effizienten Gestaltung des operativen Fertigungsmanagement innerhalb der
Lieferkette identifiziert werden. Auf der Basis dieser Problemfelder soll dann die Zielsetzung
der Arbeit hergeleitet werden. Abschließend werden Anforderungen an die im Rahmen der
Arbeit zu entwickelnden Lösungsansätze abgeleitet.
2.1 Problemdefinition
2.1.1 Gegenstand der Arbeit
Da keine einheitlichen Begriffsdefinitionen bezüglich der Lieferkette und des operativen Ferti-
gungsmanagements innerhalb der Lieferkette existieren, werden im Folgenden die im Rahmen
der Arbeit benutzten Begriffsdefinitionen bestimmt. Weiterhin werden die hier benutzten
Begriffsdefinitionen zu den verschiedenen in der Literatur bestehenden Begriffsdefinitionen in
Beziehung gesetzt.
Lieferkette
In der Literatur1 finden sich unterschiedliche Begriffe zu vernetzten Organisationsformen, wie
z.B. Unternehmensnetzwerk, Strategisches Netzwerk2, Virtuelles Unternehmen, Lieferkette,
Logistikkette, Logistiknetzwerk3, Logistische Kette4, Added-Value-Networks5 etc., die häufig
nicht eindeutig voneinander abgegrenzt werden können. Jedoch lassen alle Bezeichnungen ein
1. Vgl. u.a. [Sydo92], [Sydo95], [Klei96], [Männ96], [Buse97], [Klin98], [Schö98], [CaAf99] und[WaBr99].2. Vgl. [Sydo95].3. Vgl. [Schö98], S. 10ff.4. Vgl. [Frigo97], S. 2.5. Vgl. [WaBr99], S. 117ff.
4 Kapitel 2: Problemstellung
konkretes Konzept vermuten, welches auf dem Zusammenschluss mehrerer Organisationsein-
heiten (sowohl inner- als auch überbetrieblich) zur Erbringung einer Leistung6 basiert.
Abbildung 17 stellt die Beziehungen zwischen einigen dieser Konzepte in verschachtelter
Form dar. In der einfachsten Form, der vernetzten Organisation, wird eine Gruppe von Organi-
sationseinheiten mit einem EDV-Netzwerk verbunden, ohne den Austausch von Ressourcen
und/oder Leistungen und ohne ein gemeinsames Ziel zu verfolgen. Virtuelle Organisation
bezeichnet eine vernetzte Organisation, in der Organisationseinheiten Ressourcen und Leistun-
gen austauschen, um eine Aufgabe zu erfüllen.8 Eine spezielle virtuelle Organisation stellt das
Virtuelle Unternehmen dar. In Anlehnung an [Schra96] ist ein virtuelles Unternehmen9 ein
hierarchisches, zunächst auf die Ausnutzung einer temporären Marktchance ausgerichtetes
Unternehmensnetzwerk, das selbst alle Unternehmungseigenschaften aufweist. Eine Speziali-
sierung des Konzeptes des virtuellen Unternehmens stellt das extendend enterprise dar, das
einen Verbund von Organisationseinheiten mit einer fokalen Organisationseinheit bezeich-
net.10
Eine Ausprägung der virtuellen Organisation stellt das Unternehmensnetzwerk dar. Dabei
besteht ein Unternehmensnetzwerk aus rechtlich selbständigen, aber wirtschaftlich interdepen-
denten Unternehmen, die durch kooperative, auf dem Gedanken der Gegenseitigkeit beru-
hende Austauschbeziehungen verbunden sind.11
6. Unter einer Leistung soll hier ein Erzeugnis oder eine Dienstleistung verstanden werden.7. Vgl. [CaAf99], S. 6.8. Ein Beispiel für die „virtuelle Organisation“ stellt die virtuelle Stadtverwaltung dar. 9. Der Begriff des virtuellen Unternehmens wird vor allem dann benutzt, wenn die Unternehmungsver-netzung (auch) auf der Nutzung interorganisationaler Informationssysteme beruht (vgl. [Sydo95], S. 631)10. Vgl. [Schra96], S. 36.
Virtuelles Unternehmen
Virtuelle Organisation
Vernetzte Organisation
„Extented
Enterprise“
Abbildung 1: Typen vernetzter Organisationen
Kapitel 2: Problemstellung 5
Die unterschiedlichen Erscheinungsformen von Unternehmensnetzwerken werden anhand ver-
schiedener Merkmale hergeleitet. In [WaBr99]12 wird in Abhängigkeit von der strategischen
Ausrichtung von Wertschöpfungsprozessen im Unternehmensnetzwerk zwischen strategi-
schen und operativen Unternehmensnetzwerken unterschieden.
In [Buse97]13 werden u.a. anhand der Merkmale Führung des Unternehmensnetzwerkes,
Organisations- und Koordinationsstrukturen, Stabilität der Beziehungen und anhand der Nut-
zung gemeinsamer Ressourcen sowie der räumlichen Distanz zwischen den Beteiligten die
Netzwerktypen strategisches14, regionales15, operatives16 Unternehmensnetzwerk und virtu-
elles Unternehmen hergeleitet.
11. Vgl. [Sydo92], S. 79ff.12. S. 109ff.13. S. 78ff, vgl. auch [BPLP96].14. Strategische Unternehmensnetzwerke werden durch ein fokales Unternehmen (häufig durch einenProduzenten, der dem Endkunden näher steht) strategisch geführt und besitzen eine hierarchische Orga-nisationsstruktur, sind relativ stabil, weisen häufig Investitionen in spezifischen Ressourcen auf und zie-len auf das gemeinsame Erreichen von Wettbewerbsvorteilen ab (vgl. [Sydo92], S. 79 ff.).15. Regionale Unternehmensnetzwerke weisen häufig eine polyzentrische Organisationsstruktur auf.Hierbei arbeiten viele - meist kleine - Unternehmen, die in räumlicher Nähe zueinander angesiedelt sind,zusammen (vgl. [Buse97], S. 95). 16. Operative Unternehmensnetzwerke haben die kurzfristige Abstimmung der Leistungen zum Ziel, so-wie insbesondere die Unterstützung der freien Fertigungs- und Logistikkapazitäten der beteiligten Unter-nehmen. Die Koordination kann dabei zentral (z.B. durch einen „Betreiber“) oder dezentral erfolgen (vgl.[Dang98b], S. 93 und [BPLP96]).
Merkmal Erläuterung
Grenze
Die Netzwerkgrenze beschreibt, wie neue Mitglieder in das Netz-werk aufgenommen werden und alte aus dem Netz ausscheiden.Die Netzwerkgrenze variiert zwischen vollständig geschlossenund vollständig offen.
DominanzMit der „Dominanz“ wird beschrieben, ob und von wem das Netz-werk dominiert wird.
Marktzugang beschreibt, wer in dem Netzwerk Zugang zu den Endkunden hat.
Erzeugnisvariabilität charakterisiert die mögliche Anzahl und Verschiedenartigkeit derErzeugnisse, die im Netz erstellt werden.
Wertschöpfungs-
variabilitätbeschreibt, wie sich die netzinterne Wertschöpfungsstruktur vonAuftrag zu Auftrag verändert.
Common
Added-Valuebeschreibt den „gemeinsamen Zusatznutzen“, den die beteiligtenUnternehmen durch die Zusammenarbeit im Netz erzielen.
Tabelle 1: Charakterisierungsmerkmale für Produktionsnetzwerke
6 Kapitel 2: Problemstellung
Bezieht sich die Zusammenarbeit in einem Unternehmensnetzwerk vor allem auf die Produkti-
onsprozesse und die damit verbundenen Logistikprozesse, so wird das entsprechende Unter-
nehmensnetzwerk als Produktionsnetzwerk bezeichnet.17 Tabelle118 legt
Charakterisierungsmerkmale fest, durch die sich das Verhalten eines Produktionsnetzwerkes
beschreiben lässt. Auf der Basis dieser Charakterisierungsmerkmale werden grundsätzlich vier
Netzwerktypen hergeleitet; das Baumnetz19, das Bus-Netz20, das Stern-Netz21 sowie das Ring-
Netz.22 Die Ausprägungen der Charaktarisierungsmerkmale für die einzelnen Netzwerktypen
sind in Abbildung 2 dargestellt.
Im Bereich der produzierenden Industrie findet man weitgehend baumähnliche Netzwerkstruk-
turen.23 Im weiteren Verlauf der Arbeit wird unter einer Lieferkette die folgende Definition
verstanden:
Definition 1: Eine Lieferkette24 ist ein sich permanent änderndes Produktionsnetzwerk mit
den Organisationseinheiten25 als Knoten und den (Austausch-)Beziehun-
gen26 zwischen den Organisationseinheiten als Kanten.
17. Vgl. [Buse97], S. 73.18. In Anlehnung an [Klin98], S. 39ff.19. Z.B. Automobilhersteller mit Zuliefererstruktur.20. Hier ensteht das Erzeugnis Stück für Stück, indem jeder Partner einen bestimmten Teil der Wertschöp-fung erbringt.21. Z.B. Taxi-Zentrale.22. Z.B. „Virtuelle Fabrik Eurogio Bodensee“. Dort wird auf einen Pool von Kapazitäten und Kompeten-zen zur Erstellung unterschiedlicher Erzeugnisse zugegriffen, um schneller und kompetenter auf Kunden-wünsche reagieren zu können. 23. Vgl. [CoLP97], S. 9.24. Die Verwendung des Begriffs „Lieferkette“ soll verdeutlichen, dass die Kunden-Lieferanten-Bezie-hungen im Produktionsnetzwerk einen zentralen Untersuchungsaspekt darstellen.25. Organisationseinheiten können Unternehmen (Hersteller, Zulieferer, Spediteur, etc.) oder aber auchWertschöpfungs-/Fertigungstufen in einem Unternehmen sein.
vollständiggeschlossen
vollständigoffen
nicht vorhanden
allePartner
stark ausgeprägt
einPartner
nicht gegeben hoch
nichtvorhanden
für jedenPartner
nicht gegeben hoch
Baum-Netz Stern-Netz Ring-NetzBus-Netz
Abbildung 2: Merkmalsausprägung der Netzwerktypen
Grenze
Dominanz
Marktzugang
Erzeugnisvar.
Wertschöpfungsvar.
Added-Value
Kapitel 2: Problemstellung 7
Bezüglich der in Tabelle 1 aufgeführten Merkmale lassen sich für die Einschränkung der obi-
gen Definition bestimmte Ausprägungen festlegen. Dabei soll die „Grenze“ der Lieferkette als
„vollständig offen“ und der „Marktzugang“ für jede Organisationseinheit als gegeben betrach-
tet werden.
In Abbildung 3 ist eine vereinfachte Struktur einer Lieferkette dargestellt. Dabei können
sowohl einzelne Fertigungs-/Wertschöpfungsstufen als auch ganze Unternehmen als Organisa-
tionseinheiten betrachtet werden.
Die Beziehungen zwischen den Organisationseinheiten in einer Lieferkette können in ver-
schiedene Arten unterteilt werden27. Material- und Informationsflussbeziehungen werden als
Wertschöpfungsbeziehungen bezeichnet. Darüber hinaus bestehen rechtliche28, organisato-
rische29, finanzielle30, zeitliche31 und räumliche32 Beziehungen zwischen den Organisations-
26. Insbesondere sind hier die Kunden-Lieferanten-Beziehungen gemeint.27. Vgl. [Klin98], S. 37.28. Z.B. „Joint Venture“.29. Z.B. „Weisungsbefugnisse“.30. Z.B. „Kapitalbeteiligung“.31. Z.B. „Just in Time“.
Rohstoff-lieferant
Spediteur Komponenten-lieferant
Endpro-dukthersteller
Distributions-zentrum
Handel
Legende:
Wertschöpfungs-/Fertigungsstufe Unternehmen Materialfluss
Abbildung 3: Skizze einer möglichen Lieferkette
Downstream
Upstream
Informationsfluss
8 Kapitel 2: Problemstellung
einheiten einer Lieferkette.33 Im weiteren Verlauf der Arbeit stehen die Informationsflussbe-
ziehungen und die zugrunde liegenden Materialflussbeziehungen zwischen den
Organisationseinheiten der Lieferkette im Mittelpunkt der Betrachtung. Dazu werden zunächst
die Aufgaben des operativen Fertigungsmanagements eingegrenzt und anschließend die
grundlegenden Begriffe Information und Informationsfluss genauer betrachtet. Abschließend
erfolgt eine Einordnung der operativen Fertigungsmanagement-Informationssysteme.
Operatives Fertigungsmanagment
Im Allgemeinen umfassen die Aufgaben des Fertigungsmanagements34 einerseits die Analyse
und Beschreibung des physischen Leistungserstellungssystems - dabei stehen insbesondere
Entscheidungen über die Struktur der Erzeugnisse und Prozesse im Mittelpunkt - und anderer-
seits die Lenkung der Material- und Informationsflüsse innerhalb der Lieferkette. Dagegen
haben die Aufgaben des operativen Fertigungsmanagements insbesondere das Ziel des mög-
lichst optimalen Einsatzes der vorhandenen Fertigungsressourcen und des wirtschaftlichen
Vollzuges der Aufgabenerfüllung, die sich aus den Absatzmöglichkeiten für einen vorgegebe-
nen Planungszeitraum ergibt. Als Stellgrößen des operativen Fertigungsmanagements sind
dabei einerseits die Menge der zu fertigenden Enderzeugnisse, Komponenten und der bereitzu-
stellenden Produktionsfaktoren und andererseits die Start- und Endtermine für die Fertigungs-
aufträge zu bezeichnen.
Zur Erfüllung des dispositiven Charakters der operativen Fertigung kommt dem Begriff Infor-
mation, als unabdingbare Basis für sämtliche Planungs-, Führungs- und Kontrollprozesse, eine
besondere Rolle zu. Hierfür wird die Information gelegentlich auch als Koordinations- und
Produktionsfaktor35 bezeichnet.36 Der Stellenwert der Information als Produktionsfaktor
32. Z.B. „ortsansäßig“.33. Vgl. [Klin98], S. 37.34. Fertigungsmanagement wird häufig als Produktions- und Logistikmanagement bezeichnet. Dabeiwird zwischen strategischem, taktischem und operativem Produktions- und Logistikmanagement unter-schieden. Das strategische Produktions- und Logistikmanagement legt die Ziele und die Strategie für dasLeistungserstellungssystem fest. Das taktische Produktions- und Logistikmanagement umfasst die Kon-kretisierung der Produktionsstrategie, wobei vor allem Entscheidungen über die Leistungsfelder, die Per-sonal- und Betriebsmittelkapazitäten sowie über die Produktionsorganisation zu fällen sind (vgl.[Zäpf96]).35. Die Frage, ob der Produktionsfaktor Information den bestehenden Klassen der verschiedenen Faktor-systeme zugeordnet wird oder eine eigenständige Klasse darstellt, ist offen. Obwohl Information in denmeisten Faktorschemata nicht als eigenständiger Produktionsfaktor erwähnt wird, ist die Bedeutung fürdie Leistungserstellung unumstritten (vgl. [Stre96], S. 39).36. Vgl. [REFA91], S. 201.
Kapitel 2: Problemstellung 9
resultiert aus der besonderen Bedeutung der Information für die Steuerung und Kontrolle der
Leistungserstellung. Die Rolle der Information als Koordinationsfaktor entsteht durch die not-
wendige Abstimmung (Koordination) zwischen den dezentral auszuführenden Aktivitäten
(sowohl inner- als auch überbetrieblich) der Leistungserstellung.37 Hierzu wird der Begriff
Informationsfluss als zentrales Element näher betrachtet.
Definition 2: Informationsfluss38
„Informationsfluss bezeichnet die Weitergabe von Informationen von einem Aufgabenträger
oder Sachmittel (Sender) zu einem anderen Aufgabenträger oder Sachmittel (Empfänger)“.
Zur Klassifikation von Informationsflüssen stehen, entsprechend dem Betrachtungsschwer-
punkt, eine Reihe von Klassifikationsmerkmalen zur Auswahl. Im Zusammenhang mit dem
Materialfluss erfolgt die Einteilung in parallele (downstream) und entgegengesetzte (upstream)
Informationsflüsse (vgl. auch Abbildung 3). Parallel zum Materialfluss gerichtete Informati-
onsflüsse können diesem außerdem vorauseilen oder nacheilen sowie begleitend gekoppelt
sein.39 In [Bren90] wird in diesem Zusammenhang zwischen vorauslaufenden, progressiven
Informationsflüssen und den zurücklaufenden, retrograden Informationsflüssen differenziert.
Ein Beispiel für den progressiven Informationsfluss ist die Auftragseinlastung in die Ferti-
gung, für den retrograden Informationsfluss die Rückmeldung von IST-Daten aus der
Betriebsdatenerfassung an die Fertigungssteuerung.40 Informationsflüsse, die relativ zum
betrachteten Ablauf weder eine vorauslaufende noch eine zurücklaufende Orientierung besit-
zen, werden als orthogonale Informationsflüsse gekennzeichnet.41 In Bezug auf die aufbauor-
ganisatorischen Hierarchieebenen wird in horizontale und vertikale Informationsflüsse
unterschieden.42 Die horizontalen Informationsflüsse finden zwischen Sender und Empfänger
statt, die sich innerhalb der gleichen aufbauorganisatorischen Hierarchieebene befinden. Bei
den vertikalen Informationsflüssen liegen der Sender und der Empfänger in unterschiedlichen
aufbauorganisatorischen Hierarchieebenen. Einen weiteren Gliederungsaspekt stellt die Inte-
grationsebene dar. Hierbei wird zwischen bereichsinternen, bereichsübergreifenden und unter-
37. Hierbei stell die Information und deren Bereitstellung die wichtigste Komponente für eine effizienteund effektive Koordinationsfähigkeit dar (vgl. [Witt93], S. 2308).38. Vgl. [HeRo98].39. Vgl. [Pfohl96], S.75.40. Vgl. [Bren90], S.30.41. Vgl. [Horn95], S. 99.42. Vgl. [Pfohl97].
10 Kapitel 2: Problemstellung
nehmensübergreifenden Informationsflüssen unterschieden.43 Abhängig davon, ob der Anstoß
der Informationsweitergabe vom Sender bzw. vom Empfänger veranlasst wird, werden die
Informationsflüsse in den Typen „holend“ und „bringend“ klassifiziert.44 Ein Informations-
fluss ist vom Typ „holend“ (auch Pull genannt), falls der Anstoß der Übertragung vom Emp-
fänger erfolgt. Wird die Aktion dagegen vom Sender veranlasst, so ist der Informationsfluss
vom Typ „bringend“ (auch Push genannt). Darüber hinaus lassen sich die Informationsflüsse,
in Abhängigkeit von der Auswirkung auf die Steuerung beim Empfänger, in „steuernde“ und
„nicht-steuernde“ unterteilen.
Zur Gestaltung und Unterstützung des operativen Fertigungsmanagements werden betriebliche
Informationssysteme eingesetzt. In Anlehnung an die Einteilung der betrieblichen Informati-
onssysteme, nach der sog. Informationspyramide45, können Informationssysteme (für das ope-
rative Fertigungsmanagement) einerseits durch die enge Verbindung mit der operativen
Leistungserstellung als „operative Informationssysteme“ und andererseits durch ihre Rolle als
Instrument zur Entscheidungsunterstützung als „Management-Informationssysteme“ angese-
hen werden.
43. Vgl. [Schmi99], S. 59.44. Vgl. [Horn95], S. 97.
Merkmal Ausprägungen
Richtung Downstream Upstream
Bezug zum Ablauf (Materialfluss) Progressiv Retrograd
Orthogo-nal
Aufbauorganisation Horizontal Vertikal
Integrationsebene Unternehmensüber-greifend
Bereichs-intern
Bereichs-übergrei
fend
Hierarchieebene Operativ Taktisch/Strategisch
Anstoß Bringend(Push) Holend(Pull)
Steuerung Steuernd Nicht-Steuernd
Tabelle 2: Merkmale und Ausprägungen der Informationsflüsse
45. Vgl. [Schee97], S. 4ff.
Kapitel 2: Problemstellung 11
Fazit: Im weiteren Verlauf der Arbeit stellt die Gestaltung des operativen Fertigungsmanage-
ments innerhalb der Lieferkette und der damit verbundenen Informationen bzw. Informations-
flüsse sowie deren Bereitstellung in einem betrieblichen Informationsystem für die
Entscheidungsunterstützung den Untersuchungsgegenstand dar.
2.1.2 Ausgangssituation
Die steigende Komplexität der Beziehungen entlang der Lieferkette kann im Wesentlichen auf
zwei Ursachen zurückgeführt werden.46 Zum einen zwingen die zunehmend hohen Arbeitsko-
sten viele Unternehmen dazu, Teilbereiche ihrer Fertigung an fremde Unternehmen auszula-
gern. Dadurch können sich die Unternehmen auf die eigenen Kernkompetenzen konzentrieren,
um somit wettbewerbsfähig zu bleiben. Zum anderen wird durch die steigende Anzahl der
Enderzeugnisvarianten aufgrund der hohen Anforderungen der Endkunden eine Prognose der
zukünftigen Bedarfe immer schwieriger und komplexer. Dieser Trend führt zu einer Reduktion
des vertikalen Integrationsgrades und der Notwendigkeit einer Erhöhung des horizontalen
Integrationsgrades in der Lieferkette.47 Daher kommt der Gestaltung des operativen Ferti-
gungsmanagements innerhalb der Lieferkette eine entscheidende Bedeutung für die mengen- ,
zeit- und qualitätsmäßige Fertigstellung von Kundenaufträgen zu. Ziel ist es dabei, die zeitlich
eng miteinander verzahnten Planungs- und Abwicklungsprozesse entlang der Lieferkette durch
den permanenten Informationsfluss zu integrieren. Dadurch soll einerseits die Transparenz des
Fertigungsgeschehens erhöht und andererseits die Reaktionsfähigkeit auf kurzfristig auftre-
tende Änderungsereignisse verbessert werden.48
Tritt ein unvorhergesehenes Ereignis in einer Organisationseinheit innerhalb der Lieferkette
auf, so ist es ggf. notwendig, die Auswirkungen der Planungsänderungen möglichst schnell in
Richtung Zulieferer (upstream) und Kunden (downstream) weiterzugeben. Dadurch sollen die
Zulieferer und Kunden die Möglichkeit erhalten, frühzeitig auf das veränderte Bedarf bzw.
Angebot zu reagieren.
46. Vgl. [Shaw00].47. Vgl. [KnMZ00].48. Vgl. [DBHHL99].
12 Kapitel 2: Problemstellung
Dies wird besonders deutlich am Beispiel des sog. Bullwhip-Effekts.49 Dabei werden kleine
Bedarfsänderungen bei den Endkunden verstärkt und führen bei den vorgelagerten Stufen der
Lieferkette zu größeren Bedarfsfluktuationen (vgl. Abbildung 4).
Die Hauptursachen50 für den Bullwhip-Effekt werden im Folgenden aufgeführt:
• Da die (tatsächliche) Menge der abgesetzten Enderzeugnisse nicht an die vorgelagerten Stu-
fen weitergegeben wird, werden in jeder Stufe Änderungen in den Bedarfsvorhersagen vor-
genommen, die speziell die eigenen (häufig maximalen) Durchlaufzeiten und die
Sicherheitsbestände berücksichtigen.
• Die Zusammenfassung von Bedarfen zu „optimalen“ Bestellmengen führt bei den vorgela-
gerten Stufen zu größeren Bedarfsschwankungen, die evtl. zu einer schlechten Planbarkeit
führen.
• Bei unerfüllten Nachfragen einer Stufe können Lieferkürzungen auftreten. Die Reaktion der
Kunden auf diese Lieferantenpolitik führt häufig zu Bedarfsfluktuationen.51
Insgesamt entsteht der Bullwhip-Effekt dadurch, dass die Fertigungs- und/oder Transportlose
nach vorne immer größer werden. Damit verursachen kleine Änderungen des Bruttobedarfes
größ-ere Veränderungen im Nettobedarf.
Unternehmensintern ist die Unterstützung des operativen Fertigungsmanagements bisher eine
Aufgabe des ERP/PPS-Systems.52 Dabei bauen die meisten ERP/PPS-Systeme auf den MRP-
49. Vgl. [HaPW97], auch Peitschen-Effekt genannt. Der Bullwhip-Effekt wurde erstmals bei Procter &Gamble diagnostiziert. Die Auswirkungen des Bullwhip-Effekts werden in [BoDa96] folgendermaßenbeschrieben: „Distorted information from one end of a supply chain to the other end can lead to tremen-dous inefficiencies: Excessive inventory investment, poor customer service, lost revenues, misguided ca-pacity plans, ineffective transportation and missed production schedules“.50. Vgl. [HaPW97].51. Auch „Rationing and shortage gaming“ genannt.52. Vgl. [LuES98], S. 261-267.
Ender-zeugnis
Rohmate-rial
Stufe 1 Stufe 2 Stufe 3 Stufe 4
Bedarfe an Stufe 4
Bedarfe an Stufe 3
Bedarfe an Stufe 2
Bedarfe an Stufe 1
Abbildung 4: Der Bullwhip-Effekt
Kapitel 2: Problemstellung 13
II-Ansatz auf, der durch das Stufenplanungskonzept53 und die Orientierung an fixen vorgege-
benen Vorlaufzeiten zwischen den Fertigungsstufen charakterisiert werden kann. Die fixen
Vorlaufzeiten bilden die maximale Übergangszeit54 des Materials von einer Fertigungsstufe in
eine nachgelagerte Fertigungsstufe. Mit Hilfe der fixen Vorlaufzeiten und der Stücklisten wird
aus dem Primärbedarf für eine Fertigungsstufe der jeweilige Sekundärbedarf für die vorgela-
gerten Fertigungsstufen ermittelt. Dies geschieht ohne Berücksichtigung der Zuordnung der
Aufträge auf die Ressourcen der nachgelagerten Fertigungsstufen. Dadurch entstehen Warte-
zeiten aufgrund von Überlastsituationen (Warten auf Kapazität) und/oder aufgrund verspäteter
Anlieferung von Materialien (Warten auf Material). Da die Wartezeiten a priori im MRP-II
nicht berücksichtigt werden können, bauen die Unternehmen Pufferbestände zwischen den
einzelnen Fertigungsstufen auf, um die Schwankungen der Bedarfe abfangen zu können. Wei-
terhin führt diese Vorgehensweise zu Schwankungen in den Durchlaufzeiten und somit zu
Verzögerungen bei der Lieferung an den Kunden. Darüber hinaus sind die auf MRP-II-basie-
renden ERP/PPS-Systeme aufgrund des langwierigen Prozesses der Planerstellung häufig
nicht in der Lage, notwendige Anpassungen bei kurzfristig geänderten Bedingungen55 vorneh-
men zu können. Abbildung 5 veranschaulicht die grobe Vorgehensweise von MRP-II-basier-
ten ERP/PPS-Systemen.56
53. Das Stufenplanungskonzept ist die Gliederung in Primärbedarfs-, Mengen-, Termin- und Kapazitäts-planung. Insbesondere die Zweiteilung in Mengen- und Kapazitätsplanung bzw. Stücklisten und Arbeits-pläne führt dazu, dass in der Mengenplanung ausschließlich Materialbedarfsgesichtspunkte, in derKapazitätsplanung dagegen nur noch Belegungen von Betriebsmitteln durch die in der Mengenplanunggebildeten Aufträge betrachtet werden (vgl. [Kern95]).54. Die Übergangszeit legt die Zeitspanne fest, die für den Wechsel von einem Arbeitsgang zum nächstenerforderlich ist. 55. Z.B. Maschinenausfall oder ein neuer Kundenauftrag.56. In Anlehnung an [Dang00].
14 Kapitel 2: Problemstellung
Auch überbetrieblich macht es die zunehmende Vernetzung in den Kunden-Lieferanten-Bezie-
hungen zwischen den Unternehmen notwendig, dass alle beteiligten Unternehmen sich aufein-
ander verlassen können. Dazu gehört einerseits, dass bei der Auftragserteilung zugesagte
Liefermengen und -termine eingehalten werden und andererseits die Änderungen in der Pla-
nung57 ggf. sowohl den Zulieferern als auch den Abnehmern mitgeteilt werden. Klassische
ERP/PPS-Systeme auf der Basis von MRP-II sind aber mit diesem speziellen Problemfeld
57. Z.B. Änderung der verfügbaren Kapazität.
Fertigungsstufe 2 Kunde
Fertigungsstufe 1 Lieferant
(Zwischen-)Erzeugnis
(End-)Erzeugnis
Feste Vorlaufzeitder Fertigungsstufe
Primärbedarf Ende Periode A
Berechnung für Periode A
Verschiebung um konstante Vorlaufzeit,Bedarfsauflösung
Berechnung für Periode A
Erzeugnis p
Programmunabhängige Belastung derFertigungsstufe
MRP-II-spezifische Liegezeit spätestes Ende für alle
Aufträge der Periode AWartezeit
Herstellung des Erzeugnis p
nach Eingangim Warenausgangs-lager der Lieferanten
Warteschlange früheste Beginn für alle Aufträge der Periode A
Sekundärbedarfsplanung: Rückwärtsbetrachtung mit fester Vorlaufzeit
Kapazitäts- und Terminplanung: Vorwärtsbetrachtung für eine Fertigungsstufe
Abbildung 5: Anschauliche Darstellung der Vorgehensweise von MRP-II-basierten ERP/PPS-Systemen
Kapitel 2: Problemstellung 15
überfordert und nur bedingt geeignet.58 Allerdings lassen sich aufbauend auf den bestehenden
ERP/PPS-Systemen Lösungen entwickeln, die das dargestellte Problem verbessern.
Eine nahliegende Lösung stellt die Kopplung des im Unternehmen eingesetzten ERP/PPS-
Systems mit den ERP/PPS-Systemen der Zulieferer und Kunden dar. Allerdings ist eine solche
Lösung aufgrund der fehlenden herstellerübergreifenden Schnittstellenstandards zur Anbin-
dung von ERP/PPS-Systemen meistens mit einem sehr hohen Kosten- und Zeitaufwand ver-
bunden. Weiterhin enthalten die Systeme häufig Daten, die als elementar und vertraulich59
gelten, so dass selbst bei den bekannten Sicherheitsmechanismen ein hohes Maß an Vertrauen
notwendig wäre, um den teilweise nur kurzfristig involvierten Partnern in der Lieferkette einen
direkten Zugriff zu gewähren.
Eine weitere Möglichkeit zur Realisierung unternehmensübergreifender Informationsflüsse
stellt das EDI-Protokoll60 dar. Allerdings stellen zum einen die unterschiedlichen branchen-
und länderspezifischen Varianten von EDI, die häufig untereinander inkompatibel sind, und
zum anderen die langwierige und kostenspielige Einführung von EDI-Systemen eine Hürde für
kleine und mittelständische Unternehmen in der Lieferkette dar.61 Darüber hinaus beschränkt
sich der Einsatz von EDI-Systemen im Bereich des überbetrieblichen Fertigungsmanagements
im Wesentlichen auf die Übermittlung von Auftrags-, Bestell- und Lieferinformationen und
eignet sich weniger für die Abstimmung bei kurzfristig aufgetretenen Änderungen.62
Ein aktueller Ansatz, der u.a. die Integration der fertigungsrelevanten Prozesse entlang der
Lieferkette verfolgt, stellt das Supply-Chain-Management (SCM) dar. Der SCM-Ansatz strebt
die Integration63, Planung, Optimierung und Steuerung der gesamten Lieferkette und der dazu-
gehörigen Geld-, Informations- und Materialflüsse an.64 Dabei wird eine Verkettung der stra-
tegischen65 und operativen66 Prozesse sowohl unternehmensintern als auch -extern verfolgt,
58. Klassische ERP/PPS-Systeme werden in diesem Zusammenhang als umfassende Speicher bzgl. ferti-gungsrelevanter Informationen betrachtet und können in manchen Fällen um ein sog. Business Informa-tion Warehouse erweitert werden, in dem ausgewählte fertigungsrelevante Informationen den Zulieferernund Kunden, differenziert nach Zugriffsrechten, bereitgestellt werden (vgl. [Delo00], [Serv98] und[KnMZ00]). 59. Vgl. [Cram98], S. 225.60. Electronic Data Interchange (vgl. auch Kapitel 3.3.2).61. Vgl. [Alt97].62. Vgl. [Thal97] und [KnMZ00].63. „The integration of all key business processes across the supply chain is what we are calling supplychain management“ (vgl. [CoLP97]).64. Vgl. [Schee99].65. Beispielsweise Produktentwicklung und Ressourcengestaltung.
16 Kapitel 2: Problemstellung
mit dem Ziel, sich am künftigen Bedarf des Kunden zu orientieren. Die gesamte Lieferkette
wird dabei als Einheit betrachtet und in einem Lieferkettenmodell abgebildet. Auf Grundlage
dieses Lieferkettenmodells werden Simulationsrechnungen vom strategischen bis zum operati-
ven Bereich durchgeführt.
Dazu erfordern die bisher realisierten SCM-Ansätze die Existenz einer zentralen Entschei-
dungsinstanz, die die Modellierung, Planung und Koordination der gesamten Lieferkette
durchführt. Diese zentrale Entscheidungsinstanz kann abhängig von der Lieferkettenstruktur
von einem dominierenden Mitglied der Lieferkette oder von einem externen „Logistikdienst-
leister“ bei einer Lieferkette mit gleichberechtigten Partnern realisiert werden. Ist jedoch eine
Organisationseinheit Mitglied in mehreren Lieferketten67, so können daraus vielfältige Koor-
dinationsprobleme68 entstehen.69 In extremen Fällen kann es vorkommen, dass eine sog.
„Konkurrenzklausel“ den Beteiligten in der Lieferkette verbietet, Kontakte mit lieferketten-
externen Marktteilnehmern zu unterhalten, was häufig zu Interessenskonflikten führen kann.70
Darüber hinaus müssten sich die Teilnehmer der Lieferkette in solchen Fällen ggf. häufig für
das gleiche Supply-Chain-Management-System eines Anbieters71 entscheiden, um eine zen-
trale Planung und Steuerung der Lieferkette zu ermöglichen.72
Der SCM-Ansatz setzt eine engere Kooperation der Beteiligten in der Lieferkette und den
Abbau von Informationsbarrieren innerhalb der Lieferkette voraus. Daher stehen neben ver-
traglichen und kapitalmäßigen Verbindungen beim Supply Chain Management Fragen des
Vertrauensmanagements im Vordergrund.73 Da es aber häufig bei vielen unabhängigen Orga-
nisationseinheiten Vorbehalte74 gegen einen intensiven und weitreichenden Informationsfluss
gibt, eignen sich die weitreichenden SCM-Lösungen bisher eher für einen organisationalen
66. Z.B.: im Zusammenhang mit dem Materialfluss.67. Wird auch als Mehrfachbindung bezeichnet (vgl. [Buse97], S. 85).68. Die rechtlich unabhängigen Organisationseinheiten in der Lieferkette verfolgen häufig das Ziel, dieeinseitige Abhängigkeit von einem Monopolisten, sowohl eines Zulieferers als auch Kunden, zu vermei-den. In der englischsprachigen Literatur hat sich für diesen Sachverhalt der Begriff der „Coopetition“ her-ausgebildet, zusammengesetzt aus „Cooperation“ und „Competition“ (vgl. [BuKo00]). 69. Vgl. [KnMZ00].70. Vgl. [Hahn00].71. Oder einen hohen Aufwand bei der Integration der Systeme unterschiedlicher Anbieter, aufgrund derfehlenden Standards, in Kauf nehmen. 72. Arbeiten Organisationseinheiten einer Lieferkette nur kurze Zeit zusammen, so fließen die in ihrenAufbau investierten Mittel nicht angemessen zurück. Verlassen einzelne Organisationseinheiten die Lie-ferkette, so können ihnen, aber auch den anderen Teilnehmern der Lieferkette, hohe „Switching-“ Kostenentstehen (vgl. [KnMZ00]). 73. Vgl. [Hahn00].
Kapitel 2: Problemstellung 17
Verbund.75 So zeigen bisherige Einführungsprojekte, dass die SCM-Software fast ausschließ-
lich Verwendung innerhalb eines Unternehmens und nur selten über mehrere Unternehmen
hinweg findet.76 Daher ist für die erfolgreiche Einführung des SCM-Ansatzes zunächst ein fle-
xibles Kooperationsmanagement erforderlich, das es den Organisationseinheiten in der Liefer-
kette ermöglicht, den Grad der Integration zu den Partnern in der Lieferkette individuell zu
bestimmen. Dadurch kann jede Organisationseinheit der Lieferkette mit ihren Kunden und
Zulieferern die Vereinbarungen bzgl. der bereitzustellenden Informationen treffen, die mög-
lichst „optimal“ auf ihre Ziele ausgerichtet sind. Diese Tendenz wird verstärkt durch die
zunehmende Ausrichtung der Fertigung weg von einer traditionell „kapazitätsorientierten“
Fertigung, die durch die verfügbare Fertigungskapazität angetrieben wird, hin zu einer „infor-
mationsorientierten“ Fertigung, wo der Fokus auf eine schnelle Antwort der Kunden- und
Marktbedarfe liegt77 (vgl. Tabelle3).
Maßgeblich dazu beigetragen hat neben dem immer höheren Vernetzungsgrad in der Lei-
stungserstellung aufgrund der immer geringeren Fertigungstiefen insbesondere der zunehmend
74. Die bereitgestellten Informationen können dazu genutzt werden, Wettbewerbsvorteile zu erzielen.Z.B. könnte das Wissen um zu hohe Lagerbestände eines Zulieferers Forderungen nach Preissenkungenauslösen.75. D.h. dort, wo langfristige und enge Kooperationsbeziehungen existeren und damit eine höhere Bereit-schaft zum Informationsaustausch. Mangelndes Vertrauen zwischen den Partnern in der Lieferkette wirdals Hauptgrund dafür angesehen, warum der Implementierungsstand von SCM-Konzepten in der Praxisgegenüber den in der Theorie entwickelten Vorgehensweisen zurückbleibt (vgl. [MoTH98]).76. Vgl. [KuHe98], [Selig99] und [Kort99].
„Kapazitätsorientierte“ Fertigung
„Informationsorientierte“ Fertigung
Manufacturing strategy Make and sell Sense and respond
Manufacturing control Hierarchical command control Distributed decision making
Inventory policy Build to stockBuild to order or assembly to
order
Operational focus Production planning and controlOrder fulfillment and supply-
chain coordination
Uncertainty management By inventory By information sharing
Managerial execution Plan and implementation Act and react
Tabelle 3: Gegenüberstellung der „kapazitätsbasierten“ und der „informationsbasierten“ Fertigung
77. Vgl. [Shaw00] und [Fulk00].
18 Kapitel 2: Problemstellung
verbreitete Einsatz der Internettechnologie und die damit verbundenen Möglichkeiten zur
Gestaltung der Informationsflüsse.78
2.1.3 Ein Ansatz zur Gestaltung des operativen Fertigungsmanagements
innerhalb der Lieferkette
Das Ziel dieser Arbeit besteht darin, einen Ansatz zur Gestaltung des operativen Fertigungs-
managements innerhalb der Lieferkette zu entwickeln. Hierdurch sollen die Integration der fer-
tigungsrelevanten Abläufe verbessert und die Transparenz und Reaktionsfähigkeit erhöht
werden.
Zur Gestaltung des operativen Fertigungsmanagements ist zunächst eine Strukturierung der
zugrunde liegenden Lieferkette festzulegen. Dabei soll die Lieferkette in disjunkte Dispositi-
onsbereiche79 unterteilt werden können, die einerseits lokal geplant und gesteuert werden und
andererseits durch ihre Informationsflussbeziehungen die Abstimmung der Fertigungsabläufe
entlang der Lieferkette ermöglichen. Somit ist das Ziel einer solchen Strukturierung herauszu-
finden, welche Merkmale für die Beschreibung der unterschiedlichen elementaren Dispositi-
onsbereiche (sog. Dispositionseinheiten) der Lieferkette von Bedeutung sind.
Aufbauend auf der Strukturierung der Lieferkette sollen die Interdependenzen80 zwischen den
Dispositionseinheiten untersucht werden. Ziel dabei ist die Herleitung von Charakterisierungs-
merkmalen von Informationsflussbeziehungen zwischen den Dispositionseinheiten in der Lie-
ferkette. Dabei soll die Gestaltung der Informationsflussbeziehungen individuell erfolgen
können und zum einen festlegen, welche Informationen bereitzustellen sind und zum anderen
wie die Informationsweitergabe durchgeführt werden soll. Dadurch soll einerseits die inhä-
rente Dynamik der Kooperationsbeziehungen entlang der Lieferkette bewältigt werden können
und andererseits die Reaktionsfähigkeit auf kurzfristige Veränderungen erhöht werden.
Einen entscheidenden Einfluß auf die Gestaltung des operativen Fertigungsmanagements spie-
len die innerhalb der Dispositionsbereiche der Lieferkette eingesetzten betrieblichen Informa-
tionssysteme und deren Integrationsmöglichkeiten. Daher soll zur
78. Vgl. Kapitel 3.3.3.79. Unter Disposition werden in Anlehnung an [DaWa97], S. 4 „die Aufgabenumfänge zusammengefaßt,die sich mit der Ermittlung von Bedarf, dem Führen des Bestandes und der Bildung von Aufträgen befas-sen“.80. Mit Interdependenzen sind hier die Wertschöpfungsbeziehungen und die darauf basierenden Abhän-gigkeiten zwischen den Dispositionseinheiten gemeint.
Kapitel 2: Problemstellung 19
informationstechnologischen Umsetzung des zu entwickelnden Ansatzes ein Fertigungsmana-
gement-Informationssystem (FMI-System) entworfen und prototypisch umgesetzt werden.
Das Fertigungsmanagement-Informationssystem soll zum einen die Spezifikation der Eigen-
schaften der Dispositionseinheiten erlauben und zum anderen die Gestaltung der Informations-
flussbeziehungen ermöglichen. Ziel hierbei ist nicht die Entwicklung eines ERP/PPS-Systems,
vielmehr geht es darum, das ERP/PPS-System um zusätzliche Komponenten zu erweitern, so
dass die in Kapitel 2.1.2 aufgezählten Schwachstellen verbessert werden können.
Damit lassen sich für den weiteren Verlauf der Arbeit die folgenden drei Untersuchungs-
aspekte ableiten:
• Strukturierung der Fertigung entlang der Lieferkette
• Gestaltung der Informationsflussbeziehungen
• Entwurf und prototypische Umsetzung eines Fertigungsmanagement-Informationssystems
2.2 Anforderungen an die Problemlösung
In diesem Kapitel werden Anforderungen an den zu entwickelnden Ansatz hergeleitet. Ent-
sprechend der Strukturierung der Aufgabenstellung werden zunächst im Kapitel 2.2.1 Anfor-
derungen an die zugrunde liegende Strukturierung der Fertigung entlang der Lieferkette im
Hinblick auf die Gestaltung des operativen Fertigungsmanagements festgelegt. Kapitel 2.2.3
beschreibt die Anforderungen an die Gestaltung der Informationsflussbeziehungen innerhalb
der Lieferkette. Abschließend werden im Kapitel 2.2.2 Anforderungen an das zu entwickelnde
Fertigungsmanagement-Informationsystem formuliert.
2.2.1 Anforderungen an eine Strukturierung der Fertigung entlang der
Lieferkette
Für die Gestaltung des operativen Fertigungsmanagements stellt die zugrunde liegende Struk-
tur der Lieferkette die Ausgangsbasis dar. Ziel einer solchen Strukturierung der Fertigung ent-
lang der Lieferkette ist die Herleitung von Merkmalen zur Charakterisierung von sog.
Dispositionseinheiten, die die Knoten der Lieferkette darstellen sollen. Im Folgenden werden
20 Kapitel 2: Problemstellung
Anforderungen an die angestrebte Strukturierung der Fertigung entlang der Lieferkette defi-
niert:
Anforderung 1.1: Prozessorientierung
Um den Aufwand organisatorischer Schnittstellen81 zwischen den Dispositionseinheiten einer
Lieferkette zu reduzieren, sollen die Dispositionseinheiten an Fertigungs- und Logistikprozes-
sen82 im abzubildenden Organisationsbereich ausgerichtet sein. Dadurch können zusammen-
gehörige Aktivitäten zur Erstellung eines (Zwischen-)Erzeugnisses bzw. einer Dienstleistung
in einer Dispositionseinheit integriert werden. So sollten einerseits mehrere aufeinanderfol-
gende Prozesse einer Dispositionseinheit zugeordnet werden können, andererseits sollte bei
der Bildung von Dispositionseinheiten die Komplexität der zugeordneten Prozessstruktur
möglichst vereinfacht werden, um eine Transparenz des Geschehens zu gewährleisten. Dazu
sollte bezüglich des Materialflusses innerhalb einer Dispositionseinheit keine Lenkungsnot-
wendigkeit83 zwischen den zugeordneten Prozessen bestehen. Durch die Zuordnung realer
Fertigungs- und Logistikprozesse zu einer Dispositionseinheit soll der Wirkungsbereich der
Entscheidungsinstanz (Disponenten) der Dispositionseinheit auf die Grenzen der zugeordneten
Prozesskette eingeschränkt werden. Dadurch wird die Entscheidungsweite an der Dispositi-
onseinheit bestimmt.
Anforderung 1.2: Planungs- und Lenkungsautonomie
Die Planung84 und Lenkung85 der fertigungsrelevanten Abläufe in einer Dispositionseinheit
soll von einer einzigen lokalen Entscheidungsinstanz erfolgen können. Dadurch sollen lange
und hierarchische Entscheidungswege vermieden werden. Die Entscheidungsinstanz soll in
der Hierarchie so niedrig wie möglich86 gehalten werden, um eine höhere Flexibilität bezüg-
lich der Entscheidungskompetenz und der Ergebnisverantwortung zu erzielen.
Gegenstand der Planung soll die Belegung der Ressourcen eines der Dispositionseinheit zuge-
ordneten Prozesse sein. Bei diesem bezüglich der Planung „dominanteren“ Prozess kann es
81. Insbesondere die Informationsübertragungs- und Wartezeiten.82. Fertigungs- und Logistikprozesse umfassen alle am Materialfluss beteiligten Leistungserstellungspro-zesse.83. Eine Lenkungsnotwendigkeit im Materialfluss besteht beim Aufteilen (Splittung) bzw. beim Zusam-menführen (Montage) des Materialflusses (vgl. [DaWa97], S. 4).84. Umfasst alle organisatorischen Maßnahmen im Vorgriff auf künftige Ereignisse.85. Umfasst alle Maßnahmen, die zur Durchführung der fertigungsrelevanten Abläufe, im Sinne der Pla-nungsergebnisse, erforderlich sind.86. D.h. Möglichst nahe am Wertschöpfungsprozess.
Kapitel 2: Problemstellung 21
sich um einen Prozess handeln, der den größeren Engpass in der Dispositionseinheit darstellt.
Die anderen Prozesse sollen diesem Prozess planungsmäßig „untergeordnet“ werden und lie-
fern die Vorgaben für die Planung und/oder werden nach den Planungsergebnissen ausgerich-
tet.87 Dadurch soll eine höhere Planungsflexibilität in Bezug auf die Reaktionsfähigkeit auf
kurzfristige Änderungen in der Lieferkette erreicht werden. Weiterhin sollen die Interdepen-
denzen zwischen den Prozessen und die darauf aufbauenden Informationsflüsse sowie deren
zeitliche Reihenfolge festgelegt werden. Dazu soll insbesondere bestimmt werden, welche
Informationsflüsse den Ablauf der Planung anstoßen und welche als Ergebnis der Planung aus-
gelöst werden.
Anforderung 1.3: Informationsautonomie
Zur Entscheidungsunterstützung in einer Dispositionseinheit sollen Informationen über die
vergangenen, aktuellen und zukünftigen fertigungsrelevanten Abläufe bereitgestellt werden
können. Dazu ist ein geeignetes Modell erforderlich, das auf der Basis der Prozesse und des
Planungsablaufes in der Dispositionseinheit beschreibt, welche Informationen in einer Dispo-
sitionseinheit zur Entscheidungsunterstützung verfügbar sein können. Dabei sollen einerseits
die Positionen in den Prozessen der Dispositionseinheit identifiziert werden, in denen die
Ergebnisse der Abläufe gemessen bzw. berechnet werden können und andererseits der zeitli-
che Bezug der Informationen bestimmt werden.
Für die Vergangenheit sollen damit die Positionen bestimmt werden, in denen Rückmeldungen
aus den Fertigungs- und Logistikprozessen über die tatsächlichen Ergebnisse der Abläufe
erfasst werden können. Für die Gegenwart und Zukunft sollen dadurch die Auswirkungen der
geplanten Abläufe bewertet werden können. Daraus sollen beispielsweise Kennzahlen88 zur
Bewertung der geplanten Abläufe generiert werden können. Insgesamt soll das Modell den
Umfang der verfügbaren Informationen über den Ablauf in einer Dispositionseinheit festlegen
und damit die Voraussetzungen für die Informationsaustauschfähigkeit schaffen.
Zur Beschreibung dieses Modells sind Konstrukte erforderlich, die sowohl die Modellierung
der statischen als auch der dynamischen Aspekte der Struktur einer Dispositionseinheit erlau-
87. Bei der Planung können unterschiedliche Optimierungsziele im Spannungsfeld zwischen den ferti-gungswirtschaftlichen Zielen Verbesserung der Liefertreue , Durchlaufzeitverkürzung, Verringerung derBestände und eine verbesserte Kapazitätsauslastung verfolgt werden. Dabei sollen für jede Dispositions-einheit die Restriktionen und Zielfunktionen lokal spezifiziert werden.88. Kennzahlen dienen als Hilfsmittel der Analyse von betriebswirtschaftlichen Fragestellungen und wer-den in Anlehnung an [Reic95] als Zahlen definiert, die quantitativ erfassbare Sachverhalte in konzentrier-ter Form erfassen.
22 Kapitel 2: Problemstellung
ben. Die statischen Aspekte sollen die Erzeugnis- und Ressourcenstrukturen89 sowie deren
Beziehungen umfassen. Die dynamischen Aspekte sollen die Dokumentation des fertigungsre-
levanten Ablaufs über einen bestimmten Zeitraum bzw. -punkt beinhalten.
Bezüglich der Erzeugnisstruktur soll die Dispositionseinheit eine Art Blackbox darstellen.90
Somit sollen nur die strukturellen Zusammenhänge zwischen den Input- und den Output-Fak-
torarten der Dispositionseinheit berücksichtigt werden. Dadurch soll die Transparenz des Fer-
tigungsgeschehens und dessen Auswirkungen auf die Bedarfe der Kunden und/oder Angebote
der Lieferanten verbessert werden.
Bezüglich der Ressourcenstruktur sollen die Ressourcen betrachtet werden, die für den pla-
nungsmäßig dominanteren Prozess eingesetzt werden. Dabei sollen mehrere hintereinander
geschaltete Ressourcen im Zuge der Zusammenfassung mehrerer realer Prozesse als eine Res-
source modelliert werden können.
2.2.2 Anforderungen an die Gestaltung der Informationsflussbeziehungen
Aufbauend auf der angestrebten Strukturierung der Fertigung sollen im Folgenden Anforde-
rungen an die Gestaltung der Beziehungen zwischen den Dispositionseinheiten hergeleitet
werden. Um das Ziel der individuellen Gestaltung der Informationsflüsse zu erreichen, soll es
ermöglicht werden, für jede benachbarte Dispositionseinheit ein individuelles Informations-
profil anzulegen. Ein solches Informationsprofil soll die bereitzustellenden Informationen
beschreiben und die Quelle für den Informationsfluss darstellen. Damit soll eine Dispositions-
einheit durch die individuelle Festlegung der Informationsprofile unterschiedliche Kooperati-
onsintensitäten eingehen können.
Zur Beschreibung der Informationsprofile sind die Interdependenzen zwischen den Dispositi-
onseinheiten zu untersuchen. Dabei gilt es, Merkmale zur Charakterisierung der möglichen
Interdependenzen herzuleiten.
89. Eine Erzeugnisstruktur beschreibt nach [Scho80] den konstruktionsbedingten Aufbau der Erzeugnisse(vgl. S. 44). Im Folgenden soll die Erzeugnisstruktur allgemein die Input- und Output-Faktorarten und de-ren Beziehungen beschreiben. Die Ressourcenstruktur umfasst die betrachteten Ressourcen, deren Eigen-schaften und Beziehungen.90. Damit soll die hier betrachtete Erzeugnisstruktur nur eine Strukturstufe besitzen.
Kapitel 2: Problemstellung 23
Anforderung 2.1: Aufbaumerkmale der Interdependenzen
Die Aufbaumerkmale sollen die Eigenschaften der zwischen den Dispositionseinheiten verein-
barten Wertschöpfungsbeziehungen darstellen. Hierbei sollen insbesondere die Eigenschaften
abgebildet werden können, die Auswirkungen auf die Gestaltung der Informationsflüsse
haben.
Anforderung 2.2: Ablaufmerkmale der Interdependenzen
Die Ablaufmerkmale sollen die Möglichkeiten der Gestaltung der Informationsflüsse aufzei-
gen. Dazu sind einerseits die Informationsflüsse zu kategorisieren und andererseits Merkmale
zur Individualisierung dieser Informationsflüsse entsprechend den Anforderungen des Emp-
fängers festzulegen. Darüber hinaus sind Konstrukte aufzustellen, die eine Beschreibung der
Interaktionsprozesse zwischen zwei Dispositionseinheiten ermöglichen.
2.2.3 Anforderungen an das Fertigungsmanagement-Informationssystem
Die Anforderungen an das zu entwickelnde FMI-System leiten sich zum einen aus den in
Kapitel 2.1.2 erwähnten Verbesserungspotentialen der auf dem MRP-II-Ansatz basierenden
ERP/PPS-Systeme und zum anderen aus den bereits in den Kapiteln 2.2.1 und 2.2.2 definierten
Anforderungen ab. Dazu lassen sich die folgenden Anforderungen bezüglich der Systemarchi-
tektur, der Modellierung der Lieferkette und der Planungsunterstützung durch das FMI-System
formulieren.
Anforderung 3.1: Architektur des FMI-Systems
Das Fertigungsmanagement-Informationssystem soll als eine dezentrale Einheit in einem orga-
nisatorisch abgegrenzten Teil der Lieferkette eingesetzt werden können. Der Einsatzbereich
soll dabei eine oder mehrere Dispositionseinheiten umfassen können. Die lokalen Installatio-
nen des FMI-Systems sollen über ein Kommunikationsmodell verbunden werden können und
dadurch den fertigungsrelevanten Informationsaustausch lieferkettenübergreifend realisieren.
Gegenüber dem eingesetzten ERP/PPS-System soll das FMI-System als eine Art „Add-On“-
Komponente betrachtet werden.91 Dazu sind Schnittstellen zu konzipieren, die es dem FMI-
System erlauben, auf die zum Teil in den ERP/PPS-Systemen enthaltenen Informationen über
den Fertigungsprozess aufzusetzen. Bei der Umsetzung der Schnittstellen soll die Unabhängig-
91. Hierbei kann es zu einer teilweisen Überlappung der Funktionalitäten der beiden Systeme kommen.Dies ist insbesondere auf den unterschiedlichen, herstellerabhängigen Funktionalitätsumfang der ERP/PPS-Systeme zurückzuführen.
24 Kapitel 2: Problemstellung
keit von dem eingesetzten ERP/PPS-System gewährleistet werden, und gleichzeitig soll der
Anpassungsaufwand an unterschiedliche ERP/PPS-Systeme so gering wie möglich gehalten
werden.
Darüber hinaus soll jede dezentrale Einheit im Sinne der Informationsautonomie92 über eine
lokale Datenbasis verfügen. Die Datenbasis bildet eine gemeinsame Kommunikationsplatt-
form sowohl für die Dispositionseinheiten im abzudeckenden Organisationsbereich der Liefer-
kette als auch für die Teilkomponenten einer dezentralen Einheit des FMI-Systems. Dabei
bestehen die Aufgaben der Teilkomponenten darin, für den betrachteten Organisationsbereich
einerseits die fertigungsrelevanten Strukturen93 der Lieferkette abzubilden und andererseits
die Gestaltung der internen und externen operativen Informationsflussbeziehungen94 zu unter-
stützen.
Um den Zeit- und Kostenaufwand für die Einführung des FMI-Systems zu reduzieren und
gleichzeitig einen breiteren Anwenderkreis zu erreichen, soll die Umsetzung des FMI-Systems
möglichst auf der Basis der „gängigen“ (Standard-)Informationssysteme95 erfolgen.
Anforderung 3.2: Modellierung der Lieferkette
Das FMI-System soll über Komponenten verfügen, die die Modellierung der fertigungsrele-
vanten Struktur im abzudeckenden Organisationsbereich ermöglichen. Damit sollen die inter-
nen Struktureigenschaften einer Dispositionseinheit und die Material- und
Informationsflussbeziehungen zu den anderen Dispositionseinheiten in einem Lieferkettenmo-
dell abgebildet werden können. Zur Beschreibung des Lieferkettenmodells soll ein geeignetes
Datenmodell entworfen und realisiert werden. Ausgehend vom Datenmodell sollen Kompo-
nenten zur Erfassung und Verwaltung bestimmter Teilaspekte des Lieferkettenmodells konzi-
piert werden.
Anforderung 3.3: Planungs- und Lenkungsunterstützung
Die Aufgabe der Komponenten zur Planungs- und Lenkungsunterstützung soll darin bestehen,
auf der Basis der im Lieferkettenmodell spezifizierten Strukturen einerseits das Fertigungsma-
nagement innerhalb einer Dispositionseinheit zu unterstützen und andererseits den Informati-
onsfluss zu den externen Dispositionseinheiten zu realisieren.
92. Vgl. Anforderung 1.3.93. Vgl. Kapitel 2.2.1 und Anforderung 3.2.94. Vgl. Kapitel 2.2.2 und Anforderung 3.3.95. Z.B. MS Office, (Standard-)Webbrowser.
Kapitel 2: Problemstellung 25
Für das Management der Fertigung innerhalb einer Dispositionseinheit sollen die Komponen-
ten über die folgenden Möglichkeiten verfügen:
• Die Erstellung der Ressourcenbelegung soll sich an den individuellen Planungsrestriktionen
und -zielen der Dispositionseinheit orientieren. Dazu sollen der Entwurf und die Realisie-
rung eines Verfahrens zur Belegungsplanung prototypisch am Beispiel des Lieferkettenmo-
dells eines Automobilzulieferers bewerkstelligt werden. Hierbei sind insbesondere die
folgenden Anforderungen zu nennen:
• Das Verfahren sollte möglichst schnellere Laufzeiten96 haben und dadurch eine höhere
Planungsfrequenz ermöglichen, um angemessen auf kurzfristig auftretende Änderungs-
ereignisse reagieren zu können.
• Um unterschiedliche Planungsbedingungen97 durchspielen zu können, sollen die Steue-
rungsparameter für das Verfahren über eine Benutzerschnittstelle vor dem Planungsvor-
gang variiert werden können.
• Eine manuelle Erstellung bzw. Nachbearbeitung der Ergebnisse einer Belegungsplanung
soll ermöglicht werden, um weitere nicht im Lieferkettenmodell abgebildete Restriktio-
nen98 berücksichtigen zu können.
• Zur Bewertung der Ergebnisse der Belegungsplanung sollen vordefinierte Kennzahlen he-
rangezogen werden können, die einen Vergleich unterschiedlicher Planungsalternativen
über unterschiedliche Zeiträume ermöglichen.
• Zur Erhöhung der Transparenz des Fertigungsgeschehens sind, in Abhängigkeit von den
Eigenschaften der Dispositionseinheit, geeignete Benutzungsschnittstellen zu realisieren,
die den Disponenten über den Stand der Fertigung in der Dispositionseinheit informieren.
Dabei sind insbesondere für die Zukunft die möglichen Verletzungen der im Lieferketten-
modell hinterlegten Termin- und Mengenrestriktionen aufzuzeigen.
Anforderung 3.4: Informationsaustausch
Um den Informationsaustausch mit den benachbarten Dispositionseinheiten zu ermöglichen,
soll - ausgehend von den im Lieferkettenmodell definierten Informationsflussbeziehungen -
zum einen über das Kommunikationsmodell der Nachrichtenaustausch zwischen zwei dezen-
96. Im Vergleich zu den MRP-II basierten Systeme.97. Sog. „What-If-Simulation“.98. Sog. „soft facts“.
26 Kapitel 2: Problemstellung
tralen Einheiten des FMI-Systems stattfinden und zum anderen über das World Wide Web aus-
gewählte Informationen bereitgestellt werden können.
Kapitel 3: Stand der Technik 27
3 Stand der Technik
3.1 Arbeiten zur Strukturierung der Fertigung entlang der Liefer-
kette
In diesem Kapitel werden bestehende Ansätze zur Strukturierung der Fertigung hinsichtlich
der in Kapitel 2.2.1 hergeleiteten Anforderungen betrachtet. Dazu wird grundsätzlich zwischen
Arbeiten zur Klassifizierung der Erscheinungsformen der Fertigung (Kapitel 3.1.1) und Arbei-
ten zur Modellierung der Fertigung (Kapitel 3.1.2) unterschieden. In Kapitel 3.1.3 wird das
Referenzmodell SCOR zur lieferkettenübergreifenden Prozessmodellierung vorgestellt.
3.1.1 Arbeiten zur Klassifizierung der Erscheinungsformen der Fertigung
In der Literatur existieren zahlreiche Arbeiten zur Klassifizierung der Erscheinungsformen der
Fertigung. Diesen Arbeiten ist gemeinsam, dass aus unterschiedlichen Motivationsgründen
Merkmale hergeleitet werden, die eine Charakterisierung der unterschiedlichen Erscheinungs-
formen der Fertigung erlauben. So wurden in [Eisen89] und [Schae78] Merkmale mit der Ziel-
setzung hergeleitet, eine allgemeine Strukturierung und Einordnung von Industriebetrieben zu
ermöglichen.
In [Groß74] wurde ein systemtheoretischer Ansatz mit der Zielsetzung entwickelt, die Erschei-
nungsformen des Fertigungsablaufs zu verdichten, um die Anwendungsbedingungen für
Erklärungs- und Entscheidungsmodelle1 der Fertigungsablaufplanung zu charakterisieren.
Demnach lassen sich inputorientierte, outputorientierte und prozessorientierte Fertigungsty-
pen unterscheiden. Der prozessorientierte Fertigungstyp lässt sich wiederum in aktions-,
objekt- und potentialorientierte Fertigungstypen unterteilen.
In [Scho80] wurde - aufbauend auf den Erfahrungen aus der Wissenschaft und Praxis und mit
der Zielsetzung, Gestaltungsempfehlungen für Produktionsplanungs- und -steuerungssysteme
(PPS) zu erstellen - ein Merkmalskatalog2 zusammengestellt, mit dem Erscheinungsformen
der Fertigung3 systematisiert werden können. Durch die Kombination von Ausprägungen
1. Erklärungsmodelle haben zum Ziel, Zusammenhänge zwischen den Modellzuständen zu finden und alsKausalzusammenhänge des modellierten Systems zu erklären. Bei Entscheidungsmodellen steht dernächste Modellzustand, der von einem bestimmten Ausgangszustand erreicht werden soll, nicht eindeutigfest und muss daher durch externe Vorgaben/Entscheidungen festgelegt werden (vgl. [Schne96], S. 39).2. Insgesamt wurden 8 Merkmale mit jeweils 3 bis 4 Merkmalsausprägungen herausgebildet.
28 Kapitel 3: Stand der Technik
unterschiedlicher Merkmale werden typische betriebliche Erscheinungsformen als Strukturen
von Merkmalsausprägungen dargestellt. Weitere Strukturierungsansätze aus dem Gebiet der
Fertigungsorganisation verfolgen die Zielsetzung, durch die Bildung autonomer organisatori-
scher Einheiten, die keine oder möglichst wenige Leistungsverflechtungen zu anderen Berei-
chen aufweisen, die Flexibilität und Reaktionsfähigkeit zu verbessern.4 Als Vertreter solcher
Ansätze sind hier Fertigungssegmentierung5 und Fraktale Fabrik6 zu erwähnen.7 Hinsichtlich
der im Rahmen dieser Arbeit angestrebten Strukturierung sind die in diesem Kapitel aufge-
führten Arbeiten aufgrund der fehlenden Konstrukte zur Modellierung der Prozessstruktur,
Ablaufrichtung und der Informationsstruktur weniger geeignet.
3.1.2 Modellierung der Fertigung
Zur Modellierung der Fertigung werden in der Literatur vielfältige Ansätze behandelt. Eine
Übersicht und eine Klassifikation dieser Ansätze ist bereits in [Schne96]8 vorgenommen wor-
den.9 Im Folgenden soll die generische Modellierungsmethode MFERT10, auf die alle
gebräuchlichen Modellierungsmethoden der Fertigung zurückgeführt werden können, unter-
sucht werden.11 Neben der Bereitstellung von Konstrukten zur Modellierung der Fertigung
erhebt der MFERT-Ansatz den Anspruch, ein operables Modell zu sein.12 Dadurch soll die
Durchführung der Planungs- und Steuerungsaufgaben der modellierten Fertigung ermöglicht
werden.
Das Grundmodell von MFERT unterscheidet zwischen Fertigungselementen (F-Elemente)
und Fertigungsvorgängen (F-Vorgängen), die in Kategorien zusammengefasst werden kön-
nen. Dabei repräsentieren die Fertigungselemente die in der Realität vorhandenen Objekte,
deren Eigenschaften durch die F-Vorgänge verändert werden. Fertigungselemente besitzen
3. Insbesondere für Maschinenbau ähnliche Fertigungsprozesse. 4. Vgl. [FrWe94].5. Vgl. [Wild96].6. Vgl. [Warn93].7. Weitere häufig anzutreffende Ansätze sind „Focused Factory“, „Fabrik in der Fabrik“, „Lean Produc-tion“ und „unbegrenzte Fabrik“ (vgl. [Dang98b], S. 81f und [Wild96], S. 474).8. Vgl. Kapitel 3 in [Schne96].9. Weitere Übersichten über die Modelle und Modellierungsmethoden der Fertigung sind in [Wied01],[MeSJ93] und [Wien87] vorzufinden.10. Modell der Fertigung.11. Vgl. [DaWa97], S. 249.12. Der Modellierungsansatz ist in zahlreichen Veröffentlichungen beschrieben worden. (vgl. u.a.[DaWi97], [DaWa97] und [Schne96]).
Kapitel 3: Stand der Technik 29
Eigenschaften, die über Attribute beschrieben werden sowie Zeitmodelle, die Aussagen über
die Existenz eines Fertigungselementes machen.13 Darüber hinaus muss ein Fertigungselement
Attribute besitzen, die zur Steuerung durch den Fertigungsplan erforderlich sind. Diese Attri-
bute müssen entsprechend gepflegt und fortgeschrieben werden.
Ein Fertigungsvorgang (F-Vorgang) beschreibt eine Transformation über die zugehörigen
Input- und Output-Fertigungselemente. Dabei repräsentiert jeder Fertigungsvorgang nur einen
realen Vorgang und ist daher eindeutig identifizierbar. Als Fertigungsvorgänge können Verän-
derungen beliebiger Attribute wie Geometrie, Ort und Status14 definiert werden. Einem Ferti-
gungsvorgang wird zusätzlich eine Dauer zugeordnet.
Durch die Menge zulässiger Merkmalskombinationen können Fertigungselemente und -vor-
gänge zu Fertigungselement-Kategorien bzw. zu Fertigungsvorgangs-Kategorien zusammen-
gefasst werden. Eine Fertigungselement-Kategorie (FE-Kategorie) identifiziert eine Gruppe
potentieller Fertigungselemente mit gemeinsamen Merkmalen, Zeit- und Mengenrestriktionen,
für die auch gemeinsame Fertigungssteuerungsmethoden angewandt werden. Ein Fertigungs-
element kann einer Fertigungselement-Kategorie zugeordnet werden, wenn es die Merkmale
besitzt, die in der Beschreibung der FE-Kategorie festgelegt wurden. Eine Fertigungsvor-
gangs-Kategorie (FV-Kategorie) identifiziert eine Gruppe potentieller Fertigungsvorgänge mit
gemeinsamen Merkmalen, Zeit- und Mengenrestriktionen, für die auch gemeinsame Ferti-
gungssteuerungsmethoden angewandt werden. Dabei kann es sich um Fertigungsvorgänge
einer einzigen Vorgangssorte oder mehrerer Vorgangssorten bzw. untergeordneter Vorgangs-
kategorien handeln. Die Fertigungsvorgangs-Kategorie beschreibt den Typ eines Vorgangs
und wird durch Input-FE-Kategorien, Output-FE-Kategorien sowie deren Beziehungen15
untereinander beschrieben.
Zur Verwaltung der Kategorien werden sog. FE-Knoten (durch dargestellt) und FV-Kno-
ten (durch dargestellt) unterschieden, die über gerichtete Kanten verbunden werden. Eine
Kante repräsentiert die Austauschbeziehung zwischen zwei Knoten bzw. zur Systemgrenze.
Bei jeder Kante ist zu präzisieren, ob einerseits der Vorgänger „bringt“, „bereitstellt“ oder nur
auf Anforderungen wartet und diese bedient, und ob andererseits der Nachfolger „holt“, „emp-
13. Ein Beispiel für ein Fertigungselement kann Rohmaterial (Element) sein, das vor einer Maschine aufdie Bearbeitung wartet. Ebenso kann diese Maschine, die darauf wartet, dass das Rohmaterial zur Bear-beitung freigegeben wird, als Fertigungselement betrachtet werden.14. Beispielausprägungen für das Attribut Status: „Geprüft“, „ungeprüft“, „voll“ und „leer“.15. Zeit- und Mengenrestriktionen.
30 Kapitel 3: Stand der Technik
fängt“ oder lediglich auf Lieferungen wartet und diese vereinnahmt. Ebenfalls ist für jede
Kante zu spezifizieren, unter welchen Bedingungen sie gültig ist.
Das Grundmodell eines Fertigungsprozesses kann auf mehreren Aggregationsebenen aufge-
stellt werden und ermöglicht somit unterschiedlich detaillierte Sichten auf den zu modellieren-
den Fertigungsprozess. Für den Aufbau komplexer hierarchischer Modelle, bei denen
gegebenenfalls auch einzelne Hierarchiestufen wieder aus komplexen Modellstrukturen beste-
hen, existiert ein besonderer Kantentyp, die sog. Schnittstellenkanten, die die Kopplung von
Modellen untereinander bzw. die Kopplung von Modellen an die reale Fertigungsumgebung
ermöglichen.
Tabelle4 zeigt, in Anlehnung an [DaWi97], eine Übersicht der Modellkonstrukte des Modells
der Fertigung auf.
Modellkonstrukt Beschreibung
Fertigungselement (F-Element)
• Repräsentiert ein Objekt in einem Merkmals- undZeitmodell.
• Beschreibung durch Identifikation, Merkmale.• Fluss über Merkmals- und Zeitmodell, der die Verän-
derungen in der Fertigung ausdrückt.
Fertigungselement-Kategorie(FE-Kategorie)
• Fasst eine Menge von Fertigungselementen mitgemeinsamen Merkmalen, Zeit- und Mengenrestrik-tionen zusammen.
Fertigungselement-Knoten(FE-Knoten)
• Verwaltet eine Hierarchie von Fertigungselement-Kategorien.
Fertigungsvorgang
• Repräsentant eines Transformationsprozesses ineinem Merkmalsmodell.
• Beschreibung durch Input- und Output-Fertigungs-elemente.
Fertigungsvorgangs-Katego-rie
• Fasst eine Menge von Fertigungsvorgängen mitgemeinsamen Merkmalen, Zeit- und Mengenrestrik-tionen zusammen.
Fertigungsvorgangs-Knoten(FV-Knoten)
• Verwaltet eine Hierarchie von Fertigungsvorgangs-Kategorien.
Fertigungselement-Fluss-kante
• Verbindet FE-Knoten und FV-Knoten.• Charakterisiert durch FE-Knoten und FV-Knoten.• Beschreibt Zeit- und Mengenrestriktionen.
Informationsfluss-kante
• Beschreibt den Informationsaustausch zwischen denKnoten.
Tabelle 4: Konstrukte des Modells der Fertigung
Kapitel 3: Stand der Technik 31
Ein weiterer wesentlicher Aspekt im Modell der Fertigung stellt die Zeitmodellierung dar.
Dazu werden Modellkonstrukte bereitgestellt, die die Definition diskreter Zeitmodelle erlau-
ben. Die Elemente eines Zeitmodells bilden reale Zeiträume oder reale Zeitpunkte ab und wer-
den (Modell-) Zeitpunkte oder Zeitelemente genannt. Auf den Elementen eines Zeitmodells ist
immer eine Ordnungsrelation definiert, die eine Reihenfolge der Elemente realisiert.16 Die
Beschreibung des Fertigungsablaufs über die Zeit wird in Modellzuständen festgehalten. Ein
bestimmter Modellzustand wird durch eine Markierung des Modells mit Fertigungselementen
ausgedrückt. Dazu werden ein Fertigungselement bzw. mehrere Fertigungselemente durch ein
Ereignis repräsentiert. Um nicht nur den aktuellen Modellzustand, sondern auch vergangen-
heitsbezogene und zukünftig geplante Zustände beschreiben zu können, werden die Ereignisse
auf sogenannte Zeit-Mengen-Leisten (Ereignisleisten) angeordnet. Ein Ereignis ist dabei stets
einem Zeitpunkt oder Zeitraum zugeordnet.
Ereignissen werden Punkte am Knoten zugeordnet, wodurch der Bezug eines Ereignisses zu
einem Fertigungselement bzw. einem Fertigungsvorgang festgelegt wird. Dazu wird in
MFERT zwischen Punkten im FE-Knoten und FV-Knoten unterschieden. In einem FE-Knoten
gibt es die drei Punkte Zugang, Mitte und Abgang, die sich auf den Fluss an Fertigungselemen-
ten durch den Knoten beziehen (vgl. Abbildung 6). Dagegen gibt es an einem FV-Knoten die
fünf Punkte Zugang, beginnende Transformationen, laufende Transformationen, endende
Transformationen und Abgang, die sich ebenfalls auf den Fluss der Fertigungselemente bezie-
hen. Neben dem Ereignistyp, der sich durch den Punkt an den Knoten bestimmt, sieht die
Modellierungsmethode weitere Eigenschaften zur Charakterisierung der Ereignisse vor (vgl.
Abbildung 7). So besitzt jedes Ereignis einen sachlichen Bezug, der in Abhängigkeit vom
Ereignistyp bestimmt werden kann. Für Ereignistypen an FE- und FV-Knoten ist die Menge
der sachlichen Bezüge grundsätzlich durch die FE-Kategorien definiert, die dem Knoten zuge-
ordnet sind. Darüber hinaus lässt sich für Ereignisse an den FV-Knoten mit den Punkten
Zugang oder Abgang die Menge der möglichen sachlichen Bezüge durch die Gesamtheit der
Schnittstellen • Verbindet Modellknoten unterschiedlicher Ebenenmiteinander bzw. deutet die Kopplung zwischenModell und realer Fertigungsumgebung an.
16. Vgl. [Schne96], S. 103.
Modellkonstrukt Beschreibung
Tabelle 4: Konstrukte des Modells der Fertigung
32 Kapitel 3: Stand der Technik
FE-Kategorien bestimmen, die den FE-Knoten zugeordnet sind und die dem betrachteten FV-
Knoten vor- bzw. nachgelagert sind.17 Ein weiteres Merkmal zur Charakterisierung der Ereig-
nisse stellt die Interpretation dar. Die Interpretation legt die Rolle eines Ereignisses fest.
Dadurch wird es möglich, ein Ereignis, das zunächst einen vorläufig geplanten Zugang reprä-
sentiert, umzuwandeln in einen fest eingeplanten Zugang.18 Der zeitliche Bezug innerhalb
eines Zeitmodells erlaubt die zeitliche Einordnung eines Ereignisses. Die Eigenschaft Quanti-
tät vereinfacht die Darstellung einer Vielzahl gleichartiger Ereignisse, indem sie zu einem ein-
zigen Ereignis zusammengefasst werden.
17. Vgl. [Schne96], S. 112.18. Beispiele für Interpretationen sind „geplant“, „vorläufig geplant“, „Soll“ und „Ist“.
Punkte im Modell
Input
Ressourcen
Output
Interpretationen
Ereignisse
Abbildung 6: Modellierung der Fertigung mittels MFERT
Transformation
Ereignisleisten
Ereignistyp AbsolutQuantitätstyp
Sachlicher Bezug
Zeitlicher Bezug
InterpretationSoll
IstPlan Relativ
KumuliertQuantität
Abbildung 7: Eigenschaften der Ereignisse
Ereignis
Kapitel 3: Stand der Technik 33
3.1.3 Supply Chain Operations Reference-model
Das Supply Chain Operations Reference-model (SCOR) ist ein Referenzmodell für Geschäfts-
prozesse, das von der Supply-Chain-Council (SCC) Organisation19 entwickelt wurde. Ziel
dabei ist die Entwicklung eines standardisierten Prozessmodells, mit dem einheitliche, ver-
gleichbare und bewertbare Lieferketten-Prozessmodelle erstellt werden können. SCOR soll
neben der Definition von Prozessen der Lieferketten auch deren Vergleich mit sog. Best Prac-
tices über Benchmarkingdaten erlauben. Dazu liefert SCOR eine Standardterminologie und
allgemeine Kennzahlen für das Benchmarking der Lieferkette. Die Best Practices werden über
viele Branchen gesammelt und den Mitgliedern des SCC zur Verfügung gestellt.20
Die Notwendigkeit eines Geschäftsprozess-Referenzmodelles besteht darin, für die unterneh-
mensübergreifende Kommunikation eine gemeinsame Terminologie21 sowie gemeinsame
Standards für die Beschreibung der Elemente des Geschäftsprozesses zur Verfügung zu stel-
len. Dadurch werden Inkonsistenzen in der Kommunikation und Doppeldeutigkeiten in den
Beschreibungen vermieden.
Grundsätzlich unterscheidet SCOR zwischen den vier Grundprozess-Typen „Plan“, „Source“,
„Make“ und „Deliver“ entlang der Lieferkette22 (vgl. Abbildung 8).
• „Plan“-Prozess (Planen):
Diese Prozesse sollen alle vorbereitenden Aktivitäten zu den jeweiligen Ausführungsprozessen
wie Zuweisung von Ressourcen, Aggregation von Anforderungen der Beschaffung, der Pro-
duktion und der Distribution, Kapazitätsplanung bis hin zur Auftragsverteilung umfassen.
• „Source“-Prozess (Beschaffen):
Die Beschaffungsprozesse sollen speziell den Erwerb, den Erhalt, die Prüfung und die Bereit-
stellung eingehenden Materials beschreiben.
19. SCC ist eine unabhängige nicht-profit-orientierte (gemeinnützige) Organisation. SCC wurde 1996 un-ter der Federführung von Pittiglio Rabin Todd & MCGrath (PRTM) und Advanced Manufacturing Rese-arch (AMR) mit weiteren 69 Partner-Unternehmen gegründet. Ziel der SCC ist es, einen Industrie-Standard für Supply Chain Management zu schaffen (http://www.supply-chain.org).20. Vgl. http://www.supply-chain.org, Stand 20.03.1999.21. Sog. „common terminology“.22. Vgl. [SCC98] und [KuHe98].
34 Kapitel 3: Stand der Technik
• „Make“-Prozess (Produzieren):
Der Make-Prozess beschreibt die Prozesse von der Anforderung und dem Erhalt von Rohmate-
rial über die Produktion bis hin zur Montage und Verpackung. Weiterhin sind hier die eigentli-
chen Produktionsprozesse aufgeführt.
• „Deliver“-Prozess (Liefern):
Der Deliver-Prozess beinhaltet die Erfassung der Nachfrage, ein Auftragsmanagement und die
Distributionsprozesse, inklusive eines Lager- und Transportmanagements.
Die Grundprozesstypen werden auf den weiteren Ebenen detailliert beschrieben. Dabei erfolgt
auf Ebene 2 eine Differenzierung in 19 Prozesskategorien, die wiederum in Ebene 3 mit Hilfe
von Prozesselementen im Sinne einer Standard-Referenz branchenspezifisch konfiguriert wer-
den können. Ab dieser Ebene wird von dem SCOR-Modell keine Modellierung mehr vorgege-
ben. Somit können die Prozesse der Lieferkette bis auf die operative Ebene hinab in Form
abgrenzbarer Teilprozesse definiert und die zeitliche sowie logische Reihenfolge der Auftrags-
durchläufe und der operativen Basisgrößen dokumentiert werden.
Das SCOR-Modell erlaubt eine einheitliche Modellierung der Prozesse unabhängig von bran-
chen- oder funktionspezifischen Aspekten. Das Modell bietet allerdings nur die Möglichkeit
der Prozessbeschreibung auf drei Prozessebenen und gibt keine Konstrukte für die Gestaltung
der Informationsflüsse zwischen den Prozessen vor. Daher muss jedes Unternehmen, das
SCOR verwenden will, das Modell mindestens auf Stufe 4 ausdehnen, um die für das Unter-
nehmen spezifischen Prozesse, Systeme und Praktiken abzubilden. Allerdings wird das SCOR-
Deliver DeliverSource Make Source Make Deliver SourceSource DeliverMake
Plan
Zulieferer Unternehmen Kunden(Intern/Extern) (Intern/Extern)
Zulieferer desZulieferers
Kunden des Kunden
Abbildung 8: Die Prozess-Grundtypen nach SCOR
Kapitel 3: Stand der Technik 35
Modell von der SCC ständig erweitert, so dass ab Version 3.1 das Modell um eine spezifische
Sprache erweitert werden soll, die das Modell um Servicetransaktionen und physische Materi-
altransaktionen ergänzen soll.23
3.2 Arbeiten zur Gestaltung des operativen Fertigungsmanage-
ments
Gegenstand dieses Kapitels ist die Untersuchung von Ansätzen zur Gestaltung der fertigungs-
relevanten operativen Informationsflüsse entlang der Lieferkette. Dabei lässt sich unterschei-
den zwischen Ansätzen, die ausschließlich inner- bzw. überbertrieblich eingesetzt werden
können und Ansätzen, die über die gesamte Lieferkette angewandt werden können.
Bezüglich der Organisation des Ablaufs lässt sich zwischen zentralen und dezentralen Ansät-
zen differenzieren.24 Bei zentralen Ansätzen wird der Ablauf von einer zentralen Instanz
geplant und evtl. gesteuert. Dezentrale Ansätze dagegen sind dadurch charakterisiert, dass den
durchführenden Fertigungseinheiten die Planungsaufgaben übertragen werden.
Ein weiterhin wesentliches Unterscheidungsmerkmal ist die Art der Anforderung bzw. Abho-
lung der zur Auftragsbearbeitung in einer Fertigungseinheit erforderlichen Materialien. Beim
sog. „Pull-Prinzip“ werden die erforderlichen Materialmengen von den liefernden Einheiten
angefordert bzw. abgeholt. Dadurch erfolgt die Fertigung einer liefernden Einheit auf der Basis
des Verbrauchs der nachfolgenden Einheit. Beim „Push-Prinzip“ werden die zur Auftragsbe-
arbeitung erforderlichen Materialien zur verarbeitenden Fertigungseinheit transportiert. Dabei
werden die Zeitpunkte des Eintreffens der Auftragsimpulse bei der liefernden Fertigungsein-
heit anhand der geplanten Vorlaufzeiten berechnet (vgl. Abbildung 9).
23. Vgl. [SCC98].24. Insbesondere unter Anwendung des Kriteriums „Delegation von Entscheidungsbefugnissen an denFertigungsbereich“ erweist sich eine Differenzierung in zentrale und dezentrale Ansätze als sinnvoll (vgl.[WeBa99], S. 426).
36 Kapitel 3: Stand der Technik
3.2.1 Manufacturing Resource Planning
Das Manufacturing Resource Planning (MRP-II) bildet den Basistyp für zentrale Verfahren
der Fertigungsplanung und -steuerung. Das MRP-II-Konzept hat zum Ziel, alle in den Ferti-
gungsprozess involvierten Aktivitäten von einer langfristigen Strategie über dispositive Maß-
nahmen bis hin zur operativen Ebene integral zu betrachten.25 Dabei wird das MRP-II-
Konzept in Form eines hierarchischen, rückwärtsorientierten Sukzessivplanungssystems
umgesetzt. Dazu werden die Teilaufgaben Produktionsprogramm26-, Materialbedarfs27-, Ter-
min- und Kapazitätsplanung28 sowie Auftragsfreigabe und -überwachung29 durchgeführt.
MRP-II teilt die innerbetriebliche Lieferkette in mehrere Planungsebenen ein, wobei die
Ergebnisse einer Ebene jeweils die Vorgaben für den nachgelagerten Bereich bilden. Innerhalb
der Ebenen werden wiederum Module gebildet, die für Mengenplanung, Durchlaufterminie-
rung, Maschinenbelegung, etc. verantwortlich sind. Eine Rückkopplung zur übergeordneten
Ebene ist nur für den Fall vorgesehen, dass eine Vorgabe sich als nicht durchführbar heraus-
stellt.30
25. Vgl. [Hein86], S. 164.26. Hier werden die herzustellenden Erzeugnisse nach Art, Menge und Termin für einen definierten Pla-nungszeitraum festgelegt (vgl. [LuES98], S. 31). 27. Hier geht es um die mengenmäßige und termingerechte Bereitstellung der zur Fertigung benötigtenTeile.28. Die Kapazitäts- und Terminplanung hat zum Ziel, aus den vorläufigen Fertigungsaufträgen der Mate-rialbedarfsplanung die erforderlichen Bearbeitungsgänge abzuleiten und Termine für deren Durchfüh-rung an den entsprechenden Arbeitsplätzen festzulegen (vgl. [Mann97], S.38) .29. Ziel hierbei ist die Sicherstellung der Umsetzung der erstellten Fertigungspläne (vgl. [Mann97], S.39).
Stufe1
Stufe2
LieferungLieferung
AnforderungAnforderung
Stufe1
Stufe2
Stufe3
LieferungLieferung
Auf-trag
Auf-trag
Rück-mel-dung
ZentralinstanzZentralinstanz
Push-PrinzipPull-Prinzip
Stufe3
Abbildung 9: Schematische Darstellung der Pull- und Push-Steuerung am Beispiel einer dreistufigen Fertigung
Kapitel 3: Stand der Technik 37
Der Informationsfluss zwischen zwei nacheinandergeschalteten Stufen im Fertigungsprozess
erfolgt bei MRP-II, wie in Abbildung 10 aufgezeigt. Danach stellen die aktuellen Bedarfe, die
aktuellen Bestände, die Stücklisteninformationen sowie die a priori festgelegten Vorlaufzeiten
zwischen den Stufen die Ausgangsbasis für die Berechnung dar. Zunächst wird über eine Net-
tobedarfsrechnung der Nettobedarf für die nachgelagerte Stufe berechnet, anschließend wird
über die Stücklistenauflösung der Bedarf (Sekundärbedarf) für die vorgelagerte Stufe erstellt.
Die Berechnung des Sekundärbedarfes findet dabei ohne Berücksichtigung der aktuellen und
geplanten Ressourcenbelegung auf der Stufe statt.
Der MRP-II-Ansatz weist bezüglich der Gestaltung der Informationsflüsse für die zunehmend
komplexeren Kunden-Lieferanten-Beziehungen einige Schwächen auf. So bieten die lokalen
MRP-II-Systeme keinen Überblick über die Abhängigkeiten entlang der Lieferkette und kön-
nen somit nicht zu der notwendigen Transparenz beitragen. Dadurch werden häufig zusätzli-
che Bestände aufgebaut, um die Bedarfsfluktuationen abzufangen. Weiterhin verbergen die für
den MRP-II charakteristischen fixen Übergangszeiten häufig die Gefahr, dass starke Schwan-
kungen der Durchlaufzeiten entstehen.31
3.2.2 Ansätze für die lieferkettenübergreifende Abstimmung
3.2.2.1 Fortschrittszahlen
Ein wesentlicher Gedanke bei der Entwicklung des Fortschrittszahlenkonzeptes war es, ein
Informationssystem zu schaffen, das die Auswirkungen von häufigen und kurzfristigen, men-
genmäßigen und zeitlichen Änderungen des Fertigungsplans auf den Fertigungsprozess auf-
zeigt.32 Um das Fortschrittszahlenkonzept anwenden zu können, wird der Fertigungsprozess in
30. Vgl. [LuES98], S. 65f.31. Vgl. auch Kapitel 2.1.2.32. Vgl. [MeSc83].
Nettobedarfsrechnung
Akt. Bestand Stückliste
Feste Vorlaufzeit
Nettobedarf
Akt. Bedarf
SekundärbedarfStücklistenauflösung
Abbildung 10: Informationsfluss bei MRP-II
38 Kapitel 3: Stand der Technik
verschiedene hierarchische Ebenen eingeteilt, die als Kontrollblöcke bezeichnet werden. Die
unterste Ebene bilden einzelne Arbeitsplätze bzw. Arbeitsplatzgruppen. Dabei finden die
Koordinierung und die Steuerung der Kontrollblöcke über die Fortschrittszahlen statt. Gene-
rell ist bei der Kontrollblockbildung darauf zu achten, dass die Kontrollblöcke in fertigungs-
technischer Hinsicht eine lineare Struktur aufweisen, d.h. dass sich der Leistungsaustausch nur
in einer Richtung vollzieht.33
Für die Realisierung des Fortschrittszahlenkonzeptes ist eine enge Zusammenarbeit bezüglich
der Informationsversorgung unabdingbar. Der Abnehmer will wissen, wie viele Teile seit
einem fixierten Startzeitpunkt geliefert worden sind. Diese Auskunft wird durch die Fort-
schrittszahl mitgeteilt, welche allgemein eine kumulierte Mengengröße eines bestimmten Teils
darstellt, die jeweils einem bestimmten Termin zugeordnet ist.34
Grundsätzlich lassen sich drei Arten von Fortschrittszahlen unterscheiden: Eine Soll-Fort-
schrittszahl gibt Auskunft über die Mengen eines Erzeugnisses, die insgesamt in einem
bestimmten Zeitrahmen zu disponieren und bereitzustellen bzw. zu fertigen ist, um ein festge-
legtes Absatzprogramm erfüllen zu können. Eine Ist-Fortschrittszahl gibt eine Menge eines
Erzeugnisses an, die zu einem Termin tatsächlich disponiert und bereitgestellt bzw. gefertigt
worden ist. Eine Plan-Fortschrittszahl gibt die Menge eines Erzeugnisses an, die zwar bis zu
einem Termin disponiert, aber noch nicht bereitgestellt oder gefertigt worden sind.
Jeder Kontrollblock weist mindestens einen Kontrollpunkt auf (vgl. Abbildung 1135).
Dieser folgt im Anschluss an den letzten Arbeitsvorgang, der innerhalb des Kontrollblocks an
dem betreffenden Teil zu verrichten ist. Die sich auf diesen Arbeitsplatz beziehenden Soll-
bzw. Ist-Fortschrittzahlen stellen für den betrachteten Kontrollblock die sog. Ausgangs-Fort-
33. Vgl. [GlGR92]. 34. Vgl. [Hoit96].35. Vgl. [Gott82].
KontrollblockOutputInput
Ausgangs-FSZEingangs-FSZ
Kontroll-punkt 1
Kontroll-punkt 2
Blockverschiebezeit
Abbildung 11: Fortschrittzahlen und Kontrollpunkte
Kapitel 3: Stand der Technik 39
schrittzahl dar. An einem zweiten Kontrollpunkt kann, zwecks Erfüllung der entsprechenden
Soll-Fortschrittzahl, die Erfassung der benötigten Input-Teile mittels einer Eingangs-Fort-
schrittzahl erfolgen.
Die Entscheidungskompetenz der einzelnen Kontrollblöcke, die weitgehend autonome Organi-
sationseinheiten bilden, soll insbesondere in der selbständigen Festlegung von Fertigungsauf-
trägen und den zugehörigen Auftrags- und Arbeitsvorgangsterminen liegen.
Einsatzvorausetzung für das Fortschrittzahlenkonzept ist die mengenbezogene Steuerung von
Kontrollblöcken durch Soll-/Ist-Vergleiche. Dabei müssen die Ist-Fertigungsmengen an den
Zählpunkten erfasst und die Fortschrittzahlen mit einem Lieferabrufsystem36 übertragen wer-
den. Dem Konzept liegt die Überlegung zugrunde, einzelne Fertigungsbereiche und Zulieferer
laufend über den sich aus der Montageplanung ergebenden Bedarfsverlauf zu informieren, so
dass eine Versorgung der Montage mit Komponenten auf Abruf erfolgen kann.37 Somit findet
es besonders in der Zuliefer- und Automobilindustrie Anwendung, wo die Montagelinien die
Engpassressourcen in der Lieferkette darstellen.38 In beiden Unternehmensbereichen herrscht
das Ziel vor, die Lagerbestände durch bedarfs- bzw. fertigungssynchrone Tagesanlieferungen
nach dem Just-in-Time-Prinzip möglichst gering zu halten.39
3.2.2.2 Just-in-Time
Beim Just-in-Time-Konzept40 handelt es sich um ein bedarfsorientiertes Steuerungsverfahren,
das die zentrale Synchronisation mehrerer Stufen der Lieferkette von der letzten Fertigungs-
stufe bis hin zu den Lieferanten zum Ziel hat.41 Es wird dabei zwischen Just-in-Time-Ferti-
gung und Just-in-Time-Anlieferung unterschieden.
Die JIT-Fertigung umfasst den JIT gesteuerten Fertigungsablauf. Dabei wird der Bedarf an
End-, Zwischen- oder Vorprodukten nicht auf Vorrat, sondern auf Anforderung durch ferti-
gungstechnisch nachgelagerte Stellen gefertigt.
36. Vgl. Kapitel 3.3.2.2.37. Vgl. [ReDi91], S. 604.38. Vgl. [Shaw00].39. Vgl. [Hoit96].40. Auch als „Produktion auf Abruf“ oder „Bedarfssynchrone Produktion“ bezeichnet (vgl. [ReDi91], S.608 und [KeSW96], S. 828).41. Vgl. [Wild95].
40 Kapitel 3: Stand der Technik
Mit der JIT-Anlieferung42 wird die Lieferkette zwischen Lieferant und Abnehmer synchroni-
siert. Dabei werden die fremdbezogenen Materialien zu dem Zeitpunkt angeliefert, an dem sie
für die eigene Fertigung benötigt werden.
Zur Verwirklichung des JIT-Konzeptes ist eine Neustrukturierung der logistischen Prozesse in
den Bereichen Fertigung und Beschaffung im Hinblick auf die Ziele „Senkung der Durchlauf-
zeiten“ und „Reduzierung der Lagerbestände“ erforderlich.43
Durch das JIT-Konzept überträgt der Abnehmer seine Lagerhaltung größtenteils auf den Liefe-
ranten. Dadurch muss der Lieferant größere Bestände aufbauen oder, falls er wiederum Liefe-
ranten hat, seine eigenen Fertigungsanforderungen an diese weitergeben. Zur erfolgreichen
Umsetzung des JIT-Ansatzes ist ein hoher Grad an informationstechnischer Integration und
Kooperation der Partner unabdingbar. Aufgrund dieser hohen Vertrauensansprüche werden
derartige Beziehungen häufig nur mit wenigen Partnern für einen langen Zeitraum (oft in Ver-
bindung mit Rahmenverträgen) gepflegt.44
3.2.2.3 Kanban
Beim Kanban-Konzept handelt es sich um eine Ausprägung des JIT-Konzeptes.45 Als Zielset-
zung wird die Reduzierung der Kostenpotentiale46 angesehen. Der Materialfluss wird durch
den Einsatz sog. Kanbans gesteuert. Dabei wird die Philosophie verfolgt, „heute“ das zu pro-
duzieren, was „gestern“ verbraucht wurde.47 In nach Kanban-Prinzipien organisierten Liefer-
ketten ist die verbrauchende Stelle für die Materialbeschaffung selbst verantwortlich und muss
sich die Materialien beim Produzenten abholen oder zumindest anfordern (Pull-Prinzip).48
Den Kern des Kanban-Konzeptes bildet die Strukturierung der Beschaffungs- und Fertigungs-
bereiche der Lieferkette in nacheinander geschaltete, sich selbst steuernde und vermaschte
Regelkreise.49 Jeder Regelkreis besteht aus einer Senke (Material verbrauchende Stelle),
Quelle (Material bereitstellende bzw. produzierende Stelle) und einem Pufferlager mit entspre-
42. Zur Realisierung der JIT-Anlieferung werden Lieferabrufsysteme eingesetzt, die am Ende dieses Ka-pitels vorgestellt werden (vgl. [FaFG97]). 43. Vgl. [KeSW96], S. 830.44. Vgl. [DeKr00], S. 9ff .45. Vgl. [Lack94] S.7.46. Insbesondere die Lagerkosten.47. Vgl. [Lerm92] S. 129.48. Beim überbetrieblichen Einsatz von Kanbans verläuft die Steuerung nach dem Push-Prinzip (vgl.[Lack94], S. 24ff).49. Vgl. [GlGR92] S. 257.
Kapitel 3: Stand der Technik 41
chenden Materialbehältern zwischen Quelle und Senke. Die Quelle eines bestimmten Regel-
kreises stellt zugleich die Senke des dem betreffenden Regelkreises direkt vorgelagerten
Regelkreises (wie in Abbildung 12) dar.50
Den entscheidenden Informationsträger zur Steuerung des Materialfusses zwischen den einzel-
nen Regelkreisen stellen die Kanbans (Karten) dar, wobei ein Kanban jeweils einem bestimm-
ten Materialbehälter zugeordnet ist.51 Es wird zwischen Produktionskanbans und
Transportkanbans unterschieden. Produktionskanbans lösen in der produzierenden Stelle
(Quelle) einen Fertigungsauftrag für die beschriebenen Teile in den angegebenen Mengen aus.
Transportskanbans steuern die Beschaffungsaktivitäten der verbrauchenden Stelle (Senke).
Zur Sicherstellung eines kontinuierlichen Materialflusses haben die Regelkreise sich an
bestimmte Ablaufregeln zu halten.52 Dazu darf jede Quelle zum einen nur dann Teile fertigen,
wenn ein Fertigungsauftrag in Form eines Kanbans vorliegt und zum anderen nur die Anzahl
an Teilen fertigen, die auf dem Kanban vermerkt ist. Weiterhin darf eine Senke nur so viele
Behälter aus dem Puffer entnehmen, wie tatsächlich benötigt werden. Zusätzlich dürfen im
Puffer nur qualitativ einwandfreie Teile eingestellt werden.
Der Einsatz des Kanban-Konzeptes stellt einen Lenkungsansatz dar, welcher den ordnungsge-
mäßen Ablauf der Just-In-Time-Fertigung steuert und überwacht.53 Wichtigste Voraussetzun-
gen für den Einsatz von Kanbans sind ein weitgehend regelmäßiger, täglicher Teilebedarf54
und eine material- bzw. fertigungsflussorientierte Betriebsmittelanordnung mit aufeinander
50. Vgl. [Wild88], S. 36 und [GlGR92], S. 256.51. Vgl. [GlGR92] S. 257.52. Vgl. [GlGR92], S. 261f.53. Vgl. [Lerm92] S. 129.54. Bei kurzfristig auftretenden Bedarfsspitzen sind Fehlmengen in den Puffern zu erwarten, die sich ent-gegen dem Materialfluss vermehren. Hierzu trägt die Ausrichtung auf einen bestimmten Periodenbedarfbei (vgl. [Mann97], S. 54).
Fertig-waren-lager
MaterialflussInformationsfluss
Abbildung 12: Regelkreissystem nach Kanban
Fertigungs-stufe 1
Puffer-lager
Fertigungs-stufe 2
Rohmate-rial
42 Kapitel 3: Stand der Technik
abgestimmten, auf die Nachfrage zugeschnittenen Kapazitäten.55 Kanban lässt sich aufgrund
der Einfachheit des zugrunde liegenden Lenkungsansatzes ohne informationstechnische Unter-
stützung bewerkstelligen.
3.2.3 Ansätze für die überbetriebliche Abstimmung
Im Folgenden sollen die Ansätze betrachtet werden, die ausschließlich zur überbetrieblichen
Abstimmung eingesetzt werden.
3.2.3.1 Efficient Consumer Response
Beim „Efficient Consumer Response“-Konzept56 handelt es sich um einen Ansatz zur interor-
ganisatorischen Kooperation zwischen Handel und Produzenten, mit dem gemeinsamen Ziel,
die Kundenorientierung und die Reorganisation der Lieferkette zu verbessern, um den Materi-
alfluss und die damit einhergehenden Transaktionen zu beschleunigen.57 Inhalt des ECR-Kon-
zepts sind sowohl Instrumente der Logistikoptimierung58 als auch solche des Marketings59
(vgl. Abbildung 1360).
55. Vgl. [GlGR92], S. 268f.56. Auch als „Effiziente Reaktion auf die Kundennachfrage“ bezeichnet (vgl. [BlIh97], S. 193ff). 57. Vgl. [Swob97], S. 37.58. Insbesondere die Integration der Informationskette zur Überwindung der Systemgrenzen zwischenHersteller und Handel, um die Kosten von Lieferung und Lagerung zu reduzieren (vgl. [BlIh97], S. 194).59. Im Bereich des unternehmensübergreifenden Marketing basiert ECR auf dem sog. Warengruppenma-nagement (Category Management). Dabei handelt es sich um eine Unternehmenskooperation zur gemein-samen Sortimentgestaltung, Verkaufsförderung, Produkteinführung und -entwicklung. Das CategoryManagement besteht aus den drei Bausteinen Efficient Store Assortment (ESA), Efficient Promotion (EP)sowie Efficient Product Introduction (EPI) (vgl. [Fies98]).
ESA EPIEP
EDI
ER
CR Vereinba-rungen
MarketingbereichLogistikbereich
Category ManagementEfficient Replenishment
ECR
Abbildung 13: Bausteine des ECR
* siehe Fußnote 59., S. 42 zur Erläuterung der Abkürzungen.
Kapitel 3: Stand der Technik 43
Um eine schnellere Reaktion auf Nachfrageänderungen zu ermöglichen, sieht es das ECR vor,
das Pull-Prinzip auf der Lieferkette, insbesondere zwischen Herstellern und Handel, zu imple-
mentieren.61 Ausgangspunkt bildet dabei der Endverbraucher am „Point of Sale“ (POS). Von
ihm werden die benötigten Erzeugnisse angefordert und so von der Lieferkette gezogen.
Erfüllt wird diese kontinuierliche Nachlieferung der Erzeugnisse durch das Efficient Reple-
nishment (ER), welches im ECR-Konzept realisiert wird. Dabei wird aufgrund von aktuellen
Abverkaufszahlen bzw. verdichteten Bestands- und Warenausgangsdaten, die via EDI62 an
den Hersteller übermittelt werden, der Bedarf an Enderzeugnissen ermittelt. Zusätzlich besteht
die Möglichkeit, ein Kundenprofil63 zu erstellen und dieses zusammen mit den POS-Daten an
den Hersteller zu übermitteln. Dadurch soll eine bessere Ausrichtung der Lieferkette an die
Kundenbedürfnisse erreicht werden.
Für die Realisierung des ECR-Konzeptes wurden fünf Erfolgsfaktoren als Voraussetzung iden-
tifiziert64 (vgl. Abbildung 1465). Der erste und wichtigste Faktor, den es zu erfüllen gilt,
bezieht sich auf die Planbarkeit und das Erreichen eines bestimmten Volumens, um die ange-
führten Nutzenpotentiale zu verwirklichen.
60. In Anlehnung an [Fies98], S. 39.61. Vgl. [Dant96], S. 26f.62. Electronic Data Interchange (vgl. Kapitel 3.3.2.1).63. Z.B. durch sog. Pay Back Aktionen (vgl. [DeKr00], S.14ff.).64. Vgl. [Swob97], S. 39.65. Vgl. [Swob97], S. 41.
44 Kapitel 3: Stand der Technik
Der zweite Faktor beinhaltet die Abschaffung des durch Bereiche begrenzten Denkens aller
Beteiligten. Es gilt, die Einflussfaktoren transparent darzustellen, um jedem einzelnen zu ver-
deutlichen, dass eine Optimierung nur auf den Gesamtprozess und nicht auf die einzelne
Abteilung gerichtet sein darf, um größtmögliche Rationalisierungspotentiale erschließen zu
können. Die einzelnen Abteilungen eines Unternehmens müssen nicht nur betriebsintern, son-
dern auch unternehmensübergreifend mit den Abteilungen der anderen Wertschöpfungspartner
kooperieren. Dies erfordert organisatorische Veränderungen66 und ein die gesamte Lieferkette
umfassendes Management.
Der dritte Faktor läßt sich als die Kooperationsfähigkeit der Partner bezeichnen. Dabei wird
davon ausgegangen, dass eine hohe Flexiblität bei der Reaktion auf sich ändernde Kundenan-
66. Von der Funktions- bzw. Objektorientierung zur Prozessorientierung.
Faktor 1: Planung/Kritische
Masse
Faktor 2: Transparenz/Organisation
Faktor 3: Kooperations-
fähigkeit
Faktor 4: Technische Infra-
struktur
Faktor 5: Kooperations-bereitschaft
Rationalisierungseffekte erst bei Intensivierung der Kooperation
Erfassung sämtlicher Artikeldaten
Mangelnde Planung mit Hilfe von Scannerkassen
Organisatorische Veränderungen
Entwicklung leistungsfähiger informationstechnologischer
Schnittstellen
Unterschiedliche Interessen und Erwartungen
Offenlegung unternehmens-spezifischer Daten
Dauerhafte Kooperation
Fehlende Radikalität in der Umsetzung von ECR
Transparenz und Management der Einflussfaktoren
Mobilisierung aller Beteiligten
Hohe Investitionen in Informationstechnologien
Fehlendes Know-how für derar-tig komplexe Kooperation
Abbildung 14: Zentrale Erfolgsfaktoren des ECR
Kapitel 3: Stand der Technik 45
forderungen nur erreicht werden kann, wenn alle Beteiligten auf lange Zeit mit hohem Ver-
trauen zusammenarbeiten. Dazu ist es notwendig, die Umsetzung von ECR als primäres Ziel
vorzugeben und durch ein von der obersten Führungsebene gestütztes Management zu forcie-
ren. Der vierte Faktor umfasst die Entwicklung leistungsfähiger Schnittstellen-Informations-
technologien sowie die Notwendigkeit der Investition in neue Technologien, um die für ECR
erforderliche technische Infrastruktur zu realisieren. Der letzte Faktor umfasst die Kooperati-
onsbereitschaft. Dazu sollen alle Beteiligten sowohl ihre unternehmensspezifischen Daten als
auch ihre spezifischen Erwartungen an die Kooperation offenlegen, um eine langfristige
Zusammenarbeit zu ermöglichen.
Der Einsatz von ECR erfordert neben dem hohen Grad an informationstechnischer Integration
der Partner auch eine hohe Kooperationsbereitschaft der beteiligten Unternehmen. Dadurch
ergeben sich in der Realität eine Reihe von Problemen, die es zu überwinden gilt, um ECR und
seine Nutzenpotentiale in vollem Umfang ausschöpfen zu können. Insbesondere die langen
und aufwendigen Planungsdurchläufe und die gegebenenfalls hohen Investitionskosten wäh-
rend der Realisierung stellen Hindernisse zur schnellen Erreichung des angestrebten Nutzens
dar.
Weiterhin beschränkt sich der Anwendungsbereich von ECR auf die Kooperation zwischen
Hersteller und Handel in der Konsumgüterindustrie. Dadurch sehen kritische Stimmen, insbe-
sondere aus der Konsumgüterindustrie, Gefahren darin, dass mächtige Einzelhändler einzelne,
für sie vorteilhafte Elemente aus dem ECR-Maßnahmenbündel herausgreifen und deren
Umsetzung in einer Weise erzwingen, die auf Seiten der Hersteller und Logistik-Dienstleister
zu erhöhten Kosten führt.67
3.2.3.2 Continuous Replenishment
Beim Continuous Replenishment68 (CR) handelt es sich um eine logische Weiterentwicklung
des zuvor beschriebenen ECR-Ansatzes. Es ist branchenübergreifender als ECR und eignet
sich vor allem für Artikel mit einem kontinuierlichen Bedarf. Dabei zielt CR ebenso wie ECR
darauf ab, die traditionellen losgrößenorientierten Beschaffungsprozesse entlang der Liefer-
kette durch ein Pull-System zu ersetzen. Der wesentliche Unterschied zu ECR liegt in den feh-
lenden Marketing-Funktionen des Category Management.
67. Vgl. [Schult99], S. 92.68. Auch Continuous Replenishment Process oder Planinng genannt (vgl. [Kort99], S. 112).
46 Kapitel 3: Stand der Technik
Je nach Intensität der Zusammenarbeit des Herstellers mit dem Handel werden für den Einsatz
von Continuous Replenishment in der Regel drei Integrationstiefen unterschieden69 (vgl.
Abbildung 15). Dabei ändern sich die Kommissionierungs- und Belieferungsvorgänge inner-
halb der Lieferkette mit steigender Intensität der Kooperation. Die erste Stufe umfaßt eine Zen-
trallagerbelieferung vom Hersteller aufgrund aktueller Lagerbestandsdaten. Der Hersteller
beliefert dann das Zentrallager mit artikelreinen Vollpaletten. Diese Art der Anlieferung erfor-
dert im Zentrallager des Handels eine zusätzliche Kommissionierung der Paletten.70 Unter
Verwendung der aktuellen POS-Daten der einzelnen Handelsfilialen erfolgt dann vom Zentral-
lager eine Belieferung der Handelsfilialen mit entsprechend kommissionierten Paletten.
Um den Warennachschub effizienter zu gestalten, kann eine intensivere Integration des Her-
stellers in die Belieferungsprozesse der Handelsfilialen eingeführt werden (Stufe 2). Dabei
werden die Paletten schon vor Anlieferung beim Hersteller aufgrund der vom Einzelhandel via
EDI übermittelten aktuellen POS-Daten filialbezogen bestückt und können dann vom Zentral-
lager in kürzester Zeit per Crossdocking71 an die Handelsfilialen weitergeleitet werden.
Die dritte und stärkste Form der Kooperation im CR-Konzept sieht eine Zusammenstellung der
Paletten beim Hersteller vor, wobei dann auch die Belieferung direkt vom Hersteller ohne ein
zwischengeschaltetes Handelslager erfolgt. Die filialreinen Paletten können dann allein durch
Crossdocking über die Lieferkette in den Einzelhandel gelangen.
Mit den drei Stufen des CR-Konzeptes wird angestrebt, den Materialfluss zu verstetigen und
dabei die Lieferzeiten und die Bestände innerhalb der Lieferkette zu minimieren. Bei der
69. Vgl. [BlGö97] und [Gud00b].70. Sog. Transshipment.71. Beim Crossdocking wird durch einen engen Informationsaustausch zwischen Versender und Empfän-ger angestrebt, dass bereits am Versandort eine zeit- und bedarfsgenaue empfängerspezifische Kommis-sionierung erfolgt. Dadurch sollen die Sendungen beim Empfänger vom Wareneingang direkt an denWarenausgang weitergeleitet werden (vgl. [Schult99], S. 54).
Zentrallagerbelieferung
Kommissionierung aufgrund der aktuellen Abverkaufszahlen und Belieferung der einzelnen Betriebsstätten
Betriebsstättenbereinigte Zentrallagerbelieferung
Stufe 1
Stufe 2
Stufe 3
Abbildung 15: Integrationstiefen des Continuous Replenishment
Kapitel 3: Stand der Technik 47
Gestaltung der Informationsflüsse treten, wie beim ECR-Konzept, Hindernisse bezüglich der
informationstechnischen Integration der Beteiligten in der Lieferkette auf.
3.2.3.3 Vendor Managed Inventory
Vendor Managed Inventory (VMI) beschreibt ein Konzept, bei dem ein Lieferant Zugriff auf
die Lagerbestandsdaten seiner Kunden hat und für das Aufrechterhalten eines definierten
Bestandes verantwortlich ist.72 Aufwendige Bestellvorgänge auf Kundenseite und Unsicher-
heiten auf Lieferantenseite sollen dadurch reduziert bzw. vermieden werden.
Einen wesentlichen Unterschied zur zweiten Stufe des CR-Ansatzes bildet dabei die Tatsache,
dass nicht der Handel die Bestandsdaten an den Hersteller weiterleitet, sondern dieser freien
Zugriff auf aktuelle Bestandsdaten des Zentrallagers besitzt.
Voraussetzung für diese intensive, unternehmensübergreifende Kooperationsform ist eine
informationstechnische Integration der Partner und ein hoher Grad an Vertrauen auf den sach-
gemäßen Umgang mit den zur Verfügung gestellten Daten. Letzterer Punkt wird in der Realität
häufig durch strenge Kooperationsverträge abgesichert. Dazu kann der Händler z.B. einen sog.
Category-Management-Vertrag mit einem Hersteller (Category-Captain) abschließen. Für alle
anderen Hersteller derselben Warengruppe bedeutet dies einen Wettbewerbsnachteil, da der
Händler nur dem Category-Captain den Zugriff auf seine Bestandsdaten gestattet und diesen
für den Warennachschub als verantwortlich bestimmt.
Die größten Rationalisierungspotentiale des VMI liegen in der Beseitigung des sog. Bullwhip-
Effekts73, indem sich der Hersteller direkt an der tatsächlichen Nachfrage der Endkunden ori-
entiert und nicht die prognostizierten Werte des Handels als Grundlage nutzen muss. Im Allge-
meinen kann VMI aufgrund der aufwendigen und strengeren Verträge nur zwischen Partnern,
die eine langfristige Kooperation anstreben, zum Einsatz kommen.
3.2.3.4 Quick Response
Ziel des Quick Response-Konzeptes (QR) ist es, durch die Abstimmung und Beschleunigung
von Wertschöpfungsprozessen innerhalb der Lieferkette die Durchlaufzeiten über die gesamte
Lieferkette zu verkürzen.74 Weiterhin soll dadurch eine schnelle Reaktion auf Änderungen der
72. Vgl. [BoDa96], S. 493.73. Vgl. Kapitel 2.1.2.74. Vgl. [BlIh97], S. 868.
48 Kapitel 3: Stand der Technik
Marktnachfrage durch entsprechende Fertigungs- und Angebotsvariationen bewirkt werden.
Dies ist insbesondere in ausdifferenzierten Märkten, die eine hohe Variantenvielfalt bei gleich-
zeitig sehr kurzen Produktlebenszyklen und ein kaum prognostizierbares Kaufverhalten der
Endkunden aufweisen, notwendig.75 Der CR-Ansatz stellt eine Weiterentwicklung des JIT-
Gedankens76 dar, indem die Auslösung der Beschaffung durch konkret vorliegende Bedarfsan-
forderungen der Fertigung erfolgt, was i.d.R. zu kleineren Beschaffungsmengen bei steigenden
Bestellfrequenzen führt.77
Zur Realisierung des QR-Ansatzes ist einerseits eine informationstechnische Integration zur
schnelleren Weitergabe von aktuellen Informationen zu realisieren und andererseits eine orga-
nisatorische Gestaltung der partnerschaftlichen Beziehungen zwischen den Stufen der Liefer-
kette unverzichtbar.78 Dabei erfordert QR ein koordiniertes Verhalten und damit den Aufbau
von langfristigen Kooperationen innerhalb der Lieferkette.
Eine Weiterentwicklung von QR stellt das Quick Response Manufacturing79(QRM) dar. Dabei
wird ein besonderer Stellenwert auf die Identifizierung von Durchlaufzeitverkürzungspoten-
zialen in der Fertigung gelegt. Dazu werden die Fertigungsstrukturen durch die Bildung von
sog. QRM-Zellen80 vereinfacht. Wesentlich für den Erfolg des QRM ist, dass eine Messgröße
für die Durchlaufzeit festgelegt und kontinuierlich gemessen wird.81
Durch seine größere Reichweite kommt es in Verbindung mit einem hohen Kooperationsgrad
beim QR zum Abbau der Intransparenz entlang der Lieferkette von den Lieferanten bis hin
zum Handel. Tendenztiell gilt jedoch, dass je endkundennäher eine Stufe ist, desto größer sind
die Einsparungspotentiale bei Bestandsverringerungen und Umsatzsteigerungen aufgrund
aktuell verfügbarer Ware.82 Zur Realisierung von QR-Konzepten ist ein bruchloser, sicherer
und schneller Informationsfluss über die gesamte Lieferkette notwendig, um die kontinuierli-
che Lieferung und Sammlung der Vertriebsdaten zu gewährleisten.83 Daher ist die Realisie-
75. Diese Beschreibung trifft z.B. auf die Textil- und Bekleidungsindustrie, die einem schnellen modi-schen Wandel unterliegt, zu (vgl. [DeKr00], S. 24ff).76. Im Gegensatz zum JIT-Ansatz, der nur bei kontinuierlichen Bedarfsverläufen einsetzbar ist, ermög-licht QR auch die Steuerung schwankender Verbräuche (vgl. [DeKr00], S. 25).77. Vgl. [BlIh97], S. 868.78. Vgl. [ScKe00] und [BlIh97], S.869f.79. Vgl. [Suri98] und [ScKe00], S. 33.80. Überschaubare und einfach zu steuernde Einheiten.81. Vgl. [ScKe00], S. 35.82. Vgl. [Diek92], S. 314ff.83. Vgl. [BuKo00], S. 52.
Kapitel 3: Stand der Technik 49
rung von QR-Systemen mit hohen Investitionen in die informationstechnologische
Infrastruktur verbunden.
Der QR-Ansatz wird bisher, aufgrund seiner Fähigkeit zur Planung von Bedarfen mit saisona-
len Schwankungen, vorwiegend in der Textil- und Bekleidungsbranche eingesetzt. Zunehmend
breitet sich die Idee des QR-Ansatzes in der Konsumgüterbranche aus.84
3.2.3.5 Collaborative Planning, Forecasting and Replenishment
Mit dem Collaborative Planning, Forecasting and Replenishment85 (CPFR) wird angestrebt,
ein Prozessmodell zur Verbesserung der zwischenbetrieblichen Partnerschaft zwischen Liefe-
ranten und Kunden durch gemeinsam verwaltete Informationen und kooperativ geführte Pro-
zesse zu etablieren.86 Im Zentrum steht dabei die Reduktion von Lagerbeständen bei einer
gleichzeitigen Verbesserung des Lieferservices.87 Mit dem CPFR sollen die aus den Ansätzen
ECR, CR, VMI und QR gewonnenen Erfahrungen genutzt und um weitergehende Praktiken
der Zusammenarbeit erweitert werden.88
Das CPFR-Prozessmodell ist in die drei Stufen Planning, Forecasting und Replenishment
unterteilt.89 In der Planning-Stufe entwickeln die Partner zum einen gemeinsame Regeln der
Zusammenarbeit, insbesondere bezüglich der gemeinsamen Nutzung von Informationen und
deren vertrauliche Behandlung, und zum anderen eine gemeinsame Strategie, die möglichst
viele Normalfälle definiert und damit die Zahl der Ausnahmen minimiert. In der Forecasting-
Phase wird auf der Basis der POS-Daten und Informationen über die geplanten Aktionen eine
Verkaufsprognose erstellt. Anschließend werden die Prognoseobjekte, bei denen die Ist-
Bedarfe über eine bereits definierte Toleranzschwelle hinaus von der Vorhersage abweichen,
als Ausnahmesituation identifiziert. Zur Lösung des durch die Ausnahmesituation entstande-
nen Problems können physische oder elektronische Konferenzen bzw. gemeinsame Datenban-
ken vorgesehen werden. Auf der Basis der Informationen über die Bedarfsprognose und die
Lagerbestände wird eine Vorhersage der Auftragseingänge erstellt. Die prognostizierten Auf-
tragseingänge werden wiederum auf Verstöße gegen die vereinbarten Regeln überprüft, um
84. Vgl. [BlIh97], S. 870.85. Vgl. http://www.cpfr.org, Stand 28.01.2001.86. Vgl. [KnMZ00], S. 112.87. Vgl. [BuKo00], S. 51.88. Vgl. [Hell99], S. 83.89. Vgl. [KnMZ00], S. 114ff.
50 Kapitel 3: Stand der Technik
Ausnahmesituationen aufzudecken und zu lösen. Abschließend können die Auftragseingänge
in verbindliche Aufträge umgewandelt und bestätigt werden.
CPFR stellt einen Rahmen dar, der sich als Ausgangsbasis für Vereinbarungen unter den Teil-
nehmern der Lieferkette eignet. Durch die gemeinsam von allen Teilnehmern der Lieferkette
genutzten Prognosen der Endkundennachfrage und der Planungsdaten trägt CPFR, wie Erfah-
rungen bei Pilotanwendern zeigen90, zur Transparenz und zur Sicherheit der Planung in der
Lieferkette bei. Allerdings erfordert der Einsatz von CPFR von den Beteiligten die Überwin-
dung der traditionellen Grenzen und einen offenen Informationsaustausch, was bei vielen
Unternehmen als Wettbewerbsnachteil angesehen werden kann.91
Der CPFR-Ansatz gibt Richtlinien für den groben Ablauf der Abstimmung in der Lieferkette,
macht aber keine Vorgaben bezüglich der Umsetzung dieser Richtlinien. Allerdings wird der
CPFR-Ansatz vom CPFR-Komitee92 ständig auf der Basis von Erfahrungen aus der Praxis
weiterentwickelt.
3.2.4 Fazit
Grundsätzlich lassen sich das Kanban- und das Fortschrittzahlen-Konzept sowohl für die
inner- als auch für die überbetriebliche Abstimmung einsetzen. Allerdings ist deren Einsatz
nur unter bestimmten Rahmenbedingungen sinnvoll.93 So lässt sich Kanban nur bei einem
regelmäßigen täglichen Teilebedarf erfolgreich anwenden. Darüber hinaus setzen beide
Ansätze eine materialflussorientierte Betriebsmittelanordnung voraus und stellen keine völlige
Alternative zum MRP-II-Konzept dar, da es die zentrale Durchführung der Primärbedarfspla-
nung sowie des langfristigen Kapazitätsabgleichs voranstellt.
Auch für die in Kapitel 3.2.3 vorgestellten Ansätze zur überbetrieblichen Abstimmung können
einige Einschränkungen hinsichtlich ihrer Einsatzmöglichkeiten entlang der Lieferkette aufge-
zeigt werden. Legt man eine grobe Einteilung der Lieferkette in den hintereinandergeschalte-
ten Bereichen Lieferanten, Produzenten und Handel zugrunde, so lässt sich die Reichweite in
Bezug auf den Einsatzbereich in der ersten Spalte der Tabelle5 wiedergeben. Bezüglich des
Kooperationsgrades, also der Intensität der betriebsübergreifenden Zusammenarbeit und der
90. Vgl. [Hell99], S. 85.91. Vgl. Kapitel 2.1.2.92. http://www.cpfr.org.93. Vgl. [Rose94] und [Hoit96].
Kapitel 3: Stand der Technik 51
daraus resultierende Abbau der Informationsasymmetrien, kann der JIT-Ansatz aufgrund der
festgeschriebenen Belieferungsverträge zwischen den beiden Parteien und der Verlagerung der
Lieferdisposition auf den Lieferanten als Mittel betrachtet werden.
Die Fähigkeit zur schnelleren Anpassung des eingesetzten Abstimmungsansatzes an wech-
selnde Bedingungen bzw. zur schnelleren Integration eines neuen Kooperationspartners wird
in Tabelle5 durch das Merkmal Dynamik (Flexibilität) verdeutlicht. Hier weist das CR mit sei-
nen drei Integrationsstufen und das CPFR mit den gemeinsam zu verwaltenden Informationen
und der bilateralen kollaborativen Prozesse eine höhere Flexibilität auf. Dagegen ist die Dyna-
mik bei den restlichen Ansätzen aufgrund der erforderlichen hohen Kosten zum Aufbau der
informationstechnologischen Infrastruktur von gering bis mittel bewertet.
ReichweiteKooperations-
gradDynamik
(Flexibilität)Zeitliche
AusrichtungBranchen-
schwerpunkt
JIT Lieferant - Produzent
mittel mittel operativAutomobilin-dustrie
ECR Produzent - Handel
hoch mittel operativLebensmittel-handel
CR Produzent - Handel
hoch hoch operativKonsumgüter-industrie
VMILieferant - Produzent
bzw. Handelhoch mittel operativ
Konsumgüter-industrie
QR Produzent - Handel
hoch hoch(mittel) operativTextil & Bekleid.
CPFRVom Liefe-ranten bis
zum Handelhoch hoch
strategisch bis operativ
branchenüber-greifend
Tabelle 5: Abgrenzung der Ansätze zur überbetrieblichen Abstimmung
52 Kapitel 3: Stand der Technik
3.3 Standards und Systeme zur Umsetzung des operativen Ferti-
gungsmanagements
Gegenstand dieses Kapitels sind die informationstechnologischen Aspekte zur Unterstützung
der Gestaltung des operativen Fertigungsmanagements innerhalb der Lieferkette. Dabei sollen
gemäss den Anforderungen 3.1 und 3.4, sowohl die möglichen Architektur-Modelle zur Inte-
gration der Komponenten einer dezentralen Einheit des FMI-Systems und zu deren Anbindung
an das ERP/PPS-System als auch die möglichen Modelle zur Realisierung der Kommunikation
zwischen zwei dezentralen Einheiten des FMI-Systems über Unternehmensgrenzen hinweg
untersucht werden. Dementsprechend wird zunächst in Kapitel 3.3.1 auf den Stand der Tech-
nik bezüglich der Integration von Anwendungen eingegangen. Anschließend werden ausge-
wählte Standards und Systeme der überbetrieblichen Integration in Kapitel 3.3.2 kurz
vorgestellt. Zum Schluss wird auf die Möglichkeiten des Einsatzes der Internettechnologie zur
Umsetzung eines Fertigungsmanagement-Informationssystems eingegangen.
3.3.1 Integration von Anwendungen
In diesem Kapitel sollen zunächst in Unterkapitel 3.3.1.1 Arbeiten vorgestellt werden, die
bereits aufgrund ihrer Verbreitung zu einem Quasi-Standard avanciert sind bzw. eine Standar-
disierung der Anwendungsintegration anstreben. In Unterkapitel 3.3.1.2 erfolgt eine kurze
Betrachtung der Eigenschaften der Systeme zur Integration der betrieblichen Informations-
systeme.
3.3.1.1 Standards
Der Bedarf in den Unternehmen nach einer offenen Softwarelandschaft, die langfristig die
Kopplung heterogener Informationssysteme über die Grenzen von Netzwerken hinweg sichert,
führt zu Bestrebungen, Referenzmodelle94 für die Architekturen von verteilten und komponen-
ten-basierten Informationssystemen zu entwickeln. In Kapitel 3.3.1.1.1 werden solche Refe-
renzmodelle vorgestellt. In Kapitel 3.3.1.1.2 wird auf die Arbeiten der Open Application
Group zur Standardisierung von Schnittstellen kurz eingegangen.
94. Sog. Distributed Object Models.
Kapitel 3: Stand der Technik 53
3.3.1.1.1 Middleware
Die meiste Verbreitung finden die drei Middleware-Modelle CORBA95 von der OMG,
DCOM96 von Microsoft und das RMI97 von SUN Microsystems, die im Folgenden beschrie-
ben werden.
• Common Object Request Broker Architecture:
Kernstück der Common Object Request Broker Architecture ist der Object Request Broker
(ORB). Über den ORB können Anwendungen, die auf verschiedenen Hardware-, Betriebs-
system- und Netzwerkumgebungen laufen und in unterschiedlichen Sprachen programmiert
sind, integriert werden. Die Schnittstellen der Anwendungen bzw. Objekte werden dabei in der
deklarativen und objektorientierten Sprache IDL (Interface Definition Language) definiert und
dem ORB bekannt gemacht. Dabei ist IDL unabhängig von einer bestimmten Programmier-
sprache. Um portable Implementierungen von IDL-Schnittstellen in den höheren Program-
miersprachen zu ermöglichen, standardisiert die OMG IDL-Anbindungen zu diesen
Programmiersprachen.98 Zentrales Anliegen der OMG ist dabei die Unterstützung von Porta-
bilität und Wiederverwendung durch objektorientierte Techniken. So werden verschiedene
Klassenbibliotheken, die zum Betrieb eines ORB unverzichtbar sind, in den sog. CORBA-Ser-
vices standardisiert. In den CORBA-Facilities werden dagegen Klassenbibliotheken (anwen-
dungsneutral oder anwendungsbezogen) standardisiert, die in den Anwendungen bzw.
Objekten verwendet werden können. Um den Einsatz von CORBA in möglichst vielen
Anwendungsbereichen zu verbreiten, gründet die OMG sog. Domain Task Forces (DTFs), die
sich mit der Spezifikation von anwendungsspezifischen CORBA-Facilities beschäftigen. Für
den Fertigungsbereich ist diese Aufgabe der CORBAmanufacturing Domain Task Force (mfg
DTF) übertragen worden. Dabei liegen die Schwerpunkte der mfg DTF in den Bereichen
Manufacturing Execution System99 (MES) und Product Data Management.
95. Common Object Request Broker Architecture.96. Distributed Component Object Model.97. Remote Method Invocation.98. Vgl. [OrHaE98].99. Ein MES unterstützt die Abwicklung der Geschäftsprozesse vom Auftragseingang bis zum fertigenErzeugnis. Durch die Benutzung aktueller und exakter Daten kann MES vorkommende Aktivitäten initi-ieren, sie weiterleiten und beratend zur Seite stehen (vgl. [RoFu98], S. 22).
54 Kapitel 3: Stand der Technik
• Distributed Component Object Model:
Das DCOM stellt eine Erweiterung des sog. Component Object Models100 (COM) um Aspekte
der Verteilung dar. Dabei definiert COM einen Standard für die Kommunikation von Objek-
ten, die sich auf einem windowsbasierten System befinden.101 Ziel von DCOM ist es, einem
Client den Zugriff auf Dienste zu ermöglichen, die auf dem Server bereitgestellt werden. Dabei
soll es nicht von Bedeutung sein, in welcher Sprache der Client oder der Server geschrieben
sind. Die Instanzen zuvor definierter DCOM-Klassen stellen ihre Dienste anderen DCOM-
Objekten durch eine oder mehrere Schnittstellen zur Verfügung. Analog zu CORBA wird zur
Erstellung der Interfaces eine an C angelehnte IDL verwendet. Ein DCOM-Object kann dabei
aus mehreren DCOM-Objekten bestehen und deren Verhalten vereinigen. DCOM stellt eine
proprietäre Lösung dar102, jedoch gibt es Bestrebungen der Open Application Group103 zur
Implementierung von DCOM für andere Betriebssysteme.
• Remote Invocation Method:
Mit der Remote Invocation Method (RMI) Architektur sollen Objekte auf Methoden anderer
Objekte zugreifen können, die nicht in derselben Java Virtual Machine104 (VM) implementiert
und die durch ein TCP/IP basiertes Netzwerk miteinander verbunden sind. Ein bedeutendes
Prinzip der RMI Architektur ist, dass die Definition von Verhalten und die Implementierung
des Verhaltens voneinander getrennt sind. Dabei erlaubt die Programmiersprache Java die
Definition eines Verhaltens auf einer anderen VM als die Implementierung dieses Verhaltens.
Dadurch kann der Client das zu erwartende Verhalten eines Dienstes festlegen und der Server
sich um die Ausführung des Dienstes kümmern. RMI verlangt, dass ein Verhalten eines
Remote Dienstes durch ein Java Interface105 definiert wird, während der Dienst selbst durch
eine Klasse beschrieben wird, die eben dieses Interface implementiert.
100. COM stell die Grundlage für das Object Linking and Embedding (OLE) und des darauf aufsetzenden„ActiveX“ dar. 101. Vgl. [Pude97].102. DCOM ist bereits ein fester Bestandteil von Windows NT 4.0 und Windows 95.103. Vgl. Kapitel 3.3.1.1.2.104. Die Java Virtual Machine ist die Umgebung, in der compelierter Java Bytecode abläuft. Der Java-Compiler generiert demnach im Gegensatz zu anderen Compilern keinen plattformabhängigen Maschi-nencode, sondern bytecode, der nur von der Virtual Machine interpretiert werden kann. Dadurch wird einhohes Maß an Portabilität garantiert.105. Java Interfaces sind Schnittstellen, wo ausschließlich abstrakte Methoden und konstante Datenele-mente vereinbart werden können. Eine Klasse kann ein oder mehrere Interfaces implementieren und sodie von C++ bekannte Mehrfachvererbung ansatzweise realisieren.
Kapitel 3: Stand der Technik 55
Fazit: Zwar stellt CORBA die Spezifikation eines offenen Standards dar, das von einem unab-
hängigen Konsortium vorgeschlagen wird, allerdings sind Implementierungen der unterschied-
lichen Hersteller häufig untereinander nicht hundertprozentig kompatibel. DCOM dagegen
repräsentiert die Implementierung des Objektmodells von Microsoft und ist daher herstellerab-
hängig. Um die Interoperabilität zwischen den unterschiedlichen CORBA-Implementierungen
und DCOM zu realisieren, werden von einigen Herstellern sog. Bridges angeboten, die die
Kommunikation der beiden Objektmodelle ermöglichen.
Weiterhin gibt es Bestrebungen zur Integration von RMI und CORBA. Dabei soll das bisher
im RMI auf der Basis von TCP/IP verwendete Protokoll JRMI106 durch den RMI-IIOP ersetzt
werden.107 RMI-IIOP soll auf dem von der OMG entwickelten Internet Inter-ORB Protocol
basieren und somit zur Integration von CORBA und RMI beitragen.
3.3.1.1.2 Open Application Group
Die Open Application Group108 (OAG) zielt auf die Festlegung von Standardschnittstellen für
unterschiedliche Anwendungen inner- und außerhalb der Unternehmen.109 Die von dieser
Gruppe entwickelten Spezifikationen legen die Kommunikation auf Basis von sog. Business
Object Document (BOD) fest, so dass auch Anwendungen unterschiedlicher Anbieter mitein-
ander kommunizieren können. Dabei besteht ein BOD aus einem Control Area und einem
Business Data Area. Das Control Area dient einerseits der globalen Identifikation110 eines
BOD und andererseits der Übertragung von Informationen zur Bestimmung des auszuführen-
den Dienstes, des ausführenden Objektes und einer Revisionsnummer zur Versionierung des
BOD. Business Data Area besteht aus einem Datendefinitionsbereich, der das Format der zu
übertragenden Daten beschreibt und einem Bereich, der die Ausprägung der definierten Daten
umfasst.
Weiterhin befasst sich die OAG mit der Entwicklung von Integrationsmodellen, die auf der
Basis der von der OAG entwickelten Technologie Szenarien für die Integration von Anwen-
dungen unterschiedlicher Bereiche aufzeigen. Dabei sollen die dort entworfenen Szenarien als
106. Java Remote Methode Protocol107. Die Arbeiten werden im Wesentlichen von den Unternehmen Sun und IBM vorangetrieben und sol-len im JDK 1.3 enthalten sein.108. 1995 von einigen Softwareherstellern gegründet109. Vgl. [OAG99] und http://www.openapplications.org110. Hierzu werden Angaben zum Sender, Datum und Uhrzeit sowie Informationen über den Adressatenverwendet.
56 Kapitel 3: Stand der Technik
Empfehlung für die Realisierung der Schnittstellen betrachtet werden. Die von der OAG ange-
strebten Modelle könnten den Aufwand bei der Erstellung von Schnittstellen erheblich redu-
zieren, allerdings sind viele führende Hersteller der ERP/PPS-Systeme in der OAG bisher
nicht vertreten.
3.3.1.2 Systeme
In diesem Kapitel erfolgt eine kurze Beschreibung des Standes der Technik bzgl. der Systeme
zur Anwendungsintegration. Hierzu wird in Kapitel 3.3.1.2.1 die Thematik Enterprise Appli-
cation Integration kurz skizziert. Anschließend wird in Kapitel 3.3.1.2.2 auf das „Application
Linking Enabling“-Konzept eingegangen.
3.3.1.2.1 Enterprise Application Integration
Ziel der Enterprise Application Integration (EAI) ist es, den zunehmenden Problemen bei der
Integration heterogener Anwendungen entgegenzuwirken und die Geschäftsprozesse anwen-
dungsübergreifend durchzuführen. Dadurch sollen sowohl anwendungsübergreifende Abläufe
modelliert und ausgeführt als auch unternehmensübergreifende Abstimmungen realisiert wer-
den können.111 Für die Integration von mehreren Anwendungen werden die Daten-, Funkti-
ons- und Prozessebene unterschieden. Auf jeder Ebene sind dabei organisatorische und
technische Aspekte der Integration zu beachten (vgl. Abbildung 16).
111. Vgl. [Linth00], S. 267ff.
Kapitel 3: Stand der Technik 57
Grundsätzlich lassen sich die EAI-Werkzeuge anhand der bei der Integration verfolgten Archi-
tektur in die folgenden Typen unterscheiden112:
Die „Process Integration Server“-Lösung stellt einen skalierbaren „Integrations-Server“113
als Multitier Anwendung in den Mittelpunkt. Der Integrations-Server nimmt einerseits die
Aufgaben der Integration der (Web-)Frontends mit den Back-Office-Anwendungen und
Datenbanken wahr, und andererseits bietet es zusätzliche Funktionen zur Automatisierung von
Workflow, Event-Schnittstellen sowie für vorgefertigte Adapter.114
Bei der „Message Broker“-Lösung wird für jede zu integrierende Anwendung eine Run-
Time-Umgebung installiert. Wird eine Nachricht von einem Sender verschickt, so überprüft
jede Run-Time-Umgebung, ob die Nachricht für sie bestimmt ist. Ein zentrales Directory mit
112. Vgl. [Reut00] und „Auswahl eines EAI-Tools“ unter www.entory.com113. Auch „Application Server“ genannt (vgl. [Matt99])114. Ein Adapter bzw. Connector wird in [RuMB01] wie folgt definiert: „A connector logic that is pro-grammed in an application whose sole purpose is to provide access to the presentation, data, or functio-nality of the application in a structured manner. The connector hides the complexity of translating andcommunicating a message or an invocation on an interface for use by the application“.
Inte
grat
ions
gege
nsta
nd Dat
en-
inte
grat
ion
Funk
tions
-in
tegr
atio
nPr
ozes
s-in
tegr
atio
nOrganisatorische Aspekte
Integrationsbereich
• Mappingtabellen für denDatenimport und -export
• Entwurf gemeinsamerDatenstrukturen
Technische Aspekte
• Technologie für denDatenaustausch (XMLbzw. EDIFACT)
• Abstimmung von Laufrei-henfolge und -häufigkeit
• Ablaufsteuerung der Pla-nungskomponenten
• Aufruf anwendungsexter-ner Funktionen
• Anwendungsübergrei-fende Ereignissteuerung
• Continuous Process Engi-neering zur IdentifikationIntegrationsfähiger Pro-zessbestandteile
• Kopplung von Anwen-dungsbausteinen über Pro-zessmodelle
• Steuerung über APIs/RFCs, Einsatz von WFMS
Abbildung 16: EAI Integrationsmatrix
58 Kapitel 3: Stand der Technik
Replikationsfunktionalität übernimmt die Steuerung der zusammenhängenden Abläufe. Die
Funktionalität beschränkt sich auf Event-Schnittstellen und Publish-/Subscribe-Mechanismen.
Die „Datenintegration“-Lösung stellt die Integration via Datenbanken durch eine regelba-
sierte Umformung der Daten und Datensynchronisation her. Dazu werden häufig Triggerme-
chanismen der Datenbankmanagementsysteme für die Event-Steuerung verwendet.
Fazit: EAI stellt einen Ansatz dar, der den hohen Kosten- und Zeitaufwand bei der Erstellung
von Schnittstellen zwischen den Anwendungen gegenüber einer individuell erstellten Lösung
erheblich reduzieren kann. Jedoch reicht das Spektrum der EAI-Werkzeuge von einer einfa-
chen Lösung zur Datenübermittlung bis hin zu einer komplexeren Lösung zur Steuerung der
Abläufe zwischen unterschiedlichen Anwendungen, so dass erhebliche Funktionalitätsunter-
schiede existieren. Weiterhin handelt es sich bei den von EAI-Anbietern angebotenen EAI-
Werkzeugen um proprietäre Lösungen, die aufgrund der fehlenden Standards untereinander
häufig inkompatibel sind.115 Um die Interoperabilität unter den EAI-Werkzeugen voranzutrei-
ben, haben sich die führenden EAI-Anbieter im Enterprise Integration Council116 zusammen-
geschlossen.
3.3.1.2.2 Application Linking Enabling
Das ALE-Konzept ist von der SAP AG entwickelt worden und dient der Integration von
betriebswirtschaftlichen Anwendungssystemen. Es basiert auf einem kontrollierten Nachrich-
tenaustausch und konsistenter Datenhaltung. Dabei erfolgt die Integration der unterschiedli-
chen Anwendungen ausschließlich über synchrone und asynchrone
Kommunikationsmechanismen. Die ALE-Architektur kann in drei Dienstebenen aufgeteilt
werden: Die Anwendungsdienstebene zur Erzeugung von betriebswirtschaftlichen Nachrichten
zur Unterstützung des integrierten Workflows, die Verarbeitungsdienstebene zur Festlegung
und Überprüfung der Nachrichtenempfänger sowie zum Filtern und Umsetzen der Nachrich-
ten, die Kommunikationsdienstebene für die Sicherung der Datenübertragung auf technischer
Ebene. Das ALE-Konzept stellt, trotz der weiten Verbreitung der SAP-Lösungen in der Praxis,
einen spezifischen Ansatz zur Integration unterschiedlicher SAP-Lösungen bzw. zur Anbin-
dung einer Fremdkomponente an eine SAP-Lösung dar.
115. Vgl. [RiWa99], S. 57116. http://www.eicouncil.org, 12/2000
Kapitel 3: Stand der Technik 59
3.3.2 Überbetriebliche Integration
In diesem Kapitel erfolgt zunächst im Unterkapitel 3.3.2.1 die Vorstellung der Standardisie-
rungsbestrebungen zur überbetrieblichen Integration der innerbetrieblichen Informationssy-
steme. Anschließend wird in Unterkapitel 3.3.2.2 auf ausgewählte Systeme zur Umsetzung der
in den Kapiteln 3.1 und 3.2 beschriebenen Ansätze eingegangen.
3.3.2.1 Standards
Als Standards zur Umsetzung des überbetrieblichen Informationsaustausches zwischen den
ERP/PPS-Systemen sollen hier zunächst die unter der Bezeichnung Electronic Data Inter-
change zusammengefassten Protokolle betrachtet werden. Anschließend wird auf das CALS-
Konzept eingegangen.
3.3.2.1.1 Electronic Data Interchange
Unter EDI werden alle Systemkonzepte verstanden, die es ermöglichen, in einem Rechner
erstellte Daten zu einem anderen, räumlich entfernten System zu übertragen und dort ohne vor-
herigen manuellen Eingriff weiterzuverarbeiten. Eine unmittelbare Weiterverarbeitung der
empfangenen Daten ist jedoch nur möglich, wenn Sender und Empfänger die übertragenen
Nachrichten gleich interpretieren. Dazu müssen Vereinbarungen zwischen ihnen getroffen
werden, so z.B. über die Struktur der Dateien und die Bedeutung der einzelnen Datenseg-
mente. Eine Reihe solcher Vereinbarungen wurden in der Vergangenheit getroffen, dadurch
entstanden länderspezifische Standards (vgl. Abbildung 17117)
117. Vgl. [Frigo97], S. 59.
60 Kapitel 3: Stand der Technik
Mit Hilfe dieser Standards können erhebliche Einsparungen und Zeitvorteile realisiert werden,
die sich jedoch stets nur auf den Nachrichtenaustausch innerhalb der Branche oder des Landes
beziehen. Eine branchen- oder länderspezifische Kommunikation muß auf anderen Wegen
stattfinden.
Alle über den Teilnehmerkreis der über EDI verbundenen Unternehmen hinausgehenden
Kommunikationsbeziehungen müssen jedoch weiterhin konventionell118 abgewickelt werden,
da die gleichzeitige Einrichtung und Pflege verschiedener EDI-Kommunikationssysteme aus
Kostengründen zumeist nicht möglich sind. Um dieses Problem zu überwinden, wird von den
Vereinten Nationen die Entwicklung von EDIFACT119 vorangetrieben. Unter deren Leitung
erarbeiten und verabschieden nationale und internationale Normungsgremien aus unterschied-
lichen Bereichen Nachrichtentypen. Diese Nachrichtentypen werden für sämtliche Geschäfts-
vorfälle entwickelt, die bei Unternehmen in unterschiedlichsten Branchen anfallen, wie z.B.
Bestellungen, Lieferstatusmitteilungen, Rechnungen, Zahlungsaufträge oder Zollformalitäten.
Zur Zeit sind ca. 40 Nachrichtentypen für die praktische Nutzung freigegeben, ca. 160 weitere
befinden sich in der Entwicklungs- oder Testphase und werden nach Freigabe einsetzbar sein.
118. D.h.: per Brief, Telefax, Telex oder Telefon, etc.119. EDIFACT = Electronic Data Interchange For Administration, Commerce and Transport: von UN/ECE (United Nations Economic Commission for Europe) entwickelte und jetzt von ISO ratifizierte EDI-Normen. EDIFACT wurde als Rahmen für eine nationale und internationale Syntax sowie für spezielleNachrichtenformate entwickelt.
EDIFACTEancom
SedasAnsi X.12
international
national
Branchen-abhängig
Branchenun-abhängig
IGES
STEPEditeur
OdetteEmedi
Editex
SWIFT
VDA
DakomGencod
GTDI/Tradacom
Abbildung 17: Standards für den überbetrieblichen Datenaustausch
Kapitel 3: Stand der Technik 61
Durch die universelle Standardisierung von EDI zu EDIFACT werden folgende Vorteile
erreicht:
• Der EDIFACT-Standard gilt international
• Die Geschäftsvorfälle sind branchenneutral und bereits sehr umfassend, es können nahezu
alle relevanten Geschäftsvorfälle durch EDIFACT abgedeckt werden
EDIFACT erweist sich für jeden Anwendungsbereich als sinnvoll, in dem viele Geschäftsvor-
fälle abgewickelt werden müssen und durch Automatisierung große Einsparungen erzielt wer-
den können. Dazu ist es jedoch notwendig, dass auch die Geschäftspartner EDIFACT
anwenden. Der Vorteil gegenüber anderen EDI-Standards tritt besonders dort zutage, wo viele
Geschäftsprozesse branchenübergreifend und dadurch mit einem branchenspezifischen Stan-
dard nicht mehr zu bewältigen sind. Schwächen zeigt EDIFACT in Bereichen, in denen pro-
duktdefinierende Daten zu spezifizieren sind.
Mit der zunehmenden Verbreitung des Internets und den dadurch „erleichterten“ Zugang zu
den Daten eröffnen sich neue Möglichkeiten zur Realisierung von EDI-Systemen. Dabei wird
zwischen WebEDI und Internet-EDI unterschieden.120 WebEDI-Anwendungen ermöglichen
Unternehmen, die noch kein EDI einsetzen, mit ihren Geschäftspartnern im EDIFACT-Format
zu kommunizieren, ohne selbst EDIFACT einzusetzen. In diesem Fall muss der Nicht-EDI-
Partner einen Dienstleister einsetzen, der für ihn die Nachrichten in das bzw. aus dem EDI-
FACT-Format übersetzt und weiterleitet.121 Im Normalfall wird der Nicht-EDI-Partner die
120. Die Deutsche EDI-Gesellschaft (http://www.dedig.de).
Kon
vert
ieru
ng
Kon
vert
ieru
ng
Lieferant Abnehmer
BuchhaltungBuchhaltung
EDIFACT-NachrichtenAnfrage
Angebot
Auftrag
Auftragsbestätigung
Lieferstatus
Versandanzeiger
Rechnung
EinkaufAuftragsab-wicklung
Abbildung 18: Beispiel eines EDIFACT-strukturierten Nachrichtenaustausches
62 Kapitel 3: Stand der Technik
empfangenen Nachrichten für seine IT-Systeme aufbereiten müssen, so dass der eigentliche
Vorteil des Web-EDI beim EDI-Partner liegt. Mit dem Internet-EDI findet der Informations-
austausch zwischen den beiden EDI-Partnern unter Nutzung von Internet-Diensten122 statt.
Durch den Einsatz von WebEDI bzw. Internet-EDI können die Kosten gegenüber denen tradi-
tioneller EDI-Systeme erheblich reduziert werden.123
3.3.2.1.2 Computer-aided Acquisition and Logistics Support
Das wesentliche Anliegen von CALS124 ist, den Informationsaustausch kooperierender Unter-
nehmen entlang der Wertschöpfungskette qualitativ zu verbessern und zu beschleunigen.125
Das Grundprinzip bildet dabei die Einbindung aller Beteiligten in den gesamten Lebensweg
eines Produktes, um so sicherzustellen, dass Informationen beliebiger Art rechtzeitig und in
einer wiederverwertbaren Form bereitgestellt werden - unabhängig davon, wo und in welchen
Systemen sie gespeichert sind.
Bei CALS handelt es sich nicht um ein vollständig neu entwickeltes Konzept, sondern um eine
Sammlung bereits bestehender Richtlinien, Austauschregeln, kaufmännischer und technischer
Standards und Normen. Zur Integration der Daten und Funktionalitäten verfolgt CALS ein Stu-
fenkonzept. Um den Aufbau einer (befristeten) überbetrieblichen Kooperation nicht mit zu
hohen Anforderungen an die Informationsverarbeitung zu belasten, sieht das CALS-Konzept in
der ersten Phase - sog. CALS I - lediglich die Weitergabe aller Projektdokumente über geeig-
nete Standardaustauschformate vor. Die dadurch bedingte redundante Datenhaltung der Infor-
mationen soll in der zweiten Stufe von CALS - sog. CALS II - überwunden werden, indem eine
integrierte Projektdatenbank126 (sog. Contractor Integrated Technical Information Service,
CITIS) aufgebaut wird. Der Vorteil dieser zweistufigen Vorgehensweise liegt darin, dass die
meisten Unternehmen die Implementierung von CALS I mit einem vertretbaren Aufwand reali-
sieren können. Die End-Vision des CALS-Konzeptes sieht die vollständige informationstechni-
121. Vgl. [PfoKo99], S. 38.122. Z.B. File Transfer Protocol (FTP) oder Simple Mail Transfer Protocol (SMTP).123. Vgl. [BuKo00], S. 95.124. CALS geht auf eine Initiative des amerikanischen Verteidigungsministeriums zurück. Ziel war es,den Informationsaustausch zwischen Behörden und Unternehmen bei grössen Militärprojekten durch einKonzept für einen koordinierten Einsatz von Standards und Normen zu verbesseren. Seitdem wird CALSfortlaufend weiterentwickelt und gewinnt als Strategie für die Nutzung modernester Informationsstrate-gien und internationaler Standards im überbetrieblichen Datenaustausch immer mehr, auch in Branchenausserhalb der Rüstungsindustrie (wie Luft- und Raumfahrt- oder der Automobilindustrie) an Bedeutung.Vgl. http://www.CALS.nato.be, Stand 12.12.1999.125. Vgl. [Schin96].126. Vgl. [Schin96], S. 206.
Kapitel 3: Stand der Technik 63
sche Verknüpfung aller unternehmensinternen und unternehmensübergreifenden Abläufe
während des gesamten Lebenszyklusses eines Produkts vor. Alle vorhandenen und künftigen
rechnerunterstützten Systeme sollen auf einem gemeinsamen Konzept zur Verfeinerung der
Geschäftsabläufe und zur Integration bisher voneinander getrennter, nicht kompatibler Daten-
haltungen aufsetzen.
Fazit: CALS bildet derzeit lediglich einen Rahmen für eine Vielzahl verschiedener Standards,
Verfahren und Methoden zum Umgang mit Daten, deren Ausgestaltung und Anwendungsbe-
reich zudem teilweise noch nicht in allen Einzelheiten geklärt ist. Es genügt nicht, für eine
betriebliche Kooperation nur allgemein die Anwendung von CALS zu vereinbaren. Es muss
festgelegt werden, für welche Funktionen welche Standards aus dem „Baukasten“ von CALS
Anwendung finden.
3.3.2.2 Systeme
In diesem Kapitel werden ausgewählte Systeme betrachtet, die einen ähnlichen Anwendungs-
bereich abdecken, wie den des zu entwickelnden Fertigungsmanagment-Informationssystems.
Hierzu erfolgt zunächst in Kapitel 3.3.2.2.1 eine Beschreibung der „Standard“-Architektur von
aktuellen SCM-Systemen. In Kapitel 3.3.2.2.2 findet eine grobe Darstellung der Funktionalität
der Lieferabrufsysteme statt. Zum Schluss erfolgt in Kapitel 3.3.2.2.3 die Beschreibung eines
„schlanken“ Systems zur Unterstützung der Disposition in einem KMUnet.127
3.3.2.2.1 SCM-Systeme
Zur Umsetzung der in Kapitel 2.1.2 angesprochenen Konzepte des Supply Chain Manage-
ments (SCM) werden von verschiedenen Standardsoftwareanbietern SCM-Systeme angeboten.
Die SCM-Systeme bestehen im Wesentlichen aus Modulen zur Unterstützung der Modellie-
rung, Planung und Steuerung der Lieferkette sowie Schnittstellenmodulen zur Integration mit
den lokalen ERP/PPS-Systemen. Abbildung 19 zeigt die funktionale Architektur eines SCM-
Systems.128
Die Modellierung umfasst die Konfiguration der gesamten Lieferkette. Dazu gehört neben der
Modellierung der Versorgungsbeziehungen der Organisationseinheiten von den Lieferanten
der Vormaterialien bis zu den Absatzmärkten die Spezifikation der kapazitäts-, termin- und
127. Ein Netzwerk klein- und mittelständischer Unternehmen. 128. In Anlehnung an [KuHe98], S. 9 und [Kort99], S. 21.
64 Kapitel 3: Stand der Technik
kostenbezogenen Informationen.129 Dadurch soll eine realitätsgetreue Abbildung der realen
logistischen Lieferkette unter Berücksichtigung aller Restriktionen erreicht werden.130 Die
Gestaltung der Leistungsstrukturen der Lieferkette erfolgt für einen langfristigen Zeitraum,
daher wird die Modellierungsphase häufig als strategische Planung bezeichnet.131
Auf der Basis der modellierten Struktur der Lieferkette finden die Planung und Abstimmung
von Mengenflüssen und Kapazitäten entlang der Lieferkette statt. In dieser Phase erfolgt
zunächst eine standortübergreifende Vorhersage des zukünftigen Absatzes bzw. Bedarfs.132
Anschließend wird aufbauend auf den prognostizierten bzw. realen Kundenbedarfen ein
Abgleich mit den Kapazitäten und Beständen der Lieferkette angestrebt. Ziel dabei ist einer-
seits die Erstellung von Lagerbestands- und Verteilungsplänen und andererseits die Generie-
rung von Produktionsplänen für die einzelnen Standorte. In einer weiteren Planungsphase
werden die erstellten Pläne auf einer detaillierteren Ebene verfeinert. So werden im Rahmen
der Beschaffungsplanung zunächst die Lieferkettenelemente identifiziert, die einen Bedarf auf-
weisen bzw. zur Deckung eines Bedarfs beitragen können.133 Anschließend erfolgt eine
Zuordnung, welche Bedarfe von welchen Lieferanten befriedigt werden können bzw. zu
befriedigen sind. Die Transportplanung umfasst die Tourenplanung, die Transportmittelaus-
wahl und die Kapazitätsbetrachtung bezüglich der Transportmittel.
Die Module zur Steuerung der Lieferkette unterstützen die Umsetzung der bereits erstellten
Pläne auf operativer Ebene für jedes Lieferkettenelement. Dabei findet eine Reihenfolgepla-
nung der Fertigungsaufträge und eine Belegungsplanung der Fertigungsaufträge auf den jewei-
ligen Fertigungsressourcen statt. Weiterhin umfassen die Steuerungsmodule der SCM-
Systeme Funktionalitäten zur kurzfristigen Ermittlung von verbindlichen Lieferterminzusagen.
Dazu werden u.a. die aktuelle Kapazitäts- und Materialsituation und die Kosten von verschie-
denen Alternativen berücksichtigt.134 Dadurch kann der Kunde umgehend über die Durchführ-
barkeit eines Auftrages informiert werden. Um auf kurzfristig aufgetretenen Änderungen
129. Beispielsweise die Modellierung der Fertigungs- und Lagerkapazitäten. 130. Vgl. [PPVR99], S. 10.131. Vgl. [Kort99], S. 21.132. Als Eingangsfaktoren zur Absatzplanung werden neben den Produktvarianten und Vertriebsgebieteninsbesondere die Vergangenheitsdaten mit einbezogen (vgl. [Kort99], S. 22).133. Vgl. [PPVR99], S. 22.134. Eine solche Funktionalität wird als Available-To-Promise (ATP) bezeichnet. Häufig wird in diesemZusammenhang auch der Begriff Capable-To-Promise (CTP) verwendet. Dies steht für eine Änderung derFertigungs- bzw. Distributionspläne für den Fall, dass ein vom Endkunden gewünschter Auftrag nicht imBestand oder Plan vorgesehen war. CTP wird als Teil von ATP angesehen (vgl. [Pete98]).
Kapitel 3: Stand der Technik 65
lieferkettenübergreifend zu reagieren, werden Abstimmungsmechanismen angeboten, die ein
kooperatives Management der dispositionsrelevanten Störungen gewährleisten.
Zur Unterstützung der Informationsversorgung in der Lieferkette ist einerseits eine enge Ver-
bindung der SCM-Systeme mit den innerbetrieblich eingesetzten ERP/PPS-Systemen und
andererseits eine Verbesserung der Informationsflüsse zu den vor- und nachgelagerten Organi-
sationseinheiten unumgänglich. Daher enthalten die SCM-Systeme Schnittstellenmodule135
für die Integration von ERP/PPS-Systemen. Aufgabe der Schnittstellenmodule ist zum einen
die Übernahme von Daten bezüglich der Struktur der Fertigungs- und Transportprozesse und
zum anderen der Austausch von Bewegungsdaten136 zur Synchronisation mit den lokalen
ERP/PPS-Systemen.
Zur Stärkung der Integration mit den vor- und nachgelagerten Organisationseinheiten werden
zunehmend auf der Basis geschlossener oder öffentlicher Netzwerke (Internet), Workflowsy-
steme zur Realisierung von Geschäftsprozessen für die gemeinsame Planung oder Problemlö-
sung in der Lieferkette angeboten. So hat der SCM-Softwarehersteller i2 einen Standard137
zum elektronischen Austausch von Planungsdaten entwickelt, der die Übertragung von
Geschäftsregeln und -vorgehensweisen, freien und reservierten Kapazitäten, Fertigstellungs-
und Versandterminen zur Entscheidungsunterstützung ermöglicht.138
135. Vgl. [KnMZ00].136. Beispielsweise IST-Daten über die bereits gefertigte Menge an Erzeugnissen in einem bestimmtenZeitraum.137. Electronic Planning Interchange (EPI).138. Vgl. [Bell97].
66 Kapitel 3: Stand der Technik
Die von den SCM-Systemen realisierten Funktionalitäten lassen sich grundsätzlich als Ergän-
zung oder Erweiterung der Funktionalitäten der klassischen ERP/PPS-Systeme betrachten.139
So werden die Funktionalitäten der ERP/PPS-Systeme um Funktionalitäten zur Modellierung
der Leistungsstruktur über die gesamte Lieferkette ergänzt, und gleichzeitig findet eine Erwei-
tung der bereits in den ERP/PPS-Systemen vorhandenen Funktionalitäten zur Termin-, Men-
gen- und Kapazitätsplanung um parametrisierbare Optimierungsverfahren (sog. Advanced
Planning and Scheduling (APS)) statt, die vorwiegend auf den mittel- und kurzfristigen
Bereich ausgerichtet sind.
Aktuelle Erhebungen über die in der Praxis eingesetzten Funktionalitäten der SCM-Systeme
zeigen, dass die existierenden Installationen der SCM-Systeme sich im Wesentlichen auf die
unternehmensinterne Lieferkette beschränken.140 Wesentliche Gründe hierfür sind einerseits
die organisatorischen und/oder kulturellen Vorbehalte gegenüber einer lieferkettenübergrei-
fenden Planung und andererseits die fehlende Bereitschaft zum intensiven und echtzeitnahen
Informationaustausch in der Lieferkette.141 So findet die verbesserte Planung lokal auf der
139. Vgl. [PPVR99], S. 43.140. Vgl. [Kort99], S. 101.141. Vgl. [PPVR99], S. 46.
Schnittstellen
Strategische Planung
Produktionsplanung Distributionsplanung Absatzsplanung
TransportsplanungBeschaffungsplanung
Produktionsfeinplanung & -steuerung Available to Promise (ATP)
Einkauf PPS/ MRP IILager-verwaltung
Auftrags-bearbeitung
Daten-austausch
ERP/PPS-System
SCM-System
Abbildung 19: Funktionen von SCM-Systemen
Verbundplanung
Kapitel 3: Stand der Technik 67
Basis von Informationen über die vor- und nachgelagerten Organisationseinheiten statt (vgl.
Abbildung 20142). Dabei werden lokale Optimierungsziele angestrebt. Dadurch können die
rechtlich selbständigen und damit unabhängigen Unternehmen ihre eigenen individuellen Ziele
verfolgen und damit nur lokale Verbesserungen erreichen. Die von dem SCM-Ansatz inten-
dierte lieferkettenübergreifende Planung auf der Basis lieferkettenübergreifender Daten eignet
sich besonders für Unternehmen mit mehreren Standorten (vgl. Abbildung 20, rechtes oberes
Feld).
3.3.2.2.2 Lieferabrufsysteme
Bei einem Lieferabrufsystem handelt es sich um ein rechnergestütztes vernetztes System zur
Abwicklung der Material- bzw. Erzeugnisdisposition zwischen Abnehmern und Lieferan-
ten.143 Aus Abnehmersicht sollen die Abrufe in Raten die rechtzeitige, in Mengen und
Umfang kostenoptimale Marterialversorgung ermöglichen. Aus Lieferantensicht sollen mit der
Einbindung in ein Lieferabrufsystem aufgrund der längerfristigen Belieferung144 Mengenvor-
teile erreicht werden.
Ein Lieferabrufsystem kann, wie in Abbildung 21 gezeigt, in drei wesentliche Komponenten
gegliedert werden.145 In der Planungs- und Dispositionskomponente werden auf Abnehmer-
142. In Anlehnung an [PPVR99], S. 48.143. Vgl. [Thal99], S. 166.144. Beispielsweise durch Rahmenverträge.145. Vgl. [Thal97].
lokal
glob
allo
kal
global
Fokus der Optimierung
Verfügbarkeit an Informationen
ERP/PPS-Systeme
Multi-CompanySCM
Multi-SiteSCM
Abbildung 20: Entwicklungstendenzen für den Einsatz von SCM-Systemen
angestrebteEntwicklung
Ak
t. E
ntw
ickl
ung
68 Kapitel 3: Stand der Technik
seite Plan- und Istzahlen ermittelt, bezogen auf Menge und Zeitpunkt der durch die Lieferab-
rufe zu bestellenden Raten. Hierzu sind der Planungshorizont, das Zeitraster und der
Planungszyklus vorgegeben. Der Planungshorizont definiert die Vorschauperiode.146 Daten,
für Plan-Abrufe können aus der Programmplanung mittels Prognoserechnung oder Schätzung,
für Ist-Abrufe aus der Materialbedarfsrechnung durch Stücklistenauflösung gewonnen werden.
Durch den Planungszyklus wird vorgegeben, wie die Lieferabrufe fortgeschrieben werden sol-
len.
Auf der Lieferantenseite werden in der Abrufkomponente Plan- und Ist-Daten erzeugt. Dabei
umfasst ein Lieferabruf u.a. Bestellmenge und Zeitpunkt für die vom Lieferanten zu produzie-
renden Teile. Für den Lieferanten wichtig ist der Übergang von geplanten Bestellungen auf
konkrete, d.h. rechtsverbindliche (Ist-)Abrufe. Die dritte Komponente im Lieferabrufsystem
stellt die Kommunikationskomponente dar. Es bietet die Möglichkeit zur Übermittlung der Lie-
ferabrufe mittels der Datenfernübertragung (DFÜ) an.
Lieferabrufsysteme werden häufig eingesetzt, um mit Hilfe von Lieferabrufen Nachfrage-
schwankungen über eine Verringerung oder Erhöhung der Bestellumfänge bzw. Veränderung
der Bestellzeitpunkte auf die Lieferanten zu übertragen. Problematisch sind allerdings - neben
der technischen und organisatorischen Installation des Lieferabrufsystems - meist die zusätzli-
chen, erhöhten Anforderungen an die betriebliche Flexibilität und der Effekt auf die Lagerhal-
146. Beispielsweise geplante Bestellungen in den zukünftigen Monaten und tatsächliche Bestellungen inden nächsten Tagen.
AbnehmerZulieferer
Planungs- undDispositionskomponenteAbrufkomponente
Kommunikationskomp.
Datenfernübertragung
gefertigte Aufträge
Bedarfsschwankungen
Lieferabrufe
Abbildung 21: Lieferabrufsystem als Bindeglied in der Lieferkette
Rahmenverträge
flexible Produktion
Kapitel 3: Stand der Technik 69
tung des Lieferanten. Die Folge des Einsatzes von Lieferabrufsystemen ist meist eine
Übernahme der Bevorratung durch den Zulieferer.
3.3.2.2.3 Virtuelle Dispositionsdatenbank
Ziel des durch das Bundesministerium für Bildung und Forschung (bmb+f) geförderten Pro-
jekts KMUnet war, die Intensivierung der Zusammenarbeit im Bereich der Logistikabwick-
lung zwischen den Abnehmern und deren KMU-Lieferanten zu intensivieren.147 Insbesondere
sollten durch das Logistikabwicklungssystem folgende Ziele erreicht werden: Transaktionsko-
stensenkung durch Vermeidung von Doppelerfassung und Automatisierung notwendiger, aber
nicht wertschöpfender Tätigkeiten, die Beschleunigung der Auftragsdurchlaufzeiten mittels
echtzeitnaher Bedarfsermittlung und -weiterleitung und die Halbierung der Bestände in der
Logisitkkette. Um den kleineren Unternehmen den Zugang zum intendierten Logistikabwick-
lungssystem zu garantieren, wurde die Vorgabe gemacht, die Einführungskosten des Systems
in einem Unternehmen möglichst unter 10 TDM zu halten.148
Das aus dem Projekt entstandene Logistikabwicklungssystem, die virtuelle Dispositionsdaten-
bank (VDDB), ist eine Zusatzkomponente zum PPS-System, die auf dem Austausch und Ver-
gleich der relevanten Produktionsplanungs- und Bedarfsdaten basiert. Die Integration der
VDDB in das PPS-System findet über die Trigger-Mechanismen des Datenbankmanagement-
Systems der PPS-Datenbank statt. Dabei werden durch die Trigger Ereignisse ermittelt, die bei
einem PPS-Ereignis eines Partners Vergleiche, Berechnungen und ggf. Aktionen149 anstoßen.
Das Konzept der VDDB eignet sich für den Einsatz in solchen KMUnet-Verbünden, wo ein
Abnehmer als fokales Unternehmen auftritt und seine Lieferanten an sich bindet. Somit ist der
Schwerpunkt der VDDB-Funktionalität auf den Abnehmer ausgerichtet. Auf der Lieferanten-
seite beschränkt sich die Funktionalität im Wesentlichen auf Triggern zum Auslesen der Pla-
nungsdaten aus dem PPS-System und der Datenspeicherung in einer Datei. Hat ein Lieferant
weitere Abnehmer, die keine VDDB betreiben, so müssen deren Aufträge anders disponiert
werden. Somit kann der Einsatz unterschiedlicher Dispositionssysteme zu einem großen Auf-
wand beim Lieferanten führen. Da die technische Realisierung auf Trigger-Mechanismen
147. Vgl. S. 2 in [KSDS99].148. Vgl. S. 4 in [KSDS99].149. Aktionen sind ereignisgesteuerte Abläufe, die aufgrund verbundweit festgelegter Ereignisse, die einmanuelles Nachregeln eines oder mehrerer Logistiksysteme erfordern, angestoßen werden. Aktionen wer-den mittels Emails den Disponenten bekannt gemacht (vgl. [KSDS99], S. 11).
70 Kapitel 3: Stand der Technik
basiert, ist es häufig unumgänglich, die Implementierung der Trigger bei jedem Release- oder
Systemwechsel des DBMS zu erneuern bzw. zu überprüfen.
3.3.3 Die Internet-Technologie
In diesem Kapitel werden die Möglichkeiten der Nutzung der Internet-Technologie150 für die
Gestaltung der Informationsflüsse innerhalb der Lieferkette untersucht. Dabei ist in Abhäng-
keit von der organisatorischen Reichweite des Einsatzgebietes und der Benutzergruppen zwi-
schen Intranet und Extranet zu unterscheiden. Unter einem Intranet ist in diesem
Zusammenhang ein abgeschlossenes Netzwerk auf Basis der Internet-Technologie zu verste-
hen, das nur unternehmensinternen Benutzern zur Verfügung steht. Ein Extranet stellt ein
Intranet dar, das in Teilen für bereits definierte unternehmensexterne Benutzergruppen151 zur
Verfügung gestellt wird.
Für den unternehmensinternen Einsatz lassen sich die Internet-Anwendungen in Systeme für
Benutzerdienste und Systeme für Netzwerkdienste unterscheiden.152 Benutzerdienste umfassen
Funktionalitäten der Informationsbeschaffung und -bereitstellung sowie zur Kommunika-
tion153 innerhalb des Unternehmens. Netzwerkdienste werden benötigt, um die Netzinfrastruk-
tur und die ihr angeschlossenen Komponenten zu einem einheitlichen Informations- und
Kommunikationssystem zu realisieren.
Für den unternehmensübergreifenden Einsatz lassen sich die Internet-Anwendungen nach dem
Umfang der Interaktionen zur Geschäftsabwicklung (Grad der Interaktivität), Anzahl der
Schritte eines Geschäftsprozesses, die über das Internet abgewickelt werden (Intensität der
Internet-Nutzung) und den Automatisierungsgrad der Prozessschritte klassifizieren.154
150. Unter dem Begriff „Internet-Technologie“ wird hier die gesamte standardisierte Technologie, auf derdas Internet basiert, verstanden (vgl. [Itte99], S. 7). Darunter fallen das Netzwerkprotokoll TCP/IP, dieMetasprachen SGML und XML sowie die Dokumentensprache HTML.151. Z.B. Lieferanten und/oder Kunden.152. Vgl. [Itte99], S. 14.153. Hier wird zwischen asynchroner und synchroner Kommunikation unterschieden. Asynchrone Kom-munikation findet beispielsweise durch E-Mail statt. Synchrone Kommunikation findet beispielsweisedurch Audio- oder Videokonferenzen statt. 154. Vgl. [Kurb97], S. 25.
Kapitel 3: Stand der Technik 71
Auf der Basis dieser drei Kriterien lassen sich sechs Anwendungskategorien (vgl. Abbildung
22155) herleiten.
Bei der ersten und einfachsten Kategorie werden Informationen über das Internet bereitge-
stellt. Ein Informationsrückfluss über das Internet ist dabei nicht vorgesehen, stattdessen wird
auf konventionelle Kommunikationsmedien156 verwiesen. Die zweite Kategorie stellt eine
Ergänzung der ersten Kategorie um die Möglichkeiten zur direkten Kontaktaufnahme dar, wie
z.B. über das Mail-System.
Bei der dritten Kategorie wird zwischen manueller und automatischer Veranlassung eines Vor-
ganges unterschieden. Bei manueller Veranlassung wird aufgrund der eingegangenen Informa-
tionen ein entsprechender Prozess von einer Person initiiert. Dagegen findet bei einer
automatischen Veranlassung die Verarbeitung direkt durch ein Informationssystem statt. Die
vierte Kategorie bilden Anwendungen zur interaktiven Vorgangsabwicklung. Dazu werden
Teile eines Geschäftsprozesses über das Internet abgewickelt, wobei die Kommunikation in
beide Richtungen erfolgt. Die fünfte Kategorie unterscheidet sich von ihren direkten Vorgän-
gern durch die breitere fachliche Abwicklung von Vorgängen (Geschäftsprozess). Bei der letz-
ten Kategorie stellen die Zusammenarbeit und der Informationsaustausch über das Internet
155. Vgl. [Kurb97], S. 26. 156. Z.B. Telefon, Telefax, etc.
Informationsko-operation
Informationsbe-reitstellung mit Kontaktangebot
Informationsbe-reitstellung
Anstoßen eines Vorgangs
Interaktive Vor-gangsabwicklung
Geschäftsprozess-Integration
Inte
rakt
ivitä
t
Reichweite
niedrig hoch
Automatisierungsgrad
Abbildung 22: Typologie der zwischenbetrieblichen Internet-Nutzungsformen
72 Kapitel 3: Stand der Technik
einen erheblichen Teil der elementaren Geschäftsprozesse dar. Dabei können alle zur Verfü-
gung stehenden Internet-Dienste verwendet werden.
Für die Aufbereitung von Dokumenten lässt sich die Metasprache Standard Generalized Mar-
kup Language (SGML)157 einsetzen. Grundprinzip von SGML ist die Beschreibung bestimm-
ter Dokument-Elemente mit Hilfe von Markups. Als Markups werden in das Dokument
eingebettete, den Inhalt beschreibende Symbole verstanden, die interpretiert werden müssen.
SGML besteht aus einer großen Menge von komplexen Syntax-Vorschriften, die einem breite-
ren Einsatz der reinen SGML bisher im Wege standen.
Eine Anwendung von SGML stellt die Hypertext Markup Language (HTML) dar, die sich als
Standardsprache für das World Wide Web (WWW) etabliert hat.158 Allerdings gehen bei der
Anbindung dieser Systeme mit HTML aufgrund der beschränkten Darstellungsmöglichkeiten
von HTML zu viel Strukturinformation verloren.
Mit der zunehmenden Abwicklung von Geschäftstransaktionen159 über das Internet besteht ein
großer Bedarf an netzwerkfähigen und anwendungsneutralen Austauschformaten, der mit
HTML nicht erfüllt werden kann. Daher wurde die Extensible Markup Language (XML) ent-
wickelt. XML160 stellt eine Teilmenge von SGML dar, in der die komplexen und selten ver-
wendeten SGML-Eigenschaften entfernt wurden und gleichzeitig die SGML-Kernidee des
„strukturierten Markup“ übernommen wurde. XML-Dokumente bauen sich aus Elementen
(Tags) auf, die den Inhalt, die Struktur und die Formatierung (Layouts) eines Dokuments defi-
nieren. Dabei unterscheiden sich die XML-Dokumente auf den ersten Blick nicht wesentlich
von HTML-Dokumenten. Während die Tags für die HTML-Dokumente vorgegeben sind, kön-
nen für XML-Dokumente beliebig viele und frei benannte Tags definiert werden. Die Bedeu-
tung des Inhaltes der Tags in einem XML-Dokument ergibt sich aus der semantischen
Auszeichnung. Die Verschachtelung der Tags gibt die Struktur der Daten wieder. Die Darstel-
lung eines XML-Dokumentes erfolgt wegen der beliebigen Menge an Tags mit Hilfe einer
Formatvorlage (Style Sheet), die mit der eigenen Sprache XSL161 definiert wird.
157. ISO 8879 Norm.158. In der Praxis dient das WWW für eine Vielzahl von Informationssystemen als Oberfläche. Beispielesind Datenbanken mit HTML-Frontend, Mail-Archive, Warenkataloge, etc. 159. Business-To-Business, Business-To-Consumer.160. Eine ausführlichere Beschreibung von XML ist in [W3C00] zu finden.161. Extensible Style Sheet Language.
Kapitel 3: Stand der Technik 73
Für die Definition von XML-Dokumenten ist eine formale Grammatik (DTD162) zuständig.
Die DTD legt die verwendbaren Tags und deren Verschachtelung in einem zugehörigen XML-
Dokument fest. Dadurch können Anwendungen XML-Dokumente auf ihre strukturelle Integri-
tät überprüfen.
Durch die Verwendung von XML kann der Austausch von Informationen zwischen verschie-
denen Anwendungen stark vereinfacht werden. Die Struktur, die zum Verständnis und zur
Verarbeitung der Daten notwendig ist, muss nicht mehr starr in den Applikationen fest inte-
griert werden. Vielmehr wird die Struktur als Teil im Dokument beschrieben. XML bietet
keine standardmäßige Operabilität, sondern ist ein Werkzeugkasten für die Gestaltung intero-
perabler Lösungen. Da mit den DTDs ein Standardformat vorgegeben werden kann, um Infor-
mationen mit bestimmten Attributen zu verbinden, können verschiedene Systeme gemeinsame
DTDs verwenden, um Informationen auszutauschen, unabhängig vom eigenen, internen For-
mat der jeweiligen Systeme. Durch die Integration der für XML notwendigen Tools in den
gängigen Internet-Browsern kann ein breiter Anwenderkreis XML-Dokumente ohne spezielle
Software bearbeiten. Jeder Partner (Anwender) kann eigene Formate mit eigener Semantik in
XML definieren.
162. Document Type Definition.
Kapitel 4: Zu leistende Arbeit 75
4 Zu leistende Arbeit
Die Zielsetzung dieser Arbeit ist der Entwurf eines Ansatzes zur Gestaltung des operativen
Fertigungsmanagements innerhalb der Lieferkette und seine prototypische Umsetzung in ein
Fertigungsmanagement-Informationssystem. Dazu wurde in Kapitel 2.1.3 der Untersuchungs-
gegenstand der Arbeit in die drei Bereiche: Strukturierung der Fertigung, Gestaltung der Infor-
mationsflussbeziehungen und die informationstechnologische Unterstützung des
Fertigungsmanagements aufgeteilt. Auf Basis dieser Aufteilung wurden in Kapitel 2.2 Anfor-
derungen an eine Problemlösung zusammengestellt.
In Kapitel 3.1 wurden Arbeiten zur Strukturierung der Fertigung entlang der Lieferkette vorge-
stellt. Im Hinblick auf die Strukturierung der Fertigung erfüllt keine der dort beschriebenen
Arbeiten zur Klassifizierung der Erscheinungsformen der Fertigung die gestellten Anforderun-
gen. Zwar sind mit der Fraktalen Fabrik bzw. der Fertigungssegmentierung Restrukturie-
rungsansätze beschrieben worden, die mit der angestrebten Strukturierung der Fertigung in
mehreren Aspekten übereinstimmen, jedoch weisen beide Ansätze keine Vorgaben bezüglich
der in Kapitel 2.2.1 angeforderten Eigenschaften insbesondere in Bezug auf die Prozess- und
Informationsmodelle der Dispositionseinheiten auf.
Das Modell der Fertigung bietet aufgrund seiner generischen Konstrukte zur Beschreibung der
Fertigung und des Fertigungsablaufes eine Ausgangsbasis zur Erstellung der angestrebten
Strukturierung der Fertigung an. Hierzu sind jedoch entsprechende Ausprägungen und Ein-
schränkungen dieser Konstrukte festzulegen, um eine Beschreibung der Eigenschaften der
Dispositionseinheiten zu ermöglichen. Für die Darstellung der Fertigungs- und Logistikpro-
zesse bietet das SCOR-Modell eine einheitliche Basis zur lieferkettenübergreifenden Pro-
zessmodellierung an. Es verfügt jedoch, zumindest bislang, über keine Konstrukte zur
Dokumentation des Fertigungsablaufes.
In Bezug auf die Gestaltung der Informationsflüsse auf Basis der angestrebten Strukturierung
der Fertigung lassen sich anhand der in Kapitel 3.2 vorgestellten Ansätze vielfältige Merkmale
zur Beschreibung der Informationsflüsse ableiten. Die Vielfalt dieser Merkmale resultiert
einerseits aus dem Umfang des Untersuchungsgegenstandes und andererseits aus den unter-
schiedlichen Ausgangsbedingungen und Zielsetzungen, die den Ansätzen zu Grunde liegen. So
lassen sich einige Ansätze nur auf Teilbereiche der Lieferkette anwenden, oder sie stellen
lediglich ein Bündel von Maßnahmen zur Realisierung der überbetrieblichen Abstimmung dar.
76 Kapitel 4: Zu leistende Arbeit
Die Umsetzung dieser Ansätze bleibt, in Bezug auf die Gestaltung der Informationsflüsse, von
Fall zu Fall freigestellt. Hingegen weisen das Kanban und das Fortschrittzahlenkonzept Merk-
male auf, auf die bei der Gestaltung der Informationsflüsse zwischen den Dispositionseinhei-
ten zurückgegriffen werden kann. Hierzu gehören vor allem das mengenorientierte Aufzeigen
von kurzfristigen Änderungen beim Fortschrittzahlenkonzept und die mengenorientierte
Steuerung des Ablaufs mittels Kanban. Im Rahmen der Lösungsentwicklung sollen in Kapitel
5.2 die Merkmale der Beziehungen zwischen den Dispositionseinheiten untersucht werden.
Dabei soll die individuelle Gestaltung der Informationsflussbeziehungen im Vordergrund ste-
hen. Dazu soll einerseits aufgezeigt werden, welche grundlegenden Interdependenzen für die
Gestaltung der Informationsflüsse relevant sind und andererseits, wie die Informationsflüsse
individuell realisiert werden können.
In Bezug auf die Entwicklung und prototypische Umsetzung des Fertigungsmanagement-
Informationssystems gilt es zu überprüfen, inwieweit bzw. welche der in Kapitel 3.3.1 vorge-
stellten Arbeiten einerseits für die Integration der dezentralen Einheiten des Fertigungsmana-
gement-Informationssystems eingesetzt werden können und andererseits, welche zur
Erstellung von Schnittstellen zu den ERP/PPS-Systemen verwendet werden können. Dazu soll
in Kapitel 5.3 entschieden werden, welche Standards verwendet werden sollen. In Abbildung
23 zeigt der schraffierte Bereich, aufgrund der in Kapitel 2.2.3 gestellten Anforderungen, die
Kapitel 4: Zu leistende Arbeit 77
vom Fertigungsmanagement-Informationssystem (FMI-System) abzudeckenden Funktionali-
täten im Vergleich zum Funktionsumfang eines SCM-Systems1 auf.
Dazu sollen in Kapitel 5.3 Komponenten zur Modellierung der fertigungsrelevanten Struktu-
ren der Lieferkette, zum Management der Fertigung innerhalb einer Dispositionseinheit und
zur Realisierung der Informationsflüsse zwischen direkt benachbarten Dispositionseinheiten
entworfen werden. Die prototypische Umsetzung der Komponenten des FMI-Systems soll am
Beispiel des Fertigungsprozesses eines Automobilzulieferers verdeutlicht werden.
1. Vgl. Kapitel 3.3.2.2.1.
Abbildung 23: Vom FMI-System abzudeckende SCM-Funktionalitäten
Schnittstellen
Strategische Planung
Produktionsplanung Distributionsplanung Absatzsplanung
TransportplanungBeschaffungsplanung
Produktionsfeinplanung & -steuerung Available to Promise (ATP)
Einkauf PPS/ MRP IILager-verwaltung
Auftrags-bearbeitung
Daten-austausch
ERP/PPS-System
SCM-System
Verbundplanung
Kapitel 5: Konzeption 79
5 Konzeption
Im Folgenden sollen die drei Teilaspekte des zu entwickelnden Ansatzes untersucht und kon-
zeptionelle Lösungen erarbeitet werden. Dazu wird zunächst in Kapitel 5.1 eine Strukturierung
der fertigungsrelevanten Organisationseinheiten (sog. Dispositionseinheiten) entlang der Lie-
ferkette vorgenommen. In Kapitel 5.2 werden die Merkmale der Interdependenzen zwischen
den Dispositionseinheiten und Aspekte des Managements dieser Interdependenzen betrachtet.
In Kapitel 5.3 wird dann die Architektur des Fertigungsmanagement-Informationssystems
(FMI-System) entwickelt, und die zugehörigen Komponenten werden konzipiert. Das FMI-
System soll es ermöglichen, die Dispositionseinheiten der Lieferkette und deren Beziehungen
abzubilden. Dabei wird am Beispiel der fertigungsrelevanten Lieferkette eines Automobilzu-
lieferers die Anwendung des Ansatzes und die prototypische Umsetzung des FMI-Systems
aufgezeigt.
5.1 Strukturierung der Fertigung entlang der Lieferkette
Ziel der hier angestrebten Strukturierung der Fertigung entlang der Lieferkette ist einerseits die
Spezifikation der Charakterisierungsmerkmale für die Beschreibung der Dispositionseinheiten
und andererseits, die Auswirkungen der Merkmalsausprägungen auf das Informationsaufkom-
men der Dispositionseinheiten zu untersuchen. Um diese Strukturierung zu erreichen, ist eine
Modellierungsmethode erforderlich, die es erlaubt, die Eigenschaften der Dispositionseinhei-
ten zu beschreiben. Als konzeptionelle Grundlage soll hier die Prozessmodellierungsmethode
MFERT1 zur Modellierung von Fertigungs- und Logistikprozessen verwendet werden.
5.1.1 Herleitung von Merkmalen der Dispositionseinheiten
Ausgangspunkt der Überlegungen ist die Betrachtung der Lieferkette als ein sich permanent
änderndes Netzwerk2 von Prozessen und Flüssen. Dabei bilden sog. Dispositionseinheiten die
Knoten des Netzwerkes und die Material- und Informationsflussbeziehungen in der Liefer-
kette3 die Kanten. Eine Dispositionseinheit stellt eine autonome prozessorientierte Organisati-
onseinheit dar, die gemäß Anforderung 1.1 einen oder mehrere reale Fertigungs- und
1. Modell des Fertigungsgeschehens (vgl. Kapitel 3.1.2, [DaWa97], [DaWi97] und [Schne96])2. Auch als Fertigungsgraphen bezeichnet. Die Untersuchungen beziehen sich in Bezug auf den Materi-alfluss auf azyklische Graphen.3. Vgl. Definition 1.
80 Kapitel 5: Konzeption
Logistikprozesse abstrahiert. Dazu werden die Dispositionseinheiten im Folgenden als Teil-
graphen4 in der MFERT-Notation betrachtet. Aufgrund der Ausrichtung auf die abzubildenden
Fertigungs- und Logistikprozesse stellt die Zusammensetzung der Prozesse innerhalb einer
Dispositionseinheit ein wesentliches Merkmal dar. Dieses Merkmal soll im Verlauf dieser
Arbeit als Prozessstruktur näher betrachtet werden. Als zweites Charakterisierungsmerkmal
lassen sich, auf der Basis der Prozessstruktur und im Sinne der Anforderung 1.2, die Beziehun-
gen zwischen den zu betrachtenden Prozessen sowie die auszutauschenden Informationen und
deren zeitliche Reihenfolge identifizieren. Dieses Merkmal wird als Ablaufrichtung bezeich-
net. Aufbauend auf der Prozessstruktur und der Ablaufrichtung soll im Sinne der Anforderung
1.3 der Umfang der verfügbaren fertigungrelevanten Informationen beschrieben werden kön-
nen. Des Weiteren soll hier mittels der Konstrukte von MFERT die notwendige Struktur spezi-
fiziert werden können. Eine solche Beschreibung soll unter dem Merkmal
Informationsstruktur zusammengefasst betrachtet werden.
5.1.2 Prozessstruktur
Bezüglich der Prozessstruktur lassen sich die Fertigungs- und Logistikprozesse in der Liefer-
kette grundsätzlich in die elementaren Grundprozesstypen Bearbeiten5, Transportieren,
Lagern bzw. Puffern einteilen.6 Wesentliches Unterscheidungskriterium hierbei sind die an
den Input-Faktoren durchgeführten Transformationen gegenüber den Output-Faktoren bezüg-
lich Zustand7, Ort und Zeit. Eine reine Zeittransformation ohne Änderung des Ortes und des
Zustandes stellt einen Pufferprozess8 dar. Ein solcher Prozess wird im Rahmen dieser Arbeit
durch den in Abbildung 24a) dargestellten Fertigungselement-Knoten modelliert. Dabei lassen
sich die für den Pufferprozess einzusetzenden Ressourcen durch Fertigungselemente9 abbil-
4. Ein Teilgraph entsteht durch die Einschränkung des Fertigungsgraphen auf eine Teilmenge seiner Kno-ten und der sie verbindenden Kanten. Für diese Teilmenge muss weiterhin gelten, dass sie mindestens auseinem Knoten besteht, der eine bestimmte Funktionalität besitzt (vgl. [Schne96] und [Schmi00]).5. In der Literatur gibt es Arbeiten, die eine detailliertere Unterteilung verfolgen. Insbesondere wird häu-fig zwischen Fertigen, Montieren und Prüfen unterschieden, die hier als Bearbeiten betrachtet werden, dasie eine Zustandsänderung bewirken (vgl. u.a. [Wien87]). 6. Vgl. [Nest74], VDI-Richtlinie 2411. 7. Eine Zustandsänderung umfasst auch Änderungen der Zusammensetzung, Quantität oder Qualität. 8. Ein Puffer bzw. ein Lager ist ein Mittel zur Stabilisierung des Materialflusses zwischen zwei (Ferti-gungs-)Systemen, bei denen der Ausstoß des ersten Systems zeitlich nicht an den Bedarf des zweiten an-gepasst ist (vgl. [Dang98b]). Entlang der Lieferkette kann zwischen Beschaffungs-, Zwischen-,Fertigwaren- und Absatz- bzw. Auslieferungslager unterschieden werden.9. Vgl. Kapitel 3.1.2.
Kapitel 5: Konzeption 81
den.10 Eine Ortstransformation ohne Zustandsveränderung charakterisiert einen Transportpro-
zess. Zur Modellierung der Transportprozesse werden in [Kuhn99] unterschiedliche
Strukturmerkmale untersucht. Dabei wird grundsätzlich zwischen unidirektionalen und bidi-
rektionalen sowie offenen und geschlossenen Transportprozessen unterschieden. Ein unidirek-
tionaler Transportprozess verbindet einem Startort A zu einem Zielort B in einer Richtung. Ein
bidirektionaler Transportprozess entsteht durch zwei unidirektionale Transportprozesse, wobei
der Startort des einen den Zielort des anderen darstellt. Ein geschlossener Transportprozess
entsteht durch einen Zyklus von mehr als zwei unidirektionalen Transportprozessen.
Ein Transportprozess in der Lieferkette soll im Rahmen dieser Arbeit über zwei Wege model-
liert werden können. Implizit soll ein Transportvorgang über die Transportdauer11 in der
Beziehung zwischen zwei Knoten abgebildet werden können. Eine weitere Möglichkeit stellt
die explizite Modellierung des Transportprozesses als Teilgraph dar.12 Für diesen zweiten Fall
wird der in Abbildung 24 b) dargestellte Teilgraph eingesetzt. Dabei verwaltet der Fertigungs-
vorgangs-Knoten die zur Modellierung der Transportvorgänge notwendigen Fertigungsvor-
gangs-Kategorien und der Fertigungselement-Knoten die entsprechenden Fertigungselement-
Kategorien für die notwendigen Ressourcen.13 Die für einen Transportprozess einzusetzenden
Ressourcen werden über Fertigungselemente abgebildet.
Findet durch die Transformation eine Zustandsänderung statt, so wird im Folgenden von
einem Fertigungsprozess (Bearbeiten) gesprochen. In Abhängigkeit von der Beziehung der
Input-Faktorarten zu den Output-Faktorarten kann grundsätzlich zwischen „durchlaufenden“,
„analytischen“, „umgruppierenden“ und „synthetischen“ Zustandstransformationen unter-
10. Vgl. Kapitel 5.1.4.1.2 zur Beschreibung der Ressourcenstruktur.11. Die Transportdauer kann explizit angegeben oder über eine Formel berechnet werden.12. Dabei wird im Rahmen der Arbeit zugrunde gelegt, dass die Ortsdimension nicht explizit mit demTransportprozess modelliert werden muss.13. Mit Ressource sind hier allgemein Betriebsmittel gemeint.
Abbildung 24: Modellierung der Fertigungs- und Logistikprozesse
a) Puffer b) Fertigungs- bzw. Transportprozess
82 Kapitel 5: Konzeption
schieden werden.14 In einer „durchlaufenden“ Zustandstransformation wird nur eine Input-
Faktorart in eine Output-Faktorart transformiert. Bei „analytischen“ Zustandstransformatio-
nen15 wird eine Input-Faktorart in mehrere Output-Faktorarten aufgespalten. Bei einer
„umgruppierenden“16 Zustandstransformation werden mehrere Input-Faktorarten in mehrere
Output-Faktorarten umgewandelt. Eine „synthetische“17 Zustandstranformation ist dadurch
gekennzeichnet, dass mehrere Input-Faktorarten in eine Output-Faktorart zusammengefasst
werden. Im Folgenden werden die o.a. Typen der Zustandstranformationen als Fertigungspro-
zesse bezeichnet. Für die Darstellung eines Fertigungsprozesses wird im Rahmen dieser Arbeit
analog zur Ortstransformation der Teilgraph in Abbildung 24 b) verwendet.
Die hier definierten drei elementaren Prozesstypen bilden die Basis für die Gestaltung der Dis-
positionseinheiten. Dabei wird zunächst davon ausgegangen, dass sich die Lieferkette in Form
eines gerichteten zyklenfreien Graphen zusammensetzen lässt, dessen Knoten aus den drei
Prozesstypen bestehen. Dazu werden allerdings folgende Restriktionen des Modells der Ferti-
gung verwendet, die es ermöglichen sollen, die Modellierung auf die für die Bildung der Dis-
positionseinheiten wesentlichen Prozesse einzuschränken.18
• Restriktion 1: Reduktion sequentieller Prozesse
Zwei Fertigungs- bzw. Transportprozesse, die direkt über einen Pufferprozess verbundensind, werden, falls keine Lenkungsnotwendigkeit19 besteht, zu einem Fertigungs- bzw.Transportprozess reduziert.
• Restriktion 2: Reduktion paralleler Prozesse
Innerbetrieblich parallel liegende20 Prozesse des gleichen Typs werden auf einen neuenProzess vom gleichen Typ reduziert.
14. Vgl. [Kuhn99], S. 113.15. Beispiele hierfür finden sich in der chemischen Industrie oder aber in der metallverarbeitenden Indu-strie, wo die gleichzeitige Herstellung von mehreren Endprodukten in einem Prozess, wie z.B. beim Stan-zen eines Bleches, erfolgt (vgl. [Kuhn99], S. 88).16. Die hier eingesetzten Verfahren sind überwiegend chemischer Natur.17. Klassische Beispiele hierfür sind die Möbel- und Automobilindustrie, sowie der Maschinenbau.18. Vgl. [DaWi97], S. 85ff.19. Lenkungsnotwendigkeit besteht genau dann, wenn über die Reihenfolge der Zugänge bzw. Abgängeentschieden werden muss.20. Zwei Prozesse sind dann „parallel liegend“, wenn sie auf der gleichen Wertschöpfungsstufe existierenund dieselben Vorgänger- und/oder Nachfolgerknoten haben.
Kapitel 5: Konzeption 83
Aufbauend auf der nach diesen Restriktionen generierten Lieferkette lassen sich die Prozess-
strukturen der Dispositionseinheiten erstellen. Dabei wird die Lieferkette in disjunkte Teilgra-
phen partitioniert, die die organisatorische Dimension der Dispositionseinheiten bilden und
somit die sog. Entscheidungsweite21 des Disponenten festlegen.
Für die Identifikation der Teilgraphen zur Bildung der Dispositionseinheiten sind die Anforde-
rungen 1.1 und 1.2 heranzuziehen. Insbesondere lässt sich über die Bestimmung des planungs-
mäßig dominanteren Prozesses und über den Umfang eines einer Dispositionseinheit
zugeordneten Prozesses, die Prozessstruktur festlegen. Kernpunkt dabei ist die Bestimmung
der Prozesse in der Lieferkette, die die größeren Engpässe darstellen. Dadurch wird die Menge
der als „planungsmäßig dominanteren“ Prozesse gebildet. Von diesen Prozessen ausgehend
werden die benachbarten Prozesse betrachtet und ggf. einem planungsmäßig dominanteren
Prozess zugeordnet. Bei dieser Zuordnung wird berücksichtigt, dass einerseits keine Len-
kungsnotwendigkeit zwischen den zugeordneten Prozessen besteht und andererseits die Kom-
plexität der Prozessstruktur möglichst einfach gehalten wird, um die Transparenz des
Geschehens zu gewährleisten. Grafisch werden die planungsmäßig dominanteren Prozesse mit
einem „P“ im Fertigungselement-Knoten für Puffer bzw. im Fertigungsvorgangs-Knoten für
Fertigungs- bzw. Transportprozesse22 gekennzeichnet (vgl. Abbildung 25).
21. Vgl. Anforderung 1.1.22. Im weiteren Verlauf werden diese Prozesse, wenn keine explizite Unterscheidung erforderlich ist, alsFertigungsprozesse bezeichnet.
84 Kapitel 5: Konzeption
In Abbildung 25 sind die unterschiedlichen Ausprägungen der Prozessstruktur zusammenge-
fasst. Neben den elementaren Dispositionseinheiten mit einem Prozess bestehen Prozessstruk-
turen mit zwei Prozessen aus einem Fertigungsprozess mit einem vor- bzw. nachgelagerten
Pufferprozess. In solchen Fällen kann die Planung der Dispositionseinheit entweder von dem
Fertigungsprozess bzw. dem Pufferprozess dominiert werden. Mögliche Dispositionseinheiten
mit einer Prozessstruktur aus drei Prozessen sind durch die Typen 7 und 8 in Abbildung 25
dargestellt. Dabei wird dem „mittleren“ Prozess stets die planungsmäßige Dominanz zugeord-
net, um die Auswirkungen der Planung auf die beiden „äußeren“ Prozesse berücksichtigen zu
können (vgl. Anforderung 1.2). Dispositionseinheiten mit mehr als drei aufeinanderfolgenden
Prozessen sind nicht sinnvoll, da einerseits die Auswirkungen der Planung des dominanteren
Prozesses nur die unmittelbar „benachbarten“ Prozesse betreffen würden und dadurch ein oder
mehr Prozesse aus der Entscheidungsweite des Disponenten wegfallen würden (vgl. Anforde-
rung 1.2) und andererseits die Komplexität der Planungsabläufe gesteigert werden würde. Die
Entscheidungsweite lässt sich durch die Belegungsplanung des dominanteren Prozesses und
dessen Auswirkungen auf die untergeordneten Prozesse beschreiben. Die in Abbildung 25 dar-
Abbildung 25: Prozessstrukturen der Dispositionseinheiten
Mit einem Prozess
Mit drei Prozessen
Ausprägungen der Prozessstruktur
Mit zweiProzessen
Typ 1 Typ 2
Typ 3 Typ 4
Typ 7
Typ 8
Typ 6Typ 5
PP
P
P
P
P
P
P
Kapitel 5: Konzeption 85
gestellten Teilgraphen bilden den Grundstein für die hier angestrebte Strukturierung der ferti-
gungsrelevanten Lieferkette. Sie legen, unter Berücksichtigung weiterer
Merkmalsausprägungen, die für einen bestimmten Dispositionsbereich der Lieferkette abzubil-
denden Struktur fest. Darüber hinaus impliziert die Prozessstruktur die möglichen Sichten auf
das Fertigungsgeschehen in der Dispositionseinheit und somit die zur Entscheidungsunterstüt-
zung bereitzustellenden Daten. Im Rahmen der prototypischen Implementierung des FMI-
Systems, in Kapitel 5.3, sollen die Teilgraphen den Ausgangspunkt für die Spezifikation des
Lieferkettenmodells darstellen.23
5.1.3 Ablaufrichtung
Zur Beschreibung der Ablaufrichtung in einer Dispositionseinheit lassen sich die in Abbildung
2624 skizzierten Informationsflüsse unterscheiden. Dabei verhalten sich die Informationsflüsse
in Abhängigkeit vom Bezug zur Materialflussrichtung spiegelbildlich. Bei einer Betrachtung
in Materialflussrichtung stellen die Informationsflüsse Angebote und bei einer entgegengesetz-
ten Betrachtung die Bedarfe dar. Weiterhin werden aus den Bruttogrößen durch den Abgleich
mit den Beständen und den Restriktionen an den Dreiecken die Nettogrößen berechnet.
Es können zwei grundsätzliche Strategien zur Ablaufrichtung differenziert werden. Bei der
Rückwärtsstrategie wird der Planungsablauf ausgehend von den Nachfragen der Kunden25
angestoßen. Anschließend werden die Bedarfe rückwärts bis zum planenden Prozess weiterge-
reicht.26 Auf der Basis der Planungsergebnisse (Ressourcenbelegung) werden dann einerseits
23. Vgl. Kapitel 5.3.324. Der Materialfluss ist von links nach rechts.25. die unmittelbar nachgelagerten Dispositionseinheiten (vgl. Kapitel 5.2).
Net
toB
rutt
o
AngebotBedarf
Abbildung 26: Brutto-/Netto-Bedarf/Angebot Informationsflüsse
86 Kapitel 5: Konzeption
die Bedarfe als Vorgaben für den vorgelagertern Prozess bzw. für die vorgelagerten Dispositi-
onseinheiten berechnet und andererseits die Angebote für den nachgelagerten Prozess bzw. die
nachgelagerten Dispositionseinheiten generiert. Dieser Sachverhalt wird am Beispiel einer
Dispositionseinheit vom Typ 5 und einem planungsmäßig dominanteren Fertigungsprozess in
Abbildung 27 a) skizziert. Bei der Rückwärtsstrategie werden die vorgegebenen Liefertermine
als ein Ziel der Planung betrachtet. Dabei werden ausgehend von diesen Lieferterminen die
spätestmöglichen Starttermine der Arbeitsgänge27 bestimmt.28
Bei der Vorwärtsstrategie erfolgt der Anstoß des Planungsablaufes auf Basis der Angebote der
Lieferanten.29 Anschließend werden die Angebote vorwärts bis zum planenden Prozess wei-
tergereicht.30 Die Planungsergebnisse stellen sich dann zum einen als Angebote für den nach-
gelagerten Prozess bzw. für die nachgelagerten Dispositionseinheiten und zum anderen als
Bedarfe für den vorgelagerten Prozess bzw. die vorgelagerten Dispositionseinheiten dar.
Abbildung 27 b) stellt die Vorwärtsstrategie am Beispiel einer Dispositionseinheit vom Typ 4
mit einem planungsmäßig dominanteren Fertigungsprozess dar. Bei der Vorwärtsstrategie
werden ausgehend vom vorgegebenen Verfügbarkeitstermin der Angebote die frühestmögli-
chen Anfangs- und Endtermine der Arbeitsgänge ermittelt.
Die beiden Strategien lassen sich kombinieren und in der gleichen Dispositionseinheit anwen-
den. Dabei bilden sowohl die Angebote der Lieferanten als auch die Bedarfe der Kunden die
Ausgangsbasis für den Planungsablauf. Die Auswirkungen der Planungsergebnisse setzen sich
dann rückwärts als Bedarfe an die Lieferanten und vorwärts als Angebote an den Kunden fort.
26. Das Weiterreichen kann in Abhängigkeit von dem durchzulaufenden Prozesstyp durch eine Brutto-Netto-Berechnung (Pufferprozess), durch eine Verschiebung um die Prozessdauer (Transportprozess)oder durch eine Stücklistenauflösung unter Berücksichtigung der Vorlaufzeiten (Fertigungsprozess) er-folgen. 27. Ein Arbeitsgang bezeichnet eine geordnete Menge von Tätigkeiten, die einem Aufgabenträger zuge-ordnet ist (vgl. [HeRo98]).28. Rückwärtsterminierung.29. die unmittelbar vorgelagerten Dispositionseinheiten.30. Hier findet das Weiterreichen durch die Umkehrung der in Fußnote 26., S. 86 angegebenen Berech-nungen statt.
Kapitel 5: Konzeption 87
Am Beispiel einer Dispositionseinheit vom Typ 8 mit einem planungsmäßig dominanteren
Fertigungsprozess wird in Abbildung 27 c) die kombinierte Strategie verdeutlicht.
Die mögliche Zuordnung einer Ablaufrichtung zu einer Prozessstruktur in einer Dispositions-
einheit wird durch den planungsmäßig dominanteren Prozesstyp mitbestimmt. Aufgrund der
Synchronisationsfunktion von Pufferprozessen in der Lieferkette steht die Reihenfolge der Zu-
bzw. Abgänge im Mittelpunkt der Planung.31 Daher ist eine kombinierte Strategie bei einer
Dispositionseinheit mit einem dominanteren Pufferprozess vorzuziehen. Bei den Fertigungs-
bzw. Transportprozessen kann in Abhängigkeit von der verfolgten Zielsetzung einer der drei
Strategien in Abbildung 27 angewendet werden.
5.1.4 Informationsstruktur
Bezüglich der Informationsstruktur stellen die zugrunde liegende Prozessstruktur und Ablauf-
richtung die Ausgangsbasis zur Gestaltung dar. So soll die Informationsstruktur festlegen, an
welchen Positionen der Prozessstruktur der Fortschritt des Fertigungsablaufs gemessen werden
kann. Dazu lassen sich besonders die Übergänge zwischen den Prozessen als mögliche Mess-
punkte identifizieren. Insbesondere können an den Schnittstellen zum planungsmäßig domi-
31. Es wird in Abhängigkeit von Aufgabe und Zielsetzung zwischen Belegungs- und Bewegungsstrategi-en unterschieden. Belegungsstrategien ermitteln, auf welchen Plätzen und in welchen Pufferzonen welche(Zwischen-)Erzeugnisse gepuffert und bereitgestellt werden müssen, um eine möglichst gute Platznut-zung und kurze Wege für die Zu- und Abgänge zu erreichen. Bewegungsstrategien legen fest, in welcherReihenfolge welche Zu- und Abgänge von den Ressourcen (z.B. Fördersysteme) durchgeführt werden,damit unter Einhaltung vorgegebener Restriktionen (z.B. FIFO, LIFO) eine möglichst hohe Einlager-,Auslager- oder Durchsatzleistung erreicht wird (vgl. [Gud00b], S. 48ff).
1234
542 3
5
1
4
4
2 35
1
4 4
12
5
1: Bruttoangebote2: Nettoangebote3: Planungsprozess4: Bruttobedarfe/-angebote5: Nettobedarfe
1: Bruttobedarfe2: Nettobedarfe3: Planungsprozess4: Bruttoangebote/-bedarfe5: Nettoangebote
1: Bruttobedarfe/-angebote2: Nettobedarfe/-angebote3: Planungsprozess4: Bruttoangebote/-bedarfe5: Nettoangebote/-bedarfe
c)Kombinierte Strategie
a)Rückwärtsstrategie b)Vorwärtsstrategie
Abbildung 27: Beispiele der Ablaufrichtung
PP
P
88 Kapitel 5: Konzeption
nanteren Prozess die Qualität der Planungsergebnisse bewertet und die Auswirkungen auf die
untergeordneten Prozesse aufgezeigt werden.
Weiterhin sind in Abhängigkeit von der verfolgten Strategie zur Ablaufrichtung bestimmte
Messpunkte zur Bewertung der Abläufe von besonderer Bedeutung. Bei einer Rückwärtsstra-
tegie sollten die Messpunkte so eingerichtet werden, dass ein Vergleich der Bruttobedarfe mit
den Nettoangeboten ermöglicht wird. Dadurch lassen sich mögliche Lieferengpässe bzw.
Überkapazitäten aufzeigen. Ähnlich sollte bei einer Vorwärtsstrategie ein Vergleich der Brut-
toangebote mit den Nettobedarfen ermöglicht werden können. In den folgenden Abschnitten
werden die Elemente zur Modellierung der Informationsstruktur einer Dispositionseinheit
betrachtet. Dazu sollen hier zunächst Konstrukte zur Abbildung der statischen Aspekte der
Fertigungs- und Logistikprozesse hergeleitet werden (vgl. Kapitel 5.1.4.1). Anschließend wer-
den in Kapitel 5.1.4.2 die Konstrukte des Ablaufs (dynamische Aspekte) behandelt.
5.1.4.1 Statische Aspekte
Gegenstand der Untersuchung der statischen Aspekte bilden die Erzeugnis- und Ressourcen-
strukturen und deren Beziehungen. Entsprechend dieser Aufteilung werden die genannten
Aspekte in den folgenden Unterkapiteln betrachtet.
5.1.4.1.1 Erzeugnisstruktur
Die Erzeugnisstruktur soll die Beziehungen zwischen den Input-Faktorarten und den Output-
Faktorarten in einer Dispositionseinheit beschreiben.32 Dabei bieten sich grundsätzlich zwei
Möglichkeiten an. Die erste Möglichkeit besteht darin, die Erzeugnisstruktur ausgehend von
den Input-Faktorarten zu beschreiben. Dazu werden für eine Input-Faktorart die möglichen
Output-Faktorarten mit Mengenzusammenhang angegeben, in denen die Input-Faktorart Ver-
wendung findet.33 Eine solche Beschreibungsmöglichkeit eignet sich besonders für Dispositi-
onseinheiten mit einer Vorwärtsstrategie34, um ausgehend von den Angeboten an Input-
Faktoren die korrespondierenden Bedarfe zu ermitteln.35 Die zweite und verbreitetste Mög-
lichkeit besteht darin, die Erzeugnisstruktur ausgehend von den Output-Faktorarten zu
32. Laut Anforderung 1.3 soll eine Dispositionseinheit bzgl. der Erzeugnisstruktur eine Art Blackbox dar-stellen. 33. Teileverwendungsnachweis.34. Vgl. Kapitel 5.1.3.35. Die Vorwärtsstrategie kann bei „umgruppierenden“ bzw. „synthetischen“ Zustandstransformationennur eingesetzt werden, wenn jede Input-Faktorart eindeutig einer Output-Faktorart zugeordnet werdenkann.
Kapitel 5: Konzeption 89
beschreiben.36 Dabei werden einer Output-Faktorart die Input-Faktorarten, aus denen sie sich
zusammensetzt, und deren Mengenverhältnisse zugeordnet. Auf der Basis einer solchen
Erzeugnisstruktur werden mit Hilfe der Stücklistenauflösung die Bedarfe37 an Input-Faktoren
ermittelt.
Die Gestaltung der Erzeugnisstrukturen in den elementaren Dispositionseinheiten38 hängt vom
Prozesstyp ab. Während bei einer Dispositionseinheit vom Typ 1 die Art der Zustandstransfor-
mation39 die Erzeugnisstruktur beeinflusst, sind die Mengen der Input- und Output-Faktorar-
ten bei den Dispositionseinheiten vom Typ 2 identisch. Für die Dispositionseinheiten mit zwei
oder drei Prozessen werden für die Beschreibung der Erzeugnisstruktur nur die Beziehungen
der Input-Faktorarten zu den Output-Faktorarten des planungsmäßig dominanteren Prozesses
in der Prozessstruktur betrachtet.40
Zur formalen Beschreibung der Erzeugnisstrukturen einer Dispositionseinheit werden die fol-
genden Konstrukte verwendet:
Sei e die Anzahl der verschiedenen Input-Faktorarten in einer Dispositionseinheit, dann ist mit
, mit und die Menge der Input-Faktorarten definiert.
Sei a die Anzahl der Output-Faktorarten in der Dispositionseinheit, dann ist mit
, mit die Menge der Output-Faktorarten definiert.
Sei , dann lassen sich mit bzw. die Zuordnungsbeziehungen zur Beschrei-
bung der Erzeugnisstruktur ausgehend von der Output-Faktorart bzw. von den Input-Faktorar-
ten wie folgt definieren:
gilt, es existiert ein .
gilt, es existiert ein .
Hierbei beschreibt die Alternativen bei der Verwendung der Input-Faktorart .
36. In der Literatur häufig als Stücklisten bezeichnet. Nach [ReDi91] sind Stücklisten Verzeichnisse in ta-bellarischer Form, die aufzeigen, wo und in welchen Mengen Rohmaterialien, Einzelteile und Baugrup-pen in das Enderzeugnis eingehen.37. Sekundärbedarfe.38. Vgl. Typ 1 und Typ 2 in Abbildung 25.39. Insbesondere durch die Anzahl der einer Output-Faktorart zuordbaren Input-Faktorarten und umge-kehrt (vgl. Kapitel 5.1.2).40. Vgl. Anforderung 1.3 bzgl. der Strukturtiefe der Erzeugnisstruktur.
E Ei 1 i e≤ ≤( ){ }= E e= e ℵ∈
A Aj 1 j a≤ ≤( ){ }= A a= a ℵ∈
B 0 1{ , }= fA fE
Aj∀ A∈ fA Aj( ) ℜ′ Be⋅∈
Ei∀ E∈ fE Ei( ) ℜ′ Ba⋅∈
fE E i( ) Ei
90 Kapitel 5: Konzeption
5.1.4.1.2 Ressourcenstruktur
Die Ressourcenstruktur soll die Merkmale und Beziehungen der Ressourcen in einer Dispositi-
onseinheit beschreiben.41 Da die Ressourcen des planungsmäßig dominanteren Prozesses den
Gegenstand der Disposition42 darstellen, ist die Ressourcenstruktur in Abhängigkeit vom Pro-
zesstyp zu betrachten. Daraus resultieren abhängig von der Transformationsart die drei
Betriebsmitteltypen Lagermittel („reine“ Zeittransformation), Transportmittel43 (Ortstransfor-
mation) und Fertigungsmittel44 (Zustandstransformation). Als wesentliche Aspekte der Res-
sourcenstruktur sollen hier die Anordung der Ressourcen und die Kapazitätsmerkmale der
Ressourcen betrachtet werden.
Bezüglich der Anordnung der Ressourcen bei einer Zustandstransformation wird grundsätzlich
zwischen einer verrichtungsorientierten45 und einer erzeugnisorientierten46 Strategie unter-
schieden.47 Im Rahmen dieser Arbeit wird einerseits eine an die Arbeitsgangfolge zur Erzeug-
niserstellung ausgerichtete Anordnung der Ressourcen in der Lieferkette zugrunde gelegt.
Andererseits wird, aufgrund der Prozessorientierung bei der Bildung der Dispositionseinhei-
ten, eine Ausrichtung der Ressourcen an die Prozessstruktur der Dispositionseinheiten vorge-
geben. Dazu stellt eine Ressource im Modell, analog zur Prozessstruktur, die
zusammengefasste Betrachtung mehrerer realer Ressourcen im Fertigungsprozess dar. Dabei
werden bei der Bildung der Dispositionseinheiten zwei Ressourcen, zwischen denen eine
direkte Materialflussbeziehung besteht, entweder zu einem Prozess zugeordnet, und damit als
eine Ressource im Modell abgebildet, oder sie werden zwei unterschiedlichen Dispositionsein-
heiten zugeteilt. Weiterhin sollen aufgrund der Einstufigkeit der betrachteten Erzeugnisstruk-
41. Im Modell werden die Ressourcenarten „Betriebsmittel“ und „Werker“ grundsätzlich gleich behan-delt. Eine differenzierte Betrachtung ist jedoch hinsichtlich der Beschreibung der Merkmale (z.B. Kapa-zität) notwendig. Im Folgenden sollen zunächst nur die Betriebsmittelressourcen betrachtet werden. 42. Vgl. Anforderung 1.2.43. Transportmittel werden in Fördermittel und Förderhilfsmittel unterschieden. Förderhilfsmittel sollendazu dienen, an das Transportgerät (Fördermittel) und das Fördergut angepasste Transporteinheiten zuschaffen, die schnell in einen Materialfluss eingefügt werden können [Dang98b]. Mit Transportmittelnsind im Rahmen dieser Arbeit die Fördermittel gemeint.44. Darunter sind Maschinen bzw. Linien zu verstehen. Im Verlauf der Arbeit wird Maschine als Sy-nonym verwendet.45. Bei dieser Strategie werden Maschinen mit gleichartigen Funktionen in einer fertigungstechnischenEinheit zusammengefasst (Werkstattfertigung).46. Hier erfolgt die Anordnung der Maschinen bei einer erzeugnisorientierten Strategie nach der zur Er-füllung eines Erzeugnisses erforderlichen Arbeitsgangfolge. 47. Eine weitere Möglichkeit zur Anordnung der Ressourcen stellt die flexible Zuordnung von ortsverän-derlichen Maschinen zu ortsfesten Erzeugnissen dar (Baustellenfertigung). Eine solcher Fall soll im wei-teren Verlauf dieser Arbeit nicht näher betrachtet werden.
Kapitel 5: Konzeption 91
tur in einer Dispositionseinheit keine Materialflussbeziehungen zwischen den Ressourcen des
planungsmäßig dominanteren Prozesses existieren können.
Neben der Anordnung der Ressourcen im Materialfluss kommt der Ressourcenkapazität bei
der Beschreibung der Ressourcenstruktur einer Dispositionseinheit eine wichtige Bedeutung
zu. Unter Kapazität wird das mengenmäßige Leistungsvermögen einer Betriebseinheit48 inner-
halb eines bestimmten Zeitintervalls verstanden.49 Dabei erfordert die Beschreibung des men-
genmäßigen Leistungsvermögens von Ressourcen sowohl die Berücksichtigung des
quantitativen (Mengenleisung) als auch des qualitativen (Art der Leistung) Kapazitätsaspek-
tes.50 Der qualitative Kapazitätsaspekt beschreibt die Fähigkeit einer Ressource.51 Die Men-
genleistung einer Ressource kann in Mengeneinheiten der zu erstellenden Output-Faktorart je
Zeiteinheit angegeben werden. Für die genaue Festlegung des Kapazitätsangebotes einer Res-
source ist eine Basiseinheit erforderlich, die die entsprechende Berechnung des von einer Ein-
heit einer Output-Faktorart beanspruchten Kapazitätsanteils erlaubt. In Abhängigkeit von der
Transformationsart der betrachteten Betriebsmittel in der Dispositionseinheit sollen als Basis-
einheiten Zeitspannen52 für jedes Betriebsmittel des Fertigungsprozesses und Flächen- bzw.
Volumeneinheiten53 für die Betriebsmittel des Puffer- bzw. Transportprozesses verwendet
werden. Dadurch lässt sich die Gesamtkapazität eines Betriebsmittels in Mengeneinheiten der
Basiseinheit angeben.
Formal sei mit und die Menge der zu betrachtenden Betriebs-
mittel in einer Dispositionseinheit definiert. Die Beschreibung der qualitativen und quantitati-
ven Kapazitäten der einzelnen Betriebsmittel erfolgt im nächsten Abschnitt.
5.1.4.1.3 Transformationsstruktur
Die Transformationsstruktur soll den Zusammenhang zwischen der Erzeugnis- und der Res-
sourcenstruktur einer Dispositionseinheit beschreiben. Dabei stehen insbesondere die qualitati-
ven und quantitativen Aspekte der Betriebsmittelkapazitäten in Bezug auf die Output-
Faktorarten im Vordergrund. Zur formalen Beschreibung der Kapazität wird der Kapazitäts-
48. Eine Betriebseinheit beschreibt die Zusammenfassung mehrerer Ressourcen.49. Vgl. [Kuhn99].50. Vgl. [Gabl98].51. Z.B. welche Output-Faktorarten auf einer Maschine gefertigt werden können.52. Z.B. Minute, Stunde, Schicht, etc. Hierbei erfolgt die Kapazitätsangabe für jede Maschine im betrach-teten Fertigungselement-Knoten. 53. Z.B. Quadrat- bzw. Kubikzentimeter zu einem Zeitpunkt.
M Mk 1 k m≤ ≤( ){ }= m ℵ∈
92 Kapitel 5: Konzeption
faktor definiert. Der Kapazitätsfaktor legt in einem Fertigungsprozess die Zeit fest, die
beim Verlassen des Betriebsmittels zwischen zwei aufeinanderfolgenden Einheiten der
Output-Faktorart verstreicht.54 Bei einem Puffer- bzw. Transportprozess legt er den für die
Lagerung bzw. Transport einer Einheit der Output-Faktorart erforderlichen Kapazitätsan-
teil55 fest.
gilt,
5.1.4.2 Dynamische Aspekte
In diesem Abschnitt sollen Konstrukte zur Beschreibung des Ablaufs in einer Dispositionsein-
heit entworfen werden. Um die Zustände56 und Ereignisse57 in einer Dispositionseinheit dar-
stellen zu können, ist es sinnvoll, zunächst ein geeignetes Zeitmodell zu definieren. Daher wird
im Kapitel 5.1.4.2.1 das dem Ablauf zugrunde liegende Zeitmodell konzipiert. Wie in Kapitel
5.1.1 festgestellt wurde, lässt sich jede Dispositionseinheit in Form eines Teilgraphen in der
MFERT-Notation abbilden. Damit kann der Ablauf in einer Dispositionseinheit durch die
Dokumentation der Ereignisse an den Knoten und Kanten des Teilgraphen beschrieben wer-
den. In Kapitel 5.1.4.2.2 findet die Betrachtung der Abläufe in einer Dispositionseinheit unter
Berücksichtigung der Struktur des MFERT-Graphen statt.
Die Zuordnung der Ressourcenkapazitäten zu den Bedarfen soll in Abhängigkeit von den spe-
zifischen Optimierungszielen der Dispositionseinheit erfolgen. Die hierzu erforderlichen Stra-
tegien sollen auf der Basis der Ausprägung der Dispositionseinheit individuell entwickelt
werden und sollen daher zunächst nicht näher betrachtet werden.58
54. In der Literatur häufig als Zyklus- bzw. Taktzeit beschrieben. 55. In der jeweiligen Basiseinheit.56. Ein Zustand ist ein in der Zeit andauerndes Phänomen und kann jeweils zu einem Zeitpunkt festge-stellt werden (vgl. [Schne96], S. 108).57. Ein Ereignis ist die Änderung eines Zustandes bezogen auf einen Zeitpunkt (vgl. [Schne96] und[Gunt85]).58. In Kapitel 5.3.4.2.2 wird ein Verfahren zur Belegungsplanung einer Dispositionseinheit des Automo-bilherstellers vorgestellt.
KFk j,
Mk
A j
A j
Mk∀ M∈ Aj∀ A∈,
Kapazitaetsfaktor Mk A j,( )KFk j, 0> falls Aj auf Mkverarbeitet werden kann,
0 sonst,
=
Kapitel 5: Konzeption 93
5.1.4.2.1 Zeitmodell
Um ein geeignetes Zeitmodell für die Beschreibung des fertigungsrelevanten Ablaufs in einer
Dispositionseinheit zu finden, sind zunächst die Ausprägungen der ontologischen59 Eigen-
schaften der Zeit zu berücksichtigen. Dabei handelt es sich, wie in Tabelle660 beschrieben, um
folgende Ausprägungen:
Die Semantik definiert die Ordnung auf den Ereignissen. Innerhalb einer „linearen“ Zeit han-
delt es sich bei der zeitlichen Reihenfolge der Ereignisse um eine totale Ordnung, während bei
der „verzweigten“ oder „total parallelen“ Zeit nur eine partielle Ordnung existiert und es somit
Ereignisse gibt, die zeitlich untereinander nicht vergleichbar sind. Die Ereignismenge kann
unbeschränkt oder ein- bzw. beidseitig beschränkt sein. Bei der Mächtigkeit der Ereignis-
menge kann zwischen einer „diskreten“ und einer „kontinuierlichen“ Zeit unterschieden wer-
den. Bei der kontinuierlichen Zeit verhält sich die Ereignismenge isomorph zu den reellen
Zahlen, während sie bei der diskreten Zeit isomorph zu den natürlichen oder rationalen Zahlen
sein kann. Ontologische Primitive der Zeit sind „Zeitpunkt“, „Intervall“ und „Zeitspanne“. Bei
einem Zeitpunkt handelt es sich um ein Element der Zeitmenge, z.B. „1.Februar 1999 um
18:30 Uhr“. Ein Intervall ist eine durch zwei unterschiedliche Zeitpunkte definierte Teilmenge
der Ereignismenge, auf der eine totale Ordnung der zeitlichen Reihenfolge existiert. Zeitspan-
nen beschreiben die Elemente einer Menge von Zeitintervallen, die ähnliche Eigenschaften
vorweisen. Eine Zeitspanne kann eine bestimmte (z.B. 1 Stunde) oder unbestimmte Länge
(z.B. 1 Monat) haben.
59. Laut [Wahr86] stellt die Ontologie „die Lehre vom Sein und seinen Prinzipien“ dar.60. Vgl. [JaZu95].
Semantik linear verzweigend parallel
Ereignismengebeidseitig beschränkt einseitig beschränkt unbeschränkt
Mächtigkeitdiskret mit fester Auflö-
sung
diskret mit beliebig
feiner Auflösungkontinuierlich
PrimitiveZeitpunkt Intervall Zeitspanne
Tabelle 6: Ontologie der Zeit
94 Kapitel 5: Konzeption
Um mit den Zeitmodellen rechnen zu können, müssen diese mathematisch umgewandelt wer-
den.61 Dazu wird hier die Zeit als eine Menge definiert, deren Elemente die Zeitpunkte (bzw.
Ereignisse) darstellen. Weiterhin ist eine totale Ordnung auf der Zeitmenge erforderlich, um
die Zeitinformationen vergleichen zu können. Dadurch sollen die verzweigende und die paral-
lele Zeit nicht weiter berücksichtigt werden.
Eine Zeitmenge wird durch ein Tupel (T, <) definiert, wobei gilt:
• T bezeichnet eine Menge von Zeitpunkten
• < ist eine vollständige Ordnungsrelation auf T, so dass gilt:
: liegt in der Vergangenheit von
Die kontinuierliche Zeitmenge ( , <) auf der Menge der reellen Zahlen mit der üblichen Ord-
nungsrelation „<“ erlaubt die beliebig genaue Einordnung eines Ereignisses. Allerdings ent-
steht durch die absolut exakte Vorgabe der Eindruck einer nicht erreichbaren Genauigkeit.62
Somit wird als Zeitmodell eine lineare, diskrete63 und einseitig beschränkte Zeit zugrunde
gelegt.64
Als geeignete Basis für das Zeitmodell bietet sich der Gregorianische Kalender an, der entspre-
chend eingeschränkt wird. Die Einschränkungen erfolgen auf der Ebene von Jahren,
Wochen65, Tagen und Schichten. Dabei wird jede Schicht aus einer Teilmenge gebildet.
Diese mehrstufige Schachtelung vereinfacht die Modellierung und die Berechnung im Zeitmo-
dell. Im Folgenden werden die Elemente des Zeitmodells definiert.
• K = { Y1, Y2, ... | Yi Kalenderjahr } mit
• Y = { W1, ... W53 | Wi Kalenderwoche } mit
• W = { D1, ... D7 | Di Kalendertag } mit
• D = { S1, S2, ... | Si Schicht } mit
61. Vgl. [Wens00].62. Die gleiche Argumentation gilt für eine zu (Q, <) isomorphe Zeitmenge.63. Und damit isomorph zu ( ,<).64. Vgl. Tabelle6. Die markierten Ausprägungen der Eigenschaften der Zeit schränken das hier verwen-dete Zeitmodell ein.65. Nach DIN 1355 lässt sich die Zuodnung von Tagen zu den Kalenderwochen wie folgt berechnen: Der1. Januar eines Jahres gehört erst dann zur der ersten Kalenderwoche, wenn dieser Tag auf einen Montag,Dienstag, Mittwoch oder Donnerstag fällt. Falls der 1. Januar ein Freitag, Samstag oder Sonntag ist, zählter, und ggf. auch der 2. und 3. Januar, noch zu der letzten Kalenderwoche des vorherigen Jahres. Weiter-hin können der 29., 30. und 31.12. eines Jahres schon zur Kalenderwoche 1 des neuen Jahres gehören.Das ist genau dann der Fall, wenn der 31.12. auf einen Montag, Dienstag oder Mittwoch fällt.
t1∀ t2 T∈, t1 t2< t1↔ t2
ℜ
ℵ
t1 t2( , )
Kapitel 5: Konzeption 95
• S ={ ( t1, t2 ), wobei t1 der Startzeitpunkt und t2 den Endzeitpunkt der Schicht dar-stellen}.
Damit ist das Zeitmodell in einer baumähnlichen Struktur abbildbar. Dabei befinden sich auf
jeder Ebene des Baumes die Instanzen eines Elementes des Zeitmodells. Die Identifikation
einer Instanz erfolgt über die Vorfahren in der Baumstruktur.
Um Berechnungen auf das Zeitmodell zu ermöglichen, sind Grundoperationen auf das Zeitmo-
dell zu definieren. Hierbei sind drei Typen von Operationen erforderlich:
• Grundoperationen zur horizontalen Navigation im Zeitmodell
• Grundoperationen zur vertikalen Navigation im Zeitmodell
• Grundoperationen zur Abbildung des Zeitmodells auf den Gregorianischen Kalender
Horizontale Operationen werden auf Elementen der gleichen Ebene (z.B. Schichten) im Zeit-
modell durchgeführt. Vertikale Operationen erlauben die Umwandlung der Elemente einer
Ebene in die Elemente einer benachbarten Ebene (z.B. für eine Schicht den passenden Tag
ermitteln). Weiterhin soll es möglich sein, aus einem Datum und einer Uhrzeit das passende
Element im Zeitmodell herauszufinden. Die auf das zu realisierende Zeitmodell ausführbaren
Grundoperationen werden in Kapitel 5.3.3.1.1 definiert.
5.1.4.2.2 Ereignisse und Zustände
Zur Beschreibung des Ablaufes in einem MFERT-Graphen werden sog. Modellereignisse ver-
wendet. Ein Modellereignis bildet reale oder simulierte (also vergangene/zukünftige) Ereig-
nisse und Zustände eines Fertigungssystems ab.66 Ein Modellereignis ist dabei vollständig
charakterisierbar durch einen „Ereignistypen“, einen „sachlichen“ und einen „zeitlichen“
Bezug. Der Ereignistyp ist gekennzeichnet durch Informationen über den Fertigungsvorgangs-
bzw. Fertigungselement-Knoten, dem das Ereignis zuzuordnen ist, die Interpretation des
Ereignisses und durch das Zeitmodell67 des Ereignisses. Die Interpretation stellt den Status des
Ereignisses dar. Hier sollen „Ist“, „Plan“ und „Soll“ unterschieden werden. Der zeitliche
Bezug gibt Auskunft über den Auftrittszeitpunkt des Ereignisses. Der sachliche Bezug gibt die
Fertigungsgegenstände68 an, auf die sich das Ereignis bezieht. Außerdem besitzt jedes Ereig-
66. Vgl. [Dang98b], S. 25.67. Im Hinblick auf die Zielsetzung dieser Arbeit beschränken wir uns auf das im vorherigen Abschnittdefinierte Zeitmodell. Eine ausführliche Behandlung der Problematik unterschiedlicher Zeitmodelle, dieAbbildung von Ereignissen und die Dauer von Zustandstransformationen als Ergebnis oder Auslöser ei-nes Ereignisses in diesen Zeitmodellen sowie die Abbildung der Zeitmodelle untereinander findet in[Holtk99] statt.
96 Kapitel 5: Konzeption
nis eine Quantität, die im Zusammenhang mit dem sachlichen Bezug steht. Im Folgenden sol-
len zunächst die Ereignisse zur Dokumentation des Ablaufes in den beiden Prozesstypen
betrachtet werden. Anschließend werden die Ereignisse zur Beschreibung der Flüsse zwischen
zwei elementaren Dispositionseinheiten untersucht.
Abbildung 28 zeigt, in Anlehnung an die Ausführungen in Kapitel 3.1.2, die Positionen in den
Prozesstypen auf, an denen die Dokumentation des Ablaufs erforderlich ist. Demnach werden
in den Fertigungselement- bzw. Fertigungsvorgangsknoten drei Bereiche betrachtet, die über
ein übergreifendes Regelwerk69 verwaltet und integriert werden. Der erste Bereich stellt die
Verwaltung und Dokumentation der Zugänge in den Knoten dar. In Abbildung 28a wird
dadurch der Fluss der Faktorarten in den Fertigungselementknoten abgebildet. Dagegen reprä-
sentieren die Zugänge in den Fertigungselementknoten der Abbildung 28b einerseits den Res-
sourcen-Fluss und andererseits ggf. die Zusammenführung von Ressourcen- und Faktorarten-
Flüssen am Fertigungsvorgangsknoten. In ähnlicher Weise stellt der dritte Bereich die Verwal-
tung und Dokumentation der Abgänge in den Knoten dar. Die Zu- bzw. Abgänge an den Ferti-
gungselementknoten in Abbildung 28b lassen sich durch die Materialverfügbarkeit für den
68. Ressourcen bzw. Faktorarten.69. Ein solches Regelwerk umfasst einerseits die Mengen- und Zeitrestriktionen bzgl. der übergänge zwi-schen den einzelnen Bereichen und andererseits die Planung des Ablaufes.
Abbildung 28: Dokumentation des Ablaufs in den Prozesstypen
a) b)
Puffer
Bes
tand
s-ve
rwal
tung
Zu
gang
Abg
ang
Tra
nsf
or-
mat
ion
Zu
gang
Abg
ang
Res
sou
rcen
-ve
rwal
tung
Zug
ang
Abg
ang
REGELWERK
REGELWERK
REGELWERK
Ressourcen
Transformation
Kapitel 5: Konzeption 97
Transformationsprozess abbilden. Der mittlere Bereich stellt die Verwaltung und Dokumenta-
tion des Übergangs von den Zugängen in die Abgänge dar. So umfasst die Bestandsverwaltung
in Abbildung 28a neben der Berechnung der Bestände der Faktorarten insbesondere die Erfas-
sung der Umbuchungen zwischen den unterschiedlichen Bestandstypen70 einer Faktorart.71
Die Transformationsvorgänge werden durch den Fertigungsvorgangsknoten der Abbildung
28b dokumentiert. Der zeitliche Bezug eines Transformationsereignisses stellt die zeitliche
Dauer der Transformation dar.72 Die Ressourcenverwaltung am Fertigungselementknoten bil-
det den Zustand der Ressourcen und damit ihre Verfügbarkeit ab.
Im Hinblick auf die möglichen Zuordnungen der Ereignistypen zu den sachlichen Bezügen las-
sen sich die in Abbildung 29 grau hinterlegten Möglichkeiten identifizieren. Demnach bezie-
hen sich die Ab- und Zugangsereignisse ausschließlich auf Faktorarten. Dagegen können
Transfomationsereignisse Ressourcen oder Ressourcen und Faktorarten als sachlichen Bezug
haben. Beispielsweise bezieht sich ein Rüstvorgang ausschließlich auf Ressourcen, ein Ferti-
gungsvorgang dagegen auf Ressourcen und Faktorarten. Bestandsumbuchungsereignisse
betreffen in der Regel nur Faktorarten, können jedoch ggf. auch Ressourcen mit einbeziehen.73
Verfügbarkeitsereignisse beziehen sich nur auf die Ressourcen.74
Der Informationsaustausch zum Materialfluss zwischen direkt benachbarten Prozessen kann
als Liste von Ereignissen angesehen werden. Insbesondere stellen die Abgangs- und Zugangs-
ereignisse und deren Eigenschaften eine Beschreibung der Informationsflüsse von und zu den
70. Durch die Modellierung verschiedener Bestandstypen lassen sich z.B. für eine Faktorart Bestände un-terschiedlicher Qualitätsstufen führen.71. Ereignisse dieser Art beziehen sich sachlich auf eine Faktorart und ggf. ein Lagermittel.72. Falls Ressourcen und Faktorarten den sachlichen Bezug bilden.73. Z.B. Reduzierung des Bestandes einer Faktorart oder Umbuchung der Bestände zwischen den Lager-mitteln.74. Die Materialverfügbarkeit lässt sich implizit durch die Bestandsumbuchungs-, Zu- und Abgangsereig-nisse in Abbildung 28a bestimmen.
Sachlicher Bezug
Nur Ressourcen Nur Faktorarten Ressourcen &Faktorarten
ZugangAbgangTransformation
Ere
igni
s-ty
pen
Ressourcenverfüg.
Abbildung 29: Mögliche Zuordnung Ereignistypen - Sachlicher Bezug
Bestandsumbuchung
98 Kapitel 5: Konzeption
direkt benachbarten Prozessen dar. Abbildung 30 zeigt die aus den Ab- bzw. Zugangsereignis-
sen in Verbindung mit den Interpretationen entstehenden Informationsflüsse auf.
Grundsätzlich lassen sich die in Abbildung 28 angegebenen Bereiche als Positionen zur
Bewertung des Fertigungsablaufs identifizieren. Dabei kann in Abhängigkeit von der verfolg-
ten Ablaufstrategie und des Erfassungssystems des realen Fertigungsprozesses zwischen
berechneten und erfassten Punkten unterschieden werden.
Im Hinblick auf das im Rahmen dieser Arbeit verwendete Zeitmodell sollen die Ereignisse
schichtweise betrachtet werden.75 Dabei beziehen sich die Auftrittszeitpunkte der Ereignisse
stets auf den Anfangs- bzw. Endzeitpunkt einer Schicht. Erstreckt sich eine Transformation
über mehrere Schichten, so wird dies im Modell durch Ereignisse, die sich jeweils auf eine
Schicht beziehen, dargestellt.
5.1.5 Herleitung von Sichten auf die Informationsstruktur
In diesem Abschnitt geht es darum, auf der Basis der im vorherigen Abschnitt vorgestellten
Ereignisse zur Dokumentation des fertigungsrelevanten Ablaufes elementare Operationen zu
entwickeln, die es ermöglichen, in Abhängigkeit von den Eigenschaften der Dispositionsein-
heit individuelle Sichten76 auf das Fertigungsgeschehen zu erstellen. Dadurch soll das Ferti-
gungsgeschehen für die Disponenten transparenter aufgezeigt werden können und somit zu
einer Verbesserung der Entscheidungsunterstützung führen. Die Gestaltung solcher Sichten
kann grundsätzlich sowohl durch die Auswahl eines Ausschnittes aus dem Ereignisraum als
auch durch die Ergebnisse von Berechnungen auf ausgewählte Bereiche des Ereignisraumes75. Da die „Schicht“, die kleinste Einheit im Zeitmodell darstellt.76. Unter einer Sicht sollen hier i.w.S. Informationen über den fertigungsrelevanten Ablauf in einem be-stimmten Zeitraum verstanden werden.
Interpretationen
Soll Plan Ist
Zugang
Abgang
Zugang
Abgang
Bruttobedarfe
Bruttobedarfe
ZugesagteNettoangebote
Nettobedarfe
Nettobedarfe
ZugesagteBruttoangeboteZugesagteBruttoangeboteZugesagteNettoangebote
Tatsächlich erbrachteNettoangeboteTatsächlich erbrachteBruttoangeboteTatsächlich erbrachteBruttoangeboteTatsächlich erbrachteNettoangebote
Abbildung 30: Interpretationen der Ab- und Zugangsereignisse
Kapitel 5: Konzeption 99
erfolgen. Dazu sind geeignete Zugriffsdimensionen im Ereignisraum zu bestimmen, die einen
komfortablen und effizienten Zugriff auf die Ereignisse gestatten. Durch die totale Ordnung
auf dem hier verwendeten Zeitmodell77 lässt sich der Auswahlbereich im Ereignisraum für
einen Zeitraum durch zwei Selektionen eingrenzen (vgl. Abbildung 31). Als weitere Zugriffs-
dimensionen können der sachliche Bezug und die Interpretation herangezogen werden.
Da ein Ereignis sich zeitlich stets auf eine Schicht bezieht, kann bei der Definition der Opera-
tionen der Betrachtungszeitraum zunächst auf eine Schicht beschränkt werden. Dazu sollen die
folgendenden Bezeichnungen festgelegt werden:
bezeichnet die betrachtete Schicht,
die Dauer der Schicht (z.B. in Minuten) und
die gegenwärtig aktuelle Schicht.
Zur Herleitung der Operationen soll im Folgenden zwischen elementaren und kombinierten
Operationen unterschieden werden. Elementare Operationen sollen den Zugriff auf die Eigen-
schaften einzelner Ereignisse ermöglichen. Kombinierte Operationen stellen eine Berechnung
dar, die sich auf einem bis mehreren Ereignissen bezieht.
5.1.5.1 Elementare Operationen
Zur Definition der elementaren Operationen werden neben den bereits angegebenen Mengen
der Input- und Output-Faktorarten und den Ressourcen der Dispositionseinheit die folgenden
Mengen definiert:
Sei die Menge der möglichen Interpretationen und
77. Vgl. Kapitel 5.1.4.2.1.
ZeitdimensionS1 ST
(ST,<=)
(S1, >=)&(ST,<=)
(S1,>=)
T: Zeitraum, mit T=(S1, ST) und S1<=ST
S1, ST : Schichten
Abbildung 31: Selektion eines Ausschnittes des Ereignisraumes
St
∆ St( )
Saktuell
I° soll plan, ist{ , }=
100 Kapitel 5: Konzeption
,
die Menge der Bestandstypen,
die Menge der Bestandsumbuchungstypen.
, stellt die Menge der Bestandsumbuchungstypen dar, die auf dem
Bestandtyp durchgeführt werden können.
sei die Menge der Ressourcen, auf denen verarbeitet wer-
den kann.
Damit lassen sich die folgenden Funktionen für den Zugriff auf die Ereignisse eines Ereignis-
typs beschreiben:
• Zugang:
Mit
:
sei die Funktion bezeichnet, die für eine Input-Faktorart in der Schicht die Höhe des ent-
stehenden Bedarfes(Soll) oder die Höhe des zugesagten(Plan) bzw. bereits erbrachten(Ist)
Angebotes ermittelt.78
• Abgang:
Mit
:
sei die Funktion bezeichnet, die für eine Output-Faktorart in der Schicht die Höhe des
gemeldeten Bedarfes(Soll) oder die Höhe des zugesagten (Plan) bzw. bereits erbrachten (Ist)
Angebotes ermittelt.
78. Vgl. Abbildung 30.
I1 planist{ , }=
BT bt1 …, btab{ , }=
BWT bwt1 …, bwtaw{ , }=
BWTbt bBWT⊆ BWTbtb
btb
M Aj( ) Mk M∈ KFk j, 0>,{ }= Aj
ZG E I°× S× ℜ′→
Ei St
AG A I°× S× ℜ′→
A j St
Kapitel 5: Konzeption 101
• Verfügbarkeit der Ressourcen:
Es sei
:
die Funktion, die angibt, wie die Ressource in der Schicht verfügbar sein wird bzw. ist.
• Transformation:
Für die Transformationsereignisse werden die folgenden Funktionen definiert:
Es sei : die Funktion, die die Dauer des Umrüstvorgangs der
Ressource von einer Output-Faktorart auf eine Output-Faktorart ermittelt.
Für die auf der Ressource in der betrachteten Schicht zu fertigenden bzw. bereits gefer-
tigten Lose gilt:
: bestimmt die Anzahl der zu fertigenden bzw. bereits
gefertigten Output-Faktorarten auf der Ressource in der Schicht .
: liefert für eine Output-Faktorart die Position des
zu fertigenden bzw. bereits gefertigten Loses, falls vorhanden.
: bestimmt ausgehend von der Position , mit
bzw. , die Quantität des zu fertigenden bzw.
bereits gefertigten Loses auf der Ressource in der Schicht .
: ermittelt die Output-Faktorart, die in der Schicht
auf der Ressource an der Position zu fertigen bzw. bereits gefertigt ist.
• Bestandsumbuchung:
Es sei
: die Funktion, die für eine Faktorart in
der betrachteten Schicht auf der Ressource die Höhe der geplanten bzw. bereits erfolg-
VG M I1× S× 0 1[ , ]→
Mk St
UZ M A× A× ℜ′→
Mk A i A j
Mk St
Losa M I1× S× ℵ→
Mk St
Loss M I1× A× S× ℵ→ A i
Losq M I1× S× ℵ× ℜ′→ p
0 p Losa Mk plan St, ,( )≤< Losa Mk ist, St( , )
Mk St
LosA M I1 S×× ℵ× A→ St
Mk p
BW BWT E A∪( )× S I1 M××× ℜ→
St Mk
102 Kapitel 5: Konzeption
ten Bestandsumbuchung , falls vorhanden, ermittelt. Dabei kann optional, falls der
Bestand pro Ressource79 verwaltet wird, die Ressource als Parameter angegeben werden.
5.1.5.2 Kombinierte Operationen
Auf der Basis der in Kapitel 5.1.5.2 angegebenen Operationen sollen hier (weiterführende)
Berechnungen auf den Ereignisraum vordefiniert werden. Dazu sollen zunächst die Operatio-
nen, die primär die Ressourcen betreffen, betrachtet werden. Anschließend werden Operatio-
nen für Faktorarten vorgestellt.
• Operationen auf Ressourcen:
Hier steht die Kapazität als wichtigste Eigenschaft einer Ressource im Vordergrund. Bezogen
auf eine Schicht lässt sich die maximal verfügbare Kapazität (sog. Kapazitätsangebot) einer
Ressource mit
für Fertigungsprozesse oder mit
für Puffer- bzw. Transportprozesse angeben, wobei
die fest vorgegebene Kapazität der Ressource darstellt.80
Für eine Ressource eines Fertigungsprozesses besteht der benötigte Kapazitätsanteil in einer
Schicht aus der Summe der Bearbeitungs- und Umrüstzeiten. Es sei die Summe
der Bearbeitungszeiten auf Ressource in der Schicht , dann gilt81:
79. Lagermittel.80. Vgl. Kapitel 5.1.4.1.2.81. Hierbei wird zur Vereinfachung angenommen, dass die erforderliche Zeit zur Fertigung des erstenTeils eines Loses mit dem Kapazitätsfaktor (Zykluszeit) identisch ist.
bwtw
St
Mk
Kap Mk St,( ) VG Mk St( , ) St( )∆⋅=
Kap Mk St,( ) VG Mk St,( ) Kap Mk( )⋅=
Kap Mk( )
SBZ Mk St,( )
Mk St
SBZ Mk St,( )
KF Mk Losa Mk plan, St i,( , )( , ) Losq Mk plan St, , i( , )⋅i 1=
Losa Mk plan, S t( , )
∑ St Saktuell≥,
KF Mk Losa Mk ist, St i,( , )( , ) Los q Mk ist St, , i( , )⋅i 1=
Losa Mk ist, S t( , )
∑ sonst,
=
Kapitel 5: Konzeption 103
Es sei die Summe der Umrüstzeiten auf Ressource in der Schicht , dann
gilt:
Damit kann die Restkapazität in der Schicht durch:
angegeben werden.
• Operationen auf Faktorarten:
Operationen auf Faktorarten betreffen grundsätzlich die Menge der verfügbaren Bestände
gegen Ende einer Schicht. Dazu sollen zunächst Operationen auf die Transformations- und
Bestandsumbuchungsereignisse angegeben werden.
Auf den Transformationsereignissen lässt sich für eine Output-Faktorart mit
bzw. die Höhe der zu fertigenden bzw. bereits gefertigten Menge Ende der Schicht
bestimmen, wobei und
Auf den Bestandsumbuchungsereignissen ist mit bzw.
dem Nettowert der Bestandsumbuchungen, die den Bestandstyp der
Output-Faktorart betreffen.82
O.B.D.A sei der Bestandstyp, in dem die Rückmeldungen der Fertigung und die Ab- bzw.
Zugänge erfolgen, dann können mit bzw. für die
erwarteten Bestände und für die die tatsächlichen Bestände83 der Faktorarten
berechnet werden.
Dabei gilt für :
und
82. Analog wird die Operation für die Input-Faktorarten definiert.83. Dazu erfolgt die enstprechende Berechnung mit den „Ist“-Werten.
SUZ Mk St,( ) Mk St
SUZ Mk St( , ) UZ Mk LosA Mk plan St i, , ,( ) LosA Mk plan St i, , ,( ),( , )i 1=
Losa Mk plan, S t( , ) 1–
∑=
FreieKap Mk St,( ) Kap Mk St,( ) BZ Mk St,( )– UZ Mk St,( )–=
Plan Aj St,( )
Ist Aj St,( )
St Plan Aj St,( ) Losq Mk plan St Loss Mk plan Aj St, , ,( ), , ,( )Mk M Aj( )∈( )∀
∑=
Is t Aj St,( ) Losq Mk ist St Loss Mk ist Aj St, , ,( ), , ,( )Mk M A j( )∈( )∀
∑=
SBW Aj St btb plan, , ,( )
SBW Aj St btb plan, , ,( ) btb
A j SBW Aj St btb plan, , ,( ) BW bwti St btb plan, , ,( )bwti BWT btb
∈( )∀∑=
bt1
Bes d Aj St,( )tan Bes d Ei St,( )tan St Saktuell≥
St Saktuell<
St Saktuell≥
Bes d Aj St,( )tan Bes d Aj St 1–,( )tan Plan Aj St,( ) SBW Aj St bt 1 plan, , ,( ) AG Aj soll S t, ,( )–+ +=
104 Kapitel 5: Konzeption
Für die weiteren Bestandstypen kann die Höhe des Bestandes der Out-
put-Faktorart84 Ende der Schicht durch angegeben werden.
Dabei gilt für 85:
Fazit: In Kapitel 5.1 wurden die Charakterisierungsmerkmale der Dispositioneinheiten herge-
leitet und mittels der Konstrukte des Modells der Fertigung beschrieben. Dazu wurden
zunächst Teilgraphen zur Beschreibung der internen Prozesse einer Dispositionseinheit festge-
legt. Anschließend wurden durch die Bestimmung des zu planenden Prozesses und des für den
Planungsanstoß erforderlichen Informationsflusses die Ausprägungen des Merkmals Ablauf-
richtung beschrieben. Die Dokumentation des durch die Prozessstruktur und die Ablaufrich-
tung definierten Ablaufes gewährleistet die Informationsstruktur. Hierzu sind Ausprägungen
der Konstrukte des Modells der Fertigung angewendet worden. Auf der erstellten Informati-
onsstruktur wurden abschließend die zur Bildung von Sichten auf das Fertigungsgeschehen
erforderlichen Operationen definiert.
84. Ähnlich erfolgt die Berechnung für die Input-Faktorarten.85. Für erfolgt die Berechnung mit den „Ist“-Werten.
Bes d Ei St,( )tan Bes d Ei St 1–,( )tan ZG Ei plan St, ,( ) SBW Aj St bt1 plan, , ,( )+ +=
fE Ei( ) l[ ] Plan Al St,( )⋅l 1=
a
∑–
btb bt2 … btab, ,{ }∈
A j St Bes d Aj St btb, ,( )tan
St Saktuell≥
St Saktuell<
Bes d Aj St btb, ,( )tan Bes d Aj St 1– btb, ,( )tan SBW Aj St bt b plan, , ,( )+=
Kapitel 5: Konzeption 105
5.2 Gestaltung der Beziehungen entlang der Lieferkette
In diesem Kapitel werden die Beziehungen zwischen den Dispositionseinheiten der Lieferkette
betrachtet. Ziel dabei ist es, aufbauend auf den in Kapitel 5.1 vorgestellten Strukturen, die
Gestaltung der operativen fertigungsrelevanten Informationsflussbeziehungen zu ermöglichen.
Dabei sollen sowohl die Informationsflüsse zu den nachgelagerten Dispositionseinheiten
(Kunden) als auch zu den vorgelagerten Dispositionseinheiten (Lieferanten) betrachtet wer-
den. Dazu werden zunächst in Abschnitt 5.2.1 die Eigenschaften der möglichen Interdepen-
denzen86 zwischen den Dispositionseinheiten untersucht. Anschließend werden in Abschnitt
5.2.2 die Merkmale der Informationsflussbeziehungen sowie Konstrukte zur Koordination der
Abläufe vorgestellt. Ziel dabei ist es, den Informationsfluss zu jeder direkt benachbarten87
Dispositionseinheit88 in der Lieferkette individuell gestalten zu können und somit den Grad
der Integration zu steuern (vgl. Abbildung 32).
5.2.1 Merkmale der Interdependenzen
Die Wertschöpfungsbeziehungen zwischen den Dispositionseinheiten stellen die Ausgangsba-
sis für die Interdependenzen dar. Diese wiederum bilden die Grundlage für die Gestaltung der
Informationsflussbeziehungen.89 Dazu sollen im Folgenden die Interdependenzen im Hinblick
86. Interdependenzen sollen die Abhängigkeitsbeziehungen zwischen den Dipositionseinheiten beschrei-ben.87. Zwei Dispositionseinheiten sind genau dann direkt benachbart, wenn zwischen ihnen eine Wert-schöpfungsbeziehung besteht. 88. Lieferant oder Kunde.89. So nimmt, in Anlehnung an [TuNa78] S. 616, die Koordinationsintensität besonders mit der Komple-xität bestehender Interdependenzen zwischen den Dispositionseinheiten zu.
Dispositionseinheit
Lieferanten Kunden
. . .
. . .
Individuelle Informationsflussbeziehungen
Abbildung 32 : Informationsflussbeziehungen einer Dispositionseinheit
106 Kapitel 5: Konzeption
auf die Art der auszutauschenden Leistungen, der quantitativen, qualitativen und zeitlichen
Zusammenhänge untersucht werden. Die verschiedenen Aspekte der Interdependenzen werden
zunächst aus der Sicht einer Dispositionseinheit betrachtet.
Kernmerkmal der Interdependenzen zwischen zwei Dispositionseinheiten ist die Art des ver-
einbarten Leistungsaustausches. In Abhängigkeit vom Bezug zur Materialflussrichtung kann
eine Dispositionseinheit in Wertschöpfungsbeziehungen zu den direkt vorgelagerten bzw.
nachgelagerten Dispositionseinheiten stehen. Dazu ist an jeder Dispositionseinheit festzule-
gen, welche Leistungen von einem Lieferanten erwartet bzw. welche Leistungen einem Kun-
den angeboten werden können. Sachlich kann sich ein Leistungsaustausch auf eine Input- bzw.
Output-Faktorart, aber auch auf Ressourcenkapazitäten90 beziehen. Dadurch lassen sich
erzeugnis- und ressourcenorientierte Wertschöpfungsbeziehungen zwischen den Dispositions-
einheiten unterscheiden.
Grundsätzlich können erzeugnisorientierte Wertschöpfungsbeziehungen zwischen allen Typen
von Dispositionseinheiten bestehen.91 Dabei ist zunächst in der betrachteten Dispositionsein-
heit für jeden Lieferanten bzw. Kunden die Menge der Input- bzw. Output-Faktorarten festzu-
legen, die geliefert werden können. Formal lässt sich dies wie folgt beschreiben:
Seien K bzw. Z Mengen der direkt nachgelagerten bzw. vorgelagerten Dispositionseinheiten,
dann gilt:
, wobei die Menge der Output-Faktorarten definiert, die vom
Kunden angefordert werden können.
Analog gilt: , wobei die Menge der Input-Faktorarten definiert,
die von einem Lieferanten geliefert werden können.
Dagegen ermöglichen ressourcenorientierte Wertschöpfungsbeziehungen den direkt benach-
barten Dispositionseinheiten den Zugriff auf bestimmte Betriebsmittelkapazitäten. Damit las-
sen sich insbesondere für Transport- und Pufferprozesse die Betriebsmittel bzw.
Betriebsmittelkapazitäten festlegen, die von einem Kunden bzw. Lieferanten genutzt werden
90. Z.B. Zwischen einem Spediteur und einem Hersteller.91. Zwar lässt sich unter Berücksichtigung der Modellierungsrestriktion von MFERT, Knoten eines Typs(Drei- oder Viereck) dürfen nur Knoten eines anderen Typs als Nachfolger haben, die Anzahl der mögli-chen Wertschöpfungsbeziehungen zwischen den Dispositionseinheiten einschränken, allerdings könnendurch die implizite Modellierung von Prozessen aufgrund ihrer Zeitdauer die Einschränkungen teilweiseaufgehoben werden.
K l∀ K∈ A Kl( )∃ 2A∈ A K l( )
Kl
Zl∀ Z∈ E Zl( )∃ 2E∈ E Z l( )
Zl
Kapitel 5: Konzeption 107
können. Weiterhin können durch ressourcenorientierte Wertschöpfungsbeziehungen die ver-
fügbaren Kapazitäten erweitert werden, um ggf. bei Engpasssituationen über „Alternativ“-
Kapazitäten verfügen zu können.
Formal gilt: bzw. gilt, bzw. , wobei
bzw. die Betriebsmittel festlegen, deren Kapazitäten vom Kunden Kl bzw. vom Liefe-
ranten Zl in Anspruch genommen werden können.92
Die zeitlichen Aspekte der Interdependenzen können zunächst neben der vereinbarten Lebens-
dauer der Wertschöpfungsbeziehung durch die erzeugnisspezifischen Vorlaufzeiten charakte-
risiert werden. Bei einer erzeugnisorientierten Wertschöpfungsbeziehung beschreibt die
erzeugnisspezifische Vorlaufzeit93 den „Zeitunterschied“ gegenüber einer direkt benachbarten
Dispositionseinheit. Für eine nachgelagerte Dispositionseinheit stellt die erzeugnisspezifische
Vorlaufzeit die Mindestzeit dar, die die betrachtete Dispositionseinheit für die Deckung eines
Bedarfs von einer Output-Faktorart benötigt.94 Für eine vorgelagerte Dispositionseinheit
beschreibt sie dagegen die minimale Zeit, mit der die geplanten Lieferungen einer Input-Fak-
torart verzögert werden können.
Ein weiteres Charakterisierungsmerkmal für den zeitlichen Aspekt der Interdependenzen stel-
len die zeitlichen Restriktionen der vereinbarten Dispositionsstrategie dar. Dabei kann das
Bestellen eines Bedarfes bzw. das Anbieten eines (Teil-)Bestandes abhängig vom Erreichen
eines vorgegebenen Zustandes (Bestellpunkt) oder eines Zeitpunktes (Bestellrhythmus) erfol-
gen. Darauf basierend lassen sich bei der Betrachtung der quantitativen Aspekte der Interde-
pendenzen grundsätzlich die bedarfsorientierte und verbrauchsorientierte
Dispositionsstrategie unterscheiden. Bei der bedarfsorientierten Dispositionsstrategie werden
die Bedarfe bzw. Angebote zeitlich und mengenmäßig so ausgelöst, wie sie zur Befriedigung
eines gegebenen Primärbedarfs erforderlich sind. Dazu werden die Erzeugnisstruktur und die
geplanten Abläufe berücksichtigt.
92. Z.B. Lager-, Transportmittel oder Spezialmaschinen, die ausschließlich für einen Kunden benutztwerden.93. Mit Vorlaufzeit ist hier die minimale Übergangszeit (vgl. Abbildung 2.1.2) zwischen den Dispositi-onseinheiten gemeint. Sie wird in Abbildung 5.3.3 auch als Sicherheitszeit bezeichnet.94. Z.B. entsteht bei einem Kunden ein Bedarf in einer bestimmten Schicht S, der von der Dispositions-einheit gedeckt werden soll, so ist daraus mit Hilfe der erzeugnisspezifischen Vorlaufzeit die Schicht zuberechnen, in der die Bedarfsmenge spätestens fertigzustellen ist, um den Kundenbedarf rechtzeitig erfül-len zu können.
K l∀ K∈ Z l∀ Z∈ M Kl( )∃ 2M∈ M Zl( )∃ 2M∈ M Kl( )
M Zl( )
108 Kapitel 5: Konzeption
Bei der verbrauchsorientierten Dispositionsstrategie werden aufgrund tatsächlich erfolgter
Verbräuche und daraus abgeleiteter verfügbarer Bestände in Abhängigkeit von vordefinierten
Restriktionen neue Bedarfe bzw. Angebote ausgelöst. Hierbei wird zwischen Bestellrhythmus
und Bestellpunkt unterschieden (vgl. Abbildung 3395).
Wird der Bestand zu vorgegebenen Zeitpunkten (Bestellrhythmus) ergänzt bzw. verringert, so
können, wie in Abbildung 33 aufgezeigt, die folgenden Alternativen unterschieden werden:
• Auffüllen auf den Maximalbestand/Entleeren auf den Minimalbestand (T, S)
• Auffüllen auf den Maximalbestand/Entleeren auf den Minimalbestand, falls der Melde-
bestand erreicht ist (T, S, s)
• Anfordern/Anbieten einer festen Losgröße (T, Q)
• Anfordern/Anbieten einer festen Losgröße, falls der Meldebestand erreicht ist (T, Q, s)
95. Vgl. [DaWa97], S. 262.
Bestellrhythmus
Bestellpunkt
feste Menge
mit Bestellpunkt(T, S, s)
Auffüllen
Ohne Bestellpunkt(T, S)
feste Menge(s, Q)
Auffüllen(s, S)
mit Bestellpunkt(T, S, s)
Ohne Bestellpunkt(T, S)
Abbildung 33: Verbrauchsorientierte Auslösungsarten
s Bestellpunkt (Meldebestand)S Sollbestand (Maximal-/Minimalbestand)T Bestellzyklus (konstantes Zeitintervall)B (Perioden-)Bedarf/BestandQ Bestellmenge
zeitorientierteBetrachtung
mengenorientierteBetrachtung
zeit- und mengenorientierteBetrachtung
Kapitel 5: Konzeption 109
Wird dagegen der Bestand permanent überwacht, um beim Auftreten eines bestimmten Ereig-
nisses, wie z.B. das Erreichen des Bestellpunktes, zu reagieren und den Bestand aufzufüllen
bzw. zu entleeren, so sind folgende Alternativen zu unterscheiden:
• Auffüllen auf den Maximalbestand/Entleeren auf den Minimalbestand bei Erreichen des
Meldebestandes (s, S)
• Anfordern/Anbieten einer festen Losgröße, falls Meldebestand erreicht ist (s,Q)
Als qualitative Aspekte der Interdependenz lassen sich mögliche Substitutionsmöglichkeiten
unter den Faktorarten, die den sachlichen Gegenstand der Wertschöpfungsbeziehung darstel-
len, identifizieren. Dazu lassen sich für jede vor- bzw. nachgelagerte Dispositionseinheit
Beziehungen zwischen den Input- bzw. Output-Faktorarten definieren, die den Grad der Sub-
stituierbarkeit festlegen. Dadurch können in Engpasssituationen unerfüllbare Bedarfe einer
Faktorart aus eventuell verfügbaren Angeboten einer anderen Faktorart gedeckt werden.
Formal gilt: bzw. gilt, bzw. , mit
bzw. , dann legt
: bzw. : den Grad der Substituierbarkeit zwi-
schen den Faktorarten fest.
Kl∀ K∈ Zl∀ Z∈ Q Kl( )∃ 2A Kl( )
∈ Q Z l( )∃ 2E Zl( )
∈
Q Kl( ) a b{ , } a b, A Kl( )∈,{ }= Q Z l( ) a b{ , } a b, E Z l( )∈{ , }=
GSKlQ Kl( ) 0 1[ , ]→ GSZl
Q Zl( ) 0 1[ , ]→
110 Kapitel 5: Konzeption
5.2.2 Management der Interdependenzen
In diesem Abschnitt werden die Gestaltungsmöglichkeiten der operativen Informationsflüsse
zwischen den Dispositionseinheiten betrachtet. Dazu findet zunächst in Kapitel 5.2.2.1 eine
Betrachtung der Formen zur Realisierung des Informationsaustausches statt. In Kapitel 5.2.2.2
erfolgt eine Kategorisierung der möglichen operativen Informationsflüsse. Anschließend wird
in Kapitel 5.2.2.3 aufgezeigt, welche Merkmale zur individuellen Gestaltung der Informations-
flüsse für die Abstimmung der dispositiven Entscheidungen herangezogen werden können. In
Kapitel 5.2.2.4 werden dann Konstrukte zur Beschreibung der Interaktionen zwischen den Dis-
positionseinheiten hergeleitet.
5.2.2.1 Formen des Informationsaustausches
Zur Realisierung des Informationsaustausches zwischen zwei Dispositionseinheiten lassen
sich zwei grundsätzliche Kommunikationsmodelle unterscheiden: Das Share- und Send-
Modell (vgl. Abbildung 34). Beim Share-Modell erfolgt die Kommunikation zwischen den
betroffenen Dispositionseinheiten indirekt über eine gemeinsame Instanz96, die in direkter
Kommunikation mit den Dispositionseinheiten steht. Dazu verfügt eine solche Instanz häufig
über Regeln, wie die Abstimmung unter den Dispositionseinheiten durchgeführt werden kann.
Das Share-Modell eignet sich besonders für den Informationsaustausch zwischen den innerbe-
trieblichen Dispositionseinheiten, die häufig eine gemeinsame Datenbasis nutzen bzw. von
einer zentralen Instanz koordiniert werden können.
Beim Send-Modell erfolgt die Kommunikation über den direkten Nachrichtenaustausch zwi-
schen den Dispositionseinheiten. Dazu ist erforderlich, dass jede Seite über Regeln verfügt,
wie die Abstimmung durchgeführt werden kann. Gegenüber dem Share-Modell entsteht dabei
ein erheblicher Abstimmungsbedarf unter den betroffenen Dispositionseinheiten. Das Send-
Modell eignet sich besonders, aufgrund der häufig nicht vorhandenen gemeinsamen Datenba-
sis, für die Gestaltung des betriebsübergreifenden Informationsaustausches.
96. Z.B. Eine gemeinsame Datenbasis oder ein zentraler Koordinator.
Kapitel 5: Konzeption 111
Um den Anforderungen97 bezüglich der individuellen und flexiblen Gestaltung der Informati-
onsflüsse und damit des Informationsaustausches zu genügen, wird im Folgenden das Kanal-
konzept98 als Kommunikationsmodell zwischen den Dispositionseinheiten zugrunde gelegt
(vgl. Abbildung 3599). Dabei verfügt ein Kanalobjekt über Daten und Operationen, mit deren
Hilfe die Elemente eines Netzwerkes miteinander in Interaktionen treten und Informationen
austauschen können. So stellt jedes Kanalobjekt Sende- und Empfangsoperationen bereit, mit
denen Informationen geschrieben und gelesen werden können. Dazu werden neben den Kanal-
namen Behälteradressen verwendet, die beim Senden die Quelladresse und beim Empfangen
die Zieladresse der Nachricht darstellen.
Durch den Einsatz des Kanalkonzeptes lassen sich sowohl die synchrone als auch die asyn-
chrone Kommunikation unterstützen. Dazu wird zur Umsetzung der synchronen Kommunika-
tion zwischen dem synchronen Empfangen und dem synchronen Senden unterschieden. Beim
synchronen Empfangen hängt das weitere Vorgehen an der Senke von dem Empfang einer
bestimmten Nachricht ab. Dazu signalisiert der Empfänger seine Empfangsbereitschaft durch
eine entsprechende Empfangsoperation und blockiert solange die Ausführungen seiner Tätig-
keit, bis die Quelle durch ihre Sendeoperation den Informationsfluss auslöst. Analog blockiert
die Quelle beim synchronen Senden die Ausführung der Tätigkeiten, bis die Senke die Nach-
richt empfangen hat.
Zur Umsetzung der asynchronen Kommunikation werden sog. Puffer im Kanalobjekt verwen-
det. Führt die Quelle eine Sendeoperation durch, obwohl die Senke noch nicht empfangsbereit
97. Vgl. Kapitel 2.2.2.98. Vgl. [Heis97].99. Die Darstellung erfolgt vereinfacht und ohne Berücksichtigung der zeitlichen Aspekte.
Send-Modell
Legende:Datenbasis/Koordinator
Dispositionseinheit
direkte Kommunikation
indirekte Kommunikation
Abbildung 34: Grundlegende Formen der KommunikationShare-Modell
112 Kapitel 5: Konzeption
ist, so wird die Nachricht im Puffer des Kanalobjektes aufgehalten, bis die Senke ihre Emp-
fangsoperation durchführt.
5.2.2.2 Herleitung von Informationsflusstypen
In diesem Abschnitt stellen die möglichen Informationsflüsse zwischen den Dispositionsein-
heiten den Betrachtungsgegenstand dar. Ziel dabei ist die Identifizierung von Informations-
flusstypen, um einerseits die Informationsflüsse zur Abstimmung der Leistungserstellung
individuell gestalten zu können und andererseits die Inhalte und ggf. die Formate der Informa-
tionsflüsse festlegen zu können. Dabei bilden die Interdependenzen100 und die zu vereinbaren-
den Informationsprofile101 zwischen den Dispositionseinheiten den Ausgangspunkt zur
Gestaltung der Informationsflüsse. In Tabelle7 stellen die dunkel-markierten Ausprägungen
eine Einordnung der hier zu betrachtenden Informationsflüsse dar.
Im Folgenden sollen in Abhängigkeit vom Zweck und der Auswirkung des Informationsflus-
ses auf die bestehenden Interdependenzen die vereinbarten Informationsprofile und auf den
geplanten Fertigungsablauf in der empfangenden Dispositionseinheit die drei grundsätzlichen
Informationsflusstypen unterschieden werden: administrative, dispositive und instruktive
Informationsflüsse.
100. Vgl. Kapitel 5.2.1.101. Vgl. Kapitel 5.2.2.3.
Quelle Senke
Sende(KN,QB) Empfange(KN,ZB)
Kanalobjekt
KN: KanalnameQB: QuellbehälterZB: Zielbehälter
ZBQB
Abbildung 35: Das Kanalkonzept
Kapitel 5: Konzeption 113
5.2.2.2.1 Administrative Informationsflüsse
Unter die administrativen Informationsflüsse fallen alle Informationsflüsse, die die Verwal-
tung der Interdependenzen und der vereinbarten Informationsprofile zum Zweck haben. Dazu
gehören einerseits Informationsflüsse zum Auf-, Abbau oder zur Modifikation der Interdepen-
denzen102 und damit der zugrunde liegenden Wertschöpfungsbeziehungen und andererseits
die Informationsflüsse zur Modifikation des vereinbarten Informationsprofils. Inhaltlich
umfassen die administrativen Informationsflüsse zur Verwaltung der Interdependenzen im
Wesentlichen Informationen zu der Faktorart bzw. Ressourcenkapazität, die von den Koopera-
tionspartnern bezogen bzw. abgenommen wird, sowie Parameter zur Beschreibung der zeitli-
chen, quantitativen und qualitativen Aspekte der Interdependenzen. Dagegen bestehen die
administrativen Informationsflüsse zur Verwaltung der Informationsprofile aus Parametern zur
Konfiguration der benötigten Informationen, um diese entsprechend den Anforderungen des
Empfängers aufbereiten zu können.103
Die Frequenz der administrativen Informationsflüsse zwischen zwei Dispositionseinheiten ist
abhängig vom Grad der Veränderungen, dem die Interdependenzen bzw. Informationsprofile
während ihres Lebenszyklusses ausgesetzt sind. Ihren Höhepunkt hat sie während des Aufbaus
der Kooperationsbeziehung, da zu diesem Zeitpunkt die Charakteristika der Interdependenzen
Merkmal Ausprägungen
Richtung Downstream Upstream
Bezug zum Ablauf (Materialfluss)
Progressiv RetrogradOrthogo-
nal
Aufbauorganisation Horizontal Vertikal
Integrationsebene Unternehmensüber-greifend
Bereichs-intern
Bereichs-übergreif
end
Hierarchieebene Operativ Taktisch/Strategisch
Anstoß Bringend(Push) Holend(Pull)
Steuerung Steuernd Nicht-Steuernd
Tabelle 7: Einordnung der Informationsflüsse
102. Z.B. Kreieren einer neuen Wertschöpfungsbeziehung oder die Änderung des Bestellrhythmus für einErzeugnis.103. Vgl. Kapitel 5.2.2.3.
114 Kapitel 5: Konzeption
und der Informationsprofile mit Hilfe administrativer Informationsflüsse ausgetauscht werden
müssen. Unmittelbar darauf nimmt die Frequenz der administrativen Informationsflüsse im
Mittel ab, das Informationsaufkommen verlagert sich auf andere Informationsflusstypen.
5.2.2.2.2 Dispositive Informationsflüsse
Die dispositiven Informationsflüsse umfassen alle Informationsflüsse, die zur Abstimmung der
Leistungserstellung zwischen den Dispositionseinheiten beitragen. Ausgangspunkt zur Bil-
dung der dispositiven Informationsflüsse stellen die in Kapitel 5.1.4.2 definierten Ereignisse
einer Dispositionseinheit dar. Dabei lässt sich ein dispositiver Informationsfluss inhaltlich
durch einen sachlichen und einen zeitlichen Bezug sowie eine Quantität charakterisieren. Der
sachliche Bezug legt fest, welche Input- bzw. Output-Faktorart oder Ressource vom Informati-
onsfluss betroffen ist. Der zeitliche Bezug beschreibt einen Zeitpunkt104 bzw. einen Zeit-
raum105, auf den sich der dispositive Informationsfluss bezieht. Die Quantität eines
dispositiven Informationsflusses wird durch die mengenmäßigen Einheiten und den Quanti-
tätstypen106 angegeben.
Ein dispositiver Informationsfluss wird durch Operationen107 in einem Ausschnitt des Ereig-
nisraumes der betrachteten Dispositionseinheit gebildet und zielt dabei auf die Benachrichti-
gung der direkt benachbarten Dispositionseinheiten über den geplanten Fertigungsablauf ab.
Hierbei können die dispositiven Informationsflüsse einerseits auf der Basis von Vereinbarun-
gen zwischen dem Sender und dem Empfänger ausgelöst und andererseits aufgrund von kurz-
fristig aufgetretenen Engpasssituationen zur Abstimmung eingesetzt werden. Somit lassen sich
die dispositiven Informationsflüsse in vereinbarte und „Ad hoc“-Informationsflüsse unter-
scheiden. Vereinbarte dispositive Informationsflüsse stellen verbindliche Bedarfe bzw. Ange-
bote an die vor- bzw. nachgelagerten Dispositionseinheiten dar, die durch im Vorfeld zu
treffende Absprachen in ihrer Form und ihrem Inhalt an die Anforderungen des Empfängers
angepasst sind.108 Dagegen bieten „Ad hoc“-Informationsflüsse die Möglichkeit, auf unerwar-
tete Änderungen109 zu reagieren und ggf. erforderliche Abstimmungen mit den betroffenen
104. Ende bzw. Anfang einer Schicht.105. Intervall zwischen zwei Schichten.106. Als Quantitätstypen können, wie in Kapitel 5.1.4.2 angegeben, relative, absolute und kumulierteQuantitäten unterschieden werden.107. Vgl. Kapitel 5.1.5.108. Vgl. Kapitel 5.2.2.3.109. Z.B. Kurzfristige Bedarfsänderung aufgrund eines Maschinenausfalls.
Kapitel 5: Konzeption 115
Dispositionseinheiten vorzunehmen.110 Auslöser für die „Ad hoc“-Informationsflüsse, und
damit Ausgangsbasis für die Abstimmungsprozesse, sind Mengen- und/oder Terminänderun-
gen bezüglich bereits zugeordneter Bedarfe bzw. Angebote. Dabei ist bezüglich der betrachte-
ten Dispositionseinheit zwischen internen und externen Änderungsereignissen zu
unterscheiden.
Bei einem internen Änderungsereignis sind zunächst die Auswirkungen auf den geplanten Fer-
tigungsablauf zu bestimmen, um ggf. die Abstimmungen mit den betroffenen Dispositionsein-
heiten zu initiieren. Wenn dagegen ein externes Änderungsereignis, aus der Sicht der
betrachteten Dispositionseinheit, in einer direkt benachbarten Dispositionseinheit auftritt, führt
dies zu Änderungen der Zu- oder Abgänge und damit ggf. zur Umänderung des geplanten Fer-
tigungsablaufs in der betrachteten Dispositionseinheit. In diesem Fall gilt es zu überprüfen, ob
eine Abstimmung mit weiteren direkt benachbarten Dispositionseinheiten erforderlich ist. In
Abhängigkeit von der Auswirkung auf die mit den Kunden bzw. Lieferanten vereinbarten Lie-
ferungen lassen sich grundsätzlich die in Abbildung 36 dargestellten grundsätzlichen Typen
von Änderungsereignissen unterscheiden.
Um Abstimmungen über die in Abbildung 36 definierten Auswirkungen der Änderungsereig-
nisse beschreiben zu können, werden im Folgenden die dispositiven Informationsflüsse in die
Typen „Anforderung“, „Anfrage“, „Gegenvorschlag“, „Zustimmung“, „Ablehnung“ und
„Bestätigung“ unterteilt. Dabei charakterisiert eine „Anforderung“ bzw. eine „Anfrage“ einen
verbindlichen bzw. unverbindlichen Informationsfluss (Bedarf oder Angebot) und stellt die
Auslösung des Abstimmungsprozesses dar. Eine Reaktion auf eine „Anforderung“ oder
„Anfrage“ kann in Form einer „Zustimmung“, „Ablehnung“ oder eines „Gegenvorschlags“
110. Durch die „Ad hoc“-Informationsflüsse lässt sich das Ziel einer verbesserten Reaktionsfähigkeit ent-lang der Lieferkette besser erreichen (vgl. Anforderungen in Kapitel 2.2.2).
Men
ge
Termin
=
-+
< >=
(erhöht)
(verringert)
(früher)(unverändert) (später)
(unverändert)
Abbildung 36: Änderungsereignisse der Bedarfe bzw. Angebote
116 Kapitel 5: Konzeption
erfolgen. Dabei stellt der „Gegenvorschlag“ eine Verfeinerung einer direkt vorausgegangenen
„Anforderung“ oder eines weiteren „Gegenvorschlags“ dar. Eine „Bestätigung“ erfolgt im
Anschluss an eine „Zustimmung“ und soll somit gewährleisten, dass beide Seiten denselben
Vereinbarungsbedingungen zugestimmt haben.111
5.2.2.2.3 Instruktive Informationsflüsse
Die instruktiven Informationsflüsse umfassen alle Informationsflüsse, die nicht den vorherigen
beiden Typen zugeordnet werden können. Ein instruktiver Informationsfluss hat einerseits kei-
nen direkten Einfluss auf den aktuellen Stand der Planung in der empfangenden Dispositions-
einheit, andererseits kann er aber zur Verstärkung der Kooperation und somit ggf. zur
Planungssicherheit beitragen. Inhaltlich kann ein instruktiver Informationsfluss sowohl aus
strukturierten als auch unstrukturierten Daten bestehen. So kann ein instruktiver Informations-
fluss beispielsweise aus strukturierten Daten in Form von Kennzahlen über die Durchlaufzei-
ten, Kapazitätsauslastungen oder Vergangenheitsrückmeldungen bestehen oder unstrukturierte
Daten in Form von Mitteilungen über eventuelle Kapazitätsengpässe in der Zukunft oder
Erläuterungen bestimmter Entscheidungen beinhalten. Weiterhin lassen sich die instruktiven
Informationsflüsse, als Ergänzung zu den dispositiven Informationsflüssen, zur Unterstützung
von Abstimmungsprozessen einsetzen.
5.2.2.3 Individuelle Gestaltung der Informationsflüsse
In diesem Abschnitt werden die Merkmale betrachtet, die zur Gestaltung der Informations-
flüsse zwischen zwei Dispositionseinheiten maßgeblich sind. Ziel dabei ist es, durch die indi-
viduelle Gestaltung der dispositiven und instruktiven Informationsflüsse die bestehenden
unterschiedlichen Kooperationsbeziehungen zu den Dispositionseinheiten der Lieferkette
unterschiedlich abbilden zu können.112
In Anlehnung an [Schmi99]113 und [Männ96]114 lassen sich die Merkmale und Ausprägungen
der Kooperationsformen grundsätzlich zwischen einem hierarchischen und einem marktlichen
Beziehungssystem unterscheiden. Dabei stellt das Koordinationsinstrument selbst das aussa-
gekräftigste Charakteristikum dar. So verlaufen die Ausprägungen des Merkmals Koordina-
tion von der weisungsgebundenen Koordination, wie sie in hierarchisch organisierten
111. Vgl. Kapitel 8.3.112. Vgl. Anforderungen in Kapitel 2.2.2.113. S. 36f.114. S. 50ff.
Kapitel 5: Konzeption 117
Beziehungen anzutreffen ist, bis zur Koordination durch das Angebot, wie sie in marktlichen
Beziehungen überwiegend vorkommt. Im Bezug auf die Gestaltung der vereinbarten dispositi-
ven Informationsflüsse korrelliert das Merkmal Koordination damit, von welcher Seite115 der
Informationsfluss angestoßen wird. Hierbei lassen sich grundsätzlich die beiden Mechanismen
Push und Pull unterscheiden.116 Beim Pull-Mechanismus geht der Anstoß des Informations-
flusses von der Senke aus. Dazu nimmt sie zunächst Verbindung mit der Quelle auf und veran-
lasst, dass der entsprechende Informationsfluss initiiert wird. Beim Push-Mechanismus stößt
dagegen die Quelle den Informationsfluss an, ohne dass eine explizite Aufforderung von der
Senke vorliegt (vgl. Abbildung 37117). Durch die Pull-/Push-Mechanismen lassen sich Wei-
sungsabhängigkeiten zwischen zwei Dispositionseinheiten abbilden. So ermöglicht die Gestal-
tung des dispositiven Informationsflusses über den Push-Mechanismus die Realisierung von
Kooperationsbeziehungen, in denen eine Dispositionseinheit die dominantere Position ein-
nimmt. Hingegen zielt der Pull-Mechanismus auf die Gleichstellung der Beteiligten in der
Kooperationsbeziehung ab.
Ein weiteres wesentliches Merkmal einer Kooperationsbeziehung stellt die schnelle Reaktions-
und Anpassungsfähigkeit und damit die Stabilität der organisatorischen Kopplung dar.118 Die
Ausprägungen dieses Merkmals verlaufen von als starr zu bezeichnenden Beziehungen bei
hierarchisch organisierten Kooperationen bis hin zu flexibel gestaltbaren Beziehungen bei
marktlich organisierten Kooperationen.
In Bezug auf die Gestaltung der vereinbarten dispositiven Informationsflüsse korrespondiert
die Reaktions- und Anpassungsfähigkeit mit der Auslösungsart des Informationsflusses. Die115. Quelle oder Senke.116. Analog zu den in Kapitel 3.2 in Bezug auf den Materialfluss aufgeführten Push-/Pull-Prinzipien.117. Hier wird der dem Materialfluss entgegengesetzte Informationsfluss betrachtet .118. Vgl. [Schmi99], S. 18 und [Powe90], S. 303.
Push
Pull
QuelleSenke
Materialfluss
Abbildung 37: Push-/Pull-Mechanismen des Informationsflusses
118 Kapitel 5: Konzeption
Auslösungsart legt den Moment fest, in dem der Informationsfluss zwischen zwei Dispositi-
onseinheiten stattfindet und hat somit maßgeblichen Einfluss auf die Systemreaktion. Dazu
werden im Folgenden drei grundsätzliche Erscheinungsformen der Auslösungsarten unter-
schieden: die manuelle, ereignisbasierte und zeitbasierte Auslösungsart. Bei der zeitbasierten
Auslösungsart wird der Informationsfluss zu a priori festgelegten Zeitpunkten initiiert.119
Dagegen setzt die ereignisbasierte Auslösungsart die Spezifikation von Ereignissen voraus, bei
deren Auftreten der Informationfluss erst ausgelöst wird.120 Bei der manuellen Auslösungsart
erfolgt die Initiierung des Informationsflusses auf Entscheidung des Disponenten und damit
nach Bedarf.121 Insgesamt weisen die ereignisbasierten und manuellen Auslösungsarten einen
flexiblen Charakter auf, während die zeitbasierte Auslösungsart als eher starr zu bezeichnen
ist.
Ein weiteres Charakterisierungsmerkmal der Beziehungen zwischen den Dispositionseinheiten
stellt die Kooperationsausrichtung dar. Während hierarchische Beziehungen eher langfristig122
angelegt sind, werden marktliche Beziehungen dagegen als kurzfristig bezeichnet. Hierzu las-
sen sich bei der Gestaltung der dispositiven Informationsflüsse der Zeithorizont und die zeitli-
che Granularität festlegen, auf die sich der Informationsfluss bezieht. Je nach
Kooperationsausrichtung unterstützt ein langer Horizont eher den Charakter einer langfristigen
Beziehung, während ein kurzer Horizont eher den Charakter einer kurzfristigen Beziehung
aufzeigt. Die Granularität erlaubt es, den Detaillierungsgrad der Informationsflüsse zu verän-
dern. Dadurch können von Vertrauen geprägte langfristige Beziehungen eher durch einen
höheren Detaillierungsgrad als kurzfristige Beziehungen unterstützt werden. Abbildung 38
119. Vgl. Bestellzyklus in Kapitel 5.2.1.120. Die Spezifikation der Ereignisse kann durch Mengen- und/oder Terminrestriktionen erfolgen, bei-spielsweise durch das Erreichen des Meldebestandes (vgl. Abbildung 33).121. Beispielsweise nach der Erstellung eines Belegungsplans.122. Da sie häufig innerbetrieblich bestehen.
Kapitel 5: Konzeption 119
stellt die Zuordnung der Kooperationsmerkmale zu den aufgeführten Gestaltungsmerkmalen
der dispositiven Informationsflüsse dar.
Neben den oben aufgeführten Merkmalen sind bei der individuellen Gestaltung der dispositi-
ven Informationsflüsse der sachliche Bezug123, die Quantitätstypen sowie die kunden- bzw.
lieferantenspezifischen Vorlaufzeiten zu berücksichtigen. Die Ausprägungen der Gestaltungs-
merkmale dispositiver Informationsflüsse sollten auf jeder Seite einer Wertschöpfungsbezie-
hung festgelegt werden. Damit können die Informationsflüsse entsprechend den
Vereinbarungen zwischen den betroffenen Dispositionseinheiten gestaltet werden. Abbildung
39 fasst die Gestaltungsmerkmale individueller dispositiver Informationsflüsse zusammen.
Weiterhin lässt sich durch die instruktiven Informationsflüsse der Informationsbedarf einer
vor- bzw. nachgelagerten Dispositionseinheit erfüllen. Dazu sind zunächst individuelle Sichten
auf das Fertigungsgeschehen zu erstellen, in denen die gewünschten Informationen gesammelt
werden können. Eine Sicht besteht dabei aus einem oder mehreren Attributen, wobei jedes
123. Vgl. Kapitel 5.2.2.2.2.
Auslösungsart
HorizontBeziehungen langfristigkooperativ
kurzfristigkompetitiv Granularität
Push-/Pull-PrinzipKoordination Weisung Angebot
Systemreaktion starr flexibel
Kooperations- HierarchieMarkt
Gestaltungs-merkmaleInitiator
Horizont
Systemreaktion
Koordination
Beziehungen
starr
Weisung
langfristig
flexibel
Angebot
kurzfristigGranularität
merkmale
Abbildung 38: Umsetzung der Kooperationsmerkmale durch die Gestaltung der Informationsflüsse
Auslösungsart
Abbildung 39: Gestaltungsmerkmale individueller Informationsflüsse
Merkmale Ausprägungen
Sachlicher Bezug Faktorart
Granularität
Horizont
Auslösungsart
Initiator
Quantitätstyp
Manuell Ereignisbasiert
Ressource
PullPush
Periodisch
Schicht Woche
Relativ
n ℵ∈
Tag
Absolut Kumuliert
120 Kapitel 5: Konzeption
Attribut wiederum eine (verdichtete) Information über das Fertigungsgeschehen in der
betrachteten Dispositionseinheit darstellt.124
5.2.2.4 Konstrukte zur Durchführung von Interaktionen
In diesem Abschnitt sollen, auf der Basis der in Kapitel 5.2.2.1 ausgewählten Form des Infor-
mationsaustausches und den in Kapitel 5.2.2.2 definierten Informationsflusstypen, Konstrukte
hergeleitet werden, die die Beschreibung der Informationsflüsse in Form von Interaktionen
ermöglichen. Dabei wird der Informationsfluss in Form von Nachrichten durch „Sende“- und
„Empfange“-Operationen125 realisiert. Dazu sollen einerseits die Formate der den Informati-
onsflusstypen (vgl. Abbildung 40) zugeordneten Nachrichten und andererseits Konstrukte zur
Beschreibung der Interaktionen bestimmt werden.
Eine durch „Sende“- bzw. „Empfangs“-Operationen übertragene Nachricht besteht im Allge-
meinen aus mehreren Parametern. Hierbei hängt die Anzahl und Art der Parameter vom Infor-
mationsflusstyp ab, der durch die Nachricht realisiert wird. Unabhängig vom
Informationsflusstyp umfasst jede Nachricht die folgenden Parameter:
- Sender_ID: enthält die Dispositionseinheit, die die Nachricht versendet hat,
- Empfänger_ID: gibt die Dispositionseinheit an, an die die Nachricht adressiert ist,
124. Vgl. Kapitel 5.3.5.2.125. Vgl. Abbildung 35.
Instruktiv
Administrativ
Dispositiv„Ad hoc“
Informationsfluss
Aufbau der Beziehung
Abbau der Beziehung
Abbildung 40: Informationsflusstypen
Modifikation der Beziehung
Vereinbarter InformationsflussAnforderung
ZustimmungAblehnung
GegenvorschlagAnfrage
Bestätigung
Kapitel 5: Konzeption 121
- Nachricht_ID: eindeutige Identifikation der Nachricht126,
- Nachrichtentyp: spezifiziert den Nachrichtentyp und damit die Anzahl und Art der zuübertragenden Parameter.
In Abhängigkeit vom Informationsflusstyp lassen sich weitere unterschiedliche Parameter für
die Nachrichten spezifizieren. Da bei den administrativen Informationsflüssen die Verwaltung
der Interdependenzen und die Gestaltung der dispositiven Informationsflüsse im Vordergrund
stehen, bilden die Faktorart und die damit verbundenen Interdependenzen127 bzw. Gestal-
tungsmerkmale128 dispositiver Informationsflüsse die Parameter der Nachrichten ab. Während
zum Aufbau bzw. zur Modifikation der Beziehungen die vollständige Anzahl der Parameter
benötigt wird, ist zum Abbau der Beziehung nur die Spezifikation der Faktorart erforderlich.
Bei den instruktiven Informationsflusstypen sollen, aufgrund der unterschiedlichen möglichen
Inhalte und des Strukturierungsgrades, die zu übertragenden Informationen durch einen textu-
ellen Parameter weitergegeben werden können.
Bei den dispositiven Informationsflusstypen sind, aufgrund ihrer Koordinationsfunktion der
Leistungserstellung, der sachliche und der zeitliche Bezug sowie die Quantität als Parameter
mitzuführen.129 Darüber hinaus sind für die Nachrichten der dispositiven Informationsflussty-
pen, die eine Art Rückmeldung darstellen, wie Gegenvorschlag, Zustimmung, Ablehnung oder
Bestätigung, Referenzen auf die ursprünglichen Nachrichten als Paramater erforderlich.130
Im Folgenden soll zur Festlegung der syntaktisch zulässigen Interaktionen im Rahmen von
Verhandlungen dispositiven Inhaltes eine Grammatik131 G definiert werden, aus der die
Menge L(G) der möglichen Vereinbarungen erzeugt werden kann.
Mit G={T, V, S, P} lässt sich die Grammatik G beschreiben, wobei gilt:
• T={Anfrage, Anforderung, Zustimmung, Ablehnung, Bestätigung, Gegenvorschlag} ist die
Menge aller Terminalsymbole.
Mit diesen Terminalsymbolen sollen die dispositiven Informationsflusstypen abgebildet wer-
den können. So sollen durch das Terminalsymbol Anforderung sowohl die vereinbarten Infor-
126. Eine Nachricht ist global über die Nachricht_ID, Sender_ID und Empfänger_ID eindeutig.127. Vgl. Kapitel 5.2.1.128. Vgl. Kapitel 5.2.2.3.129. Vgl. Kapitel 5.2.2.2.2.130. Durch einen Verweis auf die Nachricht_ID.131. Zur formalen Definiton einer Grammatik (vgl. [Wege93] und [Chom56]).
122 Kapitel 5: Konzeption
mationsflüsse als auch die ad hoc aufgetretenen Anforderungen (Angebote bzw. Bedarfe)
beschrieben werden können. Die restlichen Terminalsymbole sind den übrigen „Ad hoc“-
Informationsflusstypen zuzuordnen (vgl. Abbildung 40).
• V={S, A, B} ist die Menge der nicht Nichtterminalsymbole(Variablen).
• S stellt das Startsymbol dar.
• P={ , , ,
, , ,} die Menge der Ableitungsregeln (Produktionen).
S AnforderungA→ S AnfrageB→ A ZustimmungBestätigung→
A Ablehnung→ A GegenvorschlagB→ B Zustimmung→B Ablehnung→
Kapitel 5: Konzeption 123
5.3 Architektur des Fertigungsmanagement-Informationssystems
In diesem Abschnitt wird die Architektur1 des Informationssystems für eine flexible2 Gestal-
tung des operativen Fertigungsmanagements entlang der Lieferkette entworfen. Ziel hierbei ist
nicht die Entwicklung eines vollständigen ERP/PPS-Systems für die Lieferkette. Vielmehr
geht es darum, das in der Dispositionseinheit ggf. eingesetzte ERP/PPS-System um die zur
Lösung der in der Problemstellung erforderlichen Komponenten zu ergänzen. Das daraus ent-
stehende Fertigungsmanagement-Informationssystem (FMIS) soll einerseits die Transparenz
der Abläufe innerhalb der Dispositionseinheit und andererseits die flexible Gestaltung und
Steuerung der Informationsflüsse zu den anderen Dispositionseinheiten in der Lieferkette
unterstützen. Ein Überblick über die Architektur des Gesamtsystems sowie eine kurze
Beschreibung der einzelnen Komponenten des Systems erfolgen in Kapitel 5.3.1. In Kapitel
5.3.2 wird die Lieferkette in einem Pilotwerk eines Automobilzulieferers vorgestellt; aus den
Komponenten der Lieferkette werden Dispositionseinheiten gebildet. In den Kapiteln 5.3.3 bis
5.3.5 findet eine detailliertere Betrachtung der Struktur der einzelnen Komponenten statt.
Dabei werden die Anwendungsmöglichkeiten der Komponenten am Beispiel der Lieferkette
im Pilotwerk verdeutlicht.
5.3.1 Komponenten der Systemarchitektur
Das hier zu entwickelnde System soll als dezentrale Einheit in einer bzw. in mehreren Disposi-
tionseinheiten eingesetzt werden können. Die lokalen Einheiten des Systems sollen die lokale
Planung der fertigungsrelevanten Abläufe unterstützen und die Abstimmung mit den direkt
benachbarten Dispositionseinheiten ermöglichen. In Abbildung 41 ist der grobe Aufbau einer
lokalen Einheit aufgeführt. Dabei werden die einzelnen Komponenten einer lokalen Einheit
über eine zentrale Datenverwaltungskomponente verbunden. Die Datenverwaltungskompo-
nente setzt sich aus einer Datenbasis und dem beschreibenden Datenmodell sowie den entspre-
chenden Zugriffsfunktionen zusammen. Da die Aufgabe der Datenverwaltungskomponente im
Wesentlichen darin besteht, „Dienste“ für die anderen Komponenten bereitzustellen, soll eine
1. Eine Architektur ist ein Organisationsprinzip, welches einem aus einer Anzahl an Elementen bestehen-den System eine (innere) Struktur gibt. Es stellt damit ein Modell des zu erzeugenden (bzw. zu implemen-tierenden) Systems mit seinen Systemelementen und ihren strukturalen Beziehungen dar (vgl. [Henk97]). 2. Unter Flexibilität wird allgemein das Vorhandensein von Freiräumen oder Handlungsspielräumen de-finiert (vgl. [Rupp94]). Bezogen auf ein System kann die Flexibilität daher als Anpassungsfähigkeit desSystems an unterschiedliche Bedingungen definiert werden. Flexibilität ist besonders von Bedeutung,wenn sich das Umfeld und damit auch die Anforderungen an das System im Zeitablauf ändern.
124 Kapitel 5: Konzeption
Beschreibung der Funktionalität der Datenverwaltungskomponente nur im Zusammenhang mit
den anderen Komponenten erfolgen.
Der Stammdatenmanager umfasst Komponenten zur Spezifikation und Verwaltung der im
FMI-System abzubildenden Dispositionseinheiten und deren fertigungsrelevante Eigenschaf-
ten. Dazu bietet es u.a. Editoren an, die es ermöglichen sollen, einerseits die entsprechenden
Erzeugnis-, Ressourcen- und Transformationsstrukturen anzulegen und andererseits die Infor-
mationsflussbeziehungen zu den benachbarten Dispositionseinheiten zu beschreiben. Um den
manuellen Aufwand bei der Pflege der Stammdaten so gering wie möglich zu halten, soll die
Möglichkeit bestehen, ausgewählte Daten aus dem ERP/PPS-System, falls dort vorhanden,
über den Schnittstellenmanager zu übernehmen.
Die Aufgabe des Bewegungsdatenmanagers besteht in Abhängigkeit von den im Stammdaten-
manager spezifizierten Eigenschaften der Dispositionseinheit darin, den Disponenten adäquate
Informationen bereitzustellen, die die bisherigen und zukünftigen Entwicklungen des Ferti-
gungsgeschehens aufzeigen. Dazu soll er neben der Funktionalität der Belegungs- und Reihen-
folgeplanungen Komponenten zur Darstellung und Bewertung der Planungsergebnisse sowie
zum Bestandsmanagement bereitstellen. Die dafür notwendigen Informationen über Zu- und
Abgänge sowie über Bestandsumbuchungen3 innerhalb einer Dispositionseinheit sollen über
den Schnittstellenmanager aus dem ERP/PPS-System4 importiert bzw. manuell erfasst werden
können. Weiterhin sollen über den Schnittstellenmanager die Ergebnisse der Belegungs- und
Reihenfolgeplanung dem ERP/PPS-System mitgeteilt werden können.5
Der Kooperationsmanager6 besteht aus zwei Komponenten, die basierend auf den im Stamm-
datenmanager festgelegten Beziehungen (Informationsprofile) zu den direkt benachbarten Dis-
positionseinheiten die Abwicklung der Informationsflüsse unterstützen können. Die erste
Komponente stellt Konstrukte zur Interaktion zwischen zwei dezentralen Einheiten des FMI-
Systems bereit und ermöglicht dadurch die Realisierung des Informationsflusses zwischen
zwei Dispositionseinheiten, die jeweils über ein FMI-System verfügen. Die zweite Kompo-
nente stellt eine Art WWW-Schnittstelle dar, die benachbarten Dispositionseinheiten ermög-
licht, Informationen über das Fertigungsgeschehen via WWW zu beziehen.
3. Z.B. Bestandskorrektur durch eine Inventur oder geplante Zubuchungen.4. Und des zugehörigen Betriebsdatenerfassungssystems (BDE).5. Beispielsweise können die Ergebnisse der Maschinenbelegungsplanung für die Ermittlung der Sekun-därbedarfe verwendet werden.6. Zu den Einsatzmöglichkeiten des Kooperationsmanagers siehe die Szenarien in Abbildung 42.
Kapitel 5: Konzeption 125
D a t e n m o d e l l
D a t e n b a n k
D a t e n v e r w a l t u n g
I n t e r f a c e
z u rInternet/
ERP/PPS-System
Stammdaten-manager
Schnittstellen-manager
Kooperations-manager
Bewegungsdatenmanager
Abbildung 41: Schematischer Aufbau der Architektur
Intranet
Kunde
Zulieferer
126 Kapitel 5: Konzeption
Die fertigungsrelevanten Informationsflüsse zwischen zwei benachbarten Dispositionseinhei-
ten lassen sich in Abhängigkeit vom Integrationsgrad der ggf. in den beiden Dispositionsein-
heiten eingesetzten ERP/PPS-Systeme auf verschiedene Weise realisieren. Einerseits sollen
mit dem FMI-System über den Kooperationsmanager via Inter- bzw. Intranet fertigungsrele-
vante Informationen mit den benachbarten Dispositionseinheiten ausgetauscht werden können,
andererseits sollen evtl. bereits über die ERP/PPS-Systeme realisierten Kommunikationsver-
bindungen genutzt werden können. Die folgenden Szenarien verdeutlichen diesen Sachverhalt.
Szenario A:
In diesem Szenario arbeiten beide Dispositionseinheiten auf demselben ERP/PPS-System.7
Dadurch ergeben sich die in der linken Hälfte der Abbildung 42 gezeigten Integrationsmög-
lichkeiten:
Im Fall A.1 werden die Dispositionseinheiten in einer gemeinsamen FMIS-Datenbank abgebil-
det und können den Austausch der fertigungsrelevanten Daten über die gemeinsame Datenba-
sis realisieren. Dieser Fall eignet sich für Dispositionseinheiten, die im gleichen Werk
existieren, insbesondere wenn der Abstimmungsbedarf so gering ist, dass der Bedarf über
mündliche Absprachen zwischen den Disponenten bewerkstelligt werden kann.
Werden die Dispositionseinheiten dagegen in unterschiedlichen FMIS-Datenbanken abgebil-
det, so können die Informationsflüsse entweder indirekt über das ERP/PPS-System, wie im
Fall A.2 skizziert ist, oder direkt über das Intra- bzw. Internet (Fall A.3) durchgeführt werden.
Der Aufwand für die Realisierung der im Fall A.2 skizzierten Lösung hängt sehr stark vom
eingesetzten ERP/PPS-System ab. Fall A.3 eignet sich sowohl für die Gestaltung werksinter-
ner als auch für werksübergreifende Informationsflüsse zwischen den Dispositionseinheiten.8
7. Gemeint ist hier dieselbe Installation des ERP/PPS-Systems.8. Z.B. In einem Konzern, wo mehrere Standorte existieren, aber nur eine zentrale ERP/PPS-Installationexistiert oder in einem Unternehmensverbund mit einem gemeinsamen ERP/PPS-System (bei einem Lo-gistikdienstleister).
Kapitel 5: Konzeption 127
Szenario B:
In der rechten Hälfte der Abbildung 42 werden die Fälle aufgezeigt, bei denen unterschiedliche
ERP/PPS-Systeme in den Dispositionseinheiten eingesetzt werden.
Im Fall B.1 lassen sich die Informationsflüsse zwischen den Dispositionseinheiten über die
Kopplung der ERP/PPS-Systeme verwirklichen, allerdings ist die Realisierung einer solchen
Lösung, wie in Kapitel 2.1.2 gezeigt wurde, häufig mit einem hohen Aufwand verbunden.
Fall B.2 zeigt eine Situation auf, in der sowohl eine Kommunikationsverbindung zwischen den
ERP/PPS-Systemen als auch eine Installation des FMI-Systems in der Dispositionseinheit B
fehlt. In einem solchen Fall kann der Dispositionseinheit B über das World Wide Web der
ERP/PPS-System
Dispositionseinheit A Dispositionseinheit B
ERP/PPS-System
Dispositionseinheit A Dispositionseinheit B
Internet/Intranet
ERP/PPS-System
Dispositionseinheit A Dispositionseinheit B
Fall A.1
Fall A.2
Fall A.3
Dispositionseinheit A Dispositionseinheit B
Internet/Intranet
ERP/PPS-SystemERP/PPS-System
Fall B.2
Dispositionseinheit A Dispositionseinheit B
ERP/PPS-SystemERP/PPS-System
Fall B.1
Fall B.3
Dispositionseinheit A Dispositionseinheit B
Internet/Intranet
ERP/PPS-System ERP/PPS-System
Abbildung 42: Szenarien zur informationstechnischen Integration der Dispositionseinheiten
128 Kapitel 5: Konzeption
Zugang zu ausgewählten Fertigungsdaten in der Dispositionseinheit A gewährt werden.9 Fall
B.3 lässt sich analog zu Fall A.3 beschreiben, allerdings mit der Einschränkung, dass sich
unterschiedliche Installationen der ERP/PPS-Systeme in den Dispositionseinheiten befinden.
5.3.2 Fallbeispiel eines Automobilzulieferers
5.3.2.1 Ausgangssituation
Im betrachteten Pilotwerk des Automobilzulieferers werden hauptsächlich Bremssättel, Trom-
melbremsen, Bremszylinder und Bremsschläuche hergestellt. Wichtigstes Enderzeugnis sind
Bremssättel, von denen ca. 2,5 Millionen pro Jahr ausgeliefert werden.10 Der Fertigungsbe-
reich ist in den „Small Series“-Bereich und den „High Volume“-Bereich unterteilt. Aufgrund
der hohen Stückzahlen im „High Volume“-Bereich beschränken sich im Folgenden die Unter-
suchungen auf diesen Fertigungsbereich.
Die Erzeugnisse im „High Volume“-Bereich sind die Original Equipment Manufacturing
(OEM) Bremsen und Handbremsen. Diese Erzeugnisse werden direkt an die Automobilher-
steller geliefert und als Ausstattungskomponenten verwendet. Weitere wichtige Abnehmer der
Enderzeugnisse sind konzerninterne Schwesterwerke. Letztere sorgen teilweise für eine nicht
unerhebliche Stückzahl, da ein Schwesterwerk beispielsweise die Nachfrage eines sonst exklu-
siv belieferten Kunden nicht befriedigen kann.11 Zur Charakterisierung des zu untersuchenden
Fertigungsbereichs ist in Tabelle 8 eine Einordnung in den betriebstypologischen Kasten12
vorgenommen worden, wobei die treffenden Merkmalsausprägungen gekennzeichnet sind.
9. Ein solcher Fall findet z.B. Anwendung bei kurzfristigen Kunden-Lieferanten-Beziehungen oder bei-spielsweise für die Anbindung kleinerer Zulieferer.10. Stand 1998.11. Diese Kapazitätsengpässe häufen sich in letzter Zeit aufgrund der seit Jahren unverhältnismäßig starkansteigenden Nachfrage.12. Vgl. [Scho80].
Kapitel 5: Konzeption 129
Tabelle 8: Betriebstypologie des Pilotwerkes
Das betrachtete Pilotwerk zeichnete sich durch eine hervorragende Qualität13 der Erzeugnisse
und eine höhere Liefertreue aus. Diese Eigenschaften haben bislang zu einer hohen Kundenzu-
friedenheit beigetragen. Ziel der Unternehmensführung war es, einerseits diesen Wettbewerbs-
vorteil trotz des verschärften Konkurrenzdrucks beizubehalten und andererseits das
Fertigungsvolumen innerhalb der nächsten vier Jahre zu verdoppeln, ohne dabei eine Erweite-
rung der Fertigungsstätten vorzunehmen. Dies erfordert einen effizienten Materialfluss und
insbesondere eine kleinstmögliche Lagerfläche. Daraus resultiert die Forderung nach der
Reduzierung der Bestände an End- und Zwischenerzeugnissen in der innerbetrieblichen Lie-
ferkette. Weiterhin wird davon ausgegangen, dass die bisher vorhandenen Ressourcen weitge-
hend bestehen bleiben und nur geringfügig aufgestockt werden können. Daher soll die
Erweiterung des Fertigungsvolumens primär durch eine bessere Gestaltung der Material- und
Informationsflüsse entlang der Lieferkette ermöglicht werden. Ferner sollte die Transparenz
Merkmal Merkmalsausprägung
Erzeugnis-spektrum
Erzeugnisse nach Kundenspezifika-
tion
typisierte Erzeug-nisse mit kunden-
spezifischen Varianten
Standarderzeug-nisse mit Varian-
ten
Standarderzeug-nisse ohne Vari-
anten
Erzeugnis-struktur
Einteilige Erzeugnisse
mehrteilige Erzeugnisse mit einfacher Struk-
tur
mehrteilige Erzeugnisse mit
mehrfacher Struk-tur
-
Auftragsaus-lösungsart
Produktion auf Bestellung mit Einzelaufträgen
Produktion auf Bestellung mit Rahmenaufträ-
gen
Produktion auf Lager -
Dispositions-art
kundenauftrags-orientiert
überwiegend kundenauftrags-
orientiert
überwiegend pro-grammorientiert
programmorien-tiert
Beschaffungs-art
Fremdbezug unbedeutend
Fremdbezug in größerem Umfang
weitestgehend Fremdbezug -
Fertigungsart EinmalfertigungEinzel- und Klein-
serienfertigungSerienfertigung Massenfertigung
Fertigungsab-laufart
Baustellenferti-gung
Werkstattferti-gung
Gruppen-/Lini-enfertigung
Fließfertigung
Fertigungs-struktur
Fertigung mit geringer Tiefe
Fertigung mit mittlerer Tiefe
Fertigung mit gro-ßer Tiefe -
13. Insbesondere durch die für Bremshersteller notwendige Forderung nach „Zero Defects“ (vgl.[BiBB99], S. 27).
130 Kapitel 5: Konzeption
des Fertigungsgeschehens verbessert werden, um den Disponenten die grundlegenden Infor-
mationen für ihre Entscheidungsfindung zu liefern.
Zur Unterstützung der Umsetzung der Ziele wurde beschlossen, ein Fertigungsmanagement-
Informationssystem einzuführen. Dazu wurde eine IST-Analyse der Material- und Informati-
onsflüsse durchgeführt, um Verbesserungspotentiale aufzuzeigen.
Der Materialfluss im zu untersuchenden Fertigungsbereich kann durch das in Abbildung 43
vereinfachte Fertigungsprozessmodell dargestellt werden.14 Der Fertigungsablauf lässt sich als
Fließfertigung über mehrere Fertigungsstufen mit alternativen Betriebsmitteln je Erzeugnis
charakterisieren. Das Rohmaterial wird zunächst in der ersten Fertigungsstufe zu den Rohtei-
len Gehäuse (Housing) und Halter (Holder) „geräumt“. Diese Teile laufen dann alternativ die
Arbeitsgänge „Bohren“ bzw. „Bohren und Gewindeschneiden“ und den anschließenden
„Finishing“-Vorgang durch.15 Dann werden die „spanend bearbeiteten“ Erzeugnisse auf einer
Galvanik veredelt. Auf den letzten Fertigungsstufen werden die Erzeugnisse dann inspiziert
und zu Bremssätteln montiert. Abweichend von diesem „Standardfluss“ gibt es Erzeugnisse,
die bestimmte Fertigungsprozesse überspringen. So werden z.B. bestimmte Erzeugnisse
unmittelbar nach dem „Räumen“ oder nach der „spanenden Bearbeitung“ direkt an die Monta-
gelinien weitergeleitet, ohne dass eine „Veredelung“ erfolgt. Außerdem besteht die Möglich-
keit, dass Gehäuse und/oder Halter an Schwesterwerke ausgeliefert werden, ohne den
„Veredelungs-“ bzw. „Montage“- Prozess zu durchlaufen oder aber auch bereits „geräumt“
und/oder „spanend bearbeitet“ eingekauft zu werden.
Die Puffer vor und nach den Fertigungsprozessen dienen im Wesentlichen zur Synchronisation
des Materialflusses entlang der Lieferkette. Dabei wiesen insbesondere die Puffer vor und
nach dem Veredelungsprozess einen sehr hohen Anteil16 an Zwischenerzeugnissen auf.
Dadurch konnten einerseits der Materialfluss zwischen den Zerspanunglinien17 mit ihren län-
geren Zykluszeiten18 und den Montagelinien mit ihren kürzeren Zykluszeiten synchronisiert
und andererseits die häufig auftretenden kurzfristigen Schwankungen der Endkundenbedarfe
abgefangen werden. Dagegen wurden in den Puffern nach dem „Bohren und Gewindeschnei-
14. Eine ausführlichere Darstellung ist im Anhang 8.3 zu finden. 15. Dieser Arbeitsgang wird als „spanende Bearbeitung“ und die zugehörigen Ressourcen als „Zerspan-nungslinien“ bezeichnet.16. Hier waren Mindestbeständen von über 6.000 Teile pro Erzeugnisart die Regel.17. Linien der spanenden Bearbeitung.18. Kapazitätsfaktoren (vgl. Kapitel 5.1.4.1.3).
Kapitel 5: Konzeption 131
den“ sowie nach dem „Inspizieren“ kaum Zwischenlagerungen vorgenommen, da die Erzeug-
nisse ohne nennenswerte Verzögerungen an die nachgelagerten Prozesse weitergeleitet werden
konnten. Auch die Bestände in den Puffern vor und nach dem „Räumen“ sowie im Ausliefe-
rungslager bergen Verbesserungspotenziale, die jedoch bei weitem nicht mit den Puffern vor
und nach dem „Veredeln“ vergleichbar sind.
Um die angestrebte Transparenz des Fertigungsgeschehens zu gewährleisten, wurden unter-
schiedliche Erzeugnisarten, die ähnliche Eigenschaften19 aufweisen, zu einer Erzeugnisart
zusammengefasst. Dadurch wurde die Anzahl der unterschiedlichen Erzeugnisarten im
betrachteten Bereich auf ca. ein Drittel reduziert.
Die Informationsflüsse für die Planung und Steuerung der Fertigung wurden bisher überwie-
gend manuell und auf der Basis von Papierlisten durchgeführt. Zielsetzung dabei war stets,
möglichst flexibel auf die kurzfristig auftretenden Änderungen der Kundenbedarfe zu reagie-
ren. Eine solche Flexibilität war nur auf der Basis langjähriger Erfahrungen weniger Disponen-
ten zu erreichen. Die Situation wurde durch das Fehlen eines integrierten ERP/PPS-Systems20,
19. Z.B. Erzeugnisarten, die denselben Arbeitsplan haben, jedoch aufgrund unterschiedlicher Verwen-dungsmöglichkeiten unterschiedlich bezeichnet werden oder solch geringe technische Unterschiede auf-weisen, dass Umrüstungen zwischen den Erzeugnisarten nur eine „verschwindend geringe Zeit“ beanspruchen. 20. Es existierte zwar ein ERP/PPS-System, allerdings wurden die Module zur Planung und Steuerungder Fertigung aus „Handhabungsschwierigkeiten“ (z.B. nicht zeitgemäße Benutzerschnittstellen, die zuAkzeptanzproblemen führten) kaum eingesetzt.
(4 Linien)Räumen
Bohren u.Gewindes.
Inspizieren
Ext. Galvanik A(1 Linie)
Int. Galvanik(1 Linie)
Ext. Galvanik B(1 Linie)
Inspektionu. Montage(1 Linie)
(9 Linien)
Finis-hing
Abbildung 43: (Vereinfachtes) Fertigungsprozessmodell des Pilotwerkes
Bohren
(5 Linien)
(5 Linien)(5 Linien)
Veredeln
(1 Linie)
Montieren
Roh
teill
ager
Aus
liefe
rung
s-la
ger
132 Kapitel 5: Konzeption
welches eine durchgängige informationstechnische Unterstützung der Abläufe anbietet, ver-
schärft. So wurde der betrachtete Fertigungsbereich bisher in drei planungsmäßig voneinander
unabhängige Teilbereiche21 unterteilt, die durch Puffer mit ständig höheren Beständen gekop-
pelt waren. Der erster Planungsbereich umfasste die auf die Befriedigung der kurzfristigen
Kundenabrufe ausgerichtete Montageplanung und die daraus resultierende Qualitätskontroll-
planung.22 Der zweite Planungsbereich beinhaltete den Veredelungsplan, der wiederum auf
der Basis des Qualitätskontrollplanes generiert wurde. Der dritte Bereich befasste sich mit der
Planung der „spanenden Bearbeitung“ und des „Räumens“. Hierbei wurden die Fertigungs-
pläne sowohl auf der Basis von kurzfristigen Kundenabrufen als auch von mittelfristigen
Bedarfsprojektionen der Kunden abgeleitet (vgl. Abbildung 44).
Das zum Zeitpunkt der IST-Analyse eingesetzte ERP/PPS-System wurde im betrachteten Fer-
tigungsbereich im Wesentlichen zum einen für die (teilweise) Verwaltung der Daten über
Erzeugnisarten und Betriebsmittel und zum anderen für die Erfassung der Mengenrückmel-
dungen über die tatsächlich gefertigten Erzeugnisse und den Bedarfs- bzw. Liefermeldungen
von bzw. an den Kunden verwendet.
Die Bedarfsmeldungen der Kunden, die aus den kurzfristigen Abrufen und den mittelfristigen
Bedarfsprojektionen bestehen und erhebliche Differenzen hinsichtlich Zeitbasen und -hori-
zonte aufweisen, wurden per Telefax bzw. via EDI übermittelt. Die Übertragung in das ERP/
PPS-System erfolgte manuell. Dabei wurden die Bedarfsmeldungen einheitlich und rechne-
risch auf eine Wochenbasis gebracht bzw. kumuliert23 und dienten als Ausgangsbasis für die
Generierung der Fertigungspläne und des Sekundärbedarfes (vgl. Abbildung 44). Ausgehend
21. In den Teilbereichen wurde die Fertigung als Fließfertigung gestaltet, bei der allerdings eine hoheDurchlaufgeschwindigkeit erreicht werden konnte. 22. Inspektionsplan. Der Planungsablauf findet in entgegengesetzter Richtung zum Materialfluss statt.23. Eine solche Berechnung wurde kundenindividuell durchgeführt und basierte im Wesentlichen auf Er-fahrungen aus der Vergangenheit.
KurzfristigeKundenabrufe
MittelfristigeBedarfsprojektionen
Montage-planung M
onta
ge-
plan Qualitätsk.-
planungVeredelungs-planung
Planung der span.Bearbeitung
Planung desRäumens
Gal
vani
k-pl
an
Insp
ektio
ns-
plan
„Hof
fman
n“-
Plan
„Mac
hine
sho
p“-
Plan
Abbildung 44: (Grober) Informationsfluss bei der Planung
Kapitel 5: Konzeption 133
von diesen Informationen wurde täglich eine manuelle Planung der Auslieferungen an den
Kunden durchgeführt. Der hier generierte Auslieferungsplan dokumentiert die täglich ange-
strebten Liefermengen und -zeiten für einen Zeithorizont von zwei Wochen und bildete die
Vorgaben für den ersten Planungsbereich. Dort erfolgte zunächst unter Berücksichtigung der
verfügbaren Teams eine Planung der Montagelinien und die damit verbundene Qualitätskon-
trolle auf Tagesbasis. Anschließend wurde im Rahmen der Veredelungsplanung ausgehend
vom Montageplan überprüft, ob die interne Galvanik für die mengen- und zeitgemäße Fertig-
stellung der benötigen Erzeugnisarten einen Engpass darstellte und dadurch ggf. Aufträge an
die beiden externen Galvaniken weitergeleitet werden mussten.
Im dritten Planungsbereich wurden die Bedarfsmeldungen der Kunden für einen Zeithorizont
von 12 Wochen als Planungsvorgaben herangezogen. Zur Unterstützung der Planerstellung
wurde eine eigens hierfür entwickelte Anwendung24 auf der Basis von Lotus-1-2-3 einge-
setzt.25 Hierbei werden die Bedarfsmeldungen der ersten beiden Wochen auf Schichtbasis und
die restlichen 10 Wochen auf Wochenbasis geplant. Der hier erstellte Plan beruhte nicht direkt
auf den erzeugnisspezifischen Zykluszeiten und tatsächlichen Kapazitätsangeboten der
Maschinen, sondern auf erzeugnisunabhängigen Überschlagswerten, die sich auf langjährige
Erfahrungen stützten. So wurde für jede Maschine von einem Kapazitätsangebot von 850 Ein-
heiten pro Schicht26 ausgegangen, das um die Hälfte reduziert wurde, wenn ein Umrüstvor-
gang geplant war. Als zentrale Größe bei der Planung der spanenden Bearbeitung wurde,
neben den Bedarfsmeldungen der Kunden, die projizierte Bestandshöhe27 der spanend bear-
beiteten Einheiten eines Erzeugnisses betrachtet.
Um eine ausreichende Transparenz der Fertigung und deren Planung für alle beteiligten Dispo-
nenten zu gewährleisten, fand täglich ein Treffen (sog. „Daily Production Meeting“) der invol-
vierten Mitarbeiter statt, in dem die erstellten Pläne der einzelnen Teilbereiche
zusammengetragen wurden. Dabei wurden anhand der aktuellen Rückmeldungen über die tat-
sächlich gefertigten Einheiten und die aktuellen Bestände die geplanten Leistungen mit den
bisherigen verglichen. Hiernach wurde im Daily Production Meeting entschieden, ob gegebe-
nenfalls daraus resultierend Änderungen an den bereits erstellten Plänen vorzunehmen sind
24. Sog. machine-shop-plan.25. Die Übertragung der Bedarfsmeldungen aus dem ERP/PPS-System in den machine-shop-plan erfolgtemanuell. 26. 8 Stunden.27. Hier sind gewisse Schwellenwerte vorgegeben, die möglichst eingehalten werden sollten.
134 Kapitel 5: Konzeption
oder zusätzliche Schichten gefahren werden mussten, um eventuelle Abweichungen von der
geplanten Leistung zu vermeiden.
Im oben beschriebenen Informationsfluss kommt es aufgrund der unterschiedlich verwendeten
Zeitbasen in den einzelnen Planungsbereichen zum Verlust von wertvollen Lieferinformatio-
nen. Insbesondere führen die auf Wochenbasis kumulierten Bedarfsmeldungen dazu, dass
bestimmte Bedarfe früher bzw. später als erforderlich fertiggestellt werden.28
Weiterhin gilt als Konsequenz aus der mangelhaften informationstechnischen Unterstützung,
dass nur wenige der beteiligten Mitarbeiter in der Lage waren, aus den teilweise unübersichtli-
chen Handzetteln und den manuell erstellten Listen und den Informationen, die nur in den
Köpfen der Disponenten existierten, eine funktionierende Planung und Steuerung zu generie-
ren.
Das zum Zeitpunkt der IST-Analyse eingesetzte ERP/PPS-System wurde später durch das
SAP/R3-System ersetzt, welches zwar u.a. eine integrierte Datenbasis bietet, die eine gemein-
same Entscheidungsgrundlage für die einzelnen Bereiche darstellt, jedoch aufgrund der in
Kapitel 2.1.2 erwähnten Mängel des MRP-II-Ansatzes nicht ausreichte, um die angestrebten
Ziele, insbesondere bezüglich der Reduktion der Bestände, zu erreichen.
5.3.2.2 Bildung der Dispositionseinheiten
Auf der Basis der im Rahmen der IST-Analyse gewonnenen Erkenntnisse über den Fertigungs-
prozess lässt sich die Fertigung im Pilotwerk mit Hilfe des in Abbildung 45 dargestellten Pro-
zessmodells wiedergeben. Dazu werden die in Kapitel 5.1.2 definierten sequentiellen bzw.
parallelen Reduktionen auf das in Abbildung 43 angegebene Prozessmodell angewendet. Dazu
wurde der Inspektionsprozess aufgrund seiner kurzen Bearbeitungsdauer und der stärkeren
Kopplung der Qualitätskontrollplanung an die Montageplanung dem Montageprozess zuge-
ordnet.29
Beim Veredelungsprozess lag das Hauptaugenmerk bei der Planung auf dem Kapazitätsange-
bot der internen Galvanik-Anlage. Die beiden externen Galvanik-Anlagen, die ein Viertel des
Kapazitätsangebotes der internen Galvanik-Anlage darstellten, wurden nur bei Kapazitätseng-
28. Da in diesem Fall Lieferungsverzögerungen „auf jeden Fall“ vermieden werden sollten, erhöht sichdas Sicherheitsdenken bei den Disponenten, so dass die Bedarfe für eine Woche möglichst zu Wochen-beginn fertiggestellt werden und somit ggf. zu einem erhöhten Bestand führen.29. Weiterhin wird die Qualitätskontrolle von den gleichen Teams vorgenommen, die auf den Montage-linien arbeiten.
Kapitel 5: Konzeption 135
pässen der internen Galvanik in Anspruch genommen und konnten von den lokalen Disponen-
ten nicht mitgeplant werden. Weiterhin befand sich im Pilotwerk eine neue Galvanik-Anlage
im Aufbau, die bei der Inbetriebnahme über eine sehr hohes Kapazitätsangebot verfügte, so
dass trotz der geplanten Verdoppelung des Fertigungsvolumens der Veredelungsprozess kei-
nen Engpass mehr darstellen würde. Daher wird im abzubildenden Veredelungsprozess aus-
schließlich die aktuelle interne Galvanik-Anlage als Engpass betrachtet.
Im Bereich der spanenden Bearbeitung wurden zunächst die beiden Fertigungsprozesse „Boh-
ren und Gewindeschneiden“ und „Finishing“ zum einen aufgrund des linearen Materialflus-
ses30 und zum anderen wegen des sehr kleinen dazwischenliegenden Puffers
zusammengeführt. Aus dem daraus entstandenen Prozess und dem parallel liegenden Ferti-
gungsprozess „Bohren“ wurde durch die Anwendung der „parallelen Reduktion“ der Prozess
„spanende Bearbeitung“ abgeleitet.
Zur Bildung der Dispositionseinheiten stellt das in Abbildung 45 dargestellte Fertigungspro-
zessmodell die Ausgangsbasis dar. Dabei ist aus der IST-Analyse des Informationsflusses fest-
zustellen, dass die vier dort aufgeführten Fertigungsprozesse die Engpässe in der Lieferkette
bilden und daher als planungsmäßig dominantere Prozesse zu betrachten sind.
Bezüglich des Planungsablaufes gilt, dass die Planung in den einzelnen Teilbereichen ausge-
hend von den Bedarfsmeldungen der Kunden über eine Rückwärtsstrategie realisiert wurde.
In Anlehnung an die in Kapitel 5.1.4.2.2 vorgestellten Konstrukten zeigen in Abbildung 46 die
Kreise die möglichen Positionen im betrachteten Fertigungsprozessmodell auf, in denen Rück-
30. D.h. es gibt eine festvorgegebene Zuordnung der Linien der Prozesse bzgl. des Materialflusses.
Abbildung 45: Reduziertes Fertigungsprozessmodell im Pilotwerk
MontierenVeredelnSpanende BearbeitungRäumen
Rohteillager Galv. TeileSpan. bearb.Teile
Geräum.Teile
Auslieferungs-lager
Int. Galvanik(1 Linie)
9 Linien 10 Linien5 Linien
P P PP
136 Kapitel 5: Konzeption
meldungen über die tatsächlichen Ereignisse aus der Fertigung erfolgen können. Bisher wird
allerdings der Fertigungszustand nur an den Positionen mit den gefüllten Kreisen erfasst.
Aus dem Fertigungsprozessmodell lassen sich aufgrund der oben beschriebenen Eigenschaften
die in Abbildung 47 skizzierten fünf Dispositionseinheiten ableiten. Die erste Dispositionsein-
heit bildet das Rohteillager vor dem Räumungsprozess ab. Dispositionseinheiten 2 bis 5 sind
vom Typ 631, wobei der Fertigungsprozess planungsmäßig dominiert und die Ablaufrichtung
rückwärts ist. Die Planung und Steuerung der Zugänge im Rohteillager werden von der
Beschaffungsabteilung vorgenommen. Da das hier zu entwickelnde FMI-System vorerst nur in
der Fertigungsabteilung eingesetzt werden soll, wird die daraus entstandene Dispositionsein-
heit in den folgenden Kapiteln nicht weiter betrachtet.
31. Vgl. Abbildung 25.
Abbildung 46: Mögliche und tatsächliche Positionen zur Erfassung des Fertigungszustandes
möglicher Zählpunkt tatsächlicher Zählpunkt
MontierenVeredelnSpanende BearbeitungRäumen
Roh
teill
ager
Gal
v. T
eile
Span
. be
arb.
Tei
le
Ger
äum
.T
eile
Auslieferungs-lager
Int. Galvanik(1 Linie)
9 Linien 10 Linien5 Linien
PPPP
Abbildung 47: Dispositionseinheiten im Pilotwerk
MontierenVeredelnSpanende BearbeitungRäumen
PPPP
Dispositions-einheit 5
Dispositions-einheit 1
Dispositions-einheit 2
Dispositions-einheit 3
Dispositions-einheit 4
Kapitel 5: Konzeption 137
5.3.3 Komponenten zum Stammdatenmanagement
In diesem Kapitel werden die Komponenten zur Verwaltung der Stammdaten detaillierter
betrachtet. Dazu wird zunächst das Datenmodell zur Beschreibung der Stammdaten in Kapitel
5.3.3.1 entworfen. Anschließend wird in Kapitel 5.3.3.2 die Komponente des Schnittstellen-
managers zur Stammdatenübernahme vorgestellt. Kapitel 5.3.3.3 gibt eine Beschreibung der
Komponenten des Stammdatenmanagements aus Benutzersicht am Beispiel des Fertigungs-
prozessmodells des Automobilzulieferers wieder.
5.3.3.1 Entwurf des Datenmodells
Das Datenmodell stellt die Grundlage der Datenverwaltung für das zu entwickelnde FMI-
System dar. Es bildet die Ausgangsbasis für die Definition von Zugriffsmethoden auf den
Datenbestand. Im Folgenden werden die Ausschnitte aus dem Datenmodell zur Beschreibung
der Stammdaten in der UML-Notation32 dargestellt.33 Dazu erfolgt zunächst die Darstellung
der Ausschnitte aus dem Klassendiagramm zur Spezifikation der Struktur einer Dispositions-
einheit und des Zeitmodells (vgl. Kapitel 5.3.3.1.1). Anschließend werden die Klassen zur
Abbildung der Beziehungen zu den vor- und nachgelagerten Dispositionseinheiten vorgestellt
(vgl. Kapitel 5.3.3.1.2).
5.3.3.1.1 Spezifikation der Struktur einer Dispositionseinheit
Zur Modellierung der statischen Struktur einer Dispositionseinheit werden die in Abbildung 48
dargestellten Klassen verwendet. Um die Klassendiagramme übersichtlicher zu gestalten, wird
auf eine ausführlicheren Darstellung aller Attribute der Klassen verzichtet.
Die Klasse Unit_Type soll die Spezifikation des Typen der zu modellierenden Dispositionsein-
heit ermöglichen. Dabei sollen die Betrachtungen im Rahmen der Arbeit auf die in Kapitel
5.1.2 hergeleiteten Typen beschränkt werden.34 Die weiteren Eigenschaften einer Dispositi-
onseinheit sollen mit der Klasse Disposition_Unit abgebildet werden. So beschreiben die Attri-
bute forward_security_time bzw. backward_security_time die spezifischen Sicherheitszeiten
32. Vgl. Kapitel 8.1.33. Zur Darstellung des Datenmodells werden Klassendiagramme verwendet. Die im Datenmodell vor-gestellten Klassen enthalten keine Operationen. Das Datenmodell lässt sich in einem relationalen Modellüberführen. Somit wird gewährleistet, dass die Portierung des zu realisierenden FMI-Systems auf das inder Praxis weitverbreitete relationale Datenbankmanagementsystem (DBMS) ohne größeren Aufwand(z.B. über ODBC) durchgeführt werden kann (vgl. Anforderung 3.1 in Kapitel 2.2.3).34. Vgl. Abbildung 25. Dabei legt eine Ausprägung der Klasse Unit_Type nicht nur die Prozessstrukturfest, sondern auch den planungsmäßig dominanteren Prozess.
138 Kapitel 5: Konzeption
der Dispositionseinheit bis hin zu den in der Lieferkette vorgelagerten bzw. nachgelagerten
Dispositionseinheiten. Operation_strategy spezifiziert die in der Dispositionseinheit verfolgte
Ablaufrichtung (vgl. Kapitel 5.1.3).
Die Klasse Part stellt das zentrale Element zur Beschreibung der Erzeugnisstruktur dar. Dabei
werden sowohl die Input- als auch die Output-Faktorarten als Instanzen dieser Klasse abgebil-
det. Die Beschreibung der Beziehungen erfolgt ausgehend von den Output-Faktorarten über
die Beziehungsklasse Consist_of.
Über die Klasse Fac_Type lassen sich die unterschiedlichen Ressourcentypen35 abbilden. Die
Modellierung der eigentlichen Ressourcen findet durch die Klasse Facility statt. Die Attribute
reliability bzw. capacity bilden den Zuverlässigkeitsfaktor36 bzw. die theoretische Mengenlei-
stung einer Ressource ab. Der Wert des Attributs capacity lässt sich dabei in Abhängigkeit
vom Ressourcentypen fest vorgeben bzw. über eine Formel berechnen. Da in einer Dispositi-
onseinheit nur die Ressourcen des planungsmäßig dominanteren Prozesses Betrachtung fin-
den, werden implizit für eine Dispositionseinheit nur die Ressourcen einer Fac_type-Instanz
abgebildet.
35. D.h. Betriebsmitteltypen (vgl. Kapitel 5.1.4.1.2).36. D.h. über den Zuverlässigkeitsfaktor wird das Verhältnis der effektiven gegenüber der theoretischenMengenleistung angegeben ( Zuverlässigkeitsfaktor = 1 - Ausfallwahrscheinlichkeit).
Disposition_Unit
disp_namedisp_idforward_security_time
0..*
From
_Gro
up
...
Unit_Type
type_nametype_id
1..10..*
Facility
fac_namefac_idreliabilitycapacity
...
Fac_Type
type_nametype_id
1..1
0..*
1..1
Part
part_namepart_idsecurity_time
...
0..* 1..1
Produced_On
version_namecycle_timeis_primary
...
0..*0..*
0..* 1..1
Change_Over_Group
cog_namecog_id
...
Change_Over_Time
duration...
1..1
0..*
To_G
roup
1..11..1
0..* 0..*
0..*
1..1
Abbildung 48: Klassenmodell zur Beschreibung der Struktur einer Dispositionseinheit
Consist_Ofquantity...
0..*0..*
backward_security_timeoperation_strategy
Kapitel 5: Konzeption 139
Die Modellierung der Transformationsstruktur erfolgt über die Beziehungsklasse
Produced_On. Dadurch wird die Zuordnung abgebildet, welche Output-Faktorart grundsätz-
lich auf welcher Ressource verarbeitet werden kann. In den Instanzen dieser Klasse stellt das
Attribut cycle_time den Kapazitätsfaktor37 dar.38 Das Attribut is_primary legt für die Bele-
gungsplanung fest, ob die Output-Faktorart bevorzugt auf der Ressource zu verarbeiten ist.
Zur Unterstützung der Belegungs- und Reihenfolgeplanung, insbesondere bei Fertigungspro-
zessen, sind die benötigten Umrüstzeiten bei einem Wechsel der zu fertigenden Output-Fak-
torart ressourcenspezifisch im Stammdatenmodell zu hinterlegen. Um den Aufwand bei der
Pflege der Umrüstzeitinformationen zu begrenzen, werden die Output-Faktorarten einer Dis-
positionseinheit mit identischem „Umrüstverhalten“ in einer Umrüstgruppe (Klasse:
Change_Over_Group) zusammengefasst. Die eigentlichen Umrüstzeiten werden in Form einer
Umrüstmatrix über die Instanzen der Klasse Change_Over_Time spezifiziert (vgl. Abbildung
48).
Zur Umsetzung des in Kapitel 5.1.4.2.1 vorgestellten Zeitmodells wird das in Abbildung 49
dargestellte Klassenmodell verwendet. Die Schicht als kleinste Einheit im Zeitmodell lässt
sich als Instanz der Klasse Shift modellieren. Dabei ist vorher die Anzahl der möglichen
Schichten pro Kalenderwoche über den Parameter shifts_in_week festzulegen. Über das Attri-
but day_no wird jede Schicht einem bestimmten Wochentag zugeordnet. Der Anfangszeit-
punkt und die Dauer einer Schicht werden durch die Attribute begin bzw. duration
beschrieben. Die Klasse Calender_Week bildet die Kalenderwochen eines Jahres ab.39
37. Vgl. Kapitel 5.1.4.1.3.38. In den Puffer- und Transportprozessen ist der Kapazitätsfaktor unabhängig von der zugeordneten Res-source und wird daher faktorartspezifisch als Attribut der Klasse Part abgebildet. 39. Die Berechnung der Kalenderwochen erfolgt nach DIN 1355. Demnach gehört der 1. Januar eines Jah-res erst dann zur ersten Kalenderwoche, wenn dieser Tag auf einen Montag, Dienstag, Mittwoch oderDonnerstag fällt. Falls der 1. Januar ein Freitag, Samstag oder Sonntag ist, zählt er, und ggf. auch der 2.und 3. Januar, noch zur letzten Kalenderwoche des vorherigen Jahres.
Shift
shift_no:{0,...,shifts_in_week-1}day_no:{1,...,7}beginduration
...
Calender_Week
year...
week_no:{1,...,53}1..1
1..s
hifts
_in_
wee
k
Abbildung 49: Klassen des Zeitmodells
140 Kapitel 5: Konzeption
In Tabelle940 sind die möglichen Grundoperationen auf dem Zeitmodell zusammengefasst.
Dabei lassen sich die ersten drei Operationen auf die anderen Ebenen41 des Zeitmodells ver-
wenden. Die Operationen 4 bis 8 ermöglichen die Überführung der Elemente einer Ebene in
die zugehörigen Elemente benachbarter Ebenen. Die Operation 9 ermittelt die passende
Schicht aus einem Datum und einer Uhrzeit. Umgekehrt erlaubt die Operation 10 die Berech-
nung des passenden Datums und der Uhrzeit des Schichtbeginns.
40. Vgl. auch Kapitel 5.1.4.2.1. Date und Time geben die Datentypen zur Beschreibung eines Datums(z.B. „DD.MM.YYYY“) und der Uhrzeit (z.B. „HH.MM.SS“) an.41. Tage, Wochen und Jahre.
Nr. Operation Signatur Beschreibung
1 MoveVerschiebt um einen Wert in Rich-
tung Zukunft oder Vergangenheit.
2 Subtract
Gibt den Abstand zwischen zwei
Schichten an. D.h. Anzahl der
Schichten zwischen zwei spezifi-
schen Schichten.
3 Compare Vergleicht zwei Schichten.
4 GetDay Ermittelt den zugeordneten Tag.
5 GetWeek Ermittelt die zugeordnete Woche.
6 GetYear Ermittelt das zugeordnete Jahr.
7GetNumShift-
OfDay
Ermittelt die Anzahl der zugehöri-
gen Schichten.
8GetFirstShiftOf-
DayErmittelt die erste Schicht.
9 GetCurrentShiftErmittelt die passende Schicht aus
einem Datum und einer Uhrzeit.
10 GetBeginShiftErmittelt das Datum und die Uhr-
zeit des Schichtbeginns.
Tabelle 9: Grundoperationen auf dem Zeitmodell
S ℑ× S→
S S× ℵ→
S S× 1– 0 1,{ , }→
S D→
D W→
W Y→
D ℵ→
D S→
Date Time× S→
S Date Time×→
Kapitel 5: Konzeption 141
5.3.3.1.2 Spezifikation der Beziehungen zu den Dispositionseinheiten
Zur Modellierung der Beziehungen zu den benachbarten Dispositionseinheiten werden die in
Abbildung 50 dargestellten Klassen verwendet. Dazu werden die benachbarten Dispositions-
einheiten durch die Klasse Partner abgebildet. Eine Unterscheidung, wie in Kapitel 5.2, zwi-
schen den vor- und nachgelagerten Dispositionseinheiten erfolgt über das Attribut role. Zur
informationstechnischen Umsetzung der Informationsflussbeziehungen können ggf. für jede
benachbarte Dispositionseinheit die elektronische Mailadresse (email_adress) des Disponen-
ten, die URL-Adresse des Servers (server_url) der entsprechenden dezentralen Einheit des
FMI-Systems und die entsprechende Webseite (website) zur Abfrage von Informationen spezi-
fiziert werden.42 Weiterhin werden bestimmte Merkmale der in Kapitel 5.2 hergeleiteten
Merkmale der Informationsflussbeziehungen als Attribute abgebildet. So werden die kunden-
bzw. zulieferspezifischen Vorlaufzeiten durch das Attribut lead_time43 modelliert.
42. Diese Daten werden in Kapitel 5.3.5 für die Funktionalitäten des Kooperationsmanagers eingesetzt.43. In Form von Anzahl der Schichten.
Disaggregation_Rules
partner_idday_percentage[0,..6]shift_percentage[0, .., shifts_in_week-1]delivery_time[0, .., shifts_in_week-1]
...
0..*
Partner
partner_namepartner_id
email_adressserver_url
...
Part_Relationpartner_idpart_id
...
1..1
websitelead_time
trigger{push, pull}
granularity{shift, day, week}horizon
role{supplier, customer}
priority
Part
trigger{push, pull}
granularity{shift, day, week}horizon
priority
0..* 1..10..*
1..1
Abbildung 50: Klassenmodell zur Spezifikation der externen Beziehungen
Facility
Partner_View View_TemplateView_Element
element_valuegranularity{shift, day, week}
element_id
...
element_name0..*
0..*
0..*
0..*
0..*1..*view_id
0..*1..*
1..10..*
1..1
0..*
view_name...
view_name
0..*1..1
0..*1..1
Contract_Type
0..*1..1
Initiation
Contract_Type
min_order_quantitymax_order_quantitylotsize
...
142 Kapitel 5: Konzeption
Die weiteren Attribute der Klasse Partner stellen eine Art Vorlage zur Gestaltung der Informa-
tionsflussbeziehungen dar, die erzeugnisspezifisch in der Klasse Part_Relation modifiziert
werden können. Dabei legt die Klasse Part_Relation zum einen fest, welche Erzeugnisse von
einem Kunden bzw. einem Zulieferer bestellt bzw. angeboten werden können, und zum ande-
ren, wie die Weiterleitung der Bedarfe bzw. der Angebote gestaltet werden kann. Zur Gestal-
tung der entsprechenden Informationsflüsse werden die Zeitbasis (granularity) und der
Zeithorizont (horizon), auf den sich die Informationen beziehen, bestimmt. Durch das Attribut
trigger wird festgelegt, ob die Übertragung der Informationen von der externen oder der loka-
len Dispositionseinheit angestoßen wird. Über das Attribut priority lässt sich für jedes Erzeug-
nis eine Reihenfolge anlegen, die spezifiziert, von welchen Zulieferern bevorzugt bestellt wird
bzw. von welchen Kunden die Bedarfe in kritischen Situationen zu befriedigen sind. Ferner
können über die Aggregationsbeziehung zu der Klasse Contract_Type Restriktionen bezüglich
der Quantitäten der zu bestellenden bzw. zu liefernden Erzeugnisse gemacht werden. Weiter-
hin wird über die Aggregationsbeziehung zu der Klasse Initiation angegeben, wann der Vor-
gang zur Aufbereitung der Bedarfe bzw. Angebote ausgelöst werden kann.44
Die Klasse Disaggregation_Rules erlaubt es, für jeden Partner individuelle Regeln aufzustel-
len, die eine Umrechnung der gemeldeten Bedarfe des Kunden bzw. der Angebote des Zuliefe-
rers von der Wochen- bzw. Tagesbasis auf die Tages- und Schichtbasis ermöglicht. Dazu
können zunächst die Quantitäten auf Wochenbasis entsprechend den Einträgen in
day_percentage auf die Wochentage verteilt werden. Ähnlich können die Quantitäten auf
Tagesbasis gemäß shift_percentage auf die einzelnen Schichten des Tages verteilt werden.
Über die delivery_time lassen sich die auf Schichtbasis generierten Bedarfe bzw. Angebote um
eventuell noch zu berücksichtigende Transportzeiten rückwärts bzw. vorwärts verschieben.
Neben den Klassen zur individuellen Gestaltung der Informationsflüsse der Bedarfe und Ange-
bote gibt es weitere Klassen zur Definition eines partnerspezifischen Informationsprofils.
Dazu können jedem Partner beliebig viele Instanzen der Klasse Partner_View zugeordnet wer-
den. Eine Partner_View-Instanz besteht aus einer Ansammlung von View_Element-Instanzen,
die bereits in einer vordefinierten View_Template existieren. Dabei stellt die Klasse
View_Element die Umsetzung der zu definierenden Sichten45 auf das Fertigungsgeschehen
innerhalb der Dispositionseinheit dar. Eine View_Element-Instanz besteht i.W. aus einem
44. Vgl. Abbildung 51.45. Vgl. Kapitel 5.1.5.
Kapitel 5: Konzeption 143
quantitativen Wert (element_value), der sich auf eine Schicht-, Tages- oder Wochenbasis
bezieht. Optional kann sich eine View_Element-Instanz auf ein bis mehrere Ressourcen und/
oder ein bis mehrere Erzeugnisarten beziehen. Auf den Einsatz der Partner_View und
View_Element wird in Kapitel 5.3.5.2 ausführlicher eingegangen.
Abbildung 51 gibt das Klassenmodell zur Beschreibung der möglichen Auslösungsarten für
die Informationsflüsse wieder. Dazu bieten sich grundsätzlich drei Alternativen an. Demnach
kann die Auslösung des Informationsflusses manuell, periodisch oder ereignisbasiert erfolgen.
Bei der manuellen Auslösung findet die Aufbereitung der Informationsflüsse durch den Dispo-
nenten statt. Geschieht die Auslösung periodisch, so sind der Startzeitpunkt und die Perioden-
länge zu bestimmen. Soll die Auslösung dagegen ereignisbasiert erfolgen, so sind im
Allgemeinen die Bedingungen aufzustellen, unter denen ein solches Ereignis auftreten kann.46
46. Im Rahmen der prototypischen Implementierung soll als auszulösendes Ereignis das Erreichen bzw.Unterstreiten eines zu bestimmenden Meldebestandes betrachtet werden.
Event_Based
Abbildung 51: Klassenmodell zur Abbildung der Auslösungsarten
Initiation
PeriodicallyManually
Inventory_Level
startbasefactor
report_level
144 Kapitel 5: Konzeption
5.3.3.2 Schnittstelle zur Stammdatenübernahme
Die in den Kapiteln 5.3.3.1.1 und 5.3.3.1.2 beschriebenen Daten zur Modellierung der Liefer-
kette können teilweise in den eingesetzten ERP/PPS-Systemen existieren. Um Inkonsistenzen
durch die notwendige doppelte Datenhaltung zu vermeiden, sollten die im FMI-System benö-
tigten Daten, falls vorhanden, aus dem ERP/PPS-System übernommen werden können.47 Dazu
sind Schnittstellen zum Datenexport und -import aus dem ERP/PPS- in das FMIS-System zu
entwickeln. Dabei geht es im Wesentlichen um die zwei Fragen: Welche Daten können aus
dem ERP/PPS-System übernommen werden, bzw. wie sind die Schnittstellen zu gestalten ?.
Grundsätzlich lassen sich für die Gestaltung der Schnittstellen folgende Möglichkeiten unter-
scheiden. Die erste Möglichkeit ist der Datenaustausch via File-Transfer. Dazu werden indivi-
duelle Schnittstellen für den Import bzw. Export zwischen den beiden Systemen programmiert.
Allerdings müssen die Schnittstellen bei jedem Update eines Systems ggf. angepasst werden.
Eine zweite Möglichkeit bieten die Application Programming Interfaces (APIs), die von den
meisten ERP/PPS-Systemen angeboten werden. Für die Entwicklung von Schnittstellen über
APIs sind Kenntnisse der Funktionalitäten und der Datenschemata der beiden Systeme unum-
gänglich. Eine weitere Variante für die Realisierung der Schnittstellen stellen Middleware-ori-
entierte Anwendungen dar, die eine einheitliche technologische Basis bieten, um Daten
zwischen den Systemen zu transferieren.48 Ein Beispiel hierfür stellen die sog. Enterprise
Application Integration (EAI)-Systeme dar.49
Da a priori nicht bekannt ist, mit welchem ERP/PPS-System die Datenübernahme erfolgen
soll, bietet es sich an, den Datenaustausch über einen File-Transfer in einem neutralen For-
mat50 zu realisieren. Dadurch reduziert sich der Integrationsaufwand bei der Einführung des
FMI-Systems auf die Realisierung der Schnittstellenfunktionalität zum Datenexport auf der
Seite des ERP/PPS-Systems.
Bezüglich der Frage, welche Daten aus dem ERP/PPS-System übernommen werden können,
gilt, dass grundsätzlich alle im FMI-System zur Modellierung der Lieferkette benötigten
47. Dadurch wird das ERP/PPS-System als das führende System betrachtet, indem die Daten zur Be-schreibung der Fertigungs- und Logistikprozesse primär gepflegt werden. Weiterhin wird durch eineÜbernahme ausgewählter Stammdaten aus dem ERP/PPS-System der manuelle Aufwand bei der Erfas-sung der Daten in das FMI-System erheblich reduziert.48. Vgl. Kapitel 3.3.1.1.1.49. Vgl. Kapitel 3.3.1.2.1.50. In der bisherigen Implementierung findet der Transfer durch Textdateien mit vordefinierten Formatenstatt. Denkbar wäre auch eine Realisierung des Datentransfers in XML-Dokumenten (vgl. Kapitel 3.3.3).
Kapitel 5: Konzeption 145
Daten, falls vorhanden, übernommen werden können. Aufgrund der unterschiedlichen Daten-
modelle der ERP/PPS-Systeme und des eventuellen Fehlens der benötigten Daten soll eine
Datenübernahme auf die häufig in den ERP/PPS-Systemen vorzufindenden Daten zur
Beschreibung der Fertigungsprozesse beschränkt werden. Dabei handelt es sich im Wesentli-
chen um Daten zur Beschreibung der Erzeugnis-, Ressourcen- und Transformationsstrukturen
sowie um die Beziehungen zu den Kunden bzw. zu den Zulieferern. Somit werden durch die
Stammdatenübernahme Instanzen der in Abbildung 48 dargestellten Klassen Part, Facility,
Produced_On und Consists_Of sowie eventuell der Klasse Partner51 in der FMIS-Datenbank
erstellt. Abbildung 52 zeigt die Benutzungsschnittstelle zum Import der Stammdaten auf der
Seite des FMI-Systems auf.
Um die Schnittstellen möglichst flexibel auf die aus dem ERP/PPS-System zu exportierenden
Daten anzupassen, können die Dateien52 und deren Formate in einer Konfigurationsdatei spe-
zifiziert werden. Dazu wird in der Konfigurationsdatei für jedes Attribut der entsprechenden
Klasse neben den Datentypen53 und der Zeichenlänge angegeben, ob es als „standard“ oder
51. Vgl. Abbildung 50.52. Die Daten werden pro Klasse in einer separaten Datei exportiert.53. Hier werden die Datentypen text, double und boolean unterschieden.
Abbildung 52: Benutzungsschnittstelle zur Stamm-datenübernahme
Spezifikation der Attributeund Formate
Auswahl der Klasse
Anzeige der Formate
Statusmeldungen desImportprozesses
146 Kapitel 5: Konzeption
„optional“ berücksichtigt werden soll. Als „standard“ gekennzeichnete Attribute müssen in
jedem Datensatz beim Importvorgang in das FMI-System vorliegen. Voraussetzung für die
Stammdatenübernahme ist das Anlegen der Grundstruktur54 des abzubildenden Fertigungspro-
zesses in der FMIS-Datenbank, so dass eine Zuordnung der zu importierenden Ressourcen-
und Erzeugnisdaten zu den Dispositionseinheiten ermöglicht wird. Aus Benutzersicht soll der
Datenexport und -import mit möglichst wenigen manuellen Eingriffen erfolgen.55 Da aber eine
vollständige Übernahme der für die Modellierung der obengenannten Strukturen benötigten
Daten aus dem ERP/PPS-System häufig aufgrund unterschiedlicher Lieferkettenmodelle nicht
möglich sein wird, ist eine manuelle Nachbearbeitung der importierten Daten unumgänglich.
5.3.3.3 Umsetzung am Fallbeispiel
Zur Spezifikation des Lieferkettenmodells von einer bzw. mehreren Dispositionseinheiten
umfasst das Stammdatenmanagement mehrere Editoren, die über das Hauptfenster in Abbil-
dung 53 gestartet werden können.56
54. Z.B. Das Festlegen der Dispositionseinheiten und deren Reihenfolge sowie die Bildung von Umrüst-gruppen (Change_Over_Group).55. Eine Online-Schnittstelle würde erfordern, dass sich die beiden Systeme triggern können.56. Darüber hinaus bietet es Möglichkeiten zur Generierung von „Reports“ über das bereits spezifizierteLieferkettenmodell.
Abbildung 53: Hauptfenster zum Stamm-datenmanagement
Festlegen der umrüst-gruppen und -zeiten
Anlegen desZeitmodells
Spezifikation derInformationsfluss-beziehungen zu denDispositionseinheiten
Spezifikation desLieferkettenmodells
Kapitel 5: Konzeption 147
Analog zu der Einteilung in Kapitel 5.3.3.1 gibt es Editoren zur Spezifikation der internen
Eigenschaften einer Dispositionseinheit sowie zur Beschreibung der Beziehungen zu den
externen Dispositionseinheiten. Im Folgenden soll eine Auswahl der Editoren anhand des Fer-
tigungsprozesses im Pilotwerk57 vorgestellt werden. Im Stages Editor (vgl. Abbildung 54)
werden die Eigenschaften der von der lokalen Einheit des FMI-Systems abzubildenden Dispo-
sitionseinheiten angegeben. So wird beim Anlegen einer neuen Dispositionseinheit der zuge-
hörige Typ58 bestimmt. Dabei werden die vier zu betrachtenden Dispositionseinheiten im
Pilotwerk dem „Typ 6“59 zugeordnet.60 Die Ablaufrichtung kann nachträglich zwischen den
drei Auswahlmöglichkeiten umgeändert werden.
Mit der Auswahl der Checkbox „Is_planned“ wird angegeben, ob für die Dispositionseinheit
eine Belegungs- und Reihenfolgeplanung erforderlich ist oder nur überprüft werden soll, ob
für die gemeldeten Bedarfe bzw. Angebote mengen- und terminmäßig ausreichend Kapazitäts-
57. Vgl. Kapitel 5.3.2.58. Vgl. Klasse Unit_Type in Abbildung 48. 59. „Typ 6“ bildet in dem hier implementierten Prototypen des FMI-Systems einer Dispositionseinheitmit einer Prozessstruktur wie bei Tap 6 in Abbildung 25 und einem planungsmäßig dominanteren Ferti-gungsprozess ab.60. Im Rahmen der prototypischen Implementierung ist zunächst nur das Anlegen der Prozessstrukturenvon den Typen 1, 2, 3, 6, und 8 mit einem planungsmäßig dominanteren Fertigungsprozess (vgl. Abbil-dung 25) möglich. Grundsätzlich ist eine Erweiterung der entworfenen Architektur um Funktionalitätenfür die weiteren Prozessstrukturen möglich, jedoch sie ist mit einem erheblichen Implementierungsauf-wand verbunden.
Abbildung 54: Stages Editor
Liste der Dispositions-einheiten
Eigenschaften derDispositionseinheiten
148 Kapitel 5: Konzeption
angebot vorhanden ist. So wird z.B. in der Galvanik überprüft, ob das Kapazitätsangebot der
internen Galvanik-Anlage ausreicht oder ggf. Leistungen der externen Galvanik-Anlagen her-
angezogen werden müssen.61 Weiterhin wird mit „Has_team_info“ für jede Dispositionsein-
heit bestimmt, ob die Personalverfügbarkeit als Kapazitätsrestriktion bei der Belegungs- und
Reihenfolgeplanung zu berücksichtigen ist.
Die Erfassung der Ressourcen und deren Eigenschaften erfolgt über den Faciliy Editor. Dazu
wird für jede Ressource eine Instanz der Klasse Facility erstellt.
Im Parts Editor (vgl. Abbildung 55) wird die Erzeugnis- und Transformationsstruktur der Dis-
positionseinheiten angelegt. Dazu werden im linken Textfeld die Erzeugnisarten aufgelistet.
Im rechten Bereich werden die Eigenschaften der einzelnen Erzeugnisarten spezifiziert. Dabei
wird für jede Erzeugnisart u.a. die spezifische Sicherheitszeit sowie ggf. der Kapazitätsfaktor
angegeben. Die Zuordnung zu einer Change Over Group soll die Erfassung der Umrüstzeiten
im Change Over Times Editor erleichtern. Weiterhin werden im Textfeld „Consists of“ für
jede Output-Faktorart die benötigten Input-Faktorarten und deren Mengenverhältnisse aufge-
zeigt. Umgekehrt werden im Textfeld „Used for“ für eine Input-Faktorart die möglichen Out-
put-Faktorarten aufgezeigt, in denen sie verwendet wird. Im unteren rechten Block des Parts
Editors erfolgt eine Auflistung der möglichen Ressourcen, auf denen die Output-Faktorart
61. Vgl. Kapitel 5.3.2.2.
Kapitel 5: Konzeption 149
gefertigt werden kann. Dabei wird bei der Zuordnung einer Output-Faktorart zu einer Res-
source ggf. die erforderliche Cycle Time angegeben.
Das im Pilotwerk eingesetzte Zeitmodell besteht aus 20 Schichten, die über den sog. Shift Edi-
tor erfasst werden. Dort können die Anfangszeitpunkte und die Dauer der Schichten angege-
ben werden.62 Im Team Availability Editor kann für jede Dispositionseinheit die Zahl der
verfügbaren Teams pro Schicht über eine Vorlage bestimmt werden. Der Change Over Groups
Editor erlaubt das Anlegen von Umrüstgruppen, die die Erfassung der Umrüstzeiten für jede
Ressource in Form einer symmetrischen Matrix im sog. Change Over Times Editor ermögli-
chen. Dort kann neben der Dauer des Umrüstvorganges angegeben werden, ob für das Umrü-
sten die verfügbaren Teamkapazitäten beansprucht werden.
Im Customer Editor63 (vgl. Abbildung 56) werden zunächst für jeden Kunden die Disaggrega-
tionsregeln64 zur Aufsplittung der gemeldeten Bedarfe angegeben. Die weitere Spezifikation
62. Die Anzahl der Schichten und deren Zuordnung zu den einzelnen Wochentagen werden als System-einstellungen über die Datenbank spezifiziert.63. Auf eine ähnliche Weise ist der Supplier Editor aufgebaut.64. Vgl. Abbildung 50.
Abbildung 55: Parts Editor
Spezifikation derErzeugnisstruktur
Liste der Output-Faktorarten
Spezifikation derTransformations-struktur
150 Kapitel 5: Konzeption
der kundenindividuellen Beziehungen erfolgt im Customer Information Editor, der vom
Customer Editor durch Drücken des Schalters „Customer Information“ aufgerufen wird.
Im Customer Information Editor (vgl. Abbildung 57) werden sowohl die für die technische
Kommunikation erforderlichen Attribute als auch die Attribute zur Bildung von Informations-
flüssen, die im Part Related Information Editor erzeugnisspezifisch geändert werden können,
erfasst.
Abbildung 56: Customer Editor
Abbildung 57: Customer Information Editor
Kapitel 5: Konzeption 151
5.3.4 Komponenten zum Bewegungsdatenmanagement
In diesem Kapitel sollen die Komponenten für das Management der anfallenden Bewegungs-
daten in einer Dispositionseinheit entworfen und realisiert werden. Dazu wird zunächst in
Kapitel 5.3.4.1 ein Datenmodell zur Abbildung der wesentlichen Aspekte der dynamischen
Strukturen beschrieben. Im nachfolgenden Kapitel werden in Abhängigkeit von den Eigen-
schaften der Dispositionseinheit geeignete Sichten auf das Fertigungsgeschehen dargestellt.
Dabei sollen insbesondere die Belegungs- und Reihenfolgeplanung der Aufträge und die
Kapazitätssituation der Ressourcen sowie deren Auswirkungen aufgezeigt werden. Kapitel
5.3.4.3 beschreibt die Komponente für das Bestandsmanagement in der Dispositionseinheit.
Zur Gestaltung des Bewegungsdatenaustausches mit dem ERP/PPS-System wird in Kapitel
5.3.4.4 eine Schnittstellen-Komponente vorgestellt.
5.3.4.1 Entwurf des Datenmodells
Das Datenmodell zur Beschreibung der Bewegungsdaten soll eine Abbildung der in Kapitel
5.1.4.2 definierten Ereignisse darstellen. Dabei gilt es zu unterscheiden zwischen Ereignissen,
die durch persistente Klassen modelliert werden, und Ereignissen, die daraus abgeleitet wer-
den. In Abbildung 58 ist der Ausschnitt aus dem Klassenmodell zur Beschreibung der Bewe-
gungsdaten aufgezeigt. Die Klasse Customer_Requirements stellt die von den Kunden
gemeldeten Bedarfe dar. Dazu werden die Kundenbedarfe für eine Output-Faktorart auf
Schichtbasis mit (shifted_qty) und ohne (not_shifted_qty) Berücksichtigung der kunden-, fak-
torart- und dispositionseinheitspezifischen Sicherheitszeiten verwaltet.65 Die Klasse
Supplier_Quotations bildet die geplanten Lieferungen (Angebote) der Zulieferer ab.
Die in der Vergangenheit66 tatsächlich erbrachten Lieferungen an den Kunden bzw. die von
den Zulieferern bereits eingegangenen Lieferungen werden in den Klassen
Customer_Despatches bzw. Supplier_Deliveries verwaltet. Zur Abbildung der Transformati-
onsereignisse werden die Klassen Plan und Actual eingesetzt. Plan bildet dabei die geplanten
Belegungen der Ressourcen des planungsmäßig dominanteren Prozesses in der Dispositions-
einheit ab. Dazu wird für jede Output-Faktorart die pro Schicht zu fertigende Menge auf einer
65. Zwar lassen sich die shift_qty aus den not_shifted_qty berechnen und umgekehrt, um jedoch den Auf-wand der Berechnungen bei jeder Zugriffsoperation zu vermeiden, werden die beiden Werte getrennt ge-halten.66. Ist-Ereignisse.
152 Kapitel 5: Konzeption
Ressource angegeben. Über das Attribut sequence lässt sich die Reihenfolge des zu fertigen-
den Loses der Output-Faktorart innerhalb einer Schicht festlegen. Dagegen dokumentiert die
Klasse Actual die in der Vergangenheit auf Schichtbasis hergestellten Mengen einer Output-
Faktorart pro Ressource.
Mit der Fac_Availability wird für jede planungsrelevante Ressource schichtweise angegeben,
ob sie verfügbar ist bzw. war. Bestandsumbuchungsereignisse werden durch die Klassen Stock
und Stock_Movements modelliert. Hierbei wird mit Stock die verfügbare Menge eines
Supplier_Quotations
...
Supplier_Deliveries
...quantity[0, shifts_in_week-1]
Stock
...quantity
Customer_Despatches
...quantity[0, shifts_in_week-1]
Customer_Requirements
...
shifted_qty[0, shifts_in_week-1]not_shifted_qty[0, shifts_in_week-1]
Part
Part_Relation
Fac_Availability
...availability[0,shifts_in_week-1]
Plan
...
quantity[0,shifts_in_week-1]sequence[0,shifts_in_week-1]
Actual
...quantity[0,shifts_in_week-1]
Shift
Stock_Type
type_idtype_name
Movement_Type
type_idtype_name
0..*
1..11..11..1
1..1
1..1
1..1
1..1
0..*
0..*
0..*
0..*
1..1
1..1
1..1
0..*0..*
0..*
0..*
0..*
1..1
1..11..1
1..1
1..*
0..*
0..*
0..*
0..*0..*
0..* 0..*
1..11..1
1..1
1..1
0..*
0..2
0..*
1..1
1..11..1
1..*
Facility
Stock_Movements
...quantity
0..*
0..1
Abbildung 58: Klassenmodell zur Abbildung der Bewegungsdaten
1..1
0..*
0..*
shifted_qty[0, shifts_in_week-1]not_shifted_qty[0, shifts_in_week-1]
Calendar_Week
Kapitel 5: Konzeption 153
Bestandstypen (Stock_Type) einer Faktorart zu Beginn der aktuellen Schicht geführt. Ferner
können die Bestände einer Faktorart ggf. pro Ressource (Facility) verwaltet werden. Durch die
Klasse Stock_Movements sollen die geplanten Bestandsumbuchungen dokumentiert werden.
Dazu wird für jede Umbuchung mit der Klasse Movement_Type die Art der Bestandsumbu-
chung festgelegt.67 Abbildung 59 gibt eine Übersicht der Zuordnung der Klassen zu den Ereig-
nistypen und den Interpretationen.
5.3.4.2 Komponente zum Planungsmanagement
Aufgabe der Planungsmanagement-Komponente68 ist es, ausgehend von den Eigenschaften
der Dispositionseinheit, einerseits den Disponenten bei der Erstellung einer Belegungsplanung
für die Ressourcen zu unterstützen und andererseits die Planungsergebnisse und deren Auswir-
kungen adäquat aufzuzeigen. Dazu soll in Kapitel 5.3.4.2.1 für ausgewählte Dispositionsein-
heiten gezeigt werden, wie die Informationen zur Entscheidungsunterstützung aufbereitet
werden können. In Kapitel 5.3.4.2.2 wird am Beispiel der Montage des Pilotwerkes ein Ver-
fahren zur Belegungsplanung vorgestellt.
5.3.4.2.1 Bildung von Disponentensichten
Die Bildung der Disponentensichten erfolgt auf der Basis der angegebenen Prozess-, Ablauf-
und Informationsstrukturen. Im Folgenden soll am Beispiel der in Abbildung 60 dargestellten
Dispositionseinheiten aufgezeigt werden, welche Informationen zur Entscheidungsunterstüt-
zung aufbereitet werden können.
67. Ggf. soll dabei für jede Umbuchung spezifiziert werden, auf welche Ressourcen sie sich bezieht.68. Vgl. Anforderung 3.3.
InterpretationSoll Plan Ist
ZugangAbgang
Transformation
Ere
igni
s-ty
pen
BestandsumbuchungVerfügbarkeit
PlanCustomer_Despatches
Stock, Stock_Movements
Vgl. Kapitel 5.3.5.1.1
Customer_RequirementsSupplier_DeliveriesSupplier_Quotations
ActualStock_Movements
Fac_AvailabilityFac_Availability
Abbildung 59: Zuordnung der Klassen zu den Ereignissen
Vgl. Kapitel 5.3.5.2
154 Kapitel 5: Konzeption
Die Aufbereitung der Informationen erfolgt zum einen auf der Basis der in Abbildung 58
beschriebenen Bewegungsdaten und zum anderen durch bestimmte Parameter, die vom Dispo-
nenten angegeben werden. Als erster Parameter ist der Zeithorizont69, für den Informationen
über das Fertigungsgeschehen aufbereitet werden sollen, zu bestimmen. Dadurch lässt sich
zum einen die Zahl der zu betrachtenden Schichten (num_shifts) im Zeithorizont ermitteln und
zum anderen ggf. eine Positionierung des Zeithorizontes gegenüber der aktuellen Schicht her-
ausstellen. Als zweiter Parameter wird die Ressource angegeben, für die die der Belegungsplan
erstellt, modifiziert bzw. aufgezeigt werden soll. Anschließend können unter Berücksichtigung
der Ablauf- und Informationsstruktur die entsprechenden Sichten auf das Fertigungsgeschehen
gebildet werden. Abbildung 61 stellt das Klassenmodell zur Aufbereitung und Darstellung der
fertigungsrelevanten Informationen für eine Ressource einer Dispositionseinheit vom „Typ
6“70 dar. Demnach stehen die ausgesuchte Ressource (Facility) und die daraus zu fertigenden
Output-Faktorarten (Parts_On_Facility) im Mittelpunkt der Betrachtung. Dazu werden für
jede Instanz der Klasse Parts_On_Facility die notwendigen Informationen schichtweise aufbe-
reitet.
69. Der Zeithorizont wird explizit durch die Startwoche und die Zahl der Wochen bestimmt.70. Vgl. Abbildung 60.
„vorwärts“„rückwärts“
Abbildung 60: Realisierte DispositionseinheitenTyp 6 Typ 3
P P
Kapitel 5: Konzeption 155
Die Klassen Requirements bzw. Despatches bilden die Summen der noch offenen Kundenbe-
darfe bzw. der bereits erfolgten Kundenlieferungen auf Schichtbasis über den gesamten Zeit-
horizont für eine Output-Faktorart ab. Die erforderlichen Informationen zur Bildung der
Instanzen der Klassen Requirements bzw. Despatches werden aus den Instanzen der Klassen
Customer_Requirements bzw. Customer_Despatches71 gebildet.72
Zur Ermittlung der abzudeckenden Nettobedarfe aus den offenen Kundenbedarfen wird
zunächst für jede Output-Faktorart der Initialbestand (Initial_Stock) berechnet. Dazu ist die
Position der ersten Schicht ( ) des zu betrachtenden Zeithorizontes gegenüber der aktuellen
Schicht zu bestimmen. Liegt die erste Schicht des Zeithorizontes vor bzw. zeitgleich
mit der aktuellen Schicht73, dann stellt der Bestand zu Beginn der aktuellen Schicht74 den
Initialbestand dar. Ist dagegen die erste Schicht in der Zukunft, so bildet der projizierte
Bestand zu Beginn der ersten Schicht den Initialbestand ab. Dabei wird der projizierte Bestand
aus dem verfügbaren Bestand zu Beginn der aktuellen Schicht unter Berücksichtigung der
71. Vgl. Abbildung 58.72. Dabei wird davon ausgegangen, dass Despatches, die bereits verschickt wurden, jedoch bei den Kun-den noch nicht eingetroffen sind, in den Requirements berücksichtigt werden.73. D.h. .74. D.h. Da der Bestand sich auf das Ende einer Schicht bezieht, gilt hier der Bestand am Ende der vor-herigen Schicht.
Parts_On_Facility
Requirements
...
shifted_qty[0, num_shifts-1]
Initial_Stock
Despatches
...
quantity[0, num_shifts-1]
Planning_Security
...quantity[0, num_shifts-1]
Other_Plan
...quantity[0, num_shifts-1]
Projected_Inventory
...quantity[0, num_shifts-1]
1..1
0..*
1..1
Facility
last_actual_shift_index...
not_shifted_qty[0, num_shifts-1]
last_despatch_shift_index
1..1
1..1
1..11..1
1..1 1..1
1..1 1..11..1
1..1 1..1 1..1
1..1Facility_Plan
...
quantity[0, num_shifts-1]sequence[0, num_shifts-1]
quantity
Capacity_Info
...
production_time[0, num_shifts-1]remaining_time[0, num_shifts-1]required_teams[0, num_shifts-1]available_teams[0, num_shifts-1] 1..1
1..1
Abbildung 61: Klassenmodell zur Bildung einer bedarfsorientierten Sicht
quantity[0, num_shifts-1]
Movements
...
1..1
1..1
S0
Saktuell
C o m p a r e S0 Saktuell,( ) 0≤
156 Kapitel 5: Konzeption
Bruttobedarfe, den zu fertigenden Losen der Output-Faktorart75 und ggf. den geplanten
Bestandsumbuchungen (Movements) in dem Zeitraum zwischen und berechnet.
Der abzudeckende Nettobedarf für jede Schicht, die in der Zukunft liegt, wird durch die
Bestimmung des projizierten Bestandes ermittelt. Dazu wird für jede Output-Faktorart der pro-
jizierte Bestand mit und ohne Berücksichtigung der Kundenbedarfsverschiebung durch die
kunden-, dispositionseinheits- und faktorartspezifischen Sicherheitszeiten berechnet (vgl.
Planning_Security, Projected_Inventory in Abbildung 61). Darüber hinaus werden für jede
Schicht im Zeithorizont durch die Klasse Capacity_Info Kapazitätsinformationen für die
betrachtete Ressource aufbereitet, die den Disponenten eventuelle Verletzungen der Kapazi-
tätsrestriktionen aufzeigen.
Die zur Bildung einer bedarfsorientierten Sicht realisierte Planungsoberfläche ist in Abbildung
63 für die Montagelinie AssemblyLine_01 im Pilotwerk dargestellt. Hierbei ist die in Abbil-
dung 62 skizzierte Erzeugnisstruktur für die Montage im Pilotwerk zugrunde gelegt worden.
Horizontal ist die Planungsoberfläche, in Abbildung 63, in den Schichten des Zeithorizontes
eingeteilt. Dabei ist der Hintergrund für Schichten der Vergangenheit dunkelgrau hinterlegt
und für die gegenwärtige Schicht ( ) hellgelb gekennzeichnet.
75. Vgl. Facility_Plan und Other_Plan.
Saktuell S0
HousingA_Links
CaliperA_Links
HolderA
HousingA_Rechts
CaliperA_Rechts
HolderA
Abbildung 62: Erzeugnisstruktur am Fallbeispiel
Saktuell
Kapitel 5: Konzeption 157
Vertikal besteht die Planungsoberfläche aus vier Blöcken. Im ersten Block werden die Despat-
ches bzw. Requirements gezeigt. Der zweite Block zeigt die Rückmeldungen aus dem Ferti-
gungsprozess auf und erlaubt für die Zukunft die manuelle Erstellung bzw. Modifikation der
geplanten Fertigungslose (Facility_Plan) auf der Ressource. Auf der Basis der geplanten Ferti-
gungslose innerhalb einer Schicht und den im Stammdatenmodell spezifizierten Restriktionen
bezüglich des Kapazitätsangebotes werden im dritten Block ressourcenspezifische Kapazitäts-
informationen, die in einer Instanz der Klasse Capacity_Info aufbereitet wurden, dargestellt.
Im untersten Block werden die projizierten Bestände zum Ende der Schicht wiedergegeben.
Abbildung 64 stellt das Klassenmodell zur Aufbereitung und Darstellung der fertigungsrele-
vanten Informationen für eine Ressource einer Dispositionseinheit vom „Typ 3“76 dar. Hierbei
findet analog, zu der bedarfsorientierten Sicht für eine Ressource und einen Zeithorizont die
Aufbereitung der Informationen für eine angebotsorientierte Sicht statt. Dazu werden für jede
Output-Faktorart (Parts_On_Facility), die auf der ausgesuchten Ressource (Facility) gefertigt
werden kann, die Input-Faktorarten (Used_For_Parts) ermittelt, zu denen eine Consist_Of-
76. Vgl. Abbildung 60.
Abbildung 63: Planungsoberfläche einer bedarfsorientierten Sicht
Bedarfs-bzw. Versand-meldungen (Output-Faktorarten)
Kapazitäts-informationen
ProjizierteBestand(Output-Faktorarten)
PlanwerteundUmrüstzeiten(Output-Faktorarten)
158 Kapitel 5: Konzeption
Beziehung besteht.77 Anschließend wird für jede Input-Faktorart der Initialbestand, analog zu
der bedarfsorientierten Sicht, ermittelt. Zur Berechnung des projizierten Bestandes für eine
Input-Faktorart (Projected_Supply_Stock) werden neben den geplanten Bestandsumbuchun-
gen die geplanten Zu- und Abgänge herangezogen. Die geplanten Zugänge (Bruttoangebote)
einer Input-Faktorart werden durch die Summe der für eine Schicht gemeldeten Lieferantenan-
gebote78 durch die Klasse Quotations für den Zeithorizont abgebildet. Dagegen erfolgt die
Ermittlung der geplanten Abgänge durch eine Stücklistenauflösung zum einen aus den geplan-
ten Fertigungslosen der bereits durch Parts_On_Facility bestimmten Output-Faktorarten
(Facility_Plan, Other_Plan) und zum anderen aus den geplanten Fertigungslosen anderer Out-
put-Faktorarten (Other_Successors_Parts), die nicht aus der Ressource gefertigt werden kön-
nen. Für die Vergangenheit stellt die Klasse Deliveries die Summe der Zugänge einer Input-
Faktorart dar. Dagegen können die Abgänge aus den Part_actuals und actual_qty in
Other_Successors_Parts berechnet werden.
77. Vgl. Klassenbeziehung in Abbildung 48.78. Vgl. Klasse Supplier_Quotations in Abbildung 58.
Facility Parts_On_FacilityUsed_For_Parts
...quantity[0, shifts_in_week-1]
Initial_Stockquantity
Projected_Supply_Stock
...quantity[0, num_shifts-1]
Other_Successors_Parts
...
plan_qty[0, num_shifts-1]
Facility_Plan
...
quantity[0, num_shifts-1]
quantity[0, num_shifts-1]
0..*1..1 ItsPredecessors
1..* 1..*
1..*
1..*
1..11..11..11..1
1..1 1..1
1..11..1
1..1
1..1
sequence[0, num_shifts-1]Movements
...
1..11..1
Abbildung 64: Klassenmodell zur Bildung einer angebotsorientierten Sicht
1..1
Quotations
...quantity[0, num_shifts-1]
Deliveries
...quantity[0, num_shifts-1]
1..1
Other_Plan
...quantity[0, num_shifts-1]
Part_Actuals
...quantity[0, num_shifts-1]
1..1
actual_qty[0, num_shifts-1]
1..1
Kapitel 5: Konzeption 159
In Abbildung 65 ist die realisierte Planungsoberfläche einer angebotsorientierten Sicht am Bei-
spiel der Montagelinie AssemblyLine_01 aufgezeigt.79 Dabei weist die Planungsoberfläche
grundsätzlich einen ähnlichen Aufbau wie die bereits in Abbildung 63 dargestellte Planungs-
oberfläche auf. Jedoch werden im ersten bzw. letzten Block die geplanten Lieferungen (Brutto-
angebote) bzw. der projizierte Bestand der Input-Faktorarten dargestellt. Dadurch sollen die
Auswirkungen der Planungsentscheidungen des Disponenten auf die Bestandsentwicklung der
Input-Faktorarten veranschaulicht werden.
5.3.4.2.2 Belegungsplanung am Fallbeispiel
In diesem Kapitel soll ein Verfahren zur Belegungsplanung der Dispositionseinheit Montage80
im Pilotwerk vorgestellt werden. Dabei besteht die Aufgabe bei der Belegungsplanung darin,
ausgehend von den offenen Kundenaufträgen, den verfügbaren Beständen und unter Berück-
sichtigung der Kapazitätsrestriktionen für einen Planungshorizont eine zulässige (möglichst
optimale) Zuordnung der Aufträge zu den Montagelinien zu erstellen, die beschreibt, wie viele
79. Auch hier ist die in Abbildung 62 dargestellte Erzeugnisstruktur zugrunde gelegt worden.80. Vgl. Kapitel 5.3.2.2.
Abbildung 65: Planungsoberfläche einer angebotsorientierten Sicht
GeplanteZugänge(Input-Faktorarten)
PlanwerteundUmrüstzeiten(Output-Faktorarten)
Kapazitäts-informationen
ProjizierteBestand(Input-Faktorarten)
160 Kapitel 5: Konzeption
Teile auf welcher Montagelinie wann gefertigt werden können. Die Kapazitätsrestriktionen
umfassen einerseits Vorgaben aus dem Lieferkettenmodell wie die Verfügbarkeiten der Mon-
tagelinien und Teams in jeder Schicht des Planungshorizontes und die Umrüstzeiten sowie
andererseits Nebenbedingungen wie den Sicherheitsbestand und die Mindestlosgröße für jede
Output-Faktorart, die als Steuerungsparameter für jede Belegungsplanung verändert werden
können. Als wichtigste Zielfunktion soll die Minimierung der Terminüberschreitungen bei der
Erfüllung der Kundenbedarfe angesehen werden. Das daraus entstehende Schedulingpro-
blem81 kann als NP-hart klassifiziert82 werden.
Um die Belegungsplanung zu unterstützen, wurde in Absprache mit den Disponenten im Pilot-
werk eine Heuristik entwickelt (vgl. Abbildung 67), die basierend auf das Lieferkettenmodell
und den Steuerungsparametern einen zulässigen Belegungsplan für die Montagelinien gene-
riert. Zu dem generierten Belegungsplan lassen sich Kennzahlen (Bzgl. Termintreue, Umrüst-
häufigkeit und -anteile sowie Kapazitätsauslastung) berechnen, die Entscheidung über die
Annahme eines Planes bleibt jedoch dem Disponenten in einer manuellen Bewertung vorbe-
halten. Der Disponent kann den generierten Plan modifizieren83, ggf. Teile des Planes fixieren
und über die Modifikation der Steuerungsparameter die automatische Belegungsplanung
anstoßen (vgl. Abbildung 66). Somit kann der Disponent den Planungsprozess mit veränderten
Steuerungsparametern beliebig iterieren bis er zu einem zufriedenstellenden Ergebnis kommt.
81. Ein Schedulingproblem besteht darin, eine bestimmte Anzahl (N) von Aufträgen (jobs) einer bestimm-te Anzahl von Maschinen (M) zuzuordnen. Gesucht wird dabei eine Zuordnung von einem oder mehrerenZeitintervallen für jeden Auftrag auf eine oder mehrere Maschinen. (vgl. [Bruc95], S.1).82. Vgl. [Muec99], S.66. Dort wurde eine polynomielle Reduktion des beschriebenen Problems auf das„Traveling Salesman“-Problem durchgeführt. 83. Die Ergebnisse der Belegungsplanung für eine Montagelinie können durch die in den Abbildungenvorgestellten Planungsoberflächen bereitgestellt werden. Dort können einerseits die Auswirkungen deserstellten Belegungsplans aufgezeigt und ggf. erforderliche manuelle Modifikationen vorgenommen wer-den.
Modell derDispositions-einheit
Steuerungsparameter-Sicherheitsbestand-Mindestlosgröße-Fixierungshorizont-Vorgriffshorizont-Planungshorizont
AutomatischeBelegungsplanung
Zulässige Belegungsplan
Mod. Belegungsplan
Man. Modifikationund ggf. Fixierungvon Losen
Abbildung 66: Planungsablauf am Fallbeispiel
Kapitel 5: Konzeption 161
Als Steuerungsparameter werden neben den output-faktorart-spezifischen Steuerungsparame-
tern, Sicherheitsbestand und Mindestlosgröße, der Vorgriffs- und Planungshorizont sowie der
Fixierungshorizont betrachtet. Die Ausprägungen der Steuerungsparameter stellen weitere
Restriktionen für die Erstellung des Belegungsplan dar. So gibt der Sicherheitsbestand die
Zahl an, die der projizierte Bestand der spezifischen Output-Faktorart nicht unterschreiten
darf. Ähnlich stellt die Mindestlosgröße die minimale Menge der Output-Faktorart dar, die für
die Bildung eines Fertigungsloses eingesetzt werden kann. Der Fixierungshorizont legt den
Zeitraum ab der „Gegenwart“ fest, in dem keine Änderungen an den bereits ermittelten Bele-
gungsplänen vorgenommen werden dürfen. Der Planungshorizont lässt sich über die Anzahl
der zu planenden Wochen und die erste zu planende Schicht bzw. das Ende des Fixierunshori-
zontes spezifizieren. Der Vorgriffshorizont gibt die Zeitspanne an, deren Bedarfe bei der Bele-
gungsplanung für die Bildung von Fertigungslosen betrachtet werden können.
Die entwickelte Heuristik für die Belegungsplanung und der Einfluss der Steuerungsparame-
tern auf die Belegungsplanung werden im Folgenden grob beschrieben (vgl. Abbildung 67).
Zunächst wird der Planungshorizont84 schichtweise durchlaufen und dabei für jede Output-
Faktorart, die am Ende der betrachteten Schicht eine Unterschreitung des Sicherheitsbestandes
(stockviolation( )) aufweist, ein Fertigungslos generiert (compute_lot_vector( )). Dazu werden
die Bruttobedarfe innerhalb eines vom Disponenten vorgegebenen Vorgriffshorizontes, unter
84. num_shifts gibt die Schichten im Planungshorizont wieder.
For s=1 to num_shifts do Parts={ | stockviolation(p, s)};
For each compute_lot_vector(p, s)=: lv(p, s);
While doFor each , do
e[p, ]= evaluate(p, , lv(p, s))odbest= find_best(e);schedule(best.p, best. , lv(best.(p, s)));Parts= Parts - {best.p};
odod
Adjust_Lots_According_To_Due_Date( );
p A∈
p Parts∈
Parts ∅≠p Parts∈ Mk M∈( )∀
Mk Mk
Mk
Abbildung 67: Grober Aufbau der Heuristik
162 Kapitel 5: Konzeption
Berücksichtigung der Mindestlosgröße und des Sicherheitsbestandes, zu einem Los zusam-
mengefasst. Anschließend werden die gebildeten Fertigungslose versuchsweise auf allen mög-
lichen Montagelinien eingeplant (evaluate( )) und dabei eine Bewertung vorgenommen, wobei
als Zielkriterien die Einhaltung der Fälligkeitstermine, die Minimierung der Bestände und die
Umrüstzeiten gewichtet berücksichtigt werden (find_best( )). Auf der Grundlage dieser Bewer-
tung wird dann ein Fertigungslos ausgewählt und, zunächst so früh wie möglich, auf der ent-
sprechenden Montagelinie fest eingeplant (schedule( )).
Dieser Vorgang der versuchsweisen Einplanung von Fertigungslosen, Bewertung, Auswahl
und schließlich festen Einplanung eines Loses wird solange iteriert, bis alle Fertigungslose des
betrachteten Vorgriffshorizonts eingeplant sind und mit der nächsten Schicht fortgefahren wer-
den kann. Nach der Bearbeitung des gesamten Planungshorizontes werden in einer abschlie-
ßenden Phase, ausgehend von der letzten Schicht des Planungshorizonts, die Lose bei
frühzeitiger Fertigstellung in Richtung ihrer Fälligkeitstermine verschoben, wobei eine
schichtgenaue Befriedigung der gemeldeten Bedarfe angestrebt wird
(Adjust_Lots_According_To_Due_Date( )). Das Verfahren hat Laufzeitkosten von
, wobei numshifts die Anzahl der Schichten im betrachteten Planungs-
horizont, e die Anzahl der Output-Faktorarten und m die Anzahl der Montagelinien darstellen.
Dadurch kann eine Belegungsplanung in kurzer Zeit85 erstellt werden und somit eine höhere
Planungsfrequenz erreicht werden.86
5.3.4.3 Komponente zum Bestandsmanagement
Aufgabe der Bestandsmanagement-Komponente ist das Anlegen und Verwalten der Bestände
und der Bestandsumbuchungsereignisse der Faktorarten einer Dispositionseinheit. Dazu sind
zunächst die zu führenden Bestandstypen87 und die Bestandsumbuchungstypen88 festzulegen.
Anschließend können die Bestandsumbuchungen in Form von Um-, Ab- oder Zubuchungen
bzw. Inventurmeldungen schichtweise manuell erfasst werden. Dabei wird eine Bestandsum-
buchung bei der Eingabe mit einem Gültigkeitsdatum versehen. Während sich die geplanten
85. Die Implementierung des Verfahrens erstellt für einen Planungshorizont von 12 Wochen, ca. 100 Out-put-Faktorarten und 11 Montagelinien einen Belegungsplan in weniger als 2 Minuten. 86. Vgl. Anforderung 3.3.87. Vgl. Stock_Type in Abbildung 58.88. Vgl. Movement_Type in Abbildung 58.
O numshifts2 e2 m⋅ ⋅( )
Kapitel 5: Konzeption 163
Bewegungen auf die gegenwärtigen bzw. zukünftigen Schichten beziehen können, werden die
bereits erfolgten Bewegungen der vergangenen Schicht zugeordnet.
Insgesamt findet die Bestandsdokumentation durch die beim System-Setup zu bestimmenden
Anfangsbestände und die schichtweise Erfassung der Bestandsumbuchungen statt. Für das
Bestandsmanagement in den Dispositionseinheiten im Pilotwerk wurden neben den Bestands-
typen OnHold89 und Stock90 sieben Bestandsumbuchungstypen unterschieden. Hierbei handelt
es sich bei den Bestandsumbuchungstypen um Um- bzw. Abbuchungen zwischen bzw. von
den Bestandstypen und Zubuchungen zu dem verfügbaren Bestand sowie Inventurmeldungen
zur Korrektur der Bestände der beiden Bestandstypen.
Die Aufgabe der Bestandsmanagement-Komponente kann auf das Bestandsmonitoring einge-
schränkt werden, falls das umgebende ERP/PPS-System über die benötigten Bestandsinforma-
tionen der Faktorarten verfügt. Dazu können die Bestandsinformationen über eine Schnittstelle
aus dem ERP/PPS-System importiert und somit eine doppelte Bestandsführung vermieden
werden.91
5.3.4.4 Schnittstellen zum Bewegungsdatenaustausch
In diesem Abschnitt sollen die Möglichkeiten des Bewegungsdatenaustausches zwischen dem
FMI- und dem ERP/PPS-System betrachtet werden. Ziel ist es hierbei, einerseits durch die
Nutzung bereits bestehender Erfassungsmöglichkeiten der Bewegungsdaten den Aufwand bei
der Einführung und dem Betrieb des FMI-Systems zu reduzieren und andererseits die ggf.
erforderliche Synchronisation der Bewegungsdaten beider Systeme durchzuführen. Dabei geht
es neben den Fragen, wie die Schnittstellen zu gestalten und welche Daten auszutauschen sind,
darum, den Zeitpunkt und die Häufigkeit des Bewegungsdatenaustausches sowie den Zeit-
raum, auf den sich die Bewegungsdaten beziehen, zu bestimmen.
Bezüglich der Schnittstellengestaltung bieten sich die in Kapitel 5.3.3.2 bereits vorgestellten
Möglichkeiten an, wobei die Realisierung des Datenaustausches über einen File-Transfer in
einem neutralen Format (aufgrund der damit verbundenen Flexibilität bei der Integration mit
verschiedenen ERP/PPS-Systemen) geeignet erscheint. Dazu ist es notwendig, den Ablauf der
89. Zu prüfender Bestand.90. Verfügbarer Bestand.91. Vgl. Kapitel 5.3.4.4.
164 Kapitel 5: Konzeption
Importe und Exporte zeitlich festzulegen, um Konflikte beim Zugriff auf die Dateien und
Inkonsistenzen der auszutauschenden Daten zu vermeiden.
Die Frage, welche Bewegungsdaten ausgetauscht werden können, soll hier aus der Sicht des
FMI-Systems betrachtet werden. Dabei können grundsätzlich in Abhängigkeit von der Ablauf-
und Informationsstruktur die Zu- bzw. Abgangsereignisse und die Bestandsumbuchungsereig-
nisse, falls vorhanden, aus dem ERP/PPS-System importiert werden. In Bezug auf die Ablauf-
richtung können insbesondere die zum Anstoß der Planung notwendigen Bedarfe und/oder
Angebote über das ERP/PPS-System bezogen werden. Dagegen bestimmt die zugrunde lie-
gende Informationsstruktur in einer Dispositionseinheit, an welchen Positionen der Prozess-
struktur der Fortschritt des Fertigungsablaufs gemessen wird. Daher lassen sich aus den an
diesen Positionen im ERP/PPS-System92 erfassten Rückmeldungen aus den Fertigungsprozes-
sen „IST“-Ereignisse an das FMI-System weitergeben, die zur Bewertung des tatsächlichen
Fertigungsfortschritts verwendet werden können.
Aus dem FMI-System können insbesondere die Ergebnisse der Belegungsplanung und die da-
raus abgeleiteten Zu- bzw. Abgänge an das ERP/PPS-System gemeldet werden und ggf. für
weitere Aktivitäten, wie z.B. zur Ermittlung der Sekundärbedarfe, eingesetzt werden.
Bei der Umsetzung im Pilotwerk erfolgt der Datenaustausch für jede Dispositionseinheit wie
in Abbildung 68 skizziert. Da es sich um Dispositionseinheiten vom „Typ 6“ handelt, stellen
die Kundenbedarfe die Ausgangsbasis für die Belegungsplanung dar.93 Daher werden in die-
sem Falle die bereits im ERP/PPS-System erfassten Kundenbedarfe94 täglich in ein Text-File
mit vordefiniertem Format95 übergeben und in das FMI-System eingelesen. Dabei erfolgt ggf.
92. Oder dem Betriebsdatenerfassungssystem (BDE).93. Vgl. Abbildung 60 und Abbildung 47.94. Vgl. Kapitel 5.3.2.1. Dabei werden die vorhandenen Kundenbedarfe für die nächsten 6 Monate be-rücksichtigt.95. Auch hier existieren neben den „Standard“-Feldern wie Kundennummer, Output-Faktorart, Datumund Quantität „optional“-Felder, die nur bei Bedarf mit übergeben werden.
Kapitel 5: Konzeption 165
eine Splittung der Kundenbedarfe auf Schichtbasis gemäß den in Disaggregation_Rules96
kundenspezifisch aufgestellten Regeln.
Weiterhin werden zur Bestandsführung im FMI-System und zur Bewertung des Fertigungsge-
schehens97 die Abgänge an die Kunden und die Abgänge der Fertigungsprozesse aus der Ver-
gangenheit benötigt. Dazu werden die Versand- und Fertigungsrückmeldungen auf
Schichtbasis in das ERP/PPS-System gebucht und täglich in einer Übergabedatei mit vordefi-
niertem Format98 fortgeschrieben. Hierbei wird besonders darauf geachtet, dass die gemelde-
ten Kundenbedarfe und Versandmeldungen sich auf den gleichen Erfassungszeitpunkt
beziehen. Damit soll vermieden werden, dass Kundenbedarfe weitergegeben werden, für die
bereits Versandmeldungen erstellt wurden oder umgekehrt. Um Fehler bei der Erfassung im
ERP/PPS-System korrigieren zu können, werden ausgleichende Meldungen, die sich auf die
letzten vergangenen vier99 Wochen beziehen können, zugelassen. Optional können auch die
Bestandsumbuchungen, falls vorhanden, aus dem ERP/PPS-System importiert werden. Dazu
ist zunächst eine eindeutige Zuordnung der Bestandsumbuchungstypen der beiden Systeme im
FMIS erforderlich. Weiterhin muss gewährleistet werden, dass durch die Möglichkeiten der
96. Vgl. Abbildung 50.97. Z.B. zur Durchführung von Soll-Ist-Vergleichen und/oder zur Berechnung von Kennzahlen.98. Das Format hängt von der Meldungsart (Despatches, Actuals) ab.99. Dies ist über einen Parameter zur Konfiguration der Schnittstelle auf Seiten des FMI-Systems einstell-bar. Im Pilotwerk beträgt der Fixierungshorizont einen Tag.
Abbildung 68: Skizze des Schnittstellenmanagements
Disaggregationrules
Umrechnungauf Schichtbasis
Bedarfsmeldungen aufTages- bzw. Wochenbasisaus dem ERP/PPS-System Versandmeldungen aus
dem ERP/PPS-System
Bedarfe aufSchichtbasis
Synchronisationder Bedarfs- undVersandmeldungen
Fertigungs- und ggf.Bestandsrückmeldungenaus dem ERP/PPS-System
Import in dasFMI-System
ERP/PPS-System FMI-System
ERP/PPS-SystemFMI-System
„Export“-Fixierungs-horizont
Übernahme-horizont
Aufbereitungder Daten ggf.auf Tagesbasis
Zu exportierendeBelegungsplan
Export desBelegungs-plans
166 Kapitel 5: Konzeption
Importierung und der manuellen Erfassung in der Bestandsmanagement-Komponente keine
Inkonsistenzen auftreten.
Abbildung 69 zeigt, aus Benutzersicht, die hier realisierte Schnittstelle zum Import der Kun-
denbedarfe, Versand- und Fertigungsrückmeldungen sowie ggf. Bestandsumbuchungen auf.
Dabei erfolgt das Einlesen der jeweiligen Übergabedatei durch Drücken des entsprechenden
„Import“-Buttons. Um sicherzustellen, dass die aus dem ERP/PPS-System exportierten Daten
korrekt erfasst werden, sind die folgenden Festlegungen getroffen worden. Die „Kundenbe-
darfsdatei“ wird bei jedem Exportvorgang überschrieben. Bei dem Importvorgang werden die
gesamten Kundenbedarfe im FMIS ersetzt und die „Kundenbedarfsdatei“ unverändert gelas-
sen. Dagegen werden die Versand- und Fertigungsrückmeldungen bei jedem Exportvorgang
fortgeschrieben. Ferner werden bei jedem Importvorgang in das FMIS die korrekt importierten
Datensätze aus der Datei gelöscht. Ähnlich erfolgen die Exporte und Importe der Bestandsum-
buchungsdaten.
Neben dem Import der Kundenbedarfe sowie der Versand- und Fertigungsrückmeldungen aus
dem ERP/PPS-System besteht die Möglichkeit, für jede Dispositionseinheit die Ergebnisse der
Belegungsplanung aus dem FMI-System über ein Text-File an das ERP/PPS-System zu expor-
tieren. Dazu wird für jede Dispositionseinheit ein Fixierungs-100 und ein Übernahmehorizont
100. Der „Export“-Fixierungshorizont ist immer kleiner oder gleich dem Fixierungshorizont der Bele-gungsplanung (vgl. Kapitel 5.3.4.2.2) der Dispositionseinheit.
Abbildung 69: Import-Management der Bewegungsdaten
Kapitel 5: Konzeption 167
bestimmt. Der Fixierungshorizont legt ausgehend von der aktuellen Schicht den Zeitraum fest,
für den keine Belegungsdaten exportiert werden dürfen. Dadurch kann gewährleistet werden,
dass die bereits für den kurzfristigen Bereich ausgelösten Beschaffungsaktivitäten (Materialbe-
reitstellung) im ERP/PPS-System nicht ständig geändert werden müssen. Mit dem Übernah-
mehorizont wird die Anzahl der Wochen ab dem Fixierungshorizont bestimmt, für die
Belegungsdaten zu exportieren sind. Dabei werden für jede Output-Faktorart die geplanten
Fertigungslose ressourcenweise auf Tages- bzw. Schichtbasis in einem Text-File mit vordefi-
niertem Format weitergegeben. Die Übertragung der Belegungsplanungergebnisse erfolgt in
der Regel täglich, wobei die alten Belegungsdaten im Übernahmehorizont bei jeder Übertra-
gung im ERP/PPS-System ersetzt werden.
168 Kapitel 5: Konzeption
5.3.5 Komponenten zum Kooperationsmanagement
Aufgabe der Komponenten zum Kooperationsmanagement ist die Unterstützung der Informa-
tionsflüsse zwischen den Dispositionseinheiten. Dazu soll zunächst in Kapitel 5.3.5.1 eine
Interaktionskomponente entworfen werden, die den Informationsfluss zwischen zwei dezen-
tralen Einheiten des FMI-Systems realisiert. Anschließend wird in Kapitel 5.3.5.2 eine Inter-
net-basierte Komponente vorgestellt, die es ermöglichen soll, aufbauend auf den bereits
definierten Informationsprofilen, den benachbarten Dispositionseinheiten Informationen über
das Fertigungsgeschehen bereitzustellen. Die prototypische Umsetzung der beiden Kompo-
nenten soll anhand von zwei Beispielen aufgezeigt werden. Dazu soll in Kapitel 5.3.5.1.4 die
Funktionalität der Interaktionskomponente am Beispiel eines Lieferanten und in Kapitel
5.3.5.2.2 die Funktionalität der Internet-basierten Komponente am Beispiel eines Kunden vor-
gestellt werden.
5.3.5.1 Entwurf der Interaktionskomponente
Ziel der Interaktionskomponente ist die Integration der dezentralen Einheiten des FMI-
Systems.101 Um dieses Ziel zu erreichen, soll die Interaktionskomponente, entsprechend den
in Kapitel 5.3.3.1.2 spezifizierten Eigenschaften der Beziehungen, einerseits die benötigten
Informationen aufbereiten können und andererseits die Kommunikation mit „entfernten“
dezentralen Einheiten des FMIS-Systems ermöglichen. Dazu wird in Kapitel 5.3.5.1.1 aufge-
zeigt, wie die benötigten Informationen aufbereitet und verwaltet werden. In Kapitel 5.3.5.1.2
erfolgt die Auswahl einer Kommunikationstechnologie, auf deren Basis in Kapitel 5.3.5.1.3
die Kommunikationskomponente entworfen wird. Um die Wiederwendbarkeit und die Flexibi-
lität der zu entwerfenden Klassen zu erhöhen, wird im Folgenden das sog. Model-View-Con-
troller-Paradigma (MVC) verfolgt.102 Dabei sind die Klassen, deren Bezeichnung mit
„Container“ oder „Flyweight“ beginnen, dem MVC-Model zuzuordnen. Sie werden zur Daten-
verwaltung verwendet. Ähnlich werden die Klassen mit den Namen „Hashtable“ zur Datenhal-
tung eingesetzt.
101. Vgl. Anforderungen 3.1.102. Das MVC-Paradigma wird durch drei Objekte umgesetzt. Das Model-Objekt stellt das abzubildendeDatenmodell dar, das View-Objekt umfasst die visuelle Darstellung, die dem Benutzer präsentiert wird,und das Controller-Objekt, das die eigentliche Anwendung beinhaltet und die bestimmt, wie mit der Be-nutzungsschnittstelle interagiert wird (vgl. [GHJV96]).
Kapitel 5: Konzeption 169
5.3.5.1.1 Informationsmodell
Ausgangsbasis für die Informationsaufbereitung stellen die in Abbildung 50 spezifizierten
Beziehungen und die in Abbildung 58 angegebenen Klassen zur Beschreibung der Bewe-
gungsdaten dar. Dazu wird im Folgenden aufgezeigt, wie die Informationsaufbereitung für
Lieferanten vollzogen wird.103
Um die an den Lieferanten weiterzuleitenden Bedarfe individuell generieren zu können, wer-
den sog. Informationspools eingesetzt. Ein Informationspool sammelt die Informationen auf,
die für die Erstellung der Bedarfe an einen Lieferanten notwendig sind und stellt somit die
Quelle für die Informationsflüsse dar. Dafür besteht ein Informationspool im Wesentlichen aus
ineinander geschachtelten Hashtabellen104 und Container-Klassen105, die Informationen auf-
bereiten und zum Austausch bereithalten. Bevor das Klassenmodell eines Informationspools
beschrieben wird, soll der Ablauf der Informationspoolerstellung betrachtet werden. Abbil-
dung 70 zeigt die an diesem Vorgang beteiligten Klassen auf.
103. Die Informationsaufbereitung für die Kunden erfolgt auf ähnliche Weise und soll daher nicht weiterbeschrieben werden. 104. Eine Hashtabelle ist eine Datenstruktur, die es erlaubt, eine Menge von Datensätzen zu speichernund dabei die Operationen Suchen, Einfügen und Entfernen unterstützt. Jeder Datensatz ist gekennzeich-net durch einen eindeutigen Schlüssel. Dabei wird bei der Suche durch eine Berechnung (Hashfunktion)versucht, die Position des Datensatzes festzustellen. Hashtabellen erlauben sehr schnelle Operationen aufihren Datensätzen und sind anderen elementaren Datenstrukturen wie Listen, Bäumen etc. in Bezug aufdie Ausführungszeit ihrer Operationen im Mittel überlegen (vgl. [OtWi93], S. 201ff.).105. Eine Container-Klasse hat die Aufgabe, Objekte anderer Klassen zu verwalten (vgl. [Burk97], S.65).
170 Kapitel 5: Konzeption
Die Klasse Manager_Supplier stellt das zentrale Element bei der Erstellung des Informations-
pools dar. Sie wird durch das Controller-Objekt, das beim Systemstart kreiert wird und somit
die Wurzel des Informationspools darstellt, instanziiert.
Anschließend werden durch das Manager_Supplier-Objekt Instanzen der Klassen
Parts_Input_Required, Parts_Input_Resolved und Parts_Input_Unsolved erzeugt, die wie-
derum Informationen über die Bedarfssituation in der betrachteten Dispositionseinheit, in
Form von Hashtabellen, beinhalten. Während Parts_Input_Required alle Bedarfe an Input-
Faktorarten umfasst, beinhaltet Parts_Input_resolved die bereits zugesagten Lieferungen.
Parts_Input_Unsolved wird aus der Differenz der beiden gebildet und repräsentiert somit die
offenen Bedarfe.
Für die Verwaltung der Informationspools erzeugt das Manager_Supplier-Objekt eine Instanz
der Klasse Supplier_Pool mit den beiden Instanzen der Klassen Parts_Input_Unsolved und
Parts_Input_Required als Parameter. Das Supplier_Pool-Objekt erzeugt eine Hashtabelle
(Hashtable_Supplier_Pool), in der für jeden Lieferanten ein separater Informationspool
(Container_Supplier_Pool) hinterlegt wird.
Container_Supplier_Pool
Supplier_Pool
0..*
1..1
1..1
1..1
1..1
Hashtable_Supplier_PoolController
Manager_Supplier
Parts_Input_Resolved
Parts_Input_Unsolved
Parts_Input_Required
1..1 1..1
1..1
1..1
1..1
1..1 1..1
1..1
1..1
1..1 1..1
1..1
1..1
Abbildung 70: Klassenmodell zur Erstellung der „Informationspools“
Kapitel 5: Konzeption 171
In Abbildung 71 ist das eigentliche Klassenmodell zur Beschreibung der Informationspools
der Lieferanten dargestellt. Demnach existiert für jeden Lieferanten ein Eintrag in der
Hashtable_Supplier_Pool, der über eine eindeutige ID erreicht werden kann.106
Ein Container_Supplier_Pool-Objekt umfasst einerseits die lieferantenspezifischen Informa-
tionen zur Gestaltung der Informationsflüsse und andererseits faktorartspezifische Informatio-
nen zur Erstellung der Bedarfe. Dazu werden zum einen in der Hashtable_Flyweight_Part die
Input-Faktorarten gehalten, die vom jeweiligen Lieferanten bezogen werden können und zum
anderen Hashtabellen, die die aktuellen Bedarfe und Lieferzusagen festhalten. In der Hashta-
belle ShouldBeOrdered wird für jede Input-Faktorart über ein Container_Part-Objekt festge-
legt, welche Bedarfe vom Lieferanten zu bestellen bzw. bereits bestellt sind. Dazu werden die
Bedarfe durch die Klassen Hashtable_Calender_Week und Container_Calender_Week
wochenweise auf Schichtbasis abgebildet. Analog dazu werden in der Hashtabelle AlreadyOr-
dered über ein Container_Part-Objekt die bereits erfolgten Lieferzusagen festgehalten.
106. Vgl. Attribut Partner_id der Klasse Partner in Abbildung 50.
Container_Supplier_Pool
Supplier_PoolHashtable_Supplier_Pool
Hashtable
Hashtable_Parts
Hashtable_Calender_Week
Container_Part
Hashtable_Flyweight_Part
Flyweight_Part
Container_Calender_Week
1..1
1..1
0..*
1..1
1..1
1..1
1..11..1
1..10..*
1..11..1
1..10..*
1..1
0..*
1..11..1
Abbildung 71: Klassenmodell zur Darstellung der Informationspools
CouldBeDelivered
ShouldBeOrdered
AlreadyOrdered
172 Kapitel 5: Konzeption
5.3.5.1.2 Auswahl der Kommunikationstechnologie
Um die Informationsflüsse zwischen den dezentralen Einheiten des FMI-Systems zu realisie-
ren, ist eine geeignete Kommunikationstechnologie auszuwählen, auf der die Kommunikati-
onskomponente aufbaut. Dabei soll einerseits insbesondere das in Kapitel 5.2.2.1 beschriebene
Kommunikationsmodell zwischen den Dispositionseinheiten durchgeführt werden können und
es andererseits keinen Unterschied hervorrufen, ob die lokalen Einheiten des FMI-Systems
sich im Intranet desselben Unternehmen befinden oder verteilt auf unterschiedliche Unterneh-
men via Internet zu verbinden sind.
Grundsätzlich erfüllen alle in Kapitel 3.3.1.1.1 aufgeführten Modelle zur Realisierung von ver-
teilten Systemen die oben gestellten Anforderungen. Jedoch ist eine Umsetzung der Kommu-
nikationskomponente auf der Basis von CORBA durch die erforderliche IDL-Programmierung
der sog. Stub- und Skeleton-Struktur mit einem hohen Aufwand verbunden.107 Weiterhin
kommt eine Umsetzung auf der Basis von DCOM aufgrund der eingeschränkten Betriebs-
systemauswahl nicht in Betracht.108 Dagegen bietet das RMI-Modell eine leistungsfähige
Kommunikationsplattform, die nicht über die Nachteile der anderen Kontrahenten verfügt.
Zwar ist RMI für eine reine „Java-zu-Java“ Kommunikation konzipiert, allerdings gibt es
Bestrebungen zur Integration von RMI und CORBA, durch die diese Einschränkung fallen
soll.109 Somit soll die Umsetzung der Kommunikationskomponente zur Interaktion zwischen
den dezentralen Einheiten des FMI-Systems auf der Basis des RMI-Modells erfolgen.
5.3.5.1.3 Kommunikationskomponente
Aufgabe der Kommunikationskomponente ist es, ausgehend von den verfügbaren Informati-
onspools und durch den Einsatz der Remote Invocation Methode (RMI) den Informationsfluss
zwischen den Dispositionseinheiten, welche unterschiedlichen dezentralen Einheiten des FMI-
Systems zugeordnet sind, zu realisieren. Abbildung 72 verdeutlicht, am Beispiel von zwei Dis-
107. Vgl. [Schulz00], S. 249ff.108. Vgl. Kapitel 3.3.1.1.1.109. Vgl. Kapitel 3.3.1.1.1.
Kapitel 5: Konzeption 173
positionseinheiten, den Aufbau der Interaktionskomponente und die Einordnung der Kommu-
nikationskomponente.
Die Realisierung der Informationsflüsse findet durch den räumlich entfernten Zugriff auf die
Informationspools statt. Dazu führt der Controller im Anschluss an die Aufbereitung der Infor-
mationspools110 eine Instantiierung der Klasse SecurityManager_FMI, welche von RMISecu-
rityManager111 erbt, aus (vgl. Abbildung 73). Das SecurityManager_FMI-Objekt legt das
Sicherheitskonzept fest, das bestimmt, welche Zugriffe auf die Informationspools ausgeführt
werden dürfen. Darüber hinaus lassen sich in der sog. Java.Policy-Datei weitere Sicherheitsre-
striktionen festlegen. Dort kann bestimmt werden, welche räumlich entfernten Rechner auf den
„eigenen“ Informationspool zugreifen dürfen und welche nicht. Dazu werden in der
Java.Policy-Datei die IP-Adressen der Rechner eingetragen, die auf den Informationspool
zugreifen dürfen. In einem weiteren Schritt übergibt das Controller-Objekt das
Manager_Supplier-Objekt an den Nameservice des RMIs (rmiregistry112). Dadurch können
die Clients113, die auf die Informationspools zugreifen wollen, zunächst eine Verbindung mit
dem Manager_Supplier-Objekt herstellen. Die dazu erforderliche Anfrage des Clients an den
110. Vgl. Kapitel 5.3.5.1.1.111. Diese Klasse erlaubt es lokalen wie entfernten Applikationen, RMI-Klassen und Schnittstellen an-zusprechen (vgl. [Schulz00], S. 259ff.). 112. Die rmiregistry führt eine Tabelle mit Objektnamen an und stellt bei Anfragen die Verbindung her.113. In dem hier dargestellten Modell bilden die Clients die Lieferanten ab.
ExterneKommunikation
Interne Informationspools
Interaktionskomp.
FMIS-Datenbasis FMIS-Datenbasis
Interaktionskomp.
Remote Invocation Methode(RMI)
Grenzen der Dispositionseinheiten
Abbildung 72: Aufbau der Interaktionskomponente
174 Kapitel 5: Konzeption
Nameservice beinhaltet neben den Namen auch die sog. uniform resource locator (URL)114
des Servers, auf dessen Informationspools der Client zugreifen möchte.
Um den räumlich entfernten Zugriff auf die Objekte des Informationspools durchführen zu
können, sind sog. Java-Interfaces zu realisieren, in denen alle Methoden und Attribute aufge-
führt sind, auf die ein räumlich entfernter Zugriff ermöglicht werden soll. In Abbildung 73 sind
Interface-Klassen aufgeführt, die aus der Interface-Klasse Remote115 erben; für den Zugriff
114. URL stellt den Verweis auf eine Ressource im Internet dar und umfasst neben dem Ort (d.h. Protokoll(z.B. http), IP-Adresse und Verzeichnis), auf den sie verweist, eine Methode des Zugriffs auf die Ressour-ce.
Supplier_Pool
Hashtable_Parts
Container_Calender_Week
Container_Part
Container_Supplier_Pool
HashtableSupplier_Pool
Controller
Manager_Supplier SecurityManager_FMI
RMISecurityManager
InterfaceManager_Supplier<<Interface>>
InterfaceContainer_Supplier_Pool<<Interface>>
InterfaceContainer_Part<<Interface>>
InterfaceContainer_Calender_Week<<Interface>>
Remote<<Interface>>
RemoteExecptionRemExc_ElementDoNotExist
UnicastRemoteObject
Hashtable_Calender_Week
Abbildung 73: Klassenmodell zur Realisierung des räumlich entfernten Objektzugriffs
1..1
1..1
1..1
1..1
0..*
0..*
0..*
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
Kapitel 5: Konzeption 175
sind die Methoden und Attribute der Klassen Manager_Supplier, Container_Supplier_Pool,
Container_Part und Container_Calender_Week aufgeführt. Die eigentliche Implementierung
der Interfaces erfolgt in den jeweiligen Klassen, die aus der Klasse UnicastRemoteObject116
erben.
5.3.5.1.4 Szenario „Supplier“
In diesem Abschnitt wird am Beispiel der Bedarfszuteilung auf die Lieferanten aufgezeigt, wie
die prototypische Umsetzung der Interaktionskomponente aus Benutzersicht erfolgte. Dazu
soll einerseits aus Kundensicht dargestellt werden, wie, ausgehend von den Sekundärbedarfen,
die Zuordnung der Bedarfe zu den Lieferanten durchgeführt werden kann, und andererseits,
wie die Kundenbedarfe beim Lieferanten disponiert werden können.
Dabei sind bei der Umsetzung der in Kapitel 5.2.2.4 beschriebenen dispositiven Nachrichten-
typen Vereinfachungen vorgenommen worden, die den Implementierungsaufwand reduzieren
und gleichzeitig für das Beispiel verdeutlichen, wie die dispositiven Nachrichtentypen abgebil-
det werden können. So soll kein Unterschied zwischen verbindlichen und unverbindlichen
Bedarfen gemacht werden.117 Im Folgenden werden Bedarfsmeldungen als Anforderungen
bezeichnet. Als Rückmeldung auf eine Anforderung soll ein Gegenvorschlag, der in Bezug auf
Mengen und Termine von der ursprünglichen Anforderung abweichen kann, erstellt werden
können. Eine Zustimmung soll als Gegenvorschlag darstellbar sein, der mengen- und termin-
mäßig der vorausgegangenen Anforderung entspricht. Eine Ablehnung ist dagegen als Gegen-
vorschlag mit der Menge „0“ darzustellen. Im Falle einer Ablehnung der Anforderung bzw.
eines Gegenvorschlages seitens des Lieferanten muss der Disponent auf der Kundenseite sei-
nen Fertigungsplan an die Rückmeldungen des Lieferanten anpassen und/oder die fehlenden
Mengen als Anforderung an andere Lieferanten weitergeben. Der Disponent hat aber auch die
Möglichkeit, die Auswirkungen der Ablehnung bzw. des Gegenvorschlages seiner Lieferanten
in Form einer Ablehnung bzw. eines Gegenvorschlages an seiner Kunden weiterzugeben.118
Weiterhin wird im Rahmen der prototypischen Implementierung unterstellt, dass die Kunden
115. Stellt ein Interface dar, das von allen Client-Interfaces erweitert werden muss, um entfernte Objekteansprechen zu können (vgl. [Schulz00], S. 259 ff.).116. Die Klasse UnicastRemoteObjekt realisiert eine Punkt-zu-Punkt-Kommunikation und stellt damitelementare Server-Funktionalitäten des RMI zur Verfügung.117. In Kapitel 5.2.2.2.2 wird zwischen (verbindlichen) Anforderungen und (unverbindlichen) Anfragenunterschieden.118. D.h. Eine Vorwärtsplanung erfolgt hier nur manuell statt. Eine automatische Vorwärtsplanung ist imRahmen der prototypischen Implementierung nicht realisiert worden.
176 Kapitel 5: Konzeption
jedem Gegenvorschlag des Lieferanten implizit zustimmen. Damit kann auf die explizite
Bestätigung der Zustimmung einer Anforderung verzichtet werden.
In Bezug auf das Gestaltungsmerkmal Auslösungsart der dispositiven Informationsflüsse ist in
der prototypischen Implementierung lediglich die manuelle Auslösungsart realisiert worden.
Jedoch lässt sich die Implementierung ohne größere Umstellung um die periodischen und
ereignisbasierten Auslösungsarten erweitern. Darüber hinaus lassen sich die beiden Auslö-
sungsarten durch die manuelle Auslösung abbilden.
Aus Disponentensicht erfolgt die Zuteilung der Sekundärbedarfe auf die Lieferanten, wie in
Abbildung 74 veranschaulicht, ausgehend von den Nettobedarfen.119 Die Zuteilungsergeb-
nisse werden in den jeweiligen Informationspools auf Schichtbasis festgehalten. Die Aufberei-
tung der Bedarfe in den Informationspools, entsprechend den lieferantenspezifischen
Gestaltungsmerkmalen, erfolgt erst bei der Initiierung des Informationsflusses.
Die manuelle Bedarfszuteilung findet, wie in Abbildung 75 gezeigt, wochenweise für jede
Input-Faktorart auf Schichtbasis statt. Dazu werden in der „Open Req“-Zeile die noch offenen
Bedarfsmengen der ausgewählten Input-Faktorart dargestellt.120 Die drei anderen Zeilen bil-
den den Zustand der Lieferabstimmung mit den in der links stehenden Auswahlliste selektier-
119. Der Zuteilungsvorgang kann manuell oder automatisch durchgeführt werden. Bei einer automati-schen Zuteilung sind Regeln zu spezifizieren, die für eine Faktorart, die von mehreren Lieferanten bezo-gen werden kann, festlegen, wie die mengenmäßige Bedarfszuteilung zu erfolgen hat. In der hiervorgestellten prototypischen Implementierung findet die Bedarfszuteilung manuell statt.120. Vgl. Klasse Parts_Input_Unsolved in Abbildung 70.
......
...Netto-bedarfedesKunden
Zuteilungder Netto-bedarfe andie Liefe-ranten
Informations-pool für Liefe-rant Zn
Informations-pool für Liefe-rant Z1
Informationsaufberei-tung entsprechend denGestaltungsmerkmalender dispositiven Infor-mationsflüsse
Bedarfe anLieferant Zn
Bedarfe anLieferant Z1
kundenseitig lieferantenseitig
Abbildung 74: Erstellung der Bedarfe an die Lieferanten
Kapitel 5: Konzeption 177
ten Lieferanten (Supplier2) ab. In der „Already Ordered“-Zeile werden die bereits zugesagten
Lieferungen dargestellt.121 Dagegen können in der „Changes“-Zeile für jede Schicht die
zusätzlich zu bestellenden Mengen (positive Zahl) bzw. die abzubestellenden Mengen (nega-
tive Zahl) der Input-Faktorart eingegeben werden. Die in der „Changes“-Zeile einzugebenden
Werte können erst über den „Commit values“ Button in den Informationspool eingetragen
werden122 (vgl. auch Abbildung 74). Die in den Informationspools eingetragenen Werte kön-
nen vom Lieferanten abgerufen und zur Erstellung eines Gegenvorschlages verwendet werden.
Um den Status der Bestellung für den Kunden festzuhalten, werden in der „Assigned Req“-
Zeile die bereits beim Lieferanten bestellten, aber noch nicht zugesagten Mengen dargestellt.
Das Abrufen der Bedarfe aus dem Informationspool des Kunden erfolgt aus Lieferantensicht
über den „Receive values“ Button (vgl. Abbildung 76).123 Dazu müssen zunächst der Kunde
121. Vgl. Klasse Supplier_Quotations in Abbildung 58.122. Vgl. Klasse Hashtable_Parts, die über ShouldBeOrdered aus dem Containter_Supplier_Pool er-reicht werden kann (vgl. Abbildung 71).123. Hierbei wird eine RMI-Verbindung zu den Informationspools beim Kunden hergestellt (vgl. Abbil-dung 73).
Abbildung 75: Zuteilung der Bedarfe an die Lieferanten
Auswahl desLieferanten
Von Supplier2 bereits zugesagte Lieferungen
Von Supplier2 bereits bestellte, aber noch nicht zugesagte Liefermengen
Änderungen gegen der bereits bestellten Liefermengen
Die gesamten offenen Bedarfe der Input-Faktorart „11-2261-9975-1-90“
178 Kapitel 5: Konzeption
und die zu disponierende Faktorart ausgewählt werden. Ferner werden auf der Kundenseite die
Bedarfe entsprechend den Gestaltungsmerkmalen der dispositiven Informationsflüsse aufbe-
reitet. Die Weiterverarbeitung der aus dem Informationspool generierten Bedarfe beim Liefe-
ranten erfolgt in Abhängigkeit von der Ausprägung des Gestaltungsmerkmals „Initiator“. Bei
einer „Push“-Ausprägung werden die Anforderungen des Kunden implizit positiv beantwortet
und die Bedarfe in die FMIS-Datenbank festgeschrieben.124 Dagegen findet bei einer „Pull“-
Ausprägung zunächst eine manuelle Disposition der Bedarfe, wie in Abbildung 77 gezeigt,
statt. Dazu werden in der „Requirement“-Zeile die aktuellen Kundenbedarfe aufgeführt. In der
„Accept. Req.“-Zeile werden, aufgrund der aktuellen Auslastungssituation beim Lieferanten,
die Gegenvorschläge eingetragen und mit dem „Process values“ Button an den Kunden weiter-
geleitet. Anschließend werden die mit den Gegenvorschlägen zugesagten Mengen als Bedarfe
in der FMIS-Datenbank festgeschrieben.
Beim Kunden wirken sich die Gegenvorschläge des Lieferanten einerseits entsprechend auf
die Werte in den Zeilen „Open Req.“ und „Already ordered“ und andererseits in Form von Dif-
ferenzen zwischen den ursprünglichen Anforderungen und den Gegenvorschlägen, die in der
„Assigned Req.“-Zeile angezeigt werden, aus (vgl. Abbildung 75). Bedarfe, die von einem Lie-
feranten nicht erfüllt werden können, lassen sich ggf. modifizieren und in Form von neuen
Anforderungen an weitere Lieferanten über die Informationspools weitergeben. Hierbei gilt,
dass die prototypische Implementierung des FMI-Systems bisher über keine Vorwärtsplanung
124. Vgl. Klasse Customer_Requirements in Abbildung 58.
Abbildung 76: Abruf der Bedarfe beim Lieferanten
Auswahl desKunden
Auswahl desErzeugnisses
Anstoßen desAbrufvorgangs
Kapitel 5: Konzeption 179
zur Entscheidungsunterstützung verfügt. Daher kann die ggf. notwendige Anpassung des Ferti-
gungsplanes zur Abstimmung mit den Lieferanten nur manuell erfolgen.
5.3.5.2 Webbasierte Informationskomponente
Ziel der webbasierten Informationskomponente ist es, den vor- bzw. nachgelagerten Dispositi-
onseinheiten Informationen über das Fertigungsgeschehen in der betrachteten Dispositionsein-
heit via World Wide Web (WWW) bereitzustellen. Dazu soll sie für jede benachbarte
Dispositionseinheit bei Bedarf ausgewählte Informationen aufbereiten und darstellen kön-
nen.125 Hierbei sollen durch die webbasierte Informationskomponente insbesondere instruk-
tive Informationsflüsse realisiert werden können, die zum einen die bestehenden
Lieferbeziehungen verfestigen und zum anderen die dispositiven Entscheidungen unterstützen
können. Grundsätzlich soll die webbasierte Informationskomponente zwischen zwei beliebi-
gen Dispositionseinheiten, jedoch insbesondere für den in Abbildung 42 skizzierten Fall B.2,
eingesetzt werden können.
Abbildung 78 zeigt den groben Aufbau der webbasierten Informationskomponente. Dabei soll
der Zugriff auf die bereitzustellenden Informationen über einen WWW-Browser erfolgen kön-
nen. Dazu ist ein „Webserver“ erforderlich, der die Anfragen empfängt, die entsprechenden
Anwendungen ausführt und die resultierenden Informationen an den WWW-Browser übermit-
125. Vgl. Anforderung 3.3.
Abbildung 77: Disposition der Kundenbedarfe beim Lieferanten
Offene Kundenbedarfe
Gegenvorschläge des Lieferanten
180 Kapitel 5: Konzeption
telt.126 Weiterhin ist gegebenenfalls ein „Mailserver“ notwendig, um die aufbereiteten Infor-
mationen als elektronische Mail versenden zu können.
Die eigentliche Funktionalität der webbasierten Informationskomponente besteht darin, auf
der Basis der a priori zu definierenden Informationsprofile einerseits ein Ablaufmodell festzu-
legen, das die möglichen Benutzerinteraktionen beschreibt, und andererseits die Informations-
aufbereitung aus der FMIS-Datenbank durchzuführen. Im Folgenden wird in Kapitel 5.3.5.2.1
gezeigt, wie die individuellen Informationsprofile erstellt werden können. In Kapitel 5.3.5.2.2
wird die Umsetzung der webbasierten Informationskomponente aus Kundensicht beispielhaft
dargestellt.
5.3.5.2.1 Erstellung der Informationsprofile
Ausgangspunkt der Erstellung der Informationsprofile sind die Instanzen der in Abbildung 50
vorgestellten Klasse View_Template und die zugehörigen View_Element-Instanzen. Eine
View_Template repräsentiert dabei eine Ansammlung von Informationen zu einem oder meh-
reren Aspekten des Fertigungsgeschehens. Dazu umfasst eine View_Template-Instanz ein oder
mehrere View_Element-Instanzen, die jeweils Informationen zu einer oder mehreren Faktorar-
ten und/oder Ressourcen darstellen. Ein View_Element kann dabei als eine Kennzahl, die sich
auf eine Zeiteinheit bezieht, betrachtet werden.127 Für jede View_Element-Instanz müssen die
126. Die prototypische Implementierung der webbasierten Informationskomponente ist auf der Basis desInternet Information Server (IIS) von Microsoft durchgeführt worden. 127. Vgl. Abbildung 50.
FMIS-Datenbank
WWW-Browser
Web-server
Mail-server
Funktionalität:
Abbildung 78: Grober Aufbau der webbasierten Informationskomponente
• Ablaufmodell• Informations-
akquisition
Informations-profile
Kapitel 5: Konzeption 181
erforderliche Funktionalität zur Informationsaufbereitung und die ggf. notwendigen Berech-
nungen implementiert werden.128
Abbildung 79 stellt den Information Profile Editor dar, der zum einen das Anlegen bzw. Ent-
fernen einer View (View_Template) bzw. eines Attributes (View_Element) ermöglicht und
zum anderen die Zuordnung und die individuelle Anpassung einer View (Partner_View) an die
spezifischen Anforderungen einer vor- bzw. nachgelagerten Dispositionseinheit erlaubt. Dabei
stellt eine View_Template eine Art Vorlage dar, die durch das Hinzufügen neuer Attribute bzw.
durch das Entfernen von Attributen verändert werden kann.
5.3.5.2.2 Szenario „Customer“
In diesem Abschnitt soll aus der Sicht eines Kunden aufgezeigt werden, wie die Umsetzung
der webbasierten Informationskomponente erfolgt ist. Dazu wird die Delivery View verwen-
det, die den Kunden Informationen über die geplanten Lieferungen bereitstellt. Die Delivery
View umfasst die beiden Attribute promise bzw. delay, die die geplanten kundenspezifischen
Lieferungen bzw. Lieferverzögerungen aufzeigen.129 Zur Ermittlung der geplanten Lieferun-
gen für einen Kunden lassen sich Verteilungsregeln130 heranziehen, die den verfügbaren
128. Vgl. Kapitel 5.1.5.129. Vgl. Abbildung 79.130. Eine Anwendung von Verteilungsregeln ist nur dann erforderlich, wenn der verfügbare Bestand dengemeldeten Bedarf nicht abdecken kann. Als Verteilungsregeln lassen sich beispielsweise Prioritäten,festgelegte Anteile (Prozentsätze) oder Zufallsregeln einsetzen. Im Rahmen der prototypischen Umset-zung wurde zur Vereinfachung davon ausgegangen, dass eine Output-Faktorart ausschließlich an einenKunden lieferbar ist.
Abbildung 79: Editor zur Erstellung und Zuordnung der Informationsprofile
Erstelung vonkunden- bzw.lieferanten-spezifischenInformations-profilen
Vorlagen zur Erstellung von „Sichten“
182 Kapitel 5: Konzeption
Bestand, ggf. unter Berücksichtigung des gemeldeten Bedarfes bzw. der mengen- und zeitmä-
ßigen Aspekte der Interdependenzen131, auf die Kunden aufteilen.
Dagegen lassen sich mögliche Lieferverzögerungen durch die Gegenüberstellung der geplan-
ten Lieferungen zu den gemeldeten Bedarfen ermitteln.
Der Zugriff und die damit verbundene Informationsaufbereitung können jederzeit über einen
WWW-Browser erfolgen. Dabei besteht nach der erfolgreichen Authentifizierung des Benut-
zers132 die Möglichkeit zur Auswahl einer der bereits im Informationsprofil zugeordneten
Views. Anschließend können, wie in Abbildung 80 für die Delivery View angezeigt, die weite-
ren Parameter zur Informationsaufbereitung spezifiziert werden. Dabei ist insbesondere eines
der dem View zugeordneten Attribute (View_Element) auszuwählen. Abbildung 81 zeigt die
131. Vgl. Kapitel 5.2.1.132. Vgl. Klasse Partner in Abbildung 50.
Abbildung 80: Frontend zur Spezifikation der Parameter zur Informationsaufbereitung
Spezifikation des Zeitintervalls Spezifikation der Parameter zurInformationsaufbereitung
Kapitel 5: Konzeption 183
Darstellung der Ergebnisse einer Benutzeranfrage nach den geplanten Lieferungen über alle
Output-Faktorarten für einen Zeitraum auf Schichtbasis.
Eine Erweiterung der webbasierten Informationskomponente ist dahingehend denkbar, dass
die Ergebnisse der Benutzeranfrage in einer Datei verwaltet werden, die zur Weiterverarbei-
tung heruntergeladen werden kann. Dazu müssten allerdings entsprechende Formate a priori
definiert werden.
Abbildung 81: Darstellung der Ergebnisse
Kapitel 6: Zusammenfassung und Ausblick 185
6 Zusammenfassung und Ausblick
Die Tendenz zur Reduktion des vertikalen Integrationsgrades verbunden mit der Notwendig-
keit einer Erhöhung des horizontalen Integrationsgrades in der Lieferkette führt zu neuen
Anforderungen an das operative Fertigungsmanagement. Dazu gehören insbesondere einer-
seits die schnelle Bereitstellung von belastungsabhängigen Bedarfs- bzw. Angebotsdaten für
die vor- bzw. nachgelagerten Stufen und andererseits die schnelle Reaktionsfähigkeit auf kurz-
fristige Änderungen. Die meisten heutigen ERP/PPS-Systeme werden, aufgrund der in MRP-II
vorgesehenen fixen Übergangszeiten und des verfolgten Stufenplanungskonzeptes, diesen
Anforderungen nicht gerecht.
Im Rahmen dieser Arbeit wurde die Zielsetzung verfolgt, einen Ansatz zur Gestaltung des ope-
rativen Fertigungsmanagements innerhalb der Lieferkette zu entwickeln, der es ermöglicht, die
ERP/PPS-Systeme um Komponenten zur Behebung der erwähnten Mängel zu ergänzen. Der
Ansatz sollte prototypisch in Form eines Fertigungsmanagement-Informationssystems umge-
setzt und in dem Pilotwerk eines Automobilzulieferers evaluiert werden. Um die angestrebte
Lösung zu erreichen, wurden in Kapitel 2 die drei Untersuchungsaspekte Strukturierung der
Fertigung entlang der Lieferkette, Gestaltung der Informationsflussbeziehungen und Entwurf
eines Fertigungsmanagement-Informationssystems identifiziert und Anforderungen an die
Teillösungen formuliert.
Die hier entwickelte Strukturierung der Fertigung beruht darauf, dass die Lieferkette durch ein
Prozessmodell mittels MFERT abgebildet werden kann. Das Prozessmodell wird in disjunkte
Teilgraphen aufgeteilt, sog. Dispositionseinheiten, die autonom geplant und gelenkt werden
können. Kernpunkt bei der Bildung der Dispositionseinheiten ist die Identifizierung von Pro-
zessen, die im Materialfluss einen (Planungs-) Engpass darstellen und somit geplant werden
müssen. Diese Prozesse können um benachbarte Prozesse erweitert und einer Dispositionsein-
heit zugeordnet werden. Durch die Bestimmung der auszutauschenden Informationen zur
Ablaufplanung und deren zeitlicher Reihenfolge wird der Informationsfluss innerhalb der Dis-
positionseinheit ermittelt. Zur Dokumentation der fertigungsrelevanten Informationen wurden
Ausprägungen der generischen MFERT-Konstrukte verwendet. Dabei wurden neben der
Modellierung der statischen Aspekte insbesondere das Zeitmodell sowie Ereignistypen zur
Zustandsbeschreibung festgelegt. Aus dem daraus entstandenen Modell wurden Operationen
zur Bildung von Sichten auf das Fertigungsgeschehen definiert.
186 Kapitel 6: Zusammenfassung und Ausblick
Die Gestaltung der Beziehungen zwischen den Dispositionseinheiten umfasst einerseits die
Charakterisierung der Interdependenzen und andererseits das Herleiten von Konstrukten zum
Management dieser Interdependenzen. Dazu wurden zur Beschreibung einer Interdependenz,
neben der Art des vereinbarten Leistungsaustausches, die zeitlichen, quantitativen und qualita-
tiven Abhängigkeiten herangezogen. Für das Management der Beziehungen wurden die drei
Informationsfluss-Grundtypen administrative, instruktive und dispositive Informationsflüsse
unterschieden. Dabei lassen sich die Informationsflüsse durch die Ausprägungen ihrer Merk-
male für unterschiedliche Kooperationsformen anpassen.
In Kapitel 5.3 wurde das Fertigungsmanagement-Informationssystem entworfen und prototy-
pisch umgesetzt. Das System besteht aus den vier Komponenten Stammdaten-, Bewegungsda-
ten-, Schnittstellen- und Kooperationsmanager, die über eine gemeinsame Datenbasis
integriert sind. Im Stammdatenmanager werden das Prozessmodell spezifiziert und die Eigen-
schaften der Dispositionseinheiten verwaltet. Um den manuellen Aufwand bei der Datenpflege
so gering wie möglich zu halten, wurde die Möglichkeit vorgesehen, ausgewählte Daten aus
dem ERP/PPS-System, falls dort vorhanden, über den Schnittstellenmanager zu übernehmen.
Der Bewegungsdatenmanager stellt dem Disponenten Informationen über die bisherige und
zukünftige Entwicklung des Fertigungsgeschehens bereit. Dabei kann es sich sowohl um
manuell erstellte Daten als auch um Ergebnisse einer automatischen Belegungsplanung han-
deln. Weiterhin können über den Schnittstellenmanager einerseits Rückmeldungen des Ferti-
gungsprozesses aus dem BDE-System übernommen werden und andererseits Ergebnisse der
Feinplanung an das ERP/PPS-System übergeben werden. Der Kooperationsmanager dient dem
Informationsaustausch mit den benachbarten Dispositionseinheiten. Er besteht aus einer Inter-
aktions- und einer webbasierten Informationskomponente. Die Interaktionskomponente basiert
auf einem Kommunikationsmodell und realisiert den Informationsfluss zwischen zwei Dispo-
sitionseinheiten, die jeweils über ein FMI-System verfügen. Die webbasierte Informations-
komponente ermöglicht die individuelle Auswahl und die Bereitstellung von Informationen für
benachbarte Dispositionseinheiten.
Durch den Einsatz des hier vorgestellten Fertigungsmanagement-Informationssystems in
einem Pilotwerk eines Automobilzulieferers wurden zum einen die Qualität des Planungspro-
zesses erheblich verbessert und zum anderen die (Zwischen-) Bestände im Werk reduziert.
Dabei wurden alle Dispositionseinheiten gegen die realen Bedarfe und stets auf der Basis von
aktuellen Daten geplant. Darüber hinaus wurden die Auswirkungen von Planungsänderungen
Kapitel 6: Zusammenfassung und Ausblick 187
auf die benachbarten Dispositionseinheiten aufgezeigt, um somit frühzeitige Steuerungsmaß-
nahmen einzuleiten.
Um ein lieferkettenübergreifendes Fertigungsmanagement zu ermöglichen, lässt sich das Ferti-
gungsmanagement-Informationssystem um eine „zentrale“ Komponente erweitern, die alle
relevanten Informationen aus den dezentralen Einheiten des Systems sammelt, aufbereitet und
daraus ggf. Rückmeldungen erstellt. Die Aufgabe einer solchen Komponente könnte von der
reinen Überwachung bis zur zentralen Planung und Lenkung der gesamten Lieferkette reichen.
Hierzu stellt die Verwendung der XML-Technologie für den Datenaustausch sowohl mit dem
ERP/PPS-System als auch zwischen den dezentralen Einheiten einen wichtigen Schritt dar.
Insbesondere soll dadurch die Integration mit anderen betrieblichen Informationssystemen ver-
bessert werden.
Literaturverzeichnis 189
7 Literaturverzeichnis
[Alt97] Alt, R.: Interorganisationssysteme in der Logistik, DUV, Wiesbaden, 1997
[BaWe99] Bannert, G.; Weizel, M.: Objektorientierter Softwareentwurf mit UML; Addi-son Wesley, München, 1999
[Bell97] Bellini, J.: i2 Technologies Intelligent Supply Chain Management, InformationIntegration and Case Studies. In: Proceedings of the Fifth National Agility Con-ference, S. 47-61, Atlanta 1996
[BiBB99] Bick, M.; Bub, M.; Buchmann, F.: Konzeption einer dynamischen Fertigungs-planung- und -steuerung bei einem Automobilzulieferer, Diplomarbeit, Univer-sität-GH Paderborn, 1999
[BlGö97] Bloech, J.; Gösta, B.: Vahlens großes Logistiklexikon, Verlag Franz Vahlen,München, 1997
[BlIh97] Bloech, J.; Ihde, G.(Hrsg.): Vahlens großes Logistiklexikon, Vahlens, München,1997
[BoDa96] Bowersox, D.J.; Closs, D.J.: Logistical Management - The Integrated SupplyChain Process, McGRAW-Hill, New York, 1996
[Bren90] Brenig, H.: Informationsflußbezogene Schnittstellen bei industriellen Produkti-onsprozessen, In: Information Management 1/90, 1990
[Bruc95] Brucker, P.: Scheduling Algorithms, Springer, Berlin, 1995
[Burk97] Burkhardt, R.: UML - Unified Modeling Language : Objektorientierte Model-lierung für die Praxis, Bonn, Addisson Wesley, 1997
[Buse97] Buse, H.-P.: Wandelbarkeit von Produktionsnetzen, In: Dangelmaier, W.(Hrsg.): Vision Logistik - Logistik wandelbarer Produktionsnetze, HNI-Verlag-schriftenreihe, Bd. 31, 1997
[BPLP96] Buse, H.-P.; Philippson, C.; Luczak, H.; Pfohl, H.-C.: Organisation der Logi-stik, In: Dangelmaier (Hrsg.): Vision Logistik. Logistik wandelbarer Produkti-onsnetze zur Auflösung ökonomisch-ökologischer Zielkonflikte. Projektbericht.Juli 1996. FZKA-PFT 181, Karlsruhe: Projektträger Fertigungstechnik undQualitätsicherung, 1996
190 Literaturverzeichnis
[BuKo00] Buxmann, P.; König, W.: Zwischenbetriebliche Kooperationen auf Basis vonSAP-Anwendungen - Perspektiven für die Logistik und das Servicemanagement,Berlin, Springer, 2000
[CaAf99] Camarinha-Matos, L.; Afsarmanesh, H.: Infrastructures for virtual Enterprises- Networking Industrial Enterprises, Kluwer Academic Publishers, Lon-don,1999
[Chom56] Chomsky, N.: Three models for the description of language. IRE Trans. onInformation Theory 2, 113-124
[CoLP97] Cooper, M.; Lambert, D.; Pagh, J.: Supply Chain Management: More Than aNew Name for Logistics, In: The international Journal of Logistics Manage-ment, Vol. 8, Nr. 1, S. 1-14, 1997
[Cram98] Cramer, F.: Instrument zur Unterstützung der unternehmensübergreifendenSynchronisation von Logistik-Leitständen, LogiChron, S. 225-228, LogistikJahrbuch 1998
[DaWi97] Dangelmaier, W.; Wiedenmann, H.: Modellbasiertes Planen und Steuern derFertigung, Beut-Verlag, 1997
[Dang98a] Dangelmaier, W.: KOMNET - Kommunikationsplattform für kmu-Netzwerke,HNI-Verlagsschriftenreihe, Band 41, Paderborn, 1998
[Dang98b] Dangelmaier, W.: Fertigungsplanung: Planung von Aufbau und Ablauf derFertigung, Springer, Berlin, 1998
[Dang97] Dangelmaier, W.: Vision Logistik - Logistik wandelbarer Produktionsnetze,HNI-Verlagschriftenreihe, Band 31, Paderborn, 1997
[Dang00] Dangelmaier, W.: Supply Chain Management nach dem Kunden-Lieferanten-Prinzip, Zeitschrift für Unternehmensentwicklung und Industrial Engineering,REFA Bundesverband(Hrsg.), 4/2000, Darmstadt, 2000
[DaWa97] Dangelmaier, W.; Warnecke, H.-J.: Fertigungslenkung: Planung und Steuerungdes Ablaufs der diskreten Fertigung; Springer, Berlin, 1997
Literaturverzeichnis 191
[DBHHL99] Dangelmaier, W.; Brockmann, K.; Hamady, M.; Holtkamp, R.; Langemann, T.:OOPUS-PSCM - Ein Werkzeug zum Produktions- und Supply-Chain-Manage-ment; In: Kopfer, H.; Bierwirth, Chr. (Hrsg.): Logistik Management - Intelli-gente I+K Technologien, Springer, Berlin 1999
[Dant96] Dantzer, U.: Kooperationen zwischen Industrie und Handel, In: BeschaffungAktuell 11/96, S.26-27, 1996
[DeKr00] Detro, L.; Kronnagel, F.: Stand der Technik: Ansätze der überbetrieblichenAbstimmung entlang der Lieferkette, Produktionstechnisches Seminar SS2000,Universität Paderborn, 2000
[Delo00] Deloitte Consulting: Energizing the Supply Chain - Trends and Issues in SupplyChain Managment, unter: http://www.dc.com, Stand 12.06.2000
[Diek92] Diekmann, A.: Flexibilitätsorientierte Strategien in der Textilwirtschaft: einemikroökonomisch und empirisch fundierte Analyse des Quick Response-Kon-zeptes, Verlag für Wissenschaft und Forschung, Stuttgart, 1992
[Eisen89] Eisenführ, F.: Grundlagen der Produktionswirtschaft - Industriebetriebslehre I,Verlag Augustinius, Aachen, 1989
[FaFG97] Fandel, G.; Francois, P.; Gubitz, K.-M.: PPS- und integrierte betriebliche Soft-waresysteme - Grundlagen, Methoden, Marktanalyse, 2.Auflage, Springer, Ner-lin, 1997.
[Fies98] Fiesser, G.: Efficient Consumer Response „ECR“ - Ein fast noch neues Schlag-wort im Vertriebscontrolling, In: controller magazin 1/98, S.37- 41
[FrWe94] Frese, E.; Werder, A.v.: Organisation als strategischer Wettbwerbsfaktor, in:Organisationsstrategien zur Sicherung der Wettbewerbsfähigkeit, ZfbF-Sonder-heft 33/94, S. 1 - 27, Düsseldorf, 1994
[Frigo97] Frigo-Mosca, F.: Referenzmodelle für Supply Chain Management nach denPrinzipien der zwischenbetrieblichen Kooperation, vdf Hochschulverlag AG,Zürich, 1997
[Fulk00] Fulkerson, W.: Information-Based Manufacturing in the Informational Age,The International Journal of Flexible Manufacturing Systems, 12(2000), S. 131-143, Kluwer Academic Publishers, Boston, 2000
192 Literaturverzeichnis
[Gabl98] Gabler Wirtschaftslexikon, CD-ROM, MDI, Schalksmühle, 1998
[GHJV96] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.: Entwurfsmuster - Elementewiederverwendbarer objektorientierter Software, ADDISON-WESLEY, Bonn,1996
[GlGR92] Glaser, H.; Geiger, W.; Rohde, V.: Produktionsplanung und -steuerung -Grundlagen -Konzepte - Anwendungen, 2. Auflage, Gabler, Wiesbaden, 1992
[Groß74] Große-Oetringhaus, W.: Fertigungstypologien unter dem Gesichtspunkt derFertigungsablaufplanung, Duncker & Humboldt Verlag, Berlin, 1974
[Gott82] Gottwald, M.: Produktionssteuerung mit Fortschrittzahlen; neue PPS-Lösun-gen; Gesellschaft für Management und Technologie mbH; München 1982
[Gud00a] Gudehus, T. : Logistik 1: Grundlagen, Verfahren und Strategien, Springer, Ber-lin, 2000
[Gud00b] Gudehus, T.: Logistik 2: Netzwerke, Systeme und Lieferketten, Springer, Berlin,2000
[Gunt85] Guntram, U.: Die Allgemeine Systemtheorie. Ein Überlick, ZfB, 55, S. 296-323,1985
[Hahn00] Hahn, D.: Problemfelder des Supply Chain Management, In: ZWF 4/2000,S.174 - 177, 2000
[Hein86] Heiner, V.: Ein modernes Produktionsmanagementsystem, In: io Management-Zeitschrift, Jg. 55, 1986, Nr. 4, S. 164-166
[Hell99] Hellingrath, B.: SCOR und CPFR - Standards für die Supply Chain, In: LogistikHeute 7/8-99, S. 77- 85, 1999
[Henk97] Henkel, S.: Ein System von Software-Entwurfsmustern für die Propagation vonEreignissen in Werzeugen zur kooperativen Fabrikmodellierung, Dissertation,Paderborn, 1997
[HaPW97] Hau, L.L.; Padmanabhan, V.; Whang, S.: The Bullwhip Effects in SupplyChains, In: Sloan Management Review, S. 93-102, Spring 1997
[HeRo98] Heinrich, L.; Roithmeyer, F.: Wirtschaftsinformatik-Lexikon, 6. Aufl., Olden-bourg, München, 1998
Literaturverzeichnis 193
[Heis97] Heiss, H.-U.: Verteilte Systeme; Skript zur Vorlesung, Universität Paderborn,1997
[Hoit96] Hoitsch, H.: Fortschrittzahlenkonzepte; In: Handwörterbuch der Produktions-wirtschaft, Band VII; Kern, Schröder, Weber (Hrsg.), 2.Auflage, Schäfer-Poe-schel, Stuttgart, 1996
[Holtk99] Holtkamp, R.: Ein objektorientiertes Rahmenwerk zur Erstellung individueller,verteilter Fertigungslenkungssysteme, HNI-Verlagsschriftenreihe, Bd. 17,Paderborn, 1999
[Horn95] Hornbostel, D.: Methode zur Modellierung der Informationsverarbeitung inIndustrieunternehmen, HNI-Verlagschriftenreihe, Dissertation, Paderborn,1995
[Itte99] Itter, R.: Internet-basierte Informationssysteme in betrieblichen Prozessen -Einsatzbereiche und Vorgehensmodelle, Josef Eul Verlag, Köln, 1999.
[JaZu95] Jasper, H.; Zukunft, O.: Time Issues in Advanced Workflow Management Appli-cations of Active Database, Technical Report, Fachbereich Informatik, Univer-sität Oldenburg, Juni 1995
[Kern95] Kernler, H.: PPS der 3. Generation: Grundlagen, Methoden, Anregungen,3.Auflage, Hütig, Heidelberg, 1995
[KeSW96] Kern, W.; Schröder, H.-H.; Weber, J.(Hrsg.): Handwörterbuch der Produkti-onswirtschaft, 2.Auflage, Schäfer-Poeschel, Stuttgart, 1996
[Klei96] Klein, S.: Interorganisationssysteme und Unternehmensnetzwerke, Gabler Ver-lag, Wiesbaden, 1996
[Klin98] Klink, J.: Produktionsnetzwerke im Überblick - eine Typologie, In 3.StuttgarterPPS-Seminar, Stuttgart, Juni 1998
[KnMZ00] Knolmeyer, G.; Mertens, P.; Zeier, A.: Supply Chain Management auf der Basisvon SAP-Systemen, Springer, Berlin, 2000.
[Kort99] Kortmann, J.: Standardsoftware für Supply Chain Management; Dangelmaier,W.; Felser, W. (Hrsg), ALB/HNI-Verlagsschriftenreihe, Paderborn, 1999
[KuHe98] Kuhn, A.; Hellingrath, B.: Anforderungen an das Supply Chain Managementder Zukunft, In: Information Management & Consulting 13 (1998)
194 Literaturverzeichnis
[Kuhn99] Kuhn, A.: Referenzmodelle für die Produktionsprozesse zur Untersuchung undGestaltung von PPS-Aufgaben, Dissertation, Universität-GH Paderborn, 1999
[Kurb97] Kurbel, K.: Internet-Nutzung im Business-to-Business-Bereich: Stand der Ent-wicklung, Typologie und Anwendungsbeispiele, S. 23-34, In: Krallmann, H.(Hrsg.): Wirtschaftsinformatik 97, Physica-Verlag,, Heidelberg, 1997
[KSDS99] Kläger, W.; Schulik, S.; Dangelmaier, W.; Schäfermeier, U.: Lieferanten mitPlanungsverantwortung - Ein automatisierter Dispositionsdatenaustausch ineinem mittelständischen Produktionsnetzwerk. In: Pfohl, H.-C.(Hrsg.): Logisti-sche Schnittstellen in Produktionsnetzwerken - Konzepte zur Verbesserung derunternehmensübergreifenden Logistik, Praxiswissen, Dortmund, 2000
[Lack94] Lackes, R.: Just-in-Time-Produktion - Systemarchitektur, Wissensbasierte Pla-nungsunterstützung, Informationssysteme, Gabler, Dortmund, 1994
[Lerm92] Lermen, P.: Hierarchische Produktionsplanung und KANBAN, Gabler, Wiesba-den, 1992
[Linth00] Linthicum, D.S.: Enterprise Application Integration, Addison-Wesley, Rea-ding, 2000
[LuES98] Luczak, H.; Eversheim, W. (Hrsg.); Schotten, M.: Produktionsplanung und -steurung - Grundlagen, Gestaltung und Konzepte, Springer, Berlin, 1998
[Männ96] Männel, B.: Netzwerke in der Zulieferindustrie, Konzepte - Gestaltungsmerk-male - betriebswirtschaftliche Wirkungen, Dissertation, TU München, 1996
[Mann97] Mannmeusel, T.: Dezentrale Produktionslenkung unter Nutzung Verhandlungs-basierter Koordinationsformen, DeutscherUniversitätsVerlag, Wiesbaden,1997
[Matt99] Mattern, T.: Lösungsansätze für eine unternehmensweite Integration auf Basisvon Applikationsservern, S. 28-34, In: OBJEKTspektrum 6/99, 1999
[MeSJ93] Mertins, K.; Süssenguth, W.; Jochem, R.: Modellierungsmethoden für rechner-integrierte Produktionsprozesse, Carl Hanser Verlag, München, 1993
[MeSc83] Meyer, B.; Schefenacker, R.: Erfahrung mit einem EDV-gestütztem Fort-schrittszahlensystem für Automobilzulieferer, In: Zeitschrift für wirtschaftlicheFertigung ZwF 78, S. 170 - 172, 1983
Literaturverzeichnis 195
[MoTH98] Monczka, R.; Trent, R.; Handfield, R.: Purchasing and Supply Chain Manage-ment, South-Western College Publishing, Cincinatti, 1998
[Muec99] Mueck, B.: Systematische Konzeption und Umsetzung eines Werkzeuges zumdynamischen Produktionsscheduling bei einem Automobilzulieferer, Diplomar-beit, Universität-GH Paderborn, 1999
[Nest74] Nestler, H.: Materialflussuntersuchungen in Fertigungsbetrieben, Reihe Mate-rialfluss im Betrieb, Band 25, 1.Auflage, VDI-Verlag, Düsseldorf, 1974
[OAG99] N.N.: OAGIS: Open Application Group, Integration Specification; Unter: http://www.openapplications.org, Stand Mai, 1999
[OMG99] OMG (Hrsg.): OMG Unified Modeling Language, Unter: http://www.omg.org/technology/uml/, Version 1.3, June 1999
[OrHaE98] Orfali, R.; Harkey, D.; Edwards, J.: INSTANT CORBA, Addison Wesley, Bonn,1998
[OtWi93] Ottmann, T.; Widmayer, P.: Algorithmen und Datenstrukturen, Brockhaus,Mannheim, 1993
[Pete98] Petersen, U.: Euroforum Deutschland GmbH(Hrsg.): Electronic Supply ChainManagement; Seminar: Supply Chain Management, 24./25.11.98, Hamburg
[Pfohl96] Pfohl, H.-Ch.: Logistiksysteme, Betriebswirtschaftliche Grundlagen, 5. Auf-lage, Springer, Berlin, 1996
[PfoKo99] Pfohl, Ch.; Koldau, A.: Auswirkungen des Electronic Commerce auf die Logi-stik, In: Industrie Management 6/99, GITO-Verlag, Berlin, 1999
[Pfohl97] Pfohl, C.: Informationsfluß in der Logistikkette, In: Pfohl (Hrsg.), Infomations-fluß in der Logistikkette, EDI - Prozeßgestaltung - Vernetzung, Erich SchmidtVerlag, Darmstadt, 1997
[Powe90] Powell, W.W.: Neither Market Nor Hierarchy - Network Forms of Organiza-tion, In: Staw, B.; Cummings, L. (Hrsg.): Research in Organisational Beha-viour, Vol. 12, S. 294-336, Greenwich: JAI, 1990
[PPVR99] Philippson, C.; Pillep, R.; von Wrede, P.; Röder, A.: Marktspiegel - SupplyChain Management Software, Luczak, H.; Eversheim, W.; Stich, V.(Hrsg), For-schungsinstitut für Rationalisierung an der RWTH Aachen, 1999
196 Literaturverzeichnis
[Pude97] Puder, A.: Verteilte Objekte: DCOM versus CORBA, In: IX - Magazin für pro-fessionelle Informationstechnik, Nr. 8/97, Verlag Heinz Heise, Hannover, 1997
[REFA91] REFA(Hrsg.): Methodenlehre der Betriebsorganisation - Planung und Steue-rung - Teil I, Darmstadt, 1991
[ReDi91] Reichwald, R.; Dietel B.: Produktionswirtschaft, S. 399-612, In: Heinen, E.(Hrsg.): Industriebetriebslehre - Entscheidungen im Industriebetrieb, Gabler,Wiesbaden, 1991
[Reic95] Reichmann, T.: Controlling mit Kennzahlen und Managementberichten, 4. Auf-lage, Vahlen, München 1995
[Reut00] Reuter, A.: EAI und Web-to-Host: Vom Ausflug zurück zur Mitte, in: IT Mana-gement 11/2000, S.62-65, IT Verlag für Informationstechnik, Hoehenkirchen,2000
[RiWa99] Ring, K.; Ward-Dutton, N.: Enterprise Application Integration - Making theright connections, OVUM Marktstudie, London, 1999
[RoFu98] Rockel, I.; Funke, H.: Überblick über CORBAmanufacturing, Produktionstech-nisches Seminar, Universität Paderborn, 1998
[Rose94] Rosenberg, O.: Skript zur Vorlesung Produktionsmanagement, Wintersemester1994/1995, Universität Paderborn, 1994
[RuMB01] Ruh, W.; Maginnis, F.; Brown, W.: Enterprise Application Integration, Wiley,New York, 2001
[Rupp94] Rupprecht-Däullary, M.; Zwischenbetriebliche Kooperationen - Möglichkeitenund Grenzen durch neue Informations- und Kommunikationstechnologien,DeutscherUniversitätsVerlag, Wiesbaden, 1994
[SCC98] Supply-Chain-Council: SCOR Primer, Overview of Model Structure, Revision3.0, European Conference, Brussel, October, 1998
[Schae78] Schäfer, E.: Der Industriebetrieb - Betriebswirtschaftslehre der Industrie auftypologischer Grundlage, 2.Auflage, Gabler Verlag, 1978
[Schee97] Scheer, A.-W.: Wirtschaftsinformatik - Referenzmodelle für industrielleGeschäftsprozesse, siebte Auflage, Springer, Berlin, 1997
Literaturverzeichnis 197
[Schee99] Scheer, A.-W.: LOGISTIK HEUTE 3-99, S. 20, 1999
[Schin96] Schinzer, H.: CALS - ein Konzept für den überbetrieblichen Datenaustausch.In: Wirtschaftswissenschaftliches Studium 25, S. 205 -208, 1996
[Schne96] Schneider, U. : Ein formales Modell und eine Klassifikation für die Fertigungs-steuerung, Dissertation, Universität-GH Paderborn, 1996
[Schmi99] Schmid, C.: Infomationsflüsse in Zuliefernetzwerken, Gabler Edition Wissen-schaft, Wiesbaden, 1999
[Schmi00] Schmidtmann, A.: Eine Spezifikationssprache für die Fertigungslenkung, Dis-sertation, Universität-GH Paderborn, 2000
[Schra96] Schräder, A.: Management virtueller Unternehmungen - Organisatorische Kon-zeption und informationstechnische Unterstützung flexibler Allianzen, Campus,Frankfurt, 1996
[Scho80] Schomburg, E.: Entwicklung eines betriebstypologischen Instrumentariums zursystematischen Ermittlung der Anforderungen an EDV-gestützten Produktions-planungs- und -steuerungssysteme im Maschinenbau, Dissertation, RWTHAachen, 1980
[Schö98] Schönsleben, P.: Integrales Logistikmanagement, Springer, Berlin, 1998
[Schult99] Schulte, C.: Lexikon der Logistik, Oldenburg, München, 1999
[Schulz00] Schulz, K.: Java - professionell programmieren, Springer, Berlin, 2000
[ScKe00] Schmidt, B.; Kerner, A.: Vom Zeitwettbewerb zum Quick Response Manufactu-ring, In: ZWF Jahrg. 95, 1-2/2000, S. 33-36, Carl Hanser Verlag, München,2000
[Selig99] Seligmann, V.: Inter- und Intra-Optimierungen durch Supply Chain Manage-ment, In: Industrie Management 5/99, GITO-Verlag, Berlin, 1999
[Serv98] Servatius, H.G.: Integration der Wertschöpfung von Unternehmen, Kunden undZulieferern: Ein Überblick, In Information Management & Consulting 13, 1998
[Shaw00] Shaw, M.J.: Information-Based Manufacturing with the Web, In: The Interna-tional Journal of Flexible Manufacturing Systems, S. 115-129, 12/2000, KluwerAcademic Publishers, Boston, 2000
198 Literaturverzeichnis
[Stre96] Streubel, F.: Theoretische Fundierung eines ganzheitlichen Informationsmana-gements, Arbeitsberichte des Lehrstuhls für Wirtschaftsinformatik, 96-21,Bochum, 1996
[Suri98] Suri, R.: Quick Response Manufacturing. A Companywide Approach to Redu-cing Lead Times. Productivity Press, Portland, 1998
[Swob97] Swoboda, B.: Kooperative Wertschöpfungspartnerschaften - Barrieren undErfolgsfaktoren des Efficient Consumer Response Managements, In: Informa-tion Management 2/97, S. 36-42, 1997
[Sydo92] Sydow, J.: Strategische Netzwerke - Evolution und Organisation , Gabler, Wies-baden, 1992
[Sydo95] Sydow, J.: Netzwerkorganisation. Interne und externe Restrukturierung vonUnternehmungen, In: Wirtschaftswissenschaftliches Studium, S. 629-634, 1995
[Thal97] Thaler, K.: Lieferabrufsysteme. In: Bloech, J.; Ihde, G. (Hrsg.): Vahlens großesLogistiklexikon, Beck, München, 1997
[Thal99] Thaler, K.: Supply Chain Management - Prozessoptimierung in der logistischenKette, Fortis Verlag, Köln, 1999
[TuNa78] Tushman, M.L.; Nadler, D. A.: Information Processing as an Integration Con-cept in Organizational Design, Academy of Management Review, S. 613-624,1978
[Wahr86] Wahrig, G.: Deutsches Wörterbuch, MOSAIK Verlag, München, 1986
[WaBr99] Warnecke, H.-J.; Braun, J. (Hrsg.): Vom Fraktal zum Produktionsnetzwerk -Unternehmenskooperationen erfolgreich gestalten, Springer, Berlin, 1999
[Warn93] Warnecke, H.-J.: Revolution der Unternehmenskultur: das fraktale Unterneh-men, Springer, Berlin, 1993
[W3C00] W3-Consortium: Extensible Markup Language (XML), unter: http://www.w3.org/XML, Stand 20.02.2000
[WeBa99] Weber, J.; Baumgarten, H: Handbuch Logistik - Management von Material-und Warenflußprozessen, Schäffer-Poeschel, Stuttgart, 1999.
[Wege93] Wegener, I.: Theoretische Informatik, Teubner, Stuttgart, 1993
Literaturverzeichnis 199
[Wens00] Wenski, R: Eine objektorientierte Systemkomponente zur Workflow-Modellie-rung und -Ausführung unter besonderer Berücksichtigung der Telekooperation,Dissertation, Universität Paderborn, 2000
[Wied01] Wiedenmann, H.: Modellierung von Produktionsprozessen als Beitrag zurGenerierung von Termin- und Kapazitätsplanungs-Systemen bei variantenrei-cher Serienfertigung, Dissertation, Universität Stuttgart, 2001
[Wien87] Wiendahl, H.-P.: Belastungsorientierte Fertigungssteuerung, Carl Hanser Ver-lag, München, 1987
[Wien87] Wieneke-Toutaoui, B.: Rechnerunterstütztes Planungssystem zur Auslegungvon Fertigungsanlagen, Carl Hanser Verlag, Müchen, 1987
[Wild88] Wildemann, H.: Produktionssteuerung nach KANBAN-Prinzipien, In: Adam, D.(Hrsg.): Fertigungssteuerung II, Wiesbaden 1988, S. 33 - 50
[Wild95] Wildemann, H.: Das Just-in-Time Konzept. München, TCW, 1995
[Wild96] Wildemann, H: Fertigungssegmentierung, S. 474 - 487, in [KeSW96]
[Witt93] Wittmann, W. (Hrsg.): Handwörterbuch der Betriebswirtschaft, Bd. 2, 5. Auf-lage, Schäffer-Poeschel, Stuttgart, 1993
[Zäpf96] Zäpfel, G.: PPS (Produktionsplanung und -steuerung), In: Handwörterbuch derProduktionswirtschaft, Kern, W.; Schröder, H.-H.; Weber, J.(Hrsg.), Schäffer-Poeschel Verlag, Wiesbaden, 1996
[Zäpf00] Zäpfel, G.: Taktisches Produktions-Management, 2. Auflage, Oldenbourg,München, 2000
Anhang 201
8 Anhang
8.1 UML-Notation
Für die Beschreibung des Datenmodells sowie zur Dokumentation von Teilen der Funktionali-
tät wurden Diagrammarten der UML (Unified Modeling Language)1 verwendet. Die Unified
Modeling Language ist eine grafische objektorientierte Modellierungssprache zur Spezifika-
tion, Konstruktion, Visualisierung und Dokumentation komplexer Softwaresysteme. UML
setzt sich aus acht Diagrammarten zusammen, von denen im Rahmen dieser Arbeit das Klas-
sen- und Sequenzdiagramm verwendet werden.
8.1.1 Klassendiagramm
Klasse
Eine Klasse ist eine Sammlung von Objekten mit einer einheitlichen Menge von Attributen
und Diensten.2 Die Aufgabe des UML-Symbols einer Klasse ist die Darstellung ihrer Intention
und der Regeln, die diese Klasse beschreiben.3 Eine Klasse wird in UML durch ein Rechteck,
das durch zwei horizontale Linien unterteilt ist, dargestellt. Der Klassenname steht in der
ersten Zeile innerhalb des Rechtecks. Attribute der Klasse werden in der Zeile darunter einge-
tragen. In der dritten Zeile werden die Methoden der Klasse eingetragen.
Assoziation
Die Assoziation repräsentiert die allgemeinste Beziehung zwischen zwei Klassen, die als
Kante zwischen den beiden dargestellt wird. Ein Ende einer Assoziation kann explizit mit
einem Rollennamen deklariert werden. Die Kardinalität wird durch die Zahlen an den Enden
der Kante angegeben, wobei ein Stern auf „beliebig viele“ hindeutet. Die bevorzugte Navigati-
1. UML basiert auf den seit Mitte der 80er Jahre von Grady Booch, Ivar Jacobson und Jim Rumbaughgeleisteten Arbeiten. Inzwischen liegt die Verantwortung für die weitere Entwicklung der UML-Spezifi-kation in den Händen der Objekt Management Group (vgl. [OMG99]).2. Vgl. [BaWe99], S. 233. Vgl. [OMG99]
Part
part_namepart_idsecurity_time
...
202 Anhang
onsrichtung zwischen den Klassen wird durch ein Dreieck mit der Spitze in Leserichtung ange-
zeigt.
Aggregation
Die Aggregation stellt eine „Zugehörigkeit“-Beziehung eines oder mehrerer Teile zu einem
Ganzen dar und wird als Linie mit weißer Raute abgebildet. Eine Art stärkere Aggregation
stellt die Komposition dar, die eine „Enthaltensein“-Beziehung der Teile in dem Ganzen
angibt. Sie wird durch eine ausgefüllte Raute angezeigt.
Assoziations-/Beziehungsklasse
In UML lässt sich eine Beziehung einer Klasse zuordnen. Die Assoziations-/Beziehungsklasse
fasst die Eigenschaften der Beziehung zusammen. Dabei wird die Klasse und die Bezeichnung
durch eine gestrichelte Linie verbunden.
Vererbung
Vererbung stellt ein wesentliches Element objektorientierter Modellierungsprachen dar. Dabei
bildet die Vererbung eine Beziehung einer allgemeinen Klasse (dem Vater) und einer speziali-
sierten Klasse (dem Kind), die völlig konsistent zu der allgemeinen Klasse ist, aber darüber
Part
part_namepart_idsecurity_time
...
Disposition_Unit
disp_namedisp_idsecurity_time
...
0..*1..1 part_of
Shift
shift_no:{0,...,shifts_in_week-1}day_name:{1,...,7}beginduration
...
Calender_Week
year...
week_no:{1,...,53}1..1
1..s
hifts
_in_
wee
k
Part
part_namepart_idsecurity_time
...
Consist_Ofquantity...
1..1
0..*
Anhang 203
hinaus um spezielle Informationen ergänzt ist, ab. In UML wird eine Vererbung als Kante mit
einem Dreieck, welches auf die Basisklasse (den Vater) deutet, visualisiert.
Schnittstellenklassen
Eine reine Schnittstelle in Java ist eine Klasse ohne Implementierung, die ausschließlich
Methodendeklarationen, aber keine Methodenrümpfe und Attribute besitzt. Im unten stehen-
den Beispiel zeigt die Realisierungsbeziehung, dass die Klasse Manager_Supplier die Imple-
mentierung der Schnittstelle InterfaceManager_Supplier beinhaltet.
8.1.2 Sequenzdiagramm
Das Sequenzdiagramm gehört neben dem Kollaborationsdiagramm zu der Gruppe der Interak-
tionsdiagramme in UML. Interaktionsdiagramme beschreiben das Zusammenwirken und den
Nachrichtenaustausch von verschiedenen Objekten und zeigen somit die dynamischen Aspekte
eines Systems auf. Dabei werden im Sequenzdiagramm die beteiligten Objekte als Rechtecke
über vertikal verlaufende, gestrichelte Linien dargestellt. Diese vertikale Linie stellt die
Lebenslinie des Objekts während der Interaktion dar. Nachrichten werden als Linien zwischen
den Lebenslinien der Objekte verlaufender Pfeile dargestellt.
Beispiel:
Hashtable
Hashtable_Parts
HashtableSupplier_Pool
InterfaceManager_SupplierManager_Supplier <<Interface>>
Nachricht (Anfrage)
Nachricht (Antwort)
Objekt 1 Objekt 2
synchron
unbestimmt
asynchron
205
8.2 Fertigungsprozessmodell des Automobilzulieferers
Wanderer
Hüller 90Stama 4
SW 3
Stama 6
1.6 MFD
Haaf
Stama 5
Stama 3
Stama 8/10
Stama 8/3
Hüller 10
SW 10
Hüller 5,6,7
Hoffmann 1
SW 4
Hoffmann 2
Hoffmann 3
Hoffmann 4
Hoffmann 5
Hoffmann 5
Hoffmann 3
Hoffmann 4
2.6 MFD
RohteileGehäuse
RohteileHalter
F. R.
Fi.
R.
R.
R.
R.
R.
R.
R.
B.
B.
B.
B.
B.&G.
B.&G.
B.&G.
B.&G.
Fi.
Fi.
Fi.
B.
G.
Fi.
206
Galvanik A(1 Linie)
Galvanik B(1 Linie)
I.
AL 1
B.: Bohren
V.: Veredeln
G.: Gewindeschneiden
R.: Räumen
I.: Inspizieren
M.: Montieren
F.: Fräsen
AL 2
AL 3
AL 4
AL 5
AL 6
AL 7
AL 8
AL 9
Handbrake AL
Inspektion
Galvanik C(1 Linie)
V.
I.&M.
M.
M.
M.
M.
M.
M.
M.
M.
M.
V.
V.
Fi.: Finishing
Spanendbearbeite Teile
AuszulieferendeTeile
(Spanende Bearbeitung)
Legende:
207
8.3 Ablauf dispositiver Abstimmungsprozesse
KundeLieferant
Sende(Anfor.)
OK
OK
Lieferant Kunde
KundeLieferantLieferantKunde
Anforderung
[Gegenvorschlag]
[Zusti
mmung/A
blehn
ung]
[Gegen
vorschlag
]
[Zust.]
Sende(Zust./Ableh.)
Sende(Best.)
Sende(Gegenv.)
Sende(Zust./Ableh.)
[Zust./Ableh.]
[Zust.]
Sende(Best.)
Sende(Anfr.)
Sende(Zust./Ableh.)
UnverbindlicheAnfrage