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/Planungen, Analysen, Umstellungen, Tests und viele Überraschungen

Projektorganisation erfordert nervenstarke Spezialisten

Das Thema Jahrtausendwechsel in der DV wird seit längerem intensiv diskutiert. Den Worten sind bisher allerdings wenig Taten gefolgt. Während sich in den USA etwa ein Drittel der Unternehmen eingehend mit dem Jahr 2000 beschäftigt, sind es in Deutschland lediglich zwischen fünf und zehn Prozent.

Dabei wird das allgemeine Lösungsumfeld immer schwieriger. Überall haben DV-Anwender die Risiken von Jahrtausendprojekten unterschätzt. Nach Erfahrungen aus laufenden Projekten sind die Budgets für Gesamtprojekte zu niedrig angesetzt. Große und erfahrene Dienstleistungsunternehmen bieten deshalb Jahr-2000-Projekte nur noch auf Zeit- beziehungsweise Materialbasis an.

Hinzu kommt, daß Fachkräfte mit Erfahrungen in den besonders gefährdeten alten Programmiertechniken kaum mehr zu finden sind. Der Stundenpreis für Cobol-Programmierer hat sich deshalb in den USA 1996 verdoppelt. Auch die Dienstleistungsanbieter in Deutschland haben nur eine begrenzte Anzahl entsprechender Experten. Die verfügbaren Ressourcen sind im Verhältnis zur Nachfrage der Unternehmen, die in nächster Zeit Unterstützung benötigen, zu knapp.

Dabei ist es grundsätzlich unproblematisch, ein Datumsfeld zu identifizieren und von zwei auf vier Stellen zu erweitern. Die eigentliche Herausforderung liegt jedoch in der Vielzahl relevanter Felder.

So geht es zum Beispiel bei einer deutschen Großbank um etwa 350000 Felder in 50 Millionen Programmzeilen. Die Felder haben auf Definitionsebene unterschiedliche Namen und werden an rund einer Million Stellen in den Systemen genutzt. Zudem sind die Programme auf die unterschiedlichste Art und Weise miteinander verknüpft, und ohne exakte Analyse bleiben die genauen Strukturen unbekannt.

Es wird schnell deutlich, daß sich hier besondere Anforderungen an Vorgehensweise, Projektsteuerung und Qualitätssicherung stellen. Nur wenn grundlegende Problemlösungsansätze in der Praxis erprobt werden, läßt sich die Aufgabe erfolgreich bewältigen.

Generell gibt es zwei Ansätze zur Lösung des Jahr-2000-Problems, die oft als gleichwertig gelten: die Erweiterung der Jahresfelder auf vier Stellen und die sogenannte Window- oder Fenstertechnik, bei der das Datum unverändert zweistellig bleibt. In letzterem Fall erfolgt die richtige Zuordnung der Jahrhundertinformation durch einen festen oder dynamischen Grenzwert: Beträgt dieser zum Beispiel 50, bekommen alle Jahre größer 50 über Logikabfragen die richtige Jahrhundertvorzahl 19 zugeordnet.

Unter Kosten- und vor allem Zeitaspekten betrachtet, handelt es sich aber keineswegs um gleichwertige Alternativen. Der Aufwand und damit die Kosten für die Umstellung auf vier Stellen entspricht dem Fünf- bis Zehnfachen im Vergleich zur "Fenster"-Lösung.

Die Gründe hierfür verdeutlicht ein Beispiel: In einem Jahr-2000-Projekt eines Finanzdienstleistungs-Unternehmens mit 550000 Programmzeilen finden sich 30000 Stellen mit Datumsinformationen - davon allerdings nur 1150 mit logischen Operationen, wie zum Beispiel Berechnungen oder Vergleiche. Es liegt auf der Hand, daß bei der Window-Lösung, bei der nur an 1150 Stellen Änderungen vorzunehmen sind, ein erheblich geringerer Aufwand für Analyse, Migration und Test entsteht als bei der Datenerweiterung, die alle 30000 Stellen betrifft.

Zusätzlich erfordert die Erweiterung auf vier Stellen eine Stichtagsumstellung. Daten und Anwendungen sind gleichzeitig zu migrieren. Denn bei Änderungen in Datenbeständen ist es notwendig, alle darauf zugreifenden Applikationen zu kennen und die gleichzeitige Modifikation der betroffenen Felder in den Programmen sicherzustellen.

Ein Projektleiter verglich diese Problematik mit dem stereotypen Briefschluß seiner Großtante, die immer, um niemanden zu vergessen, am Ende den Satz schrieb: "Viele Grüße an alle." In dem Unternehmen dieses Projektleiters ist bei Datenänderungen nicht 100prozentig bekannt, welche Anwendungen auf die relevanten Datensätze zugreifen. In solchen Fällen bietet sich das "Grußverfahren" an: Eine Mitteilung an alle Anwendungsverantwortlichen fordert die Betroffenen auf, sie möchten entsprechend den bestehenden Prozessen reagieren und ihre Programme gleichzeitig anpassen.

Keine Frage: In der Praxis kann dies bei 30000 Programmen mit etwa einer Million Stellen, an denen ein Datum vorkommt, nur schwer funktionieren. Vor allem läßt es sich aber nicht kontrollieren. Der Aufwand für das Testen und die Fehlerbeseitigung ist mit diesem Ansatz bis zum Jahr 2000 nicht zu bewältigen.

In Anbetracht der bis zum Jahrtausendwechsel verbleibenden Zeit ist grundsätzlich die "zweistellige Lösung" mit Fenstertechnik anzustreben und die Erweiterung von Jahresfeldern auf vier Stellen nur dort vorzunehmen, wo es unbedingt erforderlich ist. In der Realität ist aber aus System- und Anwendungssicht die Erweiterung des Datumsfelds zwingend notwendig.

Ein Beispiel ist hier die Verwendung eines Datumsfeldes im Schlüssel einer Datenbank. Die Frage, in welchen Teilbereichen die Stichtagsumstellung zu erfolgen hat, ist also eines der Kernprobleme und stets als erstes zu beantworten.

Grundbedingung für die erfolgreiche Bewältigung der Jahr-2000-Herausforderung ist somit die genaue Analyse der in Frage kommenden Programme und Felder mittels einschlägiger Analyse-Tools. Kein Werkzeuganbieter garantiert eine 100prozentige Trefferquote. Eine 95-Prozent-Lösung bedeutet jedoch bei einer Million Datumsfelder, daß man 50000 betroffene Stellen erst während der Testphase lokalisieren kann.

Angesichts so vieler Fehlerquellen ist ein befriedigendes Qualitätsniveau nicht zu erreichen. Der zusätzliche Aufwand an Analyse, Programmkorrektur und Wiederholung der fehlgeschlagenen Testreihen ist schlicht unüberschaubar. Besonders kritisch ist aber der damit verbundene Zeitverzug. Insbesondere bei der Felderweiterung auf vier Stellen kommen die beschriebenen Zusammenhänge zum Tragen.

Die Anforderungen an die Programmanalyse sind demnach bei der Lösung der Jahr-2000-Problematik besonders hoch. Das Analysewerkzeug muß die Ergebnisse so aufbereiten, daß man exakt die Verwendung logischer Operationen erkennt und weiß, an welchen Stellen die Jahres- beziehungsweise Jahrhundertinformationen im Datumsfeld zu finden sind.

Viele der am Markt angebotenen Tools arbeiten mit iterativen Verfahren, bei denen sich die Trefferbedingungen für ein Datumsfeld auf den Feldnamen beziehen und schrittweise immer weiter verfeinert werden. Da es in der Regel keine Namenskonventionen für das Datum gibt, führt dieses Vorgehen dazu, daß ab einer bestimmten Iteration bereits gefundene Treffer eliminiert und immer zu viele Felder auftreten. Diese "Überdeckung" hat natürlich einen zusätzlichen, unnötigen Aufwand zur Folge.

Erfahrungen aus laufenden Projekten zeigen, daß Suchkriterien - bei einem gewünschten Ergebnis von 100 Prozent identifizierter Datumsfelder - so global zu definieren sind, um zusätzlich die zwei- bis dreifache Menge an nicht betroffenen Feldern zu finden.

Sowohl diese Alternative als auch die Reduzierung der Gesamtmenge bei einer Trefferrate von beispielsweise 95 Prozent sind in einem unternehmenswichtigen Projekt wie der Datumsumstellung nicht akzeptabel.

Es sind deshalb solche Tools einzusetzen, die nicht nach Namensvergleichen arbeiten, sondern die logischen Zusammenhänge von datumsrelevanten Feldern analysieren. Dies ist im globalen Anwendungssystem über Programme und Anwendungen hinweg zu leisten. Durch diese inhaltliche Analyse lassen sich Trefferquoten von annähernd 100 Prozent erzielen, womit auch das Problem der Ungenauigkeit gelöst ist.

Verantwortliche auf Analyse konzentriertAlle Experten sind sich darin einig, daß in komplexen Projekten wie der Jahreszahlenumstellung mindestens 50 Prozent des Gesamtaufwands durch das Testen entsteht. Dennoch findet dieses Thema in der Praxis bis jetzt nicht die nötige Aufmerksamkeit. Der Grund könnte sein, daß in bisherigen Projekten der Test als eine der letzten Phasen begriffen wird, die Verantwortlichen sich momentan aber auf die Analyse und die Migration konzentrieren.

Entsprechende Testszenarien aufzubauen, erfordert Zeit und Kenntnis der Anwendungen und Systeme. Entscheidend ist dabei ebenfalls eine umfangreiche Beteiligung der Fachabteilungen. Testfälle sind entsprechend definierter Geschäftsprozesse zu erzeugen und "automatisch abspielbar" zu protokollieren. Die Fülle der entstehenden Testskripte macht eine eigene Datenbank für Organisation und Verwaltung notwendig. Schon die Generierung zugeordneter, repräsentativer Testdaten ist eine Aufgabe mit erheblichem Aufwand.

Beim Jahreszahlenwechsel gibt es einen besonderen Aspekt, der eine Automatisierung der Abläufe zwingend nach sich zieht. Testen bedeutet im Normalfall, nach funktionalen Fehlern zu suchen. Bei der Umstellung auf das Jahr 2000 ist nicht mit Sicherheit zu sagen, ob eine Anwendung, die nach der Umstellung korrekt läuft, nicht irgendwann in Zukunft doch Fehler liefert.

Ein Test, der sich ausschließlich auf den 1. Januar 2000 konzentriert, genügt also nicht. Denn Bugs können jederzeit vor und auch nach der Jahrtausendwende auftreten. Bei Anwendungen, die mit archivierten Historiendaten arbeiten, passiert dies vielleicht erst im Jahr 2005, weil für eine Auswertung der Zeitraum bis fünf Jahre vor dem aktuellen Datum zu berücksichtigen ist. Durch ein nicht entdecktes "Fenster" verlängern sich diese Zeiträume entsprechend.

Das Systemdatum mit den zugehörigen Komponenten auf zukünftige Zeitpunkte zu modifizieren, reicht allein noch nicht aus. Dieses Vorgehen gibt einen Hinweis auf die Art und den Umfang der Problematik, deckt aber jene Fehler nicht auf, bei denen keine Rückmeldungen erfolgen. Der Grund: Die Anwendungen produzieren zwar falsche Werte, die Programme interpretieren diese aber als "gültiges" Ergebnis beziehungsweise ziehen falsche Schlußfolgerungen.

Beispiele hierfür sind die Berechnungen von Zinsen über 99 Jahre bei einer Bank oder der Stillstand der Bänder bei einem Automobilunternehmen Anfang des Jahres 2000. Auch wenn das System die Bestellungen an Zulieferer im Jahr "00" als ungültiges Datum erkennt, gibt es aber - ohne weitere Meldung - keine Bestellung auf.

Sogenannte "Zeitreisen" lösen diese Problematik. Dabei werden alle relevanten Jahresangaben beim Testen mittels Werkzeuge gealtert. Relevant heißt in diesem Zusammenhang, die zeitlichen und funktionalen Abhängigkeiten eines Geschäftsvorfalles entsprechend dem simulierten Jahr synchron in die Zukunft zu transformieren.

Die zu modifizierenden Felder werden bereits bei der Erstellung der Testszenarien festgehalten und später mit vorhandenen Werkzeugen auf ein gewünschtes Datum transferiert. Ein automatischer Vergleich der simulierten Testjahresergebnisse zeigt dann die physischen und logischen Fehlfunktionen auf.

In der Praxis existieren bei einem Unternehmen mit heterogenem, in den letzten Jahrzehnten gewachsenem IT-Umfeld immer Teilaufgaben, die einen hohen Anteil manueller beziehungsweise weniger automatisierter Restarbeiten erfordern. Beispielhaft seien dezentrale Systeme, Client-Server-Umgebungen, Programmiersprachen, wie Assembler und C, sowie externe Schnittstellen genannt.

Die Projektsteuerung der Jahr-2000-Umstellung umfaßt aber auch weitere Themen wie Software-Change-Management, Produktionseinführung, Austausch von Hardware und Systemsoftware sowie die Qualitätssicherung aller Aktivitäten. Viele dieser Aufgaben sind fachlich durch externe Ressourcen nicht zu bewerkstelligen. Die Maßnahmen sind den Gegebenheiten vor Ort genau anzupassen und mit einem hohen Personaleinsatz verbunden.

Die organisatorische Abwicklung erweist sich wegen der kurzen Zeitspanne bis zum Jahr 2000 als weiteres Kernproblem. Neben den Werkzeugen empfiehlt sich deshalb eine festgeschriebene Vorgehensweise, die diesen Aspekt berücksichtigt.

Der "Factory"-Ansatz ist in diesem Fall der richtige Weg. Hierbei handelt es sich um einen definierten, wiederholbaren und in mehreren Phasen ablaufenden Prozeß, der weitgehend von Werkzeugen unterstützt und damit automatisiert abläuft. Diese Methodik in Verbindung mit der Auswahl und vor allem der Integration der besten Technologien reduziert die Gesamtkosten eines Jahr-2000-Projekts bis zu 50 Prozent.

Die Unternehmen stehen vor der Aufgabe, bis zur Jahrtausendwende all ihre Probleme zu lösen. Mit bisherigen, bewährten Vorgehensweisen laufen sie Gefahr, die Aufgabe Jahr 2000 zu spät und/ oder nicht in der erforderlichen Form anzugehen. Das Beispiel einer Bank macht dies deutlich: Nach intensiven Gesprächen über einen Zeitraum von immerhin 17 Monaten und der Auswertung eines Pilotprojekts war festzuhalten, daß mit der vorhandenen Infrastruktur und dem angewandten Verfahren die Aufgabe nicht die gewünschten Ergebnisse bringt. Es ist zu befürchten, daß solche Erkenntnisse in nächster Zeit vielen Unternehmen drohen.

Mit Blick auf die Komplexität, die Unternehmensbedeutung und in Anbetracht der Zeit ist es höchste Eisenbahn, die beschriebenen Basisansätze in die Praxis umzusetzen und die Lösung der Jahr-2000-Problematik zur Chefsache zu erklären.

WaschzettelNeun Essentials beim Problem-2000-Management

- Die Gesamtkosten liegen zwischen einer und zwei Mark pro Programmzeile. Gehen Sie davon aus, daß dies auch für das eigene Unternehmen gilt. Nur eine detaillierte Analyse beziehungsweise Pilotprojekte können hier Klarheit schaffen.

- Stellen Sie die erforderlichen Budgets zur Verfügung.

- Der Projektleiter muß Gesamtverantwortung und die nötigen Befugnisse haben. Setzen Sie Ihren besten Projektleiter auf das Thema an.

- Kehren Sie keine Teilprobleme unter den Teppich. Haben Sie die richtige Lösungsstrategie?

- Ohne systematisches Testen muß Ihr Jahr-2000-Projekt scheitern.

- Sehr viele Aufgaben sind nur durch eigene Mitarbeiter zu lösen. Verfügen Sie über ausreichend Personalressourcen?

- Es werden noch viele manuelle Restarbeiten anfallen. Haben Sie externe Ressourcen reserviert?

- Suchen Sie Projektpartner, die mit Umstellungen dieser Art Erfahrung haben.

- Nutzen Sie die Umstellung, um grundsätzlich Ihre DV zu verbessern und zu aktualisieren.

Angeklickt

Zwar spät, aber doch nehmen Unternehmen zur Kenntnis, daß sie mit den berühmten zwei Nullen "auch noch ein Problem" haben. Zumindest nach dem Volumen der zu analysierenden, umzustellenden und zu testenden Codezeilen nimmt dieses Thema beeindruckende Ausmaße an. Und: Es zeichnet sich ab, daß die Kapazitäten entsprechender Dienstleister und freier Kenner alter Softwaretechniken nicht mehr ausreichen. Tools sind kein Allheilmittel. Die überlegte Organisation der Arbeitsschritte gewinnt angesichts oft überraschender Zwischenergebnisse in den Umstellungsprojekten zunehmend an Bedeutung.

*Helmut Wolf ist Leiter Vertieb Projekte bei der Compuware GmbH in Dreieich.