0. ITIL - Über dieses Buch 0.1 Über dieses Buch – Ziel, Arbeitsweise und Qualitätsmaßstab Kurz erklärt Dieses Buch vermittelt Grundlagen und Zusammenhänge des professionellen IT-Service-Managements. Es zeigt außerdem, wie Fachinformatiker für Systemintegration dieses Wissen im täglichen IT-Betrieb anwenden können. Das Buch ist damit gleichzeitig: Lernwerk, Nachschlagewerk, Arbeitshilfe, Entscheidungshilfe, Checklisten-Sammlung, und langfristige Wissensbasis. Ziel dieses Buches Dieses Buch verbindet fachliches ITIL-Wissen mit konkreten Situationen aus dem Arbeitsalltag eines Fachinformatikers für Systemintegration. Es soll dabei helfen: digitale Produkte und Services zu verstehen, technische Aufgaben in ihren betrieblichen Zusammenhang einzuordnen, Störungen strukturiert zu bearbeiten, Anforderungen richtig zuzuordnen, Prioritäten nachvollziehbar festzulegen, Änderungen kontrolliert durchzuführen, Risiken vor technischen Eingriffen zu erkennen, Benutzer und andere Beteiligte angemessen zu informieren, Arbeitsschritte verständlich zu dokumentieren, Wissen für Kollegen verfügbar zu machen, wiederkehrende Fehler langfristig zu reduzieren, und Produkte, Services sowie Arbeitsweisen kontinuierlich zu verbessern. Das notwendige Fachwissen bildet dafür die Grundlage. Der praktische Nutzen entscheidet darüber, wie dieses Wissen erklärt und aufbereitet wird. Leitsatz Wissen hilft dabei, Zusammenhänge zu verstehen. Struktur hilft dabei, dieses Wissen im richtigen Moment richtig anzuwenden. Für wen ist dieses Buch gedacht? Das Buch richtet sich insbesondere an: angehende Fachinformatiker für Systemintegration, Auszubildende und Umschüler, Berufseinsteiger im IT-Betrieb, Systemadministratoren, Service-Desk- und Support-Mitarbeiter, IT-Techniker, Netzwerkadministratoren, Mitarbeiter von Managed Service Providern, sowie Personen, die digitale Produkte und Services professionell betreiben oder unterstützen möchten. Die Inhalte berücksichtigen unterschiedliche Wissensstände. Wissensstand Schwerpunkt Einsteiger verständliche Grundlagen, Fachbegriffe und erste Praxisbeispiele Fortgeschrittene Abläufe, Zusammenhänge, Entscheidungshilfen und technische Einordnung Erfahrene Fachkräfte Schnellreferenzen, Risiken, Sonderfälle, Checklisten und Verbesserungsmöglichkeiten Das Buch soll sowohl beim Lernen als auch später im beruflichen Alltag verwendet werden können. Was dieses Buch vermitteln soll Das Buch soll nicht nur Definitionen bereitstellen. Es soll drei miteinander verbundene Fähigkeiten entwickeln: Verstehen Anwenden Erfahrung aufbauen Diese Ebenen greifen ineinander. Fachwissen ohne Anwendung bleibt theoretisch. Anwendung ohne ausreichendes Verständnis kann zu Fehlern führen. Erfahrung hilft dabei, Risiken, Zusammenhänge und Sonderfälle früher zu erkennen. Die drei Wissensebenen Ebene Leitfrage Inhalt Verstehen Was ist das und warum ist es wichtig? Begriffe, Grundlagen, Ziele und Zusammenhänge Anwenden Wie gehe ich konkret vor? Abläufe, Checklisten, Werkzeuge und Entscheidungshilfen Erfahrung Was muss ich in der Praxis zusätzlich beachten? Risiken, typische Fehler, Sonderfälle und bewährte Vorgehensweisen Nicht jede Seite muss alle drei Ebenen gleich ausführlich behandeln. Es soll jedoch erkennbar sein, ob ein Abschnitt: eine offizielle ITIL-Grundlage erklärt, eine praktische Umsetzung beschreibt, oder zusätzliches Erfahrungswissen vermittelt. So arbeitet dieses Buch Die Inhalte verbinden die drei Wissensebenen miteinander: Verstehen – Begriffe, Ziele und Zusammenhänge erfassen. Anwenden – Wissen in konkrete Handlungen und Entscheidungen übertragen. Erfahrung – Risiken, typische Fehler und Sonderfälle berücksichtigen. Dadurch soll aus theoretischem Wissen eine sichere und nachvollziehbare Arbeitsweise entstehen. Vom Wissen zur professionellen Arbeitsweise Fachwissen → ITIL-Einordnung → Handlung → Dokumentation → Verbesserung Interaktive Darstellung öffnen Hinweis Die statische Grafik enthält die Kernaussage vollständig. Die interaktive Darstellung ergänzt weitere Erklärungen und Praxisbeispiele, ist für das Verständnis der Seite aber nicht zwingend erforderlich. Warum ITIL für Systemintegratoren wichtig ist Fachinformatiker für Systemintegration arbeiten nicht ausschließlich mit: Servern, Netzwerken, Betriebssystemen, Benutzerkonten, Anwendungen, Cloud-Plattformen, Firewalls, Backups, und Monitoring-Systemen. Zum Berufsalltag gehören ebenfalls: Tickets bearbeiten, Benutzer unterstützen, Auswirkungen von Störungen bewerten, Prioritäten setzen, Änderungen abstimmen, Wartungsarbeiten planen, Kollegen informieren, Wissen dokumentieren, Dienstleister koordinieren, Sicherheitsanforderungen beachten, und die Verfügbarkeit von Services unterstützen. Technisches Wissen beantwortet beispielsweise die Frage: Wie untersuche und behebe ich einen ausgefallenen Dienst? Service Management hilft zusätzlich bei folgenden Fragen: Welcher Service ist betroffen? Wer ist von der Störung betroffen? Welche Auswirkungen bestehen? Wie dringend ist die Wiederherstellung? Wer muss informiert werden? Ist eine Eskalation erforderlich? Wurde kürzlich eine Änderung durchgeführt? Welche Zwischenlösung ist möglich? Was muss dokumentiert werden? Ist nach der Wiederherstellung eine Ursachenanalyse notwendig? Kann das gewonnene Wissen später wiederverwendet werden? Professionelle IT-Arbeit verbindet technische Kompetenz mit einer strukturierten und serviceorientierten Arbeitsweise. Technische und organisatorische Perspektive Viele Aufgaben eines Systemintegrators besitzen zwei unterschiedliche Perspektiven. Perspektive Zentrale Frage Technische Perspektive Wie untersuche, konfiguriere oder repariere ich das System? Service-Management-Perspektive Wie ordne, priorisiere, koordiniere und dokumentiere ich die Arbeit? Beispiel: Ein Webserver ist nicht erreichbar. Die technische Perspektive kann folgende Prüfungen umfassen: Netzwerkverbindung prüfen, DNS-Auflösung testen, Erreichbarkeit des Hosts kontrollieren, Dienststatus prüfen, Protokolle auswerten, Firewall-Regeln untersuchen, Container oder virtuelle Maschine kontrollieren. Die Service-Management-Perspektive ergänzt: betroffenen Service bestimmen, betroffene Benutzer ermitteln, Auswirkungen bewerten, Priorität festlegen, Zuständigkeit klären, Beteiligte informieren, Eskalation prüfen, Wiederherstellung dokumentieren, mögliche Folgeaktivitäten einleiten. Merke Technische Fehleranalyse und Service Management ersetzen sich nicht. Sie ergänzen sich. Was ITIL leistet ITIL ist ein anpassbares Best-Practice-Framework für das Management digitaler Produkte und Services. Es unterstützt Organisationen unter anderem dabei: eine gemeinsame Sprache zu verwenden, Entscheidungen an Wert und Outcomes auszurichten, Produkte und Services ganzheitlich zu betrachten, Verantwortlichkeiten und Zusammenarbeit zu verbessern, geeignete Management Practices einzusetzen, Wertströme sichtbar zu machen, und kontinuierliche Verbesserung in die tägliche Arbeit zu integrieren. ITIL ist kein starres Regelwerk. Es schreibt nicht für jedes Unternehmen dieselben: Rollen, Arbeitsschritte, Genehmigungsstufen, Werkzeuge, Organisationsformen, oder technischen Lösungen vor. Die Inhalte müssen an den jeweiligen Kontext angepasst werden. Grundsatz ITIL soll die Wertschöpfung unterstützen. Es soll keine unnötige Bürokratie erzeugen. Was ITIL nicht leistet ITIL ersetzt nicht: technisches Fachwissen, Herstellerdokumentationen, Sicherheitsrichtlinien, gesetzliche Anforderungen, betriebliche Arbeitsanweisungen, technische Tests, eigene Risikobewertungen, oder die Erfahrung der beteiligten Fachkräfte. ITIL erklärt beispielsweise nicht im Detail: mit welchem Linux-Befehl ein Dienst geprüft wird, wie eine bestimmte Firewall-Regel konfiguriert wird, welche Menüoption in einer bestimmten Software gewählt werden muss, oder wie ein konkreter Switch eingerichtet wird. Das Framework hilft stattdessen dabei, technische Tätigkeiten sinnvoll zu: planen, priorisieren, koordinieren, dokumentieren, kontrollieren, und verbessern. Aktueller ITIL-Stand dieses Buches Dieses Buch trägt absichtlich keine Versionsnummer im Titel. ITIL wird weiterentwickelt, während ältere Versionen in Unternehmen weiterhin verbreitet sein können. Für dieses Buch gelten deshalb folgende Regeln: Die fachliche Hauptgrundlage ist ITIL Version 5 . Weiterhin relevantes Wissen aus ITIL 4 wird zusätzlich berücksichtigt. Unterschiede zwischen den Versionen werden gekennzeichnet. Begriffe aus ITIL 4 werden nicht automatisch als falsch dargestellt. Veraltete Begriffe werden nicht ohne Hinweis als aktueller Stand übernommen. Betriebliche Bezeichnungen können von den offiziellen ITIL-Begriffen abweichen. Prüfungswissen wird von allgemeinem Praxiswissen getrennt. Beispiel: ITIL Version 5 ITIL 4 Change Management Change Enablement Beide Begriffe können in bestehenden Organisationen und Unterlagen vorkommen. Innerhalb dieses Buches wird bei relevanten Unterschieden angegeben, auf welche Version sich eine Aussage bezieht. Offizielle Inhalte und Praxiswissen unterscheiden Das Buch unterscheidet verschiedene Informationsarten. Informationsart Bedeutung ITIL-Grundlage Begriff, Modell, Prinzip oder Practice aus dem offiziellen Framework Offizielle Quelle Aussage aus einer offiziellen Veröffentlichung oder Herstellerdokumentation Best Practice allgemein bewährte Vorgehensweise Praxisempfehlung zusätzliche Empfehlung für den Arbeitsalltag Praxisbeispiel vereinfachte Situation zur Erklärung Community-Hinweis Erfahrungsbericht ohne gleichwertige offizielle Bestätigung Eigener Test Ergebnis aus einer dokumentierten eigenen Testumgebung Versionsabhängig Aussage kann sich durch eine neue Version verändern Umgebungsabhängig Aussage gilt nur unter bestimmten Bedingungen Sicherheitsrelevant Handlung kann Vertraulichkeit, Integrität oder Verfügbarkeit beeinflussen Eine Praxisempfehlung wird nicht als offizielle ITIL-Vorgabe dargestellt. Eine Community-Erfahrung wird nicht ohne Prüfung als allgemein gültige Lösung übernommen. Eine technisch mögliche Handlung wird nicht automatisch als sicher oder betrieblich zulässig betrachtet. Die 30-Sekunden-Regel Eine Seite soll so aufgebaut sein, dass innerhalb von etwa 30 Sekunden erkennbar ist: welches Thema behandelt wird, ob die Seite zur aktuellen Frage passt, wo sich die wichtigste Information befindet, welche Handlung als Nächstes sinnvoll ist, und welche Risiken beachtet werden müssen. Dafür verwendet das Buch bevorzugt: eindeutige Überschriften, kurze Absätze, Tabellen, Checklisten, Merksätze, Praxisbeispiele, Ablaufbeschreibungen, Entscheidungshilfen, Grafiken, und klar gekennzeichnete Hinweise. Die schnelle Orientierung darf nicht dazu führen, dass notwendiges Grundlagenwissen oder wichtige Einschränkungen fehlen. Qualitätsmaßstab Vor der Veröffentlichung oder einer größeren Überarbeitung wird insbesondere geprüft: Ist der Zweck der Seite eindeutig? Wird das notwendige Fachwissen korrekt vermittelt? Ist der praktische Nutzen erkennbar? Sind Fachbegriffe verständlich erklärt? Werden offizielle Inhalte und Praxisempfehlungen getrennt? Werden typische Risiken und Fehler berücksichtigt? Sind Handlungsschritte nachvollziehbar begründet? Wurden Vermutungen als solche gekennzeichnet? Sind versionsabhängige Angaben erkennbar? Ist die Seite schnell durchsuchbar? Sind sinnvolle Querverweise vorhanden? Sind die verwendeten Quellen aufgeführt? Unterstützt die Seite eine Handlung, Entscheidung oder ein besseres Verständnis? Wichtigste Kontrollfrage Hilft diese Seite einem Fachinformatiker dabei, seinen Arbeitsalltag besser, sicherer oder effizienter zu bewältigen? Eigenständigkeit und rechtlicher Hinweis Dieses Buch ist eine unabhängige, öffentlich zugängliche 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 Inhalte werden in eigenen Worten zusammengefasst und durch selbst erstellte: Praxisbeispiele, Checklisten, Entscheidungshilfen, technische Erklärungen, und Erfahrungswerte ergänzt. ITIL® und PeopleCert® sind eingetragene Marken von PeopleCert International Limited. Alle Rechte an den Marken und offiziellen Veröffentlichungen verbleiben bei den jeweiligen Rechteinhabern. Verwandte Seiten 0.2 So nutzt du dieses Buch 0.3 Kennzeichnungen, Quellen und Versionsstände 0.4 Aktualisierungen, Versionspflege und Korrekturen 1.1 Warum professionelles Service Management notwendig ist Quellen und Versionsstand Offizielle Grundlagen PeopleCert: ITIL Foundation – Version 5 ITIL: ITIL at a Glance PeopleCert: aktuelle offizielle Veröffentlichungen zu ITIL Version 5 Einordnung Die praktischen Beispiele, Qualitätsregeln und Hinweise zur Nutzung dieses Buches sind redaktionelle Festlegungen 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 0.2 So nutzt du dieses Buch Kurz erklärt Dieses Buch kann vollständig von Anfang bis Ende gelesen oder gezielt als Nachschlagewerk und praktische Arbeitshilfe verwendet werden. Du musst nicht jedes Kapitel gelesen haben, bevor du mit einer konkreten Aufgabe arbeitest. Die Seiten sind so aufgebaut, dass zentrale Informationen auch einzeln verständlich und schnell auffindbar sind. Drei Möglichkeiten, dieses Buch zu verwenden Nutzung Wann ist sie sinnvoll? Vorgehensweise Lernen Du möchtest ITIL und professionelles Service Management systematisch verstehen. Kapitel in der vorgesehenen Reihenfolge durcharbeiten. Nachschlagen Du suchst eine Definition, Abgrenzung oder Entscheidungshilfe. Über Inhaltsverzeichnis, Suche oder Querverweise direkt zur passenden Seite wechseln. Arbeiten Du befindest dich in einer konkreten Arbeitssituation. Schnellübersicht, Vorgehensweise und Checkliste der passenden Seite verwenden. Die drei Nutzungsarten schließen sich nicht gegenseitig aus. Eine Seite kann zunächst zum Lernen gelesen und später als kompakte Arbeitshilfe verwendet werden. Wenn du das Thema vollständig lernen möchtest Für ein systematisches Verständnis empfiehlt sich folgende Reihenfolge: Grundlagen des professionellen Service Managements zentrale Begriffe wie Produkt, Service, Wert, Outcome, Kosten und Risiken Aufbau und Denkweise von ITIL Produkte, Services, Wertströme und Lebenszyklus Zusammenarbeit mit Benutzern, Kunden und weiteren Stakeholdern professionelle Ticketbearbeitung wichtige ITIL Practices typische Situationen aus dem IT-Betrieb Praxisfälle, Checklisten und Entscheidungshilfen Die Grundlagenkapitel vermitteln das notwendige Verständnis für spätere Themen. Es ist beispielsweise hilfreich, zunächst die Begriffe Service , Wert , Output , Outcome , Kosten , Risiko und Stakeholder zu verstehen, bevor einzelne Practices und deren Zusammenwirken vertieft werden. Merke Die praktische Anwendung wird leichter verständlich, wenn die zugrunde liegenden Begriffe, Ziele und Zusammenhänge bekannt sind. Wenn du schnell etwas nachschlagen möchtest Beim Nachschlagen musst du nicht jede Seite vollständig von oben bis unten lesen. Orientiere dich zunächst an den folgenden Bereichen: Gesuchte Information Geeigneter Abschnitt schnelle Einordnung des Themas Kurz erklärt Bedeutung eines Begriffs Grundlagen oder Schnellzusammenfassung konkrete Arbeitsschritte Vorgehensweise schnelle Kontrolle Checkliste Auswahl zwischen mehreren Möglichkeiten Entscheidungshilfe häufige Fehlentscheidungen Typische Fehler mögliche Gefahren und Auswirkungen Risiken und Sicherheitsaspekte zusätzliche Erfahrung aus der Praxis Praxistipp wichtigste Kernaussage Merke technische Vertiefung Verwandte Seiten Herkunft einer Aussage Quellen und Versionsstand Die wichtigsten Informationen stehen nach Möglichkeit weit oben auf der Seite. Vertiefungen, Sonderfälle, Beispiele und Quellen folgen anschließend. Wenn du dich in einer konkreten Arbeitssituation befindest Angenommen, ein Benutzer meldet: „Ich kann mich seit heute Morgen nicht mehr anmelden.“ Dann musst du nicht sofort das gesamte Kapitel über Incident Management lesen. Gehe stattdessen schrittweise vor: konkrete Situation erfassen betroffenen Service bestimmen betroffene Benutzer und Auswirkungen ermitteln nach Service, Fehlermeldung oder beobachtetem Verhalten suchen passende Praxis- oder Schnellreferenzseite öffnen Voraussetzungen und wichtigste Rückfragen prüfen geeignete Vorgehensweise auswählen Sicherheits-, Eskalations- und Freigabekriterien beachten durchgeführte Schritte und Ergebnisse dokumentieren bei Bedarf technische Querverweise verwenden prüfen, ob eine weitere Untersuchung oder Verbesserung notwendig ist Wichtig Eine Checkliste unterstützt die Arbeit. Sie ersetzt nicht die fachliche Bewertung der konkreten Situation. Schnellzugriff nach Arbeitssituation Situation Passender Themenbereich Ein Benutzer meldet eine Störung. Incident Management Ein Benutzer benötigt einen vorgesehenen Standardservice. Service Request Management Derselbe oder ein ähnlicher Fehler tritt wiederholt auf. Problem Management Eine technische oder organisatorische Änderung soll durchgeführt werden. Change Management Ein kritischer Incident beeinträchtigt einen wichtigen Service. Incident Management und betrieblicher Major-Incident-Ablauf Eine Lösung soll dauerhaft für Kollegen verfügbar sein. Knowledge Management Hardware, Software oder Lizenzen sollen verwaltet werden. IT Asset Management Abhängigkeiten zwischen Services und Komponenten sollen erfasst werden. Service Configuration Management Ein Monitoring-System erzeugt eine Meldung. Monitoring and Event Management Ein externer Dienstleister muss eingebunden werden. Supplier Management Vereinbarte Serviceziele werden nicht erreicht. Service Level Management Eine Arbeitsweise oder ein Service soll verbessert werden. Continual Improvement Ein sicherheitsrelevantes Ereignis wurde erkannt. Information Security Management und betriebliche Sicherheitsverfahren Diese Zuordnung dient als erste Orientierung. Eine Arbeitssituation kann mehrere Practices, technische Fachbereiche und betriebliche Verfahren gleichzeitig betreffen. Hinweis Ein Major Incident ist ein besonders schwerwiegender Incident. Die Kriterien, Rollen, Kommunikationswege und Eskalationsverfahren dafür werden von der jeweiligen Organisation festgelegt. Technische und serviceorientierte Perspektive verbinden Viele Aufgaben eines Fachinformatikers für Systemintegration besitzen mindestens zwei Perspektiven. Perspektive Zentrale Frage Technische Perspektive Wie untersuche, konfiguriere oder repariere ich das System? Serviceorientierte Perspektive Welche Auswirkungen bestehen und wie wird die Arbeit koordiniert, dokumentiert und bewertet? Beispiel: Ein Webserver ist nicht erreichbar. Die technische Perspektive kann folgende Prüfungen umfassen: Netzwerkverbindung prüfen, DNS-Auflösung testen, Erreichbarkeit des Hosts kontrollieren, Dienststatus prüfen, Protokolle auswerten, Zertifikate kontrollieren, Firewall-Regeln untersuchen, Container oder virtuelle Maschine prüfen. Die serviceorientierte Perspektive ergänzt: betroffenen Service bestimmen, betroffene Benutzer ermitteln, geschäftliche Auswirkungen bewerten, Dringlichkeit feststellen, Zuständigkeit klären, Beteiligte informieren, Eskalation prüfen, Zwischenlösung bewerten, Wiederherstellung kontrollieren, Maßnahmen dokumentieren, und notwendige Folgeaktivitäten einleiten. Merke Technische Fehleranalyse und Service Management ersetzen sich nicht. Sie ergänzen sich. Die Seitenarten dieses Buches Nicht jede Seite verfolgt denselben Zweck. Seitenart Zweck Grundlagenseite erklärt Begriffe, Modelle und Zusammenhänge Practice-Seite beschreibt Zweck, Nutzen und Anwendung einer Management Practice Praxisfall zeigt eine realistische Arbeitssituation Vorgehensweise führt schrittweise durch eine Aufgabe Entscheidungshilfe unterstützt bei Auswahl, Priorisierung oder Eskalation Checkliste ermöglicht eine schnelle Kontrolle wichtiger Punkte Vorlage liefert eine wiederverwendbare Dokumentationsstruktur Schnellreferenz fasst wichtige Informationen kompakt zusammen Vergleichsseite grenzt ähnliche Begriffe oder Vorgehensweisen voneinander ab Glossarseite erklärt Fachbegriffe und Abkürzungen Die Seitenart soll möglichst bereits durch Titel und Aufbau erkennbar sein. So erkennst du wichtige Hinweise Im Buch werden wiederkehrende Kennzeichnungen verwendet. Kennzeichnung Bedeutung Kurz erklärt kompakte Einordnung des Themas ITIL-Grundlage Begriff, Modell oder Inhalt aus dem offiziellen Framework Offizielle Quelle Aussage aus einer offiziellen Veröffentlichung oder Dokumentation Praxisbeispiel realistische oder vereinfachte Arbeitssituation Vorgehensweise empfohlene Reihenfolge von Arbeitsschritten Entscheidungshilfe Unterstützung bei einer konkreten Auswahl Typischer Fehler häufige oder besonders relevante Fehlentscheidung Risiko mögliche technische, organisatorische oder sicherheitsrelevante Folge Praxistipp zusätzliche bewährte Empfehlung für den Arbeitsalltag Merke zentrale Aussage zum schnellen Wiederholen Checkliste Punkte zur direkten Kontrolle Versionsabhängig Information kann sich durch neue Versionen verändern Umgebungsabhängig Information gilt nur unter bestimmten Voraussetzungen Verwandte Seiten passende Grundlagen oder Vertiefungen Nicht jede Kennzeichnung wird auf jeder Seite verwendet. Es werden nur Elemente eingesetzt, die für das jeweilige Thema einen tatsächlichen Nutzen bieten. Querverweise richtig verwenden IT-Aufgaben lassen sich selten vollständig einem einzigen Thema zuordnen. Ein fehlgeschlagener Anmeldevorgang kann beispielsweise folgende Bereiche betreffen: Incident Management, Identitäts- und Zugriffsmanagement, Active Directory oder einen anderen Verzeichnisdienst, DNS, Zeitsynchronisation, Kerberos oder andere Authentifizierungsverfahren, Netzwerk, Informationssicherheit, Monitoring, und technische Fehleranalyse. Querverweise helfen dabei: technische Vertiefungen zu finden, Zusammenhänge zu verstehen, doppelte Erklärungen zu vermeiden, und eine Aufgabe aus mehreren Perspektiven zu betrachten. Grundsatz Ein Querverweis soll eine konkrete Frage beantworten oder die nächste sinnvolle Vertiefung ermöglichen. So verwendest du die Suche Beginne mit dem wichtigsten Begriff der Situation. Geeignete Suchbegriffe können sein: Incident Service Request Problem Change Priorität Eskalation Service Major Incident Benutzeranmeldung VPN DNS Server nicht erreichbar Wiederherstellung Rückfallplan Falls ein Begriff keine passenden Ergebnisse liefert, suche zusätzlich: nach einem Synonym, nach dem betroffenen Service, nach der sichtbaren Fehlermeldung, nach dem technischen System, nach der betroffenen Komponente, oder nach der auszuführenden Tätigkeit. Beispiel: Statt ausschließlich nach Outlook zu suchen, können folgende Suchbegriffe hilfreicher sein: E-Mail-Service Microsoft 365 Anmeldung Authentifizierung Verbindungsproblem Incident Postfach So verwendest du Checklisten Checklisten helfen dabei, wichtige Punkte nicht zu vergessen. Sie eignen sich besonders: vor Änderungen, bei wiederkehrenden Aufgaben, bei kritischen Störungen, für Eskalationen, bei Übergaben, bei Wiederherstellungen, und vor dem Abschluss eines Vorgangs. Eine Checkliste ist jedoch keine automatische Handlungsanweisung. Prüfe immer: Passt der Punkt zur konkreten Umgebung? Ist die Maßnahme freigegeben? Besitzt du die notwendige Berechtigung? Gibt es Sicherheits- oder Datenschutzanforderungen? Kann die Handlung den laufenden Betrieb beeinflussen? Bestehen Abhängigkeiten zu anderen Services? Ist ein Rückfallplan vorhanden? Muss eine verantwortliche Person eingebunden werden? Wie wird der Erfolg geprüft? So verwendest du Vorlagen Vorlagen stellen eine Ausgangsbasis dar. Sie können beispielsweise verwendet werden für: Ticketdokumentationen, Incident-Berichte, Change-Anträge, Wartungsankündigungen, Übergaben, Wissensartikel, Ursachenanalysen, Wiederherstellungsprotokolle, und Abschlussberichte. Vorlagen müssen an die tatsächliche Situation angepasst werden. Nicht relevante Abschnitte können entfernt werden. Fehlende Informationen müssen ergänzt werden. Typischer Fehler Eine vollständig ausgefüllte Vorlage ist nicht automatisch eine gute Dokumentation. Entscheidend ist, ob ein anderer Mitarbeiter die Situation, die durchgeführten Schritte und die getroffenen Entscheidungen nachvollziehen kann. Arbeiten unter Zeitdruck Bei einem kritischen Incident solltest du dich zunächst auf folgende Punkte konzentrieren: unmittelbare Gefahren und Sicherheitsrisiken erkennen betroffenen Service bestimmen Auswirkungen und Dringlichkeit feststellen Zuständigkeit und Eskalation klären Service stabilisieren oder wiederherstellen Beteiligte angemessen informieren wesentliche Beobachtungen und Maßnahmen dokumentieren Erfolg der Wiederherstellung kontrollieren Ursachenanalyse und Verbesserungen anschließend durchführen Unter Zeitdruck kann die Dokumentation zunächst kompakt gehalten werden. Wichtige Beobachtungen, Entscheidungen und Änderungen müssen trotzdem erfasst werden. Praxistipp Notiere während eines Incidents mindestens: Uhrzeit, Beobachtung, Maßnahme, Ergebnis. Beispiel: Uhrzeit Beobachtung Maßnahme Ergebnis 09:12 Uhr Webservice nicht erreichbar Dienststatus geprüft Dienst gestoppt 09:15 Uhr Ursache noch unbekannt Dienst kontrolliert gestartet Service wieder erreichbar 09:20 Uhr Störung trat nach einer Änderung auf weiterer Untersuchungsbedarf dokumentiert Ursachenanalyse folgt Das Buch ersetzt keine betrieblichen Vorgaben Die Inhalte dieses Buches bieten Orientierung, Hintergrundwissen und praktische Unterstützung. Im tatsächlichen Unternehmen gelten zusätzlich: interne Richtlinien, Rollen und Berechtigungen, Sicherheitsvorgaben, Datenschutzbestimmungen, Freigabeprozesse, Eskalationswege, Verträge, Service Level Agreements, Arbeitsanweisungen, und Entscheidungen verantwortlicher Personen. Bei einem Widerspruch haben verbindliche rechtliche, sicherheitsrelevante und betriebliche Vorgaben Vorrang. Empfohlener Schnellablauf Situation erfassen betroffenen Service bestimmen Auswirkungen und Dringlichkeit bewerten passende Seite finden Voraussetzungen und Risiken prüfen geeignete Vorgehensweise anwenden Ergebnis kontrollieren Arbeit dokumentieren notwendige Folgeaktivitäten einleiten Verbesserungspotenzial prüfen Checkliste für die Nutzung des Buches Habe ich die konkrete Situation richtig verstanden? Weiß ich, welcher Service betroffen ist? Habe ich Auswirkungen und Dringlichkeit berücksichtigt? Nutze ich die passende Seitenart? Habe ich Voraussetzungen und Berechtigungen geprüft? Habe ich Risiken und Sicherheitsaspekte beachtet? Benötige ich eine technische Vertiefung? Muss eine andere Person oder ein anderes Team eingebunden werden? Habe ich Schritte und Ergebnisse dokumentiert? Wurde der Erfolg aus Benutzersicht geprüft? Gibt es einen passenden Querverweis? Muss aus der Situation später Wissen oder eine Verbesserung entstehen? Nutzungsweg durch das Buch Situation erfassen ↓ passende Seite finden ↓ Grundlagen und Voraussetzungen prüfen ↓ Vorgehensweise anwenden ↓ Ergebnis kontrollieren ↓ Arbeit dokumentieren ↓ Verbesserung ableiten Eine spätere interaktive Darstellung kann typische Arbeitssituationen anbieten und direkt zu den passenden Themenbereichen führen. Verwandte Seiten 0.1 Über dieses Buch – Ziel, Arbeitsweise und Qualitätsmaßstab 0.3 Kennzeichnungen, Quellen und Versionsstände 0.4 Aktualisierungen, Versionspflege und Korrekturen 1.1 Warum professionelles Service Management notwendig ist 1.2 Technik, Produkt, Service und Geschäftsergebnis professionelle Ticketbearbeitung Fehleranalyse und Troubleshooting Quellen und Versionsstand Diese Seite beschreibt die Nutzung und den redaktionellen Aufbau dieses unabhängigen Nachschlagewerks. Die dargestellten Nutzungswege, Seitenarten, Checklisten und Suchstrategien sind Festlegungen dieses Buchprojekts und keine vorgeschriebenen ITIL-Prozesse. Offizielle ITIL-Begriffe und Practices werden auf den jeweiligen Fachseiten anhand aktueller offizieller Quellen erläutert. Fachlicher Stand: August 2026 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 0.4 Aktualisierungen, Versionspflege und Korrekturen Kurz erklärt Dieses Buch wird als langfristiges Lern-, Arbeits- und Nachschlagewerk aufgebaut. Inhalte werden deshalb nicht nur einmal erstellt, sondern regelmäßig geprüft, aktualisiert und bei Bedarf korrigiert. Dabei soll nachvollziehbar bleiben: wann eine Seite zuletzt fachlich geprüft wurde, auf welche Versionen sie sich bezieht, welche Inhalte verändert wurden, warum eine Änderung notwendig war, und welche Punkte möglicherweise noch nicht abschließend geklärt sind. Warum eine kontinuierliche Pflege notwendig ist IT-Wissen verändert sich. Neue Versionen können: Begriffe verändern, Funktionen ergänzen, bisherige Vorgehensweisen ersetzen, Sicherheitsanforderungen verändern, Menüpfade anpassen, Befehle erweitern oder entfernen, Standards aktualisieren, und neue technische Abhängigkeiten erzeugen. Auch digitales Produkt- und Service-Management entwickelt sich weiter. Zusätzlich können sich betriebliche Anforderungen verändern, beispielsweise durch: neue Produkte und Services, andere Organisationsstrukturen, geänderte Verantwortlichkeiten, neue gesetzliche oder vertragliche Anforderungen, Sicherheitsvorfälle, neue Herstellerprodukte, veränderte Lieferantenbeziehungen, oder Erfahrungen aus dem laufenden Betrieb. Ein dauerhaft hilfreiches Nachschlagewerk muss solche Veränderungen berücksichtigen. Grundsatz Eine Wissensseite ist nicht endgültig abgeschlossen. Sie beschreibt den fachlich geprüften Stand zu einem bestimmten Zeitpunkt. Erstellung, Bearbeitung, Prüfung und Test unterscheiden Die folgenden Angaben beschreiben unterschiedliche Zustände einer Seite. Angabe Bedeutung Erstellt am Datum, an dem die Seite erstmals angelegt wurde Zuletzt bearbeitet Datum der letzten inhaltlichen oder redaktionellen Änderung Fachlich geprüft am Datum der letzten vollständigen fachlichen Kontrolle Technisch getestet am Datum eines dokumentierten praktischen Tests Behandelte Version Version des Frameworks, Produkts oder Systems Nächste Prüfung empfohlen Zeitpunkt oder Anlass für eine erneute Kontrolle Bekannte Einschränkungen Bedingungen, unter denen eine Aussage möglicherweise nicht gilt Offene Punkte noch nicht abschließend geklärte Fragen Eine reine Textkorrektur ist nicht automatisch eine vollständige fachliche Prüfung. Beispiel Am 10. August wurde ein Rechtschreibfehler behoben. Die letzte vollständige fachliche Prüfung kann trotzdem weiterhin vom 1. August stammen. Ebenso ist eine fachlich geprüfte Anleitung nicht automatisch technisch getestet. Eine technische Durchführung kann außerdem nur das Verhalten der tatsächlich verwendeten Testumgebung bestätigen. Fachlicher Stand einer Seite Am Ende einer Fachseite wird nach Möglichkeit ein fachlicher Stand angegeben. Beispiel: Fachlicher Stand: August 2026 Behandelte Hauptversion: ITIL Version 5 Zusätzlich berücksichtigt: ITIL 4 Bei technischen Seiten können weitere Angaben notwendig sein. Beispiel: Getestetes Betriebssystem: Ubuntu Server 24.04 LTS Getestete Softwareversion: Beispielsoftware 5.2 Bereitstellungsart: Docker Architektur: ARM64 Technisch getestet am: 01.08.2026 Die Angaben sollen dem Leser helfen einzuschätzen: wie aktuell die Information ist, für welche Version sie gilt, ob sie praktisch getestet wurde, und ob sie zur eigenen Umgebung passt. Merke Das Bearbeitungsdatum einer Seite sagt allein noch nichts über ihre fachliche Aktualität aus. Welche Inhalte besonders häufig geprüft werden müssen Nicht jede Information verändert sich gleich schnell. Informationsart Typischer Prüfungsanlass grundlegende ITIL-Konzepte neue offizielle Framework-Veröffentlichung offizielle Begriffe und Modelle Versionswechsel oder geänderte Definition Practice-Beschreibungen neue oder überarbeitete offizielle Practice Guidance technische Menüpfade neue Software- oder Firmwareversion Befehle und Optionen Versions-, Betriebssystem- oder Plattformwechsel Herstellerempfehlungen geänderte offizielle Dokumentation Sicherheitsmaßnahmen neue Schwachstelle, Warnung oder Empfehlung gesetzliche Anforderungen Änderung der Rechtslage vertragliche Anforderungen neuer oder geänderter Vertrag Community-Lösungen vor jeder produktiven Wiederverwendung eigene Testergebnisse neue Version oder abweichende Umgebung allgemeine technische Grundlagen fachlicher Anlass oder erkannter Fehler Grundsatz Je stärker eine Aussage von einer bestimmten Version, einem Hersteller oder einer aktuellen Sicherheitslage abhängt, desto häufiger muss sie geprüft werden. Anlässe für eine Aktualisierung Eine Seite sollte überprüft werden, wenn mindestens einer der folgenden Fälle eintritt: Eine neue ITIL-Version erscheint. Eine offizielle Definition wird geändert. Eine Management Practice wird überarbeitet. Ein Hersteller veröffentlicht eine relevante neue Version. Eine verwendete Funktion wird als veraltet gekennzeichnet. Ein Befehl oder Menüpfad funktioniert nicht mehr. Eine Sicherheitslücke oder Sicherheitswarnung wird bekannt. Eine verwendete Quelle wird entfernt oder ersetzt. Eine Empfehlung erweist sich als unvollständig oder ungeeignet. Eine technische Anleitung liefert in der Praxis ein anderes Ergebnis. Ein Praxisfall zeigt einen bislang nicht berücksichtigten Sonderfall. Ein Leser meldet einen möglichen Fehler. Andere Seiten enthalten widersprüchliche Angaben. Eine betriebliche Erfahrung liefert eine bessere Vorgehensweise. Eine vollständige Überarbeitung ist nicht bei jeder kleinen Änderung notwendig. Entscheidend ist, ob die Änderung: das fachliche Verständnis, die praktische Vorgehensweise, die Sicherheit, das Risiko, die Gültigkeit einer Aussage, oder das erwartete Ergebnis beeinflusst. Arten von Änderungen Änderungen werden nach ihrer Bedeutung unterschieden. Änderungsart Beispiel Änderungsvermerk Redaktionelle Änderung Rechtschreibung, Formatierung oder bessere Lesbarkeit normalerweise nicht erforderlich Kleine fachliche Präzisierung missverständliche Formulierung genauer erklärt kurzer Hinweis sinnvoll Fachliche Korrektur falsche Definition oder Zuordnung berichtigt erforderlich Technische Aktualisierung neuer Befehl, Menüpfad oder Versionshinweis erforderlich Sicherheitsrelevante Korrektur riskante Empfehlung entfernt oder abgesichert deutlich dokumentieren Strukturelle Überarbeitung Seite aufgeteilt, zusammengeführt oder neu eingeordnet Querverweise aktualisieren Framework-Aktualisierung neue ITIL-Version berücksichtigt Versionshinweis erforderlich Archivierung Inhalt gilt nur noch für ältere Systeme deutlich kennzeichnen Redaktionelle Änderungen Redaktionelle Änderungen verändern nicht die fachliche Bedeutung. Dazu gehören beispielsweise: Rechtschreibkorrekturen, bessere Satzstruktur, einheitliche Formatierung, übersichtlichere Tabellen, verbesserte Verlinkungen, und verständlichere Überschriften. Solche Änderungen benötigen normalerweise keinen ausführlichen Änderungsvermerk. Das Datum der letzten Bearbeitung kann sich dennoch ändern. Fachliche Präzisierungen Eine fachliche Präzisierung ist notwendig, wenn eine Aussage grundsätzlich richtig, aber zu allgemein oder missverständlich formuliert ist. Beispiel: Unpräzise: Die Priorität eines Incidents ergibt sich aus Auswirkung und Dringlichkeit. Präziser: Viele Organisationen verwenden Auswirkung und Dringlichkeit als Kriterien für die Priorisierung von Incidents. Die konkrete Bewertungsmethode und Prioritätsmatrix werden von der jeweiligen Organisation festgelegt. Die Präzisierung verhindert den falschen Eindruck, dass jede Organisation zwingend dieselbe Berechnung oder Matrix verwenden müsse. Fachliche Korrekturen Wird eine fachlich falsche Aussage erkannt, wird nicht nur der einzelne Satz ersetzt. Zusätzlich muss geprüft werden: Hat der Fehler andere Abschnitte beeinflusst? Verweisen andere Seiten auf die falsche Aussage? Ist eine Tabelle oder Checkliste betroffen? Wurde daraus eine Handlungsempfehlung abgeleitet? Kann die Aussage ein Sicherheitsrisiko verursachen? Muss ein Praxisbeispiel angepasst werden? Muss ein Versionshinweis ergänzt werden? Müssen Suchbegriffe oder Seitentitel geändert werden? Wichtig Bei sicherheitsrelevanten oder potenziell schädlichen Fehlern hat die Korrektur Vorrang vor redaktionellen Verbesserungen. Wesentliche Fehler nicht stillschweigend verbergen Kleine sprachliche Fehler können ohne gesonderten Hinweis korrigiert werden. Wesentliche fachliche Änderungen sollen nachvollziehbar bleiben. Ein Änderungsvermerk ist insbesondere sinnvoll, wenn: eine frühere Aussage fachlich falsch war, sich eine offizielle Definition geändert hat, eine Empfehlung nicht mehr unterstützt wird, eine Sicherheitsgefahr bestand, eine technische Anleitung ersetzt wurde, sich eine Versionszuordnung geändert hat, oder sich die Bedeutung eines Abschnitts wesentlich verändert hat. Beispiel: Änderung vom 12.08.2026 Die bisherige Aussage zur Priorisierung wurde präzisiert. Prioritäten werden nicht allein anhand der technischen Schwere eines Fehlers bestimmt. Die jeweilige Organisation legt fest, welche Kriterien verwendet und wie diese bewertet werden. Grundsatz Eine nachvollziehbare Korrektur erhöht die Qualität und Glaubwürdigkeit eines Nachschlagewerks. Änderungsprotokoll Bei umfangreichen, häufig verwendeten oder besonders wichtigen Seiten kann ein kompaktes Änderungsprotokoll geführt werden. Datum Art Änderung Grund 01.08.2026 Ersterstellung Seite angelegt Aufbau des Nachschlagewerks 12.08.2026 Präzisierung Begriff genauer abgegrenzt missverständliche Formulierung 20.09.2026 Aktualisierung neue Framework-Version berücksichtigt offizielle Veröffentlichung 05.10.2026 Korrektur Handlungsempfehlung ersetzt Abgleich mit einer Primärquelle Nicht jede Rechtschreib- oder Formatierungsänderung benötigt einen Eintrag. Dokumentiert werden vor allem Änderungen, die: eine fachliche Aussage verändern, eine Handlungsempfehlung betreffen, ein Sicherheitsrisiko korrigieren, einen Versionswechsel berücksichtigen, oder die Bedeutung eines Abschnitts wesentlich verändern. Empfohlener Änderungsvermerk Für wichtige Änderungen kann folgende Struktur verwendet werden: Änderungsvermerk Datum: Art der Änderung: Betroffener Abschnitt: Bisherige Aussage: Korrigierte Aussage: Grund der Änderung: Verwendete Quelle: Auswirkung auf andere Seiten: Nicht benötigte Felder können weggelassen werden. Umgang mit unterschiedlichen ITIL-Versionen Bei einer neuen ITIL-Version wird nicht automatisch der gesamte ältere Inhalt gelöscht. Stattdessen wird geprüft: Ist die bisherige Aussage weiterhin fachlich gültig? Wurde nur die Bezeichnung geändert? Hat sich die Definition verändert? Wurde ein Modell ersetzt, erweitert oder neu eingeordnet? Wird die ältere Version weiterhin in Organisationen verwendet? Ist die Unterscheidung für Praxis oder Prüfung relevant? Muss eine Vergleichstabelle ergänzt werden? Sind Querverweise oder Seitentitel betroffen? Beispiel: Versionshinweis In ITIL Version 5 heißt die Practice Change Management . In ITIL 4 wurde sie Change Enablement genannt. Älteres Wissen kann erhalten bleiben, wenn es weiterhin relevant ist und eindeutig einer Version zugeordnet wird. Typischer Fehler Ein gleich oder ähnlich klingender Begriff wird ohne Prüfung als vollständig identisch mit dem Begriff einer anderen Version behandelt. Umgang mit technischen Versionen Technische Anleitungen werden nach Möglichkeit auf eine konkrete Umgebung bezogen. Beispiel: Getestete Umgebung Betriebssystem: Debian 13 Anwendung: Beispielsoftware 4.2 Bereitstellung: Docker Architektur: ARM64 Testdatum: 01.08.2026 Bei einer neuen Version ist unter anderem zu prüfen: Existiert der Befehl weiterhin? Wurde eine Option umbenannt? Hat sich ein Standardpfad verändert? Gibt es neue Voraussetzungen? Wurde eine Funktion entfernt? Hat sich das Berechtigungsmodell geändert? Sind neue Abhängigkeiten entstanden? Hat sich das unterstützte Betriebssystem geändert? Sind neue Sicherheitsrisiken bekannt? Funktioniert die Rückfall- oder Wiederherstellungsmethode weiterhin? Eine Anleitung ist nicht allein deshalb aktuell, weil die Seite kürzlich bearbeitet wurde. Fachlich geprüft und technisch getestet Diese beiden Angaben dürfen nicht gleichgesetzt werden. Status Aussage Fachlich geprüft Die Aussagen wurden mit geeigneten Quellen und Fachwissen kontrolliert. Technisch getestet Die beschriebene Durchführung wurde in einer dokumentierten Umgebung praktisch geprüft. Eine Anleitung kann fachlich korrekt sein, ohne in der eigenen Umgebung getestet worden zu sein. Ein erfolgreicher Test kann wiederum nur das Verhalten der getesteten Umgebung bestätigen. Er beweist nicht automatisch: eine offizielle Unterstützung, eine allgemeine Kompatibilität, ein identisches Verhalten unter anderen Versionen, oder die Eignung für jede Produktivumgebung. Merke Ein Test beantwortet die Frage: „Was ist in dieser Umgebung passiert?“ Eine offizielle Herstellerangabe beantwortet die Frage: „Was wird offiziell beschrieben oder unterstützt?“ Umgebungsabhängige Inhalte Eine Anleitung kann fachlich richtig sein und trotzdem nicht zur eigenen Umgebung passen. Mögliche Unterschiede bestehen bei: Betriebssystem, Softwareversion, Hardwarearchitektur, Cloud- oder On-Premises-Betrieb, Hochverfügbarkeitskonzept, Netzwerkaufbau, Berechtigungsmodell, Sicherheitsrichtlinien, Mandantenstruktur, verwendeten Erweiterungen, und externen Abhängigkeiten. Vor der Übernahme einer technischen Anleitung muss deshalb geprüft werden: Gilt sie für die verwendete Version? Ist die Plattform identisch? Sind die Voraussetzungen erfüllt? Bestehen zusätzliche Abhängigkeiten? Wird eine Freigabe benötigt? Gibt es eine Testmöglichkeit? Ist ein Rückfallplan vorhanden? Wie wird der Erfolg kontrolliert? Veraltete Inhalte Veraltete Inhalte werden nicht immer sofort gelöscht. Sie können weiterhin hilfreich sein, wenn: ältere Systeme noch produktiv eingesetzt werden, eine Migration vorbereitet wird, historische Tickets untersucht werden, alte Dokumentationen verstanden werden müssen, frühere Entscheidungen nachvollzogen werden sollen, oder eine ältere Prüfungsversion behandelt wird. Solche Inhalte müssen eindeutig gekennzeichnet werden. Veraltet Die folgende Vorgehensweise bezieht sich auf eine ältere Produktversion. Sie darf nicht ungeprüft auf aktuelle Systeme übertragen werden. Situation Maßnahme Inhalt ist weiterhin nützlich ältere Version deutlich angeben Inhalt ist nur historisch relevant archivieren Inhalt ist fachlich falsch korrigieren oder entfernen Inhalt ist sicherheitsgefährdend sofort entfernen und Korrekturhinweis ergänzen aktuelle Alternative vorhanden direkt auf die neue Vorgehensweise verweisen mehrere Versionen werden verwendet Inhalte eindeutig voneinander trennen Archivieren statt unkontrolliert löschen Eine ältere Seite kann weiterhin Informationen enthalten, die für folgende Aufgaben wichtig sind: Wartung von Altsystemen, Analyse früherer Störungen, Verständnis alter Konfigurationen, Migrationen, Audits, und Nachvollziehen früherer Entscheidungen. Vor dem Löschen sollte deshalb geprüft werden: Wird die Information noch benötigt? Gibt es produktive Systeme mit dieser Version? Verweisen andere Seiten darauf? Ist die Historie für einen späteren Vergleich hilfreich? Enthält die Seite noch gültige Teilinformationen? Kann sie eindeutig als veraltet oder archiviert gekennzeichnet werden? Praxistipp Veraltete Inhalte dürfen nicht unauffällig zwischen aktuellen Anleitungen stehen. Eine eindeutige Archiv- oder Versionskennzeichnung verhindert Fehlanwendungen. Offene und noch nicht abschließend geprüfte Punkte Nicht jeder Sachverhalt kann sofort vollständig geklärt werden. Offene Punkte dürfen dokumentiert werden, müssen aber eindeutig erkennbar sein. Noch zu prüfen Für diesen Sonderfall liegt derzeit keine ausreichend eindeutige offizielle Quelle vor. Vor einer produktiven Anwendung ist eine zusätzliche Prüfung erforderlich. Ein offener Punkt sollte möglichst enthalten: die konkrete Fragestellung, bisherige Erkenntnisse, die fehlende Information, benötigte Quelle oder Testumgebung, mögliche Risiken, und den nächsten Prüfschritt. Ungeeignet ist eine unklare Notiz wie: Später noch einmal prüfen. Besser ist: Zu prüfen ist, ob die Funktion ab Version 5.2 auch auf ARM64 offiziell unterstützt wird. Bisher liegt nur ein Community-Bericht vor. Prüfstatus einer Seite Für umfangreiche oder kritische Inhalte können folgende Statusangaben verwendet werden: Status Bedeutung Entwurf Inhalt befindet sich noch im Aufbau In Prüfung fachliche Kontrolle ist noch nicht abgeschlossen Fachlich geprüft Inhalt wurde gegen geeignete Quellen geprüft Technisch getestet praktische Durchführung wurde dokumentiert getestet Aktualisierung erforderlich Inhalt könnte nicht mehr aktuell sein Veraltet Inhalt bezieht sich ausdrücklich auf einen älteren Stand Archiviert Inhalt wird hauptsächlich aus historischen Gründen aufbewahrt Ein Status darf nur verwendet werden, wenn seine Voraussetzungen erfüllt sind. Eine automatisch erzeugte oder oberflächlich gelesene Seite gilt nicht als vollständig fachlich geprüft. Wann eine erneute Prüfung erforderlich ist Eine Seite sollte erneut geprüft werden, wenn: die angegebene Version nicht mehr aktuell ist, eine neue offizielle Veröffentlichung vorliegt, ein möglicher Fehler gemeldet wurde, eine verwendete Quelle nicht mehr erreichbar ist, der Hersteller seine Dokumentation geändert hat, eine Handlung in der Praxis ein anderes Ergebnis liefert, neue Sicherheitsinformationen vorliegen, andere Seiten widersprüchliche Angaben enthalten, oder sich die betriebliche Umgebung wesentlich verändert hat. Zusätzlich kann eine anlassbezogene Prüfung sinnvoll sein: Seitenart Geeigneter Prüfungsanlass ITIL-Grundlagen neue offizielle Framework-Version Practice-Seiten neue oder überarbeitete Practice Guidance Sicherheitsrelevante Anleitung neue Schwachstelle oder Sicherheitsempfehlung Softwareanleitung relevante neue Hauptversion Herstellerabhängige Konfiguration neue Firmware oder geänderte Dokumentation Community-basierte Lösung vor jeder produktiven Verwendung Checkliste nach realer Anwendung und festgestellten Lücken Vorlage bei geänderten betrieblichen Anforderungen Risikobasierte Priorisierung von Aktualisierungen Nicht alle veralteten Seiten sind gleich dringend. Die Aktualisierung sollte zuerst dort erfolgen, wo ein Fehler große Auswirkungen verursachen kann. Priorität Typische Inhalte Sehr hoch Sicherheitsmaßnahmen, Wiederherstellung, Berechtigungen und produktive Änderungen Hoch Incident-Bearbeitung, Eskalation, Backup, Change und Notfallverfahren Mittel Produktkonfigurationen, technische Anleitungen und Menüpfade Niedrig allgemeine Beispiele, stilistische Verbesserungen und historische Informationen Ein veralteter Screenshot besitzt normalerweise eine geringere Priorität als eine fehlerhafte Anleitung zur Wiederherstellung eines Backups. Grundsatz Aktualisierungen werden nicht nur nach Alter, sondern vor allem nach Risiko und möglicher Auswirkung priorisiert. Meldung eines möglichen Fehlers Eine Fehlermeldung sollte möglichst konkrete Informationen enthalten. Hilfreich sind: betroffene Seite, betroffener Abschnitt, vermuteter Fehler, verwendete Quelle, behandelte Version, technische Umgebung, beobachtetes Verhalten, und eine mögliche Korrektur. Beispiel: Möglicher Fehler Seite: Change Management Abschnitt: Standard Change Problem: Die Formulierung kann so verstanden werden, dass jeder Standard Change vor jeder Durchführung erneut genehmigt werden muss. Vorgeschlagene Prüfung: Definition und Freigabemodell anhand der aktuellen offiziellen Practice Guidance vergleichen. Eine Fehlermeldung führt nicht automatisch zu einer Änderung. Sie löst zunächst eine fachliche Prüfung aus. Ablauf einer fachlichen Korrektur Vorgehensweise möglichen Fehler dokumentieren betroffene Aussage eingrenzen bisherige Quelle prüfen geeignete Primärquellen vergleichen Version und Umgebung berücksichtigen Auswirkungen auf andere Inhalte prüfen Korrektur formulieren Änderungsvermerk ergänzen Querverweise, Tabellen und Checklisten aktualisieren fachlichen Stand anpassen Ablauf einer Versionsaktualisierung Vorgehensweise neue Version und offizielle Änderungen erfassen betroffene Seiten identifizieren Begriffe, Definitionen und Modelle vergleichen technische oder organisatorische Auswirkungen bewerten weiterhin gültige Inhalte bestimmen veraltete Inhalte aktualisieren oder archivieren Praxisbeispiele und Entscheidungshilfen prüfen Checklisten und Vorlagen anpassen Quellen und Querverweise aktualisieren Versions- und Änderungsvermerk ergänzen Checkliste vor einer Aktualisierung 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