0.3 Kennzeichnungen, Quellen und Versionsstände

Kurz erklärt

Dieses Buch unterscheidet klar zwischen:

offiziellen ITIL-Inhalten,

verbindlichen Vorgaben,

technischen Herstellerinformationen,

anerkannten Standards,

allgemeinen Best Practices,

zusätzlichen Praxisempfehlungen,

Community-Erfahrungen,

und eigenen Tests.

Dadurch soll erkennbar bleiben:

woher eine Aussage stammt,

wie belastbar sie ist,

für welche Version und Umgebung sie gilt,

und ob sie vor einer praktischen Anwendung zusätzlich geprüft werden muss.

Warum diese Unterscheidung wichtig ist

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

Ein offizieller ITIL-Begriff ist anders zu bewerten als:

eine interne Arbeitsanweisung,
eine Herstellerdokumentation,
eine allgemeine Empfehlung für den IT-Betrieb,
ein Beitrag in einem Fachforum,
oder ein Ergebnis aus einer eigenen Testumgebung.

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

eine persönliche Empfehlung eine offizielle ITIL-Vorgabe sei,
ein einzelner erfolgreicher Test eine allgemein unterstützte Funktion beweise,
ein Community-Beitrag für jede Version gelte,
oder eine allgemeine Herstellerseite eine konkrete technische Aussage bestätige.

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:

Service
Wert
Outcome
Guiding Principles
ITIL Value System
vier Dimensionen
Management Practices
Continual Improvement
Product and Service Lifecycle

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:

Gesetze,
Verordnungen,
behördliche Auflagen,
Verträge,
Datenschutzanforderungen,
Sicherheitsrichtlinien,
betriebliche Arbeitsanweisungen,
genehmigte Notfallverfahren,
Rollen- und Berechtigungskonzepte,
sowie verbindliche Freigabeprozesse.

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:

erlaubt,

freigegeben,

sicher,

vertraglich zulässig,

oder für die Produktivumgebung geeignet.

Offizielle Quelle

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

Dazu gehören beispielsweise:

offizielle ITIL- und PeopleCert-Veröffentlichungen,
Herstellerdokumentationen,
technische Produkthandbücher,
veröffentlichte Normen und Standards,
RFC-Dokumente,
Dokumentationen zuständiger Behörden,
offizielle Sicherheitsmeldungen,
und offizielle Dokumentationen eines Softwareprojekts.

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:

eine bestimmte Menüeinstellung,
eine konkrete Gerätekompatibilität,
einen bestimmten Befehlsparameter,
das Verhalten einer einzelnen Firmwareversion,
oder eine offiziell unterstützte Konfiguration.

Primärquelle und Sekundärquelle

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

Beispiele:

PeopleCert für offizielle ITIL-Inhalte,
der Hersteller für eine Produktfunktion,
der Herausgeber eines Standards,
das zuständige Softwareprojekt,
oder eine Behörde für ihre eigene Regelung.

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

Beispiele:

Fachbuch,
Schulungsunterlage,
Fachartikel,
Blogbeitrag,
Video,
Community-Wiki,
oder technische Zusammenfassung.

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:

gesetzlich vorgeschrieben,
technisch zwingend,
Bestandteil von ITIL,
oder für jedes Unternehmen unverändert geeignet.

Beispiele:

Änderungen zuerst in einer Testumgebung prüfen
vor risikoreichen Änderungen einen Rückfallplan erstellen
wichtige Arbeitsschritte mit Zeitstempel dokumentieren
bei kritischen Incidents regelmäßige Statusinformationen bereitstellen
nach einer Wiederherstellung die Überwachung fortsetzen
wiederkehrende Lösungen als Wissensartikel dokumentieren
Wiederherstellungsverfahren regelmäßig testen

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:

Uhrzeit,

Beobachtung,

durchgeführte Maßnahme,

und Ergebnis.

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:

eine Handlung verständlicher machen,
typische Fehler vermeiden,
Risiken reduzieren,
die Zusammenarbeit verbessern,
eine Dokumentation erleichtern,
oder die Übertragung eines theoretischen Inhalts in den Arbeitsalltag unterstützen.

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:

der technischen Umgebung,
dem betroffenen Service,
der Anzahl der betroffenen Benutzer,
bestehenden Verträgen,
internen Prozessen,
Sicherheitsanforderungen,
vorhandenen Berechtigungen,
und der geschäftlichen Bedeutung der Situation.

Community-Hinweis

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

Mögliche Quellen sind:

Herstellerforen,
GitHub-Issues,
Fachforen,
technische Communities,
Diskussionsplattformen,
und Erfahrungsberichte anderer Administratoren.

Ein Community-Beitrag belegt jedoch nicht automatisch, dass:

die beschriebene Ursache korrekt ist,
die Lösung allgemein funktioniert,
die Maßnahme offiziell unterstützt wird,
die Vorgehensweise sicher ist,
oder sie zur eigenen Version und Umgebung passt.

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:

offiziellen Quellen,
mehreren voneinander unabhängigen Berichten,
technischen Protokollen,
oder eigenen Tests

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:

getestetes Produkt,
verwendete Version,
Betriebssystem oder Plattform,
Hardwarearchitektur,
relevante Konfiguration,
durchgeführte Schritte,
beobachtetes Ergebnis,
und Testdatum.

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:

ITIL-Versionen,
Betriebssysteme,
Softwareprodukte,
Firmware,
Menüpfade,
APIs,
Befehlsoptionen,
Sicherheitsrichtlinien,
Zertifizierungsinhalte,
und Herstellerempfehlungen.

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:

vorhandene Zertifizierungen weiterhin bestehen können,
viele Organisationen ITIL-4-Begriffe verwenden,
betriebliche Arbeitsweisen nicht sofort umgestellt werden,
und zahlreiche Dokumentationen noch auf ITIL 4 beruhen.

Dieses Buch verwendet deshalb folgende Regeln:

Neue oder grundlegend überarbeitete Inhalte werden vorrangig anhand von ITIL Version 5 geprüft.
Weiterhin relevantes Wissen aus ITIL 4 bleibt erhalten.
Unterschiede zwischen ITIL 4 und ITIL Version 5 werden gekennzeichnet.
Begriffe aus ITIL 4 werden nicht automatisch als falsch dargestellt.
Veraltete Begriffe werden nicht ohne Versionshinweis als aktueller Stand übernommen.
Prüfungswissen wird von allgemeinem Praxiswissen getrennt.
Versionsangaben werden ergänzt, wenn ein Unterschied für Verständnis oder Anwendung wichtig ist.

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:

Product and Service Management Practices
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:

nur einzelne Practices einsetzen,
eigene Prozessnamen verwenden,
ältere Begriffe weiterführen,
mehrere Frameworks kombinieren,
Rollen anders benennen,
oder ITIL lediglich als Orientierung verwenden.

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:

welche Begriffe verwendet werden,

welche Arbeitsweisen tatsächlich gelten,

wer welche Verantwortung besitzt,

welche Freigaben erforderlich sind,

und wo verbindliche Vorgaben dokumentiert sind.

Umgebungsabhängige Informationen

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

Mögliche Unterschiede sind:

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

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:

Gilt die Anleitung für die verwendete Version?
Ist die Plattform identisch?
Sind die Voraussetzungen erfüllt?
Bestehen Abhängigkeiten zu anderen Services?
Gibt es Redundanz oder Hochverfügbarkeit?
Wird eine Freigabe benötigt?
Ist ein Rückfallplan vorhanden?
Kann die Maßnahme andere Benutzer oder Systeme beeinträchtigen?
Wie wird der Erfolg kontrolliert?

Sicherheitsrelevante Inhalte

Sicherheitsrelevante Hinweise werden besonders gekennzeichnet.

Sie betreffen beispielsweise:

Benutzerkonten und Berechtigungen,
Kennwörter und Zugangsdaten,
Firewall-Regeln,
Verschlüsselung,
Protokollierung,
Backups,
Produktivsysteme,
personenbezogene Daten,
Sicherheitsvorfälle,
administrative Befehle,
und Änderungen an Schutzmechanismen.

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:

Voraussetzungen,
benötigten Berechtigungen,
möglichen Auswirkungen,
Schutzmaßnahmen,
Rückfallmöglichkeiten,
Protokollierung,
und notwendiger Kontrolle nach der Durchführung.

Bewertung von Quellen

Quellen werden nicht ausschließlich nach ihrer Bekanntheit bewertet.

Entscheidend ist, ob eine Quelle:

für die konkrete Aussage zuständig ist,
die passende Version behandelt,
fachlich nachvollziehbar ist,
ausreichend aktuell ist,
und die Aussage tatsächlich unterstützt.

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:

Für die Bedeutung eines ITIL-Begriffs ist eine offizielle ITIL-Quelle maßgeblich.
Für einen Menüpfad ist die Dokumentation der betreffenden Softwareversion entscheidend.
Für eine gesetzliche Verpflichtung ist die maßgebliche Rechtsquelle wichtiger als ein Herstellerblog.
Für einen undokumentierten Fehler können Community-Berichte und eigene Tests ergänzend hilfreich sein.

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:

Wann wurde die Quelle veröffentlicht?
Wann wurde sie zuletzt inhaltlich aktualisiert?
Welche Version behandelt sie?
Gibt es eine neuere offizielle Quelle?
Wurde die Aussage später geändert oder zurückgezogen?
Bezieht sie sich auf ein inzwischen eingestelltes Produkt?
Stimmen Seitentitel, Inhalt und Versionsangabe miteinander überein?

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:

Welche Quelle ist primär oder offiziell?
Auf welche Version bezieht sich die jeweilige Aussage?
Wann wurde die Quelle veröffentlicht oder aktualisiert?
Behandeln die Quellen wirklich dieselbe Funktion und Umgebung?
Wurde eine ältere Empfehlung später ersetzt?
Ist nur eine bestimmte Konfiguration betroffen?
Kann die Abweichung reproduziert werden?
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:

Herausgeber oder Hersteller,
Titel der Dokumentation,
behandelte Version,
Veröffentlichungs- oder Aktualisierungsdatum, sofern bekannt,
Abruf- oder Prüfdatum,
und der relevante Abschnitt.

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

Herausgeber: …

Dokument: …

behandelte Version: …

Ergänzende Quellen

Herstellerdokumentation: …

Standard oder Fachquelle: …

Community-Hinweis: …

Eigene Prüfung

Testumgebung: …

getestete Version: …

Testdatum: …

Fachlicher Stand: …

Nicht benötigte Bereiche werden weggelassen.

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

Quellenlinks

Quellenlinks sollen möglichst:

direkt zur behandelten Dokumentation führen,
nicht nur auf eine allgemeine Startseite verweisen,
keine automatisch erzeugten Tracking-Parameter enthalten,
dauerhaft erreichbar sein,
und zur angegebenen Version passen.

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:

aktuelle Nachfolgeseite suchen,
offizielle Dokumentationsarchive prüfen,
neue Herstellerdokumentation verwenden,
einen Webarchiv-Hinweis ergänzen,
Aussage mit einer anderen Primärquelle belegen,
oder den Prüfstatus der Aussage herabsetzen.

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:

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

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:

keine offizielle ITIL-Publikation,
kein offizielles PeopleCert-Schulungsmaterial,
keine akkreditierte ITIL-Schulung,
keine offizielle Prüfungsvorbereitung,
und kein Ersatz für aktuelle offizielle Veröffentlichungen.

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

0.1 Über dieses Buch – Ziel, Arbeitsweise und Qualitätsmaßstab
0.2 So nutzt du dieses Buch
0.4 Aktualisierungen, Versionspflege und Korrekturen
1.1 Warum professionelles Service Management notwendig ist
1.2 Technik, Produkt, Service und Geschäftsergebnis
ITIL Version 5 und ITIL 4 im Vergleich
Glossar und Begriffserklärungen

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert: ITIL Foundation – Version 5
PeopleCert: ITIL FAQ – Frequently Asked Questions about ITIL
PeopleCert: ITIL Foundation Version 5 – What’s New?
PeopleCert: ITIL Qualification Scheme
PeopleCert: Acknowledgement Statements
PeopleCert: Marks Usage Policy
ITIL: ITIL Foundation – Version 5

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

Revision #2
Created 1 August 2026 19:22:31 by Admin
Updated 1 August 2026 21:09:53 by Admin