Die Ergebnisse der Befragungen unter IT-Managern sprechen eine deutliche Sprache: Einerseits ist sich nahezu jeder der Tatsache bewußt, daß das Problem 2000, amerikanisch gekürzt zu Y2K, sowie die Einführung des Euro die DV und damit das Unternehmen lahmlegen können. Andererseits ist erst ein Drittel der Firmen bei der konkreten Umsetzung angelangt. Rund zwei Drittel haben nicht einmal ein fertiges Konzept.
Schmerzliche Erfahrungen haben bereits einige Vorreiter-Unternehmen gemacht, die das Jahrtausendproblem und die Euro-Einführung parallel zu lösen versuchten. In einer Studie der Europäischen Kommission gab ein Großteil der 800 befragten IT-Manager zu Protokoll, daß sich diese Vorgehensweise als falsch erwiesen habe.
Der Grund ist, daß es sich beim Y2K-Projekt um ein rein technisches Problem handelt, die Einführung des Euro dagegen ein Business-Problem darstellt, also vor allem Geschäftsprozesse betroffen sind. Demzufolge sind für beide Projekte spezifische Strategien notwendig, die aber aufeinander abgestimmt werden und ineinander greifen müssen.
In den USA sorgt derzeit ein Modell für Furore, das IT-Leitern bei der Problemlösung helfen kann. Gearbeitet wird wie bei einem Rettungsdienst ("Triage"). So werden Rettungssanitäter dahingehend ausgebildet, folgende Fragen zu stellen, das sogenannte "Triage"-Verfahren: 1. Wer überlebt ohne Hilfe? 2. Wer hat trotz Hilfe keine Überlebenschance? 3. Wer wird nur überleben, wenn er Hilfe erhält?
Die Fragen 1 und 2 werden ad acta gelegt; der Rettungsdienst konzentriert sich auf Betroffene der Kategorie 3. In die IT-Nomenklatur übertragen heißt das, Unternehmen müssen eine Klassifizierung der einzelnen Applikationen vornehmen, um die wirklich "überlebenswichtigen" Anwendungen zu identifizieren.
Das Triage-Verfahren ist dabei auf die ersten beiden Phasen des "klassischen" Umstellungsprozesses für das Jahr 2000 und den Euro anzuwenden. In der Stufe 1 ("Inventory") wird analysiert, welche Applikationen funktional notwendig sind. Die zweite Stufe ("Assessment") umfaßt eine erste Abschätzung der Probleme, wo sie zu erwarten sind und welcher Aufwand zu ihrer Lösung nötig sein wird. Gerade an diesem Punkt sind mit Hilfe des Triage-Modells erste Rückschlüsse auf den tatsächlichen Handlungsbedarf möglich: Ist es absehbar, daß sich eine "Mission-critical"-Anwendung nicht mehr rechtzeitig konvertieren läßt? Bevor hier wertvolle Zeit verlorengeht, läßt sich eine Alternativlösung meist über die Standardsoftware finden.
Dann geht es über die Triage-Methode hinaus. In der dritten Stufe, "Remediation" genannt, erfolgt die aktive Umstellung, wobei es verschiedene Methoden je nach Anwendung zu unterscheiden gibt. In der Testphase, dem vierten Schritt, werden die Konvertierungen von der Modul- über die Applikations- bis hin zur Geschäftsebene sowohl unter Last- als auch Performance-Aspekten überprüft. Den Abschluß bildet dann die "Deployment"-Phase, also der Einsatz des Systems unter realen Bedingungen.
Gerade in Deutschland verharren noch zu viele Unternehmen in der Inventory- oder Assessment-Phase. Manager sind immer noch auf der Suche nach weiteren Informationen, um die endgültigen Entscheidungen - und damit auch die Kosten - zu rechtfertigen. Nur wenige haben es bislang geschafft, bis zur Remediation- oder gar Testphase vorzudringen. Unternehmen, die bis heute gewartet haben, können den Zeitverlust nur noch durch die Einstellung zusätzlicher Entwickler kompensieren oder ganze Projekte an Dienstleister auslagern.
Die Uhr tickt - es spielt keine Rolle, ob man eine Minute, einen Tag oder eine Woche zu spät mit den Projekten fertig wird. Doch die Unannehmlichkeiten beginnen nicht erst mit dem 1. Januar 2000. Bereits heute treten immer öfter Probleme bei Anwendungen und Rechenoperationen auf, die über das Jahr 2000 hinausgehen. Die Gartner Group beschreibt dieses Problem als "Time Horizon to Failure" (THF).
Dual Use, wo immer es möglich ist
Trotz zahlreicher Horrorszenarien ist für die meisten Unternehmen der Zug noch nicht abgefahren. Um wertvolle Zeit bei der Lösung des Y2K- und Euro-Problems aufzuholen, sollte die Testphase schon von Beginn an in die Planungen einbezogen werden. Gerade beim Assessment lassen sich Testwerkzeuge parallel einsetzen (das ist eben "Dual Use"), um eine Klassifizierung der Applikationen und damit einen Überblick über die Lebensadern des DV-Systems zu gewinnen.
Die klassische Methode besteht darin, mit Hilfe eines Analyzers die Programmteile herauszufiltern, deren Programmcodes Änderungen nötig haben. Dies bezeichnet man auch als "White-box"-Verfahren. Am einfachsten ist es, die bestehende Software auf dem jetzigen System mit einer sogenannten Zeitreise in die Zukunft zu schicken. So läßt sich testen, was funktionieren wird und was nicht. Hierfür gibt es den Ausdruck "Black-box"-Verfahren.
Der Einsatz automatisierter Testwerkzeuge spart Zeit. Die Projektteams Euro und Y2K können dieses Vorgehen parallel durchführen, ohne jedoch gleichzeitig an den gleichen Programmteilen zu arbeiten.
Die Abbildung verdeutlicht, daß die Testläufe so früh wie möglich einsetzen sollen. Obwohl zum Beispiel Andrew Dailey, Consultant bei der Gartner Group, für die Umstellung auf den Euro den zwei- bis sechsfachen Aufwand im Vergleich zum Problem 2000 veranschlagt, ist der Jahrtausendumstellung absolute Priorität einzuräumen.
Garant für eine erfolgreiche Umstellung der Systemstrukturen ist, beide Projekte klar voneinander zu trennen. Auf der einen Seite herrscht für die Euro-Umstellung das Diktat der Projekt-Manager mit fundierter Erfahrung im Bereich Geschäftsprozeß-Optimierung. Auf der anderen Seite sind für das Jahr 2000 Programmierer und Software-Entwickler zuständig. Entscheidend ist, daß eine übergeordnete Instanz als Koordinierungsstelle geschaffen wird. Diese protokolliert die Schritte der einzelnen Teams und schafft Freiräume für Synergien. Das Gebot der Stunde heißt Risiko-Management durch die Betrachtung von zwei Seiten.
Besonders kritisch sind Anwendungen, deren Module beiden Umstellungen - also Y2K und Euro - gewachsen sein müssen und demzufolge überlappend zu bearbeiten sind. Beispiele hierfür sind Abrechnungswesen, Materialwirtschaft, interne Verrechnungen, Fakturierung etc. Beim Test läuft wieder alles zusammen - um so wichtiger ist es deshalb, immer wieder den Status quo der beiden Projekte zu analysieren.
Von selbst lassen sich die Probleme Y2K und Euro nicht lösen. Zumindest ist aber eine gewisse Sicherheit im Sinne von Projektkoordination und -überblick als Planungs- und Management-Grundlage möglich. Testen läßt sich allerdings, ob die Geschäftsprozesse laufen. Aber auch hier ist Vorsicht geboten.
Denn kein Test-Tool wird in der Lage sein, eine 100prozentige Trefferquote zu liefern. Dies ist zum Teil allein schon aufgrund der System-Schnittstellen nicht möglich; beispielsweise erfordert der Dialogbetrieb andere Testwerkzeuge als die Batch-Prozesse. Das schwächste Glied einer Testkette ist immer das Erkennen der Felder (Y2K: Datum) und deren Abhängigkeiten (Euro: Eingliederung in komplexe Prozesse).
Der Schlüssel zum Erfolg liegt darin, die Applikationen wiederholt unter verschiedenen Aspekten und mit unterschiedlichen Methoden zu testen. Trotz der Leistungsfähigkeit moderner Systeme wird es sich nicht vermeiden lassen, manuell nach verborgenen Programmzeilen und -feldern zu suchen. Denn schon eine Fehlerrate von einem Promille kann bei der Masse der Codezeilen zum Verhängnis werden.
Funktionalität und Kompatibilität der modifizierten Applikationen sind noch keine Garantie für einen reibungslosen Ablauf. Wenige Millisekunden Bearbeitungszeit geraten bei 500 Nutzern mit gleichzeitigem Zugriff auf eine Applikation mit 1000 Operationen schnell zu einem Flaschenhals. Deswegen müssen die Systeme einer hohen Belastung unter Praxisbedingungen ausgesetzt werden. Der Lasttest sollte daher die Anzahl der Anwender, die verschiedenen Transaktionen sowie die Lastverteilung berücksichtigen. Je besser diese drei Faktoren in ein und demselben Test berücksichtigt werden, desto effektiver ist die Systembeurteilung.
Die Performance-Analyse ist speziell bei überlappenden Modulen für Y2K und Euro immens wichtig. Beim Testen der Belastung für ein komplettes System sind diverse Faktoren innerhalb der Architektur zu berücksichtigen: die Kapazität der Applikations-Server, Netzwerkbandbreite, Interoperabilität und schließlich Skalierbarkeit.
Testen heißt immer auch Experimentieren. Nicht alle Versuche führen zum geplanten Ergebnis. Abweichungen aufzudecken ist eines der elementaren Ziele eines jeden Tests. An dieser Stelle muß eine fachliche Auswertung durch einen Experten erfolgen: Handelt es sich bei der Abweichung wirklich um einen Fehler oder nicht?Auf der Basis dieser Prüfung lassen sich dann die Gründe für das Fehlverhalten analysieren.
Das Testen der Y2K- und Euro-Kompatibilität erfordert zudem einen Blick über den Tellerrand hinaus. So ist es durchaus denkbar, daß die eigenen Systeme den Kompatibilitätsanforderungen entsprechen - wie verhält es sich aber mit den Systemen von Kunden, Lieferanten etc.? Auch hier lautet das Gebot der Stunde Test-Management.
Der doppelte Gebrauch von Werkzeugen bei der DV-Umstellung für Y2K und Euro hängt von der zugrundeliegenden Strategie ab. Im Bereich Test-Management ist der Wiederverwendung unter Kosten-Nutzen-Aspekten zuzustimmen. Für das Testen der Y2K- und Euro-kompatiblen Applikationen sollte jedoch eine Kombination verschiedener Methoden und Tools zum Einsatz kommen.
Angeklickt
Nach allen bekannten Daten dürften mehr Manager ihre Planungen für die Millenium-Silvesterparty abgeschlossen haben als die zur Umstellung der IT auf das Jahr 2000. Leider ist das nicht das einzige Problem. Fast gleichzeitig kommt der Euro und fordert weitere Zusatzarbeiten der DV-Spezialisten und finanzielle Mehrbelastungen der Unternehmen. Entgegen dem Rat der meisten erfahrenen Anwender versuchen viele Firmen angesichts der drängenden Termine, beide Modifikationen in einem Zug durchzuführen. In einigen Punkten gibt es tatsächlich Möglichkeiten, Zeit und Geld zu sparen - vor allem im Rahmen der aufwendigen Tests.