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

Revision #1
Created 1 August 2026 22:19:32 by Admin
Updated 1 August 2026 22:19:45 by Admin