Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.04.1997 - 

Problem 2000/Das Problem 2000 ist in der Fertigungsindustrie bereits akut

Ist das baldige Ende von Planung, Steuerung und Produktion zu befürchten?

Die Mehrzahl der zu koordinierenden Ablaufprozesse in einem produzierenden Unternehmen regeln spezielle Softwareprogramme. Diese bestehen aus zahllosen Unterprogrammen, die meist sehr eng miteinander verwoben und eigentlich immer abhängig von einer oder mehreren Datumsangaben sind.

Da bei langfristig planenden Einzel-, aber auch Serienfertigern bereits heute wie in vergangenen Jahren Aufträge eingehen beziehungsweise eingingen, die über die Jahrtausendgrenze hinaus abgewickelt werden, geht es in vielen Fällen um die Verarbeitung von Terminen nach dem Jahr 2000. Aus diesem Grund sieht sich die Fertigungsindustrie im besonderen dieser speziellen Problematik ausgesetzt.

Beispielhaft hierfür ist der Zusammenhang zwischen Auftragseingangs-, Dispositions- und Lieferdatum. Während der Auftragseingang noch in diesem Jahrhundert erfolgt, können einige Koordinationsdaten und vor allem das Lieferdatum erst im Jahr 2000 liegen. Software, die diese Problemstellung nicht berücksichtigt, ist für die Abwicklung solcher Aufträge jedoch ungeeignet. Beim Versuch, eine entsprechende Disposition vorzunehmen, verursachen sie entweder Systemabstürze, beispielsweise durch unschlüssige Datumsangaben oder treffen inkonsistente Aussagen, die eine sachgemäße und korrekte Bearbeitung unmöglich machen.

In den in der Fertigung üblicherweise eingesetzten Softwareprogrammen wie Enterprise Resource Planning (ERP) oder PPS-Systemen für Produktionsplanung und -steuerung tauchen Datumsangaben unter anderem als Anlage-, Korrektur-, Überwachungs- und Systemdatum auf. Zu komplexen Business-Objekten gibt es darüber hinaus noch zahlreiche andere Angaben, die auf einem Datum basieren oder ein Datum einbeziehen.

Ausnahmslos alle Unternehmen der Fertigungsindustrie sind betroffen: jene mit weitreichenden Planungshorizonten früher als andere, unabhängig davon, ob sie als Großunternehmen operieren oder mittelständisch strukturiert sind. Denn bei allen Unternehmen dieser Prägung bestimmen mehr oder weniger identische Prozesse die internen Abläufe.

Immer sind Aufträge zu erfassen, zu disponieren und zu koordinieren. Immer ist Materialbeschaffung und Terminierung ein Thema. Und immer steht am Ende, ob Einzel- oder Serienfertigung, das Lieferdatum. Kaum eine der notwendigen Operationen, um einen Auftrag zu erledigen, kommt dabei ohne Datumsangabe aus. Ein Datum kann auch versteckt vorliegen, wie meist in Rückmeldungen aus der Betriebsdatenerfassung. Das Datum 2000 wird dadurch zur allgegenwärtigen Problemstellung, sofern die Software nicht in weiser Voraussicht seit jeher über vierstellig aufgebaute Datumsfelder verfügt.

Uninterpretierbare Fehlermeldungen

Bei der Auftragserfassung zum Beispiel meldet der interne Fabrikkalender bereits beim Versuch, ein Datum einzugeben, einen Fehler, sollte es kleiner als das zuletzt erfaßte Auftragsdatum sein. Gelingt es dennoch, einen Auftrag anzulegen und zu speichern, wird er unauffindbar bleiben. Oder es tauchen bei der Weiterbearbeitung des Auftrags uninterpretierbare Fehlermeldungen auf, die eine Fortführung der jeweiligen Operation unmöglich machen.

Auch bei Filteroperationen oder Übersichtsfunktionalitäten erhält der Sachbearbeiter durch die falsche Sortierung der Daten unbrauchbare Angaben. Bei Summierungen wird über falsche historische Grenzen hinaus addiert, Überwachungen fördern falsche Aufträge zutage, das gewünschte Projekt jedoch ist verschwunden. Die nicht mehr vorhandene Funktionalität des Systems stellt somit das eigentliche Problem dar. Wenn überhaupt, bekommt man, da die Software die benötigten Daten nicht mehr richtig zusammenstellt, falsche Informationen.

Falsche Prioritäten bei der Auftragsbearbeitung

Ein Beispiel: Man erfaßt einen Auftrag und leitet softwaretechnisch die Überwachung der damit verbundenen Koordinationsprozesse ein. Dabei müßten aktuelle Aufträge vor den bereits ausgeführten erscheinen. In der Regel geschieht die Sortierung jedoch nach Überwachungsdatum. Wenn die Auftragsabwicklung auch über das Jahr 2000 hinaus erfolgen muß, werden Aufträge aus dem nächsten Jahrtausend als ältere anstatt neuere angezeigt. Der Grund: Die zweistellige Zahl eines Datums wird kleiner sein als jede Jahresangabe aus dem zu Ende gehenden 20. Jahrhundert. Der Sachbearbeiter erhält also beim Sortiervorgang eine Fehlinformation und bearbeitet Aufträge nach der falschen Priorität, sofern er das Problem nicht oder nicht sofort erkennt.

Noch problematischer wird es, wenn ein Unternehmen im Konzert mit verschiedenen anderen Applikationen ein Patchwork von verschiedenen DV-Systemen betreibt. Alle Schnittstellen zu anderen Programmen sind davon betroffen. Es ist nicht nur das System an sich, das zu modernisieren beziehungsweise zu erweitern ist, auch die Kommunikation zwischen Mensch und Maschine oder von Maschine zu Maschine ist sicherzustellen. Der sich ergebende Aufwand ist gewiß ebenso hoch anzusetzen wie die systemimmanenten Probleme mit proprietären Programmen.

Und auch die Hardware rückt in den Mittelpunkt des Interesses. Computer der 70er und 80er Jahre führen meist ein zweistelliges Systemdatum, das beim Booten aktiviert wird. Dieses Datum nutzen Systemroutinen, um in hardwarenah programmierten höheren Applikationen die Datumsversorgung sicherzustellen.

Eine Konvertierung von alten Datenbeständen ist bei fehlendem Sourcecode kaum noch möglich. Dieser ist durchdrungen von Operationen, die sich auf Datumsangaben stützen. Die während einer Migration ablaufenden Arbeitsroutinen nutzen die Daten aus der Vergangenheit sehr rudimentär. Das heißt: Tief in der Software liegende Programmstrukturen sind nötig, um Transaktionen vorzunehmen. Nur so kann man auf diese Daten zugreifen, sie vergleichen und lokal zwischenspeichern. An der Programmschnittstelle vorbei lassen sie sich nicht bedienen.

Sind die ursprünglichen Quellen nicht mehr verfügbar, die Dokumentationen des Systems unvollständig oder fehlen die richtigen Fachleute, ist die oft erforderliche Übernahme von Altdaten in ein neu konfiguriertes System kaum noch möglich.

Da in der Fertigungsindustrie meist nur schwer überschaubare Systeme im Einsatz sind, nimmt die Umstellung auf das Jahr 2000 in vielen Firmen vermutlich zwei bis drei Jahre in Anspruch.

Eine relativ gut dokumentierte Software datumsgerecht umzustellen, beansprucht etwa fünf Prozent der Zeit, die für die Installation des Systems notwendig war.

Die Entwicklung der PSI-Lösung "Piuss penta", die aufgrund einer vierstelligen Datumsangabe von diesem Problem nicht tangiert ist, hat zum Beispiel ungefähr 275 Mannjahre benötigt. Bei vergleichbaren, jedoch betroffenen Systemen sind ähnliche Größenordnungen anzusetzen. Ein umfassender Personaleinsatz und rechtzeitiges Handeln sind folglich unabdingbar.

Wer heute als Maschinen- und Anlagenbauer glaubt, sich mit der Problematik nicht vor 1998 oder gar erst 1999 befassen zu müssen, könnte eine böse Überraschung erleben. Denn ist die Umstellung bis zum 31. Dezember 1999 nicht bewerkstelligt, könnten alle Anstrengungen auf dem Weg dorthin umsonst gewesen sein. Das System wird, sollte es nicht vollständig auf das Jahr 2000 eingestellt sein, schon bei der ersten Berechnung im neuen Jahrtausend fehlerhaft arbeiten.

Die Konsequenzen könnten identisch sein mit jenen, die entstehen, wenn das Problem ignoriert wird. Die bis dahin investierten Gelder wären dann quasi in den Sand gesetzt worden. Deshalb ist die Schonfrist für Unternehmen, die entsprechend untaugliche Systeme einsetzen, abgelaufen. Es müssen jetzt sofort Entscheidungen über die Vorgehensweise inklusive der Outsourcing-Thematik sowie die Installierung eines Projektmanagements und über Art und Umfang des Personaleinsatzes getroffen werden.

Dabei sollten Testläufe, Steuerungsprozesse und Operationen mit vertraulichen Daten hausintern ablaufen. Kommen externe Dienstleister ins Spiel, empfiehlt es sich, sie mit zeitintensiven Routineaufgaben zu betrauen. Gleichzeitig müssen sie über Fachkräfte verfügen, die alle höheren Programmiersprachen, wie etwa RPG, Cobol, Fortran, Pascal und C, beherrschen.

Wichtiger ist jedoch, daß Experten, die von außen kommen, ein Verständnis für die komplexen Zusammenhänge zwischen der Funktionalität und Verarbeitung von Daten mitbringen. Da dies für die betroffenen Unternehmen zu Beginn der Zusammenarbeit nur schwer einzuschätzen ist, sollten eventuell nicht vollständig abgeschlossene Umstellungen bis zum Jahr 2000 vertraglich abgesichert sein.

Handelt es sich bei den betroffenen Programmen um weitläufige, komplexe Applikationen, können sich die entstehenden Ausfallzeiten über mehrere Tage erstrecken. Zumindest während der Datenkonvertierung wird das System vermutlich komplett stillstehen, da die im Unternehmen vorhandene Hardware voraussichtlich nicht in der Lage ist, neben den Konvertierungsabläufen noch andere Rechenleistungen zu erbringen. Es müssen nämlich zwei komplette Datensätze bereitgehalten werden, um Daten von A nach B transferieren zu können.

Für den Fall, daß Altdatenbestände aus Dokumentationsgründen aufzubewahren sind, benötigt man eine nahezu doppelte Platten- beziehungsweise Speicherkapazität. Die Rechenleistung und die Speicher der verwendeten Computer dürften in der Mehrzahl der Fälle voll ausgelastet sein.

Reicht dennoch die Plattenkapazität der Systeme nicht aus, ist zusätzliche Hardware erforderlich. Dies muß auch dann erfolgen, wenn die vorhandene Hardware nicht in der Lage sein sollte, unter Laborbedingungen aussagefähige Testläufe durchzuführen, die für eine erfolgreiche Migration notwendig sind.

Laut Gartner Group sollte der Lösungsansatz einer ganz bestimmten Vorgehensweise folgen. Danach wären für Analyse und Design der Lösung, für den Migrationsvorgang sowie für die Testläufe der Programme 60 Prozent der insgesamt zur Problembewältigung anzusetzenden Zeit zu veranschlagen. Im Einklang mit dem von der Gartner Group vorgeschlagenen Verfahren empfiehlt PSI, über eine Datenanalyse den im Unternehmen vorhandenen und relevanten Datenbestand zu ermitteln.

Dazu bedarf es einer exakten Beschreibung des Datenmodells, um einen Migrationspfad erarbeiten zu können. Die Informationen müssen sowohl die Schnittstellenproblematik zu anderen Programmen als auch archivierte, historische, sprich nicht aktivierte Datenbestände berücksichtigen. Auch die auf Magnetbändern gelagerten Datenbestände sind mit einzubeziehen. All diese Daten sind zu konvertieren, durch entsprechende Migrationsvorgänge in das neue System zu übernehmen und dort abzuspeichern.

Hierzu ist eine exakte Ausarbeitung von umfassenden Konvertierungskonzepten unumgänglich. Beispielsweise müssen die herangezogenen Sourcecodes editiert, rekompiliert und getestet werden. Praxisbezogene Tests sind notwendig, um Belastbarkeit und Integrationsfähigkeit der Lösung zu ermitteln.

Release-Wechsel oder Systemneueinführung

Im Zuge der Migration werden alle Stellen identifiziert, in denen Datumseingaben erfolgen. Dann ist deren Funktionalität über die Jahrtausendwende hinaus zu prüfen und gegebenenfalls entsprechend zu ändern. Die Systemoberfläche, über die das Jahrhundert identifiziert wird, und die Datenbank sind am stärksten von Veränderungen betroffen.

Die Umstellung der komplexen Softwaresysteme in der Fertigungsindustrie können nur die Hersteller des Systems vornehmen. Denn nur sie halten adäquate Releases für die großen Bestandteile der im Unternehmen eingesetzten Systeme bereit. In sehr großen Unternehmen kommen gleichzeitig mehrere Systeme zum Einsatz. Die entsprechenden Schnittstellen werden in der Regel intern verwaltet. Ein Team aus Hersteller, internem Fachpersonal und externen Programmierern sollte eine umfassende Problemlösung sicherstellen.

Insgesamt empfiehlt sich in diesen komplexen Software-Umgebungen ein stufenweises Vorgehen, bei dem zunächst die Migration aller Standardprogramme und unmittelbar danach die der individuellen Softwarelösungen erfolgt. Schließlich lassen sich auch Einzelsysteme Schritt für Schritt ablösen. Eine solche Umstellung entspricht im einfachen Fall einem Release-Wechsel, schlimmstenfalls einer Systemneueinführung.

Die Entscheidung für eine Systemneueinführung sollte mit der Überlegung eines angepaßten Business Re-Engineering einhergehen, um unternehmensinterne Abläufe und die neue Systemumgebung effizient aufeinander abzustimmen. Und nicht zu vergessen: Der gesamte Migrationsprozeß sollte lückenlos dokumentiert sein, damit er sich jederzeit nachvollziehen läßt.

Angeklickt

Statt Visionen Angst vor einem möglichen Zusammenbruch aller Geschäftsprozesse am 1. Januar 2000. Grund hierfür ist das bekannte Problem der zweistelligen Datumsangaben. Neben Versicherungsunternehmen und Bankgesellschaften sehen sich bereits heute insbesondere die nahezu 10000 deutschen Unternehmen der Fertigungindustrie massiv mit dieser Problematik konfrontiert. Der Autor erläutert, was passiert, wenn Maschinen- und Anlagenbauer oder andere Unternehmen der produzierenden Industrie das Problem negieren oder sich zu spät damit befassen.

*Thomas Krüger ist Diplom-Mathematiker und bei der Berliner PSI AG im Bereich "Piuss penta" als Bereichsleiter Applikaionsentwicklung tätig.