Warehouse-Management : Organisation und Steuerung von Lager- und Kommissioniersystemen ; mit 48 Tabellen [3., korr. Aufl] 9783540748755, 354074875X [PDF]

Zitiervorschau

Michael ten Hompel · Thorsten Schmidt Warehouse Management

Michael ten Hompel · Thorsten Schmidt

Warehouse Management Organisation und Steuerung von Lager- und Kommissioniersystemen

3., korrigierte Auflage Mit 117 Abbildungen und 48 Tabellen

123

Professor Dr. Michael ten Hompel [email protected]

Priv.-Doz. Dr.-Ing. habil. Thorsten Schmidt [email protected] Fraunhofer-Institut für Materialfluss und Logistik (IML) Joseph-von-Fraunhofer-Straße 2–4 44227 Dortmund Germany

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN 978-3-540-74875-5 3. Auflage Springer Berlin Heidelberg New York 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. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2008 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch 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. Sollte in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z. B. DIN, VDI, VDE) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität übernehmen. Es empfiehlt sich, gegebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlinien in der jeweils gültigen Fassung hinzuzuziehen. Satz: Digitale Vorlagen der Autoren Herstellung: LE-TEX Jelonek, Schmidt & Vöckler GbR, Leipzig Einbandgestaltung: WMXDesign, Heidelberg Gedruckt auf säurefreiem Papier

68/3180/YL – 5 4 3 2 1 0

Vorwort

Heutige Lager- und Distributionssysteme stellen ¨außerst komplexe Knoten in den Wertsch¨ opfungsketten dar und unterliegen einer Vielzahl von Zeit-, Kosten- und Qualit¨ atsanforderungen. Der 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¨agt, 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¨osungen und die Verschiedenartigkeit der Systemanforderungen fordern bei Gestaltung, Auswahl und Betrieb eines WMS umfassendes Wissen und Erfahrung. Es gilt eine verwirrende Vielfalt von Aspekten abzuw¨ agen und umzusetzen, die bei der Auswahl eines solchen Systems entscheidend f¨ ur Erfolg oder Misserfolg sein k¨onnen. ¨ An dieser Stelle soll das Buch Uberblick 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¨oglicht die dazugeh¨orige ublichen PC. Simulationsumgebung den autarken Betrieb auf einem handels¨

VI

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. 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¨aftige Mitwirkung von Herrn Thomas Albrecht, Frau Susanne Grau, Herrn Jorgos Katsimitsoulias und Frau Sabine Priebs beim Satz und bei der Korrektur des Manuskriptes sowie der Erstellung der Abbildungen w¨ are die Bucherstellung ebensowenig m¨ oglich gewesen. Auch ihnen gilt unser herzlicher Dank. Die Intralogistik als identit¨ atsstiftende und inhaltliche Klammer dieser Buchreihe spannt das Feld von der Organisation, Durchf¨ uhrung und Optimierung innerbetrieblicher Materialfl¨ usse, die zwischen den unterschiedlichsten Logistikknoten stattfinden, u ¨ ber die dazugeh¨origen Informationsstr¨ome bis hin zum Warenumschlag in Industrie, Handel und ¨offentlichen 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

VIII

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.

IX

X

Inhaltsverzeichnis

7.

Datenmodell eines WMS am Beispiel myWMS . . . . . . . . . . . 7.1 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Klassische Realisierung eines WMS . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Tabellenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Sicherung der logischen Integrit¨ at . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Anlegen und Abfragen von Stammdaten . . . . . . . . . . . . . 7.4 myWMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Grunds¨ atzlicher Aufbau von myWMS . . . . . . . . . . . . . . . 7.4.2 Gesch¨ aftsobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Kernel-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.4 Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Beispielhaftes Distributionssystem/Referenzlager . . . . . . . . . . . 7.5.1 Beschreibung des Beispiels . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Beschreibung des Lagersystems . . . . . . . . . . . . . . . . . . . . 7.5.3 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.4 Lagertechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.5 F¨ ordertechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.6 Steuerungstechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.7 Materialfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.8 Logistische Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Aufbau der Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7 Plug-In - Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

255 256 262 265 267 269 270 271 274 276 277 279 279 279 279 280 281 282 284 284 286 288 291

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

295 296 297 298 298 300 301 303 303 305 308 308 308 310 311 314 314 314 315 315

Inhaltsverzeichnis

9.

XI

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

317 318 318 319 320 320 320

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

325

321 322 322

325 327 328 329 332 333

Abk¨ urzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

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¨atigkeiten und Aufgaben sind in einem Lagersystem nur dann zu erreichen, wenn ein auf die speziellen Anforderungen zurechtgeschnittenes System geformt wird, das sich aus • der technischen Grundstruktur, • dem betrieblich-organisatorischen Rahmen und • der alles koordinierenden Systemf¨ uhrung zusammensetzt. Fragen der Planung der technischen Systemstruktur betreffen beispielsweise die Layoutierung des Systems, die Auswahl und Dimensionierung der f¨ order- und lagertechnischen Gewerke oder die Gestaltung der physischen Schnittstellen zu angrenzenden Systemen. Die Behandlung dieser Fragen ist Gegenstand unz¨ ahliger Ver¨ 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¨at (Umfang und Dynamik) der Abl¨ aufe praktisch nur durch Einsatz rechnergest¨ utzter Managementsysteme beherrschbar wird. Die mit den zahlreichen Funktionalit¨aten versehenen Steuerungssysteme reifen aber auch ihrerseits zu immer komplexeren und schwierig zu fassenden Systemen. Eine große Schwierigkeit besteht deshalb in der 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¨alle im Betrieb sind nicht nur kostentr¨ achtig, sondern k¨onnen durch die Gefahr der Abwanderung von Kunden, eines schlechten Rufes auf dem Markt oder m¨ oglicher Regressforderungen auch den mittel- und langfristigen Unternehmenserfolg gef¨ ahrden. Entscheidend ist also, ein passendes System mit sehr hoher Verf¨ ugbarkeit zu schaffen. Es geht in diesem Buch daher nicht nur um die Frage, wie Lager- und Distributionssysteme technisch gestaltet werden k¨onnen, sondern auch darum, wie sie im Zusammenspiel der Systeme sinnvoll betrieben werden k¨onnen. Das f¨ ur diese Umsetzung erforderliche Wissen und Handwerkszeug soll durch ¨ dieses Buch bereitgestellt werden. Es soll Ubersicht 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¨aufig negative Eigenschaften verbunden werden, ist die Lagerung von Waren in der Praxis aus vielf¨ altigsten Gr¨ unden in den meisten Bereichen unumg¨anglich. Eine aus logistischer Sicht wesentliche Besonderheit ist dabei, dass es sich um einen geplanten Prozess der Zeit- und Zustands¨ uberbr¨ uckung handelt [24]. Einige wesentliche Gr¨ unde zur Errichtung und zum Betrieb von Lager- und Distributionssystemen entlang 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¨ahigkeit beschreiben l¨asst. 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¨oherfrequenten Auftragserteilung geringerer Teilmengen und die g¨ angige Forderung nach immer k¨ urzeren Lieferzeiten lassen die logistische Leistung zu einem entscheidenden Kriterium f¨ ur die Auswahl eines Lieferanten werden. Durch Einsatz leistungsf¨ ahiger und 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¨at von Produktionsketten, die nach dem Just-In-Time-Ansatz (richtigerweise) auf eine konsequente Minimierung der Best¨ ande entlang der Lieferkette ausgelegt sind, ließ sich in der Vergangenheit immer wieder an markanten Stillst¨ anden ganzer Produktionslinien in der Automobilindustrie ermessen, wenn aus Gr¨ unden wie Grenzblockaden aufgebrachter Fernfahrer oder Streik in externen Zulieferbetrieben wichtige Bauteile nicht rechtzeitig verf¨ ugbar waren. Die Sicherstellung der Materialverf¨ ugbarkeit zur Auslastung kostenintensiver Produktionsstufen ist nach wie vor eine der Hauptursachen der Bestandsbildung. Erbringung zus¨ atzlicher Dienstleistungen: L¨angst gehen die Anforderungen an ein Lager u ¨ber die kurzfristige Bereitstellung eines einzelnen

4

1. Einleitung

Produktes oder Artikels hinaus. Einerseits w¨achst die Variantenvielfalt durch die aus Sicht des Produktmarketings reizvolle 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¨oglichst sp¨aten Zeitpunkt unter Verwendung weniger Grundelemente. Dabei werden solche Produktionsschritte zunehmend als Montagedienstleitungen in Warenverteilzentren durchgef¨ uhrt. Andererseits k¨ onnen auch Fertigprodukte die Spezialisierung auf verschiedene Verkaufskan¨ ale, beispielsweise durch die sp¨ate Anbringung von Verkaufsinformationen (Label etc.) oder den Aufbau von Aktionsst¨anden zu verkaufsf¨ ordernden Maßnahmen, erfahren. Transportkostenreduktion: Einer der Hauptgr¨ unde zur Bestandsbildung bleibt das Ziel, Transportkosten zu optimieren und sprungfixe Kostens¨atze im Transportgewerbe durch m¨ oglichst gute Nutzung der Laderaumkapazit¨ aten (Ganzladungen) zu nutzen. Eng damit verbunden ist aber auch die Notwendigkeit einer Optimierung der Umschlagprozesse in Warenein- und -ausgang. Die Bearbeitung einer Vielzahl kleiner Mengen ist in der Regel wesentlich 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¨aten einer laufenden Bereitschaft zur Warenannahme (Personal und Ladetore), so dass an diesen Schnittstellen bedarfsgerechte Liefermengen gesammelt angeliefert werden m¨ ussen. Ausgleich von Bedarfs- und Liefermengen: Trotz der l¨angst vollzogenen Wandlung vom Verk¨ aufer- zum K¨ aufermarkt und der damit verbundenen Auslegung der Produktionscharakteristik in Richtung bedarfsgesteuerter Produktion (Pull-Systeme) bleibt in vielen Bereichen die wirtschaftliche Notwendigkeit einer Produktion in entsprechenden Losgr¨oßen bestehen. Innerhalb der Produktion sind einzelne Produktionsphasen durch verschiedenartige Prozesszeiten und Ausbringungsmengen oder unregelm¨aßige Zu- und Abg¨ ange zwischen Bereichen gekennzeichnet. Die Vermeidung von Leerlaufzeiten erfordert wiederum die 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¨atskosten wie z.B. Administrationskosten (Durchf¨ uhrung der Bestellung, Preisverhandlungen) gegen¨ uberstehen. Lagerung als Prozessschritt: Bei verschiedenen Produkten oder Abl¨aufen stellt die Lagerung einen elementaren Prozess der Wertsch¨opfung oder -steigerung dar (z.B. durch Reifung oder spekulative Absichten) und wird damit zu einem Teil des Produktionsablaufes. Wie sich aus dieser Auflistung entnehmen l¨asst, 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¨otigt und deshalb zur Seite gelegt, bis zu dem Zeitpunkt, zu dem ein Kunde ihn verlangt. Er wird dann hervorgeholt und u ¨ bergeben. Damit reduzieren sich die Kernschritte auf Waren empfangen, lagern, entnehmen, versenden. In der Praxis wird dieser scheinbar einfache Ablauf nun durch Zeit-, Qualit¨ ats- und Kostenanspr¨ uche sowie eine Verkettung ¨auß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¨andigen Ver¨ anderungen in Bezug auf Mengenstr¨ ome, Kundenauftragsstruktur, Artikelvielfalt und -form usw. • vieles mehr In solchen Systemen resultiert die Komplexit¨at aus der Systemgr¨oße, Warenmenge oder geforderten Reaktionsgeschwindigkeit und Dynamik. F¨ ur eine ¨ vergleichende Betrachtung und einen groben Uberblick sind dazu einige wesentliche Kennzahlen in Tabelle 1.1 gegen¨ ubergestellt.

1.1 Anforderungen

7

1.1.3 Optimierung von Lagersystemen Wie bereits oben angef¨ uhrt, wird der Prozess der Lagerhaltung aufgrund der Kosten kritisch betrachtet, was absolut richtig ist, teilweise jedoch auch zu fragw¨ urdigen Entscheidungen f¨ uhrt. So wird mitunter bereits dar¨ uber philosophiert, ob die breite Tendenz zum Outsourcing nicht auch insbesondere dadurch vorangetrieben wird, dass Entscheidungstr¨ager von der arbeitsaufw¨ andigen Analyse und Prognostizierung von Aufw¨anden und Erl¨osen der hauseigenen Logistik befreit werden. [5] Neben den 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¨aufe die prinzipielle Gefahr der Intransparenz. Durch das Bestreben, Lageranzahl und -standorte durch Zentralisierungsbem¨ uhungen zu reduzieren oder einzelne Lagerstufen zu eliminieren, steigt jedoch der Anspruch an die Transparenz von Abl¨aufen, Best¨anden und Auftr¨ agen. Um den allgemein gewachsenen Anforderungen an das zeitliche Reaktionsverm¨ ogen und die logistische Leistungsf¨ahigkeit der Warenverteilsysteme bei konsequenter Minimierung der Best¨ ande und Optimierung der Kosten gerecht zu werden, bedarf es strukturierter, transparenter Abl¨aufe einerseits und eines hohen Maßes an Disziplin in der Durchf¨ uhrung der Aufgaben andererseits. Erst durch den Einsatz von Warehouse Managementsystemen (WMS) werden diese Ziele in vielen F¨ allen erreicht. Eines der Schl¨ usselelemente eines 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¨aufung u ¨berh¨ohter Si” cherheitsbest¨ ande“ ist schlichtweg Unsicherheit auf Seiten der Disponenten und weiterer Lagerverantwortlicher. Solche Unsicherheit resultiert beispielsweise aus einer unvollst¨ andigen Datenbasis oder zeitaufw¨andigen Recherchen nach Bestandsmengen, Lagerorten oder Auftragsstati. Ein transparentes System beginnt bei der Datensicherheit und 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¨aufe bieten die wesentliche Grundlage f¨ ur eine kontinuierliche Systemoptimierung. Neben der Kontrollier- und Steuerbarkeit der Prozesse wird auch eine h¨ ohere Reaktionsgeschwindigkeit und Flexibilit¨at erreicht. Schnelle Ortung von und 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¨agte 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¨achst ein System zur Verwaltung von Mengen und Orten (Lagerorten) und insbesondere deren Beziehung zueinander. Ein solches System kann dabei auch manuell z. B. Lagerleiter mit Karteikartensystem1) realisiert sein. Die Mehrzahl dieser Verwaltungssysteme d¨ urfte heute aber rechnergest¨ utzt arbeiten. Zus¨ atzliche Funktionen k¨ onnen dabei auch die Verwaltung der Transportsysteme beinhalten. Somit stellt ein Lagerverwaltungssystem im engeren Sinne ein Lagerbestandsverwaltungssystem dar. Das Warehouse Management bezeichnet im allgemeinen Sprachgebrauch dagegen die Steuerung, Kontrolle und Optimierung komplexer Lager- und Distributionssysteme. Neben den elementaren Funktionen einer Lagerverwaltung wie Mengen- und Lagerplatzverwaltung, F¨ordermittelsteuerung und -disposition geh¨ oren nach dieser Betrachtungsweise auch umfangreiche Methoden und Mittel zur Kontrolle der Systemzust¨ande und eine Auswahl an Betriebs- und Optimierungsstrategien zum Leistungsumfang. Auf ein derartiges, u ¨ bergreifendes Verwaltungs- und Managementsystem 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¨agte 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¨oglichst 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¨age, Prozesse usw. abgearbeitet werden. Dazu werden unterlagerte Steuerungen angesprochen. Warehouse Control System (abgek. WCS) Vergleichbar mit dem MFR kontrollieren WCS Quelle-Ziel-Beziehungen. Typischerweise werden zu-

10

1. Einleitung

s¨ atzliche Aufgaben integriert, die u ¨ber den Umfang eines reinen MFR hinausgehen. WCS k¨ onnen insbesondere lokale bzw. nicht bewegte Best¨ande verwalten. Sie gelangen insbesondere dort zum Einsatz, wo wesentliche Funktionen eines WMS durch WWS bzw. ERP-Systeme abgedeckt werden und demzufolge eine separates WMS nicht erforderlich ist. Das Zusammenwirken der verschiedenen Systeme im Distributionslager zeigt Abb. 1.1. Darin sind zur Verdeutlichung der prinzipiellen Abl¨aufe beispielhafte Funktionen, Aktionen und Kommunikationswege dargestellt. Die einzelnen Systemhierarchien werden durch vertikale Linien verk¨orpert. Im Bereich der WWS sind in Bezug auf das Lagersystem Aufgaben der allgemeinen Bestandsoptimierung angesiedelt, das WMS u ¨bernimmt administrative und dispositive Aufgaben der Optimierung und die 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¨aufe. So k¨onnen 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¨achern und Generierung der Pickreihenfolge) erfolgt beispielsweise im WCS. Die technische Durchf¨ uhrung wiederum realisiert ein MFR, der auf die physische Ebene (Feldebene) zugreift und die Fachanzeige ansteuert. Ebenso werden einzelne Aktionen dokumentiert (Erfassung des Kommissioniervorganges) und an die jeweils u uckgemeldet, was jedoch in Abb. 1.1 nicht ex¨ berlagerten Ebenen zur¨ plizit dargestellt ist. Analog werden bei der Steuerung automatischer Gewerke Quelle-Ziel-Beziehungen eines RBG im WMS abgebildet und u ¨ ber das WCS bereichsweise ausgef¨ uhrt. Die Ansteuerung einzelner Achsen eines Ger¨ates erfolgt schließlich auf der Feldebene.

1.3 Systemschnittstellen und Abgrenzung

11

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

12

1. Einleitung

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

1.4 Aufbau und Ziel des Buches

13

Abbildung 1.2. Grundlegende Informations߬ usse und Systembausteine in der ELogistics

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

1.4 Aufbau und Ziel des Buches Nachdem der 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¨aufe 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¨aufe, Anforderungen und Strategien in Lager- und Distributionssystemen. Außerdem werden die wesentlichen Prinzipien der Kommissionierung dargelegt sowie einige besondere Abl¨ aufe beschrieben. Gleichzeitig werden die Anforderungen, die an ein Lagerverwaltungssystem gestellt werden, 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¨ahlen die Grundlagen der Betriebssysteme, der Kommunikation in Netzen und die wichtigen Fragen der Datensicherheit. Im Anschluss daran werden in Kapitel 6 Softwarearchitekturen sowie Grundlagen und Methoden zur Erstellung moderner Softwaresysteme vorgestellt. Mit der dann folgenden beispielhaften Beschreibung von Datenmodellen, wie sie f¨ ur Lagersteuerung und -verwaltung genutzt werden, wird dem Leser gleichzeitig ein Warehouse Managementsystem vorgestellt, welches alle elementaren Bestandteile eines Lager- und Distributionssystems mit automatisierter F¨ ordertechnik und manueller Kommissionierung umfasst (myWMS). Die vielf¨ altigen Aspekte der Auswahl und Einf¨ uhrung eines Warehouse Managementsystems von der Anforderungserstellung bis zur Inbetriebnahme und dem weiteren Betrieb des Systems werden in Kapitel 8 behandelt. Der Anhang enth¨ alt die Kurzvorstellung der f¨ uhrenden Software Plattformen, die im Umfeld von Warehouse Managementsystemen eingesetzt werden.

2. Lagersysteme und Lagerverwaltung

Lager- und Distributionssysteme sind auf ein spezielles 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¨aufe gezielt optimieren zu k¨ onnen. Diese sollen zun¨ achst n¨ aher beleuchtet werden. Nachfolgend werden die grunds¨ atzlichen Abl¨ aufe in einem Lager beschrieben und die f¨ ur einen 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¨aher 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

2. Lagersysteme und Lagerverwaltung

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¨allen bedeutet dies auch, einen dem physischen Materialfluss vorauseilenden Informationsfluss zu schaffen, der z. B. die Bereithaltung entsprechender Kapazit¨aten an F¨order-, Lager- oder Handhabungsmitteln erm¨ oglicht. In diesem Kapitel werden kontinuierlich die Bedeutung und die Umsetzung dieses Paradigmas verdeutlicht. Supply Chain Management (SCM) Wie bereits aufgezeigt, ergibt sich im heutigen G¨ uter- und 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¨anomen, auch als Bullwhip- oder Peitscheneffekt bekannt, wurde Ende 1950 von Forrester beschrieben, und erst heute, mit der Verf¨ ugbarkeit leistungsf¨ahiger Rechenund Kommunikationssysteme, entstehen aussichtsreiche Ans¨atze zur Beherrschung dieser komplexen Zusammenh¨ ange. Der Schl¨ ussel liegt in der Informationsverarbeitung und -bereitstellung wichtiger Systeminformationen an

1

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

2.1 Logistische Rahmenbedingungen

17

beliebigen Punkten der Supply Chain. Bekannte Strategien in diesem Umfeld sind ECR2 und CPFR3 . Auch wenn das Supply Chain Management und die Methoden und Werkzeuge zur Optimierung dieser Ketten nicht im Fokus dieser Arbeit liegen, ist die Relevanz der Informationserfassung, -aufbereitung und -verarbeitung entlang der Supply Chain ein ganz entscheidender Faktor, der auch den Betrieb von Lagersystemen 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¨oß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¨asenz oder durch Verk¨ urzung von Lieferzeiten. Viele Kontraktlogistiker besitzen eine solche Pr¨ asenz per se, ein Aufbau aus eigenen Kr¨aften l¨asst sich dagegen wirtschaftlich oftmals nicht darstellen. Als Beispiel sei der Aufbau einer EDI-L¨ osung mit sicherer Kundenanbindung zur Erstellung geforderter Lieferavise genannt; • Nutzung 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¨ande in ein externes Lager des Kontraktlogistikers u uhrt, wo sie nun neben Best¨anden anderer Fir¨ berf¨ men gef¨ uhrt werden (Multi-Mandantensystem, auch Shared Warehouse). In jedem Fall erwachsen daraus neue Anforderungen an den Betrieb solcher outgesourcter L¨ ager. Da die Verg¨ utung der Leistung oftmals nach durchgef¨ uhrten Transaktionen erfolgt, ist die Leistungsmessung und Transparenz 2 3

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

2. Lagersysteme und Lagerverwaltung

der Aktivit¨ aten eine elementare Voraussetzung f¨ ur den Betrieb, um den Kunden die Prozesse nachvollziehbar pr¨ asentieren zu k¨onnen. Weitaus anspruchsvoller gestalten sich L¨ osungen mit verschiedenen Kunden in einem System. Hier sind scheinbar gleichwertige Waren v¨ollig unterschiedlichen Prozessen zu unterziehen, beispielsweise im Bereich der Inventur. Und letztlich werden solche Vertr¨ age typischerweise f¨ ur relativ kurze Dauer geschlossen, was f¨ ur den Betreiber (Kontraktlogistiker) ein betr¨achtliches Risiko darstellt; ein Umstand, der gegebenenfalls die Errichtung hochspezialisierter Gewerke zu einem nicht kalkulierbaren Risiko macht. Nicht zuletzt resultiert daraus eine Vielzahl von Anforderungen an das Warehouse Management und die eingesetzten Warehouse Managementsysteme. Diese m¨ ussen je nach Einsatzfall hochtransparent, allgemein einsetzbar und den unterschiedlichsten Anforderungen gen¨ ugend ausgef¨ uhrt werden. Wenig verwunderlich ist daher, dass große Kontraktlogistiker heute typischerweise u ¨ ber erhebliche personelle Ressourcen im Bereich der Informationslogistik verf¨ ugen. In den folgenden inhaltlichen Ausf¨ uhrungen sollen diese Anforderungen ausgiebig Ber¨ ucksichtigung 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-

2.1 Logistische Rahmenbedingungen

19

ten Bestellverhalten der Kunden und mit der geforderten Reaktionsgeschwindigkeit der Unternehmen verkn¨ upft. Insbesondere vor dem Hintergrund der zuk¨ unftigen Entwicklung im E-Commerce-Bereich wird der Branche auch f¨ ur die n¨ achsten Jahre weiteres Wachstum vorausgesagt [7]. ¨ Diese Anderungen im Versandverhalten wirken sich ebenso nachhaltig auf die Prozesse in den Distributionszentren aus. Eine zunehmende Vielfalt kleiner Sendungen muss unter hohen zeitlichen Anforderungen fertiggestellt, erfasst und verbucht werden. Dieses l¨ asst sich 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¨anderung des Systemzustandes von G¨ utern hinsichtlich Zeit, Ort, Menge, Zusammensetzung oder Qualit¨ at dar. Die Einheiten kommen je nach punktueller Anforderung seitens der relevanten Teilsysteme und Betriebsmittel sowie der kundenseitigen Anforderungen in st¨ andig wechselnder Form und Zusammensetzung in den Lagersystemen vor. Gleichzeitig haben sich verschiedene Bezeichnungen etabliert, die spezielle Verwendung in logistischen Systemen finden (aber nicht immer stringent genutzt werden). Jede Betrachtung von Materialfl¨ ussen setzt daher zwangsl¨aufig 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¨oßen) zu produzieren und sie m¨ oglichst effizient, das bedeutet im Allgemeinen in einer m¨oglichst geringen Anzahl an Arbeitsschritten, zum n¨ achsten Abnehmer der G¨ uter zu transportieren. Ein wichtiger Aspekt ist in diesem Zusammenhang auch die Konsolidierung der 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¨ zierte G¨ uter vor den Einfl¨ ussen w¨ ahrend der Transport-, Umschlag- und Lagerprozesse (TUL-Prozesse) so zu sch¨ utzen, dass keine qualitative Beein-

20

2. Lagersysteme und Lagerverwaltung

tr¨ achtigung auftritt. Diese Zielsetzungen werden im Wesentlichen durch Auswahl einer geeigneten Verpackung einerseits und durch Bildung so genannter Ladeeinheiten andererseits zu erreichen versucht. Neben der Hauptfunktion, das Gut w¨ ahrend der TUL-Prozesse zu sch¨ utzen, erf¨ ullt eine Verpackung aber auch eine Reihe weiterer Anforderungen. So soll die Verpackung in bestimmten F¨allen, z. B. bei Gefahrg¨ utern, nat¨ urlich auch die Umwelt und speziell die beteiligten Mitarbeiter vor dem Gut sch¨ utzen. Um eine effiziente Handhabung w¨ahrend dieser Prozesse zu erm¨ oglichen, soll eine Verpackung Lager- und Transportvorg¨ange vereinfachen, beispielsweise durch Schaffung einheitlicher, stapelbarer oder f¨orderf¨ ahiger Einheiten. Insbesondere im Bereich des Einzelhandels soll die Verpackung eine verkaufsf¨ ordernde Wirkung erzielen. Dem Kunden bzw. Verbraucher soll sie ggf. eine Verwendungsfunktion 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¨aufigen 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¨ahrend des Transports zwischen Hersteller und Vertreiber; Verkaufsverpackungen: werden vom Endverbraucher zum Transport oder bis zum Verbrauch der Waren verwendet; Umverpackungen: sind zus¨ atzliche Verpackungen um Verkaufsverpackungen, die unter anderem die Abgabe von Waren im Wege der Selbstbedienung erm¨ oglichen, dem Diebstahlschutz oder der Werbung dienen. Diese Verpackungstypen erfahren im Rahmen der Verpackungsverordnung besondere Bedeutung, die den Handel und Erzeuger zu einer R¨ 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¨atigkeiten in-

2.1 Logistische Rahmenbedingungen

21

Tabelle 2.1. Ziele der Einheitenbildung Zielsetzung

Beispiele

Vereinfachung und Kostensenkung

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

Vereinheitlichung

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

Austauschbarkeit

Poolbetrieb ermöglichen 1:1-Tausch identischer Ladehilfsmittel

Funktionalität

Stapelbarkeit erhöhen Zugriff ermöglichen

nerhalb der logistischen Aufgabenerf¨ ullung optimiert erbracht werden k¨onnen. G¨ angige Zielsetzungen, die zur Bildung Logistischer Einheiten f¨ uhren, sind in Tabelle 2.1 aufgef¨ uhrt. In der Idealvorstellung wird nur eine Logistische Einheit gew¨ahlt bzw. geformt, die unver¨ andert die gesamte Transportkette durchl¨auft, d. h. gleichzeitig Lager-, Transport-, Versand- und Ladeeinheit ist. Wie aber bereits eingehend ausgef¨ uhrt, l¨ asst sich diese Zielsetzung aufgrund einer Reihe unterschiedlicher Anspr¨ uche in den seltensten F¨allen wirklich umsetzen. Insbesondere in 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

2. Lagersysteme und Lagerverwaltung

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¨ alter). • 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¨oßeren System etabliert sind. Dies ist auch unvermeidlich, da jedes Distributionszentrum letztlich ein Glied in einer u ¨ bergeordneten Versorgungskette bzw. Supply Chain ist. Diese typischen grundlegenden Abl¨ aufe werden im Folgenden dargestellt. 2.2.1 Warenannahme und -eingang Ausgehend von der Warenbestellung durch einen Disponenten beginnt der 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

2. Lagersysteme und Lagerverwaltung

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

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

2.2 Funktionen in Lagersystemen

25

Dabei erfolgt eine Buchung des Frachtbriefes gegen das Avis. Es schließt sich ¨ die vorl¨ 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¨ oßeren Systemen aufgrund der r¨ aumlichen Trennung Aufgaben der Verkehrs- und Zielf¨ uhrung der ankommenden Lkw zu den Verladetoren an. Die r¨ aumliche Trennung erfolgt dabei h¨ 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¨otiger Such- und Rangierfahrten gew¨ ahrleisten sollen. Wareneingang Durch Nutzung der Avis-Informationen kann auch der Wareneingang bereits auf die eingehende Lieferung vorbereitet werden, was insbesondere bei gr¨ oßeren Liefermengen (in Bezug auf das vereinnahmende System gesehen) vorteilhaft ist. Dazu geh¨ ort beispielsweise die Planung und Reservierung korrespondierender 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 ¨ahnlich bereits im Handel (EAN128) oder in der Automobilbranche (Odette) vermehrt zum Einsatz gelangt, jedoch im Lager noch keine standort¨ ubergreifende Verbreitung gefunden hat. Dies ist u. a. darauf zur¨ uckzuf¨ uhren, dass zur Steuerung des 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¨atssicherung. Diese Pr¨ ufungen reichen vom Sichtvergleich bis zu Laborpr¨ ufungen einzelner Stichproben oder vollst¨ andigen 100%-Kontrollen. M¨angelbehaftete Ware wird danach mit Sperrkennzeichen versehen und in spezielle Bereiche verbracht oder unter Ber¨ ucksichtigung der Sperrmerkmale (s. Abschn. 2.3.1, S. 55) eingelagert. Bei neuen Artikeln ist unter Umst¨ anden noch eine Vervollst¨andigung der Artikelstammdaten (vgl. Tabelle 2.13) erforderlich. Eine sorgf¨altige Erstellung und Pflege dieser Stammdaten ist die wesentliche Voraussetzung f¨ ur

26

2. Lagersysteme und Lagerverwaltung

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¨onnen Kundenauftr¨age auf Vollst¨ andigkeit gepr¨ uft werden. Spezielle automatische Ger¨ate 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¨ohen auf das Artikel- bzw. Lagergutspektrum angepasst werden, wodurch die Raumnutzung des Lagerbereiches optimiert werden kann. Entsprechend der Gr¨oße eines Kommissionierauftrags k¨ onnen des Weiteren optimale Versandbeh¨alter vorausberechnet werden. Dadurch lassen sich letztlich Versandkosten minimieren. Bei der Ermittlung der Artikelabmessungen kommen unterschiedliche Verfahren zum Einsatz. Neben dem exakten Vermessen bzw. der Aufnahme der exakten Artikelabmessungen in das Lagerverwaltungssystem reicht verschiedenen Anwendern auch die u agige Gruppierung in bestimmte ¨ berschl¨ Gr¨ oßenklassen. Ein solches Verfahren ist dann sinnvoll, wenn die Gr¨oßenerfassung manuell durchgef¨ uhrt wird. Dazu werden oftmals Messlehren eingesetzt, die entsprechend den gew¨ ahlten Gr¨ oßenklassen Markierungen aufweisen. Der Bediener kann so die Gr¨ oßenklasse sehr leicht ablesen. Daneben existieren auch automatische Abmessungserfassungsger¨ate, welche die Artikel abtasten und die erfassten Abmessungen direkt an das Lagerverwaltungssystem u ¨bertragen (s. Abb. 2.3). Schließlich werden weitere kennzeichnende Gr¨ oßen oder Besonderheiten (z. B. Gefahrgutkennzeichen etc.) der Artikel aufgenommen, soweit sie in der Artikelstammdatei noch nicht vorliegen. Zur Sicherung hochwertiger G¨ uter ist eventuell die Aufnahme von Seriennummern erforderlich. Die durchgehende Kontrolle und Nachvollziehbarkeit erfordert hierbei eine u ¨ ber die Warenbeschreibung hinausgehende Funktionalit¨ at, da nicht der Artikel, sondern die spezielle Ladeeinheit des Artikels und deren Bewegung im Lager dokumentiert werden muss. Dar¨ uber hinaus muss gegebenenfalls f¨ ur eine Zeitspanne nach Durchlauf der Einheit die Inur die Verfolgung formation verf¨ ugbar bleiben. Das Gleiche gilt sinngem¨aß f¨ von Produktionschargen. ¨ Um eine Uberalterung von Ware mit begrenzter Lebensdauer (verderbliche Ware) auszuschließen, ist gegebenenfalls das Verfallsdatum zu erfassen bzw. die Restlaufzeit zu bestimmen. Anhand dieser Parameter k¨onnen Auslagerpriorit¨ aten bestimmt oder Umlagerungen veranlasst werden.

2.2 Funktionen in Lagersystemen

27

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

Bildung der Lagereinheiten In vielen Lager- und Materialflusssystemen sind aus Gr¨ unden der Transportsicherheit oder Handhabung spezielle Ladehilfsmittel oder Beh¨ alter im Einsatz. Hierzu z¨ahlen Tablarsysteme oder Regalsysteme mit genormten Beh¨ altergr¨ oßen, die ein spezielles Ladehilfsmittel erfordern. Eingehende G¨ uter sind dagegen mit der Zielsetzung der Versandkosten- und Transportkostenminimierung zu volumen- und mengenoptimierten Einheiten zusammengefasst. Deshalb ist in solchen F¨allen eine Anpassung an das 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¨onnen 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¨oglicht gleichzeitig die Nutzung dauerhafter Kennzeichnungselemente an den Paletten zur Mate-

28

2. Lagersysteme und Lagerverwaltung

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

2.2 Funktionen in Lagersystemen

29

Verteilung auf Lagerbereiche In einem ersten Schritt (Backorders) wird gepr¨ uft, ob die eingetroffenen Wareneing¨ ange zur Vervollst¨andigung 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¨auchlich, aber eher unangebracht ist. Ansonsten folgt der Transport in den Lagerbereich bzw. die Lagerbereiche. Dazu ist im ersten Schritt die Festlegung der Transportziele im Lagerverwaltungssystem erforderlich. Gerade in großen Systemen ergeben sich hierbei erhebliche Optimierungspotenziale je nach H¨ ohe der anfallenden Transportwege und -mengen. Dies gilt umso mehr, wenn manuell gef¨ uhrte Unstetigf¨orderer (z. B. Stapler oder Schleppz¨ uge) zum Einsatz kommen. Eine innerbetriebliche Transportoptimierung kann durch verschiedene Maßnahmen und Techniken erreicht werden. Ein organisatorischer Ansatz liegt in der Sammlung und Vorsortierung der Artikel auf Touren. Das setzt jedoch entsprechende 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¨onnen beispielsweise Stapler mit Staplerterminals ausger¨ ustet werden, die dem Fahrer eine optimierte Auftragsreihenfolge vorgeben (vgl. Abschn. 2.3.3, S. 58). Ein wichtiger Aspekt ist die Transparenz des 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¨asst 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¨atestens die Identit¨atskontrolle am so genannten I-Punkt statt. Dies geschieht h¨aufig 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

2. Lagersysteme und Lagerverwaltung

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¨ahigkeit kontrolliert werden. Dazu z¨ahlt insbesondere die Konturenkontrolle (Pr¨ ufung der Abmessungen der einzulagernden Einheit) sowie ggf. eine Gewichtskontrolle, was speziell in Systemen mit nicht einheitlichen Lagerfachkapazit¨ aten erforderlich ist (s. Abb. 2.4). Bei bestimmten Inventurverfahren (vgl. Abschn. 2.3.5) erfolgt an dieser Stelle eine k¨ orperliche Bestandsaufnahme (permanente Inventur). Vergabe des Lagerplatzes und Einlagerung Die Durchf¨ uhrung einer Einlagerung setzt zun¨ achst die Festlegung des Lagerfaches bzw. des Lagerplatzes voraus. Die Vergabe des Lagerfaches kann anhand einer Vielzahl von Kriterien erfolgen. Es ergeben sich 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

2.2 Funktionen in Lagersystemen

31

Tabelle 2.2. Einige wesentliche Parameter zur Lagerplatzvergabe Parameter

Anforderungen

technische Anforderungen

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

betriebliche Optimierung

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

sicherheitstechnische und rechtliche Vorgaben

Beachtung von Zusammenlagerungsverboten (Gefahrgutlagerung) Getrenntlagerung (Lebensmittelbereich) Chargengruppierung

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

32

2. Lagersysteme und Lagerverwaltung

Tabelle 2.3. Operationelle Lagerplatzvergabestrategien Bezeichnung

Strategie

Zielsetzung

Festplatzlagerung

feste Zuordnung eines Lagerplatzes f r einen bestimmten Artikel

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

freie Platzvergabe (chaotische Lagerung)

Artikel kann auf einem beliebigen freien Lagerplatz eingelagert werden

maximale Ausnutzung der Lagerkapazit t

Zonung

Wahl des Lagerplatzes entsprechend der Umschlagh ufigkeit des Artikels

Erh hung der Umschlagleistung durch Minimierung der mittleren Wegl nge

Querverteilung

Lagerung mehrerer Einheiten eines Artikels verteilt ber mehrere Lagergassen

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

Pick-/Teilefamilien Clustering

benachbarte Lagerorte f r h ufig kombinierte Artikel

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

k rzester Fahrweg

Anfahrt des Lagerplatzes mit k rzestem Weg

Erh hung der Umschlagleistung durch Minimierung der Anschlusswege

Vorpufferung

in Spitzenzeiten Einlagerung auf vorderen Lagerbereich

Vermeidung von R ckstau durch Erh hung des Durchsatzes

untereinander kompatibel

bzw. Lagersteuerungen per se abl¨ auft, bedarf es im Fall eines manuellen Lagersystems (mit rechnergest¨ utzter F¨ uhrung, z. B. durch Staplerleitsystem) einer 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¨achsten Auftrag. 2.2.3 Auslagerung Die Verwaltung der Auslagerungsauftr¨ age erfolgt je nach Anwendungsfall f¨ ur einen k¨ urzeren oder l¨ angeren Zeitraum. In jedem Fall muss zun¨achst eine Pr¨ ufung der vorliegenden Auftr¨ age auf Erf¨ ullbarkeit durchgef¨ uhrt werden. Dabei erfolgt eine Reservierung der auszulagernden Mengen und/oder Lagereinheiten, um Fehlmengen zum terminierten Auslagerzeitpunkt zu vermeiden (vgl. Abschn. 2.3.1, S. 55). Die Disposition und Durchf¨ uhrung der Auslagerung erfordert die Ber¨ ucksichtigung verschiedenster Zielvorgaben und wird unter Anwendung bestimmter Auslagerungsstrategien (s. Tabelle 2.4) durchgef¨ uhrt. Einige Strategien (terminierte oder tourenoptimierte Auslagerungen) k¨ onnen nur bei entsprechender zeitlicher Disposition realisiert werden.

2.2 Funktionen in Lagersystemen

33

Tabelle 2.4. Auslagerstrategien Bezeichnung

Strategie

Zielsetzung

FIFO (First-In-First-Out)

Auslagerung der zuerst eingelagerten Ladeeinheit eines Artikels

Vermeidung von Überalterung und Verfall einzelner Ladeeinheiten eines Artikels

LIFO (Last-In-First-Out)

Auslagerung der zuletzt eingelagerten Ladeeinheit eines Artikels

Vermeidung von Umlagerungen bei bestimmten Lagertechniken (Blocklager)

Mengenanpassung

Auslagerung von vollen und angebrochenen Ladeeinheiten entsprechend der Auftragsmenge

Erhöhung der Umschlagleistung durch Minimierung der Rücklagerungen

Anbruchmengenbevorzugung

generelle Priorisierung angebrochener Ladeeinheiten

verbesserte Nutzung der Lagerkapazitäten

kürzester Fahrweg

Auslagerung der Ladeeinheit eines Artikels mit dem kürzesten Anschlussweg

Erhöhung der Umschlagleistung durch Minimierung der Fahrwege

Gassenwechselminimierung

Sortierung der Auslagerreihenfolge nach einzelnen Lagergassen

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

tourenbezogen

Planung der Auslagerreihenfolge entsprechend der Tourenplanung eines nachgeschalteten Verkehrsmittels

Reduzierung der Rangier- und Umladearbeiten

terminiert

Planung des Auslagerzeitpunktes entsprechend dem voraussichtlichen Bedarfszeitpunkt

Reduzierung der Rangier- und Umladearbeiten

Vorholung

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

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

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

34

2. Lagersysteme und Lagerverwaltung

2.2.4 Konsolidierungspunkt Der Konsolidierungspunkt ist eine Stelle zur Identifizierung abgefertigter Einheiten an Schl¨ usselpositionen des Materialflusses. Insbesondere in Systemen mit stochastischen Einfl¨ ussen, beispielsweise mit manuellen Arbeitsabl¨aufen, ist ein solcher Messpunkt elementar zur Feststellung des Produktionsfortschrittes im Lager. Es erfolgt einerseits ein Abgleich der Soll- und Ist-Daten (z. B. durch ¨ ¨ Messung des Gewichts) und somit eine Uberpr¨ ufung der Ubereinstimmung von Material- und 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¨orige Prozess als Kommissionierung bezeichnet. Die Kommissionierung beschreibt damit die Zusammenstellung von Artikeln f¨ ur einen Kundenauftrag, d. h. die Entnahme von Teilmengen gr¨ oßerer Einheiten einzelner Artikel und deren Zusammenf¨ uhrung und Bereitstellung f¨ ur die Versendung. Die Kommissionierung stellt einen arbeitsintensiven, zumeist personalintensiven und im Allgemeinen kostenintensiven Bereich eines Lager- und Warenverteilzentrums dar und erf¨ ahrt dadurch besondere Beachtung bei Planung und Betrieb solcher Systeme. In der Kommissionierung kommen heute alle erdenklichen f¨order- und lagertechnischen Systeme zum Einsatz. Die enge 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¨aufe 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¨angigerweise 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

2.2 Funktionen in Lagersystemen

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¨ordert 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¨ osungen f¨ ur Kommissioniersysteme erarbeiten bzw. beschreiben. Dabei ist darauf zu achten, dass zur Zusammenf¨ uhrung von Kommissionierer und Bereitstelleinheit entweder der Kommissionierer oder die Bereitstelleinheit eine Bewegung durchf¨ uhren muss. Ebenso muss entweder die Entnahmeeinheit oder die Kommissioniereinheit einen Transport durchf¨ uhren, um den Kommissioniervorgang abzuschließen. Bei dem Kommissionierer“ kann es sich ” bei dieser Betrachtung sowohl um einen Menschen als auch um eine Maschine (z. B. Kommissionierroboter) handeln. Die Bedeutung einer Reihe von 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¨ar, beispielsweise in einem Regalfach, zur Entnahme bereitsteht. Analog muss bei dynamischer Bereitstellung die Bereitstelleinheit des gew¨ unschten Artikels zum Entnahmeort bef¨ ordert und gegebenenfalls nach erfolgter Entnahme zur¨ uckgelagert werden. In j¨ ungeren Publikationen wird dagegen die Bezeichnung auf den Entnahmevorgang konzentriert. Nach dieser Definition befinden sich bei statischer Bereitstellung die zu greifenden Teile in Ruhe, bei dynamischer Bereitstellung erfolgt der Entnahmevorgang auf das bewegte Teil.

36

2. Lagersysteme und Lagerverwaltung

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

2.2 Funktionen in Lagersystemen

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¨art, ob die Bereitstelleinheit zur Durchf¨ uhrung einer Entnahme f¨ordertechnisch 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¨aumlichen festen Punkt, bei der dezentralen Entnahme an verschiedenen r¨aumlichen Punkten statt. Zur Verdeutlichung dieser Unterscheidungen dienen die Beispiele in Tabelle 2.6. Wie diese 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¨allen 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¨ordermittel bzw. die Sammeleinrichtung. Befindet sich das F¨ordermittel in Bewegung (Stetigf¨ orderer), liegt eine dynamische Abgabe vor; wird dagegen auf eine unbewegte Sammeleinrichtung abgegeben, liegt eine statische Abgabe vor. Hinsichtlich der Unterscheidung in zentrale und dezentrale Abgabe verh¨alt sich

38

2. Lagersysteme und Lagerverwaltung

statisch

dynamisch

dezentral

Fachbodenregalanlage

Regalfront an AKL

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

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

zentral

Tabelle 2.6. Beispiele zur Bereitstellung

Kommissioniernest

Hochregallagervorzone

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

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

die Unterscheidung analog zur Entnahme: Wird z. B. eine Sammeleinrichtung mitgef¨ uhrt, erfolgt die Abgabe der Entnahmeeinheiten an unterschiedlichen Orten, also dezentral; eine Abgabe an einen fest installierten Abgabepunkt ist dagegen zentral. Beispiele f¨ ur verschiedene Auspr¨agungsformen liefert Tabelle 2.7. Weitere Unterscheidungsmerkmale 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¨at oder Kommissionierstapler, die dreidimensionale mittels Kran erfolgen. Die Entnahme erfolgt zum u ¨ berwiegenden Teil manuell, bei schweren oder unhandlichen G¨ utern auch mechanisiert u ¨ ber entsprechende Hilfsmittel (z. B. Manipulatoren) und bei geeigneten Gut- und Auftragsspektren auch zunehmend automatisiert u ¨ber Kommissionierroboter oder Schachtkommissionierer (z. B. in der Pharmazie). Eng mit der Eignung zur Automatisierung ist schließlich auch die Frage des Ordnungszustandes bei der Bereitstellung und Abgabe der Einheiten verkn¨ upft. Die automatische Kommissionierung ist um-

2.2 Funktionen in Lagersystemen

39

zentral

dezentral

Tabelle 2.7. Beispiele zur Abgabe der Entnahmeeinheit statisch

dynamisch

Pick-to-Box

Pick-to-Belt

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

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

Ware-zur-Person / Kommissionier-U

Ware-zur-Person / Paternosterregal mit Rollenbahn

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

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

so einfacher bzw. effizienter realisierbar, je h¨ oher der Ordnungszustand der Einheiten ist. W¨ ahrend auf Basis dieser Klassifizierungen durchaus grunds¨atzliche Eignungsparameter und Charakteristika abgeleitet werden k¨onnen, ist die Entscheidung, welches System f¨ ur einen gegebenen Anwendungsfall optimal ist, praktisch nur im Einzelfall im Rahmen einer Systemplanung zu 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¨ angigerweise werden dabei die Aufbauorganisation, d. h. die Struktur der Anordnung der Lagerbereiche, und die Ablauforganisation, d. h. die Abwicklung des Kommissionierprozesses, unterschieden. Aufbauorganisation Die Aufgabe der Aufbauorganisation besteht in der 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¨altige ¨ Analyse des Sortiments und der Auftragsstruktur voraus. Ublicherweise leiten sich daraus variierende Anforderungen an Kapazit¨at, Leistung und Eigenschaften des Bereitstellsystems ab. Solche Anforderungen resultieren u. a. aus • Volumina, Gewichten und Abmessungen der Bereitstelleinheiten, • Umschlagh¨ aufigkeiten bzw. Zugriffsh¨ aufigkeiten pro Artikel,

40

• • • •

2. Lagersysteme und Lagerverwaltung

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¨agt durch die ¨ • Basiszeit (z. B. Ubernahme des Auftrags, Sortieren von Belegen, Aufnahme von Kommissionierbeh¨ altern, Abgabe von Ware und Kommissionierbeh¨ altern, Weitergabe bzw. abschließende Belegbearbeitung), • Greifzeit (Hinlangen, Aufnehmen, Bef¨ ordern und Ablegen der Entnahmeeinheit), • Totzeit (z. B. Lesen, Aufreißen von Verpackungen, Suchen und 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¨ achsten Auftrag bearbeitet. Das Prinzip wird als einfache, auftragsweise Kommissionierung bezeichnet. Dieser Ablauf kann beim Prinzip Person-zurWare durchaus dort sinnvoll sein, wo die durchschnittliche Auftragsmenge die Transportkapazit¨ at des Kommissionierers ausf¨ ullt. Sie bietet außerdem den Vorteil eines geringen Aufwandes zur Vorbereitung. Im einfachsten Fall wird direkt der eingehende Kundenauftrag als Kommissionierliste verwendet. Der Kommissionierer legt dadurch aber lange Wege zur¨ uck, da die Pickfolge unmittelbar durch den Auftrag vorgegeben wird, wodurch das Prinzip auf kleine Systeme beschr¨ ankt ist.

2.2 Funktionen in Lagersystemen

41

Die erste Optimierungsm¨ oglichkeit besteht in der Sammlung und gleichzeitigen Bearbeitung mehrerer Kundenauftr¨ age, was als auftragsparalleles Kommissionieren oder Sortieren w¨ahrend der Kommissionierung bezeichnet wird. Durch Anstieg der Entnahmepunktdichte reduziert sich die mittlere Wegzeit pro Auftrag. Dabei ist der Kommissionierer derart durch das System zu f¨ uhren, dass er automatisch zum n¨ achsten Entnahmeort gef¨ uhrt wird und somit lange Totzeiten (Identifizierung des n¨achstliegenden Artikels) oder Zur¨ uckgehen vermieden werden. In großen Systemen ist es wenig sinnvoll, dass ein Kommissionierer mit dem Auftrag das gesamte Kommissioniersystem durchl¨auft. In diesem Fall m¨ usste der Kommissionierer sich nicht nur in allen Bereichen gleichermaßen auskennen, sondern auch zwangsl¨ 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¨onnen, sofern keine ¨ berbr¨ Artikel in diesen Zonen zu entnehmen sind. Alternativ dazu k¨ onnen auch die Kundenauftr¨age in Teilauftr¨age zerlegt werden, die jeweils zeitgleich in die einzelnen Zonen eingeschleust und dort parallel gesammelt werden, was insbesondere zu einer Verk¨ urzung der Durchlaufzeit der Auftr¨ age f¨ uhrt. Dieses Verfahren wird als parallele bzw. exakter als zonenparallele Kommissionierung bezeichnet. Dem m¨oglichen Zeitgewinn steht wiederum der Aufwand der Vorbereitung der Auftr¨age und die Notwendigkeit der Zusammenf¨ uhrung der Teilauftr¨age entgegen. W¨ahrend die Auftragsaufbereitung weitgehend rechnergest¨ utzt ablaufen kann, sind zur Zuage ggf. Puffer-, Sammel- oder Verteilsysteme sammenf¨ uhrung der Teilauftr¨ 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¨onnen alle in einer gr¨oßeren Auftragsmenge auftretenden identischen Artikel in einem Kommissioniervorgang gepickt werden, d. h. die Bereitstelleinheit ist nur einmal anzusteuern

42

2. Lagersysteme und Lagerverwaltung

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

2.2 Funktionen in Lagersystemen

43

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

44

2. Lagersysteme und Lagerverwaltung

kleinen Systemen, ungeeignet. In Abh¨ angigkeit vom gew¨ahlten Organisationstyp der Kommissionierung fallen folgende T¨atigkeiten an: • Vervollst¨ andigen der Auftr¨ age mit den zur Kommissionierung relevanten Informationen (Lagerort, Artikelnummer, Sammelbeh¨alter), • Sortieren der Positionen in der Reihenfolge der Anordnung im Regal, • Zerlegen der Auftr¨ age in Teilauftr¨ age, die in verschiedenen Zonen abgearbeitet werden, • Zusammenf¨ uhren der Auftr¨ age zu einem gemeinsam abzuarbeitenden Auftragsstapel, • Filterung von Auftr¨ agen mit gleicher Priorit¨at, Versandart oder gleichem Zieltermin, • Filterung von Auftr¨ agen unterschiedlicher Behandlung (z. B. EinpositionenAuftr¨ age). Informationsmanagement Kommissioniererf¨ uhrung In praktisch jedem Kommissioniersystem gelangt der Mensch, h¨ 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¨ onnen. Beim Einsatz automatischer Systeme sind in jedem Fall spezialisierte, an das System angepasste Steuerungen erforderlich. ¨ Die Hauptaufgabe der Kommissioniererf¨ uhrung ist die Ubermittlung der relevanten Entnahmeinformationen mit der generellen Zielsetzung einer maximalen Kommissionierleistung und der Minimierung m¨oglicher Pickfehler. Die Verfahren der Weitergabe der Entnahmeinformationen an die Kommissionierer lassen sich grunds¨ atzlich in papier- oder belegbehaftete Verfahren und papier- oder beleglose Verfahren unterscheiden. Fehlerhafte Kommissionervorg¨ ange untergraben nicht nur das Vertrauen der Kunden in die logistische Leistungsf¨ ahigkeit des Lieferanten, sie bedeuten in der Regel auch erhebliche 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¨age erfasst werden, um darauf aufbauend Folgeauftr¨ age einzuschleusen. Deshalb wird dieser Pr¨ ufvorgang auch als Quittierung des Auftrags bzw. der Entnahmeeinheit bezeichnet.

2.2 Funktionen in Lagersystemen

45

Kommissioniererf¨ uhrung mit Pickliste Die papierbehaftete Version stellt die klassische L¨ osung der Kommissioniererf¨ uhrung dar. Der Kommissionierer erh¨ alt einen Papierbogen mit den Entnahmeinformationen. Die Pickliste ist prinzipiell f¨ ur alle Kommissionierverfahren einsetzbar, bei Verfahren mit automatischer Unterst¨ utzung (automatisch gesteuerte Ware-zur-PersonSysteme) ist der Einsatz jedoch wenig sinnvoll, da die Informationen zur Steuerung der Anlagen (z. B. horizontale oder vertikale Umlaufregale) ohnehin elektronisch aufbereitet vorliegen. Entscheidend f¨ ur die Kommissionierleistung ist die Reihenfolge der Entnahmeinformationen auf der Liste. Diese sollte der Reihenfolge der Artikel in der Regalzeile entsprechen. In gr¨ oßeren Systemen mit volumen- und wegoptimierter Anordnung der Entnahmeeinheiten ist die Pickliste gegen¨ uber dem Auftragseingang, der typischerweise kunden-, alphabetisch- oder artikelnummerorientiert erfolgt, zu reorganisieren. Diese Funktionalit¨at kann sinnvoll nur durch rechnergest¨ utzte Verwaltungssysteme erfolgen. Bei zonenparalleler Kommissionierung muss die Ursprungsliste zwangsl¨aufig in mehrere Teillisten umgesetzt werden. Vorteilhaft bei der Pickliste ist sowohl die relativ g¨ unstige Vorbereitung und Ausfertigung als auch die einfache Umsetzung des Prinzips. In geeigneten F¨ allen k¨ onnen auch Nebenfunktionen ausgef¨ uhrt werden. Eine g¨angige Anwendung ist die Pickliste in Form von Klebeetiketten (Labeln), bei der die Entnahmeeinheiten mit verschiedensten Informationen (u. a. auch Preisauszeichnung) versehen werden k¨ onnen. Dadurch k¨onnen wiederum Arbeitsschritte eingespart werden. Eine Selbstkontrolle des Kommissionierers wird oft durch Abhaken der einzelnen Positionen einer Pickliste und die Quittierung beispielsweise durch Abzeichnen der abgeschlossenen Kommissionierliste realisiert. Eine weitere Kontrolle bei der Kommissionierung mit Pickliste l¨asst sich aber nur durch nachfolgende 100%-Kontrolle des komplettierten Kundenauftrags vornehmen. Papierlose F¨ uhrung und Kontrolle des Kommissioniervorganges Nachteile der Pickliste bestehen in dem hohen Totzeitanteil zur 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 Adapande erfordern tion des Kommissionierverhaltens auf wechselnde Systemzust¨ (dazu z¨ ahlen dynamische Batchsteuerungsverfahren in der zweistufigen Kommissionierung), nicht einsetzbar.

46

2. Lagersysteme und Lagerverwaltung

Tabelle 2.8. Papierlose Verfahren der Kommissioniererf¨ uhrung Bezeichnung

Funktion

Mobiles Terminal

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

Stationäres Terminal

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

Pick-by-Light

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

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

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

2.2 Funktionen in Lagersystemen

47

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

Durchschnittliche Fehlerquote

Pick-by-Voice

0,08%

Beleg

0,35%

Etiketten

0,37%

Pick-by-Light

0,40%

mobile Terminals

0,46%

mobile Terminals und Etiketten

0,94%

der Kommissionierfehler zufolge ist die Kommissionierung per Pickliste ( Be” leg“) grunds¨ atzlich nicht ung¨ unstiger als andere Verfahren ([33] und Tabelle 2.9). ¨ Ubliche Auspr¨ agungsformen in der Kommissionierung Der Grundtyp der Kommissionierung ist in Abb. 2.5 dargestellt. Der Kommissionierer bewegt sich mit einem Wagen entlang der Regalfront (Durchlauf-, Paletten- oder Fachbodenregal) und greift die Einheiten entsprechend den Entnahmeinformationen einer Pickliste. Auf dem Wagen werden ein oder mehrere Auftragsbeh¨ alter mitgef¨ uhrt, die zur Aufnahme der getrennt nach Kundenauftrag kommissionierten Einheiten dienen. Ausgehend von einer Basisstation B, an der leere Kundenauftragsbeh¨ alter und die Pickliste(n) aufgenommen werden, beginnt der Kommissionierer den Rundgang und u ¨ bergibt nach abgeschlossenem Rundgang die gef¨ ullten Beh¨alter an der Schnittstelle zum Versand. Dabei bewegt er sich schleifen- oder m¨aanderf¨ormig durch die Regalanordnung (Schleifenstrategie). Je nach Pickliste k¨onnen auch einzelne Gassen u ¨ bersprungen oder die Gassen nur zu einem Teil begangen werden (Stichgangstrategie). Entsprechend der zuvor 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¨ache

48

2. Lagersysteme und Lagerverwaltung

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¨ohere Bewegungsdynamik des Kommissionierstaplers oder Regalbedienger¨ates und damit eine h¨ ohere Kommissionierleistung. Ein elementarer leistungsbestimmender Faktor ist die Gestaltung der Fachreihenfolge, in der die Entnahmepositionen angefahren werden. Es existieren verschiedene Verfahren dieser so genannten ¨ Tripoptimierung, die in Kapitel 4 behandelt werden. Ublicherweise erfolgt die Kommissioniererf¨ uhrung dabei durch ein auf dem Bedienger¨at installiertes Terminal. In Abb. 2.7 sind zwei g¨ angige Systeme f¨ ur das Prinzip Ware-zur-Person dargestellt. Im ersten Fall (Abb. 2.7, a) steht der Kommissionierer an der Stirnseite eines Automatischen Kleinteilelagers (AKL). Die artikelreinen Beh¨ alter werden u ormige F¨ ordertechnik (Rollen- oder Kettenf¨or¨ ber eine U-f¨ derer) zur Entnahme bereitgestellt. Die Anordnung wird als KommissionierU bezeichnet. Im zweiten Beispiel (Abb. 2.7, b) 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

2.2 Funktionen in Lagersystemen

49

Abbildung 2.6. Person-zur-Ware im Hochregal

Kommissionierer gleichzeitig bedient. Die Bereitstellung erfolgt in diesen F¨ allen zentral-dynamisch, die Abgabe von Entnahme- und Kommissioniereinheit zentral-statisch. Zur Kommissionierf¨ uhrung werden u ¨ blicherweise station¨ are Terminals genutzt. Die Systeme k¨ onnen sowohl in 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¨aufig getrennt. Der Kommissionierer erh¨ alt u ¨ ber ein Pick-by-Light-System die Entnahmeinformationen. Die entnommenen Einheiten werden direkt an ein F¨orderband oder Rollenf¨ orderer u ¨ bergeben (Pick-to-Belt). Die Entnahme erfolgt somit

50

2. Lagersysteme und Lagerverwaltung

a )

b )

Abbildung 2.7. 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¨alter werden aus einem entfernten Lagerbereich zum Entnahmeplatz transportiert und zur Entnahme bereitgestellt (dezentral-dynamische Bereitstellung). Die Abgabe erfolgt in die im Regal befindlichen Kundenauftragsbeh¨alter, die nach Vervollst¨ andigung des Auftrags durch weitere Mitarbeiter zum Versand bef¨ ordert werden (statisch-dezentrale Abgabe der Entnahmeeinheit und statisch-zentrale Abgabe der Kommissioniereinheit). Das Verfahren wird als Inverse Kommissionierung bezeichnet und findet in den letzten Jahren insbesondere im e-Commerce-Bereich zunehmend Bedeutung (sehr großes Sortiment und viele kleine Auftr¨age). Gelangt eine optische F¨ uhrung der Kommissionierer zum Einsatz, wird das Prinzip auch als Pick-to-Light oder Put-to-Light bezeichnet. Nachschubsteuerung Die Verf¨ ugbarkeit der Artikel an den Entnahmestellen ist von entscheidender Bedeutung f¨ ur einen reibungslosen und schnellen Ablauf in der Kommissionierung. Insbesondere in batchorientierten Kommissioniersystemen k¨onnen

2.2 Funktionen in Lagersystemen

51

Abbildung 2.8. Zweistufiges Kommissioniersystem mit Sorter

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

52

2. Lagersysteme und Lagerverwaltung

A K L

V e rs a n d

Abbildung 2.9. Inverse Kommissionierung

Im Hinblick auf eine Versandkostenoptimierung m¨ ussen Sendungen u. a. volumenoptimiert gebildet werden. Viele Unternehmen setzen bei diesem Schritt auf die F¨ ahigkeiten und die Erfahrung des Packpersonals, f¨ ur eine vorliegende Verpackungsmenge die richtige Verpackungseinheit (z. B. Kartongr¨ oße) zu bestimmen. In der Praxis ist jedoch h¨aufig 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¨oßen ermitteln. Insbesondere bei umfangreicheren Verpackungs- und Ladeeinheitenbildungsprozessen ist der Mensch schnell u ¨ berfordert. Auf dem Markt wird eine Reihe von rechnergest¨ utzten Optimierungswerkzeugen, beispielsweise zur Packmustergenerierung bei Palettierungsaufgaben, angeboten. Schließlich erfolgt bei diesem Schritt eine Warenausgangspr¨ ufung mit der Pr¨ ufung auf Vollst¨ andigkeit des Kundenauftrags und auf Qualit¨at und 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¨ahernd homogenes Gewichts- und Artikelspektrum voraus. Informationstechnisch erfolgt abschließend die Aktualisierung des Auftragsstatus mit der Fortschreibung des Status des Auslagerauftrags und gegebenenfalls eine Erg¨ anzung der transport- und versandtechnischen Daten.

2.2 Funktionen in Lagersystemen

53

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

54

2. Lagersysteme und Lagerverwaltung

Tabelle 2.10. 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¨atze eines Lagersystems (Platzverwaltung), und andererseits u ¨ ber die in diesem System gelagerten Einheiten (Mengenverwaltung/Bestandsverwaltung). Dar¨ uber hinaus sollte f¨ ur eine kontinuierliche Lageroptimierung sinnvollerweise eine Reihe von Kontrollfunktionen integriert sein. Lagertypenverwaltung W¨ ahrend im Fall eines manuell gef¨ uhrten Lagersystems die Bediener durch ihr Erfahrungswissen und ihre Entscheidungskraft selbstst¨ andig in der Lage sind, geeignete F¨order- und Lagermittel auszuw¨ ahlen bzw. einzusetzen, muss beim Einsatz automatischer Lagerverwaltungssysteme eine Zuweisung der Kompatibilit¨at einzelner Elemente eines Lagersystems erfolgen. Ebenso werden durch den manuellen Bediener verschiedene Prozesse intuitiv richtig ausgef¨ uhrt. F¨ ur ein automatisches System ist die Reihenfolge der Bearbeitung, beispielsweise bei der Entleerung oder Bef¨ ullung eines Lagerkanals nach dem FIFO-Prinzip, nicht aus der Arbeitsanweisung unmittelbar herauszulesen. Verschiedene Funktionen der Lageroptimierung ben¨otigen dar¨ uber hinaus die M¨ oglichkeit der selbstst¨ andigen Generierung von Auftr¨agen, beispielsweise zur 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¨otigt ein automatisches System daher eine stringente Klassifizierung der Lager- und F¨ordertechnik aus informationstechnischer Sicht. Dazu sollten die in Tabelle 2.10 gelisteten Lagertypen definiert werden. Lagerplatzverwaltung Die Lagerplatzverwaltung ist zun¨achst 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¨achen) reduziert sich die Angabe ggf. auf eine Spezifikation der Fl¨achen und Koordinaten. Gleichzeitig umfasst die Lagerplatzverwaltung die Verwaltung der an einem Lagerplatz gelagerten Einheiten. Dazu geh¨oren 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¨otigt. 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¨ahlte Ladeeinheit eines Artikels dem aktuellen Auftrag zugewiesen wird, ist der Status des Artikels an den Auftrag zu binden. Die wichtigsten Stati von Lagerpl¨ atzen und Ladeeinheiten sind in Tabelle 2.11 zusammengefasst. Neben der Realisierung der Ein-/Auslagerfunktionalit¨at ist das Sperren von Best¨anden bzw. das Setzen von Sperrkennzeichen eine elementare Verwaltungsfunktion, die bei unterschiedlichsten Operationen Verwendung 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¨atze, also das Abbild des momentanen Lagerzustandes, wird als Lagerspiegel bezeichnet. Der Lagerspiegel kann auch um die Art und Menge der pro Lagerfach vorhandenen Artikel erg¨ anzt sein.

56

2. Lagersysteme und Lagerverwaltung

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

lagerplatzbezogen

ladeeinheitenbezogen

disponibel

Auf den Lagerplatz kann beliebig zugegriffen werden.

Auf den Artikel kann beliebig zugegriffen werden.

reserviert

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

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

gesperrt

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

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

Mengenverwaltung (Bestandsf¨ uhrung) Eine andere logische Betrachtung erfolgt durch die Mengenverwaltung und Bestandsf¨ uhrung. Kernpunkt dabei ist die Registrierung und Aktualisierung der pro Artikel gelagerten Mengen insgesamt, ggf. unter Ber¨ ucksichtigung der relevanten Stati (s. Tabelle 2.12). Die Verwaltung der Waren nach unterschiedlichen Kriterien (Min./Max.-Bestand) soll die Versorgungssicherheit gew¨ahrleisten und ¨ ¨ Ubermengen vermeiden. Dazu sind bei Uberoder Unterschreiten vorgegebener Grenzen Meldungen auszul¨ osen oder Aktionen (Bestellungen, Umlagerungen etc.) zu initiieren. ¨ Diese Funktion erfordert aber auch in besonderem Maß die Uberwachung ¨ des Lagergutes. Dazu z¨ ahlen die Uberwachung der zul¨assigen Lagerdauer und das Sperren des Artikels bei Erreichen eines bestimmten (Verfall-)Datums. Unter bestimmten Voraussetzungen ist in solchen F¨allen eine Auslagerung zum Schutz anderer Lagerg¨ uter zu initiieren. Der wesentliche Unterschied zu einem Warenwirtschaftssystem (WWS), in dem z. T. ¨ ahnliche Funktionen liegen, besteht in der 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¨allen ausgepr¨ agt erforderlich ist.

2.3 Warehouse Managementsystem

57

Tabelle 2.12. Bestandsklassen Bezeichnung

Bedeutung

physischer Bestand

im Lagersystem vorhandene Einheiten

verfügbarer Bestand

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

reservierter Bestand

mit Sperrkennzeichen versehener Bestand

Fehlmengen

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

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

58

2. Lagersysteme und Lagerverwaltung

Optimierung durchzuf¨ uhren, was als Lagerreorganisation verstanden wird. Ausl¨ oser hierf¨ ur k¨ onnen sein: ¨ • Anderungen im 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¨ohung der Umschlagleistung, Verbesserung der Systemnutzung), ¨ (schnelle Reaktionen auf • Systemflexibilit¨ at bei kurzfristigen Anderungen Transportanforderungen), • Systemzustands¨ uberwachung (Laufzeit von Fahrzeugen, Betriebskosten pro Fahrzeug etc.).

2.3 Warehouse Managementsystem

59

Umfassende Systeme zur Fahrzeugdisposition und -f¨ uhrung werden als Staplerleitsysteme (SLS) oder Transportleitsysteme (TLS) bezeichnet (s. [71]). Die Systeme bestehen aus einem rechnergest¨ utzten Leitstand oder Leitrech¨ ner, einem drahtlosen Ubertragungsmedium (Funk oder Infrarot) und mobilen Terminals auf den Fahrzeugen. Die eingehenden Transportauftr¨age bzw. -anfragen (Bedarfsanforderungen) werden aufbereitet, mit den relevanten Daten erg¨ anzt (z. B. Erg¨ anzung von Artikelnmummer oder -bezeichnung, Lagerort (Quelle), Zielort (Senke)) und anhand bestimmter Prozeduren und Strategien an die Fahrer u ¨bermittelt. Bei allen Leitsystemen muss im ersten Schritt eine Festlegung getroffen werden, welche F¨ ordermittel f¨ ur einen bestimmten Auftragstyp grunds¨atzlich 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¨ordermittel zu einem idealen“ Fahrplan und somit auch die Erstellung einer opti” mierten Auftragsreihenfolge. Das Hauptziel liegt in der Optimierung der Systemleistung. Wesentliche Voraussetzung f¨ ur ein Scheduling ist dabei die Sammlung einer Reihe anstehender Auftr¨age in einem Auftragspool, aus dem heraus die optimale Verteilung erfolgen kann. Im Gegensatz zu einer manuellen Fahrplanerstellung, die im lagertechnischen Umfeld ohnehin nur in den seltensten F¨ allen einsetzbar ist, erfolgt das Scheduling wiederholt in relativ kurzen Abst¨ anden. In der praktischen Umsetzung wird in der Regel eine Mischform der beiden Verfahren eingesetzt, in der priorit¨ are Auftragsanforderungen jederzeit ber¨ ucksichtigt werden k¨ onnen. Neben solchen umfangreichen dispositiven F¨ uhrungssystemen existieren einfache Systeme zur reinen F¨ ordermittelverwaltung, bei denen die Erfassung des Systemzustandes im Vordergrund steht und keine auftragsdispo-

60

2. Lagersysteme und Lagerverwaltung

sitiven Zuweisungen erfolgen. Dazu z¨ ahlen die Erfassung der Betriebszeiten oder Reparaturkosten je Fahrzeug sowie die Batteriezustands¨ uberwachung und Kontrolle der Wartungsintervalle je Fahrzeug. In Systemen mit Nutzung der Fahrzeuge durch einen gr¨ oßeren Personenkreis bietet sich gegebenenfalls die Fahrzeugf¨ 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¨agt, 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¨age pro Kommissionierer; Einlagerungen pro Staplerfahrer; Wartezeiten pro Fahrzeug) ¨ • Ubersichtsinformationen – Lagerspiegel (Sortierung nach Lagerpl¨ atzen, frei/belegt, ...) – Lagerbestand – Lagerstatistiken (Umschlagh¨ aufigkeiten, St¨orungszeiten, F¨ ullgrad, ...) – Raumnutzung • Betriebsmittelstatistiken – Laufzeiten – Ausfallzeiten – Wartungs- und Reparaturkosten je Einheit • u. v. a. m. W¨ ahrend die personenbezogene Leistungserfassung in vielen F¨allen nicht unproblematisch ist und in der Regel die Einbeziehung des Betriebsrates erfordert, ist sie in einigen F¨ allen sogar unverzichtbare Basis f¨ ur die Leistungsabrechnung. Die gilt insbesondere f¨ ur die • Erfassung bei Akkordlohn, • Erfassung von Kontraktlogistikleistungen. Die Erfassung aussagekr¨ aftiger Statusinformationen ist die elementare Voraussetzung zur Steuerung und Optimierung des Distributionssystems. Im Bereich der Systemsteuerung m¨ ussen basierend auf diesen Daten Personalbedarfe (z. B. in Kommissionierbereichen) oder sonstige Ressourcenbedarfe ermittelt und eingeplant werden. Auslastungsgrade von F¨ordermitteln zeigen, ob parallel angeordnete Systeme im Gleichgewicht arbeiten. Wartezeiten an bestimmten Punkten k¨ onnen wiederum Engp¨asse anzeigen und eine ¨ Uberpr¨ ufung von Betriebsstrategien, Systemleistungen oder Personaleinsatz initiieren.

2.3 Warehouse Managementsystem

61

Entscheidend f¨ ur die Nutzung und erfolgreiche Verwertung der Daten ist das zugrunde liegende Erfassungsverfahren. Es existieren zwei prinzipielle Verfahren zur Ermittlung aussagekr¨ aftiger Daten und Kennzahlen: Online-Erfassung Die zur Generierung der ben¨otigten Daten erforderliche Datenbasis wird im Prozess erfasst und automatisch in die gew¨ unschte Kennzahl umgesetzt. Vorteilhaft ist dabei, dass die Kennzahlen unmittelbar zur Verf¨ ugung stehen. Demgegen¨ uber konzentriert sich die Erfassung und Auswertung auf die im Vorhinein zu 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¨aume auszublenden, ist nicht m¨ oglich, da als Ergebnis lediglich die aggregierte Kennzahl vorliegt. Insofern stellt dieses Verfahren ein statisches System dar. Zeitreihenerfassung Es wird zun¨ achst nur ein 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¨age – Anforderungen: • Anforderungs-ID/Bedarfs-ID • Quelle/Senke • Datum/Zeit • Status (Eil-/Normal) – Erf¨ ullung: • Person oder Betriebsmittel-ID • Datum/Zeit • Terminierung • Betriebsprotokoll – Betriebsbeginn/Betriebsende – Fehler-/St¨ orungsmeldungen und -zeiten – Lagerbewegungen • Einzelinformationen – artikelbezogene Daten (Artikel-Nr., Best¨ande, ...) – auftragsbezogene Daten (Auftrags-Nr., Auftragspositionen, Termine, ...) – lagereinheitenbezogene Daten (Lagerplatz-Nr., frei-/belegt-Status, Menge, ...)

62

2. Lagersysteme und Lagerverwaltung

Daneben m¨ ussen aus rechtlichen Gr¨ unden Lieferscheine bzw. Warenausgangsprotokolle erfasst und dokumentiert werden. 2.3.5 Inventur Die Inventur ist eine gesetzliche 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¨aten, also auch bei Best¨ anden, muss eine k¨orperliche Bestandsaufnahme durchgef¨ uhrt werden. Damit sollen insbesondere die Lagerbest¨ande (Buchbest¨ande) und die Zuverl¨ assigkeit der Bestandsf¨ uhrung (Lagerbuchf¨ uhrung) u uft wer¨ berpr¨ den. Alle Gegenst¨ ande (Lagereinheiten) sind zu identifizieren und zu klassifizieren und durch Z¨ ahlen, Messen oder Wiegen mengenm¨aßig zu erfassen. Es muss ein Aufnahmebeleg mit folgenden Angaben erstellt werden: • • • • • • •

¨ Belegnummer (Uberpr¨ ufbarkeit der Vollst¨ andigkeit), Lagerort und Position, Bezeichnung des Gegenstandes, aufgenommene Menge und Mengeneinheit, Einheitspreis und Gesamtwert, ggf. Hinweise auf 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¨oglich. Aus diesem Grund bestehen unterschiedliche Verfahren und Vereinfachungen zur Durchf¨ uhrung der Inventur, deren Anwendung allerdings mit den jeweiligen ufern und Finanzbeh¨ orden abzustimmen ist: Wirtschaftspr¨ Stichtagsinventur Die klassische Form der Inventur erfordert die k¨orperliche Aufnahme aller Best¨ ande am Bilanzstichtag. Da der Gesch¨aftsverkehr am Bilanzstichtag ruht, ergeben sich keine Ver¨anderungen am Verm¨ ogen“. Eine solche Aufnahme ist nur bei kleineren Systemen m¨og” lich. Es besteht auch die M¨ oglichkeit, die Inventur nicht notwendigerweise an einem Tag, jedoch zeitnah, d. h. bis zu zehn Tage vor oder nach dem Bilanzstichtag durchzuf¨ uhren, sofern Bestandsver¨anderungen zuverl¨assig aufgezeichnet, nachgewiesen und im Inventar zum Bilanzstichtag entsprechend ber¨ ucksichtigt werden. Noch weitergehender erm¨ oglicht die vor- oder nachverlegte Stichtagsinventur, den Bestand auf einen Tag, drei Monate vor oder zwei Monate nach dem Bilanzstichtag, zu ermitteln und durch einen besonderen Bestand zur¨ uckzurechnen. Das setzt allerdings ein Fortschreibungs- bzw.

2.3 Warehouse Managementsystem

63

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

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

64

2. Lagersysteme und Lagerverwaltung

Sch¨ atzverfahren Aufbauend auf den Kenngr¨oßen der H¨aufigkeitsverteilung einer Stichprobe wird auf die Kenngr¨oßen der Grundgesamtheit geschlossen. Bei geschichteten Sch¨atzverfahren wird die Grundgesamtheit in Teile zerlegt, aus denen jeweils eine Stichprobe gezogen werden muss. Gebundene Sch¨ atzverfahren beziehen außerdem zur Hochrechnung eine Hilfskennzahl, z. B. den Bestandswert lt. Buchhaltung, in die Berechnung ein. Wie bereits oben angef¨ uhrt, h¨ angt die Auswahl eines Verfahrens von der Zustimmung durch den jeweiligen Wirtschaftspr¨ ufer und die zust¨andige Finanzbeh¨ orde ab. 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¨asst eine ¨außerst azise Bestandsf¨ uhrung zu. Es darf dabei auch nicht u pr¨ ¨ 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¨assigkeit oder Diebstahl nicht selten erst durch die Einf¨ uhrung einer zuverl¨assigen Inventur aufgedeckt.

2.4 Basisdaten und Kennzahlen von Lagersystemen

65

2.4 Basisdaten und Kennzahlen von Lagersystemen Die Planung und Ausgestaltung von Lager- und Distributionssystemen erfolgt derartig vielschichtig, dass eine vollst¨ andige Sammlung aller m¨oglichen relevanten systembeschreibenden Gr¨ oßen praktisch nicht m¨oglich ist. Der u oßen ist im Einzelfall zur Kl¨arung einer ¨ berwiegende Teil solcher Kenngr¨ gegebenen Aufgabenstellung zu definieren bzw. zu erstellen. Im Folgenden sollen dennoch die elementaren und allgemeing¨ ultigen Kenngr¨oßen, die in einer Vielzahl bekannter Systeme existieren und zur Anwendung gelangen, eingef¨ uhrt werden. Dabei werden grunds¨ atzlich Basisdaten und Kennzahlen unterschieden: Basisdaten werden als Absolutzahlen bezeichnet und ergeben sich aus unmittelbarer Messung, Z¨ ahlung, Summation oder 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 angeren Zeitraum unver¨anderte ¨ber einen l¨ Daten. Die Stammdaten enthalten alle wichtigen Informationen u ¨ ber die grundlegenden Eigenschaften eines Artikels, Ladehilfsmittels usw. Die bedeutendsten Stammdaten f¨ ur den Lagerbetrieb sind die Artikelstammdaten, da alle wesentlichen Lagerfunktionen und Kontrollmechanismen darauf zur¨ uckgreifen. Der Artikelstamm enth¨ alt Beschreibungen aller Artikel, unabh¨angig von ihrem aktuellen Bestand. Die Summe der Artikel entspricht grunds¨atzlich dem Sortiment. Abweichungen gegen¨ uber dem Bestand bzw. dem tats¨achlichen Sortiment ergeben sich jedoch durch ausgelaufene oder tote Artikel. Wesentliche Elemente des Artikelstamms sind in Tabelle 2.13 exemplarisch aufgef¨ uhrt. Bestandsdaten Diese Datengruppe gibt u ¨ ber die zu einem Zeitpunkt oder l¨ angeren Verlauf gelagerten und bereitgehaltenen Mengen der Artikel Auskunft. Die Aktualit¨at und Genauigkeit dieser Datenerfassung ist von besonderer Bedeutung zur Sicherstellung der Lieferf¨ ahigkeit und zur Dimensionierung des Lagersystems. Da diese Daten kontinuierlichen Ver¨anderungen unterworfen sind, werden sie auch als dynamische Daten bezeichnet.

66

2. Lagersysteme und Lagerverwaltung

Tabelle 2.13. Elementare Basisdaten Artikelstammdaten

Bestandsdaten

Bewegungsdaten

sonstige Systemdaten

Artikelnummer Bezeichnung

Artikelanzahl Gesamtbestand

Wareneingänge/d Warenausgänge/d

Artikelgewicht

Durchschnittsbestand

Einlagerungen/d

Auftragsarten Ladeeinheitenstammdaten

Artikellänge

Mindestbestand/Artikel

Auslagerungen/d

Artikelbreite

Anz. LE/Artikel

Mengenumschlag/a

Artikelhöhe

verfügbarer Bestand

Umlagerungen/d

Mengeneinheit

Aufträge/d

Art Ladeeinheit

Aufträge pro Artikel

Beladungsfaktor (Packmenge/ Ladeeinheit)

Positionen/Auftrag Positionen/d Zugriffe/Positionen

Greifeinheit (Packmenge/ Entnahmeeinheit)

Auftragseingang/h Auftragsdurchlaufzeit Materialdurchlaufzeit

Sperrkennzeichen

Auftragszahl/Auftragsart

ABC Klassifikation

Doppelspielanteil/d

Chargennummer

Kompletteinheiten/d

Gewicht/Entnahmeeinheit

Verpackungsstammdaten Lagerkapazität Flächenrestriktionen Raumrestriktionen Flächen-/Volumennutzungsgrad Anzahl LE/Artikel Anzahl Mitarbeiter/ Bereich Krankenstand Betriebskosten (Personal, Energie, Wartung) Investitionskosten (Austausch) Wertumschlag/a

Gewicht/Ladeeinheit

Produktivität

Mandant Verfallkennzeichen Restlaufzeit Sortereignung h = Stunde

d = Tag

a = Jahr

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

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

2.4 Basisdaten und Kennzahlen von Lagersystemen

67

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

68

2. Lagersysteme und Lagerverwaltung

Tabelle 2.14. Beispiele f¨ ur Logistikkennzahlen Kennzahl

Lieferbereitschaftsgrad

Definition

Anzahl termingerecht ausgelieferter Bedarfsanforderungen (Stck)

Zielsetzung/ Fragestellung

Einflussgrößen

Lieferservice, Kundenzufriedenheit

Auftragshandling, Durchsatz, Kapazität

Nutzung der Ressource Lagerkapazität

Bestandsmanagement

Dynamik des Lagers

Große Versandeinheiten (durch Kundenaufträge)

Bestandskosten

Bestellwesen

Wahl der Lagertechnik

Lagertechnik

Bestandskosten, Dynamik des Lagers, Servicegrad

Bestellwesen

Bestandskosten, Servicegrad

Bestellwesen

Wahl des Kommissionierverfahrens

Ablaufsteuerung, Kommissionierprinzip, Informationsmanagement

mittlere Wegzeiten, Kommissionierleistung

Nachschubsteuerung, Regaltechnik

Anzahl Bedarfsanforderung (Stck)

Lagerfüllungsgrad

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

Umschlagsgrad mengenbezogen

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

Umschlagsgrad wertbezogen

Gesamtumsatz (€)

Kosten/Lagerplatz

Gesamtkosten (€)

Ø Lagerwert (€)

Lagerkapazität (Stck)

Lagerreichweite mengenbezogen

Aktueller Lagerbestand (Stck)

Lagerreichweite wertbezogen

Lagerbestand (€)

Kommissionierweg/ Position

Lagerumsatz (Stck/a)

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¨ange 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¨ande 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¨alter statt. Dieses Prinzip wird auch als zweistufiges Cross Docking oder Beh¨alter Cross Docking bezeichnet. Das wesentliche Merkmal ist die Durchf¨ uhrung einer Kommissionierung. Cross Docking als Durchlaufsystem In diesem Fall werden die eingehenden Lieferungen durch die Lieferanten entsprechend den Auftr¨ agen einzelner Filialen bereits so vorkommissioniert, dass die einzelne Logistische Einheit nicht mehr aufgebrochen und auf Filialen verteilt, sondern nur noch konsolidiert, d. h. mit anderen auftragsreinen Einheiten zusammengef¨ uhrt wird. Dieses Prinzip wird auch als einstufiges Cross Docking bezeichnet.

70

2. Lagersysteme und Lagerverwaltung

Werden dabei nur ganze Transporteinheiten (z. B. Paletten) umgeschlagen, spricht man z. B. vom Paletten-Cross-Docking. Befinden sich auf den Ladeeinheiten dagegen f¨ ur einzelne Filialen vorkommissionierte Beh¨alter, die den einzelnen Filialen bzw. Touren zugeordnet werden m¨ ussen, wird das Prinzip auch als Pre-sorted Store Order bezeichnet. In diesem Fall 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¨oglich. Ist das Auftragsspektrum der Filialbetriebe weitgehend gleich, werden auch die Touren zwangsl¨ aufig zu einem ¨ ahnlichen Zeitpunkt fertiggestellt. Hieraus k¨onnen Engp¨ asse im Warenausgang entstehen. Dadurch sind gegebenenfalls auch t¨ aglich mehrfache Belieferungen einzelner Filialen erforderlich. In der praktischen Umsetzung macht es daher nur dort Sinn, wo relativ konstante Verbr¨ auche, ¨ ahnliche Mengen und Artikel, kurze Wiederbeschaffungszeiten und kurze Distanzen zu den Filialen vorliegen. Anwendungen 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¨aufe in das Warehouse Managementsystem integriert werden. Empfehlungen f¨ ur die Umsetzung der Kommunikationsschnittstellen liefert [6]. 2.5.2 Outsourcing der physischen Distributions- und Lagerprozesse Die Hintergr¨ unde zur externen Vergabe von Logistikleistungen wurden bereits einleitend behandelt (s. S. 17). Auswirkungen auf das Lagermanagement ergeben sich unter anderem in der Anbindung der externen Systeme an die eigene Warenwirtschaft. Um in Outsourcing-L¨ agern mit mehreren Kunden die Prozesse speziell auf die Bed¨ urfnisse einzelner Kunden ausrichten zu k¨onnen, ist die Ber¨ ucksichtigung der Prozesse, Abl¨ aufe und Strategien nicht nur in waren- und kundenbezogener, sondern auch in mandantenbezogener Sicht notwendig, was im WMS zu implementieren ist. Ein solches System wird als mandantenf¨ahig bezeichnet. Da die Abrechnung der erbrachten Leistungen oftmals auf Basis durchgef¨ uhrter Aktionen erfolgt, ist außerdem die Erfassung einzelner Leistungen (z. B. Staplerfahrten, Kommissionierpositionen) in Abh¨angigkeit vom Mandantenauftrag wichtig.

2.5 Besondere Abl¨ aufe und Verfahrensweisen

71

Abbildung 2.10. Prinzipien des Cross Docking

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

72

2. Lagersysteme und Lagerverwaltung

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

3. Grundlagen der Lager- und F¨ ordertechnik

Entsprechend der Vielfalt m¨ oglicher Aufgabenstellungen und Besonderheiten bei der Lagerung und F¨ orderung von St¨ uckg¨ utern, hat sich eine ebenso große Vielzahl systemtechnischer Umsetzungen zur effektiven Erbringung dieser Aufgaben herausgebildet. Im Folgenden sollen die g¨angigsten technischen L¨ osungen zur Lagerung und F¨ orderung von G¨ utern als Basis f¨ ur die Diskussion der 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¨andnis dieser Systeme. Hinsichtlich einer u ¨bergreifenden und vergleichenden Betrachtung wird auf andere Werke verwiesen [24, 34, 47, 48, 59].

3.1 Lagersysteme Um Lagersysteme richtig bewerten und ausw¨ ahlen zu k¨onnen, ist eine Systematik hilfreich, aus der systembedingte Leistungscharakteristika allgemeing¨ ultig abgeleitet werden k¨ onnen. Die grundlegenden 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¨aufig zu einer Ortsveranderung 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

3. Grundlagen der Lager- und F¨ ordertechnik

Tabelle 3.1. Differenzierung der Lagersysteme Merkmal

Ausprägungsformen

Beschreibung

gängige Zielsetzungen

Lagertechnik

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

Lagerform

Lagerort

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

3.1 Lagersysteme

75

Abbildung 3.1. Bodenlagerung a) Blocklagerung b) Zeilenlagerung

Tabelle 2.4, S. 33) m¨ oglich ist. Dabei kann es sich einerseits um klassische monostrukturierte L¨ ager (Getr¨ anke, Rohstoffe) und andererseits um Pufferl¨ager 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¨oglich. Ebenso ist die direkte Zuweisung eines Lagerplatzes an einen Bediener (Stapler-

76

3. Grundlagen der Lager- und F¨ ordertechnik

fahrer) kaum m¨ oglich, da pr¨ azise Referenzpunkte, wie z. B. die Fachnummer eines Lagerregals, fehlen. Eine genaue Platzverwaltung existiert damit quasi nicht, die Mengenverwaltung erfolgt u ¨ ber die Erfassung der zu- und abgehenden Einheiten. Diese Situation kann insbesondere zu Problemen bei der Chargenverfolgung f¨ uhren. Sofern eine solche Verfolgung gefordert wird, l¨asst sich im ersten Ansatz die getrennte Lagerung einzelner Chargen in separaten Stellfl¨achen durchf¨ uhren. Neuere L¨ osungsans¨ atze versuchen via GPS oder aufbauend auf der Technologie Fahrerloser Transportsysteme die exakte Position im Raum bei der Ein- und Auslagerung zu erfassen und dadurch eine Materialflussverfolgung zu gew¨ ahrleisten [36]. Demgegen¨ uber werden in automatisch betriebenen Bodenblockl¨agern, die mit Automatikkranen oder Fahrerlosen Transportfahrzeugen bedient werden (beispielsweise bei der Lagerung von Papierrollen oder Stahlcoils), die einzelnen Positionen exakt erfasst und verwaltet. Somit besteht hier die zuvor dargestellte Problematik nicht. 3.1.2 Statische Regallagerung Beim Einsatz von Regalen steht zumeist die Optimierung der Fl¨achennutzung durch eine bessere Nutzung der H¨ ohe im Vordergrund. Die Ladeeinheiten werden in ein separates Fach oder an einen spezifizierten Ort eines Lagergestells gesetzt. Insbesondere k¨ onnen so auch nicht stapelf¨ahige 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¨agern. Zeilenregale Die Gestaltung eines Zeilenregals variiert mit der Gr¨oße, Form und dem Gewicht des einzulagernden Gutspektrums, der gew¨ahlten oder m¨oglichen Be-

3.1 Lagersysteme

77

dientechnik, der geforderten Ein-/Auslagerleistung und den r¨aumlichen Gegebenheiten. Die einzelnen F¨ acher des Regals sind auf die maximalen Abmessungen einzulagernder G¨ uter zuz¨ uglich allseitiger Freir¨aume zur Handhabung und Gut¨ ubergabe auszulegen. Die L¨ ange einzelner Lagerg¨ange und die Anordnung der Bedien- und Gassenwechselwege werden im Wesentlichen durch die Anforderungen des Kommissioniersystems gepr¨agt. Der Begriff Zeilenregal definiert zun¨ achst, dass einzelne F¨acher u ¨ber- und nebeneinander angeordnet werden und die Ladeeinheiten unmittelbar an der Regalfront ein- und ausgelagert werden. Im normalen Fall der einfachtiefen Lagerung kann somit auf jede Lagereinheit direkt 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¨alterregal, Kastenregal bzw. Kastenlager) oder die Lagerbauform (Traversenregal, Kragarmregal, Wabenregal) bezeichnet werden. Ein entscheidendes Merkmal ist dabei auch die Unterscheidung in Lagerung mit und ohne Ladehilfsmittel. Die Regalbedienung erfolgt bei schweren und großen Einheiten u ¨ blicherweise u ate oder Krane, die die Ladeeinheit ¨ ber Gabelstapler, Regalbedienger¨ durch vertikale Hubbewegung absetzen respektive anheben. Vereinzelt kommen auch Satellitenfahrzeuge zum Einsatz, die u ¨ber Lastaufnahmemittel zur seitlichen Lastaufnahme verf¨ ugen (Automatische Verteilfahrzeuge). Bei leichten Einheiten ist auch die manuelle Bedienung u ¨ blich. In Abh¨angigkeit von der eingesetzten Bedientechnik variieren die erforderlichen Arbeitsgangbreiten und damit der realisierbare Raumnutzungsgrad. Palettenregale Palettenregale (engl. Racks) stellen die am h¨aufigsten eingesetzte Lagertechnik f¨ ur Paletten dar. Sie setzen auf einem standardisierten Ladehilfsmittel auf. Im klassischen Fall wird die eingelagerte Einheit (Palette oder Gitterbox) nur an den beiden Stirnseiten unterst¨ utzt, wobei 1

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

78

3. Grundlagen der Lager- und F¨ ordertechnik

die Lagereinheit l¨ angs oder quer eingelagert wird. Bei der L¨angseinlagerung sind jeweils zwischen den vorderen und den hinteren Regalst¨ utzen zwei Traversen befestigt (geschraubt, im Lochraster eingeh¨angt oder verschweißt), auf denen die Ladeeinheiten nebeneinander gelagert werden. Bei Verwendung von Standardpaletten (800 mm×1200 mm, 1000 mm×1200 mm) ergibt sich aufgrund der Palettenkonstruktion zwangsl¨aufig die Einlagerung in L¨ angsrichtung der Ladeeinheit, bezogen auf die Fachtiefe (s. Abb. 3.2). Aufgrund der M¨ oglichkeit, mehrere Ladeeinheiten direkt nebeneinander zu lagern, wird das Prinzip als Mehrplatzlagerung verstanden. Gemeinhin werden drei bis max. f¨ unf Ladeeinheiten in einem so genannten Feld nebeneinander gelagert. Bei der Quereinlagerung wird eine im Allgemeinen winkelf¨ormige 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¨onnen die meisten Regalbedienger¨ ate nicht derart schmal ausgef¨ uhrt werden, dass sich insgesamt schmalere Arbeitsgangbreiten ergeben. Die Quereinlagerung besitzt im Fall der manuellen Kommissionierung im Regal allerdings eine bessere Erreichbarkeit der Artikel im Regalfach (die maximale Reichweite des Menschen betr¨ agt ca. 950 mm). Im Fall der doppelttiefen Lagerung ist eine Anpassung der Traversenh¨ohen auch an die Bauh¨ ohe und die Durchbiegung der Lastaufnahmeeinheit anzupassen. Dazu werden die hinteren Traversen um ca. 100 mm hochgesetzt. Werden unterschiedliche Palettenmaße eingelagert, zu denen die Traversen inkompatibel sind, k¨ onnen auf die Traversen auch Gitterroste, Bleche oder Bretter aufgelegt werden, wodurch streng genommen ein Fachbodenregal 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¨allen die Einlagerung kleinealter oder Tablare bevorzugt (z. B. 400 mm×600 mm). Tablare sind rer Beh¨ Blechwannen mit einer stirnseitig angebrachten Eingriffsleiste. Durch die geringen St¨ uckgewichte ist die Lagerung auf einfachen Winkelprofilen m¨oglich, die seitlich an den Lagerf¨ achern angebracht sind. Die geringen St¨ uckgutgewichte erm¨ oglichen dabei auch effektivere Formen der Lagerfachbedienung, die zu speziellen Auspr¨agungen der Zeilenregale gef¨ uhrt haben und als Beh¨alter-, Kasten- oder Tablarregale bezeichnet werden. Das relativ geringe St¨ uckgutgewicht erm¨oglicht in vielen F¨allen, die Lagereinheit (Beh¨ alter, Kasten, Tablar) in das Lagerfach zu schieben respektive

3.1 Lagersysteme

79

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

bei der Auslagerung aus dem Fach zu ziehen. Das Lastaufnahmemittel greift dazu in die Leiste oder den 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¨alter auf einer gemeinsamen Palette oder Mischpalette stellt besondere Anforderungen an die Lagerf¨ uhrung. Es ist nicht nur die Verwaltung mehrerer Einheiten am identischen Ort zu realisieren (was in der Regel u ¨ ber die Verbuchung ¨ auf eine einzige Paletten-ID erreicht wird), sondern auch die Uberwachung

80

3. Grundlagen der Lager- und F¨ ordertechnik

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

der Lagermenge pro Palette, da die Einheiten typischerweise unterschiedlich geleert werden. Dazu sind bei Bedarf Verdichtungsoperationen anzustoßen (vgl. Abschn. 2.3.2). Außerdem muss bei der Zulagerung eines Artikels auf eine bereits teilgef¨ ullte Palette die betreffende Einheit zun¨achst 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¨onnen u atze respektive mehrere 100 000 Beh¨alterpl¨atze um¨ ber 100 000 Palettenpl¨ fassen. Solche Systeme werden h¨ aufig in Silobauweise realisiert, dabei tr¨agt die Regalkonstruktion Dach und W¨ ande und bildet so einen reinen Einzweckbau, der nur dem Zweck der Lagerung dient. Vorteilhaft ist dabei neben der kurzen Realisierungszeit und den vergleichsweise geringen Kosten unter anderem der

3.1 Lagersysteme

81

deutlich k¨ urzere Abschreibungszeitraum. Allerdings muss der Regalbau auch den zus¨ atzlichen Lastf¨ allen Rechnung tragen. Liftsysteme (Turmregale) Einen Sonderfall der Zeilenregale stellen die Liftsysteme oder Turmregale dar. In diesem Fall werden zwei Lagers¨aulen einander gegen¨ uberliegend angeordnet. Dazwischen verf¨ahrt vertikal ein spezielles Lastaufnahmemittel, das u ¨ber eine Ziehtechnik Tablare zwischen den ¨ Lagerf¨ achern und dem Ubergabeplatz bewegt (s. Abb. 3.4). Durch die geringen bewegten Massen lassen sich dabei hohe Beschleunigungen realisieren und hohe Ein-/Auslagerleistungen erzielen. Neben Systemen mit festen Fachh¨ ohen innerhalb der Lagers¨aule werden auch Anlagen mit flexibel definierbaren Fachh¨ohen 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¨ohen an unterschiedliche G¨ uter und somit eine Volumenoptimierung, insbesondere bei variierenden Ladeeinheitenh¨ ohen. Fachbodenregal Fachbodenregale (engl. Shelves) besitzen f¨ ur jedes Lagerfach einen durchgehenden Lagerboden (ggf. auch Gitter), so dass Lagerg¨ uter mit beliebigen Abmessungen eingelagert werden k¨onnen. Durch die 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¨ohe betr¨agt zwei Meter. Unter Verwendung von Hilfsmitteln (z. B. Leitern) werden auch drei Meter hohe Ausf¨ uhrungen eingesetzt, wobei durch die zus¨atzlichen Bewegungsabl¨ aufe jedoch die Kommissionierleistung sinkt. Daneben werden zur Ausnutzung vorhandener Raumh¨ ohen auch mehrgeschossige Anlagen errichtet, ange direkt an den Regalst¨ utzen befestigt bei denen die Zu- und Bewegungsg¨ werden (s. Abb. 3.5). Wabenregal Beim Wabenregal werden mehrere Regale unmittelbar hintereinander angeordnet, so dass besonders tiefe Lagerf¨acher entstehen, die sich zur Lagerung von Langgut eignen. Wie bei Zeilenregalen u ¨ blich, lassen sich durch eindeutige Fachzuordnung eine pr¨ azise Lagerverwaltung und verschiedenste Ein-/Auslagerstrategien realisieren. Die Lagerg¨ uter werden je nach Anwendungsfall direkt, also ohne Ladehilfsmittel, oder durch Nutzung spezieller Ladungstr¨ager (Langgutkassetten oder Langgutwannen) in das Regalfach eingelagert. Die Lagerfachbedienung bedarf aufgrund der langen und zum Teil schweren Lagerg¨ uter besonderer Verfahren und Hilfsmittel. Es existieren dazu spezielle Regalbedienger¨ate,

82

3. Grundlagen der Lager- und F¨ ordertechnik

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

Stapler oder Krane. Aufgrund der großen Gangbreite eignet sich das System jedoch nur bei einer großen Menge einzulagernder Artikel oder G¨ uter. Kragarmregal An vertikalen oder geneigten Regalst¨ utzen werden auskragende Arme (Ausleger) befestigt, auf die das Lagergut abgelegt wird. Ebenso k¨ onnen die Kragarme als Trennelemente f¨ ur stehende G¨ uter genutzt werden. Wie im Fall der Palettenregale k¨ onnen durch zus¨atzliche Auslegeb¨oden auch durchgehende 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¨oglichkeit, sehr hohe Volumennutzungsgrade staudruckfrei bei gleichzeitig geringem Fl¨ achenbedarf (durch große Lagerh¨ ohen) zu realisieren. Die Ladeeinheiten werden nur an den beiden Stirnseiten gest¨ utzt und m¨ ussen damit eine identische Breite aufweisen. Die Bewegung der Ladeeinheiten in schmalen

84

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.6. Einfahrregal [Foto: GEHRING]

Kan¨ alen stellt gleichzeitig hohe Qualit¨ atsanforderungen an die Ladeeinheiten bez¨ uglich Abmessungen und Formstabilit¨ at. Aus den genannten Eigenschaften leitet sich auch der bevorzugte Einsatzfall zur Lagerung großer Mengen weniger Artikel ab. Einfahr- und Durchfahrregale Der einfachste Fall der statischen Blockregallagerung stellt das Einfahr- bzw. Durchfahrregal dar. Die Regalst¨ utzen werden derart angeordnet, dass sich jeweils vertikale Spalten ergeben, die durch Flurf¨ orderzeuge befahren werden k¨ onnen. An den Regalst¨ utzen werden wie bei der Einplatzlagerung durchgehende 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¨oglich. Der F¨ ullungsgrad des Regals h¨ angt in hohem Maße von der Ein- und Auslagerfrequenz ab. Betrieb und Organisation Aufgrund dieser Eigenschaften ist die Nutzung als Vorratsregal f¨ ur unterschiedliche Artikel wenig sinnvoll, jedoch bei gleichen Artikeln pro Gang und dem Umschlag ganzer Einheiten durchaus vor-

3.1 Lagersysteme

85

teilhaft. Die Erfassung und Verwaltung einzelner Lagerpl¨atze ist technisch zwar m¨ oglich, l¨ asst sich jedoch in der Praxis unter anderem durch die manuelle Bedienung und notwendige 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¨angig verfahren und dadurch auf die jeweils erste Einheit eines Kanals zugreifen kann. Dadurch lassen sich wesentlich mehr Einheiten als im Falle des Einfahrregals ansprechen. Zumeist wird die Einfahrstrategie, also LIFO, angewendet. Ebenso ist der beiderseitige 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¨aufig 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¨oglichen Einsatz einer Vielzahl von Fahrzeugen lassen sich kompakte Lagerung und hohe Durchsatzleistung vereinen. Mit wachsendem Mischungsgrad der Kan¨ale (verschiedene Ladeeinheiten in einem Gang) und notwendigem 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¨age. 3.1.3 Dynamische Regallager Aus verschiedenen Gr¨ unden werden Lagersysteme dynamisch ausgef¨ uhrt, d.h. die Ladeeinheiten zwischen Ein- und Auslagerung bewegt. Der damit erzielte Nutzen ist insbesondere durch • Wegeinsparung in der Kommissionierung und Erh¨ohung der Kommissionierleistung, • hohe Umschlagleistung bei kompakter Lagerung und • Nutzung der Vorteile der Block- und Zeilenlagerung gekennzeichnet.

2

ein Produkt der Westfalia F¨ ordertechnik

86

3. Grundlagen der Lager- und F¨ ordertechnik

Bei der dynamischen Lagerung werden zwei grundlegende Prinzipien unterschieden: feststehende Lagereinheiten in bewegten Regalen und bewegte Lagereinheiten in feststehenden Regalen. Zur ersten Gruppe z¨ahlen Verschieberegale und Umlaufregale, zur zweiten die verschiedenen Formen der Durchlaufregale. Verschieberegale Diese Regalform stellt die Erweiterung eines statischen Zeilenregals um eine verfahrbare Plattform, einen so genannten Fahrschemel, dar. Auf solche Fahrschemel k¨ onnen alle Regaltechniken wie Paletten-, Beh¨alter-, Fachbodenoder Kragarmregale montiert werden, allerdings bei begrenzter H¨ohe (bis ca. zehn Meter). Dadurch k¨ onnen einzelne Regalzeilen durch seitliches Verfahren zu einem kompakten Block zusammengef¨ uhrt werden und die Regalg¨ange entfallen (s. Abb. 3.7). Ebenso k¨ onnen einzelne Regalzeilen aus einem kompakten Block heraus auch stirnseitig verfahren ( herausgezogen“) werden. ” ¨ In einem solchen System kann auf jede einzelne Lagereinheit nach 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¨aten erg¨anzte Stetigf¨ordermittel (Kreis- oder Umlauff¨ orderer). Gegen¨ uber einem Fachbodenregal k¨onnen 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¨ache lassen sich durch Nutzung der Raumh¨ ohe relativ viele Artikel mit geringer 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¨angt 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¨andige Reversierfahrten zu vermeiden. Horizontale Umlaufregale (Karusselllager) An einer horizontal umlaufenden F¨ orderkette werden einzelne Lagerfelder befestigt, die eine Fach¨ bodenregals¨ aule oder Ahnliches aufnehmen. Die Bedienung bzw. Entnah-

88

3. Grundlagen der Lager- und F¨ ordertechnik

me durch den Kommissionierer erfolgt in der Regel am stirnseitigen Wendepunkt, wobei typischerweise mehrere Regale parallel angeordnet werden. F¨ ur ein anzusprechendes Lagerfach wird die Kette bewegt, bis sich die relevante Lagers¨ aule bzw. das Lagerfeld am Entnahmepunkt 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¨alter-Umlaufregale dar. Die Systeme dienen prim¨ ar der kurzzeitigen Pufferung, beispielsweise zur Konsolidierung von Teilauftr¨ agen im Versandbereich. W¨ahrend beim klassischen Umlaufregal in erster Linie einzelne Artikel oder Gebinde entnommen werden, wird beim Beh¨ alter-Umlaufregal der gesamte Beh¨alter gewechselt. Deshalb ist in diesem Fall auch eine hohe Umschlagleistung maßgeblich. Durch separate, u orderebenen kann jede einzelne Ebene ¨bereinanderliegende F¨ unabh¨ angig verfahren werden. Bei der Ein-/Auslagerung werden zu entleerende F¨ acher und freie F¨ acher u ¨ bereinander positioniert, so dass von einer zentralen Wechseleinrichtung (Stufenlift mit Mehrfach-Greifeinrichtungen) alle Operationen in einem Arbeitsschritt durchgef¨ uhrt werden k¨onnen. Durchlaufregal Durch Einf¨ ugen einer F¨ orderebene in einen feststehenden Regalblock k¨onnen sich die Lagereinheiten in den Lagerbl¨ ocken bewegen. Die Lagereinheiten werden entweder an der r¨ uckseitigen Regalfront in einen Lagerkanal gegeben, zur vorderseitigen Regalfront gef¨ ordert und dort entnommen oder an der Frontseite in den Lagerkanal eingeschoben und dort wieder entnommen (Einschubregal). In den Kan¨ alen befinden sich die Lagereinheiten hintereinander. Zugriff ist grunds¨ atzlich nur auf die vordere Regalfront m¨oglich. Durch das Durchlaufprinzip werden Beschickung und Entnahme getrennt onnen so unabh¨ angig voneinander ablaufen. Außerdem wird das FIFOund k¨ Prinzip zwangsl¨ aufig und ohne zus¨ atzlichen Steuerungsbedarf gew¨ahrleistet (bzw. LIFO im Fall des Einschubregals). Der entscheidende Vorteil liegt neben der kompakten Lagerung in der Vorhaltung vieler Artikel im direkten 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¨alen 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¨ahigen 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¨aten k¨ onnen hochdynamische Lager- und Umschlagsysteme realisiert und auch gemischte Kan¨ ale gebildet werden. F¨ ur eine umfassende Behandlung der Rollpalettentechnik sei auf [83] verwiesen. 3.1.4 Regalvorzone In der Vorzone eines Regalsystems fallen unterschiedliche Aufgaben an. Einzulagernde Einheiten sind auf die Gassen zu verteilen, Kommissionierpl¨atze vor dem Regal sind mit Bereitstelleinheiten und Leerbeh¨altern zu versorgen und gegebenenfalls Sammeleinheiten abzutransportieren. Weiterhin sind ausgelagerte Einheiten in Richtung Versand zu transportieren oder auf andere Regalgassen zu verteilen, im Rahmen der Inventur m¨ ussen Lagerein-

90

3. Grundlagen der Lager- und F¨ ordertechnik

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

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

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

3.2 F¨ ordersysteme

91

Stetigf¨ orderer besitzen eine kontinuierliche Arbeitsweise und sind zumeist ortsfest installiert. Sie verf¨ ugen u ¨ ber eine hohe F¨orderleistung, gemessen in St¨ uck/Zeiteinheit, und produzieren einen kontinuierlichen bzw. quasikontinuierlichen F¨ orderstrom. Sie erlauben vielf¨altige Linienf¨ uhrungen im Raum und die M¨ oglichkeit einer jederzeitigen Bereitschaft zur Aufnahme oder Abgabe von G¨ utern. Die kontinuierliche Arbeitsweise und die einfache Funktion erm¨ oglichen die gute Automatisierbarkeit und Kontrolle der Warenstr¨ ome im F¨ ordersystem. Unstetigf¨ orderer sind Einzelgewerke, die einzelne bzw. wenige F¨orderg¨ uter von einer Quelle zu einem Ziel transportieren und mit dem F¨ordergut verfahren. Dieser Prozess wird als Arbeitsspiel bezeichnet. Sie k¨onnen je nach Bauweise beliebige Punkte entlang eine Linie, in der Fl¨ache oder im Raum anfahren. Sie eignen sich daher in erster Linie zur Bedienung vieler Auf- und Abgabepunkte, zum Transport großer Gewichte und zur ¨ Uberbr¨ uckung langer Strecken. Je nach Systemauspr¨agung steigen mit der Einsatzflexibilit¨ at auch der Steuerungsaufwand und die Anforderungen an die Automatisierung. 3.2.1 Stetigf¨ orderer Rollenf¨ orderer Bei Rollenf¨ orderern wird das F¨ordergut u ¨ ber ortsfeste, drehbare Rollen gef¨ uhrt (s. Abb. 3.11). Der dissipative Bewegungswiderstand wird auf die Lagerreibung in der Rolle und die Walkung des Gutes beim Passieren der Rolle reduziert. Daraus resultiert ein geringer Energieaufwand zur F¨ orderung der St¨ uckg¨ uter. Die Bewegung der G¨ uter wird manuell, bei geneigten Rollenf¨ orderern durch Schwerkraft sowie durch verschiedene Antriebsformen motorisch realisiert. Bei hohen F¨ ordergutgewichten (ca. 1 t) kommen daorderketten 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¨oglicht, aus Kostengr¨ unden jedoch nur bei den genannten Ladeeinheiten ohne ausreichend steifes Ladehilfsmittel zum Einsatz gelangt. Im Bereich der leichten St¨ uckg¨ uter (Tablare, Beh¨alter; vgl. Abschn. 3.1.2) ergeben sich dagegen vielf¨ altige Gestaltungsformen der Last¨ ubergabe, da u. a. ein Ziehen der Einheiten unproblematisch m¨oglich ist (entsprechend glatte und ebene B¨ oden der Ladeeinheit und reibarme Regalaufnahmen vorausgesetzt). Verschiedene Formen der Lastaufnahmemittel sind in Abb. 3.24 dargestellt. Steuerung und Betrieb Der leistungsorientierte Betrieb von Regalbedienger¨aten setzt eine zeitnahe Ansteuerung der RBG-Funktionen voraus. Aus diesem Grund werden zur Steuerung eigene Systemsteuerungen in Form autarker Materialflussrechner (MFR) und unterlagerter Ger¨atesteuerungen zur Ausf¨ uhrung und Optimierung der Bewegungsabl¨aufe 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.

3.2 F¨ ordersysteme

109

a)

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

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

110

3. Grundlagen der Lager- und F¨ ordertechnik

Elektroh¨ angebahn Elektroh¨ angebahnen (EHB) sind flurfreie, automatische Unstetigf¨orderer. An einer an der Decke oder an St¨ utzen abgeh¨ angten Schiene verfahren elektrisch betriebene Einzelfahrzeuge, die im Allgemeinen u ¨ber an der Schiene montierte Schleifleitungen mit Energie versorgt werden. Das F¨ordergut wird u ¨ ber Lastgeh¨ ange, Greiftraversen oder verschiedene Formen von Haken und Hebezeugen unterhalb des Fahrzeuges transportiert. Die vielfach eingesetzten Lastgeh¨ ange k¨ onnen auch mit aktiven Lastaufnahmemitteln (Rollenbahnen, Tragkettenf¨ orderern) ausger¨ ustet werden und dadurch die Last¨ ubergabe optimieren und dar¨ uber hinaus zur St¨ uckgutverteilung eingesetzt werden. Im Lagerbereich werden EHB h¨ aufig zur Verbindung verschiedener funktionaler Bereiche (z. B. Wareneingang und Hochregal) eingesetzt. Ein EHB-System ist ein universell einsetzbares F¨ordersystem. Die Beladung erfolgt im Stillstand, so dass auch große und schwere Lasten sicher u onnen. Fahrgeschwindigkeiten bis zu 2 m/s erm¨oglichen ¨ bergeben werden k¨ ¨ gleichzeitig die effiziente Uberbr¨ uckung großer Distanzen und hohe Durchs¨atze. Durch zahlreiche Verzweigungs- und Zusammenf¨ uhrungselemente (Drehkreuze, Zwei-/Dreiwegeweichen, Parallelweichen) sowie Steig-/Gef¨allestrecken und Heber k¨ onnen umfangreiche Transportnetze realisiert werden. Bei großen Nutzlasten und hohen Durchs¨ atzen bieten sich an Steigstrecken ggf. Steighilfen an, um den technischen Aufwand an den Einzelfahrwerken, die in Spezialausf¨ uhrung und bei leichten Lasten auch eigenst¨andig 90◦ -Passagen u onnen, zu begrenzen. Durch angepasste Fahrzeuganzahl oder ¨ berwinden k¨ parallele 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¨ohere Lasten errichtet. Zur Erh¨ ohung der m¨ oglichen Traglast werden Einzelfahrwerke gekoppelt, wobei zumeist ein getriebenes Zugfahrzeug und ein oder mehrere nicht angetriebene Fahrwerke zusammengeschlossen werden. Die zur Ansteuerung der Einzelfahrzeuge erforderlichen Steuerungsbefehle werden entweder u ¨ber die 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¨allen wird ein EHB-vergleichbares Schienensystem auf dem Boden montiert, im Fall der EPB zwei parallele Schienen. Das F¨ ordergut wird oberhalb des Fahr-

3.2 F¨ ordersysteme

111

werks transportiert, wodurch sich dieses System in speziellen Anwendungen besser integrieren l¨ asst. Bez¨ uglich Ansteuerung und Organisation verhalten sich beide Systeme analog zur EHB. Krane Krane z¨ ahlen zu den klassischen Umschlagmitteln im 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¨ahlen die Folgenden: ¨ Br¨ uckenkrane Uber dem Arbeitsbereich sind seitlich Laufschienen (Kranbahnen) montiert, die sich direkt in das Geb¨aude abst¨ utzen. Die Kranbr¨ ucke u ¨berspannt den Arbeitsbereich und verf¨ahrt u ¨ber seitlich angeordnete Kopftr¨ ager. Oberhalb, seitlich oder unterhalb der Kranbr¨ ucke verf¨ ahrt das Katzfahrwerk, an dem das eigentliche Hebezeug (Seil- oder Kettenzug) befestigt ist. Seitlich angeordnete Katzen oder Winkellaufkatzen leiten ein Torsionsmoment in die ansonsten nur auf Biegung beanspruchte Kranbr¨ ucke ein, erm¨ oglichen jedoch eine Minimierung der Kranbauh¨ ohe und dadurch eine Vergr¨ oßerung des Arbeitsbereiches. Die Verfahrbewegung und Ableitung der Kr¨ afte in die Kranbahn erfolgt i. Allg. u ader. ¨ ber Stahllaufr¨ H¨ angekrane Die Laufschienen sind im Gegensatz zum Br¨ uckenkran unterhalb der Hallendecke montiert, so dass der Kran vollst¨andig unterhalb der Schiene h¨ angt. Dadurch wird der Arbeitsbereich vergr¨oßert, da die Laufkatze auch unterhalb der Schiene operieren kann. Ebenso ist ein ¨ Uberwechseln der Laufkatze in andere Hallenbereiche m¨oglich. ucken- oder H¨angekran besitzt der StaStapelkrane Basierend auf einem Br¨ pelkran anstelle des Seil- oder Kettenhubwerks einen festen, ggf. teleskopierbaren Mast. Dadurch wird die bei Kranen sonst u ¨ bliche Pendelneigung des Lastaufnahmemittels mechanisch umgangen, so dass sich der Stapelkran insbesondere zur Regalbedienung und zur dynamischen Diagonalfahrt eignet. Portalkrane Falls eine Abst¨ utzung der Kranbr¨ ucke u ¨ ber das Geb¨aude nicht m¨ oglich ist, kann die Kranbr¨ ucke u utzen auf dem Boden ver¨ ber eigene St¨ fahren. Je nach Baugr¨ oße wird dabei eine St¨ utze als Pendelst¨ utze ausgef¨ uhrt, um Spannungen in den Rahmenecken durch W¨armeeinwirkungen oder Toleranzen in der Kranbahn zu umgehen. Die gr¨oßere Masse und

112

3. Grundlagen der Lager- und F¨ ordertechnik

Form der Abst¨ utzung l¨ asst gegen¨ uber den Br¨ uckenkranen nur geringere dynamische Bewegungen zu. Konsolkrane Der Konsolkran wird l¨ angs einer senkrechten Wand verfahren und kragt in den Arbeitsbereich hinein. Die Laufschienen sind u ur geringere Lasten und klei¨ bereinander angeordnet. Sie werden nur f¨ ne Kragweiten ausgelegt und ggf. unterhalb eines weiteren Br¨ uckenkrans betrieben. Krane mit zylinderf¨ ormigem Arbeitsbereich basieren auf einem drehbar gelagerten Ausleger. Der Ausleger kann sowohl schwenkbar gelagert sein als auch u ugen, um verschiedene Radien des Arbeitsrau¨ ber eine Laufkatze verf¨ mes zu bedienen. Im innerbetrieblichen Einsatz kommen Drehkrane nur als S¨ aulendrehkrane an Industriearbeitspl¨ atzen zum Einsatz und besitzen f¨ ur den 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¨aufig eines selbstwirkenden Lastaufnahmemittels (Magnet- oder Sauggreifer oder Zangen) sowie einer geeigneten Steuerung zur Pendelkompensation. Der automatische Kranbetrieb darf nur in abgesperrten Bereichen ohne Personenverkehr erfolgen. Die Lagerortverwaltung setzt in diesem Fall eine exakte Erfassung des Lagerplatzes voraus, da die Lagerg¨ uter typischerweise unterschiedliche Abmessungen aufweisen und die Lagerpl¨ atze je nach Stapelbildung variieren. Gleichzeitig ist die Ber¨ ucksichtigung der Stapelreihenfolge erforderlich. Die Durchsatzleistung ist konsequenterweise von den Lagerstrategien und erforderlichen Umlagerungen abh¨ angig. Ebenso werden Krane zur Regalbedienung eingesetzt (sowohl automatisch als auch manuell), wobei die gleichen Anforderungen an das Steuerungssystem gelten wie bei Regalbedienger¨aten. Daneben finden Krane Einsatz als Umschlagger¨ate im Wareneingang und -ausgang. Dabei werden sowohl einzelne G¨ uter als auch Ladeeinheiten wie Container umgeschlagen.

3.3 Sortier- und Verteilsysteme

113

3.3 Sortier- und Verteilsysteme Sortier- und Verteilsysteme, h¨ 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¨onnen innerhalb des Verteilprozesses auch manuell ausgef¨ uhrt werden. Durch steigende Anforderungen hinsichtlich der Durchlaufzeit und der Betriebskosten, aber auch durch ver¨ anderte Versandstrukturen mit einem Wandel zur hochfrequenten und bedarfszeitpunktgerechten Belieferung kleiner Mengen spielen diese Systeme eine immer wichtigere Rolle. Im Folgenden sollen die elementaren Systemstrukturen und Verteilprinzipien dargestellt werden. 3.3.1 Einsatzfelder Die Anforderungen an den Verteilprozess variieren in einzelnen Einsatzbereichen erheblich. Im Bereich der Lager- und Distributionssysteme lassen sich folgende Einsatzbereiche unterscheiden: Umschlagsysteme der Post und Paketdienstleister In diesem Anwendungsfall sind eingehende Sendungen in m¨oglichst kurzer Zeit auf abgehende Touren zu verteilen. Im regionalen Umfeld gesammelte Sendungen werden in Kleintransportern an einem so genannten Hub angeliefert und je nach Zielort sowohl auf abgehende Transporte zu anderen Hubs als auch auf regionale Lieferungen, die vom selben Hub bedient werden, verteilt. Die zur Verf¨ ugung stehende Zeit innerhalb des Hubs ist aufgrund der kurzen Lieferzeiten auf wenige Stunden begrenzt. Die Distanz zum Zielort bestimmt dabei die Priorit¨ at des Sortierauftrags. Die eingehenden und abgehenden Str¨ ome bzw. Zuordnungen liegen weitgehend fest. Das einzelne Sendungsst¨ uck besitzt immer einen eindeutigen Zielort. Die Umschlagsysteme sind durch ausgepr¨agte Lastspitzen mit pulsierenden Anliefermengen gepr¨ agt. Das Sortiergutspektrum ist sehr groß und uneinheitlich, da die Sortierg¨ uter beim versendenden Kunden, also außerhalb des Systems, erzeugt werden. Vorgaben bestehen hinsichtlich des Gutgewichtes und der Abmessungen (zul¨assiges Gurtmaß h¨aufig = 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¨age werden f¨ ur den Versand separiert. Da die Menge der t¨aglich abzuarbeitenden Kundenauftr¨ age die m¨ ogliche Endstellenanzahl oftmals deutlich age zu Stapeln zusammengefasst, u ¨ berschreitet, werden die Kundenauftr¨ die nacheinander abgewickelt werden. Somit werden die Artikel bei jedem Lauf neu zugewiesen. Ebenfalls ist die Zuordnung einer einzelnen

114

3. Grundlagen der Lager- und F¨ ordertechnik

Einheit nicht eindeutig, da derselbe Artikel in verschiedenen Kundenauftr¨ agen gefordert sein kann3 und sich somit zur Zuweisung auf mehrere Ziele 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¨agen zu Versandauftr¨ agen (Beh¨ altersortierung) stellt dabei andere Anforderungen an das Verteilsystem: die Sortierg¨ uter sind zusammengefasste Mengen (Beh¨alter, Kartonagen), der Durchsatz ist relativ gering und die in der Endstelle zu 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¨afen ist die k¨ urzeste Anschlusszeit (Minimum Connecting Time, MCT), um den sicheren Gep¨ acktransfer bei Anschlussfl¨ ugen sicherzustellen. Auf großen Flugh¨afen ist eine kurze Prozesszeit nur durch umfangreiche f¨ordertechnische Anlagen mit Sortier- und Verteilfunktionalit¨at m¨oglich. Besondere Anforderungen stellt dabei das Sortiergut (Fluggep¨ack), dessen Gutform und -eigenschaften nicht pr¨ azise 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¨at 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.

3.3 Sortier- und Verteilsysteme

115

Systemeingabe Aufgabe der Systemeingabe ist die Angleichung der Arbeitscharakteristik des Sorters an das vorgeschaltete System. Pulsierende Eingangsstr¨ome m¨ ussen beispielsweise mit der konstanten Arbeitsweise des Verteilsystems mit einer festen Verteilleistung in Einklang gebracht werden. Dazu sind beispielsweise Entladebahnen zur Entleerung eingehender Transporter mit entsprechenden 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¨achtigten Verarbeitung. Das l¨ asst sich beispielsweise durch zwei hintereinander geschaltete Stetigf¨orderer mit F¨ ordergeschwindigkeiten v1 < v2 erzielen. Ausrichten F¨ ur eine pr¨ azise Durchf¨ uhrung des Ausschleusvorgangs auf dem Verteilf¨ orderer werden die Sortierg¨ uter in unterschiedlicher Art zum Verteilkreislauf ausgerichtet. Verteilsysteme wie Abweiser oder Schwenkrollensorter ben¨ otigen zur sicheren Gutabgabe die Vorpositionierung auf den Rand des F¨ orderers, wozu beispielsweise Rollenf¨ordererabschnitte mit schr¨ aggestellten oder konischen Rollen vor der Gutaufgabe eingesetzt werden. Bei F¨ orderern mit Einzelplatzbelegung verbessert die Orientierung des Sortiergutes mit der L¨ angsrichtung parallel zum Verteilkreislauf die m¨ ogliche Fl¨ achennutzung des Schalensegmentes und ggf. den Platzbedarf in der Endstelle. Zu diesem Zweck werden Zuf¨orderer und Aufgabef¨ orderer in einem entsprechenden Winkel zueinander justiert, oder es wird eine manuelle Aufgabe eingesetzt. Die sichere 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¨ate (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

3. Grundlagen der Lager- und F¨ ordertechnik

Aufbringen von Zusatzinformationen Wenn St¨ uckg¨ uter sich nicht durch Abmessungen, Gewicht, Erscheinungsbild oder vorhandenen Barcode unterscheiden lassen, ist eine zus¨ atzliche physische oder logische Verkn¨ upfung des Sortierkriteriums mit dem Sortiergut erforderlich. ¨ Gewichtserfassung Die Gewichtserfassung wird zur Vermeidung von Uberlastungen des Sortiersystems infolge von Gewichts¨ uberschreitungen oder zur Kontrolle auf Pickfehler eingesetzt. 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¨oht 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¨ahrt die Spracheingabe (Voice-Coding), die es dem Kommissionierer erm¨oglicht, mit beiden H¨ anden zuzugreifen. Spracheingabesysteme werden sowohl in Paketverteilzentren zur Eingabe von Postleitzahlen oder Routingcodes als auch bei der Kommissionierung von Artikeln eingesetzt (s. Abschn. 2.2.5). Insbesondere im Postbereich gelangt die Klarschrifterkennung zum Einsatz, die bei Leseproblemen wiederum andere Verfahren (Telecoding) integriert. Verteilen Der Aufbau eines Verteilsystems l¨ asst sich anhand verschiedener Kriterien 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

3.3 Sortier- und Verteilsysteme

117

Abbildung 3.25. Anordnung in Linien- und Ringstruktur

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

118

3. Grundlagen der Lager- und F¨ ordertechnik

Systeme mit Einzelplatzbelegung

Systeme mit freier Belegung

zu- und abfördernde Systeme

abweisende Systeme

Kraftfeld

zu- und abfördernde Systeme

abweisende Systeme

Kraftfeld

Quergurtsorter

Kammsorter

Kippschalensorter

Schwenkrollensorter

Schiebeschuhsorter

Kippgliederband

Tragschuhsorter

Brushsorter

Fallklappensorter

Kanalsorter

Dreharmsorter

Drehsorter

Transfere

Pusher

Ringsorter

Abweiser

Abstreifer

Abbildung 3.26. Systematik der Verteiltechniken

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

3.3 Sortier- und Verteilsysteme

119

abweisende Systeme Das Sortiergut wird durch ein separates Element vom F¨ ordermittel abgeschoben. Der Formschluss zwischen Sortiergut und Ausschleuselement garantiert ein sicheres Auschleusen, je nach Ausf¨ uhrung kann das Sortiergut dabei erheblich beansprucht werden. kraftfeldbasierte Systeme Die Systeme nutzen zur Ausschleusung die Erdbeschleunigung, teilweise auch Zentrifugalkr¨afte, und k¨onnen dadurch die Anzahl erforderlicher Antriebe reduzieren. Der Ausschleusvorgang ist auch von den Guteigenschaften (Gewicht, Dichte, Schwerpunktlage, Gleiteigenschaften) abh¨ angig und nicht f¨ ur alle G¨ uter einsetzbar. Die Zuordnung g¨ angiger Verteiltechniken anhand dieser 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¨oglichst viele G¨ uter unmittelbar hintereinander in dieselbe Endstelle ausschleusen zu k¨ onnen. • Die Geschwindigkeit in den Endstellen und der resultierende Staudruck d¨ urfen nicht zu groß sein. • geringer Platzbedarf • leichte Entleerung durch das Packpersonal (ergonomische Greifh¨ohe, kein Stoßen der G¨ uter) Aufgrund der zahlreichen Verwendung im System werden an Endstellen aber auch hohe Anforderungen hinsichtlich der Investitionskosten gestellt. Daher ist es wichtig, f¨ ur einen gew¨ ahlten Einsatzfall die geeignete Endstellentechnik und -dimension zu bestimmen. G¨ angige eingesetzte Techniken sind • • • • • •

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

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

120

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.27. Rutschen-Endstellen [Foto: BEUMER]

n¨ achsten Sortierauftrag freigegeben. Diesem Arbeitsschritt kommt eine besondere Bedeutung f¨ ur die Gesamtsystemleistung zu, da die Reihenfolge der zu bedienenden Endstellen und der Weg zwischen den Endstellen zu optimieren sind. Um die begrenzte Ressource Packer sinnvoll einzusetzen, sind optische Zustandsmeldungen vorzusehen und ggf. geeignete Bedienstrategien zu 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¨osungen 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¨orderrichtung Gurtf¨ orderer montiert, die auf die maximale Gutgr¨oße dimensioniert sind (s. Abb. 3.28). Jeder Gurtf¨ orderer ist separat verfahrbar. Bei der u ¨ blichen Form der seitlichen Gutaufgabe wird der Gurtf¨ orderer im Moment der Gutaufgabe synchron zum Zuf¨ uhrband verfahren und das F¨ordergut geht ohne Re-

3.3 Sortier- und Verteilsysteme

121

Abbildung 3.28. Quergurtsorter [Foto: AXMANN]

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

122

3. Grundlagen der Lager- und F¨ ordertechnik

Abbildung 3.29. Kippschalensorter [Foto: BEUMER]

Schiebeschuhsorter Zwei vertikal umlaufende Ketten sind mit St¨aben oder 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¨alt (s. z. B. [3]). Ein Θ-Verbund der Tabellen ARTIKEL und LADEEINHEIT kann in SQL durch eine zus¨ atzliche where-Klausel formuliert werden. 21 22 23

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

182

5. Informations- und Kommunikationstechnik

select * from ARTIKEL, LADEEINHEIT where ARTIKEL.GEWICHT > 20.000 Weitere elementare Verkn¨ upfungen sind u ¨ ber die Mengenoperationen Vereinigung (union), Durchschnitt (intersection) und Differenz (minus) m¨ oglich. Datenbanken werden als Client-Server-Applikationen betrieben. Die eigentliche Datenbank, die Datenbankengine (DBMS : Datenbankmanagementsystem), stellt als Serverprozess ihre Dienste den Clients zur Verf¨ ugung. Diese Clients sind Applikationen, welche die anwendungsspezifischen Operationen auf den Daten ausf¨ uhren. Im Bereich der WMS k¨onnte 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¨otigt man auf der Clientseite einen geeigneten ODBC-Treiber, der im Allgemeinen vom Hersteller der Datenbank geliefert wird. Die Client-Server-Architektur eines Datenbanksystems erfordert, dass jeder Datensatz, der manipuliert wird, zuerst vom Server – der Datenbank – zum Client gesendet werden muss, dort manipuliert und anschließend u uckgeschrieben wird. F¨ ur h¨aufig ¨ 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¨atze nur f¨ ur eine verh¨ altnism¨ aßig kurze Zeit gesperrt werden und damit schneller wieder ur andere Clients zur Verf¨ ugung stehen. Die Folge ist eine oft drastische f¨ 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¨ankte Zeit u uckt werden. Die Energiezufuhr erfolgt f¨ ur diese Zeit aus Akkus. Die ¨ berbr¨ Last¨ ubernahme wird dem Rechner u ¨ ber eine – meist serielle – Schnittstelle signalisiert. Das Betriebssystem hat nun die Aufgabe, wenn nicht innerhalb einer einstellbaren Zeit die Stromversorgung aus dem Netz wiederhergestellt wird, alle Anwenderprogramme zu beenden und anschließend den Rechner herunterzufahren“. Damit soll insbesondere der Datenbestand gesichert wer” den. Die Anwenderprogramme m¨ ussen in der Lage sein, sich auf ein solches Signal vom Betriebssystem geordnet zu beenden. Laufende Transaktionen (s. Abschn. 5.2.1) und ge¨ 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¨ocke 1 bis n auf die Laufwerke 1 bis n, danach die Bl¨ocke n+ 1 bis 2n ebenfalls auf die Laufwerke 1 bis n und so weiter in numerisch aufsteigender Reihenfolge geschrieben. Das Lesen erfolgt analog. Fehlersicherheit existiert bei diesem Verfahren nicht. F¨ allt ein Laufwerk aus, dann sind alle Daten auch auf den anderen Laufwerken verloren. RAID 1 wird auch mirroring genannt und basiert auf einer doppelten Speicherung der Daten (Datenspiegelung). Nutzbar ist daher nur die H¨alfte der vorhandenen Plattenkapazit¨ at. F¨ allt ein Laufwerk aus, dann wird mit dem jeweils anderen weitergearbeitet.

184

5. Informations- und Kommunikationstechnik

RAID 0 (disk striping) mit 3 Festplatten 1

4

7

...

8

5

2

Festplatte 1

...

3

Festplatte2

6

9

...

Festplatte3

RAID 1 (disk mirroring) 1

2

3

4

5

6

7

8

9

...

1

2

3

4

5

6

7

8

9

...

Festplatte 2

Festplatte 1

RAID 5 (distributed parity check) mit 4 Festplatten 1

4

7

...

2

5

p(7-9) . . .

3 p(4-6)

8

...

p(1-3)

6

9

...

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

RAID 5 versieht die Daten mit einer zus¨ atzlichen Pr¨ ufsumme und verteilt sowohl die Daten als auch eine Pr¨ ufsumme u ¨ber mehrere Laufwerke. RAID 5 ist besonders f¨ ur viele Zugriffe mit kleinen Datenmengen geeignet, daher wird diese Variante besonders h¨aufig in transaktionsorientierten Umfeldern wie Datenbanken eingesetzt. F¨allt ein Laufwerk aus, k¨ onnen die Daten aus den verbleibenden Laufwerken rekonstruiert werden. ¨ Journaling Alle Anderungen an den Datenbest¨anden werden in einer ¨ Journal-Datei aufgezeichnet. Diese Datei wird immer zeitlich vor den Anderungen der Datenbest¨ ande geschrieben. Auf der Basis des letzten Backups (s.u.) kann dann der aktuelle Zustand durch ein so genanntes Recovery wiederhergestellt werden. Die Voraussetzung hierzu ist die Verf¨ ugbarkeit der Journaldatei selbst. Die eigentlichen Daten-Dateien und die Journaldatei werden auf unterschiedlichen Festplatten gehalten. Ein Verlust einer der beiden Dateien ist damit unproblematisch. Sicherungskopien Gegen die Auswirkungen von Hardwareausf¨allen oder ¨ außeren Einfl¨ ussen wie Wasser, Feuer oder Uberspannung, aber auch gegen ¨ 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¨aßigen Abst¨ anden gesichert werden. Nach dem Aufspielen der letzten Sicherungs¨ kopie m¨ ussen noch die letzten Anderungen unter Nutzung der Journaldatei (s.o.) nachvollzogen werden. Falls die Journaldatei nicht mehr verf¨ ugbar ist, ¨ k¨ onnen die letzten Anderungen nur noch manuell nachvollzogen werden. Neben dem gelegentlichen Vollbackup werden durch inkrementelles und diffe¨ renzielles Backup nur Anderungen gesichert, um das Speichervolumen gering zu halten (s. Tabelle 5.9).

186

5. Informations- und Kommunikationstechnik

Das Backup dient auch der Archivierung von Daten f¨ ur eine sp¨atere Auswertung. Es sollte also immer ein Archivierungssystem betrieben werden, das nicht nur technische, sondern auch organisatorische Vorkehrungen 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¨ande 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¨ate, eine intuitive Bedienerf¨ uhrung und die ergonomische Gestaltung der Bildschirmmasken sind wichtige Voraussetzungen f¨ ur die Akzeptanz bei den Bedienern und f¨ ur eine geringe Fehlerquote. 5.3.1 Endger¨ ate Endger¨ ate sind alle Ein-/Ausgabeger¨ ate, die – im Gegensatz zu Sensoren und Aktoren, welche die Schnittstelle zur F¨ ordertechnik bilden – in direktem Bezug zu einem Bediener stehen. Diese Ein-/Ausgabeger¨ate werden oft zu komplexen Einheiten f¨ ur spezielle Einsatzzwecke zusammengestellt. Beispiele sind • Bildschirmarbeitspl¨ atze mit Mausbedienung und der Ausgabe von Warnt¨ onen u ¨ ber einen Lautsprecher, • Funkterminals mit einer Textanzeige, einer numerischen Tastatur und einem Barcodeleser (s. Abb. 5.15), • Zustandsanzeige durch eine Kontrolllampe und Quittierung durch die Bet¨ atigung eines Tasters.

5.3 Benutzerschnittstelle

187

Tabelle 5.10. Endger¨ ate typische Ausgabegeräte

typische Eingabegeräte

optische Anzeigen

Taster

Kontrolllampen

Maus oder Touchscreen

Textanzeigen

Tastatur

Bildschirm

Barcodescanner

Drucker

Lautsprecher

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

188

5. Informations- und Kommunikationstechnik

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

Die an einem Arbeitsplatz oder an einem Ger¨at ausf¨ uhrbaren Funktionen werden einer oder mehreren Rollen zugewiesen. Beispiele f¨ ur Funktionen ¨ sind das Sperren/Freigeben von Paletten und Lagerorten oder das Andern einer Palettenbelegung. Beispiele f¨ ur Rollen sind Wareneingangspr¨ ufung, Qualit¨ atskontrolle oder Disposition. In einem angenommenen Fall d¨ urfen sowohl die Wareneingangspr¨ ufung als auch die Qualit¨atssicherung Paletten sperren, w¨ ahrend nur die Qualit¨ atssicherung Paletten freigeben darf. Lagerorte k¨ onnen beispielsweise nur von der Disposition gesperrt und freigegeben werden. 5.3.3 Zugangskontrolle Um Funktionen in einem WMS auszuf¨ uhren, sollte aus Sicherheitsgr¨ unden immer eine Zugangskontrolle 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¨atzlich kann nach Ablauf einer gewissen Zeit, in der keine Eingaben erfolgen, der Arbeitsplatz gesperrt oder der Bediener implizit abgemeldet werden. Ein gesperrter Arbeitsplatz kann nur durch eine nochmalige erfolgreiche Zugangskontrolle des bereits angemeldeten Bedieners freigegeben werden. Alternativ oder zus¨ atzlich k¨ onnen auch die Arbeitspl¨atze, f¨ ur die eine Berechtigung besteht, eingeschr¨ ankt werden. Dann kann anstelle des rollenbezogenen Zugangs (Einlagern, Kommissionieren usw.) ein ortsbezogener Zugang – z. B. zu genau einem oder zu mehreren definierten I-Punkten oder Kommissionierpl¨ atzen – zugesichert werden. Weitere Einschr¨ankungen k¨onnen 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¨atskontrolle ist gelegentlich auch die R¨ uckverfolgung auf die beteiligten Personen erforderlich. Das Gleiche gilt f¨ ur leistungsbezogene Bezahlung. In diesen Anwendungen der Zugangskontrolle werden personenbezogene Daten erfasst und gespeichert, so dass hier in jedem Fall bei der Einf¨ uhrung solcher Systeme mindestens die gesetzlichen Anforderungen des Datenschutzes beachtet werden m¨ ussen. Eine weitergehende Beteiligung der Mitarbeiter und ihrer Vertreter ist bei solchen Vorhaben sinnvoll. 5.3.4 Internationalisierung Grunds¨ atzlich k¨ onnen die Ein- und Ausgaben bedienerabh¨angig, standortabh¨ angig oder nach einem Firmen- oder einem internationalen Standard erfolgen. Dialogtexte sollten in der jeweiligen Landessprache des Bedieners dargestellt werden k¨ onnen. Die Auswahl kann manuell oder u ¨ ber das Bedienerprofil der Zugangskontrolle erfolgen. Die Endger¨ ate m¨ ussen u ¨ ber entsprechende Zeiahigkeit verf¨ ugen, ihren Zeichensatz von einem exchens¨atze oder u ¨ ber die F¨ ternen Ger¨ at zu beziehen. Die rechnerinterne Darstellung muss hier eine Unterst¨ utzung bieten. Da die u ur einzel¨ blicherweise benutzte 8-Bit-Codierung f¨ ne Buchstaben oft nicht ausreicht, wurde der Unicode, eine 16-Bit-Codierung, zur Unterst¨ utzung der multilingualen Textbearbeitung eingef¨ uhrt. 24

beispielsweise Fingerabdruck oder Irisbild

190

5. Informations- und Kommunikationstechnik

Die Darstellung des Datums und der Uhrzeit sollte in einer unverwechselbaren Form erfolgen. Abweichend hiervon sind Darstellungen m¨oglich, die am Standort des Betreibers u uche k¨onnen in der Punkt- oder ¨ blich ist. Dezimalbr¨ ¨ Kommanotation dargestellt werden. Ublicherweise wird die standort¨ ubliche Darstellung gew¨ ahlt. Die physikalischen Gr¨ oßen – wie beispielsweise Gewicht oder Abmessungen – sollten dem internationalen Standard (MKS-System: Meter, Kilogramm, Sekunde) entsprechen. Umrechnungen zwischen unterschiedlichen Gr¨ oßen sollten im Bereich der Identifikation durch geeignete Funktionen m¨ oglich sein. Neuere Programmiersprachen unterst¨ utzen die Internationalisierung durch entsprechende Datentypen und Bibliotheken. 5.3.5 Hilfesysteme und Hilfsdienste Zur Unterst¨ utzung der Bediener existieren Handb¨ ucher, die jedoch meist nicht f¨ ur den operativen Betrieb, sondern zu Schulungszwecken genutzt werden. Zur Unterst¨ utzung k¨ onnen diese Handb¨ ucher auch online verf¨ ugbar gemacht werden (vgl. Abb. 5.16), was auch eine Suche u ¨ ber den Inhalt, u ¨ ber Stichworte und u ¨ber den gesamten Text (Volltextsuche) erm¨oglicht. Wichtiger als die Online-Handb¨ ucher ist jedoch eine kontextsensitive Hilfe, die abh¨ angig von der gerade ausgef¨ uhrten Funktion einen kurzen Hinweis geben soll. Insbesondere sind die Anzeige der m¨oglichen Eingabewerte oder Wertebereiche hilfreich. Adaptive Verfahren k¨onnen abh¨angig von der Vorgeschichte des Bedienerdialoges gezielte Hinweise geben. Adaptive Hilfesysteme werden heute kaum oder nur in einer sehr rudiment¨aren Form eingesetzt. H¨ 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¨ ache assoziiert. Ein Betriebssystem beinhaltet aber viele weitere elementare Funktionen, die einem Anwender meist verborgen bleiben. Die Kenntnis der grunds¨ atzlichen Prinzipien eines Betriebssystems ist f¨ ur das gesamte Gebiet der IT-Systeme sinnvoll. In diesem Abschnitt werden die Grundprinzipien der Betriebssysteme kurz erl¨ autert. Die darauf aufbauenden Funktionen, wie beispielsweise netzwerkf¨ ahige Dateisysteme und Bedienoberfl¨achen, 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¨ angigkeiten zwischen verschiedenen Anwenderprogrammen (Synchronisation)

192

5. Informations- und Kommunikationstechnik

• Zurverf¨ ugungstellung allgemein verwendbarer Programmbibliotheken (Bibliotheken, Libraries) • Bereitstellung eines einheitlichen Ein-/Ausgabe-Systems (virtuelles I/OSystem) • Bereitstellung einer Speicherverwaltung (virtueller Speicher ) • Schutz der Anwenderprogramme gegen Fehler in anderen Anwenderprogrammen • Unterst¨ utzung unterschiedlicher Benutzer mit 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¨ahigkeit einer CPU wird oft durch die Anzahl der ausf¨ uhrbaren Instruktionen pro Zeiteinheit und durch eine Taktrate angegeben. Derartige Kennzahlen stellen aber nur einen Parameter f¨ ur die Beurteilung der Leistungsf¨ahigkeit einer Hardware dar. Diese ergibt sich aus dem Zusammenspiel aller Komponenten und ist f¨ ur die Beurteilung aus Sicht eines Betreibers ohne Ber¨ ucksichtigung der Betriebssystemeigenschaften und der Eigenschaften der Anwenderprogramme auch nicht aussagekr¨ aftig. Statt dessen setzt man Benchmarks26 26

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

194

5. Informations- und Kommunikationstechnik

ein, um die Leistungsf¨ ahigkeit f¨ ur eine Klasse von Einsatzf¨allen zu ermitteln. • Ger¨ ate (Devices): Hierunter werden folgende Ger¨ategruppen zusammengefasst: – Schnittstellen: Beispiele sind parallele und serielle Schnittstellen wie RS232 oder USB. – Netzwerk: 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¨onnen 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¨at dar, dem eine besondere Bedeutung zukommt. Sie l¨ ost zyklische Unterbrechungen (Interrupts) aus, die das Betriebssystem veranlassen, bestimmte Aufgaben (s. Abschn. 5.4.2 Uhren) zu erf¨ ullen. Zus¨ atzlich dient die Uhr der Bestimmung des aktuellen Datums und der aktuellen Zeit. Hierzu stellen Betriebssysteme weitere Dienste, welche die Zeitzonen und ggf. die Sommerzeit ber¨ ucksichtigen, Prozesse zeitgesteuert aktivieren (Timer) und die Rechneruhren in verteilten Systemen synchronisieren (s. Abschn. 5.1.6), zur Verf¨ ugung. Die Uhrenproblematik trat zur letzten Jahrtausendwende durch das so genannte Jahr-2000-Problem“ (y2k-Problem) in das Bewusstsein einer ¨” breiten 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¨aufig 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¨aufig drucken. Um sinnvolle Ergebnisse zu erhalten, darf in einem solchen Szenario zu einer Zeit immer nur ein Prozess drucken – die Prozesse m¨ ussen sich wechselseitig ausschließen. Dieses Prinzip des wechselseitigen Ausschlusses wird dar¨ uber hinaus durchg¨ angig auf alle denkbaren exklusiven Ressourcen angewendet. Neuere Programmiersprachen bieten Sprachkonstrukte f¨ ur den Wechselseitigen Ausschluss an. • Synchronisation: Es muss sichergestellt sein, dass unter bestimmten Bedingungen ein Prozess in seiner Ausf¨ uhrung erst dann fortfahren kann, wenn er ein Signal erh¨ alt, das von einem anderen Prozess erzeugt werden muss. • Vermeidung von Deadlocks: Es muss verhindert werden, dass sich eine Menge von Prozessen bildet, von denen keiner fortfahren kann, ohne dass ein anderer aus dieser Menge fortfahren kann28 . Da die Deadlockproblematik 28

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

196

5. Informations- und Kommunikationstechnik

von grundlegender Bedeutung – nicht nur f¨ ur Betriebssysteme, sondern auch f¨ ur Datenbanken und dar¨ uber hinaus auch f¨ ur Materialflusssteuerungen – ist, wird in Abschn. 5.4.2 auf dieses Thema eingegangen. • Kommunikation: Ein Nachrichtenaustausch zwischen Prozessen, die so genannte Interprozesskommunikation, muss m¨oglich sein. Diese Kommunikation kann sich auf den Austausch von Signalen ohne eine zus¨atzliche Information beschr¨ anken oder sie kann auch Inhalte in Form von Datens¨atzen enthalten. Dar¨ uber hinaus ist auch eine datenstromorientierte Kommunikation m¨ oglich, die einen unstrukturierten Zeichenstrom zwischen den Prozessen austauscht (s. Abschn. 5.1). Jeder Prozess befindet sich zu jedem Zeitpunkt in einem der drei Zust¨ande rechnend“, rechenbereit“ oder blockiert“. Blockierte Prozesse warten auf ” ” ” Betriebsmittel, auf die Fertigstellung eines I/O-Auftrags oder auf ein TimerEreignis. Nach dem Ende der Blockade wird der Prozess in den Zustand re” chenbereit“ versetzt und bewirbt sich erneut um die CPU. Die Prozessorverwaltung regelt die Zuteilung der Prozesse an den Prozessor beziehungsweise an die Prozessoren und verwaltet dementsprechend die Prozesszust¨ande. Die blockierten Prozesse warten passiv, d.h. sie verbrauchen praktisch keine Rechenzeit. Das Betriebssystem verwaltet die Ereignisse, auf welche die blockierten Prozesse warten, und weckt“ diese nach dem Eintritt des ” Ereignisses. Das entgegengesetzte Prinzip ist das aktive Warten, bei dem ein Programm durch zyklische Abfragen einer Bedingung ein Ereignis detektiert. Dieses Prinzip wird Polling genannt und wird gelegentlich in Anwenderprogrammen verwendet, aber niemals in Betriebssystemen. Das Polling erfordert zwischen den einzelnen Abfragen immer eine Wartezeit τp , damit andere Prozesse Gelegenheit erhalten, ihr Programm weiter auszuf¨ uhren. Wird τp klein gew¨ ahlt, belastet der pollende Prozess die CPU zus¨atzlich, ohne eine Leistung oßer gew¨ ahlt, steigt die Reaktionszeit, die im Mittel zu erbringen. Wird τp gr¨ τ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

CPU

fertige Prozesse

Abbildung 5.19. Prinzip eines Round-Robin-Schedulers

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

198

5. Informations- und Kommunikationstechnik Virtueller Speicher 1

Physischer Speicher

0

0

0

~ ~ ~ ~

232-1

Virtueller Speicher 2

~ ~

227-1

~ ~

Auslagern

~ ~

Einlagern

~ ~

232-1

Auslagerungsdatei (Festplatte) Verfügbare Seite

Ausgelagerte Seite

Ungenutzte Seite

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

kenntnis ist kritisch. Die auf der einen Seite vermeintlichen Vorteile k¨onnen schwerwiegende Nachteile zur Folge haben. Speicherverwaltung Jeder Prozess verf¨ ugt u ¨ ber einen separaten virtuellen Adressraum. Dieser wird vom Betriebssystem bereitgestellt und durch unterschiedliche Verfahren auf den physischen Speicher abgebildet. Das am h¨ 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¨ onnen nach unterschiedlichen Algorithmen auf einen Hintergrundspeicher,

5.4 Betriebssysteme

199

einen Massenspeicher mit langsamerem Zugriff, aber mit wesentlich gr¨oßerer Kapazit¨ at (das ist in der Praxis eine Festplatte) kopiert (ausgelagert ) werden. Hierdurch werden Bereiche des physischen Speichers f¨ ur andere Programme nutzbar. Wenn ausgelagerte Seiten ben¨ otigt werden, spricht man von einem Seitenfehler (Pagefault), der dazu f¨ uhrt, dass die ben¨otigten Seiten wieder in den Arbeitsspeicher kopiert (eingelagert ) werden. Zuvor m¨ ussen jedoch bei Bedarf andere Seiten in den Hintergrund kopiert werden, um f¨ ur die einzulagernden Seiten Platz zu schaffen. Die entsprechenden Algorithmen sind teilweise sehr aufw¨ andig und ber¨ ucksichtigen unter anderem auch die Zugriffsh¨aufigkeit 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¨oglich, da hierzu zus¨atzlicher Speicher ben¨ otigt wird, der dann jedoch nicht mehr zur Verf¨ ugung steht. Ger¨ ate- und Ressourcenverwaltung Die Ger¨ateverwaltung beinhaltet auf unterer Ebene die zeitnahe Kommunikation mit der Hardware. Diese erfolgt u ¨ ber Interrupts, die durch die Hardware ausgel¨ost werden, den 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

5. Informations- und Kommunikationstechnik

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¨ate 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¨aufig 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¨ankt auf die Verf¨ ugbarkeit von Betriebsmitteln warten und in dem keinem Prozess von außen zwangsweise Betriebsmittel entzogen werden k¨ onnen, besteht eine potenzielle Deadlockgefahr. Ein Deadlock ist eine Systemverklemmung, die nur durch einen erzwungenen Entzug von Betriebsmitteln (Preemption) oder durch das erzwungene Beenden von Prozessen gel¨ ost werden kann. Abbildung 5.21 zeigt eine typische Deadlocksituation mit Hilfe eines Resource-Allocation-Graphen. Prozesse und Betriebsmittel bilden die Knoten eines solchen Graphen, Betriebsmittelanforderungen und -zuteilungen werden durch Kanten dargestellt. ur zwei BetriebsIm zeitlichen Ablauf wird f¨ ur zwei Prozesse (P1 , P2 ) und f¨ mittel (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

BM2 Legende:

BMi

BMi

t4+

Anforderung des BMi durch Prozessj

Zuteilung des BMi an Prozessj

Prozessj

Prozessj

Abbildung 5.21. Deadlocksituation im Resource-Allocation-Graphen

t1 t1 + Δ t2 t2 + Δ t3 t4

: : : : : :

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

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

202

5. Informations- und Kommunikationstechnik BM2

Fortschritt Prozess2

nicht erreichbare Zustände

BM1

BM1

t3

unsichere Zustände

t4

BM2

. . .t

.t

2

Deadlock

1

wechselseitiger Ausschluss verletzt

Fortschritt Prozess1

Abbildung 5.22. Deadlocksituation in einem Diagramm der Prozessfortschritte

Eine Alternative zur Deadlockvermeidung ist Anforderung aller ben¨otigten Betriebsmittel als unteilbare Operation oder die Aufl¨osung eines Deadlocks durch Preemption. Werden alle ben¨ otigten Betriebsmittel bereits bei der ersten Anforderung auch nur eines Betriebsmittels angefordert und zugeteilt, wird im Allgemeinen der Durchsatz verringert, da andere Prozesse auf diese Betriebsmittel warten m¨ ussen. Ein Deadlock kann aber mit dieser Methode verhindert werden. Nach Preemption werden die bisher auf den 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.5 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¨onnte. Falls absolute Zeiten in einem System verwendet werden, kann ein Zur¨ uckstellen der Uhr dazu f¨ uhren, dass eine Wirkung f¨ ur nicht beteiligte Prozesse scheinbar zeitlich vor ihrer Ursache liegt. Aus diesem Grund laufen Hardwareuhren bewusst geringf¨ ugig zu langsam. Ein solcher 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¨andert wurden. Falls ” w¨ ahrend der Entwicklungsarbeiten die Uhr zur¨ uckgestellt wurde, kann das zu ¨ einer nur teilweisen Ubersetzung der Programme f¨ uhren. Die Folge sind meist nicht kompatible Ergebnisse und damit gar nicht oder fehlerhaft arbeitende ¨ Programme. Ahnliche 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¨atzlich u ¨ber eine OffsetVariable zur Korrektur der Zeit. Ein Zur¨ uckstellen der Uhr kann jetzt dadurch erreicht werden, dass die Softwareuhr langsamer l¨auft, d.h. der Offset wird durch das Auslassen einzelner Ticks langsamer erh¨oht, so dass die Softwareuhr zwar langsamer, aber niemals r¨ uckw¨ arts l¨auft. Die Problematik wird in vernetzten Systemen durch den Einsatz von Uhrenprotokollen gel¨ost.

5.5 Programmiersprachen Programmiersprachen dienen zur Umsetzung der logischen Konzepte in ausf¨ uhrbare Programme. Sie stellen ein Bindeglied zwischen dem Programm P eines Programmierers und der Maschine M , auf der das Programm ausgef¨ uhrt werden soll, dar. Der 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¨onnen wiederum Eingaben f¨ ur ein anderes Programm sein. 32

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

204

5. Informations- und Kommunikationstechnik

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

5.5 Programmiersprachen

Input I

Program P

205

Output O

Code M Interpreter M

I

P

O

M M

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

Code M1

Machine M1

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

sprachen programmiert, aber einige Programmiersprachen setzen Ma¨ kros ein. Vor der eigentlichen Ubersetzung durch den Compiler erfolgt 33 ein getrennter Pass , in dem die Makros expandiert werden. Das dient einerseits der Reduzierung der Schreibarbeit, verdeckt aber andererseits Schw¨ achen der Programmiersprache (s. [51]). • Der Programmcode wird mit Hilfe eines Interpreters direkt ausgef¨ uhrt. Ein Interpreter ist ein Programm, das auf einer Wirtsmaschine ausgef¨ uhrt wird und die Anweisungen eines Anwenderprogramms interpretiert und ausf¨ uhrt (s. Abb. 5.24). In diesem Sinne stellen Interpreter virtuelle Maschinen dar, welche die Eigenschaften der Wirtsmaschine gegen¨ uber dem Anwendungsprogramm verbergen. F¨ ur die Erstellung von Anwendungsprogrammen werden Compiler und Interpreter sowohl alternativ als auch erg¨ anzend eingesetzt. Die beiden zugrunde liegenden Prinzipien haben ihre 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

5. Informations- und Kommunikationstechnik Program P

Program P Language Language L

L

Code Compiler

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¨aufig 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 Java

207

Language

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 Maschine) wahlweise auf der Zielmaschine M1 oder M2 ausgef¨ uhrt werden.

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

5. Informations- und Kommunikationstechnik

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-

5.5 Programmiersprachen

209

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

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

210

5. Informations- und Kommunikationstechnik

Elementinhalt und abschließend das Endtag, das auch wieder in spitzen Klammern mit einem f¨ uhrenden Schr¨ agstrich den Elementnamen wiederholt. Als Inhalte von Elementen k¨ onnen weitere Elemente vorkommen. Soll beispielsweise ein Lagerartikel, hier eine Dose Erbsen, durch XML beschrieben werden, dann k¨ onnte das wie folgt geschehen, wobei die Eigenschaften des Artikels durch den Starttag und den Endtag begrenzt werden:

401234500001 Erbsen 850 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:

Werden bei der Benennung der Elemente und deren Attribute mnemonische (selbsterkl¨ arende) Namen verwendet, kann mit XML eine selbstdokumentierende Art der Beschreibung von Datenstrukturen erreicht werden. Obiges Beispiel des Artikelelementes f¨ uhrt an, dass es sowohl die M¨oglichkeit der Benutzung von Subelementen als auch die der Bildung von Attributen zu Elementen gibt. Es ist auch eine Mischung dieser beiden Verfahren m¨ oglich. Dies verdeutlicht das nachfolgenden Beispiel zur Beschreibung eines Kunden. Durch die Wahl selbsterkl¨ arender Element- und Attributbenennungen muss es nicht weiter beschrieben werden :

+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¨anken. Eine solche Beschr¨ ankung ist wichtig zur Validierung dieser Dokumente. W¨ahrend die Zul¨ assigkeit (oder Wohlgeformtheit) eines XML-Dokumentes aus seinem Aufbau, also aus dem korrekten Umgang mit den Elementen, unabh¨angig von seinen Inhalten sofort ersichtlich ist, entscheidet das Schema oder die DTD u ¨ ber ¨ die G¨ ultigkeit des Dokumentes durch Uberpr¨ ufung der Existenz bestimmter und Nichtvorkommen anderer Elemente sowie die Einhaltung vorgeschriebener Verschachtelungen. Das nachfolgende Beispiel zeigt eine DTD f¨ ur das obige Beispiel des Kundenelements. Das Element kunde setzt sich dabei aus mindestens einem adresse- und beliebig vielen telefon-Elementen zusammen, wobei adresse aus einem ElementEmptyTag und telefon aus einem Start- und einem Endtag besteht:

212

5. Informations- und Kommunikationstechnik

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¨oglichkeit, die Richtigkeit einer Telefonnummer zu u ufen; der Eintrag von jeder Art von Zeichen¨ berpr¨ sequenzen als Telefonnummer w¨ are g¨ ultig. Die automatische Pr¨ ufung eingehender Dokumente auf einige Aspekte der formalen Korrektheit ist anhand von DTDs m¨oglich, aber aufw¨andig. Mit Hilfe von Schemata k¨ onnen auch Attribute und Elementinhalte einer weitergehenden Pr¨ ufung unterzogen werden. Bei Schnittstellen, die einen hohen Durchsatz an XML-Dokumenten leisten m¨ ussen, werden daher diese formalen Pr¨ ufungen m¨ oglicherweise nach einer Testphase von Hand optimiert oder auch ganz abgeschaltet. Der Gewinn gegen¨ uber propriet¨ ar vereinbarten Datenschnittstellen ist dennoch enorm. Eine XML-Schnittstelle ist u ¨ ber die DTD oder das Schema sehr schnell zwischen den Entwicklern einer Kommunikations-Schnittstelle ausgehandelt. Ist die Beschreibung einmal verabschiedet, ist die Konformit¨at einer Nachricht reproduzierbar verifizierbar. Die Schnittstellen k¨onnen einfach getestet und debugged35 werden, da die u ¨ bertragenen Inhalte lesbar sind. Vielf¨ altigkeit durch Stylesheets Das in Abschn. 5.5.3 aufgezeigte Beispiel f¨ ur kunde k¨onnte innerhalb eines neuen Elements bestellung durch das Hinzuf¨ ugen eines weiteren Ele35

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

5.5 Programmiersprachen

213

mentes orderItem in eine Bestellung u uhrt werden. Das neue Element ¨ berf¨ orderItem baut dabei auf dem in Abschn. 5.5.3 vorgestellten artikel auf und erweitert diesen um preis und anzahl. Die zugeh¨orige DTD sieht dann wie folgt aus:

kunde ... > kunde ... > orderItem EMPTY> orderItem ean CDATA #REQUIRED name CDATA #REQUIRED menge CDATA #REQUIRED einheit CDATA #REQUIRED verpackung CDATA #REQUIRED preis CDATA #REQUIRED anzahl CDATA #REQUIRED >

Mittels obiger DTD k¨ onnen nun XML-Dokumente vom Typ bestellung validiert werden. Das nachfolgende Beispiel zeigt ein wohlgeformtes und g¨ ultiges XML-Dokument zu dieser DTD:



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

214

5. Informations- und Kommunikationstechnik

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¨alliger 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¨onnen die Kommunikationsumst¨ ande ebenfalls sch¨ utzenswert sein. Die wichtigsten Aspekte sind Anonymit¨ at und Unbeobachtbarkeit der Kommunikationspartner. Das k¨onnen Personen, aber auch Rechner, Programme oder Betriebssystemprozesse sein. Die Anfertigung von 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¨onnen leicht auf andere Szenarien in verteilten Applikationen u ¨ bertragen werden. 5.6.1 Geheimhaltung ¨ Die Geheimhaltung von Nachrichten auf ihren Ubertragungswegen hat eine jahrtausendelange Tradition. In j¨ ungster Zeit wurden grundlegend neue Verfahren entwickelt, die sich auch f¨ ur hohe Sicherheitsanforderungen eignen. Sowohl die Geheimhaltung als auch die anderen Sicherheitsaspekte beruhen auf Verschl¨ usselung. Das Grundprinzip aller Verschl¨ usselungen basiert auf jeweils einem Algorithmus zur Verschl¨ usselung (Encryption) und zur Entschl¨ usselung (Decryption) unter Nutzung von Schl¨ usseln (Keys) (s. Abb. 5.29). Die Algorithmen und der Aufbau der Schl¨ ussel k¨onnen sehr unterschiedlich sein. Die Sicherheit der Verschl¨ usselung sollte aber in allen F¨allen durch die Sicherheit der Schl¨ ussel und nicht durch die der Algorithmen begr¨ undet sein. Die Nachricht M (Message) wird unter Nutzung des Schl¨ ussels K (Key) durch die Verschl¨ usselungsfunktion E 36 in die 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¨oglichst u ale – erh¨ oht die Sicherheit. ¨ ber unterschiedliche Kan¨ Die Entschl¨ usselung erfolgt u ¨ ber eine inverse Funktion E −1 , die mit Hilfe des gleichen Schl¨ ussels K die 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 ======================

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

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

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

Lieferstermin 12.Nov. 2003

Lieferstermin 12.Nov. 2003

Lieferstermin 12.Nov. 2003

Lieferstermin 12.Nov. 2003

Klartext

Geheimtext

Geheimtext

Klartext

Übertragungskanal

Abbildung 5.29. Grundprinzip der Verschl¨ usselung

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

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

5.6 Sicherheitsaspekte

217

Kd ). Der private oder geheime Schl¨ ussel Kd bleibt im alleinigen Besitz des Empf¨ angers, w¨ ahrend der ¨ 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¨ahnten Primzahlzerlegung basiert (s. [81]). Die L¨ ange des Schl¨ ussels ist unabh¨angig vom Algorithmus und bestimmt das Maß der erreichten Sicherheit. F¨ ur heute gebr¨ auchliche Schl¨ ussel mit 128 Bit L¨ ange ben¨ otigt ein leistungsf¨ahiger Rechner mehrere Monate zur Primzahlzerlegung. Umgekehrt kann das Produkt der Primfaktoren mit wenigen Multiplikationen berechnet werden. Prinzipiell ist es m¨ oglich, KE aus KD zu berechnen. Der Aufwand hierzu – insbesondere die erforderliche Zeit – w¨ achst jedoch exponentiell mit der Schl¨ ussell¨ange, so dass hinreichend lange Schl¨ ussel immer die geforderte Sicherheit geben. Die Verteilung der ¨ 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¨anger nicht durch Dritte verf¨ alscht werden. Diese Integrit¨atssicherung sch¨ utzt vor den Angriffen Dritter. Beispielsweise k¨ onnten Bestellmengen, die letztlich in einem WMS ¨ zu Auslagerungen f¨ uhren, auf dem Ubertragungsweg ge¨andert werden. Die Folge k¨ onnte die Auslieferung des gesamten Bestandes sein, der dann f¨ ur zuk¨ unftige Auftr¨ age anderer Kunden – bis zur Kl¨arung des Vorfalles und einem eventuellen R¨ ucktransport – nicht mehr verf¨ ugbar w¨are. Das Ziel der Integrit¨ atssicherung kann durch den Einsatz von Verschl¨ usselungsverfahren erreicht werden. In einem System mit symmetrischen Schl¨ us¨ seln muss der Angreifer sowohl zum Lesen als auch zum Andern der Nachricht u ussel verf¨ ugen. Beim Einsatz unsymmetrischer Ver¨ ber den geheimen Schl¨ ussel fahren muss der Angreifer u ¨ ber den geheimen und den ¨offentlichen Schl¨ des Empf¨ angers verf¨ ugen. 5.6.3 Authentifizierung Die Integrit¨ at einer Nachricht kann durch den Einsatz von Verschl¨ usselung gesichert werden. Beim Einsatz unsymmetrischer Schl¨ ussel kann Jeder mit

218

5. Informations- und Kommunikationstechnik

Hilfe des ¨ offentlichen Schl¨ ussels eine Nachricht an dessen Eigent¨ umer absetzen und sich als jemand Anderes ausgeben. Beispielsweise ist es leicht m¨oglich, Bestellungen im Namen anderer Kunden an einen Lieferanten abzusetzen. Der Lieferant muss sich aber darauf verlassen k¨onnen, dass der Absender der Bestellung mit dem in der Bestellung Angef¨ uhrten identisch ist. Dieses Problem der 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¨ ur A und jeden Teilnehmer ein unsymmetrisches Schl¨ usselpaar (KEA , KDA ) f¨ ur B genutzt. Der Sitzungsschl¨ ussel ist nach dieser Authentifi(KEB , KDB ) f¨ zierungsprozedur nur den beiden Teilnehmern bekannt, die nun ein symmetrisches Verfahren mit diesem Schl¨ ussel einsetzen. Der Vorteil liegt in den wesentlich schnelleren Algorithmen, die bei symmetrischen Verfahren eingesetzt werden. usselt diese mit dem ¨offentlichen 1. A w¨ ahlt eine Zufallszahl RA , verschl¨ 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 Zufallsussel KS mit dem zahl RA , die selbst erzeugte RB und den Sitzungsschl¨ 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 ¨offentlichen Schl¨ ussels des jeweils anderen Kommunikationspartners, insbesondere eine vertrauensw¨ urdige Zuordnung des Schl¨ ussels zum Teilnehmer, voraus. F¨ ur die Verwaltung

5.6 Sicherheitsaspekte

219

offentlicher Schl¨ ussel existieren Trustcenter, welche f¨ ur diese Vertrauensw¨ ur¨ digkeit einstehen. Eine Alternative sind logische Netzwerke, welche dezentral ein Maß f¨ ur die Vertrauensw¨ urdigkeit berechnen. Wenn A dem Kommunikationspartner B vertraut und B vertraut C, dann vertraut A auch dem Teilnehmer C, jedoch in einem etwas geringeren Maße. So kann in einem Kommunikationsnetz die Vertrauensw¨ urdigkeit der Teilnehmer dynamisch propagiert werden. 5.6.4 Echtheitsnachweis und elektronische Signatur Sowohl f¨ ur den Absender einer Nachricht als auch f¨ ur den Empf¨anger kann es wichtig sein, ihre Echtheit zu beweisen. Hier wird ebenfalls das grunds¨atzliche Prinzip eines Verfahrens, das auf unsymmetrischen Schl¨ usseln basiert, vorgestellt. Die Voraussetzung f¨ ur das hier vorgestellte Verfahren ist, das außer der oben beschriebenen Eigenschaft D(Kd , E(Ke , M )) = M das Prinzip auch mit vertauschten“ Schl¨ usseln m¨ oglich ist: ” E(Ke , D(Kd , M )) = M Mit dem privaten Schl¨ ussel codierte Nachrichten k¨onnen also mit dem 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¨angers codiert. Die chiffrierte Nachricht kann in der ersten Stufe nur vom Empf¨anger mit seinem privaten Schl¨ ussel decodiert werden. In der zweiten Stufe decodiert der Empf¨ anger nun mit dem ¨ 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¨aßige Methoden und Prinzipien zum Einsatz, um ein gegebenes Ziel zu erreichen. Die Ziele eines Warehouse Managementsystems (WMS) werden z. B. im Rahmen einer 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¨asentationen auf ganz unterschiedliche Art verwendet. W¨ ahrend Software das inh¨arente Problem hat, einem potenziellen Kunden gegen¨ uber nicht darstellbar zu sein, scheinen umgekehrt die 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¨atzlich sagt die Wahl der Softwarearchitektur nichts u ¨ber die Qualit¨at einer Software aus.

222

6. Softwareengineering

Zu vernachl¨ assigen ist die Wahl einer Architektur in Bezug auf die zu erreichenden Ziele aber nicht. Es folgt eine Auswahl typischer Kriterien, die bei der Wahl einer Softwarearchitektur ber¨ ucksichtigt werden sollten: • beteiligte Systemkomponenten (z. B. Betriebssystem, Datenbank, Massenspeicher) • benachbarte Systeme (z. B. Warenwirtschaft, Webshop, Produktionsplanung) • Leistungsf¨ ahigkeit (z. B. Speicherverbrauch, Antwortzeiten, Operationen pro Zeiteinheit) • Entwicklungsdauer und Entwicklungsaufwand • Anzahl und Kompetenzen der Entwickler und Systembetreuer • Wartungsfreundlichkeit und Betriebsaufwand • Nachvollziehbarkeit des operativen Betriebs der Software • Robustheit bei Fehlbedienung • Integrit¨ at (z. B. Qualit¨ at und Fehlerfreiheit der Daten, Algorithmen und Prozesse) • Wiederverwendbarkeit der Software • Erweiterungsf¨ ahigkeit der Software (z. B. in Bezug auf erweiterte Nutzung oder neue Prozesse und Algorithmen) Architektur-Konzepte, die im folgenden beschrieben werden, sind • monolithische Architektur, • Modularisierung der Software, • Prinzip der Schichtung, • Verteilung der Applikation. Alle hier vorgestellten Architekturkonzepte werden durch geeignete 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¨amtliche Funktionen der

6.1 Softwarearchitekturen

223

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

2

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

224

6. Softwareengineering

Systeme wiederum k¨ onnen weiter in Module unterteilt werden. So k¨onnen die einzelnen Prozesse eines Warehouse Managementsystems, wie z. B. der Wareneingang, der innerbetriebliche Transport oder die Inventur, als eigene Module angesehen werden. Bezeichnend f¨ ur ein Modul ist, dass es seine abgegrenzte betriebliche Aufgabe im Unternehmen erf¨ ullt. Technische Aufgaben wie Datenhaltung, Benutzerschnittstelle und Kommunikation sind im Modul vereint. Ein enger gefasster Modul-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¨age 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¨andert oder erweitert werden. 6.1.3 Schichtung Die Schichtung beschreibt die Einf¨ uhrung von technischen oder auch gesch¨aftlichen Ebenen (Layer) in ein Softwaresystem. Ein neuerer Terminus f¨ ur Schichtung ist auch die englische Vokabel Stack, also Stapel4 , oder in Verbindung mit der Anzahl der n Schichten innerhalb einer Applikation das n-Tier5 Modell. Die Merkmale einer Schichtung sind: • Eine Schicht kommuniziert ausschließlich mit ihren Nachbarschichten. Das ¨ Uberspringen einer Schicht ist nicht m¨ oglich. Andere als die benachbarten Schichten sind transparent, also unsichtbar. 3 4

5

ein Programm, welches z. B. unter Windows ausgef¨ uhrt wird und ein mit der Maus und der Tastatur bedienbares Fenster ¨ 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

6.1 Softwarearchitekturen

225

• Jede Schicht u ¨ bernimmt ihre Aufgabe autonom. Angrenzende Schichten ben¨ otigen keine Informationen zur Implementierung einer Schicht, um sie zu nutzen. Die Implementierung einer Schicht kann durch eine andere Implementierung ersetzt werden, ohne benachbarte Schichten ¨andern zu m¨ ussen. Die folgenden Beispiele verdeutlichen das Konzept der Schichtung: Automatisierungspyramide Speziell auf den Bereich der 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¨orderbandsegmente, 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

6. Softwareengineering

Abbildung 6.1. Automatisierungspyramide

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

z. B. 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.

6.1 Softwarearchitekturen

227

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

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

228

6. Softwareengineering

verlangsamt werden, kann auch dies erheblichen 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¨assig 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¨ahig, um die Verf¨ ugbarkeit und Performance anzupassen. 6.1.5 Konfiguration und Erweiterung Hersteller einer Branchen-Software sind bem¨ uht, ihre Software auf m¨oglichst viele Anwendungsf¨ alle abzustimmen. Das f¨ uhrt in der Praxis zum einen dazu, dass eine Software viel mehr kann, als man ihr tats¨achlich abverlangt. Auf der anderen Seite ist vielleicht genau die Funktion, die vom Anwender ben¨otigt wird, in der Software nicht implementiert. Eine u ¨bliche Vorgehensweise der Softwarehersteller ist es, neue Funktionen in die Software zu integrieren und diese Funktionen abschaltbar zu gestalten. Beispielsweise k¨ onnen in einem Warehouse Managementsystem mehrere M¨ oglichkeiten zur Generierung einer neuen Artikelnummer implementiert 12

siehe dazu auch Kapitel 6.5

6.2 Grundz¨ uge der objektorientierten Programmierung

229

sein. Die Software wird in einem konkreten Einsatz dann aber so konfiguriert, dass nur eine dieser M¨ oglichkeiten nutzbar ist. Variantenvielfalt und Konfigurationspotenzial sind zun¨achst ein Vorteil: Der Anwender hat bei der Installation und m¨ oglicherweise auch bei sp¨ateren ¨ Anderungen im Betriebsablauf die M¨ oglichkeit, das Verhalten der Software anzupassen. Konfigurationspotenzial ist aber genau dann irrelevant, wenn die verschiedenen Varianten nicht tats¨ achlich ben¨otigt werden. Im Gegenteil erh¨ oht Variantenvielfalt immer auch die Komplexit¨at und damit die Fehleranf¨ alligkeit einer Software. In verschiedenen Branchen und bei unterschiedlichen Anbietern existieren verschiedene Ansichten und Erfahrungen dar¨ uber, wie weit der Standardisierungsgrad13 einer Software u ¨ berhaupt getrieben werden kann. Grunds¨atzlich gilt: Je komplexer eine logistische Unternehmung ist, desto h¨oher ist der Aufwand f¨ ur individuelle Entwicklungen im Softwareprojekt. Weitere Hinweise und ein Vorgehensmodell zur Einf¨ uhrung und 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¨ate beschrieben, die in der Lage sind, Ladeeinheiten von einem Ort zu einem anderen zu transportieren. Diese Darstellung erfolgt sowohl mit den Symbolen der UML (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

6. Softwareengineering

• 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¨onnen 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¨achst ” sehr aufw¨ andig. Die Vorteile werden jedoch offensichtlich, wenn bei sp¨ateren Softwareerweiterungen bei jedem Variablenzugriff zus¨atzlich weitere Variablen ge¨ andert oder weitere Funktionen aufgerufen werden m¨ ussen. Eine Erweiterung braucht dann nur in der entsprechenden Funktion nachger¨ ustet zu werden, w¨ ahrend die Schnittstelle zum aufrufenden Programm gleich bleibt. Der Programmierer ben¨ otigt f¨ ur die Nutzung der Funktion lediglich einen m¨ oglichst selbsterkl¨ arenden Namen; die Details bleiben ihm verborgen. Beispielsweise kann bei einem bestehenden WMS nachtr¨aglich die Forderung gestellt werden, die Zeitdauer, w¨ ahrend der ein Lagerfach gesperrt war, in einem Betriebsprotokoll aufzuzeichnen. Eine direkte Programmierung ¨ k¨ onnte in der Programmiersprache Java vor der Anderung wie folgt aussehen15 : ... // Auswahl eines Lagerfachs fach ... // Das ausgewaehlte Fach wird als gesperrt gekennzeichnet fach.locked = true; ...

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

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

6.2 Grundz¨ uge der objektorientierten Programmierung

231

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

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

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

232

6. Softwareengineering

Die bis hier beschriebenen Prinzipien stellen nicht sicher, dass alle Attribute auch immer initialisiert sind. Hier bietet die objektbasierte Technik spezielle Funktionen, die Konstruktoren. In den meisten Programmiersprachen m¨ ussen Konstruktoren den Namen ihrer Klasse tragen. Jede Klasse muss mindestens einen Konstruktor enthalten17 . Bei Bedarf k¨onnen auch mehrere Konstruktoren 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.

6.2 Grundz¨ uge der objektorientierten Programmierung

233

Eine neue Instanz eines Regalbedienger¨ ates kann auf drei unterschiedliche Arten erzeugt werden: • RBG rbg1 = new RBG() f¨ ur ein neues Regalbedienger¨at. Das neu erzeugte Objekt der Klasse RBG heißt rbg1 und wird mit der Standardinitialisierung, der Ruheposition (1,1), erzeugt; • RBG rbg1 = new RBG(2, 3) f¨ ur ein neues Regalbedienger¨at mit der aktuellen Position (2,3); • RBG rbg1 = new RBG("E2T3") f¨ ur ein neues Regalbedienger¨at mit der aktuellen Position, welche durch die Zeichenkette E2T3 beschrieben wird. Das Gegenst¨ uck zum Konstruktor ist der Destruktor, der von dem Objekt belegte Ressourcen wieder freigeben soll. Zum Schluss gibt der Destruktor den von dem entsprechenden Objekt belegten Speicherplatz wieder frei19 . 6.2.3 Vererbung Die Analyse der durch Software abzubildenden Objekte zeigt gelegentlich, dass diese, unabh¨ angig von einer detaillierten Betrachtung, u ¨ ber gemeinsame Funktionen oder Attribute verf¨ ugen. Beispielsweise kann ein F¨orderger¨at“ ” Ladeeinheiten von einem Lagerort zu einem anderen transportieren. Dieses Verhalten ist durch unterschiedliche technische Auspr¨agungen, die oft u ¨ ber weitere, zus¨ atzliche Eigenschaften verf¨ ugen, zu erreichen. Die Grundidee der Objektorientierung erweitert das oben beschriebene objektbasierte Konzept um das Prinzip der Spezialisierung von Klassen. Eine Klasse, die Methoden und Attribute bereitstellt, kann durch Ableitung spezialisiert werden. Die allgemeinere Klasse wird als Basisklasse, die spezialisierten Klassen als abgeleitete Klassen bezeichnet. Dieses Prinzip wird auch Vererbung genannt, da die abgeleiteten Klassen die Attribute und Methoden ihrer Basisklasse erben“. ” Das Prinzip der Vererbung ist in Abb. 6.2 am Beispiel der Basisklasse Transportgeraet f¨ ur alle Transportger¨ ate und je einer Ableitung f¨ ur Regalbedienger¨ ate und f¨ ur Verschiebewagen gezeigt. Beide abgeleiteten Klassen sind instanziierbar, w¨ ahrend in diesem Fall aus der Basisklasse keine Objekte erzeugt werden k¨ onnen. Die Basisklasse stellt lediglich einige Attribute bereit und deklariert einige Methoden, stellt also eine 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¨onnen weitere Attribute und Methoden besitzen, die nicht in der Basisklasse deklariert wurden. Solche Methoden k¨ onnen nicht u ¨ber die Schnittstelle der Basisklasse aufgerufen werden, da sie dort unbekannt sind20 . Ein Beispiel ist ein kurveng¨ angiges RBG (erm¨ oglicht das Umsetzen des RBG in verschiedene Gassen), das mit Hilfe der Methode changeAisle() die Gasse wechseln kann. Das Prinzip der Ableitung kann mehrfach eingesetzt werden, so dass aus einer Basisklasse ein ganzer Baum weiterer Klassen abgeleitet werden kann. So k¨ onnte die Klasse RBG durch weitere Ableitungen spezialisiert werden.

20

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

6.3 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¨onnen in einer Kindklasse u uberladen werden. Ein instanziiertes ¨berschrieben oder ¨ Objekt ersetzt dann Methoden der Oberklassen durch die eigene. Polymorphie Gleichnamige Methoden k¨ onnen mit verschiedenen Parametern implementiert werden. Beispielsweise k¨onnten neben der Methode cmttaddMehrwertSteuer() auch noch die Methode cmttaddMehrwertSteuer(double prozentsatz) und die Methode cmttaddMehrwertSteuer(int prozentpunkte) implementiert werden. Je nach aufgerufener Methode wird dann die entsprechende Mehrwertsteuer aufgeschlagen: die gerade g¨ ultige oder die jeweils angegebene. Assoziation, Aggregation und Komposition Objekte k¨onnen sich gegenseitig referenzieren u ¨ber die Assoziation oder deren Zusammensetzung ausdr¨ ucken u ¨ ber die Aggregation. Eine Aggregation beschreibt die Teile des Ganzen21 . Die Komposition unterscheidet sich von der Aggregation darin, dass sie in h¨ ochstens einem referenzierten Element vorkommt. Die Assoziation beschreibt die Abh¨ angigkeiten der Klassen untereinander22 . Oft wird objektorientierte Programmierung damit beworben, dass sie der realen Welt sehr a ¨hnlich sei. In technischen Systemen wird sie allerdings insbesondere als Methode zur Beherrschung der Komplexit¨at von Systemen verwendet. Diejenigen Objekte (Entities), welche realweltliche Dinge oder Vorg¨ ange abbilden, werden dagegen seltener u ¨ ber ihre objektorientierte Hierarchie 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

6. Softwareengineering

Diagrammtypen bereit, die unterschiedliche Aspekte eines Softwaresystems abbilden. Die Diagramme k¨ onnen prinzipiell mit jedem beliebigen Hilfsmittel erzeugt werden. Es ist v¨ ollig legitim, ein Diagramm mit Bleistift auf Papier zu bringen oder es mit einem 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¨achlich 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¨achst oft wegen der Ersparnis an Formalit¨ aten gern in Kauf genommen, f¨ uhrt dann bei den ¨ folgenden Anderungen zu zunehmendem Kontrollverlust. ¨ Einige UML-Werkzeuge bieten unter anderem die M¨oglichkeit, Anderungen in zwei Richtungen zu propagieren: ¨ ¨ 1. Anderungen am UML-Modell f¨ uhren zu Anderungen im Softwaresystem. ¨ ¨ 2. Anderungen am Softwaresystem f¨ uhren zu Anderungen im UML-Modell. Am erfolgreichsten wird diese Technik bislang bei Klassendiagrammen eingesetzt. Dazu existieren Werkzeuge, die bestehende Klassen analysieren und ¨ als UML-Klassendiagramm abbilden k¨ onnen, genauso wie sie die Anderungen der Klassen im UML-Diagramm in die Implementierung u ¨ bernehmen k¨onnen. Bei Projekten, deren zu entwickelndes Softwaresystem u ¨ber mehrere Jahre angewendet werden soll, ist davon auszugehen, dass im Laufe der ¨ Zeit Anderungen und Erg¨ anzungen am Softwaresystem durchgef¨ uhrt werden m¨ ussen. Der Aufwand durch Erstellung und 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¨andig 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¨ahrt.

6.3 Unified Modeling Language (UML)

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¨onnen. Folgende Punkte sollten bei der Verwendung von UML Diagrammen jedoch beachtet werden: • Die Diagramme m¨ ussen von den entscheidenden Projektbeteiligten akzeptiert werden. • Der Formalismus sollte in akzeptablen Grenzen gehalten werden. Der Diagramm- und Formenreichtum der Symbole der UML dient dazu, eine angemessene Auswahl zu 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¨aufig 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¨alle (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

6. Softwareengineering

WE-Mitarbeiter

Disponent Wareneingang avisieren Waren identifizieren

Wareneingangsstatus abrufen Einlagerung auslösen

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

Kommentar zum Klassendiagramm Interface AbstrakteKlasse KlasseC

KlasseA

KlasseB

0..*

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

KlasseD

Kommentar zu einem Element des Klassendiagramms

Abbildung 6.4. Das Diagramm zeigt typische Elemente eines Klassendiagramms.

Klassenarchitekturen zu veranschaulichen. Sie stellen also die Datenstruk¨ turen eines Softwaresystems dar. Ublicherweise 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¨arenden Namen tragen und ihre Attribute25 und Methoden26 ausweisen. Die objektorientier23 24 25 26

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

6.3 Unified Modeling Language (UML)

239

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

Ereignis A

Ereignis A Zustand 2

Bedingung xy erfüllt

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

6. Softwareengineering

ten Startzustand k¨ onnen Ereignisse eintreten, die einen Wechsel nach einem anderen Zustand erm¨ oglichen. S¨ amtliche erwartete Ereignisse werden mit jeweils einer Transition im Zustandsdiagramm repr¨asentiert. Mehrere Transitionen im Diagramm d¨ urfen dieselben Ereignisse repr¨asentieren, sofern sie von verschiedenen Zust¨ anden ausgehen. Dadurch kann je nach aktuellem Zustand ein und dasselbe Ereignis zu unterschiedlichen Folgezust¨anden f¨ uhren. Nicht definierte, beziehungsweise unerwartete Ereignisse f¨ uhren nicht zu einem Wechsel des Zustandes. Auf Transitionen k¨onnen 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 ¨andert 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¨ageraustausch-Verfahren realisiert die Auftragsertei¨ lung (Uberweisungen, Einz¨ uge etc.) an Kreditinstitute. EDIFACT Electronic Data Interchange for Administration Commerce and Transport ist ein globaler Standard, der auf die Initiative der UNO zur¨ uckzuf¨ uhren ist. Mit EDIFACT soll die beleglose Gesch¨aftsabwicklung zwischen Unternehmen gew¨ ahrleistet werden. EDIFACT wurde als ISO 9735 von der International Organization for Standardization registriert. BMEcat Das BMEcat-Format realisiert den Austausch von Katalogdaten. Es wurde auf Initiative des Bundesverband Materialwirtschaft, Einkauf und Logistik e. V. (BME) ins Leben gerufen und basiert auf XML. Die genannten Formate 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

6. Softwareengineering

Formate ist allerdings auch eine gewisse Interpretationsfreiheit bei der Implementierung. So enth¨ alt beispielsweise das EDIFACT-Format etwa 200 verschiedene Nachrichtenarten und viele 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¨alschen und/oder Mitlesen durch Dritte. F¨ ur jeden einzelnen dieser Aspekte k¨onnen 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¨ates implementiert ist, aufw¨ andiger w¨ are als die individuelle Unterst¨ utzung der Schnittstelle im eigenen IT-System. 6.4.2 Kommunikationsmechanismen Dateiaustausch Es werden Dateiformate wie z. B. XML-Formate vereinbart, die auf vereinbarten Orten im Dateisystem hinterlegt werden. Der Empf¨anger sieht zu regelm¨ aßigen Zeitpunkten am vereinbarten Ort nach und liest die dort hinterlegten Daten ein. Der Dateitransfer erfolgt typischerweise u ¨ ber ein Rechnernetz. Socket-Kommunikation Es werden individuelle Telegramme vereinbart, die an den Kommunikationspartner u ¨ bermittelt werden. Bei dieser Art der Kommunikation gibt es immer einen technischen Server, der auf einen oder mehr Clients wartet, sowie den technischen Client, der die Verbindung zum Server initiieren muss. Ist die Verbindung zur Gegenstelle erst einmal hergestellt, k¨onnen Informationen in beide Richtungen zwischen den Kommunikationspartnern ausgetauscht werden. Der technische Client-Server-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¨andige und reihen¨ folgerichtige Ubertragung der Daten zugesichert. St¨orungen in der Kommunikation k¨ onnen von den Kommunikationspartnern aufgedeckt und behandelt 32

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

244

6. Softwareengineering

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

6.5 Application-Server (Java EE)

245

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

6.5 Application-Server (Java EE) Als Application-Server werden ganz allgemein Server bezeichnet, auf denen Anwendungen (Applications) abgearbeitet werden. Application-Server stellen dazu eine standardisierte Laufzeitumgebung zur Verf¨ ugung, die sich die darauf laufenden Anwendungen teilen. Der Schwerpunkt soll hier auf Java EE liegen, auch als J2EE bezeichnet. Eine Einf¨ uhrung in Java EE ist in [52] zu 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¨oglich. Java wird unter anderem von den folgenden Plattformen unterst¨ utzt: • • • • •

Microsoft Windows Linux z/Linux Solaris MacOS X

Die Implementierung von Anwendungen f¨ ur Application-Server impliziert eine Reihe von Konventionen und Entwurfsmustern. Damit verbunden ist ein hoher Einarbeitungsaufwand. Andererseits gew¨ahrleisten die Konventionen und Muster aber gute Wartbarkeit, Skalierbarkeit und Flexibilit¨at. Application-Server werden durch Schichtenmodelle realisiert. Die Schich¨ ten einer Application-Server-Anwendung werden auch Tiers genannt. Ublich sind mindestens drei Tiers: 1. Pr¨ asentation 2. Gesch¨ aftslogik 3. 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

6. Softwareengineering

Mobiles Datenterminal

Desktop PC

Webbrowser

WMS-Host

LeitstandAnwendung

WMS

Application Server Webapplikation TransportProzess

WareneingangsProzess

...

WareneingangBean

TopologieBean

ArtikelstammBean

LagerfachService

ArtikelstammService

...

Geschäftslogik TransportBean

...

Datenbeschaffung AuftragService

Relationale Datenbank

Abbildung 6.6. Eine exemplarische Application-Server-Anwendung.

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

6.5 Application-Server (Java EE)

247

Gew¨ ohnlich besitzen relationale Datenbanksysteme ein ausgefeiltes Rechtemanagement. Darin k¨ onnen Rollen 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¨amtliche Operationen mit diesem einen Account, aber m¨oglicherweise mit mehreren Verbindungen gleichzeitig durchf¨ uhrt. Dies ist f¨ ur die im Application-Server eingesetzten Optimierungen (Connection-Pooling und Caching) sogar dringend erw¨ unscht. Die 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 am Prozess f¨ uhren schnell zu einer Anderung an der

248

6. Softwareengineering

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

6.5 Application-Server (Java EE)

249

• Die Anzahl der User Interfaces ist in der Regel gr¨oßer oder gleich der Anzahl der Gesch¨ aftslogiken, die von den User Interfaces genutzt werden. Die einmalige Implementierung an zentraler Stelle erfordert weniger Aufwand. • Authentifizierung von Benutzern ist Gesch¨ aftslogik und sie ist gesch¨aftsrelevant, also sensibel. • Sp¨ atestens, wenn das User Interface nicht mehr im Application-Server ausgef¨ uhrt wird, was auch mit Web-Applikationen m¨oglich ist, w¨ urde eine 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¨atigt werden m¨ ussen, desto mehr Zeit geht durch verteilte Aufrufe verloren. In der Praxis f¨ uhrt das dazu, dass die so genannten Transfer-Objekte eingef¨ uhrt werden, die alle ben¨ otigten Informationen eines entfernten Methodenaufrufs kapseln. Es werden vorzugsweise elementare Datentypen u ¨ bermittelt, da diese am schnellsten zu u bermitteln sind. Zudem werden die Methoden ¨ so ausgelegt, dass m¨ oglichst pro Prozess-Schritt im Benutzerinterface nur ein Methodenaufruf notwendig ist, der alle relevanten zu u ¨bermittelnden Parameter sammelt. 36 37 38 39

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

250

6. Softwareengineering

Oft geh¨ ort ist der Wunsch nach generischen Schnittstellen, die eine Vielzahl von m¨ oglichen Prozessen am Benutzerinterface abdecken k¨onnen. Der Aufwand, einen ge¨ anderten Prozess abzubilden, soll m¨oglichst gering gehalten werden. Generische Schnittstellen sind aber definitionsgem¨aß 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¨at, 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¨onnen hoch performante Applikationen entwickelt werden. Dabei ist der Aufwand bei ¨ Anderungen f¨ ur eingearbeitete Entwickler u ¨ berschaubar und selbst h¨aufige 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 a ¨ndernde Anforderungen an die Gesch¨aftsprozesse eines Unternehmens zu reagieren. Durch den Einsatz von SOA wird ein Unternehmen also agiler. Eine SOA besitzt die folgenden Eigenschaften [12]: Lose Kopplung Aufrufende und aufgerufene Beteiligte sind weitestgehend voneinander entkoppelt. Damit kann ein Beteiligter durch einen anderen ¨ ersetzt werden, ohne dass Anderungen an dem oder den anderen Beteiligten notwendig sind. Aufrufe sind m¨ oglich, ohne die zugrunde liegende Implementierung eines Services zu kennen. Die lose Kopplung leistet damit einen erheblichen Beitrag zur Abstraktion. Kontrakt Services und deren Benutzer sind an die jeweilige 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¨arer Zweck in der Komponierbarkeit und der Wiederverwendbarkeit liegt und die damit andere Services st¨ utzen. Zustandsfreiheit Services minimieren zustandsbehaftete Operationen42 . Im Idealfall reicht eine Botschaft an einen Service aus, um die jeweilige Operation vollst¨ andig auszuf¨ uhren. Zustandsfreiheit tr¨agt dazu bei, die Abh¨ angigkeiten einer Software klein zu halten, und leistet einen Beitrag zur Robustheit einer Software. Auffindbarkeit Services sind selbstbeschreibend, so dass sie u ¨ber Suchmechanismen gefunden und dann genutzt werden k¨onnen. Dieser Aspekt wird durch den Service-Kontrakt erm¨ oglicht und f¨ordert damit die Wiederverwendbarkeit. 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

6. Softwareengineering

Die Beteiligten (Aufrufer und Aufrufender) k¨onnen an verschiedenen ¨ Standorten oder in verschiedenen Softwareprozessen betrieben werden. Ublicherweise, aber nicht notwendigerweise ist ein Netzwerk beteiligt, u ¨ ber welches eine Verbindung hergestellt wird. Services k¨ onnen als weitere Entwicklungsstufe klassischer Komponenten gesehen werden: Auch diese haben ein per Kontrakt festgeschriebenes Inter¨ face und sie k¨ onnen ohne Anderung per Komposition zu neuen Komponenten zusammengefasst werden. Zur Implementierung einer SOA kommen unter anderem folgende Technologien in Frage: RPC Die Abk¨ urzung RPC steht f¨ ur Remote Procedure Call. Funktionen und Prozeduren werden konventionell in einem Server implementiert und im Rahmen eines Server-Prozesses gestartet. Ein entferntes Programm kann diese Funktionen dann u ¨ ber das Netzwerk aufrufen. XML-RPC Es handelt sich um eine Variante, entfernte Funktionen und Prozeduren aufzurufen. Die Daten werden dabei in Form von XMLBotschaften ausgetauscht. XML-RPC kann als ein Vorl¨aufer zum SOAP (siehe unten) betrachtet werden. CORBA Die Abk¨ urzung CORBA steht f¨ ur Common Objekt Request Broker Architecture und stellt die objektorientierte Erweiterung von RPC dar. Es werden nicht einzelne Funktionen f¨ ur den Fernzugriff exponiert, sondern ganze Serverobjekte mit ihren Methoden stehen f¨ ur entfernte Prozesse zur Verf¨ ugung. CORBA ist plattformunabh¨angig und in vielen objektorientierten Programmiersprachen verf¨ ugbar. RMI Die Abk¨ urzung RMI steht f¨ ur Remote Method Invocation. RMI ist wie CORBA eine objektorientierte Variante f¨ ur den 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¨angig. Die Kopplung anderer Programmiersprachen ist allerdings nicht Ziel von RMI [53]. unglich steht die Abk¨ urzung SOAP f¨ ur Simple Object Access SOAP Urspr¨ 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¨ohten 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¨ohere 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¨angenden, aktuellen Aufgaben in der SOA-Welt realisiert werden. Sollen beispielsweise LegacyAnwendungen46 an neuere Applikationen angeschlossen werden, bietet es sich an, SOA-Adapter (engl. Wrapper ) zu den alten Legacy-Applikationen zu 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

6. Softwareengineering

gegen¨ uber einer konventionellen Realisierung. Gesteigerte Anforderungen an die Infrastruktur k¨ onnen iterativ kompensiert werden. Fr¨ uher oder sp¨ ater wird es notwendig sein, die 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¨ane, was den Aufbau der Kataloge und den Ausbau der Dienste angeht.

7. Datenmodell eines WMS am Beispiel myWMS

Es existiert eine Vielzahl unterschiedlicher Warehouse Managementsysteme. 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 vielen weiteren Punkten und 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¨angig 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-Source-Projekt und kann z.B. f¨ ur Forschung und Lehre kostenfrei verwendet werden. Eine entsprechende CD mit weiteren Informationen, Quelltexten und einer Beispielapplikation liegt diesem Buch bei. 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 1 2

Fraunhofer-Institut f¨ ur Materialfluss und Logistik, Dortmund siehe hierzu http://www.mywms.org

256

7. Datenmodell eines WMS am Beispiel myWMS

klassische Ansatz zur Realisierung eines WMS aufgezeigt. Nachfolgend werden die elementaren Strukturen von myWMS vorgestellt, und abschließend wird an einem Beispiel der praktische Einsatz von myWMS demonstriert.

7.1 Datenmodell Die Grundlage eines jeden WMS ist ein Datenmodell, das die Basis der Verwaltung der vielf¨ altig auftretenden Datenbest¨ande und Datenstr¨ome im Betrieb eines Lagers darstellt. Ein Datenmodell bildet die f¨ ur eine Anwendung relevanten Teile der Realit¨ at in softwaretechnische Strukturen (Datenstrukturen) ab. Der erste Schritt der Modellierung ist die Analyse der f¨ ur ein WMS relevanten Daten, ihrer Strukturen und ihre formale Beschreibung. In einem nachfolgenden Schritt m¨ ussen die Beziehungen der Daten zueinander analysiert und spezifiziert werden. Datencontainer des Modells Die nummerierten K¨astchen der Abb. 7.1 stellen die Datencontainer, im Folgenden Container (Datenhalter) genannt, f¨ ur die Daten eines WMS dar. Ein Container nimmt gleich strukturierte und logisch zusammenh¨ angende Daten auf. Die 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¨asentierenden 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¨achst, dass die Container in dem Modell vorhanden und deren Bedeutungen eindeutig definiert sind und sie Teile der Realit¨ at darstellen. • 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 Wahl der Nummerierungen f¨ ur die drei ersten Container ist mit 1a, 1b und 1c gew¨ ahlt worden. Da es vorstellbar ist, dass ein Lieferant auch Kunde oder ein Hersteller auch Lieferant (und umgekehrt) sein kann, w¨are hier zur Vermeidung redundanter Datenhaltung eine Zusammenlegung der Container 1a, 1b und 1c zu einem Container empfehlenswert, der eine juristische Person repr¨ asentiert. Die Kenntnis u ur ein WMS nicht rele¨ ber diese Personen ist f¨ vant und daher, genau so wie der Container f¨ ur die Warengruppe, in Abb. 7.1 außerhalb der gestrichelten Linie gezeichnet.

7.1 Datenmodell 1c

1a Lieferant 1

257

1

Kunde

1b m

m

Hersteller

1

Warenwirtschaftssystem 1

1

2 Warengruppe m

3

m

m supply (WEAnforderung)

n n

4

n

m

itemData (Artikelstamm)

Personalverwaltung

1 m

m

6

stockUnit (Artikel)

9

n n

m

order (WAAnforderung)

m

Beispiel WMS

m m

n

7 stockUnitCategory (Artikelgruppe)

m

8

5

n m

1

unitLoad (Ladehilfsmittel)

worker (Arbeiter)

1

1

loadHandler (Maschine) 1

m

n

m

Mandantenverwaltung

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.

Im Folgenden werden die f¨ ur das WMS relevanten Datenhalter beschrieben, die auch von externen Systemen (z. B. Personalverwaltung, Qualit¨atssicherung 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, 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 Licht- und Temperaturbereich, Anzahl Bereitstelleinheiten pro Palette oder Gefahrgutklasse und Gewichtsangaben (vgl. Abschn. 2.4).

258

7. Datenmodell eines WMS am Beispiel myWMS

• WAAnforderung (Order ): Container 5 enth¨alt eingehende Bestellungen (Kundenauftr¨ age) und ist analog zu dem Container f¨ ur Supply zu verstehen. Lediglich die Lieferanten- und die Kundenseite sind vertauscht. • Arbeiter (worker ): Hier werden Daten u ¨ber Lagermitarbeiter aufgenommen, beispielsweise von Kommissionierern. Insbesondere sind f¨ ur den Betrieb des Lagers Informationen u ¨ ber die Berechtigungen und F¨ahigkeiten der Mitarbeiter f¨ ur den Umgang und die F¨ uhrung von Maschinen - zum Beispiel Gabelstaplern - erforderlich. ¨ • Lagerplatzgruppe (LocationCategory): Uber den Container 12 lassen sich Lagerpl¨ atze gruppieren. Hierdurch k¨ onnen Lagerpl¨atze einer Zone oder Lagergruppe zugeordnet sowie nach anderen Kriterien klassifiziert werden. • Transportauftrag (OrderChain): Der Container 13 h¨alt Daten u ¨ ber die einzelnen Bewegungen der Ladehilfsmittel zwischen Lagerpl¨atzen. Er kann als eine Art Mitschrift verstanden werden. Die letzte Gruppe von Containern ist nur innerhalb des WMS relevant. Es gelten die gleichen Namenskonventionen wie bei den oben beschriebenen Schnittstellencontainern. • Bereitstelleinheit (StockUnit ): Im Container 6 werden die Daten zu den Artikeln gehalten, auf deren Metadaten u ¨ ber Container 4 (ItemData) 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. • Artikelgruppe (StockUnitCategory): Hier k¨onnen 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¨onnen. Ein Ladehilfsmittel kann gemischt oder artikelrein belegt sein. • Maschine (LoadHandler ): Die Maschine dient zur Durchf¨ uhrung der physischen Transporte und muss zu diesem Zweck tempor¨ar Ladeeinheiten aufnehmen. Kurzfristig dient eine Maschine damit als Lagerplatz“. ” • Lagerplatz (Location): Im Container 11 werden die Lagerpl¨atze erfasst. Ein Lagerplatz kann belegt oder frei sein. Zus¨atzlich kann, wie bei allen anderen Containern auch, ein Sperrkennzeichen vergeben werden. Die bisher vorgestellten Container beschreiben die Daten eines typischen Lagers. Dieses Modell kann durch zus¨ atzliche Container erweitert werden. So w¨ are beispielsweise ein Container f¨ ur die Gruppierung der Ladehilfsmittel denkbar, um verschiedene Ladehilfsmittel mit partiell gleichen Eigenschaften

7.1 Datenmodell

259

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¨oglich, deren Vielfachheit durch Zahlen oder Buchstaben am Ende der Verbindungslinie gekennzeichnet sind: • Eine 0 bedeutet, dass keine Beziehung in diese Richtung besteht. Zur Vereinfachung der Darstellung einer Beziehung muss eine 0 nicht dargestellt werden. Beziehungen, die auf beiden Seiten mit 0 beschrieben sind, werden leere Beziehungen genannt, haben keinen Informationsgehalt und werden auch nicht gezeichnet. • Die 1 auf einer Seite einer Beziehungslinie stellt dar, dass auf dieser Seite genau ein Element des Containers dem Container auf der anderen Seite der Linie zugeordnet ist. So hat beispielsweise eine Telefonnummer eine Beziehung zu genau einer juristischen Person (Kunde, Hersteller oder Lieferant). • Steht ein n auf einer Seite einer Beziehungslinie, dann existieren zu dieser Seite bis zu maximal n Beziehungen. So kann beispielsweise eine juristische Person u usse verf¨ ugen, dieses impliziert ¨ ber mehrere Telefonanschl¨ allerdings auch, dass kein Telefonanschluss vorhanden sein kann. Im Falle einer in beiden Richtungen mehrfachen Beziehung wird eine Seite mit n und die andere Seite mit m beschriftet, um anzudeuten, dass die m Vielfachheit unterschiedlich sein kann. So k¨ onnte zum Beispiel eine n Relation zwischen dem Hersteller- und dem Lieferanten-Container aufgezeigt werden, wenn diese relevant w¨ are. Diese Relation k¨onnte zeigen, dass sich ein Hersteller der Leistung von n Lieferanten bedient, ein Lieferant dagegen die m -Beziehungslinie entspricht Produkte von m Herstellern f¨ uhrt. Eine n 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 6 ) Lieferung: Diese Relation beschreibt die Lieferung von • ( 1a 1 Artikeln, wobei ein Lieferant mehrere Artikel (n ≥ 0) liefert, ein Artikel aber genau einer Lieferung eines Lieferanten angeh¨ort. Das Datenmodell

260

•

• • •

• •

•

•

• • •

7. Datenmodell eines WMS am Beispiel myWMS

allein ist nicht in der Lage, sinnvolle Verkn¨ upfungen von unsinnigen zu unterscheiden. So erlaubt diese Relation beispielsweise leere Lieferungen, also auch solche, die keine Artikel enthalten. Die u ¨ bergeordnete Logik hat sicherzustellen, dass eine Lieferung mindestens einen Artikel enth¨alt. n ¨ 3 ) Bestellung (oder Avis): Uber diese Relation wird ( 1a 1 eine Bestellung (oder ein Avis) abgebildet. Dabei ist eine Bestellung (ein Avis) genau einem Lieferanten zugeordnet, w¨ahrend ein Lieferant mehreren Bestellungen (Avisen) zugeordnet sein kann. n 4 ) Katalog: Der Katalog eines Lieferanten beinhaltet ( 1a m 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 4 ) Kaufverhalten: Das Kaufverhalten des Kunden kann ( 1c m 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 5 ) Bestellung: Ein Kunde kann im Laufe der Zeit ver( 1c 1 schiedene Bestellungen absetzen, aber eine Bestellung ist immer genau einem Kunden zugeordnet. n 6 ) Seriennummernverfolgung: Diese Relation erlaubt ( 1c 1 ¨ 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 4 ) Warengruppenzugeh¨ origkeit: Die Relation Waren(2 m gruppenzugeh¨ origkeit fasst die Metadaten von Artikeln mit gleichen Eigenschaften zusammen. Diese Verkn¨ upfung ist eher im Bereich der Shopoder Warenwirtschaftssysteme von u ¨bergeordnetem Interesse. n 4 ) Einlagerauftrag: Eine Lieferung f¨ uhrt zu einem Ein(3 m lagerauftrag, 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 ) Zusammenlagerungsverbot: Da verschiedene Ar( 4 m tikel nicht miteinander gelagert werden d¨ urfen (vgl. Kapitel 2), ist diese Relation erforderlich. n 5 ) Auslagerauftrag: Jeder Kundenauftrag ist mit ei( 4 m ner Menge von Artikeln assoziiert, die durch diese Relation mit den zugeh¨ origen Metadaten beschrieben wird. n 7 ) Artikelgruppenzugeh¨ origkeit: Ein Artikel kann ( 6 m mehreren Gruppen angeh¨ oren und jede Gruppe eine Vielzahl von Artikeln beinhalten.

7.1 Datenmodell

261

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 stehen3 , jedoch kann dieses mehrere Artikel aufnehmen. 0 13 ) Arbeitsauftrag, • (8 1 1 0 • (9 13 ) Transportobjekt, 0 13 ) Transportmedium, • ( 10 1 0 • ( 11 1 13 ) Transportquelle, 0 • ( 11 1 13 ) Transportziel: Diese Relationen gehen alle von einem Transportauftrag aus und sind einseitig. Die Relation Arbeitsauftrag ordnet dem Transportauftrag genau eine Person Arbeiter zu, beispielsweise einen Staplerfahrer f¨ ur einen Fahrauftrag oder einen Kommissionierer f¨ ur einen Kommissionierauftrag. Innerhalb eines vollautomatischen Lagers wird u ¨ber die Relation Arbeitsauftrag die Verantwortlichkeit beschrieben. Die Relation Transportobjekt beschreibt, welches Ladehilfsmittel bewegt wird. Transportmedium gibt die Beziehung zur ausf¨ uhrenden Maschine an. Die Relationen Transportquelle (source) und Transportziel (destination) sind selbsterkl¨ arend. 1 11 ) Platzbelegung: Jedes Ladehilfsmittel muss genau • ( 9 n einem Platz zugeordnet sein. Ein Lagerplatz kann mehrere Ladehilfsmittel aufnehmen. n 11 ) Arbeitsbereich: Ein bestimmter Lagerplatz kann von • ( 10 m mehreren Maschinen erreicht werden, allerdings kann auch eine Maschine mehrere Lagerpl¨ atze versorgen. n 12 ) Zonung: Verschiedene Lagerpl¨atze lassen sich in Zonen • ( 11 m gruppieren und jeder Zone k¨ onnen viele Lagerpl¨atze angeh¨oren.

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

4

Artikel, die ohne Ladehilfsmittel transportiert oder gelagert werden, erf¨ ullen durch Zuordnung zu einem virtuellen Ladehilfsmittel“, das physisch nicht vor” handen ist, diese Beziehung. 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).

262

7. Datenmodell eines WMS am Beispiel myWMS

ten als auch Kaufverbot als Relationen zwischen Kunde und Artikelstamm gew¨ unscht sind, sind beide durch je eine separate Linie aufzuf¨ uhren.

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

Personalverwaltung, Qualit¨ atssicherung, Speditionswesen, Mandantenverwaltung und Warenwirtschaft

relevant. Die Implementierung kann auf zwei Arten geschehen: Eine gemeinsame Datenbasis vermeidet redundante Datenhaltung und die damit verbundenen Nachteile (vgl. Abschn. 5.2). Alternativ kann nach dem Prinzip der mehrfachen Datenhaltung gearbeitet werden, das heißt, die Daten liegen in Kopien an verschiedenen Stellen vor. Nachteilig ist der damit verbundene Aufwand f¨ ur die Synchronisation der Datenbest¨ande und die kurzfristige Verletzung der Integrit¨ at durch einseitige Daten¨anderung. Dennoch wird dieses Verfahren in der Praxis h¨ 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¨otigt. Dabei ist zu beachten, dass der Artikelstamm neben einem von beiden Systemen gemeinsam genutzten Teil - in der Mitte der Abb. 7.2 grau hinterlegt - auch spezifische Daten nur f¨ ur das WMS und solche f¨ ur das WWS enth¨alt. 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¨aufiger, im Extremfall ¨ bei jeder Anderung, synchronisiert werden.

7.2 Klassische Realisierung eines WMS In diesem Abschnitt werden Teilaspekte einer m¨oglichen Realisierung auf der Basis einer relationalen Datenbank beschrieben. Diese Art der Umsetzung des logischen Konzeptes eines WMS ist typisch f¨ ur die heute im Einsatz befindlichen und am Markt angebotenen Systeme. Aufgrund der suggestiven Struktur relationaler Datenbanken und ihrer eing¨angigen Abfragesprachen

7.2 Klassische Realisierung eines WMS

263

Artikelstamm

Artikelstamm Artikelnummer Artikelbezeichnung BildURL

Artikelnummer Artikelbezeichnung BildURL Hersteller Inhaltsstoffe .. .

Hersteller Inhaltsstoffe .. . Vorzugszone ZLVerbot .. .

Datenabgleich Artikelstamm Artikelnummer Artikelbezeichnung BildURL Vorzugszone ZLVerbot .. .

Abbildung 7.2. Realisierung der Schnittstellen durch teilweise redundante Datenhaltung.

k¨ onnen Systeme in angemessener Zeit realisiert werden. F¨ ur das oben beschriebene Datenmodell werden hier grunds¨ atzliche Techniken, wie sie unter Einsatz einer Datenbank u autert. ¨ blich sind, erl¨ sectionFunktionale 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 Datenbankserver5 l¨auft, oder die • Client-Server-Systeme (vgl. Abb. 7.4), die verteilte Arbeitsstationsrechner mit spezifischer Funktionalit¨ at an einen Datenbankserver binden. Bei der Mainframe-Architektur laufen alle Prozesse auf dem Zentralrechner und werden durch Terminals bedient, die u ¨ber keine eigene WMSFunktionalit¨ at verf¨ ugen. Bei Client-Server-Systemen werden diese Prozesse ganz oder teilweise auf die intelligenten Arbeitsstationen verteilt und der Server wird dadurch entlastet. Aus informationstechnischer Sicht sind folgende Teilaufgaben zu unterscheiden: • Maskenaufbau und Darstellung der Daten k¨ onnen immer lokal erfolgen und bed¨ urfen keines Datenbankzugriffs. Als m¨ ogliches Beispiel f¨ ur die Auslagerung der Darstellung sei der html-Browser genannt. 5

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

264

7. Datenmodell eines WMS am Beispiel myWMS

DB Applikation (WMS)

Server

Client

... ...

Terminal

Abbildung 7.3. Beispiel einer mainframe-basierten Architektur

• Plausibilit¨ atskontrollen k¨ onnen an einen Client abgegeben werden. Die Pr¨ ufung auf richtige Eingabe einer Postleitzahl oder einer E-Mail-Adresse beispielsweise sind Aktionen, die lokal abgearbeitet werden k¨onnen. Eine Versendung dieser Daten vom Client zum Server und zur¨ uck kann als unn¨ otige Kommunikation betrachtet werden. • Integrit¨ atschecks dienen der Sicherung der Vollst¨andigkeit und Widerspruchsfreiheit der Daten. Im Allgemeinen werden hierzu mehrere Datens¨ atze ben¨ otigt, so dass diese Checks vorzugsweise auf dem Server ausgef¨ uhrt werden. So muss beispielsweise vor dem L¨oschen von Artikelstammdaten gesichert sein, dass sich keine Artikel mit der Artikelnummer des zu l¨ oschenden Datensatzes mehr im Lager 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¨osungen). Diese Form der Datenhaltung und des Datenaustausches finden z. B. bei Tauschb¨orsen im Internet Anwendung.

7.2 Klassische Realisierung eines WMS

265

DB Applikation (WMS)

... ...

Abbildung 7.4. Beispiel einer Client-Server-Architektur

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.1 Tabellenstruktur Die Datenbank stellt die M¨ oglichkeit zur Verf¨ ugung, die verschiedenen Daten, die zum Betrieb eines Lagers n¨ otig sind und die w¨ahrend des Betriebs anfallen, strukturiert abzulegen. Das Tabellenkonzept unterst¨ utzt die Strukturierung. Generell kann jeder Container der Abb. 7.1 in eine eigene DatenbankTabelle abgebildet werden. Bevor die Daten jedoch abgelegt werden k¨onnen, muss die 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 6 zu speichern. Bei einer etwas genaueren Betrachtung f¨allt die 6

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

266

7. Datenmodell eines WMS am Beispiel myWMS

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¨arschl¨ usseln zur Identifizierung einer Datenzeile. Die Struktur der Datenbank-Tabelle ItemData k¨onnte wie in Tabelle 7.1 dargestellt aussehen. Das Feld photo hat in dieser Struktur eine L¨ange von 255 Zeichen, um eine URL (s. Seite 171) f¨ ur das Foto anzugeben. Eine Methode zur Speicherung solcher Bin¨ ardaten stellt der Datenbanktyp blob (Binary Large Object) dar. Die Vorteile der URL im Gegensatz zum blob liegen in der Flexibilit¨ at der Wahl des Speicherortes der Fotodaten, deren M¨oglichkeit zur mehrfachen Referenzierung und der Entlastung der Datenbank von der ¨ ¨ Handhabung großer Datenmengen. Ahnliche Uberlegungen gelten f¨ ur die Beschreibung, die alternativ in einer separaten Textdatei stehen und u ¨ ber eine URL angesprochen werden kann. Im Rahmen einer Internationalisierung der Beschreibungen stehen u altige M¨oglichkeiten zur Verwal¨ber die URL vielf¨ tung und Darstellung zur Verf¨ ugung. In der Tabelle 7.1 steht der Feldbezeichner rId f¨ ur eine eindeutige RawId als Prim¨ arschl¨ ussel. Die Nutzung der Artikelnummer k¨onnte sp¨atestens bei der Implementierung eines Mandantenlagers zu Mehrdeutigkeiten f¨ uhren und ussel nicht geeignet. Heutige Datenbanksysteme bieist damit als Prim¨ arschl¨ ten die M¨ oglichkeit, die Prim¨ arschl¨ ussel zu den einzelnen Datens¨atzen automatisch zu generieren und den Programmierer dadurch zu entlasten. n Zwischen ItemData und StockUnit besteht eine 1 -Relation. Das ItemData kann auf keine, eine oder mehrere StockUnit-Tabellen verweisen. Diese Relation wird u ¨ ber das Feld itemDataId (s. Tabelle 7.2) realisiert, das jeder Zeile von StockUnit genau eine rId von ItemData zugeweist, umgekehrt kann eine rId von ItemData in mehreren Zeilen von StockUnit erscheinen (vgl. Abb. 7.5). m -Assoziation zwischen location und locationCategory kann Die n sinnvollerweise nur u ¨ ber eine Hilfstabelle, die Referenztabelle, auch map table genannt, realisiert werden (vgl. Abb. 7.6). Jede Zeile der Referenztabelle verbindet eine RawId der Tabelle location mit einer RawId der Tabelle locationCategory und verf¨ ugt selbst u ¨ ber einen Prim¨ arschl¨ ussel, der aus den jeweiligen beiden RawIds der zugeh¨origen Zeile gebildet werden kann.

7.3 Sicherung der logischen Integrit¨ at

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

Der Verzicht auf eine solche Referenztabelle w¨ urde zu einer stark redundanten Datenhaltung und daraus resultierenden zus¨atzlichen Anforderungen an Speicher- und Laufzeitbedarf f¨ uhren.

7.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 muss durch zus¨ atzliche Logik sichergestellt werden. Je nach Anwendungsfall muss oder sollte jede location genau einer Zone A, B oder C zugeordnet werden. Eine Zuordnung zu mehreren Zonen ist aus logistischer Sicht unzul¨assig und muss vermieden werden. Allerdings darf eine location zus¨atzlich einer

268

7. Datenmodell eines WMS am Beispiel myWMS

Tabelle 7.2. Aufbau der Tabelle stockUnit Name

Typ

Länge

rId

int

seriennummer

varChar

anzahl

int

itemDataId

int

20

Gewichtsklasse zugeordnet werden, die u ¨ ber das gleiche Feld repr¨asentiert wird. Alternativ k¨ onnten die Inhalte von locationCategory auf mehrere dedizierte Datenbank-Tabellen verteilt werden. Eine Verteilung, bei der nur noch 1 n -Relationen auftreten, vermeidet das Problem zu Lasten einer statischen Struktur; zus¨ atzliche Kategorien k¨ onnen nicht im laufenden Betrieb ¨ ohne Anderung des Datenmodells angelegt werden. Ein weiteres Beispiel zum Problem der Sicherung der logischen Integrit¨at ist auf Seite 264 beschrieben. Wenn in der Datenbank-Tabelle stockUnit das Feld seriennummer belegt ist, muss das Feld anzahl den Wert 1 enthalten. itemData bezeichnung

photo

00001

Erbsen

http://www.mywms

42

00002

Bohnen

http://www.mywms

21

00003

Linsen

...

11

42

01

17

00004

...

...

96

11

02

9

00005

...

...

84

217

03

1

...

...

...

12

42

04

11

96 96

05 ...

25 ...

42

...

...

rId

Abbildung 7.5. Beispiel einer 1-z-u-n-Relation

stockUnit itemDataId rId anzahl

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

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

artnr

7.3 Sicherung der logischen Integrit¨ at

269

2.2.3 2.2.2 2.1.2 1.1.1

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

7

...

1.3.1

rId1

...

2.3.1

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

location locationCode

... ...

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

7.3.1 Anlegen und Abfragen von Stammdaten Der Zugriff auf die in der Datenbank abgelegten Datens¨atze und deren Manipulation durch einen Anwender erfolgt mittels einer datenbankspezifischen Sprache (DML7 ), die meisten Datenbanksysteme unterst¨ utzen f¨ ur diesen Zweck SQL8 als standardisierte Abfragesprache. Damit ein Anwender SQL ¨ f¨ ur Abfragen und Anderungen an einem Datenbestand einsetzen kann, ist die Kenntnis des Datenmodells erforderlich. Beispielhaft werden nachfolgend einige typische Datenbankoperationen unter SQL beschrieben. Das Hinzuf¨ ugen eines neuen Datensatzes in die Tabelle stockUnit erfolgt durch folgende Anweisung, in der die Inhalte der Spalteneintr¨age durch Variablen u ¨bergeben werden. Im Beispiel stellt stockUnitCount eine sequence dar, welche die Anzahl der Datens¨ atze in der Tabelle stockUnit enth¨alt: insert into stockUnit (rId, seriennummer, anzahl, itemDataId) values (stockUnitCount.nextVal,’’,11,42);

Durch den nachfolgenden Aufruf werden die Bezeichnungen aller Artikel ausgegeben, deren Gewicht unter zehn Gewichtseinheiten liegt. select bezeichnung 7 8

Data Manipulating Language Structured Query Language

270

7. Datenmodell eines WMS am Beispiel myWMS

from itemData where gewicht < 10;

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

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

7.4 myWMS Die objektorientierte Programmierung (s. Abschn. 6.2) bietet auch f¨ ur die Realisierung von WMS viele Vorteile. Aus diesem Grund werden f¨ ur neuere Entwicklungen oft objektorientierte Programmiersprachen9 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 aufbauen. ¨ Im Mittelpunkt der Uberlegungen steht nicht eine Abbildung der Datenstrukturen auf Tabellen einer Datenbank, sondern eine Analyse, die 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 solche u ¨ ber Java hilfreich. Durch den suggestiven Aufbau dieses Kapitels und der gew¨ahlten Beispiele sind die grundlegenden Prinzipien auch ohne derartige Kenntnisse nachvollziehbar. In Abschn. 7.5 wird anhand eines einfachen Beispiels der Einsatz dieses Rahmenwerkes f¨ ur ein vereinfachtes WMS gezeigt. 9

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

7.4 myWMS

271

7.4.1 Grunds¨ atzlicher Aufbau von myWMS myWMS stellt - wie ein Betriebssystem - vielf¨ altige Basisfunktionen und elementare Dienste f¨ ur WMS-Applikationen bereit. Es ist als Plattform nicht eigenst¨ andig ohne applikationsspezifische Erweiterungen zu betreiben. myWMS 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. Neben der reinen Lagerverwaltung beinhaltet das myWMS-Framework auch eine Materialflusssteuerung. Aspekte der Warenwirtschaft, der Produktionsplanung und der Produktionssteuerung werden im Rahmen dieses Projektes nicht behandelt, Schnittstellen zu solchen Systemen sind jedoch Bestandteil des Rahmenwerks. Da myWMS nicht auf spezielle Lagertypen und logistische Prozesse festgelegt ist, existiert ein breites Anwendungsfeld: Von manuell bedienten L¨agern u ager bis hin zu r¨ aumlich verteilten L¨agern mit hetero¨ ber automatische L¨ genen Strukturen sind die unterschiedlichsten Szenarien denkbar. Die Anpassung an bestehende L¨ ager wird durch die M¨oglichkeit der Entwicklung geeigneter Plug-Ins, wie beispielsweise Routing- oder Optimierungsalgorithmen, erleichtert. Ein Plug-In muss an einen Prozess - im Folgenden Kernel genannt - gebunden werden. Ein Kernel stellt vom Lagertyp unabh¨angig Grundfunktionalit¨ at zur Verf¨ ugung (vgl. Abb. 7.7). myWMS bietet eine Bibliothek f¨ ur h¨aufig ben¨ otigte Plug-Ins an. Dem Nutzer ist es freigestellt, diese im Original oder in einer modifizierten Form zu nutzen oder die ben¨otigten Plug-Ins selbst zu erstellen. 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¨ahigkeit auf unterschiedlichsten Rechnerarchitekturen und Betriebssystemen gew¨ahrleistet werden. Verteilbarkeit: Die Module eines WMS sollten auf mehreren kooperierenden Rechnern nebenl¨ aufig betrieben werden k¨onnen. So kann beispielsweise die Materialflusssteuerung auf einem anderen Rechner als die eigentliche Lagerverwaltung ablaufen. Die Plattformunabh¨angigkeit erm¨ oglicht den Einsatz heterogener Rechnersysteme. Skalierbarkeit: Wachsende Anforderungen, wie beispielsweise steigende Durchsatzzahlen oder eine Erh¨ ohung der Mandantenanzahl, sollten von

272

7. Datenmodell eines WMS am Beispiel myWMS

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

einem WMS abgedeckt werden k¨ onnen. Mittel hierzu sind Verteilung, Anpassung der Module und Parametrierung. Parametrierbarkeit: Ein WMS sollte eine durchg¨angige Parametrierbarkeit der Module erlauben. Das 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: keine Beschr¨ ankung auf bestimmte Lagertypen, Betriebsmittel oder Strategien Erweiterbarkeit: Durch die Erstellung zus¨atzlicher Module oder die Erweiterung bestehender ist die Anpassung an die verschiedensten Anforderungen der Logistik m¨ oglich. myWMS erf¨ ullt diese Anforderungen durch die Kernel/Plug-In-Technologie, die konzeptionelle M¨ oglichkeit der Verteilbarkeit, die Konfigurationsf¨ahigkeit und die Implementierung in Java. myWMS basiert auf einer dreischich-

7.4 myWMS

273

Kern Plug-In Erweiterungen

Bestands verwaltun g

Lagerorts verwaltun g

Materialflu ss Steuerun g

Abbildung 7.8. Das Schichtenmodell von myWMS

tigen Hierarchie, die aus der Bestandsverwaltung, der Lagerortsverwaltung sowie der Materialflusssteuerung gebildet wird (s. Abb. 7.8). Die Bestandsverwaltung (Inventory Manager ) hat die Aufgabe, die Artikelstammdaten (ItemData) und die artikelbezogenen, standortunabh¨angigen Operationen sowie die verf¨ ugbaren und die vorhandenen Mengen der Bereitstelleinheiten (vgl. Abb. 7.1) zu verwalten. Die Lagerortsverwaltung (Location Manager ) verwaltet die Lagerorte (Location). Hier werden die aktuelle Belegung der Lagerorte mit Ladeeinheiten, die durch Ladehilfsmittel (UnitLoad ) repr¨ asentiert werden, und die Attribute der Lagerorte verwaltet. Die Materialflusssteuerung (Equipment Manager ) berechnet die Transportwege, beauftragt die Betriebsmittel und u ¨ berwacht die operative Ausf¨ uhrung der Transportauftr¨ age. Nicht jedes System muss alle drei Schichten realisieren. So kann beispielsweise eine Bestands- und eine Ortsverwaltung betrieben werden, die untere Schicht kann dann durch einen getrennten Materialflussrechner ersetzt werden. In einem nichtautomatisiertem Lager kann die unterste Schicht, also die Materialflusssteuerung, die Erstellung von gedruckten Transportanweisungen oder die Ansteuerung von Funkterminals u ¨bernehmen.

274

7. Datenmodell eines WMS am Beispiel myWMS

Durch den separaten Betrieb der untersten Schicht kann aber auch unter Verzicht auf die Lagerfunktionalit¨ at ein eigenst¨andiger Materialflussrechner auf myWMS-Basis erstellt werden. Jede dieser Schichten kann auch in mehreren Instanzen betrieben werden. So kann durch mehrfache Instanziierung der beiden oberen Schichten ein Mandantenlager, also eine Bereitstellung mehrerer logischer L¨ager in einem Lagerhaus, erstellt werden. Durch mehrfache Instanziierung der unteren Schicht kann ein Multilager, also ein Lager, das u ¨ ber mehrere r¨aumlich getrennte Standorte verf¨ ugt, betrieben werden. Damit ist auch die Bildung von mandantenf¨ ahigen Multil¨ agern m¨ oglich. 7.4.2 Gesch¨ aftsobjekte Die Aufgabe der einzelnen Schichten ist die Verwaltung der zugeh¨origen Daten, die in Gesch¨ aftsobjekten gespeichert sind. Jedes Gesch¨aftsobjekt entspricht genau einem Container des Datenmodells der Abb. 7.1. myWMS umfasst folgende Gesch¨ aftsobjekte: • • • • • • • • • •

Supply (WEAnforderung), ItemData (Artikelstamm), Order (WAAnforderung), StockUnit (Bereitstelleinheit ), StockUnitCategory (Artikelgruppe), UnitLoad (Ladehilfsmittel ), LoadHandler (Maschine), Location (Lagerplatz ), LocationCategory (Lagerplatzgruppe) und OrderChain (Transportauftrag).

Die Schichtung erlaubt eine detailliertere Modellierung einzelner Objekte. So wird beispielsweise mit StorageLocation der physische und mit Location der logische Lagerplatz unterschieden. Im Allgemeinen existiert zu jedem logischen auch ein physischer Lagerplatz. Der Platz auf dem Lastaufnahmemittel einer Maschine stellt einen physischen Lagerplatz dar, der kein ¨ logisches Aquivalent besitzt (vgl. Seite 258). Die Gesch¨ aftsobjekte sind unter konsequenter Einhaltung der OO-Denkweise (vgl. Abschn. 6.2), also Analyse, Design, Implementierung und Test, erstellt worden. Zum Beispiel ist kein Attribut direkt zugreifbar: Alle Attribute sind gekapselt und nur durch die so genannten Accessor-Methoden verf¨ ugbar. Jedes Gesch¨ aftsobjekt verf¨ ugt u ¨ ber eine Schnittstelle, mit der u ¨ ber die dort deklarierten Methoden mit ihm kommuniziert werden kann. Andere Methoden sind gekapselt und stehen nicht zur Verf¨ ugung. Gesch¨ aftsobjekte k¨ onnen durch das Mittel der Vererbung spezialisiert werden. Kommen zur Laufzeit des WMS neue Attribute hinzu, die w¨ahrend der Implementierung noch nicht bekannt sein konnten, nicht bekannt waren oder nicht ber¨ ucksichtigt wurden, werden diese durch Key-Value-Coding

7.4 myWMS

275

realisiert. Diese Technik ist als allgemeines Design-Pattern Property bekannt und in Java unter anderem als Hashtable realisiert. Eine Kombination beider Verfahren, also Vererbung und Propertytechnik, ist m¨oglich. Das myWMS-Gesch¨ aftsobjekt ItemData sollte nur durch das Mittel der Ableitung auf den jeweiligen Anwendungsfall angepasst werden, da in der Basisklasse nur die Attribute itemNumber (Artikelnummer) und name (Klartextbezeichnung), die jedes Lager aufweist, existieren10 . Reale L¨ager k¨onnen weitere Attribute wie etwa die Lokation eines Fotos oder einen Mindestbestand (vgl. Abschn. 2.3.1) ben¨ otigen. Diese w¨ urden dann in einer ItemData erweiternden Klasse zusammen mit ihren Accessor-Methoden deklariert und definiert werden. Sie sind dem Kernel nicht bekannt und werden von anderen Objekten oder Plug-Ins benutzt. F¨ ur das Gesch¨ aftsobjekt LocationCategory kann die Nutzung von Properties sinnvoller sein, da hierdurch eine dynamische Erweiterung der Gruppierungen von Lagerpl¨ atzen leicht m¨ oglich ist. Das comObject, eine von myWMS implementierte Klasse, nutzt beide Techniken. Die Basisklasse stellt eine gesch¨ utzte (protected) Hashtable zur Verf¨ ugung, die mit jeder Ableitungsstufe weiter gef¨ ullt wird. Jede Ableitung stellt die entsprechenden Accessor-Methoden zur Verf¨ ugung. F¨ ur die Funktionalit¨ at eines WMS sind entsprechende Gesch¨aftsprozesse zu modellieren und zu implementieren. Gesch¨aftsprozesse k¨onnen myWMS u ¨ ber das Plug-In-Interface bekanntgegeben werden. Eine wichtige M¨oglichkeit bietet die Nutzung des SupplyStrategyInterface, welches das Plug-In-Interface erweitert und zur Versorgung von Locations dient. Die Kopplung der Prozesse mit den Gesch¨ aftsobjekten ist ereignisgesteuert und basiert auf dem ListenerKonzept . Die Gesch¨ aftsprozesse tauschen keine Zustandsinformationen aus, sie sind aus Sicht des myWMS zustandslos. Typische Gesch¨aftsprozesse sind • Einlagern, • Kommissionieren und • Auslagern. ¨ Die Anderung an einem Gesch¨ aftsobjekt bewirkt, dass alle als Listener registrierten Gesch¨ aftsprozesse benachrichtigt werden. Ein Gesch¨aftsprozess, ullung zus¨atzlicher Randbeder eine solche Nachricht erh¨ alt, pr¨ uft die Erf¨ dingungen und f¨ uhrt gegebenenfalls den n¨ achsten Prozessschritt aus. Der ¨ Prozessschritt kann eine Anderung an Gesch¨ aftsobjekten zur Folge haben. myWMS verf¨ ugt u ¨ ber einige vormodellierte Gesch¨aftsprozesse. Im Allgemeinen ist jedoch eine Anpassung an die konkreten Anforderungen der logistischen Prozesse erforderlich.

10

ItemData verf¨ ugt außerdem u oglichkeit der Nutzung von Plug-Ins ¨ ber die M¨ durch Interfaces, wie beispielsweise ItemDataLockInterface zur Verwaltung von Artikelsperren.

276

7. Datenmodell eines WMS am Beispiel myWMS

7.4.3 Kernel-Konzept Die drei Schichten Bestandsverwaltung, Lagerortsverwaltung und Materialflusssteuerung werden aus Sicht der Informationstechnik aus je mindestens einem Prozess gebildet. Dieser wird als Kernel bezeichnet. Ein WMS setzt sich aus den Kernels der drei obigen Schichten sowie den zugeh¨origen Plug-Ins und den anwendungsfallspezifischen Erweiterungen zusammen. Grundlegende Prinzipien von myWMS sind nachfolgend aufgef¨ uhrt: Logistikorientierung: Im Gegensatz zu Datenbanken oder Application Servern, deren Zielsetzung eine universelle Verwendbarkeit ist, ist myWMS auf die Anforderungen der Logistik, insbesondere der Lagerverwaltung zugeschnitten. Flexibilit¨ at: Durch die Beschr¨ ankung auf Kernfunktionalit¨at und die M¨oglichkeit der Entwicklung spezifischer Plug-Ins wird ein hohes Maß an Flexibilit¨ at erreicht11 . Verteilung der Kernel: Die Kernel der verschiedenen Schichten k¨onnen auf unterschiedlichen Rechnern betrieben werden. Dar¨ uber hinaus k¨onnen die einzelnen Schichten auch wieder aus mehreren Kerneln bestehen, die ihrerseits verteilt werden k¨ onnen. Abschnitt 7.4.1 erl¨autert dies am Beispiel des Mandanten- und des Multilagers. Ereignissteuerung: Um kurze Reaktionszeiten zu erzielen, wird das Konzept der Ereignissteuerung (Event-Verarbeitung) stringent eingehalten. Die Umsetzung erfolgt durch das Design-Pattern Listener. Hierbei registriert sich ein Objekt mit Callback-Methoden bei einem oder mehreren anderen Objekten. Ausnahmebehandlung: Zur Laufzeit auftretende, nicht vorhersehbare Ereignisse wie beispielsweise das versehentliche Ausl¨osen eines Sensorsignals durch das Bedienpersonal, stellen eine Ausnahmesituation dar. Die traditionelle L¨ osung gibt das Ergebnis eines Funktionsaufrufs als R¨ uckgabewert, der den Erfolg oder Misserfolg der Aktion beschreibt, an den Aufrufer zur¨ uck. Je nach der Korrektheit der Implementierung erfolgt eine ad¨ aquate Bearbeitung dieses R¨ uckgabewertes. Das Konzept der Ausnahmebehandlung erzwingt auf transparente Weise eine weitere Bearbeitung. Dies hat direkten Einfluss auf die Steigerung der Qualit¨at der Software. Einbindung aktiver Komponenten: Die Plug-Ins werden vom Kernel u onnen sie auch als eigenst¨andige ¨ ber ihre Methoden aufgerufen. Dabei k¨ Threads nebenl¨ aufig Aktionen ausf¨ uhren und dadurch die Performance steigern.

11

Diese Beschr¨ ankung bedeutet nicht, dass die Kernel trivial sind. Der Einblick in den frei verf¨ ugbaren Quellcode zeigt die Komplexit¨ at und Leistungsf¨ ahigkeit dieses Konzepts.

7.4 myWMS

277

Assoziationsrealisierung: Die Gesch¨ aftsobjekte verwalten selbst keine Assoziationen, diese werden im Kernel realisiert. Dies ist eine der Voraussetzungen f¨ ur die Verteilbarkeit. Verteilung der Gesch¨ aftsobjekte: Gibt der Kernel ein Gesch¨aftsobjekt tempor¨ ar an einen nebenl¨ aufigen Prozess, wird eine Kopie dieses Objektes mit identischer Objektnummer erstellt. In Verbindung mit der Serialisierungsf¨ ahigkeit aller Gesch¨ aftsobjekte wird deren Verteilbarkeit u ¨ ber mehrere Rechner erzielt. Sicherung der Integrit¨ at: Obwohl jedes Gesch¨aftsobjekt elementare Inte¨ grit¨ atspr¨ ufungen durchf¨ uhrt, k¨ onnen u u¨ ber Plug-Ins zus¨atzliche Uberpr¨ fungen vorgenommen werden. So pr¨ uft beispielsweise eine Ableitung von StockUnit die korrekte Auff¨ ullung der Seriennummer auf zugelassene Zeichen und Zwischenr¨ aume. Durch ein Plug-In kann sichergestellt werden, dass diese Seriennummer nicht doppelt vorhanden ist. Persistierung der Daten: Der Kernel ruft Persistierungsmethoden auf, die u ugung gestellt werden m¨ ussen. Ei¨ ber ein Plug-In-Interface zur Verf¨ nige Persistierungs-Plug-Ins sind bereits Bestandteil von myWMS, so ist neben der Sicherungsm¨ oglichkeit u ¨ ber die Datenbank auch die Nutzung des File-Systems u oglich. Zu Lehr- und Testzwecken ¨ ber Serialisierung m¨ besteht die M¨ oglichkeit, unter Verzicht auf den Einsatz einer Datenbank die Daten u ¨ber das gleiche Interface im Speicher abzulegen. Die obigen Konzepte legen die Implementierung der myWMS-Kernel und der zugeh¨ origen Plug-Ins in Java nahe. Java bietet • • • • • •

Event- und Exceptionhandling sowie Multithreading, Interfaces zur Beschreibung abstrakter Klassen, grundlegende Serialisierungskonzepte, Remote Message Invocation (RMI), umfangreiche Netzwerkf¨ ahigkeit, m¨ achtige Klassenbibliotheken f¨ ur alle denkbaren Problemstellungen.

Dar¨ uber hinaus ist Java die meistgelehrte Sprache bei der Ausbildung der Programmierer und Software-Ingenieure und wird auf breiter Basis akzeptiert. 7.4.4 Laufzeitumgebung Neben dem Kernel und der Plug-In-Bibliothek bietet myWMS mit dem Standard-Environment“ zus¨ atzlich eine Laufzeitumgebung, die viele n¨ utz” liche Funktionen bietet und auch in anderen Projekten sinnvoll eingesetzt werden kann. Dieses Environment wird in folgende Themengebiete gegliedert:

278

7. Datenmodell eines WMS am Beispiel myWMS

Logging: Das Logging dient der Aufzeichnung von verschiedenen Nachrichten, die unterschieden nach Dringlichkeit (logLevel ) und Kategorie genau einem Logserver u ¨ bergeben werden. myWMS stellt einen solchen Logugung. Die Klassifizierung der Kategorien server als Singleton12 zur Verf¨ nach • ausf¨ uhrendem Rechner, • aktuellem Benutzer, • Datum und Uhrzeit, • Objekt, • Methode und • Thread erm¨ oglicht eine qualifizierte Offline-Analyse der gespeicherten Nachrichten. Statistik: Die Sammlung der statistischen Rohdaten erfolgt analog zu der Aufzeichnung von Log-Nachrichten in einem separaten Server, dem Statistikserver. ¨ Konfiguration: Uber die Konfiguration wird neben der Parametrierung festgelegt, welche Plug-Ins genutzt werden. Die Anmeldung bei einem Konfigurations-Provider sichert die Benachrichtigung der angemeldeten Objekte u anderungen zu. Damit kann auch zur Lauf¨ ber Konfigurations¨ zeit die Konfiguration ge¨ andert werden. Clearing: Ausnahmesituationen, die von dem System nicht selbstst¨andig behandelt werden k¨ onnen, werden einem Clearing-Singleton mit einer vorgegebenen Menge von Antworten oder Handlungsanweisungen u ¨ bergeben. Wird vom Clearing eine solche Ausnahmesituation empfangen, wird ein externer Eingriff zur Auswahl der korrekten Antwort oder zur Quittierung einer Handlungsanweisung erforderlich. Kommunikation: Das Channelkonzept von myWMS erm¨oglicht den Transport von Kommunikationsobjekten u ¨ ber die verschiedenen physischen und logischen Leitungen. So implementiert myWMS den Transport u ¨ ber den Layer des ISO/OSI-Protokollstacks (vgl. Abschn. 5.1.1) genauso wie die Kommunikation u ¨ber RS232. Die als Plug-In vorhandenen Protokolle erm¨ oglichen hierbei die Serialisierung und Deserialisierung der Kommunikationsobjekte. Event-multicasting: Verschiedene Listener-Objekte k¨onnen sich bei einem Panelobjekt , das selbst wiederum ein Listener ist, registrieren und bilden dann eine Listener-Gruppe. Beim Panelobjekt eingehende Events werden in Kopie an alle registrierten Listener weitergeleitet. Das von myWMS implementierte Event-multicasting beinhaltet die M¨oglichkeit der Verwaltung von bis zu zwei Listener-Gruppen.

12

Eine Klasse, die dem Design-Pattern des Singletons gen¨ ugt, stellt sicher, dass sie maximal einmal instanziiert wird.

7.5 Beispielhaftes Distributionssystem/Referenzlager

279

Die Nutzung der mitgelieferten Laufzeitumgebung ist nicht bindend, lediglich die Interfaces m¨ ussen eingehalten werden. Damit ist die Anbindung an vorhandene L¨ osungen, wie etwa ein eigenes Logging, m¨oglich.

7.5 Beispielhaftes Distributionssystem/Referenzlager Dieses Kapitel stellt ein fiktives Lager vor, an dem beispielhaft typische Strukturen von Warehouse Managementsystemen aufgezeigt werden. Auf der beigelegten CD befindet sich hierzu ein lauff¨ ahiges Programm mit einer animierten Visualisierung dieses Beispiellagers. Nachfolgend werden die Topologie, die Betriebsmittel und die logistischen Prozesse beschrieben. 7.5.1 Beschreibung des Beispiels Zur nachfolgenden Beschreibung der Funktionalit¨aten dient ein Distributionssystem f¨ ur Elektrokleinger¨ ate aus dem Haushaltswarenbereich. Das System besteht aus dem Wareneingangs- und Warenausgangsbereich und dem Lagersystem mit vorgeschalteter Kommissionierzone (s. Abb. 7.9). Ankommende Einheiten werden 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) bzw. in einen separaten Sperrbereich zum Zwecke einer eingehenden Qualit¨ atspr¨ ufung. Aus dem Lagerbereich werden einerseits ganze Einheiten entnommen und von der Auslagerstichbahn per Stapler zu den Pufferzonen des Warenausgangsbereiches verbracht. Teilmengen werden andererseits an Kommissionierpl¨ atzen vor dem Hochregal gebildet und nach Fertigstellung analog in den Warenausgangsbereich transportiert. 7.5.2 Beschreibung des Lagersystems Bei dem Lager (vgl. Abb. 7.10) handelt es sich um ein einfaches, automatisches Hochregallager (HRL). Um den Anforderungen eines Referenzsystems gerecht zu werden, ist es einerseits so gestaltet, dass typische Komponenten und Abl¨ aufe eines Lagers dargestellt werden; andererseits werden an bestimmten Stellen Vereinfachungen in Kauf genommen, um die Komplexit¨at zu reduzieren und die wesentlichen Gesichtspunkte hervorzuheben. 7.5.3 Topologie Das vorgestellte Lager hat 4.000 Lagerpl¨ atze. Als Ladehilfsmittel kommen Europaletten (800 mm×1200 mm) zum Einsatz, auf denen die Artikel artikelrein transportiert und gelagert werden. Insgesamt lassen sich die Funktionsbereiche Hochregallager, Lagervorzone und Kommissionierpl¨atze identifizieren.

280

7. Datenmodell eines WMS am Beispiel myWMS

Abbildung 7.9. Das Distributionssystem

Das Hochregallager besteht aus vier Gassen, jede Lagergasse wird von einem Regalbedienger¨ at (RBG) bedient. Die Lagervorzone stellt die materialflusstechnische Verbindung der Funktionsbereiche her. Als Querf¨ordertechnik kommt ein Querverteilwagen (QVW) zum Einsatz. Neben dem Querverteilwagen umfasst die Lagervorzone die Einlagerbahn mit I-Punkt, die Ausla¨ ¨ gerbahn 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 vor- und einem ¨ nachgeschalteten Ubergabeplatz zur Anbindung an den Querverteilwagen. 7.5.4 Lagertechnik Das Hochregallager wird in dieser Form tausendfach in der Praxis eingesetzt und beschreibt einen klassischen Fall der Lagertechnik (vgl. Kapitel 3). Alle Lagerf¨ acher haben die gleichen Abmessungen und sind f¨ ur die einfachtiefe Aufnahme von Standard-Europaletten in L¨angsrichtung ausgelegt. Jedes der acht Regale besteht aus 50 F¨ achern in horizontaler und zehn F¨achern in vertikaler Richtung, so dass sich eine Lagerfachanzahl von 500 pro Regal und 4.000 insgesamt ergibt. Besonderheiten wie doppelttiefe Lagerung oder unterschiedliche Fachabmessungen kommen im Referenzlager nicht zur Anwendung.

7.5 Beispielhaftes Distributionssystem/Referenzlager

281

Abbildung 7.10. Das Beispiellager

7.5.5 F¨ ordertechnik Pro Lagergasse kommt ein automatisches Regalbedienger¨at zum Einsatz (vgl. Abschn. 3.2.2). Die Regalbedienger¨ ate sind einmastig, u ¨ ber Schienen bodenverfahrbar und deckengef¨ uhrt. Das Wechseln eines Regalbedienger¨ates in eine andere Gasse ist nicht m¨ oglich. Alle Antriebe sind elektrisch, wobei die Energie- und Steuersignal¨ ubertragung u ¨ber Schleifleitungen erfolgt. Als Lastaufnahmemittel findet eine Teleskopgabel Verwendung. Wichtige Kenngr¨oßen der Regalbedienger¨ ate sind in Tabelle 7.3 aufgef¨ uhrt. Der in der Lagervorzone eingesetzte Querverteilwagen ist ebenfalls schienengef¨ uhrt. Energie- und Signal¨ ubertragung erfolgen u ¨ ber Schleppkabel. Als Lastaufnahmemittel dient ein Kettenf¨ orderer. Der eingesetzte Querverteilwagen zeichnet sich durch hohe Beschleunigungs- und Geschwindigkeitswerte aus, um den hohen f¨ ordertechnischen Anforderungen als zentrales und leistungsbestimmendes F¨ orderelement gerecht zu werden. ¨ 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

282

7. Datenmodell eines WMS am Beispiel myWMS

Tabelle 7.3. Technische Daten der Regalbedienger¨ ate Name

Typ

rId

int

seriennummer

varChar

anzahl

int

itemDataId

int

Länge

20

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 Querverteilwagen u onnen. Das Aufgeben von Paletten auf die Ein¨ bergeben werden k¨ lagerbahn bzw. das Abf¨ ordern von Paletten von der Auslagerbahn oder der fertig kommissionierten Paletten erfolgt u ¨ ber konventionelle Frontgabelstapler. Diese erhalten ihre Auftr¨ age von einem separaten Staplerleitsystem, das nicht fester Bestandteil dieses Beispielsystems ist. 7.5.6 Steuerungstechnik Die Informationen zum Steuern eines automatischen Lagers werden zun¨achst 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¨ahrend des Prozesses am Wareneingang, der außerhalb der Systemgrenze des Referenzlagers liegt und somit hier nicht betrachtet wird. Innerhalb des Lagers kann mit Hilfe zweier Lesestellen jede Palette 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¨atze sind mit Tastern, u ¨ ber die der Kommissionierer einen Auftrag quittieren kann, sowie mit Terminals zum Anzeigen des zu entnehmenden Artikels und der Entnahmemenge ausgestattet. S¨ amtliche Sensorinformationen werden von den Sensoren an u ¨ berlagerte Speicherprogrammierbare Steuerungen (SPS) gesendet. Die SPS wiederum

ERP System

WMS

IP

KP

ppj

PP2

PP3 PP4

Leitstand

RBGJ RBG2 RBG3 RBG4 QVW

Transportleitsystem

Abbildung 7.11. Systemhierarchie (logische Sicht)

Abbildung 7.12. Systemhierarchie (physikahsche Sicht) kommunizieren liber Ethernet und T C P / I P mit den iiberlagerten 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 iiberlagerte System. Umgekehrt empfangt jede SPS vom iiberlagerten System Steuerungstelegramme, die sie in Steuerbefehle fiir unterlagerte Aktoren umwandelt. Die Steuerungsarchitektur ist demnach hierarchischer Natur und als Ghent-Server-Struktur ausgelegt. Die Abbildungen 7.11 und 7.12 geben einen Uberbhck liber die logische und physikahsche Systemarchitektur. Insgesamt dienen sechs SPS zur Steuerung der Fordertechnik: je eine fiir jedes Regalbediengerat, eine fiir den Querverteilwagen sowie eine SPS zur

284

7. Datenmodell eines WMS am Beispiel myWMS

Steuerung der restlichen Lagervorzone inkl. der Kommissionierpl¨atze. Die SPS-Ebene bildet die gemeinsame Schnittstelle zwischen unterlagerter Steuerung und u ¨ berlagerten Systemen. 7.5.7 Materialfluss Die grunds¨ atzlich m¨ oglichen Wege einer Palette durch das Referenzlager ergeben sich durch die beschriebene Topologie und die eingesetzte F¨ordertechnik. Zentrale Bedeutung kommt dabei dem Querverteilwagen zu, da er die einzige Verbindung zwischen den Funktionsbereichen ist und als Knotenpunkt fungiert13 . Bedingt durch die unidirektionale F¨orderrichtung der einzelnen ¨ Ubergabepl¨ atze kann der Querverteilwagen entweder eine Palette von ei¨ nem Platz aufnehmen (Ubernahme auf den Querverteilwagen) oder aber ei¨ ne Palette auf einen Platz abgeben (Ubergabe vom Querverteilwagen). Ein ¨ Ubergabeplatz kann weder Paletten auf den Querverteilwagen abgeben noch von ihm entgegennehmen. Typische Wege einer Palette durch das Lager ergeben sich aus der logistischen Funktion des Lagers. Grunds¨ atzlich besteht diese aus den Grundfunktionen Einlagern, Auslagern und Kommissionieren. Beispiele f¨ ur typische Wege unter Einbeziehung des Querverteilwagens sind demnach • Einlagern in Gasse 4: I-Punkt → QVW → U1r → RGB4 → Lagerfach; • Auslagern aus Gasse 1: Lagerfach → RGB1 → U1l → QVW → Auslagerbahn; • Kommissionieren: Lagerfach → RGB2 → U2l → QVW → Kommissionier − U2 → QVW U2r → RGB2 → Lagerfach. Typische Wege ohne Einbeziehung des Querverteilwagens sind • Umlagern in Gasse 1: Lagerfach → RGB1 → Lagerfach; • negative Konturenkontrolle: Einlagerbahn → Auslagerbahn. 7.5.8 Logistische Prozesse F¨ ordertechnik, Lagertechnik und Steuerungstechnik bilden zusammen mit den zu verwaltenden Artikeln das Grundger¨ ust, auf dem ein Lagerverwaltungssystem operiert, um logistische Prozesse zu verwalten und zu steuern. Die Aufgaben eines Lagerverwaltungssystems sind in Kapitel 2 beschrieben. Grundlegende Prozesse, die im engen Zusammenhang mit dem Materialfluss stehen, sind u. a.

13

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.

7.5 Beispielhaftes Distributionssystem/Referenzlager

285

1. das Einlagern, 2. das Auslagern 3. und das Kommissionieren. Diese Prozesse werden nachfolgend in ihrer spezifischen Auspr¨agung f¨ ur das Referenzsystem grob umrissen und stellen den Anforderungsrahmen f¨ ur das zu implementierende WMS dar.

Einlagern Das Aufsetzten einer Palette am I-Punkt hat die Identifizierung der Ladeeinheit u are Lesestelle zur Folge. Die entsprechende ¨ ber die station¨ SPS versendet daraufhin ein Telegramm mit der Paletten-ID an das WMS. Das WMS wertet den Eingang der Nachricht als Trigger und pr¨ uft zun¨achst, ob die gemeldete Paletten-ID bekannt ist. Ist dies nicht der Fall, handelt es sich um einen Fehler, da die Paletten-ID bei der Warenannahme zusammen mit der Artikel-ID an das WMS h¨ atte gemeldet werden m¨ ussen. In diesem Fall wird f¨ ur die Palette ein Transportauftrag auf die Auslagerbahn generiert, so dass sie ausgeschleust und zur Clearing-Stelle gebracht werden kann. Dasselbe passiert, wenn der Leser keine Paletten-ID 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¨oht die Zugriffssicherheit; die ABC-Zonung erm¨ oglicht einen schnellen Zugriff auf die schnelldrehenden Artikel bei der Auslagerung. Sind keine entsprechenden Lagerpl¨atze verf¨ ugbar, kann ein Artikel prinzipiell auf jedem freien Lagerplatz eingelagert werden. Ein Einlagervorgang ist abgeschlossen, sobald das entsprechende Ladehilfsmittel auf dem richtigen Einlagerplatz verbucht werden konnte. Auslagern und Kommissionieren Kundenauftr¨age werden u ¨ber ein ERPSystem 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 Auftrags-Warteschlange ein, von wo sie der Einfachheit halber vom WMS nach dem FIFO-Prinzip der Reihe nach

286

7. Datenmodell eines WMS am Beispiel myWMS

abgearbeitet werden. Auf Basis der Kundenauftr¨age erzeugt das WMS Auslagerauftr¨ age und w¨ ahlt diejenigen Ladeeinheiten aus, die zur Erf¨ ullung der einzelnen Positionen ausgelagert werden sollen. Es muss daf¨ ur Sorge tragen, dass die Auswahl geeigneter Ladeeinheiten so erfolgt, dass folgende - evtl. kontr¨ are - Zielsetzungen erreicht werden: 1. Die Anzahl der zu kommissionierenden Paletten soll m¨oglichst gering sein, d.h. es sollen nach M¨ oglichkeit Ladeeinheiten direkt ausgelagert werden. Dabei sollen auch angebrochene Paletten ber¨ ucksichtigt werden. 2. Die LE mit dem ¨ altesten Einlagerdatum soll zuerst ausgelagert werden. 3. Der Auslastungsgrad der Regalbedienger¨ate soll ann¨ahernd gleich sein. Paletten, die nicht kommissioniert werden m¨ ussen, verlassen das Lager u ber Querverteilwagen und Auslagerbahn. Auf dem Querverteilwagen 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¨ordern. 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 zu kommissionieren hat. Durch Bet¨ atigung des Tasters signalisiert er dem WMS die Fertigstellung des Kommissioniervorgangs. Das WMS bestimmt daraufhin gem¨ aß den Regeln der Einlagerung einen neuen Lagerplatz f¨ ur die R¨ ucklagerung der Palette. Zudem wird u uft, ob mit Erledigung des ¨ berpr¨ Kommissioniervorgangs alle zu kommissionierenden 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.

7.6 Aufbau der Topologie Die Topologie eines Lagers, die aus den Lagerpl¨atzen, den Maschinen und deren Verkn¨ upfungen besteht, wird in Java mit Hilfe der Kernelmethoden erstellt. Die Lagerpl¨ atze werden durch Objekte der Klasse StorageLocation repr¨ asentiert, wobei zwischen verschiedenen Zugriffsmethoden (beispielsweise LIFO, FIFO, RandomAccess) entsprechend den Anforderungen gew¨ahlt

7.6 Aufbau der Topologie

287

werden kann. Die r¨ aumliche Lage der einzelnen Pl¨atze ist f¨ ur myWMS nicht relevant und wird nicht abgebildet. Objekte der Klasse HandlingScope repr¨ asentieren einen Arbeitsbereich f¨ ur die Maschinen, welche die Objekte der Klasse StorageLocation verbinden. Jeder LoadHandler , der f¨ ur eine Maschine steht, operiert zu einer Zeit auf genau einem HandlingScope. Der folgende Code-Ausschnitt zeigt die prinzipielle Vorgehensweise beim Aufbau einer Topologie: // Aufbau einer Lagergassenseite EquipmentKernelInterface ek = ... // Verbindung zum Kern int x=50; int y=10; int i,j; long tid;

// // // //

Tiefe der Gasse : 50 Faecher Hoehe des Regals : 10 Faecher Laufvariablen Transaktionshandle

StorageLocation sl; HandlingScope hs;

// temporaere SL fuer ALLE Faecher // temporaeres HS fuer gesamte Gasse

String HandlingScopeName =...// Name der Gasse ... tid = ek.beginTransaction(); // Oeffnen einer Transaktion hs = ek.getHandlingScope(HandlingScopeName, tid); // existierender handlingScope // inkl. Loadhandler anfordern for ( i = 0 ; i < x ; i++ ) { for ( j = 0 ; j < y ; j++ ) { try{ sl = ek.createStorageLocation(tid); sl.setName(getFachName(i,j)); // getFachName liefert // individuellen Namen sl.setStorageType(StorageLocation.LIFO); sl.setDepth(1); // eine UnitLoad pro Fach ek.setStorageLocation(sl,tid); // sl an Kern hs.addStorageLocation(sl); // Verknuepfung hs mit sl } catch (...) { ... } } } try { ek.setHandlingScope(hs,tid); // hs dem Kern zurueckgeben } catch (IntegrityException iex){ ... } try { ek.commit(tid); // Transaktion ausfuehren

288

7. Datenmodell eines WMS am Beispiel myWMS

} catch (TransactionException tex){ ... } ...

Obiges Codefragment setzt die Existenz eines HandlingScopes sowie des darin operierenden LoadHandlers einschließlich seines Lastaufnahmemittels, das aus einer StorageLocation besteht, voraus. Die Instanziierung der Gesch¨ aftsobjekte, in diesem Beispiel die 500 StorageLocations, erfolgt durch entsprechende create-Methoden des Kernels, in diesem Beispiel ek.createStorageLocation(tid). Jedes Gesch¨ aftsobjekt ist u ¨ ber einen Namen adressierbar, der Name wird u ¨ ber die Methode sl.setName(name) der StorageLocation zugewiesen. Danach wird dem Lagerfach u ¨ ber die Methode sl.setStorageType( StorageLocation.LIFO) der Typ Last-In-First-Out“ und u ¨ber die Methode ” sl.setDepth(1) die Kapazit¨ at zugeteilt. Der Typ LIFO wurde f¨ ur die Regalf¨ acher im Hinblick auf eine m¨ ogliche sp¨ atere Erweiterung auf mehrfachtiefe Lagerung gew¨ ahlt. Im Falle einer solchen Erweiterung ist es ausreichend, die Tiefe des Faches mit der Methode sl.setDepth(n) entsprechend zu setzen. Eine solche Erweiterung erfordert eine Anpassung der Zugriffsstrategien auf Regalf¨ acher, da nicht gew¨ ahrleistet werden kann, dass das gew¨ unschte Ladehilfsmittel im direkten Zugriff steht. Diese angepasste Zugriffsstrategie wird dem Kernel wieder u ¨ ber das Plug-In-Verfahren bekannt gegeben. Zur weiteren Verwaltung wird mit der Methode ek.setStorageLocation(sl,tid) die neu erzeugte und konfigurierte StorageLocation dem Kernel u ¨ bergeben. Schließlich wird das Regalfach mit dem HandlingScope durch die Methode hs.addStorageLocation(sl) verkn¨ upft. Die Methode hs.addStorageLocation(sl) sichert einen bidirektionalen Materialfluss (RBG ⇔ Regalfach) zu. Auf diese Weise werden neben den restlichen 3.500 Regalf¨achern alle weiatze erzeugt und mindestens einem HandlingScope zugewiesen. Die teren Pl¨ ¨ Ubergabepl¨ atze zwischen RBG und Verschiebewagen beispielsweise werden ¨ an zwei HandlingScopes gebunden. Da der Materialfluss der Ubergabepl¨ atze unidirektional ist, sind hier die Methoden hs.addPutAway(sl) oder hs.addRetrieval(sl) auf die jeweiligen HandlingScopes anzuwenden. Die Zeile ek.beginTransaction() leitet eine Transaktion ein, die nachfolgend durch ihren Transaktionshandle tid verwaltet wird. Erst durch den Aufruf von ek.commit(tid) wird die Transaktion beendet. Dadurch werden die erzeugten Objekte persistiert und f¨ ur andere Kernelmethoden verf¨ ugbar.

7.7 Plug-In - Routing Der Weg von einer Quelle, beispielsweise einem Regalfach, zu einem Ziel, etwa einem Kommissionierplatz, wird durch ein Plug-In berechnet, das das

7.7 Plug-In - Routing

289

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¨aß den Anforderungen ¨ nach dem Prinzip der Vererbung zu erweitern. Ein Uberschreiben der Methode findWay() der Klasse RouteStrategyFirstMatch mit einem auf die Gegebenheiten des Lagers angepassten Algorithmus ist in vielen F¨allen ausreichend. Der Aufruf von findWay() erfolgt durch die Methode route() des Plug-In-Interfaces. Alternativ besteht die M¨ oglichkeit, das Interface durch eine eigene Klasse ohne Ableitung direkt zu erf¨ ullen. Dabei ist neben den Anforderungen der ererbten Interfaces14 nur die Methode route() zu implementieren. 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: ⎧ l 1 = 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 dem Kernel bekannt gemacht werden. Dazu wird ein entsprechender Eintrag in die Konfigurationsdatei vorgenommen. Der Konfigurationsmanager sorgt f¨ ur die Instanziierung des Plug-Ins und die Einbindung in den Kernel. Abbildung 7.13 zeigt das Zusammenspiel der einzelnen Komponenten: • Der Kernel stellt ein Plug-In-Interface bereit mit vordefinierten Methodennamen, deren Argumenten und R¨ uckgabewerten. 14

Plug-In-Interface und dessen Vorg¨ anger, das ConfigurationClientInterface.

290

7. Datenmodell eines WMS am Beispiel myWMS

Abbildung 7.13. Einbindung eines Plug-Ins in den Kernel u ¨ ber die Konfiguration

• Ein Plug-In muss dieses Interface erf¨ ullen. • Das Plug-In kann durch Vererbung erweitert werden. • Die Konfiguration entscheidet, welches Plug-In vom Kernel 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.8 Kommunikation

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

storageLocation:String unitLoadKods:String unitLoads:String

data:String commandArgument:String

command:String commandArgument:String

MfcStateRequest

MfcModifyRequest

DeviceWriteRequest

DeviceCommandRequest

291

Response errorCode:String

MfcTransportOrder orderNummer:String transportSource:String transportDestination:String unitLoadKods:String unitLoads:String

MfcTransportExecution orderNummer:String storageLocation:String unitLoadDifference:String

Abbildung 7.14. Diagramm der Kommunikationsklassen

7.8 Kommunikation Die M¨ oglichkeit einer Kommunikation zwischen myWMS und den unterlagerten Aktoren und Sensoren, respektive deren Zusammenfassung zu Subsystemen, ist grundlegender Bestandteil des Equipment-Kernels, der den Materialfluss steuert. Im Rahmen dieser Kommunikation sendet und empf¨angt der Kernel Objekte, w¨ ahrend die angeschlossenen Ger¨ate Bytestreams unterschiedlicher Formate empfangen und senden. Basisklasse aller Kommunikationsobjekte ist die Klasse ComObject, die grundlegende Methoden bereitstellt, wie etwa die Propertyverwaltung. Das Design-Pattern Property“ mit den beiden Methoden setProperty() und ”

292

7. Datenmodell eines WMS am Beispiel myWMS

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. 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.14 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. 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.4.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 interface Protocol { ... public byte[] eval(ComObject comObject, ...) throws ComException; public ComObject[] eval(byte[] bytes, ...); }

7.8 Kommunikation

293

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



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. 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, und sie stellen damit eine Herausforderung an die Softwaretechnik dar, die sich in den letzen Jahren - insbesondere durch den Einsatz der objektorientierten Techniken und geeigneter, anwendbarer Methoden und Werkzeuge - zu einer praktisch nutzbaren Ingenieursdisziplin entwickelt hat.

294

7. Datenmodell eines WMS am Beispiel myWMS

Es gilt in Zukunft, mit geeigneten Methoden und Standards unterschiedliche Anforderungen ohne eine individuelle Neuprogrammierung schnell, kosteng¨ unstig und in guter Qualit¨ at umzusetzten. Das in diesem Abschnitt vorgestellte objektorientierte Konzept stellt neben den auf relationalen Datenbanken basierenden WMS eine M¨ oglichkeit dar, dieses Ziel zu erreichen.

8. Auswahl und Einfu ¨ hrung von WMS

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

296

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¨aren Einbindung weiterer Personen, die zur Projektbearbeitung notwendig sind. Es ist f¨ ur die erfolgreiche und zeitgerechte Durchf¨ uhrung des WMS-Projektes notwendig, dass die Mitglieder des Projektteams f¨ ur die Projektarbeit von ihren sonstigen Aufgabenbereichen zumindest teilweise freigestellt werden. Weiter ist es erforderlich, dass das WMS-Projekt von der Gesch¨aftsleitung unterst¨ utzt wird und dass die Projektleitung die notwendige Befugnis besitzt, Entscheidungen zu treffen und durchzusetzen.

8.2 Projektmanagement/Qualit¨ atssicherungsmaßnahmen

297

Abbildung 8.1. Exemplarischer Umsetzungszeitplan

Zus¨ atzlich sind fr¨ uhzeitig Mitarbeiter der operativen Ebene (z. B. Kommissionierer) mit in das WMS-Projekt einzubeziehen. So wird gleich zu Beginn eine m¨ oglichst hohe Akzeptanz bei der Einf¨ uhrung neuer Abl¨aufe und ¨ Technologien erzielt und es werden Angste vor Ver¨anderungen genommen. Abschließend wird ein Umsetzungszeitplan erstellt, der die groben Meilensteine aufzeigt und den geplanten Zeitbedarf 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¨ahrend 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?

298

8. Auswahl und Einf¨ uhrung von WMS

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

8.3 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¨oser sind z. B.: • Einf¨ uhrung einer neuen Lagertechnik (z. B. automatisches Hochregallager) oder eines neuen Lagergutes (z. B. Gefahrgut) • Rationalisierung oder Erh¨ ohung der Leistungskennzahlen durch Einf¨ uhrung neuer Technologien (z. B. Erh¨ ohung der manuell erbrachten Kommissionierleistungen durch Einf¨ uhrung von Pick-To-Light) • Nutzung des Lagers f¨ ur verschiedene Eigent¨ umer der Ware (Mandantenf¨ ahigkeit) • Integration von zus¨ atzlichen wertsch¨ opfenden T¨atigkeiten im Lager (Value Added Logistics, VAL) • Vergabe der logistischen Leistungen an einen Dritten (Outsourcing) • ge¨ anderte Prozesse im Lager (z. B. Verbesserung der Qualit¨atssicherung und Dokumentation) ¨ • Anderung der Auftragsstruktur durch ver¨ andertes Bestellverhalten (z. B. stetig erh¨ ohte Kommissionierleistung durch kleinere Bestellmengen pro Auftrag, die nicht 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

299

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¨aftsprozesskette. Neben der reinen Aufnahme physischer T¨atigkeiten 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¨origen Gesch¨aftsprozesse 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.

300

8. Auswahl und Einf¨ uhrung von WMS

Beschreibung der Struktur der relevanten Daten Die Beschreibung der Struktur der relevanten Daten (z. B. Artikelnummer, Auftragsnummer, ¨ Charge) enth¨ alt einen vollst¨ andigen Uberblick u ¨ber den Aufbau aller wichtigen Daten, Objekte und Nummernkreise, wie z. B. Artikelstammdaten, Seriennummern, Ladehilfsmittelnummern etc. (s. Tabelle 2.13, S. 66). Das Ziel der Ist-Aufnahme ist somit die l¨ uckenlose Erfassung und Beschreibung aller das Lager 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 Proonnen Schwachstellen innerhalb der Gesch¨aftszesskettenanalyse4 (PKA) k¨ prozesse (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¨otigten Anforderungen ab (z. B. fehlende Unterst¨ utzung von ungeplanten Wareneing¨angen durch das WMS). Schnittstellen zu unter- und u ¨bergeordneten Systemen Nicht alle im Rahmen der Ist-Analyse aufgenommen Schnittstellen sind eindeutig beschrieben (z. B. unvollst¨ andige Beschreibung der ERP-Schnittstelle). Struktur relevanter Daten Die Struktur der vorhandenen Nummernkreise entspricht nicht mehr den tats¨ achlichen Anforderungen oder die ben¨otigten Nummernkreise sind im WMS nicht vorhanden (z. B. Bedarf einer Seriennummer zur Seriennummern-Verfolgung, Fehlen eines entsprechenden Datenfeldes im WMS).

4

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

8.3 Anforderungsdefinition

301

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¨osung des alten WMS sollten neben den Verbesserungspotenzialen unter anderem auch folgende Aspekte ber¨ ucksichtigt werden: • • • •

wirtschaftliche Situation des Unternehmens strategische Ausrichtung des Unternehmens Prognosen (z. B. gesamtwirtschaftliche oder 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¨oßtenteils auf den aus der Ist-Aufnahme gewonnenen Erkenntnissen. Die im Rahmen der Schwachstellen-Analyse aufgezeigten M¨ oglichkeiten werden aufgenommen und die Anforderung an das neue WMS unter Ber¨ ucksichtigung der Verbesserungspotenziale beschrieben. Unter Beachtung der bei der SchwachstellenAnalyse eingef¨ uhrten Klassifizierung ergeben sich die folgenden beispielhaften Anforderungen: Gesch¨ aftsprozesse und Informationsfluss im Lager Alle Gesch¨aftsprozesse, die das Lager betreffen, sind eindeutig definiert. Der Informationsfluss und die Verwendung von Dokumenten sind vollst¨andig beschrieben. Leistungsumfang des WMS Die Anforderungen an den Leistungsumfang (Funktionen und die dazugeh¨ origen Gesch¨ aftsprozesse und Abl¨aufe) des neuen WMS decken die tats¨ achlichen und geplanten Forderungen vollst¨andig ab. Schnittstellen zu unter- und u ¨ bergeordneten Systemen Der gesamte Datenaustausch des WMS wird dargestellt, alle beteiligten Fremdsysteme, die verwendeten Protokolle sowie die zu u ¨ bertragenden Daten werden aufgezeigt. Zudem ist eindeutig festgelegt, welches System welche Daten als Stammdaten h¨ alt. Struktur der relevanten Daten Alle ben¨ otigten Daten, Objekte und Nummernkreise sind vollst¨ andig 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.

302

8. Auswahl und Einf¨ uhrung von WMS

Tabelle 8.2. Sollkonzept: Beispielhafter Aufbau einer Lagerplatzdatei Nr.

Feld

Beschreibung

1.

Warehouse

identifiziert das Lager

2.

Area

identifiziert den Lagerort

3.

Aisle

identifiziert die Lagergasse

4.

Side

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

5.

X

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

6.

Y

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

7.

Z

Z-Koordinate des Regal-Fachs beginnend bei 1

8.

Quality

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

9.

MaxHeight

maximal nutzbare Höhe des Lagerplatzes in mm

10.

IDLocProp

berechnet das Lagerortskennzeichen des Platzes

11.

IDTSUTypeGroup

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

12.

IDTSUType

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

13.

Quantity

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

14.

ResQuantity

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

15.

RepQuantity

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

16.

IDLock

Sperrkennzeichen

17.

InvTS

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

18.

InvIDOperator

Mitarbeiter, der die letzte Inventur durchgeführt hat

19.

ZCrossingTS

ZeroCrossingTimeStamp – Nulldurchgangszeitpunkt

8.4 Erstellung der Ausschreibungsunterlagen

303

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)

304

8. Auswahl und Einf¨ uhrung von WMS

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

8.4 Erstellung der Ausschreibungsunterlagen

305

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¨azise zusammen. Adressaten Die u ¨ blichen Adressaten des Lastenheftes sind beim WMSAnbieter die Vertriebsmitarbeiter, der potenzielle Projektleiter sowie die Anwendungsspezialisten. Inhalt Auf einem ausreichend hohen Abstraktionsniveau wird die zu l¨osende Aufgabe, nicht die pr¨ azise Umsetzung, beschrieben (das WAS, nicht das WIE ). Form Eine eindeutige Nummerierung der einzelnen Anforderungen erleichtert z. B. sowohl beim Angebotsvergleich als auch bei der 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¨oglicht eine Beschr¨ ankung des Umfangs auf wenige Seiten. Die oben genannten Aspekte f¨ uhren zu folgendem beispielhaften Grobschema: A) Grundlegendes (kurze, nicht funktionale Beschreibung des Projektes): • Aufgabenstellung allgemeine gesch¨ aftsstrategische Umschreibung der Aufgabe (z. B. Abl¨ osung des vorhandenen WMS durch ein neues WMS) • Veranlassung Gr¨ unde und Notwendigkeiten, die zu der Aufgabe f¨ uhrten (z. B. unzureichende Funktionalit¨ at beim vorhandenen WMS) • Zielsetzung des Vorhabens generelle Beschreibung des Projektziels (z. B. funktionale Unterst¨ utzung aller T¨ atigkeiten im Lager durch ein neues WMS, wobei dieses System auch auf zuk¨ unftige Anforderungen vom Anwender parametrisierbar sein muss). Auch die geplanten Leistungskennzahlen werden hier aufgef¨ uhrt.

306

8. Auswahl und Einf¨ uhrung von WMS

• Projektumfeld kurze Zusammenfassung des Umfelds (z. B. Hauptsitz mit Produktion und Zwischenlager der Firma in Stadt A, Distributionszentren in den Orten B und C) B) Funktionsumfang (Beschreibung aller Funktionen): • Abgrenzung zu ERP und MFC und sonstiger Software Positionierung des WMS innerhalb der Systemlandschaft (z. B. Kundenauftr¨ age kommen ausschließlich vom u ¨bergeordneten ERP-System, die Gleichverteilung innerhalb der Gassen des Hochregals ist Aufgabe des Steuerungssystems Hochregal“) ” • Funktionen Aufz¨ ahlung und Beschreibung aller unverzichtbaren Funktionen und Leistungen (z. B. Chargenf¨ ahigkeit) • optionale Funktionen Aufz¨ ahlung und Beschreibung aller Funktionen und Leistungen, die f¨ ur den Betrieb des Lagers hilfreich w¨ aren, aber im Zweifelsfall (z. B. wegen steigender Kosten) nicht vorhanden sein m¨ ussen (z. B. OnlineSprachumschaltung, ohne sich abmelden und erneut am System anmelden zu m¨ ussen) • Sonderfunktionen Aufz¨ ahlung und Beschreibung aller Funktionen und Leistungen, die den gew¨ ohnlichen Betrieb eines Lagers nicht betreffen, aber f¨ ur die Administration des WMS erforderlich sind (z. B. Anpassungsf¨ahigkeit/Erweiterbarkeit: Der Benutzer kann ohne Unterst¨ utzung des WMS-Anbieters weitere Lager im WMS abbilden.) Neben der Darstellung der nicht gew¨ ohnlichen Funktionen z¨ahlt auch die Beschreibung der zu u bernehmenden Daten aus dem vorhandenen ¨ WMS zu den Sonderfunktionen. Bei der Erstellung des Lastenheftes sollten die folgenden Normen und Richtlinien Beachtung 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¨oßen) • VDI 3649 (Anwendung der Verf¨ ugbarkeitsrechnung f¨ ur F¨order- und Lagersysteme)

8.4 Erstellung der Ausschreibungsunterlagen

307

• 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

308

8. Auswahl und Einf¨ uhrung von WMS

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

8.5 Auftragsvergabe Vor der Auftragsvergabe stehen die Anbietervorauswahl, die daraus resultierende Versendung der Ausschreibungsunterlagen an einen qualifizierten Kreis von Anbietern, die Besuche der Anbieter beim Auftraggeber, der Angebotsvergleich und eine abschließende, Angebotspr¨asentation sowie die Besuche des Auftraggebers bei verschiedenen Referenzkunden der Anbieter. 8.5.1 Anbietervorauswahl Zur Vorbereitung der Anbieterauswahl und des Angebotsvergleichs ist es notwendig, die im Lastenheft beschriebenen Funktionen zu unterteilen: • Kriterien, die f¨ ur den reibungslosen Betriebsablauf im Lager unverzichtbar sind, z. B. Mandantenf¨ ahigkeit f¨ ur Logistikdienstleister, werden zu Ausschlusskriterien: Wird diese Funktion vom Produkt des WMS-Anbieters nicht erf¨ ullt, scheidet das Produkt beim Auswahlprozess sofort aus. • Kriterien, die den Betriebsablauf unterst¨ utzen, aber nicht unverzichtbar sind, werden zu so genannten optionalen Kriterien: F¨ ur den Betriebsablauf ist diese Funktion hilfreich, das Fehlen dieser Funktionalit¨at f¨ uhrt aber nicht automatisch zum Ausscheiden des WMS beim weiteren Auswahlprozess. Der Angebotsvergleich kann erheblich dadurch reduziert werden, dass nur Anbieter angeschrieben werden, die die Mindestanforderungen erf¨ ullen (die so genannte 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

309

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¨oglicht.

310

8. Auswahl und Einf¨ uhrung von WMS

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

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

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

usw.

Abbildung 8.6. Checkliste Angebotsvergleich

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

8.5 Auftragsvergabe

311

Angebot stellen. F¨ ur beide Seiten bietet die Besichtigung die Chance, sich pers¨ onlich kennenzulernen. Ziele der Standort-/Lagerbesichtigung sind die Beantwortung von Fragen zu den Ausschreibungsunterlagen, ein Gesp¨ ur f¨ ur das Lager des Auftraggebers zu bekommen sowie ein erstes Kennenlernen der m¨oglichen Vertragspartner. 8.5.3 Angebotsvergleich W¨ ahrend des folgenden Angebotvergleichs m¨ ussen die eingehenden Angebote in einem ersten Schritt einander gegen¨ ubergestellt werden. Ein solches Vorgehen ist notwendig, da die WMS-Anbieter nicht immer die Umsetzung der im Lastenheft beschriebenen Anforderungen anbieten, sondern zun¨achst h¨aufig 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.

312

8. Auswahl und Einf¨ uhrung von WMS

Anbieter n

Anbieter B

Anbieter A

Funktion/ Leistung

Ausschlusskriterium

Tabelle 8.4. Bewertung Angebote

Datendarstellung und Mengengerüst

...

warenbezogene Stammdaten

...

Artikelstammdaten

+

+

...

Verpackungseinheiten je Artikel

+

(+) 1

...

Warenarten-Tabelle

+

(-) 2

...

+

...

(-) 3

...

+

...

(+) 9

...

+

...

(+) 28

+

...

Buchung WMS

(+) 29

(+) 10

...

Zugang aus der Produktion

(+) 31

+

...

+

...

Stammdaten Lager- und Transportsysteme Stammdaten Lager

KO

Stammdaten Gabelstapler Ablauf Warenzugang Abwicklung Warenzugang Warenanlieferung

+

Einlagerplatzbestimmung Einlagerungstransport Warenzugangsbuchungen

Ablauf Kundenauftragsabwicklung Kommissionierung Auftragsfreigabe zur Kommissionierung manuell

+

automatisch ohne Restriktionen

(+) 32

automatisch mit Restriktionen

(+) 32

Bedienerführung Kommissionierung

(-) 34

+

...

Generierung Nachschubaufträge

(-) 34

+

...

+

...

Warenabgang

8.5 Auftragsvergabe

Anbieter B

+

+

...

Informations- und Berichtswesen

Anbieter n

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?

...

313

314

8. Auswahl und Einf¨ uhrung von WMS

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

8.6 Umsetzung

315

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¨ahnen sind in dieser Phase die begleitenden Controlling- und Qualit¨atssicherungsmaß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¨ahrend 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¨ost werden sollen. Damit enth¨ alt es die Leistungsbeschreibung des zu entwickelnden Systems und legt bei dieser Gelegenheit dar, wie und zumeist auch mit welchen Mitteln die Aufgabenstellung gel¨ ost werden soll. Vor diesem Hintergrund liefert das 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.

316

8. Auswahl und Einf¨ uhrung von WMS

Um Missverst¨ andnisse zu vermeiden, sollte ein gemeinsames Glossar angelegt werden. Zus¨ atzlich ist der Verweis auf entsprechende Ver¨offentlichungen hilfreich [58]. Unterschiedliche Deutungen der im Pflichtenheft beschriebenen Leistungen werden minimiert, eine exaktere Umsetzung wird erm¨oglicht. 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¨andig, 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¨atzlich wird die Umsetzung der im Lastenheft beschriebenen Anforderungen g¨anzlich, widerspruchsfrei und unmissverst¨ andlich beschrieben. Treten im Laufe der Realisierung nicht vorhersehbare neue Erkenntnisse auf, sollten diese mit Einverst¨ andnis von Auftraggeber und Auftragnehmer nachtr¨aglich zum Bestandteil des 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¨osung des vorhandenen WMS durch ein neues WMS – Veranlassung Gr¨ unde und Notwendigkeiten, die zu der Aufgabe f¨ uhrten; z. B. neue T¨ atigkeiten im Lager k¨ onnen durch das Alt-System nicht mehr abgedeckt werden. – Zielsetzung des Vorhabens generelle Beschreibung des Projektziels, z. B. funktionale Unterst¨ utzung aller T¨ atigkeiten im Lager durch ein neues WMS, wobei dieses System auch auf zuk¨ unftige Ereignisse vom Anwender parametrisierbar sein muss. Auch die zu realisierenden Leistungskennzahlen sollten hier aufgef¨ uhrt werden. – Projektumfeld kurze Zusammenfassung des Umfelds, z. B. Hauptsitz mit Produktion und Zwischenlager der Firma in Stadt A, Distributionszentren in den Orten B und C

8.6 Umsetzung

•

• • •

317

– Zeitrahmen Nennung aller Meilensteine mit zeitlichen Rahmendaten Funktionsumfang (Beschreibung aller Funktionen) – Abgrenzung zu ERP und MFC und sonstiger Software: Positionierung des WMS innerhalb der Systemlandschaft – Funktionen: Aufz¨ ahlung und Beschreibung aller Funktionen und Leistungen – Schnittstellen: Beschreibung der ben¨ otigten Schnittstellen und Protokolle. – Daten¨ ubernahme: Art und Weise der Daten¨ ubernahme mit Angabe der zu u autert. ¨ bernehmenden Daten werden erl¨ Schulung (Zeitpunkt, Ort und Umfang sowie Zielgruppe der einzelnen Schulungsmaßnahmen werden benannt.) Inbetriebnahme (Zeitpunkt und Ablauf der Inbetriebnahme werden beschrieben.) Abnahme (Form und Umfang der Abnahme mit pr¨azise 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¨atigkeiten und Funktionen) inklusive ihrer Terminierung, die zur Erf¨ ullung des Projektziels notwendig sind. Das Pflichtenheft wird durch den Auftraggeber genehmigt. Es ist m¨ oglich, 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

318

8. Auswahl und Einf¨ uhrung von WMS

¨ Auftraggeber zu kommunizieren. M¨ ogliche Gr¨ unde f¨ ur Anderungen k¨onnen neue Erkenntnisse (beispielsweise hat es sich als effizienter erwiesen, den geplanten Ablauf umzugestalten), fehlende Punkte im Lasten- und Pflichtenheft sowie neue Anforderung (z. B. werden weitere Formulare und zus¨atzliche statistische Informationsabfragen ben¨ otigt) sein. Dokumentiert werden sollten unter anderem folgende Aspekte: • Welche Leistung/Funktion f¨ allt weg/kommt neu dazu/¨andert sich? ¨ • Welche kostenwirksamen Anderungen sind damit verbunden? • Welche zeitlichen Auswirkungen (Terminierung der Meilensteine des Projektes) ergeben sich hieraus? ¨ • Welche Priorit¨ at hat die Anderung? Muss sie vor der Inbetriebnahme er¨ folgt sein? Wenn die Anderung sp¨ ater erfolgen kann, bis wann muss sie sp¨ atestens erfolgen? ¨ Durch die Dokumentation der Anderungen werden m¨ogliche Unstimmigkeiten w¨ ahrend der Abnahme vermieden, da die zwangsl¨aufigen 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¨at.

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¨ande (z. B. Artikel-Stammdaten, Lagerbewegungsprotokoll) u ¨ bernommen werden. Hierbei kann es erforderlich werden, z. B. spezielle Import-Programme zu entwickeln. Generell gilt: Je ¨ gr¨ oßer der Umfang der Datenbest¨ ande ist, desto eher sollte die Ubernahme beginnen (s. [4], S. 1088). W¨ ahrend der Laborphase wird das neue WMS unter Laborbedingungen, aber mit realen Daten getestet: Die Auftr¨ age, die das WMS erteilt, werden beispielsweise nicht tats¨ achlich vom Kommissionierer ausgef¨ uhrt, sondern die Bearbeitung wird datentechnisch simuliert (z. B. wird die kommissionierte Menge durch ein Testprogramm direkt in die Datenbank geschrieben). Die Daten, die verwendet werden, k¨ onnen hingegen tagesaktuell geplant oder historisch sein.

8.7 Inbetriebnahme

319

¨ Die Uberpr¨ ufung auf Korrektheit erfolgt bei tagesaktuellen Daten gegen das Alt-System, bei historischen Daten gegen die Alt-Daten des Alt-Systems. Um ein WMS bereits unter Laborbedingungen realit¨atsnah zu testen, werden Simulationen eingesetzt. Dies k¨ onnen spezielle Programme sein, die z. B. die Auftragslast f¨ ur ein Kommissioniersystem an einer Datenschnittstelle zur Verf¨ ugung stellen. Um das Zeitverhalten des Materialflusssystems nachzubilden, werden Simulationsprogramme verwendet, die eine Leistungsbestimmung und einen Test der systemspezifischen Heuristiken bei vorgegebener Auftragslast erm¨ oglichen. Derartigen Materialflusssimulatoren“ werden bei ”¨ gr¨ oß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¨osenden WMS ausgef¨ uhrt werden. Ist festzustellen, dass die Ergebnisse sowohl im alten als auch im neuen WMS identisch sind, wird das neue WMS federf¨ uhrend. Nach einer festzulegenden Zeit ohne St¨orungen kann das alte WMS abgeschaltet werden. Der Vorteil dieser Vorgehensweise liegt in der erh¨ ohten Sicherheit, die sich daraus ergibt, dass beim Auftreten von Fehlern sofort auf das alte WMS zur¨ 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¨ohnlich 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¨orungen sind zu protokollieren und anschließend zu beheben. Sobald das alte WMS vollst¨ andig abgeschaltet ist und das neue WMS alle Funktionen u ¨bernommen hat, beginnt der Produktivbetrieb des neuen WMS.

320

8. Auswahl und Einf¨ uhrung von WMS

8.7.3 Schulungsmaßnahmen Parallel zur Inbetriebnahme erfolgt die Schulung der Benutzer am System. Hierbei wird unterschieden zwischen der • Schulung aller potenziellen Benutzer des WMS durch den Auftragnehmer und • der Schulung der so genannten Trainer, die dann ihrerseits ihre Kollegen schulen (Train the Trainer). Wichtig ist eine fr¨ uhzeitige und ausreichende Schulung, die eine Freistellung der teilnehmenden Mitarbeiter voraussetzt. Eine Schulung, die beispielsweise nach Feierabend oder am Wochenende durchgef¨ uhrt wird, kann bereits im Vorfeld die Bereitschaft zur Akzeptanz des neuen Systems schm¨alern. Am Ende der Projektphase Inbetriebnahme steht die Verwaltung und Steuerung des Lagers durch geschulte Mitarbeiter mit Hilfe des neuen WMS. Dabei werden die im Lasten- und 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¨agigen) zusammenh¨ angenden Betrieb unter Realbedingungen und Volllast. Eine Unterbrechung des Leistungsbetriebs im Zusammenhang mit St¨orungen bedingt eine Wiederholung des Tests. Im Rahmen der funktionalen Leistungstests wird zun¨achst das Vorhandensein aller im Pflichtenheft beschriebenen Funktionen u uft. Anschlie¨ berpr¨ ßend erfolgt die Einzelpr¨ ufung der ordnungsgem¨aßen Arbeitsweise jeder

8.8 Abnahme

321

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¨age) sowie die Bearbeitungsdauer f¨ ur einen Report (z. B. Artikel pro Mandant im Monat). Zus¨ atzlich sind die Antwortzeiten an den externen/mobilen Terminals (z. B. Stapler-Terminals) abzunehmen. Zu beachten ist hierbei die Richtlinie VDI 3649. ¨ 8.8.2 Simulation von St¨ orf¨ allen / Uberpr¨ ufung von Notfallstrategien Bei der Simulation von St¨ orf¨ allen werden Ausnahmesituationen nachgebildet, die im 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¨oglich aufrechterhalten. Eine Datensynchronisation nach Behebung der St¨ orung ist zwingend erforderlich: • Auslagerungen/Einlagerungen, die nur auf Papier festgehalten wurden, m¨ ussen in das System eingepflegt werden k¨ onnen. • 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.

322

8. Auswahl und Einf¨ uhrung von WMS

8.8.3 Verf¨ ugbarkeit Die technische Verf¨ ugbarkeit beschreibt die Wahrscheinlichkeit, ein Element oder ein System zu einem vorgegebenen Zeitpunkt in einem funktionsf¨ahigen Zustand 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¨ahigkeit zu erhalten. 8.8.4 Formale Abnahme W¨ ahrend der Abnahme werden die einzelnen Positionen nacheinander abgenommen und vom Auftraggeber und Auftragnehmer unterzeichnet. Jede Erf¨ ullung, jeder Fehler bzw. jede Abweichung wird protokolliert. Bei Fehlern bzw. Abweichungen wird diskutiert, um welche Fehlerklasse es sich handelt, wobei die folgenden vier Fehlerklassen unterschieden werden: Klasse 1 Das Lager kann aufgrund des Fehlers bzw. der funktionalen Abweichung vom Pflichtenheft nicht betrieben werden (z. B. die Sicherheitslichtschranken oder die Ansteuerung der Regalbedienger¨ate funktionieren nicht).

8.8 Abnahme

323

Klasse 2 F¨ ur einen Fehler bzw. eine Abweichung existiert nur ein aufw¨andiges alternatives Vorgehen (z. B. die Scan-Funktion am Wareneingang funktioniert nicht, jeder Artikel muss daher manuell erfasst werden). Klasse 3 F¨ ur einen Fehler bzw. eine Abweichung besteht ein akzeptables alternatives Vorgehen (z. B. bei der t¨ aglich zweimal durchzuf¨ uhrenden, automatischen Auftragsannahme vom Host werden die Daten gelegentlich nicht vom WMS erfasst, der Benutzer muss daher die Auftragsannahme pr¨ ufen und gegebenenfalls neu veranlassen). Klasse 4 Ein Fehler bzw. eine Abweichung stellt keine Einschr¨ankung hinsichtlich der Nutzung des Systems dar (z. B. das Druckformat f¨ ur den Begleitschein im Warenausgang stimmt nicht exakt mit der 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¨agt (wenn bspw. bis zur Behebung des Fehlers zus¨atzliches Personal eingestellt werden muss). Die Entscheidung u ¨ ber eine Teilabnahme mit Auflagen und die Produktivsetzung des WMS kann nur fallweise 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¨at, mit der der Fehler behoben werden muss. Die endg¨ ultige offizielle Abnahme des Gesamtgewerks gem¨aß § 12 VOB Teil B und VDMA erfolgt nach einem einwandfreien, unbeanstandeten Leistungstest, der sp¨ atestens drei Monate nach Inbetriebnahme durchgef¨ uhrt ¨ werden muss. Vor der Abnahme sind die im Ubergabeprotokoll bezeichneangel zu beseitigen. Die Abnahme ist vom Auftragnehmer schriftlich ten M¨ zu beantragen. Die Abnahme erfolgt ausschließlich durch eine schriftliche Bescheinigung des Auftraggebers. Sie kann weder durch eine fr¨ uhere Benutzung, Inbetriebnahme oder beh¨ ordliche Abnahme noch durch die Mitteilung des Auftragnehmers u ¨ ber die Fertigstellung ersetzt werden.

324

8. Auswahl und Einf¨ uhrung von WMS

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¨arker steigt der Anteil der Kosten f¨ ur das Softwareengineering an den Gesamt¨ projektkosten. Es ist keine Seltenheit, dass die Kosten f¨ ur Anderungen im ERP-System h¨ oher ausfallen als die 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

326

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¨asentation ¨ der Daten wird XML und zur Ubertragung der Nachrichten Internetprotokolle wie HTTP genutzt. SOAP erlebte in der Weiterentwicklung mit Hilfe von Web Services bzw. Service-Oriented Architecture (SOA) eine Renaissance, wobei ¨ ahnlich wie bei Jini dynamisch Dienste registriert und gesucht werden k¨ onnen. Jini verwaltet die Services im jeweiligen lokalen Subnetz, w¨ ahrend Web Service mit Hilfe des Universal Discovery and Description Interface (UDDI) Dienste im Internet nutzen oder anbieten kann, solange sie auf SOAP-Funktionalit¨ at zur¨ uckgreifen. Unter SOA versteht man einen dienstorientierten und verteilten Architekturansatz. Als Services bzw. Dienste werden bereitgestellte Funktionalit¨aten gesehen, die u ¨ber Schnittstellen angesprochen werden. Die Kernidee ist es, durch die lose Kopplung von einfachen, unabh¨angigen Diensten komplexe Dienste aufzubauen. Dabei werden aufw¨ andige Prozesse durch die Komposition bzw. Aneinanderreihung von Services abgebildet. Besonders Web Services, die auf 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¨aftigen und zus¨atzlich noch Prozesslogik abbilden, werden sie h¨ aufig auch als Enterprise Application

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

327

Business

Business Activity

Activity

Monitoring

Services

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¨aftsprozesse. Anhand verschiedener Produkte sollen nachfolgend Beispiele f¨ ur aktuelle Middleware-Systeme aufgezeigt werden. 9.1.1 Microsoft Eine Microsoft-Middleware zur Enterprise Application Integration ist der so genannte Microsoft BizTalk Server . Aufsetzend auf .NET bietet der Microsoft BizTalk Server standardisierte Schnittstellen u ¨ ber Web Services, die durch Transformationsregeln die eingehenden Objekte in das Format des Zielsystems konvertieren. Neben Web Services k¨ onnen andere Softwareapplikationen auch u ¨ ber so genannte Adapter angebunden werden. Der BizTalk Server versteht sich dabei als Hub und steht damit in Konkurrenz zu Peerto-Peer-Systemen. Microsoft und die hier nicht beschriebenen Middleware-

328

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¨aftigt. Kommt sie nicht als

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

329

mySAP™ Business Suite Composites Rechnungsprüfung

...

...

...

SAP NetWeaver™

APO

ERP

CRM

FI

Komponenten

Abbildung 9.2. SAP Enterprise Application Integration (EAI)

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

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

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

330

9. Anhang

SAP NetWeaver™ NetWeaver People Integration Multichannel Collaboration

Knowledge Management

Master Data Management

Process Integration Integration Broker

Business Process Management

Application Platform J2EE Intelligence

Websphere

Business Intelligence

Microsoft®.net

Life-Cycle Management

Information Integration

Composite-Application Framework

...

Portal

ABAP Management

DB and OS Abstraction

Abbildung 9.3. SAP Middleware NetWeaver

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

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

331

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

Development Tools SOA Tools, Framework

Systems Management System Application Services

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

Directory Provisioning, Single Sign-on, Identity Administration

Grid Infrastructure Cluster, Metadata, Registry, Security

Abbildung 9.4. Oracle Middleware Fusion

tausch mit anderen Middleware-Produkten zur EAI statt. Hier gibt es z. B. Konnektoren zu SAP NetWeaver oder IBM WebSphere. Zur Kommunikation dient der Enterprise Service Bus (ESB), der die Datenstrukturen (Messages) des Senders ggf. so konvertiert, dass diese vom Empf¨anger verstanden und verarbeitet werden k¨ onnen. Auch das Verwalten von Gesch¨aftsabl¨aufen Business Process Management (BPM) und das Business Activity Monitoring (BAM) zum Betrachten der Gesch¨ aftvorf¨ alle, um auf der Basis der erhaltenen Informationen Entscheidungen zu 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¨aftsabl¨aufen und Entscheidungen.

332

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

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

333

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¨onnen, 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

334

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¨ aftsbedingungen 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¨ asentationen u ¨ ber zeitrelevante Gesch¨aftsprozesse in Organisationen Business Application Programming Interface = eine standardisierte Programmierschnittstelle der SAP-Business-Objekte Bundesverband Materialwirtschaft, Einkauf und Logistik = ein standardisiertes Austauschformat f¨ ur Katalogdaten Business Objects Berkeley Open Infrastructure for Network Computing = eine Softwareplattform f¨ ur verteiltes Rechnen Business-Process-Management = Managementprozesse und Software, die sich mit der Automatisierung und Optimierung von Gesch¨ aftsprozessen auseinandersetzen Composite Application Platform Suite Common Object Request Broker Architecture = objektorientierte Middleware, die plattform¨ ubergreifende Protokolle und Dienste definiert Carrier Sense Multiple Access/Collision Detection = Medienzugriffsverfahren, das den Zugriff verschiedener Stationen auf ein ¨ gemeinsames Ubertragungsmedium im Zeitmultiplexverfahren beschreibt Data Definition Language Datentr¨ ageraustausch-Verfahren = ein Verfahren im bargeldlosen Zahlungsverkehr

336

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¨ aftsprozessen Elektronische Datenverarbeitung Enterprise Resource Planning Electronic Data Interchange = Format zum Austausch von Daten Electronic Data Interchange For Administration, Commerce and Transport = ein branchen¨ ubergreifender internationaler Standard f¨ ur das Format elektronischer Daten im Gesch¨aftsverkehr Elektroh¨ angebahn Elektropalettenbahn Europalette Enterprise Service Bus = die zentrale Aufgabe eines ESB ist der Austausch von Daten zwischen IT-Systemen Elektrotragbahn First-In-First-Out“ = Auslagerungsreihenfolge des gleichen Ar” tikels nach dem Einlagerungsdatum (¨altester Artikel zuerst) Fahrerloses Transportfahrzeug File Transfer Protocol = ein Netzwerkprotokoll zur Datei¨ ubertragung Fahrerloses Transportsystem Hochregallager Hypertext Markup Language = standardisierte Sprache des World Wide Web ¨ Hypertext Transfer Protocol = ein Protokoll zur Ubertragung von Daten u ¨ber ein Netzwerk 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

Abk¨ urzungsverzeichnis

JNDI

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

SOA SOAP

337

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¨ atssicherung Quertransportwagen Querverteilwagen Produktionsplanungs- und Steuerungssystem Regalbedienger¨ at 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

338

Abk¨ urzungsverzeichnis

SPS

SQL TCP/IP TSU TSP TUL UDDI UDP UML

URL USV WA WAN WAS WCS WE WMS WSDL WWS XI

XML XSD XML-RPC

Speicherprogrammierbare Steuerung zur Steuerung der Bewegungen der RBG und der F¨ orderanlagen. Die SPS ist mit dem MFR online verbunden. Structured Query Language Transmission Control Program/Internet Protocol Transport Unit Travelling-Salesman-Problem Transport, Umschlag und Lagerung Universal Description, Discovery and Integration = ein Verzeichnisdienst User Datagram Protocol = ein verbindungsloses Netzprotokoll 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: Cross Docking zwischen Handel und Industrie – Eine ECR-Anwendungsempfehlung der ECR-Initiativen Deutsch¨ land und Osterreich. 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 ¨ uber die Abnahme und Verf¨ ugbarkeit von Anlagen mit 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

340

Literaturverzeichnis

[18] Gudehus, Timm: Logistik: Grundlagen, Strategien, Anwendungen. SpringerVerlag, Berlin Heidelberg, 1999 [19] Hafner, Sigrid (Hrsg.): Industrielle Anwendung evolution¨ arer Algorithmen. R. Oldenbourg Verlag M¨ unchen, 1998 [20] Hein, Mathias: TCP/IP — Internet-Protokolle im praktischen Einsatz. 4. 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: Logistiksysteme f¨ ur Gewichts- und Volumenerfassung [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

Literaturverzeichnis

341

[42] Pleßmann, K.W.: Handbuch zum VDI-Bildungswerk GmbH Seminar: Lasten- und Pflichtenheft als Vorbereitung und Voraussetzung der Entwicklung von Software. Stuttgart, Oktober 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 ¨ [63] VDI 2326 – Ubersichtsbl¨ atter Stetigf¨ orderer – Gurtf¨ orderer f¨ ur St¨ uckgut. Verein 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

342

Literaturverzeichnis

[66] VDI 3312 – Sortieren im logistischen Prozeß – Entwurf. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, Dezember 1998 [67] VDI 3581 – Verf¨ ugbarkeit von Transport- und Lageranlagen sowie deren Teilsysteme und Elemente. Verein Deutscher Ingenieure, Beuth-Verlag, Berlin, Dezember 2004 [68] VDI 3586 – Flurf¨ orderzeuge – 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, 329 Ableitung, 233 Abnahme, 320 – formale, 322 adaptive Hilfesysteme, 190 Adressraum, virtueller, 198 Aggregation, 235 Akteur, 237 aktives Warten, 196 Anbieterauswahl, 314 Anbietervorauswahl, 308 Anforderungsanalyse, 237 Angebots – pr¨ asentation, 314 – vergleich, 311 Anwendungsfalldiagramm, 237 Application Link Enabling (ALE), 328 Application Service Providing, 71 Application Services, 328 Application-Server, 245, 329 Applikation, 195 Architektur, 221 Archivierung, 175 Artificial Intelligence, 127 ASP, 71 Assembler, 204 Assoziation, 177, 235 Auftragsdisposition, 125, 129, 130, 144 Auftragserfassung, 43 Auftragsvergabe, 308 Auftragszusammenf¨ uhrung, 51 Auskunftsf¨ ahigkeit, 126, 146 Auslagerung, 32 Auslagerungsdatei, 199 Ausschreibung, 303

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

344

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, 331 Bytecode, 206 Client, 169 Client-Server, 226 Cold Standby, 228 Commit, 174 Communication Services, 328 Compiler, 204 Compilezeit, 205 Composite Application Platform Suite (CAPS), 333 CORBA, 252 CPFR, 17 Cross Docking, 29, 69 Customizing, 317 Dateisystem, 175 Datenbank, 177 Datenbankschema, 179 DBMS, 182 DDL, 180 Destruktor, 233 dirty read, 174 Dispatching, 59, 130, 148 Distribution Services, 328 DML, 180 DNS, 170 Doppelspiele, 132, 135 DTAUS, 241 Durchlagerung, 29 E-Commerce, 18 E-Logistics, 18 ECR, 17 Edgeware, 326 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 Entity-Relationship-Diagramm, 178 EPB, 110 Equipment Manager, 273 Er¨ offnungsverfahren, 141, 152 ERP, 9 ETB, 110 Exchange Infrastructure (XI), 328 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, 320 Gateway, 167 Gesch¨ aftslogik, 247 Gesch¨ aftsobjekt, 274 Gesch¨ aftsprozessaufnahme, 299 Grammatiksymbol, 207 Greifzeit, 40 Grid Infrastructure, 329 Gruppierung, 57 Hardware – Memory, 192 – MMU, 192 Hot Standby, 228 HRL, 80 HTTP, 172 Hub, 166 I-Punkt, 29 IANA, 168 IBM WebSphere, 332

Sachverzeichnis IBM WebSphere Application-Server (WAS), 332 Identit¨ atskontrolle, 29 IEEE802.11, 161 IEEE802.3, 161 IEEE802.4, 161 IEEE802.5, 161 IEEE802.6, 161 Image-Backup, 185 Implementierung, 317 Inbetriebnahme, 318 – Laborphase, 318 Index, 177 indexsequenziell, 176 Individualprogrammierung, 317 Informationsfluss, 299 Instanz, 231 Integration & Business Management, 330 Integration Broker, 328 Intermediate Documents (IDocs), 328 Interpreter, 205 Interrupt, 194, 199 Inventory Manager, 273 Inventur, 62 IP, 160 ISO/OSI-Referenzmodell, 158 Ist-Analyse, 299 Ist-Aufnahme, 298 J2EE, 245 Java Platform Enterprise Edition, 245 Jini, 253 join, 181 Journalfile, 174 Journaling, 174, 184 Karusselllager, 87 Kennzahl, 65, 303 Kennzahlen – Logistik-, 68 KEP, 18 Klasse, 231 Klassendiagramm, 237 Kollaborative Gesch¨ aftsprozesse, 327 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, 305 Latenzzeit, 165 Laufzeit, 205 Layer, siehe Schicht, 224 Leistungstest, 320 Leistungsverzeichnis, 303 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, 299, 300 Mengenverwaltung, 56 Messaging, 244 Methode, 125, 231 MFR, 9 Microsoft BizTalk Server, 327 Middleware, 240 mime, 172 MIS, 9

345

346

Sachverzeichnis

Mischpalette, 28 Modularisierung, 223 Monolithische Architektur, 222 Multiplex ¨ – Ubertragungskanal, 163, 165 – Prozessor, 196 – Speicher, 198 Multipurpose Internet Mail Extensions, 172 Multiuser, 192 myWMS – Clearing, 278 – Equipment Manager, 273 – Inventory Manager, 273 – Kernel, 271 – Listener, 275 – Location Manager, 273 – Panel, 278 – Plug-In, 271 n-Tier, 224 Nameserver, 170 Nebenl¨ aufigkeit, 195 NSP, 159 NTP, 170 Nummernkreis, 300 Objekt, 231 objektrelationales Mapping, 246 ODBC, 182 ODBS, 182 Open-Source, 204 Operations Research, 127 Outsourcing, 17 Pack-Programm, 186 Paket, 159 Parallelbetrieb, 319 Parametrisierung, 317 passives Warten, 196 Paternosterregal, 86 Persistierung, 173 Person-zur-Ware, 37 Pfad, 175 Pflichtenheft, 315 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, 295 Projektion, 181 Property, 275 Protokoll, 240 Protokollheader, 158 Protokollstack, 158 Prozesskettenanalyse, 300 Put-to-Light, 50 PzW, 37 QTW, 106 Quellprogramm, 204 Queues, 244 Quittierung, 46 RDBS, 177 Realisierung, 317 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), 328 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 Rollpaletten, 89 Router, 167

Sachverzeichnis RPC, 252 RSA-Verfahren, 217 SAP NetWeaver, 328 Scheduler, 196 Scheduling, 59, 129, 144 Schedulingverfahren, 196 Schicht, 158 Schichtenmodell, 158 Schichtung, 224 Schnittstelle, 299 Schulung, 320 Schutzmechanismus, 177 Schwachstellenanalyse, 300 SCM, 16 Selektion, 181 sequenziell, 175 Seriennummer, 26 Server, 169 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, 301 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, 321 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, 319 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, 320, 322 Verkaufsverpackung, 20 Verpackung, 19 Verschiebewagen, 106 Verschl¨ usselung, 177 Verschl¨ usselungsverfahren – symmetrisch, 215 – unsymmetrisch, 216 Verteilsystem, 113

347

348

Sachverzeichnis

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 WzP, 37 XML – DTD, 211 – Schema, 211 Zeilenlager – Boden-, 75 – Regal-, 76 Zeitscheibe, 196 Zielfunktion, 127, 149 Zustandsdiagramm, 239