© Buchachon Petthanya, 123RF.com

IT-Abteilungen unterliegen ebenso einem Wandel wie ihr Gegenstand, die IT. Organisch gewachsene Strukturen, die beim Weiterwachsen deutliche Schmerzen verursachen, sollten Verantwortliche dringend ordnen und professionalisieren. ITIL kann ihnen dabei helfen.

Mit “ITIL ist eine Sammlung von Büchern …” beginnen fast alle Ausführungen [1] zur IT Infrastructure Library [2]–[4]. Zurecht, denn die Aussage ist elementar und ITIL wirklich nur Best Practice, also eine Darstellung von guten Beispielen, um ein IT-Service-Management (ITSM) zu etablieren. Zwar gibt es mit ISO/IEC 20 000 lange schon eine richtige Norm, gegen die sich Organisationseinheiten (für drei Jahre) zertifizieren lassen können. Aber der Kerngedanke von ITIL bleibt, dass sich eine Firma anhand der Beispiele ihr eigenes Qualitätsmanagement-System maßschneidert (Abbildung 1), und das geht ohne Zertifikat.

Die gute Nachricht lautet: Das Ganze ist kein Hexenwerk, solange die IT-Abteilung nicht riesig groß ist und eine Zertifizierung – falls überhaupt angestrebt – erst am Schluss stehen soll. Der Prozess lässt sich weitgehend ohne professionelle Beratung in Eigenregie einrichten, oder man holt sich Unterstützung aus einer Firma, die so etwas schon einmal an sich selbst gemacht hat.

Abbildung 1: Die prinzipielle Struktur von ITIL, dargestellt als Kreis.

Vorarbeit spart Aufwand

Wichtig ist von allem die gründliche Vorarbeit. Alles, was jemand hier versäumt, bereut er später – das Nachholen vervielfacht häufig den notwendigen Aufwand, so die Erfahrung. Ein Teil der Vorarbeit kristallisiert sich in der Configuration Management Database (CMDB), die alle Betriebsmittel der IT (Configuration Items, CI) erfasst. Mit ihr steht und fällt zugleich ITIL. Dabei muss die CMDB nicht zwingend eine einheitliche Datenbank sein – in großen Firmen ist sie es tatsächlich häufig nicht –, aber eine Gesamt-CMDB vereinfacht später es später, die Toolunterstützung aufzusetzen.

Dank der CMDB hält eine IT-Abteilung in zentral vorgehaltenen Strukturen ihr Wissen vor, welche Geräte sie besitzt, verwaltet und betreibt, welche Services sie anbietet und wie die funktionieren. Letztere Informationen liegen häufig schon vor, zum Beispiel weil die Firma mit einem SAP-System bucht. Daher bleibt in den meisten Fällen das Zusammentragen aller Informationen über Hard- und Software der mit Abstand arbeitsaufwändigste Akt.

Die LAN-Geräte kann der Admin häufig durch einen Netzwerkscan automatisiert erfassen, und bringt mit Hilfe der MAC-Adresse die anderen Informationen wie Ausstattung, Kaufdatum und Benutzer sowie Services ans Licht. Standortinformationen (Raum-, aber auch Telefonnummern) muss er meist manuell einpflegen. Dabei ist nicht immer der Anwender auch der Kunde, sondern häufig dessen Chef, an den die Rechnung ging.

Schwieriger ist die Software (auf Windows-Rechnern) zu erfassen – Linux-Maschinen mit ihrem einheitlichen Paketmanagement erleichtern diese Aufgabe. Ganz allgemein gibt es Tools, die Software erkennen. Der IT-Verantwortliche sollte aber darauf achten, dass daraus keine Überwachung der Mitarbeiter entsteht – allein der Verdacht genügt, um Ärger zu bekommen. Wer jetzt noch beispielsweise aus dem SAP die Services gewinnen kann, ist einen großen Schritt weiter.

Von Calls und Tickets

Der nächste große Schritt zielt auf die Auswahl eines Tools, das, als Mindestanforderung, Störungsmeldungen der Anwender und die daraufhin erledigten Arbeiten erfasst. Je nach Tool heißen solche Meldungen Tickets oder Calls. Sie zu managen, ist neben der CMDB die zweite unverzichtbare Säule.

Abteilungen mit organisch gewachsenen Strukturen hantieren hier genau wie bei der CMDB gerne nur mit Papierformularen oder E-Mails. Das geht eine ganze Zeit gut, danach aber verlieren die Admins in der Mailflut den Überblick, und die Erkenntnis reift, dass es ohne Tool nicht mehr geht. Die Auswahl an Ticketsystemen erscheint mehr als reichlich.

Neben der Zertifizierung gegen Ende scheint es hier eine zweite Gelegenheit zu geben, um punktuell professionelle Hilfe einzuholen. Denn die Tools unterscheiden sich in vielen Merkmalen, vor allem in der Art, wie sie Prozesse und Workflows abbilden. Probleme ergeben sich nämlich, wenn bereits vorhandene Systeme zu integrieren sind, häufig SAP & Co. Das macht die Eigenarbeit schwierig, aber möglich.

Es gibt Tools, die einen eigenständigen Ansatz verfolgen und bei denen Workflows erst beim Customizing entstehen – was den Vorteil hat, dass die dann wirklich maßgeschneidert sind. Und es gibt Tools, die mit einem vorgefertigten Satz an ITIL-Prozessen kommen, und so schneller zum Erfolg führen. Manchmal ist es aber nötig, einen Workflow an das Tool anzupassen.

Prozesse mit Augenmaß

Während ein Admin das Tool aufsetzt und mit der CMDB füttert, sollte jemand zumindest einen Rohentwurf seiner wichtigsten Prozesse anlegen. Hilfreich ist es, bereits vorhandene Dokumentation heranzuziehen und zu vereinheitlichen. Denn: Jeder noch so geniale Neuentwurf haftet ein Makel an – eben, dass er neu und damit für Mitarbeiter unbekannt ist. Je ähnlicher der Neuentwurf der bisherigen Praxis ist, desto leichter und reibungsärmer wird er umgesetzt werden.

Prozesse haben Besitzer. Das sind Mitarbeiter, die definieren, wie die Firma einen Prozess konkret ausgestaltet. Ein solcher Owner kümmert sich um die Weiterentwicklung der Prozessdokumentation, und er sorgt dafür, sie mit Leben zu füllen. Prozesse definieren Rollen, die wiederum Mitarbeiter ausführen. Die Basisprozesse, ohne die nichts geht, sind:

• Incident Management
• Configuration Management
• Change Management.

Wer sie sauber definiert, für den sind die meisten anderen Prozesse nicht mehr weit. Er sollte sich jedoch unbedingt hüten, zu viel auf einmal zu wollen. Fürs Erste lässt sich ohne Problem Management arbeiten, sich wiederholende Störungen fängt das Incident Management ab, das ohnehin stets mit im Boot ist. Das Release Management vermag das Change Management mit abzuhandeln et cetera. Spezialdisziplinen wie Availability oder Capacity Management brauchen realistisch betrachtet ohnehin fast nur Großbetriebe, oder man fasst Prozesse zusammen.

Botschafter mit Außenwirkung

Im Incident Management (in ITIL zu finden unter: Service Operation | Incident Management) muss sich die IT-Abteilung der Außenwirkung wegen entscheiden, ob sie nur ein Helpdesk oder (besser) ein Servicedesk betreiben möchte. Ideal ist ein so genannter Skilled Service Desk mit Mitarbeitern, die versuchen, die Hälfte oder mehr aller eingehenden Störungen zu beheben, während der Anwender noch am Telefon ist. In den meisten Firmen nehmen die normalen Angestellten von der IT-Abteilung als Ganzes im Normalfall nichts wahr. Sehen können sie nur die Leute, die mal einen PC ausliefern oder reparieren. Zu hören bekommen sie IT-Kräfte am Telefon, wenn sie etwas bestellen oder eine Störung melden. Tipp: Diese IT-Mitarbeiter sollte man auf ihre Rollen als “Botschafter” der IT-Abteilung einschwören.

Ausdifferenziert

Mit steigender Größe wird eine Aufgabenteilung in der Entstörung sinnvoll. Die IT-Abteilung braucht ohnehin Leute, die arbeitsintensivere Sachen nachverfolgen oder Auskünfte bei Herstellern einholen. Fürs vertiefte Bearbeiten schafft man einen Second-Level-Support und für Hausbesuche bei Anwendern und Kunden einen Außendienst. Für den Betrieb eines Rechenzentrums sollten die Admins einige Rollen definieren.

Um die so mühsam erstellte CMDB weiter gut in Schuss zu halten, erweist sich ein Configuration Management als absolut unverzichtbar (in ITIL: Service Transition | Service Asset & Configuration Management). Es regelt, welche Daten von wem wann wie womit zu erheben sind, wer sie pflegt und wer sie überprüft. Eine Validitäts- und Integritätskontrolle ist lästig, muss aber ab und zu sein. Nicht zwingend dagegen sind manuell Inventuren, denn dafür gibt es automatische Tools.

Der Probestart

Wer die elementaren Prozesse beieinander hat, darf mit der Testphase beginnen. Die größte Umstellung für Mitarbeiter ist sicherlich das Rollenmodell an sich. In vielen organisch gewachsenen IT-Abteilungen gibt es Zuständigkeiten: Server repariert der Kollege Huber. Die Telefonanlage macht Franz. Am Telefon sitzt Karla Meier. Mit ITIL gibt es das so nicht mehr. Eine Rolle heißt hier, ein Mitarbeiter führt eine Funktion aus. Ein anderer Mitarbeiter kann die gleiche Rolle und damit Funktion ausführen.

Ein Mitarbeiter darf zudem mehr als eine Rolle innehaben – dann hat er sinnbildlich mehrere Hüte auf. Hier ist es wichtig, dass sich kein Kollege überfordert fühlt. Drei Hüte aufhaben heißt nicht automatisch, für drei arbeiten zu müssen. Das richtig zu justieren ist Aufgabe der Vorgesetzten und nicht immer einfach.

Das Servicedesk beziehungsweise das Auftragsmanagement (oder die Kombination beider) soll so organisiert sein, dass es als die einzige Anlaufstelle für Anwender und Kunden fungiert (Abbildung 2). Als professionell kann eine IT-Abteilung erst gelten, wenn ein Anwender nicht mehr seinen Lieblingsspezialisten direkt anruft, denn die persönliche Bindung erweist sich zwar als schnell, ist aber nicht nachhaltig. Dabei entstehen undokumentierte Lösungen. Wer sich entscheidet, das Auftragsmanagement separat zu betreiben, kann seine Struktur recht ähnlich zu der vom Servicedesk wählen (in ITIL: Service Operations | Request Fulfillment).

Abbildung 2: Das proaktive Servicedesk mit seinen Facetten sollte viele Probleme sofort am Telefon lösen.

King of the Ring

Schwieriger als das in irgendeiner Form ohnehin vorhandenen Servicedesk zu reformieren, ist es, das Change Management (Service Transition | Change Management) zu starten. Denn die Spezialisten im Haus, die wissen “wie man es macht”, lassen sich erfahrungsgemäß nur ungern sagen, dass sie künftig nicht “mal schnell” etwas ändern dürfen. Vielmehr müssen sie nun einen Antrag (Request for Change, RfC) formulieren, über den ein Change Advisory Board berät – und den es auch mal ablehnt.

In einer gut geführten IT-Abteilung kommt kein Administrator einfach so ins Rechenzentrum, sofern er keinen genehmigten RfC und einen Termin (im Forward Schedule of Change) hat. Und nach jedem Change kommt der PIR, der Post Implementation Review. Nur Änderungen, die erfolgreich waren, haben Bestand. Andernfalls muss man einen Rollback erwägen. Für Routine-Aufgaben gibt es übrigens abgespeckte Changes, damit die Bürokratie nicht zu sehr wuchert (Standard Change – vorab autorisiert).

Keine Schikane

Was im ersten Moment nach ausufernder Bürokratie klingt, ist in Wirklichkeit die einzige Chance, Ordnung in den Wildwuchs zu bringen und eine zwingende Voraussetzung für erfolgreiche Entstörungen. Salopp ausgedrückt muss jeder die Welt neu dokumentieren, wenn er sie ändert. Für Systemadministratoren bedeutet es sicherlich eine Umstellung, nicht mehr “King of the Ring” zu sein, sondern Teil eines Teams. Doch wer schon einmal erlebt hat, was passiert, wenn so ein King kündigt (oder nur krank wird), weiß um die Gefahren. Wenn dann, wie so oft, die Dokumentation nicht stimmt, wird es schnell brenzlig.

Gerade wenn die IT-Abteilung nicht besonders groß ist und trotzdem jede Rolle mit einem oder gar mehreren Mitarbeitern zu besetzen ist, bekommen viele Admins mehrere Hüte aufgesetzt, sprich mehrere Rollen zugewiesen. Ideal ist es, wenn der Organisator dabei die bisherige Tätigkeit der Mitarbeiter abbilden kann. Andernfalls sollte er sachlich Naheliegendes kombinieren.

Wie in allen modernen QM-Systemen ist in ITIL auch der Deming-Cycle integraler Bestandteil. Der Zyklus wird auch Plan-do-check-Act oder kontinuierlicher Verbesserungsprozess genannt. Er sieht vor, dass jeder Vorgang erst geplant, dann ausgeführt und dann überprüft wird, und daraufhin wird die Planung verbessert und so weiter.

Die weitere Reise

Ist diese Einführungsphase geschafft, kann sich die Firma daran machen, die Buchhaltung anzuflanschen (ITIL: Service Strategy | Financial Management), und zum Beispiel die Ergebnisse der Aufwandsbuchungen für Tickets SAP zu übergeben. Ohne SAP-Spezialisten geht da gar nichts – eigentlich wie immer, wenn es um Geld geht. Dann zieht man weitere Verästelungen ein.

Sicher lässt das erste Problem nicht lange auf sich warten. Fünf Kollegen können auf einmal nicht mehr drucken. Jemand muss – nachdem die unmittelbare Störung behoben ist – untersuchen, ob es ein Spoolerproblem gab. Oder es leigt ein tiefgreifendes Problem mit dem Drucker vor, der eventuell den Anforderungen nicht gewachsen ist. Oder es gab eine Netzwerkstörung oder eine Putzfrau hat schlicht ein paar Stecker gezogen. Kurz: Ein Problem Management (Service Operation | Problem Management) muss her, das nach den Wurzeln des Übels (Root Causes) sucht und Known-Error-Dokumente erstellt (oder anfertigen lässt). So hat der Servicedesk beim Eingang weiterer Störmeldungen erste Handlungsanweisungen und kann die Experten auftreiben, damit sie wo möglich Lösungen schaffen und dokumentieren (Abbildung 3). Gerade bei großen Störungen bewährt sich ein Problem Management.

Spätestens der nächste Betriebssystemwechsel oder ein Leasingtausch wird die Notwendigkeit des Release Managements (Service Transition | Release and Deploy Management) zeigen, eine Art aufgebohrtes Change Management. Für die Planung des Ausbaus kann ein Capacity Management (Service Design | Capacity Management) sinnvoll sein, für das Einhalten der Servicelevel ein Availability Management (Service Design | Availability Management). Einen Qualitätsmanager sollte spätestens dann bereitstehen, wenn es ans Zertifizieren geht. Er wacht unter anderem darüber, dass alle Prozesse sauber dokumentiert sind, und prüft mit regelmäßigen internen Audits, ob sich auch alle an die Regeln halten.

Jedes Firma kann morgen Opfer eines Hackerangriffs werden, weshalb ITIL jeder IT-Abteilung ein Security Management angedeihen lässt (Service Design | Information Security Management).

Abbildung 3: Das Problem Management sucht nach Root Causes und fertigt Known-Error-Dokumente an.

Mit Sicherheit mehr

Das Ende des Artikel bringt den ITIL-Interessierten allerdings noch nicht zum Ende seiner Todo-Liste: Vertragsmanagement, Lizenzmanagement, Supplier Management, Business Relation Management, Service Portfolio Management, IT Service Continuity Management, Access Management – es bleiben viele Dinge, die er tun kann, wenn die Zeit dafür gekommen ist. Wie schon erwähnt: Lieber anfangs weniger, dafür bessere Prozesse. Und wer den Eindruck hat, dass alles schön läuft, darf eine Zertifizierung ins Auge fassen. Hier ist professionelle Hilfe unerlässlich, denn nur sie erkennt Stolperstellen, bevor man ein teures externes Audit versemmelt.

Fazit

ITIL ist ein Weg zur Professionalisierung. Nicht der einzige, aber ein bewährter. Sofern eine IT-Abteilung nicht zu viel auf einmal will oder sich unnötigerweise vom Start weg unter Zeitdruck setzt, kann sie damit viel erreichen. Ein echter Königsweg existiert nicht, aber die sichere Erkenntnis, dass die Qualität der CMDB über jeden Zweifel erhaben sein muss, um eine Chance auf Sieg zu haben. Den Kunden und Anwendern ist es meistens viel wichtiger, dass alles “schön flutscht”. Wichtiger als Zertifikate allemal.

Der Autor

Oliver Kluge ist ITIL-geprüft und zertifizierter Qualitätsmanagementbeauftragter und -Auditor (QMB/QMA) nach ISO 9001. Er ist verantwortlich für das technische Qualitätsmanagement in der IT des Flughafens München und leitet dort das Testlabor. Er arbeitet auch als Problem Manager und berät IT-Abteilungen anderer Flughäfen in vielen Ländern der Welt. Kluge hat Informatik studiert, war Redakteur bei großen PC-Zeitschriften und 2001 beim Linux-Magazin Leiter des damaligen Competence Center Hardware.