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.
Die Phase der Umsetzung
Aufgrund seiner Marktbedeutung beschränken wir uns bei den weiteren Betrachtungen auf OTRS. Das System, das kostenfrei heruntergeladen und ausprobiert werden kann, ist zügig installiert. Nutzern wird es leicht fallen, die ersten Warteschlangen für Tickets (so genannte Queues) einzurichten. So lassen sich recht einfach ITSM-Praxiserfahrungen sammeln. Ein funktionales System wird daraus aber noch nicht.
Die meisten größeren ITSM-Projekte kommen ohne das Know-how eines spezialisierten Dienstleisters nicht aus. Je nach Ausprägung des Anfrage-Managements kann er dabei helfen, weitere Prozesse zu integrieren, so dass Event-, Konfigurations- und Change- oder Release-Management reibungslos funktionieren.
Kommt OTRS zum Einsatz, lassen sich Event-Meldungen aus Monitoring-Tools wie "Nagios" oder dem Fork "Icinga" automatisch einbinden. Auch proprietäre Produkte wie "HP Openview" können berücksichtigt werden. Auch das Konfigurations-Management ist offen für Erweiterungen wie die automatische Software-Verteilung "opsi" von der Mainzer uib, für Thin-Client-Tools von Igel oder für die CMDB "i-doit" als Alternative oder Ergänzung zur OTRS-eigenen CMDB. Hinzu könnten "Bugzilla" oder "JIRA" für das Change- und Release-Management kommen. Ein MediaWiki und andere Erweiterungen für den Self-Service sind ebenfalls möglich.
Die weitaus größte Projektherausforderung ist die Qualität der Datenbasis, die in die CMDB einfließen soll. In den meisten Fällen sind bei den Inventardaten die Konfigurationsobjekte in verschiedenen Datenbanken, Tabellen oder Listen erfasst, Informationen über die Beziehungen zwischen den Objekten fehlen. Das Einbinden, Strukturieren und Homogenisieren der Konfigurationsdaten verschlingt meistens viel Zeit.
Ähnlich verhält es sich mit den Kundendaten. In der Regel sind alle Informationen über die Mitarbeiter in einem Verzeichnisdienst erfasst, von wo sie sich theoretisch leicht integrieren lassen sollten. Die Praxis hält allerdings regelmäßig Überraschungen bereit. Geht man Fehlermeldungen auf den Grund, stößt man auf Dubletten oder Datensätze, denen bestimmte Attribute fehlen. In OTRS-Umgebungen muss das Attribut "E-Mail-Adresse" immer gefüllt sein, es ist ein Pflichtfeld.
Wichtig ist auch das Filtern der Informationen, die in das ITSM-System einfließen. Allein die Basissysteme liefern eine erschlagende Menge an Daten, von denen der überwiegende Anteil für die Organisation der IT-Prozesse völlig unerheblich ist. Dabei braucht beispielsweise der Helpdesk die wichtigsten Informationen auf einen Blick, weil er möglichst schnell Entscheidungen treffen muss, die dem Endanwender helfen. Tausende Detaildaten verschleiern das Problem nur. Reichen die Informationen, um Anfragen auf den Grund zu gehen, nicht aus, kann er vertiefende Daten aus den Subsystemen holen. Auf diese Selektion, die Bestimmung des relevanten Inputs für den Großteil der Incident-Meldungen, sollte viel Wert gelegt werden. Sie wird bei jedem Unternehmen etwas anders ausfallen.
Selbstverständlich wollen alle Verantwortlichen Reports. Dabei sind sie als Tätigkeitsnachweis (Wie viele Tickets pro Monat?) häufig wenig hilfreich. Sinnvoller sind Reports, die sich von konkreten Indikatoren ableiten und dazu beitragen, Incidents künftig vorzubeugen. So kann zum Beispiel eine Häufung von Router-Ausfällen anzeigen, dass ein Gerätetyp für bestimmte Umweltbedingungen wie Hitze und Staub ungeeignet ist. Auslastungsdaten von Druckern geben Hinweise darauf, ob Kauf oder Leasing der Geräte wirtschaftlicher ist. Indikatoren können auch die Qualität der angebotenen Serviceleistungen sein.
Die Basiseinrichtung eines ITSM-Systems muss dokumentiert werden. Tatsächlich geschieht das aufgrund der oft hohen Belastung des IT-Personals meistens nur lückenhaft. Unabdingbar aber ist, wenigstens die Konfigurationsänderungen gegenüber dem Standard-OTRS festzuhalten.
Die Phase der ITSM-Einführung
In der ITSM-Einführungsphase ist es wichtig, die IT-Mitarbeiter gut geschult in die Produktivphase des neuen ITSM-Systems mit gegebenenfalls neuen Prozessen starten zu lassen. "Learning by Doing" ist hier der falsche Weg. Sind die IT-Mitarbeiter im Umgang mit dem neuen system nicht kompetent, erkennen die Endanwender das sofort. Sie werden das Projekt ablehnen und in der Folge entsteht eine Investitionsruine.
Die Endanwender sind der eigentliche Knackpunkt. Sie haben sie sich an bestimmte Verfahren zur Problemlösung gewöhnt, zum Beispiel Papierformulare, auf denen sie ihr Anliegen festhalten. Diese Formulare sollten möglichst genau in elektronische Vorlagen umgesetzt werden. Finden die Anwender ihre gewohnte Umgebung wieder, werden sie auch im produktiven Betrieb mit den neuen Mitteln arbeiten - und einer der wichtigen "Quick-Wins" ist erreicht.
Sollen die Endanwender etwas anders machen, als sie es gewohnt sind, muss man es ihnen erklären. Wichtig ist, dass der Support über eine zentrale Telefonnummer und Mailadresse zu erreichen ist. Das wird die Kunden nicht davon abhalten, ihren bekannten Supporter anzurufen oder sogar persönlich aufzusuchen. Deshalb werden die IT-Mitarbeiter Geduld aufbringen müssen, den Anwendern das Ticket-System sowie Organisation und Steuerung des Helpdesk mitsamt den Vorteilen zu erklären. Allerdings sei vor der Illusion gewarnt, durch das Schreiben von Tickets seien alle Firmenangehörige gleich. Die Sekretärin vom Chef wird auch in Zukunft gleicher sein. Zu diesem Zweck gibt es Klassifizierungsmerkmale wie Ticket-Typen, Services und SLAs, um Tickets vorab zu priorisieren.
Die Betriebsphase
Die Einführungsprobleme ziehen sich weit in die eigentliche Betriebsphase hinein. Nun aber ist es Zeit, die Früchte klugen Vorgehens zu ernten. Aus der Praxis Dutzender Projekte lässt sich feststellen, dass ITSM, selbst auf der unteren Ebene des Helpdesk, ein nie endendes Projekt ist. Und das ist durchaus im Sinne der ITIL-Vordenker, denen zufolge sich die IT dynamisch an die sich wandelnden Anforderungen von Unternehmen und Verwaltungen anzupassen hat.
Das manifestiert sich vor allem darin, dass regelmäßig schon bald nach der Produkteinführung neue Wünsche hinsichtlich Funktionalität und Prozesskonfiguration auftauchen. Erstaunlicherweise haben diese meistens herzlich wenig mit den in der Vorbereitungsphase vorgebrachten Wunschanforderungen zu tun. Das unterstreicht, wie wichtig es ist, die anfängliche Anforderungsliste möglichst klein zu halten und zu priorisieren.
Ganz sicher aber wird sehr bald in der IT die Idee aufkommen, man könne die Arbeitslast durch "Customer Self Service" weiter reduzieren. An dieses Thema ist mit Vorsicht und Planung heranzugehen. Der Ansatz "Jetzt helfe ich mir selbst" richtet in der IT eher Schaden an, jedenfalls wenn es um die Behebung von Funktionsstörungen geht. Unproblematischer ist sie, wenn es um das Bereitstellen von Applikationen geht oder den Zugang zu Dateiverzeichnissen, E-Mail oder ähnlichem. Dazu bedarf es aber zum Teil neuer innerbetrieblicher Abläufe und ihrer elektronischen Nachbildung - womit das nächste Projekt auf dem ITSM-Weg starten kann. (mhr)