Ein Projekt kann nur bezogen auf eine gegebene Zielsetzung erfolgreich sein oder scheitern. Demzufolge ist die Voraussetzung für jedes professionell abzuwickelnde Projekt eine präzise und prüfbare Zieldefinition im Sinne eines Projektauftrags. Die denkbaren Ziele unterscheiden sich erheblich, lassen sich aber zu einem Gesamtbild kombinieren. Zwei Beispiele zur Erläuterung:

Technische Ziele können etwa beinhalten, daß die eingesetzten Technologien beherrscht werden, wichtige Ressourcen verfügbar sind, Fehlerursachen schnell ermittelt, die Anwendungs-Performance regelmäßig geprüft und sichergestellt wird und daß ein schnelles Recovery bei Ausfällen garantiert ist. Zu den organisatorischen Zielen gehört es hingegen, daß Informationen all jenen zur Verfügung stehen, die sie benötigen, daß Schnittstellen zwischen Abteilungen etabliert, Querschnittsprozesse ermöglicht sowie kontinuierliche Verbesserungsprozesse in Gang gesetzt werden.

Naturgemäß haben nicht alle Ziele die gleiche Priorität. Performance-Optimierungen machen erst Sinn, wenn die Verfügbarkeit sichergestellt ist. Dies ist aber in verteilten, dezentralen Umgebungen nicht selbstverständlich. Bedingt durch Abhängigkeiten zwischen einzelnen Komponenten entstehen technische Prozeßketten. Diese sind in der Verfügbarkeit wesentlich schwieriger zu optimieren als eine einzige zentrale Komponente. Abbildung 1 (Seite 52) beschreibt diesen Zusammenhang für den Zugang zu einem zentralen R3-Server.

Das Grundproblem besteht darin, daß die Verfügbarkeit einer Kette zu durchlaufender Komponenten durch die Multiplikation der Einzelverfügbarkeiten der Kettenelemente berechnet wird. Um eine Verfügbarkeit von deutlich über 99 Prozent in der Nutzung einer Anwendung zu erreichen, müßten demnach alle Komponenten, die zwischen Benutzer und Anwendung liegen, eine Einzelverfügbarkeit von 99,9999 Prozent und mehr erreichen. Es ist klar, daß dies mit heutigen DV-Architekturen unrealistisch ist. Allerdings kommt aus dem Umfeld großer Web-Server-Farmen ein neuer Architekturansatz, der auf Lastverteilung und Skalierbarkeit basiert.

Wie Abbildung 2 (Seite 53) zeigt, läßt sich mit solchen Architekturen ein höherer Grad an Verfügbarkeit erreichen.

Entsprechend dieser Ausgangslage hat sich der Markt für Netzwerk- und System-Management-Lösungen in Bedarfsphasen entwickelt. In der ersten Phase vor etwa drei bis fünf Jahren, dominierte die Diskussion um die Element-Manager speziell in den Bereichen Netzwerk, Server und Mainframe. Typische Produkte dieser Zeit sind HP Openview Network Node Manager, IBM Netview for AIX, BMC Patrol und Candle Command Center.

In der zweiten Phase, die in den vergangenen beiden Jahren stattgefunden hat, konzentrierte sich die Diskussion auf die Frage von Vor- und Nachteilen von Framework-Lösungen gegenüber Point-Solutions. Typische Produkte sind CA Unicenter TNG, die HP-Open-View-Produkt-Familie und das Tivoli-Framework mit seinen einzelnen Modulen.

Inzwischen wird immer deutlicher, daß die damit zu realisierenden Lösungen im wesentlichen ein hierarchisches Alarm- und Ereignis-Management realisieren, das auf den technologiespezifischen Einzelwerten aufsetzt und durch Korrelation und Filterung versucht, einen technologieübergreifenden Gesamtblick zu realisieren. Damit wird nur ein Teil der zuvor genannten Ziele abgedeckt. Projektlösungen der ersten beiden Phasen haben einige erhebliche und äußerst kritische Nachteile.

Kluft zwischen Anspruch und Wirklichkeit

Obwohl sie eine technologieübergreifende Lösung anstreben, konzentrieren sie sich nicht auf das wesentliche: auf den durch Management in einer definierten Qualität und Leistung sicherzustellenden Geschäftsprozeß beim Anwender. Die Werbung der Hersteller stellt dies zwar anders dar, in der Praxis werden die Versprechungen jedoch relativiert. Wer jemals mit den bisherigen Produkten versucht hat, einen Geschäftsprozeß so nachzubilden, daß dessen Betriebssituation in ihrer Auswirkung auf die Mitarbeiter im User Helpdesk (UHD) oder eine Leitwarte intuitiv verständlich zu beurteilen war, der weiß, daß hier zwischen Anspruch und Wirklichkeit große Lücken klaffen. Der notwendige Aufwand ist extrem hoch, das Ergebnis weder intuitiv nutzbar noch von der Handhabung für eine größere Zahl von Nicht-Systemspezialisten brauchbar.

So stellen die einzelnen Technologien Netzwerk, Server, Mainframe, Applikation etwa eine solche gigantische Menge an Einzelinformation dar, daß deren Weiterverarbeitung durch Filter oder Regeln an Grenzen stößt. Zwar gibt es einige gute und lobenswerte Ansätze wie die neuen Korrelationsmöglichkeiten im HP Open View ECS, die objektorientierte Korrelation in Cabletron Spectrum oder die programmatischen Potentiale einer Tivoli Enterprise Console. Aber auch mit ihnen bleiben die Komplexität der Ereignisverarbeitung und jeder Versuch einer technologieübergreifenden Korrelation zu hoch.

Seit einigen Monaten kursiert nun ein neues Schlagwort. Genau genommen ist es allerdings nicht wirklich neu, sondern wurde erst jetzt populär: Service-Level-Management. Damit ist die dritte Phase der Entwicklung von Netzwerk- und System-Management-Lösungen eingeläutet. In dieser Phase wird primär die Frage nach der Servicesituation beim Anwender gestellt. Unter Service versteht man dabei beispielsweise die Nutzbarkeit der elementaren Geschäftsanwendungen im Sinne eines festgelegten Leistungsumfangs. Leistung unterteilt man dabei in die Bereiche Verfügbarkeit, Transaktionszeit, Durchsatz. Abbildung 3, oben, beschreibt den technischen Ansatz der Phasen 1 und 2. Abbildung 3, unten, skizziert den aktuellen Ansatz des ServiceLevel-Managements-(Seite 53).

Diese Überlegungen verdeutlichen, daß die Frage des Projekterfolgs sehr von der Ausgangslage und den Zielen abhängt. Gut abgrenzbare, eher technische Ziele lassen sich naturgemäß leichter erreichen als komplexe organisatorische Aufgabenstellungen wie die Realisierung eines Querschnittsprozesses für Service-Level-Management.

Die Erfahrung zeigt weiter, daß System-Management-Projekte immer wieder an den gleichen Stellen Probleme bekommen. Für das Scheitern gibt es drei wichtige Gründe: Zum einen wurde die Kombination aus Technik und Organisation nicht beherrscht. Des weiteren haben sich Produkte als instabil und fehlerhaft herausgestellt. Schließlich wurde der Personal- und Zeitbedarf für die Umsetzung drastisch unterschätzt.

In der Regel hat die Realisierung von Netzwerk- und System-Management Auswirkungen auf die Organisation. Wer ein Fehler-Monitoring-System aufbaut, der muß auch jemanden an den Monitor setzen. Wer die Performance beim Anwender optimieren will, der braucht eine komplexe Querschnittsorganisation. Die Umsetzung organisatorischer Änderungen erfordert aber mehr Zeit als die Installation und Einführung von Technik. Wer Technik in zu großer Menge und zu schnell einführt, wird feststellen, daß die Mitarbeiter diese nur verhalten annehmen und selten sinnvoll einsetzen. Das Ergebnis sind Tools, die von niemandem genutzt werden. Die Situation verschlimmert sich noch durch die Komplexität dieser Werkzeuge. Umgekehrt ist ein Teil dieser Vielschichtigkeit erforderlich, um neue organisatorische Abläufe umsetzen zu können. Wer also die organisatorischen Hausaufgaben vernachlässigt, schafft unwirtschaftliche Komplexitäten.

Und eines zeigen die Projekte deutlich: Wer die Vorstellung hat, mit System-Management mehr Technik mit weniger Personal betreiben zu können, wird schnell eines besseren belehrt werden: Gerade in der Startphase wird der Betriebsaufwand deutlich höher sein als die eingesparten Kosten. Nicht umsonst wird die Wirtschaftlichkeit von System-Management in der Regel durch die Vermeidung von Ausfallkosten berechnet. Bei konsequenter und systematischer Einführung wird allerdings ein mittelfristiger Spareffekt (ein bis zwei Jahre) im Bereich der Benutzerbetreuung und des Server- und Applikations-Managements erreicht.

Als Faustformel für Projekte mit Lizenzkosten unter einer Million Mark hat sich folgendes Verhältnis ergeben: Die Arbeitskosten berechnen sich aus Lizenzkosten mal zehn. Damit wird auch deutlich, warum Projekte an dieser Stelle scheitern können. Das scheinbar simple Weiterleiten von Alarmen eines NT-Servers an ein Trouble-Ticket-System kann mit Arbeiten von bis zu vier Personenwochen verbunden sein (wer dies versäumt, wird schnell sein Trouble-Ticket-System fluten oder so wenige Alarme verarbeiten können, daß kein Mehrwert mehr entsteht). Die Paketdefinition in der Softwareverteilung für eine einzige Applikation kann spielend 40 bis 60 Tage Zeit kosten. System-Management-Produkte sollten grundsätzlich als Rohwerkzeuge angesehen werden. Die Aussage einiger Hersteller, mit ihren Produkten würde Know-how eingekauft, läßt sich bislang nicht bestätigen.

Sowohl bei der technischen als auch bei der organisatorischen Umsetzung von System-Management sind zudem die Verpflichtungen des Betriebsverfassungsgesetzes zu beachten (§ 87 und § 90). Der Betriebsrat ist in der Regel mindestens rechtzeitig und umfassend zu informieren, häufig wird auch eine Mitbestimmungssituation bestehen. In diesen Fällen muß eine Betriebsvereinbarung erarbeitet werden, was einige Tage, aber auch mehrere Monate dauern kann. Typische Problemfälle sind etwa der Einsatz von Trouble-Ticket-Systemen, von PC-Fernwartung, von beliebigen Agenten auf Endsystemen, die Umsetzung von Bereitschaftsdienst, Arbeit am Wochenende sowie die Veränderung der Arbeitsplätze von Operatoren im Schichtbetrieb.

Daraus ergeben sich folgende Empfehlungen. Projektziele sollten präzise und mit Prioritäten definiert werden, ein Projektplan ist formal und sauber zu pflegen. Die Projektumsetzung sollte zudem in drei bis vier Stufen erfolgen, wobei in jedem Schritt das Verhältnis aus Technik und Organisation zu klären ist. Die nächste Stufe sollte nur angegangen werden, wenn die vorherige erfolgreich abgeschlossen wurde. Darüber hinaus ist es ratsam, vor dem Einstieg in eine neue Phase eine Revision des Projektplans durchzuführen und die bereits getroffenen Produktentscheidungen gegebenenfalls einer Überprüfung zu unterziehen.

Die einzelnen Projektstufen sollten aufeinander abgestimmt werden. Insbesondere die relativ neuen Tools zum Service-Level-Management ermöglichen es, die bisherigen Element-Manager mit weniger aufwendigen Konfigurationen zu betreiben. Durch den zeitlich sorgfältig abgestimmten Einsatz der einzelnen Management-Technologien entsteht in der Summe der technische und wirtschaftliche Erfolg. Eine sinnvolle Reihenfolge kann wie folgt aussehen:

- Aufbau einer System-Management-Grundarchitektur mit Element-Managern und Ereignis-Konsole,

- Umsetzung von Monitoring und Event-Management, Stufe eins,

- Einbindung User Helpdesk,

- Einführung von organisatorischen Querschnittsprozessen und Prozeßverantwortung,

- Implementierung von Berichtswesen, Stufe eins

- Umsetzung von Monitoring und Event-Management, Stufe zwei,

- technologiespezifisches Verfügbarkeits- und Performance-Management,

- Service-Level-Management, Stufe eins

- Recovery-Management, Stufe eins,

- Prognosen und Trendanalysen, Stufe eins

- Service-Level-Management, Stufe zwei

- Prognosen und Trendanalysen, Stufe zwei, und schließlich

- Recovery-Management, Stufe zwei.

Die Unternehmen müssen sich damit abfinden, daß die erfolgreiche Umsetzung von System-Management mehrere Jahre in Anspruch nehmen kann. Die Gründe liegen in der Organisation und nicht in der Technik. Wer Technik für mehrere Millionen Mark kauft, ohne eine Projektplanung unter besonderer Berücksichtigung der Organisation durchgeführt zu haben, der schafft die optimalen Voraussetzungen für eine Investitionsruine. In den Projekten bringen zudem gute Ideen zu organisatorischen Lösungen häufig mehr Erfolg als die eingesetzte Technik.

Leider wird diese Problematik durch die auf Umsatzprovisionen schielenden Vertriebsbeauftragten der Anbieter verschärft. Sie versprechen technische Lösung in kurzer Zeit, obwohl dies in den seltensten Fällen realistisch ist. Konventionalstrafen sind in diesem Umfeld sinnlos, da es jedem halbwegs intelligenten Projektleiter gelingen wird, die Ursache für die Verzögerungen beim Kunden zu finden (eben wegen der organisatorischen Abhängigkeiten).

Ein weiterer wichtiger Grund für das Scheitern von Projekten kann in der Qualität und dem Leistungsumfang der eingesetzten Produkte liegen. Im Extremfall werden Produkte verkauft, die beim Starten die gesamte Maschine zusammenbrechen lassen. Da hilft es nur, vorher sorgfältig zu testen, Referenzinstallationen zu begutachten oder spezialisierte, neutrale Systemhäuser einzuschalten.

Auf dem Markt sind durchaus gute Produkte erhältlich, so daß kein Projekt an dieser Stelle scheitern muß. Die Schwierigkeit liegt in der geeigneten Zusammenstellung und der Implementierung der notwendigen Schnittstellen. Auch ein Framework-Produkt löst dieses Problem nicht, da die aktuellen Produkte durch Zusatz-Tools angereichert werden sollten.

Die Praxis zeigt, daß es sinnvoll ist, von vornherein ein Eskalations-Management zu installieren: einen erfahrenen und mit den entsprechenden Kompetenzen ausgestatteten Mitarbeiter sowohl auf der Lieferanten- als auch auf der Kundenseite. Die häufig praktizierte Aufgabenteilung (normale Eskalation durch Sachbearbeiter, höhere Eskalation durch Abteilungsleiter) führt erfahrungsgemäß nur zu Pingpongeffekten und hat nicht die notwendige Konstanz.

Leider läßt das Serviceverhalten auch großer und bekannter Hersteller deutlich zu wünschen übrig. Hier sollte von vornherein ein vertraglich abgesichertes Druckmittel geschaffen werden. Denn die Punkte Eskalation, Abnahme, Gewährleistung werden in den meisten Verträgen nicht mit der ausreichenden Sorgfalt behandelt.

Alles in allem läßt sich sagen, daß System-Management-Projekte nicht scheitern müssen. Es gibt zahlreiche Projekte verschiedenster Größenordnung, die erfolgreich abgeschlossen werden konnten. Der Schlüssel des Erfolgs liegt in einem sorgfältig abgestimmten Stufenplan und in der geeigneten Kombination aus Organisation und Technik.

ANGEKLICKT

Um System-Management-Projekte erfolgreich abschließen zu können braucht man klar definierte Ziele. Die Praxis zeigt, daß die Technik beherrschbar ist; große Probleme ergeben sich jedoch immer wieder bei der Umsetzung von organisatorischen Zielen. Das wiegt um so schwerer, als Anwender zusehends dazu übergehen, ihren IT-Dienstleistern das Service-Management zu verordnen. Hier ist Realisierung eines Querschnittsprozesses über die herkömmlichen Management-Grenzen hinweg erforderlich. Organisation und Arbeitsabläufe in den IT-Abteilungen müssen darauf abgestimmt werden.

*Dr. Jürgen Suppan ist Geschäftsführer der Comconsult Akademie und Vorsitzender des Beirats der Comconsult Kommunikationstechnik in Aachen.