Eins wird sich gewiß nicht ändern: Anwender werden - aus Bequemlichkeit oder Eile - auch weiterhin Jahreszahlen zweistellig schreiben. Es spricht alles dafür, daß sich das Problem 2000 ohne Gegenmaßnahme weit ins nächste Millennium fortpflanzt.
Tabellenkalkulationen können bereits heute mit dem Jahr 2000 umgehen, indem sie mittels Windowing-Verfahren zweistellige Jahreszahlen interpretieren und das Jahrhundert nach vorgegebenen Regeln hinzufügen. So werden beispielsweise Jahreszahlen kleiner als 30 jeweils als 20xx, andere Zahlen als 19xx interpretiert.
Aber hilft dieses Verfahren wirklich? Was geschieht mit Verträgen über eine Laufzeit von 35 Jahren? Unterschiedliche Versionen der gleichen Software können ein Datum verschieden interpretieren. Hier muß sichergestellt sein, daß sich Jahreszahlen nur vierstellig eingeben lassen, damit sie keine Fehler hervorrufen.
Datenbanken bieten das Datumsformat an und speichern die Jahreszahlen automatisch vierstellig ab. Wenn in einer Microsoft-Access-Form oder einem Excel-Tabellenformular eine zweistellige Eingabe vorgesehen ist, hat der Anwender auch nicht die geringste Chance, ein Datum korrekt vierstellig einzugeben. Er wird zu Fehlern gewungen.
Erfahrungen aus der Großrechnerwelt haben außerdem gezeigt, daß nicht jeder Entwickler für ein Datum auch das Datumsformat der Datenbank nutzt. DB2 schreibt keine zweistellige Jahresangabe vor. Aber in der Praxis haben die Tabellen mehr als genug Felder, die als Character oder gepackte Felder in der Form JJMMTT gespeichert sind. Warum sollte dies in PC-Umgebungen anders sein?
Anwendungen auf dem PC werden auch im Jahr 2000 laufen. Es bleibt jedoch die Unsicherheit, ob dieselben Anwendungen auf unterschiedlichen Rechnern tatsächlich dasselbe Ergebnis liefern. Solche Fragen verschaffen den Unternehmen zumindest ein gewisses Maß an Unsicherheit.
Die Verunsicherung entsteht nicht etwa aus Unverständnis der DV-Probleme. Die Controller der Unternehmen sind diesbezüglich zusehends aufmerksam, zumal auch Wirtschaftprüfer zumindest das Vorhandensein eines Jahr-2000-Projekts als Voraussetzung für ihre Testate verlangen. Ein Controller wird den IT-Verantwortlichen in die Pflicht nehmen und von ihm eine Aussage fordern.
Das Ausmaß des Problems in PC und Client-Server-Umgebungen ist riesig. Weltweit gibt es mehr als 240 Millionen PCs, zirka 35 Millionen Anwender arbeiten mit Microsofts Excel. Laut Gartner Group werden mehr als 70 Prozent aller PCs geschäftlich genutzt. Die Kosten zur Beseitigung des Problems schätzen Analysten auf 300 bis 1300 Mark pro Rechner, was einem Gesamtaufwand von 20 bis 80 Milliarden Mark entspricht. Dabei wird der Aufwand um so höher, je relevanter PC-Software und -Daten für ein Unternehmen sind.
Insbesonders für die Bankwirtschaft mit ihrer intensiven Nutzung von Informationstechnologie ist ein einwandfreies Funktionieren der Hard- und Software essentiell. Mehr und mehr Kunden nutzen - durchaus auch im Interesse der Banken - Electronic Banking. Point-of-Sales-Lösungen unterstützen den Vertrieb von Bankangeboten. Tag für Tag durchlaufen dreistellige Millionenbeträge die Finanz- und Anlagesysteme. Risk-Management-Systeme sind zur Kontrolle über Kapitalanlagen unabdingbar.
Aber die weitaus überwiegende Mehrzahl der Programmzeilen für all diese DV-technischen Hilfsmittel ist für PCs geschrieben. Milliardenwerte laufen über PC-Anwendungen. Für die IT-Verantwortlichen sind diese Systeme kaum noch überschaubar, weil viele Programme in der Fachabteilung mit PC-Werkzeugen wie Visual Basic, Powerbuilder oder auch Excel-Makros entstanden sind. Um so schwieriger wird sich das Auffinden und Beheben der vom Jahrhundertwechsel betroffenen Anwendungen und Daten gestalten.
Die explosionsartige Ausbreitung der PCs in den Abteilungen war durch die langen Entwicklungszeiten der zentralen Datenverarbeitung bedingt. Früher waren ein paar Apple II, heute sind massenhaft PCs - notfalls an offiziellen Budgets vorbei - die probaten Helfer.
Versiertere Kollegen erleichterten denen nebenan mit schnellentwickelten Programmen die tägliche Arbeit. So entstanden und entstehen noch täglich Tausende Applikationen auf PCs, die keiner Kontrolle und Verwaltung des Unternehmens unterliegen. Es gibt nicht einmal einen Überblick. Anwender laden Software aus dem Internet und installieren ihre Updates selbst.
Ein Jahr-2000-Projekt unter solchen Umständen kann den aus der Mainframe-Welt bekannten Vorgehensweisen folgen. Es muß allerdings die Besonderheiten der PC- und Client-Server-Welt berücksichtigen.
Eine Inventarisierung der Hard- und Software kann nicht nur über das Netzwerk erfolgen, sondern darf sich darauf nicht beschränken. Es existieren zahlreiche offline arbeitende PCs, Notebooks sind nur periodisch im Netz. Hier müssen notfalls Diskettenaustausch oder E-Mail helfen.
So ermittelte Dateien und Anwendungen müssen auf ihr Jahr-2000-Risiko hin analysiert werden. Besonderes Augenmerk sollte dabei Quattro-Pro- und Lotus-1-2-3-Tabellen, Dbase-, Paradox- und Foxpro-Datenbanken sowie den verbreiteten Microsoft-Produkten gelten.
Wenn das Risiko der betroffenen Quellen bekannt ist, läßt sich ein Projektplan für die Umstellung entwerfen. In ihm ist auch festzulegen, wer die Modifikationen vornehmen wird. Dies kann im einfachen Fall, zum Beispiel bei Tabellendaten, der Anwender selbst tun. Komplexeren Anwendungen und Daten, die über Abteilungsgrenzen hinaus Verwendung finden, wird sich die IT-Abteilung zentral annehmen müssen.
Es ist einigermaßen wahrscheinlich, daß sich ein "Y2K-Projektteam" im Gegenzug wieder personell und fachlich aus den Abteilungen verstärken muß, um Tricks und Findigkeiten dort entwickelter Programme auf die Spur zu kommen. Spezialkenntnisse sind erforderlich für Excel-Makros, Access-Forms, C, C++, Powerbuilder, Visual Basic, Unix-Shell-Scripts und andere Client-Server-Entwicklungsumgebungen. Hilfreich ist ein Software-Tool das die Umsetzung dieser unterschiedlichen Programme mit Hilfe einer einheitlichen Benutzeroberfläche gewährleistet.
Nach der Umstellung sollte auch in PC-Umgebungen der Erfolg der Änderungen belegbar sein. Die Tests verlangen wie in der Mainframe-Welt Planung, Management und die Durchführung des funktionalen Abgleichs (Vorher-nachher-Test). Datenübernahme und die Interaktion verschiedener Programme sind unbedingt zu simulieren. Erst danach kann man die umgestellten Dateien und Anwendungen in das produktive Geschäft übernehmen.
Wer nach dieser Vorgehensweise alle PC-Hard- und Software fit für das Jahr 2000 gemacht hat, ist gleichwohl nicht fertig. Denn bis zum Jahr 2000 muß noch eine ständige Überprüfung jedes Rechners auf nachträglich installierte Software und übertragende Daten laufen. Eine Automatisierung dieses Prozesses hilft gewährleisten, daß die PCs auch bis zum Jahr 2000 sicher bleiben.
Angeklickt:
Vom Problem 2000 in Großrechnerumgebungen gab es hier genug zu lesen. Auch von den Schwierigkeiten mit BIOS und Echtzeitchip der PCs wurde berichtet. Doch auch softwareseitig bereiten PCs und Client-Server-Umgebungen Sorgen. So nimmt sich selbst der bisher zu dieser Thematik sehr zurückhaltende Branchenriese Microsoft, in Amerika deswegen schon als "Sleeping Giant" gescholten, mit einer eigenen Web-page des Problems an. Allerdings fallen hier die Hinweise auf Werkzeuge, mit denen man seine Software auf Jahr-2000-Fähigkeit überprüfen kann, äußerst spärlich aus.
* Holger Exner ist Marketing-Manager der Viasoft GmbH in München.
Abb.1: Eingeschränkte Sicht
Übersehen? In vielen Umstellungsprojekten beschränkt sich die Aufmerksamkeit auf die Mainframe-Umgebungen. Quelle: Exner
Abb.2: Kreislauf
Umstellungen im PC-Umfeld geraten wegen selbständiger Installationen der Anwender leicht zu einem Kreislauf. Quelle: Exner