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

Revision #1
Created 1 August 2026 22:52:16 by Admin
Updated 1 August 2026 22:52:28 by Admin