2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen

2.1 Was ist ITIL und wie ist das Framework aufgebaut?

Kurz erklärt

ITIL ist ein anpassbares Best-Practice-Framework für das Management digitaler Produkte und Services.

Es unterstützt Organisationen dabei, technische und organisatorische Fähigkeiten so miteinander zu verbinden, dass für Benutzer, Kunden und weitere Stakeholder verlässliche Outcomes und nachhaltiger Wert entstehen.

ITIL ist kein fertiger Unternehmensprozess, kein Ticketsystem und keine technische Anleitung. Das Framework stellt Begriffe, Prinzipien, Modelle und Management Practices bereit, die an die jeweilige Organisation angepasst werden müssen.

Was bedeutet ITIL?

Die Bezeichnung ITIL entstand ursprünglich aus dem Namen Information Technology Infrastructure Library.

Heute wird ITIL als eigenständiger Name des Frameworks verwendet.

Die aktuelle Generation ist ITIL Version 5.

Sie betrachtet nicht mehr ausschließlich den Betrieb von IT-Services, sondern das integrierte Management digitaler Produkte und Services über ihren gesamten Lebenszyklus.

Dazu gehören unter anderem:

Bedarf und Chancen erkennen,
Produkte und Services gestalten,
Lösungen beschaffen oder entwickeln,
Änderungen in die produktive Umgebung überführen,
Systeme betreiben,
Services bereitstellen,
Benutzer unterstützen,
Erfahrungen auswerten,
und Produkte, Services sowie Arbeitsweisen kontinuierlich verbessern.

Merke

ITIL beschreibt nicht nur, wie bestehende IT-Services unterstützt werden.

Es betrachtet auch, wie digitale Produkte und Services entstehen, zusammenwirken und über ihren gesamten Lebenszyklus Wert ermöglichen.

Was ist ein Framework?

Ein Framework ist ein strukturierter Orientierungsrahmen.

Es stellt unter anderem bereit:

gemeinsame Begriffe,
grundlegende Prinzipien,
Modelle,
Practices,
Betrachtungsperspektiven,
Entscheidungshilfen,
und bewährte Vorgehensweisen.

Ein Framework schreibt jedoch nicht jeden Arbeitsschritt verbindlich vor.

ITIL legt beispielsweise nicht grundsätzlich fest:

welches Ticketsystem verwendet werden muss,
wie viele Supportgruppen eine Organisation benötigt,
welche Prioritätsmatrix eingesetzt werden muss,
wer jeden Change genehmigt,
wie ein Organigramm aufgebaut sein muss,
oder welche technischen Produkte eingesetzt werden sollen.

Diese Entscheidungen hängen vom jeweiligen Kontext ab.

Dazu gehören beispielsweise:

Größe der Organisation,
angebotene Produkte und Services,
gesetzliche und vertragliche Anforderungen,
Risiken,
Sicherheitsanforderungen,
vorhandene Fähigkeiten,
verwendete Technologien,
Unternehmenskultur,
und Zusammenarbeit mit Partnern und Lieferanten.

Grundsatz

ITIL wird nicht unverändert „installiert“.

Die Organisation verwendet geeignete Bestandteile des Frameworks und passt sie an ihren tatsächlichen Bedarf an.

ITIL ist Best-Practice-Guidance

ITIL stellt bewährte Orientierung für das Management digitaler Produkte und Services bereit.

Best Practice bedeutet in diesem Zusammenhang:

Die beschriebenen Konzepte haben sich in vielen Organisationen als hilfreich erwiesen.
Die Inhalte bieten eine fachlich strukturierte Ausgangsbasis.
Die Empfehlungen müssen an den jeweiligen Kontext angepasst werden.
Eine andere Vorgehensweise kann in einer konkreten Organisation ebenfalls sinnvoll sein.
Betriebliche, gesetzliche und sicherheitsrelevante Vorgaben besitzen weiterhin Vorrang.

ITIL ist deshalb weder:

eine gesetzliche Vorschrift,
eine technische Norm,
eine Produktzertifizierung,
noch eine Garantie für erfolgreiche Servicequalität.

Typischer Fehler

Eine Organisation übernimmt Begriffe, Formulare und Genehmigungsstufen, ohne zu prüfen, welches konkrete Problem damit gelöst werden soll.

Dadurch kann unnötige Bürokratie entstehen, ohne dass sich Produkte, Services oder Outcomes verbessern.

Wofür ITIL eingesetzt wird

ITIL kann Organisationen dabei unterstützen:

digitale Produkte und Services ganzheitlich zu betrachten,
gemeinsame Begriffe zu verwenden,
Verantwortlichkeiten zu klären,
Zusammenarbeit zwischen Teams zu verbessern,
Entscheidungen an Wert und Outcomes auszurichten,
technische und organisatorische Abhängigkeiten zu berücksichtigen,
Risiken bewusster zu behandeln,
Erfahrungen von Benutzern und Kunden einzubeziehen,
geeignete Management Practices zu etablieren,
Wertströme zu verstehen und zu verbessern,
und kontinuierliche Verbesserung in die tägliche Arbeit zu integrieren.

ITIL kann in unterschiedlichen Organisationen eingesetzt werden.

Beispiele:

interne IT-Abteilung,
Managed Service Provider,
Cloud-Anbieter,
Softwareunternehmen,
öffentliche Verwaltung,
Krankenhaus,
Produktionsunternehmen,
Bildungseinrichtung,
Finanzunternehmen,
oder gemeinnützige Organisation.

Die Grundgedanken sind nicht auf eine bestimmte Branche oder Organisationsgröße beschränkt.

ITIL richtet sich nicht nur an IT-Service-Manager

ITIL ist für unterschiedliche Rollen relevant.

Dazu gehören beispielsweise:

Fachinformatiker für Systemintegration,
Service-Desk-Mitarbeiter,
Systemadministratoren,
Netzwerkadministratoren,
Supporttechniker,
Produktverantwortliche,
Service Owner,
Entwickler,
Informationssicherheitsverantwortliche,
Projekt- und Change-Verantwortliche,
Lieferantenmanager,
Führungskräfte,
und Mitarbeiter aus Fachabteilungen.

Nicht jede Rolle benötigt dasselbe Detailwissen.

Ein Fachinformatiker für Systemintegration muss beispielsweise nicht jede strategische Entscheidung selbst treffen.

Er sollte jedoch verstehen:

welcher Service von seiner technischen Arbeit abhängt,
welche Auswirkungen eine Änderung besitzen kann,
wie Incidents und Service Requests eingeordnet werden,
wann eine Eskalation notwendig ist,
welche Informationen dokumentiert werden müssen,
und wie technische Erkenntnisse in Verbesserungen einfließen.

Der zentrale Gedanke: Wert ermöglichen

ITIL richtet das Management digitaler Produkte und Services auf Wert aus.

Wert entsteht nicht allein dadurch, dass eine technische Komponente vorhanden ist.

Ein Service ist beispielsweise nicht automatisch wertvoll, nur weil:

ein Server läuft,
eine Anwendung installiert wurde,
ein Benutzerkonto existiert,
ein Backup erfolgreich beendet wurde,
oder ein Monitoring-System keine Warnung zeigt.

Entscheidend ist, ob die beteiligten Stakeholder die benötigten Outcomes erreichen.

Beispiele:

Technischer Output	Erwartetes Outcome
Benutzerkonto wurde angelegt.	Neuer Mitarbeiter kann seine Aufgaben ausführen.
VPN-Client wurde installiert.	Mitarbeiter kann sicher von außerhalb arbeiten.
Backup wurde erstellt.	Daten können nach einem Verlust wiederhergestellt werden.
Anwendung wurde bereitgestellt.	Fachabteilung kann ihren Geschäftsprozess durchführen.
Monitoring wurde eingerichtet.	Relevante Störungen werden rechtzeitig erkannt und behandelt.

Bei der Bewertung von Wert berücksichtigt ITIL Version 5 insbesondere das Zusammenspiel von:

Outcomes,
Kosten,
Risiken,
Erfahrung,
Nachhaltigkeit,
und den Erwartungen der beteiligten Stakeholder.

Wert wird gemeinsam ermöglicht

Wert wird nicht ausschließlich vom Service Provider erzeugt und anschließend an einen passiven Kunden übergeben.

Service Provider, Service Consumer und weitere Stakeholder wirken gemeinsam daran mit, dass ein gewünschtes Outcome erreicht wird.

Beispiel: sicherer Fernzugriff

Der Service Provider stellt unter anderem bereit:

VPN-Infrastruktur,
Identitätsprüfung,
Multi-Faktor-Authentifizierung,
Support,
Monitoring,
Sicherheitsmaßnahmen,
und Dokumentation.

Der Benutzer trägt unter anderem bei durch:

Schutz seiner Zugangsdaten,
ordnungsgemäße Verwendung der MFA,
Verwendung eines geeigneten Endgeräts,
Einhaltung von Sicherheitsvorgaben,
und rechtzeitige Meldung von Störungen.

Die Fachabteilung oder Führungskraft trägt möglicherweise bei durch:

Genehmigung des Zugriffs,
Festlegung notwendiger Berechtigungen,
rechtzeitige Mitteilung organisatorischer Änderungen,
und Überprüfung des tatsächlichen Bedarfs.

Merke

Ein Service kann technisch bereitgestellt werden.

Das gewünschte Outcome entsteht jedoch erst durch das Zusammenwirken der beteiligten Personen, Teams, Technologien und Arbeitsweisen.

Der Aufbau von ITIL Version 5

ITIL Version 5 besteht aus mehreren miteinander verbundenen Bestandteilen.

Bestandteil	Zweck
Grundbegriffe des Produkt- und Service-Managements	schaffen eine gemeinsame fachliche Sprache
Wertschöpfung und Servicebeziehungen	erklären, wie Stakeholder gemeinsam Outcomes und Wert ermöglichen
vier Dimensionen	unterstützen eine ganzheitliche Betrachtung
ITIL Value System	verbindet die zentralen Elemente des Frameworks
Guiding Principles	unterstützen Entscheidungen in unterschiedlichen Situationen
Governance	sorgt für Steuerung, Überwachung und Verantwortlichkeit
Value Chain Activities	beschreiben zentrale Aktivitäten zur Wertschöpfung
Management Practices	stellen organisatorische Fähigkeiten und Ressourcen für bestimmte Aufgaben bereit
Continual Improvement	unterstützt die fortlaufende Verbesserung
Product and Service Lifecycle	verbindet Produkt- und Servicearbeit über einen gemeinsamen Lebenszyklus
Value Stream Mapping and Management	macht den Arbeitsfluss zur Erzeugung von Wert sichtbar und verbesserbar

Diese Bestandteile dürfen nicht dauerhaft isoliert betrachtet werden.

Sie ergänzen sich und werden abhängig von der jeweiligen Situation miteinander kombiniert.

Das ITIL Value System

Das ITIL Value System beschreibt, wie unterschiedliche Bestandteile und Aktivitäten einer Organisation zusammenwirken, um Wert zu ermöglichen.

Es verbindet:

Guiding Principles,
Governance,
Value Chain Activities,
Management Practices,
und Continual Improvement.

Das Value System dient als übergeordneter Orientierungsrahmen.

Es hilft bei Fragen wie:

Woran sollen Entscheidungen ausgerichtet werden?
Wie wird die Organisation gesteuert und kontrolliert?
Welche Aktivitäten sind für die Wertschöpfung notwendig?
Welche Fähigkeiten und Practices werden benötigt?
Wie werden Erfahrungen und Ergebnisse für Verbesserungen genutzt?

Wichtig

Das ITIL Value System ist kein einzelner Prozess.

Es beschreibt das Zusammenwirken verschiedener Elemente des Produkt- und Service-Managements.

Die einzelnen Bestandteile werden auf späteren Seiten dieses Kapitels ausführlich behandelt.

Die Guiding Principles

Die Guiding Principles sind allgemeine Empfehlungen, die Entscheidungen und Handlungen in unterschiedlichen Situationen unterstützen.

Sie sollen dabei helfen:

den tatsächlichen Nutzen im Blick zu behalten,
vorhandene Fähigkeiten und Informationen zu berücksichtigen,
schrittweise und auf Grundlage von Feedback vorzugehen,
über Team- und Systemgrenzen hinweg zusammenzuarbeiten,
Produkte und Services ganzheitlich zu betrachten,
unnötige Komplexität zu vermeiden,
und geeignete Tätigkeiten zu optimieren oder zu automatisieren.

Die Guiding Principles sind keine starren Arbeitsschritte.

Sie dienen als Denk- und Entscheidungshilfe.

Ein einzelner Grundsatz sollte nicht isoliert angewendet werden, wenn dadurch andere wichtige Perspektiven übersehen werden.

Praxisbeispiel

Die Automatisierung einer Benutzeranlage kann Zeit sparen.

Vor der Automatisierung muss jedoch verstanden werden:

welche Daten benötigt werden,

welche Genehmigungen gelten,

welche Fehler auftreten können,

welche Sicherheitsanforderungen bestehen,

und wie das Ergebnis kontrolliert wird.

Governance

Governance sorgt dafür, dass die Organisation:

eine klare Richtung besitzt,
Entscheidungen angemessen getroffen werden,
Verantwortlichkeiten festgelegt sind,
Leistung und Risiken überwacht werden,
und Tätigkeiten mit den Zielen der Organisation übereinstimmen.

Governance ist nicht mit täglichem Management gleichzusetzen.

Vereinfacht betrachtet:

Governance	Management
legt Richtung und Rahmenbedingungen fest	plant und koordiniert die praktische Umsetzung
bewertet Bedürfnisse und Erwartungen	organisiert Ressourcen und Aktivitäten
überwacht Leistung und Regelkonformität	führt Arbeit innerhalb der Vorgaben durch
stellt Verantwortlichkeit sicher	bearbeitet konkrete Aufgaben und Entscheidungen

Beispiel:

Die Unternehmensleitung kann vorgeben, dass administrative Zugriffe grundsätzlich durch Multi-Faktor-Authentifizierung geschützt werden müssen.

Das zuständige IT-Team plant und implementiert anschließend die konkrete technische Lösung.

Die vier Dimensionen

ITIL verwendet vier Dimensionen, damit Produkte und Services nicht ausschließlich aus einer technischen Perspektive betrachtet werden.

Dimension	Typische Inhalte
Organisationen und Menschen	Rollen, Verantwortlichkeiten, Kompetenzen, Kommunikation und Kultur
Informationen und Technologie	Daten, Anwendungen, Infrastruktur, Automatisierung und Wissen
Partner und Lieferanten	Hersteller, Provider, Verträge und externe Abhängigkeiten
Wertströme und Prozesse	Aktivitäten, Abläufe, Übergaben, Kontrollen und Arbeitsfluss

Die Dimensionen beeinflussen sich gegenseitig.

Beispiel:

Eine neue Monitoring-Plattform kann technisch leistungsfähig sein.

Sie liefert trotzdem keinen ausreichenden Nutzen, wenn:

Mitarbeiter nicht geschult wurden,
Verantwortlichkeiten für Alarme unklar sind,
ein externer Provider nicht eingebunden ist,
oder kein geregelter Ablauf für die Behandlung relevanter Events existiert.

Merke

Ein technisches Problem kann organisatorische Ursachen besitzen.

Ein organisatorisches Problem kann technische Folgen verursachen.

Der Product and Service Lifecycle

ITIL Version 5 verwendet ein gemeinsames Lebenszyklusmodell für digitale Produkte und Services.

Das Modell umfasst acht miteinander verbundene Aktivitäten:

Discover – Bedarf, Chancen, Erwartungen und Ausgangslage verstehen
Design – geeignete Produkte, Services und Lösungen gestalten
Acquire – benötigte Ressourcen, Produkte oder Leistungen beschaffen
Build – Lösungen erstellen, konfigurieren, integrieren und testen
Transition – neue oder geänderte Lösungen kontrolliert in die vorgesehene Umgebung überführen
Operate – Produkte, Systeme und technische Fähigkeiten betreiben
Deliver – Services und vereinbarte Leistungen für Stakeholder bereitstellen
Support – Benutzer, Kunden, Produkte und Services unterstützen

Die Aktivitäten bilden keinen starren linearen Ablauf.

Je nach Situation können sie:

parallel stattfinden,
wiederholt werden,
sich gegenseitig beeinflussen,
oder Rücksprünge zu früheren Aktivitäten erforderlich machen.

Beispiel:

Während des Betriebs kann erkannt werden, dass eine Anwendung die Anforderungen der Benutzer nicht ausreichend erfüllt.

Diese Erkenntnis kann erneut zu Discovery und Design führen, obwohl das Produkt bereits produktiv verwendet wird.

Wichtig

Ein Produkt oder Service befindet sich nicht dauerhaft nur in einer einzigen Lebenszyklusaktivität.

Unterschiedliche Versionen, Komponenten oder Verbesserungen können gleichzeitig verschiedene Aktivitäten durchlaufen.

Management Practices

Eine Management Practice ist mehr als ein einzelner Prozess.

Sie umfasst organisatorische Ressourcen und Fähigkeiten, die zur Erreichung eines bestimmten Zwecks eingesetzt werden.

Dazu können gehören:

Menschen und Rollen,
Informationen und Wissen,
Prozesse und Wertströme,
Technologien und Werkzeuge,
Partner und Lieferanten,
Regeln und Kontrollen,
sowie Kennzahlen und Verbesserungsmaßnahmen.

Beispiele für Management Practices:

Incident Management,
Problem Management,
Service Request Management,
Change Management,
Service Configuration Management,
IT Asset Management,
Knowledge Management,
Monitoring and Event Management,
Information Security Management,
Supplier Management,
Service Level Management,
und Continual Improvement.

ITIL Version 5 verwendet weiterhin 34 Management Practices.

Diese sind in zwei Gruppen eingeordnet:

Product and Service Management Practices
General Management Practices

Typischer Fehler

Eine Practice wird ausschließlich als Ablaufdiagramm betrachtet.

Für eine wirksame Practice werden jedoch auch Rollen, Informationen, Fähigkeiten, Werkzeuge, Beziehungen und kontinuierliche Verbesserungen benötigt.

Continual Improvement

Continual Improvement ist im gesamten ITIL-Framework verankert.

Verbesserungen können sich beziehen auf:

Produkte,
Services,
technische Komponenten,
Practices,
Prozesse,
Wertströme,
Benutzererfahrung,
Zusammenarbeit,
Werkzeuge,
Dokumentation,
und Fähigkeiten von Mitarbeitern.

Eine Verbesserung sollte nicht nur aus einer spontanen Idee bestehen.

Sie sollte möglichst beantworten:

Was soll verbessert werden?
Warum ist die Verbesserung notwendig?
Wie sieht der aktuelle Zustand aus?
Welcher Zielzustand wird angestrebt?
Welche Maßnahme ist sinnvoll?
Wie wird die Wirkung überprüft?
Wie werden Erkenntnisse gesichert?

Beispiel:

Nach mehreren Störungen wird erkannt, dass ein ablaufendes Zertifikat nicht rechtzeitig bemerkt wurde.

Eine nachhaltige Verbesserung könnte umfassen:

Zertifikate zentral erfassen,
Ablaufdaten überwachen,
rechtzeitig Warnungen erzeugen,
Verantwortlichkeiten festlegen,
Erneuerungsverfahren dokumentieren,
und die Wirksamkeit der Alarmierung testen.

Value Streams

Ein Value Stream beschreibt die Abfolge von Schritten, durch die für einen Stakeholder Wert ermöglicht wird.

Ein Value Stream kann mehrere:

Teams,
Practices,
Technologien,
Lieferanten,
und organisatorische Bereiche

miteinander verbinden.

Beispiel: neuer Mitarbeiter benötigt einen arbeitsfähigen IT-Arbeitsplatz

Mögliche Schritte:

Personalabteilung meldet den Eintritt.
Führungskraft benennt Aufgaben und Berechtigungen.
Benutzerkonto wird erstellt.
Lizenzen werden zugewiesen.
Endgerät wird vorbereitet.
Sicherheitsmaßnahmen werden eingerichtet.
Zugriffe werden getestet.
Gerät und Zugangsdaten werden übergeben.
Benutzer bestätigt die Arbeitsfähigkeit.
Dokumentation und Asset-Daten werden aktualisiert.

An diesem Value Stream können unter anderem beteiligt sein:

Personalabteilung,
Führungskraft,
Service Desk,
Identitätsmanagement,
Endgeräteverwaltung,
Informationssicherheit,
Einkauf,
Lieferanten,
und der neue Mitarbeiter.

Merke

Ein Value Stream folgt dem Weg zum gewünschten Outcome.

Er endet nicht automatisch an der Grenze eines einzelnen Teams.

ITIL verbindet Produkt- und Serviceperspektive

Digitale Produkte und Services sind zwei eng miteinander verbundene Perspektiven auf eine technologiebasierte Lösung.

Die Produktperspektive betrachtet beispielsweise:

Entwicklung,
Funktionen,
Roadmap,
technische Fähigkeiten,
Lebenszyklus,
Investitionen,
und Weiterentwicklung.

Die Serviceperspektive betrachtet beispielsweise:

Nutzung,
Servicequalität,
Unterstützung,
Beziehungen,
Erfahrung,
Verfügbarkeit,
und vereinbarte Outcomes.

Beide Perspektiven benötigen einander.

Ohne ausreichende Produktperspektive	Ohne ausreichende Serviceperspektive
technische Schulden werden übersehen	Benutzeranforderungen werden übersehen
Produktentwicklung erfolgt ohne langfristige Planung	Support und Betrieb werden zu spät berücksichtigt
Funktionen werden unkoordiniert erweitert	technisch erfolgreiche Produkte liefern keine brauchbaren Services
Lebenszyklus und Ablösung bleiben ungeklärt	Erfahrung und Servicequalität werden nicht ausreichend bewertet

ITIL Version 5 verbindet diese Perspektiven durch einen gemeinsamen Produkt- und Service-Lebenszyklus.

Was ITIL nicht vorgibt

ITIL gibt keinen universellen Musterprozess für jede Organisation vor.

Das Framework bestimmt nicht automatisch:

die konkrete Organisationsstruktur,
die Anzahl der Supportebenen,
die verwendete Software,
die Namen interner Teams,
die Prioritätsstufen,
die Servicezeiten,
die Genehmigungsbefugnisse,
die genaue Ticketstruktur,
oder die technische Architektur.

Diese Elemente müssen von der Organisation selbst gestaltet werden.

ITIL unterstützt dabei mit:

gemeinsamen Begriffen,
Prinzipien,
Modellen,
Practices,
und bewährten Fragestellungen.

ITIL ist keine Zertifizierung einer Organisation

Personen können ITIL-Zertifizierungen erwerben.

Das bedeutet jedoch nicht automatisch, dass:

ihre Organisation vollständig nach ITIL arbeitet,
alle beschriebenen Practices eingeführt wurden,
Prozesse wirksam sind,
Services eine hohe Qualität besitzen,
oder jede interne Regel einer offiziellen ITIL-Vorgabe entspricht.

Auch ein Werkzeug kann bestimmte ITIL-Practices unterstützen oder dafür bewertet worden sein.

Das Werkzeug allein führt jedoch kein wirksames Service Management ein.

Merke

Zertifikate, Werkzeuge und Prozessdokumente können professionelles Service Management unterstützen.

Entscheidend ist, wie wirksam die Organisation tatsächlich arbeitet und welche Outcomes sie erreicht.

ITIL und andere Methoden oder Frameworks

ITIL kann gemeinsam mit anderen Ansätzen verwendet werden.

Beispiele:

Ansatz	Mögliche Ergänzung zu ITIL
Agile Arbeitsweisen	iterative Entwicklung und schnelles Feedback
Scrum	strukturierte Produktentwicklung in Teams
Kanban	Visualisierung und Steuerung des Arbeitsflusses
DevOps	Zusammenarbeit zwischen Entwicklung, Betrieb und weiteren Beteiligten
Lean	Reduzierung von Verschwendung und Verbesserung des Flusses
COBIT	Governance und Steuerung von Information und Technologie
ISO/IEC 20000	Anforderungen an ein Service-Management-System
ISO/IEC 27001	Anforderungen an ein Informationssicherheitsmanagementsystem
Projektmanagement	zeitlich begrenzte Vorhaben mit definierten Zielen

ITIL verlangt nicht, diese Ansätze zu ersetzen.

Sie können sich ergänzen, wenn:

Begriffe und Verantwortlichkeiten geklärt sind,
Ziele aufeinander abgestimmt werden,
doppelte oder widersprüchliche Regeln vermieden werden,
und die kombinierte Arbeitsweise einen erkennbaren Nutzen besitzt.

Praxisbeispiel: Eine neue Monitoring-Lösung

Eine Organisation möchte eine neue Monitoring-Lösung einführen.

Eine rein technische Betrachtung könnte sich konzentrieren auf:

Serveranforderungen,
Agenten,
Netzwerkzugriffe,
Dashboards,
Alarmregeln,
und Datenspeicherung.

Die ITIL-Perspektive ergänzt weitere Fragen.

Wert und Outcomes

Welches Problem soll das Monitoring lösen?
Welche Ausfälle sollen früher erkannt werden?
Wer verwendet die Informationen?
Welches Outcome wird erwartet?

Vier Dimensionen

Wer bearbeitet Alarme?
Welche Technologien und Daten werden benötigt?
Welche Lieferanten sind beteiligt?
Wie sieht der Ablauf vom Event bis zur Reaktion aus?

Lebenszyklus

Wie wird der Bedarf untersucht?
Wie wird die Lösung gestaltet?
Wird sie beschafft oder selbst aufgebaut?
Wie wird sie getestet und eingeführt?
Wie wird sie betrieben und unterstützt?

Practices

Monitoring and Event Management
Incident Management
Service Configuration Management
IT Asset Management
Information Security Management
Supplier Management
Continual Improvement

Verbesserung

Wie wird gemessen, ob relevante Störungen früher erkannt werden?
Werden unnötige Alarme reduziert?
Werden Erkenntnisse aus Incidents in neue Überwachungsregeln übernommen?

Dieses Beispiel zeigt, dass ITIL die technische Umsetzung nicht ersetzt.

Es erweitert die Betrachtung um Ziele, Stakeholder, Lebenszyklus, Zusammenarbeit, Risiken und Verbesserung.

Typische Missverständnisse

Missverständnis 1: ITIL schreibt jeden Prozess genau vor

ITIL stellt anpassbare Best-Practice-Guidance bereit.

Die konkrete Umsetzung wird von der Organisation gestaltet.

Missverständnis 2: ITIL ist nur für große Unternehmen geeignet

Auch kleine Organisationen können geeignete Grundsätze, Practices und einfache Arbeitsweisen verwenden.

Der Umfang muss zum tatsächlichen Bedarf passen.

Missverständnis 3: ITIL bedeutet viele Formulare und Genehmigungen

Unnötige Bürokratie widerspricht einer sinnvollen Anpassung des Frameworks.

Kontrollen sollen einen erkennbaren Zweck erfüllen.

Missverständnis 4: ITIL ersetzt technisches Fachwissen

ITIL unterstützt die Organisation technischer Arbeit.

Es erklärt nicht die konkrete Konfiguration jedes Produkts.

Missverständnis 5: ITIL betrifft nur den Service Desk

Produktentwicklung, Betrieb, Support, Informationssicherheit, Lieferantensteuerung, Governance und Führung können ebenfalls beteiligt sein.

Missverständnis 6: Ein ITIL-Begriff muss intern zwingend genauso heißen

Organisationen können eigene Bezeichnungen verwenden.

Wichtig ist, dass Bedeutung, Verantwortung und Arbeitsweise eindeutig sind.

Missverständnis 7: ITIL Version 5 macht alles aus ITIL 4 ungültig

ITIL Version 5 entwickelt viele bestehende Konzepte weiter.

ITIL-4-Wissen bleibt in zahlreichen Bereichen relevant, muss bei versionsabhängigen Aussagen jedoch richtig eingeordnet werden.

Wie ein Systemintegrator ITIL praktisch verwendet

Ein Fachinformatiker für Systemintegration muss nicht vor jeder Handlung das gesamte Framework analysieren.

Für den Arbeitsalltag können bereits folgende Fragen hilfreich sein:

Welcher Service oder welches Produkt ist betroffen?
Welches Outcome wird benötigt?
Welche Stakeholder sind beteiligt?
Welche der vier Dimensionen müssen berücksichtigt werden?
Welche technischen und organisatorischen Abhängigkeiten bestehen?
Welche Practice unterstützt die Aufgabe?
Welche Risiken und Vorgaben müssen beachtet werden?
Wie wird der Erfolg überprüft?
Was muss dokumentiert werden?
Was kann anschließend verbessert werden?

Checkliste zur Einordnung einer neuen Aufgabe

Schnellzusammenfassung

Begriff	Kurzbeschreibung
ITIL	anpassbares Best-Practice-Framework für digitales Produkt- und Service-Management
Framework	strukturierter Orientierungsrahmen, kein starrer Musterprozess
Wert	wahrgenommener Nutzen für Stakeholder
Value System	verbindet zentrale Bestandteile des Frameworks zur Wertschöpfung
Guiding Principles	allgemeine Empfehlungen für Entscheidungen und Handlungen
Governance	Richtung, Überwachung und Verantwortlichkeit
vier Dimensionen	ganzheitliche Betrachtung von Produkten und Services
Lifecycle	gemeinsame Lebenszyklusbetrachtung digitaler Produkte und Services
Practice	organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Value Stream	Abfolge von Schritten zur Ermöglichung von Wert
Continual Improvement	fortlaufende Verbesserung von Produkten, Services und Arbeitsweisen

Aufbau dieses Kapitels

Die folgenden Seiten vertiefen die einzelnen Bestandteile des Frameworks:

2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen

Übersicht des Frameworks

Bedürfnisse, Chancen und Erwartungen
↓
ITIL Value System
↓
Guiding Principles · Governance · Value Chain Activities · Management Practices · Continual Improvement
↓
gemeinsamer Product and Service Lifecycle
↓
digitale Produkte und Services
↓
Outcomes und gemeinsam ermöglichter Wert

Die Darstellung ist eine vereinfachte Orientierung.

Die Elemente wirken nicht ausschließlich in einer linearen Reihenfolge, sondern beeinflussen sich gegenseitig.

Verwandte Seiten

1.1 Warum professionelles Service Management notwendig ist
1.2 Technik, Produkt, Service und Geschäftsergebnis
1.3 Wert, Nutzen, Kosten und Risiken
1.4 Servicebeziehungen, Rollen und Serviceangebote
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.9 Continual Improvement

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert: ITIL Foundation – Version 5
ITIL: ITIL Foundation – Version 5
ITIL: ITIL Foundation Version 5 – What’s New?
ITIL: New ITIL Explained for Certified Professionals
ITIL: New ITIL Product and Service Lifecycle Model

Einordnung

Die Aussagen zum Aufbau von ITIL Version 5, zum ITIL Value System, zu den vier Dimensionen, den Guiding Principles, Management Practices, Continual Improvement und dem gemeinsamen Produkt- und Service-Lebenszyklus wurden anhand der genannten offiziellen Quellen geprüft.

Die Praxisbeispiele, Tabellen, Checklisten und vereinfachten Darstellungen sind zusätzliche Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.2 Das ITIL Value System

Kurz erklärt

Das ITIL Value System beschreibt, wie die verschiedenen Bestandteile und Aktivitäten einer Organisation als zusammenhängendes System wirken, um Wert zu ermöglichen.

Es verbindet:

Guiding Principles,

Governance,

Value Chain Activities,

Management Practices,

und Continual Improvement.

Ausgangspunkte sind Chancen, Anforderungen und Nachfrage. Das angestrebte Ergebnis ist gemeinsam ermöglichter Wert für Kunden, Benutzer, die Organisation und weitere Stakeholder.

Warum ein Value System notwendig ist

Digitale Produkte und Services entstehen nicht durch einen einzelnen Prozess oder ein einzelnes Team.

An ihrer Planung, Bereitstellung, Nutzung und Verbesserung können unter anderem beteiligt sein:

Unternehmensleitung,
Fachabteilungen,
Produktteams,
Entwicklung,
Systemadministration,
Netzwerkbetrieb,
Service Desk,
Informationssicherheit,
Einkauf,
externe Dienstleister,
Hersteller,
Kunden,
und Benutzer.

Jeder dieser Beteiligten kann eigene:

Ziele,
Aufgaben,
Informationen,
Werkzeuge,
Prioritäten,
Risiken,
und Verantwortlichkeiten

besitzen.

Werden diese Bereiche voneinander isoliert gesteuert, können lokale Verbesserungen entstehen, die dem gesamten Produkt oder Service schaden.

Beispiele:

Ein Team optimiert seine Bearbeitungszeit, erzeugt aber zusätzliche Übergaben für andere Teams.
Eine Sicherheitsmaßnahme wird technisch korrekt umgesetzt, verhindert jedoch die Nutzung einer wichtigen Fachanwendung.
Eine neue Anwendung wird bereitgestellt, ohne Monitoring, Support und Wiederherstellung ausreichend vorzubereiten.
Ein Ticketsystem wird automatisiert, obwohl die zugrunde liegende Arbeitsweise unklar ist.
Ein Service erfüllt technische Kennzahlen, ermöglicht aber nicht das erwartete Outcome.

Das Value System unterstützt deshalb eine ganzheitliche Betrachtung.

Merke

Professionelles Produkt- und Service-Management entsteht nicht durch einzelne optimierte Bestandteile.

Entscheidend ist, wie alle Bestandteile zusammenwirken.

Vom Bedarf zum Wert

Das ITIL Value System kann vereinfacht folgendermaßen dargestellt werden:

Chance oder Nachfrage
↓
ITIL Value System
↓
digitale Produkte und Services
↓
Outcomes, Erfahrungen und gemeinsam ermöglichter Wert

Nachfrage kann beispielsweise entstehen durch:

einen neuen Mitarbeiter,
einen gemeldeten Incident,
eine benötigte Berechtigung,
eine gesetzliche Anforderung,
einen höheren Kapazitätsbedarf,
eine neue Geschäftsanwendung,
oder einen vereinbarten Service Request.

Eine Chance kann beispielsweise entstehen durch:

Automatisierung,
neue Technologie,
verbesserte Monitoring-Daten,
Rückmeldungen von Benutzern,
Erkenntnisse aus einem Incident,
eine neue Lieferantenleistung,
oder eine mögliche Vereinfachung eines Arbeitsablaufs.

Das Value System soll dabei helfen, Nachfrage und Chancen nicht isoliert zu bearbeiten, sondern kontrolliert in wertschöpfende Ergebnisse zu überführen.

Wichtig

Nicht jede Nachfrage muss unverändert erfüllt werden.

Nicht jede technische Möglichkeit besitzt automatisch einen ausreichenden Nutzen.

Anforderungen und Chancen müssen hinsichtlich Outcomes, Wert, Kosten, Risiken, Erfahrung und Nachhaltigkeit bewertet werden.

Die fünf Bestandteile des ITIL Value Systems

Bestandteil	Zentrale Aufgabe
Guiding Principles	unterstützen Entscheidungen und Handlungen in unterschiedlichen Situationen
Governance	gibt Richtung, überwacht die Organisation und stellt Verantwortlichkeit sicher
Value Chain Activities	bilden ein flexibles Betriebsmodell für wertschöpfende Arbeit
Management Practices	stellen benötigte organisatorische Ressourcen und Fähigkeiten bereit
Continual Improvement	verbessert Produkte, Services, Practices und Arbeitsweisen fortlaufend

Diese Bestandteile sind keine voneinander getrennten Ebenen.

Sie wirken gleichzeitig und beeinflussen sich gegenseitig.

Das Value System ist kein einzelner Prozess

Ein Prozess beschreibt normalerweise eine strukturierte Abfolge von Aktivitäten, durch die bestimmte Eingaben in Ergebnisse überführt werden.

Das Value System ist umfassender.

Es verbindet:

Entscheidungsgrundsätze,
Steuerung,
operative Aktivitäten,
organisatorische Fähigkeiten,
Rollen,
Informationen,
Technologien,
Partner,
Wertströme,
und Verbesserung.

Typischer Fehler

Das ITIL Value System wird als festes Ablaufdiagramm verstanden, das bei jedem Vorgang Schritt für Schritt durchlaufen werden muss.

Tatsächlich ist es ein übergeordneter Orientierungsrahmen, innerhalb dessen unterschiedliche Wertströme und Arbeitsabläufe gestaltet werden.

Ein Incident wird beispielsweise anders bearbeitet als:

die Einführung einer neuen Anwendung,
die Bereitstellung eines Arbeitsplatzes,
eine Sicherheitsverbesserung,
oder die Ablösung eines veralteten Servers.

Alle diese Situationen können jedoch innerhalb desselben Value Systems gesteuert werden.

Guiding Principles

Die Guiding Principles sind allgemeine Empfehlungen für Entscheidungen und Handlungen.

Sie gelten unabhängig davon:

welche Rolle eine Person besitzt,
welches Produkt betroffen ist,
welche Practice verwendet wird,
welche Technologie eingesetzt wird,
oder wie groß die Organisation ist.

Die sieben Guiding Principles sind:

Focus on value
Start where you are
Progress iteratively with feedback
Collaborate and promote visibility
Think and work holistically
Keep it simple and practical
Optimize and automate

Praxisnahe Bedeutung:

Guiding Principle	Leitfrage
Focus on value	Welchen Nutzen und welches Outcome soll die Tätigkeit ermöglichen?
Start where you are	Was funktioniert bereits und welche Informationen sind vorhanden?
Progress iteratively with feedback	Kann die Verbesserung in kontrollierten Schritten erfolgen?
Collaborate and promote visibility	Wer muss beteiligt werden und welche Informationen müssen sichtbar sein?
Think and work holistically	Welche Produkte, Services, Menschen und Abhängigkeiten sind betroffen?
Keep it simple and practical	Welche Schritte sind wirklich notwendig?
Optimize and automate	Was sollte zuerst verbessert und anschließend sinnvoll automatisiert werden?

Die Guiding Principles ersetzen keine technische Analyse und keine betriebliche Vorgabe.

Sie helfen dabei, Entscheidungen aus mehreren Perspektiven zu prüfen.

Praxisbeispiel

Ein Administrator möchte die Anlage neuer Benutzerkonten automatisieren.

Die Guiding Principles führen unter anderem zu folgenden Fragen:

Welches Outcome soll verbessert werden?

Welche funktionierenden Abläufe existieren bereits?

Kann zunächst ein kleiner Teil automatisiert werden?

Sind Personalabteilung, Führungskräfte und Informationssicherheit eingebunden?

Welche Abhängigkeiten bestehen zu Lizenzen, Gruppen und Endgeräten?

Welche unnötigen Schritte können entfernt werden?

Wie werden Fehler, Ausnahmen und Ergebnisse kontrolliert?

Die Guiding Principles werden auf der Seite 2.3 Die sieben Guiding Principles ausführlich behandelt.

Governance

Governance stellt sicher, dass die Organisation angemessen geführt und kontrolliert wird.

Dazu gehören insbesondere:

Ziele und Richtung festlegen,
Bedürfnisse und Erwartungen bewerten,
Verantwortlichkeiten bestimmen,
Entscheidungen kontrollieren,
Risiken überwachen,
Leistung bewerten,
und die Einhaltung verbindlicher Vorgaben sicherstellen.

Governance wird häufig mit drei grundlegenden Tätigkeiten beschrieben:

Tätigkeit	Bedeutung
Evaluate	Situation, Bedürfnisse, Optionen, Leistung und Risiken bewerten
Direct	Richtung, Prioritäten und Rahmenbedingungen vorgeben
Monitor	Ergebnisse, Leistung, Risiken und Einhaltung überwachen

Beispiel:

Eine Organisation beschließt, dass administrative Zugriffe durch Multi-Faktor-Authentifizierung geschützt werden müssen.

Governance bestimmt unter anderem:

das Sicherheitsziel,
verbindliche Rahmenbedingungen,
Verantwortlichkeiten,
akzeptierbare Risiken,
und die erforderliche Überwachung.

Das Management organisiert anschließend:

Produktauswahl,
technische Einführung,
Tests,
Kommunikation,
Support,
Dokumentation,
und laufenden Betrieb.

Merke

Governance gibt Richtung und Rahmenbedingungen vor.

Management plant, koordiniert und kontrolliert die praktische Umsetzung innerhalb dieses Rahmens.

Governance ist nicht nur Aufgabe einer einzelnen Führungskraft.

Je nach Organisation können verschiedene Gremien und Rollen beteiligt sein, beispielsweise:

Geschäftsführung,
IT-Leitung,
Informationssicherheit,
Datenschutz,
Architekturboard,
Risikomanagement,
Service Owner,
Product Owner,
und Change-Verantwortliche.

Value Chain Activities

Die Value Chain Activities bilden das operative Kernmodell des Value Systems.

Sie beschreiben miteinander verbundene Tätigkeitsbereiche, die abhängig von der jeweiligen Situation zu Wertströmen kombiniert werden.

Ein Wertstrom kann beispielsweise zeigen, wie eine Organisation:

einen Incident bearbeitet,
einen neuen Benutzer bereitstellt,
eine Anwendung einführt,
einen Change umsetzt,
einen Service verbessert,
oder einen veralteten Server ablöst.

Die Value Chain Activities sind dabei keine starren Abteilungen.

Eine einzelne Aktivität kann Beiträge mehrerer Teams und Practices enthalten.

Beispiel:

Bei der Bereitstellung eines neuen Arbeitsplatzes können beteiligt sein:

Personalabteilung,
Führungskraft,
Service Desk,
Einkauf,
Identitätsmanagement,
Endgeräteverwaltung,
Informationssicherheit,
Netzwerkbetrieb,
und externe Lieferanten.

Wichtig

Ein Wertstrom wird durch das benötigte Outcome bestimmt.

Er sollte nicht ausschließlich entlang bestehender Abteilungsgrenzen aufgebaut werden.

ITIL Version 5 verwendet eine gegenüber ITIL 4 vereinfachte und praxisnähere Darstellung der Value Chain. Sie bleibt Bestandteil des ITIL Value Systems und ist vom neuen Product and Service Lifecycle zu unterscheiden.

Management Practices

Management Practices stellen organisatorische Ressourcen und Fähigkeiten bereit, die zur Durchführung bestimmter Aufgaben oder zur Erreichung bestimmter Ziele benötigt werden.

Eine Practice besteht nicht nur aus einem Ablaufdiagramm.

Sie kann umfassen:

Rollen und Verantwortlichkeiten,
Fähigkeiten und Kompetenzen,
Informationen und Wissen,
Prozesse und Arbeitsabläufe,
Technologien und Werkzeuge,
Partner und Lieferanten,
Regeln und Kontrollen,
Messgrößen,
sowie Verbesserungsmaßnahmen.

Beispiele:

Practice	Typischer Beitrag
Incident Management	negative Auswirkungen von Incidents verringern und Servicebetrieb wiederherstellen
Service Request Management	vereinbarte Benutzeranfragen wirksam bearbeiten
Problem Management	Ursachen und Wahrscheinlichkeiten von Incidents reduzieren
Change Management	Änderungen bewerten und kontrolliert ermöglichen
Knowledge Management	benötigtes Wissen verfügbar und nutzbar machen
Service Configuration Management	verlässliche Informationen über Services und Configuration Items bereitstellen
IT Asset Management	IT-Assets über ihren Lebenszyklus verwalten
Monitoring and Event Management	relevante Zustandsänderungen erkennen und bewerten
Information Security Management	Sicherheitsanforderungen und Risiken angemessen behandeln
Supplier Management	Lieferanten und deren Leistungen steuern
Continual Improvement	Verbesserungen identifizieren, priorisieren und umsetzen

Mehrere Practices können gemeinsam einen Wertstrom unterstützen.

Beispiel: Ein wiederkehrender Ausfall

Monitoring and Event Management erkennt eine Abweichung.
Incident Management koordiniert die Wiederherstellung.
Problem Management untersucht die zugrunde liegende Ursache.
Change Management unterstützt die kontrollierte dauerhafte Korrektur.
Knowledge Management stellt die Lösung bereit.
Service Configuration Management aktualisiert relevante Beziehungsinformationen.
Continual Improvement bewertet weitere Verbesserungsmöglichkeiten.

Typischer Fehler

Eine Practice wird mit einem einzelnen Team gleichgesetzt.

In der Praxis können mehrere Teams zu einer Practice beitragen und ein Team kann an mehreren Practices beteiligt sein.

Continual Improvement

Continual Improvement ist im gesamten Value System verankert.

Verbessert werden können unter anderem:

Produkte,
Services,
technische Komponenten,
Practices,
Wertströme,
Prozesse,
Dokumentationen,
Werkzeuge,
Benutzererfahrungen,
Zusammenarbeit,
und Fähigkeiten von Mitarbeitern.

Verbesserung ist nicht nur nach einem Fehler notwendig.

Sie kann entstehen durch:

neue Chancen,
Feedback,
Kennzahlen,
technische Schulden,
geänderte Anforderungen,
neue Risiken,
neue Technologien,
oder Erkenntnisse aus dem laufenden Betrieb.

Praxisbeispiel

Ein Zertifikat läuft unerwartet ab und verursacht einen Serviceausfall.

Die unmittelbare Wiederherstellung behebt den Incident.

Continual Improvement fragt zusätzlich:

Warum wurde das Ablaufdatum nicht rechtzeitig erkannt?

Welche Zertifikate existieren noch?

Wer ist verantwortlich?

Kann eine zentrale Erfassung eingerichtet werden?

Kann eine automatische Warnung erzeugt werden?

Wie wird die Wirksamkeit der neuen Überwachung geprüft?

Continual Improvement unterstützt jede Value Chain Activity und alle anderen Bestandteile des Value Systems.

Es wird auf der Seite 2.9 Continual Improvement ausführlich behandelt.

Wie die Bestandteile zusammenwirken

Die Bestandteile des Value Systems dürfen nicht isoliert betrachtet werden.

Beispiel: Einführung einer neuen Backup-Lösung

Guiding Principles

Welcher Wert soll entstehen?
Welche bestehende Lösung kann weiterverwendet werden?
Kann die Einführung schrittweise erfolgen?
Wer muss beteiligt werden?
Wie wird die gesamte Wiederherstellungskette betrachtet?
Welche Komplexität ist tatsächlich notwendig?
Welche Schritte können optimiert und automatisiert werden?

Governance

Welche gesetzlichen und betrieblichen Anforderungen gelten?
Welche Daten müssen geschützt werden?
Welche Risiken sind akzeptabel?
Wer ist verantwortlich?
Wie wird die Einhaltung überwacht?

Value Chain Activities

Wie wird aus dem Bedarf eine eingeführte und nutzbare Lösung?
Welche Aktivitäten, Übergaben und Entscheidungen sind notwendig?
Wie fließen Anforderungen, Tests und Rückmeldungen durch den Wertstrom?

Management Practices

Möglicherweise beteiligt:

Information Security Management,
Architecture Management,
Supplier Management,
IT Asset Management,
Service Configuration Management,
Change Management,
Deployment Management,
Monitoring and Event Management,
Incident Management,
und Continual Improvement.

Continual Improvement

Werden Wiederherstellungen regelmäßig getestet?
Werden Fehlversuche analysiert?
Sind Sicherungszeiten und Wiederherstellungsziele angemessen?
Werden neue Systeme vollständig in die Sicherung aufgenommen?
Werden Erkenntnisse aus Tests umgesetzt?

Angestrebter Wert

Daten können nach Verlust oder Ausfall innerhalb der vereinbarten Ziele wiederhergestellt werden.
Risiken und Betriebsunterbrechungen werden begrenzt.
Verantwortlichkeiten und Nachweise sind nachvollziehbar.

Value System, Lifecycle, Value Stream und Practice unterscheiden

Diese Begriffe beschreiben unterschiedliche Betrachtungsebenen.

Begriff	Bedeutung
ITIL Value System	übergeordneter Rahmen, der die Bestandteile der Organisation zur Wertschöpfung verbindet
Product and Service Lifecycle	beschreibt die gemeinsamen Lebenszyklusaktivitäten digitaler Produkte und Services
Value Chain	flexibles operatives Modell innerhalb des Value Systems
Value Stream	konkrete Abfolge von Schritten für ein bestimmtes Outcome
Management Practice	Ressourcen und Fähigkeiten für einen bestimmten Zweck
Prozess	strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen
Arbeitsanweisung	konkrete Beschreibung, wie eine bestimmte Tätigkeit ausgeführt wird

Beispiel:

Ziel: Ein neuer Mitarbeiter soll am ersten Arbeitstag arbeitsfähig sein.

Betrachtung	Beispiel
Value System	verbindet Steuerung, Prinzipien, Practices und Verbesserung
Lifecycle	berücksichtigt Gestaltung, Aufbau, Betrieb, Bereitstellung und Unterstützung der verwendeten Produkte und Services
Value Stream	führt von der Eintrittsmeldung bis zum geprüften Arbeitsplatz
Practices	unter anderem Service Request Management, IT Asset Management und Information Security Management
Prozess	Ablauf zur Anlage eines Benutzerkontos
Arbeitsanweisung	konkrete Schritte zur Kontoanlage im verwendeten Verzeichnisdienst

Merke

Das Value System beschreibt das große Ganze.

Der Value Stream beschreibt den Weg zu einem konkreten Outcome.

Eine Practice stellt Fähigkeiten bereit.

Eine Arbeitsanweisung beschreibt die konkrete Durchführung.

Praxisbeispiel: Ein neuer Mitarbeiter beginnt

Die Personalabteilung meldet einen neuen Mitarbeiter.

Nachfrage

Der Mitarbeiter benötigt zum Eintrittsdatum einen arbeitsfähigen IT-Arbeitsplatz.

Angestrebtes Outcome

Der Mitarbeiter kann sich anmelden und alle für seine Tätigkeit freigegebenen Services verwenden.

Guiding Principles

Fokus auf das tatsächlich benötigte Outcome
bestehende Onboarding-Abläufe berücksichtigen
schrittweise verbessern
Personalabteilung, Führungskraft und IT einbinden
vollständigen Ablauf betrachten
unnötige Sonderwege vermeiden
standardisierbare Tätigkeiten automatisieren

Governance

Wer darf Zugriffe genehmigen?
Welche Sicherheitsrichtlinien gelten?
Welche Funktionstrennung ist notwendig?
Welche Daten dürfen verarbeitet werden?
Wer kontrolliert die ordnungsgemäße Bereitstellung?

Value Stream

Eintritt wird gemeldet.
Aufgaben und benötigte Zugriffe werden bestimmt.
Genehmigungen werden eingeholt.
Benutzerkonto und Lizenzen werden bereitgestellt.
Endgerät wird vorbereitet.
Sicherheitsmaßnahmen werden eingerichtet.
Zugriffe werden getestet.
Gerät und Informationen werden übergeben.
Arbeitsfähigkeit wird bestätigt.
Asset- und Konfigurationsdaten werden aktualisiert.

Beteiligte Practices

Service Request Management
IT Asset Management
Service Configuration Management
Information Security Management
Knowledge Management
Supplier Management
Change Management
Continual Improvement

Verbesserung

Nach jedem Onboarding kann geprüft werden:

Wurden alle Informationen rechtzeitig übermittelt?
Gab es unnötige Wartezeiten?
Fehlten Berechtigungen?
Waren Zuständigkeiten unklar?
Welche Schritte lassen sich vereinfachen oder automatisieren?

Bedeutung für Fachinformatiker für Systemintegration

Ein Fachinformatiker arbeitet häufig innerhalb mehrerer Bestandteile des Value Systems.

Beispiele:

Tätigkeit	Bezug zum Value System
Incident analysieren	Value Stream und Incident Management
Firewall-Regel ändern	Governance, Change Management und Information Security Management
Server dokumentieren	Knowledge Management und Service Configuration Management
Monitoring-Alarm bearbeiten	Monitoring and Event Management sowie Incident Management
neuen Arbeitsplatz bereitstellen	Service Request Management, IT Asset Management und Value Stream
Backup testen	Governance, Risikobehandlung und Continual Improvement
wiederkehrenden Fehler automatisieren	Guiding Principles, Problem Management und Continual Improvement

Der einzelne Mitarbeiter steuert normalerweise nicht das gesamte Value System.

Er trägt jedoch durch seine:

Entscheidungen,
technischen Maßnahmen,
Dokumentationen,
Rückmeldungen,
Eskalationen,
und Verbesserungsvorschläge

zu dessen Wirksamkeit bei.

Wie du das Value System im Alltag verwendest

Bei einer neuen Aufgabe kannst du folgende Fragen stellen:

Welche Nachfrage oder Chance liegt vor?
Welches Outcome und welcher Wert werden erwartet?
Welche Stakeholder sind beteiligt?
Welche Guiding Principles helfen bei der Entscheidung?
Welche Governance-Vorgaben gelten?
Welcher Wertstrom wird durchlaufen?
Welche Practices und Fähigkeiten werden benötigt?
Welche Informationen und Technologien werden benötigt?
Welche Risiken und Abhängigkeiten bestehen?
Wie wird das Ergebnis überprüft?
Was kann anschließend verbessert werden?

Diese Fragen müssen nicht in jedem kleinen Vorgang schriftlich beantwortet werden.

Sie unterstützen jedoch eine strukturierte und ganzheitliche Denkweise.

Anzeichen für ein schlecht abgestimmtes Value System

Mögliche Warnzeichen sind:

Teams optimieren ausschließlich ihre eigenen Kennzahlen.
Verantwortlichkeiten für Services sind unklar.
Entscheidungen widersprechen sich.
Governance-Vorgaben sind unbekannt oder werden nicht kontrolliert.
Practices arbeiten voneinander isoliert.
Informationen gehen an Übergaben verloren.
Änderungen verursachen regelmäßig unerwartete Störungen.
Benutzererfahrungen werden nicht berücksichtigt.
Verbesserungen werden nicht priorisiert oder nachverfolgt.
Werkzeuge bestimmen die Arbeitsweise statt der benötigten Outcomes.
Lieferanten werden nicht ausreichend in Wertströme eingebunden.
Ergebnisse werden nur anhand technischer Outputs bewertet.

Ein einzelnes Warnzeichen beweist noch kein grundsätzlich unwirksames Value System.

Wiederholen sich mehrere dieser Muster, sollten Zusammenhänge und Schnittstellen untersucht werden.

Typische Fehler

Fehler 1: Nur einzelne Practices einführen

Eine Organisation führt Incident Management ein, ohne:

Governance,
Wissensmanagement,
Konfigurationsinformationen,
Kommunikation,
oder Verbesserung

ausreichend einzubeziehen.

Das Ergebnis kann ein Ticketsystem mit vielen erfassten Incidents sein, ohne dass wiederkehrende Ursachen reduziert werden.

Fehler 2: Governance mit Bürokratie verwechseln

Governance soll Richtung, Verantwortlichkeit und Kontrolle sicherstellen.

Sie bedeutet nicht automatisch:

viele Genehmigungsstufen,
lange Entscheidungswege,
oder unnötige Dokumente.

Kontrollen müssen zum Risiko und zum Kontext passen.

Fehler 3: Value Streams entlang von Abteilungen gestalten

Ein Wertstrom sollte dem Weg zum Outcome folgen.

Er sollte nicht künstlich an jeder Teamgrenze enden.

Fehler 4: Automatisieren, bevor der Ablauf verstanden wurde

Ein fehlerhafter oder unnötig komplexer Ablauf wird durch Automatisierung häufig nur schneller wiederholt.

Zuerst verstehen und optimieren, danach automatisieren.

Fehler 5: Verbesserung als einmaliges Projekt behandeln

Continual Improvement ist keine einmalige Aufräumaktion.

Es muss in die tägliche Arbeit und in alle Bestandteile des Value Systems integriert werden.

Fehler 6: Technische Outputs mit Wert gleichsetzen

Ein Server, Benutzerkonto oder Dashboard ist zunächst ein Output.

Wert entsteht erst, wenn Stakeholder damit benötigte Outcomes erreichen.

Checkliste zur Bewertung eines Value Systems

Schnellzusammenfassung

Bestandteil	Kernfrage
Guiding Principles	Wie sollten wir denken und entscheiden?
Governance	Wer gibt Richtung vor und überwacht die Ergebnisse?
Value Chain Activities	Welche operativen Tätigkeiten werden miteinander verbunden?
Management Practices	Welche Fähigkeiten und Ressourcen werden benötigt?
Continual Improvement	Wie werden Produkte, Services und Arbeitsweisen fortlaufend verbessert?

Gesamtfrage des Value Systems

Wie müssen alle Bestandteile der Organisation zusammenwirken, damit aus Chancen und Nachfrage nachhaltiger Wert entstehen kann?

Vereinfachte Darstellung

Chancen und Nachfrage
↓
Guiding Principles
Governance
Value Chain Activities
Management Practices
Continual Improvement
↓
digitale Produkte und Services
↓
Outcomes, Erfahrungen und gemeinsam ermöglichter Wert

Die Bestandteile wirken nicht ausschließlich nacheinander.

Sie bilden ein zusammenhängendes System mit Rückmeldungen, Abhängigkeiten und fortlaufenden Verbesserungen.

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zu den fünf Bestandteilen des ITIL Value Systems, zur Überführung von Chancen und Nachfrage in Wert sowie zur fortlaufenden Bedeutung von Continual Improvement wurden anhand der genannten offiziellen ITIL- und PeopleCert-Quellen geprüft.

Die konkreten Praxisbeispiele, Checklisten, Tabellen und vereinfachten Darstellungen sind zusätzliche Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

Die öffentlich zugänglichen offiziellen Übersichtsseiten bestätigen für ITIL Version 5 eine vereinfachte Value Chain, veröffentlichen dort jedoch nicht alle Detaildarstellungen und Workflowdiagramme der offiziellen Foundation-Publikation. Deshalb werden an dieser Stelle keine nicht eindeutig öffentlich belegten Bezeichnungen einzelner neuer Value Chain Activities ergänzt.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.3 Die sieben Guiding Principles

Kurz erklärt

Die sieben Guiding Principles sind allgemeine Empfehlungen, die Entscheidungen und Handlungen im digitalen Produkt- und Service-Management unterstützen.

Sie können unabhängig davon angewendet werden:

welche Rolle eine Person besitzt,

welches Produkt oder welcher Service betroffen ist,

welche Management Practice verwendet wird,

welche Technologie eingesetzt wird,

und wie groß oder komplex die Organisation ist.

Die Guiding Principles geben keine festen Arbeitsschritte vor. Sie helfen dabei, Situationen aus mehreren Perspektiven zu beurteilen und angemessene Entscheidungen zu treffen.

Die sieben Guiding Principles im Überblick

Nr.	Guiding Principle	Praktische Bedeutung
1	Focus on value	Arbeit am tatsächlich benötigten Wert und Outcome ausrichten
2	Start where you are	vorhandene Fähigkeiten, Informationen und funktionierende Bestandteile berücksichtigen
3	Progress iteratively with feedback	in überschaubaren Schritten vorgehen und Rückmeldungen auswerten
4	Collaborate and promote visibility	geeignete Beteiligte einbeziehen und relevante Informationen sichtbar machen
5	Think and work holistically	Produkte, Services, Menschen, Technologien und Abhängigkeiten gemeinsam betrachten
6	Keep it simple and practical	nur Schritte und Kontrollen verwenden, die einen erkennbaren Nutzen besitzen
7	Optimize and automate	Arbeitsweisen zuerst verstehen und verbessern, anschließend sinnvoll automatisieren

Die englischen Bezeichnungen werden beibehalten, da sie in offiziellen ITIL-Unterlagen und in der internationalen Praxis verwendet werden.

Die deutschen Erläuterungen in diesem Buch sind sinngemäße Erklärungen und keine wörtlichen offiziellen Übersetzungen.

Fortführung in ITIL Version 5

ITIL Version 5 führt die Guiding Principles als Kernelement des ITIL Value Systems fort.

Sie stammen bereits aus ITIL 4 und bleiben relevant, weil sie keine produktspezifischen oder kurzlebigen technischen Anweisungen darstellen.

Die Prinzipien unterstützen vielmehr eine grundlegende Denkweise für:

Produktentwicklung,
Servicebereitstellung,
Betrieb,
Support,
Governance,
Zusammenarbeit,
Veränderung,
und kontinuierliche Verbesserung.

ITIL Version 5 ergänzt den Anwendungskontext insbesondere um:

das integrierte Management digitaler Produkte und Services,
komplexe und schnell veränderliche Umgebungen,
den Einsatz von künstlicher Intelligenz,
digitale Erfahrung,
Nachhaltigkeit,
und den gemeinsamen Product and Service Lifecycle.

Merke

Die Guiding Principles geben Orientierung, wenn ein detaillierter Ablauf allein nicht ausreicht oder eine Situation mehrere mögliche Vorgehensweisen zulässt.

Die Guiding Principles sind keine Prozessschritte

Die sieben Prinzipien bilden keine Reihenfolge, die von Nummer 1 bis Nummer 7 abgearbeitet werden muss.

Sie können:

gleichzeitig angewendet werden,
sich gegenseitig ergänzen,
je nach Situation unterschiedlich stark gewichtet werden,
und bei jeder Management Practice berücksichtigt werden.

Beispiel:

Eine Organisation möchte die Bereitstellung neuer Benutzerkonten automatisieren.

Dabei können gleichzeitig folgende Prinzipien relevant sein:

Focus on value: Der Mitarbeiter soll am ersten Arbeitstag arbeitsfähig sein.
Start where you are: Der bestehende Ablauf und vorhandene Datenquellen werden geprüft.
Progress iteratively with feedback: Zunächst wird nur ein klar abgegrenzter Teil automatisiert.
Collaborate and promote visibility: Personalabteilung, Führungskräfte, IT und Informationssicherheit werden einbezogen.
Think and work holistically: Konto, Endgerät, Lizenzen, Berechtigungen und Support werden gemeinsam betrachtet.
Keep it simple and practical: Unnötige Sonderwege und doppelte Dateneingaben werden entfernt.
Optimize and automate: Erst nach der Verbesserung wird der geeignete Ablauf automatisiert.

Typischer Fehler

Nur das Prinzip auszuwählen, das die bereits bevorzugte Entscheidung unterstützt.

Eine gute Entscheidung berücksichtigt alle relevanten Guiding Principles und mögliche Zielkonflikte.

1. Focus on value

Sinngemäße Bedeutung

Jede Tätigkeit sollte einen nachvollziehbaren Beitrag zum Wert für relevante Stakeholder leisten.

Wert entsteht nicht allein dadurch, dass eine technische Aufgabe abgeschlossen wurde.

Entscheidend ist, ob das benötigte Outcome erreicht und von den beteiligten Stakeholdern als nützlich wahrgenommen wird.

Mögliche Stakeholder sind beispielsweise:

Benutzer,
Kunden,
Fachabteilungen,
Produktverantwortliche,
Service Provider,
Lieferanten,
Unternehmensleitung,
Informationssicherheit,
und Mitarbeiter des IT-Betriebs.

Wert kann sich unter anderem zeigen durch:

zuverlässig nutzbare Services,
geringere Risiken,
kürzere Bearbeitungszeiten,
bessere Benutzererfahrung,
geringere Kosten,
bessere Zusammenarbeit,
höhere Sicherheit,
schnellere Wiederherstellung,
oder die Erfüllung gesetzlicher und vertraglicher Anforderungen.

Leitfragen zu Focus on value

Welches Outcome soll erreicht werden?
Wer nimmt den Wert wahr?
Welches Problem wird tatsächlich gelöst?
Welcher Geschäftsprozess oder Benutzerbedarf wird unterstützt?
Wie wird festgestellt, ob das gewünschte Ergebnis erreicht wurde?
Welche Kosten und Risiken sind mit der Lösung verbunden?
Verbessert die Maßnahme auch die Erfahrung der betroffenen Benutzer?
Entsteht nur ein technischer Output oder ein tatsächlich nutzbares Ergebnis?

Praxisbeispiel: Backup

Ein Backup-System meldet jeden Tag einen erfolgreichen Sicherungslauf.

Der technische Output lautet:

Die Sicherungsdaten wurden erzeugt.

Der angestrebte Wert besteht jedoch darin, dass:

wichtige Daten geschützt sind,
Wiederherstellungen innerhalb der benötigten Zeit möglich sind,
Datenverluste begrenzt werden,
und die Organisation nach einem Ausfall weiterarbeiten kann.

Um den tatsächlichen Wert zu beurteilen, müssen deshalb zusätzlich geprüft werden:

Sind alle notwendigen Systeme erfasst?
Sind die Sicherungsdaten verwendbar?
Wurden Wiederherstellungen getestet?
Werden die benötigten Wiederherstellungszeiten erreicht?
Sind Verantwortlichkeiten eindeutig?
Sind die Sicherungen gegen unbefugte Veränderung geschützt?

Merke

Ein erfolgreich ausgeführter Sicherungslauf ist ein Output.

Wiederherstellbare und ausreichend geschützte Daten ermöglichen das benötigte Outcome.

Typische Fehler bei Focus on value

ausschließlich technische Kennzahlen betrachten
nur auf möglichst niedrige Kosten achten
den Wert nur aus Sicht eines einzelnen Stakeholders bewerten
Aktivitäten mit Ergebnissen verwechseln
eine neue Funktion bereitstellen, ohne ihren Nutzen zu prüfen
Benutzererfahrung und Risiken nicht berücksichtigen
eine Maßnahme fortführen, obwohl ihr ursprünglicher Zweck nicht mehr besteht

Bedeutung für Systemintegratoren

Vor einer technischen Maßnahme sollte nicht nur gefragt werden:

Wie führe ich diese Aufgabe aus?

Zusätzlich sollte gefragt werden:

Warum wird diese Aufgabe durchgeführt und welches Ergebnis soll sie ermöglichen?

Beispiele:

Technische Aufgabe	Wertorientierte Frage
Server neu starten	Welcher Service soll dadurch wiederhergestellt werden?
neue Firewall-Regel einrichten	Welcher notwendige Zugriff wird ermöglicht und welches Risiko entsteht?
Monitoring-Alarm anlegen	Welche relevante Störung soll dadurch früher erkannt werden?
Benutzerkonto erstellen	Welche Arbeitsfähigkeit muss zum vorgesehenen Zeitpunkt bestehen?
Anwendung aktualisieren	Welcher Nutzen entsteht und welche Risiken werden reduziert?

2. Start where you are

Sinngemäße Bedeutung

Bevor etwas vollständig neu aufgebaut wird, sollen der aktuelle Zustand, vorhandene Fähigkeiten und bereits funktionierende Bestandteile untersucht werden.

Ein bestehender Zustand ist selten vollständig schlecht oder vollständig gut.

Auch in einer unzureichenden Arbeitsweise können bereits wertvolle Bestandteile vorhanden sein, beispielsweise:

erfahrene Mitarbeiter,
funktionierende technische Werkzeuge,
brauchbare Dokumentationen,
etablierte Kommunikationswege,
vorhandene Messdaten,
automatisierte Teilabläufe,
oder bewährte Notfallverfahren.

Diese Bestandteile sollten erkannt und sinnvoll weiterverwendet werden.

Wichtig

Start where you are bedeutet nicht, dass der vorhandene Zustand unverändert bleiben muss.

Es bedeutet, dass Entscheidungen auf einer realistischen Bewertung des aktuellen Zustands beruhen sollen.

Leitfragen zu Start where you are

Wie sieht der aktuelle Zustand tatsächlich aus?
Was funktioniert bereits?
Welche Probleme bestehen konkret?
Welche Daten und Messwerte liegen vor?
Welche Dokumentationen sind vorhanden?
Welche Fähigkeiten besitzen die beteiligten Mitarbeiter?
Welche Werkzeuge können weiterverwendet werden?
Welche Annahmen müssen überprüft werden?
Was kann übernommen, verbessert oder entfernt werden?
Welche Abhängigkeiten sind möglicherweise noch unbekannt?

Praxisbeispiel: neues Ticketsystem

Eine Organisation möchte ein neues Ticketsystem einführen.

Eine ungeprüfte Vorgehensweise wäre:

neues Produkt auswählen
bestehende Daten vollständig verwerfen
neue Kategorien entwerfen
alle Abläufe gleichzeitig umstellen

Die Anwendung von Start where you are führt zunächst zu einer Bestandsaufnahme:

Welche Vorgangsarten werden tatsächlich verwendet?
Welche Kategorien liefern brauchbare Informationen?
Welche Automatisierungen funktionieren bereits?
Welche Daten müssen übernommen werden?
Welche Probleme entstehen durch das Werkzeug?
Welche Probleme entstehen unabhängig vom Werkzeug?
Welche Berichte werden benötigt?
Welche Mitarbeiter kennen die tatsächlichen Abläufe?
Welche bestehenden Integrationen müssen erhalten bleiben?

Dadurch wird verhindert, dass funktionierende Bestandteile unnötig ersetzt oder bekannte Fehler in das neue System übernommen werden.

Beobachten statt nur vermuten

Eine Bestandsaufnahme sollte nach Möglichkeit auf überprüfbaren Informationen beruhen.

Geeignete Informationsquellen können sein:

technische Messwerte,
Tickets,
Monitoring-Daten,
Protokolle,
Konfigurationsinformationen,
Gespräche mit Beteiligten,
Benutzerfeedback,
Prozessbeobachtungen,
Berichte,
und dokumentierte Testergebnisse.

Typischer Fehler

Eine Arbeitsweise wird allein anhand ihrer Dokumentation bewertet.

Der tatsächlich gelebte Ablauf kann deutlich von der beschriebenen Vorgehensweise abweichen.

Bedeutung für Systemintegratoren

Bei einer Störung sollte nicht sofort davon ausgegangen werden, dass:

die zuletzt vermutete Ursache zutrifft,
ein bestimmtes System vollständig neu installiert werden muss,
oder eine neue Technologie automatisch die beste Lösung ist.

Zuerst sollte geprüft werden:

Was funktioniert noch?
Welche Komponente zeigt tatsächlich eine Abweichung?
Was wurde zuletzt verändert?
Welche Informationen sind bereits vorhanden?
Gibt es bekannte Fehler oder frühere Incidents?
Welche funktionierenden Teile müssen geschützt werden?

3. Progress iteratively with feedback

Sinngemäße Bedeutung

Große Vorhaben sollen nach Möglichkeit in überschaubare Schritte unterteilt werden. Nach jedem geeigneten Schritt werden Ergebnisse und Rückmeldungen ausgewertet.

Kleine, kontrollierbare Schritte können dazu beitragen:

Risiken früher zu erkennen,
Fehlentwicklungen zu begrenzen,
schneller nutzbare Ergebnisse zu liefern,
Erfahrungen früh einzubeziehen,
und Entscheidungen auf Grundlage tatsächlicher Ergebnisse zu verbessern.

Iteration bedeutet nicht, ohne Ziel immer wieder dasselbe zu versuchen.

Eine Iteration benötigt:

ein klares Teilziel,
einen begrenzten Umfang,
überprüfbare Ergebnisse,
Feedback,
und eine Entscheidung über den nächsten Schritt.

Leitfragen zu Progress iteratively with feedback

Kann das Vorhaben in kleinere Teile zerlegt werden?
Welcher kleinste sinnvolle Schritt liefert verwertbares Wissen?
Welche Risiken können früh geprüft werden?
Wer gibt Feedback?
Wie wird das Ergebnis gemessen?
Welche Erkenntnisse müssen vor dem nächsten Schritt berücksichtigt werden?
Welche Abhängigkeiten verhindern eine sinnvolle Teilung?
Welche Rückfallmöglichkeit besteht?
Wann ist die nächste Iteration sinnvoll?

Praxisbeispiel: Einführung einer Monitoring-Plattform

Statt sofort alle Systeme zu überwachen, kann eine Organisation schrittweise vorgehen.

Erste Iteration

einen kritischen Service auswählen
wichtigste Komponenten erfassen
wenige relevante Alarme konfigurieren
Verantwortlichkeiten festlegen
Benachrichtigung und Reaktion testen

Feedback auswerten

Werden relevante Störungen erkannt?
Entstehen zu viele Fehlalarme?
Sind Schwellenwerte geeignet?
Erhalten die richtigen Personen die Meldungen?
Sind die Informationen zur Fehleranalyse ausreichend?

Nächste Iteration

Alarmregeln verbessern
weitere Servicekomponenten aufnehmen
Dashboards ergänzen
Dokumentation aktualisieren
Automatisierung erweitern

Merke

Eine kleine Iteration sollte nicht nur Arbeit erzeugen.

Sie sollte ein verwertbares Ergebnis oder neues Wissen liefern.

Feedback richtig verwenden

Feedback kann aus unterschiedlichen Quellen stammen:

Benutzererfahrung,
technische Messwerte,
Supportanfragen,
Incidents,
Tests,
Rückmeldungen von Mitarbeitern,
Lieferanteninformationen,
Audits,
und Geschäftsergebnisse.

Feedback ist nicht automatisch eine Anweisung.

Es muss bewertet werden hinsichtlich:

Relevanz,
Zuverlässigkeit,
Ursache,
Häufigkeit,
Auswirkungen,
und Zusammenhang mit anderen Anforderungen.

Typischer Fehler

Feedback wird erst am Ende eines umfangreichen Vorhabens eingeholt.

Dann können grundlegende Fehlentscheidungen bereits hohe Kosten verursacht haben.

Bedeutung für Änderungen

Bei einer größeren technischen Änderung kann ein iteratives Vorgehen beispielsweise bedeuten:

Testumgebung verwenden
begrenzte Pilotgruppe auswählen
technische und servicebezogene Ergebnisse prüfen
Rückmeldungen auswerten
Konfiguration anpassen
kontrolliert auf weitere Systeme ausweiten
nach jeder Stufe überwachen

Ein iteratives Vorgehen ist nicht immer möglich.

Bei akuten Sicherheitsrisiken, gesetzlichen Fristen oder kritischen Störungen kann schnelles umfassendes Handeln notwendig sein.

Auch dann sollten Ergebnisse und Rückmeldungen so früh wie möglich ausgewertet werden.

4. Collaborate and promote visibility

Sinngemäße Bedeutung

Geeignete Personen und Teams sollen zusammenarbeiten. Relevante Informationen, Entscheidungen, Risiken und Fortschritte müssen für die zuständigen Beteiligten sichtbar sein.

Zusammenarbeit bedeutet nicht, jede Person an jeder Entscheidung zu beteiligen.

Zu viele Beteiligte können:

Entscheidungen verzögern,
Verantwortlichkeiten verwischen,
unnötige Besprechungen erzeugen,
und den Arbeitsfluss behindern.

Entscheidend ist, die richtigen Beteiligten zum richtigen Zeitpunkt mit den richtigen Informationen einzubeziehen.

Leitfragen zu Collaborate and promote visibility

Wer besitzt notwendiges Fachwissen?
Wer trägt Verantwortung?
Wer ist von der Entscheidung betroffen?
Wer muss informiert werden?
Welche Informationen müssen sichtbar sein?
Welche Informationen dürfen aus Sicherheits- oder Datenschutzgründen nicht allgemein sichtbar sein?
Wie werden Entscheidungen dokumentiert?
Wo befinden sich aktuelle Statusinformationen?
Welche Übergaben bestehen?
Wo entstehen Informationsverluste oder Missverständnisse?

Praxisbeispiel: Änderung einer Firewall-Regel

Eine Fachabteilung benötigt eine neue Verbindung zu einem externen Dienst.

Mögliche Beteiligte sind:

Anforderer,
Anwendungsverantwortlicher,
Netzwerkadministration,
Informationssicherheit,
Datenschutz,
externer Dienstleister,
Service Owner,
und Change-Verantwortlicher.

Sichtbar sein sollten unter anderem:

Zweck der Verbindung,
Quelle und Ziel,
benötigte Ports und Protokolle,
betroffene Services,
Sicherheitsbewertung,
Freigabe,
geplanter Umsetzungszeitpunkt,
Testergebnis,
Rückfallplan,
und tatsächlich umgesetzte Konfiguration.

Merke

Sichtbarkeit bedeutet nicht, dass jede Information öffentlich sein muss.

Relevante Informationen müssen für die berechtigten und verantwortlichen Beteiligten zugänglich sein.

Warum Sichtbarkeit wichtig ist

Fehlende Sichtbarkeit kann dazu führen, dass:

mehrere Teams dieselbe Arbeit durchführen,
Änderungen miteinander kollidieren,
Incidents falsch priorisiert werden,
Entscheidungen nicht nachvollziehbar sind,
Risiken zu spät erkannt werden,
und Benutzer widersprüchliche Informationen erhalten.

Geeignete Formen der Sichtbarkeit können sein:

aktueller Ticketstatus,
Service-Dashboard,
Change-Kalender,
dokumentierte Entscheidung,
Wissensartikel,
Konfigurationsinformationen,
Statusmeldung,
Kanban-Board,
oder gemeinsames Incident-Protokoll.

Zusammenarbeit und Verantwortung

Zusammenarbeit ersetzt keine eindeutige Verantwortung.

Auch bei gemeinsamer Bearbeitung muss erkennbar bleiben:

Wer koordiniert?
Wer entscheidet?
Wer führt die Maßnahme aus?
Wer prüft das Ergebnis?
Wer informiert die Stakeholder?
Wer aktualisiert die Dokumentation?

Typischer Fehler

Viele Personen werden informiert, aber niemand besitzt eine eindeutige Verantwortung für den nächsten Schritt.

5. Think and work holistically

Sinngemäße Bedeutung

Produkte, Services, Organisationen und ihre Bestandteile sollen als zusammenhängendes System betrachtet werden.

Ein Service hängt selten nur von einer einzelnen technischen Komponente ab.

Zu berücksichtigen sind unter anderem:

Menschen und Rollen,
Informationen,
Technologien,
Partner,
Lieferanten,
Prozesse,
Wertströme,
Sicherheitsanforderungen,
Kosten,
Risiken,
Erfahrungen,
und technische Abhängigkeiten.

Die vier Dimensionen des Produkt- und Service-Managements unterstützen diese ganzheitliche Betrachtung.

Leitfragen zu Think and work holistically

Welches Produkt oder welcher Service ist betroffen?
Welche technischen Komponenten gehören dazu?
Welche Benutzer und Geschäftsprozesse sind abhängig?
Welche Teams und Rollen sind beteiligt?
Welche Lieferanten werden benötigt?
Welche Informationen fließen zwischen den Beteiligten?
Welche Wechselwirkungen bestehen?
Welche unbeabsichtigten Folgen kann eine Maßnahme besitzen?
Was geschieht vor und nach meinem eigenen Arbeitsschritt?
Wie wird das Ende-zu-Ende-Ergebnis geprüft?

Praxisbeispiel: Benutzeranmeldung funktioniert nicht

Mögliche technische Abhängigkeiten:

Endgerät,
Netzwerk,
DNS,
Zeitsynchronisation,
Verzeichnisdienst,
Identitätsanbieter,
Zertifikate,
Multi-Faktor-Authentifizierung,
Benutzerkonto,
Gruppenmitgliedschaften,
und Cloud-Dienste.

Mögliche organisatorische Abhängigkeiten:

Berechtigungsfreigabe,
Eintritts- oder Austrittsprozess,
Sicherheitsrichtlinie,
Helpdesk-Arbeitsweise,
externer Provider,
und Zuständigkeit für Identitätsmanagement.

Eine ausschließlich auf das Benutzerkennwort beschränkte Betrachtung kann deshalb zu kurz greifen.

Lokale Optimierung vermeiden

Ein einzelnes Team kann seine eigene Kennzahl verbessern und gleichzeitig den gesamten Wertstrom verschlechtern.

Beispiel:

Der Service Desk verkürzt seine durchschnittliche Bearbeitungszeit, indem komplexe Tickets möglichst schnell an andere Teams weitergegeben werden.

Die lokale Kennzahl verbessert sich.

Für den Benutzer können jedoch entstehen:

mehr Übergaben,
längere Gesamtdauer,
wiederholte Rückfragen,
widersprüchliche Informationen,
und geringere Zufriedenheit.

Merke

Eine lokale Verbesserung ist nur dann hilfreich, wenn sie den gesamten Wertstrom und das benötigte Outcome unterstützt.

Bedeutung für technische Änderungen

Vor dem Austausch einer technischen Komponente sollte geprüft werden:

Welche Services verwenden sie?
Welche Schnittstellen bestehen?
Welche Überwachung ist betroffen?
Welche Backup- und Wiederherstellungsverfahren gelten?
Welche Dokumentationen müssen aktualisiert werden?
Welche Lieferanten sind beteiligt?
Welche Sicherheitskontrollen greifen?
Welche Benutzer müssen informiert werden?
Welche anderen Changes finden gleichzeitig statt?

6. Keep it simple and practical

Sinngemäße Bedeutung

Arbeitsweisen, Kontrollen und Lösungen sollen so einfach wie möglich und so umfangreich wie tatsächlich notwendig gestaltet werden.

Einfach bedeutet nicht:

oberflächlich,
unkontrolliert,
unvollständig,
oder ohne Sicherheitsmaßnahmen.

Einfach bedeutet:

verständlich,
zweckmäßig,
angemessen,
wartbar,
und frei von unnötiger Komplexität.

Jeder zusätzliche Schritt, jedes Pflichtfeld und jede Genehmigung sollte einen nachvollziehbaren Zweck besitzen.

Leitfragen zu Keep it simple and practical

Welchen Zweck erfüllt dieser Schritt?
Was würde geschehen, wenn er entfernt wird?
Welche Information wird tatsächlich benötigt?
Ist die Arbeitsweise für die Beteiligten verständlich?
Gibt es doppelte Erfassungen?
Sind alle Genehmigungen notwendig?
Kann eine Regel vereinheitlicht werden?
Ist die Lösung langfristig wartbar?
Passt der Aufwand zum Risiko?
Wird eine seltene Ausnahme unnötig zum Standard gemacht?

Praxisbeispiel: Change-Dokumentation

Für einen Change werden 35 Pflichtfelder verlangt.

In der Praxis werden viele Felder:

mit bedeutungslosen Standardtexten,
mehrfach identischen Angaben,
oder unzutreffenden Platzhaltern

gefüllt.

Die umfangreiche Dokumentation erzeugt dadurch keine zusätzliche Sicherheit.

Eine zweckmäßige Struktur könnte sich stattdessen auf tatsächlich notwendige Informationen konzentrieren:

Ziel und Begründung,
betroffene Produkte und Services,
technische Änderung,
Auswirkungen und Risiken,
Test,
Freigabe,
Umsetzungsplan,
Rückfallplan,
Kommunikation,
und Erfolgskontrolle.

Typischer Fehler

Umfang wird mit Qualität verwechselt.

Eine längere Arbeitsanweisung ist nicht automatisch verständlicher oder sicherer.

Angemessene Kontrolle statt identischer Kontrolle

Nicht jede Änderung besitzt dasselbe Risiko.

Beispiele:

Änderung	Möglicher Kontrollumfang
dokumentierte, häufig ausgeführte Standardänderung	vereinfachter und vorab autorisierter Ablauf
normale Änderung mit überschaubarem Risiko	angemessene Bewertung und Freigabe
kritische Änderung an zentraler Infrastruktur	umfangreichere Prüfung, Abstimmung und Rückfallplanung
dringende Änderung zur Behebung einer akuten Gefahr	beschleunigtes Verfahren mit nachträglicher Kontrolle

Die konkrete Organisation legt die Change-Modelle, Freigaben und Risikokriterien fest.

Merke

Einfachheit entsteht nicht dadurch, notwendige Kontrollen wegzulassen.

Sie entsteht durch passende Kontrollen ohne unnötige Schritte.

7. Optimize and automate

Sinngemäße Bedeutung

Arbeit soll zunächst verstanden und verbessert werden. Anschließend können geeignete Bestandteile automatisiert werden.

Automatisierung kann unter anderem:

Bearbeitungszeiten verkürzen,
wiederkehrende Fehler reduzieren,
Ergebnisse vereinheitlichen,
Mitarbeiter entlasten,
Skalierbarkeit verbessern,
und Kontrollen nachvollziehbarer machen.

Automatisierung kann jedoch auch:

Fehler schneller verbreiten,
intransparente Abhängigkeiten erzeugen,
Sicherheitsrisiken vergrößern,
Ausnahmen falsch behandeln,
oder eine ungeeignete Arbeitsweise dauerhaft festschreiben.

Grundsatz

Nicht alles, was technisch automatisierbar ist, sollte automatisiert werden.

Leitfragen zu Optimize and automate

Welches Outcome soll verbessert werden?
Ist die bestehende Arbeitsweise verstanden?
Welche Schritte erzeugen keinen erkennbaren Nutzen?
Welche Engpässe bestehen?
Ist der Ablauf ausreichend stabil und wiederholbar?
Welche Entscheidungen benötigen menschliches Urteilsvermögen?
Welche Ausnahmen existieren?
Wie werden Fehler erkannt und behandelt?
Wie wird die Automatisierung überwacht?
Gibt es eine manuelle Rückfallmöglichkeit?
Sind Sicherheit und Datenschutz berücksichtigt?
Ist der Nutzen größer als Aufbau und Wartungsaufwand?

Optimierung vor Automatisierung

Eine geeignete Reihenfolge ist:

Outcome und Zweck verstehen
aktuellen Ablauf erfassen
unnötige Schritte entfernen
Übergaben und Abhängigkeiten verbessern
Ablauf vereinheitlichen
geeignete Tätigkeiten automatisieren
Ergebnisse überwachen
Automatisierung fortlaufend verbessern

Typischer Fehler

Ein fehlerhafter oder unnötig komplexer Ablauf wird unverändert automatisiert.

Das Ergebnis ist ein schnellerer fehlerhafter Ablauf.

Praxisbeispiel: automatische Benutzeranlage

Geeignete Automatisierungen können sein:

Übernahme freigegebener Personaldaten,
Erstellung eines Benutzerkontos,
Zuweisung standardisierter Gruppen,
Vergabe vorgesehener Lizenzen,
Erstellung standardisierter Tickets,
Benachrichtigung zuständiger Teams,
und Aktualisierung von Asset- oder Konfigurationsinformationen.

Nicht vollständig automatisiert werden sollten möglicherweise:

nicht standardisierte Berechtigungsentscheidungen,
sicherheitskritische Ausnahmen,
unklare oder widersprüchliche Anforderungen,
und Entscheidungen ohne verantwortlichen Genehmiger.

Die Automatisierung muss zusätzlich kontrollieren:

ob alle notwendigen Daten vorhanden sind,
ob eine Freigabe vorliegt,
ob ein Konto bereits existiert,
ob ein Teilschritt fehlgeschlagen ist,
ob das Ergebnis vollständig war,
und wer bei Fehlern informiert wird.

Automatisierung und künstliche Intelligenz

ITIL Version 5 berücksichtigt digitale und KI-gestützte Arbeitsumgebungen stärker.

Auch beim Einsatz von KI bleiben die Guiding Principles relevant.

Vor einer KI-gestützten Automatisierung sollte unter anderem geprüft werden:

Welches Outcome soll verbessert werden?
Welche Daten werden verwendet?
Sind Ergebnisse nachvollziehbar?
Welche Fehler können entstehen?
Welche menschliche Kontrolle ist erforderlich?
Werden Datenschutz und Informationssicherheit eingehalten?
Kann eine Entscheidung angefochten oder korrigiert werden?
Wie werden Qualität und Verzerrungen überwacht?
Welche Verantwortung verbleibt bei Menschen?

Sicherheitsrelevant

Eine automatisierte oder KI-generierte Entscheidung entbindet die Organisation nicht von Verantwortung, Kontrolle und Risikobewertung.

Zusammenspiel der sieben Guiding Principles

Die Prinzipien entfalten ihren größten Nutzen, wenn sie gemeinsam betrachtet werden.

Beispiel: Ablösung eines alten Fileservers

Focus on value

Welche Outcomes müssen erhalten oder verbessert werden?
Benötigen Benutzer weiterhin dieselben Zugriffsmöglichkeiten?

Start where you are

Welche Daten, Berechtigungen und Abhängigkeiten bestehen?
Welche Teile der vorhandenen Lösung funktionieren zuverlässig?

Progress iteratively with feedback

Kann zunächst eine begrenzte Benutzergruppe migriert werden?
Welche Rückmeldungen liefert der Pilot?

Collaborate and promote visibility

Welche Fachabteilungen, Administratoren und Sicherheitsverantwortlichen müssen beteiligt werden?
Wo wird der Migrationsstatus dokumentiert?

Think and work holistically

Sind Anwendungen, Backups, Berechtigungen, Netzlaufwerke, Skripte und Schnittstellen berücksichtigt?

Keep it simple and practical

Welche alte Verzeichnisstruktur oder Sonderberechtigung wird nicht mehr benötigt?
Kann die Zielstruktur vereinfacht werden?

Optimize and automate

Können Datenübertragung, Berechtigungsprüfung und Erfolgskontrolle automatisiert werden?

Mögliche Spannungen zwischen den Prinzipien

Die Guiding Principles liefern nicht immer automatisch dieselbe Handlungsrichtung.

Beispiele:

Mögliche Spannung	Notwendige Abwägung
schnell iterieren oder ganzheitlich analysieren	ausreichend prüfen, ohne jede denkbare Frage vor dem ersten Schritt lösen zu wollen
einfach halten oder zusätzliche Kontrollen einführen	Kontrollaufwand am tatsächlichen Risiko ausrichten
Zusammenarbeit fördern oder schnell entscheiden	notwendige Beteiligte einbeziehen, aber Verantwortung eindeutig lassen
automatisieren oder flexibel bleiben	nur stabile und ausreichend verstandene Teile automatisieren
Bestehendes nutzen oder neu aufbauen	Nutzen, technische Schulden, Risiken und Migrationsaufwand vergleichen
kurzfristigen Wert oder langfristige Nachhaltigkeit priorisieren	unmittelbare Outcomes und langfristige Folgen gemeinsam bewerten

Merke

Die Guiding Principles ersetzen keine fachliche Abwägung.

Sie verbessern die Qualität der Fragen, auf deren Grundlage entschieden wird.

Guiding Principles bei einem Incident

Auch bei einer laufenden Störung können die Prinzipien helfen.

Guiding Principle	Anwendung im Incident
Focus on value	zuerst die für Benutzer wichtigste Servicefunktion wiederherstellen
Start where you are	vorhandene Monitoring-Daten, bekannte Fehler und letzte Changes prüfen
Progress iteratively with feedback	Maßnahmen kontrolliert durchführen und Ergebnis nach jedem Schritt prüfen
Collaborate and promote visibility	zuständige Teams einbinden und aktuellen Status sichtbar halten
Think and work holistically	Serviceabhängigkeiten und mögliche Folgeauswirkungen berücksichtigen
Keep it simple and practical	zunächst die sicherste geeignete Wiederherstellung wählen
Optimize and automate	nach dem Incident wiederkehrende Diagnose- oder Wiederherstellungsschritte verbessern

Während eines kritischen Incidents steht zunächst die sichere und angemessene Wiederherstellung im Vordergrund.

Die umfassende Ursachenanalyse und nachhaltige Verbesserung können anschließend folgen.

Guiding Principles bei einem Change

Guiding Principle	Anwendung beim Change
Focus on value	Zweck, Outcome und Nutzen des Changes klären
Start where you are	aktuellen Zustand und vorhandene Konfiguration erfassen
Progress iteratively with feedback	Test, Pilot oder schrittweise Einführung verwenden
Collaborate and promote visibility	Betroffene, Verantwortliche und Abhängigkeiten sichtbar machen
Think and work holistically	Auswirkungen auf Produkte, Services, Sicherheit und Lieferanten betrachten
Keep it simple and practical	angemessenen Kontrollumfang wählen
Optimize and automate	standardisierbare Prüfung und Umsetzung verbessern

Bedeutung für Fachinformatiker für Systemintegration

Die Guiding Principles helfen bei technischen und organisatorischen Entscheidungen.

Beispiele:

Soll ein Server repariert, aktualisiert oder ersetzt werden?
Muss eine technische Lösung vollständig neu aufgebaut werden?
Welche Benutzer müssen vor einer Änderung beteiligt werden?
Kann eine Migration schrittweise erfolgen?
Welche Informationen müssen im Ticket sichtbar sein?
Ist eine Arbeitsanweisung unnötig kompliziert?
Welche wiederkehrenden Tätigkeiten können automatisiert werden?
Unterstützt die technische Maßnahme tatsächlich das erwartete Outcome?

Ein Fachinformatiker muss die englischen Bezeichnungen nicht in jedem Ticket dokumentieren.

Die zugrunde liegenden Fragen sollten jedoch Teil der professionellen Arbeitsweise werden.

Entscheidungshilfe für neue Aufgaben

Bei einer neuen Aufgabe kannst du die sieben Prinzipien als Kurzprüfung verwenden:

Wert: Welches Outcome soll erreicht werden?
Ausgangslage: Was ist bereits vorhanden und funktionsfähig?
Schritte: Kann kontrolliert und iterativ vorgegangen werden?
Zusammenarbeit: Wer muss beteiligt und informiert werden?
Gesamtsicht: Welche Abhängigkeiten und Auswirkungen bestehen?
Einfachheit: Welche Schritte sind tatsächlich erforderlich?
Optimierung: Was kann verbessert und anschließend automatisiert werden?

Checkliste zur Anwendung der Guiding Principles

Typische Fehlanwendungen

Nur ein Prinzip verwenden

Ein Team beruft sich ausschließlich auf Keep it simple and practical, um notwendige Sicherheitskontrollen wegzulassen.

Richtig wäre, zusätzlich:

Wert,
Risiken,
Governance,
Gesamtauswirkungen,
und betroffene Stakeholder

zu berücksichtigen.

Start where you are mit Stillstand verwechseln

Der aktuelle Zustand wird nicht verbessert, weil er bereits lange besteht.

Das Prinzip verlangt jedoch eine Bestandsaufnahme, keine unveränderte Fortführung.

Iterationen ohne klares Ziel durchführen

Es werden regelmäßig kleine Änderungen vorgenommen, aber weder Outcome noch Erfolgskriterien sind definiert.

Iteration benötigt Ziel, Feedback und Auswertung.

Sichtbarkeit mit Informationsüberlastung verwechseln

Alle Beteiligten erhalten jede technische Einzelmeldung.

Dadurch gehen relevante Informationen in der Menge unter.

Sichtbarkeit muss zielgruppengerecht und handlungsorientiert sein.

Ganzheitliche Betrachtung als endlose Analyse verwenden

Eine Organisation untersucht jede denkbare Auswirkung und beginnt deshalb nie mit der Umsetzung.

Ganzheitlich denken schließt ein iteratives und pragmatisches Vorgehen nicht aus.

Einfachheit mit fehlender Sorgfalt verwechseln

Dokumentation, Tests oder Rückfallplanung werden weggelassen.

Einfachheit darf notwendige Sicherheit und Nachvollziehbarkeit nicht beseitigen.

Automatisierung als Selbstzweck betrachten

Eine Tätigkeit wird automatisiert, weil die technische Möglichkeit besteht.

Der tatsächliche Nutzen, die Wartung und mögliche Risiken werden nicht bewertet.

Schnellreferenz

Principle	Kurzfrage
Focus on value	Welchen Wert und welches Outcome ermöglicht die Tätigkeit?
Start where you are	Was ist bereits vorhanden und funktioniert?
Progress iteratively with feedback	Was ist der nächste kontrollierbare Schritt?
Collaborate and promote visibility	Wer muss beteiligt sein und was muss sichtbar werden?
Think and work holistically	Welche Zusammenhänge und Abhängigkeiten bestehen?
Keep it simple and practical	Was ist tatsächlich notwendig?
Optimize and automate	Was kann zuerst verbessert und danach automatisiert werden?

Zusammenfassende Darstellung

Focus on value
Ziel und Outcome verstehen
↓
Start where you are
tatsächlichen Ausgangszustand prüfen
↓
Progress iteratively with feedback
kontrolliert vorgehen und lernen
↓
Collaborate and promote visibility
geeignete Beteiligte und Informationen verbinden
↓
Think and work holistically
das gesamte System berücksichtigen
↓
Keep it simple and practical
unnötige Komplexität vermeiden
↓
Optimize and automate
verbessern, automatisieren und überwachen

Diese Darstellung dient nur als Lernhilfe.

Die Guiding Principles bilden keine verbindliche Reihenfolge und können gleichzeitig angewendet werden.

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die offiziellen ITIL-Version-5-Übersichten bestätigen, dass die Guiding Principles weiterhin ein Kernelement des ITIL Value Systems und der praktischen Entscheidungsfindung sind.

Die sieben Guiding Principles werden aus ITIL 4 fortgeführt:

Focus on value
Start where you are
Progress iteratively with feedback
Collaborate and promote visibility
Think and work holistically
Keep it simple and practical
Optimize and automate

Die deutschen Erklärungen, Leitfragen, Praxisbeispiele, Tabellen und Checklisten auf dieser Seite sind eigene sinngemäße Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.4 Governance und Verantwortlichkeit

Kurz erklärt

Governance beschreibt, wie eine Organisation gelenkt und kontrolliert wird.

Sie sorgt dafür, dass:

Ziele und Prioritäten festgelegt werden,

Entscheidungen innerhalb klarer Rahmenbedingungen getroffen werden,

Verantwortlichkeiten eindeutig sind,

Risiken angemessen behandelt werden,

verbindliche Vorgaben eingehalten werden,

und die tatsächlichen Ergebnisse überwacht werden.

Im ITIL Value System wird Governance durch drei grundlegende Aktivitäten verwirklicht:

Evaluate – bewerten

Direct – Richtung vorgeben

Monitor – überwachen

Warum Governance notwendig ist

Digitale Produkte und Services beeinflussen heute häufig:

Geschäftsprozesse,
Kommunikation,
Kundenerfahrung,
Informationssicherheit,
Datenschutz,
Finanzen,
Produktion,
Lieferketten,
und die Arbeitsfähigkeit von Mitarbeitern.

Technische Entscheidungen können deshalb weitreichende organisatorische Folgen besitzen.

Beispiele:

Eine Firewall-Regel beeinflusst die Sicherheit und Erreichbarkeit eines Service.
Eine neue Cloud-Anwendung kann personenbezogene Daten verarbeiten.
Eine Änderung am Verzeichnisdienst kann viele Benutzer und Anwendungen betreffen.
Eine nicht getestete Wiederherstellung kann im Notfall zu langen Ausfallzeiten führen.
Eine KI-gestützte Entscheidung kann falsche oder nicht nachvollziehbare Ergebnisse erzeugen.
Ein externer Dienstleister kann eine kritische Abhängigkeit für mehrere Services darstellen.

Ohne klare Governance können unter anderem folgende Probleme entstehen:

Entscheidungen werden ohne ausreichende Befugnis getroffen.
Verantwortlichkeiten sind unklar.
Risiken werden uneinheitlich bewertet.
Teams verfolgen widersprüchliche Ziele.
verbindliche Vorgaben werden übersehen.
technische Maßnahmen unterstützen nicht die Ziele der Organisation.
Leistung wird gemessen, aber nicht wirksam bewertet.
bekannte Probleme bleiben ohne Konsequenz.
externe Dienstleister werden nicht ausreichend kontrolliert.
niemand trägt erkennbar Verantwortung für das Gesamtergebnis.

Merke

Governance soll nicht jede technische Einzelentscheidung zentralisieren.

Sie schafft den Rahmen, innerhalb dessen angemessene Entscheidungen getroffen und kontrolliert werden können.

Governance im ITIL Value System

Governance ist einer der fünf Bestandteile des ITIL Value Systems.

Das Value System verbindet:

Guiding Principles,
Governance,
Value Chain Activities,
Management Practices,
und Continual Improvement.

Governance stellt dabei sicher, dass die Tätigkeiten der Organisation:

an ihren Zielen ausgerichtet sind,
innerhalb akzeptierter Grenzen stattfinden,
nachvollziehbar entschieden werden,
und hinsichtlich Leistung, Risiken und Regelkonformität überwacht werden.

Governance wirkt damit auf:

digitale Produkte,
Services,
Practices,
Wertströme,
Projekte,
technische Änderungen,
Lieferantenbeziehungen,
Investitionen,
Informationssicherheit,
und Verbesserungsinitiativen.

Wichtig

Governance ist kein einzelner Prozess und keine einzelne Management Practice.

Sie ist ein übergreifender Bestandteil des gesamten ITIL Value Systems.

Die drei Governance-Aktivitäten

Governance wird durch drei grundlegende Aktivitäten verwirklicht:

Aktivität	Bedeutung	Zentrale Frage
Evaluate	Bedürfnisse, Optionen, Leistung, Risiken und Rahmenbedingungen bewerten	Was ist notwendig und welche Entscheidung ist angemessen?
Direct	Richtung, Prioritäten, Grundsätze und Entscheidungsrahmen vorgeben	Was soll erreicht werden und innerhalb welcher Grenzen?
Monitor	Leistung, Ergebnisse, Risiken und Einhaltung überwachen	Erreichen wir die Ziele und werden die Vorgaben eingehalten?

Diese Aktivitäten sind miteinander verbunden.

Die Ergebnisse des Monitorings können eine erneute Bewertung auslösen.

Aus einer neuen Bewertung können wiederum geänderte Vorgaben oder Prioritäten entstehen.

Vereinfachter Kreislauf

Evaluate
↓
Direct
↓
Monitor
↓
neue Erkenntnisse
↓
erneut Evaluate

Evaluate – bewerten

Bei Evaluate werden die aktuelle Situation, Bedürfnisse, Möglichkeiten und Risiken untersucht.

Mögliche Bewertungsgegenstände sind:

Anforderungen von Kunden und Benutzern,
Ziele der Organisation,
gesetzliche Verpflichtungen,
vertragliche Anforderungen,
technische Möglichkeiten,
bestehende Fähigkeiten,
Kosten,
Risiken,
Sicherheitsanforderungen,
Nachhaltigkeitsaspekte,
Erfahrungen der Stakeholder,
und erwartete Outcomes.

Beispiel:

Eine Organisation prüft, ob eine zentrale Cloud-Plattform eingeführt werden soll.

Bei der Bewertung können unter anderem folgende Fragen relevant sein:

Welches Problem soll gelöst werden?
Welche Outcomes werden erwartet?
Welche Daten werden verarbeitet?
Welche Sicherheits- und Datenschutzanforderungen gelten?
Welche Kosten entstehen?
Welche Lieferantenabhängigkeiten entstehen?
Welche vorhandenen Systeme müssen integriert werden?
Welche Risiken entstehen bei einem Ausfall?
Welche Fähigkeiten werden intern benötigt?
Welche Alternativen bestehen?
Wie kann die Lösung später wieder abgelöst werden?

Typischer Fehler

Eine Entscheidung wird ausschließlich anhand des Anschaffungspreises oder einzelner technischer Funktionen bewertet.

Betrieb, Support, Integration, Sicherheit, Abhängigkeiten und spätere Ablösung werden nicht berücksichtigt.

Evaluate bedeutet nicht nur einmalig prüfen

Bewertung findet nicht ausschließlich vor einer Einführung statt.

Eine erneute Bewertung kann notwendig sein, wenn:

sich Geschäftsziele ändern,
neue gesetzliche Anforderungen entstehen,
ein Sicherheitsvorfall auftritt,
ein Lieferant seine Leistung verändert,
neue Technologien verfügbar werden,
Benutzerfeedback auf Probleme hinweist,
Kosten deutlich steigen,
Risiken anders eingeschätzt werden,
oder ein Service seine Ziele nicht mehr erreicht.

Beispiel:

Eine Anwendung wurde ursprünglich nur für eine kleine interne Abteilung eingeführt.

Später wird sie für einen unternehmenskritischen Prozess eingesetzt.

Dadurch können sich ändern:

Verfügbarkeitsanforderungen,
Sicherheitsanforderungen,
Supportzeiten,
Wiederherstellungsziele,
Überwachung,
Dokumentation,
und notwendige Lieferantenvereinbarungen.

Die ursprüngliche Bewertung reicht dann möglicherweise nicht mehr aus.

Direct – Richtung vorgeben

Bei Direct werden Richtung, Prioritäten und Rahmenbedingungen vorgegeben.

Dies kann beispielsweise erfolgen durch:

Strategien,
Grundsätze,
Richtlinien,
Ziele,
Prioritäten,
Entscheidungsbefugnisse,
Risikogrenzen,
Rollen,
Vorgaben für Kontrollen,
und zu erreichende Ergebnisse.

Beispiele:

Administrative Zugriffe müssen durch Multi-Faktor-Authentifizierung geschützt werden.
Kritische Services müssen dokumentierte Wiederherstellungsverfahren besitzen.
Produktive Änderungen benötigen eine dem Risiko angemessene Autorisierung.
Personenbezogene Daten dürfen nur in freigegebenen Systemen verarbeitet werden.
Für kritische Lieferanten müssen Ausweich- oder Beendigungsstrategien betrachtet werden.
Sicherheitsrelevante Ereignisse müssen nach dem festgelegten Verfahren gemeldet werden.
Wiederherstellungsverfahren müssen in festgelegten Abständen getestet werden.

Governance gibt dabei normalerweise nicht jeden technischen Einzelschritt vor.

Beispiel:

Governance kann festlegen:

Administrative Zugriffe müssen mit einer starken Mehrfaktor-Authentifizierung geschützt werden.

Das zuständige Management und die Fachteams bestimmen anschließend:

welche technische Lösung verwendet wird,
wie sie eingeführt wird,
welche Ausnahmen zulässig sind,
wie Benutzer unterstützt werden,
und wie die Wirksamkeit kontrolliert wird.

Richtung und Grenzen

Eine gute Governance-Vorgabe beantwortet möglichst:

Welches Ziel wird verfolgt?
Für welchen Bereich gilt die Vorgabe?
Wer trägt Verantwortung?
Welche Grenzen müssen eingehalten werden?
Welche Ausnahmen sind möglich?
Wer darf Ausnahmen genehmigen?
Wie wird die Einhaltung geprüft?
Was geschieht bei Abweichungen?
Wann wird die Vorgabe erneut bewertet?

Unklare Vorgabe:

Systeme müssen sicher sein.

Präzisere Vorgabe:

Kritische Systeme müssen entsprechend der festgelegten Schutzbedarfs- und Risikobewertung abgesichert, überwacht und regelmäßig auf die Wirksamkeit ihrer Kontrollen geprüft werden.

Die konkrete technische Umsetzung wird anschließend durch zuständige Fachkräfte und Management Practices gestaltet.

Monitor – überwachen

Bei Monitor wird geprüft, ob:

die vorgegebene Richtung eingehalten wird,
Ziele erreicht werden,
Risiken innerhalb akzeptierter Grenzen bleiben,
Kontrollen wirksam sind,
Verantwortlichkeiten wahrgenommen werden,
und Produkte sowie Services die erwarteten Outcomes unterstützen.

Monitoring im Governance-Kontext bedeutet mehr als technische Überwachung.

Es kann unter anderem umfassen:

Serviceleistung,
Benutzer- und Kundenerfahrung,
Sicherheitsrisiken,
Einhaltung von Richtlinien,
Kostenentwicklung,
Lieferantenleistung,
Fortschritt strategischer Vorhaben,
Ergebnisse von Audits,
Status kritischer Verbesserungen,
Wiederherstellbarkeit,
und Wirksamkeit organisatorischer Kontrollen.

Beispiel:

Eine Organisation verlangt regelmäßige Wiederherstellungstests.

Governance-Monitoring prüft nicht nur, ob ein Testtermin im Kalender stand.

Es prüft beispielsweise:

Wurde der Test tatsächlich durchgeführt?
Welche Systeme wurden getestet?
War die Wiederherstellung erfolgreich?
Wurden die vereinbarten Wiederherstellungsziele erreicht?
Welche Probleme wurden erkannt?
Wurden notwendige Verbesserungen umgesetzt?
Bestehen weiterhin nicht akzeptierte Risiken?

Merke

Aktivität ist nicht automatisch Wirksamkeit.

Ein ausgefülltes Kontrollformular beweist noch nicht, dass das gewünschte Ergebnis erreicht wurde.

Governance und Management unterscheiden

Governance und Management sind eng miteinander verbunden, aber nicht identisch.

Governance	Management
bewertet Bedürfnisse, Erwartungen und Rahmenbedingungen	plant und organisiert die praktische Umsetzung
gibt Richtung und Grenzen vor	weist Ressourcen und Aufgaben zu
legt Verantwortlichkeit und Entscheidungsbefugnisse fest	koordiniert Teams, Practices und Arbeitsabläufe
überwacht Outcomes, Risiken und Regelkonformität	überwacht die laufende Ausführung
entscheidet über grundlegende Prioritäten	trifft operative und taktische Entscheidungen innerhalb des Rahmens
stellt Rechenschaftspflicht sicher	liefert Ergebnisse und berichtet darüber

Vereinfacht:

Governance

Bestimmt, was erreicht und kontrolliert werden muss.

Management

Organisiert, wie dies innerhalb des vorgegebenen Rahmens umgesetzt wird.

Diese Trennung bedeutet nicht, dass Governance nur die Unternehmensleitung betrifft.

Auch nachgelagerte Gremien oder Rollen können delegierte Governance-Aufgaben wahrnehmen.

Die grundlegende Rechenschaftspflicht muss jedoch eindeutig bleiben.

Beispiel: Einführung von Multi-Faktor-Authentifizierung

Governance

bewertet Sicherheitsrisiken und rechtliche Anforderungen
gibt das Ziel einer starken Authentifizierung vor
legt Geltungsbereich und zulässige Ausnahmen fest
bestimmt Verantwortlichkeit
fordert Wirksamkeitsnachweise
überwacht Risiken und Einhaltung

Management

plant die Einführung
wählt geeignete Produkte und Verfahren
organisiert Ressourcen
legt Zeitplan und Pilotgruppen fest
koordiniert Kommunikation und Support
behandelt technische Probleme
berichtet über Fortschritt und Ergebnisse

Technische Umsetzung

Identitätsanbieter konfigurieren
Authentifizierungsmethoden einrichten
Richtlinien anwenden
Benutzer registrieren
Protokollierung aktivieren
Notfallzugänge absichern
Funktion und Rückfallmöglichkeiten testen

Alle drei Ebenen sind notwendig.

Eine technisch erfolgreiche Konfiguration allein beweist noch nicht, dass:

der vollständige Geltungsbereich geschützt ist,
Ausnahmen kontrolliert werden,
Benutzer unterstützt werden,
oder die Sicherheitsziele tatsächlich erreicht werden.

Verantwortung und Verantwortlichkeit

Im Deutschen wird der Begriff Verantwortung häufig für unterschiedliche Sachverhalte verwendet.

Für eine klare Rollenverteilung ist die Unterscheidung hilfreich zwischen:

Begriff	Bedeutung
Ausführungsverantwortung	eine Person oder Rolle führt eine Aufgabe aus
Entscheidungsverantwortung	eine Person oder Rolle besitzt die Befugnis, eine Entscheidung zu treffen
Ergebnisverantwortung	eine Person oder Rolle steht für das erreichte Ergebnis ein
Rechenschaftspflicht	eine Person oder ein Gremium muss Entscheidungen und Ergebnisse erklären und vertreten
Beratung	Fachwissen wird eingebracht, ohne selbst die endgültige Entscheidung zu treffen
Informationsbedarf	eine Person oder Rolle muss über Entscheidung oder Ergebnis informiert werden

Eine Person kann eine Aufgabe ausführen, ohne die endgültige Entscheidungs- oder Ergebnisverantwortung zu besitzen.

Beispiel:

Ein Systemadministrator setzt eine freigegebene Firewall-Regel um.

Der Administrator ist für die korrekte technische Ausführung verantwortlich.
Eine andere Rolle kann für die fachliche Anforderung verantwortlich sein.
Eine Sicherheitsrolle kann die Risikobewertung durchführen.
Eine autorisierte Rolle kann die Änderung genehmigen.
Ein Service Owner kann für die Auswirkungen auf den Service rechenschaftspflichtig sein.

Typischer Fehler

Die Person, die eine technische Änderung ausführt, wird automatisch für sämtliche geschäftlichen, rechtlichen und organisatorischen Entscheidungen verantwortlich gemacht.

Verantwortung muss eindeutig sein

Bei wichtigen Produkten, Services und Entscheidungen sollte erkennbar sein:

Wer besitzt die Entscheidungsbefugnis?
Wer führt die Aufgabe aus?
Wer prüft das Ergebnis?
Wer akzeptiert verbleibende Risiken?
Wer kommuniziert mit betroffenen Stakeholdern?
Wer aktualisiert die Dokumentation?
Wer überwacht die langfristige Wirksamkeit?
Wer eskaliert bei Abweichungen?

Unklare Verantwortung kann zu folgenden Situationen führen:

Jeder geht davon aus, dass ein anderer handelt.
Entscheidungen werden mehrfach oder widersprüchlich getroffen.
Risiken werden ohne erkennbare Autorisierung akzeptiert.
Probleme werden zwischen Teams weitergereicht.
Dokumentationen bleiben veraltet.
notwendige Eskalationen erfolgen zu spät.
niemand überprüft das Ende-zu-Ende-Ergebnis.

Praxistipp

Kann bei einer kritischen Aufgabe niemand eindeutig benennen, wer entscheidet und wer für das Ergebnis einsteht, besteht ein Governance- und Verantwortlichkeitsproblem.

Delegation und Rechenschaftspflicht

Aufgaben und Entscheidungsbefugnisse können delegiert werden.

Eine sinnvolle Delegation benötigt:

einen klaren Umfang,
bekannte Grenzen,
ausreichende Fachkenntnisse,
benötigte Ressourcen,
Zugang zu relevanten Informationen,
definierte Eskalationswege,
und eine geeignete Kontrolle.

Beispiel:

Ein Betriebsteam darf bestimmte dokumentierte Standardänderungen selbstständig durchführen.

Die Delegation kann festlegen:

welche Änderungen umfasst sind,
welche Voraussetzungen gelten,
wann keine zusätzliche Genehmigung notwendig ist,
welche Dokumentation erforderlich ist,
wann eskaliert werden muss,
und wie die Ergebnisse überwacht werden.

Wichtig

Delegation bedeutet nicht, dass keine Kontrolle mehr erforderlich ist.

Sie soll Entscheidungen dort ermöglichen, wo ausreichendes Wissen vorhanden ist und das Risiko angemessen beherrscht werden kann.

Entscheidungsbefugnisse

Entscheidungsbefugnisse sollten zum Risiko und zur Bedeutung einer Entscheidung passen.

Mögliche Entscheidungsbereiche sind:

Investitionen,
Produkt- und Serviceprioritäten,
Sicherheitsausnahmen,
Change-Autorisierung,
Risikoakzeptanz,
Lieferantenauswahl,
Datenverarbeitung,
Notfallmaßnahmen,
und Außerbetriebnahme von Systemen.

Eine Entscheidungsbefugnis sollte möglichst beantworten:

Wer darf entscheiden?
Für welchen Umfang?
Bis zu welcher Risikogrenze?
Welche Informationen werden benötigt?
Welche Beratung ist erforderlich?
Welche Entscheidung muss dokumentiert werden?
Wann ist eine höhere Instanz einzubeziehen?

Beispiel:

Ein Administrator darf einen abgestürzten Dienst nach einer dokumentierten Arbeitsanweisung neu starten.

Er darf möglicherweise nicht ohne zusätzliche Autorisierung:

die gesamte Serverplattform neu konfigurieren,
Sicherheitskontrollen deaktivieren,
Daten löschen,
oder einen nicht getesteten Change an einem kritischen Produktivsystem durchführen.

Autorisierung nach Risiko und Kontext

Nicht jede Entscheidung benötigt denselben Freigabeumfang.

Situation	Mögliche Behandlung
häufige, dokumentierte und risikoarme Standardtätigkeit	delegierte oder vorab autorisierte Ausführung
normale Änderung mit überschaubarem Risiko	Bewertung und Autorisierung durch zuständige Rolle
komplexe Änderung an kritischem Service	erweiterte fachliche, technische und geschäftliche Bewertung
dringende Sicherheitsmaßnahme	beschleunigtes Verfahren mit klarer Befugnis und nachträglicher Kontrolle
grundlegende strategische Änderung	Entscheidung durch entsprechend befugtes Governance-Gremium

Die konkrete Organisation legt fest:

welche Entscheidungsmodelle verwendet werden,
welche Risikokriterien gelten,
wer autorisieren darf,
und welche Nachweise erforderlich sind.

Typischer Fehler

Jede Änderung muss dieselben umfangreichen Genehmigungsstufen durchlaufen.

Dadurch werden risikoarme Tätigkeiten unnötig verzögert, während kritische Entscheidungen möglicherweise trotzdem nicht ausreichend fachlich bewertet werden.

Governance ist mehr als Genehmigung

Governance wird häufig fälschlich auf Freigaben reduziert.

Eine Freigabe beantwortet lediglich eine begrenzte Frage:

Darf diese konkrete Handlung innerhalb des festgelegten Rahmens durchgeführt werden?

Governance umfasst zusätzlich:

Ziele,
Strategien,
Verantwortung,
Risikogrenzen,
Leistung,
Regelkonformität,
Erfahrung,
Nachhaltigkeit,
und fortlaufende Kontrolle.

Ein Change kann formal genehmigt sein und dennoch schlecht gesteuert werden, wenn:

das Ziel unklar ist,
Auswirkungen nicht verstanden wurden,
das Ergebnis nicht geprüft wird,
Verantwortlichkeiten fehlen,
oder wiederholt dieselben Probleme entstehen.

Richtlinien, Standards und Arbeitsanweisungen unterscheiden

Governance-Vorgaben können auf unterschiedlichen Ebenen konkretisiert werden.

Dokumentenart	Zweck	Beispiel
Grundsatz oder Policy	legt Ziel, Richtung und verbindliche Erwartungen fest	administrative Zugriffe müssen angemessen geschützt werden
Standard	legt verbindliche einheitliche Anforderungen fest	zugelassene MFA-Verfahren und Mindestanforderungen
Prozess oder Ablauf	beschreibt zusammenhängende Aktivitäten und Verantwortlichkeiten	Beantragung und Freigabe eines administrativen Zugriffs
Verfahren	beschreibt eine festgelegte Vorgehensweise	Registrierung eines neuen MFA-Geräts
Arbeitsanweisung	beschreibt konkrete Ausführungsschritte	Menü- und Konfigurationsschritte im Identitätssystem
Checkliste	unterstützt die Kontrolle wichtiger Punkte	Prüfung eines neuen administrativen Kontos

Nicht jede Organisation verwendet exakt diese Bezeichnungen.

Entscheidend ist, dass:

Geltungsbereich,
Verbindlichkeit,
Verantwortlichkeit,
und erforderliche Handlung

eindeutig sind.

Beispiel: Backup-Governance

Governance-Vorgabe

Geschäftskritische Daten und Systeme müssen entsprechend ihrer Kritikalität gesichert und innerhalb definierter Ziele wiederhergestellt werden können.

Mögliche Standards

zulässige Sicherungsziele
Verschlüsselungsanforderungen
Aufbewahrungszeiten
Trennung von Produktiv- und Sicherungszugängen
Anforderungen an unveränderbare Sicherungen
Häufigkeit von Wiederherstellungstests

Management

plant Backup-Infrastruktur
weist Verantwortlichkeiten zu
organisiert Lizenzen und Speicher
koordiniert Tests
bewertet Kapazität und Kosten
berichtet über Abweichungen

Technische Umsetzung

Backup-Jobs konfigurieren
Zugangsdaten absichern
Zeitpläne einrichten
Warnungen konfigurieren
Wiederherstellungen testen
Ergebnisse dokumentieren

Governance-Monitoring

Sind alle kritischen Systeme erfasst?
Sind Wiederherstellungen erfolgreich?
Werden Zielzeiten erreicht?
Werden Fehler zeitnah behandelt?
Sind verbleibende Risiken akzeptiert?
Werden Verbesserungen umgesetzt?

Risikobereitschaft und Risikotoleranz

Governance legt fest, welche Risiken:

akzeptiert,
reduziert,
übertragen,
vermieden,
oder weiter beobachtet

werden.

Die Organisation kann dafür Risikogrenzen definieren.

Beispiele:

maximal tolerierbare Ausfallzeit
maximal akzeptabler Datenverlust
zulässige Lieferantenabhängigkeit
notwendiger Freigabeumfang
erforderliche Sicherheitskontrollen
maximale finanzielle Auswirkung
zulässige Restunsicherheit bei einer Einführung

Ein technisches Team sollte verbleibende erhebliche Risiken nicht ohne entsprechende Befugnis selbst akzeptieren.

Beispiel:

Ein Administrator stellt fest, dass ein veraltetes System keine Sicherheitsupdates mehr erhält.

Er kann:

die technische Situation dokumentieren,
mögliche Maßnahmen vorschlagen,
Auswirkungen bewerten,
kurzfristige Schutzmaßnahmen umsetzen,
und das Risiko eskalieren.

Die Entscheidung, ein erhebliches Restrisiko langfristig zu akzeptieren, benötigt eine entsprechend befugte Rolle.

Merke

Risikoanalyse kann durch Fachkräfte erfolgen.

Risikoakzeptanz muss durch eine dafür autorisierte Stelle erfolgen.

Kontrollen

Eine Kontrolle soll ein Risiko reduzieren, eine Vorgabe sicherstellen oder eine Abweichung erkennbar machen.

Kontrollen können sein:

vorbeugend,
erkennend,
korrigierend,
manuell,
technisch automatisiert,
organisatorisch,
oder eine Kombination daraus.

Kontrollart	Beispiel
Vorbeugend	MFA verhindert Anmeldung nur mit Kennwort
Erkennend	Monitoring erkennt abgelaufenes Zertifikat
Korrigierend	dokumentiertes Wiederherstellungsverfahren
Manuell	Vier-Augen-Prüfung einer kritischen Änderung
Automatisiert	Richtlinie blockiert unsichere Konfiguration
Organisatorisch	Funktionstrennung zwischen Beantragung und Genehmigung

Eine Kontrolle sollte hinsichtlich ihrer Wirksamkeit bewertet werden.

Fragen dazu:

Welches Risiko behandelt die Kontrolle?
Ist sie vollständig umgesetzt?
Kann sie umgangen werden?
Erzeugt sie neue Risiken?
Wird ihre Funktion regelmäßig geprüft?
Ist der Aufwand angemessen?
Gibt es Ausnahmen?
Werden Abweichungen verfolgt?

Messgrößen und Governance

Governance benötigt Informationen, um Leistung und Risiken bewerten zu können.

Kennzahlen sollten jedoch nicht isoliert betrachtet werden.

Beispiel:

98 Prozent aller Tickets wurden innerhalb der Zielzeit geschlossen.

Diese Zahl beantwortet nicht automatisch:

Waren die Lösungen nachhaltig?
Wurden Tickets voreilig geschlossen?
Mussten Benutzer erneut Kontakt aufnehmen?
Wurden wichtige Incidents angemessen priorisiert?
Wurde das erwartete Outcome erreicht?
Sind die Zielzeiten selbst sinnvoll?

Geeignete Governance-Informationen können umfassen:

erreichte Outcomes,
Serviceleistung,
Benutzer- und Kundenerfahrung,
Risiken und Abweichungen,
Sicherheitsvorfälle,
wiederkehrende Incidents,
Wirksamkeit von Verbesserungen,
Kostenentwicklung,
Lieferantenleistung,
Wiederherstellungstests,
und Einhaltung verbindlicher Anforderungen.

Typischer Fehler

Eine einzelne leicht messbare Kennzahl wird zum alleinigen Steuerungsziel.

Mitarbeiter optimieren anschließend die Kennzahl, ohne den tatsächlichen Wert zu verbessern.

Verantwortlichkeit für Produkte und Services

Für wichtige Produkte und Services sollten Verantwortlichkeiten geklärt sein.

Mögliche Rollen können sein:

Product Owner,
Product Manager,
Service Owner,
Service Manager,
technische Systemverantwortliche,
Information Owner,
Process Owner,
Practice Owner,
Supplier Manager,
Risk Owner,
und Informationssicherheitsverantwortliche.

ITIL schreibt nicht für jede Organisation dieselben Rollenbezeichnungen oder Organisationsstrukturen vor.

Entscheidend ist, dass folgende Fragen beantwortet werden:

Wer verantwortet das Produkt?
Wer verantwortet den Service?
Wer entscheidet über Prioritäten?
Wer verantwortet technische Komponenten?
Wer akzeptiert Risiken?
Wer verantwortet Daten?
Wer steuert Lieferanten?
Wer überwacht die Leistung?
Wer treibt Verbesserungen voran?

Wichtig

Eine Rollenbezeichnung allein schafft noch keine wirksame Verantwortung.

Die Rolle benötigt Befugnisse, Informationen, Fähigkeiten und Ressourcen.

Service Owner und technische Verantwortung unterscheiden

Ein Service Owner betrachtet den Service normalerweise aus einer Ende-zu-Ende-Perspektive.

Technische Verantwortliche betreuen dagegen möglicherweise einzelne Bestandteile.

Beispiel: E-Mail-Service

Verantwortungsbereich	Mögliche Zuständigkeit
gesamter E-Mail-Service	Service Owner
Identitätsplattform	Identity-Team
DNS	Netzwerk- oder Infrastrukturteam
Mailplattform	Messaging-Team oder Cloud-Provider
Endgeräte und Client	Workplace-Team
Sicherheitsanforderungen	Informationssicherheit
Lieferantenvertrag	Supplier Management oder Einkauf
Benutzerunterstützung	Service Desk

Der Service Owner muss nicht jede technische Tätigkeit selbst ausführen.

Er benötigt jedoch ausreichende Informationen, um:

Serviceleistung zu bewerten,
Abhängigkeiten zu verstehen,
Risiken zu eskalieren,
Prioritäten abzustimmen,
und Verbesserungen zu unterstützen.

RACI als mögliches Hilfsmittel

Eine RACI-Matrix kann helfen, Rollen bei einer Tätigkeit zu klären.

Kürzel	Bedeutung
R – Responsible	führt die Aufgabe aus
A – Accountable	steht für das Ergebnis ein und besitzt die übergeordnete Verantwortlichkeit
C – Consulted	wird vor oder während der Entscheidung fachlich einbezogen
I – Informed	wird über Entscheidung oder Ergebnis informiert

Beispiel: produktive Firewall-Änderung

Rolle	Zuordnung
Netzwerkadministrator	Responsible
autorisierte Change- oder Service-Rolle	Accountable
Informationssicherheit und Anwendungsverantwortlicher	Consulted
Service Desk und betroffene Benutzergruppen	Informed

Eine RACI-Matrix ist ein mögliches Organisationswerkzeug und keine zwingend vorgeschriebene ITIL-Darstellung.

Bei der Verwendung sollte vermieden werden:

mehrere unklare Accountable-Zuordnungen,
fehlende ausführende Verantwortung,
Beteiligung zu vieler Personen,
veraltete Rollenzuordnungen,
und eine Matrix ohne praktische Anwendung.

Eskalation

Eskalation ist notwendig, wenn:

eine Entscheidung außerhalb der eigenen Befugnis liegt,
ein Risiko die eigene Entscheidungsgrenze überschreitet,
vereinbarte Ziele gefährdet sind,
benötigte Ressourcen fehlen,
Verantwortlichkeiten unklar bleiben,
ein Konflikt nicht gelöst werden kann,
eine Sicherheits- oder Datenschutzverletzung möglich ist,
oder eine verbindliche Vorgabe nicht eingehalten werden kann.

Eskalation bedeutet nicht automatisch persönliches Versagen.

Sie ist ein vorgesehener Mechanismus, um Entscheidungen an die geeignete Verantwortungs- und Befugnisebene zu übergeben.

Praxistipp

Eine gute Eskalation enthält:

konkrete Situation,

bekannte Auswirkungen,

bisherige Maßnahmen,

bestehendes Risiko,

benötigte Entscheidung,

mögliche Optionen,

und den spätesten sinnvollen Entscheidungszeitpunkt.

Ungeeignete Eskalation:

Das System funktioniert nicht. Bitte entscheiden.

Besser:

Der zentrale Dateiservice ist seit 09:10 Uhr für zwei Standorte nicht erreichbar. Die lokale Wiederherstellung war erfolglos. Eine Umschaltung auf das Ersatzsystem ist möglich, kann aber Datenänderungen der letzten 15 Minuten verlieren. Benötigt wird die Entscheidung, ob die Umschaltung durchgeführt und der mögliche Datenverlust akzeptiert wird.

Governance bei Incidents

Governance bestimmt unter anderem den Rahmen für:

Priorisierung,
Eskalation,
Major-Incident-Kriterien,
Kommunikation,
Entscheidungsbefugnisse,
Sicherheitsmeldungen,
und Risikoakzeptanz.

Bei einem kritischen Incident sollte geklärt sein:

Wer darf ein Major-Incident-Verfahren aktivieren?
Wer übernimmt die Koordination?
Wer darf Notfallmaßnahmen autorisieren?
Wer informiert Führungskräfte, Kunden oder Behörden?
Welche Risiken dürfen kurzfristig akzeptiert werden?
Wer entscheidet über eine Wiederherstellung mit möglichen Nebenwirkungen?
Welche Dokumentation ist zwingend erforderlich?
Wann muss eine nachgelagerte Überprüfung stattfinden?

Governance soll die Wiederherstellung nicht unnötig verzögern.

Entscheidungsrechte und Notfallverfahren sollten deshalb vor einem Incident vorbereitet werden.

Governance bei Changes

Governance legt den Rahmen fest, innerhalb dessen Changes bewertet und autorisiert werden.

Dazu können gehören:

Change-Modelle,
Risikokriterien,
Entscheidungsbefugnisse,
Funktionstrennung,
notwendige Tests,
Rückfallplanung,
Dokumentation,
und nachgelagerte Überprüfung.

Nicht jeder Change benötigt dieselben Beteiligten oder dasselbe Gremium.

Die Autorisierung sollte sich richten nach:

Risiko,
Auswirkungen,
Komplexität,
Unsicherheit,
betroffenen Services,
und betrieblichen Vorgaben.

Typischer Fehler

Ein Change Advisory Board wird als zentrale Freigabestelle für jede kleine Änderung verwendet.

Dadurch können unnötige Verzögerungen entstehen, ohne dass kritische Changes automatisch besser bewertet werden.

Governance bei Lieferanten

Externe Lieferanten können einen wesentlichen Teil eines Produkts oder Service bereitstellen.

Governance sollte unter anderem klären:

Welche Leistung wird erwartet?
Welche Risiken entstehen durch die Abhängigkeit?
Welche Daten verarbeitet der Lieferant?
Welche Sicherheitsanforderungen gelten?
Welche Unterauftragnehmer werden eingesetzt?
Wie wird die Leistung gemessen?
Welche Eskalationswege bestehen?
Welche Rechte bestehen bei Leistungsabweichungen?
Wie können Daten und Services zurückgeführt werden?
Was geschieht bei Vertragsende oder Ausfall des Lieferanten?

Merke

Die Auslagerung einer Tätigkeit überträgt nicht automatisch die gesamte Verantwortung für das Ergebnis oder die Risiken an den Lieferanten.

Governance bei künstlicher Intelligenz

ITIL Version 5 berücksichtigt ausdrücklich AI-gestützte Produkte, Services und Arbeitsweisen.

Governance für KI kann unter anderem behandeln:

zulässige Anwendungsfälle,
Verantwortlichkeit,
verwendete Daten,
Datenschutz,
Informationssicherheit,
Transparenz,
Nachvollziehbarkeit,
Verzerrungen,
menschliche Kontrolle,
Qualität der Ergebnisse,
Überwachung,
und gesetzliche Anforderungen.

Vor dem Einsatz einer KI-Lösung sollte unter anderem geprüft werden:

Welches Outcome soll unterstützt werden?
Welche Entscheidungen darf die KI beeinflussen?
Welche Daten werden eingegeben oder gespeichert?
Können vertrauliche Informationen offengelegt werden?
Wie werden falsche Ergebnisse erkannt?
Wer prüft kritische Entscheidungen?
Wie werden Modelle oder Anbieteränderungen überwacht?
Kann die Funktion bei Problemen deaktiviert werden?
Wer trägt die Ergebnisverantwortung?

Sicherheitsrelevant

Die Verwendung einer KI-Lösung überträgt die Verantwortung für Entscheidungen und Folgen nicht automatisch auf das technische System oder den Anbieter.

Governance und Continual Improvement

Governance und Continual Improvement unterstützen sich gegenseitig.

Governance gibt unter anderem vor:

welche Ziele wichtig sind,
welche Risiken behandelt werden müssen,
welche Ergebnisse überwacht werden,
und welche Abweichungen nicht akzeptabel sind.

Continual Improvement nutzt unter anderem:

Leistungsdaten,
Feedback,
Auditergebnisse,
Incident-Erkenntnisse,
Risikobewertungen,
und Governance-Entscheidungen,

um Verbesserungen zu identifizieren und umzusetzen.

Beispiel:

Das Monitoring zeigt wiederholt, dass kritische Zertifikate erst kurz vor Ablauf erneuert werden.

Governance kann festlegen:

kritische Zertifikate müssen zentral erfasst werden,
Verantwortlichkeiten müssen eindeutig sein,
Warnfristen müssen definiert werden,
und die Einhaltung muss überwacht werden.

Continual Improvement entwickelt und verbessert anschließend:

Erfassung,
Alarmierung,
Arbeitsabläufe,
Automatisierung,
und Erfolgskontrolle.

Praxisbeispiel: Ausfall eines zentralen Speichersystems

Ein zentrales Speichersystem zeigt kritische Fehler.

Technische Situation

mehrere Hosts verwenden das Storage
erste Datenträger zeigen Fehler
ein Ersatzsystem ist vorhanden
eine Umschaltung kann kurzzeitige Unterbrechungen verursachen
der Datenstand des Ersatzsystems muss geprüft werden

Evaluate

Welche Services sind betroffen?
Wie hoch ist das Ausfallrisiko?
Welche Daten könnten verloren gehen?
Welche Alternativen bestehen?
Welche Auswirkungen besitzt eine sofortige Umschaltung?
Wie lange kann weiterbetrieben werden?

Direct

Welche Services müssen zuerst geschützt werden?
Wer darf die Umschaltung autorisieren?
Welche Unterbrechung wird akzeptiert?
Welche Stakeholder müssen informiert werden?
Welche Datenverlustrisiken dürfen nicht überschritten werden?

Monitor

Bleibt das Primärsystem stabil?
Ist die Replikation aktuell?
Funktioniert das Ersatzsystem?
Werden die Services nach der Umschaltung wiederhergestellt?
Werden alle offenen Risiken nachverfolgt?

Mögliche Verantwortlichkeiten

Storage-Administrator: technische Analyse und Umsetzung
Service Owner: Bewertung der Serviceauswirkungen
Informationssicherheit oder Datenverantwortlicher: Bewertung des Datenrisikos
Incident-Koordination: Koordination und Kommunikation
autorisierte Entscheidungsrolle: Freigabe der risikobehafteten Umschaltung

Dieses Beispiel zeigt, dass technische Kompetenz, Management und Governance zusammenwirken müssen.

Typische Governance-Fehler

Fehler 1: Verantwortung ohne Befugnis

Eine Person soll für ein Ergebnis einstehen, besitzt aber keine Möglichkeit:

Entscheidungen zu treffen,
Ressourcen zu erhalten,
Informationen einzufordern,
oder Risiken zu eskalieren.

Fehler 2: Befugnis ohne Kontrolle

Eine Rolle darf weitreichende Entscheidungen treffen, ohne:

Ergebnisse dokumentieren,
Risiken begründen,
oder über Auswirkungen berichten

zu müssen.

Fehler 3: Governance nur als Genehmigung verstehen

Viele Freigaben werden eingeführt, aber Ziele, Verantwortlichkeiten und Erfolgskriterien bleiben unklar.

Fehler 4: Jede Entscheidung zentralisieren

Auch risikoarme Tätigkeiten benötigen hochrangige Genehmigungen.

Dadurch entstehen:

Verzögerungen,
Überlastung,
Umgehungslösungen,
und unklare operative Verantwortung.

Fehler 5: Risiken ohne Befugnis akzeptieren

Ein technisches Team dokumentiert ein erhebliches Risiko, entscheidet aber eigenständig, es dauerhaft zu akzeptieren.

Fehler 6: Nur technische Leistung überwachen

Server und Anwendungen sind verfügbar, aber:

Benutzer können ihre Aufgaben nicht ausführen,
Lieferanten erfüllen Vereinbarungen nicht,
oder Sicherheitsrisiken bleiben unbehandelt.

Fehler 7: Dokumentation mit Wirksamkeit verwechseln

Eine Richtlinie existiert, wird aber:

nicht verstanden,
nicht umgesetzt,
nicht kontrolliert,
oder durch Ausnahmen vollständig umgangen.

Fehler 8: Verantwortung bleibt an Teamgrenzen hängen

Jedes Team erfüllt seine Komponentenaufgabe, aber niemand verantwortet das Ende-zu-Ende-Ergebnis des Service.

Fehler 9: Governance nicht an Veränderungen anpassen

Entscheidungsmodelle und Kontrollen bleiben unverändert, obwohl sich:

Technologie,
Risiken,
Organisationsstruktur,
oder gesetzliche Anforderungen

verändert haben.

Fragen für eine neue Organisation

Beim Einstieg in eine neue IT-Organisation solltest du klären:

Welche Governance-Gremien existieren?
Wer bestimmt strategische IT-Ziele?
Wer verantwortet wichtige Produkte und Services?
Wer darf Risiken akzeptieren?
Wer darf produktive Changes autorisieren?
Welche Tätigkeiten sind delegiert oder vorab autorisiert?
Welche Sicherheitsrichtlinien gelten?
Welche Eskalationswege bestehen?
Wie werden kritische Entscheidungen dokumentiert?
Welche Kennzahlen werden überwacht?
Wie werden Lieferanten gesteuert?
Wie werden Ausnahmen behandelt?
Wie werden Verbesserungen priorisiert?
Wie werden Major Incidents gesteuert?
Welche Notfallbefugnisse bestehen?

Entscheidungshilfe: Ist eine Governance-Entscheidung notwendig?

Eine Governance- oder übergeordnete Entscheidung kann erforderlich sein, wenn:

mehrere Produkte oder Services betroffen sind,
eine Entscheidung strategische Auswirkungen besitzt,
erhebliche finanzielle Mittel benötigt werden,
ein wesentliches Risiko akzeptiert werden soll,
gesetzliche oder vertragliche Anforderungen betroffen sind,
mehrere Verantwortungsbereiche im Konflikt stehen,
eine grundlegende Richtlinie geändert werden soll,
kritische Lieferantenabhängigkeiten entstehen,
oder eine Entscheidung außerhalb bestehender Befugnisse liegt.

Eine operative Entscheidung kann dagegen innerhalb delegierter Befugnisse getroffen werden, wenn:

Ziel und Rahmen eindeutig sind,
das Risiko innerhalb festgelegter Grenzen liegt,
ausreichende Fachkenntnisse vorhanden sind,
und die notwendige Dokumentation und Kontrolle sichergestellt sind.

Checkliste für klare Verantwortlichkeiten

Checkliste für wirksame Governance

Schnellreferenz

Frage	Governance-Bezug
Was wird benötigt?	Evaluate
Welche Optionen und Risiken bestehen?	Evaluate
Welches Ziel und welche Grenzen gelten?	Direct
Wer darf entscheiden?	Direct
Wer trägt die Ergebnisverantwortung?	Direct
Werden Vorgaben eingehalten?	Monitor
Werden Outcomes erreicht?	Monitor
Bleiben Risiken innerhalb akzeptierter Grenzen?	Monitor
Müssen Richtung oder Vorgaben angepasst werden?	erneutes Evaluate und Direct

Zusammenfassende Darstellung

Bedürfnisse, Ziele, Risiken und Rahmenbedingungen
↓
Evaluate
Situation und Optionen bewerten
↓
Direct
Richtung, Verantwortung und Grenzen vorgeben
↓
Management und technische Umsetzung
↓
Monitor
Ergebnisse, Risiken und Einhaltung überwachen
↓
Feedback, Abweichungen und neue Anforderungen
↓
erneute Bewertung und Anpassung

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen
Change Management
Information Security Management
Risk Management
Supplier Management
Service Level Management

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zur Einbindung von Governance in das ITIL Value System sowie zu den Governance-Aktivitäten Evaluate, Direct und Monitor wurden anhand offizieller PeopleCert- und ITIL-Unterlagen geprüft.

Die Ausführungen zu:

Entscheidungsbefugnissen,
Verantwortung,
RACI,
Richtlinien,
Kontrollen,
Eskalation,
Lieferanten,
Backup-Governance,
und den dargestellten Praxisfällen

sind zusätzliche herstellerneutrale Erläuterungen und Praxisempfehlungen dieses unabhängigen Nachschlagewerks.

Eine RACI-Matrix ist ein mögliches Hilfsmittel zur Rollenklärung, aber keine zwingend vorgeschriebene ITIL-Struktur.

Konkrete Governance-Gremien, Rollenbezeichnungen, Freigabestufen und Risikogrenzen müssen von der jeweiligen Organisation festgelegt werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.5 Die vier Dimensionen des Produkt- und Service-Managements

Kurz erklärt

Die vier Dimensionen unterstützen eine ganzheitliche Betrachtung digitaler Produkte und Services.

Sie helfen dabei, nicht ausschließlich auf Technik, Prozesse oder einzelne Teams zu schauen.

Die vier Dimensionen sind:

Organizations and People – Organisationen und Menschen

Information and Technology – Informationen und Technologie

Partners and Suppliers – Partner und Lieferanten

Value Streams and Processes – Wertströme und Prozesse

Bei Entscheidungen, Änderungen, Störungen und Verbesserungen sollten alle vier Dimensionen berücksichtigt werden.

Warum die vier Dimensionen notwendig sind

Digitale Produkte und Services entstehen durch das Zusammenwirken unterschiedlicher Bestandteile.

Dazu gehören beispielsweise:

Menschen,
Rollen,
Wissen,
Informationen,
Anwendungen,
Infrastruktur,
Prozesse,
Wertströme,
Lieferanten,
Verträge,
Sicherheitsanforderungen,
und organisatorische Entscheidungen.

Eine technische Lösung kann leistungsfähig sein und trotzdem keinen ausreichenden Wert ermöglichen.

Beispiele:

Eine Anwendung funktioniert, aber niemand ist für ihren Support verantwortlich.
Ein Monitoring-System erkennt Fehler, aber Warnungen werden nicht bearbeitet.
Ein Cloud-Service ist verfügbar, aber der Vertrag enthält keine geeignete Ausstiegsregelung.
Ein Prozess ist ausführlich dokumentiert, wird aber von den Mitarbeitern nicht verstanden.
Eine neue Plattform besitzt viele Funktionen, lässt sich aber nicht in die vorhandene Umgebung integrieren.
Ein Service erfüllt technische Messwerte, unterstützt aber das benötigte Outcome nicht.

Die vier Dimensionen helfen dabei, solche Lücken frühzeitig zu erkennen.

Merke

Ein Produkt oder Service ist nur so wirksam wie das Zusammenspiel seiner organisatorischen, technischen, menschlichen und externen Bestandteile.

Die vier Dimensionen im Überblick

Dimension	Zentrale Betrachtung
Organizations and People	Rollen, Fähigkeiten, Kapazitäten, Kommunikation, Kultur und Organisationsstruktur
Information and Technology	Informationen, Wissen, Daten, Anwendungen, Infrastruktur, Integration und Automatisierung
Partners and Suppliers	externe Leistungen, Lieferantenbeziehungen, Verträge, Abhängigkeiten und Zusammenarbeit
Value Streams and Processes	Ende-zu-Ende-Arbeitsfluss, Aktivitäten, Übergaben, Kontrollen und Ergebnisse

Die Dimensionen sind keine voneinander getrennten Bereiche.

Eine Entscheidung in einer Dimension beeinflusst häufig auch die anderen drei Dimensionen.

Die Dimensionen sind Betrachtungsperspektiven

Die vier Dimensionen sind:

keine vier Abteilungen,
keine vier aufeinanderfolgenden Prozessschritte,
keine vier Reifegrade,
und keine voneinander unabhängigen Managementsysteme.

Sie dienen als Perspektiven, mit denen ein Produkt, Service, Wertstrom, Problem oder Vorhaben untersucht werden kann.

Beispiel:

Eine Organisation führt eine neue Plattform für die zentrale Dateiablage ein.

Organizations and People

Wer verwaltet die Plattform?
Wer unterstützt die Benutzer?
Welche Fähigkeiten werden benötigt?
Wer genehmigt Zugriffe?

Information and Technology

Welche Daten werden gespeichert?
Wie werden Berechtigungen technisch umgesetzt?
Welche Schnittstellen bestehen?
Wie werden Backup und Wiederherstellung realisiert?

Partners and Suppliers

Wird ein Cloud-Anbieter verwendet?
Welche Leistungen werden vertraglich zugesichert?
Wie werden Störungen eskaliert?
Wie können Daten bei Vertragsende exportiert werden?

Value Streams and Processes

Wie werden neue Zugriffe beantragt?
Wie werden Freigaben erteilt?
Wie werden Berechtigungen entfernt?
Wie werden Incidents und Service Requests bearbeitet?

Erst die gemeinsame Betrachtung ergibt ein vollständigeres Bild.

Nicht jede Dimension benötigt immer denselben Aufwand

Alle vier Dimensionen sollten berücksichtigt werden.

Das bedeutet jedoch nicht, dass sie bei jeder Aufgabe gleich ausführlich dokumentiert werden müssen.

Beispiel:

Bei einer einfachen, dokumentierten Standardtätigkeit kann eine kurze Prüfung ausreichen.

Bei der Einführung einer geschäftskritischen Cloud-Plattform kann dagegen eine umfangreiche Betrachtung notwendig sein.

Der erforderliche Umfang hängt unter anderem ab von:

Bedeutung des betroffenen Produkts oder Service,
Anzahl der betroffenen Stakeholder,
Risiko,
Komplexität,
gesetzlichen und vertraglichen Anforderungen,
Sicherheitsanforderungen,
Neuartigkeit der Lösung,
Lieferantenabhängigkeit,
und möglicher Auswirkung eines Fehlers.

Grundsatz

Alle vier Dimensionen berücksichtigen, aber den Prüf- und Dokumentationsaufwand an Risiko und Kontext anpassen.

1. Organizations and People

Die Dimension Organizations and People betrachtet die organisatorischen und menschlichen Voraussetzungen für wirksames Produkt- und Service-Management.

Dazu gehören unter anderem:

Organisationsstruktur,
Rollen,
Verantwortlichkeiten,
Entscheidungsbefugnisse,
Fähigkeiten,
Kompetenzen,
Personalkapazität,
Kommunikation,
Zusammenarbeit,
Führung,
Kultur,
Motivation,
und gemeinsame Werte.

Technische Systeme werden von Menschen:

geplant,
entwickelt,
beschafft,
konfiguriert,
betrieben,
unterstützt,
überwacht,
verwendet,
und verbessert.

Eine technisch geeignete Lösung kann deshalb scheitern, wenn die menschlichen und organisatorischen Voraussetzungen fehlen.

Organisationen sind mehr als Organigramme

Ein Organigramm zeigt formale Strukturen.

Es beantwortet jedoch nicht automatisch:

Wie werden Entscheidungen tatsächlich getroffen?
Wer besitzt notwendiges Fachwissen?
Wer übernimmt bei einem Incident die Koordination?
Wie arbeiten Teams miteinander?
Welche informellen Abhängigkeiten bestehen?
Wo entstehen Konflikte oder Verzögerungen?
Können Mitarbeiter Probleme offen ansprechen?
Werden Erfahrungen und Fehler für Verbesserungen genutzt?

Für die Bewertung dieser Dimension müssen deshalb sowohl formale als auch tatsächlich gelebte Arbeitsweisen betrachtet werden.

Typischer Fehler

Eine Rolle ist im Organigramm eingetragen, besitzt aber weder ausreichende Befugnisse noch Zeit, Informationen oder Ressourcen, um ihre Verantwortung wahrzunehmen.

Rollen und Verantwortlichkeiten

Für wichtige Produkte, Services und Tätigkeiten sollte geklärt sein:

Wer entscheidet?
Wer führt die Tätigkeit aus?
Wer steht für das Ergebnis ein?
Wer muss fachlich beteiligt werden?
Wer muss informiert werden?
Wer darf Risiken akzeptieren?
Wer koordiniert bei Störungen?
Wer pflegt Dokumentationen?
Wer treibt Verbesserungen voran?

Mögliche Rollen sind beispielsweise:

Product Owner,
Product Manager,
Service Owner,
Service Manager,
Systemadministrator,
Netzwerkadministrator,
Service-Desk-Mitarbeiter,
Information Owner,
Supplier Manager,
Informationssicherheitsverantwortlicher,
und Change-Verantwortlicher.

ITIL schreibt nicht vor, dass jede Organisation genau diese Rollenbezeichnungen verwenden muss.

Entscheidend ist, dass Verantwortung, Befugnis und erwartetes Ergebnis eindeutig sind.

Fähigkeiten und Kompetenzen

Eine Organisation benötigt nicht nur ausreichend Personal, sondern auch geeignete Fähigkeiten.

Dazu können gehören:

technisches Fachwissen,
Produktwissen,
Serviceverständnis,
Fehleranalyse,
Kommunikation,
Risikobewertung,
Dokumentation,
Lieferantensteuerung,
Informationssicherheit,
Automatisierung,
Datenanalyse,
und Entscheidungsfähigkeit.

Bei einer neuen Technologie sollte deshalb nicht nur geprüft werden:

Kann das Produkt beschafft oder installiert werden?

Zusätzlich ist zu prüfen:

Wer kann es betreiben?
Wer kann Fehler analysieren?
Wer kann die Sicherheit bewerten?
Wer übernimmt Bereitschaft und Support?
Wie wird Wissen aufgebaut?
Wie wird Wissen bei Personalwechsel erhalten?
Welche Fähigkeiten müssen intern vorhanden bleiben?
Welche Fähigkeiten können extern bezogen werden?

Merke

Eine Organisation besitzt eine Fähigkeit nicht allein deshalb, weil sie ein Werkzeug gekauft hat.

Kapazität und Arbeitsbelastung

Auch fachlich geeignete Mitarbeiter können ihre Aufgaben nicht wirksam erfüllen, wenn ausreichende Kapazität fehlt.

Anzeichen für Kapazitätsprobleme können sein:

Tickets bleiben lange unbearbeitet.
Dokumentationen werden dauerhaft verschoben.
Wartungsarbeiten finden nicht statt.
Verbesserungen werden immer wieder abgebrochen.
Mitarbeiter reagieren nur noch auf akute Störungen.
Wissen konzentriert sich auf einzelne Personen.
Vertretungen fehlen.
Bereitschaftsdienste sind dauerhaft überlastet.
Sicherheitsmaßnahmen werden aus Zeitmangel nicht umgesetzt.

Kapazität sollte deshalb nicht nur anhand der Anzahl von Mitarbeitern bewertet werden.

Zu berücksichtigen sind außerdem:

benötigte Fähigkeiten,
Arbeitsmenge,
Komplexität,
Automatisierungsgrad,
Servicezeiten,
Bereitschaftsanforderungen,
Urlaubs- und Krankheitsvertretung,
und ungeplante Arbeit.

Kommunikation und Zusammenarbeit

Digitale Produkte und Services überschreiten häufig Team- und Organisationsgrenzen.

Eine wirksame Zusammenarbeit benötigt:

gemeinsame Ziele,
verständliche Begriffe,
geeignete Kommunikationswege,
sichtbare Zuständigkeiten,
aktuelle Informationen,
nachvollziehbare Entscheidungen,
und funktionierende Eskalationswege.

Mögliche Kommunikationsprobleme sind:

Teams verwenden dieselben Begriffe mit unterschiedlicher Bedeutung.
Informationen werden nur in privaten Chats weitergegeben.
technische Änderungen werden dem Service Desk nicht mitgeteilt.
Lieferanten erhalten unvollständige Fehlerbeschreibungen.
Benutzer bekommen widersprüchliche Statusmeldungen.
Entscheidungen werden nicht dokumentiert.
Wissen wird erst weitergegeben, wenn eine Schlüsselperson ausfällt.

Praxistipp

Die Qualität der Zusammenarbeit zeigt sich besonders an Übergaben, Störungen und Änderungen.

Organisationskultur

Kultur beeinflusst, wie Menschen tatsächlich handeln.

Sie zeigt sich beispielsweise darin:

ob Fehler offen gemeldet werden,
ob Risiken angesprochen werden dürfen,
ob Teams Wissen teilen,
ob Verantwortlichkeiten übernommen werden,
ob Probleme nur einzelnen Personen zugeschrieben werden,
ob Benutzerfeedback ernst genommen wird,
und ob Verbesserungen dauerhaft unterstützt werden.

Eine Organisation kann offiziell Zusammenarbeit fördern und gleichzeitig durch ihre tatsächliche Arbeitsweise Konkurrenz zwischen Teams erzeugen.

Beispiel:

Teams werden ausschließlich nach ihrer eigenen Bearbeitungszeit bewertet.

Dadurch kann jedes Team versuchen, Vorgänge möglichst schnell weiterzugeben.

Die lokale Kennzahl verbessert sich, während sich die gesamte Bearbeitungsdauer für den Benutzer verlängert.

Leitfragen zu Organizations and People

Sind Rollen und Verantwortlichkeiten eindeutig?
Besitzen die Rollen ausreichende Befugnisse?
Sind notwendige Fähigkeiten vorhanden?
Gibt es ausreichende Kapazität?
Wie werden Wissen und Erfahrung weitergegeben?
Funktionieren Vertretungen?
Sind Kommunikations- und Eskalationswege bekannt?
Unterstützt die Organisationskultur Zusammenarbeit?
Werden Mitarbeiter bei Veränderungen angemessen einbezogen?
Verstehen die Beteiligten das angestrebte Outcome?
Sind Anreize und Kennzahlen auf den gesamten Wertstrom ausgerichtet?
Können Probleme und Risiken offen angesprochen werden?

2. Information and Technology

Die Dimension Information and Technology betrachtet die Informationen, das Wissen und die Technologien, die für Produkte und Services benötigt werden.

Dazu gehören beispielsweise:

Daten,
Dokumentationen,
Wissen,
Anwendungen,
Infrastruktur,
Netzwerke,
Cloud-Plattformen,
Datenbanken,
Schnittstellen,
Automatisierung,
Monitoring,
Kommunikationssysteme,
Sicherheitswerkzeuge,
und künstliche Intelligenz.

Informationen und Technologie unterstützen nahezu jede Tätigkeit im digitalen Produkt- und Service-Management.

Sie müssen jedoch zu den tatsächlichen Anforderungen und Fähigkeiten der Organisation passen.

Informationen als Arbeitsgrundlage

Geeignete Entscheidungen benötigen geeignete Informationen.

Beispiele:

Ein Incident benötigt Angaben zu Auswirkungen, Symptomen und betroffenen Services.
Ein Change benötigt Informationen zu Risiken, Abhängigkeiten und Rückfallmöglichkeiten.
Ein Service Owner benötigt Informationen über Leistung, Erfahrung und Risiken.
Ein Administrator benötigt aktuelle Konfigurationsinformationen.
Ein Lieferantenmanager benötigt Informationen über vereinbarte und tatsächlich erbrachte Leistungen.
Governance benötigt Informationen über Outcomes, Risiken und Regelkonformität.

Informationen sollten möglichst:

korrekt,
aktuell,
vollständig genug,
verständlich,
verfügbar,
geschützt,
nachvollziehbar,
und für den jeweiligen Zweck geeignet

sein.

Wichtig

Mehr Daten bedeuten nicht automatisch bessere Informationen.

Entscheidend ist, ob die Daten verständlich, zuverlässig und für eine konkrete Entscheidung nutzbar sind.

Datenqualität

Fehlerhafte oder veraltete Daten können zu falschen Entscheidungen führen.

Beispiele:

Ein ausgeschiedener Mitarbeiter besitzt weiterhin aktive Berechtigungen.
Eine CMDB enthält nicht mehr vorhandene Server.
Ein Servicekatalog nennt einen nicht mehr verantwortlichen Service Owner.
Ein Monitoring-System verwendet veraltete Schwellenwerte.
Eine Knowledge-Base beschreibt eine frühere Softwareversion.
Ein Asset-System enthält doppelte oder unvollständige Geräteinformationen.

Datenqualität sollte deshalb nicht nur bei der Erfassung, sondern über den gesamten Lebenszyklus betrachtet werden.

Zu klären ist:

Wer erzeugt die Daten?
Wer verwendet sie?
Wer ist für ihre Qualität verantwortlich?
Wann werden sie aktualisiert?
Wie werden Fehler erkannt?
Wann werden sie archiviert oder gelöscht?
Welche Quelle gilt als maßgeblich?

Information und Wissen unterscheiden

Informationen werden erst durch Einordnung und Erfahrung zu anwendbarem Wissen.

Beispiel:

Information

Der Dienst wurde innerhalb von drei Monaten zwölfmal neu gestartet.

Wissen

Die Neustarts treten regelmäßig nach einem bestimmten Speicheranstieg auf und stellen nur eine vorübergehende Wiederherstellung dar.

Anwendbare Erkenntnis

Die Ursache muss untersucht und eine dauerhafte Korrektur geplant werden.

Knowledge Management soll dabei helfen, relevante Informationen:

zu erfassen,
zu bewerten,
zu strukturieren,
auffindbar zu machen,
zu verwenden,
und aktuell zu halten.

Technologieauswahl

Eine Technologie sollte nicht nur anhand ihrer Funktionen bewertet werden.

Zu berücksichtigen sind beispielsweise:

benötigte Outcomes,
Kompatibilität,
Integrationen,
Skalierbarkeit,
Verfügbarkeit,
Sicherheit,
Datenschutz,
Bedienbarkeit,
Wartbarkeit,
Support,
Kosten,
Fähigkeiten der Mitarbeiter,
Lieferantenabhängigkeit,
Datenportabilität,
und Ablösung am Lebensende.

Typischer Fehler

Eine neue Technologie wird eingeführt, weil sie viele Funktionen besitzt.

Erst später wird festgestellt, dass sie nicht zu vorhandenen Arbeitsweisen, Fähigkeiten oder Schnittstellen passt.

Architektur und Integration

Digitale Produkte und Services bestehen häufig aus mehreren integrierten Systemen.

Zu berücksichtigen sind:

Datenflüsse,
APIs,
Protokolle,
Identitäten,
Berechtigungen,
Abhängigkeiten,
Schnittstellen,
Ausfallszenarien,
und Versionskompatibilität.

Beispiel:

Eine Anwendung kann technisch verfügbar sein, aber nicht nutzbar, wenn:

der Identitätsanbieter gestört ist,
DNS-Einträge fehlen,
ein Zertifikat abgelaufen ist,
eine API nicht erreichbar ist,
oder eine benötigte Lizenz nicht zugeordnet wurde.

Eine ganzheitliche Betrachtung erfordert deshalb Informationen über Ende-zu-Ende-Abhängigkeiten.

Informationssicherheit

Informationen und Technologien müssen angemessen geschützt werden.

Zu den grundlegenden Schutzzielen gehören insbesondere:

Vertraulichkeit,
Integrität,
Verfügbarkeit.

Je nach Kontext können außerdem relevant sein:

Authentizität,
Nachvollziehbarkeit,
Datenschutz,
Beweissicherheit,
und Widerstandsfähigkeit.

Bei technischen Entscheidungen sollte geprüft werden:

Welche Informationen werden verarbeitet?
Welchen Schutzbedarf besitzen sie?
Wer darf darauf zugreifen?
Wie werden Zugriffe kontrolliert?
Wie werden Daten übertragen und gespeichert?
Welche Protokollierung ist notwendig?
Wie werden Daten gesichert und wiederhergestellt?
Wann müssen Daten gelöscht werden?
Welche Sicherheitsvorfälle sind möglich?

Automatisierung

Automatisierung kann:

wiederkehrende Arbeit reduzieren,
Ergebnisse vereinheitlichen,
Fehler verringern,
Geschwindigkeit erhöhen,
und Skalierbarkeit verbessern.

Sie benötigt jedoch:

einen verstandenen Ablauf,
geeignete Eingabedaten,
klare Regeln,
Fehlerbehandlung,
Überwachung,
Verantwortlichkeit,
und eine Rückfallmöglichkeit.

Beispiel:

Eine automatisierte Benutzeranlage kann Konten, Lizenzen und Standardgruppen bereitstellen.

Die Automatisierung muss trotzdem klären:

Liegt eine gültige Anforderung vor?
Wurde der Zugriff genehmigt?
Sind die Personaldaten vollständig?
Existiert bereits ein Konto?
Was geschieht bei einem Teilfehler?
Wer prüft das Ergebnis?
Wie werden Ausnahmen behandelt?

Künstliche Intelligenz

KI kann bei digitalen Produkten und Services unter anderem eingesetzt werden für:

Klassifizierung,
Zusammenfassung,
Analyse,
Suche,
Mustererkennung,
Prognosen,
Vorschläge,
Automatisierung,
und Benutzerinteraktion.

Dabei müssen unter anderem betrachtet werden:

Datenqualität,
Datenschutz,
Informationssicherheit,
mögliche Verzerrungen,
Nachvollziehbarkeit,
Fehlerwahrscheinlichkeit,
menschliche Kontrolle,
Verantwortlichkeit,
Anbieterabhängigkeit,
und Überwachung der Ergebnisse.

Sicherheitsrelevant

Eine KI-generierte Antwort oder Entscheidung muss abhängig von ihrer möglichen Auswirkung angemessen geprüft werden.

Die Verantwortung verbleibt bei der Organisation und den zuständigen Rollen.

Technische Schulden

Technische Schulden entstehen, wenn kurzfristige Lösungen später zusätzlichen Aufwand oder Risiken verursachen.

Beispiele:

nicht unterstützte Softwareversionen,
manuelle Sonderkonfigurationen,
fehlende Automatisierung,
veraltete Schnittstellen,
unzureichende Tests,
fehlende Dokumentation,
oder dauerhaft eingesetzte Zwischenlösungen.

Technische Schulden sind nicht automatisch vollständig vermeidbar.

Sie sollten jedoch:

sichtbar,
bewertet,
priorisiert,
verantwortet,
und kontrolliert reduziert

werden.

Leitfragen zu Information and Technology

Welche Informationen werden benötigt?
Sind die Informationen korrekt, aktuell und geschützt?
Wer ist für die Datenqualität verantwortlich?
Welche Technologien unterstützen das Outcome?
Passen die Technologien zur vorhandenen Architektur?
Welche Integrationen und Abhängigkeiten bestehen?
Sind Sicherheit und Datenschutz berücksichtigt?
Sind Backup und Wiederherstellung vorbereitet?
Besitzen Mitarbeiter die notwendigen Fähigkeiten?
Welche Tätigkeiten können sinnvoll automatisiert werden?
Wie werden automatisierte oder KI-gestützte Ergebnisse kontrolliert?
Welche technischen Schulden bestehen?
Wie werden Systeme am Ende ihres Lebenszyklus abgelöst?

3. Partners and Suppliers

Die Dimension Partners and Suppliers betrachtet externe Organisationen und Personen, die an Produkten, Services oder Wertströmen beteiligt sind.

Dazu können gehören:

Hardwarehersteller,
Softwareanbieter,
Cloud-Provider,
Telekommunikationsanbieter,
Beratungsunternehmen,
Managed Service Provider,
Logistikunternehmen,
Wartungsdienstleister,
Schulungsanbieter,
und Unterauftragnehmer.

Viele Organisationen können digitale Produkte und Services nicht vollständig allein bereitstellen.

Externe Partner können:

Technologien,
Fachwissen,
Kapazitäten,
Infrastruktur,
Support,
Lizenzen,
oder vollständige Servicebestandteile

bereitstellen.

Partner und Lieferant unterscheiden

Die Begriffe können in Organisationen unterschiedlich verwendet werden.

Vereinfacht kann unterschieden werden:

Begriff	Mögliche Bedeutung
Lieferant	stellt vertraglich vereinbarte Produkte oder Leistungen bereit
Partner	arbeitet enger und möglicherweise längerfristig an gemeinsamen Outcomes mit

Ein Lieferant kann gleichzeitig ein strategischer Partner sein.

Entscheidend ist nicht nur die Bezeichnung, sondern:

welche Leistung erbracht wird,
welche Verantwortung besteht,
welche Abhängigkeit entsteht,
wie eng zusammengearbeitet wird,
und wie die Beziehung gesteuert wird.

Sourcing-Entscheidungen

Organisationen müssen entscheiden, welche Fähigkeiten und Leistungen sie:

intern aufbauen,
extern beschaffen,
gemeinsam mit Partnern erbringen,
oder vollständig als externen Service nutzen.

Mögliche Kriterien sind:

strategische Bedeutung,
vorhandene Fähigkeiten,
Kosten,
Geschwindigkeit,
Flexibilität,
Skalierbarkeit,
Sicherheitsanforderungen,
gesetzliche Anforderungen,
Kontrollbedarf,
Verfügbarkeit geeigneter Anbieter,
und Abhängigkeiten.

Typischer Fehler

Eine Tätigkeit wird ausschließlich wegen kurzfristig geringerer Kosten ausgelagert.

Langfristige Abhängigkeiten, Datenportabilität, interne Fähigkeiten und Ausstiegskosten werden nicht berücksichtigt.

Verträge und Vereinbarungen

Verträge und Vereinbarungen sollten die benötigten Outcomes unterstützen.

Mögliche Inhalte sind:

Leistungsumfang,
Verantwortlichkeiten,
Servicezeiten,
Qualitätsziele,
Sicherheitsanforderungen,
Datenschutz,
Eskalationswege,
Support,
Meldepflichten,
Wartungsbedingungen,
Datenstandort,
Unterauftragnehmer,
Auditmöglichkeiten,
Haftung,
Vertragsänderungen,
Kündigung,
Datenrückgabe,
und Übergangsunterstützung.

Eine vertraglich zugesicherte technische Verfügbarkeit beantwortet nicht automatisch:

wie gut der Support funktioniert,
wie schnell ein kritischer Incident koordiniert wird,
wie Daten zurückgeführt werden,
oder ob der Service das benötigte Outcome ermöglicht.

Lieferantenabhängigkeiten

Externe Abhängigkeiten sollten sichtbar und bewertet sein.

Mögliche Risiken sind:

Ausfall eines einzelnen Anbieters,
fehlende alternative Anbieter,
proprietäre Datenformate,
schwer ersetzbare Schnittstellen,
Preissteigerungen,
Vertragsänderungen,
fehlende interne Kenntnisse,
eingeschränkte Datenportabilität,
nicht kontrollierte Unterauftragnehmer,
und lange Migrationszeiten.

Besonders kritisch kann eine Konzentration entstehen, wenn viele Produkte und Services von demselben Anbieter abhängen.

Beispiel:

Ein einziger Cloud-Anbieter stellt bereit:

Identitätsdienst,
E-Mail,
Dateiablage,
Kollaborationsplattform,
Gerätemanagement,
und Sicherheitsfunktionen.

Ein Ausfall oder Vertragsproblem kann dann mehrere zentrale Services gleichzeitig beeinflussen.

Geteilte Verantwortung

Bei extern bereitgestellten Services bleiben Verantwortlichkeiten häufig zwischen Anbieter und Kunde aufgeteilt.

Beispiel: Cloud-Service

Der Anbieter kann verantwortlich sein für:

Betrieb der Plattform,
physische Infrastruktur,
bestimmte Sicherheitsmaßnahmen,
und zugesicherte Verfügbarkeit.

Die nutzende Organisation kann weiterhin verantwortlich sein für:

Benutzerkonten,
Berechtigungen,
Konfiguration,
Datenklassifizierung,
Endgeräte,
sichere Nutzung,
und eigene Backups oder Exporte.

Die genaue Aufteilung hängt vom jeweiligen Produkt, Vertrag und Bereitstellungsmodell ab.

Merke

Eine ausgelagerte Tätigkeit bedeutet nicht automatisch, dass alle Risiken und Verantwortlichkeiten auf den Anbieter übergehen.

Lieferanten in Incidents

Bei einem Incident sollte geklärt sein:

Welcher Lieferant ist betroffen?
Welche Vertrags- oder Supportnummer wird benötigt?
Wer darf den Lieferanten kontaktieren?
Welche Informationen müssen übermittelt werden?
Welche Prioritätsstufen verwendet der Lieferant?
Welche Reaktions- und Lösungsziele gelten?
Wie erfolgt die Eskalation?
Wer koordiniert intern weiter?
Wie werden Benutzer informiert?
Wie werden Beweise und Protokolle gesichert?

Eine Supportanfrage an einen Lieferanten ersetzt nicht die interne Verantwortung für:

Koordination,
Kommunikation,
Risikobewertung,
und Überprüfung des gesamten Service.

Ausstiegs- und Übergangsplanung

Bereits bei der Auswahl eines Lieferanten sollte betrachtet werden, wie die Beziehung später verändert oder beendet werden kann.

Zu prüfen sind:

Können Daten vollständig exportiert werden?
In welchem Format werden Daten bereitgestellt?
Wie lange dauert eine Migration?
Welche technische Unterstützung wird angeboten?
Was geschieht mit Sicherungskopien?
Wie werden Zugänge entfernt?
Welche Dokumentationen werden übergeben?
Welche internen Fähigkeiten müssen erhalten bleiben?
Welche Kosten entstehen beim Ausstieg?
Wie wird ein unterbrechungsarmer Übergang ermöglicht?

Praxistipp

Eine Exit-Strategie sollte nicht erst entwickelt werden, wenn der Vertrag bereits beendet werden muss.

Leitfragen zu Partners and Suppliers

Welche externen Partner sind beteiligt?
Welche Leistungen stellen sie bereit?
Welche Produkte und Services hängen davon ab?
Sind Verantwortlichkeiten eindeutig geregelt?
Passen Verträge zu den benötigten Outcomes?
Welche Sicherheits- und Datenschutzanforderungen gelten?
Werden Unterauftragnehmer eingesetzt?
Wie wird die Lieferantenleistung überwacht?
Welche Eskalationswege bestehen?
Welche Konzentrations- und Ausfallrisiken bestehen?
Welche internen Fähigkeiten müssen erhalten bleiben?
Können Daten und Leistungen zu einem anderen Anbieter übertragen werden?
Gibt es eine geeignete Ausstiegs- und Übergangsplanung?

4. Value Streams and Processes

Die Dimension Value Streams and Processes betrachtet, wie Arbeit durch die Organisation fließt und wie Aktivitäten zu Ergebnissen und Wert beitragen.

Dazu gehören:

Wertströme,
Prozesse,
Aktivitäten,
Eingaben,
Ergebnisse,
Rollen,
Übergaben,
Entscheidungen,
Kontrollen,
Messgrößen,
und Rückmeldungen.

Einzelne Teams können ihre Aufgaben gut erfüllen und trotzdem einen schlechten Ende-zu-Ende-Arbeitsfluss erzeugen.

Die Dimension richtet den Blick deshalb nicht nur auf einzelne Prozessschritte, sondern auf den gesamten Weg zum benötigten Outcome.

Value Stream

Ein Value Stream beschreibt eine Abfolge von Schritten, durch die Wert für einen Stakeholder ermöglicht wird.

Beispiele:

neuen Mitarbeiter arbeitsfähig machen,
einen Incident bearbeiten,
eine Anwendung bereitstellen,
einen Zugriff genehmigen,
eine Schwachstelle beheben,
einen Service verbessern,
oder einen Lieferanten ablösen.

Ein Value Stream kann mehrere:

Teams,
Practices,
Technologien,
Prozesse,
Lieferanten,
und organisatorische Bereiche

verbinden.

Merke

Ein Wertstrom folgt dem Weg zum Outcome und nicht automatisch der Struktur des Organigramms.

Prozess

Ein Prozess ist eine strukturierte Folge miteinander verbundener Aktivitäten.

Er überführt bestimmte Eingaben in Ergebnisse.

Ein Prozess kann beispielsweise festlegen:

welche Informationen benötigt werden,
welche Schritte durchgeführt werden,
wer beteiligt ist,
welche Entscheidungen notwendig sind,
und wie das Ergebnis kontrolliert wird.

Ein Value Stream kann mehrere Prozesse enthalten.

Ein Prozess kann wiederum in mehreren Value Streams verwendet werden.

Beispiel:

Der Prozess zur Benutzerkontoanlage kann Bestandteil sein von:

Mitarbeiter-Onboarding,
Bereitstellung eines zusätzlichen Zugriffs,
Wechsel der Abteilung,
und Wiederherstellung eines irrtümlich entfernten Kontos.

Ende-zu-Ende-Sicht

Eine Ende-zu-Ende-Betrachtung prüft den gesamten Weg vom Bedarf bis zum erreichten Outcome.

Beispiel: neuer Mitarbeiter

Eintritt wird gemeldet.
Aufgaben und benötigte Zugriffe werden bestimmt.
Freigaben werden eingeholt.
Benutzerkonto wird erstellt.
Lizenzen werden zugewiesen.
Endgerät wird bereitgestellt.
Sicherheitsmaßnahmen werden eingerichtet.
Zugriffe werden getestet.
Arbeitsplatz wird übergeben.
Arbeitsfähigkeit wird bestätigt.

Wird nur die Kontoanlage betrachtet, können andere notwendige Schritte übersehen werden.

Der technische Output:

Das Benutzerkonto wurde erstellt.

bedeutet noch nicht automatisch das Outcome:

Der neue Mitarbeiter kann seine Aufgaben ausführen.

Übergaben

An Übergaben entstehen häufig:

Wartezeiten,
Informationsverluste,
Missverständnisse,
doppelte Arbeit,
und unklare Verantwortlichkeiten.

Beispiele:

Die Personalabteilung meldet einen Eintritt ohne Funktionsbeschreibung.
Der Service Desk weist ein Ticket ohne Diagnoseinformationen weiter.
Ein Change wird umgesetzt, aber das Monitoring-Team wird nicht informiert.
Ein Lieferant erklärt seine Komponente für funktionsfähig, obwohl der gesamte Service weiterhin gestört ist.
Eine Lösung wird gefunden, aber nicht in der Wissensdatenbank dokumentiert.

Übergaben sollten deshalb geprüft werden auf:

benötigte Informationen,
eindeutige Verantwortung,
erwartete Ergebnisse,
Zeitpunkte,
technische Schnittstellen,
und Rückmeldungen.

Engpässe und Wartezeiten

Ein Value Stream kann durch Engpässe verlangsamt werden.

Mögliche Ursachen sind:

fehlende Informationen,
unklare Freigaben,
begrenzte Fachkenntnisse,
unnötige Genehmigungsstufen,
manuelle Dateneingaben,
technische Medienbrüche,
überlastete Teams,
oder Abhängigkeiten von einzelnen Personen.

Nicht jede lange Gesamtdauer entsteht durch langsame Ausführung.

Häufig besteht ein großer Teil aus Wartezeit.

Beispiel:

Schritt	Bearbeitungszeit	Wartezeit
Anforderung prüfen	15 Minuten	1 Tag
Freigabe erteilen	5 Minuten	2 Tage
Konto erstellen	10 Minuten	4 Stunden
Zugriff testen	15 Minuten	1 Tag

Die tatsächliche Bearbeitungszeit beträgt weniger als eine Stunde.

Der gesamte Durchlauf dauert trotzdem mehrere Tage.

Kontrollen im Arbeitsfluss

Kontrollen können notwendig sein für:

Sicherheit,
Qualität,
Risiko,
Freigabe,
Nachvollziehbarkeit,
und gesetzliche Anforderungen.

Sie sollten jedoch einen klaren Zweck besitzen.

Zu prüfen ist:

Welches Risiko behandelt die Kontrolle?
Ist sie an der richtigen Stelle?
Wird sie doppelt durchgeführt?
Ist eine Automatisierung möglich?
Passt ihr Umfang zum Risiko?
Erzeugt sie unnötige Wartezeit?
Werden Ergebnisse der Kontrolle verwendet?
Kann sie umgangen werden?

Typischer Fehler

Zusätzliche Freigaben werden eingeführt, nachdem ein Fehler aufgetreten ist.

Später wird nicht mehr geprüft, ob sie das Risiko tatsächlich reduzieren oder nur den Arbeitsfluss verlangsamen.

Prozesse dürfen nicht zum Selbstzweck werden

Ein Prozess ist kein Wert an sich.

Er soll ein benötigtes Outcome unterstützen.

Anzeichen für einen ungeeigneten Prozess können sein:

Mitarbeiter umgehen den offiziellen Ablauf regelmäßig.
Informationen werden mehrfach erfasst.
Pflichtfelder enthalten bedeutungslose Standardtexte.
Genehmigungen erfolgen ohne tatsächliche Prüfung.
der Ablauf ist nur wenigen Personen verständlich.
Ergebnisse werden nicht gemessen.
Ausnahmen werden häufiger als der Standardfall.
Benutzer müssen denselben Sachverhalt mehrfach erklären.
jeder Vorgang wird gleich behandelt, obwohl die Risiken unterschiedlich sind.

Messung von Wertströmen und Prozessen

Mögliche Messgrößen sind:

Durchlaufzeit,
Bearbeitungszeit,
Wartezeit,
Anzahl der Übergaben,
Fehlerquote,
Nacharbeit,
Erfolgsquote,
Abbruchquote,
Benutzererfahrung,
Kosten,
und erreichte Outcomes.

Eine einzelne Kennzahl reicht häufig nicht aus.

Beispiel:

Eine kurze Ticketbearbeitungszeit kann positiv sein.

Sie kann aber auch entstehen, weil Tickets:

voreilig geschlossen,
an andere Teams weitergegeben,
oder nur oberflächlich bearbeitet

werden.

Messgrößen sollten deshalb gemeinsam und im Kontext betrachtet werden.

Leitfragen zu Value Streams and Processes

Welches Outcome soll erreicht werden?
Wo beginnt und endet der Wertstrom?
Welche Schritte sind tatsächlich notwendig?
Welche Teams, Practices und Lieferanten sind beteiligt?
Wo entstehen Übergaben?
Welche Informationen werden benötigt?
Wo entstehen Wartezeiten oder Nacharbeit?
Welche Kontrollen sind notwendig?
Welche Schritte erzeugen keinen erkennbaren Nutzen?
Wo bestehen Engpässe?
Welche Tätigkeiten können vereinheitlicht oder automatisiert werden?
Wie wird der Erfolg aus Sicht der Stakeholder geprüft?
Wie fließt Feedback in Verbesserungen ein?

Zusammenwirken der vier Dimensionen

Die vier Dimensionen beeinflussen sich gegenseitig.

Veränderung	Mögliche Auswirkungen auf andere Dimensionen
neues Ticketsystem	Schulungsbedarf, Rollen, Datenmigration, Lieferantenvertrag und angepasste Prozesse
Outsourcing des Service Desk	neue Schnittstellen, Verantwortlichkeiten, technische Zugänge und Eskalationswege
Automatisierung der Benutzeranlage	Datenqualität, Freigaben, Rollen, Sicherheitskontrollen und Prozessänderungen
Einführung einer Cloud-Plattform	neue Fähigkeiten, Verträge, Integrationen, Datenflüsse und Supportprozesse
Änderung eines Incident-Prozesses	Werkzeugkonfiguration, Schulung, Lieferanteneinbindung und neue Messgrößen
Einsatz von KI	Datenanforderungen, Governance, Kompetenzen, Lieferantenrisiken und Kontrollabläufe

Merke

Eine Änderung in nur einer Dimension ist in der Praxis selten auf diese eine Dimension begrenzt.

Praxisbeispiel: Einführung eines neuen Ticketsystems

Eine Organisation möchte ihr bisheriges Ticketsystem ersetzen.

Organizations and People

Welche Teams verwenden das System?
Welche Rollen und Berechtigungen werden benötigt?
Welche Schulungen sind notwendig?
Wer administriert das System?
Wer verantwortet Kategorien, Vorlagen und Automatisierungen?
Wie werden Benutzer und Supportmitarbeiter einbezogen?

Information and Technology

Welche Daten müssen übernommen werden?
Welche Schnittstellen bestehen?
Wie werden Identitäten und Berechtigungen integriert?
Welche Sicherheits- und Datenschutzanforderungen gelten?
Wie werden Backups, Protokollierung und Monitoring umgesetzt?
Welche Automatisierungen werden benötigt?

Partners and Suppliers

Welcher Anbieter stellt die Lösung bereit?
Welche Support- und Verfügbarkeitsleistungen gelten?
Wie werden Daten exportiert?
Welche Unterauftragnehmer sind beteiligt?
Wie erfolgen Eskalationen?
Wie kann das System später abgelöst werden?

Value Streams and Processes

Welche Vorgangsarten werden benötigt?
Wie laufen Incident, Service Request, Problem und Change durch das System?
Welche Pflichtinformationen sind sinnvoll?
Wo bestehen heute unnötige Übergaben?
Welche Abläufe sollen vereinfacht werden?
Welche Kennzahlen werden benötigt?

Wird nur die Technologie ausgewählt, können die anderen drei Dimensionen später zu erheblichen Problemen führen.

Praxisbeispiel: wiederkehrender VPN-Ausfall

Mehrere Benutzer verlieren regelmäßig ihre VPN-Verbindung.

Organizations and People

Wer koordiniert die Untersuchung?
Besitzen Service Desk und Netzwerkteam ausreichendes Wissen?
Sind Verantwortlichkeiten zwischen interner IT und Provider klar?

Information and Technology

Welche Protokolle und Monitoring-Daten liegen vor?
Welche VPN-Komponenten, Zertifikate und Identitätsdienste sind beteiligt?
Sind die Daten für eine Ursachenanalyse ausreichend?

Partners and Suppliers

Ist ein Internet- oder VPN-Provider beteiligt?
Welche Support- und Eskalationswege gelten?
Welche Nachweise benötigt der Provider?

Value Streams and Processes

Werden ähnliche Incidents miteinander verknüpft?
Wird Problem Management einbezogen?
Wie werden Benutzer informiert?
Wie wird eine dauerhafte Korrektur geplant und kontrolliert umgesetzt?

Eine rein technische Einzelbehandlung kann den Service kurzfristig wiederherstellen.

Die ganzheitliche Betrachtung unterstützt zusätzlich eine nachhaltige Verbesserung.

Praxisbeispiel: Backup und Wiederherstellung

Organizations and People

Wer überwacht Sicherungen?
Wer darf Wiederherstellungen anfordern?
Wer führt Tests durch?
Wer entscheidet bei möglichem Datenverlust?

Information and Technology

Welche Systeme und Daten werden gesichert?
Sind Sicherungen verschlüsselt und geschützt?
Funktionieren Wiederherstellungen?
Welche RPO- und RTO-Anforderungen bestehen?

Partners and Suppliers

Wird ein Cloud- oder Backup-Anbieter verwendet?
Welche Leistungen sind zugesichert?
Wie können Daten bei Anbieterwechsel zurückgeführt werden?
Welche Supportwege bestehen?

Value Streams and Processes

Wie werden neue Systeme in die Sicherung aufgenommen?
Wie werden Fehler behandelt?
Wie laufen Wiederherstellungstests ab?
Wie werden Ergebnisse und Verbesserungen dokumentiert?

Merke

Backup ist nicht nur eine Technologie.

Wiederherstellbarkeit entsteht durch das Zusammenspiel aller vier Dimensionen.

Die vier Dimensionen bei einem Incident

Dimension	Beispielhafte Fragen
Organizations and People	Wer koordiniert, entscheidet, analysiert und kommuniziert?
Information and Technology	Welche Systeme, Daten, Protokolle und Abhängigkeiten sind betroffen?
Partners and Suppliers	Welche Anbieter müssen beteiligt oder eskaliert werden?
Value Streams and Processes	Wie erfolgt Erfassung, Priorisierung, Wiederherstellung, Kommunikation und Abschluss?

Die vier Dimensionen bei einem Change

Dimension	Beispielhafte Fragen
Organizations and People	Wer beantragt, bewertet, autorisiert, implementiert und prüft?
Information and Technology	Welche Komponenten, Daten, Schnittstellen und Sicherheitsmaßnahmen sind betroffen?
Partners and Suppliers	Werden Hersteller, Provider oder Wartungspartner benötigt?
Value Streams and Processes	Wie erfolgen Bewertung, Test, Autorisierung, Umsetzung, Rückfall und Erfolgskontrolle?

Die vier Dimensionen bei einer Verbesserung

Dimension	Beispielhafte Fragen
Organizations and People	Welche Fähigkeiten, Rollen oder kulturellen Veränderungen werden benötigt?
Information and Technology	Welche Daten belegen das Problem und welche Technologie unterstützt die Verbesserung?
Partners and Suppliers	Welche externen Beiträge oder Vertragsänderungen sind notwendig?
Value Streams and Processes	Welcher Arbeitsfluss wird verbessert und wie wird die Wirkung gemessen?

Typische Fehler

Fehler 1: Nur Technik betrachten

Eine Organisation kauft eine neue Plattform, ohne Rollen, Fähigkeiten, Support und Arbeitsabläufe vorzubereiten.

Fehler 2: Nur Prozesse dokumentieren

Abläufe werden beschrieben, aber notwendige Informationen, Technologien und Kompetenzen fehlen.

Fehler 3: Lieferanten nicht als Teil des Service betrachten

Externe Abhängigkeiten werden erst berücksichtigt, wenn ein Incident eskaliert.

Fehler 4: Menschen als austauschbare Ressourcen behandeln

Benötigte Fähigkeiten, Erfahrungen, Motivation und Zusammenarbeit werden nicht berücksichtigt.

Fehler 5: Jede Dimension getrennt optimieren

Ein Team verbessert seine eigene Kennzahl, verschlechtert aber den gesamten Wertstrom.

Fehler 6: Alle Situationen gleich ausführlich prüfen

Kleine Standardtätigkeiten werden unnötig kompliziert, während kritische Vorhaben nicht risikogerecht vertieft werden.

Fehler 7: Werkzeuge mit Fähigkeiten verwechseln

Eine Organisation besitzt eine Funktion im Ticketsystem, hat aber keine wirksame Arbeitsweise und keine eindeutigen Verantwortlichkeiten dafür.

Fehler 8: Verträge nur beim Einkauf betrachten

Betrieb, Support, Sicherheit, Eskalation und Ausstieg werden nicht ausreichend einbezogen.

Fehler 9: Datenmenge mit Informationsqualität verwechseln

Viele Kennzahlen werden gesammelt, liefern aber keine Grundlage für Entscheidungen oder Verbesserungen.

Fehler 10: Prozesse an Teamgrenzen enden lassen

Jedes Team bearbeitet nur seinen Teil, während niemand das Ende-zu-Ende-Outcome verantwortet.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten häufig hauptsächlich in der technischen Dimension.

Ihre Aufgaben beeinflussen jedoch immer wieder alle vier Dimensionen.

Beispiel: neuer Server

Tätigkeit	Betroffene Dimension
Server installieren und konfigurieren	Information and Technology
Zuständigkeit und Betrieb klären	Organizations and People
Hardware-, Software- oder Cloud-Anbieter einbinden	Partners and Suppliers
Bereitstellung, Change, Monitoring und Support einordnen	Value Streams and Processes

Vor einer technischen Maßnahme sind deshalb zusätzliche Fragen sinnvoll:

Welcher Service hängt von der Komponente ab?
Wer trägt Verantwortung?
Wer muss informiert werden?
Welche Informationen müssen dokumentiert werden?
Welche Lieferanten sind beteiligt?
Welche Arbeitsabläufe werden verändert?
Wie wird der Erfolg aus Benutzersicht geprüft?
Welche langfristigen Betriebs- und Supportaufgaben entstehen?

30-Sekunden-Prüfung

Bei einer neuen Aufgabe kannst du alle vier Dimensionen mit vier Kurzfragen prüfen:

Menschen: Wer ist beteiligt, verantwortlich und ausreichend befähigt?
Technologie: Welche Informationen, Systeme und technischen Abhängigkeiten werden benötigt?
Partner: Welche externen Anbieter und vertraglichen Abhängigkeiten bestehen?
Arbeitsfluss: Wie gelangt die Aufgabe vom Bedarf zum überprüften Outcome?

Diese Kurzprüfung ersetzt keine notwendige Detailanalyse.

Sie hilft jedoch dabei, eine Dimension nicht vollständig zu übersehen.

Checkliste zu Organizations and People

Sind Rollen und Verantwortlichkeiten eindeutig?
Sind Entscheidungs- und Eskalationswege bekannt?
Sind notwendige Fähigkeiten vorhanden?
Besteht ausreichende Kapazität?
Sind Vertretungen geregelt?
Funktioniert die Zusammenarbeit zwischen Teams?
Werden Wissen und Erfahrungen geteilt?
Unterstützt die Kultur offene Kommunikation und Verbesserung?
Verstehen die Beteiligten das erwartete Outcome?

Checkliste zu Information and Technology

Sind benötigte Informationen verfügbar und aktuell?
Ist die Verantwortung für Datenqualität geklärt?
Passen Technologien und Architektur zum Bedarf?
Sind Schnittstellen und Abhängigkeiten dokumentiert?
Sind Informationssicherheit und Datenschutz berücksichtigt?
Sind Backup und Wiederherstellung vorbereitet?
Werden Systeme angemessen überwacht?
Sind Automatisierungen kontrollierbar?
Sind technische Schulden und Lebenszyklusrisiken bekannt?

Checkliste zu Partners and Suppliers

Sind alle relevanten Lieferanten bekannt?
Sind Leistungsumfang und Verantwortlichkeiten eindeutig?
Passen Verträge zu den benötigten Outcomes?
Sind Sicherheits- und Datenschutzanforderungen geregelt?
Bestehen bekannte Ausfall- oder Konzentrationsrisiken?
Sind Support- und Eskalationswege vorbereitet?
Werden Lieferantenleistungen überwacht?
Bleiben notwendige interne Fähigkeiten erhalten?
Besteht eine Ausstiegs- und Übergangsplanung?

Checkliste zu Value Streams and Processes

Gesamtcheck für ein Produkt oder einen Service

Schnellreferenz

Dimension	Kurzfrage
Organizations and People	Wer wird benötigt und wie arbeiten die Beteiligten zusammen?
Information and Technology	Welche Informationen und Technologien ermöglichen das Outcome?
Partners and Suppliers	Welche externen Leistungen und Abhängigkeiten bestehen?
Value Streams and Processes	Wie fließt die Arbeit vom Bedarf zum Ergebnis?

Zusammenfassende Darstellung

Organizations and People
Rollen · Fähigkeiten · Kapazität · Kommunikation · Kultur

Information and Technology
Daten · Wissen · Anwendungen · Infrastruktur · Integration · Automatisierung

Partners and Suppliers
Leistungen · Verträge · Zusammenarbeit · Abhängigkeiten · Ausstieg

Value Streams and Processes
Aktivitäten · Übergaben · Kontrollen · Arbeitsfluss · Outcomes

↓

ganzheitliches digitales Produkt- und Service-Management

↓

bessere Outcomes und gemeinsam ermöglichter Wert

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen
Supplier Management
Information Security Management
Knowledge Management
Service Configuration Management
IT Asset Management

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL Version 5 verwendet die folgenden vier Dimensionen des Produkt- und Service-Managements:

Organizations and People
Information and Technology
Partners and Suppliers
Value Streams and Processes

Die offiziellen ITIL-Version-5-Grundlagen beschreiben die vier Dimensionen als Grundlage einer ganzheitlichen Betrachtung digitaler Produkte und Services.

Die ausführlichen Leitfragen, Beispiele, Checklisten und technischen Einordnungen auf dieser Seite sind zusätzliche herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation verbindlichen Arbeitsabläufe dar.

Konkrete Rollen, Technologien, Lieferantenmodelle, Prozesse und Kontrollen müssen an den jeweiligen Kontext angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.6 Der Product and Service Lifecycle

Kurz erklärt

Der ITIL Product and Service Lifecycle beschreibt den gemeinsamen Lebenszyklus digitaler Produkte und Services.

Er verbindet Produktentwicklung, Beschaffung, technische Umsetzung, Betrieb, Bereitstellung und Unterstützung in einem gemeinsamen Modell.

Die acht Lifecycle-Aktivitäten sind:

Discover

Design

Acquire

Build

Transition

Operate

Deliver

Support

Die Aktivitäten bilden keinen starren linearen Ablauf. Sie können sich überschneiden, wiederholt werden und sich gegenseitig beeinflussen.

Warum ein gemeinsamer Lebenszyklus notwendig ist

Digitale Produkte und Services wurden in Organisationen häufig getrennt betrachtet.

Produktteams konzentrierten sich beispielsweise auf:

Anforderungen,
Funktionen,
Entwicklung,
Releases,
Roadmaps,
und technische Weiterentwicklung.

Serviceteams konzentrierten sich dagegen auf:

Betrieb,
Servicequalität,
Benutzerunterstützung,
Incidents,
Service Requests,
Service Levels,
und Kommunikation.

Diese Trennung kann zu Problemen führen.

Beispiele:

Eine neue Funktion wird veröffentlicht, ohne den Service Desk vorzubereiten.
Eine Anwendung wird entwickelt, ohne Monitoring und Wiederherstellung ausreichend zu berücksichtigen.
Ein Produktteam bewertet den Release als erfolgreich, obwohl Benutzer den Service nicht zuverlässig verwenden können.
Betriebserfahrungen erreichen die Produktentwicklung nicht.
Anforderungen an Sicherheit, Support und Servicequalität werden erst kurz vor der Einführung betrachtet.
Technische Schulden werden zwischen Entwicklung und Betrieb hin- und hergeschoben.
Produkt- und Serviceteams verwenden unterschiedliche Ziele und Kennzahlen.

ITIL Version 5 verbindet beide Perspektiven deshalb in einem gemeinsamen Product and Service Lifecycle.

Merke

Produkt und Service sind keine voneinander unabhängigen Alternativen.

Sie sind zwei miteinander verbundene Perspektiven auf eine technologiebasierte Lösung.

Produkt- und Serviceperspektive

Die Produktperspektive betrachtet unter anderem:

Fähigkeiten und Funktionen,
technische Architektur,
Roadmap,
Entwicklung,
Investitionen,
Versionen,
technische Schulden,
und den Lebenszyklus der Lösung.

Die Serviceperspektive betrachtet unter anderem:

Nutzung,
Outcomes,
Servicequalität,
Erfahrung,
Support,
Servicebeziehungen,
Verfügbarkeit,
Kontinuität,
und die Zusammenarbeit mit Stakeholdern.

Beispiel: VPN-Lösung

Produktperspektive	Serviceperspektive
VPN-Gateway und Clientsoftware	sicherer Fernzugriff für Benutzer
Authentifizierungsfunktionen	verständlicher und zuverlässiger Anmeldevorgang
unterstützte Betriebssysteme	Nutzbarkeit auf den benötigten Endgeräten
technische Kapazität	ausreichende Leistung für die Benutzer
Softwareversionen	kontrollierte und möglichst störungsarme Aktualisierung
Protokollierung	Unterstützung bei Störungen und Sicherheitsanalysen
Hersteller-Roadmap	langfristige Nutzbarkeit des Fernzugriffs

Beide Perspektiven müssen gemeinsam betrachtet werden.

Eine technisch leistungsfähige VPN-Plattform ermöglicht noch keinen verlässlichen Fernzugriffsservice, wenn:

Benutzer nicht eingerichtet sind,
Berechtigungen fehlen,
der Support nicht vorbereitet wurde,
keine verständliche Anleitung existiert,
die Internetverbindung ungeeignet ist,
oder Störungen nicht wirksam bearbeitet werden.

Die acht Lifecycle-Aktivitäten im Überblick

Aktivität	Zentrale Aufgabe
Discover	Bedürfnisse, Chancen, Ausgangslage und Umfeld verstehen
Design	geeignete Produkte, Services und Lösungen gestalten
Acquire	benötigte Ressourcen, Produkte, Leistungen und Fähigkeiten beschaffen oder zuordnen
Build	Lösungen erstellen, konfigurieren, integrieren und testen
Transition	neue oder geänderte Bestandteile kontrolliert in die vorgesehene Nutzung überführen
Operate	Produkte, Plattformen und technische Fähigkeiten zuverlässig betreiben
Deliver	Services und Serviceangebote für Stakeholder bereitstellen und steuern
Support	Benutzer, Kunden, Produkte und Services bei Fragen, Anfragen und Störungen unterstützen

Die Beschreibungen in dieser Tabelle sind praxisnahe Zusammenfassungen.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen dar.

Lifecycle-Aktivitäten statt starrer Phasen

Die Begriffe können zunächst den Eindruck einer festen Reihenfolge vermitteln:

Discover → Design → Acquire → Build → Transition → Operate → Deliver → Support

Das Modell ist jedoch nicht als starres Wasserfallmodell gedacht.

Jede Aktivität kann:

Erkenntnisse für andere Aktivitäten liefern,
erneut erforderlich werden,
gleichzeitig mit anderen Aktivitäten stattfinden,
Rücksprünge auslösen,
und unterschiedliche Versionen eines Produkts oder Service betreffen.

Beispiel:

Während Version 1 einer Anwendung betrieben, bereitgestellt und unterstützt wird, kann gleichzeitig:

Version 2 gestaltet werden,
eine neue Komponente beschafft werden,
ein Update erstellt und getestet werden,
und eine zukünftige Version untersucht werden.

Produkt- oder Serviceversion	Mögliche aktuelle Aktivität
Version 1.0	Operate, Deliver und Support
Version 1.1	Build und Test
Version 1.2	Design
zukünftige Hauptversion	Discover
abzulösende Altversion	Transition und Operate

Merke

Ein Produkt oder Service befindet sich nicht dauerhaft nur in einer einzigen Lifecycle-Aktivität.

Transitions können zwischen verschiedenen Aktivitäten stattfinden

Transition ist nicht ausschließlich ein einmaliger Schritt zwischen Build und Operate.

Eine kontrollierte Überführung kann an unterschiedlichen Stellen notwendig sein.

Beispiele:

Übergabe neuer Erkenntnisse von Discover an Design
Überführung eines Entwurfs in Beschaffung oder Entwicklung
Übergang von einer Testumgebung in eine Pilotumgebung
Übergang von einem Pilotbetrieb in die allgemeine Nutzung
Übergabe einer neuen Funktion an Betrieb und Support
Migration von einem alten zu einem neuen Anbieter
Außerbetriebnahme einer bisherigen Produktversion
Überführung einer Zwischenlösung in eine dauerhafte Lösung

Die konkrete Form einer Transition hängt vom jeweiligen Produkt, Service, Risiko und Wertstrom ab.

Wichtig

Transition bedeutet nicht, dass ein Team seine Arbeit beendet und die Verantwortung vollständig an ein anderes Team abgibt.

Produkt-, Service-, Betriebs- und Supportverantwortung müssen über den Übergang hinweg zusammenwirken.

Lifecycle, Value System und Value Stream unterscheiden

Begriff	Bedeutung
ITIL Value System	verbindet die übergeordneten Bestandteile der Organisation zur Wertschöpfung
Product and Service Lifecycle	beschreibt acht gemeinsame Aktivitäten über den Lebenszyklus digitaler Produkte und Services
Value Chain	flexibles operatives Modell innerhalb des ITIL Value Systems
Value Stream	konkrete Abfolge von Schritten zur Erreichung eines bestimmten Outcomes
Management Practice	organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Prozess	strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen
Projekt	zeitlich begrenztes Vorhaben zur Erreichung definierter Ziele

Beispiel: Einführung einer neuen Monitoring-Plattform

Der Lifecycle hilft, alle Aktivitäten von Discovery bis Support zu betrachten.
Der Value Stream beschreibt den konkreten Weg von der Anforderung bis zur wirksam eingesetzten Plattform.
Die Practices stellen Fähigkeiten wie Monitoring and Event Management, Change Management und Supplier Management bereit.
Ein Projekt kann Teile der Einführung zeitlich organisieren.
Das Value System verbindet Governance, Prinzipien, Practices, Wertschöpfung und Verbesserung.

Lifecycle und Projektlebenszyklus unterscheiden

Ein Projekt besitzt normalerweise:

einen definierten Anfang,
festgelegte Ziele,
einen begrenzten Umfang,
einen Zeitplan,
und ein formales Ende.

Ein digitales Produkt oder ein Service besteht häufig über das Projekt hinaus.

Beispiel:

Ein Projekt führt eine neue E-Mail-Plattform ein.

Nach Projektende müssen weiterhin durchgeführt werden:

Betrieb,
Monitoring,
Incident-Bearbeitung,
Benutzerunterstützung,
Kapazitätsplanung,
Sicherheitsaktualisierungen,
Lieferantensteuerung,
Verbesserungen,
und spätere Ablösung.

Typischer Fehler

Die Produkt- und Serviceverantwortung endet mit dem Projektabschluss.

Dadurch bleiben Betrieb, Support, technische Schulden und langfristige Weiterentwicklung ungeklärt.

1. Discover

Zentrale Frage

Was wird benötigt, warum wird es benötigt und welche Ausgangslage besteht?

Discover dient dazu, Bedürfnisse, Chancen, Probleme und Rahmenbedingungen zu verstehen.

Mögliche Auslöser sind:

neue Benutzeranforderung,
geändertes Geschäftsziel,
wiederkehrender Incident,
Sicherheitsrisiko,
technische Schulden,
neue gesetzliche Anforderung,
Rückmeldung von Kunden,
neue Technologie,
Lieferantenänderung,
oder mögliches Verbesserungspotenzial.

Discover sollte nicht nur bestätigen, was ein einzelner Anforderer bereits als Lösung vorgeschlagen hat.

Zuerst sollte das zugrunde liegende Bedürfnis verstanden werden.

Beispiel:

Anforderung:

Wir benötigen einen neuen Server.

Mögliche zugrunde liegende Bedürfnisse:

zusätzliche Kapazität,
Ablösung eines nicht unterstützten Systems,
Trennung verschiedener Anwendungen,
bessere Verfügbarkeit,
neue Testumgebung,
oder Erfüllung einer Sicherheitsanforderung.

Erst nach dieser Klärung kann bewertet werden, ob ein neuer Server tatsächlich die geeignete Lösung darstellt.

Typische Inhalte von Discover

Bedürfnisse und Erwartungen
betroffene Stakeholder
gewünschte Outcomes
aktuelle Probleme
vorhandene Produkte und Services
technische und organisatorische Ausgangslage
Chancen und Risiken
Markt- und Technologieentwicklung
gesetzliche und vertragliche Anforderungen
Nachhaltigkeitsanforderungen
Benutzer- und Kundenerfahrung
vorhandene Daten und Messwerte
mögliche Einschränkungen
Annahmen und Unsicherheiten

Leitfragen zu Discover

Welches Problem oder Bedürfnis besteht?
Wer nimmt den erwarteten Wert wahr?
Welches Outcome soll erreicht werden?
Wie sieht der aktuelle Zustand aus?
Was funktioniert bereits?
Welche Daten belegen das Problem?
Welche Stakeholder sind beteiligt?
Welche gesetzlichen und betrieblichen Vorgaben gelten?
Welche Chancen und Risiken bestehen?
Welche Annahmen müssen überprüft werden?
Welche Auswirkungen hätte es, nichts zu verändern?
Welche bestehenden Produkte oder Services könnten angepasst werden?
Muss überhaupt eine neue Lösung entstehen?

Mögliche Ergebnisse von Discover

verständlich beschriebener Bedarf
bekannte Stakeholder
gewünschte Outcomes
erste Wert- und Risikobewertung
dokumentierte Ausgangslage
bekannte Einschränkungen
erste Lösungsoptionen
priorisierte Anforderungen
Entscheidung über weitere Untersuchung
Entscheidung, ein Vorhaben nicht weiterzuverfolgen

Merke

Ein sinnvolles Ergebnis von Discover kann auch die Entscheidung sein, keine neue Lösung einzuführen.

Praxisbeispiel: wiederkehrende Anmeldeprobleme

Mehrere Benutzer können sich regelmäßig nicht anmelden.

Eine vorschnelle Lösung wäre:

Der Verzeichnisdienst muss ersetzt werden.

Discover untersucht zunächst:

Welche Benutzer sind betroffen?
Wann treten die Fehler auf?
Welche Fehlermeldungen erscheinen?
Welche Systeme sind beteiligt?
Gab es kürzlich Changes?
Sind DNS und Zeitsynchronisation stabil?
Liegen Probleme mit MFA oder Zertifikaten vor?
Sind Benutzerprozesse verständlich?
Besteht ein Kapazitätsproblem?
Welche bisherigen Maßnahmen wurden durchgeführt?

Erst danach kann eine geeignete Designentscheidung getroffen werden.

Typische Fehler bei Discover

Lösung festlegen, bevor das Problem verstanden wurde
nur mit einem Stakeholder sprechen
vorhandene Daten ignorieren
Benutzererfahrung nicht berücksichtigen
technische Symptome mit der eigentlichen Ursache verwechseln
bestehende Fähigkeiten und Lösungen übersehen
Unsicherheiten nicht dokumentieren
keine Kriterien für Erfolg definieren
jede technische Neuerung automatisch als Chance betrachten

2. Design

Zentrale Frage

Wie müssen Produkt und Service gestaltet werden, damit das gewünschte Outcome sicher und nachhaltig unterstützt wird?

Design übersetzt Bedürfnisse und Erkenntnisse in eine geeignete Gesamtlösung.

Dabei werden nicht nur technische Funktionen gestaltet.

Zu berücksichtigen sind ebenfalls:

Serviceerfahrung,
Betriebsmodell,
Support,
Sicherheit,
Wiederherstellung,
Informationen,
Prozesse,
Rollen,
Lieferanten,
und Lebenszyklusanforderungen.

Funktionale und nichtfunktionale Anforderungen

Funktionale Anforderungen beschreiben, was eine Lösung leisten soll.

Beispiele:

Benutzer können sich anmelden.
Dateien können gemeinsam bearbeitet werden.
Administratoren können Berechtigungen verwalten.
Monitoring erkennt den Ausfall eines Dienstes.

Nichtfunktionale Anforderungen beschreiben Eigenschaften und Qualitätsanforderungen.

Beispiele:

Verfügbarkeit
Leistung
Skalierbarkeit
Sicherheit
Datenschutz
Wartbarkeit
Bedienbarkeit
Barrierefreiheit
Wiederherstellbarkeit
Protokollierung
Kompatibilität
Nachhaltigkeit

Typischer Fehler

Die Funktionen werden gestaltet, während Betrieb, Support, Sicherheit und Wiederherstellung erst kurz vor der Einführung betrachtet werden.

Design betrachtet alle vier Dimensionen

Organizations and People

Welche Rollen und Fähigkeiten werden benötigt?
Wer verantwortet Produkt und Service?
Wie werden Benutzer und Supportmitarbeiter geschult?

Information and Technology

Welche Architektur, Daten und Technologien werden benötigt?
Wie werden Integration, Sicherheit und Wiederherstellung gestaltet?

Partners and Suppliers

Welche externen Leistungen werden benötigt?
Welche Anforderungen müssen Verträge und Supportvereinbarungen erfüllen?

Value Streams and Processes

Wie erfolgen Bestellung, Bereitstellung, Nutzung, Support und Verbesserung?
Welche Übergaben und Kontrollen sind notwendig?

Leitfragen zu Design

Welche Outcomes und Erfahrungen sollen unterstützt werden?
Welche Funktionen werden benötigt?
Welche Qualitätsanforderungen gelten?
Welche Sicherheits- und Datenschutzanforderungen bestehen?
Wie wird der Service betrieben und unterstützt?
Welche Abhängigkeiten und Schnittstellen bestehen?
Welche Daten werden verarbeitet?
Welche Kapazität und Verfügbarkeit werden benötigt?
Wie erfolgen Backup und Wiederherstellung?
Welche Rollen und Fähigkeiten werden benötigt?
Welche Lieferanten werden beteiligt?
Wie wird die Lösung überwacht?
Wie werden Updates und Changes durchgeführt?
Wie kann die Lösung später erweitert oder abgelöst werden?
Wie wird der Erfolg überprüft?

Betrieb und Support bereits im Design berücksichtigen

Ein Produkt sollte nicht erst nach seiner Entwicklung „betriebsfähig gemacht“ werden.

Bereits im Design sollten unter anderem berücksichtigt werden:

Monitoring
Protokollierung
Fehlerdiagnose
Backup
Wiederherstellung
Kapazität
Verfügbarkeit
Patch- und Updateverfahren
Zugriffskontrolle
Supportinformationen
Service-Desk-Vorbereitung
bekannte Fehlerszenarien
Eskalationswege
Dokumentation
Außerbetriebnahme

Merke

Operability und Supportability sind keine nachträglichen Zusatzfunktionen.

Sie gehören zur Gestaltung eines nutzbaren und nachhaltigen digitalen Produkts und Service.

Mögliche Ergebnisse von Design

Lösungsentwurf
Produkt- und Serviceanforderungen
Architektur
Prototyp
Serviceangebot
Sicherheitskonzept
Supportmodell
Monitoring-Konzept
Betriebs- und Wiederherstellungskonzept
Lieferantenanforderungen
Teststrategie
Transition-Planung
Erfolgskriterien
Plan für spätere Ablösung

Typische Fehler bei Design

nur sichtbare Funktionen gestalten
Benutzer und Support nicht einbeziehen
Betriebsanforderungen zu spät berücksichtigen
Sicherheitskontrollen nachträglich ergänzen
keine Exit- oder Ablösungsplanung
Lieferantenabhängigkeiten übersehen
unklare Erfolgskriterien
unnötige Komplexität aufbauen
Design nicht anhand von Feedback überprüfen

3. Acquire

Zentrale Frage

Welche Produkte, Leistungen, Ressourcen und Fähigkeiten werden benötigt und wie werden sie beschafft oder bereitgestellt?

Acquire umfasst die Beschaffung oder Zuordnung benötigter Bestandteile.

Dazu können gehören:

Hardware
Software
Cloud-Services
Lizenzen
externe Dienstleistungen
Daten
Infrastrukturkapazität
Fachwissen
Schulungen
Personal
Entwicklungsleistungen
Supportverträge
und Lieferantenressourcen

Acquire bedeutet nicht automatisch, dass etwas von einem externen Anbieter gekauft werden muss.

Mögliche Entscheidungen sind:

selbst entwickeln
intern wiederverwenden
Standardprodukt kaufen
Cloud-Service abonnieren
Open-Source-Lösung einsetzen
Dienstleistung auslagern
gemeinsam mit einem Partner entwickeln
oder eine bestehende Fähigkeit erweitern

Make, Buy, Reuse oder Partner

Möglichkeit	Beispiel
Make	eigene Anwendung oder Automatisierung entwickeln
Buy	Standardsoftware oder Hardware beschaffen
Reuse	vorhandene Plattform oder Komponente weiterverwenden
Subscribe	Cloud- oder SaaS-Service abonnieren
Partner	Lösung gemeinsam mit einem externen Partner entwickeln
Outsource	Tätigkeit oder Servicebestandteil extern erbringen lassen

Die Entscheidung sollte nicht nur anhand des Anschaffungspreises erfolgen.

Zu berücksichtigen sind beispielsweise:

benötigte Outcomes
Gesamtkosten
Geschwindigkeit
vorhandene Fähigkeiten
Integrationsaufwand
Sicherheit
Datenschutz
Lieferantenabhängigkeit
Datenportabilität
Wartung
Support
Skalierbarkeit
und spätere Ablösung

Leitfragen zu Acquire

Welche Ressourcen und Fähigkeiten werden benötigt?
Was ist bereits vorhanden?
Was kann intern bereitgestellt werden?
Was muss extern beschafft werden?
Welche Lieferanten kommen infrage?
Welche Anforderungen müssen vertraglich geregelt werden?
Welche Lizenzen werden benötigt?
Welche Sicherheits- und Datenschutzanforderungen gelten?
Welche Abhängigkeiten entstehen?
Können Daten und Konfigurationen später exportiert werden?
Welche internen Fähigkeiten müssen erhalten bleiben?
Wie wird die Lieferantenleistung überwacht?
Was geschieht bei Vertragsende oder Lieferantenausfall?
Sind Beschaffungszeit und Verfügbarkeit realistisch?

Beschaffung ist mehr als Bestellung

Eine technische Bestellung allein stellt noch keine nutzbare Ressource bereit.

Beispiel: neue Firewall

Zusätzlich zur Hardware können benötigt werden:

Lizenzen
Supportvertrag
Rackplatz
Stromversorgung
Netzwerkanschlüsse
Managementzugang
Zertifikate
Administrationswissen
Ersatzteile
Monitoring
Dokumentation
Backup der Konfiguration
und ein Ablösungsplan

Typischer Fehler

Der Kaufpreis wird geplant, während Betriebskosten, Lizenzen, Support und notwendige Fähigkeiten nicht berücksichtigt werden.

Lieferanten und Exit-Planung

Bei externen Leistungen sollte bereits während Acquire geprüft werden:

Wie werden Daten zurückgegeben?
Welche Exportformate existieren?
Welche Unterauftragnehmer werden eingesetzt?
Welche Support- und Eskalationswege gelten?
Welche Serviceziele werden zugesichert?
Welche Sicherheitsnachweise existieren?
Wie werden Vertragsänderungen behandelt?
Welche Kosten entstehen bei einer Migration?
Wie kann die Leistung später ersetzt werden?
Welche internen Kenntnisse müssen erhalten bleiben?

Mögliche Ergebnisse von Acquire

beschaffte Produkte und Leistungen
zugewiesene interne Ressourcen
Lizenzen und Nutzungsrechte
Verträge und Vereinbarungen
Lieferantenbeziehungen
bereitgestellte Umgebungen
benötigte Fähigkeiten und Schulungen
bekannte Lieferantenrisiken
Exit- und Übergangsanforderungen
geprüfte Liefergegenstände

Typische Fehler bei Acquire

nur den niedrigsten Preis bewerten
Betriebskosten übersehen
Fähigkeiten und Schulungen nicht einplanen
Supportanforderungen nicht vertraglich klären
Lieferantenabhängigkeit ignorieren
keine Datenportabilität vorsehen
Lizenzen falsch dimensionieren
Beschaffung und technische Integration nicht abstimmen
Exit-Planung auf später verschieben

4. Build

Zentrale Frage

Wie wird die entworfene Lösung erstellt, konfiguriert, integriert und überprüft?

Build umfasst die praktische Erstellung und technische Umsetzung.

Dazu können gehören:

Softwareentwicklung
Hardwareinstallation
Systemkonfiguration
Cloud-Bereitstellung
Integration
Datenmigration
Automatisierung
Erstellung von Schnittstellen
Konfiguration von Monitoring
Sicherheitsmaßnahmen
Dokumentation
und Tests

Build bedeutet nicht ausschließlich Programmierung.

Auch die Konfiguration einer Standardsoftware oder der Aufbau einer Infrastruktur kann Teil dieser Aktivität sein.

Build und Test gehören zusammen

Eine erstellte Lösung muss überprüft werden.

Mögliche Testarten sind:

Funktionstest
Integrationstest
Sicherheitstest
Leistungstest
Wiederherstellungstest
Kompatibilitätstest
Benutzerakzeptanztest
Failover-Test
Migrationstest
Überwachungstest
Rückfalltest
und Test der Supportfähigkeit

Tests sollten sich an Anforderungen und Risiken orientieren.

Merke

Ein erfolgreicher Funktionstest beweist nicht automatisch, dass eine Lösung sicher, betreibbar, wiederherstellbar und für Benutzer geeignet ist.

Leitfragen zu Build

Entspricht die Umsetzung dem Design?
Welche Komponenten müssen erstellt oder konfiguriert werden?
Welche Standards und Sicherheitsvorgaben gelten?
Welche Abhängigkeiten bestehen?
Wie werden Änderungen versioniert?
Welche Umgebungen werden verwendet?
Wie werden Zugangsdaten und Geheimnisse geschützt?
Welche Tests sind notwendig?
Sind Testdaten geeignet und zulässig?
Wie werden Fehler dokumentiert und korrigiert?
Wie wird die Konfiguration reproduzierbar?
Werden Betrieb, Monitoring und Support vorbereitet?
Ist die Dokumentation ausreichend?
Ist eine Rückfallmöglichkeit vorhanden?

Reproduzierbarkeit

Technische Lösungen sollten möglichst reproduzierbar aufgebaut werden.

Geeignete Maßnahmen können sein:

dokumentierte Konfiguration
Versionsverwaltung
Infrastructure as Code
automatisierte Bereitstellung
standardisierte Images
Konfigurationsmanagement
automatisierte Tests
und nachvollziehbare Abhängigkeiten

Reproduzierbarkeit unterstützt:

Wiederherstellung
Skalierung
Fehleranalyse
Tests
Sicherheit
und spätere Änderungen

Build umfasst Betriebsbereitschaft

Während Build sollten nicht nur Produktfunktionen erstellt werden.

Ebenfalls vorzubereiten sind:

Monitoring
Alarmierung
Protokollierung
Backup
Wiederherstellung
Administrationszugänge
Sicherheitskontrollen
Betriebsdokumentation
Supportinformationen
bekannte Fehler
Kapazitätsgrenzen
und Eskalationsinformationen

Mögliche Ergebnisse von Build

erstellte oder konfigurierte Lösung
integrierte Komponenten
getestete Produktversion
technische Dokumentation
Betriebsdokumentation
automatisierte Bereitstellung
bekannte Fehler und Einschränkungen
Testergebnisse
Sicherheitsnachweise
Monitoring und Protokollierung
vorbereitete Transition

Typische Fehler bei Build

nur den Normalfall testen
produktive Änderungen manuell und undokumentiert durchführen
Betrieb und Support nicht einbeziehen
Konfiguration nicht versionieren
Zugangsdaten unsicher behandeln
keine Wiederherstellung testen
Test- und Produktivumgebung stark voneinander abweichen lassen
bekannte Fehler nicht dokumentieren
eine technisch fertige Lösung automatisch als einsatzbereit betrachten

5. Transition

Zentrale Frage

Wie wird eine neue oder geänderte Lösung kontrolliert in die vorgesehene Nutzung und Verantwortung überführt?

Transition verbindet Entwicklung, Beschaffung und Aufbau mit der tatsächlichen Verwendung, dem Betrieb, der Bereitstellung und dem Support.

Mögliche Bestandteile sind:

Change-Bewertung
Releaseplanung
Deployment
Datenmigration
Pilotbetrieb
Benutzerkommunikation
Schulung
Wissensübergabe
Betriebsfreigabe
Servicevalidierung
Rückfallplanung
und Erfolgskontrolle

Transition ist mehr als Deployment

Deployment beschreibt die technische Übertragung von Komponenten in eine Zielumgebung.

Transition umfasst zusätzlich die organisatorische und servicebezogene Einsatzbereitschaft.

Deployment	Transition
Software wird installiert.	Produkt und Service werden kontrolliert in die Nutzung überführt.
Konfiguration wird verteilt.	Betrieb, Support und Stakeholder sind vorbereitet.
technische Komponente wird aktiviert.	Funktion, Erfahrung, Risiken und Outcomes werden überprüft.
Daten werden migriert.	Datenqualität, Benutzerzugriff und Geschäftsabläufe werden validiert.

Merke

Technisch bereitgestellt bedeutet nicht automatisch betriebsbereit, supportfähig oder für Benutzer nutzbar.

Operational Readiness

Vor einer produktiven Nutzung sollte geprüft werden:

Ist die Lösung ausreichend getestet?
Ist Monitoring aktiv?
Sind Backup und Wiederherstellung vorbereitet?
Sind Rollen und Verantwortlichkeiten bekannt?
Ist der Service Desk informiert?
Existieren Support- und Eskalationswege?
Sind Dokumentationen verfügbar?
Wurden Benutzer informiert oder geschult?
Sind Lizenzen und Verträge gültig?
Ist die Sicherheitsfreigabe erfolgt?
Sind bekannte Einschränkungen akzeptiert?
Ist ein Rückfallplan vorhanden?
Wie wird der Erfolg nach der Einführung kontrolliert?

Leitfragen zu Transition

Was wird überführt?
Welche Produkte und Services sind betroffen?
Welche Stakeholder müssen beteiligt werden?
Welche Risiken bestehen?
Welche Autorisierung ist erforderlich?
Wie wird die Einführung geplant?
Ist ein Pilot sinnvoll?
Welche Daten müssen migriert werden?
Welche Unterbrechungen können entstehen?
Wie werden Benutzer informiert?
Wie werden Betrieb und Support vorbereitet?
Welche Rückfallmöglichkeiten bestehen?
Wer entscheidet über Fortsetzung oder Abbruch?
Wie wird die erfolgreiche Nutzung bestätigt?
Welche Nacharbeiten sind notwendig?

Rückfall und Wiederherstellung

Ein Rückfallplan sollte möglichst klären:

Unter welchen Bedingungen wird zurückgefallen?
Wer darf die Entscheidung treffen?
Wie wird der vorherige Zustand wiederhergestellt?
Welche Datenänderungen müssen berücksichtigt werden?
Wie lange dauert der Rückfall?
Welche Benutzer sind betroffen?
Wie wird kommuniziert?
Wie wird das Ergebnis kontrolliert?

Ein Rückfall ist nicht immer die beste oder technisch mögliche Option.

Bei Datenmigrationen oder unumkehrbaren Änderungen kann stattdessen ein alternativer Wiederherstellungsplan notwendig sein.

Mögliche Ergebnisse von Transition

kontrolliert eingeführte Produktversion
aktivierter Service
migrierte Daten
vorbereiteter Betrieb
vorbereiteter Support
geschulte Beteiligte
aktualisierte Dokumentation
validierte Servicefunktion
dokumentierte Einschränkungen
überwachte Einführungsphase
abgeschlossene oder geplante Nacharbeiten

Typische Fehler bei Transition

Transition mit Installation gleichsetzen
Service Desk und Benutzer zu spät informieren
keine Betriebsbereitschaft prüfen
ungetestete Migration durchführen
Rückfallplan nur formal dokumentieren
Erfolg nur technisch prüfen
bekannte Fehler nicht kommunizieren
Verantwortungsübergabe ohne Wissenstransfer
direkt nach Deployment alle Beteiligten aus dem Vorhaben abziehen

6. Operate

Zentrale Frage

Wie werden Produkte, Plattformen und technische Fähigkeiten zuverlässig, sicher und wirtschaftlich betrieben?

Operate betrachtet den laufenden technischen Betrieb.

Dazu gehören beispielsweise:

Systembetrieb
Überwachung
Wartung
Kapazitätssteuerung
Verfügbarkeitsmanagement
Sicherheitsbetrieb
Backup
Wiederherstellung
Patchmanagement
Jobsteuerung
Verwaltung technischer Konfigurationen
und Behandlung betrieblicher Ereignisse

Operate sorgt dafür, dass die technischen Fähigkeiten vorhanden bleiben, auf denen Services aufbauen.

Operate und Deliver unterscheiden

Operate konzentriert sich stärker auf den laufenden Betrieb der technischen Produkt- und Plattformbestandteile.

Deliver konzentriert sich stärker darauf, Services und Serviceangebote für Stakeholder nutzbar bereitzustellen.

Beispiel: E-Mail

Operate

Mailplattform betreiben
Kapazität überwachen
Sicherheitsupdates installieren
Warteschlangen kontrollieren
Backup und Wiederherstellung sicherstellen
technische Verfügbarkeit überwachen

Deliver

E-Mail-Service für Benutzer bereitstellen
Zugänge und Leistungsumfang steuern
Serviceerwartungen abstimmen
Nutzung und Servicequalität bewerten
Benutzererfahrung berücksichtigen

Beide Aktivitäten überschneiden und beeinflussen sich.

Leitfragen zu Operate

Welche Komponenten müssen betrieben werden?
Welche Betriebsziele gelten?
Wie werden Verfügbarkeit und Leistung überwacht?
Welche Wartungsarbeiten sind notwendig?
Wie werden Patches und Updates durchgeführt?
Wie werden Kapazitätsgrenzen erkannt?
Wie werden Sicherheitsereignisse behandelt?
Funktionieren Backup und Wiederherstellung?
Sind technische Abhängigkeiten bekannt?
Welche Automatisierungen werden überwacht?
Wie werden technische Schulden behandelt?
Welche Bereitschaft oder Rufbereitschaft ist notwendig?
Wie wird bei Lieferantenausfällen reagiert?
Wann muss eine Komponente ersetzt oder abgelöst werden?

Stabilität und Veränderung

Operate bedeutet nicht, technische Systeme möglichst unverändert zu lassen.

Ein stabiler Betrieb benötigt regelmäßig:

Sicherheitsupdates
Kapazitätsanpassungen
Fehlerkorrekturen
Zertifikatserneuerungen
Konfigurationsverbesserungen
Austausch veralteter Komponenten
und Anpassung an neue Anforderungen

Diese Änderungen müssen kontrolliert erfolgen.

Merke

Stabilität entsteht nicht durch Stillstand.

Sie entsteht durch kontrollierte Veränderung, Überwachung und angemessene Wiederherstellungsfähigkeit.

Technische Schulden im Betrieb

Technische Schulden können sich zeigen durch:

nicht unterstützte Software
veraltete Hardware
manuelle Sonderkonfigurationen
fehlende Automatisierung
nicht dokumentierte Abhängigkeiten
dauerhaft verwendete Zwischenlösungen
unsichere Altprotokolle
oder nicht reproduzierbare Systeme

Sie sollten:

sichtbar gemacht,
hinsichtlich Risiko bewertet,
priorisiert,
verantwortet,
und kontrolliert reduziert

werden.

Mögliche Ergebnisse von Operate

laufende technische Fähigkeiten
überwachte Plattformen
durchgeführte Wartung
gesicherte und wiederherstellbare Daten
bekannte Kapazität
behandelte Events
dokumentierte technische Risiken
aktuelle Konfigurationsinformationen
betriebliche Leistungsdaten
identifizierte Verbesserungsmöglichkeiten

Typische Fehler bei Operate

nur auf Verfügbarkeit achten
Warnungen ohne klare Reaktion erzeugen
Backup-Erfolg mit Wiederherstellbarkeit verwechseln
technische Schulden nicht sichtbar machen
Wartung dauerhaft verschieben
Abhängigkeiten nicht dokumentieren
Betrieb ausschließlich reaktiv gestalten
technische Kennzahlen nicht mit Service-Outcomes verbinden

7. Deliver

Zentrale Frage

Wie werden Services und Serviceangebote so bereitgestellt, dass Stakeholder die vorgesehenen Outcomes erreichen können?

Deliver betrachtet die tatsächliche Bereitstellung und Steuerung des Service gegenüber Benutzern, Kunden und weiteren Stakeholdern.

Dazu können gehören:

Serviceangebote
Zugangs- und Nutzungsbereitstellung
Servicebeziehungen
Abstimmung von Erwartungen
Servicequalität
Service Levels
Kommunikation
Erfüllung vereinbarter Leistungen
Benutzererfahrung
und Überprüfung erreichter Outcomes

Technische Verfügbarkeit und Servicebereitstellung

Ein technisches System kann verfügbar sein, während der Service für den Benutzer nicht nutzbar ist.

Beispiele:

Die Anwendung läuft, aber der Benutzer besitzt keine Lizenz.
Das VPN-Gateway ist erreichbar, aber MFA funktioniert nicht.
Der Fileserver ist verfügbar, aber Berechtigungen fehlen.
Die E-Mail-Plattform läuft, aber DNS ist fehlerhaft.
Das Portal ist erreichbar, aber der Geschäftsprozess kann nicht abgeschlossen werden.

Deliver betrachtet deshalb nicht nur technische Funktion, sondern auch die tatsächliche Nutzbarkeit und Leistung des Service.

Leitfragen zu Deliver

Welcher Service wird bereitgestellt?
Welche Serviceangebote bestehen?
Wer darf den Service nutzen?
Welche Outcomes werden erwartet?
Welche Erwartungen und Vereinbarungen gelten?
Welche Zugänge und Ressourcen werden benötigt?
Wie wird die Nutzung ermöglicht?
Welche Qualität wird wahrgenommen?
Welche Servicezeiten und Serviceziele gelten?
Wie werden Abweichungen kommuniziert?
Wie werden Rückmeldungen erfasst?
Werden vereinbarte Leistungen tatsächlich erreicht?
Entspricht der Service weiterhin dem Bedarf?
Welche Verbesserungen sind notwendig?

Serviceangebot

Ein Serviceangebot kann unterschiedliche Bestandteile verbinden:

Waren oder übertragene Ressourcen
Zugang zu Ressourcen
Servicehandlungen

Praxisbeispiel: Arbeitsplatzservice

Mögliche Bestandteile:

Endgerät
Benutzerkonto
Softwarelizenzen
Netzwerkzugang
Dateiablage
E-Mail
Support
Geräteaustausch
Sicherheitsmaßnahmen
und Wartung

Der Benutzer benötigt normalerweise nicht jeden technischen Bestandteil einzeln.

Er benötigt einen arbeitsfähigen Arbeitsplatz als nutzbares Gesamtergebnis.

Servicequalität und Erfahrung

Servicequalität kann sowohl objektive als auch subjektive Aspekte besitzen.

Mögliche objektive Informationen:

Verfügbarkeit
Reaktionszeit
Lösungszeit
Leistung
Fehlerquote
Erfüllungsquote
Wiederherstellungszeit

Mögliche Erfahrungsaspekte:

Verständlichkeit
Zuverlässigkeit aus Benutzersicht
Einfachheit der Nutzung
Qualität der Kommunikation
Vertrauen
wahrgenommene Geschwindigkeit
und Aufwand für den Benutzer

Merke

Ein Service kann technische Zielwerte erfüllen und trotzdem eine schlechte Benutzererfahrung erzeugen.

Mögliche Ergebnisse von Deliver

nutzbarer Service
erfüllte Service Requests
bereitgestellte Zugänge
abgestimmte Erwartungen
gemessene Serviceleistung
bekannte Benutzererfahrung
dokumentierte Serviceabweichungen
aktualisierte Serviceangebote
identifizierte Verbesserungen
erreichte oder teilweise erreichte Outcomes

Typische Fehler bei Deliver

Servicebereitstellung mit technischem Betrieb gleichsetzen
nur interne Kennzahlen verwenden
Benutzererfahrung nicht berücksichtigen
Serviceangebote unverständlich beschreiben
Zugangs- und Berechtigungsprozesse nicht einbeziehen
Leistungen zusagen, die technisch oder organisatorisch nicht unterstützt werden
Servicequalität ohne Stakeholderfeedback bewerten

8. Support

Zentrale Frage

Wie werden Benutzer, Kunden, Produkte und Services bei Fragen, Anfragen, Problemen und Störungen wirksam unterstützt?

Support umfasst die Unterstützung während der Nutzung eines Produkts oder Service.

Dazu können gehören:

Service Desk
Incident-Bearbeitung
Service Requests
technische Unterstützung
Wissensbereitstellung
Kommunikation
Eskalation
Problem Management
Benutzerberatung
und Rückmeldungen an Produkt- und Serviceteams

Support beschränkt sich nicht darauf, Tickets möglichst schnell zu schließen.

Das Ziel besteht darin, negative Auswirkungen zu begrenzen, Nutzung zu ermöglichen und wertvolle Erkenntnisse zurück in den Lebenszyklus zu führen.

Support als Informationsquelle

Support erhält häufig direkte Informationen über:

Benutzerprobleme
unklare Funktionen
wiederkehrende Fehler
fehlende Dokumentation
Schulungsbedarf
schlechte Benutzererfahrung
nicht erfüllte Erwartungen
und Verbesserungspotenzial

Diese Erkenntnisse sollten nicht ausschließlich im einzelnen Ticket bleiben.

Sie können zurückfließen in:

Discover
Design
Build
Operate
Deliver
Problem Management
Knowledge Management
und Continual Improvement

Merke

Support ist nicht nur die letzte Aktivität des Modells.

Support liefert Erkenntnisse für den gesamten Product and Service Lifecycle.

Leitfragen zu Support

Welche Unterstützung benötigen Benutzer und Kunden?
Wie erreichen sie die zuständige Stelle?
Welche Informationen müssen erfasst werden?
Wie werden Incidents und Service Requests unterschieden?
Wie werden Auswirkungen und Dringlichkeit bewertet?
Welche Lösungen und Wissensartikel existieren?
Wann muss eskaliert werden?
Wie werden Benutzer informiert?
Welche Lieferanten müssen eingebunden werden?
Wie wird die Wiederherstellung geprüft?
Welche wiederkehrenden Muster bestehen?
Welche Erkenntnisse müssen an Produkt- und Serviceteams weitergegeben werden?
Wie wird die Supporterfahrung bewertet?
Welche Unterstützung kann verhindert oder vereinfacht werden?

Supportfähigkeit bereits vorher aufbauen

Wirksamer Support benötigt unter anderem:

verständliche Serviceinformationen
eindeutige Kontaktwege
geschulte Mitarbeiter
technische Diagnosemöglichkeiten
Zugriffsberechtigungen
aktuelle Dokumentation
Knowledge-Artikel
Monitoring- und Protokolldaten
bekannte Eskalationswege
Lieferantenkontakte
und klare Verantwortlichkeiten

Diese Voraussetzungen müssen bereits in Design, Build und Transition berücksichtigt werden.

Mögliche Ergebnisse von Support

wiederhergestellte Services
erfüllte Benutzeranfragen
gelöste technische Fragen
bereitgestelltes Wissen
dokumentierte Incidents
identifizierte Probleme
weitergeleitetes Benutzerfeedback
verbesserte Supportinformationen
bekannte Produkt- und Servicefehler
Vorschläge für Continual Improvement

Typische Fehler bei Support

Ticketabschluss mit erreichtem Outcome gleichsetzen
Benutzer mehrfach dieselben Informationen liefern lassen
nur Symptome behandeln
bekannte Lösungen nicht dokumentieren
wiederkehrende Incidents nicht an Problem Management übergeben
Support nicht vor Releases informieren
Benutzerfeedback nicht weiterverwenden
interne Kennzahlen wichtiger behandeln als die tatsächliche Wiederherstellung

Zusammenwirken der acht Aktivitäten

Praxisbeispiel: Einführung eines neuen sicheren Fernzugriffs

Discover

Bedarf an Remote-Arbeit verstehen
Benutzergruppen und Anwendungen bestimmen
bisherige Probleme und Risiken untersuchen
gewünschte Outcomes festlegen

Design

VPN- oder Zero-Trust-Lösung gestalten
Identität, MFA, Endgeräte und Support einplanen
Sicherheits-, Verfügbarkeits- und Erfahrungsanforderungen definieren

Acquire

Plattform, Lizenzen und Supportleistungen beschaffen
benötigte Schulungen und externe Fähigkeiten organisieren

Build

Systeme konfigurieren
Integrationen erstellen
Sicherheitsregeln, Monitoring und Dokumentation aufbauen
Funktion, Leistung und Wiederherstellung testen

Transition

Pilotgruppe einführen
Benutzer und Service Desk vorbereiten
Daten und Konfigurationen überführen
Rückfall- und Kommunikationsplan bereitstellen

Operate

Gateways, Identitätsdienste und Zertifikate betreiben
Leistung, Sicherheit und Kapazität überwachen
Updates und Wartung durchführen

Deliver

Fernzugriffsservice für berechtigte Benutzer bereitstellen
Serviceerwartungen und Nutzungsbedingungen kommunizieren
Qualität und Erfahrung bewerten

Support

Anmeldeprobleme und Anfragen bearbeiten
Wissen bereitstellen
wiederkehrende Fehler untersuchen
Feedback an Produkt- und Serviceteams zurückführen

Continual Improvement über den gesamten Lifecycle

Continual Improvement ist nicht auf das Ende des Lebenszyklus beschränkt.

Jede Aktivität kann verbessert werden.

Lifecycle-Aktivität	Beispiel für eine Verbesserung
Discover	Benutzerfeedback früher und systematischer erfassen
Design	Betriebs- und Sicherheitsanforderungen früher berücksichtigen
Acquire	Exit-Anforderungen in Lieferantenbewertungen aufnehmen
Build	Tests und Bereitstellung stärker automatisieren
Transition	Pilot- und Rückfallverfahren verbessern
Operate	wiederkehrende Wartung automatisieren
Deliver	Serviceangebote verständlicher gestalten
Support	bekannte Lösungen schneller auffindbar machen

Erkenntnisse aus späteren Aktivitäten können frühere Aktivitäten erneut auslösen.

Beispiel:

Support erkennt viele Anfragen zu einer unverständlichen Funktion.

Dies kann führen zu:

erneutem Discover der Benutzerbedürfnisse,
angepasstem Design,
verändertem Build,
neuer Transition,
und verbesserter Bereitstellung.

Governance über den gesamten Lifecycle

Governance wirkt auf alle acht Aktivitäten.

Zu klären sind unter anderem:

Welche Ziele und Prioritäten gelten?
Wer besitzt Entscheidungsbefugnis?
Welche Risiken dürfen akzeptiert werden?
Welche gesetzlichen und vertraglichen Anforderungen gelten?
Welche Kontrollen sind notwendig?
Wie werden Investitionen priorisiert?
Wie werden Ergebnisse überwacht?
Wer trägt Verantwortung für Produkt und Service?
Wann muss eine Aktivität erneut bewertet werden?
Wann muss ein Produkt oder Service beendet werden?

Governance sollte nicht erst bei der produktiven Einführung beginnen.

Ungeeignete Grundentscheidungen in Discover, Design oder Acquire können später nur mit hohem Aufwand korrigiert werden.

Die Guiding Principles im Lifecycle

Guiding Principle	Anwendung im Lifecycle
Focus on value	jede Aktivität am benötigten Outcome ausrichten
Start where you are	bestehende Produkte, Fähigkeiten und Daten berücksichtigen
Progress iteratively with feedback	Versionen, Piloten und kontrollierte Schritte verwenden
Collaborate and promote visibility	Produkt-, Service-, Betriebs- und Supportteams verbinden
Think and work holistically	alle acht Aktivitäten und vier Dimensionen berücksichtigen
Keep it simple and practical	unnötige Übergaben und Komplexität vermeiden
Optimize and automate	Arbeitsweisen verbessern und geeignete Teile automatisieren

Künstliche Intelligenz im Lifecycle

KI kann in allen Lifecycle-Aktivitäten verwendet werden.

Beispiele:

Aktivität	Mögliche KI-Unterstützung
Discover	Muster in Feedback und Nutzungsdaten erkennen
Design	Varianten analysieren oder Prototypen unterstützen
Acquire	Angebote und Anforderungen vergleichen
Build	Code-, Konfigurations- oder Testunterstützung
Transition	Risiken und Migrationsdaten analysieren
Operate	Anomalien und mögliche Ausfälle erkennen
Deliver	Services personalisieren oder Interaktionen unterstützen
Support	Tickets klassifizieren und Lösungsvorschläge bereitstellen

Dabei bleiben notwendig:

klare Verantwortlichkeit
Datenqualität
Datenschutz
Informationssicherheit
menschliche Kontrolle
Überwachung
Nachvollziehbarkeit
und Risikobewertung

Sicherheitsrelevant

KI-Unterstützung ersetzt nicht die Verantwortung der zuständigen Personen und Organisation.

Wo befindet sich die Außerbetriebnahme?

Das offizielle ITIL-Version-5-Modell nennt acht Aktivitäten und enthält keine separate neunte Aktivität mit der Bezeichnung Retire.

Die Ablösung oder Außerbetriebnahme eines Produkts oder Service muss trotzdem kontrolliert gestaltet werden.

Dazu können Beiträge aus mehreren Aktivitäten gehören:

Discover

Warum soll die bisherige Lösung beendet werden?
Welche Stakeholder und Abhängigkeiten sind betroffen?

Design

Wie sieht die Ziel- oder Übergangslösung aus?
Welche Archivierungs- und Aufbewahrungsanforderungen gelten?

Acquire und Build

Welche Ersatzlösung und Migrationswerkzeuge werden benötigt?

Transition

Wie werden Benutzer, Daten und Abhängigkeiten überführt?
Wie wird die alte Lösung kontrolliert deaktiviert?

Operate

Wie lange muss die Altumgebung parallel betrieben werden?
Wie werden Restzugriffe und technische Risiken überwacht?

Deliver und Support

Wie werden Serviceangebote, Benutzerinformationen und Support angepasst?
Wie werden Fragen während der Ablösung behandelt?

Zusätzlich können Practices wie folgende beteiligt sein:

Change Management
IT Asset Management
Service Configuration Management
Information Security Management
Supplier Management
Knowledge Management
und Continual Improvement

Wichtig

Außerbetriebnahme bedeutet nicht nur, ein System auszuschalten.

Daten, Zugänge, Verträge, Assets, Dokumentationen, Abhängigkeiten und Sicherheitsanforderungen müssen ebenfalls behandelt werden.

Anwendung bei einem Incident

Ein Incident findet hauptsächlich während Operate, Deliver oder Support statt.

Seine Erkenntnisse können jedoch den gesamten Lifecycle beeinflussen.

Beispiel:

Ein Zertifikat läuft ab und verursacht einen Serviceausfall.

Support

Incident erfassen
Benutzer informieren
Wiederherstellung koordinieren

Operate

Zertifikat erneuern
Systeme und Abhängigkeiten kontrollieren

Discover

untersuchen, warum das Risiko nicht rechtzeitig erkannt wurde

Design

Zertifikatsverwaltung und Verantwortlichkeiten verbessern

Acquire

falls notwendig geeignetes Zertifikats- oder Monitoring-Werkzeug beschaffen

Build

automatisierte Erfassung und Alarmierung erstellen

Transition

neue Überwachung kontrolliert einführen

Deliver

prüfen, ob der Service wieder vollständig nutzbar ist

Anwendung bei einem Change

Ein Change kann mehrere Lifecycle-Aktivitäten betreffen.

Beispiel: Datenbank-Upgrade

Discover: Notwendigkeit, Risiken und Abhängigkeiten verstehen
Design: Zielversion, Architektur und Migrationsweg festlegen
Acquire: Lizenzen, Support oder zusätzliche Ressourcen beschaffen
Build: Zielumgebung konfigurieren und Migration testen
Transition: Upgrade kontrolliert durchführen
Operate: neue Version überwachen und warten
Deliver: Servicefunktion und Leistung aus Stakeholdersicht prüfen
Support: bekannte Fehler und Benutzerfragen bearbeiten

Merke

Change Management unterstützt die kontrollierte Veränderung.

Der Product and Service Lifecycle zeigt den größeren Zusammenhang, in dem die Veränderung stattfindet.

Anwendung bei einem kleinen Standardservice

Nicht jede Servicebereitstellung benötigt ein umfangreiches Projekt.

Beispiel: Standardsoftware für einen Mitarbeiter bereitstellen

Discover

benötigte Software und geschäftlichen Zweck klären

Design

vorgesehenes Standardpaket und Berechtigungsmodell verwenden

Acquire

vorhandene Lizenz zuordnen oder zusätzliche Lizenz beschaffen

Build

Softwarepaket und Konfiguration bereitstellen

Transition

kontrolliert auf das Endgerät verteilen

Operate

Plattform und Paketverwaltung betreiben

Deliver

Anwendung für den Benutzer freischalten

Support

Installation und Nutzung bei Bedarf unterstützen

Bei einem standardisierten und risikoarmen Fall können viele Schritte automatisiert und sehr kompakt ausgeführt werden.

Typische Missverständnisse

Missverständnis 1: Die Aktivitäten werden immer einmal nacheinander durchgeführt

Tatsächlich können sie wiederholt, übersprungen, kombiniert oder gleichzeitig durchgeführt werden.

Missverständnis 2: Nach Transition beginnt ausschließlich der Betrieb

Auch während Operate, Deliver und Support können neue Discovery-, Design- und Build-Aktivitäten stattfinden.

Missverständnis 3: Build bedeutet nur Softwareentwicklung

Build kann auch Installation, Konfiguration, Integration, Automatisierung und technische Tests umfassen.

Missverständnis 4: Acquire bedeutet nur Einkauf

Acquire kann auch interne Ressourcen, Fähigkeiten, Daten, Lizenzen und wiederverwendete Komponenten umfassen.

Missverständnis 5: Operate und Deliver bedeuten dasselbe

Operate konzentriert sich stärker auf den technischen Betrieb. Deliver betrachtet stärker die tatsächliche Servicebereitstellung und das Stakeholder-Outcome.

Missverständnis 6: Support beginnt erst nach der Einführung

Supportfähigkeit muss bereits während Design, Build und Transition vorbereitet werden.

Missverständnis 7: Lifecycle und Value Stream sind identisch

Der Lifecycle stellt allgemeine Aktivitäten bereit. Ein Value Stream verbindet konkrete Schritte für ein bestimmtes Outcome.

Missverständnis 8: Ein Produkt ist nach dem ersten Release fertig

Digitale Produkte und Services werden weiter betrieben, unterstützt, verändert und verbessert.

Missverständnis 9: Eine erfolgreiche Transition beendet die Verantwortung des Produktteams

Produkt-, Service-, Betriebs- und Supportverantwortung müssen weiterhin zusammenarbeiten.

Missverständnis 10: Das Modell besitzt automatisch für jede Organisation dieselben Rollen

Die konkrete Rollenverteilung wird von der jeweiligen Organisation gestaltet.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sind nicht nur in Operate und Support beteiligt.

Sie können Beiträge über den gesamten Lifecycle leisten.

Aktivität	Möglicher Beitrag
Discover	technische Ausgangslage und bestehende Probleme erklären
Design	Architektur, Betrieb, Sicherheit und Wiederherstellung mitgestalten
Acquire	technische Anforderungen an Produkte und Lieferanten bewerten
Build	Systeme installieren, konfigurieren, integrieren und testen
Transition	Migration, Deployment und Betriebsübernahme unterstützen
Operate	Infrastruktur und Plattformen betreiben
Deliver	Servicebereitstellung und Nutzbarkeit sicherstellen
Support	Incidents, Anfragen und technische Probleme bearbeiten

Praxistipp

Bringe Betriebs- und Supportwissen möglichst früh ein.

Viele spätere Probleme können bereits während Discover, Design und Build verhindert werden.

30-Sekunden-Prüfung

Bei einem Produkt, Service oder Change kannst du acht Kurzfragen stellen:

Discover: Verstehen wir den tatsächlichen Bedarf?
Design: Ist die Gesamtlösung einschließlich Betrieb und Support gestaltet?
Acquire: Sind alle notwendigen Ressourcen und Fähigkeiten verfügbar?
Build: Wurde die Lösung erstellt, integriert und ausreichend getestet?
Transition: Kann sie kontrolliert und mit Rückfallmöglichkeit eingeführt werden?
Operate: Kann sie zuverlässig und sicher betrieben werden?
Deliver: Ist der Service für Stakeholder tatsächlich nutzbar?
Support: Können Benutzer und Service wirksam unterstützt werden?

Checkliste zu Discover

Ist das zugrunde liegende Bedürfnis verstanden?
Sind Stakeholder und gewünschte Outcomes bekannt?
Wurde der aktuelle Zustand untersucht?
Sind Daten und Rückmeldungen verfügbar?
Sind Chancen, Risiken und Einschränkungen bekannt?
Wurden bestehende Lösungen berücksichtigt?
Sind Annahmen und Unsicherheiten dokumentiert?
Ist klar, wie Erfolg bewertet wird?

Checkliste zu Design

Sind funktionale und nichtfunktionale Anforderungen berücksichtigt?
Wurden alle vier Dimensionen betrachtet?
Sind Sicherheit und Datenschutz integriert?
Sind Betrieb, Monitoring und Wiederherstellung gestaltet?
Sind Support und Benutzererfahrung berücksichtigt?
Sind Rollen und Fähigkeiten geklärt?
Sind Lieferantenanforderungen bekannt?
Ist die spätere Ablösung berücksichtigt?

Checkliste zu Acquire

Ist bekannt, welche Ressourcen benötigt werden?
Wurden vorhandene Ressourcen und Fähigkeiten geprüft?
Wurde Make, Buy, Reuse oder Partner angemessen bewertet?
Sind Gesamtbetriebskosten berücksichtigt?
Sind Lizenzen und Nutzungsrechte geklärt?
Sind Sicherheit und Datenschutz vertraglich berücksichtigt?
Sind Support- und Eskalationswege vereinbart?
Besteht eine Exit- und Übergangsplanung?

Checkliste zu Build

Entspricht die Umsetzung dem Design?
Sind Konfigurationen nachvollziehbar und reproduzierbar?
Sind Schnittstellen und Abhängigkeiten getestet?
Wurden Sicherheitsanforderungen umgesetzt?
Wurden Funktion, Leistung und Wiederherstellung getestet?
Sind Monitoring und Protokollierung vorbereitet?
Sind Dokumentationen vorhanden?
Sind bekannte Fehler und Einschränkungen erfasst?

Checkliste zu Transition

Ist die Lösung ausreichend getestet?
Sind Change und Autorisierung geklärt?
Sind Betrieb und Support vorbereitet?
Sind Benutzer und Stakeholder informiert?
Ist die Datenmigration geprüft?
Besteht ein geeigneter Rückfall- oder Wiederherstellungsplan?
Sind Verantwortlichkeiten während der Einführung eindeutig?
Wird das Ergebnis nach der Einführung überwacht?
Wird die Nutzbarkeit aus Stakeholdersicht bestätigt?

Checkliste zu Operate

Sind Betriebsverantwortlichkeiten eindeutig?
Werden Verfügbarkeit, Leistung und Kapazität überwacht?
Sind Wartung und Patchmanagement geregelt?
Funktionieren Backup und Wiederherstellung?
Werden Sicherheitsereignisse behandelt?
Sind technische Abhängigkeiten bekannt?
Werden technische Schulden sichtbar gemacht?
Bestehen geeignete Eskalations- und Bereitschaftswege?
Fließen Betriebsdaten in Verbesserungen ein?

Checkliste zu Deliver

Ist der Service für berechtigte Stakeholder nutzbar?
Sind Serviceangebot und Leistungsumfang verständlich?
Sind Erwartungen und Vereinbarungen abgestimmt?
Werden Serviceleistung und Outcomes gemessen?
Wird die Benutzer- und Kundenerfahrung berücksichtigt?
Werden Abweichungen transparent kommuniziert?
Sind Zugangs- und Berechtigungswege wirksam?
Wird geprüft, ob der Service weiterhin zum Bedarf passt?

Checkliste zu Support

Existiert ein eindeutiger Kontaktweg?
Sind Mitarbeiter, Werkzeuge und Informationen vorbereitet?
Sind Incident und Service Request richtig einzuordnen?
Sind Auswirkungen und Dringlichkeit nachvollziehbar?
Sind Wissen und Diagnoseinformationen verfügbar?
Sind Eskalations- und Lieferantenwege bekannt?
Wird die Wiederherstellung aus Benutzersicht geprüft?
Werden wiederkehrende Muster erkannt?
Fließen Erkenntnisse in Produkt, Service und Verbesserung zurück?

Gesamtcheck für den Product and Service Lifecycle

Schnellreferenz

Aktivität	Kurzfrage
Discover	Was wird benötigt und warum?
Design	Wie muss die Gesamtlösung gestaltet sein?
Acquire	Welche Ressourcen und Fähigkeiten werden benötigt?
Build	Wie wird die Lösung erstellt und getestet?
Transition	Wie wird sie kontrolliert in die Nutzung überführt?
Operate	Wie wird sie zuverlässig und sicher betrieben?
Deliver	Wie wird der Service für Stakeholder nutzbar bereitgestellt?
Support	Wie werden Benutzer, Produkt und Service unterstützt?

Zusammenfassende Darstellung

Discover
Bedarf, Chancen und Ausgangslage verstehen
↓
Design
Produkt, Service und Gesamtlösung gestalten
↓
Acquire
Ressourcen, Produkte und Fähigkeiten beschaffen
↓
Build
erstellen, konfigurieren, integrieren und testen
↓
Transition
kontrolliert in die vorgesehene Nutzung überführen
↓
Operate
technische Fähigkeiten zuverlässig betreiben
↓
Deliver
Services für Stakeholder bereitstellen
↓
Support
Benutzer, Produkte und Services unterstützen
↓
Feedback und Continual Improvement
↓
erneutes Discover, Design oder eine andere benötigte Aktivität

Die Darstellung dient als Lernhilfe.

Das offizielle Modell ist nicht starr oder ausschließlich linear. Jede Aktivität kann Erkenntnisse für jede andere Aktivität liefern.

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen
Change Management
Deployment Management
Release Management
Service Design
Service Desk
Incident Management
Supplier Management
Monitoring and Event Management

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL Version 5 verwendet einen gemeinsamen Product and Service Lifecycle mit acht Aktivitäten:

Discover
Design
Acquire
Build
Transition
Operate
Deliver
Support

Die offiziellen Veröffentlichungen beschreiben das Modell als ganzheitlich, flexibel und nicht starr linear.

Aktivitäten können sich gegenseitig beeinflussen, wiederholt werden und für unterschiedliche Versionen eines Produkts oder Service gleichzeitig stattfinden.

Die detaillierten Leitfragen, Beispiele, Checklisten und praktischen Einordnungen auf dieser Seite sind eigene herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebenen Arbeitsabläufe dar.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.7 Die ITIL Management Practices

Kurz erklärt

ITIL Management Practices bündeln organisatorische Ressourcen und Fähigkeiten, die für einen bestimmten Zweck eingesetzt werden.

Eine Practice umfasst deshalb nicht nur einen Prozess.

Si:contentReference[oaicite:0]{index=0}chen und Rollen,

Fähigkeiten und Wissen,

Informationen und Daten,

Wertströme und Prozesse,

Technologien und Werkzeuge,

Partner und Lieferanten,

Regeln und Kontrollen,

Messgrößen,

sowie Verbesserungsmaßnahmen.

ITIL Version 5 führt weiterhin 34 Management Practices. Sie wurden gegenüber ITIL 4 nicht vollständig ersetzt, sondern weitgehend fortgeführt und an den neuen Produkt- und Servicekontext angepasst.

Warum Management Practices notwendig sind

Digitale Produkte und Services benötigen unterschiedliche organisatorische Fähigkeiten.

Beispiele:

Incidents müssen erkannt und bearbeitet werden.
Benutzer benötigen einen eindeutigen Kontaktweg.
Änderungen müssen hinsichtlich Nutzen und Risiken bewertet werden.
technische Komponenten und Abhängigkeiten müssen bekannt sein.
Wissen muss verfügbar und aktuell sein.
Lieferanten müssen gesteuert werden.
Sicherheitsanforderungen müssen berücksichtigt werden.
wiederkehrende Fehler müssen nachhaltig untersucht werden.
Serviceleistung und Erfahrungen müssen ausgewertet werden.
Verbesserungen müssen geplant und umgesetzt werden.

Eine einzelne Abteilung oder ein einzelner Prozess kann diese Aufgaben normalerweise nicht vollständig erfüllen.

Management Practices stellen deshalb strukturierte Fähigkeiten bereit, die in unterschiedlichen Wertströmen miteinander kombiniert werden können.

Merke

Eine Practice beschreibt eine organisatorische Fähigkeit.

Ein konkreter Wertstrom verwendet die benötigten Practices, um ein bestimmtes Outcome zu erreichen.

Practice, Prozess, Team und Werkzeug unterscheiden

Diese Begriffe dürfen nicht gleichgesetzt werden.

Begriff	Bedeutung
Management Practice	organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Prozess	strukturierte Folge von Aktivitäten, die Eingaben in Ergebnisse überführt
Value Stream	Ende-zu-Ende-Abfolge von Schritten zur Ermöglichung eines bestimmten Outcomes
Team	Gruppe von Personen, die bestimmte Aufgaben oder Verantwortlichkeiten übernimmt
Rolle	definierte Verantwortung, Befugnis oder Tätigkeit
Werkzeug	technische Unterstützung für Informationen, Kommunikation, Automatisierung oder Kontrolle
Arbeitsanweisung	konkrete Beschreibung, wie eine bestimmte Tätigkeit ausgeführt wird

Beispiel: Incident Management

Die Practice kann enthalten:

Rollen und Verantwortlichkeiten,
Priorisierungskriterien,
Eskalationswege,
Kommunikationsregeln,
Wissen,
Ticketsystem,
Monitoring-Informationen,
Lieferantenkontakte,
Messgrößen,
und Verbesserungsaktivitäten.

Ein Prozess kann beschreiben:

Incident erfassen
Auswirkungen und Dringlichkeit bewerten
kategorisieren
zuständige Bearbeitung zuweisen
untersuchen und diagnostizieren
Service wiederherstellen
Ergebnis prüfen
dokumentieren und abschließen

Ein Team kann sein:

Service Desk,
Netzwerkteam,
Anwendungsteam,
Infrastrukturteam,
externer Provider,
oder eine bereichsübergreifende Incident-Gruppe.

Ein Werkzeug kann sein:

Ticketsystem,
Monitoring-Plattform,
Kommunikationsplattform,
Wissensdatenbank,
oder Automatisierungslösung.

Typischer Fehler

Eine Practice wird eingeführt, indem lediglich ein entsprechendes Modul im Ticketsystem aktiviert wird.

Ein Werkzeug kann eine Practice unterstützen, aber fehlende Verantwortung, Fähigkeiten, Informationen und Zusammenarbeit nicht ersetzen.

Die vier Dimensionen innerhalb einer Practice

Jede Practice sollte ganzheitlich über die vier Dimensionen betrachtet werden.

Dimension	Beispielhafte Inhalte einer Practice
Organizations and People	Rollen, Fähigkeiten, Kapazität, Kommunikation und Verantwortung
Information and Technology	Daten, Wissen, Ticketsysteme, Monitoring und Automatisierung
Partners and Suppliers	externe Supportpartner, Hersteller, Provider und Verträge
Value Streams and Processes	Aktivitäten, Übergaben, Kontrollen und Arbeitsergebnisse

Beispiel: Monitoring and Event Management

Organizations and People

Wer überwacht die Meldungen?
Wer entscheidet über die notwendige Reaktion?
Besteht ausreichende Bereitschaft und Fachkenntnis?

Information and Technology

Welche Systeme werden überwacht?
Sind Messwerte und Schwellenwerte zuverlässig?
Wie werden Events korreliert und gespeichert?

Partners and Suppliers

Welche Provider liefern eigene Meldungen?
Wie werden Störungen externer Services eskaliert?

Value Streams and Processes

Wie wird aus einem relevanten Event eine Handlung?
Wann wird ein Incident erfasst?
Wie werden Fehlalarme verbessert?

Management Practices sind keine isolierten Silos

Eine Practice arbeitet normalerweise nicht allein.

Bei einer realen Situation können mehrere Practices zusammenwirken.

Beispiel: Eine Unternehmensanwendung fällt nach einem Update aus.

Monitoring and Event Management erkennt eine Zustandsänderung.
Incident Management koordiniert die Wiederherstellung.
Service Desk dient als Kontakt- und Kommunikationspunkt.
Service Configuration Management liefert Informationen über Abhängigkeiten.
Knowledge Management stellt bekannte Diagnose- und Wiederherstellungsschritte bereit.
Supplier Management bindet gegebenenfalls den Hersteller ein.
Problem Management untersucht die zugrunde liegende Ursache.
Change Enablement unterstützt die kontrollierte dauerhafte Korrektur.
Release Management plant die Bereitstellung einer korrigierten Version.
Deployment Management überträgt die korrigierten Komponenten in die Zielumgebung.
Service Validation and Testing prüft die neue oder geänderte Lösung.
Continual Improvement leitet Verbesserungen für Tests, Monitoring und Arbeitsweisen ab.

Merke

Ein Vorgang gehört nicht immer nur zu einer Practice.

Die benötigten Practices werden entsprechend dem tatsächlichen Wertstrom miteinander verbunden.

Änderungen gegenüber ITIL 4

ITIL Version 5 führt die 34 Management Practices weitgehend fort.

Sie werden im aktuellen Framework in zwei übergeordneten Gruppen organisiert:

Product and Service Management Practices
General Management Practices

Die frühere ITIL-4-Einteilung in:

General Management Practices,
Service Management Practices,
und Technical Management Practices

soll deshalb nicht ungeprüft als aktuelle ITIL-Version-5-Struktur übernommen werden.

Die öffentlich zugänglichen offiziellen Übersichtsseiten bestätigen die neue Einteilung in zwei Gruppen, veröffentlichen dort jedoch keine vollständige frei zugängliche Zuordnung aller 34 Practices zu diesen beiden Gruppen.

Die detaillierten aktuellen Practice Guides werden über PeopleCert Plus bereitgestellt.

Wichtig

Diese Seite führt die 34 Practices deshalb alphabetisch auf.

Sie behauptet keine nicht ausreichend öffentlich belegte Einzelzuordnung zu den beiden neuen Gruppen.

Hinweis zur Bezeichnung Change Enablement

Die aktuelle offizielle ITIL-Version-5-Übersicht zum Practice-Manager-Pfad verwendet weiterhin die Bezeichnung Change Enablement.

In anderen offiziellen Überblickstexten wird teilweise allgemein von change management gesprochen.

Solange die konkrete aktuelle Practice Guidance keine eindeutig abweichende offizielle Practice-Bezeichnung vorgibt, verwendet dieses Buch deshalb:

Change Enablement

Change Management kann weiterhin als allgemeiner organisatorischer Oberbegriff oder als betriebliche Bezeichnung vorkommen.

Versionsabhängig

Eine betriebliche Organisation kann weiterhin eigene Begriffe wie Change Management, Änderungsmanagement oder Change-Prozess verwenden.

Entscheidend ist, dass Zweck, Verantwortlichkeiten und Arbeitsweise eindeutig sind.

Die 34 ITIL Management Practices im Überblick

Die folgenden Kurzbeschreibungen sind praxisnahe Zusammenfassungen in eigenen Worten.

Sie ersetzen nicht die vollständigen offiziellen Practice Guides.

Nr.	Management Practice	Praxisnahe Kurzbeschreibung
1	Architecture Management	aktuelle und zukünftige Strukturen, Beziehungen und Architekturentscheidungen nachvollziehbar gestalten
2	Availability Management	sicherstellen, dass Produkte und Services die benötigte und vereinbarte Verfügbarkeit unterstützen
3	Business Analysis	Bedürfnisse, Probleme und Anforderungen untersuchen und geeignete Lösungsoptionen unterstützen
4	Capacity and Performance Management	ausreichende Kapazität und Leistung für aktuelle und zukünftige Anforderungen sicherstellen
5	Change Enablement	erfolgreiche Änderungen durch angemessene Bewertung, Autorisierung und Steuerung unterstützen
6	Continual Improvement	Produkte, Services, Practices und Arbeitsweisen fortlaufend an veränderte Bedürfnisse anpassen
7	Deployment Management	neue oder geänderte Komponenten kontrolliert in Zielumgebungen übertragen
8	Incident Management	negative Auswirkungen von Incidents verringern und den normalen Servicebetrieb angemessen schnell wiederherstellen
9	Information Security Management	Informationen und unterstützende Systeme entsprechend den Sicherheitsanforderungen schützen
10	Infrastructure and Platform Management	Infrastruktur- und Plattformressourcen über ihren Lebenszyklus planen, betreiben und verbessern
11	IT Asset Management	IT-Assets über ihren Lebenszyklus steuern, um Wert, Kosten, Risiken und Entscheidungen zu unterstützen
12	Knowledge Management	benötigtes Wissen und Informationen wirksam erfassen, pflegen, teilen und verwenden
13	Measurement and Reporting	verlässliche Messungen und Berichte für Entscheidungen, Steuerung und Verbesserung bereitstellen
14	Monitoring and Event Management	Produkte, Services und Komponenten systematisch beobachten und relevante Zustandsänderungen behandeln
15	Organizational Change Management	menschliche und organisatorische Veränderungen so unterstützen, dass neue Arbeitsweisen angenommen und dauerhaft genutzt werden
16	Portfolio Management	Investitionen, Produkte, Services, Programme und Projekte auf Strategie, Wert und verfügbare Ressourcen ausrichten
17	Problem Management	Ursachen und Wahrscheinlichkeiten von Incidents reduzieren sowie bekannte Fehler und Workarounds verwalten
18	Project Management	zeitlich begrenzte Vorhaben strukturiert planen, steuern und abschließen
19	Relationship Management	Beziehungen zu Stakeholdern aufbauen, pflegen und für gemeinsame Outcomes nutzen
20	Release Management	neue oder geänderte Produkte, Services und Funktionen für die vorgesehene Nutzung verfügbar machen
21	Risk Management	Risiken identifizieren, bewerten, behandeln, überwachen und angemessen kommunizieren
22	Service Catalogue Management	verlässliche und verständliche Informationen über Services und Serviceangebote bereitstellen
23	Service Configuration Management	zuverlässige Informationen über Services, Configuration Items und deren Beziehungen verfügbar machen
24	Service Continuity Management	ausreichende Servicefähigkeit nach schwerwiegenden Störungen oder Katastrophen vorbereiten und erhalten
25	Service Design	Produkte und Services ganzheitlich so gestalten, dass sie zweckmäßig, nutzbar und nachhaltig betreibbar sind
26	Service Desk	zentralen Kontakt, Kommunikation sowie Unterstützung für Benutzer und Kunden ermöglichen
27	Service Financial Management	finanzielle Informationen, Planung und Kontrolle für Produkte, Services und Entscheidungen unterstützen
28	Service Level Management	verständliche, geschäftsbezogene Serviceziele vereinbaren und deren Erfüllung steuern
29	Service Request Management	vereinbarte und häufig standardisierte Benutzeranfragen wirksam bearbeiten
30	Service Validation and Testing	prüfen, ob neue oder geänderte Produkte und Services definierte Anforderungen und Nutzungsbedürfnisse erfüllen
31	Software Development and Management	Software so entwickeln und verwalten, dass sie Anforderungen, Qualität, Wartbarkeit und Compliance unterstützt
32	Strategy Management	Ziele, Ausrichtung und geeignete Handlungsoptionen für die Organisation entwickeln
33	Supplier Management	Lieferanten, Verträge, Leistungen und Beziehungen angemessen steuern
34	Workforce and Talent Management	sicherstellen, dass ausreichend geeignete Menschen, Fähigkeiten und Entwicklungsmöglichkeiten vorhanden sind

Nicht jede Practice muss gleich stark ausgeprägt sein

Eine Organisation muss nicht jede Practice:

als eigene Abteilung,
mit einem eigenen Practice Owner,
mit einem umfangreichen Prozess,
oder mit einem separaten Werkzeugmodul

aufbauen.

Der benötigte Umfang hängt unter anderem ab von:

Größe der Organisation,
Produkten und Services,
Risiken,
gesetzlichen Anforderungen,
Anzahl der Benutzer,
Lieferantenabhängigkeiten,
vorhandenen Fähigkeiten,
technischer Komplexität,
und strategischer Bedeutung.

Beispiel:

Ein kleines Unternehmen kann Supplier Management durch:

klar dokumentierte Verträge,
eindeutige Ansprechpartner,
regelmäßige Leistungsprüfungen,
und vorbereitete Eskalationswege

umsetzen.

Eine große Organisation benötigt möglicherweise zusätzlich:

mehrere Supplier Manager,
formalisierte Lieferantenbewertungen,
Risikokategorien,
regelmäßige Reviews,
Vertragsdatenbanken,
Auditverfahren,
und strategische Lieferantenprogramme.

Grundsatz

Eine Practice muss wirksam und angemessen sein.

Sie muss nicht möglichst groß oder kompliziert sein.

Foundation-Wissen und vollständige Practice Guidance unterscheiden

Die ITIL Foundation vermittelt:

grundlegende Begriffe,
zentrale Zwecke,
wichtige Zusammenhänge,
und ausgewählte Practice-Terminologie.

Die vollständige Practice Guidance kann darüber hinaus behandeln:

Erfolgsfaktoren,
Practice-Prozesse,
Aktivitäten,
Rollen,
Informationen,
Technologien,
Partner,
Messgrößen,
Wertströme,
Reife und Fähigkeiten,
Automatisierung,
und Verbesserung.

Wichtig

Eine kurze Foundation-Definition reicht nicht aus, um eine vollständige betriebliche Practice zu gestalten.

Für eine praktische Einführung werden zusätzlich benötigt:

Analyse des aktuellen Zustands,
Ziele und Outcomes,
betriebliche Anforderungen,
Rollen und Befugnisse,
konkrete Wertströme,
Werkzeuge,
Daten,
Schulungen,
Messgrößen,
und ein Verbesserungsplan.

Zertifizierungsbezogene Practice-Bündel

Die aktuelle offizielle Practice-Manager-Struktur verwendet drei Bündel mit jeweils fünf Practices.

Diese Bündel sind für die Zertifizierungsstruktur relevant.

Sie sind nicht mit den zwei übergeordneten Practice-Gruppen von ITIL Version 5 gleichzusetzen.

Monitor, Support and Fulfil

Enthaltene Practices:

Service Desk
Incident Management
Problem Management
Service Request Management
Monitoring and Event Management

Gemeinsamer praktischer Schwerpunkt:

Zustände erkennen,
Benutzerkontakte ermöglichen,
Störungen bearbeiten,
Anfragen erfüllen,
wiederkehrende Ursachen reduzieren,
und Erkenntnisse aus dem laufenden Betrieb verwenden.

Plan, Implement and Control

Enthaltene Practices:

Change Enablement
Deployment Management
Release Management
Service Configuration Management
IT Asset Management

Gemeinsamer praktischer Schwerpunkt:

Veränderungen vorbereiten,
Risiken und Abhängigkeiten verstehen,
Komponenten kontrolliert bereitstellen,
Releases verfügbar machen,
und Informationen über Assets sowie Konfigurationen pflegen.

Collaborate, Assure and Improve

Enthaltene Practices:

Relationship Management
Supplier Management
Service Level Management
Continual Improvement
Information Security Management

Gemeinsamer praktischer Schwerpunkt:

Beziehungen und Erwartungen gestalten,
Lieferanten steuern,
Serviceziele vereinbaren,
Informationssicherheit unterstützen,
und Verbesserungen fortlaufend umsetzen.

Hinweis

Die übrigen Practices bleiben weiterhin Bestandteil der insgesamt 34 ITIL Management Practices, auch wenn sie nicht in diesen drei Practice-Manager-Bündeln enthalten sind.

Wichtige Practices für Fachinformatiker für Systemintegration

Für Fachinformatiker für Systemintegration sind abhängig vom Arbeitsplatz besonders häufig folgende Practices relevant:

Practice	Typischer Bezug zum Arbeitsalltag
Service Desk	Benutzerkontakt, Erfassung, Kommunikation und Weiterleitung
Incident Management	Störungen analysieren und Servicebetrieb wiederherstellen
Service Request Management	Benutzerkonten, Zugriffe, Software und Standardleistungen bereitstellen
Problem Management	wiederkehrende Fehler und zugrunde liegende Ursachen untersuchen
Change Enablement	technische Änderungen bewerten und kontrolliert durchführen
Deployment Management	Software, Konfigurationen oder Infrastrukturkomponenten bereitstellen
Release Management	neue oder geänderte Funktionen für die Nutzung verfügbar machen
Monitoring and Event Management	technische Zustände und relevante Abweichungen erkennen
Service Configuration Management	Abhängigkeiten und Configuration Items nachvollziehen
IT Asset Management	Hardware, Software, Lizenzen und Cloud-Ressourcen verwalten
Knowledge Management	Lösungen, Arbeitsanweisungen und Erkenntnisse verfügbar machen
Information Security Management	Schutzanforderungen bei Betrieb und Änderungen berücksichtigen
Supplier Management	Hersteller, Provider und Supportpartner einbinden
Service Continuity Management	Wiederherstellung und Fortführung kritischer Services unterstützen
Capacity and Performance Management	Leistung, Kapazität und zukünftigen Bedarf bewerten
Availability Management	benötigte Verfügbarkeit technischer und servicebezogener Fähigkeiten unterstützen
Continual Improvement	wiederkehrende Probleme und Arbeitsweisen nachhaltig verbessern

Nicht jeder Fachinformatiker ist für die vollständige Steuerung dieser Practices verantwortlich.

Er kann jedoch durch technische Arbeit, Dokumentation, Eskalation und Rückmeldungen zu ihrer Wirksamkeit beitragen.

Service Desk und Incident Management unterscheiden

Diese beiden Practices werden häufig gleichgesetzt.

Service Desk	Incident Management
stellt einen zentralen Kontakt- und Kommunikationspunkt bereit	koordiniert die Behandlung von Incidents
bearbeitet Kontakte, Fragen, Anfragen und Meldungen	konzentriert sich auf negative Serviceauswirkungen und Wiederherstellung
unterstützt Benutzerkommunikation	organisiert Priorisierung, Diagnose, Eskalation und Wiederherstellung
kann Incidents und Service Requests erfassen	kann mehrere Teams und Lieferanten einbeziehen
ist eine Practice und kann organisatorisch als Team umgesetzt sein	ist eine Practice, die nicht auf ein einzelnes Team begrenzt ist

Ein Service Desk kann Incident Management wesentlich unterstützen.

Er ist jedoch nicht mit der gesamten Incident-Management-Practice identisch.

Incident Management und Problem Management unterscheiden

Incident Management	Problem Management
konzentriert sich auf die aktuelle negative Auswirkung	konzentriert sich auf Ursachen und zukünftige Auswirkungen
priorisiert Wiederherstellung	priorisiert Untersuchung und nachhaltige Risikoreduzierung
kann eine Zwischenlösung verwenden	verwaltet Ursachen, bekannte Fehler und Workarounds
arbeitet häufig unter höherem Zeitdruck	kann nach der Wiederherstellung vertieft arbeiten
Erfolg: Service ist wieder nutzbar	Erfolg: Wahrscheinlichkeit oder Auswirkung weiterer Incidents wird reduziert

Beispiel:

Ein Dienst wird nach einem Speicherfehler neu gestartet.

Der Neustart kann den Incident lösen.
Die Ursache des steigenden Speicherverbrauchs bleibt ein mögliches Problem.
Eine dauerhafte Korrektur kann anschließend einen Change, Release und Deployment benötigen.

Merke

Ein Incident muss nicht vollständig ursächlich verstanden sein, bevor der Service wiederhergestellt wird.

Eine Wiederherstellung beseitigt jedoch nicht automatisch die zugrunde liegende Ursache.

Event, Incident und Problem unterscheiden

Begriff	Bedeutung
Event	erkannte Zustandsänderung, die für das Management eines Produkts oder Service relevant sein kann
Incident	ungeplante Unterbrechung, Qualitätsminderung oder andere negative Serviceauswirkung
Problem	Ursache oder mögliche Ursache eines oder mehrerer Incidents

Beispiel:

Monitoring meldet eine hohe Speicherauslastung: Event
Anwendung reagiert nicht mehr: Incident
fehlerhafte Speicherverwaltung der Anwendung: Problem

Nicht jedes Event wird zu einem Incident.

Nicht jeder Incident benötigt einen eigenen Problem Record.

Die konkrete Einordnung hängt von Auswirkungen, Wiederholung, Risiko und betrieblicher Arbeitsweise ab.

Service Request und Incident unterscheiden

Service Request	Incident
vorgesehene Benutzeranfrage	ungeplante negative Serviceauswirkung
häufig standardisierbar	benötigt Untersuchung oder Wiederherstellung
Beispiel: neue Software anfordern	Beispiel: vorhandene Software startet nicht
Beispiel: Zugriff beantragen	Beispiel: genehmigter Zugriff funktioniert nicht
Beispiel: Auskunft anfordern	Beispiel: Service ist nicht erreichbar

Die Formulierung eines Benutzers entscheidet nicht automatisch über die Einordnung.

Ein Benutzer kann beispielsweise sagen:

Ich brauche ein neues Kennwort.

Dahinter können unterschiedliche Situationen stehen:

planmäßige Kennwortänderung,
vergessenes Kennwort,
gesperrtes Konto,
möglicher Sicherheitsvorfall,
oder fehlerhafter Identitätsdienst.

Change Enablement, Release und Deployment unterscheiden

Practice	Zentrale Betrachtung
Change Enablement	Nutzen, Risiko, Bewertung, Autorisierung und Steuerung einer Änderung
Release Management	neue oder geänderte Funktionen und Servicebestandteile für die Nutzung verfügbar machen
Deployment Management	Komponenten in eine Zielumgebung übertragen

Beispiel: neue Anwendungsversion

Change Enablement

Auswirkungen und Risiken bewerten
notwendige Autorisierung sicherstellen
Zeitpunkt und Abhängigkeiten koordinieren
Rückfall- oder Wiederherstellungsplanung berücksichtigen

Release Management

festlegen, welche Funktionen und Änderungen gemeinsam verfügbar gemacht werden
Releaseinformationen bereitstellen
Erwartungen und Zeitplanung abstimmen

Deployment Management

Softwarepaket technisch übertragen
Konfiguration anwenden
Installation oder Aktivierung durchführen
technisches Ergebnis prüfen

Diese Tätigkeiten können miteinander verbunden sein, besitzen aber unterschiedliche Zwecke.

IT Asset und Configuration Item unterscheiden

Ein IT Asset wird hinsichtlich seines finanziellen, vertraglichen, risikobezogenen und lebenszyklusbezogenen Werts verwaltet.

Ein Configuration Item wird verwaltet, weil Informationen über seinen Zustand und seine Beziehungen für das Management eines Produktes oder Service benötigt werden.

Ein Gegenstand kann:

nur IT Asset,
nur Configuration Item,
beides,
oder keines von beidem

sein.

Beispiele:

Gegenstand	Mögliche Einordnung
physischer Server	IT Asset und Configuration Item
Softwarelizenz	IT Asset, möglicherweise auch Configuration Item
virtueller Cluster	Configuration Item, abhängig vom Modell möglicherweise Asset-Bezug
Netzwerkkabel	je nach Bedeutung weder einzeln verwaltetes Asset noch CI
Cloud-Abonnement	IT Asset und möglicherweise Configuration Item
Service-Dokumentation	möglicherweise Configuration Item, aber normalerweise kein IT Asset

Wichtig

Nicht jede technische Komponente muss automatisch als einzelnes Configuration Item erfasst werden.

Der benötigte Detaillierungsgrad muss einen erkennbaren Nutzen besitzen.

Practice Owner, Process Owner und ausführende Rolle

Organisationen können unterschiedliche Verantwortlichkeiten verwenden.

Rolle	Möglicher Schwerpunkt
Practice Owner	Wirksamkeit und Weiterentwicklung der gesamten Practice
Process Owner	Gestaltung und Pflege eines konkreten Prozesses
Process Manager	laufende Steuerung eines Prozesses
Service Owner	Ende-zu-Ende-Verantwortung für einen Service
Product Owner oder Product Manager	Prioritäten und Entwicklung eines Produkts
ausführende Rolle	konkrete Bearbeitung einer Aufgabe
Tool Owner	Betrieb und Weiterentwicklung des unterstützenden Werkzeugs

ITIL schreibt nicht vor, dass jede Organisation genau diese Rollen einsetzen muss.

Entscheidend ist, dass geklärt ist:

wer entscheidet,
wer ausführt,
wer für Ergebnisse einsteht,
wer Verbesserungen steuert,
und wer die benötigten Informationen und Ressourcen bereitstellt.

Eine Practice einführen oder verbessern

Eine Practice sollte nicht mit der Auswahl eines Werkzeugs beginnen.

Eine sinnvolle Vorgehensweise ist:

Problem oder Bedarf verstehen
gewünschte Outcomes bestimmen
aktuellen Zustand untersuchen
relevante Stakeholder einbeziehen
betroffene Wertströme bestimmen
vorhandene Fähigkeiten und Daten bewerten
Rollen und Verantwortung klären
angemessene Prozesse und Kontrollen gestalten
benötigte Informationen und Werkzeuge festlegen
Lieferanten und Abhängigkeiten berücksichtigen
Messgrößen und Erfolgskriterien definieren
schrittweise einführen
Feedback auswerten
fortlaufend verbessern

Typischer Fehler

Eine vollständige theoretische Practice wird auf einmal entworfen und anschließend der Organisation aufgezwungen.

Dadurch entstehen umfangreiche Dokumentationen, die nicht zur tatsächlichen Arbeitsweise passen.

Eine Practice an Wertströmen ausrichten

Practices sollten nicht ausschließlich intern optimiert werden.

Beispiel:

Incident Management erreicht eine kurze interne Bearbeitungszeit, indem Tickets schnell an andere Teams weitergegeben werden.

Dadurch können jedoch entstehen:

mehr Übergaben,
Informationsverluste,
längere Gesamtdauer,
wiederholte Rückfragen,
und schlechte Benutzererfahrung.

Deshalb sollte geprüft werden:

Welchen Value Stream unterstützt die Practice?
Welches Outcome soll erreicht werden?
Welche anderen Practices sind beteiligt?
Wo entstehen Übergaben?
Welche Informationen müssen fließen?
Welche lokalen Kennzahlen schaden möglicherweise dem Gesamtergebnis?

Merke

Eine leistungsfähige Practice unterstützt den gesamten Wertstrom und nicht nur ihre eigene interne Kennzahl.

Messung einer Practice

Messgrößen sollten den Zweck und die Outcomes einer Practice unterstützen.

Nicht ausreichend ist es, nur leicht verfügbare Aktivitäten zu zählen.

Beispiel: Incident Management

Mögliche Aktivitätszahlen:

Anzahl geöffneter Tickets
Anzahl geschlossener Tickets
durchschnittliche Bearbeitungszeit

Zusätzliche Ergebnisinformationen:

tatsächliche Wiederherstellungszeit
Auswirkung auf Benutzer
wiederholte Incidents
Erfolgsquote von Wiederherstellungen
Qualität der Kommunikation
erneute Kontaktaufnahme
Anzahl falsch geschlossener Vorgänge
Serviceerfahrung
nachhaltige Verbesserungen

Beispiel: Knowledge Management

Unzureichende Einzelkennzahl:

Anzahl veröffentlichter Wissensartikel

Ergänzende Fragen:

Werden die Artikel gefunden?
Sind sie aktuell?
Helfen sie bei der Lösung?
Werden sie von Benutzern und Mitarbeitern verstanden?
Reduzieren sie wiederholte Analyse?
Werden falsche oder veraltete Inhalte entfernt?

Kennzahlen dürfen nicht das Verhalten verschlechtern

Eine ungeeignete Kennzahl kann unerwünschtes Verhalten fördern.

Kennzahl	Mögliche Fehlwirkung
möglichst viele geschlossene Tickets	Vorgänge werden voreilig abgeschlossen
möglichst kurze Gesprächsdauer	Benutzerproblem wird nicht vollständig verstanden
möglichst wenige Changes	notwendige Verbesserungen und Sicherheitsupdates werden vermieden
möglichst wenige Incidents	Incidents werden nicht erfasst oder falsch eingeordnet
möglichst viele Wissensartikel	Qualität und Aktualität sinken
möglichst hohe technische Verfügbarkeit	tatsächliche Nutzbarkeit und Erfahrung werden übersehen

Messgrößen sollten deshalb gemeinsam betrachtet und regelmäßig überprüft werden.

Practice Capability und Maturity

Eine Practice kann unterschiedlich stark entwickelt sein.

Zu bewerten sind beispielsweise:

Klarheit von Zweck und Outcomes,
Rollen und Verantwortlichkeiten,
Fähigkeiten,
Informationen,
Prozesse,
Werkzeuge,
Lieferanten,
Messung,
Integration in Wertströme,
und Continual Improvement.

Eine umfangreiche Dokumentation bedeutet nicht automatisch hohe Fähigkeit oder Reife.

Eine Practice kann formal beschrieben sein und trotzdem unwirksam bleiben, wenn:

Mitarbeiter den Ablauf umgehen,
Informationen unzuverlässig sind,
Befugnisse fehlen,
Werkzeuge nicht passen,
Schnittstellen nicht funktionieren,
oder Ergebnisse nicht verbessert werden.

Merke

Practice Capability zeigt sich in der wirksamen Erreichung des Zwecks und nicht in der Menge der Dokumente.

Automatisierung innerhalb von Practices

Automatisierung kann Practices unterstützen.

Beispiele:

Practice	Mögliche Automatisierung
Incident Management	automatische Erfassung aus relevantem Monitoring-Event
Service Request Management	standardisierte Bereitstellung genehmigter Software
Change Enablement	risikobasierte Weiterleitung und Terminprüfung
IT Asset Management	automatische Inventarisierung
Service Configuration Management	technische Discovery und Beziehungsaktualisierung
Knowledge Management	Vorschläge passender Wissensartikel
Monitoring and Event Management	Korrelation und Unterdrückung redundanter Events
Measurement and Reporting	automatische Datensammlung und Berichtserstellung
Deployment Management	automatisierte Bereitstellung und technische Prüfung
Information Security Management	automatische Richtlinien- und Konfigurationskontrolle

Vor der Automatisierung muss geprüft werden:

Ist der Zweck verstanden?
Ist die Arbeitsweise geeignet?
Sind Eingabedaten zuverlässig?
Sind Ausnahmen bekannt?
Wie werden Fehler erkannt?
Wer trägt Verantwortung?
Wie wird die Automatisierung überwacht?
Gibt es eine Rückfallmöglichkeit?
Entsteht ein tatsächlicher Nutzen?

Grundsatz

Erst verstehen und optimieren, dann automatisieren.

Künstliche Intelligenz innerhalb von Practices

KI kann unter anderem unterstützen bei:

Klassifizierung von Tickets,
Zusammenfassung von Vorgängen,
Suche nach Wissensartikeln,
Erkennung von Mustern,
Priorisierungsvorschlägen,
Analyse von Monitoring-Daten,
Berichtserstellung,
Übersetzung,
und Formulierung von Benutzerkommunikation.

Dabei müssen berücksichtigt werden:

Datenqualität,
Datenschutz,
Informationssicherheit,
Nachvollziehbarkeit,
mögliche Verzerrungen,
Fehlerwahrscheinlichkeit,
menschliche Kontrolle,
und Verantwortung.

Beispiel:

Eine KI schlägt eine hohe Incident-Priorität vor.

Die zuständige Arbeitsweise muss weiterhin klären:

Welche Auswirkungen bestehen tatsächlich?
Wie dringend ist die Situation?
Welche Kriterien verwendet die Organisation?
Sind die Eingangsdaten vollständig?
Wer bestätigt oder ändert die Priorität?
Wie wird die Entscheidung dokumentiert?

Sicherheitsrelevant

Eine KI-Empfehlung überträgt die Entscheidungs- und Ergebnisverantwortung nicht auf das technische System.

Practice und betriebliche Organisation

Organisationen können Practices unterschiedlich benennen oder zusammenfassen.

Beispiele:

Incident Management kann intern als Störungsmanagement bezeichnet werden.
Service Request Management kann im Bestell- oder Benutzerportal integriert sein.
Change Enablement kann als Change Management bezeichnet werden.
Monitoring and Event Management kann organisatorisch im Network Operations Center liegen.
IT Asset Management kann teilweise durch Einkauf oder Finanzabteilung unterstützt werden.
Information Security Management kann eng mit einem Informationssicherheitsmanagementsystem verbunden sein.

Die interne Bezeichnung ist weniger wichtig als eine eindeutige Arbeitsweise.

Zu klären ist:

Welcher Zweck wird verfolgt?
Welche Outcomes werden erwartet?
Wer trägt Verantwortung?
Welche Informationen werden benötigt?
Welche Schnittstellen bestehen?
Wie wird die Wirksamkeit geprüft?
Wie werden Verbesserungen umgesetzt?

Praxisbeispiel: wiederkehrender VPN-Ausfall

Mehrere Benutzer verlieren regelmäßig die VPN-Verbindung.

Monitoring and Event Management

Verbindungsabbrüche und technische Zustände erkennen
relevante Messwerte und Ereignisse bereitstellen

Service Desk

Benutzerkontakte und Rückmeldungen erfassen
verständliche Statusinformationen bereitstellen

Incident Management

Auswirkungen und Dringlichkeit bewerten
Wiederherstellung koordinieren
zuständige Teams und Provider einbinden

Service Configuration Management

Abhängigkeiten zwischen VPN-Gateway, Identitätsdienst, Zertifikaten, Netzwerk und Provider darstellen

Supplier Management

externe Anbieter anhand geeigneter Informationen einbinden und eskalieren

Knowledge Management

Diagnose- und Zwischenlösungen verfügbar machen

Problem Management

wiederkehrende Muster und zugrunde liegende Ursache untersuchen

Change Enablement

dauerhafte Korrektur hinsichtlich Risiko, Autorisierung und Zeitpunkt steuern

Deployment Management

geänderte Konfiguration oder Software kontrolliert bereitstellen

Service Validation and Testing

Stabilität, Kompatibilität und erwartete Nutzung prüfen

Continual Improvement

Monitoring, Dokumentation, Eskalation und technische Lösung verbessern

Praxisbeispiel: neuer Mitarbeiter

Das gewünschte Outcome lautet:

Der neue Mitarbeiter kann am ersten Arbeitstag sicher und vollständig arbeiten.

Mögliche beteiligte Practices:

Practice	Beitrag
Service Request Management	Onboarding-Anfrage erfassen und koordinieren
Service Catalogue Management	verfügbare Arbeitsplatz- und Zugangsangebote beschreiben
IT Asset Management	Endgerät und Lizenzen bereitstellen und verwalten
Service Configuration Management	relevante Beziehungen und Konfigurationen dokumentieren
Information Security Management	Zugriff und Sicherheitsanforderungen berücksichtigen
Supplier Management	externe Lieferung oder Lizenzbereitstellung steuern
Knowledge Management	Anleitungen und Übergabeinformationen bereitstellen
Service Desk	Fragen und Probleme beim Einstieg unterstützen
Continual Improvement	Verzögerungen und wiederkehrende Fehler im Onboarding reduzieren

Der Value Stream endet nicht bereits mit der Erstellung des Benutzerkontos.

Er endet mit dem überprüften Outcome der Arbeitsfähigkeit.

Praxisbeispiel: abgelaufenes Zertifikat

Ein Zertifikat läuft ab und verursacht einen Serviceausfall.

Incident Management

Service wiederherstellen

Monitoring and Event Management

prüfen, warum keine ausreichende Warnung erfolgte

Service Configuration Management

betroffene Zertifikate, Systeme und Services nachvollziehen

Problem Management

systemische Ursache untersuchen

Knowledge Management

Erneuerungs- und Wiederherstellungsverfahren dokumentieren

Change Enablement

dauerhafte technische oder organisatorische Korrektur steuern

Information Security Management

sichere Zertifikatsverwaltung berücksichtigen

Continual Improvement

zentrale Erfassung, Verantwortlichkeit und Alarmierung verbessern

Merke

Die unmittelbare technische Reparatur kann einen Incident lösen.

Mehrere weitere Practices können notwendig sein, um eine Wiederholung zu verhindern.

Typische Fehler bei der Anwendung von Practices

Fehler 1: Practice mit Prozess gleichsetzen

Die Organisation dokumentiert einen Ablauf, berücksichtigt aber Rollen, Wissen, Werkzeuge und Partner nicht ausreichend.

Fehler 2: Practice mit Team gleichsetzen

Incident Management wird ausschließlich als Aufgabe des Service Desk betrachtet, obwohl technische Teams, Service Owner und Lieferanten beteiligt sein können.

Fehler 3: Tool als Ausgangspunkt verwenden

Das Ticketsystem bestimmt Kategorien und Arbeitsweisen, obwohl der tatsächliche Bedarf nicht untersucht wurde.

Fehler 4: Practices isoliert optimieren

Jede Practice verbessert ihre eigenen Kennzahlen, während Übergaben und Gesamtdauer schlechter werden.

Fehler 5: jede Practice maximal formalisieren

Auch einfache und risikoarme Tätigkeiten erhalten unnötig umfangreiche Prozesse und Freigaben.

Fehler 6: nur den Normalfall gestalten

Ausnahmen, Eskalationen, Sicherheitsvorfälle und Lieferantenausfälle werden nicht berücksichtigt.

Fehler 7: Verantwortung nicht eindeutig festlegen

Viele Teams sind beteiligt, aber niemand koordiniert das Ende-zu-Ende-Ergebnis.

Fehler 8: Messung nur auf Aktivität ausrichten

Gezählt werden Tickets, Changes oder Wissensartikel, aber nicht deren Nutzen und Qualität.

Fehler 9: Practice nach Einführung nicht weiterentwickeln

Arbeitsweisen, Werkzeuge und Anforderungen verändern sich, während die Practice unverändert bleibt.

Fehler 10: ältere Begriffe ungeprüft übernehmen

ITIL-4-Kategorien oder betriebliche Begriffe werden ohne Versionshinweis als aktuelle ITIL-Version-5-Struktur dargestellt.

30-Sekunden-Prüfung einer Practice

Bei der Bewertung einer Practice kannst du folgende Fragen stellen:

Welchen Zweck erfüllt die Practice?
Welches Outcome soll sie unterstützen?
In welchen Wertströmen wird sie verwendet?
Wer trägt Verantwortung?
Welche Fähigkeiten werden benötigt?
Welche Informationen und Werkzeuge sind notwendig?
Welche anderen Practices sind beteiligt?
Welche Partner oder Lieferanten werden benötigt?
Wie wird die Wirksamkeit gemessen?
Wie wird die Practice verbessert?

Checkliste für den Aufbau einer Practice

Checkliste für die Bewertung einer bestehenden Practice

Schnellreferenz für häufige Arbeitssituationen

Situation	Häufig beteiligte Practices
Service ist ausgefallen	Incident Management, Service Desk, Monitoring and Event Management
Fehler tritt wiederholt auf	Problem Management, Knowledge Management, Continual Improvement
Benutzer benötigt Standardsoftware	Service Request Management, IT Asset Management, Service Desk
System soll aktualisiert werden	Change Enablement, Release Management, Deployment Management
Abhängigkeiten sind unklar	Service Configuration Management, Architecture Management
Hardware oder Lizenz muss verwaltet werden	IT Asset Management, Supplier Management, Service Financial Management
Sicherheitsrisiko wurde erkannt	Information Security Management, Risk Management, Change Enablement
Anbieterleistung ist unzureichend	Supplier Management, Service Level Management, Relationship Management
neue Anwendung wird eingeführt	Service Design, Business Analysis, Architecture Management, Project Management
Service muss nach Katastrophe wiederhergestellt werden	Service Continuity Management, Incident Management, Availability Management
Leistung reicht nicht aus	Capacity and Performance Management, Availability Management
Benutzer verstehen den Service nicht	Service Catalogue Management, Knowledge Management, Relationship Management
Arbeitsweise soll verbessert werden	Continual Improvement, Measurement and Reporting
neues Team oder neue Arbeitsweise wird eingeführt	Organizational Change Management, Workforce and Talent Management

Zusammenfassende Darstellung

Bedarf oder Chance
↓
gewünschtes Outcome und Value Stream bestimmen
↓
benötigte Management Practices auswählen
↓
Menschen · Informationen · Prozesse · Technologie · Partner verbinden
↓
Arbeit durchführen und Ergebnisse messen
↓
Feedback und Erkenntnisse auswerten
↓
Practices und Wertströme kontinuierlich verbessern

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen
Service Desk
Incident Management
Service Request Management
Problem Management
Change Enablement
Monitoring and Event Management
Knowledge Management
Service Configuration Management
IT Asset Management

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen aktuellen ITIL-Version-5-Informationen bestätigen:

ITIL Version 5 führt weiterhin 34 Management Practices.
Die Practices bleiben gegenüber ITIL 4 weitgehend erhalten.
Anpassungen erfolgen zur Ausrichtung auf die neuen ITIL-Version-5-Inhalte.
Die 34 Practices werden in zwei Gruppen organisiert:
- Product and Service Management Practices
- General Management Practices
Die vollständigen Practice Guides werden über PeopleCert Plus bereitgestellt.
Die Practice-Manager-Bündel enthalten jeweils fünf ausgewählte Practices.

Hinweis zur Practice-Bezeichnung

Die aktuelle offizielle Beschreibung des Practice-Manager-Moduls Plan, Implement and Control verwendet weiterhin die Bezeichnung Change Enablement.

Deshalb wird diese Practice auf dieser Seite nicht ohne eindeutigen offiziellen Nachweis in Change Management umbenannt.

Einordnung

Die alphabetische Übersicht, deutschen Kurzbeschreibungen, Vergleiche, Praxisbeispiele, Checklisten und Arbeitssituationen sind eigene herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebenen Prozesse dar.

Die konkrete Gestaltung, Priorisierung und Ausprägung einer Practice muss an Ziele, Risiken, Fähigkeiten und Wertströme der jeweiligen Organisation angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.8 Value Streams und Value Stream Mapping

Kurz erklärt

Ein Value Stream beschreibt den Ende-zu-Ende-Weg, durch den aus einem Bedarf, einer Nachfrage oder einer Chance ein nutzbares Ergebnis und Wert für Stakeholder entstehen.

Value Stream Mapping macht diesen Weg sichtbar.

Dabei werden nicht nur einzelne Prozessschritte betrachtet, sondern auch:

beteiligte Personen und Teams,

Management Practices,

Informationen,

Technologien,

Partner und Lieferanten,

Entscheidungen,

Kontrollen,

Übergaben,

Wartezeiten,

Nacharbeit,

Risiken,

und Rückmeldungen.

Ziel ist nicht, ein besonders umfangreiches Ablaufdiagramm zu erstellen.

Ziel ist, den tatsächlichen Arbeitsfluss zu verstehen und gezielt zu verbessern.

Warum Value Streams wichtig sind

Digitale Produkte und Services entstehen normalerweise nicht innerhalb eines einzigen Teams.

Ein benötigtes Outcome kann Beiträge erfordern von:

Benutzern,
Fachabteilungen,
Service Desk,
Systemadministration,
Netzwerkbetrieb,
Entwicklung,
Informationssicherheit,
Einkauf,
Personalabteilung,
Lieferanten,
Cloud-Providern,
und Führungskräften.

Jeder Beteiligte kann seinen eigenen Arbeitsschritt korrekt ausführen.

Der gesamte Ablauf kann trotzdem:

langsam,
unübersichtlich,
fehleranfällig,
unnötig kompliziert,
oder für den Benutzer unbefriedigend

sein.

Beispiel:

Ein neuer Mitarbeiter benötigt einen arbeitsfähigen IT-Arbeitsplatz.

Alle beteiligten Teams können ihre jeweilige Aufgabe korrekt ausführen:

Personalabteilung meldet den Eintritt.
Führungskraft nennt benötigte Zugriffe.
Einkauf bestellt das Endgerät.
IT erstellt das Benutzerkonto.
Informationssicherheit prüft Berechtigungen.
Service Desk übergibt das Gerät.

Der Mitarbeiter kann am ersten Arbeitstag trotzdem nicht arbeiten, wenn:

die Meldung zu spät erfolgte,
notwendige Informationen fehlten,
eine Freigabe liegen blieb,
die Lizenz nicht verfügbar war,
das Endgerät nicht rechtzeitig geliefert wurde,
oder niemand das Ende-zu-Ende-Ergebnis kontrollierte.

Merke

Die Qualität einzelner Arbeitsschritte garantiert noch kein gutes Ende-zu-Ende-Ergebnis.

Was ist ein Value Stream?

Ein Value Stream ist eine zusammenhängende Abfolge von Schritten, durch die ein bestimmtes Outcome und Wert für einen Stakeholder ermöglicht werden.

Ein Value Stream besitzt normalerweise:

einen erkennbaren Auslöser,
einen bestimmten Bedarf oder eine Chance,
einen oder mehrere Stakeholder,
ein gewünschtes Outcome,
mehrere miteinander verbundene Schritte,
beteiligte Rollen und Fähigkeiten,
benötigte Informationen und Technologien,
sowie ein überprüfbares Ergebnis.

Beispiele für Value Streams:

neuen Mitarbeiter arbeitsfähig machen
einen Incident bearbeiten und den Service wiederherstellen
einen genehmigten Zugriff bereitstellen
eine neue Anwendung einführen
eine Schwachstelle dauerhaft beheben
einen Arbeitsplatz austauschen
einen Service verbessern
eine neue Produktfunktion bereitstellen
einen Lieferanten ablösen
einen nicht mehr benötigten Service außer Betrieb nehmen

Wichtig

Ein Value Stream sollte anhand des benötigten Outcomes benannt werden.

Ein Name wie „Ticket bearbeiten“ ist häufig zu eng.

Ein geeigneterer Name kann beispielsweise lauten:

„Benutzer nach einer Störung wieder arbeitsfähig machen.“

Auslöser, Output, Outcome und Wert

Diese Begriffe müssen unterschieden werden.

Begriff	Bedeutung	Beispiel
Auslöser	Ereignis, Nachfrage oder Chance, die den Wertstrom startet	neuer Mitarbeiter tritt ein
Input	benötigte Informationen oder Ressourcen	Eintrittsdatum, Rolle und genehmigte Zugriffe
Aktivität	durchgeführter Arbeitsschritt	Benutzerkonto erstellen
Output	direkt erzeugtes Ergebnis einer Aktivität	Benutzerkonto wurde angelegt
Outcome	durch Stakeholder ermöglichtes Ergebnis	Mitarbeiter kann seine Aufgaben ausführen
Wert	wahrgenommener Nutzen unter Berücksichtigung von Outcomes, Kosten und Risiken	produktiver und sicherer Arbeitsbeginn

Ein Output ist nicht automatisch das gewünschte Outcome.

Beispiel:

Output: Das VPN wurde installiert.

Outcome: Der Benutzer kann sicher auf die benötigten Anwendungen zugreifen.

Merke

Value Streams werden vom benötigten Outcome aus betrachtet und nicht nur anhand erledigter technischer Tätigkeiten.

Value Stream und Value Stream Mapping

Begriff	Bedeutung
Value Stream	tatsächlicher oder geplanter Ende-zu-Ende-Weg zum Outcome
Value Stream Mapping	strukturierte Darstellung und Untersuchung dieses Weges
Value Stream Management	fortlaufende Steuerung, Messung und Verbesserung des Wertstroms

Value Stream Mapping ist damit keine einmalige Zeichenübung.

Die Abbildung soll dabei helfen:

tatsächliche Arbeit sichtbar zu machen,
Probleme und Engpässe zu erkennen,
Verbesserungen zu priorisieren,
Verantwortlichkeiten zu klären,
und die Wirkung von Änderungen später zu überprüfen.

Value Stream, Value Chain und Lifecycle unterscheiden

Begriff	Bedeutung
ITIL Value System	übergeordneter Rahmen für Wertschöpfung innerhalb der Organisation
Value Chain	flexibles operatives Modell innerhalb des ITIL Value Systems
Product and Service Lifecycle	acht allgemeine Aktivitäten über den Lebenszyklus digitaler Produkte und Services
Value Stream	konkrete Ende-zu-Ende-Abfolge für ein bestimmtes Outcome
Prozess	strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen
Management Practice	organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Customer oder User Journey	Erfahrung eines Kunden oder Benutzers über mehrere Interaktionen hinweg

Beispiel: neue Anwendung für eine Fachabteilung

Lifecycle

Discover
Design
Acquire
Build
Transition
Operate
Deliver
Support

Value Stream

Bedarf der Fachabteilung erfassen
→ Lösung auswählen und bereitstellen
→ Benutzer befähigen
→ produktive Nutzung bestätigen

Beteiligte Practices

Business Analysis
Service Design
Architecture Management
Supplier Management
Change Enablement
Deployment Management
Information Security Management
Service Desk
Continual Improvement

Prozesse

Beschaffung
Change-Bewertung
Benutzeranlage
Softwareverteilung
Support

User Journey

Bedarf melden
Informationen erhalten
Anwendung testen
Schulung nutzen
Support anfordern
Erfahrung bewerten

Merke

Der Lifecycle stellt allgemeine Aktivitäten bereit.

Der Value Stream zeigt den konkreten Weg zum Outcome.

Practices liefern die dafür benötigten Fähigkeiten.

Value Streams überschreiten Organisationsgrenzen

Ein Value Stream endet nicht automatisch an einer Team-, Abteilungs- oder Unternehmensgrenze.

Beispiel: Internetzugang eines Standorts wiederherstellen

Mögliche Beteiligte:

Benutzer am Standort
Service Desk
Netzwerkteam
lokaler Techniker
Internetprovider
Hardwarehersteller
Incident-Koordination
Service Owner

Der Wertstrom endet nicht bereits dann, wenn das interne Netzwerkteam ein Ticket an den Provider übermittelt hat.

Er endet erst, wenn das gewünschte Outcome erreicht oder eine andere vereinbarte Entscheidung getroffen wurde.

Mögliches Outcome:

Der Standort besitzt wieder einen stabilen und ausreichend leistungsfähigen Internetzugang.

Typischer Fehler

Ein Team betrachtet seinen eigenen Arbeitsschritt als abgeschlossen, obwohl das Ende-zu-Ende-Outcome noch nicht erreicht wurde.

Die Grenzen eines Value Streams festlegen

Vor der Abbildung muss geklärt werden:

Welches konkrete Outcome wird betrachtet?
Welches Ereignis startet den Wertstrom?
Wann gilt der Wertstrom als abgeschlossen?
Für welche Benutzer- oder Kundengruppe gilt er?
Welche Produkt- oder Servicevariante wird untersucht?
Welche Ausnahmen gehören noch zum Umfang?
Welche angrenzenden Wertströme werden nicht betrachtet?

Unklare Abgrenzung:

Wir bilden den gesamten IT-Support ab.

Bessere Abgrenzung:

Wir bilden den Wertstrom ab, durch den ein Benutzer nach einer gemeldeten Arbeitsplatzstörung wieder arbeitsfähig wird.

Eine klare Grenze verhindert, dass die Darstellung:

zu groß,
unübersichtlich,
nicht messbar,
oder praktisch nicht verbesserbar

wird.

Aktueller und zukünftiger Zustand

Beim Value Stream Mapping werden häufig zwei Zustände unterschieden.

Zustand	Zweck
Ist-Zustand	zeigt, wie die Arbeit tatsächlich heute erfolgt
Zielzustand	zeigt, wie der verbesserte Wertstrom künftig funktionieren soll

Der Ist-Zustand darf nicht ausschließlich aus vorhandenen Prozessdokumentationen übernommen werden.

Er sollte anhand tatsächlicher Informationen untersucht werden.

Geeignete Quellen können sein:

Beobachtung realer Vorgänge,
Tickets,
Systemprotokolle,
Monitoring-Daten,
Zeitmessungen,
Gespräche mit Beteiligten,
Benutzerfeedback,
bestehende Dokumentationen,
Lieferanteninformationen,
und Stichproben.

Wichtig

Dokumentierter Prozess und tatsächlich gelebter Ablauf können deutlich voneinander abweichen.

Was in einer Value-Stream-Darstellung enthalten sein kann

Eine praktische Darstellung kann folgende Elemente enthalten:

Element	Beispiel
Auslöser	Benutzer meldet einen Incident
Stakeholder	Benutzer, Service Desk und technisches Team
gewünschtes Outcome	Benutzer kann wieder arbeiten
Schritt	Incident erfassen
verantwortliche Rolle	Service-Desk-Mitarbeiter
benötigte Information	Symptome und betroffener Service
verwendetes Werkzeug	Ticketsystem
beteiligte Practice	Incident Management
Bearbeitungszeit	10 Minuten
Wartezeit	45 Minuten
Übergabe	Service Desk an Netzwerkteam
Entscheidung	Eskalation erforderlich?
Kontrolle	Benutzer bestätigt Wiederherstellung
Nacharbeit	Ticket wegen fehlender Informationen zurückgegeben
Lieferant	Internetprovider
Risiko	falsche Priorisierung
Messgröße	gesamte Wiederherstellungszeit
Verbesserungsmöglichkeit	Pflichtinformationen bei Erfassung verbessern

Nicht jede Darstellung muss alle Elemente enthalten.

Der Detaillierungsgrad richtet sich nach:

Ziel der Untersuchung,
Risiko,
Komplexität,
verfügbarer Zeit,
und benötigter Entscheidung.

Eine einfache Darstellungsform

Für kleinere Wertströme kann eine Tabelle ausreichen.

Nr.	Schritt	Verantwortlich	Ergebnis	Bearbeitungszeit	Wartezeit	Problem
1	Anfrage erfassen	Service Desk	vollständiges Ticket	10 Min.	0 Min.	Pflichtangaben fehlen häufig
2	Zugriff prüfen	Fachverantwortlicher	fachliche Freigabe	5 Min.	2 Tage	keine Vertretung
3	Zugriff einrichten	Administration	technische Berechtigung	15 Min.	4 Std.	manuelle Gruppensuche
4	Funktion testen	Administration	technischer Test	10 Min.	0 Min.	Benutzer nicht beteiligt
5	Nutzung bestätigen	Benutzer	bestätigtes Outcome	5 Min.	1 Tag	Rückmeldung wird nicht nachverfolgt

Gesamte Bearbeitungszeit:

45 Minuten

Gesamte Wartezeit:

mehr als 3 Tage

Das Beispiel zeigt:

Die lange Durchlaufzeit entsteht nicht hauptsächlich durch langsame technische Ausführung.

Sie entsteht überwiegend durch:

Warteschlangen,
fehlende Vertretung,
manuelle Übergaben,
und verzögerte Rückmeldungen.

Bearbeitungszeit und Durchlaufzeit unterscheiden

Begriff	Bedeutung
Bearbeitungszeit	Zeit, in der aktiv an einem Vorgang gearbeitet wird
Wartezeit	Zeit, in der keine wertstromrelevante Bearbeitung erfolgt
Durchlaufzeit	gesamte Zeit vom Auslöser bis zum abgeschlossenen Outcome
Übergabezeit	Zeit und Aufwand beim Wechsel zwischen Rollen, Teams oder Systemen
Nacharbeitszeit	zusätzlicher Aufwand aufgrund unvollständiger oder fehlerhafter Arbeit

Beispiel:

aktive Bearbeitung: 40 Minuten
Wartezeit: 3 Tage
Nacharbeit: 20 Minuten
gesamte Durchlaufzeit: mehr als 3 Tage

Merke

Eine lange Durchlaufzeit bedeutet nicht automatisch, dass Mitarbeiter langsam arbeiten.

Häufig entstehen Verzögerungen zwischen den aktiven Arbeitsschritten.

Weitere mögliche Messgrößen

Je nach Wertstrom können unter anderem betrachtet werden:

gesamte Durchlaufzeit
aktive Bearbeitungszeit
Wartezeit
Anzahl der Übergaben
Anzahl beteiligter Teams
Anzahl notwendiger Freigaben
Nacharbeitsquote
Fehlerquote
Abbruchquote
Wiederholungsquote
Automatisierungsgrad
First-Time-Right-Quote
Wiederherstellungszeit
Benutzeraufwand
Kosten pro Vorgang
Erreichung des gewünschten Outcomes
Benutzer- oder Kundenerfahrung
Anzahl ungeklärter Ausnahmen

Eine einzelne Kennzahl sollte nicht isoliert optimiert werden.

Beispiel:

Eine geringere Bearbeitungszeit kann erreicht werden, indem Tickets schneller an andere Teams weitergegeben werden.

Dadurch können jedoch:

mehr Übergaben,
längere Gesamtdauer,
schlechtere Kommunikation,
und mehr Nacharbeit

entstehen.

Übergaben sichtbar machen

Übergaben sind Stellen, an denen Arbeit, Verantwortung oder Informationen von einer Rolle, einem Team oder einem System zu einem anderen wechseln.

Beispiele:

Benutzer an Service Desk
Service Desk an Fachteam
internes Team an Lieferanten
Entwicklung an Betrieb
Einkauf an technische Administration
Führungskraft an Berechtigungsmanagement
automatisiertes System an menschlichen Bearbeiter

An Übergaben können entstehen:

Informationsverluste,
Missverständnisse,
Wartezeiten,
doppelte Erfassung,
unklare Verantwortung,
falsche Priorisierung,
und Rückfragen.

Bei jeder Übergabe sollte geprüft werden:

Welche Informationen werden benötigt?
Sind sie vollständig und verständlich?
Wer trägt danach die Verantwortung?
Ist der nächste Schritt eindeutig?
Wie wird der Empfang bestätigt?
Muss das Ergebnis zurückgemeldet werden?
Ist die Übergabe überhaupt notwendig?
Kann sie vereinfacht oder automatisiert werden?

Warteschlangen und Engpässe

Ein Engpass begrenzt den Fluss des gesamten Wertstroms.

Mögliche Engpässe sind:

einzelne Fachpersonen,
manuelle Genehmigungen,
fehlende Informationen,
begrenzte Testumgebungen,
Lieferzeiten,
unzureichende Lizenzen,
langsame technische Systeme,
überlastete Teams,
oder nicht automatisierte Routinetätigkeiten.

Anzeichen für einen Engpass:

Vorgänge sammeln sich vor einem bestimmten Schritt.
Die Wartezeit ist deutlich länger als die Bearbeitungszeit.
Viele Vorgänge benötigen dieselbe einzelne Person.
Nachgelagerte Teams warten regelmäßig auf Ergebnisse.
Aufgaben werden häufig eskaliert.
Mitarbeiter umgehen den vorgesehenen Ablauf.
Prioritäten werden ständig geändert.
Fehler entstehen durch Zeitdruck.

Wichtig

Wird nur ein Schritt vor dem eigentlichen Engpass beschleunigt, kann sich die Warteschlange am Engpass weiter vergrößern.

Nacharbeit und Rückschleifen

Nacharbeit entsteht, wenn ein Schritt erneut durchgeführt oder korrigiert werden muss.

Mögliche Ursachen:

unvollständige Anforderungen
falsche Kategorisierung
fehlende Freigabe
fehlerhafte technische Umsetzung
ungeeignete Testdaten
unklare Verantwortlichkeiten
veraltete Dokumentation
widersprüchliche Informationen
nicht berücksichtigte Abhängigkeiten
fehlende Benutzerbestätigung

Beispiel:

Benutzer beantragt Zugriff.
Administration richtet den Zugriff ein.
Fachverantwortlicher stellt fest, dass der falsche Berechtigungsumfang gewählt wurde.
Zugriff muss entfernt und erneut eingerichtet werden.

Die Nacharbeit erhöht:

Durchlaufzeit,
Kosten,
Risiko,
und Arbeitsbelastung.

Sie kann außerdem das Vertrauen der Stakeholder beeinträchtigen.

Kontrollen und Freigaben untersuchen

Kontrollen können notwendig sein für:

Sicherheit,
Datenschutz,
Qualität,
Risiko,
gesetzliche Anforderungen,
finanzielle Verantwortung,
und Nachvollziehbarkeit.

Beim Mapping sollte nicht automatisch jede Kontrolle entfernt werden.

Stattdessen wird geprüft:

Welches Risiko behandelt die Kontrolle?
Ist sie an der richtigen Stelle?
Wird sie tatsächlich fachlich durchgeführt?
Ist sie mehrfach vorhanden?
Passt ihr Umfang zum Risiko?
Sind Entscheidungskriterien eindeutig?
Besteht eine Vertretung?
Kann die Kontrolle automatisiert unterstützt werden?
Werden Ergebnisse dokumentiert?
Wird die Kontrolle regelmäßig auf ihre Wirksamkeit geprüft?

Typischer Fehler

Eine Genehmigung wird entfernt, nur weil sie Zeit kostet.

Zuerst muss verstanden werden, welches Risiko oder welche Verpflichtung sie behandelt.

Arbeit mit und ohne direkten Wertbeitrag

Nicht jeder notwendige Schritt erzeugt unmittelbar einen für den Benutzer sichtbaren Wert.

Eine praktische Unterscheidung kann sein:

Kategorie	Bedeutung	Beispiel
direkter Wertbeitrag	unterstützt unmittelbar das gewünschte Outcome	benötigten Zugriff bereitstellen
notwendige unterstützende Arbeit	ist für Sicherheit, Steuerung oder Zuverlässigkeit erforderlich	Berechtigung prüfen
vermeidbare Arbeit	besitzt keinen ausreichenden Nutzen oder entsteht durch Fehler	dieselben Daten erneut erfassen
Nacharbeit	korrigiert unvollständige oder fehlerhafte Ergebnisse	falsche Berechtigung entfernen

Nicht sichtbare Arbeit ist nicht automatisch unnötig.

Beispiele für notwendige unterstützende Tätigkeiten:

Sicherheitsprüfung
Protokollierung
Dokumentation
Test
Backup
Freigabe
Compliance-Nachweis

Diese Tätigkeiten sollten jedoch:

einen klaren Zweck besitzen,
angemessen gestaltet,
und möglichst effizient ausgeführt

werden.

Value Stream Mapping und die vier Dimensionen

Eine vollständige Untersuchung berücksichtigt alle vier Dimensionen.

Organizations and People

Welche Rollen und Teams sind beteiligt?
Sind Verantwortung und Befugnisse eindeutig?
Bestehen ausreichende Fähigkeiten und Kapazitäten?
Wie funktionieren Kommunikation und Zusammenarbeit?

Information and Technology

Welche Informationen werden benötigt?
Welche Systeme und Werkzeuge werden verwendet?
Sind Daten korrekt und aktuell?
Wo bestehen Medienbrüche oder manuelle Übertragungen?
Welche Automatisierung ist möglich?

Partners and Suppliers

Welche externen Anbieter sind beteiligt?
Welche Wartezeiten und Abhängigkeiten entstehen?
Sind Eskalationswege vorbereitet?
Unterstützen Verträge das benötigte Outcome?

Value Streams and Processes

Welche Schritte, Entscheidungen und Übergaben existieren?
Wo entstehen Wartezeiten, Nacharbeit und Engpässe?
Welche Prozesse und Practices werden verwendet?
Wie wird das Outcome überprüft?

Value Streams und der Product and Service Lifecycle

Die acht Lifecycle-Aktivitäten können in einem Value Stream unterschiedlich kombiniert werden.

Beispiel: neue Monitoring-Lösung einführen

Lifecycle-Aktivität	Möglicher Beitrag zum Value Stream
Discover	Bedarf, Ausfälle und heutige Überwachung verstehen
Design	Zielarchitektur, Alarmierung und Betriebsmodell gestalten
Acquire	Plattform, Lizenzen oder externe Leistungen beschaffen
Build	Lösung konfigurieren, integrieren und testen
Transition	Pilot und kontrollierte Einführung durchführen
Operate	Plattform zuverlässig betreiben
Deliver	relevante Monitoring-Leistungen für Teams bereitstellen
Support	Benutzer und Administratoren bei Problemen unterstützen

Ein anderer Value Stream verwendet möglicherweise nur einen Teil dieser Aktivitäten oder wiederholt einzelne Aktivitäten mehrfach.

Merke

Der Lifecycle liefert allgemeine Aktivitätsbereiche.

Der Value Stream verbindet die konkret benötigten Schritte für ein bestimmtes Outcome.

Value Streams und Management Practices

Ein Value Stream verwendet normalerweise mehrere Practices.

Beispiel: Incident eines extern betriebenen Cloud-Service

Schritt	Mögliche beteiligte Practice
Störung erkennen	Monitoring and Event Management
Benutzerkontakt erfassen	Service Desk
Auswirkungen und Priorität bewerten	Incident Management
Abhängigkeiten ermitteln	Service Configuration Management
bekannte Lösung suchen	Knowledge Management
Anbieter einbinden	Supplier Management
Service wiederherstellen	Incident Management und technische Practices
Ursache untersuchen	Problem Management
dauerhafte Korrektur steuern	Change Enablement
Erfahrung auswerten	Continual Improvement

Practices dürfen dabei nicht als getrennte Teilprozesse betrachtet werden, zwischen denen ein Vorgang nur weitergereicht wird.

Sie sollen gemeinsam das Ende-zu-Ende-Outcome unterstützen.

Praxisnahe Vorgehensweise zum Value Stream Mapping

Die folgende Vorgehensweise ist eine redaktionelle Praxisempfehlung dieses Buches.

Sie ist keine vorgeschriebene offizielle ITIL-Schrittfolge.

1. Zweck und Outcome festlegen

Zuerst wird geklärt:

Welcher Value Stream wird untersucht?
Welches Problem soll gelöst werden?
Welches Outcome soll erreicht werden?
Für welche Stakeholder?
Wie wird Erfolg erkannt?

Beispiel:

Ziel ist, neue Mitarbeiter spätestens zum vereinbarten Eintrittszeitpunkt mit einem vollständig nutzbaren und sicheren IT-Arbeitsplatz auszustatten.

2. Auslöser und Abschluss bestimmen

Auslöser:

Die Personalabteilung übermittelt eine vollständige und bestätigte Eintrittsmeldung.

Abschluss:

Der Mitarbeiter bestätigt, dass Anmeldung, Endgerät und benötigte Services funktionieren.

Dadurch wird vermieden, dass der Wertstrom zu früh endet.

3. Beteiligte Stakeholder bestimmen

Mögliche Beteiligte:

neuer Mitarbeiter
Personalabteilung
Führungskraft
Service Desk
Einkauf
IT Asset Management
Identitätsmanagement
Endgeräteverwaltung
Informationssicherheit
Lieferant

Zusätzlich sollte geklärt werden:

Wer besitzt die Ergebnisverantwortung?
Wer koordiniert den Wertstrom?
Wer darf Entscheidungen treffen?
Wer muss informiert werden?

4. Tatsächliche Schritte erfassen

Die Beteiligten beschreiben, wie ein realer Vorgang heute abläuft.

Nicht nur:

Wie sollte der Prozess funktionieren?

Sondern:

Was geschieht tatsächlich?

Dabei können reale Tickets oder Fälle verfolgt werden.

Mögliche Schritte:

Eintritt melden
Rolle und Zugriffe bestimmen
Freigaben einholen
Endgerät bestellen
Benutzerkonto erstellen
Lizenzen zuweisen
Endgerät konfigurieren
Sicherheitsmaßnahmen aktivieren
Zugriffe testen
Gerät übergeben
Arbeitsfähigkeit bestätigen

5. Informationen, Werkzeuge und Practices ergänzen

Für jeden Schritt wird geprüft:

Welche Information wird benötigt?
Woher stammt sie?
In welchem System wird sie gespeichert?
Welches Werkzeug wird verwendet?
Welche Practice unterstützt den Schritt?
Welche Lieferanten sind beteiligt?

Beispiel:

Schritt	Information	Werkzeug	Practice
Endgerät bereitstellen	Rolle und Hardwarestandard	Asset- und Ticketsystem	IT Asset Management
Konto erstellen	Name, Eintrittsdatum und Organisationseinheit	Verzeichnisdienst	Service Request Management
Zugriffe einrichten	genehmigter Berechtigungsumfang	IAM-System	Information Security Management
Nutzung bestätigen	Benutzerfeedback	Ticket oder Portal	Service Desk

6. Zeiten und Übergaben erfassen

Für jeden Schritt können erfasst werden:

Bearbeitungszeit
Wartezeit
Übergabe
Rückfrage
Wiederholung
Fehler
und Abbruch

Nicht jede Zeit muss auf die Minute genau bekannt sein.

Auch eine erste Einteilung kann hilfreich sein:

wenige Minuten
mehrere Stunden
ein Arbeitstag
mehrere Tage
stark schwankend

7. Probleme und Risiken kennzeichnen

Mögliche Beobachtungen:

Eintrittsmeldung kommt zu spät.
Führungskraft nennt unvollständige Zugriffe.
Bestellung benötigt manuelle E-Mail.
Es gibt keine Vertretung für die Freigabe.
Kontoanlage und Lizenzzuweisung erfolgen in getrennten Systemen.
Benutzer wird bei der Funktionsprüfung nicht beteiligt.
Lieferzeit ist nicht transparent.
Abschluss erfolgt ohne Bestätigung der Arbeitsfähigkeit.

Probleme sollten möglichst mit Fakten oder Beispielen belegt werden.

8. Ursachen untersuchen

Nicht jedes sichtbare Problem ist die eigentliche Ursache.

Beispiel:

Symptom: Endgerät ist am ersten Arbeitstag nicht verfügbar.

Mögliche Ursachen:

Eintritt wurde zu spät gemeldet.
Gerätebestand ist nicht bekannt.
Beschaffung dauert länger als geplant.
Hardwarestandard ist unklar.
Bestellung benötigt mehrere Freigaben.
kein Mindestbestand ist definiert.
Lieferantenleistung wird nicht überwacht.

Eine Verbesserung sollte möglichst die relevante Ursache behandeln und nicht nur das Symptom verschieben.

9. Zielzustand gestalten

Der Zielzustand beschreibt, wie der Wertstrom künftig funktionieren soll.

Mögliche Verbesserungen:

vollständiges digitales Eintrittsformular
klare Mindestvorlaufzeit
rollenbasierte Standardpakete
definierte Vertretungsregelung
transparenter Gerätebestand
automatische Kontoanlage nach Freigabe
gemeinsame Statusübersicht
standardisierte Funktionsprüfung
verbindliche Bestätigung der Arbeitsfähigkeit
Messung von Durchlaufzeit und Fehlern

Der Zielzustand sollte:

verständlich,
realistisch,
risikogerecht,
und messbar

sein.

10. Verbesserungen priorisieren und umsetzen

Verbesserungen können bewertet werden nach:

erwarteter Wirkung
Dringlichkeit
Risiko
Aufwand
Kosten
Abhängigkeiten
Umsetzbarkeit
und benötigten Fähigkeiten

Nicht alle Verbesserungen müssen gleichzeitig umgesetzt werden.

Ein iteratives Vorgehen kann beispielsweise beginnen mit:

vollständige Eintrittsmeldung sicherstellen
klare Verantwortlichkeit festlegen
Status sichtbar machen
Standardpakete definieren
geeignete Schritte automatisieren
Wirkung messen
weitere Engpässe bearbeiten

Value Stream Management nach dem Mapping

Nach der ersten Abbildung muss der Wertstrom fortlaufend gesteuert werden.

Dazu gehören:

Verantwortlichkeit festlegen
relevante Messgrößen überwachen
Abweichungen untersuchen
Feedback auswerten
Risiken beobachten
Verbesserungen priorisieren
Änderungen am Wertstrom kontrollieren
Dokumentation aktuell halten
und den Wertstrom regelmäßig erneut betrachten

Mögliche Fragen:

Wird das gewünschte Outcome erreicht?
Hat sich die Durchlaufzeit verbessert?
Entsteht weniger Nacharbeit?
Wurden Engpässe nur verlagert?
Hat sich die Benutzererfahrung verbessert?
Sind neue Risiken entstanden?
Werden Kontrollen weiterhin wirksam durchgeführt?
Passen die Messgrößen noch zum Ziel?

Governance von Value Streams

Für wichtige Value Streams sollte geklärt sein:

Wer trägt die Ende-zu-Ende-Verantwortung?
Welche Outcomes und Ziele gelten?
Welche Risiken dürfen akzeptiert werden?
Welche Kontrollen sind verbindlich?
Wer darf den Wertstrom verändern?
Wie werden Leistung und Abweichungen überwacht?
Wie werden Konflikte zwischen Teams entschieden?
Welche Verbesserungen erhalten Priorität?
Welche Lieferantenabhängigkeiten bestehen?

Ein Value Stream kann mehrere organisatorische Verantwortungsbereiche überschreiten.

Trotzdem muss eine geeignete Koordination des Gesamtergebnisses bestehen.

Typischer Fehler

Jeder Schritt besitzt einen Verantwortlichen, aber niemand verantwortet das gesamte Ende-zu-Ende-Outcome.

Value Stream Mapping bei einem Incident

Beispielwertstrom:

Benutzer nach einem Serviceausfall wieder arbeitsfähig machen

Mögliche Schritte:

Störung erkennen oder melden
Incident erfassen
Auswirkungen und Dringlichkeit bewerten
betroffenen Service bestimmen
erste Diagnose durchführen
zuständiges Fachwissen einbinden
Service wiederherstellen
Funktion technisch prüfen
Nutzbarkeit mit dem Benutzer bestätigen
Kommunikation abschließen
notwendige Folgeaktivitäten einleiten

Mögliche Probleme:

Benutzer muss dieselben Informationen mehrfach nennen.
Ticket wird mehrfach weitergeleitet.
Serviceabhängigkeiten sind unbekannt.
Lieferantenkontakt beginnt zu spät.
Statusinformationen sind widersprüchlich.
technische Wiederherstellung wird nicht aus Benutzersicht geprüft.
wiederkehrende Incidents werden nicht an Problem Management übergeben.

Mögliche Messgrößen:

Zeit bis zur Erfassung
Zeit bis zur ersten qualifizierten Reaktion
gesamte Wiederherstellungszeit
Anzahl der Übergaben
erneute Kontaktaufnahme
wiederholte Incidents
Benutzerbestätigung
Qualität der Kommunikation

Value Stream Mapping bei einem Service Request

Beispielwertstrom:

genehmigte Standardsoftware für einen Benutzer nutzbar bereitstellen

Mögliche Schritte:

Software anfordern
Berechtigung und Bedarf prüfen
Lizenzverfügbarkeit kontrollieren
erforderliche Freigabe einholen
Software bereitstellen
Installation oder Zuweisung prüfen
Benutzer informieren
Nutzbarkeit bestätigen
Asset- und Lizenzinformationen aktualisieren

Mögliche Verbesserungen:

verständliches Serviceangebot
rollenbasierte Standardgenehmigung
automatische Lizenzprüfung
automatisierte Softwareverteilung
automatische Statusinformationen
technische Erfolgskontrolle
Abschluss erst nach bestätigter Nutzbarkeit

Value Stream Mapping bei einem Change

Beispielwertstrom:

Sicherheitsupdate kontrolliert und ohne vermeidbare Serviceunterbrechung bereitstellen

Mögliche Schritte:

Handlungsbedarf erkennen
betroffene Produkte und Services bestimmen
Risiko und Dringlichkeit bewerten
Update testen
Umsetzungs- und Rückfallplan erstellen
Autorisierung einholen
Beteiligte informieren
Update bereitstellen
technische Funktion prüfen
Service-Nutzbarkeit prüfen
Monitoring fortführen
Dokumentation und Konfigurationsinformationen aktualisieren

Mögliche Probleme:

unklare Abhängigkeiten
fehlende Testumgebung
lange Wartezeit auf Freigabe
manuelle Wiederholung derselben Prüfungen
fehlende Rückfallkriterien
Service Desk wird nicht informiert
technischer Erfolg wird ohne Serviceprüfung angenommen

Value Streams und Automatisierung

Automatisierung kann den Fluss verbessern, wenn:

der Wertstrom verstanden wurde,
Eingabedaten zuverlässig sind,
Regeln eindeutig sind,
Ausnahmen behandelt werden,
und Ergebnisse kontrolliert werden.

Geeignete Beispiele:

automatische Ticketanlage aus relevanten Events
automatische Vollständigkeitsprüfung von Anträgen
standardisierte Genehmigungsweiterleitung
automatische Softwareverteilung
automatische Aktualisierung von Asset-Daten
Statusbenachrichtigungen
automatische technische Tests
Erkennung von Wartezeiten und Eskalationsbedarf

Ungeeignet ist Automatisierung, wenn:

der Ablauf unklar ist,
Verantwortlichkeiten fehlen,
Eingabedaten unzuverlässig sind,
Ausnahmen nicht bekannt sind,
oder der Schritt keinen ausreichenden Nutzen besitzt.

Grundsatz

Einen schlechten Wertstrom zu automatisieren kann dazu führen, dass Fehler und Verschwendung nur schneller ausgeführt werden.

Künstliche Intelligenz in Value Streams

KI kann innerhalb von Value Streams beispielsweise unterstützen bei:

Klassifizierung von Anfragen
Erkennung ähnlicher Vorgänge
Zusammenfassung von Informationen
Prognose möglicher Engpässe
Analyse von Durchlaufzeiten
Vorschlägen für passende Wissensartikel
Erkennung wiederkehrender Muster
und Unterstützung der Kommunikation

Dabei müssen unter anderem berücksichtigt werden:

Datenqualität
Datenschutz
Informationssicherheit
Nachvollziehbarkeit
mögliche Verzerrungen
menschliche Kontrolle
Fehlerbehandlung
und Verantwortung

Beispiel:

Eine KI schlägt die automatische Genehmigung eines Zugriffs vor.

Vor einer solchen Automatisierung muss geklärt sein:

Welche Zugriffe dürfen standardisiert genehmigt werden?
Welche Rollen und Risiken sind betroffen?
Welche Daten verwendet die KI?
Wer überprüft Ausnahmen?
Wie werden falsche Entscheidungen erkannt?
Wer trägt die Ergebnisverantwortung?

Sicherheitsrelevant

Die Verwendung von KI verändert nicht automatisch bestehende Verantwortlichkeiten und Governance-Anforderungen.

Value Streams und Continual Improvement

Value Stream Mapping liefert eine Grundlage für Continual Improvement.

Möglicher Verbesserungszyklus:

benötigtes Outcome bestimmen
aktuellen Wertstrom erfassen
Daten und Feedback sammeln
Engpässe und Risiken erkennen
Ursachen untersuchen
Zielzustand gestalten
Verbesserungen priorisieren
schrittweise umsetzen
Wirkung messen
Wertstrom erneut bewerten

Verbesserungen können betreffen:

einzelne Schritte,
Übergaben,
Informationen,
Rollen,
Technologien,
Lieferanten,
Kontrollen,
oder den gesamten Aufbau des Wertstroms.

Merke

Value Stream Mapping zeigt nicht nur, wo Arbeit stattfindet.

Es zeigt, wo Wertfluss behindert wird und wo Verbesserungen ansetzen können.

Typische Fehler beim Value Stream Mapping

Fehler 1: Nur den dokumentierten Soll-Prozess abbilden

Der tatsächlich gelebte Arbeitsablauf bleibt unbekannt.

Fehler 2: An Abteilungsgrenzen aufhören

Der gesamte Weg zum Stakeholder-Outcome wird nicht betrachtet.

Fehler 3: Zu großen Umfang wählen

Der Wertstrom wird so umfangreich, dass keine konkreten Verbesserungen mehr erkennbar sind.

Fehler 4: Nur technische Schritte betrachten

Menschen, Informationen, Lieferanten, Kontrollen und Benutzererfahrung fehlen.

Fehler 5: Nur Bearbeitungszeiten messen

Wartezeit, Übergaben, Nacharbeit und Verzögerungen bleiben unsichtbar.

Fehler 6: Jede nicht sichtbare Tätigkeit als Verschwendung betrachten

Notwendige Sicherheits-, Qualitäts- oder Compliance-Kontrollen werden ungeprüft infrage gestellt.

Fehler 7: Das Diagramm als Endergebnis betrachten

Probleme werden sichtbar gemacht, aber Verbesserungen werden nicht priorisiert oder umgesetzt.

Fehler 8: Mitarbeiter für Probleme im Wertstrom verantwortlich machen

Systemische Ursachen wie fehlende Informationen, ungeeignete Werkzeuge und widersprüchliche Ziele werden übersehen.

Fehler 9: Nur einen idealen Einzelfall betrachten

Ausnahmen, Fehler, Eskalationen und Lieferantenabhängigkeiten bleiben unbekannt.

Fehler 10: Lokale Kennzahlen optimieren

Einzelne Teams verbessern ihre Werte, während sich das Ende-zu-Ende-Outcome verschlechtert.

Fehler 11: Zielzustand ohne Messgrößen gestalten

Später kann nicht festgestellt werden, ob die Verbesserung tatsächlich wirksam war.

Fehler 12: Zu früh automatisieren

Ein ungeeigneter oder instabiler Ablauf wird technisch festgeschrieben.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sehen häufig nur einen Teil des gesamten Wertstroms.

Beispiele:

Benutzerkonto erstellen
Server konfigurieren
Firewall-Regel ändern
Software verteilen
Incident untersuchen
Backup wiederherstellen
Monitoring-Alarm bearbeiten

Value-Stream-Denken ergänzt folgende Fragen:

Welcher Auslöser führte zu meiner Aufgabe?
Welches Outcome soll erreicht werden?
Welche Schritte fanden bereits statt?
Welche Informationen fehlen mir?
Wer arbeitet nach meinem Schritt weiter?
Welche Auswirkungen besitzt eine Verzögerung?
Welche Rückmeldung muss ich liefern?
Welche Practices und Teams sind beteiligt?
Wie wird der Erfolg aus Benutzersicht geprüft?
Kann mein Arbeitsschritt vereinfacht oder automatisiert werden?
Erzeuge ich möglicherweise unnötige Nacharbeit für andere?

Praxistipp

Dokumentiere nicht nur, was du getan hast.

Dokumentiere auch das Ergebnis, relevante Abhängigkeiten und den nächsten notwendigen Schritt.

30-Sekunden-Prüfung eines Value Streams

Auslöser: Was startet den Wertstrom?
Stakeholder: Für wen wird das Outcome benötigt?
Outcome: Wann ist das tatsächliche Ziel erreicht?
Schritte: Welche Tätigkeiten sind notwendig?
Verantwortung: Wer entscheidet und wer führt aus?
Informationen: Welche Daten werden benötigt?
Übergaben: Wo wechselt die Arbeit zwischen Beteiligten?
Fluss: Wo entstehen Wartezeit, Nacharbeit oder Engpässe?
Kontrollen: Welche Prüfungen sind wirklich erforderlich?
Messung: Wie wird Erfolg festgestellt?
Verbesserung: Welcher nächste Schritt verbessert den Wertstrom?

Checkliste vor dem Mapping

Checkliste für die Ist-Aufnahme

Checkliste für den Zielzustand

Checkliste nach der Verbesserung

Schnellreferenz

Frage	Bedeutung
Was startet den Wertstrom?	Auslöser bestimmen
Für wen wird gearbeitet?	Stakeholder bestimmen
Was soll erreicht werden?	Outcome definieren
Welche Schritte finden statt?	tatsächlichen Arbeitsfluss erfassen
Wer ist beteiligt?	Rollen, Teams und Lieferanten bestimmen
Welche Informationen werden benötigt?	Informationsfluss untersuchen
Wo wartet die Arbeit?	Warteschlangen erkennen
Wo wird Arbeit wiederholt?	Nacharbeit erkennen
Wo wechselt Verantwortung?	Übergaben untersuchen
Welche Kontrollen sind notwendig?	Risiken und Vorgaben berücksichtigen
Wie wird Erfolg gemessen?	geeignete Messgrößen bestimmen
Was sollte zuerst verbessert werden?	Verbesserungen priorisieren

Zusammenfassende Darstellung

Bedarf, Nachfrage oder Chance
↓
Auslöser des Value Streams
↓
miteinander verbundene Schritte
↓
Menschen · Practices · Informationen · Technologien · Lieferanten
↓
Übergaben · Entscheidungen · Kontrollen · Rückmeldungen
↓
Output
↓
überprüftes Outcome
↓
gemeinsam ermöglichter Wert
↓
Feedback und Continual Improvement

Aufbau einer einfachen Value-Stream-Karte

Auslöser

Was startet den Wertstrom?

↓

Schritt 1

Verantwortliche Rolle · benötigte Information · Ergebnis

↓ Übergabe oder Wartezeit

Schritt 2

Verantwortliche Rolle · verwendete Practice · Werkzeug

↓ Entscheidung oder Kontrolle

Schritt 3

technische oder organisatorische Umsetzung

↓

Ergebnisprüfung

Funktioniert das Produkt oder der Service technisch?

↓

Outcome-Prüfung

Kann der Stakeholder das benötigte Ergebnis erreichen?

↓

Feedback und Verbesserung

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.9 Continual Improvement
2.10 ITIL an den eigenen Kontext anpassen
Incident Management
Service Request Management
Change Enablement
Problem Management
Measurement and Reporting

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL-Version-5-Informationen bestätigen:

Value Stream Mapping and Management ist Bestandteil von ITIL Foundation Version 5.
Value Streams sollen identifiziert, abgebildet und gesteuert werden.
Ziel sind besserer Fluss, höhere Sichtbarkeit und bessere Outcomes über digitale Produkte und Services hinweg.
Geschäfts-Wertströme und der Product and Service Lifecycle sollen gemeinsam betrachtet werden, um die Unterstützung des Geschäfts durch digitale Technologie zu verstehen.
ITIL Version 5 verwendet weiterhin das ITIL Value System und eine vereinfachte Value Chain.
Digitale Produkte können als integrierte Value Streams über ihren vollständigen Lebenszyklus betrachtet werden.

Einordnung

Die auf dieser Seite dargestellte Vorgehensweise zur:

Abgrenzung eines Value Streams,
Erfassung von Bearbeitungs- und Wartezeiten,
Untersuchung von Übergaben,
Gestaltung eines Zielzustands,
Priorisierung von Verbesserungen,
und Verwendung der Checklisten

ist eine praxisnahe redaktionelle Methode dieses unabhängigen Nachschlagewerks.

Sie ist keine wörtliche offizielle ITIL-Methode und keine für jede Organisation vorgeschriebene Notation.

Die konkrete Darstellungsform und der benötigte Detaillierungsgrad müssen an Ziel, Risiko, Komplexität und verfügbare Informationen angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.9 Continual Improvement

Kurz erklärt

Continual Improvement beschreibt die fortlaufende Verbesserung von:

digitalen Produkten,

Services,

Management Practices,

Wertströmen,

Prozessen,

Technologien,

Informationen,

Fähigkeiten,

Zusammenarbeit,

und Erfahrungen der Stakeholder.

Continual Improvement ist:

Bestandteil des ITIL Value Systems,

eine der 34 ITIL Management Practices,

und ein grundlegender Gedanke über den gesamten Product and Service Lifecycle.

ITIL Version 5 verwendet ein überarbeitet formuliertes Continual Improvement Model mit sieben Schritten.

Warum Continual Improvement notwendig ist

Produkte, Services und Arbeitsweisen bleiben nicht dauerhaft optimal.

Sie werden beeinflusst durch:

veränderte Benutzeranforderungen,
neue Geschäftsziele,
neue Technologien,
technische Schulden,
Sicherheitsrisiken,
neue gesetzliche Anforderungen,
steigende Kosten,
veränderte Lieferantenleistungen,
neue Erkenntnisse aus Incidents,
Rückmeldungen von Benutzern,
und Erfahrungen aus dem laufenden Betrieb.

Auch eine heute wirksame Lösung kann später ungeeignet werden.

Beispiele:

Die Anzahl der Benutzer steigt.
Eine bisher unterstützte Softwareversion erreicht ihr Lebensende.
Ein Lieferant verändert Preise oder Leistungsumfang.
Ein manueller Ablauf verursacht bei wachsender Menge zu viele Fehler.
Eine Sicherheitsanforderung wird verschärft.
Ein Service erreicht technische Zielwerte, wird von Benutzern aber als unzuverlässig wahrgenommen.
Ein Wiederherstellungsverfahren funktioniert unter den aktuellen Bedingungen nicht mehr.
Eine ursprünglich sinnvolle Kontrolle verursacht inzwischen unnötige Wartezeiten.

Merke

Verbesserung ist nicht nur notwendig, wenn etwas vollständig fehlschlägt.

Sie ist auch notwendig, damit weiterhin wirksame Produkte und Services mit veränderten Anforderungen Schritt halten.

Continual und Continuous unterscheiden

Die Begriffe werden im allgemeinen Sprachgebrauch häufig miteinander vermischt.

Begriff	Vereinfachte Bedeutung
Continual Improvement	wiederkehrende Verbesserungsaktivitäten in angemessenen Abständen
Continuous Improvement	Verbesserung als weitgehend ununterbrochene Aktivität

ITIL verwendet den Begriff:

Continual Improvement

Das bedeutet nicht, dass jederzeit ohne Unterbrechung an jeder Sache gearbeitet werden muss.

Verbesserungen können:

geplant,
priorisiert,
schrittweise umgesetzt,
unterbrochen,
überprüft,
und später fortgeführt

werden.

Entscheidend ist, dass Verbesserung dauerhaft in der Arbeitsweise verankert bleibt.

Continual Improvement im ITIL Value System

Continual Improvement ist einer der fünf Bestandteile des ITIL Value Systems.

Das Value System verbindet:

Guiding Principles,
Governance,
Value Chain Activities,
Management Practices,
und Continual Improvement.

Continual Improvement wirkt dabei nicht nur auf einen einzelnen Bereich.

Verbessert werden können:

das gesamte Value System,
einzelne Management Practices,
Value Streams,
Produkte,
Services,
technische Komponenten,
Organisation und Zusammenarbeit,
Informationen,
Partnerbeziehungen,
und konkrete Arbeitsanweisungen.

Wichtig

Continual Improvement ist nicht nur eine nachgelagerte Tätigkeit.

Es wirkt auf alle Bestandteile des Value Systems und auf den gesamten Product and Service Lifecycle.

Continual Improvement als Management Practice

Als Management Practice benötigt Continual Improvement mehr als einzelne Verbesserungsideen.

Zu einer wirksamen Practice können gehören:

klare Verantwortlichkeiten,
geeignete Fähigkeiten,
verfügbare Zeit,
verlässliche Informationen,
Messgrößen,
ein Verbesserungsregister,
Priorisierungskriterien,
Entscheidungsbefugnisse,
Werkzeuge,
Kommunikation,
Wissen,
und regelmäßige Erfolgskontrolle.

Eine Organisation kann mögliche Rollen verwenden wie:

Continual Improvement Manager,
Practice Owner,
Service Owner,
Product Owner,
Improvement Owner,
Improvement Champion,
oder verantwortlicher Teamleiter.

ITIL schreibt nicht für jede Organisation dieselben Rollenbezeichnungen vor.

Entscheidend ist, dass für eine Verbesserungsinitiative geklärt ist:

Wer koordiniert sie?
Wer entscheidet?
Wer setzt Maßnahmen um?
Wer stellt Ressourcen bereit?
Wer misst die Ergebnisse?
Wer verantwortet die nachhaltige Verankerung?

Verbesserung ist Aufgabe aller Beteiligten

Continual Improvement darf nicht ausschließlich einer zentralen Verbesserungsstelle überlassen werden.

Verbesserungsmöglichkeiten können erkannt werden durch:

Benutzer,
Service Desk,
Administratoren,
Entwickler,
Informationssicherheit,
Product Owner,
Service Owner,
Lieferanten,
Führungskräfte,
Fachabteilungen,
und andere Stakeholder.

Beispiele:

Ein Service-Desk-Mitarbeiter erkennt eine häufige Rückfrage.
Ein Administrator erkennt einen fehleranfälligen manuellen Arbeitsschritt.
Ein Benutzer meldet eine unverständliche Servicebeschreibung.
Ein Lieferant weist auf eine neue technische Möglichkeit hin.
Ein Service Owner erkennt eine wiederkehrende Abweichung von einem Serviceziel.
Ein Security-Team erkennt eine unsichere Alttechnologie.
Ein Product Owner erkennt, dass eine Funktion kaum verwendet wird.

Grundsatz

Jeder kann Verbesserungen vorschlagen.

Nicht jeder kann allein über Priorität, Ressourcen und Umsetzung entscheiden.

Verbesserung muss gesteuert werden

Ohne eine gemeinsame Arbeitsweise können Verbesserungen:

verloren gehen,
mehrfach bearbeitet werden,
miteinander konkurrieren,
nur nach persönlicher Vorliebe ausgewählt werden,
ohne ausreichende Daten begonnen werden,
oder nach der Umsetzung nicht überprüft werden.

Eine wirksame Steuerung sorgt dafür, dass Verbesserungsideen:

erfasst,
verstanden,
bewertet,
priorisiert,
verantwortet,
umgesetzt,
gemessen,
und nachhaltig verankert

werden.

Das ITIL Continual Improvement Model

ITIL Version 5 verwendet ein Continual Improvement Model mit sieben Schritten.

Nr.	Offizielle englische Leitfrage	Praxisnahe deutsche Bedeutung
1	What is the vision?	Welche Richtung, Ziele und Grenzen gelten?
2	Where are we now?	Wie sieht der tatsächliche Ausgangszustand aus?
3	Where do we want to be?	Welcher konkrete Zielzustand soll erreicht werden?
4	How do we get there?	Welcher Weg führt vom Ausgangs- zum Zielzustand?
5	Take action	Die geplanten Maßnahmen iterativ umsetzen
6	Are we getting there?	Prüfen, ob die Initiative den Zielzustand tatsächlich erreicht
7	How do we keep the improvements relevant?	Ergebnisse verankern und ihre weitere Relevanz sicherstellen

Versionsabhängig

Die Anzahl der Schritte wurde gegenüber ITIL 4 nicht verändert.

In ITIL Version 5 wurden einzelne Schrittbezeichnungen präzisiert.

Dieses Buch verwendet deshalb die aktuellen Bezeichnungen aus ITIL Version 5.

Das Modell ist iterativ

Die sieben Schritte bilden keine einmalig zu durchlaufende starre Abfolge.

Während einer Initiative kann es notwendig sein:

die Vision zu präzisieren,
weitere Ausgangsdaten zu erfassen,
den Zielzustand anzupassen,
einen anderen Umsetzungsweg zu wählen,
zusätzliche Maßnahmen aufzunehmen,
oder eine Initiative zu beenden.

Beispiel:

Während der Umsetzung wird festgestellt, dass die angenommene Ursache nicht zutrifft.

Dann kann die Initiative zu folgenden Schritten zurückkehren:

Where are we now?
Where do we want to be?
How do we get there?

Merke

Ein Rücksprung im Modell ist nicht automatisch ein Fehler.

Er kann zeigen, dass Feedback und neue Erkenntnisse tatsächlich berücksichtigt werden.

Das Model ist skalierbar

Das Continual Improvement Model kann für unterschiedlich große Initiativen verwendet werden.

Beispiele:

Kleine Verbesserung

Pflichtfeld in einem Ticketformular anpassen
veralteten Wissensartikel korrigieren
unnötige Monitoring-Meldung entfernen

Mittlere Verbesserung

Onboarding-Ablauf vereinfachen
Zertifikatsüberwachung einführen
Backup-Tests standardisieren
Incident-Kommunikation verbessern

Größere Verbesserung

neues Ticketsystem einführen
Service Desk neu organisieren
kritischen Service auf eine neue Plattform migrieren
unternehmensweites Identitätsmanagement verbessern

Der Umfang der:

Analyse,
Dokumentation,
Governance,
Messung,
und Kommunikation

muss an Größe, Risiko und Komplexität angepasst werden.

1. What is the vision?

Zentrale Frage

Welche Richtung, Ziele, Rahmenbedingungen und Grenzen gelten für die Verbesserung?

Eine Verbesserung benötigt einen verständlichen Bezug zu:

Strategie,
Zielen,
Stakeholder-Erwartungen,
Risiken,
Produkten,
Services,
und gewünschten Outcomes.

Ohne eine klare Vision können zwar einzelne Maßnahmen umgesetzt werden, ihr Beitrag zum tatsächlichen Wert bleibt jedoch unklar.

Beispiel:

Unzureichende Vision:

Wir wollen das Ticketsystem verbessern.

Präzisere Vision:

Benutzer sollen Störungen und Anfragen einfach melden können. Die zuständigen Teams sollen vollständige Informationen erhalten, damit Vorgänge schneller und mit weniger Rückfragen bearbeitet werden.

Bestandteile einer Vision

Eine Vision kann unter anderem beschreiben:

Anlass der Verbesserung,
betroffene Stakeholder,
gewünschte Outcomes,
strategischen Zusammenhang,
Geltungsbereich,
wichtige Grenzen,
erwarteten Nutzen,
und nicht akzeptierbare Auswirkungen.

Beispiel:

Der Onboarding-Wertstrom soll neue Mitarbeiter spätestens zum vereinbarten Eintrittsdatum mit einem sicheren und vollständig nutzbaren IT-Arbeitsplatz versorgen. Sicherheitsfreigaben dürfen dadurch nicht umgangen werden.

Leitfragen zu What is the vision?

Warum ist die Verbesserung notwendig?
Welches Problem oder welche Chance besteht?
Welches Produkt, welcher Service oder welche Practice ist betroffen?
Welche Stakeholder sind relevant?
Welches Outcome wird angestrebt?
Wie unterstützt die Verbesserung die Ziele der Organisation?
Welche Grenzen und Vorgaben gelten?
Welche Risiken dürfen nicht entstehen?
Welche Erwartungen besitzen Führungskräfte und Stakeholder?
Wer muss die Vision unterstützen?
Was gehört ausdrücklich nicht zum Umfang?

Typische Fehler bei der Vision

Verbesserung nur als technische Maßnahme beschreiben
keinen Bezug zu Stakeholdern oder Outcomes herstellen
zu allgemeinen oder unrealistischen Zielzustand formulieren
widersprüchliche Erwartungen nicht klären
Risiken und Grenzen nicht berücksichtigen
mehrere unterschiedliche Probleme in einer Initiative vermischen
Lösung bereits festlegen, bevor der tatsächliche Bedarf verstanden ist

2. Where are we now?

Zentrale Frage

Wie sieht der tatsächliche gegenwärtige Zustand aus?

Der aktuelle Zustand bildet die Ausgangsbasis für die Verbesserung.

Ohne eine nachvollziehbare Baseline kann später nicht zuverlässig festgestellt werden, ob sich etwas verbessert hat.

Zu untersuchen sind beispielsweise:

aktuelle Leistung,
bestehende Arbeitsweisen,
vorhandene Fähigkeiten,
Technologien,
Rollen,
Kosten,
Risiken,
Probleme,
Stakeholder-Erfahrung,
und technische Schulden.

Geeignete Informationsquellen

Der Ausgangszustand kann untersucht werden anhand von:

Tickets,
Monitoring-Daten,
Protokollen,
Messwerten,
Benutzerfeedback,
Interviews,
Beobachtungen,
Value Stream Mapping,
Auditergebnissen,
Risikobewertungen,
Lieferantenberichten,
bestehenden Dokumentationen,
Tests,
und Stichproben.

Wichtig

Die bestehende Dokumentation zeigt möglicherweise den vorgesehenen Ablauf.

Sie beweist nicht automatisch, wie tatsächlich gearbeitet wird.

Baseline

Eine Baseline ist ein dokumentierter Ausgangswert oder Ausgangszustand, mit dem spätere Ergebnisse verglichen werden können.

Beispiele:

durchschnittliche Durchlaufzeit: fünf Arbeitstage
30 Prozent der Onboardings sind am ersten Arbeitstag unvollständig
monatlich zwölf Incidents wegen abgelaufener Zertifikate
40 Prozent der Tickets benötigen Rückfragen
durchschnittlich vier Teamübergaben pro Incident
Restore-Test war bei zwei von zehn Systemen erfolgreich

Die Baseline sollte:

relevant,
nachvollziehbar,
ausreichend zuverlässig,
und zum gewünschten Outcome passend

sein.

Leitfragen zu Where are we now?

Was geschieht heute tatsächlich?
Welche Daten liegen vor?
Welche Outcomes werden aktuell erreicht?
Was funktioniert bereits gut?
Wo bestehen Probleme?
Welche Risiken und technischen Schulden sind bekannt?
Welche Stakeholder sind betroffen?
Wie wird die heutige Erfahrung wahrgenommen?
Welche Fähigkeiten und Ressourcen stehen zur Verfügung?
Welche Lieferanten und Abhängigkeiten bestehen?
Welche Maßnahmen wurden bereits versucht?
Welche Annahmen müssen überprüft werden?
Welche Baseline kann verwendet werden?

Typische Fehler bei der Ist-Analyse

nur Probleme betrachten und funktionierende Bestandteile ignorieren
ausschließlich leicht verfügbare Kennzahlen verwenden
subjektive Vermutungen als Baseline verwenden
Benutzer- und Kundenerfahrung nicht berücksichtigen
tatsächlichen Ablauf nicht beobachten
Datenqualität nicht prüfen
unterschiedliche Produkt- oder Servicevarianten vermischen
bereits mit der Umsetzung beginnen, bevor die Ausgangslage verstanden ist

3. Where do we want to be?

Zentrale Frage

Welcher konkrete und überprüfbare Zielzustand soll als Nächstes erreicht werden?

Der Zielzustand übersetzt die Vision in konkrete Outcomes und Erfolgskriterien.

Er sollte ausreichend:

verständlich,
realistisch,
relevant,
messbar,
und zeitlich einordenbar

sein.

Beispiel:

Vision:

Der Onboarding-Prozess soll neue Mitarbeiter rechtzeitig arbeitsfähig machen.

Konkreter Zielzustand:

Innerhalb von drei Monaten sollen mindestens 95 Prozent der vollständig und fristgerecht gemeldeten Mitarbeiter am ersten Arbeitstag über Endgerät, Benutzerkonto und genehmigte Standardzugriffe verfügen.

Critical Success Factors und Key Performance Indicators

Ein Critical Success Factor beschreibt eine Voraussetzung oder ein Ergebnis, das für den Erfolg wesentlich ist.

Beispiel:

Vollständige Eintrittsinformationen liegen rechtzeitig vor.

Ein Key Performance Indicator unterstützt die Messung.

Beispiel:

Anteil vollständiger Eintrittsmeldungen mindestens zehn Arbeitstage vor dem Eintritt.

Kennzahlen sollten nicht nur leicht messbare Aktivität abbilden.

Sie sollten einen erkennbaren Bezug besitzen zu:

Outcome,
Wert,
Qualität,
Erfahrung,
Risiko,
oder Nachhaltigkeit.

Leading und Lagging Indicators

Art	Bedeutung	Beispiel
Leading Indicator	früher Hinweis auf die wahrscheinliche Entwicklung	Anteil rechtzeitig eingegangener Eintrittsmeldungen
Lagging Indicator	zeigt das bereits eingetretene Ergebnis	Anteil am ersten Tag vollständig arbeitsfähiger Mitarbeiter

Beide Perspektiven können gemeinsam hilfreich sein.

Nur das Endergebnis zu messen kann zu spät sein.

Nur vorbereitende Aktivität zu messen beweist noch nicht, dass das Outcome erreicht wurde.

Leitfragen zu Where do we want to be?

Welches konkrete Outcome soll erreicht werden?
Was soll sich für Stakeholder verändern?
Welche Qualität wird benötigt?
Welche Risiken sollen reduziert werden?
Welche Zielwerte sind sinnvoll?
Welche Fähigkeiten müssen aufgebaut werden?
Welche technischen Schulden sollen reduziert werden?
Welche Grenzen und Vorgaben gelten?
Wann soll der nächste Zielzustand erreicht sein?
Wie wird Erfolg gemessen?
Welche unbeabsichtigten Auswirkungen müssen überwacht werden?
Ist der Zielzustand realistisch und ausreichend unterstützt?

Typische Fehler beim Zielzustand

Ziel nur als Aktivität formulieren
keine Erfolgskriterien definieren
ausschließlich technische Kennzahlen verwenden
unrealistische Zielwerte festlegen
zu viele Ziele gleichzeitig verfolgen
Nebenwirkungen nicht berücksichtigen
nur einen endgültigen Idealzustand statt eines erreichbaren nächsten Zustands beschreiben
Zielwerte festlegen, ohne Baseline zu kennen

4. How do we get there?

Zentrale Frage

Welcher realistische Weg führt vom aktuellen zum gewünschten Zustand?

In diesem Schritt wird der Verbesserungsweg gestaltet.

Dazu können gehören:

Lösungsoptionen,
Maßnahmen,
Prioritäten,
Ressourcen,
Verantwortlichkeiten,
Risiken,
Abhängigkeiten,
Zeitplanung,
Tests,
Kommunikation,
und Messung.

Der Weg kann:

direkt,
schrittweise,
experimentell,
oder explorativ

sein.

In komplexen Situationen ist der vollständige Weg möglicherweise nicht von Anfang an bekannt.

Dann können kleine Experimente und Feedback notwendig sein.

Verbesserungsoptionen bewerten

Mögliche Kriterien:

erwarteter Nutzen
Beitrag zum Outcome
Risiko
Aufwand
Kosten
Dringlichkeit
technische Machbarkeit
organisatorische Machbarkeit
Abhängigkeiten
benötigte Fähigkeiten
Stakeholder-Unterstützung
Nachhaltigkeit
Rückfallmöglichkeit
und Geschwindigkeit des Erkenntnisgewinns

Beispiel:

Problem:

Viele Tickets enthalten unvollständige Informationen.

Mögliche Optionen:

Formular verständlicher gestalten
dynamische Pflichtfelder verwenden
Benutzer mit Beispielen unterstützen
Serviceangebote klarer beschreiben
automatische Plausibilitätsprüfung verwenden
Service-Desk-Mitarbeiter schulen
Eingangskanäle vereinheitlichen

Nicht jede Option muss gleichzeitig umgesetzt werden.

Verbesserungsplan

Ein Verbesserungsplan kann enthalten:

Feld	Inhalt
Maßnahme	Was wird verändert?
Verantwortlich	Wer koordiniert die Umsetzung?
Ziel	Welches Outcome wird unterstützt?
Priorität	Wie wichtig und dringend ist die Maßnahme?
Ressourcen	Welche Zeit, Fähigkeiten und Mittel werden benötigt?
Abhängigkeiten	Was muss vorher oder gleichzeitig geschehen?
Risiken	Welche negativen Folgen sind möglich?
Messung	Wie wird die Wirkung festgestellt?
Termin	Wann beginnt und endet die nächste Iteration?
Status	geplant, aktiv, blockiert, abgeschlossen oder verworfen

Leitfragen zu How do we get there?

Welche Optionen bestehen?
Welche Maßnahme besitzt den größten erwarteten Nutzen?
Was ist der kleinste sinnvolle nächste Schritt?
Kann ein Pilot oder Experiment verwendet werden?
Welche Ressourcen werden benötigt?
Wer trägt Verantwortung?
Welche Practices sind beteiligt?
Welche Lieferanten werden benötigt?
Welche Risiken und Abhängigkeiten bestehen?
Welche Governance-Entscheidungen sind notwendig?
Wie werden Stakeholder einbezogen?
Wie wird Feedback erhoben?
Wie wird bei Problemen reagiert?
Welche Rückfall- oder Anpassungsmöglichkeit besteht?

Typische Fehler bei der Planung

Maßnahmen auswählen, bevor Ursachen verstanden wurden
ausschließlich eine technische Lösung betrachten
Ressourcen nicht verbindlich bereitstellen
Verantwortlichkeit unklar lassen
zu großen Umfang für eine einzelne Iteration wählen
Kommunikation und Organizational Change Management vergessen
keine Messung einplanen
Abhängigkeiten und Lieferanten nicht berücksichtigen
Verbesserung nebenbei ohne realistische Kapazität erwarten

5. Take action

Zentrale Aufgabe

Die geplanten Maßnahmen kontrolliert und möglichst iterativ umsetzen.

Eine Verbesserung entsteht nicht durch:

Analyse,
Besprechung,
Dokumentation,
oder Aufnahme in ein Register

allein.

Die Maßnahme muss umgesetzt und ihre Wirkung beobachtet werden.

ITIL Version 5 betont bei diesem Schritt ein iteratives Vorgehen mit Möglichkeiten:

Fortschritt zu prüfen,
den Ansatz neu zu bewerten,
und notwendige Anpassungen vorzunehmen.

Iterative Umsetzung

Eine mögliche Vorgehensweise ist:

kleinen sinnvollen Umfang auswählen
Erfolgskriterien festlegen
Maßnahme umsetzen
Ergebnis beobachten
Feedback erfassen
Probleme und Nebenwirkungen untersuchen
Vorgehensweise anpassen
nächste Iteration durchführen

Beispiel: Verbesserung des Monitoring

Iteration 1

einen kritischen Service auswählen
wichtigste Komponenten erfassen
wenige relevante Alarme konfigurieren
Reaktionsweg testen

Auswertung

Werden relevante Störungen erkannt?
Entstehen Fehlalarme?
Erhalten die richtigen Personen die Meldung?
Reichen die Informationen für eine Entscheidung?

Iteration 2

Schwellenwerte verbessern
redundante Events reduzieren
weitere Komponenten einbeziehen
Dokumentation und Eskalation anpassen

Organizational Change Management

Viele Verbesserungen verändern nicht nur Technik.

Sie verändern möglicherweise:

Rollen,
Verantwortlichkeiten,
Gewohnheiten,
Kommunikation,
Arbeitsabläufe,
Werkzeuge,
und Erwartungen.

Deshalb kann Organizational Change Management notwendig sein.

Zu berücksichtigen sind:

verständlicher Zweck,
betroffene Personengruppen,
Kommunikation,
Beteiligung,
Schulung,
Widerstände,
Fähigkeiten,
Unterstützung,
und tatsächliche Anwendung der neuen Arbeitsweise.

Typischer Fehler

Eine neue Arbeitsweise wird technisch bereitgestellt, aber von den Beteiligten nicht verstanden oder verwendet.

Leitfragen zu Take action

Ist der nächste Schritt eindeutig?
Sind Verantwortlichkeiten bekannt?
Sind Ressourcen verfügbar?
Sind Risiken und Rückfallmöglichkeiten berücksichtigt?
Sind Beteiligte informiert?
Ist notwendige Schulung erfolgt?
Kann schrittweise vorgegangen werden?
Wie wird Feedback während der Umsetzung erhoben?
Wie wird der Fortschritt sichtbar gemacht?
Wer entscheidet bei Abweichungen?
Wie werden Erkenntnisse dokumentiert?
Welche Änderungen am Plan sind notwendig?

Typische Fehler bei der Umsetzung

Verbesserung dauerhaft verschieben
zu viele Maßnahmen gleichzeitig beginnen
niemanden eindeutig verantwortlich machen
Beteiligte nicht informieren
Probleme erst am Ende auswerten
am ursprünglichen Plan festhalten, obwohl neue Erkenntnisse vorliegen
nur den technischen Rollout betrachten
keine Zeit für Stabilisierung und Nacharbeit einplanen

6. Are we getting there?

Zentrale Frage

Führt die Initiative tatsächlich zum gewünschten Zielzustand?

In diesem Schritt wird der neue aktuelle Zustand mit folgenden Bezugspunkten verglichen:

der ursprünglichen Baseline,
dem gewünschten Zielzustand,
den Erfolgskriterien,
und der Vision.

Es wird nicht nur geprüft, ob Maßnahmen ausgeführt wurden.

Es wird geprüft, ob sie die erwartete Wirkung erzeugen.

Aktivität und Wirkung unterscheiden

Aktivität	Wirkung
neues Monitoring installiert	relevante Störungen werden früher erkannt
Schulung durchgeführt	Mitarbeiter wenden die neue Arbeitsweise korrekt an
Wissensartikel veröffentlicht	Lösungen werden schneller gefunden und erfolgreich verwendet
Pflichtfeld ergänzt	Tickets enthalten vollständigere Informationen
Backup-System aktualisiert	Wiederherstellungen funktionieren innerhalb der benötigten Ziele
Automatisierung eingerichtet	Durchlaufzeit und Fehlerquote sinken

Merke

Eine umgesetzte Maßnahme beweist noch keine erfolgreiche Verbesserung.

Ergebnisse vergleichen

Beispiel:

Baseline

40 Prozent der Tickets benötigen Rückfragen.
durchschnittliche Bearbeitungsverzögerung: acht Stunden.

Zielzustand

höchstens 15 Prozent benötigen Rückfragen.
durchschnittliche Verzögerung unter zwei Stunden.

Nach der ersten Iteration

25 Prozent benötigen Rückfragen.
durchschnittliche Verzögerung: vier Stunden.

Bewertung:

Die gewünschte Richtung ist erkennbar.
Der Zielzustand ist noch nicht erreicht.
Weitere Untersuchung und Maßnahmen sind notwendig.

Quantitative und qualitative Informationen

Quantitative Informationen:

Zeit,
Anzahl,
Quote,
Kosten,
Ausfallhäufigkeit,
Fehlerquote,
Kapazität,
oder Zielerreichung.

Qualitative Informationen:

Benutzerfeedback,
Mitarbeitererfahrung,
Verständlichkeit,
Vertrauen,
wahrgenommene Einfachheit,
Qualität der Zusammenarbeit,
und beobachtete Hindernisse.

Beide Informationsarten können notwendig sein.

Beispiel:

Die Bearbeitungszeit sinkt.

Mitarbeiter berichten jedoch, dass sie zur Zielerreichung notwendige Dokumentation überspringen.

Die Verbesserung kann dadurch neue Risiken erzeugen.

Leitfragen zu Are we getting there?

Wurden die geplanten Maßnahmen umgesetzt?
Hat sich der aktuelle Zustand verändert?
Wie verhält er sich zur Baseline?
Werden die gewünschten Outcomes erreicht?
Welche Zielwerte wurden erreicht?
Welche Zielwerte wurden nicht erreicht?
Hat sich die Stakeholder-Erfahrung verändert?
Sind neue Risiken oder Nebenwirkungen entstanden?
Wurde ein Engpass nur verlagert?
Sind Daten ausreichend zuverlässig?
Muss die Initiative angepasst werden?
Sind zusätzliche Maßnahmen notwendig?
Sollte die Initiative beendet oder neu ausgerichtet werden?

Wenn eine Verbesserung nicht wirkt

Mögliche Ursachen:

Problem wurde falsch verstanden.
Baseline war unzuverlässig.
Maßnahme behandelte nur ein Symptom.
Ziel war unrealistisch.
Umsetzung war unvollständig.
Beteiligte verwenden die neue Arbeitsweise nicht.
benötigte Ressourcen fehlen.
technische oder organisatorische Abhängigkeiten wurden übersehen.
externe Bedingungen haben sich verändert.
Messgrößen bilden den tatsächlichen Wert nicht ab.

Eine nicht erfolgreiche Initiative sollte nicht automatisch verborgen werden.

Sie kann wichtige Erkenntnisse liefern.

Grundsatz

Ein kontrolliertes Experiment ohne erwarteten Erfolg kann wertvoll sein, wenn die Erkenntnisse dokumentiert und verwendet werden.

7. How do we keep the improvements relevant?

Zentrale Frage

Wie werden die Ergebnisse verankert und unter veränderten Bedingungen weiterhin relevant gehalten?

Eine Verbesserung kann kurzfristig erfolgreich sein und später wieder verloren gehen.

Mögliche Ursachen:

Mitarbeiter kehren zur alten Arbeitsweise zurück.
Dokumentationen werden nicht aktualisiert.
Verantwortlichkeiten wechseln.
neue Mitarbeiter werden nicht geschult.
Werkzeuge werden anders konfiguriert.
Messung endet unmittelbar nach der Einführung.
andere Veränderungen widersprechen der Verbesserung.
Anforderungen und Risiken verändern sich erneut.

ITIL Version 5 betont deshalb nicht nur das Aufrechterhalten von Dynamik, sondern die fortlaufende Relevanz der Verbesserung.

Verbesserung verankern

Mögliche Maßnahmen:

Verantwortung dauerhaft festlegen
Arbeitsanweisungen aktualisieren
Knowledge-Artikel anpassen
Schulung und Einarbeitung ergänzen
Werkzeuge und Automatisierung aktualisieren
Messgrößen dauerhaft beobachten
Governance-Kontrollen anpassen
Service- und Produktdokumentation aktualisieren
Rollen und Eskalationswege klären
Lieferantenvereinbarungen anpassen
Erkenntnisse in weitere Initiativen übertragen
und regelmäßige Überprüfungstermine festlegen

Knowledge Management

Erkenntnisse sollten so dokumentiert werden, dass andere Beteiligte sie nutzen können.

Dazu können gehören:

Ursachen,
Entscheidungen,
verworfene Optionen,
Testergebnisse,
Messwerte,
bekannte Einschränkungen,
neue Arbeitsweisen,
und gewonnene Erfahrungen.

Praxistipp

Dokumentiere nicht nur, was erfolgreich war.

Dokumentiere auch, welche Ansätze nicht funktioniert haben und warum.

Relevanz regelmäßig überprüfen

Eine Verbesserung kann später angepasst oder aufgehoben werden müssen.

Beispiel:

Eine zusätzliche Genehmigungsstufe wurde nach einem Sicherheitsvorfall eingeführt.

Später wird eine technische Kontrolle implementiert, die das Risiko automatisch behandelt.

Dann sollte geprüft werden:

Ist die manuelle Genehmigung weiterhin notwendig?
Kann sie vereinfacht werden?
Behandelt sie noch ein relevantes Restrisiko?
Erzeugt sie inzwischen unnötige Wartezeit?

Merke

Eine Verbesserung ist nicht dauerhaft richtig, nur weil sie zum Zeitpunkt ihrer Einführung sinnvoll war.

Leitfragen zu How do we keep the improvements relevant?

Wie wird die neue Arbeitsweise dauerhaft verankert?
Wer trägt langfristig Verantwortung?
Welche Dokumentationen müssen aktualisiert werden?
Welche Fähigkeiten und Schulungen werden benötigt?
Welche Messgrößen werden weiter beobachtet?
Wie wird eine Rückkehr zum alten Zustand erkannt?
Welche Governance-Vorgaben müssen angepasst werden?
Welche Erkenntnisse sollen geteilt werden?
Wann wird die Relevanz erneut geprüft?
Welche Veränderungen könnten die Verbesserung beeinflussen?
Welche weiteren Verbesserungsmöglichkeiten entstehen?
Was wurde aus Fehlern oder Abweichungen gelernt?

Typische Fehler bei der Verankerung

Initiative direkt nach dem technischen Rollout schließen
Messung sofort beenden
Dokumentation nicht aktualisieren
keine dauerhafte Verantwortung festlegen
neue Mitarbeiter nicht berücksichtigen
Lessons Learned erfassen, aber nicht verwenden
Erfolg nicht kommunizieren
Verbesserung unverändert fortführen, obwohl sie nicht mehr relevant ist

Continual Improvement Register

Ein Continual Improvement Register ist ein mögliches Hilfsmittel zur Erfassung und Steuerung von Verbesserungen.

Es kann enthalten:

Feld	Inhalt
ID	eindeutige Kennung
Titel	kurze Beschreibung
Auslöser	Problem, Feedback, Risiko oder Chance
betroffenes Produkt oder Service	fachlicher Bezug
gewünschtes Outcome	erwartetes Ergebnis
Ausgangszustand	bekannte Baseline
Vorschlag	mögliche Maßnahme
Nutzen	erwarteter Wertbeitrag
Risiko	mögliche negative Auswirkungen
Aufwand	erwarteter Ressourceneinsatz
Priorität	Reihenfolge der Bearbeitung
Verantwortlich	Improvement Owner
Status	neu, bewertet, geplant, aktiv, blockiert, abgeschlossen oder verworfen
Messgrößen	Kriterien zur Erfolgskontrolle
Erkenntnisse	Ergebnisse und Lessons Learned

Das Register kann umgesetzt werden als:

Tabelle,
Ticketsystem,
Kanban-Board,
Datenbank,
Projektwerkzeug,
oder spezialisiertes Improvement-Backlog.

Wichtig

ITIL schreibt kein bestimmtes Werkzeug und kein universelles Registerformat vor.

Möglicher Status einer Verbesserung

Status	Bedeutung
Neu	Idee oder Problem wurde erfasst
Zu prüfen	weitere Informationen werden benötigt
Bewertet	Nutzen, Risiko und Aufwand wurden untersucht
Priorisiert	Reihenfolge wurde festgelegt
Geplant	Maßnahmen und Ressourcen sind vorgesehen
Aktiv	Umsetzung läuft
Blockiert	Abhängigkeit oder Hindernis verhindert Fortschritt
In Auswertung	Wirkung wird gemessen
Abgeschlossen	Zielzustand wurde ausreichend erreicht und verankert
Zurückgestellt	derzeit keine ausreichende Priorität oder Ressource
Verworfen	Initiative wird begründet nicht weitergeführt

Verbesserungen priorisieren

Nicht jede gute Idee kann sofort umgesetzt werden.

Mögliche Bewertungskriterien:

erwarteter Wert
Beitrag zu strategischen Zielen
Auswirkung auf Benutzer
Sicherheitsrisiko
regulatorische Notwendigkeit
Dringlichkeit
Kosten
Aufwand
verfügbare Fähigkeiten
Abhängigkeiten
technische Schulden
Lieferantenrisiko
Umsetzbarkeit
und Zeit bis zum erwarteten Nutzen

Eine einfache Priorisierung kann beispielsweise betrachten:

Kriterium	Frage
Wirkung	Wie stark verbessert sich das Outcome?
Dringlichkeit	Welche Folgen besitzt eine Verzögerung?
Risiko	Welches Risiko wird reduziert oder neu erzeugt?
Aufwand	Welche Ressourcen werden benötigt?
Abhängigkeit	Was muss vorher geschehen?
Sicherheit	Besteht unmittelbarer Handlungsbedarf?
Machbarkeit	Kann die Initiative erfolgreich umgesetzt werden?

Typischer Fehler

Die lauteste Forderung oder die technisch interessanteste Idee erhält automatisch die höchste Priorität.

Quick Wins

Ein Quick Win ist eine Verbesserung, die:

mit relativ geringem Aufwand,
in kurzer Zeit,
einen erkennbaren Nutzen

erzeugen kann.

Beispiele:

veralteten Wissensartikel korrigieren
eindeutigen Ticketkontakt ergänzen
unnötige Monitoring-Meldung deaktivieren
fehlenden Lieferantenkontakt dokumentieren
häufige Diagnoseabfrage automatisieren

Quick Wins können sinnvoll sein, um:

unmittelbaren Nutzen zu erzeugen,
Akzeptanz aufzubauen,
und Erfahrungen zu sammeln.

Sie dürfen jedoch nicht dauerhaft wichtigere strukturelle Verbesserungen verdrängen.

Merke

Schnell umsetzbar bedeutet nicht automatisch besonders wertvoll.

Hoher Wert bedeutet nicht automatisch schnell umsetzbar.

Verbesserung und Problem Management unterscheiden

Continual Improvement	Problem Management
verbessert Produkte, Services, Practices und Arbeitsweisen	reduziert Wahrscheinlichkeit und Auswirkungen von Incidents
kann durch Chancen oder Feedback ausgelöst werden	wird häufig durch Incidents, Muster oder Risiken ausgelöst
betrachtet unterschiedliche Verbesserungsgegenstände	konzentriert sich auf Ursachen und mögliche Ursachen von Incidents
verwendet Verbesserungsinitiativen	verwendet Problems, Known Errors und Workarounds

Beide Practices können zusammenwirken.

Beispiel:

Problem Management erkennt, dass Zertifikate nicht zentral verwaltet werden.

Continual Improvement kann anschließend koordinieren:

zentrale Erfassung,
Verantwortlichkeiten,
Monitoring,
Dokumentation,
und regelmäßige Wirksamkeitsprüfung.

Verbesserung und Incident Management unterscheiden

Incident Management	Continual Improvement
begrenzt aktuelle negative Serviceauswirkungen	verbessert zukünftige Produkte, Services oder Arbeitsweisen
priorisiert Wiederherstellung	priorisiert nachhaltige Veränderung
arbeitet häufig unter Zeitdruck	kann strukturiert und iterativ umgesetzt werden
kann eine Zwischenlösung verwenden	bewertet, wie Ursachen und Arbeitsweisen verbessert werden

Beispiel:

Ein Dienst wird neu gestartet und funktioniert wieder.

Incident Management koordiniert die Wiederherstellung.
Problem Management untersucht möglicherweise die Ursache.
Continual Improvement verbessert möglicherweise Monitoring, Dokumentation und Wiederherstellungsverfahren.

Verbesserung und Change Enablement unterscheiden

Continual Improvement	Change Enablement
bestimmt und steuert Verbesserungsbedarf	unterstützt erfolgreiche Änderungen
richtet Maßnahmen an Outcomes und Wert aus	bewertet unter anderem Nutzen, Risiko und Autorisierung konkreter Changes
kann mehrere Changes enthalten	behandelt eine konkrete Änderung oder ein Change-Modell

Eine Verbesserungsinitiative kann mehrere Changes benötigen.

Beispiel:

Verbesserungsinitiative:

Zertifikatsmanagement zuverlässiger gestalten.

Mögliche Changes:

Monitoring-Plattform konfigurieren
zentrale Datenbank einführen
neue Verantwortlichkeiten technisch abbilden
automatische Erneuerung aktivieren
Alarmierungswege anpassen

Verbesserung und Transformation unterscheiden

Continual Improvement und Transformation überschneiden sich, besitzen aber unterschiedliche typische Anwendungsbereiche.

Continual Improvement	Transformation
kann lokal oder schrittweise angewendet werden	betrifft häufig umfangreiche organisatorische Veränderungen
eignet sich für konkrete Produkte, Services und Practices	kann das gesamte Value System oder große Organisationsbereiche verändern
kann mit begrenztem Umfang und kurzer Laufzeit erfolgen	umfasst häufig viele Stakeholder, Abhängigkeiten und längere Zeiträume
verwendet das Continual Improvement Model	ITIL Version 5 besitzt zusätzlich ein eigenes Transformation Model

Eine Transformation benötigt ebenfalls:

Lernen,
Messung,
Feedback,
Anpassung,
und fortlaufende Verbesserung.

Wichtig

Nicht jede Verbesserung ist eine Transformation.

Eine Transformation ohne Continual Improvement kann ihre Wirkung jedoch später wieder verlieren.

Verbesserung und Maturity Assessment unterscheiden

Ein Maturity Assessment bewertet Fähigkeiten oder Reife im Vergleich zu einem festgelegten Modell.

Es kann Informationen liefern für:

Where are we now?
Where do we want to be?
Are we getting there?

Das Assessment selbst verbessert jedoch noch nichts.

Es liefert Erkenntnisse, auf deren Grundlage Verbesserungen geplant werden können.

Typischer Fehler

Ein höherer Reifegrad wird als Selbstzweck verfolgt, ohne zu prüfen, ob dadurch relevante Outcomes verbessert werden.

Continual Improvement im Product and Service Lifecycle

Continual Improvement wirkt auf alle acht Lifecycle-Aktivitäten.

Lifecycle-Aktivität	Beispielhafte Verbesserung
Discover	Bedürfnisse und Feedback systematischer erfassen
Design	Sicherheit, Betrieb und Erfahrung früher einbeziehen
Acquire	Lieferanten- und Exit-Risiken besser bewerten
Build	Tests und Konfiguration stärker automatisieren
Transition	Pilotierung, Kommunikation und Rückfallplanung verbessern
Operate	technische Schulden reduzieren und Überwachung optimieren
Deliver	Serviceangebote und Stakeholder-Outcomes verbessern
Support	Wissen, Kommunikation und Wiederherstellung beschleunigen

Erkenntnisse aus einer späteren Aktivität können Verbesserungen in früheren Aktivitäten auslösen.

Beispiel:

Support erkennt wiederkehrende Bedienprobleme.

Daraus können Verbesserungen entstehen in:

Discover,
Design,
Build,
Transition,
Deliver,
und Knowledge Management.

Die sieben Guiding Principles bei Verbesserungen

Guiding Principle	Anwendung bei Continual Improvement
Focus on value	Verbesserung am benötigten Outcome ausrichten
Start where you are	Baseline und funktionierende Bestandteile berücksichtigen
Progress iteratively with feedback	kontrollierte Schritte und regelmäßige Auswertung verwenden
Collaborate and promote visibility	Stakeholder beteiligen und Fortschritt sichtbar machen
Think and work holistically	alle vier Dimensionen und Abhängigkeiten betrachten
Keep it simple and practical	angemessenen Umfang und verständliche Maßnahmen wählen
Optimize and automate	Arbeitsweise zuerst verbessern und danach sinnvoll automatisieren

Die vier Dimensionen bei Verbesserungen

Organizations and People

Welche Rollen und Fähigkeiten sind betroffen?
Welche Verhaltensänderung wird benötigt?
Bestehen ausreichende Zeit und Kapazität?
Wie wird die neue Arbeitsweise angenommen?

Information and Technology

Welche Daten belegen den Ausgangszustand?
Welche Technologie unterstützt die Verbesserung?
Sind Messung und Automatisierung zuverlässig?
Welche technischen Schulden bestehen?

Partners and Suppliers

Welche externen Anbieter sind betroffen?
Müssen Verträge oder Leistungen angepasst werden?
Welche Abhängigkeiten können die Verbesserung blockieren?
Welche Unterstützung wird benötigt?

Value Streams and Processes

Welcher Arbeitsfluss wird verbessert?
Wo entstehen Wartezeit und Nacharbeit?
Welche Kontrollen und Übergaben sind betroffen?
Wie wird das Outcome gemessen?

Praxisbeispiel: Zertifikate laufen wiederholt ab

Ausgangssituation

Mehrere Services waren innerhalb eines Jahres durch abgelaufene Zertifikate beeinträchtigt.

1. What is the vision?

Zertifikate kritischer Services sollen rechtzeitig erneuert werden, damit vermeidbare Ausfälle verhindert werden.

2. Where are we now?

Zertifikate werden in verschiedenen Tabellen geführt.
Verantwortlichkeiten sind nicht eindeutig.
Warnungen erfolgen teilweise manuell.
zwölf Zertifikate sind nicht zentral erfasst.
im letzten Jahr entstanden drei Incidents.

3. Where do we want to be?

alle kritischen Zertifikate sind zentral erfasst
verantwortliche Rollen sind zugeordnet
automatische Warnungen erfolgen 60, 30 und 14 Tage vor Ablauf
Erneuerungsverfahren sind dokumentiert
kein vermeidbarer Incident durch unbemerktes Ablaufdatum

4. How do we get there?

vollständigen Bestand erfassen
Verantwortlichkeiten klären
zentrale Datenquelle festlegen
Monitoring konfigurieren
Eskalationsregeln definieren
Erneuerungsverfahren dokumentieren
Pilot mit einem Service durchführen

5. Take action

Pilotservice auswählen
Zertifikat erfassen
Alarmierung testen
Erneuerung simulieren
Verantwortliche schulen
weitere Services iterativ aufnehmen

6. Are we getting there?

Sind alle kritischen Zertifikate erfasst?
Funktionieren Warnungen?
Reagieren die Verantwortlichen?
Wurde die Erneuerung rechtzeitig durchgeführt?
Sind neue Incidents entstanden?

7. How do we keep the improvements relevant?

Erfassung neuer Zertifikate in den Build- und Transition-Ablauf integrieren
Verantwortlichkeiten regelmäßig prüfen
Monitoring überwachen
Wissensartikel pflegen
nach Änderungen und Lieferantenwechseln Bestand kontrollieren
jährliche Wirksamkeitsprüfung durchführen

Praxisbeispiel: Onboarding dauert zu lange

Vision

Neue Mitarbeiter sollen am ersten Arbeitstag sicher und vollständig arbeiten können.

Ausgangszustand

durchschnittliche Durchlaufzeit: zwölf Arbeitstage
viele unvollständige Eintrittsmeldungen
Hardwarebestand ist nicht transparent
mehrere manuelle Freigaben
kein Ende-zu-Ende-Verantwortlicher

Zielzustand

95 Prozent rechtzeitig gemeldeter Eintritte sind am ersten Tag vollständig arbeitsfähig
klare Vorlaufzeit
vollständiges digitales Formular
definierte Standardpakete
sichtbarer Status
geregelte Vertretung

Mögliche Maßnahmen

Value Stream Mapping durchführen
Eintrittsformular verbessern
Rollenpakete definieren
Gerätebestand erfassen
Freigaben vereinfachen
Kontoanlage teilweise automatisieren
Arbeitsfähigkeit bestätigen lassen

Messung

Durchlaufzeit
Anteil vollständiger Meldungen
Anteil arbeitsfähiger Mitarbeiter am ersten Tag
Anzahl Rückfragen
Benutzer- und Führungskräftefeedback

Praxisbeispiel: Zu viele Monitoring-Alarme

Vision

Administratoren sollen relevante Zustandsänderungen rechtzeitig erkennen, ohne durch unnötige Meldungen überlastet zu werden.

Ausgangszustand

täglich mehrere hundert Meldungen
viele Duplikate
unklare Verantwortlichkeit
kritische Meldungen gehen in der Menge unter
Alarmregeln werden selten überprüft

Zielzustand

relevante Alarme besitzen eindeutige Zuständigkeit
Duplikate werden reduziert
kritische Events werden priorisiert
Alarmregeln werden nach Incidents überprüft
Reaktionszeiten werden messbar

Mögliche Maßnahmen

Alarmbestand analysieren
technische und handlungsrelevante Events unterscheiden
redundante Meldungen korrelieren
Verantwortlichkeiten zuordnen
Schwellenwerte testen
automatische Eskalation konfigurieren
monatliche Qualitätsprüfung etablieren

Praxisbeispiel: Knowledge-Base wird kaum genutzt

Vision

Mitarbeiter und Benutzer sollen verlässliches Wissen schnell finden und erfolgreich anwenden können.

Ausgangszustand

viele veraltete Artikel
uneinheitliche Titel
schlechte Suchbegriffe
keine Verantwortlichkeit
Erfolg wird nur anhand der Artikelanzahl gemessen

Zielzustand

häufig benötigte Inhalte sind aktuell
Suche liefert relevante Ergebnisse
Eigentümer und Prüfdatum sind bekannt
Nutzung und Lösungsbeitrag werden gemessen
veraltete Inhalte werden archiviert

Mögliche Maßnahmen

Suchdaten und häufige Tickets auswerten
wichtige Artikel priorisieren
Vorlagen vereinheitlichen
Verantwortliche festlegen
Versionsstände ergänzen
Feedback ermöglichen
regelmäßige Überprüfung einrichten

Continual Improvement bei einem Incident

Nach einem Incident können Verbesserungsmöglichkeiten entstehen bei:

Monitoring,
Eskalation,
Kommunikation,
Dokumentation,
Wiederherstellung,
Lieferantensteuerung,
Konfigurationsinformationen,
Sicherheitskontrollen,
und Benutzerinformation.

Nicht jeder Incident benötigt eine umfangreiche Verbesserungsinitiative.

Eine Initiative ist besonders sinnvoll, wenn:

ein Incident schwerwiegend war,
derselbe Fehler wiederholt auftritt,
die Wiederherstellung unnötig lange dauerte,
wichtige Informationen fehlten,
Risiken nicht erkannt wurden,
oder ähnliche Services ebenfalls gefährdet sind.

Lessons Learned und Post-Incident Review

Eine nachgelagerte Überprüfung kann untersuchen:

Was ist geschehen?
Welche Auswirkungen bestanden?
Was funktionierte gut?
Was erschwerte die Bearbeitung?
Welche Entscheidungen wurden getroffen?
Welche Informationen fehlten?
Welche Maßnahmen waren erfolgreich?
Welche Risiken bestehen weiterhin?
Welche Verbesserungen sind notwendig?
Wer übernimmt diese Verbesserungen?

Wichtig

Ein Lessons-Learned-Dokument allein erzeugt keine Verbesserung.

Erkenntnisse müssen in verantwortete und priorisierte Maßnahmen überführt werden.

Fehlerkultur

Continual Improvement benötigt eine Umgebung, in der:

Probleme offen angesprochen,
Risiken eskaliert,
Fehler untersucht,
und Erkenntnisse geteilt

werden können.

Eine Untersuchung sollte nicht vorschnell nach einer schuldigen Person suchen.

Zu prüfen sind ebenfalls:

unklare Anforderungen,
fehlende Informationen,
ungeeignete Werkzeuge,
widersprüchliche Ziele,
fehlende Fähigkeiten,
unrealistische Arbeitslast,
unzureichende Kontrollen,
und organisatorische Abhängigkeiten.

Grundsatz

Individuelles Fehlverhalten darf nicht ignoriert werden.

Eine ausschließliche Schuldzuweisung kann jedoch systemische Ursachen verdecken.

Messung und Reporting

Eine Verbesserung benötigt passende Informationen.

Messgrößen sollten beantworten:

Hat sich das Outcome verbessert?
Hat sich das Risiko verändert?
Hat sich die Stakeholder-Erfahrung verbessert?
Sind Kosten oder Aufwand gesunken?
Wurden unbeabsichtigte Nebenwirkungen erzeugt?
Bleibt die Verbesserung wirksam?

Mögliche Messgrößen:

Durchlaufzeit
Wiederherstellungszeit
Fehlerquote
Wiederholungsquote
Wartezeit
Anzahl Übergaben
Verfügbarkeit
Serviceerfahrung
Nutzung
Kosten
Sicherheitsvorfälle
Datenverlust
Nacharbeit
Einhaltung von Zielwerten

Kennzahlen gemeinsam betrachten

Einzelne Kennzahlen können irreführend sein.

Beispiel:

Die durchschnittliche Ticketbearbeitungszeit wurde um 30 Prozent reduziert.

Zusätzlich sollte geprüft werden:

Werden Tickets häufiger wieder geöffnet?
Werden Vorgänge schneller weitergereicht?
Müssen Benutzer erneut Kontakt aufnehmen?
Ist die Dokumentationsqualität gesunken?
Wurde das tatsächliche Outcome erreicht?

Typischer Fehler

Eine Kennzahl verbessert sich, während sich der gesamte Wertstrom oder die Benutzererfahrung verschlechtert.

Automatisierung bei Continual Improvement

Automatisierung kann Verbesserungen unterstützen durch:

automatische Datenerfassung
Berichte
Trendanalysen
Workflow-Steuerung
Erinnerungen
technische Tests
Überwachung von Zielwerten
und Erkennung wiederkehrender Muster

Automatisierung kann jedoch keine fehlende:

Vision,
Verantwortlichkeit,
Priorisierung,
Datenqualität,
oder fachliche Bewertung

ersetzen.

Grundsatz

Nicht die Verbesserungsidee automatisieren, sondern einen verstandenen und geeigneten Zielzustand.

Künstliche Intelligenz bei Continual Improvement

KI kann beispielsweise unterstützen bei:

Analyse großer Ticketmengen
Erkennung wiederkehrender Themen
Zusammenfassung von Feedback
Vorschlägen für mögliche Verbesserungen
Prognose von Kapazitätsproblemen
Erkennung von Anomalien
und Erstellung erster Berichte

Dabei müssen berücksichtigt werden:

Qualität der Eingangsdaten
Datenschutz
Informationssicherheit
Nachvollziehbarkeit
mögliche Verzerrungen
menschliche Kontrolle
und Ergebnisverantwortung

Beispiel:

Eine KI erkennt, dass viele Tickets den Begriff „Anmeldung“ enthalten.

Das beweist noch nicht:

dass dieselbe Ursache besteht,
dass alle Tickets falsch bearbeitet wurden,
oder welche Verbesserung notwendig ist.

Die Muster müssen fachlich untersucht und eingeordnet werden.

Typische Fehler bei Continual Improvement

Fehler 1: Verbesserung nur nach Störungen

Chancen, Feedback und technische Schulden werden nicht berücksichtigt.

Fehler 2: Keine klare Vision

Maßnahmen werden umgesetzt, ohne ihren Beitrag zu Outcomes und Wert zu verstehen.

Fehler 3: Keine Baseline

Später kann nicht festgestellt werden, ob sich der Zustand tatsächlich verbessert hat.

Fehler 4: Aktivität mit Wirkung verwechseln

Ein Werkzeug wurde eingeführt oder eine Schulung durchgeführt, aber das Outcome bleibt unverändert.

Fehler 5: Zu viele Initiativen beginnen

Ressourcen werden auf viele Vorhaben verteilt, während kaum eine Initiative abgeschlossen wird.

Fehler 6: Nur Quick Wins umsetzen

Größere strukturelle Risiken und Engpässe bleiben dauerhaft bestehen.

Fehler 7: Verbesserung als Zusatzarbeit behandeln

Es werden keine realistischen Ressourcen, Befugnisse oder Zeitfenster bereitgestellt.

Fehler 8: Mitarbeiter nicht einbeziehen

Die neue Arbeitsweise passt nicht zur tatsächlichen Situation oder wird nicht angenommen.

Fehler 9: Nach der Umsetzung nicht messen

Ob die Verbesserung wirkt oder neue Probleme erzeugt, bleibt unbekannt.

Fehler 10: Ergebnisse nicht verankern

Die Organisation kehrt nach kurzer Zeit zur bisherigen Arbeitsweise zurück.

Fehler 11: Lessons Learned nicht weiterverfolgen

Erkenntnisse werden dokumentiert, aber nicht priorisiert und umgesetzt.

Fehler 12: Kennzahlen isoliert optimieren

Lokale Zielwerte verbessern sich, während Wertstrom und Stakeholder-Erfahrung schlechter werden.

Fehler 13: Improvement Register als Ablage verwenden

Viele Ideen werden erfasst, aber nicht bewertet, priorisiert oder abgeschlossen.

Fehler 14: Verbesserung mit Transformation verwechseln

Eine kleine lokale Anpassung wird unnötig als umfangreiches Veränderungsprogramm organisiert.

Fehler 15: Frühere Verbesserung nie erneut prüfen

Eine einst sinnvolle Kontrolle oder Arbeitsweise bleibt bestehen, obwohl sie inzwischen unnötig oder ungeeignet ist.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker erkennen häufig Verbesserungsmöglichkeiten direkt im technischen Betrieb.

Beispiele:

wiederkehrende manuelle Tätigkeiten
fehlende Monitoring-Regeln
veraltete Dokumentationen
unnötige Ticketübergaben
wiederkehrende Fehlkonfigurationen
schlecht nachvollziehbare Abhängigkeiten
ungetestete Wiederherstellungsverfahren
uneinheitliche Serverkonfigurationen
fehlende Automatisierung
und dauerhaft eingesetzte Zwischenlösungen

Eine gute Verbesserungsidee sollte nicht nur lauten:

Das sollten wir automatisieren.

Sie sollte möglichst beantworten:

Welches Problem besteht?
Wie häufig tritt es auf?
Welche Auswirkungen besitzt es?
Welches Outcome soll verbessert werden?
Welche Daten belegen den Bedarf?
Welche Risiken bestehen?
Welche Maßnahme wird vorgeschlagen?
Wie wird der Erfolg gemessen?

Beispiel für einen Verbesserungsvorschlag

Unpräzise:

Wir brauchen besseres Monitoring.

Präziser:

Bei drei Incidents innerhalb der letzten sechs Monate wurde der Ausfall des internen DNS-Dienstes erst durch Benutzermeldungen erkannt. Vorgeschlagen wird eine aktive Funktionsprüfung der DNS-Auflösung mit Alarmierung des Bereitschaftsteams. Erfolgskriterium ist, dass ein Ausfall innerhalb von fünf Minuten erkannt und eindeutig dem DNS-Service zugeordnet wird.

30-Sekunden-Prüfung einer Verbesserung

Vision: Warum ist die Verbesserung wichtig?
Ist-Zustand: Welche Daten und Beobachtungen liegen vor?
Zielzustand: Was soll konkret besser werden?
Weg: Welche Maßnahme ist geeignet?
Aktion: Wer setzt den nächsten Schritt um?
Messung: Woran erkennen wir Fortschritt und Erfolg?
Verankerung: Wie bleibt die Verbesserung wirksam und relevant?

Checkliste für eine neue Verbesserungsidee

Checkliste für eine Verbesserungsinitiative

Checkliste während der Umsetzung

Checkliste zur Erfolgskontrolle

Checkliste zur Verankerung

Schnellreferenz des Continual Improvement Models

Schritt	Kurzfrage	Typisches Ergebnis
1	What is the vision?	Richtung, Zweck und Grenzen
2	Where are we now?	Ausgangszustand und Baseline
3	Where do we want to be?	Zielzustand und Erfolgskriterien
4	How do we get there?	Verbesserungsplan und nächste Schritte
5	Take action	umgesetzte Maßnahmen und Feedback
6	Are we getting there?	Wirkungsprüfung und Anpassungsentscheidung
7	How do we keep the improvements relevant?	verankerte und weiterhin überprüfte Verbesserung

Zusammenfassende Darstellung

What is the vision?
Richtung und Zweck klären
↓
Where are we now?
aktuellen Zustand und Baseline erfassen
↓
Where do we want to be?
Zielzustand und Erfolgskriterien bestimmen
↓
How do we get there?
geeigneten Verbesserungsweg planen
↓
Take action
Maßnahmen iterativ umsetzen
↓
Are we getting there?
Fortschritt, Wirkung und Nebenwirkungen prüfen
↓
How do we keep the improvements relevant?
Ergebnisse verankern und regelmäßig neu bewerten
↓
neue Erkenntnisse und weitere Verbesserungsmöglichkeiten
↓
erneute Anwendung des Modells

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.10 ITIL an den eigenen Kontext anpassen
Incident Management
Problem Management
Change Enablement
Knowledge Management
Measurement and Reporting
Organizational Change Management

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende offizielle Community-Quelle

PeopleCert Community: Continual Improvement, Maturity or Transformation?

Offiziell bestätigter Stand

Die aktuellen offiziellen ITIL-Version-5-Informationen bestätigen:

Continual Improvement ist weiterhin Bestandteil des ITIL Value Systems.
Continual Improvement ist über das gesamte Framework und den Product and Service Lifecycle hinweg relevant.
ITIL Foundation Version 5 behandelt ein verfeinertes Continual Improvement Model.
Das Modell besitzt weiterhin sieben Schritte.
Einzelne Schrittbezeichnungen wurden gegenüber ITIL 4 präzisiert.
Die aktuellen sieben Schritte lauten:
1. What is the vision?
2. Where are we now?
3. Where do we want to be?
4. How do we get there?
5. Take action
6. Are we getting there?
7. How do we keep the improvements relevant?
Das Modell kann auf Verbesserungen von Produkten, Services, Practices und anderen Bestandteilen des Value Systems angewendet werden.
Die Schritte werden iterativ verwendet und können auf Grundlage neuer Erkenntnisse erneut durchlaufen werden.

Einordnung

Die ausführlichen:

Leitfragen,
Tabellen,
Checklisten,
Registerfelder,
Priorisierungskriterien,
Praxisbeispiele,
und Umsetzungshinweise

sind zusätzliche herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebene Verbesserungsmethode dar.

Rollen, Messgrößen, Werkzeuge, Priorisierungsverfahren und Dokumentationsumfang müssen an Ziel, Risiko, Größe und Arbeitsweise der jeweiligen Organisation angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

2.10 ITIL an den eigenen Kontext anpassen

Kurz erklärt

ITIL ist kein fertiger Musterprozess, der unverändert in jede Organisation übernommen werden kann.

Das Framework stellt:

Begriffe,

Prinzipien,

Modelle,

Management Practices,

Betrachtungsperspektiven,

und bewährte Orientierung

bereit.

Die konkrete Organisation muss daraus eine Arbeitsweise gestalten, die zu ihren:

Zielen,

Produkten und Services,

Risiken,

gesetzlichen Anforderungen,

Fähigkeiten,

Technologien,

Lieferanten,

und tatsächlichen Wertströmen

passt.

ITIL soll deshalb übernommen und angepasst werden.

Eine sinnvolle Anpassung bewahrt Zweck und Nutzen der Guidance, ohne unnötige Komplexität zu erzeugen.

Warum ITIL angepasst werden muss

Organisationen unterscheiden sich erheblich.

Beispiele:

Ein kleines Unternehmen betreut 40 Benutzer mit einem dreiköpfigen IT-Team.
Ein internationaler Konzern betreibt geschäftskritische Services an vielen Standorten.
Ein Krankenhaus benötigt besonders hohe Verfügbarkeit und nachvollziehbare Sicherheitskontrollen.
Eine öffentliche Verwaltung muss umfangreiche rechtliche und organisatorische Vorgaben berücksichtigen.
Ein Cloud-Anbieter entwickelt und betreibt digitale Produkte in kurzen Releasezyklen.
Ein Managed Service Provider unterstützt mehrere Kunden mit unterschiedlichen Verträgen.
Ein Softwareunternehmen arbeitet mit agilen Produktteams und automatisierten Deployments.

Für alle diese Organisationen können ITIL-Konzepte hilfreich sein.

Sie benötigen jedoch nicht:

dieselben Rollen,
dieselben Prozesse,
dieselben Werkzeuge,
dieselben Genehmigungsstufen,
denselben Dokumentationsumfang,
oder dieselben Kennzahlen.

Merke

Gleiche ITIL-Grundgedanken können in unterschiedlichen Organisationen zu unterschiedlichen praktischen Umsetzungen führen.

Anpassen bedeutet nicht beliebig auswählen

ITIL an den Kontext anzupassen bedeutet nicht:

nur angenehme Bestandteile zu verwenden,
notwendige Kontrollen zu entfernen,
Begriffe ohne Verständnis umzubenennen,
jede bestehende Arbeitsweise nachträglich als ITIL zu bezeichnen,
oder Risiken mit dem Hinweis auf Flexibilität zu ignorieren.

Eine Anpassung sollte nachvollziehbar beantworten:

Welches Problem soll gelöst werden?
Welches Outcome wird benötigt?
Welchen Zweck erfüllt die betreffende Practice?
Welche Risiken und Vorgaben bestehen?
Welche Bestandteile werden benötigt?
Welche Bestandteile wären unnötig?
Wie wird die Wirksamkeit überprüft?
Wie wird die Arbeitsweise später verbessert?

Grundsatz

Anpassung verändert die konkrete Umsetzung.

Sie darf nicht dazu führen, dass der eigentliche Zweck einer Practice, Kontrolle oder Verantwortung verloren geht.

ITIL wird nicht installiert

Ein ITSM-Werkzeug kann installiert werden.

Ein Framework kann dagegen nicht wie eine Software vollständig „installiert“ werden.

ITIL stellt einen Orientierungsrahmen bereit.

Die Organisation muss selbst gestalten:

welche Produkte und Services sie verwaltet,
welche Outcomes sie erreichen will,
welche Wertströme benötigt werden,
welche Practices diese Wertströme unterstützen,
welche Rollen und Verantwortlichkeiten gelten,
welche Informationen benötigt werden,
welche Werkzeuge eingesetzt werden,
wie Risiken behandelt werden,
und wie Verbesserungen gesteuert werden.

Typischer Fehler

Eine Organisation kauft ein ITSM-Werkzeug mit vorkonfigurierten ITIL-Modulen und betrachtet die Einführung damit als abgeschlossen.

Das Werkzeug kann die Arbeitsweise unterstützen. Es ersetzt jedoch keine geklärten Ziele, Verantwortlichkeiten, Fähigkeiten und Wertströme.

Die wichtigsten Kontextfaktoren

Vor der Gestaltung einer ITIL-basierten Arbeitsweise sollten mindestens folgende Kontextfaktoren betrachtet werden:

Kontextfaktor	Beispielhafte Fragen
Ziele und Strategie	Welche geschäftlichen und organisatorischen Ergebnisse sollen unterstützt werden?
Produkte und Services	Welche Leistungen werden angeboten und wie kritisch sind sie?
Stakeholder	Wer nutzt, finanziert, unterstützt oder beeinflusst die Produkte und Services?
Größe und Struktur	Wie viele Benutzer, Teams, Standorte und Organisationseinheiten existieren?
Risiken	Welche Ausfälle, Sicherheitsvorfälle oder Fehlentscheidungen wären besonders schwerwiegend?
Gesetze und Verträge	Welche rechtlichen, regulatorischen und vertraglichen Verpflichtungen gelten?
Betriebsmodell	Wird intern, extern, hybrid, agil, produktorientiert oder projektorientiert gearbeitet?
Fähigkeiten	Welche Kenntnisse, Erfahrungen und Kapazitäten sind vorhanden?
Technologie	Welche Infrastruktur, Anwendungen, Cloud-Dienste und Automatisierungen werden eingesetzt?
Lieferanten	Welche Produkte und Services hängen von externen Anbietern ab?
Kultur	Wie werden Entscheidungen, Fehler, Zusammenarbeit und Verantwortung tatsächlich behandelt?
Reife und Ausgangslage	Welche Arbeitsweisen funktionieren bereits und wo bestehen erkennbare Schwächen?
Kosten und Ressourcen	Welcher Aufwand ist vertretbar und welche Ressourcen stehen zur Verfügung?
Veränderungsgeschwindigkeit	Wie häufig ändern sich Produkte, Anforderungen und Technologien?
Erfahrung der Stakeholder	Wie erleben Benutzer, Kunden und Mitarbeiter die vorhandenen Services?

Die Ziele der Organisation zuerst verstehen

Die Einführung einer Practice sollte nicht mit einem Prozessdiagramm beginnen.

Zuerst muss geklärt werden, welches Ergebnis verbessert werden soll.

Unzureichendes Ziel:

Wir möchten Incident Management einführen.

Besser:

Benutzer sollen nach ungeplanten Serviceunterbrechungen schneller wieder arbeitsfähig werden. Auswirkungen, Verantwortung und Kommunikation müssen dabei nachvollziehbar sein.

Unzureichendes Ziel:

Wir benötigen eine CMDB.

Besser:

Bei Incidents und Changes fehlen verlässliche Informationen über kritische Serviceabhängigkeiten. Dadurch dauern Analysen länger und Änderungen verursachen unerwartete Auswirkungen.

Unzureichendes Ziel:

Wir wollen ITIL-konform arbeiten.

Besser:

Wir wollen unsere wichtigsten Services nachvollziehbar steuern, Störungen verlässlich bearbeiten, Änderungen kontrollieren und wiederkehrende Fehler systematisch reduzieren.

Merke

ITIL ist ein Hilfsmittel zur Verbesserung von Produkten, Services und Outcomes.

Die Einführung von ITIL-Begriffen ist kein eigenständiges geschäftliches Outcome.

Nicht mit allen 34 Practices gleichzeitig beginnen

ITIL Version 5 enthält 34 Management Practices.

Eine Organisation muss nicht alle Practices gleichzeitig vollständig ausgestalten.

Eine sinnvollere Vorgehensweise ist:

wichtige Produkte und Services bestimmen
konkrete Probleme und Chancen erfassen
relevante Wertströme untersuchen
benötigte Practices identifizieren
vorhandene Fähigkeiten bewerten
wichtigste Lücken priorisieren
kleine wirksame Verbesserungen umsetzen
Ergebnisse messen
weitere Practices oder Fähigkeiten schrittweise entwickeln

Beispiel:

Eine Organisation besitzt folgende Probleme:

Störungen gehen verloren.
Benutzer kennen keinen eindeutigen Kontaktweg.
Prioritäten werden willkürlich vergeben.
Wiederkehrende Fehler werden nicht untersucht.
technische Änderungen werden nicht dokumentiert.

Zunächst besonders relevant können sein:

Service Desk
Incident Management
Problem Management
Change Enablement
Knowledge Management
Monitoring and Event Management
Continual Improvement

Andere Practices bleiben ebenfalls wichtig, müssen aber möglicherweise nicht mit derselben Priorität entwickelt werden.

Vom Problem zur benötigten Practice

Beobachtetes Problem	Möglicherweise relevante Practices
Benutzer wissen nicht, wohin sie sich wenden sollen.	Service Desk, Service Catalogue Management
Incidents werden uneinheitlich bearbeitet.	Incident Management, Knowledge Management
dieselben Störungen treten regelmäßig erneut auf	Problem Management, Continual Improvement
Changes verursachen unerwartete Ausfälle	Change Enablement, Service Configuration Management, Service Validation and Testing
technische Abhängigkeiten sind unbekannt	Service Configuration Management, Architecture Management
Hardware und Lizenzen sind nicht nachvollziehbar	IT Asset Management, Supplier Management
Monitoring erzeugt zu viele unbrauchbare Meldungen	Monitoring and Event Management, Continual Improvement
Lieferanten werden bei Incidents zu spät eingebunden	Supplier Management, Incident Management
Benutzer erhalten unverständliche Serviceinformationen	Service Catalogue Management, Relationship Management
Kapazitätsprobleme werden erst nach Ausfällen erkannt	Capacity and Performance Management, Monitoring and Event Management
Wiederherstellungen sind nicht ausreichend vorbereitet	Service Continuity Management, Availability Management
Wissen befindet sich nur bei einzelnen Personen	Knowledge Management, Workforce and Talent Management

Diese Zuordnung ist eine erste Orientierung.

Die tatsächliche Situation kann Beiträge mehrerer Practices und Kontextfaktoren erfordern.

Die sieben Guiding Principles zur Anpassung verwenden

Die Guiding Principles unterstützen die Entscheidung, wie ITIL angemessen übernommen wird.

Focus on value

Fragen:

Welches Outcome soll verbessert werden?
Wer nimmt den Wert wahr?
Welcher Nutzen entsteht durch die neue Arbeitsweise?
Ist der Aufwand angemessen?
Welche Risiken werden reduziert?

Beispiel:

Ein neues Pflichtfeld im Ticketsystem ist nur sinnvoll, wenn die Information tatsächlich:

eine bessere Entscheidung,
schnellere Bearbeitung,
geringeres Risiko,
oder bessere Auswertung

ermöglicht.

Start where you are

Fragen:

Was funktioniert bereits?
Welche Daten und Werkzeuge existieren?
Welche Mitarbeiter besitzen wertvolles Wissen?
Welche Arbeitsweisen sollten erhalten bleiben?
Was ist tatsächlich problematisch?

Eine Organisation sollte vorhandene Fähigkeiten nicht allein deshalb verwerfen, weil sie nicht mit offiziellen ITIL-Begriffen bezeichnet wurden.

Beispiel:

Ein kleines Team besitzt bereits:

einen funktionierenden gemeinsamen Supportkanal,
klare persönliche Zuständigkeiten,
gute technische Dokumentation,
und regelmäßige Verbesserungsbesprechungen.

Diese Bestandteile können weiterentwickelt werden, statt ein vollständig neues und komplexes Modell einzuführen.

Progress iteratively with feedback

Fragen:

Was ist der kleinste sinnvolle nächste Schritt?
Kann zunächst ein Pilot verwendet werden?
Welche Rückmeldungen werden benötigt?
Wie wird die Wirkung gemessen?
Welche Risiken können früh erkannt werden?

Beispiel:

Statt sofort sämtliche Serviceprozesse neu zu gestalten, kann zunächst der Incident-Wertstrom eines besonders wichtigen Service verbessert werden.

Collaborate and promote visibility

Fragen:

Wer ist betroffen?
Wer besitzt notwendiges Wissen?
Wer muss entscheiden?
Welche Informationen müssen sichtbar sein?
Wo entstehen Missverständnisse und Übergabeverluste?

Eine ITIL-Einführung, die ausschließlich innerhalb eines kleinen Prozess- oder Toolteams gestaltet wird, kann den tatsächlichen Arbeitsalltag verfehlen.

Think and work holistically

Fragen:

Welche vier Dimensionen sind betroffen?
Welche Produkte und Services hängen zusammen?
Welche Lieferanten sind beteiligt?
Welche Auswirkungen entstehen für Betrieb, Support und Benutzer?
Welche anderen Practices werden beeinflusst?

Beispiel:

Die Einführung eines Change-Prozesses beeinflusst möglicherweise:

Entwicklung,
Betrieb,
Informationssicherheit,
Service Desk,
Lieferanten,
Dokumentation,
Monitoring,
und Releaseplanung.

Keep it simple and practical

Fragen:

Welchen Zweck erfüllt jeder Schritt?
Welche Dokumentation ist tatsächlich notwendig?
Welche Genehmigungen reduzieren ein reales Risiko?
Welche Sonderfälle werden unnötig zum Standard?
Ist die Arbeitsweise für die Beteiligten verständlich?

Merke

Einfach bedeutet nicht unkontrolliert.

Einfach bedeutet zweckmäßig, verständlich und frei von unnötiger Komplexität.

Optimize and automate

Fragen:

Ist der Ablauf verstanden?
Welche Schritte erzeugen keinen Nutzen?
Welche Daten sind zuverlässig?
Welche Ausnahmen bestehen?
Welche Teile können anschließend sicher automatisiert werden?
Wie werden automatisierte Ergebnisse kontrolliert?

Ein ungeeigneter Ablauf sollte nicht unverändert automatisiert werden.

Alle vier Dimensionen berücksichtigen

Die Anpassung einer Practice muss alle vier Dimensionen einbeziehen.

Organizations and People

Zu klären sind beispielsweise:

Rollen
Verantwortung
Entscheidungsbefugnisse
Fähigkeiten
Kapazität
Kommunikation
Kultur
Schulung
Vertretung
und Akzeptanz

Beispiel:

Ein neuer Incident-Prozess kann fachlich gut beschrieben sein.

Er bleibt dennoch unwirksam, wenn:

Mitarbeiter ihn nicht kennen,
niemand koordinieren darf,
Supportkapazität fehlt,
oder Teams nicht miteinander kommunizieren.

Information and Technology

Zu klären sind beispielsweise:

benötigte Informationen
Datenqualität
Werkzeuge
Schnittstellen
Automatisierung
Monitoring
Sicherheit
Datenschutz
und technische Abhängigkeiten

Beispiel:

Eine Prioritätsmatrix funktioniert nur, wenn ausreichende Informationen über:

Auswirkungen,
Dringlichkeit,
betroffene Services,
und Benutzergruppen

vorliegen.

Partners and Suppliers

Zu klären sind beispielsweise:

Lieferantenleistungen
Supportwege
Verträge
Eskalation
Sicherheitsanforderungen
Datenverarbeitung
Abhängigkeiten
und Exit-Strategien

Beispiel:

Ein Incident-Prozess ist unvollständig, wenn ein kritischer Cloud-Provider beteiligt ist, aber:

keine Supportberechtigung,
keine Vertragsnummer,
kein Eskalationskontakt,
und keine interne Koordination

festgelegt wurden.

Value Streams and Processes

Zu klären sind beispielsweise:

Auslöser
benötigte Outcomes
Schritte
Übergaben
Entscheidungen
Kontrollen
Wartezeiten
Nacharbeit
Messgrößen
und Verbesserung

Die Anpassung sollte nicht nur einen isolierten Prozessschritt optimieren.

Sie sollte den gesamten Wertstrom berücksichtigen.

Practices an Wertströmen ausrichten

Practices besitzen einen bestimmten Zweck.

Wert entsteht jedoch durch das Zusammenwirken mehrerer Practices in konkreten Wertströmen.

Beispielwertstrom:

Benutzer nach einer Störung wieder arbeitsfähig machen

Möglicherweise beteiligt:

Service Desk
Incident Management
Monitoring and Event Management
Knowledge Management
Service Configuration Management
Supplier Management
Problem Management
Continual Improvement

Die Organisation sollte deshalb nicht nur fragen:

Wie sieht unser Incident-Management-Prozess aus?

Zusätzlich sollte sie fragen:

Wie meldet der Benutzer die Störung?
Welche Informationen werden benötigt?
Wie werden Auswirkungen erkannt?
Wie werden Abhängigkeiten ermittelt?
Wie werden Fachteams und Lieferanten eingebunden?
Wie wird der Benutzer informiert?
Wie wird die Wiederherstellung bestätigt?
Wie werden wiederkehrende Ursachen behandelt?
Wie werden Erkenntnisse verbessert?

Angemessene Rollen festlegen

ITIL nennt verschiedene mögliche Rollen.

Eine Organisation muss jedoch nicht für jede Rolle eine eigene Vollzeitstelle schaffen.

Kleine Organisation:

Eine Person kann mehrere Rollen übernehmen, beispielsweise:

Service-Desk-Mitarbeiter,
Incident-Koordinator,
Administrator,
und Knowledge-Verantwortlicher.

Große Organisation:

Diese Verantwortlichkeiten können auf mehrere spezialisierte Rollen verteilt werden.

Entscheidend ist nicht die Anzahl der Rollennamen.

Entscheidend ist, dass geklärt ist:

Wer entscheidet?
Wer führt aus?
Wer koordiniert?
Wer trägt Ergebnisverantwortung?
Wer muss beteiligt werden?
Wer wird informiert?
Wer eskaliert?
Wer verbessert die Arbeitsweise?

Wichtig

Eine Person kann mehrere Rollen besitzen.

Kritische Funktionstrennungen sowie gesetzliche und sicherheitsrelevante Anforderungen müssen trotzdem berücksichtigt werden.

Rollenbezeichnungen dürfen angepasst werden

Eine Organisation kann eigene Begriffe verwenden.

Beispiele:

ITIL-Begriff	Mögliche interne Bezeichnung
Service Desk	Helpdesk, IT-Support oder Benutzerbetreuung
Incident	Störung
Service Request	Standardanfrage oder Leistungsanforderung
Change Enablement	Change Management oder Änderungssteuerung
Service Owner	Serviceverantwortlicher
Supplier Management	Lieferantensteuerung
Continual Improvement	kontinuierliche Verbesserung oder Verbesserungsmanagement

Die interne Bezeichnung ist weniger wichtig als eine eindeutige Bedeutung.

Problematisch ist es, wenn derselbe Begriff in verschiedenen Teams unterschiedliche Bedeutungen besitzt.

Beispiel:

Das Wort „Problem“ kann im allgemeinen Sprachgebrauch jede Schwierigkeit bezeichnen.

Im ITIL-Kontext besitzt Problem Management einen bestimmten Zweck im Zusammenhang mit Ursachen oder möglichen Ursachen von Incidents.

Praxistipp

Erstelle ein kurzes internes Glossar für wichtige Begriffe.

Es muss verständlich erklären, wie die Organisation die Begriffe praktisch verwendet.

Dokumentationsumfang anpassen

Nicht jeder Vorgang benötigt dieselbe Dokumentation.

Der Umfang sollte sich richten nach:

Risiko,
Komplexität,
Wiederholbarkeit,
betroffenen Services,
gesetzlichen Vorgaben,
Sicherheitsanforderungen,
und notwendiger Nachvollziehbarkeit.

Beispiel:

Einfache Standardanfrage

Anforderer
gewünschte Leistung
Genehmigung, falls erforderlich
technische Durchführung
Ergebnis

Kritischer Change

Ziel
betroffene Produkte und Services
Auswirkungen
Risiken
technische Abhängigkeiten
Testnachweise
Autorisierung
Kommunikationsplan
Umsetzungsplan
Rückfall- oder Wiederherstellungsplan
Erfolgskriterien
Ergebnis und Nacharbeiten

Grundsatz

Dokumentation muss eine Entscheidung, Ausführung, Kontrolle oder spätere Nutzung unterstützen.

Daten ohne erkennbaren Zweck sollten nicht nur aus Gewohnheit erhoben werden.

Kontrollen nach Risiko gestalten

Nicht jeder Vorgang benötigt dieselbe Kontrolle.

Beispielhafte Einteilung:

Situation	Mögliche Behandlung
häufige, dokumentierte und risikoarme Standardtätigkeit	vorab autorisierter und möglichst automatisierter Ablauf
normale Änderung mit überschaubarem Risiko	angemessene Bewertung und Autorisierung
komplexe Änderung an kritischem Service	vertiefte Risiko-, Abhängigkeits- und Rückfallprüfung
dringende Sicherheitsmaßnahme	beschleunigtes Verfahren mit klarer Befugnis und nachgelagerter Kontrolle
strategische Veränderung	Entscheidung durch entsprechend befugte Governance-Rollen

Die konkreten Kategorien und Entscheidungsbefugnisse werden von der Organisation festgelegt.

Typischer Fehler

Jede kleine Änderung durchläuft dieselben umfangreichen Freigaben wie eine hochriskante Änderung.

Dadurch entstehen unnötige Wartezeiten, ohne dass kritische Änderungen automatisch besser bewertet werden.

Priorisierung anpassen

ITIL schreibt keine universelle Prioritätsmatrix vor.

Eine Organisation kann Auswirkungen und Dringlichkeit als wichtige Kriterien verwenden.

Sie muss jedoch selbst festlegen:

welche Prioritätsstufen existieren,
welche Auswirkungen als kritisch gelten,
welche Benutzer oder Geschäftsprozesse besonders wichtig sind,
welche Reaktions- und Wiederherstellungsziele gelten,
und wer eine Priorität verändern darf.

Beispielhafte Faktoren:

Anzahl betroffener Benutzer
Bedeutung des Geschäftsprozesses
vollständiger oder teilweiser Ausfall
verfügbare Zwischenlösung
Sicherheits- oder Datenschutzrisiko
gesetzliche Frist
zeitkritische Geschäftsaktivität
externe Kundenwirkung
drohender Datenverlust
und erwartete Dauer

Wichtig

Die lauteste Beschwerde darf nicht automatisch die höchste Priorität bestimmen.

Prioritäten sollten anhand nachvollziehbarer organisatorischer Kriterien festgelegt werden.

Servicekatalog angemessen gestalten

Ein Servicekatalog muss nicht jedes technische Detail enthalten.

Er sollte Informationen bereitstellen, die für die jeweilige Zielgruppe hilfreich sind.

Für Benutzer können relevant sein:

Name des Service
verständliche Beschreibung
mögliche Leistungen
Kontakt- oder Bestellweg
Voraussetzungen
Servicezeiten
erwartete Bereitstellungszeit
und wichtige Einschränkungen

Für interne Teams können zusätzlich relevant sein:

Service Owner
technische Abhängigkeiten
Lieferanten
Supportgruppen
Serviceziele
Sicherheitsklassifizierung
und Wiederherstellungsanforderungen

Ein kleiner Betrieb kann mit einer übersichtlichen Serviceliste beginnen.

Ein großes Unternehmen benötigt möglicherweise mehrere Katalogansichten und umfangreichere Serviceinformationen.

Configuration Management angemessen gestalten

Service Configuration Management bedeutet nicht, jede Schraube und jedes Kabel als einzelnes Configuration Item zu erfassen.

Der benötigte Detaillierungsgrad sollte sich richten nach:

Entscheidungsnutzen,
Risiko,
Änderungsbedarf,
Fehleranalyse,
Sicherheitsanforderungen,
Kosten der Datenpflege,
und Automatisierungsmöglichkeiten.

Geeignete Fragen:

Welche Informationen werden bei Incidents benötigt?
Welche Abhängigkeiten müssen vor Changes bekannt sein?
Welche Komponenten besitzen besondere Risiken?
Welche Daten lassen sich zuverlässig automatisiert erfassen?
Wer verwendet die Informationen?
Wie werden veraltete Daten erkannt?
Ist der Pflegeaufwand angemessen?

Typischer Fehler

Eine sehr detaillierte CMDB wird aufgebaut, ohne zu klären, welche Entscheidungen sie unterstützen soll.

Die Daten veralten und verlieren dadurch ihren Nutzen.

Knowledge Management anpassen

Eine Wissensdatenbank muss nicht möglichst viele Artikel enthalten.

Sie sollte benötigtes Wissen:

auffindbar,
verständlich,
aktuell,
vertrauenswürdig,
und anwendbar

bereitstellen.

Mögliche Wissensarten:

Benutzeranleitungen
Diagnoseanleitungen
Wiederherstellungsverfahren
bekannte Fehler
Workarounds
technische Standards
Lieferantenkontakte
Notfallinformationen
und Lessons Learned

Eine kleine Organisation kann mit wenigen hochwertigen Artikeln für häufige und kritische Situationen beginnen.

Kennzahlen an Outcomes ausrichten

ITIL schreibt keine universellen Kennzahlen für jede Organisation vor.

Kennzahlen sollten zum Zweck der jeweiligen Practice und zum benötigten Outcome passen.

Beispiel Incident Management:

Mögliche Kennzahlen:

Wiederherstellungszeit
Auswirkung auf Benutzer
Anzahl wiederholter Incidents
Anteil erneuter Kontaktaufnahmen
Qualität der Kommunikation
Serviceunterbrechungsdauer
und Anteil bestätigter Wiederherstellungen

Nicht ausreichend ist häufig die alleinige Betrachtung von:

Anzahl geschlossener Tickets
durchschnittlicher Ticketdauer
oder Anzahl weitergeleiteter Vorgänge

Beispiel Knowledge Management:

Nicht nur:

Wie viele Artikel wurden erstellt?

Sondern zusätzlich:

Werden sie gefunden?
Werden sie erfolgreich verwendet?
Sind sie aktuell?
Reduzieren sie wiederholte Analyse?
Verstehen Benutzer und Mitarbeiter die Inhalte?

Merke

Eine leicht messbare Zahl ist nicht automatisch eine hilfreiche Steuerungsinformation.

Werkzeuge nach der Arbeitsweise auswählen

Ein Werkzeug sollte die benötigten Wertströme und Practices unterstützen.

Vor der Auswahl sollte geklärt sein:

Welche Probleme sollen gelöst werden?
Welche Benutzergruppen verwenden das Werkzeug?
Welche Informationen werden benötigt?
Welche Integrationen bestehen?
Welche Automatisierungen sind sinnvoll?
Welche Sicherheitsanforderungen gelten?
Wie werden Daten exportiert?
Welche Lieferantenabhängigkeiten entstehen?
Wie hoch sind Einführung und Betrieb?
Welche Fähigkeiten werden benötigt?
Wie kann das Werkzeug später angepasst oder abgelöst werden?

Typischer Fehler

Die Organisation passt ihre gesamte Arbeitsweise an die Standardkonfiguration eines Werkzeugs an, obwohl diese nicht zu ihren Wertströmen und Risiken passt.

Gleichzeitig sollte eine unnötige Sonderkonfiguration vermieden werden.

Zu viele individuelle Anpassungen können:

Updates erschweren,
Kosten erhöhen,
Support komplizieren,
und die spätere Ablösung behindern.

Automatisierung angemessen einsetzen

Geeignete Automatisierungen können sein:

automatische Ticketerfassung aus relevanten Events
standardisierte Benutzeranlage
Softwareverteilung
technische Validierung
Erinnerungen und Eskalationen
Inventarisierung
Aktualisierung bestimmter Konfigurationsdaten
Statuskommunikation
und Berichtserstellung

Vor der Automatisierung sollte geklärt sein:

Ist der Ablauf notwendig?
Ist er verstanden?
Sind Regeln eindeutig?
Sind Eingangsdaten zuverlässig?
Welche Ausnahmen bestehen?
Wie werden Fehler behandelt?
Wer trägt Verantwortung?
Wie wird das Ergebnis kontrolliert?
Kann bei Bedarf manuell eingegriffen werden?

Grundsatz

Standardisieren und optimieren, bevor automatisiert wird.

Notwendige menschliche Entscheidungen dürfen nicht unbemerkt durch ungeprüfte technische Regeln ersetzt werden.

Künstliche Intelligenz kontextgerecht einsetzen

KI kann ITIL-basierte Arbeitsweisen unterstützen, beispielsweise durch:

Ticketklassifizierung
Zusammenfassungen
Wissenssuche
Mustererkennung
Prognosen
Kommunikationsvorschläge
und Automatisierungsunterstützung

Der Umfang menschlicher Kontrolle muss sich nach dem möglichen Risiko richten.

Zu prüfen sind:

Zweck der KI-Unterstützung
verwendete Daten
Datenschutz
Informationssicherheit
Ergebnisqualität
mögliche Verzerrungen
Nachvollziehbarkeit
Fehlerbehandlung
Lieferantenabhängigkeit
und Ergebnisverantwortung

Beispiel:

Eine KI kann eine Ticketkategorie vorschlagen.

Die Organisation muss trotzdem regeln:

wann eine automatische Zuordnung zulässig ist,
wie Fehlzuordnungen erkannt werden,
wer kritische Entscheidungen prüft,
und wie aus Fehlern gelernt wird.

ITIL mit anderen Ansätzen kombinieren

ITIL muss nicht isoliert verwendet werden.

Es kann mit anderen Frameworks, Normen und Arbeitsweisen kombiniert werden.

Ansatz	Möglicher Beitrag
Agile	iterative Entwicklung, Feedback und Anpassungsfähigkeit
Scrum	strukturierte Arbeit in Produktentwicklungsteams
Kanban	Visualisierung und Verbesserung des Arbeitsflusses
DevOps	Zusammenarbeit, Automatisierung und schnelle zuverlässige Bereitstellung
Lean	Fluss verbessern und vermeidbare Arbeit reduzieren
COBIT	Governance und Steuerung von Information und Technologie
ISO/IEC 20000	Anforderungen an ein Service-Management-System
ISO/IEC 27001	Anforderungen an ein Informationssicherheitsmanagementsystem
Projektmanagement	zeitlich begrenzte Vorhaben planen und steuern
Enterprise Architecture	Strukturen, Abhängigkeiten und Zielarchitekturen gestalten
Site Reliability Engineering	Zuverlässigkeit, Automatisierung und messbare Betriebsziele
Business Continuity Management	Fortführung kritischer Geschäftsaktivitäten vorbereiten

Die kombinierte Arbeitsweise sollte keine unnötigen parallelen Strukturen erzeugen.

Zu klären ist:

Welche Begriffe werden verwendet?
Welche Verantwortlichkeiten überschneiden sich?
Welche Kontrollen können gemeinsam genutzt werden?
Welche Dokumentationen sind doppelt?
Welche Ziele oder Messgrößen widersprechen sich?
Wie greifen die Ansätze im Wertstrom zusammen?

ITIL und agile Arbeitsweisen

ITIL und agile Arbeitsweisen schließen sich nicht aus.

Gemeinsame Grundgedanken können sein:

Fokus auf Wert
iterative Entwicklung
Feedback
Zusammenarbeit
Sichtbarkeit
und kontinuierliche Verbesserung

Mögliche Verbindung:

Product Owner priorisiert Produktanforderungen.
Service Owner betrachtet die Ende-zu-Ende-Servicequalität.
Entwicklung und Betrieb arbeiten gemeinsam an Releases.
Change Enablement verwendet risikobasierte Change-Modelle.
standardisierte und automatisierte Changes benötigen vereinfachte Autorisierung.
Betriebs- und Supportfeedback fließt in das Product Backlog.

Typischer Fehler

Jeder agile Sprint wird durch zusätzliche schwerfällige Freigabeverfahren verzögert, obwohl automatisierte Tests, klare Entscheidungsrechte und risikoarme Standardänderungen vorhanden sind.

Ebenso problematisch ist:

Mit dem Hinweis auf Agilität werden notwendige Sicherheits-, Qualitäts- oder Governance-Kontrollen vollständig umgangen.

ITIL und DevOps

DevOps fördert die Zusammenarbeit von:

Entwicklung,
Betrieb,
Sicherheit,
Qualitätssicherung,
und weiteren Beteiligten.

ITIL kann dazu beitragen:

Wert und Outcomes zu klären,
Produkte und Services gemeinsam zu betrachten,
Governance einzubinden,
Practices zu koordinieren,
Servicebeziehungen zu gestalten,
und Verbesserungen systematisch zu steuern.

Mögliche gemeinsame Umsetzung:

Infrastructure as Code
automatisierte Tests
automatisierte Deployments
Monitoring und Observability
gemeinsame Incident-Bearbeitung
blameless Reviews
risikobasierte Change-Modelle
automatisierte Dokumentationsaktualisierung
und Feedback aus dem Betrieb an Produktteams

ITIL und ISO/IEC 20000

ITIL stellt anpassbare Best-Practice-Guidance bereit.

ISO/IEC 20000 enthält Anforderungen an ein Service-Management-System.

Vereinfacht:

ITIL	ISO/IEC 20000
Best-Practice-Framework	internationale Norm
anpassbare Guidance	prüfbare Anforderungen
beschreibt Konzepte und Practices	fordert ein wirksames Managementsystem
keine allgemeine Organisationszertifizierung durch ITIL	Organisationen können sich im festgelegten Geltungsbereich zertifizieren lassen

Eine Organisation kann ITIL-Guidance verwenden, um ihr Service-Management-System zu gestalten.

Die Erfüllung einzelner ITIL-Empfehlungen beweist jedoch nicht automatisch die Konformität mit ISO/IEC 20000.

Nicht „ITIL-konform“ als allgemeines Ziel verwenden

ITIL ist ein anpassbares Framework und keine Norm mit einem universellen Organisationszertifikat.

Die Aussage:

Unsere Organisation ist vollständig ITIL-konform.

ist deshalb häufig unpräzise.

Besser ist eine konkrete Beschreibung:

Wir verwenden ITIL-Prinzipien zur Gestaltung unserer Arbeitsweisen.
Unser Incident Management orientiert sich an der entsprechenden ITIL Practice.
Unsere Wertströme kombinieren mehrere ITIL Practices.
Unsere Rollen und Prozesse wurden an den betrieblichen Kontext angepasst.
Unser ITSM-Werkzeug unterstützt bestimmte ITIL Practices.
Bestimmte Mitarbeiter besitzen ITIL-Zertifizierungen.

Wichtig

Zertifizierte Personen, akkreditierte Schulungen oder bewertete Werkzeuge beweisen nicht automatisch die Wirksamkeit des gesamten Service Managements einer Organisation.

Kleine Organisationen

Eine kleine Organisation benötigt möglicherweise:

einen gemeinsamen Supportkanal
wenige verständliche Ticketkategorien
klare persönliche Zuständigkeiten
einfache Prioritätsregeln
kompakte Change-Checklisten
wenige hochwertige Wissensartikel
eine übersichtliche Asset-Liste
vorbereitete Lieferantenkontakte
und regelmäßige Verbesserungsbesprechungen

Nicht zwingend erforderlich sind:

viele spezialisierte Rollen
mehrere Freigabegremien
umfangreiche Prozesshandbücher
hochkomplexe CMDB-Strukturen
oder für jede Practice ein eigenes Team

Merke

Klein bedeutet nicht unprofessionell.

Auch einfache Arbeitsweisen können verlässlich, kontrolliert und nachvollziehbar sein.

Große oder regulierte Organisationen

Eine große oder regulierte Organisation benötigt möglicherweise:

formalisierte Governance
eindeutige Funktionstrennung
mehrere Supportgruppen
umfangreiche Auditnachweise
unterschiedliche Serviceklassen
definierte Risikomodelle
Lieferantensteuerung
Notfall- und Kontinuitätsverfahren
zentrale Konfigurationsinformationen
automatisierte Kontrollen
und umfangreichere Messung

Trotzdem sollte auch hier unnötige Komplexität vermieden werden.

Ein umfangreicher Ablauf ist nur dann gerechtfertigt, wenn er:

ein relevantes Risiko behandelt,
eine verbindliche Anforderung erfüllt,
eine notwendige Entscheidung ermöglicht,
oder einen nachweisbaren Wertbeitrag besitzt.

Managed Service Provider

Ein Managed Service Provider muss zusätzlich berücksichtigen:

unterschiedliche Kundenverträge
unterschiedliche Serviceziele
getrennte Kundendaten
Berechtigungsgrenzen
kundenspezifische Eskalationen
gemeinsame technische Plattformen
Unterauftragnehmer
und klare Verantwortungsübergänge

Ein standardisierter interner Ablauf kann sinnvoll sein.

Er muss jedoch unterschiedliche Kundenanforderungen und Vertragsbedingungen berücksichtigen.

Beispiel:

Ein Incident derselben technischen Plattform kann für zwei Kunden unterschiedliche:

Prioritäten,
Kommunikationspflichten,
Servicezeiten,
und Eskalationswege

besitzen.

Cloud- und SaaS-Umgebungen

Bei Cloud-Services sollte die Anpassung unter anderem berücksichtigen:

geteilte Verantwortung
Anbieterabhängigkeit
Datenstandort
Identitätsmanagement
Schnittstellen
Konfiguration
Kostensteuerung
Serviceänderungen des Anbieters
Supportmodelle
Datenportabilität
und Exit-Planung

Traditionelle Aufgaben können sich verändern.

Beispiel:

Die Organisation tauscht möglicherweise keine defekten physischen Server mehr selbst aus.

Sie bleibt jedoch verantwortlich für:

geeignete Architektur,
Konfiguration,
Benutzerzugriffe,
Daten,
Überwachung,
Kosten,
Wiederherstellungsplanung,
und Lieferantensteuerung.

Öffentliche Verwaltung und regulierte Bereiche

Zusätzlich relevant können sein:

Vergaberecht
Datenschutz
Aufbewahrungsfristen
Barrierefreiheit
Informationssicherheit
Nachweispflichten
Mitbestimmung
Aktenführung
Haushaltsvorgaben
und besondere Genehmigungswege

Diese Anforderungen dürfen nicht als unnötige Bürokratie entfernt werden.

Sie sollten jedoch so gestaltet werden, dass:

Zweck und Verantwortung verständlich sind,
doppelte Kontrollen vermieden werden,
Informationen möglichst einmalig und zuverlässig erfasst werden,
und der gesamte Wertstrom weiterhin handlungsfähig bleibt.

Praktische Vorgehensweise zur Anpassung

Die folgende Vorgehensweise ist eine redaktionelle Praxisempfehlung dieses Buches.

Sie ist keine verbindlich vorgeschriebene offizielle ITIL-Schrittfolge.

1. Ziele und Probleme bestimmen

Erfasse:

wichtige Geschäfts- und Organisationsziele
betroffene Produkte und Services
konkrete Probleme
Chancen
Risiken
und Erwartungen der Stakeholder

Ergebnis:

verständliche Beschreibung, warum eine Veränderung notwendig ist

2. Kritische Produkte und Services bestimmen

Fragen:

Welche Services sind besonders wichtig?
Welche Benutzer und Geschäftsprozesse hängen davon ab?
Welche Ausfälle wären besonders schwerwiegend?
Welche Lieferanten und technischen Komponenten sind kritisch?
Welche Sicherheits- und Wiederherstellungsanforderungen gelten?

Ergebnis:

priorisierter Ausgangspunkt statt unkontrollierter Bearbeitung aller Bereiche

3. Tatsächliche Wertströme untersuchen

Beispiele:

Incident bearbeiten
neuen Benutzer bereitstellen
Software anfordern
Sicherheitsupdate einführen
Lieferantenstörung eskalieren
Service wiederherstellen

Untersuche:

Auslöser
Schritte
Beteiligte
Informationen
Übergaben
Wartezeiten
Nacharbeit
Kontrollen
und Outcome

4. Benötigte Practices bestimmen

Fragen:

Welche Fähigkeiten werden im Wertstrom benötigt?
Welche Practices existieren bereits?
Welche Practice-Lücken verursachen konkrete Probleme?
Wo fehlen Rollen, Informationen oder Werkzeuge?
Welche Practices müssen zusammenwirken?

5. Aktuellen Zustand bewerten

Bewerte unter anderem:

Rollen
Fähigkeiten
Kapazität
Prozesse
Werkzeuge
Datenqualität
Lieferanten
Messgrößen
Governance
und tatsächliche Anwendung

Ergebnis:

realistische Baseline statt rein theoretischer Sollbeschreibung

6. Zielzustand bestimmen

Der Zielzustand sollte beschreiben:

gewünschtes Outcome
benötigte Rollen
angemessene Kontrollen
Informationsbedarf
Werkzeugunterstützung
relevante Messgrößen
und notwendige Schnittstellen

Er muss nicht sofort den endgültigen Idealzustand darstellen.

Ein sinnvoller nächster Zustand kann ausreichend sein.

7. Kleinste wirksame Verbesserung auswählen

Beispiele:

eindeutigen Kontaktweg einführen
Prioritätskriterien dokumentieren
Lieferanteneskalation vorbereiten
kritische Serviceabhängigkeiten erfassen
Pflichtinformationen eines Tickets verbessern
Wiederherstellung aus Benutzersicht bestätigen
häufige Lösung dokumentieren
unnötige Freigabe entfernen
oder relevante Monitoring-Warnung ergänzen

8. Verantwortlichkeit und Governance klären

Bestimme:

wer entscheidet
wer umsetzt
wer das Ergebnis kontrolliert
wer Risiken akzeptieren darf
wer eskaliert
wer die Arbeitsweise verbessert
und welche Grenzen gelten

9. Iterativ umsetzen

Verwende nach Möglichkeit:

Pilotgruppen
begrenzte Services
kurze Feedbackzyklen
messbare Teilziele
und kontrollierte Ausweitung

10. Wirkung messen

Prüfe:

Hat sich das Outcome verbessert?
Wurde das Risiko reduziert?
Ist die Arbeitsweise verständlicher?
Entsteht weniger Wartezeit oder Nacharbeit?
Hat sich die Benutzererfahrung verbessert?
Sind neue Probleme entstanden?
Wird die Arbeitsweise tatsächlich verwendet?

11. Ergebnisse verankern

Aktualisiere bei Bedarf:

Rollen
Prozesse
Arbeitsanweisungen
Werkzeuge
Automatisierungen
Knowledge-Artikel
Schulungen
Lieferantenvereinbarungen
und Messgrößen

12. Fortlaufend verbessern

Erfasse neue:

Probleme
Chancen
technische Schulden
Stakeholder-Rückmeldungen
Risiken
und Verbesserungsideen

Anpassung ist keine einmalige Einführungsphase.

Sie bleibt Teil von Continual Improvement.

Minimum Viable Practice

Eine Organisation kann zunächst eine bewusst begrenzte, aber funktionsfähige Ausprägung einer Practice gestalten.

Eine solche erste Ausprägung sollte mindestens klären:

Zweck
gewünschtes Outcome
Auslöser
Rollen
Verantwortung
wichtigste Schritte
notwendige Informationen
Eskalation
Ergebnisprüfung
und Verbesserung

Beispiel: erste Incident-Management-Ausprägung

eindeutiger Kontaktweg
einheitliche Incident-Erfassung
einfache Prioritätskriterien
klare Zuständigkeiten
Eskalationsweg
Statuskommunikation
Prüfung der Wiederherstellung
Erfassung wiederkehrender Muster

Später können ergänzt werden:

Automatisierung
umfassendere Serviceabhängigkeiten
detailliertere Messung
Lieferantenintegration
Major-Incident-Verfahren
und weiterentwickelte Knowledge-Unterstützung

Wichtig

Eine minimale Practice darf nicht so stark reduziert sein, dass ihr grundlegender Zweck nicht mehr erfüllt wird.

Pilotierung

Ein Pilot kann helfen, eine angepasste Arbeitsweise zu prüfen.

Geeigneter Pilotumfang:

ein wichtiger Service
ein Standort
eine Benutzergruppe
ein Team
eine bestimmte Ticketart
oder ein klar abgegrenzter Wertstrom

Vor dem Pilot sollten festgelegt werden:

Ziel
Umfang
Beteiligte
Erfolgskriterien
Dauer
Risiken
Rückfallmöglichkeit
Feedbackwege
und Auswertungszeitpunkt

Nach dem Pilot wird entschieden:

übernehmen
anpassen
erweitern
erneut testen
oder verwerfen

Organizational Change Management

Die Anpassung von ITIL verändert möglicherweise:

Rollen
Gewohnheiten
Entscheidungswege
Werkzeuge
Verantwortlichkeiten
Kennzahlen
und Zusammenarbeit

Technische Bereitstellung allein reicht deshalb nicht aus.

Zu berücksichtigen sind:

verständliche Begründung
Beteiligung der Betroffenen
Kommunikation
Schulung
Unterstützung
Widerstände
Führung
Zeit für Umstellung
und Überprüfung der tatsächlichen Anwendung

Typischer Fehler

Ein neuer Prozess wird veröffentlicht und die Organisation erwartet, dass alle Beteiligten ihn ab dem nächsten Tag korrekt anwenden.

Zwischen lokaler Verbesserung und Transformation unterscheiden

Nicht jede Anpassung benötigt ein großes Transformationsprogramm.

Lokale Verbesserung

Beispiele:

Ticketformular verbessern
Eskalationskontakt ergänzen
Wissensartikel aktualisieren
Monitoring-Regel anpassen

Practice-Verbesserung

Beispiele:

Incident Management neu gestalten
Service Configuration Management entwickeln
Supplier Management vereinheitlichen

Wertstromverbesserung

Beispiele:

Onboarding Ende zu Ende verbessern
Releasebereitstellung beschleunigen
Incident-Wiederherstellung vereinfachen

Transformation

Beispiele:

gesamte Organisation auf Produkt- und Serviceorientierung ausrichten
Governance, Betriebsmodell, Rollen und Technologie umfassend verändern
mehrere Wertströme und Practices gleichzeitig neu gestalten

Der Umfang der Steuerung muss zur tatsächlichen Veränderung passen.

Reife nicht als Selbstzweck betrachten

Eine Organisation kann Practices und Fähigkeiten bewerten, um ihren aktuellen Zustand besser zu verstehen.

Ein höherer Reife- oder Fähigkeitsgrad ist jedoch nicht automatisch für jede Practice notwendig.

Fragen:

Welche Fähigkeit wird für unsere Outcomes benötigt?
Welches Risiko besteht im aktuellen Zustand?
Welche Investition ist angemessen?
Welche Practice ist besonders kritisch?
Welcher nächste Fähigkeitsstand erzeugt einen tatsächlichen Nutzen?

Beispiel:

Ein hochentwickeltes Service Configuration Management kann für eine komplexe, stark integrierte Umgebung wichtig sein.

Für eine sehr kleine und überschaubare Umgebung kann eine einfachere, aber zuverlässige Dokumentation ausreichend sein.

Typische Fehlanpassungen

Fehler 1: ITIL vollständig kopieren

Vorlagen und Prozesse werden unverändert übernommen, obwohl sie nicht zur Organisation passen.

Fehler 2: Nur Begriffe ändern

Alte Probleme bleiben bestehen, werden aber mit neuen ITIL-Bezeichnungen versehen.

Fehler 3: Mit dem Werkzeug beginnen

Das Tool bestimmt die Arbeitsweise, bevor Ziele und Wertströme verstanden wurden.

Fehler 4: Alle Practices gleichzeitig einführen

Ressourcen werden überlastet und keine Practice wird wirksam aufgebaut.

Fehler 5: Jede Practice als eigene Abteilung aufbauen

Unnötige Silos und Übergaben entstehen.

Fehler 6: Rollen ohne Befugnisse vergeben

Personen tragen Verantwortung, können aber nicht entscheiden oder Ressourcen erhalten.

Fehler 7: Jeden Vorgang gleich behandeln

Risikoarme und kritische Tätigkeiten durchlaufen identische Kontrollen.

Fehler 8: Dokumentationsmenge mit Qualität verwechseln

Viele Felder und Dokumente erzeugen keine bessere Entscheidung oder Nachvollziehbarkeit.

Fehler 9: Bestehende funktionierende Arbeitsweisen verwerfen

Wertvolles Wissen und bewährte Fähigkeiten gehen verloren.

Fehler 10: Nur interne Sicht verwenden

Benutzer, Kunden, Fachabteilungen und Lieferanten werden nicht ausreichend einbezogen.

Fehler 11: Prozessgrenzen mit Wertstromgrenzen verwechseln

Jedes Team optimiert seinen Abschnitt, aber niemand betrachtet das gesamte Outcome.

Fehler 12: Kontrollen ohne Zweck einführen

Jeder frühere Fehler führt zu einer zusätzlichen dauerhaften Genehmigung.

Fehler 13: Notwendige Kontrollen als Bürokratie entfernen

Sicherheits-, Datenschutz- oder Compliance-Anforderungen werden unzureichend behandelt.

Fehler 14: Kennzahlen ungeprüft übernehmen

Gemessen wird, was das Werkzeug standardmäßig anbietet, nicht was für Outcomes und Entscheidungen wichtig ist.

Fehler 15: Automatisierung als erstes Ziel verwenden

Ein ungeeigneter Ablauf wird schneller und schwerer veränderbar gemacht.

Fehler 16: Anpassung als einmalige Einführung betrachten

Nach dem Projekt werden Arbeitsweisen nicht mehr überprüft oder verbessert.

Fehler 17: „ITIL-konform“ statt wirksam arbeiten

Die Organisation konzentriert sich auf Begriffe und Formalitäten statt auf Outcomes, Risiken und Erfahrung.

Praxisbeispiel: Kleiner interner IT-Support

Ausgangslage

drei IT-Mitarbeiter
80 Benutzer
Meldungen per Telefon, E-Mail und Zuruf
keine einheitliche Priorisierung
Lösungen befinden sich in privaten Notizen

Angemessener erster Zielzustand

ein gemeinsamer Kontaktweg
ein einfaches Ticketsystem
Incident und Service Request unterscheiden
drei oder vier Prioritätsstufen
klare persönliche Zuständigkeit
gemeinsame Wissensablage
wöchentliche Prüfung wiederkehrender Probleme

Noch nicht zwingend notwendig

komplexes Major-Incident-Gremium
umfangreiche CMDB
mehrere Supportebenen
vollständige Prozessbibliothek
zahlreiche spezialisierte Rollen

Praxisbeispiel: Kritischer Produktionsservice

Ausgangslage

Produktion hängt von mehreren Anwendungen und Netzwerken ab
externe Anlagenhersteller sind beteiligt
Ausfälle verursachen hohe Kosten
Abhängigkeiten sind nur teilweise dokumentiert

Möglicher Zielzustand

eindeutiger Service Owner
bekannte kritische Configuration Items
vorbereitete Major-Incident-Koordination
risikobasierte Change-Autorisierung
aktuelle Lieferantenkontakte
definierte Wiederherstellungsziele
getestete Notfallverfahren
Monitoring des gesamten Service
regelmäßige Problem- und Verbesserungsanalyse

Hier ist ein höherer Kontroll- und Dokumentationsumfang angemessen.

Praxisbeispiel: Agile Softwareorganisation

Ausgangslage

mehrere tägliche Deployments
automatisierte Tests
Produktteams mit Ende-zu-Ende-Verantwortung
zentrale Change-Sitzung verzögert jede Veröffentlichung

Mögliche Anpassung

standardisierte, automatisierte Deployments als geeignetes Change-Modell behandeln
Entscheidungsrechte an befähigte Produktteams delegieren
automatisierte Tests und technische Kontrollen als Nachweise verwenden
risikoreiche Änderungen vertieft bewerten
Änderungen transparent machen
Monitoring und schnelle Wiederherstellung sicherstellen
fehlgeschlagene Changes auswerten
Governance über Ziele, Grenzen und Ergebnisse statt über jede Einzelgenehmigung ausüben

Merke

Häufige Änderungen benötigen nicht automatisch weniger Kontrolle.

Sie benötigen häufig stärker automatisierte, risikogerechte und schneller wirksame Kontrollen.

Praxisbeispiel: Cloud-Service

Ausgangslage

E-Mail, Dateien und Zusammenarbeit werden als Cloud-Service bezogen
interne IT betreibt keine zugrunde liegenden Server
Benutzerkonten und Berechtigungen werden intern verwaltet

Angepasste Practices

Supplier Management für Anbieterleistung und Eskalation
Information Security Management für Identitäten und Daten
Service Configuration Management für Abhängigkeiten und Integrationen
Incident Management für interne Koordination
Service Request Management für Benutzer- und Zugriffsanfragen
IT Asset Management für Lizenzen und Abonnements
Service Continuity Management für Ausfall- und Wiederherstellungsszenarien
Continual Improvement für Kosten, Nutzung und Erfahrung

Die Verantwortung verschiebt sich.

Sie verschwindet nicht.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten häufig an der konkreten Umsetzung angepasster Practices.

Mögliche Beiträge:

technische Ausgangslage erklären
Abhängigkeiten dokumentieren
Risiken einer Änderung benennen
praktische Arbeitsanweisungen erstellen
Monitoring und Automatisierung aufbauen
Wiederherstellung testen
Werkzeugkonfiguration verbessern
Lieferanteninformationen bereitstellen
wiederkehrende Fehler sichtbar machen
und Verbesserungsvorschläge formulieren

Hilfreiche Fragen im Arbeitsalltag:

Welches Outcome soll meine Tätigkeit unterstützen?
Welche betriebliche Regel gilt?
Warum existiert diese Regel?
Passt der Aufwand zum Risiko?
Welche Informationen werden wirklich benötigt?
Wer arbeitet vor und nach meinem Schritt?
Welche Abhängigkeiten bestehen?
Wie wird der Erfolg geprüft?
Was muss dokumentiert werden?
Was könnte vereinfacht oder automatisiert werden?
Welche Verbesserung sollte weitergegeben werden?

30-Sekunden-Prüfung einer ITIL-Anpassung

Ziel: Welches Problem oder Outcome steht im Mittelpunkt?
Ausgangslage: Was funktioniert bereits?
Kontext: Welche Risiken, Vorgaben und Fähigkeiten bestehen?
Wertstrom: Wie gelangt die Arbeit vom Bedarf zum Ergebnis?
Practices: Welche Fähigkeiten werden tatsächlich benötigt?
Dimensionen: Wurden Menschen, Technologie, Partner und Arbeitsfluss betrachtet?
Einfachheit: Ist jeder Schritt notwendig?
Governance: Sind Verantwortung und Befugnisse eindeutig?
Messung: Woran erkennen wir Wirksamkeit?
Verbesserung: Wie wird Feedback genutzt?

Checkliste vor der Anpassung

Checkliste zur Gestaltung

Checkliste zur Einführung

Checkliste zur Wirksamkeitsprüfung

Checkliste gegen unnötige Bürokratie

Schnellreferenz

Frage	Bedeutung für die Anpassung
Was soll verbessert werden?	Ziel und Outcome bestimmen
Was funktioniert bereits?	vorhandene Fähigkeiten erhalten
Welcher Kontext gilt?	Risiken, Vorgaben und Ressourcen berücksichtigen
Welcher Wertstrom ist betroffen?	Ende-zu-Ende-Arbeit untersuchen
Welche Practices werden benötigt?	passende organisatorische Fähigkeiten auswählen
Wie umfangreich muss die Lösung sein?	Aufwand an Risiko und Nutzen ausrichten
Wer entscheidet und verantwortet?	Governance und Rollen klären
Welche Informationen werden benötigt?	Daten und Dokumentation zweckmäßig gestalten
Welche Werkzeuge unterstützen?	Technik nach der Arbeitsweise auswählen
Wie wird Erfolg geprüft?	Outcomes und geeignete Messgrößen verwenden
Was lernen wir daraus?	Continual Improvement verankern

Zusammenfassende Darstellung

Ziele, Bedürfnisse, Risiken und Vorgaben verstehen
↓
aktuelle Produkte, Services und Wertströme untersuchen
↓
vorhandene Fähigkeiten und funktionierende Arbeitsweisen berücksichtigen
↓
benötigte Management Practices auswählen
↓
Rollen · Informationen · Prozesse · Technologie · Lieferanten anpassen
↓
klein und risikogerecht beginnen
↓
Ergebnisse und Stakeholder-Erfahrung messen
↓
Arbeitsweise verankern und kontinuierlich verbessern

Abschluss des Kapitels

Die wichtigsten Bestandteile des ITIL-Frameworks wurden in diesem Kapitel behandelt:

ITIL als anpassbares Best-Practice-Framework
das ITIL Value System
die sieben Guiding Principles
Governance und Verantwortlichkeit
die vier Dimensionen
der Product and Service Lifecycle
die 34 Management Practices
Value Streams und Value Stream Mapping
Continual Improvement
und die Anpassung an den organisatorischen Kontext

Diese Bestandteile sollten nicht isoliert verwendet werden.

Sie bilden gemeinsam einen Orientierungsrahmen für professionelles digitales Produkt- und Service-Management.

Kernaussage des Kapitels

ITIL liefert keine fertige Organisation.

ITIL hilft einer Organisation, ihre eigenen Produkte, Services, Wertströme, Practices und Entscheidungen wirksamer zu gestalten.

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.9 Continual Improvement
Service Desk
Incident Management
Service Request Management
Problem Management
Change Enablement
Knowledge Management
Service Configuration Management
Measurement and Reporting

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL-Version-5-Informationen bestätigen:

ITIL stellt praktische und anpassbare Best-Practice-Guidance bereit.
ITIL ist für unterschiedliche Branchen, Betriebsmodelle und organisatorische Reifegrade vorgesehen.
Die Guiding Principles unterstützen die Anpassung von ITIL Practices an reale digitale Umgebungen.
ITIL soll in realen organisatorischen Kontexten angewendet und an den tatsächlichen Bedarf angepasst werden.
ITIL Version 5 verbindet Wert, Outcomes, Erfahrung, Governance, Practices, Technologie und Continual Improvement.
Für umfangreiche organisatorische Veränderungen stellt ITIL Version 5 zusätzliche Transformation Guidance bereit.

Einordnung

Die auf dieser Seite dargestellte praktische Vorgehensweise mit zwölf Schritten, die Checklisten, Beispiele, Tabellen und die Bezeichnung Minimum Viable Practice sind redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtliche offizielle ITIL-Implementierungsmethode und keine vorgeschriebene Reihenfolge dar.

Konkrete:

Rollen,
Prozessschritte,
Prioritätsmodelle,
Freigaben,
Werkzeuge,
Kennzahlen,
Dokumentationsanforderungen,
und Kontrollverfahren

müssen von der jeweiligen Organisation anhand ihrer Ziele, Risiken, Fähigkeiten und verbindlichen Vorgaben festgelegt werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026