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 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 Zusätzlich berücksichtigt: ITIL 4 Fachlicher Stand: August 2026