Vom Prozess zur Practice — was ITIL 4 strukturell neu denkt
4. Juni 2026
Florian Nitz, Thomas Scherzinger
Lesezeit: 6 Minuten
Warum eine «Practice» mehr ist als ein umbenannter Prozess — und was sich an Verantwortung, Tooling und Organisation verschiebt.
Ein IT-Leiter einer Schweizer Stadtverwaltung blickt auf seine Tool-Landschaft: ein Ticket-System fürs Incident Management, daneben ein Change-Modul, eine separate Configuration Management Database, ein eigenes Tool für die Wissensdatenbank. Jedes mit eigenem Prozess-Eigner, eigenen Kennzahlen, eigenen Schulungen. Auf dem Papier ist alles ITIL-konform.
In der Praxis spricht keines dieser Systeme mit dem anderen. Die CMDB ist seit Monaten nicht gepflegt, und derselbe Vorfall steht in zwei Tools mit zwei verschiedenen Geschichten. Wer hier ein Tool-Problem vermutet, sucht an der falschen Stelle. Es sitzt eine Ebene tiefer, in der Art, wie die IT-Arbeit überhaupt zugeschnitten ist — und genau dort hat ITIL 4 angesetzt. Der Wechsel von «Prozessen» zu «Practices» im Jahr 2019 hat die kleinste Baueinheit der IT-Organisation ausgetauscht: weg vom Workflow, hin zu der Fähigkeit, die ihn überhaupt erst zum Laufen bringt.
Was nach einer Vokabelübung aussieht, ist die folgenreichste strukturelle Neuerung in ITIL 4 — und damit den genaueren Blick wert.
1. Vom Prozess zur Practice — was sich strukturell ändert
Im Wertstrom-Artikel hatten wir es bereits angekündigt: ITIL 4 hat die 26 Prozesse aus Version 3 durch 34 Practices ersetzt. Hinter dem neuen Wort steckt mehr als eine Umbenennung — es geht darum, wie eine IT-Organisation ihre Fähigkeiten überhaupt fasst.
Ein Prozess in ITIL v3 war eine Abfolge mit festem Anfang und Ende: Eingaben rein, definierte Schritte, Ergebnis raus. Incident Management etwa hiess melden, klassifizieren, diagnostizieren, lösen, schliessen. Wer welche Rolle übernahm, stand im Prozesshandbuch. Mit welchem Tool gearbeitet wurde, war ein eigenes Kapitel — und welche Daten dabei zu pflegen waren, noch eines.
Das trug, solange die Umgebung stabil genug blieb, um Abläufe sauber festzuschreiben. Heute überholt die Realität jeden Ablaufplan: Ein Vorfall meldet sich aus dem Monitoring, trifft einen Cloud-Service, wird zur Hälfte von einem Lieferanten gelöst und muss am Ende auch noch regulatorisch sauber dokumentiert sein. Der lineare Workflow ist die Theorie; die Praxis ist ein Geflecht aus Menschen, Systemen, Datenquellen und Partnern.
Eine Practice nimmt dieses Geflecht von vornherein ernst. Sie beschreibt keine Schrittfolge, sondern eine organisatorische Fähigkeit — alles, was zusammenkommen muss, damit ein Bereich zuverlässig liefert: Menschen, die es können, Werkzeuge mit brauchbaren Daten, verlässliche Zulieferer. Workflows gehören dazu, klar. Aber sie sind ein Bestandteil der Practice, nicht ihr Kern.
2. Die vier Dimensionen einer Practice
Jede der 34 Practices steht in ITIL 4 auf vier Dimensionen — und reif ist sie erst, wenn alle vier tragen:
- Organisationen und Menschen — Rollen, Kompetenzen, Kultur. Weniger die Frage, wer was tut, mehr die Frage, wer was kann und wer am Ende geradesteht.
- Information und Technologie — die Daten und Werkzeuge, mit denen gearbeitet wird. Ein Tool ist hier Mittel zum Zweck, nicht der Zweck selbst.
- Partner und Lieferanten — wer von aussen beiträgt, wie zuverlässig, über welche Schnittstellen. Gerade in der Verwaltung gern übersehen.
- Wertströme und Prozesse — wie die Arbeit am Ende wirklich läuft. Hier, und erst hier, sitzen die klassischen Workflow-Elemente.
Ein erstklassiges Tool nützt wenig, wenn die Leute es nicht bedienen können; ein eingespieltes Team läuft ins Leere, wenn die Datenbasis nicht stimmt. Reife entsteht im Zusammenspiel, nicht in einer einzelnen Dimension.
Abbildung 1: Die vier Dimensionen einer Practice — Organisationen und Menschen, Information und Technologie, Partner und Lieferanten, Wertströme und Prozesse. Eine reife Practice entwickelt alle vier gleichzeitig.
Die 34 Practices im Überblick
Die 34 Practices gliedern sich in drei Gruppen:
- General Management Practices (14) — universelle Disziplinen wie Risk Management, Workforce and Talent Management, Project Management.
- Service Management Practices (17) — der Kern: Incident Management, Change Enablement, Service Desk, Problem Management, Service Level Management.
- Technical Management Practices (3) — Infrastructure and Platform Management, Software Development and Management, Deployment Management.
Auf die genaue Zahl kommt es weniger an als auf die Anordnung: Service-Management steht nicht länger isoliert da, sondern eingebettet zwischen allgemeinem Management und technischer Realität.
3. Zwei vertraute Practices im Vergleich
Am greifbarsten wird der Unterschied an zwei alten Bekannten — Incident Management und Change Management.
Incident Management — was sich verschiebt
In v3: ein klar definierter Prozess mit Stufen (Detection, Classification, Investigation, Resolution, Closure). Gemessen wurde die Bearbeitungszeit je Stufe.
In ITIL 4: eine Practice mit dem Zweck, den Service so schnell wie möglich wiederherzustellen. Was sich verschiebt:
- Der Mensch rückt nach vorne. Die erste Frage ist nicht mehr «welcher Workflow greift», sondern «wer löst das am schnellsten — und ist die Person gerade greifbar?». Statt sich durch Eskalationsstufen zu hangeln, holt man die richtigen Köpfe sofort zusammen (Swarming).
- Information und Werkzeuge wachsen zusammen. Monitoring, Wissensdatenbank und Kommunikationskanal greifen ineinander, statt nebeneinander herzulaufen.
- Lieferanten gehören zur Lösung dazu — eingebunden in die Practice und nicht als Black Box, an die man Arbeit übergibt und dann auf Antwort wartet.
Change Management wird zu Change Enablement
Schon der Name verrät die Richtung. Change Management in v3 hiess oft: ein Change Advisory Board, das wöchentlich tagt und Anträge prüft. Sicherheit ging vor Tempo. Change Enablement in ITIL 4 dreht die Frage um — wie ermöglichen wir möglichst viele Changes bei möglichst wenig Risiko? Standard Changes laufen vorautorisiert, Normal Changes mit risikoadäquater Prüfung, Emergency Changes über eine klare Eskalation.
Das ist mehr als Wortklauberei. Eine IT, die laufend ausliefert, kann nicht jede Änderung durch ein wöchentliches Gremium schleusen — sonst wird das Komitee vom Hilfsmittel zum Engpass.
4. Was sich für IT-Verantwortliche konkret ändert
Drei Verschiebungen tauchen in fast jedem ITIL-4-Projekt wieder auf:
- Verantwortung wird breiter. Aus dem «Process Owner Incident Management» wird ein «Practice Owner» — zuständig nicht mehr nur für den Ablauf, sondern auch für die Kompetenzen im Team, die Tool-Auswahl, die Anbindung der Lieferanten und die Datenqualität. Faktisch eine andere und meist grössere Rolle.
- Der Reifegrad wird anders gemessen. Nicht mehr «wie gut läuft unser Prozess», sondern «wie gut ist unsere Fähigkeit insgesamt» — über alle vier Dimensionen. Das bringt Schwachstellen ans Licht, die ein reines Prozess-Audit nie findet: dünn besetzte Teams, in die Jahre gekommene Tools, Lieferanten, deren Beitrag niemand richtig kennt.
- Das Tool kommt zuletzt. Wer eine Practice aufbaut, klärt zuerst Menschen und Daten und sucht dann das passende Werkzeug. Das steht quer zur gewohnten Reihenfolge — erst kaufen, dann weitersehen — und kostet spürbar mehr Disziplin. Dafür trägt das Werkzeug am Ende auch wirklich.
Abbildung 2: Incident Management in v3 versus ITIL 4 — vom linearen Workflow zur Practice, die auf allen vier Dimensionen entwickelt wird. Die Stufen sind nicht verschwunden; sie sind nur nicht mehr die Hauptsache.
5. Fazit: Capability statt Workflow
Practices sind weder eine neue Vokabel noch ein frischer Anstrich fürs Bestehende. Sie tragen der schlichten Tatsache Rechnung, dass IT-Arbeit immer mehr ist als ihr Ablauf — sie hängt genauso an den Menschen, der Datenlage und den Zulieferern dahinter. Wer ITIL 4 nur als umetikettierte Prozesslandschaft einführt, hat den Aufwand umsonst betrieben.
Wer Practices dagegen ernst nimmt und über alle vier Dimensionen aufbaut, bekommt etwas Robusteres: eine Organisation, deren Können nicht am einzelnen Tool oder Ablauf hängt — und die einen Werkzeugwechsel oder eine Reorganisation übersteht, ohne jedes Mal bei null zu beginnen.
Im nächsten Artikel der Serie schauen wir uns an, was ITIL 5 zu diesem Rahmen ergänzt: Lifecycle-Denken über die einzelne Practice hinaus und die Governance künstlicher Intelligenz im ITSM.
Unser Praxistipp
Nehmen Sie sich pro Quartal eine einzige Practice vor — und beurteilen Sie sie entlang der vier Dimensionen, nicht nur entlang des Workflows. Incident Management oder Change Enablement eignen sich gut zum Einstieg, weil beide vertraut genug sind, um den Unterschied spürbar zu machen. Drei ehrliche Fragen je Dimension genügen: Haben wir die richtigen Menschen? Haben wir die richtigen Daten und Werkzeuge? Wissen wir, was unsere Lieferanten beitragen? Und erst dann: Läuft der Workflow? Die Antworten fallen selten bequem aus — und liefern Ihnen genau deshalb die ehrlichste Standortbestimmung.
Autor
Florian Nitz
Florian Nitz ist Consultant bei der Qudits AG und ITIL 4 Managing Professional. Er verantwortet technische und digitale Projekte — von IT-Service-Management bis zur Weiterentwicklung digitaler Plattformen — und verbindet strategische Klarheit mit pragmatischer Umsetzung.
Autor
Thomas Scherzinger
Thomas ist Executive Partner bei Qudits AG und ITIL V3 Expert. Seine Schwerpunkte liegen im Management komplexer IT-Programme und -Projekte — insbesondere im Bereich Life Sciences — sowie im Aufbau und der kontinuierlichen Verbesserung von IT-Service-Management-Organisationen. Mit Leidenschaft entwickelt er Teams und Menschen weiter.