Foto: fotandy, Fotolia.de
ITIL wurde Ende der 80-er Jahre in England entwickelt und ist als Best-Practice-Sammlung in der dritten Generation mehr als 30 Jahre alt. Als ich Anfang der 90-er Jahre als Externer für große, international agierende Unternehmen in der Schweiz die ersten Service-Management-Projekte machte, war ich zunächst mit einem babylonischen Begriffswirrwarr konfrontiert: Ein Berater sprach von Incidents, der nächste von Problemen, der dritte von Issues und dem vierten, fünften, sechsten gelang es, noch deutsche Begriffe für ein und denselben Sachverhalt beizufügen. ITIL hat diesen Sprachdschungel gelichtet und über die Jahre Einheitlichkeit in die Sprache -also auch das Verständnis - von IT-Service-Management, kurz ITSM, gebracht.
Im Laufe der Versionen 1, 2 und 3 wurde die Methode mehr und mehr vervollständigt; die einzelnen Themenbereiche gelangten in einen greifbareren Zusammenhang. Trotz der "Hochkonjunktur", die auch der Autor des besagten COMPUTERWOCHE-Beitrags ITIL bescheinigt ist die Best-Practices-Sammlung längst nicht vollständig und wird es wohl auch nie sein. Neue Gebiete wie Cloud Computing oder Bring your own device (Byod) verändern die IT und die IT-Services immer wieder, weshalb auch in ITIL immer wieder neue Aspekte integriert werden müssen.
ITIL ist deshalb auch kein Standard, der "die Möglichkeit eigenständiger Lösungsansätze" verhindert, wie der Autor befürchtet. ITIL ist eine Methode oder eben eine Sammlung von Best Practice-Beispielen. Der wirkliche Standard zum Thema ITSM ist ISO/IEC 20.000, der am Ende des COMPUTERWOCHE-Artikels ebenfalls erwähnt wird. Aber ISO/IEC 20.000 ist im Unterschied zu ITIL kein Modell, aus dem man sich wahlweise bedienen kann, sondern ein internationaler Standard, der Service-Management-Organisationen vergleichbar machen soll. Er führt 142 Kontrollziele auf, von denen die meisten in umfangreiche Detailinformationen - mit insgesamt 181 weiteren Spezifikationen - unterteilt werden. Soll die Norm vom Auditor als erfüllt bestätigt werden, so muss die Befolgung aller Kontrollziele und Spezifikationen nachgewiesen werde.
In Bezug auf ITIL haben die Unternehmen über die Jahre erkannt, dass sie auf der Basis einer unabhängigen Methode ihre eigenen Prozesse entwickeln und implementieren können. Die Vorgaben und Best Practice-Vorschläge kommen mittlerweile nicht mehr nur vom grünen Tisch der Beratungsunternehmen. Jeder kann sich unabhängig ein eigenes Bild davon machen.
Dazu muss der Service-Manager auch nicht gleich die fünf großen Bücher der Kernliteratur verinnerlichen. Einen Überblick bietet der handliche Pocket Guide, und daneben gibt es eine umfangreichere Zusammenfassung in einem Buch. Inzwischen können Interessierte sogar auf separate Zusammenfassungen für einzelne Lifecycle-Phasen zurückgreifen. Das Kursangebot reicht von Informationsveranstaltungen, eintägigen Überblickskursen bis zur Master-Arbeit. Jeder kann, abgestimmt auf seine Situation und seine Bedürfnisse, den angemessenen Grad an Informationen und Ausbildung wählen.
Ein Problem des Projekt-Managements
Der Autor des besagten COMPUTERWOCHE-Beitrags erweckt den Eindruck, ITIL schreibe vor, welche Prozesse wie und in welchem Umfang implementiert werden müssen. Und das bedinge besipielsweise Einführungszeiten von 18 Monaten für einen einzigen Prozess; konkret genannt wird das Asset and Configuration Management. Dieses Beispiel mag ja durchaus der Realität entnommen sein. Es zeigt jedoch eher die Folgen ungenügenden Projekt- Managements, unter Umständen auch mangelnder Erfahrung des Bereratungsunternehmens, als die Mängel von ITIL auf. ITIL bietet, wie schon erwähnt, alle Freiheiten, das zu nutzen, was passt, aber es schreibt nichts vor. Der Asset-and-Configuration-Management-Prozess lässt sich beispielssweise auch nur für Unix-Server einführen, also für kein einziges weiteres Configuration Item.
Ähnliches gilt für das von ITIL verwendete Rollenmodell. In der Tat wird dort eine astronomisch anmutende Anzahl von Rollen beschrieben. Aber die Rollen sind nicht gleichzusetzen mit organisatorischen Stellen. Man kann die Aufgaben eines "Service Desk Agent", der die eingehenden Benutzeranfragen bearbeitet, und die Rolle des "Incident Managers", der für deren vollständige Beantwortung sorgt, nicht einfach negieren, nur weil in der jeweilien IT-Organisation der beides von derselben Person erledigt ist - die dann eventuell auch noch für die Installationen am Mail-Server zuständig ist, also Changes implementiert, die sie möglicherweise sogar selbst bewilligt hat. ITIL beschreibt allgemein, was zu beachten ist, damit diese Aufgaben gut erledig5t wird. Wie das konkret umgesetzt ist, hängt von der jeweiligen Organisation ab.
Seit Jahren ist es meine zentrale Aufgabe, ITIL im Schweizer Mittelstand zu implementieren. Unternehmen mit IT-Organisationen von weniger als 20 Mitarbeitern sind hier keine Seltenheit. Gibt es in diesen Organisationen etwa keine Incidents? Identifizieren die Verantwortlichen keine Probleme, die nachhaltig beseitigt werden müssen? Ist das Inventar unwichtig? Ändern sich die IT-Services und die Infrastruktur nie? Braucht diese IT Organisation keine IT-(Service)Strategie, kein Service Portfolio? Schickt man dort alle Mitarbeiter nach Hause, wenn die IT-Systeme nicht verfügbar sind? Und werden die Verträge mit Lieferanten einfach abgelegt, ohne die Bedingungen zu prüfen sowie deren Einhaltung zu überwachen?
Natürlich nicht. Die Themen in der ITIL-Methodik sind ja auch deshalb in den Büchern beschrieben, weil sie für die meisten IT-Organisationen wichtig sind. Aber jede Organisation muss ITIL auf das Maß beschränken, das sie benötigt. Das kann, darf und muss sie machen. ITIL hat den Mittelstand also nicht vergessen. Tatsächlich nutzen immer mehr mittelständische Unternehmen die Inhalte aus ITIL sowie die Prozesse, Rollenbeschreibungen und Prozessabläufe, Vorschläge für Servicekataloge etc. (qua)