Ein Ansatz zur Gestaltung des operativen ...gcc.uni-paderborn.de/www/wi/wi2/wi2_lit.nsf/663247270b635985c1256bc... · ORB Object Request Broker PDM Product Data Management PPS Produktionsplanung

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

Geleitwort des Herausgebers

Vorwort

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

iv Inhaltsverzeichnis

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

Abbildungsverzeichnis viii

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

x Tabellenverzeichnis

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

Symbolverzeichnis XIV

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


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


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


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


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.


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].


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.


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].


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


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].


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


ü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.


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].


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].


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.


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


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.


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.


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.


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.


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.


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“.


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]).


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.


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


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


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


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].


• „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


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).


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


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


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


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].


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.


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


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.


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.


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


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).


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


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.


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.


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.


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].


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


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.


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).


• 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.


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.


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.


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


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


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.


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


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


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.


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.


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]).


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].


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


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


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


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).


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.


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


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.


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

78 Kapitel 4: Zu leistende Arbeit

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.


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


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.


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.


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


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


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.


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


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.


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


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.


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 ℵ∈


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,

=


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


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( , )


• 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.


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


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


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


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{ , }=


,

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


• 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


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,

=


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, ,( )–+ +=


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, , ,( )+=


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


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


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( )


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


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[ , ]→


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.


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


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


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.


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.


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


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.


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


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.


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


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


- 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]).


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→


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.


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.


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


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).


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


Internet/Intranet

ERP/PPS-System


Fall A.1

Fall A.2

Fall A.3


Internet/Intranet

ERP/PPS-SystemERP/PPS-System

Fall B.2


ERP/PPS-SystemERP/PPS-System

Fall B.1

Fall B.3


Internet/Intranet

ERP/PPS-System ERP/PPS-System

Abbildung 42: Szenarien zur informationstechnischen Integration der Dispositionseinheiten


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].


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).


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).


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


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


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.


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.


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


9 Linien 10 Linien5 Linien

P P PP


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.


Abbildung 46: Mögliche und tatsächliche Positionen zur Erfassung des Fertigungszustandes

möglicher Zählpunkt tatsächlicher Zählpunkt


Roh

teill

ager

Gal

v. T

eile

Span

. be

arb.

Tei

le

Ger

äum

.T

eile

Auslieferungs-lager


9 Linien 10 Linien5 Linien

PPPP

Abbildung 47: Dispositionseinheiten im Pilotwerk


PPPP

Dispositions-einheit 5






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.


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


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


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×→


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

...


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.


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


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).


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


„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


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


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.


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


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


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.


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


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


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


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


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


Projected_Inventory


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


Movements

...

1..1

1..1

S0

Saktuell

C o m p a r e S0 Saktuell,( ) 0≤


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


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-


Abbildung 63: Planungsoberfläche einer bedarfsorientierten Sicht

Bedarfs-bzw. Versand-meldungen (Output-Faktorarten)

Kapazitäts-informationen

ProjizierteBestand(Output-Faktorarten)

PlanwerteundUmrüstzeiten(Output-Faktorarten)


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


Initial_Stockquantity

Projected_Supply_Stock


Other_Successors_Parts

...

plan_qty[0, num_shifts-1]

Facility_Plan

...



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


Deliveries


1..1

Other_Plan


Part_Actuals


1..1

actual_qty[0, num_shifts-1]

1..1


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)


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


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


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⋅ ⋅( )


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.


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.


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


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


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.


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]).


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).


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“


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.


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


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.


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


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


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


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.


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


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“


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


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


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


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“


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


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.

188 Kapitel 6: Zusammenfassung und Ausblick

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


[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


[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


[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


[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)


[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


[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


[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


[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


[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


[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


...

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


...

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


...

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

204 Anhang

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

208

Documents

Ein Ansatz zur Gestaltung des operativen ...gcc.uni-paderborn.de/www/wi/wi2/wi2_lit.nsf/663247270b635985c1256bc... · ORB Object Request Broker PDM Product Data Management PPS Produktionsplanung