0. ITIL - Über dieses Buch

0.1 Über dieses Buch – Ziel, Arbeitsweise und Qualitätsmaßstab

Kurz erklärt

Dieses Buch vermittelt Grundlagen und Zusammenhänge des professionellen IT-Service-Managements.

Es zeigt außerdem, wie Fachinformatiker für Systemintegration dieses Wissen im täglichen IT-Betrieb anwenden können.

Das Buch ist damit gleichzeitig:

Ziel dieses Buches

Dieses Buch verbindet fachliches ITIL-Wissen mit konkreten Situationen aus dem Arbeitsalltag eines Fachinformatikers für Systemintegration.

Es soll dabei helfen:

Das notwendige Fachwissen bildet dafür die Grundlage.

Der praktische Nutzen entscheidet darüber, wie dieses Wissen erklärt und aufbereitet wird.

Leitsatz

Wissen hilft dabei, Zusammenhänge zu verstehen.

Struktur hilft dabei, dieses Wissen im richtigen Moment richtig anzuwenden.

Für wen ist dieses Buch gedacht?

Das Buch richtet sich insbesondere an:

Die Inhalte berücksichtigen unterschiedliche Wissensstände.

Wissensstand Schwerpunkt
Einsteiger verständliche Grundlagen, Fachbegriffe und erste Praxisbeispiele
Fortgeschrittene Abläufe, Zusammenhänge, Entscheidungshilfen und technische Einordnung
Erfahrene Fachkräfte Schnellreferenzen, Risiken, Sonderfälle, Checklisten und Verbesserungsmöglichkeiten

Das Buch soll sowohl beim Lernen als auch später im beruflichen Alltag verwendet werden können.

Was dieses Buch vermitteln soll

Das Buch soll nicht nur Definitionen bereitstellen.

Es soll drei miteinander verbundene Fähigkeiten entwickeln:

  1. Verstehen
  2. Anwenden
  3. Erfahrung aufbauen

Diese Ebenen greifen ineinander.

Fachwissen ohne Anwendung bleibt theoretisch.

Anwendung ohne ausreichendes Verständnis kann zu Fehlern führen.

Erfahrung hilft dabei, Risiken, Zusammenhänge und Sonderfälle früher zu erkennen.

Die drei Wissensebenen

Ebene Leitfrage Inhalt
Verstehen Was ist das und warum ist es wichtig? Begriffe, Grundlagen, Ziele und Zusammenhänge
Anwenden Wie gehe ich konkret vor? Abläufe, Checklisten, Werkzeuge und Entscheidungshilfen
Erfahrung Was muss ich in der Praxis zusätzlich beachten? Risiken, typische Fehler, Sonderfälle und bewährte Vorgehensweisen

Nicht jede Seite muss alle drei Ebenen gleich ausführlich behandeln.

Es soll jedoch erkennbar sein, ob ein Abschnitt:

So arbeitet dieses Buch

Die Inhalte verbinden die drei Wissensebenen miteinander:

  1. Verstehen – Begriffe, Ziele und Zusammenhänge erfassen.
  2. Anwenden – Wissen in konkrete Handlungen und Entscheidungen übertragen.
  3. Erfahrung – Risiken, typische Fehler und Sonderfälle berücksichtigen.

Dadurch soll aus theoretischem Wissen eine sichere und nachvollziehbare Arbeitsweise entstehen.

Vom Wissen zur professionellen Arbeitsweise

Fachwissen → ITIL-Einordnung → Handlung → Dokumentation → Verbesserung

Interaktive Darstellung öffnen

Hinweis

Die statische Grafik enthält die Kernaussage vollständig.

Die interaktive Darstellung ergänzt weitere Erklärungen und Praxisbeispiele, ist für das Verständnis der Seite aber nicht zwingend erforderlich.

Warum ITIL für Systemintegratoren wichtig ist

Fachinformatiker für Systemintegration arbeiten nicht ausschließlich mit:

Zum Berufsalltag gehören ebenfalls:

Technisches Wissen beantwortet beispielsweise die Frage:

Wie untersuche und behebe ich einen ausgefallenen Dienst?

Service Management hilft zusätzlich bei folgenden Fragen:

Professionelle IT-Arbeit verbindet technische Kompetenz mit einer strukturierten und serviceorientierten Arbeitsweise.

Technische und organisatorische Perspektive

Viele Aufgaben eines Systemintegrators besitzen zwei unterschiedliche Perspektiven.

Perspektive Zentrale Frage
Technische Perspektive Wie untersuche, konfiguriere oder repariere ich das System?
Service-Management-Perspektive Wie ordne, priorisiere, koordiniere und dokumentiere ich die Arbeit?

Beispiel:

Ein Webserver ist nicht erreichbar.

Die technische Perspektive kann folgende Prüfungen umfassen:

Die Service-Management-Perspektive ergänzt:

Merke

Technische Fehleranalyse und Service Management ersetzen sich nicht.

Sie ergänzen sich.

Was ITIL leistet

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

Es unterstützt Organisationen unter anderem dabei:

ITIL ist kein starres Regelwerk.

Es schreibt nicht für jedes Unternehmen dieselben:

vor.

Die Inhalte müssen an den jeweiligen Kontext angepasst werden.

Grundsatz

ITIL soll die Wertschöpfung unterstützen.

Es soll keine unnötige Bürokratie erzeugen.

Was ITIL nicht leistet

ITIL ersetzt nicht:

ITIL erklärt beispielsweise nicht im Detail:

Das Framework hilft stattdessen dabei, technische Tätigkeiten sinnvoll zu:

Aktueller ITIL-Stand dieses Buches

Dieses Buch trägt absichtlich keine Versionsnummer im Titel.

ITIL wird weiterentwickelt, während ältere Versionen in Unternehmen weiterhin verbreitet sein können.

Für dieses Buch gelten deshalb folgende Regeln:

Beispiel:

ITIL Version 5 ITIL 4
Change Management Change Enablement

Beide Begriffe können in bestehenden Organisationen und Unterlagen vorkommen.

Innerhalb dieses Buches wird bei relevanten Unterschieden angegeben, auf welche Version sich eine Aussage bezieht.

Offizielle Inhalte und Praxiswissen unterscheiden

Das Buch unterscheidet verschiedene Informationsarten.

Informationsart Bedeutung
ITIL-Grundlage Begriff, Modell, Prinzip oder Practice aus dem offiziellen Framework
Offizielle Quelle Aussage aus einer offiziellen Veröffentlichung oder Herstellerdokumentation
Best Practice allgemein bewährte Vorgehensweise
Praxisempfehlung zusätzliche Empfehlung für den Arbeitsalltag
Praxisbeispiel vereinfachte Situation zur Erklärung
Community-Hinweis Erfahrungsbericht ohne gleichwertige offizielle Bestätigung
Eigener Test Ergebnis aus einer dokumentierten eigenen Testumgebung
Versionsabhängig Aussage kann sich durch eine neue Version verändern
Umgebungsabhängig Aussage gilt nur unter bestimmten Bedingungen
Sicherheitsrelevant Handlung kann Vertraulichkeit, Integrität oder Verfügbarkeit beeinflussen

Eine Praxisempfehlung wird nicht als offizielle ITIL-Vorgabe dargestellt.

Eine Community-Erfahrung wird nicht ohne Prüfung als allgemein gültige Lösung übernommen.

Eine technisch mögliche Handlung wird nicht automatisch als sicher oder betrieblich zulässig betrachtet.

Die 30-Sekunden-Regel

Eine Seite soll so aufgebaut sein, dass innerhalb von etwa 30 Sekunden erkennbar ist:

Dafür verwendet das Buch bevorzugt:

Die schnelle Orientierung darf nicht dazu führen, dass notwendiges Grundlagenwissen oder wichtige Einschränkungen fehlen.

Qualitätsmaßstab

Vor der Veröffentlichung oder einer größeren Überarbeitung wird insbesondere geprüft:

Wichtigste Kontrollfrage

Hilft diese Seite einem Fachinformatiker dabei, seinen Arbeitsalltag besser, sicherer oder effizienter zu bewältigen?

Eigenständigkeit und rechtlicher Hinweis

Dieses Buch ist eine unabhängige, öffentlich zugängliche Wissenssammlung.

Es ist:

Offizielle Inhalte werden in eigenen Worten zusammengefasst und durch selbst erstellte:

ergänzt.

ITIL® und PeopleCert® sind eingetragene Marken von PeopleCert International Limited.

Alle Rechte an den Marken und offiziellen Veröffentlichungen verbleiben bei den jeweiligen Rechteinhabern.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die praktischen Beispiele, Qualitätsregeln und Hinweise zur Nutzung dieses Buches sind redaktionelle Festlegungen dieses unabhängigen Nachschlagewerks.

Sie sind keine vorgeschriebenen ITIL-Prozesse.

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

0.2 So nutzt du dieses Buch

Kurz erklärt

Dieses Buch kann vollständig von Anfang bis Ende gelesen oder gezielt als Nachschlagewerk und praktische Arbeitshilfe verwendet werden.

Du musst nicht jedes Kapitel gelesen haben, bevor du mit einer konkreten Aufgabe arbeitest. Die Seiten sind so aufgebaut, dass zentrale 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 professionelles Service Management systematisch verstehen. Kapitel in der vorgesehenen Reihenfolge durcharbeiten.
Nachschlagen Du suchst eine Definition, Abgrenzung oder Entscheidungshilfe. Über Inhaltsverzeichnis, Suche oder Querverweise direkt 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 systematisches Verständnis empfiehlt sich folgende Reihenfolge:

  1. Grundlagen des professionellen Service Managements
  2. zentrale Begriffe wie Produkt, Service, Wert, Outcome, Kosten und Risiken
  3. Aufbau und Denkweise von ITIL
  4. Produkte, Services, Wertströme und Lebenszyklus
  5. Zusammenarbeit mit Benutzern, Kunden und weiteren Stakeholdern
  6. professionelle Ticketbearbeitung
  7. wichtige ITIL Practices
  8. typische Situationen aus dem IT-Betrieb
  9. 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, Output, Outcome, Kosten, Risiko und Stakeholder zu verstehen, bevor einzelne Practices und deren Zusammenwirken vertieft werden.

Merke

Die praktische Anwendung 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 jede Seite vollständig von oben bis unten lesen.

Orientiere dich zunächst an den folgenden Bereichen:

Gesuchte Information Geeigneter Abschnitt
schnelle Einordnung des Themas Kurz erklärt
Bedeutung eines Begriffs Grundlagen oder Schnellzusammenfassung
konkrete Arbeitsschritte Vorgehensweise
schnelle Kontrolle Checkliste
Auswahl zwischen mehreren Möglichkeiten Entscheidungshilfe
häufige Fehlentscheidungen Typische Fehler
mögliche Gefahren und Auswirkungen Risiken und Sicherheitsaspekte
zusätzliche Erfahrung aus der Praxis Praxistipp
wichtigste Kernaussage Merke
technische Vertiefung Verwandte Seiten
Herkunft einer Aussage Quellen und Versionsstand

Die wichtigsten Informationen stehen nach Möglichkeit weit oben auf der Seite.

Vertiefungen, Sonderfälle, Beispiele 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 schrittweise vor:

  1. konkrete Situation erfassen
  2. betroffenen Service bestimmen
  3. betroffene Benutzer und Auswirkungen ermitteln
  4. nach Service, Fehlermeldung oder beobachtetem Verhalten suchen
  5. passende Praxis- oder Schnellreferenzseite öffnen
  6. Voraussetzungen und wichtigste Rückfragen prüfen
  7. geeignete Vorgehensweise auswählen
  8. Sicherheits-, Eskalations- und Freigabekriterien beachten
  9. durchgeführte Schritte und Ergebnisse dokumentieren
  10. bei Bedarf technische Querverweise verwenden
  11. prüfen, ob eine weitere Untersuchung oder Verbesserung notwendig ist

Wichtig

Eine Checkliste unterstützt die Arbeit.

Sie ersetzt 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 vorgesehenen Standardservice. Service Request Management
Derselbe oder ein ähnlicher Fehler tritt wiederholt auf. Problem Management
Eine technische oder organisatorische Änderung soll durchgeführt werden. Change Management
Ein kritischer Incident beeinträchtigt einen wichtigen Service. Incident Management und betrieblicher Major-Incident-Ablauf
Eine Lösung soll dauerhaft für Kollegen verfügbar sein. Knowledge Management
Hardware, Software oder Lizenzen sollen verwaltet werden. IT Asset Management
Abhängigkeiten zwischen Services und Komponenten sollen erfasst werden. Service Configuration Management
Ein Monitoring-System erzeugt eine Meldung. Monitoring and Event Management
Ein externer Dienstleister muss eingebunden werden. Supplier Management
Vereinbarte Serviceziele werden nicht erreicht. Service Level Management
Eine Arbeitsweise oder ein Service soll verbessert werden. Continual Improvement
Ein sicherheitsrelevantes Ereignis wurde erkannt. Information Security Management und betriebliche Sicherheitsverfahren

Diese Zuordnung dient als erste Orientierung.

Eine Arbeitssituation kann mehrere Practices, technische Fachbereiche und betriebliche Verfahren gleichzeitig betreffen.

Hinweis

Ein Major Incident ist ein besonders schwerwiegender Incident.

Die Kriterien, Rollen, Kommunikationswege und Eskalationsverfahren dafür werden von der jeweiligen Organisation festgelegt.

Technische und serviceorientierte Perspektive verbinden

Viele Aufgaben eines Fachinformatikers für Systemintegration besitzen mindestens zwei Perspektiven.

Perspektive Zentrale Frage
Technische Perspektive Wie untersuche, konfiguriere oder repariere ich das System?
Serviceorientierte Perspektive Welche Auswirkungen bestehen und wie wird die Arbeit koordiniert, dokumentiert und bewertet?

Beispiel:

Ein Webserver ist nicht erreichbar.

Die technische Perspektive kann folgende Prüfungen umfassen:

Die serviceorientierte Perspektive ergänzt:

Merke

Technische Fehleranalyse und Service Management ersetzen sich nicht.

Sie ergänzen sich.

Die Seitenarten dieses Buches

Nicht jede Seite verfolgt denselben Zweck.

Seitenart Zweck
Grundlagenseite erklärt Begriffe, Modelle und Zusammenhänge
Practice-Seite beschreibt Zweck, Nutzen und Anwendung einer Management 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 wichtiger Punkte
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 möglichst bereits durch Titel und Aufbau erkennbar sein.

So erkennst du wichtige Hinweise

Im Buch werden wiederkehrende Kennzeichnungen verwendet.

Kennzeichnung Bedeutung
Kurz erklärt kompakte Einordnung des Themas
ITIL-Grundlage Begriff, Modell oder Inhalt aus dem offiziellen Framework
Offizielle Quelle Aussage aus einer offiziellen Veröffentlichung oder Dokumentation
Praxisbeispiel realistische oder vereinfachte Arbeitssituation
Vorgehensweise empfohlene Reihenfolge von Arbeitsschritten
Entscheidungshilfe Unterstützung bei einer konkreten Auswahl
Typischer Fehler häufige oder besonders relevante Fehlentscheidung
Risiko mögliche technische, organisatorische oder sicherheitsrelevante Folge
Praxistipp zusätzliche bewährte Empfehlung für den Arbeitsalltag
Merke zentrale Aussage zum schnellen Wiederholen
Checkliste Punkte zur direkten Kontrolle
Versionsabhängig Information kann sich durch neue Versionen verändern
Umgebungsabhängig Information gilt nur unter bestimmten Voraussetzungen
Verwandte Seiten passende Grundlagen oder Vertiefungen

Nicht jede Kennzeichnung wird auf jeder Seite verwendet.

Es werden nur Elemente eingesetzt, die für das jeweilige Thema einen tatsächlichen Nutzen bieten.

Querverweise richtig verwenden

IT-Aufgaben lassen sich selten vollständig einem einzigen Thema zuordnen.

Ein fehlgeschlagener Anmeldevorgang kann beispielsweise folgende Bereiche betreffen:

Querverweise helfen dabei:

Grundsatz

Ein Querverweis soll eine konkrete Frage beantworten oder die nächste sinnvolle Vertiefung ermöglichen.

So verwendest du die Suche

Beginne mit dem wichtigsten Begriff der Situation.

Geeignete Suchbegriffe können sein:

Falls ein Begriff keine passenden Ergebnisse liefert, suche zusätzlich:

Beispiel:

Statt ausschließlich nach Outlook zu suchen, können folgende Suchbegriffe hilfreicher sein:

So verwendest du Checklisten

Checklisten helfen dabei, wichtige Punkte nicht zu vergessen.

Sie eignen sich besonders:

Eine Checkliste ist jedoch keine automatische Handlungsanweisung.

Prüfe immer:

So verwendest du Vorlagen

Vorlagen stellen eine Ausgangsbasis dar.

Sie können beispielsweise verwendet werden für:

Vorlagen müssen an die tatsächliche Situation angepasst werden.

Nicht relevante Abschnitte können entfernt werden.

Fehlende Informationen müssen ergänzt werden.

Typischer Fehler

Eine vollständig ausgefüllte Vorlage ist nicht automatisch eine gute Dokumentation.

Entscheidend ist, ob ein anderer Mitarbeiter die Situation, die durchgeführten Schritte und die getroffenen Entscheidungen nachvollziehen kann.

Arbeiten unter Zeitdruck

Bei einem kritischen Incident solltest du dich zunächst auf folgende Punkte konzentrieren:

  1. unmittelbare Gefahren und Sicherheitsrisiken erkennen
  2. betroffenen Service bestimmen
  3. Auswirkungen und Dringlichkeit feststellen
  4. Zuständigkeit und Eskalation klären
  5. Service stabilisieren oder wiederherstellen
  6. Beteiligte angemessen informieren
  7. wesentliche Beobachtungen und Maßnahmen dokumentieren
  8. Erfolg der Wiederherstellung kontrollieren
  9. Ursachenanalyse und Verbesserungen anschließend durchführen

Unter Zeitdruck kann die Dokumentation zunächst kompakt gehalten werden.

Wichtige Beobachtungen, Entscheidungen und Änderungen müssen trotzdem erfasst werden.

Praxistipp

Notiere während eines Incidents mindestens:

Beispiel:

Uhrzeit Beobachtung Maßnahme Ergebnis
09:12 Uhr Webservice nicht erreichbar Dienststatus geprüft Dienst gestoppt
09:15 Uhr Ursache noch unbekannt Dienst kontrolliert gestartet Service wieder erreichbar
09:20 Uhr Störung trat nach einer Änderung auf weiterer Untersuchungsbedarf dokumentiert Ursachenanalyse folgt

Das Buch ersetzt keine betrieblichen Vorgaben

Die Inhalte dieses Buches bieten Orientierung, Hintergrundwissen und praktische Unterstützung.

Im tatsächlichen Unternehmen gelten zusätzlich:

Bei einem Widerspruch haben verbindliche rechtliche, sicherheitsrelevante und betriebliche Vorgaben Vorrang.

Empfohlener Schnellablauf

  1. Situation erfassen
  2. betroffenen Service bestimmen
  3. Auswirkungen und Dringlichkeit bewerten
  4. passende Seite finden
  5. Voraussetzungen und Risiken prüfen
  6. geeignete Vorgehensweise anwenden
  7. Ergebnis kontrollieren
  8. Arbeit dokumentieren
  9. notwendige Folgeaktivitäten einleiten
  10. Verbesserungspotenzial prüfen

Checkliste für die Nutzung des Buches

Nutzungsweg durch das Buch

Situation erfassen
↓
passende Seite finden
↓
Grundlagen und Voraussetzungen prüfen
↓
Vorgehensweise anwenden
↓
Ergebnis kontrollieren
↓
Arbeit dokumentieren
↓
Verbesserung ableiten

Eine spätere interaktive Darstellung kann typische Arbeitssituationen anbieten und direkt zu den passenden Themenbereichen führen.

Verwandte Seiten

Quellen und Versionsstand

Diese Seite beschreibt die Nutzung und den redaktionellen Aufbau dieses unabhängigen Nachschlagewerks.

Die dargestellten Nutzungswege, Seitenarten, Checklisten und Suchstrategien sind Festlegungen dieses Buchprojekts und keine vorgeschriebenen ITIL-Prozesse.

Offizielle ITIL-Begriffe und Practices werden auf den jeweiligen Fachseiten anhand aktueller offizieller Quellen erläutert.

Fachlicher Stand: August 2026

0.3 Kennzeichnungen, Quellen und Versionsstände

Kurz erklärt

Dieses Buch unterscheidet klar zwischen:

Dadurch soll erkennbar bleiben:

Warum diese Unterscheidung wichtig ist

Nicht jede hilfreiche Aussage besitzt dieselbe Herkunft, Verbindlichkeit oder Beweiskraft.

Ein offizieller ITIL-Begriff ist anders zu bewerten als:

Werden diese Informationsarten miteinander vermischt, kann der falsche Eindruck entstehen, dass:

Dieses Buch trennt deshalb möglichst klar zwischen Herkunft, Gültigkeit und praktischer Einordnung einer Information.

Grundsatz

Eine hilfreiche Empfehlung muss nicht unmittelbar aus ITIL stammen.

Sie muss jedoch als Empfehlung erkennbar sein und darf nicht als offizielle Framework-Vorgabe dargestellt werden.

Die verwendeten Kennzeichnungen

Kennzeichnung Bedeutung
ITIL-Grundlage Begriff, Modell, Prinzip, Practice oder andere Aussage aus dem offiziellen ITIL-Framework
Verbindliche Vorgabe gesetzliche, vertragliche, sicherheitsrelevante oder betriebliche Regel, die eingehalten werden muss
Offizielle Quelle Aussage aus einer offiziellen Veröffentlichung, Norm, Hersteller- oder Projektdokumentation
Best Practice allgemein bewährte Vorgehensweise, die an den jeweiligen Kontext angepasst werden muss
Praxisempfehlung zusätzliche Empfehlung dieses Buches für den Arbeitsalltag
Praxisbeispiel realistische oder vereinfachte Situation zur Erklärung eines Zusammenhangs
Community-Hinweis Erfahrungsbericht oder Lösungsansatz ohne gleichwertige offizielle Bestätigung
Eigener Test Erkenntnis aus einer dokumentierten eigenen Testumgebung
Versionsabhängig Aussage kann sich durch eine andere oder neuere Version verändern
Umgebungsabhängig Aussage gilt nur unter bestimmten technischen oder organisatorischen Bedingungen
Sicherheitsrelevant Information oder Handlung kann Vertraulichkeit, Integrität oder Verfügbarkeit beeinflussen
Betriebliche Vorgabe beachten interne Rollen, Berechtigungen, Prozesse oder Freigaben können Vorrang haben
Noch zu prüfen Aussage oder Sonderfall ist noch nicht ausreichend belegt
Veraltet Inhalt bezieht sich ausdrücklich auf einen älteren Stand
Archiviert Inhalt wird vorwiegend aus historischen Gründen aufbewahrt

Nicht jede Seite benötigt alle Kennzeichnungen.

Sie werden nur verwendet, wenn sie das Verständnis, die Bewertung oder die sichere Anwendung eines Inhalts verbessern.

ITIL-Grundlage

Die Kennzeichnung ITIL-Grundlage wird verwendet, wenn ein Inhalt unmittelbar aus dem offiziellen ITIL-Framework stammt oder einen offiziellen ITIL-Begriff sinngemäß erklärt.

Beispiele:

Beispiel:

ITIL-Grundlage

Incident Management dient dazu, die negativen Auswirkungen von Incidents zu verringern, indem der normale Servicebetrieb so schnell wie unter den jeweiligen Bedingungen sinnvoll wiederhergestellt wird.

Eine solche Aussage wird nicht ohne Kennzeichnung mit zusätzlichen technischen oder persönlichen Empfehlungen vermischt.

Wichtig

Eine sinngemäße Erklärung in eigenen Worten ist keine wörtliche offizielle Definition.

Wörtliche Definitionen müssen eindeutig als Zitat gekennzeichnet und urheberrechtlich zulässig verwendet werden.

Verbindliche Vorgabe

Verbindliche Vorgaben besitzen Vorrang vor allgemeinen Empfehlungen dieses Buches.

Dazu können gehören:

Beispiel:

Betriebliche Vorgabe beachten

Auch wenn eine technische Änderung einfach rückgängig gemacht werden könnte, darf sie nicht ohne die im Unternehmen vorgeschriebene Freigabe durchgeführt werden.

Merke

Technisch möglich bedeutet nicht automatisch:

Offizielle Quelle

Die Kennzeichnung Offizielle Quelle wird verwendet, wenn eine Aussage aus einer maßgeblichen Primärquelle stammt.

Dazu gehören beispielsweise:

Beispiele:

Thema Bevorzugte offizielle Quelle
ITIL-Begriff oder ITIL-Modell offizielle ITIL- oder PeopleCert-Veröffentlichung
Microsoft-Produkt Microsoft Learn oder offizielle Produktdokumentation
Linux-Befehl Manpage oder offizielle Projektdokumentation
Docker-Funktion offizielle Docker-Dokumentation
Netzwerkprotokoll maßgeblicher RFC oder veröffentlichter Standard
Sicherheitswarnung Hersteller, BSI, CERT oder zuständige Sicherheitsorganisation
Softwarekonfiguration offizielle Dokumentation der verwendeten Version
Hardwarefunktion offizielles Handbuch, Datenblatt oder Supportdokument des Herstellers

Wichtig

Eine offizielle Quelle ist grundsätzlich zu bevorzugen.

Sie muss jedoch die konkrete Aussage tatsächlich belegen.

Eine allgemeine Produktseite bestätigt beispielsweise nicht automatisch:

Primärquelle und Sekundärquelle

Eine Primärquelle stammt direkt von der für den Inhalt verantwortlichen Stelle.

Beispiele:

Eine Sekundärquelle erklärt, bewertet oder fasst Primärquellen zusammen.

Beispiele:

Sekundärquellen können beim Verständnis sehr hilfreich sein.

Bei konkreten, versionsabhängigen oder sicherheitsrelevanten Aussagen sollten sie nach Möglichkeit durch eine geeignete Primärquelle ergänzt werden.

Grundsatz

Zum Lernen kann eine gute Sekundärquelle besonders verständlich sein.

Zum Belegen einer konkreten Herstellerfunktion ist normalerweise die Primärquelle stärker.

Best Practice

Eine Best Practice ist eine bewährte Vorgehensweise, die sich in vielen vergleichbaren Situationen als sinnvoll erwiesen hat.

Sie ist nicht automatisch:

Beispiele:

Best Practice

Eine bewährte Vorgehensweise muss an Größe, Risiken, Anforderungen und technische Umgebung der jeweiligen Organisation angepasst werden.

Praxisempfehlung

Eine Praxisempfehlung ergänzt offizielle Framework- oder Herstellerinformationen um konkrete Hinweise für den Arbeitsalltag.

Beispiel:

Praxisempfehlung

Notiere während eines laufenden Incidents mindestens:

Dadurch lässt sich der Ablauf später wesentlich leichter rekonstruieren.

Diese Empfehlung ist sinnvoll, aber nicht automatisch eine wörtliche ITIL-Vorgabe.

Praxisempfehlungen werden verwendet, wenn sie:

Praxisbeispiel

Praxisbeispiele übertragen theoretische Inhalte auf realistische Arbeitssituationen.

Beispiel:

Praxisbeispiel

Nach einem nächtlichen Update können sich mehrere Benutzer nicht mehr anmelden.

Technisch muss die Ursache untersucht werden. Aus Sicht des Service Managements müssen zusätzlich Auswirkungen, Priorität, Kommunikation, Eskalation und Dokumentation berücksichtigt werden.

Praxisbeispiele sind keine vollständig vorgeschriebenen Musterlösungen.

Die tatsächliche Vorgehensweise hängt unter anderem ab von:

Community-Hinweis

Community-Beiträge können besonders bei seltenen Fehlern, undokumentierten Besonderheiten oder neuen Softwareproblemen hilfreich sein.

Mögliche Quellen sind:

Ein Community-Beitrag belegt jedoch nicht automatisch, dass:

Community-Hinweis

Ein Community-Beitrag kann einen wertvollen Lösungsansatz liefern.

Vor der Anwendung müssen Version, Umgebung, Risiken und mögliche Nebenwirkungen geprüft werden.

Community-Aussagen werden nach Möglichkeit mit:

abgeglichen.

Eigener Test

Die Kennzeichnung Eigener Test wird verwendet, wenn eine Aussage in einer kontrollierten Umgebung praktisch geprüft wurde.

Eine solche Angabe sollte möglichst enthalten:

Beispiel:

Eigener Test

Die beschriebene Funktion wurde unter der angegebenen Softwareversion in einer dokumentierten Testumgebung erfolgreich geprüft.

Das Ergebnis bestätigt nicht automatisch dasselbe Verhalten unter älteren Versionen, anderen Plattformen oder abweichenden Konfigurationen.

Merke

Ein erfolgreicher eigener Test belegt das beobachtete Verhalten der getesteten Umgebung.

Er beweist nicht automatisch eine allgemeine oder offiziell unterstützte Kompatibilität.

Offiziell unterstützt und technisch funktionsfähig unterscheiden

Eine Funktion kann technisch funktionieren, obwohl sie vom Hersteller nicht ausdrücklich als unterstützt dokumentiert ist.

Umgekehrt kann eine Funktion offiziell unterstützt werden, aber aufgrund einer fehlerhaften Konfiguration in einer bestimmten Umgebung nicht funktionieren.

Deshalb müssen folgende Aussagen getrennt werden:

Aussage Bedeutung
Offiziell dokumentiert Die Funktion wird in einer offiziellen Quelle beschrieben.
Offiziell unterstützt Der Hersteller nennt die betreffende Verwendung ausdrücklich als unterstützte Konfiguration.
Technisch getestet Die Funktion wurde in einer bestimmten Umgebung praktisch geprüft.
Von Benutzern berichtet Community-Mitglieder berichten über entsprechende Erfahrungen.
Vermutet Es besteht eine Annahme, aber noch kein ausreichender Beleg.

Typischer Fehler

Aus der Aussage „Es hat bei einem Benutzer funktioniert“ wird die Aussage „Der Hersteller unterstützt diese Konfiguration“.

Versionsabhängige Informationen

Technische und organisatorische Inhalte können sich durch neue Versionen verändern.

Dies betrifft beispielsweise:

Versionsabhängige Angaben werden deshalb nach Möglichkeit mit folgenden Informationen versehen:

Angabe Beispiel
Framework oder Produkt ITIL
behandelte Version Version 5
zusätzlich berücksichtigt ITIL 4
fachlich geprüft am August 2026
Quelle offizielle PeopleCert-Veröffentlichung
mögliche Abweichung ältere Begriffe können weiterhin verwendet werden

Aktueller ITIL-Versionsstand dieses Buches

Stand August 2026 ist ITIL Version 5 die aktuelle Generation des Frameworks.

ITIL 4 ist weiterhin relevant, da:

Dieses Buch verwendet deshalb folgende Regeln:

Versionsabhängig

Eine Organisation kann weiterhin Prozesse, Begriffe und Werkzeuge verwenden, die an ITIL 4 oder einer älteren ITIL-Ausgabe ausgerichtet sind.

Für die tägliche Arbeit ist deshalb neben dem aktuellen Framework-Stand auch die tatsächlich eingeführte Arbeitsweise der Organisation entscheidend.

ITIL Practices in Version 5

ITIL Version 5 verwendet weiterhin 34 Management Practices.

Diese werden in zwei Gruppen eingeordnet:

  1. Product and Service Management Practices
  2. General Management Practices

Die Practices wurden gegenüber ITIL 4 nicht vollständig ersetzt, sondern für die neue Version angepasst und neu eingeordnet.

Wichtig

Die Einordnung einer Practice in ITIL Version 5 darf nicht allein aus älteren ITIL-4-Übersichten übernommen werden.

Bei einer versionsabhängigen Aussage muss die aktuelle offizielle Quelle geprüft werden.

Framework-Version und betriebliche Umsetzung unterscheiden

Die verwendete ITIL-Version bestimmt nicht automatisch, wie eine Organisation arbeitet.

Organisationen können:

Beispiel:

Eine Organisation kann einen Vorgang intern als „Störungsticket“ bezeichnen, obwohl im ITIL-Kontext der Begriff Incident verwendet wird.

Eine andere Organisation kann für besonders schwerwiegende Incidents einen eigenen Major-Incident-Ablauf einsetzen.

Praxistipp

Prüfe beim Einstieg in eine Organisation:

Umgebungsabhängige Informationen

Eine technische Anleitung kann fachlich korrekt sein und trotzdem nicht zur eigenen Umgebung passen.

Mögliche Unterschiede sind:

Beispiel:

Umgebungsabhängig

Der Neustart eines einzelnen Dienstes kann in einer Testumgebung unkritisch sein.

In einem Cluster, einer Hochverfügbarkeitsumgebung oder einem Produktivsystem kann derselbe Schritt zusätzliche Auswirkungen verursachen.

Vor technischen Eingriffen muss deshalb geprüft werden:

Sicherheitsrelevante Inhalte

Sicherheitsrelevante Hinweise werden besonders gekennzeichnet.

Sie betreffen beispielsweise:

Sicherheitsrelevant

Eine technisch mögliche Handlung ist nicht automatisch zulässig oder sicher.

Vor der Durchführung müssen Berechtigung, Auswirkungen, Datenschutz, betriebliche Vorgaben und Wiederherstellungsmöglichkeiten geprüft werden.

Sicherheitsrelevante Anleitungen sollen nach Möglichkeit Informationen enthalten zu:

Bewertung von Quellen

Quellen werden nicht ausschließlich nach ihrer Bekanntheit bewertet.

Entscheidend ist, ob eine Quelle:

Als Orientierung gilt:

Rang Quellen- oder Vorgabenart
1 geltendes Recht, verbindliche Verträge und betriebliche Vorgaben
2 offizielle Normen, Standards und behördliche Anforderungen
3 offizielle ITIL- und PeopleCert-Veröffentlichungen
4 offizielle Hersteller- oder Projektdokumentation
5 dokumentierte Hersteller-Supportaussage
6 anerkannte Fachliteratur
7 dokumentierte und nachvollziehbare Best Practice
8 reproduzierbarer eigener Test
9 nachvollziehbarer Community-Bericht
10 unbestätigte Einzelmeinung oder Vermutung

Diese Reihenfolge ist keine starre Hierarchie für jeden Einzelfall.

Die geeignete Quelle hängt von der jeweiligen Aussage ab.

Beispiele:

Aktualität einer Quelle prüfen

Das Veröffentlichungs- oder Änderungsdatum einer Quelle ist wichtig, aber nicht allein entscheidend.

Eine neue Webseite kann ältere Informationen enthalten.

Eine ältere Quelle kann weiterhin gültige Grundlagen beschreiben.

Geprüft werden sollte:

Merke

Neu veröffentlicht bedeutet nicht automatisch fachlich aktueller.

Alt bedeutet nicht automatisch ungültig.

Wenn Quellen einander widersprechen

Widersprechen sich mehrere Quellen, wird nicht automatisch die zuerst gefundene Aussage übernommen.

Stattdessen wird geprüft:

  1. Welche Quelle ist primär oder offiziell?
  2. Auf welche Version bezieht sich die jeweilige Aussage?
  3. Wann wurde die Quelle veröffentlicht oder aktualisiert?
  4. Behandeln die Quellen wirklich dieselbe Funktion und Umgebung?
  5. Wurde eine ältere Empfehlung später ersetzt?
  6. Ist nur eine bestimmte Konfiguration betroffen?
  7. Kann die Abweichung reproduziert werden?
  8. Gibt es eine offizielle Stellungnahme?

Kann der Widerspruch nicht eindeutig geklärt werden, wird er sichtbar gekennzeichnet.

Noch zu prüfen

Die verfügbaren Quellen beschreiben unterschiedliche Ergebnisse.

Die Abweichung kann mit Version, Plattform oder Konfiguration zusammenhängen. Vor einer produktiven Anwendung ist eine zusätzliche Prüfung erforderlich.

Mindestangaben für Quellen

Eine Quelle sollte so angegeben werden, dass sie eindeutig wiedergefunden und bewertet werden kann.

Geeignete Angaben sind:

Beispiel:

Herausgeber: PeopleCert
Dokument: ITIL Foundation – Version 5
Behandelter Stand: ITIL Version 5
Fachlich geprüft: August 2026

Bei technischer Dokumentation zusätzlich:

Hersteller: Beispielhersteller
Produkt: Beispielsoftware
Version: 5.2
Dokument: Administrator Guide
Abschnitt: Backup and Restore
Fachlich geprüft: August 2026

Empfohlener Quellenblock am Seitenende

Je nach Inhalt kann am Ende einer Seite folgender Aufbau verwendet werden:

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende Quellen

Eigene Prüfung

Fachlicher Stand: …

Nicht benötigte Bereiche werden weggelassen.

Leere Felder oder nicht überprüfte Platzhalter dürfen nicht veröffentlicht werden.

Quellenlinks sollen möglichst:

Bei umfangreichen Dokumenten sollte zusätzlich der relevante Abschnitt angegeben werden.

Typischer Fehler

Als Quelle wird lediglich die Startseite eines Herstellers angegeben, obwohl die konkrete Aussage dort nicht auffindbar ist.

Umgang mit nicht mehr erreichbaren Quellen

Eine nicht mehr erreichbare Quelle macht eine Aussage nicht automatisch falsch.

Die Aussage muss jedoch erneut geprüft werden.

Mögliche Maßnahmen:

Ist keine ausreichende Quelle mehr verfügbar, wird dies kenntlich gemacht.

Noch zu prüfen

Die bisher verwendete Quelle ist nicht mehr erreichbar. Die Aussage muss anhand einer aktuellen Primärquelle erneut bewertet werden.

Änderungen und Korrekturen

Fehler, unklare Formulierungen und veraltete Informationen können trotz sorgfältiger Prüfung auftreten.

Werden sie erkannt, sollen sie nachvollziehbar korrigiert werden.

Bei wichtigen Änderungen können folgende Angaben ergänzt werden:

Datum Änderung Grund
01.08.2026 Seite erstmals erstellt Aufbau des Nachschlagewerks
späteres Datum Begriff an neue ITIL-Version angepasst offizielle Framework-Aktualisierung
späteres Datum technische Anleitung korrigiert geänderte Herstellerdokumentation
späteres Datum Praxisbeispiel präzisiert missverständliche Formulierung

Nicht jede kleine Rechtschreibkorrektur benötigt einen eigenen Eintrag.

Dokumentiert werden sollten vor allem Änderungen, die:

Grundsatz

Eine fachlich begründete Korrektur erhöht die Qualität des Buches.

Fehler sollen nachvollziehbar verbessert und nicht verborgen werden.

Kennzeichnung offener Inhalte

Noch nicht ausreichend geprüfte Inhalte werden nicht als gesicherte Aussagen dargestellt.

Beispiele:

Noch zu prüfen

Für diesen Punkt fehlt derzeit eine ausreichend eindeutige offizielle Quelle.

Versionsabhängig

Die beschriebene Funktion wurde bisher nur unter der angegebenen Version geprüft.

Community-Hinweis

Die beschriebene Lösung wird von mehreren Benutzern berichtet, ist jedoch nicht offiziell bestätigt.

Dadurch bleibt erkennbar, welche Aussagen ausreichend belegt sind und wo noch Unsicherheit besteht.

Keine Vermutung als Tatsache darstellen

Kann eine Aussage nicht ausreichend belegt werden, muss sie als Annahme oder offene Frage formuliert werden.

Ungeeignet:

Die Funktion wurde wahrscheinlich aus Sicherheitsgründen entfernt.

Geeignet:

Die Funktion ist in der aktuellen Dokumentation nicht mehr beschrieben.

Ob sie aus Sicherheitsgründen entfernt wurde, konnte anhand der verfügbaren offiziellen Quellen nicht bestätigt werden.

Merke

Eine plausible Erklärung ist noch kein belegter Sachverhalt.

Rechtlicher und markenbezogener Hinweis

Dieses Buch ist eine unabhängige Wissenssammlung.

Es ist:

Offizielle Begriffe und Konzepte werden in eigenen Worten erklärt und durch selbst erstellte Beispiele, Checklisten und Praxisempfehlungen ergänzt.

ITIL® ist eine eingetragene Marke der PeopleCert-Gruppe.

Die Nennung dient der sachlichen Beschreibung des behandelten Frameworks.

Dieses Buch ist nicht mit PeopleCert verbunden und wird nicht von PeopleCert geprüft, unterstützt oder herausgegeben.

Hinweis

Die Verwendung geschützter Logos, umfangreicher Originaltexte, offizieller Grafiken oder anderer urheberrechtlich geschützter Materialien kann zusätzlichen Bedingungen unterliegen.

Dieses Buch verwendet deshalb bevorzugt eigene Formulierungen, Tabellen, Beispiele und Darstellungen.

Checkliste für die fachliche Prüfung einer Seite

Schnellübersicht zur Quellenbewertung

Frage Bedeutung
Wer ist für die Aussage zuständig? passende Quelle bestimmen
Welche Version wird behandelt? Übertragbarkeit prüfen
Ist die Aussage direkt belegt? Fehlinterpretationen vermeiden
Wie aktuell ist der Inhalt? mögliche Änderungen erkennen
Gilt die Aussage für meine Umgebung? Fehlanwendung vermeiden
Ist die Funktion offiziell unterstützt? Supportstatus klären
Wurde die Aussage praktisch getestet? beobachtetes Verhalten nachvollziehen
Gibt es Risiken oder Einschränkungen? sichere Anwendung ermöglichen
Widersprechen sich Quellen? zusätzliche Prüfung durchführen

Quellen- und Verlässlichkeitsmodell

Verbindliche Vorgabe
↓
geeignete offizielle Primärquelle
↓
Hersteller- oder Projektdokumentation
↓
anerkannte Fachquelle oder Best Practice
↓
reproduzierbarer eigener Test
↓
nachvollziehbarer Community-Bericht
↓
unbestätigte Vermutung

Dieses Modell ist eine Orientierung und keine für jeden Fall starre Rangfolge.

Die benötigte Quellenart muss immer zur konkreten Aussage passen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Regeln zur Quellenbewertung, Dokumentation eigener Tests, Kennzeichnung von Community-Inhalten und Pflege dieses Buches sind redaktionelle Qualitätsregeln dieses unabhängigen Nachschlagewerks.

Sie sind keine vorgeschriebenen ITIL-Prozesse.

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

0.4 Aktualisierungen, Versionspflege und Korrekturen

Kurz erklärt

Dieses Buch wird als langfristiges Lern-, Arbeits- und Nachschlagewerk aufgebaut.

Inhalte werden deshalb nicht nur einmal erstellt, sondern regelmäßig geprüft, aktualisiert und bei Bedarf korrigiert.

Dabei soll nachvollziehbar bleiben:

Warum eine kontinuierliche Pflege notwendig ist

IT-Wissen verändert sich.

Neue Versionen können:

Auch digitales Produkt- und Service-Management entwickelt sich weiter.

Zusätzlich können sich betriebliche Anforderungen verändern, beispielsweise durch:

Ein dauerhaft hilfreiches Nachschlagewerk muss solche Veränderungen berücksichtigen.

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

Die folgenden Angaben beschreiben unterschiedliche Zustände einer Seite.

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
Bekannte Einschränkungen Bedingungen, unter denen eine Aussage möglicherweise nicht gilt
Offene Punkte noch nicht abschließend geklärte Fragen

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.

Ebenso ist eine fachlich geprüfte Anleitung nicht automatisch technisch getestet.

Eine technische Durchführung kann außerdem nur das Verhalten der tatsächlich verwendeten Testumgebung bestätigen.

Fachlicher Stand einer Seite

Am Ende einer Fachseite wird nach Möglichkeit ein fachlicher Stand angegeben.

Beispiel:

Fachlicher Stand: August 2026
Behandelte Hauptversion: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4

Bei technischen Seiten können weitere Angaben notwendig sein.

Beispiel:

Getestetes Betriebssystem: Ubuntu Server 24.04 LTS
Getestete Softwareversion: Beispielsoftware 5.2
Bereitstellungsart: Docker
Architektur: ARM64
Technisch getestet am: 01.08.2026

Die Angaben sollen dem Leser helfen einzuschätzen:

Merke

Das Bearbeitungsdatum einer Seite sagt allein noch nichts über ihre fachliche Aktualität aus.

Welche Inhalte besonders häufig geprüft werden müssen

Nicht jede Information verändert sich gleich schnell.

Informationsart Typischer Prüfungsanlass
grundlegende ITIL-Konzepte neue offizielle Framework-Veröffentlichung
offizielle Begriffe und Modelle Versionswechsel oder geänderte Definition
Practice-Beschreibungen neue oder überarbeitete offizielle Practice Guidance
technische Menüpfade neue Software- oder Firmwareversion
Befehle und Optionen Versions-, Betriebssystem- oder Plattformwechsel
Herstellerempfehlungen geänderte offizielle Dokumentation
Sicherheitsmaßnahmen neue Schwachstelle, Warnung oder Empfehlung
gesetzliche Anforderungen Änderung der Rechtslage
vertragliche Anforderungen neuer oder geänderter Vertrag
Community-Lösungen vor jeder produktiven Wiederverwendung
eigene Testergebnisse neue Version oder abweichende Umgebung
allgemeine technische Grundlagen fachlicher Anlass oder erkannter Fehler

Grundsatz

Je stärker eine Aussage von einer bestimmten Version, einem Hersteller oder einer aktuellen Sicherheitslage abhängt, desto häufiger muss sie geprüft werden.

Anlässe für eine Aktualisierung

Eine Seite sollte überprüft werden, wenn mindestens einer der folgenden Fälle eintritt:

Eine vollständige Überarbeitung ist nicht bei jeder kleinen Änderung notwendig.

Entscheidend ist, ob die Änderung:

beeinflusst.

Arten von Änderungen

Änderungen werden nach ihrer Bedeutung unterschieden.

Änderungsart Beispiel Änderungsvermerk
Redaktionelle Änderung Rechtschreibung, Formatierung oder bessere Lesbarkeit normalerweise nicht erforderlich
Kleine fachliche Präzisierung missverständliche Formulierung genauer erklärt kurzer Hinweis sinnvoll
Fachliche Korrektur falsche Definition oder Zuordnung berichtigt erforderlich
Technische Aktualisierung neuer Befehl, Menüpfad oder Versionshinweis erforderlich
Sicherheitsrelevante Korrektur riskante Empfehlung entfernt oder abgesichert deutlich dokumentieren
Strukturelle Überarbeitung Seite aufgeteilt, zusammengeführt oder neu eingeordnet Querverweise aktualisieren
Framework-Aktualisierung neue ITIL-Version berücksichtigt Versionshinweis erforderlich
Archivierung Inhalt gilt nur noch für ältere Systeme deutlich kennzeichnen

Redaktionelle Änderungen

Redaktionelle Änderungen verändern nicht die fachliche Bedeutung.

Dazu gehören beispielsweise:

Solche Änderungen benötigen normalerweise keinen ausführlichen Änderungsvermerk.

Das Datum der letzten Bearbeitung kann sich dennoch ändern.

Fachliche Präzisierungen

Eine fachliche Präzisierung ist notwendig, wenn eine Aussage grundsätzlich richtig, aber zu allgemein oder missverständlich formuliert ist.

Beispiel:

Unpräzise:

Die Priorität eines Incidents ergibt sich aus Auswirkung und Dringlichkeit.

Präziser:

Viele Organisationen verwenden Auswirkung und Dringlichkeit als Kriterien für die Priorisierung von Incidents. Die konkrete Bewertungsmethode und Prioritätsmatrix werden von der jeweiligen Organisation festgelegt.

Die Präzisierung verhindert den falschen Eindruck, dass jede Organisation zwingend dieselbe Berechnung oder Matrix verwenden müsse.

Fachliche Korrekturen

Wird eine fachlich falsche Aussage erkannt, wird nicht nur der einzelne Satz ersetzt.

Zusätzlich muss geprüft werden:

Wichtig

Bei sicherheitsrelevanten oder potenziell schädlichen Fehlern hat die Korrektur Vorrang vor redaktionellen Verbesserungen.

Wesentliche Fehler nicht stillschweigend verbergen

Kleine sprachliche Fehler können ohne gesonderten Hinweis korrigiert werden.

Wesentliche fachliche Änderungen sollen nachvollziehbar bleiben.

Ein Änderungsvermerk ist insbesondere sinnvoll, wenn:

Beispiel:

Änderung vom 12.08.2026

Die bisherige Aussage zur Priorisierung wurde präzisiert.

Prioritäten werden nicht allein anhand der technischen Schwere eines Fehlers bestimmt. Die jeweilige Organisation legt fest, welche Kriterien verwendet und wie diese bewertet werden.

Grundsatz

Eine nachvollziehbare Korrektur erhöht die Qualität und Glaubwürdigkeit eines Nachschlagewerks.

Änderungsprotokoll

Bei umfangreichen, häufig verwendeten oder besonders wichtigen Seiten kann ein kompaktes Änderungsprotokoll geführt werden.

Datum Art Änderung Grund
01.08.2026 Ersterstellung Seite angelegt Aufbau des Nachschlagewerks
12.08.2026 Präzisierung Begriff genauer abgegrenzt missverständliche Formulierung
20.09.2026 Aktualisierung neue Framework-Version berücksichtigt offizielle Veröffentlichung
05.10.2026 Korrektur Handlungsempfehlung ersetzt Abgleich mit einer Primärquelle

Nicht jede Rechtschreib- oder Formatierungsänderung benötigt einen Eintrag.

Dokumentiert werden vor allem Änderungen, die:

Empfohlener Änderungsvermerk

Für wichtige Änderungen kann folgende Struktur verwendet werden:

Änderungsvermerk

Datum:
Art der Änderung:
Betroffener Abschnitt:
Bisherige Aussage:
Korrigierte Aussage:
Grund der Änderung:
Verwendete Quelle:
Auswirkung auf andere Seiten:

Nicht benötigte Felder können weggelassen werden.

Umgang mit unterschiedlichen ITIL-Versionen

Bei einer neuen ITIL-Version wird nicht automatisch der gesamte ältere Inhalt gelöscht.

Stattdessen wird geprüft:

  1. Ist die bisherige Aussage weiterhin fachlich gültig?
  2. Wurde nur die Bezeichnung geändert?
  3. Hat sich die Definition verändert?
  4. Wurde ein Modell ersetzt, erweitert oder neu eingeordnet?
  5. Wird die ältere Version weiterhin in Organisationen verwendet?
  6. Ist die Unterscheidung für Praxis oder Prüfung relevant?
  7. Muss eine Vergleichstabelle ergänzt werden?
  8. Sind Querverweise oder Seitentitel betroffen?

Beispiel:

Versionshinweis

In ITIL Version 5 heißt die Practice Change Management.

In ITIL 4 wurde sie Change Enablement genannt.

Älteres Wissen kann erhalten bleiben, wenn es weiterhin relevant ist und eindeutig einer Version zugeordnet wird.

Typischer Fehler

Ein gleich oder ähnlich klingender Begriff wird ohne Prüfung als vollständig identisch mit dem Begriff einer anderen Version behandelt.

Umgang mit technischen Versionen

Technische Anleitungen werden nach Möglichkeit auf eine konkrete Umgebung bezogen.

Beispiel:

Getestete Umgebung

Bei einer neuen Version ist unter anderem zu prüfen:

Eine Anleitung ist nicht allein deshalb aktuell, weil die Seite kürzlich bearbeitet wurde.

Fachlich geprüft und technisch getestet

Diese beiden Angaben dürfen nicht gleichgesetzt werden.

Status Aussage
Fachlich geprüft Die Aussagen wurden mit geeigneten Quellen und Fachwissen kontrolliert.
Technisch getestet Die beschriebene Durchführung wurde in einer dokumentierten Umgebung praktisch geprüft.

Eine Anleitung kann fachlich korrekt sein, ohne in der eigenen Umgebung getestet worden zu sein.

Ein erfolgreicher Test kann wiederum nur das Verhalten der getesteten Umgebung bestätigen.

Er beweist nicht automatisch:

Merke

Ein Test beantwortet die Frage: „Was ist in dieser Umgebung passiert?“

Eine offizielle Herstellerangabe beantwortet die Frage: „Was wird offiziell beschrieben oder unterstützt?“

Umgebungsabhängige Inhalte

Eine Anleitung kann fachlich richtig sein und trotzdem nicht zur eigenen Umgebung passen.

Mögliche Unterschiede bestehen bei:

Vor der Übernahme einer technischen Anleitung muss deshalb geprüft werden:

Veraltete Inhalte

Veraltete Inhalte werden nicht immer sofort gelöscht.

Sie können weiterhin hilfreich sein, wenn:

Solche Inhalte müssen eindeutig gekennzeichnet werden.

Veraltet

Die folgende Vorgehensweise bezieht sich auf eine ältere Produktversion.

Sie darf nicht ungeprüft auf aktuelle Systeme übertragen werden.

Situation Maßnahme
Inhalt ist weiterhin nützlich ältere Version deutlich angeben
Inhalt ist nur historisch relevant archivieren
Inhalt ist fachlich falsch korrigieren oder entfernen
Inhalt ist sicherheitsgefährdend sofort entfernen und Korrekturhinweis ergänzen
aktuelle Alternative vorhanden direkt auf die neue Vorgehensweise verweisen
mehrere Versionen werden verwendet Inhalte eindeutig voneinander trennen

Archivieren statt unkontrolliert löschen

Eine ältere Seite kann weiterhin Informationen enthalten, die für folgende Aufgaben wichtig sind:

Vor dem Löschen sollte deshalb geprüft werden:

Praxistipp

Veraltete Inhalte dürfen nicht unauffällig zwischen aktuellen Anleitungen stehen.

Eine eindeutige Archiv- oder Versionskennzeichnung verhindert Fehlanwendungen.

Offene und noch nicht abschließend geprüfte Punkte

Nicht jeder Sachverhalt kann sofort vollständig geklärt werden.

Offene Punkte dürfen dokumentiert werden, müssen aber eindeutig erkennbar sein.

Noch zu prüfen

Für diesen Sonderfall liegt derzeit keine ausreichend eindeutige offizielle Quelle vor.

Vor einer produktiven Anwendung ist eine zusätzliche Prüfung erforderlich.

Ein offener Punkt sollte möglichst enthalten:

Ungeeignet ist eine unklare Notiz wie:

Später noch einmal prüfen.

Besser ist:

Zu prüfen ist, ob die Funktion ab Version 5.2 auch auf ARM64 offiziell unterstützt wird. Bisher liegt nur ein Community-Bericht vor.

Prüfstatus einer Seite

Für umfangreiche oder kritische Inhalte können folgende Statusangaben verwendet werden:

Status Bedeutung
Entwurf Inhalt befindet sich noch im Aufbau
In Prüfung fachliche Kontrolle ist noch nicht abgeschlossen
Fachlich geprüft Inhalt wurde gegen geeignete Quellen geprüft
Technisch getestet praktische Durchführung wurde dokumentiert getestet
Aktualisierung erforderlich Inhalt könnte nicht mehr aktuell sein
Veraltet Inhalt bezieht sich ausdrücklich auf einen älteren Stand
Archiviert Inhalt wird hauptsächlich aus historischen Gründen aufbewahrt

Ein Status darf nur verwendet werden, wenn seine Voraussetzungen erfüllt sind.

Eine automatisch erzeugte oder oberflächlich gelesene Seite gilt nicht als vollständig fachlich geprüft.

Wann eine erneute Prüfung erforderlich ist

Eine Seite sollte erneut geprüft werden, wenn:

Zusätzlich kann eine anlassbezogene Prüfung sinnvoll sein:

Seitenart Geeigneter Prüfungsanlass
ITIL-Grundlagen neue offizielle Framework-Version
Practice-Seiten neue oder überarbeitete Practice Guidance
Sicherheitsrelevante Anleitung neue Schwachstelle oder Sicherheitsempfehlung
Softwareanleitung relevante neue Hauptversion
Herstellerabhängige Konfiguration neue Firmware oder geänderte Dokumentation
Community-basierte Lösung vor jeder produktiven Verwendung
Checkliste nach realer Anwendung und festgestellten Lücken
Vorlage bei geänderten betrieblichen Anforderungen

Risikobasierte Priorisierung von Aktualisierungen

Nicht alle veralteten Seiten sind gleich dringend.

Die Aktualisierung sollte zuerst dort erfolgen, wo ein Fehler große Auswirkungen verursachen kann.

Priorität Typische Inhalte
Sehr hoch Sicherheitsmaßnahmen, Wiederherstellung, Berechtigungen und produktive Änderungen
Hoch Incident-Bearbeitung, Eskalation, Backup, Change und Notfallverfahren
Mittel Produktkonfigurationen, technische Anleitungen und Menüpfade
Niedrig allgemeine Beispiele, stilistische Verbesserungen und historische Informationen

Ein veralteter Screenshot besitzt normalerweise eine geringere Priorität als eine fehlerhafte Anleitung zur Wiederherstellung eines Backups.

Grundsatz

Aktualisierungen werden nicht nur nach Alter, sondern vor allem nach Risiko und möglicher Auswirkung priorisiert.

Meldung eines möglichen Fehlers

Eine Fehlermeldung sollte möglichst konkrete Informationen enthalten.

Hilfreich sind:

Beispiel:

Möglicher Fehler

Seite: Change Management
Abschnitt: Standard Change
Problem: Die Formulierung kann so verstanden werden, dass jeder Standard Change vor jeder Durchführung erneut genehmigt werden muss.
Vorgeschlagene Prüfung: Definition und Freigabemodell anhand der aktuellen offiziellen Practice Guidance vergleichen.

Eine Fehlermeldung führt nicht automatisch zu einer Änderung.

Sie löst zunächst eine fachliche Prüfung aus.

Ablauf einer fachlichen Korrektur

Vorgehensweise

  1. möglichen Fehler dokumentieren
  2. betroffene Aussage eingrenzen
  3. bisherige Quelle prüfen
  4. geeignete Primärquellen vergleichen
  5. Version und Umgebung berücksichtigen
  6. Auswirkungen auf andere Inhalte prüfen
  7. Korrektur formulieren
  8. Änderungsvermerk ergänzen
  9. Querverweise, Tabellen und Checklisten aktualisieren
  10. fachlichen Stand anpassen

Ablauf einer Versionsaktualisierung

Vorgehensweise

  1. neue Version und offizielle Änderungen erfassen
  2. betroffene Seiten identifizieren
  3. Begriffe, Definitionen und Modelle vergleichen
  4. technische oder organisatorische Auswirkungen bewerten
  5. weiterhin gültige Inhalte bestimmen
  6. veraltete Inhalte aktualisieren oder archivieren
  7. Praxisbeispiele und Entscheidungshilfen prüfen
  8. Checklisten und Vorlagen anpassen
  9. Quellen und Querverweise aktualisieren
  10. Versions- und Änderungsvermerk ergänzen

Checkliste vor einer Aktualisierung

Checkliste nach einer Aktualisierung

Empfohlener Abschluss einer Fachseite

Je nach Inhalt kann eine Seite mit folgenden Angaben enden:

Quellen und Versionsstand

Behandelte Hauptversion:
Zusätzlich berücksichtigt:
Fachlich geprüft am:
Technisch getestet am:
Bekannte Einschränkungen:
Offene Punkte:
Nächste Prüfung empfohlen:

Nur tatsächlich benötigte und korrekt ausgefüllte Angaben werden übernommen.

Leere Felder sollen nicht veröffentlicht werden.

Lebenszyklus einer Wissensseite

Erstellen
↓
fachlich prüfen
↓
veröffentlichen
↓
anwenden und Rückmeldungen sammeln
↓
erneut prüfen
↓
aktualisieren, korrigieren oder archivieren

Die praktische Nutzung einer Seite kann neue Erkenntnisse liefern.

Diese Erkenntnisse fließen anschließend wieder in die Prüfung und Verbesserung des Inhalts ein.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Diese Seite beschreibt die redaktionelle und fachliche Pflege dieses unabhängigen Nachschlagewerks.

Die dargestellten Prüf-, Änderungs-, Dokumentations- und Archivierungsabläufe sind Regeln dieses Buchprojekts und keine vorgeschriebenen ITIL-Prozesse.

Sie orientieren sich an bewährten Grundsätzen wie:

ITIL Version 5 behandelt Continual Improvement weiterhin als grundlegenden Bestandteil des Frameworks und verwendet ein weiterentwickeltes Continual Improvement Model.

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