Quasistandard als Handlungsempfehlung

ITIL ist kein Kochbuch

Viele neue Technologien drängen in die Unternehmen, doch sind IT-Abteilungen oft noch damit befasst, den bereits bestehenden Technologiestapel hinsichtlich ­Betriebskosten und einfacher Administrierbarkeit zu optimieren. ITIL (IT Infrastructure Library) kann dabei helfen – zumindest wenn die IT diesen Quasistandard als ­Handlungsempfehlung versteht.

Kochbuch

ITIL wird häufig als Kochbuch verstanden, dem man strikt folgen muss.

Internet of Things (IoT), Industrie 4.0, Cloud und zahllose weitere Technologien versprechen den Unternehmen mehr Effizienz, geringere Kosten und neue Geschäftsmodelle. Doch eines bleibt, wie es schon immer war: Im Mittelpunkt der ganzen Bestrebungen steht die Unternehmens-IT. Die IT-Organisation ist gefordert, die neuen Möglichkeiten schnell nutzbar zu machen, in die bestehenden Landschaften zu integrieren und sie gleichzeitig zuverlässig zu betreiben. Und genau hier beginnt die Herausforderung: „Die IT-Infrastruktur (mit Einbezug neuer Technologien) ist maßgebend für den digitalen Wandel – 59 Prozent der Anwenderunternehmen sind hier unzureichend aufgestellt“, ergibt eine Studie der Experton Group von April dieses Jahres.

Um von neuen Technologien zu profitieren, muss also zunächst die Basis vorhanden sein. Und hier steht es in vielen Unternehmen nicht zum Besten. Die Gründe dafür sind vielfältig und auch zu einem guten Teil nachvollziehbar: Historisch gewachsene IT-Landschaften, hohe Aufwände im täglichen Betrieb und enge Ressourcen lassen wenig Spielraum für Optimierungen. Gleichzeitig schrecken Hilfestellungen wie ITIL eher ab, als dass sie motivieren. Dennoch ist es unumgänglich, sich dieser Werkzeuge zu bedienen.

Für eine funktionierende und zuverlässige IT ist das IT-Service-Management (ITSM) zuständig. Wie ITSM im Idealfall gestaltet werden sollte, ist in erster Linie im Quasistandard ITIL beschrieben. Doch noch immer scheitern Unternehmen bei dem Versuch, jenen in der eigenen IT-Organisation nachhaltig und effizient zu verankern. Der Hauptgrund dafür: ITIL wird als „Kochbuch“ verstanden, dem man strikt folgen muss. Soll der Quasistandard seine Stärken ausspielen, muss er jedoch kritisch hinterfragt werden.

Mehr Rollen als IT-Mitarbeiter


Unternehmen, die darauf abzielen, die IT Infrastructure Library in vollem Umfang einzuführen, sind die Ausnahme. Denn zum einen ist die komplette Ausrichtung der IT an jener eine Mammutaufgabe. Überspitzt gesagt fordert ITIL mehr Rollen, als die meisten Unternehmen IT-Mitarbeiter haben. Zum anderen benötigen die meisten Unternehmen nur einen recht überschaubaren Ausschnitt des Rahmenwerks. Eine vollständige Einführung ist in der Regel nur sinnvoll, wenn ein Unternehmen sich nach ISO/IEC 20000 zertifizieren lassen möchte.

Denn ITIL beschränkt sich nicht darauf, wie die IT konkret betrieben werden sollte. Die Sammlung deckt auch alle Nebenbereiche ab. In der üblicherweise genutzten Version 3 besteht der Quasistandard aus fünf sogenannten Büchern: Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement. Mit dem konkreten Betrieb befasst sich im Wesentlichen der Bereich „Service Operations“. Für die meisten Unternehmen reicht es also aus, sich auf diesen Teil zu konzentrieren. Hierin sind die für den laufenden Betrieb wichtigen Anforderungen an den Service-Desk, das Incident-Management oder auch das Monitoring beschrieben.

Diese grundlegenden Aufgaben des System-Managements nach ITIL-Standards auszurichten, ist besonders lohnend: Laut der aktuellen Studie „IT-Budgets 2016“ von Capgemini werden über 46 Prozent der IT-Budgets für Betrieb, Wartung und Pflege der Systeme ausgegeben. In diesem Bereich zu optimieren, stellt also nicht nur die IT auf eine solide Basis, sondern hilft auch, Ressourcen für innovative Projekte frei zu bekommen. Zudem ist der Einstieg in die „Service Operation“ einfach: Viele Monitoring- und Service-Desk-Lösungen wie Neteye und Erizone von Würth Phoenix verfügen über integrierte und erprobte Prozesse, die auf ITIL aufbauen. So ist z.B. im Service-Desk standardmäßig ausgeschlossen, dass gemeldete Störungen verloren gehen oder nicht hinreichend priorisiert werden. Dadurch muss die IT nicht mit großem Aufwand in den Kernbereichen wie Incident- und Problem-Management eigene Abläufe entwickeln und evaluieren.

Dies ist ein Artikel aus unserer Print-Ausgabe 06/2016. Bestellen Sie ein kostenfreies Probe-Abo.

Oft jedoch wird bei der Planung ein zentrales Element nur en passant betrachtet: das Monitoring. Dieses ist in der IT Infrastructure Library in der Funktion „Operation Management“ angesiedelt, die wiederum ein Element der „Service Operation“ darstellt. Die im Monitoring gewonnenen Daten sind für alle weiteren ITIL-Prozesse entscheidend. Nur wenn hier eine vollständige Sicht auf alle Komponenten der IT möglich ist, lassen sich potentielle Pro-bleme so frühzeitig erkennen und in das Problem- oder Incident-Management einspeisen, dass die Betriebsbereitschaft des Unternehmens nicht gefährdet ist. Dieses Unified Monitoring, bei dem alle Daten zentral erhoben werden, sollte bei allen ITIL-Initiativen zu Beginn berücksichtigt werden und im Rahmen einer entsprechenden schrittweisen Einführung den ersten Meilenstein bilden. Erst dann sollte im zweiten Schritt das Incident- und Problem-Management folgen.

Der Anwender im Mittelpunkt


Doch unabhängig davon, welchen Weg ein Unternehmen bei ITIL geht: Ohne einen kulturellen Wandel sind alle Engagements zum Scheitern verurteilt. Denn im Mittelpunkt von IT Infrastructure Library steht der Service – das Zusammenspiel technologischer Komponenten, die dem Anwender einen Wert bieten. Die Frage, wie es um einen bestimmten Server oder eine spezielle Datenbank bestellt ist, darf heute nicht mehr im Vordergrund stehen. Die Frage muss sein: Wie geht es dem Nutzer?


Das Problem mit dem Incident
Was ist nach ITIL ein Problem, was ein Incident? Bei der Abgrenzung herrscht oft Unklarheit, da das Management beider Aspekte Hand in Hand geht. Unter einem Incident versteht man eine Störung des Betriebs. Das Ziel des Incident-Managements ist es, diese Störung so schnell wie möglich zu beheben, ohne sich mit Ursachenforschung aufzuhalten. Ein Problem ist entsprechend die Analyse, warum es zu den Störungen kommt. Das heißt, das eigentliche Problem, das zu den Störungen führt, wird identifiziert und durch einen Change behoben. Mit einer sogenannten „Post Implementation Review“ wird nachvollzogen, ob es dann so ist.


Bildquelle: Thinkstock/iStock

©2026Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok