Warehouse Management: Organisation und Steuerung von Lager- und Kommissioniersystemen, 4. Auflage

Warehouse Management Michael ten Hompel • Thorsten Schmidt Warehouse Management Organisation und Steuerung von Lager...

Author: Michael Hompel | Thorsten Schmidt

736 downloads 2510 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Warehouse Management

Michael ten Hompel • Thorsten Schmidt

Warehouse Management Organisation und Steuerung von Lager- und Kommissioniersystemen 4., neu bearbeitete Auflage

13

Professor Dr. Michael ten Hompel Fraunhofer-Institut für Materialfluss und Logistik (IML) Joseph-von-Fraunhofer-Str. 2-4 44227 Dortmund Deutschland [email protected]

Professor Dr.-Ing. habil. Thorsten Schmidt Technische Universität Dresden Institut für Technische Logistik und Arbeitssysteme Helmholtzstraße 10 01069 Dresden Deutschland [email protected]

Ergänzendes Material zu diesem Buch finden Sie auf http://extra.springer.com. ISBN 978-3-642-03184-7 e-ISBN 978-3-642-03185-4 DOI 10.1007/978-3-642-03185-4 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer-Verlag Berlin Heidelberg 2003, 2004, 2007, 2010 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Dieses Buch entstand mit freundlicher Unterstützung der Firma LinogistiX GmbH. Einbandentwurf: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Vorwort

Vorwort zur 4. Auﬂage ¨ Nach Uberzeugung vieler Experten werden Service Orientierte Architekturen (SOA) zuk¨ unftig ein entscheidender Baustein zur Beherrschung der steten Komplexit¨ atszunahme in der Logistik sein. Die nun vorliegende, vierte Auf¨ lage nimmt diesen aktuellen, nach unserer Uberzeugung nachhaltigen Trend vertiefend auf und widmet sich in Kapitel 7 verst¨arkt diesen softwaretechnischen Aspekten. Schwerpunkt ist darin die Modellierung und Programmierung eines objektorientierten Warehouse Management System (WMS) in der Programmiersprache Java sowie die Einbettung in eine Service Orientierte Architektur. Die Vorteile der Service Orientierung werden durch die beispielhafte Erweiterung der Grundapplikation um ein Modul zur Anbindung eines Pick-By-Light Systems aufgezeigt. In der Praxis werden solche Erweiterungen zunehmend relevant, um neue Kapazit¨ atsreserven zu erschließen. Mit dieser Aktualisierung m¨ ochten wir den dynamischen Entwicklungen im Bereich der Logistik-IT auch mit diesem Standardwerk am Ball bleiben und haben uns daher nach kurzer Zeitspanne zur einer neuen Auflage entschieden. Um diese und andere Funktionen anschaulich zu vermitteln, wird den Lesern auch mit dieser Ausgabe wieder eine Software zur Verf¨ ugung gestellt. Durch die freundliche Unterst¨ utzung der LinogistiX GmbH aus Dortmund steht den Lesern mit myWMS LOS eine vollwertige SOA-Implementierung eines WMS auf Basis des Open-Source Rahmenwerks myWMS zur Verf¨ ugung. Anhand dieses Schulungssystems werden die Funktionsweise eines WMS und speziell die Hauptprozesse Wareneingang, Kommissionierung und Warenausgang in manuellen L¨agern veranschaulicht. Zielsetzung ist die Vermittlung der Grundfunktionen aus Anwendersicht. Neben dieser Schulungsversion ist myWMS LOS unter der Open Source Lizenz GPL im Quelltext verf¨ ugbar und kostenlos nutzbar. Die Schulungsversion steht den Lesern unter http://extras.springer.com zur Verf¨ ugung. Durch die Nutzung dieser Download-Plattform anstelle der bislang dem Buch beigef¨ ugten CD steht der jederzeitige Zugriﬀ auf myWMS LOS inklusive aller zuk¨ unftigen Aktualisierungen zur Verf¨ ugung. Dortmund, im Fr¨ uhjahr 2010

Michael ten Hompel, Thorsten Schmidt

VI

Vorwort zur 3. Auﬂage Heutige Lager- und Distributionssysteme stellen ¨außerst komplexe Knoten in den Wertsch¨ opfungsketten dar und unterliegen einer Vielzahl von Zeit-, Kosten- und Qualit¨ atsanforderungen. Der eﬃziente Betrieb eines solchen Systems ist f¨ ur jeden Verantwortlichen eine stete und große Herausforderung. Durch die Fortschritte in der Rechner- und Steuerungstechnik gepr¨agt, sind heute Steuerungs- und Verwaltungssysteme (Warehouse Managementsysteme, WMS) verf¨ ugbar, die einen eﬃzienten Betrieb unter den zahlreichen Anforderungen u oglichen. Gleichzeitig sind diese Systeme ¨ berhaupt erst erm¨ zwangsl¨ auﬁg zu einem Komplexit¨ atsgrad gereift, der die Anwender gelegentlich auch u ¨ berfordert. Die Unterschiedlichkeit der angebotenen L¨osungen und die Verschiedenartigkeit der Systemanforderungen fordern bei Gestaltung, Auswahl und Betrieb eines WMS umfassendes Wissen und Erfahrung. Es gilt eine verwirrende Vielfalt von Aspekten abzuw¨ agen und umzusetzen, die bei der Auswahl eines solchen Systems entscheidend f¨ ur Erfolg oder Misserfolg sein k¨onnen. ¨ An dieser Stelle soll das Buch Uberblick verschaﬀen und helfen, die richtige Entscheidung zu treﬀen. Es richtet sich unter anderem an Mitarbeiter, die mit der Auswahl und Speziﬁkation von Warehouse Managementsystemen befasst sind. Es werden Hintergr¨ unde, Potenziale, aber auch Gefahren und L¨ osungsstrategien aufgezeigt. Dadurch soll eine Basis f¨ ur vergleichende Betrachtungen geschaﬀen werden. Ebenso soll das Buch Studenten der Logistik und Anf¨ angern, die sich in diese Thematik einarbeiten, eine elementare St¨ utze sein. Die Ausrichtung dieses Buches ist praxisbezogen, ohne grundlegende Zusammenh¨ ange zu vernachl¨ assigen oder Spezialwissen vorauszusetzen. Die f¨ ur das Verst¨ andnis grundlegenden Abl¨ aufe und Techniken werden daher umfassend dargestellt. Systementwicklern sollen gleichzeitig neue Anregungen geliefert werden. Dazu werden Probleme und Grenzen der derzeitigen Entwicklung aufgezeigt und neue Ans¨ atze f¨ ur Struktur und Aufbau von WMS gegeben. Dem Buch wird ein einfaches, aber lauﬀ¨ ahiges und gut dokumentiertes WMS beigelegt, das der Open-Source Initiative myWMS entstammt. Um das System auch ohne die sonst zwingend erforderlichen Eingangsdaten f¨ ur einen einzelnen Anwender nutzbar zu machen, erm¨oglicht die dazugeh¨orige Simulationsumgebung den autarken Betrieb auf einem handels¨ ublichen PC. Durch entsprechende Visualisierung werden so Betrieb, Funktion und Nutzen eines WMS erfahrbar. Diese Buch w¨ are sicher nicht ohne die freundliche und engagierte Unterst¨ utzung fachkundiger Helfer entstanden. Unser Dank gilt besonders und in alphabetischer Reihenfolge Hubert B¨ uchter f¨ ur seine grundlegenden Betrachtungen zu den Themen Informationstechnik und Design von Warehouse Managementsystemen.

VII

Arnd Ciprina, der viele Gespr¨ ache mit Middleware-Anbietern gef¨ uhrt und die wesesentlichen Fakten zu diesem Thema zusammengetragen hat. Ulrich Franzke f¨ ur seine Ausarbeitungen zu den Themen XML und Kommunikation sowie f¨ ur seine Erl¨ auterungen zum Datenmodell des im Buch vorgestellten WMS. Olaf Krause f¨ ur seinen Beitrag zum Thema Software Engineering. Er ließ in seiner Rolle als Softwarearchitekt die Erfahrungen aus zahlreichen Industrie- und Forschungsprojekten einﬂießen. Dirk Liekenbrock, dem optimalen Fachmann f¨ ur Steuerung und Optimierung. Oliver Wolf, der im Fraunhofer IML das Team warehouse logistics leitet, das j¨ ahrlich die internationale Marktstudie Warehouse Management Systems (http://www.warehouse-logistics.com) durchf¨ uhrt. Sein Beitrag ﬁndet sich vor allem im Kapitel zum Thema Auswahl und Einf¨ uhrung von Warehouse Managementsystemen. Die konstruktive und freundliche Zusammenarbeit verschiedener Fachleute aus unterschiedlichen Fakult¨ aten war ein entscheidender Faktor zum Gelingen diese Buches. Daf¨ ur vielen Dank. Ohne die tatkr¨aftige Mitwirkung von Herrn Thomas Albrecht, Frau Susanne Grau, Herrn Jorgos Katsimitsoulias und Frau Sabine Priebs beim Satz und bei der Korrektur des Manuskriptes sowie der Erstellung der Abbildungen w¨ are die Bucherstellung ebensowenig m¨oglich gewesen. Auch ihnen gilt unser herzlicher Dank. Die Intralogistik als identit¨ atsstiftende und inhaltliche Klammer dieser Buchreihe spannt das Feld von der Organisation, Durchf¨ uhrung und Optimierung innerbetrieblicher Materialﬂ¨ usse, die zwischen den unterschiedlichsten Logistikknoten stattﬁnden, u origen Informationsstr¨ome bis ¨ber die dazugeh¨ hin zum Warenumschlag in Industrie, Handel und ¨oﬀentlichen Einrichtungen auf. Dabei steuert sie im Rahmen des Supply Chain Managements den gesamten Materialﬂuss entlang der Wertsch¨ opfungskette. Innerhalb dieses Spektrums pr¨ asentieren und bearbeiten die Buchtitel der Reihe Intralogistik als eigenst¨ andige Grundlagenwerke thematisch fokussiert und eng verzahnt die zahlreichen Facetten dieser eigenst¨ andigen Disziplin und technischen Seite der Logistik. Dortmund, im Sommer 2007

Michael ten Hompel, Thorsten Schmidt

Inhaltsverzeichnis

1.

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Lagerhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Merkmale von Lagersystemen . . . . . . . . . . . . . . . . . . . . . . 5 1.1.3 Optimierung von Lagersystemen . . . . . . . . . . . . . . . . . . . 7 1.2 Warehouse Management und Lagerverwaltung . . . . . . . . . . . . . 8 1.3 Systemschnittstellen und Abgrenzung . . . . . . . . . . . . . . . . . . . . . 9 1.4 Aufbau und Ziel des Buches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.

Lagersysteme und Lagerverwaltung . . . . . . . . . . . . . . . . . . . . . . . 2.1 Logistische Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Logistik-Grunds¨ atze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Verpackung und Logistische Einheiten . . . . . . . . . . . . . . 2.2 Funktionen in Lagersystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Warenannahme und -eingang . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Einlagerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Auslagerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Konsolidierungspunkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Kommissionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.6 Verpackung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.7 Versand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Warehouse Managementsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Lagerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Reorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 F¨ ordermittelverwaltung und Leitsysteme . . . . . . . . . . . . 2.3.4 Datenerfassung, -aufbereitung und -visualisierung . . . . 2.3.5 Inventur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Basisdaten und Kennzahlen von Lagersystemen . . . . . . . . . . . . 2.4.1 Basisdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Logistische Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Besondere Abl¨ aufe und Verfahrensweisen . . . . . . . . . . . . . . . . . . 2.5.1 Cross Docking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Outsourcing der physischen Distributions- und Lagerprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 15 15 19 23 23 28 32 34 34 51 53 54 54 57 58 60 62 65 65 67 69 69 70

X

Inhaltsverzeichnis

2.5.3 Outsourcing der Software: Application Service Providing 71 3.

Grundlagen der Lager- und F¨ ordertechnik . . . . . . . . . . . . . . . . 3.1 Lagersysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Bodenlager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Statische Regallagerung . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Dynamische Regallager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Regalvorzone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 F¨ ordersysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Stetigf¨ orderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Unstetigf¨ orderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Sortier- und Verteilsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Einsatzfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Grunds¨ atzlicher Aufbau von Sortiersystemen . . . . . . . . . 3.3.3 Verteiltechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Steuerung und Strategien . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Robotereinsatz in Lagersystemen . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Palettierroboter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Kommissionierroboter . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73 73 74 76 85 89 90 91 95 113 113 114 120 122 123 124 124

4.

Grundlagen der betrieblichen Optimierung . . . . . . . . . . . . . . . ¨ 4.1 Optimierung in der Ubersicht ............................ 4.1.1 Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Einordnung der betrieblichen Optimierung . . . . . . . . . . . 4.1.3 Begriﬀe und Elemente der Disposition . . . . . . . . . . . . . . . 4.2 Optimierungsaufgaben im Lager . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Transportoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Bildung von Kommissionierreihenfolgen . . . . . . . . . . . . . 4.2.3 Routenplanung im Lager . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 4.2.4 Ubergreifende Auftragsdisposition – Batchplanung . . . . 4.3 Verfahren der L¨ osungsoptimierung . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 4.3.2 Optimierungsverfahren im Uberblick ................ 4.3.3 Beispiele bekannter L¨ osungsverfahren . . . . . . . . . . . . . . .

125 125 126 128 130 131 132 141 143 144 146 146 148 150

5.

Informations- und Kommunikationstechnik . . . . . . . . . . . . . . . 5.1 Kommunikationstechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Schichtenmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 5.1.3 Ubertragungsmedien .............................. 5.1.4 Netztypen und Internetworking . . . . . . . . . . . . . . . . . . . . 5.1.5 Netzwerkadressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.6 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

157 157 158 158 161 164 167 169 173 173

Inhaltsverzeichnis

5.2.2 Dateisysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.4 Datenverf¨ ugbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Endger¨ ate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Funktionale Sicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Zugangskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4 Internationalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.5 Hilfesysteme und Hilfsdienste . . . . . . . . . . . . . . . . . . . . . . Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programmiersprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 5.5.1 Ubersetzer und Interpreter . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 Sprachkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3 Sprachgenerationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sicherheitsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Geheimhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Integrit¨ atssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.3 Authentiﬁzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.4 Echtheitsnachweis und elektronische Signatur . . . . . . . .

175 177 182 186 186 187 188 189 190 190 191 192 203 204 207 209 214 215 217 217 219

Softwareengineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Softwarearchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Monolithische Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Modularisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3 Schichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.4 Verteilte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.5 Konﬁguration und Erweiterung . . . . . . . . . . . . . . . . . . . . 6.2 Grundz¨ uge der objektorientierten Programmierung . . . . . . . . . 6.2.1 Datenabstraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Klassen und Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Eigenschaften von Klassen . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Uniﬁed Modeling Language (UML) . . . . . . . . . . . . . . . . . . . . . . . 6.4 Middleware und Kommunikationsmechanismen . . . . . . . . . . . . . 6.4.1 Kommunikationspartner . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Kommunikationsmechanismen . . . . . . . . . . . . . . . . . . . . . 6.5 Application-Server (Java EE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Service-orientierte Architektur (SOA) . . . . . . . . . . . . . . . . . . . . .

221 221 222 223 224 226 228 229 229 231 233 235 235 240 241 243 245 251

5.3

5.4

5.5

5.6

6.

XI

XII

Inhaltsverzeichnis

7.

Implementierung eines WMS am Beispiel myWMS . . . . . . . 7.1 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Klassische Realisierung eines WMS . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Funktionale Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Tabellenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Sicherung der logischen Integrit¨at . . . . . . . . . . . . . . . . . . 7.2.4 Anlegen und Abfragen von Stammdaten . . . . . . . . . . . . . 7.3 Implementierung mit myWMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Grunds¨ atzlicher Aufbau von myWMS . . . . . . . . . . . . . . . 7.3.2 Gesch¨ aftsobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3 SOA Konzept von myWMS LOS . . . . . . . . . . . . . . . . . . . 7.3.4 Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Beispielhaftes Distributionssystem/Referenzlager . . . . . . . . . . . 7.4.1 Beschreibung des manuellen Regallagers . . . . . . . . . . . . . 7.4.2 Beschreibung des automatischen Lagersystems . . . . . . . 7.4.3 Prozesse aus Anwendersicht . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Erweiterungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Erg¨ anzung eines Pick-By-Light Systems . . . . . . . . . . . . . 7.5.2 Anbindung der F¨ ordertechnik und Steuerungstechnik . 7.5.3 Materialﬂuss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.4 Plug-In - Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.5 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

255 256 263 264 265 268 269 270 271 274 276 281 282 283 284 285 290 291 293 294 295 296 300

8.

Auswahl und Einf¨ uhrung von WMS . . . . . . . . . . . . . . . . . . . . . . 8.1 Kick-oﬀ: WMS-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Projektmanagement/Qualit¨ atssicherungsmaßnahmen . . . . . . . . 8.3 Anforderungsdeﬁnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Ist-Aufnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Schwachstellen-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 Entwicklung Soll-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Erstellung der Ausschreibungsunterlagen . . . . . . . . . . . . . . . . . . 8.4.1 Deﬁnition Leistungsverzeichnis . . . . . . . . . . . . . . . . . . . . . 8.4.2 Erstellung Lastenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.3 Komplettierung der Ausschreibungsunterlagen . . . . . . . 8.5 Auftragsvergabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.1 Anbietervorauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.2 Standort-/Lagerbesichtigung . . . . . . . . . . . . . . . . . . . . . . . 8.5.3 Angebotsvergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.4 Angebotspr¨ asentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.5 Referenzbesuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.6 Anbieterauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.1 Pﬂichtenhefterstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . .

301 302 303 304 304 306 307 309 309 311 314 314 314 316 317 320 320 320 321 321

Inhaltsverzeichnis

9.

XIII

8.6.2 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Inbetriebnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.1 Laborphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 8.7.2 Ubergang vom alten zum neuen WMS . . . . . . . . . . . . . . 8.7.3 Schulungsmaßnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8 Abnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.1 Leistungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 8.8.2 Simulation von St¨ orf¨ allen / Uberpr¨ ufung von Notfallstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.3 Verf¨ ugbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.4 Formale Abnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

323 324 324 325 326 326 326

Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 9.1 Uberblick markt¨ ublicher Technologien am Beispiel (Auto-ID) Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.2 SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.3 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.4 IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.5 SUN Microsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

331

327 328 328

331 333 334 335 338 339

Abk¨ urzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

1. Einleitung

Warehouse Management beschreibt die Kunst, ein Lager- und Distributionssystem zu f¨ uhren – genauer gesagt: eﬃzient zu f¨ uhren. Exzellente Logistikleistungen k¨ onnen heute neue M¨ arkte erschließen, gleichsam erwarten die Kunden Schnelligkeit, Qualit¨ at und Kostenminimierung der logistischen Leistungen. L¨ ager und Umschlagsysteme stellen dabei die Kernelemente im Warenﬂuss zwischen Produzenten und Verbrauchern dar. Die im Rahmen der Warenvorhaltung und -verteilung anfallenden T¨atigkeiten und Aufgaben sind in einem Lagersystem nur dann zu erreichen, wenn ein auf die speziellen Anforderungen zurechtgeschnittenes System geformt wird, das sich aus • der technischen Grundstruktur, • dem betrieblich-organisatorischen Rahmen und • der alles koordinierenden Systemf¨ uhrung zusammensetzt. Fragen der Planung der technischen Systemstruktur betreﬀen beispielsweise die Layoutierung des Systems, die Auswahl und Dimensionierung der f¨order- und lagertechnischen Gewerke oder die Gestaltung der physischen Schnittstellen zu angrenzenden Systemen. Die Behandlung dieser Fragen ist Gegenstand unz¨ ahliger Ver¨ oﬀentlichungen (s. u. a. [2, 16, 24, 34, 47, 48, 61]) und soll im Rahmen dieses Buches nur soweit ber¨ ucksichtigt werden, wie es f¨ ur Fragen der Systemsteuerung von Bedeutung ist. Ebenso ist die Gestaltung der betrieblichen Organisation sowie der Logistikorganisation ein Bereich, in dem vielf¨ altigste Aspekte aus unterschiedlichsten Bereichen (Betriebswirtschaft, Organisationswesen, Verkehrswesen) zusammenﬂießen. Im Blickpunkt dieses Buches stehen speziell Fragen der eﬃzienten Nutzung vorhandener Ressourcen. Zur Behandlung spezieller betriebswirtschaftlicher Fragestellungen oder der Gestaltung u ¨ berbetrieblicher Logistikstrukturen wird auf die einschl¨ agige Literatur verwiesen (vgl. u. a. [29, 41, 80]). Ein eﬃzientes Lagermanagement stellt Expertenwissen dar, das die exakte Kenntnis der erforderlichen Abl¨ aufe, das Wissen des technisch und betrieblich Machbaren und die erfolgreiche Umsetzung in ein funktionierendes Gesamtsystem umfasst. Zur Erreichung dieser Zielsetzung existieren jedoch keine allgemein g¨ ultigen und universell verwendbaren Regeln. Zu verschieden

2

1. Einleitung

sind die Anforderungen, die aus dem Bestellverhalten der Kunden, der Attraktivit¨ at der Produkte und Dienstleistungen, den Anforderungen der Produktion und vielem mehr resultieren. Der Gestaltung und Realisierung des F¨ uhrungs- und Kontrollsystems kommt eine besondere Bedeutung zu. W¨ ahrend Fragen der Planung technischer Systeme und maschinenbaulicher Gewerke u ¨berwiegend einmalig bzw. im Rahmen von Ausbau- und Optimierungsmaßnahmen durchgef¨ uhrt werden, fallen bei der Systemf¨ uhrung sowohl einmalige Aspekte der Systemgestaltung und -implementierung als auch kontinuierliche Dispositionsaufgaben w¨ ahrend des Betriebs der Lager- und Distributionssysteme an. Hier ¨ ist eine st¨ andige Uberwachung und F¨ uhrung der Prozesse und Anpassung der Abl¨ aufe erforderlich. Ein Blick auf die Leistungsdaten heutiger Lager- und Distributionssysteme verdeutlicht sehr schnell, dass die Komplexit¨at (Umfang und Dynamik) der Abl¨ aufe praktisch nur durch Einsatz rechnergest¨ utzter Managementsysteme beherrschbar wird. Die mit den zahlreichen Funktionalit¨aten versehenen Steuerungssysteme reifen aber auch ihrerseits zu immer komplexeren und schwierig zu fassenden Systemen. Eine große Schwierigkeit besteht deshalb in der Identiﬁzierung und Anpassung eines geeigneten Systems an ein vorhandenes Anforderungsproﬁl. Auf dem Markt existieren zahlreiche Anbieter f¨ ur Logistiksteuerungssysteme, deren Bewertung aufgrund der unterschiedlichen Ausrichtung ihrer Produkte sehr schwierig ist. Eine weitere H¨ urde ist die fehlerfreie Umsetzung (Implementierung) des Systems. Insbesondere Verz¨ ogerungen bei der Inbetriebnahme und Ausf¨alle im Betrieb sind nicht nur kostentr¨ achtig, sondern k¨onnen durch die Gefahr der Abwanderung von Kunden, eines schlechten Rufes auf dem Markt oder m¨ oglicher Regressforderungen auch den mittel- und langfristigen Unternehmenserfolg gef¨ ahrden. Entscheidend ist also, ein passendes System mit sehr hoher Verf¨ ugbarkeit zu schaﬀen. Es geht in diesem Buch daher nicht nur um die Frage, wie Lager- und Distributionssysteme technisch gestaltet werden k¨onnen, sondern auch darum, wie sie im Zusammenspiel der Systeme sinnvoll betrieben werden k¨onnen. Das f¨ ur diese Umsetzung erforderliche Wissen und Handwerkszeug soll durch ¨ dieses Buch bereitgestellt werden. Es soll Ubersicht schaﬀen, Standards aufzeigen und Fehler vermeiden helfen.

1.1 Anforderungen Bevor eine detaillierte Behandlung der Aspekte rund um das Warehouse Management erfolgt, soll zun¨ achst das Wesen der Lagerhaltung und der Warenverteilung beleuchtet werden.

1.1 Anforderungen

3

1.1.1 Lagerhaltung Obwohl mit diesem Stichwort aufgrund der damit verbundenen Kosten und der vermeintlich wertsch¨ opfungslosen Zeit¨ uberbr¨ uckung h¨auﬁg negative Eigenschaften verbunden werden, ist die Lagerung von Waren in der Praxis aus vielf¨ altigsten Gr¨ unden in den meisten Bereichen unumg¨anglich. Eine aus logistischer Sicht wesentliche Besonderheit ist dabei, dass es sich um einen geplanten Prozess der Zeit- und Zustands¨ uberbr¨ uckung handelt [24]. Einige wesentliche Gr¨ unde zur Errichtung und zum Betrieb von Lager- und Distributionssystemen entlang mehrstuﬁger Versorgungsketten sind daher die Folgenden: Optimierung logistischer Leistung: Ein elementares Kundenanliegen besteht zumeist in der kurzfristigen Erf¨ ullung eines erteilten Auftrags. Da sich Auftragszeitpunkt und die Auftragsmenge f¨ ur die relevante Masse der Waren nicht exakt vorherbestimmen lassen, ist der erste Ansatz die Bevorratung einer prognostizierten Warenmenge, was sich auch pr¨ agnant als Sicherstellung der Lieferf¨ahigkeit beschreiben l¨asst. Insbesondere bei großen r¨ aumlichen Distanzen zwischen der Produktentstehung und Konsumierung, bei denen gegebenenfalls noch Prozesse der Zollabfertigung stattﬁnden, erh¨ alt dieser Ansatz seine Berechtigung. Ferne M¨ arkte k¨ onnen zum Teil erst hierdurch erschlossen werden. Eine in allen Bereichen wachsende Vielfalt an Waren oder Artikeln, der Wandel im Bestellverhalten hin zu einer h¨oherfrequenten Auftragserteilung geringerer Teilmengen und die g¨angige Forderung nach immer k¨ urzeren Lieferzeiten lassen die logistische Leistung zu einem entscheidenden Kriterium f¨ ur die Auswahl eines Lieferanten werden. Durch Einsatz leistungsf¨ ahiger und eﬃzient gef¨ uhrter Warenverteilzentren kann im Marktwettbewerb eine Position erreicht, behauptet oder ausgebaut werden. ¨ Nat¨ urlich bedarf diese Vorratshaltung der kontinuierlichen Uberwachung der Bestandsmengen und der Optimierung des Bestellverhaltens, um zu hohe oder zu lange lagernde Warenbest¨ ande zu vermeiden. Sicherstellung der Produktionsf¨ ahigkeit: Die Sensibilit¨at von Produktionsketten, die nach dem Just-In-Time-Ansatz (richtigerweise) auf eine konsequente Minimierung der Best¨ ande entlang der Lieferkette ausgelegt sind, ließ sich in der Vergangenheit immer wieder an markanten Stillst¨ anden ganzer Produktionslinien in der Automobilindustrie ermessen, wenn aus Gr¨ unden wie Grenzblockaden aufgebrachter Fernfahrer oder Streik in externen Zulieferbetrieben wichtige Bauteile nicht rechtzeitig verf¨ ugbar waren. Die Sicherstellung der Materialverf¨ ugbarkeit zur Auslastung kostenintensiver Produktionsstufen ist nach wie vor eine der Hauptursachen der Bestandsbildung. Erbringung zus¨ atzlicher Dienstleistungen: L¨angst gehen die Anforderungen an ein Lager u ¨ ber die kurzfristige Bereitstellung eines einzelnen

4

1. Einleitung

Produktes oder Artikels hinaus. Einerseits w¨achst die Variantenvielfalt durch die aus Sicht des Produktmarketings reizvolle Produktdiﬀerenzierung und damit die Sortimentsgr¨ oße in nahezu allen Bereichen. Ein Ansatz, der daraus resultierenden Kostensteigerung entgegenzutreten, ist die endg¨ ultige Variantenbildung zu einem m¨oglichst sp¨aten Zeitpunkt unter Verwendung weniger Grundelemente. Dabei werden solche Produktionsschritte zunehmend als Montagedienstleitungen in Warenverteilzentren durchgef¨ uhrt. Andererseits k¨ onnen auch Fertigprodukte die Spezialisierung auf verschiedene Verkaufskan¨ ale, beispielsweise durch die sp¨ate Anbringung von Verkaufsinformationen (Label etc.) oder den Aufbau von Aktionsst¨anden zu verkaufsf¨ ordernden Maßnahmen, erfahren. Transportkostenreduktion: Einer der Hauptgr¨ unde zur Bestandsbildung bleibt das Ziel, Transportkosten zu optimieren und sprungﬁxe Kostens¨atze im Transportgewerbe durch m¨ oglichst gute Nutzung der Laderaumkapazit¨ aten (Ganzladungen) zu nutzen. Eng damit verbunden ist aber auch die Notwendigkeit einer Optimierung der Umschlagprozesse in Warenein- und -ausgang. Die Bearbeitung einer Vielzahl kleiner Mengen ist in der Regel wesentlich ineﬃzienter als die der konsolidierten Menge. Dadurch lassen sich wiederum vorhandene Kapazit¨ aten (Anzahl von Ladetoren, Rangierﬂ¨ achen etc.) vorteilhafter nutzen. Insbesondere im Bereich des Einzelhandels fehlen die Kapazit¨aten einer laufenden Bereitschaft zur Warenannahme (Personal und Ladetore), so dass an diesen Schnittstellen bedarfsgerechte Liefermengen gesammelt angeliefert werden m¨ ussen. Ausgleich von Bedarfs- und Liefermengen: Trotz der l¨angst vollzogenen Wandlung vom Verk¨ aufer- zum K¨ aufermarkt und der damit verbundenen Auslegung der Produktionscharakteristik in Richtung bedarfsgesteuerter Produktion (Pull-Systeme) bleibt in vielen Bereichen die wirtschaftliche Notwendigkeit einer Produktion in entsprechenden Losgr¨oßen bestehen. Innerhalb der Produktion sind einzelne Produktionsphasen durch verschiedenartige Prozesszeiten und Ausbringungsmengen oder unregelm¨aßige Zu- und Abg¨ ange zwischen Bereichen gekennzeichnet. Die Vermeidung von Leerlaufzeiten erfordert wiederum die Puﬀerung von Halbfertigprodukten zur gleichm¨ aßigen Nutzung von Produktionsanlagen oder -prozessen. Bestimmte Produktionsprozesse unterliegen dar¨ uber hinaus zeitlich nicht beeinﬂussbaren Gesetzm¨ aßigkeiten (z. B. Abk¨ uhlungsprozesse, Wachstumsprozesse von Kulturen in der Pharmazie etc.), die somit nicht dem kontinuierlichen oder sporadischen Bedarfsverhalten entsprechen. Viele Gesch¨ aftsfelder unterliegen ferner erheblichen saisonalen Schwankungen, die nicht wirtschaftlich durch Anpassungen der Produktionskapazit¨ aten abgefedert werden k¨ onnen.

1.1 Anforderungen

5

Nutzung der Marktposition: Die durch Nutzung von Mengenrabatten induzierte Lagerhaltung ist eine klassische Kostenrechnungsfrage und erschließt sich u oßendegressionseﬀekte auf der Zulieferseite, denen ¨ber Gr¨ die Kosten der Lagerhaltung, aber auch weitere Komplexit¨atskosten wie z.B. Administrationskosten (Durchf¨ uhrung der Bestellung, Preisverhandlungen) gegen¨ uberstehen. Lagerung als Prozessschritt: Bei verschiedenen Produkten oder Abl¨aufen stellt die Lagerung einen elementaren Prozess der Wertsch¨opfung oder -steigerung dar (z.B. durch Reifung oder spekulative Absichten) und wird damit zu einem Teil des Produktionsablaufes. Wie sich aus dieser Auﬂistung entnehmen l¨asst, zwingen nicht allein Gr¨ unde der Produktionslosgr¨ oßenoptimierung oder Einkaufsmengenrabattierung zur Bestandsvorhaltung, sondern insbesondere auch ein Geﬂecht miteinander gekoppelter Prozesse, die zur Ablaufoptimierung der Puﬀerung und Ver¨ anderung der Warenstr¨ ome bed¨ urfen. Folgerichtig geht es bei der Bestandsvorhaltung nicht allein um den Aspekt der reinen Lagerung. Entscheidender sind vielmehr die Prozesse der optimierten, eﬃzienten Behandlung erforderlicher Warenstr¨ ome und deren jeweilige Anpassung auf ideale Zusammensetzung, Menge und Form. 1.1.2 Merkmale von Lagersystemen Der Basisprozess in einem Lager und Warenverteilsystem ist so banal wie simpel. Ein angelieferter Artikel wird nicht direkt ben¨otigt und deshalb zur Seite gelegt, bis zu dem Zeitpunkt, zu dem ein Kunde ihn verlangt. Er wird dann hervorgeholt und u ¨bergeben. Damit reduzieren sich die Kernschritte auf Waren empfangen, lagern, entnehmen, versenden. In der Praxis wird dieser scheinbar einfache Ablauf nun durch Zeit-, Qualit¨ ats- und Kostenanspr¨ uche sowie eine Verkettung a¨ußerer Einﬂ¨ usse schnell zu einem komplexen Prozess mit F¨ uhrungs- und Optimierungsbedarf: • Im Wareneingang sind ankommende Lieferungen oft nicht planbar oder erfolgen unregelm¨ aßig mit ausgepr¨ agten Spitzen. • Das Warensortiment erfordert aufgrund seiner Abmessungen, Gewichte, Temperaturanforderungen etc. eine Vielzahl unterschiedlicher Transport-, Lager- oder Handhabungstechniken, die jeweils vorzuhalten und bereitzustellen sind. • Das Durchsatzverhalten einzelner Artikel ist sehr unterschiedlich und unterliegt zudem hohen zeitlichen Schwankungen. • Durch die Kunden werden jeweils nur geringe Mengen geordert, allerdings sollen diese in k¨ urzester Zeit zusammengetragen werden und im Versand gleichzeitig ankommen, so dass eine einzige Versandeinheit gebildet werden kann.

6

1. Einleitung

Tabelle 1.1. Beispielhafte Kenndaten von Warenverteilzentren (u. a. nach [29]) Versandhandel (sehr groß)

Pharmagroßhandel

Lebensmittel Regionallager

Produzent Elektrohaushaltsgeräte

Kunde

Endkunden, Sammelbesteller, Filialen

Apotheken

Filialen

stationärer Handel

Anz. verschiedener Artikel

250 000

130 000

8150

200

Lagerhaltung

25 Mio. Stck

4,5 Mio. Stck

2 Mio. Einh

150 000 Stck

Personal

≥2000

ca. 300

ca. 300

75

Kommissionierung

2700 Pal.-Plätze 740 000 Kartonplätze

125 000 Fächer

32 000 Pal.-Plätze 15 000 Bodenplätze

4000 Pal.- Plätze

Aufträge/Tag

190 000

6800

780

350

Auftragspos./ Tag

650 000

105 000

300 000

4000

WELieferungen

150 Lkw/Tag

220 EP/Tag

100 Lkw/Tag

625 EP/Tag

WASendungen

≈ Aufträge

= Aufträge

100 Lkw/Tag

722 EP/Tag

Durchlaufzeit/ Kundenauftrag

4–5 h

50 min

24 h

4h

• Gleichzeitig m¨ ussen Hunderte von Auftr¨ agen abgearbeitet werden, wobei die Reihenfolge der Abarbeitung nach Kundenposition, Auftragstyp, Versandart, m¨ oglichen Zeitfenstern und vorhandenen personellen und technischen Kapazit¨ aten optimiert werden muss. • Die Systemparameter bleiben nicht konstant, sondern unterliegen st¨andigen Ver¨ anderungen in Bezug auf Mengenstr¨ ome, Kundenauftragsstruktur, Artikelvielfalt und -form usw. • vieles mehr In solchen Systemen resultiert die Komplexit¨at aus der Systemgr¨oße, Warenmenge oder geforderten Reaktionsgeschwindigkeit und Dynamik. F¨ ur eine ¨ vergleichende Betrachtung und einen groben Uberblick sind dazu einige wesentliche Kennzahlen in Tabelle 1.1 gegen¨ ubergestellt.

1.1 Anforderungen

7

1.1.3 Optimierung von Lagersystemen Wie bereits oben angef¨ uhrt, wird der Prozess der Lagerhaltung aufgrund der Kosten kritisch betrachtet, was absolut richtig ist, teilweise jedoch auch zu fragw¨ urdigen Entscheidungen f¨ uhrt. So wird mitunter bereits dar¨ uber philosophiert, ob die breite Tendenz zum Outsourcing nicht auch insbesondere dadurch vorangetrieben wird, dass Entscheidungstr¨ager von der arbeitsaufw¨ andigen Analyse und Prognostizierung von Aufw¨anden und Erl¨osen der hauseigenen Logistik befreit werden. [5] Neben den oﬀensichtlichen Kosten der Lagerhaltung und -f¨ uhrung, wie Bestandskosten (im wesentlichen Kapitalbindungs- und Versicherungskosten) und den durch Lager- und Warenverteilsystem verursachten Kosten f¨ ur Technik, Personal und Betrieb, existieren durch Bestandsvorhaltung aber auch spezielle Probleme und indirekte Kosten, die nur schwer zu erfassen sind. So werden durch entsprechende Bestandspegel auch unwirtschaftliche Abl¨ aufe und ineﬃziente Strukturen verdeckt. Bei komplexen Systemen besteht dar¨ uber hinaus durch die Vielzahl paralleler Transaktionen und Abl¨aufe die prinzipielle Gefahr der Intransparenz. Durch das Bestreben, Lageranzahl und -standorte durch Zentralisierungsbem¨ uhungen zu reduzieren oder einzelne Lagerstufen zu eliminieren, steigt jedoch der Anspruch an die Transparenz von Abl¨aufen, Best¨anden und Auftr¨ agen. Um den allgemein gewachsenen Anforderungen an das zeitliche Reaktionsverm¨ ogen und die logistische Leistungsf¨ahigkeit der Warenverteilsysteme bei konsequenter Minimierung der Best¨ ande und Optimierung der Kosten gerecht zu werden, bedarf es strukturierter, transparenter Abl¨aufe einerseits und eines hohen Maßes an Disziplin in der Durchf¨ uhrung der Aufgaben andererseits. Erst durch den Einsatz von Warehouse Managementsystemen (WMS) werden diese Ziele in vielen F¨ allen erreicht. Eines der Schl¨ usselelemente eines eﬃzienten WMS ist in diesem Zusammenhang die Vermittlung von Vertrauen und Sicherheit in das F¨ uhrungs- und Kontrollsystem. Eine wesentliche Ursache f¨ ur die Anh¨aufung u berh¨ ohter Si¨ ” cherheitsbest¨ ande“ ist schlichtweg Unsicherheit auf Seiten der Disponenten und weiterer Lagerverantwortlicher. Solche Unsicherheit resultiert beispielsweise aus einer unvollst¨ andigen Datenbasis oder zeitaufw¨andigen Recherchen nach Bestandsmengen, Lagerorten oder Auftragsstati. Ein transparentes System beginnt bei der Datensicherheit und schaﬀt dadurch Akzeptanz f¨ ur die G¨ ultigkeit der Datenbasis und schließlich den Abbau verdeckter Sicherheitsbest¨ ande. Sicherheit und pr¨ azises Datenhandling m¨ ussen daher auch Zielsetzungen eines jeden WMS sein. Transparente Abl¨aufe bieten die wesentliche Grundlage f¨ ur eine kontinuierliche Systemoptimierung. Neben der Kontrollier- und Steuerbarkeit der Prozesse wird auch eine h¨ ohere Reaktionsgeschwindigkeit und Flexibilit¨at erreicht. Schnelle Ortung von und Zugriﬀ auf Waren sind Grundvoraussetzungen f¨ ur eine Anpassung an den heutigen schnellen Wandel in den u ¨bergeordneten Strukturen. Durch Schnittstellen zu u ¨ bergeordneten Systemen wird Austauschbar-

8

1. Einleitung

¨ keit gew¨ ahrleistet, und Anderungen k¨ onnen kurzfristig durch ein angepasstes Verhalten ber¨ ucksichtigt werden.

1.2 Warehouse Management und Lagerverwaltung F¨ ur dieses Buch wurde zur Beschreibung der Prozesse und Technologien des Managements von L¨ agern bewusst der Begriﬀ Warehouse Management gew¨ ahlt, obwohl hierzu der seit langem eingepr¨agte deutsche Begriﬀ Lagerverwaltung existiert. Ein Großteil der hier behandelten Inhalte betriﬀt die Steuerung und Verwaltung von Lagersystemen; demnach scheint der Begriﬀ Lagerverwaltungssystem viel angebrachter. Bei genauerer Betrachtung zeigt sich jedoch, dass die Begriﬀe Warehouse Management und Lagerverwaltung nicht austauschbar sind. Ein Lagerverwaltungssystem beschreibt im Kernbereich zun¨achst ein System zur Verwaltung von Mengen und Orten (Lagerorten) und insbesondere deren Beziehung zueinander. Ein solches System kann dabei auch manuell z. B. Lagerleiter mit Karteikartensystem1 ) realisiert sein. Die Mehrzahl dieser Verwaltungssysteme d¨ urfte heute aber rechnergest¨ utzt arbeiten. Zus¨ atzliche Funktionen k¨ onnen dabei auch die Verwaltung der Transportsysteme beinhalten. Somit stellt ein Lagerverwaltungssystem im engeren Sinne ein Lagerbestandsverwaltungssystem dar. Das Warehouse Management bezeichnet im allgemeinen Sprachgebrauch dagegen die Steuerung, Kontrolle und Optimierung komplexer Lager- und Distributionssysteme. Neben den elementaren Funktionen einer Lagerverwaltung wie Mengen- und Lagerplatzverwaltung, F¨ordermittelsteuerung und -disposition geh¨ oren nach dieser Betrachtungsweise auch umfangreiche Methoden und Mittel zur Kontrolle der Systemzust¨ande und eine Auswahl an Betriebs- und Optimierungsstrategien zum Leistungsumfang. Auf ein derartiges, u ¨ bergreifendes Verwaltungs- und Managementsystem triﬀt der deutsche Begriﬀ Lagerverwaltungssystem nicht mehr zu. Es m¨ usste also exakter als innerbetriebliches Materialﬂusskontroll-, -steuerungs- und -optimierungssystem oder Kontroll-, Steuerungs- und Optimierungssystem f¨ ur den (innerbetrieblichen) Materialﬂuss bezeichnet werden. F¨ ur eine klare Abgrenzung wird daher im Folgenden der auch im deutschen Sprachgebrauch eingepr¨agte und pr¨ agnante Titel Warehouse Management als Synonym f¨ ur ein u ¨ bergreifendes Instrumentarium Verwendung ﬁnden. 1

In der Tat werden auch heutzutage manuell gef¨ uhrte Systeme in bestimmten Bereichen ¨ außerst eﬃzient eingesetzt. Beispielsweise werden in kleineren Pufferl¨ agern in Produktions- und Montagesystemen Pinboards mit Anh¨ angern f¨ ur jede Materialart eingesetzt. F¨ ur jeden Artikel existiert ein Schacht, bei Einlagerung wird eine Karte mit der Lagerplatznummer oben nachgef¨ ullt, zur Auslagerung unten entnommen. Dieses ¨ außerst einfache System erm¨ oglicht bei wenigen Artikeln gleichzeitig eine ideale Visualisierung der Best¨ ande.

1.3 Systemschnittstellen und Abgrenzung

9

1.3 Systemschnittstellen und Abgrenzung Die Aufgabe von Warehouse Managementsystemen besteht in der F¨ uhrung und Optimierung von innerbetrieblichen Lagersystemen. In dieser Position ergibt sich eine F¨ ulle von Schnittstellen zu angrenzenden System, deren Abgrenzung nicht immer leicht f¨ allt. Je nach Einsatzfall und vorliegender Systemstruktur ﬁnden sich einzelne Steuerungsmodule auch in angrenzenden Systemen wieder. In kleineren Unternehmen werden nicht notwendigerweise alle Systeme eingesetzt, und nicht origin¨ are Systemelemente werden Bestandteil eines WMS. Funktionsbedingt bestehen enge Verkn¨ upfungen zu Systemen der Materialwirtschaft (WWS-, PPS- oder ERP-Systeme) und den Systemen zur unmittelbaren Steuerung des Materialﬂusses und der Kommissionierung (Warehouse Control Systeme (WCS) und Materialﬂussrechner (MFR)). Die Systeme lassen sich folgendermaßen abgrenzen [58]: Warenwirtschaftssystem (abgek. WWS, engl. Enterprise resource planning system (ERP system)) ist ein rechnergest¨ utztes System zur artikelund mengengenauen Erfassung und Verfolgung von Bedarfs- und Mengenstr¨ omen, wie sie beispielsweise im Handelsbereich zum Einsatz gelangen. Das u ¨ bergeordnete Ziel ist die Steuerung von Bestellwesen, Warenvorhaltung und Verkauf. Managementinformationssystem (abgek. MIS) hat als vorrangige Aufgabe die Vorbereitung von Managemententscheidungen. MIS werden oftmals als Bestandteil eines WWS gef¨ uhrt. Seit Mitte der 90er Jahre werden zunehmend analytische Funktionen in MIS integriert. Trends, Prognosen und Analysen im echtzeitnahen Bereich sollen das Management unterst¨ utzen. Produktionsplanung und -steuerungssystem (abgek. PPS, engl. Production planning and control system) umfasst informationsverarbeitende Systeme der Produktionsplanung und -steuerung. PPS-Systeme lassen sich nach dem Steuerungsprinzip einteilen... Enterprise Resource Planning System (abgek. ERP System) ist ein integriertes Softwaresystem zur umfassenden Planung und Koordination unternehmerischer, insbesondere betriebswirtschaftlicher Aufgaben mit dem Ziel, die in einem Unternehmen vorhandenen Ressourcen m¨oglichst eﬃzient einzusetzen. Materialﬂussrechner (abgek. MFR, engl. Material ﬂow computer) Die Umsetzung teil- oder vollautomatischer Materialﬂussoperationen erfolgt im MFR der die Reihenfolge koordiniert, ggf. auch optimiert, und die Quelle-Ziel-Beziehungenkontrolliert, in der einzelne Auftr¨age, Prozesse usw. abgearbeitet werden. Dazu werden unterlagerte Steuerungen angesprochen. Warehouse Control System (abgek. WCS) Vergleichbar mit dem MFR kontrollieren WCS Quelle-Ziel-Beziehungen. Typischerweise werden zu-

10

1. Einleitung

s¨ atzliche Aufgaben integriert, die u ¨ ber den Umfang eines reinen MFR hinausgehen. WCS k¨ onnen insbesondere lokale bzw. nicht bewegte Best¨ande verwalten. Sie gelangen insbesondere dort zum Einsatz, wo wesentliche Funktionen eines WMS durch WWS bzw. ERP-Systeme abgedeckt werden und demzufolge eine separates WMS nicht erforderlich ist. Das Zusammenwirken der verschiedenen Systeme im Distributionslager zeigt Abb. 1.1. Darin sind zur Verdeutlichung der prinzipiellen Abl¨aufe beispielhafte Funktionen, Aktionen und Kommunikationswege dargestellt. Die einzelnen Systemhierarchien werden durch vertikale Linien verk¨orpert. Im Bereich der WWS sind in Bezug auf das Lagersystem Aufgaben der allgemeinen Bestandsoptimierung angesiedelt, das WMS u ¨ bernimmt administrative und dispositive Aufgaben der Optimierung und die Materialﬂussrechnerebene die Optimierung einzelner Abl¨ aufe. Mit der Ann¨ aherung an die physische Ebene des Materialﬂusses steigen auch die zeitlichen Anforderungen an die Umsetzung einzelner Funktionen. Auf der u ¨ berlagerten Ebene kommuniziert das WMS mit dem WWS bzw. PPS/ERP-System. Diverse Buchungen erfolgen vom WMS zum WWS, beispielsweise bestandsver¨ andernde Vorg¨ ange. Vom WWS ausgehend werden Kundenauftr¨ age in Verbindung mit den zur Durchf¨ uhrung erforderlichen Informationen (z. B. Lieferscheindaten) u ¨ bermittelt. Im Bereich der WMS sind die Grundfunktionen und einige grundlegende manuelle Materialﬂussoperationen angesiedelt. Bestimmte Steuerungsfunktionen erfolgen autark im WMS ohne R¨ uckgriﬀ auf unterlagerte Ebenen. Diese Funktionen umfassen beispielsweise manuelle Abl¨aufe. So k¨onnen nach einer Wareneingangskontrolle f¨ ur Ladeeineinheiten Label generiert werden, anhand derer ein Staplerfahrer die Ladeeinheiten und den Zielort identiﬁziert und den Transport, beispielsweise zum I-Punkt (Identiﬁkationspunkt), durchf¨ uhrt. Damit ist dieser Prozess abgeschlossen. Finden dagegen automatische oder teilautomatische Materialﬂussoperationen statt, greift das WMS auf unterlagerte Ebenen zu. Im Bereich der Kommissionierung werden die durch das WWS u ¨bermittelten Kundenauftr¨ age im WMS aufbereitet und einzelnen Zonen zugeordnet. Die Umsetzung der Entnahmeinformationen f¨ ur eine u ¨ber Pick-to-Light gesteuerte Kommissionierzone (Zuordnung der Entnahmemengen zu F¨achern und Generierung der Pickreihenfolge) erfolgt beispielsweise im WCS. Die technische Durchf¨ uhrung wiederum realisiert ein MFR, der auf die physische Ebene (Feldebene) zugreift und die Fachanzeige ansteuert. Ebenso werden einzelne Aktionen dokumentiert (Erfassung des Kommissioniervorganges) und an die jeweils u uckgemeldet, was jedoch in Abb. 1.1 nicht ex¨ berlagerten Ebenen zur¨ plizit dargestellt ist. Analog werden bei der Steuerung automatischer Gewerke Quelle-Ziel-Beziehungen eines RBG im WMS abgebildet und u ¨ber das WCS bereichsweise ausgef¨ uhrt. Die Ansteuerung einzelner Achsen eines Ger¨ates erfolgt schließlich auf der Feldebene.

1.3 Systemschnittstellen und Abgrenzung

11

Abbildung 1.1. FDS-Diagramm (Funktionen – Daten – Systeme) f¨ ur Warehouse Management

12

1. Einleitung

Wie bereits angef¨ uhrt, ist die exakte Abgrenzung der Funktionalit¨aten einzelner Systeme in der Praxis nicht eindeutig und der idealtypische Fall nicht u ¨ berall exakt umzusetzen. Eine besonders enge Vernetzung verschiedener Systeme erfordern typischerweise die Anwendungen im Bereich der E-Logistics (s. dazu S. 18). Eine beispielhafte Systemstruktur zeigt dazu Abb. 1.2. Bei der dargestellten Struktur kann es sich sowohl um eine Anwendung im Endkundenbereich (Business-to-Consumer, B2C) als auch im Gesch¨aftskundenbereich (Businessto-Business, B2B) handeln. Der Kunde kommuniziert u ¨ber das so genannte Shopsystem und kann nicht nur Produktkataloge einsehen und darauf basierend Auftr¨age erteilen, sondern auch Warenk¨ orbe anlegen und an Auktionen teilnehmen sowie aktiv Auktionen durch entsprechende Ausschreibungen durchf¨ uhren. Das Shopsystem kann durch einen unabh¨angigen Shop-Betreiber unterhalten werden. Zu den Funktionen innerhalb des Shopsystems z¨ahlt auch die Pr¨ ufung der Kunden, respektive der Kundenbonit¨at, und der Produktverf¨ ugbarkeit. Die Kataloginformationen werden durch den Lieferanten, im Idealfall f¨ ur direkte Verf¨ ugbarkeitsabfragen durch das WWS des Lieferanten, zur Verf¨ ugung gestellt. Die Rechnungsabwicklung mit dem Kunden erfolgt ebenfalls u ¨ ber das Shopsystem. Auftr¨ age werden neben einer Auftragsbest¨atigung an den Kunden an das WWS des Distributionszentrums“ (das repr¨asentiert in diesem Fall glei” chermaßen Handelsunternehmen oder Hersteller) u ¨bergeben. Zu den Aufgaben dieses WWS geh¨ oren die gesamte Auftragsverwaltung, die Steuerung des Einkaufs (Bestandspr¨ ufungen, Bestellvorschl¨ age und Bestellverwaltung), die Pﬂege der Produkt- und Kundendaten und die Erstellung von Analysen, Prognosen und Statistiken mit dem Ziel einer kontinuierlichen Optimierung der Best¨ ande und des Bestellverhaltens. Je nach Bestandssituation werden damit basierend auf der Auftragslage Bestellungen an das WWS des jeweiligen Lieferanten u ¨ bermittelt. Von diesem ausgehend werden Avise u ¨ ber Warenlieferungen an das WMS des Distributionszentrums gesendet. Dieses WMS verwaltet die Best¨ ande und Lagerorte im Distributionszentrum, setzt Kundenauftr¨ age in die erforderlichen Lager- und Kommissionieroperationen um und verwaltet ein- und ausgehende Warenstr¨ ome. Das Management ausgehender ¨ Warenstr¨ ome umfasst die Ubergabe der Lieferscheine und ggf. Rechnungsdaten an den Spediteur bzw. den KEP-Dienstleister und die Avisierung der Lieferung gegen¨ uber dem Kunden. Daneben k¨onnen Lieferungen auch vom Lieferanten direkt an den Kunden erfolgen, was insbesondere bei hochwertigen Waren und Eilauftr¨ agen realisiert wird. Das Leitsystem des Transportdienstleisters steuert unter anderem die Liefertouren und generiert ein pr¨ azisiertes Lieferavis (eine Wareneingangsank¨ undigung) an den Kunden. Ebenso geh¨ oren Aufgaben der Nachnahmeverfolgung und des Retourenmanagements zu diesen Funktionen. Erfolgt die Lieferung nicht unmittelbar an den Kunden, sondern u ¨ber eine dezentrale

1.4 Aufbau und Ziel des Buches

13

Abbildung 1.2. Grundlegende Informationsﬂ¨ usse und Systembausteine in der ELogistics

Pick-Up-Station, von der der Kunde seine Ware abholt, werden die Lieferdaten durch das Leitsystem automatisch oder durch den Auslieferer manuell der Station u ¨ bergeben. Ebenso kann eine Avisierung anstehender Lieferungen bereits durch das WMS des Distributionszentrums, das in diesem Fall den Lieferanten darstellt, erfolgen. Die Benachrichtigung u ¨ber abholbereite Sendungen erfolgt dann durch die Pickup-Station an den Kunden. Abgeschlossene Lieferungen werden schließlich dem Distributionszentrum durch das Leitsystem u ¨ bermittelt.

1.4 Aufbau und Ziel des Buches Nachdem der Begriﬀ WMS im vorangegangenen Kapitel deﬁniert und im Kontext eingeordnet wurde, f¨ uhrt das folgende Kapitel 2 in das Management von Lager- und Distributionssystemen ein und zeigt dazu die Abl¨aufe aus Sicht des Materialﬂusses auf, d.h. ein Lagersystem wird anhand der typischen Materialﬂ¨ usse und Abl¨ aufe beschrieben. Das Augenmerk liegt dabei

14

1. Einleitung

auf der detaillierten und strukturierten Darstellung der Abl¨aufe, Anforderungen und Strategien in Lager- und Distributionssystemen. Außerdem werden die wesentlichen Prinzipien der Kommissionierung dargelegt sowie einige besondere Abl¨ aufe beschrieben. Gleichzeitig werden die Anforderungen, die an ein Lagerverwaltungssystem gestellt werden, deﬁniert. Die Umsetzung dieser Anforderungen in die technische Struktur eines Warehouse Managementsystems, d.h. die Realisierung der Aufgaben der Lagerverwaltung und -steuerung in einem WMS, werden dargestellt. ¨ Das Kapitel 3 gibt einen Uberblick u ¨ ber die maschinenbaulichen Komponenten der Lager-, F¨ order-, Sortier- und Verteiltechniken. Die Darstellung der Techniken erfolgt fokussiert auf das Thema Lager- und Distributionssystem und nur soweit sie f¨ ur die vorliegende Betrachtung relevant sind. Das Kapitel 4 f¨ uhrt in die Verfahren zur Optimierung des Lagerbetriebs ein und behandelt Fragen des Scheduling und Dispatching. Hier stehen Fragen der Optimierung der Auftragsdisposition im Vordergrund. Die generellen Prinzipien der Informationsverarbeitung und Kommunikation in Netzwerken werden im Kapitel 5 behandelt. Dazu z¨ahlen die Grundlagen der Betriebssysteme, der Kommunikation in Netzen und die wichtigen Fragen der Datensicherheit. Im Anschluss daran werden in Kapitel 6 Softwarearchitekturen sowie Grundlagen und Methoden zur Erstellung moderner Softwaresysteme vorgestellt. Mit der dann folgenden beispielhaften Beschreibung von Datenmodellen, wie sie f¨ ur Lagersteuerung und -verwaltung genutzt werden, wird dem Leser gleichzeitig ein Warehouse Managementsystem vorgestellt, welches alle elementaren Bestandteile eines Lager- und Distributionssystems mit automatisierter F¨ ordertechnik und manueller Kommissionierung umfasst (myWMS). Die vielf¨ altigen Aspekte der Auswahl und Einf¨ uhrung eines Warehouse Managementsystems von der Anforderungserstellung bis zur Inbetriebnahme und dem weiteren Betrieb des Systems werden in Kapitel 8 behandelt. Der Anhang enth¨ alt die Kurzvorstellung der f¨ uhrenden Software Plattformen, die im Umfeld von Warehouse Managementsystemen eingesetzt werden.

2. Lagersysteme und Lagerverwaltung

Lager- und Distributionssysteme sind auf ein spezielles Anforderungsproﬁl zurechtgeschnittene L¨ osungen, die sich entsprechend der Vielfalt der technischen und organisatorischen Gestaltungsmerkmale mehr oder weniger stark unterscheiden. Dennoch sind die grundlegenden ablauftechnischen Prozesse zwangsl¨ auﬁg ¨ ahnlich, da diese Systeme wiederum Teil einer u ¨ bergreifenden Kette des Warenﬂusses sind. Mit dem Ziel der Schaﬀung einer einheitlichen Basis werden im Folgenden die wesentlichen Randbedingungen, Grundlagen und Abl¨ aufe herausgearbeitet. Ein eﬃzientes Lagermanagement setzt die Ber¨ ucksichtigung dieser Rahmenbedingungen und der logistischen Einheiten voraus, um Abl¨aufe gezielt optimieren zu k¨ onnen. Diese sollen zun¨ achst n¨ aher beleuchtet werden. Nachfolgend werden die grunds¨ atzlichen Abl¨ aufe in einem Lager beschrieben und die f¨ ur einen eﬃzienten Betrieb entscheidenden Funktionen identiﬁziert. Im Hinblick auf den besonderen Stellenwert der Kommissionierung als personalintensives und zeitkritisches Glied in der innerbetrieblichen Ablaufkette werden deren relevante Abl¨ aufe genauer betrachtet. Abschließend werden die typischen Daten und Kennzahlen der Systeme sowie elementare Funktionen eines WMS eingef¨ uhrt.

2.1 Logistische Rahmenbedingungen 2.1.1 Logistik-Grunds¨ atze

Der Begriﬀ Logistik Die Logistik beschreibt einen systemischen Ansatz zur umfassenden Optimierung von Fließsystemen, dazu z¨ ahlen insbesondere Materialﬂusssysteme, u ¨ ber einzelne Systemgrenzen hinaus. Es existieren je nach Ausrichtung verschiedenste Deﬁnitionen der Logistik, auf die hier aber nicht n¨aher eingegangen werden soll, da sie nicht im Hauptaugenmerk der Betrachtungen liegen. Der Kern einer Reihe von Deﬁnitionen reduziert sich auf die Rolle der Logistik als Forschung und Lehre der Planung, Organisation und Kontrolle solcher Fließsysteme (vgl. u. a. [18, 24, 29, 41, 58]).

16

2. Lagersysteme und Lagerverwaltung

Entsprechend dem materialﬂussbezogenen Fokus dieser Arbeit sollen die so genannten 6R’s“ der Logistik1 hervorgehoben werden. Die 6R’s“ der ” ” Logistik beschreiben eines der Ziele der Logistik als die Lieferung der • • • • • •

richtigen richtigen richtigen richtigen richtigen richtigen

Ware, zum Zeitpunkt, in der Zusammensetzung und der Qualit¨ at, am Ort zum Preis.

Trotz der starken Simpliﬁzierung besitzt dieser Leitsatz große Verbreitung. Richtig ist dabei als eine seitens des Kunden erwartete Eigenschaft im Sinne von bestellt, gefordert, erwartet und zu minimalen Kosten zu verstehen. Koordination (Gleichlauf ) von Materialﬂuss und Informationsﬂuss Eine weitere etablierte und relevante Erkenntnis ist, dass sich die logistische Leistung eines Systems im Sinne der Erbringung eines optimalen Lieferservice zu minimalen Kosten nur dann erreichen l¨ asst, wenn Materialﬂuss und Informationsﬂuss aufeinander abgestimmt werden. In vielen F¨allen bedeutet dies auch, einen dem physischen Materialﬂuss vorauseilenden Informationsﬂuss zu schaﬀen, der z. B. die Bereithaltung entsprechender Kapazit¨aten an F¨order-, Lager- oder Handhabungsmitteln erm¨ oglicht. In diesem Kapitel werden kontinuierlich die Bedeutung und die Umsetzung dieses Paradigmas verdeutlicht. Supply Chain Management (SCM) Wie bereits aufgezeigt, ergibt sich im heutigen G¨ uter- und Warenﬂuss eine Reihe von Faktoren, die zu mehrstuﬁgen Schritten bzw. Teilsystemen, einer Versorgungskette oder Supply Chain, f¨ uhrt. Im klassischen Fall, bei dem jedes Element autark ist und jeweils nur das Verhalten seines Kunden (in Form von Bestellungen) und seiner Lieferanten (in Form von Lieferzeiten) wahrnimmt, f¨ uhren minimale Schwankungen im Bestellverhalten am Ende der Supply Chain zu massiven Schwankungen im Bestellverhalten (und damit den Systembest¨ anden) am Anfang der Kette. Dieses Ph¨anomen, auch als Bullwhip- oder Peitscheneﬀekt bekannt, wurde Ende 1950 von Forrester beschrieben, und erst heute, mit der Verf¨ ugbarkeit leistungsf¨ahiger Rechenund Kommunikationssysteme, entstehen aussichtsreiche Ans¨atze zur Beherrschung dieser komplexen Zusammenh¨ ange. Der Schl¨ ussel liegt in der Informationsverarbeitung und -bereitstellung wichtiger Systeminformationen an

1

verschiedentlich bei entsprechender Komprimierung der Inhalte auch als 4R’s bezeichnet

2.1 Logistische Rahmenbedingungen

17

beliebigen Punkten der Supply Chain. Bekannte Strategien in diesem Umfeld sind ECR2 und CPFR3 . Auch wenn das Supply Chain Management und die Methoden und Werkzeuge zur Optimierung dieser Ketten nicht im Fokus dieser Arbeit liegen, ist die Relevanz der Informationserfassung, -aufbereitung und -verarbeitung entlang der Supply Chain ein ganz entscheidender Faktor, der auch den Betrieb von Lagersystemen betriﬀt. Outsourcing In den letzten Jahren l¨ asst sich aus verschiedenen Gr¨ unden eine eindeutige Tendenz zur externen Vergabe von innerbetrieblichen Dienstleistungen im Bereich der Logistik erfassen, was allgemein als Outsourcing bezeichnet wird. H¨ auﬁg angef¨ uhrte Gr¨ unde sind dabei die folgenden: • Konzentration der betrieblichen Bem¨ uhungen auf die eigentlichen Kernkompetenzen, z. B. Entwicklung und Fertigung von G¨ utern, und Freisetzen von Managementkapazit¨ aten; • Reduktion der Logistikkosten durch Nutzung von Gr¨oßendegressionseffekten (Economies-of-scale-Eﬀekte) und bessere Systemauslastung auf Seiten des Kontraktlogistikers; • Abfedern saisonaler Arbeitsspitzen oder Schwankungen, welche die Vorhaltung entsprechender eigener Kapazit¨ aten nicht rechtfertigen; • Steigerung des Lieferservice durch Erh¨ ohung der Kundenpr¨asenz oder durch Verk¨ urzung von Lieferzeiten. Viele Kontraktlogistiker besitzen eine solche Pr¨ asenz per se, ein Aufbau aus eigenen Kr¨aften l¨asst sich dagegen wirtschaftlich oftmals nicht darstellen. Als Beispiel sei der Aufbau einer EDI-L¨ osung mit sicherer Kundenanbindung zur Erstellung geforderter Lieferavise genannt; • Nutzung tariﬂicher Rahmenbedingungen; • Zukauf/Aufbau logistischer Kompetenz. Es existieren verschiedenste Formen des Outsourcing. So kann ein Kontraktlogistiker den Betrieb eines vorhandenen Lagersystems u ¨ bernehmen und fortf¨ uhren. In anderen F¨ allen werden Warenbest¨ande in ein externes Lager des Kontraktlogistikers u uhrt, wo sie nun neben Best¨anden anderer Fir¨ berf¨ men gef¨ uhrt werden (Multi-Mandantensystem, auch Shared Warehouse). In jedem Fall erwachsen daraus neue Anforderungen an den Betrieb solcher outgesourcter L¨ ager. Da die Verg¨ utung der Leistung oftmals nach durchgef¨ uhrten Transaktionen erfolgt, ist die Leistungsmessung und Transparenz 2 3

Eﬃcient Consumer Response wird als direkte R¨ uckmeldung eines Kundenbedarfs an das bestandsf¨ uhrende System (Lieferant) verstanden. Collaborative Planning, Forecasting and Replenishment propagiert die Vernetzung aller Beteiligten einer Supply Chain, um Bestellanforderungen und Lieferengp¨ asse fr¨ uhzeitig abzugleichen.

18

2. Lagersysteme und Lagerverwaltung

der Aktivit¨ aten eine elementare Voraussetzung f¨ ur den Betrieb, um den Kunden die Prozesse nachvollziehbar pr¨ asentieren zu k¨onnen. Weitaus anspruchsvoller gestalten sich L¨ osungen mit verschiedenen Kunden in einem System. Hier sind scheinbar gleichwertige Waren v¨ollig unterschiedlichen Prozessen zu unterziehen, beispielsweise im Bereich der Inventur. Und letztlich werden solche Vertr¨ age typischerweise f¨ ur relativ kurze Dauer geschlossen, was f¨ ur den Betreiber (Kontraktlogistiker) ein betr¨achtliches Risiko darstellt; ein Umstand, der gegebenenfalls die Errichtung hochspezialisierter Gewerke zu einem nicht kalkulierbaren Risiko macht. Nicht zuletzt resultiert daraus eine Vielzahl von Anforderungen an das Warehouse Management und die eingesetzten Warehouse Managementsysteme. Diese m¨ ussen je nach Einsatzfall hochtransparent, allgemein einsetzbar und den unterschiedlichsten Anforderungen gen¨ ugend ausgef¨ uhrt werden. Wenig verwunderlich ist daher, dass große Kontraktlogistiker heute typischerweise u ¨ber erhebliche personelle Ressourcen im Bereich der Informationslogistik verf¨ ugen. In den folgenden inhaltlichen Ausf¨ uhrungen sollen diese Anforderungen ausgiebig Ber¨ ucksichtigung ﬁnden. E-Logistics Ein Bereich, der in den letzten Jahren zunehmend an Bedeutung gewinnt, ist die E-Logistics. Sie l¨ asst sich deﬁnieren als ein ¨ Uberbegriﬀ f¨ ur die Planung, Steuerung und Kontrolle des Waren-, Informations- und Geldﬂusses entlang der gesamten Supply Chain u oﬀentliche und private Netze (Internet, Intranets), d. h. vom ¨ ber ¨ Front-End u ¨ ber die Kunden-Online-Bestellung (Business-to-Consumer (B2C), Business-to-Business (B2B)) bis zur Sendungsverfolgung und zum Kundenservice [58]. Die E-Logistics wird somit als verbindendes Element industriellen Handelns im Internet-Zeitalter verstanden. Die Erfahrungen zeigen gerade auf diesem Gebiet, dass eine leistungsf¨ ahige Logistik und schnelle Materialﬂusssysteme u ¨ ber Erfolg oder Misserfolg entscheiden. Die einseitige Fokussierung auf den Verkaufskanal und die Vernachl¨ assigung der Erf¨ ullung der Kundenauftr¨ age (das so genannte Fulﬁllment) haben den Niedergang etlicher ECommerce-Firmen zur Jahrtausendwende zumindest beschleunigt. Es zeigt sich aber auch, dass klassische Distributionssysteme den Anforderungen der E-Logistics h¨ auﬁg nur ungen¨ ugend gerecht werden. Der Schl¨ ussel liegt in der hochﬂexiblen und schnellen Abarbeitung kleiner, aber zahlreicher Kundenauftr¨ age bei dynamisch schwankenden Auftrags- und Sortimentsstrukturen. KEP-Dienste und E-Commerce Seit Jahren besitzt die KEP-Branche (Kurier-, Express-, Paketdienstleister) ein dynamisches Wachstum. Dieser Erfolg ist eng mit dem bereits diskutier-

2.1 Logistische Rahmenbedingungen

19

ten Bestellverhalten der Kunden und mit der geforderten Reaktionsgeschwindigkeit der Unternehmen verkn¨ upft. Insbesondere vor dem Hintergrund der zuk¨ unftigen Entwicklung im E-Commerce-Bereich wird der Branche auch f¨ ur die n¨ achsten Jahre weiteres Wachstum vorausgesagt [7]. ¨ Diese Anderungen im Versandverhalten wirken sich ebenso nachhaltig auf die Prozesse in den Distributionszentren aus. Eine zunehmende Vielfalt kleiner Sendungen muss unter hohen zeitlichen Anforderungen fertiggestellt, erfasst und verbucht werden. Dieses l¨ asst sich eﬃzient nur durch konsequenten Einsatz geeigneter Leit- und Dokumentationssysteme erreichen. 2.1.2 Verpackung und Logistische Einheiten ¨ Ein umfassender Uberblick setzt die Kenntnis der typischen Einheiten voraus, die in diesen Prozessen im weiteren Sinne transformiert werden. Nach [24] stellt ein solcher Transformationsprozess eine Ver¨anderung des Systemzustandes von G¨ utern hinsichtlich Zeit, Ort, Menge, Zusammensetzung oder Qualit¨ at dar. Die Einheiten kommen je nach punktueller Anforderung seitens der relevanten Teilsysteme und Betriebsmittel sowie der kundenseitigen Anforderungen in st¨ andig wechselnder Form und Zusammensetzung in den Lagersystemen vor. Gleichzeitig haben sich verschiedene Bezeichnungen etabliert, die spezielle Verwendung in logistischen Systemen ﬁnden (aber nicht immer stringent genutzt werden). Jede Betrachtung von Materialﬂ¨ ussen setzt daher zwangsl¨auﬁg bei den Mengen und Eigenschaften der Waren und G¨ uter an. Die Akteure oder Entscheider an den Endstellen solcher Materialﬂ¨ usse stellen dabei grundverschiedene Anforderungen insbesondere an die Zusammensetzung dieser Einheiten. Am Beginn der Prozesskette sind die Produzenten oder Hersteller bestrebt, G¨ uter in wirtschaftlichen Mengen (Losgr¨oßen) zu produzieren und sie m¨ oglichst eﬃzient, das bedeutet im Allgemeinen in einer m¨oglichst geringen Anzahl an Arbeitsschritten, zum n¨ achsten Abnehmer der G¨ uter zu transportieren. Ein wichtiger Aspekt ist in diesem Zusammenhang auch die Konsolidierung der Warenﬂ¨ usse und Prozesse. Die Logistik- und Materialﬂusssysteme von Produzenten sind in der Regel auf die eﬃziente Handhabung großer Mengen weniger Artikel ausgerichtet. Daher werden u ¨ ber den mehrstuﬁgen Handel die hier erforderlichen Gr¨ oßeneﬀekte (Economies of scale) realisiert. Erst seitdem u ¨ ber den E-Commerce unter Umgehung klassischer Handelsstrukturen eine unmittelbare Pr¨ asenz jedes Produzenten gegen¨ uber Endkunden realisiert werden konnte, begannen sich diese Strukturen zu bewegen. Verpackung ussen steht die Notwendigkeit, produAm Anfang von G¨ uter- und Warenﬂ¨ uter vor den Einﬂ¨ ussen w¨ zierte G¨ ahrend der Transport-, Umschlag- und Lagerprozesse (TUL-Prozesse) so zu sch¨ utzen, dass keine qualitative Beein-

20

2. Lagersysteme und Lagerverwaltung

tr¨ achtigung auftritt. Diese Zielsetzungen werden im Wesentlichen durch Auswahl einer geeigneten Verpackung einerseits und durch Bildung so genannter Ladeeinheiten andererseits zu erreichen versucht. Neben der Hauptfunktion, das Gut w¨ ahrend der TUL-Prozesse zu sch¨ utzen, erf¨ ullt eine Verpackung aber auch eine Reihe weiterer Anforderungen. So soll die Verpackung in bestimmten F¨allen, z. B. bei Gefahrg¨ utern, nat¨ urlich auch die Umwelt und speziell die beteiligten Mitarbeiter vor dem Gut sch¨ utzen. Um eine eﬃziente Handhabung w¨ahrend dieser Prozesse zu erm¨ oglichen, soll eine Verpackung Lager- und Transportvorg¨ange vereinfachen, beispielsweise durch Schaﬀung einheitlicher, stapelbarer oder f¨orderf¨ahiger Einheiten. Insbesondere im Bereich des Einzelhandels soll die Verpackung eine verkaufsf¨ ordernde Wirkung erzielen. Dem Kunden bzw. Verbraucher soll sie ggf. eine Verwendungsfunktion oﬀerieren, beispielsweise durch mehrfache Verschließbarkeit oder sogar durch eine einsatzfremde Benutzung nach Verbrauch der eigentlichen Ware. Schließlich spielt die Identiﬁkations- und Informationsfunktion eine Schl¨ usselrolle sowohl bei der Identiﬁkation der Ware innerhalb des Materialﬂusses (beispielsweise durch aufgedruckte Barcodes) als auch bei Oﬀerierung der Waren in den Verkaufsregalen. Diese Vielzahl von Anforderungen, die zu teilweise gegenl¨auﬁgen Zielsetzungen f¨ uhrt, l¨ asst sich im Allgemeinen nicht durch eine einzelne Verpackung erf¨ ullen, sondern nur durch ein abgestimmtes Verpackungssystem [24]. Daher haben sich auch unterschiedliche Verpackungen f¨ ur die verschiedenen Abschnitte entlang der Transportkette etabliert. Auch im Hinblick auf die anfallenden Verpackungsabf¨ alle werden unterschiedliche Verpackungstypen diﬀerenziert: Transportverpackungen: sch¨ utzen Waren w¨ahrend des Transports zwischen Hersteller und Vertreiber; Verkaufsverpackungen: werden vom Endverbraucher zum Transport oder bis zum Verbrauch der Waren verwendet; Umverpackungen: sind zus¨ atzliche Verpackungen um Verkaufsverpackungen, die unter anderem die Abgabe von Waren im Wege der Selbstbedienung erm¨ oglichen, dem Diebstahlschutz oder der Werbung dienen. Diese Verpackungstypen erfahren im Rahmen der Verpackungsverordnung besondere Bedeutung, die den Handel und Erzeuger zu einer R¨ ucknahmeverpﬂichtung der Altverpackungen vom Kunden verpﬂichtet. F¨ ur eine vertiefende Betrachtung der Verpackungstechnik bzw. -problematik sei auf [10, 24, 32] verwiesen. Logistische Einheiten Obwohl ein verpacktes Gut eine Einheit in einem beliebigen logistischen System darstellt, ist es nicht zwangsl¨ auﬁg mit einer Logistischen Einheit gleichzusetzen. Die Bildung solcher Einheiten hat das u ¨bergeordnete Ziel, einzelne G¨ uter in geeigneter Weise derart zusammenzuf¨ ugen, dass die T¨atigkeiten in-

2.1 Logistische Rahmenbedingungen

21

Tabelle 2.1. Ziele der Einheitenbildung Zielsetzung

Beispiele

Vereinfachung und Kostensenkung

Reduktion von Umschlagvorgängen unnötige Identifizierungsvorgänge vermeiden Prüf-, Mess- und Zählvorgänge minimieren

Vereinheitlichung

Anpassung zur Adaption technischer Geräte einheitliche Schnittstellen zur Gutaufnahme Standardmaße zum Einsatz universeller Geräte

Austauschbarkeit

Poolbetrieb ermöglichen 1:1-Tausch identischer Ladehilfsmittel

Funktionalität

Stapelbarkeit erhöhen Zugriff ermöglichen

nerhalb der logistischen Aufgabenerf¨ ullung optimiert erbracht werden k¨onnen. G¨angige Zielsetzungen, die zur Bildung Logistischer Einheiten f¨ uhren, sind in Tabelle 2.1 aufgef¨ uhrt. In der Idealvorstellung wird nur eine Logistische Einheit gew¨ahlt bzw. geformt, die unver¨ andert die gesamte Transportkette durchl¨auft, d. h. gleichzeitig Lager-, Transport-, Versand- und Ladeeinheit ist. Wie aber bereits eingehend ausgef¨ uhrt, l¨ asst sich diese Zielsetzung aufgrund einer Reihe unterschiedlicher Anspr¨ uche in den seltensten F¨allen wirklich umsetzen. Insbesondere in mehrstuﬁgen Versorgungsketten besteht die Tendenz zu immer kleineren Einheiten (s. dazu auch Kapitel 1, S. 3). Die Ladeeinheitenbildung beschreibt das eﬃziente Zusammenfassen von G¨ utern zu gr¨ oßeren, einzeln handhabbaren Einheiten. Dabei kommen entsprechende Ladehilfsmittel zum Einsatz. Die Ladehilfsmittel werden anhand ihrer Form und/oder Funktion u ¨blicherweise in • tragende Ladehilfsmittel, auf die das Gut gestellt oder gestapelt wird, • umschließende Ladehilfsmittel, die das Gut aufnehmen und seitlich st¨ utzen, und • abschließende Ladehilfsmittel, die das Gut allseitig umfassen, unterschieden. F¨ ur den verbesserten Produkt- und Transportschutz werden Ladeeinheiten zus¨ atzlich durch Ladeeinheitensicherungsmittel gesch¨ utzt (s. [74]). Die g¨ angigsten Verfahren sind hier das Schrumpfen, das Stretchen und das Umreifen (s. [24]).

22

2. Lagersysteme und Lagerverwaltung

Abbildung 2.1. Wechsel der Artikelmengen und Liefereinheiten entlang einer exemplarischen Transportkette

Aus materialﬂusstechnischer Sicht ist besonders der Wechsel zwischen den unterschiedlichen Zusammensetzungen bzw. Zusammenstellungen von Verpackungen und Ladeeinheiten von Interesse. Diesen Zusammenhang verdeutlicht Abb. 2.1. Die besonderen Anforderungen im Bereich der Kommissionierung (vgl. Abschn. 2.2.5) erfordern eine weitere Diﬀerenzierung der Einheiten:

2.2 Funktionen in Lagersystemen

23

• Lagereinheiten stellen die Einheiten dar, in denen ein Artikel im Lager bevorratet wird (z. B. Palette; auch: Nachschubeinheiten). • Bereitstelleinheiten werden die Einheiten genannt, die zur Entnahme angeboten werden (z. B. Schachteln oder Beh¨alter). • Entnahmeeinheiten sind die Einheiten eines bestimmten Artikels, die durch den Kommissionierer beim Kommissioniervorgang gegebenenfalls durch mehrere Einzelzugriﬀe entnommen werden (z. B. Gebinde). • Greifeinheiten (auch Pickeinheiten) umfassen diejenige Menge an Artikelbzw. Verpackungseinheiten, die ein Kommissionierer im Mittel mit einem Griﬀ aus dem Kommissionierregal entnimmt. • Sammeleinheiten, auch Kommissioniereinheiten genannt, entstehen durch die Bearbeitung der einzelnen Positionen einer Pickliste durch den Kommissionierer. Sie enthalten jeweils eine oder mehrere Greif- und Entnahmeeinheiten. • Versandeinheiten repr¨ asentieren die Menge der Artikel in der entsprechenden St¨ uckzahl, die der Kunde durch seinen Auftrag angefordert hat. Die einzelne Versandeinheit wird h¨ auﬁg mittels eines Ladehilfsmittels (Palette, Gitterbox etc.) gebildet.

2.2 Funktionen in Lagersystemen So unterschiedlich die Anforderungen an ein Distributionszentrum und so vielf¨ altig die Realisierungsm¨ oglichkeiten der Prozesse, der technischen Systemgestaltung und der Kontrollfunktionen der Leitungsebene auch sind, es existieren bestimmte Standardabl¨ aufe, die in jedem gr¨oßeren System etabliert sind. Dies ist auch unvermeidlich, da jedes Distributionszentrum letztlich ein Glied in einer u ¨ bergeordneten Versorgungskette bzw. Supply Chain ist. Diese typischen grundlegenden Abl¨ aufe werden im Folgenden dargestellt. 2.2.1 Warenannahme und -eingang Ausgehend von der Warenbestellung durch einen Disponenten beginnt der Materialﬂuss f¨ ur das empfangende Unternehmen mit der Ank¨ undigung der Lieferung durch den Hersteller bzw. Lieferanten. Avisierung von Wareneingang und Liefertermin Je nach Liefersituation wurde ein pr¨ aziser Liefertermin vereinbart. Dies ist insbesondere dort erforderlich, wo bei einer hohen Zahl an Warenanlieferungen nur eine begrenzte Kapazit¨ at zur Warenannahme zur Verf¨ ugung steht. Durch eine solche Terminierung sollen auf Seiten des Transporteurs Wartezeiten der Lkw vermieden bzw. reduziert werden und auf Empf¨ angerseite, respektive Verladerseite, die Systemlasten harmonisiert und ausgepr¨ agte Lastspitzen vermieden werden.

24

2. Lagersysteme und Lagerverwaltung

Abbildung 2.2. Grundelemente von Warehouse Managementsystemen und deren Bezug zu den Funktionen im Lager

Diese aus Sicht des Materialﬂusses erstrebenswerte Realisierung h¨angt wiederum von vielen Einﬂussgr¨ oßen wie beispielsweise Sendungsgr¨oße und -wert, der Lieferdistanz und allgemeinen Verkehrssituation, beh¨ordlichen Arbeitszeiten (z. B. Zollabfertigung) und nat¨ urlich der Position des empfangenden Unternehmen ab und l¨ asst sich in der idealtypischen Form nur eingeschr¨ankt realisieren. Warenannahme Die Warenannahme ist der erste wichtige Schritt im Materialﬂuss eines Lagers mit der Entlastung des Spediteurs. Basierend auf dem Lieferavis l¨ asst sich die eintreﬀende Lieferung mit der Bestellung abgleichen.

2.2 Funktionen in Lagersystemen

25

Dabei erfolgt eine Buchung des Frachtbriefes gegen das Avis. Es schließt sich ¨ die vorl¨ auﬁge Ubernahme der Avis-Informationen in das bestandsf¨ uhrende System (Einbuchung unter Vorbehalt) an. Dieser Schritt beschleunigt den Prozess des Wareneingangs erheblich, da bei nachfolgender positiver Pr¨ ufung die Daten lediglich best¨ atigt werden m¨ ussen. W¨ ahrend in kleinen Lagersystemen Warenannahme und Wareneingang physisch zusammenliegen k¨ onnen, fallen in gr¨oßeren Systemen aufgrund der r¨ aumlichen Trennung Aufgaben der Verkehrs- und Zielf¨ uhrung der ankommenden Lkw zu den Verladetoren an. Die r¨ aumliche Trennung erfolgt dabei h¨ auﬁg mit dem Ziel einer besseren Kontrolle der Hofverkehre. Zu diesem Zweck werden Hofmanagementsysteme (auch Stock- and Yardmanagementsysteme) eingesetzt, die einen koordinierten Verkehrsﬂuss auf dem Werksgel¨ ande und insbesondere die Minimierung unn¨otiger Such- und Rangierfahrten gew¨ ahrleisten sollen. Wareneingang Durch Nutzung der Avis-Informationen kann auch der Wareneingang bereits auf die eingehende Lieferung vorbereitet werden, was insbesondere bei gr¨ oßeren Liefermengen (in Bezug auf das vereinnahmende System gesehen) vorteilhaft ist. Dazu geh¨ ort beispielsweise die Planung und Reservierung korrespondierender Puﬀerﬂ¨ achen, die Auswahl geeigneter Annahmestellen (z. B. Ladetore oder -buchten) oder der Ausdruck der ﬁrmeninternen Label zur innerbetrieblichen Identiﬁkation der G¨ uter. Aus materialﬂusstechnischer Sicht ist der Einsatz eines betriebs¨ ubergreifenden Kennzeichnungssystems anzustreben, wie es ¨ahnlich bereits im Handel (EAN128) oder in der Automobilbranche (Odette) vermehrt zum Einsatz gelangt, jedoch im Lager noch keine standort¨ ubergreifende Verbreitung gefunden hat. Dies ist u. a. darauf zur¨ uckzuf¨ uhren, dass zur Steuerung des Materialﬂusses andere Anforderungen an Kennzeichnungs- oder Identsysteme gestellt werden als z. B. im Handel. Wareneingangspr¨ ufung Neben dem logischen Abgleich von bestellter und ¨ eingehender Ware erfolgt die physische Uberpr¨ ufung der eingetroﬀenen Ware. Dazu geh¨ ort in der Regel f¨ ur alle G¨ uter die Pr¨ ufung auf Art und Menur bestimmte ge, welche im Allgemeinen das Entladepersonal durchf¨ uhrt. F¨ G¨ uter erfolgt entsprechend den ﬁrmeninternen Regelungen eine eingehende Pr¨ ufung der Beschaﬀenheit der Artikel durch die Qualit¨atssicherung. Diese Pr¨ ufungen reichen vom Sichtvergleich bis zu Laborpr¨ ufungen einzelner Stichproben oder vollst¨ andigen 100%-Kontrollen. M¨angelbehaftete Ware wird danach mit Sperrkennzeichen versehen und in spezielle Bereiche verbracht oder unter Ber¨ ucksichtigung der Sperrmerkmale (s. Abschn. 2.3.1, S. 55) eingelagert. Bei neuen Artikeln ist unter Umst¨ anden noch eine Vervollst¨andigung der Artikelstammdaten (vgl. Tabelle 2.13) erforderlich. Eine sorgf¨altige Erstellung und Pﬂege dieser Stammdaten ist die wesentliche Voraussetzung f¨ ur

26

2. Lagersysteme und Lagerverwaltung

eine Reihe von Kontroll- und Optimierungsfunktionen im weiteren Materialﬂussprozess. Die Kenntnis des exakten Gutgewichtes ist erforderlich f¨ ur Pr¨ ufprozesse im Rahmen der Kommissionierung. So k¨onnen Kundenauftr¨age auf Vollst¨ andigkeit gepr¨ uft werden. Spezielle automatische Ger¨ate wie Kommissionierroboter ben¨ otigen diese Informationen teilweise zur Veriﬁzierung des erfolgreichen Greifvorganges. Daher werden alle neuen oder im System noch unbekannten Artikel idealerweise bei der Wareneingangspr¨ ufung oder Vereinzelung verwogen. Die Summe der Einzelgewichte eines Auftrags kann anschließend z. B. auch zur Kommissionierkontrolle verwendet werden. Ebenso sind die Gutabmessungen von entscheidender Bedeutung bei der Optimierung der Volumennutzung entlang des Materialﬂussprozesses. Lagerf¨ acher eines Regallagers k¨ onnen mit unterschiedlichen Lagerfachh¨ohen auf das Artikel- bzw. Lagergutspektrum angepasst werden, wodurch die Raumnutzung des Lagerbereiches optimiert werden kann. Entsprechend der Gr¨oße eines Kommissionierauftrags k¨ onnen des Weiteren optimale Versandbeh¨alter vorausberechnet werden. Dadurch lassen sich letztlich Versandkosten minimieren. Bei der Ermittlung der Artikelabmessungen kommen unterschiedliche Verfahren zum Einsatz. Neben dem exakten Vermessen bzw. der Aufnahme der exakten Artikelabmessungen in das Lagerverwaltungssystem reicht verschiedenen Anwendern auch die u agige Gruppierung in bestimmte ¨ berschl¨ Gr¨ oßenklassen. Ein solches Verfahren ist dann sinnvoll, wenn die Gr¨oßenerfassung manuell durchgef¨ uhrt wird. Dazu werden oftmals Messlehren eingesetzt, die entsprechend den gew¨ ahlten Gr¨ oßenklassen Markierungen aufweisen. Der Bediener kann so die Gr¨ oßenklasse sehr leicht ablesen. Daneben existieren auch automatische Abmessungserfassungsger¨ate, welche die Artikel abtasten und die erfassten Abmessungen direkt an das Lagerverwaltungssystem u ¨bertragen (s. Abb. 2.3). Schließlich werden weitere kennzeichnende Gr¨ oßen oder Besonderheiten (z. B. Gefahrgutkennzeichen etc.) der Artikel aufgenommen, soweit sie in der Artikelstammdatei noch nicht vorliegen. Zur Sicherung hochwertiger G¨ uter ist eventuell die Aufnahme von Seriennummern erforderlich. Die durchgehende Kontrolle und Nachvollziehbarkeit erfordert hierbei eine u ¨ ber die Warenbeschreibung hinausgehende Funktionalit¨ at, da nicht der Artikel, sondern die spezielle Ladeeinheit des Artikels und deren Bewegung im Lager dokumentiert werden muss. Dar¨ uber hinaus muss gegebenenfalls f¨ ur eine Zeitspanne nach Durchlauf der Einheit die Information verf¨ ugbar bleiben. Das Gleiche gilt sinngem¨aß f¨ ur die Verfolgung von Produktionschargen. ¨ Um eine Uberalterung von Ware mit begrenzter Lebensdauer (verderbliche Ware) auszuschließen, ist gegebenenfalls das Verfallsdatum zu erfassen bzw. die Restlaufzeit zu bestimmen. Anhand dieser Parameter k¨onnen Auslagerpriorit¨ aten bestimmt oder Umlagerungen veranlasst werden.

2.2 Funktionen in Lagersystemen

27

Abbildung 2.3. Verfahren zur Erfassung der Abmessungen (in Anlehnung an [35])

Bildung der Lagereinheiten In vielen Lager- und Materialﬂusssystemen sind aus Gr¨ unden der Transportsicherheit oder Handhabung spezielle Ladehilfsmittel oder Beh¨ alter im Einsatz. Hierzu z¨ahlen Tablarsysteme oder Regalsysteme mit genormten Beh¨ altergr¨ oßen, die ein spezielles Ladehilfsmittel erfordern. Eingehende G¨ uter sind dagegen mit der Zielsetzung der Versandkosten- und Transportkostenminimierung zu volumen- und mengenoptimierten Einheiten zusammengefasst. Deshalb ist in solchen F¨allen eine Anpassung an das ﬁrmeninterne Materialﬂusssystem durch Umf¨ ullen in ﬁrmeninterne Beh¨ alter und verbrauchskonforme Einheiten erforderlich. Dasselbe gilt f¨ ur Einheiten auf der Basis von Standardpaletten (z. B. Euro- oder Industriepalette). Oftmals ist die Qualit¨ at angelieferter Einheiten im Hinblick auf nachgeschaltete automatische Systeme wie Hochregallager bedenklich. So k¨onnen beispielsweise besch¨ adigte Paletten Toleranzmaße u ¨berschreiten und dadurch auf bestimmten F¨ orderabschnitten stecken bleiben. Deshalb werden solche Einheiten z. T. auf ﬁrmenspeziﬁsche Lagereinheiten (hochwertige Standardpaletten ohne Besch¨ adigungen) umgesetzt. Dabei wird oft ein schlechterer Lagerraumnutzungsgrad in Kauf genommen und die komplette Ladeeinheit auf eine ﬁrmeninterne Palette gesetzt. Dieser Schritt erm¨oglicht gleichzeitig die Nutzung dauerhafter Kennzeichnungselemente an den Paletten zur Mate-

28

2. Lagersysteme und Lagerverwaltung

rialﬂusssteuerung. Werden automatische Lagertechniken mit sehr hohen dynamischen Bewegungsanteilen eingesetzt, kann eine zus¨atzliche Sicherung der eingehenden Ladeeinheiten notwendig werden. Ist das resultierende Volumen der einzulagernden Menge wesentlich kleiner als das verf¨ ugbare minimale Lagerplatzvolumen (beispielsweise des Regalfaches eines Regallagers), ist die Bildung von Mischpaletten ein g¨angiges Verfahren zur Verbesserung des Lagernutzungsgrades. Diese Maßnahme ist von besonderer Bedeutung f¨ ur das steuernde Lagerverwaltungssystem. Ein Problem ist dabei nicht nur die Zulagerung von Artikeln mit stark unterschiedlichen Eigenschaften, die eine pr¨ azise Verwaltung der Artikelabmessungen und zur Verf¨ ugung stehenden Lagerkapazit¨aten voraussetzt. Bei sp¨ateren Auslagerungen ist auch Sorge zu tragen, dass nur ein bestimmter Artikel der Mischpalette entnommen wird. Um zu vermeiden, dass infolge unterschiedlicher Auslagerungs- bzw. Entnahmezeitpunkte der Anteil der nur noch zu einem geringen Anteil gef¨ ullten Paletten zu groß wird, sind hier ggf. eine zus¨ atzliche Volumen¨ uberwachung und die Initiierung einer Umlagerung, Umpackung oder Verdichtung (s. Abschn. 2.3.2, S. 57) zu realisieren. Eine Besonderheit stellt das Retourenhandling (Retoure = Warenr¨ ucksendung durch den Kunden) im Bereich des Versandhandels dar. Die Retourenquote kann sich im klassischen Versandhandel auf 30 % der Warenlieferungen und mehr belaufen. Da die Qualit¨ at des einzelnen Artikels im Vorfeld nicht bekannt ist, wird eine eingehende Pr¨ ufung aller Retourenlieferungen notwendig. Somit stellen Retouren einzeln eingehende Teile dar, die separat gepr¨ uft und bei Bedarf gereinigt, neu verpackt und etikettiert werden m¨ ussen und somit einen erheblichen Arbeitsaufwand bedeuten. Je nach eingesetzter Strategie wird die Retourenware auf die jeweils aktuelle und artikelreine Anbrucheinheit zur¨ uckgelagert oder gemeinsam mit anderer Retourenware in speziellen Lagerpositionen mit entsprechender Entnahmepriorisierung eingelagert. Sind alle Pr¨ ufungen positiv erfolgt und ist das Gut zur Vereinnahmung in das System geeignet, erfolgt die endg¨ ultige Einbuchung der Bestandsmengen in das bestandsf¨ uhrende System. 2.2.2 Einlagerung Im Fall eines manuellen Lagersystems (z. B. Blocklager mit Staplerbedienung) l¨auft in einem durchg¨ angigen Prozess die Aufnahme einer Lagereinheit und die direkte Verbringung an den ﬁnalen Lagerbereich inklusive der Einlagerung oder Abgabe der Lagereinheit ab. Dagegen erfolgt in gr¨oßeren und automatischen Systemen ein stufenweiser Prozess bis zur letztendlichen Einlagerung in ein Lagerfach. Daher wird im Folgenden der Gesamtablauf beschrieben, der im manuellen Fall nur aus speziﬁschen Teilschritten besteht.

2.2 Funktionen in Lagersystemen

29

Verteilung auf Lagerbereiche In einem ersten Schritt (Backorders) wird gepr¨ uft, ob die eingetroﬀenen Wareneing¨ ange zur Vervollst¨andigung von Auftr¨ agen gebraucht werden, die sich bereits im Warenausgang oder Versand beﬁnden, so dass eventuell ein direkter Transport an die Verbrauchsstellen oder in den Versandbereich erforderlich ist. Dieser Prozess wird auch als Durchlagerung bezeichnet. Daneben ﬁndet auch der Begriﬀ Cross Docking Verwendung, womit exakterweise ein umfangreicheres Konzept gemeint ist (vgl. S. 69), weshalb die Bezeichnung an dieser Stelle zwar gebr¨auchlich, aber eher unangebracht ist. Ansonsten folgt der Transport in den Lagerbereich bzw. die Lagerbereiche. Dazu ist im ersten Schritt die Festlegung der Transportziele im Lagerverwaltungssystem erforderlich. Gerade in großen Systemen ergeben sich hierbei erhebliche Optimierungspotenziale je nach H¨ ohe der anfallenden Transportwege und -mengen. Dies gilt umso mehr, wenn manuell gef¨ uhrte Unstetigf¨orderer (z. B. Stapler oder Schleppz¨ uge) zum Einsatz kommen. Eine innerbetriebliche Transportoptimierung kann durch verschiedene Maßnahmen und Techniken erreicht werden. Ein organisatorischer Ansatz liegt in der Sammlung und Vorsortierung der Artikel auf Touren. Das setzt jedoch entsprechende Puﬀerﬂ¨ achen und Bewegungsfreir¨ aume voraus. Ebenso ergeben sich dabei ggf. unterschiedliche Bearbeitungszeiten f¨ ur die zu verbringenden Waren. Einen weitergehenden Ansatz stellt daher ein automatisches Transportleitsystem dar, das unter Verwendung deterministischer Transportstrategien und -regeln die Verbringung in verschiedene Lagerbereiche steuert. Dazu k¨onnen beispielsweise Stapler mit Staplerterminals ausger¨ ustet werden, die dem Fahrer eine optimierte Auftragsreihenfolge vorgeben (vgl. Abschn. 2.3.3, S. 58). Ein wichtiger Aspekt ist die Transparenz des Materialﬂusses, wiederum insbesondere bei gr¨ oßeren Materialﬂusssystemen. Beispielhaft sei die Abgabe einer Transporteinheit an einem falschen Ort durch einen Staplerfahrer genannt, was in der Praxis typischerweise zum physischen Suchen f¨ uhrt. Zur Nachvollziehbarkeit und m¨ oglichen Fehlerbestimmung ist die logische Handhabung der F¨ ordermittel als virtuelle Lagerorte und die Umbuchung der Waren bei Transporten auf die F¨ ordermittel ein geeigneter Ansatz. Somit l¨asst sich eine l¨ uckenlose Dokumentationskette aufbauen und u ¨ ber ein Tracking and Tracing eine schnelle Ortung einzelner Einheiten realisieren. Identiﬁkation Sofern die Identit¨ at der Lagereinheit noch nicht bei der Wareneingangspr¨ ufung erfasst wurde, ﬁndet nun sp¨atestens die Identit¨atskontrolle am so genannten I-Punkt statt. Dies geschieht h¨auﬁg im Vorfeld automatischer Lagersysteme, wie beispielsweise vor Hochregalanlagen. Dabei wird ¨ zun¨ achst die Ubereinstimmung der Artikelnummer und Menge mit der Ladeeinheit gepr¨ uft, ggf. auch das Vorhandensein der Stammdaten. Gleichzeitig werden somit aber auch Materialﬂuss und Informationsﬂuss synchronisiert. Im Falle des Einsatzes automatischer Lagersysteme geschieht dies logischer-

30

2. Lagersysteme und Lagerverwaltung

Abbildung 2.4. Identiﬁkation und Konturenkontrolle am I-Punkt vor einem Hoch¨ regallager [Foto: STOCKLIN SIEMAG]

weise an der Schnittstelle zwischen manuellem und automatischem System. Hinter diesem Punkt kann die Reihenfolge nicht mehr vertauscht werden. Gleichzeitig muss auf Lagerf¨ahigkeit kontrolliert werden. Dazu z¨ahlt insbesondere die Konturenkontrolle (Pr¨ ufung der Abmessungen der einzulagernden Einheit) sowie ggf. eine Gewichtskontrolle, was speziell in Systemen mit nicht einheitlichen Lagerfachkapazit¨ aten erforderlich ist (s. Abb. 2.4). Bei bestimmten Inventurverfahren (vgl. Abschn. 2.3.5) erfolgt an dieser Stelle eine k¨orperliche Bestandsaufnahme (permanente Inventur). Vergabe des Lagerplatzes und Einlagerung Die Durchf¨ uhrung einer Einlagerung setzt zun¨ achst die Festlegung des Lagerfaches bzw. des Lagerplatzes voraus. Die Vergabe des Lagerfaches kann anhand einer Vielzahl von Kriterien erfolgen. Es ergeben sich Einﬂ¨ usse aus den physischen Anforderungen seitens des Lagergutes, der betriebstechnisch optimalen Lageroperation sowie aus der sicherheitstechnischen und rechtlichen Betrachtung (s. Tabelle 2.2). Anforderungen bez¨ uglich der physischen Lagergutabmessungen und Gewichte ergeben sich aus der allgemeinen Forderung nach wirtschaftlichem Regalbau, wobei aus dem vorhandenen oder zuk¨ unftigen Lagergutspektrum f¨ ur jeden Anwendungsfall speziﬁsche Lagerfachdimensionen und Traglasten

2.2 Funktionen in Lagersystemen

31

Tabelle 2.2. Einige wesentliche Parameter zur Lagerplatzvergabe Parameter

Anforderungen

technische Anforderungen

Beachtung zulässiger Fach- und Feldlasten gleichmäßige Regalbelastung und Vermeidung einseitiger Belastungen, insbesondere in dynamischen Lagersystemen Lagerfachvolumen optimal nutzen

betriebliche Optimierung

Fahr- und Transportwege minimieren Umschlagleistung maximieren maximale Nutzung der vorhandenen Lagerkapazität hohe Verfügbarkeit, d. h. Zugriffssicherheit auch bei Ausfall einzelner Transportoder Bediengeräte schnelles Finden und Identifizieren der Waren in manuellen Systemen

sicherheitstechnische und rechtliche Vorgaben

Beachtung von Zusammenlagerungsverboten (Gefahrgutlagerung) Getrenntlagerung (Lebensmittelbereich) Chargengruppierung

abgeleitet werden m¨ ussen. Sofern ein Lagergutspektrum vorliegt, das eine solche Segmentierung rechtfertigt (ausreichende Verteilung in verschiedenen Klassen), ist die Reduzierung der zul¨ assigen Traglasten mit zunehmender Regalebene bzw. die Bildung entsprechender Lastbereiche eine g¨angige Praxis. Auch in der manuellen Kommissionierung wird aus ergonomischen Gr¨ unden in den oberen Lagerf¨ achern die Einlagerung leichterer Einheiten angestrebt. Bei einigen dynamischen Lagersystemen, beispielsweise den HorizontalUmlaufregalen (s. S. 87), muss funktionsbedingt eine einseitige Belastung vermieden werden. In solchen F¨ allen ist eine gleichm¨aßige Lastverteilung durch die Systemsteuerung zu realisieren. Ein generelles Bestreben ist die m¨oglichst gute Nutzung des vorhandenen Lagervolumens. Daher ist im Fall stark unterschiedlicher H¨ ohen der Ladeeinheiten eine Stufung der Lagerfachh¨ohen angebracht. Zur Optimierung der operativen Bedienprozesse eines Lagersystems existiert eine Reihe unterschiedlicher Strategien, die z. T. inkompatibel zueinander sind. Die g¨ angigsten Strategien und deren Vertr¨aglichkeiten sind in Tabelle 2.3 dargestellt. Die Fahrwegstrategie stellt dabei eine allgemeing¨ ultige Sekund¨ arstrategie dar und ist der Vollst¨ andigkeit halber mit aufgef¨ uhrt. Sicherheitstechnische und rechtliche Vorgaben besitzen naturgem¨aß Priorit¨ at und gelten insbesondere im Gefahrgut- und Lebensmittelbereich. Hier existiert eine Vielzahl besonderer Regelungen, die im Folgenden auf ihre funktionellen Auswirkungen f¨ ur die Lagerverwaltung beleuchtet werden. ¨ Die Uberwachung der Einlagerung ist ebenfalls integraler Bestandteil eines modernen Lagermanagements und schließt den Prozess der Einlagerung ab. Dazu wird eine R¨ uckmeldung der Ausf¨ uhrung mit Lagerplatz und Einlagerungszeit dokumentiert. W¨ ahrend dieser Schritt in vollautomatischen L¨agern

32

2. Lagersysteme und Lagerverwaltung

Tabelle 2.3. Operationelle Lagerplatzvergabestrategien Bezeichnung

Strategie

Zielsetzung

Festplatzlagerung

feste Zuordnung eines Lagerplatzes für einen bestimmten Artikel

Zugriffssicherheit bei Ausfall des Verwaltungssystems schneller Zugriff in manuellen Kommissioniersystemen durch Übung (Verringerung der Suchzeiten)

freie Platzvergabe (chaotische Lagerung)

Artikel kann auf einem beliebigen freien Lagerplatz eingelagert werden

maximale Ausnutzung der Lagerkapazität

Zonung

Wahl des Lagerplatzes entsprechend der Umschlaghäufigkeit des Artikels

Erhöhung der Umschlagleistung durch Minimierung der mittleren Weglänge

Querverteilung

Lagerung mehrerer Einheiten eines Artikels verteilt über mehrere Lagergassen

Verfügbarkeit des Artikels bei Ausfall eines Regalförderzeuges Erhöhung der Umschlagleistung durch Parallelisierung

Pick-/Teilefamilien Clustering

benachbarte Lagerorte für häufig kombinierte Artikel

Erhöhung der Umschlag- bzw. Kommissionierleistung durch Minimierung der Anschlusswege

kürzester Fahrweg

Anfahrt des Lagerplatzes mit kürzestem Weg

Erhöhung der Umschlagleistung durch Minimierung der Anschlusswege

Vorpufferung

in Spitzenzeiten Einlagerung auf vorderen Lagerbereich

Vermeidung von Rückstau durch Erhöhung des Durchsatzes

untereinander kompatibel

bzw. Lagersteuerungen per se abl¨ auft, bedarf es im Fall eines manuellen Lagersystems (mit rechnergest¨ utzter F¨ uhrung, z. B. durch Staplerleitsystem) einer Veriﬁkation durch den Bediener, z. B. durch unmittelbare Erfassung von Lagergut und Lagerplatz. G¨ angige Systeme disponieren zur Sicherstellung dieses Schritts erst nach erfolgter Veriﬁkation den n¨achsten Auftrag. 2.2.3 Auslagerung Die Verwaltung der Auslagerungsauftr¨ age erfolgt je nach Anwendungsfall f¨ ur einen k¨ urzeren oder l¨ angeren Zeitraum. In jedem Fall muss zun¨achst eine Pr¨ ufung der vorliegenden Auftr¨ age auf Erf¨ ullbarkeit durchgef¨ uhrt werden. Dabei erfolgt eine Reservierung der auszulagernden Mengen und/oder Lagereinheiten, um Fehlmengen zum terminierten Auslagerzeitpunkt zu vermeiden (vgl. Abschn. 2.3.1, S. 55). Die Disposition und Durchf¨ uhrung der Auslagerung erfordert die Ber¨ ucksichtigung verschiedenster Zielvorgaben und wird unter Anwendung bestimmter Auslagerungsstrategien (s. Tabelle 2.4) durchgef¨ uhrt. Einige Strategien (terminierte oder tourenoptimierte Auslagerungen) k¨ onnen nur bei entsprechender zeitlicher Disposition realisiert werden.

2.2 Funktionen in Lagersystemen

33

Tabelle 2.4. Auslagerstrategien Bezeichnung

Strategie

Zielsetzung

FIFO (First-In-First-Out)

Auslagerung der zuerst eingelagerten Ladeeinheit eines Artikels

Vermeidung von Überalterung und Verfall einzelner Ladeeinheiten eines Artikels

LIFO (Last-In-First-Out)

Auslagerung der zuletzt eingelagerten Ladeeinheit eines Artikels

Vermeidung von Umlagerungen bei bestimmten Lagertechniken (Blocklager)

Mengenanpassung

Auslagerung von vollen und angebrochenen Ladeeinheiten entsprechend der Auftragsmenge

Erhöhung der Umschlagleistung durch Minimierung der Rücklagerungen

Anbruchmengenbevorzugung

generelle Priorisierung angebrochener Ladeeinheiten

verbesserte Nutzung der Lagerkapazitäten

kürzester Fahrweg

Auslagerung der Ladeeinheit eines Artikels mit dem kürzesten Anschlussweg

Erhöhung der Umschlagleistung durch Minimierung der Fahrwege

Gassenwechselminimierung

Sortierung der Auslagerreihenfolge nach einzelnen Lagergassen

Minmierung der Umsetzvorgänge bei kurvengängigen RBG oder Verschieberegalen

tourenbezogen

Planung der Auslagerreihenfolge entsprechend der Tourenplanung eines nachgeschalteten Verkehrsmittels

Reduzierung der Rangier- und Umladearbeiten

terminiert

Planung des Auslagerzeitpunktes entsprechend dem voraussichtlichen Bedarfszeitpunkt

Reduzierung der Rangier- und Umladearbeiten

Vorholung

Umlagerung der in Kürze auszulagernden Einheiten in die Nähe des Übergabepunktes

Verkürzung der Reaktionszeit durch Erhöhung der Umschlagleistung zum Bedarfszeitpunkt

¨ Das Lagerverwaltungssystem besitzt weiterhin die Aufgabe der Uberwachung der initiierten Auslagerungen und der R¨ uckmeldung der korrekten Ausf¨ uhrung. Nach Durchf¨ uhrung der Auslagerung erfolgen die Freigabe des Lagerplatzes, die Bestandsfortschreibung mit der Verminderung des Lagerbestandes um die ausgelagerte Menge und die L¨oschung entsprechender Reservierungen. F¨ ur eine kontinuierliche Materialﬂussverfolgung sollte die Ladeeinheit, respektive der Bestand, an den nachfolgenden Empf¨anger oder auf das Transportmittel verbucht werden (in diesem Fall wird das Transportmittel logisch wie ein Lagerplatz behandelt).

34

2. Lagersysteme und Lagerverwaltung

2.2.4 Konsolidierungspunkt Der Konsolidierungspunkt ist eine Stelle zur Identiﬁzierung abgefertigter Einheiten an Schl¨ usselpositionen des Materialﬂusses. Insbesondere in Systemen mit stochastischen Einﬂ¨ ussen, beispielsweise mit manuellen Arbeitsabl¨aufen, ist ein solcher Messpunkt elementar zur Feststellung des Produktionsfortschrittes im Lager. Es erfolgt einerseits ein Abgleich der Soll- und Ist-Daten (z. B. durch ¨ ¨ Messung des Gewichts) und somit eine Uberpr¨ ufung der Ubereinstimmung von Material- und Informationsﬂuss. Dabei wird generell der Auftragsstatus aktualisiert, d. h. im Fall des Lagersystems wird der Status des Auslagerungsauftrags fortgeschrieben. Andererseits erfolgen materialﬂusstechnische Entscheidungen wie die Auswahl von Transportzielen f¨ ur fertige Einheiten. 2.2.5 Kommissionierung Die Zusammenstellung einer kundengerechten Bedarfsmenge eines oder mehrerer Artikel wird als Kommission, der dazugeh¨orige Prozess als Kommissionierung bezeichnet. Die Kommissionierung beschreibt damit die Zusammenstellung von Artikeln f¨ ur einen Kundenauftrag, d. h. die Entnahme von Teilmengen gr¨ oßerer Einheiten einzelner Artikel und deren Zusammenf¨ uhrung und Bereitstellung f¨ ur die Versendung. Die Kommissionierung stellt einen arbeitsintensiven, zumeist personalintensiven und im Allgemeinen kostenintensiven Bereich eines Lager- und Warenverteilzentrums dar und erf¨ ahrt dadurch besondere Beachtung bei Planung und Betrieb solcher Systeme. In der Kommissionierung kommen heute alle erdenklichen f¨order- und lagertechnischen Systeme zum Einsatz. Die enge Verﬂechtung von technischen Gewerken, Ablauf- und Organisationsstruktur und Informationsmanagement machen die Gestaltung und den Betrieb von Kommissioniersystemen zu einer sehr komplexen Aufgabe. Mit dem Ziel einer besseren Strukturierbarkeit dieser Abl¨ aufe und Aufgaben wurden Grundfunktionen und Standardabl¨aufe deﬁniert, die eine systematische Vorgehensweise bei der Planung und Organisation eines Kommissioniersystems erm¨ oglichen sollen [22, 24, 69, 70]. Bei der Betrachtung von Kommissioniersystemen werden g¨angigerweise die drei Bereiche • Materialﬂusssystem, • Organisation und • Informationsﬂuss unterschieden. Materialﬂusssystem Bei der Gestaltung des Materialﬂusses eines Kommissioniersystems steht zun¨ achst die Frage im Vordergrund, wie Kommissionierer und Artikel zur

2.2 Funktionen in Lagersystemen

35

Durchf¨ uhrung der Vereinzelung r¨ aumlich und zeitlich eﬃzient zusammengef¨ uhrt werden k¨ onnen und in welcher Form die einzelne Entnahmeeinheit bzw. die Sammel- oder Kommissioniereinheit (vgl. Abschn. 2.1.2, S. 22) weiter gef¨ ordert wird. Nur in wenigen F¨ allen ﬁndet keine unmittelbare Bewegung statt, da die Vereinzelung – analog zur Funktionsweise eines Zigarettenautomaten – innerhalb der Maschine selbst erfolgt und von dort zur Sammelstelle gef¨ordert wird (z. B. bei automatischen Kommissionieranlagen wie Schachtkommissionierern). Nach [24] setzt sich die physische Kommissionierung aus folgenden materialﬂusstechnischen Grundfunktionen zusammen: • • • • • • • • •

Bewegung der G¨ uter zur Bereitstellung, Bereitstellung, Fortbewegung des Kommissionierers zur Bereitstellung, Entnahme der G¨ uter durch den Kommissionierer, Transport der Entnahmeeinheit zur Abgabe, Abgabe der Entnahmeeinheit, Transport der Kommissioniereinheit zur Abgabe, Abgabe der Kommissioniereinheit, R¨ ucktransport der angebrochenen Ladeeinheit.

Anhand des in Tabelle 2.5 dargestellten morphologischen Kastens lassen sich durch vertikale Kombination der einzelnen Elemente Strukturen und L¨osungen f¨ ur Kommissioniersysteme erarbeiten bzw. beschreiben. Dabei ist darauf zu achten, dass zur Zusammenf¨ uhrung von Kommissionierer und Bereitstelleinheit entweder der Kommissionierer oder die Bereitstelleinheit eine Bewegung durchf¨ uhren muss. Ebenso muss entweder die Entnahmeeinheit oder die Kommissioniereinheit einen Transport durchf¨ uhren, um den Kommissioniervorgang abzuschließen. Bei dem Kommissionierer“ kann es sich ” bei dieser Betrachtung sowohl um einen Menschen als auch um eine Maschine (z. B. Kommissionierroboter) handeln. Die Bedeutung einer Reihe von Klassiﬁzierungen erfordert dabei besondere Beachtung. Insbesondere die Anwendung der Bezeichnungen statisch“ ” und dynamisch“ erfolgt in der Praxis und der Literatur uneinheitlich. Die ” klassische und auch in der Lagertechnik verwendete Deﬁnition sieht vor, dass bei statischer Bereitstellung eine Einheit zwischen Ein- und Auslagerung am selben Ort verbleibt (vgl. z. B. [17]), d. h. der Artikel station¨ar, beispielsweise in einem Regalfach, zur Entnahme bereitsteht. Analog muss bei dynamischer Bereitstellung die Bereitstelleinheit des gew¨ unschten Artikels zum Entnahmeort bef¨ ordert und gegebenenfalls nach erfolgter Entnahme zur¨ uckgelagert werden. In j¨ ungeren Publikationen wird dagegen die Bezeichnung auf den Entnahmevorgang konzentriert. Nach dieser Deﬁnition beﬁnden sich bei statischer Bereitstellung die zu greifenden Teile in Ruhe, bei dynamischer Bereitstellung erfolgt der Entnahmevorgang auf das bewegte Teil.

36

2. Lagersysteme und Lagerverwaltung

Tabelle 2.5. Grundfunktionen des Materialﬂusssystems nach [24] Grundfunktionen Materialfluss

Realisierungsmöglichkeiten

Bewegung der Güter zur Bereitstellung

keine Bewegung

Bereitstellung

Bereitstellung

1-dimensional

2-dimensional

3-dimensional

manuell

mechanisiert

automatisiert

statisch

dynamisch

zentral

dezentral

geordnet Fortbewegung des Kommissionierers zur Bereitstellung

Bewegung

keine Fortbewegung

manuell

teilgeordnet Fortbewegung 1-dimensional

2-dimensional

3-dimensional

manuell

mechanisiert

automatisiert

mechanisiert

Einzelstückgut Transport der Entnahmeeinheit zur Abgabe

Abgabe der Entnahmeeinheit

kein Transport

Abgabe der Kommissioniereinheit

Sammelstückgut Transport Fördermittel

1-dimensional

2-dimensional

3-dimensional

manuell

mechanisiert

automatisiert

statisch

dynamisch

zentral

dezentral

kein Transport

teilgeordnet

ungeordnet

Transport Kommissionierer

Fördermittel

1-dimensional

2-dimensional

3-dimensional

manuell

mechanisiert

automatisiert

statisch

dynamisch

zentral

dezentral

geordnet Bewegung der Güter zur Bereitstellung

automatisiert

Kommissionierer

geordnet Transport der Kommissioniereinheit zur Abgabe

ungeordnet

keine Bewegung

teilgeordnet

ungeordnet

Rücktransport ins Lager

Rücktransport ins Anbruchlager

1-dimensional

2-dimensional

3-dimensional

manuell

mechanisiert

automatisiert

2.2 Funktionen in Lagersystemen

37

Eng mit dieser Problematik ist die Diﬀerenzierung in zentrale und dezentrale Bereitstellung verkn¨ upft. Unter zentraler Bereitstellung wird dabei die Bereitstellung und Entnahme an einem ¨ ortlich festen Punkt verstanden oder zumindest an r¨ aumlich stark begrenzten Punkten (z. B. zwei bis drei nebeneinander liegenden Paletten¨ ubergabepl¨ atzen oder Kommissionierung aus mehreren Horizontal-Umlaufregalen (s. Abschn. 3.1.3, S. 87)). Die Bereitstelleinheiten werden sequenziell an diesem zentralen Punkt bereitgestellt. Nur auf diese bereitgestellten Einheiten kann zugegriﬀen werden. Demgegen¨ uber erfolgt bei dezentraler Bereitstellung die Entnahme an unterschiedlichen Punkten, zu denen sich der Kommissionierer bewegen muss. Abwechselnd wird in der Literatur ferner die statische oder die dezentrale Bereitstellung mit dem Prinzip Person-zur-Ware und die dynamische oder die zentrale Bereitstellung mit dem Prinzip Ware-zur-Person gleichgesetzt. Angesichts der Tatsache, dass die Unterscheidung zentral – dezentral“ je” doch nicht alle Gestaltungsformen abdecken kann und Kommissionierverfahren, bei denen eine Entnahme eines in Bewegung beﬁndlichen Gutes erfolgt, praktisch nicht bekannt sind, wird folgende Bedeutung zugrunde gelegt: Die Diﬀerenzierung in statische und dynamische Bereitstellung kl¨art, ob die Bereitstelleinheit zur Durchf¨ uhrung einer Entnahme f¨ordertechnisch bewegt werden muss. Und: Die Diﬀerenzierung in zentrale und dezentrale Bereitstellung deﬁniert den Ort der Durchf¨ uhrung der Entnahme. Bei der zentralen Bereitstellung ﬁndet die Entnahme an einem r¨aumlichen festen Punkt, bei der dezentralen Entnahme an verschiedenen r¨aumlichen Punkten statt. Zur Verdeutlichung dieser Unterscheidungen dienen die Beispiele in Tabelle 2.6. Wie diese Auﬂistung zeigt, ist die statische Bereitstellung nicht gleichbedeutend mit der Bewegung des Kommissionierers zur Ware (Personzur-Ware, PzW), da diese im Fall des Kommissioniernestes auch zentral erfolgen kann. Demgegen¨ uber ist auch bei der dynamischen Bereitstellung gegebenenfalls eine Bewegung des Kommissionierers erforderlich. In diesen F¨allen verschwimmt die Bezeichnung Ware-zur-Person (WzP) und es kann nicht mehr eindeutig nach WzP bzw. PzW diﬀerenziert werden. Bei der Abgabe der kommissionierten Einheiten erfahren die Unterscheidungsmerkmale zum Teil eine andere Bedeutung. Im Fall der Abgabe der Entnahmeeinheit oder der Kommissioniereinheit bezieht sich die Unterscheidung in statische oder dynamische Abgabe auf das abzugebende F¨ordermittel bzw. die Sammeleinrichtung. Beﬁndet sich das F¨ordermittel in Bewegung (Stetigf¨ orderer), liegt eine dynamische Abgabe vor; wird dagegen auf eine unbewegte Sammeleinrichtung abgegeben, liegt eine statische Abgabe vor. Hinsichtlich der Unterscheidung in zentrale und dezentrale Abgabe verh¨alt sich

38

2. Lagersysteme und Lagerverwaltung

statisch

dynamisch

dezentral

Fachbodenregalanlage

Regalfront an AKL

Die Bereitstellung erfolgt in einem Fachbodenregal, der Kommissionierer bewegt sich entlang der Regalfront und entnimmt entsprechend den Bedarfsinformationen einzelne Einheiten. Es werden nur die Bereitstelleinheiten angesprochen, für die Bedarf vorliegt. Dieser Ablauf wird auch als das Prinzip „Person-zur-Ware“ verstanden.

Die Bereitstelleinheiten befinden sich beispielsweise in einem automatischen Kleinteilelager (AKL). Die Kommissionierung erfolgt an der bodenebenen Regalebene, seitlich des AKL. Die Bereitstelleinheiten werden in unterster Regalhöhe dynamisch bereitgestellt, allerdings werden verschiedene Plätze angefahren, so dass sich der Kommissionierer wie im Fall des Fachbodenregals vor der Regalzeile bewegen muss.

zentral

Tabelle 2.6. Beispiele zur Bereitstellung

Kommissioniernest

Hochregallagervorzone

Es wird eine Regalanordnung geschaffen (zumeist U-förmige Anordnung), in deren Mitte der Kommissionierer steht und alle Artikel in Reichweite hat. Der Kommissionierer erreicht durch Wegfall sämtlicher Weganteile sehr hohe Kommissionierleistungen (bis zu 1000 Teile/h). Die Anwendung ist auf die Kommissionierung einer begrenzten Anzahl kleinvolumiger Artikel beschränkt.

Die Bereitstelleinheiten befinden sich in einem automatischen Hochregal oder Kleinteilelager und müssen zur Entnahme an einen zentralen Übergabepunkt befördert werden. Die Lagereinheiten werden nach Auslagerung aus dem Regalfach zumeist über Stetigfördertechnik zum Kommissionierplatz gefördert und anschließend wieder eingelagert. Eine Anordnung dieser Art wird auch als „Kommissionier-U“ bezeichnet und der Ablauf als das Prinzip „Ware-zur-Person“ verstanden.

die Unterscheidung analog zur Entnahme: Wird z. B. eine Sammeleinrichtung mitgef¨ uhrt, erfolgt die Abgabe der Entnahmeeinheiten an unterschiedlichen Orten, also dezentral; eine Abgabe an einen fest installierten Abgabepunkt ist dagegen zentral. Beispiele f¨ ur verschiedene Auspr¨agungsformen liefert Tabelle 2.7. Weitere Unterscheidungsmerkmale betreﬀen die Form der Bewegung, die Art der Entnahme und die Ordnung der bereitgestellten oder abgegebenen G¨ uter. Die Bewegung kann in der Kommissionierung ein-, zwei- oder dreidimensional erfolgen. Bewegt sich der Kommissionierer ebenerdig entlang einer Regalfront, liegt dabei eindimensionale Bewegung vor. Die zweidimensionale Bewegung kann beispielsweise mittels Regalbedienger¨at oder Kommissionierstapler, die dreidimensionale mittels Kran erfolgen. Die Entnahme erfolgt zum u ¨ berwiegenden Teil manuell, bei schweren oder unhandlichen G¨ utern auch mechanisiert u ¨ ber entsprechende Hilfsmittel (z. B. Manipulatoren) und bei geeigneten Gut- und Auftragsspektren auch zunehmend automatisiert u ¨ber Kommissionierroboter oder Schachtkommissionierer (z. B. in der Pharmazie). Eng mit der Eignung zur Automatisierung ist schließlich auch die Frage des Ordnungszustandes bei der Bereitstellung und Abgabe der Einheiten verkn¨ upft. Die automatische Kommissionierung ist um-

2.2 Funktionen in Lagersystemen

39

zentral

dezentral

Tabelle 2.7. Beispiele zur Abgabe der Entnahmeeinheit statisch

dynamisch

Pick-to-Box

Pick-to-Belt

Der Kommissionierer legt die Einheiten in einen mitgeführten Behälter („Kommissionierwanne“). Dabei bewegt er sich mit dem Behälter zwischen den Entnahmenstellen. Stellt der Behälter gleichzeitig die zum Kunden gehende Versandeinheit dar, wird das Prinzip als „Pick&Pack“ bezeichnet.

Der Kommissionierer legt die Entnahmeeinheiten direkt nach der Entnahme auf ein parallel zur Regalfront angeordnetes, zumeist angetriebenes Förderband. Anschließend bewegt er sich zum nächsten Entnahmeort.

Ware-zur-Person / Kommissionier-U

Ware-zur-Person / Paternosterregal mit Rollenbahn

Die an der Entnahmestelle entnommenen Einheiten werden auf eine bereitgestellte Sammeleinheit (Palette oder Behälter) abgegeben und ggf. dort gestapelt.

Die dem Paternosterregal entnommenen Einheiten werden auf einen davor installierten Bandförderer abgegeben. Der Kommissionierer legt keine Wege zurück.

so einfacher bzw. eﬃzienter realisierbar, je h¨oher der Ordnungszustand der Einheiten ist. W¨ ahrend auf Basis dieser Klassiﬁzierungen durchaus grunds¨atzliche Eignungsparameter und Charakteristika abgeleitet werden k¨onnen, ist die Entscheidung, welches System f¨ ur einen gegebenen Anwendungsfall optimal ist, praktisch nur im Einzelfall im Rahmen einer Systemplanung zu treﬀen. Organisationsformen Einen wesentlichen Einﬂuss auf die Eﬃzienz und damit auch auf die Systemwahl besitzt die Organisation des Kommissioniersystems, d. h. die Wahl der Struktur und Steuerung der Abl¨ aufe innerhalb des Kommissioniersystems. G¨angigerweise werden dabei die Aufbauorganisation, d. h. die Struktur der Anordnung der Lagerbereiche, und die Ablauforganisation, d. h. die Abwicklung des Kommissionierprozesses, unterschieden. Aufbauorganisation Die Aufgabe der Aufbauorganisation besteht in der Deﬁnition einer geeigneten Struktur f¨ ur ein Kommissioniersystem. Dabei steht die Frage im Vordergrund, welche Bereitstellsysteme f¨ ur unterschiedliche Artikel gew¨ ahlt werden. In jedem Fall setzt dieser Schritt eine sorgf¨altige ¨ Analyse des Sortiments und der Auftragsstruktur voraus. Ublicherweise leiten sich daraus variierende Anforderungen an Kapazit¨at, Leistung und Eigenschaften des Bereitstellsystems ab. Solche Anforderungen resultieren u. a. aus • Volumina, Gewichten und Abmessungen der Bereitstelleinheiten, • Umschlagh¨ auﬁgkeiten bzw. Zugriﬀsh¨ auﬁgkeiten pro Artikel,

40

• • • •

2. Lagersysteme und Lagerverwaltung

mittleren Entnahmemengen pro Artikel pro Zeiteinheit, Zugriﬀ, h¨ auﬁgen Kombinationen einzelner Artikel, Sicherheitsanforderungen (hochwertige G¨ uter), Temperatur- und Sicherheitsanforderungen.

Da die Bereitstellsysteme sich jeweils durch besondere Eignungsschwerpunkte ausweisen (vgl. Kapitel 3), ist gegebenenfalls die Nutzung unterschiedlicher Systeme sinnvoll. Deshalb werden g¨ angigerweise dedizierte Zonen f¨ ur unterschiedliche Artikeltypen gebildet. Aber auch innerhalb eines Bereitstellsystems kann durch eine logische Zonung (vgl. Tabelle 2.3) eine Optimierung erzielt werden. Ablauforganisation Die Produktivit¨ at eines Kommissionierers ist gepr¨agt durch die ¨ • Basiszeit (z. B. Ubernahme des Auftrags, Sortieren von Belegen, Aufnahme von Kommissionierbeh¨ altern, Abgabe von Ware und Kommissionierbeh¨ altern, Weitergabe bzw. abschließende Belegbearbeitung), • Greifzeit (Hinlangen, Aufnehmen, Bef¨ ordern und Ablegen der Entnahmeeinheit), • Totzeit (z. B. Lesen, Aufreißen von Verpackungen, Suchen und Identiﬁzieren, Kontrollieren und Reagieren), • Wegzeit (Bewegung (Fahren oder Gehen) des Kommissionierers zwischen Annahmestelle – Entnahmeort – Abgabestelle). Die Summe dieser Zeitanteile wird als Kommissionierzeit bzw. als mittlere Kommissionierzeit bezeichnet, sofern die gemittelten Zeitanteile ber¨ ucksichtigt werden. Sie wird einerseits durch die Auftragsstruktur und im Wesentlichen von der mittleren Anzahl der Zeilen (Auftragspositionen) pro Auftrag bestimmt. Andererseits h¨ angt sie auch in starkem Maße von der Systemstruktur und der Organisation der zu entnehmenden Einheiten und Entnahmeorte ab. W¨ ahrend die Basis- und Totzeitanteile u. a. durch Wahl eines geeigneten Informationssystems beeinﬂusst werden k¨ onnen (s. S. 44), stehen die Greifund vor allem die Wegzeit im Fokus der Ablauforganisation. Im einfachsten Fall wird der Kundenauftrag durch einen Kommissionierer bearbeitet, der diesen Auftrag vollst¨ andig abschließt und anschließend den n¨achsten Auftrag bearbeitet. Das Prinzip wird als einfache, auftragsweise Kommissionierung bezeichnet. Dieser Ablauf kann beim Prinzip Person-zurWare durchaus dort sinnvoll sein, wo die durchschnittliche Auftragsmenge die Transportkapazit¨ at des Kommissionierers ausf¨ ullt. Sie bietet außerdem den Vorteil eines geringen Aufwandes zur Vorbereitung. Im einfachsten Fall wird direkt der eingehende Kundenauftrag als Kommissionierliste verwendet. Der Kommissionierer legt dadurch aber lange Wege zur¨ uck, da die Pickfolge unmittelbar durch den Auftrag vorgegeben wird, wodurch das Prinzip auf kleine Systeme beschr¨ ankt ist.

2.2 Funktionen in Lagersystemen

41

Die erste Optimierungsm¨ oglichkeit besteht in der Sammlung und gleichzeitigen Bearbeitung mehrerer Kundenauftr¨age, was als auftragsparalleles Kommissionieren oder Sortieren w¨ahrend der Kommissionierung bezeichnet wird. Durch Anstieg der Entnahmepunktdichte reduziert sich die mittlere Wegzeit pro Auftrag. Dabei ist der Kommissionierer derart durch das System zu f¨ uhren, dass er automatisch zum n¨ achsten Entnahmeort gef¨ uhrt wird und somit lange Totzeiten (Identiﬁzierung des n¨achstliegenden Artikels) oder Zur¨ uckgehen vermieden werden. In großen Systemen ist es wenig sinnvoll, dass ein Kommissionierer mit dem Auftrag das gesamte Kommissioniersystem durchl¨auft. In diesem Fall m¨ usste der Kommissionierer sich nicht nur in allen Bereichen gleichermaßen auskennen, sondern auch zwangsl¨ auﬁg sehr hohe Weganteile zur¨ ucklegen. Gleichzeitig w¨ urde ein sehr großes Verkehrsaufkommen mit einem nahezu unkoordinierbaren Ablauf entstehen. Aus diesem Grund werden die Bereiche in einzelne Sektionen geteilt, in denen jeweils ein oder wenige Kommissionierer aktiv sind und einen Teil des Kundenauftrags bearbeiten. Nach Abarbeitung der in der jeweiligen Zone beﬁndlichen Artikel werden die Sammeleinheiten in die folgende Sektion weitergereicht. Dieses Verfahren wird als Kommissionieren in seriellen Zonen bezeichnet. Vorteilhaft ist dabei insbesondere, dass einzelne Zonen durch F¨ ordertechnik u uckt werden k¨onnen, sofern keine ¨ berbr¨ Artikel in diesen Zonen zu entnehmen sind. Alternativ dazu k¨ onnen auch die Kundenauftr¨age in Teilauftr¨age zerlegt werden, die jeweils zeitgleich in die einzelnen Zonen eingeschleust und dort parallel gesammelt werden, was insbesondere zu einer Verk¨ urzung der Durchlaufzeit der Auftr¨ age f¨ uhrt. Dieses Verfahren wird als parallele bzw. exakter als zonenparallele Kommissionierung bezeichnet. Dem m¨oglichen Zeitgewinn steht wiederum der Aufwand der Vorbereitung der Auftr¨age und die Notwendigkeit der Zusammenf¨ uhrung der Teilauftr¨age entgegen. W¨ahrend die Auftragsaufbereitung weitgehend rechnergest¨ utzt ablaufen kann, sind zur Zusammenf¨ uhrung der Teilauftr¨ age ggf. Puﬀer-, Sammel- oder Verteilsysteme erforderlich (s. Abschn. 2.2.6, S. 51). Bei allen vorgenannten Verfahren ist die Bindung eines Artikels an den dazugeh¨ origen Auftrag jederzeit ersichtlich. Diese Verfahren werden als einstuﬁg bezeichnet, da Entnahme und Zuordnung zum Kundenauftrag in einem Schritt durchgef¨ uhrt werden. Die Wegzeitreduzierung durch auftragsparalleles Kommissionieren (gleichzeitiges Ansteuern gleicher oder nahe zusammenliegender Artikel bzw. Bereitstelleinheiten) l¨ asst sich dabei jedoch nur bis zu einem bestimmten Grad durchf¨ uhren, da jeweils eine direkte Trennung in einzelne Auftr¨ age erfolgen muss. Bei der artikelorientierten Kommissionierung werden dagegen die Prozesse der Entnahme und der Zusammenstellung der Kundenauftr¨ age voneinander getrennt und in zwei separaten Schritten oder zweistuﬁg durchgef¨ uhrt. Durch diese Maßnahme k¨onnen alle in einer gr¨oßeren Auftragsmenge auftretenden identischen Artikel in einem Kommissioniervorgang gepickt werden, d. h. die Bereitstelleinheit ist nur einmal anzusteuern

42

2. Lagersysteme und Lagerverwaltung

bzw. zum Entnahmeplatz zu bef¨ ordern. Es k¨ onnen sowohl die Wegzeiten als auch die Greifzeiten erheblich reduziert werden. Dieser Vorgang setzt die Sammlung mehrerer Kundenauftr¨age in so genannten Auftragsstapeln oder Batches voraus, weshalb dieses Prinzip auch als Batchkommissionierung bezeichnet wird. Nachdem die gesamten im Auftragsstapel entnommenen Einheiten gesammelt wurden, erfolgt im zweiten Schritt die Verteilung einzelner Entnahmeeinheiten auf die Kundenauftr¨ age. Zur Durchf¨ uhrung dieses zweiten Schrittes stehen verschiedene F¨ ordersysteme, so genannte Sortier- und Verteilanlagen oder Sorter [25] zur Verf¨ ugung. Die Batchkommissionierung erfordert einen hohen Systemaufwand zur Auftragsvorbereitung, zum Transport der Entnahmeeinheiten und zur Verteilung auf Kundenauftr¨ age, wodurch sich dieses Prinzip f¨ ur kleine Systeme mit einem geringen Auftragsvolumen weniger eignet. Die artikelorientierte Kommissionierung (Batchkommissionierung, zweistuﬁge Kommissionierung) erbringt hohe Kommissionierleistung, setzt allerdings folgende Eigenschaften voraus: • gute F¨ orderf¨ ahigkeit der Entnahmeeinheiten mit ¨ahnlichen Dimensionen und Handhabungseigenschaften, • rechnergest¨ utzte Auftragsaufbereitung und Zusammenf¨ uhrung zur Sortierung der Entnahmeeinheiten und Zuteilung auf Kundenauftr¨age, • ausreichende Verdichtungsm¨ oglichkeit des Auftragseingangs, d. h. ausreichende Menge an Auftr¨ agen zur Stapelbildung mit weitgehend gleicher Priorit¨ at. Betriebsorganisation/Steuerungsstrategien Der Betrieb eines Kommissioniersystems bedarf verschiedener Regeln, Strategien und ﬂexibler Verhaltensmuster, um den im Tagesbetrieb variierenden Systemanforderungen gerecht zu werden. Dementsprechend ist die Betriebsorganisation eines Kommissioniersystems eine Sammlung an die speziellen Anforderungen eines Systems angepasster organisatorischer Regeln, die sowohl Teil des Warehouse Managementsystems als auch statisch etablierte Regeln sein k¨onnen. Darunter fallen beispielsweise T¨ atigkeiten wie • Einlastung bzw. Behandlung von Fixtermin- und Eilauftr¨agen, • Auftragseinschleusung in Abh¨ angigkeit von der momentan verf¨ ugbaren Kommissionierleistung, vom aktuellen Arbeitsfortschritt oder vom Systemstatus, • Zuteilung von Kommissionierern zu Zonen oder T¨atigkeiten (Ressourcenmanagement), • Ausl¨osung Nachschub. Dabei ﬁnden prinzipiell alle Maßnahmen Anwendung, die in Kapitel 4 behandelt werden.

2.2 Funktionen in Lagersystemen

43

Informationsverarbeitung Die Aufgabe der Informationsverarbeitung besteht in der Erfassung, Aufbereitung und Verarbeitung der zur Durchf¨ uhrung der Kommissionierung erforderlichen Informationen. Dazu z¨ ahlen im Einzelnen (vgl. [24, 69]) • die Erfassung der Kundenauftr¨ age unter Ber¨ ucksichtigung des Servicegedankens gegen¨ uber dem Kunden und der Kapazit¨at des Erfassungssystems, • die Aufbereitung der Auftr¨ age in ein dem Organisationstyp des Kommissioniersystems angepasstes Format, • die F¨ uhrung der Kommissionierer durch Zuweisung von Entnahmeort und -menge und • die Kontrolle des Prozessablaufes. Kundenauftragserfassung Die Aufnahme der Kundenauftr¨age muss sicher und eﬃzient erfolgen und gleichzeitig dem Kunden ein hohes Maß an Service bieten. Nicht zuletzt daraus leiten sich die Anforderungen an die Erfassung ab: • Angebot einer Auswahl an Auftragserteilungsm¨oglichkeiten (telefonisch, ¨ Internet), per Fax, DFU, • Zeitpunkt der Auftragserteilung dem Kundenwunsch entsprechend (=beliebiger Zeitpunkt), • direkte Auskunft der Artikelverf¨ ugbarkeit und eines m¨oglichen Liefertermins, • M¨ oglichkeit der Beratung, • gegebenenfalls Erfassung von Sonderw¨ unschen. Demgegen¨ uber steht die Zielsetzung einer kosteneﬃzienten und fehlerresistenten Auftragsannahme. Dabei gilt es insbesondere aus Kapazit¨atsgr¨ unden ausgepr¨ agte Eingangsspitzen zu vermeiden. Bei beratungsunkritischen Produkten werden daher zunehmend Dienstleister (Call-Center) einbezogen. Im Bereich der Gesch¨ aftskunden bietet sich die Einrichtung fester Abruftermine f¨ ur Bestellungen an, die regelm¨ aßig erfolgen. Der Datenaustausch erfolgt in den meisten F¨ allen u ¨ber internetbasierte Dienste. Einen kritischen Einﬂuss besitzt bei allen verschiedenen Erfassungskan¨alen die aktuelle Verf¨ ugbarkeit lieferbarer Artikel. Dazu ist eine pr¨azise und schnelle Bestandsf¨ uhrung elementare Voraussetzung. Die Kundenauftragserfassung ist typischerweise eine Funktion des Warenwirtschaftssystems (WWS), nicht jedoch des WMS. Allerdings greift auch das WWS auf die aktuelle und zeituck. nahe Bestandsverwaltung zur¨ Auftragsaufbereitung Die erfassten Kundenauftr¨age sind zur Durchf¨ uhrung einer eﬃzienten Kommissionierung, mit wenigen Ausnahmen bei sehr

44

2. Lagersysteme und Lagerverwaltung

kleinen Systemen, ungeeignet. In Abh¨ angigkeit vom gew¨ahlten Organisationstyp der Kommissionierung fallen folgende T¨atigkeiten an: • Vervollst¨ andigen der Auftr¨ age mit den zur Kommissionierung relevanten Informationen (Lagerort, Artikelnummer, Sammelbeh¨alter), • Sortieren der Positionen in der Reihenfolge der Anordnung im Regal, • Zerlegen der Auftr¨ age in Teilauftr¨ age, die in verschiedenen Zonen abgearbeitet werden, • Zusammenf¨ uhren der Auftr¨ age zu einem gemeinsam abzuarbeitenden Auftragsstapel, • Filterung von Auftr¨ agen mit gleicher Priorit¨at, Versandart oder gleichem Zieltermin, • Filterung von Auftr¨ agen unterschiedlicher Behandlung (z. B. EinpositionenAuftr¨ age). Informationsmanagement Kommissioniererf¨ uhrung In praktisch jedem Kommissioniersystem gelangt der Mensch, h¨ auﬁg durch Technik unterst¨ utzt, als Kommissionierer zum Einsatz. Im Folgenden soll die F¨ uhrung von Menschen zur Durchf¨ uhrung der Kommissionierung im Vordergrund stehen. Der Einsatz automatischer Kommissioniersysteme konzentriert sich dagegen auf bestimmte Sortimentsbereiche, in denen die speziellen Vorteile automatischer Systeme genutzt werden k¨onnen. Beim Einsatz automatischer Systeme sind in jedem Fall spezialisierte, an das System angepasste Steuerungen erforderlich. ¨ Die Hauptaufgabe der Kommissioniererf¨ uhrung ist die Ubermittlung der relevanten Entnahmeinformationen mit der generellen Zielsetzung einer maximalen Kommissionierleistung und der Minimierung m¨oglicher Pickfehler. Die Verfahren der Weitergabe der Entnahmeinformationen an die Kommissionierer lassen sich grunds¨ atzlich in papier- oder belegbehaftete Verfahren und papier- oder beleglose Verfahren unterscheiden. Fehlerhafte Kommissionervorg¨ ange untergraben nicht nur das Vertrauen der Kunden in die logistische Leistungsf¨ ahigkeit des Lieferanten, sie bedeuten in der Regel auch erhebliche ﬁnanzielle Verluste und stellen dadurch eine kritische Systemgr¨ oße dar. Um die Fehler zu reduzieren, erfolgt eine Kontrolle an verschiedenen Punkten entlang des Kommissionierprozesses. Es bieten sich verschiedene Verfahren der Kontrolle des Kommissioniervorganges an, die im Wesentlichen von der eingesetzten Form der Kommissioniererf¨ uhrung bestimmt werden. Neben der Vermeidung von Kommissionierfehlern sollen durch diese Maßnahmen der Systemstatus und die abgeschlossenen Auftr¨age erfasst werden, um darauf aufbauend Folgeauftr¨ age einzuschleusen. Deshalb wird dieser Pr¨ ufvorgang auch als Quittierung des Auftrags bzw. der Entnahmeeinheit bezeichnet.

2.2 Funktionen in Lagersystemen

45

Kommissioniererf¨ uhrung mit Pickliste Die papierbehaftete Version stellt die klassische L¨ osung der Kommissioniererf¨ uhrung dar. Der Kommissionierer erh¨ alt einen Papierbogen mit den Entnahmeinformationen. Die Pickliste ist prinzipiell f¨ ur alle Kommissionierverfahren einsetzbar, bei Verfahren mit automatischer Unterst¨ utzung (automatisch gesteuerte Ware-zur-PersonSysteme) ist der Einsatz jedoch wenig sinnvoll, da die Informationen zur Steuerung der Anlagen (z. B. horizontale oder vertikale Umlaufregale) ohnehin elektronisch aufbereitet vorliegen. Entscheidend f¨ ur die Kommissionierleistung ist die Reihenfolge der Entnahmeinformationen auf der Liste. Diese sollte der Reihenfolge der Artikel in der Regalzeile entsprechen. In gr¨ oßeren Systemen mit volumen- und wegoptimierter Anordnung der Entnahmeeinheiten ist die Pickliste gegen¨ uber dem Auftragseingang, der typischerweise kunden-, alphabetisch- oder artikelnummerorientiert erfolgt, zu reorganisieren. Diese Funktionalit¨at kann sinnvoll nur durch rechnergest¨ utzte Verwaltungssysteme erfolgen. Bei zonenparalleler Kommissionierung muss die Ursprungsliste zwangsl¨auﬁg in mehrere Teillisten umgesetzt werden. Vorteilhaft bei der Pickliste ist sowohl die relativ g¨ unstige Vorbereitung und Ausfertigung als auch die einfache Umsetzung des Prinzips. In geeigneten F¨ allen k¨ onnen auch Nebenfunktionen ausgef¨ uhrt werden. Eine g¨angige Anwendung ist die Pickliste in Form von Klebeetiketten (Labeln), bei der die Entnahmeeinheiten mit verschiedensten Informationen (u. a. auch Preisauszeichnung) versehen werden k¨ onnen. Dadurch k¨onnen wiederum Arbeitsschritte eingespart werden. Eine Selbstkontrolle des Kommissionierers wird oft durch Abhaken der einzelnen Positionen einer Pickliste und die Quittierung beispielsweise durch Abzeichnen der abgeschlossenen Kommissionierliste realisiert. Eine weitere Kontrolle bei der Kommissionierung mit Pickliste l¨asst sich aber nur durch nachfolgende 100%-Kontrolle des komplettierten Kundenauftrags vornehmen. Papierlose F¨ uhrung und Kontrolle des Kommissioniervorganges Nachteile der Pickliste bestehen in dem hohen Totzeitanteil zur Identiﬁzierung der n¨ achsten Entnahmeposition und dem Handling der Liste und insbesondere in der großen Inﬂexibilit¨ at. Die Vorbereitung und der Ausdruck ¨ der Listen ben¨ otigen nicht reduzierbare Grundzeiten, kurzzeitige Anderungen sind praktisch nicht durchf¨ uhrbar. Dies zeigt sich insbesondere bei auftretenden Fehlmengen, die gemeldet und manuell verarbeitet werden m¨ ussen. Aus diesen Gr¨ unden ist die Pickliste bei Verfahren, die eine sehr schnelle Adaption des Kommissionierverhaltens auf wechselnde Systemzust¨ande erfordern (dazu z¨ ahlen dynamische Batchsteuerungsverfahren in der zweistuﬁgen Kommissionierung), nicht einsetzbar.

46

2. Lagersysteme und Lagerverwaltung

Tabelle 2.8. Papierlose Verfahren der Kommissioniererf¨ uhrung Bezeichnung

Funktion

Mobiles Terminal

Der Kommissionierer erhält die Entnahmeinformation online (via Infrarot oder Funk), in anderern Fällen auch offline (via Dockingstations), visuell über LCDAnzeigen oder akustisch (Pick-by-Voice).

Stationäres Terminal

Festinstallierte Monitore zeigen (online) die Entnahmeinformationen an; häufiger Einsatz an zentralen Kommissionierstellen, z. B. an Ware-zur-Person Kommisionierstationen.

Pick-by-Light

Optische Anzeigen an Regalfläche zeigen die anzusprechenden Bereitstellungseinheiten und die jeweils zu entnehmende Menge an; häufiger Einsatz an Durchlauf- oder Fachbodenregalen.

Daher kommen alternativ zur Pickliste verschiedene papierlose Verfahren zum Einsatz (s. Tabelle 2.8). Diese Online-Verfahren bieten die M¨oglichkeit der Erfassung des Bearbeitungsfortschrittes und so die Grundlage zur Anpassung der Auftragssteuerung an das Systemverhalten (Systemlast und -kapazit¨ at). Außerdem sind Bestandsabweichungen unmittelbar erfassbar (vgl. Abschn. 2.3.5) und k¨ onnen kurzfristig in den Kommissionierprozess eingeplant werden. Die papierlosen Verfahren bieten bessere M¨oglichkeiten der Quittierung eines Auftrags. Sofern die Weitergabe der Entnahmepositionen jeweils einzeln erfolgt4 , l¨ asst sich jede Entnahmeeinheit oder jede Position separat u ufen bzw. quittieren. Allerdings ist auch der damit verbundene Zeit¨berpr¨ aufwand zu beachten, der insbesondere bei der Quittierung der einzelnen Entnahmeeinheit sehr hoch ist. Ein klassisches Problem besteht bei der Pickby-Light-Kommissionierung indes darin, dass Kommissionierer in der Praxis dazu tendieren, die Quittierungstaste vor dem Pick zu bet¨atigen, woraus Z¨ahlfehler resultieren k¨ onnen. Durchaus weitergehende Kontrollm¨ oglichkeiten bieten Terminal-basierte Verfahren. Verschiedene Pr¨ ufungen erfolgen durch Einsatz von BarcodeHandscannern, mit denen beispielsweise die Fachnummer oder auch jede Entnahmeeinheit gescannt werden muss. Pick-by-Voice-Systeme fragen analog Pr¨ ufnummern ab, die der Kommissionierer sprechen muss. Solche Pr¨ ufverfahren sind in erster Linie Hilfen f¨ ur den Kommissionierer und k¨ onnen die Einweisung, Mitwirkung und Motivation der Mitarbeiter nicht ersetzen. Trotz unterschiedlicher Kontrollm¨oglichkeiten ist die Ableitung unmittelbarer Zusammenh¨ ange auf die Fehlerresistenz bei unterschied¨ lichen Ubermittlungsverfahren nicht m¨ oglich. Einer aktuellen Untersuchung 4

Dies geschieht zwangsl¨ auﬁg bei Pick-by-Voice und den meisten mobilen Terminals; Verfahren wie Pick-to-Light erm¨ oglichen die Weitergabe einzelner oder mehrerer Kommissionierpositionen.

2.2 Funktionen in Lagersystemen

47

Tabelle 2.9. Durchschnittliche Fehlerraten unterschiedlicher Kommissioniersysteme nach [33] Technisches Hilfsmittel

Durchschnittliche Fehlerquote

Pick-by-Voice

0,08%

Beleg

0,35%

Etiketten

0,37%

Pick-by-Light

0,40%

mobile Terminals

0,46%

mobile Terminals und Etiketten

0,94%

der Kommissionierfehler zufolge ist die Kommissionierung per Pickliste ( Be” leg“) grunds¨ atzlich nicht ung¨ unstiger als andere Verfahren ([33] und Tabelle 2.9). ¨ Ubliche Auspr¨ agungsformen in der Kommissionierung Der Grundtyp der Kommissionierung ist in Abb. 2.5 dargestellt. Der Kommissionierer bewegt sich mit einem Wagen entlang der Regalfront (Durchlauf-, Paletten- oder Fachbodenregal) und greift die Einheiten entsprechend den Entnahmeinformationen einer Pickliste. Auf dem Wagen werden ein oder mehrere Auftragsbeh¨ alter mitgef¨ uhrt, die zur Aufnahme der getrennt nach Kundenauftrag kommissionierten Einheiten dienen. Ausgehend von einer Basisstation B, an der leere Kundenauftragsbeh¨ alter und die Pickliste(n) aufgenommen werden, beginnt der Kommissionierer den Rundgang und u ¨ bergibt nach abgeschlossenem Rundgang die gef¨ ullten Beh¨alter an der Schnittstelle zum Versand. Dabei bewegt er sich schleifen- oder m¨aanderf¨ormig durch die Regalanordnung (Schleifenstrategie). Je nach Pickliste k¨onnen auch einzelne Gassen u ¨bersprungen oder die Gassen nur zu einem Teil begangen werden (Stichgangstrategie). Entsprechend der zuvor deﬁnierten Terminologie liegt damit eine einstuﬁge, auftragsparallele Kommissionierung nach dem Personzur-Ware-Prinzip mit eindimensionaler Fortbewegung des Kommissionierers vor. Die Bereitstellung ist statisch-dezentral und die Abgabe der Kommissioniereinheiten statisch-zentral. Bei sehr großen Sortimenten bietet sich alternativ die in Abb. 2.6 dargestellte Variante an. W¨ ahrend der prinzipielle Ablauf gleich der zuvor vorgestellten Variante ist, ﬁndet die Kommissionierung nun in der Regalﬂ¨ache

48

2. Lagersysteme und Lagerverwaltung

B

A b g a b e Abbildung 2.5. Einstuﬁges Kommissioniersystem Person-zur-Ware

eines Hochregals statt. Dadurch ergibt sich eine bessere Raumnutzung und im Allgemeinen ein geringerer Wegzeitanteil durch die h¨ohere Bewegungsdynamik des Kommissionierstaplers oder Regalbedienger¨ates und damit eine h¨ohere Kommissionierleistung. Ein elementarer leistungsbestimmender Faktor ist die Gestaltung der Fachreihenfolge, in der die Entnahmepositionen angefahren werden. Es existieren verschiedene Verfahren dieser so genannten ¨ Tripoptimierung, die in Kapitel 4 behandelt werden. Ublicherweise erfolgt die Kommissioniererf¨ uhrung dabei durch ein auf dem Bedienger¨at installiertes Terminal. In Abb. 2.7 sind zwei g¨ angige Systeme f¨ ur das Prinzip Ware-zur-Person dargestellt. Im ersten Fall (Abb. 2.7, a) steht der Kommissionierer an der Stirnseite eines Automatischen Kleinteilelagers (AKL). Die artikelreinen Beh¨ alter werden u ormige F¨ ordertechnik (Rollen- oder Kettenf¨or¨ber eine U-f¨ derer) zur Entnahme bereitgestellt. Die Anordnung wird als KommissionierU bezeichnet. Im zweiten Beispiel (Abb. 2.7, b) beﬁndet sich der Kommissionierer an der Stirnseite eines horizontalen Umlaufregales, bei dem die gew¨ unschten F¨ acher zur Entnahme an der Stirnseite positioniert werden. Oftmals werden dabei mehrere Umlaufregale (typischerweise 2-4) durch einen

2.2 Funktionen in Lagersystemen

49

Abbildung 2.6. Person-zur-Ware im Hochregal

Kommissionierer gleichzeitig bedient. Die Bereitstellung erfolgt in diesen F¨allen zentral-dynamisch, die Abgabe von Entnahme- und Kommissioniereinheit zentral-statisch. Zur Kommissionierf¨ uhrung werden u ¨blicherweise station¨ are Terminals genutzt. Die Systeme k¨ onnen sowohl in einstuﬁgen als auch in zweistuﬁgen Kommissioniersystemen eingesetzt werden. Im vierten Beispiel (s. Abb. 2.8) ist ein zweistuﬁges Kommissioniersystem dargestellt. Die Kommissionierung erfolgt an Durchlaufregalen. Nachschub und Entnahme der Einheiten sind in diesem Fall zwangsl¨auﬁg getrennt. Der Kommissionierer erh¨ alt u ¨ber ein Pick-by-Light-System die Entnahmeinformationen. Die entnommenen Einheiten werden direkt an ein F¨orderband oder Rollenf¨ orderer u ¨bergeben (Pick-to-Belt). Die Entnahme erfolgt somit

50

2. Lagersysteme und Lagerverwaltung

a )

b )

Abbildung 2.7. Einstuﬁges Kommissioniersystem Ware-zur-Person

dezentral-statisch, die Abgabe der Entnahmeeinheit dezentral-dynamisch. Die entnommenen Einheiten werden in der zweiten Stufe auf einen Sortierkreislauf gef¨ ordert und auf Kundenauftr¨ age verteilt. Eine Umkehrung des herk¨ ommlichen Kommissionierablaufs stellt das Beispiel in Abb. 2.9 dar. W¨ ahrend im herk¨ ommlichen Fall Waren aus einem Regal entnommen und zur Abgabe transportiert werden, sind in diesem Fall in einem Regal Kundenauftragsbeh¨ alter angeordnet. Artikelreine Beh¨alter werden aus einem entfernten Lagerbereich zum Entnahmeplatz transportiert und zur Entnahme bereitgestellt (dezentral-dynamische Bereitstellung). Die Abgabe erfolgt in die im Regal beﬁndlichen Kundenauftragsbeh¨alter, die nach Vervollst¨ andigung des Auftrags durch weitere Mitarbeiter zum Versand bef¨ ordert werden (statisch-dezentrale Abgabe der Entnahmeeinheit und statisch-zentrale Abgabe der Kommissioniereinheit). Das Verfahren wird als Inverse Kommissionierung bezeichnet und ﬁndet in den letzten Jahren insbesondere im e-Commerce-Bereich zunehmend Bedeutung (sehr großes Sortiment und viele kleine Auftr¨age). Gelangt eine optische F¨ uhrung der Kommissionierer zum Einsatz, wird das Prinzip auch als Pick-to-Light oder Put-to-Light bezeichnet. Nachschubsteuerung Die Verf¨ ugbarkeit der Artikel an den Entnahmestellen ist von entscheidender Bedeutung f¨ ur einen reibungslosen und schnellen Ablauf in der Kommissionierung. Insbesondere in batchorientierten Kommissioniersystemen k¨onnen

2.2 Funktionen in Lagersystemen

51

Abbildung 2.8. Zweistuﬁges Kommissioniersystem mit Sorter

erforderliche Nachkommissionierungen zu Verz¨ogerungen einer Vielzahl von Auftr¨ agen, respektive zu unvollst¨ andigen Einzelauftr¨agen f¨ uhren. Daher ist ¨ die Uberwachung der Bereitstellmengen und die rechtzeitige Ausl¨osung des Nachschubes ein wichtiger Faktor im Kommissionierablauf. 2.2.6 Verpackung In Bereich der Verpackung werden die bereitgestellten oder kommissionierten G¨ uter nach bestimmten Kriterien zusammengef¨ uhrt, auf Vollst¨andigkeit gepr¨ uft, f¨ ur anstehende Transportvorg¨ ange verpackt und schließlich dem Versand zugef¨ uhrt. In gr¨ oßeren Lagersystemen setzen sich Kundenauftr¨age u ¨blicherweise aus Teilmengen unterschiedlicher Lagerbereiche zusammen. Da eine sekundengenaue Zusammenf¨ uhrung solcher Teilmengen f¨ ur den Versand in der Regel nicht m¨ oglich ist, wird in einem ersten Schritt eine Auftragszusammenf¨ uhrung durchgef¨ uhrt, um die Transport-/Versandeinheiten zu bilden. Dieser Prozess wird oftmals durch Auftragssortierpuﬀer (hochdynamische Puﬀerl¨ager) wie beispielsweise Durchlaufregale (vgl. Abschn. 3.1.3) oder Beh¨alter-Umlaufregale (vgl. Abschn. 3.1.3) technisch unterst¨ utzt.

52

2. Lagersysteme und Lagerverwaltung

A K L

V e rs a n d

Abbildung 2.9. Inverse Kommissionierung

Im Hinblick auf eine Versandkostenoptimierung m¨ ussen Sendungen u. a. volumenoptimiert gebildet werden. Viele Unternehmen setzen bei diesem Schritt auf die F¨ ahigkeiten und die Erfahrung des Packpersonals, f¨ ur eine vorliegende Verpackungsmenge die richtige Verpackungseinheit (z. B. Kartongr¨ oße) zu bestimmen. In der Praxis ist jedoch h¨auﬁg auch ein mehrfaches Umpacken zu beobachten, das entsprechend ineﬃzient ist. Daher wird eine solche Funktionalit¨ at auch zunehmend in WMS integriert, die, basierend auf einer Volumenberechnung des Kundenauftrags, geeignete Versandgr¨oßen ermitteln. Insbesondere bei umfangreicheren Verpackungs- und Ladeeinheitenbildungsprozessen ist der Mensch schnell u ¨berfordert. Auf dem Markt wird eine Reihe von rechnergest¨ utzten Optimierungswerkzeugen, beispielsweise zur Packmustergenerierung bei Palettierungsaufgaben, angeboten. Schließlich erfolgt bei diesem Schritt eine Warenausgangspr¨ ufung mit der Pr¨ ufung auf Vollst¨ andigkeit des Kundenauftrags und auf Qualit¨at und Beschaﬀenheit der Transport-/Versandeinheiten. Hilfreich ist dabei oftmals eine Konsolidierung und Pr¨ ufung der Kommissionierung durch Erfassung des Auftragsgewichtes als Summe der Artikel- bzw. Positionsgewichte. Dies setzt allerdings hinreichend genaue Artikelstammdaten sowie ein ann¨ahernd homogenes Gewichts- und Artikelspektrum voraus. Informationstechnisch erfolgt abschließend die Aktualisierung des Auftragsstatus mit der Fortschreibung des Status des Auslagerauftrags und gegebenenfalls eine Erg¨ anzung der transport- und versandtechnischen Daten.

2.2 Funktionen in Lagersystemen

53

2.2.7 Versand Oberﬂ¨ achlich betrachtet, besteht die Aufgabe des Versands lediglich in der Zusammenstellung der Versandeinheiten entsprechend den Auftr¨agen und der Verladung der Waren in ein Transportmittel. Abgesehen von den physischen Abl¨ aufen in der Versandzone geh¨ort zur Durchf¨ uhrung dieser T¨ atigkeiten auch eine Reihe an Organisations- und Kontrollfunktionen. Sofern noch nicht durch den Auftrag vorgegeben, ist zun¨achst die optimale Versandart bzw. das Transportmittel zu bestimmen. Dieser Prozess ist durch die Verschiedenheit der Preisgestaltung der Spediteure und KEP-Dienstleister nicht trivial. Eine kostenoptimierte Versandformwahl setzt daher eine genaue Recherche der Versandmengen (Volumina und Gewichte) und der Transportziele sowie -frequenzen voraus. Auf dieser Basis lassen sich dann die optimalen Transportdienstleister f¨ ur einzelne Transportauftragstypen bestimmen. Im gleichen Schritt sind auch Touren zu planen, wobei f¨ ur den jeweiligen Kundenauftrag die Dringlichkeit der Lieferung, die Verf¨ ugbarkeit der bestellten Waren, zuvor verhandelte Lieferfrequenzen usw. zu ber¨ ucksichtigen sind. Je nach Lagerform variieren die Anforderungen dabei erheblich und sind in die Strategien einzubeziehen. W¨ ahrend die vorgeschalteten Lager- und Kommissionierbereiche im Allgemeinen durch eine gleichm¨ aßige Auslastung gekennzeichnet sind, konzentriert sich die Verladung in Transportmittel oft auf relativ kurze Zeitfenster, was beispielsweise durch nachgeschaltete Konsolidierungen der Ladungen in Hubs bedingt ist. So ergeben sich typischerweise verschiedene Arbeitscharakteristiken von Zu- und Ablauf, die durch die Versandzone ausgeglichen, d. h. gepuﬀert werden m¨ ussen. Dazu sind vor der Verladung die Versandkommissionen zusammenzustellen und f¨ ur die Verladung bereitzuhalten. Beim Versand palettierter oder anderer gr¨oßerer Einheiten werden die Ladungen g¨ angigerweise auf Bodenstellpl¨ atzen vor den Versandtoren bereitgestellt. Daneben kommen beim St¨ uckgutversand kleinerer Einheiten auch hochdynamische Lagertechniken (s. bspw. Abschn. 3.1.3) zum Einsatz. Die Raumsituation an den Versandtoren ist in der Praxis wiederum ein klassischer Engpass, so dass die Organisation der Versandzone eine kontinuierliche Optimierung erfordert. Zur Verladung sind schließlich Transport-/Versandpapiere (tourenbezogene Ladelisten, Frachtdaten) zu erstellen. Durch eine Scannung der verladenen Einheiten kann die Transparenz der Lieferkette sichergestellt werden. Damit wird der Auftragsabschluss quittiert und die R¨ uckmeldung an die Auftragsverwaltung bzw. das Auftragsmanagement garantiert.

54

2. Lagersysteme und Lagerverwaltung

Tabelle 2.10. Lagertypendeﬁnitionen

Bezeichnung

Parameter

Lagerort

Plätze, Fächer, Kanäle, . . .

Zugriffsart auf einzelne Lagerplätze

wahlfrei, Stack, LIFO, FIFO, . . .

Art der Abarbeitung

automatisch – manuell

Durchführung der Lageroperation

Definition geeigneter Lagergeräte (Tragfähigkeiten, Aufnahmekapazität, Reichweite, Rechte)

2.3 Warehouse Managementsystem 2.3.1 Lagerverwaltung Die Lagerverwaltung stellt die ureigenste Funktion eines Warehouse Managementsystems dar. Sie f¨ uhrt einerseits Buch u ¨ ber das vorhandene Lagerungspotenzial, d. h. die Speziﬁkation der vorhandenen Lagerpl¨atze eines Lagersystems (Platzverwaltung), und andererseits u ¨ber die in diesem System gelagerten Einheiten (Mengenverwaltung/Bestandsverwaltung). Dar¨ uber hinaus sollte f¨ ur eine kontinuierliche Lageroptimierung sinnvollerweise eine Reihe von Kontrollfunktionen integriert sein. Lagertypenverwaltung W¨ ahrend im Fall eines manuell gef¨ uhrten Lagersystems die Bediener durch ihr Erfahrungswissen und ihre Entscheidungskraft selbstst¨ andig in der Lage sind, geeignete F¨order- und Lagermittel auszuw¨ ahlen bzw. einzusetzen, muss beim Einsatz automatischer Lagerverwaltungssysteme eine Zuweisung der Kompatibilit¨at einzelner Elemente eines Lagersystems erfolgen. Ebenso werden durch den manuellen Bediener verschiedene Prozesse intuitiv richtig ausgef¨ uhrt. F¨ ur ein automatisches System ist die Reihenfolge der Bearbeitung, beispielsweise bei der Entleerung oder Bef¨ ullung eines Lagerkanals nach dem FIFO-Prinzip, nicht aus der Arbeitsanweisung unmittelbar herauszulesen. Verschiedene Funktionen der Lageroptimierung ben¨otigen dar¨ uber hinaus die M¨ oglichkeit der selbstst¨ andigen Generierung von Auftr¨agen, beispielsweise zur Deﬁnition von Umlagerauftr¨ agen zur Zugriﬀszeitoptimierung, und damit auch die Kenntnis der richtigen Betriebsweise von Ein- und Auslagerungsverfahren.

2.3 Warehouse Managementsystem

55

Als Basis f¨ ur solche Optimierungsverfahren ben¨otigt ein automatisches System daher eine stringente Klassiﬁzierung der Lager- und F¨ordertechnik aus informationstechnischer Sicht. Dazu sollten die in Tabelle 2.10 gelisteten Lagertypen deﬁniert werden. Lagerplatzverwaltung Die Lagerplatzverwaltung ist zun¨achst das Abbild der technischen Lagerstruktur, d. h. die auf der realisierten Lagertechnik (z. B. Regalf¨ acher) basierende Speziﬁkation des Lagerplatzes mit Beschreibung der Lagerplatzdimension, -tragf¨ ahigkeit und Ortsangabe (z. B. Fachkoordinaten). Bei bestimmten Lagerplatzvergabestrategien (vgl. Abschn. 2.2.2) ist eine solche pr¨ azise Beschreibung der Lagerpl¨ atze eine wesentliche Betriebsvoraussetzung. Bei ﬂexibel nutzbaren Lagerformen (z. B. Bodenlagerﬂ¨achen) reduziert sich die Angabe ggf. auf eine Speziﬁkation der Fl¨achen und Koordinaten. Gleichzeitig umfasst die Lagerplatzverwaltung die Verwaltung der an einem Lagerplatz gelagerten Einheiten. Dazu geh¨oren die Aufnahme der warenspeziﬁschen Daten wie Artikelkennzeichnung (Artikelnummer oder Ladeeinheitennummer) und die Registrierung und Fortschreibung der je Lagerplatz gelagerten Mengen. F¨ ur die steuerungstechnische Umsetzung sowohl von Einlagerungen als auch Auslagerungen werden Statusangaben ben¨otigt. Bei Festlegung des Einlagerplatzes am Identiﬁkationspunkt muss einerseits die Verf¨ ugbarkeit eines Lagerplatzes bekannt sein, andererseits muss sichergestellt werden, dass von der Zuweisung des Lagerplatzes bis zum Abschluss der Einlagerung der Platz nicht doppelt vergeben wird. Zu diesem Zweck werden dem Lagerplatz verschiedene Stati zugewiesen, die einen Platz f¨ ur bestimmte Operationen sperren bzw. f¨ ur bestimmte Artikel oder Auftr¨ age reservieren. Auch im Falle der Auslagerung muss bekannt sein, ob eine bestimmte Einheit eines Artikels verf¨ ugbar ist. Um sicherzustellen, dass die ausgew¨ahlte Ladeeinheit eines Artikels dem aktuellen Auftrag zugewiesen wird, ist der Status des Artikels an den Auftrag zu binden. Die wichtigsten Stati von Lagerpl¨ atzen und Ladeeinheiten sind in Tabelle 2.11 zusammengefasst. Neben der Realisierung der Ein-/Auslagerfunktionalit¨at ist das Sperren von Best¨anden bzw. das Setzen von Sperrkennzeichen eine elementare Verwaltungsfunktion, die bei unterschiedlichsten Operationen Verwendung ﬁndet. Hierbei lassen sich insbesondere • Sperren zur Ein-/Auslagerung und • Sperren f¨ ur bestimmte Lageroperationen (z. B. Umlagerungen empﬁndlicher G¨ uter vermeiden) unterscheiden. Die Auﬂistung aller im Lager belegten Pl¨atze, also das Abbild des momentanen Lagerzustandes, wird als Lagerspiegel bezeichnet. Der Lagerspiegel kann auch um die Art und Menge der pro Lagerfach vorhandenen Artikel erg¨ anzt sein.

56

2. Lagersysteme und Lagerverwaltung

Tabelle 2.11. Statusangaben zur Steuerung von Ein- und Auslagerung (Auszug) Bezeichnung

lagerplatzbezogen

ladeeinheitenbezogen

disponibel

Auf den Lagerplatz kann beliebig zugegriffen werden.

Auf den Artikel kann beliebig zugegriffen werden.

reserviert

Der Lagerplatz ist für eine bestimmte Ladeeinheit zur Einlagerung reserviert.

Der Artikel ist für einen später zu bearbeitenden Auftrag reserviert. Die Reservierung erfolgt idealerweise mit einer Referenz auf den Auftrag.

gesperrt

Der Lagerplatz ist für zukünftige Einlagerungen gesperrt (beispielsweise wegen Wartungsarbeiten).

Der Artikel ist aus bestimmtem Grund (Verfalldatum abgelaufen, Artikel liegt in Quarantäne) für den Zugriff oder nur für bestimmte Operationen (z. B. Umlagerungen) nicht freigegeben.

Mengenverwaltung (Bestandsf¨ uhrung) Eine andere logische Betrachtung erfolgt durch die Mengenverwaltung und Bestandsf¨ uhrung. Kernpunkt dabei ist die Registrierung und Aktualisierung der pro Artikel gelagerten Mengen insgesamt, ggf. unter Ber¨ ucksichtigung der relevanten Stati (s. Tabelle 2.12). Die Verwaltung der Waren nach unterschiedlichen Kriterien (Min./Max.-Bestand) soll die Versorgungssicherheit gew¨ahrleisten und ¨ ¨ Ubermengen vermeiden. Dazu sind bei Uberoder Unterschreiten vorgegebener Grenzen Meldungen auszul¨ osen oder Aktionen (Bestellungen, Umlagerungen etc.) zu initiieren. ¨ Diese Funktion erfordert aber auch in besonderem Maß die Uberwachung ¨ des Lagergutes. Dazu z¨ ahlen die Uberwachung der zul¨assigen Lagerdauer und das Sperren des Artikels bei Erreichen eines bestimmten (Verfall-)Datums. Unter bestimmten Voraussetzungen ist in solchen F¨allen eine Auslagerung zum Schutz anderer Lagerg¨ uter zu initiieren. Der wesentliche Unterschied zu einem Warenwirtschaftssystem (WWS), in dem z. T. ¨ ahnliche Funktionen liegen, besteht in der speziﬁschen Lagersystemsicht des WMS im Gegensatz zur Kunden- und Vertriebssicht des WWS. So verf¨ ugt ein Lagerverwaltungssystem im Allgemeinen nicht u ¨ber Kundendaten oder Preise. Gleichwohl erfordert ein funktionierendes Gesamtsystem einen kontinuierlichen Austausch zwischen WMS und WWS. ¨ ¨ Uberwachung von Umweltparametern Die Uberwachung der Lagerbedingungen (Temperatur und Feuchtigkeit) und der Sicherheit (Zugangskontrolle) stellt eine besondere Funktion dar, die nur in wenigen F¨allen ausgepr¨ agt erforderlich ist.

2.3 Warehouse Managementsystem

57

Tabelle 2.12. Bestandsklassen Bezeichnung

Bedeutung

physischer Bestand

im Lagersystem vorhandene Einheiten

verfügbarer Bestand

Lagerbestand unter Berücksichtigung gesperrter oder reservierter Mengen = Bestand an disponiblen Einheiten

reservierter Bestand

mit Sperrkennzeichen versehener Bestand

Fehlmengen

offene (ausstehende) Eingangslieferungen, für die bereits ein Auftrag besteht

Gruppierungen Im Lagerbetrieb fallen regelm¨aßig Aufgaben an, die sich jeweils auf ganze Gruppen von Lagereinheiten, Artikeln, F¨achern usw. beziehen. Zu diesem Zweck sollte ein Warehouse Managementsystem die ﬂexible Zuweisung von Gruppierungen erm¨ oglichen, um eine aufw¨andige Bearbeitung der einzelnen Elemente zu umgehen. Solche Aufgaben fallen beispielsweise an bei • der Wartung, Reparatur oder dem Ausfall einzelner Gassen automatischer Regalanlagen, • der Waren¨ uberwachung (z. B. besondere Verfahrensmaßnahmen bei gef¨ahrlichen oder hochwertigen Waren), • der Lagerung gesperrter Waren (z. B. Quarant¨ane-Lagerung), • der Auswahl einer gr¨ oßeren Warenmenge oder • Inventurverfahren. Idealerweise sollten sich derartige Gruppierungen sehr ﬂexibel setzen lassen. In jedem Fall sollte die Gruppierung von • Lagerorten (nach Lagergasse, Lagerzone etc.), • Artikelgruppen (nach Typengruppe, Artikelnummer etc.) sowie • Chargen m¨oglich sein. Konsequenterweise sollte dann auch die Anwendung entsprechender Verwaltungsfunktionen (Sperren, Reservierungen, Ein-/Auslagerungen) auf die gesamte Gruppe anwendbar sein. 2.3.2 Reorganisation In regelm¨ aßigen Abst¨ anden ist es erforderlich, ein laufendes Lager- und Distributionssystem auf Eﬃzienz zu u ufen und geeignete Schritte zur ¨ berpr¨

58

2. Lagersysteme und Lagerverwaltung

Optimierung durchzuf¨ uhren, was als Lagerreorganisation verstanden wird. Ausl¨ oser hierf¨ ur k¨ onnen sein: ¨ • Anderungen im Zugriﬀsverhalten auf einzelne Artikel, wie z. B. Absinken ¨ des Artikeldurchsatzes oder Anderung der typischen Entnahmeeinheiten, • an- oder auslaufende Vertriebsaktionen, • Ver¨ anderungen des Sortimentes, • Anwachsen der Menge angebrochener Lagereinheiten und der daraus resultierende schlechte Volumennutzungsgrad. Dies f¨ uhrt dazu, dass Lagerf¨ acher logisch falsch belegt sind (z. B. falsche ABC-Zonung), die mittleren Transportwege steigen und der Raumnutzungsgrad sinkt. Deshalb sollten die entsprechenden Kennzahlen kontinuierlich u ¨berwacht und analysiert werden. Die Frage der geeigneten Art und Weise der System¨ uberwachung wird in Abschn. 2.3.4 behandelt (S. 60, siehe dort). Zur resultierenden Systemoptimierung ﬁnden einige Maßnahmen Anwendung, die ebenfalls auch durch ein Warehouse Managementsystem unterst¨ utzt werden sollten: • Umbuchung, d. h. Neuzuweisung der Artikel in geeignete Zugriﬀsklassen und Lagerzonen, • Umlagerung bereits vorhandener Lagereinheiten in zugriﬀsschwachen Zeiten (z. B. zur Wiederherstellung einer ABC-Zonung), • Verdichtung angebrochener Einheiten oder schlecht ausgenutzter Mischpaletten (Auslagerung relevanter Einheiten, Umpacken der Lagereinheiten und Wiedereinlagerung gem¨ aß Speziﬁkation.). 2.3.3 F¨ ordermittelverwaltung und Leitsysteme W¨ ahrend automatische F¨ ordermittel u ¨ ber eine entsprechende Steuerung (Materialﬂussrechner, MFR bzw. MFC) gef¨ uhrt und u ¨berwacht werden, existieren f¨ ur manuell gef¨ uhrte Unstetigf¨ orderer (Stapler etc.) verschiedene Verfahren der Systemf¨ uhrung, von der manuellen Verwaltung bis zur automatischen Systemf¨ uhrung. Rechnergest¨ utzte Leitsysteme f¨ ur den innerbetrieblichen Transport werden innerhalb des Warehouse Managements aus unterschiedlichen Gr¨ unden eingesetzt: • zur Optimierung der Systemleistung (Reduzierung von Leerfahrten, Erh¨ohung der Umschlagleistung, Verbesserung der Systemnutzung), ¨ • Systemﬂexibilit¨ at bei kurzfristigen Anderungen (schnelle Reaktionen auf Transportanforderungen), • Systemzustands¨ uberwachung (Laufzeit von Fahrzeugen, Betriebskosten pro Fahrzeug etc.).

2.3 Warehouse Managementsystem

59

Umfassende Systeme zur Fahrzeugdisposition und -f¨ uhrung werden als Staplerleitsysteme (SLS) oder Transportleitsysteme (TLS) bezeichnet (s. [71]). Die Systeme bestehen aus einem rechnergest¨ utzten Leitstand oder Leitrech¨ ner, einem drahtlosen Ubertragungsmedium (Funk oder Infrarot) und mobilen Terminals auf den Fahrzeugen. Die eingehenden Transportauftr¨age bzw. -anfragen (Bedarfsanforderungen) werden aufbereitet, mit den relevanten Daten erg¨ anzt (z. B. Erg¨ anzung von Artikelnmummer oder -bezeichnung, Lagerort (Quelle), Zielort (Senke)) und anhand bestimmter Prozeduren und Strategien an die Fahrer u ¨ bermittelt. Bei allen Leitsystemen muss im ersten Schritt eine Festlegung getroﬀen werden, welche F¨ ordermittel f¨ ur einen bestimmten Auftragstyp grunds¨atzlich aufgrund ihrer Tragf¨ ahigkeiten, Hubh¨ ohen oder sonstigen Klassiﬁkationen geeignet und somit zuweisungsf¨ ahig f¨ ur einen Auftrag sind. Dazu muss analog zur Lagertypenverwaltung (vgl. Abschn. 2.3.1) eine Klassiﬁkation der vorhandenen F¨ ordermittel vorliegen. Ebenso sind Restriktionen sonstiger Einrich¨ tungen wie m¨ ogliche Ubergabestellen zu erfassen. Zur Fahrzeugdisposition existieren zwei grundlegende Verfahren: Dispatching Beim Dispatching (=Abfertigung) wird f¨ ur einen aktuell anstehenden Auftrag das geeignete F¨ ordermittel zugewiesen. Die Zuweisung erfolgt anhand unterschiedlicher Kriterien und Strategien. Dabei kann es sich beispielsweise um das • n¨ achste freie F¨ ordermittel, • r¨ aumlich n¨ achste beﬁndliche F¨ ordermittel oder das • F¨ ordermittel mit der k¨ urzesten Anschlussfahrt handeln. Da das Dispatching den jeweils n¨ achsten, freigegebenen Auftrag bearbeitet, reagiert das System schnell und ﬂexibel. Damit bietet sich das Verfahren bei dynamischen Umgebungen an. Scheduling Das Ziel des Scheduling (=Fahrplanung, Vorplanung) dagegen ist die Zuweisung mehrerer Auftr¨ age und/oder mehrerer F¨ordermittel zu einem idealen“ Fahrplan und somit auch die Erstellung einer opti” mierten Auftragsreihenfolge. Das Hauptziel liegt in der Optimierung der Systemleistung. Wesentliche Voraussetzung f¨ ur ein Scheduling ist dabei die Sammlung einer Reihe anstehender Auftr¨age in einem Auftragspool, aus dem heraus die optimale Verteilung erfolgen kann. Im Gegensatz zu einer manuellen Fahrplanerstellung, die im lagertechnischen Umfeld ohnehin nur in den seltensten F¨ allen einsetzbar ist, erfolgt das Scheduling wiederholt in relativ kurzen Abst¨ anden. In der praktischen Umsetzung wird in der Regel eine Mischform der beiden Verfahren eingesetzt, in der priorit¨ are Auftragsanforderungen jederzeit ber¨ ucksichtigt werden k¨ onnen. Neben solchen umfangreichen dispositiven F¨ uhrungssystemen existieren einfache Systeme zur reinen F¨ ordermittelverwaltung, bei denen die Erfassung des Systemzustandes im Vordergrund steht und keine auftragsdispo-

60

2. Lagersysteme und Lagerverwaltung

sitiven Zuweisungen erfolgen. Dazu z¨ ahlen die Erfassung der Betriebszeiten oder Reparaturkosten je Fahrzeug sowie die Batteriezustands¨ uberwachung und Kontrolle der Wartungsintervalle je Fahrzeug. In Systemen mit Nutzung der Fahrzeuge durch einen gr¨ oßeren Personenkreis bietet sich gegebenenfalls die Fahrzeugf¨ uhreridentiﬁkation und -dokumentation an. 2.3.4 Datenerfassung, -aufbereitung und -visualisierung Wie bereits in Abschn. 2.4 gezeigt, ist ein Lager- und Distributionssystem durch eine Vielzahl verschiedener Daten und Kennzahlen gepr¨agt, die zu unterschiedlichsten Zwecken Verwendung ﬁnden: • Leistungserfassung – Kundenbetreuung, – Fehlmengendokumentation aus Inventur – Erfassung von Kommissionierfehlern, Abweichungen an WA-Kontrolle – Eﬃzienz der Mitarbeiter (z. B. Picks oder Auftr¨age pro Kommissionierer; Einlagerungen pro Staplerfahrer; Wartezeiten pro Fahrzeug) ¨ • Ubersichtsinformationen – Lagerspiegel (Sortierung nach Lagerpl¨ atzen, frei/belegt, ...) – Lagerbestand – Lagerstatistiken (Umschlagh¨ auﬁgkeiten, St¨orungszeiten, F¨ ullgrad, ...) – Raumnutzung • Betriebsmittelstatistiken – Laufzeiten – Ausfallzeiten – Wartungs- und Reparaturkosten je Einheit • u. v. a. m. W¨ ahrend die personenbezogene Leistungserfassung in vielen F¨allen nicht unproblematisch ist und in der Regel die Einbeziehung des Betriebsrates erfordert, ist sie in einigen F¨ allen sogar unverzichtbare Basis f¨ ur die Leistungsabrechnung. Die gilt insbesondere f¨ ur die • Erfassung bei Akkordlohn, • Erfassung von Kontraktlogistikleistungen. Die Erfassung aussagekr¨ aftiger Statusinformationen ist die elementare Voraussetzung zur Steuerung und Optimierung des Distributionssystems. Im Bereich der Systemsteuerung m¨ ussen basierend auf diesen Daten Personalbedarfe (z. B. in Kommissionierbereichen) oder sonstige Ressourcenbedarfe ermittelt und eingeplant werden. Auslastungsgrade von F¨ordermitteln zeigen, ob parallel angeordnete Systeme im Gleichgewicht arbeiten. Wartezeiten an bestimmten Punkten k¨ onnen wiederum Engp¨asse anzeigen und eine ¨ Uberpr¨ ufung von Betriebsstrategien, Systemleistungen oder Personaleinsatz initiieren.

2.3 Warehouse Managementsystem

61

Entscheidend f¨ ur die Nutzung und erfolgreiche Verwertung der Daten ist das zugrunde liegende Erfassungsverfahren. Es existieren zwei prinzipielle Verfahren zur Ermittlung aussagekr¨ aftiger Daten und Kennzahlen: Online-Erfassung Die zur Generierung der ben¨otigten Daten erforderliche Datenbasis wird im Prozess erfasst und automatisch in die gew¨ unschte Kennzahl umgesetzt. Vorteilhaft ist dabei, dass die Kennzahlen unmittelbar zur Verf¨ ugung stehen. Demgegen¨ uber konzentriert sich die Erfassung und Auswertung auf die im Vorhinein zu deﬁnierende Fragestellung. Die nachtr¨ agliche Auswertung anderer oder verwandter Daten und Kennzahlen ist dagegen nicht in jedem Fall m¨ oglich. Ebenso liegt der Erfassungszeitraum weitgehend fest. Eine Zur¨ ucksetzung des Erfassungszeitraumes, um beispielsweise bestimmte Eﬀekte oder Zeitr¨aume auszublenden, ist nicht m¨ oglich, da als Ergebnis lediglich die aggregierte Kennzahl vorliegt. Insofern stellt dieses Verfahren ein statisches System dar. Zeitreihenerfassung Es wird zun¨ achst nur ein Logﬁle mit der Erfassung von Ereignissen und dem Eintrittszeitraum erstellt (Zeitreihe). Aus dem Logﬁle werden die Daten typischerweise in eine Datenbank u uhrt. Da¨berf¨ bei ist im Vorfeld nur auf die sinnvolle Festlegung der Eingangsdaten zu achten. Die ben¨ otigten Kennzahlen werden in einem zweiten Schritt u ¨ ber entsprechende Abfragen aus der Datenbank extrahiert. Dieses Verfahren ist deutlich vielseitiger und bietet eine bessere Grundlage zur Systemplanung und -optimierung. Nachteilig kann jedoch das kontinuierliche Ansteigen des Datenrahmens (Datenumfangs) sein. Sinnvoll erscheint u. a. die Buchung folgender Daten: • Dokumentation angeforderter sowie erledigter Auftr¨age – Anforderungen: • Anforderungs-ID/Bedarfs-ID • Quelle/Senke • Datum/Zeit • Status (Eil-/Normal) – Erf¨ ullung: • Person oder Betriebsmittel-ID • Datum/Zeit • Terminierung • Betriebsprotokoll – Betriebsbeginn/Betriebsende – Fehler-/St¨ orungsmeldungen und -zeiten – Lagerbewegungen • Einzelinformationen – artikelbezogene Daten (Artikel-Nr., Best¨ande, ...) – auftragsbezogene Daten (Auftrags-Nr., Auftragspositionen, Termine, ...) – lagereinheitenbezogene Daten (Lagerplatz-Nr., frei-/belegt-Status, Menge, ...)

62

2. Lagersysteme und Lagerverwaltung

Daneben m¨ ussen aus rechtlichen Gr¨ unden Lieferscheine bzw. Warenausgangsprotokolle erfasst und dokumentiert werden. 2.3.5 Inventur Die Inventur ist eine gesetzliche Verpﬂichtung, die durch jeden Kaufmann nach § 240 HGB f¨ ur jedes Gesch¨ aftsjahr durchgef¨ uhrt werden muss und die Grundlage f¨ ur den Jahresabschluss bildet. Bei Sachanlagen und Vorr¨aten, also auch bei Best¨ anden, muss eine k¨orperliche Bestandsaufnahme durchgef¨ uhrt werden. Damit sollen insbesondere die Lagerbest¨ande (Buchbest¨ande) und die Zuverl¨ assigkeit der Bestandsf¨ uhrung (Lagerbuchf¨ uhrung) u uft wer¨ berpr¨ den. Alle Gegenst¨ ande (Lagereinheiten) sind zu identiﬁzieren und zu klassiﬁzieren und durch Z¨ ahlen, Messen oder Wiegen mengenm¨aßig zu erfassen. Es muss ein Aufnahmebeleg mit folgenden Angaben erstellt werden: • • • • • • •

¨ Belegnummer (Uberpr¨ ufbarkeit der Vollst¨ andigkeit), Lagerort und Position, Bezeichnung des Gegenstandes, aufgenommene Menge und Mengeneinheit, Einheitspreis und Gesamtwert, ggf. Hinweise auf wertbeeinﬂussende Umst¨ ande (Alter, Lagerdauer), Aufnahmedatum und Unterschrift (des Aufnehmenden).

Daraus resultiert ein immenser Arbeitsaufwand, der insbesondere bei sehr großen L¨ agern praktisch nicht erbringbar ist. Dar¨ uber hinaus erlauben be¨ stimmte automatische Lagertechniken nicht die direkte Uberpr¨ ufung durch eine Person, und leistungs- und ablauftechnisch sowie aus wirtschaftlichen Gr¨ unden ist die Auslagerung aller Einheiten zur Inventur nicht m¨oglich. Aus diesem Grund bestehen unterschiedliche Verfahren und Vereinfachungen zur Durchf¨ uhrung der Inventur, deren Anwendung allerdings mit den jeweiligen ufern und Finanzbeh¨ orden abzustimmen ist: Wirtschaftspr¨ Stichtagsinventur Die klassische Form der Inventur erfordert die k¨orperliche Aufnahme aller Best¨ ande am Bilanzstichtag. Da der Gesch¨aftsverkehr am Bilanzstichtag ruht, ergeben sich keine Ver¨anderungen am Verm¨ ogen“. Eine solche Aufnahme ist nur bei kleineren Systemen m¨og” lich. Es besteht auch die M¨ oglichkeit, die Inventur nicht notwendigerweise an einem Tag, jedoch zeitnah, d. h. bis zu zehn Tage vor oder nach dem Bilanzstichtag durchzuf¨ uhren, sofern Bestandsver¨anderungen zuverl¨assig aufgezeichnet, nachgewiesen und im Inventar zum Bilanzstichtag entsprechend ber¨ ucksichtigt werden. Noch weitergehender erm¨ oglicht die vor- oder nachverlegte Stichtagsinventur, den Bestand auf einen Tag, drei Monate vor oder zwei Monate nach dem Bilanzstichtag, zu ermitteln und durch einen besonderen Bestand zur¨ uckzurechnen. Das setzt allerdings ein Fortschreibungs- bzw.

2.3 Warehouse Managementsystem

63

R¨ uckrechnungsverfahren nach den Grunds¨atzen odnungsgem¨aßer Buchf¨ uhrung (GoB) voraus. Permanente Inventur Um die Durchf¨ uhrung der Inventur entsprechend den Bed¨ urfnissen eines Betriebes in Zeiten mit geringer Betriebst¨atigkeit oder geringen Bestandsmengen durchzuf¨ uhren, bietet sich die permanente Inventur an. Dabei kann die k¨ orperliche Aufnahme der Best¨ande u aftsjahr verteilt werden. Voraussetzung ist die kontinu¨ ber das Gesch¨ ierliche Lagerbuchf¨ uhrung aller Best¨ ande und separate Buchung aller Zu- und Abg¨ ange mit Tag, Art und Menge. Zum Bilanzstichtag erfolgt die (mengenm¨ aßige) Bestandsfortschreibung und somit eine so genannte buchm¨ aßige Bestandsaufnahme. Die Z¨ ahlung kann artikelbezogen oder lagerplatzbezogen durchgef¨ uhrt werden. Dazu m¨ ussen alle Bewegungen auf den betrachteten Artikeln oder Lagerpl¨atzen ruhen. Im Fall der artikelbezogenen Aufnahme m¨ ussen ferner alle unbelegten Lagerpl¨ atze separat gepr¨ uft werden. Diese Verfahren setzen voraus, dass in der EDV-gest¨ utzten Lagerverwaltung artikeloder lagerplatzbezogene Z¨ ahlkennzeichen gesetzt werden k¨onnen. Da in automatischen L¨ agern die Bestandsaufnahme aus technischen Gr¨ unden nicht am Lagerplatz erfolgen kann, bieten sich weiterhin die Einlagerungsinventur und die Nulldurchgangsinventur an. Bei der Einlagerungsinventur erfolgt die Z¨ ahlung an einem anderen Ort (g¨angigerweise am Identiﬁkationspunkt vor der Einlagerung). Dabei wird das Z¨ahlkennzeichen auf den Artikel gesetzt. Im Fall der Nulldurchgangsinventur werden alle Lagerpl¨ atze beim rechnerischen Nulldurchgang erfasst (der am Lagerplatz vorhandene Bestand wird komplett geleert). Abweichungen werden dann unmittelbar eingegeben und das Z¨ahlkennzeichen aktualisiert5 . Stichprobeninventur Sofern ein EDV-basiertes Lagerverwaltungssystem eingesetzt wird und die GoB (s. o.) erf¨ ullt sind, kommt auch ein Stichprobenverfahren in Betracht, das den Aufwand der Inventur erheblich reduzieren kann. Es wird eine k¨ orperliche Aufnahme von Stichproben durchgef¨ uhrt, die mit Hilfe anerkannter mathematisch-statistischer Verfahren ausgewertet werden. Dabei kommen insbesondere zwei Verfahren in Betracht: Sequenzialtest Der Stichprobenumfang ist im Vorfeld nicht bekannt und ergibt sich aus der wiederholten Pr¨ ufung des Testkriteriums. Der Test wird solange fortgef¨ uhrt, bis das Annahmekriterium erf¨ ullt ist (Unterschreiten der minimalen Fehlerrate) oder abgewiesen wird ¨ (Uberschreiten der maximalen Fehlerrate). Um die Testdauer zu begrenzen, kann auch ein Abbruchkriterium festgelegt werden. 5

Werden in diesem Fall Mindermengen festgestellt, muss das Lagerf¨ uhrungssystem unabh¨ angig vom Bedarf der Z¨ ahlung (Inventur) einen Nachschub ausl¨ osen oder andere Entnahmeorte einbeziehen, um den Kundenauftrag korrekt erf¨ ullen zu k¨ onnen.

64

2. Lagersysteme und Lagerverwaltung

Sch¨ atzverfahren Aufbauend auf den Kenngr¨oßen der H¨auﬁgkeitsverteilung einer Stichprobe wird auf die Kenngr¨oßen der Grundgesamtheit geschlossen. Bei geschichteten Sch¨atzverfahren wird die Grundgesamtheit in Teile zerlegt, aus denen jeweils eine Stichprobe gezogen werden muss. Gebundene Sch¨ atzverfahren beziehen außerdem zur Hochrechnung eine Hilfskennzahl, z. B. den Bestandswert lt. Buchhaltung, in die Berechnung ein. Wie bereits oben angef¨ uhrt, h¨ angt die Auswahl eines Verfahrens von der Zustimmung durch den jeweiligen Wirtschaftspr¨ ufer und die zust¨andige Finanzbeh¨ orde ab. Einﬂussparameter, welche die Tauglichkeit eines Verfahrens beeinﬂussen, sind u.a. • Pr¨ asenz bzw. Einsatz eines EDV-gest¨ utzten Lagerbestandsf¨ uhrungssystems, • Zug¨ anglichkeit der Lagerf¨ acher (frei zug¨ angliches Lager oder abgeschlossener Bereich eines automatischen Lagers), • Wert der G¨ uter (Mit steigendem Gutwert steigt auch die Anforderung an die Inventurgenauigkeit. Bei sehr wertvollen G¨ utern“ kommen Stichpro” benverfahren nicht in Betracht.). Warehouse Managementsysteme sollten zum Zwecke der Inventur zusammengefasst mindestens folgende Funktionen besitzen: • Z¨ ahldatum f¨ ur Lagereinheiten und Lagerf¨ acher, • Sperren von Artikelgruppen oder Lagerfachbereichen zur Durchf¨ uhrung der Inventur, • st¨ andige Aktualisierbarkeit der Z¨ ahlkennzeichen unter Verbuchung der aufnehmenden Person sowie von Datum und Zeit, • Nulldurchgangsinventur. Kritisch betrachtet, werden die rigiden Anforderungen der Inventur den M¨ oglichkeiten moderner Warehouse Managementsysteme nicht gerecht. Kontinuierliche Gegenbuchung und Nulldurchgangsabgleich l¨asst eine ¨außerst azise Bestandsf¨ pr¨ uhrung zu. Es darf dabei auch nicht u ¨bersehen werden, dass im Rahmen der Inventur Erfassungsfehler unvermeidlich sind. Andererseits l¨ asst sich jedoch die Datensicherheit der Bestandsverwaltung auch f¨ ur die eigene Betriebsf¨ ahigkeit nicht hoch genug bewerten. In der Kombination von regelm¨ aßigem Datenabgleich und fehlerfreiem Datenmanagement wird die Basis f¨ ur einen hohen Lieferservice und eine kurze Reaktionszeit erst geschaﬀen. Die Inventur besitzt damit auch f¨ ur die eigene Betriebsf¨ ahigkeit eine erhebliche Bedeutung. Zudem werden Nachl¨assigkeit oder Diebstahl nicht selten erst durch die Einf¨ uhrung einer zuverl¨assigen Inventur aufgedeckt.

2.4 Basisdaten und Kennzahlen von Lagersystemen

65

2.4 Basisdaten und Kennzahlen von Lagersystemen Die Planung und Ausgestaltung von Lager- und Distributionssystemen erfolgt derartig vielschichtig, dass eine vollst¨ andige Sammlung aller m¨oglichen relevanten systembeschreibenden Gr¨ oßen praktisch nicht m¨oglich ist. Der u oßen ist im Einzelfall zur Kl¨arung einer ¨berwiegende Teil solcher Kenngr¨ gegebenen Aufgabenstellung zu deﬁnieren bzw. zu erstellen. Im Folgenden sollen dennoch die elementaren und allgemeing¨ ultigen Kenngr¨oßen, die in einer Vielzahl bekannter Systeme existieren und zur Anwendung gelangen, eingef¨ uhrt werden. Dabei werden grunds¨ atzlich Basisdaten und Kennzahlen unterschieden: Basisdaten werden als Absolutzahlen bezeichnet und ergeben sich aus unmittelbarer Messung, Z¨ ahlung, Summation oder Diﬀerenz bestimmter Einheiten, oder sie werden als Stammdaten erfasst und u ¨ bernommen. Gleichzeitig stellen sie die durch ein System zu leistenden Anforderungen und Basisinformationen dar. Kennzahlen sollen aussagekr¨ aftige und verdichtete Informationen zur Bewertung und zum Vergleich der Eﬃzienz von Prozessen und Systemen liefern. Dabei kommen sowohl Absolutzahlen als auch Relativzahlen, d. h. in ein Verh¨ altnis gesetzte Zahlen bzw. Daten, zur Anwendung. 2.4.1 Basisdaten

Stammdaten sind statische, d. h. u ¨ ber einen l¨angeren Zeitraum unver¨anderte Daten. Die Stammdaten enthalten alle wichtigen Informationen u ¨ber die grundlegenden Eigenschaften eines Artikels, Ladehilfsmittels usw. Die bedeutendsten Stammdaten f¨ ur den Lagerbetrieb sind die Artikelstammdaten, da alle wesentlichen Lagerfunktionen und Kontrollmechanismen darauf zur¨ uckgreifen. Der Artikelstamm enth¨ alt Beschreibungen aller Artikel, unabh¨angig von ihrem aktuellen Bestand. Die Summe der Artikel entspricht grunds¨atzlich dem Sortiment. Abweichungen gegen¨ uber dem Bestand bzw. dem tats¨achlichen Sortiment ergeben sich jedoch durch ausgelaufene oder tote Artikel. Wesentliche Elemente des Artikelstamms sind in Tabelle 2.13 exemplarisch aufgef¨ uhrt. Bestandsdaten Diese Datengruppe gibt u ¨ber die zu einem Zeitpunkt oder l¨angeren Verlauf gelagerten und bereitgehaltenen Mengen der Artikel Ausat und Genauigkeit dieser Datenerfassung ist von besondekunft. Die Aktualit¨ rer Bedeutung zur Sicherstellung der Lieferf¨ ahigkeit und zur Dimensionierung des Lagersystems. Da diese Daten kontinuierlichen Ver¨anderungen unterworfen sind, werden sie auch als dynamische Daten bezeichnet.

66

2. Lagersysteme und Lagerverwaltung

Tabelle 2.13. Elementare Basisdaten Artikelstammdaten

Bestandsdaten

Bewegungsdaten

sonstige Systemdaten

Artikelnummer Bezeichnung

Artikelanzahl Gesamtbestand

Wareneingänge/d Warenausgänge/d

Artikelgewicht

Durchschnittsbestand

Einlagerungen/d

Auftragsarten Ladeeinheitenstammdaten

Artikellänge

Mindestbestand/Artikel

Auslagerungen/d

Artikelbreite

Anz. LE/Artikel

Mengenumschlag/a

Artikelhöhe

verfügbarer Bestand

Umlagerungen/d

Mengeneinheit

Aufträge/d

Art Ladeeinheit

Aufträge pro Artikel

Beladungsfaktor (Packmenge/ Ladeeinheit)

Positionen/Auftrag Positionen/d Zugriffe/Positionen

Greifeinheit (Packmenge/ Entnahmeeinheit)

Verpackungsstammdaten Lagerkapazität Flächenrestriktionen Raumrestriktionen Flächen-/Volumennutzungsgrad Anzahl LE/Artikel

Auftragseingang/h

Anzahl Mitarbeiter/ Bereich

Auftragsdurchlaufzeit

Krankenstand

Sperrkennzeichen

Materialdurchlaufzeit

ABC Klassifikation

Auftragszahl/Auftragsart

Chargennummer

Doppelspielanteil/d

Gewicht/Entnahmeeinheit

Kompletteinheiten/d

Betriebskosten (Personal, Energie, Wartung) Investitionskosten (Austausch) Wertumschlag/a

Gewicht/Ladeeinheit

Produktivität

Mandant Verfallkennzeichen Restlaufzeit Sortereignung h = Stunde

d = Tag

a = Jahr

Bewegungsdaten Die zweite Gruppe dynamischer Daten sind die Bewegungsdaten, die alle wesentlichen physischen Lagerprozesse wiedergeben. Darunter fallen sowohl die Basisprozesse wie Warenein-/-ausgang und Lageroperationen als auch die Kommissionierprozesse und somit die Auftragsbearbeitung. Sonstige Systemdaten Weitere elementare Systemdaten sind unter anderem • • • •

Fl¨ achen- und Raumstrukturdaten, Personalstrukturdaten, Kostendaten und Ladeeinheiten- und Verpackungsstammdaten etc.

2.4 Basisdaten und Kennzahlen von Lagersystemen

67

2.4.2 Logistische Kennzahlen Wie bereits der vorangehende Abschnitt zeigt, f¨allt in Lager- und Distributionssystemen eine F¨ ulle verschiedenster Informationen in Form von Daten an, die eine Bewertung und Optimierung des Systems auf Basis dieser Datenf¨ ulle sehr komplizieren. Außerdem k¨ onnen einzelne Daten irref¨ uhrend sein, wenn der Kontext nicht beachtet wird. So sagt beispielsweise die Auftragsanzahl/d recht wenig aus, wenn nicht gleichzeitig die Anzahl Positionen/Auftrag ber¨ ucksichtigt wird. Im engeren Sinne sind Kennzahlen verdichtete Kenngr¨oßen, also aus Daten oder anderen Kennzahlen zusammengesetzte (Verh¨altnis-)Gr¨oßen. Dagegen werden im weiteren Sinne alle m¨ oglichen Kenngr¨oßen zusammenfassend als Kennzahlen bezeichnet, die folgende Eigenschaften besitzen: Logistische Kennzahlen sind Zahlen, mit denen die quantitativ erfassbaren Sachverhalte des Logistikbereiches in konzentrierter Form wiedergegeben werden k¨ onnen. [45] Danach geh¨ oren auch Basisdaten zu Kennzahlen. Die Spezialisierung auf die Logistik-Kennzahlen ber¨ ucksichtigt dabei, dass Kennzahlen in allen Bereichen der Technik, Betriebs- und Volkswirtschaft usw. zum Einsatz gelangen. Das Ziel der Nutzung von Kennzahlen ist die Vermittlung eines schnel¨ len und komprimierten Uberblicks, insbesondere u ¨ber optimale Kosten- und Leistungsrelationen [45] und die Bewertung unterschiedlicher Varianten. Zur Herleitung relativer Kennzahlen werden insbesondere Eﬃzienz-/Produktivit¨atszahlen (Output/Input) und Intensit¨atszahlen (Input/Output) gebildet. Die Bildung der speziﬁschen Kennzahl h¨angt wiederum davon ab, ob die Ausrichtung der Fragestellung operativer oder strategischer Natur ist. Operative Kennzahlen dienen in erster Linie der Steuerung und Regelung eﬃzienter logistischer Abl¨ aufe, strategische Kennzahlen werden mit dem Ziel der Entwicklung und Gestaltung eﬀektiver G¨ uterﬂ¨ usse erstellt [15]. Kennzahlen basieren oftmals auf gemittelten und angen¨aherten Werten und geben Sachverhalte nicht pr¨ azise wieder, sondern dienen in erster Linie zur Ver¨ mittlung eines schnellen Uberblicks. Typische Kennzahlen sind in Tabelle 2.14 aufgef¨ uhrt. Eine Betrachtung der Kennzahlen Mengenumschlag“ und Lagerreich” ” weite“ zeigt, dass einzelne Kennzahlen in unterschiedlicher Weise deﬁniert sein k¨ onnen, woraus erhebliche Diskrepanzen in der Bewertung resultieren. ufen, ob eine Kennzahl wertm¨aßig oder mengenDaher ist insbesondere zu pr¨ bzw. leistungsbezogen erstellt wurde. Da auch einzelne Kennzahlen nur Teilaspekte wiedergeben k¨onnen und die Vielzahl m¨ oglicher Kennzahlen und deren variierende Zusammensetzung eine zielgerichtete, systematische Kennzahlenarbeit erschweren, werden Kennzahlen in Kennzahlensystemen zusammengefasst (siehe u. a. [45]). In einer hierarchisierten Struktur systematisch verkn¨ upfter Einzelkennzahlen werden so

68

2. Lagersysteme und Lagerverwaltung

Tabelle 2.14. Beispiele f¨ ur Logistikkennzahlen Kennzahl

Lieferbereitschaftsgrad

Definition

Anzahl termingerecht ausgelieferter Bedarfsanforderungen (Stck)

Zielsetzung/ Fragestellung

Einflussgrößen

Lieferservice, Kundenzufriedenheit

Auftragshandling, Durchsatz, Kapazität

Nutzung der Ressource Lagerkapazität

Bestandsmanagement

Dynamik des Lagers

Große Versandeinheiten (durch Kundenaufträge)

Bestandskosten

Bestellwesen

Wahl der Lagertechnik

Lagertechnik

Bestandskosten, Dynamik des Lagers, Servicegrad

Bestellwesen

Bestandskosten, Servicegrad

Bestellwesen

Wahl des Kommissionierverfahrens

Ablaufsteuerung, Kommissionierprinzip, Informationsmanagement

mittlere Wegzeiten, Kommissionierleistung

Nachschubsteuerung, Regaltechnik

Anzahl Bedarfsanforderung (Stck)

Lagerfüllungsgrad

Anzahl belegter Fächer (Stck) Lagerkapazität (Stck)

Umschlagsgrad mengenbezogen

Auslagerungen (Stck/a) Lagerkapazität (Stck)

Umschlagsgrad wertbezogen

Gesamtumsatz (€)

Kosten/Lagerplatz

Gesamtkosten (€)

Ø Lagerwert (€)

Lagerkapazität (Stck)

Lagerreichweite mengenbezogen

Lagerreichweite wertbezogen

Kommissionierweg/ Position

Aktueller Lagerbestand (Stck) Lagerumsatz (Stck/a)

Lagerbestand (€) Lagerumsatz (€/a)

mittlerer Kommisssionierweg (m) Ø Positionen (Stck)

Pickdichte

Positionenzahl (Stck) Zugriffsfläche (m²)

die zu einer F¨ uhrungsaufgabe ben¨ otigten Informationen u ¨ ber Hilfskennzahlen zusammengetragen. Als Spitzenkennzahlen eines solchen Systems werden beispielsweise nach Reichmann die Umschlagsh¨ auﬁgkeit, die Gesamtlogistikkosten und der Lieferbereitschaftsgrad zusammengetragen. Das Hauptproblem besteht indes darin, ein solches System f¨ ur einen speziellen Anwendungsfall zu bilden. W¨ ahrend einzelne Kennzahlen relativ unproblematisch zur Analyse von Abweichungen und der Erreichung einzelner Ziele im Rahmen des Warehouse Management eingesetzt werden, sind umfassende Kennzahlensysteme im We-

2.5 Besondere Abl¨ aufe und Verfahrensweisen

69

sentlichen ein Hauptinstrument des Logistikcontrollings und sollen an dieser Stelle nicht weiter vertieft werden.

2.5 Besondere Abl¨ aufe und Verfahrensweisen 2.5.1 Cross Docking Beim Cross Docking werden die Warenanlieferungen und Warenabg¨ange so aufeinander abgestimmt, dass die eingehenden Waren ohne Einlagerung unmittelbar in den Versand gegeben werden. Damit ﬁndet keine Vereinnahmung in das Lagersystem statt und das System gleicht einem reinen Umschlagsystem. Die Zielsetzungen dabei sind • • • • •

Senkung der Best¨ ande an bestimmten Punkten der Versorgungskette, Steigerung der Eﬃzienz durch Vermeidung von Prozessschritten, k¨ urzere Durchlaufzeiten der Artikel im System, Servicesteigerung durch h¨ auﬁgere Belieferung, eﬀektive Sortierung nach Destinationen, z. B. f¨ ur den KEP-Bereich.

Dabei sollen nicht nur die Best¨ ande im Distributionssystem bzw. dem Cross-Docking-Punkt minimiert werden, sondern auch Best¨ande an den Endverkaufspunkten, was eine h¨ auﬁgere Belieferung voraussetzt, dadurch aber letztlich eine Servicesteigerung bewirkt. Es existieren zwei prinzipielle Methoden zur Umsetzung eines CrossDocking-Prinzips: 1. Cross Docking mit Aufbrechen der Ladeeinheiten, 2. Cross Docking als Durchlaufsystem. Cross Docking mit Aufbrechen der Ladeeinheiten Die ankommenden Einheiten sind quasi artikelrein und m¨ ussen entsprechend den Auftr¨ agen einzelner Filialen verteilt bzw. kommissioniert werden. Typischerweise ﬁndet ein Umschlag von palettierten Einheiten in Rollbeh¨alter statt. Dieses Prinzip wird auch als zweistuﬁges Cross Docking oder Beh¨alter Cross Docking bezeichnet. Das wesentliche Merkmal ist die Durchf¨ uhrung einer Kommissionierung. Cross Docking als Durchlaufsystem In diesem Fall werden die eingehenden Lieferungen durch die Lieferanten entsprechend den Auftr¨ agen einzelner Filialen bereits so vorkommissioniert, dass die einzelne Logistische Einheit nicht mehr aufgebrochen und auf Filialen verteilt, sondern nur noch konsolidiert, d. h. mit anderen auftragsreinen Einheiten zusammengef¨ uhrt wird. Dieses Prinzip wird auch als einstuﬁges Cross Docking bezeichnet.

70

2. Lagersysteme und Lagerverwaltung

Werden dabei nur ganze Transporteinheiten (z. B. Paletten) umgeschlagen, spricht man z. B. vom Paletten-Cross-Docking. Beﬁnden sich auf den Ladeeinheiten dagegen f¨ ur einzelne Filialen vorkommissionierte Beh¨alter, die den einzelnen Filialen bzw. Touren zugeordnet werden m¨ ussen, wird das Prinzip auch als Pre-sorted Store Order bezeichnet. In diesem Fall ﬁndet ein reiner Umschlag statt, Z¨ ahl- und direkte Pickvorg¨ ange entfallen hingegen. Voraussetzungen und Einsatzfelder Eine Reihe von Voraussetzungen ist bei der Anwendung des Cross-DockingPrinzips zu ber¨ ucksichtigen. Die direkte Weiterleitung eingehender G¨ uter ist eine eﬃziente L¨ osung, stellt aber gleichzeitig hohe Anforderungen an die kurzfristige Verf¨ ugbarkeit der gew¨ unschten Mengen. Aufgrund fehlender Best¨ ande ist die Gefahr von Fehlmengen entsprechend hoch. R¨ ucklagerungen infolge von Auftragsstornierungen sind praktisch nicht m¨oglich. Ist das Auftragsspektrum der Filialbetriebe weitgehend gleich, werden auch die Touren zwangsl¨ auﬁg zu einem ¨ ahnlichen Zeitpunkt fertiggestellt. Hieraus k¨onnen Engp¨ asse im Warenausgang entstehen. Dadurch sind gegebenenfalls auch t¨ aglich mehrfache Belieferungen einzelner Filialen erforderlich. In der praktischen Umsetzung macht es daher nur dort Sinn, wo relativ konstante Verbr¨ auche, ¨ ahnliche Mengen und Artikel, kurze Wiederbeschaffungszeiten und kurze Distanzen zu den Filialen vorliegen. Anwendungen ﬁnden sich daher beispielsweise im Frischwarenbereich. Ebenso werden diese Prinzipien innerhalb existierender Warenverteilzentren f¨ ur bestimmte Warengruppen realisiert. In diesen F¨ allen m¨ ussen entsprechende Abl¨aufe in das Warehouse Managementsystem integriert werden. Empfehlungen f¨ ur die Umsetzung der Kommunikationsschnittstellen liefert [6]. 2.5.2 Outsourcing der physischen Distributions- und Lagerprozesse Die Hintergr¨ unde zur externen Vergabe von Logistikleistungen wurden bereits einleitend behandelt (s. S. 17). Auswirkungen auf das Lagermanagement ergeben sich unter anderem in der Anbindung der externen Systeme an die eigene Warenwirtschaft. Um in Outsourcing-L¨ agern mit mehreren Kunden die Prozesse speziell auf die Bed¨ urfnisse einzelner Kunden ausrichten zu k¨onnen, ist die Ber¨ ucksichtigung der Prozesse, Abl¨ aufe und Strategien nicht nur in waren- und kundenbezogener, sondern auch in mandantenbezogener Sicht notwendig, was im WMS zu implementieren ist. Ein solches System wird als mandantenf¨ahig bezeichnet. Da die Abrechnung der erbrachten Leistungen oftmals auf Basis durchgef¨ uhrter Aktionen erfolgt, ist außerdem die Erfassung einzelner Leistungen (z. B. Staplerfahrten, Kommissionierpositionen) in Abh¨angigkeit vom Mandantenauftrag wichtig.

2.5 Besondere Abl¨ aufe und Verfahrensweisen

71

Abbildung 2.10. Prinzipien des Cross Docking

2.5.3 Outsourcing der Software: Application Service Providing ¨ Ahnlich dem Outsourcing physischer Lagerprozesse durch einen externen Dienstleister werden beim Application Service Providing (ASP) IT-Leistungen und rechnergest¨ utzte Steuerungsfunktionalit¨aten an einen Dienstleister u bertragen, der die entsprechenden Prozesse von einem zentralen Rechen¨ zentrum aus steuert bzw. die Berechnungen, Verarbeitungen usw. in diesem Zentrum ausf¨ uhrt. Daf¨ ur sprechen nicht nur die direkte Erschließung von Kostenpotenzialen, beispielsweise durch die m¨ ogliche Reduktion von EDV-Personal vor Ort, sondern insbesondere auch Fragen der Datensicherheit. Einem zentralen Service Provider stehen andere und bessere M¨ oglichkeiten zur Verf¨ ugung, als sie in vielfacher Ausf¨ uhrung an dezentralen Orten wirtschaftlich darstellbar sind.

72

2. Lagersysteme und Lagerverwaltung

Im Bereich der Logistik existieren solche L¨osungen f¨ ur Shopsysteme im Bereich des E-Commerce und f¨ ur Anwendungen in der Warenwirtschaft, also auf WMS-¨ uberlagerten Ebenen. Eine ASP-L¨osung, bei der die Steuerung zeitkritischer Abl¨ aufe eines gr¨ oßeren Distributionssystems durch ein zentrales Rechenzentrum erfolgt, ist bislang nicht bekannt. Problematisch sind in ¨ diesem Zusammenhang die Gew¨ ahrleistung der Ubertragungssicherheit und gegebenenfalls das zeitliche Reaktionsverm¨ ogen (Echtzeitverhalten). Angesichts der Entwicklung der Informations- und Kommunikationstechnologie sind solche L¨ osungen insbesondere f¨ ur kleinere Anwendungen zuk¨ unftig durchaus denkbar. Die grundlegenden Funktionalit¨aten ¨andern sich dadurch jedoch nicht. Auf die Darstellung der speziellen Abl¨aufe wird daher verzichtet.

3. Grundlagen der Lager- und F¨ ordertechnik

Entsprechend der Vielfalt m¨ oglicher Aufgabenstellungen und Besonderheiten bei der Lagerung und F¨ orderung von St¨ uckg¨ utern, hat sich eine ebenso große Vielzahl systemtechnischer Umsetzungen zur eﬀektiven Erbringung dieser Aufgaben herausgebildet. Im Folgenden sollen die g¨angigsten technischen L¨ osungen zur Lagerung und F¨ orderung von G¨ utern als Basis f¨ ur die Diskussion der eﬃzienten Steuerung und Verwaltung mit Hilfe von Warehouse Managementsystemen vorgestellt werden. Das Augenmerk liegt dabei nicht auf einer vergleichenden Betrachtung der verschiedenen Systeme und Techniken mit dem Ziel einer optimierten Technik- oder Systemauswahl, sondern auf der Schaﬀung einer soliden Basis f¨ ur ein Grundverst¨andnis dieser Systeme. Hinsichtlich einer u ¨ bergreifenden und vergleichenden Betrachtung wird auf andere Werke verwiesen [24, 34, 47, 48, 59].

3.1 Lagersysteme Um Lagersysteme richtig bewerten und ausw¨ahlen zu k¨onnen, ist eine Systematik hilfreich, aus der systembedingte Leistungscharakteristika allgemeing¨ ultig abgeleitet werden k¨ onnen. Die grundlegenden Diﬀerenzierungen f¨ ur verschiedene Lagersysteme sind in Tabelle 3.1 aufgef¨ uhrt. Ebenso sind den einzelnen Auspr¨ agungsformen bereits einige allgemeing¨ ultige Eigenschaften zugeordnet. Die Diﬀerenzierung in statische und dynamische Lagersysteme ber¨ ucksichtigt dabei, ob das Lagersystem zwangsl¨auﬁg zu einer Ortsvera nderung w¨ ahrend des Lagerungsprozesses f¨ uhrt. Die Umlagerung in einem ¨ klassischen Zeilenregal wird in diesem Zusammenhang nicht als dynamische Lagerung betrachtet. Anhand dieser Klassiﬁkation lassen sich bereits wesentliche Eigenschaften ableiten. Die prim¨ aren Auswahlgr¨ oßen bei der Wahl eines Lagersystems sind • • • • • •

Anzahl verschiedener Artikel, Artikelabmessungen und -gewichte, Mengen pro Artikel, geforderte Ein-/Auslagerlagerleistung oder Durchsatz, Fl¨ achen- und Raumbedarf, Zugriﬀsverhalten und Bedienstrategien.

74

3. Grundlagen der Lager- und F¨ ordertechnik

Tabelle 3.1. Diﬀerenzierung der Lagersysteme Merkmal

Lagertechnik

Lagerform

Lagerort

Ausprägungsformen

Beschreibung

gängige Zielsetzungen

Bodenlagerung

Ladegut wird unmittelbar auf dem Boden gelagert, ggf. gestapelt

große Mengen weniger Artikel kostengünstig lagern

Regallagerung

Ladegut wird in Regalen gelagert, zumeist auf einem Ladehilfsmittel.

Direktzugriff auf große Artikelanzahl, hohe Flächennutzung

Blocklagerung

Lagergüter werden unmittelbar über-, hinter und nebeneinander gelagert.

hohe Raumnutzung und geringe Bedienwege

Zeilenlagerung

Ladegüter werden über- und hintereinander gelagert; zwischen Regalflächen bestehen Bedienwege.

Direktzugriff auf größere Artikelanzahl

Statisches Lagersystem

Lagergut verbleibt zwischen Ein- und Auslagerung am selben Ort, d.h. es führt keine Ortsveränderung durch

kostengünstige Lagertechnik, geringe Beanspruchung des Lagergutes

Dynamisches Lagersystem

Ladeeinheiten werden nach der Einlagerung bewegt. Ein-/Auslagerung am selben Ort ist dennoch möglich

geringe Bedienwege, Direktzugriff trotz hoher Volumennutzung

Die g¨ angigen Systeme werden im Folgenden vorgestellt und hinsichtlich ihrer Einsatzfelder und der Anforderungen an die Systemf¨ uhrung genauer eingeordnet. Weitere Systematisierungen k¨ onnen dar¨ uber hinaus anhand der Lagerfunktion, der Lagerbauweise oder der dort eingesetzten F¨ordermittel erfolgen. 3.1.1 Bodenlager Die G¨ uter werden unmittelbar auf dem Boden gelagert bzw. dort gestapelt. Die m¨ ogliche Stapelh¨ ohe h¨ angt u. a. von den Eigenschaften der G¨ uter oder der eingesetzten Ladehilfsmittel (z. B. Gitterboxen), der Bedientechnik (z. B. Stapler oder Kran) und nat¨ urlich den r¨ aumlichen Gegebenheiten ab. Diese einfache Form der Lagerung verursacht geringe Investitionskosten und ist ﬂexibel an ¨ ortliche Gegebenheiten (Fl¨achenzuschnitt und Geb¨audeform) anpassbar. Bei ausreichend dimensionierten Gangbreiten kann durch eine entsprechende Anzahl von F¨ ordermitteln auch eine relativ hohe Umschlagsleistung realisiert werden. Die Bedienung erfolgt zum u ¨ berwiegenden Teil manuell. Bodenblocklager Die G¨ uter werden zu einem kompakten Block angeordnet, d.h. unmittelbar u ¨ ber-, hinter- und nebeneinander gelagert. Dadurch lassen sich die h¨ ochsten Raumnutzungsgrade erzielen, allerdings ist der Zugriﬀ nur auf die in vorderster S¨ aule beﬁndlichen G¨ uter m¨oglich. Damit ist dieses Prinzip praktikabel nur dort einsetzbar, wo eine LIFO-Strategie (vgl.

3.1 Lagersysteme

75

Abbildung 3.1. Bodenlagerung a) Blocklagerung b) Zeilenlagerung

Tabelle 2.4, S. 33) m¨ oglich ist. Dabei kann es sich einerseits um klassische monostrukturierte L¨ ager (Getr¨ anke, Rohstoﬀe) und andererseits um Puﬀerl¨ager im Warenein-/-ausgang handeln, sofern hier Ganzladungen gepuﬀert werden. Bodenzeilenlager Um einen gegen¨ uber dem Bodenblocklager besseren Zugriﬀ auf einzelne Ladeeinheiten zu erhalten, werden die Artikel so angeordnet, dass jede S¨ aule an einem Bediengang liegt. Folgerichtig sinkt der Raumnutzungsgrad, demgegen¨ uber steigt die sinnvoll lagerbare Artikelanzahl. Organisation und Betrieb Der Einfachheit dieses Systems steht die Problematik einer pr¨ azisen Materialﬂussverfolgung gegen¨ uber. Da in den meisten F¨ allen nur Bodenﬂ¨ achen als Lagerort erfasst sind und die Ein- und Auslagerung manuell gesteuert und nur auf den Artikeltyp bezogen erfolgt, ist die genaue Erfassung einer einzelnen Ladeeinheit praktisch nicht m¨oglich. Ebenso ist die direkte Zuweisung eines Lagerplatzes an einen Bediener (Stapler-

76

3. Grundlagen der Lager- und F¨ ordertechnik

fahrer) kaum m¨ oglich, da pr¨ azise Referenzpunkte, wie z. B. die Fachnummer eines Lagerregals, fehlen. Eine genaue Platzverwaltung existiert damit quasi nicht, die Mengenverwaltung erfolgt u ¨ber die Erfassung der zu- und abgehenden Einheiten. Diese Situation kann insbesondere zu Problemen bei der Chargenverfolgung f¨ uhren. Sofern eine solche Verfolgung gefordert wird, l¨asst sich im ersten Ansatz die getrennte Lagerung einzelner Chargen in separaten Stellﬂ¨achen durchf¨ uhren. Neuere L¨ osungsans¨ atze versuchen via GPS oder aufbauend auf der Technologie Fahrerloser Transportsysteme die exakte Position im Raum bei der Ein- und Auslagerung zu erfassen und dadurch eine Materialﬂussverfolgung zu gew¨ ahrleisten [36]. Demgegen¨ uber werden in automatisch betriebenen Bodenblockl¨agern, die mit Automatikkranen oder Fahrerlosen Transportfahrzeugen bedient werden (beispielsweise bei der Lagerung von Papierrollen oder Stahlcoils), die einzelnen Positionen exakt erfasst und verwaltet. Somit besteht hier die zuvor dargestellte Problematik nicht. 3.1.2 Statische Regallagerung Beim Einsatz von Regalen steht zumeist die Optimierung der Fl¨achennutzung durch eine bessere Nutzung der H¨ ohe im Vordergrund. Die Ladeeinheiten werden in ein separates Fach oder an einen speziﬁzierten Ort eines Lagergestells gesetzt. Insbesondere k¨ onnen so auch nicht stapelf¨ahige G¨ uter eﬃzient gelagert werden. Die m¨ ogliche Regalh¨ ohe wird dabei im Wesentlichen von der gew¨ ahlten Bedientechnik (s. Abschn. 3.2) bestimmt. Entsprechend variieren die Regalh¨ ohen von zwei Meter (manuelle Bedienung) bis zu etwa 50 m (beim Einsatz von Regalbedienger¨ aten). Neben der physischen Umsetzung der Lagerung f¨ uhren aber auch Fragen der Lagerorganisation zur Wahl von Regaltechniken. Wesentliche Vorteile sind die M¨ oglichkeit einer eindeutigen Zuordnung von Ladeeinheit und Lagerort und die weitgehende Umsetzbarkeit geforderter Strategien. Dadurch wird die wesentliche Basis f¨ ur die Automatisierung von Lagerprozessen geschaﬀen. ¨ Im t¨ aglichen Betrieb wird dar¨ uber hinaus Ubersichtlichkeit und Ordnung im Lager erzeugt. Regale in Zeilenanordnung (Zeilenregale) bieten beliebigen Zugriﬀ auf einzelne Ladeeinheiten. Blockregale bieten dagegen kompakte Lagerung und hohe Raumnutzung bei z. T. sehr hohen Durchsatzleistungen. Die meisten Regale setzen allerdings einheitliche G¨ uter mit standardisierten Ladehilfsmitteln voraus. Werden nur ganze Ladeeinheiten ein- und ausgelagert, spricht man daher auch von Einheitenl¨agern. Zeilenregale Die Gestaltung eines Zeilenregals variiert mit der Gr¨oße, Form und dem Gewicht des einzulagernden Gutspektrums, der gew¨ahlten oder m¨oglichen Be-

3.1 Lagersysteme

77

dientechnik, der geforderten Ein-/Auslagerleistung und den r¨aumlichen Gegebenheiten. Die einzelnen F¨ acher des Regals sind auf die maximalen Abmessungen einzulagernder G¨ uter zuz¨ uglich allseitiger Freir¨aume zur Handhabung und Gut¨ ubergabe auszulegen. Die L¨ ange einzelner Lagerg¨ange und die Anordnung der Bedien- und Gassenwechselwege werden im Wesentlichen durch die Anforderungen des Kommissioniersystems gepr¨agt. Der Begriﬀ Zeilenregal deﬁniert zun¨ achst, dass einzelne F¨acher u ¨ ber- und nebeneinander angeordnet werden und die Ladeeinheiten unmittelbar an der Regalfront ein- und ausgelagert werden. Im normalen Fall der einfachtiefen Lagerung kann somit auf jede Lagereinheit direkt zugegriﬀen werden. Entsprechend lassen sich alle m¨ oglichen Lagerstrategien (s. Abschn. 2.2.3) direkt umsetzen. Strategien wie FIFO oder LIFO werden dabei u ¨ber die Lagerorganisation realisiert und nicht durch die physische Anordnung der Lagerpl¨ atze vorgegeben. Daneben k¨ onnen bei Einsatz spezieller Bedientechniken die Ladeeinheiten auch zweifach oder dreifach hintereinander (doppelt- oder dreifachtief) eingelagert werden. Hierdurch ergeben sich jedoch beim Zugriﬀ auf hintere Einheiten notwendige Umlagerungen oder spezielle Lageroperationen, die den m¨ oglichen Durchsatz verringern1. Eine funktionierende Lagerplatzverwaltung vorausgesetzt, lassen sich alle Ladeeinheiten einfach und schnell lokalisieren und auslagern. Damit sind Zeilenregale immer dann sinnvoll, wenn moderate Mengen einzelner Artikel bei allerdings großer Artikelanzahl einzulagern sind. Je nach Lagergut leiten sich spezielle Bauformen ab, die in Anlehnung an den eingesetzten Ladehilfsmitteltyp (Palettenregal, Beh¨alterregal, Kastenregal bzw. Kastenlager) oder die Lagerbauform (Traversenregal, Kragarmregal, Wabenregal) bezeichnet werden. Ein entscheidendes Merkmal ist dabei auch die Unterscheidung in Lagerung mit und ohne Ladehilfsmittel. Die Regalbedienung erfolgt bei schweren und großen Einheiten u ¨ blicherweise u ate oder Krane, die die Ladeeinheit ¨ber Gabelstapler, Regalbedienger¨ durch vertikale Hubbewegung absetzen respektive anheben. Vereinzelt kommen auch Satellitenfahrzeuge zum Einsatz, die u ¨ ber Lastaufnahmemittel zur seitlichen Lastaufnahme verf¨ ugen (Automatische Verteilfahrzeuge). Bei leichten Einheiten ist auch die manuelle Bedienung u ¨ blich. In Abh¨angigkeit von der eingesetzten Bedientechnik variieren die erforderlichen Arbeitsgangbreiten und damit der realisierbare Raumnutzungsgrad. Palettenregale Palettenregale (engl. Racks) stellen die am h¨auﬁgsten eingesetzte Lagertechnik f¨ ur Paletten dar. Sie setzen auf einem standardisierten Ladehilfsmittel auf. Im klassischen Fall wird die eingelagerte Einheit (Palette oder Gitterbox) nur an den beiden Stirnseiten unterst¨ utzt, wobei 1

Tats¨ achlich stellt die mehrfachtiefe Einlagerung streng genommen eine Blocklagerung dar. Aufgrund der u uhrung ¨ berwiegend jedoch nur in doppelttiefer Ausf¨ vorkommenden Version und der Verf¨ ugbarkeit verschiedener mehrfach wirkender Lastaufnahmemittel werden diese Systeme zu den Zeilenregalen gez¨ ahlt.

78

3. Grundlagen der Lager- und F¨ ordertechnik

die Lagereinheit l¨ angs oder quer eingelagert wird. Bei der L¨angseinlagerung sind jeweils zwischen den vorderen und den hinteren Regalst¨ utzen zwei Traversen befestigt (geschraubt, im Lochraster eingeh¨angt oder verschweißt), auf denen die Ladeeinheiten nebeneinander gelagert werden. Bei Verwendung von Standardpaletten (800 mm×1200 mm, 1000 mm×1200 mm) ergibt sich aufgrund der Palettenkonstruktion zwangsl¨auﬁg die Einlagerung in L¨ angsrichtung der Ladeeinheit, bezogen auf die Fachtiefe (s. Abb. 3.2). Aufgrund der M¨ oglichkeit, mehrere Ladeeinheiten direkt nebeneinander zu lagern, wird das Prinzip als Mehrplatzlagerung verstanden. Gemeinhin werden drei bis max. f¨ unf Ladeeinheiten in einem so genannten Feld nebeneinander gelagert. Bei der Quereinlagerung wird eine im Allgemeinen winkelf¨ormige Auﬂage zwischen einer vorderen und hinteren St¨ utze befestigt und die Ladeeinheit stirnseitig zur St¨ utze und somit quer ins Lagerfach eingelagert. In diesem Fall beﬁndet sich nur eine Ladeeinheit zwischen den Regalst¨ utzen, woraus sich die Bezeichnung Einplatzlagerung ableitet. Die L¨ angseinlagerung erm¨ oglicht eine eﬃzientere Raumnutzung, da im Regal weniger St¨ utzen und Sicherheitsabst¨ ande vorhanden sind. Auch k¨onnen die meisten Regalbedienger¨ ate nicht derart schmal ausgef¨ uhrt werden, dass sich insgesamt schmalere Arbeitsgangbreiten ergeben. Die Quereinlagerung besitzt im Fall der manuellen Kommissionierung im Regal allerdings eine bessere Erreichbarkeit der Artikel im Regalfach (die maximale Reichweite des Menschen betr¨ agt ca. 950 mm). Im Fall der doppelttiefen Lagerung ist eine Anpassung der Traversenh¨ohen auch an die Bauh¨ ohe und die Durchbiegung der Lastaufnahmeeinheit anzupassen. Dazu werden die hinteren Traversen um ca. 100 mm hochgesetzt. Werden unterschiedliche Palettenmaße eingelagert, zu denen die Traversen inkompatibel sind, k¨ onnen auf die Traversen auch Gitterroste, Bleche oder Bretter aufgelegt werden, wodurch streng genommen ein Fachbodenregal geschaﬀen wird. Beh¨ alterregale Bei der Lagerung sehr kleiner Artikel oder geringer Mengen ist oftmals die Wahl geringerer Lagergutabmessungen erforderlich und das klassische Palettenmaß (800 mm×1200 mm) liefert keine zufriedenstellende Raumnutzung. Daher wird in diesen F¨allen die Einlagerung kleinerer Beh¨ alter oder Tablare bevorzugt (z. B. 400 mm×600 mm). Tablare sind Blechwannen mit einer stirnseitig angebrachten Eingriﬀsleiste. Durch die geringen St¨ uckgewichte ist die Lagerung auf einfachen Winkelproﬁlen m¨oglich, die seitlich an den Lagerf¨ achern angebracht sind. Die geringen St¨ uckgutgewichte erm¨ oglichen dabei auch eﬀektivere Formen der Lagerfachbedienung, die zu speziellen Auspr¨agungen der Zeilenregale gef¨ uhrt haben und als Beh¨alter-, Kasten- oder Tablarregale bezeichnet werden. Das relativ geringe St¨ uckgutgewicht erm¨oglicht in vielen F¨allen, die Lagereinheit (Beh¨ alter, Kasten, Tablar) in das Lagerfach zu schieben respektive

3.1 Lagersysteme

79

¨ Abbildung 3.2. Palettenregal mit L¨ angseinlagerung [Foto: STOCKLIN SIEMAG]

bei der Auslagerung aus dem Fach zu ziehen. Das Lastaufnahmemittel greift dazu in die Leiste oder den Griﬀ des Tablars oder durch einen Zangenmechanismus seitlich am Beh¨ alter an (s. Abb. 3.24). Durch den Einsatz solcher Ziehtechniken wird einerseits eine k¨ urzere Last¨ ubergabezeit realisiert, und außerdem reduzieren sich die Sicherheitsabst¨ ande und eine bessere Raumnutzung wird erm¨ oglicht. Die Beh¨ alterregale werden im Allgemeinen durch automatische Regalbedienger¨ ate bedient und als Automatische Kleinteilelager (AKL) bezeichnet (s. Abb. 3.3). Sofern AKL in zug¨ anglichen Bereichen betrieben werden, m¨ ussen sie seitlich gekapselt (verkleidet) werden, um insbesondere ein Verschieben der Ladeeinheit zu vermeiden, die bei Kollision mit dem RBG zu erheblichen Sch¨ aden f¨ uhren w¨ urde. Daneben wird durch solch eine Kapselung dem Personenschutz und der Diebstahlsicherung Rechnung getragen. Mischpalettenlagerung Die Lagerung verschiedener artikelreiner Beh¨alter auf einer gemeinsamen Palette oder Mischpalette stellt besondere Anforderungen an die Lagerf¨ uhrung. Es ist nicht nur die Verwaltung mehrerer Einheiten am identischen Ort zu realisieren (was in der Regel u ¨ber die Verbuchung ¨ auf eine einzige Paletten-ID erreicht wird), sondern auch die Uberwachung

80

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.3. Automatisches Kleinteilelager (AKL) mit Tablarsystem [Foto: BITO]

der Lagermenge pro Palette, da die Einheiten typischerweise unterschiedlich geleert werden. Dazu sind bei Bedarf Verdichtungsoperationen anzustoßen (vgl. Abschn. 2.3.2). Außerdem muss bei der Zulagerung eines Artikels auf eine bereits teilgef¨ ullte Palette die betreﬀende Einheit zun¨achst ausgelagert werden, wodurch zus¨ atzliche Wege anfallen. Die Problematik triﬀt analog auf Mischlagerung bei Tablaren und Beh¨ altern zu. Hochregallager Die Bezeichnung Hochregal wird oft als Synonym f¨ ur hohe Regalbauten genutzt, tats¨ achlich triﬀt die Bezeichnung aber erst f¨ ur Regalh¨ ohen ab zw¨ olf m zu. Unter der Bezeichnung Hochregallager versteht man dar¨ uber hinausgehend ein Hochregalsystem mit fest installiertem Bedienger¨ at. Hochregale werden bis H¨ ohen von ca. 50 m ausgef¨ uhrt und k¨onnen u atze respektive mehrere 100 000 Beh¨alterpl¨atze um¨ber 100 000 Palettenpl¨ fassen. Solche Systeme werden h¨ auﬁg in Silobauweise realisiert, dabei tr¨agt die Regalkonstruktion Dach und W¨ ande und bildet so einen reinen Einzweckbau, der nur dem Zweck der Lagerung dient. Vorteilhaft ist dabei neben der kurzen Realisierungszeit und den vergleichsweise geringen Kosten unter anderem der

3.1 Lagersysteme

81

deutlich k¨ urzere Abschreibungszeitraum. Allerdings muss der Regalbau auch den zus¨ atzlichen Lastf¨ allen Rechnung tragen. Liftsysteme (Turmregale) Einen Sonderfall der Zeilenregale stellen die Liftsysteme oder Turmregale dar. In diesem Fall werden zwei Lagers¨aulen einander gegen¨ uberliegend angeordnet. Dazwischen verf¨ahrt vertikal ein spezielles Lastaufnahmemittel, das u ¨ ber eine Ziehtechnik Tablare zwischen den ¨ Lagerf¨ achern und dem Ubergabeplatz bewegt (s. Abb. 3.4). Durch die geringen bewegten Massen lassen sich dabei hohe Beschleunigungen realisieren und hohe Ein-/Auslagerleistungen erzielen. Neben Systemen mit festen Fachh¨ ohen innerhalb der Lagers¨aule werden auch Anlagen mit ﬂexibel deﬁnierbaren Fachh¨ohen ausgef¨ uhrt. Dazu wird anstelle absoluter Lagerf¨ acher ein Aufnahmeraster f¨ ur die Tablare mit einem Rastermaß von ca. 100 mm geschaﬀen, in das die Tablare eingeschoben werden. Nach Erfassung der Ladeeinheitenh¨ ohe wird das Tablar eingelagert und die entsprechenden dar¨ uber liegenden Rasterebenen werden f¨ ur weitere Einlagerungen gesperrt. Dies erm¨ oglicht eine Anpassung der Lagerfachh¨ohen an unterschiedliche G¨ uter und somit eine Volumenoptimierung, insbesondere bei variierenden Ladeeinheitenh¨ ohen. Fachbodenregal Fachbodenregale (engl. Shelves) besitzen f¨ ur jedes Lagerfach einen durchgehenden Lagerboden (ggf. auch Gitter), so dass Lagerg¨ uter mit beliebigen Abmessungen eingelagert werden k¨onnen. Durch die ﬂexibel einstellbaren Fachh¨ ohen, verschiedenste Formen der Fachteilung und eine große Menge an Zubeh¨ or kann das Fachbodenregal ideal an Bed¨ urfnisse der manuellen Kommissionierung angepasst werden und ist somit ein Standardregaltyp in der Kommissionierung. Die normale Regalh¨ohe betr¨agt zwei Meter. Unter Verwendung von Hilfsmitteln (z. B. Leitern) werden auch drei Meter hohe Ausf¨ uhrungen eingesetzt, wobei durch die zus¨atzlichen Bewegungsabl¨ aufe jedoch die Kommissionierleistung sinkt. Daneben werden zur Ausnutzung vorhandener Raumh¨ ohen auch mehrgeschossige Anlagen errichtet, ange direkt an den Regalst¨ bei denen die Zu- und Bewegungsg¨ utzen befestigt werden (s. Abb. 3.5). Wabenregal Beim Wabenregal werden mehrere Regale unmittelbar hintereinander angeordnet, so dass besonders tiefe Lagerf¨acher entstehen, die sich zur Lagerung von Langgut eignen. Wie bei Zeilenregalen u ¨blich, lassen sich durch eindeutige Fachzuordnung eine pr¨ azise Lagerverwaltung und verschiedenste Ein-/Auslagerstrategien realisieren. Die Lagerg¨ uter werden je nach Anwendungsfall direkt, also ohne Ladehilfsmittel, oder durch Nutzung spezieller Ladungstr¨ager (Langgutkassetten oder Langgutwannen) in das Regalfach eingelagert. Die Lagerfachbedienung bedarf aufgrund der langen und zum Teil schweren Lagerg¨ uter besonderer Verfahren und Hilfsmittel. Es existieren dazu spezielle Regalbedienger¨ate,

82

3. Grundlagen der Lager- und F¨ ordertechnik

¨ Abbildung 3.4. Prinzipdarstellung eines Liftsystems [Foto: SSI SCHAFER]

Stapler oder Krane. Aufgrund der großen Gangbreite eignet sich das System jedoch nur bei einer großen Menge einzulagernder Artikel oder G¨ uter. Kragarmregal An vertikalen oder geneigten Regalst¨ utzen werden auskragende Arme (Ausleger) befestigt, auf die das Lagergut abgelegt wird. Ebenso k¨onnen die Kragarme als Trennelemente f¨ ur stehende G¨ uter genutzt werden. Wie im Fall der Palettenregale k¨ onnen durch zus¨atzliche Auslegeb¨oden auch durchgehende Lagerﬂ¨ achen f¨ ur G¨ uter mit unterschiedlichen Abmessungen geschaﬀen werden. Ideal dient das Kragarmregal zur Lagerung von Langgut ¨ (Rohre oder Stangen) oder Tafelmaterial. Ublicherweise besitzen die Regale große Tragf¨ ahigkeiten und sind damit universell einsetzbare Lagersysteme. Die ﬂexible Nutzung der Regalebenen erfordert jedoch besondere Disziplin in der Lagergutverwaltung, da Ladeeinheiten an beliebiger Stelle eingela-

3.1 Lagersysteme

83

Abbildung 3.5. Mehrgeschossige Fachbodenanlage [Foto: BITO]

gert werden k¨ onnen. Wie bei den Zeilenregalen u ¨blich, besteht direkte Zugriﬀsm¨ oglichkeit auf jeden Artikel. Zur Regalbedienung kommen unterschiedliche Systeme zum Einsatz. Neben der manuellen Bedienung bei leichten Lasten werden insbesondere Stapler und Krane eingesetzt. In einigen F¨ allen werden die Kragarme bzw. Regalb¨ oden auch beweglich ausgef¨ uhrt, um den Zugriﬀ aus vertikaler Richtung (von oben) zu erm¨ oglichen. Statische Blockregale Statische Blockregale fassen die Ladeeinheiten zu einem kompakten Block zusammen. Durch die Regalanordnung kann nur von einer oder zwei Seiten auf den Block zugegriﬀen werden. Je nachdem, ob die Bedienung ein- oder zweiseitig erfolgt, l¨ asst sich als Auslagerstrategie nur LIFO oder FIFO realisieren (vgl. Abschn. 2.2.3). Bei Zugriﬀ auf im Block beﬁndliche Einheiten sind Umlagerungen unumg¨ anglich. Der wesentliche Vorteil dieser Lagertechniken besteht in der M¨oglichkeit, sehr hohe Volumennutzungsgrade staudruckfrei bei gleichzeitig geringem Fl¨ achenbedarf (durch große Lagerh¨ ohen) zu realisieren. Die Ladeeinheiten werden nur an den beiden Stirnseiten gest¨ utzt und m¨ ussen damit eine identische Breite aufweisen. Die Bewegung der Ladeeinheiten in schmalen

84

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.6. Einfahrregal [Foto: GEHRING]

Kan¨ alen stellt gleichzeitig hohe Qualit¨ atsanforderungen an die Ladeeinheiten bez¨ uglich Abmessungen und Formstabilit¨ at. Aus den genannten Eigenschaften leitet sich auch der bevorzugte Einsatzfall zur Lagerung großer Mengen weniger Artikel ab. Einfahr- und Durchfahrregale Der einfachste Fall der statischen Blockregallagerung stellt das Einfahr- bzw. Durchfahrregal dar. Die Regalst¨ utzen werden derart angeordnet, dass sich jeweils vertikale Spalten ergeben, die durch Flurf¨ orderzeuge befahren werden k¨ onnen. An den Regalst¨ utzen werden wie bei der Einplatzlagerung durchgehende Winkelproﬁle befestigt, auf die die Ladeeinheiten abgesetzt werden k¨ onnen. Bei der Ein- und Auslagerung wird die Ladeeinheit knapp oberhalb des Winkelproﬁls bewegt. Die Bedienung erfolgt ausschließlich u ¨ber Frontgabelstapler, die im Regal zur einfachen Fahrzeugf¨ uhrung seitlich gef¨ uhrt werden. Die Staplerkontur muss dabei der Regalform angepasst sein. Es kommen zur Bedienung zwei Bewegungsformen zum Einsatz: Einfahrregal Die Ladeeinheiten werden von der gleichen Seite ein- und ausgelagert. Daraus leitet sich zwangsl¨ auﬁg die LIFO-Strategie ab. Durchfahrregal Einlagerung und Auslagerung erfolgen auf gegen¨ uberliegenden Seiten. Dadurch wird die FIFO-Strategie realisiert. Eine Umsetzung von Ladeeinheiten innerhalb des Regalgangs ist nicht m¨oglich. Der F¨ ullungsgrad des Regals h¨ angt in hohem Maße von der Ein- und Auslagerfrequenz ab. Betrieb und Organisation Aufgrund dieser Eigenschaften ist die Nutzung als Vorratsregal f¨ ur unterschiedliche Artikel wenig sinnvoll, jedoch bei gleichen Artikeln pro Gang und dem Umschlag ganzer Einheiten durchaus vor-

3.1 Lagersysteme

85

teilhaft. Die Erfassung und Verwaltung einzelner Lagerpl¨atze ist technisch zwar m¨ oglich, l¨ asst sich jedoch in der Praxis unter anderem durch die manuelle Bedienung und notwendige Platzidentiﬁkation nur schwer realisieren. Dagegen l¨ asst sich das Lagerprinzip zur Puﬀerung eingehender oder ausgehender Sendungen sehr erfolgreich nutzen. Satellitenregale Dieser Regaltyp wird auch als Kanallager mit Satellit2 bezeichnet. Unterhalb der Lagerebene eines Kanals ist eine Fahrschiene f¨ ur ein Satelliten- oder Kanalfahrzeug vorhanden, das in diesem Kanal unabh¨angig verfahren und dadurch auf die jeweils erste Einheit eines Kanals zugreifen kann. Dadurch lassen sich wesentlich mehr Einheiten als im Falle des Einfahrregals ansprechen. Zumeist wird die Einfahrstrategie, also LIFO, angewendet. Ebenso ist der beiderseitige Zugriﬀ auf einen Kanal m¨ oglich. Verschiedene Kanalfahrzeuge sind dazu in der Lage, unter gelagerten Einheiten hindurchzufahren. Damit wird auch FIFO theoretisch m¨ oglich. Um einen hohen F¨ ullungsgrad bei unterschiedlichen Artikeln zu erreichen, m¨ ussten die Ladeeinheiten jedoch h¨auﬁg umgelagert werden. Betrieb und Organisation Mittels automatisierter Satellitenfahrzeuge l¨ asst sich eine sehr ﬂexible Lagerorganisation realisieren. Durch die unabh¨ angige Operation der Satellitenfahrzeuge im Regal und den m¨oglichen Einsatz einer Vielzahl von Fahrzeugen lassen sich kompakte Lagerung und hohe Durchsatzleistung vereinen. Mit wachsendem Mischungsgrad der Kan¨ale (verschiedene Ladeeinheiten in einem Gang) und notwendigem Einzelzugriﬀ steigt jedoch auch der Umlagerungsaufwand sowie der Aufwand der erforderlichen Lagerreorganisation. Diese Funktionalit¨ at muss durch die Lagersteuerung bereitgestellt werden. Ebenso ist eine fr¨ uhzeitige Vorholung einzelner Ladeeinheiten in die N¨ ahe der Auslagerpunkte ein entscheidender Faktor zur Realisierung einer hohen Reaktionsgeschwindigkeit f¨ ur Auslagerauftr¨age. 3.1.3 Dynamische Regallager Aus verschiedenen Gr¨ unden werden Lagersysteme dynamisch ausgef¨ uhrt, d.h. die Ladeeinheiten zwischen Ein- und Auslagerung bewegt. Der damit erzielte Nutzen ist insbesondere durch • Wegeinsparung in der Kommissionierung und Erh¨ohung der Kommissionierleistung, • hohe Umschlagleistung bei kompakter Lagerung und • Nutzung der Vorteile der Block- und Zeilenlagerung gekennzeichnet.

2

ein Produkt der Westfalia F¨ ordertechnik

86

3. Grundlagen der Lager- und F¨ ordertechnik

Bei der dynamischen Lagerung werden zwei grundlegende Prinzipien unterschieden: feststehende Lagereinheiten in bewegten Regalen und bewegte Lagereinheiten in feststehenden Regalen. Zur ersten Gruppe z¨ahlen Verschieberegale und Umlaufregale, zur zweiten die verschiedenen Formen der Durchlaufregale. Verschieberegale Diese Regalform stellt die Erweiterung eines statischen Zeilenregals um eine verfahrbare Plattform, einen so genannten Fahrschemel, dar. Auf solche Fahrschemel k¨ onnen alle Regaltechniken wie Paletten-, Beh¨alter-, Fachbodenoder Kragarmregale montiert werden, allerdings bei begrenzter H¨ohe (bis ca. zehn Meter). Dadurch k¨ onnen einzelne Regalzeilen durch seitliches Verfahren zu einem kompakten Block zusammengef¨ uhrt werden und die Regalg¨ange entfallen (s. Abb. 3.7). Ebenso k¨ onnen einzelne Regalzeilen aus einem kompakten Block heraus auch stirnseitig verfahren ( herausgezogen“) werden. ” ¨ In einem solchen System kann auf jede einzelne Lagereinheit nach Oﬀnen des Ganges bzw. Aktivieren der Regalzeile zugegriﬀen werden. Die relativ langsame Verfahrgeschwindigkeit der großen und schweren Regaleinheiten im Bereich von 3–5 m/min l¨ asst jedoch nur eine geringe Durchsatzleistung bei einem gleichm¨ aßig verteilten Zugriﬀsverhalten zu. Entscheidend f¨ ur die Durchsatzleistung ist daher auch die Ein- und Auslagerstrategie, die insbesondere auf eine Minimierung der Regalbewegungen abzielen sollte. Eine solche Funktion ist im Fall des Einsatzes von Verschieberegalen in der Lagersteuerung zu implementieren. Aufgrund der Funktionscharakteristik ist der Einsatz dort sinnvoll, wo eine hohe Raumnutzung bei geringer Lagerleistung gefordert ist, beispielsweise in Archiven, aber auch in K¨ uhll¨ agern. Umlaufregale Umlaufregale sind prinzipiell um Lagerkapazit¨aten erg¨anzte Stetigf¨ordermittel (Kreis- oder Umlauﬀ¨ orderer). Gegen¨ uber einem Fachbodenregal k¨onnen Gangbreiten reduziert werden, da die Umlenkradien sehr gering ausgef¨ uhrt werden k¨ onnen. Diese Technik wird h¨ auﬁg in Kommissioniersystemen nach dem Prinzip Ware-zur-Person eingesetzt. Durch parallelen Einsatz mehrerer Umlaufregale kann die Kommissionierleistung deutlich gesteigert werden. Vertikale Umlaufregale (Paternosterregal) An zwei vertikal umlaufenden Ketten sind horizontale Wannen drehbar befestigt. Diese dienen zur Aufnahme sowohl von Kleinteilen als auch Langgut (s. Abb. 3.8). Der Kommis¨ sionierer beﬁndet sich am zentralen Ubergabepunkt. Ebenso sind mehrere ¨ Ubergabepunkte auf verschiedenen Ebenen m¨ oglich. Auf geringer Standﬂ¨ache ohe relativ viele Artikel mit geringer lassen sich durch Nutzung der Raumh¨ oder mittlerer Menge pro Artikel einlagern. Die Verkleidung des Systems dient dem Personenschutz und ebenso dem Schutz vor unerlaubtem Zugriﬀ.

3.1 Lagersysteme

87

Abbildung 3.7. Verschieberegal [Foto: META]

¨ Abbildung 3.8. Vertikales Umlaufregal (Paternosterregal) [Foto: HANEL]

Die realisierbare Kommissionierleistung an einem System h¨angt in hohem Maße von der Bauh¨ ohe und dem Zugriﬀsverhalten auf die gelagerten Artikel ab. Zur Erreichung einer akzeptablen Leistung ist die Zugriﬀsreihenfolge auf die Lagerplatzreihenfolge abzustimmen, um st¨andige Reversierfahrten zu vermeiden. Horizontale Umlaufregale (Karusselllager) An einer horizontal umlaufenden F¨ orderkette werden einzelne Lagerfelder befestigt, die eine Fach¨ bodenregals¨ aule oder Ahnliches aufnehmen. Die Bedienung bzw. Entnah-

88

3. Grundlagen der Lager- und F¨ ordertechnik

me durch den Kommissionierer erfolgt in der Regel am stirnseitigen Wendepunkt, wobei typischerweise mehrere Regale parallel angeordnet werden. F¨ ur ein anzusprechendes Lagerfach wird die Kette bewegt, bis sich die relevante Lagers¨ aule bzw. das Lagerfeld am Entnahmepunkt beﬁndet. Zur weiteren Fl¨ acheneinsparung k¨ onnen auch mehrere Regale (zwei bis drei) u uhrungen (bis ca. sieben ¨bereinander gesetzt oder bei besonders hohen Ausf¨ Meter Bauh¨ ohe) auch vertikal verfahrbare Plattformen eingesetzt werden. Der Betrieb in der Kommissionierung erfolgt analog zum Paternosterregal. Die großen Baul¨ angen der Karusselllager von bis zu 50 m bieten jedoch erheblich h¨ ohere Lagerkapazit¨ aten. Eine besondere Bauform stellen so genannte Beh¨alter-Umlaufregale dar. Die Systeme dienen prim¨ ar der kurzzeitigen Puﬀerung, beispielsweise zur Konsolidierung von Teilauftr¨ agen im Versandbereich. W¨ahrend beim klassischen Umlaufregal in erster Linie einzelne Artikel oder Gebinde entnommen werden, wird beim Beh¨ alter-Umlaufregal der gesamte Beh¨alter gewechselt. Deshalb ist in diesem Fall auch eine hohe Umschlagleistung maßgeblich. Durch separate, u orderebenen kann jede einzelne Ebene ¨ bereinanderliegende F¨ unabh¨ angig verfahren werden. Bei der Ein-/Auslagerung werden zu entleerende F¨ acher und freie F¨ acher u ¨ bereinander positioniert, so dass von einer zentralen Wechseleinrichtung (Stufenlift mit Mehrfach-Greifeinrichtungen) alle Operationen in einem Arbeitsschritt durchgef¨ uhrt werden k¨onnen. Durchlaufregal Durch Einf¨ ugen einer F¨ orderebene in einen feststehenden Regalblock k¨onnen sich die Lagereinheiten in den Lagerbl¨ ocken bewegen. Die Lagereinheiten werden entweder an der r¨ uckseitigen Regalfront in einen Lagerkanal gegeben, zur vorderseitigen Regalfront gef¨ ordert und dort entnommen oder an der Frontseite in den Lagerkanal eingeschoben und dort wieder entnommen (Einschubregal). In den Kan¨ alen beﬁnden sich die Lagereinheiten hintereinander. Zugriﬀ ist grunds¨ atzlich nur auf die vordere Regalfront m¨oglich. Durch das Durchlaufprinzip werden Beschickung und Entnahme getrennt angig voneinander ablaufen. Außerdem wird das FIFOund k¨ onnen so unabh¨ Prinzip zwangsl¨ auﬁg und ohne zus¨ atzlichen Steuerungsbedarf gew¨ahrleistet (bzw. LIFO im Fall des Einschubregals). Der entscheidende Vorteil liegt neben der kompakten Lagerung in der Vorhaltung vieler Artikel im direkten Zugriﬀ bei gesichertem Nachschub. Dadurch kann sich auch eine erhebliche Stirnﬂ¨ achenverkleinerung der Lagerﬂ¨ ache ergeben, die wiederum zu Wegeinsparungen in der Kommissionierung und der Lagerbedienung f¨ uhrt. Durchlaufregale werden sowohl f¨ ur leichte als auch schwere St¨ uckg¨ uter realisiert. Entscheidend f¨ ur den Betrieb ist, dass in den einzelnen Lagerkan¨alen artikelreine bzw. auftragsreine Ladeeinheiten gebildet werden. Umlagerungen zum Zugriﬀ auf nicht an der Regalfront beﬁndliche Einheiten sind praktisch nicht m¨ oglich. Daher macht der Einsatz in der Kommissionierung nur

3.1 Lagersysteme

89

Abbildung 3.9. Durchlaufregal mit Rollenf¨ ordertechnik zur Kommissionierung nach dem Prinzip Pick-to-Belt [Foto: BITO]

dort Sinn, wo aus Durchsatzgr¨ unden mehrere Einheiten vorgehalten werden m¨ ussen, ohne jedoch ganze Paletten bereitzustellen. Rollpalettensysteme Diese Systeme stellen spezielle Formen der Einschubregale dar, bei denen die Lagereinheit auf einer rollf¨ahigen Palette steht und in die Schienen eines Lagerkanals eingeschoben wird. Durch frontseitig angebrachte Haken werden die in der Gasse beﬁndlichen Lagereinheiten zu einem Zug gekoppelt, der durch Verschieben der gassenseitigen Lagereinheit bewegt wird. Durch Installation ausreichender Ein-/Auslagerkapazit¨aten k¨ onnen hochdynamische Lager- und Umschlagsysteme realisiert und auch gemischte Kan¨ ale gebildet werden. F¨ ur eine umfassende Behandlung der Rollpalettentechnik sei auf [83] verwiesen. 3.1.4 Regalvorzone In der Vorzone eines Regalsystems fallen unterschiedliche Aufgaben an. Einzulagernde Einheiten sind auf die Gassen zu verteilen, Kommissionierpl¨atze vor dem Regal sind mit Bereitstelleinheiten und Leerbeh¨altern zu versorgen und gegebenenfalls Sammeleinheiten abzutransportieren. Weiterhin sind ausgelagerte Einheiten in Richtung Versand zu transportieren oder auf andere Regalgassen zu verteilen, im Rahmen der Inventur m¨ ussen Lagerein-

90

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.10. Regalvorzone mit Stetigf¨ ordertechnik. Zur Vermeidung gegenseitiger Behinderungen der zu- und abgehenden Str¨ ome sind die F¨ orderstr¨ ange separat und aus Platzgr¨ unden auf verschiedenen Ebenen angeordnet. [Foto: KHT]

heiten zur Erfassung vorgeholt und wieder eingelagert werden usw. Daraus resultieren verschiedenste Transportrelationen und kreuzende Verkehre. Zwei Punkte beeinﬂussen die Leistungsf¨ ahigkeit der Lagervorzone maßgeblich: eine leistungsf¨ ahige F¨ ordertechnik und ein geeignetes Steuerungskonzept. Seitens der F¨ ordertechnik kommen Rollenbahnen, Tragkettenf¨orderer, Drehweichen oder Verschiebewagen zum Einsatz. Je nach Regalbedienger¨at erfolgt die Bereitstellung beiderseits des Ganges oder u ¨ bereinander. Davor sind ausreichend dimensionierte Puﬀerpl¨ atze vorzusehen (s. Abb. 3.10).

3.2 F¨ ordersysteme Als F¨ordermittel werden im Allgemeinen die technischen Systeme des Materialﬂusses verstanden, die im Wesentlichen die innerbetriebliche Ortsver¨anderung von G¨ utern bewirken. Beim Transport außerhalb der Lager- und Distributionssysteme kommen dagegen so genannte Verkehrsmittel zum Einsatz, die nicht im Augenmerk der vorliegenden Betrachtungen stehen. Der Ausrichtung dieses Buches entsprechend sollen schwerpunktm¨aßig die F¨ordermittel f¨ ur den St¨ uckguttransport behandelt werden. F¨ ordermittel lassen sich anhand ihrer Arbeitscharakteristik in zwei Gruppen unterteilen, die sich im Wesentlichen durch folgende Eigenschaften auszeichnen:

3.2 F¨ ordersysteme

91

Stetigf¨ orderer besitzen eine kontinuierliche Arbeitsweise und sind zumeist ortsfest installiert. Sie verf¨ ugen u ¨ ber eine hohe F¨orderleistung, gemessen in St¨ uck/Zeiteinheit, und produzieren einen kontinuierlichen bzw. quasikontinuierlichen F¨ orderstrom. Sie erlauben vielf¨altige Linienf¨ uhrungen im Raum und die M¨ oglichkeit einer jederzeitigen Bereitschaft zur Aufnahme oder Abgabe von G¨ utern. Die kontinuierliche Arbeitsweise und die einfache Funktion erm¨ oglichen die gute Automatisierbarkeit und Kontrolle der Warenstr¨ ome im F¨ ordersystem. Unstetigf¨ orderer sind Einzelgewerke, die einzelne bzw. wenige F¨orderg¨ uter von einer Quelle zu einem Ziel transportieren und mit dem F¨ordergut verfahren. Dieser Prozess wird als Arbeitsspiel bezeichnet. Sie k¨onnen je nach Bauweise beliebige Punkte entlang eine Linie, in der Fl¨ache oder im Raum anfahren. Sie eignen sich daher in erster Linie zur Bedienung vieler Auf- und Abgabepunkte, zum Transport großer Gewichte und zur ¨ Uberbr¨ uckung langer Strecken. Je nach Systemauspr¨agung steigen mit der Einsatzﬂexibilit¨ at auch der Steuerungsaufwand und die Anforderungen an die Automatisierung. 3.2.1 Stetigf¨ orderer Rollenf¨ orderer Bei Rollenf¨ orderern wird das F¨ordergut u ¨ber ortsfeste, drehbare Rollen gef¨ uhrt (s. Abb. 3.11). Der dissipative Bewegungswiderstand wird auf die Lagerreibung in der Rolle und die Walkung des Gutes beim Passieren der Rolle reduziert. Daraus resultiert ein geringer Energieaufwand zur F¨ orderung der St¨ uckg¨ uter. Die Bewegung der G¨ uter wird manuell, bei geneigten Rollenf¨ orderern durch Schwerkraft sowie durch verschiedene Antriebsformen motorisch realisiert. Bei hohen F¨ ordergutgewichten (ca. 1 t) kommen dabei F¨ orderketten zum Einsatz, bei leichtem St¨ uckgut (<100 kg) u ¨ berwiegend uckt werden. Neben RolAntriebsriemen, die an die Rollenunterseite gedr¨ lenk¨ orpern aus Stahlblech werden zunehmend auch Kunststoﬀrollen eingesetzt. Wesentliche Voraussetzung zur F¨ ordereignung des Gutes ist die Beschaffenheit des F¨ ordergutbodens, der eben und ausreichend formstabil sein muss. Der Rollenabstand beeinﬂusst maßgeblich die Qualit¨at der Bewegung. Mit wachsendem Rollenabstand steigt die Sch¨ uttelneigung des Gutes auf dem F¨ orderer und damit die Belastung des F¨ ordergutes. Das Abw¨ alzen der Rolle unter dem F¨ ordergut f¨ uhrt zu einem Antriebsschlupf, der unter anderem vom F¨ ordergut abh¨angig ist. Die Position eines F¨ ordergutes auf der F¨ orderstrecke unterliegt daher Abweichungen und kann nicht deterministisch bestimmt werden. Sie muss daher in automatisierten Anlagen an bestimmten Stellen durch geeignete Sensoren (i. Allg. Lichtschranken) erfasst werden. Besondere Bauformen erm¨ oglichen die Nutzung der F¨orderstrecke als Puffer. Da ein Aufstauen einer Reihe von F¨ orderg¨ utern auf einer angetriebenen

92

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.11. Rollenf¨ orderer. Im Einlaufbereich sind die Rollen schr¨ ag gestellt, um eine Ausrichtung der F¨ orderg¨ uter auf die im Bild rechte Seitenf¨ uhrung zu erzielen. [Foto: SIEMENS DEMATIC]

F¨orderstrecke zu einem wachsendem Staudruck auf die vorderen G¨ uter f¨ uhrt, muss ab einer bestimmten Staul¨ ange der Rollenbereich der wartenden Rollen deaktiviert werden, um die Antriebskraft der Rollen aufzuheben. Zu diesem Zweck existieren verschiedene Bauformen, die als Rollenstauf¨orderer bezeichnet werden. Der einfache Aufbau der Rollenf¨ orderer stellt in vielen F¨allen eine g¨ unstige Alternative bei einfachen F¨ orderaufgaben dar. Allerdings weisen Rollenf¨orderer auch relativ hohe Ger¨ auschpegel auf, die insbesondere durch das Auftreﬀen der G¨ uter auf die Rollen und durch die Art der St¨ uckg¨ uter sowie Rollenteilung und -lagerung bestimmt werden. Bandf¨ orderer Die Bezeichnung Bandf¨ orderer ist der Oberbegriﬀ f¨ ur Stetigf¨ ordermittel, bei denen ein durchgehendes, angetriebenes Element (Band, Gurt, Riemen oder Drahtgeﬂecht) zur Aufnahme und zum Transport des Gutes eingesetzt wird. Das F¨ ordergut liegt fest am F¨orderband an und vollzieht somit keine Relativbewegung zum antreibenden F¨ordermittel, wodurch eine gleichm¨ aßige, sichere und schonende F¨ orderung realisiert wird. Der am h¨ auﬁgsten eingesetzte Bandf¨ orderer ist der so genannte Gurtf¨orderer (s. [63]), bei dem der F¨ ordergurt so dimensioniert ist, dass das gr¨oßte betriebsinterne F¨ ordergut vollst¨ andig auf dem Gurt auﬂiegt. Unterhalb des Gurtes werden Tragrollen oder Tragﬂ¨ achen angeordnet, die das Gewicht des

3.2 F¨ ordersysteme

93

Abbildung 3.12. Gurtf¨ orderer: Wendelkurve [Foto: AXMANN]

F¨ordergutes sowie des Gurtes aufnehmen. Der F¨ordergurt muss im Wesentlichen folgende Anforderungen erf¨ ullen: • F¨ ahigkeit, hohe Zugkr¨ afte bei geringer Dehnung aufzunehmen, • geringer Walkwiderstand bei der Umlenkung, • geringe Haftung auf der Gurtunterseite (Laufseite) zur Reduktion der er¨ forderlichen Antriebsleistung, jedoch ausreichende Reibbeiwerte zur Ubertragung der Antriebskr¨ afte an der antreibenden Trommel, • je nach Einsatzfall unterschiedliche Reibbeiwerte auf der Gurtoberseite (Tragseite). Um den unterschiedlichen Anforderungen zu gen¨ ugen, gelangen Verbundmaterialien zum Einsatz. Einlagen aus Polyamid, Polyester oder Aramid die¨ nen u Zwischenlagen aus ¨ berlicherweise zur Aufnahme der Zugkr¨afte. Uber Gummi oder Kunststoﬀ sind die Decklagen verbunden, die neben den genannten Anforderungen den Gurt außerdem widerstandsf¨ahig und best¨andig gegen Alterung und ¨ außere Einﬂ¨ usse machen sollen. Beim St¨ uckguttransport werden Gurtf¨ orderer zum Transport von leichtem St¨ uckgut bis ca. 50 kg eingesetzt. Durch geeignete Paarung von Gurt und Tragkonstruktion kann das F¨ ordermittel sehr leise ausgef¨ uhrt wer-

94

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.13. Kettenf¨ orderer: Flexibles Gliederband f¨ ur leichtes St¨ uckgut (Tragkettenf¨ orderer) [Foto: FLEXLINK]

den. Neben dem Normalfall der geraden F¨ orderstrecke k¨onnen bei seitlicher Gurtabst¨ utzung auch kurveng¨ angige Gurtf¨orderer realisiert werden (s. Abb. 3.12). Im Betrieb zeichnet sich der Gurtf¨ orderer durch die pr¨azise Steuerbarkeit und hohe Dynamik aus, da das F¨ ordergut durch relativ hohe Reibbeiwerte fest auf dem Gut auﬂiegt. Dadurch lassen sich unter anderem auch Steigungsstrecken realisieren (s. Abb. 3.12). Durch Verwendung sehr schmaler Gurte oder Riemen werden auch Stauf¨ orderer aufgebaut, bei denen das F¨ordergut im Staubetrieb vom Riemen abgehoben wird. Kettenf¨ orderer Als kennzeichnendes Merkmal gelangt bei Kettenf¨orderern als Trag- und/oder Zugorgan eine Kette zum Einsatz. Das F¨ordermittel Kette vereint vorteilhaft hohe Tragf¨ ahigkeiten, geringe Umlenkradien und die einfache Montierbarkeit von Zusatzelementen. Entsprechend vielf¨altig ist deshalb der Einsatz in der F¨ order- und Lagertechnik (vgl. Abschn. 3.1.3). Die g¨ angigsten eingesetzten Kettenf¨ orderer sind in Tabelle 3.2 aufgef¨ uhrt. Detaillierte Angaben zu den einzelnen Prinzipien sind in [24] enthalten.

3.2 F¨ ordersysteme

95

Tabelle 3.2. Bauformen von Kettenf¨ orderern im St¨ uckgutbereich Bezeichnung

Funktion

Fördergeschwindigkeit

Einsatzfelder

Tragkettenförderer

Das Fördergut ruht auf 1–3 parallel angeordneten Kettensträngen,die in entsprechend geformten Schienen verlaufen. Die Ketten werden horizontal oder vertikal umgelenkt.

0,2 bis 1,0 m/s

horizontale und geneigte Förderung; Umsetzer

Schleppkettenförderer

Die Kette ist reines Zugorgan und wird ggf. unter der Förderebene (unterflur) geführt. Das Fördergut wird auf Tragrollen, Schienen, Wagen oder Gabelhubwagen gefördert.

0,2 bis 0,5 m/s

Umschlagzentren, Transport schwerer Lasten; manuelle Auf- und Abgabe großer Einheiten

Schaukelförderer + Paternoster

Zwischen zwei vertikal (beim Paternoster parallel versetzt) umlaufenden Ketten sind Lastträger zur Aufnahme der Güter angeordnet.

ca. 0,3 m/s

Vertikaltransport zwischen Stockwerken

Kreisförderer

An einer beliebig im Raum verlaufenden Kette sind Lastgehänge montiert, die zur Aufnahme der Fördergüter dienen. Die Beladung erfolgt manuell oder mechanisch.

0,2 bis 1,5 m/s

Transport großer Mengen flurfrei über weite Distanzen

Power&Free (Schleppkreisförderer)

Ähnlich wie Kreisförderer aufgebaut, existiert jedoch eine separate Förderbahn für die Lastgehänge, so dass die Lastgehänge von der umlaufenden Förderkette entkoppelt werden können.

0,2 bis 0,5 m/s

größere Fördernetze mit verschiedenen Kreisläufen und Pufferbahnen

3.2.2 Unstetigf¨ orderer W¨ ahrend im Fall der Stetigf¨ orderer die gesamte F¨orderstrecke auf das gr¨oßte, schwerste oder empﬁndlichste Gut auszulegen ist, reduziert sich die Dimensionierung eines F¨ ordersystems mit Unstetigf¨orderer(n) im Wesentlichen auf die geeignete Gestaltung des Transportmittels. Die fahrweggebundenen Investitionen reduzieren sich dadurch. Außerdem kann bei einem gr¨oßeren System mit mehreren Fahrzeugen ein Spektrum unterschiedlicher Fahrzeugtypen eingesetzt werden, welches das Anforderungsschema entsprechend ber¨ ucksichtigt. Unstetigf¨ orderer werden anhand ihrer Verfahrbarkeit in zwei grundlegende Typen klassiﬁziert:

96

3. Grundlagen der Lager- und F¨ ordertechnik

Frei verfahrbar Die F¨ ordermittel sind in der Ebene beliebig verfahrbar. Durch Anbaueinrichtungen oder Hubger¨ uste wird auch die dritte Dimension erschlossen. Die freie Wahl des Bewegungsortes stellt hohe Anforderungen an die Fahrsteuerung: Bestimmung des Ortes im Raum, an Betriebs- und Verkehrssituationen angepasste Fahrweise bzw. Betrieb, Kollisionsvermeidung etc. Die Steuerung u ¨ bernimmt daher zum u ¨ berwiegenden Teil der Mensch, dessen kognitive F¨ahigkeiten alternativ nur durch aufw¨ andige Steuerungs- und Sensoreinrichtungen erbracht werden k¨ onnen, wie sie beispielsweise in Fahrerlosen Transportsystemen zum Einsatz gelangen. Gef¨ uhrt verfahrbar Die F¨ ordermittel sind durch Laufschienen spurgef¨ uhrt, die bodenmontiert (ﬂurgebunden), auf St¨ utzen (aufgest¨andert) oder außerhalb des eigentlichen Arbeitsbereiches (ﬂurfrei) angeordnet sind. Da eine aktive Lenkung nicht erforderlich ist, reduziert sich der Steuerungsaufwand erheblich. Die meisten gef¨ uhrten Unstetigf¨orderer eignen sich daher auch besonders zur Automatisierung. Flurf¨ orderzeuge Unter diesem Oberbegriﬀ werden alle ﬂurgebundenen Unstetigf¨orderer zusammengefasst. Dabei fallen unterschiedliche Aufgabenstellungen an, welche die Gestaltung der Flurf¨ orderzeuge wesentlich beeinﬂussen: • Transport von St¨ uckg¨ utern u ¨ ber kurze oder lange Entfernungen • Umschlag von St¨ uckg¨ utern zwischen Arbeitsmitteln oder Wechsel zwischen Arbeitsstationen • Stapeln von St¨ uckg¨ utern und ggf. Transport gestapelter Einheiten • Regalbedienung: Ein-/Auslagerung von St¨ uckg¨ utern im Regal und Kommissionierung in der Regalﬂ¨ ache Je nachdem, in welcher H¨ auﬁgkeit ein oder mehrere Aufgaben auszuf¨ uhren sind, werden unterschiedliche Typen der Flurf¨ orderzeuge eingesetzt. F¨ ur reine Transportaufgaben kommen Wagen oder Schlepper mit Anh¨angern zum Einsatz (Transportger¨ate), die zur Be- und Entladung allerdings eines weiteren F¨ ordermittels oder des Menschen bed¨ urfen. Universalger¨ate bzw. universelle Umschlagger¨ ate k¨ onnen Ladeeinheiten selbstst¨andig aufnehmen und sie zum Abgabepunkt bzw. zum Lagerfach transportieren, um sie dort eigenst¨andig abzugeben. Zur Optimierung der Raumnutzung, Umschlag- oder Kommissionierleistung werden im Bereich der Regalbedienung spezielle Lagerger¨ate eingesetzt, die sich durch schmale Arbeitsg¨ ange, große Einlagerh¨ohen oder durch die M¨ oglichkeit der Kommissionierung in der Regalfront auszeichnen, gleichzeitig aber auch hohe Anforderungen an die Bodenqualit¨at stellen und nicht universell eingesetzt werden k¨ onnen.

3.2 F¨ ordersysteme

Abbildung 3.14. JUNGHEINRICH]

Verschiedene

Flurf¨ orderzeuge

im

Lagereinsatz

97

[Foto:

Transportger¨ ate Die u ¨ berwiegend elektrisch angetriebenen Wagen und Schlepper werden vorwiegend dort eingesetzt, wo regelm¨aßig Transportstr¨ ome u uber ¨ber große Distanzen und wechselnde Ziele anfallen. Gegen¨ l¨ angeren Transporten mit Gabelstaplern bieten sie eine h¨ohere Wirtschaftlichkeit und aufgrund der besseren Sicht in Fahrtrichtung auch ein geringeres Gef¨ ahrdungspotenzial. Bei niedrigen Trag- und Zuglasten werden die Ger¨ate dreir¨adrig (bis ca. 8,5 kN Zugkraft, s. Abb. 3.15), mit einem nicht angetriebenen und gelenkten Vorderrad ausgef¨ uhrt, wodurch die Einzelger¨ ate sehr wendig sind. Bei gekoppelten Wagenz¨ ugen (Schlepper mit mehreren Anh¨angern) ist f¨ ur die erforderliche Trassenbreite die Radf¨ uhrung der Anh¨ anger entscheidend. Anh¨anger mit nur einer gelenkten Achse weisen ein einschn¨ urendes Kurvenverhalten auf, das mit steigender H¨ angerzahl große Trassenbreiten erfordert. Um demgegen¨ uber die Spur des ziehenden Fahrzeuges einzuhalten, sind Vierrad-Lenkungen mit gekoppelten Achsen erforderlich. Umschlagger¨ ate Das wesentliche Merkmal der Umschlagger¨ate ist die F¨ ahigkeit, Ladeeinheiten eigenst¨ andig aufzunehmen und abzugeben. F¨ ur geringe Umschlagleistungen existieren verschiedene manuell betriebene Ger¨ate wie Karren (Stechkarren) und Gabelhubwagen. Die weit verbreiteten Gabelhubwagen sind auf Standardpalettenmaße (Euro- und Industriepaletten) ausgelegt. Mit steigenden Umschlaggewichten und -frequenzen ist die alleinige

98

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.15. Schlepper [Foto: STILL]

Nutzung der menschlichen Arbeitskraft jedoch nicht wirtschaftlich, weshalb verschiedene Stufen der Motorisierung zum Einsatz gelangen. Neben dem Antrieb der Fahr- und Hubfunktion sind die Wagen mit Fahrerst¨ anden oder -sitzen ausger¨ ustet, um auch die Transportgeschwindigkeit zu erh¨ ohen. In der Kommissionierung werden außerdem Gabelhubwagen mit hebbarer Plattform f¨ ur den Kommissionierer eingesetzt, um auch die zweite Regalebene f¨ ur die manuelle Kommissionierung zu erschließen. Wird neben der bodenebenen Aufnahme und Abgabe von Ladeeinheiten auch der Zugriﬀ in h¨ oheren Ebenen oder die Stapelbildung erforderlich, kommen Stapelger¨ate zum Einsatz. Das verbreitetste Ger¨at ist der Gabelstapler (auch Frontstapler, Gegengewichtstapler, s. Abb. 3.16). An einem drei- oder vierr¨ adrigen Fahrrahmen ist ein vertikales Hubger¨ ust mit dem Gabeltr¨ager befestigt, das die Last außerhalb der Radbasis des Gabelstaplers aufnimmt. Zur Erreichung hoher Traglasten wird an der lastabgewandten Seite ein Gegengewicht angebracht. Um m¨ oglichst große Hubh¨ ohen bei geringer Fahrzeugh¨ohe zu realisieren, sind die Hubger¨ uste teleskopierbar ausgef¨ uhrt. In einem U-Proﬁl ist ein Innenrahmen angeordnet, der wiederum weitere Rahmen aufnehmen kann. Die Hubbewegung erfolgt u uge, die durch seitlich oder mittig ange¨ ber Kettenz¨ ordnete Hydraulikzylinder bet¨ atigt werden. Um die Gutaufnahme zu erleichtern, wird der gesamte Hubrahmen geringf¨ ugig in Richtung Gut geschwenkt. Analog erfolgt die Schwenkung in Richtung Fahrzeug zum sicheren Transport der Ladeeinheit auf den Gabelzinken. Neben zul¨assigem Lastgewicht und maximaler Hubh¨ ohe ist der Freihub, d.h. die maximale Hubh¨ohe der Gabelzinken ohne Ausfahren (Teleskopieren) des Mastes, eine entscheidende Kenngr¨ oße f¨ ur die Funktionalit¨ at des Hubger¨ ustes, da so auch bei begrenzten Raumh¨ ohen operiert werden kann. Die Gutaufnahme und -abgabe erfolgt grunds¨ atzlich frontal. Die bevorzugte Fahrtrichtung ist mit der Gabel voraus, was bei großvolumigen Lasten durch eingeschr¨ankte Sicht problematisch sein

Abbildung 3.16. JUNGHEINRICH]

Frontgabelstapler

bei

der

3.2 F¨ ordersysteme

99

Lkw-Be-/-Entladung

[Foto:

kann. Eine große Auswahl an Anbauger¨ aten erm¨oglicht ein großes Einsatzspektrum mit Anwendungen auch außerhalb der eigentlichen Transport- und Umschlagaufgabe. Dreiradfahrzeuge besitzen auf der lastabgewandten Seite ein einzelnes gelenktes Rad, daraus resultieren ein einfacher Systemaufbau und ein geringer Wenderadius. Wenn h¨ ohere Traglasten realisiert werden sollen, kommen Vierradfahrzeuge zum Einsatz. Diese haben auf der lastabgewandten Seite eine Pendelachse, besitzen eine h¨ ohere Fahrstabilit¨at (insbesondere gegen¨ uber der Gefahr des seitlichen Kippens), weisen jedoch auch gr¨oßere Kurvenradien auf. Die Art der Fahrwerksanordnung und die m¨ogliche Traglast bestimmen auch dadurch maßgeblich die erforderliche Breite der Arbeitsg¨ange im Lager, dass Frontgabelstapler zur Gutaufnahme und -abgabe in jedem Fall eine 90◦ -Drehung durchf¨ uhren m¨ ussen. Im innerbetrieblichen Einsatz werden u ¨ berwiegend Elektrostapler eingesetzt, im außerbetrieblichen Einsatz und bei großen Lastgewichten vorzugsweise Dieselstapler. Im Mischbetrieb (Innen- und Außeneinsatz) bietet sich neben Elektrostaplern auch der Einsatz von Treibgasstaplern an. Die Eignung f¨ ur den Außeneinsatz h¨ angt dar¨ uber hinaus von der Wahl der Bereifung ab. Lagerger¨ ate Darunter fallen alle Flurf¨ orderzeuge, die ausschließlich oder nahezu u ¨ berwiegend zur Regalbedienung eingesetzt werden. Spreizenstapler besitzen zwei auskragende Arme, die unterhalb der aufzunehmenden Last, d. h. unterhalb der Gabelzinken, angeordnet sind (s. Abb. 3.17). Ist die Last vom Boden aufzunehmen, muss der Abstand der Radarme oder Spreizen derart bemessen sein, dass die Ladeeinheit dazwischen passt bzw. die Radarme in die Aussparungen einer Palette passen. Bei

100

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.17. Spreizenstapler [Foto: STILL]

schmaleren Abst¨ anden ist eine Bodenaufnahme nicht mehr m¨oglich und die Ladeeinheit kann nur einem Lagerfach entnommen werden, wenn ein unteres Freimaß von ca. 250 mm besteht. Der Transport bzw. das Handling der Ladeeinheit innerhalb der Radbasis er¨ ubrigt das beim Gabelstapler erforderliche Gegengewicht und l¨ asst dadurch eine deutlich k¨ urzere Bauweise zu. Die Ger¨ ate besitzen typischerweise Dreiradantrieb. Um Ladeeinheiten unabh¨ angig von ihrer Breite auch bodeneben aufnehmen zu k¨ onnen, besitzen Schubmaststapler ein in den Radarmen verfahrbares Hubger¨ ust, das zur Gutaufnahme und -abgabe in eine vordere Position verfahren wird, in der die Radarme die Gutaufnahme nicht mehr behindern (s. Abb. 3.18). Zum Transport wird der Hubmast wieder zur¨ uckgezogen und nimmt mit der Traglast eine stabile Position ein. Eine weitere Alternative zum Spreizenstapler sind Schubgabelstapler, die jedoch nur noch selten eingesetzt werden. Der Gabeltr¨ ager ist dabei gegen¨ uber dem Hubmast beweglich angeordnet und kann zur Gutaufnahme/-abgabe in eine vordere Position verfahren werden. Dadurch k¨ onnen auch doppelttief gelagerte Ladeeinheiten entnommen werden (s. Abb. 3.19). Die verschiedenen Bauformen der Radarmstapler ben¨otigen deutlich geringere Arbeitsgangbreiten als Gegengewichtstapler. Da das Ladeeinheitenhandling jedoch frontseitig erfolgt, ist die 90◦ -Drehung des Staplers zu diesem

3.2 F¨ ordersysteme

101

Abbildung 3.18. Schubmaststapler [Foto: STILL]

Zweck unumg¨ anglich. Dadurch ergibt sich zwangsl¨auﬁg eine Gassenbreite von drei Metern oder mehr. Um die erforderliche Gangbreite weiter zu reduzieren, werden verschiedene Stapler eingesetzt, die Ladeeinheiten seitlich aufnehmen k¨ onnen und dadurch die Drehung vor dem Regalfach umgehen: Hochregalstapler Diese Stapler werden auch als Seitenstapler bzw. Dreiseitenstapler bezeichnet. Am Hubger¨ ust sind seitlich ausfahrbare Teleskopgabeln oder ein drehbarer Gabeltr¨ ager angeordnet, der die Gabel beidseitig schwenken kann (Schwenkschubgabel, s. Abb. 3.20). Je nach Ausf¨ uhrung kann die Schwenkschubgabel auch im Regalgang geschwenkt werden. Hochregalstapler erm¨ oglichen die Regalbedienung bis zu einer H¨ohe von etwa zw¨ olf Metern. Die sichere Durchf¨ uhrung einer Ein-/Auslagerung von Ladeeinheiten in dieser H¨ ohe erfordert eine Reihe von Hilfsmitteln. Dazu sind die Hochregalstapler im Regalgang mechanisch oder induktiv zwangsgef¨ uhrt. Die Positionierung der Gabel vor dem Regalfach erfolgt durch automatische Fachwahlsysteme oder unterst¨ utzt durch Kamerasysteme. Kommissionierstapler Im Gegensatz zum Hochregalstapler wird beim Kommissionierstapler oder Hochhubkommissionierer die Bedienerkabine

102

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.19. Schubgabelstapler [Foto: ATLET]

mit der Gabel am Hubger¨ ust angehoben, so dass der Kommissionierer Einheiten direkt der Ladeeinheit bzw. Bereitstelleinheit entnehmen kann. Die Sammeleinheit wird durch Anfahren einzelner Lagerf¨acher nach dem Prinzip Person-zur-Ware gebildet. Einige Ausf¨ uhrungen dienen ausschließlich dem Kommissionieren von Teilmengen und sind nicht zur Ein/Auslagerung ganzer Ladeeinheiten geeignet. Sie verf¨ ugen deshalb nur u ¨ ber eine starre, nicht schwenkbar angeordnete Gabel. Daneben existieren auch Kommissionierstapler, die sowohl zur Bildung von Teilmengen als auch zur Auslagerung ganzer Ladeeinheiten geeignet sind und alle Merkmale der Hochregalstapler aufweisen. Quergabelstapler Diese Ausf¨ uhrung ist speziell zum Langgut-Handling in Kragarmregalen geeignet. Auf einem vierr¨adrigen Wagen ist ¨ahnlich dem Schubmaststapler ein quer verfahrbares Hubger¨ ust angeordnet, das Langgut quer zur Fahrtrichtung aufnehmen kann. Zum sicheren Transport k¨ onnen die aufgenommenen Einheiten auf dem Wagen abgelegt werden. Dadurch ergibt sich trotz langer F¨ orderg¨ uter ein sehr schmaler Arbeitsgang. Aufgrund des Fahrzeugaufbaus sind ferner l¨angere Transporte unproblematisch m¨ oglich. Vierwegestapler Der Aufbau entspricht grunds¨atzlich dem des Schubmaststaplers. Das Ger¨ at ist jedoch anstelle der beiden sonst starren vorderen Rollen bzw. R¨ ader mit drehbar angetriebenen Radmotoren versehen, so dass der Stapler u ugt (s. ¨ber mindestens zwei lenkbare Radeinheiten verf¨

3.2 F¨ ordersysteme

103

Abbildung 3.20. Hochregalstapler mit Schwenkschubgabel [Foto: STILL]

Abb. 3.22). Dadurch wird die beliebige Bewegung in jeglicher Richtung erm¨ oglicht, d.h. das Ger¨ at kann l¨ angs und quer verfahren und Traversierfahrten ausf¨ uhren. Die Drehung des Ger¨ates zur Gutaufnahme entf¨allt somit, da das Fahrzeug quer zur Gutaufnahme in den Arbeitsgang einfahren kann. Auswahlkriterien Die sinnvolle Auswahl eines Flurf¨orderzeuges bedarf der Einbeziehung der Gesamtaufgabenstellung, der Ber¨ ucksichtigung der Ausgestaltung des Lager- und Kommissioniersystems und der angrenzenden F¨ordertechnik. Dabei sind auch die zu erbringende Umschlag- und Transportleistung und deren prognostizierte Entwicklung zu ber¨ ucksichtigen. So ist einerseits die Systemleistung bei Unstetigf¨orderern prinzipiell durch Anpassung der F¨ ordereranzahl skalierbar, jedoch gilt diese Regel beispielsweise nicht in Schmalgangl¨ agern, bei denen ein Passieren der Fahrzeuge im Gang nicht m¨ oglich ist oder nur ein Fahrzeug pro Gang betrieben werden kann. Außerdem sind die mit wachsendem Spezialisierungsgrad der Flurf¨ orderzeuge steigenden Investitions- und Betriebskosten den realisierbaren Fl¨ acheneinsparungen gegen¨ uberzustellen.

104

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.21. Kommissionierstapler mit hebbarer Kabine [Foto: STILL]

Einheitliche und abgesicherte Aussagen zur Wirtschaftlichkeit einzelner Fahrzeuge sind angesichts der Vielschichtigkeit der Randbedingungen nicht m¨ oglich. Betrieb und Organisation Zum eﬃzienten Einsatz von Flurf¨orderzeugen m¨ ussen die anstehenden Auftr¨ age in einer Weise abgewickelt werden, dass priorisierte Auftr¨ age bevorzugt behandelt, Leerfahrten minimiert und die vorhandenen Ressourcen sinnvoll genutzt werden. Ein einzelner Mitarbeiter (Staplerfahrer) vermag bei bekanntem Auftragsstapel seine Arbeitsreihenfolge mit gutem Ergebnis eigenst¨ andig zu optimieren, sofern er u ¨ ber entsprechende Erfahrung verf¨ ugt und die vorliegenden Systemanforderungen dies zulassen. Ebenso kann ein Disponent (Leitstand-Mitarbeiter) bestimmte Optimierungsaufgaben koordinierend manuell steuern. Bei vielen Fahrzeugeinheiten und einem dynamischem Umfeld mit kurzzeitigem Auftragsvorlauf sind diese M¨ oglichkeiten nicht mehr zielf¨ uhrend. Die Optimierung des Gesamtsystems bedarf in einem solchen Fall der kontinuierlichen Erfassung des Systemzustandes mit aktuellem Auftragsstatus

3.2 F¨ ordersysteme

105

Abbildung 3.22. Vierwegestapler [Foto: STILL]

einzelner F¨ orderer und deren Zielorte. Ein ﬂexibles und dynamisches Reaktionsverhalten setzt den jederzeitigen Zugriﬀ auf einzelne Einheiten voraus. Dazu muss eine Kommunikationsm¨ oglichkeit zu den dezentral operierenden Einheiten bestehen. Zur Kommissionierung im Regal mittels Kommissionierstaplern bedarf es zudem der Wegminimierung (Tripoptimierung) zwischen einzelnen Entnahmeorten. Zur Optimierung des Gesamtsystems ist daher ein u ¨ bergeordnetes Steuerungssystem, das die Auftragsabwicklung kontrolliert, erforderlich. Arbeitsweise und Strategien solcher Transportleitsysteme wurden bereits in Abschn. 2.3.3 behandelt. Ein weiterer wichtiger Aspekt stellt die Dokumentation erfolgter Arbeitsoperationen dar. Zur Fehleranalyse ist die Rekonstruktion von Teilprozessen ein entscheidender Schritt, um bei auftretenden Problemen (z. B. falscher Artikel im Lagerfach, Minderbest¨ ande trotz Wareneing¨ange etc.) ohne arbeitsintensive Fehlersuche in kurzer Zeit Aufkl¨ arung herbeizuf¨ uhren. Zu diesem Zweck ist das innerbetriebliche Tracking und Tracing der Materialﬂussprozesse eine wesentliche Voraussetzung (vgl. Abschn. 2.3.4). Eine sinnvolle Maßnahme ist dabei das interne Handling der F¨ ordermittel als tempor¨are Lagerpl¨atze. Dadurch ist auch in Transport beﬁndliches Material jederzeit pr¨azise u ufbar, was insbesondere bei zeitkritischen Versorgungsprozessen von ¨berpr¨ Bedeutung ist.

106

3. Grundlagen der Lager- und F¨ ordertechnik

Fahrerlose Transportsysteme Die Automatisierung von Flurf¨orderzeugen ist aufgrund der vielen Freiheitsgrade dieser F¨ordermittel eine komplizierte Aufgabe. Daher umfasst ein solches automatisiertes System neben dem mit der entsprechenden Steuerungstechnik ausgestatteten Fahrzeug auch die dazugeh¨ orige station¨ are Leittechnik mit der Fahrzeug- bzw. Systemf¨ uhrung und die Kommunikations- und Sicherheitseinrichtungen. Die Zielsetzung dabei ist der automatische Transport mittels Flurf¨ orderzeugen ohne direktes menschliches Einwirken. Trotz des hohen technischen Aufwandes werden Fahrerlose Transportsysteme (FTS) aus einer Reihe von Gr¨ unden eingesetzt: • Transporte in Risikobereichen und Erh¨ ohung der Arbeitssicherheit, • Erf¨ ullung hoher f¨ ordertechnischer Anforderungen hinsichtlich Pr¨azision, Wiederholgenauigkeit oder zwingender Einhaltung von Bewegungsgangfolgen, z. B. beim Transport großvolumiger G¨ uter in beengten Verh¨altnissen, • Personalkostenreduzierung, insbesondere im Mehrschichtbetrieb, • Transparenz der Abl¨ aufe, • Vermeidung von Transportsch¨ aden, • Umgehung erforderlicher Bodeninstallationen gegen¨ uber schienengef¨ uhrten Systemen. Alle g¨ angigen Flurf¨ orderzeuge wurden mittlerweile auch als Fahrerlose Transportfahrzeuge (FTF) realisiert. F¨ ur die speziellen Aspekte der Fahrzeugsteuerung sei auf [23, 24] verwiesen. F¨ ur die Ablaufoptimierung gelten grunds¨ atzlich die gleichen Grunds¨ atze wie f¨ ur manuelle Systeme. Verschiebewagen Verschiebewagen, auch als Verteilwagen oder Quertransportwagen (QTW) bezeichnet, sind bodengebundene, schienengef¨ uhrte Transportwagen, die u ¨ ber ein Lastaufnahmemittel (Rollen- oder Kettenf¨orderer) zur selbstst¨andigen Aufnahme und Abgabe von Ladeeinheiten dienen. Sie verfahren zwischen fest ¨ deﬁnierten Ubergabepunkten, verbinden so verschiedene Zu- und Abl¨aufe und erm¨ oglichen dar¨ uber hinaus eine Sortier- und Verteilfunktion. Der h¨auﬁgste Einsatz ist die Verteilung innerhalb einer Regalvorzone, wo Verschiebewagen eine kosteng¨ unstige Alternative zu Stetigf¨ orderkreisl¨aufen bilden. Da ein einzelner Verschiebewagen typischerweise mehrere Gewerke f¨ordertechnisch verbindet, ist seine Leistung besonders kritisch zu pr¨ ufen. Zur Erzielung einer ausreichenden Systemleistung sind die Fahrzeuge maschinenseitig hinsichtlich der Beschleunigungs- und Geschwindigkeitswerte optimiert. Eine auf den speziellen Einsatzfall abgestimmte Fahrstrategie ist ebenfalls von großer Bedeutung f¨ ur die Systemleistung. Hier sind zumeist applikationsspeziﬁsche Strategien zu entwickeln, welche die Wahl der k¨ urzesten Anschlusswege und das Auftragsalter gleichermaßen ber¨ ucksichtigen. Gegebenenfalls ist auch die Wahl einer geeigneten Leerlaufposition einzuplanen.

3.2 F¨ ordersysteme

107

¨ Abbildung 3.23. Regalbedienger¨ at zum Palettenhandling [Foto: STOCKLIN SIEMAG]

Regalbedienger¨ ate Regalbedienger¨ ate (RBG) sind schienengef¨ uhrte F¨ordermittel zur Bedienung von Zeilenregalen (s. Abb. 3.23). Durch den Einsatz von Regalbedienger¨ aten konnte die Bauh¨ ohe von Palettenregalen gesteigert und damit die Fl¨ achennutzung wesentlich verbessert werden. Typische Systeme erreichen bis zu 50 m H¨ ohe bei bis zu 150 m Gassenl¨ ange. Aufbau Das RBG besteht aus ein bis zwei Masten, einem daran vertikal verfahrbaren Hubwagen, der ein oder mehrere Lastaufnahmemittel (LAM) tr¨ agt, und dem Fahrwerk. Das RBG ist boden- und deckenseitig gef¨ uhrt. Der Fahrantrieb erfolgt u ¨ ber Reibrad- oder Zahnriemenantrieb, in Einzelf¨allen mit Seilen, im Fahrwerk u ¨ ber die Bodenschiene. Bei Zugmittelantrieben kommen sowohl station¨ are Riemen und mitbewegte, auf dem Fahrwerk montierte Antriebe als auch station¨ are, extern angeordnete Antriebe und bewegte, am RBG angeschlagene Riemen zum Einsatz. Die L¨ange der Zugmittelantriebe

108

3. Grundlagen der Lager- und F¨ ordertechnik

ist jedoch aus Schwingungsgr¨ unden auf mittlere Gassenl¨angen begrenzt. Bei hochdynamischen Ger¨ aten wird ggf. ein zus¨ atzlicher Antrieb an der oberen F¨ uhrungsschiene vorgesehen. Regalbedienger¨ ate eignen sich zur Bedienung aller Regaltypen mit Operation in der Regalfront (Paletten und Beh¨alterregale sowie Durchlauf- / Einschubregale). Bei Kanall¨ agern k¨ onnen sie wiederum mittelbar eingesetzt werden, beispielsweise als Umsetzer von Kanalfahrzeugen oder Satelliten zwischen einzelnen Lagerkan¨ alen. Lastaufnahme Die Art und Anzahl der auf dem Hubwagen beﬁndlichen Lastaufnahmemittel beeinﬂussen in großem Maße Leistung und Arbeitsweise des Systems sowie die erforderliche Gestaltung der Systemschnittstellen. Das grundlegende Prinzip der Last¨ ubergabe wird durch Form und Gewicht der Ladeeinheit bestimmt. Im Bereich des Palettenhandling (Lasten >300 kg) wird die Last u ¨ blicherweise mittels Teleskopgabel in das Lagerfach gesetzt. Dadurch tritt keine Relativbewegung zwischen Fach und Ladeeinheit auf. Dieser Prozess erfordert allerdings durch sequenzielle Bewegungsabl¨ aufe (Positionierung vor Lagerfach – Gabel ausfahren – Kurzhub des Hubwagens – Gabel einfahren) und damit verbundene Positionierzeiten relativ lange Last¨ ubergabezeiten. Bei speziellen Ladeeinheiten im Schwerlastbereich, die einer kontinuierlichen und großﬂ¨ achigen Unterst¨ utzung bed¨ urfen (insb. Luftfrachtpaletten (Unit Load Devices ULD)), ist das Prinzip der Teleskopgabel aufgrund der linienf¨ ormigen Lastunterst¨ utzung nicht einsetzbar. Dazu werden Rollenf¨ orderer sowohl auf dem Lastaufnahmemittel als auch im Lagerfach eingesetzt, was unter anderem k¨ urzere Last¨ ubergabezeiten erm¨oglicht, aus Kostengr¨ unden jedoch nur bei den genannten Ladeeinheiten ohne ausreichend steifes Ladehilfsmittel zum Einsatz gelangt. Im Bereich der leichten St¨ uckg¨ uter (Tablare, Beh¨alter; vgl. Abschn. 3.1.2) ergeben sich dagegen vielf¨ altige Gestaltungsformen der Last¨ ubergabe, da u. a. ein Ziehen der Einheiten unproblematisch m¨ oglich ist (entsprechend glatte und ebene B¨ oden der Ladeeinheit und reibarme Regalaufnahmen vorausgesetzt). Verschiedene Formen der Lastaufnahmemittel sind in Abb. 3.24 dargestellt. Steuerung und Betrieb Der leistungsorientierte Betrieb von Regalbedienaten setzt eine zeitnahe Ansteuerung der RBG-Funktionen voraus. Aus ger¨ diesem Grund werden zur Steuerung eigene Systemsteuerungen in Form autarker Materialﬂussrechner (MFR) und unterlagerter Ger¨atesteuerungen zur Ausf¨ uhrung und Optimierung der Bewegungsabl¨aufe auf der Feldebene eingesetzt. Auf dem Materialﬂussrechner sind die Strategien zur Lagerplatzvergabe (vgl. Tabelle 2.2) und zur Auslagerung (vgl. Tabelle 2.4) abgebildet. Zur Umsetzung ist außerdem die bereichsbezogene Platzverwaltung auf dem MFR installiert.

3.2 F¨ ordersysteme

a)

b)

c)

d)

109

Abbildung 3.24. Lastaufnahmemittel von RBG: a Ziehvorrichtung b UnterfahrTeleskop c Greifer d Reibriemen [Fotos: TGW]

Sonderbauformen Eng verwandt mit RBG sind die Stapelkrane, die eine Verbindung von RBG und Br¨ uckenkran darstellen. Am Katzfahrwerk des Kranes ist ein vertikaler Mast mit der Funktionalit¨at eines RBG-Mastes (Lastf¨ uhrung, Hubwagen und Lastaufnahmemittel) angebracht. Der wesentliche Unterschied besteht in der h¨ angenden Ausf¨ uhrung des Systems ohne den Bedarf von Bodeninstallationen, wodurch sich das System u. a. f¨ ur den Betrieb in Verschieberegalanlagen (s. Abschn. 3.1.3) eignet. Ein ¨ahnliches Prinzip verfolgt der so genannte TransFaster, bei dem das Lastaufnahmemittel h¨angend an einem Katzfahrwerk angebracht ist. Das Katzfahrwerk verf¨ahrt wie ein Kanalfahrzeug auf seitlichen Schienen innerhalb einer Gasse. Dadurch k¨ onnen auch mehrere Fahrwerke auf verschiedenen H¨ohenniveaus in einem Regalgang verfahren. ¨ Ahnlich dem RBG ist auch das Hubbalkensystem“, das im Prinzip ein ” um 90◦ gedrehtes RBG darstellt. Der Mast in Form eines horizontalen Hubbalkens ist seitlich an vertikalen Schienen gef¨ uhrt, auf dem Balken verf¨ahrt der Hubwagen analog zur Krankatze das Lastaufnahmemittel. Durch diese Bauform k¨ onnen die mitbewegten Antriebe reduziert und die Dynamik des Systems erh¨ oht werden. Diese Vorteile kommen jedoch nur bei kleineren Lagersystemen zum Tragen.

110

3. Grundlagen der Lager- und F¨ ordertechnik

Elektroh¨ angebahn Elektroh¨ angebahnen (EHB) sind ﬂurfreie, automatische Unstetigf¨orderer. An einer an der Decke oder an St¨ utzen abgeh¨ angten Schiene verfahren elektrisch betriebene Einzelfahrzeuge, die im Allgemeinen u ¨ ber an der Schiene montierte Schleiﬂeitungen mit Energie versorgt werden. Das F¨ordergut wird u ¨ ber Lastgeh¨ ange, Greiftraversen oder verschiedene Formen von Haken und Hebezeugen unterhalb des Fahrzeuges transportiert. Die vielfach eingesetzten Lastgeh¨ ange k¨ onnen auch mit aktiven Lastaufnahmemitteln (Rollenbahnen, Tragkettenf¨ orderern) ausger¨ ustet werden und dadurch die Last¨ ubergabe optimieren und dar¨ uber hinaus zur St¨ uckgutverteilung eingesetzt werden. Im Lagerbereich werden EHB h¨ auﬁg zur Verbindung verschiedener funktionaler Bereiche (z. B. Wareneingang und Hochregal) eingesetzt. Ein EHB-System ist ein universell einsetzbares F¨ordersystem. Die Beladung erfolgt im Stillstand, so dass auch große und schwere Lasten sicher u onnen. Fahrgeschwindigkeiten bis zu 2 m/s erm¨oglichen ¨bergeben werden k¨ ¨ gleichzeitig die eﬃziente Uberbr¨ uckung großer Distanzen und hohe Durchs¨atze. Durch zahlreiche Verzweigungs- und Zusammenf¨ uhrungselemente (Drehkreuze, Zwei-/Dreiwegeweichen, Parallelweichen) sowie Steig-/Gef¨allestrecken und Heber k¨ onnen umfangreiche Transportnetze realisiert werden. Bei großen Nutzlasten und hohen Durchs¨ atzen bieten sich an Steigstrecken ggf. Steighilfen an, um den technischen Aufwand an den Einzelfahrwerken, die in Spezialausf¨ uhrung und bei leichten Lasten auch eigenst¨andig 90◦ -Passagen u onnen, zu begrenzen. Durch angepasste Fahrzeuganzahl oder ¨berwinden k¨ parallele Puﬀerstrecken k¨ onnen auch verschiedene Puﬀeraufgaben erf¨ ullt werden. Typische Standardlasten pro Fahrzeug betragen ca. 300–1000 kg, daneben werden auch Systeme f¨ ur geringere und deutliche h¨ohere Lasten errichtet. Zur Erh¨ ohung der m¨ oglichen Traglast werden Einzelfahrwerke gekoppelt, wobei zumeist ein getriebenes Zugfahrzeug und ein oder mehrere nicht angetriebene Fahrwerke zusammengeschlossen werden. Die zur Ansteuerung der Einzelfahrzeuge erforderlichen Steuerungsbefehle werden entweder u ¨ ber die Schleiﬂeitungen oder kontaktlos u ¨ ber Funk oder Infrarot u uhrungslose ¨ bertragen. Zur Verschleißminimierung werden auch ber¨ Formen der Energie¨ ubertragung (induktive Kopplung) eingesetzt. Neben der fahrzeugbezogenen Steuerung (z. B. Last¨ ubergabe, Abstands¨ uberwachung zu vorausfahrenden Fahrzeugen) u ¨ bernimmt ein Systemrechner die Vorfahrtregelung an komplexen Streckenabschnitten (Kreuzungen, Einm¨ undungen), steuert das Schienennetz (Weichen etc.), sorgt f¨ ur die Vermeidung von Deadlocks und optimiert die Systemleistung. Sonderbauformen Einen Sonderfall der EHB stellen die Elektrotragbahn (ETB) und die Elektropalettenbahn (EPB) (vgl. [75]) dar. In beiden F¨allen wird ein EHB-vergleichbares Schienensystem auf dem Boden montiert, im Fall der EPB zwei parallele Schienen. Das F¨ ordergut wird oberhalb des Fahr-

3.2 F¨ ordersysteme

111

werks transportiert, wodurch sich dieses System in speziellen Anwendungen besser integrieren l¨ asst. Bez¨ uglich Ansteuerung und Organisation verhalten sich beide Systeme analog zur EHB. Krane Krane z¨ ahlen zu den klassischen Umschlagmitteln im Materialﬂuss. Sie werden vorzugsweise zum F¨ ordergutwechsel zwischen unterschiedlichen Transportmitteln und zur Manipulation schwerer Lasten eingesetzt. Ein wesentliches Merkmal aller Kranbauformen ist der ﬂurfreie Transport in nahezu beliebiger Richtung ohne Inanspruchnahme von Verkehrswegen. Hinsichtlich ihrer Bauform lassen sich linear verfahrbare Krane mit quaderf¨ ormigem Arbeitsraum und Drehkrane mit zylindrischem Arbeitsraum unterscheiden. Im außerbetrieblichen Einsatz beﬁnden sich daneben verschiedene Formen von Fahrzeugkranen, die hier nicht weiter vertieft werden sollen (vgl. dazu [65]). Zu den Kranen mit quaderf¨ ormigem Arbeitsraum z¨ahlen die Folgenden: ¨ Br¨ uckenkrane Uber dem Arbeitsbereich sind seitlich Laufschienen (Kranbahnen) montiert, die sich direkt in das Geb¨aude abst¨ utzen. Die Kranbr¨ ucke u ¨ berspannt den Arbeitsbereich und verf¨ahrt u ¨ ber seitlich angeordnete Kopftr¨ ager. Oberhalb, seitlich oder unterhalb der Kranbr¨ ucke verf¨ ahrt das Katzfahrwerk, an dem das eigentliche Hebezeug (Seil- oder Kettenzug) befestigt ist. Seitlich angeordnete Katzen oder Winkellaufkatzen leiten ein Torsionsmoment in die ansonsten nur auf Biegung beanspruchte Kranbr¨ ucke ein, erm¨ oglichen jedoch eine Minimierung der Kranbauh¨ ohe und dadurch eine Vergr¨ oßerung des Arbeitsbereiches. Die Verfahrbewegung und Ableitung der Kr¨ afte in die Kranbahn erfolgt i. Allg. u ader. ¨ ber Stahllaufr¨ H¨ angekrane Die Laufschienen sind im Gegensatz zum Br¨ uckenkran unterhalb der Hallendecke montiert, so dass der Kran vollst¨andig unterhalb der Schiene h¨ angt. Dadurch wird der Arbeitsbereich vergr¨oßert, da die Laufkatze auch unterhalb der Schiene operieren kann. Ebenso ist ein ¨ Uberwechseln der Laufkatze in andere Hallenbereiche m¨oglich. Stapelkrane Basierend auf einem Br¨ ucken- oder H¨angekran besitzt der Stapelkran anstelle des Seil- oder Kettenhubwerks einen festen, ggf. teleskopierbaren Mast. Dadurch wird die bei Kranen sonst u ¨bliche Pendelneigung des Lastaufnahmemittels mechanisch umgangen, so dass sich der Stapelkran insbesondere zur Regalbedienung und zur dynamischen Diagonalfahrt eignet. Portalkrane Falls eine Abst¨ utzung der Kranbr¨ ucke u ¨ ber das Geb¨aude nicht m¨ oglich ist, kann die Kranbr¨ ucke u utzen auf dem Boden ver¨ ber eigene St¨ fahren. Je nach Baugr¨ oße wird dabei eine St¨ utze als Pendelst¨ utze ausgef¨ uhrt, um Spannungen in den Rahmenecken durch W¨armeeinwirkungen oder Toleranzen in der Kranbahn zu umgehen. Die gr¨oßere Masse und

112

3. Grundlagen der Lager- und F¨ ordertechnik

Form der Abst¨ utzung l¨ asst gegen¨ uber den Br¨ uckenkranen nur geringere dynamische Bewegungen zu. Konsolkrane Der Konsolkran wird l¨ angs einer senkrechten Wand verfahren und kragt in den Arbeitsbereich hinein. Die Laufschienen sind u ur geringere Lasten und klei¨ bereinander angeordnet. Sie werden nur f¨ ne Kragweiten ausgelegt und ggf. unterhalb eines weiteren Br¨ uckenkrans betrieben. Krane mit zylinderf¨ ormigem Arbeitsbereich basieren auf einem drehbar gelagerten Ausleger. Der Ausleger kann sowohl schwenkbar gelagert sein als auch u ugen, um verschiedene Radien des Arbeitsrau¨ ber eine Laufkatze verf¨ mes zu bedienen. Im innerbetrieblichen Einsatz kommen Drehkrane nur als S¨ aulendrehkrane an Industriearbeitspl¨ atzen zum Einsatz und besitzen f¨ ur den Materialﬂuss in Lager- und Distributionssystemen eine untergeordnete Rolle. Im außerbetrieblichen Einsatz werden dagegen verschiedenste Formen von Drehkranen an Kaianlagen und im Baugewerbe eingesetzt. Kraneinsatz in Lagersystemen Krane werden vorzugsweise zur Lagerbedienung sehr schwerer St¨ uckg¨ uter wie Stahlcoils, Papierrollen, Stahltafeln oder besonderem Langgut eingesetzt. Dabei erfolgt die Lagerung oftmals in Blocklagerung und die Bedienung von oben. Zu diesem Zweck werden auch automatisierte Systeme eingesetzt, da die Bedienung und Lagerverwaltung aus den in Abschn. 3.1.1 (vgl. S. 75) geschilderten Gr¨ unden problematisch ist. Die Einsatzm¨ oglichkeit bedarf dabei zwangsl¨auﬁg eines selbstwirkenden Lastaufnahmemittels (Magnet- oder Sauggreifer oder Zangen) sowie einer geeigneten Steuerung zur Pendelkompensation. Der automatische Kranbetrieb darf nur in abgesperrten Bereichen ohne Personenverkehr erfolgen. Die Lagerortverwaltung setzt in diesem Fall eine exakte Erfassung des Lagerplatzes voraus, da die Lagerg¨ uter typischerweise unterschiedliche Abmessungen aufweisen und die Lagerpl¨ atze je nach Stapelbildung variieren. Gleichzeitig ist die Ber¨ ucksichtigung der Stapelreihenfolge erforderlich. Die Durchsatzleistung ist konsequenterweise von den Lagerstrategien und erforderlichen Umlagerungen abh¨ angig. Ebenso werden Krane zur Regalbedienung eingesetzt (sowohl automatisch als auch manuell), wobei die gleichen Anforderungen an das Steuerungssystem gelten wie bei Regalbedienger¨aten. Daneben ﬁnden Krane Einsatz als Umschlagger¨ate im Wareneingang und -ausgang. Dabei werden sowohl einzelne G¨ uter als auch Ladeeinheiten wie Container umgeschlagen.

3.3 Sortier- und Verteilsysteme

113

3.3 Sortier- und Verteilsysteme Sortier- und Verteilsysteme, h¨ auﬁg nur kurz Sorter genannt, sind automatische Anlagen, die eine große Menge an G¨ utern in kurzer Zeit sicher nach speziellen Kriterien verteilen sollen. Einzelne Prozesse k¨onnen innerhalb des Verteilprozesses auch manuell ausgef¨ uhrt werden. Durch steigende Anforderungen hinsichtlich der Durchlaufzeit und der Betriebskosten, aber auch durch ver¨ anderte Versandstrukturen mit einem Wandel zur hochfrequenten und bedarfszeitpunktgerechten Belieferung kleiner Mengen spielen diese Systeme eine immer wichtigere Rolle. Im Folgenden sollen die elementaren Systemstrukturen und Verteilprinzipien dargestellt werden. 3.3.1 Einsatzfelder Die Anforderungen an den Verteilprozess variieren in einzelnen Einsatzbereichen erheblich. Im Bereich der Lager- und Distributionssysteme lassen sich folgende Einsatzbereiche unterscheiden: Umschlagsysteme der Post und Paketdienstleister In diesem Anwendungsfall sind eingehende Sendungen in m¨oglichst kurzer Zeit auf abgehende Touren zu verteilen. Im regionalen Umfeld gesammelte Sendungen werden in Kleintransportern an einem so genannten Hub angeliefert und je nach Zielort sowohl auf abgehende Transporte zu anderen Hubs als auch auf regionale Lieferungen, die vom selben Hub bedient werden, verteilt. Die zur Verf¨ ugung stehende Zeit innerhalb des Hubs ist aufgrund der kurzen Lieferzeiten auf wenige Stunden begrenzt. Die Distanz zum Zielort bestimmt dabei die Priorit¨ at des Sortierauftrags. Die eingehenden und abgehenden Str¨ ome bzw. Zuordnungen liegen weitgehend fest. Das einzelne Sendungsst¨ uck besitzt immer einen eindeutigen Zielort. Die Umschlagsysteme sind durch ausgepr¨agte Lastspitzen mit pulsierenden Anliefermengen gepr¨ agt. Das Sortiergutspektrum ist sehr groß und uneinheitlich, da die Sortierg¨ uter beim versendenden Kunden, also außerhalb des Systems, erzeugt werden. Vorgaben bestehen hinsichtlich des Gutgewichtes und der Abmessungen (zul¨assiges Gurtmaß h¨auﬁg = L¨ ange + 2×Breite + 2×H¨ ohe = 3000 mm). Kommissioniersysteme Insbesondere in zweistuﬁgen Kommissioniersystemen ist die automatische Verteilung praktisch ein elementarer Bestandteil des Kommissioniersystems (s. Abschn. 2.2.5). Die in der ersten Stufe zu Kommissionierbatches zusammengefassten Kundenauftr¨age werden f¨ ur den Versand separiert. Da die Menge der t¨aglich abzuarbeitenden Kundenauftr¨ age die m¨ ogliche Endstellenanzahl oftmals deutlich u ¨ berschreitet, werden die Kundenauftr¨age zu Stapeln zusammengefasst, die nacheinander abgewickelt werden. Somit werden die Artikel bei jedem Lauf neu zugewiesen. Ebenfalls ist die Zuordnung einer einzelnen

114

3. Grundlagen der Lager- und F¨ ordertechnik

Einheit nicht eindeutig, da derselbe Artikel in verschiedenen Kundenauftr¨ agen gefordert sein kann3 und sich somit zur Zuweisung auf mehrere Ziele qualiﬁziert. Daher h¨ angt die Sortierleistung in diesem Anwendungsfall unter anderem auch von der Anwendung geeigneter Zuweisungsregeln ab. Aber auch in einstuﬁgen, auftragsparallel arbeitenden Kommissioniersystemen k¨ onnen durch Sortereinsatz Rationalisierungspotenziale erschlossen werden. Die Zusammenf¨ uhrung von Teilauftr¨agen zu Versandauftr¨ agen (Beh¨ altersortierung) stellt dabei andere Anforderungen an das Verteilsystem: die Sortierg¨ uter sind zusammengefasste Mengen (Beh¨alter, Kartonagen), der Durchsatz ist relativ gering und die in der Endstelle zu puﬀernde Menge (oftmals Versandtour) relativ groß. Retourensortierung Retouren stellen besondere Anforderungen an den Wareneingang und die Behandlung im System (s. Abschn. 2.2.1). Bei R¨ uckeinlagerung der retournierten Waren erfolgt eine Verteilung auf einzelne Lagerbereiche. Ebenso ist eine direkte Einbeziehung der Artikel in den laufenden Kommissionierprozess m¨ oglich, um Lagerprozesse zu umgehen. Gep¨ ackabfertigung Kritische Kennzahl aller Flugh¨afen ist die k¨ urzeste Anschlusszeit (Minimum Connecting Time, MCT), um den sicheren Gep¨ acktransfer bei Anschlussﬂ¨ ugen sicherzustellen. Auf großen Flugh¨afen ist eine kurze Prozesszeit nur durch umfangreiche f¨ordertechnische Anlagen mit Sortier- und Verteilfunktionalit¨at m¨oglich. Besondere Anforderungen stellt dabei das Sortiergut (Fluggep¨ack), dessen Gutform und -eigenschaften nicht pr¨ azise deﬁnierbar sind. Neben nahezu beliebigen Formen und Steiﬁgkeiten sind an den G¨ utern Schlaufen, lose Riemen usw. vorhanden. 3.3.2 Grunds¨ atzlicher Aufbau von Sortiersystemen Augenf¨ alliges Merkmal eines Sortiersystems ist der Verteilstrang mit der jeweiligen Verteiltechnik. Die sichere Systemfunktionalit¨at erfordert auch vorund nachgeschaltete Systemelemente. Es lassen sich f¨ unf funktionelle Bestandteile unterscheiden [72]: • • • • •

3

Systemeingabe Vorbereiten Identiﬁzieren Verteilen Systemausgabe

Dieser Zustand ist das eigentliche Ziel des Kommissionierprinzips, um Kommissionierwege in der ersten Stufe (artikelweise Kommissionierung) zu reduzieren.

3.3 Sortier- und Verteilsysteme

115

Systemeingabe Aufgabe der Systemeingabe ist die Angleichung der Arbeitscharakteristik des Sorters an das vorgeschaltete System. Pulsierende Eingangsstr¨ome m¨ ussen beispielsweise mit der konstanten Arbeitsweise des Verteilsystems mit einer festen Verteilleistung in Einklang gebracht werden. Dazu sind beispielsweise Entladebahnen zur Entleerung eingehender Transporter mit entsprechenden Puﬀerkapazit¨ aten vorzusehen. Auch in gr¨ oßeren Kommissioniersystemen ist die zeitgerechte Abarbeitung und Bereitstellung eines Kommissionierbatches systemtechnisch nicht ohne weiteres m¨ oglich. Zur Entkopplung der ersten von der zweiten Stufe kann daher die Puﬀerung mehrerer Batches vor dem Sorter erforderlich sein. Vorbereiten Die eﬃziente Arbeitsweise eines automatischen Systems kann im Allgemeinen dadurch unterst¨ utzt werden, dass die Freiheitsgrade der zu bearbeitenden Objekte begrenzt werden, was auch auf Verteiltechniken zutriﬀt. Je nach Ausf¨ uhrung des Systems geh¨ oren zu dieser Funktionsgruppe von Sortier- und Verteilsystemen daher folgende T¨ atigkeiten: Vereinzeln Die Erfassung und Zuteilung einer Sequenz von G¨ utern bedarf deﬁnierter Zwischenabst¨ ande zur unbeeintr¨achtigten Verarbeitung. Das l¨ asst sich beispielsweise durch zwei hintereinander geschaltete Stetigf¨orderer mit F¨ ordergeschwindigkeiten v1 < v2 erzielen. Ausrichten F¨ ur eine pr¨ azise Durchf¨ uhrung des Ausschleusvorgangs auf dem Verteilf¨ orderer werden die Sortierg¨ uter in unterschiedlicher Art zum Verteilkreislauf ausgerichtet. Verteilsysteme wie Abweiser oder Schwenkrollensorter ben¨ otigen zur sicheren Gutabgabe die Vorpositionierung auf den Rand des F¨ orderers, wozu beispielsweise Rollenf¨ordererabschnitte mit schr¨ aggestellten oder konischen Rollen vor der Gutaufgabe eingesetzt werden. Bei F¨ orderern mit Einzelplatzbelegung verbessert die Orientierung des Sortiergutes mit der L¨ angsrichtung parallel zum Verteilkreislauf die m¨ ogliche Fl¨ achennutzung des Schalensegmentes und ggf. den Platzbedarf in der Endstelle. Zu diesem Zweck werden Zuf¨orderer und Aufgabef¨ orderer in einem entsprechenden Winkel zueinander justiert, oder es wird eine manuelle Aufgabe eingesetzt. Die sichere Identiﬁzierung des F¨ ordergutes ist ebenfalls elementare Voraussetzung f¨ ur einen st¨ orungsarmen Sorterbetrieb. In verschiedenen Abl¨ aufen kann die Position des Identiﬁzierungsmerkmals jedoch beliebig sein. Um den Einsatz kostenintensiver Allseiten-Erfassungsger¨ate (Scannerbr¨ ucken) zu umgehen, ist die Ausrichtung des Identiﬁzierungsmerkmals zum Leseger¨ at vorteilhaft. Dieser Vorgang wird u ¨ berwiegend manuell, z. T. aber auch durch automatisches Kippen in die korrekte Position bewerkstelligt.

116

3. Grundlagen der Lager- und F¨ ordertechnik

Aufbringen von Zusatzinformationen Wenn St¨ uckg¨ uter sich nicht durch Abmessungen, Gewicht, Erscheinungsbild oder vorhandenen Barcode unterscheiden lassen, ist eine zus¨ atzliche physische oder logische Verkn¨ upfung des Sortierkriteriums mit dem Sortiergut erforderlich. ¨ Gewichtserfassung Die Gewichtserfassung wird zur Vermeidung von Uberlastungen des Sortiersystems infolge von Gewichts¨ uberschreitungen oder zur Kontrolle auf Pickfehler eingesetzt. Identiﬁzieren Die Identiﬁzierung des Sortiergutes erfolgt u ¨ blicherweise via Barcode, in wenigen F¨ allen par Klarschrifterkennung. Die Scannung des Barcodes kann an unterschiedlichen Positionen erfolgen, auf der Zuf¨ uhrung oder nach Gutaufgabe auf dem Sortierkreislauf. Je fr¨ uher die Scannung erfolgt, umso eher besteht die M¨ oglichkeit, bei Fehllesungen zu reagieren. Außerdem ist zur Gutaufgabe die F¨ ordergeschwindigkeit h¨ auﬁg niedriger, was die Lesesicherheit erh¨oht bzw. den Einsatz einfacherer Scanner erm¨ oglicht. Besitzt das Sortiergut keinen maschinenlesbaren Code, werden verschiedene Formen einer manuellen Identiﬁzierung eingesetzt. Aus dem Postbereich ist beispielsweise das manuelle Eintippen des Zielcodes und Auﬂegen auf den Zuf¨ orderer bekannt. Liegt gemischtes Sortiergut (mit und ohne Zieldaten auf dem Label) vor, wird in großen Systemen zunehmend auch Telecoding eingesetzt. Dabei wird an der Identiﬁkationsstelle eine Kamera installiert, welche die Bildinformationen an einen externen Bildschirmarbeitsplatz u agt. Daraus resultieren nicht nur weniger Fehler wegen besserer Ergo¨bertr¨ nomie, sondern auch Vorteile hinsichtlich der Personalauslastung. Zwischen Lese- und Entscheidungsstelle muss dabei ein ausreichender Abstand vorhanden sein (Verarbeitungszeit ca. 20 s). Eine wachsende Bedeutung erf¨ahrt die Spracheingabe (Voice-Coding), die es dem Kommissionierer erm¨oglicht, mit beiden H¨ anden zuzugreifen. Spracheingabesysteme werden sowohl in Paketverteilzentren zur Eingabe von Postleitzahlen oder Routingcodes als auch bei der Kommissionierung von Artikeln eingesetzt (s. Abschn. 2.2.5). Insbesondere im Postbereich gelangt die Klarschrifterkennung zum Einsatz, die bei Leseproblemen wiederum andere Verfahren (Telecoding) integriert. Verteilen Der Aufbau eines Verteilsystems l¨ asst sich anhand verschiedener Kriterien klassiﬁzieren: • Anordnung in Linien- oder Ringstruktur, • Anzahl und Anordnung der Aufgabestellen und • Verteil- oder Ausschleusprinzip. Bei der Anordnung in Linienstruktur erfolgt die Gutzuf¨ uhrung und -verteilung auf einer geraden Strecke (s. Abb. 3.25, a+b). Je nach Verteilprinzip

3.3 Sortier- und Verteilsysteme

117

Abbildung 3.25. Anordnung in Linien- und Ringstruktur

wird der F¨ orderer ggf. am Ende der Strecke vertikal umgelenkt. Die technisch aufw¨ andige Verteilstrecke kann dadurch kurz ausgef¨ uhrt werden. Nicht ausgeschleuste G¨ uter (z. B. aufgrund u ullter Endstellen) m¨ ussen u ¨ berf¨ ¨ ber zus¨ atzliche Standardf¨ ordertechnik zur Aufgabestelle am Anfang der Verteilstrecke zur¨ uckgef¨ ordert und erneut aufgegeben werden. Bei der Anordnung in Ringstruktur wird der Verteilparcours zu einem endlosen, horizontal umlaufenden Kreislauf zusammengeschlossen (s. Abb. 3.25, c+d). Die Endstellen und insbesondere die Aufgabestellen k¨onnen an beliebiger Stelle entlang des Kreislaufs angeordnet werden (von sonstigen Restriktionen abgesehen). K¨ onnen Sortierg¨ uter an der vorgesehenen Endstelle nicht ausgeschleust werden, so k¨ onnen sie ohne erneute Identiﬁkation und Zuf¨ uhrung auf dem Verteilkreislauf verbleiben und bei der n¨achsten Passage in die Endstelle abgegeben werden. Gegen¨ uber der Linienstruktur ist bei dieser Anordnung eine lange und kostenintensive Verteilstrecke erforderlich. Die Gutaufgabe l¨ asst sich aus drei Richtungen vornehmen: 1. vertikal von oben, 2. horizontal in F¨ orderrichtung, am Beginn der F¨orderstrecke, 3. horizontal, seitlich der F¨ orderstrecke. Die Form der Gutaufgabe ist nicht frei w¨ ahlbar, sondern wird u ¨ berwiegend durch das gew¨ ahlte Verteilprinzip bestimmt. Einige Verteiltechniken k¨onnen systembedingt nur von oben, nur von vorne oder nur seitlich bef¨ ullt werden (s. Abschn. 3.3.3). Seitliche und vertikale Zuf¨ uhrung erm¨oglicht eine Erh¨ohung der Systemleistung durch mehrfache und parallel angeordnete Zuf¨ uhrstellen. Außerdem k¨ onnen aus verschiedenen Bereichen kommende F¨orderstrecken unmittelbar an den Verteilkreislauf angeschlossen werden. Demgegen¨ uber muss bei der Horizontalaufgabe in F¨ orderrichtung der gesamte F¨orderstrom vorab auf eine F¨ orderstrecke verdichtet werden. Die m¨ ogliche Leistungssteigerung bei der Nutzung diagonal angeordneter Zuf¨ uhrstellen (s. Abb. 3.25, d) h¨ angt von der Vorbereitung des Gutstromes, dem Ansprechverhalten einzelner Endstellen und dem Rezirkulationsverh¨ altnis (durchschnittlicher Anteil an Kreisl¨aufern) ab. Im Idealfall wird der Gutstrom derart vorsortiert, dass die in einem Bereich zugef¨ uhrten

118

3. Grundlagen der Lager- und F¨ ordertechnik

Systeme mit Einzelplatzbelegung

Systeme mit freier Belegung

zu- und abfördernde Systeme

abweisende Systeme

Kraftfeld

zu- und abfördernde Systeme

abweisende Systeme

Kraftfeld

Quergurtsorter

Kammsorter

Kippschalensorter

Schwenkrollensorter

Schiebeschuhsorter

Kippgliederband

Tragschuhsorter

Brushsorter

Fallklappensorter

Kanalsorter

Dreharmsorter

Drehsorter

Transfere

Pusher

Ringsorter

Abweiser

Abstreifer

Abbildung 3.26. Systematik der Verteiltechniken

Sortierg¨ uter auf die unmittelbar folgenden Endstellen ohne Passieren des n¨achsten Zuf¨ uhrbereiches verteilt werden. Dadurch l¨asst sich nahezu eine n-fache Belegung der Verteilstrecke erreichen. Begrenzend wirkt wiederum der Anteil an Kreisl¨ aufern. Werden dagegen gemischte Teilstr¨ome an verschiedenen Stellen des Kreislaufs zugef¨ uhrt, ist eine Angabe der m¨oglichen Leistungssteigerung aufgrund der zuvor genannten Einﬂussgr¨oßen nicht pauschal m¨ oglich. Das Verteilprinzip l¨ asst sich einerseits nach der Art der Belegung der Verteilstrecke beschreiben. Bei Sortern mit Einzelplatzbelegung ist der Verteilf¨ orderer in diskrete Abschnitte (Schalen) aufgeteilt, die jeweils ein einzelnes St¨ uckgut aufnehmen. Die theoretische Verteilleistung wird durch die Schalenteilung und die F¨ ordergeschwindigkeit deﬁniert. Bestimmte Anlagen lassen dar¨ uber hinaus auch die virtuelle Zusammenschaltung mehrerer Einzelsegmente zur Aufnahme u uter zu. Bei Anlagen mit frei¨ berlanger Sortierg¨ er Belegung ist der Verteilf¨ orderer beliebig belegbar und l¨asst dadurch eine Optimierung des St¨ uckgutabstandes zu, was insbesondere bei einem stark variierenden Gutspektrum vorteilhaft sein kann, sofern ein entsprechendes Steuerungssystem vorhanden ist. Andererseits beschreibt das Wirkprinzip des Ausschleusmechanismus die Arbeitsweise der Verteiltechnik. Bei heutigen Systemen werden folgende Prinzipien genutzt: zu- und abf¨ ordernde Systeme Das Sortiergut liegt auf einem F¨ordermittel auf und wird durch Verfahren des F¨ ordermittels ausgeschleust. Die Ausschleusung ohne Relativbewegung zum F¨ordermittel erm¨oglicht eine ¨ pr¨ azise und gutschonende Ubergabe.

3.3 Sortier- und Verteilsysteme

119

abweisende Systeme Das Sortiergut wird durch ein separates Element vom F¨ ordermittel abgeschoben. Der Formschluss zwischen Sortiergut und Ausschleuselement garantiert ein sicheres Auschleusen, je nach Ausf¨ uhrung kann das Sortiergut dabei erheblich beansprucht werden. kraftfeldbasierte Systeme Die Systeme nutzen zur Ausschleusung die Erdbeschleunigung, teilweise auch Zentrifugalkr¨afte, und k¨onnen dadurch die Anzahl erforderlicher Antriebe reduzieren. Der Ausschleusvorgang ist auch von den Guteigenschaften (Gewicht, Dichte, Schwerpunktlage, Gleiteigenschaften) abh¨ angig und nicht f¨ ur alle G¨ uter einsetzbar. Die Zuordnung g¨ angiger Verteiltechniken anhand dieser Klassiﬁkation ist in Abb. 3.26 dargestellt. Systemausgabe Die an die Endstellen oder Zielstellen gestellten technischen Anforderungen sind vielf¨ altig: • Die geforderte Auftragsmenge muss sicher gespeichert werden. • Die G¨ uter m¨ ussen bei jedem F¨ ullungsgrad nach einem Stillstand sicher weitergef¨ ordert werden. • Die G¨ uter m¨ ussen schnell vom Sorter abgezogen werden, um m¨oglichst viele G¨ uter unmittelbar hintereinander in dieselbe Endstelle ausschleusen zu k¨ onnen. • Die Geschwindigkeit in den Endstellen und der resultierende Staudruck d¨ urfen nicht zu groß sein. • geringer Platzbedarf • leichte Entleerung durch das Packpersonal (ergonomische Greifh¨ohe, kein Stoßen der G¨ uter) Aufgrund der zahlreichen Verwendung im System werden an Endstellen aber auch hohe Anforderungen hinsichtlich der Investitionskosten gestellt. Daher ist es wichtig, f¨ ur einen gew¨ ahlten Einsatzfall die geeignete Endstellentechnik und -dimension zu bestimmen. G¨ angige eingesetzte Techniken sind • • • • • •

Rutschen (ebene Rutschen, Stufenrutschen, Wendelrutschen), Rollenbahnen (angetrieben oder gebremst), R¨ ollchenbahnen, Gurtf¨ orderer, Beh¨ alter, Wannen, Rollbeh¨ alter sowie S¨ acke und Versandkartons.

Aus Kostengr¨ unden kommen dabei Rutschen zum Einsatz (s. Abb. 3.27). Bez¨ uglich der Systemintegration ist ferner die Anbindung an anschließende Prozesse zu beachten. Aktive Endstellen wie Rollenbahnen und Gurtf¨orderer unterst¨ utzen eine automatisierte Handhabung. Passive Endstellen (oftmals Rutschen, Beh¨ alter etc.) werden durch Mitarbeiter entleert und f¨ ur den

120

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.27. Rutschen-Endstellen [Foto: BEUMER]

n¨achsten Sortierauftrag freigegeben. Diesem Arbeitsschritt kommt eine besondere Bedeutung f¨ ur die Gesamtsystemleistung zu, da die Reihenfolge der zu bedienenden Endstellen und der Weg zwischen den Endstellen zu optimieren sind. Um die begrenzte Ressource Packer sinnvoll einzusetzen, sind optische Zustandsmeldungen vorzusehen und ggf. geeignete Bedienstrategien zu deﬁnieren. 3.3.3 Verteiltechniken Vielseitig und h¨ auﬁg eingesetzte Verteiltechniken f¨ ur klassisches St¨ uckgut sind Quergurtsorter, Kippschalensorter und Schiebeschuhsorter, die im Folgenden vorgestellt werden. Weitere Systeme sind unter anderem in [24] beschrieben. Neben den Anwendungen im St¨ uckgutbereich werden Sorter insbesondere in der Briefsortierung eingesetzt. Weitere Speziall¨osungen die hier der Vollst¨ andigkeit halber erw¨ ahnt seien, ﬁnden sich beispielsweise zur Sortierung von H¨ angeware. Quergurtsorter Auf einer Wagenkette sind quer zur F¨orderrichtung Gurtf¨ orderer montiert, die auf die maximale Gutgr¨oße dimensioniert sind (s. Abb. 3.28). Jeder Gurtf¨ orderer ist separat verfahrbar. Bei der u ¨blichen Form der seitlichen Gutaufgabe wird der Gurtf¨ orderer im Moment der Gutaufgabe synchron zum Zuf¨ uhrband verfahren und das F¨ordergut geht ohne Re-

3.3 Sortier- und Verteilsysteme

121

Abbildung 3.28. Quergurtsorter [Foto: AXMANN]

lativbewegung auf den Sortierstrang u ¨ ber. Die Gutabgabe erfolgt beidseitig durch Aktivieren des Gurtf¨ orderers an der Endstelle. Zum Antrieb des Gurtf¨ orderers kommen sowohl zwangsgef¨ uhrte Systeme als auch Einzelantriebe zum Einsatz. Bei der aufw¨ andigeren Ausf¨ uhrung mit Einzelantrieben sind Fahr- und Gurtbewegung vollst¨ andig entkoppelt, wodurch nicht nur die Lage des Gutes auf dem F¨ orderelement nachjustiert, sondern auch die Abwurfbahn sowie die Lage des Gutes in der Endstelle beeinﬂusst werden k¨onnen. Der Antrieb der gesamten Wagenkette erfolgt mechanisch u ¨ ber Ketten, Schleppoder Schneckenantriebe oder linearmotorisch. Die Umlenkung und F¨ uhrung der Wagenkette kann sowohl horizontal als auch vertikal erfolgen, wodurch sich das System zum Einsatz in ring- und linienf¨ormig angeordneten Strukturen gleichermaßen eignet. Kippschalensorter Das Einzelplatzsystem nutzt im Wesentlichen die Erdbeschleunigung zur Ausschleusung der Sortierg¨ uter. Es besteht ebenfalls aus einer Aneinanderkettung einzelner Elemente (Wagen). Jeder Wagen besitzt eine seitlich zur F¨ orderrichtung kippbare Plattform (Schale), die eine beidseitige Gutabgabe erm¨ oglicht (s. Abb. 3.29). Bei der u ¨blichen Form der seitlichen Gutaufgabe wird das Sortiergut durch Reibung in der Schale abgebremst (ggf. unterst¨ utzt durch seitliche F¨ uhrungen). Die Aktivierung an der Endstelle erfolgt u are Schaltnocken. Daneben werden in neueren Sys¨ ber station¨ temen auch elektrische Einzelantriebe f¨ ur jedes Schalenelement vorgesehen, wodurch ebenfalls Fahr- und Ausschleusbewegung entkoppelt werden k¨onnen und gr¨ oßere Freiheiten bei der Gut¨ ubergabe bestehen. Auch die Form der Kippbewegung kann den Ausschleusvorgang beeinﬂussen. Das Ziel ist dabei im Allgemeinen eine Reduzierung der sonst relativ großen Endstellenbreite. Antrieb und Umlenkung erfolgen analog zum Quergurtsorter.

122

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.29. Kippschalensorter [Foto: BEUMER]

Schiebeschuhsorter Zwei vertikal umlaufende Ketten sind mit St¨aben oder Proﬁlen (Tragelemente) zur Aufnahme und zum Transport des Sortiergutes versehen. Auf jedem Tragelement ist ein verschiebbares Element (Schiebeschuh) angeordnet, das u uhrung unterhalb der Tragele¨ ber eine Zwangsf¨ ¨ mente gesteuert wird (s. Abb. 3.30). Uber ein entsprechendes Schienensystem und Weichen k¨ onnen die Schiebeschuhe an den Endstellen derart verfahren werden, dass auf dem Tragelement beﬁndliches Sortiergut in die Endstelle abgeschoben wird. Durch eine geeignete Vorausrichtung der Schiebeschuhe im Untertrum (R¨ ucklauf) der F¨ orderkette ist eine beidseitige Gutabgabe m¨ oglich. Die zwangsgesteuerte Gutabgabe erschließt ein weites Gutspektrum. Ausnahmen bilden G¨ uter mit Schlaufen und sehr kleine G¨ uter (<150 mm). Das System kommt in Linienanordnung zum Einsatz. Die Gutaufgabe erfolgt von vorne, horizontal am Beginn der Verteilstrecke. 3.3.4 Steuerung und Strategien Ein Sortier- und Verteilsystem stellt eine komplexe Einheit eines Materialﬂusssystems dar und bedarf vielf¨ altigster Steuerungs- und Optimierungsaufgaben. Zur Ansteuerung der typenabh¨ angigen Funktionalit¨aten ist ein separates, herstellerseitiges Steuerungssystem auf der Ebene eines Materialﬂussrechners unumg¨ anglich. Beim Einsatz in der Kommissionierung ist die zyklische Kommunikation ¨ mit dem u der Sortierkriterien erfor¨ bergeordneten Leitsystem zur Ubergabe derlich, die mit jedem Sortierbatch wechseln. Ebenfalls werden dar¨ uber die

3.4 Robotereinsatz in Lagersystemen

123

R [Foto: VANDERLANDE Abbildung 3.30. Schiebeschuhsorter (Posisorter) INDUSTRIES]

Vollst¨ andigkeit des Sortierauftrags gepr¨ uft bzw. Abbruchregeln (z. B. infolge fehlender G¨ uter durch Fehllesungen ( No-Read“) oder fehlerhafter Picks ” ( No-Need“)) initiiert. Zur Transparenz der Abl¨aufe ist die Dokumentation ” erfolgter und abgearbeiteter Auftr¨ age erforderlich. Der eﬃziente Sorterbetrieb ist keine triviale Aufgabe. Hier greifen verschiedenste Steuerungs- und Ablaufstrategien ineinander, beginnend bei der Bildung des Kommissionierbatches, u ¨ ber Starten und Beenden eines Batches, der Priorisierung der Zuweisung von Endstellen usw. bis zur Steuerung des Packsystems. Grundlegende Abh¨ angigkeiten wurden dazu in [43] erarbeitet. Eine sorgf¨ altige Planung, ggf. unter Hinzunahme einer rechnerbasierten Simulation des Gesamtsystems, ist daher sinnvoll.

3.4 Robotereinsatz in Lagersystemen Roboter sind Handhabungsger¨ ate, die neben der Lage eines Gutes im Raum auch die Orientierung beeinﬂussen k¨ onnen. Sie verf¨ ugen u ¨ ber mindestens drei unabh¨ angige Achsen. In Lagersystemen werden Roboter zur Palettierung und zur Kommissionierung eingesetzt.

124

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.31. Roboter in der Kommissionierung als Portalroboter [Foto: SWISSLOG]

3.4.1 Palettierroboter Palettierroboter dienen einerseits zur Entlastung des Menschen von monotonen und k¨ orperlichen Arbeiten bzw. T¨ atigkeiten, die des umst¨andlichen Einsatzes von Hilfsmitteln bed¨ urfen und dadurch lange Prozesszeiten erfordern. Gegen¨ uber automatischen Spezialanlagen k¨onnen sie ﬂexibler und bei geringerer Arbeitslast auch kosteneﬃzienter eingesetzt werden. Typische Roboter sind in diesem Einsatzbereich Portal- und Knickarmroboter. 3.4.2 Kommissionierroboter In der Kommissionierung werden sowohl Roboter eingesetzt, die auf Regalbedienger¨ aten montiert im Regalgang aus dem Fach kommissionieren, als solche, die auch in separaten Bereichen zur Kommissionierung gr¨oßerer standardisierter Einheiten von Palettenstapeln dienen. Der technische Aufwand und die realisierbare Leistung h¨ angen dabei wesentlich von der Bereitstellung der Entnahmeeinheiten ab. Je pr¨ aziser diese erfolgt, umso einfacher ist die Integration des Roboters in das Gesamtsystem. Sehr hohe Anforderungen an die Lageerkennung, Vereinzelung und Artikelhandhabung f¨ uhren dagegen zu zeitaufw¨ andigen und kostenintensiven Prozessen.

4. Grundlagen der betrieblichen Optimierung

Der optimale Betrieb eines Lager- oder Distributionssystems ist dann erreicht, wenn Kundenauftr¨ age jederzeit p¨ unktlich und vollst¨andig bearbeitet am Warenausgang zum Versand bereitstehen und auch unter wechselnden Anforderungen alle dazu erforderlichen operativen Abl¨aufe mit dem geringstm¨ oglichen Zeit- und Ressourcenaufwand erbracht werden. Um diese Anforderungen erf¨ ullen zu k¨ onnen, ist eine vorausgehende Planung und Abstimmung, d.h. eine Disposition dieser Abl¨ aufe notwendig. Die Auftragsdisposition in einem Warehouse Managementsystem hat damit die Aufgabe, alle Warenbewegungen im Lager vor der Ausf¨ uhrung den leistungserbringenden Ressourcen zuzuordnen sowie die Zeitpunkte und die Reihenfolge der Auftragsbearbeitung so zu bestimmen, dass eine fristgerechte Auftragsbearbeitung und eine gleichm¨ aßige Systemauslastung ohne Engp¨asse erreicht und der Anteil unproduktiver Nebenzeiten auf ein Minimum reduziert werden. Im vorliegenden Kapitel werden die Methoden der rechnergest¨ utzten Auftragsdisposition und die zugrunde liegenden Algorithmen und Heuristiken an typischen Problemstellungen in einem Lager einf¨ uhrend beschrieben.

¨ 4.1 Optimierung in der Ubersicht Die Optimierung betrieblicher Abl¨ aufe in einem Lager- oder Distributionssystem ist eine notwendige Konsequenz aus wirtschaftlichen und technischorganisatorischen Zielsetzungen. Jeder im Lager auszuf¨ uhrende Arbeitsschritt ist an eine oder mehrere Ressourcen, d.h. an Personal und Betriebsmittel gebunden, die Kosten und Zeitverbr¨ auche zur Folge haben. Dabei gilt es, die gesamte, aus allen einzelnen Arbeitsschritten zusammengesetzte Umschlagsleistung zwischen dem Warenein- und -ausgang mit dem geringstm¨ oglichen Aufwand an verf¨ ugbaren Ressourcen zu erbringen. Dar¨ uber hinaus entstehen durch den Verbund mit Lieferanten und Kunden weitere Randbedingungen, die ebenfalls bei einer betrieblichen Optimierung zu ber¨ ucksichtigen sind: Vorab vereinbarte Zeitfenster f¨ ur die Anlieferung durch Lieferanten sowie f¨ ur den Versand kundenseitig bestellter G¨ uter

126

4. Grundlagen der betrieblichen Optimierung

am Warenausgang geben einen Rahmen f¨ ur die im Verlauf eines Arbeitszeitraumes auszuf¨ uhrenden T¨ atigkeiten vor. Die Auskunftsf¨ahigkeit u ¨ ber Waren und Liefer- bzw. Abholtermine gegen¨ uber Kunden wird umgekehrt erst durch eine vorausgehende Disposition erm¨ oglicht. 4.1.1 Hintergrund Optimal zu handeln bedeutet, aus einer Menge von Handlungsm¨oglichkeiten diejenige Entscheidung (zu treﬀen), welche eine speziﬁzierte Zielsetzung am ” ehesten erf¨ ullt“[40]. Derartige Entscheidungssituationen ﬁndet man in allen Bereichen des menschlichen Lebens. In der Logistik stehen gleichsam Entscheidungsprozesse an, die eine optimierte Auswahl erwarten; ein typisches Beispiel sind die Planungsschritte zur Gestaltung eines Materialﬂusssystems. Verschiedene systemtechnische L¨ osungsvarianten werden erarbeitet, die f¨ ur eine weitere Systemauswahl auf letztlich eine Variante zu beschr¨anken sind. Die Auswahl st¨ utzt sich dabei auf die Formulierung der mit dem Materialﬂusssystem verbunden Zielsetzungen. In einem gr¨ oßeren Umfang treten Entscheidungssituationen im sp¨ateren Betrieb eines Materialﬂusssystems auf. Die Auftragsdisposition ist beispielhaft f¨ ur derartige Entscheidungssituationen. Dort gilt es, die optimale Reihenfolge der Bearbeitung einer Auftragssequenz zu bestimmen. Optimierung ist die klassische, mit der Gestaltung und dem Betrieb aller technischen Systeme verbundene Aufgabenstellung. Sie umfasst alle Aspekte der Systemgestaltung mit der allgemeinen Zielsetzung, eine gew¨ unschte Funktionalit¨ at zu insgesamt geringstm¨ oglichen Kosten herzustellen. Entsprechend vielf¨ altig und unterschiedlich in ihrer Anwendung sind die unter dem Begriﬀ Optimierungstheorie vereinten Methoden. Zun¨ achst soll daher eine Einf¨ uhrung in die Grundz¨ uge der Optimierungstheorie gegeben werden. Im Anschluss erfolgt eine Einordnung lagerlogistischer Optimierungsprobleme in diesen breiten wissenschaftlichen Kontext. Grunds¨ atzlich ist Optimierung gleichzusetzen mit der zielorientierten Suche nach dem bestm¨ oglichen Ergebnis innerhalb eines vorgegebenen Handlungsspielraumes bzw. innerhalb einer Menge gegebener Handlungsalternativen. Gesucht ist diejenige Alternative, mit der ein optimales Ergebnis in einer der folgenden Auspr¨ agungen erreicht wird [26]: • mit einem gegebenen Aufwand das bestm¨ ogliche Ergebnis erzielen (Maximierungsproblem) • ein deﬁniertes Ergebnis mit dem geringstm¨ oglichen Aufwand erreichen (Minimierungsproblem) • ein bestm¨ ogliches Ergebnis mit dem geringsten Aufwand erreichen (sog. Dualproblem) Zur Bestimmung der optimalen L¨ osung m¨ ussen die Alternativen quantiﬁzierbar, d.h. gegeneinander bewertbar sein. Wesentliche Elemente der Optimierung sind daher die Deﬁnition der Zielkriterien, anhand derer optimiert

¨ 4.1 Optimierung in der Ubersicht

127

werden soll, sowie die Aufstellung einer Zielfunktion, mit welcher der Zielerreichungsgrad bzw. die Optimalit¨at einzelner Alternativen ermittelt werden kann. Die allen Optimierungsproblemen zugrunde liegende Aufgabenstellung lautet danach allgemein [40]: Bestimme das Gesuchte (W ) unter Ber¨ ucksichtigung des Gegebenen (G), so dass eine Zielfunktion Z(W, G) minimiert oder maximiert wird. Verschiedene wissenschaftliche Disziplinen haben wesentlich zur Entwicklung anwendungsspeziﬁscher mathematischer L¨osungsverfahren f¨ ur Optimierungsprobleme beigetragen. Zu nennen sind u. a. die Spieltheorie und die Entscheidungstheorie [44], die allerdings vorrangig zur L¨osung ¨okonomischer Fragestellungen herangezogen werden. Zwei historisch aus unterschiedlichen Aufgabenstellungen entstandene wissenschaftliche Bereiche besch¨ aftigen sich unmittelbar mit den Problemen der Planung und betrieblichen Optimierung: Operations Research (OR) (engl. Unternehmensforschung) hat die Entwicklung von Methoden und Verfahren (Algorithmen) zur Bestimmung optimaler L¨ osungen zum Ziel. Typische Anwendungsfelder des OR sind die Erstellung von Zeitpl¨ anen (Schedules) und die Reihenfolgeplanung von Arbeitsschritten sowie die L¨ osung von Standortproblemen, die z.B. in der Lagerplanung zur Wegminimierung durch eine entsprechende Anordnung von Lagerbereichen auftreten. Ein wichtiges Kriterium des OR ist der Aufwand zur L¨ osungsbestimmung. Wie im weiteren Verlauf dieses Kapitels noch dargestellt wird, existieren Optimierungsprobleme, die sich durch Rechner in endlicher Zeit nicht optimal bzw. u ¨ berhaupt nicht l¨osen lassen. Artiﬁcial Intelligence (AI) (engl. K¨ unstliche Intelligenz – KI) geht u ¨ ber die Methoden des OR hinaus, da sie den Aspekt autonomer Entscheidungsﬁndung bei Maschinen (Rechnern) mit einbezieht und versucht, Muster der Humanintelligenz auf Rechner zu transformieren. Beispielhaft sei die Modellierung bestimmter Optimierungsprobleme mit Hilfe k¨ unstlicher neuronaler Netze genannt. Hierbei steht weniger die Bestimmung der exakten optimalen L¨ osung eines Problems, sondern die generelle L¨osungsm¨oglichkeit in akzeptabler Laufzeit auch unter Einbußen in der L¨osungsg¨ ute im Vordergrund. Eine klare Abgrenzung beider Disziplinen ist angesichts z.T. identischer Anwendungsbereiche und sich u ¨ berschneidender Methoden heutzutage nicht mehr auszumachen, beide sind als rechnergest¨ utzte Verfahren in der Informatik vereint.

128

4. Grundlagen der betrieblichen Optimierung

4.1.2 Einordnung der betrieblichen Optimierung In allen Phasen eines Lager- oder Distributionssystems, d.h. von der Planung bis zum sp¨ ateren Betrieb, treten Fragestellungen der Optimierung auf. Als generelle Zielsetzungen der Optimierung k¨ onnen u. a. folgende festgehalten werden: • • • • •

gleichm¨ aßige Auslastung der Betriebsmittel und des Personals Vermeidung unproduktiver Nebenzeiten Minimierung des Leerfahrtenanteils von F¨ ordermitteln Minimierung der Auftragsdurchlaufzeit Einhaltung vorgegebener Zeitfenster der Auftragsbearbeitung

Ein erster Ansatz zur Klassiﬁzierung ist der zeitliche Horizont der verschiedenen, nachfolgend vorgestellten Problemstellungen. Langfristige Planungsaufgaben beinhalten die Auslegung eines Lagersystems mit den strategischen Fragestellungen: • Dimensionierung von Lagerﬂ¨ achen und Auswahl der Lagersystemtechnik • Bildung eines Lagerlayouts (Anordnung der Lagerbereiche und Zugangswege) • Erstellung grundlegender Betriebsstrategien und Nachweis der Systemfunktionalit¨ at, beispielsweise durch Simulation Bei der Aufstellung eines Lagerlayouts sind die Lagerbereiche und Wege so anzuordnen, dass die im Vorfeld der Planung prognostizierten Warenmengen durch die ausgew¨ ahlte Systemtechnik mit insgesamt minimalem Transportaufwand bew¨ altigt werden k¨ onnen. Zwar ist die Anlagenplanung kein Bestandteil der betrieblichen Optimierung, es sei jedoch darauf hingewiesen, dass bereits in dieser Phase eine mitunter sehr detaillierte Kenntnis u ur den Betrieb der verschiedenen Ar¨ber einzusetzende Betriebsstrategien f¨ beitsbereiche eines Lagersystems erforderlich sein kann. Zum Nachweis der Gesamtfunktionalit¨ at k¨ onnen die sp¨ ater einzusetzenden und in einem WMS abzubildenden Betriebsstrategien in einem Simulationsmodell implementiert und auf diese Weise fr¨ uhzeitig optimiert werden. Mittelfristige, beispielsweise in monatlichen oder w¨ochentlichen Abst¨anden anstehende Planungsprozesse orientieren sich an den u ¨ ber diese Zeitr¨aume aggregierten Umschlagszahlen eines Lagersystems und sollen die im System vorgehaltenen Ressourcen auf saisonal schwankende Anforderungen anpassen. Typische Planungsaufgaben sind danach die • Sortimentsplanung (Anpassung des im Lager vorzuhaltenden Artikelspektrums als Reaktion auf saisonale bzw. marktbestimmte Einﬂ¨ usse), • Personalbedarfsplanung (Erstellung von Schichtenmodellen bzw. Arbeitszeitpl¨ anen),

¨ 4.1 Optimierung in der Ubersicht

129

• Reorganisation von Lagerbest¨ anden, z.B. Umlagerungen anhand vorausgehender ABC-Analyse1 . Eine Reorganisation von Lagerbest¨ anden durch Umlagerung von Artikeln mit h¨ auﬁgem Zugriﬀ in vordere Lagerbereiche ist f¨ ur sich genommen ebenfalls eine betriebliche Optimierungsmaßnahme, die zur Erh¨ohung der Zugriﬀsgeschwindigkeit auf Artikel eingesetzt wird und damit insgesamt zur Minimierung von Auftragsdurchlaufzeiten beitragen kann. Sofern gen¨ ugend Kapazit¨ aten zur Auftragsbearbeitung im Lager vorgehalten werden, kann diese Maßnahme auch in k¨ urzeren Zyklen erfolgen, allerdings ist der zus¨atzliche Aufwand f¨ ur die Umlagerungen mit dem sich einstellenden Einsparpotenzial abzugleichen. Unter betrieblicher Optimierung im eigentlichen Sinn ist die operative Planung, d.h. die Disposition der im Tagesgesch¨aft abzuwickelnden Arbeitsabl¨ aufe zu verstehen. Sie ist am aktuellen, i. Allg. taggenauen Bestell- und Lieferaufkommen orientiert und bildet ein geplantes Betriebsgeschehen maximal u ullenden ¨ber einen Zeitraum weniger Tage oder Stunden ab. Die darin zu erf¨ Aufgaben sind • Ressourcenzuordnung, Terminierung und Reihenfolgeplanung von Kommissionier- und Transportauftr¨ agen, • Routenplanung von Transporten im Lager, • u ¨ bergreifende Planung von Batches (engl. Auftragsstapel ), d.h. Vorplanung aller vorgenannten Arbeitsprozesse im Lager. Der f¨ ur die Disposition zur Verf¨ ugung stehende Planungszeitraum vari¨ iert je nach Aufgabenstellung und wird zudem durch kurzfristige Anderungen wie zwischenzeitlich eingehende Eilauftr¨ age, ungeplante Wareneing¨ange (Anlieferung ohne vorhergehende Terminierung durch den Lieferanten, falsche Liefermengen) oder St¨ orungen im laufenden Betrieb beeinﬂusst. Abh¨ angig von den vorliegenden Auftragsdaten der zu disponierenden Auftr¨ age und der f¨ ur die Disposition verf¨ ugbaren Zeit werden die Optimierungsaufgaben weiterhin unterschieden in Oﬄine- und Online-Probleme. Oﬄine-Probleme sind dadurch gekennzeichnet, dass alle Auftragsinformationen vor einer Disposition, d.h. der Berechnung eines optimalen Auftragsplanes (Schedule, vgl. auch Abschn. 4.2) vollst¨andig vorliegen. Das OﬄineScheduling ist gleichsam die klassische Form der Reihenfolgeplanung im Opeagigen Literatur ausf¨ uhrlich behanrations Research und wird in der einschl¨ delt. 1

Die allgemeine Form der ABC-Analyse ist die so genannte Cluster-Analyse, bei der die Zugriﬀsh¨ auﬁgkeit auf das in einem Lager vorr¨ atige Artikelspektrum nicht allein auf drei (A-B-C), sondern auf beliebig viele disjunkte Artikelmengen bezogen wird. Im ¨ außersten Fall bestehen die zu untersuchenden Mengen aus genau einem Artikel.

130

4. Grundlagen der betrieblichen Optimierung

Online-Probleme treten auf, falls Auftr¨ age ohne vorherige Berechnung eines Schedules unmittelbar den Betriebsmitteln zur Ausf¨ uhrung zugeordnet oder neue Auftr¨ age in einen bereits angelaufenen Arbeitsprozess mit vorbestimmtem Arbeitsablauf eingeplant werden. Eine andere Bezeichnung f¨ ur Online-Probleme ist das Dispatching. Online-Probleme entstehen u. a. auch dann, wenn in einem bereits geplanten Schedule kurzfristig neue Auftr¨ age eingeplant werden m¨ ussen. Gr¨ unde k¨ onnen beispielsweise Warenanlieferungen ohne vorherige Ank¨ undigung oder kurzfristig eingegangene Eilauftr¨ age sein, die dann in vorgeplante Auftragssequenzen einzuf¨ ugen sind. Die Optimierungstheorie unterscheidet eine Vielzahl weiterer Klassen von Problemen bzw. Optimierungsmodellen, die sich im Hinblick auf die korrespondierende logistische Aufgabenstellung nur geringf¨ ugig unterscheiden und an dieser Stelle nicht weiter betrachtet werden sollen. F¨ ur ein vertieftendes Studium sei an dieser Stelle auf [26, 40] verwiesen. 4.1.3 Begriﬀe und Elemente der Disposition M¨ ogliche Vorgehensweisen bei der Disposition werden nach [46] unterschieden in • auftragsbasierte (order based) Disposition, d.h. jeweils ein bisher noch nicht eingeplanter Auftrag wird gew¨ ahlt und dieser wird vollst¨andig verplant, d.h. f¨ ur alle Schritte des Auftrags werden passende Ressourcen und Zeitintervalle gew¨ ahlt. Dies wird wiederholt, bis alle Auftr¨age geplant sind. • ressourcenbasierte (resource based) Disposition, d.h. jeweils eine Ressource wird gew¨ ahlt und darauf der am besten passende Schritt eines Auftrags verplant. Dies wird ebenfalls so lange wiederholt, bis alle Auftr¨age (alle Schritte aller Auftr¨ age) geplant sind. • operationsbasierte (operation based) Disposition, d.h. so lange, bis alle Auftr¨ age verplant sind, wird eine Operation (Arbeitsschritt) gew¨ahlt und dazu die passende Ressource und ein passendes Zeitintervall gesucht. Die Ausf¨ uhrungen zur Optimierung der Auftragsdisposition sind als operationsbasierte Disposition zu verstehen, f¨ ur eine genaue Einordnung und Darstellung des Ablaufes dieser Dispositionsart in Form der Batchbildung sei an dieser Stelle auf Abschnitt 4.2.4 verwiesen. Kundenauftr¨age bezeichnen die von einem u ¨ berlagerten ERP-System veruber, welche Arwalteten Bestellungen und enthalten alle Informationen dar¨ tikel in welcher Menge f¨ ur einen Kunden zu einem vereinbarten Liefertermin am Warenausgang bereitstehen sollen. Die grundlegenden Elemente der Disposition sind Auftr¨age, die von den Ressourcen im Lager ausgef¨ uhrt werden sollen. Im Unterschied zu Kunden-

4.2 Optimierungsaufgaben im Lager

131

auftr¨ agen als ausl¨ osende Elemente des Lagerbetriebes beschreibt der Auftragsbegriﬀ im Rahmen der betrieblichen Disposition die Ortsver¨anderung genau einer Lagereinheit (Ladehilfsmittel, Gebinde, Artikel) von einer Quelle zu einer Senke und damit eine elementare logistische Operation. Die bei einer Disposition zu ber¨ ucksichtigenden Auftragsbestandteile sind beispielsweise • eindeutige Kennzeichnung der zu bewegenden Einheit (LHM-ID, Artikelnummer), • Quelle und Senke, • bearbeitende Ressource, • Auftragsbezug (beispielsweise Unterauftrag zu einem u ¨bergeordneten Kommissionierauftrag), • Zeitfenster (fr¨ uhester Auftragsbeginn, sp¨ ateste Auftragsausf¨ uhrung), • Priorit¨ at, • Auftragsstatus (noch unbearbeitet, in Bearbeitung, erledigt). Quellen und Senken k¨ onnen, abh¨ angig von der Art des Auftrages, Lagerorte, aber auch Ressourcen oder Ladehilfsmittel im Lager sein. Gemeinsam mit der Auswahl der ausf¨ uhrenden Ressource und der Angabe u ¨ ber die zu bewegende Lagereinheit stellen diese Angaben die wesentlichen Auftragsinformationen dar. Ressourcen bezeichnen die auftragsausf¨ uhrenden Einheiten eines Lagersystems, d.h. das Personal und die F¨ order- bzw. Lagertechnik. Um die in einem Arbeitszeitraum zu disponierenden Auftr¨ age auf die Ressourcen eines Lagers zuteilen zu k¨ onnen, m¨ ussen ebenfalls Informationen u ¨ber diese Ressourcen mitgef¨ uhrt werden: • Leistungsgr¨ oßen (F¨ ordergeschwindigkeit, Greifzeit etc.) • Kapazit¨ at • aktuelle Auslastung Dar¨ uber hinaus sind f¨ ur eine Auftragsdisposition weitere Angaben u ¨ ber die r¨ aumlichen Gegebenheiten innerhalb eines Lagers, d.h. dessen Topologie, erforderlich, um einerseits die Bearbeitungsdauer eines Auftrages anhand des im Auftragsablauf zur¨ uckzulegenden Weges kalkulieren zu k¨onnen und andererseits im Falle verschiedener m¨ oglicher Transportwege zwischen einer Quelle und einer Senke die k¨ urzestm¨ ogliche Verbindung ermitteln zu k¨onnen. Die Angabe von Weg- oder Spielzeiten in Form von Adjazenzmatrizen ist ein notwendiger Bestandteil des Datenmodells innerhalb eines WMS.

4.2 Optimierungsaufgaben im Lager Zur Einf¨ uhrung in die Methoden der betrieblichen Optimierung und der damit verbundenen Problemstellungen werden zun¨achst einige Beispiele vorgestellt.

132

4. Grundlagen der betrieblichen Optimierung

4.2.1 Transportoptimierung Ein WMS steuert die Transporte in einem Lager, beispielsweise die Palettentransporte zwischen den verschiedenen Lagerbereichen durch Stapler, Transporte auf F¨ ordersystemen oder auch die Ein- und Auslagerungen in automatisierten Hochregall¨ agern, die im Folgenden n¨aher betrachtet werden sollen. In einem Hochregallager werden alle Transporte als einzelne Transportauftr¨ age f¨ ur jeweils ein Ladehilfsmittel unter Angabe der Quelle- und Senkekoordinaten vom WMS verwaltet und zur Ausf¨ uhrung sequentiell jeweils an die unterlagerten Steuerungen der RBG in den Gassen u ¨ bermittelt. Auf diese Weise steuert das WMS die Reihenfolge der von einem RBG in einer Gasse auszuf¨ uhrenden Arbeitsspiele. In jeder Gasse sind die ein- und auszulagernden Ladehilfsmittel auf Stellpl¨ atzen in der Lagervorzone gepuﬀert, die Transportbewegungen im HRL sind so durch die Puﬀerpl¨atze vom u ¨ brigen Materialﬂuss im Lager entkoppelt. Eine grundlegende Optimierungsmaßnahme in einer Gasse ist dann die Sequenzierung von gleichzeitig anstehenden Ein- und Auslagerungen in Mehrfachspielen. Bildung von Doppelspielen Im betrachteten Fall habe das Lastaufnahmemittel eines RBG eine Aufnah¨ mekapazit¨ at von einer Palette. Da die Vorzone als Ubergabepunkt zum Beginn und zum Ende eines Mehrfachspiels angefahren werden muss, ist eine Optimierung in diesem Fall auf die Zusammenlegung von zwei Transporten, einer Einlagerung und der nachfolgenden Auslagerung, in einem Doppelspiel beschr¨ ankt. Sind Transportauftr¨ age in entsprechender Anzahl vorhanden, beginnt das RBG ein Doppelspiel mit der Aufnahme einer einzulagernden Palette aus der Vorzone, lagert diese am vorgesehenen Platz ein und f¨ahrt anschließend den Lagerort einer auszulagernden Palette an, um diese auf einem Platz in der Vorzone abzugeben. Falls mehrere Ein- und Auslagerauftr¨ age f¨ ur eine Gasse im Auftragsbestand des WMS vorhanden sind, die ohne zus¨ atzliche Restriktionen bez¨ uglich der Ausf¨ uhrungsreihenfolge in vollst¨ andigen Doppelspielen ausgef¨ uhrt werden k¨ onnen, ist vom WMS vor der Beauftragung des RBG die g¨ unstigste Kombination m¨ oglicher Doppelspiele zu ermitteln. Der in Abb. 4.1 angenommene Auftragsbestand umfasst drei Ein- und Auslagerauftr¨ age und somit drei Doppelspiele2 , die in einer Sequenz nacheinander vom RBG abgearbeitet werden sollen. Zu Beginn der Sequenz sind die ¨ ¨ bis U3 ¨ mit den Paletten der Auftr¨age 1 bis 3 belegt. Die Ubergabepl¨ atze U1 im Anschluss an eine Einlagerung ausgelagerte Palette wird dann jeweils auf ¨ ¨ U2 ¨ oder U3) ¨ abgestellt. dem zuvor frei gewordenen Ubergabeplatz (U1, 2

¨ ¨ Zur besseren Ubersicht sind die anzufahrenden Lagerorte und die Ubergabepl¨ atze in diesem Beispiel in einer Ebene angeordnet, bei der Bestimmung der optimalen Doppelspielreihenfolge sind so nur die horizontalen Entfernungen zu ber¨ ucksichtigen.

4.2 Optimierungsaufgaben im Lager

Auftrag

Quelle

Senke

Auftrag

Quelle

Senke

1

Ü1

LP1

4

LP7

Ü1/Ü2/Ü3

2

Ü2

LP3

5

LP4

Ü1/Ü2/Ü3

3

Ü3

LP6

6

LP2

Ü1/Ü2/Ü3

133

Abbildung 4.1. Beispiel f¨ ur Doppelspiele in einem Palettenhochregallager

An den ersten der drei Einlagerauftr¨ age 1 bis 3 kann einer der drei Auslagerauftr¨ age 4 bis 6 anschließen, dem folgenden Einlagerauftrag (einer von zwei m¨ oglichen) kann dann noch einer der verbleibenden zwei Auslagerauftr¨age zugeordnet werden, das letzte Doppelspiel ergibt sich aus den u ¨ brigen beiden Fahrauftr¨ agen. Da jeder der Einlagerauftr¨age 1 bis 3 der erste Fahrauftrag dieser Sequenz sein kann, ergibt sich die Anzahl n m¨oglicher Doppelspiele bei diesem Auftragsbestand nach Gl. 4.1 zu n = 3 · 3 · 2 · 2 · 1 · 1 = 3! · 3! = (3!)2 = 36

(4.1)

Demnach m¨ ussen theoretisch 36 Kombinationen auf eine optimale Fahrtenfolge hin untersucht werden. Da bei allen Doppelspielen der Zeitanteil f¨ ur die Aufnahme und Abgabe der Paletten konstant bleibt, ist das alleinige Optimierungskriterium der zu minimierende Gesamtweg. Mit den Distanzen3 der Einzelauftr¨ age aus Abb. 4.1 k¨ onnen die Distanzen der Doppelspiele aufgestellt und damit der insgesamt zu verfahrende Weg ermittelt werden (vgl. Tabelle 4.1). Bei der Berechnung kann der Umstand genutzt werden, dass die Reihenfolge der Doppelspiele oﬀenbar keinen Einﬂuss auf den Gesamtweg hat, es ist also unerheblich, ob die Doppelspielsequenz 1-5-9 (vgl. Tabelle 4.1) oder die Sequenz 9-1-5 beauftragt wird. Insgesamt reduziert sich durch diese Strategie der Aufwand zur Bestimmung der optimalen L¨osung, da nurmehr sechs Sequenzen (3 · 2 · 1 = 3!) gebildet und miteinander verglichen werden m¨ ussen. Im vorliegenden Beispiel ergibt sich als optimale Reihenfolge die Doppelspielsequenz 3-5-7 (bzw. die Auftragssequenz 1-6, 2-5, 3-4 ) mit einem 3

Die Distanzen sind einheitenlos in Lagerplatzkoordinaten (in diesem Fall nur in der Breite) angegeben.

134

4. Grundlagen der betrieblichen Optimierung

Tabelle 4.1. Ermittlung der optimalen Fahrtenfolge der drei Doppelspiele Nr.

Doppelspiel (Auftragssequenz)

Weg (Lagerplatzbreiten)

1

1 - 4 (Ü1 → LP1 → LP7 → Ü1)

20

2

1 - 5 (Ü1 → LP1 → LP4 → Ü1)

14

3

1 - 6 (Ü1 → LP1 → LP2 → Ü1)

10

4

2 - 4 (Ü2 → LP3 → LP7 → Ü2)

18

5

2 - 5 (Ü2→ LP3 → LP4 → Ü2)

12

6

2 - 6 (Ü2 → LP3 → LP2 → Ü2)

10

7

3 - 4 (Ü3 → LP6 → LP7 → Ü3)

16

8

3 - 5 (Ü3 → LP6 → LP4 → Ü3)

14

9

3 - 6 (Ü3 → LP6 → LP2 → Ü3)

14

Gesamtfahrweg von 38 Lagerplatzeinheiten; die schlechteste Doppelspielsequenz ist danach die Folge 2-4-9 (entspr. der Auftragssequenz 1-5, 2-4, 3-6 ) mit 46 Lagerplatzeinheiten. Allgemein gilt f¨ ur die Anzahl n m¨ oglicher Doppelspiele bei einem symmetrischen Auftragsbestand von jeweils k Ein- und Auslagerauftr¨agen: n = k! = k · (k − 1) · . . . · 2 · 1

(4.2)

Die in Gl. 4.2 aufgezeigte Problemgr¨ oße der Reihenfolgeplanung von Transportfahrten ist kennzeichnend f¨ ur eine Vielzahl ¨ahnlich gelagerter Optimierungsprobleme. Ein Prototyp f¨ ur Reihenfolge- oder auch Schedulingprobleme dieser Art4 ist das Travelling-Salesman-Problem (TSP), dessen ex-

4.2 Optimierungsaufgaben im Lager

135

akte L¨ osungsbestimmung f¨ ur verschiedene Probleminstanzen Gegenstand vieler Fachver¨ oﬀentlichungen ist und zudem ein grundlegendes Modell f¨ ur Optimierungsprobleme auch in anderen technisch-wissenschaftlichen Disziplinen darstellt. Charakteristisch f¨ ur das TSP ist der mit steigender Auftragsgr¨oße u ¨berproportional anwachsende Berechnungsaufwand, gekennzeichnet durch die Anzahl der zur L¨ osungsbestimmung erforderlichen Rechenschritte bzw. Vergleiche. Ist das hier vorgestellte Problem noch mit vergleichsweise geringem Aufwand in sechs Vergleichen exakt l¨ osbar, so w¨aren bereits bei zehn auszuf¨ uhrenden Doppelspielen 10! = 3.628.800 Vergleiche erforderlich. Nimmt man zur Berechnung dieser Auftragsgr¨ oße auf einem PC mittlerer Leistung eine Laufzeit von 0,1 s an, w¨ urde die exakte Berechnung einer Sequenz von 15 Doppelspielen anhand der Suche in allen L¨osungen hierbei bereits mehr als zehn Stunden dauern. Wie im Verlauf dieses Kapitels noch an anderer Stelle gezeigt wird, ist die Berechnungsdauer trotz steigender Rechnerleistungen angesichts der bei der Disposition aller Arbeitsschritte in einem Lager zu ber¨ ucksichtigenden Auftr¨ age durchaus eine kritische Gr¨ oße. Vielfach wird daher auf eine exakte L¨osung zugunsten der Laufzeit verzichtet. Die verschiedenen Verfahren zur Berechnung sind n¨ aher in Abschn. 4.3 beschrieben. Mehrfachspiele bei h¨ oherer Aufnahmekapazit¨ at In Beh¨ alter- oder Tablarl¨ agern, bei denen auch Lastaufnahmemittel (LAM) mit einer h¨ oheren Aufnahmekapazit¨ at eingesetzt werden k¨onnen, ergeben sich dar¨ uber hinaus noch weitergehende Kombinationsm¨oglichkeiten f¨ ur eine Zusammenf¨ uhrung und damit eine Optimierung der Transportfahrten. Ein LAM eines RBG in einem Beh¨ alterlager habe eine Aufnahmekapazit¨at ¨ ¨ und U2 ¨ zwei von zwei Beh¨ altern. Das LAM soll von den Ubergabepunkten U1 Beh¨ alter aufnehmen und an den Pl¨ atzen 1 und 2 einlagern (vgl. Abb. 4.2). Im Verlauf des Mehrfachspiels sind zwei weitere Beh¨alter von den Pl¨atzen 3 ¨ und 4 aufzunehmen und im Anschluss an den Ubergabepl¨ atzen abzugeben. Ist die Reihenfolge der Aufnahme und Abgabe von Beh¨altern beliebig, sind die in Abb. 4.3 dargestellten Kombinationen f¨ ur eine kombinierte Einund Auslagerung aller vier Beh¨ alter m¨ oglich. Theoretisch k¨onnen die Beh¨alter in einem Mehrfachspiel somit in acht unterschiedlichen Fahrtenfolgen (2 · (2 + 1 + 1)) bewegt werden. Um festzustellen, bei welcher Fahrtenfolge die k¨ urzeste Gesamtspielzeit erreicht wird, m¨ ussen die Zeitbedarfe aller Einzelfahrten ermittelt und f¨ ur jeweils eine der acht g¨ ultigen Kombinationen summiert werden. 4

Das hier angegebene Optimierungsproblem sieht nur die Bestimmung einer optimalen Reihenfolge der vorab bekannten Transportauftr¨ age vor. Zus¨ atzliche Bedingungen wie die Transportkapazit¨ at eines RBG oder Zeitfenster f¨ ur die Auftragsbearbeitung sind hierbei noch nicht ber¨ ucksichtigt.

136

4. Grundlagen der betrieblichen Optimierung

8

2 7

1 6 5 4 3

3 2

4 Ü 1

Ü 2

1

X 0

0 1

2

3

4

5

6

7

8

9

1 0

1 1

1 2

Abbildung 4.2. Beispiel eines Mehrfachspiels in einem Beh¨ alterlager

¨ F¨ ur das vorliegende Beispiel sei zur besseren Ubersicht angenommen, dass das RBG nach der Aufnahme der Beh¨ alter vom Referenzpunkt X aus die er¨ ste Einlagerung ausf¨ uhrt und nach der letzten Auslagerung vor der Ubergabe zun¨ achst wieder diesen Referenzpunkt anf¨ ahrt. Vereinfachend sei angenommen, die H¨ ohen und Breiten der Lagerf¨ acher seien ¨aquidistant und die horizontale und vertikale Fahrgeschwindigkeit des RBG identisch. Zwischen zwei Pl¨ atzen ist die Dauer einer Fahrt dann proportional zum l¨angeren Anteil eines Verfahrweges, d.h. dem Maximum des horizontalen und vertikalen Weganteils einer Einzelfahrt. In Tabelle 4.2 sind die m¨ oglichen acht Fahrtenfolgen und die sich daraus ergebenden Gesamtverfahrwege des RBG dargestellt. Die schlechteste (37 L¨ angeneinheiten) L¨ osung weist gegen¨ uber der besten L¨osung (26 L¨angeneinheiten) einen um etwa 42% h¨ oheren Gesamtfahrweg auf. Schon bei u ¨ berschaubaren Optimierungsaufgaben wie in diesem Fall k¨onnen also erhebliche Optimierungspotenziale entstehen. Das hier beschriebene Problem der Reihenfolgeplanung tritt in ¨ahnlicher Form in vielen Bereichen der Materialﬂusstechnik auf. Typische Anwendungsbeispiele sind neben den hier beschriebenen kombinierten Mehrfachspielen in Beh¨ alter- oder Tablarlagern auch Transportplanungsaufgaben f¨ ur Stapler und Schlepper, die eine Ladekapazit¨ at von mehr als einer Palette aufweisen und in einer m¨ oglichst kurzen Fahrt alle Ladestellen (Lagerorte) f¨ ur eine Beund Entladung anfahren sollen. Bei der Kommissionierung nach dem Prinzip Person-zur-Ware (vgl. Abb. 2.2.5) entstehen ebenfalls ¨ahnliche Aufgabenstellungen.

4.2 Optimierungsaufgaben im Lager

Aufnahme LHM 1 und 2

Zweiter Zweig für Einlagerung LHM 2

Verzweigungen (Folgeknoten)

Einlagerung LHM 1

Einlagerung LHM 2

Auslagerung LHM 3

Auslagerung LHM 4

Auslagerung LHM 4

137

2

Auslagerung LHM 3

Auslagerung LHM 4

3

Einlagerung LHM 2

Einlagerung LHM 2

2/1/1

Auslagerung LHM 3

1

Vom Zweig für Einlagerung LHM 2

Abgabe LHM 3 und 4

Abbildung 4.3. Fahrtenfolgen bei einem Mehrfachspiel (LAM mit zweifacher Kapazit¨ at)

Diese Aufgabenstellung geht allerdings u ¨ber die Anforderungen des urspr¨ unglichen TSP noch hinaus, da in diesen F¨allen die erh¨ohte Ladekapazit¨at eines F¨ ordermittels zu einer weitaus h¨ oheren Anzahl m¨oglicher Kombinationen der Auftragsbearbeitung und damit wiederum zu einem h¨oheren Berechnungsaufwand f¨ uhrt5 . Nachfolgend wird deshalb unter verallgemeinernden Annahmen der Berechnungsaufwand f¨ ur diese als multikapazitives TSP zu bezeichnende Optimierungsaufgabe anhand der Gr¨oße des zugrunde liegenden Suchraumes, d.h. der Anzahl m¨ oglicher Auftragskombinantionen hergeleitet. Ein F¨ ordermittel habe eine Aufnahmekapazit¨at von n gleichartigen Ladeeinheiten. Die Auftragsbearbeitung soll in einem geschlossenen Auftragszyklus vorab bekannter Auftr¨ age erfolgen, d.h. im Verlauf der Bearbeitung kommen keine weiteren Auftr¨ age hinzu. Am Beginn der Tour sind, entsprechend der F¨ ordermittelkapazit¨ at, n Ladeeinheiten aus einem Puﬀerbereich 5

Bereits das in Abb. 4.3 vorgestellte Beispiel eines LAM mit zweifacher Ladekapazit¨ at weist eine h¨ ohere Anzahl m¨ oglicher Auftragsfolgen auf (hier acht Kombinationen) als bei einem LAM mit einfacher Kapazit¨ at, das die Auftr¨ age in Doppelspielen abarbeitet (2! = zwei Kombinationen).

138

4. Grundlagen der betrieblichen Optimierung

auf das F¨ ordermittel umgeladen worden, die im Verlauf der Bearbeitung an den auftragsbezogenen Senken im Arbeitsraum eingelagert (E) werden sollen. W¨ ahrend der Fahrt sind, analog zum vorausgehenden Beispiel, ebenfalls n Ladeeinheiten auszulagern (A) und zur¨ uck zum Puﬀerbereich zu bringen; insgesamt werden in diesem Auftragszyklus damit 2·n Ladeeinheiten bewegt. Da alle Ein- und Auslagerauftr¨ age vor Beginn der Tour bekannt sind, kann eine vorausgehende Disposition erfolgen, in der die k¨ urzeste Tour f¨ ur das Anfahren aller Ladestellen (Quellen und Senken) im Arbeitsraum ermittelt werden soll. Bei der Aufstellung m¨ oglicher Auftragsreihenfolgen m¨ ussen aufgrund der beschr¨ ankten Kapazit¨ at des F¨ ordermittels allerdings einige einschr¨ ankende Bedingungen (engl. constraints) beachtet werden: 1. Eine Tour muss mit mindestens einer Entladung bzw. Einlagerung (E) beginnen und 2. endet mit der Aufnahme bzw. Auslagerung (A) der letzten verbleibenden Ladeeinheit. 3. Es k¨ onnen direkt aufeinanderfolgend nur maximal so viele Auslagerstellen (A) angefahren werden, wie freie Ladepl¨atze auf dem F¨ordermittel vorhanden sind. Anhand dieser allgemeinen Aufgabenbeschreibung lassen sich alle m¨oglichen Auftragskombinationen aufstellen und aus dem sich ergebenden Suchraum diejenige mit dem k¨ urzesten Gesamtweg ermitteln. Zur VeranschauliTabelle 4.2. Ermittlung einer optimalen Fahrtenfolge der Mehrfachspiele im Beispiel Fahrtenfolge

Einzeldistanzen und Gesamtweg

X→1→2→3→4→X

6 + 4 + 5 + 9 + 2 = 26 kürzestes Gesamtspiel

X→1→2→4→3→X

6 + 4 + 6 + 9 + 11 = 36

X→1→3→2→4→X

6 + 8 + 5 + 6 + 2 = 27

X→1→4→2→3→X

6 + 5 + 6 + 5 + 11 = 33

X→2→1→3→4→X

7 + 4 + 8 + 9 + 2 = 30

X→2→1→4→3→X

7 + 4 + 5 + 9 + 11 = 36

X→2→3→1→4→X

7 + 5 + 8 + 5 + 2 = 27

X→2→4→1→3→X

7 + 6 + 5 + 8 + 11 = 37 längstes Gesamtspiel

4.2 Optimierungsaufgaben im Lager je 2 E in - u n d A u s la g e r u n g e n

je 3 E in - u n d A u s la g e r u n g e n

2 x E

3 x E

E

2 x A

2 ! x A

E

2 x 2

2 x E

3 x A

E

A

3 ! x A

2 x 2

3 x 2 x 6

3 x A

2 x E

E

2 x A

E

2 x A

2 ! x A

E

2 ! x A

E

3 x 2 x 3 x 2 A

3 x 3 x 2 x 2

3 x 2 x 3 x 2

2 x 4 = 8 K o m b in a tio n e n

139

A

3 x 3 x 2 x 2

5 x 3 6 = 1 8 0 K o m b in a tio n e n

Abbildung 4.4. Suchbaum f¨ ur multikapazitive TSP

chung der Suchraumbildung ist eine Darstellung der Auftr¨age als Knoten in einem Suchbaum hilfreich, in dem zun¨ achst die Reihenfolge der Bearbeitung von Ein- und Auslagerungen eingetragen ist (vgl. Abb. 4.4). In der Abbildung sind die Suchb¨ aume f¨ ur ein multikapazitives TSP mit einer Kapazit¨ at von zwei bzw. drei Ladestellen dargestellt. Die Knoten der Suchb¨ aume kennzeichnen jeweils einen Auftrag innerhalb einer von oben nach unten zu durchlaufenden Auftragsreihenfolge. Innerhalb der Knoten ist die Art des Auftrages (Einlagerung E oder Auslagerung A) mit der Anzahl an Variationen f¨ ur einen Auftrag an dieser Stelle eingetragen. Jeder vollst¨ andige Zweig beschreibt so eine der m¨oglichen Auftragsreihenfolgen, in der allerdings nur die Reihung aufeinanderfolgender Ein- und Auslagerungen abzulesen ist, nicht jedoch eine konkrete Auftragssequenz6 . Eine Reihung steht jeweils stellvertretend f¨ ur diejenigen Auftragsreihenfolgen, in denen Ein- und Auslagerauftr¨ age auf die beschriebene Weise ange6

Zur Veranschauung seien die Einlagerauftr¨ age E1, E2 und E3 sowie die Auslagerauftr¨ age A1, A2 und A3 gegeben. Eine konkrete (und g¨ ultige) Auftragssequenz ist dann beispielsweise die Folge E1-E2-A2-E3-A1-A3. Als Reihung wird hier die qualitative Abfolge der Ein- und Auslagerungen ohne konkrete Angabe der Auftr¨ age bezeichnet, in diesem Fall ergibt sich damit die Folge E-E-A-E-A-A.

140

4. Grundlagen der betrieblichen Optimierung

ordnet sind. Die Anzahl aller f¨ ur diese Probleme m¨oglichen und g¨ ultigen7 Auftragsreihenfolgen ergibt sich f¨ ur einzelne Zweige durch eine Multiplikation der Knotenkoeﬃzienten innerhalb eines Zweiges, das Produkt ist f¨ ur alle Zweige identisch. Im rechten Suchbaum (siehe Abb. 4.4) sind die g¨ ultigen Auftragsreihenfolgen bei einer F¨ ordermittelkapazit¨ at k = 3 angegeben. In diesem Fall existieren f¨ unf Zweige mit g¨ ultigen Reihungen. Der oberste Knoten kann mit einem von drei m¨ oglichen Einlagerauftr¨ agen besetzt sein. Auf die gleiche Weise wird der Knotenkoeﬃzient f¨ ur den ersten oberen Auslagerauftrag bestimmt. F¨ ur die weiter unten liegenden Knoten ergeben sich entsprechend verringerte M¨ oglichkeiten. Die Anzahl nREIHUN G m¨ oglicher Reihungen bei einer gegebenen Kapazit¨ at k und der entsprechenden Menge an Ein- und Auslagerauftr¨agen kann kombinatorisch durch den in Gl. 4.3 dargestellten Zusammenhang ermittelt werden: (2·k)! nREIHUN G = 2·k = k!·(2·k−k)! = (2·k)! (4.3) k (k!)2 F¨ ur die Kapazit¨ at k = 3 ergeben sich somit 20 M¨oglichkeiten f¨ ur die Aneinanderreihung aller in einem Spiel durchzuf¨ uhrenden Ein- und Auslagerungen, von denen allerdings einige keine g¨ ultigen L¨osungen darstellen, da sie oﬀenbar undurchf¨ uhrbar sind. Die Anzahl nGUELT IG g¨ ultiger Reihungen wird nach Gl. 4.4 auf einfache Weise ermittelt zu 1 1 nGUELT IG = k+1 = k+1 · 2·k · (2·k)! (4.4) k (k!)2 ultigen Auftragsreihenfolgen errechnet Die Gesamtzahl nGESAMT aller g¨ sich dann, wie in Abb. 4.4 dargestellt, zu nGESAMT = nGUELT IG · (k!)2 =

(2·k)! k+1

(4.5)

Dabei entspricht der Term (k!)2 dem Produkt der Knotenkoeﬃzenten eines Zweiges. Insgesamt kann der Berechnungsaufwand in diesem Beispiel durch die hier dargestellte Strategie um mindestens 75% gegen¨ uber einer vollst¨andigen L¨ osung reduziert werden, in der alle m¨ oglichen (und damit auch die unbrauchbaren) Auftragsreihenfolgen ber¨ ucksichtigt sind. Neben der Bestimmung einer optimalen Reihenfolge ist damit ebenfalls der Berechnungsaufwand optimiert. Bei der Aufstellung m¨ oglicher Auftragsreihenfolgen ergeben sich bei Ber¨ ucksichtigung der oben genannten Zusammenh¨ange somit erhebliche Verringerungen der Problemgr¨ oße. Die Strategie der Reihung kann dar¨ uber hinaus 7

Ung¨ ultige Auftragsreihenfolgen sind hier beispielsweise diejenigen mit der Reiurde durch die ersten beiden Aufnahmen die Kapahung E-A-A-E-E-A. Hier w¨ zit¨ at des F¨ ordermittels u ¨ berschritten.

4.2 Optimierungsaufgaben im Lager

141

neben der Optimierung einzelner Spiele auch auf gr¨oßere Auftragsmengen angewendet werden, die nacheinander von einem F¨ordermittel in mehreren Spielen abgearbeitet werden. Beispielhaft seien jeweils vier Ein- und Auslagerungen mit geringstm¨oglichem Aufwand von einem F¨ ordermittel mit der Kapazit¨at k = 2 durchzuf¨ uhren. Theoretisch k¨ onnen die einzelnen Auftr¨age in 8! = 40320 verschiedenen Reihenfolgen abgearbeitet werden. Sch¨opft man die Kapazit¨at des F¨ ordermittels maximal aus und reiht die Auftr¨age in Gruppen so, dass in einem Spiel jeweils zwei Ein- und Auslagerungen durchgef¨ uhrt werden, wird die Anzahl m¨ oglicher Reihenfolgen auf (4!)2 · 22 = 2304 reduziert. Derartiges Wissen u ¨ ber problembezogene Zusammenh¨ange wird ebenfalls in anderen Optimierungsaufgaben zur Reduktion der Suchvorg¨ange verwendet, eine allgemeine Form dieser Vorgehensweise ist das Branch&Bound (vgl. Abschn. 4.3.3). 4.2.2 Bildung von Kommissionierreihenfolgen Die Optimierung der Kommissionierreihenfolge kann ebenfalls als Travelling¨ Salesman-Problem modelliert und gel¨ ost werden. Ubertragen auf Kommissioniersysteme stellen die Entnahmef¨ acher die Orte, das Kommissionierper¨ ¨ sonal bzw. die Systemtechnik die Fahrzeuge und die Ubergabe/ Ubernahme das Depot dar. Pro Auftrag muss auch hier die optimale Reihenfolge der Entnahmef¨ acher ermittelt werden. Zur L¨ osung von TSP und Tourenplanungsproblemen sind exakte und heuristische Verfahren entwickelt worden (vgl. Abschn. 4.3). F¨ ur die Bearbeitung praxisrelevanter Problemgr¨ oßen ist die Laufzeit der exakten Algorithmen zu groß, daher werden Heuristiken verwendet. Zur L¨osung von Tourenplanungen bieten sich Er¨ oﬀnungsverfahren an, die in einem ersten Schritt eine g¨ ultige, aber u.U. suboptimale L¨ osung liefern. Im Anschluss durchzuf¨ uhrende Verbesserungsverfahren k¨ onnen die L¨ osungsg¨ ute mitunter bis zur optimalen L¨osung steigern. M¨ ogliche Er¨ oﬀnungsverfahren zur L¨ osung von TSP sind beispielsweise das Verfahren des besten Nachfolgers oder die Streifenstrategie. Beim Verfahren des besten Nachfolgers wird aus einer Auftragsmenge, ausgehend von einem Startauftrag, jeweils derjenige Auftrag mit der k¨ urzesten Anfahrtdistanz als Nachfolger bestimmt. Bei der Streifenstrategie wird der Lagerquerschnitt horizontal in gleich große Streifen aufgeteilt (vgl. Abb. 4.5). Die F¨acher in den einzelnen Streifen werden der Reihe nach angefahren, am Ende des Streifens wird in den n¨ achsten gewechselt und die F¨acher dieses Streifens werden bearbeitet. Eine m¨ ogliche Verbesserung der Anfangsl¨osung kann ein Kantentausch herbeif¨ uhren, beispielsweise als 2-opt-, 3-opt- oder allgemein als r-opt-Verfahren bezeichnet (siehe auch Abschn. 4.3.3). Dieser Kantentausch ur alle Kanten jeweils mit einm Vergleich der sich neu einkann paarweise f¨ stellenden L¨ angen durchgef¨ uhrt werden. Das Verfahren ermittelt jedoch nicht

142

4. Grundlagen der betrieblichen Optimierung L a rg e s t-G a p

S tr e ife n

M ä a n d e r

Ü b e rg a b e p u n k t

M itte lp u n k t

S tic h g a n g

Abbildung 4.5. Kommissionierstrategien

alle Permutationen der Anfangsl¨ osung und f¨ uhrt deswegen nicht zwangsl¨auﬁg auf eine optimale L¨ osung. Heuristische Verfahren zur Tourenplanung (siehe Abb. 4.5) unterscheiden sich darin, ob die G¨ ange durchlaufen werden (M¨aander-Heuristik) oder ob in dem aktuellen Gang umgekehrt wird (Mittelpunkt- oder Largest-GapHeuristik). Bei der M¨ aander-Heuristik durchl¨ auft der Kommissionierer den Gang, wenn er mindestens ein anzulaufendes Fach enth¨alt. Die G¨ange werden in einer vorher festgelegten Reihenfolge von links nach rechts oder umgekehrt durchlaufen. Falls mehr als ein Fach pro Gang abzuarbeiten ist, stellt die MittelpunktHeuristik eine Alternative dar. Hier wird jeder Gang in zwei Teile aufgeteilt, die F¨ acher der oberen H¨ alfte werden von dem oberen Gang erreicht, die der unteren H¨ alfte von dem unteren. Der Kommissionierer verl¨asst den aktuellen Gang auf der Seite, auf der er ihn betreten hat. Eine weitere Verbesserung stellt die Largest-Gap-Heuristik dar. Im Gegensatz zur Mittelpunkt-Heuristik wird der Gang hier bis zum Largest Gap (bis zur gr¨ oßten L¨ ucke) durchlaufen. Eine L¨ ucke ist die Entfernung zweier benachbarter F¨ acher, die anzulaufen sind bzw. der Weg vom Gang zum n¨achsten Fach. Die gr¨ oßte L¨ ucke ist der Teil des Ganges, der nicht durchlaufen wird.

4.2 Optimierungsaufgaben im Lager

143

4.2.3 Routenplanung im Lager Aufgabe der Routenplanung im Lager ist die Bestimmung der k¨ urzesten Transportverbindung zwischen einer Quelle und einer Senke, sofern bei der Ausf¨ uhrung einer Transportbewegung mehrere Routen existieren. Im Gegensatz zur Anordnung der Lagerpl¨ atze in einem Hochregallager, die vom Einlagerpunkt aus unmittelbar in der k¨ urzesten Verbindung angefahren werden, kann beispielsweise die Linienf¨ uhrung eines Fahrerlosen Transportsystems das Abfahren einer Tour u ¨ ber verschiedene Routen erlauben. Auch die Transporte mit Staplern in einem Lager lassen in der Regel mehrere M¨oglichkeiten der Auftragsausf¨ uhrung zu8 . Eine typische Situation zeigt die nachfolgende Abbildung auf, in der ein Transportgut von der angegebenen Quelle zu der eingezeichneten Senke zu bewegen ist. 1 2

3

S 4

7

S

5 6

9 8

Q 1 0

1 1 Q

1 2

Abbildung 4.6. Routingproblem in einem Lager

Das Lagerlayout enth¨ alt in Reihen angeordnete Lagerpl¨atze, die u ¨ber ein orthogonales Netz von Wegen miteinander verbunden sind. Der k¨ urzeste Weg von der zwischen den Knoten 11 und 12 liegenden Quelle zur zwischen den Knoten 4 und 5 liegenden Senke wird auf nachvollziehbare Weise oﬀenbar u ¨ber die Route Q → 11 → 8 → 5 → S angefahren, prinzipiell sind aber auch alle anderen m¨ oglichen (und l¨ angeren) Routen zwischen den beiden Endknoten der Tour befahrbar. 8

wobei es in diesen F¨ allen oft der Ortskenntnis des Personals u ¨ berlassen bleibt, die k¨ urzeste Route zu einer anzufahrenden Senke zu bestimmen.

144

4. Grundlagen der betrieblichen Optimierung

Ein rechnergest¨ utztes Fahrzeugleitsystem hat im Rahmen der Auftragsdisposition die Aufgabe, die k¨ urzeste Route zu ermitteln, die bei der Auftragsausf¨ uhrung abgefahren werden kann. Neben einer Wegmatrix sind f¨ ur diesen Dispositionsschritt ebenfalls Informationen u ¨ber das Wegenetz innerhalb des Lagers zu hinterlegen, anhand derer die jeweils k¨ urzeste Route ermittelt werden kann. Ein Verfahren zur Ermittlung der k¨ urzesten Verbindung ist der DijkstraAlgorithmus, der zur Wegﬁndung zwischen einem Startknoten und einem Zielknoten in einem gegebenen zusammenh¨ angenden Graphen dient (vgl. Abschnitt 4.3.3). ¨ 4.2.4 Ubergreifende Auftragsdisposition – Batchplanung Ziel einer auftragsorientierten Batchbildung ist die Vorplanung der bis zu einem Stichtermin eingegangenen Auftr¨ age in festen zeitlichen Intervallen, so genannten Batches. Der Begriﬀ der Batchberechnung wird in verschiedenen Zusammenh¨angen verwendet und beschreibt sowohl die Vorplanung von Kommissionier- oder Sortierauftr¨ agen als auch die gesamte Auftragsplanung in einem Lager. Innerhalb eines Batches sind alle eingegangenen Auftr¨age so anzuordnen, d.h. zeitlich einzuplanen und auf die Ressourcen im Lager zu verteilen, dass eine m¨ oglichst kurze Bearbeitungszeit, eine deﬁnierte Bereitstellzeit im Versand und eine gleichm¨ aßige Auslastung des Systems bzw. der Ressourcen erreicht werden kann. Eine allgemeine Bezeichnung f¨ ur Optimierungsprobleme dieser Art ist das job-shop-scheduling. Die folgenden Ausf¨ uhrungen beschreiben die Batchplanung f¨ ur ein Lagersystem (siehe auch [57]). Einem WMS werden Auftr¨age vom u bergeordneten ¨ ERP-System u ¨ bermittelt, in dem Kundenauftr¨age entgegengenommen sowie Liefertermine anhand des aktuellen Lagerbestandes und der Auftragslast koordiniert und vorverarbeitet werden. Ein an das WMS u ¨ bermittelter Auftrag ist dann grundlegend durch die folgenden Auftragsbestandteile beschrieben: • • • •

Auftragsnummer (eindeutig) Kundennummer zu liefernde Artikelmenge f¨ ur diesen Auftrag Termin f¨ ur die Bereitstellung am WA (und anschließende Abholung durch einen Transportdienstleister)

F¨ ur die Batchplanung ist die Gr¨ oße des Zeitintervalls, in dem Auftr¨age einzuplanen sind, ein wesentlicher Parameter, da das gr¨oßte Optimierungspotenzial grunds¨ atzlich dann besteht, wenn eine große Auftragsmenge vorliegt. In direktem Zusammenhang mit dem zeitlichen Horizont der Batchplanung steht allerdings auch die Planung der auftragsbezogenen Liefertermine, die u atskennzahlen der Ressourcen abzufragen ¨ber jeweils aktuelle Produktivit¨ ist. Mitunter ist diese Art der Disposition allerdings nicht durchzuf¨ uhren:

4.2 Optimierungsaufgaben im Lager

145

eine exakte Vorausberechnung des Liefertermins f¨ ur einen Auftrag w¨ urde bedeuten, dass dieser Auftrag in den bis zu diesem Zeitpunkt vorhandenen Auftragsbestand eingeplant werden muss. Die dort gehaltenen Auftr¨age sind allerdings ebenfalls mit Zeitintervallen f¨ ur Liefertermine versehen, eine vollst¨ andige Neuberechnung des bis zu diesem Zeitpunkt erstellten Auftragsplanes ist damit unvermeidlich und entsprechend zeitaufw¨andig9 . Eine in Unternehmen vielfach realisierte Auftragsdisposition beruht auf einer mittelfristigen Absch¨ atzung der Produktivit¨at, die es beispielsweise erlaubt, alle bis zu einer festgelegten Uhrzeit im Verkauf eingegangenen Kundenauftr¨ age bis zum n¨ achsten Tag versandfertig am Warenausgang bereitzustellen. Die Auftragsdisposition im WMS (und damit die eigentliche Batchplanung) l¨ auft dann typisch in folgenden Schritten ab: • • • • •

¨ Ubernahme der Auftr¨ age vom Hostsystem Unterteilen der Auftr¨ age in Einpositions- und Mehrpositionsauftr¨age Ermittlung der Lagerorte der einzelnen Artikel Bestimmung der erforderlichen Beh¨ alteranzahl f¨ ur Kommissioniermengen Berechnung der Bearbeitungszeit (Durchlaufzeit) pro Auftrag

Die Bearbeitungszeit eines einzelnen Auftrages ist aus Einzelschritten, den Operationen zusammengesetzt, z. B. : • Kommissionierzeit (Basiszeit, Greifzeit, Totzeit, Wegzeit; s. Abschn. 2.2.5) • vorgelagerte Bereitstellung leerer LHM • Puﬀerung nach der Kommissionierung (abh¨angig davon, ob unmittelbar vor dem Versand kommissioniert wird, Arbeitszeit, Schichtenmodell) • Bereitstellung am Warenausgang Mehrpositionenauftr¨ age vereinen gleichartige Operationen, die in diesem Planungsschritt bereits in optimierter Reihenfolge anzuordnen sind, beispielsweise bei der auftragsreinen Kommissionierung. Die Operationen sind im Rahmen der Batchplanung weiterhin den Ressourcen im Lager zur Bearbeitung zuzuordnen. Auf diese Weise werden alle Kundenauftr¨age in elementare Operationen aufgeteilt. Ausgehend von den kundenauftragsbezogenen Lieferterminen erfolgt f¨ ur jede Operation eine r¨ uckw¨ artsgerichtete Terminierung. Jeder Ressource wird durch die Batchplanung auf diese Weise ein Auftragspool zugewiesen, der in einem weiteren Schritt gegebenenfalls lokal optimiert werden kann (siehe Abb. 4.7). Die Reihenfolge der Auftr¨ age in einem Auftragspool kann dabei noch modiﬁziert werden, falls die (zu diesem Zeitpunkt feststehenden) zeitlichen Vorgaben eine Reihenfolge¨ anderung erlauben. 9

Eine exakte Methode zur Batchberechnung wird in [1] vorgestellt. F¨ ur die tageweise Kommissionierplanung in einem Kommissionierbereich mit einigen tausend Auftragspositionen liegt die Berechnungsdauer eines exakten Verfahrens (CSP) danach im Bereich mehrerer Minuten.

146

4. Grundlagen der betrieblichen Optimierung O p e r a tio n

A 1 A 2

R e s s o u rc e n p u ffe r

R B G

K o m m is s io n ie r p u ffe r

S ta p le r

K o m m is s io n ie r e r

V e rs a n d

Abbildung 4.7. Auftragsbelegung von Ressourcen, dargestellt im GanttDiagramm

Die Berechnungsdauer der Batchplanung wird maßgeblich durch die Anzahl der zu planenden Auftr¨ age und damit auch durch den abzubildenden Arbeitszeitraum (Zeitintervall) bestimmt. Prinzipiell kann die Batchgr¨oße oder das Zeitintervall beliebig fein gew¨ ahlt werden, infolgedessen verringert sich auch die erforderliche Berechnungsdauer erheblich. Es ist allerdings zu ber¨ ucksichtigen, dass bei kleineren Zeitintervallen ein geringeres Optimierungspotenzial erzielt wird, da die Ressourcen dann nur in Ausnahmef¨allen u ¨ber dieses gesamte Intervall voll belegt werden k¨onnen. Andererseits steigt die Auskunftsf¨ ahigkeit u ¨ ber Ressourcenbelegungen bei kleineren Intervallen erheblich, da jederzeit Auftr¨age eingelastet und Batches neu berechnet werden k¨ onnen. Zwischen diesen beiden Anforderungen – optimierter Auftragsdurchsatz und kurzfristige Dispositionsf¨ahigkeit – bewegt sich die Batchplanung in einem WMS.

4.3 Verfahren der L¨ osungsoptimierung 4.3.1 Allgemeines Die im Rahmen der betrieblichen Optimierung und der Disposition im Warehouse Management auftretenden Probleme sind berechenbar, d.h. durch Algorithmen beschreibbar. Von grundlegender Bedeutung bei der Entwicklung und Anwendung solcher Algorithmen ist die Komplexit¨at als ein Maß f¨ ur den Berechnungsaufwand, den ein Algorithmus erzeugt; sie wird daher auch rechnerische Komplexit¨ at (computational complexity) genannt. Zur Ermittlung der Komplexit¨at wird anhand der Algorithmenstruktur eine Aufwandsabsch¨atzung getroﬀen,

4.3 Verfahren der L¨ osungsoptimierung

147

die den Ressourcenbedarf10 eines Algorithmus bei einer gegebenen Problemgr¨ oße n angibt. Die Zeitkomplexit¨ at T (n) kann als Funktion der n Eingangsdaten direkt durch Abz¨ ahlen der von einem Algorithmus bearbeiteten Operationen ermittelt werden. Da jedoch weniger exakte Zahlenwerte als das funktionale Verhalten f¨ ur große n im Vordergrund stehen, wird die Zeitkomplexit¨at durch die O-Notation ausgedr¨ uckt, welche den h¨ochsten Grad desjenigen Polynoms angibt, das die Laufzeit des Algorithmus beschreibt. Beispielhaft sind die Zeitkomplexit¨ aten typischer Aufgabenstellungen in steigender Reihenfolge aufgef¨ uhrt: • O(log n) : • • • • • •

O(n) : O(n log n) : O(n2 ) : O(nk ) : O(2n ) : O(nn ) :

logarithmischer Aufwand, z. B. bin¨are Suche in n geordneten Daten linearer Aufwand, z. B. Addition von n Eingabewerten quasilinearer Aufwand, z. B. Sortierung quadratischer Aufwand, z. B. Vektormultiplikation polynomialer Aufwand, z. B. Matrizenmultiplikation exponentieller Aufwand, z. B. Erf¨ ullbarkeitsprobleme z. B. Travelling-Salesman-Problem (TSP)11

Mit P wird nun die Klasse von Problemen bezeichnet, die ein deterministischer 12 Algorithmus in polynomialer und damit praktisch durchf¨ uhrbarer Zeit l¨ osen kann, also O(1), O(n) oder O(nk ). NP bezeichnet die Klasse von Problemen, welche nur ein nichtdeterministischer Algorithmus in polynomialer Zeit l¨ osen kann. Ein deterministischer Algorithmus ben¨otigt nach dem bisherigen Stand der Informatik dazu einen mit der Problemgr¨oße mindestens exponentiell ansteigenden Zeitaufwand. Kennzeichnend f¨ ur einen Algorithmus sind nach der formalen Deﬁnition folgende Eigenschaften: • Endlichkeit – Ein Algorithmus terminiert nach einer problembezogenen, vorab festgelegten Anzahl von Berechnungsschritten. • Eindeutigkeit – Zu jeder Zeit sind die weiteren Bearbeitungsschritte vorgegeben. • Eﬀektivit¨at – Jeder Bearbeitungsschritt wird in endlicher Zeit ausgef¨ uhrt. • Eﬃzienz – Durch den Algorithmus wird m¨ oglichst wenig Speicherplatz und Rechenzeit verbraucht. 10

11

12

verallgemeinert f¨ ur Speicher- und Zeitbedarf zur L¨ osungsﬁndung. Damit setzt sich die Komplexit¨ at aus der Zeitkomplexit¨ at T (n) und der Speicherkomplexit¨ at S(n) zusammen. Ein Algorithmus zur vollst¨ andigen L¨ osung des TSP ist durch das Laufzeitverhalten T (n) = (n!) exakt angegeben, die Ordnung O ergibt sich nach der Sterlingschen Formel √ zu n! ≈ nn · e−n · 2πn ≈ nn = O(nn ) ein Algorithmus, der nach einer vorab festgelegten Zeit eine (optimale) L¨ osung generiert.

148

4. Grundlagen der betrieblichen Optimierung

n e u e A u fträ g e A u ftra g s p o o l

R e s s o u rc e

Abbildung 4.8. Dispatching in Warteschlangen

Insbesondere ist an den Algorithmenbegriﬀ auch die Vorhersagbarkeit der L¨osungsg¨ ute gekn¨ upft; im Gegensatz dazu wird der Begriﬀ Heuristik13 f¨ ur diejenigen L¨ osungsverfahren verwendet, bei denen man keine Aussage zur L¨ osungsg¨ ute treﬀen kann. ¨ 4.3.2 Optimierungsverfahren im Uberblick Bei der Optimierung kombinatorischer Probleme kommt eine Vielzahl sehr unterschiedlicher Verfahren zum Einsatz, die sich durch die beschreibenden Algorithmen bzw. Heuristiken, das Laufzeitverhalten und die Robustheit unterscheiden. Die folgende Einteilung stellt zun¨achst die grundlegenden Verfahren vor, im anschließenden Abschnitt sind konkrete Implementierungen vorgestellt. Vergabestrategien in Warteschlangen Eine eﬃziente Methode zur Zuteilung von Auftr¨agen an Ressourcen, die insbesondere in Online-Problemen angewendet wird, stellen Vergabestrategien dar. Der Auftragspool einer Ressource ist in diesen F¨allen als Warteschlange zu betrachten, aus der nacheinander Auftr¨ age von der Ressource abgerufen werden. Jederzeit k¨ onnen allerdings neue Auftr¨age in diese Warteschlange eingelastet werden (Abb. 4.8). Eine Vorausberechnung der optimalen Auftragsreihenfolge aller in der Warteschlange beﬁndlichen Auftr¨ age ist nur bedingt m¨oglich, da die Auftragszusammensetzung u ¨ ber die Zeit variiert. Auf diese Anwendungsf¨ alle wird daher das Prinzip des besten Nach” folgers“ angewendet. Derartige Dispatching-Strategien bestimmen aus einem sich zeitlich ¨ andernden Auftragspool der Gr¨ oße n jeweils einen Auftrag mit linearem Suchaufwand (O(n)). Eine Optimierung, d.h. die Suche des besten Anschlussauftrages, orientiert sich an applikationsspeziﬁschen Kriterien F¨ ur F¨order- und Kommissioniersysteme kann dies die k¨ urzeste Anschlussfahrt sein. Weitere Optimierungskriterien sind die Auftragspriorit¨ at oder das Datum der Einlastung. Derartige Dispatching-Strategien werden in [1, 43] untersucht.

13

vom griechischen heuriskein: ﬁnden.

4.3 Verfahren der L¨ osungsoptimierung

149

Enumerierende Verfahren Bei den vollst¨ andigen enumerierenden Optimierungsverfahren werden alle L¨ osungen eines L¨ osungsraumes untersucht, daher ist garantiert, dass die exakte optimale L¨ osung gefunden wird. Dazu m¨ ussen jedoch mit entsprechendem Berechnungsaufwand alle L¨ osungen nacheinander erzeugt und bewertet werden. Da aber die Anzahl der L¨ osungen bei realen Problemen sehr hoch werden kann, sind vollst¨andige enumerierende Verfahren bei solchen Problemen nicht eﬃzient einsetzbar. Die typischen Probleme der Reihenfolgeplanung und des Scheduling werden zur Gruppe der NP-vollst¨ andigen Verfahren mit exponentiellem L¨ osungsaufwand gez¨ ahlt. Angepasste enumerierenden Optimierungsverfahren schr¨anken den Aufwand zur L¨ osungsﬁndung durch Integration von Problemwissen (Heuristiken) ein. Die vollst¨ andig enumerierenden Verfahren werden dabei so modiﬁziert, dass m¨ oglichst wenige L¨ osungen erzeugt und bewertet werden m¨ ussen, aber dennoch das Auﬃnden der besten L¨ osung (globales Optimum) garantiert bleibt. Ein bekanntes Beispiel f¨ ur solche Verfahren ist der Branch&Bound Algorithmus. Kalk¨ ulbasierte Verfahren Bei den indirekten kalk¨ ulbasierten Optimierungsverfahren wird die optimale L¨ osung durch ein Gradientenverfahren ermittelt, das die Steigung der Zielfunktion in Abh¨ angigkeit von den Parametern untersucht. Von der Zielfunktion werden die Gradienten zu Null gesetzt und anschließend das sich ergebende Gleichungssystem f¨ ur die entsprechenden Parameter gel¨ost. Die L¨osungen sind die lokalen Optima, die dann verglichen und bewertet werden. Auf diese Weise lassen sich die globalen Optima identiﬁzieren. Bei den direkten kalk¨ ulbasierten Optimierungsverfahren ﬁndet die Suche nach der besten L¨ osung durch gezielte Schritte im Suchraum statt. Ein zuf¨ allig gew¨ ahlter Ausgangspunkt repr¨ asentiert eine Anfangsl¨osung, in deren Umgebung die Richtung mit dem steilsten Anstieg, also der gr¨oßte Gradientenwert der Zielfunktion, bestimmt wird. Das Verfahren durchsucht unter dieser Vorgehensweise den L¨osungsraum iterativ und stoppt, wenn es keine Richtung mehr gibt, in der sich bessere L¨ osungen ﬁnden lassen. Dieser Ansatz wird als Hill-Climbing-Verfahren“ ” bezeichnet, da es zielsicher das n¨ achstgelegene lokale Optimum ﬁndet. Im besten Fall entspricht das zuletzt gefundene lokale Optimum dem globalen Optimum. Da das Auﬃnden des globalen Optimums aber nicht garantiert werden kann, ist das erzielte Ergebnis meist nur eine N¨aherung. Es sei noch einmal darauf hingewiesen, dass nur das enumerierende Optimierungsverfahren die beste L¨ osung garantiert, jedoch erfordern kalk¨ ulbasierte Optimierungsverfahren in den meisten F¨ allen einen erheblich geringeren Suchaufwand.

150

4. Grundlagen der betrieblichen Optimierung

Zufallsgesteuerte Verfahren Zufallsgesteuerte bzw. stochastische Optimierungsverfahren verwenden keine zielgerichtete Suche, sondern generieren iterativ zuf¨allige L¨osungen, die bis zum Erreichen eines Abbruchkriteriums bewertet und verbessert werden. Bei der Monte-Carlo-Strategie werden zuf¨ allig verschiedene L¨osungen erzeugt und bewertet. Wird im Optimierungslauf eine bessere als die zuletzt gespeicherte L¨ osung gefunden, wird die neu gefundene L¨osung u ¨ bernommen; ein u ¨ bliches Abbruchkriterium ist die Anzahl der Iterationen. Random Walk ist eine weitere Methode, den L¨osungsraum basierend auf einer Anfangsl¨ osung schrittweise zu durchsuchen. Jede L¨osung wird aus der ¨ zuletzt betrachteten durch zuf¨ allige, marginale Anderungen entwickelt. Die beste auf dem Weg gefundene L¨ osung wird gemerkt. Als Abbruchkriterium kann ebenfalls die Anzahl der erzeugten L¨ osungen deﬁniert werden. Naturanaloge Optimierungsverfahren sind ebenfalls in die Gruppe der stochastischen Verfahren einzuordnen. Hier werden in Analogie zu den namensgebenden nat¨ urlichen Vorg¨ angen die chemisch/physikalischen und die biologischen Modelle unterschieden. Weder bei der Monte-Carlo-Strategie und Random Walk noch bei einem der naturanalogen Verfahren k¨ onnen aus dem Verfahren heraus Aussagen u at der gefunden L¨ osung getroﬀen werden; unter Umst¨anden ¨ber Optimalit¨ wird nicht einmal ein lokales Optimum bestimmt. 4.3.3 Beispiele bekannter L¨ osungsverfahren F¨ ur alle Arten von Optimierungsproblemen sind z. T. sehr spezialisierte L¨osungsverfahren entwickelt worden. Die im Folgenden beschriebenen Algorithmen stellen eine Auswahl von in der Literatur ver¨oﬀentlichten Verfahren zur Optimierung lagerlogistischer Problemstellungen dar. Branch&Bound-Algorithmen Das Branch&Bound-Prinzip ist unter den exakten Verfahren eine Vorgehensweise, die systematisch m¨ oglichst erfolgsversprechende L¨osungen aus der L¨ osung einfacherer Teilprobleme aufbaut und die nicht zum Optimum f¨ uhrenden Teill¨ osungen aus der weiteren Untersuchung ausschließt. Um die Funktionsweise von Branch&Bound-Algorithmen zu verdeutlichen, soll die Ermittlung des k¨ urzesten Weges anhand eines einfachen Beispiels gezeigt werden (siehe Abb. 4.9). Betrachtet wird hierzu der dort gezeigte Graph mit den Knoten 1 bis 5 und den eingezeichneten Kantenl¨angen. Als ur eine zu bestimStartknoten soll Knoten 1 und als Zielknoten Knoten 5 f¨ mende Tour verwendet werden. Um die einzelnen Arbeitsschritte bei der Wegermittlung transparent zu machen, wird die L¨ osungsﬁndung an dem in Abbildung 4.10 gezeigten Schema beschrieben.

4.3 Verfahren der L¨ osungsoptimierung 3 2 1

4 4 5

5 3

151

3

8

4

5

B

M in

Abbildung 4.9. Beispielgraph f¨ ur ein TSP D is ta n z 2 3 4 1

1

0 2 4 1

3 4 5

2

0

0

0 0

0

4

4 8

0

5 0

1

3 3

V o rg ä n g e r 2 3 4 5 1

0 9

0 1

0

1

1

0

0 1

0

1 2

U n te rg re n z e 2 3 4 5 1 0

1

0

0

2

0 0

9

0

0 1 1 1 1 1 1

9

0

0 0 9

5

Abbildung 4.10. Schema zur Ermittlung des k¨ urzesten Weges

Distanz, Vorg¨ anger und Untergrenze stehen je f¨ ur ein Feld, dessen Gr¨ oße mit der Anzahl der Knoten des Graphen u ¨ bereinstimmt. In analoger Weise zum Dijkstra-Algorithmus wird der als n¨achstes zu untersuchende Knoten Min jeweils aus einer Menge B von noch zu bearbeitenden Knoten geholt, wobei B denjenigen Knoten im Graph entspricht, die von den bislang besuchten Knoten direkt erreicht werden k¨ onnen. Von diesem Knoten Min aus werden dann alle Nachbarknoten untersucht. Als Vorg¨ angerknoten des Nachbarn wird im Fall, dass noch kein Vorg¨anger existiert, Min in Vorg¨ anger und die Wegl¨ ange u ¨ber Min zum Startknoten in Distanz eingetragen. Existiert ein Vorg¨ angerknoten, dann ersetzt Min diesen, falls der Weg zum Startknoten u urzer ist als der f¨ ur diesen ¨ ber Min k¨ Nachbarn gespeicherte Weg. Wie man in Abb. 4.10 in Zeile 2 sehen kann, berechnen sich im Beispielgraph die gesch¨ atzten Wegl¨ angen f¨ ur die Nachbarknoten des Startknotens 1 beispielsweise zu U ntergrenze(2) = 0 + 4 + 5 = 9 U ntergrenze(3) = 0 + 4 + 4 + 3 = 11 U ntergrenze(4) = 0 + 3 + 8 = 11

152

4. Grundlagen der betrieblichen Optimierung

Der vielversprechendste Knoten ist somit Knoten 2, weswegen dieser als n¨achstes aus der Menge B geholt wird, um dessen Nachbarn zu untersuchen. Die Wegsuche ist beendet, falls der Zielknoten aus der Menge B entfernt wird. Im Beispiel ist dies bereits nach drei Schritten mit Erreichen des Knotens 5 der Fall. Der k¨ urzeste Weg kann dann mit Hilfe des Feldes Vorg¨anger (1-2-5) ermittelt und seine L¨ ange in Distanz (Distanz(5) = 9) abgelesen werden. Der Dijkstra-Algorithmus zur Bestimmung k¨ urzester Wege in einem Graphen basiert ebenfalls auf dieser Vorgehensweise. Heuristische Er¨ oﬀnungsverfahren Die Aufgabe von Er¨ oﬀnungsverfahren liegt in der Bestimmung g¨ ultiger Auftragsreihenfolgen, die allerdings noch nicht optimal sein m¨ ussen, da die eigentliche Optimierung durch ein anschließendes Verbesserungsverfahren erfolgt. Die nachfolgend beschriebenen Verfahren beziehen sich auf die L¨osung eines TSP mit n Orten und einem Startpunkt, wie es beispielsweise bei der Berechnung von Kommissionierreihenfolgen auftritt. Die Grundidee der Savings-Heuristik liegt darin, zun¨achst alle Orte einzeln direkt vom Startpunkt (0) aus anzufahren. Eine solche aus Pendeltouren (0 → j → 0) bestehende L¨ osung ist oﬀenbar ung¨ unstig, da der zur¨ uckzulegende Gesamtweg aus der Summe der Einzeldistanzen d0j (Distanz zwischen 0 und dem Ort j) mit (4.6) 2 · nj=1 d0j sehr ineﬃzient berechnet w¨ are. W¨ ahlt man eine Tour hingegen so, dass jeweils zwei Orte i und j in einem Zyklus besucht werden, kann die Wegeinsparung sij mit sij = d0i + d0j − dij

(4.7)

erzielt werden. Diese Savings“ werden dann unter Beachtung eventueller Re” striktionen f¨ ur alle Paare von Orten errechnet, f¨ ur die eine gemeinsame Tour zul¨ assig ist. Der Savings-Algorithmus kann unter Verwendung einer Entfernungsmatrix D = dij , 1 ≤ i, j ≤ n wie folgt formuliert werden [87]: 1. Bestimmung einer Ausgangsl¨ osung, alle Pendeltouren (0 → j → 0) f¨ ur j = 1, . . . , n. 2. Bestimmung aller Savings gem¨ aß Gl. 4.7, die unter Ber¨ ucksichtigung der Restriktionen entstehen k¨ onnen. Sortierung der berechneten Savings sij nach abnehmenden Werten in einer Liste. 3. Suche nach einer Kante dij , f¨ ur die sij maximal ist. Verbindung der Orte i und j, falls gilt: • Die Orte liegen nicht auf derselben Route. • Keiner der Ort i und j ist innerer Punkt einer Route. • Keine Nebenbedingung (Kapazit¨ at, Zeit, Fahrstrecke etc.) wird verletzt.

4.3 Verfahren der L¨ osungsoptimierung

153

Streichung von sij , weiter mit Schritt 4. ¨ 4. Uberpr¨ ufung, ob noch Zusammenlegungen von Touren m¨oglich sind. Falls ja, weiter mit Schritt 3, sonst Schritt 5. 5. Ende Weitere Er¨ oﬀnungsverfahren sind Bester Nachfolger“, das Sweep-Ver” fahren [86] und im Speziellen f¨ ur die Planung von Kommissionierauftr¨agen die im Absatz 4.2.2 aufgef¨ uhrten Verfahren. Deterministische r-opt-Verbesserungsverfahren Die r-optimalen Verfahren gehen von einer durch ein Er¨oﬀnungsverfahren ermittelten, zul¨ assigen L¨ osung aus und zielen auf eine Verbesserung der L¨ osungsg¨ ute durch Vertauschen einer Anzahl r in einem g¨ ultigen Reihenfolgegraphen beﬁndlichen Kanten ab. Beim 2-opt-Verfahren werden die Tauschm¨oglichkeiten von jeweils zwei Kanten gepr¨ uft. Falls sich durch eine Vertauschung eine verbesserte L¨osung ergibt, wird diese u ¨bernommen. Der Algorithmus f¨ ur das 2-opt-Verfahren zur Bestimmung der k¨ urzesten Tour in einem TSP ist hier als Metacode beschrieben. Gegeben sind die n Orte s1 bis sn und die Entfernungsmatrix C, in der alle Entfernungen zwischen je zwei Orten si und sj als Wegdistanz cij hinterlegt sind, sowie eine zul¨assige Anfangstour r = [t1 , t2 , . . . , tn ] mit tn+1 = t1 . Der Algorithmus wird beendet, falls bei einem Iterationsschritt keine Verbesserung zum vorhergehenden Schritt erzielt werden kann. ITERATION μ (1,2,...) For i := 1 to (n-2) do begin For j : = i + 2 to n do begin berechne cti tj + cti+1 tj+1 − ct1 ti+1 + ctj tj+1 Falls < 0 bilde eine neue Tour [t1 , . . . , tn] mit vertauschten ti und tj Weiter mit ITERATION μ + 1 end end Am Beispiel der Bildung einer Kommissionierreihenfolge mit der Streifenstrategie als Anfangsl¨ osung wird durch Vertauschen von jeweils r Kanten zwischen den Knoten im zugrunde liegenden Graphen iterativ eine Verk¨ urzung der Tour eingestellt. Beim 2-opt-Kantentausch kann die L¨ange einer Tour durch paarweises Vertauschen der Reihenfolge von je zwei Knoten (und damit der verbindenden Kanten) beeinﬂusst werden. In Abb. 4.11 ist das Tauschen der Kanten 3-4 und 6-7 auf die Kanten 3-7 und 6-4 mit der sich ¨andernden Tourl¨ ange gezeigt.

154

4. Grundlagen der betrieblichen Optimierung A n fa n g s lö s u n g (S tr e ife n ) 9 8

n a c h K a n te n ta u s c h 9

7

7

6

8

5

4 2

6

3

1

5

4 2

3

1

Ü b e rg a b e p u n k t

Abbildung 4.11. Kantentauschverfahren

Genetische Algorithmen Genetische Algorithmen (engl. genetic algorithms, GA) geh¨oren zur Gruppe der naturanalogen Verfahren, die Mechanismen nat¨ urlicher Systeme in technisch-¨ okonomischen Anwendungen adaptieren (vgl. [19]). Die Idee zur Entwicklung und Anwendung genetischer Algorithmen in technischen Optimierungsproblemen ist aus der Anschauung heraus entstanden, die evolution¨ are Entwicklung der Natur nachzubilden, welche ihrerseits ebenfalls einem Optimierungsprinzip, dem Survival of the Fittest“ folgt14 . ” Der Ablauf genetischer Algorithmen besteht darin, aus einer Menge von Anfangsl¨ osungen innerhalb der Population durch eine Rekombination, d. h. neue Zusammensetzung bereits existierender L¨osungen, bessere (und auch schlechtere) L¨ osungen zu generieren. Die schlechteren L¨osungen werden aus der L¨ osungsmenge ausgeschieden und durch die besseren ersetzt, bis u ¨ ber mehrere Iterationsstufen letztlich keine signiﬁkanten Verbesserungen mehr erzielt werden. Damit die GA im Verlauf der Rekombination keine identischen L¨ osungen produzieren, wird die Methode der Mutation genutzt, d.h. dass bei einer rekombinierten L¨ osung zuf¨ allig eine Ver¨anderung erzeugt wird. Die folgenden Schritte beschreiben den grundlegenden Ablauf eines GA; gegeben sei die Problemgr¨ oße durch die Anzahl n Elemente, f¨ ur die eine optimale Reihenfolge bestimmt werden soll: 1. Bildung einer Grundpopulation aus μ Elementen (Initialisierung, μ n!) 2. Deﬁnition eines Abbruchkriteriums f¨ ur den nachfolgenden Schleifendurchlauf 14

Survival of the Fittest“ ist nach der evolution¨ aren Theorie als Ergebnis von ” Selektion, Vererbung und naturbedingten Zufallsmechanismen, den Mutationen, anzusehen, welche individuelle Ver¨ anderungen an Auspr¨ agungen biologischer Organismen hervorrufen.

4.3 Verfahren der L¨ osungsoptimierung

155

3. Bewertung der Individuen mit der Zielfunktion f (Bewertung der Fitness, z. B. anhand der Wegl¨ ange) 4. Auswahl von Individuen aus dieser Population (Selektion anhand der Fitness) 5. Bildung von Nachkommen (Rekombination) 6. Modiﬁkation der Nachkommeneigenschaften (Mutation) 7. Wiederholung ab Schritt 3, bis Abbruchkriterium erf¨ ullt ist Reihenfolgeprobleme werden als GA derart codiert, dass die zu reihenden Auftr¨ age jeweils einem Gen innerhalb eines Genstranges, dem Genom bzw. Chromosom, entsprechen. Jeder Auftrag kann somit eine beliebige Stelle innerhalb des Chromosoms besetzen; die Reihenfolge der Bearbeitung eines Auftrags entspricht dann der Position innerhalb des Chromosoms. Bei der Initialisierung wird durch einen Zufallsgenerator eine Grundpopulation aus μ unterschiedlichen Chromosomen gebildet. Die Fitness dieser Chromosomen entspricht bei Reihenfolgeproblemen der durch eine Bewertungsfunktion ermittelten Tourl¨ ange (bspw. Kommissionierrundgang15). Im Zuge der Selektion werden die Elternchromosomen f¨ ur eine anschließende Rekombination anhand ihrer Fitness ausgew¨ahlt. Eine einfach durchzuf¨ uhrende Auswahl erfolgt anhand der relativen H¨auﬁgkeit der Fitness. Hierbei k¨ onnen allerdings Dominanzeﬀekte auftreten. Bestimmte Chromosomenauspr¨ agungen w¨ urden nach dieser Vorgehensweise u ¨ berproportional oft selektiert, der GA optimiert dann nur auf ein lokales Optimum hin. Dieser Eﬀekt kann jedoch durch eine Normalisierung der Fitnesswerte verhindert werden. Nach der Selektion von jeweils zwei Eltern werden deren Gene durch Rekombinationsoperatoren an die Nachkommen vererbt. Ein f¨ ur Reihenfolgeprobleme einfach zu implementierender Operator ist, neben zahlreichen problemspeziﬁschen Operatoren, das uniform order-based crossover, bei dem ein zuf¨ alliger Bitstring in der L¨ ange der Chromosomen bestimmt, welche Gene auf welche Nachkommen verteilt werden (Abb. 4.12). Die im Bitstring mit einer 1 gekennzeichneten Stellen u ¨bertragen die Gene von Elternteil 1 auf den ersten Nachkommen, umgekehrt werden die anderen, mit 0 gekennzeichneten Gene von Elternteil 2 auf den zweiten Nachkommen u ubernahme noch zu besetzenden ¨bertragen. Die nach der Positions¨ Leerstellen in den Chromosomen der Nachkommen werden in der Reihenfolge ihres Auftretens im korrespondierenden Elterngenom mit den Genen der Eltern aufgef¨ ullt. Auf diese Weise ist außerdem sichergestellt, dass nur g¨ ultige Gensequenzen f¨ ur die Nachkommen erzeugt werden (keine Verdoppelung von Genen). Durch Mutation k¨ onnen einzelne Chromosome innerhalb der Population zielgerichtet modiﬁziert werden, um ebenfalls eine Einschr¨ankung des L¨ osungsraumes und damit eine nur lokale Optimierung zu vermeiden. Bei 15

Zu ber¨ ucksichtigen ist, dass die Fitness problemspeziﬁsch, d.h. abh¨ angig von der zugrundeliegenden Zielfunktion, maximiert oder minimiert wird.

156

4. Grundlagen der betrieblichen Optimierung

Elternteil 1

1

4

2

6

5

3

Elternteil 2

3

4

5

1

2

6

Bitstring

0

1

1

1

0

1 T e il- S tr in g

-

4

2

6

-

3

3 -

-

-

2

-

Kind 1

5 4

2

6

1

3

Kind 2

3 1

4

6

5

3

Positionsübernahme

Abbildung 4.12. Rekombinationsoperator uniform order-based crossover

1

4

2

6

5

3

In v e r s io n

1

4

5

6

2

3

S c r a m b le d S u b lis t

1

4

5

2

6

3

Abbildung 4.13. Anwendung von Mutationsoperatoren

den in Abb. 4.13 gezeigten Mutationsoperatoren werden Teilbereiche eines Chromosoms entweder durch Spiegeln der Genreihenfolge (Inversion) oder durch zuf¨ allige Neuanordnung (Scrambled Sublist) angeordnet. Auf welche Weise die verschiedenen Operatoren zur Reproduktion angewendet werden, h¨ angt vom Reproduktionsmodell der Population bzw. des GA ab. Darin wird u. a. die Anzahl und Wahrscheinlichkeit pcross der zu selektierenden und zu rekombinierenden Elternpaare und ihrer Nachfolger sowie die Generationsanzahl und die in einer Generation ablaufenden Mutations- und gegebenenfalls Klonvorg¨ ange mit ihren jeweiligen Auftrittswahrscheinlichkeiten festgelegt. Gleichzeitig klassiﬁziert das Reproduktionsmodell den Berechnungsaufwand und ist damit ein Gradmesser f¨ ur das Laufzeitverhalten. Allgemein kann der Berechnungsaufwand f¨ ur den eingangs beschriebenen GA danach als polynomial abgesch¨ atzt werden. Im Gegensatz zu den bereits beschriebenen klassischen Optimierungsverfahren basiert eine Optimierung durch genetische Algorithmen damit nicht auf der schrittweisen Verbesserung nur einer L¨osung, sondern wird durch mehrere L¨ osungsinstanzen gebildet, die gleichzeitig unterschiedliche Stellen des Suchraums belegen. Auf diese Weise sind genetische Verfahren robuster gegen¨ uber Schwankungen der problembestimmenden Eingangsgr¨oßen und k¨ onnen ebenfalls verhindern, dass L¨ osungen in nur einem lokal begrenzten Bereich (lokales Optimum) generiert werden. F¨ ur ein weiterf¨ uhrendes Studium genetischer Algorithmen sei hier auf [21, 28] verwiesen.

5. Informations- und Kommunikationstechnik

In diesem Kapitel werden die Grundlagen der Informations- und Kommuni¨ kationstechnik in Form eines Uberblicks dargelegt. Ziel dieses Kapitels ist die Vermittlung von allgemeinen Prinzipien und deren praktische Umsetzung – soweit sie f¨ ur Entscheidungen bez¨ uglich der Auswahl, der Beschaﬀung und des Betriebs von WMS relevant sind. Aufgrund des schnellen Wandels in der Informations- und Kommunikationstechnik beschr¨ankt sich dieses Kapitel auf die Grundlagen, w¨ ahrend konkrete Verfahren anhand ausgew¨ahlter Beispiele erl¨ autert werden.

5.1 Kommunikationstechnik Die moderne Kommunikationstechnik bildet den Schl¨ ussel zum schnellen, fehlerfreien Datenaustausch und zu zahlreichen Diensten, die in o¨ﬀentlichen Netzen weltweit angeboten werden ([54], [55]). Die elektronische Kommunikationstechnik begann mit der auf Morsezeichen basierenden Telegraphie und entwickelte sich u ¨ ber das Telefon, Telefax und das Fernsehen bis hin zu den ¨ digitalen Techniken der heutigen Zeit. Die Ubertragungstechnik hat sich von den Anf¨ angen bis heute ebenfalls stark gewandelt. Fr¨ uher waren ausschließlich drahtgebundene Punkt-zu-Punkt-Verbindungen ohne jegliche Vermittlungstechnik m¨ oglich. Diese entwickelte sich u ¨ber W¨ahlverbindungen1 , Paket2 3 vermittlung und Breitbandtechnologie weiter. Dazu kamen die M¨oglichkeit der Mehrfachnutzung der Medien durch die Multiplextechnik, die optische ¨ Ubertragungstechnik und die Satellitentechnik. Heute wird eine Vielzahl von ¨ Diensten u angeboten. ¨ ber unterschiedlichste Ubertragungsmedien Die folgenden Abschnitte dienen dazu, die Vielzahl der Begriﬀe und Abk¨ urzungen rund um das Thema Kommunikationstechnik einzuordnen. 1 2

3

Die Vermittlungstechnik der W¨ ahlverbindungen, bei denen f¨ ur die Dauer einer Verbindung eine Leitung geschaltet wird, wird Leitungsvermittlung genannt. Die zu u ¨ bertragenden Daten werden zu kleinen Einheiten, den Paketen, zusammengefasst und jedes Paket wird individuell durch das Netz transportiert, statt die gesamten Daten u ¨ ber eine fest zugeordnete Leitung zu u ¨ bertragen. ¨ Mehrere Daten¨ ubertragungen nutzen gleichzeitig innerhalb eines Ubertragungskanals das gleiche Frequenzband.

158

5. Informations- und Kommunikationstechnik Schicht n+1

Funktionen

Daten

Modul der Schicht n

Funktionen

Schicht n

Daten

Schicht n-1

Abbildung 5.1. Grundlegendes Prinzip einer Schicht in einem Softwaresystem

5.1.1 Schichtenmodelle Schichtenmodelle stellen ein Prinzip der Strukturierung von Software dar. In der Kommunikationstechnik wird dieses Prinzip besonders erfolgreich eingesetzt. Eine Schicht (Layer ) stellt – unter Nutzung der Dienste der untergeordneten Schicht – Dienste f¨ ur die u ¨bergeordnete Schicht bereit (s. Abb. 5.1). In diesem und in den folgenden Abschnitten wird das in der Kommunikationstechnik weit verbreitete und anerkannte ISO/OSI-Referenzmodell (s. Abb. 5.2) zugrunde gelegt. Mit Hilfe des ISO/OSI-Modells l¨asst sich die Kommunikation u ¨ber elektronische Medien durch sieben Schichten darstellen, die, hierarchisch aufgebaut, den Informationsﬂuss vom physischen Medium bis zur Applikation (zum Beispiel ein WMS) beschreiben. Applikationen stehen u ¨ ber ¨ die Schichtenfolge 6 → 5 → 4 → 3 → 2 → 1 → Ubertragungsmedium →1→2 → 3 → 4 → 5 → 6 miteinander in Verbindung. Da auf der Empfangsseite die Schichten in umgekehrter Reihenfolge durchlaufen werden, spricht man auch von einem Protokollstack. Tabelle 5.1 beschreibt die Aufgaben der einzelnen Schichten. Die Schichten 1 bis 4 bezeichnet man auch als transportorientierte Schichten und die Schichten 5 bis 7 als applikationsorientierte Schichten. Detailliertere Beschreibungen sind beispielsweise in [55] zu ﬁnden. 5.1.2 Protokolle Protokolle implementieren die Funktionen einer Schicht. Jede einzelne Schicht empf¨ angt von der ihr u ¨bergeordneten Schicht die zu u ¨bertragenden Nutzdaten. Diese werden zusammen mit einem Kopf (Header ), der Informationen

5.1 Kommunikationstechnik Applikation1

Anwendungsschicht

Anwendungsprotokoll

6

Darstellungsschicht

Darstellungsprotokoll

5

Kommunikationssteuerungsschicht

Sitzungssprotokoll

4

Transportschicht

Transportprotokoll

3

Vermittlungsschicht

2

Sicherungsschicht

1

Bitübertragungsschicht

Applikation2

Daten

7

Vermittlungsprotokoll

Application Layer

AH Daten

Presentation Layer

PH Daten SH TH NH DH

Session Layer

Daten

Transport Layer

Daten

Network Layer

Daten Daten Bits

159

DT

Data Link Layer Physical Layer

Abbildung 5.2. Das ISO/OSI-Referenzmodell. Auf der linken Seite des Protokollstacks sind die Schichten mit den deutschen, auf der rechten Seite mit den englischen Begriﬀen beschriftet.

u alt, als Frame oder Paket 4 wei¨ber die zu u ¨ bertragenden Nutzdaten enth¨ tergeleitet. Anhand der Headerinformationen werden die zu u ¨ bertragenden Daten einschließlich des Headers durch das Protokoll bearbeitet und, mit einem zus¨ atzlichen Header versehen, an die n¨ achsttiefere Schicht u ¨bergeben. Bei diesem Vorgang k¨ onnen große Pakete in mehrere kleine zerlegt oder zu gr¨ oßeren Paketen zusammengefasst werden. Auf der Empfangsseite werden die von den einzelnen Schichten erzeugten Header wieder von den Nutzdaten getrennt, so dass schließlich der Applikation auf der Empfangsseite nur die Daten geliefert werden, welche die Applikation auf der Sendeseite gesendet hat. Empfangene Pakete werden meist durch Quittungspakete best¨atigt oder ¨ verworfen. Protokolle k¨ onnen Ubertragungsfehler durch Pr¨ ufsummenberechnung und -auswertung erkennen und bei der aufrufenden Schicht eine Wiederholung des entsprechenden Paketes anfordern. F¨ ur eine detailliertere Beschreibung allgemeiner Protokollprinzipien siehe beispielsweise [20, 55]. Typische Protokolle, die im Internet angewendet werden, sind in Abb. 5.3 dargestellt: • Internetprotokolle ¨ – FTP (File Transfer Protocol) zur sicheren Ubertragung von Dateien – TELNET (Remote Terminal Program) zur zeichenbasierten Kommunikation mit System- und Anwendungsprogrammen ¨ – SMTP (Simple Mail Transfer Protocol) zur Ubertragung von E-Mail – NSP (Name Server Protocol) zur Namensauﬂ¨osung im Internet 4

Frame und Rahmen sowie Packet (engl.) und Paket werden synonym verwendet. Sie enthalten immer einen Header und die Nutzdaten. Der Begriﬀ Frame“ wird ” meist f¨ ur die Schichten 1 und 2 verwendet.

160

5. Informations- und Kommunikationstechnik

Tabelle 5.1. Schichten des ISO/OSI-Referenzmodells und ihre Bedeutung Nr.

Schicht

Aufgaben

7

Applikation

Anwendungsprogramm, das unter Nutzung des Protokollstacks mit einer oder mehreren anderen Anwendungen kommuniziert

6

Präsentation

Vereinheitlichung einer applikationsunabhängigen Darstellung von Datentypen im Netzwerk. Beispielsweise werden ganze Zahlen netzwerkseitig immer in einer bestimmten Reihenfolge dargestellt, während die applikationsseitige Darstellung von der Hardware des Rechners abhängt.

5

Sitzung

Für die Dauer der Laufzeit einer Applikation werden hier Zustandsdaten gehalten. Insbesondere für Fehlerfälle werden so genannte Synchronisationspunkte verwaltet.

4

Transport

Die Sendedaten werden in Pakete zerlegt. Die Reihenfolge empfangener Pakete wird sichergestellt.

3

Vermittlung

Die Pakete, die nicht für diesen Rechner bestimmt sind, werden an einen Nachbarrechner weitergeleitet. Diese Vermittlung kann über mehrere Rechner erfolgen. Die Wegefindung nennt man Routing. Die Rechner, welche diese Schicht nur als Vermittlungsknoten zwischen benachbarten Rechnern realisieren und die empfangenen Pakete nicht an höhere Protokollschichten weiterleiten, nennt man Router (s. Abb. 5.10).

2

Sicherung

Sicherung der korrekten Übertragung der Daten. Die Korrektheit wird zwar auch in den höheren Schichten überprüft. Dieser Schicht kommt aber eine besondere Bedeutung zu, da sie die erste Schicht ist, die direkte Verbindung zur Hardware hat und hier – je nach eingesetztem Übertragungsmedium und dem Zugriffsverfahren sowie der aktuellen Störsituation – eine große Fehlerhäufigkeit zu erwarten ist. Die kleinste Einheit der zu übertragenden Daten nennt man hier Frame. Diese Schicht wird in zwei Subschichten aufgeteilt. Die MAC-Schicht (MAC: Medium Access Control) regelt den Zugriff auf das Medium. Beispielsweise werden hier Kollisionen in Bussystemen behandelt. Die LLC-Schicht (LLC: Logical Link Control) ist für die sichere Übertragung der Daten zuständig. Die Frames werden um Prüfsummen erweitert. Quittungsframes bestätigen den korrekten Empfang von Frames.

1

Bitübertragung

Spezifikation von physikalischen Anforderungen wie beispielsweise von Kabeln, Steckern und Spannungspegeln

– SNMP (Simple Network Management Protocol) zur Verwaltung von Netzwerken • Transportprotokolle – TCP (Transmission Control Protocol) zur verbindungsorientierten Kommunikation. Ein Client-Prozess (s. Abschn. 5.1.6) baut zu einem ServerProzess eine Verbindung auf, die dann in beiden Richtungen zur Kommunikation genutzt werden kann, bis einer der beiden Teilnehmer diese Verbindung beendet. – UDP (User Datagram Protocol) arbeitet im Gegensatz zum TCP verbindungslos. Jedes Datenpaket wird getrennt vom Sender zum Empf¨anger geschickt. UDP garantiert nicht, dass die Pakete auch tats¨achlich ihr Ziel erreichen. • IP (Internet Protocol) als Beispiel f¨ ur ein Vermittlungsprotokoll; h¨auﬁg in Verbindung mit dem TCP-Transportprotokoll eingesetzt (→TCP/IP )

5.1 Kommunikationstechnik

161

Nutzer

Applikation1

Applikation2

Applikationn

File Transfer Protocol (FTP) Remote Terminal Protocol (TELNET) Simple Mail Transfer Protocol (SMTP) Name Server Protocol (NSP) Simple Network Management Protocol (SNMP)

TCP

UDP

Schicht 5 bis 7

Schicht 4

IP

Schicht 3

IEEE 802.x

Schicht 2

Physikalisches Medium

Schicht 1

Abbildung 5.3. Typische Protokolle, die im Internet angewendet werden (nach [55])

• Sicherungsprotokolle nach IEEE802.x – IEEE802.3 Ethernet als Beispiel f¨ ur eine Busstruktur – IEEE802.4 Tokenbus als logische Ringstruktur auf einem physischen Bus – IEEE802.5 Tokenring als Beispiel f¨ ur eine ringbasierte Netzstruktur – IEEE802.6 optisches Doppelbussystem f¨ ur den Einsatz in MANs – IEEE802.11 Einsatz in drahtlosen LANs ¨ 5.1.3 Ubertragungsmedien ¨ Die Ubertragungsmedien stellen die unterste Schicht eines Kommunikationssystems dar. Trotz ihres analogen physikalischen Funktionsprinzips werden

162

5. Informations- und Kommunikationstechnik

Nachrichtenquelle 1

Quellencoder 1

Nachrichtenquelle 2

Quellencoder 2

...

...

...

...

Nachrichtenquelle n

Quellencoder n

MUX

Modulator

Störungen

Nachrichtensenke 1

Quellencoder 1

Nachrichtensenke 2

Quellencoder 2

...

...

...

...

Nachrichtensenke n

Quellencoder n

Kanalencoder

DEMUX

Übertragungskanal

Demodulator

Kanaldecoder

¨ Abbildung 5.4. Quellcodierung und Mehrfachzugriﬀ auf das Ubertragungsmedium

¨ sie f¨ ur die Ubertragung digitaler Signale – das sind Signale mit einem endlich abz¨ ahlbaren Symbolvorrat – genutzt. Auf den h¨oheren Schichten werden ausschließlich digitale Signale mit zwei Zust¨anden – bin¨are Signale – verwendet. Ein elektrisches Kabel kann beispielsweise mit unterschiedlichen Spannungswerten beaufschlagt werden. Je dichter die m¨oglichen Spannungswerte gestaﬀelt werden, um so kritischer ist unter realen Verh¨altnissen die Zuordnung eines konkreten Wertes zu einem Symbol. Reale Verh¨altnisse beinhalten immer Schwankungen der Spannungswerte durch Eigenschaften des ¨ Ubertragungsmediums und durch externe St¨ oreinﬂ¨ usse. Aus diesem Grund ist die zu einem Zeitpunkt zu u ¨bertragende Informationsmenge von den St¨ oreinﬂ¨ ussen und von der G¨ ute des Mediums abh¨angig. Viele Modems5 , die zur Daten¨ ubertragung u ¨ber Telefonleitungen eingesetzt werden, passen ¨ sich daher selbstst¨ andig der aktuellen G¨ ute des Ubertragungskanals an.

5

Ein Modem beinhaltet die Baugruppen Modulator und Demodulator.

5.1 Kommunikationstechnik

163

¨ Die Ubertragung von Spannungswerten ist nur eine Art der Aufpr¨agung ¨ der Information auf ein Medium. Alternativen sind beispielsweise die Uber6 tragung von T¨ onen, Ton¨ anderungen, aber auch kombinierte Verfahren . Lichtwellenleiter (LWL, auch: Glasfaser) erlauben eine weitgehend st¨o¨ rungsfreie Ubertragung der Signale. Mit ihnen lassen sich große Bandbreiten ¨ und eine gegen elektromagnetische Felder unempﬁndliche Ubertragung realisieren. Lichtwellenleiter ﬁnden in allen Bereichen der industriellen Netzwerktechnik zunehmend Verwendung. Abbildung 5.4 zeigt schematisch den grunds¨atzlichen Aufbau einer Daten¨ ubertragung von den Datenquellen bis zu den Datensenken. Der Quellencoder hat die Aufgabe, den Datenstrom zu verdichten. Die Verfahren sind abh¨ angig von der Art der Datenquelle. Digitale Bild- und Audiodaten werden mit anderen Verfahren codiert als beispielsweise Textdateien. Zur bes¨ seren Nutzung des Ubertragungskanals k¨ onnen sich mehrere Datenstr¨ome ¨ ein Ubertragungsmedium teilen. Diese Technik nennt man Multiplexing, die Ger¨ ate Multiplexer/Demultiplexer (MUX/DEMUX). Der Kanalencoder ¨ passt die so geb¨ undelten Signale den Eigenschaften des Ubertragungskanals optimal an [27]. Adaptive Verfahren arbeiten dynamisch und ber¨ ucksichtigen dabei auch die aktuelle St¨ orsituation. Bei einem Anstieg der St¨orungen, ¨ ¨ die auf den Ubertragungskanal wirken, wird die Ubertragungsgeschwindigkeit reduziert. Der Modulator setzt schließlich die Signale in eine physische Gr¨ oße (elektrisch/optisch) um, die dann durch den Kanal zum Empfangsort u ange in umgekehrter Reihenfolge ab. ¨bertragen wird. Hier laufen alle Vorg¨ Das dargestellte Grundprinzip zeigt nicht die M¨oglichkeit der bidirektionalen Nutzung des Kanals. Das Schema beschr¨ ankt sich auch auf die Darstellung von Punkt-zu-Punkt-Verbindungen: Jeder Datenquelle ist genau eine Datensenke zugeordnet. Abschnitt 5.1.4 zeigt weitere m¨ogliche Netzstrukturen und Vermittlungstechnik. Eine wichtige Kenngr¨ oße ist die Geschwindigkeit, mit der die Zeichen u ¨bertragen werden. Die Anzahl der Zeichenwechsel pro Sekunde wird mit der Einheit Baud bezeichnet und durch die Eigenschaften des Mediums (Band¨ breite) beschr¨ ankt. F¨ ur den Anwender ist die Ubertragungsrate in Bit pro ¨ Sekunde wichtiger, da diese Kennzahl sich direkt auf die erforderliche Ubertragungszeit f¨ ur ein gegebenes Datenvolumen auswirkt. angeren Kabeln der zeitliche Verlauf der Signale verschleift und Da bei l¨ die Signalst¨ arken abnehmen, setzt man in diesen F¨allen Repeater (s. Abschn. 5.1.4) ein, um die Form der Signale zu restaurieren und zu verst¨arken. ¨ Außer den hier angesprochenen elektrischen Ubertragungsmedien werden auch optische Medien eingesetzt, die unabh¨ angig von externen elektromagnetischen Feldern sind und selbst keine derartigen Felder abstrahlen. Man spricht von einer hohen elektromagnetischen Vertr¨aglichkeit (EMV ). Damit k¨ onnen sie auch problemlos zusammen mit anderen Kabeln verlegt werden. 6

Die entsprechenden Verfahren der Nachrichtentechnik (Amplituden-, Frequenz-, Phasen- und Quadraturmodulation) werden beispielsweise in [27] beschrieben.

164

5. Informations- und Kommunikationstechnik

Busstruktur

Ring

Doppelbus

Doppelring

Stern

Gitter

Vollständiges Netz

Abbildung 5.5. Typische Netzwerktopologien

Eine besondere Stellung nehmen die Funk¨ ubertragungsverfahren ein. Insbesondere Abschattungen, starke Schwankungen der Signale am Empfangsort und Mehrfachempfang durch Reﬂexionen erschweren technische Realisierungen. Insbesondere innerhalb eines Lagers mit zahlreichen Stahlelementen erfordert der Einsatz der Funk¨ ubertragungstechnik eine sorgf¨altige Planung und Inbetriebnahme. Ausf¨ uhrliche Funkmessungen und ggf. der daraus resultierende Einsatz zus¨ atzlicher Sender und Antennen zur ﬂ¨achendeckenden Ausleuchtung des gesamten Einsatzbereiches sind h¨auﬁg notwendig. 5.1.4 Netztypen und Internetworking Netze k¨ onnen nach ihrer Struktur als Bus, Ring, Doppelring, Stern, Gitter oder als vollst¨ andig klassiﬁziert werden (s. Abb. 5.5). Mit Ausnahme der Busstruktur basieren die Topologien auf Punkt-zu-Punkt-Verbindungen. Die Bussysteme erschweren die Kommunikation zwischen den angeschlossenen Teilnehmern, da zu einer Zeit immer nur ein Teilnehmer senden kann. Eine ¨ ahnliche Problematik tritt bei den funk- und infrarotbasierten Systemen auf. Auch hier teilen sich mehrere Teilnehmer ein Medium. Aufgrund der Mobilit¨ at der Teilnehmer und der beschr¨ ankten Reichweiten ergibt sich das

5.1 Kommunikationstechnik

165

Problem der Lokalisierung und der Bedarf nach hochdynamischen Vermittlungsverfahren, auf die hier nicht eingegangen wird (s. z. B. [55]). Vom Feldbus bis zum Weitverkehrsnetz Netzwerke ﬁnden in allen industriellen Bereichen Anwendung. Ein Kriterium zur Klassiﬁzierung der ¨ Netzwerktypen ist die L¨ ange des Ubertragungsweges zwischen zwei Kom7 munikationspartnern . Mit der Entfernung steigen die Fehlerh¨auﬁgkeit und die Latenzzeit8 . Die Betrachtung der typischen Entfernungen zwischen den einzelnen Knotenrechnern f¨ uhrt zu den folgenden Einteilungen: • Feldbussysteme dienen den Ger¨ aten der Automatisierungstechnik zum schnellen Austausch von Signalen und Messwerten zwischen Sensoren und Steuerungen sowie zwischen Steuerungen und Aktoren. Die Forderung nach einer kurzen Verz¨ ogerungszeit (Latenzzeit ) kann von einer sehr niedrigen bis zu einer garantierten maximalen Latenzzeit reichen. Das Echtzeitverhalten9 des Gesamtsystems muss auch bei den relativ langsamen Prozessen der F¨ ordertechnik sichergestellt werden. • Local Area Networks (LANs) werden meist innerhalb von Geb¨auden eingesetzt und erm¨ oglichen bei geringer Latenzzeit einen großen Durchsatz. • Metropolitan Area Networks (MANs) haben ihren typischen Einsatz bei mittleren“ Entfernungen. ” ¨ • Wide Area Networks (WANs) dienen der Uberbr¨ uckung von großen Entfernungen – z. B. zwischen St¨ adten, L¨ andern oder Kontinenten. Abbildung 5.6 zeigt eine qualitative Einordnung dieser Netzklassen. Aus diesen Netzen mit ihren jeweiligen charakteristischen Eigenschaften k¨onnen große Netzwerke – so genannte Internetzwerke [55] – aufgebaut werden. Ein typisches Beispiel hierzu ist das Internet, dessen Hauptverbindungsstrecken, die große Datenmengen u ¨ ber weite Distanzen u ¨ bertragen, als Backbone bezeichnet werden (s. Abb. 5.7). Internetworking In einer heterogenen Kommunikationswelt m¨ ussen große Entfernungen u uckt und unterschiedliche Netzwerke miteinander ver¨berbr¨ bunden werden. Die Wegsuche durch solche Netzwerke erfordert ebenfalls entsprechende Vermittlungseinrichtungen, die netz¨ ubergreifend arbeiten. Auf den verschiedenen Ebenen des Schichtenmodells k¨onnen Teilnetze miteinander verbunden werden.

7 8 9

Das gilt auch f¨ ur den Weg zwischen jeweils zwei Knotenrechnern, u ¨ ber welche die Datenpakete zum Zielrechner vermittelt werden. Unter Latenzzeit versteht man die Verz¨ ogerungszeit zwischen einem Ereignis und dem Eintreten einer Reaktion. Echtzeitf¨ ahigkeit ist eine Systemeigenschaft, die innerhalb einer Zeitschranke T die Reaktion eines Systems auf ein Ereignis garantiert.

166

5. Informations- und Kommunikationstechnik

Latenzzeit Fehlerhäufigkeit

WAN MAN LAN

Feldbus

Gebäude

Land

Stadt

Erde

Reichweite

LAN: Local Area Network MAN: Metropolitan Area Network WAN: Wide Area Network

Abbildung 5.6. Grobklassiﬁzierung verschiedener Netzwerke

• Repeater geh¨ oren zur ISO/OSI-Schicht 1 und dienen zur Regenerierung elektrischer Signale. Repeater werden eingesetzt, wenn gr¨oßere Entfernungen zu u ucken sind. ¨berbr¨ • Hubs geh¨ oren ebenfalls zur Schicht 1 und dienen als Sternpunkt im Wesentlichen einer Vereinfachung der Verkabelung. Sie verbinden mehrere Segmente, von denen jedes ein eigenes Bussystem darstellt. Ein Hub kopiert alle ankommenden Frames eines jeden Segmentes auf alle anderen Segmente. Damit hat das gesamte Netz zwar eine sternf¨ormige Topologie, aber das Verhalten eines Bussystems.

LAN

LAN LAN MAN LAN

LAN

WAN

MAN WAN LAN LAN

LAN

MAN

LAN

Abbildung 5.7. Verbindung von LAN, MAN und WAN zu einen Internetzwerk

5.1 Kommunikationstechnik

167

Bridge Repeater

Physikalisches Medium1

Physikalisches Medium2

Abbildung 5.8. Repeater zur Signalregenerierung zwischen Kabelsegmenten

Physikalisches Medium1

Physikalisches Medium2

Abbildung 5.9. Bridge zur Kopplung von Netzen mit unterschiedlichen Sicherungsprotokollen

• Zur Vermeidung von Kollisionen zwischen den Frames unterschiedlicher Segmente setzt man Switches ein. Diese sind ¨ahnlich wie Hubs aufgebaut, kopieren aber die empfangenen Pakete nur auf das Segment, an dem der Empf¨ anger angeschlossen ist (auch als Switching Hubs bezeichnet). • Viele Unternehmen betreiben mehrere LANs und m¨ ussen diese miteinander verbinden. Hier bietet sich eine Bridge an. Im Gegensatz zu einem Router, der auf der Schicht 2 arbeitet, ist der Aufwand wesentlich geringer. Bridges k¨ onnen Netze mit unterschiedlichen Technologien – genauer gesagt mit unterschiedlichen Medienzugriﬀsprotokollen – miteinander verbinden. Dabei werden die Zieladressen der Vermittlungsschicht nicht aufgel¨ost. • Router vermitteln auf der Schicht 3 die Datenpakete u unstige“ Pfade. ¨ ber g¨ ” • Ein Gateway arbeitet auf der Ebene der Applikationen. Dazu m¨ ussen alle tieferen Schichten des Protokollstacks durchlaufen werden. Gateways dienen der Verbindung von unterschiedlichen Applikationen oder von unterschiedlichen unterlagerten Protokollschichten, die erst auf dieser Ebe¨ ne einen Ubergang zwischen verschiedenen Netzen erm¨oglichen. Gateways werden oft zur Kopplung von WMS und ERP-Systemen eingesetzt, um trotz unterschiedlicher Applikationsprotokolle eine Kommunikation zwischen ihnen zu erm¨ oglichen.

5.1.5 Netzwerkadressen Jede Schicht des ISO/OSI-Protokollstacks arbeitet mit eindeutigen Identiﬁkationen, die je nach Schicht als Funktionscode, Sitzungsidentiﬁkation, Dienstidentiﬁkation, Knotenadresse oder Hardwareadresse bezeichnet werden. Die Adressierung wird an einem einfachen Beispiel10 erl¨autert: Auf der Schicht 1 sind die physischen Anschl¨ usse eindeutig identiﬁzierbare und eindeutig benannte Einheiten. Ethernetanschl¨ usse werden typischerweise mit eth0, eth1, usw. bezeichnet. F¨ ur RS232-Anschl¨ usse11 werden oft die 12 Bezeichner com1 und com2 verwendet. 10 11 12

Das Beispiel basiert auf dem TCP/IP-Protokoll und einem Ethernet-Bussystem. RS232 ist eine serielle Spannungsschnittstelle. Unter den Betriebssystemen Unix und Linux werden die seriellen Schnittstellen mit ttyS0 und ttyS1 bezeichnet.

168

5. Informations- und Kommunikationstechnik

Gateway

Router

Physikalisches Medium1

Physikalisches Medium2

Abbildung 5.10. Darstellung eines Routers zur Vermittlung von Datenpaketen zu Zielknoten

Physikalisches Medium1

Physikalisches Medium2

Abbildung 5.11. Gateway zur Kopplung unterschiedlicher Applikationen

Die Adressen der Schicht 2 bezeichnet man als MAC-Adressen. Sie sind in Bussystemen zwingend erforderlich, um die Teilnehmer eindeutig zu identiﬁzieren. Das Ethernet verwendet eine 48-Bit-Adresse, die weltweit eindeutig vergeben wird und vom Hersteller jeweils einer Netzwerkkarte fest zugeordnet wird. Die Adressen der Schicht 3 – der Vermittlungsschicht – sind analog zu Telefonnummern zu sehen. Jeder Teilnehmer ben¨otigt eine eindeutige Identiﬁzierung unabh¨ angig von der Technologie und den Protokollen der Schichten 1 und 2. Abbildung 5.12 zeigt das h¨ auﬁg genutzte IP-Adressschema ipv4 mit einer 32-Bit-Adresse13. Die Adressen werden wegen der besseren Lesbarkeit in vier durch Punkte separierte Zahlen – jeweils im Bereich 0 bis 255 – dargestellt. Die Adressen werden zentral von der IANA (Internet Assigned Numbers Authority) vergeben. Eine Sonderstellung nehmen die Adressen 10.0.0.0 ... 10.255.255.255 172.16.0.0 ... 172.31.255.255 192.168.0.0 ... 192.168.255.255 ein, die nicht zentral verwaltet werden. Sie k¨onnen in Netzen genutzt werden, die keinen Zugang zum Internet haben. Adressen, die mit dem Bitmuster 1110“ beginnen, bezeichnen sog. Multicast-Adressen, die f¨ ur Gruppenkom” munikation – ein Sender, viele Empf¨ anger – reserviert sind (s. [55]). Die Einteilung in Klassen ist ein sehr starres Schema, bei dem Netze der Klasse A 224 , der Klasse B 216 , und Netze der Klasse C 28 Teilnehmer beinhalten 13

Hier wird nur auf das ipv4 eingegangen, das mit seinen 232 m¨ oglichen Adressen f¨ ur den weltweiten Einsatz u ugt. Aus ¨ ber einen viel zu kleinen Adressvorrat verf¨ diesem Grund existieren Verfahren zur dynamischen Zuteilung von IP-Adressen. oglichen Adressen umgestellt. Zur Zeit wird ipv4 auf ipv6 mit 2128 m¨

5.1 Kommunikationstechnik

169

32 Bit

Klasse

Adressbereich

A

0

B

10

C

110

D

1110

Netz

Host Netz

1.0.0.0 Host

Netz Multicastadresse

Host

bis 127.255.255.255

128.0.0.0

bis 191.255.255.255

192.0.0.0

bis 223.255.255.255

224.0.0.0

bis 239.255.255.255

Abbildung 5.12. Vereinfachtes Adressierungsschema des Vermittlungsprotokolls IP in der Version ipv4

k¨ onnen. Durch die Einf¨ uhrung einer so genannten Netzmaske, mit deren Hilfe ein Teilbereich der Adresse gekennzeichnet wird, kann dieses Adressschema besser an den tats¨ achlichen Bedarf angepasst werden. Schicht 4 nutzt f¨ ur Transportverbindungen eine je Teilnehmer bzw. je Rechnerknoten eindeutige Kennung. Unter dem TCP (Transport Control Protocol) nennt man diese Kennung Port. Die Schicht 5 f¨ uhrt f¨ ur die Dauer der Nutzung eines Dienstes eine SessionID, u ¨ ber die sich der Nutzer des Dienstes identiﬁzieren kann. Schicht 6 identiﬁziert die Datentypen u ¨ ber entsprechende Kennungen, und die Schicht 7 kann je nach Auspr¨ agung der jeweiligen Applikation Funktionscodes oder Objekt-IDs als eindeutige Kennung verwenden. 5.1.6 Beispiele Client-Server-Modell Netzwerke eignen sich dazu, Dienste f¨ ur andere Teilnehmer bereitzustellen. Der Erbringer eines solchen Dienstes wird Server, der Nutzer des Dienstes wird Client genannt14 . Beispielsweise stellt ein Fileserver Dienste f¨ ur den Zugriﬀ auf ein Dateisystem zur Verf¨ ugung. Diese Dienste k¨ onnen auch von mehreren Clients nebenl¨auﬁg genutzt werden. Eine solche Architektur muss unterschiedliche St¨ orf¨ alle behandeln k¨onnen. So kann beispielsweise der Server, einer der Clients oder das Netzwerk in unterschiedlichen Systemzust¨ anden ausfallen (s. [55]). Ein Prozess kann auch gleichzeitig beide Rollen einnehmen, indem er zur Erbringung seiner Dienste die Dienste eines anderen Servers nutzt. WMS setzen h¨ auﬁg das Client-Server-Prinzip ein, um beispielsweise dezentrale Arbeitsstationen zu realisieren. Auf einem Serverrechner werden zen14

Das Client-Server-Prinzip ist allgemeing¨ ultig und nicht an ein Netzwerk gebunden. Auch auf einem einzelnen Rechner k¨ onnen Server durch Prozesse realisiert werden und gleichzeitig k¨ onnen andere Prozesse als Client arbeiten.

170

5. Informations- und Kommunikationstechnik

tral die Bestandsdaten gehalten, w¨ ahrend auf Clientrechnern ortsnah unter Nutzung der lokalen Rechenleistung lagerspeziﬁsche Anwenderprogramme laufen. Beispiele sind Identiﬁkationsstationen am I-Punkt, Auftragsver¨ waltung f¨ ur die Eingabe und Uberwachung von Auslagerungen und mobile Endger¨ ate im Kommissionierbereich, die mit ortsfesten oder lokalen Clientprogrammen arbeiten. Uhrensynchronisation am Beispiel NTP In einem WMS, das aus mehreren Rechnern besteht und/oder online mit anderen Systemen gekoppelt ist, ist der Einsatz eines Uhrenprotokolls eine wichtige Voraussetzung f¨ ur die Systemkonsistenz (s. Abschn. 5.4.2). Das NTP (Network Time Protocol) ist eine M¨ oglichkeit, die Uhren unterschiedlicher Rechner in einem Netzwerk untereinander zu synchronisieren. Das Grundprinzip basiert auf der Mittelwertbildung. Es wird ein verteilter Algorithmus verwendet, dessen Teile auf unterschiedlichen Rechnern laufen. Namensdienst DNS Der DNS (Domain Name Service) ist ein Internetdienst und dient der Zuordnung von hierarchisch strukturierten Bezeichnern zu einem Satz von Eigenschaften (Resource Records) (s. [55]). Die Hierarchie wird durch eine Folge von Bezeichnern, die durch Punkte getrennt sind, speziﬁziert. Die h¨ ochste Hierarchieebene – die so genannte Top Level Domain – steht ganz rechts. Durch eine Erweiterung nach links durch jeweils einen Punkt und einen Bezeichner kann der Namensraum feiner strukturiert werden. Der rechts von einem Punkt stehende Teil eines Bezeichners wird auch Dom¨ ane (Domain) genannt, der links stehende Teil als Name“, ” der nur innerhalb seiner Dom¨ ane eindeutig sein muss. Die wichtigste Anwendung ist die Zuordnung einer IP-Adresse zu einem Bezeichner. Damit ist es m¨ oglich, Rechner im Internet statt u ¨ ber die numerische und damit oft schwer zu merkende IP-Adresse u ¨ ber einen sprechenden ” Namen“ zu speziﬁzieren. Dar¨ uber hinaus kann sich durch Reorganisation die numerische Adresse ¨ andern, w¨ ahrend der Name gleich bleiben kann. Aliasnamen, die auf den gleichen Rechner verweisen, sind m¨oglich15 . Weitere Anwendungen des DNS sind beispielsweise die Zuordnung von Rechnern zu Mailservern sowie eine Beschreibung des Rechners im Klartext. ¨ DNS ist im Internet als verteilte Datenbank realisiert. F¨ ur die Ubersetzung eines Bezeichners in seine Eigenschaften – zum Beispiel in die zugeordnete IPAdresse – sind die Nameserver zust¨ andig. Diese haben permanente Kenntnis u andigkeitsbereich (in ihrer Dom¨ane). F¨ ur die ¨ber alle Rechner in ihrem Zust¨ Auﬂ¨ osung fremder Adressen nutzt der Nameserver die Dienste anderer Nameserver und h¨ alt diese Information f¨ ur eine gewisse Zeit, um den Datenverkehr zu verringern.

15

www.mywms.org und www.mywms.com verweisen auf die gleiche IP-Adresse.

5.1 Kommunikationstechnik

171

Tabelle 5.2. Beispiele f¨ ur URLs URL

Beschreibung

http://mywms.org

Hypertext Transfer Protocol über den Standard-Port des http-Servers des Rechners mywms.org

http://mywms.org:8080

Hypertext Transfer Protocol über den Port 8080 des http-Servers des Rechners mywms.org

mailto://[email protected]

Senden einer E-Mail an den Rechner mywms.org für den Empfänger info

ftp://dante.org/tex/v1.tgz

File Transfer Protocol zum Lesen der Datei /tex/v1.tgz vom Rechner dante.org

ftp://alice:[email protected]/tex/v1.tgz

wie oben, jedoch identifiziert sich der Nutzer des Dienstes mit dem Namen alice und dem Kennwort bob

URL Die Forderung nach einem einheitlichen Adressierungsschema wird durch die URL (Universal Resource Locator )16 erf¨ ullt. Der hierarchische Namensraum einer URL wird durch die Kombination mehrerer Namensr¨aume gebildet. An erster Stelle steht ein Protokollbezeichner, der mit einem Doppelpunkt abschließt. Das so speziﬁzierte Protokoll bestimmt einerseits das zu verwendende Applikationsprotokoll und andererseits den weiteren Aufbau der URL. Der weitere Aufbau beginnt h¨ auﬁg mit einem Schr¨agstrich, wenn Dateinamen speziﬁziert werden oder mit einem doppelten Schr¨agstrich, wenn Rechner speziﬁziert werden. Rechner k¨ onnen wahlweise durch ihren Namen (s. Abschn. 5.1.6) oder durch ihre IP-Adresse (s. Abschn. 5.1.5) bezeichnet werden. WWW Das WWW (World Wide Web) ist ein Internetdienst, der 1989 am CERN in Genf mit dem Ziel einer einheitlichen Darstellung und einer einheitlichen Verkn¨ upfung von Dokumenten entwickelt wurde. Inzwischen ist das WWW zu dem bekanntesten Internetdienst geworden, so dass umgangssprachlich das Internet h¨ auﬁg mit dem WWW – oder kurz: Web – gleichgesetzt wird. Der Dienst arbeitet nach dem Client-Server-Prinzip. Der Server verwaltet die Dokumente, die u ¨ber URLs, die so genannten Links, miteinander verkn¨ upft sind. Ein Link kann als interner Link auf Teile des Dokuments, in dem er deﬁniert ist, oder als externer Link auf andere Dokumente, die auch auf fremden Rechnern gespeichert sein k¨onnen, verweisen. 16

Der Begriﬀ URI (Universal Resource Identiﬁer) wird synonym verwendet, ist aber nicht so weit verbreitet (s. [81]).

172

5. Informations- und Kommunikationstechnik

Tabelle 5.3. Einige Beispiele f¨ ur mime-Typen Typ

Untertyp

Beschreibung

Text

Plain

unformatierter Text

Richtext

Text mit einfachen Formatierungen

gif

Bild im Grafikformat “gif“

jpg

Bild im Grafikformat “jpeg“

Audio

wav

Audiodatei

Application

octet-stream

applikationsspezifischer Bytestrom

Image

Die Dokumente werden in einem logischen Format in der Hypertext Markup Language (HTML) gespeichert und u ¨bertragen. Die genaue Art der Darstellung bestimmt der Client. Das Darstellungsprogramm f¨ ur HTML-Dokumente – der Browser – kann u ¨ ber lokale Einstellungen die empfangenen Dokumente an die Nutzerbed¨ urfnisse angepasst darstellen. Hierzu z¨ahlen beispielsweise Schriftgr¨ oße, Farben und die Seitenbreite, aber auch sicherheitsrelevante Einstellungen wie beispielsweise Verkn¨ upfungen von empfangenen Dokumenten ¨ mit Applikationen. Die Ubertragung der Dokumente erfolgt durch ein einfaches Klartext-Protokoll17, das HTTP (Hypertext Transfer Protocol ). Die Art der Dokumente ist nicht auf Texte beschr¨ankt, sondern umfasst auch eine Vielzahl weiterer Dokumenttypen wie Multimedia-Dokumente oder anwendungsspeziﬁsche Dokumente wie beispielsweise Zeichnungen oder Artikelstammdaten. Dokumente werden durch ihre mime-Typen (Multipurpose Internet Mail Extensions) [55] speziﬁziert, die urspr¨ unglich f¨ ur E-Mail eingef¨ uhrt wurden (s. Tabelle 5.3). In WMS wird HTML zunehmend f¨ ur die Benutzerschnittstelle eingesetzt. Der Vorteil liegt in einer einheitlichen Kommunikation, so dass die Endger¨ate nur u ugen m¨ ussen. Diese sind bereits auf ¨ber einen geeigneten Browser verf¨ vielen Personalcomputern im B¨ urobereich vorhanden, und mobile Endger¨ate mit HTML-Browsern werden zunehmend am Markt verf¨ ugbar. Ressourcenfreigabe Die Netzwerktechnik bietet die M¨oglichkeit, lokale Ger¨ ate, Verzeichnisse und Dateien f¨ ur andere Teilnehmer im Netz zur Verf¨ ugung zu stellen. Ziele sind die Mehrfachnutzung, Kostenersparnis und 17

Klartext bedeutet, dass nur druckbare Zeichen u ¨ bertragen werden.

5.2 Datenhaltung

173

Nutzung zentraler Dienste, wie beispielsweise ein zentrales Backup eines Fileservers.

5.2 Datenhaltung Die Datenhaltung ist ein wichtiger Aspekt der Lagerverwaltung. Neben den Artikel- und den Bestandsdaten – den Kerndaten eines Lagerverwaltungssystems – existiert eine Vielzahl weiterer Daten, die verwaltet werden muss. Eine Diﬀerenzierung kann nach dem Grad der Dynamik erfolgen. Statische Daten, die im laufenden Betrieb nicht ver¨ andert werden k¨onnen, sind beispielsweise Anzahl und Abmessungen der Lagerorte18. Daten mit einer geringen Dynamik sind Artikelstammdaten, da sie nur beim Anlegen neuer Artikel erzeugt ¨ und bei Anderungen der Artikeleigenschaften ge¨andert werden. Zu den hochdynamischen Daten z¨ ahlen Auftrags- und Bestandsdaten, da diese bei jeder Lagerbewegung ge¨ andert werden (s. Kapitel 2.4). Die sichere und dauerhafte Speicherung, die Widerspruchsfreiheit der Gesamtheit aller Daten eines Systems, der schnelle Zugriﬀ sowie die Archivierung von Daten stehen im Mittelpunkt der folgenden Betrachungen. Dabei wird auch die relationale Datenbank behandelt, die heute den meistverbreiteten Standard f¨ ur die Datenhaltung in komplexen Systemen darstellt. 5.2.1 Prinzipien Die folgenden Prinzipien und Deﬁnitionen sind unabh¨angig von der Art der Datenhaltung. Persistierung Die dauerhafte Speicherung der Daten unabh¨angig von der Methode nennt man Persistierung. Programme halten ihre Daten zur Laufzeit im Speicher, dessen Inhalt bei Ausfall der Versorgungsspannung, bei Defekten an der Hardware und bei fehlerhaftem Programmverhalten verloren gehen kann. Gelegentlich ist es erforderlich, die Ausf¨ uhrung eines laufenden Systems f¨ ur Wartungszwecke zu beenden und zu einem sp¨ateren Zeitpunkt neu zu starten. In all diesen F¨ allen m¨ ussen die Daten dauerhaft erhalten bleiben, also persisiert werden. Referenzielle Integrit¨ at Daten d¨ urfen nicht gel¨oscht werden, wenn andere Programmteile diese Daten noch ben¨ otigen ( referenzieren“). Dieses Prinzip ” der referenziellen Integrit¨at kann beispielsweise verhindern, dass in einem WMS Artikelstammdaten gel¨ oscht werden, wenn sich noch entsprechende Artikel im Lager beﬁnden oder avisiert sind. 18

¨ Es existieren Systeme, die zur Laufzeit solche Anderungen erlauben. Dabei kann die Sicherung der Systemintegrit¨ at sehr aufw¨ andig sein.

174

5. Informations- und Kommunikationstechnik

Transaktionen W¨ ahrend der Bearbeitung von Daten treten immer wieder tempor¨ ar inkonsistente Zust¨ ande auf. Wenn beispielsweise eine neue Palette ins System kommt, m¨ ussen ihre Daten u ur ¨ bernommen werden, der Z¨ahler f¨ die Palettenanzahl inkrementiert und ein Stellplatz belegt werden. Da der Programmﬂuss aber sequenziell ist, treten kurzzeitig inkonsistente Zust¨ande auf. Die L¨ osung hierf¨ ur ist das Mittel der Transaktion, die solche Operationen klammert“. Jeder Zustand vor einer Transaktion ist konsistent und jeder ” Zustand nach einer Transaktion ebenfalls. Transaktionssysteme bieten die M¨ oglichkeit eines Rollbacks, um eine Transaktion abzubrechen und in den vorherigen Zustand zur¨ uckzukehren. Ein Rollback verwirft alle innerhalb der ¨ Transaktion durchgef¨ uhrten Anderungen. Das Gegenteil – der erfolgreiche Abschluss einer Transaktion – wird durch ein Commit eingeleitet und f¨ uhrt zu einer dauerhaften Aktualisierung der ge¨ anderten Daten und zu einem neuen konsistenten Zustand. Zugriﬀs- und Sperrmechanismen Die nebenl¨auﬁge Nutzung von Daten sowie das Transaktionskonzept erfordern Zugriﬀsmechanismen, die abh¨angig von den beabsichtigten Operationen auf den gelesenen Daten sind. Eine Sperre kann sich beispielsweise nur auf genau den Umfang der gelesenen Daten oder auf ganze Dateien sowie auf Datenbanktabellen oder nur auf Teile einer Datenbanktabelle beziehen. Einige Datenhaltungssysteme bieten die M¨oglichkeit, auch gesperrte Daten zu lesen. Ein Anwender dieses dirty read -Prinzips muss ber¨ ucksichtigen, dass diese Daten nebenl¨ auﬁg ge¨ andert werden k¨onnen. Diese Art des Zugriﬀs wird beispielsweise f¨ ur Auskunftsfunktionen genutzt. ¨ Trigger Anderungen von Datens¨ atzen k¨ onnen oft weitere Aktionen nach sich ziehen. Das Grundprinzip, dass eine Zustands¨anderung zu einem Ereignis wird, nennt man Trigger – in diesem konkreten Fall Datentrigger. In ¨ einem WMS kann dies bedeuten, dass die Anderung einer Artikeleigenschaft zu Aktualisierungen weiterer Daten f¨ uhren muss. Dieser Sachverhalt kann zwar in den Funktionen eines Programms codiert werden, eine L¨osung u ¨ ber ¨ Datentrigger stellt aber immer sicher, dass diese Anderungen durchgef¨ uhrt werden und vermeidet potenzielle Programmierfehler. Journaling Da die dauerhafte Speicherung eines großen Datenbestandes sehr aufw¨ andig ist, kann es in einigen F¨ allen sinnvoll sein, nach einer ¨ Anderung des Datenbestandes nicht die Daten selbst, sondern nur die Operationen zu speichern. Dieses Journaling genannte Prinzip wird vielf¨altig – auch zur Datensicherung – angewendet. Transaktionen und undo-Funktionen“ ” werden meist durch Journaling realisiert. Ausgehend von einem Anfangs¨ zustand werden alle Anderungen in einem so genannten Journalﬁle aufgezeichnet. Nach einem Systemabbruch kann nun durch Anwendung der in der

5.2 Datenhaltung

175

Journaldatei hinterlegten Operationen der aktuelle Zustand19 wieder restauriert werden. Die Persistierung beschr¨ ankt sich also bei Einsatz der Journaltechnik auf die Persistierung der Zustands¨anderungen und nicht auf die Zust¨ ande selbst. Damit die Journaldatei nicht zu groß wird, muss der aktuelle Systemzustand von Zeit zu Zeit persisiert und die Journaldatei gel¨oscht werden. Archivierung Die Archivierung von Datenbest¨anden dient im Gegensatz zur Persistierung der langfristigen Sicherung von Datenbest¨anden und ist f¨ ur eine sp¨ atere Auswertung von Daten und insbesondere f¨ ur die Erstellung von Reports und anderen Oﬄine-Auswertungen wichtig. Teilweise existieren auch gesetzliche Anforderungen f¨ ur die Archivierung von Daten, oder die Erfordernisse der Qualit¨ atssicherung verlangen eine Archivierung. Beispiele sind die Archivierung von Lieferscheinen und Inventurdaten. 5.2.2 Dateisysteme Eine dauerhafte Datenspeicherung20 bietet jedes Betriebssystem in Form eines Dateisystems (Filesystem). Dateien werden u ¨ ber Namen referenziert, welche in der Regel einer Hierarchie unterliegen. Diese Hierarchie wird durch Verzeichnisse (Directories) dargestellt. Eine Datei kann durch einen absoluten oder durch einen relativen Pfad (Path) referenziert werden. Jede Hierarchie beginnt bei einer Wurzel und endet bei einer Datei. Die Wurzel eines Dateisystems kann mit dem Speichermedium des Dateisystems oder mit einem logischen Bezeichner beginnen (UNIX: /“, WINDOWS: a:“, b:“, c:“, ” ” ” ” d:“, usw.). Die Verwendung von Sonderzeichen ist oft erlaubt, f¨ uhrt aber ” bei einigen Systemen zu einer besonderen Interpretation. Diese Aspekte sind insbesondere bei verteilten und bei portablen WMS zu ber¨ ucksichtigen. Hier sollte man auf Sonderzeichen und Leerzeichen verzichten und alle Dateinamen einheitlich mit Kleinbuchstaben schreiben. F¨ ur portable Dateibezeichner existieren Empfehlungen. Die logische Struktur von Dateien beschreibt die Art, wie bestimmte Datens¨ atze selektiert werden k¨ onnen: • sequenziell (sequence access): Die Datens¨ atze einer Datei k¨onnen nur sequenziell fortlaufend gelesen bzw. geschrieben werden. Diese Art der Dateiorganisation ist beispielsweise f¨ ur das Schreiben von Zeitreihen f¨ ur sp¨atere 19

20

Oﬀene Transaktionen werden beim Restaurieren nicht mehr ausgef¨ uhrt. Damit ist nach einem Systemabbruch immer zu pr¨ ufen, ob die letzten Operationen auch ausgef¨ uhrt wurden. So genannte RAM-Disks, die im Hauptspeicher eines Rechners angelegt werden, stellen ein ﬂ¨ uchtiges Dateisystem dar und sind dann sinnvoll, wenn eine Applikation die Funktionalit¨ at eines Dateisystems mit Ausnahme der Persistierung ben¨ otigt. Insbesondere f¨ ur Testzwecke kann der Einsatz einer RAM-Disk wegen der kurzen Zugriﬀszeiten f¨ ur Tests sinnvoll sein. F¨ ur WMS triﬀt das – im Gegensatz zu unterlagerten Steuerungssystemen – in der Regel nicht zu.

176

5. Informations- und Kommunikationstechnik

Tabelle 5.4. Typische Dateiattribute und deren Bedeutung Attribut

Bedeutung

read

Lesen des Datei-Inhaltes ist erlaubt.

write

Schreiben der Datei ist erlaubt.

delete

Löschen der Datei ist erlaubt. Das ist in vielen Systemen gleichbedeutend mit einem Schreibrecht im Verzeichnis dieser Datei.

execute

Die Datei darf als Code ausgeführt werden. Es kann sich dabei um eine Datei mit ausführbarem Maschinencode oder bei einigen Systemen auch um einen interpretierbaren Code handeln.

lock

Die Datei ist bereits geöffnet und darf nicht noch ein weiteres Mal geöffnet werden.

archive

Diese Datei soll in eine Sicherungskopie aufgenommen werden.

password

Password für den Zugriff auf diese Datei

owner

Eigentümer dieser Datei

Zeitpunkt der Erzeugung

Uhrzeit und Datum der Erzeugung

Zeitpunkt des letzten Zugriffs

Uhrzeit und Datum des letzten lesenden Zugriffs

Zeitpunkt der letzten Änderung

Uhrzeit und Datum des letzten schreibenden Zugriffs

statistische Auswertungen sinnvoll. Bandger¨ate unterst¨ utzen aufgrund ihres physischen Aufbaus nur diese Zugriﬀsart. • indexsequenziell (ISAM: index sequence access method): Jeder Datensatz kann u ussel selektiert werden. Danach kann von dieser Positi¨ ber einen Schl¨ on aus weiter sequenziell auf die Daten zugegriﬀen werden. ISAM-Dateien wurden in der Vergangenheit h¨ auﬁg in der Lagerverwaltung eingesetzt. Heute wird diese Zugriﬀsmethode von Datenbanken genutzt und bleibt damit meist anderen Applikationen verborgen. • wahlfrei (random access): Jeder Datensatz kann u ¨ ber eine ganze Zahl selektiert werden. Damit kann eine Applikation selbst u ¨ ber eine so genannte Schl¨ usseltransformation beliebige Zugriﬀe realisieren. In der Vergangenheit wurden h¨ auﬁg Datens¨ atze, die den Lagerorten zugeordnet sind, u ¨ ber wahlfreie Dateizugriﬀe selektiert. Heutige Systeme setzen in der Regel Datenbanken ein.

5.2 Datenhaltung

177

Der Zugriﬀ auf Dateien unterliegt einem Schutzmechanismus, der meist durch ein abgestuftes Berechtigungssystem f¨ ur den Eigent¨ umer, die Gruppenmitglieder und sonstige Benutzer realisiert wird. Durch Verschl¨ usselung von Dateiinhalten kann – falls Unbefugte in den Dateibesitz gekommen sind – zus¨ atzliche Sicherheit gegen Missbrauch eingebaut werden. Der Inhalt der Datei kann in diesem Fall erst nach einer Entschl¨ usselung, die nur durch Kenntnis des entsprechenden Schl¨ ussels – meist ein Kennwort – m¨ oglich ist, betrachtet werden. 5.2.3 Datenbanken Unter einer Datenbank versteht man heute im Allgemeinen eine relationale Datenbank (RDBS : Relational Database System). Das Grundprinzip dieser Datenbanken wird in diesem Abschnitt beschrieben. Eine Datenbank muss • • • • •

Daten dauerhaft speichern, die Integrit¨ at der Daten sichern, den Zugriﬀ auf Datens¨ atze erlauben, Datens¨ atze miteinander verkn¨ upfen und Datens¨ atze anlegen, ¨ andern und l¨ oschen k¨ onnen.

Dar¨ uber hinaus werden die in Abschn. 5.2.1 beschriebenen allgemeinen Anforderungen an die Datenhaltung erf¨ ullt. In Kapitel 7.2 wird ein Beispiel f¨ ur ein WMS auf der Basis einer relationalen Datenbank vorgestellt. Die in einer Datenbank zu verwaltenden elementaren Datens¨atze (Records, Tupel) aus der realen oder der Vorstellungswelt nennt man Entit¨aten. Die Struktur der Datens¨ atze wird durch Felder (Attribute) beschrieben, die mit Werten (Attributwerten) belegt werden. Jedem Feld eines Datensatzes wird ein Datentyp zugewiesen. Gleich strukturierte Datens¨atze werden in einer Tabelle gespeichert. Die Datens¨ atze einer Tabelle m¨ ussen sich mindestens in dem Wert eines Feldes unterscheiden. Damit entspricht eine Tabelle im mathematischen Sinne einer Relation (s. Tabelle 5.5). Die Beziehungen zwischen Entit¨ atsmengen werden durch gerichtete Assoziationen ausgedr¨ uckt. Eine Assoziation EM1 ← EM2 legt fest, wie viele Entit¨ aten aus EM2 einer Entit¨ at aus EM1 zugeordnet sein k¨onnen. In der Praxis werden aber nur vier Grundtypen von Assoziationen unterschieden (s. Tabelle 5.6). Tabelle 5.8 zeigt Beispiele f¨ ur Assoziationen. Aus den elementaren Assoziationstypen k¨onnen Assoziationen in beide Richtungen gebildet werden. Tabelle 5.7 erl¨ autert die Typen der hierarchischen, der konditionellen und der netzwerkf¨ ormigen Assoziationen. Jede Tabelle ben¨ otigt einen eindeutigen Prim¨arschl¨ ussel, der im Allgemeinen genau einem Feld zugeordnet wird. Viele Datenbanken unterst¨ utzen auch segmentierte Schl¨ ussel, die sich u ¨ber mehrere Felder erstrecken. Um den Zugriﬀ auf einzelne Datens¨ atze zu beschleunigen, k¨onnen Indizes angegeben

178

5. Informations- und Kommunikationstechnik

Tabelle 5.5. Darstellung einer Relation durch eine Tabelle Relation Artikel

Nummer

Bezeichnung

Gewicht

3973684

PU-Schaum

0.800

3974954

Bitumen

3978617

Fuellspachtel

30.000

Attribut

Tupel

5.000

Attributwert

Tabelle 5.6. Assoziationstypen und deren Bedeutung Assoziationstypen und deren Bedeutung

Assoziationstyp

Anzahl der Entitäten aus EM2, die einer Entität aus EM1 zugeordnet sind

1 : einfache Assoziation

1

c : konditionelle Assoziation

c ෛ {0, 1}

m : multiple Assoziation

m≥1

mc : multiple-konditionelle Assoziation

mc ≥ 0

werden, die sich ebenfalls auf ein Feld oder auf eine Gruppe von Feldern erstrecken k¨ onnen. Jeder zus¨ atzliche Index erfordert jedoch auch zus¨atzlichen Speicherplatz und Rechenzeit, um diesen Index zu erstellen. Die Assoziationen zwischen mehreren Relationen werden durch EntityRelationship-Diagramme dargestellt. Die Assoziationen selbst sind auch Relationen, die in Datenbanken ebenfalls durch Tabellen implementiert werden. Abbildung 5.13 zeigt ein einfaches Beispiel. Die Entit¨aten artikel, palette, lagerort und charge sind u ¨ber die Assoziationen zusammenlagerungsverbot, ladeeinheit, chargenzugeh¨origkeit und palette-lagerplatz-zuordnung verbunden. Das Diagramm zeigt an den Verbindungslinien den jeweiligen Typ der Assoziation.

5.2 Datenhaltung

179

Tabelle 5.7. Klassiﬁzierung von Assoziationstypen nach [85] Klassifizierung von Assoziationstypen nach [78]

1

c

m

mc

1

1–1

c–1

m–1

mc – 1

hierarchisch

c

1–c

c–c

m–c

mc – c

konditionell

m

1–m

c–m

m–m

mc – m

netzwerkförmig

mc

1 – mc

c – mc

m – mc

mc – mc

Tabelle 5.8. Beispiele f¨ ur Assoziationen Entitätsmenge_1

Entitätsmenge_2

Assoziationstyp

Bezeichnung

Artikel

Artikel

m–m

Zusammenlagerungsverbot

Artikel

Palette

mc – mc

Ladeeinheit (Mischpalette)

Artikel

Palette

c – mc

Ladeeinheit (artikelreine Palette)

Palette

Lagerplatz

c–1

Standort einer Palette (platzgenau)

Palette

Lagerort

mc – 1

Standort einer Palette (bereichsgenau)

Charge

Palette

c–m

Chargenzugehörigkeit einer Palette (Voraussetzung: chargenreine Paletten)

Zone

Lagerfach

m–m

Zonendefinition

Lagerplatz

Lagerplatz

m–m

Distanz (Transportkosten)

Bislang wurde eine Datenbank aus logischer Sicht (logisches Schema) beschrieben. Eine Datenbank wird durch drei Datenbankschemata beschrieben: • Das logische Schema beschreibt die Struktur der Tabellen (s.o.).

180

5. Informations- und Kommunikationstechnik

Abbildung 5.13. Typisches Entity-Relationship-Diagramm am Beispiel einiger Aspekte der Lagerverwaltung

• Ein oder mehrere externe Schemata beschreiben Sichten (views) auf das logische Schema. Jedes Schema enth¨ alt einen Ausschnitt der Sichten, der f¨ ur die jeweilige Applikation oder f¨ ur einen Benutzer oder eine Benutzergruppe erforderlich oder erlaubt ist. • Das interne Schema beschreibt die physische Organisation der Datenspeicherung sowie die Zugriﬀsorganisation. Bevor Daten in eine Datenbank eingegeben, gelesen und ge¨andert werden k¨ onnen, muss die Datenbank eingerichtet werden. Hierzu nutzt man eine Datendeﬁnitionssprache (DDL: data deﬁnition language). Es werden die Tabellen, deren Struktur und Feldtypen sowie die Indizes beschrieben. F¨ ur die ¨ Operationen auf einer Datenbank stehen f¨ ur Abfragen und f¨ ur Anderungen auf den Datenbest¨ anden Datenmanipulationssprachen (DML: data manipulation language) zur Verf¨ ugung. DDL und DML werden bei den meisten Datenbanksystemen durch eine Sprache zusammengefasst. Als Standard hat sich hier SQL (Structured Query Language) etabliert. SQL erm¨oglicht insbesondere das Einrichten von Tabellen, Indizes und Views sowie das Suchen, Ver¨ kn¨ upfen, Andern, Einf¨ ugen und L¨ oschen von Datens¨atzen. Die Tabelle 5.5 kann in SQL mit der Anweisung create table ARTIKEL ( NUMMER number(7) BEZEICHNUNG char(40) GEWICHT number(8) ) erstellt werden. Die Werte k¨ onnen mit den Anweisungen insert into ARTIKEL values (3973684, PU-Schaum, 0.800) insert into ARTIKEL values (3974954, Bitumen, 30.000) insert into ARTIKEL values (3978617, Fuellspachtel, 5.000)

5.2 Datenhaltung

181

in die Tabelle eingetragen werden. Anhand einfacher SQL-Beispiele werden die Grundoperationen, die auf Tabellen ausgef¨ uhrt werden k¨ onnen, beschrieben. Das Ergebnis einer solchen Verkn¨ upfung ist immer eine neue Tabelle. • Die Projektion erm¨ oglicht die Auswahl bestimmter Attribute (Spalten) aus einer Tabelle. select NUMMER BEZEICHNUNG from ARTIKEL Als Ergebnis wird aus der Tabelle 5.5 3973684 PU-Schaum 3974954 Bitumen 3978617 Fuellspachtel zur¨ uckgegeben. Durch zus¨ atzliche Angabe einer where-Klausel k¨onnen die Grundoperationen der Selektion und der Projektion verkn¨ upft werden. • Die Selektion erm¨ oglicht die Auswahl bestimmter Tupel (Zeilen) aus einer Tabelle21 . select * from ARTIKEL where GEWICHT > 20.000 Als Ergebnis wird aus der Tabelle 5.5 3974954

Bitumen

30.000

zur¨ uckgegeben. • Der Verbund (join) verkn¨ upft zwei Tabellen P und Q bez¨ uglich gemeinsamer Attribute22 . Das Resultat ist eine Tabelle mit einer neuen Struktur, welche die Attribute, die in beiden Originaltabellen gemeinsam vorhanden sind, nur einmal enth¨ alt. Die neuen Tupel umfassen alle Kombinationen der Tupel von P und Q, die auf den gemeinsamen Attributen identische Wertekombinationen besitzen. Ein Join der Tabellen ARTIKEL und LADEEINHEIT wird in SQL durch select * from ARTIKEL, LADEEINHEIT ausgedr¨ uckt. Das Ergebnis sind alle Tupel aus ARTIKEL vereinigt mit allen Tupeln aus LADEEINHEIT23 , bei denen die Artikelnummer gleich ist. Außer diesem nat¨ urlichen Verbund (⊗-Verbund) existiert der Θ-Verbund, der zus¨ atzliche Vorschriften f¨ ur die Attributwerte enth¨alt (s. z. B. [3]). Ein Θ-Verbund der Tabellen ARTIKEL und LADEEINHEIT kann in SQL durch eine zus¨ atzliche where-Klausel formuliert werden. 21 22 23

Das *-Zeichen nach dem select bedeutet, dass die ausgegebenen Tupel alle Attribute enthalten. Zwei Attribute sind gleich, wenn sowohl ihre Bezeichner als auch ihre Wertebereiche u ¨ bereinstimmen. Die Tabelle LADEEINHEIT verkn¨ upft Artikelnummern mit Palettennummern und ist hier aus Platzgr¨ unden nicht dargestellt.

182

5. Informations- und Kommunikationstechnik

select * from ARTIKEL, LADEEINHEIT where ARTIKEL.GEWICHT > 20.000 Weitere elementare Verkn¨ upfungen sind u ¨ber die Mengenoperationen Vereinigung (union), Durchschnitt (intersection) und Diﬀerenz (minus) m¨oglich. Datenbanken werden als Client-Server-Applikationen betrieben. Die eigentliche Datenbank, die Datenbankengine (DBMS : Datenbankmanagementsystem), stellt als Serverprozess ihre Dienste den Clients zur Verf¨ ugung. Diese Clients sind Applikationen, welche die anwendungsspeziﬁschen Operationen auf den Daten ausf¨ uhren. Im Bereich der WMS k¨onnte das beispielsweise ein Client zur Pﬂege der Stammdaten oder ein Client f¨ ur den Wareneingangsbereich sein. Der Zugriﬀ auf die Datenbankengine erfolgt entweder u ¨ ber Bibliotheksmodule, die mit der Datenbank ausgeliefert werden, oder u ¨ ber ein Standardprotokoll wie beispielsweise ODBC (Open Database Connectivity). ODBC erlaubt einer Applikation, sich – ggf. u ¨ ber ein Netzwerk – mit einer Datenbank zu verbinden und ihre Dienste zu nutzen. Hierzu ben¨otigt man auf der Clientseite einen geeigneten ODBC-Treiber, der im Allgemeinen vom Hersteller der Datenbank geliefert wird. Die Client-Server-Architektur eines Datenbanksystems erfordert, dass jeder Datensatz, der manipuliert wird, zuerst vom Server – der Datenbank – zum Client gesendet werden muss, dort manipuliert und anschließend u uckgeschrieben wird. F¨ ur h¨auﬁg ¨ber den entgegengesetzten Weg wieder zur¨ ben¨ otigte und f¨ ur umfangreiche Operationen – beispielsweise das Setzen von Sperrkennzeichen auf alle F¨ acher einer Regalgasse – f¨ uhrt das zu einer starken Performanceeinbuße. Aus diesem Grund bieten die meisten Datenbanken so genannte Stored Procedures. Hierbei handelt es sich um Funktionen, die auf der Serverseite hinterlegt sind und dort nach einer Aktivierung durch einen Client selbstst¨ andig die Operationen ausf¨ uhren, ohne dass ein Datentransfer zwischen Server und Client stattﬁndet. Die schnellere Ausf¨ uhrung der Operation hat auch zur Folge, dass die betroﬀenen Datens¨atze nur f¨ ur eine verh¨ altnism¨aßig kurze Zeit gesperrt werden und damit schneller wieder f¨ ur andere Clients zur Verf¨ ugung stehen. Die Folge ist eine oft drastische Erh¨ ohung des Gesamtdatendurchsatzes. Neben den hier beschriebenen relationalen Datenbanken kommen vermehrt auch objektorientierte Datenbanken (ODBS : Object Oriented Database System) auf den Markt. Diese erlauben eine direkte Persistierung von Softwareobjekten und erschließen damit den Bereich der Datenbanken auch f¨ ur die objektorientierten Techniken. 5.2.4 Datenverf¨ ugbarkeit Die Verf¨ ugbarkeit der Datenbest¨ ande darf nicht mit der Sicherung der Integrit¨ at und nicht mit der Vermeidung des Zugriﬀs durch Dritte verwechselt

5.2 Datenhaltung

183

werden. Diese Aspekte werden unter dem Stichwort der Sicherheit in Datenbest¨ anden behandelt. Die aktuellen Daten m¨ ussen immer verf¨ ugbar (OnlineVerf¨ ugbarkeit) und ¨ altere Daten m¨ ussen bei Bedarf zugreifbar (OﬄineVerf¨ ugbarkeit) sein. Unterbrechungsfreie Stromversorgung Die Verf¨ ugbarkeit der Daten muss auch bei Ausfall der Stromversorgung und nach einem Hardwaredefekt gew¨ ahrleistet sein. Ein Ausfall der Stromversorgung kann durch Einsatz einer unterbrechungsfreien Stromversorgung (USV ) f¨ ur eine beschr¨ankte Zeit u uckt werden. Die Energiezufuhr erfolgt f¨ ur diese Zeit aus Akkus. Die ¨berbr¨ Last¨ ubernahme wird dem Rechner u ¨ ber eine – meist serielle – Schnittstelle signalisiert. Das Betriebssystem hat nun die Aufgabe, wenn nicht innerhalb einer einstellbaren Zeit die Stromversorgung aus dem Netz wiederhergestellt wird, alle Anwenderprogramme zu beenden und anschließend den Rechner herunterzufahren“. Damit soll insbesondere der Datenbestand gesichert wer” den. Die Anwenderprogramme m¨ ussen in der Lage sein, sich auf ein solches Signal vom Betriebssystem geordnet zu beenden. Laufende Transaktionen (s. Abschn. 5.2.1) und ge¨ oﬀnete Dateien m¨ ussen geschlossen sowie Verbindungen zu Datenbanken beendet werden. Redundante Datenhaltung Schutz vor einem Hardwareausfall kann durch eine redundante Datenhaltung erreicht werden. Die Methoden sind als RAIDSysteme (Redundant Array of Independent Disks) bekannt. Die Level linear und 0 bieten keine Redundanz, sie wurden durch die ANSI (American National Standards Institute), die diesen Standard deﬁniert hat, aber dennoch in das RAID-Schema eingebunden. Die meistgenutzten Methoden sind die Level 1 und 5. Die Level 0 und 1 k¨ onnen auch gemeinsam genutzt werden. Das Verfahren heißt dann Level 10 oder Level 0/1. Die hier angef¨ uhrten RAIDLevel haben im Einzelnen die folgende Bedeutung: RAID 0 wird auch disk striping genannt und beinhaltet keine Redundanz. Es dient ausschließlich zur Beschleunigung des Zugriﬀs und sollte daher nur gemeinsam mit einer der anderen Varianten eingesetzt werden. Der Datenstrom wird in Bl¨ ocke zerlegt und parallel auf die installierten Laufwerke geschrieben. Sind n Laufwerke vorhanden, dann werden die Bl¨ocke 1 bis n auf die Laufwerke 1 bis n, danach die Bl¨ocke n+ 1 bis 2n ebenfalls auf die Laufwerke 1 bis n und so weiter in numerisch aufsteigender Reihenfolge geschrieben. Das Lesen erfolgt analog. Fehlersicherheit existiert bei diesem Verfahren nicht. F¨ allt ein Laufwerk aus, dann sind alle Daten auch auf den anderen Laufwerken verloren. RAID 1 wird auch mirroring genannt und basiert auf einer doppelten Speicherung der Daten (Datenspiegelung). Nutzbar ist daher nur die H¨alfte der vorhandenen Plattenkapazit¨ at. F¨ allt ein Laufwerk aus, dann wird mit dem jeweils anderen weitergearbeitet.

184

5. Informations- und Kommunikationstechnik

RAID 0 (disk striping) mit 3 Festplatten

1

4

7

...

8

5

2

Festplatte 1

...

3

Festplatte2

6

9

...

Festplatte3

RAID 1 (disk mirroring)

1

2

3

4

5

6

7

8

9

...

1

2

3

4

5

6

7

8

9

...

Festplatte 2

Festplatte 1

RAID 5 (distributed parity check) mit 4 Festplatten

1

4

7

...

2

5

p(7-9) . . .

3 p(4-6)

8

...

p(1-3)

6

9

...

Abbildung 5.14. Vereinfachte Darstellung der Ablage von neun Datenbl¨ ocken unter Einsatz unterschiedlicher RAID-Level

RAID 5 versieht die Daten mit einer zus¨ atzlichen Pr¨ ufsumme und verteilt sowohl die Daten als auch eine Pr¨ ufsumme u ¨ ber mehrere Laufwerke. RAID 5 ist besonders f¨ ur viele Zugriﬀe mit kleinen Datenmengen geeignet, daher wird diese Variante besonders h¨auﬁg in transaktionsorientierten Umfeldern wie Datenbanken eingesetzt. F¨allt ein Laufwerk aus, k¨ onnen die Daten aus den verbleibenden Laufwerken rekonstruiert werden. ¨ Journaling Alle Anderungen an den Datenbest¨anden werden in einer ¨ Journal-Datei aufgezeichnet. Diese Datei wird immer zeitlich vor den Anderungen der Datenbest¨ ande geschrieben. Auf der Basis des letzten Backups (s.u.) kann dann der aktuelle Zustand durch ein so genanntes Recovery wiederhergestellt werden. Die Voraussetzung hierzu ist die Verf¨ ugbarkeit der Journaldatei selbst. Die eigentlichen Daten-Dateien und die Journaldatei werden auf unterschiedlichen Festplatten gehalten. Ein Verlust einer der beiden Dateien ist damit unproblematisch. Sicherungskopien Gegen die Auswirkungen von Hardwareausf¨allen oder ¨ ussen wie Wasser, Feuer oder Uberspannung, aber auch gegen ¨außeren Einﬂ¨ versehentliches oder vors¨ atzliches L¨ oschen von Dateien werden Sicherungskopien (Backup) eingesetzt. Die Speichermedien sollten wechselbar sein, wie zum Beispiel CDs oder Magnetb¨ ander, und an einem sicheren Ort aufbewahrt werden. Alternativ hierzu k¨ onnen die Daten auch u ¨ber ein Netzwerk an einem

5.2 Datenhaltung

185

¨ Tabelle 5.9. Backupmethoden im Uberblick Typ

Beschreibung

Vorteile

Nachteile

normal

Alle (oder alle ausgewählten) Dateien werden gesichert und markiert.

Erfordert nur ein Medium oder einen Satz von Medien zur Wiederherstellung. Dateien lassen sich einfach finden.

Sicherung dauert lange. Es werden viele Medien benötigt, da immer alle Dateien gesichert werden.

differenziell

Nur die geänderten und bisher noch nicht als gesichert markierten Dateien werden gesichert, aber, im Gegensatz zur inkrementellen Sicherung, nicht markiert.

Für die Wiederherstellung werden nur die Medien aus den letzten normalen und der letzten differenziellen Sicherung benötigt. Die Sicherung erfolgt schneller als bei der normalen Sicherung.

Die Wiederherstellung dauert im Allgemeinen länger als bei der normalen Sicherung.

inkrementell

Nur die geänderten und bisher noch nicht als gesichert markierten Dateien werden gesichert und anschließend markiert.

Geringster Speicherbdarf und schnellste Sicherungsmethode.

Die Wiederherstellung dauert wegen der Vielzahl sequenziell einzuspielender Medien länger als bei der differenziellen Sicherung.

entfernten Ort gesichert werden. Die Anfertigung solcher Sicherungen wird auch als Dienstleistung per Datenfern¨ ubertragung (z. B. via Standleitung) angeboten. Ein Backup kann sich auf eine speziﬁsche Applikation, eine Datenbank, das Dateisystem oder auf logische oder physische Festplatten beziehen. Am Anfang sollte man immer eine Komplett-Sicherung seines gesamten Systems durchf¨ uhren. Diese beinhaltet auch das Betriebssystem mit allen Einstellungen und s¨ amtliche Anwendungsprogramme in Form eines so genannten Image-Backups. Hierunter versteht man die komplette Sicherung einer Festplatte. Damit entf¨ allt nach einem Hardwareausfall eine Neuinstallation des Betriebssystems und der Anwendungsprogramme und insbesondere auch die Einstellung der Systemparameter. Das gesicherte Image kann direkt auf eine neue Festplatte kopiert werden. In diesem Fall sind aber die dynamischen Daten noch nicht aktuell. Hierzu m¨ ussen diese Daten in regelm¨aßigen Abst¨ anden gesichert werden. Nach dem Aufspielen der letzten Sicherungs¨ kopie m¨ ussen noch die letzten Anderungen unter Nutzung der Journaldatei (s.o.) nachvollzogen werden. Falls die Journaldatei nicht mehr verf¨ ugbar ist, ¨ k¨onnen die letzten Anderungen nur noch manuell nachvollzogen werden. Neben dem gelegentlichen Vollbackup werden durch inkrementelles und diﬀe¨ renzielles Backup nur Anderungen gesichert, um das Speichervolumen gering zu halten (s. Tabelle 5.9).

186

5. Informations- und Kommunikationstechnik

Das Backup dient auch der Archivierung von Daten f¨ ur eine sp¨atere Auswertung. Es sollte also immer ein Archivierungssystem betrieben werden, das nicht nur technische, sondern auch organisatorische Vorkehrungen triﬀt. Hierzu z¨ ahlen Backup-Programme, Automatisierung von Sicherungsl¨ aufen, Verantwortlichkeiten, Ablagesysteme und Wiederherstellungsszenarien. W¨ ahrend das Backup in der Praxis oft gut organisiert ist, sind f¨ ur die Wiederherstellung (Recovery) korrupter Datenbest¨ande jedoch nicht selten unzureichende Vorkehrungen getroﬀen. Pack-Programme (Packer) werden zur Komprimierung der Daten von den meisten Archivierungssystemen genutzt, um das anfallende Datenvolumen klein zu halten. Die meisten Dateien enthalten Zeichen oder Zeichenfolgen, die mehrfach auftreten. F¨ ur Textdateien sind lange Folgen von Leerzeichen oder das wiederholte Auftreten von einzelnen Worten typisch. Aber auch in anderen Dateien treten viele Zeichenfolgen mehrfach auf. Einfache Verfahren speichern diese mehrfach auftretenden Sequenzen nur einmal ab und f¨ ugen dann statt der Wiederholung dieser Sequenz nur einen Verweis auf ihr erstes Auftreten ein. Bei mehrfach auftretenden Sequenzen wird ein Wiederholungsz¨ ahler, der die Vielfachheit angibt, in die komprimierte Datei mit aufgenommen. Dieses Grundprinzip wurde erweitert und verbessert. Heute sind viele unterschiedliche Algorithmen und Programme zur Komprimierung von Dateien verf¨ ugbar.

5.3 Benutzerschnittstelle Der Benutzerschnittstelle kommt als Mensch-Maschine-Schnittstelle in WMS eine große Bedeutung zu. Die richtige Wahl der Endger¨ate, eine intuitive Bedienerf¨ uhrung und die ergonomische Gestaltung der Bildschirmmasken sind wichtige Voraussetzungen f¨ ur die Akzeptanz bei den Bedienern und f¨ ur eine geringe Fehlerquote. 5.3.1 Endger¨ ate Endger¨ ate sind alle Ein-/Ausgabeger¨ ate, die – im Gegensatz zu Sensoren und Aktoren, welche die Schnittstelle zur F¨ ordertechnik bilden – in direktem Bezug zu einem Bediener stehen. Diese Ein-/Ausgabeger¨ate werden oft zu komplexen Einheiten f¨ ur spezielle Einsatzzwecke zusammengestellt. Beispiele sind • Bildschirmarbeitspl¨ atze mit Mausbedienung und der Ausgabe von Warnt¨ onen u ¨ ber einen Lautsprecher, • Funkterminals mit einer Textanzeige, einer numerischen Tastatur und einem Barcodeleser (s. Abb. 5.15), • Zustandsanzeige durch eine Kontrolllampe und Quittierung durch die Bet¨ atigung eines Tasters.

5.3 Benutzerschnittstelle

187

Tabelle 5.10. Endger¨ ate typische Ausgabegeräte

typische Eingabegeräte

optische Anzeigen

Taster

Kontrolllampen

Maus oder Touchscreen

Textanzeigen

Tastatur

Bildschirm

Barcodescanner

Drucker

Lautsprecher

5.3.2 Funktionale Sicht Die Endger¨ ate sind erst durch den Einsatz entsprechender Software in der Lage, eine Mensch-Maschine-Schnittstelle zu realisieren. Hierzu sind eine Reihe von Funktionen bereitzustellen, die auf den jeweiligen operativen Prozess abgestimmt sind. Die Funktionen arbeiten im Wechselspiel zwischen Ein- und Ausgaben und sollen den Bediener einerseits sinnvoll f¨ uhren, aber andererseits ihn nicht ohne Grund zu einer festen Reihenfolge zwingen. Insbesondere muss – soweit m¨ oglich – eine begonnene Funktion abgebrochen werden k¨ onnen. F¨ ur die Auswahl einer auszuf¨ uhrenden Funktion werden meist hierarchisch organisierte Auswahlmen¨ us angeboten. Die Auswahl der n¨ achsten Ebene und die R¨ uckkehr in die u ¨ bergeordnete Ebene stellen die statische Navigation durch die Auswahlmen¨ us dar. Dem steht als dynamische Navigation der R¨ ucksprung auf die zuletzt ausgew¨ahlte Ebene gegen¨ uber. Ein R¨ ucksprung kann bei der dynamischen Navigation durch einen Vorw¨ artssprung wieder aufgehoben werden. Bei Einsatz dieser Navigationsmethode sollte zur Vermeidung von Fehlern sichergestellt werden, dass Eingabefelder, die bei einer fr¨ uheren Funktionsausf¨ uhrung mit Werten belegt wurden, nach einem dynamischen R¨ ucksprung wieder mit den Voreinstellungen belegt werden. F¨ ur die Eingabewerte sind sinnvolle Vorgaben vorzusehen und alle vom Bediener eingegebenen Werte auf Plausibilit¨at zu pr¨ ufen. Das bedeutet, dass nur erlaubte Zeichen eingegeben, Wertebereiche eingehalten und keine Abh¨ angigkeiten zwischen einzelnen Parametern verletzt werden k¨onnen.

188

5. Informations- und Kommunikationstechnik

Abbildung 5.15. Typisches Endger¨ at mit Barcodescanner, Textanzeige, Tastatur und funkbasierter Daten¨ ubertragung [Foto: SYMBOL]

Die an einem Arbeitsplatz oder an einem Ger¨at ausf¨ uhrbaren Funktionen werden einer oder mehreren Rollen zugewiesen. Beispiele f¨ ur Funktionen ¨ sind das Sperren/Freigeben von Paletten und Lagerorten oder das Andern einer Palettenbelegung. Beispiele f¨ ur Rollen sind Wareneingangspr¨ ufung, Qualit¨ atskontrolle oder Disposition. In einem angenommenen Fall d¨ urfen sowohl die Wareneingangspr¨ ufung als auch die Qualit¨atssicherung Paletten sperren, w¨ ahrend nur die Qualit¨ atssicherung Paletten freigeben darf. Lagerorte k¨ onnen beispielsweise nur von der Disposition gesperrt und freigegeben werden. 5.3.3 Zugangskontrolle Um Funktionen in einem WMS auszuf¨ uhren, sollte aus Sicherheitsgr¨ unden immer eine Zugangskontrolle stattﬁnden. Der Administrator des WMS hinterlegt hierzu Personennamen, Zugangsdaten und die Rollen, die diese Person annehmen darf. Zugangsdaten k¨ onnen Kennworte (Passwords) oder biometri-

5.3 Benutzerschnittstelle

189

sche Daten24 sein. Bei Arbeitsbeginn muss sich jede Person an ihrem Arbeitsplatz anmelden und f¨ ur diese Zugangskontrolle dann auch die Zugangsdaten – beispielsweise durch Eingabe des Kennwortes oder durch einen Scan der Iris – bereitstellen. Nach erfolgreicher Anmeldung kann der Arbeitsplatz f¨ ur die Rollen genutzt werden, f¨ ur die er ausgelegt ist und f¨ ur die auch eine Berechtigung f¨ ur den jeweiligen Bediener vorliegt. Ein Abmelden sollte explizit durch den Bediener erfolgen. Alternativ oder zus¨atzlich kann nach Ablauf einer gewissen Zeit, in der keine Eingaben erfolgen, der Arbeitsplatz gesperrt oder der Bediener implizit abgemeldet werden. Ein gesperrter Arbeitsplatz kann nur durch eine nochmalige erfolgreiche Zugangskontrolle des bereits angemeldeten Bedieners freigegeben werden. Alternativ oder zus¨ atzlich k¨ onnen auch die Arbeitspl¨atze, f¨ ur die eine Berechtigung besteht, eingeschr¨ ankt werden. Dann kann anstelle des rollenbezogenen Zugangs (Einlagern, Kommissionieren usw.) ein ortsbezogener Zugang – z. B. zu genau einem oder zu mehreren deﬁnierten I-Punkten oder Kommissionierpl¨ atzen – zugesichert werden. Weitere Einschr¨ankungen k¨onnen bis auf die erlaubten Einzelfunktionen im Sinne von Berechtigungsproﬁlen (Stammdatenauskunft, Sperren/Freigeben von Chargen usw.) erfolgen. Die Zugangsbeschr¨ ankung auf erlaubte Zeitfenster (Arbeitstage, Schicht usw.) bietet weitere Sicherheit. Die Zugangskontrolle sollte erlauben, die Dialoge in der jeweiligen Muttersprache des Bedieners zu f¨ uhren (s. Abschn. 5.3.4). F¨ ur die Qualit¨atskontrolle ist gelegentlich auch die R¨ uckverfolgung auf die beteiligten Personen erforderlich. Das Gleiche gilt f¨ ur leistungsbezogene Bezahlung. In diesen Anwendungen der Zugangskontrolle werden personenbezogene Daten erfasst und gespeichert, so dass hier in jedem Fall bei der Einf¨ uhrung solcher Systeme mindestens die gesetzlichen Anforderungen des Datenschutzes beachtet werden m¨ ussen. Eine weitergehende Beteiligung der Mitarbeiter und ihrer Vertreter ist bei solchen Vorhaben sinnvoll. 5.3.4 Internationalisierung Grunds¨ atzlich k¨ onnen die Ein- und Ausgaben bedienerabh¨angig, standortabh¨ angig oder nach einem Firmen- oder einem internationalen Standard erfolgen. Dialogtexte sollten in der jeweiligen Landessprache des Bedieners dargestellt werden k¨ onnen. Die Auswahl kann manuell oder u ¨ber das Bedienerproﬁl der Zugangskontrolle erfolgen. Die Endger¨ ate m¨ ussen u ¨ ber entsprechende Zeiahigkeit verf¨ ugen, ihren Zeichensatz von einem exatze oder u chens¨ ¨ber die F¨ ternen Ger¨ at zu beziehen. Die rechnerinterne Darstellung muss hier eine Unterst¨ utzung bieten. Da die u ur einzel¨blicherweise benutzte 8-Bit-Codierung f¨ ne Buchstaben oft nicht ausreicht, wurde der Unicode, eine 16-Bit-Codierung, zur Unterst¨ utzung der multilingualen Textbearbeitung eingef¨ uhrt. 24

beispielsweise Fingerabdruck oder Irisbild

190

5. Informations- und Kommunikationstechnik

Die Darstellung des Datums und der Uhrzeit sollte in einer unverwechselbaren Form erfolgen. Abweichend hiervon sind Darstellungen m¨oglich, die am Standort des Betreibers u uche k¨onnen in der Punkt- oder ¨ blich ist. Dezimalbr¨ ¨ Kommanotation dargestellt werden. Ublicherweise wird die standort¨ ubliche Darstellung gew¨ ahlt. Die physikalischen Gr¨ oßen – wie beispielsweise Gewicht oder Abmessungen – sollten dem internationalen Standard (MKS-System: Meter, Kilogramm, Sekunde) entsprechen. Umrechnungen zwischen unterschiedlichen Gr¨ oßen sollten im Bereich der Identiﬁkation durch geeignete Funktionen m¨oglich sein. Neuere Programmiersprachen unterst¨ utzen die Internationalisierung durch entsprechende Datentypen und Bibliotheken. 5.3.5 Hilfesysteme und Hilfsdienste Zur Unterst¨ utzung der Bediener existieren Handb¨ ucher, die jedoch meist nicht f¨ ur den operativen Betrieb, sondern zu Schulungszwecken genutzt werden. Zur Unterst¨ utzung k¨ onnen diese Handb¨ ucher auch online verf¨ ugbar gemacht werden (vgl. Abb. 5.16), was auch eine Suche u ¨ber den Inhalt, u ¨ ber Stichworte und u ¨ ber den gesamten Text (Volltextsuche) erm¨oglicht. Wichtiger als die Online-Handb¨ ucher ist jedoch eine kontextsensitive Hilfe, die abh¨ angig von der gerade ausgef¨ uhrten Funktion einen kurzen Hinweis geben soll. Insbesondere sind die Anzeige der m¨oglichen Eingabewerte oder Wertebereiche hilfreich. Adaptive Verfahren k¨onnen abh¨angig von der Vorgeschichte des Bedienerdialoges gezielte Hinweise geben. Adaptive Hilfesysteme werden heute kaum oder nur in einer sehr rudiment¨aren Form eingesetzt. H¨ auﬁg wird stattdessen bei mehrfachen Fehleingaben immer ein festes Vorgehen, das oft in einem Verweis auf das Online-Handbuch besteht, einprogrammiert. Zus¨ atzliche Hilfsdienste k¨ onnen von Fall zu Fall sinnvoll sein: • elektronische Notizzettel als Ersatz f¨ ur ﬂiegende Zettel“ ” • innerbetriebliches elektronisches Mailsystem mit einer direkten Kopplung zum WMS • arbeitsplatzbezogene To-do-Listen zur schicht¨ ubergreifenden Kommunikation • arbeitsplatzbezogene Kalender f¨ ur die Erfassung von Wartungsterminen und die Ank¨ undigung außergew¨ ohnlicher Ereignisse

5.4 Betriebssysteme Ein Betriebssystem ist ein Programm eines Computersystems, das alle Komponenten verwaltet und steuert sowie die Ausf¨ uhrung von Programmen veranlasst. Es stellt eine Abstraktionsschicht dar, die den direkten Zugriﬀ von Anwenderprogrammen auf die Hardware eines Rechners vermeidet und ihre gesamten Aktivit¨ aten koordiniert.

5.4 Betriebssysteme

191

Abbildung 5.16. Beispiel eines Online-Hilfesystems [Foto: VANDERLANDE INDUSTRIES]

Mit dem Begriﬀ Betriebssystem (BS) werden seit dem Aufkommen der Personal Computer Anfang der 80er Jahre oft Eigenschaften des Dateisystems, Netzwerkf¨ ahigkeiten und insbesondere Konzepte der Bedienoberﬂ¨ache assoziiert. Ein Betriebssystem beinhaltet aber viele weitere elementare Funktionen, die einem Anwender meist verborgen bleiben. Die Kenntnis der grunds¨ atzlichen Prinzipien eines Betriebssystems ist f¨ ur das gesamte Gebiet der IT-Systeme sinnvoll. In diesem Abschnitt werden die Grundprinzipien der Betriebssysteme kurz erl¨ autert. Die darauf aufbauenden Funktionen, wie beispielsweise netzwerkf¨ ahige Dateisysteme und Bedienoberﬂ¨achen, werden in getrennten Abschnitten behandelt. 5.4.1 Aufgaben Ein Betriebssystem bildet eine Softwareschicht, die Anwenderprogramme von dem direkten Zugriﬀ auf die Hardware abschirmt. Die Aufgaben eines Betriebssystems bestehen in der Bereitstellung von Betriebsmitteln (Resources) und Diensten (Services) unter Nutzung der Hardware. Beispiele f¨ ur Betriebsmittel sind Drucker und Barcodeleser, aber auch der Speicherplatz auf einer Festplatte. Die Aufgaben eines Betriebssystems sind im Einzelnen: • Parallelbetrieb mehrerer Anwenderprogramme (Multiprogramming) • Realisierung von deﬁnierten zeitlichen Abh¨angigkeiten zwischen verschiedenen Anwenderprogrammen (Synchronisation)

192

5. Informations- und Kommunikationstechnik

• Zurverf¨ ugungstellung allgemein verwendbarer Programmbibliotheken (Bibliotheken, Libraries) • Bereitstellung eines einheitlichen Ein-/Ausgabe-Systems (virtuelles I/OSystem) • Bereitstellung einer Speicherverwaltung (virtueller Speicher ) • Schutz der Anwenderprogramme gegen Fehler in anderen Anwenderprogrammen • Unterst¨ utzung unterschiedlicher Benutzer mit benutzerspeziﬁschen Rechten und mit gegenseitigem Schutz (Multiuser ) Zusammenfassend k¨ onnen die Aufgaben eines Betriebssystems als Pr¨ asentation eines logischen Rechners (virtuelle Maschine) mit an” wendungsnahen Schnittstellen auf logisch hohem Niveau“ deﬁniert werden. Das Prinzip der virtuellen Maschine als Abstraktionsschicht zwischen Hardware und Anwenderprogrammen kann noch weiter verfeinert werden. So arbeiten viele der modernen Betriebssyteme mit einer so genannten Hardware-Abstraktionsschicht (HAL: Hardware Abstraction Layer), die es dem Hersteller eines Betriebssystems erleichtert, sein Produkt mit wenig Aufwand auf unterschiedliche Hardware zu portieren. 5.4.2 Prinzipien In diesem Abschnitt werden die grundlegenden Prinzipien und Komponenten von Betriebssystemen vorgestellt. Als weiterf¨ uhrende Literatur wird auf die zahlreichen B¨ ucher zum Thema BS – wie beispielsweise [49], [54] oder [82] – verwiesen. Eine wesentliche Grundfunktion jedes Betriebssystems ist die Verwaltung unterschiedlicher Hardware. Diese wird u ¨ blicherweise in folgende Kategorien eingeteilt: • Speicher (Hauptspeicher, Memory): der physische Speicher, in dem Daten und Programme zur Laufzeit abgelegt werden Die Hardware unterst¨ utzt eine dynamische Einteilung in Read-Only- und in Read-Write-Bereiche. Eine MMU (Memory Management Unit) u ¨berwacht den Read-Only-Bereich permanent auf schreibende Zugriﬀe, verhindert diese und l¨ ost bei Verletzung einen Interrupt aus, der dann das Betriebssystem veranlasst, das verursachende Programm zu beenden. Weitergehende Schutzmechanismen, die beispielsweise den Zugriﬀ auf Speicherbereiche anderer Programme verhindern25 , und die Zuteilung des Speichers an die Programme selbst m¨ ussen vom Betriebssystem bereitgestellt werden (s. S. 198). Ein bewusster, durch das Betriebssystem kontrollierter Zugriﬀ 25

Allein die M¨ oglichkeit des lesenden Zugriﬀs auf Speicherbereiche fremder Programme ist aus Sicht des Datenschutzes unbedingt zu vermeiden, s. Abschn. 5.6. Ein schreibender Zugriﬀ kann zu Sabotagezwecken missbraucht werden.

5.4 Betriebssysteme

193

Prozess i

Applikationen Prozess 1

Prozess 2

MultiuserUnterstützung

Prozess i1

Prozess i2

Bytepuffer (Pipe)

Nachrichtenpuffer

Betriebssystem Timer Virtuelle CPU

Virtueller Adressraum

CPU

Dateisystem

Gerätetreiber

Hauptspeicher (Memory)

Systembus

Hardware

i/o

Uhr

Grafik Interface Plattenspeicher Netzwerk i/o

Abbildung 5.17. Betriebssystem als Abstraktionsschicht zwischen der Hardware und den Applikationen

unterschiedlicher Programme auf den gleichen Speicherbereich sollte jedoch unterst¨ utzt werden (s. Abschn. 5.4.2). • Prozessoren (CPU, Central Processing Unit): Hier ﬁndet die Ausf¨ uhrung der im Speicher beﬁndlichen Programme statt. Neuere Hardware unterst¨ utzt mehrere CPUs, die vom Betriebssystem verwaltet werden m¨ ussen (s. S. 195). Moderne Prozessoren verf¨ ugen u ¨ber eingebaute Cache-Speicher, in denen h¨ auﬁg referenzierte Anweisungen und Daten f¨ ur einen schnellen Zugriﬀ zwischengespeichert werden. Die Leistungsf¨ahigkeit einer CPU wird oft durch die Anzahl der ausf¨ uhrbaren Instruktionen pro Zeiteinheit und durch eine Taktrate angegeben. Derartige Kennzahlen stellen aber nur einen Parameter f¨ ur die Beurteilung der Leistungsf¨ahigkeit einer Hardware dar. Diese ergibt sich aus dem Zusammenspiel aller Komponenten und ist f¨ ur die Beurteilung aus Sicht eines Betreibers ohne Ber¨ ucksichtigung der Betriebssystemeigenschaften und der Eigenschaften der Anwenderprogramme auch nicht aussagekr¨ aftig. Statt dessen setzt man Benchmarks26 26

Benchmarks sind in diesem Zusammenhang deﬁnierte Testl¨ aufe von ausgew¨ ahlten Programmen einer oder mehrerer Kategorien von Applikationen mit

194

5. Informations- und Kommunikationstechnik

ein, um die Leistungsf¨ ahigkeit f¨ ur eine Klasse von Einsatzf¨allen zu ermitteln. • Ger¨ ate (Devices): Hierunter werden folgende Ger¨ategruppen zusammengefasst: – Schnittstellen: Beispiele sind parallele und serielle Schnittstellen wie RS232 oder USB. – Netzwerk: Zugriﬀ auf lokale und/oder Weitverkehrs-Netzwerke zur Rechnerkommunikation u ¨ ber unterschiedliche Medien (s. Abschn. 5.1) – Massenspeicher: Massenspeicher mit wahlfreiem Zugriﬀ27 wie Festplatten, Disketten, CD-ROM und DVD, welche auf rotierenden Medien basieren, und solche, die keine mechanisch beweglichen Teile enthalten, wie beispielsweise Flash-Media-Karten Ein Kriterium f¨ ur die Klassiﬁzierung von Massenspeichern ist die Auswechselbarkeit der Speichermedien. Diese Eigenschaft ist insbesondere f¨ ur Archivierungen, aber auch f¨ ur den Import und den Export von Daten sowie f¨ ur die Anfertigung von Sicherungskopien sinnvoll (s. Abschn. 5.2.4). – Bildschirm: Bildschirme werden im Allgemeinen u ¨ ber so genannte GraﬁkKarten angesteuert. Hierbei handelt es sich um Subsysteme, die eine hohe Datenrate von der CPU empfangen. Auf diesen Daten k¨onnen die Graﬁk-Karten selbstst¨ andig komplexe Operationen ausf¨ uhren. Die Funktionsweise des Bildschirms ist aus der Sicht der Rechners nicht relevant. • Uhr (Clock): Die Uhr stellt ein spezielles Ger¨at dar, dem eine besondere Bedeutung zukommt. Sie l¨ ost zyklische Unterbrechungen (Interrupts) aus, die das Betriebssystem veranlassen, bestimmte Aufgaben (s. Abschn. 5.4.2 Uhren) zu erf¨ ullen. Zus¨ atzlich dient die Uhr der Bestimmung des aktuellen Datums und der aktuellen Zeit. Hierzu stellen Betriebssysteme weitere Dienste, welche die Zeitzonen und ggf. die Sommerzeit ber¨ ucksichtigen, Prozesse zeitgesteuert aktivieren (Timer) und die Rechneruhren in verteilten Systemen synchronisieren (s. Abschn. 5.1.6), zur Verf¨ ugung. Die Uhrenproblematik trat zur letzten Jahrtausendwende durch das so genannte Jahr-2000-Problem“ (y2k-Problem) in das Bewusstsein einer ¨” breiten Oﬀentlichkeit. Die Ursache dieses Problems lag in der 2-stelligen Darstellung der Jahreszahl und betraf fast ausschließlich die Software mit Ausnahme der Rechner, deren Hardwareuhren die Jahreszahl ebenfalls so darstellten. Neuere Hardwareuhren werden durch einen unstrukturierten Z¨ ahler dargestellt, dessen Wert die Anzahl von Zeiteinheiten darstellt, die seit einem bestimmten Basiszeitpunkt vergangen sind.

27

deﬁnierten Eingabedaten unter einem konkreten Betriebssystem auf einer speziﬁzierten Hardware. Ziele sind unter anderem die Ermittlung der Antwortzeiten und des mittleren Durchsatzes. Unter einem wahlfreien Zugriﬀ versteht man, dass ein Programm jederzeit die M¨ oglichkeit hat, auf einen beliebigen Datensatz“ auf diesem Medium zuzugrei” fen.

5.4 Betriebssysteme

195

Jedes Anwenderprogramm wird unter der Kontrolle eines Betriebssystems ausgef¨ uhrt und ist einem Prozess zugeordnet. Ein Prozess wird auch als Task bezeichnet und beinhaltet außer dem Anwenderprogramm auch Informationen u ¨ ber seinen aktuellen Zustand sowie den Ressourcenbedarf und die aktuelle Ressourcenzuteilung. Tasks k¨ onnen zeitlich sequenziell oder nebenl¨auﬁg ausgef¨ uhrt werden. Nebenl¨ auﬁgkeit bedeutet, dass eine zeitlich parallele Bearbeitung erfolgen kann, jedoch nicht zwangsweise muss. Diese zeitliche Parallelit¨ at kann auch nur f¨ ur einige Zeitintervalle erfolgen, streng zyklisch wechseln oder u ¨ber die gesamte Laufzeit einer Task vorliegen. Da diese zeitlichen Abl¨ aufe in einem dynamischen System mit nichtdeterministischen außeren Ereignissen nicht vorhersagbar sind, wird in diesem Zusammenhang ¨ der Begriﬀ der Nebenl¨ auﬁgkeit verwendet. WMS sind aus softwaretechnischer Sicht komplexe Systeme, die aus mehreren, teilweise nebenl¨ auﬁgen Tasks bestehen, die untereinander Daten austauschen, sich gegenseitig Dienste bereitstellen und ihren Programmﬂuss an deﬁnierten Stellen synchronisieren. In neuerer Zeit hat sich sowohl f¨ ur einzelne Anwenderprogramme als auch f¨ ur komplexere Programmsysteme der Oberbegriﬀ der Applikation etabliert. In diesem Sinne sind WMS Applikationen. Im Folgenden werden die Hauptaufgaben eines Betriebssystems – insbesondere im Zusammenspiel mit einer WMS-Applikation – detaillierter beschrieben. Steuerung der Betriebssystemprozesse Die Prozess-Steuerung muss folgende Aufgaben l¨ osen: • Wechselseitiger Ausschluss: Beim Zugriﬀ auf exklusive Betriebsmittel darf zu einer Zeit maximal ein Prozess auf dieses Betriebsmittel zugreifen. Als anschauliches Beispiel stelle man sich einen Drucker vor, auf den – ohne weitere Vorkehrungen – mehrere Prozesse nebenl¨auﬁg drucken. Um sinnvolle Ergebnisse zu erhalten, darf in einem solchen Szenario zu einer Zeit immer nur ein Prozess drucken – die Prozesse m¨ ussen sich wechselseitig ausschließen. Dieses Prinzip des wechselseitigen Ausschlusses wird dar¨ uber hinaus durchg¨ angig auf alle denkbaren exklusiven Ressourcen angewendet. Neuere Programmiersprachen bieten Sprachkonstrukte f¨ ur den Wechselseitigen Ausschluss an. • Synchronisation: Es muss sichergestellt sein, dass unter bestimmten Bedingungen ein Prozess in seiner Ausf¨ uhrung erst dann fortfahren kann, wenn er ein Signal erh¨ alt, das von einem anderen Prozess erzeugt werden muss. • Vermeidung von Deadlocks: Es muss verhindert werden, dass sich eine Menge von Prozessen bildet, von denen keiner fortfahren kann, ohne dass ein anderer aus dieser Menge fortfahren kann28 . Da die Deadlockproblematik 28

In der Literatur wird die Deadlockproblematik oft am Beispiel des so genannten Philosophenproblems“ diskutiert. ”

196

5. Informations- und Kommunikationstechnik

von grundlegender Bedeutung – nicht nur f¨ ur Betriebssysteme, sondern auch f¨ ur Datenbanken und dar¨ uber hinaus auch f¨ ur Materialﬂusssteuerungen – ist, wird in Abschn. 5.4.2 auf dieses Thema eingegangen. • Kommunikation: Ein Nachrichtenaustausch zwischen Prozessen, die so genannte Interprozesskommunikation, muss m¨oglich sein. Diese Kommunikation kann sich auf den Austausch von Signalen ohne eine zus¨atzliche Information beschr¨anken oder sie kann auch Inhalte in Form von Datens¨atzen enthalten. Dar¨ uber hinaus ist auch eine datenstromorientierte Kommunikation m¨ oglich, die einen unstrukturierten Zeichenstrom zwischen den Prozessen austauscht (s. Abschn. 5.1). Jeder Prozess beﬁndet sich zu jedem Zeitpunkt in einem der drei Zust¨ande rechnend“, rechenbereit“ oder blockiert“. Blockierte Prozesse warten auf ” ” ” Betriebsmittel, auf die Fertigstellung eines I/O-Auftrags oder auf ein TimerEreignis. Nach dem Ende der Blockade wird der Prozess in den Zustand re” chenbereit“ versetzt und bewirbt sich erneut um die CPU. Die Prozessorverwaltung regelt die Zuteilung der Prozesse an den Prozessor beziehungsweise an die Prozessoren und verwaltet dementsprechend die Prozesszust¨ande. Die blockierten Prozesse warten passiv, d.h. sie verbrauchen praktisch keine Rechenzeit. Das Betriebssystem verwaltet die Ereignisse, auf welche die blockierten Prozesse warten, und weckt“ diese nach dem Eintritt des ” Ereignisses. Das entgegengesetzte Prinzip ist das aktive Warten, bei dem ein Programm durch zyklische Abfragen einer Bedingung ein Ereignis detektiert. Dieses Prinzip wird Polling genannt und wird gelegentlich in Anwenderprogrammen verwendet, aber niemals in Betriebssystemen. Das Polling erfordert zwischen den einzelnen Abfragen immer eine Wartezeit τp , damit andere Prozesse Gelegenheit erhalten, ihr Programm weiter auszuf¨ uhren. Wird τp klein gew¨ ahlt, belastet der pollende Prozess die CPU zus¨atzlich, ohne eine Leistung zu erbringen. Wird τp gr¨ oßer gew¨ ahlt, steigt die Reaktionszeit, die im Mittel τp /2 betr¨ agt. Prozessorverwaltung Ein rechenbereiter Prozess bewirbt“ sich um die ” Ressource CPU. Das Verfahren, das die Zuteilung von Prozessen zu einer CPU bestimmt, nennt man Schedulingverfahren, den entsprechenden Programmteil eines Betriebssystems nennt man Scheduler. Im Allgemeinen ist die Zahl der Prozesse wesentlich gr¨ oßer als die Zahl der Prozessoren. Um dennoch alle Prozesse zu bearbeiten, wendet man das Prinzip des Multiplexing auf die CPUs an. Danach wird einem Prozess nach Ablauf einer gewissen Zeit (Zeitscheibe, Zeitquantum) die CPU entzogen und die frei gewordene CPU wird einem anderen Prozess zugeteilt. Falls f¨ ur das Scheduling der Ablauf einer Zeitscheibe das einzige Kriterium ist und wenn alle rechenbereiten Prozesse streng sequenziell eine CPU zugeteilt bekommen, spricht man auch von einem Round-Robin-Scheduler (RR) (s. Abb. 5.19). In der Praxis wird f¨ ur das Scheduling jedoch noch eine Vielzahl weiterer Kriterien genutzt. Eine fast in jedem Betriebssystem implementierte Schedu-

5.4 Betriebssysteme

197

rechenbereit i/o beendet

CPU-Zuteilung Zeitscheibe abgelaufen

blockiert

rechnend

i/o gestartet

Abbildung 5.18. Prozesszust¨ ande neue Prozesse

Warteschlange RR Scheduler

fertige Prozesse CPU

Abbildung 5.19. Prinzip eines Round-Robin-Schedulers

lingstrategie ordnet den Prozessen Priorit¨aten zu. Diese Priorit¨aten unterliegen dabei oft innerhalb gewisser Schranken einer Dynamik: Prozesse, die wegen einer Ein-/Ausgabe die CPU freigeben, steigen in ihrer Priorit¨at, bis sie eine vorgegebene Obergrenze erreicht haben. Nach dem Ablauf einer Zeitscheibe wird die Priorit¨ at schrittweise bis zu einer Untergrenze dekrementiert. Der Scheduler arbeitet immer die Prozesse mit der h¨ochsten Priorit¨atsklasse nach dem RR-Verfahren ab und dann die Prozesse der n¨achstniedrigeren Priorit¨ atsklasse. Wird ein Prozess mit einer h¨ oheren Priorit¨at rechenbereit, wird der gerade rechnende Prozess unterbrochen – d. h. er wird in den Zustand rechenbereit“ versetzt – und der Scheduler wird aktiviert. ” In einigen Betriebssystemen ist der Scheduler selbst ein Prozess mit einer hohen, aber festen Priorit¨ at. Damit unterliegen Prozesse, deren Priorit¨at h¨oher als die des Schedulers sind, nicht mehr dem RR-Verfahren und k¨onnen nur noch durch einen h¨ oherprioren Prozess unterbrochen werden. Prozesse mit einer derart hohen Priorit¨ at werden als Echtzeitprozesse bezeichnet. Diese kurze Darstellung einiger einfacher Scheduling-Verfahren zeigt, dass priorit¨ atsgesteuerte Scheduling-Verfahren eine Dynamik aufweisen, die sich – oft nach wesentlich komplexeren Algorithmen – an die aktuelle Systemlast ¨ anpassen. Die Anderung von Prozesspriorit¨ aten ohne eine tiefere System-

198

5. Informations- und Kommunikationstechnik Virtueller Speicher 1

Physischer Speicher

0

0

0

~ ~ ~ ~

32

2 -1

Virtueller Speicher 2

~ ~

227-1

~ ~

Auslagern

~ ~

Einlagern

~ ~

32

2 -1

Auslagerungsdatei (Festplatte) Verfügbare Seite

Ausgelagerte Seite

Ungenutzte Seite

Abbildung 5.20. Abbildung von 2 virtuellen Adressr¨ aumen auf den physischen Speicher am Beispiel eines 32-Bit-Rechners mit 128 MByte physischem Hauptspeicher

kenntnis ist kritisch. Die auf der einen Seite vermeintlichen Vorteile k¨onnen schwerwiegende Nachteile zur Folge haben. Speicherverwaltung Jeder Prozess verf¨ ugt u ¨ber einen separaten virtuellen Adressraum. Dieser wird vom Betriebssystem bereitgestellt und durch unterschiedliche Verfahren auf den physischen Speicher abgebildet. Das am h¨ auﬁgsten eingesetzte Verfahren hierzu nutzt den physischen Speicherplatz mehrfach, weswegen man auch von Speichermultiplexing spricht. Das heute u ¨ bliche Verfahren – das Paging-Verfahren – teilt hierzu den Speicher in gleichgroße so genannte Seiten (Pages) ein. Nichtbenutzte Seiten k¨onnen nach unterschiedlichen Algorithmen auf einen Hintergrundspeicher,

5.4 Betriebssysteme

199

einen Massenspeicher mit langsamerem Zugriﬀ, aber mit wesentlich gr¨oßerer Kapazit¨ at (das ist in der Praxis eine Festplatte) kopiert (ausgelagert ) werden. Hierdurch werden Bereiche des physischen Speichers f¨ ur andere Programme nutzbar. Wenn ausgelagerte Seiten ben¨ otigt werden, spricht man von einem Seitenfehler (Pagefault), der dazu f¨ uhrt, dass die ben¨otigten Seiten wieder in den Arbeitsspeicher kopiert (eingelagert ) werden. Zuvor m¨ ussen jedoch bei Bedarf andere Seiten in den Hintergrund kopiert werden, um f¨ ur die einzulagernden Seiten Platz zu schaﬀen. Die entsprechenden Algorithmen sind teilweise sehr aufw¨ andig und ber¨ ucksichtigen unter anderem auch die Zugriﬀsh¨auﬁgkeit auf einzelne Seiten und erstellen hieraus eine Prognose (s. z. B. [82]). Die auszulagernden Seiten werden in einer oder mehreren Dateien (Auslagerungsdatei, Pageﬁle 29 ) oder in einem oder mehreren unformatierten Bereichen der Festplatte30 (s. Abschn. 5.2.2) abgelegt. Um den Durchsatz durch Nebenl¨ auﬁgkeit zu erh¨ ohen, unterst¨ utzen viele Betriebssysteme die Verteilung der Auslagerungen auf unterschiedliche Laufwerke. Ein hoher Wert f¨ ur die Pagefaults je Zeiteinheit ist immer ein Indiz f¨ ur zu geringen Speicherausbau, w¨ ahrend eine zu kleine Auslagerungsdatei immer zu einer Fehlermeldung des Betriebssystems f¨ uhrt. Diese wird im Allgemeinen ¨ zuerst durch Warnungen bei Uberschreitung eines bestimmten F¨ ullgrades eingeleitet. Falls keine Maßnahmen ergriﬀen werden, sind folgende Szenarien m¨ oglich: • Das Betriebssystem suspendiert ganze Prozesse und lagert deren Speicherinhalte in einen eigenen Hintergrundspeicher-Bereich, das so genannte Swapﬁle aus. • Das Betriebssystem beendet zwangsweise einzelne Prozesse. • Das Problem wird ignoriert, was einen Deadlock (s. Abschn. 5.4.2) zur Folge hat. Die Auﬂ¨ osung eines solchen Deadlocks durch das Beenden eines Prozesses durch den Bediener ist oft nicht mehr m¨oglich, da hierzu zus¨atzlicher Speicher ben¨ otigt wird, der dann jedoch nicht mehr zur Verf¨ ugung steht. Ger¨ ate- und Ressourcenverwaltung Die Ger¨ateverwaltung beinhaltet auf unterer Ebene die zeitnahe Kommunikation mit der Hardware. Diese erfolgt u ¨ber Interrupts, die durch die Hardware ausgel¨ost werden, den Programmﬂuss unterbrechen und zu einer Interrupt-Service-Routine verzweigen. Diese u ¨ bernimmt dann die Bearbeitung des Interrupts, indem sie typischerweise mit dem anfordernden Ger¨ at Daten und Signale austauscht und an29

30

In einigen Systemen wird auch der Begriﬀ Swapﬁle verwendet, w¨ ahrend in anderen Systemen Swapﬁles nicht zum Paging, sondern zur Auslagerung ganzer Prozesse dienen. Festplatten werden meist in Partitionen aufgeteilt. Diese Partitionen k¨ onnen Dateisysteme enthalten oder als raw device ohne eine Formatierung von Applikationen oder von Datenbanken genutzt werden.

200

5. Informations- und Kommunikationstechnik

schließend die Kontrolle wieder an den bis zu diesem Zeitpunkt ruhenden Programmﬂuss zur¨ uckgibt. Auf der n¨ achsth¨ oheren logischen Ebene werden die Ger¨ate als Ressourcen oder als Betriebsmittel (BM) verwaltet. Ein Betriebsmittel muss nicht notwendigerweise ein physisches Ger¨ at sein. Logische oder virtuelle Betriebsmittel sind beispielsweise Kommunikationspuﬀer, gemeinsam von mehreren Prozessen genutzte Speicherbereiche oder Datenbanktabellen. Betriebsmittel werden im Allgemeinen durch Prozesse exklusiv genutzt, wenn schreibende Zugriﬀe erfolgen. Lesende Zugriﬀe f¨ uhren im Allgemeinen zu keinen Zustands¨ anderungen und sind deswegen in der Regel auch nebenl¨auﬁg m¨ oglich. Das Verfahren hierzu nennt man Wechselseitiger Ausschluss (mutual exclusion oder kurz mutex ). Die Zeitdauer, in der ein Betriebsmittel durch einen Prozess exklusiv belegt ist, nennt man auch einen kritischen Abschnitt (critical region). Prozesse, die in einen kritischen Abschnitt eintreten m¨ ochten, m¨ ussen zun¨ achst das zugeh¨ orige Betriebsmittel vom Betriebssystem anfordern. Ist es verf¨ ugbar, wird es in der Regel zugeteilt. Falls es nicht verf¨ ugbar ist, wartet der anfordernde Prozess auf die Verf¨ ugbarkeit. Die Betriebsmittelverwaltung weckt den Prozess, sobald das Betriebsmittel, auf das er wartet, wieder frei ist. Falls mehrere Prozesse auf ein bestimmtes Betriebsmittel warten, werden ihre Anforderungen in einer Warteschlange nach dem ﬁrst-come-ﬁrst-served-Prinzip (FCFS )31 verwaltet. Abweichungen vom strikten FCFS-Prinzip sind f¨ ur zeitkritische Prozesse oder f¨ ur Prozesse, die bereits viele weitere Betriebsmittel halten, m¨ oglich und sinnvoll. Deadlockproblematik In einem Umfeld, in dem der Wechselseitige Ausschluss gew¨ ahrleistet ist, die Prozesse unbeschr¨ankt auf die Verf¨ ugbarkeit von Betriebsmitteln warten und in dem keinem Prozess von außen zwangsweise Betriebsmittel entzogen werden k¨ onnen, besteht eine potenzielle Deadlockgefahr. Ein Deadlock ist eine Systemverklemmung, die nur durch einen erzwungenen Entzug von Betriebsmitteln (Preemption) oder durch das erzwungene Beenden von Prozessen gel¨ ost werden kann. Abbildung 5.21 zeigt eine typische Deadlocksituation mit Hilfe eines Resource-Allocation-Graphen. Prozesse und Betriebsmittel bilden die Knoten eines solchen Graphen, Betriebsmittelanforderungen und -zuteilungen werden durch Kanten dargestellt. Im zeitlichen Ablauf wird f¨ ur zwei Prozesse (P1 , P2 ) und f¨ ur zwei Betriebsmittel (BM1 , BM2 ) folgende Situation dargestellt:

31

Das ﬁrst-come-ﬁrst-served-Prinzip besagt, dass derjenige Prozess, der zuerst einen Betriebsmittelbedarf angemeldet hat, auch zuerst bei der Zuteilung dieses Betriebsmittels ber¨ ucksichtigt wird. Das entspricht dem FIFO-Prinzip, das auch im Materialﬂuss angewendet wird (Abschn. 2.2.3).

5.4 Betriebssysteme

201

BM1

t1+

Prozess1

t1

t2

t3

t4

Prozess2 t4+

BM2

Legende: BMi

BMi

Anforderung des BMi durch Prozessj

Zuteilung des BMi an Prozessj

Prozessj

Prozessj

Abbildung 5.21. Deadlocksituation im Resource-Allocation-Graphen

t1 t1 + Δ t2 t2 + Δ t3 t4

: : : : : :

P1 fordert BM1 an BM1 wird P1 zugeteilt P2 fordert BM2 an BM2 wird P2 zugeteilt P1 fordert BM2 an und muss warten P2 fordert BM1 an und muss warten

Zum Zeitpunkt t4 liegt nun ein Deadlock vor. Keiner der beiden Prozesse kann seine Arbeit fortsetzen, ohne auf den jeweils anderen zu warten. Eine andere Art der Darstellung des oben beschriebenen Szenarios bildet das Diagramm der Prozessfortschritte (s. Abb. 5.22). Es zeigt mit Hilfe einer Trajektorie, wie eine solche Situation entstehen kann, und es verdeutlicht auch, wie man sie vermeiden kann. Die beiden Achsen des Koordinatensystems stehen f¨ ur den Fortschritt der Prozesse P1 und P2 . Die Graphen, die in einem solchen Diagramm dargestellt werden, stellen die Fortschritte der beiden Prozesse dar und k¨ onnen mit dem Parameter t f¨ ur die Zeit beschriftet werden. Solche Graphen werden auch als Trajektorien bezeichnet. Unter der Voraussetzung, dass Preemption (s.o.) nicht erlaubt ist, enthalten diese Graphen niemals eine Komponente in negativer Achsenrichtung. Bei einem Ein-Prozessor-System bilden sie immer aufsteigende Treppenkurven. Der Betriebsmittelbedarf f¨ ur die beiden Prozesse ist an den Achsen aufgetragen. Damit der wechselseitige Ausschluss gew¨ahrleistet ist, darf eine Trajektorie niemals das dunkelgrau dargestellte Gebiet schneiden. Unter diesen Voraussetzungen wird der Deadlock unvermeidlich, wenn das untere linke Teilgebiet – die unsicheren Zust¨ande – erreicht wird. Hier setzen die Verfahren der Deadlockvermeidung an, die von Betriebssystemen und teilweise auch von Datenbanken genutzt werden.

202

5. Informations- und Kommunikationstechnik BM2

Fortschritt Prozess2

nicht erreichbare Zustände

BM1

BM1

t3

unsichere Zustände

t4

. .

BM2

.t

.t

2 Deadlock

1

wechselseitiger Ausschluss verletzt

Fortschritt Prozess1

Abbildung 5.22. Deadlocksituation in einem Diagramm der Prozessfortschritte

Eine Alternative zur Deadlockvermeidung ist Anforderung aller ben¨otigten Betriebsmittel als unteilbare Operation oder die Auﬂ¨osung eines Deadlocks durch Preemption. Werden alle ben¨ otigten Betriebsmittel bereits bei der ersten Anforderung auch nur eines Betriebsmittels angefordert und zugeteilt, wird im Allgemeinen der Durchsatz verringert, da andere Prozesse auf diese Betriebsmittel warten m¨ ussen. Ein Deadlock kann aber mit dieser Methode verhindert werden. Nach Preemption werden die bisher auf den betroﬀenen Betriebsmitteln ausgef¨ uhrten Operationen ung¨ ultig und m¨ ussen zu einem sp¨ ateren Zeitpunkt wiederholt werden. Die Folge ist ebenfalls ein sinkender Datendurchsatz. Die hier beschriebenen Zusammenh¨ ange sind auch auf Materialﬂusssysteme anwendbar. In Kapitel 7.4 wird ein Beispiellager vorgestellt, das ebenfalls deadlockgef¨ ahrdet ist. Durch den Einsatz geeigneter Algorithmen m¨ ussen auf dem Gebiet des Materialﬂusses Deadlocks vermieden werden. Ein Preemption ist bei diesen Anforderungen nicht sinnvoll und auch nicht immer m¨ oglich, da zum Abbruch von Transporten entsprechende R¨ ucktransporte m¨ oglich sein m¨ ussten. Uhren Die Hardwareuhr bildet die Basis f¨ ur • den Anstoß f¨ ur zyklisch auszuf¨ uhrende Betriebssystemfunktionen, wie beispielsweise das Scheduling, die dem Anwender verborgen bleiben, • die Bereitstellung von Weckdiensten (Timer) und f¨ ur • die Berechnung des aktuellen Datums und der aktuellen Zeit.

5.5 Programmiersprachen

203

Die Hardwareuhr eines Rechners unterliegt immer einer gewissen Drift. Daher muss die Uhrzeit gelegentlich aktualisiert werden. Das kann manuell durch einen Systemadministrator, durch Kopplung mit einer externen Referenzuhr oder durch ein Uhrenprotokoll (s. Abschn. 5.1.6) in einem Rechnernetz erfolgen. In einem laufenden System darf die Uhr nicht zur¨ uckgestellt werden, da das zu Verletzungen der Kausalit¨ at f¨ uhren k¨onnte. Falls absolute Zeiten in einem System verwendet werden, kann ein Zur¨ uckstellen der Uhr dazu f¨ uhren, dass eine Wirkung f¨ ur nicht beteiligte Prozesse scheinbar zeitlich vor ihrer Ursache liegt. Aus diesem Grund laufen Hardwareuhren bewusst geringf¨ ugig zu langsam. Ein solcher Eﬀekt tritt beispielsweise auf, wenn Applikationen das Er¨ stellungs- oder Anderungsdatum von Dateien als Kriterium f¨ ur deren Bearbeitung heranziehen. Bei der Softwareentwicklung werden durch das ma” ke“-Kommando alle Programme u ¨ bersetzt, deren Dateien vor dem letzten erfolgreich ausgef¨ uhrten make“-Aufruf erstellt oder ge¨andert wurden. Falls ” w¨ ahrend der Entwicklungsarbeiten die Uhr zur¨ uckgestellt wurde, kann das zu ¨ einer nur teilweisen Ubersetzung der Programme f¨ uhren. Die Folge sind meist nicht kompatible Ergebnisse und damit gar nicht oder fehlerhaft arbeitende ¨ Programme. Ahnliche Eﬀekte k¨ onnen auch in WMS auftreten, wenn Zeitpunkte als Kriterium f¨ ur die Durchf¨ uhrung einzelner Bearbeitungsschritte herangezogen werden. Falls eine Uhr dennoch zur¨ uckgestellt werden muss, kann diese Problematik durch Einf¨ uhrung einer Softwareuhr gel¨ ost werden. Eine Softwareuhr basiert immer auf einer Hardwareuhr, verf¨ ugt aber zus¨atzlich u ¨ ber eine OﬀsetVariable zur Korrektur der Zeit. Ein Zur¨ uckstellen der Uhr kann jetzt dadurch erreicht werden, dass die Softwareuhr langsamer l¨auft, d.h. der Oﬀset wird durch das Auslassen einzelner Ticks langsamer erh¨oht, so dass die Softwareuhr zwar langsamer, aber niemals r¨ uckw¨ arts l¨auft. Die Problematik wird in vernetzten Systemen durch den Einsatz von Uhrenprotokollen gel¨ost.

5.5 Programmiersprachen Programmiersprachen dienen zur Umsetzung der logischen Konzepte in ausf¨ uhrbare Programme. Sie stellen ein Bindeglied zwischen dem Programm P eines Programmierers und der Maschine M , auf der das Programm ausgef¨ uhrt werden soll, dar. Der Begriﬀ der Maschine“ ist hier nicht mit der ” Hardware gleichzusetzen, da das Betriebssystem eine virtuelle Maschine ist, die zur Ausf¨ uhrung von Programmen bereitgestellt wird32 . Jedes Programm verarbeitet Eingaben E und erzeugt Ausgaben A. Diese Ausgaben k¨onnen wiederum Eingaben f¨ ur ein anderes Programm sein. 32

Das Betriebssystem ist zwar auch ein Programm, aber es verbirgt die Hardware f¨ ur die hier zu besprechenden Anwendungsprogramme.

204

5. Informations- und Kommunikationstechnik

¨ 5.5.1 Ubersetzer und Interpreter In diesem Abschnitt werden die wichtigsten Konzepte kurz vorgestellt und einige Begriﬀe deﬁniert. F¨ ur den Betreiber einer Applikation k¨onnte die Programmiersprache, in der sie geschrieben wurde, von untergeordneter Bedeutung sein, solange der Lieferant die korrekte Funktion gew¨ahrleistet und ¨ f¨ ur Anderungen, Erweiterungen und Portierungen auf eine andere Hardware verf¨ ugbar ist. Sobald dieser Fall jedoch nicht gegeben ist oder wenn Drittanbieter beteiligt werden sollen – oder beteiligt werden m¨ ussen –, gewinnt die Wahl der Programmiersprache an Bedeutung. Die T-Diagramme (s. Abb. 5.23) sind eine Art der graphischen Darstellung dieser Zusammenh¨ ange [84]. Zur Laufzeit ben¨otigt jedes Programm eine Maschine, die den Programmcode ausf¨ uhren kann. In den seltensten F¨allen stehen Maschinen zur Verf¨ ugung, die den Programmcode direkt verarbeiten k¨onnen. Es gibt zwei L¨ osungen f¨ ur dieses Problem: ¨ • Mit Hilfe eines Ubersetzers wird der Programmcode in diejenige Sprache u uhren kann. Das zu u ¨bersetzt, welche die Maschine ausf¨ ¨ bersetzende Programm nennt man Quellprogramm oder Sourcecode, das Ergebnis einer ¨ solchen Ubersetzung ist der Maschinencode, der von einer Maschine ausgef¨ uhrt werden kann. Man unterscheidet zwischen folgenden Typen von ¨ Ubersetzern: – Assembler sind strukturerhaltend, d.h. die Programme werden in einer zwar menschenlesbaren Form, jedoch in den Strukturen, welche die ausf¨ uhrende Maschine verarbeiten kann, geschrieben. Die Programme werden in diesem Fall in einer Assembler-Sprache geschrieben und durch einen Assembler in die Maschinensprache u ¨ bersetzt. Diese Art der Programmentwicklung hat f¨ ur die Erstellung von Anwendungsprogrammen heute keine Bedeutung mehr, wird aber noch bei hardwarenahen Entwicklungen eingesetzt. ¨ – Compiler sind Ubersetzer, die die Strukturen des zu u ¨ bersetzenden Programms nicht erhalten (s. Abb. 5.25). Diese Strukturtransformation gibt dem Compiler die M¨ oglichkeit, umfangreiche Optimierungen durchzuf¨ uhren. Die Ziele dieser Optimierungen sind kleine Programme mit wenig Speicherbedarf und kurzen Ausf¨ uhrungszeiten. Aufgrund der Stukturtransformation ist der Kompilierungsprozess nicht umkehrbar. ¨ Das bedeutet, dass f¨ ur sp¨ atere Anderungen der Progammlogik immer das Quellprogramm verf¨ ugbar sein muss. Die meisten Hersteller von WMS liefern die Quellprogramme gar nicht oder nur teilweise aus. Eine vollst¨ andige Auslieferung erfolgt in den Open-Source-Projekten. – Makroexpander oder Makroprozessoren sind Textersetzungssysteme, die dazu dienen, h¨ auﬁg ben¨ otigte Programmteile durch parametrierbare Textbausteine, die Makros, zu ersetzen. Ein Makroprozessor ersetzt die formalen Parameter der Makros durch die aktuellen Parameter des Makro-Aufrufes. Anwendungsprogramme werden nicht durch Makro-

5.5 Programmiersprachen

Input I

Program P

205

Output O

Code M Interpreter M

I

P

O

M M

Abbildung 5.23. Darstellung eines T-Diagramms. Ein Programm P wird auf der Maschine M ausgef¨ uhrt. Es liest Eingabedaten E und erzeugt Ausgabedaten A.

Code M1

Machine M1

Abbildung 5.24. Interpreter als virtuelle Maschine. Ein Interpreter arbeitet auf einer Wirtsmaschine M1 und f¨ uhrt ein Programm P , das in der Sprache M existiert, aus.

sprachen programmiert, aber einige Programmiersprachen setzen Ma¨ kros ein. Vor der eigentlichen Ubersetzung durch den Compiler erfolgt 33 ein getrennter Pass , in dem die Makros expandiert werden. Das dient einerseits der Reduzierung der Schreibarbeit, verdeckt aber andererseits Schw¨ achen der Programmiersprache (s. [51]). • Der Programmcode wird mit Hilfe eines Interpreters direkt ausgef¨ uhrt. Ein Interpreter ist ein Programm, das auf einer Wirtsmaschine ausgef¨ uhrt wird und die Anweisungen eines Anwenderprogramms interpretiert und ausf¨ uhrt (s. Abb. 5.24). In diesem Sinne stellen Interpreter virtuelle Maschinen dar, welche die Eigenschaften der Wirtsmaschine gegen¨ uber dem Anwendungsprogramm verbergen. F¨ ur die Erstellung von Anwendungsprogrammen werden Compiler und Interpreter sowohl alternativ als auch erg¨ anzend eingesetzt. Die beiden zugrunde liegenden Prinzipien haben ihre speziﬁschen Vor- und Nachteile: • Ein Interpreter erlaubt die sofortige Ausf¨ uhrung eines Programms, ohne dieses zuerst u ussen. Die Ausf¨ uhrungszeiten sind bei Einsatz ¨bersetzen zu m¨ eines Interpreters gr¨ oßer als bei compilierten Programmen. • Compiler analysieren das zu u ¨ bersetzende Programm zur Compilezeit, Interpreter aber erst zur Laufzeit, d.h. zur Zeit der Ausf¨ uhrung des Programms. Diese Analyse kann aber auch syntaktisch fehlerhafte Programmteile – also Programme mit fehlerhaftem Satzbau – erkennen. Eine solche 33

Pass bezeichnet eine Bearbeitung des kompletten Programmcodes durch ein Programm. Compiler arbeiten u ¨ blicherweise mit mehreren nacheinander ausgef¨ uhrten Passes wie beispielsweise Syntaxanalyse, Codegenerierung und Codeoptimierung.

206

5. Informations- und Kommunikationstechnik

Program P

Program P Language

Language L

Code Compiler

L

M

Code M

Input I

Program P

Code M

Code M

Machine M

Machine M

Output O

¨ Abbildung 5.25. Ubersetzung eines Programms P , das in der Quellsprache S geschrieben wurde, in die Zielsprache M durch einen Compiler, der auf einer Maschine M l¨ auft. Das so erzeugte Zielprogramm wird dann auf einer Maschine M ausgef¨ uhrt.

Analyse erst zur Laufzeit durchzuf¨ uhren w¨ urde bedeuten, dass ein Potenzial der Programmiersprachen unzureichend genutzt wird. • Compilierte Programme sind nicht portabel. Ein Anwendungsprogramm ist somit nur auf dem Rechner und unter dem Betriebssystem ausf¨ uhrbar, f¨ ur das es kompiliert wurde. Diese Bindung beinhaltet h¨auﬁg sogar noch die Version des Betriebssystems. Um ein Programm auf einem anderen Rechner betreiben zu k¨ onnen, sind also mindestens das Quellprogramm und ein geeigneter Compiler erforderlich, w¨ ahrend ein Programm auf jedem Rechner ausgef¨ uhrt werden kann, auf dem ein entsprechender Interpreter verf¨ ugbar ist. Eine Synthese aus den Prinzipien der Kompilierung und der Interpretation bildet einen guten Kompromiss zwischen Ausf¨ uhrungsgeschwindigkeit, Compilezeitanalyse und Portabilit¨ at. Das Quellprogramm wird durch einen Compiler in eine maschinenunabh¨ angige Zwischensprache u ¨ bersetzt, die dann auf allen Rechnern ausgef¨ uhrt werden kann, die u ber einen entsprechenden ¨ Interpreter verf¨ ugen. Das bekannteste nach diesem Konzept arbeitende Programmiersystem ist Java. Ein in Java geschriebenes Quellprogramm wird mit einem JavaCompiler in den so genannten Bytecode, einen von der Hardware und von einem Betriebssystem unabh¨ angigen Bin¨ arcode u ¨bersetzt (s. Abb. 5.26). Damit werden alle lexikalischen, alle syntaktischen und einige semantische Fehler (s. Abschn. 5.5.2) bereits zur Compilezeit entdeckt. Dar¨ uber hinaus kann der Compiler bereits Optimierungen durchf¨ uhren. Der so erzeugte Bytecode ist sehr kompakt und wird zur Laufzeit durch eine virtuelle Java-Maschine (VM ) interpretiert. Dieses Konzept eignet sich zum Aufbau verteilter Applikationen.

5.5 Programmiersprachen Program WMS

Program WMS

Language Language Java

207

Compiler Java

Code Code Bytecode Bytecode

Input I

Code Mo

Machine Mo

Program WMS

Output O

Input I

Program WMS

Code Bytecode

Code Bytecode

Interpreter Java-VM

Interpreter Java-VM

Code M1

Code M2

Machine M1

Machine M2

Output O

¨ Abbildung 5.26. Ubersetzung eines in Java geschriebenen WMS auf der Maschine M in Bytecode. Dieser portable Bytecode kann durch einen Interpreter (virtuelle uhrt werden. Maschine) wahlweise auf der Zielmaschine M1 oder M2 ausgef¨

5.5.2 Sprachkonzepte Programmiersprachen werden durch • ihre lexikalischen Elemente, • ihre syntaktische Struktur und durch • ihre Semantik beschrieben. Die lexikalischen Elemente bilden die atomaren Einheiten, die Buchsta” ben“ des Quellprogramms. Hierunter versteht man beispielsweise Schl¨ usselw¨ orter, numerische Konstanten, Zeichenketten mit einem festen Inhalt, Operatoren sowie Bezeichner f¨ ur Variablen und Funktionen. Die syntaktische Struktur beschreibt den Satzbau“ eines Programms und ” wird formal durch eine rekursive Deﬁnition, durch die Backus-Naur-Form (BNF ) oder eine der BNF ¨ ahnlichen Notation oder durch Syntaxdiagramme beschrieben. Syntaktische Einheiten werden durch Grammatiksymbole repr¨ asentiert. Die Speziﬁkation der Syntax einer Programmiersprache besteht aus einer Menge von Regeln, deren linke Seite immer genau aus einem Grammatiksymbol und deren rechte Seite aus einer Folge von Grammatiksymbolen und lexikalischen Symbolen besteht. Syntaxdiagramme sind eine anschauliche Art der graphischen Darstellung dieser Regeln durch Rechtecke und Kreise bzw. abgerundete Rechtecke. Die BNF sieht im Gegensatz zu den Syntaxdiagrammen auf der rechten Seite zur Vereinfachung der Darstellung spezielle Operatoren und Symbole vor. Optionale Symbole oder Symbolfolgen werden in eckige Klammern gefasst. Geschweifte Klammern dr¨ ucken aus, dass die eingeschlossene Symbolfolge iterativ ist und damit mehrmals hintereinander in einem Programm auftreten darf (s. Abb. 5.27).

208

5. Informations- und Kommunikationstechnik

Abbildung 5.27. Darstellung der syntaktischen Regeln einer Programmiersprache durch rekursive Deﬁnitionen in der Pfeil“-Notation und durch die Backus-Naur” Form auf der linken Seite. Dem stehen entsprechende Syntaxdiagramme auf der rechten Seite gegen¨ uber.

Die Semantik einer Programmiersprache wird in der Regel f¨ ur die Programmierer verbal beschrieben. Ein Beispiel f¨ ur die Semantik ist die Einhaltung von Signaturen, d.h. bei der Deﬁnition und beim Aufruf einer Funk-

5.5 Programmiersprachen

209

tion m¨ ussen die Anzahl und die Typen der Parameter mit der Deklaration u ¨bereinstimmen. 5.5.3 Sprachgenerationen Die Programmiersprachen k¨ onnen nach unterschiedlichen Kriterien kategorisiert werden. Hier folgt die Einteilung in Generationen: 1. Erste Generation: Hierunter versteht man die Maschinensprachen, also die Sprachen, welche die Hardware der Rechner direkt ohne eine vorherige ¨ Ubersetzung und ohne den Einsatz von Interpretern ausf¨ uhren kann. 2. Zweite Generation: Die Assemblersprache entspricht strukturell den Sprachen der ersten Generation, erleichtert den Programmierern durch die Nutzung mnemonischen Codes – das sind Klartextbezeichner f¨ ur Anweisungen und Speicheradressen – die Programmierung. Vor der Ausf¨ uhrung ¨ ist immer eine Ubersetzung durch einen Assembler erforderlich. 3. Dritte Generation: Die problemorientierten Programmiersprachen werden oft auch als h¨ ohere Programmiersprachen bezeichnet und k¨onnen – je nach Art der Sprache und der Verf¨ ugbarkeit der Interpreter und Compiler – entweder direkt interpretiert oder m¨ ussen vorher u ¨ bersetzt werden. 4. Vierte Generation (4GL: 4th Generation Language): Programme werden weitgehend nat¨ urlichsprachlich geschrieben. Die erforderlichen Datenstrukturen und Algorithmen werden von einem Compiler und/oder Interpreter erzeugt oder ausgew¨ ahlt. Ein typischer Vertreter f¨ ur eine 4GL-Sprache ist SQL, die f¨ ur Datenbankabfragen und -manipulationen verwendet wird. Key-Value-Coding XML benutzt das so genannte Key-Value-Coding, das in Analogie zu einem W¨ orterbuch zu jedem Schl¨ ussel einen oder mehrere zugeordnete Werte repr¨ asentiert. Insbesondere bedeutet dies, dass niemals ein Wert ohne einen zugeh¨ origen Schl¨ ussel vorkommen kann. Die Existenz eines Schl¨ ussels, zu dem es keinen Wert gibt, ist andererseits gestattet und kann sogar sehr sinnvoll sein. Als Erweiterung des reinen Key-Value-Codings erlaubt XML die Mehrfachnennung eines Schl¨ ussels. Die Key-Values eines XML-Dokuments werden in Elementen zusammengefasst, der jeweilige Key wird als Elementname und der Value als Elementinhalt innerhalb der Elementtags 34 geschrieben. Der Elementname bildet in spitzen Klammern das Starttag, das das Element einleitet. Darauf folgt der 34

tag engl. f¨ ur auszeichnen, hervorheben. Als tag bezeichnet man hier die Zeichensequenz, die dem Element seinen Namen gibt.

210

5. Informations- und Kommunikationstechnik

Elementinhalt und abschließend das Endtag, das auch wieder in spitzen Klammern mit einem f¨ uhrenden Schr¨ agstrich den Elementnamen wiederholt. Als Inhalte von Elementen k¨ onnen weitere Elemente vorkommen. Soll beispielsweise ein Lagerartikel, hier eine Dose Erbsen, durch XML beschrieben werden, dann k¨ onnte das wie folgt geschehen, wobei die Eigenschaften des Artikels durch den Starttag <artikel> und den Endtag begrenzt werden: <artikel> <ean>401234500001 Erbsen <menge>850 <einheit>ml Dose Alternativ erlaubt XML die Benutzung von Attributen, die mit den Eigenschaften eines Elementes versehen werden. Die Werte von Attributen m¨ ussen paarweise durch Hochkommata oder Anf¨ uhrungsstriche eingeschlossen werden. Hat ein Element keinen Inhalt, kann auf das Endtag verzichtet werden, wenn als letztes Zeichen vor der schließenden spitzen Klammer ein Schr¨ agstrich geschrieben wird; man spricht dann nicht mehr vom Start- und Endtag, sondern vom EmptyElementTag. Dann kann der Artikel aus obigem Beispiel wie folgt beschrieben werden: <artikel ean="401234500001" name="Erbsen" menge="850" einheit="ml" verpackung="Dose" /> Werden bei der Benennung der Elemente und deren Attribute mnemonische (selbsterkl¨ arende) Namen verwendet, kann mit XML eine selbstdokumentierende Art der Beschreibung von Datenstrukturen erreicht werden. Obiges Beispiel des Artikelelementes f¨ uhrt an, dass es sowohl die M¨oglichkeit der Benutzung von Subelementen als auch die der Bildung von Attributen zu Elementen gibt. Es ist auch eine Mischung dieser beiden Verfahren m¨ oglich. Dies verdeutlicht das nachfolgenden Beispiel zur Beschreibung eines Kunden. Durch die Wahl selbsterkl¨ arender Element- und Attributbenennungen muss es nicht weiter beschrieben werden :
5.5 Programmiersprachen

211

ort="Dortmund" plz="44227"/> +49-231-21282 +49-231-56080 Auf diese Art gebaute XML-Dokumente, also Dokumente, die zu einem Element ein Starttag und ein Endtag (in richtiger Reihenfolge und richtiger Verschachtelung) oder nur ein ElementEmptyTag haben, und bei denen sowohl das Start- als auch das ElementEmptyTag Attribute nach obiger Art benutzen, werden wohlgeformt oder zul¨ assig genannt. Nachfolgend ein Beispiel f¨ ur ein unzul¨ assiges XML-Dokument: Allgemein kann festgestellt werden, dass richtig angewandtes XML durch die Technik des Key-Value-Codings viele Vorteile bietet. Neben der schon erw¨ ahnten m¨ oglichen Selbstdokumentation sei besonders noch die Reihenfolgenunabh¨ angigkeit der einzelnen Elemente (und auch die ihrer Attribute) genannt. Ein weiterer Vorteil besteht darin, dass optionale Felder einfach weggelassen werden k¨ onnen. Die Syntax von XML Mit Hilfe der DTD, der Document Type Deﬁnitions oder durch die Benutzung von Schemata lassen sich XML-Dokumente beschr¨anken. Eine solche Beschr¨ ankung ist wichtig zur Validierung dieser Dokumente. W¨ahrend die Zul¨ assigkeit (oder Wohlgeformtheit) eines XML-Dokumentes aus seinem Aufbau, also aus dem korrekten Umgang mit den Elementen, unabh¨angig von seinen Inhalten sofort ersichtlich ist, entscheidet das Schema oder die DTD u ¨ ber ¨ die G¨ ultigkeit des Dokumentes durch Uberpr¨ ufung der Existenz bestimmter und Nichtvorkommen anderer Elemente sowie die Einhaltung vorgeschriebener Verschachtelungen. Das nachfolgende Beispiel zeigt eine DTD f¨ ur das obige Beispiel des Kundenelements. Das Element kunde setzt sich dabei aus mindestens einem adresse- und beliebig vielen telefon-Elementen zusammen, wobei adresse aus einem ElementEmptyTag und telefon aus einem Start- und einem Endtag besteht:

212

5. Informations- und Kommunikationstechnik

kunde (adresse+,telefon*)> adresse EMPTY> telefon (#PCDATA)> kunde CDATA #REQUIRED CDATA #REQUIRED CDATA #IMPLIED CDATA #IMPLIED > adresse (liefer|rechnung) "rechnung" CDATA #REQUIRED CDATA #REQUIRED CDATA #REQUIRED > telefon (arbeit|mobil|privat) "privat" >

Bei der Benutzung von DTDs ist Vorsicht geboten. Die obige Deﬁnition schließt nicht aus, dass telefon mit dem Attribut typ=“privat“ mehrfach innerhalb eines Kundenelements vorkommt, oder dass telefon aus einem ElementEmptyTag besteht und gar keine Nummer beinhaltet. F¨ ur den letzteren Fall k¨ onnte die Telefonnummer als Attribut in telefon deﬁniert werden, die DTD verf¨ ugt allerdings u ¨ber keinerlei M¨oglichkeit, die Richtigkeit einer Telefonnummer zu u ufen; der Eintrag von jeder Art von Zeichen¨berpr¨ sequenzen als Telefonnummer w¨ are g¨ ultig. Die automatische Pr¨ ufung eingehender Dokumente auf einige Aspekte der formalen Korrektheit ist anhand von DTDs m¨oglich, aber aufw¨andig. Mit Hilfe von Schemata k¨ onnen auch Attribute und Elementinhalte einer weitergehenden Pr¨ ufung unterzogen werden. Bei Schnittstellen, die einen hohen Durchsatz an XML-Dokumenten leisten m¨ ussen, werden daher diese formalen Pr¨ ufungen m¨ oglicherweise nach einer Testphase von Hand optimiert oder auch ganz abgeschaltet. Der Gewinn gegen¨ uber propriet¨ ar vereinbarten Datenschnittstellen ist dennoch enorm. Eine XML-Schnittstelle ist u ¨ber die DTD oder das Schema sehr schnell zwischen den Entwicklern einer Kommunikations-Schnittstelle ausgehandelt. Ist die Beschreibung einmal verabschiedet, ist die Konformit¨at einer Nachricht reproduzierbar veriﬁzierbar. Die Schnittstellen k¨onnen einfach getestet und debugged35 werden, da die u ¨bertragenen Inhalte lesbar sind. Vielf¨ altigkeit durch Stylesheets Das in Abschn. 5.5.3 aufgezeigte Beispiel f¨ ur kunde k¨onnte innerhalb eines neuen Elements bestellung durch das Hinzuf¨ ugen eines weiteren Ele35

debugging engl. f¨ ur Fehlersuche; Fehler werden in der Fachsprache auch Bug genannt.

5.5 Programmiersprachen

213

mentes orderItem in eine Bestellung u uhrt werden. Das neue Element ¨ berf¨ orderItem baut dabei auf dem in Abschn. 5.5.3 vorgestellten artikel auf und erweitert diesen um preis und anzahl. Die zugeh¨orige DTD sieht dann wie folgt aus:
bestellung (kunde,orderItem+)> kunde ... > kunde ... > orderItem EMPTY> orderItem ean CDATA #REQUIRED name CDATA #REQUIRED menge CDATA #REQUIRED einheit CDATA #REQUIRED verpackung CDATA #REQUIRED preis CDATA #REQUIRED anzahl CDATA #REQUIRED >

Mittels obiger DTD k¨ onnen nun XML-Dokumente vom Typ bestellung validiert werden. Das nachfolgende Beispiel zeigt ein wohlgeformtes und g¨ ultiges XML-Dokument zu dieser DTD: Eine in XML formulierte Bestellung kann durch den Prozessor unter Zuhilfenahme eines geeigneten Stylesheets in ein anderes Format konvertiert werden. Das Ausgabeformat wird ausschließlich durch den Inhalt des Stylesheets bestimmt, so dass durch den Einsatz unterschiedlicher Stylesheets mit dem gleichem Prozessor und den gleichen Eingabedaten verschiedene Ergebnisse erzielt werden. Abbildung 5.28 zeigt beispielhaft zwei unterschiedliche Formatierungen einer Bestellung. W¨ ahrend der Prozessor durch das Stylesheet 1 das XMLDokument der Bestellung in ein SQL-Statement zur weiteren Verarbeitung f¨ ur die Datenbank konvertiert, wandelt der gleiche Prozessor (oder ein anderer) das XML-Dokument in eine HTML-Datei um, die durch einen Browser dargestellt werden kann.

214

5. Informations- und Kommunikationstechnik

DB

<customer title=`Ms´ name= `Marple´ surname=`Jane´ custno=`0042´> ean=`401234500001´ name=`peas´ packaging=`tin unit=`ml´ quantitye=`850´ price`0,74´ quantity=`03´ />

XML Processor

insert into order (custno. , ean , quantity, order date) values (`0042´ , `401234500001´, `3´ , sysdate);

Stylesheet1

XML Processor

Stylesheet2

Abbildung 5.28. Konvertierung eines XML-Dokumentes durch Einsatz von Stylesheets.

5.6 Sicherheitsaspekte Sobald ein Austausch sch¨ utzenswerter Daten u ¨ ber Rechnernetze erfolgt, m¨ ussen Sicherheitsvorkehrungen getroﬀen werden. Ziele sind die Sicherung der Vertraulichkeit, der Integrit¨ at der Daten, der Zurechenbarkeit der Daten zu einem Erzeuger oder Absender sowie die Verf¨ ugbarkeit der Daten. Die Schutzmechanismen m¨ ussen sowohl gegen die Auswirkungen zuf¨alliger Ereignisse als auch gegen gezielte Angriﬀe wirksam sein. Kryptographie ist bei der Sicherung der Vertraulichkeit, Integrit¨ at und Zurechenbarkeit das wichtigste Hilfsmittel. F¨ ur die Verf¨ ugbarkeit sind Diversit¨ at und Verteiltheit – beide Ziele sind u. a. durch den Einsatz von Sicherungskopien (s. Abschn. 5.2.4) erreichbar – sowie Fehlertoleranz die wichtigsten Mechanismen [81]. Neben dem Inhalt einer Kommunikation k¨onnen die Kommunikationsumst¨ ande ebenfalls sch¨ utzenswert sein. Die wichtigsten Aspekte sind Anonymit¨ at und Unbeobachtbarkeit der Kommunikationspartner. Das k¨onnen Personen, aber auch Rechner, Programme oder Betriebssystemprozesse sein. Die Anfertigung von Kommunikationsproﬁlen liefert Rohdaten, aus denen auch ohne oder mit nur partieller Kenntnis der Kommunikationsinhalte auf Lagerbewegungen, Kundenverhalten oder Umsatzzahlen geschlossen werden kann.

5.6 Sicherheitsaspekte

215

Insbesondere r¨ aumlich verteilte WMS und/oder WMS in Netzwerkumgebungen sind potenziell gef¨ ahrdet. E-Commerce-Systeme sind auf Abrechnungsverfahren angewiesen, deren Qualit¨ atsmerkmal Sicherheit eine entscheidende Rolle spielt. Am Beispiel eines E-Mail-Austausches werden in den folgenden Abschnitten die Prinzipien beschrieben. Sie k¨onnen leicht auf andere Szenarien in verteilten Applikationen u ¨bertragen werden. 5.6.1 Geheimhaltung ¨ Die Geheimhaltung von Nachrichten auf ihren Ubertragungswegen hat eine jahrtausendelange Tradition. In j¨ ungster Zeit wurden grundlegend neue Verfahren entwickelt, die sich auch f¨ ur hohe Sicherheitsanforderungen eignen. Sowohl die Geheimhaltung als auch die anderen Sicherheitsaspekte beruhen auf Verschl¨ usselung. Das Grundprinzip aller Verschl¨ usselungen basiert auf jeweils einem Algorithmus zur Verschl¨ usselung (Encryption) und zur Entschl¨ usselung (Decryption) unter Nutzung von Schl¨ usseln (Keys) (s. Abb. 5.29). Die Algorithmen und der Aufbau der Schl¨ ussel k¨onnen sehr unterschiedlich sein. Die Sicherheit der Verschl¨ usselung sollte aber in allen F¨allen durch die Sicherheit der Schl¨ ussel und nicht durch die der Algorithmen begr¨ undet sein. Die Nachricht M (Message) wird unter Nutzung des Schl¨ ussels K (Key) durch die Verschl¨ usselungsfunktion E 36 in die chiﬀrierte Nachricht MK u ¨ bersetzt. E(K, M ) → MK Symmetrische oder geheime Verschl¨ usselungsverfahren setzen den gleichen Schl¨ ussel f¨ ur die Ver- und Entschl¨ usselung ein. Das Hauptproblem dieses Verfahrens besteht in einem sicheren Schl¨ usselaustausch. Sender und ¨ Empf¨ anger ben¨ otigen hierzu einen getrennten Ubertragungskanal, da der f¨ ur den Nachrichtenaustausch genutzte Kanal ohne Verschl¨ usselung vorausset¨ zungsgem¨ aß unsicher ist. Eine Ubertragung in mehreren Teilen – m¨oglichst u ale – erh¨ oht die Sicherheit. ¨ber unterschiedliche Kan¨ Die Entschl¨ usselung erfolgt u ¨ber eine inverse Funktion E −1 , die mit Hilfe des gleichen Schl¨ ussels K die chiﬀrierte Nachricht MK in den Klartext M u ¨bersetzt37 . E −1 (K, MK ) → M oder:

E −1 (K, E(K, M )) = M

Wegen des aufw¨ andigen Schl¨ usselaustausches werden diese Verfahren den Anforderungen der elektronischen Kommunikation nicht mehr gerecht. 36 37

E steht symbolisch f¨ ur encryption. Die Funktionen E und E −1 k¨ onnen auch identisch sein. Ein Beispiel ist die bitweise XOR-Verkn¨ upfung der Nachricht mit dem Schl¨ ussel.

216

5. Informations- und Kommunikationstechnik Empfänger

Sender

Schlüssel e

Schlüssel d

Algorithmus e

Algorithmus d

Von ABC

Von ABC

Von ABC

Von ABC

An Fa. XYZ

An Fa. XYZ

An Fa. XYZ

An Fa. XYZ

Bestellung

Bestellung

Bestellung

Bestellung

500 Schrauben M3 € 10,23 250 Muttern M8 € 4,22 --------------------------------------Auftragswert € 14,45 ======================

500 Schrauben M3 € 10,23 250 Muttern M8 € 4,22 --------------------------------------Auftragswert € 14,45 ======================

500 Schrauben M3 € 10,23 250 Muttern M8 € 4,22 --------------------------------------Auftragswert € 14,45 ======================

500 Schrauben M3 € 10,23 250 Muttern M8 € 4,22 --------------------------------------Auftragswert € 14,45 ======================

Lieferstermin 12.Nov. 2003

Lieferstermin 12.Nov. 2003

Lieferstermin 12.Nov. 2003

Lieferstermin 12.Nov. 2003

Klartext

Geheimtext

Geheimtext

Klartext

Übertragungskanal

Abbildung 5.29. Grundprinzip der Verschl¨ usselung

Unsymmetrische Verschl¨ usselungsverfahren oder Verschl¨ usselungsverfahren mit ¨ oﬀentlichen Schl¨ usseln (public key) arbeiten mit unterschiedlichen Schl¨ usseln f¨ ur die Ver- und Entschl¨ usselung. Diese Verfahren unterscheiden zwischen einem Schl¨ ussel Ke , der auf der Senderseite, und einem Schl¨ ussel Kd , der auf der Empf¨ angerseite bekannt sein muss (s. [77]). Die Funktion zur Verschl¨ usselung E unterscheidet sich von der Funktion zur Entschl¨ usselung D. D(Kd , E(Ke , M )) = M Die Problematik des Schl¨ usselaustausches entf¨allt, da aus der Kenntnis von Ke nicht – mit einem praktikabel realisierbaren Aufwand – auf Kd geschlossen werden kann. Ein einfaches Beispiel ist ein Verfahren, das auf der Zerlegung einer ganzen Zahl in ihre Primfaktoren beruht: W¨ahrend die Berechnung des Produktes der Primfaktoren leicht m¨oglich ist, ist der umgekehrte Weg zwar m¨ oglich, aber mit einem erheblich h¨oheren Aufwand verbunden38 . Dieser Aufwand ist von der Gr¨oße der Zahl – also von der Schl¨ ussell¨ ange – abh¨ angig. Der Empf¨ anger erzeugt ein Schl¨ usselpaar (Ke , 38

Jede nat¨ urliche Zahl n kann als Potenz von Primzahlen P dargestellt werden: n = ki=1 Piei ; z. B. 1024 = 210 , 7007 = 72 × 111 × 131 Die Zerlegung in Primzahlen wird bei großen Zahlen sehr aufw¨ andig.

5.6 Sicherheitsaspekte

217

Kd ). Der private oder geheime Schl¨ ussel Kd bleibt im alleinigen Besitz des Empf¨ angers, w¨ ahrend der ¨ oﬀentliche Schl¨ ussel Ke allen potenziellen Sendern zug¨ anglich gemacht wird. Das erkl¨ art auch die oft verwendete Bezeichnung Public Key System. Der Sender verschl¨ usselt seine Nachricht nun mit dem oﬀentlich zug¨ anglichen Schl¨ ussel, sendet diese chiﬀrierte Nachricht durch den ¨ ¨ Ubertragungskanal an den Empf¨ anger, der mit Hilfe des privaten Schl¨ ussels wieder den Klartext erzeugt. Praktische Verfahren unterscheiden sich im Algorithmus, in der Schl¨ ussell¨ ange und im Verfahren der Schl¨ usselverteilung. Ein Beispiel ist das RSAVerfahren (von Rivest, Shamir und Adelman), das auf der oben erw¨ahnten Primzahlzerlegung basiert (s. [81]). Die L¨ ange des Schl¨ ussels ist unabh¨angig vom Algorithmus und bestimmt das Maß der erreichten Sicherheit. F¨ ur heute gebr¨ auchliche Schl¨ ussel mit 128 Bit L¨ ange ben¨otigt ein leistungsf¨ahiger Rechner mehrere Monate zur Primzahlzerlegung. Umgekehrt kann das Produkt der Primfaktoren mit wenigen Multiplikationen berechnet werden. Prinzipiell ist es m¨ oglich, KE aus KD zu berechnen. Der Aufwand hierzu – insbesondere die erforderliche Zeit – w¨ achst jedoch exponentiell mit der Schl¨ ussell¨ange, so dass hinreichend lange Schl¨ ussel immer die geforderte Sicherheit geben. Die Verteilung der ¨ oﬀentlichen Schl¨ ussel kann auf direktem Weg vom Sen¨ der zum Empf¨ anger durch unsichere Ubertragungskan¨ ale oder durch eine Ver¨ oﬀentlichung u ¨ ber zentrale Dienste erfolgen. Die unsymmetrischen Verfahren haben sich auf dem gesamten Gebiet der Sicherheitstechnik in oﬀenen Systemen durchgesetzt. 5.6.2 Integrit¨ atssicherung Eine Nachricht darf auf dem Weg vom Sender zum Empf¨anger nicht durch Dritte verf¨ alscht werden. Diese Integrit¨atssicherung sch¨ utzt vor den Angriﬀen Dritter. Beispielsweise k¨ onnten Bestellmengen, die letztlich in einem WMS ¨ zu Auslagerungen f¨ uhren, auf dem Ubertragungsweg ge¨andert werden. Die Folge k¨ onnte die Auslieferung des gesamten Bestandes sein, der dann f¨ ur zuk¨ unftige Auftr¨ age anderer Kunden – bis zur Kl¨arung des Vorfalles und einem eventuellen R¨ ucktransport – nicht mehr verf¨ ugbar w¨are. Das Ziel der Integrit¨ atssicherung kann durch den Einsatz von Verschl¨ usselungsverfahren erreicht werden. In einem System mit symmetrischen Schl¨ us¨ seln muss der Angreifer sowohl zum Lesen als auch zum Andern der Nachricht u ussel verf¨ ugen. Beim Einsatz unsymmetrischer Ver¨ber den geheimen Schl¨ fahren muss der Angreifer u ussel ¨ ber den geheimen und den ¨oﬀentlichen Schl¨ des Empf¨ angers verf¨ ugen. 5.6.3 Authentiﬁzierung usselung Die Integrit¨ at einer Nachricht kann durch den Einsatz von Verschl¨ gesichert werden. Beim Einsatz unsymmetrischer Schl¨ ussel kann Jeder mit

218

5. Informations- und Kommunikationstechnik

Hilfe des ¨ oﬀentlichen Schl¨ ussels eine Nachricht an dessen Eigent¨ umer absetzen und sich als jemand Anderes ausgeben. Beispielsweise ist es leicht m¨oglich, Bestellungen im Namen anderer Kunden an einen Lieferanten abzusetzen. Der Lieferant muss sich aber darauf verlassen k¨onnen, dass der Absender der Bestellung mit dem in der Bestellung Angef¨ uhrten identisch ist. Dieses Problem der Authentiﬁzierung kann ebenfalls durch den Einsatz unsymmetrischer Schl¨ ussel gel¨ ost werden. Es existiert eine Vielzahl von Authentiﬁkationsprotokollen (s. [55]), die entweder eine zentrale, vertrauensw¨ urdige Instanz oder die gegenseitige Kenntnis der ¨ oﬀentlichen Schl¨ ussel voraussetzen. F¨ ur den zweiten Fall folgt ein einfaches Beispiel mit den Teilnehmern A und B. A m¨ ochte mit B kommunizieren und f¨ ur die Dauer der Verbindung einen Sitzungsschl¨ ussel KS vereinbaren. Dieser Sitzungsschl¨ ussel muss nat¨ urlich u ur ¨ber einen sicheren Kanal ausgetauscht werden. Hierzu wird f¨ jeden Teilnehmer ein unsymmetrisches Schl¨ usselpaar (KEA , KDA ) f¨ ur A und (KEB , KDB ) f¨ ur B genutzt. Der Sitzungsschl¨ ussel ist nach dieser Authentiﬁzierungsprozedur nur den beiden Teilnehmern bekannt, die nun ein symmetrisches Verfahren mit diesem Schl¨ ussel einsetzen. Der Vorteil liegt in den wesentlich schnelleren Algorithmen, die bei symmetrischen Verfahren eingesetzt werden. 1. A w¨ ahlt eine Zufallszahl RA , verschl¨ usselt diese mit dem ¨oﬀentlichen Schl¨ ussel KEB von B. Das Resultat E(KEB , RA ) sendet A an B. 2. B entschl¨ usselt die Nachricht mit seinem geheimen Schl¨ ussel KDA . 3. Da nur der Besitzer dieses Schl¨ ussels in der Lage ist, die Nachricht zu decodieren, wird die von A gew¨ ahlte Zufallszahl zum Beweis“ an A ” zur¨ uckgesendet. Zus¨ atzlich erzeugt B nun ebenfalls eine Zufallszahl und einen Sitzungsschl¨ ussel. B verschl¨ usselt also nun die empfangene Zufallszahl RA , die selbst erzeugte RB und den Sitzungsschl¨ ussel KS mit dem oﬀentlichen Schl¨ ussel KEA von A. Das Resultat E(KEa , (RA , RB , KS )) ¨ sendet der Teilnehmer B an A. 4. A entschl¨ usselt die Nachricht mit seinem geheimen Schl¨ ussel. Wenn die empfangene Zufallszahl RA mit der in Schritt 1 gesendeten Zahl u ¨ bereinstimmt, vertraut er B und die Prozedur kann fortgesetzt werden. Im anderen Fall wird sie abgebrochen. 5. A arbeitet nun mit dem von B empfangenen Sitzungsschl¨ ussel KS . Er verschl¨ usselt die von B erzeugte Zufallszahl mit dem Sitzungsschl¨ ussel. Das Resultat E(KS , RB ) sendet er an B. 6. B entschl¨ usselt die empfangene Nachricht mit dem zuvor gesendeten Sitzungsschl¨ ussel. Wenn die so decodierte Zufallszahl RB mit der in Schritt 3 erzeugten Zahl u ¨ bereinstimmt, vertraut er auch A und die Kommunikation kann beginnen. Dieses Verfahren setzt die Kenntnis des ¨oﬀentlichen Schl¨ ussels des jeweils anderen Kommunikationspartners, insbesondere eine vertrauensw¨ urdige Zuordnung des Schl¨ ussels zum Teilnehmer, voraus. F¨ ur die Verwaltung

5.6 Sicherheitsaspekte

219

ussel existieren Trustcenter, welche f¨ ur diese Vertrauensw¨ ur¨oﬀentlicher Schl¨ digkeit einstehen. Eine Alternative sind logische Netzwerke, welche dezentral ein Maß f¨ ur die Vertrauensw¨ urdigkeit berechnen. Wenn A dem Kommunikationspartner B vertraut und B vertraut C, dann vertraut A auch dem Teilnehmer C, jedoch in einem etwas geringeren Maße. So kann in einem Kommunikationsnetz die Vertrauensw¨ urdigkeit der Teilnehmer dynamisch propagiert werden. 5.6.4 Echtheitsnachweis und elektronische Signatur Sowohl f¨ ur den Absender einer Nachricht als auch f¨ ur den Empf¨anger kann es wichtig sein, ihre Echtheit zu beweisen. Hier wird ebenfalls das grunds¨atzliche Prinzip eines Verfahrens, das auf unsymmetrischen Schl¨ usseln basiert, vorgestellt. Die Voraussetzung f¨ ur das hier vorgestellte Verfahren ist, das außer der oben beschriebenen Eigenschaft D(Kd , E(Ke , M )) = M das Prinzip auch mit vertauschten“ Schl¨ usseln m¨ oglich ist: ” E(Ke , D(Kd , M )) = M Mit dem privaten Schl¨ ussel codierte Nachrichten k¨onnen also mit dem oﬀentlichen Schl¨ ussel des Senders decodiert werden. Unter dieser Vorausset¨ zung wird die Nachricht beim Sender zun¨ achst mit seinem geheimen Schl¨ ussel codiert und anschließend mit dem ¨ oﬀentlichen Schl¨ ussel des Empf¨angers codiert. Die chiﬀrierte Nachricht kann in der ersten Stufe nur vom Empf¨anger mit seinem privaten Schl¨ ussel decodiert werden. In der zweiten Stufe decodiert der Empf¨ anger nun mit dem ¨ oﬀentlichen Schl¨ ussel des Senders. Da nur der Sender u origen Schl¨ ussel verf¨ ugt, kann auch nur er diese ¨ ber den zugeh¨ Nachricht erstellt haben und er kann sowohl die Existenz als auch den Inhalt der Nachricht nicht leugnen. Der Empf¨ anger kann ebenfalls den Inhalt nicht nachtr¨ aglich ¨ andern, da der Sender im Konﬂiktfall als Beweis die von ihm mit seinem privaten Schl¨ ussel codierte Nachricht verlangen kann. Diese kann der Empf¨ anger mangels Schl¨ ussel nicht manipulieren. Abbildung 5.30 zeigt das grunds¨ atzliche Verfahren. Da der Aufwand f¨ ur diese zweistuﬁge Verschl¨ usselung sehr hoch ist, existieren f¨ ur den praktischen Einsatz schnellere Verfahren, die jedoch auf diesem Prinzip basieren. Auch diese Verfahren setzen die gegenseitige Kenntnis der oﬀentlichen Schl¨ ussel und das Vertrauen in ihre Korrektheit voraus. ¨

220

5. Informations- und Kommunikationstechnik Sender

Empfänger öffentlicher Schlüssel

öffentlicher Schlüssel

privater Schlüssel

privater Schlüssel

Algorithmuse

Klartext

Algorithmuse

signierter Text

Algorithmusd

Geheimtext

Geheimtext

signierter Text

Algorithmusd

Klartext

Übertragungskanal

Abbildung 5.30. Grundprinzip der Signierung eines Dokumentes mit anschließender Verschl¨ usselung

6. Softwareengineering

Das Softwareengineering, oder auch auf Deutsch die Softwaretechnik, befasst sich mit der Herstellung von Software. Dabei kommen ingenieurm¨aßige Methoden und Prinzipien zum Einsatz, um ein gegebenes Ziel zu erreichen. Die Ziele eines Warehouse Managementsystems (WMS) werden z. B. im Rahmen einer Anforderungsspeziﬁkation oder eines Pﬂichtenheftes festgelegt. Zunehmend seltener werden WMS komplett neu entwickelt. Um ein WMS jedoch f¨ ur einen konkreten Anwendungsfall zu r¨ usten, reichen oft die reinen Konﬁgurationsm¨ oglichkeiten eines gegebenen WMS nicht aus. Teile oder Module der Software m¨ ussen erg¨ anzt oder neu geschrieben werden. Vor diesem Hintergrund werden im Rahmen dieses Buches einige wichtige Aspekte des Softwareengineering zusammengefasst. Die Begriﬀswelt in der Informationstechnologie und ganz besonders in der Softwaretechnik ist nicht einheitlich. Die hier vorgestellten Begriﬀe werden in zahlreichen Werbeaussagen und Produktpr¨asentationen auf ganz unterschiedliche Art verwendet. W¨ ahrend Software das inh¨arente Problem hat, einem potenziellen Kunden gegen¨ uber nicht darstellbar zu sein, scheinen umgekehrt die Begriﬀe, mit denen Softwareeigenschaften beschrieben werden, zu unscharf deﬁniert zu sein, so dass deren Verwendung mitunter obskur ist. Der folgende Text soll daher auch ein Verst¨ andnis f¨ ur die von IT-Fachleuten oft und gern benutzten Fachbegriﬀe schaﬀen.

6.1 Softwarearchitekturen Architektur beschreibt im weitesten Sinne die Struktur einer Konstruktion. Eine Softwarearchitektur beschreibt, wie die einzelnen Softwareteile untereinander koordiniert sind und welche Aufgabenteilung zwischen ihnen besteht. Die Wahl einer Architektur f¨ ur ein Softwaresystem ist f¨ ur die weiteren T¨ atigkeiten in einem Softwareprojekt grundlegend. Dieses Kapitel beschreibt vier typische Architektur-Konzepte. Die einzelnen Konzepte k¨ onnen dabei durchaus miteinander kombiniert werden, um den jeweiligen Vorteil eines Konzeptes zu nutzen. Grunds¨atzlich sagt die Wahl der Softwarearchitektur nichts u ¨ ber die Qualit¨at einer Software aus.

222

6. Softwareengineering

Zu vernachl¨ assigen ist die Wahl einer Architektur in Bezug auf die zu erreichenden Ziele aber nicht. Es folgt eine Auswahl typischer Kriterien, die bei der Wahl einer Softwarearchitektur ber¨ ucksichtigt werden sollten: • beteiligte Systemkomponenten (z. B. Betriebssystem, Datenbank, Massenspeicher) • benachbarte Systeme (z. B. Warenwirtschaft, Webshop, Produktionsplanung) • Leistungsf¨ ahigkeit (z. B. Speicherverbrauch, Antwortzeiten, Operationen pro Zeiteinheit) • Entwicklungsdauer und Entwicklungsaufwand • Anzahl und Kompetenzen der Entwickler und Systembetreuer • Wartungsfreundlichkeit und Betriebsaufwand • Nachvollziehbarkeit des operativen Betriebs der Software • Robustheit bei Fehlbedienung • Integrit¨ at (z. B. Qualit¨ at und Fehlerfreiheit der Daten, Algorithmen und Prozesse) • Wiederverwendbarkeit der Software • Erweiterungsf¨ ahigkeit der Software (z. B. in Bezug auf erweiterte Nutzung oder neue Prozesse und Algorithmen) Architektur-Konzepte, die im folgenden beschrieben werden, sind • monolithische Architektur, • Modularisierung der Software, • Prinzip der Schichtung, • Verteilung der Applikation. Alle hier vorgestellten Architekturkonzepte werden durch geeignete Konﬁgurationmechanismen an den jeweiligen Betriebsfall angepasst. Die hier gew¨ ahlte Zusammenstellung ist eine Auswahl praxisrelevanter Konzepte. In der Informatik sind dar¨ uber hinaus weit tiefere Betrachtungen u ¨ ber Architekturmuster, Entwurfsmuster, Idiome, Pattern und andere Konzepte zu ﬁnden. Bei der getroﬀenen Auswahl liegt der Fokus auf dem Kontext Warehouse Management. 6.1.1 Monolithische Architektur Der Begriﬀ Monolith r¨ uhrt vom griechischen Begriﬀ mon´ olithos her, dem Stein aus einem St¨ uck. Die monolithische Softwarearchitektur bezeichnet Softwaresysteme, deren Strukturen eng verzahnt sind und in denen neben dem großen Ganzen keine einzelnen Teile mehr erkennbar sind. In der Evolutions-Geschichte der Softwaretechnik sind die monolithischen Systeme die Einzeller unter den Softwaresystemen. S¨amtliche Funktionen der

6.1 Softwarearchitekturen

223

Software sind in einem einzigen Block vereint. Zum Beispiel sind Bedienerschnittstelle, fachliche Algorithmen, Datenspeicherung und Datenkommunikation miteinander vereint. Arbeitsteilung ist f¨ ur monolithische Systeme nur bei Parallelisierbarkeit1 einer ganzen Aufgabe denkbar. Die Teill¨osung von Aufgaben durch das System ist nicht erkennbar. Der gr¨ oßte Nachteil monolithischer Architekturen ist deren schlechte Wartbarkeit. Dieser Nachteil ist so gravierend, da mit Zunahme der Gr¨oße eines Projektes das Projekt u ¨berproportional aufw¨andig wird. Wenn mehrere Entwickler gleichzeitig ein monolithisches System entwickeln, ist mit hohen Kommunikationsaufw¨ anden zu rechnen, da die nicht vorhandene Abgrenzung innerhalb der Software auch keine einfache Arbeitsteilung der beteiligten Entwickler zul¨ asst. Typisch f¨ ur eine monolithische Architektur ist, dass sie Aufgaben als Ganzes erf¨ ullt, die prinzipiell auch in mehrere Teilaufgaben h¨atten zerlegt werden k¨ onnen. Dennoch hat auch diese Form der Softwarearchitektur Vorteile: Optimierung In einer monolithischen Software besitzen alle Regionen einer Software gleichberechtigten Zugriﬀ auf die Daten anderer Regionen. Mit diesen verh¨ altnism¨ aßig einfach zu beschaﬀenden Informationen k¨onnen leistungsf¨ ahige Optimierungen entwickelt werden. Performance In einem monolithischen System sind die Wege zur Beschaffung von Informationen kurz. Dies kann sich der Entwickler zunutze machen und durch den direkten Zugriﬀ auf Informationen die sonst notwendigen Wege durch die Instanzen vermeiden. Durch immer schnellere Hardware, die schlechte Performance kompensiert, sowie immer gr¨ oßere Projekte, deren Kontrollierbarkeit entscheidend ist, sind monolithische Systeme heute keine ernsthafte Option mehr. Monolithische Architekturen sollten heute, wenn u ¨ berhaupt noch, als eine schnelle L¨ osung2 mit begrenzter Haltbarkeit angesehen werden. Die n¨achste logische Entwicklungsstufe ist die Modularisierung von Software. 6.1.2 Modularisierung Ein Modul stellt einen Teil eines gr¨ oßeren Ganzen dar. Bei der Modularisierung von Softwaresystemen werden einzelne Aufgabenbereiche eingegrenzt, die durch jeweils eine unabh¨ angige Software, das Softwaremodul, bearbeitet werden. In einem gr¨ oßeren Softwaresystem k¨ onnen Module auch funktionale Gebiete umfassen. Beispielsweise k¨ onnen in der Unternehmens-IT das Warehouse Managementsystem, das Warenwirtschaftssystem und die Produktionsplanung als Module einer Gesamtl¨ osung bezeichnet werden. Die einzelnen 1

2

Die gleichzeitige Bearbeitung mehrerer Aufgaben: Anstelle eines Rechners, der beispielsweise zehn gleiche Aufgaben l¨ ost, werden f¨ unf Rechner eingesetzt, die jeweils zwei Aufgaben l¨ osen. Schnelle L¨ osungen werden auch oft als Quick Hack oder quick and dirty bezeichnet.

224

6. Softwareengineering

Systeme wiederum k¨ onnen weiter in Module unterteilt werden. So k¨onnen die einzelnen Prozesse eines Warehouse Managementsystems, wie z. B. der Wareneingang, der innerbetriebliche Transport oder die Inventur, als eigene Module angesehen werden. Bezeichnend f¨ ur ein Modul ist, dass es seine abgegrenzte betriebliche Aufgabe im Unternehmen erf¨ ullt. Technische Aufgaben wie Datenhaltung, Benutzerschnittstelle und Kommunikation sind im Modul vereint. Ein enger gefasster Modul-Begriﬀ in der Softwaretechnik ist der der Komponente. Komponenten haben eine deﬁnierte, also wohlbekannte Schnittstelle, und deren Verhalten ist ebenso wohlbekannt. Bei einer Komponente ist streng speziﬁziert, welche Daten in sie hinein gelangen und welche Daten als Resultat herauskommen. Ein Beispiel: Eine Kuchendiagramm“-Komponente dient zur Anzeige in ” einer Desktop-Applikation3 . Sie dient in einem Kundenauftragsmodul des ¨ Warenwirtschaftssystems dazu, aus den vorhandenen Daten einen Uberblick u ¨ber die bearbeiteten, unbearbeiteten und fehlerhaft bearbeiteten Auftr¨age zu generieren. Die eingehenden Daten sind exakt speziﬁziert und die Ausgabe ist die graﬁsche Darstellung dieser Daten in einem Fenster. Die Komponente k¨ onnte in gleicher Weise zur Anzeige von Wahlergebnissen bei Bundestagswahlen eingesetzt werden. Komponenten und Module haben grunds¨ atzlich das Potenzial, eine Unternehmens-IT aufwandsarm aus einem Baukastensystem zu komponieren. Dieses Ideal wird seit geraumer Zeit verfolgt, aber nicht immer erreicht. Zwar werden oft Module und Komponenten eingesetzt. In der Regel m¨ ussen sie jedoch zumindest konﬁguriert, teilweise auch ver¨andert oder erweitert werden. 6.1.3 Schichtung Die Schichtung beschreibt die Einf¨ uhrung von technischen oder auch gesch¨aftlichen Ebenen (Layer) in ein Softwaresystem. Ein neuerer Terminus f¨ ur Schichtung ist auch die englische Vokabel Stack, also Stapel4 , oder in Verbindung mit der Anzahl der n Schichten innerhalb einer Applikation das n-Tier5 Modell. Die Merkmale einer Schichtung sind: • Eine Schicht kommuniziert ausschließlich mit ihren Nachbarschichten. Das ¨ Uberspringen einer Schicht ist nicht m¨ oglich. Andere als die benachbarten Schichten sind transparent, also unsichtbar. 3 4

5

ein Programm, welches z. B. unter Windows ausgef¨ uhrt wird und ein mit der Maus und der Tastatur bedienbares Fenster ¨ oﬀnet Ein Stack oder Stapel in der Informatik ist zudem eine Last-In-First-Out (LIFO) Datenstruktur, bei der immer nur das zuletzt aufgelegte Element betrachtet und wieder entnommen werden kann. engl. f¨ ur Schicht, Etage oder Stufe

6.1 Softwarearchitekturen

225

• Jede Schicht u ¨bernimmt ihre Aufgabe autonom. Angrenzende Schichten ben¨ otigen keine Informationen zur Implementierung einer Schicht, um sie zu nutzen. Die Implementierung einer Schicht kann durch eine andere Implementierung ersetzt werden, ohne benachbarte Schichten ¨andern zu m¨ ussen. Die folgenden Beispiele verdeutlichen das Konzept der Schichtung: Automatisierungspyramide Speziell auf den Bereich der Materialﬂussautomatisierung zugeschnitten ist das Ebenenmodell f¨ ur Materialﬂusssteuerungen nach VDMA 15276 [76]. Es deﬁniert die folgenden Ebenen, angefangen bei der Warenwirtschaft bis hinunter zum Aktor und Sensor: Warenwirtschafts-/Produktionsplanungssystem (WWS, PPS) Hier wird das IT-Modell der wirtschaftlichen Gegebenheiten und Prozesse eines Betriebes dargestellt. Lagerverwaltung Es werden Orte, Bereiche, Topologie und Belegung verwaltet. Die Prozesse im Lager werden organisiert. Die Lagerverwaltung stellt ein IT-Modell der notwendigen technischen Gegebenheiten und Prozesse in einem Lager dar. Darstellung und Kommunikation Diese Schicht ist eine Zwischenschicht, die die Daten der Subsystemsteuerungen konzentriert und darstellt sowie als Kommunikations-Schnittstelle zu den u ¨berlagerten Systemen dient. Subsystemsteuerung Die Subsystemsteuerung fasst die zu steuernden Bereiche zusammen und koordiniert diese entsprechend den Vorgaben der Lagerverwaltung. Bereichssteuerung Die Bereichssteuerung fasst bereichsweise die zu steuernden Elemente zusammen und koordiniert diese entsprechend den Vorgaben der Subsystemsteuerung. Elementsteuerung Die Elementsteuerung verarbeitet die eingehenden Sensordaten und steuert die Aktoren entsprechend den Vorgaben der Bereichssteuerung. Antriebe und Geber (auch als die Feldebene bezeichnet) Sensoren wie z. B. Lichtschranken oder Lichttaster sowie Aktoren wie z. B. F¨orderbandsegmente, Weichen oder Abschieber werden u ¨ber direkte Verkabelung oder Feldbussysteme angebunden. Dieses Ebenenmodell wird oft den Anforderungen entsprechend variiert und graﬁsch als Automatisierungspyramide dargestellt. Ein weiteres Beispiel f¨ ur geschichtete Systeme ist das OSI-Modell (siehe Abschn. 5.1.1).

226

6. Softwareengineering

Abbildung 6.1. Automatisierungspyramide

6.1.4 Verteilte Systeme Ein verteiltes System ist eine Menge unabh¨ angiger Computer, die sich ihrem Benutzer als ein einziges, koh¨ arentes System darstellen [56]. Das verteilte System besitzt keinen zentralen Speicher und keine gemeinsamen Datenobjekte. Die einzelnen Prozesse eines verteilten Systems k¨onnen lediglich durch den Austausch von Nachrichten miteinander interagieren. Typische Auspr¨ agungen von verteilten Systemen sind • Client-Server und • verteilte Anwendungen. Das Client-Server-Konzept ist hierarchisch. Ein meist zentraler Server bietet Dienstleistungen an, derer sich einer oder mehrere Clients bedienen. Es existiert eine Aufgabenteilung in Client-Aufgaben6 und Server-Aufgaben7. Bei einer verteilten Anwendung dagegen sind die ansonsten im Server abgewickelten Aufgaben auf die verschiedenen Knoten des Systems verteilt. 6 7

z. B. Benutzeroberﬂ¨ achen oder Schnittstellen zu unter- oder u ¨ berlagerten Systemen. z. B. Sicherung der Integrit¨ at und der Gesch¨ aftsregeln, Datenbankoperationen und Datenspeicherung, Datenauswertung u. s. w.

6.1 Softwarearchitekturen

227

Ziel des verteilten Systems ist die M¨ oglichkeit, Aufgaben nebenl¨auﬁg abzuarbeiten oder Redundanz und damit Ausfallsicherheit zu schaﬀen. Verteilte Systeme k¨ onnen damit Vorteile bei der Skalierbarkeit bieten: Durch den Einsatz weiterer Knoten kann die Gesamtleistung des Systems erh¨oht werden. Verteilte Systeme sind gegen¨ uber ihren Anwendern transparent, das heißt, sie verhalten sich wie ein einzelnes, geschlossenes System. Verteilte Systeme sind grunds¨ atzlich mit einem Mehraufwand behaftet, der durch die Verteilung selbst entsteht: • Die Verteilung der Aufgaben muss koordiniert werden, was zus¨atzlicher organisatorischer Leistungen bedarf. ¨ • Die Verteilung erfordert die Ubertragung von Nachrichten zu den einzelnen verteilten Knoten. Die Ergebnisse m¨ ussen zur¨ uck u ¨ bertragen werden. Breite Bekanntheit hat ein verteiltes System namens BOINC 8 , welches die Rechenleistung beispielsweise f¨ ur das SETI@home-Project 9 koordiniert. Mit der Installation der BOINC-Software auf einem am Internet angeschlossenen PC kann dieser zur L¨ osung von rechnerischen Aufgaben beitragen. Dabei werden die Zeiten genutzt, in denen der Nutzer selbst seinen PC nicht beansprucht10 . Ein Bindeglied zwischen Client-Server-Systemen und verteilten Systemen sind Cluster. Ein Cluster besteht aus mehreren miteinander vernetzten Rechnern. Cluster haben typischerweise die folgenden, zun¨achst divergierenden Zielsetzungen: Hochverf¨ ugbarkeit Ein Gesamtsystem soll gegen Ausfall gesch¨ utzt werden. Der Ausfall einzelner Knoten gef¨ ahrdet nicht die Verf¨ ugbarkeit des Gesamtsystems. Lastverteilung Eine zu bew¨ altigende Last soll nach bestimmten Kriterien auf vorhandene Ressourcen verteilt werden11 . Hochleistung Durch die Implementierung als Cluster soll eine m¨oglichst hohe Gesamtleistung erzielt werden. Im Rahmen der Softwarearchitektur von Warehouse Managementsystemen ist zu beachten, dass sowohl die Leistung als auch die Verf¨ ugbarkeit von Computersystemen relevante Gr¨ oßen sind. Der Ausfall eines Warehouse Managementsystems bei einem großen Versandhandel, u ¨ ber wenige Stunden in der Vorweihnachtszeit, kann sich bis in die Jahresbilanz des Unternehmens negativ auswirken. Wenn ein Warehouse Managementsystem auf Spitzenlasten mit Leistungseinbr¨ uchen reagiert und die Prozesse im Lager dadurch 8 9 10 11

s. auch http://www.boinc.de/ s. auch http://setiathome.ssl.berkeley.edu/ Die Zeiten, in denen ein Rechner nichts zu tun hat, werden idle genannt. Diese Zeiten k¨ onnen von wartenden und niedrig priorisierten Prozessen genutzt werden. z. B. gleiches/angemessenes Lastniveau auf beteiligten Knoten oder Einsparung von nicht ben¨ otigten Ressourcen.

228

6. Softwareengineering

verlangsamt werden, kann auch dies erheblichen Einﬂuss auf die Ergebnisse eines Unternehmens haben. Einige Warehouse Managementsysteme gehen aus diesen Gr¨ unden den Weg der Verteilung. Im einfachsten Fall handelt es sich um zwei redundante Rechner, wobei im Schadensfall nach manueller oder automatischer Umschaltung einer der beiden die Operationen des jeweils anderen u ¨bernehmen kann. ¨ ¨ Die jederzeitige Ubernahmebereitschaft sowie die automatische Ubernahme der operativen Prozesse wird auch Hot Standby genannt, die Bereitstellung lediglich einer redundanten Infrastruktur mit manueller Umschaltung Cold Standby. Die Variantenvielfalt von Last- und Ausfallszenarien ist nahezu unersch¨ opflich. Ohne entsprechende Erfahrungen auf diesem Gebiet haben Vorsorgemaßnahmen nicht immer den gew¨ unschten Erfolg. Somit ist gesteigerter Wert auf den praktischen Test der Vorsorgemaßnahmen zu legen, wobei das tats¨ achliche Verhalten des Systems bei Ausfall einzelner Komponenten beobachtet wird und die koordinierte Instandsetzung trainiert wird. Verteilte Systeme sind bei der zeitgem¨ aßen Unternehmens-IT praktisch nicht entbehrlich. Zum einen legen die oben genannten Gr¨ unde nahe, dass die einzelnen Systeme einer Unternehmens-IT m¨ oglichst zuverl¨assig ihren Dienst versehen. Zum anderen gilt es h¨ auﬁg, unterschiedliche Softwareprodukte wie beispielsweise ein PPS und ein WMS miteinander zu koppeln, so dass ein verteiltes System entsteht. Diese miteinander zu koppeln heißt, die beiden einzelnen Systeme zu einem einzigen verteilten System zusammenzuschalten. Im Kapitel 6.4 Middleware wird auf diese Aspekte eingegangen. Unterst¨ utzt werden kann die Unternehmens-IT auch durch die Wahl der entsprechenden Plattformen. Ein Beispiel sind Application-Server unter Java12 . Unter Beachtung der Programmierrichtlinien der J2EE-Plattform sind die darauf basierenden Systeme bei Einsatz entsprechend ausger¨ usteter Application-Server und Datenbanken prinzipiell auch Cluster-f¨ahig, um die Verf¨ ugbarkeit und Performance anzupassen. 6.1.5 Konﬁguration und Erweiterung Hersteller einer Branchen-Software sind bem¨ uht, ihre Software auf m¨oglichst viele Anwendungsf¨ alle abzustimmen. Das f¨ uhrt in der Praxis zum einen dazu, dass eine Software viel mehr kann, als man ihr tats¨achlich abverlangt. Auf der anderen Seite ist vielleicht genau die Funktion, die vom Anwender ben¨otigt wird, in der Software nicht implementiert. Eine u ¨ bliche Vorgehensweise der Softwarehersteller ist es, neue Funktionen in die Software zu integrieren und diese Funktionen abschaltbar zu gestalten. Beispielsweise k¨ onnen in einem Warehouse Managementsystem mehrere M¨ oglichkeiten zur Generierung einer neuen Artikelnummer implementiert 12

siehe dazu auch Kapitel 6.5

6.2 Grundz¨ uge der objektorientierten Programmierung

229

sein. Die Software wird in einem konkreten Einsatz dann aber so konﬁguriert, dass nur eine dieser M¨ oglichkeiten nutzbar ist. Variantenvielfalt und Konﬁgurationspotenzial sind zun¨achst ein Vorteil: Der Anwender hat bei der Installation und m¨ oglicherweise auch bei sp¨ateren ¨ Anderungen im Betriebsablauf die M¨ oglichkeit, das Verhalten der Software anzupassen. Konﬁgurationspotenzial ist aber genau dann irrelevant, wenn die verschiedenen Varianten nicht tats¨ achlich ben¨otigt werden. Im Gegenteil erh¨ oht Variantenvielfalt immer auch die Komplexit¨at und damit die Fehleranf¨ alligkeit einer Software. In verschiedenen Branchen und bei unterschiedlichen Anbietern existieren verschiedene Ansichten und Erfahrungen dar¨ uber, wie weit der Standardisierungsgrad13 einer Software u ¨ berhaupt getrieben werden kann. Grunds¨atzlich gilt: Je komplexer eine logistische Unternehmung ist, desto h¨oher ist der Aufwand f¨ ur individuelle Entwicklungen im Softwareprojekt. Weitere Hinweise und ein Vorgehensmodell zur Einf¨ uhrung und applikationsspeziﬁschen Gestaltung von WMS ﬁnden sich in Kapitel 8.

6.2 Grundzu ¨ ge der objektorientierten Programmierung In diesem Abschnitt wird die grunds¨ atzliche Idee der objektorientierten Programmierung dargestellt. Die Objektorientierung ist nicht nur eine Programmiertechnik, sondern auch eine Methode f¨ ur die Systemanalyse und das Systemdesign. Diese Aspekte werden im letzten Unterabschnitt kurz angesprochen. Zur anschaulichen Darstellung werden Transportger¨ate beschrieben, die in der Lage sind, Ladeeinheiten von einem Ort zu einem anderen zu transportieren. Diese Darstellung erfolgt sowohl mit den Symbolen der UML (Uniﬁed Modelling Language, s. Abschn. 6.3) als auch durch Codest¨ ucke, die in der Programmiersprache Java geschrieben sind. 6.2.1 Datenabstraktion Die traditionelle Programmierung geht entweder von den Datenstrukturen oder den Funktionen aus. Die Grundidee der Datenabstraktion besteht darin, dass Daten und Funktionen zusammengefasst und als Einheit betrachtet werden. Der Zugriﬀ auf die Daten, die ihrerseits aus solchen Einheiten bestehen k¨ onnen, erfolgt dabei ausschließlich u ¨ ber die Funktionen. Dieses auch als Kapselung der Daten (Information Hiding) bezeichnete Prinzip verbietet den direkten Zugriﬀ auf die Daten14 und bietet folgende Vorteile: 13 14

Mit dem Standardisierungsgrad ist der Anteil einer Software gemeint, der bei einem neuen Projekt nicht mehr ge¨ andert werden muss. Viele Programmiersprachen, die dieses Konzept unterst¨ utzen, erlauben dennoch einen direkten Zugriﬀ auf die Daten. Dieses muss dann durch Programmierdisziplin vermieden werden.

230

6. Softwareengineering

• Die einheitliche Schnittstelle des Funktionsaufrufes abstrahiert von den zugrunde liegenden Daten. • Die Details der Zugriﬀsfunktionen und der unterliegenden Daten bleiben dem Aufrufer verborgen. • Die Sicherung der Datenintegrit¨ at obliegt ausschließlich den Zugriﬀsfunktionen und nicht dem Aufrufer. ¨ • Nachtr¨ agliche Anderungen der Funktionen k¨onnen lokal und damit ohne Auswirkungen auf deren Aufrufer erfolgen. Diese ausschließliche Nutzung der Funktionsschnittstelle und das explizite Verbot eines direkten Zugriﬀs scheint bei einfachen“ Variablen zun¨achst ” sehr aufw¨ andig. Die Vorteile werden jedoch oﬀensichtlich, wenn bei sp¨ateren Softwareerweiterungen bei jedem Variablenzugriﬀ zus¨atzlich weitere Variablen ge¨ andert oder weitere Funktionen aufgerufen werden m¨ ussen. Eine Erweiterung braucht dann nur in der entsprechenden Funktion nachger¨ ustet zu werden, w¨ ahrend die Schnittstelle zum aufrufenden Programm gleich bleibt. Der Programmierer ben¨ otigt f¨ ur die Nutzung der Funktion lediglich einen m¨ oglichst selbsterkl¨ arenden Namen; die Details bleiben ihm verborgen. Beispielsweise kann bei einem bestehenden WMS nachtr¨aglich die Forderung gestellt werden, die Zeitdauer, w¨ ahrend der ein Lagerfach gesperrt war, in einem Betriebsprotokoll aufzuzeichnen. Eine direkte Programmierung ¨ k¨onnte in der Programmiersprache Java vor der Anderung wie folgt ausse15 hen : ... // Auswahl eines Lagerfachs fach ... // Das ausgewaehlte Fach wird als gesperrt gekennzeichnet fach.locked = true; ...

Bei dieser Art der Programmierung m¨ ussen alle Zuweisungen an die Variable lock nachtr¨ aglich durch entsprechende Funktionsaufrufe ersetzt oder um zus¨ atzliche Anweisungen erg¨ anzt werden. Bei Anwendung des Kapselungsprinzips w¨ are die Zeile fach.locked = true durch fach.lock(), also entsprechende Funktionsaufrufe zu ersetzen. Die dem Fach zugeordnete Funktion lock k¨ onnte wie folgt programmiert sein: class Fach { ... // sperren eines Lagerfaches public void lock() { locked = true; } // freigeben eines Lagerfaches public void unlock() { locked = false; } ... } 15

Der doppelte Schr¨ agstrich kennzeichnet den Rest der jeweiligen Zeile als Kommentar.

6.2 Grundz¨ uge der objektorientierten Programmierung

231

Nach der Erweiterung des Datentypen Fach um die Variable startLock k¨onnten die Funktionen nun erweitert werden: class Fach { long startLock; ... // sperren eines Lagerfaches public void lock() { if (! locked) { // lock = true; // speichern des Zeitpunktes der Sperrung startLock = getTime_ms(); } } // freigeben eines Lagerfaches public void unlock() { long delta; if (locked) { lock = false; // berechnen der Dauer der Sperrung delta = (System.currentTimeMillis() - startLock)/1000/60; // protokollieren der Dauer der Sperrung logbook.println( "Fach " + name + " wurde " + delta + "Minuten gesperrt."); } } ... }

Die Aufrufstellen brauchen in diesem Fall nicht ge¨andert zu werden, was einen großen Vorteil f¨ ur die Menge der zu ¨ andernden und zu testenden Teile der Software darstellt. 6.2.2 Klassen und Objekte Die Beschreibung der Gesamtheit aller logisch zusammengeh¨orenden Datenbeschreibungen und Funktionen nennt man Klasse, die Daten werden Attribute und die Funktionen Methoden dieser Klasse genannt. Eine Klasse enth¨alt keine Attributwerte 16 , sondern nur Metadaten. Um Daten zu erzeugen, muss zun¨ achst ein Objekt dieser Klasse generiert werden. Ein solches Objekt wird auch Instanz seiner Klasse genannt und verf¨ ugt u ¨ ber Speicherplatz zur Ablage der Attributwerte. Von jeder Klasse k¨ onnen – unter Ber¨ ucksichtigung des begrenzten Speicherplatzes – beliebig viele Objekte erzeugt werden. In den meisten Programmiersprachen wird der Operator f¨ ur diese Instanziierung von Klassen mit new bezeichnet. 16

Die static Attribute, welche auch einer Klasse Werte zuordnen, werden hier nicht betrachtet.

232

6. Softwareengineering

Die bis hier beschriebenen Prinzipien stellen nicht sicher, dass alle Attribute auch immer initialisiert sind. Hier bietet die objektbasierte Technik spezielle Funktionen, die Konstruktoren. In den meisten Programmiersprachen m¨ ussen Konstruktoren den Namen ihrer Klasse tragen. Jede Klasse muss mindestens einen Konstruktor enthalten17 . Bei Bedarf k¨onnen auch mehrere Konstruktoren speziﬁziert werden, wenn sie sich in ihren Parameterlisten (Signaturen) unterscheiden18 . Die Instanziierung einer Klasse stellt zun¨ achst Speicherplatz f¨ ur ihre Attribute bereit und f¨ uhrt anschließend den vom Programmierer gew¨ unschten Konstruktor aus. Ein Regalbedienger¨ at kann beispielsweise durch eine Klasse RBG repr¨ asentiert werden. Diese Klasse k¨ onnte u u¨ber mehrere Konstruktoren verf¨ gen, die im Folgenden in einem stark vereinfachten Java-Code-Beispiel dargestellt werden. class RBG { // Definition einer Konstanten f¨ ur die Ruheposition aller RBG private final Position homepos = new Position(1, 1); // Attribut f¨ ur die aktuelle Position des RBG private Position pos; RBG () { // Anlegen einer neuen Instanz des Attributes pos pos = new Position(); // Setzen der Positionskoordinaten, aus der Konstanten homepos pos.setx(homepos.x()); pos.sety(homepos.y()); } RBG (int x, int y) { // Anlegen einer neuen Instanz des Attributes pos pos = new Position(); // Setzen der Positionskoordinaten, die als Parameter diesem // Konstruktor ¨ ubergeben werden pos.setx(x); pos.sety(y); } RBG (String pos) { // Anlegen einer neuen Instanz des Attributes pos pos = new Position(); // Die Klasse Position kann die Koordinatenwerte auch aus einem // String erzeugen pos.setByName(s); } } 17

18

Die meisten Programmiersprachen stellen implizite Default-Konstruktoren bereit, die jedoch keine speziﬁsche Initialisierung der Attribute mit den wechselseitigen Abh¨ angigkeiten ihrer Werte ersetzen k¨ onnen. ¨ Diese Technik des Uberladens ist auch f¨ ur Methoden erlaubt.

6.2 Grundz¨ uge der objektorientierten Programmierung

233

Eine neue Instanz eines Regalbedienger¨ ates kann auf drei unterschiedliche Arten erzeugt werden: • RBG rbg1 = new RBG() f¨ ur ein neues Regalbedienger¨at. Das neu erzeugte Objekt der Klasse RBG heißt rbg1 und wird mit der Standardinitialisierung, der Ruheposition (1,1), erzeugt; • RBG rbg1 = new RBG(2, 3) f¨ ur ein neues Regalbedienger¨at mit der aktuellen Position (2,3); • RBG rbg1 = new RBG("E2T3") f¨ ur ein neues Regalbedienger¨at mit der aktuellen Position, welche durch die Zeichenkette E2T3 beschrieben wird. Das Gegenst¨ uck zum Konstruktor ist der Destruktor, der von dem Objekt belegte Ressourcen wieder freigeben soll. Zum Schluss gibt der Destruktor den von dem entsprechenden Objekt belegten Speicherplatz wieder frei19 . 6.2.3 Vererbung Die Analyse der durch Software abzubildenden Objekte zeigt gelegentlich, dass diese, unabh¨ angig von einer detaillierten Betrachtung, u ¨ ber gemeinsame Funktionen oder Attribute verf¨ ugen. Beispielsweise kann ein F¨orderger¨at“ ” Ladeeinheiten von einem Lagerort zu einem anderen transportieren. Dieses Verhalten ist durch unterschiedliche technische Auspr¨agungen, die oft u ¨ ber weitere, zus¨ atzliche Eigenschaften verf¨ ugen, zu erreichen. Die Grundidee der Objektorientierung erweitert das oben beschriebene objektbasierte Konzept um das Prinzip der Spezialisierung von Klassen. Eine Klasse, die Methoden und Attribute bereitstellt, kann durch Ableitung spezialisiert werden. Die allgemeinere Klasse wird als Basisklasse, die spezialisierten Klassen als abgeleitete Klassen bezeichnet. Dieses Prinzip wird auch Vererbung genannt, da die abgeleiteten Klassen die Attribute und Methoden ihrer Basisklasse erben“. ” Das Prinzip der Vererbung ist in Abb. 6.2 am Beispiel der Basisklasse Transportgeraet f¨ ur alle Transportger¨ ate und je einer Ableitung f¨ ur Regalbedienger¨ ate und f¨ ur Verschiebewagen gezeigt. Beide abgeleiteten Klassen sind instanziierbar, w¨ ahrend in diesem Fall aus der Basisklasse keine Objekte erzeugt werden k¨ onnen. Die Basisklasse stellt lediglich einige Attribute bereit und deklariert einige Methoden, stellt also eine Schnittstellenspeziﬁkation bereit. WMS, die beispielsweise sowohl RBG als auch Verschiebewagen abbilden, k¨ onnen mit den Methoden der Klasse Transportgeraet arbeiten. Lediglich bei der Instanziierung muss der Programmierer darauf achten, dass 19

In Java-Systemen kann aufgrund der automatisch arbeitenden Speicherverwaltung nicht vorhergesagt werden, wann der Destruktor ausgef¨ uhrt wird. In C++Systemen werden Destruktoren sofort ausgef¨ uhrt, wenn auf ein Objekt der delete-Operator angewendet wird. Hier liegen wichtige konzeptionelle Unterschiede vor, die jedoch f¨ ur das grunds¨ atzliche Verst¨ andnis der Thematik nicht relevant sind.

234

6. Softwareengineering TransportGeraet -maximalGewicht:int -aktuellePosition:Position -gesperrt:boolean +transportiere(quelle:Position,ziel:Position) :void +leerfahrt(ziel:Position) :void +druckeAuftragsliste(out:PrintsStream) :void +sperren() :void +freigeben() :void

RBG +RBG(pos:Position) +transportiere(quelle:Position,ziel:Position) :void

Verschiebewagen -lastaufnahmemittel:LAM +Verschiebewagen(anzahlLam:int,pos:Position) +transportiere(quelle:Position,ziel:Position) :void

Abbildung 6.2. Ableitung je einer Klasse f¨ ur Regalbedienger¨ ate RBG und f¨ ur Verschiebewagen Verschiebewagen aus der Basisklasse Transportgeraet. Mit -“ wer” den die Attribute, mit +“ die Methoden gekennzeichnet. ”

die Objekte aus genau der Klasse erzeugt werden, die das konkrete Transportger¨ at beschreibt. Das Programmiersystem sorgt dann daf¨ ur, dass immer die richtige Methode aufgerufen wird. Falls eine Basisklasse auch Methoden deﬁniert und die abgeleitete Klasse diese Methoden ebenfalls deﬁniert, werden diese Methoden der Ableitung aufgerufen; andernfalls die Methode der Basisklasse. Abgeleitete Klassen k¨onnen weitere Attribute und Methoden besitzen, die nicht in der Basisklasse deklariert wurden. Solche Methoden k¨ onnen nicht u ¨ ber die Schnittstelle der Basisklasse aufgerufen werden, da sie dort unbekannt sind20 . Ein Beispiel ist ein kurveng¨ angiges RBG (erm¨ oglicht das Umsetzen des RBG in verschiedene Gassen), das mit Hilfe der Methode changeAisle() die Gasse wechseln kann. Das Prinzip der Ableitung kann mehrfach eingesetzt werden, so dass aus einer Basisklasse ein ganzer Baum weiterer Klassen abgeleitet werden kann. So k¨ onnte die Klasse RBG durch weitere Ableitungen spezialisiert werden.

20

In diesem Fall muss das Objekt zun¨ achst in ein Objekt des abgeleiteten Typs konvertiert (Typcasting) werden.

6.3 Uniﬁed Modeling Language (UML)

235

6.2.4 Eigenschaften von Klassen Neben dem Prinzip der Vererbung deﬁniert das Paradigma der Objektorientierten Programmierung noch weitere Begriﬀe: ¨ Uberladen Methoden, die in einer Mutterklasse deﬁniert wurden, k¨onnen in einer Kindklasse ¨ uberschrieben oder ¨ uberladen werden. Ein instanziiertes Objekt ersetzt dann Methoden der Oberklassen durch die eigene. Polymorphie Gleichnamige Methoden k¨ onnen mit verschiedenen Parametern implementiert werden. Beispielsweise k¨onnten neben der Methode cmttaddMehrwertSteuer() auch noch die Methode cmttaddMehrwertSteuer(double prozentsatz) und die Methode cmttaddMehrwertSteuer(int prozentpunkte) implementiert werden. Je nach aufgerufener Methode wird dann die entsprechende Mehrwertsteuer aufgeschlagen: die gerade g¨ ultige oder die jeweils angegebene. Assoziation, Aggregation und Komposition Objekte k¨onnen sich gegenseitig referenzieren u ¨ ber die Assoziation oder deren Zusammensetzung ausdr¨ ucken u ¨ ber die Aggregation. Eine Aggregation beschreibt die Teile des Ganzen21 . Die Komposition unterscheidet sich von der Aggregation darin, dass sie in h¨ ochstens einem referenzierten Element vorkommt. Die Assoziation beschreibt die Abh¨ angigkeiten der Klassen untereinander22 . Oft wird objektorientierte Programmierung damit beworben, dass sie der realen Welt sehr ¨ ahnlich sei. In technischen Systemen wird sie allerdings insbesondere als Methode zur Beherrschung der Komplexit¨at von Systemen verwendet. Diejenigen Objekte (Entities), welche realweltliche Dinge oder Vorg¨ ange abbilden, werden dagegen seltener u ¨ ber ihre objektorientierte Hierarchie deﬁniert; sie sind vielmehr hierarchielose Datenkapseln. Beispielsweise sind Entities im Open Source Warehouse Managementsystem myWMS mit einer technischen Hierarchie versehen, die jede einzelne Entity mit einem Erzeugungs-Datum, einer eindeutigen Nummer, einem Manipulations-Datum, einer Versionsnummer und einem Sperrkennzeichen versieht. Im produktiven Einsatz beﬁndet sich dagegen in der Regel jeweils eine Klasse f¨ ur Artikelstammdaten, Lagerf¨ acher, Ladehilfsmittel und so weiter. Objektorientierte Ableitungshierarchien sind daher f¨ ur den Benutzer eines Softwaresystems nicht sichtbar.

6.3 Uniﬁed Modeling Language (UML) Die Uniﬁed Modelling Language (UML) ist eine graﬁsche Notation f¨ ur Baupl¨ ane objektorientierter Softwaresysteme. Dazu stellt die UML eine Reihe von 21 22

z. B. : Das Auto besteht aus T¨ uren, einem Motor, R¨ adern, Sitzen, ... z. B.: Das Auto wird gefahren von einem Fahrer. Es geh¨ ort einem Eigent¨ umer...

236

6. Softwareengineering

Diagrammtypen bereit, die unterschiedliche Aspekte eines Softwaresystems abbilden. Die Diagramme k¨ onnen prinzipiell mit jedem beliebigen Hilfsmittel erzeugt werden. Es ist v¨ ollig legitim, ein Diagramm mit Bleistift auf Papier zu bringen oder es mit einem graﬁschen Zeichenprogramm zu malen. ¨ Ahnlich wie bei Baupl¨ anen anderer Disziplinen existiert aber mittlerweile eine Reihe von Programmen, mit denen UML-Diagramme bequem und formal korrekt erzeugt werden k¨ onnen. Einige UML-Produkte treten mit dem Anspruch an, eine umfassende UML-Dokumentation f¨ ur Softwaresysteme w¨ ahrend ihres gesamten Lebenszyklus bereitzustellen. Dies ist tats¨achlich ein lohnendes Ziel, hat aber zur Folge, dass Bauplan und Software simultan oder zeitnah gepﬂegt werden. Nicht selten wird daher auch die Variante praktiziert, bei der nach Konstruktion bereits die Anforderungs¨ anderungen nicht mehr in den UMLBauplan eingepﬂegt werden und die Dokumentation binnen kurzer Entwicklungszeit ihren Bezug zur Realit¨ at verliert. Dieser Eﬀekt, zun¨achst oft wegen der Ersparnis an Formalit¨ aten gern in Kauf genommen, f¨ uhrt dann bei den ¨ folgenden Anderungen zu zunehmendem Kontrollverlust. ¨ Einige UML-Werkzeuge bieten unter anderem die M¨oglichkeit, Anderungen in zwei Richtungen zu propagieren: ¨ ¨ 1. Anderungen am UML-Modell f¨ uhren zu Anderungen im Softwaresystem. ¨ ¨ 2. Anderungen am Softwaresystem f¨ uhren zu Anderungen im UML-Modell. Am erfolgreichsten wird diese Technik bislang bei Klassendiagrammen eingesetzt. Dazu existieren Werkzeuge, die bestehende Klassen analysieren und ¨ als UML-Klassendiagramm abbilden k¨ onnen, genauso wie sie die Anderungen der Klassen im UML-Diagramm in die Implementierung u ¨ bernehmen k¨onnen. Bei Projekten, deren zu entwickelndes Softwaresystem u ¨ ber mehrere Jahre angewendet werden soll, ist davon auszugehen, dass im Laufe der ¨ Zeit Anderungen und Erg¨ anzungen am Softwaresystem durchgef¨ uhrt werden m¨ ussen. Der Aufwand durch Erstellung und Pﬂege einer guten Dokumentation zahlt sich dann in aller Regel aus. Die UML ist kein Vorgehensmodell. Sie beschreibt nicht, in welcher Reihenfolge die Aktivit¨ aten eines Projektes durchgef¨ uhrt werden sollen. Dennoch werden die unterschiedlichen Diagramme zu unterschiedlichen Zeitpunkten innerhalb eines Projektes verwendet. So steht z. B. das AnwendungsfallDiagramm u ¨ blicherweise am Anfang eines Projektes, da hier die Anforderungen aus der Sicht der Anwender eines Softwaresystems aufgezeichnet werden. Eine mit UML konstruierte Software ist nicht automatisch vollst¨andig dokumentiert. UML dient als Hilfsmittel und kann einen sehr eﬃzienten Einblick in ein Softwaresystem erm¨ oglichen. Die große Menge der Details einer Implementierung wird sich allerdings regelm¨ aßig nicht in den UML-Diagrammen wiederﬁnden. Den Rahmen dieses Buches u uhrung in die ¨bersteigt eine komplette Einf¨ UML. Weiterf¨ uhrende Informationen enth¨ alt beispielsweise die UML Kurzreferenz [39], w¨ ahrend [37] einen vollst¨ andigen Einblick in die UML gew¨ahrt.

6.3 Uniﬁed Modeling Language (UML)

237

Hinweise zur Durchf¨ uhrung von objektorientierten Projekten liefert [38]. Die hier ausgew¨ ahlten Diagramme sind die am h¨ auﬁgsten eingesetzten Diagramme in Warehouse Managementprojekten. Die Erfahrung zeigt, dass UML Diagramme in Softwareprojekten f¨ ur Warehouse Managementsysteme erfolgreich eingesetzt werden k¨onnen. Folgende Punkte sollten bei der Verwendung von UML Diagrammen jedoch beachtet werden: • Die Diagramme m¨ ussen von den entscheidenden Projektbeteiligten akzeptiert werden. • Der Formalismus sollte in akzeptablen Grenzen gehalten werden. Der Diagramm- und Formenreichtum der Symbole der UML dient dazu, eine angemessene Auswahl zu treﬀen. • Diagramme k¨ onnen der Veranschaulichung von Sachverhalten und Algorithmen dienen. Der Wert dieser Diagramme liegt in der Abstraktion, also im Auslassen von Details. • Andere Diagramme dienen als Programmiervorlage oder zur Dokumentation bestehender Algorithmen. Der Wert dieser Diagramme liegt in der Vollst¨ andigkeit der Details. In den folgenden Abschnitten werden einige h¨auﬁg genutzte Diagrammtypen vorgestellt. Anwendungsfalldiagramm Das Anwendungsfalldiagramm (engl. Use Case Diagram) dient bei der Anforderungsanalyse dazu, die Anforderungen an ein Softwaresystem aufzunehmen. Abbildung 6.3 ist ein m¨ ogliches Anwendungsfalldiagramm f¨ ur einen Wareneingang. In einem Anwendungsfalldiagramm werden die Akteure (Strichﬁguren) und die von ihnen genutzten einzelnen Funktionen oder Anwendungsf¨alle (Elipsen) dargestellt. Die Verbinder zwischen Akteur und Anwendungsfall kennzeichnen deren Verh¨ altnis. Beispielsweise nutzt ein WE-Mitarbeiter die Funktion Ware identiﬁzieren. Ein Verbinder zwischen den Funktionen stellt deren Verh¨ altnis zueinander dar. Diese Verbinder werden in der Regel mit einem Qualiﬁzierer wie z. B. include, realize oder extend und einem Pfeil zur Kennzeichnung der Leserichtung ausgezeichnet. Auch nichtmenschliche Akteure k¨ onnen die Funktionen eines Systems nutzen und in einem Anwendungsfalldiagramm dargestellt werden. Beispielsweise k¨ onnen so Funktionen beschrieben werden, die durch ein u ¨ berlagertes Hostsystem genutzt werden. Klassendiagramm Klassendiagramme sind Pl¨ ane f¨ ur die objektorientierte Klassenarchitektur. Klassendiagramme eignen sich insbesondere dazu, die im System existierenden Entity-Klassen und deren Abh¨ angigkeiten darzustellen sowie komplexe

238

6. Softwareengineering

WE-Mitarbeiter

Disponent Wareneingang avisieren Waren identifizieren

Wareneingangsstatus abrufen Einlagerung auslösen

Abbildung 6.3. Ein m¨ ogliches Anwendungsfalldiagramm f¨ ur einen Wareneingang

Kommentar zum Klassendiagramm Interface AbstrakteKlasse

KlasseC

KlasseA

KlasseB 0..* 0..1 1..* 0..1

KlasseD

Kommentar zu einem Element des Klassendiagramms

Abbildung 6.4. Das Diagramm zeigt typische Elemente eines Klassendiagramms.

Klassenarchitekturen zu veranschaulichen. Sie stellen also die Datenstruk¨ turen eines Softwaresystems dar. Ublicherweise betriﬀt das alle im Projekt selbst erzeugten Klassen unterhalb der Pr¨ asentationsschicht23 und bis an die Persistenzschicht24. Die dargestellten Klassen sollten einen m¨ oglichst selbsterkl¨arenden Namen tragen und ihre Attribute25 und Methoden26 ausweisen. Die objektorientier23 24 25 26

die Schicht, welche die Informationen einem Benutzer anzeigt und mit ihm interagiert die Schicht, welche die Datenspeicherung und -beschaﬀung realisiert Variablen Funktionen

6.3 Uniﬁed Modeling Language (UML)

239

Gleiche Ereignisse können zu unterschiedlichen Zielzuständen führen.

Ereignis A

Ereignis A

Bedingung xy erfüllt Zustand 2

Bedingung xy nicht erfüllt

Zustand 1

Ereignis C

Ereignis B Zustand 3

Startpunkt

Zustand 4

Ereignis C

Endpunkt

Abbildung 6.5. Das Diagramm zeigt einige Zust¨ ande, die nach dem Eintreﬀen deﬁnierter Ereignisse zum Zustandswechsel f¨ uhren.

ten Eigenschaften und Abh¨ angigkeiten der Klassen werden durch ensprechende Verbinder dargestellt: • Vererbung wird durch einen Verbinder mit einem Dreieckpfeil dargestellt. Die Klasse, auf die der Pfeil zeigt, ist die Oberklasse, die andere Klasse ist die Unterklasse. • Eine Assoziation wird durch einen einfachen Strich dargestellt. Gerichtete Assoziationen werden durch einen Pfeil dargestellt. Die Klasse, von der der Pfeil am Ende des Assoziations-Verbinders wegzeigt, ist auch die Klasse, die die Variable enth¨ alt, welche die Assoziation realisiert. AssoziationsVerbinder ohne Pfeil sind in der Regel beidseitige Assoziationen, das heißt beide Objekte beider Klassen enthalten Variablen der jeweils anderen Klassen. • Eine Aggregation wird durch einen Strich dargestellt, an dessen Ende eine Raute liegt. • Eine Komposition wird durch einen Strich dargestellt, an dessen Ende eine ausgef¨ ullt Raute liegt. Assoziationen und Aggregationen sollten, wie in der Graﬁk 6.4 gezeigt, quantiﬁziert sein. Im Beispiel assoziiert die KlasseA die KlasseB. Dabei referenzieren Objekte der KlasseA genau 1 oder mehr Objekte der KlasseB. Andersherum werden Objekte der KlasseB genau 0 oder 1 mal von Objekten der KlasseA referenziert. KlasseB aggregiert die KlasseC, das heißt Objekte der KlasseC sind Teil von Objekten der KlasseB. Siehe dazu auch Kapitel 6.2. Zustandsdiagramm Das Zustandsdiagramm (engl. Statechart Diagram) wird verwendet, um die Zust¨ ande einer Software zu veranschaulichen. Beginnend bei einem deﬁnier-

240

6. Softwareengineering

ten Startzustand k¨ onnen Ereignisse eintreten, die einen Wechsel nach einem anderen Zustand erm¨ oglichen. S¨ amtliche erwartete Ereignisse werden mit jeweils einer Transition im Zustandsdiagramm repr¨asentiert. Mehrere Transitionen im Diagramm d¨ urfen dieselben Ereignisse repr¨asentieren, sofern sie von verschiedenen Zust¨ anden ausgehen. Dadurch kann je nach aktuellem Zustand ein und dasselbe Ereignis zu unterschiedlichen Folgezust¨anden f¨ uhren. Nicht deﬁnierte, beziehungsweise unerwartete Ereignisse f¨ uhren nicht zu einem Wechsel des Zustandes. Auf Transitionen k¨onnen auch Bedingungen (engl. guarding conditions) deﬁniert werden, aufgrund deren Auswertungen unterschiedliche Folgezust¨ ande eintreten. Das Beispiel in Abbildung 6.5 startet mit dem Zustand 1. Tritt daraufhin Ereignis A ein, wechselt der Zustand nach Zustand 2. Tritt jedoch Ereignis B ein, wechselt der Zustand nach Zustand 3. Beﬁndet sich das System im Zustand 1, so wird Ereignis C nicht beachtet. Ist das System im Zustand 2 und tritt Ereignis A ein, so wird anhand der Bedingung xy entschieden, welcher der neue Zielzustand ist. Sobald der Endpunkt erreicht ist, terminiert das im Zustandsdiagramm modellierte System. Zustandsdiagramme eignen sich in Warehouse Managementsystemen insbesondere dazu, den Status von Auftr¨ agen zu modellieren. Beispielsweise wird ein Transportauftrag in das System eingelastet und beﬁndet sich im Zustand Eingelastet. Zu einem beliebigen sp¨ ateren Zeitpunkt wird er von einem Lagermitarbeiter begonnen. Der Zustand ¨andert sich auf Begonnen. Ist der Transportauftrag ausgef¨ uhrt worden, f¨ uhrt ein Ereignis zum Endzustand. M¨ oglicherweise wird auch ein Fehlerzustand deﬁniert f¨ ur den Fall, dass der Transportauftrag nicht bearbeitet werden kann. Kommissionier-, Ein-, Umund Auslagerauftr¨ age usw. sind geeignet, entsprechend modelliert zu werden und dabei die Prozesse eines Warehouse Managementsystems abzubilden.

6.4 Middleware und Kommunikationsmechanismen Middleware bezeichnet ganz allgemein ein System zum Austausch von Informationen von eigenst¨ andig operierenden Modulen. Der Begriﬀ ist, in Anlehnung an Hard- und Software, die Vermittlungs- oder die Zwischenschicht. Im einfachsten Fall ist Middleware ein vereinbartes Protokoll zwischen zwei Modulen, beispielsweise dem Warenwirtschaftssystem (WWS) und dem Lagerverwaltungssystem (LVS). Im Anhang (s. Abschn. 9.1) sind Beispiele f¨ ur Middleware-Produkte aufgelistet. M¨ oglicherweise aber sind die angebotenen Protokolle27 der beteiligten Module nicht kompatibel28 , obwohl die Inhalte es durchaus sind. Dann kann eine eigenst¨ andige Middleware eingesetzt werden, die zwischen den Protokollen u ¨bersetzt und vermittelt. Das Konzept, 27 28

Protokoll ist hier gleichzusetzen mit Sprache Kompatible Dinge passen zusammen, w¨ ahrend inkompatible oder nicht kompatible Dinge nicht zusammenpassen.

6.4 Middleware und Kommunikationsmechanismen

241

welches eine einzige Middleware f¨ ur alle Belange der im Unternehmen ausgetauschten Daten realisiert, wird auch von einigen Herstellern als Enterprise Application Integration (EAI) oder auch Enterprise Bus bezeichnet29 . Der Enterprise Bus ist nicht zu verwechseln mit dem Enterprise Service Bus, der auf Service-orientierte Architekturen fokussiert30 . 6.4.1 Kommunikationspartner Der Einsatz unterschiedlicher Softwaremodule innerhalb eines Unternehmens impliziert die Verﬂechtung dieser unterschiedlichen Module miteinander. Eine noch immer praktizierte Variante der Kommunikation ist die so genannte Papierschnittstelle. Informationen, die dem einen Modul entspringen, werden ausgedruckt oder notiert und in Papierform und danach per Tastatureingabe an das folgende Modul weitergegeben. Beispielsweise sind Lieferpapiere und Paletten-Etiketten in Papierform noch relativ u ussen Informa¨ blich. M¨ tionen ausgedruckt werden, damit sie an anderer Stelle wieder eingetippt werden k¨ onnen, kommt schnell der Wunsch nach einem direkteren Austausch der Daten auf. F¨ ur eine moderne Unternehmens-IT hat neben den einzelnen Modulen und Subsystemen der Datenaustausch zwischen ihnen eine zentrale Bedeutung. Schnittstellen zwischen unterschiedlichen IT-Systemen und Modulen proﬁtieren von der Standardisierung der Schnittstellen. Eine exemplarische, breit gef¨ acherte Auswahl standardisierter Schnittstellen f¨ ur den Datenaustausch im Umfeld einer Unternehmens-IT sind beispielsweise: DTAUS Das Datentr¨ageraustausch-Verfahren realisiert die Auftragsertei¨ lung (Uberweisungen, Einz¨ uge etc.) an Kreditinstitute. EDIFACT Electronic Data Interchange for Administration Commerce and Transport ist ein globaler Standard, der auf die Initiative der UNO zur¨ uckzuf¨ uhren ist. Mit EDIFACT soll die beleglose Gesch¨aftsabwicklung zwischen Unternehmen gew¨ ahrleistet werden. EDIFACT wurde als ISO 9735 von der International Organization for Standardization registriert. BMEcat Das BMEcat-Format realisiert den Austausch von Katalogdaten. Es wurde auf Initiative des Bundesverband Materialwirtschaft, Einkauf und Logistik e. V. (BME) ins Leben gerufen und basiert auf XML. Die genannten Formate betreﬀen insbesondere den Datenaustausch mit externen Systemen, also zwischen Unternehmen. Hier ist eine starke Standardisierung von großem Interesse, da die potenziellen Kommunikationspartner un¨ uberschaubar viele sind und nicht f¨ ur jeden neuen Kontakt eine individuelle Schnittstelle vereinbart werden sollte. Typisch f¨ ur einige der genannten 29 30

Ein Bus ist ein Leitungssystem zum Datenaustausch zwischen beliebig vielen Teilnehmern. zum Thema Service-orientierte Architekturen s. auch Kapitel 6.6

242

6. Softwareengineering

Formate ist allerdings auch eine gewisse Interpretationsfreiheit bei der Implementierung. So enth¨ alt beispielsweise das EDIFACT-Format etwa 200 verschiedene Nachrichtenarten und viele branchenspeziﬁsche so genannte Subsets; ein in der Regel nicht vollst¨ andig implementierter Umfang also. Die Organisation innerhalb eines Unternehmens ist in der Regel bei weitem nicht so stark standardisiert wie die u ¨ blichen Interaktionen mit externen Unternehmen. Es ist daher naheliegend, die Schnittstellen der Module innerhalb eines Unternehmens bei Bedarf auch individuell auszulegen. Speziell im Bereich des Warehouse Management l¨ asst sich die Kommunikation in drei Bereiche gliedern31 : Host: die Kommunikation mit u ¨ berlagerten Systemen Steuerungstechnik: die Kommunikation mit unterlagerten Systemen Peripherie: die Kommunikation mit autonomen Komponenten ¨ Grunds¨ atzlich gilt f¨ ur alle Schnittstellen, dass die Ubertragung u ¨ber eine Schnittstelle auf irgendeine Art gesichert erfolgen muss. Das heißt, dass Daten vollst¨ andig und zuverl¨ assig an den Empf¨ anger u ¨bertragen und dort verarbeitet werden m¨ ussen. Je nachdem, u ¨ber welche Medien die Schnittstellen kommunizieren, ist zudem auch noch eine Authentiﬁzierung der beteiligten Kommunikationspartner notwendig sowie die Sicherung gegen Verf¨alschen und/oder Mitlesen durch Dritte. F¨ ur jeden einzelnen dieser Aspekte k¨onnen prinzipiell die entsprechenden Maßnahmen ergriﬀen werden. Host-Kommunikation Als Host (Gastgeber) wird hier ein Rechner oder ein Dienstanbieter bezeichnet, auf dem ein Modul oder ein System wie z. B. ein Warehouse Managementsystem, ein Produktionsplanungssystem (PPS) oder ein Warenwirtschaftssystem (WWS) ausgef¨ uhrt wird. Typische Verfahren zur HostKommunikation sind die in den folgenden Abschnitten beschriebenen Kommunikationsmechanismen • • • •

Dateiaustausch, Socketkommunikation, Pipes und Queues, Messaging.

Kommunikation mit Steuerungstechnik Die Steuerungstechnik besteht aus Komponenten, die direkt mit Sensoren und Aktoren in Verbindung stehen. Sie organisiert beispielsweise den Materialﬂuss u ordertechniksegmente bei Eingang ¨ ber Ein- und Ausschalten der F¨ bestimmter Sensor-Informationen. Die Steuerungstechnik ist die Ebene unterhalb der Materialﬂusssteuerung. Typische Verfahren zur Kommunikation 31

Siehe auch die Automatisierungspyramide in Kapitel 6.1.3.

6.4 Middleware und Kommunikationsmechanismen

243

mit der Steuerungstechnik sind die in den folgenden Abschnitten beschriebenen • Feldbussysteme und • Socketkommunikation32 . Kommunikation mit Peripherie Als Peripherie wird das Umfeld eines IT-Systems bezeichnet. Hierunter fallen z. B. Drucker, einige RFID-Leser und -Schreiber, Barcode-Leser, Temperatur¨ uberwachungen, Waagen usw. Diese Komponenten sind oft mit einer eigenen, propriet¨ aren Schnittstelle ausgestattet. Die Anpassung der komponentenseitigen Schnittstelle scheidet h¨ auﬁg deshalb aus, weil die Anpassung dieser Schnittstelle, die meist in der Hardware des Ger¨ates implementiert ist, aufw¨ andiger w¨ are als die individuelle Unterst¨ utzung der Schnittstelle im eigenen IT-System. 6.4.2 Kommunikationsmechanismen Dateiaustausch Es werden Dateiformate wie z. B. XML-Formate vereinbart, die auf vereinbarten Orten im Dateisystem hinterlegt werden. Der Empf¨anger sieht zu regelm¨ aßigen Zeitpunkten am vereinbarten Ort nach und liest die dort hinterlegten Daten ein. Der Dateitransfer erfolgt typischerweise u ¨ ber ein Rechnernetz. Socket-Kommunikation Es werden individuelle Telegramme vereinbart, die an den Kommunikationspartner u ¨bermittelt werden. Bei dieser Art der Kommunikation gibt es immer einen technischen Server, der auf einen oder mehr Clients wartet, sowie den technischen Client, der die Verbindung zum Server initiieren muss. Ist die Verbindung zur Gegenstelle erst einmal hergestellt, k¨onnen Informationen in beide Richtungen zwischen den Kommunikationspartnern ausgetauscht werden. Der technische Client-Server-Begriﬀ hat keinen Einﬂuss darauf, welcher der beiden Kommunikationspartner fachlich der Dienstleister und wer der Nutznießer ist. Diese Art der Kommunikation ist synchron, das heißt, dass die u ¨ bermittelten Daten zeitnah bei der Gegenstelle eintreﬀen und diese umgehend den Empfang der Daten quittieren kann. Wird f¨ ur die Socket-Kommunikation das Transmission Control Protocol/Internet Protocol (TCP/IP) verwendet, so ist die vollst¨andige und reihen¨ folgerichtige Ubertragung der Daten zugesichert. St¨orungen in der Kommunikation k¨ onnen von den Kommunikationspartnern aufgedeckt und behandelt 32

auch via Industrial Ethernet, der Ethernet-Variante f¨ ur industrielle Produktionsumgebungen

244

6. Softwareengineering

werden. Nicht gesichert ist allerdings die korrekte Interpretation der Daten durch die Gegenstelle. Ausserdem ist diese Schnittstelle prinzipiell nicht gegen Datenverlust gesch¨ utzt: Tritt eine St¨ orung auf, nachdem der Kommunikationspartner die Nachricht ausgelesen hat, aber bevor er diese verarbeiten konnte, ist die Nachricht verloren. Diesem Verlust muss durch Quittungen und Sendewiederholungen begegnet werden, was die Implementierung einer solchen Schnittstelle aufw¨ andig macht. Feldbussysteme Das Umfeld im industriellen Produktionsbereich stellt besondere Anforderungen an die Komponenten von Kommunikationseinrichtungen. Ger¨ate, die typischerweise in einer B¨ uroumgebung eingesetzt werden, sind hier aufgrund mechanischer und elektrischer St¨ oreinﬂ¨ usse nicht geeignet. Feldbussysteme sind f¨ ur entsprechende Umgebungen ausgelegt und bieten zudem besondere Zusicherungen, wie z. B. garantierte maximale Signallaufzeiten, priorisierte Nachrichtenzustellung und Ausfallsicherheit. Beispiele f¨ ur Feldbussysteme sind • CAN (Controller Area Network), • PROFIBUS (Process Field Bus), • I2 C-Bus. Die u ¨ber ein Feldbussystem ausgetauschten Informationen sind in der Regel abh¨ angig von den Eigenschaften und M¨oglichkeiten des Bus-Systems (s. Seite 165). Pipes und Queues Mit diesem Verfahren ist es m¨ oglich, eine große Menge von Daten in einen Zwischenspeicher zu schreiben. Der Zeitpunkt der Verarbeitung der Daten beim Kommunikationspartner kann zu einem beliebigen, sp¨ateren Zeitpunkt erfolgen. Dadurch werden z. B. langsamere Datenkonsumenten von schnelleren Datenlieferanten wirksam entkoppelt. Diese Art der Kommunikation ist also asynchron. Das bedeutet auch, dass der Sender der Daten lediglich Sicherheit dar¨ uber erh¨ alt, dass die Informationen seinen Prozess verlassen haben, nicht aber, ob sie von der Gegenstelle auch empfangen und verarbeitet wurden. Messaging Das Messaging erweitert das Prinzip der Queues und Pipes um zwei weitere Aspekte. Zum einen kann die Informationsverarbeitung in ein TransaktionsKonzept integriert werden. Tritt w¨ ahrend der Verarbeitung einer Information eine St¨ orung auf, kann die gesamte Transaktion r¨ uckg¨angig gemacht werden und die Informationen verbleiben f¨ ur einen sp¨ateren Verarbeitungsversuch in einer Queue. Zum anderen k¨ onnen Daten eingespeist und an einen oder mehrere Empf¨ anger verteilt werden (Load Balancing).

6.5 Application-Server (Java EE)

245

Besonders stark integriert ist das Messaging im Application-Server-Konzept 33 , welches individuelle Transaktionen auf den unterschiedlichsten Ressourcen zu verteilten Transaktionen zusammenfasst.

6.5 Application-Server (Java EE) Als Application-Server werden ganz allgemein Server bezeichnet, auf denen Anwendungen (Applications) abgearbeitet werden. Application-Server stellen dazu eine standardisierte Laufzeitumgebung zur Verf¨ ugung, die sich die darauf laufenden Anwendungen teilen. Der Schwerpunkt soll hier auf Java EE liegen, auch als J2EE bezeichnet. Eine Einf¨ uhrung in Java EE ist in [52] zu ﬁnden. Da das hier vorgestellte Application-Server-Konzept auf der Programmiersprache Java beruht, ist der Einsatz der Application-Server, wie die Programmiersprache selbst, plattform¨ ubergreifend m¨oglich. Java wird unter anderem von den folgenden Plattformen unterst¨ utzt: • • • • •

Microsoft Windows Linux z/Linux Solaris MacOS X

Die Implementierung von Anwendungen f¨ ur Application-Server impliziert eine Reihe von Konventionen und Entwurfsmustern. Damit verbunden ist ein hoher Einarbeitungsaufwand. Andererseits gew¨ahrleisten die Konventionen und Muster aber gute Wartbarkeit, Skalierbarkeit und Flexibilit¨at. Application-Server werden durch Schichtenmodelle realisiert. Die Schich¨ ten einer Application-Server-Anwendung werden auch Tiers genannt. Ublich sind mindestens drei Tiers: 1. Pr¨ asentation 2. Gesch¨ aftslogik 3. Datenbeschaﬀung Datenbeschaﬀung und Datenbank Zur Datenhaltung wird ein konventionelles relationales Datenbanksystem verwendet. Die Tabellen und deren Spalten in der Datenbank bilden das so genannte Datenmodell. Das Datenmodell wird durch die verschiedenen Services im Application-Server in Entities u uhrt. Eine Entity ist eine objektori¨ berf¨ entierte Klasse, die jeweils eine Zeile einer Tabelle der relationalen Datenbank darstellt. Diese Beziehung zwischen Objekten einerseits und Zeilen in 33

siehe auch Kapitel 6.5

246

6. Softwareengineering

Mobiles Datenterminal

Desktop PC

Webbrowser

WMS-Host

LeitstandAnwendung

WMS

Application Server Webapplikation TransportProzess

WareneingangsProzess

...

WareneingangBean

TopologieBean

ArtikelstammBean

LagerfachService

ArtikelstammService

...

Geschäftslogik TransportBean

...

Datenbeschaffung AuftragService

Relationale Datenbank

Abbildung 6.6. Eine exemplarische Application-Server-Anwendung.

einer Datenbanktabelle andererseits wird objektrelationales Mapping (ORMapping) genannt. Dabei ist zun¨ achst nachrangig, ob zuerst die DatenbankStrukturen oder die Entities entwickelt werden. Auf beiden Seiten sind jedoch Einschr¨ ankungen zu beachten, damit ein OR-Mapping u ¨ berhaupt funktionieren kann, und in der Praxis ist Fachwissen und Erfahrung aus beiden Welten, der relationalen und der objektorientierten, unerl¨asslich. Es ist nicht ungew¨ ohnlich, dass lediglich die eine Seite von Hand entwickelt werden muss und die andere automatisch generiert wird. Die SAPNetWeaver-Plattform beispielsweise geht von existierenden Tabellen aus, welche automatisch in Entities u uhrt werden. Die JBoss-Plattform mit Hi¨berf¨ bernate als OR-Mapper geht den anderen Weg und erwartet Entities, f¨ ur die dann automatisch Datenbanktabellen generiert werden. Allerdings hat bislang jeder Automatismus noch Potenzial zur Optimierung der generierten Datenstrukturen gelassen.

6.5 Application-Server (Java EE)

247

Gew¨ ohnlich besitzen relationale Datenbanksysteme ein ausgefeiltes Rechtemanagement. Darin k¨ onnen Rollen deﬁniert werden, die dar¨ uber entscheiden, ob ein Mitglied dieser Rolle einzelne Tabellen oder Views einsehen, andern, darin einf¨ ugen oder l¨ oschen darf und vieles mehr. Dieses Rechtemana¨ gement kann zwar auch in den Anwendungen auf Application-Servern genutzt werden. Die Regel ist jedoch, dass der Application-Server nur mit einem einzigen User-Account pro Anwendung die Datenbank anbindet und s¨amtliche Operationen mit diesem einen Account, aber m¨oglicherweise mit mehreren Verbindungen gleichzeitig durchf¨ uhrt. Dies ist f¨ ur die im Application-Server eingesetzten Optimierungen (Connection-Pooling und Caching) sogar dringend erw¨ unscht. Die Authentiﬁzierungsmechanismen werden also an den Application-Server und seine Anwendungen delegiert. Gesch¨ aftslogik Die Gesch¨ aftslogik hat im Wesentlichen die Aufgabe, f¨ ur einen bestimmten Anwendungsfall die notwendigen Methoden bereitzustellen. Zur Veranschaulichung folgt das einfache Beispiel eines trivialen Wareneingangs (s. dazu auch Abbildung 6.6). Der Wareneingangsmitarbeiter soll die folgenden Daten angeben: • • • •

die Artikelnummer der eingehenden Ware, die Anzahl der Artikel, die auf der neuen Palette lagern, die Paletten-ID, auf der die eingehende Ware eingelagert werden soll, den Ort, auf dem die neue Palette steht.

Der einfachste Wareneingang ben¨ otigt also lediglich eine einfache Methode in der WareneingangBean, z. B. : WareneingangBean.neuePalette (artikelnr, anzahl, palettenId, ortsbezeichnung) Die Gesch¨ aftslogik nimmt diese Daten entgegen. Anhand der Artikelnummer wird mit Hilfe des ArtikelstammService die passende ArtikelstammEntity ermittelt, mit Hilfe eines PalettenService wird eine neue PaletteEntity angelegt und mit der neuen Paletten-ID eindeutig benannt, mit Hilfe des LagerfachService wird das aktuelle LagerfachEntity ermittelt. Die Daten werden von der Gesch¨ aftslogik miteinander verkn¨ upft: Dem Lagerfach wird die neue Palette zugef¨ ugt und der Palette wird die angegebene Anzahl von Artikeln mit der angegebenen Artikelnummer zugef¨ ugt. Dabei achtet die Gesch¨ aftslogik darauf, dass die Paletten-ID eindeutig ist und nicht bereits anderweitig im Lager verwendet wird, dass die Artikelnummer g¨ ultig und nicht gesperrt ist, dass das angegebene Lagerfach eine weitere Palette u ¨ berhaupt aufnehmen darf und so weiter. Die Gesch¨ aftslogik ist stark abh¨ angig vom Prozess, der im Lager ablau¨ ¨ fen soll. Anderungen an der am Prozess f¨ uhren schnell zu einer Anderung

248

6. Softwareengineering

Gesch¨ aftslogik. Beispielsweise k¨ onnte eine Auskunftsfunktion vorgesehen werden, anhand der ein Wareneingangsmitarbeiter nach einer Artikelnummer suchen kann. Des Weiteren k¨ onnte der Lagerbeh¨alter vom System anhand der Artikelstammdaten vorgegeben werden usw. Die Gesch¨ aftslogik ist in der Regel von einem entfernten Rechner aus erreichbar. Damit ist die Gesch¨ aftslogik auch die Stelle in der Anwendung, an der die Benutzerauthentiﬁzierung erfolgen muss. Die Anwendung in einem Application-Server kann dazu f¨ ur jede einzelne Gesch¨aftslogik-Bean oder sogar f¨ ur einzelne Methoden einer Bean Regeln deﬁnieren. Grunds¨atzlich kann so das Konzept von Rollen und Anwendern realisiert werden, wie dies auch in einem relationalen Datenbanksystem m¨oglich ist. Im Falle des Application-Servers ist jedoch meist die Abstimmung zwischen Rolle, Aufgabe (Gesch¨ aftslogik-Bean) und Berechtigung einfacher, denn im ApplicationServer werden die Berechtigungen eben nach Aufgabe verteilt und nicht, wie in der Datenbank, nach Tabellen (also Daten). Web-Applikation Application-Server bieten grunds¨ atzlich einen eigenen Webserver. Das hat dann den Vorteil, dass eine Webanwendung, auch Web-Applikation oder Webapp genannt, sehr eng mit der u ¨ brigen Anwendung zusammenarbeiten kann. Eine Web-Applikation ist eine Benutzerschnittstelle34 , sie erm¨oglicht die Interaktion von Menschen mit der Anwendung. Bei einer Webanwendung wird dazu ein Internetbrowser ben¨ otigt, mit dem die Seiten der Webanwendung abgerufen werden k¨ onnen. Prinzipiell k¨ onnen keine Daten vom Webserver an einen Browser u ¨bertragen werden, außer der Browser fragt diese Daten an35 . Die Konzepte der Web-Applikation und der u ¨ brigen Application-ServerAnwendung erg¨ anzen sich sehr gut. Ein Webserver erh¨alt einen Aufruf von einem Browser, ruft im Zuge der Bearbeitung dieses Aufrufs Methoden der untergeordneten Anwendung auf und fasst die Ergebnisse in einer Antwort zusammen, dem zur¨ uckgelieferten HTML-Dokument, welches ein Browser darstellt. Das zur¨ uckgelieferte HTML-Dokument besitzt seinerseits Buttons, Links oder andere interaktive Elemente, mit denen dann der n¨achste Aufruf zum Webserver erfolgen kann und so weiter. Auch f¨ ur Web-Applikationen existieren Mechanismen zur Benutzer-Authentiﬁzierung. Diese k¨ onnen mit den Mechanismen der u ¨ brigen Anwendung koordiniert werden. Denkbar ist prinzipiell auch, dass die Benutzerauthentiﬁzierung ausschließlich in der Web-Applikation erfolgt und die restliche Applikation v¨ ollig oﬀen gehalten wird. Damit wird allerdings die Authentiﬁzierung an das User Interface delegiert, was eher nicht zu empfehlen ist: 34 35

engl. User Interface oder UI Allerdings ist es m¨ oglich, dem Browser in einer ausgelieferten Seite mitzuteilen, dass er nach einer deﬁnierten Anzahl von Sekunden eine Seite nachladen soll, worauf wiederum der Webserver ein weiteres Mal das gleiche oder ein anderes Dokument ausliefert.

6.5 Application-Server (Java EE)

249

• Die Anzahl der User Interfaces ist in der Regel gr¨oßer oder gleich der Anzahl der Gesch¨ aftslogiken, die von den User Interfaces genutzt werden. Die einmalige Implementierung an zentraler Stelle erfordert weniger Aufwand. • Authentiﬁzierung von Benutzern ist Gesch¨ aftslogik und sie ist gesch¨aftsrelevant, also sensibel. • Sp¨ atestens, wenn das User Interface nicht mehr im Application-Server ausgef¨ uhrt wird, was auch mit Web-Applikationen m¨oglich ist, w¨ urde eine oﬀene, unauthentiﬁzierte Schnittstelle betrieben, die per Deﬁnition nicht kontrollierbar ist. Client ¨ Ubrig bleiben externe Zugriﬀe auf eine Application-Server-Anwendung. Diese Variante ist ein verteiltes System36 . Abgebildet werden diese Zugriﬀe u ¨ber einen in Java realisierten und transparenten Mechanismus der Objektserialisierung37 mittels RMI38 und JNDI39 . Diese Mechanismen arbeiten vollst¨ andig transparent. Die externe Applikation kann auf die entfernten Gesch¨ aftslogik-Beans zugreifen, als seien es lokale Objekte. Zugriﬀe auf entfernte Objekte kosten allerdings gegen¨ uber lokalen Zugriffen ein Vielfaches der Zeit. Zudem werden die Daten aus lokalen Objekten in der Regel nicht u ¨ bermittelt, sondern deren Referenz wird u ¨bergeben. Daten¨ ubergaben an entfernte Objekte oder von entfernten Objekten bed¨ urfen ¨ dagegen der Ubermittlung der Daten. Die u ¨ bergebenen Daten werden also bei entfernten Zugriﬀen kopiert. Daraus ergeben sich zwei Anforderungen an das Design der Anwendung: 1. Datensparsamkeit: Je weniger Daten bei einem Methodenaufruf u ¨bermittelt werden m¨ ussen, desto schneller wird dieser abgearbeitet werden k¨ onnen. 2. Minimale Anzahl von Aufrufen: Je ¨ ofter Aufrufe get¨atigt werden m¨ ussen, desto mehr Zeit geht durch verteilte Aufrufe verloren. In der Praxis f¨ uhrt das dazu, dass die so genannten Transfer-Objekte eingef¨ uhrt werden, die alle ben¨ otigten Informationen eines entfernten Methodenaufrufs kapseln. Es werden vorzugsweise elementare Datentypen u ¨ bermittelt, da diese am schnellsten zu u ¨bermitteln sind. Zudem werden die Methoden so ausgelegt, dass m¨ oglichst pro Prozess-Schritt im Benutzerinterface nur ein Methodenaufruf notwendig ist, der alle relevanten zu u ¨ bermittelnden Parameter sammelt. 36 37 38 39

siehe auch Kapitel 6.1.4 Die Objekte werden in eine u uhrt, u ¨ bertragbare Datenstruktur u ¨ berf¨ ¨ bertragen und auf der Empf¨ angerseite wieder in die Objektform u uhrt. ¨ berf¨ siehe auch Kapitel 6.6 Java Naming and Directory Interface, ein in der Java-Plattform anzusiedelnder einheitlicher Namens- und Verzeichnisdienst.

250

6. Softwareengineering

Oft geh¨ ort ist der Wunsch nach generischen Schnittstellen, die eine Vielzahl von m¨ oglichen Prozessen am Benutzerinterface abdecken k¨onnen. Der Aufwand, einen ge¨ anderten Prozess abzubilden, soll m¨oglichst gering gehalten werden. Generische Schnittstellen sind aber deﬁnitionsgem¨aß nicht prozessspeziﬁsch. Gerade an der Schnittstelle zum Client sollte klar werden, dass sich hier zwei widerspr¨ uchliche Ziele gegen¨ uber stehen: 1. generische Schnittstellen mit einem Maximum an Prozessﬂexibilit¨at, aber schlechter Performance 2. hoch spezialisierte Schnittstellen mit einem Maximum an Performance, aber schlechter Prozessﬂexibilit¨ at Das Application-Server-Konzept, insbesondere die aktuellen Entwicklungen, versuchen hier einen guten Kompromiss zu ﬁnden. Es k¨onnen hoch performante Applikationen entwickelt werden. Dabei ist der Aufwand bei ¨ Anderungen f¨ ur eingearbeitete Entwickler u ¨ berschaubar und selbst h¨auﬁge Inbetriebnahmen neuerer Versionen im Produktiv-System werden vom Application-Server gut unterst¨ utzt.

6.6 Service-orientierte Architektur (SOA)

251

6.6 Service-orientierte Architektur (SOA) SOA ist die Abk¨ urzung f¨ ur service oriented architecture oder Service-orientierte Architektur. SOA beschreibt selbst keine Technologie, sondern stellt ein Konzept dar. Service-orientierte Architekturen haben das Potenzial, schnell auf sich ¨ andernde Anforderungen an die Gesch¨aftsprozesse eines Unternehmens zu reagieren. Durch den Einsatz von SOA wird ein Unternehmen also agiler. Eine SOA besitzt die folgenden Eigenschaften [12]: Lose Kopplung Aufrufende und aufgerufene Beteiligte sind weitestgehend voneinander entkoppelt. Damit kann ein Beteiligter durch einen anderen ¨ ersetzt werden, ohne dass Anderungen an dem oder den anderen Beteiligten notwendig sind. Aufrufe sind m¨ oglich, ohne die zugrunde liegende Implementierung eines Services zu kennen. Die lose Kopplung leistet damit einen erheblichen Beitrag zur Abstraktion. Kontrakt Services und deren Benutzer sind an die jeweilige SchnittstellenSpeziﬁkation des Service gebunden. Darin werden die Parameter und R¨ uckgabewerte eines jeweiligen Service festgelegt. Autonomie Die Services steuern die in ihnen enthaltene Logik autonom. Abstraktion Services verbergen die in ihnen enthaltene Logik und deren Implementierung40 . Wiederverwendbarkeit Der Service kann von unterschiedlichen Aufrufern genutzt werden. Komposition Die einzelnen Services k¨ onnen in zusammengesetzten Services41 verwendet werden. Die Komponierbarkeit der Services st¨ arkt daher deren Wiederverwendbarkeit. Grunds¨ atzlich lassen sich so auch Services anlegen, deren prim¨arer Zweck in der Komponierbarkeit und der Wiederverwendbarkeit liegt und die damit andere Services st¨ utzen. Zustandsfreiheit Services minimieren zustandsbehaftete Operationen42 . Im Idealfall reicht eine Botschaft an einen Service aus, um die jeweilige Operation vollst¨ andig auszuf¨ uhren. Zustandsfreiheit tr¨agt dazu bei, die Abh¨ angigkeiten einer Software klein zu halten, und leistet einen Beitrag zur Robustheit einer Software. Auﬃndbarkeit Services sind selbstbeschreibend, so dass sie u ¨ ber Suchmechanismen gefunden und dann genutzt werden k¨onnen. Dieser Aspekt wird durch den Service-Kontrakt erm¨ oglicht und f¨ordert damit die Wiederverwendbarkeit. Auﬃndbarkeit kann auch durch ein Dienste-Verzeichnis (engl. Repository) gew¨ ahrleistet werden. 40 41 42

¨ Der Fachbegriﬀ f¨ ur etwas, dessen Außeres, nicht aber dessen Inneres bekannt ist, lautet Blackbox. sog. Composite Services Hiermit ist insbesondere der technische Aspekt gemeint und nicht der Zustand von Gesch¨ aftsvorf¨ allen.

252

6. Softwareengineering

Die Beteiligten (Aufrufer und Aufrufender) k¨onnen an verschiedenen ¨ Standorten oder in verschiedenen Softwareprozessen betrieben werden. Ublicherweise, aber nicht notwendigerweise ist ein Netzwerk beteiligt, u ¨ber welches eine Verbindung hergestellt wird. Services k¨ onnen als weitere Entwicklungsstufe klassischer Komponenten gesehen werden: Auch diese haben ein per Kontrakt festgeschriebenes Inter¨ face und sie k¨ onnen ohne Anderung per Komposition zu neuen Komponenten zusammengefasst werden. Zur Implementierung einer SOA kommen unter anderem folgende Technologien in Frage: RPC Die Abk¨ urzung RPC steht f¨ ur Remote Procedure Call. Funktionen und Prozeduren werden konventionell in einem Server implementiert und im Rahmen eines Server-Prozesses gestartet. Ein entferntes Programm kann diese Funktionen dann u ¨ ber das Netzwerk aufrufen. XML-RPC Es handelt sich um eine Variante, entfernte Funktionen und Prozeduren aufzurufen. Die Daten werden dabei in Form von XMLBotschaften ausgetauscht. XML-RPC kann als ein Vorl¨aufer zum SOAP (siehe unten) betrachtet werden. CORBA Die Abk¨ urzung CORBA steht f¨ ur Common Objekt Request Broker Architecture und stellt die objektorientierte Erweiterung von RPC dar. Es werden nicht einzelne Funktionen f¨ ur den Fernzugriﬀ exponiert, sondern ganze Serverobjekte mit ihren Methoden stehen f¨ ur entfernte Prozesse zur Verf¨ ugung. CORBA ist plattformunabh¨angig und in vielen objektorientierten Programmiersprachen verf¨ ugbar. RMI Die Abk¨ urzung RMI steht f¨ ur Remote Method Invocation. RMI ist wie CORBA eine objektorientierte Variante f¨ ur den Zugriﬀ auf entfernte Objekte. RMI ist aber im Wesentlichen auf die Programmiersprache Java beschr¨ ankt und dort sehr gut integriert. Obwohl auch Java direkt an CORBA anschließt, ist eine Kopplung zwischen RMI und CORBA prinzipiell m¨ oglich. RMI ist, wie Java an sich auch, plattformunabh¨angig. Die Kopplung anderer Programmiersprachen ist allerdings nicht Ziel von RMI [53]. ur Simple Object Access SOAP Urspr¨ unglich steht die Abk¨ urzung SOAP f¨ Protocol. Neben anderen Deutungen43 ist SOAP mittlerweile vor allem ein Eigenname (vgl. [78], [79]). Webservice Webservice kombiniert drei Standards: • UDDI (Universal Description, Discovery and Integration), ein Verzeichnisdienst, an dem sich die zur Verf¨ ugung stehenden Dienstanbieter anmelden und u ¨ ber den sie von den Dienstanwendern lokalisiert werden • WSDL (Web Services Description Language) zur Beschreibung der angebotenen Dienste, also deren Funktionen/Prozeduren und Parameter • SOAP oder XML-RPC (siehe oben) zum eigentlichen Datenaustausch 43

z. B. Service Oriented Architecture Protocol

6.6 Service-orientierte Architektur (SOA)

253

Jini ist ein Java-basiertes Rahmenwerk mit besonderem Fokus auf Skalierbarkeit. Jini 44 deﬁniert, wie sich Dienste (Server) und Dienstnutzer (Clients) in einem Netzwerk ﬁnden. Die eigentliche Netzwerkkommunikation kann z. B. u ¨ ber RMI, SOAP oder CORBA erfolgen. In den meisten Unternehmen existiert bereits eine IT-Infrastruktur. Diese ist m¨ oglicherweise nicht nach den Prinzipien der SOA eingef¨ uhrt worden. Wird dennoch das Ziel gesetzt, eine SOA zu implementieren, sind einige Punkte zu beachten: Die Services einer SOA eines Unternehmens sollten den Gesch¨ aftsprozessen folgen. Dabei sollten kleine u ¨ berschaubare Schritte get¨ atigt werden. Eine im SOA-Umfeld oft zitierte Maxime lautet Think big, start small. Die Entwicklung und Einf¨ uhrung neuer Services einer SOA sollte von den Gesch¨ aftsprozessen getrieben werden. Der Sicherheit der implementierten SOA kommt eine besondere Bedeutung zu: • Welche Auswirkungen hat die Einf¨ uhrung von SOA auf die Verf¨ ugbarkeit der gesch¨ aftskritischen IT-Infrastruktur? • Welche Sicherheitsmechanismen werden eingesetzt45 ? Die u onnen einfach von anderen Applika¨ ber SOA exponierten Dienste k¨ tionen genutzt werden. Dies f¨ uhrt m¨ oglicherweise zu einer erh¨ohten oder sogar inﬂation¨ aren Nutzung einiger Dienste. Insbesondere bei Auskunftsdiensten ist dies zu erwarten. Diese Dienste ben¨ otigen daher in einer SOA-Umgebung mehr Computerleistung. Zus¨ atzlich wird durch die Einf¨ uhrung von SOA auch die restliche IT-Infrastruktur durch die einhergehende h¨ohere Abstraktion und mehr Kommunikation st¨ arker belastet. Unter dem Begriﬀ SOA kann sicherlich die gesamte Kommunikation zwischen den Komponenten und Applikationen einer Unternehmens-IT saniert werden. Die Auseinandersetzung mit SOA sollte daher mit einer Betrachtung der aktuellen Schnittstellen beginnen. Davon ausgehend ist es hilfreich, eine Vorstellung davon zu entwickeln, wie eine SOA in einem Unternehmen realisiert werden kann. Dennoch sollten zun¨ achst nur die dr¨angenden, aktuellen Aufgaben in der SOA-Welt realisiert werden. Sollen beispielsweise LegacyAnwendungen46 an neuere Applikationen angeschlossen werden, bietet es sich an, SOA-Adapter (engl. Wrapper ) zu den alten Legacy-Applikationen zu schaﬀen. Dies bietet zum einen den Vorteil eines u ¨berschaubaren Arbeitspaketes zur Realisierung und erm¨ oglicht andererseits einen guten Vergleich 44

45 46

Eine oﬃzielle Erkl¨ arung des Wortes Jini wird vom Hersteller Sun nicht gegeben; eine m¨ ogliche/¨ ubliche Interpretation lautet Java intelligent network infrastructure. Bleibt noch anzumerken, dass die meisten Java-Technologien mit dem Buchstaben J beginnen und die Aussprache im Englischen dem Wort Genie ahnelt. ¨ Insbesondere, wenn fremde Unternehmen angebunden werden sollen. Als Legacy-Anwendungen werden alte Softwaresysteme bezeichnet, die aus historischen Gr¨ unden noch weiterbetrieben werden, deren Technologie aber veraltet ist.

254

6. Softwareengineering

gegen¨ uber einer konventionellen Realisierung. Gesteigerte Anforderungen an die Infrastruktur k¨ onnen iterativ kompensiert werden. Fr¨ uher oder sp¨ ater wird es notwendig sein, die betroﬀenen SOA-Komponenten (Soft- und Hardware) unternehmensweit zu katalogisieren. Eine Katalogisierung ist auch ratsam bez¨ uglich der unterschiedlichen Technologien, mit denen bestehende Systeme m¨ oglicherweise eigene Dienste anbieten. Zudem verf¨ ugen die Hersteller einiger eingesetzter Systeme u ¨ ber eigene Pl¨ane, was den Aufbau der Kataloge und den Ausbau der Dienste angeht.

7. Implementierung eines WMS am Beispiel myWMS

Es existiert eine Vielzahl unterschiedlicher Warehouse Managementsysteme(WMS). Sie unterscheiden sich • • • • •

im Umfang ihrer Funktionalit¨ at, in ihren Schnittstellen, in der erforderlichen Hardware, in den ben¨ otigten Betriebssystemen, in ihren Bedienkonzepten

und in weiteren Punkten, nicht zuletzt in den Investitionskosten. Zumeist bedeutet die Festlegung auf ein WMS die langfristige Bindung des Lagerbetreibers an den Hersteller und damit die Abh¨ angigkeit bei der Erweiterung der Funktionalit¨ at, dem Ausbau der Schnittstellen und dem Austausch der Hardware. Ein modulares und oﬀenes Warehouse Managementsystem, das unabh¨angig von Hardware und Betriebssystem und in einer auf breiter Basis akzeptierten Programmiersprache implementiert ist, ist zur Schaﬀung einer Kompatibilit¨ at zu Produkten und Bausteinen verschiedener Quellen und Hersteller hilfreich. Dadurch kann eine eﬃziente Anpassung an die schnell wechselnden Gegebenheiten des Marktes gew¨ ahrleistet werden. Eine derartige ganzheitliche L¨ osung f¨ ur WMS wird seit dem Jahr 2000 am Fraunhofer IML1 unter dem Namen myWMS2 entwickelt. Es handelt sich hierbei um ein auf dem Baukastenprinzip beruhendes Rahmenwerk (Framework) f¨ ur Warehouse Managementsysteme. Es stellt eine Menge von Softwaremodulen und Regeln f¨ ur die softwaretechnische Konstruktion zur Verf¨ ugung, welche die Erstellung eines WMS unterst¨ utzen. myWMS ist ein Open-SourceProjekt. Seit M¨ arz 2009 ist der Quelltext unter der oﬀenen GNU General Public License (GPL) verf¨ ugbar. Damit steht myWMS nicht nur f¨ ur nichtkommerzielle Anwendungen kostenfrei zur Verf¨ ugung, sondern ist f¨ ur jedwede Anwendung gem¨ aß GPL frei nutzbar. Die Software wird von einer Gruppe3 aus Anwendern und Softwareh¨ ausern entwickelt. Mit der freien Distribution 1 2 3

Fraunhofer-Institut f¨ ur Materialﬂuss und Logistik, Dortmund siehe hierzu http://www.mywms.org siehe hierzu http://www.mywms.org/community/partners.jsp

256

7. Implementierung eines WMS am Beispiel myWMS

von myWMS LOS steht ein vollwertiges WMS zur Verf¨ ugung, das ebenfalls unter der GPL Lizenz ver¨ oﬀentlicht ist4 . myWMS LOS ist gem¨ aß der Java Enterprise Edition 5 (Java EE 5) Speziﬁkation (vgl. Abschn. 6.5) programmiert. Die Speziﬁkation umfasst die Architektur von modularen Softwarekomponenten und Diensten zur Programmierung von verteilten, mehrschichtigen Anwendungen. Dar¨ uber hinaus beschreibt sie deﬁnierte Schnittstellen zwischen Komponenten und LaufzeitContainern, sodass eine hohe Interoperabilit¨ at zwischen diesen sowie eine hohe Skalierbarkeit der gesamtem Anwendung gew¨ahrleistet ist. Eine Schulungsversion von myWMS LOS mit weiteren Informationen, Quelltexten und einer Beispielapplikation ist online verf¨ ugbar. Details zur Installation ﬁnden sich am Ende des Buches. In diesem Kapitel wird zun¨ achst ein allgemeines Datenmodell diskutiert, wie es in der Praxis bei vielen Warehouse Managementsystemen anzutreﬀen ist und welches auch die Grundlage f¨ ur myWMS bildet. Danach wird der klassische Ansatz zur Realisierung eines WMS aufgezeigt. Nachfolgend werden die elementaren Strukturen von myWMS vorgestellt, und abschließend wird an einem Beispiel der praktische Einsatz von myWMS demonstriert.

7.1 Datenmodell Die Grundlage eines jeden WMS ist ein Datenmodell, das die Basis der Verwaltung der vielf¨ altig auftretenden Datenbest¨ ande und Datenstr¨ome im Betrieb eines Lagers darstellt. Ein Datenmodell bildet, die f¨ ur eine Anwendung relevanten Teile der Realit¨ at in softwaretechnische Strukturen (Datenstrukturen) ab. Der erste Schritt der Modellierung ist die Analyse der f¨ ur ein WMS relevanten Daten, ihrer Strukturen und ihre formale Beschreibung. In einem nachfolgenden Schritt m¨ ussen die Beziehungen der Daten zueinander analysiert und speziﬁziert werden. Datencontainer des Modells Die nummerierten K¨astchen der Abb. 7.1 stellen die Datencontainer, im Folgenden Container (Datenhalter) genannt, f¨ ur die Daten eines WMS dar. Ein Container nimmt gleich strukturierte und logisch zusammenh¨ angende Daten auf. Die Speziﬁzierung der exakten Dateninhalte eines Containers ist dabei zun¨ achst von untergeordneter Bedeutung. So kann beispielsweise im Container 1c der Abb. 7.1, also in dem den Kunden repr¨asentierenden Container, nur eine Kundennummer oder die ausf¨ uhrliche Auﬀ¨ uhrung der den Kunden beschreibenden Daten wie Vorname, Name, Lieferadresse, Rechnungsadresse, Telefonnummern etc. stehen. Wichtig ist an dieser Stelle zun¨achst, dass die Container in dem Modell vorhanden und deren Bedeutungen eindeutig deﬁniert sind und sie Teile der Realit¨ at darstellen. 4

siehe hierzu http://www.mywms.org/los

7.1 Datenmodell 1c

1a

Kunde

Lieferant

Warenwirtschaftssystem

1b 1

257

1

m

m

Hersteller

1

1

1

2 Warengruppe m

3

m

m supply (WEAnforderung)

n n

4

n

m

itemData (Artikelstamm)

Personalverwaltung

1 m

m

6

stockUnit (Artikel)

5

n m

n n

m

Beispiel WMS

m m

n

9

7 stockUnitCategory (Artikelgruppe)

m

8

m

order (WAAnforderung)

1

unitLoad (Ladehilfsmittel)

worker (Arbeiter)

1

1

loadHandler (Maschine) 1

m

n

Mandantenverwaltung

m 1

11

10

location (Lagerplatz) 1

12 m

n

locationCategory (Lagerplatzgruppe)

1

13 Qualitätssicherung

orderChain (Transportauftrag)

Speditionswesen

Abbildung 7.1. Das Datenmodell eines Warehouse Managementsystems mit den angrenzenden Systemen. Die gestrichelte Linie grenzt das WMS von seiner Umgebung ab. Doppelt beschriftete Datencontainer zeigen die in myWMS verwendete Bezeichnung und darunter in Klammern die deutschsprachige Benennung.

• Lieferant: Der Container 1a enth¨ alt die Daten, welche die Zulieferer eines Lagers beschreiben. • Hersteller: Der Container 1b beinhaltet die Daten der Hersteller der einzelnen Artikel. • Kunden: Der Container 1c enth¨ alt die Daten der Kunden, die aus diesem Lager beliefert werden. • Warengruppe: Innerhalb eines Lagers ist eine Gruppierung der Artikel nach verschiedenen Kriterien m¨ oglich, die mit Container 2 realisiert wird. Die Nummerierungen f¨ ur die drei ersten Container lautet 1a, 1b und 1c. Da es vorstellbar ist, dass ein Lieferant auch Kunde oder ein Hersteller auch Lieferant (und umgekehrt) sein kann, w¨ are hier zur Vermeidung redundanter Datenhaltung eine Zusammenlegung der Container 1a, 1b und 1c zu einem Container empfehlenswert, der eine juristische Person repr¨asentiert. Die Kenntnis u ur ein WMS nicht relevant und daher, ge¨ber diese Personen ist f¨ nau so wie der Container f¨ ur die Warengruppe, in Abb. 7.1 außerhalb der gestrichelten Linie gezeichnet. Im Folgenden werden die f¨ ur das WMS relevanten Datenhalter beschrieben, die auch von externen Systemen (z. B. Personalverwaltung, Qualit¨ats-

258

7. Implementierung eines WMS am Beispiel myWMS

sicherung und Warenwirtschaft) ben¨ otigt werden (s. 262). Dabei wird hier jeder Container doppelt benannt: zuerst deutschsprachig, gefolgt von einer technischen Benennung aus Begriﬀen der englischen Sprache. Begriﬀe, wie sie allgemein u ¨blich sind und im myWMS-Projekt verwendet werden. • WEAnforderung (Supply): Unter einem Supply wird eine ausgehende Bestellung (und gegebenenfalls deren Ausf¨ uhrung) von Artikeln f¨ ur das Lager verstanden. • Artikelstamm (ItemData): Der Container 4 beinhaltet die Metadaten zu den konkreten Artikeln. In ItemData werden die Eigenschaften der Artikel beschrieben und nicht die Bereitstelleinheiten, die sich im Lager beﬁnden und mit einer Seriennummer assoziiert sind. Insbesondere sind hierunter auch die Daten zu verstehen, die f¨ ur die korrekte Lagerung und Bewegung n¨ otig sind, wie etwa Vorzugszone (A, B oder C), erlaubter Lichtund Temperaturbereich, Anzahl der Bereitstelleinheiten pro Palette oder Gefahrgutklasse und Gewichtsangaben (vgl. Abschn. 2.4). • WAAnforderung (Order ): Container 5 enth¨alt eingehende Bestellungen (Kundenauftr¨ age) und ist analog zu dem Container f¨ ur Supply zu verstehen. Lediglich die Lieferanten- und die Kundenseite sind vertauscht. • Arbeiter (worker ): Hier werden Daten u ¨ ber Lagermitarbeiter aufgenommen, beispielsweise von Kommissionierern. Insbesondere sind f¨ ur den Betrieb des Lagers Informationen u ¨ber die Berechtigungen und F¨ahigkeiten der Mitarbeiter f¨ ur den Umgang und die F¨ uhrung von Maschinen, zum Beispiel Gabelstaplern, erforderlich. ¨ • Lagerplatzgruppe (LocationCategory): Uber den Container 12 lassen sich Lagerpl¨ atze gruppieren. Hierdurch k¨ onnen Lagerpl¨atze einer Zone oder Lagergruppe zugeordnet sowie nach anderen Kriterien klassiﬁziert werden. • Transportauftrag (OrderChain): Der Container 13 h¨alt Daten u ¨ ber die einzelnen Bewegungen der Ladehilfsmittel zwischen Lagerpl¨atzen. Er kann als eine Art Mitschrift verstanden werden. Die letzte Gruppe von Containern ist nur innerhalb des WMS relevant. Es gelten die gleichen Namenskonventionen wie bei den oben beschriebenen Schnittstellencontainern. • Bereitstelleinheit (StockUnit ): Im Container 6 werden die Daten zu den Artikeln gehalten, auf deren Metadaten u ¨ber Container 4 (ItemData) zugegriﬀen werden kann. Ein Ger¨ at mit einer Seriennummer stellt die Konkretisierung seines Metadatums dar. Der Fernseher Modell Schau ins ” Land“ mit der Seriennummer 405432100002 stellt beispielsweise einen Eintrag im Container Bereitstelleinheit dar, wogegen im Container Artikelstamm alle Fernseher des Modells Schau ins Land“ beschrieben sind ” ¨ und das konkrete Modell nur Auswirkungen auf den Bestand hat. Ahnliche ¨ Uberlegungen gelten auch f¨ ur Systeme, die keine Seriennummern verwalten.

7.1 Datenmodell

259

• Artikelgruppe (StockUnitCategory): Hier k¨onnen Klassiﬁzierungen u ¨ ber konkrete Bereitstelleinheiten, wie etwa die Chargenbildung oder die Tourennummer des Lieferanten, vorgenommen werden. • Ladehilfsmittel (UnitLoad ): Der Container 9 beschreibt das Ladehilfsmittel, auf dem sich Bereitstelleinheiten beﬁnden k¨onnen. Ein Ladehilfsmittel kann gemischt oder artikelrein belegt sein. • Maschine (LoadHandler ): Die Maschine dient zur Durchf¨ uhrung der physischen Transporte und muss zu diesem Zweck tempor¨ar Ladeeinheiten aufnehmen. Kurzfristig dient eine Maschine damit als Lagerplatz“. ” • Lagerplatz (Location): Im Container 11 werden die Lagerpl¨atze erfasst. Ein Lagerplatz kann belegt oder frei sein. Zus¨atzlich kann, wie bei allen anderen Containern auch, ein Sperrkennzeichen vergeben werden. Die bisher vorgestellten Container beschreiben die Daten eines typischen Lagers. Dieses Modell kann durch zus¨ atzliche Container erweitert werden. So w¨ are beispielsweise ein Container f¨ ur die Gruppierung der Ladehilfsmittel denkbar, um verschiedene Ladehilfsmittel mit partiell gleichen Eigenschaften klassiﬁzieren zu k¨ onnen. Das hier dargestellte Modell geht von dem in der Praxis vorherrschenden Fall weniger Ladehilfsmitteltypen aus und bildet diese Unterschiedlichkeiten in einem Attribut des Containers Ladehilfsmittel ab. Ein konkretes Datenmodell muss nicht alle Container des hier vorgestellten Modells nutzen.

Beziehungen zwischen den Daten W¨ ahrend die Container der Abb. 7.1 die Daten eines WMS beschreiben, werden u ¨ber die Linien in dieser Abbildung die Beziehungen (Relationen) zwischen ihnen aufgezeigt. Dabei sind mehrere Arten von ein- oder zweiseitig gerichteten Beziehungen m¨oglich, deren Vielfachheit durch Zahlen oder Buchstaben am Ende der Verbindungslinie gekennzeichnet sind: • Eine 0 bedeutet, dass keine Beziehung in diese Richtung besteht. Zur Vereinfachung der Darstellung einer Beziehung muss eine 0 nicht dargestellt werden. Beziehungen, die auf beiden Seiten mit 0 beschrieben sind, werden leere Beziehungen genannt, haben keinen Informationsgehalt und werden auch nicht gezeichnet. • Die 1 auf einer Seite einer Beziehungslinie stellt dar, dass auf dieser Seite genau ein Element des Containers dem Container auf der anderen Seite der Linie zugeordnet ist. So hat beispielsweise eine Telefonnummer eine Beziehung zu genau einer juristischen Person (Kunde, Hersteller oder Lieferant). • Steht ein n auf einer Seite einer Beziehungslinie, dann existieren zu dieser Seite bis zu maximal n Beziehungen. So kann beispielsweise eine juristische Person u usse verf¨ ugen, dieses impliziert ¨ ber mehrere Telefonanschl¨ allerdings auch, dass kein Telefonanschluss vorhanden sein kann.

260

7. Implementierung eines WMS am Beispiel myWMS

Im Falle einer mehrfachen Beziehung in beiden Richtungen, wird eine Seite mit n und die andere Seite mit m beschriftet, um anzudeuten, dass die m Vielfachheit unterschiedlich sein kann. So k¨ onnte zum Beispiel eine n Relation zwischen dem Hersteller- und dem Lieferanten-Container aufgezeigt werden, wenn diese relevant w¨ are. Diese Relation k¨onnte zeigen, dass sich ein Hersteller der Leistung von n Lieferanten bedient, ein Lieferant dagegen die m Produkte von m Herstellern f¨ uhrt. Eine n -Beziehungslinie entspricht 0 m somit der symbolischen Zusammenfassung einer n und einer 0 -Linie. Nachfolgend werden alle Beziehungslinien der Abb. 7.1 tabellarisch aufgef¨ uhrt und beschrieben. Dabei werden die Nummern der beteiligten Container jeweils durch eine der oben stehenden Linien verbunden und nachstehend mit einem Namen versehen. n • ( 1a 1 6 ) Lieferung: Diese Relation beschreibt die Lieferung von Artikeln, wobei ein Lieferant mehrere Artikel (n ≥ 0) liefert, ein Artikel aber genau einer Lieferung eines Lieferanten angeh¨ort. Das Datenmodell allein ist nicht in der Lage, sinnvolle Verkn¨ upfungen von unsinnigen zu unterscheiden. So erlaubt diese Relation beispielsweise leere Lieferungen, also auch solche, die keine Artikel enthalten. Die u ¨bergeordnete Logik hat sicherzustellen, dass eine Lieferung mindestens einen Artikel enth¨alt. n ¨ • ( 1a 1 3 ) Bestellung (oder Avis): Uber diese Relation wird eine Bestellung (oder ein Avis) abgebildet. Dabei ist eine Bestellung (ein Avis) genau einem Lieferanten zugeordnet, w¨ahrend ein Lieferant mehreren Bestellungen (Avisen) zugeordnet sein kann. n • ( 1a m 4 ) Katalog: Der Katalog eines Lieferanten beinhaltet die Metadaten verschiedener Artikel, allerdings kann ein Artikel auch von unterschiedlichen Lieferanten bezogen werden. n • ( 1b 1 4 ) Produktliste: Ein Artikel, der hier durch sein Metadatum repr¨ asentiert wird, wird von genau einem Hersteller produziert, dieser kann jedoch mehrere Artikel in seinem Programm f¨ uhren. n • ( 1c m 4 ) Kaufverhalten: Das Kaufverhalten des Kunden kann durch eine Beziehung zwischen Artikelstamm und Kunde beschrieben werden. Ein Kunde kann unterschiedliche Artikel kaufen und ein Artikel kann von unterschiedlichen Kunden gekauft werden. n • ( 1c 1 5 ) Bestellung: Ein Kunde kann im Laufe der Zeit verschiedene Bestellungen absetzen, aber eine Bestellung ist immer genau einem Kunden zugeordnet. n • ( 1c 1 6 ) Seriennummernverfolgung: Diese Relation erlaubt ¨ die R¨ uckverfolgung gelieferter Artikel zum Kunden und umgekehrt. Uber die vom Artikel ausgehende Relation Lieferung (zum Lieferanten) kann beispielsweise ein Garantiefall abgewickelt werden. Auch die Kette f¨ ur R¨ uckrufaktionen schließt sich mit dieser Relation. n • (2 m 4 ) Warengruppenzugeh¨ origkeit: Die Relation Warengruppenzugeh¨ origkeit fasst die Metadaten von Artikeln mit gleichen Ei-

7.1 Datenmodell

•

• • • •

• • • • •

• • • 5

261

genschaften zusammen. Diese Verkn¨ upfung ist eher im Bereich der Shopoder Warenwirtschaftssysteme von u ¨ bergeordnetem Interesse. n (3 m 4 ) Einlagerauftrag: Eine Lieferung f¨ uhrt zu einem Einlagerauftrag, der mit einer Menge von Artikeln in Verbindung steht. Die Verkn¨ upfung einer Lieferung erfolgt nicht nur mit den konkreten Artikeln, sondern auch mit deren Stammdaten. n ( 4 m 4 ) Zusammenlagerungsverbot: Da verschiedene Artikel nicht miteinander gelagert werden d¨ urfen (vgl. Kapitel 2), ist diese Relation erforderlich. n ( 4 m 5 ) Auslagerauftrag: Jeder Kundenauftrag ist mit einer Menge von Artikeln assoziiert, die durch diese Relation mit den zugeh¨ origen Metadaten beschrieben wird. n ( 6 m 7 ) Artikelgruppenzugeh¨ origkeit: Ein Artikel kann mehreren Gruppen angeh¨ oren und jede Gruppe kann eine Vielzahl von Artikeln beinhalten. 1 (6 n 9 ) Ladung: Mittels dieser Relation wird die Zuordnung der Artikel zu den Ladehilfsmitteln beschrieben. Zwar kann ein Artikel immer nur auf genau einem Ladehilfsmittel stehen5 , jedoch kann dieses mehrere Artikel aufnehmen. 0 (8 1 13 ) Arbeitsauftrag, 1 0 (9 13 ) Transportobjekt, 0 ( 10 1 13 ) Transportmedium, 0 ( 11 1 13 ) Transportquelle, 0 ( 11 1 13 ) Transportziel: Diese Relationen gehen alle von einem Transportauftrag aus und sind einseitig. Die Relation Arbeitsauftrag ordnet dem Transportauftrag genau eine Person Arbeiter zu, beispielsweise einen Staplerfahrer f¨ ur einen Fahrauftrag oder einen Kommissionierer f¨ ur einen Kommissionierauftrag. Innerhalb eines vollautomatischen Lagers wird u ¨ ber die Relation Arbeitsauftrag die Verantwortlichkeit beschrieben. Die Relation Transportobjekt beschreibt, welches Ladehilfsmittel bewegt wird. Transportmedium gibt die Beziehung zur ausf¨ uhrenden Maschine an. Die Relationen Transportquelle (source) und Transportziel (destination) sind selbsterkl¨arend. 1 ( 9 n 11 ) Platzbelegung: Jedes Ladehilfsmittel muss genau einem Platz zugeordnet sein. Ein Lagerplatz kann mehrere Ladehilfsmittel aufnehmen. n ( 10 m 11 ) Arbeitsbereich: Ein bestimmter Lagerplatz kann von mehreren Maschinen erreicht werden, allerdings kann auch eine Maschine mehrere Lagerpl¨ atze versorgen. n ( 11 m 12 ) Zonung: Verschiedene Lagerpl¨atze lassen sich in Zonen gruppieren und jeder Zone k¨ onnen viele Lagerpl¨atze angeh¨oren. Artikel, die ohne Ladehilfsmittel transportiert oder gelagert werden, erf¨ ullen durch Zuordnung zu einem virtuellen Ladehilfsmittel“, das physisch nicht vor” handen ist, diese Beziehung.

262

7. Implementierung eines WMS am Beispiel myWMS

Weitere Relationen sind m¨ oglich, die aber selten ben¨otigt werden. So kann m das Modell beispielsweise um eine n -Relation zwischen Arbeiter und Maschine erweitert werden, die u ahigungen zum F¨ uhren bestimm¨ ber die Bef¨ ter Maschinen Auskunft gibt. Die Merkmale u ussten ¨ber die Bef¨ahigungen m¨ dann aus dem Container Arbeiter entfernt werden. Die vorhandenen Relationen k¨ onnen auch in einer anderen Vielfachheit n auftreten, wie etwa die Relation Arbeitsbereich als eine 1 -Relation, wenn die Lagerpl¨ atze von genau einer Maschine angefahren werden, beispiels¨ weise ein Regalbedienger¨ at. Ahnliche Einschr¨ ankungen k¨onnen zum Beispiel auch auf die Artikelgruppenzugeh¨origkeit angewendet werden, wenn die einzige Gruppe durch die Charge gebildet wird. Eine andere Interpretation der Relationen ist denkbar, so kann die Relation Kaufverhalten auch als Kaufverbot auftreten6 . Falls sowohl Kaufverhalten als auch Kaufverbot als Relationen zwischen Kunde und Artikelstamm gew¨ unscht sind, sind beide durch je eine separate Linie aufzuf¨ uhren.

Schnittstellen Die Container, die in der Abb. 7.1 von der gestrichelten Linie geschnitten werden, bilden die Schnittstellen des betrachteten WMS. Die Daten dieser Container sind sowohl f¨ ur das WMS als auch f¨ ur angrenzende Systeme, wie etwa • • • • •

Personalverwaltung, Qualit¨ atssicherung, Speditionswesen, Mandantenverwaltung und Warenwirtschaft

relevant. Die Implementierung kann auf zwei Arten geschehen: Eine gemeinsame Datenbasis vermeidet redundante Datenhaltung und die damit verbundenen Nachteile (vgl. Abschn. 5.2). Alternativ kann nach dem Prinzip der mehrfachen Datenhaltung gearbeitet werden, das heißt, die Daten liegen in Kopien an verschiedenen Stellen vor. Nachteilig ist der damit verbundene Aufwand f¨ ur die Synchronisation der Datenbest¨ande und die kurzfristige Verletzung der Integrit¨ at durch einseitige Daten¨ anderung. Dennoch wird dieses Verfahren in der Praxis h¨ auﬁg eingesetzt, da es einfach zu implementieren ist und den zeitweise autonomen Betrieb von Teilsystemen erlaubt. Abbildung 7.2 erl¨ autert das Verfahren der mehrfachen Datenhaltung am Beispiel der Artikelstammdaten. Diese Daten werden sowohl von einem WMS als auch von einem Warenwirtschaftssystem (WWS) ben¨otigt. Dabei ist zu beachten, dass der Artikelstamm neben einem von beiden Systemen gemeinsam genutzten Teil – in der Mitte der Abb. 7.2 grau hinterlegt – auch speziﬁsche Daten nur f¨ ur das WMS und solche f¨ ur das WWS enth¨alt. 6

Ein solches Kaufverbot f¨ ur einzelne Artikel und L¨ ander fand sich z. B. in der CoCom-Liste (Coordinating Committee on East-West Trade Policy).

7.2 Klassische Realisierung eines WMS

263

Artikelstamm

Artikelstamm Artikelnummer Artikelbezeichnung BildURL

Artikelnummer Artikelbezeichnung BildURL Hersteller Inhaltsstoffe .. .

Hersteller Inhaltsstoffe .. .

Datenabgleich Artikelstamm

Vorzugszone ZLVerbot .. .

Artikelnummer Artikelbezeichnung BildURL Vorzugszone ZLVerbot .. .

Abbildung 7.2. Realisierung der Schnittstellen durch teilweise redundante Datenhaltung.

Nur der gemeinsam genutzte Teil bildet die Schnittstelle und muss synchronisiert werden. In der Regel wird der Datenabgleich zyklisch zu Zeiten geringer Systemaktivit¨ at, oft nachts, durchgef¨ uhrt. Andere Container, deren Daten einer h¨ oheren Dynamik unterliegen, m¨ ussen h¨auﬁger, im Extremfall ¨ bei jeder Anderung, synchronisiert werden.

7.2 Klassische Realisierung eines WMS In diesem Abschnitt werden Teilaspekte einer m¨oglichen Realisierung auf der Basis einer relationalen Datenbank beschrieben. Diese Art der Umsetzung des logischen Konzeptes eines WMS ist typisch f¨ ur die heute im Einsatz beﬁndlichen und am Markt angebotenen Systeme. Aufgrund der suggestiven Struktur relationaler Datenbanken und ihrer eing¨ angigen Abfragesprachen k¨ onnen Systeme in angemessener Zeit realisiert werden. F¨ ur das oben beschriebene Datenmodell werden hier grunds¨atzliche Techniken, wie sie unter Einsatz einer Datenbank u ¨ blich sind, erl¨autert.

264

7. Implementierung eines WMS am Beispiel myWMS

7.2.1 Funktionale Struktur Zwei m¨ ogliche Arten der Realisierung von WMS sind die • mainframe basierten Architekturen (vgl. Abb. 7.3), wobei das WMS auf einem Zentralrechner mit Datenbankserver7 l¨auft, oder die • Client-Server-Systeme (vgl. Abb. 7.4), die verteilte Arbeitsstationsrechner mit speziﬁscher Funktionalit¨ at an einen Datenbankserver binden.

DB Applikation (WMS)

Server

Client

... ...

Terminal

Abbildung 7.3. Beispiel einer mainframe-basierten Architektur

Bei der Mainframe-Architektur laufen alle Prozesse auf dem Zentralrechner und werden durch Terminals bedient, die u ¨ ber keine eigene WMSFunktionalit¨ at verf¨ ugen. Bei Client-Server-Systemen werden diese Prozesse ganz oder teilweise auf die intelligenten Arbeitsstationen verteilt und der Server wird dadurch entlastet. Aus informationstechnischer Sicht sind folgende Teilaufgaben zu unterscheiden: • Maskenaufbau und Darstellung der Daten k¨onnen immer lokal erfolgen und bed¨ urfen keines Datenbankzugriﬀs. Als m¨ ogliches Beispiel f¨ ur die Auslagerung der Darstellung sei der html-Browser genannt. 7

Die Datenbankoperationen k¨ onnen auch durch den Einsatz eines Applikationsservers gekapselt werden, um auf einem WMS-nahen Niveau Dienste anbieten zu k¨ onnen.

7.2 Klassische Realisierung eines WMS

265

• Plausibilit¨ atskontrollen k¨ onnen an einen Client abgegeben werden. Die Pr¨ ufung auf richtige Eingabe einer Postleitzahl oder einer E-Mail-Adresse beispielsweise sind Aktionen, die lokal abgearbeitet werden k¨onnen. Eine Versendung dieser Daten vom Client zum Server und zur¨ uck kann als unn¨ otige Kommunikation betrachtet werden. • Integrit¨ atschecks dienen der Sicherung der Vollst¨andigkeit und Widerspruchsfreiheit der Daten. Im Allgemeinen werden hierzu mehrere Datens¨ atze ben¨ otigt, sodass diese Checks vorzugsweise auf dem Server ausgef¨ uhrt werden. So muss beispielsweise vor dem L¨oschen von Artikelstammdaten gesichert sein, dass sich keine Artikel mit der Artikelnummer des zu l¨ oschenden Datensatzes mehr im Lager beﬁnden und auch nicht avisiert sind. • Berechnungen k¨ onnen, abh¨ angig davon, ob Daten vom Datenbankserver ben¨ otigt werden oder nicht, teils lokal und teils nur auf dem Server ausgef¨ uhrt werden. • Datenbankoperationen m¨ ussen in der Regel auf dem Server ausgef¨ uhrt werden. Eine Ausnahme stellen verteilte Datenbanken dar, die teilweise durch die Clients realisiert werden (Peer-to-Peer-L¨osungen). Diese Form der Datenhaltung und des Datenaustausches ﬁnden z. B. bei Tauschb¨orsen im Internet Anwendung. Eine Unterscheidung, ob es sich bei einem System um eine mainframebasierte Architektur oder eine Client-Server L¨ osung handelt, ist nicht immer eindeutig zu treﬀen. 7.2.2 Tabellenstruktur Die Datenbank stellt die M¨ oglichkeit zur Verf¨ ugung, die verschiedenen Daten, die zum Betrieb eines Lagers n¨ otig sind und die w¨ahrend des Betriebs anfallen, strukturiert abzulegen. Das Tabellenkonzept unterst¨ utzt die Strukturierung. Generell kann jeder Container der Abb. 7.1 in eine eigene DatenbankTabelle abgebildet werden. Bevor die Daten jedoch abgelegt werden k¨onnen, muss die speziﬁsche Struktur einer jeden Tabelle erarbeitet werden, das heißt, es muss genau festgelegt werden, • • • •

was (welches Datum), wo (welche Tabelle), wie (welche Genauigkeit) und womit (welcher Datentyp)

abgelegt wird. Beispielsweise liegt es nahe, eine Telefonnummer als Datentyp Integer 8 zu speichern. Bei einer etwas genaueren Betrachtung f¨allt die 8

Ein Datentyp Integer repr¨ asentiert eine positive oder negative Ganzzahl.

266

7. Implementierung eines WMS am Beispiel myWMS

DB Applikation (WMS)

... ...

Abbildung 7.4. Beispiel einer Client-Server-Architektur

f¨ uhrende Null der Vorwahl auf, die bei der Speicherung als Integer nicht mitgef¨ uhrt werden k¨ onnte. Eine weitere Betrachtung einer Telefonnummer zeigt Sonderzeichen wie das f¨ uhrende Pluszeichen oder den Bindestrich. Sinnvollerweise sollte also die Speicherung einer Telefonnummer als Zeichenkette (varChar oder String) erfolgen, wobei eine ausreichende Anzahl von Zeichen (Genauigkeit) als m¨ ogliche L¨ ange gew¨ ahlt werden muss. Die logisch zusammenh¨ angenden Daten, etwa die Daten eines ItemData (s. Abb. 7.1), werden zeilenweise in die speziﬁzierten Felder einer Tabelle geschrieben. Unabdingbar bei der Arbeit mit relationalen Datenbanken und den zugeh¨ origen Tabellen ist die eineindeutige Vergabe von Prim¨arschl¨ usseln zur Identiﬁzierung einer Datenzeile. Die Struktur der Datenbank-Tabelle ItemData k¨onnte, wie in Tabelle 7.1 dargestellt, aussehen. Das Feld photo hat in dieser Struktur eine L¨ange von 255 Zeichen, um eine URL (s. Seite 171) f¨ ur das Foto anzugeben. Eine Methode zur Speicherung solcher Bin¨ ardaten stellt der Datenbanktyp blob (Binary Large Object) dar. Die Vorteile der URL, im Gegensatz zum blob, liegen in der Flexibilit¨ at der Wahl des Speicherortes der Fotodaten, deren M¨oglichkeit zur mehrfachen Referenzierung und der Entlastung der Datenbank von der ¨ ¨ Handhabung großer Datenmengen. Ahnliche Uberlegungen gelten f¨ ur die Beschreibung, die alternativ in einer separaten Textdatei stehen und u ¨ ber eine URL angesprochen werden kann. Im Rahmen einer Internationalisierung der Beschreibungen stehen, u altige M¨oglichkeiten zur Verwal¨ber die URL, vielf¨ tung und Darstellung zur Verf¨ ugung.

7.2 Klassische Realisierung eines WMS

267

Tabelle 7.1. Aufbau der Datenbank-Tabelle itemData Name

Typ

Länge

rId

int

artnr

varChar

20

bezeichnung

varChar

42

beschreibung

varChar

255

photo

varChar

255

groesse

varChar

80

gewicht

int

vorzugszone

varChar

meldebestand

int

istbestand

int

12

In der Tabelle 7.1 steht der Feldbezeichner rId f¨ ur eine eindeutige RawId als Prim¨ arschl¨ ussel. Die Nutzung der Artikelnummer k¨onnte sp¨atestens bei der Implementierung eines Mandantenlagers zu Mehrdeutigkeiten f¨ uhren und ist damit als Prim¨ arschl¨ ussel nicht geeignet. Heutige Datenbanksysteme bieten die M¨ oglichkeit, die Prim¨ arschl¨ ussel zu den einzelnen Datens¨atzen automatisch zu generieren und den Programmierer dadurch zu entlasten. n Zwischen ItemData und StockUnit besteht eine 1 -Relation. Das ItemData kann auf keine, eine oder mehrere StockUnit-Tabellen verweisen. Diese Relation wird u ¨ber das Feld itemDataId (s. Tabelle 7.2) realisiert, das jeder Zeile von StockUnit genau eine rId von ItemData zuweist, umgekehrt kann eine rId von ItemData in mehreren Zeilen von StockUnit erscheinen (vgl. Abb. 7.5). m Die n -Assoziation zwischen location und locationCategory kann sinnvollerweise nur u ¨ ber eine Hilfstabelle, die Referenztabelle, auch map table genannt, realisiert werden (vgl. Abb. 7.6).

268

7. Implementierung eines WMS am Beispiel myWMS

Tabelle 7.2. Aufbau der Tabelle stockUnit Name

Typ

Länge

rId

int

seriennummer

varChar

anzahl

int

itemDataId

int

20

Jede Zeile der Referenztabelle verbindet eine RawId der Tabelle location mit einer RawId der Tabelle locationCategory und verf¨ ugt selbst u ¨ ber einen Prim¨ arschl¨ ussel, der aus den jeweiligen beiden RawIds der zugeh¨origen Zeile gebildet werden kann. Der Verzicht auf eine solche Referenztabelle w¨ urde zu einer stark redundanten Datenhaltung und daraus resultierenden zus¨atzlichen Anforderungen an Speicher- und Laufzeitbedarf f¨ uhren. 7.2.3 Sicherung der logischen Integrit¨ at In Abb. 7.6 wird der Aufbau der Datenbank-Tabelle locationCategory dargestellt; u ¨ ber das Feld eigenschaft werden die einzelnen Zonen benannt und aufgef¨ uhrt. Die sinnvolle Zuordnung einer location zu einer locationCategory

bezeichnung

photo

Erbsen

http://www.mywms

00002

Bohnen

http://www.mywms

00003

Linsen

...

00004

...

...

00005

...

...

...

...

...

rId

stockUnit

42 21

itemDataId rId anzahl

11

42

01

17

96

11

02

9

84

217

03

1

12

42

04

11

96 96

05 ...

25 ...

42

...

...

Abbildung 7.5. Beispiel einer 1-zu-n-Relation

...... ... ......... ... ...

artnr 00001

... ... ... ... ... ... ...

itemData

7.2 Klassische Realisierung eines WMS

269

1.2.1 2.2.3 2.2.2 2.1.2 1.1.1

7 1 2 6 5 4 3 8 9

Referenztabelle rId1 rId rId2 1 1 2 1

2

4

2

3

1

1

4

8

4

5

3

4

6

8

3

7

2

3

8

6

2

9

4

8

10

6

locationCategory rId2

eigenschaft

2

Zone B

1

Zone A

3

Zone C

4

bis 100kg

5

bis 200kg

6

bis 500kg

7 8

... ... ... ... ... ...... ... ...

1.3.1

rId1

...

2.3.1

...

locationCode

...... ... ... ...... ......... ...

location

... ...

Abbildung 7.6. Beispiel einer n-zu-m-Relation

muss durch zus¨ atzliche Logik sichergestellt werden. Je nach Anwendungsfall muss oder sollte jede location genau einer Zone A, B oder C zugeordnet werden. Eine Zuordnung zu mehreren Zonen ist aus logistischer Sicht unzul¨assig und muss vermieden werden. Allerdings darf eine location zus¨atzlich einer Gewichtsklasse zugeordnet werden, die u ¨ ber das gleiche Feld repr¨asentiert wird. Alternativ k¨ onnten die Inhalte von locationCategory auf mehrere dedizierte Datenbank-Tabellen verteilt werden. Eine Verteilung, bei der nur noch 1 n -Relationen auftreten, vermeidet das Problem zu Lasten einer statischen Struktur; zus¨ atzliche Kategorien k¨ onnen nicht im laufenden Betrieb ¨ ohne Anderung des Datenmodells angelegt werden. Ein weiteres Beispiel zum Problem der Sicherung der logischen Integrit¨at ist auf Seite 265 beschrieben. Wenn in der Datenbank-Tabelle stockUnit das Feld seriennummer belegt ist, muss das Feld anzahl den Wert 1 enthalten. 7.2.4 Anlegen und Abfragen von Stammdaten Der Zugriﬀ auf die in der Datenbank abgelegten Datens¨atze und deren Manipulation durch einen Anwender erfolgt mittels einer datenbankspeziﬁschen Sprache (DML9 ), die meisten Datenbanksysteme unterst¨ utzen f¨ ur diesen Zweck SQL10 als standardisierte Abfragesprache. Damit ein Anwender SQL ¨ f¨ ur Abfragen und Anderungen an einem Datenbestand einsetzen kann, ist die Kenntnis des Datenmodells erforderlich. 9 10

Data Manipulating Language Structured Query Language

270

7. Implementierung eines WMS am Beispiel myWMS

Beispielhaft werden nachfolgend einige typische Datenbankoperationen unter SQL beschrieben. Das Hinzuf¨ ugen eines neuen Datensatzes in die Tabelle stockUnit erfolgt durch folgende Anweisung, in der die Inhalte der Spalteneintr¨age durch Variablen u ¨ bergeben werden. Im Beispiel stellt stockUnitCount eine sequence dar, welche die Anzahl der Datens¨ atze in der Tabelle stockUnit enth¨alt: insert into stockUnit (rId, seriennummer, anzahl, itemDataId) values (stockUnitCount.nextVal,’’,11,42);

Durch den nachfolgenden Aufruf werden die Bezeichnungen aller Artikel ausgegeben, deren Gewicht unter zehn Gewichtseinheiten liegt. select bezeichnung from itemData where gewicht < 10;

Sollen beispielsweise alle Lagerf¨ acher der A-Zone gez¨ahlt werden, dann kann das durch den folgenden Aufruf geschehen: select count (*) from Referenztabelle where locationCategory.eigenschaft = ’Zone A’ and rid2 = locationCategory.rid2;

Im obigen Beispiel wird der Umstand ausgenutzt, dass die Anzahl der selektierten Zeilen in der Referenztabelle der Anzahl der Lagerpl¨atze mit dem gesuchten Kriterium entspricht. Viele relationale Datenbanksysteme stellen durch Stored Procedures die M¨ oglichkeit der serverseitigen Speicherung von wiederkehrenden Abfragen ¨ mit Ubergabeparametern zur Verf¨ ugung.

7.3 Implementierung mit myWMS Die objektorientierte Programmierung (s. Abschn. 6.2) bietet f¨ ur die Realisierung von WMS viele Vorteile. Aus diesem Grund werden f¨ ur neuere Entwicklungen gr¨ oßtenteils objektorientierte Programmiersprachen11 eingesetzt. Der Vorteil der Objektorientierung kommt jedoch erst dann voll zur Geltung, wenn nicht nur die Programmierung, sondern bereits die Analyse und das Design eines Softwareproduktes durchg¨ angig auf dieser Methodik auf¨ bauen. Im Mittelpunkt der Uberlegungen steht nicht eine Abbildung der Datenstrukturen auf Tabellen einer Datenbank, sondern eine Analyse, die 11

¨ In Ubereinstimmung mit der allgemeinen Sprachregelung wird objektorientiert“ ” mit OO abgek¨ urzt.

7.3 Implementierung mit myWMS

271

Abbildung 7.7. myWMS LOS Plattform und Anwendungen

sich an den Objekten der Realit¨ at orientiert. Bereits in dieser Analysephase werden nicht nur die Daten und ihre Beziehungen untereinander, sondern die m¨ oglichen Methoden, die auf die Daten anzuwenden sind, beschrieben. Die Abbildung in Softwarestrukturen und deren Umsetzung, unter Einsatz einer OO-Programmiersprache, erfolgt erst sp¨ ater. Eine solche OO-L¨ osung f¨ ur WMS wurde in dem Projekt myWMS entwickelt. Dieser Abschnitt beschreibt das technische Konzept von myWMS als Beispiel f¨ ur die konsequente Anwendung der OO-Techniken f¨ ur WMS. F¨ ur die folgenden Kapitel zum Thema myWMS sind Kenntnisse der Objektorientierung und f¨ ur das detaillierte Verst¨ andnis Javakenntnisse hilfreich. Durch den suggestiven Aufbau dieses Kapitels und der gew¨ahlten Beispiele sind die grundlegenden Prinzipien auch ohne derartige Kenntnisse nachvollziehbar. In diesem Kapitel wird anhand eines einfachen Beispiels der Einsatz f¨ ur ein WMS gezeigt. 7.3.1 Grunds¨ atzlicher Aufbau von myWMS myWMS stellt ein Datenmodell und elementare Dienste f¨ ur WMS-Applikationen bereit12 . Es schaﬀt wohldeﬁnierte Kommunikationsschnittstellen zu externen Systemen und interne Schnittstellen zu den auswechselbaren Modulen, den so genannten Plug-Ins. Letztere werden in Form von Java-Interfaces speziﬁziert und erm¨ oglichen so Dritten, eigene Produkte einzubinden. 12

Bis Version 3 des myWMS Rahmenwerks verf¨ ugte myWMS u ¨ ber einen eigenst¨ andigen Kernel. Die dort zur Verf¨ ugung gestellten Dienste zum Datenzugriﬀ werden nun u ¨ ber den Applikationsserver bereitgestellt.

272

7. Implementierung eines WMS am Beispiel myWMS

Abbildung 7.8. Das Kernsystem, vereinfacht und idealisiert als Schnittmenge der Funktionen und Datenstrukturen unterschiedlicher Lagertypen

Neben Diensten f¨ ur die reine Lagerverwaltung beinhaltet das myWMSFramework auch Dienste f¨ ur die Realisierung von Materialﬂusssteuerungen. Aspekte der Warenwirtschaft, der Produktionsplanung und der Produktionssteuerung werden im Rahmen dieses Projektes nicht behandelt. Die Schnittstellen zu solchen Systemen sind jedoch Bestandteil des Rahmenwerks. Da myWMS nicht auf spezielle Lagertypen und logistische Prozesse festgelegt ist, existiert ein breites Anwendungsfeld. Von manuell bedienten L¨agern u ager bis hin zu r¨ aumlich verteilten L¨agern mit hetero¨ber automatische L¨ genen Strukturen sind die unterschiedlichsten Szenarien denkbar. Die Anpassung an bestehende L¨ ager wird durch die M¨oglichkeit der Entwicklung geeigneter Plug-Ins, wie beispielsweise Routing- oder Optimierungsalgorithmen, erleichtert. So kann eine Applikation mit Alleinstellungsmerkmalen eines Nutzers ausgestattet werden und dennoch von den Vorteilen eines standardisierten Systems proﬁtieren. Ein modulares und noch nicht auf einen bestimmten Anwendungsfall spezialisiertes und erweiterbares Warehouse Managementsystem sollte mindestens folgenden Anforderungen gen¨ ugen: Plattformunabh¨ angigkeit: Durch den Einsatz einer Programmiersprache, die es erlaubt portablen Code zu erzeugen, kann die Lauﬀ¨ahigkeit auf unterschiedlichsten Rechnerarchitekturen und Betriebssystemen gew¨ahrleistet werden.

7.3 Implementierung mit myWMS

273

Verteilbarkeit: Die Module eines WMS sollten auf mehreren kooperierenden Rechnern nebenl¨ auﬁg betrieben werden k¨onnen. So kann beispielsweise die Materialﬂusssteuerung auf einem anderen Rechner als die eigentliche Lagerverwaltung ablaufen. Die Plattformunabh¨angigkeit erm¨ oglicht den Einsatz heterogener Rechnersysteme. Skalierbarkeit: Wachsende Anforderungen, wie beispielsweise steigende Durchsatzzahlen oder eine Erh¨ ohung der Mandantenanzahl, sollten von einem WMS abgedeckt werden k¨ onnen. Mittel hierzu sind Verteilung, Anpassung der Module und Parametrierung. Parametrierbarkeit: Ein WMS sollte eine durchg¨angige Parametrierbarkeit der Module erlauben. Das Konﬁgurationskonzept sollte hierzu die M¨ oglichkeit der Persistierung der Parameter bieten. Releasef¨ ahigkeit: Die Zusicherung des langfristigen Bestands der Schnittstellen ist ein wichtiges Kriterium bei der Auswahl eines WMS. Die Basissoftware kann unter Beibehaltung der bestehenden Module und ihrer applikationsspeziﬁschen Erweiterungen und Anpassungen ebenso ausgetauscht werden, wie diese Module unter Beibehaltung der Basissoftware. Web-basierte Bedienbarkeit: Die Bedienbarkeit durch beliebige WebBrowser unterst¨ utzt die Plattformunabh¨ angigkeit. Damit wird die Einbindung der bestehenden IT-Infrastruktur zur Bedienung des WMS erm¨ oglicht. Unabh¨ angigkeit: Es gibt keine Beschr¨ ankung auf bestimmte Lagertypen, Betriebsmittel oder Strategien. Erweiterbarkeit: Durch die Erstellung zus¨atzlicher Module oder die Erweiterung bestehender Module, ist die Anpassung an die verschiedensten Anforderungen der Logistik m¨ oglich. myWMS erf¨ ullt diese Anforderungen durch die Einhaltung der Java EE Speziﬁkation. Das Framework besteht aus drei logischen Hierarchieebenen: aus der Bestandsverwaltung, der Lagerortsverwaltung sowie einer optionalen Materialﬂusssteuerung (s. Abb. 7.9). Die Bestandsverwaltung (Inventory Manager ) hat die Aufgabe, die Artikelstammdaten (ItemData) und die artikelbezogenen, standortunabh¨angigen Operationen sowie die verf¨ ugbaren und die vorhandenen Mengen der Bereitstelleinheiten (vgl. Abb. 7.1) zu verwalten. Die Lagerortsverwaltung (Location Manager ) verwaltet die Lagerorte (Location). Hier werden die aktuelle Belegung der Lagerorte mit Ladeeinheiten, die durch Ladehilfsmittel (UnitLoad ) repr¨ asentiert werden und die Attribute der Lagerorte verwaltet. Die Materialﬂusssteuerung (Equipment Manager ) berechnet die Transportwege, beauftragt die Betriebsmittel und u uhrung der ¨berwacht die operative Ausf¨ Transportauftr¨ age. Nicht jedes System muss alle drei Schichten realisieren. So kann beispielsweise nur eine Bestands- und eine Ortsverwaltung betrieben werden, die untere Schicht kann dann in einem manuellen Lager entfallen. Umgekehrt kann durch den separaten Betrieb der untersten Schicht, unter Verzicht auf die La-

274

7. Implementierung eines WMS am Beispiel myWMS Kern Plug-In Erweiterungen

Bestands verwaltun g

Lagerorts verwaltun g

Materialflu ss Steuerun g

Abbildung 7.9. Das logische Schichtenmodell von myWMS

gerfunktionalit¨ at, ein eigenst¨ andiger Materialﬂussrechner auf myWMS-Basis erstellt werden. 7.3.2 Gesch¨ aftsobjekte Die Aufgabe der einzelnen Schichten ist die Verwaltung der zugeh¨origen Daten, die in Gesch¨ aftsobjekten (Entit¨aten) gespeichert sind. Jedes Gesch¨aftsobjekt entspricht genau einem Container des Datenmodells der Abb. 7.1. myWMS umfasst u. a. folgende Gesch¨ aftsobjekte: 13 • • • • • •

ItemData (Artikelstamm) StockUnit (Bereitstelleinheit ) StorageLocation (Lagerplatz ) UnitLoad (Ladehilfsmittel ) Order (WAAnforderung) PickRequest (Kommissionierauftrag)

Die Gesch¨ aftsobjekte sind unter konsequenter Einhaltung der OO-Technik (vgl. Abschn. 6.2), also Analyse, Design, Implementierung und Test, erstellt worden. Alle Attribute sind gekapselt und nur durch die so genannten 13

myWMS LOS beinhaltet weitere Gesch¨ aftsobjekte und Hilfsobjekte. Hier werden nur die f¨ ur das weitere Verst¨ andnis notwendigen Gesch¨ aftsobjekte aufgef¨ uhrt.

7.3 Implementierung mit myWMS

275

Accessor-Methoden verf¨ ugbar. Die Objektorientierung erlaubt eine detailliertere Modellierung einzelner Objekte. So wird beispielsweise mit StorageLocation jeder physische Lagerplatz und mit RackLocation der Lagerplatz innerhalb eines Regals unterschieden. RackLocation erbt von StorageLocation. Gesch¨ aftsobjekte k¨ onnen somit durch das Mittel der Vererbung spezialisiert werden. Das myWMS-Gesch¨ aftsobjekt ItemData kann in gleicher Weise durch das Mittel der Ableitung projektspeziﬁsch um zus¨atzliche Attribute, wie etwa eine Abbildung, erweitert werden. Diese Ableitung wird dann in einer ItemData erweiternden Klasse zusammen mit ihren Accessor-Methoden deklariert und deﬁniert. Die Klasse ItemData zeigt das nachfolgende Fragment: /** * ItemData contains general informations about * the goods stored in the warehouse. */ @Entity @Table(name="mywms_itemdata",uniqueConstraints = { @UniqueConstraint(columnNames = { "client_id", "item_nr"})}) public class ItemData extends BasicClientAssignedEntity { private String number = ""; /** * The number is a unique product number, like for example an EAN. * * @return Returns the number. */ @Column(nullable = false, name="item_nr") public String getNumber() { return this.number; } /** * @param number The number to set. */ public void setNumber(String number) { this.number = number; } ... }

Die Annotierungen14 @Entity und @Table zeigen an, dass es sich bei der Klasse um eine persistente Entit¨ at handelt, die in die Datenbanktabelle mywms itemdata abgebildet wird. Das Feld number ist außerhalb der Klasse nicht sichtbar, da es als private deklariert ist. Zum Setzen und Lesen des Attributes existieren die Accessor-Methoden setNumber und getNumber. 14

Annotierungen dienen dazu, Metadaten in den Quelltext einzubinden, um diesen n¨ aher zu beschreiben. Andere Programme k¨ onnen die Annotierungen auswerten, um annotierte Aspekte gezielt zu behandeln. Im JEE 5 Standard sind Annotierungen das zentrale Mittel zur Bereitstellung laufzeitrelevanter Informationen f¨ ur den JEE Container, der diese auswertet.

276

7. Implementierung eines WMS am Beispiel myWMS

@Column(nullable = false) zeigt an, dass das Attribut immer deﬁniert sein muss. Da ItemData die Klasse BasicClientAssignedEntity ableitet, erbt sie deren Attribut Client (Mandant), so dass jeder Artikel einem Mandanten zugeordnet werden kann (muss). 7.3.3 SOA Konzept von myWMS LOS F¨ ur die Funktionalit¨ at eines WMS sind entsprechende Gesch¨aftsprozesse zu modellieren und zu implementieren. Typische Gesch¨aftsprozesse sind • Einlagern, • Kommissionieren und • Auslagern. Aufbauend auf dem vorgestellten Datenmodell myWMS wird im Folgenden skizziert, wie mit dem Projekt LOS eine Service-orientierte Architektur (Abschn. 6.6) geschaﬀen wurde, um diese Gesch¨aftsprozesse dienstebasiert abzubilden. myWMS LOS verf¨ ugt u ¨ ber fertig modellierte Gesch¨aftsprozesse und erm¨ oglicht eine Anpassung an konkrete, projektspeziﬁsche Anforderungen im Bedarfsfall. Durch die typische Flexibilit¨at von Open-Source Projekten k¨ onnen beide Projekte nahtlos integriert werden. Die drei logischen Schichten Bestandsverwaltung, Lagerortsverwaltung und Materialﬂusssteuerung werden, aus Sicht der Informationstechnik, durch je ein Modul abgebildet. Module k¨ onnen jeweils einzeln (z.B. nur die Materialﬂusssteuerung) oder in Kombination (Lagerplatz- und Bestandsverwaltung, aber ohne Materialﬂusssteuerung zur Abbildung eines manuellen Lagers) in einen Applikationsserver (Abschn. 6.5) zur Ausf¨ uhrung gebracht werden. Jedes Modul (Module) deﬁniert in einem Persistenz-Archiv die modultypischen Gesch¨ aftsobjekte (Entities) sowie deren Datenzugriﬀsdienste (Entity Services). Komponenten (Components) aggregieren die Datenzugriﬀsdienste und stellen einen deﬁnierten Satz von Diensten zur Abbildung von Gesch¨ aftslogik zur Verf¨ ugung. Diese Dienste k¨onnen wiederum von Benutzeroberﬂ¨ achen oder von automatisierten Schnittstellen genutzt werden. Im Falle der Benutzeroberﬂ¨ achen wird der Zugriﬀ u ¨ ber Fassaden (Facade Services) entkoppelt, sodass eine saubere Trennung von Darstellungslogik und oglicht wird. Automatische Schnittstellen werden u Gesch¨ aftslogik erm¨ ¨ ber Web Services bereit gestellt und k¨ onnen von anderen Applikationen (z.B. ERP Systemen) oder von einer Workﬂow Engine aufgerufen werden. Die Sammlung aller Module bildet die Applikation. Durch das Einbringen zus¨ atzlicher Module, die f¨ ur sich alleinstehend Funktionalit¨at bereitstellen oder die Dienste existierender Module nutzen, k¨onnen beliebige Erweiterungen der Gesamtapplikation vorgenommen werden, wie in Abbildung 7.10 veranschaulicht.

7.3 Implementierung mit myWMS

Rich Client

Browser

RMI

ERP

https

RFID

277

PDA

Webservices

RS 232

http

ApplicationServer

InventoryModule

Web Application

Remote Session Beans

UI Process Components

WS

FacadeServices

Web Services

Communication

Security

Project Module

CRUD Services

Agent Module Components

Plug-Ins

Business Services

InventoryModule Local

Local

Item Data Service

Stock Unit Service

Entity

Entity

Item Data

Stock Unit

Local

Order Service Entity

Order

Local

Unit Service Entity

Unit

Local

... Service Entity

...

Location Module MFC Module myWMS Module

Database Abbildung 7.10. SOA-Architektur myWMS LOS

Entity Services Ein Entity Service bezieht sich immer auf eine Entit¨at und deﬁniert Operationen zum Erzeugen, Abfragen, Aktualisieren und L¨oschen derselben15 . Die Mutterklasse aller Entity Services ist der BasicService, der Operationen zum Abfragen (get) und L¨ oschen (delete) einzelner Entit¨aten deﬁniert. F¨ ur die Entit¨ at ItemData gibt es eine Ableitung ItemDataService, die zus¨ atzlich eine Operation zum Erzeugen (create) einer Instanz von ItemData deﬁniert sowie weitere spezielle Operationen. Zu beachten ist, dass Services zun¨ achst nur u ¨ ber ein Interface deﬁniert werden, das zugesicherte Operationen, deren Parameter und R¨ uckgabewerte sowie eventuelle Ausnahmen (Exceptions) auﬂistet. Die Programmierung von Funktionalit¨at erfolgt in einer Klasse, die das Interface implementiert. @Local public interface BasicService<E> { /** * Returns the entity matching the specified id. */ E get(long id) throws EntityNotFoundException; /** 15

Nach den englischen Begriﬀe Create, Retrieve, Update und Delete heißen diese Operationen auch CRUD Operationen.

278

7. Implementierung eines WMS am Beispiel myWMS

* Removes the specified entity from the database. */ void delete(E entity) throws ConstraintViolatedException; /** * Returns a list of entities, matching the specified client. */ List<E> getList(Client client); ... } @Local public interface ItemDataService extends BasicService { /** * Checks the specified number for being already given away. If * the number is valid, a new ItemData will be created, assigned * to Client client and added to persistence context. * * @param client the owning client of the new ItemData. * @param number the number of the new ItemData. * @return a persistent instance of ItemData. * @throws UniqueConstraintViolatedException if Client client has * already an ItemData with Number number. * @throws NullPointerException if client or number is null. */ ItemData create(Client client, String number) throws UniqueConstraintViolatedException; /** * Returns a list of ItemDatas, matching the specified zone. */ List getListByZone(Zone zone); ... }

Business Services Business Services stellen Dienste zur Abbildung von Gesch¨ aftslogik zur Verf¨ ugung. Sie sind als wieder verwendbare Komponenten ausgelegt, da sie naturgem¨ aß den h¨ ochsten Programmieranteil ausmachen. Die Operationen bezeichnen feingranulare Gesch¨aftsprozesse. Diese nehmen h¨ auﬁg als Argumente Entit¨ aten entgegen, auf denen sie operieren, nachdem umfangreiche Konsistenzchecks durchgef¨ uhrt worden sind. Genutzt werden dazu Entity Services oder andere Komponenten. Auch das Protokollieren f¨ allt in ihren Zust¨ andigkeitsbereich. Ein Beispiel ist die Bestandskomponente LOSInventoryComponent : @Local public interface LOSInventoryComponent extends BasicFacade{ /** * Transfers given StockUnit from source UnitLoad to * destination UnitLoad. */ public void transferStockUnit(

7.3 Implementierung mit myWMS

279

StockUnit su, LOSUnitLoad dest, String activityCode) throws InventoryException, FacadeException; /** * Tests whether the StockUnit can be placed on UnitLoad */ boolean testSuitable(StockUnit su, LOSUnitLoad ul); } ... }

Die Operation transferStockUnit bucht eine Lagereinheit auf ein Ladehilfsmittel um. Eine Implementierung dieses Dienstes muss zun¨achst pr¨ ufen, ob alle Randbedingungen daf¨ ur erf¨ ullt sind. Beispielsweise darf das Ladehilfsmittel nicht gesperrt sein. Bei erfolgreicher Pr¨ ufung muss die entsprechende Referenz auf das neue LHM gesetzt werden. Um eine l¨ uckenlose R¨ uckverfolgbarkeit zu gew¨ ahrleisten wird anschließend ein Buchungssatz geschrieben, der festh¨ alt wann, welche Lagereinheit durch wen und warum, von wo, wohin gebucht wurde. Zur Schreibung dieses Buchungssatzes (LOSStockUnitRecord ) nutzt LOSInventoryComponentBean den Service LOSStockUnitRecordService 16 . Die Komponenten sind außerdem f¨ ur das Thema Sicherheit verantwortlich. Entsprechend mit der Annotation @RolesAllowed versehene Operationen d¨ urfen nur von authentiﬁzierten Benutzern, die einer deklarierten Rolle (@DeclareRoles) angeh¨ oren, ausgef¨ uhrt werden. @Stateless @DeclareRoles({Role.ADMIN_STR,Role.INVENTORY_STR,Role.FOREMAN _STR,Role.OPERATOR_STR}) public class LOSInventoryComponentBean extends BasicFacadeBean implements LOSInventoryComponent { @EJB StockUnitService stockUnitService; @EJB LOSStockUnitRecordService recordService; @RolesAllowed({Role.ADMIN_STR,Role.INVENTORY_STR,Role.FOREMAN_ STR,Role.OPERATOR_STR}) public void transferStockUnit(StockUnit su, LOSUnitLoad dest, String activityCode) throws FacadeException { if (! testSuitable(su, dest)) { throw new InventoryException( InventoryExceptionKey.STOCKUNIT_TRANSFER_NOT_ALLOWED, new String[] { su.toUniqueString(), dest.getLabelId() }); } 16

Die Annotierung @EJB zeigt an, dass vom JEE Container zur Laufzeit eine Implementierung von LOSStockUnitRecordService injiziert“ werden soll. Durch die” ses Dependency Injection genannte Entwurfsmuster werden die Abh¨ angigkeiten zwischen Komponenten und Diensten minimiert.

280

7. Implementierung eines WMS am Beispiel myWMS

su.setUnitLoad(dest); // add to destination recordService.recordTransfer(su, old, dest, activityCode); } ... }

Facade Services Eine Fassade (engl. Facade) deﬁniert eine einheitliche Schnittstelle zum Zugriﬀ auf die Gesch¨ aftslogik von außen. W¨ahrend alle bis jetzt eingef¨ uhrten Dienste nur lokal innerhalb des Applikationsservers bzw. der Applikation bekannt sind, werden Fassaden nach außen bekanntgegeben17 . Das f¨ uhrt dazu, dass sie u ¨ber einen Verzeichnisdienst18 auﬃndbar und aufrufbar sind. Im Gegensatz zu den Business Services liefern Fassaden in der Regel keine Entit¨ aten aus, sondern operieren mit Datentransferobjekten (DTO). Diese sind auf den speziellen Anwendungsfall (meist eine Benutzeroberﬂ¨ ache) zugeschnitten und k¨ onnen so performanter zum Datenaustausch eingesetzt werden, als die Entit¨ aten mit all ihren Datenfeldern. Ein Beispiel ist die Fassade QueryInventoryFacade zum Abrufen von Bestandswerten: @Remote public interface QueryInventoryFacade{ /** * Gets an inventory List by unique client reference containing all articles. * One entry per batch if consolidateLot is false. One entry per article otherwise. */ QueryInventoryTO[] getInventoryList( String clientRef, boolean consolidateLot) throws InventoryException; }

Web Services Diese sind ¨ ahnlich einzuordnen wie Fassaden. Statt u ¨ ber JNDI sind sie unabh¨ angig von der Programmiersprache speziﬁziert und der Datenaustausch ﬁndet durch XML-basierte Nachrichten u ¨ ber internetbasierte Protokolle statt. Mit wenigen zus¨ atzlichen Annotationen (@WebService, @WebMethod) l¨ asst sich aus der Fassade QueryInventoryFacade ein Web Service erzeugen: @Remote @WebService @SOAPBinding( style = SOAPBinding.Style.RPC, use = SOAPBinding.Use.LITERAL) public interface QueryInventory extends java.rmi.Remote { /** * Gets an inventory List by unique client reference containing all 17 18

Sie sind durch die Annotation @Remote gekennzeichnet hier: Java Naming and Directory Interface, JNDI.

7.3 Implementierung mit myWMS

281

* articles. * One entry per batch if consolidateLot is false. One entry per * article otherwise. */ @WebMethod QueryInventoryTO[] getInventoryList( @WebParam(name="clientRef") String clientRef, @WebParam(name="consolidateLot") boolean consolidateLot throws InventoryException; }

7.3.4 Laufzeitumgebung Der Applikationsserver f¨ uhrt die Logik des Systems aus und stellt die Schnittstellen bereit, die von Clientapplikationen oder externen Systemen verwendet werden. Abschn. 6.5 geht detaillierter auf das Konzept eines Applikationsservers ein. In der myWMS LOS Schulungsversion werden Open-Source Produkte eingesetzt (JBoss AS bzw. Postgres DB), im produktiven Einsatz h¨auﬁg propriet¨ are Alternativen, etwa IBM Websphere, SAP Netweaver bzw. Oracle DB. Neben den Applikationsserver Modulen bietet myWMS mit dem Stan” dard-Environment“ Bibliotheken, die zus¨ atzliche Funktionen zur Verf¨ ugung stellen und losgel¨ ost vom Applikationsserver sinnvoll eingesetzt werden k¨onnen. Dieses Environment wird in folgende Themengebiete gegliedert: Kommunikation: Das Channelkonzept von myWMS erm¨oglicht den Transport von Kommunikationsobjekten u ¨ber die verschiedenen physischen und logischen Leitungen. So implementiert myWMS den Transport u ¨ ber den Layer des ISO/OSI-Protokollstacks (vgl. Abschn. 5.1.1) genauso wie die Kommunikation u ¨ ber RS232. Die als Plug-In vorhandenen Protokolle erm¨ oglichen hierbei die Serialisierung und Deserialisierung der Kommunikationsobjekte. Event-Handling und Multicasting: myWMS beinhaltet ein komplexes, verteilbares Event-System, das dem Entwurfsmuster des Listener folgt. Verschiedene Listener-Objekte k¨ onnen sich bei einem Event-Dispatcher , registrieren und bilden dann eine Listener-Gruppe. Vom Event-Dispatcher verteilte Events werden in Kopie an alle registrierten Listener weitergeleitet. Clearing: Ausnahmesituationen, die von dem System nicht automatisch behandelt werden k¨ onnen, werden einem Clearing-Dispatcher mit einer vorgegebenen Menge von Antworten oder Handlungsanweisungen u ¨ bergeben. Eine solche Ausnahmesituation macht eine Benutzereingabe zur Auswahl der korrekten Antwort oder zur Quittierung einer Handlungsanweisung erforderlich. Andere, fr¨ uher in myWMS enthaltene Bibliotheken, sind zugunsten von JEE Standardbibliotheken abgel¨ ost worden, da diese - anders als zu Beginn

282

7. Implementierung eines WMS am Beispiel myWMS

des Projekts - heute industriellen Anforderungen vollauf gen¨ ugen. Dies betriﬀt beispielsweise das Logging, f¨ ur das in der aktuellen Version das Apache Logging Services Project log4j zum Einsatz kommt. Das Logging dient der Aufzeichnung von verschiedenen Nachrichten, die unterschieden werden nach Dringlichkeit (logLevel ) und Kategorie. Die Klassiﬁzierung ist konﬁgurierbar, z.B. nach • • • • • •

ausf¨ uhrendem Rechner, aktuellem Benutzer, Datum und Uhrzeit, Objekt, Methode oder Thread

und erm¨ oglicht eine qualiﬁzierte Oﬄine-Analyse der gespeicherten Nachrichten. Das Darstellen und Erfassen von Informationen ist Aufgabe der Clientapplikationen. In der Schulungsversion werden zwei Ans¨atze eingebunden: Der erste Ansatz realisiert eine reichhaltige, in Java programmierte Benutzeroberﬂ¨ ache, u ¨ ber welche die typischen Prozesse eines Sachbearbeiters bedient werden. Diese Prozesse umfassen beispielsweise das Erfassen von Avisen, den Wareneingang und die Auftragserzeugung. Der zweite Ansatz ist webbasiert, l¨auft in jedem Webbrowser und somit auch auf den meisten Handger¨aten und Staplerterminals. Ein Beispiel ist der Vorgang des Kommissionierens mit Hilfe eines mobilen Endger¨ ates.

7.4 Beispielhaftes Distributionssystem/Referenzlager Dieses Kapitel stellt ein ﬁktives Lager f¨ ur Elektrokleinger¨ate aus dem Haushaltswarenbereich vor, an dem beispielhaft typische Strukturen von Warehouse Managementsystemen aufgezeigt werden. Nachfolgend werden die Topologie, die Betriebsmittel und die logistischen Prozesse beschrieben. Das System besteht aus dem Wareneingangs- und Warenausgangsbereich und dem Lagersystem mit vorgeschalteter Kommissionierzone (s. Abb. 7.11). Angenommene Ware wird mittels Stapler entladen und in reservierten Bereitstellzonen gepuﬀert. Nach Pr¨ ufung und Vereinnahmung in das System erfolgt der Transport per Stapler zum I-Punkt des Lagersystems (Einlagerstichbahn) oder in ein separates, manuell bedientes Lager, das auch einen Sperrbereich zum Zweck einer eingehenden Qualit¨atspr¨ ufung enth¨alt. Aus dem Lagerbereich werden ganze Einheiten entnommen. An den Kommissionierpl¨ atzen werden Teilmengen gebildet und nach Fertigstellung der Kommissioniereinheit analog in den Warenausgangsbereich transportiert. Um den Anforderungen eines Referenzsystems gerecht zu werden, sind die Lagersysteme einerseits so gestaltet, dass typische Komponenten und

7.4 Beispielhaftes Distributionssystem/Referenzlager

283

Abbildung 7.11. Das Distributionssystem

Abl¨ aufe eines Lagers dargestellt werden. Andererseits werden an bestimmten Stellen Vereinfachungen in Kauf genommen, um die Komplexit¨at zu reduzieren und die wesentlichen Gesichtspunkte hervorzuheben. Als Ladehilfsmittel kommen durchg¨ angig Europaletten (800 mm×1200 mm) zum Einsatz, auf denen die Artikel artikelrein transportiert und gelagert werden. Insgesamt lassen sich die Funktionsbereiche Wareneingangsbereich, Hochregallager, manuell bedientes Regallager, Kommissionierzone und Warenausgangsbereich identiﬁzieren. 7.4.1 Beschreibung des manuellen Regallagers Das manuell bzw. u ¨ber Stapler bediente Lager besteht aus 12 Regalen, von denen je zwei r¨ uckseitig aneinander gef¨ ugt sind. Jedes Regal ist u ¨ ber eine Gasse, die vom Mittelgang abzweigt, erreichbar. Jedes Regal besteht aus 13 Lagerf¨ achern in horizontaler und vier F¨ achern in vertikaler Richtung. Alle Lagerf¨ acher haben die gleichen Abmessungen und sind f¨ ur die einfachtiefe Aufnahme von Standard-Europaletten in L¨ angsrichtung ausgelegt. An jedem Regalsteher beﬁndet sich eine Blechtafel, die pro Lagerfach ein Etikett enth¨ alt, auf dem der Lagerplatzname als Barcode und in Klarschrift sowie evtl. eine Pr¨ ufziﬀer kodiert ist. Die Benennung der Lagerpl¨atze folgt dem Schema Regalnummer Ebene Spalte. Das Etikett in Abb. 7.12 bezeichnet also das zweite Regal, in der ersten Ebene und dort das dritte Lagerfach. Die Nummerierung der Regale erfolgt pro Gasse von links nach rechts (aus Sicht einer Person, die das Regal anblickt), beginnend bei eins und fort-

284

7. Implementierung eines WMS am Beispiel myWMS

R2-1-3 Abbildung 7.12. Beispiel f¨ ur ein Lagerplatz-Etikett

laufend aufsteigend. Die Nummerierung der Lagerf¨acher einer Ebene erfolgt ebenfalls von links nach rechts beginnend bei eins. Die Nummerierung der Ebenen erfolgt von unten nach oben, beginnend mit eins. 7.4.2 Beschreibung des automatischen Lagersystems Das Hochregallager (HRL) wird in dieser Form tausendfach in der Praxis eingesetzt und beschreibt einen klassischen Fall der Lagertechnik (vgl. Kapitel 3). Alle Lagerf¨ acher haben die gleichen Abmessungen und sind f¨ ur die einfachtiefe Aufnahme von Standard-Europaletten in L¨angsrichtung ausgelegt. Jedes der acht Regale besteht aus 50 F¨ achern in horizontaler und zehn F¨achern in vertikaler Richtung, so dass sich eine Lagerfachanzahl von 500 pro Regal und 4.000 insgesamt ergibt. Besonderheiten wie doppelttiefe Lagerung oder unterschiedliche Fachabmessungen kommen im Referenzlager nicht zur Anwendung. Jede Lagergasse wird von einem Regalbedienger¨at (RBG, vgl. Abschn. 3.2.2) bedient. Die Lagervorzone stellt die materialﬂusstechnische Verbindung der Funktionsbereiche her. Als Querf¨ordertechnik kommt ein Querverteilwagen (QVW) zum Einsatz. Neben dem Querverteilwagen umfasst die Lagervorzone die Einlagerbahn mit I-Punkt, die Auslagerbahn ¨ ¨ und zwei Ubergabepl¨ atze je Lagergasse f¨ ur die Ubergabe von Ladeeinheiten zwischen Regalbedienger¨ at und Querverteilwagen. Jeder der vier Kommissionierpl¨ atze setzt sich zusammen aus dem Kommissionier-U“, dem Platz ” f¨ ur den Kommissionierer und dem Stellplatz f¨ ur die Palette, auf die kommissioniert wird (Sammeleinheit). Das Kommissionier-U“ besteht aus dem ” Puﬀerplatz, von dem kommissioniert wird, sowie einem vor- und einem nach¨ geschalteten Ubergabeplatz zur Anbindung an den Querverteilwagen. ¨ Die Ubergabepl¨ atze zwischen Lagervorzone und Hochregalen sind u ¨ ber zwei hintereinandergeschaltete Kettenf¨ orderer realisiert, so dass sich eine Puﬀerkapazit¨ at von zwei Stellpl¨ atzen ergibt. Jede Lagergasse besitzt zwei solcher Kettenf¨ ordererpaare: ein Paar zum Einlagern, eins zum Auslagern. Kettenf¨ ordermodule bilden, erg¨ anzt um je zwei Eckumsetzer, auch die Kom” missionier-Us“. Bei den Ein- und Auslagerbahnen hingegen handelt es sich um angetriebene Staurollenf¨ orderer. Am Ende der Einlagerbahn ist ein Umsetzer integriert, mit dem Paletten wahlweise direkt auf die Auslagerbahn gef¨ ordert (z. B. bei negativer Konturenkontrolle) oder an den Querverteilwa-

7.4 Beispielhaftes Distributionssystem/Referenzlager

285

gen u onnen. Das Aufgeben von Paletten auf die Einlager¨bergeben werden k¨ bahn bzw. das Abf¨ ordern von Paletten von der Auslagerbahn oder der fertig kommissionierten Paletten erfolgt u ¨ber konventionelle Frontgabelstapler. 7.4.3 Prozesse aus Anwendersicht In den folgenden Abschnitten werden die Standardprozesse Wareneingang, Einlagerung, Bestellung, Kommissionierung und Versand aus Sicht des Anwenders, also des Lagermitarbeiters oder der Sachbearbeiterin, beschrieben. Wareneingang Ein Lagermitarbeiter will angelieferte Ware, hier beispielhaft Laserdrucker, im Wareneingang erfassen. Dazu w¨ahlt er im myWMS LOS Client unter Men¨ upunkt Dialoge den Unterpunkt Wareneingang an. Es ¨ oﬀnet sich ein Dialog (vgl. Abb. 7.13), mit dem der Wareneingang der Laserdrucker angezeigt wird. Zun¨ achst gibt der Lagermitarbeiter das Tor an, an dem die Ware angeliefert wurde. Dazu nutzt er das Auswahlfeld Tor“. ” Durch eine systeminterne Vorauswahl werden ihm nur Wareneingangstore, keine Warenausgangstore, angezeigt. Im Beispiel w¨ahlt er Tor 1 (WE). Um bei sp¨ ateren R¨ uckfragen oder Beanstandungen das anliefernde Unternehmen verf¨ ugbar zu haben, gibt der Lagermitarbeiter den Namen des Anlieferers im Textfeld ein. Dann ordnet er die Lieferung dem Mandanten mit der Nummer 100001 zu. Die angelieferten Ladehilfsmittel, in diesem Fall Paletten, haben keine Identiﬁkationsnummer. Der Eintrag auf der Registerkarte LHM“ bleibt leer, aber es kann angeben werden, um welchen LHM ” Typ es sich handelt. Auf der Registerkarte Lagereinheit“ sucht er u ¨ber das ” Auswahlfeld das entsprechende Avis heraus. Dieses wurde vorher per Web Service Schnittstelle vom ERP System u ¨ bertragen. Mit den Informationen aus dem Avis wird der Artikel automatisch u ¨ bernommen. Der Lagermitarbeiter gibt die Anzahl der Drucker pro Palette ein. Da einhundert Drucker bestellt wurden und er weiß, dass auf jeder Palette f¨ unfundzwanzig Drucker gepackt sind, kann er eingeben, dass vier identische Ladehilfsmittels angenommen werden. Da es sich um einen normalen Wareneingang und nicht um eine Retoure handelt, wird in der Maske der entsprechende Eintrag ausgew¨ ahlt. Der Mitarbeiter kann nun noch eine Charge f¨ ur die Laserdrucker angeben. Da er unter dem Punkt Charge ausw¨ ahlen“ im Auswahlfeld keine Charge ” ﬁnden kann, muss es sich um eine neue, dem System nicht bekannte Chargennummer handeln. Er u ¨bernimmt die Chargennummer 321 des Lieferscheines und tr¨ agt diese unter neue Charge erzeugen“ ein. Eine G¨ ultigkeit der Char” ge ist auf dem Lieferschein nicht vermerkt. Also l¨asst er diesen Eintrag oﬀen. Nach Klicken der Schaltﬂ¨ ache Hinzuf¨ ugen“ wird der Wareneingang der ein” hundert Laserdrucker in die Positionsliste aufgenommen, ein Palettenschein wird vom LVS automatisch f¨ ur die Ware gedruckt. Dieser beinhaltet vor allem einen Barcode, der die Palette eindeutig bezeichnet. Durch abschlie-

286

7. Implementierung eines WMS am Beispiel myWMS

Abbildung 7.13. Dialog Wareneingang

ßendes Klicken auf die Schaltﬂ¨ ache Wareneingang erzeugen“ wird die Ware ” im Wareneingang gebucht und steht f¨ ur die Einlagerung bereit. Einlagerung der Waren in das manuelle Regallager Die Einlagerung der vier Paletten und die Bearbeitung der Dokumentation geschehen durch einen Lagermitarbeiter im Lager mittels seines Handger¨ates. Hierzu muss sich dieser zun¨ achst am System anmelden. Auf der Startseite w¨ahlt der Mitarbeiter den Punkt Einlagerung“ aus. Es ¨ oﬀnet sich ein Fenster, danach wird der ” Barcode des Ladehilfsmittels gescannt. Das System sucht einen geeigneten freien Lagerplatz und erzeugt einen Einlagerauftrag. F¨ ur das Ladehilfsmittel 000000 wird der Lagerplatz R1-1-1 dem Mitarbeiter u at angezeigt (vgl. Abb. 7.14). Sobald er die Palette ¨ ber das Handger¨ mit dem Stapler zum Lagerplatz R1-1-1 gebracht hat, scannt er den Barcode des Lagerplatzes. Die Identiﬁkationsnummern des Ladehilfsmittels und des Lagerplatzes stehen den eingescannten Barcodes gegen¨ uber. Bevor er auf Fertig“ klickt vergewissert er sich von deren Richtigkeit. Auch das LVS pr¨ uft ”

7.4 Beispielhaftes Distributionssystem/Referenzlager

287

Abbildung 7.14. Dialog Einlagerung

die Richtigkeit und gibt dem Mitarbeiter die Information, dass er die Ware planm¨ aßig verr¨ aumt hat oder erzeugt einen Pr¨ uﬀalldialog. Die erste Palette mit f¨ unfundzwanzig Laserdruckern ist eingelagert. Nun bearbeitet der Mitarbeiter die weiteren drei Paletten. Den Einlagerungsvorgang f¨ uhrt er in dieser Form noch dreimal aus. Allerdings tragen die entsprechenden Ladehilfsmittel nun die Identiﬁkationsnummern 000001 bis 000003. Die Lagerpl¨atze tragen die Identiﬁkationsnummern R1-1-2 bis R1-1-4. Einlagern in das HRL Das Aufsetzen einer Palette am I-Punkt hat die Identiﬁzierung der Ladeeinheit u ¨ber die station¨are Lesestelle zur Folge. Die entsprechende SPS versendet daraufhin ein Telegramm mit der Paletten-ID an das WMS. Das WMS wertet den Eingang der Nachricht als Trigger und pr¨ uft zun¨ achst, ob die gemeldete Paletten-ID bekannt ist. Ist dies nicht der Fall, handelt es sich um einen Fehler, da die Paletten-ID bei der Warenannahme zusammen mit der Artikel-ID an das WMS h¨atte gemeldet werden m¨ ussen. In diesem Fall wird f¨ ur die Palette ein Transportauftrag auf die Auslagerbahn generiert, so dass sie ausgeschleust und zur Clearing-Stelle gebracht werden kann. Dasselbe passiert, wenn der Leser keine Paletten-ID identiﬁzieren konnte (NO READ). Ist die Paletten-ID dem WMS bekannt, wird die Palette auf der Staurollenbahn weitergef¨ ordert und passiert die Konturenkontrolle. Entspricht das erfasste Proﬁl nicht der Vorgabe, wird die Palette unmittelbar u ¨ ber die Auslagerbahn aus dem Lager ausgeschleust. Andernfalls wird die Ware in den Bestand gebucht, ein Einlagerauftrag generiert und gleichzeitig der entsprechende Lagerplatz reserviert. Die Bestimmung eines geeigneten Lagerplatzes soll so erfolgen, dass die Artikel 1. gassen¨ ubergreifend m¨ oglichst gleichverteilt und 2. innerhalb der Gassen m¨ oglichst gem¨ aß einer ABC-Zonung angeordnet sind. Die gassen¨ ubergreifende Gleichverteilung erh¨oht die Zugriﬀssicherheit; die ABC-Zonung erm¨ oglicht einen schnellen Zugriﬀ auf die schnelldrehenden Artikel bei der Auslagerung. Sind keine entsprechenden Lagerpl¨atze verf¨ ugbar, kann ein Artikel prinzipiell auf jedem freien Lagerplatz eingelagert werden.

288

7. Implementierung eines WMS am Beispiel myWMS

Abbildung 7.15. Dialog Kommissionierung

Ein Einlagervorgang ist abgeschlossen, sobald das entsprechende Ladehilfsmittel auf dem richtigen Einlagerplatz verbucht werden konnte. Bestellungen Kundenauftr¨ age oder Bestellungen werden u ¨ ber ein ERPSystem in das WMS eingelastet. Ein Kundenauftrag besteht in der Regel aus mehreren Positionen. Kann eine Position des Auftrages nicht erf¨ ullt werden, weil die verf¨ ugbaren Einheiten des gew¨ unschten Artikels im Lager nicht ausreichen, wird der gesamte Auftrag abgelehnt und eine Meldung an das ERP gesendet. Andernfalls reiht das WMS die Bestellung in die AuftragsWarteschlange ein. Auf Basis der Bestellungen erzeugt das WMS Kommissionierauftr¨ age und w¨ ahlt diejenigen Ladeeinheiten aus, die zur Erf¨ ullung der einzelnen Positionen ausgelagert werden sollen. Es muss daf¨ ur Sorge tragen, dass die Auswahl geeigneter Ladeeinheiten so erfolgt, dass folgende - evtl. kontr¨ are - Zielsetzungen erreicht werden: 1. Die Anzahl der zu kommissionierenden Paletten soll m¨oglichst gering sein, d.h. es sollen nach M¨ oglichkeit Ladeeinheiten direkt ausgelagert werden. Dabei sollen auch angebrochene Paletten ber¨ ucksichtigt werden. 2. Die Lagereinheit mit dem ¨ altesten Einlagerdatum, respektive der Charge mit dem ¨ altesten Mindesthaltbarkeitsdatum, soll zuerst ausgelagert werden. Kommissionierung aus dem Regallager (Mann zur Ware) Die Kommissionierung eines Kundenauftrages von z. B. vierzig Laserdruckern und die Bearbeitung der Dokumentation geschehen durch einen Lagermitarbeiter mittels seines Handger¨ ates. Hierzu muss dieser das Handger¨at im Log-in Dialog im Web anmelden. Auf der Startseite w¨ahlt er den Punkt Kommis” sionierung“ aus. Es ¨ oﬀnet sich ein Fenster, in dem er den zu kommissionierenden Auftrag zur Bestellung VM10096 ausw¨ahlt und auf Weiter“ klickt. ” Dann wird er u at zum Lagerplatz R1-1-1 gef¨ uhrt. (Abb. 7.15) ¨ber das Handger¨ Sobald er den Lagerplatz erreicht hat, scannt er den Barcode des Platzes ab. Auf dem Handger¨ at wird ihm angegeben, dass er f¨ unfundzwanzig St¨ uck des

7.4 Beispielhaftes Distributionssystem/Referenzlager

289

Artikels Drucker X entnehmen soll. Nach Entnahme best¨atigt er die entnommene Menge im Textfeld. Das Handger¨ at meldet ihm, dass es sich bei der Warenentnahme um einen Nulldurchgang handelt, da nach Entnahme von f¨ unfundzwanzig Druckern die Ladeeinheit leer ist. Zur Sicherheit wird u ¨ ber das Handger¨ at nochmals abgefragt, ob ein Restbestand auf der Palette vorhanden ist. Diesen kann er mit 0“ angeben. Er wird zur Entnahme weiterer ” f¨ unfzehn Laserdrucker durch das Handger¨ at zum Lagerplatz R1-1-2 geleitet. Der Entnahmevorgang wiederholt sich. Das Handger¨at gibt ihm an, dass er alle Positionen des ausgew¨ ahlten Kommissionierauftrages erledigt hat. Im n¨achsten Schritt wird er u at zum Warenausgang Tor 4 (WA), ¨ ber das Handger¨ der in der Bestellung als Zielplatz hinterlegt ist, geleitet. Sobald er dort angekommen ist, scannt er den Barcode des Tor 4 (WA) mit dem Handger¨at und schließt so den Prozess ab. Das LVS pr¨ uft die Richtigkeit des vorgegebenen und des gescannten Zielplatzes. Somit sind die bestellten vierzig Laserdrucker kommissioniert und stehen f¨ ur den Versand im Warenausgang an Tor 4 (WA) bereit. Kommissionieren aus dem HRL (Ware zum Mann) Kundenauftr¨age werden u ¨ ber ein ERP-System in das WMS eingelastet und in eine Warteschlange eingereiht. Ein Kundenauftrag besteht in der Regel aus mehreren Positionen. Kann eine Position des Auftrages nicht erf¨ ullt werden, weil die verf¨ ugbaren Einheiten des gew¨ unschten Artikels im Lager nicht ausreichen, wird der gesamte Auftrag abgelehnt und eine Meldung an das ERP gesendet. Andernfalls reiht das WMS den Kundenauftrag in die AuftragsWarteschlange ein, von wo sie vom WMS nach dem FIFO-Prinzip oder gem¨aß ihrer Priorisierung der Reihe nach abgearbeitet werden. Auf Basis der Kundenauftr¨ age erzeugt das WMS Auslagerauftr¨ age und w¨ahlt diejenigen Ladeeinheiten aus, die zur Erf¨ ullung der einzelnen Positionen ausgelagert werden sollen. Es muss daf¨ ur Sorge tragen, dass die Auswahl geeigneter Ladeeinheiten so erfolgt, dass folgende - evtl. kontr¨ are - Zielsetzungen erreicht werden: 1. Die Anzahl der zu kommissionierenden Paletten soll m¨oglichst gering sein, d.h. es sollen nach M¨ oglichkeit Ladeeinheiten direkt ausgelagert werden. Dabei sollen auch angebrochene Paletten ber¨ ucksichtigt werden. 2. Die LE mit dem ¨ altesten Einlagerdatum soll zuerst ausgelagert werden. 3. Der Auslastungsgrad der Regalbedienger¨ ate soll ann¨ahernd gleich sein. Paletten, die nicht kommissioniert werden m¨ ussen, verlassen das Lager u ¨ber Querverteilwagen und Auslagerbahn. Auf dem Querverteilwagen ﬁndet ¨ bei der Aufnahme der Palette vom Ubergabeplatz des HRL eine Identiﬁzierung u ¨ ber die Lesestelle statt, um zu kontrollieren, ob es sich um die richtige Palette handelt. Bei negativem Pr¨ ufergebnis wird die Palette zum ClearingPlatz transportiert. Ansonsten wird bei Ankunft der Palette auf der Auslagerbahn das Staplerleitsystem angewiesen, diese Palette auf den f¨ ur den zugeh¨ origen Auftrag vorgesehenen Puﬀerplatz im Warenausgang zu f¨ordern.

290

7. Implementierung eines WMS am Beispiel myWMS

Abbildung 7.16. Dialog Warenausgang

Kann eine Position nicht ausschließlich mit ganzen Paletten erf¨ ullt werden, muss kommissioniert werden. In diesem Fall wird die vom WMS als geeignet identiﬁzierte Palette vom HRL u ¨ber den Querverteilwagen auf den Kommissionierplatz gef¨ ordert, der dem aktuellen Auftrag zugeordnet ist. Dort bekommt der Kommissionierer u ¨ ber das Terminal angezeigt, wie viel Mengeneinheiten er zu entnehmen und auf die bereitgestellte Auftragspalette abzulegen hat. Durch Bet¨ atigung des Tasters signalisiert er dem WMS die Fertigstellung des Kommissioniervorgangs. Das WMS bestimmt daraufhin einen neuen Lagerplatz f¨ ur die R¨ ucklagerung der Palette. Zudem wird u uft, ob mit Erledigung des Kommissioniervorgangs alle zu kommissio¨berpr¨ nierenden Positionen f¨ ur den aktuellen Auftrag abgearbeitet sind. Falls das der Fall ist, veranlasst das WMS das Staplerleitsystem zum Abtransport der Auftragspalette auf den f¨ ur diesen Auftrag reservierten Puﬀerplatz im Warenausgang. Dort werden kommissionierte und direkt ausgelagerte Ladeeinheiten zusammengef¨ uhrt, nach Bedarf verdichtet und versandfertig verpackt.

Versendung der Waren Zur Versendung der kommissionierten vierzig Laserdrucker w¨ ahlt der Lagermitarbeiter auf der Startseite im Handger¨at den Punkt Versand“ aus. Es ¨ oﬀnet sich ein Fenster, in dem er den zu versenden” den Auftrag zur Bestellnummer VM10096 ausw¨ahlt und auf Weiter“ klickt. ” Dann scannt er mit dem Handger¨ at den Barcode der kommissionierten, zu versendenden Lagereinheit. Das LVS gleicht die gescannte Ladeeinheit mit der zu versendenden und markiert diese, zur Best¨atigung der Richtigkeit gr¨ un (Abb. 7.16). Nach Klick auf Weiter“ gibt ihm das Handger¨at an, dass er ” den Auftrag bearbeitet hat. Somit k¨ onnen die vierzig Laserdrucker versendet werden.

7.5 Erweiterungsszenarien Anhand zweier Beispiele soll gezeigt werden, wie durch die Service-orientierte Architektur eine Erweiterung des Systems vonstattengehen kann.

7.5 Erweiterungsszenarien

291

7.5.1 Erg¨ anzung eines Pick-By-Light Systems In diesem Szenario soll das Regal R1 mit einem Pick-By-Light System ausgestattet werden. Bis jetzt wurde in diesem Bereich mit Hilfe des mobilen Handger¨ ates der Prozess gef¨ uhrt. Stattdessen wird der Prozess nun wie folgt ge¨ andert: Der Kommissionierer f¨ ahrt mit einem Kommissionierwagen, auf dem sich auftragsbezogene Kommissionerbeh¨ alter beﬁnden, in die Kommissionierzone. Dort scannt er mit einem am Wagen montierten Scanner die Nummer eines Auftragsbeh¨ alters. Das System bestimmt daraufhin, von welchen Lagerpl¨ atzen welche Menge entnommen und in den Auftragsbeh¨alter ¨ kommissioniert werden soll. Uber eine Schnittstelle wird diese Information an das Pick-By-Light System u ¨bergeben. Als Folge werden auf den Displays der bezeichneten Lagerpl¨ atze die u ¨ bermittelten Mengen angezeigt. Der Kommissionierer f¨ ahrt zum n¨ achstgelegenen Lagerplatz, entnimmt dort die angezeigte Menge und best¨ atigt durch den neben dem Display beﬁndlichen Taster die Entnahme. Zur Umsetzung dieses Szenarios m¨ ussen zuerst die topologischen Stammdaten angelegt werden. Dies geschieht entweder u ¨ ber die Dialoge zur Stammdatenverwaltung in der Benutzeroberﬂ¨ ache, u ¨ ber einen Excel-Import oder durch folgende Programmlogik: for (int x = 1; x < 4; x++) { for (int y = 1; y < 2; y++) { String locName = "R1-" + y + "-" + x; RackLocation loc; try { loc = locQuery .queryByIdentity(locName); log.info("RackLocation exists:" + locName); } catch (BusinessObjectNotFoundException ex) { loc = new RackLocation(); loc.setClient(rack.getClient()); loc.setArea(areaKomm); loc.setName(locName); loc.setRack(rack); loc.setXPos(x); loc.setYPos(y); manager.persist(loc); log.info("Created RackLocation " + locName); } } }

Als n¨ achstes muss eine Fassade deﬁniert werden, die vom Pick-By-Light System aufgerufen werden kann. Die Fassade enth¨alt zwei Operationen: getPickLocations wird vom Pick-By-Light-System aufgerufen und liefert die Namen der Lagerpl¨ atze, von denen f¨ ur die u ¨ bergebene Nummer des Auftragsbeh¨ alters (Parameter unitLoadId) Ware entnommen werden soll. Mit dem Aufruf von setPicked am Ende eines jeden Kommissioniervorganges

292

7. Implementierung eines WMS am Beispiel myWMS

meldet das Pick-By-Light System die erfolgreiche Entnahme. Die Fassade zeigt das folgende Listing: @Remote public interface PickByLight { /** * Returns a list of StorageLocation names and amounts to pick for * the specified unitLoadId in the specified rack. * * @param rackId the name of the rack - per convention the first * characters found in each StorageLocation name of this rack * @param unitLoadId the UnitLoad where the new StockUnits are * picked to * @return a list of locations and it amounts being picked */ PickByLightLocationDataTO[] getPickLocations(String unitLoadId); /** * This method is called, if a picker has picked and acknowledged an * amount. * * @param data containing the StorageLocation name and the picked * amount * @param unitLoadId the UnitLoad where the new StockUnits are * picked to */ void setPicked(PickByLightLocationDataTO data, String unitLoadId); }

Die Implementierung der Fassade gestaltet sich nun ¨außerst einfach, da auf vorhandene Dienste zugegriﬀen werden kann. In diesem Fall nutzt die Fassade u ¨ber die Annotation @EJB den in myWMS LOS vorhandenen Dienst PickOrderFacade und ruft dort die Operation processPickRequestPosition auf. Die notwendigen Informationen stehen in den Attributen pickAmount (Menge) und locationName (Lagerplatz) des als Parameter empfangenen Datentransferobjekts PickByLightLocationDataTO. Anhand des Parameters unitLoadId kann die Implementierung die aktuell zu bearbeitende Auftragsposition pos u ¨ ber einen weiteren Dienst (LOSPickRequestPositionService) ermitteln. @EJB PickOrderFacade pickOrderFacade; @EJB LOSPickRequestPositionService pickRequestPositionService; public void setPicked(PickByLightLocationDataTO data, String unitLoadId){ LOSPickRequestPosition pos = pickRequestPositionService.getByUnitLoad(unitLoadId);

7.5 Erweiterungsszenarien

293

pickOrderFacade.processPickRequestPosition( pos, data.locationName, new BigDecimal(data.pickAmount)); }

Mit der Deﬁnition einer projektspeziﬁschen Fassade und einer wenigen Zeilen umfassenden Programmlogik kann demzufolge eine weitreichende Erweiterung des Systems um eine neue Technologie realisiert werden. Aus Gr¨ unden der Transparenz ist in dem Implementierungsbeispiel auf eine Fehlerbehandlung verzichtet worden. Außerdem setzt dieses Beispiel voraus, dass das Pick-By-Light-System u ¨ber eine RMI oder Web Service Schnittstelle verf¨ ugt. Anderenfalls muss u ¨ber einen zwischengeschalteten Konnektor eine andere Form der Schnittstelle (z.B. TCP-IP) implementiert werden (vgl. Abschn. 7.5.5). 7.5.2 Anbindung der F¨ ordertechnik und Steuerungstechnik Die Informationen zum Steuern eines automatischen Lagers werden zun¨achst aus der im Lager vorhandenen Sensorik und Identiﬁkationstechnik bezogen. Als Identiﬁkationsmedium kommt ein auf dem Ladehilfsmittel angebrachtes Barcode-Label zum Einsatz. Die Applikation des Labels geschieht w¨ahrend des Prozesses am Wareneingang, der außerhalb der Systemgrenze des Referenzlagers liegt und somit hier nicht betrachtet wird. Innerhalb des Lagers kann mit Hilfe zweier Lesestellen jede Palette identiﬁziert werden. Eine dieser Lesestellen beﬁndet sich station¨ ar am Anfang der Einlagerbahn zur Identiﬁkation von Paletten, die in die Systemgrenze eintreten. Die zweite Lesestelle ¨ beﬁndet sich auf dem Querverteilwagen. Zur Uberpr¨ ufung der Paletten, die u uber hinaus eine ¨ber die Einlagerbahn die Systemgrenze passieren, ist dar¨ Konturenkontrolle installiert. Diverse Lichtschranken (z. B. am Ende jeder Staurollenbahn und jedes ¨ Ubergabeplatzes) erm¨ oglichen außerdem die Waren- und Ablaufverfolgung innerhalb des Lagers (Tracking und Tracing). Die Kommissionierpl¨atze sind mit Tastern, u ¨ber die der Kommissionierer einen Auftrag quittieren kann, sowie mit Terminals zum Anzeigen des zu entnehmenden Artikels und der Entnahmemenge ausgestattet. S¨ amtliche Sensorinformationen werden von den Sensoren an u ¨berlagerte Speicherprogrammierbare Steuerungen (SPS) gesendet. Die SPS wiederum kommunizieren u ¨ ber Ethernet und TCP/IP mit den u ¨berlagerten Systemen. Je nach Steuerungsphilosophie handelt es sich dabei um das Lagerverwaltungssystem oder um einen Materialﬂussrechner und evtl. weitere Subsysteme. Jede SPS verdichtet die empfangenen Sensorinformationen und verschickt ein entsprechendes Telegramm an das u ¨berlagerte System. Umgekehrt empf¨ angt jede SPS vom u ¨berlagerten System Steuerungstelegramme, die sie in Steuerbefehle f¨ ur unterlagerte Aktoren umwandelt. Die Steuerungsarchitektur ist demnach hierarchischer Natur und als Client-Server-Struktur

294

7. Implementierung eines WMS am Beispiel myWMS

ERP System

Leitstand

WMS

IP

KP

PP1 PP2 PP3 PP4

RBG1 RBG2 RBG3 RBG4

Transportleitsystem

QVW

Abbildung 7.17. Systemhierarchie (logische Sicht) ERP System

WMS Leitstand

Barcodeleser QVW RS232

Gateway

TCP/IP Ethernet

Barcodeleser IP RS232 . . . . . .

TCP/IP Konturenkontrolle

. . .

. . .

. . . . . .

. . .

. . .

. . . . . .

. . .

. . .

. . . . . .

. . .

. . .

Steuerung der Regalbediengeräte Kommissionierterminals

Transportleitsystem

Abbildung 7.18. Systemhierarchie (physikalische Sicht)

¨ ausgelegt. Die Abbildungen 7.17 und 7.18 geben einen Uberblick u ¨ber die logische und physikalische Systemarchitektur. Insgesamt dienen sechs SPS zur Steuerung der F¨ordertechnik: je eine f¨ ur jedes Regalbedienger¨ at, eine f¨ ur den Querverteilwagen sowie eine SPS zur Steuerung der restlichen Lagervorzone inkl. der Kommissionierpl¨atze. Die SPS-Ebene bildet die gemeinsame Schnittstelle zwischen unterlagerter Steuerung und u ¨berlagerten Systemen. 7.5.3 Materialﬂuss Die grunds¨ atzlich m¨ oglichen Wege einer Palette durch das Referenzlager ergeben sich durch die beschriebene Topologie und die eingesetzte F¨ordertechnik.

7.5 Erweiterungsszenarien

295

Zentrale Bedeutung kommt dabei dem Querverteilwagen zu, da er die einzige Verbindung zwischen den Funktionsbereichen ist und als Knotenpunkt fungiert19 . Bedingt durch die unidirektionale F¨orderrichtung der einzelnen ¨ Ubergabepl¨ atze kann der Querverteilwagen entweder eine Palette von ei¨ nem Platz aufnehmen (Ubernahme auf den Querverteilwagen) oder aber ei¨ ne Palette auf einen Platz abgeben (Ubergabe vom Querverteilwagen). Ein ¨ Ubergabeplatz kann weder Paletten auf den Querverteilwagen abgeben noch von ihm entgegennehmen. Typische Wege einer Palette durch das Lager ergeben sich aus der logistischen Funktion des Lagers. Grunds¨ atzlich besteht diese aus den Grundfunktionen Einlagern, Auslagern und Kommissionieren. Beispiele f¨ ur typische Wege unter Einbeziehung des Querverteilwagens sind demnach • Einlagern in Gasse 4: I-Punkt → QVW → U1r → RGB4 → Lagerfach; • Auslagern aus Gasse 1: Lagerfach → RGB1 → U1l → QVW → Auslagerbahn; • Kommissionieren: Lagerfach → RGB2 → U2l → QVW → Kommissionier − U2 → QVW U2r → RGB2 → Lagerfach. Typische Wege ohne Einbeziehung des Querverteilwagens sind • Umlagern in Gasse 1: Lagerfach → RGB1 → Lagerfach; • negative Konturenkontrolle: Einlagerbahn → Auslagerbahn. 7.5.4 Plug-In - Routing Der Weg von einer Quelle, beispielsweise einem Regalfach, zu einem Ziel, etwa einem Kommissionierplatz, wird durch ein Plug-In berechnet, welches das RouteStrategyInterface erf¨ ullt. myWMS stellt mit der Klasse RouteStrategyFirstMatch ein einfaches Routing-Plug-In zur Verf¨ ugung, das u ¨ ber eine Rekursion immer einen Weg ﬁndet, sofern er existiert. In der Praxis ist es ausreichend, diese Klasse gem¨aß den Anforderungen ¨ nach dem Prinzip der Vererbung zu erweitern. Ein Uberschreiben der Methode findWay() der Klasse RouteStrategyFirstMatch mit einem auf die Gegebenheiten des Lagers angepassten Algorithmus ist in vielen F¨allen ausreichend. Der Aufruf von findWay() erfolgt durch die Methode route() des Plug-In-Interfaces. Alternativ besteht die M¨oglichkeit, das Interface durch eine eigene Klasse ohne Ableitung direkt zu erf¨ ullen. Dabei ist neben den Anforderungen der ererbten Interfaces20 nur die Methode route() zu implementieren. 19

20

Trotz der B¨ undelung der Transporte auf ein einziges zentrales Ger¨ at und der prinzipiellen Gefahr des Engpasses stellen richtig dimensionierte Verteilwagen kosteng¨ unstige, raumsparende und dennoch leistungsf¨ ahige L¨ osungen dar. Plug-In-Interface und dessen Vorg¨ anger, das ConﬁgurationClientInterface.

296

7. Implementierung eines WMS am Beispiel myWMS

public interface RouteStrategyInterface extends PluginInterface { OrderChain[] route(final OrderChain[] orders, long tid) throws TransactionException; }

Der Methode route() werden Paare von Quellen und Zielen u ¨bergeben, f¨ ur jedes dieser Paare berechnet route() einen Weg. Quelle und Ziel sind jeweils eine StorageLocation und werden in einer sonst leeren OrderChain u uck¨bergeben. Der Weg wird ebenfalls als OrderChain an den Aufrufer zur¨ gegeben, jetzt jedoch mit einer detaillierten Route, bestehend aus den einzelnen StorageLocations (Wegpunkten) und den HandlingScopes, die diese verbinden. route() ist als die Mehrfachanwendung der mathematischen Funktion r zu verstehen, die auf dem Transportnetz mit den Knoten l und den im HandlingScope h beﬁndlichen Kanten arbeitet: ⎧ l1 = l2 ⎨ null es existiert kein Weg r(l1 , l2 ) = null ⎩ l1 , (h, l)∗, h, l2 sonst Aus der Funktion ist ersichtlich, dass es zwischen zwei StorageLocations nicht immer einen Weg geben muss. Das so gebildete Plug-In muss der Applikation bekannt gemacht werden. Dazu wird ein entsprechender Eintrag in die Konﬁgurationsdatei vorgenommen. Der Konﬁgurationsmanager sorgt f¨ ur die Instanziierung des Plug-Ins. Abbildung 7.19 zeigt das Zusammenspiel der einzelnen Komponenten: • • • •

Der MFC Modul enth¨ alt alle Plug-In-Interfaces. Ein Plug-In muss dieses Interface erf¨ ullen. Das Plug-In kann durch Vererbung erweitert werden. Die Konﬁguration entscheidet, welches Plug-In zur Laufzeit verwendet wird.

Sinngem¨ aß muss die hier beschriebene Vorgehensweise bei allen PlugIn-Schnittstellen eingehalten werden. myWMS beinhaltet eine umfangreiche Bibliothek vorgefertigter Plug-Ins, die bereits den Aufbau einfacher WMS erm¨ oglichen. 7.5.5 Kommunikation Die M¨ oglichkeit einer Kommunikation zwischen myWMS und den unterlagerten Aktoren und Sensoren, respektive deren Zusammenfassung zu Subsystemen, ist grundlegender Bestandteil des myWMS MFC Moduls, der den Materialﬂuss steuert. Im Rahmen dieser Kommunikation sendet und empf¨angt

7.5 Erweiterungsszenarien 2

1

Equipment Kernel

3

class RouteStrategyFirstMatch implements RoutestrategyInterface . . .

interface RouteStrategyInterface . . .

297

{

class RouteShortestPath extends RouteStrategyFirstMatch . . .

Vererbung

~

Interface

{

Zuordnung

equipment.config

de.mywms.wms.kernel.equipment.EquipmentKernel.RoutingStrategyClassname= de.mywms.wms.kernel.equipment.strategy.RouteShortestPath

Abbildung 7.19. Einbindung eines Plug-Ins u ¨ ber die Konﬁguration

eine Komponente Objekte, w¨ ahrend die angeschlossenen Ger¨ate Bytestreams unterschiedlicher Formate empfangen und senden. Basisklasse aller Kommunikationsobjekte ist die Klasse ComObject, die grundlegende Methoden bereitstellt, wie etwa die Propertyverwaltung. Das Design-Pattern Property“ mit den beiden Methoden setProperty() und ” getProperty() erleichtert die Implementierung der unterschiedlichen aus ComObject abgeleiteten Klassen. Direkt von ComObject abgeleitet ist die Klasse DirectedMessage, die u ¨ ber die gesch¨ utzten Methoden setProperty() und getProperty() der Basisklasse ¨ oﬀentliche Funktionalit¨ at f¨ ur die Festlegung (set) und Abfrage (get) folgender Attribute zur Verf¨ ugung stellt: • sender ist der Erzeuger der Instanz • receiver ist der Empf¨ anger der Nachricht

298

7. Implementierung eines WMS am Beispiel myWMS

<<event>> DeviceStateEvent data:String type:String <<event>> DeviceAliveEvent

<<message>> ComObject +setProperty:void +getProperty:String #match:boolean +toString:String Properties:PropertyObject timeout:int

<<event>> DirectedMessage

<<event>> DeviceReadEvent data:String unit:String

+setSortingOrder:void +checkIt:void #match:boolean sender:String receiver:String sequenceNummer:String functionCode:String

storageLocation:String localSortingOrder:String <<event>> MfcStateEvent operationMode:String localSortingOrder:String <<Event>> MfcTransportEvent storageLocation:String unitLoadKods:String unitLoads:String <<event>> MfcModifyRequest

<<event>> DeviceWriteRequest

storageLocation:String unitLoadKods:String unitLoads:String

data:String commandArgument:String <<event>> DeviceCommandRequest command:String commandArgument:String

<<event>> MfcStateRequest

<<event>> MfcTransportOrder <<event>> Response errorCode:String

orderNummer:String transportSource:String transportDestination:String unitLoadKods:String unitLoads:String <<event>> MfcTransportExecution orderNummer:String storageLocation:String unitLoadDifference:String

Abbildung 7.20. Diagramm der Kommunikationsklassen

• functionCode beschreibt den Typ der Nachricht • sequenceNumber ist ein Z¨ ahler zur Prim¨ arschl¨ usselbildung Ist ein dem myWMS bekannter functionCode angegeben, wird ein hierf¨ ur spezialisiertes Objekt erzeugt. Die Abb. 7.20 zeigt durch ein Klassendiagramm, welche m¨ oglichen Auspr¨ agungen existieren. Bei spezialisierten Kommunikationsobjekten ist eindeutig festgelegt, wie sie innerhalb von myWMS zu behandeln sind. Kommunikationsobjekte mit einem unbekannten functionCode k¨ onnen von myWMS nicht ausgewertet werden, sie sind f¨ ur anwendungsfallspeziﬁsche Erweiterungen vorgesehen.

7.5 Erweiterungsszenarien

299

Die Klasse MfcTransportOrder erweitert DirectedMessage und dient der Beauftragung der Transportger¨ ate. Die erforderlichen neuen Attribute werden nicht als Elemente dieser Ableitungsstufe angelegt, sondern in der Propertystruktur der Wurzelklasse abgelegt. Diese neuen Attribute sind • • • •

transportSource, der Startpunkt des Transportes transportDestination, der Endpunkt des Transportes orderNumber, eine laufende Nummer f¨ ur den Transport unitLoads, die Anzahl der Transporteinheiten

Die Einzelschritte eines Tansportauftrages werden mit Hilfe einer Routingstrategie in MfcTransportOrder abgebildet und u ¨ber das im Folgenden beschriebene Protokoll-Channel-Verfahren an die ausf¨ uhrenden Maschinen kommuniziert. Die Kommunikationsobjekte werden u ¨ber den Channel (vgl. Abschn. 7.3.4) mit der Umgebung ausgetauscht. Dabei u ¨bernimmt der Channel die Abwicklung der Datentransporte und nutzt ein Protokollobjekt f¨ ur die Serialisierung der Kommunikationsobjekte bzw. deren Konstruktion aus den Bytestreams. public ... public throws public }

interface Protocol { byte[] eval(ComObject comObject, ...) ComException; ComObject[] eval(byte[] bytes, ...);

Jedes Protokoll muss das obige Protokoll-Interface erf¨ ullen; im Wesentli¨ chen ist hier die Methode eval zu nennen, die durch Uberladung zweifach zu implementieren ist: • Bei der Serialisierung wird eval als erster Parameter ein ComObject u ¨bergeben. Nach den Regeln des zu implementierenden Protokolls wird das ComObject in ein Array aus Bytes (byte[]) u uhrt und dem Aufru¨ berf¨ fer zur¨ uckgegeben. • Bei der Deserialisierung wird eval ein Bytearray als erster Parameter u ¨bergeben. Das Bytearray stellt den Ausschnitt eines empfangenen Streams dar. Bei dieser Konstruktion kann ein ComObjects unvollst¨andig sein, Daten f¨ ur ein oder mehrere ComObjects enthalten, unvollst¨andige Teile des n¨achsten enthalten oder fehlerhaft sein. Aus vollst¨ andigen Bytefolgen werden ComObjects erzeugt und in einem Array zur¨ uckgegeben. Unvollst¨andige Bytefolgen m¨ ussen bis zum n¨ achsten eval-Aufruf zwischengepuﬀert werden. myWMS beinhaltet mehrere Protokolle, die unterschiedliche Zielsetzungen verfolgen. So existieren Klassen f¨ ur die Kommunikation mit einer Auswahl von AutoID-Ger¨ aten. Andere Klassen repr¨asentieren Protokolle f¨ ur den Datenaustausch mit Materialﬂussrechnern. Ein universell einsetzbares Protokoll ist durch die Klasse XMLProtokoll gegeben. Hier k¨onnen die Flexibilit¨at der XML-Metasprache sowie aller XML-Tools genutzt werden.

300

7. Implementierung eines WMS am Beispiel myWMS

<message type="WMSmessage">

<MfcTransportOrder unitLoads="0001" orderNumber="3" transportSource="1.2" transportDestination="1.7" />

Das obige Beispiel zeigt ein serialisiertes MfcTransportOrder-Objekt, das durch eine Instanz des XML-Protokolls serialisiert wurde und in dieser Form an ein Transportger¨ at (LoadHandler) geschickt werden kann. Die Bezeichner f¨ ur Transportquellen und -ziel entsprechen dabei der Sicht“ des Transport” ger¨ ates.

7.6 Fazit In diesem Kapitel wurden einige grunds¨ atzliche Techniken anhand eines einfachen Distributionssystems erl¨ autert. Es wurde beispielhaft gezeigt, dass ein WMS mehr als ein Datenmodell beinhaltet. Warehouse Managementsysteme sind komplexe Systeme, welche die unterschiedlichsten Anforderungen erf¨ ullen m¨ ussen. Sie stellen damit eine Herausforderung an die Softwaretechnik dar, die sich in den letzen Jahren – insbesondere durch den Einsatz der objekt- und serviceorientierten Techniken und geeigneter, anwendbarer Methoden und Werkzeuge – zu einer praktisch nutzbaren Ingenieursdisziplin entwickelt hat. Es gilt weiterhin, mit geeigneten Methoden und Standards unterschiedliche Anforderungen schnell, kosteng¨ unstig und in guter Qualit¨at umzusetzen. Das in diesem Abschnitt vorgestellte objektorientierte Konzept in Verbindung mit einer Service-orientierten Architektur stellt neben den auf relationalen Datenbanken basierenden WMS eine M¨oglichkeit dar, dieses Ziel zu erreichen.

8. Auswahl und Einfu ¨ hrung von WMS

Die durchschnittliche Einf¨ uhrung eines umfangreichen WMS, z. B. im Rahmen eines Distributionszentrums, betr¨ agt in der Regel neun Monate1 . Ein solcher Zeitrahmen deutet darauf hin, dass die Einf¨ uhrung eines WMS ein komplexes Vorhaben ist, welches nicht mit der Installation einer beliebigen Software-Anwendung wie beispielsweise einer Textverarbeitung zu vergleichen ist. So muss die WMS-Einf¨ uhrung als ein Projekt2 eingestuft werden. Nicht immer kann ein reibungsloser operativer Betrieb des Lagers w¨ahrend dieser Zeit sichergestellt werden. Im Rahmen der Realisierungsmaßnahmen kann es zu St¨ orungen kommen, wobei die Gr¨ unde sehr vielf¨altig sein k¨onnen (beispielsweise Anpassungsschwierigkeiten bei der Umsetzung der neuen Arbeitsanl¨ aufe, Hemmnisse bei der Bedienung der neuen Software und Integrationsprobleme bei der neuen Hardware). Solche St¨orungen sind sowohl zeitals auch kostenintensiv und m¨ ussen soweit wie m¨oglich minimiert werden. Unabdingbar sind somit eine sorgf¨ altige Planung im Vorfeld des Projektes und anschließend eine zielgerechte Vorgehensweise bei der Umsetzung. Dieses Kapitel zeigt einen systematischen Ablauf auf, wobei die Auswahl und Einf¨ uhrung von WMS grunds¨ atzlich dem gleichen schematischen Ablauf folgt, wie er bei der Einf¨ uhrung einer beliebigen Software in entsprechender Gr¨ oßenordnung in Industrie- und Dienstleistungsbereichen u ¨ blich ist (s. Tabelle 8.1). Je nach Ausgangssituation unterteilen sich die Projekte in 1. die Abl¨ osung eines vorhandenen WMS 2. die Einf¨ uhrung eines neuen WMS im Rahmen eines Lagerneubaus Da sich die Projektabwicklung in beiden F¨allen nur geringf¨ ugig unterscheidet, wird im Weiteren lediglich die Abl¨ osung eines bestehenden WMS betrachtet. Sollte sich f¨ ur den Lagerneubau die im Folgenden beschriebene Vorgehensweise grundlegend unterscheiden, wird darauf explizit hingewiesen. Die VDI-Richtlinie 2523 (Projektmanagement f¨ ur logistische Systeme der Materialﬂuss- und Lagertechnik) deﬁniert die grundlegenden Schritte der Projektabwicklung, auf die im Folgenden Bezug genommen wird. 1 2

Quelle: Internationale Marktstudie WMS, http://www.warehouse-logistics.com Ein Vorhaben, zu dessen Durchf¨ uhrung besondere organisatorische Maßnahmen erforderlich sind. In der Regel ist das Projekt zeitlich begrenzt, hat deﬁnierte Ziele, ist einmalig und ist bereichs¨ ubergreifend anzugehen.

302

8. Auswahl und Einf¨ uhrung von WMS

Tabelle 8.1. Projektablauf Projektschritt

Arbeitspunkte

Kick-off ”WMS-Projekt“

Installation des Gesamt-Projektteams

Anforderungsdefinition

Ist-Aufnahme Schwachstellenanalyse Entwicklung Soll-Konzept

Erstellung der Ausschreibungsunterlagen

Definition Leistungskennziffern Erstellung Lastenheft

Auftragsvergabe

Anbietervorauswahl und qualifizierte Versendung der Ausschreibungsunterlagen Standort-/ Lagerbesichtigung

Komplettierung der Ausschreibungsunterlagen

Angebotsvergleich Angebotspräsentation Besuche von Referenzanlagen ausgewählter Anbieter Anbieterauswahl Kick-off ”WMS-Einführung“

Installation des Projektteams ”WMS-Einführung“

Umsetzung

Pflichtenhefterstellung Realisierung

Inbetriebnahme

Laborphase Übergang vom alten zum neuen WMS Schulungsmaßnahmen

Abnahme

Leistungstest/ Funktionstest/ Verfügbarkeitsüberprüfung Simulation von Störfällen/ Überprüfung von Notfallstrategien formale Abnahme

8.1 Kick-oﬀ: WMS-Projekt Zu Beginn eines WMS-Projektes wird ein Projektteam mit den relevanten Mitgliedern zusammengestellt. In diesem Team werden zu Beginn im Rahmen eines Kick-oﬀ-Meetings die Arbeitsschritte, Projektziele sowie die erforderlichen Formalien (z. B. Protokollf¨ uhrung, Projektdokumentation, Datenaustausch) vereinbart. Weiterhin erfolgt die Abstimmung zur tempor¨aren Einbindung weiterer Personen, die zur Projektbearbeitung notwendig sind. Es ist f¨ ur die erfolgreiche und zeitgerechte Durchf¨ uhrung des WMS-Projektes notwendig, dass die Mitglieder des Projektteams f¨ ur die Projektarbeit von ihren sonstigen Aufgabenbereichen zumindest teilweise freigestellt werden. Weiter ist es erforderlich, dass das WMS-Projekt von der Gesch¨aftsleitung unterst¨ utzt wird und dass die Projektleitung die notwendige Befugnis besitzt, Entscheidungen zu treﬀen und durchzusetzen.

8.2 Projektmanagement/Qualit¨ atssicherungsmaßnahmen

303

Abbildung 8.1. Exemplarischer Umsetzungszeitplan

Zus¨ atzlich sind fr¨ uhzeitig Mitarbeiter der operativen Ebene (z. B. Kommissionierer) mit in das WMS-Projekt einzubeziehen. So wird gleich zu Beginn eine m¨ oglichst hohe Akzeptanz bei der Einf¨ uhrung neuer Abl¨aufe und ¨ Technologien erzielt und es werden Angste vor Ver¨anderungen genommen. Abschließend wird ein Umsetzungszeitplan erstellt, der die groben Meilensteine aufzeigt und den geplanten Zeitbedarf deﬁniert (s. Abb. 8.1). Bei der Erstellung des Umsetzungszeitplans ist auf eine realistische und umsetzbare Zeitplanung zu achten. Einzukalkulieren sind z. B. Urlaubszeiten oder besondere saisonale Belastungen. Zudem sollte die Inbetriebnahme nicht w¨ahrend der Hochsaison stattﬁnden.

8.2 Projektmanagement/Qualit¨ atssicherungsmaßnahmen W¨ ahrend des gesamten WMS-Projektes sollten im Rahmen des realisierungsbegleitenden Projektmanagements u ¨ bliche Controlling-Maßnahmen beachtet werden z. B. : ¨ • Uberwachung der Meilensteine Wurde der Zeitbedarf f¨ ur die jeweiligen Meilensteine eingehalten? K¨ undigen sich R¨ uckst¨ ande bei einzelnen Projektschritten an, oder bedrohen Verz¨ ogerungen die Gesamtlaufzeit?

304

8. Auswahl und Einf¨ uhrung von WMS

• Ressourcenkontrolle Reichen die zur Verf¨ ugung stehenden Ressourcen aus? W¨ urde eine Erh¨ohung der Ressourcen eine signiﬁkante Steigerung der Produktivit¨at ergeben? Wird das geplante Budget eingehalten? Ferner sind die zum Qualit¨ atsmanagement geh¨orenden realisierungsbegleitenden Qualit¨ atssicherungsmaßnahmen zu beachten.

8.3 Anforderungsdeﬁnition Die Projektphase der Anforderungsdeﬁnition wird wesentlich von der Erkenntnis getragen, dass das vorhandene WMS nicht mehr den Anforderungen entspricht und/oder der Status Quo verbessert werden muss. ¨ Die Ausl¨ oser f¨ ur die Einf¨ uhrung oder Uberarbeitung eines Warehouse Managementsystems k¨ onnen vielf¨ altig sein, wobei der angestrebte Eﬃzienzgewinn zumeist im Vordergrund steht. Weitere typische Ausl¨oser sind z. B.: • Einf¨ uhrung einer neuen Lagertechnik (z. B. automatisches Hochregallager) oder eines neuen Lagergutes (z. B. Gefahrgut) • Rationalisierung oder Erh¨ ohung der Leistungskennzahlen durch Einf¨ uhrung neuer Technologien (z. B. Erh¨ ohung der manuell erbrachten Kommissionierleistungen durch Einf¨ uhrung von Pick-To-Light) • Nutzung des Lagers f¨ ur verschiedene Eigent¨ umer der Ware (Mandantenf¨ ahigkeit) • Integration von zus¨ atzlichen wertsch¨ opfenden T¨atigkeiten im Lager (Value Added Logistics, VAL) • Vergabe der logistischen Leistungen an einen Dritten (Outsourcing) • ge¨ anderte Prozesse im Lager (z. B. Verbesserung der Qualit¨atssicherung und Dokumentation) ¨ • Anderung der Auftragsstruktur durch ver¨ andertes Bestellverhalten (z. B. stetig erh¨ ohte Kommissionierleistung durch kleinere Bestellmengen pro Auftrag, die nicht eﬃzient vom System unterst¨ utzt wird) • Integration von E-Commerce-L¨ osungen (z. B. die Integration eines OnlineShops) • Zukunftssicherung durch die Abl¨ osung veralteter Hard- und Software (z. B. Einf¨ uhrung neuer Datenbanken) • neue Schnittstellen zu u ¨bergeordneten ERP- und PPS-Systemen (z. B. ERP-Systemeinf¨ uhrung im Rahmen einer unternehmensweiten Strategie) 8.3.1 Ist-Aufnahme Aufgrund der vielf¨ altigen Erwartungen, die an ein neues WMS gestellt werden, kommt einer koordinierten und exakten Dokumentation des aktuellen Status eine besondere Bedeutung zu. Sie erfolgt im Rahmen der Ist-

8.3 Anforderungsdeﬁnition

305

Abbildung 8.2. Beispielhafte Prozesskette des Ist-Zustands

Aufnahme (auch Ist-Analyse genannt), die im Wesentlichen aus den folgenden Arbeitsg¨ angen besteht: Aufnahme der Gesch¨ aftsprozesse und des Informationsﬂusses Das Ziel der Gesch¨ aftsprozessaufnahme ist die l¨ uckenlose Dokumentation aller Gesch¨ aftsprozesse3 im Lager. Eine u ¨ bliche Darstellungsform ist die Gesch¨aftsprozesskette. Neben der reinen Aufnahme physischer T¨atigkeiten wird hier auch der Informationsﬂuss und die Verwendung von Dokumenten protokolliert. Dadurch werden unter anderem leistungsmindernde Medienbr¨ uche (Wechsel zwischen zwei unterschiedlichen Medien, z. B. EDV und Papier) erkennbar. Erfassung des bestehenden Leistungsumfangs des WMS Um ein genaues Bild u ¨ ber den Leistungsumfang eines WMS zu erhalten, werden alle verwendeten Funktionen sowie die dazugeh¨origen Gesch¨aftsprozesse und Abl¨ aufe aufgezeigt. Zudem werden die wesentlichen Antwortzeiten (z. B. Maskenaufbau, Datenbankzugriﬀ, Batch-Berechnung) erfasst. Dokumentation der Schnittstellen zu u ¨berlagerten (ERP, WWS) und unterlagerten (WCS) Systemen Bei der Dokumentation der Schnittstellen des WMS zu u ¨ ber- und untergeordneten Systemen wird der gesamte Datenaustausch des WMS erfasst. Zu dokumentieren sind Art und Anzahl der Fremdsysteme, die verwendeten Protokolle sowie die zu u ¨ bertragenden Eingangs- und Ausgangsdaten. Weiter sind der Speicherort der Stammdaten und die Gestaltung der Hierarchie von Daten- und Informationsﬂ¨ ussen zu erfassen.

3

Ein Gesch¨ aftsprozess in diesem Zusammenhang ist eine Abfolge von T¨ atigkeiten, die u auft und einen Wert f¨ ur ¨ber verschiedene betriebliche Funktionsbereiche verl¨ Kunden und Unternehmen schaﬀt.

306

8. Auswahl und Einf¨ uhrung von WMS

Beschreibung der Struktur der relevanten Daten Die Beschreibung der Struktur der relevanten Daten (z. B. Artikelnummer, Auftragsnummer, ¨ Charge) enth¨ alt einen vollst¨ andigen Uberblick u ¨ ber den Aufbau aller wichtigen Daten, Objekte und Nummernkreise, wie z. B. Artikelstammdaten, Seriennummern, Ladehilfsmittelnummern etc. (s. Tabelle 2.13, S. 66). Das Ziel der Ist-Aufnahme ist somit die l¨ uckenlose Erfassung und Beschreibung aller das Lager betreﬀenden Vorg¨ ange, Daten und Systeme. 8.3.2 Schwachstellen-Analyse Im Rahmen der Schwachstellen-Analyse werden alle Daten der Ist-Aufnahme hinsichtlich m¨ oglicher Verbesserungspotenziale untersucht. Die Unterteilung der Schwachstellen lehnt sich dabei an die im Rahmen der Ist-Aufnahme genannten Arbeitsg¨ ange an. Typische Schwachstellen sind nachfolgend genannt: Gesch¨ aftsprozesse und Informationsﬂuss im Lager Mit Hilfe der Prozesskettenanalyse4 (PKA) k¨ onnen Schwachstellen innerhalb der Gesch¨aftsprozesse (z. B. uneinheitliche Abl¨ aufe f¨ ur fast identische Prozesse oder keine deﬁnierten Prozesse f¨ ur Ausnahmesituationen) und des Informationsﬂusses (z. B. Medienbr¨ uche) aufgezeigt werden. Leistungsumfang des WMS Der vorhandene Leistungsumfang des WMS deckt nicht alle f¨ ur einen reibungslosen Betriebsablauf ben¨otigten Anforderungen ab (z. B. fehlende Unterst¨ utzung von ungeplanten Wareneing¨angen durch das WMS). Schnittstellen zu unter- und u ¨bergeordneten Systemen Nicht alle im Rahmen der Ist-Analyse aufgenommen Schnittstellen sind eindeutig beschrieben (z. B. unvollst¨ andige Beschreibung der ERP-Schnittstelle). Struktur relevanter Daten Die Struktur der vorhandenen Nummernkreise entspricht nicht mehr den tats¨ achlichen Anforderungen oder die ben¨otigten Nummernkreise sind im WMS nicht vorhanden (z. B. Bedarf einer Seriennummer zur Seriennummern-Verfolgung, Fehlen eines entsprechenden Datenfeldes im WMS).

4

Eine Prozesskette l¨ asst sich als eine abgestimmte, d.h. an einem festgelegten Ablauf orientierte Abfolge einzelner Teilprozesse (Prozesskettenelemente) festlegen. F¨ ur die Prozesskettenanalyse werden zun¨ achst die relevanten Prozessketten aufgenommen und anschließend hinsichtlich der zu realisierenden Potenziale (z. B. Zeitreduzierung und Kostenersparnis) untersucht ([30]; [31], S. 162ﬀ).

8.3 Anforderungsdeﬁnition

307

Das Ziel der Schwachstellen-Analyse ist die Identiﬁzierung aller Schwachstellen, aus denen anschließend Verbesserungspotenziale abgeleitet werden. Bei der Entscheidung zwischen Abl¨ osung bzw. Nicht-Abl¨osung des alten WMS sollten neben den Verbesserungspotenzialen unter anderem auch folgende Aspekte ber¨ ucksichtigt werden: • • • •

wirtschaftliche Situation des Unternehmens strategische Ausrichtung des Unternehmens Prognosen (z. B. gesamtwirtschaftliche oder branchenspeziﬁsche) Machbarkeitsstudie und Risikoanalyse5

8.3.3 Entwicklung Soll-Konzept Wird die Entscheidung zur Abl¨ osung des alten WMS durch ein neues getroffen, folgt die Entwicklung eines Soll-Konzeptes. Dieses basiert gr¨oßtenteils auf den aus der Ist-Aufnahme gewonnenen Erkenntnissen. Die im Rahmen der Schwachstellen-Analyse aufgezeigten M¨ oglichkeiten werden aufgenommen und die Anforderung an das neue WMS unter Ber¨ ucksichtigung der Verbesserungspotenziale beschrieben. Unter Beachtung der bei der SchwachstellenAnalyse eingef¨ uhrten Klassiﬁzierung ergeben sich die folgenden beispielhaften Anforderungen: Gesch¨ aftsprozesse und Informationsﬂuss im Lager Alle Gesch¨aftsprozesse, die das Lager betreﬀen, sind eindeutig deﬁniert. Der Informationsﬂuss und die Verwendung von Dokumenten sind vollst¨andig beschrieben. Leistungsumfang des WMS Die Anforderungen an den Leistungsumfang (Funktionen und die dazugeh¨ origen Gesch¨ aftsprozesse und Abl¨aufe) des neuen WMS decken die tats¨ achlichen und geplanten Forderungen vollst¨andig ab. Schnittstellen zu unter- und u ¨bergeordneten Systemen Der gesamte Datenaustausch des WMS wird dargestellt, alle beteiligten Fremdsysteme, die verwendeten Protokolle sowie die zu u ¨bertragenden Daten werden aufgezeigt. Zudem ist eindeutig festgelegt, welches System welche Daten als Stammdaten h¨ alt. Struktur der relevanten Daten Alle ben¨ otigten Daten, Objekte und Nummernkreise sind vollst¨ andig deﬁniert (siehe Tabelle 2.13 S. 66 und Tabelle 8.2).

5

Die Risikoanalyse dient der m¨ oglichst fr¨ uhzeitigen Erkennung und Absch¨ atzung potenzieller interner und externer Projektrisiken.

308

8. Auswahl und Einf¨ uhrung von WMS

Tabelle 8.2. Sollkonzept: Beispielhafter Aufbau einer Lagerplatzdatei Nr.

Feld

Beschreibung

1.

Warehouse

identifiziert das Lager

2.

Area

identifiziert den Lagerort

3.

Aisle

identifiziert die Lagergasse

4.

Side

gibt die Seite innerhalb der Gasse an (vom Einlagerungspunkt aus gesehen): 0 – rechts, 1 – links

5.

X

X-Koordinate des Regal-Fachs beginnend bei 1, Start am Einlagertisch

6.

Y

Y-Koordinate des Regal-Fachs beginnend bei 1, Start von unten

7.

Z

Z-Koordinate des Regal-Fachs beginnend bei 1

8.

Quality

Die Güte (der ABC-Zone) gibt die euklidische Entfernung des Lagerplatzes zum Ein- bzw. Auslagerstich an; eine kleinere Güte entspricht einer höheren Zugriffsgeschwindigkeit

9.

MaxHeight

maximal nutzbare Höhe des Lagerplatzes in mm

10.

IDLocProp

berechnet das Lagerortskennzeichen des Platzes

11.

IDTSUTypeGroup

Gruppe von LHM-Typen (engl. Transport Support Unit, TSU), die auf diesem Platz untergebracht werden können

12.

IDTSUType

aktuell auf dem Platz befindlicher LHM-Typ (engl. TSU)

13.

Quantity

Anzahl LHM auf dem Platz: 0 – Platz ist leer, größer 0 – Platz ist mit dem in IDTSUType angegebenen Typ belegt

14.

ResQuantity

reserved quantity – Anzahl LHM, die für Abgang reserviert sind

15.

RepQuantity

replenished quantity – Anzahl LHM, die als Nachschub für diesen Platz unterwegs sind

16.

IDLock

Sperrkennzeichen

17.

InvTS

Zeitpunkt der letzten Inventur (engl. Time Stamp, TS)

18.

InvIDOperator

Mitarbeiter, der die letzte Inventur durchgeführt hat

19.

ZCrossingTS

ZeroCrossingTimeStamp – Nulldurchgangszeitpunkt

8.4 Erstellung der Ausschreibungsunterlagen

309

Abbildung 8.3. Beispielhafte Prozesskette des Soll-Zustands

8.4 Erstellung der Ausschreibungsunterlagen Die Projektphase Leistungsverzeichnis, Lastenheft und Ausschreibung ist gekennzeichnet durch die formale Aufschreibung des erarbeiteten Soll-Konzepts, wobei geltende Normen, Richtlinien und Gesetze sowie ﬁrmeninterne Vorschriften Ber¨ ucksichtigung ﬁnden. Das Ziel dieser Projektphase ist die vollst¨ andige Erstellung der Ausschreibungsunterlagen. 8.4.1 Deﬁnition Leistungsverzeichnis Im Leistungsverzeichnis werden die Leistungskennzahlen (Key Performance Indicators, KPI) aufgef¨ uhrt. Beispielhaft sind dies • • • •

Auftr¨ age, Positionen, Auslagerungen pro Zeitintervall (Tag/Woche/Monat) Positionen, Auslagerungen pro Artikel/Sortiment/Mandant Auftr¨ age, Volumen, Gewicht pro Position/Kunde/Versandart usw.

Um eine Unterdimensionierung des WMS zu vermeiden, sind bei der Bestimmung der KPIs neben den derzeitig gestellten Anforderungen auch langfristige Entwicklungen (z. B. Ausweitung des Artikelsortiments oder die Einf¨ uhrung einer leistungsbezogenen Entlohnung f¨ ur die Kommissionierer)

310

8. Auswahl und Einf¨ uhrung von WMS

zu ber¨ ucksichtigen. Die Leistungskennzahlen deﬁnieren die Anforderungen an das neue WMS und stellen einen wichtigen Bestandteil der Ausschreibungsunterlagen dar.

Abbildung 8.4. Beispielhaftes Inhaltsverzeichnis Lastenheft

8.4 Erstellung der Ausschreibungsunterlagen

311

8.4.2 Erstellung Lastenheft Ein weiterer wichtiger Bestandteil der Ausschreibungsunterlagen ist das Lastenheft: Das Lastenheft eines Projektes ist die Zusammenstellung der Anfor” derungen an das zu entwickelnde System, hier an das zu entwickelnde Programm/Programmsystem. Dies verlangt als Voraussetzung: • eine Untersuchung zur Machbarkeit und • eine eingehende Analyse der Risiken, die mit der Entwicklung verbunden sind oder sein k¨ onnten.“([42], S. L-1) Wesentliche Aspekte f¨ ur die Erstellung eines Lastenheftes f¨ ur ein WMS ([4], S. 63) sind nachfolgend aufgef¨ uhrt: Aufgabe Das Lastenheft fasst alle fachlichen Anforderungen, die das zu beschaﬀende WMS aus Sicht des Auftraggebers erf¨ ullen muss, pr¨azise zusammen. Adressaten Die u ¨ blichen Adressaten des Lastenheftes sind beim WMSAnbieter die Vertriebsmitarbeiter, der potenzielle Projektleiter sowie die Anwendungsspezialisten. Inhalt Auf einem ausreichend hohen Abstraktionsniveau wird die zu l¨osende Aufgabe, nicht die pr¨ azise Umsetzung, beschrieben (das WAS, nicht das WIE ). Form Eine eindeutige Nummerierung der einzelnen Anforderungen erleichtert z. B. sowohl beim Angebotsvergleich als auch bei der PﬂichtenheftErstellung eine sp¨ atere Referenzierung. Zeitpunkt Das Lastenheft ist das erste formale Dokument, das die wesentlichen Anforderungen an das WMS beschreibt. Umfang Die Konzentration auf die fundamentalen Anforderungen erm¨oglicht eine Beschr¨ ankung des Umfangs auf wenige Seiten. Die oben genannten Aspekte f¨ uhren zu folgendem beispielhaften Grobschema: A) Grundlegendes (kurze, nicht funktionale Beschreibung des Projektes): • Aufgabenstellung allgemeine gesch¨ aftsstrategische Umschreibung der Aufgabe (z. B. Abl¨ osung des vorhandenen WMS durch ein neues WMS) • Veranlassung Gr¨ unde und Notwendigkeiten, die zu der Aufgabe f¨ uhrten (z. B. unzureichende Funktionalit¨ at beim vorhandenen WMS) • Zielsetzung des Vorhabens generelle Beschreibung des Projektziels (z. B. funktionale Unterst¨ utzung aller T¨ atigkeiten im Lager durch ein neues WMS, wobei dieses System auch auf zuk¨ unftige Anforderungen vom Anwender parametrisierbar sein muss). Auch die geplanten Leistungskennzahlen werden uhrt. hier aufgef¨

312

8. Auswahl und Einf¨ uhrung von WMS

• Projektumfeld kurze Zusammenfassung des Umfelds (z. B. Hauptsitz mit Produktion und Zwischenlager der Firma in Stadt A, Distributionszentren in den Orten B und C) B) Funktionsumfang (Beschreibung aller Funktionen): • Abgrenzung zu ERP und MFC und sonstiger Software Positionierung des WMS innerhalb der Systemlandschaft (z. B. Kundenauftr¨ age kommen ausschließlich vom u ¨ bergeordneten ERP-System, die Gleichverteilung innerhalb der Gassen des Hochregals ist Aufgabe des Steuerungssystems Hochregal“) ” • Funktionen Aufz¨ ahlung und Beschreibung aller unverzichtbaren Funktionen und Leistungen (z. B. Chargenf¨ ahigkeit) • optionale Funktionen Aufz¨ ahlung und Beschreibung aller Funktionen und Leistungen, die f¨ ur den Betrieb des Lagers hilfreich w¨ aren, aber im Zweifelsfall (z. B. wegen steigender Kosten) nicht vorhanden sein m¨ ussen (z. B. OnlineSprachumschaltung, ohne sich abmelden und erneut am System anmelden zu m¨ ussen) • Sonderfunktionen Aufz¨ ahlung und Beschreibung aller Funktionen und Leistungen, die den gew¨ ohnlichen Betrieb eines Lagers nicht betreﬀen, aber f¨ ur die Administration des WMS erforderlich sind (z. B. Anpassungsf¨ahigkeit/Erweiterbarkeit: Der Benutzer kann ohne Unterst¨ utzung des WMS-Anbieters weitere Lager im WMS abbilden.) Neben der Darstellung der nicht gew¨ ohnlichen Funktionen z¨ahlt auch die Beschreibung der zu u ¨bernehmenden Daten aus dem vorhandenen WMS zu den Sonderfunktionen. Bei der Erstellung des Lastenheftes sollten die folgenden Normen und Richtlinien Beachtung ﬁnden: • VDI 2519 (Vorgehensweise bei der Erstellung von Lastenheften) • VDI/VDE 3694 (Lastenheft f¨ ur den Einsatz von Automatisierungssystemen) • VDI 3969 (Schnittstellen des Lagerverwaltungssystems zu u ¨bergeordneten Systemen) • DIN ISO 9126 (Software-Qualit¨ atsmerkmale) Zus¨ atzlich zu den oben genannten Normen und Richtlinien sollten bei der Beschreibung der Verf¨ ugbarkeit die nachstehenden Normen ber¨ ucksichtigt werden: • VDI 4004 Blatt 4 (Zuverl¨ assigkeitskenngr¨ oßen – Verf¨ ugbarkeitskenngr¨oßen) ur F¨order- und Lager• VDI 3649 (Anwendung der Verf¨ ugbarkeitsrechnung f¨ systeme)

8.4 Erstellung der Ausschreibungsunterlagen

313

• VDI 3581 Entwurf (Verf¨ ugbarkeit von Transport- und Lageranlagen sowie deren Teilsysteme und Elemente) Zusammenfassend gilt, dass das Lastenheft sinnvoll gegliedert und strukturiert sein sollte. Angebote sollen und m¨ ussen sich direkt auf das Lastenheft beziehen k¨ onnen. Beispielhaft ist das Inhaltsverzeichnis eines Lastenhefts zur WMS-Auswahl dargestellt (s. Abb. 8.4). Tabelle 8.3. Exemplarische Vorgabe f¨ ur Preisangaben Leistung

Kosten in EURO

Grundmodul

Hauptfunktion 1

Funktion 1

Funktion ...

Hauptfunktion n

Funktion m

Option 1

Funktion 1

Funktion 1

Funktion ...

XX.XXX,XX

Funktion m

Option n

Funktion ...

Funktion m

Funktion 1

XX.XXX,XX

Funktion ...

Funktion m

Hardware

Gerät 1

Bestandteil 1

Gerät n

Bestandteil ...

Bestandteil m

Bestandteil 1

XX.XXX,XX

Bestandteil ...

Bestandteil m

Schulung

Themengebiet 1

Themengebiet n

XX.XXX,XX

Wartungsvertrag n

XX.XXX,XX

Wartung

Wartungsvertrag 1

Leistung 1

Leistung ...

Leistung m

Leistung 1

Leistung ...

Leistung m

314

8. Auswahl und Einf¨ uhrung von WMS

8.4.3 Komplettierung der Ausschreibungsunterlagen Die Ausschreibungsunterlagen werden unter anderem durch die nachfolgenden Punkte komplettiert: • Allgemeine Einkaufsbedingungen • Geheimhaltungsvereinbarung • Aussagen u ogliche Vertragsstrafen/P¨ onale (auch: Recht auf Nachbes¨ber m¨ serung) • wesentliche Abnahmekriterien • Bereitstellung einer verbindlichen Formatvorlage f¨ ur die Gliederung des Angebots • Bereitstellung einer verbindlichen Formatvorlage f¨ ur die Preisangaben (s. Tabelle 8.3).

8.5 Auftragsvergabe Vor der Auftragsvergabe stehen die Anbietervorauswahl, die daraus resultierende Versendung der Ausschreibungsunterlagen an einen qualiﬁzierten Kreis von Anbietern, die Besuche der Anbieter beim Auftraggeber, der Angebotsvergleich und eine abschließende, Angebotspr¨asentation sowie die Besuche des Auftraggebers bei verschiedenen Referenzkunden der Anbieter. 8.5.1 Anbietervorauswahl Zur Vorbereitung der Anbieterauswahl und des Angebotsvergleichs ist es notwendig, die im Lastenheft beschriebenen Funktionen zu unterteilen: • Kriterien, die f¨ ur den reibungslosen Betriebsablauf im Lager unverzichtbar sind, z. B. Mandantenf¨ ahigkeit f¨ ur Logistikdienstleister, werden zu Ausschlusskriterien: Wird diese Funktion vom Produkt des WMS-Anbieters nicht erf¨ ullt, scheidet das Produkt beim Auswahlprozess sofort aus. • Kriterien, die den Betriebsablauf unterst¨ utzen, aber nicht unverzichtbar sind, werden zu so genannten optionalen Kriterien: F¨ ur den Betriebsablauf ist diese Funktion hilfreich, das Fehlen dieser Funktionalit¨at f¨ uhrt aber nicht automatisch zum Ausscheiden des WMS beim weiteren Auswahlprozess. Der Angebotsvergleich kann erheblich dadurch reduziert werden, dass nur Anbieter angeschrieben werden, die die Mindestanforderungen erf¨ ullen (die so genannte qualiﬁzierte Versendung der Ausschreibungsunterlagen). Eine beispielhafte Checkliste zur Hinterfragung dieser Mindestanforderung durch den Auftraggeber zeigt Abb. 8.5. Hier sei auf eine Initiative verwiesen, die mit Hilfe einer Internetdatenbank eine WMS-Anbieter-Vorauswahl unterst¨ utzt [50].

8.5 Auftragsvergabe

315

Für welche Lagertechniken soll der Anbieter bereits Projekte realisiert haben? Z.B. • AKL (Automatisches Kleinteilelager) • manuelles Behälter-/Kleinteilelager

Für welches spezielle Lagergut soll der Anbieter bereits Projekte realisiert haben? Z.B. • Stückgut • Coil • Langgut • Schüttgut Für welche Lagerarten sollen bereits Projekte realisiert worden sein? Z.B. • Kommissionierlager • Zolllager • Kühllager • Gefahrgutlager • Mehrlager: Hauptlager mit Regionallagern Wird eine für Speditionen geeignete Software benötigt?

Wird eine für den Bereich Paketdienst geeignete Software benötigt?

Wird eine für Logistikdienstleister geeignete Software benötigt?

Wird eine Chargenverwaltung benötigt?

Wird eine Seriennummernverwaltung benötigt?

Soll das System mandantenfähig sein?

Soll das System mehrlagerfähig sein?

Wird Unterstützung durch das WMS beim Dock-/ Yardmanagement benötigt?

...

Abbildung 8.5. Checkliste Mindestanforderungen

¨ Das Ergebnis der Anbietervorauswahl ist eine Ubersicht derjenigen Anbieter, die die gestellten Anforderungen erf¨ ullen. Ein qualiﬁziertes Versenden der Ausschreibungsunterlagen wird dadurch erm¨oglicht.

316

8. Auswahl und Einf¨ uhrung von WMS

Angebot der Ausschluss-Funktionen (Werden alle geforderten Ausschluss-Funktionen angeboten?) Angebot der Optionen (Inwieweit werden die Funktionen angeboten?) Standardisierungsgrad der angebotenen Software (Gehören die Ausschluss- Funktionen bzw. die Optionen zum Standard6 oder müssen sie individuell implementiert werden?)

Lizenzmodelle

Angebot Schulungsmaßnahmen (Welche Schulungsmaßnahmen werden angeboten?) Angebot Wartung und Pflege

detaillierte Beschreibung des Aufwands für die Individualprogrammierung Anforderungen des WMS-Anbieter an den Auftraggeber (z. B.: Wie viele Mitarbeiter müssen für das Projekt freigestellt werden, welche Vorbereitungsmaßnahmen werden erwartet?) Höhe der Tages- bzw. Stundensätze und der Reisekosten; Unterscheidung nach Qualifikation der Mitarbeiter und Tätigkeit Umfang des Angebots (Wird mehr angeboten als gefordert? Warum wird mehr angeboten? Ist dieses ”Mehr“ auch aus Auftraggebersicht notwendig?) Durchsicht der AGB des Anbieters

usw.

Abbildung 8.6. Checkliste Angebotsvergleich

8.5.2 Standort-/Lagerbesichtigung F¨ ur den WMS-Anbieter ist es f¨ ur die korrekte Angebotserstellung sehr hilfreich, mindestens einen Standort/ein Lager des Auftraggebers vorher zu besichtigen. Hier kann er sich einen Eindruck verschaﬀen und ggf. Fragen zum

8.5 Auftragsvergabe

317

Angebot stellen. F¨ ur beide Seiten bietet die Besichtigung die Chance, sich pers¨ onlich kennenzulernen. Ziele der Standort-/Lagerbesichtigung sind die Beantwortung von Fragen zu den Ausschreibungsunterlagen, ein Gesp¨ ur f¨ ur das Lager des Auftraggebers zu bekommen sowie ein erstes Kennenlernen der m¨oglichen Vertragspartner. 8.5.3 Angebotsvergleich W¨ ahrend des folgenden Angebotvergleichs m¨ ussen die eingehenden Angebote in einem ersten Schritt einander gegen¨ ubergestellt werden. Ein solches Vorgehen ist notwendig, da die WMS-Anbieter nicht immer die Umsetzung der im Lastenheft beschriebenen Anforderungen anbieten, sondern zun¨achst h¨auﬁg den Standardumfang des jeweiligen WMS. Unterst¨ utzung bei dem Vergleich der unterschiedlichen Angebote bietet die in Abb. 8.6 aufgezeigte Checkliste. ¨ Die Uberpr¨ ufung wird systematisch f¨ ur jedes Angebot aufbereitet. In der Regel treten dabei Fragen auf, die gekl¨ art werden m¨ ussen, wobei ggf. eine Erweiterung und/oder Detaillierung des vorliegenden Angebots angefordert werden muss. Den beispielhaften schematischen Aufbau eines Angebotvergleichs zeigen Tabelle 8.4 und Tabelle 8.6.

318

8. Auswahl und Einf¨ uhrung von WMS

Anbieter n

Anbieter B

Anbieter A

Funktion/ Leistung

Ausschlusskriterium

Tabelle 8.4. Bewertung Angebote

Datendarstellung und Mengengerüst

...

warenbezogene Stammdaten

...

Artikelstammdaten

+

+

...

Verpackungseinheiten je Artikel

+

(+) 1

...

Warenarten-Tabelle

+

(-) 2

...

+

...

(-) 3

...

+

...

(+) 9

...

+

...

(+) 28

+

...

Buchung WMS

(+) 29

(+) 10

...

Zugang aus der Produktion

(+) 31

+

...

+

...

Stammdaten Lager- und Transportsysteme Stammdaten Lager

KO

Stammdaten Gabelstapler Ablauf Warenzugang Abwicklung Warenzugang Warenanlieferung

+

Einlagerplatzbestimmung Einlagerungstransport Warenzugangsbuchungen

Ablauf Kundenauftragsabwicklung Kommissionierung Auftragsfreigabe zur Kommissionierung manuell

+

automatisch ohne Restriktionen

(+) 32

automatisch mit Restriktionen

(+) 32

Bedienerführung Kommissionierung

(-) 34

+

...

Generierung Nachschubaufträge

(-) 34

+

...

+

...

Warenabgang

8.5 Auftragsvergabe

Informations- und Berichtswesen

Anbieter n

Anbieter B

Anbieter A

Funktion/ Leistung

Ausschlusskriterium

Tabelle 8.5. Bewertung Angebote (Forts.)

+

+

...

Datenübernahme ALT-WMS

KO

+

+

...

zweistufige Kommissionierung

KO

-

-

...

Prioritätenvergabe

KO

+

+

...

Kompatibilität RF

(+) 2, 6

+

...

Wartungsvertrag

-

-

Schulung

+

+

...

Leistungsanforderung

+

-

...

Verfügbarkeitsanforderung

-

+

Projektabwicklung

-

+

...

... ...

KO

Ausschlusskriterium; ein leeres Feld kennzeichnet ein optionales Kriterium.

+/-

Anforderung wird im Angebot genannt und erfüllt/nicht erfüllt.

-

Anforderung wird im Angebot genannt und nicht erfüllt. Auf die Anforderung wird im Angebot nicht eingegangen.

32

Topic in der Bemerkungsanlage Tabelle 7.8

Tabelle 8.6. Bemerkungen zu den Angeboten Topic

Angebot Seite

Lastenheft Kapitel

Anmerkung Firma A

2

5

2.3

XP-Rechner und Konsolen-Software als zusätzliche Kosten aufgeführt

6

8

2.5

Warum wird der Austausch älterer Geräte empfohlen? Gibt es Probleme beim Einsatz älterer Geräte oder ist dies eine generelle Meinung?

28

18

2.3.4

„Zusammengefasste Transporte“ ist Ausschlusskriterium; aufgeführt als Add-On „Zusammengefasste Transporte“; genauer Preis fehlt.

34

19

2.4.3.2-3

„Bedienerführung Kommissionierung“ und „Generierung Nachschubaufträge“: Beides muss angepasst werden. Im Angebotspreis bereits enthalten?

...

319

320

8. Auswahl und Einf¨ uhrung von WMS

8.5.4 Angebotspr¨ asentation In der Regel zeigt sich, dass eine einfache numerische Bewertung des Angebots nicht unmittelbar m¨ oglich und bei der Entscheidung f¨ ur ein WMS nicht ausreichend ist. Ein Treﬀen zwischen Auftraggeber und Auftragnehmer liefert zus¨ atzliche, f¨ ur die Entscheidung hilfreiche Informationen. Einen passenden Rahmen hierf¨ ur bietet beispielsweise eine Pr¨asentation des Angebots durch den WMS-Anbieter beim Auftraggeber. Im Rahmen der Angebotspr¨ asentation wird dem WMS-Anbieter die M¨oglichkeit gegeben, sein Angebot dem Auftraggeber pers¨onlich vorzustellen. Dabei kann er sowohl die St¨ arken seines Produktes als auch die seines Unternehmens explizit herausarbeiten. Zudem werden die Vorgehensweise/Methodik und der Projektplan bei der Einf¨ uhrung eines WMS erl¨autert. Der Auftraggeber hat die M¨ oglichkeit, oﬀene Punkte hinsichtlich des Angebots fachlich zu kl¨ aren. Die Aussagen und Erkenntnisse der Angebotspr¨asentation werden protokolliert. Zus¨ atzlich zum Projektleiter sollten auf Seiten des Auftraggebers die verantwortlichen Entscheidungstr¨ ager und die f¨ ur den Lagerbetrieb operativ verantwortlichen Mitarbeiter an einer solchen Pr¨ asentation teilnehmen. Auf Seiten des WMS-Anbieters sollten zumindest die verantwortlichen Vertriebsmitarbeiter sowie der potenzielle Projektleiter teilnehmen. Ein standardisiertes Vorgehen erleichtert den Vergleich und die Bewertung der Pr¨ asentationen aller WMS-Anbieter (vgl. Tabelle 8.6). Das Ziel der Angebotspr¨ asentation ist somit die Kl¨arung aller oﬀenen Punkte sowohl von Seiten des Auftraggebers als auch von Seiten des WMSAnbieters. Das vorliegende Angebot ist vollst¨ andig, eindeutig und verstanden. 8.5.5 Referenzbesuche Zur realistischen Einsch¨ atzung des Leistungsumfangs der angebotenen WMS ist es f¨ ur den Auftraggeber sinnvoll, ¨ ahnlich gelagerte Referenzanlagen der WMS-Anbieter zu besichtigen. Hier bietet sich die M¨oglichkeit, Erfahrungen (Wie verlief die WMS-Einf¨ uhrung? Wie ist die After-Sales-Unterst¨ utzung?) mit Alt-Kunden des Anbieter auszutauschen. Ziel der Referenzbesuche ist es auch, einen Eindruck vom WMS im laufenden Betrieb zu bekommen. 8.5.6 Anbieterauswahl Die Erkenntnisse, die im Rahmen der Lager-/Standortbesichtigung, der Angebotspr¨ asentation und der Referenzbesuche gewonnen wurden, ﬂießen in die Bewertung des Angebots ein. Aus der abschließenden Bewertung der vorliegenden Angebote entsteht eine Rangfolge. Die kaufm¨annischen Verhandlungen mit den in Frage kommenden Anbietern schließen die Anbieterauswahl ab.

8.6 Umsetzung

321

Tabelle 8.7. Bewertungsbogen Nr.

Funktionsbereiche

1

Einrichtung Stammdaten

2

Einlagerungsstrategien

3

Nachschub Kommissionierung

Status Angebot

Kommentar

Status Präsentation

Wert

...

8.6 Umsetzung Die Projektphase Umsetzung wird von der Pﬂichtenhefterstellung und der anschließenden Realisierung dominiert. Ausdr¨ ucklich zu erw¨ahnen sind in dieser Phase die begleitenden Controlling- und Qualit¨atssicherungsmaßnahmen (vgl. Kapitel 8.1). Die Projektphase Umsetzung startet analog zum Kick-oﬀ-Meeting am Anfang des WMS-Projekt mit einem Kick-oﬀ-Meeting WMS-Einf¨ uhrung. In diesem Rahmen wird ein Projektteam mit den relevanten Mitgliedern des Auftraggebers und des Auftragnehmers zusammengestellt. In diesem Team werden die Arbeitsschritte, Untersuchungsinhalte, Datenbedarfe und Terminpl¨ ane sowie die erforderlichen Formalien (z. B. Protokollf¨ uhrung, Projektdokumentation, Datenaustausch) vereinbart. 8.6.1 Pﬂichtenhefterstellung Das Pﬂichtenheft beschreibt, WIE die Vorgaben des Lastenhefts umgesetzt werden. Es bildet die Grundlage aller T¨ atigkeiten w¨ahrend der Realisierung und sollte integraler Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer sein. Das Pﬂichtenheft beschreibt im Wesentlichen, wie die Aufgaben, die ” im Lastenheft speziﬁziert worden sind, gel¨ost werden sollen. Damit enth¨ alt es die Leistungsbeschreibung des zu entwickelnden Systems und legt bei dieser Gelegenheit dar, wie und zumeist auch mit welchen Mitteln die Aufgabenstellung gel¨ ost werden soll. Vor diesem Hintergrund liefert das Pﬂichtenheft die Grundlage f¨ ur die Abnahme. (...) Im Zusammenspiel zwischen Auftraggeber und Auftragnehmer ist aus dem Lastenheft ein Pﬂichtenheft zu erarbeiten, das Grundlage des Vertrags ... ist.“([42], S. L-1) Viele Begriﬀe der Intralogistik sind branchen- oder ﬁrmenspeziﬁsch. Zudem unterliegen sie einem steten, durch die Technologie getriebenen Wandel.

322

8. Auswahl und Einf¨ uhrung von WMS

Um Missverst¨ andnisse zu vermeiden, sollte ein gemeinsames Glossar angelegt werden. Zus¨ atzlich ist der Verweis auf entsprechende Ver¨oﬀentlichungen hilfreich [58]. Unterschiedliche Deutungen der im Pﬂichtenheft beschriebenen Leistungen werden minimiert, eine exaktere Umsetzung wird erm¨oglicht. Das Pﬂichtenheft stellt eine Verfeinerung des Lastenheftes dar (...). ” Auf der Grundlage des Pﬂichtenheftes und des Glossars wird ein formales Produkt-Modell erstellt, das die Anforderungen vollst¨andig, konsistent und eindeutig beschreiben muss.“([4], S. 100) Die Aspekte bei der Erstellung des Pﬂichtenhefts gleichen im Allgemeinen denen bei der Erstellung des Lastenhefts (vgl. Abschn. 8.4.2). Zus¨atzlich wird die Umsetzung der im Lastenheft beschriebenen Anforderungen g¨anzlich, widerspruchsfrei und unmissverst¨ andlich beschrieben. Treten im Laufe der Realisierung nicht vorhersehbare neue Erkenntnisse auf, sollten diese mit Einverst¨ andnis von Auftraggeber und Auftragnehmer nachtr¨aglich zum Bestandteil des Pﬂichtenhefts gemacht werden. Das Studium der nachstehenden Normen und Richtlinien erleichtert die Erstellung des Pﬂichtenhefts. Gegebenenfalls kann deren Beachtung zu einem Bestandteil des Vertrags gemacht werden: • VDI 2519 (Vorgehensweise bei der Erstellung von Pﬂichtenheften) • VDI/VDE 3694 (Pﬂichtenheft f¨ ur den Einsatz von Automatisierungssystemen) • ANSI/IEEE 830-1998 (SRS Software Requirements Speciﬁcations) Das folgende, beispielhafte Grobschema eines Pﬂichtenhefts ber¨ ucksichtigt die wesentlichen, oben beschriebenen Anforderungen: • Grundlegendes (kurze, nicht funktionale Beschreibung des Projektes) – Aufgabenstellung allgemeine (gesch¨ aftspolitische) Umschreibung der Aufgabe, z. B. Abl¨osung des vorhandenen WMS durch ein neues WMS – Veranlassung Gr¨ unde und Notwendigkeiten, die zu der Aufgabe f¨ uhrten; z. B. neue T¨ atigkeiten im Lager k¨ onnen durch das Alt-System nicht mehr abgedeckt werden. – Zielsetzung des Vorhabens generelle Beschreibung des Projektziels, z. B. funktionale Unterst¨ utzung aller T¨ atigkeiten im Lager durch ein neues WMS, wobei dieses System auch auf zuk¨ unftige Ereignisse vom Anwender parametrisierbar sein muss. Auch die zu realisierenden Leistungskennzahlen sollten hier aufgef¨ uhrt werden. – Projektumfeld kurze Zusammenfassung des Umfelds, z. B. Hauptsitz mit Produktion und Zwischenlager der Firma in Stadt A, Distributionszentren in den Orten B und C

8.6 Umsetzung

•

• • •

323

– Zeitrahmen Nennung aller Meilensteine mit zeitlichen Rahmendaten Funktionsumfang (Beschreibung aller Funktionen) – Abgrenzung zu ERP und MFC und sonstiger Software: Positionierung des WMS innerhalb der Systemlandschaft – Funktionen: Aufz¨ ahlung und Beschreibung aller Funktionen und Leistungen – Schnittstellen: Beschreibung der ben¨ otigten Schnittstellen und Protokolle. – Daten¨ ubernahme: Art und Weise der Daten¨ ubernahme mit Angabe der zu u autert. ¨ bernehmenden Daten werden erl¨ Schulung (Zeitpunkt, Ort und Umfang sowie Zielgruppe der einzelnen Schulungsmaßnahmen werden benannt.) Inbetriebnahme (Zeitpunkt und Ablauf der Inbetriebnahme werden beschrieben.) Abnahme (Form und Umfang der Abnahme mit pr¨azise deﬁnierten Leistungskennzahlen und einer Liste der Pﬂichten von Auftragnehmer, aber auch Auftraggeber werden aufgef¨ uhrt.)

Das Ziel der Projektphase Pﬂichtenhefterstellung ist die exakte und zweifelsfreie Niederlegung aller Pﬂichten (Leistungen, T¨atigkeiten und Funktionen) inklusive ihrer Terminierung, die zur Erf¨ ullung des Projektziels notwendig sind. Das Pﬂichtenheft wird durch den Auftraggeber genehmigt. Es ist m¨oglich, das gesamte Pﬂichtenheft erst nach Fertigstellung durch den Auftraggeber abnehmen zu lassen. Eﬃzienter und eﬀektiver ist es hingegen, jedes einzelne Kapitel sofort nach Fertigstellung abnehmen zu lassen. Als Bestandteil des Vertrages ist das Pﬂichtenheft f¨ ur beide Seiten verbindlich. 8.6.2 Realisierung Der sich anschließende Projektschritt ist die Realisierung. Bei der Realisierung handelt es sich um die Umsetzung der im Lasten- und Pﬂichtenheft beschriebenen Anforderungen zur Fertigstellung des Produktes. Die Umsetzung erfolgt durch • Implementierung (Installation der Software auf die bereitgestellte Hardware), • Customizing (Anpassung an die gegebenen Schnittstellen und Aktivierung der ben¨ otigten Programmmodule), • Parametrisierung (Anpassung der Software mittels Parameter und Schalter an die Kundenvorgaben), • Individualprogrammierung (Programmierung von individuellen Funktionen). ¨ Alle sich w¨ ahrend der Realisierung ergebenden Anderungen zum Lastenbzw. Pﬂichtenheft sind zu dokumentieren und zwischen Auftragnehmer und

324

8. Auswahl und Einf¨ uhrung von WMS

¨ Auftraggeber zu kommunizieren. M¨ ogliche Gr¨ unde f¨ ur Anderungen k¨onnen neue Erkenntnisse (beispielsweise hat es sich als eﬃzienter erwiesen, den geplanten Ablauf umzugestalten), fehlende Punkte im Lasten- und Pﬂichtenheft sowie neue Anforderung (z. B. werden weitere Formulare und zus¨atzliche statistische Informationsabfragen ben¨ otigt) sein. Dokumentiert werden sollten unter anderem folgende Aspekte: • Welche Leistung/Funktion f¨ allt weg/kommt neu dazu/¨andert sich? ¨ • Welche kostenwirksamen Anderungen sind damit verbunden? • Welche zeitlichen Auswirkungen (Terminierung der Meilensteine des Projektes) ergeben sich hieraus? ¨ • Welche Priorit¨ at hat die Anderung? Muss sie vor der Inbetriebnahme er¨ folgt sein? Wenn die Anderung sp¨ ater erfolgen kann, bis wann muss sie sp¨ atestens erfolgen? ¨ Durch die Dokumentation der Anderungen werden m¨ogliche Unstimmigkeiten w¨ ahrend der Abnahme vermieden, da die zwangsl¨auﬁgen Unterschiede zwischen den im Lasten- und Pﬂichtenheft beschriebenen Funktionen und den realisierten Funktionen aufgezeigt und somit nachvollziehbar werden. Das Ziel der Projektphase Realisierung ist die Umsetzung der im Pﬂichtenheft beschriebenen Funktionalit¨ at innerhalb des gesetzten Zeitrahmens, mit den geplanten Ressourcen, in der gew¨ unschten Qualit¨at.

8.7 Inbetriebnahme Die Projektphase Inbetriebnahme unterteilt sich in eine Laborphase, den ei¨ gentlichen Ubergang vom alten zum neuen WMS und die parallel stattﬁndenden Schulungsmaßnahmen. Mit erfolgreichem Abschluss der Inbetriebnahme erfolgt die Freigabe des neuen WMS f¨ ur den Produktivbetrieb. 8.7.1 Laborphase Vor der Laborphase m¨ ussen die Alt-Datenbest¨ande (z. B. Artikel-Stammdaten, Lagerbewegungsprotokoll) u ¨bernommen werden. Hierbei kann es erforderlich werden, z. B. spezielle Import-Programme zu entwickeln. Generell gilt: Je ¨ gr¨ oßer der Umfang der Datenbest¨ ande ist, desto eher sollte die Ubernahme beginnen (s. [4], S. 1088). W¨ ahrend der Laborphase wird das neue WMS unter Laborbedingungen, aber mit realen Daten getestet: Die Auftr¨ age, die das WMS erteilt, werden beispielsweise nicht tats¨ achlich vom Kommissionierer ausgef¨ uhrt, sondern die Bearbeitung wird datentechnisch simuliert (z. B. wird die kommissionierte Menge durch ein Testprogramm direkt in die Datenbank geschrieben). Die Daten, die verwendet werden, k¨ onnen hingegen tagesaktuell geplant oder historisch sein.

8.7 Inbetriebnahme

325

¨ Die Uberpr¨ ufung auf Korrektheit erfolgt bei tagesaktuellen Daten gegen das Alt-System, bei historischen Daten gegen die Alt-Daten des Alt-Systems. Um ein WMS bereits unter Laborbedingungen realit¨atsnah zu testen, werden Simulationen eingesetzt. Dies k¨ onnen spezielle Programme sein, die z. B. die Auftragslast f¨ ur ein Kommissioniersystem an einer Datenschnittstelle zur Verf¨ ugung stellen. Um das Zeitverhalten des Materialﬂusssystems nachzubilden, werden Simulationsprogramme verwendet, die eine Leistungsbestimmung und einen Test der systemspeziﬁschen Heuristiken bei vorgegebener Auftragslast erm¨ oglichen. Derartigen Materialﬂusssimulatoren“ werden bei ”¨ gr¨oßeren Projekten zur Planung und Uberpr¨ ufung des physischen Materialﬂusses h¨ auﬁg verwendet. Zunehmend werden sie auch – u ¨ber eine Middleware mit dem WMS verbunden – zum Test von WMS unter Realzeitbedingungen genutzt. ¨ 8.7.2 Ubergang vom alten zum neuen WMS Das Umschalten vom alten zum neuen WMS kann auf die folgenden zwei Arten geschehen: Parallelbetrieb Beim Parallelbetrieb oder Parallellauf [4] laufen beide Systeme gleichzeitig, wobei zun¨ achst nur Anweisungen des abzul¨osenden WMS ausgef¨ uhrt werden. Ist festzustellen, dass die Ergebnisse sowohl im alten als auch im neuen WMS identisch sind, wird das neue WMS federf¨ uhrend. Nach einer festzulegenden Zeit ohne St¨orungen kann das alte WMS abgeschaltet werden. Der Vorteil dieser Vorgehensweise liegt in der erh¨ ohten Sicherheit, die sich daraus ergibt, dass beim Auftreten von Fehlern sofort auf das alte WMS zur¨ uckgegriﬀen werden kann. Einen Nachteil stellen die hohen Kosten f¨ ur die Betreuung von zwei Systemen sowie die allgemeinen Schwierigkeiten, die durch den Parallelbetrieb entstehen, dar. Direkte Umstellung Bei der direkten Umstellung wird unmittelbar von dem alten auf das neue WMS gewechselt. Das alte System wird abgeschaltet, das neue nimmt den Betrieb sofort auf. Gew¨ohnlich wird die direkte Umstellung dann gew¨ ahlt, wenn diese aus Gr¨ unden der gesamtbetrieblichen Situation ausschließlich innerhalb eines fest deﬁnierten Zeitraums erfolgen kann (beispielsweise w¨ ahrend der Betriebsferien oder außerhalb des Saisongesch¨ afts). Der Vorteil der direkten Umstellung sind die geringeren Kosten. Dem gegen¨ uber steht das Risiko, dass die Umstellung nicht im geplanten Zeitraum vollzogen werden kann. Alle w¨ ahrend der Inbetriebnahme auftretenden St¨orungen sind zu protokollieren und anschließend zu beheben. Sobald das alte WMS vollst¨ andig abgeschaltet ist und das neue WMS alle Funktionen u ¨ bernommen hat, beginnt der Produktivbetrieb des neuen WMS.

326

8. Auswahl und Einf¨ uhrung von WMS

8.7.3 Schulungsmaßnahmen Parallel zur Inbetriebnahme erfolgt die Schulung der Benutzer am System. Hierbei wird unterschieden zwischen der • Schulung aller potenziellen Benutzer des WMS durch den Auftragnehmer und • der Schulung der so genannten Trainer, die dann ihrerseits ihre Kollegen schulen (Train the Trainer). Wichtig ist eine fr¨ uhzeitige und ausreichende Schulung, die eine Freistellung der teilnehmenden Mitarbeiter voraussetzt. Eine Schulung, die beispielsweise nach Feierabend oder am Wochenende durchgef¨ uhrt wird, kann bereits im Vorfeld die Bereitschaft zur Akzeptanz des neuen Systems schm¨alern. Am Ende der Projektphase Inbetriebnahme steht die Verwaltung und Steuerung des Lagers durch geschulte Mitarbeiter mit Hilfe des neuen WMS. Dabei werden die im Lasten- und Pﬂichtenheft beschriebenen Funktionalit¨ aten ber¨ ucksichtigt und alle w¨ ahrend der Inbetriebnahme aufgetretenen St¨ orungen beseitigt.

8.8 Abnahme W¨ ahrend der Projektphase Abnahme erfolgen die Kontrolle der im Lastenund Pﬂichtenheft beschriebenen Funktionalit¨ at und Antwortzeiten, die Simu¨ lation von St¨ orf¨ allen sowie das Uberpr¨ ufen von Notfallstrategien. Die Abnahme lehnt sich an die VDI-Richtlinien 3977E und 3979 an. Ziel der Abnahme ist das Abnahmeprotokoll. Abnahme Juristisch deﬁnierter Vorgang, bei dem der Auftraggeber ” die Annahme des Produkts erkl¨ art. Das abgenommene Produkt geht in das Eigentum des Auftraggebers u ¨ ber.“([4], S. 1098) 8.8.1 Leistungstest Der Leistungstest, dessen wesentliche Bestandteile der Funktionstest und die Verf¨ ugbarkeits¨ uberpr¨ ufung sind, umfasst einen (meist mehrt¨agigen) zusammenh¨ angenden Betrieb unter Realbedingungen und Volllast. Eine Unterbrechung des Leistungsbetriebs im Zusammenhang mit St¨orungen bedingt eine Wiederholung des Tests. Im Rahmen der funktionalen Leistungstests wird zun¨achst das Vorhandensein aller im Pﬂichtenheft beschriebenen Funktionen u uft. Anschlie¨ berpr¨ ßend erfolgt die Einzelpr¨ ufung der ordnungsgem¨aßen Arbeitsweise jeder

8.8 Abnahme

327

Funktion. Insbesondere sollte hier auf die vom Standard abweichenden Funktionen6 geachtet werden: • Ist die Funktion vorhanden? • Entspricht die Funktion den Anforderungen? Neben den Funktionen ist das Zeitverhalten des WMS nachzuweisen. Beispiele hierf¨ ur sind die Dauer des Maskenaufbaus am Bildschirm, die Dauer eines Datenbankzugriﬀs (z. B. Anzeige der Stammdaten eines Artikels) und der Zeitraum f¨ ur eine Datenbankabfrage (z. B. oﬀene Kommissionierauftr¨age) sowie die Bearbeitungsdauer f¨ ur einen Report (z. B. Artikel pro Mandant im Monat). Zus¨ atzlich sind die Antwortzeiten an den externen/mobilen Terminals (z. B. Stapler-Terminals) abzunehmen. Zu beachten ist hierbei die Richtlinie VDI 3649. ¨ 8.8.2 Simulation von St¨ orf¨ allen / Uberpr¨ ufung von Notfallstrategien Bei der Simulation von St¨ orf¨ allen werden Ausnahmesituationen nachgebildet, die im Pﬂichtenheft beschrieben sind: • Systemverhalten bei Unterbrechungen der Kommunikation mit dem HostSystem • Auswirkungen bei Stromausfall • Strategie¨ uberpr¨ ufung (Welche Strategie greift, wenn ausgelagert werden soll, der Lagerplatz aber leer ist? Wie reagiert das System bei einem Einlagerungsversuch in einen falschen Lagerbereich, z. B. K¨ uhlgut in den Gefahrgut-Bereich?) • usw. Wichtig bei der Simulation von St¨ orf¨ allen ist der Nachweis von Notfallstrategien, die den Gesch¨ aftsbetrieb soweit wie m¨oglich aufrechterhalten. Eine Datensynchronisation nach Behebung der St¨ orung ist zwingend erforderlich: • Auslagerungen/Einlagerungen, die nur auf Papier festgehalten wurden, m¨ ussen in das System eingepﬂegt werden k¨onnen. • HOST- und WMS-Datenbestand m¨ ussen abgeglichen werden. • Nicht protokollierte Lagerbewegungen m¨ ussen erfasst werden. • usw. Alle im Lasten- bzw. Pﬂichtenheft genannten Kriterien, Leistungen und ¨ Verf¨ ugbarkeiten, die f¨ ur die Abnahme relevant sind, werden im Ubergabeprotokoll aufgef¨ uhrt. 6

Vom Standard abweichende Funktionen sind alle Funktionen, die individuell f¨ ur das Projekt programmiert und nicht u ¨ ber Parameter oder Customizing an das Projekt angepasst wurden.

328

8. Auswahl und Einf¨ uhrung von WMS

8.8.3 Verf¨ ugbarkeit Die technische Verf¨ ugbarkeit beschreibt die Wahrscheinlichkeit, ein Element oder ein System zu einem vorgegebenen Zeitpunkt in einem funktionsf¨ahigen Zustand anzutreﬀen ([73], S. 2),([13], S. 3).Die Verf¨ ugbarkeit betrachtet sowohl das Ausfall- als auch das Reparaturverhalten eines Systems. Der Schwerpunkt existierender Richtlinien aus dem deutschsprachigen Raum liegt im Bereich der Verf¨ ugbarkeitstests und -nachweise f¨ ur bereits realisierte Materialﬂusssysteme ([13]), ([14]), ([67]), ([73]), ([58]). Im Allgemeinen wird die Verf¨ ugbarkeit innerhalb der Intralogistik als prozentualer, einheitsloser Kennwert angegeben, der sich wie folgt berechnet: Techn. Verf¨ ugbarkeit =

M T BF 100[%] M DT + M T BF

MDT = Mean Down Time MTBF = Mean Time Between Failure W¨ ahrend des Leistungstests wird versucht, auch das langfristige Ausfallverhalten des Gesamtsystems und seiner Komponenten anhand von Verf¨ ugbarkeitskennwerten zu bewerten. Dies ist aufgrund der Kurzfristigkeit eines solchen Tests nur sehr bedingt m¨ oglich. Dennoch wird nicht selten ein erheblicher Teil der Abnahme auf einen einzelnen Wert - die Gesamtverf¨ ugbarkeit des Systems - fokussiert. Typische, vertraglich vereinbarte Werte liegen im Bereich oberhalb von 98 %. Dies ergibt wiederum eine notwendige Verf¨ ugbarkeit des gesamten Leit- und Steuerungssystems, inklusive WMS, von u ahren eines Leistungs- und Verf¨ ugbarkeitstests ¨ ber 99 %. Dies ist w¨ weder seri¨ os zuzusagen, noch sinnvoll zu messen. Stattdessen empﬁehlt sich eine l¨ angerfristige Vereinbarung im Rahmen eines Wartungs- und Instandhaltungsvertrages. Hierbei ist wiederum zu beachten, dass auch Warehouse Managmentsysteme einer vorbeugenden Instandhaltung und Wartung (z. B. Pﬂege der Datenbank) bed¨ urfen, um deren Leistungsf¨ahigkeit zu erhalten. 8.8.4 Formale Abnahme W¨ ahrend der Abnahme werden die einzelnen Positionen nacheinander abgenommen und vom Auftraggeber und Auftragnehmer unterzeichnet. Jede Erf¨ ullung, jeder Fehler bzw. jede Abweichung wird protokolliert. Bei Fehlern bzw. Abweichungen wird diskutiert, um welche Fehlerklasse es sich handelt, wobei die folgenden vier Fehlerklassen unterschieden werden: Klasse 1 Das Lager kann aufgrund des Fehlers bzw. der funktionalen Abweichung vom Pﬂichtenheft nicht betrieben werden (z. B. die Sicherheitslichtschranken oder die Ansteuerung der Regalbedienger¨ate funktionieren nicht).

8.8 Abnahme

329

Klasse 2 F¨ ur einen Fehler bzw. eine Abweichung existiert nur ein aufw¨andiges alternatives Vorgehen (z. B. die Scan-Funktion am Wareneingang funktioniert nicht, jeder Artikel muss daher manuell erfasst werden). Klasse 3 F¨ ur einen Fehler bzw. eine Abweichung besteht ein akzeptables alternatives Vorgehen (z. B. bei der t¨ aglich zweimal durchzuf¨ uhrenden, automatischen Auftragsannahme vom Host werden die Daten gelegentlich nicht vom WMS erfasst, der Benutzer muss daher die Auftragsannahme pr¨ ufen und gegebenenfalls neu veranlassen). Klasse 4 Ein Fehler bzw. eine Abweichung stellt keine Einschr¨ankung hinsichtlich der Nutzung des Systems dar (z. B. das Druckformat f¨ ur den Begleitschein im Warenausgang stimmt nicht exakt mit der Speziﬁkation u ¨ berein). Die Auswirkungen f¨ ur die Abnahme und die Entscheidung u ¨ ber die Produktivsetzung des WMS sind wie folgt: Klasse 1 Keine Abnahme, keine Produktivsetzung. Klasse 2 Kl¨ arung, wer eventuelle Mehrkosten des Auftraggebers tr¨agt (wenn bspw. bis zur Behebung des Fehlers zus¨atzliches Personal eingestellt werden muss). Die Entscheidung u ¨ber eine Teilabnahme mit Auflagen und die Produktivsetzung des WMS kann nur fallweise getroﬀen werden. Klasse 3 Eine Abnahme kann mit Auﬂagen erteilt werden, die Produktivsetzung kann erfolgen. Die Umsetzung der oﬀenen Punkte muss mit h¨ ochster Priorit¨ at erfolgen. Klasse 4 Eine Abnahme kann mit Auﬂagen erteilt werden, die Produktivsetzung kann erfolgen. Die zeitliche Umsetzung der oﬀenen Punkte muss zwischen Auftraggeber und Auftragnehmer terminiert werden. Unwesentliche Abweichungen sollten kein Hinderungsgrund f¨ ur die Einf¨ uhrung des Systems sein. Es muss jedoch festgelegt werden, ob und bis wann die Abweichungen zu korrigieren sind. Falls sich die Anzahl der Klasse-3-bzw. Klasse-4-Fehler h¨ auft, sollte gepr¨ uft werden, ob die Abnahme erteilt werden kann. Die Klassen kennzeichnen gleichzeitig die Priorit¨at, mit der der Fehler behoben werden muss. Die endg¨ ultige oﬃzielle Abnahme des Gesamtgewerks gem¨aß § 12 VOB Teil B und VDMA erfolgt nach einem einwandfreien, unbeanstandeten Leistungstest, der sp¨ atestens drei Monate nach Inbetriebnahme durchgef¨ uhrt ¨ werden muss. Vor der Abnahme sind die im Ubergabeprotokoll bezeichneangel zu beseitigen. Die Abnahme ist vom Auftragnehmer schriftlich ten M¨ zu beantragen. Die Abnahme erfolgt ausschließlich durch eine schriftliche Bescheinigung des Auftraggebers. Sie kann weder durch eine fr¨ uhere Benutzung, Inbetriebnahme oder beh¨ ordliche Abnahme noch durch die Mitteilung des Auftragnehmers u ¨ ber die Fertigstellung ersetzt werden.

330

8. Auswahl und Einf¨ uhrung von WMS

F¨ ur die Abnahmen und Tests ist vom Auftragnehmer ausreichendes und qualiﬁziertes Personal bereitzustellen, welches den reibungslosen Ablauf der beschriebenen Aktivit¨ aten sicherstellt. Zus¨ atzlich ist vom Auftragnehmer ein verantwortlicher Ansprechpartner zu benennen. Nach der Endabnahme des Gewerks erfolgt die Gefahr¨ ubertragung vom Auftragnehmer auf den Auftraggeber, und die bei der Auftragsvergabe vereinbarte Gew¨ ahrleistungszeit beginnt. Das Ziel der Projektphase Abnahme ist der Abschluss des Projekts Realisierung des Warehouse Managementsystems. In dieser Phase des Projekts sind alle zugesicherten Eigenschaften u uft, die Gewerke entsprechen den ¨ berpr¨ Anforderungen, das Abnahmeprotokoll weist keine Fehler oder L¨ ucken auf und wird von beiden Vertragspartnern unterzeichnet. Das WMS geht in den Produktivbetrieb.

9. Anhang

¨ 9.1 Uberblick marktu ¨ blicher Technologien am Beispiel (Auto-ID) Middleware Der Einsatz neuer Technikkomponenten in Materialﬂuss- oder ERP-Systemen hat sehr h¨ auﬁg Anpassungen der betrieblichen Prozesse zur Folge. Pro¨ zess¨ anderungen erfordern aber fast immer auch Anderungen der steuernden IT-Systeme. Je komplexer die Prozess¨ anderungen sind, umso st¨arker steigt der Anteil der Kosten f¨ ur das Softwareengineering an den Gesamt¨ projektkosten. Es ist keine Seltenheit, dass die Kosten f¨ ur Anderungen im ERP-System h¨ oher ausfallen als die Hardwareanschaﬀungskosten f¨ ur neue Auto-ID-Infrastruktur wie z. B. RFID-Komponenten. Gerade an diesen Soft¨ warekomponenten m¨ ochte man m¨ oglichst wenige Anderungen nach einer erfolgreichen Inbetriebnahme durchf¨ uhren, um zu vermeiden, dass Seiteneﬀekte die Produktivit¨ at des Unternehmens beeintr¨ achtigen. Ein Technologiewechsel muss folglich mit m¨ oglichst geringen Kosten in den ERP-Systemen durchgef¨ uhrt werden k¨ onnen. Um Auto-ID- und sekund¨ are IT-Systeme in eine bestehende IT-Landschaft zu integrieren, muss die Anbindung an die ERP-Softwaresysteme abstrahiert werden. Ein probates Mittel f¨ ur solch eine Abstraktion ist der Einsatz einer Middleware, die z. B. durch die Vereinheitlichung von Schnittstellen als Abstraktionslayer zwischen den Kommunikationspartnern agiert. Beispielsweise muss ein ERP-System nicht wissen, ob ein Objekt durch einen Barcodeleser, ein RFID-Tag oder durch die manuelle Eingabe eines Bedieners eindeutig identiﬁziert wurde. Diese Information wird durch eine Middleware vor dem ERP-System verborgen. Die Middleware sorgt im Wesentlichen f¨ ur die Koordination der Kommunikation, d.h. sie routet die Daten vom jeweiligen Sender zum Empf¨ anger. Auch eine m¨ ogliche Verdichtung der Daten und eine Translation in ein f¨ ur den Empf¨ anger verst¨ andliches Format kann in der Middleware stattﬁnden. Man unterscheidet grunds¨ atzlich zwischen Systemen, die auch vertikale Funktionalit¨ aten wie z. B. Datenhaltung oder Datenmanipulationen durchf¨ uhren, und so genannten Informationsbrokern, die die Daten lediglich horizontal weitergeben. Im ersten Fall handelt es sich eher um so genannte

332

9. Anhang

,,Edgeware“, d.h. um Middleware-Komponenten, die mit einer gewissen Eigenintelligenz bzw. Funktionalit¨ at erweitert sind. Die Kommunikation zwischen den teilnehmenden Systemen und damit die Middleware an sich basiert u ¨blicherweise auf einer Auswahl folgender Konzepte: • • • • • • •

RPC -Remote Procedure Call SOAP -Simple Object Access Protocol CORBA -Common Object Request Broker Architecture RMI -Remote Method Invocation Jini -Java intelligent network infrastructure Web Service Peer-to-Peer-Computing

Die fr¨ uhen Konzepte RPC und CORBA spielen in Software-Neuentwicklungen nur noch eine zunehmend untergeordnete Rolle. Das erste plattformunabh¨ angige Konzept einer Middleware war das Javabasierte RMI, auf das das Unternehmen Sun Ende der neunziger Jahre mit seiner Middleware-Plattform Jini aufsetzte. Auch mit Peer-to-PeerComputing l¨ asst sich eine hocheﬃziente Verbindung zwischen den Kommunikationspartnern gestalten, wobei man dann ganz ohne zentrale Dienste auskommt. Jeder Peer kann hier sowohl Client als auch Dienstanbieter sein. SOAP wurde mit dem Ziel entwickelt, den Austausch von strukturierten Daten zwischen verteilten Anwendungen zu erm¨ oglichen. F¨ ur die Repr¨asentation ¨ der Daten wird XML und zur Ubertragung der Nachrichten Internetprotokolle wie HTTP genutzt. SOAP erlebte in der Weiterentwicklung mit Hilfe von Web Services bzw. Service-Oriented Architecture (SOA) eine Renaissance, wobei ¨ ahnlich wie bei Jini dynamisch Dienste registriert und gesucht werden k¨ onnen. Jini verwaltet die Services im jeweiligen lokalen Subnetz, w¨ ahrend Web Service mit Hilfe des Universal Discovery and Description Interface (UDDI) Dienste im Internet nutzen oder anbieten kann, solange sie auf SOAP-Funktionalit¨ at zur¨ uckgreifen. Unter SOA versteht man einen dienstorientierten und verteilten Architekturansatz. Als Services bzw. Dienste werden bereitgestellte Funktionalit¨aten gesehen, die u ¨ ber Schnittstellen angesprochen werden. Die Kernidee ist es, durch die lose Kopplung von einfachen, unabh¨angigen Diensten komplexe Dienste aufzubauen. Dabei werden aufw¨ andige Prozesse durch die Komposition bzw. Aneinanderreihung von Services abgebildet. Besonders Web Services, die auf oﬀenen Standards wie XML und HTTP aufsetzen, sind zur Umsetzung einer SOA geeignet. Die Vorteile einer Service-Oriented Architecture sind hohe Flexibilit¨ at, die Wiederverwendbarkeit der Dienste und der hohe Grad der Verteilung. Sofern sich Middleware-Systeme mit der unternehmensweiten oder -¨ ubergreifenden Kommunikation zwischen IT-Systemen besch¨aftigen und zus¨atzlich noch Prozesslogik abbilden, werden sie h¨ auﬁg auch als Enterprise Application

¨ 9.1 Uberblick markt¨ ublicher Technologien am Beispiel (Auto-ID) Middleware

Business

Business

Activity Monitoring

Activity Services

333

BizTalk Server 2006 Engine Orchestration

Business Rules Engine Messaging

Health and Activity Tracking

Enterprise Single Sign-On

Abbildung 9.1. Microsoft Middleware BizTalk Server

Integration (EAI) Tools bezeichnet. Prozesslogik auf unterschiedlichen Systemen, die u ¨ ber EAI-Mechanismen miteinander kommunizieren, nennt man h¨ auﬁg auch Kollaborative Gesch¨aftsprozesse. Anhand verschiedener Produkte sollen nachfolgend Beispiele f¨ ur aktuelle Middleware-Systeme aufgezeigt werden. 9.1.1 Microsoft Eine Microsoft-Middleware zur Enterprise Application Integration ist der so genannte Microsoft BizTalk Server . Aufsetzend auf .NET bietet der Microsoft BizTalk Server standardisierte Schnittstellen u ¨ ber Web Services, die durch Transformationsregeln die eingehenden Objekte in das Format des Zielsystems konvertieren. Neben Web Services k¨ onnen andere Softwareapplikationen auch u ¨ ber so genannte Adapter angebunden werden. Der BizTalk Server versteht sich dabei als Hub und steht damit in Konkurrenz zu Peerto-Peer-Systemen. Microsoft und die hier nicht beschriebenen Middleware-

334

9. Anhang

Systeme von Sybase (iAnywhere) und Progress (Sonic) gehen bei der applikations¨ ubergreifenden Kommunikation mit der .NET-Plattform einen eigenen Weg. Die .NET-Plattform l¨ auft nur auf Hardware mit Microsoft-Betriebssystemen. 9.1.2 SAP SAP NetWeaver bildet die technologische Grundlage der Middleware von SAP. Dabei nimmt die SAP-NetWeaver-Komponente Exchange Infrastructure (XI) eine zentrale Rolle f¨ ur den Datenaustausch zwischen beteiligten Kommunikationspartnern ein. XI bindet u ¨ber den so genannten Integration Broker heterogene Komponenten an. Der eigentliche Datenaustausch wird durch Application Link Enabling (ALE) nicht nur zwischen SAP-Modulen, sondern auch bei der Kommunikation mit Fremdsystemen durchgef¨ uhrt. ALE konsolidiert die Art der Kommunikation, indem z. B. XML, SOAP oder SAP-eigene Integrationsstandards wie Remote Function Calls (RFC) oder Intermediate Documents (IDocs) zum Einsatz kommen. Klar strukturierte Austauschformate mit Kontroll-, Daten- und Statuss¨ atzen entstehen an den Schnittstellen der Business Objects (BO), den sogenannten Business Application Programming Interfaces (BAPI). ALE bietet folgende drei Dienste an: Application Services Die Application Services bilden die Schnittstelle zu den Business Objects und vereinfachen den Datenaustausch zwischen den Systemen. Distribution Services Die Distribution Services sind das Herzst¨ uck des ALE, sie bieten Filter, Konverter, Verteilungsmodelle etc. an. Je nach Typ, Empf¨ anger, Verteilungsmodell oder anderen Kriterien kann dieser Service z. B. das Master-IDoc, welches vom Business Object erstellt wurde, umwandeln. Hier werden bestimmte Datenfelder ausgeblendet oder mit vorhandenen Daten gef¨ ullt. Communication Services Die Communication Services realisieren die Verbindung der Systeme z. B. mit RFCs, die einer Transaktionskontrolle unterliegen. Durch diese RFCs k¨ onnen Funktionsaufrufe auch auf entfernten und auch auf Nicht-SAP-Systemen ausgef¨ uhrt werden. Falls die Gegenseite ein Fremdsystem ist, welches RFC oder ALE nicht unterst¨ utzt, kommt ein ALE-Converter zum Einsatz. SAP entwickelt selbst keine ALE-Converter, es gibt aber einige von SAP zertiﬁzierte ALE-Converter, wie z. B. die eWay-Schnittstelle in Suns SeeBeyond, einen Konverter f¨ ur IBM’s WebSphere oder zu Microsofts BizTalk Server. SAP Auto-ID Infrastructure (SAP-AII) ist die Komponente, die sich innerhalb SAP NetWeaver mit der Integration von Auto-ID-Systemen wie z. B. Barcode-Scannern und RFID-Technologien besch¨aftigt. Kommt sie nicht als

¨ 9.1 Uberblick markt¨ ublicher Technologien am Beispiel (Auto-ID) Middleware

335

mySAP™ Business Suite Composites Rechnungsprüfung

...

...

...

SAP NetWeaver™

APO

ERP

CRM

FI

Komponenten

Abbildung 9.2. SAP Enterprise Application Integration (EAI)

Standalone-System zum Einsatz, dann werden noch zus¨atzlich die Komponenten SAP XI und SAP Supply Chain Management Server ben¨otigt. 9.1.3 Oracle Die Middleware zur EAI von Oracle heißt Fusion. Sie besteht aus einer Menge unterschiedlicher Werkzeuge, die im Wesentlichen auf standardisierten Komponenten aufbauen. Oracle teilt Fusion in f¨ unf unterschiedliche, mehr oder minder hierarchische Komponenten: • • • • •

Grid Infrastructure Application-Server Integration & Business Management Business Intelligence Suite User Interface

Grid Infrastructure Oracles Middleware unterst¨ utzt bei Bedarf Grid Computing, d.h., die zugrunde liegende Hardware-Infrastruktur wird so verwaltet, dass sie f¨ ur die dar¨ uber liegenden Schichten wie ein System erscheint. Application-Server Der Oracle Application-Server 10g bildet die Plattform f¨ ur die Anwendungen in der Oracle Fusion Middleware. Hier werden

336

9. Anhang

SAP NetWeaver™ NetWeaver People Integration Multichannel

Collaboration

Knowledge Management

Master Data Management

Process Integration Integration Broker

Business Process Management

Application Platform J2EE Intelligence

Websphere

Business Intelligence

Microsoft®.net

Life-Cycle Management

Information Integration

Composite-Application Framework

...

Portal

ABAP Management

DB and OS Abstraction

Abbildung 9.3. SAP Middleware NetWeaver

z. B. auf J2EE-Basis die technischen Funktionalit¨aten wie beispielsweise Sicherheit, Transkaktionsmanagement und Namens- und Verzeichnisdienste als SOA-basierte Funktionalit¨ aten bereitgestellt. Integration & Business Management Diese Schicht ist das Herzst¨ uck der Oracle Middleware, in ihr ﬁndet die Datentransformation f¨ ur den Aus-

¨ 9.1 Uberblick markt¨ ublicher Technologien am Beispiel (Auto-ID) Middleware

337

User Interaction Portals, Content, Search, Desktop, Mobile, VoIP Business Intelligence ETL, O&A, OLAP, Reports, Alerts, Real Time

Development Tools SOA Tools, Framework

Systems Management System Application Services

Integration & Process Management Messaging, ESB, BPM, B2B, BAM, MDM Identity Management Application Server J2EE, WS-*, Events, Rules

Directory Provisioning, Single Sign-on, Identity Administration

Grid Infrastructure Cluster, Metadata, Registry, Security

Abbildung 9.4. Oracle Middleware Fusion

tausch mit anderen Middleware-Produkten zur EAI statt. Hier gibt es z. B. Konnektoren zu SAP NetWeaver oder IBM WebSphere. Zur Kommunikation dient der Enterprise Service Bus (ESB), der die Datenstrukturen (Messages) des Senders ggf. so konvertiert, dass diese vom Empf¨anger verstanden und verarbeitet werden k¨ onnen. Auch das Verwalten von Gesch¨aftsabl¨aufen Business Process Management (BPM) und das Business Activity Monitoring (BAM) zum Betrachten der Gesch¨ aftvorf¨ alle, um auf der Basis der erhaltenen Informationen Entscheidungen zu treﬀen, ﬁnden hier statt. Business Intelligence Suite Die Oracle Business Intelligence Suite bietet z. B. durch Online Analytical Processing (OLAP) echtzeitnahe Unterst¨ utzung beim Beobachten, Erstellen und Filtern von kritischen Gesch¨aftsabl¨aufen und Entscheidungen.

338

9. Anhang

CRM

ERP

BPEL

Enterprise Service Bus Mediator

.NET

Legacy

Java

Abbildung 9.5. Oracle – Enterprise Service Bus (ESB)

User Interface Das User Interface bildet die Schnittstelle zum Benutzer, indem es die entsprechenden Benutzeroberﬂ¨ achen auf Endger¨aten wie z. B. Desktops, Browser-Applikationen oder mobilen Endger¨aten zur Verf¨ ugung stellt. Die Oracle Fusion Middleware wird durch weitere Komponenten erg¨anzt. Die Development Tools stellen z. B. SOA-Komponenten in einem Framework zur Erg¨ anzung der Funktionalit¨ at zur Verf¨ ugung. Systems Management und Identity Management stellen Werkzeuge z. B. zum Verwalten der Anwendungen und Benutzer bereit. RFID-Komponenten, Barcode-Scanner und mobile Endger¨ate werden bei der Oracle Middleware mit Hilfe eines sogenannten Sensor-Edge-Servers angebunden. Dieser nimmt die zur Identiﬁkation ben¨otigten Informationen auf, bereinigt gegebenenfalls diese Rohdaten und reicht sie anschließend weiter an die Datenbank, wo sie im Sensor Data Archive gespeichert werden. 9.1.4 IBM WebSphere ist eine Software-Produktlinie von IBM, die mit Hilfe unterschiedlicher Komponenten Middleware-Funktionalit¨at bereitstellt. Kernst¨ uck der Middleware ist der IBM WebSphere Application-Server (WAS), der damit ein zentraler Baustein der IBM Referenzarchitektur zur Business Integration ist. F¨ ur die SOA-Funktionalit¨ at setzt WAS auf J2EE auf und unterst¨ utzt aktuelle Web Service Standards. Zur Konnektivit¨at der einzelnen Kommunikationspartner kommt der Enterprise Service Bus (ESB) zum Einsatz, der bei Bedarf Mechanismen f¨ ur die Konvertierung der Daten bzw. der Datenstrukturen der beteiligten Systeme vorh¨ alt. Der ESB bietet eine weitgehend auf Standards basierende Anwendungsintegration und Unterst¨ utzung f¨ ur Web Services und nachrichtenorientierten Transport. F¨ ur den Datenaustausch der

¨ 9.1 Uberblick markt¨ ublicher Technologien am Beispiel (Auto-ID) Middleware

339

Entwicklungsservices Services für Business Performance Management Interaktionsservices

Prozessservices

Informationsservices

Konnektivitätsservices Enterprise Service Bus

Partnerservices

Business Application Services

Anwendungsund Informationsressourcen

Services für das Infrastrukturmanagement

Abbildung 9.6. IBM Middleware WebSphere

Kommunikationspartner kann auch WebSphere MQ, das Nachfolgeprodukt von MQSeries, zum Einsatz kommen, wodurch eine transaktionsgesteuerte Kommunikation z. B. auch mit Großrechnern aufgesetzt werden kann. Unternehmensweite Gesch¨ aftprozesse k¨ onnen mit dem WebSphere Message Broker abgebildet werden. 9.1.5 SUN Microsystems Die Sun Java Composite Application Platform Suite (CAPS) ist aus dem ehemaligen SeeBeyond ICAN-System hervorgegangen. Auch CAPS setzt auf SOA und bildet daf¨ ur Adapter, Datentransformationen, Orchestrations der Web Services und Kommunikationsmechanismen ab. Weil sich mittlerweile Standards f¨ ur oﬀene Services etabliert haben, gibt es auch immer mehr Web Services, die applikations¨ ubergreifend wiederverwendbar sind. Die Web Services Description Language (WSDL) ist eine XML-Speziﬁkation zur standardisierten Beschreibung von Web Services. Sun registriert diese mit WSDL speziﬁzierten Services per UDDI. Solcherart standardisierte Services lassen sich auch u ¨ ber Applikationsgrenzen hinaus einsetzen. Die Schnittstelle, mit der die Applikationen miteinander kommunizieren k¨onnen, wird bei SUN Application Service Interface (ASI) genannt und dient zur Entkopplung der speziﬁschen Anwendungssystemfunktionalit¨ at von der Prozessdeﬁnition sowie der Entkopplung der einzelnen Anwendungen voneinander. Zur Integration von RFID in die Sun-Architektur laufen sogenannte Devicecontroller, die Java-basierte Treiber der RFID-Hardware implementieren. Diese Devices

340

9. Anhang

Warehouse Management System

Supply Chain Execution

Enterprise Resource Planning

Enterprise Application Integration

Network

Object Name Service

Java System RFID Software RFID Event Manager

RFID Information Server

RFID Reader

RF Signal

RFID Database

z.B. Electronic Product Code-Tag

Abbildung 9.7. SUN RFID-Middleware-Referenzarchitektur

bieten ihre Dieste als Web Services u ¨ber den Integration Server bzw. u ¨ ber CAPS an. Sun hat mit der Programmiersprache Java eine objektorientierte und betriebssystemunabh¨ angige Plattform geschaﬀen, die die Basis fast aller hier beschriebenen Middleware-Architekturen ist.

Abku ¨rzungsverzeichnis

AG AGB ALE AN ANSI ASI Auto-ID BAM

BAPI BMEcat BO BOINC BPM

CAPS CORBA

CSMA/CD

DDL DTAUS

Auftraggeber Allgemeine Gesch¨aftsbedingungen Application Link Enabling = Synchronisierung von Daten von verschiedenen SAP-Systemen Auftragnehmer American National Standards Institute = Amerikanischer Normenausschuß Application Service Interface Automatische Identiﬁkation Business-Activity-Monitoring = die Sammlung von Analysen und Pr¨asentationen u aftsprozesse in Organisa¨ ber zeitrelevante Gesch¨ tionen Business Application Programming Interface = eine standardisierte Programmierschnittstelle der SAP-Business-Objekte Bundesverband Materialwirtschaft, Einkauf und Logistik = ein standardisiertes Austauschformat f¨ ur Katalogdaten Business Objects Berkeley Open Infrastructure for Network Computing = eine Softwareplattform f¨ ur verteiltes Rechnen Business-Process-Management = Managementprozesse und Software, die sich mit der Automatisierung und Optimierung von Gesch¨aftsprozessen auseinandersetzen Composite Application Platform Suite Common Object Request Broker Architecture = objektorientierte Middleware, die plattform¨ ubergreifende Protokolle und Dienste deﬁniert Carrier Sense Multiple Access/Collision Detection = Medienzugriﬀsverfahren, das den Zugriﬀ verschiedener Stationen auf ein ¨ gemeinsames Ubertragungsmedium im Zeitmultiplexverfahren beschreibt Data Deﬁnition Language Datentr¨ageraustausch-Verfahren = ein Verfahren im bargeldlosen Zahlungsverkehr

342

Abk¨ urzungsverzeichnis

DTD DNS EAI

EDV ERP EDI EDIFACT

EHB EPB EP ESB ETB FIFO FTF FTP FTS HRL HTML HTTP I-Punkt IP ID IDocs IMAP ISO IT J2EE

Jini

Document Type Deﬁnition = eine Deklaration in SGML- und XML-Dokumenten zur Strukturierung Domain Name Service Enterprise Application Integration = Integration von verschiedenen Applikationen auf unterschiedlichen Plattformen zu Gesch¨aftsprozessen Elektronische Datenverarbeitung Enterprise Resource Planning Electronic Data Interchange = Format zum Austausch von Daten Electronic Data Interchange For Administration, Commerce and Transport = ein branchen¨ ubergreifender internationaler Standard f¨ ur das Format elektronischer Daten im Gesch¨ aftsverkehr Elektroh¨angebahn Elektropalettenbahn Europalette Enterprise Service Bus = die zentrale Aufgabe eines ESB ist der Austausch von Daten zwischen IT-Systemen Elektrotragbahn First-In-First-Out“ = Auslagerungsreihenfolge des gleichen Ar” tikels nach dem Einlagerungsdatum (¨ altester Artikel zuerst) Fahrerloses Transportfahrzeug File Transfer Protocol = ein Netzwerkprotokoll zur Datei¨ ubertragung Fahrerloses Transportsystem Hochregallager Hypertext Markup Language = standardisierte Sprache des World Wide Web ¨ Hypertext Transfer Protocol = ein Protokoll zur Ubertragung von Daten u ¨ ber ein Netzwerk Identiﬁzierungspunkt Internet Protocol, IP-Adresse: Nummer zur Identiﬁzierung eines Computers im Internet Barcode-Identnummer Intermediate Documents Internet Message Access Protocol = ein Protokoll f¨ ur den Zugriﬀ sowie die Verwaltung von empfangenen E-Mails International Organization for Standardization Informationstechnik Java Platform, Enterprise Edition= die Speziﬁkation einer Softwarearchitektur f¨ ur die transaktionsbasierte Ausf¨ uhrung von in Java programmierten Webanwendungen Java intelligent network infrastructure = ein Framework zum Programmieren von verteilten Anwendungen

Abk¨ urzungsverzeichnis

JNDI

KEP KPI LAM LAN LE LHM LIFO LVS MFR MFC OLAP OSI OSI-Modell OR-Mapping PIN POP3 QS QTW QVW PPS RBG RFID RFC RMI RPC SLS SMTP

SOA SOAP

343

Java Naming and Directory Interface = eine Programmierschnittstelle (API) innerhalb der Programmiersprache Java f¨ ur Namensdienste und Verzeichnisdienste Kurier-, Express- und Paket(dienst) Key Performance Indicator = Kennzahl Lastaufnahmemittel Local Area Network = innerbetriebliches Netzwerk Ladeeinheit als eine Lager- und Transporteinheit Ladehilfsmittel, z.B. Karton, Beh¨ alter oder Palette Last-In-First-Out“ = Auslagerungsreihenfolge des gleichen Arti” kels nach dem Einlagerungsdatum (j¨ ungster Artikel zuerst) Lagerverwaltungssystem Materialﬂussrechner Material Flow Controller Online-Analytical-Processing = echtzeitnahes analytisches Informationssystem Open Systems Interconnection Open Systems Interconnection Reference Modell Object-Relational-Mapping = die Beziehung zwischen Objekten und Zeilen in einer Datenbanktabelle Personal Identiﬁcation Number ¨ Post Oﬃce Protocol Version 3 = ein Ubertragungsprotokoll, u ¨ ber welches ein Client E-Mails von einem E-Mail-Server abholen kann Qualit¨atssicherung Quertransportwagen Querverteilwagen Produktionsplanungs- und Steuerungssystem Regalbedienger¨at Radio Frequency Identiﬁcation Remote Function Call = um Funktionsbausteine innerhalb von SAP R/3 aufzurufen Remote Method Invocation = Aufruf einer Methode eines entfernten Java-Objekts Remote Procedure Call = Aufruf einer Funktion auf einem entfernten Rechner oder Host Staplerleitsystem Simple Mail Transfer Protocol = ein Protokoll der Internetprotokollfamilie, das zum Austausch von E-Mails in Computernetzen dient Service-orientierte Architektur = ein Managementkonzept Simple Object Access Protocol = plattformunabh¨ angiges Kommunikationsprotokoll bei Web Services

344

Abk¨ urzungsverzeichnis

SPS

SQL TCP/IP TSU TSP TUL UDDI UDP UML

URL USV WA WAN WAS WCS WE WMS WSDL WWS XI

XML XSD XML-RPC

Speicherprogrammierbare Steuerung zur Steuerung der Bewegungen der RBG und der F¨orderanlagen. Die SPS ist mit dem MFR online verbunden. Structured Query Language Transmission Control Program/Internet Protocol Transport Unit Travelling-Salesman-Problem Transport, Umschlag und Lagerung Universal Description, Discovery and Integration = ein Verzeichnisdienst User Datagram Protocol = ein verbindungsloses Netzprotokoll Uniﬁed Modeling Language = eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache f¨ ur die Modellierung von Software Uniform Resource Locator = Internet-Adresse Unterbrechungsfreie Stromversorgung Warenausgang Wide Area Network oder Warenannahme WebSphere Application Server = zentraler Baustein der IBMReferenzarchitektur zur Business Integration Warehouse Control System Wareneingang Warehouse Managementsystem Web Services Description Language = XML-Speziﬁkation zur standardisierten Beschreibung von Web Services Warenwirtschaftssystem Exchange Infrastructure = Bestandteil des SAP NetWeaver, ist eine Middleware-Komponente,die f¨ ur den Datenaustausch zwischen beteiligten Kommunikationspartnern wichtig ist Extensible Markup Language = ist ein Standard zur Deﬁnition von Auszeichnungssprachen XML Schema Deﬁnition Language = Strukturbeschreibungssprache f¨ ur XML-Dokumente eine Speziﬁkation, die es Software auf verschiedenen Systemen und unter verschiedenen Umgebungen erlaubt, miteinander u ¨ ber ein TCP/IP-basiertes Netzwerk zu kommunizieren

Literaturverzeichnis

[1] [2] [3] [4] [5]

[6]

[7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

Alicke, Knut: Modellierung und Optimierung mehrstuﬁger Umschlagsysteme. Karlsruhe, Universit¨ at Karlsruhe, Dissertation, Okt. 1999 Arnold, Dieter: Materialﬂusslehre. 2. Auﬂage. Verlag Vieweg & Sohn Braunschweig Wiesbaden, 1998 Balzert, Helmut: Lehrbuch der Softwaretechnik — Software-Entwicklung. Spektrum Akademischer Verlag GmbH, Heidelberg, Berlin, 1996 Balzert, Helmut: Lehrbuch der Software-Technik – (Lehrb¨ ucher der Informatik); Bd. 1. Software-Entwicklung. Bd. 2. Auﬂage. Spektrum, Akad. Verl., Heidelberg : Berlin, 2000 Bretzke, Wolf-R¨ udiger: Die Eignung der Transaktionskostentheorie zur Begr¨ undung von Make-or-Buy-Entscheidungen. In: Pfohl, Hans-Christian (Hrsg.): Logistikforschung – Entwicklungsz¨ uge und Gestaltungsans¨ atze. Erich Schmidt Verlag Berlin, 1999, S. 335–363 Centrale f¨ ur Coorganisation GmbH, K¨ oln (Hrsg.): Cross Docking zwischen Handel und Industrie – Eine ECR-Anwendungsempfehlung der ECR¨ Initiativen Deutschland und Osterreich. Centrale f¨ ur Coorganisation GmbH, K¨ oln, M¨ arz 2000 eLogistics-Facts 1.0. Market Research Service Center und Deutsche Post eBusiness GmbH eCommerce Services in Zusammenarbeit mit Fraunhofer Institut Materialﬂuss und Logistik, November 2001 Dietze, G¨ unther ; Figgener, Olaf: Studie Lagerverwaltungssysteme und ihr Leistungsproﬁl. In: F+H F¨ ordern und Heben 51 (2001), Nr. 1-2, S. 59–60 Dietze, G¨ unther ; Figgener, Olaf ; Spee, Detlef: Studie Lagerverwaltungssysteme und ihr Leistungsproﬁl. In: F+H F¨ ordern und Heben 50 (2000), Nr. 12, S. 18–19 DIN 55405 – Begriﬀe f¨ ur das Verpackungswesen. Deutsches Institut f¨ ur Normung e.V., Beuth-Verlag, Berlin, 1988-1993 DIN 55429 – Schachteln aus Karton, Vollpappe oder Wellpappe, Bauarten Ausf¨ uhrungen Lieferformen. Deutsches Institut f¨ ur Normung e.V., BeuthVerlag, Berlin, Juni 1985 Erl, Thomas: Service Oriented Achitecture. Prentice Hall, 2005 FEM 9.221, – Leistungsnachweis f¨ ur Regalbedienger¨ ate; Zuverl¨ assigkeit, Verf¨ ugbarkeit FEM 9.222, – Regeln u ugbarkeit von Anlagen mit ¨ber die Abnahme und Verf¨ Regalbedienger¨ aten und anderen Gewerken. 1989 G¨ opfert, Ingrid: Trends bei Logistik-Kennzahlen. In: F¨ ordern und Heben 46 (1996), Nr. 4, S. 254–258 Großeschallau, W.: Materialﬂussrechnung. Springer-Verlag, Berlin Heidelberg, 1984 Gudehus, Timm: Grundlagen der Kommissioniertechnik. Verlag W. Girardet, Essen, 1973

346

Literaturverzeichnis

[18] Gudehus, Timm: Logistik: Grundlagen, Strategien, Anwendungen. SpringerVerlag, Berlin Heidelberg, 1999 [19] Hafner, Sigrid (Hrsg.): Industrielle Anwendung evolution¨ arer Algorithmen. R. Oldenbourg Verlag M¨ unchen, 1998 [20] Hein, Mathias: TCP/IP — Internet-Protokolle im praktischen Einsatz. 4. Auﬂage. International Thomson Publishing, Bonn, 1998 [21] Heistermann, J.: Genetische Algorithmen. B.G. Teubner Verlag Stuttgart Leipzig, 1994 [22] J¨ unemann, Reinhardt: Materialﬂuß und Logistik – Systemtechnische Grundlagen mit Praxisbeispielen. Springer-Verlag, Berlin Heidelberg, 1989 [23] J¨ unemann, Reinhardt ; Beyer, Andreas: Steuerung von Materialﬂuß- und Logistiksystemen. 2. Auﬂage. Springer-Verlag, Berlin Heidelberg New York London Paris Tokyo, 1998 [24] J¨ unemann, Reinhardt ; Schmidt, Thorsten: Materialﬂußsysteme – Systemtechnische Grundlagen. 2. Auﬂage. Springer-Verlag, Berlin Heidelberg New York London Paris Tokyo, 1999 [25] Jodin, Dirk ; Hompel, Michael ten: Sortier- und Verteilsysteme. SpringerVerlag, Berlin, 2005 [26] Jungnickel, Dieter: Optimierungsmethoden — Eine Einf¨ uhrung. SpringerVerlag, Berlin, Heidelberg, New York, 1999 [27] Kauffels, Franz-Joachim: Moderne Datenkommunikation — Eine strukturierte Einf¨ uhrung. International Thomson Publishing, Bonn, 1996 [28] Kinnebrock, W.: Optimierung mit genetischen und selektiven Algorithmen. R. Oldenbourg Verlag Verlag Verlag M¨ unchen Wien, 1994 [29] Krampe, Horst (Hrsg.) ; Lucke, Hans-Joachim (Hrsg.): Grundlagen der Logistik – Einf¨ uhrung in Theorie und Praxis logistischer Systeme. 2. Auﬂ. HussVerlag GmbH, M¨ unchen, 2001 [30] Kuhn, A. ; Hellingrath, B.: Supply Chain Management — Optimierte Zusammenarbeit in der Wertsch¨ opfungskette. Springer Verlag, Berlin Heidelberg, 2002 [31] Kuhn, A. ; Pielok, Th. ; S¨ umpelmann, A.: Prozesskettenanalyse — Instrumente f¨ ur die strategische Planung. In: Jahrbuch der Logistik 1993 (1993), S. 160 ﬀ. [32] Lange, Volker ; Brachetti, Christoph: Mehrweg-Transport-Systeme. Verlag Praxiswissen, Dortmund, 1997 [33] Lolling, Andreas: Fehlerraten verschiedener Kommissionersysteme in der Praxis. In: Zeitschrift f¨ ur Arbeitswissenschaft 56 (2002), Nr. 1-2, S. 112–115 [34] Martin, Heinrich: Praxiswissen Materialﬂussplanung. Verlag Vieweg & Sohn Braunschweig Wiesbaden, 1999 [35] Mettler Toledo (Hrsg.): Logistiksysteme f¨ ur Gewichts- und Volumenerfassung. Mettler Toledo [36] N.N.: Gerolsteiner positioniert sich neu — Automatische Chargenverfolgung. In: Logistik Heute 23 (2001), Juni, Nr. 6, S. 20–22 [37] Oestereich, Bernd: Objektorientierte Softwareentwicklung. 4. aktualisierte Auﬂage. Oldenbourg, 1998 [38] Oestereich, Bernd: Erfolgreich mit Objektorientierung. Oldenbourg Verlag M¨ unchen Wien, 1999 [39] Oestereich, Bernd: Die UML 2.0 Kurzreferenz f¨ ur die Praxis. 3. Auﬂage. Oldenbourg, 2004 [40] Papageorgiou, Markos: Optimierung: statische, dynamische, stochastische Verfahren. 2. Auﬂage. R. Oldenbourg Verlag M¨ unchen, 1996 [41] Pfohl, Hans-Christian: Logistiksysteme – Betriebwirtschaftliche Grundlagen. 6. Auﬂage. Springer-Verlag, Berlin Heidelberg u.a., 2000

Literaturverzeichnis

347

[42] Pleßmann, K.W.: Handbuch zum VDI-Bildungswerk GmbH Seminar: Lasten- und Pﬂichtenheft als Vorbereitung und Voraussetzung der Entwicklung von Software. Stuttgart, 2000 [43] Radtke, Axel: Beitrag zur Entwicklung optimierter Betriebsstrategien f¨ ur Sortiersysteme. Verlag Praxiswissen, 2000 [44] Raiffa, Howard: Einf¨ uhrung in die Entscheidungstheorie. R. Oldenbourg Verlag M¨ unchen Wien, 1973 [45] Reichmann, Thomas: Kennzahlen. In: Bloech, J¨ urgen (Hrsg.) ; Ihde, G¨ osta B. (Hrsg.): Vahlens großes Logistiklexikon, Verlag Franz Vahlen, M¨ unchen, 1997, S. 425–426 [46] Sauer, J¨ urgen: Multi-Site Scheduling — Hierarchisch koordinierte Ablaufplanung auf mehreren Ebenen. Oldenburg, Universit¨ at Oldenburg, Habilitation, Januar 2002 [47] Scheffler, M.: Grundlagen der F¨ ordertechnik – Elemente und Triebwerke. Verlag Vieweg & Sohn Wiesbaden, 1994 [48] Scheffler, M. ; Feyrer, K. ; Matthias, K.: F¨ ordermaschinen – Hebezeuge, Flurf¨ orderzeuge, Aufz¨ uge. Verlag Vieweg & Sohn Wiesbaden, 1997 [49] Silberschatz, Abraham ; Peterson, James L. ; Galvin, Peter B.: Operating System Concepts. 3. Auﬂage. Addison Wesley, 1991 [50] Spee, Detlef: LVS-Auswahl per Internet — Kosten sparende Entscheidungshilfe. In: Hebezeuge und F¨ ordermittel 41 (2001), Juni, S. 282–283 [51] Stroustrup, Bjarne: Die C++ Programmiersprache. Addison-WesleyLongmann, Bonn, 1998 [52] Sun: Java 2 Platform, Enterprise Edition. Sun Microsystems, Inc., http: //java.sun.com/j2ee/reference/whitepapers/j2ee_guide.pdf, 1999 [53] Sun: Java Remote Method Invocation Speciﬁcation. Sun Microsystems, Inc., http://java.sun.com/j2se/1.5/pdf/rmi-spec-1.5.0.pdf, 2004 [54] Tanenbaum, Andrew S.: Moderne Betriebssysteme. 2. Auﬂage. Carl Hanser Verlag, M¨ unchen, Wien, 1995 [55] Tanenbaum, Andrew S.: Computernetzwerke. Prentice Hall Verlag GmbH, M¨ unchen, 1997 [56] Tanenbaum, Andrew S. ; Steen, Maarten van: Distributed Systems. Prentice Hall, 2002 [57] ten hompel, Michael: Lagerverwaltungssysteme – Das Objekt-Ebenenmodell der Lagerverwaltung. GamBit GmbH, Dortmund, 1999 [58] ten hompel, Michael ; Heidenblut, V.: Taschenlexikon Logistik. Springen Verlag, Berlin Heidelberg, 2006 [59] ten hompel, Michael ; Schmidt, Thorsten ; Nagel, Lars: Materialﬂusssysteme – F¨ order- und Lagertechnik. Springen Verlag, Berlin Heidelberg, 2007 [60] Tompkins, James A. (Hrsg.) ; Smith, Jerry D. (Hrsg.): The Warehouse Management Handbook. Tompkins Press, Raleigh, 1998 [61] Tompkins, James A. ; White, John A. ; Bozer, Yavuz A. ; Frazelle, Edward H. ; Tanchovo, J.M.A. ; Trevino, Jaime: Facilities Planning. 2nd. Edition. John Wiley & Sons, Inc. New York u.a., 1996 ¨ [62] VDI 2319 – Ubersichtsbl¨ atter Stetigf¨ orderer – Angetriebene Rollenbahn. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, Juli 1971 ¨ atter Stetigf¨ orderer – Gurtf¨ orderer f¨ ur St¨ uckgut. Ver[63] VDI 2326 – Ubersichtsbl¨ ein Deutscher Ingenieure, Beuth-Verlag, Berlin, Juni 1979 ¨ [64] VDI 2340 – Ein- und Ausschleusungen von St¨ uckg¨ utern – Ubersicht, Aufbau und Arbeitsweise. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, M¨ arz 1997 [65] VDI 2395 – Gleislose Fahrzeugkrane. Verein Deutscher Ingenieure, BeuthVerlag, Berlin, September 1989

348

Literaturverzeichnis

[66] VDI 3312 – Sortieren im logistischen Prozeß – Entwurf. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, Dezember 1998 [67] VDI 3581 – Verf¨ ugbarkeit von Transport- und Lageranlagen sowie deren Teilsysteme und Elemente. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, Dezember 2004 [68] VDI 3586 – Flurf¨ orderzeuge – Begriﬀe, Kurzzeichen. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, M¨ arz 1996 [69] VDI 3590 Blatt 1 – Kommissioniersysteme – Grundlagen. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, April 1994 [70] VDI 3590 Blatt 1 – Kommissioniersysteme – Systemﬁndung. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, Juli 2002 [71] VDI 3591 – Transportleitsysteme. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, Dezember 1998 [72] VDI 3619 – Sortiersysteme f¨ ur St¨ uckgut. Verein Deutscher Ingenieure, BeuthVerlag, Berlin, M¨ arz 1983 [73] VDI 3649 – Anwendung der Verf¨ ugbarkeitsrechnung f¨ ur F¨ order- und Lagersysteme. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, Januar 1992 [74] VDI 3968, Blatt 1-6 – Sicherung von Ladeeinheiten. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, 1994 [75] VDI 4422 – Elektropalettenbahn (EPB) und Elektrotragbahn (ETB). Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, September 2000 [76] VDMA: VDMA-Einheitsblatt 15276: Datenschnittstellen in Materialﬂusssystemen. Verband Deutscher Maschinen- und Anlagenbau, Beuth-Verlag, Berlin, 1994 [77] W. Diffie, M. H.: New Directions in Cryptography. IEEE Transactions on Information Theory, November 1976 [78] W3C: Simple Object Access Protocol (SOAP) 1.1. W3C, World Wide Web Consortium, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, 2000 [79] W3C: SOAP Version 1.2 Part 1: Messaging Framework. W3C, World Wide Web Consortium, http://www.w3.org/TR/soap12-part1/, 2003 [80] Weber, J¨ urgen: Logistikkostenrechnung. 2. Auﬂage. Springer-Verlag, Berlin Heidelberg, 2002 [81] Weber, Michael: Verteilte Systeme. Spektrum Akademischer Verlag, Heidelberg Berlin, 1998 [82] Weck, Gerhard: Prinzipien und Realisierung von Betriebssystemen. Teubner Verlag, Stuttgart, 1982 [83] Wesselmann, Friedhelm: Untersuchungen zur Weiterentwicklung automatischer Blocklagersysteme mit gekuppelten Rollpaletten. 1997 [84] Wirth, Niklaus: Compilerbau. 4. Auﬂage. B. G. Teubner, Stuttgart, 1984 [85] Zehnder, C. A.: Informationssysteme und Datenbanken. 5. Auﬂage. B. G. Teubner Stuttgart, 1989 [86] Ziegler, H.-J.: Computergest¨ utzte Transport- und Tourenplanung. Expert Verlag, Ehningen bei B¨ oblingen, 1988 [87] Zimmermann, H.-J.: Operations Research — Methoden und Modelle. Vieweg Verlag, Braunschweig, Wiesbaden, 1987

Sachverzeichnis

¨ Uberladen, 235 ¨ Ubersetzer, 204 ¨ Ubertragungsrate, 163 4GL, 209 Oracle Fusion, 335 Ableitung, 233 Abnahme, 326 – formale, 328 adaptive Hilfesysteme, 190 Adressraum, virtueller, 198 Aggregation, 235 Akteur, 237 aktives Warten, 196 Anbieterauswahl, 320 Anbietervorauswahl, 314 Anforderungsanalyse, 237 Angebots – pr¨ asentation, 320 – vergleich, 317 Anwendungsfalldiagramm, 237 Application Link Enabling (ALE), 334 Application Service Providing, 71 Application Services, 334 Application-Server, 245, 335 Applikation, 195 Architektur, 221 Archivierung, 175 Artiﬁcial Intelligence, 127 ASP, 71 Assembler, 204 Assoziation, 177, 235 Auftragsdisposition, 125, 129, 130, 144 Auftragserfassung, 43 Auftragsvergabe, 314 Auftragszusammenf¨ uhrung, 51 Auskunftsf¨ ahigkeit, 126, 146 Auslagerung, 32 Auslagerungsdatei, 199 Ausschreibung, 309

Automatisierungspyramide, 225 Avis, 23 Backbone, 165 Backorder, 29 Backup, 184 Backus-Naur-Form, 207 Bandbreite, 163 Basisdaten, 65 Basisklasse, 233 Basiszeit, 40 Batchberechnung, 129, 130, 144 Batchkommissionierung, 42 Baud, 163 Bereitstellung – dezentral, 37 – dynamisch, 37 – statisch, 37 – zentral, 37 Bestandsdaten, 65 Bestandsf¨ uhrung, 56 Betriebsmittel, 200 Betriebsmittelstatistik, 60 Betriebssystem – kritischer Abschnitt, 200 Betriebssystem, 191, 201 – Deadlock – – Vermeidung, 195 – Echtzeitprozess, 197 – Interprozesskommunikation, 196 – Multiprogramming, 191 – Pageﬁle, 199 – Paging, 198 – Preemption, 200 – Prozess, 195 – Speichermultiplexing, 198 – Synchronisation, 191 – Task, 195 – virtuelle Maschine, 192 – Virtueller Speicher, 192 – Virtuelles I/O-System, 192

350

Sachverzeichnis

Bewegungsdaten, 66 Bibliothek, 192 Blocklager – Boden-, 74 BMEcat, 241 BNF, 207 Bodenlager, 74 BOINC, 227 Bridge, 167 Browser, 172 BS, siehe Betriebssystem Business Intelligence Suite, 337 Bytecode, 206 Client, 169 Client-Server, 226 Cold Standby, 228 Commit, 174 Communication Services, 334 Compiler, 204 Compilezeit, 205 Composite Application Platform Suite (CAPS), 339 CORBA, 252 CPFR, 17 Cross Docking, 29, 69 Customizing, 323 Dateisystem, 175 Datenbank, 177 Datenbankschema, 179 DBMS, 182 DDL, 180 Destruktor, 233 dirty read, 174 Dispatching, 59, 130, 148 Distribution Services, 334 DML, 180 DNS, 170 Doppelspiele, 132, 135 DTAUS, 241 Durchlagerung, 29 E-Commerce, 18 E-Logistics, 18 ECR, 17 Edgeware, 332 EDIFACT, 241 EHB, 110 Einheit – Entnahme-, 23 – Greif-, 23 – Lager-, 23, 27

– Logistische, 20 – Sammel-, 23 – Versand-, 23 Einlagerung, 28 Elektroh¨ angebahn, 110 Elektropalettenbahn, 110 Elektrotragbahn, 110 EMV, 163 Enterprise Application Integration, 241 Enterprise Bus, 241 Entit¨ at, 177 Entities, 276 Entity-Relationship-Diagramm, 178 EPB, 110 Equipment Manager, 273 Er¨ oﬀnungsverfahren, 141, 152 ERP, 9 ETB, 110 Exchange Infrastructure (XI), 334 F¨ orderer – Band-, 92 – Ketten-, 94 – Rollen-, 91 – Stetig-, 91 FCFS, 200 Fehlerraten, 47 Feldbus, 165 Filesystem, 175 Flurf¨ orderzeuge, 96 Frame, 159 FTP, 159 Funktionstest, 326 Gateway, 167 Gesch¨ aftslogik, 247 Gesch¨ aftsprozessaufnahme, 305 GPL, 255 Grammatiksymbol, 207 Greifzeit, 40 Grid Infrastructure, 335 Gruppierung, 57 Hardware – Memory, 192 – MMU, 192 Hot Standby, 228 HRL, 80 HTTP, 172 Hub, 166 I-Punkt, 29 IANA, 168 IBM WebSphere, 338

Sachverzeichnis IBM WebSphere Application-Server (WAS), 338 Identit¨ atskontrolle, 29 IEEE802.11, 161 IEEE802.3, 161 IEEE802.4, 161 IEEE802.5, 161 IEEE802.6, 161 Image-Backup, 185 Implementierung, 323 Inbetriebnahme, 324 – Laborphase, 324 Index, 177 indexsequenziell, 176 Individualprogrammierung, 323 Informationsﬂuss, 305 Instanz, 231 Integration & Business Management, 336 Integration Broker, 334 Intermediate Documents (IDocs), 334 Interpreter, 205 Interrupt, 194, 199 Inventory Manager, 273 Inventur, 62 IP, 160 ISO/OSI-Referenzmodell, 158 Ist-Analyse, 305 Ist-Aufnahme, 304 J2EE, 245 Java – EE 5, 256 Java Platform Enterprise Edition, 245 JEE, 256 Jini, 253 join, 181 Journalﬁle, 174 Journaling, 174, 184 Karusselllager, 87 Kennzahl, 65, 309 Kennzahlen – Logistik-, 68 KEP, 18 Klasse, 231 Klassendiagramm, 237 Kollaborative Gesch¨ aftsprozesse, 333 Kommissionier-U, 48 Kommissionierung, 34 – Ablauforganisation, 40 – auftragsparallel, 41 – auftragsweise, 40

– einfache, 40 – einstuﬁge, 41 – inverse, 50 – Organisation, 39, 42 – Strategien, 42 – zonenparallele, 41 – zweistuﬁge, 41 Kommissionierzeit, 40 Komponente, 224 Komposition, 235 Konsolidierungspunkt, 34 Konstruktor, 232 kontextsensitive Hilfe, 190 Konturenkontrolle, 30 Kran, 111 Lagerf¨ ahigkeit, 30 Lagerger¨ at, 99 Lagerhaltung, 3 Lagerplatzvergabe, 31 – Strategien, 32 Lagerspiegel, 55 Lagertypen, 54 Lagerung, 3 – Mischpaletten-, 79 Lagerverwaltung, 54, 225 LAN, 165 Lastenheft, 311 Latenzzeit, 165 Laufzeit, 205 Layer, siehe Schicht, 224 Leistungstest, 326 Leistungsverzeichnis, 309 Lieferavis, 23 Lieferf¨ ahigkeit, 3 Liftsystem, 81 Link, 171 Location Manager, 273 Logistik, 15 MAC-Adressen, 168 Makro, 204 Makroexpander, 204 Makroprozessor, 204 MAN, 165 Mandanten, 70 Maschinencode, 204 Materialﬂussrechner, 9 Medienbruch, 305, 306 Mengenverwaltung, 56 Messaging, 244 Methode, 125, 231 MFR, 9 Microsoft BizTalk Server, 333

351

352

Sachverzeichnis

Middleware, 240 mime, 172 MIS, 9 Mischpalette, 28 Modularisierung, 223 Monolithische Architektur, 222 Multiplex ¨ – Ubertragungskanal, 163, 165 – Prozessor, 196 – Speicher, 198 Multipurpose Internet Mail Extensions, 172 Multiuser, 192 myWMS – Clearing, 281 – Entit¨ at, 274 – Equipment Manager, 273 – Event-Dispatcher, 281 – Gesch¨ aftsobjekt, 274 – Inventory Manager, 273 – Location Manager, 273 – Plug-In, 271 n-Tier, 224 Nameserver, 170 Nebenl¨ auﬁgkeit, 195 NSP, 159 NTP, 170 Nummernkreis, 306 Objekt, 231 objektrelationales Mapping, 246 ODBC, 182 ODBS, 182 Open-Source, 204 Operations Research, 127 Outsourcing, 17 Pack-Programm, 186 Paket, 159 Parallelbetrieb, 325 Parametrisierung, 323 passives Warten, 196 Paternosterregal, 86 Persistierung, 173 Person-zur-Ware, 37 Pfad, 175 Pﬂichtenheft, 321 Pick-to-Belt, 49 Pickliste, 45 Pipes, 244 Plug-In, 271 Polling, 196

Polymorphie, 235 PPS, 9 Prim¨ arschl¨ ussel, 177 Priorit¨ at, 197 Projekt, 301 Projektion, 181 Protokoll, 240 Protokollheader, 158 Protokollstack, 158 Prozesskettenanalyse, 306 Put-to-Light, 50 PzW, 37 QTW, 106 Quellprogramm, 204 Queues, 244 Quittierung, 46 RDBS, 177 Realisierung, 323 Recovery, 184, 186 Referenzielle Integrit¨ at, 173 Regal – Beh¨ alter-, 78 – Block, 83 – Durchfahr-, 84 – Durchlauf-, 88 – Einfahr-, 84 – Fachboden-, 81 – Hoch-, 80 – Kragarm-, 82 – Paletten-, 77 – Satellit-, 85 – Turm-, 81 – Umlauf-, 86 – Verschiebe-, 86 – Waben-, 81 Regalbedienger¨ at, 107 Regel, 207 Relation, 177 Remote Function Calls (RFC), 334 Remote Procedure Call, 252 Reorganisation, 57 Repeater, 165 Resource-Allocation-Graph, 200 Ressource, 200 Retoure, 28 RGB, 107 RMI, 252 Roboter – Kommissionier-, 124 – Palettier-, 124 Rollback, 174 Rollen, 188

Sachverzeichnis Rollpaletten, 89 Router, 167 RPC, 252 RSA-Verfahren, 217 SAP NetWeaver, 334 Scheduler, 196 Scheduling, 59, 129, 144 Schedulingverfahren, 196 Schicht, 158 Schichtenmodell, 158 Schichtung, 224 Schnittstelle, 305 Schulung, 326 Schutzmechanismus, 177 Schwachstellenanalyse, 306 SCM, 16 Selektion, 181 sequenziell, 175 Seriennummer, 26 Server, 169 Services – Entity Services, 276 – Fassaden, 276 – Komponenten, 276 – Web Services, 276 Sicherheit – Authentiﬁzierung, 218 – Integrit¨ atssicherung, 217 – Public Key System, 217 – Sitzungsschl¨ ussel, 218 – Trustcenter, 219 – Verschl¨ usselung, 215 Sicherungskopien, 184 SMTP, 159 SNMP, 160 SOA, 251 SOAP, 252 Softwarearchitekturen, 221 Soll-Konzept, 307 Sorter, 113 – Kippschalen-, 121 – Quergurt-, 120 – Schiebeschuh-, 122 Sortiersystem, 113 Sourcecode, 204 Sperren, 55 Sperrkennzeichen, 55 SQL, 180 Stammdaten, 65 Stapel, 224 Stapler – Hochregal-, 101

– Kommissionier-, 101 – Leitsystem, 59 – Quergabel-, 102 – Schubgabel-, 100 – Schubmast-, 100 – Spreizenstapler, 99 – Vierwege-, 102 Statechart Diagram, 239 Stetigf¨ orderer, 91 Stored Procedures, 182 Strategie – Notfall, 327 Strategien – Auslagerung, 33 Supply Chain Management, 16 Switch, 167 Synchronisation, 195 Syntaxdiagramm, 207 T-Diagramme, 204 Tabelle, 177 TCP, 160, 169 TCP/IP, 160 TELNET, 159 TLS, 105 Totzeit, 40 Transaktion, 174 Transportleitsystem, 105 Transportverpackung, 20 Trigger, 174 TSP, 134, 139, 141, 147 UDP, 160 Umbuchung, 58 UML, 235 UML-Diagramme, 236 Umlagerung, 58 Umlaufregal, 86 Umschlagger¨ at, 97 Umstellung – direkt, 325 Umverpackung, 20 Unicode, 189 Universal Resource Locator, 171 Unstetigf¨ orderer, 91 URL, 171 USV, 183 Verbesserungsverfahren, 141, 153 Verbund, 181 Verdichtung, 58 Vererbung, 233 Verf¨ ugbarkeit, 326, 328 Verkaufsverpackung, 20

353

354

Sachverzeichnis

Verpackung, 19 Verschiebewagen, 106 Verschl¨ usselung, 177 Verschl¨ usselungsverfahren – symmetrisch, 215 – unsymmetrisch, 216 Verteilsystem, 113 Verteilwagen, 106 Verzeichnisse, 175 view, 180 virtuelle Maschinen, 205 VM, virtual java machine, 206 wahlfrei, 176 WAN, 165 Ware-zur-Person, 37 Warehouse Control System, 9 Warenannahme, 23 Wareneingang, 23 Warenwirtschafts/Produktionsplanungssystem, 225

Warenwirtschaftssystem, 9 WCS, 9 Web-Applikation, 248 Webservice, 252 Wechselseitiger Ausschluss, 195, 200 Wegzeit, 40 Wirtsmaschine, 205 Workﬂow Engine, 276 WzP, 37 XML – DTD, 211 – Schema, 211 Zeilenlager – Boden-, 75 – Regal-, 76 Zeitscheibe, 196 Zielfunktion, 127, 149 Zustandsdiagramm, 239

Warehouse Management: Organisation und Steuerung von Lager- und Kommissioniersystemen, 4. Auflage

Warehouse Management: Organisation und Steuerung von Lager- und Kommissioniersystemen (VDI-Buch)

Baukosten bei Neu- und Umbauten: Planung und Steuerung, 4.Auflage

Planung und Steuerung von Innovationsprojekten

Regierungszentralen: Organisation, Steuerung und Politikformulierung zwischen Formalitat und Informalitat

Abschlussprüfungen Bankwirtschaft, Rechnungswesen und Steuerung, Wirtschafts- und Sozialkunde, 3.Auflage

Produktionsplanung und -steuerung: Grundlagen, Gestaltung und Konzepte, 3.Auflage

Organisation und Welterschließung: Dekonstruktionen, 2. Auflage

Die Integration von Individuum und Organisation

Organisation und Entscheidung

Organisation und Strategie

Forsteinrichtung: Adaptive Steuerung und Mehrpfadprinzip

Werkzeugmaschinen 4: Automatisierung von Maschinen und Anlagen, 6. Auflage

Werkzeugmaschinen 4: Automatisierung von Maschinen und Anlagen 6. Auflage

Bausanierung: Erkennen und Beheben von Bauschäden, 4. Auflage

Management und Organisation von Wissensarbeit: Strategie, Arbeitssystem und organisationale Praktiken in wissensbasierten Unternehmen

Gabler Lexikon Logistik: Management logistischer Netzwerke und Flusse. 4. Auflage

Management von operationellen Risiken: Kategorisierung, Bewertung, Steuerung

Organisation und Projektmanagement (BA KOMPAKT)

Leistungsermittlungshandbuch für Baumaschinen und Bauprozesse, 4. Auflage

Eisenwerkstoffe - Stahl und Gusseisen 4. Auflage

Umbrien und die Marken, 4.Auflage

Springer Lexikon Kosmetik und Körperpflege, 4. Auflage

Depressionen verstehen und bewältigen 4. Auflage

Arbeitszeugnisse. Textbausteine und Tatigkeitsbeschreibungen 4. Auflage

Steuerung im Bildungswesen: Zur Zusammenarbeit von Ministerien, Schulaufsicht und Schulleitungen

Datenbanken: Konzepte und Sprachen, 4. Auflage

Tier- und Humanphysiologie: Eine Einführung, 4. Auflage

Zahlenwerk: Kalkulation, Organisation und Gesellschaft

Motivation und Handeln 4. Auflage (Springer-Lehrbuch)

Pädiatrische Notfall- und Intensivmedizin. Kitteltaschenbuch, 4. Auflage

Warehouse Management: Organisation und Steuerung von Lager- und Kommissioniersystemen, 4. Auflage

Warehouse Management: Organisation und Steuerung von Lager- und Kommissioniersystemen (VDI-Buch)

Baukosten bei Neu- und Umbauten: Planung und Steuerung, 4.Auflage

Planung und Steuerung von Innovationsprojekten

Regierungszentralen: Organisation, Steuerung und Politikformulierung zwischen Formalitat und Informalitat

Abschlussprüfungen Bankwirtschaft, Rechnungswesen und Steuerung, Wirtschafts- und Sozialkunde, 3.Auflage

Produktionsplanung und -steuerung: Grundlagen, Gestaltung und Konzepte, 3.Auflage

Organisation und Welterschließung: Dekonstruktionen, 2. Auflage

Die Integration von Individuum und Organisation

Organisation und Entscheidung

Organisation und Strategie

Forsteinrichtung: Adaptive Steuerung und Mehrpfadprinzip

Werkzeugmaschinen 4: Automatisierung von Maschinen und Anlagen, 6. Auflage

Werkzeugmaschinen 4: Automatisierung von Maschinen und Anlagen 6. Auflage

Bausanierung: Erkennen und Beheben von Bauschäden, 4. Auflage

Management und Organisation von Wissensarbeit: Strategie, Arbeitssystem und organisationale Praktiken in wissensbasierten Unternehmen

Gabler Lexikon Logistik: Management logistischer Netzwerke und Flusse. 4. Auflage

Management von operationellen Risiken: Kategorisierung, Bewertung, Steuerung

Organisation und Projektmanagement (BA KOMPAKT)

Leistungsermittlungshandbuch für Baumaschinen und Bauprozesse, 4. Auflage

Eisenwerkstoffe - Stahl und Gusseisen 4. Auflage

Umbrien und die Marken, 4.Auflage

Springer Lexikon Kosmetik und Körperpflege, 4. Auflage

Depressionen verstehen und bewältigen 4. Auflage

Arbeitszeugnisse. Textbausteine und Tatigkeitsbeschreibungen 4. Auflage

Steuerung im Bildungswesen: Zur Zusammenarbeit von Ministerien, Schulaufsicht und Schulleitungen

Datenbanken: Konzepte und Sprachen, 4. Auflage

Tier- und Humanphysiologie: Eine Einführung, 4. Auflage

Zahlenwerk: Kalkulation, Organisation und Gesellschaft

Motivation und Handeln 4. Auflage (Springer-Lehrbuch)

Pädiatrische Notfall- und Intensivmedizin. Kitteltaschenbuch, 4. Auflage

Recommend Documents