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 2514 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. Auflage ¨ 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ärkt 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ägern 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 Zugriff 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. Auflage Heutige Lager- und Distributionssysteme stellen äußerst komplexe Knoten in den Wertsch¨ opfungsketten dar und unterliegen einer Vielzahl von Zeit-, Kosten- und Qualit¨ atsanforderungen. Der effiziente Betrieb eines solchen Systems ist f¨ ur jeden Verantwortlichen eine stete und große Herausforderung. Durch die Fortschritte in der Rechner- und Steuerungstechnik geprägt, sind heute Steuerungs- und Verwaltungssysteme (Warehouse Managementsysteme, WMS) verf¨ ugbar, die einen effizienten Betrieb unter den zahlreichen Anforderungen u oglichen. Gleichzeitig sind diese Systeme ¨ berhaupt erst erm¨ zwangsl¨ aufig zu einem Komplexit¨ atsgrad gereift, der die Anwender gelegentlich auch u ¨ berfordert. Die Unterschiedlichkeit der angebotenen Lösungen 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önnen. ¨ An dieser Stelle soll das Buch Uberblick verschaffen und helfen, die richtige Entscheidung zu treffen. Es richtet sich unter anderem an Mitarbeiter, die mit der Auswahl und Spezifikation 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 geschaffen 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 lauff¨ 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öglicht die dazugehörige 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 einfließ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 findet 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äftige 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öglich 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 Materialfl¨ usse, die zwischen den unterschiedlichsten Logistikknoten stattfinden, u origen Informationsströme bis ¨ber die dazugeh¨ hin zum Warenumschlag in Industrie, Handel und öffentlichen Einrichtungen auf. Dabei steuert sie im Rahmen des Supply Chain Managements den gesamten Materialfluss 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 Begriffe 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 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Konfiguration 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 Unified 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ät . . . . . . . . . . . . . . . . . . 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 Materialfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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-off: WMS-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Projektmanagement/Qualit¨ atssicherungsmaßnahmen . . . . . . . . 8.3 Anforderungsdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Ist-Aufnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Schwachstellen-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 Entwicklung Soll-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Erstellung der Ausschreibungsunterlagen . . . . . . . . . . . . . . . . . . 8.4.1 Definition 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 Pflichtenhefterstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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: effizient 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 Warenfluss zwischen Produzenten und Verbrauchern dar. Die im Rahmen der Warenvorhaltung und -verteilung anfallenden Tätigkeiten 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 betreffen beispielsweise die Layoutierung des Systems, die Auswahl und Dimensionierung der förder- und lagertechnischen Gewerke oder die Gestaltung der physischen Schnittstellen zu angrenzenden Systemen. Die Behandlung dieser Fragen ist Gegenstand unz¨ ahliger Ver¨ offentlichungen (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) zusammenfließen. Im Blickpunkt dieses Buches stehen speziell Fragen der effizienten 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 effizientes 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ät (Umfang und Dynamik) der Abl¨ aufe praktisch nur durch Einsatz rechnergest¨ utzter Managementsysteme beherrschbar wird. Die mit den zahlreichen Funktionalitäten versehenen Steuerungssysteme reifen aber auch ihrerseits zu immer komplexeren und schwierig zu fassenden Systemen. Eine große Schwierigkeit besteht deshalb in der Identifizierung und Anpassung eines geeigneten Systems an ein vorhandenes Anforderungsprofil. 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älle im Betrieb sind nicht nur kostentr¨ achtig, sondern können 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 schaffen. Es geht in diesem Buch daher nicht nur um die Frage, wie Lager- und Distributionssysteme technisch gestaltet werden können, sondern auch darum, wie sie im Zusammenspiel der Systeme sinnvoll betrieben werden können. Das f¨ ur diese Umsetzung erforderliche Wissen und Handwerkszeug soll durch ¨ dieses Buch bereitgestellt werden. Es soll Ubersicht schaffen, 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äufig negative Eigenschaften verbunden werden, ist die Lagerung von Waren in der Praxis aus vielf¨ altigsten Gr¨ unden in den meisten Bereichen unumgänglich. 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 mehrstufiger 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ähigkeit beschreiben lässt. Insbesondere bei großen r¨ aumlichen Distanzen zwischen der Produktentstehung und Konsumierung, bei denen gegebenenfalls noch Prozesse der Zollabfertigung stattfinden, 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öherfrequenten Auftragserteilung geringerer Teilmengen und die gängige 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 effizient 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ät 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ängst gehen die Anforderungen an ein Lager u ¨ ber die kurzfristige Bereitstellung eines einzelnen

4

1. Einleitung

Produktes oder Artikels hinaus. Einerseits wächst die Variantenvielfalt durch die aus Sicht des Produktmarketings reizvolle Produktdifferenzierung 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öglichst späten 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äte Anbringung von Verkaufsinformationen (Label etc.) oder den Aufbau von Aktionsständen zu verkaufsf¨ ordernden Maßnahmen, erfahren. Transportkostenreduktion: Einer der Hauptgr¨ unde zur Bestandsbildung bleibt das Ziel, Transportkosten zu optimieren und sprungfixe Kostensätze 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 ineffizienter als die der konsolidierten Menge. Dadurch lassen sich wiederum vorhandene Kapazit¨ aten (Anzahl von Ladetoren, Rangierfl¨ achen etc.) vorteilhafter nutzen. Insbesondere im Bereich des Einzelhandels fehlen die Kapazitäten 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ängst 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ößen bestehen. Innerhalb der Produktion sind einzelne Produktionsphasen durch verschiedenartige Prozesszeiten und Ausbringungsmengen oder unregelmäßige Zu- und Abg¨ ange zwischen Bereichen gekennzeichnet. Die Vermeidung von Leerlaufzeiten erfordert wiederum die Pufferung von Halbfertigprodukten zur gleichm¨ aßigen Nutzung von Produktionsanlagen oder -prozessen. Bestimmte Produktionsprozesse unterliegen dar¨ uber hinaus zeitlich nicht beeinflussbaren 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ßendegressionseffekte auf der Zulieferseite, denen ¨ber Gr¨ die Kosten der Lagerhaltung, aber auch weitere Komplexitätskosten wie z.B. Administrationskosten (Durchf¨ uhrung der Bestellung, Preisverhandlungen) gegen¨ uberstehen. Lagerung als Prozessschritt: Bei verschiedenen Produkten oder Abläufen stellt die Lagerung einen elementaren Prozess der Wertschöpfung oder -steigerung dar (z.B. durch Reifung oder spekulative Absichten) und wird damit zu einem Teil des Produktionsablaufes. Wie sich aus dieser Auflistung entnehmen lässt, zwingen nicht allein Gr¨ unde der Produktionslosgr¨ oßenoptimierung oder Einkaufsmengenrabattierung zur Bestandsvorhaltung, sondern insbesondere auch ein Geflecht miteinander gekoppelter Prozesse, die zur Ablaufoptimierung der Pufferung 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, effizienten 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ötigt 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üßerer Einfl¨ 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ändigen Ver¨ anderungen in Bezug auf Mengenstr¨ ome, Kundenauftragsstruktur, Artikelvielfalt und -form usw. • vieles mehr In solchen Systemen resultiert die Komplexität aus der Systemgröß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äger von der arbeitsaufw¨ andigen Analyse und Prognostizierung von Aufwänden und Erlösen der hauseigenen Logistik befreit werden. [5] Neben den offensichtlichen 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 ineffiziente Strukturen verdeckt. Bei komplexen Systemen besteht dar¨ uber hinaus durch die Vielzahl paralleler Transaktionen und Abläufe 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äufen, Beständen und Auftr¨ agen. Um den allgemein gewachsenen Anforderungen an das zeitliche Reaktionsverm¨ ogen und die logistische Leistungsfähigkeit der Warenverteilsysteme bei konsequenter Minimierung der Best¨ ande und Optimierung der Kosten gerecht zu werden, bedarf es strukturierter, transparenter Abläufe 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 effizienten WMS ist in diesem Zusammenhang die Vermittlung von Vertrauen und Sicherheit in das F¨ uhrungs- und Kontrollsystem. Eine wesentliche Ursache f¨ ur die Anhäufung 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ändigen Recherchen nach Bestandsmengen, Lagerorten oder Auftragsstati. Ein transparentes System beginnt bei der Datensicherheit und schafft 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äufe bieten die wesentliche Grundlage f¨ ur eine kontinuierliche Systemoptimierung. Neben der Kontrollier- und Steuerbarkeit der Prozesse wird auch eine h¨ ohere Reaktionsgeschwindigkeit und Flexibilität erreicht. Schnelle Ortung von und Zugriff 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 Begriff Warehouse Management gew¨ ahlt, obwohl hierzu der seit langem eingeprägte deutsche Begriff Lagerverwaltung existiert. Ein Großteil der hier behandelten Inhalte betrifft die Steuerung und Verwaltung von Lagersystemen; demnach scheint der Begriff Lagerverwaltungssystem viel angebrachter. Bei genauerer Betrachtung zeigt sich jedoch, dass die Begriffe Warehouse Management und Lagerverwaltung nicht austauschbar sind. Ein Lagerverwaltungssystem beschreibt im Kernbereich zunächst 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ördermittelsteuerung und -disposition geh¨ oren nach dieser Betrachtungsweise auch umfangreiche Methoden und Mittel zur Kontrolle der Systemzustände und eine Auswahl an Betriebs- und Optimierungsstrategien zum Leistungsumfang. Auf ein derartiges, u ¨ bergreifendes Verwaltungs- und Managementsystem trifft der deutsche Begriff Lagerverwaltungssystem nicht mehr zu. Es m¨ usste also exakter als innerbetriebliches Materialflusskontroll-, -steuerungs- und -optimierungssystem oder Kontroll-, Steuerungs- und Optimierungssystem f¨ ur den (innerbetrieblichen) Materialfluss bezeichnet werden. F¨ ur eine klare Abgrenzung wird daher im Folgenden der auch im deutschen Sprachgebrauch eingeprägte und pr¨ agnante Titel Warehouse Management als Synonym f¨ ur ein u ¨ bergreifendes Instrumentarium Verwendung finden. 1

In der Tat werden auch heutzutage manuell gef¨ uhrte Systeme in bestimmten Bereichen ¨ außerst effizient 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 finden 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 Materialflusses und der Kommissionierung (Warehouse Control Systeme (WCS) und Materialflussrechner (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öglichst effizient einzusetzen. Materialflussrechner (abgek. MFR, engl. Material flow computer) Die Umsetzung teil- oder vollautomatischer Materialflussoperationen erfolgt im MFR der die Reihenfolge koordiniert, ggf. auch optimiert, und die Quelle-Ziel-Beziehungenkontrolliert, in der einzelne Aufträge, 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ände 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äufe beispielhafte Funktionen, Aktionen und Kommunikationswege dargestellt. Die einzelnen Systemhierarchien werden durch vertikale Linien verkörpert. 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 Materialflussrechnerebene die Optimierung einzelner Abl¨ aufe. Mit der Ann¨ aherung an die physische Ebene des Materialflusses 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 Materialflussoperationen angesiedelt. Bestimmte Steuerungsfunktionen erfolgen autark im WMS ohne R¨ uckgriff auf unterlagerte Ebenen. Diese Funktionen umfassen beispielsweise manuelle Abläufe. So können nach einer Wareneingangskontrolle f¨ ur Ladeeineinheiten Label generiert werden, anhand derer ein Staplerfahrer die Ladeeinheiten und den Zielort identifiziert und den Transport, beispielsweise zum I-Punkt (Identifikationspunkt), durchf¨ uhrt. Damit ist dieser Prozess abgeschlossen. Finden dagegen automatische oder teilautomatische Materialflussoperationen 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ächern 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ätes 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äten 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äftskundenbereich (Businessto-Business, B2B) handeln. Der Kunde kommuniziert u ¨ber das so genannte Shopsystem und kann nicht nur Produktkataloge einsehen und darauf basierend Aufträge erteilen, sondern auch Warenk¨ orbe anlegen und an Auktionen teilnehmen sowie aktiv Auktionen durch entsprechende Ausschreibungen durchf¨ uhren. Das Shopsystem kann durch einen unabhängigen Shop-Betreiber unterhalten werden. Zu den Funktionen innerhalb des Shopsystems zählt auch die Pr¨ ufung der Kunden, respektive der Kundenbonität, 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ätigung an den Kunden an das WWS des Distributionszentrums“ (das repräsentiert 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 Pflege 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önnen 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 Informationsfl¨ 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 Begriff WMS im vorangegangenen Kapitel definiert und im Kontext eingeordnet wurde, f¨ uhrt das folgende Kapitel 2 in das Management von Lager- und Distributionssystemen ein und zeigt dazu die Abläufe aus Sicht des Materialflusses auf, d.h. ein Lagersystem wird anhand der typischen Materialfl¨ usse und Abl¨ aufe beschrieben. Das Augenmerk liegt dabei

14

1. Einleitung

auf der detaillierten und strukturierten Darstellung der Abläufe, 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, definiert. 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ählen 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 Anforderungsprofil 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¨ aufig ¨ ahnlich, da diese Systeme wiederum Teil einer u ¨ bergreifenden Kette des Warenflusses sind. Mit dem Ziel der Schaffung einer einheitlichen Basis werden im Folgenden die wesentlichen Randbedingungen, Grundlagen und Abl¨ aufe herausgearbeitet. Ein effizientes Lagermanagement setzt die Ber¨ ucksichtigung dieser Rahmenbedingungen und der logistischen Einheiten voraus, um Abläufe 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 effizienten Betrieb entscheidenden Funktionen identifiziert. 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 Begriff Logistik Die Logistik beschreibt einen systemischen Ansatz zur umfassenden Optimierung von Fließsystemen, dazu z¨ ahlen insbesondere Materialflusssysteme, u ¨ ber einzelne Systemgrenzen hinaus. Es existieren je nach Ausrichtung verschiedenste Definitionen der Logistik, auf die hier aber nicht näher eingegangen werden soll, da sie nicht im Hauptaugenmerk der Betrachtungen liegen. Der Kern einer Reihe von Definitionen 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


Entsprechend dem materialflussbezogenen 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 Simplifizierung 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 Materialfluss und Informationsfluss 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 Materialfluss und Informationsfluss aufeinander abgestimmt werden. In vielen Fällen bedeutet dies auch, einen dem physischen Materialfluss vorauseilenden Informationsfluss zu schaffen, der z. B. die Bereithaltung entsprechender Kapazitäten an Förder-, 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 Warenfluss eine Reihe von Faktoren, die zu mehrstufigen 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änomen, auch als Bullwhip- oder Peitscheneffekt bekannt, wurde Ende 1950 von Forrester beschrieben, und erst heute, mit der Verf¨ ugbarkeit leistungsfähiger Rechenund Kommunikationssysteme, entstehen aussichtsreiche Ansätze 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 betrifft. 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¨ aufig 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ößendegressionseffekten (Economies-of-scale-Effekte) 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äsenz oder durch Verk¨ urzung von Lieferzeiten. Viele Kontraktlogistiker besitzen eine solche Pr¨ asenz per se, ein Aufbau aus eigenen Kräften lässt sich dagegen wirtschaftlich oftmals nicht darstellen. Als Beispiel sei der Aufbau einer EDI-L¨ osung mit sicherer Kundenanbindung zur Erstellung geforderter Lieferavise genannt; • Nutzung tariflicher 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ände in ein externes Lager des Kontraktlogistikers u uhrt, wo sie nun neben Beständen 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

Efficient 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


der Aktivit¨ aten eine elementare Voraussetzung f¨ ur den Betrieb, um den Kunden die Prozesse nachvollziehbar pr¨ asentieren zu können. Weitaus anspruchsvoller gestalten sich L¨ osungen mit verschiedenen Kunden in einem System. Hier sind scheinbar gleichwertige Waren völlig 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ächtliches 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 finden. E-Logistics Ein Bereich, der in den letzten Jahren zunehmend an Bedeutung gewinnt, ist die E-Logistics. Sie l¨ asst sich definieren als ein ¨ Uberbegriff f¨ ur die Planung, Steuerung und Kontrolle des Waren-, Informations- und Geldflusses entlang der gesamten Supply Chain u offentliche 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 Materialflusssysteme 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 Fulfillment) haben den Niedergang etlicher ECommerce-Firmen zur Jahrtausendwende zumindest beschleunigt. Es zeigt sich aber auch, dass klassische Distributionssysteme den Anforderungen der E-Logistics h¨ aufig nur ungen¨ ugend gerecht werden. Der Schl¨ ussel liegt in der hochflexiblen 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-


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 effizient 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änderung 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 finden (aber nicht immer stringent genutzt werden). Jede Betrachtung von Materialfl¨ ussen setzt daher zwangsläufig bei den Mengen und Eigenschaften der Waren und G¨ uter an. Die Akteure oder Entscheider an den Endstellen solcher Materialfl¨ 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ößen) zu produzieren und sie m¨ oglichst effizient, das bedeutet im Allgemeinen in einer möglichst geringen Anzahl an Arbeitsschritten, zum n¨ achsten Abnehmer der G¨ uter zu transportieren. Ein wichtiger Aspekt ist in diesem Zusammenhang auch die Konsolidierung der Warenfl¨ usse und Prozesse. Die Logistik- und Materialflusssysteme von Produzenten sind in der Regel auf die effiziente Handhabung großer Mengen weniger Artikel ausgerichtet. Daher werden u ¨ ber den mehrstufigen Handel die hier erforderlichen Gr¨ oßeneffekte (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 Warenfl¨ uter vor den Einfl¨ ussen w¨ zierte G¨ ahrend der Transport-, Umschlag- und Lagerprozesse (TUL-Prozesse) so zu sch¨ utzen, dass keine qualitative Beein-

20


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ällen, z. B. bei Gefahrg¨ utern, nat¨ urlich auch die Umwelt und speziell die beteiligten Mitarbeiter vor dem Gut sch¨ utzen. Um eine effiziente Handhabung während dieser Prozesse zu erm¨ oglichen, soll eine Verpackung Lager- und Transportvorgänge vereinfachen, beispielsweise durch Schaffung einheitlicher, stapelbarer oder förderfähiger Einheiten. Insbesondere im Bereich des Einzelhandels soll die Verpackung eine verkaufsf¨ ordernde Wirkung erzielen. Dem Kunden bzw. Verbraucher soll sie ggf. eine Verwendungsfunktion offerieren, beispielsweise durch mehrfache Verschließbarkeit oder sogar durch eine einsatzfremde Benutzung nach Verbrauch der eigentlichen Ware. Schließlich spielt die Identifikations- und Informationsfunktion eine Schl¨ usselrolle sowohl bei der Identifikation der Ware innerhalb des Materialflusses (beispielsweise durch aufgedruckte Barcodes) als auch bei Offerierung der Waren in den Verkaufsregalen. Diese Vielzahl von Anforderungen, die zu teilweise gegenläufigen 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 differenziert: Transportverpackungen: sch¨ utzen Waren während 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¨ ucknahmeverpflichtung der Altverpackungen vom Kunden verpflichtet. 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¨ aufig 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ätigkeiten in-


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önnen. Gängige Zielsetzungen, die zur Bildung Logistischer Einheiten f¨ uhren, sind in Tabelle 2.1 aufgef¨ uhrt. In der Idealvorstellung wird nur eine Logistische Einheit gewählt bzw. geformt, die unver¨ andert die gesamte Transportkette durchläuft, 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ällen wirklich umsetzen. Insbesondere in mehrstufigen Versorgungsketten besteht die Tendenz zu immer kleineren Einheiten (s. dazu auch Kapitel 1, S. 3). Die Ladeeinheitenbildung beschreibt das effiziente 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


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

Aus materialflusstechnischer 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 Differenzierung 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älter). • Entnahmeeinheiten sind die Einheiten eines bestimmten Artikels, die durch den Kommissionierer beim Kommissioniervorgang gegebenenfalls durch mehrere Einzelzugriffe entnommen werden (z. B. Gebinde). • Greifeinheiten (auch Pickeinheiten) umfassen diejenige Menge an Artikelbzw. Verpackungseinheiten, die ein Kommissionierer im Mittel mit einem Griff 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¨ aufig 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öß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 Materialfluss 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


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

Diese aus Sicht des Materialflusses erstrebenswerte Realisierung hängt wiederum von vielen Einflussgr¨ oßen wie beispielsweise Sendungsgröße und -wert, der Lieferdistanz und allgemeinen Verkehrssituation, behördlichen Arbeitszeiten (z. B. Zollabfertigung) und nat¨ urlich der Position des empfangenden Unternehmen ab und l¨ asst sich in der idealtypischen Form nur eingeschränkt realisieren. Warenannahme Die Warenannahme ist der erste wichtige Schritt im Materialfluss eines Lagers mit der Entlastung des Spediteurs. Basierend auf dem Lieferavis l¨ asst sich die eintreffende Lieferung mit der Bestellung abgleichen.


25

Dabei erfolgt eine Buchung des Frachtbriefes gegen das Avis. Es schließt sich ¨ die vorl¨ aufige 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öß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¨ aufig mit dem Ziel einer besseren Kontrolle der Hofverkehre. Zu diesem Zweck werden Hofmanagementsysteme (auch Stock- and Yardmanagementsysteme) eingesetzt, die einen koordinierten Verkehrsfluss auf dem Werksgel¨ ande und insbesondere die Minimierung unnötiger 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 Pufferfl¨ achen, die Auswahl geeigneter Annahmestellen (z. B. Ladetore oder -buchten) oder der Ausdruck der firmeninternen Label zur innerbetrieblichen Identifikation der G¨ uter. Aus materialflusstechnischer Sicht ist der Einsatz eines betriebs¨ ubergreifenden Kennzeichnungssystems anzustreben, wie es ähnlich 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 Materialflusses 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 eingetroffenen 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 firmeninternen Regelungen eine eingehende Pr¨ ufung der Beschaffenheit der Artikel durch die Qualitätssicherung. Diese Pr¨ ufungen reichen vom Sichtvergleich bis zu Laborpr¨ ufungen einzelner Stichproben oder vollst¨ andigen 100%-Kontrollen. Mängelbehaftete 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ändigung der Artikelstammdaten (vgl. Tabelle 2.13) erforderlich. Eine sorgfältige Erstellung und Pflege dieser Stammdaten ist die wesentliche Voraussetzung f¨ ur

26


eine Reihe von Kontroll- und Optimierungsfunktionen im weiteren Materialflussprozess. Die Kenntnis des exakten Gutgewichtes ist erforderlich f¨ ur Pr¨ ufprozesse im Rahmen der Kommissionierung. So können Kundenaufträge auf Vollst¨ andigkeit gepr¨ uft werden. Spezielle automatische Geräte wie Kommissionierroboter ben¨ otigen diese Informationen teilweise zur Verifizierung 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 Materialflussprozesses. Lagerf¨ acher eines Regallagers k¨ onnen mit unterschiedlichen Lagerfachhöhen auf das Artikel- bzw. Lagergutspektrum angepasst werden, wodurch die Raumnutzung des Lagerbereiches optimiert werden kann. Entsprechend der Größe eines Kommissionierauftrags k¨ onnen des Weiteren optimale Versandbehälter 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öß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äte, 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äß 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önnen Auslagerpriorit¨ aten bestimmt oder Umlagerungen veranlasst werden.


27

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

Bildung der Lagereinheiten In vielen Lager- und Materialflusssystemen sind aus Gr¨ unden der Transportsicherheit oder Handhabung spezielle Ladehilfsmittel oder Beh¨ alter im Einsatz. Hierzu zählen 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ällen eine Anpassung an das firmeninterne Materialflusssystem durch Umf¨ ullen in firmeninterne 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önnen beispielsweise besch¨ adigte Paletten Toleranzmaße u ¨berschreiten und dadurch auf bestimmten F¨ orderabschnitten stecken bleiben. Deshalb werden solche Einheiten z. T. auf firmenspezifische Lagereinheiten (hochwertige Standardpaletten ohne Besch¨ adigungen) umgesetzt. Dabei wird oft ein schlechterer Lagerraumnutzungsgrad in Kauf genommen und die komplette Ladeeinheit auf eine firmeninterne Palette gesetzt. Dieser Schritt ermöglicht gleichzeitig die Nutzung dauerhafter Kennzeichnungselemente an den Paletten zur Mate-

28


rialflusssteuerung. Werden automatische Lagertechniken mit sehr hohen dynamischen Bewegungsanteilen eingesetzt, kann eine zusätzliche 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ängiges 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äten voraussetzt. Bei späteren 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äuft in einem durchg¨ angigen Prozess die Aufnahme einer Lagereinheit und die direkte Verbringung an den finalen Lagerbereich inklusive der Einlagerung oder Abgabe der Lagereinheit ab. Dagegen erfolgt in größ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 spezifischen Teilschritten besteht.


29

Verteilung auf Lagerbereiche In einem ersten Schritt (Backorders) wird gepr¨ uft, ob die eingetroffenen Wareneing¨ ange zur Vervollständigung von Auftr¨ agen gebraucht werden, die sich bereits im Warenausgang oder Versand befinden, so dass eventuell ein direkter Transport an die Verbrauchsstellen oder in den Versandbereich erforderlich ist. Dieser Prozess wird auch als Durchlagerung bezeichnet. Daneben findet auch der Begriff Cross Docking Verwendung, womit exakterweise ein umfangreicheres Konzept gemeint ist (vgl. S. 69), weshalb die Bezeichnung an dieser Stelle zwar gebräuchlich, 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örderer (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 Pufferfl¨ 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önnen 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 Materialflusses, wiederum insbesondere bei gr¨ oßeren Materialflusssystemen. 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ässt sich eine l¨ uckenlose Dokumentationskette aufbauen und u ¨ ber ein Tracking and Tracing eine schnelle Ortung einzelner Einheiten realisieren. Identifikation Sofern die Identit¨ at der Lagereinheit noch nicht bei der Wareneingangspr¨ ufung erfasst wurde, findet nun spätestens die Identitätskontrolle am so genannten I-Punkt statt. Dies geschieht häufig 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 Materialfluss und Informationsfluss synchronisiert. Im Falle des Einsatzes automatischer Lagersysteme geschieht dies logischer-

30


Abbildung 2.4. Identifikation 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ähigkeit kontrolliert werden. Dazu zählt 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örperliche 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 Einfl¨ 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 spezifische Lagerfachdimensionen und Traglasten


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ängige 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äßige Lastverteilung durch die Systemsteuerung zu realisieren. Ein generelles Bestreben ist die möglichst gute Nutzung des vorhandenen Lagervolumens. Daher ist im Fall stark unterschiedlicher H¨ ohen der Ladeeinheiten eine Stufung der Lagerfachhöhen 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äglichkeiten 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äß 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ägern

32


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 Verifikation durch den Bediener, z. B. durch unmittelbare Erfassung von Lagergut und Lagerplatz. G¨ angige Systeme disponieren zur Sicherstellung dieses Schritts erst nach erfolgter Verifikation den nächsten 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ächst 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.


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öschung entsprechender Reservierungen. F¨ ur eine kontinuierliche Materialflussverfolgung sollte die Ladeeinheit, respektive der Bestand, an den nachfolgenden Empfänger oder auf das Transportmittel verbucht werden (in diesem Fall wird das Transportmittel logisch wie ein Lagerplatz behandelt).

34


2.2.4 Konsolidierungspunkt Der Konsolidierungspunkt ist eine Stelle zur Identifizierung abgefertigter Einheiten an Schl¨ usselpositionen des Materialflusses. Insbesondere in Systemen mit stochastischen Einfl¨ ussen, beispielsweise mit manuellen Arbeitsabläufen, 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 Informationsfluss. Dabei wird generell der Auftragsstatus aktualisiert, d. h. im Fall des Lagersystems wird der Status des Auslagerungsauftrags fortgeschrieben. Andererseits erfolgen materialflusstechnische 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örige 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örder- und lagertechnischen Systeme zum Einsatz. Die enge Verflechtung 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äufe definiert, 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ängigerweise die drei Bereiche • Materialflusssystem, • Organisation und • Informationsfluss unterschieden. Materialflusssystem Bei der Gestaltung des Materialflusses eines Kommissioniersystems steht zun¨ achst die Frage im Vordergrund, wie Kommissionierer und Artikel zur


35

Durchf¨ uhrung der Vereinzelung r¨ aumlich und zeitlich effizient 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 findet keine unmittelbare Bewegung statt, da die Vereinzelung – analog zur Funktionsweise eines Zigarettenautomaten – innerhalb der Maschine selbst erfolgt und von dort zur Sammelstelle gefördert wird (z. B. bei automatischen Kommissionieranlagen wie Schachtkommissionierern). Nach [24] setzt sich die physische Kommissionierung aus folgenden materialflusstechnischen 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ösungen 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 Klassifizierungen 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 Definition 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är, 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 Definition befinden sich bei statischer Bereitstellung die zu greifenden Teile in Ruhe, bei dynamischer Bereitstellung erfolgt der Entnahmevorgang auf das bewegte Teil.

36


Tabelle 2.5. Grundfunktionen des Materialflusssystems 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


37

Eng mit dieser Problematik ist die Differenzierung 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 zugegriffen 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 befindlichen Gutes erfolgt, praktisch nicht bekannt sind, wird folgende Bedeutung zugrunde gelegt: Die Differenzierung in statische und dynamische Bereitstellung klärt, ob die Bereitstelleinheit zur Durchf¨ uhrung einer Entnahme fördertechnisch bewegt werden muss. Und: Die Differenzierung in zentrale und dezentrale Bereitstellung definiert den Ort der Durchf¨ uhrung der Entnahme. Bei der zentralen Bereitstellung findet die Entnahme an einem räumlichen festen Punkt, bei der dezentralen Entnahme an verschiedenen räumlichen Punkten statt. Zur Verdeutlichung dieser Unterscheidungen dienen die Beispiele in Tabelle 2.6. Wie diese Auflistung 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ällen verschwimmt die Bezeichnung Ware-zur-Person (WzP) und es kann nicht mehr eindeutig nach WzP bzw. PzW differenziert 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ördermittel bzw. die Sammeleinrichtung. Befindet sich das Fördermittel 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ält sich

38


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ägungsformen liefert Tabelle 2.7. Weitere Unterscheidungsmerkmale betreffen 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ät 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-


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. effizienter realisierbar, je höher der Ordnungszustand der Einheiten ist. W¨ ahrend auf Basis dieser Klassifizierungen durchaus grundsätzliche Eignungsparameter und Charakteristika abgeleitet werden können, ist die Entscheidung, welches System f¨ ur einen gegebenen Anwendungsfall optimal ist, praktisch nur im Einzelfall im Rahmen einer Systemplanung zu treffen. Organisationsformen Einen wesentlichen Einfluss auf die Effizienz 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ängigerweise 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 Definition 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ältige ¨ Analyse des Sortiments und der Auftragsstruktur voraus. Ublicherweise leiten sich daraus variierende Anforderungen an Kapazität, Leistung und Eigenschaften des Bereitstellsystems ab. Solche Anforderungen resultieren u. a. aus • Volumina, Gewichten und Abmessungen der Bereitstelleinheiten, • Umschlagh¨ aufigkeiten bzw. Zugriffsh¨ aufigkeiten pro Artikel,

40

• • • •


mittleren Entnahmemengen pro Artikel pro Zeiteinheit, Zugriff, h¨ aufigen 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ägt 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 Identifizieren, 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 beeinflusst 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ächsten 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.


41

Die erste Optimierungsm¨ oglichkeit besteht in der Sammlung und gleichzeitigen Bearbeitung mehrerer Kundenaufträge, was als auftragsparalleles Kommissionieren oder Sortieren während 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 (Identifizierung des nächstliegenden Artikels) oder Zur¨ uckgehen vermieden werden. In großen Systemen ist es wenig sinnvoll, dass ein Kommissionierer mit dem Auftrag das gesamte Kommissioniersystem durchläuft. In diesem Fall m¨ usste der Kommissionierer sich nicht nur in allen Bereichen gleichermaßen auskennen, sondern auch zwangsl¨ aufig 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 befindlichen 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önnen, sofern keine ¨ berbr¨ Artikel in diesen Zonen zu entnehmen sind. Alternativ dazu k¨ onnen auch die Kundenaufträge in Teilaufträge 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öglichen Zeitgewinn steht wiederum der Aufwand der Vorbereitung der Aufträge und die Notwendigkeit der Zusammenf¨ uhrung der Teilaufträge entgegen. Während die Auftragsaufbereitung weitgehend rechnergest¨ utzt ablaufen kann, sind zur Zusammenf¨ uhrung der Teilauftr¨ age ggf. Puffer-, 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 einstufig 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 zweistufig durchgef¨ uhrt. Durch diese Maßnahme können alle in einer größeren Auftragsmenge auftretenden identischen Artikel in einem Kommissioniervorgang gepickt werden, d. h. die Bereitstelleinheit ist nur einmal anzusteuern

42


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äge 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, zweistufige Kommissionierung) erbringt hohe Kommissionierleistung, setzt allerdings folgende Eigenschaften voraus: • gute F¨ orderf¨ ahigkeit der Entnahmeeinheiten mit ähnlichen Dimensionen und Handhabungseigenschaften, • rechnergest¨ utzte Auftragsaufbereitung und Zusammenf¨ uhrung zur Sortierung der Entnahmeeinheiten und Zuteilung auf Kundenaufträge, • 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 flexibler 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önnen. Darunter fallen beispielsweise T¨ atigkeiten wie • Einlastung bzw. Behandlung von Fixtermin- und Eilaufträgen, • Auftragseinschleusung in Abh¨ angigkeit von der momentan verf¨ ugbaren Kommissionierleistung, vom aktuellen Arbeitsfortschritt oder vom Systemstatus, • Zuteilung von Kommissionierern zu Zonen oder Tätigkeiten (Ressourcenmanagement), • Auslösung Nachschub. Dabei finden prinzipiell alle Maßnahmen Anwendung, die in Kapitel 4 behandelt werden.


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ät 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äge muss sicher und effizient 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öglichkeiten (telefonisch, ¨ Internet), per Fax, DFU, • Zeitpunkt der Auftragserteilung dem Kundenwunsch entsprechend (=beliebiger Zeitpunkt), • direkte Auskunft der Artikelverf¨ ugbarkeit und eines möglichen Liefertermins, • M¨ oglichkeit der Beratung, • gegebenenfalls Erfassung von Sonderw¨ unschen. Demgegen¨ uber steht die Zielsetzung einer kosteneffizienten und fehlerresistenten Auftragsannahme. Dabei gilt es insbesondere aus Kapazitätsgr¨ 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 Einfluss besitzt bei allen verschiedenen Erfassungskanälen die aktuelle Verf¨ ugbarkeit lieferbarer Artikel. Dazu ist eine präzise 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äge sind zur Durchf¨ uhrung einer effizienten Kommissionierung, mit wenigen Ausnahmen bei sehr

44


kleinen Systemen, ungeeignet. In Abh¨ angigkeit vom gewählten Organisationstyp der Kommissionierung fallen folgende Tätigkeiten an: • Vervollst¨ andigen der Auftr¨ age mit den zur Kommissionierung relevanten Informationen (Lagerort, Artikelnummer, Sammelbehälter), • 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ät, 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¨ aufig 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önnen. 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öglicher 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 finanzielle 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äge erfasst werden, um darauf aufbauend Folgeauftr¨ age einzuschleusen. Deshalb wird dieser Pr¨ ufvorgang auch als Quittierung des Auftrags bzw. der Entnahmeeinheit bezeichnet.


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ät kann sinnvoll nur durch rechnergest¨ utzte Verwaltungssysteme erfolgen. Bei zonenparalleler Kommissionierung muss die Ursprungsliste zwangsläufig 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ängige 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önnen 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ässt 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 Identifizierung der n¨ achsten Entnahmeposition und dem Handling der Liste und insbesondere in der großen Inflexibilit¨ 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ände erfordern (dazu z¨ ahlen dynamische Batchsteuerungsverfahren in der zweistufigen Kommissionierung), nicht einsetzbar.

46


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öglichkeit 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öglichkeiten 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ätigen, woraus Zählfehler 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öglichkeiten ist die Ableitung unmittelbarer Zusammenh¨ ange auf die Fehlerresistenz bei unterschied¨ lichen Ubermittlungsverfahren nicht m¨ oglich. Einer aktuellen Untersuchung 4

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


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älter an der Schnittstelle zum Versand. Dabei bewegt er sich schleifen- oder mäanderförmig durch die Regalanordnung (Schleifenstrategie). Je nach Pickliste können auch einzelne Gassen u ¨bersprungen oder die Gassen nur zu einem Teil begangen werden (Stichgangstrategie). Entsprechend der zuvor definierten Terminologie liegt damit eine einstufige, 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, findet die Kommissionierung nun in der Regalfläche

48


B

A b g a b e Abbildung 2.5. Einstufiges Kommissioniersystem Person-zur-Ware

eines Hochregals statt. Dadurch ergibt sich eine bessere Raumnutzung und im Allgemeinen ein geringerer Wegzeitanteil durch die höhere Bewegungsdynamik des Kommissionierstaplers oder Regalbediengerätes und damit eine höhere 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ät 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ör¨ber eine U-f¨ derer) zur Entnahme bereitgestellt. Die Anordnung wird als KommissionierU bezeichnet. Im zweiten Beispiel (Abb. 2.7, b) befindet 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


49

Abbildung 2.6. Person-zur-Ware im Hochregal

Kommissionierer gleichzeitig bedient. Die Bereitstellung erfolgt in diesen Fällen 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 einstufigen als auch in zweistufigen Kommissioniersystemen eingesetzt werden. Im vierten Beispiel (s. Abb. 2.8) ist ein zweistufiges Kommissioniersystem dargestellt. Die Kommissionierung erfolgt an Durchlaufregalen. Nachschub und Entnahme der Einheiten sind in diesem Fall zwangsläufig getrennt. Der Kommissionierer erh¨ alt u ¨ber ein Pick-by-Light-System die Entnahmeinformationen. Die entnommenen Einheiten werden direkt an ein Förderband oder Rollenf¨ orderer u ¨bergeben (Pick-to-Belt). Die Entnahme erfolgt somit

50


a )

b )

Abbildung 2.7. Einstufiges 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älter werden aus einem entfernten Lagerbereich zum Entnahmeplatz transportiert und zur Entnahme bereitgestellt (dezentral-dynamische Bereitstellung). Die Abgabe erfolgt in die im Regal befindlichen Kundenauftragsbehälter, 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 findet in den letzten Jahren insbesondere im e-Commerce-Bereich zunehmend Bedeutung (sehr großes Sortiment und viele kleine Aufträge). 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önnen


51

Abbildung 2.8. Zweistufiges Kommissioniersystem mit Sorter

erforderliche Nachkommissionierungen zu Verzögerungen einer Vielzahl von Auftr¨ agen, respektive zu unvollst¨ andigen Einzelaufträgen f¨ uhren. Daher ist ¨ die Uberwachung der Bereitstellmengen und die rechtzeitige Auslösung 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ändigkeit gepr¨ uft, f¨ ur anstehende Transportvorg¨ ange verpackt und schließlich dem Versand zugef¨ uhrt. In gr¨ oßeren Lagersystemen setzen sich Kundenaufträge 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 Auftragssortierpuffer (hochdynamische Pufferläger) wie beispielsweise Durchlaufregale (vgl. Abschn. 3.1.3) oder Behälter-Umlaufregale (vgl. Abschn. 3.1.3) technisch unterst¨ utzt.

52


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äufig auch ein mehrfaches Umpacken zu beobachten, das entsprechend ineffizient ist. Daher wird eine solche Funktionalit¨ at auch zunehmend in WMS integriert, die, basierend auf einer Volumenberechnung des Kundenauftrags, geeignete Versandgröß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ät und Beschaffenheit 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ähernd 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.


53

2.2.7 Versand Oberfl¨ achlich betrachtet, besteht die Aufgabe des Versands lediglich in der Zusammenstellung der Versandeinheiten entsprechend den Aufträgen und der Verladung der Waren in ein Transportmittel. Abgesehen von den physischen Abl¨ aufen in der Versandzone gehört zur Durchf¨ uhrung dieser T¨ atigkeiten auch eine Reihe an Organisations- und Kontrollfunktionen. Sofern noch nicht durch den Auftrag vorgegeben, ist zunächst 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. gepuffert werden m¨ ussen. Dazu sind vor der Verladung die Versandkommissionen zusammenzustellen und f¨ ur die Verladung bereitzuhalten. Beim Versand palettierter oder anderer größ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


Tabelle 2.10. Lagertypendefinitionen

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 Spezifikation der vorhandenen Lagerplätze 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örder- und Lagermittel auszuw¨ ahlen bzw. einzusetzen, muss beim Einsatz automatischer Lagerverwaltungssysteme eine Zuweisung der Kompatibilität 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ötigen dar¨ uber hinaus die M¨ oglichkeit der selbstst¨ andigen Generierung von Aufträgen, beispielsweise zur Definition von Umlagerauftr¨ agen zur Zugriffszeitoptimierung, und damit auch die Kenntnis der richtigen Betriebsweise von Ein- und Auslagerungsverfahren.

2.3 Warehouse Managementsystem

55

Als Basis f¨ ur solche Optimierungsverfahren benötigt ein automatisches System daher eine stringente Klassifizierung der Lager- und Fördertechnik aus informationstechnischer Sicht. Dazu sollten die in Tabelle 2.10 gelisteten Lagertypen definiert werden. Lagerplatzverwaltung Die Lagerplatzverwaltung ist zunächst das Abbild der technischen Lagerstruktur, d. h. die auf der realisierten Lagertechnik (z. B. Regalf¨ acher) basierende Spezifikation 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 flexibel nutzbaren Lagerformen (z. B. Bodenlagerflächen) reduziert sich die Angabe ggf. auf eine Spezifikation der Flächen und Koordinaten. Gleichzeitig umfasst die Lagerplatzverwaltung die Verwaltung der an einem Lagerplatz gelagerten Einheiten. Dazu gehören die Aufnahme der warenspezifischen 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ötigt. Bei Festlegung des Einlagerplatzes am Identifikationspunkt 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ählte 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ät ist das Sperren von Beständen bzw. das Setzen von Sperrkennzeichen eine elementare Verwaltungsfunktion, die bei unterschiedlichsten Operationen Verwendung findet. Hierbei lassen sich insbesondere • Sperren zur Ein-/Auslagerung und • Sperren f¨ ur bestimmte Lageroperationen (z. B. Umlagerungen empfindlicher G¨ uter vermeiden) unterscheiden. Die Auflistung aller im Lager belegten Plätze, 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


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ährleisten 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ässigen Lagerdauer und das Sperren des Artikels bei Erreichen eines bestimmten (Verfall-)Datums. Unter bestimmten Voraussetzungen ist in solchen Fällen 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 spezifischen 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ällen ausgepr¨ agt erforderlich ist.


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äßig Aufgaben an, die sich jeweils auf ganze Gruppen von Lagereinheiten, Artikeln, Fächern usw. beziehen. Zu diesem Zweck sollte ein Warehouse Managementsystem die flexible Zuweisung von Gruppierungen erm¨ oglichen, um eine aufwändige 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ährlichen oder hochwertigen Waren), • der Lagerung gesperrter Waren (z. B. Quarantäne-Lagerung), • der Auswahl einer gr¨ oßeren Warenmenge oder • Inventurverfahren. Idealerweise sollten sich derartige Gruppierungen sehr flexibel setzen lassen. In jedem Fall sollte die Gruppierung von • Lagerorten (nach Lagergasse, Lagerzone etc.), • Artikelgruppen (nach Typengruppe, Artikelnummer etc.) sowie • Chargen möglich 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 Effizienz zu u ufen und geeignete Schritte zur ¨ berpr¨

58


Optimierung durchzuf¨ uhren, was als Lagerreorganisation verstanden wird. Ausl¨ oser hierf¨ ur k¨ onnen sein: ¨ • Anderungen im Zugriffsverhalten 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 finden einige Maßnahmen Anwendung, die ebenfalls auch durch ein Warehouse Managementsystem unterst¨ utzt werden sollten: • Umbuchung, d. h. Neuzuweisung der Artikel in geeignete Zugriffsklassen und Lagerzonen, • Umlagerung bereits vorhandener Lagereinheiten in zugriffsschwachen 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ß Spezifikation.). 2.3.3 F¨ ordermittelverwaltung und Leitsysteme W¨ ahrend automatische F¨ ordermittel u ¨ ber eine entsprechende Steuerung (Materialflussrechner, 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öhung der Umschlagleistung, Verbesserung der Systemnutzung), ¨ • Systemflexibilit¨ at bei kurzfristigen Anderungen (schnelle Reaktionen auf Transportanforderungen), • Systemzustands¨ uberwachung (Laufzeit von Fahrzeugen, Betriebskosten pro Fahrzeug etc.).


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äge 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 getroffen werden, welche F¨ ordermittel f¨ ur einen bestimmten Auftragstyp grundsätzlich aufgrund ihrer Tragf¨ ahigkeiten, Hubh¨ ohen oder sonstigen Klassifikationen geeignet und somit zuweisungsf¨ ahig f¨ ur einen Auftrag sind. Dazu muss analog zur Lagertypenverwaltung (vgl. Abschn. 2.3.1) eine Klassifikation 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 befindliche 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 flexibel. 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ördermittel 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äge 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


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¨ uhreridentifikation 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ägt, die zu unterschiedlichsten Zwecken Verwendung finden: • Leistungserfassung – Kundenbetreuung, – Fehlmengendokumentation aus Inventur – Erfassung von Kommissionierfehlern, Abweichungen an WA-Kontrolle – Effizienz der Mitarbeiter (z. B. Picks oder Aufträge pro Kommissionierer; Einlagerungen pro Staplerfahrer; Wartezeiten pro Fahrzeug) ¨ • Ubersichtsinformationen – Lagerspiegel (Sortierung nach Lagerpl¨ atzen, frei/belegt, ...) – Lagerbestand – Lagerstatistiken (Umschlagh¨ aufigkeiten, Störungszeiten, F¨ ullgrad, ...) – Raumnutzung • Betriebsmittelstatistiken – Laufzeiten – Ausfallzeiten – Wartungs- und Reparaturkosten je Einheit • u. v. a. m. W¨ ahrend die personenbezogene Leistungserfassung in vielen Fällen 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ördermitteln zeigen, ob parallel angeordnete Systeme im Gleichgewicht arbeiten. Wartezeiten an bestimmten Punkten k¨ onnen wiederum Engpässe anzeigen und eine ¨ Uberpr¨ ufung von Betriebsstrategien, Systemleistungen oder Personaleinsatz initiieren.


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ötigten 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 definierende 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 Effekte oder Zeiträume 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 Logfile mit der Erfassung von Ereignissen und dem Eintrittszeitraum erstellt (Zeitreihe). Aus dem Logfile 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äge – 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ände, ...) – auftragsbezogene Daten (Auftrags-Nr., Auftragspositionen, Termine, ...) – lagereinheitenbezogene Daten (Lagerplatz-Nr., frei-/belegt-Status, Menge, ...)

62


Daneben m¨ ussen aus rechtlichen Gr¨ unden Lieferscheine bzw. Warenausgangsprotokolle erfasst und dokumentiert werden. 2.3.5 Inventur Die Inventur ist eine gesetzliche Verpflichtung, 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äten, also auch bei Best¨ anden, muss eine körperliche Bestandsaufnahme durchgef¨ uhrt werden. Damit sollen insbesondere die Lagerbestände (Buchbestände) und die Zuverl¨ assigkeit der Bestandsf¨ uhrung (Lagerbuchf¨ uhrung) u uft wer¨ berpr¨ den. Alle Gegenst¨ ande (Lagereinheiten) sind zu identifizieren und zu klassifizieren und durch Z¨ ahlen, Messen oder Wiegen mengenmäß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 wertbeeinflussende 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öglich. 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örperliche Aufnahme aller Best¨ ande am Bilanzstichtag. Da der Geschäftsverkehr am Bilanzstichtag ruht, ergeben sich keine Veränderungen am Verm¨ ogen“. Eine solche Aufnahme ist nur bei kleineren Systemen mög” 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änderungen zuverlässig 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.


63

R¨ uckrechnungsverfahren nach den Grundsätzen odnungsgemäßer Buchf¨ uhrung (GoB) voraus. Permanente Inventur Um die Durchf¨ uhrung der Inventur entsprechend den Bed¨ urfnissen eines Betriebes in Zeiten mit geringer Betriebstätigkeit oder geringen Bestandsmengen durchzuf¨ uhren, bietet sich die permanente Inventur an. Dabei kann die k¨ orperliche Aufnahme der Bestände 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ätzen 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önnen. 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ängigerweise am Identifikationspunkt vor der Einlagerung). Dabei wird das Zählkennzeichen 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ählkennzeichen 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


Sch¨ atzverfahren Aufbauend auf den Kenngrößen der Häufigkeitsverteilung einer Stichprobe wird auf die Kenngrößen der Grundgesamtheit geschlossen. Bei geschichteten Schätzverfahren 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ändige Finanzbeh¨ orde ab. Einflussparameter, welche die Tauglichkeit eines Verfahrens beeinflussen, 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ässt eine äuß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 geschaffen. Die Inventur besitzt damit auch f¨ ur die eigene Betriebsf¨ ahigkeit eine erhebliche Bedeutung. Zudem werden Nachlässigkeit oder Diebstahl nicht selten erst durch die Einf¨ uhrung einer zuverlässigen 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öglichen relevanten systembeschreibenden Gr¨ oßen praktisch nicht möglich ist. Der u oßen ist im Einzelfall zur Klärung einer ¨berwiegende Teil solcher Kenngr¨ gegebenen Aufgabenstellung zu definieren bzw. zu erstellen. Im Folgenden sollen dennoch die elementaren und allgemeing¨ ultigen Kenngröß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 Differenz 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 Effizienz 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ängeren Zeitraum unveränderte 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ängig von ihrem aktuellen Bestand. Die Summe der Artikel entspricht grundsätzlich dem Sortiment. Abweichungen gegen¨ uber dem Bestand bzw. dem tatsächlichen 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ängeren 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änderungen unterworfen sind, werden sie auch als dynamische Daten bezeichnet.

66


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ällt 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ößen, also aus Daten oder anderen Kennzahlen zusammengesetzte (Verhältnis-)Größen. Dagegen werden im weiteren Sinne alle m¨ oglichen Kenngröß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 Effizienz-/Produktivitätszahlen (Output/Input) und Intensitätszahlen (Input/Output) gebildet. Die Bildung der spezifischen Kennzahl hängt wiederum davon ab, ob die Ausrichtung der Fragestellung operativer oder strategischer Natur ist. Operative Kennzahlen dienen in erster Linie der Steuerung und Regelung effizienter logistischer Abl¨ aufe, strategische Kennzahlen werden mit dem Ziel der Entwicklung und Gestaltung effektiver G¨ uterfl¨ usse erstellt [15]. Kennzahlen basieren oftmals auf gemittelten und angenäherten 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 definiert sein k¨ onnen, woraus erhebliche Diskrepanzen in der Bewertung resultieren. ufen, ob eine Kennzahl wertmäßig oder mengenDaher ist insbesondere zu pr¨ bzw. leistungsbezogen erstellt wurde. Da auch einzelne Kennzahlen nur Teilaspekte wiedergeben können 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


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¨ aufigkeit, 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änge so aufeinander abgestimmt, dass die eingehenden Waren ohne Einlagerung unmittelbar in den Versand gegeben werden. Damit findet 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 Effizienz durch Vermeidung von Prozessschritten, k¨ urzere Durchlaufzeiten der Artikel im System, Servicesteigerung durch h¨ aufigere Belieferung, effektive 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ände an den Endverkaufspunkten, was eine h¨ aufigere 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 findet ein Umschlag von palettierten Einheiten in Rollbehälter statt. Dieses Prinzip wird auch als zweistufiges Cross Docking oder Behälter 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 einstufiges Cross Docking bezeichnet.

70


Werden dabei nur ganze Transporteinheiten (z. B. Paletten) umgeschlagen, spricht man z. B. vom Paletten-Cross-Docking. Befinden sich auf den Ladeeinheiten dagegen f¨ ur einzelne Filialen vorkommissionierte Behälter, die den einzelnen Filialen bzw. Touren zugeordnet werden m¨ ussen, wird das Prinzip auch als Pre-sorted Store Order bezeichnet. In diesem Fall findet 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 effiziente 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öglich. Ist das Auftragsspektrum der Filialbetriebe weitgehend gleich, werden auch die Touren zwangsl¨ aufig zu einem ¨ ahnlichen Zeitpunkt fertiggestellt. Hieraus können 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 finden 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äufe 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önnen, 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ähig 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ängigkeit 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äten 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


Im Bereich der Logistik existieren solche Lösungen f¨ ur Shopsysteme im Bereich des E-Commerce und f¨ ur Anwendungen in der Warenwirtschaft, also auf WMS-¨ uberlagerten Ebenen. Eine ASP-Lösung, 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äten ändern sich dadurch jedoch nicht. Auf die Darstellung der speziellen Abläufe 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 effektiven Erbringung dieser Aufgaben herausgebildet. Im Folgenden sollen die gängigsten technischen L¨ osungen zur Lagerung und F¨ orderung von G¨ utern als Basis f¨ ur die Diskussion der effizienten 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 Schaffung einer soliden Basis f¨ ur ein Grundverständnis 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ählen zu können, ist eine Systematik hilfreich, aus der systembedingte Leistungscharakteristika allgemeing¨ ultig abgeleitet werden k¨ onnen. Die grundlegenden Differenzierungen f¨ ur verschiedene Lagersysteme sind in Tabelle 3.1 aufgef¨ uhrt. Ebenso sind den einzelnen Auspr¨ agungsformen bereits einige allgemeing¨ ultige Eigenschaften zugeordnet. Die Differenzierung in statische und dynamische Lagersysteme ber¨ ucksichtigt dabei, ob das Lagersystem zwangsläufig 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 Klassifikation 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, Zugriffsverhalten und Bedienstrategien.

74


Tabelle 3.1. Differenzierung 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ördermittel 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 flexibel an ¨ ortliche Gegebenheiten (Flächenzuschnitt und Gebäudeform) 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 Zugriff nur auf die in vorderster S¨ aule befindlichen G¨ uter möglich. 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, Rohstoffe) und andererseits um Pufferläger im Warenein-/-ausgang handeln, sofern hier Ganzladungen gepuffert werden. Bodenzeilenlager Um einen gegen¨ uber dem Bodenblocklager besseren Zugriff 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 Materialflussverfolgung gegen¨ uber. Da in den meisten F¨ allen nur Bodenfl¨ 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öglich. Ebenso ist die direkte Zuweisung eines Lagerplatzes an einen Bediener (Stapler-

76


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ässt sich im ersten Ansatz die getrennte Lagerung einzelner Chargen in separaten Stellflächen 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 Materialflussverfolgung zu gew¨ ahrleisten [36]. Demgegen¨ uber werden in automatisch betriebenen Bodenblocklägern, 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ächennutzung durch eine bessere Nutzung der H¨ ohe im Vordergrund. Die Ladeeinheiten werden in ein separates Fach oder an einen spezifizierten Ort eines Lagergestells gesetzt. Insbesondere k¨ onnen so auch nicht stapelfähige G¨ uter effizient 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 geschaffen. ¨ Im t¨ aglichen Betrieb wird dar¨ uber hinaus Ubersichtlichkeit und Ordnung im Lager erzeugt. Regale in Zeilenanordnung (Zeilenregale) bieten beliebigen Zugriff 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ägern. Zeilenregale Die Gestaltung eines Zeilenregals variiert mit der Größe, Form und dem Gewicht des einzulagernden Gutspektrums, der gewählten oder möglichen Be-

3.1 Lagersysteme

77

dientechnik, der geforderten Ein-/Auslagerleistung und den räumlichen Gegebenheiten. Die einzelnen F¨ acher des Regals sind auf die maximalen Abmessungen einzulagernder G¨ uter zuz¨ uglich allseitiger Freiräume zur Handhabung und Gut¨ ubergabe auszulegen. Die L¨ ange einzelner Lagergänge und die Anordnung der Bedien- und Gassenwechselwege werden im Wesentlichen durch die Anforderungen des Kommissioniersystems geprägt. Der Begriff Zeilenregal definiert zun¨ achst, dass einzelne Fächer 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 zugegriffen 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 Zugriff 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älterregal, 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ängigkeit von der eingesetzten Bedientechnik variieren die erforderlichen Arbeitsgangbreiten und damit der realisierbare Raumnutzungsgrad. Palettenregale Palettenregale (engl. Racks) stellen die am häufigsten 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


die Lagereinheit l¨ angs oder quer eingelagert wird. Bei der Längseinlagerung sind jeweils zwischen den vorderen und den hinteren Regalst¨ utzen zwei Traversen befestigt (geschraubt, im Lochraster eingehängt 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äufig 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örmige Auflage zwischen einer vorderen und hinteren St¨ utze befestigt und die Ladeeinheit stirnseitig zur St¨ utze und somit quer ins Lagerfach eingelagert. In diesem Fall befindet sich nur eine Ladeeinheit zwischen den Regalst¨ utzen, woraus sich die Bezeichnung Einplatzlagerung ableitet. Die L¨ angseinlagerung erm¨ oglicht eine effizientere Raumnutzung, da im Regal weniger St¨ utzen und Sicherheitsabst¨ ande vorhanden sind. Auch können 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öhen 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 geschaffen 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ällen die Einlagerung kleinerer Beh¨ alter oder Tablare bevorzugt (z. B. 400 mm×600 mm). Tablare sind Blechwannen mit einer stirnseitig angebrachten Eingriffsleiste. Durch die geringen St¨ uckgewichte ist die Lagerung auf einfachen Winkelprofilen möglich, die seitlich an den Lagerf¨ achern angebracht sind. Die geringen St¨ uckgutgewichte erm¨ oglichen dabei auch effektivere Formen der Lagerfachbedienung, die zu speziellen Ausprägungen der Zeilenregale gef¨ uhrt haben und als Behälter-, Kasten- oder Tablarregale bezeichnet werden. Das relativ geringe St¨ uckgutgewicht ermöglicht in vielen Fällen, 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 Griff 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älter 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


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 betreffende Einheit zunächst ausgelagert werden, wodurch zus¨ atzliche Wege anfallen. Die Problematik trifft analog auf Mischlagerung bei Tablaren und Beh¨ altern zu. Hochregallager Die Bezeichnung Hochregal wird oft als Synonym f¨ ur hohe Regalbauten genutzt, tats¨ achlich trifft 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önnen u atze respektive mehrere 100 000 Behälterplätze um¨ber 100 000 Palettenpl¨ fassen. Solche Systeme werden h¨ aufig in Silobauweise realisiert, dabei trägt 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äulen einander gegen¨ uberliegend angeordnet. Dazwischen verfährt 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äule werden auch Anlagen mit flexibel definierbaren Fachhöhen ausgef¨ uhrt. Dazu wird anstelle absoluter Lagerf¨ acher ein Aufnahmeraster f¨ ur die Tablare mit einem Rastermaß von ca. 100 mm geschaffen, 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öhen 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önnen. Durch die flexibel 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öhe beträgt zwei Meter. Unter Verwendung von Hilfsmitteln (z. B. Leitern) werden auch drei Meter hohe Ausf¨ uhrungen eingesetzt, wobei durch die zusätzlichen 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ächer 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äger (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äte,

82


¨ 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önnen die Kragarme als Trennelemente f¨ ur stehende G¨ uter genutzt werden. Wie im Fall der Palettenregale k¨ onnen durch zusätzliche Auslegeböden auch durchgehende Lagerfl¨ achen f¨ ur G¨ uter mit unterschiedlichen Abmessungen geschaffen 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 flexible 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 Zugriffsm¨ 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 Zugriff 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 zugegriffen 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 Zugriff auf im Block befindliche Einheiten sind Umlagerungen unumg¨ anglich. Der wesentliche Vorteil dieser Lagertechniken besteht in der Möglichkeit, 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


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 Winkelprofile befestigt, auf die die Ladeeinheiten abgesetzt werden k¨ onnen. Bei der Ein- und Auslagerung wird die Ladeeinheit knapp oberhalb des Winkelprofils 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¨ aufig 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öglich. 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ätze ist technisch zwar m¨ oglich, l¨ asst sich jedoch in der Praxis unter anderem durch die manuelle Bedienung und notwendige Platzidentifikation nur schwer realisieren. Dagegen l¨ asst sich das Lagerprinzip zur Pufferung 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ängig 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 Zugriff 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äufig umgelagert werden. Betrieb und Organisation Mittels automatisierter Satellitenfahrzeuge l¨ asst sich eine sehr flexible Lagerorganisation realisieren. Durch die unabh¨ angige Operation der Satellitenfahrzeuge im Regal und den möglichen Einsatz einer Vielzahl von Fahrzeugen lassen sich kompakte Lagerung und hohe Durchsatzleistung vereinen. Mit wachsendem Mischungsgrad der Kanäle (verschiedene Ladeeinheiten in einem Gang) und notwendigem Einzelzugriff 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äge. 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öhung der Kommissionierleistung, • hohe Umschlagleistung bei kompakter Lagerung und • Nutzung der Vorteile der Block- und Zeilenlagerung gekennzeichnet.

2

ein Produkt der Westfalia F¨ ordertechnik

86


Bei der dynamischen Lagerung werden zwei grundlegende Prinzipien unterschieden: feststehende Lagereinheiten in bewegten Regalen und bewegte Lagereinheiten in feststehenden Regalen. Zur ersten Gruppe zählen 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älter-, Fachbodenoder Kragarmregale montiert werden, allerdings bei begrenzter Höhe (bis ca. zehn Meter). Dadurch k¨ onnen einzelne Regalzeilen durch seitliches Verfahren zu einem kompakten Block zusammengef¨ uhrt werden und die Regalgänge 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 Offnen des Ganges bzw. Aktivieren der Regalzeile zugegriffen 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 Zugriffsverhalten 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äten ergänzte Stetigfördermittel (Kreis- oder Umlauff¨ orderer). Gegen¨ uber einem Fachbodenregal können Gangbreiten reduziert werden, da die Umlenkradien sehr gering ausgef¨ uhrt werden k¨ onnen. Diese Technik wird h¨ aufig 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 befindet sich am zentralen Ubergabepunkt. Ebenso sind mehrere ¨ Ubergabepunkte auf verschiedenen Ebenen m¨ oglich. Auf geringer Standfläche 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 Zugriff.

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ängt in hohem Maße von der Bauh¨ ohe und dem Zugriffsverhalten auf die gelagerten Artikel ab. Zur Erreichung einer akzeptablen Leistung ist die Zugriffsreihenfolge auf die Lagerplatzreihenfolge abzustimmen, um ständige 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


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 befindet. 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älter-Umlaufregale dar. Die Systeme dienen prim¨ ar der kurzzeitigen Pufferung, beispielsweise zur Konsolidierung von Teilauftr¨ agen im Versandbereich. Während beim klassischen Umlaufregal in erster Linie einzelne Artikel oder Gebinde entnommen werden, wird beim Beh¨ alter-Umlaufregal der gesamte Behälter 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önnen. Durchlaufregal Durch Einf¨ ugen einer F¨ orderebene in einen feststehenden Regalblock können 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 befinden sich die Lagereinheiten hintereinander. Zugriff ist grunds¨ atzlich nur auf die vordere Regalfront möglich. Durch das Durchlaufprinzip werden Beschickung und Entnahme getrennt angig voneinander ablaufen. Außerdem wird das FIFOund k¨ onnen so unabh¨ Prinzip zwangsl¨ aufig und ohne zus¨ atzlichen Steuerungsbedarf gewährleistet (bzw. LIFO im Fall des Einschubregals). Der entscheidende Vorteil liegt neben der kompakten Lagerung in der Vorhaltung vieler Artikel im direkten Zugriff bei gesichertem Nachschub. Dadurch kann sich auch eine erhebliche Stirnfl¨ achenverkleinerung der Lagerfl¨ 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älen artikelreine bzw. auftragsreine Ladeeinheiten gebildet werden. Umlagerungen zum Zugriff auf nicht an der Regalfront befindliche 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ähigen Palette steht und in die Schienen eines Lagerkanals eingeschoben wird. Durch frontseitig angebrachte Haken werden die in der Gasse befindlichen Lagereinheiten zu einem Zug gekoppelt, der durch Verschieben der gassenseitigen Lagereinheit bewegt wird. Durch Installation ausreichender Ein-/Auslagerkapazitäten 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ätze vor dem Regal sind mit Bereitstelleinheiten und Leerbehältern 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


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 beeinflussen die Leistungsf¨ ahigkeit der Lagervorzone maßgeblich: eine leistungsf¨ ahige F¨ ordertechnik und ein geeignetes Steuerungskonzept. Seitens der F¨ ordertechnik kommen Rollenbahnen, Tragkettenförderer, Drehweichen oder Verschiebewagen zum Einsatz. Je nach Regalbediengerät erfolgt die Bereitstellung beiderseits des Ganges oder u ¨ bereinander. Davor sind ausreichend dimensionierte Pufferpl¨ atze vorzusehen (s. Abb. 3.10).

3.2 F¨ ordersysteme Als Fördermittel werden im Allgemeinen die technischen Systeme des Materialflusses verstanden, die im Wesentlichen die innerbetriebliche Ortsveränderung 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äßig die Fördermittel 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örderleistung, gemessen in St¨ uck/Zeiteinheit, und produzieren einen kontinuierlichen bzw. quasikontinuierlichen F¨ orderstrom. Sie erlauben vielfältige 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örderg¨ uter von einer Quelle zu einem Ziel transportieren und mit dem Fördergut verfahren. Dieser Prozess wird als Arbeitsspiel bezeichnet. Sie können je nach Bauweise beliebige Punkte entlang eine Linie, in der Fläche 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ägung steigen mit der Einsatzflexibilit¨ at auch der Steuerungsaufwand und die Anforderungen an die Automatisierung. 3.2.1 Stetigf¨ orderer Rollenf¨ orderer Bei Rollenf¨ orderern wird das Fördergut 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 (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ßfl¨ 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öglicht, 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älter; 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 Materialflussrechner (MFR) und unterlagerter Gerätesteuerungen zur Ausf¨ uhrung und Optimierung der Bewegungsabläufe auf der Feldebene eingesetzt. Auf dem Materialflussrechner 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.


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ät 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 ähnliches Prinzip verfolgt der so genannte TransFaster, bei dem das Lastaufnahmemittel hängend an einem Katzfahrwerk angebracht ist. Das Katzfahrwerk verfährt wie ein Kanalfahrzeug auf seitlichen Schienen innerhalb einer Gasse. Dadurch k¨ onnen auch mehrere Fahrwerke auf verschiedenen Höhenniveaus 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ährt 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


Elektroh¨ angebahn Elektroh¨ angebahnen (EHB) sind flurfreie, automatische Unstetigförderer. 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 Schleifleitungen mit Energie versorgt werden. Das Fördergut 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¨ aufig zur Verbindung verschiedener funktionaler Bereiche (z. B. Wareneingang und Hochregal) eingesetzt. Ein EHB-System ist ein universell einsetzbares Fördersystem. Die Beladung erfolgt im Stillstand, so dass auch große und schwere Lasten sicher u onnen. Fahrgeschwindigkeiten bis zu 2 m/s ermöglichen ¨bergeben werden k¨ ¨ gleichzeitig die effiziente Uberbr¨ uckung großer Distanzen und hohe Durchsätze. Durch zahlreiche Verzweigungs- und Zusammenf¨ uhrungselemente (Drehkreuze, Zwei-/Dreiwegeweichen, Parallelweichen) sowie Steig-/Gefällestrecken 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ändig 90◦ -Passagen u onnen, zu begrenzen. Durch angepasste Fahrzeuganzahl oder ¨berwinden k¨ parallele Pufferstrecken k¨ onnen auch verschiedene Pufferaufgaben erf¨ ullt werden. Typische Standardlasten pro Fahrzeug betragen ca. 300–1000 kg, daneben werden auch Systeme f¨ ur geringere und deutliche höhere 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 Schleifleitungen 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ällen wird ein EHB-vergleichbares Schienensystem auf dem Boden montiert, im Fall der EPB zwei parallele Schienen. Das F¨ ordergut wird oberhalb des Fahr-


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 Materialfluss. Sie werden vorzugsweise zum F¨ ordergutwechsel zwischen unterschiedlichen Transportmitteln und zur Manipulation schwerer Lasten eingesetzt. Ein wesentliches Merkmal aller Kranbauformen ist der flurfreie 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 befinden sich daneben verschiedene Formen von Fahrzeugkranen, die hier nicht weiter vertieft werden sollen (vgl. dazu [65]). Zu den Kranen mit quaderf¨ ormigem Arbeitsraum zählen die Folgenden: ¨ Br¨ uckenkrane Uber dem Arbeitsbereich sind seitlich Laufschienen (Kranbahnen) montiert, die sich direkt in das Gebäude abst¨ utzen. Die Kranbr¨ ucke u ¨ berspannt den Arbeitsbereich und verfährt 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ändig unterhalb der Schiene h¨ angt. Dadurch wird der Arbeitsbereich vergrößert, da die Laufkatze auch unterhalb der Schiene operieren kann. Ebenso ist ein ¨ Uberwechseln der Laufkatze in andere Hallenbereiche möglich. Stapelkrane Basierend auf einem Br¨ ucken- oder Hängekran 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äude 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ärmeeinwirkungen oder Toleranzen in der Kranbahn zu umgehen. Die größere Masse und

112


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 Materialfluss 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äufig 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äten. Daneben finden Krane Einsatz als Umschlaggeräte 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¨ aufig 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önnen 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öglichst 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ägte 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ässiges Gurtmaß häufig = L¨ ange + 2×Breite + 2×H¨ ohe = 3000 mm). Kommissioniersysteme Insbesondere in zweistufigen 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äge werden f¨ ur den Versand separiert. Da die Menge der täglich abzuarbeitenden Kundenauftr¨ age die m¨ ogliche Endstellenanzahl oftmals deutlich u ¨ berschreitet, werden die Kundenaufträge zu Stapeln zusammengefasst, die nacheinander abgewickelt werden. Somit werden die Artikel bei jedem Lauf neu zugewiesen. Ebenfalls ist die Zuordnung einer einzelnen

114


Einheit nicht eindeutig, da derselbe Artikel in verschiedenen Kundenauftr¨ agen gefordert sein kann3 und sich somit zur Zuweisung auf mehrere Ziele qualifiziert. Daher h¨ angt die Sortierleistung in diesem Anwendungsfall unter anderem auch von der Anwendung geeigneter Zuweisungsregeln ab. Aber auch in einstufigen, auftragsparallel arbeitenden Kommissioniersystemen k¨ onnen durch Sortereinsatz Rationalisierungspotenziale erschlossen werden. Die Zusammenf¨ uhrung von Teilaufträgen zu Versandauftr¨ agen (Beh¨ altersortierung) stellt dabei andere Anforderungen an das Verteilsystem: die Sortierg¨ uter sind zusammengefasste Mengen (Behälter, Kartonagen), der Durchsatz ist relativ gering und die in der Endstelle zu puffernde 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äfen ist die k¨ urzeste Anschlusszeit (Minimum Connecting Time, MCT), um den sicheren Gep¨ acktransfer bei Anschlussfl¨ ugen sicherzustellen. Auf großen Flughäfen ist eine kurze Prozesszeit nur durch umfangreiche fördertechnische Anlagen mit Sortier- und Verteilfunktionalität möglich. Besondere Anforderungen stellt dabei das Sortiergut (Fluggepäck), dessen Gutform und -eigenschaften nicht pr¨ azise definierbar sind. Neben nahezu beliebigen Formen und Steifigkeiten 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ät erfordert auch vorund nachgeschaltete Systemelemente. Es lassen sich f¨ unf funktionelle Bestandteile unterscheiden [72]: • • • • •

3

Systemeingabe Vorbereiten Identifizieren Verteilen Systemausgabe

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


115

Systemeingabe Aufgabe der Systemeingabe ist die Angleichung der Arbeitscharakteristik des Sorters an das vorgeschaltete System. Pulsierende Eingangsströme 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 Pufferkapazit¨ 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 Pufferung mehrerer Batches vor dem Sorter erforderlich sein. Vorbereiten Die effiziente Arbeitsweise eines automatischen Systems kann im Allgemeinen dadurch unterst¨ utzt werden, dass die Freiheitsgrade der zu bearbeitenden Objekte begrenzt werden, was auch auf Verteiltechniken zutrifft. 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 definierter Zwischenabst¨ ande zur unbeeinträchtigten Verarbeitung. Das l¨ asst sich beispielsweise durch zwei hintereinander geschaltete Stetigförderer 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ördererabschnitte 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örderer und Aufgabef¨ orderer in einem entsprechenden Winkel zueinander justiert, oder es wird eine manuelle Aufgabe eingesetzt. Die sichere Identifizierung des F¨ ordergutes ist ebenfalls elementare Voraussetzung f¨ ur einen st¨ orungsarmen Sorterbetrieb. In verschiedenen Abl¨ aufen kann die Position des Identifizierungsmerkmals jedoch beliebig sein. Um den Einsatz kostenintensiver Allseiten-Erfassungsgeräte (Scannerbr¨ ucken) zu umgehen, ist die Ausrichtung des Identifizierungsmerkmals zum Leseger¨ at vorteilhaft. Dieser Vorgang wird u ¨ berwiegend manuell, z. T. aber auch durch automatisches Kippen in die korrekte Position bewerkstelligt.

116


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. Identifizieren Die Identifizierung 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¨ aufig niedriger, was die Lesesicherheit erhöht bzw. den Einsatz einfacherer Scanner erm¨ oglicht. Besitzt das Sortiergut keinen maschinenlesbaren Code, werden verschiedene Formen einer manuellen Identifizierung eingesetzt. Aus dem Postbereich ist beispielsweise das manuelle Eintippen des Zielcodes und Auflegen 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 Identifikationsstelle 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ährt die Spracheingabe (Voice-Coding), die es dem Kommissionierer ermöglicht, 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 klassifizieren: • 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


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önnen 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 Identifikation und Zuf¨ uhrung auf dem Verteilkreislauf verbleiben und bei der nächsten 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örderstrecke, 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önnen systembedingt nur von oben, nur von vorne oder nur seitlich bef¨ ullt werden (s. Abschn. 3.3.3). Seitliche und vertikale Zuf¨ uhrung ermöglicht eine Erhöhung der Systemleistung durch mehrfache und parallel angeordnete Zuf¨ uhrstellen. Außerdem k¨ onnen aus verschiedenen Bereichen kommende Förderstrecken unmittelbar an den Verteilkreislauf angeschlossen werden. Demgegen¨ uber muss bei der Horizontalaufgabe in F¨ orderrichtung der gesamte Förderstrom 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äufern) ab. Im Idealfall wird der Gutstrom derart vorsortiert, dass die in einem Bereich zugef¨ uhrten

118


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ächsten Zuf¨ uhrbereiches verteilt werden. Dadurch lässt sich nahezu eine n-fache Belegung der Verteilstrecke erreichen. Begrenzend wirkt wiederum der Anteil an Kreisl¨ aufern. Werden dagegen gemischte Teilströme an verschiedenen Stellen des Kreislaufs zugef¨ uhrt, ist eine Angabe der möglichen Leistungssteigerung aufgrund der zuvor genannten Einflussgröß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 definiert. 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ässt 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ördermittel auf und wird durch Verfahren des F¨ ordermittels ausgeschleust. Die Ausschleusung ohne Relativbewegung zum Fördermittel ermöglicht eine ¨ pr¨ azise und gutschonende Ubergabe.


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äfte, und können 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 Klassifikation 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öglichst 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öhe, 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örderer unterst¨ utzen eine automatisierte Handhabung. Passive Endstellen (oftmals Rutschen, Beh¨ alter etc.) werden durch Mitarbeiter entleert und f¨ ur den

120


Abbildung 3.27. Rutschen-Endstellen [Foto: BEUMER]

nächsten 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 definieren. 3.3.3 Verteiltechniken Vielseitig und h¨ aufig 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ösungen die hier der Vollst¨ andigkeit halber erw¨ ahnt seien, finden sich beispielsweise zur Sortierung von H¨ angeware. Quergurtsorter Auf einer Wagenkette sind quer zur Förderrichtung Gurtf¨ orderer montiert, die auf die maximale Gutgröß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ördergut geht ohne Re-


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 beeinflusst werden können. 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örmig 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önnen und gr¨ oßere Freiheiten bei der Gut¨ ubergabe bestehen. Auch die Form der Kippbewegung kann den Ausschleusvorgang beeinflussen. Das Ziel ist dabei im Allgemeinen eine Reduzierung der sonst relativ großen Endstellenbreite. Antrieb und Umlenkung erfolgen analog zum Quergurtsorter.

122


Abbildung 3.29. Kippschalensorter [Foto: BEUMER]

Schiebeschuhsorter Zwei vertikal umlaufende Ketten sind mit Stäben oder Profilen (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 befindliches 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 ( 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ält (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 Differenz (minus) möglich. 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 anwendungsspezifischen Operationen auf den Daten ausf¨ uhren. Im Bereich der WMS könnte das beispielsweise ein Client zur Pflege der Stammdaten oder ein Client f¨ ur den Wareneingangsbereich sein. Der Zugriff 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ötigt 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äufig ¨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 stattfindet. Die schnellere Ausf¨ uhrung der Operation hat auch zur Folge, dass die betroffenen Datensätze nur f¨ ur eine verh¨ altnismäß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 Zugriffs 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 (OfflineVerf¨ 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änkte 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¨ offnete 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 definiert 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 Zugriffs 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öcke 1 bis n auf die Laufwerke 1 bis n, danach die Blöcke 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älfte der vorhandenen Plattenkapazit¨ at. F¨ allt ein Laufwerk aus, dann wird mit dem jeweils anderen weitergearbeitet.

184


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 Zugriffe mit kleinen Datenmengen geeignet, daher wird diese Variante besonders häufig in transaktionsorientierten Umfeldern wie Datenbanken eingesetzt. Fällt ein Laufwerk aus, k¨ onnen die Daten aus den verbleibenden Laufwerken rekonstruiert werden. ¨ Journaling Alle Anderungen an den Datenbeständen 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ällen oder ¨ ussen wie Wasser, Feuer oder Uberspannung, aber auch gegen äußeren Einfl¨ 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 spezifische 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äß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önnen die letzten Anderungen nur noch manuell nachvollzogen werden. Neben dem gelegentlichen Vollbackup werden durch inkrementelles und diffe¨ renzielles Backup nur Anderungen gesichert, um das Speichervolumen gering zu halten (s. Tabelle 5.9).

186


Das Backup dient auch der Archivierung von Daten f¨ ur eine spätere Auswertung. Es sollte also immer ein Archivierungssystem betrieben werden, das nicht nur technische, sondern auch organisatorische Vorkehrungen trifft. 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ände jedoch nicht selten unzureichende Vorkehrungen getroffen. 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äte, 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äte 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ählte 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ät zu pr¨ ufen. Das bedeutet, dass nur erlaubte Zeichen eingegeben, Wertebereiche eingehalten und keine Abh¨ angigkeiten zwischen einzelnen Parametern verletzt werden können.

188


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

Die an einem Arbeitsplatz oder an einem Gerät 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ätssicherung 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 stattfinden. 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ätzlich 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ätze, 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 definierten I-Punkten oder Kommissionierpl¨ atzen – zugesichert werden. Weitere Einschränkungen können bis auf die erlaubten Einzelfunktionen im Sinne von Berechtigungsprofilen (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ätskontrolle 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ängig, 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 Bedienerprofil 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


Die Darstellung des Datums und der Uhrzeit sollte in einer unverwechselbaren Form erfolgen. Abweichend hiervon sind Darstellungen möglich, die am Standort des Betreibers u uche können 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 Identifikation durch geeignete Funktionen möglich 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öglicht. 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öglichen Eingabewerte oder Wertebereiche hilfreich. Adaptive Verfahren können abhängig von der Vorgeschichte des Bedienerdialoges gezielte Hinweise geben. Adaptive Hilfesysteme werden heute kaum oder nur in einer sehr rudimentären Form eingesetzt. H¨ aufig 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 fliegende 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 Zugriff 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 Begriff Betriebssystem (BS) werden seit dem Aufkommen der Personal Computer Anfang der 80er Jahre oft Eigenschaften des Dateisystems, Netzwerkf¨ ahigkeiten und insbesondere Konzepte der Bedienoberfläche 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 Bedienoberflächen, werden in getrennten Abschnitten behandelt. 5.4.1 Aufgaben Ein Betriebssystem bildet eine Softwareschicht, die Anwenderprogramme von dem direkten Zugriff 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 definierten zeitlichen Abhängigkeiten zwischen verschiedenen Anwenderprogrammen (Synchronisation)

192


• 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 benutzerspezifischen 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“ definiert 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 Zugriffe, 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 Zugriff 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 Zugriff 25

Allein die M¨ oglichkeit des lesenden Zugriffs auf Speicherbereiche fremder Programme ist aus Sicht des Datenschutzes unbedingt zu vermeiden, s. Abschn. 5.6. Ein schreibender Zugriff 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 findet die Ausf¨ uhrung der im Speicher befindlichen 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¨ aufig referenzierte Anweisungen und Daten f¨ ur einen schnellen Zugriff zwischengespeichert werden. Die Leistungsfähigkeit 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ähigkeit 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 definierte Testl¨ aufe von ausgew¨ ahlten Programmen einer oder mehrerer Kategorien von Applikationen mit

194


ein, um die Leistungsf¨ ahigkeit f¨ ur eine Klasse von Einsatzfällen zu ermitteln. • Ger¨ ate (Devices): Hierunter werden folgende Gerätegruppen zusammengefasst: – Schnittstellen: Beispiele sind parallele und serielle Schnittstellen wie RS232 oder USB. – Netzwerk: Zugriff auf lokale und/oder Weitverkehrs-Netzwerke zur Rechnerkommunikation u ¨ ber unterschiedliche Medien (s. Abschn. 5.1) – Massenspeicher: Massenspeicher mit wahlfreiem Zugriff27 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 Klassifizierung 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 GrafikKarten angesteuert. Hierbei handelt es sich um Subsysteme, die eine hohe Datenrate von der CPU empfangen. Auf diesen Daten können die Grafik-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ät 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 Offentlichkeit. 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

definierten Eingabedaten unter einem konkreten Betriebssystem auf einer spezifizierten Hardware. Ziele sind unter anderem die Ermittlung der Antwortzeiten und des mittleren Durchsatzes. Unter einem wahlfreien Zugriff 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äufig ausgef¨ uhrt werden. Nebenl¨ aufigkeit 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 Begriff der Nebenl¨ aufigkeit verwendet. WMS sind aus softwaretechnischer Sicht komplexe Systeme, die aus mehreren, teilweise nebenl¨ aufigen Tasks bestehen, die untereinander Daten austauschen, sich gegenseitig Dienste bereitstellen und ihren Programmfluss an definierten Stellen synchronisieren. In neuerer Zeit hat sich sowohl f¨ ur einzelne Anwenderprogramme als auch f¨ ur komplexere Programmsysteme der Oberbegriff 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 Zugriff 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äufig 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


von grundlegender Bedeutung – nicht nur f¨ ur Betriebssysteme, sondern auch f¨ ur Datenbanken und dar¨ uber hinaus auch f¨ ur Materialflusssteuerungen – ist, wird in Abschn. 5.4.2 auf dieses Thema eingegangen. • Kommunikation: Ein Nachrichtenaustausch zwischen Prozessen, die so genannte Interprozesskommunikation, muss möglich sein. Diese Kommunikation kann sich auf den Austausch von Signalen ohne eine zusätzliche Information beschränken oder sie kann auch Inhalte in Form von Datensätzen 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 befindet sich zu jedem Zeitpunkt in einem der drei Zustände 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ände. 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ätzlich, 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äten zu. Diese Prioritäten unterliegen dabei oft innerhalb gewisser Schranken einer Dynamik: Prozesse, die wegen einer Ein-/Ausgabe die CPU freigeben, steigen in ihrer Priorität, 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öchsten Prioritätsklasse nach dem RR-Verfahren ab und dann die Prozesse der nächstniedrigeren Priorit¨ atsklasse. Wird ein Prozess mit einer h¨ oheren Priorität 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ät höher als die des Schedulers sind, nicht mehr dem RR-Verfahren und können 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önnen 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¨ aufigsten 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önnen nach unterschiedlichen Algorithmen auf einen Hintergrundspeicher,

5.4 Betriebssysteme

199

einen Massenspeicher mit langsamerem Zugriff, aber mit wesentlich größ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ötigten 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 schaffen. Die entsprechenden Algorithmen sind teilweise sehr aufw¨ andig und ber¨ ucksichtigen unter anderem auch die Zugriffshäufigkeit auf einzelne Seiten und erstellen hieraus eine Prognose (s. z. B. [82]). Die auszulagernden Seiten werden in einer oder mehreren Dateien (Auslagerungsdatei, Pagefile 29 ) oder in einem oder mehreren unformatierten Bereichen der Festplatte30 (s. Abschn. 5.2.2) abgelegt. Um den Durchsatz durch Nebenl¨ aufigkeit 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 ergriffen werden, sind folgende Szenarien m¨ oglich: • Das Betriebssystem suspendiert ganze Prozesse und lagert deren Speicherinhalte in einen eigenen Hintergrundspeicher-Bereich, das so genannte Swapfile aus. • Das Betriebssystem beendet zwangsweise einzelne Prozesse. • Das Problem wird ignoriert, was einen Deadlock (s. Abschn. 5.4.2) zur Folge hat. Die Aufl¨ osung eines solchen Deadlocks durch das Beenden eines Prozesses durch den Bediener ist oft nicht mehr möglich, da hierzu zusätzlicher Speicher ben¨ otigt wird, der dann jedoch nicht mehr zur Verf¨ ugung steht. Ger¨ ate- und Ressourcenverwaltung Die Geräteverwaltung beinhaltet auf unterer Ebene die zeitnahe Kommunikation mit der Hardware. Diese erfolgt u ¨ber Interrupts, die durch die Hardware ausgelöst werden, den Programmfluss 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 Begriff Swapfile verwendet, w¨ ahrend in anderen Systemen Swapfiles 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


schließend die Kontrolle wieder an den bis zu diesem Zeitpunkt ruhenden Programmfluss zur¨ uckgibt. Auf der n¨ achsth¨ oheren logischen Ebene werden die Geräte als Ressourcen oder als Betriebsmittel (BM) verwaltet. Ein Betriebsmittel muss nicht notwendigerweise ein physisches Ger¨ at sein. Logische oder virtuelle Betriebsmittel sind beispielsweise Kommunikationspuffer, gemeinsam von mehreren Prozessen genutzte Speicherbereiche oder Datenbanktabellen. Betriebsmittel werden im Allgemeinen durch Prozesse exklusiv genutzt, wenn schreibende Zugriffe erfolgen. Lesende Zugriffe f¨ uhren im Allgemeinen zu keinen Zustands¨ anderungen und sind deswegen in der Regel auch nebenläufig 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 first-come-first-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änkt 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 first-come-first-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 Materialfluss 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ährleistet 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ände – 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ötigten Betriebsmittel als unteilbare Operation oder die Auflösung 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 betroffenen 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 Materialflusssysteme 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 Materialflusses 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önnte. 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 Effekt 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ändert 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 Effekte 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ätzlich u ¨ ber eine OffsetVariable zur Korrektur der Zeit. Ein Zur¨ uckstellen der Uhr kann jetzt dadurch erreicht werden, dass die Softwareuhr langsamer läuft, d.h. der Offset wird durch das Auslassen einzelner Ticks langsamer erhöht, so dass die Softwareuhr zwar langsamer, aber niemals r¨ uckw¨ arts läuft. Die Problematik wird in vernetzten Systemen durch den Einsatz von Uhrenprotokollen gelöst.

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 Begriff 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önnen 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.5.1 Ubersetzer und Interpreter In diesem Abschnitt werden die wichtigsten Konzepte kurz vorgestellt und einige Begriffe definiert. F¨ ur den Betreiber einer Applikation könnte die Programmiersprache, in der sie geschrieben wurde, von untergeordneter Bedeutung sein, solange der Lieferant die korrekte Funktion gewährleistet 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ötigt jedes Programm eine Maschine, die den Programmcode ausf¨ uhren kann. In den seltensten Fällen stehen Maschinen zur Verf¨ ugung, die den Programmcode direkt verarbeiten können. 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¨ aufig 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-


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 spezifischen 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


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äufig 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 Definition, durch die Backus-Naur-Form (BNF ) oder eine der BNF ¨ ahnlichen Notation oder durch Syntaxdiagramme beschrieben. Syntaktische Einheiten werden durch Grammatiksymbole repr¨ asentiert. Die Spezifikation 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


Abbildung 5.27. Darstellung der syntaktischen Regeln einer Programmiersprache durch rekursive Definitionen 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 Definition und beim Aufruf einer Funk-


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önnen – 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


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öglichkeit 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 : +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 Definitions oder durch die Benutzung von Schemata lassen sich XML-Dokumente beschränken. Eine solche Beschr¨ ankung ist wichtig zur Validierung dieser Dokumente. Während die Zul¨ assigkeit (oder Wohlgeformtheit) eines XML-Dokumentes aus seinem Aufbau, also aus dem korrekten Umgang mit den Elementen, unabhängig 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


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 Definition 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 definiert werden, die DTD verf¨ ugt allerdings u ¨ber keinerlei Möglichkeit, 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öglich, aber aufwändig. 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ät einer Nachricht reproduzierbar verifizierbar. Die Schnittstellen können 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önnte 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.


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örige 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


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 getroffen 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älliger Ereignisse als auch gegen gezielte Angriffe 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önnen die Kommunikationsumst¨ ande ebenfalls sch¨ utzenswert sein. Die wichtigsten Aspekte sind Anonymit¨ at und Unbeobachtbarkeit der Kommunikationspartner. Das können Personen, aber auch Rechner, Programme oder Betriebssystemprozesse sein. Die Anfertigung von Kommunikationsprofilen 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önnen 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önnen sehr unterschiedlich sein. Die Sicherheit der Verschl¨ usselung sollte aber in allen Fällen 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 chiffrierte 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öglichst 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 chiffrierte 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 ======================




Lieferstermin 12.Nov. 2003




Klartext

Geheimtext

Geheimtext

Klartext

Übertragungskanal

Abbildung 5.29. Grundprinzip der Verschl¨ usselung

Unsymmetrische Verschl¨ usselungsverfahren oder Verschl¨ usselungsverfahren mit ¨ offentlichen 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ällt, 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ährend die Berechnung des Produktes der Primfaktoren leicht möglich ist, ist der umgekehrte Weg zwar m¨ oglich, aber mit einem erheblich höheren Aufwand verbunden38 . Dieser Aufwand ist von der Größ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.


217

Kd ). Der private oder geheime Schl¨ ussel Kd bleibt im alleinigen Besitz des Empf¨ angers, w¨ ahrend der ¨ offentliche 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 offentlich zug¨ anglichen Schl¨ ussel, sendet diese chiffrierte 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ähnten Primzahlzerlegung basiert (s. [81]). Die L¨ ange des Schl¨ ussels ist unabhängig vom Algorithmus und bestimmt das Maß der erreichten Sicherheit. F¨ ur heute gebr¨ auchliche Schl¨ ussel mit 128 Bit L¨ ange benötigt ein leistungsfähiger 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änge, so dass hinreichend lange Schl¨ ussel immer die geforderte Sicherheit geben. Die Verteilung der ¨ offentlichen Schl¨ ussel kann auf direktem Weg vom Sen¨ der zum Empf¨ anger durch unsichere Ubertragungskan¨ ale oder durch eine Ver¨ offentlichung u ¨ ber zentrale Dienste erfolgen. Die unsymmetrischen Verfahren haben sich auf dem gesamten Gebiet der Sicherheitstechnik in offenen Systemen durchgesetzt. 5.6.2 Integrit¨ atssicherung Eine Nachricht darf auf dem Weg vom Sender zum Empfänger nicht durch Dritte verf¨ alscht werden. Diese Integritätssicherung sch¨ utzt vor den Angriffen Dritter. Beispielsweise k¨ onnten Bestellmengen, die letztlich in einem WMS ¨ zu Auslagerungen f¨ uhren, auf dem Ubertragungsweg geändert werden. Die Folge k¨ onnte die Auslieferung des gesamten Bestandes sein, der dann f¨ ur zuk¨ unftige Auftr¨ age anderer Kunden – bis zur Klärung des Vorfalles und einem eventuellen R¨ ucktransport – nicht mehr verf¨ ugbar wäre. 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 öffentlichen Schl¨ des Empf¨ angers verf¨ ugen. 5.6.3 Authentifizierung usselung Die Integrit¨ at einer Nachricht kann durch den Einsatz von Verschl¨ gesichert werden. Beim Einsatz unsymmetrischer Schl¨ ussel kann Jeder mit

218


Hilfe des ¨ offentlichen Schl¨ ussels eine Nachricht an dessen Eigent¨ umer absetzen und sich als jemand Anderes ausgeben. Beispielsweise ist es leicht möglich, Bestellungen im Namen anderer Kunden an einen Lieferanten abzusetzen. Der Lieferant muss sich aber darauf verlassen können, dass der Absender der Bestellung mit dem in der Bestellung Angef¨ uhrten identisch ist. Dieses Problem der Authentifizierung kann ebenfalls durch den Einsatz unsymmetrischer Schl¨ ussel gel¨ ost werden. Es existiert eine Vielzahl von Authentifikationsprotokollen (s. [55]), die entweder eine zentrale, vertrauensw¨ urdige Instanz oder die gegenseitige Kenntnis der ¨ offentlichen 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 Authentifizierungsprozedur 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 öffentlichen 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 offentlichen 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 öffentlichen Schl¨ ussels des jeweils anderen Kommunikationspartners, insbesondere eine vertrauensw¨ urdige Zuordnung des Schl¨ ussels zum Teilnehmer, voraus. F¨ ur die Verwaltung


219

ussel existieren Trustcenter, welche f¨ ur diese Vertrauensw¨ uröffentlicher 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änger kann es wichtig sein, ihre Echtheit zu beweisen. Hier wird ebenfalls das grundsätzliche 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önnen also mit dem offentlichen 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 ¨ offentlichen Schl¨ ussel des Empfängers codiert. Die chiffrierte Nachricht kann in der ersten Stufe nur vom Empfänger mit seinem privaten Schl¨ ussel decodiert werden. In der zweiten Stufe decodiert der Empf¨ anger nun mit dem ¨ offentlichen 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 Konfliktfall 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 zweistufige 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 offentlichen 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äßige Methoden und Prinzipien zum Einsatz, um ein gegebenes Ziel zu erreichen. Die Ziele eines Warehouse Managementsystems (WMS) werden z. B. im Rahmen einer Anforderungsspezifikation oder eines Pflichtenheftes festgelegt. Zunehmend seltener werden WMS komplett neu entwickelt. Um ein WMS jedoch f¨ ur einen konkreten Anwendungsfall zu r¨ usten, reichen oft die reinen Konfigurationsm¨ 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 Begriffswelt in der Informationstechnologie und ganz besonders in der Softwaretechnik ist nicht einheitlich. Die hier vorgestellten Begriffe werden in zahlreichen Werbeaussagen und Produktpräsentationen auf ganz unterschiedliche Art verwendet. W¨ ahrend Software das inhärente Problem hat, einem potenziellen Kunden gegen¨ uber nicht darstellbar zu sein, scheinen umgekehrt die Begriffe, mit denen Softwareeigenschaften beschrieben werden, zu unscharf definiert 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 Fachbegriffe schaffen.

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ätzlich sagt die Wahl der Softwarearchitektur nichts u ¨ ber die Qualität einer Software aus.

222


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 Konfigurationmechanismen 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 finden. Bei der getroffenen Auswahl liegt der Fokus auf dem Kontext Warehouse Management. 6.1.1 Monolithische Architektur Der Begriff Monolith r¨ uhrt vom griechischen Begriff 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ämtliche 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ösung 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öße eines Projektes das Projekt u ¨berproportional aufwändig 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ätten zerlegt werden k¨ onnen. Dennoch hat auch diese Form der Softwarearchitektur Vorteile: Optimierung In einer monolithischen Software besitzen alle Regionen einer Software gleichberechtigten Zugriff auf die Daten anderer Regionen. Mit diesen verh¨ altnism¨ aßig einfach zu beschaffenden Informationen können 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 Zugriff 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ächste 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


Systeme wiederum k¨ onnen weiter in Module unterteilt werden. So können 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-Begriff in der Softwaretechnik ist der der Komponente. Komponenten haben eine definierte, also wohlbekannte Schnittstelle, und deren Verhalten ist ebenso wohlbekannt. Bei einer Komponente ist streng spezifiziert, 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äge zu generieren. Die eingehenden Daten sind exakt spezifiziert und die Ausgabe ist die grafische 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 konfiguriert, teilweise auch verändert oder erweitert werden. 6.1.3 Schichtung Die Schichtung beschreibt die Einf¨ uhrung von technischen oder auch geschäftlichen 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 ¨ offnet 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


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 ändern zu m¨ ussen. Die folgenden Beispiele verdeutlichen das Konzept der Schichtung: Automatisierungspyramide Speziell auf den Bereich der Materialflussautomatisierung zugeschnitten ist das Ebenenmodell f¨ ur Materialflusssteuerungen nach VDMA 15276 [76]. Es definiert 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örderbandsegmente, Weichen oder Abschieber werden u ¨ber direkte Verkabelung oder Feldbussysteme angebunden. Dieses Ebenenmodell wird oft den Anforderungen entsprechend variiert und grafisch als Automatisierungspyramide dargestellt. Ein weiteres Beispiel f¨ ur geschichtete Systeme ist das OSI-Modell (siehe Abschn. 5.1.1).

226


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önnen 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. Benutzeroberfl¨ 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.


227

Ziel des verteilten Systems ist die M¨ oglichkeit, Aufgaben nebenläufig abzuarbeiten oder Redundanz und damit Ausfallsicherheit zu schaffen. Verteilte Systeme k¨ onnen damit Vorteile bei der Skalierbarkeit bieten: Durch den Einsatz weiterer Knoten kann die Gesamtleistung des Systems erhöht 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ätzlicher 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ächst 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öglichst 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


verlangsamt werden, kann auch dies erheblichen Einfluss 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ässig ihren Dienst versehen. Zum anderen gilt es h¨ aufig, 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ähig, um die Verf¨ ugbarkeit und Performance anzupassen. 6.1.5 Konfiguration und Erweiterung Hersteller einer Branchen-Software sind bem¨ uht, ihre Software auf möglichst viele Anwendungsf¨ alle abzustimmen. Das f¨ uhrt in der Praxis zum einen dazu, dass eine Software viel mehr kann, als man ihr tatsächlich abverlangt. Auf der anderen Seite ist vielleicht genau die Funktion, die vom Anwender benötigt 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 konfiguriert, dass nur eine dieser M¨ oglichkeiten nutzbar ist. Variantenvielfalt und Konfigurationspotenzial sind zunächst ein Vorteil: Der Anwender hat bei der Installation und m¨ oglicherweise auch bei späteren ¨ Anderungen im Betriebsablauf die M¨ oglichkeit, das Verhalten der Software anzupassen. Konfigurationspotenzial ist aber genau dann irrelevant, wenn die verschiedenen Varianten nicht tats¨ achlich benötigt werden. Im Gegenteil erh¨ oht Variantenvielfalt immer auch die Komplexität 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ätzlich gilt: Je komplexer eine logistische Unternehmung ist, desto höher ist der Aufwand f¨ ur individuelle Entwicklungen im Softwareprojekt. Weitere Hinweise und ein Vorgehensmodell zur Einf¨ uhrung und applikationsspezifischen Gestaltung von WMS finden 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äte beschrieben, die in der Lage sind, Ladeeinheiten von einem Ort zu einem anderen zu transportieren. Diese Darstellung erfolgt sowohl mit den Symbolen der UML (Unified 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 Zugriff 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 Zugriff 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 Zugriff auf die Daten. Dieses muss dann durch Programmierdisziplin vermieden werden.

230


• Die einheitliche Schnittstelle des Funktionsaufrufes abstrahiert von den zugrunde liegenden Daten. • Die Details der Zugriffsfunktionen und der unterliegenden Daten bleiben dem Aufrufer verborgen. • Die Sicherung der Datenintegrit¨ at obliegt ausschließlich den Zugriffsfunktionen und nicht dem Aufrufer. ¨ • Nachtr¨ agliche Anderungen der Funktionen können lokal und damit ohne Auswirkungen auf deren Aufrufer erfolgen. Diese ausschließliche Nutzung der Funktionsschnittstelle und das explizite Verbot eines direkten Zugriffs scheint bei einfachen“ Variablen zunächst ” sehr aufw¨ andig. Die Vorteile werden jedoch offensichtlich, wenn bei späteren Softwareerweiterungen bei jedem Variablenzugriff zusätzlich 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äglich die Forderung gestellt werden, die Zeitdauer, w¨ ahrend der ein Lagerfach gesperrt war, in einem Betriebsprotokoll aufzuzeichnen. Eine direkte Programmierung ¨ könnte 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.


231

Nach der Erweiterung des Datentypen Fach um die Variable startLock könnten 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ändert 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örenden Datenbeschreibungen und Funktionen nennt man Klasse, die Daten werden Attribute und die Funktionen Methoden dieser Klasse genannt. Eine Klasse enthält 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


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önnen auch mehrere Konstruktoren spezifiziert 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 spezifische Initialisierung der Attribute mit den wechselseitigen Abh¨ angigkeiten ihrer Werte ersetzen k¨ onnen. ¨ Diese Technik des Uberladens ist auch f¨ ur Methoden erlaubt.


233

Eine neue Instanz eines Regalbedienger¨ ates kann auf drei unterschiedliche Arten erzeugt werden: • RBG rbg1 = new RBG() f¨ ur ein neues Regalbediengerät. 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ät mit der aktuellen Position (2,3); • RBG rbg1 = new RBG("E2T3") f¨ ur ein neues Regalbediengerät 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ördergerät“ ” Ladeeinheiten von einem Lagerort zu einem anderen transportieren. Dieses Verhalten ist durch unterschiedliche technische Ausprägungen, 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 Schnittstellenspezifikation 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 definiert und die abgeleitete Klasse diese Methoden ebenfalls definiert, werden diese Methoden der Ableitung aufgerufen; andernfalls die Methode der Basisklasse. Abgeleitete Klassen können 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 Unified Modeling Language (UML)

235

6.2.4 Eigenschaften von Klassen Neben dem Prinzip der Vererbung definiert das Paradigma der Objektorientierten Programmierung noch weitere Begriffe: ¨ Uberladen Methoden, die in einer Mutterklasse definiert wurden, können 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önnten 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önnen 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ät von Systemen verwendet. Diejenigen Objekte (Entities), welche realweltliche Dinge oder Vorg¨ ange abbilden, werden dagegen seltener u ¨ ber ihre objektorientierte Hierarchie definiert; 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 befindet 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 Unified Modeling Language (UML) Die Unified Modelling Language (UML) ist eine grafische 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


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 grafischen 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ächlich ein lohnendes Ziel, hat aber zur Folge, dass Bauplan und Software simultan oder zeitnah gepflegt werden. Nicht selten wird daher auch die Variante praktiziert, bei der nach Konstruktion bereits die Anforderungs¨ anderungen nicht mehr in den UMLBauplan eingepflegt werden und die Dokumentation binnen kurzer Entwicklungszeit ihren Bezug zur Realit¨ at verliert. Dieser Effekt, zunächst 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öglichkeit, 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önnen. 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 Pflege 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ändig dokumentiert. UML dient als Hilfsmittel und kann einen sehr effizienten 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 wiederfinden. 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ährt.


237

Hinweise zur Durchf¨ uhrung von objektorientierten Projekten liefert [38]. Die hier ausgew¨ ahlten Diagramme sind die am h¨ aufigsten eingesetzten Diagramme in Warehouse Managementprojekten. Die Erfahrung zeigt, dass UML Diagramme in Softwareprojekten f¨ ur Warehouse Managementsysteme erfolgreich eingesetzt werden können. 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 treffen. • 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äufig 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 (Strichfiguren) und die von ihnen genutzten einzelnen Funktionen oder Anwendungsfälle (Elipsen) dargestellt. Die Verbinder zwischen Akteur und Anwendungsfall kennzeichnen deren Verh¨ altnis. Beispielsweise nutzt ein WE-Mitarbeiter die Funktion Ware identifizieren. Ein Verbinder zwischen den Funktionen stellt deren Verh¨ altnis zueinander dar. Diese Verbinder werden in der Regel mit einem Qualifizierer 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


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 betrifft das alle im Projekt selbst erzeugten Klassen unterhalb der Pr¨ asentationsschicht23 und bis an die Persistenzschicht24. Die dargestellten Klassen sollten einen m¨ oglichst selbsterklärenden 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 -beschaffung realisiert Variablen Funktionen


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 Eintreffen definierter 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 Grafik 6.4 gezeigt, quantifiziert 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 definier-

240


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äsentiert. Mehrere Transitionen im Diagramm d¨ urfen dieselben Ereignisse repräsentieren, sofern sie von verschiedenen Zust¨ anden ausgehen. Dadurch kann je nach aktuellem Zustand ein und dasselbe Ereignis zu unterschiedlichen Folgezuständen f¨ uhren. Nicht definierte, beziehungsweise unerwartete Ereignisse f¨ uhren nicht zu einem Wechsel des Zustandes. Auf Transitionen können auch Bedingungen (engl. guarding conditions) definiert 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. Befindet 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 befindet sich im Zustand Eingelastet. Zu einem beliebigen sp¨ ateren Zeitpunkt wird er von einem Lagermitarbeiter begonnen. Der Zustand ändert sich auf Begonnen. Ist der Transportauftrag ausgef¨ uhrt worden, f¨ uhrt ein Ereignis zum Endzustand. M¨ oglicherweise wird auch ein Fehlerzustand definiert 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 Begriff 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 Verflechtung 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 profitieren 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ägeraustausch-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äftsabwicklung 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 betreffen 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


Formate ist allerdings auch eine gewisse Interpretationsfreiheit bei der Implementierung. So enth¨ alt beispielsweise das EDIFACT-Format etwa 200 verschiedene Nachrichtenarten und viele branchenspezifische 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 Authentifizierung der beteiligten Kommunikationspartner notwendig sowie die Sicherung gegen Verfälschen und/oder Mitlesen durch Dritte. F¨ ur jeden einzelnen dieser Aspekte können prinzipiell die entsprechenden Maßnahmen ergriffen 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 Materialfluss u ordertechniksegmente bei Eingang ¨ ber Ein- und Ausschalten der F¨ bestimmter Sensor-Informationen. Die Steuerungstechnik ist die Ebene unterhalb der Materialflusssteuerung. 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¨ aufig deshalb aus, weil die Anpassung dieser Schnittstelle, die meist in der Hardware des Gerätes 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änger 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önnen Informationen in beide Richtungen zwischen den Kommunikationspartnern ausgetauscht werden. Der technische Client-Server-Begriff hat keinen Einfluss 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 eintreffen 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ändige und reihen¨ folgerichtige Ubertragung der Daten zugesichert. Störungen in der Kommunikation k¨ onnen von den Kommunikationspartnern aufgedeckt und behandelt 32

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

244


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äte, die typischerweise in einer B¨ uroumgebung eingesetzt werden, sind hier aufgrund mechanischer und elektrischer St¨ oreinfl¨ 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öglichkeiten 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äteren 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ängig gemacht werden und die Informationen verbleiben f¨ ur einen späteren 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 finden. 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öglich. 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ährleisten die Konventionen und Muster aber gute Wartbarkeit, Skalierbarkeit und Flexibilität. 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. Datenbeschaffung Datenbeschaffung 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


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ässlich. 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.


247

Gew¨ ohnlich besitzen relationale Datenbanksysteme ein ausgefeiltes Rechtemanagement. Darin k¨ onnen Rollen definiert 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ämtliche Operationen mit diesem einen Account, aber möglicherweise 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 Authentifizierungsmechanismen 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


Gesch¨ aftslogik. Beispielsweise k¨ onnte eine Auskunftsfunktion vorgesehen werden, anhand der ein Wareneingangsmitarbeiter nach einer Artikelnummer suchen kann. Des Weiteren k¨ onnte der Lagerbehälter 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 Benutzerauthentifizierung erfolgen muss. Die Anwendung in einem Application-Server kann dazu f¨ ur jede einzelne Geschäftslogik-Bean oder sogar f¨ ur einzelne Methoden einer Bean Regeln definieren. Grundsätzlich kann so das Konzept von Rollen und Anwendern realisiert werden, wie dies auch in einem relationalen Datenbanksystem möglich 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öglicht 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ält 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ächste Aufruf zum Webserver erfolgen kann und so weiter. Auch f¨ ur Web-Applikationen existieren Mechanismen zur Benutzer-Authentifizierung. Diese k¨ onnen mit den Mechanismen der u ¨ brigen Anwendung koordiniert werden. Denkbar ist prinzipiell auch, dass die Benutzerauthentifizierung ausschließlich in der Web-Applikation erfolgt und die restliche Applikation v¨ ollig offen gehalten wird. Damit wird allerdings die Authentifizierung 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 definierten Anzahl von Sekunden eine Seite nachladen soll, worauf wiederum der Webserver ein weiteres Mal das gleiche oder ein anderes Dokument ausliefert.


249

• Die Anzahl der User Interfaces ist in der Regel größer oder gleich der Anzahl der Gesch¨ aftslogiken, die von den User Interfaces genutzt werden. Die einmalige Implementierung an zentraler Stelle erfordert weniger Aufwand. • Authentifizierung von Benutzern ist Gesch¨ aftslogik und sie ist geschäftsrelevant, also sensibel. • Sp¨ atestens, wenn das User Interface nicht mehr im Application-Server ausgef¨ uhrt wird, was auch mit Web-Applikationen möglich ist, w¨ urde eine offene, unauthentifizierte Schnittstelle betrieben, die per Definition nicht kontrollierbar ist. Client ¨ Ubrig bleiben externe Zugriffe auf eine Application-Server-Anwendung. Diese Variante ist ein verteiltes System36 . Abgebildet werden diese Zugriffe 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. Zugriffe 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 Zugriffen 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ätigt 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


Oft geh¨ ort ist der Wunsch nach generischen Schnittstellen, die eine Vielzahl von m¨ oglichen Prozessen am Benutzerinterface abdecken können. Der Aufwand, einen ge¨ anderten Prozess abzubilden, soll möglichst gering gehalten werden. Generische Schnittstellen sind aber definitionsgemäß nicht prozessspezifisch. 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 Prozessflexibilität, aber schlechter Performance 2. hoch spezialisierte Schnittstellen mit einem Maximum an Performance, aber schlechter Prozessflexibilit¨ at Das Application-Server-Konzept, insbesondere die aktuellen Entwicklungen, versuchen hier einen guten Kompromiss zu finden. Es können hoch performante Applikationen entwickelt werden. Dabei ist der Aufwand bei ¨ Anderungen f¨ ur eingearbeitete Entwickler u ¨ berschaubar und selbst häufige 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äftsprozesse 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 SchnittstellenSpezifikation 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ärer 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ägt dazu bei, die Abh¨ angigkeiten einer Software klein zu halten, und leistet einen Beitrag zur Robustheit einer Software. Auffindbarkeit Services sind selbstbeschreibend, so dass sie u ¨ ber Suchmechanismen gefunden und dann genutzt werden können. Dieser Aspekt wird durch den Service-Kontrakt erm¨ oglicht und fördert damit die Wiederverwendbarkeit. Auffindbarkeit kann auch durch ein Dienste-Verzeichnis (engl. Repository) gew¨ ahrleistet werden. 40 41 42

¨ Der Fachbegriff 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


Die Beteiligten (Aufrufer und Aufrufender) können 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äufer 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 Fernzugriff exponiert, sondern ganze Serverobjekte mit ihren Methoden stehen f¨ ur entfernte Prozesse zur Verf¨ ugung. CORBA ist plattformunabhängig 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 Zugriff 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ängig. 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 definiert, wie sich Dienste (Server) und Dienstnutzer (Clients) in einem Netzwerk finden. 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öhten oder sogar inflation¨ 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öhere Abstraktion und mehr Kommunikation st¨ arker belastet. Unter dem Begriff 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ängenden, 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 schaffen. Dies bietet zum einen den Vorteil eines u ¨berschaubaren Arbeitspaketes zur Realisierung und erm¨ oglicht andererseits einen guten Vergleich 44

45 46

Eine offizielle 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


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 betroffenen 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äne, 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 offenes Warehouse Managementsystem, das unabhängig von Hardware und Betriebssystem und in einer auf breiter Basis akzeptierten Programmiersprache implementiert ist, ist zur Schaffung einer Kompatibilit¨ at zu Produkten und Bausteinen verschiedener Quellen und Hersteller hilfreich. Dadurch kann eine effiziente 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 offenen 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 Materialfluss und Logistik, Dortmund siehe hierzu http://www.mywms.org siehe hierzu http://www.mywms.org/community/partners.jsp

256


von myWMS LOS steht ein vollwertiges WMS zur Verf¨ ugung, das ebenfalls unter der GPL Lizenz ver¨ offentlicht ist4 . myWMS LOS ist gem¨ aß der Java Enterprise Edition 5 (Java EE 5) Spezifikation (vgl. Abschn. 6.5) programmiert. Die Spezifikation umfasst die Architektur von modularen Softwarekomponenten und Diensten zur Programmierung von verteilten, mehrschichtigen Anwendungen. Dar¨ uber hinaus beschreibt sie definierte Schnittstellen zwischen Komponenten und LaufzeitContainern, sodass eine hohe Interoperabilit¨ at zwischen diesen sowie eine hohe Skalierbarkeit der gesamtem Anwendung gewährleistet ist. Eine Schulungsversion von myWMS LOS mit weiteren Informationen, Quelltexten und einer Beispielapplikation ist online verf¨ ugbar. Details zur Installation finden sich am Ende des Buches. In diesem Kapitel wird zun¨ achst ein allgemeines Datenmodell diskutiert, wie es in der Praxis bei vielen Warehouse Managementsystemen anzutreffen 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öme 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 spezifiziert werden. Datencontainer des Modells Die nummerierten Kästchen 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 Spezifizierung 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äsentierenden Container, nur eine Kundennummer oder die ausf¨ uhrliche Auff¨ uhrung der den Kunden beschreibenden Daten wie Vorname, Name, Lieferadresse, Rechnungsadresse, Telefonnummern etc. stehen. Wichtig ist an dieser Stelle zunächst, dass die Container in dem Modell vorhanden und deren Bedeutungen eindeutig definiert 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äsentiert. 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äts-

258


sicherung und Warenwirtschaft) ben¨ otigt werden (s. 262). Dabei wird hier jeder Container doppelt benannt: zuerst deutschsprachig, gefolgt von einer technischen Benennung aus Begriffen der englischen Sprache. Begriffe, 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 befinden 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ält 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ähigkeiten 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ätze einer Zone oder Lagergruppe zugeordnet sowie nach anderen Kriterien klassifiziert werden. • Transportauftrag (OrderChain): Der Container 13 hält Daten u ¨ ber die einzelnen Bewegungen der Ladehilfsmittel zwischen Lagerplätzen. 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) zugegriffen 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önnen Klassifizierungen 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 befinden können. 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är Ladeeinheiten aufnehmen. Kurzfristig dient eine Maschine damit als Lagerplatz“. ” • Lagerplatz (Location): Im Container 11 werden die Lagerplätze erfasst. Ein Lagerplatz kann belegt oder frei sein. Zusätzlich 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 klassifizieren 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öglich, 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


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önnte 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ört. 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ält. 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ährend 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ärend. 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ätze lassen sich in Zonen gruppieren und jeder Zone k¨ onnen viele Lagerplätze angehören. 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


Weitere Relationen sind m¨ oglich, die aber selten benötigt 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ähigungen 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önnen zum Beispiel auch auf die Artikelgruppenzugehörigkeit 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ände und die kurzfristige Verletzung der Integrit¨ at durch einseitige Daten¨ anderung. Dennoch wird dieses Verfahren in der Praxis h¨ aufig 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ötigt. 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 spezifische Daten nur f¨ ur das WMS und solche f¨ ur das WWS enthält. 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äufiger, im Extremfall ¨ bei jeder Anderung, synchronisiert werden.

7.2 Klassische Realisierung eines WMS In diesem Abschnitt werden Teilaspekte einer möglichen 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 befindlichen 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ätzliche Techniken, wie sie unter Einsatz einer Datenbank u ¨ blich sind, erläutert.

264


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äuft, oder die • Client-Server-Systeme (vgl. Abb. 7.4), die verteilte Arbeitsstationsrechner mit spezifischer 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önnen immer lokal erfolgen und bed¨ urfen keines Datenbankzugriffs. 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.


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önnen. 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ändigkeit 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öschen von Artikelstammdaten gesichert sein, dass sich keine Artikel mit der Artikelnummer des zu l¨ oschenden Datensatzes mehr im Lager befinden 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ösungen). Diese Form der Datenhaltung und des Datenaustausches finden z. B. bei Tauschbörsen 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 treffen. 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ährend 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önnen, muss die spezifische 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ällt die 8

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

266


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 spezifizierten Felder einer Tabelle geschrieben. Unabdingbar bei der Arbeit mit relationalen Datenbanken und den zugeh¨ origen Tabellen ist die eineindeutige Vergabe von Primärschl¨ usseln zur Identifizierung einer Datenzeile. Die Struktur der Datenbank-Tabelle ItemData könnte, wie in Tabelle 7.1 dargestellt, aussehen. Das Feld photo hat in dieser Struktur eine Länge 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öglichkeit 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öglichkeiten zur Verwal¨ber die URL, vielf¨ tung und Darstellung zur Verf¨ ugung.


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önnte spätestens 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ätzen 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


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örigen Zeile gebildet werden kann. Der Verzicht auf eine solche Referenztabelle w¨ urde zu einer stark redundanten Datenhaltung und daraus resultierenden zusätzlichen 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


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ässig und muss vermieden werden. Allerdings darf eine location zusätzlich einer Gewichtsklasse zugeordnet werden, die u ¨ ber das gleiche Feld repräsentiert 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ät 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 Zugriff auf die in der Datenbank abgelegten Datensätze und deren Manipulation durch einen Anwender erfolgt mittels einer datenbankspezifischen 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


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äge durch Variablen u ¨ bergeben werden. Im Beispiel stellt stockUnitCount eine sequence dar, welche die Anzahl der Datens¨ atze in der Tabelle stockUnit enthält: 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ählt 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ätze 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ählten 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 schafft wohldefinierte Kommunikationsschnittstellen zu externen Systemen und interne Schnittstellen zu den auswechselbaren Modulen, den so genannten Plug-Ins. Letztere werden in Form von Java-Interfaces spezifiziert 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 Datenzugriff werden nun u ¨ ber den Applikationsserver bereitgestellt.

272


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 Materialflusssteuerungen. 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ägern u ager bis hin zu r¨ aumlich verteilten Lägern mit hetero¨ber automatische L¨ genen Strukturen sind die unterschiedlichsten Szenarien denkbar. Die Anpassung an bestehende L¨ ager wird durch die Möglichkeit 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 profitieren. 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 Lauffähigkeit auf unterschiedlichsten Rechnerarchitekturen und Betriebssystemen gewährleistet werden.


273

Verteilbarkeit: Die Module eines WMS sollten auf mehreren kooperierenden Rechnern nebenl¨ aufig betrieben werden können. So kann beispielsweise die Materialflusssteuerung auf einem anderen Rechner als die eigentliche Lagerverwaltung ablaufen. Die Plattformunabhängigkeit 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ängige Parametrierbarkeit der Module erlauben. Das Konfigurationskonzept 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 applikationsspezifischen 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ätzlicher 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 Spezifikation. Das Framework besteht aus drei logischen Hierarchieebenen: aus der Bestandsverwaltung, der Lagerortsverwaltung sowie einer optionalen Materialflusssteuerung (s. Abb. 7.9). Die Bestandsverwaltung (Inventory Manager ) hat die Aufgabe, die Artikelstammdaten (ItemData) und die artikelbezogenen, standortunabhängigen 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 Materialflusssteuerung (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 Materialflussrechner auf myWMS-Basis erstellt werden. 7.3.2 Gesch¨ aftsobjekte Die Aufgabe der einzelnen Schichten ist die Verwaltung der zugehörigen Daten, die in Gesch¨ aftsobjekten (Entitäten) gespeichert sind. Jedes Geschäftsobjekt 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.


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 projektspezifisch um zusätzliche Attribute, wie etwa eine Abbildung, erweitert werden. Diese Ableitung wird dann in einer ItemData erweiternden Klasse zusammen mit ihren Accessor-Methoden deklariert und definiert. 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


@Column(nullable = false) zeigt an, dass das Attribut immer definiert 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äftsprozesse zu modellieren und zu implementieren. Typische Geschäftsprozesse 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) geschaffen wurde, um diese Geschäftsprozesse dienstebasiert abzubilden. myWMS LOS verf¨ ugt u ¨ ber fertig modellierte Geschäftsprozesse und erm¨ oglicht eine Anpassung an konkrete, projektspezifische Anforderungen im Bedarfsfall. Durch die typische Flexibilität von Open-Source Projekten k¨ onnen beide Projekte nahtlos integriert werden. Die drei logischen Schichten Bestandsverwaltung, Lagerortsverwaltung und Materialflusssteuerung werden, aus Sicht der Informationstechnik, durch je ein Modul abgebildet. Module k¨ onnen jeweils einzeln (z.B. nur die Materialflusssteuerung) oder in Kombination (Lagerplatz- und Bestandsverwaltung, aber ohne Materialflusssteuerung zur Abbildung eines manuellen Lagers) in einen Applikationsserver (Abschn. 6.5) zur Ausf¨ uhrung gebracht werden. Jedes Modul (Module) definiert in einem Persistenz-Archiv die modultypischen Gesch¨ aftsobjekte (Entities) sowie deren Datenzugriffsdienste (Entity Services). Komponenten (Components) aggregieren die Datenzugriffsdienste und stellen einen definierten Satz von Diensten zur Abbildung von Gesch¨ aftslogik zur Verf¨ ugung. Diese Dienste können wiederum von Benutzeroberfl¨ achen oder von automatisierten Schnittstellen genutzt werden. Im Falle der Benutzeroberfl¨ achen wird der Zugriff 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 Workflow Engine aufgerufen werden. Die Sammlung aller Module bildet die Applikation. Durch das Einbringen zus¨ atzlicher Module, die f¨ ur sich alleinstehend Funktionalität bereitstellen oder die Dienste existierender Module nutzen, können beliebige Erweiterungen der Gesamtapplikation vorgenommen werden, wie in Abbildung 7.10 veranschaulicht.


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ät und definiert Operationen zum Erzeugen, Abfragen, Aktualisieren und Löschen derselben15 . Die Mutterklasse aller Entity Services ist der BasicService, der Operationen zum Abfragen (get) und L¨ oschen (delete) einzelner Entitäten definiert. F¨ ur die Entit¨ at ItemData gibt es eine Ableitung ItemDataService, die zus¨ atzlich eine Operation zum Erzeugen (create) einer Instanz von ItemData definiert sowie weitere spezielle Operationen. Zu beachten ist, dass Services zun¨ achst nur u ¨ ber ein Interface definiert werden, das zugesicherte Operationen, deren Parameter und R¨ uckgabewerte sowie eventuelle Ausnahmen (Exceptions) auflistet. Die Programmierung von Funktionalität 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 Begriffe Create, Retrieve, Update und Delete heißen diese Operationen auch CRUD Operationen.

278


* 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äftsprozesse. Diese nehmen h¨ aufig 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(


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ächst 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 authentifizierten 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


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

Facade Services Eine Fassade (engl. Facade) definiert eine einheitliche Schnittstelle zum Zugriff auf die Gesch¨ aftslogik von außen. Während 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 auffindbar 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 Benutzeroberfl¨ 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 spezifiziert und der Datenaustausch findet 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.


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äufig 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önnen. Dieses Environment wird in folgende Themengebiete gegliedert: Kommunikation: Das Channelkonzept von myWMS ermöglicht 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


des Projekts - heute industriellen Anforderungen vollauf gen¨ ugen. Dies betrifft 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 Klassifizierung ist konfigurierbar, z.B. nach • • • • • •

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

und erm¨ oglicht eine qualifizierte Offline-Analyse der gespeicherten Nachrichten. Das Darstellen und Erfassen von Informationen ist Aufgabe der Clientapplikationen. In der Schulungsversion werden zwei Ansätze eingebunden: Der erste Ansatz realisiert eine reichhaltige, in Java programmierte Benutzeroberfl¨ 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äuft in jedem Webbrowser und somit auch auf den meisten Handgeräten und Staplerterminals. Ein Beispiel ist der Vorgang des Kommissionierens mit Hilfe eines mobilen Endger¨ ates.

7.4 Beispielhaftes Distributionssystem/Referenzlager Dieses Kapitel stellt ein fiktives Lager f¨ ur Elektrokleingeräte 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 gepuffert. 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ätspr¨ ufung enthält. 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ät 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 identifizieren. 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 befindet sich eine Blechtafel, die pro Lagerfach ein Etikett enth¨ alt, auf dem der Lagerplatzname als Barcode und in Klarschrift sowie evtl. eine Pr¨ ufziffer kodiert ist. Die Benennung der Lagerplätze 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


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

laufend aufsteigend. Die Nummerierung der Lagerfächer 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ängsrichtung ausgelegt. Jedes der acht Regale besteht aus 50 F¨ achern in horizontaler und zehn Fächern 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ät (RBG, vgl. Abschn. 3.2.2) bedient. Die Lagervorzone stellt die materialflusstechnische Verbindung der Funktionsbereiche her. Als Querfördertechnik 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 ” Pufferplatz, von dem kommissioniert wird, sowie einem vorund 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 Pufferkapazit¨ 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-


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ählt er im myWMS LOS Client unter Men¨ upunkt Dialoge den Unterpunkt Wareneingang an. Es ¨ offnet 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ählt 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 Identifikationsnummer. 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 ” finden 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ässt er diesen Eintrag offen. Nach Klicken der Schaltfl¨ 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


Abbildung 7.13. Dialog Wareneingang

ßendes Klicken auf die Schaltfl¨ 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ätes. Hierzu muss sich dieser zun¨ achst am System anmelden. Auf der Startseite wählt der Mitarbeiter den Punkt Einlagerung“ aus. Es ¨ offnet 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 Identifikationsnummern 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 ”


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¨ uffalldialog. 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 Identifikationsnummern 000001 bis 000003. Die Lagerplätze tragen die Identifikationsnummern R1-1-2 bis R1-1-4. Einlagern in das HRL Das Aufsetzen einer Palette am I-Punkt hat die Identifizierung der Ladeeinheit u ¨ber die stationäre 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ätte 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 identifizieren 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 Profil 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öht die Zugriffssicherheit; die ABC-Zonung erm¨ oglicht einen schnellen Zugriff auf die schnelldrehenden Artikel bei der Auslagerung. Sind keine entsprechenden Lagerplätze verf¨ ugbar, kann ein Artikel prinzipiell auf jedem freien Lagerplatz eingelagert werden.

288


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öglichst 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ät im Log-in Dialog im Web anmelden. Auf der Startseite wählt er den Punkt Kommis” sionierung“ aus. Es ¨ offnet sich ein Fenster, in dem er den zu kommissionierenden Auftrag zur Bestellung VM10096 auswählt 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


289

Artikels Drucker X entnehmen soll. Nach Entnahme bestätigt 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ät gibt ihm an, dass er alle Positionen des ausgew¨ ahlten Kommissionierauftrages erledigt hat. Im nächsten 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ät 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äge 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äß ihrer Priorisierung der Reihe nach abgearbeitet werden. Auf Basis der Kundenauftr¨ age erzeugt das WMS Auslagerauftr¨ age und wählt 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öglichst 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ähernd gleich sein. Paletten, die nicht kommissioniert werden m¨ ussen, verlassen das Lager u ¨ber Querverteilwagen und Auslagerbahn. Auf dem Querverteilwagen findet ¨ bei der Aufnahme der Palette vom Ubergabeplatz des HRL eine Identifizierung 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 Pufferplatz im Warenausgang zu fördern.

290


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 identifizierte 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 Pufferplatz 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ät den Punkt Versand“ aus. Es ¨ offnet sich ein Fenster, in dem er den zu versenden” den Auftrag zur Bestellnummer VM10096 auswählt 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ätigung der Richtigkeit gr¨ un (Abb. 7.16). Nach Klick auf Weiter“ gibt ihm das Handgerät 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 befinden, 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älter ¨ 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 befindlichen 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 Benutzeroberfl¨ 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 definiert werden, die vom Pick-By-Light System aufgerufen werden kann. Die Fassade enthält 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


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 äußerst einfach, da auf vorhandene Dienste zugegriffen 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);


293

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

Mit der Definition einer projektspezifischen 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ächst aus der im Lager vorhandenen Sensorik und Identifikationstechnik bezogen. Als Identifikationsmedium kommt ein auf dem Ladehilfsmittel angebrachtes Barcode-Label zum Einsatz. Die Applikation des Labels geschieht während 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 identifiziert werden. Eine dieser Lesestellen befindet sich station¨ ar am Anfang der Einlagerbahn zur Identifikation von Paletten, die in die Systemgrenze eintreten. Die zweite Lesestelle ¨ befindet 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ätze 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 Materialflussrechner 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


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ördertechnik: je eine f¨ ur jedes Regalbedienger¨ at, eine f¨ ur den Querverteilwagen sowie eine SPS zur Steuerung der restlichen Lagervorzone inkl. der Kommissionierplätze. Die SPS-Ebene bildet die gemeinsame Schnittstelle zwischen unterlagerter Steuerung und u ¨berlagerten Systemen. 7.5.3 Materialfluss Die grunds¨ atzlich m¨ oglichen Wege einer Palette durch das Referenzlager ergeben sich durch die beschriebene Topologie und die eingesetzte Fördertechnik.


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örderrichtung 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 findet, sofern er existiert. In der Praxis ist es ausreichend, diese Klasse gemäß 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ällen ausreichend. Der Aufruf von findWay() erfolgt durch die Methode route() des Plug-In-Interfaces. Alternativ besteht die Möglichkeit, 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 ConfigurationClientInterface.

296


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 befindlichen 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 Konfigurationsdatei vorgenommen. Der Konfigurationsmanager 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 Konfiguration 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 Materialfluss steuert. Im Rahmen dieser Kommunikation sendet und empfängt

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 Konfiguration

eine Komponente Objekte, w¨ ahrend die angeschlossenen Geräte 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 ¨ offentliche 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


> DeviceStateEvent data:String type:String > DeviceAliveEvent

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

> DirectedMessage

> DeviceReadEvent data:String unit:String

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

storageLocation:String localSortingOrder:String > MfcStateEvent operationMode:String localSortingOrder:String > MfcTransportEvent storageLocation:String unitLoadKods:String unitLoads:String > MfcModifyRequest

> DeviceWriteRequest

storageLocation:String unitLoadKods:String unitLoads:String

data:String commandArgument:String > DeviceCommandRequest command:String commandArgument:String

> MfcStateRequest

> MfcTransportOrder > Response errorCode:String

orderNummer:String transportSource:String transportDestination:String unitLoadKods:String unitLoads:String > 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 anwendungsfallspezifische Erweiterungen vorgesehen.


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ändig sein, Daten f¨ ur ein oder mehrere ComObjects enthalten, unvollständige Teile des nächsten enthalten oder fehlerhaft sein. Aus vollst¨ andigen Bytefolgen werden ComObjects erzeugt und in einem Array zur¨ uckgegeben. Unvollständige Bytefolgen m¨ ussen bis zum n¨ achsten eval-Aufruf zwischengepuffert 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äsentieren Protokolle f¨ ur den Datenaustausch mit Materialflussrechnern. Ein universell einsetzbares Protokoll ist durch die Klasse XMLProtokoll gegeben. Hier können die Flexibilität der XML-Metasprache sowie aller XML-Tools genutzt werden.

300


<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ät 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öglichkeit 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ährend dieser Zeit sichergestellt werden. Im Rahmen der Realisierungsmaßnahmen kann es zu St¨ orungen kommen, wobei die Gr¨ unde sehr vielfältig sein können (beispielsweise Anpassungsschwierigkeiten bei der Umsetzung der neuen Arbeitsanl¨ aufe, Hemmnisse bei der Bedienung der neuen Software und Integrationsprobleme bei der neuen Hardware). Solche Störungen sind sowohl zeitals auch kostenintensiv und m¨ ussen soweit wie möglich 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ällen 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 Materialfluss- und Lagertechnik) definiert 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 definierte 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-off: 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-off-Meetings die Arbeitsschritte, Projektziele sowie die erforderlichen Formalien (z. B. Protokollf¨ uhrung, Projektdokumentation, Datenaustausch) vereinbart. Weiterhin erfolgt die Abstimmung zur temporären 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äftsleitung unterst¨ utzt wird und dass die Projektleitung die notwendige Befugnis besitzt, Entscheidungen zu treffen 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äufe und ¨ Technologien erzielt und es werden Angste vor Veränderungen genommen. Abschließend wird ein Umsetzungszeitplan erstellt, der die groben Meilensteine aufzeigt und den geplanten Zeitbedarf definiert (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ährend der Hochsaison stattfinden.

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


• Ressourcenkontrolle Reichen die zur Verf¨ ugung stehenden Ressourcen aus? W¨ urde eine Erhöhung der Ressourcen eine signifikante Steigerung der Produktivität ergeben? Wird das geplante Budget eingehalten? Ferner sind die zum Qualit¨ atsmanagement gehörenden realisierungsbegleitenden Qualit¨ atssicherungsmaßnahmen zu beachten.

8.3 Anforderungsdefinition Die Projektphase der Anforderungsdefinition 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 Effizienzgewinn zumeist im Vordergrund steht. Weitere typische Auslöser 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ätigkeiten im Lager (Value Added Logistics, VAL) • Vergabe der logistischen Leistungen an einen Dritten (Outsourcing) • ge¨ anderte Prozesse im Lager (z. B. Verbesserung der Qualitätssicherung und Dokumentation) ¨ • Anderung der Auftragsstruktur durch ver¨ andertes Bestellverhalten (z. B. stetig erh¨ ohte Kommissionierleistung durch kleinere Bestellmengen pro Auftrag, die nicht effizient 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 Anforderungsdefinition

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 Informationsflusses Das Ziel der Gesch¨ aftsprozessaufnahme ist die l¨ uckenlose Dokumentation aller Gesch¨ aftsprozesse3 im Lager. Eine u ¨ bliche Darstellungsform ist die Geschäftsprozesskette. Neben der reinen Aufnahme physischer Tätigkeiten wird hier auch der Informationsfluss 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örigen Geschäftsprozesse und Abl¨ aufe aufgezeigt. Zudem werden die wesentlichen Antwortzeiten (z. B. Maskenaufbau, Datenbankzugriff, 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 Informationsfl¨ 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 schafft.

306


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 betreffenden 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 Informationsfluss im Lager Mit Hilfe der Prozesskettenanalyse4 (PKA) k¨ onnen Schwachstellen innerhalb der Geschäftsprozesse (z. B. uneinheitliche Abl¨ aufe f¨ ur fast identische Prozesse oder keine definierten Prozesse f¨ ur Ausnahmesituationen) und des Informationsflusses (z. B. Medienbr¨ uche) aufgezeigt werden. Leistungsumfang des WMS Der vorhandene Leistungsumfang des WMS deckt nicht alle f¨ ur einen reibungslosen Betriebsablauf benötigten Anforderungen ab (z. B. fehlende Unterst¨ utzung von ungeplanten Wareneingängen 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ötigten 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. 162ff).

8.3 Anforderungsdefinition

307

Das Ziel der Schwachstellen-Analyse ist die Identifizierung aller Schwachstellen, aus denen anschließend Verbesserungspotenziale abgeleitet werden. Bei der Entscheidung zwischen Abl¨ osung bzw. Nicht-Ablösung 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 branchenspezifische) 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öß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 Klassifizierung ergeben sich die folgenden beispielhaften Anforderungen: Gesch¨ aftsprozesse und Informationsfluss im Lager Alle Geschäftsprozesse, die das Lager betreffen, sind eindeutig definiert. Der Informationsfluss und die Verwendung von Dokumenten sind vollständig beschrieben. Leistungsumfang des WMS Die Anforderungen an den Leistungsumfang (Funktionen und die dazugeh¨ origen Gesch¨ aftsprozesse und Abläufe) des neuen WMS decken die tats¨ achlichen und geplanten Forderungen vollständig 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 definiert (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


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 firmeninterne Vorschriften Ber¨ ucksichtigung finden. Das Ziel dieser Projektphase ist die vollst¨ andige Erstellung der Ausschreibungsunterlagen. 8.4.1 Definition 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


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

Abbildung 8.4. Beispielhaftes Inhaltsverzeichnis Lastenheft


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 beschaffende WMS aus Sicht des Auftraggebers erf¨ ullen muss, präzise 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ösende 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 PflichtenheftErstellung 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öglicht 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


• 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 betreffen, aber f¨ ur die Administration des WMS erforderlich sind (z. B. Anpassungsfähigkeit/Erweiterbarkeit: Der Benutzer kann ohne Unterst¨ utzung des WMS-Anbieters weitere Lager im WMS abbilden.) Neben der Darstellung der nicht gew¨ ohnlichen Funktionen zählt 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 finden: • 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ößen) ur Förder- und Lager• VDI 3649 (Anwendung der Verf¨ ugbarkeitsrechnung f¨ systeme)


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.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 qualifizierten Kreis von Anbietern, die Besuche der Anbieter beim Auftraggeber, der Angebotsvergleich und eine abschließende, Angebotspräsentation 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ät 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 qualifizierte 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 qualifiziertes Versenden der Ausschreibungsunterlagen wird dadurch ermöglicht.

316


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 verschaffen 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öglichen 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ächst häufig 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


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.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 Treffen zwischen Auftraggeber und Auftragnehmer liefert zus¨ atzliche, f¨ ur die Entscheidung hilfreiche Informationen. Einen passenden Rahmen hierf¨ ur bietet beispielsweise eine Präsentation des Angebots durch den WMS-Anbieter beim Auftraggeber. Im Rahmen der Angebotspr¨ asentation wird dem WMS-Anbieter die Möglichkeit gegeben, sein Angebot dem Auftraggeber persönlich 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äutert. Der Auftraggeber hat die M¨ oglichkeit, offene Punkte hinsichtlich des Angebots fachlich zu kl¨ aren. Die Aussagen und Erkenntnisse der Angebotspräsentation 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ärung aller offenen 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öglichkeit, 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, fließen in die Bewertung des Angebots ein. Aus der abschließenden Bewertung der vorliegenden Angebote entsteht eine Rangfolge. Die kaufmännischen 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 Pflichtenhefterstellung und der anschließenden Realisierung dominiert. Ausdr¨ ucklich zu erwähnen sind in dieser Phase die begleitenden Controlling- und Qualitätssicherungsmaßnahmen (vgl. Kapitel 8.1). Die Projektphase Umsetzung startet analog zum Kick-off-Meeting am Anfang des WMS-Projekt mit einem Kick-off-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 Pflichtenhefterstellung Das Pflichtenheft beschreibt, WIE die Vorgaben des Lastenhefts umgesetzt werden. Es bildet die Grundlage aller T¨ atigkeiten während der Realisierung und sollte integraler Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer sein. Das Pflichtenheft beschreibt im Wesentlichen, wie die Aufgaben, die ” im Lastenheft spezifiziert worden sind, gelöst 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 Pflichtenheft die Grundlage f¨ ur die Abnahme. (...) Im Zusammenspiel zwischen Auftraggeber und Auftragnehmer ist aus dem Lastenheft ein Pflichtenheft zu erarbeiten, das Grundlage des Vertrags ... ist.“([42], S. L-1) Viele Begriffe der Intralogistik sind branchen- oder firmenspezifisch. Zudem unterliegen sie einem steten, durch die Technologie getriebenen Wandel.

322


Um Missverst¨ andnisse zu vermeiden, sollte ein gemeinsames Glossar angelegt werden. Zus¨ atzlich ist der Verweis auf entsprechende Veröffentlichungen hilfreich [58]. Unterschiedliche Deutungen der im Pflichtenheft beschriebenen Leistungen werden minimiert, eine exaktere Umsetzung wird ermöglicht. Das Pflichtenheft stellt eine Verfeinerung des Lastenheftes dar (...). ” Auf der Grundlage des Pflichtenheftes und des Glossars wird ein formales Produkt-Modell erstellt, das die Anforderungen vollständig, konsistent und eindeutig beschreiben muss.“([4], S. 100) Die Aspekte bei der Erstellung des Pflichtenhefts gleichen im Allgemeinen denen bei der Erstellung des Lastenhefts (vgl. Abschn. 8.4.2). Zusätzlich wird die Umsetzung der im Lastenheft beschriebenen Anforderungen gänzlich, 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äglich zum Bestandteil des Pflichtenhefts gemacht werden. Das Studium der nachstehenden Normen und Richtlinien erleichtert die Erstellung des Pflichtenhefts. Gegebenenfalls kann deren Beachtung zu einem Bestandteil des Vertrags gemacht werden: • VDI 2519 (Vorgehensweise bei der Erstellung von Pflichtenheften) • VDI/VDE 3694 (Pflichtenheft f¨ ur den Einsatz von Automatisierungssystemen) • ANSI/IEEE 830-1998 (SRS Software Requirements Specifications) Das folgende, beispielhafte Grobschema eines Pflichtenhefts ber¨ ucksichtigt die wesentlichen, oben beschriebenen Anforderungen: • Grundlegendes (kurze, nicht funktionale Beschreibung des Projektes) – Aufgabenstellung allgemeine (gesch¨ aftspolitische) Umschreibung der Aufgabe, z. B. Ablösung 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äzise definierten Leistungskennzahlen und einer Liste der Pflichten von Auftragnehmer, aber auch Auftraggeber werden aufgef¨ uhrt.)

Das Ziel der Projektphase Pflichtenhefterstellung ist die exakte und zweifelsfreie Niederlegung aller Pflichten (Leistungen, Tätigkeiten und Funktionen) inklusive ihrer Terminierung, die zur Erf¨ ullung des Projektziels notwendig sind. Das Pflichtenheft wird durch den Auftraggeber genehmigt. Es ist möglich, das gesamte Pflichtenheft erst nach Fertigstellung durch den Auftraggeber abnehmen zu lassen. Effizienter und effektiver ist es hingegen, jedes einzelne Kapitel sofort nach Fertigstellung abnehmen zu lassen. Als Bestandteil des Vertrages ist das Pflichtenheft 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 Pflichtenheft 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. Pflichtenheft sind zu dokumentieren und zwischen Auftragnehmer und

324


¨ Auftraggeber zu kommunizieren. M¨ ogliche Gr¨ unde f¨ ur Anderungen können neue Erkenntnisse (beispielsweise hat es sich als effizienter erwiesen, den geplanten Ablauf umzugestalten), fehlende Punkte im Lasten- und Pflichtenheft sowie neue Anforderung (z. B. werden weitere Formulare und zusätzliche statistische Informationsabfragen ben¨ otigt) sein. Dokumentiert werden sollten unter anderem folgende Aspekte: • Welche Leistung/Funktion f¨ allt weg/kommt neu dazu/ändert 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ögliche Unstimmigkeiten w¨ ahrend der Abnahme vermieden, da die zwangsläufigen Unterschiede zwischen den im Lasten- und Pflichtenheft beschriebenen Funktionen und den realisierten Funktionen aufgezeigt und somit nachvollziehbar werden. Das Ziel der Projektphase Realisierung ist die Umsetzung der im Pflichtenheft beschriebenen Funktionalit¨ at innerhalb des gesetzten Zeitrahmens, mit den geplanten Ressourcen, in der gew¨ unschten Qualität.

8.7 Inbetriebnahme Die Projektphase Inbetriebnahme unterteilt sich in eine Laborphase, den ei¨ gentlichen Ubergang vom alten zum neuen WMS und die parallel stattfindenden 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ände (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ätsnah 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 Materialflusssystems nachzubilden, werden Simulationsprogramme verwendet, die eine Leistungsbestimmung und einen Test der systemspezifischen Heuristiken bei vorgegebener Auftragslast erm¨ oglichen. Derartigen Materialflusssimulatoren“ werden bei ”¨ größeren Projekten zur Planung und Uberpr¨ ufung des physischen Materialflusses h¨ aufig 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ösenden 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örungen 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¨ uckgegriffen 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öhnlich wird die direkte Umstellung dann gew¨ ahlt, wenn diese aus Gr¨ unden der gesamtbetrieblichen Situation ausschließlich innerhalb eines fest definierten 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örungen 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.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älern. 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 Pflichtenheft 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 Pflichtenheft 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 definierter 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ägigen) zusammenh¨ angenden Betrieb unter Realbedingungen und Volllast. Eine Unterbrechung des Leistungsbetriebs im Zusammenhang mit Störungen bedingt eine Wiederholung des Tests. Im Rahmen der funktionalen Leistungstests wird zunächst das Vorhandensein aller im Pflichtenheft beschriebenen Funktionen u uft. Anschlie¨ berpr¨ ßend erfolgt die Einzelpr¨ ufung der ordnungsgemäß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 Datenbankzugriffs (z. B. Anzeige der Stammdaten eines Artikels) und der Zeitraum f¨ ur eine Datenbankabfrage (z. B. offene Kommissionieraufträge) 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 Pflichtenheft 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öglich aufrechterhalten. Eine Datensynchronisation nach Behebung der St¨ orung ist zwingend erforderlich: • Auslagerungen/Einlagerungen, die nur auf Papier festgehalten wurden, m¨ ussen in das System eingepflegt werden können. • HOST- und WMS-Datenbestand m¨ ussen abgeglichen werden. • Nicht protokollierte Lagerbewegungen m¨ ussen erfasst werden. • usw. Alle im Lasten- bzw. Pflichtenheft 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.8.3 Verf¨ ugbarkeit Die technische Verf¨ ugbarkeit beschreibt die Wahrscheinlichkeit, ein Element oder ein System zu einem vorgegebenen Zeitpunkt in einem funktionsfähigen Zustand anzutreffen ([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 Materialflusssysteme ([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 empfiehlt 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. Pflege der Datenbank) bed¨ urfen, um deren Leistungsfähigkeit 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 Pflichtenheft nicht betrieben werden (z. B. die Sicherheitslichtschranken oder die Ansteuerung der Regalbediengeräte funktionieren nicht).

8.8 Abnahme

329

Klasse 2 F¨ ur einen Fehler bzw. eine Abweichung existiert nur ein aufwändiges 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änkung hinsichtlich der Nutzung des Systems dar (z. B. das Druckformat f¨ ur den Begleitschein im Warenausgang stimmt nicht exakt mit der Spezifikation 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ägt (wenn bspw. bis zur Behebung des Fehlers zusätzliches Personal eingestellt werden muss). Die Entscheidung u ¨ber eine Teilabnahme mit Auflagen und die Produktivsetzung des WMS kann nur fallweise getroffen werden. Klasse 3 Eine Abnahme kann mit Auflagen erteilt werden, die Produktivsetzung kann erfolgen. Die Umsetzung der offenen Punkte muss mit h¨ ochster Priorit¨ at erfolgen. Klasse 4 Eine Abnahme kann mit Auflagen erteilt werden, die Produktivsetzung kann erfolgen. Die zeitliche Umsetzung der offenen 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ät, mit der der Fehler behoben werden muss. Die endg¨ ultige offizielle Abnahme des Gesamtgewerks gemäß § 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


F¨ ur die Abnahmen und Tests ist vom Auftragnehmer ausreichendes und qualifiziertes 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 Materialfluss- oder ERP-Systemen hat sehr h¨ aufig 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ärker 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 Hardwareanschaffungskosten 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 Seiteneffekte 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 identifiziert 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 stattfinden. 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 hocheffiziente 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äsentation ¨ 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äten gesehen, die u ¨ ber Schnittstellen angesprochen werden. Die Kernidee ist es, durch die lose Kopplung von einfachen, unabhängigen Diensten komplexe Dienste aufzubauen. Dabei werden aufw¨ andige Prozesse durch die Komposition bzw. Aneinanderreihung von Services abgebildet. Besonders Web Services, die auf offenen 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äftigen und zusätzlich noch Prozesslogik abbilden, werden sie h¨ aufig 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¨ aufig auch Kollaborative Geschäftsprozesse. 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 zertifizierte 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äftigt. Kommt sie nicht als


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ätzlich die Komponenten SAP XI und SAP Supply Chain Management Server benötigt. 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äten 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 findet die Datentransformation f¨ ur den Aus-


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änger verstanden und verarbeitet werden k¨ onnen. Auch das Verwalten von Geschäftsabläufen 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 treffen, finden 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äftsabläufen 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 Benutzeroberfl¨ achen auf Endgeräten wie z. B. Desktops, Browser-Applikationen oder mobilen Endgeräten zur Verf¨ ugung stellt. Die Oracle Fusion Middleware wird durch weitere Komponenten ergänzt. 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äte werden bei der Oracle Middleware mit Hilfe eines sogenannten Sensor-Edge-Servers angebunden. Dieser nimmt die zur Identifikation benötigten 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ät 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ät 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


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 offene Services etabliert haben, gibt es auch immer mehr Web Services, die applikations¨ ubergreifend wiederverwendbar sind. Die Web Services Description Language (WSDL) ist eine XML-Spezifikation zur standardisierten Beschreibung von Web Services. Sun registriert diese mit WSDL spezifizierten Services per UDDI. Solcherart standardisierte Services lassen sich auch u ¨ ber Applikationsgrenzen hinaus einsetzen. Die Schnittstelle, mit der die Applikationen miteinander kommunizieren können, wird bei SUN Application Service Interface (ASI) genannt und dient zur Entkopplung der spezifischen Anwendungssystemfunktionalit¨ at von der Prozessdefinition 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 geschaffen, 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äftsbedingungen Application Link Enabling = Synchronisierung von Daten von verschiedenen SAP-Systemen Auftragnehmer American National Standards Institute = Amerikanischer Normenausschuß Application Service Interface Automatische Identifikation Business-Activity-Monitoring = die Sammlung von Analysen und Präsentationen 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äftsprozessen auseinandersetzen Composite Application Platform Suite Common Object Request Broker Architecture = objektorientierte Middleware, die plattform¨ ubergreifende Protokolle und Dienste definiert Carrier Sense Multiple Access/Collision Detection = Medienzugriffsverfahren, das den Zugriff verschiedener Stationen auf ein ¨ gemeinsames Ubertragungsmedium im Zeitmultiplexverfahren beschreibt Data Definition Language Datenträgeraustausch-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 Definition = eine Deklaration in SGML- und XML-Dokumenten zur Strukturierung Domain Name Service Enterprise Application Integration = Integration von verschiedenen Applikationen auf unterschiedlichen Plattformen zu Geschäftsprozessen 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ängebahn 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 Identifizierungspunkt Internet Protocol, IP-Adresse: Nummer zur Identifizierung eines Computers im Internet Barcode-Identnummer Intermediate Documents Internet Message Access Protocol = ein Protokoll f¨ ur den Zugriff sowie die Verwaltung von empfangenen E-Mails International Organization for Standardization Informationstechnik Java Platform, Enterprise Edition= die Spezifikation einer Softwarearchitektur f¨ ur die transaktionsbasierte Ausf¨ uhrung von in Java programmierten Webanwendungen Java intelligent network infrastructure = ein Framework zum Programmieren von verteilten Anwendungen


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 Materialflussrechner 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 Identification Number ¨ Post Office Protocol Version 3 = ein Ubertragungsprotokoll, u ¨ ber welches ein Client E-Mails von einem E-Mail-Server abholen kann Qualitätssicherung Quertransportwagen Querverteilwagen Produktionsplanungs- und Steuerungssystem Regalbediengerät Radio Frequency Identification 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


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örderanlagen. 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 Unified 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-Spezifikation 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 Definition von Auszeichnungssprachen XML Schema Definition Language = Strukturbeschreibungssprache f¨ ur XML-Dokumente eine Spezifikation, 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 mehrstufiger Umschlagsysteme. Karlsruhe, Universit¨ at Karlsruhe, Dissertation, Okt. 1999 Arnold, Dieter: Materialflusslehre. 2. Auflage. 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. Auflage. 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 Materialfluss und Logistik, November 2001 Dietze, G¨ unther ; Figgener, Olaf: Studie Lagerverwaltungssysteme und ihr Leistungsprofil. 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 Leistungsprofil. In: F+H F¨ ordern und Heben 50 (2000), Nr. 12, S. 18–19 DIN 55405 – Begriffe 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.: Materialflussrechnung. Springer-Verlag, Berlin Heidelberg, 1984 Gudehus, Timm: Grundlagen der Kommissioniertechnik. Verlag W. Girardet, Essen, 1973

346


[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. Auflage. International Thomson Publishing, Bonn, 1998 [21] Heistermann, J.: Genetische Algorithmen. B.G. Teubner Verlag Stuttgart Leipzig, 1994 [22] J¨ unemann, Reinhardt: Materialfluß und Logistik – Systemtechnische Grundlagen mit Praxisbeispielen. Springer-Verlag, Berlin Heidelberg, 1989 [23] J¨ unemann, Reinhardt ; Beyer, Andreas: Steuerung von Materialfluß- und Logistiksystemen. 2. Auflage. Springer-Verlag, Berlin Heidelberg New York London Paris Tokyo, 1998 [24] J¨ unemann, Reinhardt ; Schmidt, Thorsten: Materialflußsysteme – Systemtechnische Grundlagen. 2. Auflage. 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. Aufl. 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 ff. [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 Materialflussplanung. 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 Auflage. 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. Auflage. Oldenbourg, 2004 [40] Papageorgiou, Markos: Optimierung: statische, dynamische, stochastische Verfahren. 2. Auflage. R. Oldenbourg Verlag M¨ unchen, 1996 [41] Pfohl, Hans-Christian: Logistiksysteme – Betriebwirtschaftliche Grundlagen. 6. Auflage. Springer-Verlag, Berlin Heidelberg u.a., 2000


347

[42] Pleßmann, K.W.: Handbuch zum VDI-Bildungswerk GmbH Seminar: Lasten- und Pflichtenheft 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. Auflage. 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 Specification. 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. Auflage. 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: Materialflusssysteme – 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


[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 – Begriffe, 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 – Systemfindung. 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 Materialflusssystemen. 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. Auflage. 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. Auflage. B. G. Teubner, Stuttgart, 1984 [85] Zehnder, C. A.: Informationssysteme und Datenbanken. 5. Auflage. 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 Artificial 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 – Pagefile, 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¨ offnungsverfahren, 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 Informationsfluss, 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 Journalfile, 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 – einstufige, 41 – inverse, 50 – Organisation, 39, 42 – Strategien, 42 – zonenparallele, 41 – zweistufige, 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 Materialflussrechner, 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¨ aufigkeit, 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 Pflichtenheft, 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 – Authentifizierung, 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 Workflow 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

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

Pädiatrische Notfall- und Intensivmedizin. Kitteltaschenbuch, 4. Auflage

Wärmeübertragung: Grundlagen Und Praxis, 4. Auflage

Wirtschaftspolitik: Allokation und kollektive Entscheidung, 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

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

Pädiatrische Notfall- und Intensivmedizin. Kitteltaschenbuch, 4. Auflage

Wärmeübertragung: Grundlagen Und Praxis, 4. Auflage

Wirtschaftspolitik: Allokation und kollektive Entscheidung, 4. Auflage

Recommend Documents