0.2 So nutzt du dieses Buch
Kurz erklärt
Dieses Buch kann vollständig von Anfang bis Ende gelesen oder gezielt als Nachschlagewerk verwendet werden.
Du musst nicht jedes Kapitel kennen, bevor du mit einer konkreten Aufgabe arbeitest. Die Seiten sind so aufgebaut, dass wichtige Informationen auch einzeln verständlich und schnell auffindbar sind.
Drei Möglichkeiten, dieses Buch zu verwenden
| Nutzung | Wann ist sie sinnvoll? | Vorgehensweise |
|---|---|---|
| Lernen | Du möchtest ITIL und Service Management systematisch verstehen. | Kapitel in der vorgesehenen Reihenfolge durcharbeiten. |
| Nachschlagen | Du suchst eine Definition, Abgrenzung oder Entscheidungshilfe. | Über Inhaltsverzeichnis, Suche oder Querverweise zur passenden Seite wechseln. |
| Arbeiten | Du befindest dich in einer konkreten Arbeitssituation. | Schnellübersicht, Vorgehensweise und Checkliste der passenden Seite verwenden. |
Die drei Nutzungsarten schließen sich nicht gegenseitig aus.
Eine Seite kann zunächst zum Lernen gelesen und später als kompakte Arbeitshilfe verwendet werden.
Wenn du das Thema vollständig lernen möchtest
Für ein vollständiges Verständnis empfiehlt sich folgende Reihenfolge:
- Grundlagen und zentrale Begriffe
- Aufbau und Denkweise von ITIL
- Produkte, Services und Wertströme
- wichtige ITIL Practices
- professionelle Ticketbearbeitung
- typische Situationen aus dem IT-Betrieb
- Praxisfälle, Checklisten und Entscheidungshilfen
Die Grundlagenkapitel vermitteln das notwendige Verständnis für spätere Themen.
Es ist beispielsweise hilfreich, zunächst die Begriffe Service, Wert, Outcome, Kosten, Risiko und Stakeholder zu verstehen, bevor Practices wie Service Level Management oder Continual Improvement vertieft werden.
Merke
Die Praxis wird leichter verständlich, wenn die zugrunde liegenden Begriffe, Ziele und Zusammenhänge bekannt sind.
Wenn du schnell etwas nachschlagen möchtest
Beim Nachschlagen musst du nicht die gesamte Seite von oben bis unten lesen.
| Gesuchte Information | Geeigneter Abschnitt |
|---|---|
| Bedeutung eines Begriffs | Kurz erklärt oder Grundlagen |
| konkrete Arbeitsschritte | Vorgehensweise |
| schnelle Kontrolle | Checkliste |
| Entscheidung zwischen mehreren Möglichkeiten | Entscheidungshilfe |
| häufige Fehler | Typische Fehler |
| besondere Gefahren | Risiken und Sicherheitsaspekte |
| praktische Erfahrung | Praxistipp |
| technische Vertiefung | Verwandte Themen |
| Herkunft einer Aussage | Quellen und Versionsstand |
Die wichtigsten Informationen stehen nach Möglichkeit weit oben auf der Seite.
Vertiefungen, Sonderfälle und Quellen folgen anschließend.
Wenn du dich in einer konkreten Arbeitssituation befindest
Angenommen, ein Benutzer meldet:
„Ich kann mich seit heute Morgen nicht mehr anmelden.“
Dann musst du nicht sofort das gesamte Kapitel über Incident Management lesen.
Gehe stattdessen folgendermaßen vor:
- konkrete Situation erfassen
- betroffenen Service bestimmen
- nach Situation, Service oder Fehlermeldung suchen
- passende Praxis- oder Schnellreferenzseite öffnen
- wichtigste Rückfragen prüfen
- Auswirkung und Dringlichkeit bewerten
- vorgeschlagene Vorgehensweise verwenden
- Eskalations- und Sicherheitskriterien beachten
- durchgeführte Schritte und Ergebnisse dokumentieren
- bei Bedarf technische Querverweise nutzen
Wichtig
Eine Checkliste unterstützt deine Arbeit, ersetzt aber nicht die fachliche Bewertung der konkreten Situation.
Schnellzugriff nach Arbeitssituation
| Situation | Passender Themenbereich |
|---|---|
| Ein Benutzer meldet eine Störung. | Incident Management |
| Ein Benutzer benötigt einen freigegebenen Standardservice. | Service Request Management |
| Derselbe Fehler tritt wiederholt auf. | Problem Management |
| Eine Konfiguration soll geändert werden. | Change Management |
| Eine Organisation verwendet noch ITIL-4-Begriffe. | Change Enablement entspricht der früheren Bezeichnung der Practice |
| Ein kritischer Incident beeinträchtigt einen wichtigen Service. | Incident Management und organisationsspezifisches Major-Incident-Verfahren |
| Eine Lösung soll für Kollegen festgehalten werden. | Knowledge Management |
| Ein Server oder Netzwerkgerät soll verwaltet erfasst werden. | IT Asset Management und Service Configuration Management |
| Ein Monitoring-System erzeugt eine Meldung. | Monitoring and Event Management |
| Ein Dienstleister muss eingebunden werden. | Supplier Management |
| Ein vereinbarter Servicewert wird nicht erreicht. | Service Level Management |
| Eine Arbeitsweise soll dauerhaft verbessert werden. | Continual Improvement |
Diese Zuordnung dient als erste Orientierung.
Je nach Situation können mehrere Practices gleichzeitig beteiligt sein.
Versionshinweis
In ITIL Version 5 heißt die Practice Change Management.
In ITIL 4 wurde sie Change Enablement genannt.
Ein Major Incident ist eine besonders schwerwiegende Kategorie eines Incidents. Die dafür verwendeten Verfahren und Rollen werden von der jeweiligen Organisation festgelegt.
Technische und organisatorische Perspektive verbinden
Viele Aufgaben eines Systemintegrators besitzen zwei Perspektiven.
| Perspektive | Zentrale Frage |
|---|---|
| Technische Perspektive | Wie untersuche, konfiguriere oder repariere ich das System? |
| Service-Management-Perspektive | Wie ordne, priorisiere, dokumentiere und koordiniere ich die Arbeit? |
Beispiel:
Ein Webserver ist nicht erreichbar.
Die technische Perspektive kann umfassen:
- Netzwerkverbindung prüfen,
- DNS-Auflösung testen,
- Erreichbarkeit des Hosts kontrollieren,
- Dienststatus prüfen,
- Protokolle auswerten,
- Firewall-Regeln untersuchen,
- Container oder virtuelle Maschine kontrollieren.
Die Service-Management-Perspektive ergänzt:
- betroffenen Service bestimmen,
- betroffene Benutzer feststellen,
- Auswirkungen bewerten,
- Priorität festlegen,
- Zuständigkeit klären,
- Beteiligte informieren,
- Eskalation prüfen,
- Wiederherstellung dokumentieren,
- Folgeaktivitäten einleiten.
Merke
Technische Fehleranalyse und ITIL ersetzen sich nicht.
Sie ergänzen sich.
Die Seitenarten dieses Buches
| Seitenart | Zweck |
|---|---|
| Grundlagenseite | erklärt Begriffe, Modelle und Zusammenhänge |
| Practice-Seite | beschreibt Ziel, Nutzen und Anwendung einer ITIL Practice |
| Praxisfall | zeigt eine realistische Arbeitssituation |
| Vorgehensweise | führt schrittweise durch eine Aufgabe |
| Entscheidungshilfe | unterstützt bei Auswahl, Priorisierung oder Eskalation |
| Checkliste | ermöglicht eine schnelle Kontrolle |
| Vorlage | liefert eine wiederverwendbare Dokumentationsstruktur |
| Schnellreferenz | fasst wichtige Informationen kompakt zusammen |
| Vergleichsseite | grenzt ähnliche Begriffe oder Vorgehensweisen voneinander ab |
| Glossarseite | erklärt Fachbegriffe und Abkürzungen |
Die Seitenart soll bereits durch Titel und Aufbau erkennbar sein.
Querverweise richtig verwenden
IT-Aufgaben lassen sich selten vollständig einem einzigen Thema zuordnen.
Ein fehlgeschlagener Anmeldevorgang kann beispielsweise folgende Bereiche betreffen:
- Incident Management,
- Active Directory,
- DNS,
- Kerberos,
- Netzwerk,
- Informationssicherheit,
- Monitoring,
- Fehleranalyse und Troubleshooting.
Querverweise helfen dabei:
- technische Vertiefungen zu finden,
- Zusammenhänge zu verstehen,
- doppelte Erklärungen zu vermeiden,
- und eine Aufgabe aus mehreren Perspektiven zu betrachten.
Grundsatz
Ein Querverweis soll eine konkrete Frage beantworten oder die nächste sinnvolle Vertiefung ermöglichen.
So verwendest du Checklisten
Checklisten helfen dabei, wichtige Punkte nicht zu vergessen.
Sie eignen sich besonders:
- vor Änderungen,
- bei wiederkehrenden Aufgaben,
- bei kritischen Störungen,
- für Eskalationen,
- bei Übergaben,
- und vor dem Abschluss eines Vorgangs.
Prüfe trotzdem immer:
- Passt der Punkt zur konkreten Umgebung?
- Ist die Maßnahme freigegeben?
- Besitzt du die erforderliche Berechtigung?
- Gibt es Sicherheits- oder Datenschutzanforderungen?
- Kann die Handlung den laufenden Betrieb beeinflussen?
- Ist ein Rückfallplan vorhanden?
- Muss ein Verantwortlicher eingebunden werden?
Arbeiten unter Zeitdruck
Bei einer kritischen Störung solltest du dich zuerst auf folgende Punkte konzentrieren:
- unmittelbare Sicherheitsrisiken berücksichtigen
- betroffenen Service bestimmen
- Auswirkung und Dringlichkeit feststellen
- Zuständigkeit und Eskalation klären
- Service stabilisieren oder wiederherstellen
- Beteiligte angemessen informieren
- wesentliche Maßnahmen dokumentieren
- Ursachenanalyse und Verbesserungen anschließend durchführen
Unter Zeitdruck kann die Dokumentation zunächst kompakt gehalten werden.
Wichtige Beobachtungen, Entscheidungen und Änderungen müssen dennoch erfasst werden.
Praxistipp
Notiere während einer Störung mindestens:
- Uhrzeit,
- Beobachtung,
- Maßnahme,
- Ergebnis.
Beispiel:
| Uhrzeit | Beobachtung | Maßnahme | Ergebnis |
|---|---|---|---|
| 09:12 Uhr | Webdienst nicht erreichbar | Dienststatus geprüft | Dienst gestoppt |
| 09:15 Uhr | Ursache noch unbekannt | Dienst gestartet | Service wieder erreichbar |
| 09:20 Uhr | Fehler trat nach einem Update auf | Problem Record angelegt | Ursachenanalyse folgt |
Das Buch ersetzt keine betrieblichen Vorgaben
Die Inhalte dieses Buches bieten Orientierung, Hintergrundwissen und praktische Unterstützung.
Im Unternehmen gelten zusätzlich:
- interne Richtlinien,
- Rollen und Berechtigungen,
- Sicherheitsvorgaben,
- Datenschutzbestimmungen,
- Freigabeprozesse,
- Eskalationswege,
- Verträge,
- Service Level Agreements,
- und Anweisungen verantwortlicher Personen.
Bei einem Widerspruch haben verbindliche rechtliche, sicherheitsrelevante und betriebliche Vorgaben Vorrang.
Schnellablauf bei einer konkreten Aufgabe
- Situation erfassen
- betroffenen Service bestimmen
- passende Seite finden
- Schnellübersicht prüfen
- Entscheidung oder Vorgehensweise auswählen
- technische Vertiefung nutzen
- Risiken und Eskalation beachten
- Ergebnis dokumentieren
- mögliche Verbesserung prüfen
Checkliste für die Nutzung des Buches
- Habe ich die konkrete Situation richtig verstanden?
- Weiß ich, welcher Service betroffen ist?
- Nutze ich die passende Seitenart?
- Habe ich Voraussetzungen und Berechtigungen geprüft?
- Habe ich Risiken und Sicherheitsaspekte beachtet?
- Benötige ich eine technische Vertiefung?
- Muss eine andere Person oder ein anderes Team eingebunden werden?
- Habe ich Schritte und Ergebnisse dokumentiert?
- Gibt es einen passenden Querverweis?
- Muss aus der Situation später Wissen oder eine Verbesserung entstehen?
Grafik vorgesehen
Nutzungsweg durch das Buch
Situation → passende Seite finden → Grundlagen verstehen → Vorgehensweise anwenden → Ergebnis dokumentieren → Verbesserung ableiten
Eine interaktive Version kann später typische Arbeitssituationen anbieten und auf die passenden Themenbereiche verweisen.
Verwandte Seiten
- 0.1 Über dieses Buch – Ziel, Arbeitsweise und Qualitätsmaßstab
- 0.3 Kennzeichnungen, Quellen und Versionsstände
- 0.4 Aktualisierungen, Versionspflege und Korrekturen
- 1.1 Warum professionelles Service Management notwendig ist
Quellen und Versionsstand
Diese Seite beschreibt die Nutzung und Struktur dieses unabhängigen Nachschlagewerks.
Die Versionshinweise zu Change Management und Incident Management orientieren sich an:
Fachlicher Stand: August 2026
0.4 Aktualisierungen, Versionspflege und Korrekturen
Kurz erklärt
Dieses Buch wird als langfristiges Nachschlagewerk aufgebaut.
Inhalte werden deshalb nicht nur einmal erstellt, sondern regelmäßig geprüft, aktualisiert und bei Bedarf korrigiert.
Dabei soll nachvollziehbar bleiben:
- wann eine Seite zuletzt fachlich geprüft wurde,
- auf welche Versionen sie sich bezieht,
- welche Inhalte verändert wurden,
- warum eine Änderung notwendig war,
- und welche Punkte noch nicht abschließend geklärt sind.
Warum eine kontinuierliche Pflege notwendig ist
IT-Wissen verändert sich.
Neue Versionen können:
- Begriffe verändern,
- Funktionen ergänzen,
- bisherige Vorgehensweisen ersetzen,
- Sicherheitsanforderungen verschärfen,
- Menüpfade ändern,
- Befehle erweitern oder entfernen,
- und neue technische Abhängigkeiten erzeugen.
Auch IT-Service-Management entwickelt sich weiter.
Zusätzlich können sich betriebliche Anforderungen verändern, beispielsweise durch:
- neue Services,
- andere Organisationsstrukturen,
- geänderte Verantwortlichkeiten,
- neue gesetzliche Anforderungen,
- Sicherheitsvorfälle,
- neue Herstellerprodukte,
- oder Erfahrungen aus dem laufenden Betrieb.
Grundsatz
Eine Wissensseite ist nicht endgültig abgeschlossen.
Sie beschreibt den fachlich geprüften Stand zu einem bestimmten Zeitpunkt.
Erstellung, Bearbeitung, Prüfung und Test unterscheiden
| Angabe | Bedeutung |
|---|---|
| Erstellt am | Datum, an dem die Seite erstmals angelegt wurde |
| Zuletzt bearbeitet | Datum der letzten inhaltlichen oder redaktionellen Änderung |
| Fachlich geprüft am | Datum der letzten vollständigen fachlichen Kontrolle |
| Technisch getestet am | Datum eines dokumentierten praktischen Tests |
| Behandelte Version | Version des Frameworks, Produkts oder Systems |
| Nächste Prüfung empfohlen | Zeitpunkt oder Anlass für eine erneute Kontrolle |
Eine reine Textkorrektur ist nicht automatisch eine vollständige fachliche Prüfung.
Beispiel
Am 10. August wurde ein Rechtschreibfehler behoben.
Die letzte vollständige fachliche Prüfung kann trotzdem weiterhin vom 1. August stammen.
Fachlicher Stand einer Seite
Am Ende wichtiger Seiten wird nach Möglichkeit ein fachlicher Stand angegeben.
**Fachlicher Stand:** August 2026
**Behandelte Hauptversion:** ITIL Version 5
**Zusätzlich berücksichtigt:** ITIL 4