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 ~~verschärfen,~~verändern,
Menüpfade ~~ändern,~~anpassen,
Befehle erweitern oder entfernen,

Standards aktualisieren,
und neue technische Abhängigkeiten erzeugen.

Auch ~~IT-~~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.

~~Unterschied~~Erstellung, ~~zwischen Erstellung,~~Bearbeitung, Prüfung und ~~Aktualisierung~~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:~~Beispiel

Am 10. August wurde ein Rechtschreibfehler behoben.

Die letzte vollständige fachliche Prüfung ~~stammt~~kann ~~jedoch~~trotzdem weiterhin vom 1. ~~August.~~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 ~~wichtiger~~einer ~~Seiten~~Fachseite wird nach Möglichkeit ein fachlicher Stand angegeben.

Beispiel:

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

Ä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

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

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.

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

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

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

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

** 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 Welche konkrete Aussage muss geprüft werden? Was hat sich verändert? Gibt es eine geeignete Primärquelle? Auf welche Version bezieht sich die Änderung? Ist die bisherige Aussage teilweise weiterhin gültig? Sind Praxisbeispiele betroffen? Müssen Tabellen, Checklisten oder Vorlagen angepasst werden? Entstehen neue Sicherheitsrisiken? Verweisen andere Seiten auf den betroffenen Inhalt? Muss die alte Version erhalten bleiben? Ist ein Änderungsvermerk erforderlich? Wurde der neue fachliche Stand angegeben? Checkliste nach einer Aktualisierung Ist die neue Aussage fachlich eindeutig? Wurde die richtige Version angegeben? Sind ältere Inhalte klar gekennzeichnet? Wurden alle betroffenen Querverweise geprüft? Wurden Tabellen, Checklisten und Vorlagen angepasst? Wurden technische Beispiele erneut geprüft? Sind Voraussetzungen und Risiken berücksichtigt? Wurden die Quellen aktualisiert? Wurde das Änderungsdatum eingetragen? Kann ein Leser nachvollziehen, warum die Änderung erfolgte? Wurden sichtbare Platzhalter oder interne Bearbeitungshinweise entfernt? 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 PeopleCert: ITIL Foundation – Version 5 PeopleCert: ITIL Foundation Version 5 – What’s New? ITIL: ITIL Foundation – Version 5 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