Bildquelle: Pexels / Foto-ID 8297428 / https://www.pexels.com/photo/8297428/ / CC0-Lizenz
ITIL Practices sind kein Arbeitsplan, den ein IT-Betrieb vollständig abhaken muss. Der Nutzen entsteht erst, wenn aus dem Framework konkrete Betriebsaufgaben, Zuständigkeiten und Nachweise werden.
ITIL 4 ist ein Rahmenwerk für IT Service Management. Es beschreibt Begriffe, Grundsätze und Practices, mit denen IT-Organisationen Services planen, betreiben, verbessern und steuern können. Für ITSM-Generalisten ist dabei wichtig: Eine Practice ist kein einzelner Prozess und auch keine fertige Vorlage. Sie bündelt Zweck, Aktivitäten, Rollen, Informationen, Werkzeuge und Steuerungsfragen rund um ein Thema.
Grundlagenkasten: ITIL Practices helfen, wiederkehrende Management- und Betriebsaufgaben zu ordnen. Sie ersetzen aber nicht die Entscheidung, welche Arbeit im eigenen Service tatsächlich geregelt werden muss. Wer zuerst die Aufgabe klärt, kann die passende Practice auswählen, statt das Framework als abstrakte Checkliste zu behandeln.
Die Betriebsaufgabe kommt vor dem Practice-Namen
In vielen ITSM-Diskussionen beginnt die Arbeit mit einer Liste von Practice-Namen. Incident Management, Change Enablement, Problem Management, Service Level Management oder Information Security Management klingen vertraut. Trotzdem sagt der Name allein noch nicht, welches Problem im Alltag gelöst werden soll. Soll der Service Desk Störungen schneller sortieren? Soll ein Audit später Freigaben nachvollziehen? Soll ein Service Owner Kosten, Risiken und Lieferanten besser steuern?
Eine brauchbare Arbeitsliste beginnt deshalb nicht mit der Frage, welche ITIL Practice „eingeführt“ werden soll. Sie beginnt mit dem konkreten Betriebsfall. Ein ausfallkritischer Service braucht andere Regeln als ein kleines internes Werkzeug. Eine neue Cloud-Plattform braucht andere Nachweise als ein stabiler Legacy-Service. Eine Support-Einheit mit vielen Übergaben braucht andere Schnittstellen als ein kleines Betriebsteam mit kurzen Wegen.
Aus Practices werden erst durch Zuständigkeiten echte Arbeit
Eine Practice beschreibt typischerweise, welche Fähigkeiten und Aktivitäten zu einem Themenfeld gehören. Im Betrieb wird daraus aber erst dann eine Arbeitshilfe, wenn klar ist, wer entscheidet, wer dokumentiert, wer prüft und wer im Konflikt eskaliert. Genau hier verlieren abstrakte Framework-Projekte oft Wirkung. Sie liefern ein schönes Zielbild, aber keine belastbare Stelle, an der ein Ticket, eine Änderung oder ein Serviceeintrag wirklich entschieden wird.
Ein Beispiel ist Change Enablement. Das Wort kann groß wirken, die erste Betriebsaufgabe ist aber sehr einfach: Welche Änderung darf direkt umgesetzt werden, welche braucht eine Freigabe und welche muss vorab mit betroffenen Services abgeglichen werden? Erst wenn diese Entscheidung sichtbar ist, kann die Practice helfen. Dann entstehen Felder im Ticket, ein Freigabeweg, ein Nachweis für das Audit und eine Rückfrage an Service Owner.
Ähnlich funktioniert Service Level Management. Die Practice ist nicht erledigt, weil eine SLA-Vorlage existiert. Entscheidend ist, ob die Zusage messbar, zugeordnet und erklärbar bleibt. Dazu passt der interne Beitrag SLA Vorlage mit Messpunkten, weil er zeigt, wie aus Zusagen prüfbare Messpunkte werden. Die Practice liefert den Rahmen, die Betriebsaufgabe macht daraus konkrete Felder und Routinen.
Eine einfache Auswahlmatrix verhindert Framework-Theater
Für eine erste Arbeitsliste reicht oft eine kleine Matrix. In die erste Spalte kommt der Service oder der Betriebsfall. In die zweite Spalte kommt die wiederkehrende Aufgabe, zum Beispiel Störung führen, Änderung freigeben, Risiko bewerten, Provider steuern oder Wissen sichern. Erst danach folgt die passende ITIL Practice. Die vierte Spalte beschreibt den Mindestnachweis: Ticketfeld, Freigabeprotokoll, Review-Termin, Servicekatalogeintrag, Eskalationskontakt oder Bericht.
Diese Reihenfolge schützt vor Framework-Theater. Niemand muss diskutieren, ob eine Organisation „alle Practices“ sauber eingeführt hat. Das bessere Gespräch lautet: Welche Betriebsaufgabe ist gerade ungeregelt, welche Folge hat das und welche Practice hilft beim Strukturieren? Daraus entsteht ein überschaubarer Startpunkt. Ein Team kann mit drei bis fünf Aufgaben beginnen und später erweitern, wenn neue Risiken oder Nachfragen sichtbar werden.
Für Governance-Themen ist diese Arbeitsweise besonders nützlich. Ein Audit fragt selten nach einer schönen Practice-Landkarte. Es fragt nach nachvollziehbaren Entscheidungen, Zuständigkeiten, Nachweisen und Verbesserungen. Deshalb sollte jede ausgewählte Practice mindestens eine Antwort auf die Frage liefern: Welcher Nachweis entsteht im Alltag, ohne dass später jemand mühsam E-Mails, Chatverläufe oder mündliche Absprachen zusammensuchen muss?
ITIL 4 bleibt Rahmen, ISO 20000 prüft Managementsysteme
ITIL 4 und ISO/IEC 20000 werden im Alltag manchmal vermischt. Das ist verständlich, aber riskant. ITIL ist ein Best-Practice-Rahmenwerk. ISO/IEC 20000-1 ist ein Standard für ein Service-Management-System und wird im Zertifizierungskontext anders betrachtet. Für die Arbeitsliste heißt das: ITIL Practices können helfen, Arbeit zu strukturieren. Ein formaler Standard stellt zusätzlich die Frage, ob das Managementsystem Anforderungen systematisch erfüllt.
Diese Unterscheidung verhindert falsche Erwartungen. Eine Organisation wird nicht auditfest, nur weil sie ITIL-Begriffe verwendet. Sie wird belastbarer, wenn sie Serviceziele, Rollen, Risiken, Änderungen, Lieferanten, Wissen und Verbesserungen so dokumentiert, dass Entscheidungen wiederholbar und prüfbar sind. Das passt zum Beitrag Schreibe Freigaben direkt ins Ticket, denn auch dort steht nicht der Methodenname im Mittelpunkt, sondern der Nachweis im Arbeitsfluss.
Der beste Startpunkt ist eine schmerzhafte Wiederholung
Eine gute Practice-Auswahl erkennt man daran, dass sie eine wiederkehrende Reibung im Betrieb reduziert. Wenn Störungen immer wieder unklar geführt werden, lohnt der Blick auf Incident Management und Kommunikationsregeln. Wenn Änderungen Nebenwirkungen erzeugen, gehört Change Enablement in die Arbeitsliste. Wenn Provider-Rückmeldungen fehlen, braucht Supplier Management eine konkrete Rückmeldefrist. Der interne Beitrag Provider-Aufgaben mit Rückmeldefrist zeigt, wie aus einer abstrakten Steuerungsfrage ein handhabbarer Übergabepunkt wird.
Die Reihenfolge sollte deshalb pragmatisch bleiben: erst die Wiederholung benennen, dann die Folge für Service, Nutzer, Audit oder Kosten beschreiben, danach die passende Practice auswählen und zuletzt den kleinsten belastbaren Nachweis definieren. So wird das Framework weder verkleinert noch überhöht. Es wird als Werkzeug genutzt, um die richtige Betriebsarbeit sichtbar zu machen.
Die Arbeitsliste braucht einen Owner und einen Review-Takt
Eine Auswahlmatrix ist nur dann wirksam, wenn sie gepflegt wird. Für jede Aufgabe sollte ein Owner benannt sein. Außerdem braucht die Liste einen Review-Takt, zum Beispiel monatlich im Service-Review oder quartalsweise im Verbesserungsmeeting. Dabei geht es nicht um Bürokratie. Es geht darum, veraltete Regeln zu erkennen, Nachweise zu vereinfachen und neue Betriebsrisiken rechtzeitig aufzunehmen.
Der praktische Test ist einfach: Kann ein Service Owner erklären, warum diese Practice für den eigenen Service wichtig ist? Kann der Service Desk sehen, welche Information im Ticket gebraucht wird? Kann ein Auditor später erkennen, wer entschieden hat? Wenn diese drei Fragen beantwortet sind, wird aus ITIL 4 keine Folie, sondern eine brauchbare Arbeitsliste für den Betrieb.
Quellen und Einordnung: PeopleCert zu ITIL 4, AXELOS zu ITIL 4 Practices, PeopleCert zur ITIL 4 Foundation, BSI zu ISO/IEC 20000-1 Service Management. Stand der Quellenprüfung: 03.08.2026. Bildquelle: Pexels / Foto-ID 8297428 / https://www.pexels.com/photo/8297428/ / CC0-Lizenz
