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:

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 möglicherweise 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 verändern,
Menüpfade anpassen,
Befehle erweitern oder entfernen,
Standards aktualisieren,
und neue technische Abhängigkeiten erzeugen.

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

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

neue Produkte und Services,
andere Organisationsstrukturen,
geänderte Verantwortlichkeiten,
neue gesetzliche oder vertragliche Anforderungen,
Sicherheitsvorfälle,
neue Herstellerprodukte,
veränderte Lieferantenbeziehungen,
oder Erfahrungen aus dem laufenden Betrieb.

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:

wie aktuell die Information ist,
für welche Version sie gilt,
ob sie praktisch getestet wurde,
und ob sie zur eigenen Umgebung passt.

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 neue ITIL-Version erscheint.
Eine offizielle Definition wird geändert.
Eine Management Practice wird überarbeitet.
Ein Hersteller veröffentlicht eine relevante neue Version.
Eine verwendete Funktion wird als veraltet gekennzeichnet.
Ein Befehl oder Menüpfad funktioniert nicht mehr.
Eine Sicherheitslücke oder Sicherheitswarnung wird bekannt.
Eine verwendete Quelle wird entfernt oder ersetzt.
Eine Empfehlung erweist sich als unvollständig oder ungeeignet.
Eine technische Anleitung liefert in der Praxis ein anderes Ergebnis.
Ein Praxisfall zeigt einen bislang nicht berücksichtigten Sonderfall.
Ein Leser meldet einen möglichen Fehler.
Andere Seiten enthalten widersprüchliche Angaben.
Eine betriebliche Erfahrung liefert eine bessere Vorgehensweise.

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

Entscheidend ist, ob die Änderung:

das fachliche Verständnis,
die praktische Vorgehensweise,
die Sicherheit,
das Risiko,
die Gültigkeit einer Aussage,
oder das erwartete Ergebnis

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:

Rechtschreibkorrekturen,
bessere Satzstruktur,
einheitliche Formatierung,
übersichtlichere Tabellen,
verbesserte Verlinkungen,
und verständlichere Überschriften.

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:

Hat der Fehler andere Abschnitte beeinflusst?
Verweisen andere Seiten auf die falsche Aussage?
Ist eine Tabelle oder Checkliste betroffen?
Wurde daraus eine Handlungsempfehlung abgeleitet?
Kann die Aussage ein Sicherheitsrisiko verursachen?
Muss ein Praxisbeispiel angepasst werden?
Muss ein Versionshinweis ergänzt werden?
Müssen Suchbegriffe oder Seitentitel geändert 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:

eine frühere Aussage fachlich falsch war,
sich eine offizielle Definition geändert hat,
eine Empfehlung nicht mehr unterstützt wird,
eine Sicherheitsgefahr bestand,
eine technische Anleitung ersetzt wurde,
sich eine Versionszuordnung geändert hat,
oder sich die Bedeutung eines Abschnitts wesentlich verändert hat.

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:

eine fachliche Aussage verändern,
eine Handlungsempfehlung betreffen,
ein Sicherheitsrisiko korrigieren,
einen Versionswechsel berücksichtigen,
oder die Bedeutung eines Abschnitts wesentlich verändern.

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:

Ist die bisherige Aussage weiterhin fachlich gültig?
Wurde nur die Bezeichnung geändert?
Hat sich die Definition verändert?
Wurde ein Modell ersetzt, erweitert oder neu eingeordnet?
Wird die ältere Version weiterhin in Organisationen verwendet?
Ist die Unterscheidung für Praxis oder Prüfung relevant?
Muss eine Vergleichstabelle ergänzt werden?
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

Betriebssystem: Debian 13

Anwendung: Beispielsoftware 4.2

Bereitstellung: Docker

Architektur: ARM64

Testdatum: 01.08.2026

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

Existiert der Befehl weiterhin?
Wurde eine Option umbenannt?
Hat sich ein Standardpfad verändert?
Gibt es neue Voraussetzungen?
Wurde eine Funktion entfernt?
Hat sich das Berechtigungsmodell geändert?
Sind neue Abhängigkeiten entstanden?
Hat sich das unterstützte Betriebssystem geändert?
Sind neue Sicherheitsrisiken bekannt?
Funktioniert die Rückfall- oder Wiederherstellungsmethode weiterhin?

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:

eine offizielle Unterstützung,
eine allgemeine Kompatibilität,
ein identisches Verhalten unter anderen Versionen,
oder die Eignung für jede Produktivumgebung.

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:

Betriebssystem,
Softwareversion,
Hardwarearchitektur,
Cloud- oder On-Premises-Betrieb,
Hochverfügbarkeitskonzept,
Netzwerkaufbau,
Berechtigungsmodell,
Sicherheitsrichtlinien,
Mandantenstruktur,
verwendeten Erweiterungen,
und externen Abhängigkeiten.

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

Gilt sie für die verwendete Version?
Ist die Plattform identisch?
Sind die Voraussetzungen erfüllt?
Bestehen zusätzliche Abhängigkeiten?
Wird eine Freigabe benötigt?
Gibt es eine Testmöglichkeit?
Ist ein Rückfallplan vorhanden?
Wie wird der Erfolg kontrolliert?

Veraltete Inhalte

Veraltete Inhalte werden nicht immer sofort gelöscht.

Sie können weiterhin hilfreich sein, wenn:

ältere Systeme noch produktiv eingesetzt werden,
eine Migration vorbereitet wird,
historische Tickets untersucht werden,
alte Dokumentationen verstanden werden müssen,
frühere Entscheidungen nachvollzogen werden sollen,
oder eine ältere Prüfungsversion behandelt wird.

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:

Wartung von Altsystemen,
Analyse früherer Störungen,
Verständnis alter Konfigurationen,
Migrationen,
Audits,
und Nachvollziehen früherer Entscheidungen.

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

Wird die Information noch benötigt?
Gibt es produktive Systeme mit dieser Version?
Verweisen andere Seiten darauf?
Ist die Historie für einen späteren Vergleich hilfreich?
Enthält die Seite noch gültige Teilinformationen?
Kann sie eindeutig als veraltet oder archiviert gekennzeichnet 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:

die konkrete Fragestellung,
bisherige Erkenntnisse,
die fehlende Information,
benötigte Quelle oder Testumgebung,
mögliche Risiken,
und den nächsten Prüfschritt.

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:

die angegebene Version nicht mehr aktuell ist,
eine neue offizielle Veröffentlichung vorliegt,
ein möglicher Fehler gemeldet wurde,
eine verwendete Quelle nicht mehr erreichbar ist,
der Hersteller seine Dokumentation geändert hat,
eine Handlung in der Praxis ein anderes Ergebnis liefert,
neue Sicherheitsinformationen vorliegen,
andere Seiten widersprüchliche Angaben enthalten,
oder sich die betriebliche Umgebung wesentlich verändert hat.

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:

betroffene Seite,
betroffener Abschnitt,
vermuteter Fehler,
verwendete Quelle,
behandelte Version,
technische Umgebung,
beobachtetes Verhalten,
und eine mögliche Korrektur.

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

möglichen Fehler dokumentieren

betroffene Aussage eingrenzen

bisherige Quelle prüfen

geeignete Primärquellen vergleichen

Version und Umgebung berücksichtigen

Auswirkungen auf andere Inhalte prüfen

Korrektur formulieren

Änderungsvermerk ergänzen

Querverweise, Tabellen und Checklisten aktualisieren

fachlichen Stand anpassen

Ablauf einer Versionsaktualisierung

Vorgehensweise

neue Version und offizielle Änderungen erfassen

betroffene Seiten identifizieren

Begriffe, Definitionen und Modelle vergleichen

technische oder organisatorische Auswirkungen bewerten

weiterhin gültige Inhalte bestimmen

veraltete Inhalte aktualisieren oder archivieren

Praxisbeispiele und Entscheidungshilfen prüfen

Checklisten und Vorlagen anpassen

Quellen und Querverweise aktualisieren

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

0.1 Über dieses Buch – Ziel, Arbeitsweise und Qualitätsmaßstab
0.2 So nutzt du dieses Buch
0.3 Kennzeichnungen, Quellen und Versionsstände
1.1 Warum professionelles Service Management notwendig ist
Continual Improvement
Knowledge Management
Service Configuration Management
IT Asset Management

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:

Arbeiten mit verlässlichen Informationen,
Lernen aus Rückmeldungen,
risikobasierter Priorisierung,
Versionskontrolle,
und kontinuierlicher Verbesserung.

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

Revision #2
Created 1 August 2026 19:24:06 by Admin
Updated 1 August 2026 21:01:10 by Admin