ITIL® Service (Version 5): Wie moderne IT-Services zuverlässig und beweglich bleiben

ITIL® Service (Version 5) zeigt, wie Organisationen digitale Services planen, entwickeln, bereitstellen, unterstützen und kontinuierlich verbessern. Im Mittelpunkt steht das Zusammenspiel aus Servicequalität, Wertschöpfung, verlässlichem Betrieb und messbarem Nutzen für Stakeholder.

Dieses Modul ist ein zentraler Baustein auf dem Weg zum ITIL® Managing Professional. Es richtet sich an alle, die Services nicht nur am Laufen halten, sondern über ihren gesamten Lebenszyklus hinweg wirksam steuern möchten.

Wenn stabil allein nicht mehr gut genug ist

Technisch stabile Services sind nicht automatisch gute Services. Auch bei hoher Verfügbarkeit können lange Änderungszeiten, schlechte Kommunikation oder unklare Verantwortlichkeiten den Nutzen für Anwender:innen und Business einschränken. 

Klassisches Service Management hat über Jahre dabei geholfen, Ordnung in komplexe IT-Landschaften zu bringen. Prozesse wurden definiert, Rollen vergeben, Service Levels vereinbart und Eskalationswege eingerichtet. Das war wichtig und bleibt es auch. 

Aber Cloud-Services, hybride Infrastrukturen, DevOps, Automatisierung und künstliche Intelligenz erhöhen zusätzlich die Veränderungsgeschwindigkeit und die Ansprüche an Sicherheit, Resilienz, Nutzungserlebnis und wirtschaftliche Transparenz. 

Hier setzt ITIL® Service (Version 5) an.

Digital Product und Service Management: ein weiterer Schritt auf dem Weg zum ITIL® Managing Professional

Dieser Beitrag ist der dritte Artikel unserer Reihe zu den einzelnen Modulen auf dem Weg zur Zertifizierung zum ITIL® Managing Professional. 

Nach ITIL® Foundation und ITIL® Product rückt nun die Frage in den Mittelpunkt, wie digitale Services zuverlässig bereitgestellt, unterstützt und verbessert werden.

Der vollständige Qualifizierungsweg umfasst:

• ITIL® Foundation (Version 5) als Einstieg in die zentralen Konzepte, Modelle und Prinzipien, Qualiplaner_ITIL-Version-5.pdf
• ITIL® Product (Version 5) für die Steuerung digitaler Produkte entlang ihres Lebenszyklus, ITIL Product Zertifizierung vorbereiten
• ITIL® Service (Version 5) für die Gestaltung, Bereitstellung und kontinuierliche Verbesserung digitaler Services, ITIL Service Management | Version 5 Training
• ITIL® Experience (Version 5) für die menschliche Wahrnehmung, das Vertrauen und das Nutzungserlebnis, ITIL Experience Zertifizierung vorbereiten
• ITIL® Transformation (Version 5) für die nachhaltige Veränderung von Organisationen, Arbeitsweisen und Services. ITIL Transformation Zertifizierung vorbereiten

Digital Product und Service Management wird dabei bewusst nicht als Sammlung voneinander getrennter Disziplinen verstanden. Product, Service, Experience und Transformation   vermitteln gemeinsam die Fähigkeiten, digitale Produkte und Services durchgängig zu managen und strategische Ziele in messbare Ergebnisse zu übersetzen. 

ITIL® Service nimmt auf diesem Weg eine Schlüsselposition ein, da es Produktidee und Nutzungserlebnis mit der täglichen Realität des Servicebetriebs verbindet.

Ein moderner Service muss über alle Phasen hinweg steuerbar bleiben: 

Was ITIL® Service (Version 5) im Kern behandelt

ITIL® Service beschäftigt sich damit, wie Organisationen ihre Services gestalten, aufbauen, bereitstellen, unterstützen und fortlaufend verbessern. 

Das klingt zunächst vertraut. Service Manager:innen tun vieles davon bereits heute. Neu ist vor allem die Konsequenz, mit der diese Aufgaben als zusammenhängender Lebenszyklus betrachtet werden. 

Es reicht nicht, einen Service sauber zu designen und anschließend an den Betrieb zu übergeben. Ebenso wenig genügt es, den laufenden Betrieb zu optimieren, wenn sich der Service kaum noch am Bedarf der Nutzer:innen orientiert.

Ein moderner Service muss über alle Phasen hinweg steuerbar bleiben: 

• von der ersten Anforderung bis zur konkreten Gestaltung, 
• von der Entwicklung bis zur Einführung,
• vom täglichen Betrieb bis zur Unterstützung, 
• von der Leistungsmessung bis zur kontinuierlichen Verbesserung,
• und irgendwann auch bis zur geordneten Ablösung.

Die entscheidende Frage lautet deshalb nicht nur: „Funktioniert der Service?“ 

Sie lautet: „Schafft der Service zuverlässig den erwarteten Wert und kann er sich weiterentwickeln, wenn sich dieser Wert verändert?“

ITIL Service Management: vom Prozessblick zum Service-Lebenszyklus

Management, Problem Management, Change Enablement oder Service LevelManagement verschwinden nicht plötzlich. 

Der Perspektivwechsel liegt an einer anderen Stelle: Prozesse werden nicht mehr isoliert betrachtet. Sie dienen einem übergeordneten Zweck, nämlich der wirksamen Bereitstellung und Verbesserung eines Services. 

Das lässt sich gut an einem Incident verdeutlichen. 

Aus Prozesssicht könnte der Fall als Erfolg gelten, wenn ein Ticket innerhalb der vereinbarten Zeit geschlossen wurde. Aus Servicesicht stellen sich jedoch weitere Fragen:

• Konnte die betroffene Person tatsächlich weiterarbeiten? 
• Wurde nur das Symptom behoben oder auch die Ursache untersucht? 
• Haben mehrere ähnliche Incidents auf ein strukturelles Problem hingewiesen? 
• Wurde das Wissen aus der Störung für künftige Verbesserungen genutzt? 
• Welche Auswirkungen hatte die Unterbrechung auf den Geschäftsprozess? 

Diese Fragen verbinden operative Arbeit mit Servicequalität, Nutzungserlebnis und geschäftlicher Wirkung. 

Genau darin liegt ein wesentlicher Mehrwert des End-to-End-Denkens.

Value Streams machen Abhängigkeiten sichtbar

Wenn jeder Bereich nur den eigenen Prozess optimiert, kann das Gesamtergebnis trotzdem enttäuschen. 

Value Streams helfen, diese Zusammenhänge sichtbar zu machen. Sie zeigen, welche Aktivitäten, Rollen, Informationen und Entscheidungen erforderlich sind, um aus einem Bedarf tatsächlich einen nutzbaren Service oder eine konkrete Verbesserung zu erzeugen. 

Damit verändert sich auch die Diskussion über Engpässe, da es weniger darum geht, welches Team „schuld“ ist. Stattdessen wird untersucht, an welcher Stelle im Wertstrom möglicherweise Informationen verloren gehen, Entscheidungen warten, Rückfragen entstehen oder unnötige Übergaben stattfinden. 

Das klingt zunächst nach Prozessanalyse, aber der Unterschied liegt im Ausgangspunkt: Betrachtet wird nicht der Ablauf eines einzelnen Prozesses, sondern der Wert, der am Ende für Stakeholder entstehen soll.

Warum ITIL® Service gut zu DevOps und agilen Arbeitsweisen passt

In manchen Organisationen hält sich hartnäckig die Vorstellung, ITIL® stehe für Kontrolle und DevOps für Geschwindigkeit. Das eine sei strukturiert, das andere flexibel. Forschungsergebnisse der DevOps Research and Assessment Group (DORA) zeigen aber seit Jahren, dass Geschwindigkeit und Stabilität kein Widerspruch sein müssen. Leistungsfähige Organisationen erzielen sowohl hohe Bereitstellungsgeschwindigkeit als auch hohe Zuverlässigkeit und kurze Wiederherstellungszeiten. 

In der Praxis hilft die Gegenüberstellung von Kontrolle und Geschwindigkeit aber nur wenig. 

Agile Entwicklung und DevOps lösen andere Probleme als ein umfassendes Service-Management-Framework. Scrum organisiert beispielsweise die iterative Produktentwicklung, wohingegen DevOps die Zusammenarbeit von Entwicklung und Betrieb fördert und schnellere, stärker automatisierte Lieferprozesse unterstützt. ITIL® schafft einen Rahmen, um Services, Wertströme, Governance, Risiken und kontinuierliche Verbesserung miteinander zu verbinden. 

Richtig kombiniert, ergänzen sich diese Ansätze.

ITIL® Service und DevOps im Vergleich

Die beiden Ansätze verfolgen unterschiedliche Schwerpunkte und schließen sich nicht gegenseitig aus.

In der Praxis erzielen Organisationen häufig die besten Ergebnisse, wenn beide Perspektiven zusammengeführt werden. 

Ein DevOps-Team kann Änderungen häufig und automatisiert bereitstellen. Das bedeutet aber nicht, dass Sicherheitsanforderungen, Serviceverantwortung oder Risikobewertung überflüssig werden. Umgekehrt darf Governance nicht dazu führen, dass jede kleine, gut beherrschbare Änderung wochenlang in einem Gremium wartet. 

Ein praxistauglicher Ansatz unterscheidet deshalb nach Risiko und Kontext. 

Standardisierte, automatisiert getestete Änderungen können anders behandelt werden als ein tiefgreifender Eingriff in einen geschäftskritischen Service. Für beides dieselbe Kontrolle vorzusehen, wäre weder effizient noch besonders sicher. 

ITIL® Service liefert an dieser Stelle kein Argument gegen Geschwindigkeit. Es unterstützt Organisationen dabei, Geschwindigkeit steuerbar zu machen.

Stabilität und Veränderung gehören zusammen 

Ein häufiger Fehler im Service Management besteht darin, Stabilität und Veränderung als Gegensätze zu behandeln. 

Der Betrieb möchte Ruhe. Die Entwicklung möchte liefern. Der Fachbereich möchte neue Funktionen. Security möchte Risiken reduzieren. Das Management möchte von allem etwas, möglichst gleichzeitig. 

Solche Spannungen lassen sich nicht vollständig beseitigen. Sie gehören zur digitalen Serviceerbringung. Die Aufgabe eines wirksamen Service Managements besteht deshalb nicht darin, eine Perspektive gegen alle anderen durchzusetzen. 

Es geht um eine bewusste Balance. 

Ein Service, der sich nie verändert, verliert irgendwann seinen Nutzen. Ein Service, der ständig verändert wird, ohne Qualität und Auswirkungen im Blick zu behalten, wird unzuverlässig. 

ITIL® Service stärkt die Fähigkeit, diese Zielkonflikte transparent zu machen. Entscheidungen sollen nicht zufällig, politisch oder nur unter Zeitdruck entstehen. Sie sollen auf nachvollziehbaren Informationen, klaren Verantwortlichkeiten und einem gemeinsamen Verständnis des erwarteten Werts beruhen.

Servicequalität ist mehr als Verfügbarkeit

Verfügbarkeit bleibt wichtig. Ebenso Reaktionszeiten, Wiederherstellungszeiten und technische Leistungswerte. 

Aber sie erzählen nur einen Teil der Geschichte. 

Ein Service kann nahezu durchgehend verfügbar und trotzdem umständlich zu bedienen sein. Ein Support-Team kann schnell antworten, ohne das eigentliche Anliegen zu lösen. Eine Anwendung kann technisch stabil laufen, während sie den Arbeitsprozess der Nutzer:innen unnötig kompliziert macht. 

Deshalb sollte Servicequalität aus mehreren Blickwinkeln betrachtet werden:

• Technische Qualität: Funktioniert der Service zuverlässig und sicher? 
• Operative Qualität: Kann der Service wirksam unterstützt und wiederhergestellt werden? 
• Nutzungsqualität: Können Anwender:innen ihre Aufgaben damit gut erledigen? 
• Geschäftliche Wirkung: Trägt der Service zu relevanten Zielen und Ergebnissen bei? 
• Anpassungsfähigkeit: Kann der Service auf neue Anforderungen reagieren? 
• Wirtschaftlichkeit: Stehen Kosten, Risiken und Nutzen in einem sinnvollen Verhältnis?

Nicht jede Organisation benötigt dafür ein kompliziertes Kennzahlensystem. Im Gegenteil, zu viele Kennzahlen verdecken oft den Blick auf das Wesentliche. 

Wichtig ist eine ausgewogene Auswahl. Technische und prozessbezogene Kennzahlen sollten mit qualitativen Rückmeldungen und businessnahen Ergebnissen verbunden werden. 

Ein grünes Dashboard ist schließlich kein Selbstzweck.

Ein Beispiel aus dem Arbeitsalltag

Stellen wir uns einen internen Collaboration-Service für Videokonferenzen, Chat und Dokumentenaustausch vor. Technisch erfüllt der Service alle vereinbarten Kennzahlen. Die Verfügbarkeit ist hoch, Incidents werden schnell bearbeitet und Updates regelmäßig eingespielt. 

Trotzdem häufen sich Beschwerden. Mitarbeiter:innen sind unsicher, welche Funktionen sie nutzen sollen, externe Gäste können nicht immer problemlos eingebunden werden und neue Funktionen werden kaum erklärt. 

Aus technischer Sicht funktioniert der Service. Aus Sicht der Nutzer:innen entsteht jedoch nicht überall der erwartete Mehrwert. Genau hier setzt die End-to-End-Perspektive von ITIL® Service an: Nicht nur die technische Leistung wird betrachtet, sondern der tatsächliche Nutzen für die Anwender:innen. 

Ein passender Verbesserungsansatz könnte mehrere Ebenen verbinden:

• häufige Supportanfragen systematisch auswerten, 
• typische Nutzungsszenarien mit Fachbereichen überprüfen, 
• Rollen und Verantwortlichkeiten im Service klären, 
• Kommunikation und Hilfsangebote überarbeiten, 
• technische Verbesserungen nach Wirkung priorisieren, 
• Nutzungsfeedback regelmäßig in die Roadmap einfließen lassen.

Nicht jede Maßnahme ist technisch und trotzdem tragen alle zur Servicequalität bei. Genau das ist der Punkt.

Resilienz beginnt nicht erst beim Notfallplan

Digitale Services sind heute Teil zentraler Geschäftsprozesse. Fällt ein kritischer Service aus, betrifft das oft nicht nur die IT, sondern auch Produktion, Vertrieb, Kundenservice oder Logistik können unmittelbar beeinträchtigt sein. 

Resilienz darf deshalb nicht erst dann zum Thema werden, wenn ein Incident bereits eskaliert. 

Sie beginnt deutlich früher:

• bei verständlich definierten Serviceabhängigkeiten, 
• bei realistischen Risikobewertungen, 
• bei klaren Wiederanlaufprioritäten, 
• bei getesteten Notfallverfahren, 
• bei belastbaren Lieferantenbeziehungen, 
• bei nachvollziehbaren Verantwortlichkeiten, 
• und bei der Fähigkeit, aus Störungen zu lernen.

Das bedeutet nicht, jede denkbare Situation vollständig abzusichern. Das wäre weder wirtschaftlich noch realistisch. 

Es bedeutet, bewusst zu entscheiden, welche Störungen ein Service verkraften muss, wie schnell eine Wiederherstellung erforderlich ist und welche Maßnahmen im Verhältnis zum Risiko angemessen sind. 

Resilienz ist also keine Zusatzfunktion. Sie gehört zur Gestaltung und Steuerung eines Services.

Governance muss Orientierung geben

Governance hat in manchen IT-Organisationen keinen besonders guten Ruf. Der Begriff wird schnell mit Freigabeschleifen, Gremien und langen Dokumenten verbunden. 

Dabei ist Governance zunächst etwas sehr Praktisches. Sie beantwortet Fragen wie:

• Wer darf welche Entscheidung treffen? 
• Nach welchen Kriterien werden Risiken bewertet? 
• Welche Leitplanken sind verbindlich? 
• Wo braucht es Kontrolle? 
• Wann können Teams selbstständig handeln? 
• Wie wird Verantwortung nachvollziehbar?

Gute Governance schafft damit klare Entscheidungsrechte und Leitplanken und kann dadurch Entscheidungen sogar beschleunigen, wenn Rollen, Grenzen und Eskalationswege klar sind. 

ITIL® Service sollte deshalb nicht als Einladung verstanden werden, zusätzliche Bürokratie aufzubauen. 

Der bessere Ansatz lautet: so viel Steuerung wie nötig, so viel Eigenverantwortung wie möglich.

Continuous Improvement braucht einen festen Platz

Incidents haben Vorrang, Projekte drängen und die nächste Anforderung wartet bereits. Verbesserungen, die nicht akut sind, rutschen immer wieder nach hinten. 

So entsteht ein bekanntes Muster: Teams arbeiten hart, lösen viele einzelne Probleme und haben trotzdem das Gefühl, dass sich grundlegende Schwierigkeiten ständig wiederholen.

Kontinuierliche Verbesserung braucht deshalb:

• eine sichtbare Liste relevanter Verbesserungen, 
• eine nachvollziehbare Priorisierung, 
• klar benannte Verantwortliche, 
• realistische Kapazitäten, 
• überprüfbare Ziele, 
• und regelmäßige Entscheidungen darüber, was weitergeführt, verändert oder beendet wird.

Nicht jede Optimierung lohnt sich gleichermaßen. Eine technische Verbesserung mag interessant sein, aber kaum Wirkung für Nutzer:innen oder Business entfalten. Umgekehrt kann eine kleine Änderung an Kommunikation oder Self-Service-Angeboten eine große Entlastung schaffen. Auch aktuelle Daten unterstreichen den Zusammenhang zwischen systematischem Service Management und Leistung: Im ITIL Performance Benchmarking Survey 2026 mit 720 Organisationen war eine höhere organisatorische Reife durchgängig mit höheren Performance-Werten verbunden. 

Verbesserung beginnt deshalb nicht mit der Frage: „Was könnten wir alles optimieren?“ 

Sie beginnt mit der Frage: „Wo verlieren unsere Stakeholder heute Wert und was können wir konkret daran ändern?“

Was sich für typische Rollen verändert

ITIL® Service ist für unterschiedliche Rollen relevant, wenn auch aus jeweils anderer Perspektive.

Wo Unternehmen bei der Einführung stolpern

Genau hier liegt ein typisches Missverständnis: Unternehmen übernehmen Begriffe, Rollen und Muster, ohne ausreichend zu prüfen, welches Problem sie eigentlich lösen wollen. Das Ergebnis ist schnell eine neue Schicht aus Meetings, Dokumentation und Kennzahlen. 

Drei Stolpersteine treten besonders häufig auf.

1.Zu viel auf einmal
Eine gesamte Serviceorganisation in einem großen Schritt neu auszurichten, erzeugt oft mehr Unsicherheit als Verbesserung. Überschaubare Pilotbereiche liefern meist bessere Erkenntnisse.

2.Neue Begriffe, alte Entscheidungen 
Ein Prozess wird zum Value Stream umbenannt, ein Service Owner zum Product Owner, aber ansonsten bleibt alles unverändert. Das bringt wenig. Entscheidend sind Verantwortlichkeiten, Entscheidungsrechte und ein veränderter Blick auf Wert.

3.Kennzahlen ohne Konsequenz
Organisationen erheben immer mehr Daten, nutzen sie aber kaum für Entscheidungen. Gute Messung besteht nicht darin, möglichst viele Werte zu sammeln. Sie soll Gespräche verbessern und Handlungen auslösen.

Hinzu kommt ein kultureller Punkt: Ein Zertifikat allein verändert keine Zusammenarbeit. Wenn Silos, unklare Zuständigkeiten oder ein ausgeprägtes Schulddenken bestehen bleiben, kann auch das beste Framework seine Wirkung nur begrenzt entfalten.

So kann der Einstieg in ITIL Service (Version 5) gelingen

Ein pragmatischer Einstieg beginnt nicht mit der vollständigen Neugestaltung aller Prozesse. Er beginnt mit einem konkreten Service und einer ehrlichen Bestandsaufnahme.

1. Einen relevanten Service auswählen
Geeignet ist ein Service, der sichtbar, geschäftlich relevant und zugleich überschaubar ist. Er sollte genügend Verbesserungspotenzial bieten, aber nicht so komplex sein, dass bereits die Analyse zum Großprojekt wird.

2. Den erwarteten Wert klären
Wer nutzt den Service, welches Ergebnis wird erwartet und welche Geschäftsprozesse hängen davon ab? Wo erleben Stakeholder heute Einschränkungen?

Diese Fragen sollten mit allen Beteiligten geteilt werden, nicht allein innerhalb der IT.

3. Den Value Stream betrachten
Wie gelangt eine Anforderung von der Idee bis zur Nutzung, wie wird eine Störung erkannt und behoben und welche Teams, Tools, Lieferanten und Entscheidungen sind beteiligt?

Besonders interessant sind Übergaben, Wartezeiten und wiederkehrende Rückfragen.

4. Verantwortung eindeutig machen
Wer trägt die End-to-End-Verantwortung und entscheidet über Prioritäten, welche Rolle spielen Product Owner, Service Manager:innen, Process Owner, Security und Betrieb?

Nicht jede Zuständigkeit muss neu vergeben werden, sie muss verständlich sein.

5. Wenige aussagekräftige Messgrößen auswählen
Technische Stabilität, Serviceleistung, Nutzerwahrnehmung und geschäftliche Wirkung sollten gemeinsam betrachtet werden. Eine kleine, ausgewogene Kennzahlengruppe ist meist hilfreicher als ein überladenes Dashboard.

6. Verbesserungen sichtbar priorisieren
Verbesserungsideen benötigen eine klare Reihenfolge. Entscheidend sind erwarteter Nutzen, Aufwand, Risiko und Dringlichkeit.

7. Erfahrungen auf andere Services übertragen risieren
Ein Pilot ist kein Beweis, dass bereits alles funktioniert, sondern eine Lernumgebung. Erst wenn klar ist, welche Ansätze sich bewährt haben und welche angepasst werden müssen, sollte die Übertragung auf weitere Services beginnen.

Was ITIL® Service leisten kann, und was nicht – ein Blick in die Zukunft

ITIL Service Version 5 bietet Organisationen einen Rahmen, digitale Services ganzheitlich und wertorientiert zu steuern. Im Mittelpunkt stehen nicht einzelne Prozesse, sondern das Zusammenspiel von Servicequalität, Verantwortung, Value Streams, Resilienz, Governance und kontinuierlicher Verbesserung. 

Das Framework nimmt Unternehmen schwierige Entscheidungen jedoch nicht ab. Sein Nutzen entsteht erst, wenn Prinzipien auf den eigenen Kontext übertragen und im Alltag gelebt werden. Moderne Serviceorganisationen müssen deshalb nicht zwischen Stabilität und Geschwindigkeit wählen – sie müssen beides bewusst steuern. 

Nach ITIL® Product und ITIL® Service richtet sich der nächste Blick dieser Reihe auf ITIL® Experience und damit auf die Frage, wie Menschen digitale Services wahrnehmen und erleben. 

Sie möchten herausfinden, wie ITIL® Service (Version 5) zu Ihrer Organisation, Ihren Teams oder Ihrem Weg zum ITIL® Managing Professional passt?

Wir beraten Sie gerne zu passenden Qualifizierungswegen, individuellen Entwicklungsmöglichkeiten und den nächsten Schritten für Ihre Organisation.

Häufige Fragen zu ITIL® Service (Version 5)

War dieser Artikel hilfreich für Sie?

Geschrieben von

René Kosel

René Kosel verantwortet bei Cegos Integrata als Produktmanager die Bereiche Software-Engineering & Testing sowie IT-Strategie und -Management. Zuvor betreute er die Themenbereiche Produktmanagement, agile Methoden und Change Management.Als ausgebildeter Fachinformatiker für Anwendungsentwicklung und seiner Arbeitserfahrung im Vertrieb der überbetrieblichen Aus- und Weiterbildung verbindet er technisches Know-how mit dem Wissen, was Organisationen antreibt. So entwickelt er Produkte und Lernlösungen, die neben einer hohen Praxisnähe auch aktuelle und zukünftige Herausforderungen abdecken.