Die fünf Bände der IT Infrastructure Library (ITIL) mögen ein dröges Regelwerk sein, das sich die wenigsten Zeitgenossen aus Vergnügen vornehmen. Gleichwohl trifft die Umsetzung der Empfehlungen für eine effektive IT in Form des ITSM auf großes Interesse. War ITIL zunächst ausschließlich ein Thema für große Unternehmen, verfolgen heute auch mittlere und kleine Betriebe entsprechende Projekte.

Unabhängig davon, wie weitreichend, anspruchsvoll und finanziell aufwändig diese Vorhaben sind, lassen sich in der Praxis immer wieder die gleichen Erfahrungen sammeln und Probleme erkennen. Zunächst unterscheiden sie sich nicht elementar von anderen IT-Projekten. Dem Kick-off folgen die Phasen Analyse, Tool-Auswahl, Umsetzung, Einführung und Betrieb. In dieser Reihenfolge sollen hier Grundregeln für die Vorgehensweise und das Vermeiden von Schwierigkeiten vorgestellt werden. Hier stehen Services für innerbetriebliche IT-Prozesse im Vordergrund. Die Erfahrungen lassen sich aber genauso auf Situationen übertragen, in denen es um Services für außerbetriebliche Kunden geht.

Die Phase der Analyse

Der erste Schritt besteht darin, die angestrebten Serviceprozesse festzulegen und zu überprüfen, ob sie realisierbar sind. Oft gibt es nur vage Vorstellungen davon, was mit ITSM umgesetzt werden sollte. Man schaut sich an, was die IT bisher gemacht hat, und möchte "es irgendwie besser machen". Leider sind die vorhandenen Prozesse meist nur rudimentär oder gar nicht dokumentiert. Darum sollte anfangs keine komplexe Ablaufbeschreibung, sondern nur eine Stichpunktliste erstellt werden - maximal ein einfaches Flussdiagramm -, um die Sachlage zu beschreiben.

Zudem gilt es, die Projektteilnehmer mit fachlichem und technischem Background festzulegen. Ihnen obliegt die Umsetzung und der spätere Betrieb des Systems - und sie müssen am Ende den Kopf hinhalten. Um den Aufwand für die Einarbeitung in Grenzen zu halten, sollten diese Personen im Verlauf des Projekts nicht wechseln. In dem Falle wäre auch das Risiko zu groß, das Projektziel schleichend zu verändern. Geraten ständig neue Anforderungen ins Pflichtenheft, ist das ITSM-Projekt gefährdet; von "dynamischen Anpassungen" kann dann keine Rede mehr sein.

Unabdingbar sind auch ein Zeit- und ein Anforderungsplan. Ersterer gerät leicht zu ambitioniert. Der zweite muss neben den fachlich-technischen Anforderungen alle im Projekt involvierten Personen benennen. Und dazu gehören nicht nur die IT-Spezialisten, sondern auch die Fachabteilungen und externe Firmen, zum Beispiel Lieferanten oder mit Softwarewartung betraute Externe, deren Produkte das ITSM-Projekt beeinflussen. Diese Anforderungslisten sollten nicht zu lang ausfallen.

Vor allem ist es wichtig, die Anforderungen durch Priorisierung und Reduktion überschaubar zu halten. Die einzelnen Phasen des ITSM-Projekts dürfen sich nicht über Jahre hinziehen, sondern es sind schnelle Detailerfolge anzustreben, auf denen sich aufbauen lässt. Völlig verkehrt wäre die Einstellung "Viel hilft viel" - das Gegenteil ist der Fall.

Erst auf der Basis dieser Vorüberlegungen geht es an eine Projektbewertung, ein Pflichtenheft, den Business-Plan, die Einteilung der einzelnen Projektphasen sowie ein technisches und ein Support-Konzept.

Die Tool-Auswahl

Häufig wird der Fehler gemacht, dass Anwender sich schon vor den grundsätzlichen Überlegungen mit der Frage befassen, welche Aufgaben dieses oder jenes bereits vorhandene Tool bewältigen könnte. Dabei geht leicht der Blick aufs Ganze verloren. Meistens gibt es mehr Aspekte zu beachten als die mit dem vorhandenen Know-how adressierbaren. Neben den prozessualen, fachlich-funktionalen und technischen Anforderungen bestehen auch integrative und finanzielle.

Die ersten Anforderungen ergeben sich aus den im Vorfeld definierten, umzusetzenden Prozessen. Einfache Abläufe wie Störungsmeldung und -bearbeitung werden meist ergänzt durch Bedarfsanforderungen und ihre Erfüllung. Sie führen zu Änderungen in der Infrastruktur und erweitern das System um den Aspekt des Change Managements. Das unterstreicht die Wichtigkeit der Maxime, Prozesse einfach zu halten und sich aufs Wesentliche zu konzentrieren.

Die fachlich-funktionalen Anforderungen beziehen sich nicht nur auf die Notwendigkeit, das ein oder andere Server-System zu kennen. Im Zentrum steht vielmehr die Datenbasis, auf der die Prozesse aufbauen - die Configuration Management Database (CMDB). In ihr müssen unter anderem alle Hardware-, Netzwerk- und Softwarekomponenten und ihre Beziehungen zueinander festgehalten sein, damit diese effektiv mit dem zukünftigen ITSM-System unterstützt werden können. Da man ja im Idealfall klein angefangen hat, beispielsweise mit einem Auszug aus einem eigentlich detailreichen Inventarisierungssystem, steht dem System ein Ausbau bevor, weshalb die CMDB skalierbar sein sollte. Das ist nur dann gegeben, wenn die CMDB gut strukturiert ist und dadurch performant arbeitet.

Aus den genannten Aspekten leiten sich technische Anforderungen ab. Diese werden aber durch einen anderen Faktor mitbestimmt: das vorhandene Know-how. Wenn es etwa überwiegend PostgreSQL-Wissen im Hause gibt, empfiehlt es sich nicht, das ITSM-System und die CMDB auf MySQL aufzusetzen. Die Tool-Auswahl ist auch dann eingeschränkt, wenn grundsätzlich nur eine bestimmte Betriebsplattform, beispielsweise Windows, zugelassen ist.

Ein ITSM-System bezieht direkt oder über die CMDB Informationen von anderen Systemen, weshalb sich zusätzliche integrative Anforderungen stellen. Welcher Verzeichnisdienst ist zu adressieren? Müssen Daten aus CRM- oder ERP-Anwendungen einfließen? Gibt es ein Client- oder ein Inventory-Management? Ganz sicher wird man das System-Management oder die vorhandenen Monitoring-Lösungen einbeziehen.

Also gilt es auch, bei der Tool-Entscheidung zu priorisieren: Was ist am wichtigsten? Die Suche nach einer Antwort kann leicht in enervierenden Debatten enden. Natürlich wird jede Fachabteilung andere Vorstellungen haben und genau ihre Anforderungen für die wichtigsten halten. Alle Wünsche sollte man gar nicht erst zu erfüllen versuchen. Der Kompromiss ist der kleinste gemeinsame Nenner, eine Balance zwischen den involvierten Fachabteilungen und dem Anforderungskatalog.

Bei alledem gilt es, die Kosten im Griff zu behalten. Der Budgetrahmen bedarf unbedingt der Zustimmung durch die Geschäftsleitung. Diese muss klar hinter dem Projekt stehen und auch dafür werben. Ist der finanzielle Rahmen eng gesteckt, schränkt sich die Freiheit bei der Tool-Auswahl ein. Das ist der Grund, warum immer mehr IT-Organisationen zu Open-Source-Lösungen greifen - auch bei ITSM-Tools.

Entsprechende Werkzeuge gibt es heute eine ganze Reihe. Beispielsweise lassen sich die eigentlich für die Softwareentwicklung geschriebenen Open-Source-Produkte "Bugzilla" und "Mantis" auch für Helpdesk-Aufgaben nutzen. Allerdings sind ihre Möglichkeiten für diesen Zweck eher eingeschränkt. Auch bei "Best Practical RT" scheint die Ausrichtung auf ITSM und ITIL nicht mehr richtig voran zu gehen. Interessanter wird es mit dem "IT Operational Portal" (ITOP) von der französischen Firma Combodo, die von ehemaligen HP-Mitarbeitern gegründet wurde. Das Produkt orientiert sich klar in Richtung ITIL und IT Service Management. Allerdings empfiehlt sich der Leistungsumfang eher für kleine bis mittelgroße Anwenderunternehmen.

Der Platzhirsch unter den Open-Source-Angeboten ist mit weltweit rund 100 000 Installationen OTRS vom gleichnamigen Anbieter aus Bad Homburg - insbesondere mit dem Erweiterungsmodul "OTRS::ITSM". Es ist funktional mächtig, skalierbar, gut dokumentiert und bietet viele Konfigurations- und Erweiterungsmöglichkeiten. OTRS stellt Tickets, also Vorgänge und Prozesse, in den Mittelpunkt und fokussiert anders als die meisten IT-Management-Systeme nicht auf einzelne Konfigurationsobjekte. Des Weiteren gibt es eine Menge Module für unterschiedliche funktionale Erweiterungen, von denen sich viele aus der Anwender-Community kostenfrei im OTRS Package Archive (OPAR) finden. Zudem gibt es Schnittstellen zur Notifikation per Web, Mail, Fax und mobilen Kommunikations-Devices.