0.3 Kennzeichnungen, Quellen und Versionsstände

Kurz erklärt

Dieses Buch unterscheidet zwischenklar zwischen:

• offiziellen ITIL-Inhalten,
• verbindlichen Vorgaben,
• technischen Herstellerinformationen,
• anerkannten Standards,
• allgemeinen Best Practices,
• zusätzlichen Praxisempfehlungen,
technischen
• Community-Erfahrungen,
Herstellerangaben
• und Erfahrungsberichten.
  eigenen Tests.

Dadurch soll jederzeit erkennbar bleiben:

• woher eine InformationAussage stammt,
• wie verlässlichbelastbar sie ist,
• für welchenwelche AnwendungsbereichVersion und Umgebung sie gilt,
• ob sie von einer bestimmten Version abhängt,
• und ob sie vor dereiner praktischen Anwendung zusätzlich geprüft werden muss.

---

Warum diese Unterscheidung wichtig ist

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

Ein offizieller ITIL-Begriff hatist eineanders anderezu Bedeutungbewerten als:

• eine interne Arbeitsanweisung,
• eine Herstellerdokumentation,
• eine allgemeine Empfehlung für den IT-Betrieb,
• ein ErfahrungswertBeitrag einesin Administrators,
einem
• eine Herstelleranleitung,
• ein Community-Beitrag,Fachforum,
• oder ein Ergebnis aus einer eigenen Testumgebung.

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

• eine persönliche Empfehlung eine offizielle ITIL-Vorgabe sei.
  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:

zwischen

Herkunft,
1. offiziellenGültigkeit Framework-Inhalten,
2. technischen Herstellerinformationen,
3. anerkannten Best Practices,
4. zusätzlichen Praxisempfehlungen,
5. Community-Erfahrungen,
6. und eigenenpraktischer Tests.
Einordnung

einer Information.

Grundsatz

Eine hilfreiche Empfehlung muss nicht direktunmittelbar aus ITIL stammen.

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

---

Die verwendeten Kennzeichnungen

Prüfung

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, NormNorm, Hersteller- oder HerstellerdokumentationProjektdokumentation
Best Practice	allgemein anerkannte und bewährte VorgehensweiseVorgehensweise, die an den jeweiligen Kontext angepasst werden muss
Praxisempfehlung	zusätzliche Empfehlung dieses Buches für den konkreten Arbeitsalltag
Praxisbeispiel	vereinfachterealistische oder realistischevereinfachte 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 neueandere oder neuere Version äverändern
Umgebungsabhängig	Aussage gilt nur unter bestimmten technischen oder organisatorischen Bedingungen
Sicherheitsrelevant	HandlungInformation oder InformationHandlung kann die Vertraulichkeit, Integrität oder Verfügbarkeit beeinflussen
Betriebliche Vorgabe beachten	interne Regeln,Rollen, BerechtigungenBerechtigungen, Prozesse oder FreigabeprozesseFreigaben können Vorrang haben
NichtNoch abschließendzu geprüftprüfen	Aussage oder Sonderfall benötigtist noch einenicht zusätzlicheausreichend fachlichebelegt
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 dort verwendet, wowenn sie zumdas Verständnisndnis, die Bewertung oder zurdie sicherensichere Anwendung beitragen.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 in eigenen Wortensinngemäß erklärt.

Beispiele:

• DefinitionService
eines
• Wert
Service
• Outcome
• Guiding Principles
• ITIL PracticesValue System
• Incidentvier ManagementDimensionen
• ProblemManagement ManagementPractices
• Continual Improvement
• Rollen,Product Modelleand oderService Wertströme aus dem FrameworkLifecycle

Beispiel für die Verwendung:Beispiel:

ITIL-Grundlage

Incident Management konzentriertdient sich darauf,dazu, die negativen Auswirkungen von StörungenIncidents zu minimierenverringern, undindem der normale Servicebetrieb so schnell wie unter den normalenjeweiligen ServicebetriebBedingungen möglichstsinnvoll schnellwiederhergestellt wiederherzustellen.wird.

Eine solche Aussage wird nicht ohne Kennzeichnung mit zusätzlichen technischen oder persönlichen Empfehlungen vermischt,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 diesedie getrenntim zuUnternehmen kennzeichnen.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-Veröffentlichungen,
• offizielleund PeopleCert-Veröffentlichungen,
• Herstellerdokumentationen,
• technische Produkthandbücher,
• veröffentlichte StandardsNormen und Normen,Standards,
• SicherheitsrichtlinienRFC-Dokumente,
anerkannter
• Dokumentationen zuständiger Behörden,
• oderoffizielle Sicherheitsmeldungen,
• und offizielle Dokumentationen eines Softwareprojekts.

Beispiele:

Thema	Bevorzugte offizielle Quelle
ITIL-Begriff oder ITIL-Modell	PeopleCert beziehungsweise offizielle ITIL-Publikation oder PeopleCert-Veröffentlichung
Microsoft-Produkt	Microsoft Learn oder offizielle Produktdokumentation
Linux-Befehl	offizielle Manpage oder offizielle Projektdokumentation
Docker-Funktion	offizielle Docker-Dokumentation
SicherheitsmaßnahmeNetzwerkprotokoll	Herstellerdokumentation,maßgeblicher BSIRFC oder einschlägigerveröffentlichter Standard
NetzwerkstandardSicherheitswarnung	veröffentlichterHersteller, StandardBSI, CERT oder RFCzustä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,bevorzugen.

sie

Sie muss aberjedoch trotzdemdie zur konkretenkonkrete Aussage passen.tatsächlich belegen.

Eine allgemeine Produktseite belegtbestätigt beispielsweise nicht automatischautomatisch:

• eine bestimmte Menüeinstellungeinstellung,
• 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 Kompatibilität.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 geeignet,
unverändert
• oder Bestandteil des offiziellen ITIL-Frameworks.geeignet.

Beispiele:

• Änderungen zunächstzuerst in einer Testumgebung prüfen
• vor risikoreichen Änderungen einen Rückfallplan erstellen
• wichtige Arbeitsschritte mit Zeitstempel dokumentieren
• bei kritischen StörungenIncidents regelmäßige StatusmeldungenStatusinformationen versendenbereitstellen
• nach einer Wiederherstellung die Überwachung fortsetzen
• wiederkehrende Lösungen als Wissensartikel dokumentieren
• Wiederherstellungsverfahren regelmäßig testen

Best Practice

Eine bewährte Vorgehensweise muss an die Größe, Risiken, ProzesseAnforderungen und technische Umgebung desder jeweiligen UnternehmensOrganisation angepasst werden.

---

Praxisempfehlung

Eine Praxisempfehlung ergänzt das offizielle FrameworkFramework- oder Herstellerinformationen um konkrete Hinweise für den Arbeitsalltag eines Systemintegrators.Arbeitsalltag.

Beispiel:

Praxisempfehlung

Notiere beiwährend einereines laufenden StörungIncidents 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,
• oder eine spätere Dokumentation erleichtern.erleichtern,
• oder die Übertragung eines theoretischen Inhalts in den Arbeitsalltag unterstützen.

---

Praxisbeispiel

Praxisbeispiele übertragen theoretische Inhalte auf eine realistische Arbeitssituation.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 Auswirkung,Auswirkungen, Priorität, Kommunikation, Eskalation und Dokumentation berücksichtigt werden.

Praxisbeispiele sind nicht alskeine vollständig vorgeschriebenevorgeschriebenen Musterlösung zu verstehen.sungen.

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

• der technischen Umgebung,
• dendem betroffenen Services,Service,
• der Anzahl der betroffenen Benutzer,
• bestehenden Verträgen,
• internen Prozessen,
• Sicherheitsanforderungen,
• vorhandenen Berechtigungen,
• und vorhandenender Berechtigungen.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,
• oderund Erfahrungsberichte anderer Administratoren.

Ein Community-Beitrag istbelegt jedoch keinnicht sicherer Beleg dafür,automatisch, dass:

• die beschriebene Ursache korrekt ist,
• die Lösung allgemein funktioniert,
• die Ursache korrekt bestimmt wurde,
• die Maßnahme vom Herstelleroffiziell 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 mitmit:

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

abgeglichen.

---

Eigener Test

Die Kennzeichnung Eigener Test wird verwendet, wenn eine Aussage in einer selbst 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 Datum des Tests.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 diedasselbe FunktionVerhalten 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,
• Programmierschnittstellen,APIs,
• Befehlsoptionen,
• Sicherheitsrichtlinien,
• Zertifizierungsinhalte,
• und Herstellerempfehlungen.

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

Angabe	Beispiel
ProduktFramework oder FrameworkProdukt	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 oder Strukturen 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 inrelevant, offiziellenda:

Angeboten

und in vielen Unternehmen, Schulungsunterlagen, Prozessen und
• vorhandene Zertifizierungen verbreitet.
  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 oder unbrauchbar dargestellt.
• Veraltete Begriffe werden nicht ohne HinweisVersionshinweis als aktueller Stand übernommen.
• Prüfungswissen wird von allgemeinem Praxiswissen getrennt.
• Versionsangaben werden ergänzt, wenn ein Unterschied für das Verständnis oder die praktische Anwendung wichtig ist.

Versionsabhängig

EinEine UnternehmenOrganisation kann weiterhin Prozesse, Begriffe und Werkzeuge verwenden, die sich an ITIL 4 oder einer noch älteren ITIL-Ausgabe orientieren.ausgerichtet sind.

Für die tägliche Arbeit ist deshalb nichtneben nurdem der aktuelleaktuellen Framework-Stand wichtig, sondern auch die tatsächlich eingeführte Arbeitsweise desder Unternehmens.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 eineine UnternehmenOrganisation arbeitet.

UnternehmenOrganisationen können:

• nur einzelne ITIL Practices verwenden,einsetzen,
• eigene Prozessnamen besitzen,verwenden,
• ältere Begriffe weiterverwenden,weiterführen,
• mehrere Frameworks kombinieren,
• interne Rollen anders benennen,
• oder ITIL nurlediglich als Orientierung nutzen.verwenden.

Beispiel:

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

EinEine anderesandere UnternehmenOrganisation kann einfür Changebesonders Advisoryschwerwiegende BoardIncidents einsetzen,einen obwohleigenen nichtMajor-Incident-Ablauf jeder Change zwingend durch ein solches Gremium bewertet werden muss.einsetzen.

Praxistipp

Prüfe beim Einstieg in eineine Unternehmen immer:Organisation:

• welche Begriffe dort verwendet werden,
• welche ProzesseArbeitsweisen tatsächlich gelten,
• wer welche Verantwortung besitzt,
• welche Freigaben erforderlich sind,
• und wo dieverbindliche verbindlichen ArbeitsanweisungenVorgaben 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,
• Hardwareplattform,Hardwarearchitektur,
• Netzwerkarchitektur,Netzwerkaufbau,
• Berechtigungsmodell,
• Hochverfügbarkeitskonzept,
• Cloud- oder On-Premises-Betrieb,
• Sicherheitsrichtlinien,
• Mandantenstruktur,
• oderaktivierte unternehmensinterneErweiterungen,
Konfiguration.
• 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 produktiven SystemProduktivsystem kann derselbe Schritt zusätzliche Auswirkungen besitzen.verursachen.

Vor technischen Eingriffen muss deshalb geprüft werden:

• Gilt die Anleitung für die verwendete Version?
• Ist die SystemrollePlattform 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 ÄnderungMaßnahme andere Benutzer oder andere Systeme beeinflussen?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,
• oderadministrative denBefehle,
Einsatz
• und administrativerÄnderungen Befehle.an Schutzmechanismen.

Sicherheitsrelevant

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

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

Sicherheitsrelevante Befehle oder ÄnderungenAnleitungen sollen nichtnach ohneMöglichkeit HinweiseInformationen zuenthalten folgenden Punkten veröffentlicht werden:zu:

• Voraussetzungen,
• benötigtetigten Berechtigungen,
• möglicheglichen Auswirkungen,
• Schutzmaßnahmen,
• Rückfallmöglichkeit,glichkeiten,
• Protokollierung,
• und notwendigenotwendiger Kontrolle nach der Durchführung.

---

QuellenhierarchieBewertung von Quellen

BeiQuellen widersprüchlichenwerden 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:

verlässlichenAngabenwirdfolgendeReihenfolgeals Orientierung verwendet:

bestätigte

Rang	Quellen- oder unterschiedlichVorgabenart
1	geltendes RechtRecht, verbindliche Verträge und verbindliche betriebliche Vorgaben
2	offizielle Normen, Standards und Sicherheitsanforderungenbehö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 BewertungHierarchie für jeden Einzelfall.

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

Beispiel:Beispiele:

• Für die Bedeutung eines ITIL-Begriffs ist eine offizielle ITIL-PublikationQuelle maßgeblich.

• Für einen konkreten Menüpfad einerist Softwaredie Dokumentation der betreffenden Softwareversion entscheidend.
• Für eine gesetzliche Verpflichtung ist dagegen die aktuellemaßgebliche HerstellerdokumentationRechtsquelle entscheidend.
  wichtiger

  als ein Herstellerblog.

• Für einen Fehler,undokumentierten den der Hersteller nicht dokumentiert hat,Fehler können Community-Berichte und eigene Tests ergänzend wertvollhilfreich 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:

1. Welche Quelle ist offiziellprimär oder primär?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 dieeine Aussage durch Tests bestätigt?
6. Hat der Hersteller seineältere Empfehlung später geändert?ersetzt?
7. Ist möglicherweise nur eine bestimmte Konfiguration betroffen?
8. Kann die Abweichung reproduziert werden?
9. Gibt es eine offizielle Stellungnahme?

Kann der Widerspruch nicht eindeutig geklärt werden, wird er aufsichtbar der Seite kenntlich gemacht.

Beispiel:gekennzeichnet.

NichtNoch abschließendzu geprüftprüfen

Die verfügbaren Quellen beschreiben unterschiedliche Ergebnisse.

Die Abweichung kann mit derVersion, verwendeten VersionPlattform oder Konfiguration zusammenhängen. Vor einer produktiven Anwendung ist eineine eigenerzusätzliche TestPrü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 betroffenerder 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


 Ist eindeutig, welche Aussagen aus ITIL stammen?

 Sind offizielle Inhalte und Praxisempfehlungen getrennt?

 Wurde möglichst eine geeignete Primärquelle verwendet?

 Passt die Quelle zur konkreten Aussage?

 Ist die behandelte Version angegeben?

 Wurden ältere oder abweichende Begriffe gekennzeichnet?

 Sind technische Aussagen auf die richtige Umgebung bezogen?

 Sind Community-Erfahrungen als solche erkennbar?

 Sind eigene Tests ausreichend dokumentiert?

 Wird zwischen technisch funktionsfähig und offiziell unterstützt unterschieden?

 Werden Sicherheitsrisiken und Voraussetzungen genannt?

 Sind widersprüchliche Quellen kenntlich gemacht?

 Ist das Datum der fachlichen Prüfung angegeben?

 Können Leser die verwendeten Quellen wiederfinden?

 Wurde keine Vermutung als gesicherte Tatsache formuliert?

 Wurden sichtbare interne Platzhalter entfernt?

 Enthalten Links keine unnötigen Tracking-Parameter?

 Sind Zitate eindeutig gekennzeichnet?

 Wurden Urheber- und Markenrechte berücksichtigt?



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

FachlichZusätzlich geprüft:berücksichtigt: ITIL 4

Fachlicher Stand: August 2026