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.

14.11.1997 - 

Problem 2000 Personaleinsatz, Kommunikation und Auslagerung (Teil 3 und Schluß)

Erfahrungen eines Projektleiters bei der Jahr-2000-Umstellung

Viele IT-Spezialisten und Manager glauben, Jahr-2000-Projekte seien eine einmalige lästige Ablenkung von den vielen anderen wichtigen DV-Aufgaben, die nur den Vorteil habe, zeitlich begrenzt zu sein. Da ist die Versuchung groß, diesen Arbeiten Personal zuzuteilen, das nicht unbedingt als das Beste in der Organisation gilt oder auf seine Pensionierung wartet. Dies wird den Erfolg des Jahr-2000-Projekts gefährden.

Aufgrund des engen Zeitrahmens und der Komplexität des Problems sind motivierte und mitdenkende Fachkräfte wichtig. Ebenso sollte das Team nicht aus mehr als fünf bis zehn Prozent unerfahrenen Mitgliedern bestehen. Das Jahr-2000-Projekt ist eine Gelegenheit, neue Mitarbeiter zu schulen, zu viele machen das Projekt allerdings ineffektiv.

Es ist sehr nützlich, wenn Mitarbeiter je nach Bedarf mehrere Positionen ausfüllen können. Viele Mitglieder unseres Teams können ebensogut eine Anwendung analysieren und umstellen wie die JCL einrichten oder Benutzertests unterstützen. Solche Anforderungen erfüllen nur gute und erfahrene Mitarbeiter, die schnell lernen.

Nicht weniger wichtig ist es, die verschiedenen Positionen mit den richtigen Leuten zu besetzen. Insbesondere sind alle Mitglieder unserer Gruppe, die die Benutzertests durchführt, aus den entsprechenden Fachbereichen des Unternehmens. Sie werden von technischem Personal mit Testerfahrung unterstützt. Wir glauben, daß dies effektiver ist, als Personal aus dem Testteam beizubringen, wie ein Anwendungssystem richtig zu bedienen ist.

Viele Organisationen in Europa werden nicht ausreichend Personal für die Umstellungsaufgaben haben. Eine allgemein übliche Lösung besteht darin, die Arbeiten teilweise oder komplett an ein externes Unternehmen auszulagern. Wir haben - was in Deutschland noch nicht so verbreitet ist - die Unterstützung eines indischen Softwarehauses in Anspruch genommen, das zu den größten des Landes gehört. Allerdings glauben wir, daß die traditionellen Modelle der Arbeitsteilung nicht optimal für Jahr-2000-Projekte sind.

In der Regel übergibt der Kunde Spezifikationen und Testskripts an das externe Team, und ein entwickeltes und getestetes System wird zurückgeliefert. Dieser Ansatz ist für ein Jahr-2000-Projekt ungeeignet. Denn in den meisten Umstellungsprojekten gibt es keine aktuelle Dokumentation der betroffenen Systeme. Daher verlangt die Umstellung schnellen und unmittelbaren Zugang zu unternehmensinternem IT- und anderem Personal, das mit dem umzustellenden System Erfahrungen hat.

Ungenutzte Arbeitszeit ist die wichtigste Ressource eines Jahr-2000-Projekts. Wenn man einige Tage auf eine Entscheidung über ein paar Datumsformate warten muß, bevor die Umstellung weitergehen kann, wird das weitere gravierende Verzögerungen an anderer Stelle zur Folge haben.

Das am Ende umgestellte System kann beispielsweise nicht zur reservierten Zeit in weitere Modifikationsprozeduren oder in den Test gehen. Solche Verzögerungen lassen sich auf ein Minimum reduzieren, wenn der Teil der Aufgaben, der Zuarbeit von anderem IT-Personal oder Anwendern im Unternehmen erfordert, vor Ort erledigt wird.

Ein weiterer Grund, der gegen das klassische Modell spricht, Projekte auszulagern, sind Sicherheitsbedenken, weil Anwendungscode das Unternehmen verläßt und ins Ausland geht.

Wir haben uns daher für ein anderes Modell entschieden. Es hat sich bewährt, einheimische und externe Mitarbeiter in einem quasi gemischten Team zusammenzufassen. Die Teammitglieder in England und unser Personal in Indien arbeiten auf derselben Mainframe und verwenden dieselben Entwicklungsumgebungen, Versions-Management-Systeme sowie sonstigen Tools.

Die beiden Standorte sind über eine 64-Kbps-Satellitenschaltung verbunden, die sowohl Daten- als auch Audioübertragung ermöglicht. Dieser Ansatz nutzt auch die Zeitverschiebung zwischen Großbritannien und Indien. Ein Teil des indischen Personals arbeitet am Unternehmensstandort in England. Das externe Team kann so schneller Know-how über die umzustellenden Anwendungssysteme sowie die Entwicklungsumgebung und -prozeduren des Kunden aufbauen.

Diese Vorgehensweise erlaubt eine logische Arbeitsteilung. Unser hiesiges Team ist verantwortlich für die Inventur, die Auswirkungsabschätzung und die durch ein Tool unterstützte automatisierte Code-Umwandlung. Es ist außerdem sowohl für die System- und Anwendertests als auch für die Unterstützung der Inbetriebnahme des umgestellten Systems zuständig. Das externe Team erledigt manuelle Code-Änderungen, Compilierungen und Einzeltests.

So sind wir in der Lage, mit unseren Personalressourcen sehr effektiv umzugehen: Das Personal des britische Umstellers setzt sein besseres Wissen über Geschäftsabläufe, Systemdetails und die Anwendungen ein. Das externe Team bringt Mainframe-Analysten und Programmierer für jene allgemeineren Aufgaben ein, die kein tieferes Anwendungswissen erfordern, aber sehr arbeitsaufwendig sind.

Man muß das Personal in einem Jahr-2000-Projekt so einsetzen, daß es die höchste Effizienz erzielt, denn fähige Mainframe-Analysten und -Programmierer werden immer rarer und teurer. Daraus folgt im übrigen, daß die nächste Herausforderung darin besteht, dieses Personal zu halten.

Ein Jahr-2000-Projekt unterscheidet sich in vieler Hinsicht nicht von anderen IT-Projekten, jedoch hat es einige Eigenarten, die mehr größere Ansprüche stellen als üblich: Eine besteht darin, daß man es mit Systemen zu tun hat, die teilweise 20 Jahre alt sind. Wenn die dann auch noch in den letzten Jahren ohne Probleme oder Verbesserungsarbeiten in Betrieb waren, gibt es in der IT-Abteilung möglicherweise niemanden mehr, der etwas über diese Systeme weiß.

In einem extremen Fall haben wir einige Nachforschungen anstellen müssen, um die einzige noch im Unternehmen verbliebene Person ausfindig zu machen, die wußte, welche Parameter für den Start der JCL eines Systems zu verwenden sind. Es war niemand aus der IT-Abteilung, sondern der einzige Benutzer des Systems.

Kommunikation ist in unserem Projekt besonders wichtig, weil wir nicht die Fortentwicklung eines Systems einfrieren können, während die Umstellung stattfindet. Dies würde die Fähigkeit des Unternehmens, seine Systeme im Hinblick auf Veränderungen der Geschäftsumgebung zu verbessern, ernsthaft beeinträchtigen. Intensive Kommunikation mit allen anderen laufenden und geplanten IT-Projekten ist unumgänglich, um sicherzustellen, daß die Zeitfenster für die einzelnen Umstellungsarbeiten an anderen Stellen keine Konflikte und unnötigen Aufwand mit sich bringen.

Es ist jedoch nicht vollständig auszuschließen, daß während einer Umstellung ein anderes DV-Team beispielsweise aufgrund eines Ausfalls oder einer dringenden Verbesserung das gleiche System ändern muß. So kann es in der Finanzwirtschaft Gesetzesänderungen geben, die schnell zu implementieren sind.

Kommunikation ist auch noch unter einem anderen Aspekt wichtig: Das Jahr-2000-Projekt soll allgemein die Aufmerksamkeit für die Problematik im Unternehmen fördern, um von möglichst vielen Seiten Hinweise auf kritische Aspekte zu erhalten. Zu diesem Zweck veröffentlichen wir regelmäßig einen Newsletter für jeden Mitarbeiter, nicht nur für das IT-Personal.

Außerdem wird die Verantwortung für die weitere Wartung der Jahr-2000-tauglichen Systeme auf andere Teams und Abteilungen übertragen. Die frühe Einbindung projektfremden Personals vereinfacht dessen spätere Einarbeitung und ermöglicht es, Wissen zu übertragen sowie die Akzeptanz der Systeme zu gewährleisten. Wir ziehen daher selbst projektfremde IT-Spezialisten regelmäßig zu Entscheidungen über Änderungen mit heran. Eine rege Kommunikation aufrechtzuerhalten war eine der größten Herausforderungen in diesem Projekt.

Im Verlauf des Projekts haben wir viel über Verfahren gelernt. Wo immer es möglich war, haben wir versucht, Vorgehensweisen bei der Umstellung zu verbessern. Beispielsweise folgten bestimmte Abläufe eher einem starren Schema, waren aber arbeitsintensiv. Ein Teammitglied hat einige Hilfsprogramme entwickelt, um diese Vorgänge zu automatisieren, so daß die Arbeiten jetzt nur noch die Hälfte der Zeit und 20 Prozent des ursprünglichen Aufwands benötigen.

Außerdem wurden Aufgaben im Team neu verteilt, um Engpässe im Umstellungsprozeß zu reduzieren, die beim Einrichten von Systemen und beim Testen auftreten können. Da sich der grundlegende Umstellungsvorgang immer wiederholt, läßt er sich optimieren. Wir glauben gleichwohl, daß sich die für den eigentlichen Umwandlungsprozeß nötige Zeit noch weiter reduzieren läßt.

Jahr-2000-Projekte gelten als kostenintensive Arbeiten ohne meßbaren Geschäftsvorteil. Sicherlich besteht ihr primäres Ziel darin, die Risiken eines DV-Ausfalls für das Funktionieren oder gar das Bestehen des Unternehmens möglichst auszuschließen. Doch darüber hinaus führen sie insbesondere im Wartungsbereich zu einer Reihe von Vorteilen - und zwar auch dann, wenn man der eindringlichen Empfehlung folgt, nicht andere Vorhaben mit der Umstellung zu verknüpfen.

Die DV wird im Rahmen eines Jahr-2000-Projekts endlich auf einheitliche und aktuelle Versionen zentraler Software wie MVS, Cobol, CICS, IMS etc. gebracht. Wenig benutzte Sprachen - und damit Lizenz- und Wartungskosten - können entfallen. Eine Anzahl von Programmen in heute obskuren 4GL-Sprachen werden beispielsweise in Cobol/CICS umgeschrieben oder ganz abgelöst. Ebenso lassen sich redundante Jobs und Programme entfernen. Des weiteren steht künftig ein unternehmensweiter Testrahmen zur Verfügung, der Testskripts, -daten und -werkzeuge umfaßt. Dieser läßt sich beispielsweise für EWS-bezogene Arbeiten wiederverwenden.

Es gibt viele Faktoren, die zum Erfolg eines Jahr-2000-Projektes beitragen. Insbesondere aber sind zwei hervorzuheben: Fokussierung und Schwungkraft. Ersteres bedeutet, sich nicht vom Ziel, das System bis zum vereinbarten Zeitpunkt Jahr-2000-tauglich zu machen, ablenken zu lassen. Man darf nicht der Versuchung erliegen, "nebenbei" auch noch andere Probleme zu lösen oder gar zusätzliche Entwicklungsarbeit anzunehmen.

Schwungkraft bedeutet, daß das beim Umstellungsprozeß einmal gewonnene Tempo beibehalten wird. Wenn bei der Umstellung immer mehr Systeme in Angriff zu nehmen sind und die Aufgabe größere Dimensionen annimmt, besteht die Gefahr, entmutigt und langsamer zu werden. Projektverantwortliche müssen alles tun, dieser Gefahr für die fristgerechte Fertigstellung entgegenzuwirken.

Ein Jahr-2000-Projekt ist eine große Herausforderung, die sich gleichwohl bewältigen läßt. Es besteht kein Grund zur Resignation oder Panik, sondern "nur" einer dazu, sofort angemessene Gegenmaßnahmen zu ergreifen. Das Ausmaß dieser Maßnahmen ist jedoch gegen eine seriöse Bewertung der Risiken für das Geschäft abzuwägen, die ohne Umstellung auftreten könnten. In dieser Hinsicht sollte nicht nur die IT-Abteilung, sondern gerade die Geschäftsleitung ein Jahr-2000-Projekt vorantreiben.

Praxisserie

Es gibt kaum neutrale Reports aus der Praxis von Jahr-2000-Projekten. Hier ist der dritte und abschließende Teil des bislang umfangreichsten Berichts über Erfahrungen und Beobachtungen, der hierzulande erschienen ist, verfaßt von einem Projektleiter. In ihm kommen das oftmals unterschätzte Problem geringer personeller Ressourcen, die Bedeutung der Kommunikation, ein Modell für die Auslagerung einzelner Aufgaben sowie Möglichkeiten zur Nutzung positiver Nebeneffekte zur Sprache.

In dieser Serie geht es vor allem um Probleme und Lösungsverfahren bei der Umstellung von Mainframe-Systemen. Viele der hier vorgestellten Erfahrungen lassen sich jedoch ebenso auf die Umstellung von verteilten Client-Server-Systemen übertragen. Der erste Teil (in CW 44/1997 ab Seite 47) des Praxisberichts befaßte sich primär mit der Projektvorbereitung und -konzeption. Im zweiten Teil (in CW 45/1997 ab Seite 70) standen die weiteren Schritte der Umstellung sowie eine Einschätzung der Möglichkeiten zur Automatisierung von Aufgaben und andere Faktoren für Zeiteinsparungen im Vordergrund.

*Rahoul Bhasin, München und London, ist bei der Deutsche Perot Systems GmbH, Frankfurt, angestellt und hat bisher verschiedene Projekte in Deutschland und im europäischen Ausland geleitet. Kontakt per Web-Site http://www.perotsystems.com oder E-Mail an rahoul.bhasin