Durchblick im Lager

Dipl.-Ing. Martin Leiacker

In den letzten Jahren wurden viele Optimierungen im Lagerlogistikbereich durchgeführt. Dazu zählen beispielsweise immer präzisere Planungen, um die Lagermenge und Lagerzeit für Rohstoffe, Halbwaren und Fertigprodukte zu reduzieren. Um den Platz optimal ausnutzen zu können, stellen viele Produktionsbetriebe von einem statischen zu einem chaotischen Lager um. Durch immer bessere Planungen kann in den meisten Fällen genau vorhergesagt werden, wann und auf welchen Lagerplatz neue Ware eingelagert werden muß, oder wann eine Auslieferung vorzunehmen ist.

Diese gestiegenen Anforderungen haben dazu geführt, daß aktuelle Daten über den Zustand eines Lagers und über anstehende Bewegungen immer wichtiger geworden sind. Damit genaue Vorgaben gemacht werden können, ist der Informationsfluß zu Planungs- und Verwaltungssystemen ebenso wichtig wie die Information aus diesen Systemen für das Lager. Heute müssen fast alle Abteilungen eines Betriebs sofort über Lagerbewegungen und vor allem über Abweichungen von den Vorgaben informiert werden. Zum Beispiel kann nach der Kommissionierung direkt die Lieferschein- und Rechnungserstellung veranlaßt werden. Abweichungen gehen so ohne Mehraufwand direkt in die nachgeschalteten Prozesse ein.

Die beschriebenen Anforderungen an ein Lager lassen sich nur noch mit spezialisierten DV-Systemen realisieren. Es hat sich gezeigt, daß – unternehmensspezifische Bedürfnisse ausgenommen – nahezu alle Firmen an die DV-Systeme in der Lagerlogistik im wesentlichen die gleichen Anforderungen stellen. Auch wenn die Arbeitsabläufe und die daraus resultierenden Prozesse häufig sehr ähnlich waren, mußte für jedes Unternehmen ein individuelles DV-System entwickelt werden. Es entstanden immer mehr neue Programme, die relativ hohe Entwicklungskosten verursachten und anschließend in den Unternehmen lange Amortisierungszeiten benötigten.

Einerseits sind in allen Lägern ähnliche Aufgaben zu lösen, wie die eindeutige Identifikation von Waren, ihre Zuordnung zu Aufträgen, die bessere Ausnutzung des Lagerplatzes, die fehlerfreie und optimale Weiterleitung der Ware oder die Realisierung eines zuverlässigen Informationsflusses zwischen den verschiedenen Abteilungen. Andererseits ist jedes Lager auch sehr individuell. Dies liegt zum Teil an den Waren, die bewegt werden müssen oder an den Schnittstellen zu anderen Systemen. Beispielsweise unterscheiden sich die Informationen bezüglich einer Palette mit Schrauben deutlich von denen, die notwendig sind zur Beschreibung einer Arzneimittelpackung. Die unterschiedlichen Informationsinhalte sollen durch folgende Stichworte verdeutlicht werden: Schüttgut/Stückware, Chargenreinheit oder Anforderungen an den Lagerplatz. Eine wesentliche Anforderung an ein neues DV-System im Logistikbereich ist, daß es sich problemlos an wechselnde Produkte, vorhandene Geräte bzw. Anlagen sowie an unterschiedliche Schnittstellen und historisch gewachsene IT-Strukturen anpassen läßt.

Objektorientierte Entwicklungsansätze erleichtern die Realisierung von Programmfunktionen. Dazu müssen die Funktionen, die zur Beschreibung eines Prozesses notwendig sind, einmal in einer Standardform entwickelt werden. Weichen einzelne Funktionen von diesem Standard ab, lassen sich durch Vererbung und Überdefinition die neuen Anforderungen implementieren. In gewisser Weise ist mit diesem objektorientierten Ansatz auch die Portierung von Funktionen auf unterschiedliche Hardwarekomponenten möglich. Voraussetzung ist natürlich, daß die Geräte die selbe Programmiersprache „verstehen“. Verschiedene mobile Datenerfassungsgeräte (MDE) können also mit Programmen ausgestattet werden, die auf einer Objektdefinition basieren. Dieser Schritt zur Vereinheitlichung von Systemen reduziert in erster Linie nur den Entwicklungsaufwand für neue Programme. Da die Änderung einer Objektdefinition einen modifizierten Sourcecode bedeutet, ist letztlich ein neues ausführbares Programm erforderlich.

Des weiteren müssen auch die Datenstrukturen mit in die Überlegungen einbezogen werden. Für jedes etwas komplexere Projekt nutzt man ein Datenbanksystem. Die Datenbank stellt dabei im Normalfall alle Daten für die Prozesse zur Verfügung. Sie ist somit auch das Verbindungsstück zwischen verschiedenen Prozessen. Daten, die zum Beispiel im Wareneingang erfaßt wurden, speichert man anschließend in einer Datenbank, um sie später für einen automatischen Einlagerungsprozeß zu nutzen.

Die zentrale Position der Datenbank kann auch für die Flexibilisierung von Prozessen genutzt werden. Basis für jede Datenbank sollte ein Entity-Relationship-Model (ER-Diagram) sein. In diesem Diagramm werden alle Datenfelder und die Beziehungen untereinander beschrieben. Mit entsprechenden Tools läßt sich aus dem Design des ER-Diagrammes die Datenbank direkt generieren. Dazu erzeugt man aus dem Designprogramm ein DDL-Script (Data Definition Language). Auf diese Weise ist es möglich, anwenderspezifische Anforderungen in der Designphase zu berücksichtigen und automatisch in die Erstellung der Datenbank einfließen zu lassen. Vor diesem Hintergrund lag der Schritt nahe, die beiden Optimierungsansätze objektorientierte Programmierung und Datenbankdesign mit ER-Tools zu kombinieren. Als Ergebnis ist das Konzept entstanden, mit dem sehr flexible Systeme entwickelt werden können.

Durch die Analyse der bisher realisierten Projekte ist eine große Basis für den Anforderungskatalog an ein Standardsystem entstanden. Diese Anforderungen werden mit den oben beschriebenen Methoden in einer flexiblen Standardsoftware realisiert. Sie können so in einem breiten Rahmen durch Konfigurationsparameter aus dem Datenbankmodell an die individuellen Anforderungen der Anwender angepaßt werden. Für den Anwender ergeben sich daraus kürzere Entwicklungszeiten für die Standardanforderungen im Lagersteuerungsbereich.

Das standardisierte Lagersteuerungssystem Stradivari besteht aus Komponenten, die sich bereits in der Umsetzung von Lagerprozessen bewährt haben. Das Spektrum reicht hier von der automatischen Identifikation durch Barcodes über spezielle mobile Datenerfassungsterminals mit der entsprechenden Software bis hin zu Standard-Frontend-Applikationen die unter Windows NT realisiert sind. Das Aussehen und die Funktionalität der Windows-NT-Programme wird dabei direkt durch die im Hintergrund liegende Datenbank bzw. indirekt durch das Datenmodell beeinflußt. Dies bedeutet, daß die Länge eines Eingabefeldes von der Länge des entsprechenden Datenbankfeldes abhängt. Gleichermaßen werden auch Eingabeprüfungen direkt vom Datentyp abhängig gemacht.

Wenn für eine Implementierung beispielsweise ein Datenfeld mit zehn Stellen numerisch definiert ist, kann der Anwender maximal 10 Zahlen eingeben. Mehr oder andere Zeichen werden in diesem Fall nicht akzeptiert. Das gleiche Datenfeld kann man bei einer anderen Implementierung 20stellig alphanumerisch definieren. Die Änderung der Eingabefeldlänge und die Eingabeprüfung wird gemäß der Datenbankdefinition angepaßt. Diese Vorgehensweise entspricht der Umsetzung eines aktiven Data Dictionary, da ohne Änderungen an der Software unterschiedliche Funktionalitäten implementiert werden können. Die Software wurde mit Microsoft Visual C++ und der MFC-Klassenbibliothek realisiert.

Um diese Möglichkeiten auch für die mobilen Datenerfassungsterminals nutzen zu können, erstellt man zuerst mit Hilfe des in Stradivari enthaltenen Konfigurationsprogramms das individuelle Datenmodell. Anschließend erfolgt die Konfiguration der Klassen für die MDE-Programme. Hierbei ist zwar immer noch ein Compilier-Vorgang erforderlich, der sich nicht vermeiden läßt, da die MDEs nicht immer auf die Datenbank zugreifen können.

Durch diese Realisierungsform ist das Lagersteuerungssystem Stradivari in der Lage, vielfältige Aufgaben zu übernehmen. Dazu gehören zum Beispiel Module für eine Permanente- oder Stichtagsinventur, Prozesse für den Wareneingang, Kommisionierungen über MDEs oder Funkterminals, Schnittstellen zu übergeordneten Systemen oder Windows-Auskunftssysteme. Letztere spiegeln das momentane Abbild des Lagers wider. Die Auswahl der Software- und Hardwaremodule erfolgt anhand einer Grafik, in der sich hinter jedem Rechteck ein oder mehrere Softwaremodule und die entsprechenden Hardwarekomponenten verbergen. Eine Ellipse repräsentiert die Daten einer Datenbank. Die Pfeile zwischen den Rechtecken und Ellipsen stellen die Abhängigkeiten zwischen den einzelnen Elementen dar. Auf diese Weise läßt sich bereits in Vorgesprächen feststellen, welche Optimierungsanforderungen mit einem Standardmodul abgedeckt werden und welche eine individuelle Entwicklung erfordern.

Weitere

Informationen

cav-319