Zur Resignation besteht selbst wenige Wochen vor dem Jahreswechsel kein Grund, wenn dem Sonderfall Jahr 2000 mit einem adäquaten Projekt- und Risiko-Management begegnet wird. Unternehmen können sogar einen Nutzen aus diesem Projekt ziehen, der über den Datumswechsel hinausreicht: Sie haben die Möglichkeit, Erfahrungen zu sammeln, mit denen das IT-Management zukünftige Projekte auf eine solide Basis stellen kann.
Dies gelingt dann, wenn die Besonderheiten dieses Falls berücksichtigt werden. Denn: Das Jahr 2000 betrifft das gesamte Unternehmen. Im Mittelpunkt steht keine einzelne Anwendung, sondern die gesamte IT-Infrastruktur. Das erfordert konsequente Verfahren des Projekt-Managements. Nicht nur die Software steht auf dem Prüfstand, sondern auch die Anwendungen, Hardware, hinzugekaufte Produkte, Betriebssysteme, Netzwerkkomponenten und die oft vernachlässigten Embedded Systems.
Selbst wenn bereits absehbar ist, daß die Zeit für die notwendigen Maßnahmen nicht mehr ausreicht, gilt es, größtmögliche Transparenz in die eigenen Informationssysteme zu bringen. Dies deckt nicht nur die wichtigsten Fehler auf, sondern verkürzt die Reparaturarbeit im neuen Jahr, falls wirklich Fehler auftreten sollten.
Innerhalb weniger Wochen können noch folgende Schritte unternommen werden:
Die Erstellung einer Inventarliste ist Ausgangspunkt für alle nachgelagerten Aktivitäten. Sie umfaßt alle (DV-)Systemkomponenten eines Unternehmens, also alle Soft- und Hardware bis zu einem geeigneten Detaillierungsgrad. Dazu gehören auch die Schnittstellen zwischen Anwendungen und Programmen sowie deren Sortierung nach Typen wie "programmintern", "anwendungsintern", "unternehmensintern" oder "extern zu Partnerfirmen". Die einzelnen Komponenten sind dabei mit Release- und Versionsständen versehen und Ansprechpartnern zugeordnet, insbesondere bei zugekauften Produkten von externen Lieferanten. Eine solche Inventarliste ist nicht nur die Basis für alle Jahr-2000-Aktivitäten, sondern kann die Wirtschaftlichkeit eines Unternehmens auch insgesamt erhöhen, wenn die Liste aktualisiert und gepflegt wird. Dies reduziert den Aufwand auch bei Fehlern, die nichts mit dem Y2K-Fehler zu tun haben, oder bei einer Systemerweiterung.
In einem zweiten Schritt sind Prioritäten zu setzen: Was sind die wichtigsten Geschäftsprozesse? Wodurch würden Bestand und Image des Unternehmens am stärksten gefährdet? Und: In welchen Bereichen spielt das Jahr 2000 überhaupt eine Rolle? Nur wer diese Fragen beantwortet hat, kann erste Reparaturen einleiten. Sonst gleicht die Arbeit einem Stochern im Nebel. Gleichzeitig ist zu entscheiden, ob sich die erkannten Mängel ganz beseitigen lassen oder ob nur noch eine Schadensbegrenzung möglich ist.
Von den Erfahrungen der anderen lernen
Doch wie läßt sich überhaupt entscheiden, ob ein Systemteil unbedenklich oder risikobehaftet ist? Was sind die Konformitätserklärungen der Hersteller wert? Große Anbieter ändern teilweise monatlich den Status ihrer Produkteinschätzung. Hier gibt es inzwischen eine ganze Reihe unabhängiger Informationsquellen, die sich meistens aus den Erfahrungen und Ergebnissen großer Umstellungsprojekte speisen. So pflegt etwa die SQS Gesellschaft für Software-Qualitätssicherung mbH mit Partnern wie der Deutschen Bank AG und anderen die Datenbank "Vendorbase". In dieser sind die Informationen zur Jahr-2000-Fähigkeit von mehr als 6500 Standardsoftware-Produkten festgehalten. Die Daten werden durch einen Abgleich- und Änderungsservice aktuell gehalten.
Ein vollständiger Jahr-2000-Konformitätstest enthält ferner die drei Phasen des Funktionstests, Integrationstests und des Externen-Partner-Tests (siehe Kasten "Phasen des Jahr-2000-Tests"). Dabei sind alle drei Phasen sogenannte Future-Date-Tests: Das Ausführungsdatum wird zum Beispiel auf den 3. Januar 2000 gesetzt, so daß sich mit einem dazu "gealterten" Testdatenbestand die Jahr-2000-spezifischen Testfälle durchspielen lassen.
Diese Vollständigkeit ist heute sicherlich nicht mehr zu erbringen. Das heißt aber nicht, daß man ganz und gar auf einen Test verzichten sollte. Ein geschäftsprozeßorientierter Test, der sich auf die risikobehafteten Teilbereiche konzentriert, ist auch jetzt noch möglich.
Wenn nichts mehr geht, muß ein Notfallplan her
Wenn solche Tests nur noch Teile der betroffenen Systeme funktionssicher machen können, gehört ein Notfallplan zum Pflichtenheft. Auch hier hat ein Unternehmen einen wichtigen Teil der Arbeit schon getan, wenn es folgende Fragen beantwortet:
-Sind nach einer Umstellung von Komponenten deren Jahr-2000-Risiken vollständig beseitigt? Oder gibt es Restgefahren?
-Müssen alle Systeme am 1. Januar um 0 Uhr abgeschaltet sein? Wenn ja, wer fährt sie wieder hoch?
-Mit welchen Fehlersituationen muß gerechnet werden?
-Sind die betreffenden Mitarbeiter erreichbar?
-Was tun, wenn Fest- und Mobilfunknetz überlastet und wichtige Ansprechpartner nicht erreichbar sind?
-Wie sind die Verantwortlichkeiten verteilt? Ist für alle Mitarbeiter ausreichend transparent, wer welche Entscheidungen treffen kann?
-Wurden zumindest die wahrscheinlichsten und gravierendsten Notfälle durchgespielt?
Wer für seine wichtigsten Geschäftsprozesse Jahr-2000-Tests und Umstellungen noch in Angriff nimmt, ist auf ein Projekt-Management angewiesen, das umgehend auf fehlende Kennzahlen reagiert. Es darf Vorgaben nicht als unumstößlich betrachten, denn viele Aufwandsdaten kristallisieren sich erst während des Projekts heraus. Damit sie umgehend in die Testplanung einfließen können, müssen sie systematisch erfaßt und bereitgestellt werden.
Bei einer großen deutschen Bank zum Beispiel hat die SQS ein spezielles Verfahren zur Zeiterfassung entwickelt, das kontinuierlich Daten über die laufenden Projektschritte sammelt. So wird erkennbar, wie sich die Ressourcen optimal verteilen lassen. In entsprechend konzentrierter Form beschleunigt dieses Vorgehen auch Kurzprojekte in den kommenden Wochen.
Dabei werden die Aktivitäten täglich notiert und wöchentlich ausgewertet. Für alle Mitarbeiter und Tätigkeiten gilt ein einheitliches Aktivitätenraster. Das Werkzeug auf Excel-Basis erfaßt die Zeiten, die für alle Aktivitäten gebraucht werden. Für die Einrichtung der Teststufen ist es wichtig, diese Raster erweiterungsfähig zu halten, um für neue, unerwartete Aktivitäten eigene Felder schaffen zu können. Die Erfahrung bei SQS zeigt, daß das Werkzeug schon nach kurzer Zeit alle Tätigkeiten adäquat abdeckt.
Ergebnis ist ein detailliertes Zeit- und Aufwands-Management, auf dessen Basis die Projektleitung erkennt, wieviel Ressourcen die Objekte in den unterschiedlichen Teststufen verbrauchen. Wöchentlich und selbst täglich kann dann neu entschieden werden, wo welche Ressourcen hinfließen und wo Verbesserungen eingeleitet werden müssen, zum Beispiel wo welche Mitarbeiter eingesetzt werden.
Mut zur Lücke
Wenn die Aufwandsdaten im Projektverlauf immer zuverlässiger werden, stellt sich die Frage: Was tun? Kann ich beispielsweise einzelne Testphasen einsparen, um schneller voranzukommen? Prinzipiell gilt: Fast alles ist möglich. Feste Vorgehensmodelle im Sinne einer reinen Abhaker-Mentalität sollen in Jahr-2000-Projekten ja gerade vermieden werden. Hier zahlt es sich aus, gute Inventarlisten zu besitzen und Geschäftsprozesse priorisiert zu haben - zum Beispiel über konzentrierte Jahr-2000-Assessments, die nicht länger als einen Tag dauern und über Checklisten feststellen, welche Funktionen sehr, welche wenig geschäftskritisch sind. Diese Bewertungskriterien erleichtern es dann, aus den erhobenen Aufwandsdaten die im Sinne der Wirtschaftlichkeit richtigen Schlüsse zu ziehen. Sie stärken den Mut zur Lücke. Unternehmen haben die Möglichkeit zu entscheiden, welche Maßnahmen übersprungen werden können und was sie andererseits unbedingt tun müssen, um jene Systeme fit zu halten, mit denen das Geschäft gemacht wird.
Phasen des Jahr-2000-Tests
1. Der Funktionstest betrachtet die Anwendungsfunktionen und weniger alle Verarbeitungsprozesse innerhalb einer Funktion, die Jahr-2000-abhängig ist oder durch ein Datum gesteuert wird.
2. Im Integrationstest geht es nicht um die einzelne Anwendung und ihre interne Struktur, sondern um den durchgängigen Ablauf des Geschäftsprozesses. Der Aufwand für diesen Check ist etwas geringer, durch die Integration unterschiedlicher Anwendungen und der Hardware jedoch komplexer. Er dokumentiert vor allem gegenüber dem Management oder der Wissensabteilung die Funktionsfähigkeit der Geschäftsprozesse.
3. Der Externe-Partner-Test ist ein unternehmensübergreifender Integrationstest, der Geschäftsprozesse überprüft, die nicht auf ein einzelnes Unternehmen beschränkt sind. Er wird vielfach im durch Geldströme stark vernetzten Bankenbereich eingesetzt und gefordert, zum Beispiel durch die Bundesbank.
*Dr. Martin Wieczorek ist Management-Berater für Software-Qualitäts-Management bei der SQS Gesellschaft für Software-Qualitätssicherung mbH in Köln.