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.

21.01.2000 - 

Y2K-Konsequenz: Definition einer IT-Strategie

Anwender ziehen Lehren aus Jahr-2000-Projekten

MÜNCHEN (ls) - Nachdem das Jahr-2000-Chaos ausgeblieben, eins der komplexesten IT-Projekte der letzten Jahres gut ausgegangen ist, ergibt sich die Frage, welche Schlüsse aus dem Erlebten gezogen wurden. Eine CW-Umfrage zeigt, dass der Druck des Alltagsgeschäfts wenig Spielraum für Konsequenzen lässt.

Aufatmen haben sie können, durchatmen noch nicht. Die IT-Spezialisten sind, wenige Tage nachdem die DV-Systeme in ihren Unternehmen den Wechsel ins Jahr 2000 unbeschadet oder nur mit kleinen Störungen überstanden haben, kaum zur Ruhe gekommen. Die Erleichterung ist groß, aber die Alarmstimmung nicht ganz verflogen. Manche Fehler können erst in diesen Tagen auftreten, und der nur alle vier Jahre eintretende Schaltjahrestag am 29. Februar 2000 wird nicht vergessen.

Gleichwohl dürften gerade die Erfahrungen aus einem außerordentlich kritischen und großen Projekt wie der Jahreszahlen-Umstellung zu wertvoll sein, als dass man nunmehr zur Tagesordnung übergehen könnte. "Man müsste die Leute zum Bier einladen und fragen: Was können wir daraus lernen? Wo haben wir die größten Schwierigkeiten gehabt?" bedauert Jürgen Rehmer, Leiter Prozessdatenverarbeitung bei den Stadtwerken Hannover: "Uns fehlt aber dazu einfach die Zeit."

Das wird auch andernorts festgestellt, heißt jedoch nicht, dass IT-Verantwortliche unbeachtet aller Y2K-Erlebnisse blind in die Zukunft tapsten. Aus den Erfahrungen sind Schlüsse gezogen worden. An erster Stelle wird "Standardsoftware" genannt.

An diesem Punkt etwas genauer nachzuhaken fördert ein differenzierteres Bild zu Tage. Die Einführung von Standardsoftware ist entgegen einer naheliegenden Annahme nicht von Datumsunsicherheiten mit eigenentwickelten Programmen veranlasst worden. So meint Peter Klukas, Mitarbeiter im Bereich Organisation und IV der AEG Lichttechnik in Algermissen: "Die Entscheidung für Standardsoftware ist durch Jahr-2000-Probleme mit selbst geschriebenen Programmen nicht motiviert, sondern allenfalls beschleunigt worden."

Viele Anwender nehmen nach den Erfahrungen der Umstellungsarbeiten Abstand von größeren Modifikationen der Standardsoftware. "Man sollte nur dann Sonderlösungen einbauen, wenn es wirklich notwendig ist", resümiert beispielsweise Sieghard Thomas, Leiter Materialwirtschaft beim Schweißtechnik- und Roboter-Systemhersteller Kloos in Haiger. Selbst dann würde er zunächst auf dem Markt nach vorhandenen Lösungen Ausschau halten. "Das werden wir uns auf die Fahne schreiben."

Auch Reinhard Mittelstedt, DV-Leiter der Münchner Paulaner-Brauerei, fühlt sich in seiner Maxime "Standardsoftware mit möglichst wenig flankierenden Eigenentwicklungen" bestätigt: "Was so nicht abgewickelt werden kann, sollte man lassen. Da sind organisatorische Lösungen gefragt. Das ist einfacher und geht genauso gut."

Eine weitgehende Beschränkung auf Standardsoftware verhindere außerdem, dass die IT-Abteilungen einem bei Jahr-2000-Projekten häufig aufgetretenen Problem schon bald wieder begegnen: der unvollständigen Dokumentation. Mittelstedt über den Vorteil seiner Standardsoftware: "Wenn wir mehr Eigenentwicklungen hätten, würden wir jetzt sicher sagen: Wir müssen besser dokumentieren."

Üble Erfahrungen hat diesbezüglich ein Hamburger DV-Leiter gemacht, der stets Wert auf Dokumentation legte: "Dokumentiert wird nur, solange Zeit dafür ist. Wenn etwas in Eile ausartet, kann es passieren, dass wieder Probleme entstehen."

Darüber hinaus lassen sich kaum Konsequenzen für die eigene Softwareentwicklung erkennen. Kein Anwender erklärte, künftig bestimmte alte Programmiersprachen nicht mehr verwenden zu wollen. Ebenso wenig stehen antiquierte Datenbanksysteme zur Disposition.

Allenfalls tut sich etwas beim Testen neuer Anwendungen. Jens-Peter Brand vom Lampertheimer Entwicklungsbüro für KfZ-Produktionsanlagen Schreiber, Brand und Partner bekundete: "Wir werden in Zukunft noch genauer testen." Allerdings plant er deswegen noch nicht die Anschaffung neuer Testing-Tools. Denen steht er skeptisch gegenüber: "Man muss ein Tool gut verstanden haben, um letztlich darauf aufbauend zu arbeiten."

Mit der Bekundung, er "vertraue mehr auf unser eigenes Know-how", trifft Brand den Kern der Aussagen diverser Anwender aus kleineren und mittelgroßen Unternehmen. Viele IT-Verantwortliche verzichteten wohl nicht zuletzt wegen der Überschaubarkeit ihrer Eigenentwicklungen auf die teuren Y2K-Tools.

Ein etwas anderes Bild ergibt sich bei Großanwendern, wo es viele selbstgeschriebene und geschäftskritische Programme gibt. Hier waren Spezialwerkzeuge allerdings wegen der Heterogenität der Umgebungen oftmals ungeeignet, oder die Umstellungsteams wussten sich mit dem vorhandenen Instrumentarium zu helfen. Die Lehren aus Jahr-2000-Projekten bestehen vor allem in der Einsicht, Testverfahren, -werkzeuge und möglichst auch -daten vereinheitlichen zu müssen. So hält es Bernd Derscheid, Projektkoordinator "Datum 2000" bei der Nürnberger Bundesanstalt für Arbeit, für "wünschenswert, wenn die einzelnen Projekte das gleiche oder ähnliche Tools verwenden würden". Unterschiedliche Testdatensätze seien ein weiteres Manko.

Wesentlich weiter ist offenbar die Frankfurter DG Bank. Deren Projekt-Manager "D2000", Thomas Brandhofe, berichtet: "So etwas wie einheitliche Testverfahren nach IEEE-Standard für verteilte und Host-Anwendungen gab es bei uns früher nicht. Die hierfür erforderliche Infrastruktur wurde aufgebaut und hat sich seitdem sehr bewährt. Eine eigene Organisationseinheit, das Integrations-Test-Center, stellt die Infrastruktur für alle Anwendungsentwicklungsprojekte als Dienstleistung zur Verfügung."

Qualität der Software zeigt sich auch daran, wie lange sie verwendbar ist. Der Hannoveraner Stadtwerke-Mitarbeiter Rehmer betont die Y2K-Lehre, "dass Software ein Haltbarkeitsdatum hat. Sie erreicht mit der Zeit immer ihre Grenzen hinsichtlich Lizenzdauer, nutzbarem Festspeicher, File-Größen." Das hat Konsequenzen für die Softwareanbieter. "Wir müssen in die Lizenzen hineinschreiben, dass die Software nicht von internen Zählern, Verwaltungstabellen etc. begrenzt wird."

Rehmer, der mit einem spektakulären öffentlichen Test seiner Echtzeitsysteme (siehe CW 12/98, Seite 4) wesentlich zum Problem-2000-Bewusstsein hierzulande beigetragen hat, weiß seit dem Umstellungsprojekt genauer, was ihm zur Verfügung steht, welche Ressourcen noch zu nutzen sind und wo die Grenzen sind. Er nennt "Inventarisierung" als einen bedeutenden Gewinn aus dem Kampf gegen Unwägbarkeiten der Systeme, weil das nun einmal die Grundlage jeder über den Tag hinausgehenden IT-Strategie sei.

Kenntnis der Software im Kontext der Geschäftsprozesse ist für die DG Bank das A und O. "Das Jahr-2000-Problem hat die Konzentration auf die Geschäftsprozesse verstärkt", erklärt Projektleiter Brandhofe. "Die Kenntnis der Kerngeschäftsprozesse und ihrer Schnittstellen ist entscheidend, um beim Ausfall einer Anwendungs- oder Systemkomponente schnell reagieren zu können."

Das Projektteam bei der DG hatte noch vor eineinhalb Jahren zwei Drittel der Anwendungen als nicht jahrtausendfähig klassifiziert. Insgesamt wurden rund 400 Anwendungen samt ihrer Hard- und Softwareplattform fit gemacht. Dabei lag nach einer Top-down-Analyse der Schwerpunkt auf 70 Kernanwendungen, auf denen 125 Bankprodukte basieren. "Die gewonnenen Erkenntnisse", merkte das Team dezent an, "sind umfangreich dokumentiert."

Die Einsicht hat nicht nur ihren Weg aufs Papier gefunden. Inzwischen gibt es ein auf den merkwürdigen Namen "Bebauungsplan-Management" getauftes Verfahren, das - per Software zu kontrollieren - eines sicherstellen soll: Strategische Business-Entscheidungen aus dem Bankvorstand sollen nachvollziehbar und kontrolliert in Projekten und bis auf die Ebene der einzelnen Anwendungen ihren Niederschlag finden. Das Wissen über die Systeme ist Voraussetzung für eine Konzentration auf Geschäftsprozesse.

Das genauere Bild der aktuellen IT-Lage könnte allerdings auch Anlass zu einer weitergehenden kritischen Analyse der IT-Politik sein. So fordert Derscheid: "Klar geworden ist die gewaltige Abhängigkeit von diesen Systemen - und dass niemand in der Lage ist, sie komplett zu überblicken und zu wissen, was sich an den einzelnen Ecken und Enden tut. Man muss sich Gedanken machen, wie man damit in Zukunft umgehen kann. Sollte man nicht besser bestimmte Dinge transparenter machen, ist mehr Wert auf Dokumentation oder auf eine strukturierte Vorgehensweise zu legen?"