„Die IT-Abteilung ist ein schwarzes Loch, in dem Geld verschwindet.” Diesen Satz hört jeder CIO mindestens einmal im Jahr vom CFO. Und kein Wunder — wenn die IT nicht klar zeigen kann, welche Services sie bereitstellt, was sie kosten und wie sie deren Qualität misst, ist es schwer, das Budget zu rechtfertigen. ITIL v3 gibt uns das Framework, um das zu ändern. Und nach drei Jahren Implementierungen wissen wir, dass es funktioniert — aber nicht umsonst.
Was ITIL ist und was es nicht ist¶
ITIL (Information Technology Infrastructure Library) ist kein Standard im strengen Sinne — im Gegensatz zu ISO 20000 können Organisationen sich nicht dagegen zertifizieren lassen. ITIL ist eine Sammlung von Best Practices für IT Service Management. Fünf Bücher, fünf Phasen des Service-Lebenszyklus: Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement.
Die zentrale Neuerung von ITIL v3 gegenüber v2 ist genau dieser Lebenszyklus. ITIL v2 war prozessorientiert — Incident Management, Problem Management, Change Management. ITIL v3 stellt das in den Kontext des Services als Ganzes. Zuerst definiert man die Strategie, dann gestaltet man den Service, überführt ihn in den Betrieb, betreibt ihn und verbessert ihn kontinuierlich. Das klingt logisch. In der Praxis bedeutet es jedoch, dass man nicht einfach einen Service Desk einführen und sagen kann, man „mache ITIL”.
Wo anfangen — Service Desk und Incident Management¶
Dennoch — die meisten unserer Kunden beginnen genau dort, wo es am meisten schmerzt. Und das ist typischerweise der Service Desk. Benutzer rufen verschiedene Nummern an, schreiben E-Mails an verschiedene Personen, Incidents gehen verloren, niemand weiß, was gelöst ist und was nicht. Klassisch.
Die Implementierung eines Service Desks nach ITIL bedeutet einen Single Point of Contact (SPOC), ein Ticketsystem, Incident-Kategorisierung und -Priorisierung, Eskalationsregeln und SLAs. Als Werkzeug verwenden wir bei den meisten Kunden HP Service Manager (ehemals HP OpenView Service Desk) oder BMC Remedy. Für kleinere Unternehmen ziehen wir auch OTRS in Betracht, das Open Source und überraschend leistungsfähig ist.
Incident Management ist der erste Prozess, den wir formalisieren. Das Ziel ist einfach: den Service so schnell wie möglich wiederherstellen. Nicht die Ursache suchen — das ist Problem Management. Diese Unterscheidung ist für IT-Abteilungen oft ungewohnt. Admins wollen naturgemäß die Root Cause finden. Aber dem Benutzer, dessen E-Mail nicht funktioniert, ist es egal warum — er will sie zurück. Jetzt.
Change Management — Kontrolle über Änderungen¶
Der zweite Prozess, den wir einführen, ist Change Management. Und hier stoßen wir auf den größten Widerstand. Entwickler und Admins sind es gewohnt, Änderungen vorzunehmen, wann immer sie es brauchen — Freitagabend, ein Patch auf Produktion, ein Hotfix ohne Test. Change Management sagt: Jede Änderung muss erfasst, bewertet (Risikobewertung), genehmigt (CAB — Change Advisory Board) und geplant werden.
Der häufigste Einwand: „Das wird uns verlangsamen.” Und ja, anfangs wird es das. Aber nach drei Monaten, wenn der Kunde sieht, dass achtzig Prozent der Ausfälle durch nicht genehmigte Änderungen verursacht wurden, lässt der Widerstand nach. Wichtig ist, Change Management nicht als Bürokratie einzuführen. Standard Changes (routinemäßige, vorab genehmigte Änderungen) durchlaufen einen vereinfachten Prozess. Emergency Changes haben ein verkürztes Verfahren mit retrospektiver Genehmigung. Nur Normal Changes durchlaufen den vollständigen Zyklus.
Configuration Management — CMDB¶
Die Configuration Management Database ist der Heilige Gral von ITIL — und gleichzeitig die Stelle, an der die meisten Implementierungen scheitern. Theoretisch sollte die CMDB alle Configuration Items (CIs) und ihre Beziehungen enthalten. Server, Anwendungen, Datenbanken, Netzwerkelemente, Lizenzen, Dokumentation — und wie alles zusammenhängt.
In der Praxis raten wir Kunden: Beginnen Sie mit einem kleinen Scope. Versuchen Sie nicht, alles auf einmal abzubilden. Konzentrieren Sie sich auf kritische Services und ihre Infrastruktur. Verbinden Sie die CMDB mit Incident Management (welches CI betrifft der Incident?) und Change Management (welche CIs wird die Änderung beeinflussen?). Und vor allem — automatisieren Sie die Discovery. Manuelle CMDB-Pflege ist ein Weg in die Hölle veralteter Daten.
Für automatisierte Discovery verwenden wir HP Universal Discovery (ehemals HP DDM) oder Microsoft SCCM, das die meisten Kunden ohnehin für die Desktop-Verwaltung betreiben. Daten aus der Discovery werden dann in die CMDB im HP Service Manager eingespielt.
Service Level Management — messen, was wir versprechen¶
Ein SLA (Service Level Agreement) ist eine Vereinbarung zwischen IT und Business über das Serviceniveau. 99,5 % Verfügbarkeit, Service-Desk-Reaktion innerhalb von 15 Minuten, Lösung von P1-Incidents innerhalb von 4 Stunden. Das klingt einfach, aber ein SLA korrekt zu definieren erfordert Geschäftsverständnis.
Wie oft haben wir SLAs gesehen, die auf technischen Metriken basieren — Server-Verfügbarkeit 99,9 %. Aber den Benutzer interessiert der Server nicht. Ihn interessiert, ob E-Mail, ERP oder das Intranet funktioniert. SLAs sollten auf Service-Ebene definiert werden, nicht auf Infrastruktur-Ebene. Und das erfordert einen Servicekatalog — eine Liste der Services, die die IT bereitstellt, verständlich für das Business.
Werkzeuge und Zertifizierungen¶
Die ITIL-Zertifizierung für Einzelpersonen hat vier Stufen: Foundation, Intermediate, Expert und Master. Foundation ist für jeden IT-Fachmann mit einem dreitägigen Kurs und einem Prüfungstag zu schaffen. Wir empfehlen sie für die gesamte IT-Abteilung — nicht wegen des Zertifikats, sondern wegen der gemeinsamen Sprache. Wenn alle wissen, was ein Incident ist, was ein Problem ist und was ein Change ist, verbessert sich die Kommunikation deutlich.
Was die Werkzeuge betrifft, ist der Markt heute breit aufgestellt. HP Service Manager und BMC Remedy dominieren das Enterprise-Segment. ServiceNow wird zu einer interessanten Alternative — SaaS-Modell, moderne Benutzeroberfläche, schnelle Einführung. Für kleinere Unternehmen ist OTRS oder Mantis eine vernünftige Wahl. Das Wichtigste ist aber: Ein Werkzeug ist nur ein Werkzeug. Ohne Prozesse und Menschen, die sie befolgen, hilft auch die teuerste Software nicht.
Fazit¶
ITIL v3 ist keine Wunderwaffe. Es ist ein Framework, das Investitionen in Menschen, Prozesse und Werkzeuge erfordert. Aber für Unternehmen, in denen die IT aufhört, „der Typ, der den Drucker repariert” zu sein, und zu einem wichtigen Serviceanbieter für das Business wird, ist ITIL die beste verfügbare Landkarte. Es ist kein Zufall, dass die meisten großen öffentlichen und privatwirtschaftlichen Ausschreibungen es heute voraussetzen.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns