# 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: 1. **Verstehen** 2. **Anwenden** 3. **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: 1. **Verstehen** – Begriffe, Ziele und Zusammenhänge erfassen. 2. **Anwenden** – Wissen in konkrete Handlungen und Entscheidungen übertragen. 3. **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: 1. Grundlagen des professionellen Service Managements 2. zentrale Begriffe wie Produkt, Service, Wert, Outcome, Kosten und Risiken 3. Aufbau und Denkweise von ITIL 4. Produkte, Services, Wertströme und Lebenszyklus 5. Zusammenarbeit mit Benutzern, Kunden und weiteren Stakeholdern 6. professionelle Ticketbearbeitung 7. wichtige ITIL Practices 8. typische Situationen aus dem IT-Betrieb 9. 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: 1. konkrete Situation erfassen 2. betroffenen Service bestimmen 3. betroffene Benutzer und Auswirkungen ermitteln 4. nach Service, Fehlermeldung oder beobachtetem Verhalten suchen 5. passende Praxis- oder Schnellreferenzseite öffnen 6. Voraussetzungen und wichtigste Rückfragen prüfen 7. geeignete Vorgehensweise auswählen 8. Sicherheits-, Eskalations- und Freigabekriterien beachten 9. durchgeführte Schritte und Ergebnisse dokumentieren 10. bei Bedarf technische Querverweise verwenden 11. 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: 1. unmittelbare Gefahren und Sicherheitsrisiken erkennen 2. betroffenen Service bestimmen 3. Auswirkungen und Dringlichkeit feststellen 4. Zuständigkeit und Eskalation klären 5. Service stabilisieren oder wiederherstellen 6. Beteiligte angemessen informieren 7. wesentliche Beobachtungen und Maßnahmen dokumentieren 8. Erfolg der Wiederherstellung kontrollieren 9. 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** > 1. Situation erfassen > 2. betroffenen Service bestimmen > 3. Auswirkungen und Dringlichkeit bewerten > 4. passende Seite finden > 5. Voraussetzungen und Risiken prüfen > 6. geeignete Vorgehensweise anwenden > 7. Ergebnis kontrollieren > 8. Arbeit dokumentieren > 9. notwendige Folgeaktivitäten einleiten > 10. 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: 1. Product and Service Management Practices 2. General Management Practices Die Practices wurden gegenüber ITIL 4 nicht vollständig ersetzt, sondern für die neue Version angepasst und neu eingeordnet. > **Wichtig** > > Die Einordnung einer Practice in ITIL Version 5 darf nicht allein aus älteren ITIL-4-Übersichten übernommen werden. > > Bei einer versionsabhängigen Aussage muss die aktuelle offizielle Quelle geprüft werden. --- **Framework-Version und betriebliche Umsetzung unterscheiden** Die verwendete ITIL-Version bestimmt nicht automatisch, wie 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: 1. Welche Quelle ist primär oder offiziell? 2. Auf welche Version bezieht sich die jeweilige Aussage? 3. Wann wurde die Quelle veröffentlicht oder aktualisiert? 4. Behandeln die Quellen wirklich dieselbe Funktion und Umgebung? 5. Wurde eine ältere Empfehlung später ersetzt? 6. Ist nur eine bestimmte Konfiguration betroffen? 7. Kann die Abweichung reproduziert werden? 8. 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: 1. Ist die bisherige Aussage weiterhin fachlich gültig? 2. Wurde nur die Bezeichnung geändert? 3. Hat sich die Definition verändert? 4. Wurde ein Modell ersetzt, erweitert oder neu eingeordnet? 5. Wird die ältere Version weiterhin in Organisationen verwendet? 6. Ist die Unterscheidung für Praxis oder Prüfung relevant? 7. Muss eine Vergleichstabelle ergänzt werden? 8. 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** > > 1. möglichen Fehler dokumentieren > 2. betroffene Aussage eingrenzen > 3. bisherige Quelle prüfen > 4. geeignete Primärquellen vergleichen > 5. Version und Umgebung berücksichtigen > 6. Auswirkungen auf andere Inhalte prüfen > 7. Korrektur formulieren > 8. Änderungsvermerk ergänzen > 9. Querverweise, Tabellen und Checklisten aktualisieren > 10. fachlichen Stand anpassen --- **Ablauf einer Versionsaktualisierung** > **Vorgehensweise** > > 1. neue Version und offizielle Änderungen erfassen > 2. betroffene Seiten identifizieren > 3. Begriffe, Definitionen und Modelle vergleichen > 4. technische oder organisatorische Auswirkungen bewerten > 5. weiterhin gültige Inhalte bestimmen > 6. veraltete Inhalte aktualisieren oder archivieren > 7. Praxisbeispiele und Entscheidungshilfen prüfen > 8. Checklisten und Vorlagen anpassen > 9. Quellen und Querverweise aktualisieren > 10. 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](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) - [PeopleCert: ITIL Foundation Version 5 – What’s New?](https://www.peoplecert.org/news-and-announcements/itil-version-5-foundation-whats-new-guide) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/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