Problem 2000/Last in - first out

Logistik ohne jede Logik: Zwei Nullen sorgen fuer Chaos

15.03.1996

Viele Logistiksysteme, vor allem jene, die in den Jahren 1980 bis 1990 entstanden sind, basieren auf hierarchischen Datenbanken oder index-sequentieller Dateiverwaltung. Das Verwalten dieser Datenbanken beziehungsweise Dateien war und ist, vor allem was Aenderungen der Datenstrukturen betrifft, aeusserst aufwendig.

Auch die Speichermedien (Platte, Band, Kassetten, Disketten etc.) waren zu damaliger Zeit sehr teuer. Sparen war angesagt, besonders beim Speicherplatz. Als unnoetiger Speicherverbraucher galt das Datum, genauer gesagt die Jahreszahl. Aus diesem Grunde wurde das Datum im Format "tt.mm.jj" - also sechsstellig und nicht achtstellig mit einer vierstelligen Jahreszahl - abgespeichert.

Das bereitet keine Probleme, solange das Datum nicht als Sortierkriterium oder gar fuer Berechnungen herangezogen wird. Bis zu einer bestimmten Datumsgrenze: Denn das Datum "31.12.99" ist DV-technisch groesser als "01.01.00". Jedes "alte" Datum ist groesser als eines ab dem 1. Januar 2000 - zumindest fuer die naechsten 80 bis 90 Jahre.

Hiervon sind nahezu alle Logistik-Systeme aus den 80er Jahren betroffen, einer IBM-Studie zufolge zirka 84 Prozent aller Teilprogramme. In diesen gibt es durchschnittlich 8000 als moegliche Datumsfelder identifizierte Datenelemente, wobei sich nur etwa 15 Prozent als eindeutige Datumsfelder identifizieren liessen.

Dies hat in Logistiksystemen mehrere Auswirkungen. Im Vertrieb werden saemtliche Auftraege mit Datum versehen (Angebots-, Auftragsanlage-, Fertigungs-, Lieferdatum etc.). Die Programme im Vertrieb pruefen das Datum oft auf Plausibilitaet. So wird man keinen Auftrag mit Lieferdatum tt.mm.00 erfassen koennen, dessen Fertigungsdatum in der Zukunft liegt (tt.mm.99). Das ist aber der Fall beim Jahrtausendwechsel.

Gleiches gilt bei Auswertungen und Statistiken. Hier dient das Datum als Sortierkriterium und fuer Vergleiche. So wird zum Beispiel die Statistik der bisherigen Lieferungen (alle Lieferungen bis zum 31.12.99) den kompletten Auslieferungsstand auflisten, auch die Auftraege, die in Wirklichkeit erst in der Zukunft (tt.mm.00) geliefert werden.

Das groesste Problem taucht aber in der Materialwirtschaft auf. Hier wird automatisch Material bestellt (Menge zum Termin), sofern kein ausreichender Lagerbestand den Bedarf abdeckt. Da ein Datum ab dem Jahr (20)00 DV-technisch fuer die Materialbedarfsplanung kleiner ist als ein vorheriges (zum Beispiel tt.mm.99), liefert der Planungslauf ein falsches Dispositionsbild. Warum sollte das Programm Auftraege generieren fuer einen Bedarf aus der Vergangenheit, dem mit dem aktuellen Lagerbestand entsprochen werden kann?

In der Lagerverwaltung wird mit dem Jahrtausendwechsel bei zweistelliger Jahreszahl die Fifo-Methode (First in - first out) automatisch zum Lifo-Verfahren (Last in - first out). Saemtliche Einlagerungen im gegenwaertigen Jahrtausend wird das System erst 100 Jahre spaeter zur Auslagerung vorschlagen.

Das Problem des Jahrtausendwechsels stellt sich DV-technisch teilweise schon vor dem Jahr 2000. Insbesondere im Maschinen- und Anlagenbau mit seinen langen Durchlaufzeiten und bereits heute existierenden Auftraegen, die erst im naechsten Jahrtausend zur Ausfuehrung kommen, ist schon frueher mit Stoerungen zu rechnen.

Langfristige Auftraege bereiten bald Probleme

Voraussichtlich ab 1998 werden die Systeme saemtliche sogenannten Langlaeufer, deren Disposition in das naechste Jahrtausend hineinreicht, falsch disponieren. Dieser besonderen Situation der im Maschinen- und Anlagenbau installierten Logistiksysteme muessen sich die Systemlieferanten, aber auch die Anwenderfirmen stellen.

Es gibt mehrere Moeglichkeiten, das Problem des Jahrtausendwechsels zu loesen. Welcher Weg fuer das jeweilige Unternehmen der richtige ist, laesst sich nur durch eine Analyse der DV-Anwendungen im Logistikbereich und der Ablauforganisation innerhalb des Auftragsstrangs feststellen.

So koennte man zum Beispiel nach einer eingehenden Analyse der gesamten Software-Umgebung Programme, bei denen mit dem Datum gearbeitet wird, entsprechend umstellen. Hier waeren die Datumsdefinitionen zu erweitern und die Verarbeitungprozeduren zu modifizieren. Gleichzeitig muessen die Daten beziehungsweise Dateistukturen an das erweiterte Datum angepasst werden. Danach sind die bisherigen Daten auf das neue Datum zu migrieren.

Keine Loesung passt ueberall gleichermassen

Die Schwierigkeit ist dabei nicht das eigentliche operative Geschaeft der Umstellung, sondern deren Vollstaendigkeit. Saemtliche Datumsfelder und zugehoerigen Verarbeitungsprogramme muessen zuverlaessig erfasst werden. Schwierigkeiten machen hierbei die sogenannten programminternen Datumszwischenfelder, die haeufig schwer zu finden sind. Voraussetzung fuer diese Vorgehensweise ist, dass der Sourcecode fuer die Programme vorhanden ist.

Die Datumsumstellung vollautomatisch mittels diverser Softwarewerkzeuge durchzufuehren ist wenig sinnvoll, da diese Methode die programminternen Datumsbezeichnungen nicht erfasst und somit auch nicht beruecksichtigen kann. Man muesste also manuell oder halbautomatisch saemtliche Anwendungsprogramme nach Datumsdefinitionen und -prozeduren nachbearbeiten.

Eine abgewandelte Form dieser Methode besteht darin, die Datenbankaenderungen nicht durchzufuehren, sondern die Datumsproblematik ausschliesslich anwendungstechnisch abzufangen. Empfehlenswert ist dies nicht, da programminterne temporaere Vergleiche mit der Datenbank eine hohe Fehlerquoute mit sich bringen wuerden, die nur ein Redesign der Anwendung beheben koennte.

Alternativ zur Umstellung der bestehenden Logistikanwendung ist auch denkbar, ein "neues" Logistiksystem zu implementieren, welches den Jahrtausendwechsel beruecksichtigt und die benoetigte Funktionalitaet abdeckt. Das bedeutet im Idealfall nicht mehr als die Installation einer neuen Programmversion, welche den Jahrtausendwechsel beruecksichtigt. Dennoch ist die Migration der bestehenden Daten auf die neue Struktur vom Unternehmen selbst durchzufuehren.

Gleichgueltig welche Art der Datumsumstellung gewaehlt wird, der Aufwand ist betraechtlich. Fuer den Logistikbereich geht man von durchschnittlichen sieben Tagen pro Anwendungsprogramm aus. Bei durchschnittlich 350 Programmen pro Logistiksystem bedeutet dies einen Gesamtaufwand von zirka 6,7 Mann-Jahren.

Das Jahr 2000 kommt fuer viele Unternehmen der Branche "Anlagen- und Maschinenbau" bereits 1998. Die grosse Frage ist, wie passt ein Projekt dieser Groessenordnung in den IT-Gesamtplan? Auch ist entscheidend, mit welchen Partnern das Projekt angegangen werden soll. Der Preis fuer die Umstellung wird um so hoeher, je naeher das Jahr 2000 rueckt. Es wird hoechste Zeit, dieses Projekt anzugehen.

Kurz & buendig

Eines der groessten Probleme bei der Umstellung fuer das Jahr 2000 besteht darin, festzustellen, wie Datenfelder, Feldzuweisungen und Programme zusammenhaengen. Es geht also nicht nur um einzelne Datensaetze oder Programme, sondern um die gesamte verwobene Anwendungslandschaft eines Unternehmens. Das Problem ist jedoch alles andere als neu und entsprechend lange schon mit einigen Schlagwoertern verbunden: In den 70er Jahren galt das Data- Dictionary als Loesung, in den 80ern das Repository. In anpassungsfaehigen Repository-Techniken liegt eine Moeglichkeit, dem Problem 2000 beizukommen.

*Joerg Schiebel ist Geschaeftsfuehrer der Iris-Gesellschaft fuer Integrierte Relationale Informationssysteme mbH in Rottenburg.