# 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:

1. wichtige Produkte und Services bestimmen
2. konkrete Probleme und Chancen erfassen
3. relevante Wertströme untersuchen
4. benötigte Practices identifizieren
5. vorhandene Fähigkeiten bewerten
6. wichtigste Lücken priorisieren
7. kleine wirksame Verbesserungen umsetzen
8. Ergebnisse messen
9. 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**

1. **Ziel:** Welches Problem oder Outcome steht im Mittelpunkt?
2. **Ausgangslage:** Was funktioniert bereits?
3. **Kontext:** Welche Risiken, Vorgaben und Fähigkeiten bestehen?
4. **Wertstrom:** Wie gelangt die Arbeit vom Bedarf zum Ergebnis?
5. **Practices:** Welche Fähigkeiten werden tatsächlich benötigt?
6. **Dimensionen:** Wurden Menschen, Technologie, Partner und Arbeitsfluss betrachtet?
7. **Einfachheit:** Ist jeder Schritt notwendig?
8. **Governance:** Sind Verantwortung und Befugnisse eindeutig?
9. **Messung:** Woran erkennen wir Wirksamkeit?
10. **Verbesserung:** Wie wird Feedback genutzt?

---

**Checkliste vor der Anpassung**

- [ ] Sind Ziele und gewünschte Outcomes bekannt?
- [ ] Sind wichtige Produkte und Services bestimmt?
- [ ] Sind relevante Stakeholder beteiligt?
- [ ] Sind gesetzliche, vertragliche und sicherheitsrelevante Vorgaben bekannt?
- [ ] Wurde der aktuelle Zustand untersucht?
- [ ] Wurde geprüft, was bereits gut funktioniert?
- [ ] Sind kritische Wertströme bekannt?
- [ ] Sind konkrete Probleme und Risiken belegt?
- [ ] Sind vorhandene Fähigkeiten und Ressourcen bekannt?
- [ ] Sind wichtige Lieferanten und Abhängigkeiten berücksichtigt?

---

**Checkliste zur Gestaltung**

- [ ] Ist der Zweck der betreffenden Practice verstanden?
- [ ] Unterstützt die Gestaltung ein konkretes Outcome?
- [ ] Wurden alle vier Dimensionen berücksichtigt?
- [ ] Sind Rollen und Entscheidungsbefugnisse eindeutig?
- [ ] Sind benötigte Informationen bestimmt?
- [ ] Sind Prozesse und Kontrollen risikogerecht?
- [ ] Wurde unnötige Komplexität vermieden?
- [ ] Unterstützen Werkzeuge die Arbeitsweise?
- [ ] Sind Lieferanten und externe Schnittstellen einbezogen?
- [ ] Sind Ausnahmen und Eskalationen geregelt?
- [ ] Sind Messgrößen und Erfolgskriterien festgelegt?
- [ ] Kann die Einführung iterativ erfolgen?

---

**Checkliste zur Einführung**

- [ ] Ist ein sinnvoller Pilotumfang festgelegt?
- [ ] Sind Verantwortliche und Ressourcen verfügbar?
- [ ] Sind betroffene Mitarbeiter beteiligt?
- [ ] Ist die Begründung der Veränderung verständlich?
- [ ] Sind Schulung und Unterstützung vorbereitet?
- [ ] Sind technische Konfigurationen getestet?
- [ ] Sind Datenmigration und Schnittstellen geprüft?
- [ ] Besteht eine Rückfall- oder Anpassungsmöglichkeit?
- [ ] Werden Feedback und Messwerte erfasst?
- [ ] Ist die nächste Auswertungsentscheidung vorbereitet?

---

**Checkliste zur Wirksamkeitsprüfung**

- [ ] Wird die neue Arbeitsweise tatsächlich angewendet?
- [ ] Hat sich das gewünschte Outcome verbessert?
- [ ] Wurden Risiken reduziert?
- [ ] Entsteht weniger Wartezeit oder Nacharbeit?
- [ ] Hat sich die Stakeholder-Erfahrung verbessert?
- [ ] Sind neue Risiken oder Engpässe entstanden?
- [ ] Sind Informationen und Dokumentationen zuverlässig?
- [ ] Passen Rollen und Befugnisse zur tatsächlichen Arbeit?
- [ ] Unterstützen Kennzahlen sinnvolles Verhalten?
- [ ] Werden Automatisierungen ausreichend überwacht?
- [ ] Sind weitere Anpassungen notwendig?

---

**Checkliste gegen unnötige Bürokratie**

- [ ] Besitzt jeder Pflichtschritt einen erkennbaren Zweck?
- [ ] Behandelt jede Genehmigung ein reales Risiko oder eine verbindliche Vorgabe?
- [ ] Werden Informationen nur einmal zuverlässig erfasst?
- [ ] Sind Pflichtfelder verständlich und nutzbar?
- [ ] Können risikoarme Standardfälle vereinfacht werden?
- [ ] Werden seltene Ausnahmen nicht unnötig zum Standard?
- [ ] Sind Dokumentationen für ihre Zielgruppen geeignet?
- [ ] Werden veraltete Kontrollen regelmäßig überprüft?
- [ ] Wird lokale Optimierung zulasten des gesamten Wertstroms vermieden?
- [ ] Wird vor einer Automatisierung zuerst optimiert?

---

**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**

- [ITIL: Welcome to ITIL](https://www.itil.com/)
- [ITIL: ITIL at a Glance](https://www.itil.com/at-a-glance)
- [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154)
- [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5)
- [ITIL: ITIL Certifications](https://www.itil.com/certifications)
- [ITIL: New ITIL Explained for Certified Professionals](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-explained)
- [PeopleCert: ITIL Transformation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-transformation-version-5-4173)
- [ITIL: ITIL Transformation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Transformation-Version-5)
- [ITIL: ITIL How to Implement – Official Book](https://www.itil.com/Itil-News-and-Announcements/itil-how-to-implement-official-book)
- [PeopleCert: ITIL FAQ](https://www.peoplecert.org/help-and-support/faq-itil)

**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