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.

23.01.1997 - 

Datumsumstellung am Beispiel der Zürcher Kantonalbank

Für kluge Firmen beginnt das neue Jahrtausend jetzt

Keine Frage - das nächste Jahrtausend kommt bestimmt. Und wenn es dann soweit ist, dürfte es ein paar Jahre lang hilfreich sein, das neue Jahrhundert in jedem Datum zu nennen. Die Kleinigkeit kostet die Unternehmen Millionen. Nur um zwei zusätzliche Stellen in einem Datum einzufügen!

Ein typischer Problemfall: Die Jahreszahl in einem Aktenzeichen sorgt bislang für Eindeutigkeit und korrekte Sortierung. Das Jahr 00 dient als Kennzeichen für ein unbekanntes Jahr. Datumsdifferenzen werden in vorzeichenlosen Feldern gespeichert, und mit dem Ergebnis rechnet man ohne zusätzliche Bedingungen weiter.

Probleme tauchen dann auf, wenn Datumsdifferenzen ins Spiel kommen. Und das ist oft der Fall, wenn es ums Geld geht oder wenn die zeitliche Reihenfolge beziehungsweise der Datumsvergleich eine Rolle spielt. Was geschieht mit einer Überweisung vom 31. Dezember 1999, die erst im nächsten Jahrtausend bei der Empfängerbank eintrifft? Wird sie in 100 Jahren gebucht?

Kann es sich Ihre Firma leisten, mit Datumsangaben falsch zu rechnen - Lieferungen zu versäumen, unsinnige Rechnungen zu stellen oder sinnvolle gar nicht zu versenden? Im günstigsten Fall kosten die möglichen Fehler ein peinliches Telefonat, häufig aber auch Geld. Das Vertrauen der Kunden steht auf dem Spiel - im schlimmsten Fall die Existenz der Firma.

Das Problem ist im Grunde simpel, aber es läßt sich nicht lokal beheben. Rund 40 Prozent aller Programme haben direkt oder indirekt mit Datumsfeldern zu tun. Jeder einzelne Fall muß genau verfolgt werden. Schnittstellen zu externen Partnern und zu Standardpaketen bilden ein besonderes Gefahrenpotential, weil hier nicht nur die hauseigene Datenverarbeitung, sondern auch die Abstimmung mit Partnerunternehmen und Softwarelieferanten gefordert ist.

Die Zürcher Kantonalbank (ZKB) hat diese Problematik frühzeitig erkannt und Gegenmaßnahmen eingeleitet. Vor zwei Jahren bereits rief sie das Projekt JW2000 ins Leben.

Der erste Schritt bestand in einer Inventarisierung aller Systeme. Das stellte sich als ein zeitaufwendiges Unterfangen heraus. Projektleiter Peter Graf nennt die Gründe: "Unser Repository lieferte nicht alle für die Datumsproblematik benötigten Informationen. Und bis vor einigen Monaten existierten im Markt nur sehr wenige Tools, die ein Gesamtsystem bezüglich der Jahrtausendwende analysieren und das Ergebnis in geeigneter Form im Repository ablegen konnten."

Für die weiteren Phasen - Analyse, Planung, Behebung und Test - machte sich die ZKB auf die Suche nach geeigneten Verfahren und Tools. Mittlerweile gab es auf dem Markt auch eine Reihe von Dienstleistungsanbietern.

"Die Evaluation der einzelnen Angebote war für uns ein intensiver Prozeß", erinnert sich Graf. Zur Zeit unternimmt er mit seinem Team Pilotversuche für zwei wichtige Applikationen - jeweils mit drei verschiedenen Lösungsvarianten.

Wie Graf betont, galt es zunächst, viele Rahmenbedingungen abzuklären. Von entscheidender Bedeutung für die Umstellung sei zum Beispiel die Konversionstechnik. In Frage kommen hier Fensterlösungen wie "Excel", eine generelle Erweiterung auf vier Stellen oder "Bridging-Routine"-Applets, die vor der Weitergabe von Daten jeweils eine Konversion vornehmen.

"Unsere historischen Daten und Sicherungskopien müssen nach der Konversion weiterhin verfügbar und einsetzbar sein", erläutert der Projektleiter. Zudem seien einheitliche Standards unabdingbar, die teilweise wiederum vom Konversionsverfahren abhingen.

Bis Ende des Jahres will sich die ZKB für eine Problemlösungs-Umgebung entschieden haben. Die Bank erwartet, die Umstellung bis zum 31. Dezember 1998 abgeschlossen zu haben. "Somit verbleibt uns ein Jahr Zeit, um das System eingehend zu beobachten und mögliche Diskrepanzen zu bereinigen", legt Graf dar.

Die ZKB kann also davon ausgehen, daß sie Silvester 1999 keine unangenehmen Überraschungen erleben muß. Für die Unternehmen, die jetzt erst mit der Vorbereitung auf den Jahrtausendwechsel beginnen, kann dagegen die Zeit knapp werden. Wer damit noch nicht angefangen hat, sollte als ersten Schritt die technischen, unternehmerischen und wirtschaftlichen Ziele klar definieren.

Wie lassen sich Zeit und Kosten sparen? Zum Beispiel werden manche Applikationen oder Teile davon bis zur Jahrtausendwende abgelöst und müssen nicht mehr betrachtet werden. Zudem läßt sich die Jahrtausendtauglichkeit im regulären Wartungszyklus prüfen. Außerdem kann die Neuerstellung einer Software günstiger sein als eine Reparatur.

Frühzeitige Planung ist das A und O

Nach Einschätzung der Gartner Group besteht in diesen Bereichen ein Einsparungspotential von bis zu 40 Prozent. Realisierbar ist es aber nur, wenn eine sehr gründliche Inventarisierung und Analyse der bestehenden Systeme vorgenommen wird.

Bei der Fremdsoftware kann der Release-Wechsel passend zur Umstellung der internen Systeme eingeplant werden. Analyse und Inventarisierung lassen sich am einfachsten und sichersten mit Hilfe spezieller Werkzeuge erledigen. Um Erfahrungen mit den jeweiligen Tools zu gewinnen, sollte eine repräsentative Anwendung ausgewählt werden. Dabei treten auch die speziellen Probleme der vorhandenen Softwarelandschaft zutage.

A und O der Umstellung ist jedoch die frühzeitige Planung der Tests mitsamt der Einführung aller notwendigen Werkzeuge. Übereinstimmend schätzen alle bekannten Untersuchungen die Testphase mit 40 bis 50 Prozent des Gesamtaufwandes ein.

Die Simulation des Jahrtausendübergangs läßt sich leider nicht durch simples "Vorstellen" der internen Uhr erreichen. Vielmehr ist es unabdingbar, daß die Datenbasis insgesamt zum simulierten Systemdatum paßt. Beispielsweise müssen Buchungssätze in der richtigen Periode liegen und Zugriffe auf Schlüsseltabellen exakt zum Stichtag erfolgen.

Bei der Zürcher Kantonalbank stammt nur bei jedem fünften Datumsfeld der Inhalt von der internen Uhr des Systems ab. Es ist also wichtig, in der Analysephase die Originalquelle für jedes einzelne Datumsfeld festzustellen.

Der Test selbst sollte zumindest drei Fragen beantworten: Läuft das System bei allen Verarbeitungen bis zum Jahrtausendwechsel korrekt? Funktioniert es während des Wechsels fehlerlos? Und liefert es auch im kommenden Jahrtausend richtige Daten?

Experten wie Ken Orr, Vorstand des Ken Orr Institute, und Larry Martin, Präsident der Data Dimensions Inc., rechnen bei US-Konzernen mit Kosten von 35 bis 40 Cent pro Codezeile. Das ergibt bis zu 100 Millionen Dollar pro Unternehmen.

Ist mit diesen immensen Kosten wirklich kein Nutzen verbunden - außer der Gewißheit, reibungslos und verlustfrei in das nächste Jahrtausend zu wechseln? ZKB-Manager Graf sieht das anders. Aus der Tatsache, daß flächendeckend alle Applikationen geprüft und teilweise überarbeitet werden, leitet er Chancen für einen zusätzlichen Nutzen ab:

Beispielsweise können unternehmensweite Standards bereinigt und einheitlich durchgesetzt werden. Auch ein allgemeinverbindliches Repository lasse sich auf diese Weise aufbauen. Die Einführung fortschrittlicher Re-Engineering-Verfahren wird ebenfalls wahrscheinlicher. Und last, but not least gewinnen die ungeliebten Maintenance-Arbeitsplätze an Renommee./*Hauke Kiesswetter ist Systemanalytiker bei der Geschäftsstelle Wettingen der Integrata AG, Stuttgart