# ITIL in der Praxis # 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 # 1. Grundlagen des professionellen Service Managements # 1.1 Warum professionelles Service Management notwendig ist > **Kurz erklärt** > > Unternehmen und öffentliche Einrichtungen sind in hohem Maß von digitalen Produkten und Services abhängig. > > Ein funktionierender Server allein erzeugt jedoch noch keinen verlässlichen Service. Erst das abgestimmte Zusammenspiel von Technik, Menschen, Arbeitsweisen, Informationen und externen Partnern ermöglicht stabile und nutzbare IT-Services. > > Professionelles Service Management hilft dabei, dieses Zusammenspiel planbar, nachvollziehbar und kontinuierlich verbesserbar zu gestalten. --- **Vom technischen System zum nutzbaren Service** Fachinformatiker für Systemintegration arbeiten täglich mit technischen Komponenten wie: - Servern, - Netzwerken, - Betriebssystemen, - Benutzerkonten, - Verzeichnisdiensten, - Cloud-Plattformen, - Anwendungen, - Datenbanken, - Backups, - Firewalls, - und Monitoring-Systemen. Für Benutzer und Organisationen ist jedoch normalerweise nicht die einzelne technische Komponente entscheidend. Sie benötigen einen funktionierenden Service. | Technische Komponenten | Unterstützter Service | |---|---| | Domain Controller, DNS, Netzwerk und Benutzerkonto | Anmeldung am Arbeitsplatz | | Mailplattform, Identitätsdienst, DNS und Internetzugang | E-Mail-Kommunikation | | Fileserver, Berechtigungen, Netzwerk und Backup | zentrale Dateiablage | | VPN-Gateway, Firewall, MFA und Benutzerkonto | sicherer Fernzugriff | | Webserver, Datenbank, Zertifikat und DNS | Unternehmensanwendung | | Druckserver, Treiber, Netzwerk und Drucker | zentraler Druckservice | Ein Service kann aus vielen technischen und organisatorischen Bestandteilen bestehen. Fällt eine wichtige Abhängigkeit aus, kann der gesamte Service für den Benutzer nicht mehr nutzbar sein. > **Merke** > > Benutzer nehmen normalerweise keinen einzelnen Server oder Netzwerkdienst wahr. > > Sie nehmen wahr, ob sie ihre Arbeit ausführen können. --- **Warum technische Kompetenz allein nicht ausreicht** Technisches Fachwissen ist unverzichtbar. Es hilft unter anderem dabei: - Fehler zu analysieren, - Systeme zu konfigurieren, - Dienste wiederherzustellen, - Netzwerke zu betreiben, - Sicherheitsmaßnahmen umzusetzen, - technische Ursachen zu ermitteln, - und Systeme zuverlässig zu betreiben. Im laufenden IT-Betrieb müssen zusätzlich organisatorische und servicebezogene Fragen beantwortet werden: - Welcher Service ist betroffen? - Wer verwendet diesen Service? - Welche Benutzer oder Geschäftsprozesse sind beeinträchtigt? - Wie groß sind die Auswirkungen? - Wie dringend ist die Wiederherstellung? - Wer trägt die Verantwortung? - Welche Abhängigkeiten bestehen? - Wurde kürzlich etwas verändert? - Wer muss informiert werden? - Gibt es eine geeignete Zwischenlösung? - Was muss dokumentiert werden? - Ist nach der Wiederherstellung eine Ursachenanalyse notwendig? - Wie kann eine Wiederholung verhindert werden? Diese Fragen können nicht allein durch einen technischen Befehl oder ein Administrationswerkzeug beantwortet werden. Dafür wird eine abgestimmte Arbeitsweise benötigt. --- **Was professionelles Service Management leistet** Professionelles Service Management schafft einen gemeinsamen Rahmen für die Planung, Bereitstellung, Unterstützung, Steuerung und Verbesserung von Services. Es unterstützt insbesondere dabei: - Services und Verantwortlichkeiten zu bestimmen, - Anforderungen und Erwartungen zu verstehen, - Störungen einheitlich zu erfassen, - Arbeit nach vereinbarten Kriterien zu priorisieren, - Änderungen kontrolliert durchzuführen, - Informationen zwischen Teams auszutauschen, - Abhängigkeiten sichtbar zu machen, - Wissen dauerhaft bereitzustellen, - Leistung und Qualität zu bewerten, - Kosten und Risiken zu berücksichtigen, - externe Partner einzubinden, - und Verbesserungen systematisch umzusetzen. ITIL stellt hierfür ein anpassbares Best-Practice-Framework bereit. ITIL Version 5 betrachtet digitales Produkt- und Service-Management stärker als zusammenhängende Aufgabe. Dadurch sollen Produkt-, Entwicklungs-, Betriebs-, Support- und Serviceteams besser zusammenarbeiten und Entscheidungen stärker an Outcomes und Wert ausrichten. > **ITIL-Grundlage** > > ITIL ist kein starres Regelwerk. > > Die Inhalte müssen an Ziele, Größe, Risiken, Fähigkeiten und Arbeitsweise der jeweiligen Organisation angepasst werden. --- **Service Management ist mehr als ein Ticketsystem** Ein Ticketsystem kann Service Management unterstützen. Es kann beispielsweise: - Meldungen erfassen, - Vorgänge kategorisieren, - Prioritäten speichern, - Zuständigkeiten zuweisen, - Bearbeitungsstände anzeigen, - Kommunikation dokumentieren, - Fristen überwachen, - und Auswertungen bereitstellen. Das Ticketsystem allein sorgt jedoch nicht automatisch für professionelles Service Management. Zusätzlich muss geklärt sein: - Welche Vorgangsarten gibt es? - Welche Informationen müssen erfasst werden? - Wie werden Vorgänge kategorisiert? - Nach welchen Kriterien werden Prioritäten bestimmt? - Wer übernimmt welche Aufgabe? - Wann wird eskaliert? - Wie werden Benutzer informiert? - Wann gilt ein Vorgang als gelöst oder abgeschlossen? - Welche Informationen werden für spätere Verbesserungen verwendet? > **Typischer Fehler** > > Die Einführung eines Ticketsystems wird mit der Einführung von Service Management gleichgesetzt. > > Ein Werkzeug kann eine Arbeitsweise unterstützen, aber keine fehlenden Verantwortlichkeiten, Regeln oder Entscheidungen ersetzen. --- **Service Management ist keine einzelne Practice** Professionelles Service Management besteht nicht nur aus Incident Management oder Ticketbearbeitung. Es verbindet verschiedene Management Practices und Arbeitsbereiche, beispielsweise: - Service Desk, - Incident Management, - Service Request Management, - Problem Management, - Change Management, - Knowledge Management, - Service Configuration Management, - IT Asset Management, - Monitoring and Event Management, - Service Level Management, - Supplier Management, - Information Security Management, - Relationship Management, - und Continual Improvement. Diese Practices können innerhalb eines Vorgangs zusammenwirken. Beispiel: 1. Das Monitoring erkennt den Ausfall eines Webdienstes. 2. Ein Incident wird erfasst. 3. Betroffene Benutzer werden informiert. 4. Die technische Analyse stellt eine fehlerhafte Konfiguration fest. 5. Eine Zwischenlösung stellt den Service wieder her. 6. Ein Problem Record wird für die weitere Ursachenanalyse angelegt. 7. Eine dauerhafte Korrektur wird als Change geplant und umgesetzt. 8. Die Lösung wird im Wissensmanagement dokumentiert. 9. Monitoring und Arbeitsanweisungen werden verbessert. Keiner dieser Schritte ersetzt die technische Fehleranalyse. Die beteiligten Practices helfen jedoch dabei, die technische Arbeit koordiniert, nachvollziehbar und nachhaltig durchzuführen. --- **Was ohne gemeinsame Arbeitsweise häufig passiert** Fehlt eine abgestimmte Service-Management-Arbeitsweise, können typische Schwierigkeiten entstehen. | Situation | Mögliche Folge | |---|---| | Meldungen erfolgen nur telefonisch oder per Zuruf. | Vorgänge gehen verloren oder werden nicht nachvollziehbar dokumentiert. | | Jeder Mitarbeiter priorisiert nach eigenem Gefühl. | Lautstärke oder persönliche Nähe bestimmen die Reihenfolge. | | Verantwortlichkeiten sind unklar. | Vorgänge werden weitergereicht oder bleiben unbearbeitet. | | Änderungen werden nicht dokumentiert. | Spätere Störungen lassen sich nur schwer mit früheren Eingriffen verbinden. | | Lösungen bleiben im Wissen einzelner Mitarbeiter. | Kollegen führen dieselbe Analyse wiederholt durch. | | Teams betrachten nur ihre eigene Komponente. | Die tatsächliche Serviceauswirkung wird übersehen. | | Benutzer erhalten keine Statusinformationen. | Unsicherheit und zusätzliche Rückfragen erhöhen den Arbeitsaufwand. | | Wiederkehrende Incidents werden nur einzeln behoben. | Die zugrunde liegende Ursache bleibt bestehen. | | Kennzahlen betrachten nur Ticketmengen. | Ergebnisse, Nutzen und Servicequalität bleiben unklar. | | Externe Dienstleister werden zu spät eingebunden. | Eskalation und Wiederherstellung verzögern sich. | > **Praxistipp** > > Wenn mehrere Mitarbeiter denselben Vorgang grundlegend unterschiedlich bearbeiten würden, fehlt möglicherweise eine gemeinsame oder ausreichend dokumentierte Arbeitsweise. --- **Praxisbeispiel: Der E-Mail-Service ist gestört** Mehrere Benutzer melden, dass sie keine E-Mails senden können. Eine technische Betrachtung könnte mit folgenden Prüfungen beginnen: - Mailplattform prüfen, - Warteschlangen kontrollieren, - DNS-Auflösung testen, - Zertifikate kontrollieren, - Identitätsdienst prüfen, - Internetverbindung untersuchen. Diese Prüfungen sind notwendig. Professionelles Service Management ergänzt weitere Fragen. **Servicebezogene Einordnung** - Ist nur das Senden oder auch das Empfangen betroffen? - Sind einzelne Benutzer, ein Standort oder die gesamte Organisation betroffen? - Welche Geschäftsbereiche sind besonders abhängig? - Welche Servicezeiten und Vereinbarungen gelten? - Welche Priorität ergibt sich aus den festgelegten Kriterien? - Handelt es sich um einen Major Incident? - Wer übernimmt die Koordination? **Kommunikation** - Welche Benutzer müssen informiert werden? - In welchen Abständen werden Statusinformationen benötigt? - Welche alternative Kommunikationsmöglichkeit steht zur Verfügung? - Wer kommuniziert mit Führungskräften, Kunden oder Partnern? **Technische Bearbeitung** - Welche Komponenten gehören zum Service? - Gab es kürzlich einen Change? - Welche Monitoring-Meldungen liegen vor? - Ist ein externer Provider beteiligt? - Gibt es einen bekannten Fehler oder eine geeignete Zwischenlösung? **Nach der Wiederherstellung** - Wurde die Funktion technisch geprüft? - Wurde die Funktion aus Benutzersicht geprüft? - Sind alle Warteschlangen vollständig verarbeitet? - Ist die Ursache bereits verstanden? - Muss ein Problem Record angelegt werden? - Muss ein Wissensartikel erstellt oder ergänzt werden? - Müssen Monitoring oder Alarmierung angepasst werden? > **Hinweis** > > Ein Major Incident ist ein besonders schwerwiegender Incident. > > Die Kriterien, Rollen, Kommunikationswege und Eskalationsverfahren werden von der jeweiligen Organisation festgelegt. Major Incident Management wird hier nicht als eigenständige ITIL Practice behandelt. > **Merke** > > Die technische Wiederherstellung ist ein zentraler Teil der Arbeit. > > Professionelles Service Management sorgt dafür, dass Auswirkungen, Kommunikation, Verantwortung, Dokumentation und Verbesserung ebenfalls berücksichtigt werden. --- **Lokale Optimierung kann dem gesamten Service schaden** Ein einzelnes Team kann seine technische Aufgabe korrekt erfüllen und trotzdem den gesamten Service beeinträchtigen. Beispiel: Ein Netzwerkadministrator verschärft eine Firewall-Regel. Die Änderung kann die Sicherheit einer einzelnen Komponente verbessern. Wurde jedoch nicht geprüft, welche Anwendungen und Services von der bisherigen Verbindung abhängen, können wichtige Geschäftsprozesse ausfallen. Eine ganzheitliche Betrachtung berücksichtigt deshalb: - technische Funktion, - Serviceabhängigkeiten, - Benutzeranforderungen, - Sicherheitsziele, - betriebliche Auswirkungen, - Kosten, - Risiken, - Erfahrungen der Beteiligten, - und externe Abhängigkeiten. --- **Die vier Dimensionen** ITIL verwendet vier Dimensionen, um digitales Produkt- und Service-Management ganzheitlich zu betrachten. | Dimension | Typische Inhalte | |---|---| | **Organisationen und Menschen** | Rollen, Fähigkeiten, Kommunikation, Kultur und Verantwortlichkeiten | | **Informationen und Technologie** | Daten, Anwendungen, Infrastruktur, Wissen und Werkzeuge | | **Partner und Lieferanten** | Hersteller, Provider, Verträge und externe Abhängigkeiten | | **Wertströme und Prozesse** | Abläufe, Aktivitäten, Übergaben, Kontrollen und Zusammenarbeit | Keine Dimension sollte dauerhaft isoliert betrachtet werden. Beispiel: Eine technisch leistungsfähige Anwendung kann trotzdem scheitern, wenn: - Benutzer nicht geschult wurden, - Verantwortlichkeiten unklar sind, - ein externer Provider nicht rechtzeitig eingebunden wird, - oder der Unterstützungsprozess ungeeignet ist. > **Merke** > > Ein Serviceproblem ist nicht automatisch ausschließlich ein Technikproblem. --- **Gemeinsame Sprache statt Missverständnisse** Unterschiedliche Teams verwenden häufig unterschiedliche Begriffe. Beispiele: - Störung, - Fehler, - Problem, - Anfrage, - Auftrag, - Änderung, - Freigabe, - Eskalation, - Service, - System, - Anwendung. Werden diese Begriffe nicht einheitlich verwendet, können Missverständnisse entstehen. Ein Benutzer meldet beispielsweise ein „Problem“. Im allgemeinen Sprachgebrauch ist das verständlich. Im Service-Management-Kontext muss jedoch zunächst geprüft werden, ob es sich um: - einen Incident, - einen Service Request, - ein Problem, - ein Event, - oder einen Change handelt. Eine gemeinsame Sprache erleichtert: - eindeutige Kommunikation, - passende Zuständigkeiten, - vergleichbare Bearbeitung, - aussagekräftige Auswertungen, - und eine verlässliche Zusammenarbeit zwischen Teams. > **Wichtig** > > Benutzer müssen nicht zwingend die offiziellen ITIL-Begriffe kennen. > > Die korrekte fachliche Einordnung ist Aufgabe der zuständigen Service- und Supportorganisation. --- **Verantwortung muss über einzelne Komponenten hinausgehen** In technischen Umgebungen werden Verantwortlichkeiten häufig nach Komponenten verteilt. Beispiele: - Netzwerkteam, - Serverteam, - Datenbankteam, - Anwendungsteam, - Cloud-Team, - Informationssicherheit, - externer Provider. Ein Service kann von allen diesen Bereichen gleichzeitig abhängen. Folgende Situation ist möglich: > Netzwerk funktioniert. > Server funktioniert. > Datenbank funktioniert. > Anwendung läuft laut Monitoring. > Der Benutzer kann trotzdem nicht arbeiten. Service Management ergänzt die technische Komponentenverantwortung um eine Ende-zu-Ende-Sicht: - Funktioniert der Service aus Sicht der Benutzer? - Wird das benötigte Outcome erreicht? - Sind Übergänge und Abhängigkeiten berücksichtigt? - Wer koordiniert die Wiederherstellung? - Wer trägt Verantwortung für die Servicequalität? - Wie wird das Ergebnis überprüft? --- **Wert entsteht nicht allein durch Bereitstellung** Ein Service erzeugt nicht automatisch Wert, nur weil er technisch bereitgestellt wurde. Eine VPN-Lösung kann: - erreichbar, - sicher konfiguriert, - dokumentiert, - leistungsfähig, - und hochverfügbar sein. Wenn Benutzer jedoch: - die Anmeldung nicht verstehen, - keine geeigneten Endgeräte besitzen, - regelmäßig durch fehlerhafte MFA-Abläufe blockiert werden, - oder notwendige Anwendungen nicht verwenden können, wird das erwartete Outcome möglicherweise nicht erreicht. ITIL Version 5 betrachtet Wertschöpfung als Zusammenarbeit zwischen Service Provider, Service Consumer und weiteren Stakeholdern. Bei der Bewertung können unter anderem berücksichtigt werden: - Outcomes, - Kosten, - Risiken, - Erfahrungen, - und Nachhaltigkeit. > **Merke** > > Ein technisch verfügbarer Service ist nicht automatisch ein brauchbarer oder wertvoller Service. --- **Service Management bedeutet nicht maximale Bürokratie** ITIL schreibt Organisationen nicht vor, jeden Ablauf möglichst umfangreich zu dokumentieren. Eine Arbeitsweise muss zum jeweiligen Kontext passen. Ein kleines Unternehmen benötigt möglicherweise: - einfache Kategorien, - wenige Freigabestufen, - klare persönliche Zuständigkeiten, - und kompakte Checklisten. Eine große oder stark regulierte Organisation benötigt möglicherweise: - mehrere Supportgruppen, - formalisierte Eskalationen, - unterschiedliche Service Levels, - umfangreiche Compliance-Nachweise, - Funktionstrennungen, - und koordinierte Lieferantensteuerung. > **Grundsatz** > > So viel Struktur wie nötig, aber nicht mehr Komplexität als sinnvoll. Eine übermäßig komplizierte Arbeitsweise kann: - Bearbeitungen verzögern, - unnötige Übergaben erzeugen, - Umgehungslösungen fördern, - und den eigentlichen Nutzen aus dem Blick verlieren. Eine zu schwache Arbeitsweise kann dagegen: - Risiken erhöhen, - Wissen verlieren, - Verantwortlichkeiten verschleiern, - Änderungen unkontrollierbar machen, - und wiederkehrende Fehler begünstigen. --- **Was professionelles Service Management nicht bedeutet** Professionelles Service Management bedeutet nicht: - jede Kleinigkeit zu einem umfangreichen Prozess zu machen, - technische Entscheidungen vollständig zu zentralisieren, - jede Änderung durch dasselbe Gremium genehmigen zu lassen, - jede Organisation identisch aufzubauen, - ITIL-Begriffe nur auswendig zu lernen, - technische Kompetenz durch Prozesse zu ersetzen, - oder jeden Benutzerwunsch ungeprüft umzusetzen. Es bedeutet vielmehr: - Ziele und Services zu verstehen, - Verantwortlichkeiten zu klären, - angemessen zu planen, - benötigte Informationen verfügbar zu machen, - Risiken zu berücksichtigen, - Zusammenarbeit zu ermöglichen, - Ergebnisse zu überprüfen, - und aus Erfahrungen zu lernen. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker für Systemintegration sind häufig an mehreren Stellen eines Service beteiligt. Zu ihren Aufgaben können gehören: - technische Komponenten installieren, - Benutzerkonten verwalten, - Störungen analysieren, - Änderungen umsetzen, - Systeme überwachen, - Backups kontrollieren, - Wiederherstellungen durchführen, - Dienstleister einbinden, - Dokumentationen erstellen, - und Wissen an Kollegen weitergeben. Service Management hilft dabei, diese technischen Tätigkeiten in einen größeren Zusammenhang einzuordnen. | Technische Tätigkeit | Zusätzliche Service-Management-Frage | |---|---| | Dienst neu starten | Wurde die Wiederherstellung geprüft und ist eine weitere Ursachenanalyse notwendig? | | Firewall-Regel ändern | Wer ist betroffen, welches Risiko besteht und wie sieht der Rückfallplan aus? | | Benutzerkonto entsperren | Handelt es sich um einen Incident oder einen Service Request? | | Server patchen | Wie werden Test, Freigabe, Wartungsfenster und Kommunikation organisiert? | | Monitoring-Alarm bearbeiten | Ist das Event relevant und muss ein Incident erfasst werden? | | neue Hardware einbauen | Müssen Asset- und Konfigurationsinformationen aktualisiert werden? | | Fehler dauerhaft beheben | Müssen Problem Management und Change Management einbezogen werden? | | Lösung dokumentieren | Wer benötigt dieses Wissen und wie wird es auffindbar gemacht? | | Backup kontrollieren | Wurde nur der Sicherungslauf oder auch die Wiederherstellbarkeit geprüft? | --- **Wie ein serviceorientierter Systemintegrator denkt** Ein serviceorientierter Systemintegrator fragt nicht nur: > Welche Komponente ist defekt? Er fragt zusätzlich: - Welcher Service ist beeinträchtigt? - Welche Benutzer oder Geschäftsprozesse sind betroffen? - Welche Wiederherstellung ist zuerst notwendig? - Welche Abhängigkeiten bestehen? - Wer muss beteiligt werden? - Welche Risiken entstehen durch meine Maßnahme? - Wie kann der vorherige Zustand wiederhergestellt werden? - Wie überprüfe ich das Ergebnis? - Was muss dokumentiert werden? - Was können wir aus diesem Vorgang lernen? Diese Denkweise verhindert nicht jede Störung. Sie hilft jedoch dabei, Störungen kontrollierter, nachvollziehbarer und nachhaltiger zu behandeln. --- **Erste Orientierung in einer neuen Organisation** Wenn du in einer neuen IT-Abteilung beginnst, solltest du frühzeitig herausfinden: - Welche wichtigen Services gibt es? - Wer verwendet diese Services? - Gibt es einen Servicekatalog? - Welches Ticketsystem wird eingesetzt? - Welche Vorgangsarten gibt es? - Wie werden Prioritäten bestimmt? - Welche Eskalationswege gelten? - Wer trägt welche Verantwortung? - Welche Änderungen darfst du selbst durchführen? - Welche Änderungen benötigen eine Freigabe? - Wo befinden sich technische Dokumentationen? - Wo wird Wissen gespeichert? - Welche Servicezeiten und Vereinbarungen gelten? - Welche externen Dienstleister sind beteiligt? - Welche kritischen Abhängigkeiten bestehen? - Wie werden Major Incidents koordiniert? - Welche Sicherheits- und Notfallverfahren gelten? > **Praxistipp** > > Lerne nicht nur die technische Infrastruktur kennen. > > Lerne auch, welche Services davon abhängen und wer bei Störungen oder Änderungen beteiligt werden muss. --- **Anzeichen für unzureichendes Service Management** Folgende Beobachtungen können darauf hinweisen, dass Arbeitsweisen verbessert werden sollten: - Vorgänge enthalten kaum verwertbare Informationen. - Prioritäten werden willkürlich oder regelmäßig nachträglich geändert. - Benutzer umgehen den vorgesehenen Kontaktweg und wenden sich an einzelne Administratoren. - Änderungen werden erst nach einer Störung bekannt. - Niemand kann die Verantwortung für einen wichtigen Service benennen. - Lösungen befinden sich nur in privaten Notizen oder Chatverläufen. - Wiederkehrende Incidents werden immer wieder einzeln bearbeitet. - Monitoring erzeugt viele Meldungen, aber keine klare Reaktion. - Teams weisen sich gegenseitig die Verantwortung zu. - Benutzer erhalten widersprüchliche Statusinformationen. - Serviceberichte enthalten viele Zahlen, aber kaum Aussagen über Outcomes. - Nach schwerwiegenden Incidents werden keine Verbesserungen umgesetzt. Ein einzelnes Anzeichen beweist noch kein grundsätzliches Organisationsproblem. Wiederholen sich mehrere dieser Muster, sollte die zugrunde liegende Arbeitsweise untersucht werden. --- **Entscheidungshilfe: Wird mehr Struktur benötigt?** Prüfe folgende Fragen: - Gehen Meldungen oder Aufgaben verloren? - Werden ähnliche Vorgänge grundlegend unterschiedlich bearbeitet? - Sind Verantwortlichkeiten häufig unklar? - Werden Änderungen ohne ausreichende Abstimmung durchgeführt? - Treten dieselben Störungen regelmäßig erneut auf? - Fehlen nachvollziehbare Dokumentationen? - Wissen Benutzer nicht, wohin sie sich wenden sollen? - Werden kritische Auswirkungen zu spät erkannt? - Fehlen verlässliche Informationen über Abhängigkeiten? - Werden Verbesserungen besprochen, aber nicht umgesetzt? Werden mehrere Fragen mit **Ja** beantwortet, besteht wahrscheinlich Verbesserungsbedarf. Die Lösung ist jedoch nicht automatisch ein möglichst umfangreicher Prozess. Zuerst sollte festgestellt werden: 1. Welches konkrete Problem besteht? 2. Welche Auswirkungen verursacht es? 3. Welche bestehende Arbeitsweise funktioniert bereits? 4. Welche kleinste sinnvolle Verbesserung ist möglich? 5. Wie lässt sich ihre Wirkung überprüfen? --- **Checkliste für den Arbeitsalltag** Wenn du eine technische Aufgabe erhältst, prüfe zusätzlich: - [ ] Welcher Service ist betroffen? - [ ] Wer verwendet oder benötigt diesen Service? - [ ] Welche Auswirkungen bestehen? - [ ] Wie dringend ist die Aufgabe? - [ ] Gibt es bereits einen Vorgang im Ticketsystem? - [ ] Wer trägt die Verantwortung? - [ ] Welche Abhängigkeiten müssen berücksichtigt werden? - [ ] Wurde kürzlich etwas geändert? - [ ] Benötige ich eine Freigabe? - [ ] Welche Risiken besitzt meine Maßnahme? - [ ] Gibt es einen Rückfallplan? - [ ] Wer muss informiert werden? - [ ] Wie überprüfe ich den technischen Erfolg? - [ ] Wie überprüfe ich die Nutzbarkeit des Service? - [ ] Was muss dokumentiert werden? - [ ] Muss daraus eine weitere Untersuchung oder Verbesserung entstehen? --- **Schnellzusammenfassung** > **Technik** > > stellt Komponenten und Funktionen bereit. > > **Service Management** > > verbindet Technik mit Menschen, Arbeitsweisen, Informationen, Partnern und den Zielen der Organisation. > > **Professionelle IT-Arbeit** > > entsteht, wenn technische Kompetenz und serviceorientierte Arbeitsweise zusammenwirken. --- **Vom technischen Baustein zum geschäftlichen Ergebnis** > Technische Komponenten > ↓ > digitales Produkt > ↓ > nutzbarer Service > ↓ > Outcome für Benutzer und Organisation > ↓ > wahrgenommener Wert Technische Komponenten bilden die Grundlage. Der eigentliche Nutzen entsteht jedoch erst, wenn daraus ein funktionierender Service entsteht, der ein benötigtes Outcome unterstützt. --- **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 - 0.4 Aktualisierungen, Versionspflege und Korrekturen - 1.2 Technik, Produkt, Service und Geschäftsergebnis - 1.3 Wert, Nutzen, Kosten und Risiken - 1.4 Servicebeziehungen, Rollen und Serviceangebote --- **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 FAQ – Frequently Asked Questions about ITIL](https://www.peoplecert.org/help-and-support/faq-itil) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [ITIL: ITIL at a Glance](https://www.itil.com/at-a-glance) **Einordnung** Die Aussagen zur gemeinsamen Wertschöpfung, zu den vier Dimensionen, zur Integration von Produkten und Services sowie zur Ausrichtung auf Outcomes, Kosten, Risiken, Erfahrung und Nachhaltigkeit wurden anhand der genannten offiziellen ITIL- und PeopleCert-Quellen geprüft. Die Praxisbeispiele, Checklisten, Entscheidungshilfen und betrieblichen Hinweise sind zusätzliche, herstellerneutrale Praxisempfehlungen dieses Nachschlagewerks. Sie stellen keine wörtlichen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 1.2 Technik, Produkt, Service und Geschäftsergebnis > **Kurz erklärt** > > Technische Komponenten sind die Bausteine einer IT-Lösung. > > Ein digitales Produkt bündelt technische und organisatorische Fähigkeiten. > > Ein Service macht diese Fähigkeiten für Benutzer oder Kunden nutzbar. > > Entscheidend ist am Ende nicht nur, ob einzelne Systeme funktionieren, sondern ob Benutzer und Organisationen mit ihrer Hilfe das gewünschte Ergebnis erreichen. --- **Warum diese Unterscheidung wichtig ist** Im IT-Arbeitsalltag werden Begriffe wie **System**, **Produkt**, **Service**, **Leistung** und **Ergebnis** häufig miteinander vermischt. Der Begriff „E-Mail-System“ kann beispielsweise Folgendes bezeichnen: - einen Mailserver, - eine technische Plattform, - eine E-Mail-Anwendung, - ein digitales Kommunikationsprodukt, - einen E-Mail-Service, - oder den gesamten Kommunikationsdienst des Unternehmens. Diese Bedeutungen hängen zusammen, sind aber nicht identisch. Für professionelles Produkt- und Service-Management muss erkennbar sein: - welche technischen Komponenten vorhanden sind, - wie diese Komponenten zusammenarbeiten, - welches digitale Produkt daraus entsteht, - welche Services damit ermöglicht werden, - wer diese Services verwendet, - welche Ergebnisse erwartet werden, - und welchen Wert die beteiligten Stakeholder wahrnehmen. > **Merke** > > Ein technisch funktionierendes System ist eine notwendige Grundlage. > > Entscheidend ist jedoch, ob der damit unterstützte Service für die Benutzer zuverlässig nutzbar ist und das erwartete Ergebnis ermöglicht. --- **Die Betrachtungsebenen** Für die praktische Einordnung unterscheiden wir folgende Ebenen: | Ebene | Zentrale Frage | Beispiel | |---|---|---| | **Technische Komponente** | Aus welchen einzelnen Bausteinen besteht die Lösung? | Server, Switch, Datenbank, Zertifikat | | **Technisches System** | Wie arbeiten mehrere Komponenten zusammen? | E-Mail-Plattform | | **Digitales Produkt** | Welche gebündelte digitale Fähigkeit wird verwaltet und weiterentwickelt? | Kommunikations- und Kollaborationsplattform | | **Service** | Wie wird diese Fähigkeit für Benutzer oder Kunden nutzbar gemacht? | E-Mail- und Kalender-Service | | **Output** | Was wurde technisch erstellt oder bereitgestellt? | Benutzerpostfach wurde angelegt | | **Outcome** | Welche Wirkung oder welches Ergebnis wurde erreicht? | Mitarbeiter kann kommunizieren | | **Wert** | Welchen Nutzen nehmen die beteiligten Stakeholder wahr? | zuverlässige Zusammenarbeit und Zeitersparnis | Diese Ebenen bilden keine starre lineare Kette. Ein digitales Produkt kann mehrere Services ermöglichen. Ein Service kann wiederum mehrere Produkte, Plattformen, Systeme und externe Leistungen verwenden. --- **Technische Komponenten** Technische Komponenten sind einzelne Bausteine, aus denen Systeme, Produkte und Services aufgebaut werden. Dazu gehören beispielsweise: - physische Server, - virtuelle Maschinen, - Container, - Betriebssysteme, - Netzwerkkomponenten, - Firewalls, - Speicher, - Datenbanken, - Anwendungen, - Programmierschnittstellen, - Zertifikate, - Benutzerkonten, - Identitätsdienste, - Cloud-Ressourcen, - Monitoring-Systeme, - Backup-Systeme, - Konfigurationsdaten, - und technische Dokumentationen. In einem Konfigurationsmanagement können relevante Bestandteile als **Configuration Items** erfasst werden. Ob ein Bestandteil als Configuration Item verwaltet wird, hängt davon ab, ob seine Informationen für die Bereitstellung, Steuerung, Unterstützung oder Wiederherstellung eines Service benötigt werden. > **Praxisbeispiel** > > Für einen VPN-Service können unter anderem folgende Komponenten notwendig sein: > > - VPN-Gateway, > - Firewall, > - Internetanschluss, > - DNS, > - Benutzerverzeichnis, > - Multi-Faktor-Authentifizierung, > - Clientsoftware, > - Zertifikate, > - Endgerät, > - Monitoring, > - und ein externer Identitätsanbieter. Jede einzelne Komponente kann technisch funktionieren. Trotzdem kann der gesamte VPN-Service unbrauchbar sein, wenn die Komponenten nicht korrekt zusammenarbeiten. --- **Technisches System** Ein technisches System entsteht durch das koordinierte Zusammenwirken mehrerer Komponenten. Beispiele: | Technisches System | Mögliche Komponenten | |---|---| | Verzeichnisdienst | Domain Controller, DNS, Datenbank, Replikation und Zeitquelle | | E-Mail-System | Mailplattform, Identitätsdienst, DNS, Zertifikate und Spamfilter | | Webplattform | Webserver, Datenbank, Load Balancer, DNS und Speicher | | Virtualisierungsplattform | Hosts, Hypervisor, Netzwerk, Storage und Managementsystem | | Backup-System | Backupserver, Agenten, Speicherziele, Zugangsdaten und Zeitpläne | Ein technisches System wird häufig aus Sicht der Architektur und Administration betrachtet. Dabei stehen Fragen im Mittelpunkt wie: - Welche Komponenten gehören zum System? - Wie sind sie miteinander verbunden? - Welche Abhängigkeiten bestehen? - Wie wird das System überwacht? - Wie wird es gesichert? - Wie kann es wiederhergestellt werden? - Wer darf es administrieren? - Welche anderen Systeme greifen darauf zu? Diese Sicht ist für Fachinformatiker für Systemintegration unverzichtbar. Für die vollständige Bewertung eines Service reicht sie allein jedoch nicht aus. --- **Was ist ein digitales Produkt?** Ein digitales Produkt bündelt Fähigkeiten, mit denen für Benutzer, Kunden oder die eigene Organisation nutzbare Ergebnisse ermöglicht werden. Ein digitales Produkt kann unter anderem bestehen aus: - Software, - Hardware, - Daten, - Schnittstellen, - Automatisierungen, - Sicherheitsfunktionen, - Dokumentation, - Betriebswerkzeugen, - Lieferantenleistungen, - Supportleistungen, - und organisatorischen Fähigkeiten. Beispiele für digitale Produkte: - eine Kommunikations- und Kollaborationsplattform, - ein Kundenportal, - eine Warenwirtschaftslösung, - eine digitale Arbeitsplatzplattform, - eine Monitoring-Plattform, - eine Identitäts- und Zugriffsplattform, - oder eine selbst entwickelte Geschäftsanwendung. Ein digitales Produkt wird über seinen gesamten Lebenszyklus betrachtet. Dazu gehören unter anderem: - Bedarf und Zielsetzung verstehen, - Anforderungen untersuchen, - Lösung gestalten, - Komponenten beschaffen oder entwickeln, - testen, - bereitstellen, - betreiben, - unterstützen, - verbessern, - und später kontrolliert außer Betrieb nehmen. > **Wichtig** > > Ein digitales Produkt ist nicht zwingend nur eine einzelne Anwendung. > > Es kann aus vielen technischen und organisatorischen Bestandteilen bestehen. --- **Produkt und Service gehören zusammen** ITIL Version 5 betrachtet digitale Produkte und Services als eng miteinander verbundene Bestandteile einer digital unterstützten Lösung. Ein Produkt stellt Fähigkeiten bereit. Ein Service ermöglicht es Benutzern oder Kunden, diese Fähigkeiten sinnvoll zu verwenden. Beispiel: | Betrachtung | Kommunikationsplattform | |---|---| | **Produkt** | technisch und organisatorisch verwaltete Kommunikations- und Kollaborationsplattform | | **Services** | E-Mail, Kalender, Kontakte, Chat, Videokonferenzen und Dateifreigabe | Produkt und Service sind dabei keine voneinander unabhängigen Welten. Probleme entstehen häufig, wenn Produktentwicklung, Betrieb und Support getrennt arbeiten und wichtige Anforderungen zu spät berücksichtigen. Mögliche Folgen sind: - Monitoring fehlt beim Produktivstart. - Supportmitarbeiter erhalten keine ausreichende Dokumentation. - Betriebsanforderungen werden erst nach der Einführung erkannt. - Sicherheitsanforderungen werden nachträglich ergänzt. - Verantwortlichkeiten bleiben unklar. - Fehler werden zwischen Teams weitergereicht. - Benutzererfahrungen fließen nicht in die Weiterentwicklung ein. > **Merke** > > Ein Produkt stellt Fähigkeiten bereit. > > Ein Service macht diese Fähigkeiten für bestimmte Stakeholder nutzbar. --- **Was ist ein Service?** Ein Service unterstützt Benutzer, Kunden oder andere Stakeholder dabei, gewünschte Ergebnisse zu erreichen. Die Benutzer müssen dabei nicht alle zugrunde liegenden technischen und organisatorischen Einzelheiten selbst verwalten. Ein Benutzer eines E-Mail-Service muss beispielsweise nicht selbst: - Mailserver betreiben, - Zertifikate verlängern, - Datenbanken warten, - Spamfilter konfigurieren, - Backups planen, - Sicherheitsupdates installieren, - Speicher erweitern, - oder externe Provider koordinieren. Der Benutzer erwartet stattdessen, dass er: - Nachrichten senden und empfangen, - Kontakte verwenden, - Termine verwalten, - Informationen austauschen, - und zuverlässig kommunizieren kann. Der Service Provider übernimmt oder koordiniert die dafür notwendigen Fähigkeiten, Ressourcen, Arbeitsweisen und Beziehungen. --- **Interne und externe Services** Ein Service muss nicht an einen extern zahlenden Kunden verkauft werden. Auch interne IT-Abteilungen erbringen Services. | Service | Mögliche Service Consumer | |---|---| | Benutzerverwaltung | Mitarbeiter und Fachabteilungen | | zentraler Dateiservice | interne Teams und Projekte | | E-Mail- und Kalender-Service | gesamte Organisation | | ERP-Service | Einkauf, Lager, Vertrieb und Buchhaltung | | Entwicklungsplattform | Softwareentwicklung | | Monitoring-Service | Betriebsteams und Service-Verantwortliche | | Backup- und Restore-Service | Fachabteilungen und Systemverantwortliche | | Netzwerkzugang | Mitarbeiter, Gäste und technische Systeme | Der Service Provider kann sein: - eine interne IT-Abteilung, - ein Managed Service Provider, - ein Cloud-Anbieter, - ein Software-as-a-Service-Anbieter, - ein externer technischer Dienstleister, - oder eine Kombination mehrerer Beteiligter. --- **Ein Produkt kann mehrere Services ermöglichen** Eine zentrale Identitätsplattform kann beispielsweise folgende Services unterstützen: - Benutzeranmeldung, - Single Sign-on, - Multi-Faktor-Authentifizierung, - Passwortzurücksetzung, - Berechtigungsbereitstellung, - Identitätsprüfung, - und Zugriff auf Cloud-Anwendungen. Ein einzelner Service kann umgekehrt mehrere Produkte benötigen. Ein digitaler Arbeitsplatzservice kann beispielsweise verwenden: - eine Identitätsplattform, - eine Endgeräteverwaltung, - eine E-Mail-Plattform, - eine Kollaborationsplattform, - Sicherheitsprodukte, - Softwareverteilung, - Netzwerkzugang, - und Supportwerkzeuge. > **Praxistipp** > > Frage bei einer Störung nicht nur: > > „Welches System ist ausgefallen?“ > > Frage zusätzlich: > > „Welche Services verwenden dieses System und welche Benutzer sind dadurch betroffen?“ --- **Output und Outcome unterscheiden** Für die Bewertung einer Aufgabe ist die Unterscheidung zwischen **Output** und **Outcome** wichtig. | Begriff | Praktische Bedeutung | |---|---| | **Output** | etwas wurde erstellt, verändert oder bereitgestellt | | **Outcome** | für einen Stakeholder wurde eine Wirkung oder ein nutzbares Ergebnis erreicht | Beispiele: | Output | Outcome | |---|---| | VPN-Client wurde installiert. | Mitarbeiter kann sicher von außerhalb arbeiten. | | Benutzerkonto wurde angelegt. | Neuer Mitarbeiter kann seine Arbeit aufnehmen. | | Server wurde bereitgestellt. | Fachanwendung kann produktiv verwendet werden. | | Backup wurde erfolgreich ausgeführt. | Daten können nach einem Ausfall wiederhergestellt werden. | | Patch wurde installiert. | Ein bekanntes Sicherheitsrisiko wurde reduziert. | | Access Point wurde montiert. | Benutzer erhalten zuverlässigen WLAN-Zugang. | | Wissensartikel wurde erstellt. | Supportmitarbeiter können eine Störung schneller lösen. | > **Typischer Fehler** > > Die technische Durchführung wird mit dem erfolgreichen Ergebnis gleichgesetzt. > > Eine installierte Anwendung ist beispielsweise noch kein erfolgreicher Service, wenn der Benutzer sie nicht starten, verwenden oder für seine Aufgabe einsetzen kann. --- **Technische Fertigstellung ist nicht gleich Serviceerfolg** Ein neues Benutzerkonto wurde technisch angelegt. Folgende Schritte wurden durchgeführt: - Konto erstellt, - Gruppen zugewiesen, - E-Mail-Adresse angelegt, - Lizenz vergeben, - Benutzerprofil vorbereitet. Der neue Mitarbeiter kann trotzdem nicht arbeiten, wenn: - das Anfangskennwort nicht sicher übermittelt wurde, - die Multi-Faktor-Authentifizierung nicht eingerichtet werden kann, - notwendige Berechtigungen fehlen, - das Endgerät nicht bereitsteht, - die Anmeldung nicht getestet wurde, - oder erforderliche Freigaben fehlen. Der technische Output lautet: > Benutzerkonto wurde erstellt. Das erwartete Outcome lautet: > Der Mitarbeiter besitzt zum vorgesehenen Zeitpunkt einen funktionierenden und angemessenen Zugriff auf die für seine Tätigkeit benötigten Services. --- **Geschäftsergebnis und Benutzerergebnis** Ein Service kann unterschiedliche Ergebnisse für verschiedene Stakeholder ermöglichen. Beispiel: Backup- und Restore-Service | Stakeholder | Erwartetes Ergebnis | |---|---| | Benutzer | versehentlich gelöschte Datei kann wiederhergestellt werden | | Fachabteilung | geschäftskritische Daten bleiben verfügbar | | IT-Betrieb | Systeme können kontrolliert wiederhergestellt werden | | Informationssicherheit | Schutz- und Aufbewahrungsanforderungen werden unterstützt | | Unternehmensleitung | Betriebsunterbrechungen und Verluste werden begrenzt | | Auditor | Kontrollen und Wiederherstellbarkeit sind nachvollziehbar dokumentiert | Nicht jeder Stakeholder bewertet denselben Service nach denselben Kriterien. Deshalb müssen Anforderungen, Erwartungen, Kosten und Risiken aus mehreren Perspektiven betrachtet werden. --- **Vom technischen Baustein zum Ergebnis** Ein vereinfachtes Beispiel für einen E-Mail-Service: | Ebene | Beispiel | |---|---| | **Komponenten** | DNS, Identitätsdienst, Mailplattform, Zertifikate und Netzwerk | | **System** | technische Kommunikationsplattform | | **Produkt** | digitale Kommunikations- und Kollaborationslösung | | **Service** | E-Mail-, Kalender- und Kontaktservice | | **Output** | Postfach und Clientzugang wurden bereitgestellt | | **Outcome** | Mitarbeiter können zuverlässig kommunizieren | | **Geschäftsergebnis** | Zusammenarbeit und Geschäftsprozesse werden unterstützt | | **Wert** | zuverlässige Kommunikation bei angemessenen Kosten und Risiken | Diese Darstellung ist keine starre ITIL-Prozesskette. Sie dient als praktische Orientierung, um technische Arbeit mit den erwarteten Ergebnissen zu verbinden. --- **Was bedeutet Wert?** Wert entsteht, wenn ein Produkt oder Service für einen Stakeholder einen erkennbaren Nutzen besitzt. Wert kann sich beispielsweise zeigen durch: - Zeitersparnis, - geringeres Risiko, - höhere Verfügbarkeit, - bessere Benutzererfahrung, - geringere Kosten, - schnellere Kommunikation, - bessere Entscheidungsgrundlagen, - höhere Sicherheit, - Erfüllung rechtlicher Anforderungen, - oder Unterstützung eines Geschäftsprozesses. Wert ist nicht für jeden Stakeholder identisch. Beispiel: Eine strengere Multi-Faktor-Authentifizierung kann: - für die Informationssicherheit einen deutlichen Schutzgewinn darstellen, - für Benutzer zusätzlichen Aufwand erzeugen, - für das Unternehmen Risiken reduzieren, - und für den Service Desk mehr Supportanfragen verursachen. Eine gute Lösung berücksichtigt diese unterschiedlichen Perspektiven. > **Merke** > > Wert ist nicht nur eine technische Eigenschaft. > > Er wird von Stakeholdern anhand ihrer Ergebnisse, Kosten, Risiken, Erfahrungen und Erwartungen wahrgenommen. --- **Wert wird gemeinsam ermöglicht** Der Service Provider erzeugt Wert nicht vollständig allein. Auch Service Consumer und weitere Stakeholder tragen zur erfolgreichen Nutzung bei. Beispiel: sicherer Fernzugriff **Der Service Provider muss unter anderem:** - VPN-Infrastruktur bereitstellen, - Zugänge verwalten, - Sicherheitsmaßnahmen umsetzen, - Störungen bearbeiten, - den Service überwachen, - und Dokumentation bereitstellen. **Der Benutzer muss unter anderem:** - Zugangsdaten schützen, - MFA korrekt verwenden, - Sicherheitsvorgaben einhalten, - ein geeignetes Endgerät verwenden, - und Störungen mit verwertbaren Informationen melden. **Die Fachabteilung oder Führungskraft muss möglicherweise:** - den Zugriff genehmigen, - benötigte Berechtigungen benennen, - Änderungen rechtzeitig mitteilen, - und organisatorische Voraussetzungen schaffen. Das gewünschte Ergebnis entsteht erst durch das Zusammenwirken der Beteiligten. --- **Verfügbarkeit allein reicht nicht aus** Ein Service kann technisch erreichbar und trotzdem praktisch unbrauchbar sein. Beispiele: - Die Anwendung lädt, reagiert aber zu langsam. - Der Benutzer kann sich anmelden, besitzt aber keine notwendigen Berechtigungen. - Das VPN ist erreichbar, unterstützt aber eine wichtige Fachanwendung nicht. - Das Backup läuft erfolgreich, wurde aber nie durch eine Wiederherstellung geprüft. - Der Druckservice ist erreichbar, aber der Benutzer kann keinen passenden Drucker auswählen. - Das Portal ist technisch verfügbar, aber für Benutzer nicht verständlich. - Ein Dienst antwortet, verarbeitet jedoch keine Transaktionen korrekt. Bei der Beurteilung eines Service können deshalb unter anderem folgende Eigenschaften wichtig sein: - Verfügbarkeit, - Leistung, - Kapazität, - Sicherheit, - Zuverlässigkeit, - Benutzerfreundlichkeit, - Support, - Wiederherstellbarkeit, - und Eignung für den vorgesehenen Zweck. --- **Praxisbeispiel: zentraler Dateiservice** Ein Unternehmen betreibt einen zentralen Dateiservice. **Technische Komponenten** - Fileserver, - Storage, - Netzwerk, - DNS, - Active Directory, - Berechtigungen, - Backup, - Monitoring. **Digitales Produkt** Eine verwaltete Plattform zur Speicherung und gemeinsamen Nutzung von Unternehmensdateien. **Service** Benutzer können entsprechend ihrer Berechtigungen: - Dateien speichern, - öffnen, - bearbeiten, - austauschen, - und bei Bedarf wiederherstellen lassen. **Erwartete Outcomes** - Teams können gemeinsam an Dokumenten arbeiten. - Unternehmensdaten werden zentral verwaltet. - Zugriffe sind kontrollierbar. - Daten können nach Fehlern wiederhergestellt werden. - Informationen bleiben bei einem Gerätewechsel verfügbar. **Möglicher Wert** - geringeres Risiko von Datenverlust, - bessere Zusammenarbeit, - zentrale Zugriffskontrolle, - nachvollziehbare Sicherung, - und geringerer Verwaltungsaufwand. --- **Praxisbeispiel: Störung des Dateiservice** Ein Benutzer meldet: > „Das Netzlaufwerk ist verschwunden.“ Eine rein komponentenorientierte Analyse könnte sofort mit dem Fileserver beginnen. Die serviceorientierte Analyse prüft zusätzlich: - Betrifft die Störung nur einen Benutzer? - Sind mehrere Standorte betroffen? - Funktioniert die Benutzeranmeldung? - Ist nur ein Laufwerk oder der gesamte Dateiservice betroffen? - Welcher Geschäftsprozess ist beeinträchtigt? - Gibt es eine alternative Zugriffsmöglichkeit? - Wurde eine Gruppenrichtlinie geändert? - Gab es einen Change am Netzwerk oder Verzeichnisdienst? - Welche Priorität ergibt sich aus Auswirkung und Dringlichkeit? - Wer muss informiert werden? Dadurch wird verhindert, dass eine einzelne technische Vermutung zu früh als Ursache angenommen wird. --- **Bedeutung für das Monitoring** Monitoring sollte nicht ausschließlich einzelne Komponenten überwachen. Ein Server kann erreichbar sein, obwohl der Service für Benutzer nicht funktioniert. Deshalb können unterschiedliche Überwachungsebenen notwendig sein: | Ebene | Beispiel | |---|---| | **Komponentenüberwachung** | CPU, Arbeitsspeicher, Datenträger und Netzwerkinterface | | **Systemüberwachung** | Datenbankverbindung und Dienststatus | | **Anwendungsüberwachung** | Anmeldung und wichtige Transaktionen | | **Serviceüberwachung** | vollständiger Benutzerweg funktioniert | | **Ergebnisorientierte Messung** | Benutzer kann die vorgesehene Aufgabe erfolgreich ausführen | > **Praxistipp** > > Überwache bei kritischen Services möglichst auch eine Funktion, die der tatsächlichen Benutzernutzung nahekommt. > > Ein erfolgreicher Ping bestätigt nur die Erreichbarkeit eines Hosts, nicht die Nutzbarkeit des gesamten Service. --- **Bedeutung für Änderungen** Vor einer technischen Änderung muss nicht nur die betroffene Komponente betrachtet werden. Zusätzlich sollte geprüft werden: - Zu welchem Produkt gehört die Komponente? - Welche Services verwenden sie? - Welche Benutzer sind abhängig? - Welche anderen Systeme greifen darauf zu? - Welche Outcomes können beeinträchtigt werden? - Welche Überwachung bestätigt die erfolgreiche Änderung? - Wie kann der vorherige Zustand wiederhergestellt werden? - Wer muss informiert werden? - Welche Dokumentationen müssen aktualisiert werden? Beispiel: Eine Änderung an DNS kann Auswirkungen besitzen auf: - Benutzeranmeldung, - E-Mail, - Webanwendungen, - Zertifikatsprüfung, - Active Directory, - VPN, - Monitoring, - und externe Schnittstellen. Die technische Änderung kann klein erscheinen, während die mögliche Serviceauswirkung sehr groß ist. --- **Bedeutung für die Priorisierung** Die Priorität einer Störung sollte nicht nur anhand der ausgefallenen Komponente bewertet werden. | Störung | Technische Betrachtung | Servicebezogene Betrachtung | |---|---|---| | einzelner Testserver ausgefallen | vollständiger Serverausfall | möglicherweise geringe geschäftliche Auswirkung | | zentraler DNS-Dienst gestört | einzelner technischer Dienst | möglicherweise viele Services betroffen | | einzelner Arbeitsplatzdrucker defekt | einzelnes Gerät ausgefallen | Auswirkung hängt von Alternativen und Bedarf ab | | zentrale Datenbank reagiert langsam | System ist noch erreichbar | möglicherweise erhebliche Beeinträchtigung eines Geschäftsprozesses | > **Merke** > > Die technische Größe eines Fehlers bestimmt nicht automatisch seine geschäftliche Priorität. --- **Bedeutung für die Dokumentation** Eine gute Dokumentation sollte nicht nur Komponenten beschreiben. Sie sollte nach Möglichkeit auch folgende Fragen beantworten: - Zu welchem Produkt gehört die Komponente? - Welche Services unterstützt sie? - Wer ist verantwortlich? - Welche Benutzer oder Kunden sind abhängig? - Welche anderen Komponenten werden benötigt? - Welche Überwachung existiert? - Welche Wiederherstellungsverfahren gelten? - Welche Lieferanten oder Verträge sind beteiligt? - Welche Änderungen wurden zuletzt durchgeführt? - Welche bekannten Fehler und Workarounds bestehen? Dadurch wird aus einer reinen Inventarliste eine nutzbare Wissensgrundlage für Betrieb, Support und Wiederherstellung. --- **Typische Denkfehler** **Denkfehler 1: Der Server ist der Service** Ein Server ist normalerweise nur eine Komponente oder Plattform. Der Service umfasst zusätzlich beispielsweise: - Nutzung, - Support, - Sicherheit, - Überwachung, - Berechtigungen, - Wiederherstellung, - Kommunikation, - und organisatorische Verantwortung. --- **Denkfehler 2: Wenn das Monitoring grün ist, funktioniert der Service** Ein grüner Hoststatus bestätigt nicht automatisch: - eine erfolgreiche Anmeldung, - korrekte Berechtigungen, - ausreichende Leistung, - fehlerfreie Transaktionen, - oder eine brauchbare Benutzererfahrung. --- **Denkfehler 3: Installation bedeutet Abschluss** Eine Softwareinstallation ist zunächst ein Output. Der gewünschte Zustand ist erst erreicht, wenn: - die Anwendung funktioniert, - der Benutzer zugreifen kann, - der vorgesehene Zweck erfüllt wird, - und das Ergebnis geprüft wurde. --- **Denkfehler 4: Produkt und Service sind dasselbe** Produkte und Services sind eng miteinander verbunden, besitzen aber unterschiedliche Betrachtungsschwerpunkte. Das Produkt bündelt und entwickelt Fähigkeiten. Der Service macht diese Fähigkeiten für bestimmte Stakeholder nutzbar. --- **Denkfehler 5: Wert bedeutet nur finanziellen Gewinn** Wert kann auch entstehen durch: - Risikoreduzierung, - Sicherheit, - Zuverlässigkeit, - Zeitersparnis, - bessere Erfahrung, - oder die Erfüllung verbindlicher Anforderungen. --- **Wie ein Systemintegrator die Zusammenhänge ermittelt** > **Vorgehensweise** > > 1. technische Komponenten erfassen > 2. Verbindungen und Abhängigkeiten bestimmen > 3. übergeordnetes System oder Produkt identifizieren > 4. unterstützte Services ermitteln > 5. Benutzer und weitere Stakeholder bestimmen > 6. erwartete Outputs und Outcomes erfassen > 7. kritische Geschäftsprozesse zuordnen > 8. Verantwortlichkeiten klären > 9. Monitoring und Wiederherstellung prüfen > 10. Informationen nachvollziehbar dokumentieren --- **Fragen für eine neue Umgebung** Wenn du einen neuen Service kennenlernst, solltest du mindestens folgende Fragen stellen: - Wie heißt der Service? - Welches Ergebnis soll er ermöglichen? - Wer verwendet ihn? - Wer ist für ihn verantwortlich? - Welche Produkte und Systeme unterstützen ihn? - Welche technischen Komponenten sind kritisch? - Welche externen Anbieter sind beteiligt? - Welche Servicezeiten gelten? - Welche Leistungsanforderungen bestehen? - Welche Sicherheitsanforderungen gelten? - Welche Abhängigkeiten bestehen? - Wie wird der Service überwacht? - Wie wird er wiederhergestellt? - Wo befindet sich die Dokumentation? - Welche bekannten Fehler und Workarounds existieren? --- **Checkliste für technische Aufgaben** Bevor du eine technische Maßnahme durchführst: - [ ] Welche Komponente wird verändert? - [ ] Zu welchem System oder Produkt gehört sie? - [ ] Welche Services verwenden sie? - [ ] Welche Benutzer oder Geschäftsbereiche sind betroffen? - [ ] Welches Ergebnis soll die Maßnahme erreichen? - [ ] Welche Abhängigkeiten bestehen? - [ ] Welche Risiken entstehen? - [ ] Wird eine Freigabe benötigt? - [ ] Gibt es einen Rückfallplan? - [ ] Wie wird der Erfolg technisch geprüft? - [ ] Wie wird die Nutzbarkeit des Service geprüft? - [ ] Wer muss informiert werden? - [ ] Welche Dokumentationen müssen aktualisiert werden? --- **Schnellzusammenfassung** | Begriff | Kurzbeschreibung | |---|---| | **Komponente** | einzelner technischer oder organisatorischer Baustein | | **System** | zusammenwirkende Gruppe von Komponenten | | **Digitales Produkt** | gebündelte digitale Fähigkeit, die über ihren Lebenszyklus verwaltet wird | | **Service** | nutzbarer Zugang zu Fähigkeiten, der gewünschte Ergebnisse unterstützt | | **Output** | erzeugtes Arbeitsergebnis oder bereitgestellter Bestandteil | | **Outcome** | erreichte Wirkung oder Veränderung für einen Stakeholder | | **Geschäftsergebnis** | Outcome, das ein Ziel oder einen Prozess der Organisation unterstützt | | **Wert** | wahrgenommener Nutzen unter Berücksichtigung von Ergebnissen, Kosten, Risiken und Erfahrung | --- **Grafik vorgesehen** > **Zusammenhang zwischen Technik, Produkt, Service und Ergebnis** > > Technische Komponenten > ↓ > Systeme und Plattformen > ↓ > digitales Produkt und unterstützende Fähigkeiten > ↓ > nutzbare Services > ↓ > Ergebnisse für Benutzer und Organisation > ↓ > wahrgenommener Wert Die Grafik sollte zusätzlich verdeutlichen, dass Rückmeldungen aus Nutzung, Betrieb und Support wieder in die Weiterentwicklung des Produkts und der Services einfließen. Eine spätere interaktive Version kann einen beispielhaften Service auswählen lassen, etwa: - Benutzeranmeldung, - E-Mail, - VPN, - Dateiservice, - Backup, - oder Unternehmensanwendung. Anschließend werden die dazugehörigen: - Komponenten, - Systeme, - Produkte, - Services, - Stakeholder, - Ergebnisse, - Risiken, - und Abhängigkeiten angezeigt. --- **Verwandte Seiten** - 1.1 Warum professionelles Service Management notwendig ist - 1.3 Typische Folgen unstrukturierter IT-Arbeit - 1.4 Serviceorientierung im Arbeitsalltag - 2.1 Was ist ein digitales Produkt? - 2.2 Was ist ein Service? - 2.3 Wert und gemeinsame Wertschöpfung - 2.4 Output und Outcome - 2.5 Kosten und Risiken - Service Configuration Management - IT Asset Management - Monitoring and Event Management - Change Management - Fehleranalyse und Troubleshooting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert: *ITIL Foundation – Version 5* - PeopleCert: *ITIL Foundation Version 5 – What’s New?* - ITIL: *New ITIL Product and Service Lifecycle Model* - PeopleCert: *ITIL Product – Version 5* - PeopleCert: *ITIL Service – Version 5* - PeopleCert: *ITIL FAQ – Frequently Asked Questions about ITIL* **Einordnung** Die Aussagen zur integrierten Betrachtung digitaler Produkte und Services, zum gemeinsamen Produkt- und Service-Lebenszyklus sowie zur Ausrichtung auf Outcomes und Wert wurden anhand der genannten offiziellen ITIL- und PeopleCert-Veröffentlichungen geprüft. Die Beispiele, Checklisten, Betrachtungsebenen und technischen Zuordnungen sind zusätzliche herstellerneutrale Praxisempfehlungen dieses Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen dar. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 1.3 Wert, Nutzen, Kosten und Risiken **Kurz erklärt** Ein IT-Service ist nicht bereits deshalb wertvoll, weil er technisch funktioniert. Wert entsteht erst, wenn der Service einen Servicekonsumenten dabei unterstützt, gewünschte Ergebnisse zu erreichen und dabei ein angemessenes Verhältnis zwischen Nutzen, Kosten und Risiken bietet. Der Wert eines Services wird daher nicht allein durch den Service Provider bestimmt. Er entsteht durch das Zusammenwirken von Provider, Kunde, Benutzer und weiteren beteiligten Stakeholdern. > Entscheidend ist nicht, welche Technik bereitgestellt wurde, sondern welchen wahrgenommenen Nutzen sie für die Beteiligten erzeugt. --- **1. Wert im Service Management** ITIL beschreibt Wert als den wahrgenommenen Nutzen, die Nützlichkeit und die Bedeutung von etwas. Dabei sind drei Punkte besonders wichtig: - Wert wird von den beteiligten Stakeholdern wahrgenommen. - Verschiedene Stakeholder können denselben Service unterschiedlich bewerten. - Der wahrgenommene Wert kann sich im Laufe der Zeit verändern. Ein technisch identischer Service kann daher für zwei Organisationen einen völlig unterschiedlichen Wert besitzen. **Beispiel** Ein Cloudspeicher mit 2 TB Speicherplatz kann für ein kleines Unternehmen sehr wertvoll sein, wenn dadurch: - Dateien zentral verfügbar werden, - mobiles Arbeiten möglich wird, - der Austausch großer Dateien vereinfacht wird, - lokale Speichersysteme entfallen, - Sicherungs- und Wiederherstellungsfunktionen verbessert werden. Für ein anderes Unternehmen kann derselbe Service ungeeignet sein, wenn: - gesetzliche Vorgaben nicht erfüllt werden, - die erforderliche Datenhoheit fehlt, - die Internetanbindung nicht ausreichend ist, - notwendige Schnittstellen fehlen, - die laufenden Kosten zu hoch sind. > Wert ist keine rein technische Eigenschaft eines Services, sondern hängt vom jeweiligen Kontext und von der Wahrnehmung der Stakeholder ab. --- **2. Wertschöpfung statt einseitiger Wertlieferung** In einem klassischen Liefermodell könnte der Eindruck entstehen, dass ein Anbieter einen fertigen Wert produziert und anschließend an den Kunden übergibt. Im Service Management entsteht Wert jedoch normalerweise erst durch die gemeinsame Nutzung und Ausgestaltung des Services. ITIL spricht deshalb von **Wertschöpfung durch Zusammenarbeit** beziehungsweise **Value Co-Creation**. Daran können beteiligt sein: - Service Provider - Kunde - Benutzer - Sponsor - Lieferanten - Entwicklungsteams - Supportteams - Fachabteilungen - Management - Sicherheits- und Datenschutzverantwortliche - externe Partner **Beispiel: Einführung eines Ticketsystems** Der Service Provider kann: - die Plattform bereitstellen, - Benutzerkonten einrichten, - Rollen und Berechtigungen konfigurieren, - Schnittstellen implementieren, - Verfügbarkeit und Support gewährleisten. Die Kundenorganisation muss unter anderem: - Anforderungen formulieren, - Verantwortlichkeiten festlegen, - Kategorien und Prioritäten definieren, - Mitarbeiter schulen, - Daten pflegen, - Rückmeldungen geben, - das System in die eigenen Arbeitsabläufe integrieren. Erst durch das Zusammenwirken beider Seiten kann das gewünschte Ergebnis entstehen. > Ein Service Provider kann die Voraussetzungen für Wert schaffen. Ob tatsächlich Wert entsteht, hängt auch davon ab, wie der Service ausgewählt, eingerichtet, genutzt und weiterentwickelt wird. --- **3. Ergebnisse statt bloßer Ausgaben** Für die Bewertung eines Services müssen **Outputs** und **Outcomes** unterschieden werden. | Begriff | Bedeutung | Beispiel | |---|---|---| | Output | unmittelbares Arbeitsergebnis einer Aktivität | ein eingerichteter VPN-Zugang | | Outcome | durch einen oder mehrere Outputs ermöglichtes Ergebnis | Beschäftigte können sicher von außerhalb arbeiten | | Wert | wahrgenommener Nutzen und Bedeutung des Ergebnisses | produktives und flexibles Arbeiten bei vertretbarem Risiko | Ein Output kann technisch vollständig erbracht worden sein, ohne dass das gewünschte Outcome erreicht wird. **Beispiel** Ein Monitoring-System wurde installiert und erfasst alle Server. Das ist zunächst ein Output. Das gewünschte Outcome könnte sein: - Störungen früher erkennen, - Ausfallzeiten verkürzen, - Kapazitätsengpässe rechtzeitig feststellen, - Ursachen schneller eingrenzen, - vereinbarte Service Levels einhalten. Werden zwar Messwerte gesammelt, aber keine sinnvollen Warnungen erzeugt und keine Reaktionen festgelegt, ist der technische Output vorhanden, das angestrebte Outcome jedoch nicht erreicht. --- **4. Nutzen beziehungsweise Utility** Die **Utility** beschreibt, ob ein Service für einen bestimmten Zweck geeignet ist und die benötigte Funktionalität bereitstellt. Sie beantwortet vereinfacht die Frage: > Tut der Service das, was benötigt wird? Utility kann entstehen, wenn ein Service: - eine gewünschte Leistung ermöglicht, - eine bestehende Einschränkung beseitigt, - einen Arbeitsablauf verbessert, - eine Aufgabe automatisiert, - eine benötigte Funktion bereitstellt, - die Produktivität erhöht. Utility wird häufig als **„fit for purpose“** bezeichnet: für den vorgesehenen Zweck geeignet. **Beispiele** | Service | mögliche Utility | |---|---| | E-Mail-Service | Nachrichten senden und empfangen | | Backup-Service | wiederherstellbare Kopien von Daten erzeugen | | VPN-Service | sicheren Fernzugriff ermöglichen | | Ticketsystem | Anfragen und Störungen strukturiert erfassen | | Identitätsdienst | Benutzer authentifizieren und Zugriffe steuern | | Monitoring | Zustände erfassen und relevante Abweichungen melden | Eine hohe Utility allein reicht nicht aus. Ein Service kann alle benötigten Funktionen besitzen und trotzdem unbrauchbar sein, wenn er beispielsweise zu häufig ausfällt oder nicht ausreichend geschützt ist. --- **5. Zusicherung beziehungsweise Warranty** Die **Warranty** beschreibt, unter welchen Bedingungen und mit welcher zugesicherten Qualität ein Service genutzt werden kann. Sie beantwortet vereinfacht die Frage: > Funktioniert der Service zuverlässig genug und unter den benötigten Bedingungen? Warranty kann sich insbesondere auf folgende Eigenschaften beziehen: - Verfügbarkeit - Kapazität - Performance - Kontinuität - Informationssicherheit Warranty wird häufig als **„fit for use“** bezeichnet: für die tatsächliche Nutzung geeignet. **Beispiel** Ein Videokonferenzdienst besitzt die benötigten Funktionen. Er bietet damit grundsätzlich Utility. Für eine Organisation ist er jedoch nur dann tatsächlich nutzbar, wenn beispielsweise: - ausreichend Teilnehmer unterstützt werden, - Bild und Ton stabil übertragen werden, - der Service zu den benötigten Zeiten verfügbar ist, - die Verbindung angemessen geschützt wird, - Ausfälle innerhalb akzeptabler Zeiten behoben werden, - Datenschutz- und Compliance-Anforderungen erfüllt werden. --- **6. Utility und Warranty gehören zusammen** | Utility | Warranty | |---|---| | Was leistet der Service? | Wie zuverlässig und unter welchen Bedingungen leistet er es? | | für den Zweck geeignet | für die Nutzung geeignet | | benötigte Funktionen | benötigtes Qualitätsniveau | | unterstützt gewünschte Ergebnisse | stellt die erforderlichen Nutzungsbedingungen sicher | **Beispiel: Backup-Service** **Utility** - Daten werden gesichert. - ältere Versionen können aufbewahrt werden. - Dateien und Systeme können wiederhergestellt werden. **Warranty** - Sicherungen werden im vereinbarten Intervall ausgeführt. - Sicherungsdaten werden vor unbefugtem Zugriff geschützt. - ausreichende Speicherkapazität steht zur Verfügung. - Wiederherstellungen sind innerhalb der benötigten Zeit möglich. - Sicherungskopien bleiben auch bei Ausfall eines Standorts verfügbar. > Utility ohne ausreichende Warranty bedeutet: Der Service kann grundsätzlich das Richtige, ist aber nicht zuverlässig genug. Warranty ohne passende Utility bedeutet: Der Service funktioniert zuverlässig, löst jedoch nicht das benötigte Problem. --- **7. Kosten aus Sicht des Servicekonsumenten** Kosten sind nicht nur der Kaufpreis oder die monatliche Rechnung. Bei der Bewertung eines Services müssen alle relevanten Aufwände betrachtet werden. Mögliche Kosten sind: - Anschaffungs- und Lizenzkosten - laufende Nutzungsgebühren - Betriebs- und Wartungskosten - Kosten für Hardware und Infrastruktur - Energie- und Raumkosten - Kosten für Personal - Schulungsaufwand - Migrationskosten - Integrationsaufwand - Kosten für Support - Kosten für Sicherheitsmaßnahmen - Kosten für Ausfallzeiten - Kosten für Anbieterwechsel oder Vertragsbeendigung - Aufwand für Compliance, Datenschutz und Dokumentation ITIL unterscheidet aus Sicht des Servicekonsumenten zwei grundlegende Wirkungen: - Kosten, die durch die Nutzung eines Services entstehen - Kosten, die der Servicekonsument durch die Nutzung des Services vermeiden oder reduzieren kann **Beispiel: Managed Backup** Durch den Service entstehen unter anderem: - monatliche Gebühren, - Einrichtungsaufwand, - Kosten für Datenübertragung, - Aufwand für regelmäßige Wiederherstellungstests. Gleichzeitig können andere Kosten reduziert oder vermieden werden: - eigene Backup-Infrastruktur, - Beschaffung zusätzlicher Speichersysteme, - manuelle Sicherungsarbeiten, - eigenes Spezialpersonal, - Folgekosten unzureichend gesicherter Daten. > Für eine sachgerechte Bewertung müssen zusätzliche Kosten und vermiedene Kosten gemeinsam betrachtet werden. --- **8. Risiken aus Sicht des Servicekonsumenten** Ein Risiko ist ein mögliches Ereignis, das Schaden verursachen, die Zielerreichung beeinträchtigen oder Unsicherheit erzeugen kann. Bei Services können Risiken beispielsweise entstehen durch: - Ausfälle - Sicherheitsvorfälle - Datenverlust - fehlerhafte Änderungen - unzureichende Kapazität - fehlende Kompetenzen - Abhängigkeit von Lieferanten - nicht erfüllte gesetzliche Anforderungen - falsche oder unvollständige Daten - unklare Verantwortlichkeiten - fehlende Wiederherstellbarkeit - Anbieterbindung - unkontrollierte Kostensteigerungen Auch bei Risiken müssen zwei Wirkungen unterschieden werden: - Risiken, die durch die Nutzung des Services entstehen - Risiken, die durch den Service reduziert oder übernommen werden **Beispiel: Cloudbasierter E-Mail-Service** Möglicherweise reduzierte Risiken: - Ausfall eigener Mailserver - veraltete lokale Software - fehlende eigene Betriebskapazität - unzureichende Skalierbarkeit - fehlende geografische Redundanz Möglicherweise neu entstehende oder verbleibende Risiken: - Abhängigkeit vom Anbieter - Abhängigkeit von der Internetverbindung - Fehlkonfiguration von Berechtigungen - Datenschutz- und Compliance-Risiken - eingeschränkte Migrationsmöglichkeiten - großflächige Störung beim Provider > Die Auslagerung eines Services beseitigt nicht automatisch die Verantwortung der Kundenorganisation. Risiken können übertragen, geteilt, reduziert oder akzeptiert werden, müssen aber weiterhin gesteuert werden. --- **9. Erfahrung und wahrgenommene Servicequalität** Die technische Leistung eines Services ist nicht der einzige Faktor für seinen Wert. Auch die Erfahrung der beteiligten Personen beeinflusst, wie der Service wahrgenommen wird. Dazu gehören beispielsweise: - einfache Bedienbarkeit - verständliche Kommunikation - Erreichbarkeit des Supports - angemessene Reaktionszeiten - transparente Statusinformationen - zuverlässige Zusagen - barrierearme Nutzung - nachvollziehbare Änderungen - respektvoller Umgang - verständliche Dokumentation **Beispiel** Zwei Provider können technisch eine Verfügbarkeit von 99,9 Prozent erreichen. Der eine informiert bei Störungen frühzeitig, nennt regelmäßig den Bearbeitungsstand und dokumentiert anschließend die Ursache. Der andere reagiert verspätet und kommuniziert widersprüchlich. Obwohl die gemessene Verfügbarkeit gleich ist, kann der wahrgenommene Wert deutlich unterschiedlich sein. > Technische Kennzahlen müssen durch die Perspektive von Kunden und Benutzern ergänzt werden. --- **10. Nachhaltigkeit als Teil langfristiger Wertbetrachtung** In der aktuellen ITIL-Weiterentwicklung wird Nachhaltigkeit ausdrücklich in die Betrachtung von Wert, Outcomes, Kosten, Risiken und Erfahrung einbezogen. Nachhaltigkeit kann verschiedene Perspektiven umfassen: - Energieverbrauch - Ressourceneinsatz - Lebensdauer von Hardware - Reparierbarkeit - Wiederverwendung - fachgerechte Entsorgung - soziale Auswirkungen - langfristige Finanzierbarkeit - organisatorische Belastbarkeit - Abhängigkeit von knappen Ressourcen **Beispiel** Eine technisch leistungsfähige Lösung kann kurzfristig einen hohen Nutzen erzeugen. Wenn sie jedoch: - unverhältnismäßig viel Energie verbraucht, - nur schwer gewartet werden kann, - Personal dauerhaft überlastet, - hohe und unkontrollierbare Folgekosten erzeugt, - regulatorische Anforderungen gefährdet, kann ihr langfristiger Wert gering sein. --- **11. Unterschiedliche Stakeholder bewerten Wert unterschiedlich** | Stakeholder | mögliche Wertkriterien | |---|---| | Benutzer | einfache und störungsarme Nutzung | | Kunde | Unterstützung der Geschäftsziele | | Sponsor | vertretbare Finanzierung und messbarer Nutzen | | Service Provider | zuverlässige und wirtschaftliche Leistungserbringung | | Management | Zielerreichung, Steuerbarkeit und Risikokontrolle | | Informationssicherheit | Vertraulichkeit, Integrität und Verfügbarkeit | | Datenschutz | rechtmäßige und zweckgebundene Verarbeitung | | Fachabteilung | passende Funktionen und kurze Bearbeitungszeiten | | Support | diagnostizierbare und wartbare Lösung | | Lieferant | klarer Leistungsumfang und erfüllbare Vereinbarungen | Konflikte sind möglich. **Beispiel** Eine besonders strenge Authentifizierung kann die Sicherheit erhöhen, gleichzeitig aber die Benutzung erschweren. Die Aufgabe des Service Managements besteht nicht darin, nur eine Perspektive zu maximieren, sondern gemeinsam eine angemessene Lösung zu finden. --- **12. Wertannahme und tatsächlich erreichter Wert** Vor Einführung eines Services existiert zunächst eine Annahme darüber, welchen Wert er erzeugen soll. Diese Annahme muss später anhand tatsächlicher Ergebnisse überprüft werden. **Vor der Einführung** - Welche Ergebnisse sollen erreicht werden? - Für wen soll Wert entstehen? - Welche Kosten werden erwartet? - Welche Risiken sollen reduziert werden? - Welche neuen Risiken können entstehen? - Welche Utility wird benötigt? - Welche Warranty ist erforderlich? - Wie soll der Erfolg gemessen werden? **Nach der Einführung** - Wurden die gewünschten Outcomes erreicht? - Wird der Service tatsächlich verwendet? - Sind die geplanten Verbesserungen eingetreten? - Entsprechen die tatsächlichen Kosten der Planung? - Haben sich Risiken wie erwartet verändert? - Wie bewerten Benutzer und Kunden ihre Erfahrung? - Sind unerwünschte Nebenwirkungen entstanden? - Besteht Verbesserungsbedarf? > Ein erfolgreich abgeschlossenes Einführungsprojekt beweist noch nicht, dass der Service dauerhaft Wert erzeugt. --- **13. Wertorientierte Kennzahlen** Kennzahlen sollten nicht nur technische Aktivität messen, sondern einen Bezug zu den gewünschten Ergebnissen besitzen. | schwache oder unvollständige Kennzahl | stärker wertorientierte Ergänzung | |---|---| | Anzahl bearbeiteter Tickets | Wiederherstellungszeit und Benutzerzufriedenheit | | Anzahl durchgeführter Changes | Anteil erfolgreicher Changes und Auswirkungen auf den Service | | Serververfügbarkeit | Verfügbarkeit des vollständigen Geschäftsservices | | Anzahl erstellter Benutzerkonten | Zeit bis zur vollständigen Arbeitsfähigkeit neuer Beschäftigter | | Anzahl erzeugter Backups | erfolgreiche und getestete Wiederherstellungen | | Anzahl geschlossener Incidents | nachhaltig behobene Störungen und Wiederholungsrate | | Anzahl automatisierter Schritte | eingesparte Bearbeitungszeit und reduzierte Fehlerquote | Kennzahlen dürfen nicht isoliert betrachtet werden. Eine verkürzte Ticketbearbeitungszeit wäre beispielsweise kein positiver Wertbeitrag, wenn Tickets lediglich vorschnell geschlossen werden und Benutzer anschließend neue Tickets eröffnen müssen. --- **14. Praxisbeispiel: neuer Remote-Work-Service** Eine Organisation führt einen Service für mobiles Arbeiten ein. **Erwartete Outcomes** - Beschäftigte können außerhalb des Standorts arbeiten. - Geschäftsprozesse bleiben auch bei Standortausfällen verfügbar. - Reisekosten und Wegezeiten werden reduziert. - externe Fachkräfte können sicher eingebunden werden. **Utility** - VPN-Zugang - Mehrfaktor-Authentifizierung - Zugriff auf Dateien und Anwendungen - Videokonferenzen - zentral verwaltete Endgeräte **Warranty** - ausreichende Verfügbarkeit - angemessene Performance - genügend gleichzeitige Verbindungen - sichere Authentifizierung - Wiederherstellbarkeit - Support zu den benötigten Zeiten **Zusätzliche Kosten** - Lizenzen - Endgeräte - Support - Schulung - Sicherheitslösungen - Internet- und Verbindungskosten **Möglicherweise vermiedene Kosten** - zusätzliche Büroflächen - Dienstreisen - lokale Infrastruktur an mehreren Standorten - Produktivitätsverluste bei Standortausfällen **Möglicherweise reduzierte Risiken** - vollständige Abhängigkeit von einem Bürostandort - unkontrollierte private Fernzugriffslösungen - Nutzung unverwalteter Endgeräte **Möglicherweise neu entstehende Risiken** - gestohlene Endgeräte - Phishing und kompromittierte Zugangsdaten - Fehlkonfigurationen - unzureichende private Netzwerkverbindungen - Datenschutzprobleme - soziale Isolation oder Überlastung **Mögliche Messgrößen** - Erfolgsquote von Anmeldungen - Verfügbarkeit des End-to-End-Services - Anzahl sicherheitsrelevanter Vorfälle - Zeit bis zur Bereitstellung eines Arbeitsplatzes - Zufriedenheit der Benutzer - Supportaufwand - tatsächlich vermiedene Kosten - Erreichung der fachlichen Arbeitsziele --- **15. Typische Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Der Server läuft, also liefert der Service Wert.“ | Ein laufender Server bestätigt weder die Funktion des vollständigen Services noch das gewünschte Outcome. | | „Der Kunde hat bezahlt, also ist der Service wertvoll.“ | Preis und wahrgenommener Wert sind nicht identisch. | | „Alle vereinbarten Funktionen sind vorhanden.“ | Utility kann vorhanden sein, während Warranty oder Benutzererfahrung unzureichend sind. | | „Der Provider übernimmt den Betrieb, daher bestehen keine Risiken mehr.“ | Risiken können reduziert oder übertragen werden, verschwinden aber nicht automatisch. | | „Die Einführung wurde termingerecht abgeschlossen.“ | Projekterfolg beweist noch keinen dauerhaften Servicewert. | | „Die SLA-Werte wurden eingehalten.“ | Einhaltung einzelner Messwerte beweist nicht, dass die geschäftlichen Outcomes erreicht wurden. | | „Viele bearbeitete Tickets zeigen einen guten Support.“ | Eine hohe Ticketzahl kann auch auf schlechte Servicequalität oder wiederkehrende Fehler hinweisen. | | „Automatisierung erzeugt immer Wert.“ | Automatisierung kann ungeeignete Abläufe beschleunigen und Fehler vervielfachen. | | „Wert ist vollständig objektiv messbar.“ | Messdaten sind wichtig, der Wert enthält jedoch auch wahrnehmungs- und kontextabhängige Aspekte. | --- **16. Checkliste zur Bewertung eines Services** - [ ] Der Servicekonsument ist eindeutig bestimmt. - [ ] Kunden, Benutzer und Sponsoren werden unterschieden. - [ ] Die gewünschten Outcomes sind beschrieben. - [ ] Die erforderliche Utility ist festgelegt. - [ ] Die erforderliche Warranty ist festgelegt. - [ ] technische und fachliche Anforderungen sind verbunden. - [ ] zusätzliche Kosten sind erfasst. - [ ] vermeidbare oder reduzierte Kosten sind erfasst. - [ ] neu entstehende Risiken sind erfasst. - [ ] reduzierte oder übernommene Risiken sind erfasst. - [ ] Verantwortlichkeiten sind vereinbart. - [ ] Abhängigkeiten und Lieferanten sind berücksichtigt. - [ ] Benutzererfahrung und Zugänglichkeit werden bewertet. - [ ] Nachhaltigkeitsaspekte werden berücksichtigt. - [ ] Kennzahlen besitzen einen Bezug zu den gewünschten Outcomes. - [ ] Annahmen werden nach der Einführung überprüft. - [ ] Kunden- und Benutzerfeedback wird ausgewertet. - [ ] Verbesserungen werden dokumentiert und priorisiert. --- **17. Versionshinweis: ITIL 4 und ITIL (Version 5)** Die grundlegende Wertorientierung bleibt auch in ITIL (Version 5) erhalten. Dazu gehören insbesondere: - gemeinsame Wertschöpfung, - Ausrichtung auf Outcomes, - Betrachtung von Kosten und Risiken, - Zusammenarbeit zwischen Providern, Konsumenten und Stakeholdern, - ganzheitliches Management digitaler Produkte und Services, - kontinuierliche Verbesserung. ITIL (Version 5) hebt zusätzlich die Erfahrung der Stakeholder, Nachhaltigkeit und den gemeinsamen Lebenszyklus digitaler Produkte und Services deutlicher hervor. Die in ITIL 4 verwendeten Konzepte **Utility** und **Warranty** bleiben für die praktische Bewertung von Serviceanforderungen relevant. Bei aktuellen Unterlagen muss jedoch immer geprüft werden, auf welche ITIL-Version und welchen offiziellen Lehrplan sie sich beziehen. --- **Merksatz** > Wert entsteht, wenn ein Service gewünschte Ergebnisse ermöglicht, einen wahrgenommenen Nutzen bietet und Kosten sowie Risiken für die beteiligten Stakeholder in einem angemessenen Verhältnis stehen. Utility beschreibt, ob der Service das Richtige leistet; Warranty beschreibt, ob er unter den benötigten Bedingungen zuverlässig genutzt werden kann. --- **Quellen und weiterführende Dokumentation** - [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: Neuerungen](https://www.peoplecert.org/news-and-announcements/itil-version-5-foundation-whats-new-guide) - [PeopleCert – ITIL Qualification Scheme](https://www.peoplecert.org/Frameworks-Professionals/ITIL-framework) - [PeopleCert – ITIL 4 Foundation](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565) - [PeopleCert – ITIL 4 Practitioner: Service Level Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-service-level-management-3867) # 1.4 Servicebeziehungen, Rollen und Serviceangebote **Kurz erklärt** Ein Service entsteht nicht isoliert innerhalb einer IT-Abteilung. Er wird in einer Beziehung zwischen einem **Service Provider** und einem **Service Consumer** bereitgestellt, genutzt und fortlaufend weiterentwickelt. Damit diese Beziehung funktioniert, muss eindeutig geklärt sein: - wer den Service bereitstellt, - wer die Anforderungen festlegt, - wer die Nutzung finanziert oder genehmigt, - wer den Service tatsächlich verwendet, - welche Leistungen angeboten werden, - welche Beiträge beide Seiten leisten, - welche Ergebnisse erreicht werden sollen, - welche Kosten und Risiken übernommen werden, - wie Kommunikation, Änderungen und Verbesserungen erfolgen. > Eine Servicebeziehung besteht nicht nur aus der technischen Bereitstellung. Sie umfasst auch Zusammenarbeit, Vereinbarungen, Nutzung, Kommunikation und gemeinsame Verantwortung für die Wertschöpfung. --- **1. Service Provider** Ein **Service Provider** ist eine Organisation, die Services bereitstellt. Der Provider kann: - Teil derselben Organisation wie der Service Consumer sein, - eine rechtlich selbstständige externe Organisation sein, - mehrere interne und externe Beteiligte koordinieren, - selbst Services anderer Provider konsumieren, - gleichzeitig in unterschiedlichen Servicebeziehungen verschiedene Rollen besitzen. Typische Aufgaben eines Service Providers sind: - Anforderungen verstehen, - Services und Serviceangebote gestalten, - Ressourcen und Fähigkeiten bereitstellen, - Services betreiben und unterstützen, - Verfügbarkeit und Kapazität sicherstellen, - Sicherheitsanforderungen umsetzen, - Störungen und Serviceanfragen bearbeiten, - Servicequalität überwachen, - Änderungen koordinieren, - Risiken steuern, - Informationen bereitstellen, - Verbesserungen durchführen, - Beziehungen zu Kunden, Benutzern und Lieferanten pflegen. **Beispiele** | Service Provider | bereitgestellter Service | |---|---| | interne IT-Abteilung | Arbeitsplatz- und Supportservice | | externer Cloudanbieter | Rechen-, Speicher- oder Plattformservice | | Managed Service Provider | Betrieb und Überwachung der IT-Infrastruktur | | Telekommunikationsunternehmen | Internet- und Standortverbindungen | | internes Personalteam | digital unterstützter Personalservice | | Softwareanbieter | cloudbasierte Fachanwendung | | Rechenzentrum | Hosting, Stromversorgung, Kühlung und Konnektivität | > Der Begriff „Provider“ bezeichnet eine Rolle innerhalb einer bestimmten Servicebeziehung. Dieselbe Organisation kann gegenüber ihren Benutzern Provider und gegenüber einem Cloudanbieter Consumer sein. --- **2. Service Consumer** Ein **Service Consumer** ist eine Organisation, die Services eines Service Providers nutzt. Der Begriff bezeichnet nicht nur einzelne Benutzer. Er umfasst die konsumierende Organisation und die unterschiedlichen Rollen, die an Auswahl, Finanzierung, Anforderungen und Nutzung eines Services beteiligt sind. Zu den Aufgaben eines Service Consumers können gehören: - Anforderungen und gewünschte Outcomes beschreiben, - benötigte Servicequalität festlegen, - Finanzierung genehmigen, - Vereinbarungen einhalten, - Benutzer und Berechtigungen verwalten, - eigene Ressourcen bereitstellen, - erforderliche Informationen liefern, - den Service bestimmungsgemäß verwenden, - Sicherheitsvorgaben beachten, - Störungen und Anforderungen melden, - Rückmeldungen geben, - Änderungen organisatorisch begleiten, - den erreichten Wert bewerten. **Beispiel** Ein Unternehmen nutzt einen externen E-Mail-Service. Der Provider stellt unter anderem bereit: - E-Mail-Plattform, - Speicher, - technische Verfügbarkeit, - Sicherheitsfunktionen, - Updates, - Supportmöglichkeiten. Die Kundenorganisation muss unter anderem: - Benutzerkonten verwalten, - Rollen und Berechtigungen festlegen, - Endgeräte absichern, - eigene Richtlinien definieren, - Benutzer schulen, - Aufbewahrungsanforderungen konfigurieren, - Vorfälle melden, - den Service vertragsgemäß nutzen. > Der Provider trägt nicht automatisch die alleinige Verantwortung für alle Ergebnisse. Auch der Consumer muss die vereinbarten Beiträge leisten. --- **3. Customer, User und Sponsor** Innerhalb des Service Consumers unterscheidet ITIL drei wichtige Rollen: | Rolle | Bedeutung | zentrale Fragestellung | |---|---|---| | Customer | definiert die Anforderungen an einen Service und übernimmt Verantwortung für die Outcomes des Servicekonsums | Was benötigen wir und welche Ergebnisse sollen erreicht werden? | | User | verwendet den Service | Kann ich den Service wirksam, sicher und verständlich nutzen? | | Sponsor | genehmigt beziehungsweise autorisiert das Budget für den Servicekonsum | Ist die Finanzierung gerechtfertigt und tragfähig? | Diese Rollen müssen nicht von verschiedenen Personen ausgeübt werden. Eine Person kann mehrere Rollen übernehmen. In größeren Organisationen sind die Rollen jedoch häufig getrennt. **Beispiel: neues Ticketsystem** **Sponsor** - genehmigt das Budget, - bewertet Investitionshöhe und erwarteten Nutzen, - achtet auf Wirtschaftlichkeit und strategische Bedeutung. **Customer** - definiert Anforderungen, - legt benötigte Prozesse und Ergebnisse fest, - verantwortet die erwarteten Outcomes, - stimmt Service Levels und Prioritäten ab. **User** - erfasst und bearbeitet Tickets, - nutzt Such-, Kommunikations- und Auswertungsfunktionen, - erlebt unmittelbar Bedienbarkeit und Performance, - liefert wichtige Rückmeldungen aus der täglichen Nutzung. > Ein Service kann die Erwartungen des Sponsors erfüllen und trotzdem für Benutzer ungeeignet sein. Deshalb müssen alle drei Perspektiven berücksichtigt werden. --- **4. Rollen sind kontextabhängig** ITIL-Rollen sind keine festen Berufsbezeichnungen. Sie beschreiben die Funktion einer Person oder Organisation in einer bestimmten Beziehung. **Beispiel: Software-as-a-Service** Ein Unternehmen verwendet eine cloudbasierte Personalverwaltungssoftware. | Beteiligter | Rolle in diesem Zusammenhang | |---|---| | SaaS-Anbieter | Service Provider gegenüber dem Unternehmen | | Personalabteilung | Customer und teilweise User | | Geschäftsführung | Sponsor | | Beschäftigte | User einzelner Funktionen | | interne IT-Abteilung | unterstützt die Nutzung und koordiniert die Integration | | Cloud-Infrastruktur-Anbieter | Provider gegenüber dem SaaS-Anbieter | | SaaS-Anbieter | Consumer gegenüber dem Cloud-Infrastruktur-Anbieter | Daraus folgt: - Eine Organisation kann gleichzeitig Provider und Consumer sein. - Die Rolle hängt immer von der betrachteten Servicebeziehung ab. - Rollen müssen für jeden Service eindeutig bestimmt werden. - Organigramme allein zeigen nicht zuverlässig, wer welche ITIL-Rolle besitzt. --- **5. Produkte und Services unterscheiden** Ein **Produkt** ist eine Konfiguration von Ressourcen einer Organisation, die dazu entwickelt wurde, einem Consumer Wert anzubieten. Zu solchen Ressourcen können gehören: - Personen und Kompetenzen, - Informationen und Wissen, - Prozesse und Arbeitsabläufe, - Anwendungen, - Infrastruktur, - Lieferantenbeziehungen, - Verträge, - finanzielle Mittel, - technische Plattformen, - geistiges Eigentum. Ein Produkt kann die Grundlage für einen oder mehrere Services bilden. **Beispiel** Ein Provider betreibt eine Plattform für Zusammenarbeit. Das Produkt kann unter anderem umfassen: - Rechenzentrums- oder Cloudressourcen, - Kommunikationssoftware, - Identitätsverwaltung, - Monitoring, - Supportorganisation, - Dokumentation, - Sicherheitsmechanismen, - Verträge mit Lieferanten. Auf dieser Grundlage können verschiedene Services angeboten werden: - Chat und Gruppenkommunikation, - Videokonferenzen, - Dateiaustausch, - externe Projektbereiche, - Aufzeichnung und Archivierung, - technischer Support. > Das Produkt ist die organisierte Ressourcenkonfiguration des Providers. Der Service ermöglicht dem Consumer daraus gewünschte Outcomes. --- **6. Service und Serviceangebot unterscheiden** Ein Service ermöglicht die gemeinsame Wertschöpfung, indem er gewünschte Outcomes unterstützt, ohne dass der Consumer bestimmte Kosten und Risiken vollständig selbst verwalten muss. Ein **Serviceangebot** beschreibt dagegen eine konkrete Zusammenstellung von Leistungen, die sich an die Bedürfnisse einer bestimmten Consumer-Gruppe richtet. Ein Serviceangebot kann enthalten: 1. Waren 2. Zugriff auf Ressourcen 3. Service Actions Diese Bestandteile können einzeln oder kombiniert auftreten. --- **7. Waren als Bestandteil eines Serviceangebots** Waren sind materielle oder übertragbare Bestandteile, deren Eigentum auf den Consumer übergehen kann. Beispiele: - Notebook, - Smartphone, - Router, - Ersatzteil, - Datenträger, - gedrucktes Handbuch, - gekaufte Hardware-Appliance. Typische Eigenschaften: - Der Consumer erhält das Eigentum. - Der Consumer kann anschließend für Betrieb oder Verwendung verantwortlich sein. - Die Ware kann Bestandteil eines umfangreicheren Serviceangebots sein. - Mit der Übergabe enden nicht automatisch alle Verpflichtungen des Providers. **Beispiel** Ein Workplace-Service enthält: - ein Notebook, - eine Dockingstation, - einen Monitor, - Einrichtung und Konfiguration, - Softwarebereitstellung, - Support, - Austausch bei Defekt. Notebook, Dockingstation und Monitor können Waren sein. Einrichtung und Support sind dagegen Service Actions. --- **8. Zugriff auf Ressourcen** Ein Serviceangebot kann dem Consumer Zugriff auf Ressourcen ermöglichen, ohne dass deren Eigentum übertragen wird. Beispiele: - Nutzung einer Cloudplattform, - Zugriff auf Speicherplatz, - Nutzung einer virtuellen Maschine, - Zugriff auf eine Fachanwendung, - Nutzung eines Netzwerks, - Zugriff auf eine Wissensdatenbank, - Nutzung einer Entwicklungsumgebung, - Zugriff auf Rechenleistung. Typische Eigenschaften: - Die Ressource bleibt unter der Kontrolle oder im Eigentum des Providers beziehungsweise eines Lieferanten. - Der Consumer erhält ein vereinbartes Nutzungsrecht. - Der Zugriff kann zeitlich, technisch oder vertraglich begrenzt sein. - Kapazität, Berechtigungen und Nutzungsbedingungen müssen festgelegt werden. **Beispiel** Bei einem Cloudspeicher erhält der Consumer normalerweise nicht das Eigentum an bestimmten physischen Festplatten. Er erhält Zugriff auf eine vereinbarte Speicherkapazität und die dazugehörigen Funktionen. --- **9. Service Actions** Service Actions sind Tätigkeiten, die der Provider zur Unterstützung des Consumers ausführt. Beispiele: - Installation einer Anwendung, - Einrichtung eines Benutzerkontos, - Bearbeitung einer Störung, - Wiederherstellung von Daten, - Überwachung eines Systems, - Beratung, - Wartung, - Aktualisierung einer Plattform, - Austausch eines defekten Geräts, - Durchführung einer Sicherheitsprüfung, - Schulung von Benutzern. Service Actions können: - automatisch, - manuell, - einmalig, - regelmäßig, - auf Anforderung, - ereignisgesteuert ausgeführt werden. **Beispiel** Ein Backup-Service kann enthalten: - Zugriff auf Sicherungsspeicher, - automatisierte Erstellung von Sicherungen, - Überwachung der Sicherungsläufe, - Benachrichtigung bei Fehlern, - Wiederherstellung auf Anforderung, - regelmäßige Wiederherstellungstests. --- **10. Beispiel für ein vollständiges Serviceangebot** **Service: verwalteter digitaler Arbeitsplatz** | Bestandteil | konkrete Leistung | |---|---| | Ware | Notebook, Netzteil und gegebenenfalls Zubehör | | Zugriff auf Ressourcen | E-Mail, Dateispeicher, Fachanwendungen, VPN und Kollaborationsplattform | | Service Actions | Einrichtung, Softwareverteilung, Support, Wartung und Austausch | | Utility | Beschäftigte können ihre betrieblichen Aufgaben digital ausführen | | Warranty | vereinbarte Verfügbarkeit, Performance, Sicherheit, Kapazität und Kontinuität | | Consumer-Beitrag | sorgfältige Nutzung, Einhaltung der Sicherheitsregeln und Meldung von Problemen | | erwartetes Outcome | Beschäftigte sind innerhalb der vorgesehenen Zeit vollständig arbeitsfähig | Verschiedene Consumer-Gruppen können unterschiedliche Serviceangebote erhalten: - Standardarbeitsplatz, - mobiler Arbeitsplatz, - Entwicklerarbeitsplatz, - Grafikarbeitsplatz, - besonders geschützter Administrationsarbeitsplatz, - temporärer Arbeitsplatz für externe Personen. > Ein Serviceangebot muss so konkret sein, dass Consumer verstehen, was enthalten ist, unter welchen Bedingungen es genutzt werden kann und welche eigenen Beiträge erforderlich sind. --- **11. Servicebeziehung** Eine **Servicebeziehung** ist die Zusammenarbeit zwischen einem Service Provider und einem Service Consumer. Sie umfasst drei miteinander verbundene Bestandteile: | Bestandteil | Bedeutung | |---|---| | Service Provision | Tätigkeiten und Ressourcen des Providers zur Bereitstellung des Services | | Service Consumption | Tätigkeiten und Ressourcen des Consumers zur Nutzung des Services | | Service Relationship Management | gemeinsame Aktivitäten zur Pflege und Weiterentwicklung der Beziehung | --- **12. Service Provision** Zur Service Provision können gehören: - Verwaltung der Provider-Ressourcen, - Bereitstellung des Zugriffs auf Ressourcen, - Ausführung vereinbarter Service Actions, - Bereitstellung von Waren, - Support für Benutzer, - Erfüllung vereinbarter Service Levels, - Überwachung des Services, - Kommunikation von Störungen und Änderungen, - kontinuierliche Verbesserung. **Beispiel: VPN-Service** Der Provider: - betreibt die VPN-Infrastruktur, - stellt VPN-Software bereit, - verwaltet Gateways und Zertifikate, - überwacht Verfügbarkeit und Kapazität, - unterstützt Benutzer, - behebt Störungen, - aktualisiert sicherheitsrelevante Komponenten. --- **13. Service Consumption** Zur Service Consumption können gehören: - Verwaltung der Consumer-Ressourcen, - Nutzung der bereitgestellten Ressourcen, - Ausführung vereinbarter Benutzerhandlungen, - Entgegennahme von Waren, - Nutzung der Service Actions, - Bereitstellung erforderlicher Informationen, - Einhaltung vereinbarter Regeln, - Rückmeldung über Qualität und Ergebnisse. **Beispiel: VPN-Service** Der Consumer: - stellt geeignete Endgeräte bereit oder verwaltet sie, - schützt Zugangsdaten, - verwendet Mehrfaktor-Authentifizierung, - hält Sicherheitsrichtlinien ein, - meldet Störungen mit geeigneten Informationen, - sorgt für eine ausreichende lokale Internetverbindung, - beendet nicht mehr benötigte Zugänge. > Auch die Nutzung eines Services benötigt Ressourcen, Kompetenzen, Verantwortlichkeiten und kontrollierte Abläufe. --- **14. Service Relationship Management** Service Relationship Management umfasst die gemeinsamen Aktivitäten von Provider und Consumer, mit denen die Servicebeziehung aufgebaut, gepflegt und verbessert wird. Dazu gehören beispielsweise: - regelmäßige Abstimmungen, - Austausch über Anforderungen, - Service Reviews, - Auswertung von Kennzahlen, - Behandlung von Beschwerden, - Bewertung der Benutzererfahrung, - Planung von Änderungen, - Behandlung von Risiken, - Eskalationen, - Überprüfung von Vereinbarungen, - Ermittlung von Verbesserungsmöglichkeiten, - Anpassung des Serviceangebots. **Typische Fragen eines Service Reviews** - Werden die gewünschten Outcomes erreicht? - Entspricht die Nutzung den Erwartungen? - Werden die vereinbarten Service Levels erreicht? - Welche Störungen sind besonders häufig oder schwerwiegend? - Welche Risiken haben sich verändert? - Welche Kosten sind tatsächlich entstanden? - Wie bewerten Benutzer ihre Erfahrung? - Haben sich Anforderungen geändert? - Welche Verbesserungen werden priorisiert? - Müssen Vereinbarungen angepasst werden? > Eine Servicebeziehung muss aktiv gepflegt werden. Ein unterschriebener Vertrag ersetzt keine laufende Zusammenarbeit. --- **15. Interne und externe Servicebeziehungen** Servicebeziehungen können intern oder extern bestehen. | Merkmal | interner Provider | externer Provider | |---|---|---| | organisatorische Zugehörigkeit | Teil derselben Organisation | rechtlich selbstständige Organisation | | Grundlage | interne Vereinbarungen, Richtlinien und Service Levels | Vertrag, Leistungsbeschreibung und Service Levels | | Finanzierung | interne Kostenstelle, Budget oder Leistungsverrechnung | Rechnung, Abonnement oder nutzungsabhängige Zahlung | | Steuerung | interne Governance | Vertrags- und Lieferantenmanagement | | Eskalation | interne Führungs- und Fachstrukturen | vertragliche und organisatorische Eskalationswege | | Verantwortung | innerhalb der Organisation verteilt | zwischen den Organisationen vereinbart | Auch interne Services benötigen: - klare Verantwortlichkeiten, - verständliche Serviceangebote, - definierte Service Levels, - abgestimmte Anforderungen, - geregelte Eskalationen, - transparente Kosten, - messbare Outcomes. > „Intern“ bedeutet nicht automatisch kostenlos, unkritisch oder frei von Vereinbarungen. --- **16. Lieferanten und Partner** Ein Provider muss nicht alle Ressourcen und Tätigkeiten selbst bereitstellen. Häufig wirken weitere Organisationen mit. Beispiele: - Cloudanbieter, - Softwarehersteller, - Telekommunikationsanbieter, - Rechenzentrumsbetreiber, - Hardwarelieferanten, - externe Supportunternehmen, - Sicherheitsdienstleister, - Beratungsunternehmen, - Logistikpartner. Der Consumer erlebt möglicherweise einen einzigen Service, obwohl im Hintergrund mehrere Provider und Lieferanten beteiligt sind. **Beispiel** Ein Software-as-a-Service-Angebot kann abhängig sein von: - einem Cloud-Infrastruktur-Anbieter, - einem Identitätsdienst, - einem Zahlungsdienstleister, - einem E-Mail-Versanddienst, - einem Monitoring-Anbieter, - einem externen Supportpartner. Der direkte Provider bleibt gegenüber seinem Consumer für die vereinbarte Servicebeziehung verantwortlich, auch wenn Teile der Leistung von Lieferanten stammen. Zu prüfen sind deshalb: - Abhängigkeiten, - Verantwortlichkeiten, - unterstützende Verträge, - Sicherheitsanforderungen, - Datenschutz, - Service Levels, - Eskalationswege, - Ausfallvorsorge, - Wechselmöglichkeiten, - Konzentrationsrisiken. --- **17. Beiträge des Providers und des Consumers** Für gemeinsame Wertschöpfung müssen die Beiträge beider Seiten bekannt sein. | Provider-Beitrag | Consumer-Beitrag | |---|---| | geeignete Servicefunktionen | klare Anforderungen | | qualifiziertes Personal | geeignete Ansprechpartner | | technische Infrastruktur | notwendige Endgeräte und lokale Voraussetzungen | | Support und Dokumentation | korrekte Nutzung und Mitarbeit | | Sicherheitsmaßnahmen | Einhaltung von Sicherheitsregeln | | Monitoring und Berichte | Rückmeldung über Erfahrung und Ergebnisse | | Behandlung von Störungen | vollständige und rechtzeitige Fehlermeldungen | | geplante Verbesserungen | Beteiligung an Tests und Abnahmen | | transparente Kommunikation | Mitteilung veränderter Anforderungen | | vereinbarte Servicequalität | Einhaltung eigener Verpflichtungen | **Beispiel** Bei einer Datenmigration kann der Provider: - Werkzeuge bereitstellen, - Migrationsläufe planen, - Daten technisch übertragen, - Fehlerprotokolle erzeugen, - die Zielplattform vorbereiten. Der Consumer muss möglicherweise: - Datenbestände bereinigen, - Verantwortliche benennen, - Aufbewahrungsregeln festlegen, - Ergebnisse fachlich prüfen, - Benutzer informieren, - Abnahmen durchführen. Fehlt einer dieser Beiträge, kann das gewünschte Outcome trotz technisch korrekter Provider-Leistung ausbleiben. --- **18. Vereinbarungen in Servicebeziehungen** Eine Vereinbarung kann formell oder informell sein. Sie muss jedoch für die beteiligten Parteien ausreichend eindeutig sein. Mögliche Inhalte sind: - Beschreibung des Services, - Serviceumfang, - ausgeschlossene Leistungen, - Zielgruppen, - Rollen und Verantwortlichkeiten, - erwartete Outcomes, - Utility und Warranty, - Servicezeiten, - Verfügbarkeit, - Kapazität und Performance, - Supportzeiten, - Reaktions- und Lösungsziele, - Sicherheitsanforderungen, - Datenschutzanforderungen, - Preise und Abrechnungsmodell, - Mitwirkungspflichten, - Berichte und Reviews, - Eskalationswege, - Änderungsverfahren, - Laufzeit und Kündigung, - Datenrückgabe und Übergang, - Notfall- und Wiederherstellungsregelungen. Mögliche Vereinbarungsformen: - Service Level Agreement - Vertrag - Leistungsbeschreibung - interne Servicevereinbarung - Betriebsvereinbarung - Servicekatalogeintrag - Nutzungsbedingungen - unterstützender Vertrag mit einem Lieferanten - Arbeitsanweisung oder Richtlinie > Eine Vereinbarung ist nur wirksam, wenn die Beteiligten sie verstehen, praktisch erfüllen können und regelmäßig überprüfen. --- **19. Abgrenzung wichtiger Begriffe** | Begriff | Bedeutung | |---|---| | Produkt | konfigurierte Ressourcen eines Providers zur Ermöglichung von Wertangeboten | | Service | Mittel zur gemeinsamen Wertschöpfung durch Unterstützung gewünschter Outcomes | | Serviceangebot | konkrete Beschreibung einer oder mehrerer Leistungen für eine Consumer-Gruppe | | Service Provider | Organisation, die Services bereitstellt | | Service Consumer | Organisation, die Services konsumiert | | Customer | definiert Anforderungen und verantwortet Outcomes des Servicekonsums | | User | verwendet den Service | | Sponsor | autorisiert das Budget für den Servicekonsum | | Service Provision | Bereitstellungstätigkeiten und Ressourcen des Providers | | Service Consumption | Nutzungstätigkeiten und Ressourcen des Consumers | | Service Relationship Management | gemeinsame Pflege und Weiterentwicklung der Beziehung | | Output | unmittelbares Arbeitsergebnis | | Outcome | durch Outputs ermöglichtes Ergebnis | | Value | wahrgenommener Nutzen und Bedeutung | | Utility | Eignung für den benötigten Zweck | | Warranty | Zusicherung der Eignung für die tatsächliche Nutzung | --- **20. Praxisbeispiel: Managed Backup Service** **Service Provider** Ein externes IT-Unternehmen betreibt den Backup-Service. **Service Consumer** Ein mittelständisches Unternehmen verwendet den Service zur Sicherung seiner Systeme. **Sponsor** Die Geschäftsführung genehmigt das Budget. **Customer** Die IT-Leitung definiert: - zu sichernde Systeme, - Aufbewahrungszeiten, - Wiederherstellungsziele, - Sicherheitsanforderungen, - Berichtsbedarf. **User** Administratoren verwenden: - Verwaltungsportal, - Statusberichte, - Wiederherstellungsfunktionen, - Supportkanäle. Indirekte Benutzer sind alle Beschäftigten, deren Daten und Anwendungen durch den Service geschützt werden. **Serviceangebot** - Zugriff auf Backup-Speicher, - automatisierte Sicherung, - verschlüsselte Übertragung, - Überwachung der Sicherungsläufe, - Benachrichtigung bei Fehlern, - Wiederherstellung auf Anforderung, - regelmäßige Wiederherstellungstests, - Berichte. **Provider-Beiträge** - Infrastruktur betreiben, - Sicherungssoftware pflegen, - Kapazität bereitstellen, - Fehler überwachen, - Support leisten, - Wiederherstellungen unterstützen. **Consumer-Beiträge** - zu sichernde Systeme melden, - erforderliche Zugänge bereitstellen, - Aufbewahrungsanforderungen definieren, - Fehlermeldungen bearbeiten, - Wiederherstellungen fachlich prüfen, - Änderungen an Systemen mitteilen. **Erwartete Outcomes** - Daten können nach Verlust wiederhergestellt werden. - Ausfallfolgen werden begrenzt. - gesetzliche und betriebliche Anforderungen werden unterstützt. - interne Administratoren werden von Routineaufgaben entlastet. > Erst getestete und fachlich bestätigte Wiederherstellungen zeigen, ob die Servicebeziehung das erwartete Outcome tatsächlich unterstützt. --- **21. Praxisbeispiel: interner Onboarding-Service** Ein neuer Beschäftigter soll am ersten Arbeitstag vollständig arbeitsfähig sein. **Beteiligte Provider** - Personalabteilung, - interne IT, - Gebäudemanagement, - Fachabteilung, - externe Softwareanbieter. **Consumer-Rollen** | Rolle | mögliches Beispiel | |---|---| | Sponsor | Leitung der einstellenden Organisationseinheit | | Customer | verantwortliche Führungskraft | | User | neuer Beschäftigter | **Benötigte Leistungen** - Benutzerkonto, - Endgerät, - E-Mail, - Zugriffsrechte, - Fachanwendungen, - Telefonie, - Gebäudezugang, - Sicherheitsunterweisung, - Dokumentation und Support. **Mögliches Outcome** Der neue Beschäftigte kann die vorgesehenen Aufgaben sicher und ohne unnötige Verzögerung ausführen. Einzelne technische Outputs reichen dafür nicht aus. Ein eingerichtetes Notebook erzeugt noch keinen vollständigen Wert, wenn: - das Benutzerkonto fehlt, - Berechtigungen nicht vorhanden sind, - Fachanwendungen nicht funktionieren, - niemand die Bedienung erklärt, - der Support nicht bekannt ist. --- **22. Typische Konflikte in Servicebeziehungen** | Konflikt | mögliche Ursache | |---|---| | Anforderungen werden nicht erfüllt | Anforderungen waren unklar, widersprüchlich oder nicht abgestimmt | | Benutzer lehnen den Service ab | Benutzerperspektive wurde nicht ausreichend berücksichtigt | | Sponsor zweifelt am Nutzen | Outcomes und Wirtschaftlichkeit wurden nicht belegt | | Provider erwartet mehr Mitwirkung | Consumer-Beiträge wurden nicht vereinbart | | Consumer erwartet nicht enthaltene Leistungen | Serviceangebot und Ausschlüsse sind unklar | | Service Levels werden erfüllt, trotzdem besteht Unzufriedenheit | Kennzahlen bilden die tatsächliche Erfahrung oder Outcomes nicht ab | | Änderungen führen zu Problemen | Kommunikation, Tests oder Verantwortlichkeiten fehlen | | Störungen eskalieren zu spät | Eskalationswege sind unbekannt oder ungeeignet | | Lieferant verursacht wiederholt Ausfälle | unterstützende Verträge passen nicht zu den Consumer-Anforderungen | | Kosten steigen unerwartet | Nutzung, Abrechnung und Kapazitätsentwicklung werden nicht ausreichend überwacht | Konflikte sollten nicht nur als Kommunikationsproblem behandelt werden. Sie können auf strukturelle Mängel hinweisen, beispielsweise: - ungeklärte Rollen, - ungeeignete Serviceangebote, - widersprüchliche Ziele, - fehlende Ressourcen, - unpassende Kennzahlen, - nicht beherrschte Lieferantenabhängigkeiten, - unrealistische Vereinbarungen. --- **23. Typische Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Der Benutzer ist automatisch der Kunde.“ | User und Customer sind unterschiedliche Rollen, auch wenn eine Person beide Rollen besitzen kann. | | „Wer bezahlt, definiert automatisch alle Anforderungen.“ | Der Sponsor autorisiert das Budget; die Anforderungen werden durch die Customer-Rolle bestimmt. | | „Der Provider erzeugt den Wert allein.“ | Wert entsteht durch das Zusammenwirken von Provider, Consumer und weiteren Stakeholdern. | | „Ein Produkt und ein Service sind dasselbe.“ | Ein Produkt ist eine Ressourcenkonfiguration; ein Service unterstützt die gemeinsame Wertschöpfung. | | „Ein Serviceangebot ist nur eine Preisliste.“ | Es beschreibt konkrete Leistungen, Zielgruppen, Bedingungen und Bestandteile des Angebots. | | „Bei einem Cloudservice besitzt der Consumer die Infrastruktur.“ | Normalerweise erhält er Zugriff auf Ressourcen, ohne deren Eigentum zu übernehmen. | | „Ein externer Provider übernimmt alle Risiken.“ | Risiken und Verantwortlichkeiten werden verteilt, aber nicht automatisch vollständig übertragen. | | „Interne Services benötigen keine Vereinbarungen.“ | Auch interne Servicebeziehungen benötigen klare Erwartungen und Verantwortlichkeiten. | | „Ein Vertrag reicht zur Steuerung der Beziehung aus.“ | Die Beziehung muss fortlaufend kommuniziert, überprüft und verbessert werden. | | „Der direkte Provider ist für Fehler seiner Lieferanten nicht zuständig.“ | Gegenüber dem Consumer gelten weiterhin die vereinbarten Verantwortlichkeiten des direkten Providers. | | „Ein Service ist erfolgreich, wenn er bereitgestellt wurde.“ | Entscheidend sind Nutzung, Outcomes, Erfahrung und tatsächlich erzeugter Wert. | --- **24. Checkliste für eine klare Servicebeziehung** - [ ] Der Service Provider ist eindeutig benannt. - [ ] Die konsumierende Organisation ist bestimmt. - [ ] Customer, User und Sponsor sind unterschieden. - [ ] Mehrfachrollen sind dokumentiert. - [ ] Die gewünschten Outcomes sind beschrieben. - [ ] Das Serviceangebot ist verständlich formuliert. - [ ] Waren, Ressourcenzugriffe und Service Actions sind unterschieden. - [ ] Enthaltene und ausgeschlossene Leistungen sind dokumentiert. - [ ] Beiträge des Providers sind festgelegt. - [ ] Beiträge des Consumers sind festgelegt. - [ ] Utility und Warranty sind abgestimmt. - [ ] Kosten und Risiken beider Seiten sind berücksichtigt. - [ ] Service Levels beziehen sich auf tatsächliche Anforderungen. - [ ] Sicherheits- und Datenschutzanforderungen sind vereinbart. - [ ] Lieferanten und Abhängigkeiten sind bekannt. - [ ] unterstützende Verträge passen zu den Consumer-Anforderungen. - [ ] Kommunikationswege sind festgelegt. - [ ] Eskalationswege sind bekannt. - [ ] Änderungen werden abgestimmt. - [ ] Service Reviews finden regelmäßig statt. - [ ] Benutzerfeedback wird berücksichtigt. - [ ] der tatsächlich erreichte Wert wird überprüft. - [ ] Verbesserungen werden priorisiert und nachverfolgt. - [ ] Beendigung, Übergang und Datenrückgabe sind geregelt. --- **25. Versionshinweis: ITIL 4 und ITIL (Version 5)** Die grundlegenden Rollen und Beziehungen bleiben auch in ITIL (Version 5) wichtig. Dazu gehören insbesondere: - Service Provider, - Service Consumer, - Customer, - User, - Sponsor, - gemeinsame Wertschöpfung, - Servicebeziehungen, - Beiträge mehrerer Stakeholder. ITIL (Version 5) verwendet für die finanzierende Consumer-Rolle teilweise die präzisere Bezeichnung **Consumer Sponsor**, um sie deutlicher von anderen Sponsorrollen abzugrenzen. Zusätzlich betrachtet ITIL (Version 5) die Perspektiven und Erfahrungen von Benutzern, Kunden, Consumer Sponsors und Provider-Rollen stärker entlang einer durchgängigen Product and Service Lifecycle Journey. Für Prüfungen und Zertifizierungen muss immer die Terminologie der jeweils zugrunde liegenden ITIL-Version und des offiziellen Lehrplans verwendet werden. --- **Merksatz** > Ein Service Provider stellt nicht einfach Technik bereit. Provider und Consumer bilden eine Servicebeziehung, in der Customer, User und Sponsor unterschiedliche Perspektiven vertreten. Ein klares Serviceangebot beschreibt, welche Waren, Ressourcenzugriffe und Service Actions enthalten sind und welche Beiträge beide Seiten leisten müssen, damit die gewünschten Outcomes und gemeinsamer Wert entstehen. --- **Quellen und weiterführende Dokumentation** - [PeopleCert – ITIL Qualification Scheme](https://www.peoplecert.org/Frameworks-Professionals/ITIL-framework) - [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: Neuerungen](https://www.peoplecert.org/news-and-announcements/itil-version-5-foundation-whats-new-guide) - [PeopleCert – ITIL Experience (Version 5)](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-experience-version-5-4177) - [PeopleCert Community – Service Relationships und Value Co-Creation](https://community.peoplecert.org/en/public/clubs/itil/blogs/service-relationships-why-value-co-creation-is-a-first-date-and-how-to-get-a-second-2026-02-24) - [PeopleCert – ITIL 4 Foundation](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565) - [PeopleCert – ITIL 4 Specialist: Drive Stakeholder Value](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-specialist-drive-stakeholder-value-2693) - [PeopleCert – ITIL 4 Practitioner: Relationship Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-relationship-management-3870) - [PeopleCert – ITIL 4 Practitioner: Service Level Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-service-level-management-3867) - [TÜV Media – ITIL 4: Serviceangebote und Servicebeziehungen](https://itsm.tuev-media.de/docs/itil_4.html) # 2. ITIL verstehen – Aufbau, Prinzipien und Modelle # 2.1 Was ist ITIL und wie ist das Framework aufgebaut? > **Kurz erklärt** > > ITIL ist ein anpassbares Best-Practice-Framework für das Management digitaler Produkte und Services. > > Es unterstützt Organisationen dabei, technische und organisatorische Fähigkeiten so miteinander zu verbinden, dass für Benutzer, Kunden und weitere Stakeholder verlässliche Outcomes und nachhaltiger Wert entstehen. > > ITIL ist kein fertiger Unternehmensprozess, kein Ticketsystem und keine technische Anleitung. Das Framework stellt Begriffe, Prinzipien, Modelle und Management Practices bereit, die an die jeweilige Organisation angepasst werden müssen. --- **Was bedeutet ITIL?** Die Bezeichnung ITIL entstand ursprünglich aus dem Namen **Information Technology Infrastructure Library**. Heute wird **ITIL** als eigenständiger Name des Frameworks verwendet. Die aktuelle Generation ist **ITIL Version 5**. Sie betrachtet nicht mehr ausschließlich den Betrieb von IT-Services, sondern das integrierte Management digitaler Produkte und Services über ihren gesamten Lebenszyklus. Dazu gehören unter anderem: - Bedarf und Chancen erkennen, - Produkte und Services gestalten, - Lösungen beschaffen oder entwickeln, - Änderungen in die produktive Umgebung überführen, - Systeme betreiben, - Services bereitstellen, - Benutzer unterstützen, - Erfahrungen auswerten, - und Produkte, Services sowie Arbeitsweisen kontinuierlich verbessern. > **Merke** > > ITIL beschreibt nicht nur, wie bestehende IT-Services unterstützt werden. > > Es betrachtet auch, wie digitale Produkte und Services entstehen, zusammenwirken und über ihren gesamten Lebenszyklus Wert ermöglichen. --- **Was ist ein Framework?** Ein Framework ist ein strukturierter Orientierungsrahmen. Es stellt unter anderem bereit: - gemeinsame Begriffe, - grundlegende Prinzipien, - Modelle, - Practices, - Betrachtungsperspektiven, - Entscheidungshilfen, - und bewährte Vorgehensweisen. Ein Framework schreibt jedoch nicht jeden Arbeitsschritt verbindlich vor. ITIL legt beispielsweise nicht grundsätzlich fest: - welches Ticketsystem verwendet werden muss, - wie viele Supportgruppen eine Organisation benötigt, - welche Prioritätsmatrix eingesetzt werden muss, - wer jeden Change genehmigt, - wie ein Organigramm aufgebaut sein muss, - oder welche technischen Produkte eingesetzt werden sollen. Diese Entscheidungen hängen vom jeweiligen Kontext ab. Dazu gehören beispielsweise: - Größe der Organisation, - angebotene Produkte und Services, - gesetzliche und vertragliche Anforderungen, - Risiken, - Sicherheitsanforderungen, - vorhandene Fähigkeiten, - verwendete Technologien, - Unternehmenskultur, - und Zusammenarbeit mit Partnern und Lieferanten. > **Grundsatz** > > ITIL wird nicht unverändert „installiert“. > > Die Organisation verwendet geeignete Bestandteile des Frameworks und passt sie an ihren tatsächlichen Bedarf an. --- **ITIL ist Best-Practice-Guidance** ITIL stellt bewährte Orientierung für das Management digitaler Produkte und Services bereit. Best Practice bedeutet in diesem Zusammenhang: - Die beschriebenen Konzepte haben sich in vielen Organisationen als hilfreich erwiesen. - Die Inhalte bieten eine fachlich strukturierte Ausgangsbasis. - Die Empfehlungen müssen an den jeweiligen Kontext angepasst werden. - Eine andere Vorgehensweise kann in einer konkreten Organisation ebenfalls sinnvoll sein. - Betriebliche, gesetzliche und sicherheitsrelevante Vorgaben besitzen weiterhin Vorrang. ITIL ist deshalb weder: - eine gesetzliche Vorschrift, - eine technische Norm, - eine Produktzertifizierung, - noch eine Garantie für erfolgreiche Servicequalität. > **Typischer Fehler** > > Eine Organisation übernimmt Begriffe, Formulare und Genehmigungsstufen, ohne zu prüfen, welches konkrete Problem damit gelöst werden soll. > > Dadurch kann unnötige Bürokratie entstehen, ohne dass sich Produkte, Services oder Outcomes verbessern. --- **Wofür ITIL eingesetzt wird** ITIL kann Organisationen dabei unterstützen: - digitale Produkte und Services ganzheitlich zu betrachten, - gemeinsame Begriffe zu verwenden, - Verantwortlichkeiten zu klären, - Zusammenarbeit zwischen Teams zu verbessern, - Entscheidungen an Wert und Outcomes auszurichten, - technische und organisatorische Abhängigkeiten zu berücksichtigen, - Risiken bewusster zu behandeln, - Erfahrungen von Benutzern und Kunden einzubeziehen, - geeignete Management Practices zu etablieren, - Wertströme zu verstehen und zu verbessern, - und kontinuierliche Verbesserung in die tägliche Arbeit zu integrieren. ITIL kann in unterschiedlichen Organisationen eingesetzt werden. Beispiele: - interne IT-Abteilung, - Managed Service Provider, - Cloud-Anbieter, - Softwareunternehmen, - öffentliche Verwaltung, - Krankenhaus, - Produktionsunternehmen, - Bildungseinrichtung, - Finanzunternehmen, - oder gemeinnützige Organisation. Die Grundgedanken sind nicht auf eine bestimmte Branche oder Organisationsgröße beschränkt. --- **ITIL richtet sich nicht nur an IT-Service-Manager** ITIL ist für unterschiedliche Rollen relevant. Dazu gehören beispielsweise: - Fachinformatiker für Systemintegration, - Service-Desk-Mitarbeiter, - Systemadministratoren, - Netzwerkadministratoren, - Supporttechniker, - Produktverantwortliche, - Service Owner, - Entwickler, - Informationssicherheitsverantwortliche, - Projekt- und Change-Verantwortliche, - Lieferantenmanager, - Führungskräfte, - und Mitarbeiter aus Fachabteilungen. Nicht jede Rolle benötigt dasselbe Detailwissen. Ein Fachinformatiker für Systemintegration muss beispielsweise nicht jede strategische Entscheidung selbst treffen. Er sollte jedoch verstehen: - welcher Service von seiner technischen Arbeit abhängt, - welche Auswirkungen eine Änderung besitzen kann, - wie Incidents und Service Requests eingeordnet werden, - wann eine Eskalation notwendig ist, - welche Informationen dokumentiert werden müssen, - und wie technische Erkenntnisse in Verbesserungen einfließen. --- **Der zentrale Gedanke: Wert ermöglichen** ITIL richtet das Management digitaler Produkte und Services auf Wert aus. Wert entsteht nicht allein dadurch, dass eine technische Komponente vorhanden ist. Ein Service ist beispielsweise nicht automatisch wertvoll, nur weil: - ein Server läuft, - eine Anwendung installiert wurde, - ein Benutzerkonto existiert, - ein Backup erfolgreich beendet wurde, - oder ein Monitoring-System keine Warnung zeigt. Entscheidend ist, ob die beteiligten Stakeholder die benötigten Outcomes erreichen. Beispiele: | Technischer Output | Erwartetes Outcome | |---|---| | Benutzerkonto wurde angelegt. | Neuer Mitarbeiter kann seine Aufgaben ausführen. | | VPN-Client wurde installiert. | Mitarbeiter kann sicher von außerhalb arbeiten. | | Backup wurde erstellt. | Daten können nach einem Verlust wiederhergestellt werden. | | Anwendung wurde bereitgestellt. | Fachabteilung kann ihren Geschäftsprozess durchführen. | | Monitoring wurde eingerichtet. | Relevante Störungen werden rechtzeitig erkannt und behandelt. | Bei der Bewertung von Wert berücksichtigt ITIL Version 5 insbesondere das Zusammenspiel von: - Outcomes, - Kosten, - Risiken, - Erfahrung, - Nachhaltigkeit, - und den Erwartungen der beteiligten Stakeholder. --- **Wert wird gemeinsam ermöglicht** Wert wird nicht ausschließlich vom Service Provider erzeugt und anschließend an einen passiven Kunden übergeben. Service Provider, Service Consumer und weitere Stakeholder wirken gemeinsam daran mit, dass ein gewünschtes Outcome erreicht wird. Beispiel: sicherer Fernzugriff **Der Service Provider stellt unter anderem bereit:** - VPN-Infrastruktur, - Identitätsprüfung, - Multi-Faktor-Authentifizierung, - Support, - Monitoring, - Sicherheitsmaßnahmen, - und Dokumentation. **Der Benutzer trägt unter anderem bei durch:** - Schutz seiner Zugangsdaten, - ordnungsgemäße Verwendung der MFA, - Verwendung eines geeigneten Endgeräts, - Einhaltung von Sicherheitsvorgaben, - und rechtzeitige Meldung von Störungen. **Die Fachabteilung oder Führungskraft trägt möglicherweise bei durch:** - Genehmigung des Zugriffs, - Festlegung notwendiger Berechtigungen, - rechtzeitige Mitteilung organisatorischer Änderungen, - und Überprüfung des tatsächlichen Bedarfs. > **Merke** > > Ein Service kann technisch bereitgestellt werden. > > Das gewünschte Outcome entsteht jedoch erst durch das Zusammenwirken der beteiligten Personen, Teams, Technologien und Arbeitsweisen. --- **Der Aufbau von ITIL Version 5** ITIL Version 5 besteht aus mehreren miteinander verbundenen Bestandteilen. | Bestandteil | Zweck | |---|---| | **Grundbegriffe des Produkt- und Service-Managements** | schaffen eine gemeinsame fachliche Sprache | | **Wertschöpfung und Servicebeziehungen** | erklären, wie Stakeholder gemeinsam Outcomes und Wert ermöglichen | | **vier Dimensionen** | unterstützen eine ganzheitliche Betrachtung | | **ITIL Value System** | verbindet die zentralen Elemente des Frameworks | | **Guiding Principles** | unterstützen Entscheidungen in unterschiedlichen Situationen | | **Governance** | sorgt für Steuerung, Überwachung und Verantwortlichkeit | | **Value Chain Activities** | beschreiben zentrale Aktivitäten zur Wertschöpfung | | **Management Practices** | stellen organisatorische Fähigkeiten und Ressourcen für bestimmte Aufgaben bereit | | **Continual Improvement** | unterstützt die fortlaufende Verbesserung | | **Product and Service Lifecycle** | verbindet Produkt- und Servicearbeit über einen gemeinsamen Lebenszyklus | | **Value Stream Mapping and Management** | macht den Arbeitsfluss zur Erzeugung von Wert sichtbar und verbesserbar | Diese Bestandteile dürfen nicht dauerhaft isoliert betrachtet werden. Sie ergänzen sich und werden abhängig von der jeweiligen Situation miteinander kombiniert. --- **Das ITIL Value System** Das **ITIL Value System** beschreibt, wie unterschiedliche Bestandteile und Aktivitäten einer Organisation zusammenwirken, um Wert zu ermöglichen. Es verbindet: - Guiding Principles, - Governance, - Value Chain Activities, - Management Practices, - und Continual Improvement. Das Value System dient als übergeordneter Orientierungsrahmen. Es hilft bei Fragen wie: - Woran sollen Entscheidungen ausgerichtet werden? - Wie wird die Organisation gesteuert und kontrolliert? - Welche Aktivitäten sind für die Wertschöpfung notwendig? - Welche Fähigkeiten und Practices werden benötigt? - Wie werden Erfahrungen und Ergebnisse für Verbesserungen genutzt? > **Wichtig** > > Das ITIL Value System ist kein einzelner Prozess. > > Es beschreibt das Zusammenwirken verschiedener Elemente des Produkt- und Service-Managements. Die einzelnen Bestandteile werden auf späteren Seiten dieses Kapitels ausführlich behandelt. --- **Die Guiding Principles** Die Guiding Principles sind allgemeine Empfehlungen, die Entscheidungen und Handlungen in unterschiedlichen Situationen unterstützen. Sie sollen dabei helfen: - den tatsächlichen Nutzen im Blick zu behalten, - vorhandene Fähigkeiten und Informationen zu berücksichtigen, - schrittweise und auf Grundlage von Feedback vorzugehen, - über Team- und Systemgrenzen hinweg zusammenzuarbeiten, - Produkte und Services ganzheitlich zu betrachten, - unnötige Komplexität zu vermeiden, - und geeignete Tätigkeiten zu optimieren oder zu automatisieren. Die Guiding Principles sind keine starren Arbeitsschritte. Sie dienen als Denk- und Entscheidungshilfe. Ein einzelner Grundsatz sollte nicht isoliert angewendet werden, wenn dadurch andere wichtige Perspektiven übersehen werden. > **Praxisbeispiel** > > Die Automatisierung einer Benutzeranlage kann Zeit sparen. > > Vor der Automatisierung muss jedoch verstanden werden: > > - welche Daten benötigt werden, > - welche Genehmigungen gelten, > - welche Fehler auftreten können, > - welche Sicherheitsanforderungen bestehen, > - und wie das Ergebnis kontrolliert wird. --- **Governance** Governance sorgt dafür, dass die Organisation: - eine klare Richtung besitzt, - Entscheidungen angemessen getroffen werden, - Verantwortlichkeiten festgelegt sind, - Leistung und Risiken überwacht werden, - und Tätigkeiten mit den Zielen der Organisation übereinstimmen. Governance ist nicht mit täglichem Management gleichzusetzen. Vereinfacht betrachtet: | Governance | Management | |---|---| | legt Richtung und Rahmenbedingungen fest | plant und koordiniert die praktische Umsetzung | | bewertet Bedürfnisse und Erwartungen | organisiert Ressourcen und Aktivitäten | | überwacht Leistung und Regelkonformität | führt Arbeit innerhalb der Vorgaben durch | | stellt Verantwortlichkeit sicher | bearbeitet konkrete Aufgaben und Entscheidungen | Beispiel: Die Unternehmensleitung kann vorgeben, dass administrative Zugriffe grundsätzlich durch Multi-Faktor-Authentifizierung geschützt werden müssen. Das zuständige IT-Team plant und implementiert anschließend die konkrete technische Lösung. --- **Die vier Dimensionen** ITIL verwendet vier Dimensionen, damit Produkte und Services nicht ausschließlich aus einer technischen Perspektive betrachtet werden. | Dimension | Typische Inhalte | |---|---| | **Organisationen und Menschen** | Rollen, Verantwortlichkeiten, Kompetenzen, Kommunikation und Kultur | | **Informationen und Technologie** | Daten, Anwendungen, Infrastruktur, Automatisierung und Wissen | | **Partner und Lieferanten** | Hersteller, Provider, Verträge und externe Abhängigkeiten | | **Wertströme und Prozesse** | Aktivitäten, Abläufe, Übergaben, Kontrollen und Arbeitsfluss | Die Dimensionen beeinflussen sich gegenseitig. Beispiel: Eine neue Monitoring-Plattform kann technisch leistungsfähig sein. Sie liefert trotzdem keinen ausreichenden Nutzen, wenn: - Mitarbeiter nicht geschult wurden, - Verantwortlichkeiten für Alarme unklar sind, - ein externer Provider nicht eingebunden ist, - oder kein geregelter Ablauf für die Behandlung relevanter Events existiert. > **Merke** > > Ein technisches Problem kann organisatorische Ursachen besitzen. > > Ein organisatorisches Problem kann technische Folgen verursachen. --- **Der Product and Service Lifecycle** ITIL Version 5 verwendet ein gemeinsames Lebenszyklusmodell für digitale Produkte und Services. Das Modell umfasst acht miteinander verbundene Aktivitäten: 1. **Discover** – Bedarf, Chancen, Erwartungen und Ausgangslage verstehen 2. **Design** – geeignete Produkte, Services und Lösungen gestalten 3. **Acquire** – benötigte Ressourcen, Produkte oder Leistungen beschaffen 4. **Build** – Lösungen erstellen, konfigurieren, integrieren und testen 5. **Transition** – neue oder geänderte Lösungen kontrolliert in die vorgesehene Umgebung überführen 6. **Operate** – Produkte, Systeme und technische Fähigkeiten betreiben 7. **Deliver** – Services und vereinbarte Leistungen für Stakeholder bereitstellen 8. **Support** – Benutzer, Kunden, Produkte und Services unterstützen Die Aktivitäten bilden keinen starren linearen Ablauf. Je nach Situation können sie: - parallel stattfinden, - wiederholt werden, - sich gegenseitig beeinflussen, - oder Rücksprünge zu früheren Aktivitäten erforderlich machen. Beispiel: Während des Betriebs kann erkannt werden, dass eine Anwendung die Anforderungen der Benutzer nicht ausreichend erfüllt. Diese Erkenntnis kann erneut zu Discovery und Design führen, obwohl das Produkt bereits produktiv verwendet wird. > **Wichtig** > > Ein Produkt oder Service befindet sich nicht dauerhaft nur in einer einzigen Lebenszyklusaktivität. > > Unterschiedliche Versionen, Komponenten oder Verbesserungen können gleichzeitig verschiedene Aktivitäten durchlaufen. --- **Management Practices** Eine Management Practice ist mehr als ein einzelner Prozess. Sie umfasst organisatorische Ressourcen und Fähigkeiten, die zur Erreichung eines bestimmten Zwecks eingesetzt werden. Dazu können gehören: - Menschen und Rollen, - Informationen und Wissen, - Prozesse und Wertströme, - Technologien und Werkzeuge, - Partner und Lieferanten, - Regeln und Kontrollen, - sowie Kennzahlen und Verbesserungsmaßnahmen. Beispiele für Management Practices: - Incident Management, - Problem Management, - Service Request Management, - Change Management, - Service Configuration Management, - IT Asset Management, - Knowledge Management, - Monitoring and Event Management, - Information Security Management, - Supplier Management, - Service Level Management, - und Continual Improvement. ITIL Version 5 verwendet weiterhin **34 Management Practices**. Diese sind in zwei Gruppen eingeordnet: 1. **Product and Service Management Practices** 2. **General Management Practices** > **Typischer Fehler** > > Eine Practice wird ausschließlich als Ablaufdiagramm betrachtet. > > Für eine wirksame Practice werden jedoch auch Rollen, Informationen, Fähigkeiten, Werkzeuge, Beziehungen und kontinuierliche Verbesserungen benötigt. --- **Continual Improvement** Continual Improvement ist im gesamten ITIL-Framework verankert. Verbesserungen können sich beziehen auf: - Produkte, - Services, - technische Komponenten, - Practices, - Prozesse, - Wertströme, - Benutzererfahrung, - Zusammenarbeit, - Werkzeuge, - Dokumentation, - und Fähigkeiten von Mitarbeitern. Eine Verbesserung sollte nicht nur aus einer spontanen Idee bestehen. Sie sollte möglichst beantworten: - Was soll verbessert werden? - Warum ist die Verbesserung notwendig? - Wie sieht der aktuelle Zustand aus? - Welcher Zielzustand wird angestrebt? - Welche Maßnahme ist sinnvoll? - Wie wird die Wirkung überprüft? - Wie werden Erkenntnisse gesichert? Beispiel: Nach mehreren Störungen wird erkannt, dass ein ablaufendes Zertifikat nicht rechtzeitig bemerkt wurde. Eine nachhaltige Verbesserung könnte umfassen: - Zertifikate zentral erfassen, - Ablaufdaten überwachen, - rechtzeitig Warnungen erzeugen, - Verantwortlichkeiten festlegen, - Erneuerungsverfahren dokumentieren, - und die Wirksamkeit der Alarmierung testen. --- **Value Streams** Ein Value Stream beschreibt die Abfolge von Schritten, durch die für einen Stakeholder Wert ermöglicht wird. Ein Value Stream kann mehrere: - Teams, - Practices, - Technologien, - Lieferanten, - und organisatorische Bereiche miteinander verbinden. Beispiel: neuer Mitarbeiter benötigt einen arbeitsfähigen IT-Arbeitsplatz Mögliche Schritte: 1. Personalabteilung meldet den Eintritt. 2. Führungskraft benennt Aufgaben und Berechtigungen. 3. Benutzerkonto wird erstellt. 4. Lizenzen werden zugewiesen. 5. Endgerät wird vorbereitet. 6. Sicherheitsmaßnahmen werden eingerichtet. 7. Zugriffe werden getestet. 8. Gerät und Zugangsdaten werden übergeben. 9. Benutzer bestätigt die Arbeitsfähigkeit. 10. Dokumentation und Asset-Daten werden aktualisiert. An diesem Value Stream können unter anderem beteiligt sein: - Personalabteilung, - Führungskraft, - Service Desk, - Identitätsmanagement, - Endgeräteverwaltung, - Informationssicherheit, - Einkauf, - Lieferanten, - und der neue Mitarbeiter. > **Merke** > > Ein Value Stream folgt dem Weg zum gewünschten Outcome. > > Er endet nicht automatisch an der Grenze eines einzelnen Teams. --- **ITIL verbindet Produkt- und Serviceperspektive** Digitale Produkte und Services sind zwei eng miteinander verbundene Perspektiven auf eine technologiebasierte Lösung. Die Produktperspektive betrachtet beispielsweise: - Entwicklung, - Funktionen, - Roadmap, - technische Fähigkeiten, - Lebenszyklus, - Investitionen, - und Weiterentwicklung. Die Serviceperspektive betrachtet beispielsweise: - Nutzung, - Servicequalität, - Unterstützung, - Beziehungen, - Erfahrung, - Verfügbarkeit, - und vereinbarte Outcomes. Beide Perspektiven benötigen einander. | Ohne ausreichende Produktperspektive | Ohne ausreichende Serviceperspektive | |---|---| | technische Schulden werden übersehen | Benutzeranforderungen werden übersehen | | Produktentwicklung erfolgt ohne langfristige Planung | Support und Betrieb werden zu spät berücksichtigt | | Funktionen werden unkoordiniert erweitert | technisch erfolgreiche Produkte liefern keine brauchbaren Services | | Lebenszyklus und Ablösung bleiben ungeklärt | Erfahrung und Servicequalität werden nicht ausreichend bewertet | ITIL Version 5 verbindet diese Perspektiven durch einen gemeinsamen Produkt- und Service-Lebenszyklus. --- **Was ITIL nicht vorgibt** ITIL gibt keinen universellen Musterprozess für jede Organisation vor. Das Framework bestimmt nicht automatisch: - die konkrete Organisationsstruktur, - die Anzahl der Supportebenen, - die verwendete Software, - die Namen interner Teams, - die Prioritätsstufen, - die Servicezeiten, - die Genehmigungsbefugnisse, - die genaue Ticketstruktur, - oder die technische Architektur. Diese Elemente müssen von der Organisation selbst gestaltet werden. ITIL unterstützt dabei mit: - gemeinsamen Begriffen, - Prinzipien, - Modellen, - Practices, - und bewährten Fragestellungen. --- **ITIL ist keine Zertifizierung einer Organisation** Personen können ITIL-Zertifizierungen erwerben. Das bedeutet jedoch nicht automatisch, dass: - ihre Organisation vollständig nach ITIL arbeitet, - alle beschriebenen Practices eingeführt wurden, - Prozesse wirksam sind, - Services eine hohe Qualität besitzen, - oder jede interne Regel einer offiziellen ITIL-Vorgabe entspricht. Auch ein Werkzeug kann bestimmte ITIL-Practices unterstützen oder dafür bewertet worden sein. Das Werkzeug allein führt jedoch kein wirksames Service Management ein. > **Merke** > > Zertifikate, Werkzeuge und Prozessdokumente können professionelles Service Management unterstützen. > > Entscheidend ist, wie wirksam die Organisation tatsächlich arbeitet und welche Outcomes sie erreicht. --- **ITIL und andere Methoden oder Frameworks** ITIL kann gemeinsam mit anderen Ansätzen verwendet werden. Beispiele: | Ansatz | Mögliche Ergänzung zu ITIL | |---|---| | **Agile Arbeitsweisen** | iterative Entwicklung und schnelles Feedback | | **Scrum** | strukturierte Produktentwicklung in Teams | | **Kanban** | Visualisierung und Steuerung des Arbeitsflusses | | **DevOps** | Zusammenarbeit zwischen Entwicklung, Betrieb und weiteren Beteiligten | | **Lean** | Reduzierung von Verschwendung und Verbesserung des Flusses | | **COBIT** | Governance und Steuerung von Information und Technologie | | **ISO/IEC 20000** | Anforderungen an ein Service-Management-System | | **ISO/IEC 27001** | Anforderungen an ein Informationssicherheitsmanagementsystem | | **Projektmanagement** | zeitlich begrenzte Vorhaben mit definierten Zielen | ITIL verlangt nicht, diese Ansätze zu ersetzen. Sie können sich ergänzen, wenn: - Begriffe und Verantwortlichkeiten geklärt sind, - Ziele aufeinander abgestimmt werden, - doppelte oder widersprüchliche Regeln vermieden werden, - und die kombinierte Arbeitsweise einen erkennbaren Nutzen besitzt. --- **Praxisbeispiel: Eine neue Monitoring-Lösung** Eine Organisation möchte eine neue Monitoring-Lösung einführen. Eine rein technische Betrachtung könnte sich konzentrieren auf: - Serveranforderungen, - Agenten, - Netzwerkzugriffe, - Dashboards, - Alarmregeln, - und Datenspeicherung. Die ITIL-Perspektive ergänzt weitere Fragen. **Wert und Outcomes** - Welches Problem soll das Monitoring lösen? - Welche Ausfälle sollen früher erkannt werden? - Wer verwendet die Informationen? - Welches Outcome wird erwartet? **Vier Dimensionen** - Wer bearbeitet Alarme? - Welche Technologien und Daten werden benötigt? - Welche Lieferanten sind beteiligt? - Wie sieht der Ablauf vom Event bis zur Reaktion aus? **Lebenszyklus** - Wie wird der Bedarf untersucht? - Wie wird die Lösung gestaltet? - Wird sie beschafft oder selbst aufgebaut? - Wie wird sie getestet und eingeführt? - Wie wird sie betrieben und unterstützt? **Practices** - Monitoring and Event Management - Incident Management - Service Configuration Management - IT Asset Management - Information Security Management - Supplier Management - Continual Improvement **Verbesserung** - Wie wird gemessen, ob relevante Störungen früher erkannt werden? - Werden unnötige Alarme reduziert? - Werden Erkenntnisse aus Incidents in neue Überwachungsregeln übernommen? Dieses Beispiel zeigt, dass ITIL die technische Umsetzung nicht ersetzt. Es erweitert die Betrachtung um Ziele, Stakeholder, Lebenszyklus, Zusammenarbeit, Risiken und Verbesserung. --- **Typische Missverständnisse** **Missverständnis 1: ITIL schreibt jeden Prozess genau vor** ITIL stellt anpassbare Best-Practice-Guidance bereit. Die konkrete Umsetzung wird von der Organisation gestaltet. --- **Missverständnis 2: ITIL ist nur für große Unternehmen geeignet** Auch kleine Organisationen können geeignete Grundsätze, Practices und einfache Arbeitsweisen verwenden. Der Umfang muss zum tatsächlichen Bedarf passen. --- **Missverständnis 3: ITIL bedeutet viele Formulare und Genehmigungen** Unnötige Bürokratie widerspricht einer sinnvollen Anpassung des Frameworks. Kontrollen sollen einen erkennbaren Zweck erfüllen. --- **Missverständnis 4: ITIL ersetzt technisches Fachwissen** ITIL unterstützt die Organisation technischer Arbeit. Es erklärt nicht die konkrete Konfiguration jedes Produkts. --- **Missverständnis 5: ITIL betrifft nur den Service Desk** Produktentwicklung, Betrieb, Support, Informationssicherheit, Lieferantensteuerung, Governance und Führung können ebenfalls beteiligt sein. --- **Missverständnis 6: Ein ITIL-Begriff muss intern zwingend genauso heißen** Organisationen können eigene Bezeichnungen verwenden. Wichtig ist, dass Bedeutung, Verantwortung und Arbeitsweise eindeutig sind. --- **Missverständnis 7: ITIL Version 5 macht alles aus ITIL 4 ungültig** ITIL Version 5 entwickelt viele bestehende Konzepte weiter. ITIL-4-Wissen bleibt in zahlreichen Bereichen relevant, muss bei versionsabhängigen Aussagen jedoch richtig eingeordnet werden. --- **Wie ein Systemintegrator ITIL praktisch verwendet** Ein Fachinformatiker für Systemintegration muss nicht vor jeder Handlung das gesamte Framework analysieren. Für den Arbeitsalltag können bereits folgende Fragen hilfreich sein: 1. Welcher Service oder welches Produkt ist betroffen? 2. Welches Outcome wird benötigt? 3. Welche Stakeholder sind beteiligt? 4. Welche der vier Dimensionen müssen berücksichtigt werden? 5. Welche technischen und organisatorischen Abhängigkeiten bestehen? 6. Welche Practice unterstützt die Aufgabe? 7. Welche Risiken und Vorgaben müssen beachtet werden? 8. Wie wird der Erfolg überprüft? 9. Was muss dokumentiert werden? 10. Was kann anschließend verbessert werden? --- **Checkliste zur Einordnung einer neuen Aufgabe** - [ ] Welches Produkt oder welcher Service ist betroffen? - [ ] Welches Outcome soll erreicht werden? - [ ] Wer sind die relevanten Stakeholder? - [ ] Welche technischen Komponenten sind beteiligt? - [ ] Welche organisatorischen Rollen sind beteiligt? - [ ] Welche Partner oder Lieferanten werden benötigt? - [ ] Welcher Wertstrom wird durchlaufen? - [ ] Welche Management Practices sind relevant? - [ ] Welche gesetzlichen, vertraglichen oder betrieblichen Vorgaben gelten? - [ ] Welche Risiken bestehen? - [ ] Wie wird das Ergebnis überprüft? - [ ] Wie können Erkenntnisse für spätere Verbesserungen genutzt werden? --- **Schnellzusammenfassung** | Begriff | Kurzbeschreibung | |---|---| | **ITIL** | anpassbares Best-Practice-Framework für digitales Produkt- und Service-Management | | **Framework** | strukturierter Orientierungsrahmen, kein starrer Musterprozess | | **Wert** | wahrgenommener Nutzen für Stakeholder | | **Value System** | verbindet zentrale Bestandteile des Frameworks zur Wertschöpfung | | **Guiding Principles** | allgemeine Empfehlungen für Entscheidungen und Handlungen | | **Governance** | Richtung, Überwachung und Verantwortlichkeit | | **vier Dimensionen** | ganzheitliche Betrachtung von Produkten und Services | | **Lifecycle** | gemeinsame Lebenszyklusbetrachtung digitaler Produkte und Services | | **Practice** | organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck | | **Value Stream** | Abfolge von Schritten zur Ermöglichung von Wert | | **Continual Improvement** | fortlaufende Verbesserung von Produkten, Services und Arbeitsweisen | --- **Aufbau dieses Kapitels** Die folgenden Seiten vertiefen die einzelnen Bestandteile des Frameworks: - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.4 Governance und Verantwortlichkeit - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 2.10 ITIL an den eigenen Kontext anpassen --- **Übersicht des Frameworks** > Bedürfnisse, Chancen und Erwartungen > ↓ > ITIL Value System > ↓ > Guiding Principles · Governance · Value Chain Activities · Management Practices · Continual Improvement > ↓ > gemeinsamer Product and Service Lifecycle > ↓ > digitale Produkte und Services > ↓ > Outcomes und gemeinsam ermöglichter Wert Die Darstellung ist eine vereinfachte Orientierung. Die Elemente wirken nicht ausschließlich in einer linearen Reihenfolge, sondern beeinflussen sich gegenseitig. --- **Verwandte Seiten** - 1.1 Warum professionelles Service Management notwendig ist - 1.2 Technik, Produkt, Service und Geschäftsergebnis - 1.3 Wert, Nutzen, Kosten und Risiken - 1.4 Servicebeziehungen, Rollen und Serviceangebote - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.9 Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert: *ITIL Foundation – Version 5* - ITIL: *ITIL Foundation – Version 5* - ITIL: *ITIL Foundation Version 5 – What’s New?* - ITIL: *New ITIL Explained for Certified Professionals* - ITIL: *New ITIL Product and Service Lifecycle Model* **Einordnung** Die Aussagen zum Aufbau von ITIL Version 5, zum ITIL Value System, zu den vier Dimensionen, den Guiding Principles, Management Practices, Continual Improvement und dem gemeinsamen Produkt- und Service-Lebenszyklus wurden anhand der genannten offiziellen Quellen geprüft. Die Praxisbeispiele, Tabellen, Checklisten und vereinfachten Darstellungen sind zusätzliche Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.2 Das ITIL Value System > **Kurz erklärt** > > Das ITIL Value System beschreibt, wie die verschiedenen Bestandteile und Aktivitäten einer Organisation als zusammenhängendes System wirken, um Wert zu ermöglichen. > > Es verbindet: > > - Guiding Principles, > - Governance, > - Value Chain Activities, > - Management Practices, > - und Continual Improvement. > > Ausgangspunkte sind Chancen, Anforderungen und Nachfrage. Das angestrebte Ergebnis ist gemeinsam ermöglichter Wert für Kunden, Benutzer, die Organisation und weitere Stakeholder. --- **Warum ein Value System notwendig ist** Digitale Produkte und Services entstehen nicht durch einen einzelnen Prozess oder ein einzelnes Team. An ihrer Planung, Bereitstellung, Nutzung und Verbesserung können unter anderem beteiligt sein: - Unternehmensleitung, - Fachabteilungen, - Produktteams, - Entwicklung, - Systemadministration, - Netzwerkbetrieb, - Service Desk, - Informationssicherheit, - Einkauf, - externe Dienstleister, - Hersteller, - Kunden, - und Benutzer. Jeder dieser Beteiligten kann eigene: - Ziele, - Aufgaben, - Informationen, - Werkzeuge, - Prioritäten, - Risiken, - und Verantwortlichkeiten besitzen. Werden diese Bereiche voneinander isoliert gesteuert, können lokale Verbesserungen entstehen, die dem gesamten Produkt oder Service schaden. Beispiele: - Ein Team optimiert seine Bearbeitungszeit, erzeugt aber zusätzliche Übergaben für andere Teams. - Eine Sicherheitsmaßnahme wird technisch korrekt umgesetzt, verhindert jedoch die Nutzung einer wichtigen Fachanwendung. - Eine neue Anwendung wird bereitgestellt, ohne Monitoring, Support und Wiederherstellung ausreichend vorzubereiten. - Ein Ticketsystem wird automatisiert, obwohl die zugrunde liegende Arbeitsweise unklar ist. - Ein Service erfüllt technische Kennzahlen, ermöglicht aber nicht das erwartete Outcome. Das Value System unterstützt deshalb eine ganzheitliche Betrachtung. > **Merke** > > Professionelles Produkt- und Service-Management entsteht nicht durch einzelne optimierte Bestandteile. > > Entscheidend ist, wie alle Bestandteile zusammenwirken. --- **Vom Bedarf zum Wert** Das ITIL Value System kann vereinfacht folgendermaßen dargestellt werden: > Chance oder Nachfrage > ↓ > ITIL Value System > ↓ > digitale Produkte und Services > ↓ > Outcomes, Erfahrungen und gemeinsam ermöglichter Wert **Nachfrage** kann beispielsweise entstehen durch: - einen neuen Mitarbeiter, - einen gemeldeten Incident, - eine benötigte Berechtigung, - eine gesetzliche Anforderung, - einen höheren Kapazitätsbedarf, - eine neue Geschäftsanwendung, - oder einen vereinbarten Service Request. **Eine Chance** kann beispielsweise entstehen durch: - Automatisierung, - neue Technologie, - verbesserte Monitoring-Daten, - Rückmeldungen von Benutzern, - Erkenntnisse aus einem Incident, - eine neue Lieferantenleistung, - oder eine mögliche Vereinfachung eines Arbeitsablaufs. Das Value System soll dabei helfen, Nachfrage und Chancen nicht isoliert zu bearbeiten, sondern kontrolliert in wertschöpfende Ergebnisse zu überführen. > **Wichtig** > > Nicht jede Nachfrage muss unverändert erfüllt werden. > > Nicht jede technische Möglichkeit besitzt automatisch einen ausreichenden Nutzen. > > Anforderungen und Chancen müssen hinsichtlich Outcomes, Wert, Kosten, Risiken, Erfahrung und Nachhaltigkeit bewertet werden. --- **Die fünf Bestandteile des ITIL Value Systems** | Bestandteil | Zentrale Aufgabe | |---|---| | **Guiding Principles** | unterstützen Entscheidungen und Handlungen in unterschiedlichen Situationen | | **Governance** | gibt Richtung, überwacht die Organisation und stellt Verantwortlichkeit sicher | | **Value Chain Activities** | bilden ein flexibles Betriebsmodell für wertschöpfende Arbeit | | **Management Practices** | stellen benötigte organisatorische Ressourcen und Fähigkeiten bereit | | **Continual Improvement** | verbessert Produkte, Services, Practices und Arbeitsweisen fortlaufend | Diese Bestandteile sind keine voneinander getrennten Ebenen. Sie wirken gleichzeitig und beeinflussen sich gegenseitig. --- **Das Value System ist kein einzelner Prozess** Ein Prozess beschreibt normalerweise eine strukturierte Abfolge von Aktivitäten, durch die bestimmte Eingaben in Ergebnisse überführt werden. Das Value System ist umfassender. Es verbindet: - Entscheidungsgrundsätze, - Steuerung, - operative Aktivitäten, - organisatorische Fähigkeiten, - Rollen, - Informationen, - Technologien, - Partner, - Wertströme, - und Verbesserung. > **Typischer Fehler** > > Das ITIL Value System wird als festes Ablaufdiagramm verstanden, das bei jedem Vorgang Schritt für Schritt durchlaufen werden muss. > > Tatsächlich ist es ein übergeordneter Orientierungsrahmen, innerhalb dessen unterschiedliche Wertströme und Arbeitsabläufe gestaltet werden. Ein Incident wird beispielsweise anders bearbeitet als: - die Einführung einer neuen Anwendung, - die Bereitstellung eines Arbeitsplatzes, - eine Sicherheitsverbesserung, - oder die Ablösung eines veralteten Servers. Alle diese Situationen können jedoch innerhalb desselben Value Systems gesteuert werden. --- **Guiding Principles** Die Guiding Principles sind allgemeine Empfehlungen für Entscheidungen und Handlungen. Sie gelten unabhängig davon: - welche Rolle eine Person besitzt, - welches Produkt betroffen ist, - welche Practice verwendet wird, - welche Technologie eingesetzt wird, - oder wie groß die Organisation ist. Die sieben Guiding Principles sind: 1. **Focus on value** 2. **Start where you are** 3. **Progress iteratively with feedback** 4. **Collaborate and promote visibility** 5. **Think and work holistically** 6. **Keep it simple and practical** 7. **Optimize and automate** Praxisnahe Bedeutung: | Guiding Principle | Leitfrage | |---|---| | **Focus on value** | Welchen Nutzen und welches Outcome soll die Tätigkeit ermöglichen? | | **Start where you are** | Was funktioniert bereits und welche Informationen sind vorhanden? | | **Progress iteratively with feedback** | Kann die Verbesserung in kontrollierten Schritten erfolgen? | | **Collaborate and promote visibility** | Wer muss beteiligt werden und welche Informationen müssen sichtbar sein? | | **Think and work holistically** | Welche Produkte, Services, Menschen und Abhängigkeiten sind betroffen? | | **Keep it simple and practical** | Welche Schritte sind wirklich notwendig? | | **Optimize and automate** | Was sollte zuerst verbessert und anschließend sinnvoll automatisiert werden? | Die Guiding Principles ersetzen keine technische Analyse und keine betriebliche Vorgabe. Sie helfen dabei, Entscheidungen aus mehreren Perspektiven zu prüfen. > **Praxisbeispiel** > > Ein Administrator möchte die Anlage neuer Benutzerkonten automatisieren. > > Die Guiding Principles führen unter anderem zu folgenden Fragen: > > - Welches Outcome soll verbessert werden? > - Welche funktionierenden Abläufe existieren bereits? > - Kann zunächst ein kleiner Teil automatisiert werden? > - Sind Personalabteilung, Führungskräfte und Informationssicherheit eingebunden? > - Welche Abhängigkeiten bestehen zu Lizenzen, Gruppen und Endgeräten? > - Welche unnötigen Schritte können entfernt werden? > - Wie werden Fehler, Ausnahmen und Ergebnisse kontrolliert? Die Guiding Principles werden auf der Seite **2.3 Die sieben Guiding Principles** ausführlich behandelt. --- **Governance** Governance stellt sicher, dass die Organisation angemessen geführt und kontrolliert wird. Dazu gehören insbesondere: - Ziele und Richtung festlegen, - Bedürfnisse und Erwartungen bewerten, - Verantwortlichkeiten bestimmen, - Entscheidungen kontrollieren, - Risiken überwachen, - Leistung bewerten, - und die Einhaltung verbindlicher Vorgaben sicherstellen. Governance wird häufig mit drei grundlegenden Tätigkeiten beschrieben: | Tätigkeit | Bedeutung | |---|---| | **Evaluate** | Situation, Bedürfnisse, Optionen, Leistung und Risiken bewerten | | **Direct** | Richtung, Prioritäten und Rahmenbedingungen vorgeben | | **Monitor** | Ergebnisse, Leistung, Risiken und Einhaltung überwachen | Beispiel: Eine Organisation beschließt, dass administrative Zugriffe durch Multi-Faktor-Authentifizierung geschützt werden müssen. **Governance bestimmt unter anderem:** - das Sicherheitsziel, - verbindliche Rahmenbedingungen, - Verantwortlichkeiten, - akzeptierbare Risiken, - und die erforderliche Überwachung. **Das Management organisiert anschließend:** - Produktauswahl, - technische Einführung, - Tests, - Kommunikation, - Support, - Dokumentation, - und laufenden Betrieb. > **Merke** > > Governance gibt Richtung und Rahmenbedingungen vor. > > Management plant, koordiniert und kontrolliert die praktische Umsetzung innerhalb dieses Rahmens. Governance ist nicht nur Aufgabe einer einzelnen Führungskraft. Je nach Organisation können verschiedene Gremien und Rollen beteiligt sein, beispielsweise: - Geschäftsführung, - IT-Leitung, - Informationssicherheit, - Datenschutz, - Architekturboard, - Risikomanagement, - Service Owner, - Product Owner, - und Change-Verantwortliche. --- **Value Chain Activities** Die Value Chain Activities bilden das operative Kernmodell des Value Systems. Sie beschreiben miteinander verbundene Tätigkeitsbereiche, die abhängig von der jeweiligen Situation zu Wertströmen kombiniert werden. Ein Wertstrom kann beispielsweise zeigen, wie eine Organisation: - einen Incident bearbeitet, - einen neuen Benutzer bereitstellt, - eine Anwendung einführt, - einen Change umsetzt, - einen Service verbessert, - oder einen veralteten Server ablöst. Die Value Chain Activities sind dabei keine starren Abteilungen. Eine einzelne Aktivität kann Beiträge mehrerer Teams und Practices enthalten. Beispiel: Bei der Bereitstellung eines neuen Arbeitsplatzes können beteiligt sein: - Personalabteilung, - Führungskraft, - Service Desk, - Einkauf, - Identitätsmanagement, - Endgeräteverwaltung, - Informationssicherheit, - Netzwerkbetrieb, - und externe Lieferanten. > **Wichtig** > > Ein Wertstrom wird durch das benötigte Outcome bestimmt. > > Er sollte nicht ausschließlich entlang bestehender Abteilungsgrenzen aufgebaut werden. ITIL Version 5 verwendet eine gegenüber ITIL 4 vereinfachte und praxisnähere Darstellung der Value Chain. Sie bleibt Bestandteil des ITIL Value Systems und ist vom neuen Product and Service Lifecycle zu unterscheiden. --- **Management Practices** Management Practices stellen organisatorische Ressourcen und Fähigkeiten bereit, die zur Durchführung bestimmter Aufgaben oder zur Erreichung bestimmter Ziele benötigt werden. Eine Practice besteht nicht nur aus einem Ablaufdiagramm. Sie kann umfassen: - Rollen und Verantwortlichkeiten, - Fähigkeiten und Kompetenzen, - Informationen und Wissen, - Prozesse und Arbeitsabläufe, - Technologien und Werkzeuge, - Partner und Lieferanten, - Regeln und Kontrollen, - Messgrößen, - sowie Verbesserungsmaßnahmen. Beispiele: | Practice | Typischer Beitrag | |---|---| | **Incident Management** | negative Auswirkungen von Incidents verringern und Servicebetrieb wiederherstellen | | **Service Request Management** | vereinbarte Benutzeranfragen wirksam bearbeiten | | **Problem Management** | Ursachen und Wahrscheinlichkeiten von Incidents reduzieren | | **Change Management** | Änderungen bewerten und kontrolliert ermöglichen | | **Knowledge Management** | benötigtes Wissen verfügbar und nutzbar machen | | **Service Configuration Management** | verlässliche Informationen über Services und Configuration Items bereitstellen | | **IT Asset Management** | IT-Assets über ihren Lebenszyklus verwalten | | **Monitoring and Event Management** | relevante Zustandsänderungen erkennen und bewerten | | **Information Security Management** | Sicherheitsanforderungen und Risiken angemessen behandeln | | **Supplier Management** | Lieferanten und deren Leistungen steuern | | **Continual Improvement** | Verbesserungen identifizieren, priorisieren und umsetzen | Mehrere Practices können gemeinsam einen Wertstrom unterstützen. Beispiel: Ein wiederkehrender Ausfall 1. Monitoring and Event Management erkennt eine Abweichung. 2. Incident Management koordiniert die Wiederherstellung. 3. Problem Management untersucht die zugrunde liegende Ursache. 4. Change Management unterstützt die kontrollierte dauerhafte Korrektur. 5. Knowledge Management stellt die Lösung bereit. 6. Service Configuration Management aktualisiert relevante Beziehungsinformationen. 7. Continual Improvement bewertet weitere Verbesserungsmöglichkeiten. > **Typischer Fehler** > > Eine Practice wird mit einem einzelnen Team gleichgesetzt. > > In der Praxis können mehrere Teams zu einer Practice beitragen und ein Team kann an mehreren Practices beteiligt sein. --- **Continual Improvement** Continual Improvement ist im gesamten Value System verankert. Verbessert werden können unter anderem: - Produkte, - Services, - technische Komponenten, - Practices, - Wertströme, - Prozesse, - Dokumentationen, - Werkzeuge, - Benutzererfahrungen, - Zusammenarbeit, - und Fähigkeiten von Mitarbeitern. Verbesserung ist nicht nur nach einem Fehler notwendig. Sie kann entstehen durch: - neue Chancen, - Feedback, - Kennzahlen, - technische Schulden, - geänderte Anforderungen, - neue Risiken, - neue Technologien, - oder Erkenntnisse aus dem laufenden Betrieb. > **Praxisbeispiel** > > Ein Zertifikat läuft unerwartet ab und verursacht einen Serviceausfall. > > Die unmittelbare Wiederherstellung behebt den Incident. > > Continual Improvement fragt zusätzlich: > > - Warum wurde das Ablaufdatum nicht rechtzeitig erkannt? > - Welche Zertifikate existieren noch? > - Wer ist verantwortlich? > - Kann eine zentrale Erfassung eingerichtet werden? > - Kann eine automatische Warnung erzeugt werden? > - Wie wird die Wirksamkeit der neuen Überwachung geprüft? Continual Improvement unterstützt jede Value Chain Activity und alle anderen Bestandteile des Value Systems. Es wird auf der Seite **2.9 Continual Improvement** ausführlich behandelt. --- **Wie die Bestandteile zusammenwirken** Die Bestandteile des Value Systems dürfen nicht isoliert betrachtet werden. Beispiel: Einführung einer neuen Backup-Lösung **Guiding Principles** - Welcher Wert soll entstehen? - Welche bestehende Lösung kann weiterverwendet werden? - Kann die Einführung schrittweise erfolgen? - Wer muss beteiligt werden? - Wie wird die gesamte Wiederherstellungskette betrachtet? - Welche Komplexität ist tatsächlich notwendig? - Welche Schritte können optimiert und automatisiert werden? **Governance** - Welche gesetzlichen und betrieblichen Anforderungen gelten? - Welche Daten müssen geschützt werden? - Welche Risiken sind akzeptabel? - Wer ist verantwortlich? - Wie wird die Einhaltung überwacht? **Value Chain Activities** - Wie wird aus dem Bedarf eine eingeführte und nutzbare Lösung? - Welche Aktivitäten, Übergaben und Entscheidungen sind notwendig? - Wie fließen Anforderungen, Tests und Rückmeldungen durch den Wertstrom? **Management Practices** Möglicherweise beteiligt: - Information Security Management, - Architecture Management, - Supplier Management, - IT Asset Management, - Service Configuration Management, - Change Management, - Deployment Management, - Monitoring and Event Management, - Incident Management, - und Continual Improvement. **Continual Improvement** - Werden Wiederherstellungen regelmäßig getestet? - Werden Fehlversuche analysiert? - Sind Sicherungszeiten und Wiederherstellungsziele angemessen? - Werden neue Systeme vollständig in die Sicherung aufgenommen? - Werden Erkenntnisse aus Tests umgesetzt? **Angestrebter Wert** - Daten können nach Verlust oder Ausfall innerhalb der vereinbarten Ziele wiederhergestellt werden. - Risiken und Betriebsunterbrechungen werden begrenzt. - Verantwortlichkeiten und Nachweise sind nachvollziehbar. --- **Value System, Lifecycle, Value Stream und Practice unterscheiden** Diese Begriffe beschreiben unterschiedliche Betrachtungsebenen. | Begriff | Bedeutung | |---|---| | **ITIL Value System** | übergeordneter Rahmen, der die Bestandteile der Organisation zur Wertschöpfung verbindet | | **Product and Service Lifecycle** | beschreibt die gemeinsamen Lebenszyklusaktivitäten digitaler Produkte und Services | | **Value Chain** | flexibles operatives Modell innerhalb des Value Systems | | **Value Stream** | konkrete Abfolge von Schritten für ein bestimmtes Outcome | | **Management Practice** | Ressourcen und Fähigkeiten für einen bestimmten Zweck | | **Prozess** | strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen | | **Arbeitsanweisung** | konkrete Beschreibung, wie eine bestimmte Tätigkeit ausgeführt wird | Beispiel: **Ziel:** Ein neuer Mitarbeiter soll am ersten Arbeitstag arbeitsfähig sein. | Betrachtung | Beispiel | |---|---| | **Value System** | verbindet Steuerung, Prinzipien, Practices und Verbesserung | | **Lifecycle** | berücksichtigt Gestaltung, Aufbau, Betrieb, Bereitstellung und Unterstützung der verwendeten Produkte und Services | | **Value Stream** | führt von der Eintrittsmeldung bis zum geprüften Arbeitsplatz | | **Practices** | unter anderem Service Request Management, IT Asset Management und Information Security Management | | **Prozess** | Ablauf zur Anlage eines Benutzerkontos | | **Arbeitsanweisung** | konkrete Schritte zur Kontoanlage im verwendeten Verzeichnisdienst | > **Merke** > > Das Value System beschreibt das große Ganze. > > Der Value Stream beschreibt den Weg zu einem konkreten Outcome. > > Eine Practice stellt Fähigkeiten bereit. > > Eine Arbeitsanweisung beschreibt die konkrete Durchführung. --- **Praxisbeispiel: Ein neuer Mitarbeiter beginnt** Die Personalabteilung meldet einen neuen Mitarbeiter. **Nachfrage** Der Mitarbeiter benötigt zum Eintrittsdatum einen arbeitsfähigen IT-Arbeitsplatz. **Angestrebtes Outcome** Der Mitarbeiter kann sich anmelden und alle für seine Tätigkeit freigegebenen Services verwenden. **Guiding Principles** - Fokus auf das tatsächlich benötigte Outcome - bestehende Onboarding-Abläufe berücksichtigen - schrittweise verbessern - Personalabteilung, Führungskraft und IT einbinden - vollständigen Ablauf betrachten - unnötige Sonderwege vermeiden - standardisierbare Tätigkeiten automatisieren **Governance** - Wer darf Zugriffe genehmigen? - Welche Sicherheitsrichtlinien gelten? - Welche Funktionstrennung ist notwendig? - Welche Daten dürfen verarbeitet werden? - Wer kontrolliert die ordnungsgemäße Bereitstellung? **Value Stream** 1. Eintritt wird gemeldet. 2. Aufgaben und benötigte Zugriffe werden bestimmt. 3. Genehmigungen werden eingeholt. 4. Benutzerkonto und Lizenzen werden bereitgestellt. 5. Endgerät wird vorbereitet. 6. Sicherheitsmaßnahmen werden eingerichtet. 7. Zugriffe werden getestet. 8. Gerät und Informationen werden übergeben. 9. Arbeitsfähigkeit wird bestätigt. 10. Asset- und Konfigurationsdaten werden aktualisiert. **Beteiligte Practices** - Service Request Management - IT Asset Management - Service Configuration Management - Information Security Management - Knowledge Management - Supplier Management - Change Management - Continual Improvement **Verbesserung** Nach jedem Onboarding kann geprüft werden: - Wurden alle Informationen rechtzeitig übermittelt? - Gab es unnötige Wartezeiten? - Fehlten Berechtigungen? - Waren Zuständigkeiten unklar? - Welche Schritte lassen sich vereinfachen oder automatisieren? --- **Bedeutung für Fachinformatiker für Systemintegration** Ein Fachinformatiker arbeitet häufig innerhalb mehrerer Bestandteile des Value Systems. Beispiele: | Tätigkeit | Bezug zum Value System | |---|---| | Incident analysieren | Value Stream und Incident Management | | Firewall-Regel ändern | Governance, Change Management und Information Security Management | | Server dokumentieren | Knowledge Management und Service Configuration Management | | Monitoring-Alarm bearbeiten | Monitoring and Event Management sowie Incident Management | | neuen Arbeitsplatz bereitstellen | Service Request Management, IT Asset Management und Value Stream | | Backup testen | Governance, Risikobehandlung und Continual Improvement | | wiederkehrenden Fehler automatisieren | Guiding Principles, Problem Management und Continual Improvement | Der einzelne Mitarbeiter steuert normalerweise nicht das gesamte Value System. Er trägt jedoch durch seine: - Entscheidungen, - technischen Maßnahmen, - Dokumentationen, - Rückmeldungen, - Eskalationen, - und Verbesserungsvorschläge zu dessen Wirksamkeit bei. --- **Wie du das Value System im Alltag verwendest** Bei einer neuen Aufgabe kannst du folgende Fragen stellen: 1. Welche Nachfrage oder Chance liegt vor? 2. Welches Outcome und welcher Wert werden erwartet? 3. Welche Stakeholder sind beteiligt? 4. Welche Guiding Principles helfen bei der Entscheidung? 5. Welche Governance-Vorgaben gelten? 6. Welcher Wertstrom wird durchlaufen? 7. Welche Practices und Fähigkeiten werden benötigt? 8. Welche Informationen und Technologien werden benötigt? 9. Welche Risiken und Abhängigkeiten bestehen? 10. Wie wird das Ergebnis überprüft? 11. Was kann anschließend verbessert werden? Diese Fragen müssen nicht in jedem kleinen Vorgang schriftlich beantwortet werden. Sie unterstützen jedoch eine strukturierte und ganzheitliche Denkweise. --- **Anzeichen für ein schlecht abgestimmtes Value System** Mögliche Warnzeichen sind: - Teams optimieren ausschließlich ihre eigenen Kennzahlen. - Verantwortlichkeiten für Services sind unklar. - Entscheidungen widersprechen sich. - Governance-Vorgaben sind unbekannt oder werden nicht kontrolliert. - Practices arbeiten voneinander isoliert. - Informationen gehen an Übergaben verloren. - Änderungen verursachen regelmäßig unerwartete Störungen. - Benutzererfahrungen werden nicht berücksichtigt. - Verbesserungen werden nicht priorisiert oder nachverfolgt. - Werkzeuge bestimmen die Arbeitsweise statt der benötigten Outcomes. - Lieferanten werden nicht ausreichend in Wertströme eingebunden. - Ergebnisse werden nur anhand technischer Outputs bewertet. Ein einzelnes Warnzeichen beweist noch kein grundsätzlich unwirksames Value System. Wiederholen sich mehrere dieser Muster, sollten Zusammenhänge und Schnittstellen untersucht werden. --- **Typische Fehler** **Fehler 1: Nur einzelne Practices einführen** Eine Organisation führt Incident Management ein, ohne: - Governance, - Wissensmanagement, - Konfigurationsinformationen, - Kommunikation, - oder Verbesserung ausreichend einzubeziehen. Das Ergebnis kann ein Ticketsystem mit vielen erfassten Incidents sein, ohne dass wiederkehrende Ursachen reduziert werden. --- **Fehler 2: Governance mit Bürokratie verwechseln** Governance soll Richtung, Verantwortlichkeit und Kontrolle sicherstellen. Sie bedeutet nicht automatisch: - viele Genehmigungsstufen, - lange Entscheidungswege, - oder unnötige Dokumente. Kontrollen müssen zum Risiko und zum Kontext passen. --- **Fehler 3: Value Streams entlang von Abteilungen gestalten** Ein Wertstrom sollte dem Weg zum Outcome folgen. Er sollte nicht künstlich an jeder Teamgrenze enden. --- **Fehler 4: Automatisieren, bevor der Ablauf verstanden wurde** Ein fehlerhafter oder unnötig komplexer Ablauf wird durch Automatisierung häufig nur schneller wiederholt. Zuerst verstehen und optimieren, danach automatisieren. --- **Fehler 5: Verbesserung als einmaliges Projekt behandeln** Continual Improvement ist keine einmalige Aufräumaktion. Es muss in die tägliche Arbeit und in alle Bestandteile des Value Systems integriert werden. --- **Fehler 6: Technische Outputs mit Wert gleichsetzen** Ein Server, Benutzerkonto oder Dashboard ist zunächst ein Output. Wert entsteht erst, wenn Stakeholder damit benötigte Outcomes erreichen. --- **Checkliste zur Bewertung eines Value Systems** - [ ] Sind die wichtigsten Produkte und Services bekannt? - [ ] Sind Kunden, Benutzer und weitere Stakeholder bestimmt? - [ ] Sind gewünschte Outcomes und Wertvorstellungen bekannt? - [ ] Werden die Guiding Principles bei Entscheidungen berücksichtigt? - [ ] Sind Governance-Verantwortlichkeiten eindeutig? - [ ] Sind verbindliche Vorgaben bekannt und kontrollierbar? - [ ] Sind wichtige Wertströme dokumentiert oder nachvollziehbar? - [ ] Arbeiten beteiligte Teams über Bereichsgrenzen hinweg zusammen? - [ ] Sind relevante Practices ausreichend entwickelt? - [ ] Sind Rollen, Informationen und Werkzeuge aufeinander abgestimmt? - [ ] Werden Partner und Lieferanten angemessen eingebunden? - [ ] Werden Ergebnisse statt nur Aktivitäten und Outputs gemessen? - [ ] Werden Risiken und Abhängigkeiten berücksichtigt? - [ ] Werden Erfahrungen und Rückmeldungen ausgewertet? - [ ] Werden Verbesserungen priorisiert und nachverfolgt? --- **Schnellzusammenfassung** | Bestandteil | Kernfrage | |---|---| | **Guiding Principles** | Wie sollten wir denken und entscheiden? | | **Governance** | Wer gibt Richtung vor und überwacht die Ergebnisse? | | **Value Chain Activities** | Welche operativen Tätigkeiten werden miteinander verbunden? | | **Management Practices** | Welche Fähigkeiten und Ressourcen werden benötigt? | | **Continual Improvement** | Wie werden Produkte, Services und Arbeitsweisen fortlaufend verbessert? | > **Gesamtfrage des Value Systems** > > Wie müssen alle Bestandteile der Organisation zusammenwirken, damit aus Chancen und Nachfrage nachhaltiger Wert entstehen kann? --- **Vereinfachte Darstellung** > Chancen und Nachfrage > ↓ > **Guiding Principles** > **Governance** > **Value Chain Activities** > **Management Practices** > **Continual Improvement** > ↓ > digitale Produkte und Services > ↓ > Outcomes, Erfahrungen und gemeinsam ermöglichter Wert Die Bestandteile wirken nicht ausschließlich nacheinander. Sie bilden ein zusammenhängendes System mit Rückmeldungen, Abhängigkeiten und fortlaufenden Verbesserungen. --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.3 Die sieben Guiding Principles - 2.4 Governance und Verantwortlichkeit - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 2.10 ITIL an den eigenen Kontext anpassen --- **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) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) - [ITIL: New ITIL Explained for Certified Professionals](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-explained) - [ITIL: Where do you start with ITIL? A case for continual improvement](https://www.itil.com/Itil-News-and-Announcements/where-do-you-start-with-ITIL) **Einordnung** Die Aussagen zu den fünf Bestandteilen des ITIL Value Systems, zur Überführung von Chancen und Nachfrage in Wert sowie zur fortlaufenden Bedeutung von Continual Improvement wurden anhand der genannten offiziellen ITIL- und PeopleCert-Quellen geprüft. Die konkreten Praxisbeispiele, Checklisten, Tabellen und vereinfachten Darstellungen sind zusätzliche Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar. Die öffentlich zugänglichen offiziellen Übersichtsseiten bestätigen für ITIL Version 5 eine vereinfachte Value Chain, veröffentlichen dort jedoch nicht alle Detaildarstellungen und Workflowdiagramme der offiziellen Foundation-Publikation. Deshalb werden an dieser Stelle keine nicht eindeutig öffentlich belegten Bezeichnungen einzelner neuer Value Chain Activities ergänzt. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.3 Die sieben Guiding Principles > **Kurz erklärt** > > Die sieben Guiding Principles sind allgemeine Empfehlungen, die Entscheidungen und Handlungen im digitalen Produkt- und Service-Management unterstützen. > > Sie können unabhängig davon angewendet werden: > > - welche Rolle eine Person besitzt, > - welches Produkt oder welcher Service betroffen ist, > - welche Management Practice verwendet wird, > - welche Technologie eingesetzt wird, > - und wie groß oder komplex die Organisation ist. > > Die Guiding Principles geben keine festen Arbeitsschritte vor. Sie helfen dabei, Situationen aus mehreren Perspektiven zu beurteilen und angemessene Entscheidungen zu treffen. --- **Die sieben Guiding Principles im Überblick** | Nr. | Guiding Principle | Praktische Bedeutung | |---:|---|---| | 1 | **Focus on value** | Arbeit am tatsächlich benötigten Wert und Outcome ausrichten | | 2 | **Start where you are** | vorhandene Fähigkeiten, Informationen und funktionierende Bestandteile berücksichtigen | | 3 | **Progress iteratively with feedback** | in überschaubaren Schritten vorgehen und Rückmeldungen auswerten | | 4 | **Collaborate and promote visibility** | geeignete Beteiligte einbeziehen und relevante Informationen sichtbar machen | | 5 | **Think and work holistically** | Produkte, Services, Menschen, Technologien und Abhängigkeiten gemeinsam betrachten | | 6 | **Keep it simple and practical** | nur Schritte und Kontrollen verwenden, die einen erkennbaren Nutzen besitzen | | 7 | **Optimize and automate** | Arbeitsweisen zuerst verstehen und verbessern, anschließend sinnvoll automatisieren | Die englischen Bezeichnungen werden beibehalten, da sie in offiziellen ITIL-Unterlagen und in der internationalen Praxis verwendet werden. Die deutschen Erläuterungen in diesem Buch sind sinngemäße Erklärungen und keine wörtlichen offiziellen Übersetzungen. --- **Fortführung in ITIL Version 5** ITIL Version 5 führt die Guiding Principles als Kernelement des ITIL Value Systems fort. Sie stammen bereits aus ITIL 4 und bleiben relevant, weil sie keine produktspezifischen oder kurzlebigen technischen Anweisungen darstellen. Die Prinzipien unterstützen vielmehr eine grundlegende Denkweise für: - Produktentwicklung, - Servicebereitstellung, - Betrieb, - Support, - Governance, - Zusammenarbeit, - Veränderung, - und kontinuierliche Verbesserung. ITIL Version 5 ergänzt den Anwendungskontext insbesondere um: - das integrierte Management digitaler Produkte und Services, - komplexe und schnell veränderliche Umgebungen, - den Einsatz von künstlicher Intelligenz, - digitale Erfahrung, - Nachhaltigkeit, - und den gemeinsamen Product and Service Lifecycle. > **Merke** > > Die Guiding Principles geben Orientierung, wenn ein detaillierter Ablauf allein nicht ausreicht oder eine Situation mehrere mögliche Vorgehensweisen zulässt. --- **Die Guiding Principles sind keine Prozessschritte** Die sieben Prinzipien bilden keine Reihenfolge, die von Nummer 1 bis Nummer 7 abgearbeitet werden muss. Sie können: - gleichzeitig angewendet werden, - sich gegenseitig ergänzen, - je nach Situation unterschiedlich stark gewichtet werden, - und bei jeder Management Practice berücksichtigt werden. Beispiel: Eine Organisation möchte die Bereitstellung neuer Benutzerkonten automatisieren. Dabei können gleichzeitig folgende Prinzipien relevant sein: - **Focus on value:** Der Mitarbeiter soll am ersten Arbeitstag arbeitsfähig sein. - **Start where you are:** Der bestehende Ablauf und vorhandene Datenquellen werden geprüft. - **Progress iteratively with feedback:** Zunächst wird nur ein klar abgegrenzter Teil automatisiert. - **Collaborate and promote visibility:** Personalabteilung, Führungskräfte, IT und Informationssicherheit werden einbezogen. - **Think and work holistically:** Konto, Endgerät, Lizenzen, Berechtigungen und Support werden gemeinsam betrachtet. - **Keep it simple and practical:** Unnötige Sonderwege und doppelte Dateneingaben werden entfernt. - **Optimize and automate:** Erst nach der Verbesserung wird der geeignete Ablauf automatisiert. > **Typischer Fehler** > > Nur das Prinzip auszuwählen, das die bereits bevorzugte Entscheidung unterstützt. > > Eine gute Entscheidung berücksichtigt alle relevanten Guiding Principles und mögliche Zielkonflikte. --- **1. Focus on value** > **Sinngemäße Bedeutung** > > Jede Tätigkeit sollte einen nachvollziehbaren Beitrag zum Wert für relevante Stakeholder leisten. Wert entsteht nicht allein dadurch, dass eine technische Aufgabe abgeschlossen wurde. Entscheidend ist, ob das benötigte Outcome erreicht und von den beteiligten Stakeholdern als nützlich wahrgenommen wird. Mögliche Stakeholder sind beispielsweise: - Benutzer, - Kunden, - Fachabteilungen, - Produktverantwortliche, - Service Provider, - Lieferanten, - Unternehmensleitung, - Informationssicherheit, - und Mitarbeiter des IT-Betriebs. Wert kann sich unter anderem zeigen durch: - zuverlässig nutzbare Services, - geringere Risiken, - kürzere Bearbeitungszeiten, - bessere Benutzererfahrung, - geringere Kosten, - bessere Zusammenarbeit, - höhere Sicherheit, - schnellere Wiederherstellung, - oder die Erfüllung gesetzlicher und vertraglicher Anforderungen. --- **Leitfragen zu Focus on value** - Welches Outcome soll erreicht werden? - Wer nimmt den Wert wahr? - Welches Problem wird tatsächlich gelöst? - Welcher Geschäftsprozess oder Benutzerbedarf wird unterstützt? - Wie wird festgestellt, ob das gewünschte Ergebnis erreicht wurde? - Welche Kosten und Risiken sind mit der Lösung verbunden? - Verbessert die Maßnahme auch die Erfahrung der betroffenen Benutzer? - Entsteht nur ein technischer Output oder ein tatsächlich nutzbares Ergebnis? --- **Praxisbeispiel: Backup** Ein Backup-System meldet jeden Tag einen erfolgreichen Sicherungslauf. Der technische Output lautet: > Die Sicherungsdaten wurden erzeugt. Der angestrebte Wert besteht jedoch darin, dass: - wichtige Daten geschützt sind, - Wiederherstellungen innerhalb der benötigten Zeit möglich sind, - Datenverluste begrenzt werden, - und die Organisation nach einem Ausfall weiterarbeiten kann. Um den tatsächlichen Wert zu beurteilen, müssen deshalb zusätzlich geprüft werden: - Sind alle notwendigen Systeme erfasst? - Sind die Sicherungsdaten verwendbar? - Wurden Wiederherstellungen getestet? - Werden die benötigten Wiederherstellungszeiten erreicht? - Sind Verantwortlichkeiten eindeutig? - Sind die Sicherungen gegen unbefugte Veränderung geschützt? > **Merke** > > Ein erfolgreich ausgeführter Sicherungslauf ist ein Output. > > Wiederherstellbare und ausreichend geschützte Daten ermöglichen das benötigte Outcome. --- **Typische Fehler bei Focus on value** - ausschließlich technische Kennzahlen betrachten - nur auf möglichst niedrige Kosten achten - den Wert nur aus Sicht eines einzelnen Stakeholders bewerten - Aktivitäten mit Ergebnissen verwechseln - eine neue Funktion bereitstellen, ohne ihren Nutzen zu prüfen - Benutzererfahrung und Risiken nicht berücksichtigen - eine Maßnahme fortführen, obwohl ihr ursprünglicher Zweck nicht mehr besteht --- **Bedeutung für Systemintegratoren** Vor einer technischen Maßnahme sollte nicht nur gefragt werden: > Wie führe ich diese Aufgabe aus? Zusätzlich sollte gefragt werden: > Warum wird diese Aufgabe durchgeführt und welches Ergebnis soll sie ermöglichen? Beispiele: | Technische Aufgabe | Wertorientierte Frage | |---|---| | Server neu starten | Welcher Service soll dadurch wiederhergestellt werden? | | neue Firewall-Regel einrichten | Welcher notwendige Zugriff wird ermöglicht und welches Risiko entsteht? | | Monitoring-Alarm anlegen | Welche relevante Störung soll dadurch früher erkannt werden? | | Benutzerkonto erstellen | Welche Arbeitsfähigkeit muss zum vorgesehenen Zeitpunkt bestehen? | | Anwendung aktualisieren | Welcher Nutzen entsteht und welche Risiken werden reduziert? | --- **2. Start where you are** > **Sinngemäße Bedeutung** > > Bevor etwas vollständig neu aufgebaut wird, sollen der aktuelle Zustand, vorhandene Fähigkeiten und bereits funktionierende Bestandteile untersucht werden. Ein bestehender Zustand ist selten vollständig schlecht oder vollständig gut. Auch in einer unzureichenden Arbeitsweise können bereits wertvolle Bestandteile vorhanden sein, beispielsweise: - erfahrene Mitarbeiter, - funktionierende technische Werkzeuge, - brauchbare Dokumentationen, - etablierte Kommunikationswege, - vorhandene Messdaten, - automatisierte Teilabläufe, - oder bewährte Notfallverfahren. Diese Bestandteile sollten erkannt und sinnvoll weiterverwendet werden. > **Wichtig** > > Start where you are bedeutet nicht, dass der vorhandene Zustand unverändert bleiben muss. > > Es bedeutet, dass Entscheidungen auf einer realistischen Bewertung des aktuellen Zustands beruhen sollen. --- **Leitfragen zu Start where you are** - Wie sieht der aktuelle Zustand tatsächlich aus? - Was funktioniert bereits? - Welche Probleme bestehen konkret? - Welche Daten und Messwerte liegen vor? - Welche Dokumentationen sind vorhanden? - Welche Fähigkeiten besitzen die beteiligten Mitarbeiter? - Welche Werkzeuge können weiterverwendet werden? - Welche Annahmen müssen überprüft werden? - Was kann übernommen, verbessert oder entfernt werden? - Welche Abhängigkeiten sind möglicherweise noch unbekannt? --- **Praxisbeispiel: neues Ticketsystem** Eine Organisation möchte ein neues Ticketsystem einführen. Eine ungeprüfte Vorgehensweise wäre: 1. neues Produkt auswählen 2. bestehende Daten vollständig verwerfen 3. neue Kategorien entwerfen 4. alle Abläufe gleichzeitig umstellen Die Anwendung von **Start where you are** führt zunächst zu einer Bestandsaufnahme: - Welche Vorgangsarten werden tatsächlich verwendet? - Welche Kategorien liefern brauchbare Informationen? - Welche Automatisierungen funktionieren bereits? - Welche Daten müssen übernommen werden? - Welche Probleme entstehen durch das Werkzeug? - Welche Probleme entstehen unabhängig vom Werkzeug? - Welche Berichte werden benötigt? - Welche Mitarbeiter kennen die tatsächlichen Abläufe? - Welche bestehenden Integrationen müssen erhalten bleiben? Dadurch wird verhindert, dass funktionierende Bestandteile unnötig ersetzt oder bekannte Fehler in das neue System übernommen werden. --- **Beobachten statt nur vermuten** Eine Bestandsaufnahme sollte nach Möglichkeit auf überprüfbaren Informationen beruhen. Geeignete Informationsquellen können sein: - technische Messwerte, - Tickets, - Monitoring-Daten, - Protokolle, - Konfigurationsinformationen, - Gespräche mit Beteiligten, - Benutzerfeedback, - Prozessbeobachtungen, - Berichte, - und dokumentierte Testergebnisse. > **Typischer Fehler** > > Eine Arbeitsweise wird allein anhand ihrer Dokumentation bewertet. > > Der tatsächlich gelebte Ablauf kann deutlich von der beschriebenen Vorgehensweise abweichen. --- **Bedeutung für Systemintegratoren** Bei einer Störung sollte nicht sofort davon ausgegangen werden, dass: - die zuletzt vermutete Ursache zutrifft, - ein bestimmtes System vollständig neu installiert werden muss, - oder eine neue Technologie automatisch die beste Lösung ist. Zuerst sollte geprüft werden: - Was funktioniert noch? - Welche Komponente zeigt tatsächlich eine Abweichung? - Was wurde zuletzt verändert? - Welche Informationen sind bereits vorhanden? - Gibt es bekannte Fehler oder frühere Incidents? - Welche funktionierenden Teile müssen geschützt werden? --- **3. Progress iteratively with feedback** > **Sinngemäße Bedeutung** > > Große Vorhaben sollen nach Möglichkeit in überschaubare Schritte unterteilt werden. Nach jedem geeigneten Schritt werden Ergebnisse und Rückmeldungen ausgewertet. Kleine, kontrollierbare Schritte können dazu beitragen: - Risiken früher zu erkennen, - Fehlentwicklungen zu begrenzen, - schneller nutzbare Ergebnisse zu liefern, - Erfahrungen früh einzubeziehen, - und Entscheidungen auf Grundlage tatsächlicher Ergebnisse zu verbessern. Iteration bedeutet nicht, ohne Ziel immer wieder dasselbe zu versuchen. Eine Iteration benötigt: - ein klares Teilziel, - einen begrenzten Umfang, - überprüfbare Ergebnisse, - Feedback, - und eine Entscheidung über den nächsten Schritt. --- **Leitfragen zu Progress iteratively with feedback** - Kann das Vorhaben in kleinere Teile zerlegt werden? - Welcher kleinste sinnvolle Schritt liefert verwertbares Wissen? - Welche Risiken können früh geprüft werden? - Wer gibt Feedback? - Wie wird das Ergebnis gemessen? - Welche Erkenntnisse müssen vor dem nächsten Schritt berücksichtigt werden? - Welche Abhängigkeiten verhindern eine sinnvolle Teilung? - Welche Rückfallmöglichkeit besteht? - Wann ist die nächste Iteration sinnvoll? --- **Praxisbeispiel: Einführung einer Monitoring-Plattform** Statt sofort alle Systeme zu überwachen, kann eine Organisation schrittweise vorgehen. **Erste Iteration** - einen kritischen Service auswählen - wichtigste Komponenten erfassen - wenige relevante Alarme konfigurieren - Verantwortlichkeiten festlegen - Benachrichtigung und Reaktion testen **Feedback auswerten** - Werden relevante Störungen erkannt? - Entstehen zu viele Fehlalarme? - Sind Schwellenwerte geeignet? - Erhalten die richtigen Personen die Meldungen? - Sind die Informationen zur Fehleranalyse ausreichend? **Nächste Iteration** - Alarmregeln verbessern - weitere Servicekomponenten aufnehmen - Dashboards ergänzen - Dokumentation aktualisieren - Automatisierung erweitern > **Merke** > > Eine kleine Iteration sollte nicht nur Arbeit erzeugen. > > Sie sollte ein verwertbares Ergebnis oder neues Wissen liefern. --- **Feedback richtig verwenden** Feedback kann aus unterschiedlichen Quellen stammen: - Benutzererfahrung, - technische Messwerte, - Supportanfragen, - Incidents, - Tests, - Rückmeldungen von Mitarbeitern, - Lieferanteninformationen, - Audits, - und Geschäftsergebnisse. Feedback ist nicht automatisch eine Anweisung. Es muss bewertet werden hinsichtlich: - Relevanz, - Zuverlässigkeit, - Ursache, - Häufigkeit, - Auswirkungen, - und Zusammenhang mit anderen Anforderungen. > **Typischer Fehler** > > Feedback wird erst am Ende eines umfangreichen Vorhabens eingeholt. > > Dann können grundlegende Fehlentscheidungen bereits hohe Kosten verursacht haben. --- **Bedeutung für Änderungen** Bei einer größeren technischen Änderung kann ein iteratives Vorgehen beispielsweise bedeuten: 1. Testumgebung verwenden 2. begrenzte Pilotgruppe auswählen 3. technische und servicebezogene Ergebnisse prüfen 4. Rückmeldungen auswerten 5. Konfiguration anpassen 6. kontrolliert auf weitere Systeme ausweiten 7. nach jeder Stufe überwachen Ein iteratives Vorgehen ist nicht immer möglich. Bei akuten Sicherheitsrisiken, gesetzlichen Fristen oder kritischen Störungen kann schnelles umfassendes Handeln notwendig sein. Auch dann sollten Ergebnisse und Rückmeldungen so früh wie möglich ausgewertet werden. --- **4. Collaborate and promote visibility** > **Sinngemäße Bedeutung** > > Geeignete Personen und Teams sollen zusammenarbeiten. Relevante Informationen, Entscheidungen, Risiken und Fortschritte müssen für die zuständigen Beteiligten sichtbar sein. Zusammenarbeit bedeutet nicht, jede Person an jeder Entscheidung zu beteiligen. Zu viele Beteiligte können: - Entscheidungen verzögern, - Verantwortlichkeiten verwischen, - unnötige Besprechungen erzeugen, - und den Arbeitsfluss behindern. Entscheidend ist, die richtigen Beteiligten zum richtigen Zeitpunkt mit den richtigen Informationen einzubeziehen. --- **Leitfragen zu Collaborate and promote visibility** - Wer besitzt notwendiges Fachwissen? - Wer trägt Verantwortung? - Wer ist von der Entscheidung betroffen? - Wer muss informiert werden? - Welche Informationen müssen sichtbar sein? - Welche Informationen dürfen aus Sicherheits- oder Datenschutzgründen nicht allgemein sichtbar sein? - Wie werden Entscheidungen dokumentiert? - Wo befinden sich aktuelle Statusinformationen? - Welche Übergaben bestehen? - Wo entstehen Informationsverluste oder Missverständnisse? --- **Praxisbeispiel: Änderung einer Firewall-Regel** Eine Fachabteilung benötigt eine neue Verbindung zu einem externen Dienst. Mögliche Beteiligte sind: - Anforderer, - Anwendungsverantwortlicher, - Netzwerkadministration, - Informationssicherheit, - Datenschutz, - externer Dienstleister, - Service Owner, - und Change-Verantwortlicher. Sichtbar sein sollten unter anderem: - Zweck der Verbindung, - Quelle und Ziel, - benötigte Ports und Protokolle, - betroffene Services, - Sicherheitsbewertung, - Freigabe, - geplanter Umsetzungszeitpunkt, - Testergebnis, - Rückfallplan, - und tatsächlich umgesetzte Konfiguration. > **Merke** > > Sichtbarkeit bedeutet nicht, dass jede Information öffentlich sein muss. > > Relevante Informationen müssen für die berechtigten und verantwortlichen Beteiligten zugänglich sein. --- **Warum Sichtbarkeit wichtig ist** Fehlende Sichtbarkeit kann dazu führen, dass: - mehrere Teams dieselbe Arbeit durchführen, - Änderungen miteinander kollidieren, - Incidents falsch priorisiert werden, - Entscheidungen nicht nachvollziehbar sind, - Risiken zu spät erkannt werden, - und Benutzer widersprüchliche Informationen erhalten. Geeignete Formen der Sichtbarkeit können sein: - aktueller Ticketstatus, - Service-Dashboard, - Change-Kalender, - dokumentierte Entscheidung, - Wissensartikel, - Konfigurationsinformationen, - Statusmeldung, - Kanban-Board, - oder gemeinsames Incident-Protokoll. --- **Zusammenarbeit und Verantwortung** Zusammenarbeit ersetzt keine eindeutige Verantwortung. Auch bei gemeinsamer Bearbeitung muss erkennbar bleiben: - Wer koordiniert? - Wer entscheidet? - Wer führt die Maßnahme aus? - Wer prüft das Ergebnis? - Wer informiert die Stakeholder? - Wer aktualisiert die Dokumentation? > **Typischer Fehler** > > Viele Personen werden informiert, aber niemand besitzt eine eindeutige Verantwortung für den nächsten Schritt. --- **5. Think and work holistically** > **Sinngemäße Bedeutung** > > Produkte, Services, Organisationen und ihre Bestandteile sollen als zusammenhängendes System betrachtet werden. Ein Service hängt selten nur von einer einzelnen technischen Komponente ab. Zu berücksichtigen sind unter anderem: - Menschen und Rollen, - Informationen, - Technologien, - Partner, - Lieferanten, - Prozesse, - Wertströme, - Sicherheitsanforderungen, - Kosten, - Risiken, - Erfahrungen, - und technische Abhängigkeiten. Die vier Dimensionen des Produkt- und Service-Managements unterstützen diese ganzheitliche Betrachtung. --- **Leitfragen zu Think and work holistically** - Welches Produkt oder welcher Service ist betroffen? - Welche technischen Komponenten gehören dazu? - Welche Benutzer und Geschäftsprozesse sind abhängig? - Welche Teams und Rollen sind beteiligt? - Welche Lieferanten werden benötigt? - Welche Informationen fließen zwischen den Beteiligten? - Welche Wechselwirkungen bestehen? - Welche unbeabsichtigten Folgen kann eine Maßnahme besitzen? - Was geschieht vor und nach meinem eigenen Arbeitsschritt? - Wie wird das Ende-zu-Ende-Ergebnis geprüft? --- **Praxisbeispiel: Benutzeranmeldung funktioniert nicht** Mögliche technische Abhängigkeiten: - Endgerät, - Netzwerk, - DNS, - Zeitsynchronisation, - Verzeichnisdienst, - Identitätsanbieter, - Zertifikate, - Multi-Faktor-Authentifizierung, - Benutzerkonto, - Gruppenmitgliedschaften, - und Cloud-Dienste. Mögliche organisatorische Abhängigkeiten: - Berechtigungsfreigabe, - Eintritts- oder Austrittsprozess, - Sicherheitsrichtlinie, - Helpdesk-Arbeitsweise, - externer Provider, - und Zuständigkeit für Identitätsmanagement. Eine ausschließlich auf das Benutzerkennwort beschränkte Betrachtung kann deshalb zu kurz greifen. --- **Lokale Optimierung vermeiden** Ein einzelnes Team kann seine eigene Kennzahl verbessern und gleichzeitig den gesamten Wertstrom verschlechtern. Beispiel: Der Service Desk verkürzt seine durchschnittliche Bearbeitungszeit, indem komplexe Tickets möglichst schnell an andere Teams weitergegeben werden. Die lokale Kennzahl verbessert sich. Für den Benutzer können jedoch entstehen: - mehr Übergaben, - längere Gesamtdauer, - wiederholte Rückfragen, - widersprüchliche Informationen, - und geringere Zufriedenheit. > **Merke** > > Eine lokale Verbesserung ist nur dann hilfreich, wenn sie den gesamten Wertstrom und das benötigte Outcome unterstützt. --- **Bedeutung für technische Änderungen** Vor dem Austausch einer technischen Komponente sollte geprüft werden: - Welche Services verwenden sie? - Welche Schnittstellen bestehen? - Welche Überwachung ist betroffen? - Welche Backup- und Wiederherstellungsverfahren gelten? - Welche Dokumentationen müssen aktualisiert werden? - Welche Lieferanten sind beteiligt? - Welche Sicherheitskontrollen greifen? - Welche Benutzer müssen informiert werden? - Welche anderen Changes finden gleichzeitig statt? --- **6. Keep it simple and practical** > **Sinngemäße Bedeutung** > > Arbeitsweisen, Kontrollen und Lösungen sollen so einfach wie möglich und so umfangreich wie tatsächlich notwendig gestaltet werden. Einfach bedeutet nicht: - oberflächlich, - unkontrolliert, - unvollständig, - oder ohne Sicherheitsmaßnahmen. Einfach bedeutet: - verständlich, - zweckmäßig, - angemessen, - wartbar, - und frei von unnötiger Komplexität. Jeder zusätzliche Schritt, jedes Pflichtfeld und jede Genehmigung sollte einen nachvollziehbaren Zweck besitzen. --- **Leitfragen zu Keep it simple and practical** - Welchen Zweck erfüllt dieser Schritt? - Was würde geschehen, wenn er entfernt wird? - Welche Information wird tatsächlich benötigt? - Ist die Arbeitsweise für die Beteiligten verständlich? - Gibt es doppelte Erfassungen? - Sind alle Genehmigungen notwendig? - Kann eine Regel vereinheitlicht werden? - Ist die Lösung langfristig wartbar? - Passt der Aufwand zum Risiko? - Wird eine seltene Ausnahme unnötig zum Standard gemacht? --- **Praxisbeispiel: Change-Dokumentation** Für einen Change werden 35 Pflichtfelder verlangt. In der Praxis werden viele Felder: - mit bedeutungslosen Standardtexten, - mehrfach identischen Angaben, - oder unzutreffenden Platzhaltern gefüllt. Die umfangreiche Dokumentation erzeugt dadurch keine zusätzliche Sicherheit. Eine zweckmäßige Struktur könnte sich stattdessen auf tatsächlich notwendige Informationen konzentrieren: - Ziel und Begründung, - betroffene Produkte und Services, - technische Änderung, - Auswirkungen und Risiken, - Test, - Freigabe, - Umsetzungsplan, - Rückfallplan, - Kommunikation, - und Erfolgskontrolle. > **Typischer Fehler** > > Umfang wird mit Qualität verwechselt. > > Eine längere Arbeitsanweisung ist nicht automatisch verständlicher oder sicherer. --- **Angemessene Kontrolle statt identischer Kontrolle** Nicht jede Änderung besitzt dasselbe Risiko. Beispiele: | Änderung | Möglicher Kontrollumfang | |---|---| | dokumentierte, häufig ausgeführte Standardänderung | vereinfachter und vorab autorisierter Ablauf | | normale Änderung mit überschaubarem Risiko | angemessene Bewertung und Freigabe | | kritische Änderung an zentraler Infrastruktur | umfangreichere Prüfung, Abstimmung und Rückfallplanung | | dringende Änderung zur Behebung einer akuten Gefahr | beschleunigtes Verfahren mit nachträglicher Kontrolle | Die konkrete Organisation legt die Change-Modelle, Freigaben und Risikokriterien fest. > **Merke** > > Einfachheit entsteht nicht dadurch, notwendige Kontrollen wegzulassen. > > Sie entsteht durch passende Kontrollen ohne unnötige Schritte. --- **7. Optimize and automate** > **Sinngemäße Bedeutung** > > Arbeit soll zunächst verstanden und verbessert werden. Anschließend können geeignete Bestandteile automatisiert werden. Automatisierung kann unter anderem: - Bearbeitungszeiten verkürzen, - wiederkehrende Fehler reduzieren, - Ergebnisse vereinheitlichen, - Mitarbeiter entlasten, - Skalierbarkeit verbessern, - und Kontrollen nachvollziehbarer machen. Automatisierung kann jedoch auch: - Fehler schneller verbreiten, - intransparente Abhängigkeiten erzeugen, - Sicherheitsrisiken vergrößern, - Ausnahmen falsch behandeln, - oder eine ungeeignete Arbeitsweise dauerhaft festschreiben. > **Grundsatz** > > Nicht alles, was technisch automatisierbar ist, sollte automatisiert werden. --- **Leitfragen zu Optimize and automate** - Welches Outcome soll verbessert werden? - Ist die bestehende Arbeitsweise verstanden? - Welche Schritte erzeugen keinen erkennbaren Nutzen? - Welche Engpässe bestehen? - Ist der Ablauf ausreichend stabil und wiederholbar? - Welche Entscheidungen benötigen menschliches Urteilsvermögen? - Welche Ausnahmen existieren? - Wie werden Fehler erkannt und behandelt? - Wie wird die Automatisierung überwacht? - Gibt es eine manuelle Rückfallmöglichkeit? - Sind Sicherheit und Datenschutz berücksichtigt? - Ist der Nutzen größer als Aufbau und Wartungsaufwand? --- **Optimierung vor Automatisierung** Eine geeignete Reihenfolge ist: 1. Outcome und Zweck verstehen 2. aktuellen Ablauf erfassen 3. unnötige Schritte entfernen 4. Übergaben und Abhängigkeiten verbessern 5. Ablauf vereinheitlichen 6. geeignete Tätigkeiten automatisieren 7. Ergebnisse überwachen 8. Automatisierung fortlaufend verbessern > **Typischer Fehler** > > Ein fehlerhafter oder unnötig komplexer Ablauf wird unverändert automatisiert. > > Das Ergebnis ist ein schnellerer fehlerhafter Ablauf. --- **Praxisbeispiel: automatische Benutzeranlage** Geeignete Automatisierungen können sein: - Übernahme freigegebener Personaldaten, - Erstellung eines Benutzerkontos, - Zuweisung standardisierter Gruppen, - Vergabe vorgesehener Lizenzen, - Erstellung standardisierter Tickets, - Benachrichtigung zuständiger Teams, - und Aktualisierung von Asset- oder Konfigurationsinformationen. Nicht vollständig automatisiert werden sollten möglicherweise: - nicht standardisierte Berechtigungsentscheidungen, - sicherheitskritische Ausnahmen, - unklare oder widersprüchliche Anforderungen, - und Entscheidungen ohne verantwortlichen Genehmiger. Die Automatisierung muss zusätzlich kontrollieren: - ob alle notwendigen Daten vorhanden sind, - ob eine Freigabe vorliegt, - ob ein Konto bereits existiert, - ob ein Teilschritt fehlgeschlagen ist, - ob das Ergebnis vollständig war, - und wer bei Fehlern informiert wird. --- **Automatisierung und künstliche Intelligenz** ITIL Version 5 berücksichtigt digitale und KI-gestützte Arbeitsumgebungen stärker. Auch beim Einsatz von KI bleiben die Guiding Principles relevant. Vor einer KI-gestützten Automatisierung sollte unter anderem geprüft werden: - Welches Outcome soll verbessert werden? - Welche Daten werden verwendet? - Sind Ergebnisse nachvollziehbar? - Welche Fehler können entstehen? - Welche menschliche Kontrolle ist erforderlich? - Werden Datenschutz und Informationssicherheit eingehalten? - Kann eine Entscheidung angefochten oder korrigiert werden? - Wie werden Qualität und Verzerrungen überwacht? - Welche Verantwortung verbleibt bei Menschen? > **Sicherheitsrelevant** > > Eine automatisierte oder KI-generierte Entscheidung entbindet die Organisation nicht von Verantwortung, Kontrolle und Risikobewertung. --- **Zusammenspiel der sieben Guiding Principles** Die Prinzipien entfalten ihren größten Nutzen, wenn sie gemeinsam betrachtet werden. Beispiel: Ablösung eines alten Fileservers **Focus on value** - Welche Outcomes müssen erhalten oder verbessert werden? - Benötigen Benutzer weiterhin dieselben Zugriffsmöglichkeiten? **Start where you are** - Welche Daten, Berechtigungen und Abhängigkeiten bestehen? - Welche Teile der vorhandenen Lösung funktionieren zuverlässig? **Progress iteratively with feedback** - Kann zunächst eine begrenzte Benutzergruppe migriert werden? - Welche Rückmeldungen liefert der Pilot? **Collaborate and promote visibility** - Welche Fachabteilungen, Administratoren und Sicherheitsverantwortlichen müssen beteiligt werden? - Wo wird der Migrationsstatus dokumentiert? **Think and work holistically** - Sind Anwendungen, Backups, Berechtigungen, Netzlaufwerke, Skripte und Schnittstellen berücksichtigt? **Keep it simple and practical** - Welche alte Verzeichnisstruktur oder Sonderberechtigung wird nicht mehr benötigt? - Kann die Zielstruktur vereinfacht werden? **Optimize and automate** - Können Datenübertragung, Berechtigungsprüfung und Erfolgskontrolle automatisiert werden? --- **Mögliche Spannungen zwischen den Prinzipien** Die Guiding Principles liefern nicht immer automatisch dieselbe Handlungsrichtung. Beispiele: | Mögliche Spannung | Notwendige Abwägung | |---|---| | schnell iterieren oder ganzheitlich analysieren | ausreichend prüfen, ohne jede denkbare Frage vor dem ersten Schritt lösen zu wollen | | einfach halten oder zusätzliche Kontrollen einführen | Kontrollaufwand am tatsächlichen Risiko ausrichten | | Zusammenarbeit fördern oder schnell entscheiden | notwendige Beteiligte einbeziehen, aber Verantwortung eindeutig lassen | | automatisieren oder flexibel bleiben | nur stabile und ausreichend verstandene Teile automatisieren | | Bestehendes nutzen oder neu aufbauen | Nutzen, technische Schulden, Risiken und Migrationsaufwand vergleichen | | kurzfristigen Wert oder langfristige Nachhaltigkeit priorisieren | unmittelbare Outcomes und langfristige Folgen gemeinsam bewerten | > **Merke** > > Die Guiding Principles ersetzen keine fachliche Abwägung. > > Sie verbessern die Qualität der Fragen, auf deren Grundlage entschieden wird. --- **Guiding Principles bei einem Incident** Auch bei einer laufenden Störung können die Prinzipien helfen. | Guiding Principle | Anwendung im Incident | |---|---| | **Focus on value** | zuerst die für Benutzer wichtigste Servicefunktion wiederherstellen | | **Start where you are** | vorhandene Monitoring-Daten, bekannte Fehler und letzte Changes prüfen | | **Progress iteratively with feedback** | Maßnahmen kontrolliert durchführen und Ergebnis nach jedem Schritt prüfen | | **Collaborate and promote visibility** | zuständige Teams einbinden und aktuellen Status sichtbar halten | | **Think and work holistically** | Serviceabhängigkeiten und mögliche Folgeauswirkungen berücksichtigen | | **Keep it simple and practical** | zunächst die sicherste geeignete Wiederherstellung wählen | | **Optimize and automate** | nach dem Incident wiederkehrende Diagnose- oder Wiederherstellungsschritte verbessern | Während eines kritischen Incidents steht zunächst die sichere und angemessene Wiederherstellung im Vordergrund. Die umfassende Ursachenanalyse und nachhaltige Verbesserung können anschließend folgen. --- **Guiding Principles bei einem Change** | Guiding Principle | Anwendung beim Change | |---|---| | **Focus on value** | Zweck, Outcome und Nutzen des Changes klären | | **Start where you are** | aktuellen Zustand und vorhandene Konfiguration erfassen | | **Progress iteratively with feedback** | Test, Pilot oder schrittweise Einführung verwenden | | **Collaborate and promote visibility** | Betroffene, Verantwortliche und Abhängigkeiten sichtbar machen | | **Think and work holistically** | Auswirkungen auf Produkte, Services, Sicherheit und Lieferanten betrachten | | **Keep it simple and practical** | angemessenen Kontrollumfang wählen | | **Optimize and automate** | standardisierbare Prüfung und Umsetzung verbessern | --- **Bedeutung für Fachinformatiker für Systemintegration** Die Guiding Principles helfen bei technischen und organisatorischen Entscheidungen. Beispiele: - Soll ein Server repariert, aktualisiert oder ersetzt werden? - Muss eine technische Lösung vollständig neu aufgebaut werden? - Welche Benutzer müssen vor einer Änderung beteiligt werden? - Kann eine Migration schrittweise erfolgen? - Welche Informationen müssen im Ticket sichtbar sein? - Ist eine Arbeitsanweisung unnötig kompliziert? - Welche wiederkehrenden Tätigkeiten können automatisiert werden? - Unterstützt die technische Maßnahme tatsächlich das erwartete Outcome? Ein Fachinformatiker muss die englischen Bezeichnungen nicht in jedem Ticket dokumentieren. Die zugrunde liegenden Fragen sollten jedoch Teil der professionellen Arbeitsweise werden. --- **Entscheidungshilfe für neue Aufgaben** Bei einer neuen Aufgabe kannst du die sieben Prinzipien als Kurzprüfung verwenden: 1. **Wert:** Welches Outcome soll erreicht werden? 2. **Ausgangslage:** Was ist bereits vorhanden und funktionsfähig? 3. **Schritte:** Kann kontrolliert und iterativ vorgegangen werden? 4. **Zusammenarbeit:** Wer muss beteiligt und informiert werden? 5. **Gesamtsicht:** Welche Abhängigkeiten und Auswirkungen bestehen? 6. **Einfachheit:** Welche Schritte sind tatsächlich erforderlich? 7. **Optimierung:** Was kann verbessert und anschließend automatisiert werden? --- **Checkliste zur Anwendung der Guiding Principles** - [ ] Ist das gewünschte Outcome eindeutig? - [ ] Sind die relevanten Stakeholder bekannt? - [ ] Wurde der aktuelle Zustand überprüft? - [ ] Wurden vorhandene Fähigkeiten und Informationen berücksichtigt? - [ ] Kann die Aufgabe in sinnvolle Schritte aufgeteilt werden? - [ ] Ist festgelegt, wie Feedback erhoben wird? - [ ] Sind die richtigen Personen und Teams beteiligt? - [ ] Sind Status, Risiken und Entscheidungen ausreichend sichtbar? - [ ] Wurden Produkte, Services und Abhängigkeiten ganzheitlich betrachtet? - [ ] Besitzt jeder Arbeitsschritt einen nachvollziehbaren Zweck? - [ ] Passt der Kontrollaufwand zum tatsächlichen Risiko? - [ ] Wurde die Arbeitsweise vor einer Automatisierung optimiert? - [ ] Werden automatisierte Ergebnisse überwacht? - [ ] Wurden mögliche Zielkonflikte zwischen den Prinzipien bewertet? - [ ] Wird der tatsächliche Wert nach Abschluss überprüft? --- **Typische Fehlanwendungen** **Nur ein Prinzip verwenden** Ein Team beruft sich ausschließlich auf **Keep it simple and practical**, um notwendige Sicherheitskontrollen wegzulassen. Richtig wäre, zusätzlich: - Wert, - Risiken, - Governance, - Gesamtauswirkungen, - und betroffene Stakeholder zu berücksichtigen. --- **Start where you are mit Stillstand verwechseln** Der aktuelle Zustand wird nicht verbessert, weil er bereits lange besteht. Das Prinzip verlangt jedoch eine Bestandsaufnahme, keine unveränderte Fortführung. --- **Iterationen ohne klares Ziel durchführen** Es werden regelmäßig kleine Änderungen vorgenommen, aber weder Outcome noch Erfolgskriterien sind definiert. Iteration benötigt Ziel, Feedback und Auswertung. --- **Sichtbarkeit mit Informationsüberlastung verwechseln** Alle Beteiligten erhalten jede technische Einzelmeldung. Dadurch gehen relevante Informationen in der Menge unter. Sichtbarkeit muss zielgruppengerecht und handlungsorientiert sein. --- **Ganzheitliche Betrachtung als endlose Analyse verwenden** Eine Organisation untersucht jede denkbare Auswirkung und beginnt deshalb nie mit der Umsetzung. Ganzheitlich denken schließt ein iteratives und pragmatisches Vorgehen nicht aus. --- **Einfachheit mit fehlender Sorgfalt verwechseln** Dokumentation, Tests oder Rückfallplanung werden weggelassen. Einfachheit darf notwendige Sicherheit und Nachvollziehbarkeit nicht beseitigen. --- **Automatisierung als Selbstzweck betrachten** Eine Tätigkeit wird automatisiert, weil die technische Möglichkeit besteht. Der tatsächliche Nutzen, die Wartung und mögliche Risiken werden nicht bewertet. --- **Schnellreferenz** | Principle | Kurzfrage | |---|---| | **Focus on value** | Welchen Wert und welches Outcome ermöglicht die Tätigkeit? | | **Start where you are** | Was ist bereits vorhanden und funktioniert? | | **Progress iteratively with feedback** | Was ist der nächste kontrollierbare Schritt? | | **Collaborate and promote visibility** | Wer muss beteiligt sein und was muss sichtbar werden? | | **Think and work holistically** | Welche Zusammenhänge und Abhängigkeiten bestehen? | | **Keep it simple and practical** | Was ist tatsächlich notwendig? | | **Optimize and automate** | Was kann zuerst verbessert und danach automatisiert werden? | --- **Zusammenfassende Darstellung** > **Focus on value** > Ziel und Outcome verstehen > ↓ > **Start where you are** > tatsächlichen Ausgangszustand prüfen > ↓ > **Progress iteratively with feedback** > kontrolliert vorgehen und lernen > ↓ > **Collaborate and promote visibility** > geeignete Beteiligte und Informationen verbinden > ↓ > **Think and work holistically** > das gesamte System berücksichtigen > ↓ > **Keep it simple and practical** > unnötige Komplexität vermeiden > ↓ > **Optimize and automate** > verbessern, automatisieren und überwachen Diese Darstellung dient nur als Lernhilfe. Die Guiding Principles bilden keine verbindliche Reihenfolge und können gleichzeitig angewendet werden. --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.2 Das ITIL Value System - 2.4 Governance und Verantwortlichkeit - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 2.10 ITIL an den eigenen Kontext anpassen --- **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) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) - [ITIL: New ITIL Explained for Certified Professionals](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-explained) - [PeopleCert: ITIL 4 Foundation](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565) - [ITIL: AI-Enabled Service Management](https://www.itil.com/organizations/ai-native) **Einordnung** Die offiziellen ITIL-Version-5-Übersichten bestätigen, dass die Guiding Principles weiterhin ein Kernelement des ITIL Value Systems und der praktischen Entscheidungsfindung sind. Die sieben Guiding Principles werden aus ITIL 4 fortgeführt: - Focus on value - Start where you are - Progress iteratively with feedback - Collaborate and promote visibility - Think and work holistically - Keep it simple and practical - Optimize and automate Die deutschen Erklärungen, Leitfragen, Praxisbeispiele, Tabellen und Checklisten auf dieser Seite sind eigene sinngemäße Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.4 Governance und Verantwortlichkeit > **Kurz erklärt** > > Governance beschreibt, wie eine Organisation gelenkt und kontrolliert wird. > > Sie sorgt dafür, dass: > > - Ziele und Prioritäten festgelegt werden, > - Entscheidungen innerhalb klarer Rahmenbedingungen getroffen werden, > - Verantwortlichkeiten eindeutig sind, > - Risiken angemessen behandelt werden, > - verbindliche Vorgaben eingehalten werden, > - und die tatsächlichen Ergebnisse überwacht werden. > > Im ITIL Value System wird Governance durch drei grundlegende Aktivitäten verwirklicht: > > 1. **Evaluate** – bewerten > 2. **Direct** – Richtung vorgeben > 3. **Monitor** – überwachen --- **Warum Governance notwendig ist** Digitale Produkte und Services beeinflussen heute häufig: - Geschäftsprozesse, - Kommunikation, - Kundenerfahrung, - Informationssicherheit, - Datenschutz, - Finanzen, - Produktion, - Lieferketten, - und die Arbeitsfähigkeit von Mitarbeitern. Technische Entscheidungen können deshalb weitreichende organisatorische Folgen besitzen. Beispiele: - Eine Firewall-Regel beeinflusst die Sicherheit und Erreichbarkeit eines Service. - Eine neue Cloud-Anwendung kann personenbezogene Daten verarbeiten. - Eine Änderung am Verzeichnisdienst kann viele Benutzer und Anwendungen betreffen. - Eine nicht getestete Wiederherstellung kann im Notfall zu langen Ausfallzeiten führen. - Eine KI-gestützte Entscheidung kann falsche oder nicht nachvollziehbare Ergebnisse erzeugen. - Ein externer Dienstleister kann eine kritische Abhängigkeit für mehrere Services darstellen. Ohne klare Governance können unter anderem folgende Probleme entstehen: - Entscheidungen werden ohne ausreichende Befugnis getroffen. - Verantwortlichkeiten sind unklar. - Risiken werden uneinheitlich bewertet. - Teams verfolgen widersprüchliche Ziele. - verbindliche Vorgaben werden übersehen. - technische Maßnahmen unterstützen nicht die Ziele der Organisation. - Leistung wird gemessen, aber nicht wirksam bewertet. - bekannte Probleme bleiben ohne Konsequenz. - externe Dienstleister werden nicht ausreichend kontrolliert. - niemand trägt erkennbar Verantwortung für das Gesamtergebnis. > **Merke** > > Governance soll nicht jede technische Einzelentscheidung zentralisieren. > > Sie schafft den Rahmen, innerhalb dessen angemessene Entscheidungen getroffen und kontrolliert werden können. --- **Governance im ITIL Value System** Governance ist einer der fünf Bestandteile des ITIL Value Systems. Das Value System verbindet: - Guiding Principles, - Governance, - Value Chain Activities, - Management Practices, - und Continual Improvement. Governance stellt dabei sicher, dass die Tätigkeiten der Organisation: - an ihren Zielen ausgerichtet sind, - innerhalb akzeptierter Grenzen stattfinden, - nachvollziehbar entschieden werden, - und hinsichtlich Leistung, Risiken und Regelkonformität überwacht werden. Governance wirkt damit auf: - digitale Produkte, - Services, - Practices, - Wertströme, - Projekte, - technische Änderungen, - Lieferantenbeziehungen, - Investitionen, - Informationssicherheit, - und Verbesserungsinitiativen. > **Wichtig** > > Governance ist kein einzelner Prozess und keine einzelne Management Practice. > > Sie ist ein übergreifender Bestandteil des gesamten ITIL Value Systems. --- **Die drei Governance-Aktivitäten** Governance wird durch drei grundlegende Aktivitäten verwirklicht: | Aktivität | Bedeutung | Zentrale Frage | |---|---|---| | **Evaluate** | Bedürfnisse, Optionen, Leistung, Risiken und Rahmenbedingungen bewerten | Was ist notwendig und welche Entscheidung ist angemessen? | | **Direct** | Richtung, Prioritäten, Grundsätze und Entscheidungsrahmen vorgeben | Was soll erreicht werden und innerhalb welcher Grenzen? | | **Monitor** | Leistung, Ergebnisse, Risiken und Einhaltung überwachen | Erreichen wir die Ziele und werden die Vorgaben eingehalten? | Diese Aktivitäten sind miteinander verbunden. Die Ergebnisse des Monitorings können eine erneute Bewertung auslösen. Aus einer neuen Bewertung können wiederum geänderte Vorgaben oder Prioritäten entstehen. > **Vereinfachter Kreislauf** > > Evaluate > ↓ > Direct > ↓ > Monitor > ↓ > neue Erkenntnisse > ↓ > erneut Evaluate --- **Evaluate – bewerten** Bei **Evaluate** werden die aktuelle Situation, Bedürfnisse, Möglichkeiten und Risiken untersucht. Mögliche Bewertungsgegenstände sind: - Anforderungen von Kunden und Benutzern, - Ziele der Organisation, - gesetzliche Verpflichtungen, - vertragliche Anforderungen, - technische Möglichkeiten, - bestehende Fähigkeiten, - Kosten, - Risiken, - Sicherheitsanforderungen, - Nachhaltigkeitsaspekte, - Erfahrungen der Stakeholder, - und erwartete Outcomes. Beispiel: Eine Organisation prüft, ob eine zentrale Cloud-Plattform eingeführt werden soll. Bei der Bewertung können unter anderem folgende Fragen relevant sein: - Welches Problem soll gelöst werden? - Welche Outcomes werden erwartet? - Welche Daten werden verarbeitet? - Welche Sicherheits- und Datenschutzanforderungen gelten? - Welche Kosten entstehen? - Welche Lieferantenabhängigkeiten entstehen? - Welche vorhandenen Systeme müssen integriert werden? - Welche Risiken entstehen bei einem Ausfall? - Welche Fähigkeiten werden intern benötigt? - Welche Alternativen bestehen? - Wie kann die Lösung später wieder abgelöst werden? > **Typischer Fehler** > > Eine Entscheidung wird ausschließlich anhand des Anschaffungspreises oder einzelner technischer Funktionen bewertet. > > Betrieb, Support, Integration, Sicherheit, Abhängigkeiten und spätere Ablösung werden nicht berücksichtigt. --- **Evaluate bedeutet nicht nur einmalig prüfen** Bewertung findet nicht ausschließlich vor einer Einführung statt. Eine erneute Bewertung kann notwendig sein, wenn: - sich Geschäftsziele ändern, - neue gesetzliche Anforderungen entstehen, - ein Sicherheitsvorfall auftritt, - ein Lieferant seine Leistung verändert, - neue Technologien verfügbar werden, - Benutzerfeedback auf Probleme hinweist, - Kosten deutlich steigen, - Risiken anders eingeschätzt werden, - oder ein Service seine Ziele nicht mehr erreicht. Beispiel: Eine Anwendung wurde ursprünglich nur für eine kleine interne Abteilung eingeführt. Später wird sie für einen unternehmenskritischen Prozess eingesetzt. Dadurch können sich ändern: - Verfügbarkeitsanforderungen, - Sicherheitsanforderungen, - Supportzeiten, - Wiederherstellungsziele, - Überwachung, - Dokumentation, - und notwendige Lieferantenvereinbarungen. Die ursprüngliche Bewertung reicht dann möglicherweise nicht mehr aus. --- **Direct – Richtung vorgeben** Bei **Direct** werden Richtung, Prioritäten und Rahmenbedingungen vorgegeben. Dies kann beispielsweise erfolgen durch: - Strategien, - Grundsätze, - Richtlinien, - Ziele, - Prioritäten, - Entscheidungsbefugnisse, - Risikogrenzen, - Rollen, - Vorgaben für Kontrollen, - und zu erreichende Ergebnisse. Beispiele: - Administrative Zugriffe müssen durch Multi-Faktor-Authentifizierung geschützt werden. - Kritische Services müssen dokumentierte Wiederherstellungsverfahren besitzen. - Produktive Änderungen benötigen eine dem Risiko angemessene Autorisierung. - Personenbezogene Daten dürfen nur in freigegebenen Systemen verarbeitet werden. - Für kritische Lieferanten müssen Ausweich- oder Beendigungsstrategien betrachtet werden. - Sicherheitsrelevante Ereignisse müssen nach dem festgelegten Verfahren gemeldet werden. - Wiederherstellungsverfahren müssen in festgelegten Abständen getestet werden. Governance gibt dabei normalerweise nicht jeden technischen Einzelschritt vor. Beispiel: Governance kann festlegen: > Administrative Zugriffe müssen mit einer starken Mehrfaktor-Authentifizierung geschützt werden. Das zuständige Management und die Fachteams bestimmen anschließend: - welche technische Lösung verwendet wird, - wie sie eingeführt wird, - welche Ausnahmen zulässig sind, - wie Benutzer unterstützt werden, - und wie die Wirksamkeit kontrolliert wird. --- **Richtung und Grenzen** Eine gute Governance-Vorgabe beantwortet möglichst: - Welches Ziel wird verfolgt? - Für welchen Bereich gilt die Vorgabe? - Wer trägt Verantwortung? - Welche Grenzen müssen eingehalten werden? - Welche Ausnahmen sind möglich? - Wer darf Ausnahmen genehmigen? - Wie wird die Einhaltung geprüft? - Was geschieht bei Abweichungen? - Wann wird die Vorgabe erneut bewertet? Unklare Vorgabe: > Systeme müssen sicher sein. Präzisere Vorgabe: > Kritische Systeme müssen entsprechend der festgelegten Schutzbedarfs- und Risikobewertung abgesichert, überwacht und regelmäßig auf die Wirksamkeit ihrer Kontrollen geprüft werden. Die konkrete technische Umsetzung wird anschließend durch zuständige Fachkräfte und Management Practices gestaltet. --- **Monitor – überwachen** Bei **Monitor** wird geprüft, ob: - die vorgegebene Richtung eingehalten wird, - Ziele erreicht werden, - Risiken innerhalb akzeptierter Grenzen bleiben, - Kontrollen wirksam sind, - Verantwortlichkeiten wahrgenommen werden, - und Produkte sowie Services die erwarteten Outcomes unterstützen. Monitoring im Governance-Kontext bedeutet mehr als technische Überwachung. Es kann unter anderem umfassen: - Serviceleistung, - Benutzer- und Kundenerfahrung, - Sicherheitsrisiken, - Einhaltung von Richtlinien, - Kostenentwicklung, - Lieferantenleistung, - Fortschritt strategischer Vorhaben, - Ergebnisse von Audits, - Status kritischer Verbesserungen, - Wiederherstellbarkeit, - und Wirksamkeit organisatorischer Kontrollen. Beispiel: Eine Organisation verlangt regelmäßige Wiederherstellungstests. Governance-Monitoring prüft nicht nur, ob ein Testtermin im Kalender stand. Es prüft beispielsweise: - Wurde der Test tatsächlich durchgeführt? - Welche Systeme wurden getestet? - War die Wiederherstellung erfolgreich? - Wurden die vereinbarten Wiederherstellungsziele erreicht? - Welche Probleme wurden erkannt? - Wurden notwendige Verbesserungen umgesetzt? - Bestehen weiterhin nicht akzeptierte Risiken? > **Merke** > > Aktivität ist nicht automatisch Wirksamkeit. > > Ein ausgefülltes Kontrollformular beweist noch nicht, dass das gewünschte Ergebnis erreicht wurde. --- **Governance und Management unterscheiden** Governance und Management sind eng miteinander verbunden, aber nicht identisch. | Governance | Management | |---|---| | bewertet Bedürfnisse, Erwartungen und Rahmenbedingungen | plant und organisiert die praktische Umsetzung | | gibt Richtung und Grenzen vor | weist Ressourcen und Aufgaben zu | | legt Verantwortlichkeit und Entscheidungsbefugnisse fest | koordiniert Teams, Practices und Arbeitsabläufe | | überwacht Outcomes, Risiken und Regelkonformität | überwacht die laufende Ausführung | | entscheidet über grundlegende Prioritäten | trifft operative und taktische Entscheidungen innerhalb des Rahmens | | stellt Rechenschaftspflicht sicher | liefert Ergebnisse und berichtet darüber | Vereinfacht: > **Governance** > > Bestimmt, was erreicht und kontrolliert werden muss. > > **Management** > > Organisiert, wie dies innerhalb des vorgegebenen Rahmens umgesetzt wird. Diese Trennung bedeutet nicht, dass Governance nur die Unternehmensleitung betrifft. Auch nachgelagerte Gremien oder Rollen können delegierte Governance-Aufgaben wahrnehmen. Die grundlegende Rechenschaftspflicht muss jedoch eindeutig bleiben. --- **Beispiel: Einführung von Multi-Faktor-Authentifizierung** **Governance** - bewertet Sicherheitsrisiken und rechtliche Anforderungen - gibt das Ziel einer starken Authentifizierung vor - legt Geltungsbereich und zulässige Ausnahmen fest - bestimmt Verantwortlichkeit - fordert Wirksamkeitsnachweise - überwacht Risiken und Einhaltung **Management** - plant die Einführung - wählt geeignete Produkte und Verfahren - organisiert Ressourcen - legt Zeitplan und Pilotgruppen fest - koordiniert Kommunikation und Support - behandelt technische Probleme - berichtet über Fortschritt und Ergebnisse **Technische Umsetzung** - Identitätsanbieter konfigurieren - Authentifizierungsmethoden einrichten - Richtlinien anwenden - Benutzer registrieren - Protokollierung aktivieren - Notfallzugänge absichern - Funktion und Rückfallmöglichkeiten testen Alle drei Ebenen sind notwendig. Eine technisch erfolgreiche Konfiguration allein beweist noch nicht, dass: - der vollständige Geltungsbereich geschützt ist, - Ausnahmen kontrolliert werden, - Benutzer unterstützt werden, - oder die Sicherheitsziele tatsächlich erreicht werden. --- **Verantwortung und Verantwortlichkeit** Im Deutschen wird der Begriff **Verantwortung** häufig für unterschiedliche Sachverhalte verwendet. Für eine klare Rollenverteilung ist die Unterscheidung hilfreich zwischen: | Begriff | Bedeutung | |---|---| | **Ausführungsverantwortung** | eine Person oder Rolle führt eine Aufgabe aus | | **Entscheidungsverantwortung** | eine Person oder Rolle besitzt die Befugnis, eine Entscheidung zu treffen | | **Ergebnisverantwortung** | eine Person oder Rolle steht für das erreichte Ergebnis ein | | **Rechenschaftspflicht** | eine Person oder ein Gremium muss Entscheidungen und Ergebnisse erklären und vertreten | | **Beratung** | Fachwissen wird eingebracht, ohne selbst die endgültige Entscheidung zu treffen | | **Informationsbedarf** | eine Person oder Rolle muss über Entscheidung oder Ergebnis informiert werden | Eine Person kann eine Aufgabe ausführen, ohne die endgültige Entscheidungs- oder Ergebnisverantwortung zu besitzen. Beispiel: Ein Systemadministrator setzt eine freigegebene Firewall-Regel um. - Der Administrator ist für die korrekte technische Ausführung verantwortlich. - Eine andere Rolle kann für die fachliche Anforderung verantwortlich sein. - Eine Sicherheitsrolle kann die Risikobewertung durchführen. - Eine autorisierte Rolle kann die Änderung genehmigen. - Ein Service Owner kann für die Auswirkungen auf den Service rechenschaftspflichtig sein. > **Typischer Fehler** > > Die Person, die eine technische Änderung ausführt, wird automatisch für sämtliche geschäftlichen, rechtlichen und organisatorischen Entscheidungen verantwortlich gemacht. --- **Verantwortung muss eindeutig sein** Bei wichtigen Produkten, Services und Entscheidungen sollte erkennbar sein: - Wer besitzt die Entscheidungsbefugnis? - Wer führt die Aufgabe aus? - Wer prüft das Ergebnis? - Wer akzeptiert verbleibende Risiken? - Wer kommuniziert mit betroffenen Stakeholdern? - Wer aktualisiert die Dokumentation? - Wer überwacht die langfristige Wirksamkeit? - Wer eskaliert bei Abweichungen? Unklare Verantwortung kann zu folgenden Situationen führen: - Jeder geht davon aus, dass ein anderer handelt. - Entscheidungen werden mehrfach oder widersprüchlich getroffen. - Risiken werden ohne erkennbare Autorisierung akzeptiert. - Probleme werden zwischen Teams weitergereicht. - Dokumentationen bleiben veraltet. - notwendige Eskalationen erfolgen zu spät. - niemand überprüft das Ende-zu-Ende-Ergebnis. > **Praxistipp** > > Kann bei einer kritischen Aufgabe niemand eindeutig benennen, wer entscheidet und wer für das Ergebnis einsteht, besteht ein Governance- und Verantwortlichkeitsproblem. --- **Delegation und Rechenschaftspflicht** Aufgaben und Entscheidungsbefugnisse können delegiert werden. Eine sinnvolle Delegation benötigt: - einen klaren Umfang, - bekannte Grenzen, - ausreichende Fachkenntnisse, - benötigte Ressourcen, - Zugang zu relevanten Informationen, - definierte Eskalationswege, - und eine geeignete Kontrolle. Beispiel: Ein Betriebsteam darf bestimmte dokumentierte Standardänderungen selbstständig durchführen. Die Delegation kann festlegen: - welche Änderungen umfasst sind, - welche Voraussetzungen gelten, - wann keine zusätzliche Genehmigung notwendig ist, - welche Dokumentation erforderlich ist, - wann eskaliert werden muss, - und wie die Ergebnisse überwacht werden. > **Wichtig** > > Delegation bedeutet nicht, dass keine Kontrolle mehr erforderlich ist. > > Sie soll Entscheidungen dort ermöglichen, wo ausreichendes Wissen vorhanden ist und das Risiko angemessen beherrscht werden kann. --- **Entscheidungsbefugnisse** Entscheidungsbefugnisse sollten zum Risiko und zur Bedeutung einer Entscheidung passen. Mögliche Entscheidungsbereiche sind: - Investitionen, - Produkt- und Serviceprioritäten, - Sicherheitsausnahmen, - Change-Autorisierung, - Risikoakzeptanz, - Lieferantenauswahl, - Datenverarbeitung, - Notfallmaßnahmen, - und Außerbetriebnahme von Systemen. Eine Entscheidungsbefugnis sollte möglichst beantworten: - Wer darf entscheiden? - Für welchen Umfang? - Bis zu welcher Risikogrenze? - Welche Informationen werden benötigt? - Welche Beratung ist erforderlich? - Welche Entscheidung muss dokumentiert werden? - Wann ist eine höhere Instanz einzubeziehen? Beispiel: Ein Administrator darf einen abgestürzten Dienst nach einer dokumentierten Arbeitsanweisung neu starten. Er darf möglicherweise nicht ohne zusätzliche Autorisierung: - die gesamte Serverplattform neu konfigurieren, - Sicherheitskontrollen deaktivieren, - Daten löschen, - oder einen nicht getesteten Change an einem kritischen Produktivsystem durchführen. --- **Autorisierung nach Risiko und Kontext** Nicht jede Entscheidung benötigt denselben Freigabeumfang. | Situation | Mögliche Behandlung | |---|---| | häufige, dokumentierte und risikoarme Standardtätigkeit | delegierte oder vorab autorisierte Ausführung | | normale Änderung mit überschaubarem Risiko | Bewertung und Autorisierung durch zuständige Rolle | | komplexe Änderung an kritischem Service | erweiterte fachliche, technische und geschäftliche Bewertung | | dringende Sicherheitsmaßnahme | beschleunigtes Verfahren mit klarer Befugnis und nachträglicher Kontrolle | | grundlegende strategische Änderung | Entscheidung durch entsprechend befugtes Governance-Gremium | Die konkrete Organisation legt fest: - welche Entscheidungsmodelle verwendet werden, - welche Risikokriterien gelten, - wer autorisieren darf, - und welche Nachweise erforderlich sind. > **Typischer Fehler** > > Jede Änderung muss dieselben umfangreichen Genehmigungsstufen durchlaufen. > > Dadurch werden risikoarme Tätigkeiten unnötig verzögert, während kritische Entscheidungen möglicherweise trotzdem nicht ausreichend fachlich bewertet werden. --- **Governance ist mehr als Genehmigung** Governance wird häufig fälschlich auf Freigaben reduziert. Eine Freigabe beantwortet lediglich eine begrenzte Frage: > Darf diese konkrete Handlung innerhalb des festgelegten Rahmens durchgeführt werden? Governance umfasst zusätzlich: - Ziele, - Strategien, - Verantwortung, - Risikogrenzen, - Leistung, - Regelkonformität, - Erfahrung, - Nachhaltigkeit, - und fortlaufende Kontrolle. Ein Change kann formal genehmigt sein und dennoch schlecht gesteuert werden, wenn: - das Ziel unklar ist, - Auswirkungen nicht verstanden wurden, - das Ergebnis nicht geprüft wird, - Verantwortlichkeiten fehlen, - oder wiederholt dieselben Probleme entstehen. --- **Richtlinien, Standards und Arbeitsanweisungen unterscheiden** Governance-Vorgaben können auf unterschiedlichen Ebenen konkretisiert werden. | Dokumentenart | Zweck | Beispiel | |---|---|---| | **Grundsatz oder Policy** | legt Ziel, Richtung und verbindliche Erwartungen fest | administrative Zugriffe müssen angemessen geschützt werden | | **Standard** | legt verbindliche einheitliche Anforderungen fest | zugelassene MFA-Verfahren und Mindestanforderungen | | **Prozess oder Ablauf** | beschreibt zusammenhängende Aktivitäten und Verantwortlichkeiten | Beantragung und Freigabe eines administrativen Zugriffs | | **Verfahren** | beschreibt eine festgelegte Vorgehensweise | Registrierung eines neuen MFA-Geräts | | **Arbeitsanweisung** | beschreibt konkrete Ausführungsschritte | Menü- und Konfigurationsschritte im Identitätssystem | | **Checkliste** | unterstützt die Kontrolle wichtiger Punkte | Prüfung eines neuen administrativen Kontos | Nicht jede Organisation verwendet exakt diese Bezeichnungen. Entscheidend ist, dass: - Geltungsbereich, - Verbindlichkeit, - Verantwortlichkeit, - und erforderliche Handlung eindeutig sind. --- **Beispiel: Backup-Governance** **Governance-Vorgabe** > Geschäftskritische Daten und Systeme müssen entsprechend ihrer Kritikalität gesichert und innerhalb definierter Ziele wiederhergestellt werden können. **Mögliche Standards** - zulässige Sicherungsziele - Verschlüsselungsanforderungen - Aufbewahrungszeiten - Trennung von Produktiv- und Sicherungszugängen - Anforderungen an unveränderbare Sicherungen - Häufigkeit von Wiederherstellungstests **Management** - plant Backup-Infrastruktur - weist Verantwortlichkeiten zu - organisiert Lizenzen und Speicher - koordiniert Tests - bewertet Kapazität und Kosten - berichtet über Abweichungen **Technische Umsetzung** - Backup-Jobs konfigurieren - Zugangsdaten absichern - Zeitpläne einrichten - Warnungen konfigurieren - Wiederherstellungen testen - Ergebnisse dokumentieren **Governance-Monitoring** - Sind alle kritischen Systeme erfasst? - Sind Wiederherstellungen erfolgreich? - Werden Zielzeiten erreicht? - Werden Fehler zeitnah behandelt? - Sind verbleibende Risiken akzeptiert? - Werden Verbesserungen umgesetzt? --- **Risikobereitschaft und Risikotoleranz** Governance legt fest, welche Risiken: - akzeptiert, - reduziert, - übertragen, - vermieden, - oder weiter beobachtet werden. Die Organisation kann dafür Risikogrenzen definieren. Beispiele: - maximal tolerierbare Ausfallzeit - maximal akzeptabler Datenverlust - zulässige Lieferantenabhängigkeit - notwendiger Freigabeumfang - erforderliche Sicherheitskontrollen - maximale finanzielle Auswirkung - zulässige Restunsicherheit bei einer Einführung Ein technisches Team sollte verbleibende erhebliche Risiken nicht ohne entsprechende Befugnis selbst akzeptieren. Beispiel: Ein Administrator stellt fest, dass ein veraltetes System keine Sicherheitsupdates mehr erhält. Er kann: - die technische Situation dokumentieren, - mögliche Maßnahmen vorschlagen, - Auswirkungen bewerten, - kurzfristige Schutzmaßnahmen umsetzen, - und das Risiko eskalieren. Die Entscheidung, ein erhebliches Restrisiko langfristig zu akzeptieren, benötigt eine entsprechend befugte Rolle. > **Merke** > > Risikoanalyse kann durch Fachkräfte erfolgen. > > Risikoakzeptanz muss durch eine dafür autorisierte Stelle erfolgen. --- **Kontrollen** Eine Kontrolle soll ein Risiko reduzieren, eine Vorgabe sicherstellen oder eine Abweichung erkennbar machen. Kontrollen können sein: - vorbeugend, - erkennend, - korrigierend, - manuell, - technisch automatisiert, - organisatorisch, - oder eine Kombination daraus. | Kontrollart | Beispiel | |---|---| | **Vorbeugend** | MFA verhindert Anmeldung nur mit Kennwort | | **Erkennend** | Monitoring erkennt abgelaufenes Zertifikat | | **Korrigierend** | dokumentiertes Wiederherstellungsverfahren | | **Manuell** | Vier-Augen-Prüfung einer kritischen Änderung | | **Automatisiert** | Richtlinie blockiert unsichere Konfiguration | | **Organisatorisch** | Funktionstrennung zwischen Beantragung und Genehmigung | Eine Kontrolle sollte hinsichtlich ihrer Wirksamkeit bewertet werden. Fragen dazu: - Welches Risiko behandelt die Kontrolle? - Ist sie vollständig umgesetzt? - Kann sie umgangen werden? - Erzeugt sie neue Risiken? - Wird ihre Funktion regelmäßig geprüft? - Ist der Aufwand angemessen? - Gibt es Ausnahmen? - Werden Abweichungen verfolgt? --- **Messgrößen und Governance** Governance benötigt Informationen, um Leistung und Risiken bewerten zu können. Kennzahlen sollten jedoch nicht isoliert betrachtet werden. Beispiel: > 98 Prozent aller Tickets wurden innerhalb der Zielzeit geschlossen. Diese Zahl beantwortet nicht automatisch: - Waren die Lösungen nachhaltig? - Wurden Tickets voreilig geschlossen? - Mussten Benutzer erneut Kontakt aufnehmen? - Wurden wichtige Incidents angemessen priorisiert? - Wurde das erwartete Outcome erreicht? - Sind die Zielzeiten selbst sinnvoll? Geeignete Governance-Informationen können umfassen: - erreichte Outcomes, - Serviceleistung, - Benutzer- und Kundenerfahrung, - Risiken und Abweichungen, - Sicherheitsvorfälle, - wiederkehrende Incidents, - Wirksamkeit von Verbesserungen, - Kostenentwicklung, - Lieferantenleistung, - Wiederherstellungstests, - und Einhaltung verbindlicher Anforderungen. > **Typischer Fehler** > > Eine einzelne leicht messbare Kennzahl wird zum alleinigen Steuerungsziel. > > Mitarbeiter optimieren anschließend die Kennzahl, ohne den tatsächlichen Wert zu verbessern. --- **Verantwortlichkeit für Produkte und Services** Für wichtige Produkte und Services sollten Verantwortlichkeiten geklärt sein. Mögliche Rollen können sein: - Product Owner, - Product Manager, - Service Owner, - Service Manager, - technische Systemverantwortliche, - Information Owner, - Process Owner, - Practice Owner, - Supplier Manager, - Risk Owner, - und Informationssicherheitsverantwortliche. ITIL schreibt nicht für jede Organisation dieselben Rollenbezeichnungen oder Organisationsstrukturen vor. Entscheidend ist, dass folgende Fragen beantwortet werden: - Wer verantwortet das Produkt? - Wer verantwortet den Service? - Wer entscheidet über Prioritäten? - Wer verantwortet technische Komponenten? - Wer akzeptiert Risiken? - Wer verantwortet Daten? - Wer steuert Lieferanten? - Wer überwacht die Leistung? - Wer treibt Verbesserungen voran? > **Wichtig** > > Eine Rollenbezeichnung allein schafft noch keine wirksame Verantwortung. > > Die Rolle benötigt Befugnisse, Informationen, Fähigkeiten und Ressourcen. --- **Service Owner und technische Verantwortung unterscheiden** Ein Service Owner betrachtet den Service normalerweise aus einer Ende-zu-Ende-Perspektive. Technische Verantwortliche betreuen dagegen möglicherweise einzelne Bestandteile. Beispiel: E-Mail-Service | Verantwortungsbereich | Mögliche Zuständigkeit | |---|---| | gesamter E-Mail-Service | Service Owner | | Identitätsplattform | Identity-Team | | DNS | Netzwerk- oder Infrastrukturteam | | Mailplattform | Messaging-Team oder Cloud-Provider | | Endgeräte und Client | Workplace-Team | | Sicherheitsanforderungen | Informationssicherheit | | Lieferantenvertrag | Supplier Management oder Einkauf | | Benutzerunterstützung | Service Desk | Der Service Owner muss nicht jede technische Tätigkeit selbst ausführen. Er benötigt jedoch ausreichende Informationen, um: - Serviceleistung zu bewerten, - Abhängigkeiten zu verstehen, - Risiken zu eskalieren, - Prioritäten abzustimmen, - und Verbesserungen zu unterstützen. --- **RACI als mögliches Hilfsmittel** Eine RACI-Matrix kann helfen, Rollen bei einer Tätigkeit zu klären. | Kürzel | Bedeutung | |---|---| | **R – Responsible** | führt die Aufgabe aus | | **A – Accountable** | steht für das Ergebnis ein und besitzt die übergeordnete Verantwortlichkeit | | **C – Consulted** | wird vor oder während der Entscheidung fachlich einbezogen | | **I – Informed** | wird über Entscheidung oder Ergebnis informiert | Beispiel: produktive Firewall-Änderung | Rolle | Zuordnung | |---|---| | Netzwerkadministrator | Responsible | | autorisierte Change- oder Service-Rolle | Accountable | | Informationssicherheit und Anwendungsverantwortlicher | Consulted | | Service Desk und betroffene Benutzergruppen | Informed | Eine RACI-Matrix ist ein mögliches Organisationswerkzeug und keine zwingend vorgeschriebene ITIL-Darstellung. Bei der Verwendung sollte vermieden werden: - mehrere unklare Accountable-Zuordnungen, - fehlende ausführende Verantwortung, - Beteiligung zu vieler Personen, - veraltete Rollenzuordnungen, - und eine Matrix ohne praktische Anwendung. --- **Eskalation** Eskalation ist notwendig, wenn: - eine Entscheidung außerhalb der eigenen Befugnis liegt, - ein Risiko die eigene Entscheidungsgrenze überschreitet, - vereinbarte Ziele gefährdet sind, - benötigte Ressourcen fehlen, - Verantwortlichkeiten unklar bleiben, - ein Konflikt nicht gelöst werden kann, - eine Sicherheits- oder Datenschutzverletzung möglich ist, - oder eine verbindliche Vorgabe nicht eingehalten werden kann. Eskalation bedeutet nicht automatisch persönliches Versagen. Sie ist ein vorgesehener Mechanismus, um Entscheidungen an die geeignete Verantwortungs- und Befugnisebene zu übergeben. > **Praxistipp** > > Eine gute Eskalation enthält: > > - konkrete Situation, > - bekannte Auswirkungen, > - bisherige Maßnahmen, > - bestehendes Risiko, > - benötigte Entscheidung, > - mögliche Optionen, > - und den spätesten sinnvollen Entscheidungszeitpunkt. Ungeeignete Eskalation: > Das System funktioniert nicht. Bitte entscheiden. Besser: > Der zentrale Dateiservice ist seit 09:10 Uhr für zwei Standorte nicht erreichbar. Die lokale Wiederherstellung war erfolglos. Eine Umschaltung auf das Ersatzsystem ist möglich, kann aber Datenänderungen der letzten 15 Minuten verlieren. Benötigt wird die Entscheidung, ob die Umschaltung durchgeführt und der mögliche Datenverlust akzeptiert wird. --- **Governance bei Incidents** Governance bestimmt unter anderem den Rahmen für: - Priorisierung, - Eskalation, - Major-Incident-Kriterien, - Kommunikation, - Entscheidungsbefugnisse, - Sicherheitsmeldungen, - und Risikoakzeptanz. Bei einem kritischen Incident sollte geklärt sein: - Wer darf ein Major-Incident-Verfahren aktivieren? - Wer übernimmt die Koordination? - Wer darf Notfallmaßnahmen autorisieren? - Wer informiert Führungskräfte, Kunden oder Behörden? - Welche Risiken dürfen kurzfristig akzeptiert werden? - Wer entscheidet über eine Wiederherstellung mit möglichen Nebenwirkungen? - Welche Dokumentation ist zwingend erforderlich? - Wann muss eine nachgelagerte Überprüfung stattfinden? Governance soll die Wiederherstellung nicht unnötig verzögern. Entscheidungsrechte und Notfallverfahren sollten deshalb vor einem Incident vorbereitet werden. --- **Governance bei Changes** Governance legt den Rahmen fest, innerhalb dessen Changes bewertet und autorisiert werden. Dazu können gehören: - Change-Modelle, - Risikokriterien, - Entscheidungsbefugnisse, - Funktionstrennung, - notwendige Tests, - Rückfallplanung, - Dokumentation, - und nachgelagerte Überprüfung. Nicht jeder Change benötigt dieselben Beteiligten oder dasselbe Gremium. Die Autorisierung sollte sich richten nach: - Risiko, - Auswirkungen, - Komplexität, - Unsicherheit, - betroffenen Services, - und betrieblichen Vorgaben. > **Typischer Fehler** > > Ein Change Advisory Board wird als zentrale Freigabestelle für jede kleine Änderung verwendet. > > Dadurch können unnötige Verzögerungen entstehen, ohne dass kritische Changes automatisch besser bewertet werden. --- **Governance bei Lieferanten** Externe Lieferanten können einen wesentlichen Teil eines Produkts oder Service bereitstellen. Governance sollte unter anderem klären: - Welche Leistung wird erwartet? - Welche Risiken entstehen durch die Abhängigkeit? - Welche Daten verarbeitet der Lieferant? - Welche Sicherheitsanforderungen gelten? - Welche Unterauftragnehmer werden eingesetzt? - Wie wird die Leistung gemessen? - Welche Eskalationswege bestehen? - Welche Rechte bestehen bei Leistungsabweichungen? - Wie können Daten und Services zurückgeführt werden? - Was geschieht bei Vertragsende oder Ausfall des Lieferanten? > **Merke** > > Die Auslagerung einer Tätigkeit überträgt nicht automatisch die gesamte Verantwortung für das Ergebnis oder die Risiken an den Lieferanten. --- **Governance bei künstlicher Intelligenz** ITIL Version 5 berücksichtigt ausdrücklich AI-gestützte Produkte, Services und Arbeitsweisen. Governance für KI kann unter anderem behandeln: - zulässige Anwendungsfälle, - Verantwortlichkeit, - verwendete Daten, - Datenschutz, - Informationssicherheit, - Transparenz, - Nachvollziehbarkeit, - Verzerrungen, - menschliche Kontrolle, - Qualität der Ergebnisse, - Überwachung, - und gesetzliche Anforderungen. Vor dem Einsatz einer KI-Lösung sollte unter anderem geprüft werden: - Welches Outcome soll unterstützt werden? - Welche Entscheidungen darf die KI beeinflussen? - Welche Daten werden eingegeben oder gespeichert? - Können vertrauliche Informationen offengelegt werden? - Wie werden falsche Ergebnisse erkannt? - Wer prüft kritische Entscheidungen? - Wie werden Modelle oder Anbieteränderungen überwacht? - Kann die Funktion bei Problemen deaktiviert werden? - Wer trägt die Ergebnisverantwortung? > **Sicherheitsrelevant** > > Die Verwendung einer KI-Lösung überträgt die Verantwortung für Entscheidungen und Folgen nicht automatisch auf das technische System oder den Anbieter. --- **Governance und Continual Improvement** Governance und Continual Improvement unterstützen sich gegenseitig. Governance gibt unter anderem vor: - welche Ziele wichtig sind, - welche Risiken behandelt werden müssen, - welche Ergebnisse überwacht werden, - und welche Abweichungen nicht akzeptabel sind. Continual Improvement nutzt unter anderem: - Leistungsdaten, - Feedback, - Auditergebnisse, - Incident-Erkenntnisse, - Risikobewertungen, - und Governance-Entscheidungen, um Verbesserungen zu identifizieren und umzusetzen. Beispiel: Das Monitoring zeigt wiederholt, dass kritische Zertifikate erst kurz vor Ablauf erneuert werden. Governance kann festlegen: - kritische Zertifikate müssen zentral erfasst werden, - Verantwortlichkeiten müssen eindeutig sein, - Warnfristen müssen definiert werden, - und die Einhaltung muss überwacht werden. Continual Improvement entwickelt und verbessert anschließend: - Erfassung, - Alarmierung, - Arbeitsabläufe, - Automatisierung, - und Erfolgskontrolle. --- **Praxisbeispiel: Ausfall eines zentralen Speichersystems** Ein zentrales Speichersystem zeigt kritische Fehler. **Technische Situation** - mehrere Hosts verwenden das Storage - erste Datenträger zeigen Fehler - ein Ersatzsystem ist vorhanden - eine Umschaltung kann kurzzeitige Unterbrechungen verursachen - der Datenstand des Ersatzsystems muss geprüft werden **Evaluate** - Welche Services sind betroffen? - Wie hoch ist das Ausfallrisiko? - Welche Daten könnten verloren gehen? - Welche Alternativen bestehen? - Welche Auswirkungen besitzt eine sofortige Umschaltung? - Wie lange kann weiterbetrieben werden? **Direct** - Welche Services müssen zuerst geschützt werden? - Wer darf die Umschaltung autorisieren? - Welche Unterbrechung wird akzeptiert? - Welche Stakeholder müssen informiert werden? - Welche Datenverlustrisiken dürfen nicht überschritten werden? **Monitor** - Bleibt das Primärsystem stabil? - Ist die Replikation aktuell? - Funktioniert das Ersatzsystem? - Werden die Services nach der Umschaltung wiederhergestellt? - Werden alle offenen Risiken nachverfolgt? **Mögliche Verantwortlichkeiten** - Storage-Administrator: technische Analyse und Umsetzung - Service Owner: Bewertung der Serviceauswirkungen - Informationssicherheit oder Datenverantwortlicher: Bewertung des Datenrisikos - Incident-Koordination: Koordination und Kommunikation - autorisierte Entscheidungsrolle: Freigabe der risikobehafteten Umschaltung Dieses Beispiel zeigt, dass technische Kompetenz, Management und Governance zusammenwirken müssen. --- **Typische Governance-Fehler** **Fehler 1: Verantwortung ohne Befugnis** Eine Person soll für ein Ergebnis einstehen, besitzt aber keine Möglichkeit: - Entscheidungen zu treffen, - Ressourcen zu erhalten, - Informationen einzufordern, - oder Risiken zu eskalieren. --- **Fehler 2: Befugnis ohne Kontrolle** Eine Rolle darf weitreichende Entscheidungen treffen, ohne: - Ergebnisse dokumentieren, - Risiken begründen, - oder über Auswirkungen berichten zu müssen. --- **Fehler 3: Governance nur als Genehmigung verstehen** Viele Freigaben werden eingeführt, aber Ziele, Verantwortlichkeiten und Erfolgskriterien bleiben unklar. --- **Fehler 4: Jede Entscheidung zentralisieren** Auch risikoarme Tätigkeiten benötigen hochrangige Genehmigungen. Dadurch entstehen: - Verzögerungen, - Überlastung, - Umgehungslösungen, - und unklare operative Verantwortung. --- **Fehler 5: Risiken ohne Befugnis akzeptieren** Ein technisches Team dokumentiert ein erhebliches Risiko, entscheidet aber eigenständig, es dauerhaft zu akzeptieren. --- **Fehler 6: Nur technische Leistung überwachen** Server und Anwendungen sind verfügbar, aber: - Benutzer können ihre Aufgaben nicht ausführen, - Lieferanten erfüllen Vereinbarungen nicht, - oder Sicherheitsrisiken bleiben unbehandelt. --- **Fehler 7: Dokumentation mit Wirksamkeit verwechseln** Eine Richtlinie existiert, wird aber: - nicht verstanden, - nicht umgesetzt, - nicht kontrolliert, - oder durch Ausnahmen vollständig umgangen. --- **Fehler 8: Verantwortung bleibt an Teamgrenzen hängen** Jedes Team erfüllt seine Komponentenaufgabe, aber niemand verantwortet das Ende-zu-Ende-Ergebnis des Service. --- **Fehler 9: Governance nicht an Veränderungen anpassen** Entscheidungsmodelle und Kontrollen bleiben unverändert, obwohl sich: - Technologie, - Risiken, - Organisationsstruktur, - oder gesetzliche Anforderungen verändert haben. --- **Fragen für eine neue Organisation** Beim Einstieg in eine neue IT-Organisation solltest du klären: - Welche Governance-Gremien existieren? - Wer bestimmt strategische IT-Ziele? - Wer verantwortet wichtige Produkte und Services? - Wer darf Risiken akzeptieren? - Wer darf produktive Changes autorisieren? - Welche Tätigkeiten sind delegiert oder vorab autorisiert? - Welche Sicherheitsrichtlinien gelten? - Welche Eskalationswege bestehen? - Wie werden kritische Entscheidungen dokumentiert? - Welche Kennzahlen werden überwacht? - Wie werden Lieferanten gesteuert? - Wie werden Ausnahmen behandelt? - Wie werden Verbesserungen priorisiert? - Wie werden Major Incidents gesteuert? - Welche Notfallbefugnisse bestehen? --- **Entscheidungshilfe: Ist eine Governance-Entscheidung notwendig?** Eine Governance- oder übergeordnete Entscheidung kann erforderlich sein, wenn: - mehrere Produkte oder Services betroffen sind, - eine Entscheidung strategische Auswirkungen besitzt, - erhebliche finanzielle Mittel benötigt werden, - ein wesentliches Risiko akzeptiert werden soll, - gesetzliche oder vertragliche Anforderungen betroffen sind, - mehrere Verantwortungsbereiche im Konflikt stehen, - eine grundlegende Richtlinie geändert werden soll, - kritische Lieferantenabhängigkeiten entstehen, - oder eine Entscheidung außerhalb bestehender Befugnisse liegt. Eine operative Entscheidung kann dagegen innerhalb delegierter Befugnisse getroffen werden, wenn: - Ziel und Rahmen eindeutig sind, - das Risiko innerhalb festgelegter Grenzen liegt, - ausreichende Fachkenntnisse vorhanden sind, - und die notwendige Dokumentation und Kontrolle sichergestellt sind. --- **Checkliste für klare Verantwortlichkeiten** - [ ] Ist das gewünschte Ergebnis eindeutig? - [ ] Ist bekannt, wer für das Ergebnis einsteht? - [ ] Ist bekannt, wer die Aufgabe ausführt? - [ ] Ist die Entscheidungsbefugnis eindeutig? - [ ] Sind Fachberater und notwendige Beteiligte bekannt? - [ ] Ist festgelegt, wer informiert werden muss? - [ ] Besitzen die Rollen notwendige Informationen und Ressourcen? - [ ] Sind Grenzen der delegierten Befugnisse bekannt? - [ ] Besteht ein klarer Eskalationsweg? - [ ] Ist geregelt, wer verbleibende Risiken akzeptieren darf? - [ ] Wird das Ergebnis kontrolliert? - [ ] Werden Entscheidungen nachvollziehbar dokumentiert? --- **Checkliste für wirksame Governance** - [ ] Sind Ziele und Prioritäten eindeutig? - [ ] Sind Produkte, Services und kritische Outcomes bekannt? - [ ] Werden Bedürfnisse und Risiken regelmäßig bewertet? - [ ] Sind Richtlinien und Entscheidungsgrenzen verständlich? - [ ] Sind Verantwortung und Rechenschaftspflicht eindeutig? - [ ] Sind notwendige Befugnisse sinnvoll delegiert? - [ ] Passen Kontrollen zum tatsächlichen Risiko? - [ ] Werden relevante Ergebnisse und nicht nur Aktivitäten gemessen? - [ ] Werden Sicherheits-, Datenschutz- und Vertragsanforderungen berücksichtigt? - [ ] Werden Lieferanten und externe Abhängigkeiten überwacht? - [ ] Werden Abweichungen eskaliert und behandelt? - [ ] Werden Risiken nur durch befugte Rollen akzeptiert? - [ ] Werden Governance-Vorgaben regelmäßig überprüft? - [ ] Fließen Erkenntnisse in Continual Improvement ein? - [ ] Wird unnötige Bürokratie vermieden? --- **Schnellreferenz** | Frage | Governance-Bezug | |---|---| | Was wird benötigt? | Evaluate | | Welche Optionen und Risiken bestehen? | Evaluate | | Welches Ziel und welche Grenzen gelten? | Direct | | Wer darf entscheiden? | Direct | | Wer trägt die Ergebnisverantwortung? | Direct | | Werden Vorgaben eingehalten? | Monitor | | Werden Outcomes erreicht? | Monitor | | Bleiben Risiken innerhalb akzeptierter Grenzen? | Monitor | | Müssen Richtung oder Vorgaben angepasst werden? | erneutes Evaluate und Direct | --- **Zusammenfassende Darstellung** > Bedürfnisse, Ziele, Risiken und Rahmenbedingungen > ↓ > **Evaluate** > Situation und Optionen bewerten > ↓ > **Direct** > Richtung, Verantwortung und Grenzen vorgeben > ↓ > Management und technische Umsetzung > ↓ > **Monitor** > Ergebnisse, Risiken und Einhaltung überwachen > ↓ > Feedback, Abweichungen und neue Anforderungen > ↓ > erneute Bewertung und Anpassung --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 2.10 ITIL an den eigenen Kontext anpassen - Change Management - Information Security Management - Risk Management - Supplier Management - Service Level 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) - [ITIL: New ITIL Explained for Certified Professionals](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-explained) - [PeopleCert: Introduction to the ITIL Maturity Model](https://peoplecert.org/-/media/2244094fd4364faab8b1e22b35278bd9.ashx) - [PeopleCert: ITIL Transformation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-transformation-version-5-4173) - [PeopleCert: ITIL FAQ](https://www.peoplecert.org/help-and-support/faq-itil) **Einordnung** Die Aussagen zur Einbindung von Governance in das ITIL Value System sowie zu den Governance-Aktivitäten **Evaluate**, **Direct** und **Monitor** wurden anhand offizieller PeopleCert- und ITIL-Unterlagen geprüft. Die Ausführungen zu: - Entscheidungsbefugnissen, - Verantwortung, - RACI, - Richtlinien, - Kontrollen, - Eskalation, - Lieferanten, - Backup-Governance, - und den dargestellten Praxisfällen sind zusätzliche herstellerneutrale Erläuterungen und Praxisempfehlungen dieses unabhängigen Nachschlagewerks. Eine RACI-Matrix ist ein mögliches Hilfsmittel zur Rollenklärung, aber keine zwingend vorgeschriebene ITIL-Struktur. Konkrete Governance-Gremien, Rollenbezeichnungen, Freigabestufen und Risikogrenzen müssen von der jeweiligen Organisation festgelegt werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.5 Die vier Dimensionen des Produkt- und Service-Managements > **Kurz erklärt** > > Die vier Dimensionen unterstützen eine ganzheitliche Betrachtung digitaler Produkte und Services. > > Sie helfen dabei, nicht ausschließlich auf Technik, Prozesse oder einzelne Teams zu schauen. > > Die vier Dimensionen sind: > > 1. **Organizations and People** – Organisationen und Menschen > 2. **Information and Technology** – Informationen und Technologie > 3. **Partners and Suppliers** – Partner und Lieferanten > 4. **Value Streams and Processes** – Wertströme und Prozesse > > Bei Entscheidungen, Änderungen, Störungen und Verbesserungen sollten alle vier Dimensionen berücksichtigt werden. --- **Warum die vier Dimensionen notwendig sind** Digitale Produkte und Services entstehen durch das Zusammenwirken unterschiedlicher Bestandteile. Dazu gehören beispielsweise: - Menschen, - Rollen, - Wissen, - Informationen, - Anwendungen, - Infrastruktur, - Prozesse, - Wertströme, - Lieferanten, - Verträge, - Sicherheitsanforderungen, - und organisatorische Entscheidungen. Eine technische Lösung kann leistungsfähig sein und trotzdem keinen ausreichenden Wert ermöglichen. Beispiele: - Eine Anwendung funktioniert, aber niemand ist für ihren Support verantwortlich. - Ein Monitoring-System erkennt Fehler, aber Warnungen werden nicht bearbeitet. - Ein Cloud-Service ist verfügbar, aber der Vertrag enthält keine geeignete Ausstiegsregelung. - Ein Prozess ist ausführlich dokumentiert, wird aber von den Mitarbeitern nicht verstanden. - Eine neue Plattform besitzt viele Funktionen, lässt sich aber nicht in die vorhandene Umgebung integrieren. - Ein Service erfüllt technische Messwerte, unterstützt aber das benötigte Outcome nicht. Die vier Dimensionen helfen dabei, solche Lücken frühzeitig zu erkennen. > **Merke** > > Ein Produkt oder Service ist nur so wirksam wie das Zusammenspiel seiner organisatorischen, technischen, menschlichen und externen Bestandteile. --- **Die vier Dimensionen im Überblick** | Dimension | Zentrale Betrachtung | |---|---| | **Organizations and People** | Rollen, Fähigkeiten, Kapazitäten, Kommunikation, Kultur und Organisationsstruktur | | **Information and Technology** | Informationen, Wissen, Daten, Anwendungen, Infrastruktur, Integration und Automatisierung | | **Partners and Suppliers** | externe Leistungen, Lieferantenbeziehungen, Verträge, Abhängigkeiten und Zusammenarbeit | | **Value Streams and Processes** | Ende-zu-Ende-Arbeitsfluss, Aktivitäten, Übergaben, Kontrollen und Ergebnisse | Die Dimensionen sind keine voneinander getrennten Bereiche. Eine Entscheidung in einer Dimension beeinflusst häufig auch die anderen drei Dimensionen. --- **Die Dimensionen sind Betrachtungsperspektiven** Die vier Dimensionen sind: - keine vier Abteilungen, - keine vier aufeinanderfolgenden Prozessschritte, - keine vier Reifegrade, - und keine voneinander unabhängigen Managementsysteme. Sie dienen als Perspektiven, mit denen ein Produkt, Service, Wertstrom, Problem oder Vorhaben untersucht werden kann. Beispiel: Eine Organisation führt eine neue Plattform für die zentrale Dateiablage ein. **Organizations and People** - Wer verwaltet die Plattform? - Wer unterstützt die Benutzer? - Welche Fähigkeiten werden benötigt? - Wer genehmigt Zugriffe? **Information and Technology** - Welche Daten werden gespeichert? - Wie werden Berechtigungen technisch umgesetzt? - Welche Schnittstellen bestehen? - Wie werden Backup und Wiederherstellung realisiert? **Partners and Suppliers** - Wird ein Cloud-Anbieter verwendet? - Welche Leistungen werden vertraglich zugesichert? - Wie werden Störungen eskaliert? - Wie können Daten bei Vertragsende exportiert werden? **Value Streams and Processes** - Wie werden neue Zugriffe beantragt? - Wie werden Freigaben erteilt? - Wie werden Berechtigungen entfernt? - Wie werden Incidents und Service Requests bearbeitet? Erst die gemeinsame Betrachtung ergibt ein vollständigeres Bild. --- **Nicht jede Dimension benötigt immer denselben Aufwand** Alle vier Dimensionen sollten berücksichtigt werden. Das bedeutet jedoch nicht, dass sie bei jeder Aufgabe gleich ausführlich dokumentiert werden müssen. Beispiel: Bei einer einfachen, dokumentierten Standardtätigkeit kann eine kurze Prüfung ausreichen. Bei der Einführung einer geschäftskritischen Cloud-Plattform kann dagegen eine umfangreiche Betrachtung notwendig sein. Der erforderliche Umfang hängt unter anderem ab von: - Bedeutung des betroffenen Produkts oder Service, - Anzahl der betroffenen Stakeholder, - Risiko, - Komplexität, - gesetzlichen und vertraglichen Anforderungen, - Sicherheitsanforderungen, - Neuartigkeit der Lösung, - Lieferantenabhängigkeit, - und möglicher Auswirkung eines Fehlers. > **Grundsatz** > > Alle vier Dimensionen berücksichtigen, aber den Prüf- und Dokumentationsaufwand an Risiko und Kontext anpassen. --- **1. Organizations and People** Die Dimension **Organizations and People** betrachtet die organisatorischen und menschlichen Voraussetzungen für wirksames Produkt- und Service-Management. Dazu gehören unter anderem: - Organisationsstruktur, - Rollen, - Verantwortlichkeiten, - Entscheidungsbefugnisse, - Fähigkeiten, - Kompetenzen, - Personalkapazität, - Kommunikation, - Zusammenarbeit, - Führung, - Kultur, - Motivation, - und gemeinsame Werte. Technische Systeme werden von Menschen: - geplant, - entwickelt, - beschafft, - konfiguriert, - betrieben, - unterstützt, - überwacht, - verwendet, - und verbessert. Eine technisch geeignete Lösung kann deshalb scheitern, wenn die menschlichen und organisatorischen Voraussetzungen fehlen. --- **Organisationen sind mehr als Organigramme** Ein Organigramm zeigt formale Strukturen. Es beantwortet jedoch nicht automatisch: - Wie werden Entscheidungen tatsächlich getroffen? - Wer besitzt notwendiges Fachwissen? - Wer übernimmt bei einem Incident die Koordination? - Wie arbeiten Teams miteinander? - Welche informellen Abhängigkeiten bestehen? - Wo entstehen Konflikte oder Verzögerungen? - Können Mitarbeiter Probleme offen ansprechen? - Werden Erfahrungen und Fehler für Verbesserungen genutzt? Für die Bewertung dieser Dimension müssen deshalb sowohl formale als auch tatsächlich gelebte Arbeitsweisen betrachtet werden. > **Typischer Fehler** > > Eine Rolle ist im Organigramm eingetragen, besitzt aber weder ausreichende Befugnisse noch Zeit, Informationen oder Ressourcen, um ihre Verantwortung wahrzunehmen. --- **Rollen und Verantwortlichkeiten** Für wichtige Produkte, Services und Tätigkeiten sollte geklärt sein: - Wer entscheidet? - Wer führt die Tätigkeit aus? - Wer steht für das Ergebnis ein? - Wer muss fachlich beteiligt werden? - Wer muss informiert werden? - Wer darf Risiken akzeptieren? - Wer koordiniert bei Störungen? - Wer pflegt Dokumentationen? - Wer treibt Verbesserungen voran? Mögliche Rollen sind beispielsweise: - Product Owner, - Product Manager, - Service Owner, - Service Manager, - Systemadministrator, - Netzwerkadministrator, - Service-Desk-Mitarbeiter, - Information Owner, - Supplier Manager, - Informationssicherheitsverantwortlicher, - und Change-Verantwortlicher. ITIL schreibt nicht vor, dass jede Organisation genau diese Rollenbezeichnungen verwenden muss. Entscheidend ist, dass Verantwortung, Befugnis und erwartetes Ergebnis eindeutig sind. --- **Fähigkeiten und Kompetenzen** Eine Organisation benötigt nicht nur ausreichend Personal, sondern auch geeignete Fähigkeiten. Dazu können gehören: - technisches Fachwissen, - Produktwissen, - Serviceverständnis, - Fehleranalyse, - Kommunikation, - Risikobewertung, - Dokumentation, - Lieferantensteuerung, - Informationssicherheit, - Automatisierung, - Datenanalyse, - und Entscheidungsfähigkeit. Bei einer neuen Technologie sollte deshalb nicht nur geprüft werden: > Kann das Produkt beschafft oder installiert werden? Zusätzlich ist zu prüfen: - Wer kann es betreiben? - Wer kann Fehler analysieren? - Wer kann die Sicherheit bewerten? - Wer übernimmt Bereitschaft und Support? - Wie wird Wissen aufgebaut? - Wie wird Wissen bei Personalwechsel erhalten? - Welche Fähigkeiten müssen intern vorhanden bleiben? - Welche Fähigkeiten können extern bezogen werden? > **Merke** > > Eine Organisation besitzt eine Fähigkeit nicht allein deshalb, weil sie ein Werkzeug gekauft hat. --- **Kapazität und Arbeitsbelastung** Auch fachlich geeignete Mitarbeiter können ihre Aufgaben nicht wirksam erfüllen, wenn ausreichende Kapazität fehlt. Anzeichen für Kapazitätsprobleme können sein: - Tickets bleiben lange unbearbeitet. - Dokumentationen werden dauerhaft verschoben. - Wartungsarbeiten finden nicht statt. - Verbesserungen werden immer wieder abgebrochen. - Mitarbeiter reagieren nur noch auf akute Störungen. - Wissen konzentriert sich auf einzelne Personen. - Vertretungen fehlen. - Bereitschaftsdienste sind dauerhaft überlastet. - Sicherheitsmaßnahmen werden aus Zeitmangel nicht umgesetzt. Kapazität sollte deshalb nicht nur anhand der Anzahl von Mitarbeitern bewertet werden. Zu berücksichtigen sind außerdem: - benötigte Fähigkeiten, - Arbeitsmenge, - Komplexität, - Automatisierungsgrad, - Servicezeiten, - Bereitschaftsanforderungen, - Urlaubs- und Krankheitsvertretung, - und ungeplante Arbeit. --- **Kommunikation und Zusammenarbeit** Digitale Produkte und Services überschreiten häufig Team- und Organisationsgrenzen. Eine wirksame Zusammenarbeit benötigt: - gemeinsame Ziele, - verständliche Begriffe, - geeignete Kommunikationswege, - sichtbare Zuständigkeiten, - aktuelle Informationen, - nachvollziehbare Entscheidungen, - und funktionierende Eskalationswege. Mögliche Kommunikationsprobleme sind: - Teams verwenden dieselben Begriffe mit unterschiedlicher Bedeutung. - Informationen werden nur in privaten Chats weitergegeben. - technische Änderungen werden dem Service Desk nicht mitgeteilt. - Lieferanten erhalten unvollständige Fehlerbeschreibungen. - Benutzer bekommen widersprüchliche Statusmeldungen. - Entscheidungen werden nicht dokumentiert. - Wissen wird erst weitergegeben, wenn eine Schlüsselperson ausfällt. > **Praxistipp** > > Die Qualität der Zusammenarbeit zeigt sich besonders an Übergaben, Störungen und Änderungen. --- **Organisationskultur** Kultur beeinflusst, wie Menschen tatsächlich handeln. Sie zeigt sich beispielsweise darin: - ob Fehler offen gemeldet werden, - ob Risiken angesprochen werden dürfen, - ob Teams Wissen teilen, - ob Verantwortlichkeiten übernommen werden, - ob Probleme nur einzelnen Personen zugeschrieben werden, - ob Benutzerfeedback ernst genommen wird, - und ob Verbesserungen dauerhaft unterstützt werden. Eine Organisation kann offiziell Zusammenarbeit fördern und gleichzeitig durch ihre tatsächliche Arbeitsweise Konkurrenz zwischen Teams erzeugen. Beispiel: Teams werden ausschließlich nach ihrer eigenen Bearbeitungszeit bewertet. Dadurch kann jedes Team versuchen, Vorgänge möglichst schnell weiterzugeben. Die lokale Kennzahl verbessert sich, während sich die gesamte Bearbeitungsdauer für den Benutzer verlängert. --- **Leitfragen zu Organizations and People** - Sind Rollen und Verantwortlichkeiten eindeutig? - Besitzen die Rollen ausreichende Befugnisse? - Sind notwendige Fähigkeiten vorhanden? - Gibt es ausreichende Kapazität? - Wie werden Wissen und Erfahrung weitergegeben? - Funktionieren Vertretungen? - Sind Kommunikations- und Eskalationswege bekannt? - Unterstützt die Organisationskultur Zusammenarbeit? - Werden Mitarbeiter bei Veränderungen angemessen einbezogen? - Verstehen die Beteiligten das angestrebte Outcome? - Sind Anreize und Kennzahlen auf den gesamten Wertstrom ausgerichtet? - Können Probleme und Risiken offen angesprochen werden? --- **2. Information and Technology** Die Dimension **Information and Technology** betrachtet die Informationen, das Wissen und die Technologien, die für Produkte und Services benötigt werden. Dazu gehören beispielsweise: - Daten, - Dokumentationen, - Wissen, - Anwendungen, - Infrastruktur, - Netzwerke, - Cloud-Plattformen, - Datenbanken, - Schnittstellen, - Automatisierung, - Monitoring, - Kommunikationssysteme, - Sicherheitswerkzeuge, - und künstliche Intelligenz. Informationen und Technologie unterstützen nahezu jede Tätigkeit im digitalen Produkt- und Service-Management. Sie müssen jedoch zu den tatsächlichen Anforderungen und Fähigkeiten der Organisation passen. --- **Informationen als Arbeitsgrundlage** Geeignete Entscheidungen benötigen geeignete Informationen. Beispiele: - Ein Incident benötigt Angaben zu Auswirkungen, Symptomen und betroffenen Services. - Ein Change benötigt Informationen zu Risiken, Abhängigkeiten und Rückfallmöglichkeiten. - Ein Service Owner benötigt Informationen über Leistung, Erfahrung und Risiken. - Ein Administrator benötigt aktuelle Konfigurationsinformationen. - Ein Lieferantenmanager benötigt Informationen über vereinbarte und tatsächlich erbrachte Leistungen. - Governance benötigt Informationen über Outcomes, Risiken und Regelkonformität. Informationen sollten möglichst: - korrekt, - aktuell, - vollständig genug, - verständlich, - verfügbar, - geschützt, - nachvollziehbar, - und für den jeweiligen Zweck geeignet sein. > **Wichtig** > > Mehr Daten bedeuten nicht automatisch bessere Informationen. > > Entscheidend ist, ob die Daten verständlich, zuverlässig und für eine konkrete Entscheidung nutzbar sind. --- **Datenqualität** Fehlerhafte oder veraltete Daten können zu falschen Entscheidungen führen. Beispiele: - Ein ausgeschiedener Mitarbeiter besitzt weiterhin aktive Berechtigungen. - Eine CMDB enthält nicht mehr vorhandene Server. - Ein Servicekatalog nennt einen nicht mehr verantwortlichen Service Owner. - Ein Monitoring-System verwendet veraltete Schwellenwerte. - Eine Knowledge-Base beschreibt eine frühere Softwareversion. - Ein Asset-System enthält doppelte oder unvollständige Geräteinformationen. Datenqualität sollte deshalb nicht nur bei der Erfassung, sondern über den gesamten Lebenszyklus betrachtet werden. Zu klären ist: - Wer erzeugt die Daten? - Wer verwendet sie? - Wer ist für ihre Qualität verantwortlich? - Wann werden sie aktualisiert? - Wie werden Fehler erkannt? - Wann werden sie archiviert oder gelöscht? - Welche Quelle gilt als maßgeblich? --- **Information und Wissen unterscheiden** Informationen werden erst durch Einordnung und Erfahrung zu anwendbarem Wissen. Beispiel: **Information** > Der Dienst wurde innerhalb von drei Monaten zwölfmal neu gestartet. **Wissen** > Die Neustarts treten regelmäßig nach einem bestimmten Speicheranstieg auf und stellen nur eine vorübergehende Wiederherstellung dar. **Anwendbare Erkenntnis** > Die Ursache muss untersucht und eine dauerhafte Korrektur geplant werden. Knowledge Management soll dabei helfen, relevante Informationen: - zu erfassen, - zu bewerten, - zu strukturieren, - auffindbar zu machen, - zu verwenden, - und aktuell zu halten. --- **Technologieauswahl** Eine Technologie sollte nicht nur anhand ihrer Funktionen bewertet werden. Zu berücksichtigen sind beispielsweise: - benötigte Outcomes, - Kompatibilität, - Integrationen, - Skalierbarkeit, - Verfügbarkeit, - Sicherheit, - Datenschutz, - Bedienbarkeit, - Wartbarkeit, - Support, - Kosten, - Fähigkeiten der Mitarbeiter, - Lieferantenabhängigkeit, - Datenportabilität, - und Ablösung am Lebensende. > **Typischer Fehler** > > Eine neue Technologie wird eingeführt, weil sie viele Funktionen besitzt. > > Erst später wird festgestellt, dass sie nicht zu vorhandenen Arbeitsweisen, Fähigkeiten oder Schnittstellen passt. --- **Architektur und Integration** Digitale Produkte und Services bestehen häufig aus mehreren integrierten Systemen. Zu berücksichtigen sind: - Datenflüsse, - APIs, - Protokolle, - Identitäten, - Berechtigungen, - Abhängigkeiten, - Schnittstellen, - Ausfallszenarien, - und Versionskompatibilität. Beispiel: Eine Anwendung kann technisch verfügbar sein, aber nicht nutzbar, wenn: - der Identitätsanbieter gestört ist, - DNS-Einträge fehlen, - ein Zertifikat abgelaufen ist, - eine API nicht erreichbar ist, - oder eine benötigte Lizenz nicht zugeordnet wurde. Eine ganzheitliche Betrachtung erfordert deshalb Informationen über Ende-zu-Ende-Abhängigkeiten. --- **Informationssicherheit** Informationen und Technologien müssen angemessen geschützt werden. Zu den grundlegenden Schutzzielen gehören insbesondere: - Vertraulichkeit, - Integrität, - Verfügbarkeit. Je nach Kontext können außerdem relevant sein: - Authentizität, - Nachvollziehbarkeit, - Datenschutz, - Beweissicherheit, - und Widerstandsfähigkeit. Bei technischen Entscheidungen sollte geprüft werden: - Welche Informationen werden verarbeitet? - Welchen Schutzbedarf besitzen sie? - Wer darf darauf zugreifen? - Wie werden Zugriffe kontrolliert? - Wie werden Daten übertragen und gespeichert? - Welche Protokollierung ist notwendig? - Wie werden Daten gesichert und wiederhergestellt? - Wann müssen Daten gelöscht werden? - Welche Sicherheitsvorfälle sind möglich? --- **Automatisierung** Automatisierung kann: - wiederkehrende Arbeit reduzieren, - Ergebnisse vereinheitlichen, - Fehler verringern, - Geschwindigkeit erhöhen, - und Skalierbarkeit verbessern. Sie benötigt jedoch: - einen verstandenen Ablauf, - geeignete Eingabedaten, - klare Regeln, - Fehlerbehandlung, - Überwachung, - Verantwortlichkeit, - und eine Rückfallmöglichkeit. Beispiel: Eine automatisierte Benutzeranlage kann Konten, Lizenzen und Standardgruppen bereitstellen. Die Automatisierung muss trotzdem klären: - Liegt eine gültige Anforderung vor? - Wurde der Zugriff genehmigt? - Sind die Personaldaten vollständig? - Existiert bereits ein Konto? - Was geschieht bei einem Teilfehler? - Wer prüft das Ergebnis? - Wie werden Ausnahmen behandelt? --- **Künstliche Intelligenz** KI kann bei digitalen Produkten und Services unter anderem eingesetzt werden für: - Klassifizierung, - Zusammenfassung, - Analyse, - Suche, - Mustererkennung, - Prognosen, - Vorschläge, - Automatisierung, - und Benutzerinteraktion. Dabei müssen unter anderem betrachtet werden: - Datenqualität, - Datenschutz, - Informationssicherheit, - mögliche Verzerrungen, - Nachvollziehbarkeit, - Fehlerwahrscheinlichkeit, - menschliche Kontrolle, - Verantwortlichkeit, - Anbieterabhängigkeit, - und Überwachung der Ergebnisse. > **Sicherheitsrelevant** > > Eine KI-generierte Antwort oder Entscheidung muss abhängig von ihrer möglichen Auswirkung angemessen geprüft werden. > > Die Verantwortung verbleibt bei der Organisation und den zuständigen Rollen. --- **Technische Schulden** Technische Schulden entstehen, wenn kurzfristige Lösungen später zusätzlichen Aufwand oder Risiken verursachen. Beispiele: - nicht unterstützte Softwareversionen, - manuelle Sonderkonfigurationen, - fehlende Automatisierung, - veraltete Schnittstellen, - unzureichende Tests, - fehlende Dokumentation, - oder dauerhaft eingesetzte Zwischenlösungen. Technische Schulden sind nicht automatisch vollständig vermeidbar. Sie sollten jedoch: - sichtbar, - bewertet, - priorisiert, - verantwortet, - und kontrolliert reduziert werden. --- **Leitfragen zu Information and Technology** - Welche Informationen werden benötigt? - Sind die Informationen korrekt, aktuell und geschützt? - Wer ist für die Datenqualität verantwortlich? - Welche Technologien unterstützen das Outcome? - Passen die Technologien zur vorhandenen Architektur? - Welche Integrationen und Abhängigkeiten bestehen? - Sind Sicherheit und Datenschutz berücksichtigt? - Sind Backup und Wiederherstellung vorbereitet? - Besitzen Mitarbeiter die notwendigen Fähigkeiten? - Welche Tätigkeiten können sinnvoll automatisiert werden? - Wie werden automatisierte oder KI-gestützte Ergebnisse kontrolliert? - Welche technischen Schulden bestehen? - Wie werden Systeme am Ende ihres Lebenszyklus abgelöst? --- **3. Partners and Suppliers** Die Dimension **Partners and Suppliers** betrachtet externe Organisationen und Personen, die an Produkten, Services oder Wertströmen beteiligt sind. Dazu können gehören: - Hardwarehersteller, - Softwareanbieter, - Cloud-Provider, - Telekommunikationsanbieter, - Beratungsunternehmen, - Managed Service Provider, - Logistikunternehmen, - Wartungsdienstleister, - Schulungsanbieter, - und Unterauftragnehmer. Viele Organisationen können digitale Produkte und Services nicht vollständig allein bereitstellen. Externe Partner können: - Technologien, - Fachwissen, - Kapazitäten, - Infrastruktur, - Support, - Lizenzen, - oder vollständige Servicebestandteile bereitstellen. --- **Partner und Lieferant unterscheiden** Die Begriffe können in Organisationen unterschiedlich verwendet werden. Vereinfacht kann unterschieden werden: | Begriff | Mögliche Bedeutung | |---|---| | **Lieferant** | stellt vertraglich vereinbarte Produkte oder Leistungen bereit | | **Partner** | arbeitet enger und möglicherweise längerfristig an gemeinsamen Outcomes mit | Ein Lieferant kann gleichzeitig ein strategischer Partner sein. Entscheidend ist nicht nur die Bezeichnung, sondern: - welche Leistung erbracht wird, - welche Verantwortung besteht, - welche Abhängigkeit entsteht, - wie eng zusammengearbeitet wird, - und wie die Beziehung gesteuert wird. --- **Sourcing-Entscheidungen** Organisationen müssen entscheiden, welche Fähigkeiten und Leistungen sie: - intern aufbauen, - extern beschaffen, - gemeinsam mit Partnern erbringen, - oder vollständig als externen Service nutzen. Mögliche Kriterien sind: - strategische Bedeutung, - vorhandene Fähigkeiten, - Kosten, - Geschwindigkeit, - Flexibilität, - Skalierbarkeit, - Sicherheitsanforderungen, - gesetzliche Anforderungen, - Kontrollbedarf, - Verfügbarkeit geeigneter Anbieter, - und Abhängigkeiten. > **Typischer Fehler** > > Eine Tätigkeit wird ausschließlich wegen kurzfristig geringerer Kosten ausgelagert. > > Langfristige Abhängigkeiten, Datenportabilität, interne Fähigkeiten und Ausstiegskosten werden nicht berücksichtigt. --- **Verträge und Vereinbarungen** Verträge und Vereinbarungen sollten die benötigten Outcomes unterstützen. Mögliche Inhalte sind: - Leistungsumfang, - Verantwortlichkeiten, - Servicezeiten, - Qualitätsziele, - Sicherheitsanforderungen, - Datenschutz, - Eskalationswege, - Support, - Meldepflichten, - Wartungsbedingungen, - Datenstandort, - Unterauftragnehmer, - Auditmöglichkeiten, - Haftung, - Vertragsänderungen, - Kündigung, - Datenrückgabe, - und Übergangsunterstützung. Eine vertraglich zugesicherte technische Verfügbarkeit beantwortet nicht automatisch: - wie gut der Support funktioniert, - wie schnell ein kritischer Incident koordiniert wird, - wie Daten zurückgeführt werden, - oder ob der Service das benötigte Outcome ermöglicht. --- **Lieferantenabhängigkeiten** Externe Abhängigkeiten sollten sichtbar und bewertet sein. Mögliche Risiken sind: - Ausfall eines einzelnen Anbieters, - fehlende alternative Anbieter, - proprietäre Datenformate, - schwer ersetzbare Schnittstellen, - Preissteigerungen, - Vertragsänderungen, - fehlende interne Kenntnisse, - eingeschränkte Datenportabilität, - nicht kontrollierte Unterauftragnehmer, - und lange Migrationszeiten. Besonders kritisch kann eine Konzentration entstehen, wenn viele Produkte und Services von demselben Anbieter abhängen. Beispiel: Ein einziger Cloud-Anbieter stellt bereit: - Identitätsdienst, - E-Mail, - Dateiablage, - Kollaborationsplattform, - Gerätemanagement, - und Sicherheitsfunktionen. Ein Ausfall oder Vertragsproblem kann dann mehrere zentrale Services gleichzeitig beeinflussen. --- **Geteilte Verantwortung** Bei extern bereitgestellten Services bleiben Verantwortlichkeiten häufig zwischen Anbieter und Kunde aufgeteilt. Beispiel: Cloud-Service Der Anbieter kann verantwortlich sein für: - Betrieb der Plattform, - physische Infrastruktur, - bestimmte Sicherheitsmaßnahmen, - und zugesicherte Verfügbarkeit. Die nutzende Organisation kann weiterhin verantwortlich sein für: - Benutzerkonten, - Berechtigungen, - Konfiguration, - Datenklassifizierung, - Endgeräte, - sichere Nutzung, - und eigene Backups oder Exporte. Die genaue Aufteilung hängt vom jeweiligen Produkt, Vertrag und Bereitstellungsmodell ab. > **Merke** > > Eine ausgelagerte Tätigkeit bedeutet nicht automatisch, dass alle Risiken und Verantwortlichkeiten auf den Anbieter übergehen. --- **Lieferanten in Incidents** Bei einem Incident sollte geklärt sein: - Welcher Lieferant ist betroffen? - Welche Vertrags- oder Supportnummer wird benötigt? - Wer darf den Lieferanten kontaktieren? - Welche Informationen müssen übermittelt werden? - Welche Prioritätsstufen verwendet der Lieferant? - Welche Reaktions- und Lösungsziele gelten? - Wie erfolgt die Eskalation? - Wer koordiniert intern weiter? - Wie werden Benutzer informiert? - Wie werden Beweise und Protokolle gesichert? Eine Supportanfrage an einen Lieferanten ersetzt nicht die interne Verantwortung für: - Koordination, - Kommunikation, - Risikobewertung, - und Überprüfung des gesamten Service. --- **Ausstiegs- und Übergangsplanung** Bereits bei der Auswahl eines Lieferanten sollte betrachtet werden, wie die Beziehung später verändert oder beendet werden kann. Zu prüfen sind: - Können Daten vollständig exportiert werden? - In welchem Format werden Daten bereitgestellt? - Wie lange dauert eine Migration? - Welche technische Unterstützung wird angeboten? - Was geschieht mit Sicherungskopien? - Wie werden Zugänge entfernt? - Welche Dokumentationen werden übergeben? - Welche internen Fähigkeiten müssen erhalten bleiben? - Welche Kosten entstehen beim Ausstieg? - Wie wird ein unterbrechungsarmer Übergang ermöglicht? > **Praxistipp** > > Eine Exit-Strategie sollte nicht erst entwickelt werden, wenn der Vertrag bereits beendet werden muss. --- **Leitfragen zu Partners and Suppliers** - Welche externen Partner sind beteiligt? - Welche Leistungen stellen sie bereit? - Welche Produkte und Services hängen davon ab? - Sind Verantwortlichkeiten eindeutig geregelt? - Passen Verträge zu den benötigten Outcomes? - Welche Sicherheits- und Datenschutzanforderungen gelten? - Werden Unterauftragnehmer eingesetzt? - Wie wird die Lieferantenleistung überwacht? - Welche Eskalationswege bestehen? - Welche Konzentrations- und Ausfallrisiken bestehen? - Welche internen Fähigkeiten müssen erhalten bleiben? - Können Daten und Leistungen zu einem anderen Anbieter übertragen werden? - Gibt es eine geeignete Ausstiegs- und Übergangsplanung? --- **4. Value Streams and Processes** Die Dimension **Value Streams and Processes** betrachtet, wie Arbeit durch die Organisation fließt und wie Aktivitäten zu Ergebnissen und Wert beitragen. Dazu gehören: - Wertströme, - Prozesse, - Aktivitäten, - Eingaben, - Ergebnisse, - Rollen, - Übergaben, - Entscheidungen, - Kontrollen, - Messgrößen, - und Rückmeldungen. Einzelne Teams können ihre Aufgaben gut erfüllen und trotzdem einen schlechten Ende-zu-Ende-Arbeitsfluss erzeugen. Die Dimension richtet den Blick deshalb nicht nur auf einzelne Prozessschritte, sondern auf den gesamten Weg zum benötigten Outcome. --- **Value Stream** Ein Value Stream beschreibt eine Abfolge von Schritten, durch die Wert für einen Stakeholder ermöglicht wird. Beispiele: - neuen Mitarbeiter arbeitsfähig machen, - einen Incident bearbeiten, - eine Anwendung bereitstellen, - einen Zugriff genehmigen, - eine Schwachstelle beheben, - einen Service verbessern, - oder einen Lieferanten ablösen. Ein Value Stream kann mehrere: - Teams, - Practices, - Technologien, - Prozesse, - Lieferanten, - und organisatorische Bereiche verbinden. > **Merke** > > Ein Wertstrom folgt dem Weg zum Outcome und nicht automatisch der Struktur des Organigramms. --- **Prozess** Ein Prozess ist eine strukturierte Folge miteinander verbundener Aktivitäten. Er überführt bestimmte Eingaben in Ergebnisse. Ein Prozess kann beispielsweise festlegen: - welche Informationen benötigt werden, - welche Schritte durchgeführt werden, - wer beteiligt ist, - welche Entscheidungen notwendig sind, - und wie das Ergebnis kontrolliert wird. Ein Value Stream kann mehrere Prozesse enthalten. Ein Prozess kann wiederum in mehreren Value Streams verwendet werden. Beispiel: Der Prozess zur Benutzerkontoanlage kann Bestandteil sein von: - Mitarbeiter-Onboarding, - Bereitstellung eines zusätzlichen Zugriffs, - Wechsel der Abteilung, - und Wiederherstellung eines irrtümlich entfernten Kontos. --- **Ende-zu-Ende-Sicht** Eine Ende-zu-Ende-Betrachtung prüft den gesamten Weg vom Bedarf bis zum erreichten Outcome. Beispiel: neuer Mitarbeiter 1. Eintritt wird gemeldet. 2. Aufgaben und benötigte Zugriffe werden bestimmt. 3. Freigaben werden eingeholt. 4. Benutzerkonto wird erstellt. 5. Lizenzen werden zugewiesen. 6. Endgerät wird bereitgestellt. 7. Sicherheitsmaßnahmen werden eingerichtet. 8. Zugriffe werden getestet. 9. Arbeitsplatz wird übergeben. 10. Arbeitsfähigkeit wird bestätigt. Wird nur die Kontoanlage betrachtet, können andere notwendige Schritte übersehen werden. Der technische Output: > Das Benutzerkonto wurde erstellt. bedeutet noch nicht automatisch das Outcome: > Der neue Mitarbeiter kann seine Aufgaben ausführen. --- **Übergaben** An Übergaben entstehen häufig: - Wartezeiten, - Informationsverluste, - Missverständnisse, - doppelte Arbeit, - und unklare Verantwortlichkeiten. Beispiele: - Die Personalabteilung meldet einen Eintritt ohne Funktionsbeschreibung. - Der Service Desk weist ein Ticket ohne Diagnoseinformationen weiter. - Ein Change wird umgesetzt, aber das Monitoring-Team wird nicht informiert. - Ein Lieferant erklärt seine Komponente für funktionsfähig, obwohl der gesamte Service weiterhin gestört ist. - Eine Lösung wird gefunden, aber nicht in der Wissensdatenbank dokumentiert. Übergaben sollten deshalb geprüft werden auf: - benötigte Informationen, - eindeutige Verantwortung, - erwartete Ergebnisse, - Zeitpunkte, - technische Schnittstellen, - und Rückmeldungen. --- **Engpässe und Wartezeiten** Ein Value Stream kann durch Engpässe verlangsamt werden. Mögliche Ursachen sind: - fehlende Informationen, - unklare Freigaben, - begrenzte Fachkenntnisse, - unnötige Genehmigungsstufen, - manuelle Dateneingaben, - technische Medienbrüche, - überlastete Teams, - oder Abhängigkeiten von einzelnen Personen. Nicht jede lange Gesamtdauer entsteht durch langsame Ausführung. Häufig besteht ein großer Teil aus Wartezeit. Beispiel: | Schritt | Bearbeitungszeit | Wartezeit | |---|---:|---:| | Anforderung prüfen | 15 Minuten | 1 Tag | | Freigabe erteilen | 5 Minuten | 2 Tage | | Konto erstellen | 10 Minuten | 4 Stunden | | Zugriff testen | 15 Minuten | 1 Tag | Die tatsächliche Bearbeitungszeit beträgt weniger als eine Stunde. Der gesamte Durchlauf dauert trotzdem mehrere Tage. --- **Kontrollen im Arbeitsfluss** Kontrollen können notwendig sein für: - Sicherheit, - Qualität, - Risiko, - Freigabe, - Nachvollziehbarkeit, - und gesetzliche Anforderungen. Sie sollten jedoch einen klaren Zweck besitzen. Zu prüfen ist: - Welches Risiko behandelt die Kontrolle? - Ist sie an der richtigen Stelle? - Wird sie doppelt durchgeführt? - Ist eine Automatisierung möglich? - Passt ihr Umfang zum Risiko? - Erzeugt sie unnötige Wartezeit? - Werden Ergebnisse der Kontrolle verwendet? - Kann sie umgangen werden? > **Typischer Fehler** > > Zusätzliche Freigaben werden eingeführt, nachdem ein Fehler aufgetreten ist. > > Später wird nicht mehr geprüft, ob sie das Risiko tatsächlich reduzieren oder nur den Arbeitsfluss verlangsamen. --- **Prozesse dürfen nicht zum Selbstzweck werden** Ein Prozess ist kein Wert an sich. Er soll ein benötigtes Outcome unterstützen. Anzeichen für einen ungeeigneten Prozess können sein: - Mitarbeiter umgehen den offiziellen Ablauf regelmäßig. - Informationen werden mehrfach erfasst. - Pflichtfelder enthalten bedeutungslose Standardtexte. - Genehmigungen erfolgen ohne tatsächliche Prüfung. - der Ablauf ist nur wenigen Personen verständlich. - Ergebnisse werden nicht gemessen. - Ausnahmen werden häufiger als der Standardfall. - Benutzer müssen denselben Sachverhalt mehrfach erklären. - jeder Vorgang wird gleich behandelt, obwohl die Risiken unterschiedlich sind. --- **Messung von Wertströmen und Prozessen** Mögliche Messgrößen sind: - Durchlaufzeit, - Bearbeitungszeit, - Wartezeit, - Anzahl der Übergaben, - Fehlerquote, - Nacharbeit, - Erfolgsquote, - Abbruchquote, - Benutzererfahrung, - Kosten, - und erreichte Outcomes. Eine einzelne Kennzahl reicht häufig nicht aus. Beispiel: Eine kurze Ticketbearbeitungszeit kann positiv sein. Sie kann aber auch entstehen, weil Tickets: - voreilig geschlossen, - an andere Teams weitergegeben, - oder nur oberflächlich bearbeitet werden. Messgrößen sollten deshalb gemeinsam und im Kontext betrachtet werden. --- **Leitfragen zu Value Streams and Processes** - Welches Outcome soll erreicht werden? - Wo beginnt und endet der Wertstrom? - Welche Schritte sind tatsächlich notwendig? - Welche Teams, Practices und Lieferanten sind beteiligt? - Wo entstehen Übergaben? - Welche Informationen werden benötigt? - Wo entstehen Wartezeiten oder Nacharbeit? - Welche Kontrollen sind notwendig? - Welche Schritte erzeugen keinen erkennbaren Nutzen? - Wo bestehen Engpässe? - Welche Tätigkeiten können vereinheitlicht oder automatisiert werden? - Wie wird der Erfolg aus Sicht der Stakeholder geprüft? - Wie fließt Feedback in Verbesserungen ein? --- **Zusammenwirken der vier Dimensionen** Die vier Dimensionen beeinflussen sich gegenseitig. | Veränderung | Mögliche Auswirkungen auf andere Dimensionen | |---|---| | neues Ticketsystem | Schulungsbedarf, Rollen, Datenmigration, Lieferantenvertrag und angepasste Prozesse | | Outsourcing des Service Desk | neue Schnittstellen, Verantwortlichkeiten, technische Zugänge und Eskalationswege | | Automatisierung der Benutzeranlage | Datenqualität, Freigaben, Rollen, Sicherheitskontrollen und Prozessänderungen | | Einführung einer Cloud-Plattform | neue Fähigkeiten, Verträge, Integrationen, Datenflüsse und Supportprozesse | | Änderung eines Incident-Prozesses | Werkzeugkonfiguration, Schulung, Lieferanteneinbindung und neue Messgrößen | | Einsatz von KI | Datenanforderungen, Governance, Kompetenzen, Lieferantenrisiken und Kontrollabläufe | > **Merke** > > Eine Änderung in nur einer Dimension ist in der Praxis selten auf diese eine Dimension begrenzt. --- **Praxisbeispiel: Einführung eines neuen Ticketsystems** Eine Organisation möchte ihr bisheriges Ticketsystem ersetzen. **Organizations and People** - Welche Teams verwenden das System? - Welche Rollen und Berechtigungen werden benötigt? - Welche Schulungen sind notwendig? - Wer administriert das System? - Wer verantwortet Kategorien, Vorlagen und Automatisierungen? - Wie werden Benutzer und Supportmitarbeiter einbezogen? **Information and Technology** - Welche Daten müssen übernommen werden? - Welche Schnittstellen bestehen? - Wie werden Identitäten und Berechtigungen integriert? - Welche Sicherheits- und Datenschutzanforderungen gelten? - Wie werden Backups, Protokollierung und Monitoring umgesetzt? - Welche Automatisierungen werden benötigt? **Partners and Suppliers** - Welcher Anbieter stellt die Lösung bereit? - Welche Support- und Verfügbarkeitsleistungen gelten? - Wie werden Daten exportiert? - Welche Unterauftragnehmer sind beteiligt? - Wie erfolgen Eskalationen? - Wie kann das System später abgelöst werden? **Value Streams and Processes** - Welche Vorgangsarten werden benötigt? - Wie laufen Incident, Service Request, Problem und Change durch das System? - Welche Pflichtinformationen sind sinnvoll? - Wo bestehen heute unnötige Übergaben? - Welche Abläufe sollen vereinfacht werden? - Welche Kennzahlen werden benötigt? Wird nur die Technologie ausgewählt, können die anderen drei Dimensionen später zu erheblichen Problemen führen. --- **Praxisbeispiel: wiederkehrender VPN-Ausfall** Mehrere Benutzer verlieren regelmäßig ihre VPN-Verbindung. **Organizations and People** - Wer koordiniert die Untersuchung? - Besitzen Service Desk und Netzwerkteam ausreichendes Wissen? - Sind Verantwortlichkeiten zwischen interner IT und Provider klar? **Information and Technology** - Welche Protokolle und Monitoring-Daten liegen vor? - Welche VPN-Komponenten, Zertifikate und Identitätsdienste sind beteiligt? - Sind die Daten für eine Ursachenanalyse ausreichend? **Partners and Suppliers** - Ist ein Internet- oder VPN-Provider beteiligt? - Welche Support- und Eskalationswege gelten? - Welche Nachweise benötigt der Provider? **Value Streams and Processes** - Werden ähnliche Incidents miteinander verknüpft? - Wird Problem Management einbezogen? - Wie werden Benutzer informiert? - Wie wird eine dauerhafte Korrektur geplant und kontrolliert umgesetzt? Eine rein technische Einzelbehandlung kann den Service kurzfristig wiederherstellen. Die ganzheitliche Betrachtung unterstützt zusätzlich eine nachhaltige Verbesserung. --- **Praxisbeispiel: Backup und Wiederherstellung** **Organizations and People** - Wer überwacht Sicherungen? - Wer darf Wiederherstellungen anfordern? - Wer führt Tests durch? - Wer entscheidet bei möglichem Datenverlust? **Information and Technology** - Welche Systeme und Daten werden gesichert? - Sind Sicherungen verschlüsselt und geschützt? - Funktionieren Wiederherstellungen? - Welche RPO- und RTO-Anforderungen bestehen? **Partners and Suppliers** - Wird ein Cloud- oder Backup-Anbieter verwendet? - Welche Leistungen sind zugesichert? - Wie können Daten bei Anbieterwechsel zurückgeführt werden? - Welche Supportwege bestehen? **Value Streams and Processes** - Wie werden neue Systeme in die Sicherung aufgenommen? - Wie werden Fehler behandelt? - Wie laufen Wiederherstellungstests ab? - Wie werden Ergebnisse und Verbesserungen dokumentiert? > **Merke** > > Backup ist nicht nur eine Technologie. > > Wiederherstellbarkeit entsteht durch das Zusammenspiel aller vier Dimensionen. --- **Die vier Dimensionen bei einem Incident** | Dimension | Beispielhafte Fragen | |---|---| | **Organizations and People** | Wer koordiniert, entscheidet, analysiert und kommuniziert? | | **Information and Technology** | Welche Systeme, Daten, Protokolle und Abhängigkeiten sind betroffen? | | **Partners and Suppliers** | Welche Anbieter müssen beteiligt oder eskaliert werden? | | **Value Streams and Processes** | Wie erfolgt Erfassung, Priorisierung, Wiederherstellung, Kommunikation und Abschluss? | --- **Die vier Dimensionen bei einem Change** | Dimension | Beispielhafte Fragen | |---|---| | **Organizations and People** | Wer beantragt, bewertet, autorisiert, implementiert und prüft? | | **Information and Technology** | Welche Komponenten, Daten, Schnittstellen und Sicherheitsmaßnahmen sind betroffen? | | **Partners and Suppliers** | Werden Hersteller, Provider oder Wartungspartner benötigt? | | **Value Streams and Processes** | Wie erfolgen Bewertung, Test, Autorisierung, Umsetzung, Rückfall und Erfolgskontrolle? | --- **Die vier Dimensionen bei einer Verbesserung** | Dimension | Beispielhafte Fragen | |---|---| | **Organizations and People** | Welche Fähigkeiten, Rollen oder kulturellen Veränderungen werden benötigt? | | **Information and Technology** | Welche Daten belegen das Problem und welche Technologie unterstützt die Verbesserung? | | **Partners and Suppliers** | Welche externen Beiträge oder Vertragsänderungen sind notwendig? | | **Value Streams and Processes** | Welcher Arbeitsfluss wird verbessert und wie wird die Wirkung gemessen? | --- **Typische Fehler** **Fehler 1: Nur Technik betrachten** Eine Organisation kauft eine neue Plattform, ohne Rollen, Fähigkeiten, Support und Arbeitsabläufe vorzubereiten. --- **Fehler 2: Nur Prozesse dokumentieren** Abläufe werden beschrieben, aber notwendige Informationen, Technologien und Kompetenzen fehlen. --- **Fehler 3: Lieferanten nicht als Teil des Service betrachten** Externe Abhängigkeiten werden erst berücksichtigt, wenn ein Incident eskaliert. --- **Fehler 4: Menschen als austauschbare Ressourcen behandeln** Benötigte Fähigkeiten, Erfahrungen, Motivation und Zusammenarbeit werden nicht berücksichtigt. --- **Fehler 5: Jede Dimension getrennt optimieren** Ein Team verbessert seine eigene Kennzahl, verschlechtert aber den gesamten Wertstrom. --- **Fehler 6: Alle Situationen gleich ausführlich prüfen** Kleine Standardtätigkeiten werden unnötig kompliziert, während kritische Vorhaben nicht risikogerecht vertieft werden. --- **Fehler 7: Werkzeuge mit Fähigkeiten verwechseln** Eine Organisation besitzt eine Funktion im Ticketsystem, hat aber keine wirksame Arbeitsweise und keine eindeutigen Verantwortlichkeiten dafür. --- **Fehler 8: Verträge nur beim Einkauf betrachten** Betrieb, Support, Sicherheit, Eskalation und Ausstieg werden nicht ausreichend einbezogen. --- **Fehler 9: Datenmenge mit Informationsqualität verwechseln** Viele Kennzahlen werden gesammelt, liefern aber keine Grundlage für Entscheidungen oder Verbesserungen. --- **Fehler 10: Prozesse an Teamgrenzen enden lassen** Jedes Team bearbeitet nur seinen Teil, während niemand das Ende-zu-Ende-Outcome verantwortet. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten häufig hauptsächlich in der technischen Dimension. Ihre Aufgaben beeinflussen jedoch immer wieder alle vier Dimensionen. Beispiel: neuer Server | Tätigkeit | Betroffene Dimension | |---|---| | Server installieren und konfigurieren | Information and Technology | | Zuständigkeit und Betrieb klären | Organizations and People | | Hardware-, Software- oder Cloud-Anbieter einbinden | Partners and Suppliers | | Bereitstellung, Change, Monitoring und Support einordnen | Value Streams and Processes | Vor einer technischen Maßnahme sind deshalb zusätzliche Fragen sinnvoll: - Welcher Service hängt von der Komponente ab? - Wer trägt Verantwortung? - Wer muss informiert werden? - Welche Informationen müssen dokumentiert werden? - Welche Lieferanten sind beteiligt? - Welche Arbeitsabläufe werden verändert? - Wie wird der Erfolg aus Benutzersicht geprüft? - Welche langfristigen Betriebs- und Supportaufgaben entstehen? --- **30-Sekunden-Prüfung** Bei einer neuen Aufgabe kannst du alle vier Dimensionen mit vier Kurzfragen prüfen: 1. **Menschen:** Wer ist beteiligt, verantwortlich und ausreichend befähigt? 2. **Technologie:** Welche Informationen, Systeme und technischen Abhängigkeiten werden benötigt? 3. **Partner:** Welche externen Anbieter und vertraglichen Abhängigkeiten bestehen? 4. **Arbeitsfluss:** Wie gelangt die Aufgabe vom Bedarf zum überprüften Outcome? Diese Kurzprüfung ersetzt keine notwendige Detailanalyse. Sie hilft jedoch dabei, eine Dimension nicht vollständig zu übersehen. --- **Checkliste zu Organizations and People** - [ ] Sind Rollen und Verantwortlichkeiten eindeutig? - [ ] Sind Entscheidungs- und Eskalationswege bekannt? - [ ] Sind notwendige Fähigkeiten vorhanden? - [ ] Besteht ausreichende Kapazität? - [ ] Sind Vertretungen geregelt? - [ ] Funktioniert die Zusammenarbeit zwischen Teams? - [ ] Werden Wissen und Erfahrungen geteilt? - [ ] Unterstützt die Kultur offene Kommunikation und Verbesserung? - [ ] Verstehen die Beteiligten das erwartete Outcome? --- **Checkliste zu Information and Technology** - [ ] Sind benötigte Informationen verfügbar und aktuell? - [ ] Ist die Verantwortung für Datenqualität geklärt? - [ ] Passen Technologien und Architektur zum Bedarf? - [ ] Sind Schnittstellen und Abhängigkeiten dokumentiert? - [ ] Sind Informationssicherheit und Datenschutz berücksichtigt? - [ ] Sind Backup und Wiederherstellung vorbereitet? - [ ] Werden Systeme angemessen überwacht? - [ ] Sind Automatisierungen kontrollierbar? - [ ] Sind technische Schulden und Lebenszyklusrisiken bekannt? --- **Checkliste zu Partners and Suppliers** - [ ] Sind alle relevanten Lieferanten bekannt? - [ ] Sind Leistungsumfang und Verantwortlichkeiten eindeutig? - [ ] Passen Verträge zu den benötigten Outcomes? - [ ] Sind Sicherheits- und Datenschutzanforderungen geregelt? - [ ] Bestehen bekannte Ausfall- oder Konzentrationsrisiken? - [ ] Sind Support- und Eskalationswege vorbereitet? - [ ] Werden Lieferantenleistungen überwacht? - [ ] Bleiben notwendige interne Fähigkeiten erhalten? - [ ] Besteht eine Ausstiegs- und Übergangsplanung? --- **Checkliste zu Value Streams and Processes** - [ ] Ist das gewünschte Outcome eindeutig? - [ ] Sind Anfang und Ende des Wertstroms bekannt? - [ ] Sind notwendige Aktivitäten und Verantwortlichkeiten geklärt? - [ ] Sind Übergaben und Informationsflüsse sichtbar? - [ ] Werden Wartezeiten und Engpässe erkannt? - [ ] Besitzen Kontrollen einen nachvollziehbaren Zweck? - [ ] Werden unnötige Schritte vermieden? - [ ] Unterstützen Prozesse den gesamten Wertstrom? - [ ] Werden Ergebnisse und Stakeholdererfahrung geprüft? - [ ] Fließt Feedback in Continual Improvement ein? --- **Gesamtcheck für ein Produkt oder einen Service** - [ ] Wurden alle vier Dimensionen berücksichtigt? - [ ] Sind die Dimensionen aufeinander abgestimmt? - [ ] Wurden Outcomes, Kosten und Risiken betrachtet? - [ ] Wurde die Erfahrung der relevanten Stakeholder berücksichtigt? - [ ] Sind betriebliche und gesetzliche Vorgaben einbezogen? - [ ] Sind technische und organisatorische Abhängigkeiten sichtbar? - [ ] Sind Verantwortung und Entscheidungsbefugnisse eindeutig? - [ ] Sind Lieferantenbeziehungen und Verträge geeignet? - [ ] Ist der Ende-zu-Ende-Wertstrom nachvollziehbar? - [ ] Sind Betrieb, Support, Sicherheit und Verbesserung vorbereitet? - [ ] Wird der Erfolg anhand des tatsächlichen Outcomes geprüft? --- **Schnellreferenz** | Dimension | Kurzfrage | |---|---| | **Organizations and People** | Wer wird benötigt und wie arbeiten die Beteiligten zusammen? | | **Information and Technology** | Welche Informationen und Technologien ermöglichen das Outcome? | | **Partners and Suppliers** | Welche externen Leistungen und Abhängigkeiten bestehen? | | **Value Streams and Processes** | Wie fließt die Arbeit vom Bedarf zum Ergebnis? | --- **Zusammenfassende Darstellung** > **Organizations and People** > Rollen · Fähigkeiten · Kapazität · Kommunikation · Kultur > > **Information and Technology** > Daten · Wissen · Anwendungen · Infrastruktur · Integration · Automatisierung > > **Partners and Suppliers** > Leistungen · Verträge · Zusammenarbeit · Abhängigkeiten · Ausstieg > > **Value Streams and Processes** > Aktivitäten · Übergaben · Kontrollen · Arbeitsfluss · Outcomes > > ↓ > > ganzheitliches digitales Produkt- und Service-Management > > ↓ > > bessere Outcomes und gemeinsam ermöglichter Wert --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.4 Governance und Verantwortlichkeit - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 2.10 ITIL an den eigenen Kontext anpassen - Supplier Management - Information Security Management - 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) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [PeopleCert: ITIL Experience – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-experience-version-5-4177) - [PeopleCert: Supporting the ITIL evolution with the new Transition module](https://www.peoplecert.org/news-and-announcements/itil-version-5-transition-for-existing-practitioners) - [ITIL: ITIL Capability and Maturity Assessment](https://www.itil.com/organizations/capability-maturity-assessment) **Einordnung** ITIL Version 5 verwendet die folgenden vier Dimensionen des Produkt- und Service-Managements: - Organizations and People - Information and Technology - Partners and Suppliers - Value Streams and Processes Die offiziellen ITIL-Version-5-Grundlagen beschreiben die vier Dimensionen als Grundlage einer ganzheitlichen Betrachtung digitaler Produkte und Services. Die ausführlichen Leitfragen, Beispiele, Checklisten und technischen Einordnungen auf dieser Seite sind zusätzliche herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation verbindlichen Arbeitsabläufe dar. Konkrete Rollen, Technologien, Lieferantenmodelle, Prozesse und Kontrollen müssen an den jeweiligen Kontext angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.6 Der Product and Service Lifecycle > **Kurz erklärt** > > Der ITIL Product and Service Lifecycle beschreibt den gemeinsamen Lebenszyklus digitaler Produkte und Services. > > Er verbindet Produktentwicklung, Beschaffung, technische Umsetzung, Betrieb, Bereitstellung und Unterstützung in einem gemeinsamen Modell. > > Die acht Lifecycle-Aktivitäten sind: > > 1. **Discover** > 2. **Design** > 3. **Acquire** > 4. **Build** > 5. **Transition** > 6. **Operate** > 7. **Deliver** > 8. **Support** > > Die Aktivitäten bilden keinen starren linearen Ablauf. Sie können sich überschneiden, wiederholt werden und sich gegenseitig beeinflussen. --- **Warum ein gemeinsamer Lebenszyklus notwendig ist** Digitale Produkte und Services wurden in Organisationen häufig getrennt betrachtet. Produktteams konzentrierten sich beispielsweise auf: - Anforderungen, - Funktionen, - Entwicklung, - Releases, - Roadmaps, - und technische Weiterentwicklung. Serviceteams konzentrierten sich dagegen auf: - Betrieb, - Servicequalität, - Benutzerunterstützung, - Incidents, - Service Requests, - Service Levels, - und Kommunikation. Diese Trennung kann zu Problemen führen. Beispiele: - Eine neue Funktion wird veröffentlicht, ohne den Service Desk vorzubereiten. - Eine Anwendung wird entwickelt, ohne Monitoring und Wiederherstellung ausreichend zu berücksichtigen. - Ein Produktteam bewertet den Release als erfolgreich, obwohl Benutzer den Service nicht zuverlässig verwenden können. - Betriebserfahrungen erreichen die Produktentwicklung nicht. - Anforderungen an Sicherheit, Support und Servicequalität werden erst kurz vor der Einführung betrachtet. - Technische Schulden werden zwischen Entwicklung und Betrieb hin- und hergeschoben. - Produkt- und Serviceteams verwenden unterschiedliche Ziele und Kennzahlen. ITIL Version 5 verbindet beide Perspektiven deshalb in einem gemeinsamen Product and Service Lifecycle. > **Merke** > > Produkt und Service sind keine voneinander unabhängigen Alternativen. > > Sie sind zwei miteinander verbundene Perspektiven auf eine technologiebasierte Lösung. --- **Produkt- und Serviceperspektive** Die Produktperspektive betrachtet unter anderem: - Fähigkeiten und Funktionen, - technische Architektur, - Roadmap, - Entwicklung, - Investitionen, - Versionen, - technische Schulden, - und den Lebenszyklus der Lösung. Die Serviceperspektive betrachtet unter anderem: - Nutzung, - Outcomes, - Servicequalität, - Erfahrung, - Support, - Servicebeziehungen, - Verfügbarkeit, - Kontinuität, - und die Zusammenarbeit mit Stakeholdern. Beispiel: VPN-Lösung | Produktperspektive | Serviceperspektive | |---|---| | VPN-Gateway und Clientsoftware | sicherer Fernzugriff für Benutzer | | Authentifizierungsfunktionen | verständlicher und zuverlässiger Anmeldevorgang | | unterstützte Betriebssysteme | Nutzbarkeit auf den benötigten Endgeräten | | technische Kapazität | ausreichende Leistung für die Benutzer | | Softwareversionen | kontrollierte und möglichst störungsarme Aktualisierung | | Protokollierung | Unterstützung bei Störungen und Sicherheitsanalysen | | Hersteller-Roadmap | langfristige Nutzbarkeit des Fernzugriffs | Beide Perspektiven müssen gemeinsam betrachtet werden. Eine technisch leistungsfähige VPN-Plattform ermöglicht noch keinen verlässlichen Fernzugriffsservice, wenn: - Benutzer nicht eingerichtet sind, - Berechtigungen fehlen, - der Support nicht vorbereitet wurde, - keine verständliche Anleitung existiert, - die Internetverbindung ungeeignet ist, - oder Störungen nicht wirksam bearbeitet werden. --- **Die acht Lifecycle-Aktivitäten im Überblick** | Aktivität | Zentrale Aufgabe | |---|---| | **Discover** | Bedürfnisse, Chancen, Ausgangslage und Umfeld verstehen | | **Design** | geeignete Produkte, Services und Lösungen gestalten | | **Acquire** | benötigte Ressourcen, Produkte, Leistungen und Fähigkeiten beschaffen oder zuordnen | | **Build** | Lösungen erstellen, konfigurieren, integrieren und testen | | **Transition** | neue oder geänderte Bestandteile kontrolliert in die vorgesehene Nutzung überführen | | **Operate** | Produkte, Plattformen und technische Fähigkeiten zuverlässig betreiben | | **Deliver** | Services und Serviceangebote für Stakeholder bereitstellen und steuern | | **Support** | Benutzer, Kunden, Produkte und Services bei Fragen, Anfragen und Störungen unterstützen | Die Beschreibungen in dieser Tabelle sind praxisnahe Zusammenfassungen. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen dar. --- **Lifecycle-Aktivitäten statt starrer Phasen** Die Begriffe können zunächst den Eindruck einer festen Reihenfolge vermitteln: > Discover → Design → Acquire → Build → Transition → Operate → Deliver → Support Das Modell ist jedoch nicht als starres Wasserfallmodell gedacht. Jede Aktivität kann: - Erkenntnisse für andere Aktivitäten liefern, - erneut erforderlich werden, - gleichzeitig mit anderen Aktivitäten stattfinden, - Rücksprünge auslösen, - und unterschiedliche Versionen eines Produkts oder Service betreffen. Beispiel: Während Version 1 einer Anwendung betrieben, bereitgestellt und unterstützt wird, kann gleichzeitig: - Version 2 gestaltet werden, - eine neue Komponente beschafft werden, - ein Update erstellt und getestet werden, - und eine zukünftige Version untersucht werden. | Produkt- oder Serviceversion | Mögliche aktuelle Aktivität | |---|---| | Version 1.0 | Operate, Deliver und Support | | Version 1.1 | Build und Test | | Version 1.2 | Design | | zukünftige Hauptversion | Discover | | abzulösende Altversion | Transition und Operate | > **Merke** > > Ein Produkt oder Service befindet sich nicht dauerhaft nur in einer einzigen Lifecycle-Aktivität. --- **Transitions können zwischen verschiedenen Aktivitäten stattfinden** Transition ist nicht ausschließlich ein einmaliger Schritt zwischen Build und Operate. Eine kontrollierte Überführung kann an unterschiedlichen Stellen notwendig sein. Beispiele: - Übergabe neuer Erkenntnisse von Discover an Design - Überführung eines Entwurfs in Beschaffung oder Entwicklung - Übergang von einer Testumgebung in eine Pilotumgebung - Übergang von einem Pilotbetrieb in die allgemeine Nutzung - Übergabe einer neuen Funktion an Betrieb und Support - Migration von einem alten zu einem neuen Anbieter - Außerbetriebnahme einer bisherigen Produktversion - Überführung einer Zwischenlösung in eine dauerhafte Lösung Die konkrete Form einer Transition hängt vom jeweiligen Produkt, Service, Risiko und Wertstrom ab. > **Wichtig** > > Transition bedeutet nicht, dass ein Team seine Arbeit beendet und die Verantwortung vollständig an ein anderes Team abgibt. > > Produkt-, Service-, Betriebs- und Supportverantwortung müssen über den Übergang hinweg zusammenwirken. --- **Lifecycle, Value System und Value Stream unterscheiden** | Begriff | Bedeutung | |---|---| | **ITIL Value System** | verbindet die übergeordneten Bestandteile der Organisation zur Wertschöpfung | | **Product and Service Lifecycle** | beschreibt acht gemeinsame Aktivitäten über den Lebenszyklus digitaler Produkte und Services | | **Value Chain** | flexibles operatives Modell innerhalb des ITIL Value Systems | | **Value Stream** | konkrete Abfolge von Schritten zur Erreichung eines bestimmten Outcomes | | **Management Practice** | organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck | | **Prozess** | strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen | | **Projekt** | zeitlich begrenztes Vorhaben zur Erreichung definierter Ziele | Beispiel: Einführung einer neuen Monitoring-Plattform - Der **Lifecycle** hilft, alle Aktivitäten von Discovery bis Support zu betrachten. - Der **Value Stream** beschreibt den konkreten Weg von der Anforderung bis zur wirksam eingesetzten Plattform. - Die **Practices** stellen Fähigkeiten wie Monitoring and Event Management, Change Management und Supplier Management bereit. - Ein **Projekt** kann Teile der Einführung zeitlich organisieren. - Das **Value System** verbindet Governance, Prinzipien, Practices, Wertschöpfung und Verbesserung. --- **Lifecycle und Projektlebenszyklus unterscheiden** Ein Projekt besitzt normalerweise: - einen definierten Anfang, - festgelegte Ziele, - einen begrenzten Umfang, - einen Zeitplan, - und ein formales Ende. Ein digitales Produkt oder ein Service besteht häufig über das Projekt hinaus. Beispiel: Ein Projekt führt eine neue E-Mail-Plattform ein. Nach Projektende müssen weiterhin durchgeführt werden: - Betrieb, - Monitoring, - Incident-Bearbeitung, - Benutzerunterstützung, - Kapazitätsplanung, - Sicherheitsaktualisierungen, - Lieferantensteuerung, - Verbesserungen, - und spätere Ablösung. > **Typischer Fehler** > > Die Produkt- und Serviceverantwortung endet mit dem Projektabschluss. > > Dadurch bleiben Betrieb, Support, technische Schulden und langfristige Weiterentwicklung ungeklärt. --- **1. Discover** > **Zentrale Frage** > > Was wird benötigt, warum wird es benötigt und welche Ausgangslage besteht? Discover dient dazu, Bedürfnisse, Chancen, Probleme und Rahmenbedingungen zu verstehen. Mögliche Auslöser sind: - neue Benutzeranforderung, - geändertes Geschäftsziel, - wiederkehrender Incident, - Sicherheitsrisiko, - technische Schulden, - neue gesetzliche Anforderung, - Rückmeldung von Kunden, - neue Technologie, - Lieferantenänderung, - oder mögliches Verbesserungspotenzial. Discover sollte nicht nur bestätigen, was ein einzelner Anforderer bereits als Lösung vorgeschlagen hat. Zuerst sollte das zugrunde liegende Bedürfnis verstanden werden. Beispiel: Anforderung: > Wir benötigen einen neuen Server. Mögliche zugrunde liegende Bedürfnisse: - zusätzliche Kapazität, - Ablösung eines nicht unterstützten Systems, - Trennung verschiedener Anwendungen, - bessere Verfügbarkeit, - neue Testumgebung, - oder Erfüllung einer Sicherheitsanforderung. Erst nach dieser Klärung kann bewertet werden, ob ein neuer Server tatsächlich die geeignete Lösung darstellt. --- **Typische Inhalte von Discover** - Bedürfnisse und Erwartungen - betroffene Stakeholder - gewünschte Outcomes - aktuelle Probleme - vorhandene Produkte und Services - technische und organisatorische Ausgangslage - Chancen und Risiken - Markt- und Technologieentwicklung - gesetzliche und vertragliche Anforderungen - Nachhaltigkeitsanforderungen - Benutzer- und Kundenerfahrung - vorhandene Daten und Messwerte - mögliche Einschränkungen - Annahmen und Unsicherheiten --- **Leitfragen zu Discover** - Welches Problem oder Bedürfnis besteht? - Wer nimmt den erwarteten Wert wahr? - Welches Outcome soll erreicht werden? - Wie sieht der aktuelle Zustand aus? - Was funktioniert bereits? - Welche Daten belegen das Problem? - Welche Stakeholder sind beteiligt? - Welche gesetzlichen und betrieblichen Vorgaben gelten? - Welche Chancen und Risiken bestehen? - Welche Annahmen müssen überprüft werden? - Welche Auswirkungen hätte es, nichts zu verändern? - Welche bestehenden Produkte oder Services könnten angepasst werden? - Muss überhaupt eine neue Lösung entstehen? --- **Mögliche Ergebnisse von Discover** - verständlich beschriebener Bedarf - bekannte Stakeholder - gewünschte Outcomes - erste Wert- und Risikobewertung - dokumentierte Ausgangslage - bekannte Einschränkungen - erste Lösungsoptionen - priorisierte Anforderungen - Entscheidung über weitere Untersuchung - Entscheidung, ein Vorhaben nicht weiterzuverfolgen > **Merke** > > Ein sinnvolles Ergebnis von Discover kann auch die Entscheidung sein, keine neue Lösung einzuführen. --- **Praxisbeispiel: wiederkehrende Anmeldeprobleme** Mehrere Benutzer können sich regelmäßig nicht anmelden. Eine vorschnelle Lösung wäre: > Der Verzeichnisdienst muss ersetzt werden. Discover untersucht zunächst: - Welche Benutzer sind betroffen? - Wann treten die Fehler auf? - Welche Fehlermeldungen erscheinen? - Welche Systeme sind beteiligt? - Gab es kürzlich Changes? - Sind DNS und Zeitsynchronisation stabil? - Liegen Probleme mit MFA oder Zertifikaten vor? - Sind Benutzerprozesse verständlich? - Besteht ein Kapazitätsproblem? - Welche bisherigen Maßnahmen wurden durchgeführt? Erst danach kann eine geeignete Designentscheidung getroffen werden. --- **Typische Fehler bei Discover** - Lösung festlegen, bevor das Problem verstanden wurde - nur mit einem Stakeholder sprechen - vorhandene Daten ignorieren - Benutzererfahrung nicht berücksichtigen - technische Symptome mit der eigentlichen Ursache verwechseln - bestehende Fähigkeiten und Lösungen übersehen - Unsicherheiten nicht dokumentieren - keine Kriterien für Erfolg definieren - jede technische Neuerung automatisch als Chance betrachten --- **2. Design** > **Zentrale Frage** > > Wie müssen Produkt und Service gestaltet werden, damit das gewünschte Outcome sicher und nachhaltig unterstützt wird? Design übersetzt Bedürfnisse und Erkenntnisse in eine geeignete Gesamtlösung. Dabei werden nicht nur technische Funktionen gestaltet. Zu berücksichtigen sind ebenfalls: - Serviceerfahrung, - Betriebsmodell, - Support, - Sicherheit, - Wiederherstellung, - Informationen, - Prozesse, - Rollen, - Lieferanten, - und Lebenszyklusanforderungen. --- **Funktionale und nichtfunktionale Anforderungen** **Funktionale Anforderungen** beschreiben, was eine Lösung leisten soll. Beispiele: - Benutzer können sich anmelden. - Dateien können gemeinsam bearbeitet werden. - Administratoren können Berechtigungen verwalten. - Monitoring erkennt den Ausfall eines Dienstes. **Nichtfunktionale Anforderungen** beschreiben Eigenschaften und Qualitätsanforderungen. Beispiele: - Verfügbarkeit - Leistung - Skalierbarkeit - Sicherheit - Datenschutz - Wartbarkeit - Bedienbarkeit - Barrierefreiheit - Wiederherstellbarkeit - Protokollierung - Kompatibilität - Nachhaltigkeit > **Typischer Fehler** > > Die Funktionen werden gestaltet, während Betrieb, Support, Sicherheit und Wiederherstellung erst kurz vor der Einführung betrachtet werden. --- **Design betrachtet alle vier Dimensionen** **Organizations and People** - Welche Rollen und Fähigkeiten werden benötigt? - Wer verantwortet Produkt und Service? - Wie werden Benutzer und Supportmitarbeiter geschult? **Information and Technology** - Welche Architektur, Daten und Technologien werden benötigt? - Wie werden Integration, Sicherheit und Wiederherstellung gestaltet? **Partners and Suppliers** - Welche externen Leistungen werden benötigt? - Welche Anforderungen müssen Verträge und Supportvereinbarungen erfüllen? **Value Streams and Processes** - Wie erfolgen Bestellung, Bereitstellung, Nutzung, Support und Verbesserung? - Welche Übergaben und Kontrollen sind notwendig? --- **Leitfragen zu Design** - Welche Outcomes und Erfahrungen sollen unterstützt werden? - Welche Funktionen werden benötigt? - Welche Qualitätsanforderungen gelten? - Welche Sicherheits- und Datenschutzanforderungen bestehen? - Wie wird der Service betrieben und unterstützt? - Welche Abhängigkeiten und Schnittstellen bestehen? - Welche Daten werden verarbeitet? - Welche Kapazität und Verfügbarkeit werden benötigt? - Wie erfolgen Backup und Wiederherstellung? - Welche Rollen und Fähigkeiten werden benötigt? - Welche Lieferanten werden beteiligt? - Wie wird die Lösung überwacht? - Wie werden Updates und Changes durchgeführt? - Wie kann die Lösung später erweitert oder abgelöst werden? - Wie wird der Erfolg überprüft? --- **Betrieb und Support bereits im Design berücksichtigen** Ein Produkt sollte nicht erst nach seiner Entwicklung „betriebsfähig gemacht“ werden. Bereits im Design sollten unter anderem berücksichtigt werden: - Monitoring - Protokollierung - Fehlerdiagnose - Backup - Wiederherstellung - Kapazität - Verfügbarkeit - Patch- und Updateverfahren - Zugriffskontrolle - Supportinformationen - Service-Desk-Vorbereitung - bekannte Fehlerszenarien - Eskalationswege - Dokumentation - Außerbetriebnahme > **Merke** > > Operability und Supportability sind keine nachträglichen Zusatzfunktionen. > > Sie gehören zur Gestaltung eines nutzbaren und nachhaltigen digitalen Produkts und Service. --- **Mögliche Ergebnisse von Design** - Lösungsentwurf - Produkt- und Serviceanforderungen - Architektur - Prototyp - Serviceangebot - Sicherheitskonzept - Supportmodell - Monitoring-Konzept - Betriebs- und Wiederherstellungskonzept - Lieferantenanforderungen - Teststrategie - Transition-Planung - Erfolgskriterien - Plan für spätere Ablösung --- **Typische Fehler bei Design** - nur sichtbare Funktionen gestalten - Benutzer und Support nicht einbeziehen - Betriebsanforderungen zu spät berücksichtigen - Sicherheitskontrollen nachträglich ergänzen - keine Exit- oder Ablösungsplanung - Lieferantenabhängigkeiten übersehen - unklare Erfolgskriterien - unnötige Komplexität aufbauen - Design nicht anhand von Feedback überprüfen --- **3. Acquire** > **Zentrale Frage** > > Welche Produkte, Leistungen, Ressourcen und Fähigkeiten werden benötigt und wie werden sie beschafft oder bereitgestellt? Acquire umfasst die Beschaffung oder Zuordnung benötigter Bestandteile. Dazu können gehören: - Hardware - Software - Cloud-Services - Lizenzen - externe Dienstleistungen - Daten - Infrastrukturkapazität - Fachwissen - Schulungen - Personal - Entwicklungsleistungen - Supportverträge - und Lieferantenressourcen Acquire bedeutet nicht automatisch, dass etwas von einem externen Anbieter gekauft werden muss. Mögliche Entscheidungen sind: - selbst entwickeln - intern wiederverwenden - Standardprodukt kaufen - Cloud-Service abonnieren - Open-Source-Lösung einsetzen - Dienstleistung auslagern - gemeinsam mit einem Partner entwickeln - oder eine bestehende Fähigkeit erweitern --- **Make, Buy, Reuse oder Partner** | Möglichkeit | Beispiel | |---|---| | **Make** | eigene Anwendung oder Automatisierung entwickeln | | **Buy** | Standardsoftware oder Hardware beschaffen | | **Reuse** | vorhandene Plattform oder Komponente weiterverwenden | | **Subscribe** | Cloud- oder SaaS-Service abonnieren | | **Partner** | Lösung gemeinsam mit einem externen Partner entwickeln | | **Outsource** | Tätigkeit oder Servicebestandteil extern erbringen lassen | Die Entscheidung sollte nicht nur anhand des Anschaffungspreises erfolgen. Zu berücksichtigen sind beispielsweise: - benötigte Outcomes - Gesamtkosten - Geschwindigkeit - vorhandene Fähigkeiten - Integrationsaufwand - Sicherheit - Datenschutz - Lieferantenabhängigkeit - Datenportabilität - Wartung - Support - Skalierbarkeit - und spätere Ablösung --- **Leitfragen zu Acquire** - Welche Ressourcen und Fähigkeiten werden benötigt? - Was ist bereits vorhanden? - Was kann intern bereitgestellt werden? - Was muss extern beschafft werden? - Welche Lieferanten kommen infrage? - Welche Anforderungen müssen vertraglich geregelt werden? - Welche Lizenzen werden benötigt? - Welche Sicherheits- und Datenschutzanforderungen gelten? - Welche Abhängigkeiten entstehen? - Können Daten und Konfigurationen später exportiert werden? - Welche internen Fähigkeiten müssen erhalten bleiben? - Wie wird die Lieferantenleistung überwacht? - Was geschieht bei Vertragsende oder Lieferantenausfall? - Sind Beschaffungszeit und Verfügbarkeit realistisch? --- **Beschaffung ist mehr als Bestellung** Eine technische Bestellung allein stellt noch keine nutzbare Ressource bereit. Beispiel: neue Firewall Zusätzlich zur Hardware können benötigt werden: - Lizenzen - Supportvertrag - Rackplatz - Stromversorgung - Netzwerkanschlüsse - Managementzugang - Zertifikate - Administrationswissen - Ersatzteile - Monitoring - Dokumentation - Backup der Konfiguration - und ein Ablösungsplan > **Typischer Fehler** > > Der Kaufpreis wird geplant, während Betriebskosten, Lizenzen, Support und notwendige Fähigkeiten nicht berücksichtigt werden. --- **Lieferanten und Exit-Planung** Bei externen Leistungen sollte bereits während Acquire geprüft werden: - Wie werden Daten zurückgegeben? - Welche Exportformate existieren? - Welche Unterauftragnehmer werden eingesetzt? - Welche Support- und Eskalationswege gelten? - Welche Serviceziele werden zugesichert? - Welche Sicherheitsnachweise existieren? - Wie werden Vertragsänderungen behandelt? - Welche Kosten entstehen bei einer Migration? - Wie kann die Leistung später ersetzt werden? - Welche internen Kenntnisse müssen erhalten bleiben? --- **Mögliche Ergebnisse von Acquire** - beschaffte Produkte und Leistungen - zugewiesene interne Ressourcen - Lizenzen und Nutzungsrechte - Verträge und Vereinbarungen - Lieferantenbeziehungen - bereitgestellte Umgebungen - benötigte Fähigkeiten und Schulungen - bekannte Lieferantenrisiken - Exit- und Übergangsanforderungen - geprüfte Liefergegenstände --- **Typische Fehler bei Acquire** - nur den niedrigsten Preis bewerten - Betriebskosten übersehen - Fähigkeiten und Schulungen nicht einplanen - Supportanforderungen nicht vertraglich klären - Lieferantenabhängigkeit ignorieren - keine Datenportabilität vorsehen - Lizenzen falsch dimensionieren - Beschaffung und technische Integration nicht abstimmen - Exit-Planung auf später verschieben --- **4. Build** > **Zentrale Frage** > > Wie wird die entworfene Lösung erstellt, konfiguriert, integriert und überprüft? Build umfasst die praktische Erstellung und technische Umsetzung. Dazu können gehören: - Softwareentwicklung - Hardwareinstallation - Systemkonfiguration - Cloud-Bereitstellung - Integration - Datenmigration - Automatisierung - Erstellung von Schnittstellen - Konfiguration von Monitoring - Sicherheitsmaßnahmen - Dokumentation - und Tests Build bedeutet nicht ausschließlich Programmierung. Auch die Konfiguration einer Standardsoftware oder der Aufbau einer Infrastruktur kann Teil dieser Aktivität sein. --- **Build und Test gehören zusammen** Eine erstellte Lösung muss überprüft werden. Mögliche Testarten sind: - Funktionstest - Integrationstest - Sicherheitstest - Leistungstest - Wiederherstellungstest - Kompatibilitätstest - Benutzerakzeptanztest - Failover-Test - Migrationstest - Überwachungstest - Rückfalltest - und Test der Supportfähigkeit Tests sollten sich an Anforderungen und Risiken orientieren. > **Merke** > > Ein erfolgreicher Funktionstest beweist nicht automatisch, dass eine Lösung sicher, betreibbar, wiederherstellbar und für Benutzer geeignet ist. --- **Leitfragen zu Build** - Entspricht die Umsetzung dem Design? - Welche Komponenten müssen erstellt oder konfiguriert werden? - Welche Standards und Sicherheitsvorgaben gelten? - Welche Abhängigkeiten bestehen? - Wie werden Änderungen versioniert? - Welche Umgebungen werden verwendet? - Wie werden Zugangsdaten und Geheimnisse geschützt? - Welche Tests sind notwendig? - Sind Testdaten geeignet und zulässig? - Wie werden Fehler dokumentiert und korrigiert? - Wie wird die Konfiguration reproduzierbar? - Werden Betrieb, Monitoring und Support vorbereitet? - Ist die Dokumentation ausreichend? - Ist eine Rückfallmöglichkeit vorhanden? --- **Reproduzierbarkeit** Technische Lösungen sollten möglichst reproduzierbar aufgebaut werden. Geeignete Maßnahmen können sein: - dokumentierte Konfiguration - Versionsverwaltung - Infrastructure as Code - automatisierte Bereitstellung - standardisierte Images - Konfigurationsmanagement - automatisierte Tests - und nachvollziehbare Abhängigkeiten Reproduzierbarkeit unterstützt: - Wiederherstellung - Skalierung - Fehleranalyse - Tests - Sicherheit - und spätere Änderungen --- **Build umfasst Betriebsbereitschaft** Während Build sollten nicht nur Produktfunktionen erstellt werden. Ebenfalls vorzubereiten sind: - Monitoring - Alarmierung - Protokollierung - Backup - Wiederherstellung - Administrationszugänge - Sicherheitskontrollen - Betriebsdokumentation - Supportinformationen - bekannte Fehler - Kapazitätsgrenzen - und Eskalationsinformationen --- **Mögliche Ergebnisse von Build** - erstellte oder konfigurierte Lösung - integrierte Komponenten - getestete Produktversion - technische Dokumentation - Betriebsdokumentation - automatisierte Bereitstellung - bekannte Fehler und Einschränkungen - Testergebnisse - Sicherheitsnachweise - Monitoring und Protokollierung - vorbereitete Transition --- **Typische Fehler bei Build** - nur den Normalfall testen - produktive Änderungen manuell und undokumentiert durchführen - Betrieb und Support nicht einbeziehen - Konfiguration nicht versionieren - Zugangsdaten unsicher behandeln - keine Wiederherstellung testen - Test- und Produktivumgebung stark voneinander abweichen lassen - bekannte Fehler nicht dokumentieren - eine technisch fertige Lösung automatisch als einsatzbereit betrachten --- **5. Transition** > **Zentrale Frage** > > Wie wird eine neue oder geänderte Lösung kontrolliert in die vorgesehene Nutzung und Verantwortung überführt? Transition verbindet Entwicklung, Beschaffung und Aufbau mit der tatsächlichen Verwendung, dem Betrieb, der Bereitstellung und dem Support. Mögliche Bestandteile sind: - Change-Bewertung - Releaseplanung - Deployment - Datenmigration - Pilotbetrieb - Benutzerkommunikation - Schulung - Wissensübergabe - Betriebsfreigabe - Servicevalidierung - Rückfallplanung - und Erfolgskontrolle --- **Transition ist mehr als Deployment** Deployment beschreibt die technische Übertragung von Komponenten in eine Zielumgebung. Transition umfasst zusätzlich die organisatorische und servicebezogene Einsatzbereitschaft. | Deployment | Transition | |---|---| | Software wird installiert. | Produkt und Service werden kontrolliert in die Nutzung überführt. | | Konfiguration wird verteilt. | Betrieb, Support und Stakeholder sind vorbereitet. | | technische Komponente wird aktiviert. | Funktion, Erfahrung, Risiken und Outcomes werden überprüft. | | Daten werden migriert. | Datenqualität, Benutzerzugriff und Geschäftsabläufe werden validiert. | > **Merke** > > Technisch bereitgestellt bedeutet nicht automatisch betriebsbereit, supportfähig oder für Benutzer nutzbar. --- **Operational Readiness** Vor einer produktiven Nutzung sollte geprüft werden: - Ist die Lösung ausreichend getestet? - Ist Monitoring aktiv? - Sind Backup und Wiederherstellung vorbereitet? - Sind Rollen und Verantwortlichkeiten bekannt? - Ist der Service Desk informiert? - Existieren Support- und Eskalationswege? - Sind Dokumentationen verfügbar? - Wurden Benutzer informiert oder geschult? - Sind Lizenzen und Verträge gültig? - Ist die Sicherheitsfreigabe erfolgt? - Sind bekannte Einschränkungen akzeptiert? - Ist ein Rückfallplan vorhanden? - Wie wird der Erfolg nach der Einführung kontrolliert? --- **Leitfragen zu Transition** - Was wird überführt? - Welche Produkte und Services sind betroffen? - Welche Stakeholder müssen beteiligt werden? - Welche Risiken bestehen? - Welche Autorisierung ist erforderlich? - Wie wird die Einführung geplant? - Ist ein Pilot sinnvoll? - Welche Daten müssen migriert werden? - Welche Unterbrechungen können entstehen? - Wie werden Benutzer informiert? - Wie werden Betrieb und Support vorbereitet? - Welche Rückfallmöglichkeiten bestehen? - Wer entscheidet über Fortsetzung oder Abbruch? - Wie wird die erfolgreiche Nutzung bestätigt? - Welche Nacharbeiten sind notwendig? --- **Rückfall und Wiederherstellung** Ein Rückfallplan sollte möglichst klären: - Unter welchen Bedingungen wird zurückgefallen? - Wer darf die Entscheidung treffen? - Wie wird der vorherige Zustand wiederhergestellt? - Welche Datenänderungen müssen berücksichtigt werden? - Wie lange dauert der Rückfall? - Welche Benutzer sind betroffen? - Wie wird kommuniziert? - Wie wird das Ergebnis kontrolliert? Ein Rückfall ist nicht immer die beste oder technisch mögliche Option. Bei Datenmigrationen oder unumkehrbaren Änderungen kann stattdessen ein alternativer Wiederherstellungsplan notwendig sein. --- **Mögliche Ergebnisse von Transition** - kontrolliert eingeführte Produktversion - aktivierter Service - migrierte Daten - vorbereiteter Betrieb - vorbereiteter Support - geschulte Beteiligte - aktualisierte Dokumentation - validierte Servicefunktion - dokumentierte Einschränkungen - überwachte Einführungsphase - abgeschlossene oder geplante Nacharbeiten --- **Typische Fehler bei Transition** - Transition mit Installation gleichsetzen - Service Desk und Benutzer zu spät informieren - keine Betriebsbereitschaft prüfen - ungetestete Migration durchführen - Rückfallplan nur formal dokumentieren - Erfolg nur technisch prüfen - bekannte Fehler nicht kommunizieren - Verantwortungsübergabe ohne Wissenstransfer - direkt nach Deployment alle Beteiligten aus dem Vorhaben abziehen --- **6. Operate** > **Zentrale Frage** > > Wie werden Produkte, Plattformen und technische Fähigkeiten zuverlässig, sicher und wirtschaftlich betrieben? Operate betrachtet den laufenden technischen Betrieb. Dazu gehören beispielsweise: - Systembetrieb - Überwachung - Wartung - Kapazitätssteuerung - Verfügbarkeitsmanagement - Sicherheitsbetrieb - Backup - Wiederherstellung - Patchmanagement - Jobsteuerung - Verwaltung technischer Konfigurationen - und Behandlung betrieblicher Ereignisse Operate sorgt dafür, dass die technischen Fähigkeiten vorhanden bleiben, auf denen Services aufbauen. --- **Operate und Deliver unterscheiden** Operate konzentriert sich stärker auf den laufenden Betrieb der technischen Produkt- und Plattformbestandteile. Deliver konzentriert sich stärker darauf, Services und Serviceangebote für Stakeholder nutzbar bereitzustellen. Beispiel: E-Mail **Operate** - Mailplattform betreiben - Kapazität überwachen - Sicherheitsupdates installieren - Warteschlangen kontrollieren - Backup und Wiederherstellung sicherstellen - technische Verfügbarkeit überwachen **Deliver** - E-Mail-Service für Benutzer bereitstellen - Zugänge und Leistungsumfang steuern - Serviceerwartungen abstimmen - Nutzung und Servicequalität bewerten - Benutzererfahrung berücksichtigen Beide Aktivitäten überschneiden und beeinflussen sich. --- **Leitfragen zu Operate** - Welche Komponenten müssen betrieben werden? - Welche Betriebsziele gelten? - Wie werden Verfügbarkeit und Leistung überwacht? - Welche Wartungsarbeiten sind notwendig? - Wie werden Patches und Updates durchgeführt? - Wie werden Kapazitätsgrenzen erkannt? - Wie werden Sicherheitsereignisse behandelt? - Funktionieren Backup und Wiederherstellung? - Sind technische Abhängigkeiten bekannt? - Welche Automatisierungen werden überwacht? - Wie werden technische Schulden behandelt? - Welche Bereitschaft oder Rufbereitschaft ist notwendig? - Wie wird bei Lieferantenausfällen reagiert? - Wann muss eine Komponente ersetzt oder abgelöst werden? --- **Stabilität und Veränderung** Operate bedeutet nicht, technische Systeme möglichst unverändert zu lassen. Ein stabiler Betrieb benötigt regelmäßig: - Sicherheitsupdates - Kapazitätsanpassungen - Fehlerkorrekturen - Zertifikatserneuerungen - Konfigurationsverbesserungen - Austausch veralteter Komponenten - und Anpassung an neue Anforderungen Diese Änderungen müssen kontrolliert erfolgen. > **Merke** > > Stabilität entsteht nicht durch Stillstand. > > Sie entsteht durch kontrollierte Veränderung, Überwachung und angemessene Wiederherstellungsfähigkeit. --- **Technische Schulden im Betrieb** Technische Schulden können sich zeigen durch: - nicht unterstützte Software - veraltete Hardware - manuelle Sonderkonfigurationen - fehlende Automatisierung - nicht dokumentierte Abhängigkeiten - dauerhaft verwendete Zwischenlösungen - unsichere Altprotokolle - oder nicht reproduzierbare Systeme Sie sollten: - sichtbar gemacht, - hinsichtlich Risiko bewertet, - priorisiert, - verantwortet, - und kontrolliert reduziert werden. --- **Mögliche Ergebnisse von Operate** - laufende technische Fähigkeiten - überwachte Plattformen - durchgeführte Wartung - gesicherte und wiederherstellbare Daten - bekannte Kapazität - behandelte Events - dokumentierte technische Risiken - aktuelle Konfigurationsinformationen - betriebliche Leistungsdaten - identifizierte Verbesserungsmöglichkeiten --- **Typische Fehler bei Operate** - nur auf Verfügbarkeit achten - Warnungen ohne klare Reaktion erzeugen - Backup-Erfolg mit Wiederherstellbarkeit verwechseln - technische Schulden nicht sichtbar machen - Wartung dauerhaft verschieben - Abhängigkeiten nicht dokumentieren - Betrieb ausschließlich reaktiv gestalten - technische Kennzahlen nicht mit Service-Outcomes verbinden --- **7. Deliver** > **Zentrale Frage** > > Wie werden Services und Serviceangebote so bereitgestellt, dass Stakeholder die vorgesehenen Outcomes erreichen können? Deliver betrachtet die tatsächliche Bereitstellung und Steuerung des Service gegenüber Benutzern, Kunden und weiteren Stakeholdern. Dazu können gehören: - Serviceangebote - Zugangs- und Nutzungsbereitstellung - Servicebeziehungen - Abstimmung von Erwartungen - Servicequalität - Service Levels - Kommunikation - Erfüllung vereinbarter Leistungen - Benutzererfahrung - und Überprüfung erreichter Outcomes --- **Technische Verfügbarkeit und Servicebereitstellung** Ein technisches System kann verfügbar sein, während der Service für den Benutzer nicht nutzbar ist. Beispiele: - Die Anwendung läuft, aber der Benutzer besitzt keine Lizenz. - Das VPN-Gateway ist erreichbar, aber MFA funktioniert nicht. - Der Fileserver ist verfügbar, aber Berechtigungen fehlen. - Die E-Mail-Plattform läuft, aber DNS ist fehlerhaft. - Das Portal ist erreichbar, aber der Geschäftsprozess kann nicht abgeschlossen werden. Deliver betrachtet deshalb nicht nur technische Funktion, sondern auch die tatsächliche Nutzbarkeit und Leistung des Service. --- **Leitfragen zu Deliver** - Welcher Service wird bereitgestellt? - Welche Serviceangebote bestehen? - Wer darf den Service nutzen? - Welche Outcomes werden erwartet? - Welche Erwartungen und Vereinbarungen gelten? - Welche Zugänge und Ressourcen werden benötigt? - Wie wird die Nutzung ermöglicht? - Welche Qualität wird wahrgenommen? - Welche Servicezeiten und Serviceziele gelten? - Wie werden Abweichungen kommuniziert? - Wie werden Rückmeldungen erfasst? - Werden vereinbarte Leistungen tatsächlich erreicht? - Entspricht der Service weiterhin dem Bedarf? - Welche Verbesserungen sind notwendig? --- **Serviceangebot** Ein Serviceangebot kann unterschiedliche Bestandteile verbinden: - Waren oder übertragene Ressourcen - Zugang zu Ressourcen - Servicehandlungen Praxisbeispiel: Arbeitsplatzservice Mögliche Bestandteile: - Endgerät - Benutzerkonto - Softwarelizenzen - Netzwerkzugang - Dateiablage - E-Mail - Support - Geräteaustausch - Sicherheitsmaßnahmen - und Wartung Der Benutzer benötigt normalerweise nicht jeden technischen Bestandteil einzeln. Er benötigt einen arbeitsfähigen Arbeitsplatz als nutzbares Gesamtergebnis. --- **Servicequalität und Erfahrung** Servicequalität kann sowohl objektive als auch subjektive Aspekte besitzen. Mögliche objektive Informationen: - Verfügbarkeit - Reaktionszeit - Lösungszeit - Leistung - Fehlerquote - Erfüllungsquote - Wiederherstellungszeit Mögliche Erfahrungsaspekte: - Verständlichkeit - Zuverlässigkeit aus Benutzersicht - Einfachheit der Nutzung - Qualität der Kommunikation - Vertrauen - wahrgenommene Geschwindigkeit - und Aufwand für den Benutzer > **Merke** > > Ein Service kann technische Zielwerte erfüllen und trotzdem eine schlechte Benutzererfahrung erzeugen. --- **Mögliche Ergebnisse von Deliver** - nutzbarer Service - erfüllte Service Requests - bereitgestellte Zugänge - abgestimmte Erwartungen - gemessene Serviceleistung - bekannte Benutzererfahrung - dokumentierte Serviceabweichungen - aktualisierte Serviceangebote - identifizierte Verbesserungen - erreichte oder teilweise erreichte Outcomes --- **Typische Fehler bei Deliver** - Servicebereitstellung mit technischem Betrieb gleichsetzen - nur interne Kennzahlen verwenden - Benutzererfahrung nicht berücksichtigen - Serviceangebote unverständlich beschreiben - Zugangs- und Berechtigungsprozesse nicht einbeziehen - Leistungen zusagen, die technisch oder organisatorisch nicht unterstützt werden - Servicequalität ohne Stakeholderfeedback bewerten --- **8. Support** > **Zentrale Frage** > > Wie werden Benutzer, Kunden, Produkte und Services bei Fragen, Anfragen, Problemen und Störungen wirksam unterstützt? Support umfasst die Unterstützung während der Nutzung eines Produkts oder Service. Dazu können gehören: - Service Desk - Incident-Bearbeitung - Service Requests - technische Unterstützung - Wissensbereitstellung - Kommunikation - Eskalation - Problem Management - Benutzerberatung - und Rückmeldungen an Produkt- und Serviceteams Support beschränkt sich nicht darauf, Tickets möglichst schnell zu schließen. Das Ziel besteht darin, negative Auswirkungen zu begrenzen, Nutzung zu ermöglichen und wertvolle Erkenntnisse zurück in den Lebenszyklus zu führen. --- **Support als Informationsquelle** Support erhält häufig direkte Informationen über: - Benutzerprobleme - unklare Funktionen - wiederkehrende Fehler - fehlende Dokumentation - Schulungsbedarf - schlechte Benutzererfahrung - nicht erfüllte Erwartungen - und Verbesserungspotenzial Diese Erkenntnisse sollten nicht ausschließlich im einzelnen Ticket bleiben. Sie können zurückfließen in: - Discover - Design - Build - Operate - Deliver - Problem Management - Knowledge Management - und Continual Improvement > **Merke** > > Support ist nicht nur die letzte Aktivität des Modells. > > Support liefert Erkenntnisse für den gesamten Product and Service Lifecycle. --- **Leitfragen zu Support** - Welche Unterstützung benötigen Benutzer und Kunden? - Wie erreichen sie die zuständige Stelle? - Welche Informationen müssen erfasst werden? - Wie werden Incidents und Service Requests unterschieden? - Wie werden Auswirkungen und Dringlichkeit bewertet? - Welche Lösungen und Wissensartikel existieren? - Wann muss eskaliert werden? - Wie werden Benutzer informiert? - Welche Lieferanten müssen eingebunden werden? - Wie wird die Wiederherstellung geprüft? - Welche wiederkehrenden Muster bestehen? - Welche Erkenntnisse müssen an Produkt- und Serviceteams weitergegeben werden? - Wie wird die Supporterfahrung bewertet? - Welche Unterstützung kann verhindert oder vereinfacht werden? --- **Supportfähigkeit bereits vorher aufbauen** Wirksamer Support benötigt unter anderem: - verständliche Serviceinformationen - eindeutige Kontaktwege - geschulte Mitarbeiter - technische Diagnosemöglichkeiten - Zugriffsberechtigungen - aktuelle Dokumentation - Knowledge-Artikel - Monitoring- und Protokolldaten - bekannte Eskalationswege - Lieferantenkontakte - und klare Verantwortlichkeiten Diese Voraussetzungen müssen bereits in Design, Build und Transition berücksichtigt werden. --- **Mögliche Ergebnisse von Support** - wiederhergestellte Services - erfüllte Benutzeranfragen - gelöste technische Fragen - bereitgestelltes Wissen - dokumentierte Incidents - identifizierte Probleme - weitergeleitetes Benutzerfeedback - verbesserte Supportinformationen - bekannte Produkt- und Servicefehler - Vorschläge für Continual Improvement --- **Typische Fehler bei Support** - Ticketabschluss mit erreichtem Outcome gleichsetzen - Benutzer mehrfach dieselben Informationen liefern lassen - nur Symptome behandeln - bekannte Lösungen nicht dokumentieren - wiederkehrende Incidents nicht an Problem Management übergeben - Support nicht vor Releases informieren - Benutzerfeedback nicht weiterverwenden - interne Kennzahlen wichtiger behandeln als die tatsächliche Wiederherstellung --- **Zusammenwirken der acht Aktivitäten** Praxisbeispiel: Einführung eines neuen sicheren Fernzugriffs **Discover** - Bedarf an Remote-Arbeit verstehen - Benutzergruppen und Anwendungen bestimmen - bisherige Probleme und Risiken untersuchen - gewünschte Outcomes festlegen **Design** - VPN- oder Zero-Trust-Lösung gestalten - Identität, MFA, Endgeräte und Support einplanen - Sicherheits-, Verfügbarkeits- und Erfahrungsanforderungen definieren **Acquire** - Plattform, Lizenzen und Supportleistungen beschaffen - benötigte Schulungen und externe Fähigkeiten organisieren **Build** - Systeme konfigurieren - Integrationen erstellen - Sicherheitsregeln, Monitoring und Dokumentation aufbauen - Funktion, Leistung und Wiederherstellung testen **Transition** - Pilotgruppe einführen - Benutzer und Service Desk vorbereiten - Daten und Konfigurationen überführen - Rückfall- und Kommunikationsplan bereitstellen **Operate** - Gateways, Identitätsdienste und Zertifikate betreiben - Leistung, Sicherheit und Kapazität überwachen - Updates und Wartung durchführen **Deliver** - Fernzugriffsservice für berechtigte Benutzer bereitstellen - Serviceerwartungen und Nutzungsbedingungen kommunizieren - Qualität und Erfahrung bewerten **Support** - Anmeldeprobleme und Anfragen bearbeiten - Wissen bereitstellen - wiederkehrende Fehler untersuchen - Feedback an Produkt- und Serviceteams zurückführen --- **Continual Improvement über den gesamten Lifecycle** Continual Improvement ist nicht auf das Ende des Lebenszyklus beschränkt. Jede Aktivität kann verbessert werden. | Lifecycle-Aktivität | Beispiel für eine Verbesserung | |---|---| | **Discover** | Benutzerfeedback früher und systematischer erfassen | | **Design** | Betriebs- und Sicherheitsanforderungen früher berücksichtigen | | **Acquire** | Exit-Anforderungen in Lieferantenbewertungen aufnehmen | | **Build** | Tests und Bereitstellung stärker automatisieren | | **Transition** | Pilot- und Rückfallverfahren verbessern | | **Operate** | wiederkehrende Wartung automatisieren | | **Deliver** | Serviceangebote verständlicher gestalten | | **Support** | bekannte Lösungen schneller auffindbar machen | Erkenntnisse aus späteren Aktivitäten können frühere Aktivitäten erneut auslösen. Beispiel: Support erkennt viele Anfragen zu einer unverständlichen Funktion. Dies kann führen zu: - erneutem Discover der Benutzerbedürfnisse, - angepasstem Design, - verändertem Build, - neuer Transition, - und verbesserter Bereitstellung. --- **Governance über den gesamten Lifecycle** Governance wirkt auf alle acht Aktivitäten. Zu klären sind unter anderem: - Welche Ziele und Prioritäten gelten? - Wer besitzt Entscheidungsbefugnis? - Welche Risiken dürfen akzeptiert werden? - Welche gesetzlichen und vertraglichen Anforderungen gelten? - Welche Kontrollen sind notwendig? - Wie werden Investitionen priorisiert? - Wie werden Ergebnisse überwacht? - Wer trägt Verantwortung für Produkt und Service? - Wann muss eine Aktivität erneut bewertet werden? - Wann muss ein Produkt oder Service beendet werden? Governance sollte nicht erst bei der produktiven Einführung beginnen. Ungeeignete Grundentscheidungen in Discover, Design oder Acquire können später nur mit hohem Aufwand korrigiert werden. --- **Die Guiding Principles im Lifecycle** | Guiding Principle | Anwendung im Lifecycle | |---|---| | **Focus on value** | jede Aktivität am benötigten Outcome ausrichten | | **Start where you are** | bestehende Produkte, Fähigkeiten und Daten berücksichtigen | | **Progress iteratively with feedback** | Versionen, Piloten und kontrollierte Schritte verwenden | | **Collaborate and promote visibility** | Produkt-, Service-, Betriebs- und Supportteams verbinden | | **Think and work holistically** | alle acht Aktivitäten und vier Dimensionen berücksichtigen | | **Keep it simple and practical** | unnötige Übergaben und Komplexität vermeiden | | **Optimize and automate** | Arbeitsweisen verbessern und geeignete Teile automatisieren | --- **Künstliche Intelligenz im Lifecycle** KI kann in allen Lifecycle-Aktivitäten verwendet werden. Beispiele: | Aktivität | Mögliche KI-Unterstützung | |---|---| | **Discover** | Muster in Feedback und Nutzungsdaten erkennen | | **Design** | Varianten analysieren oder Prototypen unterstützen | | **Acquire** | Angebote und Anforderungen vergleichen | | **Build** | Code-, Konfigurations- oder Testunterstützung | | **Transition** | Risiken und Migrationsdaten analysieren | | **Operate** | Anomalien und mögliche Ausfälle erkennen | | **Deliver** | Services personalisieren oder Interaktionen unterstützen | | **Support** | Tickets klassifizieren und Lösungsvorschläge bereitstellen | Dabei bleiben notwendig: - klare Verantwortlichkeit - Datenqualität - Datenschutz - Informationssicherheit - menschliche Kontrolle - Überwachung - Nachvollziehbarkeit - und Risikobewertung > **Sicherheitsrelevant** > > KI-Unterstützung ersetzt nicht die Verantwortung der zuständigen Personen und Organisation. --- **Wo befindet sich die Außerbetriebnahme?** Das offizielle ITIL-Version-5-Modell nennt acht Aktivitäten und enthält keine separate neunte Aktivität mit der Bezeichnung **Retire**. Die Ablösung oder Außerbetriebnahme eines Produkts oder Service muss trotzdem kontrolliert gestaltet werden. Dazu können Beiträge aus mehreren Aktivitäten gehören: **Discover** - Warum soll die bisherige Lösung beendet werden? - Welche Stakeholder und Abhängigkeiten sind betroffen? **Design** - Wie sieht die Ziel- oder Übergangslösung aus? - Welche Archivierungs- und Aufbewahrungsanforderungen gelten? **Acquire und Build** - Welche Ersatzlösung und Migrationswerkzeuge werden benötigt? **Transition** - Wie werden Benutzer, Daten und Abhängigkeiten überführt? - Wie wird die alte Lösung kontrolliert deaktiviert? **Operate** - Wie lange muss die Altumgebung parallel betrieben werden? - Wie werden Restzugriffe und technische Risiken überwacht? **Deliver und Support** - Wie werden Serviceangebote, Benutzerinformationen und Support angepasst? - Wie werden Fragen während der Ablösung behandelt? Zusätzlich können Practices wie folgende beteiligt sein: - Change Management - IT Asset Management - Service Configuration Management - Information Security Management - Supplier Management - Knowledge Management - und Continual Improvement > **Wichtig** > > Außerbetriebnahme bedeutet nicht nur, ein System auszuschalten. > > Daten, Zugänge, Verträge, Assets, Dokumentationen, Abhängigkeiten und Sicherheitsanforderungen müssen ebenfalls behandelt werden. --- **Anwendung bei einem Incident** Ein Incident findet hauptsächlich während Operate, Deliver oder Support statt. Seine Erkenntnisse können jedoch den gesamten Lifecycle beeinflussen. Beispiel: Ein Zertifikat läuft ab und verursacht einen Serviceausfall. **Support** - Incident erfassen - Benutzer informieren - Wiederherstellung koordinieren **Operate** - Zertifikat erneuern - Systeme und Abhängigkeiten kontrollieren **Discover** - untersuchen, warum das Risiko nicht rechtzeitig erkannt wurde **Design** - Zertifikatsverwaltung und Verantwortlichkeiten verbessern **Acquire** - falls notwendig geeignetes Zertifikats- oder Monitoring-Werkzeug beschaffen **Build** - automatisierte Erfassung und Alarmierung erstellen **Transition** - neue Überwachung kontrolliert einführen **Deliver** - prüfen, ob der Service wieder vollständig nutzbar ist --- **Anwendung bei einem Change** Ein Change kann mehrere Lifecycle-Aktivitäten betreffen. Beispiel: Datenbank-Upgrade - **Discover:** Notwendigkeit, Risiken und Abhängigkeiten verstehen - **Design:** Zielversion, Architektur und Migrationsweg festlegen - **Acquire:** Lizenzen, Support oder zusätzliche Ressourcen beschaffen - **Build:** Zielumgebung konfigurieren und Migration testen - **Transition:** Upgrade kontrolliert durchführen - **Operate:** neue Version überwachen und warten - **Deliver:** Servicefunktion und Leistung aus Stakeholdersicht prüfen - **Support:** bekannte Fehler und Benutzerfragen bearbeiten > **Merke** > > Change Management unterstützt die kontrollierte Veränderung. > > Der Product and Service Lifecycle zeigt den größeren Zusammenhang, in dem die Veränderung stattfindet. --- **Anwendung bei einem kleinen Standardservice** Nicht jede Servicebereitstellung benötigt ein umfangreiches Projekt. Beispiel: Standardsoftware für einen Mitarbeiter bereitstellen **Discover** - benötigte Software und geschäftlichen Zweck klären **Design** - vorgesehenes Standardpaket und Berechtigungsmodell verwenden **Acquire** - vorhandene Lizenz zuordnen oder zusätzliche Lizenz beschaffen **Build** - Softwarepaket und Konfiguration bereitstellen **Transition** - kontrolliert auf das Endgerät verteilen **Operate** - Plattform und Paketverwaltung betreiben **Deliver** - Anwendung für den Benutzer freischalten **Support** - Installation und Nutzung bei Bedarf unterstützen Bei einem standardisierten und risikoarmen Fall können viele Schritte automatisiert und sehr kompakt ausgeführt werden. --- **Typische Missverständnisse** **Missverständnis 1: Die Aktivitäten werden immer einmal nacheinander durchgeführt** Tatsächlich können sie wiederholt, übersprungen, kombiniert oder gleichzeitig durchgeführt werden. --- **Missverständnis 2: Nach Transition beginnt ausschließlich der Betrieb** Auch während Operate, Deliver und Support können neue Discovery-, Design- und Build-Aktivitäten stattfinden. --- **Missverständnis 3: Build bedeutet nur Softwareentwicklung** Build kann auch Installation, Konfiguration, Integration, Automatisierung und technische Tests umfassen. --- **Missverständnis 4: Acquire bedeutet nur Einkauf** Acquire kann auch interne Ressourcen, Fähigkeiten, Daten, Lizenzen und wiederverwendete Komponenten umfassen. --- **Missverständnis 5: Operate und Deliver bedeuten dasselbe** Operate konzentriert sich stärker auf den technischen Betrieb. Deliver betrachtet stärker die tatsächliche Servicebereitstellung und das Stakeholder-Outcome. --- **Missverständnis 6: Support beginnt erst nach der Einführung** Supportfähigkeit muss bereits während Design, Build und Transition vorbereitet werden. --- **Missverständnis 7: Lifecycle und Value Stream sind identisch** Der Lifecycle stellt allgemeine Aktivitäten bereit. Ein Value Stream verbindet konkrete Schritte für ein bestimmtes Outcome. --- **Missverständnis 8: Ein Produkt ist nach dem ersten Release fertig** Digitale Produkte und Services werden weiter betrieben, unterstützt, verändert und verbessert. --- **Missverständnis 9: Eine erfolgreiche Transition beendet die Verantwortung des Produktteams** Produkt-, Service-, Betriebs- und Supportverantwortung müssen weiterhin zusammenarbeiten. --- **Missverständnis 10: Das Modell besitzt automatisch für jede Organisation dieselben Rollen** Die konkrete Rollenverteilung wird von der jeweiligen Organisation gestaltet. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker sind nicht nur in Operate und Support beteiligt. Sie können Beiträge über den gesamten Lifecycle leisten. | Aktivität | Möglicher Beitrag | |---|---| | **Discover** | technische Ausgangslage und bestehende Probleme erklären | | **Design** | Architektur, Betrieb, Sicherheit und Wiederherstellung mitgestalten | | **Acquire** | technische Anforderungen an Produkte und Lieferanten bewerten | | **Build** | Systeme installieren, konfigurieren, integrieren und testen | | **Transition** | Migration, Deployment und Betriebsübernahme unterstützen | | **Operate** | Infrastruktur und Plattformen betreiben | | **Deliver** | Servicebereitstellung und Nutzbarkeit sicherstellen | | **Support** | Incidents, Anfragen und technische Probleme bearbeiten | > **Praxistipp** > > Bringe Betriebs- und Supportwissen möglichst früh ein. > > Viele spätere Probleme können bereits während Discover, Design und Build verhindert werden. --- **30-Sekunden-Prüfung** Bei einem Produkt, Service oder Change kannst du acht Kurzfragen stellen: 1. **Discover:** Verstehen wir den tatsächlichen Bedarf? 2. **Design:** Ist die Gesamtlösung einschließlich Betrieb und Support gestaltet? 3. **Acquire:** Sind alle notwendigen Ressourcen und Fähigkeiten verfügbar? 4. **Build:** Wurde die Lösung erstellt, integriert und ausreichend getestet? 5. **Transition:** Kann sie kontrolliert und mit Rückfallmöglichkeit eingeführt werden? 6. **Operate:** Kann sie zuverlässig und sicher betrieben werden? 7. **Deliver:** Ist der Service für Stakeholder tatsächlich nutzbar? 8. **Support:** Können Benutzer und Service wirksam unterstützt werden? --- **Checkliste zu Discover** - [ ] Ist das zugrunde liegende Bedürfnis verstanden? - [ ] Sind Stakeholder und gewünschte Outcomes bekannt? - [ ] Wurde der aktuelle Zustand untersucht? - [ ] Sind Daten und Rückmeldungen verfügbar? - [ ] Sind Chancen, Risiken und Einschränkungen bekannt? - [ ] Wurden bestehende Lösungen berücksichtigt? - [ ] Sind Annahmen und Unsicherheiten dokumentiert? - [ ] Ist klar, wie Erfolg bewertet wird? --- **Checkliste zu Design** - [ ] Sind funktionale und nichtfunktionale Anforderungen berücksichtigt? - [ ] Wurden alle vier Dimensionen betrachtet? - [ ] Sind Sicherheit und Datenschutz integriert? - [ ] Sind Betrieb, Monitoring und Wiederherstellung gestaltet? - [ ] Sind Support und Benutzererfahrung berücksichtigt? - [ ] Sind Rollen und Fähigkeiten geklärt? - [ ] Sind Lieferantenanforderungen bekannt? - [ ] Ist die spätere Ablösung berücksichtigt? --- **Checkliste zu Acquire** - [ ] Ist bekannt, welche Ressourcen benötigt werden? - [ ] Wurden vorhandene Ressourcen und Fähigkeiten geprüft? - [ ] Wurde Make, Buy, Reuse oder Partner angemessen bewertet? - [ ] Sind Gesamtbetriebskosten berücksichtigt? - [ ] Sind Lizenzen und Nutzungsrechte geklärt? - [ ] Sind Sicherheit und Datenschutz vertraglich berücksichtigt? - [ ] Sind Support- und Eskalationswege vereinbart? - [ ] Besteht eine Exit- und Übergangsplanung? --- **Checkliste zu Build** - [ ] Entspricht die Umsetzung dem Design? - [ ] Sind Konfigurationen nachvollziehbar und reproduzierbar? - [ ] Sind Schnittstellen und Abhängigkeiten getestet? - [ ] Wurden Sicherheitsanforderungen umgesetzt? - [ ] Wurden Funktion, Leistung und Wiederherstellung getestet? - [ ] Sind Monitoring und Protokollierung vorbereitet? - [ ] Sind Dokumentationen vorhanden? - [ ] Sind bekannte Fehler und Einschränkungen erfasst? --- **Checkliste zu Transition** - [ ] Ist die Lösung ausreichend getestet? - [ ] Sind Change und Autorisierung geklärt? - [ ] Sind Betrieb und Support vorbereitet? - [ ] Sind Benutzer und Stakeholder informiert? - [ ] Ist die Datenmigration geprüft? - [ ] Besteht ein geeigneter Rückfall- oder Wiederherstellungsplan? - [ ] Sind Verantwortlichkeiten während der Einführung eindeutig? - [ ] Wird das Ergebnis nach der Einführung überwacht? - [ ] Wird die Nutzbarkeit aus Stakeholdersicht bestätigt? --- **Checkliste zu Operate** - [ ] Sind Betriebsverantwortlichkeiten eindeutig? - [ ] Werden Verfügbarkeit, Leistung und Kapazität überwacht? - [ ] Sind Wartung und Patchmanagement geregelt? - [ ] Funktionieren Backup und Wiederherstellung? - [ ] Werden Sicherheitsereignisse behandelt? - [ ] Sind technische Abhängigkeiten bekannt? - [ ] Werden technische Schulden sichtbar gemacht? - [ ] Bestehen geeignete Eskalations- und Bereitschaftswege? - [ ] Fließen Betriebsdaten in Verbesserungen ein? --- **Checkliste zu Deliver** - [ ] Ist der Service für berechtigte Stakeholder nutzbar? - [ ] Sind Serviceangebot und Leistungsumfang verständlich? - [ ] Sind Erwartungen und Vereinbarungen abgestimmt? - [ ] Werden Serviceleistung und Outcomes gemessen? - [ ] Wird die Benutzer- und Kundenerfahrung berücksichtigt? - [ ] Werden Abweichungen transparent kommuniziert? - [ ] Sind Zugangs- und Berechtigungswege wirksam? - [ ] Wird geprüft, ob der Service weiterhin zum Bedarf passt? --- **Checkliste zu Support** - [ ] Existiert ein eindeutiger Kontaktweg? - [ ] Sind Mitarbeiter, Werkzeuge und Informationen vorbereitet? - [ ] Sind Incident und Service Request richtig einzuordnen? - [ ] Sind Auswirkungen und Dringlichkeit nachvollziehbar? - [ ] Sind Wissen und Diagnoseinformationen verfügbar? - [ ] Sind Eskalations- und Lieferantenwege bekannt? - [ ] Wird die Wiederherstellung aus Benutzersicht geprüft? - [ ] Werden wiederkehrende Muster erkannt? - [ ] Fließen Erkenntnisse in Produkt, Service und Verbesserung zurück? --- **Gesamtcheck für den Product and Service Lifecycle** - [ ] Werden Produkt und Service gemeinsam betrachtet? - [ ] Sind gewünschte Outcomes und Stakeholder bekannt? - [ ] Sind alle acht Aktivitäten angemessen berücksichtigt? - [ ] Wurde das Modell nicht als starrer Ablauf verwendet? - [ ] Sind mehrere gleichzeitig aktive Produktversionen berücksichtigt? - [ ] Arbeiten Produkt-, Service-, Betriebs- und Supportteams zusammen? - [ ] Werden alle vier Dimensionen betrachtet? - [ ] Sind Governance und Verantwortlichkeit geklärt? - [ ] Werden Risiken und technische Schulden sichtbar behandelt? - [ ] Sind Betrieb, Support und Ablösung frühzeitig berücksichtigt? - [ ] Werden Feedback und Betriebsdaten zurückgeführt? - [ ] Ist Continual Improvement in allen Aktivitäten verankert? - [ ] Wird der tatsächliche Wert statt nur technischer Outputs bewertet? --- **Schnellreferenz** | Aktivität | Kurzfrage | |---|---| | **Discover** | Was wird benötigt und warum? | | **Design** | Wie muss die Gesamtlösung gestaltet sein? | | **Acquire** | Welche Ressourcen und Fähigkeiten werden benötigt? | | **Build** | Wie wird die Lösung erstellt und getestet? | | **Transition** | Wie wird sie kontrolliert in die Nutzung überführt? | | **Operate** | Wie wird sie zuverlässig und sicher betrieben? | | **Deliver** | Wie wird der Service für Stakeholder nutzbar bereitgestellt? | | **Support** | Wie werden Benutzer, Produkt und Service unterstützt? | --- **Zusammenfassende Darstellung** > **Discover** > Bedarf, Chancen und Ausgangslage verstehen > ↓ > **Design** > Produkt, Service und Gesamtlösung gestalten > ↓ > **Acquire** > Ressourcen, Produkte und Fähigkeiten beschaffen > ↓ > **Build** > erstellen, konfigurieren, integrieren und testen > ↓ > **Transition** > kontrolliert in die vorgesehene Nutzung überführen > ↓ > **Operate** > technische Fähigkeiten zuverlässig betreiben > ↓ > **Deliver** > Services für Stakeholder bereitstellen > ↓ > **Support** > Benutzer, Produkte und Services unterstützen > ↓ > Feedback und Continual Improvement > ↓ > erneutes Discover, Design oder eine andere benötigte Aktivität Die Darstellung dient als Lernhilfe. Das offizielle Modell ist nicht starr oder ausschließlich linear. Jede Aktivität kann Erkenntnisse für jede andere Aktivität liefern. --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.4 Governance und Verantwortlichkeit - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 2.10 ITIL an den eigenen Kontext anpassen - Change Management - Deployment Management - Release Management - Service Design - Service Desk - Incident Management - Supplier Management - Monitoring and Event 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) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) - [ITIL: The New ITIL Product and Service Lifecycle Model – A Connected Ecosystem Approach](https://www.itil.com/Itil-News-and-Announcements/itil-product-and-service-lifecycle-model) - [ITIL: The New ITIL Product and Service Lifecycle Model](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-service-lifecycle-model) - [ITIL: New ITIL Explained for Certified Professionals](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-explained) - [ITIL: ITIL Product – Version 5](https://www.itil.com/professionals/certifications/ITIL-Product-Version-5) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) **Einordnung** ITIL Version 5 verwendet einen gemeinsamen Product and Service Lifecycle mit acht Aktivitäten: - Discover - Design - Acquire - Build - Transition - Operate - Deliver - Support Die offiziellen Veröffentlichungen beschreiben das Modell als ganzheitlich, flexibel und nicht starr linear. Aktivitäten können sich gegenseitig beeinflussen, wiederholt werden und für unterschiedliche Versionen eines Produkts oder Service gleichzeitig stattfinden. Die detaillierten Leitfragen, Beispiele, Checklisten und praktischen Einordnungen auf dieser Seite sind eigene herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebenen Arbeitsabläufe dar. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.7 Die ITIL Management Practices > **Kurz erklärt** > > ITIL Management Practices bündeln organisatorische Ressourcen und Fähigkeiten, die für einen bestimmten Zweck eingesetzt werden. > > Eine Practice umfasst deshalb nicht nur einen Prozess. > > Si:contentReference[oaicite:0]{index=0}chen und Rollen, > - Fähigkeiten und Wissen, > - Informationen und Daten, > - Wertströme und Prozesse, > - Technologien und Werkzeuge, > - Partner und Lieferanten, > - Regeln und Kontrollen, > - Messgrößen, > - sowie Verbesserungsmaßnahmen. > > ITIL Version 5 führt weiterhin **34 Management Practices**. Sie wurden gegenüber ITIL 4 nicht vollständig ersetzt, sondern weitgehend fortgeführt und an den neuen Produkt- und Servicekontext angepasst. --- **Warum Management Practices notwendig sind** Digitale Produkte und Services benötigen unterschiedliche organisatorische Fähigkeiten. Beispiele: - Incidents müssen erkannt und bearbeitet werden. - Benutzer benötigen einen eindeutigen Kontaktweg. - Änderungen müssen hinsichtlich Nutzen und Risiken bewertet werden. - technische Komponenten und Abhängigkeiten müssen bekannt sein. - Wissen muss verfügbar und aktuell sein. - Lieferanten müssen gesteuert werden. - Sicherheitsanforderungen müssen berücksichtigt werden. - wiederkehrende Fehler müssen nachhaltig untersucht werden. - Serviceleistung und Erfahrungen müssen ausgewertet werden. - Verbesserungen müssen geplant und umgesetzt werden. Eine einzelne Abteilung oder ein einzelner Prozess kann diese Aufgaben normalerweise nicht vollständig erfüllen. Management Practices stellen deshalb strukturierte Fähigkeiten bereit, die in unterschiedlichen Wertströmen miteinander kombiniert werden können. > **Merke** > > Eine Practice beschreibt eine organisatorische Fähigkeit. > > Ein konkreter Wertstrom verwendet die benötigten Practices, um ein bestimmtes Outcome zu erreichen. --- **Practice, Prozess, Team und Werkzeug unterscheiden** Diese Begriffe dürfen nicht gleichgesetzt werden. | Begriff | Bedeutung | |---|---| | **Management Practice** | organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck | | **Prozess** | strukturierte Folge von Aktivitäten, die Eingaben in Ergebnisse überführt | | **Value Stream** | Ende-zu-Ende-Abfolge von Schritten zur Ermöglichung eines bestimmten Outcomes | | **Team** | Gruppe von Personen, die bestimmte Aufgaben oder Verantwortlichkeiten übernimmt | | **Rolle** | definierte Verantwortung, Befugnis oder Tätigkeit | | **Werkzeug** | technische Unterstützung für Informationen, Kommunikation, Automatisierung oder Kontrolle | | **Arbeitsanweisung** | konkrete Beschreibung, wie eine bestimmte Tätigkeit ausgeführt wird | Beispiel: Incident Management **Die Practice kann enthalten:** - Rollen und Verantwortlichkeiten, - Priorisierungskriterien, - Eskalationswege, - Kommunikationsregeln, - Wissen, - Ticketsystem, - Monitoring-Informationen, - Lieferantenkontakte, - Messgrößen, - und Verbesserungsaktivitäten. **Ein Prozess kann beschreiben:** 1. Incident erfassen 2. Auswirkungen und Dringlichkeit bewerten 3. kategorisieren 4. zuständige Bearbeitung zuweisen 5. untersuchen und diagnostizieren 6. Service wiederherstellen 7. Ergebnis prüfen 8. dokumentieren und abschließen **Ein Team kann sein:** - Service Desk, - Netzwerkteam, - Anwendungsteam, - Infrastrukturteam, - externer Provider, - oder eine bereichsübergreifende Incident-Gruppe. **Ein Werkzeug kann sein:** - Ticketsystem, - Monitoring-Plattform, - Kommunikationsplattform, - Wissensdatenbank, - oder Automatisierungslösung. > **Typischer Fehler** > > Eine Practice wird eingeführt, indem lediglich ein entsprechendes Modul im Ticketsystem aktiviert wird. > > Ein Werkzeug kann eine Practice unterstützen, aber fehlende Verantwortung, Fähigkeiten, Informationen und Zusammenarbeit nicht ersetzen. --- **Die vier Dimensionen innerhalb einer Practice** Jede Practice sollte ganzheitlich über die vier Dimensionen betrachtet werden. | Dimension | Beispielhafte Inhalte einer Practice | |---|---| | **Organizations and People** | Rollen, Fähigkeiten, Kapazität, Kommunikation und Verantwortung | | **Information and Technology** | Daten, Wissen, Ticketsysteme, Monitoring und Automatisierung | | **Partners and Suppliers** | externe Supportpartner, Hersteller, Provider und Verträge | | **Value Streams and Processes** | Aktivitäten, Übergaben, Kontrollen und Arbeitsergebnisse | Beispiel: Monitoring and Event Management **Organizations and People** - Wer überwacht die Meldungen? - Wer entscheidet über die notwendige Reaktion? - Besteht ausreichende Bereitschaft und Fachkenntnis? **Information and Technology** - Welche Systeme werden überwacht? - Sind Messwerte und Schwellenwerte zuverlässig? - Wie werden Events korreliert und gespeichert? **Partners and Suppliers** - Welche Provider liefern eigene Meldungen? - Wie werden Störungen externer Services eskaliert? **Value Streams and Processes** - Wie wird aus einem relevanten Event eine Handlung? - Wann wird ein Incident erfasst? - Wie werden Fehlalarme verbessert? --- **Management Practices sind keine isolierten Silos** Eine Practice arbeitet normalerweise nicht allein. Bei einer realen Situation können mehrere Practices zusammenwirken. Beispiel: Eine Unternehmensanwendung fällt nach einem Update aus. 1. **Monitoring and Event Management** erkennt eine Zustandsänderung. 2. **Incident Management** koordiniert die Wiederherstellung. 3. **Service Desk** dient als Kontakt- und Kommunikationspunkt. 4. **Service Configuration Management** liefert Informationen über Abhängigkeiten. 5. **Knowledge Management** stellt bekannte Diagnose- und Wiederherstellungsschritte bereit. 6. **Supplier Management** bindet gegebenenfalls den Hersteller ein. 7. **Problem Management** untersucht die zugrunde liegende Ursache. 8. **Change Enablement** unterstützt die kontrollierte dauerhafte Korrektur. 9. **Release Management** plant die Bereitstellung einer korrigierten Version. 10. **Deployment Management** überträgt die korrigierten Komponenten in die Zielumgebung. 11. **Service Validation and Testing** prüft die neue oder geänderte Lösung. 12. **Continual Improvement** leitet Verbesserungen für Tests, Monitoring und Arbeitsweisen ab. > **Merke** > > Ein Vorgang gehört nicht immer nur zu einer Practice. > > Die benötigten Practices werden entsprechend dem tatsächlichen Wertstrom miteinander verbunden. --- **Änderungen gegenüber ITIL 4** ITIL Version 5 führt die 34 Management Practices weitgehend fort. Sie werden im aktuellen Framework in zwei übergeordneten Gruppen organisiert: 1. **Product and Service Management Practices** 2. **General Management Practices** Die frühere ITIL-4-Einteilung in: - General Management Practices, - Service Management Practices, - und Technical Management Practices soll deshalb nicht ungeprüft als aktuelle ITIL-Version-5-Struktur übernommen werden. Die öffentlich zugänglichen offiziellen Übersichtsseiten bestätigen die neue Einteilung in zwei Gruppen, veröffentlichen dort jedoch keine vollständige frei zugängliche Zuordnung aller 34 Practices zu diesen beiden Gruppen. Die detaillierten aktuellen Practice Guides werden über PeopleCert Plus bereitgestellt. > **Wichtig** > > Diese Seite führt die 34 Practices deshalb alphabetisch auf. > > Sie behauptet keine nicht ausreichend öffentlich belegte Einzelzuordnung zu den beiden neuen Gruppen. --- **Hinweis zur Bezeichnung Change Enablement** Die aktuelle offizielle ITIL-Version-5-Übersicht zum Practice-Manager-Pfad verwendet weiterhin die Bezeichnung **Change Enablement**. In anderen offiziellen Überblickstexten wird teilweise allgemein von **change management** gesprochen. Solange die konkrete aktuelle Practice Guidance keine eindeutig abweichende offizielle Practice-Bezeichnung vorgibt, verwendet dieses Buch deshalb: > **Change Enablement** **Change Management** kann weiterhin als allgemeiner organisatorischer Oberbegriff oder als betriebliche Bezeichnung vorkommen. > **Versionsabhängig** > > Eine betriebliche Organisation kann weiterhin eigene Begriffe wie Change Management, Änderungsmanagement oder Change-Prozess verwenden. > > Entscheidend ist, dass Zweck, Verantwortlichkeiten und Arbeitsweise eindeutig sind. --- **Die 34 ITIL Management Practices im Überblick** Die folgenden Kurzbeschreibungen sind praxisnahe Zusammenfassungen in eigenen Worten. Sie ersetzen nicht die vollständigen offiziellen Practice Guides. | Nr. | Management Practice | Praxisnahe Kurzbeschreibung | |---:|---|---| | 1 | **Architecture Management** | aktuelle und zukünftige Strukturen, Beziehungen und Architekturentscheidungen nachvollziehbar gestalten | | 2 | **Availability Management** | sicherstellen, dass Produkte und Services die benötigte und vereinbarte Verfügbarkeit unterstützen | | 3 | **Business Analysis** | Bedürfnisse, Probleme und Anforderungen untersuchen und geeignete Lösungsoptionen unterstützen | | 4 | **Capacity and Performance Management** | ausreichende Kapazität und Leistung für aktuelle und zukünftige Anforderungen sicherstellen | | 5 | **Change Enablement** | erfolgreiche Änderungen durch angemessene Bewertung, Autorisierung und Steuerung unterstützen | | 6 | **Continual Improvement** | Produkte, Services, Practices und Arbeitsweisen fortlaufend an veränderte Bedürfnisse anpassen | | 7 | **Deployment Management** | neue oder geänderte Komponenten kontrolliert in Zielumgebungen übertragen | | 8 | **Incident Management** | negative Auswirkungen von Incidents verringern und den normalen Servicebetrieb angemessen schnell wiederherstellen | | 9 | **Information Security Management** | Informationen und unterstützende Systeme entsprechend den Sicherheitsanforderungen schützen | | 10 | **Infrastructure and Platform Management** | Infrastruktur- und Plattformressourcen über ihren Lebenszyklus planen, betreiben und verbessern | | 11 | **IT Asset Management** | IT-Assets über ihren Lebenszyklus steuern, um Wert, Kosten, Risiken und Entscheidungen zu unterstützen | | 12 | **Knowledge Management** | benötigtes Wissen und Informationen wirksam erfassen, pflegen, teilen und verwenden | | 13 | **Measurement and Reporting** | verlässliche Messungen und Berichte für Entscheidungen, Steuerung und Verbesserung bereitstellen | | 14 | **Monitoring and Event Management** | Produkte, Services und Komponenten systematisch beobachten und relevante Zustandsänderungen behandeln | | 15 | **Organizational Change Management** | menschliche und organisatorische Veränderungen so unterstützen, dass neue Arbeitsweisen angenommen und dauerhaft genutzt werden | | 16 | **Portfolio Management** | Investitionen, Produkte, Services, Programme und Projekte auf Strategie, Wert und verfügbare Ressourcen ausrichten | | 17 | **Problem Management** | Ursachen und Wahrscheinlichkeiten von Incidents reduzieren sowie bekannte Fehler und Workarounds verwalten | | 18 | **Project Management** | zeitlich begrenzte Vorhaben strukturiert planen, steuern und abschließen | | 19 | **Relationship Management** | Beziehungen zu Stakeholdern aufbauen, pflegen und für gemeinsame Outcomes nutzen | | 20 | **Release Management** | neue oder geänderte Produkte, Services und Funktionen für die vorgesehene Nutzung verfügbar machen | | 21 | **Risk Management** | Risiken identifizieren, bewerten, behandeln, überwachen und angemessen kommunizieren | | 22 | **Service Catalogue Management** | verlässliche und verständliche Informationen über Services und Serviceangebote bereitstellen | | 23 | **Service Configuration Management** | zuverlässige Informationen über Services, Configuration Items und deren Beziehungen verfügbar machen | | 24 | **Service Continuity Management** | ausreichende Servicefähigkeit nach schwerwiegenden Störungen oder Katastrophen vorbereiten und erhalten | | 25 | **Service Design** | Produkte und Services ganzheitlich so gestalten, dass sie zweckmäßig, nutzbar und nachhaltig betreibbar sind | | 26 | **Service Desk** | zentralen Kontakt, Kommunikation sowie Unterstützung für Benutzer und Kunden ermöglichen | | 27 | **Service Financial Management** | finanzielle Informationen, Planung und Kontrolle für Produkte, Services und Entscheidungen unterstützen | | 28 | **Service Level Management** | verständliche, geschäftsbezogene Serviceziele vereinbaren und deren Erfüllung steuern | | 29 | **Service Request Management** | vereinbarte und häufig standardisierte Benutzeranfragen wirksam bearbeiten | | 30 | **Service Validation and Testing** | prüfen, ob neue oder geänderte Produkte und Services definierte Anforderungen und Nutzungsbedürfnisse erfüllen | | 31 | **Software Development and Management** | Software so entwickeln und verwalten, dass sie Anforderungen, Qualität, Wartbarkeit und Compliance unterstützt | | 32 | **Strategy Management** | Ziele, Ausrichtung und geeignete Handlungsoptionen für die Organisation entwickeln | | 33 | **Supplier Management** | Lieferanten, Verträge, Leistungen und Beziehungen angemessen steuern | | 34 | **Workforce and Talent Management** | sicherstellen, dass ausreichend geeignete Menschen, Fähigkeiten und Entwicklungsmöglichkeiten vorhanden sind | --- **Nicht jede Practice muss gleich stark ausgeprägt sein** Eine Organisation muss nicht jede Practice: - als eigene Abteilung, - mit einem eigenen Practice Owner, - mit einem umfangreichen Prozess, - oder mit einem separaten Werkzeugmodul aufbauen. Der benötigte Umfang hängt unter anderem ab von: - Größe der Organisation, - Produkten und Services, - Risiken, - gesetzlichen Anforderungen, - Anzahl der Benutzer, - Lieferantenabhängigkeiten, - vorhandenen Fähigkeiten, - technischer Komplexität, - und strategischer Bedeutung. Beispiel: Ein kleines Unternehmen kann Supplier Management durch: - klar dokumentierte Verträge, - eindeutige Ansprechpartner, - regelmäßige Leistungsprüfungen, - und vorbereitete Eskalationswege umsetzen. Eine große Organisation benötigt möglicherweise zusätzlich: - mehrere Supplier Manager, - formalisierte Lieferantenbewertungen, - Risikokategorien, - regelmäßige Reviews, - Vertragsdatenbanken, - Auditverfahren, - und strategische Lieferantenprogramme. > **Grundsatz** > > Eine Practice muss wirksam und angemessen sein. > > Sie muss nicht möglichst groß oder kompliziert sein. --- **Foundation-Wissen und vollständige Practice Guidance unterscheiden** Die ITIL Foundation vermittelt: - grundlegende Begriffe, - zentrale Zwecke, - wichtige Zusammenhänge, - und ausgewählte Practice-Terminologie. Die vollständige Practice Guidance kann darüber hinaus behandeln: - Erfolgsfaktoren, - Practice-Prozesse, - Aktivitäten, - Rollen, - Informationen, - Technologien, - Partner, - Messgrößen, - Wertströme, - Reife und Fähigkeiten, - Automatisierung, - und Verbesserung. > **Wichtig** > > Eine kurze Foundation-Definition reicht nicht aus, um eine vollständige betriebliche Practice zu gestalten. Für eine praktische Einführung werden zusätzlich benötigt: - Analyse des aktuellen Zustands, - Ziele und Outcomes, - betriebliche Anforderungen, - Rollen und Befugnisse, - konkrete Wertströme, - Werkzeuge, - Daten, - Schulungen, - Messgrößen, - und ein Verbesserungsplan. --- **Zertifizierungsbezogene Practice-Bündel** Die aktuelle offizielle Practice-Manager-Struktur verwendet drei Bündel mit jeweils fünf Practices. Diese Bündel sind für die Zertifizierungsstruktur relevant. Sie sind nicht mit den zwei übergeordneten Practice-Gruppen von ITIL Version 5 gleichzusetzen. --- **Monitor, Support and Fulfil** Enthaltene Practices: - Service Desk - Incident Management - Problem Management - Service Request Management - Monitoring and Event Management Gemeinsamer praktischer Schwerpunkt: - Zustände erkennen, - Benutzerkontakte ermöglichen, - Störungen bearbeiten, - Anfragen erfüllen, - wiederkehrende Ursachen reduzieren, - und Erkenntnisse aus dem laufenden Betrieb verwenden. --- **Plan, Implement and Control** Enthaltene Practices: - Change Enablement - Deployment Management - Release Management - Service Configuration Management - IT Asset Management Gemeinsamer praktischer Schwerpunkt: - Veränderungen vorbereiten, - Risiken und Abhängigkeiten verstehen, - Komponenten kontrolliert bereitstellen, - Releases verfügbar machen, - und Informationen über Assets sowie Konfigurationen pflegen. --- **Collaborate, Assure and Improve** Enthaltene Practices: - Relationship Management - Supplier Management - Service Level Management - Continual Improvement - Information Security Management Gemeinsamer praktischer Schwerpunkt: - Beziehungen und Erwartungen gestalten, - Lieferanten steuern, - Serviceziele vereinbaren, - Informationssicherheit unterstützen, - und Verbesserungen fortlaufend umsetzen. > **Hinweis** > > Die übrigen Practices bleiben weiterhin Bestandteil der insgesamt 34 ITIL Management Practices, auch wenn sie nicht in diesen drei Practice-Manager-Bündeln enthalten sind. --- **Wichtige Practices für Fachinformatiker für Systemintegration** Für Fachinformatiker für Systemintegration sind abhängig vom Arbeitsplatz besonders häufig folgende Practices relevant: | Practice | Typischer Bezug zum Arbeitsalltag | |---|---| | **Service Desk** | Benutzerkontakt, Erfassung, Kommunikation und Weiterleitung | | **Incident Management** | Störungen analysieren und Servicebetrieb wiederherstellen | | **Service Request Management** | Benutzerkonten, Zugriffe, Software und Standardleistungen bereitstellen | | **Problem Management** | wiederkehrende Fehler und zugrunde liegende Ursachen untersuchen | | **Change Enablement** | technische Änderungen bewerten und kontrolliert durchführen | | **Deployment Management** | Software, Konfigurationen oder Infrastrukturkomponenten bereitstellen | | **Release Management** | neue oder geänderte Funktionen für die Nutzung verfügbar machen | | **Monitoring and Event Management** | technische Zustände und relevante Abweichungen erkennen | | **Service Configuration Management** | Abhängigkeiten und Configuration Items nachvollziehen | | **IT Asset Management** | Hardware, Software, Lizenzen und Cloud-Ressourcen verwalten | | **Knowledge Management** | Lösungen, Arbeitsanweisungen und Erkenntnisse verfügbar machen | | **Information Security Management** | Schutzanforderungen bei Betrieb und Änderungen berücksichtigen | | **Supplier Management** | Hersteller, Provider und Supportpartner einbinden | | **Service Continuity Management** | Wiederherstellung und Fortführung kritischer Services unterstützen | | **Capacity and Performance Management** | Leistung, Kapazität und zukünftigen Bedarf bewerten | | **Availability Management** | benötigte Verfügbarkeit technischer und servicebezogener Fähigkeiten unterstützen | | **Continual Improvement** | wiederkehrende Probleme und Arbeitsweisen nachhaltig verbessern | Nicht jeder Fachinformatiker ist für die vollständige Steuerung dieser Practices verantwortlich. Er kann jedoch durch technische Arbeit, Dokumentation, Eskalation und Rückmeldungen zu ihrer Wirksamkeit beitragen. --- **Service Desk und Incident Management unterscheiden** Diese beiden Practices werden häufig gleichgesetzt. | Service Desk | Incident Management | |---|---| | stellt einen zentralen Kontakt- und Kommunikationspunkt bereit | koordiniert die Behandlung von Incidents | | bearbeitet Kontakte, Fragen, Anfragen und Meldungen | konzentriert sich auf negative Serviceauswirkungen und Wiederherstellung | | unterstützt Benutzerkommunikation | organisiert Priorisierung, Diagnose, Eskalation und Wiederherstellung | | kann Incidents und Service Requests erfassen | kann mehrere Teams und Lieferanten einbeziehen | | ist eine Practice und kann organisatorisch als Team umgesetzt sein | ist eine Practice, die nicht auf ein einzelnes Team begrenzt ist | Ein Service Desk kann Incident Management wesentlich unterstützen. Er ist jedoch nicht mit der gesamten Incident-Management-Practice identisch. --- **Incident Management und Problem Management unterscheiden** | Incident Management | Problem Management | |---|---| | konzentriert sich auf die aktuelle negative Auswirkung | konzentriert sich auf Ursachen und zukünftige Auswirkungen | | priorisiert Wiederherstellung | priorisiert Untersuchung und nachhaltige Risikoreduzierung | | kann eine Zwischenlösung verwenden | verwaltet Ursachen, bekannte Fehler und Workarounds | | arbeitet häufig unter höherem Zeitdruck | kann nach der Wiederherstellung vertieft arbeiten | | Erfolg: Service ist wieder nutzbar | Erfolg: Wahrscheinlichkeit oder Auswirkung weiterer Incidents wird reduziert | Beispiel: Ein Dienst wird nach einem Speicherfehler neu gestartet. - Der Neustart kann den Incident lösen. - Die Ursache des steigenden Speicherverbrauchs bleibt ein mögliches Problem. - Eine dauerhafte Korrektur kann anschließend einen Change, Release und Deployment benötigen. > **Merke** > > Ein Incident muss nicht vollständig ursächlich verstanden sein, bevor der Service wiederhergestellt wird. > > Eine Wiederherstellung beseitigt jedoch nicht automatisch die zugrunde liegende Ursache. --- **Event, Incident und Problem unterscheiden** | Begriff | Bedeutung | |---|---| | **Event** | erkannte Zustandsänderung, die für das Management eines Produkts oder Service relevant sein kann | | **Incident** | ungeplante Unterbrechung, Qualitätsminderung oder andere negative Serviceauswirkung | | **Problem** | Ursache oder mögliche Ursache eines oder mehrerer Incidents | Beispiel: - Monitoring meldet eine hohe Speicherauslastung: **Event** - Anwendung reagiert nicht mehr: **Incident** - fehlerhafte Speicherverwaltung der Anwendung: **Problem** Nicht jedes Event wird zu einem Incident. Nicht jeder Incident benötigt einen eigenen Problem Record. Die konkrete Einordnung hängt von Auswirkungen, Wiederholung, Risiko und betrieblicher Arbeitsweise ab. --- **Service Request und Incident unterscheiden** | Service Request | Incident | |---|---| | vorgesehene Benutzeranfrage | ungeplante negative Serviceauswirkung | | häufig standardisierbar | benötigt Untersuchung oder Wiederherstellung | | Beispiel: neue Software anfordern | Beispiel: vorhandene Software startet nicht | | Beispiel: Zugriff beantragen | Beispiel: genehmigter Zugriff funktioniert nicht | | Beispiel: Auskunft anfordern | Beispiel: Service ist nicht erreichbar | Die Formulierung eines Benutzers entscheidet nicht automatisch über die Einordnung. Ein Benutzer kann beispielsweise sagen: > Ich brauche ein neues Kennwort. Dahinter können unterschiedliche Situationen stehen: - planmäßige Kennwortänderung, - vergessenes Kennwort, - gesperrtes Konto, - möglicher Sicherheitsvorfall, - oder fehlerhafter Identitätsdienst. --- **Change Enablement, Release und Deployment unterscheiden** | Practice | Zentrale Betrachtung | |---|---| | **Change Enablement** | Nutzen, Risiko, Bewertung, Autorisierung und Steuerung einer Änderung | | **Release Management** | neue oder geänderte Funktionen und Servicebestandteile für die Nutzung verfügbar machen | | **Deployment Management** | Komponenten in eine Zielumgebung übertragen | Beispiel: neue Anwendungsversion **Change Enablement** - Auswirkungen und Risiken bewerten - notwendige Autorisierung sicherstellen - Zeitpunkt und Abhängigkeiten koordinieren - Rückfall- oder Wiederherstellungsplanung berücksichtigen **Release Management** - festlegen, welche Funktionen und Änderungen gemeinsam verfügbar gemacht werden - Releaseinformationen bereitstellen - Erwartungen und Zeitplanung abstimmen **Deployment Management** - Softwarepaket technisch übertragen - Konfiguration anwenden - Installation oder Aktivierung durchführen - technisches Ergebnis prüfen Diese Tätigkeiten können miteinander verbunden sein, besitzen aber unterschiedliche Zwecke. --- **IT Asset und Configuration Item unterscheiden** Ein **IT Asset** wird hinsichtlich seines finanziellen, vertraglichen, risikobezogenen und lebenszyklusbezogenen Werts verwaltet. Ein **Configuration Item** wird verwaltet, weil Informationen über seinen Zustand und seine Beziehungen für das Management eines Produktes oder Service benötigt werden. Ein Gegenstand kann: - nur IT Asset, - nur Configuration Item, - beides, - oder keines von beidem sein. Beispiele: | Gegenstand | Mögliche Einordnung | |---|---| | physischer Server | IT Asset und Configuration Item | | Softwarelizenz | IT Asset, möglicherweise auch Configuration Item | | virtueller Cluster | Configuration Item, abhängig vom Modell möglicherweise Asset-Bezug | | Netzwerkkabel | je nach Bedeutung weder einzeln verwaltetes Asset noch CI | | Cloud-Abonnement | IT Asset und möglicherweise Configuration Item | | Service-Dokumentation | möglicherweise Configuration Item, aber normalerweise kein IT Asset | > **Wichtig** > > Nicht jede technische Komponente muss automatisch als einzelnes Configuration Item erfasst werden. > > Der benötigte Detaillierungsgrad muss einen erkennbaren Nutzen besitzen. --- **Practice Owner, Process Owner und ausführende Rolle** Organisationen können unterschiedliche Verantwortlichkeiten verwenden. | Rolle | Möglicher Schwerpunkt | |---|---| | **Practice Owner** | Wirksamkeit und Weiterentwicklung der gesamten Practice | | **Process Owner** | Gestaltung und Pflege eines konkreten Prozesses | | **Process Manager** | laufende Steuerung eines Prozesses | | **Service Owner** | Ende-zu-Ende-Verantwortung für einen Service | | **Product Owner oder Product Manager** | Prioritäten und Entwicklung eines Produkts | | **ausführende Rolle** | konkrete Bearbeitung einer Aufgabe | | **Tool Owner** | Betrieb und Weiterentwicklung des unterstützenden Werkzeugs | ITIL schreibt nicht vor, dass jede Organisation genau diese Rollen einsetzen muss. Entscheidend ist, dass geklärt ist: - wer entscheidet, - wer ausführt, - wer für Ergebnisse einsteht, - wer Verbesserungen steuert, - und wer die benötigten Informationen und Ressourcen bereitstellt. --- **Eine Practice einführen oder verbessern** Eine Practice sollte nicht mit der Auswahl eines Werkzeugs beginnen. Eine sinnvolle Vorgehensweise ist: 1. Problem oder Bedarf verstehen 2. gewünschte Outcomes bestimmen 3. aktuellen Zustand untersuchen 4. relevante Stakeholder einbeziehen 5. betroffene Wertströme bestimmen 6. vorhandene Fähigkeiten und Daten bewerten 7. Rollen und Verantwortung klären 8. angemessene Prozesse und Kontrollen gestalten 9. benötigte Informationen und Werkzeuge festlegen 10. Lieferanten und Abhängigkeiten berücksichtigen 11. Messgrößen und Erfolgskriterien definieren 12. schrittweise einführen 13. Feedback auswerten 14. fortlaufend verbessern > **Typischer Fehler** > > Eine vollständige theoretische Practice wird auf einmal entworfen und anschließend der Organisation aufgezwungen. > > Dadurch entstehen umfangreiche Dokumentationen, die nicht zur tatsächlichen Arbeitsweise passen. --- **Eine Practice an Wertströmen ausrichten** Practices sollten nicht ausschließlich intern optimiert werden. Beispiel: Incident Management erreicht eine kurze interne Bearbeitungszeit, indem Tickets schnell an andere Teams weitergegeben werden. Dadurch können jedoch entstehen: - mehr Übergaben, - Informationsverluste, - längere Gesamtdauer, - wiederholte Rückfragen, - und schlechte Benutzererfahrung. Deshalb sollte geprüft werden: - Welchen Value Stream unterstützt die Practice? - Welches Outcome soll erreicht werden? - Welche anderen Practices sind beteiligt? - Wo entstehen Übergaben? - Welche Informationen müssen fließen? - Welche lokalen Kennzahlen schaden möglicherweise dem Gesamtergebnis? > **Merke** > > Eine leistungsfähige Practice unterstützt den gesamten Wertstrom und nicht nur ihre eigene interne Kennzahl. --- **Messung einer Practice** Messgrößen sollten den Zweck und die Outcomes einer Practice unterstützen. Nicht ausreichend ist es, nur leicht verfügbare Aktivitäten zu zählen. Beispiel: Incident Management Mögliche Aktivitätszahlen: - Anzahl geöffneter Tickets - Anzahl geschlossener Tickets - durchschnittliche Bearbeitungszeit Zusätzliche Ergebnisinformationen: - tatsächliche Wiederherstellungszeit - Auswirkung auf Benutzer - wiederholte Incidents - Erfolgsquote von Wiederherstellungen - Qualität der Kommunikation - erneute Kontaktaufnahme - Anzahl falsch geschlossener Vorgänge - Serviceerfahrung - nachhaltige Verbesserungen Beispiel: Knowledge Management Unzureichende Einzelkennzahl: > Anzahl veröffentlichter Wissensartikel Ergänzende Fragen: - Werden die Artikel gefunden? - Sind sie aktuell? - Helfen sie bei der Lösung? - Werden sie von Benutzern und Mitarbeitern verstanden? - Reduzieren sie wiederholte Analyse? - Werden falsche oder veraltete Inhalte entfernt? --- **Kennzahlen dürfen nicht das Verhalten verschlechtern** Eine ungeeignete Kennzahl kann unerwünschtes Verhalten fördern. | Kennzahl | Mögliche Fehlwirkung | |---|---| | möglichst viele geschlossene Tickets | Vorgänge werden voreilig abgeschlossen | | möglichst kurze Gesprächsdauer | Benutzerproblem wird nicht vollständig verstanden | | möglichst wenige Changes | notwendige Verbesserungen und Sicherheitsupdates werden vermieden | | möglichst wenige Incidents | Incidents werden nicht erfasst oder falsch eingeordnet | | möglichst viele Wissensartikel | Qualität und Aktualität sinken | | möglichst hohe technische Verfügbarkeit | tatsächliche Nutzbarkeit und Erfahrung werden übersehen | Messgrößen sollten deshalb gemeinsam betrachtet und regelmäßig überprüft werden. --- **Practice Capability und Maturity** Eine Practice kann unterschiedlich stark entwickelt sein. Zu bewerten sind beispielsweise: - Klarheit von Zweck und Outcomes, - Rollen und Verantwortlichkeiten, - Fähigkeiten, - Informationen, - Prozesse, - Werkzeuge, - Lieferanten, - Messung, - Integration in Wertströme, - und Continual Improvement. Eine umfangreiche Dokumentation bedeutet nicht automatisch hohe Fähigkeit oder Reife. Eine Practice kann formal beschrieben sein und trotzdem unwirksam bleiben, wenn: - Mitarbeiter den Ablauf umgehen, - Informationen unzuverlässig sind, - Befugnisse fehlen, - Werkzeuge nicht passen, - Schnittstellen nicht funktionieren, - oder Ergebnisse nicht verbessert werden. > **Merke** > > Practice Capability zeigt sich in der wirksamen Erreichung des Zwecks und nicht in der Menge der Dokumente. --- **Automatisierung innerhalb von Practices** Automatisierung kann Practices unterstützen. Beispiele: | Practice | Mögliche Automatisierung | |---|---| | Incident Management | automatische Erfassung aus relevantem Monitoring-Event | | Service Request Management | standardisierte Bereitstellung genehmigter Software | | Change Enablement | risikobasierte Weiterleitung und Terminprüfung | | IT Asset Management | automatische Inventarisierung | | Service Configuration Management | technische Discovery und Beziehungsaktualisierung | | Knowledge Management | Vorschläge passender Wissensartikel | | Monitoring and Event Management | Korrelation und Unterdrückung redundanter Events | | Measurement and Reporting | automatische Datensammlung und Berichtserstellung | | Deployment Management | automatisierte Bereitstellung und technische Prüfung | | Information Security Management | automatische Richtlinien- und Konfigurationskontrolle | Vor der Automatisierung muss geprüft werden: - Ist der Zweck verstanden? - Ist die Arbeitsweise geeignet? - Sind Eingabedaten zuverlässig? - Sind Ausnahmen bekannt? - Wie werden Fehler erkannt? - Wer trägt Verantwortung? - Wie wird die Automatisierung überwacht? - Gibt es eine Rückfallmöglichkeit? - Entsteht ein tatsächlicher Nutzen? > **Grundsatz** > > Erst verstehen und optimieren, dann automatisieren. --- **Künstliche Intelligenz innerhalb von Practices** KI kann unter anderem unterstützen bei: - Klassifizierung von Tickets, - Zusammenfassung von Vorgängen, - Suche nach Wissensartikeln, - Erkennung von Mustern, - Priorisierungsvorschlägen, - Analyse von Monitoring-Daten, - Berichtserstellung, - Übersetzung, - und Formulierung von Benutzerkommunikation. Dabei müssen berücksichtigt werden: - Datenqualität, - Datenschutz, - Informationssicherheit, - Nachvollziehbarkeit, - mögliche Verzerrungen, - Fehlerwahrscheinlichkeit, - menschliche Kontrolle, - und Verantwortung. Beispiel: Eine KI schlägt eine hohe Incident-Priorität vor. Die zuständige Arbeitsweise muss weiterhin klären: - Welche Auswirkungen bestehen tatsächlich? - Wie dringend ist die Situation? - Welche Kriterien verwendet die Organisation? - Sind die Eingangsdaten vollständig? - Wer bestätigt oder ändert die Priorität? - Wie wird die Entscheidung dokumentiert? > **Sicherheitsrelevant** > > Eine KI-Empfehlung überträgt die Entscheidungs- und Ergebnisverantwortung nicht auf das technische System. --- **Practice und betriebliche Organisation** Organisationen können Practices unterschiedlich benennen oder zusammenfassen. Beispiele: - Incident Management kann intern als Störungsmanagement bezeichnet werden. - Service Request Management kann im Bestell- oder Benutzerportal integriert sein. - Change Enablement kann als Change Management bezeichnet werden. - Monitoring and Event Management kann organisatorisch im Network Operations Center liegen. - IT Asset Management kann teilweise durch Einkauf oder Finanzabteilung unterstützt werden. - Information Security Management kann eng mit einem Informationssicherheitsmanagementsystem verbunden sein. Die interne Bezeichnung ist weniger wichtig als eine eindeutige Arbeitsweise. Zu klären ist: - Welcher Zweck wird verfolgt? - Welche Outcomes werden erwartet? - Wer trägt Verantwortung? - Welche Informationen werden benötigt? - Welche Schnittstellen bestehen? - Wie wird die Wirksamkeit geprüft? - Wie werden Verbesserungen umgesetzt? --- **Praxisbeispiel: wiederkehrender VPN-Ausfall** Mehrere Benutzer verlieren regelmäßig die VPN-Verbindung. **Monitoring and Event Management** - Verbindungsabbrüche und technische Zustände erkennen - relevante Messwerte und Ereignisse bereitstellen **Service Desk** - Benutzerkontakte und Rückmeldungen erfassen - verständliche Statusinformationen bereitstellen **Incident Management** - Auswirkungen und Dringlichkeit bewerten - Wiederherstellung koordinieren - zuständige Teams und Provider einbinden **Service Configuration Management** - Abhängigkeiten zwischen VPN-Gateway, Identitätsdienst, Zertifikaten, Netzwerk und Provider darstellen **Supplier Management** - externe Anbieter anhand geeigneter Informationen einbinden und eskalieren **Knowledge Management** - Diagnose- und Zwischenlösungen verfügbar machen **Problem Management** - wiederkehrende Muster und zugrunde liegende Ursache untersuchen **Change Enablement** - dauerhafte Korrektur hinsichtlich Risiko, Autorisierung und Zeitpunkt steuern **Deployment Management** - geänderte Konfiguration oder Software kontrolliert bereitstellen **Service Validation and Testing** - Stabilität, Kompatibilität und erwartete Nutzung prüfen **Continual Improvement** - Monitoring, Dokumentation, Eskalation und technische Lösung verbessern --- **Praxisbeispiel: neuer Mitarbeiter** Das gewünschte Outcome lautet: > Der neue Mitarbeiter kann am ersten Arbeitstag sicher und vollständig arbeiten. Mögliche beteiligte Practices: | Practice | Beitrag | |---|---| | **Service Request Management** | Onboarding-Anfrage erfassen und koordinieren | | **Service Catalogue Management** | verfügbare Arbeitsplatz- und Zugangsangebote beschreiben | | **IT Asset Management** | Endgerät und Lizenzen bereitstellen und verwalten | | **Service Configuration Management** | relevante Beziehungen und Konfigurationen dokumentieren | | **Information Security Management** | Zugriff und Sicherheitsanforderungen berücksichtigen | | **Supplier Management** | externe Lieferung oder Lizenzbereitstellung steuern | | **Knowledge Management** | Anleitungen und Übergabeinformationen bereitstellen | | **Service Desk** | Fragen und Probleme beim Einstieg unterstützen | | **Continual Improvement** | Verzögerungen und wiederkehrende Fehler im Onboarding reduzieren | Der Value Stream endet nicht bereits mit der Erstellung des Benutzerkontos. Er endet mit dem überprüften Outcome der Arbeitsfähigkeit. --- **Praxisbeispiel: abgelaufenes Zertifikat** Ein Zertifikat läuft ab und verursacht einen Serviceausfall. **Incident Management** - Service wiederherstellen **Monitoring and Event Management** - prüfen, warum keine ausreichende Warnung erfolgte **Service Configuration Management** - betroffene Zertifikate, Systeme und Services nachvollziehen **Problem Management** - systemische Ursache untersuchen **Knowledge Management** - Erneuerungs- und Wiederherstellungsverfahren dokumentieren **Change Enablement** - dauerhafte technische oder organisatorische Korrektur steuern **Information Security Management** - sichere Zertifikatsverwaltung berücksichtigen **Continual Improvement** - zentrale Erfassung, Verantwortlichkeit und Alarmierung verbessern > **Merke** > > Die unmittelbare technische Reparatur kann einen Incident lösen. > > Mehrere weitere Practices können notwendig sein, um eine Wiederholung zu verhindern. --- **Typische Fehler bei der Anwendung von Practices** **Fehler 1: Practice mit Prozess gleichsetzen** Die Organisation dokumentiert einen Ablauf, berücksichtigt aber Rollen, Wissen, Werkzeuge und Partner nicht ausreichend. --- **Fehler 2: Practice mit Team gleichsetzen** Incident Management wird ausschließlich als Aufgabe des Service Desk betrachtet, obwohl technische Teams, Service Owner und Lieferanten beteiligt sein können. --- **Fehler 3: Tool als Ausgangspunkt verwenden** Das Ticketsystem bestimmt Kategorien und Arbeitsweisen, obwohl der tatsächliche Bedarf nicht untersucht wurde. --- **Fehler 4: Practices isoliert optimieren** Jede Practice verbessert ihre eigenen Kennzahlen, während Übergaben und Gesamtdauer schlechter werden. --- **Fehler 5: jede Practice maximal formalisieren** Auch einfache und risikoarme Tätigkeiten erhalten unnötig umfangreiche Prozesse und Freigaben. --- **Fehler 6: nur den Normalfall gestalten** Ausnahmen, Eskalationen, Sicherheitsvorfälle und Lieferantenausfälle werden nicht berücksichtigt. --- **Fehler 7: Verantwortung nicht eindeutig festlegen** Viele Teams sind beteiligt, aber niemand koordiniert das Ende-zu-Ende-Ergebnis. --- **Fehler 8: Messung nur auf Aktivität ausrichten** Gezählt werden Tickets, Changes oder Wissensartikel, aber nicht deren Nutzen und Qualität. --- **Fehler 9: Practice nach Einführung nicht weiterentwickeln** Arbeitsweisen, Werkzeuge und Anforderungen verändern sich, während die Practice unverändert bleibt. --- **Fehler 10: ältere Begriffe ungeprüft übernehmen** ITIL-4-Kategorien oder betriebliche Begriffe werden ohne Versionshinweis als aktuelle ITIL-Version-5-Struktur dargestellt. --- **30-Sekunden-Prüfung einer Practice** Bei der Bewertung einer Practice kannst du folgende Fragen stellen: 1. Welchen Zweck erfüllt die Practice? 2. Welches Outcome soll sie unterstützen? 3. In welchen Wertströmen wird sie verwendet? 4. Wer trägt Verantwortung? 5. Welche Fähigkeiten werden benötigt? 6. Welche Informationen und Werkzeuge sind notwendig? 7. Welche anderen Practices sind beteiligt? 8. Welche Partner oder Lieferanten werden benötigt? 9. Wie wird die Wirksamkeit gemessen? 10. Wie wird die Practice verbessert? --- **Checkliste für den Aufbau einer Practice** - [ ] Ist der konkrete Bedarf bekannt? - [ ] Sind Zweck und gewünschte Outcomes eindeutig? - [ ] Wurde der aktuelle Zustand untersucht? - [ ] Sind relevante Stakeholder beteiligt? - [ ] Sind die betroffenen Wertströme bekannt? - [ ] Sind Rollen, Verantwortung und Befugnisse geklärt? - [ ] Sind benötigte Fähigkeiten und Kapazitäten vorhanden? - [ ] Sind Informationen und Daten ausreichend zuverlässig? - [ ] Sind Prozesse und Kontrollen angemessen? - [ ] Unterstützen Werkzeuge die Arbeitsweise? - [ ] Sind Partner und Lieferanten berücksichtigt? - [ ] Sind Schnittstellen zu anderen Practices geklärt? - [ ] Sind Messgrößen und Erfolgskriterien definiert? - [ ] Wird schrittweise mit Feedback eingeführt? - [ ] Ist Continual Improvement integriert? --- **Checkliste für die Bewertung einer bestehenden Practice** - [ ] Erfüllt die Practice ihren tatsächlichen Zweck? - [ ] Unterstützt sie benötigte Outcomes und Wertströme? - [ ] Sind Verantwortung und Eskalationswege bekannt? - [ ] Werden Arbeitsweisen tatsächlich angewendet? - [ ] Sind Daten und Dokumentationen aktuell? - [ ] Sind Werkzeuge zweckmäßig konfiguriert? - [ ] Funktionieren Übergaben zu anderen Practices? - [ ] Werden Benutzer- und Stakeholdererfahrungen berücksichtigt? - [ ] Entstehen unnötige Wartezeiten oder Freigaben? - [ ] Werden Risiken angemessen behandelt? - [ ] Sind Lieferanten wirksam eingebunden? - [ ] Messen Kennzahlen Ergebnisse statt nur Aktivitäten? - [ ] Werden Automatisierungen überwacht? - [ ] Werden bekannte Schwächen priorisiert verbessert? - [ ] Passt die Practice weiterhin zur Organisation? --- **Schnellreferenz für häufige Arbeitssituationen** | Situation | Häufig beteiligte Practices | |---|---| | Service ist ausgefallen | Incident Management, Service Desk, Monitoring and Event Management | | Fehler tritt wiederholt auf | Problem Management, Knowledge Management, Continual Improvement | | Benutzer benötigt Standardsoftware | Service Request Management, IT Asset Management, Service Desk | | System soll aktualisiert werden | Change Enablement, Release Management, Deployment Management | | Abhängigkeiten sind unklar | Service Configuration Management, Architecture Management | | Hardware oder Lizenz muss verwaltet werden | IT Asset Management, Supplier Management, Service Financial Management | | Sicherheitsrisiko wurde erkannt | Information Security Management, Risk Management, Change Enablement | | Anbieterleistung ist unzureichend | Supplier Management, Service Level Management, Relationship Management | | neue Anwendung wird eingeführt | Service Design, Business Analysis, Architecture Management, Project Management | | Service muss nach Katastrophe wiederhergestellt werden | Service Continuity Management, Incident Management, Availability Management | | Leistung reicht nicht aus | Capacity and Performance Management, Availability Management | | Benutzer verstehen den Service nicht | Service Catalogue Management, Knowledge Management, Relationship Management | | Arbeitsweise soll verbessert werden | Continual Improvement, Measurement and Reporting | | neues Team oder neue Arbeitsweise wird eingeführt | Organizational Change Management, Workforce and Talent Management | --- **Zusammenfassende Darstellung** > Bedarf oder Chance > ↓ > gewünschtes Outcome und Value Stream bestimmen > ↓ > benötigte Management Practices auswählen > ↓ > Menschen · Informationen · Prozesse · Technologie · Partner verbinden > ↓ > Arbeit durchführen und Ergebnisse messen > ↓ > Feedback und Erkenntnisse auswerten > ↓ > Practices und Wertströme kontinuierlich verbessern --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.4 Governance und Verantwortlichkeit - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 2.10 ITIL an den eigenen Kontext anpassen - Service Desk - Incident Management - Service Request Management - Problem Management - Change Enablement - Monitoring and Event Management - 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) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [ITIL: New ITIL Explained for Certified Professionals](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-explained) - [PeopleCert: Frequently Asked Questions about ITIL](https://www.peoplecert.org/help-and-support/faq-itil) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) - [PeopleCert: ITIL 4 Management Practices 2023](https://www.peoplecert.org/news-and-announcements/2023/itil-4-management-practices-2023) - [PeopleCert: ITIL Practice Guides – A Hidden Gem](https://www.peoplecert.org/news-and-announcements/2023/itil-practice-guides-a-hidden-gem) - [ITIL: PeopleCert Plus](https://www.itil.com/professionals/peoplecert-plus) **Offiziell bestätigter Stand** Die offiziellen aktuellen ITIL-Version-5-Informationen bestätigen: - ITIL Version 5 führt weiterhin 34 Management Practices. - Die Practices bleiben gegenüber ITIL 4 weitgehend erhalten. - Anpassungen erfolgen zur Ausrichtung auf die neuen ITIL-Version-5-Inhalte. - Die 34 Practices werden in zwei Gruppen organisiert: - Product and Service Management Practices - General Management Practices - Die vollständigen Practice Guides werden über PeopleCert Plus bereitgestellt. - Die Practice-Manager-Bündel enthalten jeweils fünf ausgewählte Practices. **Hinweis zur Practice-Bezeichnung** Die aktuelle offizielle Beschreibung des Practice-Manager-Moduls **Plan, Implement and Control** verwendet weiterhin die Bezeichnung **Change Enablement**. Deshalb wird diese Practice auf dieser Seite nicht ohne eindeutigen offiziellen Nachweis in **Change Management** umbenannt. **Einordnung** Die alphabetische Übersicht, deutschen Kurzbeschreibungen, Vergleiche, Praxisbeispiele, Checklisten und Arbeitssituationen sind eigene herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebenen Prozesse dar. Die konkrete Gestaltung, Priorisierung und Ausprägung einer Practice muss an Ziele, Risiken, Fähigkeiten und Wertströme der jeweiligen Organisation angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.8 Value Streams und Value Stream Mapping > **Kurz erklärt** > > Ein Value Stream beschreibt den Ende-zu-Ende-Weg, durch den aus einem Bedarf, einer Nachfrage oder einer Chance ein nutzbares Ergebnis und Wert für Stakeholder entstehen. > > Value Stream Mapping macht diesen Weg sichtbar. > > Dabei werden nicht nur einzelne Prozessschritte betrachtet, sondern auch: > > - beteiligte Personen und Teams, > - Management Practices, > - Informationen, > - Technologien, > - Partner und Lieferanten, > - Entscheidungen, > - Kontrollen, > - Übergaben, > - Wartezeiten, > - Nacharbeit, > - Risiken, > - und Rückmeldungen. > > Ziel ist nicht, ein besonders umfangreiches Ablaufdiagramm zu erstellen. > > Ziel ist, den tatsächlichen Arbeitsfluss zu verstehen und gezielt zu verbessern. --- **Warum Value Streams wichtig sind** Digitale Produkte und Services entstehen normalerweise nicht innerhalb eines einzigen Teams. Ein benötigtes Outcome kann Beiträge erfordern von: - Benutzern, - Fachabteilungen, - Service Desk, - Systemadministration, - Netzwerkbetrieb, - Entwicklung, - Informationssicherheit, - Einkauf, - Personalabteilung, - Lieferanten, - Cloud-Providern, - und Führungskräften. Jeder Beteiligte kann seinen eigenen Arbeitsschritt korrekt ausführen. Der gesamte Ablauf kann trotzdem: - langsam, - unübersichtlich, - fehleranfällig, - unnötig kompliziert, - oder für den Benutzer unbefriedigend sein. Beispiel: Ein neuer Mitarbeiter benötigt einen arbeitsfähigen IT-Arbeitsplatz. Alle beteiligten Teams können ihre jeweilige Aufgabe korrekt ausführen: - Personalabteilung meldet den Eintritt. - Führungskraft nennt benötigte Zugriffe. - Einkauf bestellt das Endgerät. - IT erstellt das Benutzerkonto. - Informationssicherheit prüft Berechtigungen. - Service Desk übergibt das Gerät. Der Mitarbeiter kann am ersten Arbeitstag trotzdem nicht arbeiten, wenn: - die Meldung zu spät erfolgte, - notwendige Informationen fehlten, - eine Freigabe liegen blieb, - die Lizenz nicht verfügbar war, - das Endgerät nicht rechtzeitig geliefert wurde, - oder niemand das Ende-zu-Ende-Ergebnis kontrollierte. > **Merke** > > Die Qualität einzelner Arbeitsschritte garantiert noch kein gutes Ende-zu-Ende-Ergebnis. --- **Was ist ein Value Stream?** Ein Value Stream ist eine zusammenhängende Abfolge von Schritten, durch die ein bestimmtes Outcome und Wert für einen Stakeholder ermöglicht werden. Ein Value Stream besitzt normalerweise: - einen erkennbaren Auslöser, - einen bestimmten Bedarf oder eine Chance, - einen oder mehrere Stakeholder, - ein gewünschtes Outcome, - mehrere miteinander verbundene Schritte, - beteiligte Rollen und Fähigkeiten, - benötigte Informationen und Technologien, - sowie ein überprüfbares Ergebnis. Beispiele für Value Streams: - neuen Mitarbeiter arbeitsfähig machen - einen Incident bearbeiten und den Service wiederherstellen - einen genehmigten Zugriff bereitstellen - eine neue Anwendung einführen - eine Schwachstelle dauerhaft beheben - einen Arbeitsplatz austauschen - einen Service verbessern - eine neue Produktfunktion bereitstellen - einen Lieferanten ablösen - einen nicht mehr benötigten Service außer Betrieb nehmen > **Wichtig** > > Ein Value Stream sollte anhand des benötigten Outcomes benannt werden. > > Ein Name wie „Ticket bearbeiten“ ist häufig zu eng. > > Ein geeigneterer Name kann beispielsweise lauten: > > „Benutzer nach einer Störung wieder arbeitsfähig machen.“ --- **Auslöser, Output, Outcome und Wert** Diese Begriffe müssen unterschieden werden. | Begriff | Bedeutung | Beispiel | |---|---|---| | **Auslöser** | Ereignis, Nachfrage oder Chance, die den Wertstrom startet | neuer Mitarbeiter tritt ein | | **Input** | benötigte Informationen oder Ressourcen | Eintrittsdatum, Rolle und genehmigte Zugriffe | | **Aktivität** | durchgeführter Arbeitsschritt | Benutzerkonto erstellen | | **Output** | direkt erzeugtes Ergebnis einer Aktivität | Benutzerkonto wurde angelegt | | **Outcome** | durch Stakeholder ermöglichtes Ergebnis | Mitarbeiter kann seine Aufgaben ausführen | | **Wert** | wahrgenommener Nutzen unter Berücksichtigung von Outcomes, Kosten und Risiken | produktiver und sicherer Arbeitsbeginn | Ein Output ist nicht automatisch das gewünschte Outcome. Beispiel: > **Output:** Das VPN wurde installiert. > > **Outcome:** Der Benutzer kann sicher auf die benötigten Anwendungen zugreifen. > **Merke** > > Value Streams werden vom benötigten Outcome aus betrachtet und nicht nur anhand erledigter technischer Tätigkeiten. --- **Value Stream und Value Stream Mapping** | Begriff | Bedeutung | |---|---| | **Value Stream** | tatsächlicher oder geplanter Ende-zu-Ende-Weg zum Outcome | | **Value Stream Mapping** | strukturierte Darstellung und Untersuchung dieses Weges | | **Value Stream Management** | fortlaufende Steuerung, Messung und Verbesserung des Wertstroms | Value Stream Mapping ist damit keine einmalige Zeichenübung. Die Abbildung soll dabei helfen: - tatsächliche Arbeit sichtbar zu machen, - Probleme und Engpässe zu erkennen, - Verbesserungen zu priorisieren, - Verantwortlichkeiten zu klären, - und die Wirkung von Änderungen später zu überprüfen. --- **Value Stream, Value Chain und Lifecycle unterscheiden** | Begriff | Bedeutung | |---|---| | **ITIL Value System** | übergeordneter Rahmen für Wertschöpfung innerhalb der Organisation | | **Value Chain** | flexibles operatives Modell innerhalb des ITIL Value Systems | | **Product and Service Lifecycle** | acht allgemeine Aktivitäten über den Lebenszyklus digitaler Produkte und Services | | **Value Stream** | konkrete Ende-zu-Ende-Abfolge für ein bestimmtes Outcome | | **Prozess** | strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen | | **Management Practice** | organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck | | **Customer oder User Journey** | Erfahrung eines Kunden oder Benutzers über mehrere Interaktionen hinweg | Beispiel: neue Anwendung für eine Fachabteilung **Lifecycle** - Discover - Design - Acquire - Build - Transition - Operate - Deliver - Support **Value Stream** > Bedarf der Fachabteilung erfassen > → Lösung auswählen und bereitstellen > → Benutzer befähigen > → produktive Nutzung bestätigen **Beteiligte Practices** - Business Analysis - Service Design - Architecture Management - Supplier Management - Change Enablement - Deployment Management - Information Security Management - Service Desk - Continual Improvement **Prozesse** - Beschaffung - Change-Bewertung - Benutzeranlage - Softwareverteilung - Support **User Journey** - Bedarf melden - Informationen erhalten - Anwendung testen - Schulung nutzen - Support anfordern - Erfahrung bewerten > **Merke** > > Der Lifecycle stellt allgemeine Aktivitäten bereit. > > Der Value Stream zeigt den konkreten Weg zum Outcome. > > Practices liefern die dafür benötigten Fähigkeiten. --- **Value Streams überschreiten Organisationsgrenzen** Ein Value Stream endet nicht automatisch an einer Team-, Abteilungs- oder Unternehmensgrenze. Beispiel: Internetzugang eines Standorts wiederherstellen Mögliche Beteiligte: - Benutzer am Standort - Service Desk - Netzwerkteam - lokaler Techniker - Internetprovider - Hardwarehersteller - Incident-Koordination - Service Owner Der Wertstrom endet nicht bereits dann, wenn das interne Netzwerkteam ein Ticket an den Provider übermittelt hat. Er endet erst, wenn das gewünschte Outcome erreicht oder eine andere vereinbarte Entscheidung getroffen wurde. Mögliches Outcome: > Der Standort besitzt wieder einen stabilen und ausreichend leistungsfähigen Internetzugang. > **Typischer Fehler** > > Ein Team betrachtet seinen eigenen Arbeitsschritt als abgeschlossen, obwohl das Ende-zu-Ende-Outcome noch nicht erreicht wurde. --- **Die Grenzen eines Value Streams festlegen** Vor der Abbildung muss geklärt werden: - Welches konkrete Outcome wird betrachtet? - Welches Ereignis startet den Wertstrom? - Wann gilt der Wertstrom als abgeschlossen? - Für welche Benutzer- oder Kundengruppe gilt er? - Welche Produkt- oder Servicevariante wird untersucht? - Welche Ausnahmen gehören noch zum Umfang? - Welche angrenzenden Wertströme werden nicht betrachtet? Unklare Abgrenzung: > Wir bilden den gesamten IT-Support ab. Bessere Abgrenzung: > Wir bilden den Wertstrom ab, durch den ein Benutzer nach einer gemeldeten Arbeitsplatzstörung wieder arbeitsfähig wird. Eine klare Grenze verhindert, dass die Darstellung: - zu groß, - unübersichtlich, - nicht messbar, - oder praktisch nicht verbesserbar wird. --- **Aktueller und zukünftiger Zustand** Beim Value Stream Mapping werden häufig zwei Zustände unterschieden. | Zustand | Zweck | |---|---| | **Ist-Zustand** | zeigt, wie die Arbeit tatsächlich heute erfolgt | | **Zielzustand** | zeigt, wie der verbesserte Wertstrom künftig funktionieren soll | Der Ist-Zustand darf nicht ausschließlich aus vorhandenen Prozessdokumentationen übernommen werden. Er sollte anhand tatsächlicher Informationen untersucht werden. Geeignete Quellen können sein: - Beobachtung realer Vorgänge, - Tickets, - Systemprotokolle, - Monitoring-Daten, - Zeitmessungen, - Gespräche mit Beteiligten, - Benutzerfeedback, - bestehende Dokumentationen, - Lieferanteninformationen, - und Stichproben. > **Wichtig** > > Dokumentierter Prozess und tatsächlich gelebter Ablauf können deutlich voneinander abweichen. --- **Was in einer Value-Stream-Darstellung enthalten sein kann** Eine praktische Darstellung kann folgende Elemente enthalten: | Element | Beispiel | |---|---| | **Auslöser** | Benutzer meldet einen Incident | | **Stakeholder** | Benutzer, Service Desk und technisches Team | | **gewünschtes Outcome** | Benutzer kann wieder arbeiten | | **Schritt** | Incident erfassen | | **verantwortliche Rolle** | Service-Desk-Mitarbeiter | | **benötigte Information** | Symptome und betroffener Service | | **verwendetes Werkzeug** | Ticketsystem | | **beteiligte Practice** | Incident Management | | **Bearbeitungszeit** | 10 Minuten | | **Wartezeit** | 45 Minuten | | **Übergabe** | Service Desk an Netzwerkteam | | **Entscheidung** | Eskalation erforderlich? | | **Kontrolle** | Benutzer bestätigt Wiederherstellung | | **Nacharbeit** | Ticket wegen fehlender Informationen zurückgegeben | | **Lieferant** | Internetprovider | | **Risiko** | falsche Priorisierung | | **Messgröße** | gesamte Wiederherstellungszeit | | **Verbesserungsmöglichkeit** | Pflichtinformationen bei Erfassung verbessern | Nicht jede Darstellung muss alle Elemente enthalten. Der Detaillierungsgrad richtet sich nach: - Ziel der Untersuchung, - Risiko, - Komplexität, - verfügbarer Zeit, - und benötigter Entscheidung. --- **Eine einfache Darstellungsform** Für kleinere Wertströme kann eine Tabelle ausreichen. | Nr. | Schritt | Verantwortlich | Ergebnis | Bearbeitungszeit | Wartezeit | Problem | |---:|---|---|---|---:|---:|---| | 1 | Anfrage erfassen | Service Desk | vollständiges Ticket | 10 Min. | 0 Min. | Pflichtangaben fehlen häufig | | 2 | Zugriff prüfen | Fachverantwortlicher | fachliche Freigabe | 5 Min. | 2 Tage | keine Vertretung | | 3 | Zugriff einrichten | Administration | technische Berechtigung | 15 Min. | 4 Std. | manuelle Gruppensuche | | 4 | Funktion testen | Administration | technischer Test | 10 Min. | 0 Min. | Benutzer nicht beteiligt | | 5 | Nutzung bestätigen | Benutzer | bestätigtes Outcome | 5 Min. | 1 Tag | Rückmeldung wird nicht nachverfolgt | Gesamte Bearbeitungszeit: > 45 Minuten Gesamte Wartezeit: > mehr als 3 Tage Das Beispiel zeigt: Die lange Durchlaufzeit entsteht nicht hauptsächlich durch langsame technische Ausführung. Sie entsteht überwiegend durch: - Warteschlangen, - fehlende Vertretung, - manuelle Übergaben, - und verzögerte Rückmeldungen. --- **Bearbeitungszeit und Durchlaufzeit unterscheiden** | Begriff | Bedeutung | |---|---| | **Bearbeitungszeit** | Zeit, in der aktiv an einem Vorgang gearbeitet wird | | **Wartezeit** | Zeit, in der keine wertstromrelevante Bearbeitung erfolgt | | **Durchlaufzeit** | gesamte Zeit vom Auslöser bis zum abgeschlossenen Outcome | | **Übergabezeit** | Zeit und Aufwand beim Wechsel zwischen Rollen, Teams oder Systemen | | **Nacharbeitszeit** | zusätzlicher Aufwand aufgrund unvollständiger oder fehlerhafter Arbeit | Beispiel: - aktive Bearbeitung: 40 Minuten - Wartezeit: 3 Tage - Nacharbeit: 20 Minuten - gesamte Durchlaufzeit: mehr als 3 Tage > **Merke** > > Eine lange Durchlaufzeit bedeutet nicht automatisch, dass Mitarbeiter langsam arbeiten. > > Häufig entstehen Verzögerungen zwischen den aktiven Arbeitsschritten. --- **Weitere mögliche Messgrößen** Je nach Wertstrom können unter anderem betrachtet werden: - gesamte Durchlaufzeit - aktive Bearbeitungszeit - Wartezeit - Anzahl der Übergaben - Anzahl beteiligter Teams - Anzahl notwendiger Freigaben - Nacharbeitsquote - Fehlerquote - Abbruchquote - Wiederholungsquote - Automatisierungsgrad - First-Time-Right-Quote - Wiederherstellungszeit - Benutzeraufwand - Kosten pro Vorgang - Erreichung des gewünschten Outcomes - Benutzer- oder Kundenerfahrung - Anzahl ungeklärter Ausnahmen Eine einzelne Kennzahl sollte nicht isoliert optimiert werden. Beispiel: Eine geringere Bearbeitungszeit kann erreicht werden, indem Tickets schneller an andere Teams weitergegeben werden. Dadurch können jedoch: - mehr Übergaben, - längere Gesamtdauer, - schlechtere Kommunikation, - und mehr Nacharbeit entstehen. --- **Übergaben sichtbar machen** Übergaben sind Stellen, an denen Arbeit, Verantwortung oder Informationen von einer Rolle, einem Team oder einem System zu einem anderen wechseln. Beispiele: - Benutzer an Service Desk - Service Desk an Fachteam - internes Team an Lieferanten - Entwicklung an Betrieb - Einkauf an technische Administration - Führungskraft an Berechtigungsmanagement - automatisiertes System an menschlichen Bearbeiter An Übergaben können entstehen: - Informationsverluste, - Missverständnisse, - Wartezeiten, - doppelte Erfassung, - unklare Verantwortung, - falsche Priorisierung, - und Rückfragen. Bei jeder Übergabe sollte geprüft werden: - Welche Informationen werden benötigt? - Sind sie vollständig und verständlich? - Wer trägt danach die Verantwortung? - Ist der nächste Schritt eindeutig? - Wie wird der Empfang bestätigt? - Muss das Ergebnis zurückgemeldet werden? - Ist die Übergabe überhaupt notwendig? - Kann sie vereinfacht oder automatisiert werden? --- **Warteschlangen und Engpässe** Ein Engpass begrenzt den Fluss des gesamten Wertstroms. Mögliche Engpässe sind: - einzelne Fachpersonen, - manuelle Genehmigungen, - fehlende Informationen, - begrenzte Testumgebungen, - Lieferzeiten, - unzureichende Lizenzen, - langsame technische Systeme, - überlastete Teams, - oder nicht automatisierte Routinetätigkeiten. Anzeichen für einen Engpass: - Vorgänge sammeln sich vor einem bestimmten Schritt. - Die Wartezeit ist deutlich länger als die Bearbeitungszeit. - Viele Vorgänge benötigen dieselbe einzelne Person. - Nachgelagerte Teams warten regelmäßig auf Ergebnisse. - Aufgaben werden häufig eskaliert. - Mitarbeiter umgehen den vorgesehenen Ablauf. - Prioritäten werden ständig geändert. - Fehler entstehen durch Zeitdruck. > **Wichtig** > > Wird nur ein Schritt vor dem eigentlichen Engpass beschleunigt, kann sich die Warteschlange am Engpass weiter vergrößern. --- **Nacharbeit und Rückschleifen** Nacharbeit entsteht, wenn ein Schritt erneut durchgeführt oder korrigiert werden muss. Mögliche Ursachen: - unvollständige Anforderungen - falsche Kategorisierung - fehlende Freigabe - fehlerhafte technische Umsetzung - ungeeignete Testdaten - unklare Verantwortlichkeiten - veraltete Dokumentation - widersprüchliche Informationen - nicht berücksichtigte Abhängigkeiten - fehlende Benutzerbestätigung Beispiel: 1. Benutzer beantragt Zugriff. 2. Administration richtet den Zugriff ein. 3. Fachverantwortlicher stellt fest, dass der falsche Berechtigungsumfang gewählt wurde. 4. Zugriff muss entfernt und erneut eingerichtet werden. Die Nacharbeit erhöht: - Durchlaufzeit, - Kosten, - Risiko, - und Arbeitsbelastung. Sie kann außerdem das Vertrauen der Stakeholder beeinträchtigen. --- **Kontrollen und Freigaben untersuchen** Kontrollen können notwendig sein für: - Sicherheit, - Datenschutz, - Qualität, - Risiko, - gesetzliche Anforderungen, - finanzielle Verantwortung, - und Nachvollziehbarkeit. Beim Mapping sollte nicht automatisch jede Kontrolle entfernt werden. Stattdessen wird geprüft: - Welches Risiko behandelt die Kontrolle? - Ist sie an der richtigen Stelle? - Wird sie tatsächlich fachlich durchgeführt? - Ist sie mehrfach vorhanden? - Passt ihr Umfang zum Risiko? - Sind Entscheidungskriterien eindeutig? - Besteht eine Vertretung? - Kann die Kontrolle automatisiert unterstützt werden? - Werden Ergebnisse dokumentiert? - Wird die Kontrolle regelmäßig auf ihre Wirksamkeit geprüft? > **Typischer Fehler** > > Eine Genehmigung wird entfernt, nur weil sie Zeit kostet. > > Zuerst muss verstanden werden, welches Risiko oder welche Verpflichtung sie behandelt. --- **Arbeit mit und ohne direkten Wertbeitrag** Nicht jeder notwendige Schritt erzeugt unmittelbar einen für den Benutzer sichtbaren Wert. Eine praktische Unterscheidung kann sein: | Kategorie | Bedeutung | Beispiel | |---|---|---| | **direkter Wertbeitrag** | unterstützt unmittelbar das gewünschte Outcome | benötigten Zugriff bereitstellen | | **notwendige unterstützende Arbeit** | ist für Sicherheit, Steuerung oder Zuverlässigkeit erforderlich | Berechtigung prüfen | | **vermeidbare Arbeit** | besitzt keinen ausreichenden Nutzen oder entsteht durch Fehler | dieselben Daten erneut erfassen | | **Nacharbeit** | korrigiert unvollständige oder fehlerhafte Ergebnisse | falsche Berechtigung entfernen | Nicht sichtbare Arbeit ist nicht automatisch unnötig. Beispiele für notwendige unterstützende Tätigkeiten: - Sicherheitsprüfung - Protokollierung - Dokumentation - Test - Backup - Freigabe - Compliance-Nachweis Diese Tätigkeiten sollten jedoch: - einen klaren Zweck besitzen, - angemessen gestaltet, - und möglichst effizient ausgeführt werden. --- **Value Stream Mapping und die vier Dimensionen** Eine vollständige Untersuchung berücksichtigt alle vier Dimensionen. **Organizations and People** - Welche Rollen und Teams sind beteiligt? - Sind Verantwortung und Befugnisse eindeutig? - Bestehen ausreichende Fähigkeiten und Kapazitäten? - Wie funktionieren Kommunikation und Zusammenarbeit? **Information and Technology** - Welche Informationen werden benötigt? - Welche Systeme und Werkzeuge werden verwendet? - Sind Daten korrekt und aktuell? - Wo bestehen Medienbrüche oder manuelle Übertragungen? - Welche Automatisierung ist möglich? **Partners and Suppliers** - Welche externen Anbieter sind beteiligt? - Welche Wartezeiten und Abhängigkeiten entstehen? - Sind Eskalationswege vorbereitet? - Unterstützen Verträge das benötigte Outcome? **Value Streams and Processes** - Welche Schritte, Entscheidungen und Übergaben existieren? - Wo entstehen Wartezeiten, Nacharbeit und Engpässe? - Welche Prozesse und Practices werden verwendet? - Wie wird das Outcome überprüft? --- **Value Streams und der Product and Service Lifecycle** Die acht Lifecycle-Aktivitäten können in einem Value Stream unterschiedlich kombiniert werden. Beispiel: neue Monitoring-Lösung einführen | Lifecycle-Aktivität | Möglicher Beitrag zum Value Stream | |---|---| | **Discover** | Bedarf, Ausfälle und heutige Überwachung verstehen | | **Design** | Zielarchitektur, Alarmierung und Betriebsmodell gestalten | | **Acquire** | Plattform, Lizenzen oder externe Leistungen beschaffen | | **Build** | Lösung konfigurieren, integrieren und testen | | **Transition** | Pilot und kontrollierte Einführung durchführen | | **Operate** | Plattform zuverlässig betreiben | | **Deliver** | relevante Monitoring-Leistungen für Teams bereitstellen | | **Support** | Benutzer und Administratoren bei Problemen unterstützen | Ein anderer Value Stream verwendet möglicherweise nur einen Teil dieser Aktivitäten oder wiederholt einzelne Aktivitäten mehrfach. > **Merke** > > Der Lifecycle liefert allgemeine Aktivitätsbereiche. > > Der Value Stream verbindet die konkret benötigten Schritte für ein bestimmtes Outcome. --- **Value Streams und Management Practices** Ein Value Stream verwendet normalerweise mehrere Practices. Beispiel: Incident eines extern betriebenen Cloud-Service | Schritt | Mögliche beteiligte Practice | |---|---| | Störung erkennen | Monitoring and Event Management | | Benutzerkontakt erfassen | Service Desk | | Auswirkungen und Priorität bewerten | Incident Management | | Abhängigkeiten ermitteln | Service Configuration Management | | bekannte Lösung suchen | Knowledge Management | | Anbieter einbinden | Supplier Management | | Service wiederherstellen | Incident Management und technische Practices | | Ursache untersuchen | Problem Management | | dauerhafte Korrektur steuern | Change Enablement | | Erfahrung auswerten | Continual Improvement | Practices dürfen dabei nicht als getrennte Teilprozesse betrachtet werden, zwischen denen ein Vorgang nur weitergereicht wird. Sie sollen gemeinsam das Ende-zu-Ende-Outcome unterstützen. --- **Praxisnahe Vorgehensweise zum Value Stream Mapping** Die folgende Vorgehensweise ist eine redaktionelle Praxisempfehlung dieses Buches. Sie ist keine vorgeschriebene offizielle ITIL-Schrittfolge. --- **1. Zweck und Outcome festlegen** Zuerst wird geklärt: - Welcher Value Stream wird untersucht? - Welches Problem soll gelöst werden? - Welches Outcome soll erreicht werden? - Für welche Stakeholder? - Wie wird Erfolg erkannt? Beispiel: > Ziel ist, neue Mitarbeiter spätestens zum vereinbarten Eintrittszeitpunkt mit einem vollständig nutzbaren und sicheren IT-Arbeitsplatz auszustatten. --- **2. Auslöser und Abschluss bestimmen** Auslöser: > Die Personalabteilung übermittelt eine vollständige und bestätigte Eintrittsmeldung. Abschluss: > Der Mitarbeiter bestätigt, dass Anmeldung, Endgerät und benötigte Services funktionieren. Dadurch wird vermieden, dass der Wertstrom zu früh endet. --- **3. Beteiligte Stakeholder bestimmen** Mögliche Beteiligte: - neuer Mitarbeiter - Personalabteilung - Führungskraft - Service Desk - Einkauf - IT Asset Management - Identitätsmanagement - Endgeräteverwaltung - Informationssicherheit - Lieferant Zusätzlich sollte geklärt werden: - Wer besitzt die Ergebnisverantwortung? - Wer koordiniert den Wertstrom? - Wer darf Entscheidungen treffen? - Wer muss informiert werden? --- **4. Tatsächliche Schritte erfassen** Die Beteiligten beschreiben, wie ein realer Vorgang heute abläuft. Nicht nur: > Wie sollte der Prozess funktionieren? Sondern: > Was geschieht tatsächlich? Dabei können reale Tickets oder Fälle verfolgt werden. Mögliche Schritte: 1. Eintritt melden 2. Rolle und Zugriffe bestimmen 3. Freigaben einholen 4. Endgerät bestellen 5. Benutzerkonto erstellen 6. Lizenzen zuweisen 7. Endgerät konfigurieren 8. Sicherheitsmaßnahmen aktivieren 9. Zugriffe testen 10. Gerät übergeben 11. Arbeitsfähigkeit bestätigen --- **5. Informationen, Werkzeuge und Practices ergänzen** Für jeden Schritt wird geprüft: - Welche Information wird benötigt? - Woher stammt sie? - In welchem System wird sie gespeichert? - Welches Werkzeug wird verwendet? - Welche Practice unterstützt den Schritt? - Welche Lieferanten sind beteiligt? Beispiel: | Schritt | Information | Werkzeug | Practice | |---|---|---|---| | Endgerät bereitstellen | Rolle und Hardwarestandard | Asset- und Ticketsystem | IT Asset Management | | Konto erstellen | Name, Eintrittsdatum und Organisationseinheit | Verzeichnisdienst | Service Request Management | | Zugriffe einrichten | genehmigter Berechtigungsumfang | IAM-System | Information Security Management | | Nutzung bestätigen | Benutzerfeedback | Ticket oder Portal | Service Desk | --- **6. Zeiten und Übergaben erfassen** Für jeden Schritt können erfasst werden: - Bearbeitungszeit - Wartezeit - Übergabe - Rückfrage - Wiederholung - Fehler - und Abbruch Nicht jede Zeit muss auf die Minute genau bekannt sein. Auch eine erste Einteilung kann hilfreich sein: - wenige Minuten - mehrere Stunden - ein Arbeitstag - mehrere Tage - stark schwankend --- **7. Probleme und Risiken kennzeichnen** Mögliche Beobachtungen: - Eintrittsmeldung kommt zu spät. - Führungskraft nennt unvollständige Zugriffe. - Bestellung benötigt manuelle E-Mail. - Es gibt keine Vertretung für die Freigabe. - Kontoanlage und Lizenzzuweisung erfolgen in getrennten Systemen. - Benutzer wird bei der Funktionsprüfung nicht beteiligt. - Lieferzeit ist nicht transparent. - Abschluss erfolgt ohne Bestätigung der Arbeitsfähigkeit. Probleme sollten möglichst mit Fakten oder Beispielen belegt werden. --- **8. Ursachen untersuchen** Nicht jedes sichtbare Problem ist die eigentliche Ursache. Beispiel: > Symptom: Endgerät ist am ersten Arbeitstag nicht verfügbar. Mögliche Ursachen: - Eintritt wurde zu spät gemeldet. - Gerätebestand ist nicht bekannt. - Beschaffung dauert länger als geplant. - Hardwarestandard ist unklar. - Bestellung benötigt mehrere Freigaben. - kein Mindestbestand ist definiert. - Lieferantenleistung wird nicht überwacht. Eine Verbesserung sollte möglichst die relevante Ursache behandeln und nicht nur das Symptom verschieben. --- **9. Zielzustand gestalten** Der Zielzustand beschreibt, wie der Wertstrom künftig funktionieren soll. Mögliche Verbesserungen: - vollständiges digitales Eintrittsformular - klare Mindestvorlaufzeit - rollenbasierte Standardpakete - definierte Vertretungsregelung - transparenter Gerätebestand - automatische Kontoanlage nach Freigabe - gemeinsame Statusübersicht - standardisierte Funktionsprüfung - verbindliche Bestätigung der Arbeitsfähigkeit - Messung von Durchlaufzeit und Fehlern Der Zielzustand sollte: - verständlich, - realistisch, - risikogerecht, - und messbar sein. --- **10. Verbesserungen priorisieren und umsetzen** Verbesserungen können bewertet werden nach: - erwarteter Wirkung - Dringlichkeit - Risiko - Aufwand - Kosten - Abhängigkeiten - Umsetzbarkeit - und benötigten Fähigkeiten Nicht alle Verbesserungen müssen gleichzeitig umgesetzt werden. Ein iteratives Vorgehen kann beispielsweise beginnen mit: 1. vollständige Eintrittsmeldung sicherstellen 2. klare Verantwortlichkeit festlegen 3. Status sichtbar machen 4. Standardpakete definieren 5. geeignete Schritte automatisieren 6. Wirkung messen 7. weitere Engpässe bearbeiten --- **Value Stream Management nach dem Mapping** Nach der ersten Abbildung muss der Wertstrom fortlaufend gesteuert werden. Dazu gehören: - Verantwortlichkeit festlegen - relevante Messgrößen überwachen - Abweichungen untersuchen - Feedback auswerten - Risiken beobachten - Verbesserungen priorisieren - Änderungen am Wertstrom kontrollieren - Dokumentation aktuell halten - und den Wertstrom regelmäßig erneut betrachten Mögliche Fragen: - Wird das gewünschte Outcome erreicht? - Hat sich die Durchlaufzeit verbessert? - Entsteht weniger Nacharbeit? - Wurden Engpässe nur verlagert? - Hat sich die Benutzererfahrung verbessert? - Sind neue Risiken entstanden? - Werden Kontrollen weiterhin wirksam durchgeführt? - Passen die Messgrößen noch zum Ziel? --- **Governance von Value Streams** Für wichtige Value Streams sollte geklärt sein: - Wer trägt die Ende-zu-Ende-Verantwortung? - Welche Outcomes und Ziele gelten? - Welche Risiken dürfen akzeptiert werden? - Welche Kontrollen sind verbindlich? - Wer darf den Wertstrom verändern? - Wie werden Leistung und Abweichungen überwacht? - Wie werden Konflikte zwischen Teams entschieden? - Welche Verbesserungen erhalten Priorität? - Welche Lieferantenabhängigkeiten bestehen? Ein Value Stream kann mehrere organisatorische Verantwortungsbereiche überschreiten. Trotzdem muss eine geeignete Koordination des Gesamtergebnisses bestehen. > **Typischer Fehler** > > Jeder Schritt besitzt einen Verantwortlichen, aber niemand verantwortet das gesamte Ende-zu-Ende-Outcome. --- **Value Stream Mapping bei einem Incident** Beispielwertstrom: > Benutzer nach einem Serviceausfall wieder arbeitsfähig machen Mögliche Schritte: 1. Störung erkennen oder melden 2. Incident erfassen 3. Auswirkungen und Dringlichkeit bewerten 4. betroffenen Service bestimmen 5. erste Diagnose durchführen 6. zuständiges Fachwissen einbinden 7. Service wiederherstellen 8. Funktion technisch prüfen 9. Nutzbarkeit mit dem Benutzer bestätigen 10. Kommunikation abschließen 11. notwendige Folgeaktivitäten einleiten Mögliche Probleme: - Benutzer muss dieselben Informationen mehrfach nennen. - Ticket wird mehrfach weitergeleitet. - Serviceabhängigkeiten sind unbekannt. - Lieferantenkontakt beginnt zu spät. - Statusinformationen sind widersprüchlich. - technische Wiederherstellung wird nicht aus Benutzersicht geprüft. - wiederkehrende Incidents werden nicht an Problem Management übergeben. Mögliche Messgrößen: - Zeit bis zur Erfassung - Zeit bis zur ersten qualifizierten Reaktion - gesamte Wiederherstellungszeit - Anzahl der Übergaben - erneute Kontaktaufnahme - wiederholte Incidents - Benutzerbestätigung - Qualität der Kommunikation --- **Value Stream Mapping bei einem Service Request** Beispielwertstrom: > genehmigte Standardsoftware für einen Benutzer nutzbar bereitstellen Mögliche Schritte: 1. Software anfordern 2. Berechtigung und Bedarf prüfen 3. Lizenzverfügbarkeit kontrollieren 4. erforderliche Freigabe einholen 5. Software bereitstellen 6. Installation oder Zuweisung prüfen 7. Benutzer informieren 8. Nutzbarkeit bestätigen 9. Asset- und Lizenzinformationen aktualisieren Mögliche Verbesserungen: - verständliches Serviceangebot - rollenbasierte Standardgenehmigung - automatische Lizenzprüfung - automatisierte Softwareverteilung - automatische Statusinformationen - technische Erfolgskontrolle - Abschluss erst nach bestätigter Nutzbarkeit --- **Value Stream Mapping bei einem Change** Beispielwertstrom: > Sicherheitsupdate kontrolliert und ohne vermeidbare Serviceunterbrechung bereitstellen Mögliche Schritte: 1. Handlungsbedarf erkennen 2. betroffene Produkte und Services bestimmen 3. Risiko und Dringlichkeit bewerten 4. Update testen 5. Umsetzungs- und Rückfallplan erstellen 6. Autorisierung einholen 7. Beteiligte informieren 8. Update bereitstellen 9. technische Funktion prüfen 10. Service-Nutzbarkeit prüfen 11. Monitoring fortführen 12. Dokumentation und Konfigurationsinformationen aktualisieren Mögliche Probleme: - unklare Abhängigkeiten - fehlende Testumgebung - lange Wartezeit auf Freigabe - manuelle Wiederholung derselben Prüfungen - fehlende Rückfallkriterien - Service Desk wird nicht informiert - technischer Erfolg wird ohne Serviceprüfung angenommen --- **Value Streams und Automatisierung** Automatisierung kann den Fluss verbessern, wenn: - der Wertstrom verstanden wurde, - Eingabedaten zuverlässig sind, - Regeln eindeutig sind, - Ausnahmen behandelt werden, - und Ergebnisse kontrolliert werden. Geeignete Beispiele: - automatische Ticketanlage aus relevanten Events - automatische Vollständigkeitsprüfung von Anträgen - standardisierte Genehmigungsweiterleitung - automatische Softwareverteilung - automatische Aktualisierung von Asset-Daten - Statusbenachrichtigungen - automatische technische Tests - Erkennung von Wartezeiten und Eskalationsbedarf Ungeeignet ist Automatisierung, wenn: - der Ablauf unklar ist, - Verantwortlichkeiten fehlen, - Eingabedaten unzuverlässig sind, - Ausnahmen nicht bekannt sind, - oder der Schritt keinen ausreichenden Nutzen besitzt. > **Grundsatz** > > Einen schlechten Wertstrom zu automatisieren kann dazu führen, dass Fehler und Verschwendung nur schneller ausgeführt werden. --- **Künstliche Intelligenz in Value Streams** KI kann innerhalb von Value Streams beispielsweise unterstützen bei: - Klassifizierung von Anfragen - Erkennung ähnlicher Vorgänge - Zusammenfassung von Informationen - Prognose möglicher Engpässe - Analyse von Durchlaufzeiten - Vorschlägen für passende Wissensartikel - Erkennung wiederkehrender Muster - und Unterstützung der Kommunikation Dabei müssen unter anderem berücksichtigt werden: - Datenqualität - Datenschutz - Informationssicherheit - Nachvollziehbarkeit - mögliche Verzerrungen - menschliche Kontrolle - Fehlerbehandlung - und Verantwortung Beispiel: Eine KI schlägt die automatische Genehmigung eines Zugriffs vor. Vor einer solchen Automatisierung muss geklärt sein: - Welche Zugriffe dürfen standardisiert genehmigt werden? - Welche Rollen und Risiken sind betroffen? - Welche Daten verwendet die KI? - Wer überprüft Ausnahmen? - Wie werden falsche Entscheidungen erkannt? - Wer trägt die Ergebnisverantwortung? > **Sicherheitsrelevant** > > Die Verwendung von KI verändert nicht automatisch bestehende Verantwortlichkeiten und Governance-Anforderungen. --- **Value Streams und Continual Improvement** Value Stream Mapping liefert eine Grundlage für Continual Improvement. Möglicher Verbesserungszyklus: 1. benötigtes Outcome bestimmen 2. aktuellen Wertstrom erfassen 3. Daten und Feedback sammeln 4. Engpässe und Risiken erkennen 5. Ursachen untersuchen 6. Zielzustand gestalten 7. Verbesserungen priorisieren 8. schrittweise umsetzen 9. Wirkung messen 10. Wertstrom erneut bewerten Verbesserungen können betreffen: - einzelne Schritte, - Übergaben, - Informationen, - Rollen, - Technologien, - Lieferanten, - Kontrollen, - oder den gesamten Aufbau des Wertstroms. > **Merke** > > Value Stream Mapping zeigt nicht nur, wo Arbeit stattfindet. > > Es zeigt, wo Wertfluss behindert wird und wo Verbesserungen ansetzen können. --- **Typische Fehler beim Value Stream Mapping** **Fehler 1: Nur den dokumentierten Soll-Prozess abbilden** Der tatsächlich gelebte Arbeitsablauf bleibt unbekannt. --- **Fehler 2: An Abteilungsgrenzen aufhören** Der gesamte Weg zum Stakeholder-Outcome wird nicht betrachtet. --- **Fehler 3: Zu großen Umfang wählen** Der Wertstrom wird so umfangreich, dass keine konkreten Verbesserungen mehr erkennbar sind. --- **Fehler 4: Nur technische Schritte betrachten** Menschen, Informationen, Lieferanten, Kontrollen und Benutzererfahrung fehlen. --- **Fehler 5: Nur Bearbeitungszeiten messen** Wartezeit, Übergaben, Nacharbeit und Verzögerungen bleiben unsichtbar. --- **Fehler 6: Jede nicht sichtbare Tätigkeit als Verschwendung betrachten** Notwendige Sicherheits-, Qualitäts- oder Compliance-Kontrollen werden ungeprüft infrage gestellt. --- **Fehler 7: Das Diagramm als Endergebnis betrachten** Probleme werden sichtbar gemacht, aber Verbesserungen werden nicht priorisiert oder umgesetzt. --- **Fehler 8: Mitarbeiter für Probleme im Wertstrom verantwortlich machen** Systemische Ursachen wie fehlende Informationen, ungeeignete Werkzeuge und widersprüchliche Ziele werden übersehen. --- **Fehler 9: Nur einen idealen Einzelfall betrachten** Ausnahmen, Fehler, Eskalationen und Lieferantenabhängigkeiten bleiben unbekannt. --- **Fehler 10: Lokale Kennzahlen optimieren** Einzelne Teams verbessern ihre Werte, während sich das Ende-zu-Ende-Outcome verschlechtert. --- **Fehler 11: Zielzustand ohne Messgrößen gestalten** Später kann nicht festgestellt werden, ob die Verbesserung tatsächlich wirksam war. --- **Fehler 12: Zu früh automatisieren** Ein ungeeigneter oder instabiler Ablauf wird technisch festgeschrieben. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker sehen häufig nur einen Teil des gesamten Wertstroms. Beispiele: - Benutzerkonto erstellen - Server konfigurieren - Firewall-Regel ändern - Software verteilen - Incident untersuchen - Backup wiederherstellen - Monitoring-Alarm bearbeiten Value-Stream-Denken ergänzt folgende Fragen: - Welcher Auslöser führte zu meiner Aufgabe? - Welches Outcome soll erreicht werden? - Welche Schritte fanden bereits statt? - Welche Informationen fehlen mir? - Wer arbeitet nach meinem Schritt weiter? - Welche Auswirkungen besitzt eine Verzögerung? - Welche Rückmeldung muss ich liefern? - Welche Practices und Teams sind beteiligt? - Wie wird der Erfolg aus Benutzersicht geprüft? - Kann mein Arbeitsschritt vereinfacht oder automatisiert werden? - Erzeuge ich möglicherweise unnötige Nacharbeit für andere? > **Praxistipp** > > Dokumentiere nicht nur, was du getan hast. > > Dokumentiere auch das Ergebnis, relevante Abhängigkeiten und den nächsten notwendigen Schritt. --- **30-Sekunden-Prüfung eines Value Streams** 1. **Auslöser:** Was startet den Wertstrom? 2. **Stakeholder:** Für wen wird das Outcome benötigt? 3. **Outcome:** Wann ist das tatsächliche Ziel erreicht? 4. **Schritte:** Welche Tätigkeiten sind notwendig? 5. **Verantwortung:** Wer entscheidet und wer führt aus? 6. **Informationen:** Welche Daten werden benötigt? 7. **Übergaben:** Wo wechselt die Arbeit zwischen Beteiligten? 8. **Fluss:** Wo entstehen Wartezeit, Nacharbeit oder Engpässe? 9. **Kontrollen:** Welche Prüfungen sind wirklich erforderlich? 10. **Messung:** Wie wird Erfolg festgestellt? 11. **Verbesserung:** Welcher nächste Schritt verbessert den Wertstrom? --- **Checkliste vor dem Mapping** - [ ] Ist der Zweck der Untersuchung eindeutig? - [ ] Ist das gewünschte Outcome bekannt? - [ ] Sind Auslöser und Abschluss festgelegt? - [ ] Ist der Umfang ausreichend eingegrenzt? - [ ] Sind relevante Stakeholder beteiligt? - [ ] Stehen reale Vorgänge und Daten zur Verfügung? - [ ] Ist geklärt, wer die Untersuchung koordiniert? - [ ] Werden alle vier Dimensionen berücksichtigt? - [ ] Sind wichtige Lieferanten einbezogen? - [ ] Ist bekannt, wie Ergebnisse verwendet werden sollen? --- **Checkliste für die Ist-Aufnahme** - [ ] Wurden tatsächliche und nicht nur dokumentierte Schritte erfasst? - [ ] Sind Rollen und Verantwortlichkeiten sichtbar? - [ ] Sind benötigte Informationen und Werkzeuge erfasst? - [ ] Sind beteiligte Practices bekannt? - [ ] Sind Lieferanten und externe Abhängigkeiten enthalten? - [ ] Sind Bearbeitungs- und Wartezeiten erkennbar? - [ ] Sind Übergaben sichtbar? - [ ] Sind Nacharbeit und Rückschleifen erfasst? - [ ] Sind Kontrollen und Freigaben enthalten? - [ ] Sind Ausnahmen und Eskalationen berücksichtigt? - [ ] Wurde das tatsächliche Stakeholder-Outcome geprüft? --- **Checkliste für den Zielzustand** - [ ] Behandelt der Zielzustand die festgestellten Ursachen? - [ ] Unterstützt er das gewünschte Outcome? - [ ] Sind Verantwortung und Entscheidungsbefugnisse eindeutig? - [ ] Werden unnötige Übergaben reduziert? - [ ] Werden benötigte Informationen früher bereitgestellt? - [ ] Bleiben notwendige Kontrollen wirksam? - [ ] Sind Lieferanten und Verträge berücksichtigt? - [ ] Ist der Zielzustand technisch und organisatorisch realistisch? - [ ] Sind Automatisierungen kontrollierbar? - [ ] Sind Messgrößen definiert? - [ ] Kann die Verbesserung iterativ umgesetzt werden? - [ ] Sind mögliche neue Risiken bewertet? --- **Checkliste nach der Verbesserung** - [ ] Wurde die Verbesserung wie geplant umgesetzt? - [ ] Hat sich die Durchlaufzeit verändert? - [ ] Wurde Wartezeit reduziert? - [ ] Entsteht weniger Nacharbeit? - [ ] Wurden Engpässe beseitigt oder nur verlagert? - [ ] Hat sich die Benutzer- oder Kundenerfahrung verbessert? - [ ] Werden Outcomes zuverlässiger erreicht? - [ ] Sind Kontrollen weiterhin wirksam? - [ ] Sind neue Risiken entstanden? - [ ] Wurden Rollen und Dokumentationen aktualisiert? - [ ] Sind weitere Verbesserungen notwendig? - [ ] Wird der Wertstrom fortlaufend überwacht? --- **Schnellreferenz** | Frage | Bedeutung | |---|---| | Was startet den Wertstrom? | Auslöser bestimmen | | Für wen wird gearbeitet? | Stakeholder bestimmen | | Was soll erreicht werden? | Outcome definieren | | Welche Schritte finden statt? | tatsächlichen Arbeitsfluss erfassen | | Wer ist beteiligt? | Rollen, Teams und Lieferanten bestimmen | | Welche Informationen werden benötigt? | Informationsfluss untersuchen | | Wo wartet die Arbeit? | Warteschlangen erkennen | | Wo wird Arbeit wiederholt? | Nacharbeit erkennen | | Wo wechselt Verantwortung? | Übergaben untersuchen | | Welche Kontrollen sind notwendig? | Risiken und Vorgaben berücksichtigen | | Wie wird Erfolg gemessen? | geeignete Messgrößen bestimmen | | Was sollte zuerst verbessert werden? | Verbesserungen priorisieren | --- **Zusammenfassende Darstellung** > Bedarf, Nachfrage oder Chance > ↓ > Auslöser des Value Streams > ↓ > miteinander verbundene Schritte > ↓ > Menschen · Practices · Informationen · Technologien · Lieferanten > ↓ > Übergaben · Entscheidungen · Kontrollen · Rückmeldungen > ↓ > Output > ↓ > überprüftes Outcome > ↓ > gemeinsam ermöglichter Wert > ↓ > Feedback und Continual Improvement --- **Aufbau einer einfachen Value-Stream-Karte** > **Auslöser** > > Was startet den Wertstrom? > > ↓ > > **Schritt 1** > > Verantwortliche Rolle · benötigte Information · Ergebnis > > ↓ Übergabe oder Wartezeit > > **Schritt 2** > > Verantwortliche Rolle · verwendete Practice · Werkzeug > > ↓ Entscheidung oder Kontrolle > > **Schritt 3** > > technische oder organisatorische Umsetzung > > ↓ > > **Ergebnisprüfung** > > Funktioniert das Produkt oder der Service technisch? > > ↓ > > **Outcome-Prüfung** > > Kann der Stakeholder das benötigte Ergebnis erreichen? > > ↓ > > **Feedback und Verbesserung** --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.4 Governance und Verantwortlichkeit - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.9 Continual Improvement - 2.10 ITIL an den eigenen Kontext anpassen - Incident Management - Service Request Management - Change Enablement - Problem Management - Measurement and Reporting --- **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) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) - [ITIL: Moving from ITIL 4 to ITIL Version 5 – Value Streams and Digital Lifecycle](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-transition-from-itil-4-value-streams-digital-lifecycle) - [ITIL: ITIL Product – Version 5](https://www.itil.com/professionals/certifications/ITIL-Product-Version-5) - [PeopleCert: ITIL Product – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-product-version-5-4179) - [ITIL: New ITIL Product and Service Lifecycle Model](https://www.itil.com/Itil-News-and-Announcements/itil-product-and-service-lifecycle-model) **Offiziell bestätigter Stand** Die offiziellen ITIL-Version-5-Informationen bestätigen: - Value Stream Mapping and Management ist Bestandteil von ITIL Foundation Version 5. - Value Streams sollen identifiziert, abgebildet und gesteuert werden. - Ziel sind besserer Fluss, höhere Sichtbarkeit und bessere Outcomes über digitale Produkte und Services hinweg. - Geschäfts-Wertströme und der Product and Service Lifecycle sollen gemeinsam betrachtet werden, um die Unterstützung des Geschäfts durch digitale Technologie zu verstehen. - ITIL Version 5 verwendet weiterhin das ITIL Value System und eine vereinfachte Value Chain. - Digitale Produkte können als integrierte Value Streams über ihren vollständigen Lebenszyklus betrachtet werden. **Einordnung** Die auf dieser Seite dargestellte Vorgehensweise zur: - Abgrenzung eines Value Streams, - Erfassung von Bearbeitungs- und Wartezeiten, - Untersuchung von Übergaben, - Gestaltung eines Zielzustands, - Priorisierung von Verbesserungen, - und Verwendung der Checklisten ist eine praxisnahe redaktionelle Methode dieses unabhängigen Nachschlagewerks. Sie ist keine wörtliche offizielle ITIL-Methode und keine für jede Organisation vorgeschriebene Notation. Die konkrete Darstellungsform und der benötigte Detaillierungsgrad müssen an Ziel, Risiko, Komplexität und verfügbare Informationen angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.9 Continual Improvement > **Kurz erklärt** > > Continual Improvement beschreibt die fortlaufende Verbesserung von: > > - digitalen Produkten, > - Services, > - Management Practices, > - Wertströmen, > - Prozessen, > - Technologien, > - Informationen, > - Fähigkeiten, > - Zusammenarbeit, > - und Erfahrungen der Stakeholder. > > Continual Improvement ist: > > - Bestandteil des ITIL Value Systems, > - eine der 34 ITIL Management Practices, > - und ein grundlegender Gedanke über den gesamten Product and Service Lifecycle. > > ITIL Version 5 verwendet ein überarbeitet formuliertes Continual Improvement Model mit sieben Schritten. --- **Warum Continual Improvement notwendig ist** Produkte, Services und Arbeitsweisen bleiben nicht dauerhaft optimal. Sie werden beeinflusst durch: - veränderte Benutzeranforderungen, - neue Geschäftsziele, - neue Technologien, - technische Schulden, - Sicherheitsrisiken, - neue gesetzliche Anforderungen, - steigende Kosten, - veränderte Lieferantenleistungen, - neue Erkenntnisse aus Incidents, - Rückmeldungen von Benutzern, - und Erfahrungen aus dem laufenden Betrieb. Auch eine heute wirksame Lösung kann später ungeeignet werden. Beispiele: - Die Anzahl der Benutzer steigt. - Eine bisher unterstützte Softwareversion erreicht ihr Lebensende. - Ein Lieferant verändert Preise oder Leistungsumfang. - Ein manueller Ablauf verursacht bei wachsender Menge zu viele Fehler. - Eine Sicherheitsanforderung wird verschärft. - Ein Service erreicht technische Zielwerte, wird von Benutzern aber als unzuverlässig wahrgenommen. - Ein Wiederherstellungsverfahren funktioniert unter den aktuellen Bedingungen nicht mehr. - Eine ursprünglich sinnvolle Kontrolle verursacht inzwischen unnötige Wartezeiten. > **Merke** > > Verbesserung ist nicht nur notwendig, wenn etwas vollständig fehlschlägt. > > Sie ist auch notwendig, damit weiterhin wirksame Produkte und Services mit veränderten Anforderungen Schritt halten. --- **Continual und Continuous unterscheiden** Die Begriffe werden im allgemeinen Sprachgebrauch häufig miteinander vermischt. | Begriff | Vereinfachte Bedeutung | |---|---| | **Continual Improvement** | wiederkehrende Verbesserungsaktivitäten in angemessenen Abständen | | **Continuous Improvement** | Verbesserung als weitgehend ununterbrochene Aktivität | ITIL verwendet den Begriff: > **Continual Improvement** Das bedeutet nicht, dass jederzeit ohne Unterbrechung an jeder Sache gearbeitet werden muss. Verbesserungen können: - geplant, - priorisiert, - schrittweise umgesetzt, - unterbrochen, - überprüft, - und später fortgeführt werden. Entscheidend ist, dass Verbesserung dauerhaft in der Arbeitsweise verankert bleibt. --- **Continual Improvement im ITIL Value System** Continual Improvement ist einer der fünf Bestandteile des ITIL Value Systems. Das Value System verbindet: - Guiding Principles, - Governance, - Value Chain Activities, - Management Practices, - und Continual Improvement. Continual Improvement wirkt dabei nicht nur auf einen einzelnen Bereich. Verbessert werden können: - das gesamte Value System, - einzelne Management Practices, - Value Streams, - Produkte, - Services, - technische Komponenten, - Organisation und Zusammenarbeit, - Informationen, - Partnerbeziehungen, - und konkrete Arbeitsanweisungen. > **Wichtig** > > Continual Improvement ist nicht nur eine nachgelagerte Tätigkeit. > > Es wirkt auf alle Bestandteile des Value Systems und auf den gesamten Product and Service Lifecycle. --- **Continual Improvement als Management Practice** Als Management Practice benötigt Continual Improvement mehr als einzelne Verbesserungsideen. Zu einer wirksamen Practice können gehören: - klare Verantwortlichkeiten, - geeignete Fähigkeiten, - verfügbare Zeit, - verlässliche Informationen, - Messgrößen, - ein Verbesserungsregister, - Priorisierungskriterien, - Entscheidungsbefugnisse, - Werkzeuge, - Kommunikation, - Wissen, - und regelmäßige Erfolgskontrolle. Eine Organisation kann mögliche Rollen verwenden wie: - Continual Improvement Manager, - Practice Owner, - Service Owner, - Product Owner, - Improvement Owner, - Improvement Champion, - oder verantwortlicher Teamleiter. ITIL schreibt nicht für jede Organisation dieselben Rollenbezeichnungen vor. Entscheidend ist, dass für eine Verbesserungsinitiative geklärt ist: - Wer koordiniert sie? - Wer entscheidet? - Wer setzt Maßnahmen um? - Wer stellt Ressourcen bereit? - Wer misst die Ergebnisse? - Wer verantwortet die nachhaltige Verankerung? --- **Verbesserung ist Aufgabe aller Beteiligten** Continual Improvement darf nicht ausschließlich einer zentralen Verbesserungsstelle überlassen werden. Verbesserungsmöglichkeiten können erkannt werden durch: - Benutzer, - Service Desk, - Administratoren, - Entwickler, - Informationssicherheit, - Product Owner, - Service Owner, - Lieferanten, - Führungskräfte, - Fachabteilungen, - und andere Stakeholder. Beispiele: - Ein Service-Desk-Mitarbeiter erkennt eine häufige Rückfrage. - Ein Administrator erkennt einen fehleranfälligen manuellen Arbeitsschritt. - Ein Benutzer meldet eine unverständliche Servicebeschreibung. - Ein Lieferant weist auf eine neue technische Möglichkeit hin. - Ein Service Owner erkennt eine wiederkehrende Abweichung von einem Serviceziel. - Ein Security-Team erkennt eine unsichere Alttechnologie. - Ein Product Owner erkennt, dass eine Funktion kaum verwendet wird. > **Grundsatz** > > Jeder kann Verbesserungen vorschlagen. > > Nicht jeder kann allein über Priorität, Ressourcen und Umsetzung entscheiden. --- **Verbesserung muss gesteuert werden** Ohne eine gemeinsame Arbeitsweise können Verbesserungen: - verloren gehen, - mehrfach bearbeitet werden, - miteinander konkurrieren, - nur nach persönlicher Vorliebe ausgewählt werden, - ohne ausreichende Daten begonnen werden, - oder nach der Umsetzung nicht überprüft werden. Eine wirksame Steuerung sorgt dafür, dass Verbesserungsideen: 1. erfasst, 2. verstanden, 3. bewertet, 4. priorisiert, 5. verantwortet, 6. umgesetzt, 7. gemessen, 8. und nachhaltig verankert werden. --- **Das ITIL Continual Improvement Model** ITIL Version 5 verwendet ein Continual Improvement Model mit sieben Schritten. | Nr. | Offizielle englische Leitfrage | Praxisnahe deutsche Bedeutung | |---:|---|---| | 1 | **What is the vision?** | Welche Richtung, Ziele und Grenzen gelten? | | 2 | **Where are we now?** | Wie sieht der tatsächliche Ausgangszustand aus? | | 3 | **Where do we want to be?** | Welcher konkrete Zielzustand soll erreicht werden? | | 4 | **How do we get there?** | Welcher Weg führt vom Ausgangs- zum Zielzustand? | | 5 | **Take action** | Die geplanten Maßnahmen iterativ umsetzen | | 6 | **Are we getting there?** | Prüfen, ob die Initiative den Zielzustand tatsächlich erreicht | | 7 | **How do we keep the improvements relevant?** | Ergebnisse verankern und ihre weitere Relevanz sicherstellen | > **Versionsabhängig** > > Die Anzahl der Schritte wurde gegenüber ITIL 4 nicht verändert. > > In ITIL Version 5 wurden einzelne Schrittbezeichnungen präzisiert. > > Dieses Buch verwendet deshalb die aktuellen Bezeichnungen aus ITIL Version 5. --- **Das Modell ist iterativ** Die sieben Schritte bilden keine einmalig zu durchlaufende starre Abfolge. Während einer Initiative kann es notwendig sein: - die Vision zu präzisieren, - weitere Ausgangsdaten zu erfassen, - den Zielzustand anzupassen, - einen anderen Umsetzungsweg zu wählen, - zusätzliche Maßnahmen aufzunehmen, - oder eine Initiative zu beenden. Beispiel: Während der Umsetzung wird festgestellt, dass die angenommene Ursache nicht zutrifft. Dann kann die Initiative zu folgenden Schritten zurückkehren: - **Where are we now?** - **Where do we want to be?** - **How do we get there?** > **Merke** > > Ein Rücksprung im Modell ist nicht automatisch ein Fehler. > > Er kann zeigen, dass Feedback und neue Erkenntnisse tatsächlich berücksichtigt werden. --- **Das Model ist skalierbar** Das Continual Improvement Model kann für unterschiedlich große Initiativen verwendet werden. Beispiele: **Kleine Verbesserung** - Pflichtfeld in einem Ticketformular anpassen - veralteten Wissensartikel korrigieren - unnötige Monitoring-Meldung entfernen **Mittlere Verbesserung** - Onboarding-Ablauf vereinfachen - Zertifikatsüberwachung einführen - Backup-Tests standardisieren - Incident-Kommunikation verbessern **Größere Verbesserung** - neues Ticketsystem einführen - Service Desk neu organisieren - kritischen Service auf eine neue Plattform migrieren - unternehmensweites Identitätsmanagement verbessern Der Umfang der: - Analyse, - Dokumentation, - Governance, - Messung, - und Kommunikation muss an Größe, Risiko und Komplexität angepasst werden. --- **1. What is the vision?** > **Zentrale Frage** > > Welche Richtung, Ziele, Rahmenbedingungen und Grenzen gelten für die Verbesserung? Eine Verbesserung benötigt einen verständlichen Bezug zu: - Strategie, - Zielen, - Stakeholder-Erwartungen, - Risiken, - Produkten, - Services, - und gewünschten Outcomes. Ohne eine klare Vision können zwar einzelne Maßnahmen umgesetzt werden, ihr Beitrag zum tatsächlichen Wert bleibt jedoch unklar. Beispiel: Unzureichende Vision: > Wir wollen das Ticketsystem verbessern. Präzisere Vision: > Benutzer sollen Störungen und Anfragen einfach melden können. Die zuständigen Teams sollen vollständige Informationen erhalten, damit Vorgänge schneller und mit weniger Rückfragen bearbeitet werden. --- **Bestandteile einer Vision** Eine Vision kann unter anderem beschreiben: - Anlass der Verbesserung, - betroffene Stakeholder, - gewünschte Outcomes, - strategischen Zusammenhang, - Geltungsbereich, - wichtige Grenzen, - erwarteten Nutzen, - und nicht akzeptierbare Auswirkungen. Beispiel: > Der Onboarding-Wertstrom soll neue Mitarbeiter spätestens zum vereinbarten Eintrittsdatum mit einem sicheren und vollständig nutzbaren IT-Arbeitsplatz versorgen. Sicherheitsfreigaben dürfen dadurch nicht umgangen werden. --- **Leitfragen zu What is the vision?** - Warum ist die Verbesserung notwendig? - Welches Problem oder welche Chance besteht? - Welches Produkt, welcher Service oder welche Practice ist betroffen? - Welche Stakeholder sind relevant? - Welches Outcome wird angestrebt? - Wie unterstützt die Verbesserung die Ziele der Organisation? - Welche Grenzen und Vorgaben gelten? - Welche Risiken dürfen nicht entstehen? - Welche Erwartungen besitzen Führungskräfte und Stakeholder? - Wer muss die Vision unterstützen? - Was gehört ausdrücklich nicht zum Umfang? --- **Typische Fehler bei der Vision** - Verbesserung nur als technische Maßnahme beschreiben - keinen Bezug zu Stakeholdern oder Outcomes herstellen - zu allgemeinen oder unrealistischen Zielzustand formulieren - widersprüchliche Erwartungen nicht klären - Risiken und Grenzen nicht berücksichtigen - mehrere unterschiedliche Probleme in einer Initiative vermischen - Lösung bereits festlegen, bevor der tatsächliche Bedarf verstanden ist --- **2. Where are we now?** > **Zentrale Frage** > > Wie sieht der tatsächliche gegenwärtige Zustand aus? Der aktuelle Zustand bildet die Ausgangsbasis für die Verbesserung. Ohne eine nachvollziehbare Baseline kann später nicht zuverlässig festgestellt werden, ob sich etwas verbessert hat. Zu untersuchen sind beispielsweise: - aktuelle Leistung, - bestehende Arbeitsweisen, - vorhandene Fähigkeiten, - Technologien, - Rollen, - Kosten, - Risiken, - Probleme, - Stakeholder-Erfahrung, - und technische Schulden. --- **Geeignete Informationsquellen** Der Ausgangszustand kann untersucht werden anhand von: - Tickets, - Monitoring-Daten, - Protokollen, - Messwerten, - Benutzerfeedback, - Interviews, - Beobachtungen, - Value Stream Mapping, - Auditergebnissen, - Risikobewertungen, - Lieferantenberichten, - bestehenden Dokumentationen, - Tests, - und Stichproben. > **Wichtig** > > Die bestehende Dokumentation zeigt möglicherweise den vorgesehenen Ablauf. > > Sie beweist nicht automatisch, wie tatsächlich gearbeitet wird. --- **Baseline** Eine Baseline ist ein dokumentierter Ausgangswert oder Ausgangszustand, mit dem spätere Ergebnisse verglichen werden können. Beispiele: - durchschnittliche Durchlaufzeit: fünf Arbeitstage - 30 Prozent der Onboardings sind am ersten Arbeitstag unvollständig - monatlich zwölf Incidents wegen abgelaufener Zertifikate - 40 Prozent der Tickets benötigen Rückfragen - durchschnittlich vier Teamübergaben pro Incident - Restore-Test war bei zwei von zehn Systemen erfolgreich Die Baseline sollte: - relevant, - nachvollziehbar, - ausreichend zuverlässig, - und zum gewünschten Outcome passend sein. --- **Leitfragen zu Where are we now?** - Was geschieht heute tatsächlich? - Welche Daten liegen vor? - Welche Outcomes werden aktuell erreicht? - Was funktioniert bereits gut? - Wo bestehen Probleme? - Welche Risiken und technischen Schulden sind bekannt? - Welche Stakeholder sind betroffen? - Wie wird die heutige Erfahrung wahrgenommen? - Welche Fähigkeiten und Ressourcen stehen zur Verfügung? - Welche Lieferanten und Abhängigkeiten bestehen? - Welche Maßnahmen wurden bereits versucht? - Welche Annahmen müssen überprüft werden? - Welche Baseline kann verwendet werden? --- **Typische Fehler bei der Ist-Analyse** - nur Probleme betrachten und funktionierende Bestandteile ignorieren - ausschließlich leicht verfügbare Kennzahlen verwenden - subjektive Vermutungen als Baseline verwenden - Benutzer- und Kundenerfahrung nicht berücksichtigen - tatsächlichen Ablauf nicht beobachten - Datenqualität nicht prüfen - unterschiedliche Produkt- oder Servicevarianten vermischen - bereits mit der Umsetzung beginnen, bevor die Ausgangslage verstanden ist --- **3. Where do we want to be?** > **Zentrale Frage** > > Welcher konkrete und überprüfbare Zielzustand soll als Nächstes erreicht werden? Der Zielzustand übersetzt die Vision in konkrete Outcomes und Erfolgskriterien. Er sollte ausreichend: - verständlich, - realistisch, - relevant, - messbar, - und zeitlich einordenbar sein. Beispiel: Vision: > Der Onboarding-Prozess soll neue Mitarbeiter rechtzeitig arbeitsfähig machen. Konkreter Zielzustand: > Innerhalb von drei Monaten sollen mindestens 95 Prozent der vollständig und fristgerecht gemeldeten Mitarbeiter am ersten Arbeitstag über Endgerät, Benutzerkonto und genehmigte Standardzugriffe verfügen. --- **Critical Success Factors und Key Performance Indicators** Ein **Critical Success Factor** beschreibt eine Voraussetzung oder ein Ergebnis, das für den Erfolg wesentlich ist. Beispiel: > Vollständige Eintrittsinformationen liegen rechtzeitig vor. Ein **Key Performance Indicator** unterstützt die Messung. Beispiel: > Anteil vollständiger Eintrittsmeldungen mindestens zehn Arbeitstage vor dem Eintritt. Kennzahlen sollten nicht nur leicht messbare Aktivität abbilden. Sie sollten einen erkennbaren Bezug besitzen zu: - Outcome, - Wert, - Qualität, - Erfahrung, - Risiko, - oder Nachhaltigkeit. --- **Leading und Lagging Indicators** | Art | Bedeutung | Beispiel | |---|---|---| | **Leading Indicator** | früher Hinweis auf die wahrscheinliche Entwicklung | Anteil rechtzeitig eingegangener Eintrittsmeldungen | | **Lagging Indicator** | zeigt das bereits eingetretene Ergebnis | Anteil am ersten Tag vollständig arbeitsfähiger Mitarbeiter | Beide Perspektiven können gemeinsam hilfreich sein. Nur das Endergebnis zu messen kann zu spät sein. Nur vorbereitende Aktivität zu messen beweist noch nicht, dass das Outcome erreicht wurde. --- **Leitfragen zu Where do we want to be?** - Welches konkrete Outcome soll erreicht werden? - Was soll sich für Stakeholder verändern? - Welche Qualität wird benötigt? - Welche Risiken sollen reduziert werden? - Welche Zielwerte sind sinnvoll? - Welche Fähigkeiten müssen aufgebaut werden? - Welche technischen Schulden sollen reduziert werden? - Welche Grenzen und Vorgaben gelten? - Wann soll der nächste Zielzustand erreicht sein? - Wie wird Erfolg gemessen? - Welche unbeabsichtigten Auswirkungen müssen überwacht werden? - Ist der Zielzustand realistisch und ausreichend unterstützt? --- **Typische Fehler beim Zielzustand** - Ziel nur als Aktivität formulieren - keine Erfolgskriterien definieren - ausschließlich technische Kennzahlen verwenden - unrealistische Zielwerte festlegen - zu viele Ziele gleichzeitig verfolgen - Nebenwirkungen nicht berücksichtigen - nur einen endgültigen Idealzustand statt eines erreichbaren nächsten Zustands beschreiben - Zielwerte festlegen, ohne Baseline zu kennen --- **4. How do we get there?** > **Zentrale Frage** > > Welcher realistische Weg führt vom aktuellen zum gewünschten Zustand? In diesem Schritt wird der Verbesserungsweg gestaltet. Dazu können gehören: - Lösungsoptionen, - Maßnahmen, - Prioritäten, - Ressourcen, - Verantwortlichkeiten, - Risiken, - Abhängigkeiten, - Zeitplanung, - Tests, - Kommunikation, - und Messung. Der Weg kann: - direkt, - schrittweise, - experimentell, - oder explorativ sein. In komplexen Situationen ist der vollständige Weg möglicherweise nicht von Anfang an bekannt. Dann können kleine Experimente und Feedback notwendig sein. --- **Verbesserungsoptionen bewerten** Mögliche Kriterien: - erwarteter Nutzen - Beitrag zum Outcome - Risiko - Aufwand - Kosten - Dringlichkeit - technische Machbarkeit - organisatorische Machbarkeit - Abhängigkeiten - benötigte Fähigkeiten - Stakeholder-Unterstützung - Nachhaltigkeit - Rückfallmöglichkeit - und Geschwindigkeit des Erkenntnisgewinns Beispiel: Problem: > Viele Tickets enthalten unvollständige Informationen. Mögliche Optionen: - Formular verständlicher gestalten - dynamische Pflichtfelder verwenden - Benutzer mit Beispielen unterstützen - Serviceangebote klarer beschreiben - automatische Plausibilitätsprüfung verwenden - Service-Desk-Mitarbeiter schulen - Eingangskanäle vereinheitlichen Nicht jede Option muss gleichzeitig umgesetzt werden. --- **Verbesserungsplan** Ein Verbesserungsplan kann enthalten: | Feld | Inhalt | |---|---| | **Maßnahme** | Was wird verändert? | | **Verantwortlich** | Wer koordiniert die Umsetzung? | | **Ziel** | Welches Outcome wird unterstützt? | | **Priorität** | Wie wichtig und dringend ist die Maßnahme? | | **Ressourcen** | Welche Zeit, Fähigkeiten und Mittel werden benötigt? | | **Abhängigkeiten** | Was muss vorher oder gleichzeitig geschehen? | | **Risiken** | Welche negativen Folgen sind möglich? | | **Messung** | Wie wird die Wirkung festgestellt? | | **Termin** | Wann beginnt und endet die nächste Iteration? | | **Status** | geplant, aktiv, blockiert, abgeschlossen oder verworfen | --- **Leitfragen zu How do we get there?** - Welche Optionen bestehen? - Welche Maßnahme besitzt den größten erwarteten Nutzen? - Was ist der kleinste sinnvolle nächste Schritt? - Kann ein Pilot oder Experiment verwendet werden? - Welche Ressourcen werden benötigt? - Wer trägt Verantwortung? - Welche Practices sind beteiligt? - Welche Lieferanten werden benötigt? - Welche Risiken und Abhängigkeiten bestehen? - Welche Governance-Entscheidungen sind notwendig? - Wie werden Stakeholder einbezogen? - Wie wird Feedback erhoben? - Wie wird bei Problemen reagiert? - Welche Rückfall- oder Anpassungsmöglichkeit besteht? --- **Typische Fehler bei der Planung** - Maßnahmen auswählen, bevor Ursachen verstanden wurden - ausschließlich eine technische Lösung betrachten - Ressourcen nicht verbindlich bereitstellen - Verantwortlichkeit unklar lassen - zu großen Umfang für eine einzelne Iteration wählen - Kommunikation und Organizational Change Management vergessen - keine Messung einplanen - Abhängigkeiten und Lieferanten nicht berücksichtigen - Verbesserung nebenbei ohne realistische Kapazität erwarten --- **5. Take action** > **Zentrale Aufgabe** > > Die geplanten Maßnahmen kontrolliert und möglichst iterativ umsetzen. Eine Verbesserung entsteht nicht durch: - Analyse, - Besprechung, - Dokumentation, - oder Aufnahme in ein Register allein. Die Maßnahme muss umgesetzt und ihre Wirkung beobachtet werden. ITIL Version 5 betont bei diesem Schritt ein iteratives Vorgehen mit Möglichkeiten: - Fortschritt zu prüfen, - den Ansatz neu zu bewerten, - und notwendige Anpassungen vorzunehmen. --- **Iterative Umsetzung** Eine mögliche Vorgehensweise ist: 1. kleinen sinnvollen Umfang auswählen 2. Erfolgskriterien festlegen 3. Maßnahme umsetzen 4. Ergebnis beobachten 5. Feedback erfassen 6. Probleme und Nebenwirkungen untersuchen 7. Vorgehensweise anpassen 8. nächste Iteration durchführen Beispiel: Verbesserung des Monitoring **Iteration 1** - einen kritischen Service auswählen - wichtigste Komponenten erfassen - wenige relevante Alarme konfigurieren - Reaktionsweg testen **Auswertung** - Werden relevante Störungen erkannt? - Entstehen Fehlalarme? - Erhalten die richtigen Personen die Meldung? - Reichen die Informationen für eine Entscheidung? **Iteration 2** - Schwellenwerte verbessern - redundante Events reduzieren - weitere Komponenten einbeziehen - Dokumentation und Eskalation anpassen --- **Organizational Change Management** Viele Verbesserungen verändern nicht nur Technik. Sie verändern möglicherweise: - Rollen, - Verantwortlichkeiten, - Gewohnheiten, - Kommunikation, - Arbeitsabläufe, - Werkzeuge, - und Erwartungen. Deshalb kann Organizational Change Management notwendig sein. Zu berücksichtigen sind: - verständlicher Zweck, - betroffene Personengruppen, - Kommunikation, - Beteiligung, - Schulung, - Widerstände, - Fähigkeiten, - Unterstützung, - und tatsächliche Anwendung der neuen Arbeitsweise. > **Typischer Fehler** > > Eine neue Arbeitsweise wird technisch bereitgestellt, aber von den Beteiligten nicht verstanden oder verwendet. --- **Leitfragen zu Take action** - Ist der nächste Schritt eindeutig? - Sind Verantwortlichkeiten bekannt? - Sind Ressourcen verfügbar? - Sind Risiken und Rückfallmöglichkeiten berücksichtigt? - Sind Beteiligte informiert? - Ist notwendige Schulung erfolgt? - Kann schrittweise vorgegangen werden? - Wie wird Feedback während der Umsetzung erhoben? - Wie wird der Fortschritt sichtbar gemacht? - Wer entscheidet bei Abweichungen? - Wie werden Erkenntnisse dokumentiert? - Welche Änderungen am Plan sind notwendig? --- **Typische Fehler bei der Umsetzung** - Verbesserung dauerhaft verschieben - zu viele Maßnahmen gleichzeitig beginnen - niemanden eindeutig verantwortlich machen - Beteiligte nicht informieren - Probleme erst am Ende auswerten - am ursprünglichen Plan festhalten, obwohl neue Erkenntnisse vorliegen - nur den technischen Rollout betrachten - keine Zeit für Stabilisierung und Nacharbeit einplanen --- **6. Are we getting there?** > **Zentrale Frage** > > Führt die Initiative tatsächlich zum gewünschten Zielzustand? In diesem Schritt wird der neue aktuelle Zustand mit folgenden Bezugspunkten verglichen: - der ursprünglichen Baseline, - dem gewünschten Zielzustand, - den Erfolgskriterien, - und der Vision. Es wird nicht nur geprüft, ob Maßnahmen ausgeführt wurden. Es wird geprüft, ob sie die erwartete Wirkung erzeugen. --- **Aktivität und Wirkung unterscheiden** | Aktivität | Wirkung | |---|---| | neues Monitoring installiert | relevante Störungen werden früher erkannt | | Schulung durchgeführt | Mitarbeiter wenden die neue Arbeitsweise korrekt an | | Wissensartikel veröffentlicht | Lösungen werden schneller gefunden und erfolgreich verwendet | | Pflichtfeld ergänzt | Tickets enthalten vollständigere Informationen | | Backup-System aktualisiert | Wiederherstellungen funktionieren innerhalb der benötigten Ziele | | Automatisierung eingerichtet | Durchlaufzeit und Fehlerquote sinken | > **Merke** > > Eine umgesetzte Maßnahme beweist noch keine erfolgreiche Verbesserung. --- **Ergebnisse vergleichen** Beispiel: **Baseline** - 40 Prozent der Tickets benötigen Rückfragen. - durchschnittliche Bearbeitungsverzögerung: acht Stunden. **Zielzustand** - höchstens 15 Prozent benötigen Rückfragen. - durchschnittliche Verzögerung unter zwei Stunden. **Nach der ersten Iteration** - 25 Prozent benötigen Rückfragen. - durchschnittliche Verzögerung: vier Stunden. Bewertung: - Die gewünschte Richtung ist erkennbar. - Der Zielzustand ist noch nicht erreicht. - Weitere Untersuchung und Maßnahmen sind notwendig. --- **Quantitative und qualitative Informationen** Quantitative Informationen: - Zeit, - Anzahl, - Quote, - Kosten, - Ausfallhäufigkeit, - Fehlerquote, - Kapazität, - oder Zielerreichung. Qualitative Informationen: - Benutzerfeedback, - Mitarbeitererfahrung, - Verständlichkeit, - Vertrauen, - wahrgenommene Einfachheit, - Qualität der Zusammenarbeit, - und beobachtete Hindernisse. Beide Informationsarten können notwendig sein. Beispiel: Die Bearbeitungszeit sinkt. Mitarbeiter berichten jedoch, dass sie zur Zielerreichung notwendige Dokumentation überspringen. Die Verbesserung kann dadurch neue Risiken erzeugen. --- **Leitfragen zu Are we getting there?** - Wurden die geplanten Maßnahmen umgesetzt? - Hat sich der aktuelle Zustand verändert? - Wie verhält er sich zur Baseline? - Werden die gewünschten Outcomes erreicht? - Welche Zielwerte wurden erreicht? - Welche Zielwerte wurden nicht erreicht? - Hat sich die Stakeholder-Erfahrung verändert? - Sind neue Risiken oder Nebenwirkungen entstanden? - Wurde ein Engpass nur verlagert? - Sind Daten ausreichend zuverlässig? - Muss die Initiative angepasst werden? - Sind zusätzliche Maßnahmen notwendig? - Sollte die Initiative beendet oder neu ausgerichtet werden? --- **Wenn eine Verbesserung nicht wirkt** Mögliche Ursachen: - Problem wurde falsch verstanden. - Baseline war unzuverlässig. - Maßnahme behandelte nur ein Symptom. - Ziel war unrealistisch. - Umsetzung war unvollständig. - Beteiligte verwenden die neue Arbeitsweise nicht. - benötigte Ressourcen fehlen. - technische oder organisatorische Abhängigkeiten wurden übersehen. - externe Bedingungen haben sich verändert. - Messgrößen bilden den tatsächlichen Wert nicht ab. Eine nicht erfolgreiche Initiative sollte nicht automatisch verborgen werden. Sie kann wichtige Erkenntnisse liefern. > **Grundsatz** > > Ein kontrolliertes Experiment ohne erwarteten Erfolg kann wertvoll sein, wenn die Erkenntnisse dokumentiert und verwendet werden. --- **7. How do we keep the improvements relevant?** > **Zentrale Frage** > > Wie werden die Ergebnisse verankert und unter veränderten Bedingungen weiterhin relevant gehalten? Eine Verbesserung kann kurzfristig erfolgreich sein und später wieder verloren gehen. Mögliche Ursachen: - Mitarbeiter kehren zur alten Arbeitsweise zurück. - Dokumentationen werden nicht aktualisiert. - Verantwortlichkeiten wechseln. - neue Mitarbeiter werden nicht geschult. - Werkzeuge werden anders konfiguriert. - Messung endet unmittelbar nach der Einführung. - andere Veränderungen widersprechen der Verbesserung. - Anforderungen und Risiken verändern sich erneut. ITIL Version 5 betont deshalb nicht nur das Aufrechterhalten von Dynamik, sondern die fortlaufende Relevanz der Verbesserung. --- **Verbesserung verankern** Mögliche Maßnahmen: - Verantwortung dauerhaft festlegen - Arbeitsanweisungen aktualisieren - Knowledge-Artikel anpassen - Schulung und Einarbeitung ergänzen - Werkzeuge und Automatisierung aktualisieren - Messgrößen dauerhaft beobachten - Governance-Kontrollen anpassen - Service- und Produktdokumentation aktualisieren - Rollen und Eskalationswege klären - Lieferantenvereinbarungen anpassen - Erkenntnisse in weitere Initiativen übertragen - und regelmäßige Überprüfungstermine festlegen --- **Knowledge Management** Erkenntnisse sollten so dokumentiert werden, dass andere Beteiligte sie nutzen können. Dazu können gehören: - Ursachen, - Entscheidungen, - verworfene Optionen, - Testergebnisse, - Messwerte, - bekannte Einschränkungen, - neue Arbeitsweisen, - und gewonnene Erfahrungen. > **Praxistipp** > > Dokumentiere nicht nur, was erfolgreich war. > > Dokumentiere auch, welche Ansätze nicht funktioniert haben und warum. --- **Relevanz regelmäßig überprüfen** Eine Verbesserung kann später angepasst oder aufgehoben werden müssen. Beispiel: Eine zusätzliche Genehmigungsstufe wurde nach einem Sicherheitsvorfall eingeführt. Später wird eine technische Kontrolle implementiert, die das Risiko automatisch behandelt. Dann sollte geprüft werden: - Ist die manuelle Genehmigung weiterhin notwendig? - Kann sie vereinfacht werden? - Behandelt sie noch ein relevantes Restrisiko? - Erzeugt sie inzwischen unnötige Wartezeit? > **Merke** > > Eine Verbesserung ist nicht dauerhaft richtig, nur weil sie zum Zeitpunkt ihrer Einführung sinnvoll war. --- **Leitfragen zu How do we keep the improvements relevant?** - Wie wird die neue Arbeitsweise dauerhaft verankert? - Wer trägt langfristig Verantwortung? - Welche Dokumentationen müssen aktualisiert werden? - Welche Fähigkeiten und Schulungen werden benötigt? - Welche Messgrößen werden weiter beobachtet? - Wie wird eine Rückkehr zum alten Zustand erkannt? - Welche Governance-Vorgaben müssen angepasst werden? - Welche Erkenntnisse sollen geteilt werden? - Wann wird die Relevanz erneut geprüft? - Welche Veränderungen könnten die Verbesserung beeinflussen? - Welche weiteren Verbesserungsmöglichkeiten entstehen? - Was wurde aus Fehlern oder Abweichungen gelernt? --- **Typische Fehler bei der Verankerung** - Initiative direkt nach dem technischen Rollout schließen - Messung sofort beenden - Dokumentation nicht aktualisieren - keine dauerhafte Verantwortung festlegen - neue Mitarbeiter nicht berücksichtigen - Lessons Learned erfassen, aber nicht verwenden - Erfolg nicht kommunizieren - Verbesserung unverändert fortführen, obwohl sie nicht mehr relevant ist --- **Continual Improvement Register** Ein Continual Improvement Register ist ein mögliches Hilfsmittel zur Erfassung und Steuerung von Verbesserungen. Es kann enthalten: | Feld | Inhalt | |---|---| | **ID** | eindeutige Kennung | | **Titel** | kurze Beschreibung | | **Auslöser** | Problem, Feedback, Risiko oder Chance | | **betroffenes Produkt oder Service** | fachlicher Bezug | | **gewünschtes Outcome** | erwartetes Ergebnis | | **Ausgangszustand** | bekannte Baseline | | **Vorschlag** | mögliche Maßnahme | | **Nutzen** | erwarteter Wertbeitrag | | **Risiko** | mögliche negative Auswirkungen | | **Aufwand** | erwarteter Ressourceneinsatz | | **Priorität** | Reihenfolge der Bearbeitung | | **Verantwortlich** | Improvement Owner | | **Status** | neu, bewertet, geplant, aktiv, blockiert, abgeschlossen oder verworfen | | **Messgrößen** | Kriterien zur Erfolgskontrolle | | **Erkenntnisse** | Ergebnisse und Lessons Learned | Das Register kann umgesetzt werden als: - Tabelle, - Ticketsystem, - Kanban-Board, - Datenbank, - Projektwerkzeug, - oder spezialisiertes Improvement-Backlog. > **Wichtig** > > ITIL schreibt kein bestimmtes Werkzeug und kein universelles Registerformat vor. --- **Möglicher Status einer Verbesserung** | Status | Bedeutung | |---|---| | **Neu** | Idee oder Problem wurde erfasst | | **Zu prüfen** | weitere Informationen werden benötigt | | **Bewertet** | Nutzen, Risiko und Aufwand wurden untersucht | | **Priorisiert** | Reihenfolge wurde festgelegt | | **Geplant** | Maßnahmen und Ressourcen sind vorgesehen | | **Aktiv** | Umsetzung läuft | | **Blockiert** | Abhängigkeit oder Hindernis verhindert Fortschritt | | **In Auswertung** | Wirkung wird gemessen | | **Abgeschlossen** | Zielzustand wurde ausreichend erreicht und verankert | | **Zurückgestellt** | derzeit keine ausreichende Priorität oder Ressource | | **Verworfen** | Initiative wird begründet nicht weitergeführt | --- **Verbesserungen priorisieren** Nicht jede gute Idee kann sofort umgesetzt werden. Mögliche Bewertungskriterien: - erwarteter Wert - Beitrag zu strategischen Zielen - Auswirkung auf Benutzer - Sicherheitsrisiko - regulatorische Notwendigkeit - Dringlichkeit - Kosten - Aufwand - verfügbare Fähigkeiten - Abhängigkeiten - technische Schulden - Lieferantenrisiko - Umsetzbarkeit - und Zeit bis zum erwarteten Nutzen Eine einfache Priorisierung kann beispielsweise betrachten: | Kriterium | Frage | |---|---| | **Wirkung** | Wie stark verbessert sich das Outcome? | | **Dringlichkeit** | Welche Folgen besitzt eine Verzögerung? | | **Risiko** | Welches Risiko wird reduziert oder neu erzeugt? | | **Aufwand** | Welche Ressourcen werden benötigt? | | **Abhängigkeit** | Was muss vorher geschehen? | | **Sicherheit** | Besteht unmittelbarer Handlungsbedarf? | | **Machbarkeit** | Kann die Initiative erfolgreich umgesetzt werden? | > **Typischer Fehler** > > Die lauteste Forderung oder die technisch interessanteste Idee erhält automatisch die höchste Priorität. --- **Quick Wins** Ein Quick Win ist eine Verbesserung, die: - mit relativ geringem Aufwand, - in kurzer Zeit, - einen erkennbaren Nutzen erzeugen kann. Beispiele: - veralteten Wissensartikel korrigieren - eindeutigen Ticketkontakt ergänzen - unnötige Monitoring-Meldung deaktivieren - fehlenden Lieferantenkontakt dokumentieren - häufige Diagnoseabfrage automatisieren Quick Wins können sinnvoll sein, um: - unmittelbaren Nutzen zu erzeugen, - Akzeptanz aufzubauen, - und Erfahrungen zu sammeln. Sie dürfen jedoch nicht dauerhaft wichtigere strukturelle Verbesserungen verdrängen. > **Merke** > > Schnell umsetzbar bedeutet nicht automatisch besonders wertvoll. > > Hoher Wert bedeutet nicht automatisch schnell umsetzbar. --- **Verbesserung und Problem Management unterscheiden** | Continual Improvement | Problem Management | |---|---| | verbessert Produkte, Services, Practices und Arbeitsweisen | reduziert Wahrscheinlichkeit und Auswirkungen von Incidents | | kann durch Chancen oder Feedback ausgelöst werden | wird häufig durch Incidents, Muster oder Risiken ausgelöst | | betrachtet unterschiedliche Verbesserungsgegenstände | konzentriert sich auf Ursachen und mögliche Ursachen von Incidents | | verwendet Verbesserungsinitiativen | verwendet Problems, Known Errors und Workarounds | Beide Practices können zusammenwirken. Beispiel: Problem Management erkennt, dass Zertifikate nicht zentral verwaltet werden. Continual Improvement kann anschließend koordinieren: - zentrale Erfassung, - Verantwortlichkeiten, - Monitoring, - Dokumentation, - und regelmäßige Wirksamkeitsprüfung. --- **Verbesserung und Incident Management unterscheiden** | Incident Management | Continual Improvement | |---|---| | begrenzt aktuelle negative Serviceauswirkungen | verbessert zukünftige Produkte, Services oder Arbeitsweisen | | priorisiert Wiederherstellung | priorisiert nachhaltige Veränderung | | arbeitet häufig unter Zeitdruck | kann strukturiert und iterativ umgesetzt werden | | kann eine Zwischenlösung verwenden | bewertet, wie Ursachen und Arbeitsweisen verbessert werden | Beispiel: Ein Dienst wird neu gestartet und funktioniert wieder. - Incident Management koordiniert die Wiederherstellung. - Problem Management untersucht möglicherweise die Ursache. - Continual Improvement verbessert möglicherweise Monitoring, Dokumentation und Wiederherstellungsverfahren. --- **Verbesserung und Change Enablement unterscheiden** | Continual Improvement | Change Enablement | |---|---| | bestimmt und steuert Verbesserungsbedarf | unterstützt erfolgreiche Änderungen | | richtet Maßnahmen an Outcomes und Wert aus | bewertet unter anderem Nutzen, Risiko und Autorisierung konkreter Changes | | kann mehrere Changes enthalten | behandelt eine konkrete Änderung oder ein Change-Modell | Eine Verbesserungsinitiative kann mehrere Changes benötigen. Beispiel: Verbesserungsinitiative: > Zertifikatsmanagement zuverlässiger gestalten. Mögliche Changes: - Monitoring-Plattform konfigurieren - zentrale Datenbank einführen - neue Verantwortlichkeiten technisch abbilden - automatische Erneuerung aktivieren - Alarmierungswege anpassen --- **Verbesserung und Transformation unterscheiden** Continual Improvement und Transformation überschneiden sich, besitzen aber unterschiedliche typische Anwendungsbereiche. | Continual Improvement | Transformation | |---|---| | kann lokal oder schrittweise angewendet werden | betrifft häufig umfangreiche organisatorische Veränderungen | | eignet sich für konkrete Produkte, Services und Practices | kann das gesamte Value System oder große Organisationsbereiche verändern | | kann mit begrenztem Umfang und kurzer Laufzeit erfolgen | umfasst häufig viele Stakeholder, Abhängigkeiten und längere Zeiträume | | verwendet das Continual Improvement Model | ITIL Version 5 besitzt zusätzlich ein eigenes Transformation Model | Eine Transformation benötigt ebenfalls: - Lernen, - Messung, - Feedback, - Anpassung, - und fortlaufende Verbesserung. > **Wichtig** > > Nicht jede Verbesserung ist eine Transformation. > > Eine Transformation ohne Continual Improvement kann ihre Wirkung jedoch später wieder verlieren. --- **Verbesserung und Maturity Assessment unterscheiden** Ein Maturity Assessment bewertet Fähigkeiten oder Reife im Vergleich zu einem festgelegten Modell. Es kann Informationen liefern für: - **Where are we now?** - **Where do we want to be?** - **Are we getting there?** Das Assessment selbst verbessert jedoch noch nichts. Es liefert Erkenntnisse, auf deren Grundlage Verbesserungen geplant werden können. > **Typischer Fehler** > > Ein höherer Reifegrad wird als Selbstzweck verfolgt, ohne zu prüfen, ob dadurch relevante Outcomes verbessert werden. --- **Continual Improvement im Product and Service Lifecycle** Continual Improvement wirkt auf alle acht Lifecycle-Aktivitäten. | Lifecycle-Aktivität | Beispielhafte Verbesserung | |---|---| | **Discover** | Bedürfnisse und Feedback systematischer erfassen | | **Design** | Sicherheit, Betrieb und Erfahrung früher einbeziehen | | **Acquire** | Lieferanten- und Exit-Risiken besser bewerten | | **Build** | Tests und Konfiguration stärker automatisieren | | **Transition** | Pilotierung, Kommunikation und Rückfallplanung verbessern | | **Operate** | technische Schulden reduzieren und Überwachung optimieren | | **Deliver** | Serviceangebote und Stakeholder-Outcomes verbessern | | **Support** | Wissen, Kommunikation und Wiederherstellung beschleunigen | Erkenntnisse aus einer späteren Aktivität können Verbesserungen in früheren Aktivitäten auslösen. Beispiel: Support erkennt wiederkehrende Bedienprobleme. Daraus können Verbesserungen entstehen in: - Discover, - Design, - Build, - Transition, - Deliver, - und Knowledge Management. --- **Die sieben Guiding Principles bei Verbesserungen** | Guiding Principle | Anwendung bei Continual Improvement | |---|---| | **Focus on value** | Verbesserung am benötigten Outcome ausrichten | | **Start where you are** | Baseline und funktionierende Bestandteile berücksichtigen | | **Progress iteratively with feedback** | kontrollierte Schritte und regelmäßige Auswertung verwenden | | **Collaborate and promote visibility** | Stakeholder beteiligen und Fortschritt sichtbar machen | | **Think and work holistically** | alle vier Dimensionen und Abhängigkeiten betrachten | | **Keep it simple and practical** | angemessenen Umfang und verständliche Maßnahmen wählen | | **Optimize and automate** | Arbeitsweise zuerst verbessern und danach sinnvoll automatisieren | --- **Die vier Dimensionen bei Verbesserungen** **Organizations and People** - Welche Rollen und Fähigkeiten sind betroffen? - Welche Verhaltensänderung wird benötigt? - Bestehen ausreichende Zeit und Kapazität? - Wie wird die neue Arbeitsweise angenommen? **Information and Technology** - Welche Daten belegen den Ausgangszustand? - Welche Technologie unterstützt die Verbesserung? - Sind Messung und Automatisierung zuverlässig? - Welche technischen Schulden bestehen? **Partners and Suppliers** - Welche externen Anbieter sind betroffen? - Müssen Verträge oder Leistungen angepasst werden? - Welche Abhängigkeiten können die Verbesserung blockieren? - Welche Unterstützung wird benötigt? **Value Streams and Processes** - Welcher Arbeitsfluss wird verbessert? - Wo entstehen Wartezeit und Nacharbeit? - Welche Kontrollen und Übergaben sind betroffen? - Wie wird das Outcome gemessen? --- **Praxisbeispiel: Zertifikate laufen wiederholt ab** **Ausgangssituation** Mehrere Services waren innerhalb eines Jahres durch abgelaufene Zertifikate beeinträchtigt. --- **1. What is the vision?** > Zertifikate kritischer Services sollen rechtzeitig erneuert werden, damit vermeidbare Ausfälle verhindert werden. --- **2. Where are we now?** - Zertifikate werden in verschiedenen Tabellen geführt. - Verantwortlichkeiten sind nicht eindeutig. - Warnungen erfolgen teilweise manuell. - zwölf Zertifikate sind nicht zentral erfasst. - im letzten Jahr entstanden drei Incidents. --- **3. Where do we want to be?** - alle kritischen Zertifikate sind zentral erfasst - verantwortliche Rollen sind zugeordnet - automatische Warnungen erfolgen 60, 30 und 14 Tage vor Ablauf - Erneuerungsverfahren sind dokumentiert - kein vermeidbarer Incident durch unbemerktes Ablaufdatum --- **4. How do we get there?** - vollständigen Bestand erfassen - Verantwortlichkeiten klären - zentrale Datenquelle festlegen - Monitoring konfigurieren - Eskalationsregeln definieren - Erneuerungsverfahren dokumentieren - Pilot mit einem Service durchführen --- **5. Take action** - Pilotservice auswählen - Zertifikat erfassen - Alarmierung testen - Erneuerung simulieren - Verantwortliche schulen - weitere Services iterativ aufnehmen --- **6. Are we getting there?** - Sind alle kritischen Zertifikate erfasst? - Funktionieren Warnungen? - Reagieren die Verantwortlichen? - Wurde die Erneuerung rechtzeitig durchgeführt? - Sind neue Incidents entstanden? --- **7. How do we keep the improvements relevant?** - Erfassung neuer Zertifikate in den Build- und Transition-Ablauf integrieren - Verantwortlichkeiten regelmäßig prüfen - Monitoring überwachen - Wissensartikel pflegen - nach Änderungen und Lieferantenwechseln Bestand kontrollieren - jährliche Wirksamkeitsprüfung durchführen --- **Praxisbeispiel: Onboarding dauert zu lange** **Vision** Neue Mitarbeiter sollen am ersten Arbeitstag sicher und vollständig arbeiten können. **Ausgangszustand** - durchschnittliche Durchlaufzeit: zwölf Arbeitstage - viele unvollständige Eintrittsmeldungen - Hardwarebestand ist nicht transparent - mehrere manuelle Freigaben - kein Ende-zu-Ende-Verantwortlicher **Zielzustand** - 95 Prozent rechtzeitig gemeldeter Eintritte sind am ersten Tag vollständig arbeitsfähig - klare Vorlaufzeit - vollständiges digitales Formular - definierte Standardpakete - sichtbarer Status - geregelte Vertretung **Mögliche Maßnahmen** - Value Stream Mapping durchführen - Eintrittsformular verbessern - Rollenpakete definieren - Gerätebestand erfassen - Freigaben vereinfachen - Kontoanlage teilweise automatisieren - Arbeitsfähigkeit bestätigen lassen **Messung** - Durchlaufzeit - Anteil vollständiger Meldungen - Anteil arbeitsfähiger Mitarbeiter am ersten Tag - Anzahl Rückfragen - Benutzer- und Führungskräftefeedback --- **Praxisbeispiel: Zu viele Monitoring-Alarme** **Vision** Administratoren sollen relevante Zustandsänderungen rechtzeitig erkennen, ohne durch unnötige Meldungen überlastet zu werden. **Ausgangszustand** - täglich mehrere hundert Meldungen - viele Duplikate - unklare Verantwortlichkeit - kritische Meldungen gehen in der Menge unter - Alarmregeln werden selten überprüft **Zielzustand** - relevante Alarme besitzen eindeutige Zuständigkeit - Duplikate werden reduziert - kritische Events werden priorisiert - Alarmregeln werden nach Incidents überprüft - Reaktionszeiten werden messbar **Mögliche Maßnahmen** - Alarmbestand analysieren - technische und handlungsrelevante Events unterscheiden - redundante Meldungen korrelieren - Verantwortlichkeiten zuordnen - Schwellenwerte testen - automatische Eskalation konfigurieren - monatliche Qualitätsprüfung etablieren --- **Praxisbeispiel: Knowledge-Base wird kaum genutzt** **Vision** Mitarbeiter und Benutzer sollen verlässliches Wissen schnell finden und erfolgreich anwenden können. **Ausgangszustand** - viele veraltete Artikel - uneinheitliche Titel - schlechte Suchbegriffe - keine Verantwortlichkeit - Erfolg wird nur anhand der Artikelanzahl gemessen **Zielzustand** - häufig benötigte Inhalte sind aktuell - Suche liefert relevante Ergebnisse - Eigentümer und Prüfdatum sind bekannt - Nutzung und Lösungsbeitrag werden gemessen - veraltete Inhalte werden archiviert **Mögliche Maßnahmen** - Suchdaten und häufige Tickets auswerten - wichtige Artikel priorisieren - Vorlagen vereinheitlichen - Verantwortliche festlegen - Versionsstände ergänzen - Feedback ermöglichen - regelmäßige Überprüfung einrichten --- **Continual Improvement bei einem Incident** Nach einem Incident können Verbesserungsmöglichkeiten entstehen bei: - Monitoring, - Eskalation, - Kommunikation, - Dokumentation, - Wiederherstellung, - Lieferantensteuerung, - Konfigurationsinformationen, - Sicherheitskontrollen, - und Benutzerinformation. Nicht jeder Incident benötigt eine umfangreiche Verbesserungsinitiative. Eine Initiative ist besonders sinnvoll, wenn: - ein Incident schwerwiegend war, - derselbe Fehler wiederholt auftritt, - die Wiederherstellung unnötig lange dauerte, - wichtige Informationen fehlten, - Risiken nicht erkannt wurden, - oder ähnliche Services ebenfalls gefährdet sind. --- **Lessons Learned und Post-Incident Review** Eine nachgelagerte Überprüfung kann untersuchen: - Was ist geschehen? - Welche Auswirkungen bestanden? - Was funktionierte gut? - Was erschwerte die Bearbeitung? - Welche Entscheidungen wurden getroffen? - Welche Informationen fehlten? - Welche Maßnahmen waren erfolgreich? - Welche Risiken bestehen weiterhin? - Welche Verbesserungen sind notwendig? - Wer übernimmt diese Verbesserungen? > **Wichtig** > > Ein Lessons-Learned-Dokument allein erzeugt keine Verbesserung. > > Erkenntnisse müssen in verantwortete und priorisierte Maßnahmen überführt werden. --- **Fehlerkultur** Continual Improvement benötigt eine Umgebung, in der: - Probleme offen angesprochen, - Risiken eskaliert, - Fehler untersucht, - und Erkenntnisse geteilt werden können. Eine Untersuchung sollte nicht vorschnell nach einer schuldigen Person suchen. Zu prüfen sind ebenfalls: - unklare Anforderungen, - fehlende Informationen, - ungeeignete Werkzeuge, - widersprüchliche Ziele, - fehlende Fähigkeiten, - unrealistische Arbeitslast, - unzureichende Kontrollen, - und organisatorische Abhängigkeiten. > **Grundsatz** > > Individuelles Fehlverhalten darf nicht ignoriert werden. > > Eine ausschließliche Schuldzuweisung kann jedoch systemische Ursachen verdecken. --- **Messung und Reporting** Eine Verbesserung benötigt passende Informationen. Messgrößen sollten beantworten: - Hat sich das Outcome verbessert? - Hat sich das Risiko verändert? - Hat sich die Stakeholder-Erfahrung verbessert? - Sind Kosten oder Aufwand gesunken? - Wurden unbeabsichtigte Nebenwirkungen erzeugt? - Bleibt die Verbesserung wirksam? Mögliche Messgrößen: - Durchlaufzeit - Wiederherstellungszeit - Fehlerquote - Wiederholungsquote - Wartezeit - Anzahl Übergaben - Verfügbarkeit - Serviceerfahrung - Nutzung - Kosten - Sicherheitsvorfälle - Datenverlust - Nacharbeit - Einhaltung von Zielwerten --- **Kennzahlen gemeinsam betrachten** Einzelne Kennzahlen können irreführend sein. Beispiel: > Die durchschnittliche Ticketbearbeitungszeit wurde um 30 Prozent reduziert. Zusätzlich sollte geprüft werden: - Werden Tickets häufiger wieder geöffnet? - Werden Vorgänge schneller weitergereicht? - Müssen Benutzer erneut Kontakt aufnehmen? - Ist die Dokumentationsqualität gesunken? - Wurde das tatsächliche Outcome erreicht? > **Typischer Fehler** > > Eine Kennzahl verbessert sich, während sich der gesamte Wertstrom oder die Benutzererfahrung verschlechtert. --- **Automatisierung bei Continual Improvement** Automatisierung kann Verbesserungen unterstützen durch: - automatische Datenerfassung - Berichte - Trendanalysen - Workflow-Steuerung - Erinnerungen - technische Tests - Überwachung von Zielwerten - und Erkennung wiederkehrender Muster Automatisierung kann jedoch keine fehlende: - Vision, - Verantwortlichkeit, - Priorisierung, - Datenqualität, - oder fachliche Bewertung ersetzen. > **Grundsatz** > > Nicht die Verbesserungsidee automatisieren, sondern einen verstandenen und geeigneten Zielzustand. --- **Künstliche Intelligenz bei Continual Improvement** KI kann beispielsweise unterstützen bei: - Analyse großer Ticketmengen - Erkennung wiederkehrender Themen - Zusammenfassung von Feedback - Vorschlägen für mögliche Verbesserungen - Prognose von Kapazitätsproblemen - Erkennung von Anomalien - und Erstellung erster Berichte Dabei müssen berücksichtigt werden: - Qualität der Eingangsdaten - Datenschutz - Informationssicherheit - Nachvollziehbarkeit - mögliche Verzerrungen - menschliche Kontrolle - und Ergebnisverantwortung Beispiel: Eine KI erkennt, dass viele Tickets den Begriff „Anmeldung“ enthalten. Das beweist noch nicht: - dass dieselbe Ursache besteht, - dass alle Tickets falsch bearbeitet wurden, - oder welche Verbesserung notwendig ist. Die Muster müssen fachlich untersucht und eingeordnet werden. --- **Typische Fehler bei Continual Improvement** **Fehler 1: Verbesserung nur nach Störungen** Chancen, Feedback und technische Schulden werden nicht berücksichtigt. --- **Fehler 2: Keine klare Vision** Maßnahmen werden umgesetzt, ohne ihren Beitrag zu Outcomes und Wert zu verstehen. --- **Fehler 3: Keine Baseline** Später kann nicht festgestellt werden, ob sich der Zustand tatsächlich verbessert hat. --- **Fehler 4: Aktivität mit Wirkung verwechseln** Ein Werkzeug wurde eingeführt oder eine Schulung durchgeführt, aber das Outcome bleibt unverändert. --- **Fehler 5: Zu viele Initiativen beginnen** Ressourcen werden auf viele Vorhaben verteilt, während kaum eine Initiative abgeschlossen wird. --- **Fehler 6: Nur Quick Wins umsetzen** Größere strukturelle Risiken und Engpässe bleiben dauerhaft bestehen. --- **Fehler 7: Verbesserung als Zusatzarbeit behandeln** Es werden keine realistischen Ressourcen, Befugnisse oder Zeitfenster bereitgestellt. --- **Fehler 8: Mitarbeiter nicht einbeziehen** Die neue Arbeitsweise passt nicht zur tatsächlichen Situation oder wird nicht angenommen. --- **Fehler 9: Nach der Umsetzung nicht messen** Ob die Verbesserung wirkt oder neue Probleme erzeugt, bleibt unbekannt. --- **Fehler 10: Ergebnisse nicht verankern** Die Organisation kehrt nach kurzer Zeit zur bisherigen Arbeitsweise zurück. --- **Fehler 11: Lessons Learned nicht weiterverfolgen** Erkenntnisse werden dokumentiert, aber nicht priorisiert und umgesetzt. --- **Fehler 12: Kennzahlen isoliert optimieren** Lokale Zielwerte verbessern sich, während Wertstrom und Stakeholder-Erfahrung schlechter werden. --- **Fehler 13: Improvement Register als Ablage verwenden** Viele Ideen werden erfasst, aber nicht bewertet, priorisiert oder abgeschlossen. --- **Fehler 14: Verbesserung mit Transformation verwechseln** Eine kleine lokale Anpassung wird unnötig als umfangreiches Veränderungsprogramm organisiert. --- **Fehler 15: Frühere Verbesserung nie erneut prüfen** Eine einst sinnvolle Kontrolle oder Arbeitsweise bleibt bestehen, obwohl sie inzwischen unnötig oder ungeeignet ist. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker erkennen häufig Verbesserungsmöglichkeiten direkt im technischen Betrieb. Beispiele: - wiederkehrende manuelle Tätigkeiten - fehlende Monitoring-Regeln - veraltete Dokumentationen - unnötige Ticketübergaben - wiederkehrende Fehlkonfigurationen - schlecht nachvollziehbare Abhängigkeiten - ungetestete Wiederherstellungsverfahren - uneinheitliche Serverkonfigurationen - fehlende Automatisierung - und dauerhaft eingesetzte Zwischenlösungen Eine gute Verbesserungsidee sollte nicht nur lauten: > Das sollten wir automatisieren. Sie sollte möglichst beantworten: - Welches Problem besteht? - Wie häufig tritt es auf? - Welche Auswirkungen besitzt es? - Welches Outcome soll verbessert werden? - Welche Daten belegen den Bedarf? - Welche Risiken bestehen? - Welche Maßnahme wird vorgeschlagen? - Wie wird der Erfolg gemessen? --- **Beispiel für einen Verbesserungsvorschlag** Unpräzise: > Wir brauchen besseres Monitoring. Präziser: > Bei drei Incidents innerhalb der letzten sechs Monate wurde der Ausfall des internen DNS-Dienstes erst durch Benutzermeldungen erkannt. Vorgeschlagen wird eine aktive Funktionsprüfung der DNS-Auflösung mit Alarmierung des Bereitschaftsteams. Erfolgskriterium ist, dass ein Ausfall innerhalb von fünf Minuten erkannt und eindeutig dem DNS-Service zugeordnet wird. --- **30-Sekunden-Prüfung einer Verbesserung** 1. **Vision:** Warum ist die Verbesserung wichtig? 2. **Ist-Zustand:** Welche Daten und Beobachtungen liegen vor? 3. **Zielzustand:** Was soll konkret besser werden? 4. **Weg:** Welche Maßnahme ist geeignet? 5. **Aktion:** Wer setzt den nächsten Schritt um? 6. **Messung:** Woran erkennen wir Fortschritt und Erfolg? 7. **Verankerung:** Wie bleibt die Verbesserung wirksam und relevant? --- **Checkliste für eine neue Verbesserungsidee** - [ ] Ist das Problem oder die Chance verständlich beschrieben? - [ ] Ist das betroffene Produkt, der Service oder die Practice bekannt? - [ ] Sind relevante Stakeholder bestimmt? - [ ] Ist das gewünschte Outcome erkennbar? - [ ] Liegen Daten oder konkrete Beobachtungen vor? - [ ] Sind Auswirkungen und Risiken bekannt? - [ ] Wurde geprüft, was bereits funktioniert? - [ ] Ist eine mögliche Maßnahme beschrieben? - [ ] Sind Nutzen und Aufwand grob einschätzbar? - [ ] Ist bekannt, wer die Idee weiter bewertet? --- **Checkliste für eine Verbesserungsinitiative** - [ ] Ist die Vision eindeutig? - [ ] Unterstützt die Initiative strategische oder betriebliche Ziele? - [ ] Ist der Umfang klar abgegrenzt? - [ ] Ist der Ausgangszustand dokumentiert? - [ ] Besteht eine geeignete Baseline? - [ ] Ist ein überprüfbarer Zielzustand definiert? - [ ] Sind Erfolgskriterien und Messgrößen festgelegt? - [ ] Sind Rollen und Verantwortlichkeiten eindeutig? - [ ] Sind Ressourcen und Fähigkeiten verfügbar? - [ ] Sind Risiken und Abhängigkeiten berücksichtigt? - [ ] Sind alle vier Dimensionen betrachtet? - [ ] Sind relevante Practices und Lieferanten einbezogen? - [ ] Ist ein iteratives Vorgehen möglich? - [ ] Sind Kommunikation und Feedback geplant? - [ ] Ist festgelegt, wie Ergebnisse verankert werden? --- **Checkliste während der Umsetzung** - [ ] Werden geplante Maßnahmen durchgeführt? - [ ] Ist der Fortschritt sichtbar? - [ ] Werden Feedback und Messwerte erfasst? - [ ] Sind neue Risiken oder Nebenwirkungen entstanden? - [ ] Sind Beteiligte ausreichend informiert? - [ ] Wird die neue Arbeitsweise tatsächlich verwendet? - [ ] Müssen Ziel, Plan oder Umfang angepasst werden? - [ ] Sind Hindernisse eskaliert? - [ ] Werden Entscheidungen dokumentiert? - [ ] Ist die nächste Iteration eindeutig? --- **Checkliste zur Erfolgskontrolle** - [ ] Wurde der neue Zustand gemessen? - [ ] Wurde er mit der Baseline verglichen? - [ ] Wurden die Zielwerte erreicht? - [ ] Wurde das gewünschte Outcome erreicht? - [ ] Hat sich die Stakeholder-Erfahrung verbessert? - [ ] Wurden Risiken reduziert? - [ ] Sind neue Risiken entstanden? - [ ] Wurde ein Engpass nur verlagert? - [ ] Sind Daten und Messung zuverlässig? - [ ] Sind weitere Maßnahmen notwendig? - [ ] Sollte die Initiative fortgeführt, angepasst oder beendet werden? --- **Checkliste zur Verankerung** - [ ] Ist eine dauerhafte Verantwortung festgelegt? - [ ] Sind Prozesse und Arbeitsanweisungen aktualisiert? - [ ] Sind Knowledge-Artikel angepasst? - [ ] Sind betroffene Mitarbeiter geschult? - [ ] Sind Werkzeuge und Automatisierungen aktualisiert? - [ ] Werden relevante Messgrößen weiter beobachtet? - [ ] Wurden Governance-Vorgaben und Kontrollen angepasst? - [ ] Sind Service-, Produkt- und Konfigurationsinformationen aktuell? - [ ] Wurden Erkenntnisse und Fehlversuche dokumentiert? - [ ] Ist ein Termin zur erneuten Relevanzprüfung festgelegt? - [ ] Wurden weitere Verbesserungsideen erfasst? --- **Schnellreferenz des Continual Improvement Models** | Schritt | Kurzfrage | Typisches Ergebnis | |---:|---|---| | 1 | **What is the vision?** | Richtung, Zweck und Grenzen | | 2 | **Where are we now?** | Ausgangszustand und Baseline | | 3 | **Where do we want to be?** | Zielzustand und Erfolgskriterien | | 4 | **How do we get there?** | Verbesserungsplan und nächste Schritte | | 5 | **Take action** | umgesetzte Maßnahmen und Feedback | | 6 | **Are we getting there?** | Wirkungsprüfung und Anpassungsentscheidung | | 7 | **How do we keep the improvements relevant?** | verankerte und weiterhin überprüfte Verbesserung | --- **Zusammenfassende Darstellung** > **What is the vision?** > Richtung und Zweck klären > ↓ > **Where are we now?** > aktuellen Zustand und Baseline erfassen > ↓ > **Where do we want to be?** > Zielzustand und Erfolgskriterien bestimmen > ↓ > **How do we get there?** > geeigneten Verbesserungsweg planen > ↓ > **Take action** > Maßnahmen iterativ umsetzen > ↓ > **Are we getting there?** > Fortschritt, Wirkung und Nebenwirkungen prüfen > ↓ > **How do we keep the improvements relevant?** > Ergebnisse verankern und regelmäßig neu bewerten > ↓ > neue Erkenntnisse und weitere Verbesserungsmöglichkeiten > ↓ > erneute Anwendung des Modells --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.4 Governance und Verantwortlichkeit - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.10 ITIL an den eigenen Kontext anpassen - Incident Management - Problem Management - Change Enablement - Knowledge Management - Measurement and Reporting - Organizational Change 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) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) - [ITIL: Where do you start with ITIL? A case for continual improvement](https://www.itil.com/Itil-News-and-Announcements/where-do-you-start-with-ITIL) - [PeopleCert: ITIL Transformation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-transformation-version-5-4173) - [PeopleCert: ITIL Service – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-service-version-5-4181) **Ergänzende offizielle Community-Quelle** - [PeopleCert Community: Continual Improvement, Maturity or Transformation?](https://community.peoplecert.org/public/clubs/itil/blogs/continual-improvement-maturity-or-transformation-2026-02-04) **Offiziell bestätigter Stand** Die aktuellen offiziellen ITIL-Version-5-Informationen bestätigen: - Continual Improvement ist weiterhin Bestandteil des ITIL Value Systems. - Continual Improvement ist über das gesamte Framework und den Product and Service Lifecycle hinweg relevant. - ITIL Foundation Version 5 behandelt ein verfeinertes Continual Improvement Model. - Das Modell besitzt weiterhin sieben Schritte. - Einzelne Schrittbezeichnungen wurden gegenüber ITIL 4 präzisiert. - Die aktuellen sieben Schritte lauten: 1. What is the vision? 2. Where are we now? 3. Where do we want to be? 4. How do we get there? 5. Take action 6. Are we getting there? 7. How do we keep the improvements relevant? - Das Modell kann auf Verbesserungen von Produkten, Services, Practices und anderen Bestandteilen des Value Systems angewendet werden. - Die Schritte werden iterativ verwendet und können auf Grundlage neuer Erkenntnisse erneut durchlaufen werden. **Einordnung** Die ausführlichen: - Leitfragen, - Tabellen, - Checklisten, - Registerfelder, - Priorisierungskriterien, - Praxisbeispiele, - und Umsetzungshinweise sind zusätzliche herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebene Verbesserungsmethode dar. Rollen, Messgrößen, Werkzeuge, Priorisierungsverfahren und Dokumentationsumfang müssen an Ziel, Risiko, Größe und Arbeitsweise der jeweiligen Organisation angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 2.10 ITIL an den eigenen Kontext anpassen > **Kurz erklärt** > > ITIL ist kein fertiger Musterprozess, der unverändert in jede Organisation übernommen werden kann. > > Das Framework stellt: > > - Begriffe, > - Prinzipien, > - Modelle, > - Management Practices, > - Betrachtungsperspektiven, > - und bewährte Orientierung > > bereit. > > Die konkrete Organisation muss daraus eine Arbeitsweise gestalten, die zu ihren: > > - Zielen, > - Produkten und Services, > - Risiken, > - gesetzlichen Anforderungen, > - Fähigkeiten, > - Technologien, > - Lieferanten, > - und tatsächlichen Wertströmen > > passt. > > ITIL soll deshalb **übernommen und angepasst** werden. > > Eine sinnvolle Anpassung bewahrt Zweck und Nutzen der Guidance, ohne unnötige Komplexität zu erzeugen. --- **Warum ITIL angepasst werden muss** Organisationen unterscheiden sich erheblich. Beispiele: - Ein kleines Unternehmen betreut 40 Benutzer mit einem dreiköpfigen IT-Team. - Ein internationaler Konzern betreibt geschäftskritische Services an vielen Standorten. - Ein Krankenhaus benötigt besonders hohe Verfügbarkeit und nachvollziehbare Sicherheitskontrollen. - Eine öffentliche Verwaltung muss umfangreiche rechtliche und organisatorische Vorgaben berücksichtigen. - Ein Cloud-Anbieter entwickelt und betreibt digitale Produkte in kurzen Releasezyklen. - Ein Managed Service Provider unterstützt mehrere Kunden mit unterschiedlichen Verträgen. - Ein Softwareunternehmen arbeitet mit agilen Produktteams und automatisierten Deployments. Für alle diese Organisationen können ITIL-Konzepte hilfreich sein. Sie benötigen jedoch nicht: - dieselben Rollen, - dieselben Prozesse, - dieselben Werkzeuge, - dieselben Genehmigungsstufen, - denselben Dokumentationsumfang, - oder dieselben Kennzahlen. > **Merke** > > Gleiche ITIL-Grundgedanken können in unterschiedlichen Organisationen zu unterschiedlichen praktischen Umsetzungen führen. --- **Anpassen bedeutet nicht beliebig auswählen** ITIL an den Kontext anzupassen bedeutet nicht: - nur angenehme Bestandteile zu verwenden, - notwendige Kontrollen zu entfernen, - Begriffe ohne Verständnis umzubenennen, - jede bestehende Arbeitsweise nachträglich als ITIL zu bezeichnen, - oder Risiken mit dem Hinweis auf Flexibilität zu ignorieren. Eine Anpassung sollte nachvollziehbar beantworten: - Welches Problem soll gelöst werden? - Welches Outcome wird benötigt? - Welchen Zweck erfüllt die betreffende Practice? - Welche Risiken und Vorgaben bestehen? - Welche Bestandteile werden benötigt? - Welche Bestandteile wären unnötig? - Wie wird die Wirksamkeit überprüft? - Wie wird die Arbeitsweise später verbessert? > **Grundsatz** > > Anpassung verändert die konkrete Umsetzung. > > Sie darf nicht dazu führen, dass der eigentliche Zweck einer Practice, Kontrolle oder Verantwortung verloren geht. --- **ITIL wird nicht installiert** Ein ITSM-Werkzeug kann installiert werden. Ein Framework kann dagegen nicht wie eine Software vollständig „installiert“ werden. ITIL stellt einen Orientierungsrahmen bereit. Die Organisation muss selbst gestalten: - welche Produkte und Services sie verwaltet, - welche Outcomes sie erreichen will, - welche Wertströme benötigt werden, - welche Practices diese Wertströme unterstützen, - welche Rollen und Verantwortlichkeiten gelten, - welche Informationen benötigt werden, - welche Werkzeuge eingesetzt werden, - wie Risiken behandelt werden, - und wie Verbesserungen gesteuert werden. > **Typischer Fehler** > > Eine Organisation kauft ein ITSM-Werkzeug mit vorkonfigurierten ITIL-Modulen und betrachtet die Einführung damit als abgeschlossen. > > Das Werkzeug kann die Arbeitsweise unterstützen. Es ersetzt jedoch keine geklärten Ziele, Verantwortlichkeiten, Fähigkeiten und Wertströme. --- **Die wichtigsten Kontextfaktoren** Vor der Gestaltung einer ITIL-basierten Arbeitsweise sollten mindestens folgende Kontextfaktoren betrachtet werden: | Kontextfaktor | Beispielhafte Fragen | |---|---| | **Ziele und Strategie** | Welche geschäftlichen und organisatorischen Ergebnisse sollen unterstützt werden? | | **Produkte und Services** | Welche Leistungen werden angeboten und wie kritisch sind sie? | | **Stakeholder** | Wer nutzt, finanziert, unterstützt oder beeinflusst die Produkte und Services? | | **Größe und Struktur** | Wie viele Benutzer, Teams, Standorte und Organisationseinheiten existieren? | | **Risiken** | Welche Ausfälle, Sicherheitsvorfälle oder Fehlentscheidungen wären besonders schwerwiegend? | | **Gesetze und Verträge** | Welche rechtlichen, regulatorischen und vertraglichen Verpflichtungen gelten? | | **Betriebsmodell** | Wird intern, extern, hybrid, agil, produktorientiert oder projektorientiert gearbeitet? | | **Fähigkeiten** | Welche Kenntnisse, Erfahrungen und Kapazitäten sind vorhanden? | | **Technologie** | Welche Infrastruktur, Anwendungen, Cloud-Dienste und Automatisierungen werden eingesetzt? | | **Lieferanten** | Welche Produkte und Services hängen von externen Anbietern ab? | | **Kultur** | Wie werden Entscheidungen, Fehler, Zusammenarbeit und Verantwortung tatsächlich behandelt? | | **Reife und Ausgangslage** | Welche Arbeitsweisen funktionieren bereits und wo bestehen erkennbare Schwächen? | | **Kosten und Ressourcen** | Welcher Aufwand ist vertretbar und welche Ressourcen stehen zur Verfügung? | | **Veränderungsgeschwindigkeit** | Wie häufig ändern sich Produkte, Anforderungen und Technologien? | | **Erfahrung der Stakeholder** | Wie erleben Benutzer, Kunden und Mitarbeiter die vorhandenen Services? | --- **Die Ziele der Organisation zuerst verstehen** Die Einführung einer Practice sollte nicht mit einem Prozessdiagramm beginnen. Zuerst muss geklärt werden, welches Ergebnis verbessert werden soll. Unzureichendes Ziel: > Wir möchten Incident Management einführen. Besser: > Benutzer sollen nach ungeplanten Serviceunterbrechungen schneller wieder arbeitsfähig werden. Auswirkungen, Verantwortung und Kommunikation müssen dabei nachvollziehbar sein. Unzureichendes Ziel: > Wir benötigen eine CMDB. Besser: > Bei Incidents und Changes fehlen verlässliche Informationen über kritische Serviceabhängigkeiten. Dadurch dauern Analysen länger und Änderungen verursachen unerwartete Auswirkungen. Unzureichendes Ziel: > Wir wollen ITIL-konform arbeiten. Besser: > Wir wollen unsere wichtigsten Services nachvollziehbar steuern, Störungen verlässlich bearbeiten, Änderungen kontrollieren und wiederkehrende Fehler systematisch reduzieren. > **Merke** > > ITIL ist ein Hilfsmittel zur Verbesserung von Produkten, Services und Outcomes. > > Die Einführung von ITIL-Begriffen ist kein eigenständiges geschäftliches Outcome. --- **Nicht mit allen 34 Practices gleichzeitig beginnen** ITIL Version 5 enthält 34 Management Practices. Eine Organisation muss nicht alle Practices gleichzeitig vollständig ausgestalten. Eine sinnvollere Vorgehensweise ist: 1. wichtige Produkte und Services bestimmen 2. konkrete Probleme und Chancen erfassen 3. relevante Wertströme untersuchen 4. benötigte Practices identifizieren 5. vorhandene Fähigkeiten bewerten 6. wichtigste Lücken priorisieren 7. kleine wirksame Verbesserungen umsetzen 8. Ergebnisse messen 9. weitere Practices oder Fähigkeiten schrittweise entwickeln Beispiel: Eine Organisation besitzt folgende Probleme: - Störungen gehen verloren. - Benutzer kennen keinen eindeutigen Kontaktweg. - Prioritäten werden willkürlich vergeben. - Wiederkehrende Fehler werden nicht untersucht. - technische Änderungen werden nicht dokumentiert. Zunächst besonders relevant können sein: - Service Desk - Incident Management - Problem Management - Change Enablement - Knowledge Management - Monitoring and Event Management - Continual Improvement Andere Practices bleiben ebenfalls wichtig, müssen aber möglicherweise nicht mit derselben Priorität entwickelt werden. --- **Vom Problem zur benötigten Practice** | Beobachtetes Problem | Möglicherweise relevante Practices | |---|---| | Benutzer wissen nicht, wohin sie sich wenden sollen. | Service Desk, Service Catalogue Management | | Incidents werden uneinheitlich bearbeitet. | Incident Management, Knowledge Management | | dieselben Störungen treten regelmäßig erneut auf | Problem Management, Continual Improvement | | Changes verursachen unerwartete Ausfälle | Change Enablement, Service Configuration Management, Service Validation and Testing | | technische Abhängigkeiten sind unbekannt | Service Configuration Management, Architecture Management | | Hardware und Lizenzen sind nicht nachvollziehbar | IT Asset Management, Supplier Management | | Monitoring erzeugt zu viele unbrauchbare Meldungen | Monitoring and Event Management, Continual Improvement | | Lieferanten werden bei Incidents zu spät eingebunden | Supplier Management, Incident Management | | Benutzer erhalten unverständliche Serviceinformationen | Service Catalogue Management, Relationship Management | | Kapazitätsprobleme werden erst nach Ausfällen erkannt | Capacity and Performance Management, Monitoring and Event Management | | Wiederherstellungen sind nicht ausreichend vorbereitet | Service Continuity Management, Availability Management | | Wissen befindet sich nur bei einzelnen Personen | Knowledge Management, Workforce and Talent Management | Diese Zuordnung ist eine erste Orientierung. Die tatsächliche Situation kann Beiträge mehrerer Practices und Kontextfaktoren erfordern. --- **Die sieben Guiding Principles zur Anpassung verwenden** Die Guiding Principles unterstützen die Entscheidung, wie ITIL angemessen übernommen wird. --- **Focus on value** Fragen: - Welches Outcome soll verbessert werden? - Wer nimmt den Wert wahr? - Welcher Nutzen entsteht durch die neue Arbeitsweise? - Ist der Aufwand angemessen? - Welche Risiken werden reduziert? Beispiel: Ein neues Pflichtfeld im Ticketsystem ist nur sinnvoll, wenn die Information tatsächlich: - eine bessere Entscheidung, - schnellere Bearbeitung, - geringeres Risiko, - oder bessere Auswertung ermöglicht. --- **Start where you are** Fragen: - Was funktioniert bereits? - Welche Daten und Werkzeuge existieren? - Welche Mitarbeiter besitzen wertvolles Wissen? - Welche Arbeitsweisen sollten erhalten bleiben? - Was ist tatsächlich problematisch? Eine Organisation sollte vorhandene Fähigkeiten nicht allein deshalb verwerfen, weil sie nicht mit offiziellen ITIL-Begriffen bezeichnet wurden. Beispiel: Ein kleines Team besitzt bereits: - einen funktionierenden gemeinsamen Supportkanal, - klare persönliche Zuständigkeiten, - gute technische Dokumentation, - und regelmäßige Verbesserungsbesprechungen. Diese Bestandteile können weiterentwickelt werden, statt ein vollständig neues und komplexes Modell einzuführen. --- **Progress iteratively with feedback** Fragen: - Was ist der kleinste sinnvolle nächste Schritt? - Kann zunächst ein Pilot verwendet werden? - Welche Rückmeldungen werden benötigt? - Wie wird die Wirkung gemessen? - Welche Risiken können früh erkannt werden? Beispiel: Statt sofort sämtliche Serviceprozesse neu zu gestalten, kann zunächst der Incident-Wertstrom eines besonders wichtigen Service verbessert werden. --- **Collaborate and promote visibility** Fragen: - Wer ist betroffen? - Wer besitzt notwendiges Wissen? - Wer muss entscheiden? - Welche Informationen müssen sichtbar sein? - Wo entstehen Missverständnisse und Übergabeverluste? Eine ITIL-Einführung, die ausschließlich innerhalb eines kleinen Prozess- oder Toolteams gestaltet wird, kann den tatsächlichen Arbeitsalltag verfehlen. --- **Think and work holistically** Fragen: - Welche vier Dimensionen sind betroffen? - Welche Produkte und Services hängen zusammen? - Welche Lieferanten sind beteiligt? - Welche Auswirkungen entstehen für Betrieb, Support und Benutzer? - Welche anderen Practices werden beeinflusst? Beispiel: Die Einführung eines Change-Prozesses beeinflusst möglicherweise: - Entwicklung, - Betrieb, - Informationssicherheit, - Service Desk, - Lieferanten, - Dokumentation, - Monitoring, - und Releaseplanung. --- **Keep it simple and practical** Fragen: - Welchen Zweck erfüllt jeder Schritt? - Welche Dokumentation ist tatsächlich notwendig? - Welche Genehmigungen reduzieren ein reales Risiko? - Welche Sonderfälle werden unnötig zum Standard? - Ist die Arbeitsweise für die Beteiligten verständlich? > **Merke** > > Einfach bedeutet nicht unkontrolliert. > > Einfach bedeutet zweckmäßig, verständlich und frei von unnötiger Komplexität. --- **Optimize and automate** Fragen: - Ist der Ablauf verstanden? - Welche Schritte erzeugen keinen Nutzen? - Welche Daten sind zuverlässig? - Welche Ausnahmen bestehen? - Welche Teile können anschließend sicher automatisiert werden? - Wie werden automatisierte Ergebnisse kontrolliert? Ein ungeeigneter Ablauf sollte nicht unverändert automatisiert werden. --- **Alle vier Dimensionen berücksichtigen** Die Anpassung einer Practice muss alle vier Dimensionen einbeziehen. --- **Organizations and People** Zu klären sind beispielsweise: - Rollen - Verantwortung - Entscheidungsbefugnisse - Fähigkeiten - Kapazität - Kommunikation - Kultur - Schulung - Vertretung - und Akzeptanz Beispiel: Ein neuer Incident-Prozess kann fachlich gut beschrieben sein. Er bleibt dennoch unwirksam, wenn: - Mitarbeiter ihn nicht kennen, - niemand koordinieren darf, - Supportkapazität fehlt, - oder Teams nicht miteinander kommunizieren. --- **Information and Technology** Zu klären sind beispielsweise: - benötigte Informationen - Datenqualität - Werkzeuge - Schnittstellen - Automatisierung - Monitoring - Sicherheit - Datenschutz - und technische Abhängigkeiten Beispiel: Eine Prioritätsmatrix funktioniert nur, wenn ausreichende Informationen über: - Auswirkungen, - Dringlichkeit, - betroffene Services, - und Benutzergruppen vorliegen. --- **Partners and Suppliers** Zu klären sind beispielsweise: - Lieferantenleistungen - Supportwege - Verträge - Eskalation - Sicherheitsanforderungen - Datenverarbeitung - Abhängigkeiten - und Exit-Strategien Beispiel: Ein Incident-Prozess ist unvollständig, wenn ein kritischer Cloud-Provider beteiligt ist, aber: - keine Supportberechtigung, - keine Vertragsnummer, - kein Eskalationskontakt, - und keine interne Koordination festgelegt wurden. --- **Value Streams and Processes** Zu klären sind beispielsweise: - Auslöser - benötigte Outcomes - Schritte - Übergaben - Entscheidungen - Kontrollen - Wartezeiten - Nacharbeit - Messgrößen - und Verbesserung Die Anpassung sollte nicht nur einen isolierten Prozessschritt optimieren. Sie sollte den gesamten Wertstrom berücksichtigen. --- **Practices an Wertströmen ausrichten** Practices besitzen einen bestimmten Zweck. Wert entsteht jedoch durch das Zusammenwirken mehrerer Practices in konkreten Wertströmen. Beispielwertstrom: > Benutzer nach einer Störung wieder arbeitsfähig machen Möglicherweise beteiligt: - Service Desk - Incident Management - Monitoring and Event Management - Knowledge Management - Service Configuration Management - Supplier Management - Problem Management - Continual Improvement Die Organisation sollte deshalb nicht nur fragen: > Wie sieht unser Incident-Management-Prozess aus? Zusätzlich sollte sie fragen: - Wie meldet der Benutzer die Störung? - Welche Informationen werden benötigt? - Wie werden Auswirkungen erkannt? - Wie werden Abhängigkeiten ermittelt? - Wie werden Fachteams und Lieferanten eingebunden? - Wie wird der Benutzer informiert? - Wie wird die Wiederherstellung bestätigt? - Wie werden wiederkehrende Ursachen behandelt? - Wie werden Erkenntnisse verbessert? --- **Angemessene Rollen festlegen** ITIL nennt verschiedene mögliche Rollen. Eine Organisation muss jedoch nicht für jede Rolle eine eigene Vollzeitstelle schaffen. Kleine Organisation: Eine Person kann mehrere Rollen übernehmen, beispielsweise: - Service-Desk-Mitarbeiter, - Incident-Koordinator, - Administrator, - und Knowledge-Verantwortlicher. Große Organisation: Diese Verantwortlichkeiten können auf mehrere spezialisierte Rollen verteilt werden. Entscheidend ist nicht die Anzahl der Rollennamen. Entscheidend ist, dass geklärt ist: - Wer entscheidet? - Wer führt aus? - Wer koordiniert? - Wer trägt Ergebnisverantwortung? - Wer muss beteiligt werden? - Wer wird informiert? - Wer eskaliert? - Wer verbessert die Arbeitsweise? > **Wichtig** > > Eine Person kann mehrere Rollen besitzen. > > Kritische Funktionstrennungen sowie gesetzliche und sicherheitsrelevante Anforderungen müssen trotzdem berücksichtigt werden. --- **Rollenbezeichnungen dürfen angepasst werden** Eine Organisation kann eigene Begriffe verwenden. Beispiele: | ITIL-Begriff | Mögliche interne Bezeichnung | |---|---| | Service Desk | Helpdesk, IT-Support oder Benutzerbetreuung | | Incident | Störung | | Service Request | Standardanfrage oder Leistungsanforderung | | Change Enablement | Change Management oder Änderungssteuerung | | Service Owner | Serviceverantwortlicher | | Supplier Management | Lieferantensteuerung | | Continual Improvement | kontinuierliche Verbesserung oder Verbesserungsmanagement | Die interne Bezeichnung ist weniger wichtig als eine eindeutige Bedeutung. Problematisch ist es, wenn derselbe Begriff in verschiedenen Teams unterschiedliche Bedeutungen besitzt. Beispiel: Das Wort „Problem“ kann im allgemeinen Sprachgebrauch jede Schwierigkeit bezeichnen. Im ITIL-Kontext besitzt Problem Management einen bestimmten Zweck im Zusammenhang mit Ursachen oder möglichen Ursachen von Incidents. > **Praxistipp** > > Erstelle ein kurzes internes Glossar für wichtige Begriffe. > > Es muss verständlich erklären, wie die Organisation die Begriffe praktisch verwendet. --- **Dokumentationsumfang anpassen** Nicht jeder Vorgang benötigt dieselbe Dokumentation. Der Umfang sollte sich richten nach: - Risiko, - Komplexität, - Wiederholbarkeit, - betroffenen Services, - gesetzlichen Vorgaben, - Sicherheitsanforderungen, - und notwendiger Nachvollziehbarkeit. Beispiel: **Einfache Standardanfrage** - Anforderer - gewünschte Leistung - Genehmigung, falls erforderlich - technische Durchführung - Ergebnis **Kritischer Change** - Ziel - betroffene Produkte und Services - Auswirkungen - Risiken - technische Abhängigkeiten - Testnachweise - Autorisierung - Kommunikationsplan - Umsetzungsplan - Rückfall- oder Wiederherstellungsplan - Erfolgskriterien - Ergebnis und Nacharbeiten > **Grundsatz** > > Dokumentation muss eine Entscheidung, Ausführung, Kontrolle oder spätere Nutzung unterstützen. > > Daten ohne erkennbaren Zweck sollten nicht nur aus Gewohnheit erhoben werden. --- **Kontrollen nach Risiko gestalten** Nicht jeder Vorgang benötigt dieselbe Kontrolle. Beispielhafte Einteilung: | Situation | Mögliche Behandlung | |---|---| | häufige, dokumentierte und risikoarme Standardtätigkeit | vorab autorisierter und möglichst automatisierter Ablauf | | normale Änderung mit überschaubarem Risiko | angemessene Bewertung und Autorisierung | | komplexe Änderung an kritischem Service | vertiefte Risiko-, Abhängigkeits- und Rückfallprüfung | | dringende Sicherheitsmaßnahme | beschleunigtes Verfahren mit klarer Befugnis und nachgelagerter Kontrolle | | strategische Veränderung | Entscheidung durch entsprechend befugte Governance-Rollen | Die konkreten Kategorien und Entscheidungsbefugnisse werden von der Organisation festgelegt. > **Typischer Fehler** > > Jede kleine Änderung durchläuft dieselben umfangreichen Freigaben wie eine hochriskante Änderung. > > Dadurch entstehen unnötige Wartezeiten, ohne dass kritische Änderungen automatisch besser bewertet werden. --- **Priorisierung anpassen** ITIL schreibt keine universelle Prioritätsmatrix vor. Eine Organisation kann Auswirkungen und Dringlichkeit als wichtige Kriterien verwenden. Sie muss jedoch selbst festlegen: - welche Prioritätsstufen existieren, - welche Auswirkungen als kritisch gelten, - welche Benutzer oder Geschäftsprozesse besonders wichtig sind, - welche Reaktions- und Wiederherstellungsziele gelten, - und wer eine Priorität verändern darf. Beispielhafte Faktoren: - Anzahl betroffener Benutzer - Bedeutung des Geschäftsprozesses - vollständiger oder teilweiser Ausfall - verfügbare Zwischenlösung - Sicherheits- oder Datenschutzrisiko - gesetzliche Frist - zeitkritische Geschäftsaktivität - externe Kundenwirkung - drohender Datenverlust - und erwartete Dauer > **Wichtig** > > Die lauteste Beschwerde darf nicht automatisch die höchste Priorität bestimmen. > > Prioritäten sollten anhand nachvollziehbarer organisatorischer Kriterien festgelegt werden. --- **Servicekatalog angemessen gestalten** Ein Servicekatalog muss nicht jedes technische Detail enthalten. Er sollte Informationen bereitstellen, die für die jeweilige Zielgruppe hilfreich sind. Für Benutzer können relevant sein: - Name des Service - verständliche Beschreibung - mögliche Leistungen - Kontakt- oder Bestellweg - Voraussetzungen - Servicezeiten - erwartete Bereitstellungszeit - und wichtige Einschränkungen Für interne Teams können zusätzlich relevant sein: - Service Owner - technische Abhängigkeiten - Lieferanten - Supportgruppen - Serviceziele - Sicherheitsklassifizierung - und Wiederherstellungsanforderungen Ein kleiner Betrieb kann mit einer übersichtlichen Serviceliste beginnen. Ein großes Unternehmen benötigt möglicherweise mehrere Katalogansichten und umfangreichere Serviceinformationen. --- **Configuration Management angemessen gestalten** Service Configuration Management bedeutet nicht, jede Schraube und jedes Kabel als einzelnes Configuration Item zu erfassen. Der benötigte Detaillierungsgrad sollte sich richten nach: - Entscheidungsnutzen, - Risiko, - Änderungsbedarf, - Fehleranalyse, - Sicherheitsanforderungen, - Kosten der Datenpflege, - und Automatisierungsmöglichkeiten. Geeignete Fragen: - Welche Informationen werden bei Incidents benötigt? - Welche Abhängigkeiten müssen vor Changes bekannt sein? - Welche Komponenten besitzen besondere Risiken? - Welche Daten lassen sich zuverlässig automatisiert erfassen? - Wer verwendet die Informationen? - Wie werden veraltete Daten erkannt? - Ist der Pflegeaufwand angemessen? > **Typischer Fehler** > > Eine sehr detaillierte CMDB wird aufgebaut, ohne zu klären, welche Entscheidungen sie unterstützen soll. > > Die Daten veralten und verlieren dadurch ihren Nutzen. --- **Knowledge Management anpassen** Eine Wissensdatenbank muss nicht möglichst viele Artikel enthalten. Sie sollte benötigtes Wissen: - auffindbar, - verständlich, - aktuell, - vertrauenswürdig, - und anwendbar bereitstellen. Mögliche Wissensarten: - Benutzeranleitungen - Diagnoseanleitungen - Wiederherstellungsverfahren - bekannte Fehler - Workarounds - technische Standards - Lieferantenkontakte - Notfallinformationen - und Lessons Learned Eine kleine Organisation kann mit wenigen hochwertigen Artikeln für häufige und kritische Situationen beginnen. --- **Kennzahlen an Outcomes ausrichten** ITIL schreibt keine universellen Kennzahlen für jede Organisation vor. Kennzahlen sollten zum Zweck der jeweiligen Practice und zum benötigten Outcome passen. Beispiel Incident Management: Mögliche Kennzahlen: - Wiederherstellungszeit - Auswirkung auf Benutzer - Anzahl wiederholter Incidents - Anteil erneuter Kontaktaufnahmen - Qualität der Kommunikation - Serviceunterbrechungsdauer - und Anteil bestätigter Wiederherstellungen Nicht ausreichend ist häufig die alleinige Betrachtung von: - Anzahl geschlossener Tickets - durchschnittlicher Ticketdauer - oder Anzahl weitergeleiteter Vorgänge Beispiel Knowledge Management: Nicht nur: > Wie viele Artikel wurden erstellt? Sondern zusätzlich: - Werden sie gefunden? - Werden sie erfolgreich verwendet? - Sind sie aktuell? - Reduzieren sie wiederholte Analyse? - Verstehen Benutzer und Mitarbeiter die Inhalte? > **Merke** > > Eine leicht messbare Zahl ist nicht automatisch eine hilfreiche Steuerungsinformation. --- **Werkzeuge nach der Arbeitsweise auswählen** Ein Werkzeug sollte die benötigten Wertströme und Practices unterstützen. Vor der Auswahl sollte geklärt sein: - Welche Probleme sollen gelöst werden? - Welche Benutzergruppen verwenden das Werkzeug? - Welche Informationen werden benötigt? - Welche Integrationen bestehen? - Welche Automatisierungen sind sinnvoll? - Welche Sicherheitsanforderungen gelten? - Wie werden Daten exportiert? - Welche Lieferantenabhängigkeiten entstehen? - Wie hoch sind Einführung und Betrieb? - Welche Fähigkeiten werden benötigt? - Wie kann das Werkzeug später angepasst oder abgelöst werden? > **Typischer Fehler** > > Die Organisation passt ihre gesamte Arbeitsweise an die Standardkonfiguration eines Werkzeugs an, obwohl diese nicht zu ihren Wertströmen und Risiken passt. Gleichzeitig sollte eine unnötige Sonderkonfiguration vermieden werden. Zu viele individuelle Anpassungen können: - Updates erschweren, - Kosten erhöhen, - Support komplizieren, - und die spätere Ablösung behindern. --- **Automatisierung angemessen einsetzen** Geeignete Automatisierungen können sein: - automatische Ticketerfassung aus relevanten Events - standardisierte Benutzeranlage - Softwareverteilung - technische Validierung - Erinnerungen und Eskalationen - Inventarisierung - Aktualisierung bestimmter Konfigurationsdaten - Statuskommunikation - und Berichtserstellung Vor der Automatisierung sollte geklärt sein: - Ist der Ablauf notwendig? - Ist er verstanden? - Sind Regeln eindeutig? - Sind Eingangsdaten zuverlässig? - Welche Ausnahmen bestehen? - Wie werden Fehler behandelt? - Wer trägt Verantwortung? - Wie wird das Ergebnis kontrolliert? - Kann bei Bedarf manuell eingegriffen werden? > **Grundsatz** > > Standardisieren und optimieren, bevor automatisiert wird. > > Notwendige menschliche Entscheidungen dürfen nicht unbemerkt durch ungeprüfte technische Regeln ersetzt werden. --- **Künstliche Intelligenz kontextgerecht einsetzen** KI kann ITIL-basierte Arbeitsweisen unterstützen, beispielsweise durch: - Ticketklassifizierung - Zusammenfassungen - Wissenssuche - Mustererkennung - Prognosen - Kommunikationsvorschläge - und Automatisierungsunterstützung Der Umfang menschlicher Kontrolle muss sich nach dem möglichen Risiko richten. Zu prüfen sind: - Zweck der KI-Unterstützung - verwendete Daten - Datenschutz - Informationssicherheit - Ergebnisqualität - mögliche Verzerrungen - Nachvollziehbarkeit - Fehlerbehandlung - Lieferantenabhängigkeit - und Ergebnisverantwortung Beispiel: Eine KI kann eine Ticketkategorie vorschlagen. Die Organisation muss trotzdem regeln: - wann eine automatische Zuordnung zulässig ist, - wie Fehlzuordnungen erkannt werden, - wer kritische Entscheidungen prüft, - und wie aus Fehlern gelernt wird. --- **ITIL mit anderen Ansätzen kombinieren** ITIL muss nicht isoliert verwendet werden. Es kann mit anderen Frameworks, Normen und Arbeitsweisen kombiniert werden. | Ansatz | Möglicher Beitrag | |---|---| | **Agile** | iterative Entwicklung, Feedback und Anpassungsfähigkeit | | **Scrum** | strukturierte Arbeit in Produktentwicklungsteams | | **Kanban** | Visualisierung und Verbesserung des Arbeitsflusses | | **DevOps** | Zusammenarbeit, Automatisierung und schnelle zuverlässige Bereitstellung | | **Lean** | Fluss verbessern und vermeidbare Arbeit reduzieren | | **COBIT** | Governance und Steuerung von Information und Technologie | | **ISO/IEC 20000** | Anforderungen an ein Service-Management-System | | **ISO/IEC 27001** | Anforderungen an ein Informationssicherheitsmanagementsystem | | **Projektmanagement** | zeitlich begrenzte Vorhaben planen und steuern | | **Enterprise Architecture** | Strukturen, Abhängigkeiten und Zielarchitekturen gestalten | | **Site Reliability Engineering** | Zuverlässigkeit, Automatisierung und messbare Betriebsziele | | **Business Continuity Management** | Fortführung kritischer Geschäftsaktivitäten vorbereiten | Die kombinierte Arbeitsweise sollte keine unnötigen parallelen Strukturen erzeugen. Zu klären ist: - Welche Begriffe werden verwendet? - Welche Verantwortlichkeiten überschneiden sich? - Welche Kontrollen können gemeinsam genutzt werden? - Welche Dokumentationen sind doppelt? - Welche Ziele oder Messgrößen widersprechen sich? - Wie greifen die Ansätze im Wertstrom zusammen? --- **ITIL und agile Arbeitsweisen** ITIL und agile Arbeitsweisen schließen sich nicht aus. Gemeinsame Grundgedanken können sein: - Fokus auf Wert - iterative Entwicklung - Feedback - Zusammenarbeit - Sichtbarkeit - und kontinuierliche Verbesserung Mögliche Verbindung: - Product Owner priorisiert Produktanforderungen. - Service Owner betrachtet die Ende-zu-Ende-Servicequalität. - Entwicklung und Betrieb arbeiten gemeinsam an Releases. - Change Enablement verwendet risikobasierte Change-Modelle. - standardisierte und automatisierte Changes benötigen vereinfachte Autorisierung. - Betriebs- und Supportfeedback fließt in das Product Backlog. > **Typischer Fehler** > > Jeder agile Sprint wird durch zusätzliche schwerfällige Freigabeverfahren verzögert, obwohl automatisierte Tests, klare Entscheidungsrechte und risikoarme Standardänderungen vorhanden sind. Ebenso problematisch ist: > Mit dem Hinweis auf Agilität werden notwendige Sicherheits-, Qualitäts- oder Governance-Kontrollen vollständig umgangen. --- **ITIL und DevOps** DevOps fördert die Zusammenarbeit von: - Entwicklung, - Betrieb, - Sicherheit, - Qualitätssicherung, - und weiteren Beteiligten. ITIL kann dazu beitragen: - Wert und Outcomes zu klären, - Produkte und Services gemeinsam zu betrachten, - Governance einzubinden, - Practices zu koordinieren, - Servicebeziehungen zu gestalten, - und Verbesserungen systematisch zu steuern. Mögliche gemeinsame Umsetzung: - Infrastructure as Code - automatisierte Tests - automatisierte Deployments - Monitoring und Observability - gemeinsame Incident-Bearbeitung - blameless Reviews - risikobasierte Change-Modelle - automatisierte Dokumentationsaktualisierung - und Feedback aus dem Betrieb an Produktteams --- **ITIL und ISO/IEC 20000** ITIL stellt anpassbare Best-Practice-Guidance bereit. ISO/IEC 20000 enthält Anforderungen an ein Service-Management-System. Vereinfacht: | ITIL | ISO/IEC 20000 | |---|---| | Best-Practice-Framework | internationale Norm | | anpassbare Guidance | prüfbare Anforderungen | | beschreibt Konzepte und Practices | fordert ein wirksames Managementsystem | | keine allgemeine Organisationszertifizierung durch ITIL | Organisationen können sich im festgelegten Geltungsbereich zertifizieren lassen | Eine Organisation kann ITIL-Guidance verwenden, um ihr Service-Management-System zu gestalten. Die Erfüllung einzelner ITIL-Empfehlungen beweist jedoch nicht automatisch die Konformität mit ISO/IEC 20000. --- **Nicht „ITIL-konform“ als allgemeines Ziel verwenden** ITIL ist ein anpassbares Framework und keine Norm mit einem universellen Organisationszertifikat. Die Aussage: > Unsere Organisation ist vollständig ITIL-konform. ist deshalb häufig unpräzise. Besser ist eine konkrete Beschreibung: - Wir verwenden ITIL-Prinzipien zur Gestaltung unserer Arbeitsweisen. - Unser Incident Management orientiert sich an der entsprechenden ITIL Practice. - Unsere Wertströme kombinieren mehrere ITIL Practices. - Unsere Rollen und Prozesse wurden an den betrieblichen Kontext angepasst. - Unser ITSM-Werkzeug unterstützt bestimmte ITIL Practices. - Bestimmte Mitarbeiter besitzen ITIL-Zertifizierungen. > **Wichtig** > > Zertifizierte Personen, akkreditierte Schulungen oder bewertete Werkzeuge beweisen nicht automatisch die Wirksamkeit des gesamten Service Managements einer Organisation. --- **Kleine Organisationen** Eine kleine Organisation benötigt möglicherweise: - einen gemeinsamen Supportkanal - wenige verständliche Ticketkategorien - klare persönliche Zuständigkeiten - einfache Prioritätsregeln - kompakte Change-Checklisten - wenige hochwertige Wissensartikel - eine übersichtliche Asset-Liste - vorbereitete Lieferantenkontakte - und regelmäßige Verbesserungsbesprechungen Nicht zwingend erforderlich sind: - viele spezialisierte Rollen - mehrere Freigabegremien - umfangreiche Prozesshandbücher - hochkomplexe CMDB-Strukturen - oder für jede Practice ein eigenes Team > **Merke** > > Klein bedeutet nicht unprofessionell. > > Auch einfache Arbeitsweisen können verlässlich, kontrolliert und nachvollziehbar sein. --- **Große oder regulierte Organisationen** Eine große oder regulierte Organisation benötigt möglicherweise: - formalisierte Governance - eindeutige Funktionstrennung - mehrere Supportgruppen - umfangreiche Auditnachweise - unterschiedliche Serviceklassen - definierte Risikomodelle - Lieferantensteuerung - Notfall- und Kontinuitätsverfahren - zentrale Konfigurationsinformationen - automatisierte Kontrollen - und umfangreichere Messung Trotzdem sollte auch hier unnötige Komplexität vermieden werden. Ein umfangreicher Ablauf ist nur dann gerechtfertigt, wenn er: - ein relevantes Risiko behandelt, - eine verbindliche Anforderung erfüllt, - eine notwendige Entscheidung ermöglicht, - oder einen nachweisbaren Wertbeitrag besitzt. --- **Managed Service Provider** Ein Managed Service Provider muss zusätzlich berücksichtigen: - unterschiedliche Kundenverträge - unterschiedliche Serviceziele - getrennte Kundendaten - Berechtigungsgrenzen - kundenspezifische Eskalationen - gemeinsame technische Plattformen - Unterauftragnehmer - und klare Verantwortungsübergänge Ein standardisierter interner Ablauf kann sinnvoll sein. Er muss jedoch unterschiedliche Kundenanforderungen und Vertragsbedingungen berücksichtigen. Beispiel: Ein Incident derselben technischen Plattform kann für zwei Kunden unterschiedliche: - Prioritäten, - Kommunikationspflichten, - Servicezeiten, - und Eskalationswege besitzen. --- **Cloud- und SaaS-Umgebungen** Bei Cloud-Services sollte die Anpassung unter anderem berücksichtigen: - geteilte Verantwortung - Anbieterabhängigkeit - Datenstandort - Identitätsmanagement - Schnittstellen - Konfiguration - Kostensteuerung - Serviceänderungen des Anbieters - Supportmodelle - Datenportabilität - und Exit-Planung Traditionelle Aufgaben können sich verändern. Beispiel: Die Organisation tauscht möglicherweise keine defekten physischen Server mehr selbst aus. Sie bleibt jedoch verantwortlich für: - geeignete Architektur, - Konfiguration, - Benutzerzugriffe, - Daten, - Überwachung, - Kosten, - Wiederherstellungsplanung, - und Lieferantensteuerung. --- **Öffentliche Verwaltung und regulierte Bereiche** Zusätzlich relevant können sein: - Vergaberecht - Datenschutz - Aufbewahrungsfristen - Barrierefreiheit - Informationssicherheit - Nachweispflichten - Mitbestimmung - Aktenführung - Haushaltsvorgaben - und besondere Genehmigungswege Diese Anforderungen dürfen nicht als unnötige Bürokratie entfernt werden. Sie sollten jedoch so gestaltet werden, dass: - Zweck und Verantwortung verständlich sind, - doppelte Kontrollen vermieden werden, - Informationen möglichst einmalig und zuverlässig erfasst werden, - und der gesamte Wertstrom weiterhin handlungsfähig bleibt. --- **Praktische Vorgehensweise zur Anpassung** Die folgende Vorgehensweise ist eine redaktionelle Praxisempfehlung dieses Buches. Sie ist keine verbindlich vorgeschriebene offizielle ITIL-Schrittfolge. --- **1. Ziele und Probleme bestimmen** Erfasse: - wichtige Geschäfts- und Organisationsziele - betroffene Produkte und Services - konkrete Probleme - Chancen - Risiken - und Erwartungen der Stakeholder Ergebnis: > verständliche Beschreibung, warum eine Veränderung notwendig ist --- **2. Kritische Produkte und Services bestimmen** Fragen: - Welche Services sind besonders wichtig? - Welche Benutzer und Geschäftsprozesse hängen davon ab? - Welche Ausfälle wären besonders schwerwiegend? - Welche Lieferanten und technischen Komponenten sind kritisch? - Welche Sicherheits- und Wiederherstellungsanforderungen gelten? Ergebnis: > priorisierter Ausgangspunkt statt unkontrollierter Bearbeitung aller Bereiche --- **3. Tatsächliche Wertströme untersuchen** Beispiele: - Incident bearbeiten - neuen Benutzer bereitstellen - Software anfordern - Sicherheitsupdate einführen - Lieferantenstörung eskalieren - Service wiederherstellen Untersuche: - Auslöser - Schritte - Beteiligte - Informationen - Übergaben - Wartezeiten - Nacharbeit - Kontrollen - und Outcome --- **4. Benötigte Practices bestimmen** Fragen: - Welche Fähigkeiten werden im Wertstrom benötigt? - Welche Practices existieren bereits? - Welche Practice-Lücken verursachen konkrete Probleme? - Wo fehlen Rollen, Informationen oder Werkzeuge? - Welche Practices müssen zusammenwirken? --- **5. Aktuellen Zustand bewerten** Bewerte unter anderem: - Rollen - Fähigkeiten - Kapazität - Prozesse - Werkzeuge - Datenqualität - Lieferanten - Messgrößen - Governance - und tatsächliche Anwendung Ergebnis: > realistische Baseline statt rein theoretischer Sollbeschreibung --- **6. Zielzustand bestimmen** Der Zielzustand sollte beschreiben: - gewünschtes Outcome - benötigte Rollen - angemessene Kontrollen - Informationsbedarf - Werkzeugunterstützung - relevante Messgrößen - und notwendige Schnittstellen Er muss nicht sofort den endgültigen Idealzustand darstellen. Ein sinnvoller nächster Zustand kann ausreichend sein. --- **7. Kleinste wirksame Verbesserung auswählen** Beispiele: - eindeutigen Kontaktweg einführen - Prioritätskriterien dokumentieren - Lieferanteneskalation vorbereiten - kritische Serviceabhängigkeiten erfassen - Pflichtinformationen eines Tickets verbessern - Wiederherstellung aus Benutzersicht bestätigen - häufige Lösung dokumentieren - unnötige Freigabe entfernen - oder relevante Monitoring-Warnung ergänzen --- **8. Verantwortlichkeit und Governance klären** Bestimme: - wer entscheidet - wer umsetzt - wer das Ergebnis kontrolliert - wer Risiken akzeptieren darf - wer eskaliert - wer die Arbeitsweise verbessert - und welche Grenzen gelten --- **9. Iterativ umsetzen** Verwende nach Möglichkeit: - Pilotgruppen - begrenzte Services - kurze Feedbackzyklen - messbare Teilziele - und kontrollierte Ausweitung --- **10. Wirkung messen** Prüfe: - Hat sich das Outcome verbessert? - Wurde das Risiko reduziert? - Ist die Arbeitsweise verständlicher? - Entsteht weniger Wartezeit oder Nacharbeit? - Hat sich die Benutzererfahrung verbessert? - Sind neue Probleme entstanden? - Wird die Arbeitsweise tatsächlich verwendet? --- **11. Ergebnisse verankern** Aktualisiere bei Bedarf: - Rollen - Prozesse - Arbeitsanweisungen - Werkzeuge - Automatisierungen - Knowledge-Artikel - Schulungen - Lieferantenvereinbarungen - und Messgrößen --- **12. Fortlaufend verbessern** Erfasse neue: - Probleme - Chancen - technische Schulden - Stakeholder-Rückmeldungen - Risiken - und Verbesserungsideen Anpassung ist keine einmalige Einführungsphase. Sie bleibt Teil von Continual Improvement. --- **Minimum Viable Practice** Eine Organisation kann zunächst eine bewusst begrenzte, aber funktionsfähige Ausprägung einer Practice gestalten. Eine solche erste Ausprägung sollte mindestens klären: - Zweck - gewünschtes Outcome - Auslöser - Rollen - Verantwortung - wichtigste Schritte - notwendige Informationen - Eskalation - Ergebnisprüfung - und Verbesserung Beispiel: erste Incident-Management-Ausprägung - eindeutiger Kontaktweg - einheitliche Incident-Erfassung - einfache Prioritätskriterien - klare Zuständigkeiten - Eskalationsweg - Statuskommunikation - Prüfung der Wiederherstellung - Erfassung wiederkehrender Muster Später können ergänzt werden: - Automatisierung - umfassendere Serviceabhängigkeiten - detailliertere Messung - Lieferantenintegration - Major-Incident-Verfahren - und weiterentwickelte Knowledge-Unterstützung > **Wichtig** > > Eine minimale Practice darf nicht so stark reduziert sein, dass ihr grundlegender Zweck nicht mehr erfüllt wird. --- **Pilotierung** Ein Pilot kann helfen, eine angepasste Arbeitsweise zu prüfen. Geeigneter Pilotumfang: - ein wichtiger Service - ein Standort - eine Benutzergruppe - ein Team - eine bestimmte Ticketart - oder ein klar abgegrenzter Wertstrom Vor dem Pilot sollten festgelegt werden: - Ziel - Umfang - Beteiligte - Erfolgskriterien - Dauer - Risiken - Rückfallmöglichkeit - Feedbackwege - und Auswertungszeitpunkt Nach dem Pilot wird entschieden: - übernehmen - anpassen - erweitern - erneut testen - oder verwerfen --- **Organizational Change Management** Die Anpassung von ITIL verändert möglicherweise: - Rollen - Gewohnheiten - Entscheidungswege - Werkzeuge - Verantwortlichkeiten - Kennzahlen - und Zusammenarbeit Technische Bereitstellung allein reicht deshalb nicht aus. Zu berücksichtigen sind: - verständliche Begründung - Beteiligung der Betroffenen - Kommunikation - Schulung - Unterstützung - Widerstände - Führung - Zeit für Umstellung - und Überprüfung der tatsächlichen Anwendung > **Typischer Fehler** > > Ein neuer Prozess wird veröffentlicht und die Organisation erwartet, dass alle Beteiligten ihn ab dem nächsten Tag korrekt anwenden. --- **Zwischen lokaler Verbesserung und Transformation unterscheiden** Nicht jede Anpassung benötigt ein großes Transformationsprogramm. **Lokale Verbesserung** Beispiele: - Ticketformular verbessern - Eskalationskontakt ergänzen - Wissensartikel aktualisieren - Monitoring-Regel anpassen **Practice-Verbesserung** Beispiele: - Incident Management neu gestalten - Service Configuration Management entwickeln - Supplier Management vereinheitlichen **Wertstromverbesserung** Beispiele: - Onboarding Ende zu Ende verbessern - Releasebereitstellung beschleunigen - Incident-Wiederherstellung vereinfachen **Transformation** Beispiele: - gesamte Organisation auf Produkt- und Serviceorientierung ausrichten - Governance, Betriebsmodell, Rollen und Technologie umfassend verändern - mehrere Wertströme und Practices gleichzeitig neu gestalten Der Umfang der Steuerung muss zur tatsächlichen Veränderung passen. --- **Reife nicht als Selbstzweck betrachten** Eine Organisation kann Practices und Fähigkeiten bewerten, um ihren aktuellen Zustand besser zu verstehen. Ein höherer Reife- oder Fähigkeitsgrad ist jedoch nicht automatisch für jede Practice notwendig. Fragen: - Welche Fähigkeit wird für unsere Outcomes benötigt? - Welches Risiko besteht im aktuellen Zustand? - Welche Investition ist angemessen? - Welche Practice ist besonders kritisch? - Welcher nächste Fähigkeitsstand erzeugt einen tatsächlichen Nutzen? Beispiel: Ein hochentwickeltes Service Configuration Management kann für eine komplexe, stark integrierte Umgebung wichtig sein. Für eine sehr kleine und überschaubare Umgebung kann eine einfachere, aber zuverlässige Dokumentation ausreichend sein. --- **Typische Fehlanpassungen** **Fehler 1: ITIL vollständig kopieren** Vorlagen und Prozesse werden unverändert übernommen, obwohl sie nicht zur Organisation passen. --- **Fehler 2: Nur Begriffe ändern** Alte Probleme bleiben bestehen, werden aber mit neuen ITIL-Bezeichnungen versehen. --- **Fehler 3: Mit dem Werkzeug beginnen** Das Tool bestimmt die Arbeitsweise, bevor Ziele und Wertströme verstanden wurden. --- **Fehler 4: Alle Practices gleichzeitig einführen** Ressourcen werden überlastet und keine Practice wird wirksam aufgebaut. --- **Fehler 5: Jede Practice als eigene Abteilung aufbauen** Unnötige Silos und Übergaben entstehen. --- **Fehler 6: Rollen ohne Befugnisse vergeben** Personen tragen Verantwortung, können aber nicht entscheiden oder Ressourcen erhalten. --- **Fehler 7: Jeden Vorgang gleich behandeln** Risikoarme und kritische Tätigkeiten durchlaufen identische Kontrollen. --- **Fehler 8: Dokumentationsmenge mit Qualität verwechseln** Viele Felder und Dokumente erzeugen keine bessere Entscheidung oder Nachvollziehbarkeit. --- **Fehler 9: Bestehende funktionierende Arbeitsweisen verwerfen** Wertvolles Wissen und bewährte Fähigkeiten gehen verloren. --- **Fehler 10: Nur interne Sicht verwenden** Benutzer, Kunden, Fachabteilungen und Lieferanten werden nicht ausreichend einbezogen. --- **Fehler 11: Prozessgrenzen mit Wertstromgrenzen verwechseln** Jedes Team optimiert seinen Abschnitt, aber niemand betrachtet das gesamte Outcome. --- **Fehler 12: Kontrollen ohne Zweck einführen** Jeder frühere Fehler führt zu einer zusätzlichen dauerhaften Genehmigung. --- **Fehler 13: Notwendige Kontrollen als Bürokratie entfernen** Sicherheits-, Datenschutz- oder Compliance-Anforderungen werden unzureichend behandelt. --- **Fehler 14: Kennzahlen ungeprüft übernehmen** Gemessen wird, was das Werkzeug standardmäßig anbietet, nicht was für Outcomes und Entscheidungen wichtig ist. --- **Fehler 15: Automatisierung als erstes Ziel verwenden** Ein ungeeigneter Ablauf wird schneller und schwerer veränderbar gemacht. --- **Fehler 16: Anpassung als einmalige Einführung betrachten** Nach dem Projekt werden Arbeitsweisen nicht mehr überprüft oder verbessert. --- **Fehler 17: „ITIL-konform“ statt wirksam arbeiten** Die Organisation konzentriert sich auf Begriffe und Formalitäten statt auf Outcomes, Risiken und Erfahrung. --- **Praxisbeispiel: Kleiner interner IT-Support** **Ausgangslage** - drei IT-Mitarbeiter - 80 Benutzer - Meldungen per Telefon, E-Mail und Zuruf - keine einheitliche Priorisierung - Lösungen befinden sich in privaten Notizen **Angemessener erster Zielzustand** - ein gemeinsamer Kontaktweg - ein einfaches Ticketsystem - Incident und Service Request unterscheiden - drei oder vier Prioritätsstufen - klare persönliche Zuständigkeit - gemeinsame Wissensablage - wöchentliche Prüfung wiederkehrender Probleme **Noch nicht zwingend notwendig** - komplexes Major-Incident-Gremium - umfangreiche CMDB - mehrere Supportebenen - vollständige Prozessbibliothek - zahlreiche spezialisierte Rollen --- **Praxisbeispiel: Kritischer Produktionsservice** **Ausgangslage** - Produktion hängt von mehreren Anwendungen und Netzwerken ab - externe Anlagenhersteller sind beteiligt - Ausfälle verursachen hohe Kosten - Abhängigkeiten sind nur teilweise dokumentiert **Möglicher Zielzustand** - eindeutiger Service Owner - bekannte kritische Configuration Items - vorbereitete Major-Incident-Koordination - risikobasierte Change-Autorisierung - aktuelle Lieferantenkontakte - definierte Wiederherstellungsziele - getestete Notfallverfahren - Monitoring des gesamten Service - regelmäßige Problem- und Verbesserungsanalyse Hier ist ein höherer Kontroll- und Dokumentationsumfang angemessen. --- **Praxisbeispiel: Agile Softwareorganisation** **Ausgangslage** - mehrere tägliche Deployments - automatisierte Tests - Produktteams mit Ende-zu-Ende-Verantwortung - zentrale Change-Sitzung verzögert jede Veröffentlichung **Mögliche Anpassung** - standardisierte, automatisierte Deployments als geeignetes Change-Modell behandeln - Entscheidungsrechte an befähigte Produktteams delegieren - automatisierte Tests und technische Kontrollen als Nachweise verwenden - risikoreiche Änderungen vertieft bewerten - Änderungen transparent machen - Monitoring und schnelle Wiederherstellung sicherstellen - fehlgeschlagene Changes auswerten - Governance über Ziele, Grenzen und Ergebnisse statt über jede Einzelgenehmigung ausüben > **Merke** > > Häufige Änderungen benötigen nicht automatisch weniger Kontrolle. > > Sie benötigen häufig stärker automatisierte, risikogerechte und schneller wirksame Kontrollen. --- **Praxisbeispiel: Cloud-Service** **Ausgangslage** - E-Mail, Dateien und Zusammenarbeit werden als Cloud-Service bezogen - interne IT betreibt keine zugrunde liegenden Server - Benutzerkonten und Berechtigungen werden intern verwaltet **Angepasste Practices** - Supplier Management für Anbieterleistung und Eskalation - Information Security Management für Identitäten und Daten - Service Configuration Management für Abhängigkeiten und Integrationen - Incident Management für interne Koordination - Service Request Management für Benutzer- und Zugriffsanfragen - IT Asset Management für Lizenzen und Abonnements - Service Continuity Management für Ausfall- und Wiederherstellungsszenarien - Continual Improvement für Kosten, Nutzung und Erfahrung Die Verantwortung verschiebt sich. Sie verschwindet nicht. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten häufig an der konkreten Umsetzung angepasster Practices. Mögliche Beiträge: - technische Ausgangslage erklären - Abhängigkeiten dokumentieren - Risiken einer Änderung benennen - praktische Arbeitsanweisungen erstellen - Monitoring und Automatisierung aufbauen - Wiederherstellung testen - Werkzeugkonfiguration verbessern - Lieferanteninformationen bereitstellen - wiederkehrende Fehler sichtbar machen - und Verbesserungsvorschläge formulieren Hilfreiche Fragen im Arbeitsalltag: - Welches Outcome soll meine Tätigkeit unterstützen? - Welche betriebliche Regel gilt? - Warum existiert diese Regel? - Passt der Aufwand zum Risiko? - Welche Informationen werden wirklich benötigt? - Wer arbeitet vor und nach meinem Schritt? - Welche Abhängigkeiten bestehen? - Wie wird der Erfolg geprüft? - Was muss dokumentiert werden? - Was könnte vereinfacht oder automatisiert werden? - Welche Verbesserung sollte weitergegeben werden? --- **30-Sekunden-Prüfung einer ITIL-Anpassung** 1. **Ziel:** Welches Problem oder Outcome steht im Mittelpunkt? 2. **Ausgangslage:** Was funktioniert bereits? 3. **Kontext:** Welche Risiken, Vorgaben und Fähigkeiten bestehen? 4. **Wertstrom:** Wie gelangt die Arbeit vom Bedarf zum Ergebnis? 5. **Practices:** Welche Fähigkeiten werden tatsächlich benötigt? 6. **Dimensionen:** Wurden Menschen, Technologie, Partner und Arbeitsfluss betrachtet? 7. **Einfachheit:** Ist jeder Schritt notwendig? 8. **Governance:** Sind Verantwortung und Befugnisse eindeutig? 9. **Messung:** Woran erkennen wir Wirksamkeit? 10. **Verbesserung:** Wie wird Feedback genutzt? --- **Checkliste vor der Anpassung** - [ ] Sind Ziele und gewünschte Outcomes bekannt? - [ ] Sind wichtige Produkte und Services bestimmt? - [ ] Sind relevante Stakeholder beteiligt? - [ ] Sind gesetzliche, vertragliche und sicherheitsrelevante Vorgaben bekannt? - [ ] Wurde der aktuelle Zustand untersucht? - [ ] Wurde geprüft, was bereits gut funktioniert? - [ ] Sind kritische Wertströme bekannt? - [ ] Sind konkrete Probleme und Risiken belegt? - [ ] Sind vorhandene Fähigkeiten und Ressourcen bekannt? - [ ] Sind wichtige Lieferanten und Abhängigkeiten berücksichtigt? --- **Checkliste zur Gestaltung** - [ ] Ist der Zweck der betreffenden Practice verstanden? - [ ] Unterstützt die Gestaltung ein konkretes Outcome? - [ ] Wurden alle vier Dimensionen berücksichtigt? - [ ] Sind Rollen und Entscheidungsbefugnisse eindeutig? - [ ] Sind benötigte Informationen bestimmt? - [ ] Sind Prozesse und Kontrollen risikogerecht? - [ ] Wurde unnötige Komplexität vermieden? - [ ] Unterstützen Werkzeuge die Arbeitsweise? - [ ] Sind Lieferanten und externe Schnittstellen einbezogen? - [ ] Sind Ausnahmen und Eskalationen geregelt? - [ ] Sind Messgrößen und Erfolgskriterien festgelegt? - [ ] Kann die Einführung iterativ erfolgen? --- **Checkliste zur Einführung** - [ ] Ist ein sinnvoller Pilotumfang festgelegt? - [ ] Sind Verantwortliche und Ressourcen verfügbar? - [ ] Sind betroffene Mitarbeiter beteiligt? - [ ] Ist die Begründung der Veränderung verständlich? - [ ] Sind Schulung und Unterstützung vorbereitet? - [ ] Sind technische Konfigurationen getestet? - [ ] Sind Datenmigration und Schnittstellen geprüft? - [ ] Besteht eine Rückfall- oder Anpassungsmöglichkeit? - [ ] Werden Feedback und Messwerte erfasst? - [ ] Ist die nächste Auswertungsentscheidung vorbereitet? --- **Checkliste zur Wirksamkeitsprüfung** - [ ] Wird die neue Arbeitsweise tatsächlich angewendet? - [ ] Hat sich das gewünschte Outcome verbessert? - [ ] Wurden Risiken reduziert? - [ ] Entsteht weniger Wartezeit oder Nacharbeit? - [ ] Hat sich die Stakeholder-Erfahrung verbessert? - [ ] Sind neue Risiken oder Engpässe entstanden? - [ ] Sind Informationen und Dokumentationen zuverlässig? - [ ] Passen Rollen und Befugnisse zur tatsächlichen Arbeit? - [ ] Unterstützen Kennzahlen sinnvolles Verhalten? - [ ] Werden Automatisierungen ausreichend überwacht? - [ ] Sind weitere Anpassungen notwendig? --- **Checkliste gegen unnötige Bürokratie** - [ ] Besitzt jeder Pflichtschritt einen erkennbaren Zweck? - [ ] Behandelt jede Genehmigung ein reales Risiko oder eine verbindliche Vorgabe? - [ ] Werden Informationen nur einmal zuverlässig erfasst? - [ ] Sind Pflichtfelder verständlich und nutzbar? - [ ] Können risikoarme Standardfälle vereinfacht werden? - [ ] Werden seltene Ausnahmen nicht unnötig zum Standard? - [ ] Sind Dokumentationen für ihre Zielgruppen geeignet? - [ ] Werden veraltete Kontrollen regelmäßig überprüft? - [ ] Wird lokale Optimierung zulasten des gesamten Wertstroms vermieden? - [ ] Wird vor einer Automatisierung zuerst optimiert? --- **Schnellreferenz** | Frage | Bedeutung für die Anpassung | |---|---| | Was soll verbessert werden? | Ziel und Outcome bestimmen | | Was funktioniert bereits? | vorhandene Fähigkeiten erhalten | | Welcher Kontext gilt? | Risiken, Vorgaben und Ressourcen berücksichtigen | | Welcher Wertstrom ist betroffen? | Ende-zu-Ende-Arbeit untersuchen | | Welche Practices werden benötigt? | passende organisatorische Fähigkeiten auswählen | | Wie umfangreich muss die Lösung sein? | Aufwand an Risiko und Nutzen ausrichten | | Wer entscheidet und verantwortet? | Governance und Rollen klären | | Welche Informationen werden benötigt? | Daten und Dokumentation zweckmäßig gestalten | | Welche Werkzeuge unterstützen? | Technik nach der Arbeitsweise auswählen | | Wie wird Erfolg geprüft? | Outcomes und geeignete Messgrößen verwenden | | Was lernen wir daraus? | Continual Improvement verankern | --- **Zusammenfassende Darstellung** > Ziele, Bedürfnisse, Risiken und Vorgaben verstehen > ↓ > aktuelle Produkte, Services und Wertströme untersuchen > ↓ > vorhandene Fähigkeiten und funktionierende Arbeitsweisen berücksichtigen > ↓ > benötigte Management Practices auswählen > ↓ > Rollen · Informationen · Prozesse · Technologie · Lieferanten anpassen > ↓ > klein und risikogerecht beginnen > ↓ > Ergebnisse und Stakeholder-Erfahrung messen > ↓ > Arbeitsweise verankern und kontinuierlich verbessern --- **Abschluss des Kapitels** Die wichtigsten Bestandteile des ITIL-Frameworks wurden in diesem Kapitel behandelt: - ITIL als anpassbares Best-Practice-Framework - das ITIL Value System - die sieben Guiding Principles - Governance und Verantwortlichkeit - die vier Dimensionen - der Product and Service Lifecycle - die 34 Management Practices - Value Streams und Value Stream Mapping - Continual Improvement - und die Anpassung an den organisatorischen Kontext Diese Bestandteile sollten nicht isoliert verwendet werden. Sie bilden gemeinsam einen Orientierungsrahmen für professionelles digitales Produkt- und Service-Management. > **Kernaussage des Kapitels** > > ITIL liefert keine fertige Organisation. > > ITIL hilft einer Organisation, ihre eigenen Produkte, Services, Wertströme, Practices und Entscheidungen wirksamer zu gestalten. --- **Verwandte Seiten** - 2.1 Was ist ITIL und wie ist das Framework aufgebaut? - 2.2 Das ITIL Value System - 2.3 Die sieben Guiding Principles - 2.4 Governance und Verantwortlichkeit - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.6 Der Product and Service Lifecycle - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - Service Desk - Incident Management - Service Request Management - Problem Management - Change Enablement - Knowledge Management - Service Configuration Management - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [ITIL: Welcome to ITIL](https://www.itil.com/) - [ITIL: ITIL at a Glance](https://www.itil.com/at-a-glance) - [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [ITIL: ITIL Certifications](https://www.itil.com/certifications) - [ITIL: New ITIL Explained for Certified Professionals](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-explained) - [PeopleCert: ITIL Transformation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-transformation-version-5-4173) - [ITIL: ITIL Transformation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Transformation-Version-5) - [ITIL: ITIL How to Implement – Official Book](https://www.itil.com/Itil-News-and-Announcements/itil-how-to-implement-official-book) - [PeopleCert: ITIL FAQ](https://www.peoplecert.org/help-and-support/faq-itil) **Offiziell bestätigter Stand** Die offiziellen ITIL-Version-5-Informationen bestätigen: - ITIL stellt praktische und anpassbare Best-Practice-Guidance bereit. - ITIL ist für unterschiedliche Branchen, Betriebsmodelle und organisatorische Reifegrade vorgesehen. - Die Guiding Principles unterstützen die Anpassung von ITIL Practices an reale digitale Umgebungen. - ITIL soll in realen organisatorischen Kontexten angewendet und an den tatsächlichen Bedarf angepasst werden. - ITIL Version 5 verbindet Wert, Outcomes, Erfahrung, Governance, Practices, Technologie und Continual Improvement. - Für umfangreiche organisatorische Veränderungen stellt ITIL Version 5 zusätzliche Transformation Guidance bereit. **Einordnung** Die auf dieser Seite dargestellte praktische Vorgehensweise mit zwölf Schritten, die Checklisten, Beispiele, Tabellen und die Bezeichnung **Minimum Viable Practice** sind redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtliche offizielle ITIL-Implementierungsmethode und keine vorgeschriebene Reihenfolge dar. Konkrete: - Rollen, - Prozessschritte, - Prioritätsmodelle, - Freigaben, - Werkzeuge, - Kennzahlen, - Dokumentationsanforderungen, - und Kontrollverfahren müssen von der jeweiligen Organisation anhand ihrer Ziele, Risiken, Fähigkeiten und verbindlichen Vorgaben festgelegt werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** ITIL 4 **Fachlicher Stand:** August 2026 # 3. Service Desk, Support und operative Servicearbeit # 3.1 Der Service Desk als zentraler Kontaktpunkt > **Kurz erklärt** > > Der Service Desk stellt einen zentralen Kontakt- und Kommunikationspunkt zwischen dem Service Provider und seinen Benutzern bereit. > > Er nimmt unter anderem: > > - Störungsmeldungen, > - Service Requests, > - Fragen, > - Rückmeldungen, > - Beschwerden, > - und Informationsbedarf > > entgegen. > > Der Service Desk muss nicht jedes technische Problem selbst lösen. > > Er sorgt jedoch dafür, dass Kontakte: > > - verstanden, > - vollständig erfasst, > - fachlich eingeordnet, > - angemessen priorisiert, > - an die richtige Stelle weitergeleitet, > - nachvollziehbar koordiniert, > - und verständlich kommuniziert > > werden. > > Damit verbindet der Service Desk Benutzer, technische Teams, Management Practices, Lieferanten und Wertströme. --- **Warum ein zentraler Kontaktpunkt notwendig ist** Benutzer benötigen einen verständlichen und verlässlichen Weg, um: - eine Störung zu melden, - eine Leistung anzufordern, - eine Frage zu stellen, - Informationen zu erhalten, - oder eine Rückmeldung zu einem Service zu geben. Ohne einen klaren Kontaktpunkt entstehen häufig mehrere parallele Meldewege. Beispiele: - Ein Benutzer ruft einen bekannten Administrator direkt an. - Ein anderer Benutzer schreibt eine private Chatnachricht. - Eine Führungskraft sendet eine E-Mail an die IT-Leitung. - Eine Störung wird in einer allgemeinen Gruppe erwähnt. - Ein Mitarbeiter spricht einen Techniker auf dem Flur an. - Eine Fachabteilung meldet denselben Ausfall bei mehreren Teams. - Ein externer Dienstleister erhält eine Meldung, ohne dass die interne IT informiert wurde. Dadurch können folgende Probleme entstehen: - Meldungen gehen verloren. - dieselbe Störung wird mehrfach bearbeitet. - Informationen befinden sich in verschiedenen Systemen. - Prioritäten werden nach persönlicher Nähe oder Lautstärke vergeben. - niemand besitzt einen vollständigen Überblick. - Benutzer erhalten widersprüchliche Aussagen. - technische Teams werden unkoordiniert unterbrochen. - Bearbeitung und Entscheidungen sind später nicht nachvollziehbar. - wiederkehrende Muster werden nicht erkannt. - Servicequalität kann nicht zuverlässig ausgewertet werden. > **Merke** > > Ein zentraler Kontaktpunkt bedeutet nicht zwingend nur einen technischen Kommunikationskanal. > > Es bedeutet, dass Benutzerkontakte kontrolliert zusammengeführt und nachvollziehbar bearbeitet werden. --- **Der Service Desk als Verbindung zwischen Benutzern und Service Provider** Benutzer kennen häufig nicht: - die technische Architektur, - die zuständige Supportgruppe, - den beteiligten Lieferanten, - die interne Practice, - oder die Ursache einer Störung. Sie sollten deshalb nicht selbst entscheiden müssen, ob ein Problem zum: - Netzwerkteam, - Serverteam, - Anwendungsteam, - Identitätsmanagement, - Cloud-Provider, - Informationssicherheitsteam, - oder Softwarehersteller gehört. Der Service Desk unterstützt bei dieser Einordnung. Beispiel: Ein Benutzer meldet: > Ich kann mich nicht mehr anmelden. Mögliche Ursachen sind unter anderem: - falsches Kennwort, - gesperrtes Benutzerkonto, - fehlerhafte Netzwerkverbindung, - nicht erreichbarer Verzeichnisdienst, - gestörte Multi-Faktor-Authentifizierung, - abgelaufenes Zertifikat, - fehlerhafte Zeitsynchronisation, - deaktivierte Lizenz, - oder eine allgemeine Störung des Identitätsdienstes. Der Benutzer muss diese Ursache nicht vor der Meldung bestimmen. Der Service Desk erfasst zunächst: - wer betroffen ist, - welcher Service benötigt wird, - welches Symptom besteht, - seit wann es besteht, - welche Auswirkungen entstehen, - und welche Informationen für die weitere Bearbeitung benötigt werden. > **Grundsatz** > > Benutzer beschreiben ihre Beobachtung und ihre Beeinträchtigung. > > Die fachliche Einordnung ist Aufgabe der Serviceorganisation. --- **Der Service Desk ist mehr als eine Telefonzentrale** Ein Service Desk darf nicht auf das reine: - Annehmen, - Erstellen, - und Weiterleiten von Tickets reduziert werden. Eine wirksame Service-Desk-Practice kann unter anderem beitragen zu: - verständlicher Kommunikation, - strukturierter Erfassung, - richtiger Einordnung von Kontakten, - erster Diagnose, - direkter Lösung geeigneter Anliegen, - Koordination von Bearbeitung, - Benutzerinformation, - Eskalation, - Wissensnutzung, - Erkennung wiederkehrender Probleme, - Verbesserung von Services, - und einer positiven Benutzererfahrung. > **Typischer Fehler** > > Der Service Desk wird nur danach bewertet, wie schnell ein Kontakt beendet oder ein Ticket weitergeleitet wird. > > Dadurch kann die lokale Bearbeitungszeit sinken, während Übergaben, Rückfragen und die gesamte Lösungsdauer steigen. --- **Service Desk als Practice, Team und Kontaktpunkt unterscheiden** Der Begriff Service Desk kann in der Praxis unterschiedliche Ebenen beschreiben. | Betrachtung | Bedeutung | |---|---| | **Service-Desk-Practice** | organisatorische Fähigkeiten und Ressourcen für Kontakt, Kommunikation und Benutzerunterstützung | | **Service-Desk-Team** | Mitarbeiter, die einen wesentlichen Teil dieser Aufgaben ausführen | | **Service-Desk-Funktion** | organisatorische Einheit mit festgelegten Aufgaben und Verantwortlichkeiten | | **Kontaktpunkt** | Zugangsmöglichkeit für Benutzer zum Service Provider | | **Service-Desk-Werkzeug** | technische Unterstützung für Kontakte, Tickets, Wissen und Kommunikation | | **Supportkanal** | Telefon, Portal, E-Mail, Chat, persönlicher Kontakt oder anderer Zugangsweg | Diese Ebenen sind miteinander verbunden, aber nicht identisch. Ein Ticketsystem ist nicht der Service Desk. Ein Service-Desk-Team ist nicht automatisch für jede technische Lösung verantwortlich. Ein Portal ist nur einer von mehreren möglichen Kontaktkanälen. --- **Zweck des Service Desk** Der Service Desk unterstützt insbesondere dabei: - Kontakte zwischen Benutzern und Service Provider zu ermöglichen, - Nachfrage nach Incident-Lösung und Service Requests aufzunehmen, - Benutzer verständlich zu informieren, - Anliegen an geeignete Wertströme und Practices zu übergeben, - und die Benutzererfahrung während der Bearbeitung zu unterstützen. Der Service Desk kann zusätzlich: - erste Diagnosen durchführen, - bekannte Lösungen anwenden, - standardisierte Leistungen bereitstellen, - Wissen erfassen, - Statusinformationen kommunizieren, - Feedback aufnehmen, - und Verbesserungsmöglichkeiten erkennen. > **Wichtig** > > Der konkrete Umfang wird von der jeweiligen Organisation festgelegt. > > ITIL schreibt nicht vor, dass jeder Service Desk dieselben Aufgaben, Kanäle, Servicezeiten oder technischen Befugnisse besitzen muss. --- **Der Service Desk als Teil mehrerer Wertströme** Der Service Desk ist nicht ausschließlich Teil des Incident-Management-Wertstroms. Er kann an verschiedenen Wertströmen beteiligt sein. | Wertstrom | Möglicher Beitrag des Service Desk | |---|---| | Benutzer nach einer Störung wieder arbeitsfähig machen | Meldung aufnehmen, erste Diagnose durchführen, informieren und koordinieren | | genehmigte Standardsoftware bereitstellen | Service Request erfassen, Status kommunizieren und Ergebnis bestätigen | | neuen Mitarbeiter arbeitsfähig machen | Fragen beantworten, Übergabe unterstützen und Probleme behandeln | | Zugriff bereitstellen | Anfrage erfassen, notwendige Angaben prüfen und Status kommunizieren | | Benutzer über geplante Wartung informieren | zielgruppengerechte Kommunikation bereitstellen | | wiederkehrendes Problem reduzieren | Muster erkennen und an Problem Management weitergeben | | Service verbessern | Benutzerfeedback und Kontaktdaten auswerten | | Sicherheitsvorfall behandeln | Meldung erkennen, sicher eskalieren und vorgegebene Kommunikation verwenden | Der Service Desk ist damit häufig ein Knotenpunkt zwischen: - Benutzern, - Incident Management, - Service Request Management, - Problem Management, - Knowledge Management, - Monitoring and Event Management, - Service Level Management, - Relationship Management, - Information Security Management, - Supplier Management, - und Continual Improvement. --- **Service Desk und Incident Management unterscheiden** | Service Desk | Incident Management | |---|---| | stellt Kontakt und Kommunikation mit Benutzern bereit | behandelt negative Auswirkungen von Incidents | | nimmt unterschiedliche Kontaktarten entgegen | konzentriert sich auf Wiederherstellung des Service | | kann Incidents erfassen und erste Diagnose durchführen | koordiniert Diagnose, Eskalation und Wiederherstellung | | kann Service Requests, Fragen und Feedback bearbeiten | behandelt nicht automatisch jede Benutzeranfrage | | kann als Team oder organisatorische Funktion umgesetzt sein | ist eine organisationsweite Management Practice | | unterstützt mehrere Wertströme | unterstützt insbesondere Incident-bezogene Wertströme | Ein Service-Desk-Mitarbeiter kann Tätigkeiten des Incident Managements ausführen. Der Service Desk ist jedoch nicht mit der vollständigen Incident-Management-Practice identisch. Bei einem komplexen Incident können zusätzlich beteiligt sein: - technische Spezialisten, - Service Owner, - Incident-Koordination, - Lieferanten, - Informationssicherheit, - und Führungskräfte. --- **Service Desk und Service Request Management unterscheiden** | Service Desk | Service Request Management | |---|---| | stellt Kontakt und Kommunikation bereit | steuert die Erfüllung vereinbarter Benutzeranfragen | | nimmt einen Request möglicherweise entgegen | ordnet den Request einem geeigneten Request-Modell zu | | unterstützt bei Rückfragen und Statusinformationen | koordiniert Genehmigung, Erfüllung und Abschluss | | kann einfache Requests direkt erfüllen | kann weitere Teams und Automatisierungen einbeziehen | | bearbeitet auch Incidents, Fragen und Feedback | konzentriert sich auf vorgesehene Service Requests | Beispiel: Ein Benutzer benötigt eine freigegebene Standardsoftware. Der Service Desk kann: - den Bedarf aufnehmen, - das passende Serviceangebot auswählen, - notwendige Angaben prüfen, - und den Status kommunizieren. Service Request Management kann anschließend: - eine erforderliche Genehmigung einholen, - eine Lizenz prüfen, - die automatisierte Installation auslösen, - das Ergebnis kontrollieren, - und Asset-Informationen aktualisieren. --- **Service Desk und Helpdesk unterscheiden** Die Begriffe werden in Organisationen unterschiedlich verwendet. Häufig wird vereinfacht unterschieden: | Helpdesk | Service Desk | |---|---| | stärker auf technische Hilfe und Störungsbehebung ausgerichtet | breiter auf Servicebeziehungen, Kommunikation und Unterstützung ausgerichtet | | häufig reaktiver Fokus | kann reaktive und proaktive Aufgaben umfassen | | möglicherweise stärker komponentenorientiert | möglichst service- und benutzerorientiert | | häufig enger Aufgabenbereich | kann mehrere Practices und Wertströme verbinden | Diese Unterscheidung ist nicht in jeder Organisation identisch. Ein intern als Helpdesk bezeichnetes Team kann praktisch alle Aufgaben eines modernen Service Desk erfüllen. > **Merke** > > Die Bezeichnung allein entscheidet nicht über die Qualität oder den tatsächlichen Aufgabenbereich. --- **Service Desk und technische Supportgruppen unterscheiden** Technische Supportgruppen besitzen häufig vertieftes Fachwissen. Beispiele: - Netzwerkteam, - Serverteam, - Datenbankteam, - Anwendungssupport, - Workplace-Team, - Cloud-Team, - Identitätsmanagement, - Informationssicherheit, - und externer Herstellersupport. Der Service Desk besitzt dagegen häufig eine breitere Sicht auf: - Benutzer, - Services, - bekannte Lösungen, - Kontaktwege, - Statuskommunikation, - Priorisierung, - und den gesamten Bearbeitungsstand. Ein Anliegen kann an eine technische Supportgruppe übergeben werden. Trotzdem sollte geklärt bleiben: - Wer besitzt den Vorgang? - Wer kommuniziert mit dem Benutzer? - Welche Informationen werden übergeben? - Wer überwacht den Fortschritt? - Wer bestätigt die Wiederherstellung? - Wer schließt den Vorgang ab? > **Typischer Fehler** > > Nach der technischen Weiterleitung fühlt sich niemand mehr für die Ende-zu-Ende-Kommunikation und das Benutzerergebnis verantwortlich. --- **Support-Level sind keine zwingende ITIL-Struktur** Viele Organisationen verwenden Bezeichnungen wie: - First-Level Support, - Second-Level Support, - Third-Level Support, - Tier 1, - Tier 2, - oder Tier 3. Eine mögliche Einteilung ist: | Ebene | Möglicher Schwerpunkt | |---|---| | **First Level** | Kontakt, Erfassung, erste Diagnose und bekannte Lösungen | | **Second Level** | vertieftes technisches oder fachliches Wissen | | **Third Level** | hochspezialisierte interne Experten, Entwicklung oder Hersteller | Diese Struktur kann hilfreich sein. Sie ist jedoch keine zwingend vorgeschriebene ITIL-Organisationsform. Mögliche Nachteile einer starren Level-Struktur: - viele Übergaben, - wiederholte Rückfragen, - lange Warteschlangen, - Verantwortungsverschiebung, - und Verlust von Kontext. Alternative oder ergänzende Modelle sind beispielsweise: - funktionsübergreifende Teams, - Swarming, - direkte Zusammenarbeit, - Produktteams mit Ende-zu-Ende-Verantwortung, - oder automatisierte Standarderfüllung. --- **Swarming als mögliche Arbeitsweise** Beim Swarming wird ein komplexer Vorgang nicht nur linear von Supportstufe zu Supportstufe weitergereicht. Stattdessen werden geeignete Fachkräfte frühzeitig zur gemeinsamen Bearbeitung einbezogen. Mögliche Vorteile: - weniger Übergaben, - schnellerer Wissensaustausch, - Erhalt des ursprünglichen Kontexts, - bessere Zusammenarbeit, - und schnellere Entwicklung neuer Fähigkeiten. Mögliche Voraussetzungen: - sichtbare Informationen, - geeignete Kommunikationswerkzeuge, - klare Koordination, - ausreichende Verfügbarkeit von Fachkräften, - und nachvollziehbare Verantwortung. Swarming ist eine mögliche Praxisempfehlung und keine für jede Organisation vorgeschriebene ITIL-Struktur. --- **Mögliche Organisationsmodelle** Ein Service Desk kann unterschiedlich organisiert werden. --- **Zentraler Service Desk** Ein gemeinsames Team unterstützt mehrere Standorte oder Bereiche. Mögliche Vorteile: - einheitliche Arbeitsweise, - zentrale Übersicht, - gemeinsame Wissensbasis, - und besser bündelbare Kapazität. Mögliche Herausforderungen: - geringere Nähe zu lokalen Besonderheiten, - Sprach- oder Zeitzonenunterschiede, - und fehlendes Wissen über einzelne Standorte. --- **Lokaler Service Desk** Support befindet sich nahe bei Benutzern oder Standorten. Mögliche Vorteile: - Kenntnis lokaler Arbeitsabläufe, - persönliche Erreichbarkeit, - und Unterstützung vor Ort. Mögliche Herausforderungen: - unterschiedliche Arbeitsweisen, - Wissenssilos, - schwankende Auslastung, - und uneinheitliche Servicequalität. --- **Virtueller Service Desk** Mitarbeiter arbeiten verteilt, erscheinen für Benutzer aber als gemeinsamer Service Desk. Mögliche Vorteile: - ortsunabhängige Zusammenarbeit, - flexiblere Kapazitätsverteilung, - und gemeinsame Bearbeitung. Mögliche Herausforderungen: - technische Abhängigkeit von Kommunikationswerkzeugen, - Koordinationsbedarf, - und mögliche Informationsverluste. --- **Follow-the-Sun-Modell** Mehrere Service-Desk-Standorte in verschiedenen Zeitzonen übernehmen nacheinander die Bearbeitung. Mögliche Vorteile: - längere oder durchgehende Servicezeiten, - bessere Verteilung internationaler Nachfrage. Mögliche Herausforderungen: - Übergaben zwischen Zeitzonen, - Sprach- und Kulturunterschiede, - unterschiedliche Zugriffsrechte, - und notwendige einheitliche Dokumentation. --- **Spezialisierter Service Desk** Ein Service Desk ist auf bestimmte: - Produkte, - Services, - Kunden, - Benutzergruppen, - oder Branchen ausgerichtet. Möglicher Vorteil: - tieferes Fach- und Kontextwissen. Mögliche Herausforderung: - mehrere Kontaktpunkte und unklare Zuständigkeiten für Benutzer. --- **Kontaktkanäle** Ein Service Desk kann über mehrere Kanäle erreichbar sein. | Kanal | Geeignet für | Mögliche Herausforderung | |---|---|---| | **Self-Service-Portal** | strukturierte Incidents und Requests | Benutzer müssen das passende Angebot finden | | **Telefon** | dringende oder erklärungsbedürftige Situationen | Dokumentation muss während oder nach dem Gespräch erfolgen | | **E-Mail** | weniger dringende und schriftlich beschreibbare Anliegen | häufig unvollständige oder unstrukturierte Angaben | | **Chat** | schnelle Rückfragen und direkte Kommunikation | Gesprächskontext muss im Vorgang gesichert werden | | **virtueller Agent** | häufige Fragen und standardisierte Anliegen | Fehlinterpretation und unzureichende Eskalation möglich | | **persönlicher Kontakt** | Vor-Ort-Unterstützung und komplexe Kommunikation | Meldungen dürfen nicht außerhalb der Nachverfolgung bleiben | | **Mobile App** | Meldungen und Status unterwegs | Sicherheit und Bedienbarkeit müssen berücksichtigt werden | | **technische Integration** | automatische Erfassung aus anderen Systemen | nicht jede technische Meldung ist ein Benutzerkontakt oder Incident | Die Organisation sollte für jeden Kanal klären: - welche Anliegen geeignet sind, - welche Servicezeiten gelten, - welche Informationen benötigt werden, - wie Authentifizierung erfolgt, - wie Kontakte dokumentiert werden, - und wie bei kritischen Situationen eskaliert wird. --- **Mehrere Kanäle, aber ein gemeinsamer Überblick** Ein Benutzer kann möglicherweise: - anrufen, - eine E-Mail senden, - einen Chat beginnen, - oder ein Portal verwenden. Trotzdem sollten relevante Informationen möglichst in einer gemeinsamen Vorgangs- und Kommunikationssicht zusammengeführt werden. Andernfalls entstehen: - doppelte Tickets, - widersprüchliche Statusinformationen, - fehlender Kontext, - und unnötige Rückfragen. > **Praxistipp** > > Die Anzahl der Kontaktkanäle sollte nicht größer sein als die Fähigkeit der Organisation, diese zuverlässig zu überwachen, zusammenzuführen und zu bearbeiten. --- **Der geeignete Kanal hängt von der Situation ab** Nicht jedes Anliegen eignet sich für jeden Kanal. Beispiele: | Situation | Möglicherweise geeigneter Kanal | |---|---| | allgemeine Standardsoftware bestellen | Self-Service-Portal | | kritischer Ausfall eines wichtigen Service | Telefon oder definierter Major-Incident-Meldeweg | | einfache Statusabfrage | Portal, Chatbot oder automatische Nachricht | | möglicher Sicherheitsvorfall | besonders geschützter und bekannter Meldeweg | | komplexes Problem mit vielen Rückfragen | Telefon, Chat oder gemeinsamer Termin | | Feedback zu einem Service | Portal, Umfrage oder persönlicher Kontakt | | Kennwort vergessen | sicherer Self-Service oder verifizierter Supportkontakt | Die Organisation legt die tatsächlichen Kanäle und Regeln fest. --- **Erreichbarkeit und Servicezeiten** Der Service Desk muss nicht automatisch rund um die Uhr besetzt sein. Mögliche Modelle: - Geschäftszeiten, - erweiterte Servicezeiten, - Bereitschaft außerhalb der Geschäftszeiten, - 24×7-Betrieb, - unterschiedliche Zeiten je Service oder Benutzergruppe, - oder Kombination aus menschlichem Support und Self-Service. Zu klären ist: - Welche Services sind außerhalb der normalen Arbeitszeit kritisch? - Welche Benutzer benötigen Unterstützung? - Welche Incidents müssen sofort behandelt werden? - Welche Kontaktwege gelten außerhalb der Servicezeit? - Wer übernimmt Bereitschaft? - Welche Lieferanten sind erreichbar? - Welche Entscheidungen dürfen getroffen werden? - Wie werden Übergaben am nächsten Arbeitstag durchgeführt? > **Wichtig** > > Servicezeiten des Service Desk, Supportzeiten eines Service und technische Betriebszeiten können unterschiedlich sein. --- **Service Desk als Kommunikationszentrum** Der Service Desk besitzt häufig eine wichtige Rolle bei der Kommunikation. Dazu gehören: - Eingangsbestätigung, - Rückfragen, - Statusinformationen, - erwartete nächste Schritte, - bekannte Zwischenlösungen, - Hinweise zu geplanten Wartungen, - Informationen bei Störungen, - und Abschlusskommunikation. Gute Kommunikation sollte möglichst sein: - verständlich, - korrekt, - zielgruppengerecht, - handlungsorientiert, - zeitnah, - konsistent, - und ehrlich. Ungeeignete Statusmeldung: > Der Incident befindet sich beim Second Level. Bessere Statusmeldung: > Das Netzwerkteam untersucht derzeit die Verbindung zum zentralen Dateiservice. Eine nächste Statusmeldung erfolgt spätestens um 14:30 Uhr. Sie müssen aktuell nichts weiter unternehmen. --- **Keine unbelegten Zusagen machen** Ein Service-Desk-Mitarbeiter sollte keine Wiederherstellungszeit versprechen, wenn diese nicht ausreichend belegt ist. Ungeeignet: > Das funktioniert in zehn Minuten wieder. Besser: > Das zuständige Team untersucht die Störung. Eine verlässliche Wiederherstellungszeit liegt noch nicht vor. Die nächste Aktualisierung erfolgt um 11:00 Uhr. > **Merke** > > Ein angekündigter Zeitpunkt für die nächste Information ist häufig zuverlässiger als eine unbelegte Schätzung der vollständigen Lösung. --- **Empathie und professioneller Umgang** Benutzer melden nicht nur einen technischen Fehler. Sie erleben möglicherweise: - Arbeitsunterbrechung, - Zeitdruck, - Unsicherheit, - Frustration, - drohenden Datenverlust, - oder Auswirkungen auf Kunden und Kollegen. Professioneller Umgang bedeutet: - zuhören, - nicht vorschnell unterbrechen, - Auswirkungen verstehen, - verständlich kommunizieren, - keine Schuldzuweisungen vornehmen, - und das Anliegen ernst nehmen. Empathie bedeutet nicht: - jede Forderung ungeprüft zu erfüllen, - jede subjektive Dringlichkeit als höchste Priorität einzustufen, - oder Sicherheitsvorgaben zu umgehen. Beispiel: > Ich verstehe, dass Sie die Datei für den heutigen Kundentermin benötigen. Ich prüfe jetzt, ob nur diese Datei oder der gesamte Dateiservice betroffen ist, und informiere Sie über den nächsten Schritt. --- **Geschäfts- und Benutzerkontext verstehen** Technisches Wissen allein reicht für guten Service-Desk-Support nicht aus. Hilfreich ist auch das Verständnis: - welche Aufgaben Benutzer ausführen, - welche Services dafür benötigt werden, - welche Zeitpunkte besonders kritisch sind, - welche Begriffe die Fachabteilung verwendet, - und welche Auswirkungen eine Störung besitzt. Beispiel: Der Ausfall eines Etikettendruckers kann technisch wie ein einzelnes Geräteproblem wirken. In einem Lager kann er jedoch: - den Versand stoppen, - Liefertermine gefährden, - und mehrere nachgelagerte Prozesse blockieren. > **Praxistipp** > > Service-Desk-Mitarbeiter sollten wichtige Arbeitsbereiche und deren Abhängigkeit von digitalen Services kennenlernen. --- **Erste Diagnose** Der Service Desk kann eine erste strukturierte Diagnose durchführen. Mögliche Ziele: - Situation verstehen, - betroffenen Service bestimmen, - Umfang der Auswirkung feststellen, - bekannte Lösung finden, - benötigte Informationen sammeln, - und eine unnötige Weiterleitung vermeiden. Mögliche Fragen: - Was wollten Sie durchführen? - Was ist stattdessen geschehen? - Welche Fehlermeldung wird angezeigt? - Seit wann besteht die Störung? - Hat die Funktion vorher gearbeitet? - Sind weitere Benutzer betroffen? - Funktionieren andere Services? - Wurde kürzlich etwas verändert? - Welche Schritte wurden bereits versucht? - Besteht eine geeignete Zwischenlösung? - Können Screenshots oder Protokolle sicher bereitgestellt werden? Die Diagnose darf nicht zu einer unstrukturierten Liste beliebiger Versuche werden. Jede Maßnahme sollte: - einen erkennbaren Zweck besitzen, - zum Risiko passen, - dokumentiert werden, - und hinsichtlich ihres Ergebnisses geprüft werden. --- **First Contact Resolution** First Contact Resolution beschreibt, dass ein Anliegen während des ersten Kontakts ausreichend gelöst oder erfüllt wird. Mögliche Vorteile: - schnellere Wiederherstellung, - weniger Übergaben, - geringerer Benutzeraufwand, - und bessere Erfahrung. First Contact Resolution darf jedoch nicht durch ungeeignete Maßnahmen künstlich erhöht werden. Ungeeignet sind beispielsweise: - Ticket ohne bestätigte Lösung schließen, - Benutzer mit einer ungetesteten Anleitung abweisen, - Sicherheitskontrollen umgehen, - oder komplexe Probleme nur oberflächlich behandeln. > **Merke** > > Eine Lösung beim ersten Kontakt ist nur dann wertvoll, wenn sie korrekt, sicher und aus Benutzersicht wirksam ist. --- **Shift Left** Shift Left beschreibt die Verlagerung geeigneten Wissens und geeigneter Fähigkeiten näher zum Benutzer oder zu früheren Supportstufen. Beispiele: - bessere Self-Service-Anleitungen, - Wissensartikel für den Service Desk, - sichere Kennwort-Selbstverwaltung, - automatisierte Standardbereitstellung, - Diagnoseinformationen direkt im Ticket, - und Schulung von Service-Desk-Mitarbeitern. Mögliche Vorteile: - schnellere Lösung, - weniger Übergaben, - Entlastung spezialisierter Teams, - und bessere Skalierbarkeit. Shift Left darf nicht bedeuten: - Verantwortung ohne Befugnisse zu verlagern, - komplexe Aufgaben ungeschulten Mitarbeitern zu übertragen, - oder Risiken nur aus Kostengründen zu verschieben. --- **Funktionale Eskalation** Eine funktionale Eskalation erfolgt, wenn zusätzliche: - Fähigkeiten, - technische Berechtigungen, - Informationen, - Werkzeuge, - oder Lieferantenunterstützung benötigt werden. Beispiele: - Netzwerkfehler an das Netzwerkteam, - Datenbankproblem an den Datenbankadministrator, - Softwarefehler an den Hersteller, - Sicherheitsverdacht an das zuständige Sicherheitsteam. Eine gute funktionale Eskalation enthält: - verständliche Problembeschreibung, - betroffenen Service, - Auswirkungen, - bisherige Diagnose, - Testergebnisse, - relevante Fehlermeldungen, - durchgeführte Maßnahmen, - und erwarteten nächsten Schritt. Ungeeignet: > Geht nicht. Bitte prüfen. Besser: > Seit 09:20 Uhr können zwölf Benutzer am Standort Nord keine Verbindung zum zentralen Dateiservice herstellen. Lokale Netzwerkverbindung und DNS-Auflösung funktionieren. Der Verbindungsversuch zum TCP-Port des Dateiservice schlägt fehl. Andere Standorte sind nicht betroffen. Benötigt wird die Prüfung der Standortverbindung und der Firewall-Regeln. --- **Hierarchische Eskalation** Eine hierarchische Eskalation kann notwendig sein, wenn: - Auswirkungen erheblich sind, - Zielzeiten gefährdet werden, - Ressourcen fehlen, - Verantwortlichkeiten unklar sind, - eine Entscheidung außerhalb vorhandener Befugnisse liegt, - mehrere Teams im Konflikt stehen, - oder ein Risiko akzeptiert werden muss. Sie bedeutet nicht automatisch, dass ein technischer Vorgang an eine Führungskraft zur Lösung weitergegeben wird. Die Führungskraft oder autorisierte Rolle kann beispielsweise: - zusätzliche Ressourcen bereitstellen, - Prioritäten verändern, - eine Entscheidung treffen, - Risiken akzeptieren oder weiter eskalieren, - und Kommunikation koordinieren. --- **Ownership eines Vorgangs** Die Organisation sollte festlegen, wer einen Vorgang über seinen gesamten Verlauf besitzt. Mögliche Modelle: - Service Desk bleibt bis zum Abschluss Eigentümer des Benutzerkontakts. - technisches Team übernimmt vollständiges Ownership. - Service Desk besitzt Kommunikation, Fachteam besitzt technische Bearbeitung. - Incident Manager übernimmt bei schweren Incidents die Koordination. - Product Team besitzt das Ende-zu-Ende-Ergebnis für seinen Service. Unabhängig vom Modell muss geklärt sein: - Wer überwacht den Fortschritt? - Wer kommuniziert? - Wer eskaliert? - Wer prüft das Ergebnis? - Wer schließt den Vorgang? - Wer leitet Folgeaktivitäten ein? > **Typischer Fehler** > > Ein Ticket besitzt eine zugewiesene Gruppe, aber keine Person oder Rolle fühlt sich für das Gesamtergebnis verantwortlich. --- **Warme und kalte Übergabe** **Kalte Übergabe** Der Vorgang wird ohne direkte Abstimmung einer anderen Gruppe zugewiesen. Mögliche Folge: - Kontextverlust, - Rückfragen, - unklare Verantwortung, - und längere Wartezeit. **Warme Übergabe** Die übergebende und übernehmende Rolle stimmen sich ab. Mögliche Bestandteile: - Situation erklären, - wichtige Informationen bestätigen, - nächste Verantwortung klären, - Benutzer über die Übergabe informieren, - und Rückfragen direkt beantworten. Eine warme Übergabe ist besonders hilfreich bei: - komplexen Incidents, - emotional belastenden Situationen, - Sicherheitsvorfällen, - wichtigen Kunden, - und schwer nachvollziehbaren Fehlerbildern. Sie ist nicht für jeden einfachen Vorgang notwendig. --- **Ticketqualität** Ein gutes Ticket unterstützt: - Bearbeitung, - Kommunikation, - Nachvollziehbarkeit, - Auswertung, - Wissen, - und Verbesserung. Mögliche Mindestinformationen: - meldende Person, - betroffener Benutzer oder Bereich, - Kontaktweg, - betroffener Service, - verständliche Beschreibung, - beobachtetes Symptom, - Zeitpunkt, - Auswirkungen, - Dringlichkeit, - bereits durchgeführte Schritte, - aktuelle Verantwortung, - und nächster Schritt. Abhängig vom Vorgang können zusätzlich notwendig sein: - Gerät oder Asset, - Standort, - Fehlermeldung, - Screenshot, - Protokolldaten, - betroffene Version, - Lieferant, - Sicherheitsbezug, - oder zugehöriger Change. > **Wichtig** > > Es sollen nur Informationen erfasst werden, die einen erkennbaren Zweck besitzen und rechtmäßig verarbeitet werden dürfen. --- **Objektiv und verständlich dokumentieren** Ungeeignete Dokumentation: > Benutzer hat wieder alles falsch gemacht. Besser: > Der Benutzer verwendete den bisherigen Anmeldeweg. Seit der Änderung vom 1. August ist eine zusätzliche MFA-Bestätigung erforderlich. Die neue Anleitung war ihm nicht bekannt. Ungeeignete Dokumentation: > Server kaputt. Besser: > Der Anwendungsserver ist seit 10:15 Uhr nicht über HTTPS erreichbar. ICMP und SSH funktionieren. Der Webdienst ist beendet und startet mit Fehlercode 1. Dokumentation sollte: - sachlich, - nachvollziehbar, - diskriminierungsfrei, - und für die weitere Bearbeitung geeignet sein. --- **Kategorisierung** Kategorien können dabei helfen: - zuständige Bearbeitung zu bestimmen, - ähnliche Vorgänge zu erkennen, - Berichte zu erstellen, - Wissen zuzuordnen, - und Verbesserungen zu identifizieren. Eine Kategorie sollte nicht ausschließlich die vermutete technische Ursache abbilden. Zu Beginn ist die Ursache häufig unbekannt. Mögliche Kategorisierungsdimensionen: - betroffener Service, - Serviceangebot, - Kontaktart, - Incident oder Service Request, - technischer Bereich, - Benutzergruppe, - Standort, - und Sicherheitsbezug. > **Typischer Fehler** > > Benutzer müssen in einem Portal aus einer umfangreichen technischen Komponentenliste auswählen, obwohl sie den betroffenen Service und die Ursache nicht kennen. --- **Priorisierung** Die Priorität sollte nach den Regeln der Organisation bestimmt werden. Häufig verwendete Kriterien sind: - Auswirkungen, - Dringlichkeit, - Kritikalität des Service, - Anzahl betroffener Benutzer, - betroffener Geschäftsprozess, - verfügbare Zwischenlösung, - Sicherheits- oder Datenschutzrisiko, - drohender Datenverlust, - und zeitkritische Geschäftssituation. ITIL schreibt keine universelle Prioritätsmatrix vor. Beispiel: Ein einzelner ausgefallener Arbeitsplatz kann eine geringe Auswirkung besitzen. Ist es jedoch der einzige Arbeitsplatz zur Steuerung einer kritischen Anlage, kann die tatsächliche Auswirkung sehr hoch sein. > **Merke** > > Die Anzahl betroffener Benutzer ist wichtig, aber nicht das einzige Kriterium. --- **Der Service Desk entscheidet nicht allein nach Lautstärke** Benutzer können ihre Situation subjektiv als sehr dringend wahrnehmen. Der Service Desk sollte: - die Auswirkung ernst nehmen, - fehlende Informationen erfragen, - die organisatorischen Kriterien anwenden, - und eine abweichende Priorisierung verständlich erklären. Ungeeignet: > Das ist nicht dringend. Besser: > Ich verstehe, dass Sie die Anwendung heute benötigen. Nach unseren Prioritätskriterien ist aktuell nur Ihr Arbeitsplatz betroffen und es steht ein Ersatzarbeitsplatz zur Verfügung. Der Vorgang wird deshalb als Priorität 3 bearbeitet. Sollte auch der Ersatz nicht funktionieren oder weitere Benutzer betroffen sein, wird die Priorität erneut bewertet. --- **Major Incidents erkennen und eskalieren** Ein Major Incident ist ein besonders schwerwiegender Incident. Die Organisation muss eigene Kriterien festlegen. Mögliche Hinweise: - Ausfall eines kritischen Service, - sehr viele betroffene Benutzer, - erhebliche Geschäfts- oder Kundenwirkung, - mögliche Sicherheits- oder Datenschutzverletzung, - drohender erheblicher Datenverlust, - starke öffentliche Wirkung, - oder sehr hoher Koordinationsbedarf. Der Service Desk kann eine wichtige Rolle übernehmen bei: - Erkennen möglicher Kriterien, - schneller Eskalation, - Sammeln von Benutzerinformationen, - Verwenden freigegebener Statusmeldungen, - und Vermeiden widersprüchlicher Kommunikation. Major Incident Management wird nicht als eigenständige der 34 ITIL Management Practices behandelt. Organisationen können jedoch ein eigenes Major-Incident-Verfahren innerhalb ihrer Incident-Management-Arbeitsweise verwenden. --- **Knowledge Management** Der Service Desk benötigt gut nutzbares Wissen. Beispiele: - Diagnoseanleitungen, - bekannte Lösungen, - Workarounds, - Serviceinformationen, - Benutzeranleitungen, - Eskalationswege, - Lieferantenkontakte, - Sicherheitsverfahren, - und aktuelle Störungsinformationen. Ein Wissensartikel sollte möglichst: - verständlichen Titel, - klare Zielgruppe, - Voraussetzungen, - sichere Schritte, - erwartetes Ergebnis, - Versionsstand, - Verantwortlichen, - und Prüfdatum enthalten. Der Service Desk ist gleichzeitig eine wichtige Quelle neuen Wissens. Wiederkehrende Fragen können zeigen: - Anleitung ist unverständlich, - Funktion ist schlecht gestaltet, - Serviceangebot ist unklar, - oder Schulung fehlt. --- **Self-Service** Self-Service kann Benutzern ermöglichen: - Informationen zu finden, - standardisierte Anfragen zu stellen, - den Status zu prüfen, - Kennwörter sicher zurückzusetzen, - Software anzufordern, - oder bekannte einfache Probleme zu lösen. Erfolgreicher Self-Service benötigt: - verständliche Sprache, - gute Suchfunktion, - aktuelle Inhalte, - klare Serviceangebote, - einfache Formulare, - geeignete Authentifizierung, - barrierearme Bedienung, - und einen sichtbaren Weg zu menschlicher Unterstützung. > **Typischer Fehler** > > Ein Portal wird eingeführt und Benutzer werden gezwungen, es zu verwenden, obwohl Inhalte, Suche und Formulare unverständlich sind. Self-Service sollte Benutzeraufwand reduzieren und nicht nur Arbeit vom Service Desk auf Benutzer verlagern. --- **Automatisierung** Mögliche Automatisierungen im Service Desk: - automatische Eingangsbestätigung, - Vorschlag einer Kategorie, - Zuordnung anhand klarer Regeln, - Anzeige passender Wissensartikel, - Statusbenachrichtigungen, - sichere Kennwort-Selbstverwaltung, - automatische Standardbereitstellung, - Erkennung doppelter Tickets, - und Eskalation bei drohender Zielverletzung. Vor der Automatisierung muss geklärt sein: - Ist der Ablauf verstanden? - Sind Regeln eindeutig? - Sind Eingangsdaten zuverlässig? - Welche Ausnahmen bestehen? - Wie werden Fehler erkannt? - Wie kann ein Mitarbeiter eingreifen? - Wer trägt Verantwortung? - Wie wird der Nutzen gemessen? --- **Künstliche Intelligenz im Service Desk** KI kann unter anderem unterstützen bei: - Zusammenfassung von Kontakten, - Erkennung ähnlicher Vorgänge, - Kategorisierungsvorschlägen, - Übersetzung, - Wissenssuche, - Formulierung von Antworten, - Erkennung von Mustern, - und einfachen virtuellen Agenten. KI kann jedoch Fehler erzeugen. Mögliche Risiken: - falsche Kategorisierung, - unzutreffende Lösungsvorschläge, - Offenlegung vertraulicher Informationen, - erfundene technische Aussagen, - ungeeignete Priorisierung, - diskriminierende oder unangemessene Kommunikation, - und unklare Verantwortung. Notwendig sind unter anderem: - zugelassene Anwendungsfälle, - Datenschutz- und Sicherheitsprüfung, - geeignete Datenquellen, - menschliche Kontrolle, - transparente Kennzeichnung, - Fehlerbehandlung, - und regelmäßige Qualitätsprüfung. > **Sicherheitsrelevant** > > KI-generierte technische Anweisungen dürfen abhängig vom möglichen Risiko nicht ungeprüft an Benutzer weitergegeben oder auf produktiven Systemen ausgeführt werden. --- **Der menschliche Kontakt bleibt wichtig** Automatisierung und Self-Service können standardisierte Anliegen effizient bearbeiten. Menschliche Unterstützung bleibt besonders wichtig bei: - komplexen Situationen, - unklaren Anforderungen, - emotional belastenden Incidents, - wichtigen Geschäftsfolgen, - Sicherheitsvorfällen, - mehreren gleichzeitig auftretenden Problemen, - und Situationen, die Einfühlungsvermögen oder kreative Zusammenarbeit erfordern. Ein guter Service Desk verbindet deshalb: - menschliches Verständnis, - technisches Wissen, - Servicekontext, - geeignete Automatisierung, - und zuverlässige Informationen. --- **Informationssicherheit am Service Desk** Der Service Desk verarbeitet häufig sensible Informationen und kann ein Ziel für Social Engineering sein. Wichtige Grundsätze: - Identität nach festgelegtem Verfahren prüfen. - niemals Kennwörter erfragen oder dokumentieren. - keine Sicherheitskontrolle nur aufgrund von Zeitdruck umgehen. - administrative Zugänge besonders schützen. - sensible Informationen nur an berechtigte Personen weitergeben. - verdächtige Kontakte nach festgelegtem Verfahren eskalieren. - Remote-Zugriffe transparent und kontrolliert durchführen. - keine unbekannten Dateien oder Links ungeprüft öffnen. - Sicherheitsvorfälle nicht in ungeeigneten öffentlichen Kanälen diskutieren. - nur notwendige personenbezogene Daten erfassen. Beispiel: Eine Person ruft an und verlangt dringend die Zurücksetzung des Kennworts eines Geschäftsführers. Zeitdruck, Autoritätsbezug und angebliche Dringlichkeit dürfen die vorgesehene Identitätsprüfung nicht ersetzen. --- **Remote-Unterstützung** Bei Remote-Support sollte geklärt sein: - welches Werkzeug zugelassen ist, - wie der Benutzer zustimmt, - wie die Identität geprüft wird, - welche Aktionen durchgeführt werden dürfen, - ob Sitzungen protokolliert werden, - wie sensible Bildschirminhalte geschützt werden, - und wann die Verbindung beendet wird. Der Mitarbeiter sollte: - erklären, was er durchführt, - keine unnötigen Daten öffnen, - keine Kennwörter beobachten oder speichern, - und den Benutzer über das Ergebnis informieren. --- **Datenschutz und Vertraulichkeit** Tickets können enthalten: - personenbezogene Daten, - Gesundheitsinformationen, - vertrauliche Geschäftsdaten, - Sicherheitsinformationen, - oder technische Zugangsdaten. Deshalb sollte die Organisation festlegen: - welche Informationen notwendig sind, - wer darauf zugreifen darf, - wie lange sie gespeichert werden, - welche Inhalte nicht erfasst werden dürfen, - wie Anhänge geschützt werden, - und wie Daten gelöscht oder anonymisiert werden. > **Typischer Fehler** > > Benutzer senden vollständige vertrauliche Dokumente, obwohl für die Diagnose nur eine Fehlermeldung oder ein technisch begrenzter Ausschnitt erforderlich wäre. --- **Zusammenarbeit mit Lieferanten** Ein Service Desk kann externe Lieferanten einbinden. Dafür sollten verfügbar sein: - Anbietername, - betroffene Leistung, - Vertrags- oder Kundennummer, - Supportkontakt, - Servicezeiten, - Eskalationsweg, - benötigte Diagnoseinformationen, - und interne Verantwortung. Eine Lieferantenmeldung sollte möglichst enthalten: - konkrete Auswirkung, - betroffenen Service, - Beginn, - Umfang, - technische Beobachtungen, - bereits geprüfte Punkte, - Dringlichkeit, - und gewünschte Unterstützung. Die Weitergabe an einen Lieferanten beendet nicht die interne Verantwortung für: - Koordination, - Kommunikation, - Sicherheitsbewertung, - und Prüfung des Ende-zu-Ende-Service. --- **Service-Desk-Kompetenzen** Mögliche benötigte Kompetenzen: - aktives Zuhören, - verständliche Kommunikation, - Empathie, - technische Grundlagen, - Serviceverständnis, - strukturierte Diagnose, - Priorisierung, - Dokumentation, - Wissensnutzung, - Sicherheitsbewusstsein, - Konfliktfähigkeit, - Zusammenarbeit, - Zeitmanagement, - und Lernbereitschaft. Nicht jeder Mitarbeiter benötigt dieselbe technische Tiefe. Der Service Desk benötigt jedoch ausreichend gemeinsames Wissen über: - wichtige Benutzergruppen, - kritische Services, - grundlegende Abhängigkeiten, - typische Störungen, - Serviceangebote, - und Eskalationswege. --- **Einarbeitung neuer Service-Desk-Mitarbeiter** Eine sinnvolle Einarbeitung kann umfassen: - Organisation und Geschäftsbereiche, - wichtige Produkte und Services, - Benutzergruppen, - Kontaktkanäle, - Ticketsystem, - Sicherheits- und Datenschutzvorgaben, - Incident- und Request-Arbeitsweisen, - Prioritätskriterien, - Eskalationswege, - Knowledge-Base, - Lieferanten, - Kommunikationsstandards, - und praktische Begleitung erfahrener Mitarbeiter. Zusätzlich hilfreich: - Besuche wichtiger Arbeitsbereiche, - Beobachtung realer Benutzeraufgaben, - Übung typischer Gesprächssituationen, - und kontrollierte Bearbeitung erster Vorgänge. --- **Qualität statt reiner Geschwindigkeit** Ein Service Desk sollte nicht ausschließlich nach Geschwindigkeit beurteilt werden. Mögliche Qualitätsaspekte: - Anliegen wurde richtig verstanden. - Informationen sind vollständig. - Kategorisierung ist brauchbar. - Priorität ist nachvollziehbar. - Kommunikation ist verständlich. - Benutzer musste Informationen nicht mehrfach liefern. - Lösung ist sicher und wirksam. - Wiederherstellung wurde bestätigt. - Dokumentation unterstützt spätere Bearbeitung. - Wissen wurde aktualisiert. - mögliche Verbesserungen wurden erkannt. --- **Mögliche Kennzahlen** Kennzahlen werden von der jeweiligen Organisation festgelegt. Mögliche Beispiele: | Kennzahl | Mögliche Aussage | |---|---| | **First Contact Resolution** | Anteil geeigneter Anliegen, die beim ersten Kontakt gelöst werden | | **durchschnittliche Antwortzeit** | Zeit bis zur ersten qualifizierten Reaktion | | **gesamte Lösungs- oder Erfüllungszeit** | Ende-zu-Ende-Dauer bis zum Ergebnis | | **Abbruchquote** | Anteil abgebrochener Telefon- oder Chatkontakte | | **Wiedereröffnungsquote** | mögliche Hinweise auf unvollständige Lösungen | | **Anzahl der Übergaben** | möglicher Hinweis auf unnötige Weiterleitungen | | **Benutzerzufriedenheit** | subjektive Erfahrung nach dem Kontakt | | **erneute Kontaktaufnahme** | mögliche Hinweise auf fehlende Lösung oder Kommunikation | | **Ticketqualität** | Vollständigkeit und Nutzbarkeit der Dokumentation | | **Backlog-Alter** | Alter unbearbeiteter oder nicht abgeschlossener Vorgänge | | **Nutzung von Wissen** | Verwendung und Wirksamkeit von Wissensartikeln | | **Self-Service-Erfolgsquote** | Anteil erfolgreich selbst erledigter geeigneter Anliegen | Keine einzelne Kennzahl beschreibt die gesamte Leistung. --- **Problematische Kennzahlen** **Möglichst kurze Gesprächsdauer** Mögliche Fehlwirkung: - Benutzer wird unterbrochen. - Problem wird nicht vollständig verstanden. - spätere Rückfragen erhöhen den Gesamtaufwand. **Möglichst viele geschlossene Tickets** Mögliche Fehlwirkung: - Vorgänge werden voreilig geschlossen. - Qualität und Outcome werden vernachlässigt. **Möglichst hohe First Contact Resolution** Mögliche Fehlwirkung: - komplexe Vorgänge werden oberflächlich behandelt. - notwendige Eskalation wird vermieden. **Möglichst wenige Eskalationen** Mögliche Fehlwirkung: - Service Desk bearbeitet Aufgaben ohne ausreichende Fähigkeiten oder Befugnisse. **Möglichst geringe Kosten pro Kontakt** Mögliche Fehlwirkung: - menschliche Unterstützung wird reduziert, obwohl die Benutzererfahrung leidet. > **Merke** > > Kennzahlen beeinflussen Verhalten. > > Sie sollten deshalb gemeinsam und im Zusammenhang mit Outcomes, Qualität und Risiken betrachtet werden. --- **Benutzerfeedback** Benutzerfeedback kann erhoben werden durch: - kurze Umfragen, - Rückfragen nach Abschluss, - Interviews, - Workshops, - Auswertung von Beschwerden, - Beobachtung von Kontaktmustern, - und Gespräche mit Fachabteilungen. Feedback sollte: - freiwillig, - verständlich, - möglichst kurz, - und tatsächlich auswertbar sein. Eine sehr niedrige Rücklaufquote kann die Aussagekraft begrenzen. Negative Einzelbewertungen sollten nicht automatisch als persönliches Versagen eines Mitarbeiters behandelt werden. Zu untersuchen sind auch: - Produktqualität, - Wartezeit, - ungeeignete Vorgaben, - fehlende Befugnisse, - Lieferantenprobleme, - und unverständliche Serviceangebote. --- **Der Service Desk als Quelle für Continual Improvement** Der Service Desk erkennt häufig früh: - wiederkehrende Incidents, - unklare Serviceangebote, - häufige Benutzerfehler, - fehlende Schulung, - schlechte Dokumentation, - unnötige Prozessschritte, - fehlerhafte Automatisierungen, - und neue Benutzerbedürfnisse. Diese Erkenntnisse sollten nicht nur in einzelnen Tickets verbleiben. Mögliche Verbesserungen: - Wissensartikel erstellen, - Formular vereinfachen, - Serviceangebot verständlicher beschreiben, - Monitoring ergänzen, - Softwarefehler an Product Teams melden, - Request automatisieren, - wiederkehrendes Problem untersuchen, - oder Schulung verbessern. --- **Praxisbeispiel: Anmeldung funktioniert nicht** Ein Benutzer meldet telefonisch: > Ich kann mich nicht anmelden. **Ungeeignete Bearbeitung** 1. Ticket mit Titel „Login geht nicht“ erstellen. 2. Vorgang ohne weitere Informationen an das Serverteam senden. 3. Benutzer erhält keine Statusinformation. 4. Serverteam stellt fest, dass MFA betroffen ist. 5. Ticket wird an ein anderes Team weitergegeben. 6. Benutzer ruft erneut an. **Bessere Bearbeitung** 1. betroffenen Benutzer und Service bestimmen 2. genaue Fehlermeldung erfassen 3. feststellen, ob weitere Benutzer betroffen sind 4. Netzwerkverbindung und allgemeine Serviceinformation prüfen 5. bekannte Störungen und letzte Änderungen prüfen 6. sichere bekannte Lösung anwenden oder geeignete Fachgruppe einbinden 7. bisherigen Diagnoseweg dokumentieren 8. Benutzer über nächsten Schritt informieren 9. Wiederherstellung bestätigen 10. wiederkehrendes Muster an Problem Management oder Continual Improvement weitergeben --- **Praxisbeispiel: Drucker funktioniert nicht** Meldung: > Der Drucker ist kaputt. Mögliche Klärung: - Welcher Druckservice wird verwendet? - Welcher Drucker ist betroffen? - Können andere Benutzer drucken? - Kann der Benutzer auf einem anderen Drucker drucken? - Ist nur eine Anwendung betroffen? - Befindet sich ein Auftrag in der Warteschlange? - Zeigt das Gerät einen Hardwarefehler? - Besteht eine Netzwerkverbindung? - Wurde kürzlich ein Treiber oder eine Konfiguration geändert? - Gibt es einen alternativen Druckweg? Mögliche Einordnung: - lokaler Incident, - allgemeiner Serviceausfall, - Verbrauchsmaterial, - Hardwaredefekt, - Service Request, - oder Lieferantenfall. Das Beispiel zeigt, warum die Formulierung des Benutzers allein nicht die fachliche Kategorie bestimmt. --- **Praxisbeispiel: Verdächtige E-Mail** Ein Benutzer meldet eine verdächtige Nachricht. Der Service Desk sollte nach dem Sicherheitsverfahren handeln. Mögliche Schritte: - Benutzer auffordern, keine Links oder Anhänge zu öffnen, - erforderliche Informationen sicher erfassen, - Nachricht nicht unkontrolliert weiterleiten, - zuständige Sicherheitsrolle einbinden, - mögliche Betroffenheit weiterer Benutzer prüfen lassen, - und nur freigegebene Kommunikation verwenden. Der Vorgang darf nicht allein als normale E-Mail-Störung behandelt werden. --- **Praxisbeispiel: Mehrfachmeldungen bei einem Ausfall** Viele Benutzer melden gleichzeitig, dass die zentrale Dateiablage nicht erreichbar ist. Der Service Desk kann: 1. Meldungen zu einem gemeinsamen Incident zusammenführen 2. Auswirkung und betroffene Bereiche erfassen 3. Major-Incident-Kriterien prüfen 4. technische Teams und Lieferanten einbinden 5. bekannte Statusinformationen veröffentlichen 6. Benutzer von unnötigen Einzelrückfragen entlasten 7. Zwischenlösungen kommunizieren 8. Wiederherstellung bestätigen 9. Folgeaktivitäten dokumentieren > **Praxistipp** > > Bei einer bekannten größeren Störung kann eine gut sichtbare Statusmeldung mehr Benutzeraufwand reduzieren als die wiederholte Einzelbearbeitung identischer Kontakte. --- **Typische Fehler im Service Desk** **Fehler 1: Ticketweiterleitung als Hauptziel** Kontakte werden möglichst schnell weitergereicht, ohne ausreichende Informationen zu erfassen. --- **Fehler 2: Benutzer müssen die technische Zuständigkeit kennen** Portale oder Mitarbeiter verlangen, dass Benutzer selbst das richtige Fachteam auswählen. --- **Fehler 3: Priorisierung nach Lautstärke** Persönliche Kontakte, Hierarchie oder häufige Nachfragen bestimmen die Reihenfolge. --- **Fehler 4: Keine Ende-zu-Ende-Verantwortung** Nach einer Weiterleitung überwacht niemand Fortschritt und Benutzerkommunikation. --- **Fehler 5: Technische Wiederherstellung nicht bestätigen** Das Fachteam meldet Erfolg, aber der Benutzer kann weiterhin nicht arbeiten. --- **Fehler 6: Gesprächszeit über Qualität stellen** Mitarbeiter beenden Kontakte schnell, erzeugen dadurch aber Rückfragen und Nacharbeit. --- **Fehler 7: Service Desk als reine Einstiegsposition behandeln** Fähigkeiten, Entwicklungsmöglichkeiten und strategische Bedeutung werden unterschätzt. --- **Fehler 8: Wissen nur bei einzelnen Personen** Lösungen bleiben in privaten Notizen oder persönlichen Chatverläufen. --- **Fehler 9: Self-Service als Zwang verwenden** Benutzer erhalten keinen geeigneten menschlichen Kontaktweg für komplexe Situationen. --- **Fehler 10: KI-Antworten ungeprüft übernehmen** Falsche oder unsichere Lösungsvorschläge werden an Benutzer weitergegeben. --- **Fehler 11: Sicherheitskontrollen unter Zeitdruck umgehen** Identitäten werden nicht ausreichend geprüft oder sensible Informationen ungeschützt verarbeitet. --- **Fehler 12: Jede Meldung als Incident behandeln** Service Requests, Fragen, Feedback und Sicherheitsmeldungen werden falsch eingeordnet. --- **Fehler 13: Jeden Kontakt einzeln betrachten** Mehrfachmeldungen und wiederkehrende Muster werden nicht erkannt. --- **Fehler 14: Keine Rückmeldung bei Verzögerungen** Benutzer müssen wiederholt nach dem Status fragen. --- **Fehler 15: Ticket schließen, weil der Benutzer nicht sofort antwortet** Es wird nicht geprüft, ob angemessene Kontaktversuche, Fristen und alternative Wege verwendet wurden. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker können im Service Desk oder in nachgelagerten Fachteams arbeiten. Wichtige Beiträge sind: - technische Zusammenhänge verständlich erklären, - vollständige Diagnoseinformationen bereitstellen, - Rückfragen vermeiden, - Statusänderungen dokumentieren, - Serviceauswirkungen berücksichtigen, - sichere Lösungen anwenden, - Wissen weitergeben, - Lieferanteninformationen ergänzen, - und Verbesserungsmöglichkeiten melden. Wenn du ein Ticket aus dem Service Desk erhältst, prüfe: - Ist der betroffene Service bekannt? - Sind Symptom und Auswirkung verständlich? - Welche Diagnose wurde bereits durchgeführt? - Welche Ergebnisse liegen vor? - Ist die Priorität nachvollziehbar? - Welche Rückmeldung wird vom Fachteam erwartet? - Wer kommuniziert mit dem Benutzer? - Wie wird die Lösung bestätigt? - Muss Wissen oder Dokumentation aktualisiert werden? --- **30-Sekunden-Prüfung eines Benutzerkontakts** 1. **Person:** Wer meldet und wer ist betroffen? 2. **Service:** Welche Arbeitsfähigkeit oder welcher Service wird benötigt? 3. **Symptom:** Was wurde beobachtet? 4. **Zeit:** Seit wann besteht die Situation? 5. **Auswirkung:** Was kann nicht durchgeführt werden? 6. **Umfang:** Sind weitere Benutzer oder Standorte betroffen? 7. **Kontext:** Was wurde verändert oder bereits versucht? 8. **Einordnung:** Incident, Service Request, Frage, Feedback oder Sicherheitsmeldung? 9. **Nächster Schritt:** Wer übernimmt welche Aufgabe? 10. **Kommunikation:** Wann erhält der Benutzer die nächste Information? 11. **Ergebnis:** Wie wird die Wiederherstellung oder Erfüllung bestätigt? 12. **Lernen:** Muss Wissen oder eine Verbesserung ergänzt werden? --- **Checkliste für die Kontaktaufnahme** - [ ] Ist der Benutzer freundlich und professionell begrüßt worden? - [ ] Wurde die Identität bei Bedarf nach dem vorgesehenen Verfahren geprüft? - [ ] Ist klar, wer betroffen ist? - [ ] Ist der benötigte Service bekannt? - [ ] Wurde das beobachtete Symptom verständlich erfasst? - [ ] Wurde nach Auswirkungen und Umfang gefragt? - [ ] Wurden relevante Zeitangaben erfasst? - [ ] Wurden bereits durchgeführte Schritte dokumentiert? - [ ] Wurden sensible Informationen angemessen geschützt? - [ ] Wurde der nächste Schritt verständlich erklärt? - [ ] Wurde ein realistischer Zeitpunkt für die nächste Information genannt? --- **Checkliste für die Weiterleitung** - [ ] Ist die zuständige Practice oder Fachgruppe nachvollziehbar? - [ ] Ist der betroffene Service eindeutig? - [ ] Sind Auswirkungen und Priorität dokumentiert? - [ ] Sind Fehlermeldungen und Beobachtungen enthalten? - [ ] Sind bisherige Diagnose und Ergebnisse dokumentiert? - [ ] Sind relevante Screenshots oder Protokolle sicher beigefügt? - [ ] Ist klar, welche Unterstützung benötigt wird? - [ ] Ist die weitere Verantwortung geklärt? - [ ] Weiß der Benutzer, dass und warum weitergeleitet wurde? - [ ] Ist festgelegt, wer den Fortschritt überwacht? --- **Checkliste für die Kommunikation** - [ ] Ist die Sprache für die Zielgruppe verständlich? - [ ] Sind technische Fachbegriffe erklärt oder vermieden? - [ ] Ist die Aussage korrekt und freigegeben? - [ ] Wird klar, was bereits bekannt ist? - [ ] Wird klar, was noch untersucht wird? - [ ] Wird der nächste Schritt genannt? - [ ] Wird eine realistische nächste Statuszeit genannt? - [ ] Werden unbelegte Versprechen vermieden? - [ ] Sind Handlungshinweise eindeutig? - [ ] Werden vertrauliche Informationen geschützt? --- **Checkliste vor dem Abschluss** - [ ] Wurde die technische Funktion geprüft? - [ ] Wurde die Nutzbarkeit aus Benutzersicht geprüft? - [ ] Ist das gewünschte Outcome ausreichend erreicht? - [ ] Sind durchgeführte Maßnahmen dokumentiert? - [ ] Ist die Lösung verständlich beschrieben? - [ ] Wurde der Benutzer über den Abschluss informiert? - [ ] Sind Asset- oder Konfigurationsinformationen aktuell? - [ ] Muss ein Wissensartikel erstellt oder aktualisiert werden? - [ ] Besteht ein wiederkehrendes Muster? - [ ] Muss Problem Management einbezogen werden? - [ ] Besteht eine Verbesserungsmöglichkeit? - [ ] Sind offene Folgeaktivitäten eindeutig zugeordnet? --- **Checkliste für einen wirksamen Service Desk** - [ ] Besitzen Benutzer einen verständlichen Kontaktweg? - [ ] Werden alle angebotenen Kanäle zuverlässig überwacht? - [ ] Werden Kontakte in einer gemeinsamen Sicht zusammengeführt? - [ ] Sind Servicezeiten und Zuständigkeiten bekannt? - [ ] Sind Incident, Service Request und andere Kontaktarten unterscheidbar? - [ ] Sind Prioritätskriterien nachvollziehbar? - [ ] Sind funktionale und hierarchische Eskalationswege vorbereitet? - [ ] Sind wichtige Services und Benutzergruppen bekannt? - [ ] Ist Wissen aktuell und auffindbar? - [ ] Sind Lieferantenkontakte und Verträge zugänglich? - [ ] Sind Sicherheits- und Datenschutzverfahren bekannt? - [ ] Werden Benutzer verständlich und regelmäßig informiert? - [ ] Wird die Wiederherstellung aus Benutzersicht bestätigt? - [ ] Werden Kennzahlen gemeinsam und outcome-orientiert betrachtet? - [ ] Fließen Kontaktdaten und Feedback in Continual Improvement ein? --- **Schnellreferenz** | Frage | Bedeutung | |---|---| | Wer meldet? | Kontakt und betroffene Person bestimmen | | Was wird benötigt? | Service oder gewünschtes Outcome verstehen | | Was ist geschehen? | Symptom und Situation erfassen | | Wer ist betroffen? | Auswirkungen und Umfang bestimmen | | Wie dringend ist es? | organisatorische Prioritätskriterien anwenden | | Was wurde bereits geprüft? | doppelte Arbeit vermeiden | | Wer kann helfen? | geeignete Fähigkeiten und Practices einbinden | | Wer besitzt den Vorgang? | Ende-zu-Ende-Verantwortung klären | | Wann gibt es Neuigkeiten? | verlässliche Kommunikation sicherstellen | | Funktioniert es wieder? | technisches und benutzerbezogenes Ergebnis bestätigen | | Was lernen wir? | Wissen und Verbesserung ableiten | --- **Aufbau dieses Kapitels** Die folgenden Seiten vertiefen die operative Arbeit rund um den Service Desk: - 3.2 Kontaktkanäle und Erreichbarkeit - 3.3 Benutzerkommunikation und professioneller Umgang - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk --- **Zusammenfassende Darstellung** > Benutzer besitzt eine Frage, Anfrage oder Beeinträchtigung > ↓ > verständlicher Kontaktkanal > ↓ > Service Desk nimmt Kontakt auf > ↓ > Identität · Service · Symptom · Auswirkung · Dringlichkeit erfassen > ↓ > Anliegen fachlich einordnen > ↓ > bekannte Lösung anwenden oder geeignete Fähigkeiten einbinden > ↓ > Verantwortung und Kommunikation aufrechterhalten > ↓ > Ergebnis technisch und aus Benutzersicht prüfen > ↓ > Vorgang nachvollziehbar abschließen > ↓ > Wissen, Muster und Verbesserungsmöglichkeiten weiterverwenden --- **Verwandte Seiten** - 1.1 Warum professionelles Service Management notwendig ist - 1.4 Servicebeziehungen, Rollen und Serviceangebote - 2.3 Die sieben Guiding Principles - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 3.2 Kontaktkanäle und Erreichbarkeit - 3.3 Benutzerkommunikation und professioneller Umgang - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Knowledge Management - Problem Management - Monitoring and Event 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) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) - [PeopleCert: ITIL Service – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-service-version-5-4181) - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [PeopleCert: ITIL 4 Specialist – Monitor, Support and Fulfil](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-monitor-support-and-fulfil-batch-1-3682) - [ITIL: The ongoing relevance of the service desk in an AI world](https://www.itil.com/Itil-News-and-Announcements/service-desk-relevance-ai-world) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) **Offiziell bestätigter Stand** Die offiziellen ITIL-Quellen bestätigen: - Service Desk bleibt eine der 34 ITIL Management Practices. - Die Service-Desk-Practice ist mit Incident Management, Service Request Management, Problem Management sowie Monitoring and Event Management eng verbunden. - Der Service Desk ist häufig ein zentraler Knotenpunkt mehrerer Wertströme. - Er stellt einen wesentlichen Kommunikationsweg zwischen Service Provider und Benutzern bereit. - Technische Fähigkeiten, Kommunikationsfähigkeit, Empathie und Verständnis des Benutzerkontexts bleiben wesentlich. - KI und Automatisierung können wiederkehrende Aufgaben, Wissenssuche, Klassifizierung und einfache Unterstützung übernehmen. - Menschliche Kommunikation und Einordnung bleiben insbesondere bei komplexen und belastenden Situationen wichtig. - ITIL Version 5 führt die 34 Practices weiter und verbindet sie mit dem gemeinsamen Product and Service Lifecycle. **Versionshinweis** Die öffentlich zugängliche spezialisierte Zertifizierungs- und Practice-Seite trägt derzeit weiterhin die Bezeichnung **ITIL 4 Practitioner: Service Desk**. ITIL Version 5 führt die Management Practices grundsätzlich fort und entwickelt sie weiter. Vollständige aktuelle Practice Guidance wird über die offiziellen ITIL Practice Guides bereitgestellt. Diese Seite stellt deshalb keine nicht öffentlich belegten Detailänderungen einer zukünftigen oder nur zugangsbeschränkt verfügbaren Service-Desk-Practice-Guidance als gesichert dar. **Einordnung** Die ausführlichen: - Organisationsmodelle, - Kanalbeschreibungen, - Diagnosefragen, - Checklisten, - Ticketbeispiele, - Eskalationshinweise, - Kennzahlen, - und Praxisempfehlungen sind herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine für jede Organisation verbindlichen ITIL-Prozesse, Support-Level, Prioritätsmatrizen oder Organisationsstrukturen dar. Die konkrete Gestaltung des Service Desk muss an: - Benutzer, - Services, - Geschäftszeiten, - Risiken, - Sicherheitsanforderungen, - Fähigkeiten, - Lieferanten, - und verfügbare Ressourcen angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.2 Kontaktkanäle und Erreichbarkeit > **Kurz erklärt** > > Kontaktkanäle bestimmen, wie Benutzer den Service Desk erreichen können. > > Typische Kanäle sind: > > - Self-Service-Portal, > - Telefon, > - E-Mail, > - Chat, > - virtueller Agent, > - mobile Anwendung, > - persönlicher Vor-Ort-Kontakt, > - und besonders definierte Meldewege für Notfälle oder Sicherheitsereignisse. > > Erreichbarkeit beschreibt mehr als die technische Verfügbarkeit eines Kanals. > > Ein Kanal ist erst dann wirksam, wenn: > > - Benutzer ihn kennen, > - er für das jeweilige Anliegen geeignet ist, > - er zuverlässig überwacht wird, > - eine Bearbeitung innerhalb angemessener Zeiten erfolgt, > - Informationen nicht verloren gehen, > - und bei Bedarf ein Wechsel zu menschlicher Unterstützung möglich ist. > > ITIL schreibt keine universelle Anzahl von Kanälen und keinen grundsätzlich rund um die Uhr besetzten Service Desk vor. > > Die Organisation gestaltet Kanäle, Servicezeiten und Eskalationswege entsprechend ihren Benutzern, Services, Risiken und verfügbaren Fähigkeiten. --- **Warum die Gestaltung der Kontaktkanäle wichtig ist** Ein Service Desk kann fachlich gut organisiert sein und trotzdem schlecht erreichbar wirken. Beispiele: - Das Portal ist vorhanden, aber Benutzer finden das passende Formular nicht. - Die Support-E-Mail-Adresse wird nur unregelmäßig geprüft. - Der Chat zeigt „verfügbar“, obwohl kein Mitarbeiter angemeldet ist. - Eine Telefonnummer ist veröffentlicht, aber außerhalb der Servicezeit gibt es keine verständliche Ansage. - Ein virtueller Agent beantwortet Standardfragen, bietet jedoch keinen Übergang zu einem Menschen. - Benutzer melden kritische Störungen über einen Kanal, der erst am nächsten Arbeitstag bearbeitet wird. - Mehrere Kontaktkanäle erzeugen voneinander unabhängige Tickets für dasselbe Anliegen. - Eine Sicherheitsmeldung wird in einem allgemeinen Supportkanal mit ungeeigneten Zugriffsrechten erfasst. Die Wahl und Gestaltung der Kontaktkanäle beeinflusst damit: - Erfassungsqualität, - Bearbeitungsgeschwindigkeit, - Benutzeraufwand, - Informationssicherheit, - Barrierefreiheit, - Priorisierung, - Kommunikation, - Nachvollziehbarkeit, - und die gesamte Benutzererfahrung. > **Merke** > > Viele Kontaktkanäle bedeuten nicht automatisch gute Erreichbarkeit. > > Jeder angebotene Kanal muss zuverlässig betrieben, überwacht und in die gemeinsamen Wertströme eingebunden werden. --- **Kontaktkanal, Servicezeit und Reaktionszeit unterscheiden** | Begriff | Bedeutung | |---|---| | **Kontaktkanal** | Weg, über den ein Benutzer mit dem Service Provider in Verbindung tritt | | **technische Verfügbarkeit** | Zeitraum, in dem der Kanal technisch erreichbar ist | | **Servicezeit** | Zeitraum, in dem eine vereinbarte menschliche oder automatisierte Leistung angeboten wird | | **Supportzeit** | Zeitraum, in dem Unterstützung für einen bestimmten Service bereitsteht | | **Betriebszeit** | Zeitraum, in dem ein Produkt oder Service regulär genutzt werden soll | | **Bereitschaftszeit** | Zeitraum, in dem zuständige Personen außerhalb regulärer Zeiten bei bestimmten Ereignissen reagieren | | **erste Reaktionszeit** | Zeit bis zu einer ersten qualifizierten Rückmeldung | | **Bearbeitungszeit** | Zeit, in der aktiv an einem Anliegen gearbeitet wird | | **Lösungs- oder Erfüllungszeit** | Zeit bis zur ausreichenden Wiederherstellung oder Erfüllung | | **Statusintervall** | vereinbarter Abstand zwischen Statusinformationen | Diese Zeiten können unterschiedlich sein. Beispiel: - Ein Portal ist technisch 24 Stunden täglich erreichbar. - Neue Standardanfragen werden nur montags bis freitags bearbeitet. - Kritische Incidents können außerhalb dieser Zeit über eine Bereitschaftsnummer gemeldet werden. - Ein bestimmter Produktionsservice wird rund um die Uhr betrieben. - Nichtkritische Fragen zu diesem Service werden trotzdem nur während der normalen Service-Desk-Zeit beantwortet. > **Wichtig** > > Ein technisch rund um die Uhr erreichbares Formular bedeutet nicht automatisch einen rund um die Uhr verfügbaren menschlichen Support. --- **Die Kanalstrategie am Benutzerbedarf ausrichten** Vor der Einführung oder Änderung von Kontaktkanälen sollte die Organisation untersuchen: - Welche Benutzergruppen werden unterstützt? - Wo und wann arbeiten diese Benutzer? - Welche Geräte stehen ihnen zur Verfügung? - Welche Sprachen werden benötigt? - Welche technischen Fähigkeiten können vorausgesetzt werden? - Welche Services sind besonders kritisch? - Welche Anliegen treten häufig auf? - Welche Situationen benötigen sofortige menschliche Kommunikation? - Welche Anliegen lassen sich sicher standardisieren? - Welche gesetzlichen, vertraglichen oder betrieblichen Anforderungen gelten? - Welche Barrieren können Benutzer vom Kontakt abhalten? - Welche Kanäle können zuverlässig betrieben werden? Unterschiedliche Benutzergruppen können unterschiedliche Anforderungen besitzen. Beispiele: | Benutzergruppe | Mögliche Anforderungen | |---|---| | Büroarbeitsplätze | Portal, E-Mail, Chat und Telefon | | Produktionsmitarbeiter | leicht erreichbare Telefonnummer oder lokaler Kontakt | | Außendienst | mobile Erreichbarkeit und Self-Service | | Schichtbetrieb | erweiterte Support- oder Bereitschaftszeiten | | externe Kunden | klar getrenntes Kundenportal und vertraglich definierte Kanäle | | Führungskräfte | dieselben Prioritätsregeln, aber möglicherweise besondere Kommunikationsanforderungen | | Benutzer mit Einschränkungen | barrierearme Kanäle und alternative Kontaktmöglichkeiten | | internationale Benutzer | unterschiedliche Zeitzonen und Sprachen | | Administratoren | technischer Eskalations- und Sicherheitskanal | > **Grundsatz** > > Der bevorzugte Kanal der IT ist nicht automatisch der geeignete Kanal für alle Benutzer. --- **Single Point of Contact und mehrere Kanäle** Der Service Desk wird häufig als zentraler oder einzelner Kontaktpunkt beschrieben. Das bedeutet nicht zwingend, dass nur ein einziger Kanal erlaubt ist. Mehrere Kanäle können gemeinsam einen zentralen Kontaktpunkt bilden, wenn sie: - eindeutig zum selben Service Desk führen, - gemeinsame Informationen verwenden, - Kontakte nachvollziehbar zusammenführen, - einheitliche Prioritäts- und Eskalationsregeln anwenden, - und konsistente Statusinformationen liefern. Beispiel: Ein Benutzer kann den Service Desk erreichen über: - Portal, - Telefon, - E-Mail, - oder Chat. Alle Kontakte werden jedoch: - im selben Vorgangssystem dokumentiert, - auf mögliche Duplikate geprüft, - nach denselben Kriterien eingeordnet, - und mit einer gemeinsamen Statussicht bearbeitet. Problematisch wäre dagegen: - Portal-Tickets werden vom Service Desk bearbeitet. - E-Mails landen bei einzelnen Administratoren. - Chatkontakte werden nicht dokumentiert. - Telefonmeldungen befinden sich in privaten Notizen. - Vor-Ort-Anfragen werden gar nicht erfasst. > **Merke** > > Ein zentraler Kontaktpunkt ist eine organisatorische Fähigkeit und nicht nur eine einzelne Telefonnummer oder E-Mail-Adresse. --- **Mehrkanal und kanalübergreifende Bearbeitung** Eine Organisation kann mehrere Kanäle anbieten. Dabei sollte unterschieden werden zwischen: | Ansatz | Bedeutung | |---|---| | **Mehrkanalbetrieb** | mehrere Kanäle existieren nebeneinander | | **kanalübergreifende Bearbeitung** | Informationen und Bearbeitungsstand bleiben beim Kanalwechsel erhalten | | **einheitliche Serviceerfahrung** | Regeln, Sprache und Statusinformationen sind über die Kanäle hinweg abgestimmt | Beispiel einer schlechten kanalübergreifenden Erfahrung: 1. Benutzer meldet eine Störung per Chat. 2. Der Chat verweist auf eine Telefonnummer. 3. Am Telefon muss der Benutzer alles erneut erklären. 4. Später erhält er eine E-Mail mit einer neuen Ticketnummer. 5. Im Portal ist keiner der bisherigen Schritte sichtbar. Bessere Gestaltung: 1. Chat erfasst die ersten Informationen. 2. Ein Vorgang wird erstellt. 3. Beim Wechsel zum Telefon sieht der Mitarbeiter den bisherigen Verlauf. 4. Der Benutzer nennt nur noch die Vorgangsnummer oder wird sicher identifiziert. 5. Status und Ergebnis bleiben im Portal sichtbar. Die konkrete technische Umsetzung hängt von den verwendeten Werkzeugen ab. --- **Kanalwahl nach Art des Anliegens** Nicht jeder Kanal ist für jedes Anliegen gleich geeignet. | Anliegen | Häufig geeignete Kanäle | |---|---| | standardisierte Softwareanforderung | Self-Service-Portal | | planbarer Berechtigungsantrag | Portal mit strukturiertem Formular | | allgemeine Frage | Portal, Knowledge-Base, Chat oder E-Mail | | komplexe Störung mit Rückfragen | Telefon, Chat oder persönlicher Kontakt | | kritischer Serviceausfall | definierter dringender Meldeweg | | möglicher Sicherheitsvorfall | besonderer Sicherheitsmeldeweg | | Kennwort vergessen | sicherer Self-Service oder verifizierter Supportkontakt | | Statusabfrage | Portal oder automatische Benachrichtigung | | Feedback oder Beschwerde | Portal, Umfrage, E-Mail oder persönlicher Kontakt | | Ausfall des normalen Portals | alternativer Kontaktweg | Die Organisation sollte deutlich kommunizieren: - welche Kanäle existieren, - wofür sie gedacht sind, - wann sie bearbeitet werden, - und welcher Kanal bei dringenden Situationen verwendet werden muss. --- **Das Self-Service-Portal** Ein Self-Service-Portal kann Benutzer dabei unterstützen: - Incidents zu melden, - Service Requests auszuwählen, - Wissen zu durchsuchen, - Statusinformationen einzusehen, - Genehmigungen abzugeben, - Rückfragen zu beantworten, - und standardisierte Leistungen selbst auszuführen. Mögliche Vorteile: - strukturiertere Informationen, - rund um die Uhr mögliche Erfassung, - transparente Statussicht, - weniger Medienbrüche, - automatische Weiterleitung, - und Unterstützung standardisierter Wertströme. Mögliche Nachteile bei schlechter Gestaltung: - unverständliche Kategorien, - zu viele Formulare, - lange Pflichtfeldlisten, - technische Begriffe, - schlechte Suchfunktion, - fehlende mobile Nutzbarkeit, - kein erkennbarer Kontakt zu einem Menschen, - und hohe Abbruchquoten. > **Merke** > > Ein Portal ist kein Selbstzweck. > > Es muss den Benutzeraufwand reduzieren und die Bearbeitung verbessern. --- **Ein verständliches Portal gestalten** Ein Benutzer sollte möglichst nicht wissen müssen: - welches technische Team zuständig ist, - welche Datenbank betroffen sein könnte, - welche Practice verwendet wird, - oder welche interne Komponentenkategorie ausgewählt werden muss. Ungeeignete Auswahl: - Active Directory - Entra ID - LDAP - SAML - OIDC - RADIUS - PKI Verständlichere Auswahl: - Ich kann mich nicht anmelden. - Mein Konto ist gesperrt. - Die Mehrfaktor-Anmeldung funktioniert nicht. - Ich benötige einen neuen Zugriff. - Ich möchte ein Kennwort ändern. - Ich vermute einen unberechtigten Zugriff. Die technische Zuordnung kann anschließend: - durch Regeln, - durch den Service Desk, - oder durch geeignete Automatisierung erfolgen. --- **Formulare zweckmäßig gestalten** Ein Portalformular sollte nur Informationen verlangen, die für: - Einordnung, - Entscheidung, - Bearbeitung, - Kontrolle, - oder spätere Auswertung benötigt werden. Mögliche Gestaltungsmittel: - einfache Sprache, - kurze Hilfetexte, - Beispiele, - dynamisch eingeblendete Felder, - sinnvolle Standardwerte, - automatische Übernahme bekannter Benutzerdaten, - Auswahl verständlicher Services, - und sichtbare Angabe der erwarteten Bearbeitungszeit. Ungeeignete Pflichtfelder: - interne Supportgruppe, - vermutete technische Ursache, - interne CI-Kennung, - oder eine Priorität, deren Kriterien der Benutzer nicht kennt. Besser: - betroffener Service, - beobachtetes Symptom, - betroffene Personen oder Standorte, - benötigter Zeitpunkt, - und mögliche Auswirkungen. --- **Portal und Barrierefreiheit** Ein Portal sollte von möglichst vielen Benutzern selbstständig verwendet werden können. Zu berücksichtigen sind beispielsweise: - Tastaturbedienbarkeit, - verständliche Beschriftungen, - ausreichende Kontraste, - skalierbare Darstellung, - kompatible Formulare, - verständliche Fehlermeldungen, - keine ausschließliche Informationsvermittlung über Farbe, - alternative Texte für relevante grafische Inhalte, - und alternative Kontaktmöglichkeiten. Die konkreten verbindlichen Anforderungen hängen von Organisation, Land, Branche und Zielgruppe ab. > **Wichtig** > > Wenn ein Portal für einen Benutzer nicht nutzbar ist, muss ein angemessener alternativer Kontaktweg bestehen. --- **Telefonischer Kontakt** Telefon eignet sich besonders für: - dringende Situationen, - komplexe Fehlerbilder, - emotional belastende Incidents, - Rückfragen in Echtzeit, - und Benutzer, die keinen Zugang zum Portal besitzen. Mögliche Vorteile: - unmittelbare Interaktion, - schnelle Klärung, - bessere Wahrnehmung von Unsicherheit oder Dringlichkeit, - und direkte Anleitung. Mögliche Herausforderungen: - Wartezeiten, - eingeschränkte Nachvollziehbarkeit ohne Dokumentation, - Missverständnisse, - Sprachprobleme, - hoher Personalbedarf, - und fehlende Übertragung technischer Details. Der Service Desk sollte deshalb sicherstellen: - verständliche Begrüßung, - notwendige Identitätsprüfung, - strukturierte Erfassung, - Dokumentation während oder unmittelbar nach dem Gespräch, - realistische Statusaussagen, - und eindeutige nächste Schritte. --- **Telefonmenü und Warteschlange** Ein Telefonmenü kann Kontakte vorsortieren. Es sollte jedoch: - möglichst kurz, - verständlich, - aktuell, - und auf tatsächlich unterschiedliche Bearbeitungswege beschränkt sein. Ungeeignet: > Drücken Sie 1 für Incident Management, 2 für Service Request Management, 3 für Configuration Management. Benutzer kennen diese internen Begriffe möglicherweise nicht. Verständlicher: > Drücken Sie 1 bei einer aktuellen technischen Störung. > Drücken Sie 2 für eine Bestellung oder Zugriffsanfrage. > Drücken Sie 3 bei einer verdächtigen E-Mail oder einem möglichen Sicherheitsvorfall. Bei Warteschlangen können hilfreich sein: - ungefähre Warteinformation, - Rückrufmöglichkeit, - Hinweis auf geeigneten Self-Service, - und verständliche Ansage für dringende Notfälle. --- **E-Mail als Kontaktkanal** E-Mail ist leicht zugänglich und eignet sich unter anderem für: - weniger dringende Anliegen, - schriftliche Rückfragen, - Übermittlung strukturierter Informationen, - und Kommunikation mit externen Partnern. Mögliche Nachteile: - unvollständige Angaben, - uneindeutige Betreffzeilen, - lange E-Mail-Verläufe, - unkontrollierte Anhänge, - fehlende Prioritätsinformationen, - Duplikate, - und Sicherheitsrisiken. Eine Support-E-Mail-Adresse sollte möglichst: - automatisch eine Eingangsbestätigung senden, - eine Vorgangsnummer erzeugen, - keine privaten Postfächer verwenden, - regelmäßig überwacht werden, - und klare Hinweise zu Servicezeiten enthalten. > **Sicherheitsrelevant** > > E-Mail ist nicht für jede vertrauliche Information oder jeden Sicherheitsvorfall geeignet. > > Die Organisation muss zulässige Inhalte und alternative sichere Übertragungswege festlegen. --- **Gute Betreffzeilen und E-Mail-Inhalte** Ungeeigneter Betreff: > Hilfe!!! Besser: > Anmeldung am Zeiterfassungssystem nicht möglich – Standort Mitte Hilfreiche Angaben: - betroffener Benutzer, - betroffener Service, - beobachtetes Verhalten, - Fehlermeldung, - Beginn, - Auswirkung, - bereits durchgeführte Schritte, - und sichere Kontaktmöglichkeit. Der Service Desk sollte Benutzer nicht mit langen technischen Vorlagen überfordern. Kurze Hinweise oder automatische Fragen können die Qualität verbessern. --- **Chat und Instant Messaging** Chat eignet sich für: - kurze Rückfragen, - schnelle Orientierung, - begleitete Diagnose, - und weniger formelle Kommunikation. Mögliche Vorteile: - direkte schriftliche Kommunikation, - Übertragung kurzer technischer Informationen, - geringer Wechsel zwischen Arbeit und Support, - und parallele Bearbeitung mehrerer Kontakte. Mögliche Risiken: - unvollständige Dokumentation, - private Chats außerhalb des Supportsystems, - Erwartung sofortiger Antwort, - Übermittlung sensibler Inhalte, - und Verlust des Verlaufs. Geeignete Regeln: - offizieller Service-Desk-Chat statt privater Direktnachrichten, - Übernahme relevanter Informationen in den Vorgang, - klare Anzeige der Servicezeit, - sichere Identitätsprüfung bei kritischen Aktionen, - und Möglichkeit zur Eskalation an einen Menschen oder einen anderen Kanal. --- **Privatnachrichten an Administratoren** Direkte Nachrichten an bekannte Administratoren wirken für Benutzer häufig schnell. Sie erzeugen jedoch mögliche Probleme: - keine zentrale Übersicht, - unklare Priorisierung, - fehlende Vertretung, - Unterbrechung konzentrierter Arbeit, - keine dokumentierte Kommunikation, - und Abhängigkeit von einzelnen Personen. Eine professionelle Reaktion kann lauten: > Ich unterstütze gern. Bitte sende die Meldung über den Service-Desk-Kanal oder erlaube mir, daraus einen Vorgang zu erstellen. Dadurch bleibt die Bearbeitung auch bei meiner Abwesenheit nachvollziehbar. Bei kritischen Situationen sollte die Meldung nicht nur zurückgewiesen werden. Der Mitarbeiter sollte sicherstellen, dass: - der Vorgang erfasst, - richtig eskaliert, - und nicht durch die formale Kanalregel verzögert wird. --- **Virtuelle Agenten und Chatbots** Ein virtueller Agent kann Benutzer unterstützen bei: - häufigen Fragen, - Statusabfragen, - Auswahl eines Serviceangebots, - Erfassung strukturierter Angaben, - sicheren standardisierten Selbsthilfeschritten, - und Weiterleitung an einen Menschen. Mögliche Vorteile: - unmittelbare Unterstützung, - hohe Skalierbarkeit, - längere Erreichbarkeit, - und Entlastung bei wiederkehrenden Anliegen. Mögliche Risiken: - falsche Interpretation, - unpassende Antworten, - Schleifen ohne Lösung, - fehlende Transparenz, - unzureichende Barrierefreiheit, - und fehlender menschlicher Eskalationsweg. > **Grundsatz** > > Ein virtueller Agent sollte nicht vorgeben, ein Mensch zu sein. > > Benutzer sollten erkennen können, dass sie mit einem automatisierten System interagieren. --- **Menschliche Übergabe bei virtuellen Agenten** Ein Übergang zu einem Mitarbeiter sollte insbesondere möglich sein, wenn: - die Anfrage nicht verstanden wird, - mehrere Lösungsversuche scheitern, - die Situation kritisch ist, - Sicherheits- oder Datenschutzbezug besteht, - der Benutzer ausdrücklich menschliche Unterstützung benötigt, - oder der virtuelle Agent keine ausreichende Befugnis besitzt. Bei der Übergabe sollten bereits erfasste Informationen erhalten bleiben. Ungeeignet: 1. Benutzer beantwortet zehn Fragen im Chatbot. 2. Der Chatbot bietet eine Telefonnummer an. 3. Der Mitarbeiter sieht keine bisherigen Angaben. 4. Der Benutzer beginnt erneut. Besser: 1. Virtueller Agent erfasst grundlegende Angaben. 2. Ein Vorgang wird erzeugt. 3. Der Mitarbeiter erhält Verlauf und bisherige Ergebnisse. 4. Der Benutzer wird über die Übergabe informiert. --- **Mobile Anwendungen** Eine mobile Supportanwendung kann hilfreich sein für: - Außendienst, - mobile Mitarbeiter, - Produktionsumgebungen, - Push-Benachrichtigungen, - Statusabfragen, - und Erfassung von Fotos oder Gerätecodes. Zu berücksichtigen sind: - Authentifizierung, - Geräteverwaltung, - Datenschutz, - sichere Speicherung, - Offline-Verhalten, - Bedienbarkeit, - und Möglichkeit eines alternativen Kontaktwegs. Fotos und Anhänge sollten nur erfasst werden, wenn sie notwendig sind. Dabei können versehentlich sichtbar werden: - personenbezogene Daten, - Bildschirminhalte, - Zugangsinformationen, - Produktionsinformationen, - oder vertrauliche Dokumente. --- **Persönlicher Vor-Ort-Kontakt** Ein persönlicher Kontakt kann sinnvoll sein bei: - Hardwareproblemen, - komplexen Benutzerfragen, - Einarbeitung, - Arbeitsplätzen ohne digitalen Zugang, - und Situationen, in denen Beobachtung des tatsächlichen Arbeitsumfelds wichtig ist. Mögliche Modelle: - Walk-up Desk, - lokale Supportzeiten, - IT-Sprechstunde, - Terminvereinbarung, - oder gezielter Vor-Ort-Einsatz. Auch ein persönlicher Kontakt sollte nachvollziehbar dokumentiert werden, wenn: - eine Bearbeitung, - ein Asset-Wechsel, - eine Sicherheitsentscheidung, - ein Incident, - oder eine weitere Maßnahme entsteht. > **Typischer Fehler** > > Vor-Ort-Hilfe wird vollständig außerhalb des Service-Management-Systems durchgeführt. > > Dadurch bleiben Aufwand, wiederkehrende Probleme und wichtige Änderungen unsichtbar. --- **Walk-up Desk** Ein Walk-up Desk ist ein physischer Kontaktpunkt, an dem Benutzer persönlich Unterstützung erhalten. Mögliche Vorteile: - unmittelbare menschliche Hilfe, - gute Unterstützung bei Geräten, - geringe Hürde, - und bessere Wahrnehmung des Benutzerkontexts. Mögliche Herausforderungen: - Warteschlangen, - Unterbrechungen, - unklare Priorisierung, - nicht dokumentierte Tätigkeiten, - und Benutzer aus anderen Standorten werden benachteiligt. Zu klären sind: - Öffnungszeiten, - geeignete Anliegen, - Termin- oder Warteschlangenmodell, - Identitätsprüfung, - Umgang mit Geräten, - Dokumentation, - und Eskalation. --- **Automatisch erzeugte Kontakte** Nicht jeder Kontakt wird durch einen Menschen ausgelöst. Mögliche technische Quellen: - Monitoring, - Event-Management-System, - Endgeräteverwaltung, - Sicherheitsplattform, - Backup-System, - Cloud-Provider, - oder Integrationsschnittstelle. Solche Meldungen können automatisch: - ein Ticket, - ein Event, - einen Incident, - oder eine andere Arbeitsaufgabe erzeugen. Dabei muss geklärt sein: - Welche technische Meldung benötigt tatsächlich eine Handlung? - Wird bereits ein Vorgang bearbeitet? - Welche Priorität ist angemessen? - Wer besitzt die Verantwortung? - Wie werden Duplikate verhindert? - Wann müssen Benutzer informiert werden? > **Merke** > > Eine automatische Meldung ist nicht automatisch ein Incident. > > Sie muss entsprechend ihrer Bedeutung und Auswirkung eingeordnet werden. --- **Besondere Meldewege für Sicherheitsereignisse** Mögliche Sicherheitsereignisse benötigen häufig einen besonders definierten Meldeweg. Beispiele: - verdächtige E-Mail, - verlorenes Gerät, - möglicher unberechtigter Zugriff, - Schadsoftware, - versehentliche Datenoffenlegung, - oder verdächtiger Anruf. Der Meldeweg sollte: - leicht auffindbar, - schnell erreichbar, - sicher, - und den Benutzern bekannt sein. Zusätzlich ist festzulegen: - welche Informationen erfasst werden, - wer Zugriff auf die Meldung erhält, - wann das Sicherheitsteam eingebunden wird, - welche Kommunikation verwendet werden darf, - und wie Beweise geschützt werden. Ungeeignet wäre ein verstecktes Formular mit vielen technischen Pflichtfeldern. --- **Notfall- und Major-Incident-Kanäle** Für besonders kritische Incidents kann ein eigener dringender Meldeweg sinnvoll sein. Dieser darf nicht zur allgemeinen Beschleunigung normaler Anliegen missbraucht werden. Mögliche Regeln: - Welche Kriterien rechtfertigen den Kanal? - Wer darf ihn verwenden? - Welche Services sind umfasst? - Welche Informationen müssen genannt werden? - Wer nimmt die Meldung entgegen? - Wie wird der Major-Incident-Prozess aktiviert? - Wie wird die Kommunikation koordiniert? - Was geschieht bei Fehlalarm? Beispiel: Ein Portalhinweis kann lauten: > Bei vollständigem Ausfall eines kritischen Produktionsservice außerhalb der Service-Desk-Zeit verwenden Sie die Bereitschaftsnummer. Normale Bestellungen und Einzelplatzprobleme werden am nächsten Arbeitstag bearbeitet. --- **Alternative Kanäle bei Ausfall des Service Desk** Der normale Kontaktweg kann selbst ausfallen. Beispiele: - Ticketsystem nicht erreichbar, - E-Mail-Service gestört, - Telefonanlage ausgefallen, - Identitätsdienst verhindert Portalzugriff, - oder Standortverbindung unterbrochen. Deshalb sollte ein alternativer Meldeweg vorbereitet sein. Mögliche Alternativen: - externe Statusseite, - separate Notfallnummer, - unabhängige Mobilfunknummer, - alternativer Kommunikationsdienst, - definierter lokaler Ansprechpartner, - oder Providerkontakt. Der alternative Kanal sollte nicht von derselben ausgefallenen Komponente abhängen. > **Praxistipp** > > Die Notfallkontaktinformationen sollten auch verfügbar sein, wenn das interne Netzwerk, das Portal oder das Identitätssystem nicht funktioniert. --- **Statusseite** Eine Statusseite kann Benutzer über bekannte Störungen, Wartungen und Wiederherstellungen informieren. Mögliche Inhalte: - betroffener Service, - Beginn, - bekannte Auswirkung, - aktueller Status, - Zwischenlösung, - nächstes Update, - und Abschlussinformation. Vorteile: - weniger Mehrfachmeldungen, - konsistente Kommunikation, - geringerer Benutzeraufwand, - und Entlastung des Service Desk. Zu berücksichtigen sind: - Zielgruppe, - Zugriffsrechte, - vertrauliche Informationen, - Verantwortlichkeit für Aktualisierungen, - und technische Unabhängigkeit von betroffenen Services. Eine externe Statusseite darf keine sicherheitskritischen internen Details offenlegen. --- **Servicezeiten bestimmen** Servicezeiten sollten sich an den benötigten Outcomes und Risiken orientieren. Zu untersuchen sind: - Betriebszeiten wichtiger Services, - Arbeitszeiten der Benutzer, - internationale Zeitzonen, - Schichtbetrieb, - vertragliche Vereinbarungen, - saisonale Spitzen, - Sicherheitsanforderungen, - und verfügbare Bereitschaft. Mögliche Modelle: - normale Geschäftszeiten, - erweiterte Servicezeiten, - 24×5, - 24×7, - Bereitschaft für kritische Services, - oder unterschiedliche Zeiten nach Serviceklasse. > **Wichtig** > > Eine längere Servicezeit benötigt nicht nur einen zusätzlichen Telefonanschluss. > > Sie benötigt Personal, Wissen, Befugnisse, Werkzeuge, Eskalationswege und erreichbare Lieferanten. --- **Erreichbarkeit außerhalb der Servicezeit** Außerhalb der regulären Servicezeit sollte klar sein: - Welche Anliegen werden bearbeitet? - Welcher Kanal gilt? - Wer reagiert? - Welche Zielzeiten gelten? - Welche Befugnisse besitzt die Bereitschaft? - Welche Fachteams können erreicht werden? - Welche Lieferanten stehen zur Verfügung? - Wie erfolgt die Übergabe an den regulären Service Desk? Mögliche Ansage: > Der reguläre Service Desk ist derzeit geschlossen. Kritische Ausfälle der Produktionsservices können über die Bereitschaftsnummer gemeldet werden. Alle anderen Anliegen können im Portal erfasst werden und werden ab 08:00 Uhr bearbeitet. --- **Bereitschaft und Rufbereitschaft** Eine Bereitschaftsregelung sollte mindestens klären: - betroffene Services, - Aktivierungsbedingungen, - erreichbare Rollen, - Reaktionspflichten, - Entscheidungsbefugnisse, - technische Zugänge, - Dokumentation, - Vertretung, - und Übergabe. Problematisch sind informelle Regelungen wie: > Rufen Sie einfach jemanden aus der IT an. Dies führt zu: - unklarer Verantwortung, - persönlicher Überlastung, - fehlender Vertretung, - und nicht nachvollziehbaren Entscheidungen. --- **Follow-the-Sun** Bei internationalem Betrieb können Teams in verschiedenen Zeitzonen nacheinander übernehmen. Voraussetzungen: - einheitliche Dokumentation, - gemeinsame Werkzeuge, - klare Ownership-Regeln, - definierte Übergaben, - ausreichende Sprachkenntnisse, - gleiche Zugriffsmöglichkeiten, - und abgestimmte Prioritätskriterien. Eine Übergabe sollte enthalten: - aktueller Status, - bisherige Maßnahmen, - offene Hypothesen, - nächste Schritte, - Risiken, - erwartete Entscheidungen, - und geplante Kommunikation. > **Typischer Fehler** > > Der Vorgang wird am Schichtende nur einer anderen Gruppe zugewiesen, ohne dass Kontext und Verantwortung geklärt sind. --- **Sprachliche Erreichbarkeit** Bei mehrsprachigen Benutzergruppen ist zu klären: - Welche Sprachen werden direkt unterstützt? - Welche Servicezeiten gelten je Sprache? - Können Übersetzungswerkzeuge verwendet werden? - Wie werden technische Begriffe einheitlich übersetzt? - Wie werden Missverständnisse erkannt? - Welche Sprache gilt für Dokumentation und Lieferanteneskalation? Automatische Übersetzung kann unterstützen. Kritische Informationen sollten jedoch überprüft werden, insbesondere bei: - Sicherheitsvorfällen, - rechtlichen Aussagen, - technischen Anweisungen, - und möglichen Datenverlusten. --- **Erreichbarkeit für externe Benutzer** Externe Kunden, Partner oder Lieferanten benötigen möglicherweise andere Kanäle als interne Mitarbeiter. Zu berücksichtigen sind: - Authentifizierung, - Vertragsbezug, - Mandantentrennung, - Datenschutz, - zulässige Informationen, - Servicezeiten, - Eskalation, - und unterschiedliche Serviceziele. Ein externer Benutzer sollte nicht auf interne Portale oder Kommunikationskanäle zugreifen müssen, für die er keine Berechtigung besitzt. --- **Identitätsprüfung je Kanal** Nicht jede Anfrage benötigt dieselbe Identitätsprüfung. Der Umfang sollte sich nach Risiko und verlangter Handlung richten. Beispiele: | Handlung | Mögliche Anforderung | |---|---| | allgemeine Serviceinformation | möglicherweise keine besondere Prüfung | | Status eines eigenen Tickets | sichere Anmeldung oder Vorgangsprüfung | | Kennwort zurücksetzen | festgelegtes starkes Identitätsverfahren | | Berechtigung ändern | Identitäts- und Genehmigungsprüfung | | vertrauliche Daten übermitteln | geschützter Kanal | | administrativen Zugriff aktivieren | besonders starke Prüfung und Autorisierung | > **Sicherheitsrelevant** > > Telefonnummer, Absenderadresse oder angezeigter Name allein beweisen nicht zuverlässig die Identität einer Person. --- **Social Engineering berücksichtigen** Kontaktkanäle können durch Angreifer ausgenutzt werden. Typische Warnzeichen: - außergewöhnlicher Zeitdruck, - Berufung auf hohe Hierarchie, - Bitte um Umgehung des üblichen Verfahrens, - Zurücksetzung eines fremden Kontos, - Änderung von Kontaktdaten vor einer Sicherheitsaktion, - Übermittlung unbekannter Links oder Dateien, - oder Forderung nach vertraulichen Informationen. Mitarbeiter benötigen: - klare Verfahren, - Schulung, - Eskalationsmöglichkeiten, - und Unterstützung durch Führungskräfte. > **Grundsatz** > > Gute Erreichbarkeit darf nicht auf Kosten von Identitätsprüfung und Informationssicherheit entstehen. --- **Kapazitätsplanung für Kontaktkanäle** Ein Kanal ist nur dann zuverlässig, wenn ausreichende Kapazität vorhanden ist. Zu berücksichtigen sind: - Anzahl der Kontakte, - zeitliche Verteilung, - durchschnittliche Bearbeitungsdauer, - saisonale Spitzen, - Ausfälle größerer Services, - Personalverfügbarkeit, - Sprachen, - und Komplexität der Anliegen. Beispiele für Spitzen: - Montagmorgen, - Beginn einer Schicht, - nach einem großen Release, - nach Kennwortänderungen, - bei neuen Mitarbeitereintrittsterminen, - oder während eines Major Incidents. Mögliche Maßnahmen: - Rückrufoption, - zusätzliche Besetzung, - sichtbare Statusmeldung, - vorbereitete Störungsansage, - Self-Service für geeignete Anliegen, - und automatische Zusammenführung von Mehrfachmeldungen. --- **Warteschlangen steuern** Eine Warteschlange sollte nicht nur die Reihenfolge nach Eingangszeit berücksichtigen. Abhängig vom Kanal können relevant sein: - Priorität, - Auswirkungen, - Sicherheitsbezug, - Serviceklasse, - bereits verstrichene Zeit, - Sprachbedarf, - und benötigte Fähigkeiten. Benutzer sollten möglichst erkennen können: - dass ihre Meldung eingegangen ist, - ob weitere Informationen benötigt werden, - wie der nächste Schritt aussieht, - und wann ungefähr eine Reaktion erfolgt. --- **Überlauf und Ausweichregelungen** Bei ungewöhnlich hoher Nachfrage können Ausweichregeln notwendig sein. Beispiele: - zusätzliche interne Mitarbeiter unterstützen vorübergehend, - nichtkritische Kontakte werden zurückgerufen, - bekannte Störung wird zentral kommuniziert, - Lieferanten übernehmen vereinbarte Teile, - oder automatisierte Statusinformationen reduzieren Nachfragen. Zu vermeiden ist: - spontane Weitergabe ohne Zugriffsrechte, - Einsatz ungeschulter Personen bei sicherheitskritischen Anliegen, - und Verlust der Dokumentation. --- **Kontaktkanäle und Service Levels** Serviceziele können je Kanal und Anliegen unterschiedlich sein. Beispiele: - Telefon: kurze Annahmezeit für kritische Incidents - Portal: Eingangsbestätigung unmittelbar - E-Mail: qualifizierte Reaktion innerhalb der Servicezeit - Chat: Reaktion nur während angezeigter Verfügbarkeit - Bereitschaft: definierte Reaktion bei kritischen Services Die Ziele sollten: - verständlich, - messbar, - realistisch, - und mit ausreichenden Ressourcen unterstützt sein. Eine sehr kurze Reaktionszeit besitzt wenig Wert, wenn die erste Antwort nur lautet: > Ihr Ticket wurde erhalten. Zusätzlich sollte geprüft werden, wann: - eine qualifizierte Bearbeitung, - eine sinnvolle Statusinformation, - oder eine Wiederherstellung erfolgt. --- **Erreichbarkeit messen** Mögliche Kennzahlen: | Kennzahl | Mögliche Aussage | |---|---| | Erreichbarkeitsquote Telefon | Anteil angenommener Anrufe | | durchschnittliche Wartezeit | Zeit bis zur Annahme | | Abbruchquote | Anteil beendeter Kontakte vor Annahme | | Rückrufzeit | Zeit bis zum zugesagten Rückruf | | erste qualifizierte Reaktionszeit | Zeit bis zu einer verwertbaren Antwort | | Portal-Abbruchquote | Anteil nicht abgeschlossener Formulare | | Chat-Übertragungsquote | Anteil der Kontakte mit menschlicher Übergabe | | Kanalwechselquote | Anteil der Fälle, die einen weiteren Kanal benötigen | | Wiederholungskontakte | erneute Meldung zum selben Anliegen | | Self-Service-Erfolgsquote | erfolgreich ohne Service-Desk-Kontakt erledigte geeignete Anliegen | | Kontakte außerhalb Servicezeit | Hinweise auf unpassende Servicezeiten | | falsch gewählter Kanal | Hinweise auf unklare Kommunikation | | Benutzeraufwand | Anzahl notwendiger Kontakte oder Wiederholungen | Keine einzelne Kennzahl beschreibt die tatsächliche Erreichbarkeit vollständig. --- **Abbruchquote richtig einordnen** Eine hohe Abbruchquote kann entstehen durch: - lange Wartezeit, - technische Probleme, - unverständliches Telefonmenü, - Benutzer findet inzwischen eine Lösung, - oder parallele Nutzung eines anderen Kanals. Eine niedrige Abbruchquote beweist nicht automatisch gute Erreichbarkeit. Möglicherweise: - werden Anrufe schnell angenommen, aber schlecht bearbeitet, - Benutzer verwenden den Kanal gar nicht mehr, - oder kritische Gruppen können ihn nicht nutzen. Kennzahlen müssen deshalb gemeinsam mit: - Benutzerfeedback, - Lösungsqualität, - Kontaktvolumen, - und tatsächlichen Outcomes betrachtet werden. --- **First Contact Resolution nach Kanal** First Contact Resolution kann je Kanal unterschiedlich bewertet werden. Beispiele: - Chatbot beantwortet eine Statusfrage vollständig. - Portal führt einen sicheren Kennwort-Reset aus. - Telefonischer Mitarbeiter löst eine bekannte Störung. - E-Mail liefert eine verständliche und erfolgreiche Anleitung. Dabei muss geprüft werden: - War das Anliegen tatsächlich gelöst? - Wurde das Ergebnis bestätigt? - Musste der Benutzer einen weiteren Kanal verwenden? - Wurden Sicherheitsregeln eingehalten? - Wurde nur das Ticket geschlossen oder das Outcome erreicht? --- **Self-Service-Erfolg richtig messen** Unzureichende Kennzahl: > Anzahl der Portalaufrufe Hilfreichere Fragen: - Finden Benutzer das passende Angebot? - Werden Formulare vollständig abgeschlossen? - Wird das Anliegen ohne weiteren Kontakt erledigt? - Sind die Ergebnisse korrekt? - Wie häufig wechseln Benutzer zum Telefon? - Welche Suchbegriffe liefern keine Ergebnisse? - Wo brechen Benutzer ab? - Welche Fehler verursachen neue Tickets? > **Merke** > > Ein Benutzer, der nach mehreren erfolglosen Self-Service-Versuchen anruft, hat mehr und nicht weniger Aufwand erlebt. --- **Kanalqualität regelmäßig überprüfen** Kontaktkanäle verändern sich durch: - neue Benutzergruppen, - neue Technologien, - veränderte Arbeitszeiten, - steigende Kontaktmengen, - neue Sicherheitsrisiken, - und Feedback. Regelmäßig zu prüfen sind: - Werden alle Kanäle noch benötigt? - Sind Servicezeiten passend? - Sind Inhalte und Ansagen aktuell? - Werden Kontakte zuverlässig zusammengeführt? - Funktionieren Übergaben? - Gibt es ungenutzte oder überlastete Kanäle? - Bestehen unnötige parallele Wege? - Sind alternative Kanäle vorbereitet? - Ist die Benutzererfahrung verständlich? - Sind Sicherheitsmaßnahmen ausreichend? --- **Kanäle nicht nur hinzufügen, sondern auch entfernen** Neue Kanäle werden häufig schnell ergänzt. Alte Kanäle bleiben jedoch bestehen. Dadurch können entstehen: - unklare Auswahl, - veraltete Adressen, - schlecht überwachte Postfächer, - widersprüchliche Informationen, - und zusätzlicher Betriebsaufwand. Vor der Abschaltung eines Kanals sollte geprüft werden: - Wer verwendet ihn? - Welche Benutzergruppe wäre betroffen? - Welche Alternative besteht? - Wie wird die Änderung kommuniziert? - Müssen Weiterleitungen eingerichtet werden? - Gibt es vertragliche oder betriebliche Anforderungen? - Wie lange bleibt ein Übergangszeitraum bestehen? --- **Einführung eines neuen Kanals** Eine mögliche Vorgehensweise: 1. Benutzerbedarf und Problem beschreiben 2. geeignete Anwendungsfälle festlegen 3. Sicherheits- und Datenschutzanforderungen prüfen 4. Verantwortlichkeit bestimmen 5. technische Integration planen 6. Servicezeiten und Kapazität festlegen 7. Pilotgruppe auswählen 8. Erfolgskriterien definieren 9. Mitarbeiter und Benutzer informieren 10. Ergebnisse messen 11. Kanal anpassen oder ausweiten 12. bestehende Kanäle erneut bewerten Beispiel: Ein Chatkanal sollte nicht nur deshalb eingeführt werden, weil die verwendete Plattform diese Funktion anbietet. Zu prüfen ist: - Welche Anliegen sollen über Chat laufen? - Wer besetzt ihn? - Wird der Verlauf dokumentiert? - Wie erfolgt die Identitätsprüfung? - Wie wird an Fachteams übergeben? - Wann wird der Chat geschlossen? - Wie wird eine hohe gleichzeitige Nachfrage behandelt? --- **Kontaktkanäle bei einem Major Incident** Während eines Major Incidents kann das Kontaktvolumen stark steigen. Geeignete Maßnahmen: - bekannte Störung sichtbar veröffentlichen, - automatische Ansage aktualisieren, - identische Meldungen verknüpfen, - Service-Desk-Mitarbeitern freigegebene Statusinformationen bereitstellen, - klaren Aktualisierungsrhythmus festlegen, - und einen separaten technischen Koordinationskanal verwenden. Benutzerkanal und technischer Koordinationskanal sollten unterschieden werden. **Benutzerkanal** - verständliche Statusinformation - Auswirkungen - Zwischenlösung - nächste Aktualisierung **Technischer Koordinationskanal** - Diagnose, - Hypothesen, - technische Maßnahmen, - Entscheidungen, - Risiken, - und Verantwortlichkeiten Technische interne Diskussionen sollten nicht ungefiltert in öffentliche Statusmeldungen übernommen werden. --- **Kontaktkanäle bei Sicherheitsvorfällen** Bei einem möglichen Sicherheitsvorfall können zusätzliche Anforderungen gelten. Beispiele: - vertrauliche Behandlung, - begrenzter Zugriff, - Beweissicherung, - keine öffentliche Statusmeldung, - definierte Meldepflichten, - und besonders kontrollierte Kommunikation. Der normale Service Desk kann den ersten Kontakt aufnehmen. Er muss jedoch wissen: - wann das Sicherheitsteam einzubinden ist, - welche Informationen nicht verändert werden dürfen, - welche Kanäle zulässig sind, - und welche Aussagen vermieden werden müssen. --- **Kontaktkanäle bei Service Requests** Standardisierte Service Requests eignen sich häufig gut für Portale und Automatisierung. Beispiele: - Standardsoftware anfordern, - Gruppenmitgliedschaft beantragen, - neues Zubehör bestellen, - Verteilerliste ändern, - oder Arbeitsplatzwechsel melden. Ein gutes Request-Formular kann: - benötigte Informationen erfassen, - Genehmigung automatisch anstoßen, - den Status sichtbar machen, - und standardisierte Erfüllung auslösen. Der Benutzer sollte erkennen können: - welche Voraussetzungen gelten, - welche Kosten entstehen können, - welche Genehmigung benötigt wird, - und welche Bereitstellungszeit zu erwarten ist. --- **Kontaktkanäle beim Onboarding** Beim Onboarding entstehen häufig mehrere Kontakte: - Personalabteilung meldet den Eintritt. - Führungskraft nennt Rolle und Zugriffe. - Einkauf oder Asset Management stellt Geräte bereit. - neuer Mitarbeiter erhält Informationen. - Service Desk unterstützt bei der ersten Nutzung. Ein zentraler digitaler Einstieg kann helfen, Informationen einmalig und strukturiert zu erfassen. Dabei muss geklärt sein: - Wer darf den Eintritt melden? - Welche Daten werden benötigt? - Welche Freigaben gelten? - Wie wird der Status sichtbar? - Wie erhält der neue Mitarbeiter Unterstützung, wenn das Konto noch nicht funktioniert? Der letzte Punkt ist besonders wichtig. Ein ausschließlich internes Portal ist möglicherweise nicht nutzbar, wenn der Benutzer noch keinen funktionierenden Zugang besitzt. --- **Praxisbeispiel: Portal wird kaum verwendet** **Beobachtung** - Benutzer rufen fast immer an. - Das Portal besitzt viele Formulare. - Suchbegriffe führen zu unpassenden Ergebnissen. - Benutzer kennen die Bearbeitungszeiten nicht. **Ungeeignete Reaktion** > Ab nächster Woche werden telefonische Anfragen nicht mehr angenommen. **Bessere Untersuchung** - Welche Anliegen werden telefonisch gemeldet? - Können Benutzer die passenden Portalangebote finden? - Welche Formulare werden abgebrochen? - Sind technische Begriffe verständlich? - Funktioniert die Anmeldung zuverlässig? - Ist das Portal mobil verwendbar? - Gibt es einen menschlichen Ausweichweg? - Welchen Nutzen besitzt das Portal für den Benutzer? **Mögliche Verbesserungen** - häufige Angebote hervorheben, - Begriffe vereinfachen, - Formulare kürzen, - Suche verbessern, - Statusinformationen ergänzen, - Anmeldung vereinfachen, - und Portal gemeinsam mit Benutzern testen. --- **Praxisbeispiel: Zu viele E-Mail-Tickets** **Beobachtung** - Viele E-Mails besitzen keinen eindeutigen Betreff. - notwendige Informationen fehlen. - mehrere Personen antworten parallel. - Anhänge enthalten sensible Daten. **Mögliche Verbesserungen** - automatische Eingangsbestätigung, - kurze Hinweise zu benötigten Angaben, - sichere Uploadmöglichkeit, - automatische Verknüpfung mit bestehenden Vorgängen, - verständliches Portal als Alternative, - und Schulung des Service Desk zur Nachqualifizierung. E-Mail muss nicht zwingend abgeschafft werden. Sie kann für bestimmte Benutzergruppen weiterhin ein sinnvoller Kanal sein. --- **Praxisbeispiel: Support außerhalb der Geschäftszeit** **Ausgangslage** - Produktionsservice läuft rund um die Uhr. - Service Desk arbeitet von 08:00 bis 18:00 Uhr. - Nachts rufen Benutzer private Telefonnummern von Administratoren an. **Möglicher Zielzustand** - definierte Bereitschaftsnummer, - klare Kriterien für kritische Meldungen, - erreichbarer Incident-Koordinator, - aktueller Dienstplan, - dokumentierte Übergabe, - und Portal für nichtkritische Anliegen. **Zusätzlich zu klären** - Welche technischen Teams müssen erreichbar sein? - Welche Lieferanten bieten Nachtsupport? - Welche Maßnahmen darf die Bereitschaft durchführen? - Wer darf risikobehaftete Entscheidungen treffen? - Wie erfolgt die Information der regulären Teams? --- **Praxisbeispiel: Virtueller Agent blockiert Benutzer** **Ausgangslage** - Chatbot beantwortet Standardfragen. - Benutzer kann keinen Mitarbeiter auswählen. - Nach drei nicht passenden Antworten beginnt der Dialog erneut. - Benutzer ruft anschließend verärgert an. **Mögliche Verbesserungen** - menschliche Übergabe sichtbar anbieten, - bisherigen Verlauf übertragen, - Abbruchgründe analysieren, - Wissensquellen verbessern, - ungeeignete Anwendungsfälle entfernen, - und kritische Begriffe sofort eskalieren. > **Merke** > > Automatisierung soll einen Kontakt vereinfachen und nicht als Barriere vor menschlicher Unterstützung dienen. --- **Praxisbeispiel: Ticketsystem fällt aus** **Situation** - Service-Desk-Portal und Ticketsystem sind nicht erreichbar. - E-Mail-Tickets können ebenfalls nicht verarbeitet werden. - Benutzer benötigen weiterhin einen Meldeweg. **Vorbereitete Lösung** - unabhängige Notfallnummer, - vorübergehende gesicherte Erfassung, - externe Statusseite, - definierte Priorisierung, - und spätere Übernahme der Notfallvorgänge in das Ticketsystem. Zu vermeiden: - private Notizzettel ohne spätere Übernahme, - unkontrollierte Chatgruppen, - und Veröffentlichung interner technischer Details. --- **Typische Fehler bei Kontaktkanälen** **Fehler 1: Möglichst viele Kanäle anbieten** Die Organisation kann sie nicht zuverlässig überwachen und zusammenführen. --- **Fehler 2: Portalzwang ohne geeignete Alternative** Komplexe, dringende oder barrierebedingte Situationen werden nicht berücksichtigt. --- **Fehler 3: Technische Verfügbarkeit mit Supportzeit verwechseln** Benutzer erwarten sofortige Bearbeitung, obwohl nur eine automatische Erfassung erfolgt. --- **Fehler 4: Private Supportkanäle dulden** Meldungen verschwinden in persönlichen Chats, Postfächern oder Telefonlisten. --- **Fehler 5: Benutzer müssen das technische Team auswählen** Falsche Zuordnungen und unnötige Weiterleitungen entstehen. --- **Fehler 6: Kritische und normale Anliegen verwenden denselben unpriorisierten Kanal** Dringende Meldungen werden möglicherweise zu spät erkannt. --- **Fehler 7: Kein alternativer Kanal** Beim Ausfall von Portal, E-Mail oder Identitätsdienst ist der Service Desk nicht erreichbar. --- **Fehler 8: Virtueller Agent ohne menschlichen Ausweg** Benutzer bleiben in automatisierten Antwortschleifen. --- **Fehler 9: Kanäle werden nicht sicher gestaltet** Identitätsprüfung, Datenschutz und vertrauliche Kommunikation fehlen. --- **Fehler 10: Servicezeiten sind nicht sichtbar** Benutzer wissen nicht, wann mit einer Reaktion zu rechnen ist. --- **Fehler 11: Kanalwechsel verliert den Kontext** Benutzer müssen ihre Situation mehrfach erklären. --- **Fehler 12: Self-Service nur zur Kostensenkung** Benutzeraufwand und Abbruchquote steigen. --- **Fehler 13: Statusseite wird nicht aktualisiert** Veraltete Informationen beschädigen das Vertrauen. --- **Fehler 14: Bereitschaft ist nur informell geregelt** Einzelne Mitarbeiter werden unkoordiniert und ohne Vertretung kontaktiert. --- **Fehler 15: Kennzahlen werden isoliert optimiert** Kurze Wartezeiten werden erreicht, während Lösungsqualität und Benutzererfahrung sinken. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten häufig in Service Desk, Betrieb oder nachgelagerten Supportgruppen. Sie sollten die vorgesehenen Kontaktwege kennen und unterstützen. Wichtige Verhaltensweisen: - private Meldungen in den offiziellen Wertstrom überführen, - kritische Anliegen nicht wegen eines falschen Kanals ignorieren, - technische Rückmeldungen im zentralen Vorgang dokumentieren, - Benutzer nicht unnötig an einen weiteren Kanal verweisen, - alternative Meldewege bei Ausfällen kennen, - Sicherheitsverfahren einhalten, - und Statusinformationen an den Service Desk zurückgeben. Beispiel: Ein Benutzer schreibt einem Administrator direkt: > Der Fileserver geht nicht. Ungeeignet: > Dafür bin ich nicht zuständig. Eröffnen Sie ein Ticket. Besser: > Ich erfasse die Meldung im Service Desk, damit sie nachvollziehbar bearbeitet wird. Können Sie mir kurz sagen, ob nur Sie oder weitere Benutzer betroffen sind? Anschließend: - Vorgang erstellen, - Auswirkung prüfen, - zuständige Bearbeitung einbinden, - und Benutzer über den nächsten Schritt informieren. --- **30-Sekunden-Prüfung eines Kontaktkanals** 1. **Zielgruppe:** Wer soll den Kanal verwenden? 2. **Anliegen:** Für welche Kontakte ist er geeignet? 3. **Servicezeit:** Wann wird er tatsächlich bearbeitet? 4. **Verantwortung:** Wer überwacht den Kanal? 5. **Integration:** Werden Kontakte zentral dokumentiert? 6. **Sicherheit:** Wie werden Identität und Informationen geschützt? 7. **Barrierefreiheit:** Können die vorgesehenen Benutzer den Kanal verwenden? 8. **Eskalation:** Wie gelangen kritische Anliegen schnell zur richtigen Stelle? 9. **Alternative:** Was geschieht bei Ausfall des Kanals? 10. **Übergabe:** Bleiben Informationen bei einem Kanalwechsel erhalten? 11. **Messung:** Wie wird die Wirksamkeit überprüft? 12. **Verbesserung:** Wie wird Benutzerfeedback verwendet? --- **Checkliste für ein Self-Service-Portal** - [ ] Sind häufige Anliegen leicht auffindbar? - [ ] Werden verständliche Begriffe verwendet? - [ ] Müssen Benutzer keine internen Teams oder Practices kennen? - [ ] Sind Formulare so kurz wie möglich? - [ ] Werden nur notwendige Informationen verlangt? - [ ] Sind Servicezeiten und erwartete Bearbeitungszeiten sichtbar? - [ ] Ist der Status eines Vorgangs nachvollziehbar? - [ ] Funktioniert das Portal auf benötigten Geräten? - [ ] Sind barrierearme Nutzung und Alternativen berücksichtigt? - [ ] Ist ein menschlicher Kontaktweg sichtbar? - [ ] Werden Sicherheits- und Datenschutzanforderungen eingehalten? - [ ] Werden Suchbegriffe, Abbrüche und Feedback ausgewertet? --- **Checkliste für telefonischen Support** - [ ] Ist die Nummer leicht auffindbar? - [ ] Sind Servicezeiten veröffentlicht? - [ ] Ist die Ansage verständlich und aktuell? - [ ] Ist das Telefonmenü möglichst kurz? - [ ] Besteht eine Regel für kritische Incidents? - [ ] Werden Kontakte zentral dokumentiert? - [ ] Ist die Identitätsprüfung risikogerecht? - [ ] Bestehen Rückruf- oder Überlaufmöglichkeiten? - [ ] Sind Wartezeiten und Abbruchquoten bekannt? - [ ] Ist eine Vertretung bei Ausfall der Telefonanlage vorbereitet? --- **Checkliste für E-Mail-Support** - [ ] Wird ein gemeinsames statt eines privaten Postfachs verwendet? - [ ] Erfolgt eine automatische Eingangsbestätigung? - [ ] Wird eine Vorgangsnummer erzeugt? - [ ] Sind Servicezeiten und dringende Alternativen angegeben? - [ ] Werden Anhänge sicher verarbeitet? - [ ] Sind Regeln für vertrauliche Informationen vorhanden? - [ ] Werden E-Mail-Verläufe dem richtigen Vorgang zugeordnet? - [ ] Werden Duplikate erkannt? - [ ] Ist der Kanal regelmäßig überwacht? - [ ] Werden unvollständige Meldungen strukturiert nachqualifiziert? --- **Checkliste für Chat und virtuelle Agenten** - [ ] Ist erkennbar, ob ein Mensch oder ein automatisiertes System antwortet? - [ ] Sind die Servicezeiten sichtbar? - [ ] Wird der Verlauf dokumentiert? - [ ] Können Vorgänge automatisch erzeugt werden? - [ ] Besteht ein klarer Übergang zu einem Menschen? - [ ] Bleiben Informationen bei der Übergabe erhalten? - [ ] Werden kritische und sicherheitsbezogene Begriffe erkannt? - [ ] Ist die Identitätsprüfung für sensible Aktionen ausreichend? - [ ] Werden Fehlantworten und Abbrüche ausgewertet? - [ ] Werden Benutzer nicht in Antwortschleifen festgehalten? --- **Checkliste für Erreichbarkeit außerhalb der Servicezeit** - [ ] Ist bekannt, welche Services kritisch sind? - [ ] Sind Aktivierungskriterien für die Bereitschaft definiert? - [ ] Ist der Meldeweg veröffentlicht? - [ ] Ist ein aktueller Dienstplan vorhanden? - [ ] Besitzen Bereitschaftskräfte notwendige Zugänge und Befugnisse? - [ ] Sind technische Eskalationswege bekannt? - [ ] Sind Lieferanten außerhalb der Geschäftszeit erreichbar? - [ ] Besteht ein alternativer Kanal bei Systemausfall? - [ ] Werden alle Maßnahmen dokumentiert? - [ ] Ist die Übergabe an den regulären Service Desk geregelt? --- **Checkliste für die gesamte Kanalstrategie** - [ ] Sind Benutzergruppen und ihre Arbeitsbedingungen bekannt? - [ ] Sind geeignete Kanäle für unterschiedliche Anliegen definiert? - [ ] Werden alle Kanäle zuverlässig überwacht? - [ ] Werden Kontakte in einer gemeinsamen Sicht zusammengeführt? - [ ] Sind Servicezeiten eindeutig veröffentlicht? - [ ] Sind kritische und normale Anliegen unterscheidbar? - [ ] Sind Sicherheits- und Datenschutzanforderungen berücksichtigt? - [ ] Bestehen barrierearme und alternative Kontaktmöglichkeiten? - [ ] Bleibt der Kontext bei Kanalwechseln erhalten? - [ ] Ist der Service Desk auch bei Ausfall zentraler Systeme erreichbar? - [ ] Sind Kapazität und Bereitschaft ausreichend? - [ ] Sind Statusinformationen konsistent? - [ ] Werden Kennzahlen und Benutzerfeedback gemeinsam ausgewertet? - [ ] Werden ungenutzte oder ungeeignete Kanäle entfernt? - [ ] Fließen Erkenntnisse in Continual Improvement ein? --- **Schnellreferenz** | Kanal | Besonders geeignet für | Besonders zu beachten | |---|---|---| | **Portal** | strukturierte Incidents und Requests | Verständlichkeit, Suche und Alternativkanal | | **Telefon** | dringende und komplexe Situationen | Wartezeit, Dokumentation und Identitätsprüfung | | **E-Mail** | schriftliche, weniger dringende Anliegen | Vollständigkeit, Anhänge und Sicherheit | | **Chat** | schnelle Rückfragen und begleitete Diagnose | Dokumentation und Übergabe | | **virtueller Agent** | häufige standardisierte Anliegen | Transparenz, Qualität und menschlicher Ausweg | | **mobile App** | mobile Benutzer und Statusinformationen | Gerätesicherheit und Datenschutz | | **Vor-Ort-Kontakt** | Geräteprobleme und komplexe Unterstützung | Dokumentation und Priorisierung | | **Notfallkanal** | klar definierte kritische Situationen | Missbrauchsschutz und schnelle Eskalation | | **Statusseite** | bekannte Störungen und Wartungen | Aktualität und Schutz vertraulicher Informationen | --- **Zusammenfassende Darstellung** > Benutzer benötigt Unterstützung > ↓ > geeigneten und bekannten Kontaktkanal auswählen > ↓ > Kanal ist technisch verfügbar und organisatorisch besetzt > ↓ > Identität und Anliegen angemessen erfassen > ↓ > Kontakt zentral dokumentieren und fachlich einordnen > ↓ > geeigneten Wertstrom und zuständige Fähigkeiten einbinden > ↓ > Status über den passenden Kanal kommunizieren > ↓ > bei Bedarf Kanal wechseln, ohne Informationen zu verlieren > ↓ > Outcome bestätigen > ↓ > Kanalqualität und Benutzererfahrung auswerten > ↓ > Kontaktstrategie fortlaufend verbessern --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.3 Benutzerkommunikation und professioneller Umgang - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Information Security Management - Knowledge Management - Service Level Management - Service Continuity Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [PeopleCert: ITIL 4 Practitioner – Service Desk Mock Exam](https://www.peoplecert.org/browse-mock-exams/it-governance-and-service-management/ITIL-1/ITIL%204%20Practitioner%20Service%20Desk%20Mock%20exam-3707) - [ITIL: The ongoing relevance of the service desk in an AI world](https://www.itil.com/Itil-News-and-Announcements/service-desk-relevance-ai-world) - [PeopleCert: Build an AI-Powered Service Desk That Runs Itself](https://www.peoplecert.org/news-and-announcements/design-a-service-desk-that-practically-runs-itself) - [ITIL: ITIL Service – Version 5](https://www.itil.com/Itil-News-and-Announcements/itil-service-version-5) - [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) **Offiziell bestätigter Stand** Die offiziellen ITIL- und PeopleCert-Quellen bestätigen: - Der Service Desk dient als zentraler Kontaktpunkt zwischen Service Provider und Benutzern. - Eine wirksame Service-Desk-Practice beeinflusst Benutzererfahrung, Kundenerfahrung und Servicebeziehungen. - Informationen und Technologien sollen die Service-Desk-Practice unterstützen, Arbeitsweisen vereinfachen und Benutzererfahrung verbessern. - Virtuelle Service Desks, KI-gestützte Unterstützung, Chatbots und automatisierte Standardaufgaben sind heute verbreitete Bestandteile moderner Serviceumgebungen. - Menschliche Kommunikation, Empathie, Kontextverständnis und kreative Zusammenarbeit bleiben insbesondere bei komplexen Situationen wichtig. - Self-Service sollte durch verständliche Portale, hochwertige Wissensinhalte, Vertrauen und benutzerorientierte Gestaltung unterstützt werden. - ITIL Version 5 richtet Serviceaktivitäten stärker auf Endbenutzererfahrung, Wertfluss und Zusammenarbeit über organisatorische Grenzen hinweg aus. **Einordnung** Die auf dieser Seite beschriebenen: - Kanalmodelle, - Servicezeiten, - Bereitschaftsregelungen, - Telefon- und Portalgestaltungen, - Checklisten, - Sicherheitsmaßnahmen, - Kennzahlen, - und Praxisbeispiele sind herstellerneutrale redaktionelle Empfehlungen dieses unabhängigen Nachschlagewerks. ITIL schreibt keine universelle: - Anzahl von Kontaktkanälen, - rund um die Uhr bestehende Servicezeit, - Telefonmenüstruktur, - Antwortzeit, - Support-Level-Struktur, - oder bestimmte technische Plattform vor. Die konkrete Kanalstrategie muss an: - Benutzergruppen, - Servicekritikalität, - Arbeitszeiten, - Risiken, - Sicherheitsanforderungen, - vertragliche Verpflichtungen, - verfügbare Fähigkeiten, - und organisatorische Ressourcen angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Service-Desk-Guidance **Fachlicher Stand:** August 2026 # 3.3 Benutzerkommunikation und professioneller Umgang > **Kurz erklärt** > > Benutzerkommunikation ist ein wesentlicher Bestandteil der Serviceerfahrung. > > Ein technisches Problem wird aus Sicht eines Benutzers nicht nur danach bewertet: > > - ob es gelöst wurde, > - sondern auch wie der Kontakt verlief, > - ob das Anliegen verstanden wurde, > - ob Informationen verständlich waren, > - ob Zusagen eingehalten wurden, > - und ob der Benutzer wusste, was als Nächstes geschieht. > > Professionelle Kommunikation bedeutet: > > - aufmerksam zuhören, > - Auswirkungen verstehen, > - verständlich sprechen und schreiben, > - Erwartungen realistisch steuern, > - Unsicherheiten offen benennen, > - regelmäßig informieren, > - respektvoll bleiben, > - Sicherheits- und Datenschutzregeln einhalten, > - und das erreichte Ergebnis aus Benutzersicht bestätigen. > > Empathie ist dabei kein Ersatz für technische Kompetenz. > > Sie hilft, technische Kompetenz so einzusetzen und zu vermitteln, dass Benutzer Vertrauen gewinnen und handlungsfähig bleiben. --- **Warum Kommunikation Teil der Serviceleistung ist** Benutzer erleben einen Service nicht ausschließlich über: - Verfügbarkeit, - Leistung, - Funktionen, - oder technische Messwerte. Sie erleben ihn auch über die Interaktionen mit der Serviceorganisation. Dazu gehören: - Portaltexte, - Fehlermeldungen, - Telefongespräche, - Chatnachrichten, - E-Mails, - Statusinformationen, - Wartungsankündigungen, - Rückfragen, - Eskalationen, - und Abschlussmeldungen. Ein Service kann technisch wiederhergestellt sein und trotzdem eine schlechte Erfahrung hinterlassen. Beispiele: - Der Benutzer erhält stundenlang keine Statusinformation. - Mehrere Mitarbeiter stellen dieselben Fragen. - Der Benutzer muss technische Begriffe verstehen, die für seine Aufgabe nicht relevant sind. - Eine versprochene Rückmeldung erfolgt nicht. - Das Ticket wird geschlossen, obwohl die Arbeitsfähigkeit noch nicht wiederhergestellt ist. - Ein Mitarbeiter macht den Benutzer für den Fehler verantwortlich. - Eine Störung wird verharmlost, obwohl sie einen wichtigen Arbeitsprozess blockiert. - Es wird eine Lösung versprochen, obwohl Ursache und Zeitbedarf noch unbekannt sind. > **Merke** > > Kommunikation ist kein Zusatz zur technischen Bearbeitung. > > Sie ist ein sichtbarer Bestandteil der gesamten Serviceerfahrung. --- **Technische Qualität und Kommunikation wirken zusammen** | Technische Bearbeitung | Kommunikation | Mögliche Wahrnehmung | |---|---|---| | schnell und wirksam | verständlich und zuverlässig | sehr positive Erfahrung | | schnell und wirksam | unfreundlich oder unklar | technisch erfolgreich, aber negatives Vertrauen | | langsam oder komplex | transparent und regelmäßig | Situation bleibt belastend, aber nachvollziehbar | | langsam oder komplex | keine verlässlichen Informationen | starke Unsicherheit und negative Erfahrung | | technisch nicht lösbar | Alternativen und Grenzen werden verständlich erklärt | realistische und professionelle Behandlung | | technisch scheinbar gelöst | Benutzer kann weiterhin nicht arbeiten | tatsächliches Outcome nicht erreicht | Eine freundliche Kommunikation kann eine schlechte technische Leistung nicht dauerhaft ausgleichen. Eine gute technische Leistung kann jedoch ebenfalls an Wert verlieren, wenn die Kommunikation: - respektlos, - unverständlich, - widersprüchlich, - oder unzuverlässig ist. --- **Ziel professioneller Benutzerkommunikation** Professionelle Kommunikation soll dazu beitragen, dass: - das Anliegen richtig verstanden wird, - notwendige Informationen vollständig vorliegen, - der Benutzer den nächsten Schritt kennt, - Missverständnisse vermieden werden, - Auswirkungen angemessen berücksichtigt werden, - Vertrauen erhalten bleibt, - Sicherheitsregeln eingehalten werden, - und das gewünschte Outcome gemeinsam erreicht werden kann. Sie soll nicht nur möglichst freundlich klingen. Sie muss außerdem: - fachlich korrekt, - situationsgerecht, - nachvollziehbar, - und handlungsorientiert sein. --- **Kommunikation an Wissen und Kontext anpassen** Service-Desk-Mitarbeiter sprechen mit Personen mit unterschiedlichen: - technischen Kenntnissen, - Aufgaben, - Verantwortlichkeiten, - Sprachkenntnissen, - Erfahrungen, - und Stresssituationen. Eine identische Erklärung ist deshalb nicht für jede Person geeignet. Beispiel für einen technisch erfahrenen Ansprechpartner: > Die Namensauflösung funktioniert, aber die TCP-Verbindung zum Dienst wird am Standort blockiert. Das Netzwerkteam prüft aktuell Firewall und Routing. Beispiel für einen Benutzer ohne technischen Schwerpunkt: > Ihr Computer erreicht den zentralen Dienst derzeit nicht. Das zuständige Netzwerkteam prüft die Verbindung. Sie müssen im Moment keine weiteren Einstellungen verändern. Beide Aussagen können dieselbe Situation beschreiben. Die Formulierung wird an die jeweilige Zielgruppe angepasst. > **Merke** > > Verständliche Kommunikation bedeutet nicht, Informationen ungenau oder falsch darzustellen. > > Sie bedeutet, die benötigte Information in einer geeigneten Sprache und Detailtiefe zu vermitteln. --- **Fachsprache bewusst verwenden** Technische Fachbegriffe sind sinnvoll, wenn: - die Gesprächspartner sie verstehen, - sie für die Entscheidung notwendig sind, - oder sie eine Situation präziser beschreiben. Sie sind ungeeignet, wenn sie: - den Benutzer verwirren, - Kompetenz demonstrieren sollen, - Verantwortung auf den Benutzer verlagern, - oder den eigentlichen nächsten Schritt verdecken. Ungeeignet: > Der SAML-Assertion-Consumer-Service liefert aufgrund eines fehlerhaften IdP-Mappings einen Authentifizierungsfehler. Verständlicher: > Die Anmeldung zwischen dem Identitätsdienst und der Anwendung funktioniert derzeit nicht korrekt. Das zuständige Team prüft die Zuordnung. Ihr Kennwort müssen Sie nicht erneut ändern. Für ein technisches Fachteam kann die detaillierte Beschreibung weiterhin notwendig sein. Benutzerkommunikation und technische Dokumentation dürfen deshalb unterschiedliche Detailstufen besitzen. --- **Aktives Zuhören** Aktives Zuhören bedeutet, den Benutzer nicht nur sprechen zu lassen, sondern seine Informationen bewusst aufzunehmen und zu überprüfen. Dazu gehören: - nicht unnötig unterbrechen, - relevante Aussagen erkennen, - gezielt nachfragen, - das Verstandene zusammenfassen, - Unsicherheiten klären, - und Auswirkungen ernst nehmen. Beispiel: Benutzer: > Seit heute Morgen geht bei mir gar nichts mehr. Ungeeignete Reaktion: > Haben Sie den Computer schon neu gestartet? Bessere Reaktion: > Ich kläre kurz, was genau betroffen ist. Können Sie sich nicht am Computer anmelden oder funktionieren nach der Anmeldung bestimmte Anwendungen nicht? Die zweite Reaktion verhindert, dass sofort eine Lösung versucht wird, bevor das Problem ausreichend verstanden ist. --- **Offene und geschlossene Fragen** Beide Fragearten können sinnvoll sein. **Offene Fragen** Sie ermöglichen eine freie Beschreibung. Beispiele: - Was wollten Sie durchführen? - Was ist stattdessen geschehen? - Welche Auswirkungen hat die Störung auf Ihre Arbeit? - Was wurde bereits ausprobiert? - Was hat sich seit gestern verändert? **Geschlossene Fragen** Sie klären konkrete Punkte. Beispiele: - Sind weitere Benutzer betroffen? - Wird eine Fehlermeldung angezeigt? - Funktioniert die Anmeldung im Browser? - Ist das Gerät mit dem Netzwerk verbunden? - Besteht eine alternative Arbeitsmöglichkeit? Eine sinnvolle Gesprächsführung beginnt häufig mit einer offenen Frage und wird anschließend durch konkrete Fragen präzisiert. --- **Das Verstandene zusammenfassen** Eine kurze Zusammenfassung hilft, Missverständnisse früh zu erkennen. Beispiel: > Ich fasse kurz zusammen: Sie können sich seit ungefähr 09:15 Uhr am Zeiterfassungssystem anmelden, aber beim Speichern erscheint die Meldung „Zugriff verweigert“. Zwei Kollegen in derselben Abteilung sind ebenfalls betroffen. Andere Anwendungen funktionieren. Ist das korrekt? Vorteile: - Benutzer kann Fehler korrigieren. - technische Bearbeitung erhält eine klare Ausgangslage. - unnötige Rückfragen werden reduziert. - der Benutzer erkennt, dass sein Anliegen verstanden wurde. --- **Empathie** Empathie bedeutet, die Situation und Perspektive einer anderen Person wahrzunehmen und angemessen darauf zu reagieren. Sie bedeutet nicht: - jeder Forderung zuzustimmen, - Prioritätsregeln aufzugeben, - technische Tatsachen zu verändern, - Sicherheitskontrollen zu umgehen, - oder die Verantwortung für alle Gefühle des Benutzers zu übernehmen. Geeignete empathische Aussagen: - Ich verstehe, dass die Unterbrechung Ihren heutigen Termin gefährdet. - Das ist besonders ungünstig, weil Sie den Zugriff gerade für den Monatsabschluss benötigen. - Ich kann nachvollziehen, dass die wiederholte Anmeldung frustrierend ist. - Ich sehe, dass Sie die Datei dringend benötigen. Ich prüfe jetzt zuerst, ob eine sichere Zwischenlösung möglich ist. Ungeeignete Aussagen: - Das ist doch nicht so schlimm. - Bei mir funktioniert es. - Sie sind der einzige Benutzer mit diesem Problem. - Dafür können wir nichts. - Beruhigen Sie sich erst einmal. > **Wichtig** > > Empathie erkennt die Auswirkung an. > > Sie verspricht nicht automatisch eine sofortige Lösung. --- **Empathie und Priorisierung unterscheiden** Ein Benutzer kann stark belastet sein, während die organisatorisch bestimmte Priorität trotzdem nicht die höchste Stufe erreicht. Beispiel: > Ich verstehe, dass Sie die Anwendung für Ihre aktuelle Aufgabe benötigen. Nach unseren Kriterien ist derzeit nur Ihr Arbeitsplatz betroffen und ein Ersatzarbeitsplatz steht zur Verfügung. Der Vorgang wird deshalb mit Priorität 3 bearbeitet. Sollte auch die Alternative ausfallen oder weitere Benutzer betroffen sein, bewerten wir die Priorität erneut. Diese Aussage: - erkennt die Situation an, - erklärt die Entscheidung, - nennt die Alternative, - und beschreibt, wann eine Neubewertung erfolgt. Ungeeignet: > Dafür bekommen Sie keine höhere Priorität. --- **Eine professionelle Gesprächsstruktur** Eine mögliche Struktur für einen Benutzerkontakt ist: 1. Kontakt eröffnen 2. Identität und Zuständigkeit klären 3. Anliegen frei beschreiben lassen 4. Situation und Auswirkungen präzisieren 5. das Verstandene zusammenfassen 6. Einordnung und nächsten Schritt erklären 7. Erwartungen und Zeitpunkte klären 8. Maßnahme durchführen oder weiterleiten 9. Ergebnis prüfen 10. Kontakt professionell abschließen Diese Struktur ist eine Praxisempfehlung und kein für jede Situation vorgeschriebener ITIL-Prozess. --- **1. Kontakt eröffnen** Eine geeignete Eröffnung sollte: - freundlich, - eindeutig, - und dem Kanal angemessen sein. Telefon: > Guten Morgen, IT-Service-Desk, Max Mustermann. Wie kann ich Sie unterstützen? Chat: > Hallo, Sie sind beim IT-Service-Desk. Ich schaue mir Ihr Anliegen gern an. Wobei benötigen Sie Unterstützung? E-Mail: > Guten Tag, vielen Dank für Ihre Meldung. Ich prüfe zunächst die betroffene Anwendung und die bisher bekannten Auswirkungen. Bei bereits bekannten Vorgängen: > Guten Tag, ich melde mich zu Ihrem Vorgang 4711 bezüglich des Dateizugriffs. --- **2. Identität und Zuständigkeit klären** Abhängig vom Anliegen kann geprüft werden: - Wer meldet? - Wer ist tatsächlich betroffen? - Für welche Organisationseinheit? - Welcher Service wird benötigt? - Darf die meldende Person die gewünschte Änderung veranlassen? - Ist eine zusätzliche Identitätsprüfung erforderlich? Eine starke Identitätsprüfung darf nicht durch freundliches Auftreten oder angeblichen Zeitdruck ersetzt werden. Ungeeignet: > Sie klingen glaubwürdig. Ich setze das Kennwort direkt zurück. Besser: > Für die Kennwortzurücksetzung muss ich Ihre Identität nach unserem festgelegten Verfahren prüfen. Ich führe Sie kurz durch die erforderlichen Schritte. --- **3. Anliegen beschreiben lassen** Der Benutzer sollte zunächst ausreichend Gelegenheit erhalten, seine Beobachtung zu schildern. Hilfreiche Einstiegsfragen: - Was möchten Sie durchführen? - Was funktioniert dabei nicht wie erwartet? - Welche Meldung sehen Sie? - Welche Auswirkung entsteht für Ihre Arbeit? Zu frühe technische Vermutungen können die Beschreibung verfälschen. Beispiel: Ungeeignet: > Dann ist bestimmt Ihr VPN kaputt. Besser: > Ich prüfe zunächst, ob die Verbindung oder die Anwendung selbst betroffen ist. --- **4. Auswirkungen präzisieren** Wichtige Fragen: - Welche Tätigkeit ist blockiert? - Sind weitere Personen betroffen? - Welcher Service oder Geschäftsprozess ist betroffen? - Besteht eine sichere Zwischenlösung? - Gibt es einen zeitkritischen Termin? - Besteht ein möglicher Sicherheits- oder Datenverlustbezug? Die Kommunikation sollte nicht nur das technische Symptom erfassen. Beispiel: > Der Drucker funktioniert nicht. Die tatsächliche Auswirkung kann reichen von: - ein Benutzer kann einen internen Entwurf nicht ausdrucken bis zu: - der gesamte Warenausgang kann keine Versandetiketten erzeugen. --- **5. Zusammenfassen und bestätigen** Beispiel: > Sie können seit etwa 13:00 Uhr keine Versandetiketten drucken. Betroffen sind alle vier Arbeitsplätze im Warenausgang. Andere Drucker funktionieren, aber es gibt dort keine zulässige Alternative für die Etiketten. Der Versand steht deshalb momentan still. Ist diese Zusammenfassung korrekt? Diese Informationen unterstützen: - Priorisierung, - technische Diagnose, - Eskalation, - und Statuskommunikation. --- **6. Nächsten Schritt erklären** Der Benutzer sollte wissen: - was jetzt geschieht, - wer beteiligt wird, - ob er selbst etwas tun muss, - und wann eine weitere Information erfolgt. Beispiel: > Ich prüfe zunächst, ob bereits eine allgemeine Störung bekannt ist. Danach teste ich die Verbindung zum Druckservice. Falls die Ursache dort nicht erkennbar ist, binde ich das zuständige Druck- und Netzwerkteam ein. Ungeeignet: > Ich gebe das weiter. Besser: > Ich gebe den Vorgang mit den bisherigen Prüfergebnissen an das Netzwerkteam. Der Service Desk behält die Kommunikation. Sie erhalten spätestens um 14:30 Uhr eine Statusmeldung, auch wenn die Ursache dann noch nicht vollständig behoben ist. --- **7. Erwartungen realistisch steuern** Zu klären sind: - Was kann sofort getan werden? - Was benötigt weitere Analyse? - Welche Abhängigkeiten bestehen? - Liegt eine bekannte Zielzeit vor? - Wann erfolgt die nächste Statusmeldung? - Besteht eine Zwischenlösung? - Welche Grenzen gelten? Eine realistische Aussage ist besser als eine beruhigend gemeinte, aber unbelegte Zusage. Ungeeignet: > Das ist gleich erledigt. Besser: > Die Ursache ist noch nicht bestätigt. Das zuständige Team beginnt jetzt mit der Analyse. Eine verlässliche Lösungszeit kann ich noch nicht nennen. Die nächste Rückmeldung erfolgt spätestens um 16:00 Uhr. --- **8. Maßnahme durchführen oder weiterleiten** Während einer Maßnahme sollte erklärt werden: - was durchgeführt wird, - warum es durchgeführt wird, - ob eine Unterbrechung entsteht, - und welches Ergebnis erwartet wird. Beispiel: > Ich starte nicht den gesamten Computer neu. Zuerst beende ich nur den betroffenen Druckdienst, weil die anderen Anwendungen ordnungsgemäß funktionieren. Bei einer Remote-Sitzung: > Ich öffne jetzt die Netzwerkeinstellungen und prüfe die bestehende Verbindung. Ich ändere noch keine Konfiguration. Sollte eine Änderung erforderlich sein, erkläre ich sie vorher. --- **9. Ergebnis prüfen** Nach einer technischen Maßnahme sollte nicht nur gefragt werden: > Geht es jetzt? Präzisere Prüfung: - Können Sie sich jetzt anmelden? - Können Sie die zuvor fehlgeschlagene Datei öffnen? - Können Sie den vollständigen Arbeitsschritt durchführen? - Erscheint die Fehlermeldung erneut? - Funktioniert die Anwendung nur vorübergehend oder stabil? - Sind weitere Benutzer weiterhin betroffen? Das Ergebnis sollte sich am ursprünglichen Outcome orientieren. --- **10. Kontakt abschließen** Ein professioneller Abschluss kann enthalten: - kurze Zusammenfassung, - bestätigtes Ergebnis, - offene Punkte, - Vorgangsnummer, - nächsten Schritt, - und Kontaktmöglichkeit. Beispiel: > Die Anmeldung funktioniert wieder und Sie konnten den Auftrag erfolgreich speichern. Die Ursache war eine fehlerhafte Gruppenmitgliedschaft. Der Vorgang bleibt noch bis morgen zur Kontrolle geöffnet. Sollte der Fehler erneut auftreten, antworten Sie bitte unter Angabe der Vorgangsnummer 4711. Bei ungelöster Situation: > Die Störung ist noch nicht behoben. Das Anwendungsteam untersucht aktuell die fehlerhafte Berechtigung. Als Zwischenlösung können Sie den Auftrag über Arbeitsplatz 12 bearbeiten. Die nächste Statusmeldung erfolgt spätestens um 11:30 Uhr. --- **Klare Sprache verwenden** Klare Sprache zeichnet sich aus durch: - kurze und vollständige Sätze, - eindeutige Handlungsanweisungen, - bekannte Begriffe, - nachvollziehbare Reihenfolge, - und sichtbare nächste Schritte. Ungeeignet: > Bitte führen Sie das übliche Prozedere durch und melden Sie sich gegebenenfalls erneut. Besser: > Starten Sie die Anwendung einmal neu. Melden Sie sich anschließend erneut an. Falls wieder die Meldung „Zugriff verweigert“ erscheint, antworten Sie bitte direkt auf diese Nachricht. --- **Nur eine Handlung pro Schritt** Besonders bei Telefon, Chat oder E-Mail sollten technische Anweisungen klar gegliedert sein. Ungeeignet: > Öffnen Sie die Einstellungen, prüfen Sie die Verbindung, löschen Sie den Cache, starten Sie neu und probieren Sie es noch einmal. Besser: 1. Öffnen Sie die Anwendung noch nicht erneut. 2. Prüfen Sie unten rechts, ob das Netzwerksymbol eine Verbindung anzeigt. 3. Teilen Sie mir bitte mit, welches Symbol angezeigt wird. 4. Danach bestimmen wir den nächsten Schritt. Dadurch kann das Ergebnis jedes einzelnen Schritts bewertet werden. --- **Richtung und Ort eindeutig beschreiben** Ungeeignet: > Klicken Sie da links auf das Symbol. Besser: > Öffnen Sie oben rechts das Benutzermenü und wählen Sie anschließend „Abmelden“. Bei mehreren Betriebssystemen oder Versionen sollte vorher geklärt werden: - welches Gerät, - welches Betriebssystem, - welche Anwendung, - und welche Version verwendet wird. --- **Keine unnötigen Vermutungen als Tatsache darstellen** Ungeeignet: > Das liegt sicher an Ihrem WLAN. Besser: > Eine instabile Verbindung ist eine mögliche Ursache. Ich prüfe zunächst, ob auch andere Benutzer oder Netzwerkverbindungen betroffen sind. Ungeeignet: > Der Hersteller hat gerade eine Störung. Besser: > Beim Hersteller ist derzeit eine mögliche Störung gemeldet. Wir prüfen noch, ob sie mit Ihrem Problem zusammenhängt. --- **Transparenz über Unsicherheit** Professionelle Kommunikation darf Unsicherheit enthalten. Geeignete Aussagen: - Die genaue Ursache ist noch nicht bestätigt. - Wir haben zwei mögliche Ursachen eingegrenzt. - Der erste Wiederherstellungsversuch war nicht erfolgreich. - Die technische Funktion ist wiederhergestellt, aber wir überwachen den Service noch. - Die Zeitangabe ist eine aktuelle Schätzung und kann sich ändern. - Wir benötigen für die weitere Analyse Informationen des Herstellers. Ungeeignet ist, Unsicherheit durch scheinbare Gewissheit zu verdecken. > **Merke** > > Ehrliche Unsicherheit kann Vertrauen erhalten. > > Falsche Sicherheit beschädigt Vertrauen, sobald eine Zusage nicht eingehalten wird. --- **Zusagen einhalten** Zusagen können sein: - Rückruf, - Statusmeldung, - Prüfung, - Weiterleitung, - Dokumentation, - oder ein vereinbarter Termin. Kann eine Zusage nicht eingehalten werden, sollte die Information vor Ablauf des zugesagten Zeitpunkts erfolgen. Beispiel: > Die angekündigte Rückmeldung um 14:00 Uhr kann ich noch nicht mit einer Lösung verbinden. Das Netzwerkteam prüft weiterhin die Standortverbindung. Der Provider wurde inzwischen einbezogen. Die nächste Aktualisierung erfolgt spätestens um 15:00 Uhr. Ungeeignet: - keine Rückmeldung geben, - bis zur vollständigen Lösung warten, - oder erst nach einer erneuten Nachfrage reagieren. --- **Statuskommunikation** Eine hilfreiche Statusmeldung beantwortet möglichst: - Was ist betroffen? - Welche Auswirkungen sind bekannt? - Was wird aktuell getan? - Gibt es eine Zwischenlösung? - Was müssen Benutzer tun? - Wann folgt die nächste Information? Beispiel: > Seit 10:20 Uhr ist die zentrale Dateiablage für die Standorte Nord und West nicht erreichbar. Das Netzwerkteam untersucht die Verbindung zum Rechenzentrum. Lokal gespeicherte Dateien sind nicht betroffen. Bitte führen Sie keine wiederholten Neustarts durch. Eine nächste Statusmeldung erfolgt spätestens um 11:00 Uhr. --- **Statusmeldung ohne neue technische Erkenntnis** Auch wenn noch keine Lösung vorliegt, kann eine Statusmeldung sinnvoll sein. Beispiel: > Die Analyse läuft weiter. Eine eindeutige Ursache wurde noch nicht bestätigt. Der Hersteller prüft derzeit die Protokolldaten. Die bisher genannte Zwischenlösung bleibt gültig. Die nächste Aktualisierung erfolgt um 16:30 Uhr. Dadurch weiß der Benutzer: - der Vorgang wird weiterhin bearbeitet, - die Organisation hat ihn nicht vergessen, - und wann eine neue Information zu erwarten ist. --- **Kommunikationshäufigkeit an die Situation anpassen** Ein kritischer Incident benötigt häufigere Statusinformationen als eine normale Serviceanfrage. Mögliche Einflussfaktoren: - Auswirkung, - Dringlichkeit, - Anzahl betroffener Benutzer, - Dauer, - Unsicherheit, - verfügbare Zwischenlösung, - und Informationsbedarf der Stakeholder. Zu häufige Meldungen ohne Inhalt können: - Bearbeitung unterbrechen, - Verwirrung erzeugen, - oder wichtige Informationen verdecken. Zu seltene Meldungen erzeugen: - Unsicherheit, - Rückfragen, - Mehrfachmeldungen, - und Vertrauensverlust. --- **Zielgruppengerechte Statusinformationen** Unterschiedliche Stakeholder benötigen unterschiedliche Informationen. | Zielgruppe | Häufig benötigte Information | |---|---| | Benutzer | Auswirkung, Zwischenlösung, nächstes Update | | Service Desk | bekannte Symptome, betroffene Gruppen, freigegebene Formulierung | | technisches Team | Diagnose, Protokolle, Hypothesen, nächste Maßnahmen | | Service Owner | Serviceauswirkung, Risiken, Fortschritt und Entscheidungen | | Führungskräfte | Geschäftsfolgen, erwartete Dauer, Risiken und benötigte Entscheidungen | | Lieferant | technische Nachweise, Vertragsbezug, Priorität und gewünschte Unterstützung | | Informationssicherheit | mögliche Daten- oder Sicherheitsauswirkung und gesicherte Beweise | Eine technische Arbeitsnotiz sollte nicht unverändert an alle Benutzer gesendet werden. --- **Kommunikation bei geplanten Wartungen** Eine Wartungsankündigung sollte möglichst enthalten: - betroffener Service, - Datum und Zeitraum, - erwartete Auswirkung, - betroffene Benutzer oder Standorte, - Grund der Maßnahme, - notwendige Vorbereitung, - mögliche Alternative, - Kontaktweg, - und Abschlussinformation. Beispiel: > Am Sonntag, 9. August 2026, wird der zentrale Dateiservice zwischen 08:00 und 10:00 Uhr aktualisiert. In diesem Zeitraum können Dateien vorübergehend nicht geöffnet oder gespeichert werden. Bitte schließen Sie geöffnete Dateien bis 07:45 Uhr. Eine Statusmeldung erfolgt nach Abschluss der Arbeiten. Ungeeignet: > Am Wochenende finden Wartungsarbeiten statt. --- **Unterschied zwischen Information und Handlungsaufforderung** Benutzer sollten erkennen können, ob sie: - nur informiert werden, - etwas vorbereiten, - eine Handlung ausführen, - oder eine Rückmeldung geben müssen. Beispiel: > **Keine Handlung erforderlich:** Die Aktualisierung wird automatisch installiert. Beispiel: > **Handlung erforderlich:** Speichern Sie Ihre Arbeit und starten Sie das Gerät spätestens am Freitag neu. Eine klare Kennzeichnung reduziert Missverständnisse. --- **Schriftliche Kommunikation** Schriftliche Kommunikation sollte: - einen eindeutigen Betreff, - eine verständliche Einleitung, - die wichtigste Aussage zuerst, - klare Handlungsschritte, - Zeitangaben, - und einen erkennbaren Ansprechpartner enthalten. Ungeeigneter Betreff: > Update Besser: > Status zum Ausfall der Dateiablage – nächstes Update um 15:00 Uhr Ungeeignete Nachricht: > Wir arbeiten daran. Besser: > Die Dateiablage ist weiterhin für die Standorte Nord und West nicht erreichbar. Der Provider untersucht aktuell die externe Verbindung. Lokal gespeicherte Dateien können weiterverwendet werden. Die nächste Statusmeldung erfolgt spätestens um 15:00 Uhr. --- **E-Mail-Kommunikation strukturieren** Eine praktische Struktur: - Anlass - aktueller Status - Auswirkung - Handlung des Benutzers - nächster Schritt - nächste Rückmeldung - Vorgangsnummer Beispiel: > Guten Tag, > > der Zugriff auf das Abrechnungssystem ist seit 09:40 Uhr für mehrere Benutzer eingeschränkt. > > Das Anwendungsteam untersucht aktuell die Anmeldung. Bitte ändern Sie Ihr Kennwort nicht erneut, da das Problem nicht durch ein falsches Kennwort verursacht wird. > > Eine nächste Statusmeldung erfolgt spätestens um 11:00 Uhr. > > Vorgangsnummer: 4711 --- **Chat-Kommunikation** Im Chat sollten Nachrichten: - kurz, - aber vollständig, - in sinnvoller Reihenfolge, - und ohne unklare Abkürzungen geschrieben werden. Ungeeignet: > ok warte Besser: > Ich prüfe jetzt, ob bereits eine allgemeine Störung bekannt ist. Das dauert voraussichtlich wenige Minuten. Bitte lassen Sie das Chatfenster geöffnet. Bei längerer Unterbrechung: > Die Prüfung dauert länger als erwartet. Ich erstelle einen Vorgang und informiere Sie per E-Mail weiter. Ihre Vorgangsnummer lautet 4711. --- **Telefonische Kommunikation** Beim Telefonkontakt sind besonders wichtig: - aktiv zuhören, - langsam und deutlich sprechen, - technische Schritte einzeln erklären, - Pausen zulassen, - Ergebnisse wiederholen lassen, - und wichtige Vereinbarungen am Ende zusammenfassen. Beispielabschluss: > Wir haben die Anwendung neu angemeldet und der Zugriff funktioniert wieder. Ich dokumentiere die Lösung unter Vorgang 4711. Sollte die Meldung erneut erscheinen, rufen Sie bitte nicht alle Schritte erneut durch, sondern nennen Sie direkt diese Vorgangsnummer. --- **Persönlicher Kontakt** Beim Vor-Ort-Support sollte der Mitarbeiter: - sich vorstellen, - erklären, was geprüft wird, - Zustimmung vor Eingriffen einholen, - sensible Inhalte beachten, - und das Ergebnis dokumentieren. Ungeeignet: - ohne Erklärung Maus und Tastatur übernehmen, - private oder vertrauliche Dateien öffnen, - oder den Arbeitsplatz verlassen, ohne das Ergebnis zu erklären. --- **Kommunikation bei Remote-Support** Vor einer Remote-Sitzung sollte geklärt werden: - welches zugelassene Werkzeug verwendet wird, - ob der Benutzer zustimmt, - welche Aktionen durchgeführt werden, - und wie die Sitzung beendet wird. Geeignete Formulierung: > Mit Ihrer Zustimmung starte ich eine Remote-Sitzung. Sie können alle Schritte sehen und die Sitzung jederzeit beenden. Ich prüfe nur die Einstellungen der betroffenen Anwendung. Bitte schließen Sie vorher vertrauliche Dokumente. Während der Sitzung: > Ich öffne jetzt die Anwendungsprotokolle. Dabei werden keine persönlichen Dateien verändert. Nach der Sitzung: > Die Remote-Verbindung ist beendet. Wir haben nur die Anwendungseinstellungen angepasst. Bitte testen Sie jetzt den vollständigen Arbeitsschritt. --- **Fehler nicht vorschnell dem Benutzer zuschreiben** Ungeeignet: - Sie haben das falsch gemacht. - Das Problem sitzt vor dem Bildschirm. - Sie hätten die Anleitung lesen müssen. - Warum haben Sie das nicht früher gemeldet? Besser: - Die bisherige Anleitung beschreibt den neuen Anmeldeweg nicht ausreichend. - Der Zugriff wurde mit einer Rolle beantragt, die für diese Tätigkeit nicht ausreicht. - Die Fehlermeldung macht nicht deutlich, welcher Schritt erforderlich ist. - Für die weitere Untersuchung ist wichtig, wann das Problem erstmals aufgetreten ist. Auch wenn ein Bedienfehler vorliegt, sollte die Organisation prüfen: - War die Funktion verständlich? - War die Anleitung auffindbar? - War die Fehlermeldung hilfreich? - Ist derselbe Fehler bei mehreren Benutzern aufgetreten? - Kann das Design verbessert werden? --- **Keine Schuldzuweisung zwischen Teams** Ungeeignet gegenüber Benutzern: - Das Netzwerkteam hat wieder etwas falsch konfiguriert. - Der Hersteller ist schuld. - Die Entwicklung bekommt das nie richtig hin. - Dafür ist der Service Desk nicht verantwortlich. Besser: - Das Netzwerkteam prüft aktuell die Verbindung. - Wir haben den Hersteller einbezogen und koordinieren die weitere Bearbeitung. - Die Ursache liegt möglicherweise in der aktuellen Anwendungsversion und wird untersucht. - Der Vorgang benötigt zusätzliche technische Analyse. Ich sorge für die Weitergabe und halte Sie informiert. Interne Ursachen können später sachlich untersucht werden. Die Benutzerkommunikation sollte nicht zur öffentlichen Schuldzuweisung verwendet werden. --- **Umgang mit verärgerten Benutzern** Ein verärgerter Benutzer kann: - laut sprechen, - wiederholt nachfragen, - Vorwürfe äußern, - oder eine sofortige Lösung verlangen. Eine mögliche Vorgehensweise: 1. nicht sofort in die Verteidigung gehen 2. ausreden lassen, soweit möglich 3. Auswirkung anerkennen 4. Sachverhalt zusammenfassen 5. konkrete nächste Schritte nennen 6. realistische Grenzen erklären 7. vereinbaren, wann die nächste Information erfolgt Beispiel: > Ich verstehe, dass der wiederholte Ausfall Ihren Monatsabschluss erheblich behindert. Der Service ist noch nicht stabil. Das Anwendungsteam und der Hersteller arbeiten gemeinsam an der Ursache. Als Zwischenlösung können Sie die Buchungen derzeit über Arbeitsplatz 4 durchführen. Ich informiere Sie spätestens um 13:00 Uhr erneut. --- **Nicht jede Beschwerde persönlich nehmen** Benutzerfrust richtet sich häufig gegen: - die Unterbrechung, - wiederholte Fehler, - fehlende Informationen, - oder die Organisation insgesamt. Mitarbeiter sollten Beschwerden ernst nehmen, ohne jede Aussage als persönliche Bewertung zu übernehmen. Gleichzeitig muss respektloses Verhalten nicht unbegrenzt akzeptiert werden. --- **Grenzen bei aggressivem oder beleidigendem Verhalten** Professioneller Umgang gilt für alle Beteiligten. Mitarbeiter müssen: - Beleidigungen, - Drohungen, - Diskriminierung, - oder gezielte Einschüchterung nicht akzeptieren. Eine mögliche Reaktion: > Ich möchte Ihr Anliegen gern weiter bearbeiten. Dafür benötige ich ein respektvolles Gespräch. Wenn die Beleidigungen fortgesetzt werden, muss ich den Kontakt beenden und nach unserem Eskalationsverfahren weitergeben. Bei konkreten Drohungen oder Sicherheitsrisiken sind die internen Sicherheits- und Eskalationsverfahren anzuwenden. > **Wichtig** > > Empathie bedeutet nicht, missbräuchliches Verhalten hinzunehmen. --- **Deeskalation** Hilfreiche Maßnahmen: - ruhig und langsam sprechen, - nicht gleichzeitig widersprechen und erklären, - keine Ironie verwenden, - konkrete Fakten nennen, - Handlungsmöglichkeiten anbieten, - Verantwortung für den nächsten Schritt übernehmen, - und unbelegten Versprechen widerstehen. Ungeeignet: > Wenn Sie mich nicht ausreden lassen, kann ich auch nichts machen. Besser: > Ich möchte die Situation lösen. Dafür fasse ich kurz zusammen, was bereits bekannt ist, und erkläre anschließend die zwei möglichen nächsten Schritte. --- **Umgang mit Beschwerden** Eine Beschwerde kann Hinweise liefern auf: - schlechte Kommunikation, - unklare Erwartungen, - wiederkehrende Störungen, - ungeeignete Prozesse, - fehlende Barrierefreiheit, - oder nicht erfüllte Serviceziele. Eine Beschwerde sollte: - sachlich erfasst, - nicht abgewertet, - entsprechend ihrer Bedeutung eskaliert, - und hinsichtlich möglicher Verbesserungen ausgewertet werden. Geeignete Antwort: > Vielen Dank für die konkrete Rückmeldung. Sie haben an drei aufeinanderfolgenden Tagen keine angekündigte Statusmeldung erhalten. Ich dokumentiere das als Abweichung und lasse zusätzlich prüfen, warum die Kommunikationsintervalle nicht eingehalten wurden. Ungeeignet: > Dafür müssen Sie sich an jemand anderen wenden. --- **Umgang mit Führungskräften und wichtigen Stakeholdern** Hierarchische Positionen können besondere Informationsbedürfnisse erzeugen. Sie dürfen jedoch nicht automatisch: - Sicherheitskontrollen aufheben, - Prioritätskriterien ersetzen, - oder andere kritische Incidents verdrängen. Professionelle Kommunikation: > Ich verstehe die geschäftliche Bedeutung Ihres Termins. Für eine höhere Priorität benötige ich noch die Information, ob weitere Benutzer oder ein zentraler Geschäftsprozess betroffen sind. Die Identitätsprüfung für den Zugriff muss trotzdem vollständig durchgeführt werden. Bei Bedarf kann eine hierarchische Eskalation erfolgen. --- **Umgang mit wiederholten Nachfragen** Wiederholte Nachfragen können ein Hinweis sein auf: - fehlende Statusinformationen, - unklare Zuständigkeit, - schlechte Erwartungssteuerung, - oder hohe geschäftliche Auswirkungen. Die Antwort sollte nicht nur lauten: > Wir arbeiten noch daran. Besser: > Seit der letzten Meldung wurde der Fehler auf die Verbindung zwischen Anwendung und Datenbank eingegrenzt. Das Datenbankteam prüft aktuell die fehlgeschlagenen Verbindungen. Eine Wiederherstellungszeit liegt noch nicht vor. Die nächste Statusmeldung erfolgt um 16:00 Uhr. --- **Umgang mit nicht erfüllbaren Forderungen** Manche Forderungen können nicht erfüllt werden, weil sie: - technisch unmöglich, - nicht genehmigt, - sicherheitswidrig, - rechtlich unzulässig, - oder außerhalb des Serviceumfangs sind. Eine professionelle Ablehnung enthält möglichst: 1. klare Aussage 2. verständliche Begründung 3. mögliche Alternative 4. gegebenenfalls Eskalations- oder Antragsweg Beispiel: > Ich kann die Mehrfaktor-Authentifizierung nicht dauerhaft deaktivieren, da sie für administrative Konten verbindlich ist. Ich kann jedoch prüfen, ob ein zugelassenes alternatives Authentifizierungsverfahren für Ihr Gerät eingerichtet werden kann. --- **„Nein“ verständlich erklären** Ungeeignet: > Das geht nicht. Prozess ist Prozess. Besser: > Der direkte Zugriff kann nicht eingerichtet werden, weil dadurch personenbezogene Daten ohne die erforderliche Berechtigung sichtbar wären. Möglich ist stattdessen ein Antrag auf die freigegebene Leseberechtigung. Ich sende Ihnen das passende Serviceangebot. --- **Kommunikation bei Fehlern der Serviceorganisation** Hat die Serviceorganisation einen Fehler verursacht, sollte sie: - den Fehler nicht verschleiern, - die bekannte Auswirkung benennen, - notwendige Korrekturen erklären, - und keine unbelegten Schuldzuweisungen vornehmen. Beispiel: > Bei der gestrigen Änderung wurde eine benötigte Berechtigungsgruppe nicht übernommen. Dadurch konnten zwölf Benutzer die Anwendung heute Morgen nicht öffnen. Die Gruppe wurde wiederhergestellt. Wir prüfen zusätzlich, warum der Test die fehlende Berechtigung nicht erkannt hat. Ungeeignet: > Es gab ein kleines technisches Problem. wenn die tatsächliche Auswirkung erheblich war. --- **Entschuldigung professionell verwenden** Eine Entschuldigung sollte konkret und angemessen sein. Geeignet: > Es tut uns leid, dass Sie trotz der zugesagten Rückmeldung keine Statusinformation erhalten haben. Weniger hilfreich: > Entschuldigung für die Unannehmlichkeiten. ohne zu benennen, was geschehen ist. Eine Entschuldigung ersetzt nicht: - Korrektur, - Information, - Verantwortung, - oder Verbesserung. --- **Kommunikation bei Major Incidents** Bei einem Major Incident müssen Informationen: - konsistent, - zeitnah, - zielgruppengerecht, - und kontrolliert bereitgestellt werden. Zu klären sind: - Wer darf offizielle Statusmeldungen veröffentlichen? - Welche Informationen sind bestätigt? - Welche Vermutungen dürfen nicht veröffentlicht werden? - Welche Zielgruppen benötigen welche Details? - Welche Intervalle gelten? - Welche Kanäle werden verwendet? - Wer genehmigt sensible Aussagen? - Wie wird die Abschlussinformation gestaltet? --- **Inhalt einer Major-Incident-Meldung** Eine erste Meldung kann enthalten: - betroffener Service, - bekannte Auswirkung, - Beginn, - aktueller Bearbeitungsstatus, - mögliche Zwischenlösung, - und nächster Aktualisierungszeitpunkt. Beispiel: > Seit 08:45 Uhr ist die zentrale Anmeldung für mehrere interne Anwendungen gestört. Benutzer können sich teilweise nicht neu anmelden. Bereits aktive Sitzungen sind nach aktuellem Stand nicht betroffen. Die zuständigen Identitäts- und Anwendungsteams untersuchen die Ursache. Bitte ändern Sie Ihr Kennwort nicht. Die nächste Statusmeldung erfolgt spätestens um 09:30 Uhr. --- **Keine unbestätigten Ursachen veröffentlichen** Ungeeignet: > Der Ausfall wurde durch einen Cyberangriff verursacht. wenn dies noch nicht bestätigt ist. Besser: > Die Ursache wird untersucht. Das Informationssicherheitsteam ist vorsorglich einbezogen. Eine bestätigte Sicherheitsauswirkung liegt derzeit noch nicht vor. --- **Abschlusskommunikation nach einem Major Incident** Eine Abschlussmeldung kann enthalten: - Zeitpunkt der Wiederherstellung, - bestätigten aktuellen Zustand, - mögliche Restbeeinträchtigungen, - notwendige Benutzeraktionen, - und Hinweis auf weitere Untersuchung. Beispiel: > Der Anmeldeservice ist seit 12:20 Uhr wieder verfügbar. Neue Anmeldungen funktionieren nach aktueller Prüfung. Benutzer mit einer weiterhin angezeigten Fehlermeldung sollen die Anwendung einmal vollständig schließen und erneut öffnen. Die zugrunde liegende Ursache wird noch untersucht. Weitere Erkenntnisse fließen in die nachgelagerte Incident-Überprüfung ein. --- **Kommunikation bei Sicherheitsvorfällen** Bei möglichen Sicherheitsvorfällen gelten häufig besondere Regeln. Der Service Desk sollte: - nur freigegebene Aussagen verwenden, - keine unbestätigten Details verbreiten, - sensible Informationen schützen, - keine Beweise verändern, - und das zuständige Sicherheitsteam einbeziehen. Ungeeignet: > Ihr Konto wurde gehackt. Besser: > Es gibt Hinweise auf eine möglicherweise unberechtigte Anmeldung. Das Sicherheitsteam prüft den Vorgang. Bitte verwenden Sie das betroffene Konto bis zur weiteren Rückmeldung nicht. Die genaue Kommunikation richtet sich nach dem Sicherheitsverfahren der Organisation. --- **Datenschutz in der Kommunikation** Kommunikation kann personenbezogene oder vertrauliche Informationen enthalten. Zu vermeiden sind: - unnötige Empfänger, - vollständige vertrauliche Dokumente, - Kennwörter, - private Gesundheitsinformationen ohne erforderlichen Zweck, - technische Zugangsdaten, - oder interne Sicherheitsdetails in offenen Kanälen. Vor dem Versand sollte geprüft werden: - Wer benötigt die Information? - Ist der Kanal geeignet? - Kann der Inhalt minimiert werden? - Müssen Anhänge geschützt werden? - Ist die Identität des Empfängers ausreichend geprüft? --- **Adressaten und Verteiler prüfen** Besonders bei größeren Störungen kann eine falsche Empfängerliste: - vertrauliche Informationen offenlegen, - unnötige Unruhe erzeugen, - oder Personen mit irrelevanten Meldungen überlasten. Vor dem Versand: - Empfängerkreis prüfen, - offene und verborgene Empfänger angemessen verwenden, - automatische Verteiler verstehen, - und gegebenenfalls Freigabe einholen. --- **Barrierearme Kommunikation** Professionelle Kommunikation berücksichtigt unterschiedliche Fähigkeiten und Voraussetzungen. Mögliche Maßnahmen: - verständliche Sprache, - gut strukturierte Texte, - ausreichende Kontraste in Statusseiten, - keine Information ausschließlich durch Farbe, - Untertitel oder Textalternativen, - zugängliche Dokumente, - alternative Kontaktkanäle, - und ausreichend Zeit für Rückfragen. Ein Benutzer darf nicht als schwierig bewertet werden, weil er: - mehr Zeit benötigt, - einen anderen Kommunikationskanal bevorzugt, - technische Anweisungen wiederholen lässt, - oder Unterstützung aufgrund einer Einschränkung benötigt. --- **Mehrsprachige Kommunikation** Bei mehrsprachigen Benutzern sollte geklärt sein: - welche Sprachen unterstützt werden, - welche Sprache für technische Dokumentation gilt, - wann Übersetzung verwendet wird, - und wie kritische Aussagen überprüft werden. Automatische Übersetzung kann unterstützen, muss aber bei wichtigen Inhalten kontrolliert werden. Besonders kritisch sind: - Sicherheitsanweisungen, - rechtliche Hinweise, - Datenverlustwarnungen, - und technische Maßnahmen mit hohem Risiko. --- **Kulturelle Unterschiede** Kommunikationsstile können sich unterscheiden hinsichtlich: - Direktheit, - Höflichkeitsformen, - Umgang mit Hierarchie, - Rückfragen, - und Ausdruck von Kritik. Professioneller Umgang bedeutet: - keine vorschnellen Bewertungen, - verständliche und respektvolle Sprache, - und Nachfrage bei möglichen Missverständnissen. Es dürfen keine Annahmen über Fähigkeiten oder Verhalten allein aufgrund von: - Herkunft, - Sprache, - Alter, - Geschlecht, - Position, - oder anderen persönlichen Merkmalen getroffen werden. --- **Interne Kommunikation zwischen Supportgruppen** Benutzerkommunikation kann nur zuverlässig sein, wenn auch die interne Kommunikation funktioniert. Eine interne Übergabe sollte enthalten: - betroffenen Service, - genaue Auswirkung, - bisherige Diagnose, - Ergebnisse, - bereits durchgeführte Maßnahmen, - relevante Zeitpunkte, - gewünschte Unterstützung, - und aktuelle Benutzerkommunikation. Ungeeignet: > Bitte übernehmen. Besser: > Seit 10:05 Uhr können alle zwölf Benutzer am Standort Süd keine Verbindung zum Warenwirtschaftssystem herstellen. DNS und allgemeine Internetverbindung funktionieren. Der Zugriff auf TCP-Port 443 der Zieladresse schlägt nur vom Standort Süd fehl. Der Standort-Router wurde nicht neu gestartet. Benötigt wird die Prüfung von Standorttunnel und Firewall. Nächste Benutzerinformation ist für 11:00 Uhr angekündigt. --- **Kommunikation bei Schicht- oder Teamübergaben** Eine Übergabe sollte nicht nur den Ticketstatus nennen. Hilfreich sind: - aktueller technischer Zustand, - bekannte Auswirkungen, - offene Hypothesen, - nächste geplante Maßnahme, - ausstehende Entscheidung, - Kommunikationszeitpunkt, - und verantwortliche Rolle. Beispiel: > Der Service ist teilweise wiederhergestellt. Neue Benutzer können sich anmelden, bestehende Sitzungen zeigen vereinzelt Fehler. Der Hersteller prüft noch die Protokolle. Keine weitere Konfigurationsänderung ohne Abstimmung mit der Incident-Koordination. Nächstes Benutzerupdate um 18:00 Uhr. --- **Kommunikationsverantwortung klären** Bei mehreren beteiligten Teams sollte festgelegt sein: - Wer spricht mit dem Benutzer? - Wer veröffentlicht allgemeine Statusmeldungen? - Wer kommuniziert mit dem Lieferanten? - Wer informiert Führungskräfte? - Wer dokumentiert technische Details? - Wer genehmigt sensible Aussagen? Andernfalls entstehen möglicherweise: - widersprüchliche Informationen, - doppelte Nachrichten, - unbestätigte Aussagen, - oder lange Kommunikationslücken. --- **Vorlagen und Textbausteine** Vorlagen können Kommunikation: - beschleunigen, - vereinheitlichen, - und bei Stress unterstützen. Sie dürfen jedoch nicht unreflektiert verwendet werden. Eine Vorlage sollte angepasst werden an: - tatsächlichen Sachverhalt, - Zielgruppe, - Auswirkungen, - nächsten Schritt, - und aktuellen Zeitpunkt. Ungeeigneter Textbaustein: > Ihr Anliegen wurde erfolgreich gelöst. wenn der Benutzer die Funktion noch nicht bestätigt hat. Besser: > Die technische Funktion wurde wiederhergestellt. Bitte prüfen Sie, ob Sie den zuvor fehlgeschlagenen Arbeitsschritt jetzt vollständig durchführen können. --- **Beispiel: Eingangsbestätigung** > Ihre Meldung wurde unter der Vorgangsnummer 4711 erfasst. > > Betroffener Service: zentrale Dateiablage > Gemeldete Auswirkung: Dateien lassen sich nicht öffnen > > Der Service Desk prüft zunächst, ob eine allgemeine Störung vorliegt. Die nächste Rückmeldung erfolgt innerhalb der vereinbarten Servicezeit. --- **Beispiel: Rückfrage** > Für die weitere Analyse benötigen wir noch folgende Information: > > - genaue Fehlermeldung, > - Zeitpunkt des letzten erfolgreichen Zugriffs, > - und die Angabe, ob weitere Benutzer betroffen sind. > > Bitte senden Sie keine Kennwörter oder vollständigen vertraulichen Dokumente. --- **Beispiel: Weiterleitung** > Die erste Prüfung zeigt, dass zusätzliche Analyse durch das Netzwerkteam erforderlich ist. > > Der Vorgang wurde mit den bisherigen Prüfergebnissen weitergegeben. Der Service Desk bleibt Ihr Kontaktpunkt. Die nächste Statusmeldung erfolgt spätestens um 14:00 Uhr. --- **Beispiel: Verzögerung** > Die Bearbeitung dauert länger als zunächst erwartet, weil zusätzliche Protokolldaten des Herstellers benötigt werden. > > Die Störung wird weiterhin aktiv untersucht. Die bisherige Zwischenlösung bleibt gültig. Die nächste Aktualisierung erfolgt spätestens um 16:30 Uhr. --- **Beispiel: Wiederherstellung** > Der Zugriff auf die Anwendung ist wiederhergestellt. > > Bitte melden Sie sich erneut an und führen Sie den zuvor fehlgeschlagenen Arbeitsschritt vollständig durch. Teilen Sie uns anschließend kurz mit, ob die Funktion wieder wie erwartet arbeitet. --- **Beispiel: Abschluss** > Sie haben bestätigt, dass die Anwendung wieder vollständig nutzbar ist. > > Ursache war eine fehlerhafte Berechtigungszuordnung. Diese wurde korrigiert. Der Vorgang 4711 wird abgeschlossen. > > Die wiederkehrende Ursache wird zusätzlich durch Problem Management untersucht. --- **Beispiel: Ablehnung mit Alternative** > Die gewünschte lokale Administratorberechtigung kann nicht dauerhaft freigegeben werden, da sie nicht dem Sicherheitsstandard für Arbeitsplatzgeräte entspricht. > > Für die Installation der benötigten Anwendung steht ein genehmigtes Serviceangebot zur Verfügung. Ich habe Ihnen den entsprechenden Antrag verlinkt. --- **KI-gestützte Kommunikation** KI kann unterstützen bei: - Zusammenfassung von Gesprächen, - Übersetzung, - Vorschlägen für Antworten, - Anpassung der Detailtiefe, - Erkennung wiederkehrender Themen, - und Erstellung erster Statusentwürfe. Mögliche Vorteile: - schnellere Erstellung, - einheitlichere Formulierungen, - Unterstützung mehrsprachiger Kontakte, - und Entlastung bei wiederkehrenden Mitteilungen. Mögliche Risiken: - erfundene Fakten, - falsche technische Aussagen, - unangemessener Ton, - Weitergabe vertraulicher Daten, - falsche Priorisierung, - und fehlender Bezug zur tatsächlichen Situation. --- **KI-Ausgaben prüfen** Vor dem Versand einer KI-gestützten Antwort sollte geprüft werden: - Stimmen alle Tatsachen? - Ist der aktuelle Status korrekt? - Ist die Zielgruppe richtig angesprochen? - Sind keine vertraulichen Informationen enthalten? - Werden keine unbelegten Zusagen gemacht? - Ist die technische Anleitung sicher? - Ist der nächste Schritt eindeutig? - Ist eine menschliche Übergabe erforderlich? > **Sicherheitsrelevant** > > KI darf keine unbekannten technischen Schritte oder produktiven Änderungen allein aufgrund plausibel klingender Formulierungen veranlassen. --- **Automatisierte Nachrichten menschlich und präzise gestalten** Ungeeignet: > Ihr Ticket wurde aktualisiert. Besser: > Das Anwendungsteam hat die Analyse übernommen. Für die weitere Prüfung werden derzeit die Anmeldeprotokolle ausgewertet. Sie müssen aktuell nichts weiter tun. Die nächste Statusmeldung erfolgt spätestens um 12:00 Uhr. Automatisierung darf nicht nur interne Statuscodes an Benutzer weitergeben. --- **Kommunikationsqualität messen** Mögliche Informationen: | Messgröße | Mögliche Aussage | |---|---| | Benutzerzufriedenheit | allgemeine Wahrnehmung des Kontakts | | wahrgenommener Aufwand | wie aufwendig der Kontakt für den Benutzer war | | Verständlichkeit | ob Informationen und Anweisungen verstanden wurden | | Vertrauen | ob Benutzer Aussagen und Zusagen als verlässlich erleben | | Wiederholungskontakte | mögliche Hinweise auf fehlende Information oder Lösung | | eingehaltene Statuszusagen | Zuverlässigkeit der Kommunikation | | Anzahl notwendiger Rückfragen | mögliche Hinweise auf unvollständige Erfassung | | Beschwerden | Hinweise auf wiederkehrende Kommunikationsprobleme | | Kanalwechsel | möglicher Hinweis auf ungeeigneten Erstkanal | | Wiedereröffnungsquote | möglicher Hinweis auf voreiligen Abschluss | | Benutzerbestätigung | ob das gewünschte Ergebnis tatsächlich erreicht wurde | Eine einzelne Zufriedenheitszahl reicht nicht aus. --- **Feedback richtig einordnen** Eine negative Bewertung kann sich beziehen auf: - den Mitarbeiter, - die lange Wartezeit, - die technische Produktqualität, - fehlende Befugnisse, - einen Lieferanten, - oder eine organisatorische Vorgabe. Vor Schlussfolgerungen sollte geprüft werden: - Was genau wurde bewertet? - War die Frage verständlich? - Wie hoch ist die Rücklaufquote? - Bestehen wiederkehrende Muster? - Welche Verbesserung ist tatsächlich möglich? Mitarbeiter sollten nicht allein anhand einzelner emotionaler Bewertungen beurteilt werden. --- **Kommunikationsreviews** Eine Organisation kann ausgewählte Kontakte prüfen auf: - sachliche Richtigkeit, - Verständlichkeit, - Respekt, - Vollständigkeit, - Datenschutz, - Sicherheitskonformität, - Erwartungssteuerung, - und Ergebnisorientierung. Die Prüfung sollte der: - Entwicklung, - Schulung, - und Verbesserung dienen. Sie sollte nicht ausschließlich als Überwachung oder Fehlersuche wahrgenommen werden. --- **Gesundheit und emotionale Belastung der Mitarbeiter** Service-Desk-Mitarbeiter bearbeiten möglicherweise: - verärgerte Benutzer, - kritische Ausfälle, - Datenverluste, - Sicherheitsvorfälle, - und dauerhaft hohe Kontaktmengen. Organisationen sollten berücksichtigen: - ausreichende Pausen, - erreichbare Führungskräfte, - Unterstützung nach belastenden Kontakten, - klare Grenzen bei missbräuchlichem Verhalten, - realistische Kennzahlen, - und angemessene Personalkapazität. > **Merke** > > Empathische Kommunikation ist qualifizierte Arbeit. > > Sie benötigt Fähigkeiten, Unterstützung und ausreichende Arbeitsbedingungen. --- **Continual Improvement der Kommunikation** Verbesserungsmöglichkeiten können entstehen durch: - Benutzerfeedback, - Beschwerden, - wiederholte Rückfragen, - abgebrochene Kontakte, - unklare Statusmeldungen, - Fehler in Vorlagen, - und Erfahrungen aus Major Incidents. Mögliche Verbesserungen: - Textbausteine überarbeiten, - Fachbegriffe vereinfachen, - Statusintervalle definieren, - Kommunikationsverantwortung klären, - Mitarbeiterschulungen durchführen, - Portaltexte verbessern, - sichere Übersetzungsunterstützung bereitstellen, - und Zielgruppen genauer unterscheiden. --- **Praxisbeispiel: keine Anmeldung möglich** Benutzer: > Ich kann mich nicht anmelden und brauche die Anwendung sofort. Ungeeignete Antwort: > Haben Sie Ihr Kennwort falsch eingegeben? Bessere Antwort: > Ich verstehe, dass Sie die Anwendung gerade benötigen. Ich kläre zunächst, ob Ihr Konto oder der gesamte Anmeldedienst betroffen ist. Welche Meldung wird angezeigt und können sich Kollegen in derselben Anwendung anmelden? Nach der Prüfung: > Weitere Benutzer sind ebenfalls betroffen. Ihr Kennwort ist deshalb wahrscheinlich nicht die Ursache. Der Identitätsdienst wird bereits untersucht. Bitte ändern Sie Ihr Kennwort nicht erneut. Die nächste Statusmeldung erfolgt um 10:30 Uhr. --- **Praxisbeispiel: verlorene Datei** Benutzer: > Meine Datei ist weg. Da waren zwei Tage Arbeit drin. Ungeeignet: > Sie hätten regelmäßig speichern müssen. Bessere Antwort: > Ich verstehe, dass der mögliche Verlust sehr belastend ist. Bitte speichern oder überschreiben Sie an diesem Speicherort zunächst nichts weiter. Ich prüfe, ob eine frühere Version oder Sicherung verfügbar ist. Wann und unter welchem Namen wurde die Datei zuletzt gespeichert? Wichtig: - keine Schuldzuweisung, - keine unbelegte Wiederherstellungszusage, - und keine Maßnahmen, die vorhandene Wiederherstellungsmöglichkeiten gefährden. --- **Praxisbeispiel: angekündigter Rückruf wurde vergessen** Benutzer: > Mir wurde gestern ein Rückruf versprochen. Es hat sich niemand gemeldet. Geeignete Antwort: > Das hätte nicht passieren dürfen. Der zugesagte Rückruf wurde nicht durchgeführt. Ich prüfe jetzt den aktuellen Bearbeitungsstand und übernehme die Koordination. Sie erhalten spätestens um 11:00 Uhr eine Rückmeldung von mir, auch wenn die technische Analyse dann noch läuft. Zusätzlich sollte intern geprüft werden: - Warum ging die Zusage verloren? - War kein Verantwortlicher eingetragen? - Fehlte eine Erinnerung? - War die Kapazität unzureichend? - Muss der Arbeitsablauf verbessert werden? --- **Praxisbeispiel: Sicherheitskontrolle wird unter Zeitdruck abgelehnt** Benutzer: > Ich bin in fünf Minuten im Termin. Setzen Sie das Kennwort einfach zurück. Geeignete Antwort: > Ich verstehe den Zeitdruck. Die Identitätsprüfung kann ich trotzdem nicht überspringen, weil dadurch ein fremdes Konto übernommen werden könnte. Wir führen jetzt das vorgesehene schnelle Prüfverfahren durch. Danach kann ich die Zurücksetzung sofort veranlassen. --- **Praxisbeispiel: technisches Team benötigt mehr Zeit** Statusmeldung: > Die Anwendung ist weiterhin nicht verfügbar. Das Team hat die Datenbankverbindung als Fehlerbereich eingegrenzt, aber die genaue Ursache ist noch nicht bestätigt. Eine Wiederherstellungsschätzung liegt deshalb noch nicht vor. Die alternative Anwendung kann weiterhin verwendet werden. Nächste Statusmeldung: 15:30 Uhr. Diese Meldung: - benennt den aktuellen Stand, - vermeidet eine ungesicherte Zeitangabe, - nennt eine Alternative, - und gibt einen verbindlichen nächsten Informationszeitpunkt. --- **Praxisbeispiel: Ticket wurde voreilig geschlossen** Benutzer: > Das Ticket ist geschlossen, aber der Fehler ist noch da. Geeignete Antwort: > Danke für den Hinweis. Der Vorgang wurde zu früh geschlossen. Ich öffne ihn erneut und dokumentiere, dass die technische Maßnahme das Benutzerproblem nicht gelöst hat. Wir prüfen jetzt den vollständigen Arbeitsschritt noch einmal. Anschließend sollte untersucht werden: - Wurde nur eine technische Komponente geprüft? - Fehlte die Benutzerbestätigung? - Belohnte eine Kennzahl den schnellen Abschluss? - War die Abschlussregel unklar? --- **Typische Kommunikationsfehler** **Fehler 1: Zu früh eine Lösung vermuten** Der Benutzer wird in eine falsche Diagnoserichtung gelenkt. --- **Fehler 2: Fachbegriffe ohne Erklärung verwenden** Der Benutzer versteht weder Situation noch nächsten Schritt. --- **Fehler 3: Auswirkungen verharmlosen** Die technische Störung wirkt klein, blockiert aber einen wichtigen Arbeitsprozess. --- **Fehler 4: Unbelegte Zeitversprechen geben** Vertrauen sinkt, sobald die Zusage nicht eingehalten wird. --- **Fehler 5: Nur bei neuen Erkenntnissen informieren** Benutzer bleiben lange ohne Status. --- **Fehler 6: „Ich gebe es weiter“ ohne Verantwortung** Nächster Schritt, Kommunikationsweg und Zuständigkeit bleiben unklar. --- **Fehler 7: Benutzer oder andere Teams beschuldigen** Zusammenarbeit und Vertrauen werden beschädigt. --- **Fehler 8: Empathie mit Zustimmung verwechseln** Prioritäts-, Sicherheits- oder Genehmigungsregeln werden unnötig aufgegeben. --- **Fehler 9: Standardtexte unverändert senden** Die Nachricht passt nicht zur tatsächlichen Situation. --- **Fehler 10: Technische Wiederherstellung mit Benutzer-Outcome verwechseln** Ticket wird geschlossen, obwohl die Tätigkeit weiterhin nicht möglich ist. --- **Fehler 11: Verärgerte Benutzer persönlich angreifen** Die Situation eskaliert weiter. --- **Fehler 12: Beleidigungen unbegrenzt akzeptieren** Mitarbeiterschutz und professionelle Grenzen fehlen. --- **Fehler 13: Sensible Informationen im falschen Kanal teilen** Datenschutz- oder Sicherheitsrisiken entstehen. --- **Fehler 14: Widersprüchliche Meldungen mehrerer Teams** Es fehlt eine geklärte Kommunikationsverantwortung. --- **Fehler 15: KI-Entwürfe ungeprüft versenden** Falsche Aussagen oder unangemessene Formulierungen erreichen Benutzer. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker kommunizieren nicht nur innerhalb des Service Desk. Sie kommunizieren ebenfalls bei: - technischen Rückfragen, - Remote-Support, - Changes, - Wartungsarbeiten, - Incidents, - Lieferantenkontakten, - und Übergaben an andere Teams. Eine gute technische Rückmeldung sollte beantworten: - Was wurde geprüft? - Welches Ergebnis liegt vor? - Was ist weiterhin unbekannt? - Welche Auswirkungen bestehen? - Was ist der nächste Schritt? - Wer übernimmt ihn? - Wann ist mit einer Rückmeldung zu rechnen? - Welche Benutzerinformation ist geeignet? Ungeeignete technische Rückmeldung: > Server läuft wieder. Besser: > Der Anwendungsdienst wurde um 14:20 Uhr wiederhergestellt. Technische Funktionsprüfungen sind erfolgreich. Zwei Testbenutzer konnten sich anmelden und Datensätze speichern. Der Service wird bis 16:00 Uhr verstärkt überwacht. Die Ursache wird noch durch Problem Management untersucht. --- **30-Sekunden-Prüfung einer Benutzerkommunikation** 1. **Zielgruppe:** Mit wem kommuniziere ich? 2. **Anliegen:** Was benötigt die Person tatsächlich? 3. **Auswirkung:** Welche Arbeit oder welches Outcome ist betroffen? 4. **Verständlichkeit:** Ist die Sprache für die Zielgruppe geeignet? 5. **Fakten:** Welche Aussagen sind bestätigt? 6. **Unsicherheit:** Was ist noch nicht bekannt? 7. **Handlung:** Was geschieht als Nächstes? 8. **Verantwortung:** Wer übernimmt die nächste Aufgabe? 9. **Zeit:** Wann folgt die nächste Information? 10. **Sicherheit:** Darf der Inhalt über diesen Kanal geteilt werden? 11. **Ergebnis:** Wie wird das Outcome bestätigt? 12. **Respekt:** Ist die Formulierung sachlich und professionell? --- **Checkliste für ein professionelles Gespräch** - [ ] Wurde freundlich und eindeutig eröffnet? - [ ] Wurde die Identität bei Bedarf geprüft? - [ ] Konnte der Benutzer das Anliegen zunächst beschreiben? - [ ] Wurden gezielte Rückfragen gestellt? - [ ] Wurden Auswirkungen und Umfang verstanden? - [ ] Wurde das Verstandene zusammengefasst? - [ ] Wurden Fachbegriffe erklärt oder vermieden? - [ ] Wurde der nächste Schritt beschrieben? - [ ] Wurden keine unbelegten Zusagen gemacht? - [ ] Wurde ein nächster Informationszeitpunkt genannt? - [ ] Wurde das Ergebnis aus Benutzersicht geprüft? - [ ] Wurde der Kontakt klar abgeschlossen? --- **Checkliste für schriftliche Nachrichten** - [ ] Ist der Betreff eindeutig? - [ ] Steht die wichtigste Information am Anfang? - [ ] Ist der betroffene Service genannt? - [ ] Sind bekannte Auswirkungen beschrieben? - [ ] Sind Fakten und Vermutungen getrennt? - [ ] Ist eine Handlung des Benutzers eindeutig gekennzeichnet? - [ ] Ist der nächste Schritt genannt? - [ ] Ist der nächste Statuszeitpunkt angegeben? - [ ] Sind technische Begriffe für die Zielgruppe verständlich? - [ ] Sind Empfänger und Kanal datenschutzgerecht? - [ ] Wurden vertrauliche Details entfernt? - [ ] Ist die Vorgangsnummer enthalten? --- **Checkliste für Statusmeldungen** - [ ] Was ist betroffen? - [ ] Seit wann besteht die Situation? - [ ] Welche Auswirkungen sind bekannt? - [ ] Welche Bearbeitung läuft? - [ ] Welche Informationen sind bestätigt? - [ ] Gibt es eine Zwischenlösung? - [ ] Müssen Benutzer etwas tun? - [ ] Wann folgt die nächste Meldung? - [ ] Ist die Zielgruppe richtig gewählt? - [ ] Ist die Aussage mit der Incident-Koordination abgestimmt? - [ ] Wurden Sicherheits- und Datenschutzanforderungen beachtet? --- **Checkliste für schwierige Gespräche** - [ ] Bleibt die eigene Stimme ruhig und sachlich? - [ ] Wurde die Auswirkung anerkannt? - [ ] Wurde nicht vorschnell widersprochen? - [ ] Wurden Fakten und nächste Schritte genannt? - [ ] Wurden klare Grenzen erklärt? - [ ] Werden Sicherheitskontrollen nicht umgangen? - [ ] Wurde ein realistischer nächster Zeitpunkt vereinbart? - [ ] Ist bei Beleidigungen oder Drohungen eine Eskalation vorgesehen? - [ ] Benötigt der Mitarbeiter nach dem Kontakt Unterstützung? - [ ] Muss die Beschwerde oder das Muster ausgewertet werden? --- **Checkliste vor dem Abschluss eines Vorgangs** - [ ] Wurde das ursprüngliche Anliegen erneut betrachtet? - [ ] Ist die technische Funktion wiederhergestellt? - [ ] Kann der Benutzer den vollständigen Arbeitsschritt durchführen? - [ ] Wurde das Ergebnis bestätigt? - [ ] Sind offene Risiken oder Einschränkungen kommuniziert? - [ ] Wurde die Lösung verständlich dokumentiert? - [ ] Sind weitere Maßnahmen eindeutig zugeordnet? - [ ] Muss Problem Management einbezogen werden? - [ ] Muss ein Wissensartikel aktualisiert werden? - [ ] Muss eine Verbesserung erfasst werden? --- **Checkliste für KI-gestützte Kommunikation** - [ ] Wurde der Text von einer zuständigen Person geprüft? - [ ] Sind alle technischen Aussagen korrekt? - [ ] Entspricht der Status dem aktuellen Vorgang? - [ ] Werden keine Ursachen erfunden? - [ ] Werden keine unbelegten Zeitangaben gemacht? - [ ] Ist die Sprache respektvoll und zielgruppengerecht? - [ ] Sind keine vertraulichen Daten enthalten? - [ ] Sind Handlungsanweisungen sicher? - [ ] Ist ein menschlicher Kontaktweg vorhanden? - [ ] Wird die Verwendung der KI entsprechend den Vorgaben der Organisation gesteuert? --- **Schnellreferenz für Formulierungen** | Situation | Geeignete Formulierung | |---|---| | Auswirkung anerkennen | Ich verstehe, dass die Störung Ihren Arbeitsablauf gerade vollständig blockiert. | | Verständnis prüfen | Ich fasse kurz zusammen, damit ich nichts übersehen habe. | | Ursache unbekannt | Die genaue Ursache ist noch nicht bestätigt. | | keine Lösungszeit bekannt | Eine verlässliche Wiederherstellungszeit liegt noch nicht vor. | | nächste Rückmeldung | Sie erhalten spätestens um 14:00 Uhr eine weitere Statusmeldung. | | Weiterleitung | Ich binde das Netzwerkteam mit den bisherigen Prüfergebnissen ein. | | Verantwortung behalten | Der Service Desk bleibt Ihr Kontaktpunkt und informiert Sie weiter. | | Sicherheitsregel erklären | Die Identitätsprüfung kann ich aus Sicherheitsgründen nicht überspringen. | | Alternative anbieten | Als Zwischenlösung können Sie derzeit Arbeitsplatz 4 verwenden. | | Ergebnis prüfen | Können Sie den zuvor fehlgeschlagenen Arbeitsschritt jetzt vollständig durchführen? | | Fehler eingestehen | Der zugesagte Rückruf ist nicht erfolgt. Ich übernehme jetzt die weitere Koordination. | | respektvolle Grenze | Ich bearbeite Ihr Anliegen gern weiter, benötige dafür aber ein Gespräch ohne Beleidigungen. | --- **Zusammenfassende Darstellung** > Benutzer schildert ein Anliegen > ↓ > aufmerksam zuhören und Auswirkung verstehen > ↓ > gezielt nachfragen > ↓ > das Verstandene zusammenfassen > ↓ > Situation fachlich und verständlich einordnen > ↓ > nächsten Schritt und Verantwortung erklären > ↓ > realistische Erwartungen und Statuszeitpunkt vereinbaren > ↓ > regelmäßig, ehrlich und zielgruppengerecht informieren > ↓ > technisches Ergebnis und Benutzer-Outcome prüfen > ↓ > Kontakt professionell abschließen > ↓ > Feedback, Beschwerden und Kommunikationsprobleme verbessern --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.2 Kontaktkanäle und Erreichbarkeit - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Knowledge Management - Relationship Management - Service Level Management - Information Security Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [ITIL: The ongoing relevance of the service desk in an AI world](https://www.itil.com/Itil-News-and-Announcements/service-desk-relevance-ai-world) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) - [ITIL: ITIL Service Version 5 – An enterprise-wide approach to service thinking](https://www.itil.com/Itil-News-and-Announcements/itil-service-version-5) - [ITIL: ITIL Experience – Version 5](https://www.itil.com/professionals/certifications/ITIL-Experience-Version-5) - [ITIL: ITIL Experience Version 5 – Making digital technology feel as good as it functions](https://www.itil.com/Itil-News-and-Announcements/itil-experience-version-5) - [ITIL: How ITIL Experience Version 5 puts user experience at the core of service and availability](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-experience-user-experience) - [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) **Offiziell bestätigter Stand** Die offiziellen ITIL- und PeopleCert-Quellen bestätigen: - Der Service Desk stellt einen zentralen Kontaktpunkt zwischen Service Provider und Benutzern bereit und unterstützt eine wirksame Kommunikation. - Service-Desk-Mitarbeiter benötigen überdurchschnittliche Kommunikationsfähigkeiten und müssen Gespräche an unterschiedliche Kenntnisse und Bedürfnisse der Benutzer anpassen. - Empathie und Verständnis des Benutzerkontexts sind wesentliche Fähigkeiten moderner Service-Desk-Arbeit. - ITIL Version 5 stärkt die Betrachtung von Benutzer- und Kundenerfahrung innerhalb des digitalen Produkt- und Service-Managements. - Eine technisch funktionierende Leistung kann trotzdem eine unzureichende Erfahrung erzeugen. - Kommunikation während Störungen beeinflusst Vertrauen, Wahrnehmung und Serviceerfahrung. - KI kann Kommunikation, Zusammenfassung, Übersetzung und Personalisierung unterstützen, benötigt aber Governance, menschliche Kontrolle und definierte Übergaberegeln. - Menschliche Kommunikation bleibt besonders bei komplexen, emotional belastenden und unsicheren Situationen wichtig. **Einordnung** Die auf dieser Seite dargestellten: - Gesprächsstrukturen, - Formulierungsbeispiele, - Statusvorlagen, - Deeskalationshinweise, - Checklisten, - Kommunikationsregeln, - und Praxisbeispiele sind herstellerneutrale redaktionelle Empfehlungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Skripte und keine für jede Organisation verbindlichen Kommunikationsabläufe dar. Die konkrete Kommunikation muss angepasst werden an: - Zielgruppe, - Kanal, - Service, - Auswirkung, - Sicherheitsanforderungen, - Datenschutz, - organisatorische Rollen, - und die jeweils bestätigte Informationslage. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Service-Desk-Guidance **Fachlicher Stand:** August 2026 # 3.4 Tickets vollständig erfassen und kategorisieren > **Kurz erklärt** > > Ein Ticket dokumentiert einen Kontakt, eine Störung, eine Anfrage oder eine andere zu bearbeitende Arbeitseinheit. > > Ein gutes Ticket macht nachvollziehbar: > > - wer Unterstützung benötigt, > - welcher Service betroffen ist, > - was beobachtet wurde, > - welche Auswirkungen bestehen, > - seit wann die Situation besteht, > - was bereits geprüft oder durchgeführt wurde, > - wer aktuell verantwortlich ist, > - welcher nächste Schritt notwendig ist, > - und welches Ergebnis erreicht wurde. > > Die Kategorisierung ordnet den Vorgang so ein, dass: > > - die richtige Bearbeitung gefunden, > - geeignetes Wissen angezeigt, > - ähnliche Vorgänge erkannt, > - Berichte erstellt, > - und Verbesserungsmöglichkeiten sichtbar > > werden können. > > ITIL schreibt kein universelles Ticketformular, kein verpflichtendes Kategoriemodell und keinen für alle Organisationen identischen Ticketstatus vor. > > Felder, Kategorien und Arbeitsabläufe müssen zu den Services, Wertströmen, Risiken und Informationsbedürfnissen der jeweiligen Organisation passen. --- **Warum eine gute Ticketqualität wichtig ist** Ein Ticket ist nicht nur eine technische Notiz. Es unterstützt unter anderem: - Kommunikation, - Priorisierung, - Diagnose, - Weiterleitung, - Eskalation, - Zusammenarbeit, - Nachvollziehbarkeit, - Messung, - Wissensmanagement, - Problem Management, - Lieferantensteuerung, - und Continual Improvement. Unvollständige oder unklare Tickets führen häufig zu: - wiederholten Rückfragen, - unnötigen Übergaben, - falscher Priorisierung, - längeren Wartezeiten, - doppelter Arbeit, - ungeeigneten Lösungsversuchen, - fehlender Benutzerkommunikation, - und schlechter Auswertbarkeit. Beispiel für ein unzureichendes Ticket: > Drucker geht nicht. Daraus ist nicht erkennbar: - welcher Drucker betroffen ist, - welcher Benutzer Unterstützung benötigt, - welche Tätigkeit blockiert ist, - welche Fehlermeldung erscheint, - ob weitere Benutzer betroffen sind, - ob ein alternativer Drucker verfügbar ist, - und was bereits geprüft wurde. Eine bessere Erfassung könnte lauten: > Seit etwa 08:20 Uhr können alle vier Arbeitsplätze im Warenausgang keine Versandetiketten über Drucker WD-ET-01 ausgeben. Normale Bürodrucker funktionieren. Am Etikettendrucker wird „Druckauftrag nicht verfügbar“ angezeigt. Der Drucker ist eingeschaltet und im Netzwerk erreichbar. Die Druckwarteschlange enthält zwölf offene Aufträge. Der Versandprozess ist derzeit unterbrochen und es besteht kein zugelassener Ersatzdrucker. > **Merke** > > Je besser ein Ticket den tatsächlichen Arbeits- und Servicekontext beschreibt, desto weniger muss die nächste bearbeitende Person erneut erfragen. --- **Ticket ist ein praktischer Sammelbegriff** Der Begriff **Ticket** wird in vielen ITSM-Werkzeugen als allgemeine Bezeichnung für einen dokumentierten Vorgang verwendet. Je nach Inhalt kann ein Ticket beispielsweise repräsentieren: - einen Incident, - einen Service Request, - eine Frage, - eine Beschwerde, - eine Sicherheitsmeldung, - eine Aufgabe, - einen Problem Record, - einen Change, - oder einen Lieferantenfall. Diese Vorgangsarten besitzen unterschiedliche Zwecke. | Vorgangsart | Typischer Zweck | |---|---| | **Kontakt** | Interaktion mit einem Benutzer oder Stakeholder dokumentieren | | **Incident** | negative Serviceauswirkung behandeln und Service wiederherstellen | | **Service Request** | vorgesehene Benutzeranfrage erfüllen | | **Problem** | Ursache oder mögliche Ursache von Incidents untersuchen | | **Change** | eine Änderung bewerten, autorisieren und kontrolliert steuern | | **Security Incident** | mögliches oder bestätigtes Sicherheitsereignis behandeln | | **Aufgabe** | abgegrenzte Tätigkeit innerhalb eines größeren Vorgangs durchführen | | **Lieferantenfall** | externe Unterstützung oder vertragliche Leistung anfordern | > **Wichtig** > > Nicht jedes Ticket ist ein Incident. > > Nicht jede Benutzerfrage ist ein Service Request. > > Die richtige Vorgangsart beeinflusst Bearbeitung, Verantwortung, Messung und Abschlusskriterien. --- **Kontakt, Ticket und zugrunde liegender Vorgang unterscheiden** Ein Benutzerkontakt und ein Ticket sind nicht immer identisch. Beispiel: 1. Ein Benutzer meldet telefonisch einen Ausfall. 2. Der Service Desk erstellt ein Incident-Ticket. 3. Drei weitere Benutzer melden dasselbe Problem per Chat. 4. Diese Kontakte werden mit dem bereits bestehenden Incident verknüpft. 5. Ein technisches Team erhält eine zugehörige Diagnoseaufgabe. 6. Ein Provider erhält einen verknüpften Lieferantenfall. 7. Nach der Wiederherstellung wird ein Problem Record für die Ursachenanalyse eröffnet. Es bestehen damit: - mehrere Benutzerkontakte, - ein gemeinsamer Incident, - technische Teilaufgaben, - ein Lieferantenfall, - und möglicherweise ein nachgelagertes Problem. > **Merke** > > Nicht jede neue Meldung benötigt einen vollständig unabhängigen Incident. > > Mehrere Kontakte können dieselbe zugrunde liegende Störung betreffen. --- **Ziel der Ticket-Erfassung** Die Erfassung soll ausreichende Informationen bereitstellen, damit die Organisation: - das Anliegen versteht, - die richtige Vorgangsart bestimmt, - Auswirkungen und Dringlichkeit bewertet, - geeignete Fähigkeiten einbindet, - Fortschritt und Kommunikation nachvollzieht, - das Ergebnis überprüft, - und relevante Erkenntnisse weiterverwendet. Das Ziel ist nicht: - möglichst viele Felder auszufüllen, - jeden technischen Wert zu speichern, - oder Benutzer mit einem umfangreichen Formular zu belasten. > **Grundsatz** > > Es sollen so viele Informationen wie notwendig und so wenige wie möglich erfasst werden. --- **Ein mögliches Mindestset an Ticketinformationen** Abhängig von Vorgangsart und Organisation können folgende Informationen sinnvoll sein: | Information | Zweck | |---|---| | **Vorgangsnummer** | eindeutige Referenz | | **Erstellungszeitpunkt** | zeitliche Nachvollziehbarkeit | | **Meldekanal** | Herkunft und Kommunikationskontext | | **meldende Person** | Kontakt und Rückfragen | | **betroffene Person oder Gruppe** | tatsächliche Auswirkung bestimmen | | **betroffener Service** | serviceorientierte Einordnung | | **kurzer Titel** | schnelle verständliche Übersicht | | **Beschreibung** | Situation und Beobachtung dokumentieren | | **Beginn** | zeitliche Einordnung der Beeinträchtigung | | **Auswirkung** | Umfang und Geschäftsbezug | | **Dringlichkeit** | zeitliche Bedeutung | | **Priorität** | organisatorisch bestimmte Bearbeitungsreihenfolge | | **Kategorie** | Zuordnung und Auswertung | | **aktueller Status** | Bearbeitungsstand | | **verantwortliche Rolle oder Gruppe** | aktuelles Ownership | | **bisherige Maßnahmen** | doppelte Arbeit vermeiden | | **Ergebnisse der Maßnahmen** | Diagnose nachvollziehen | | **nächster Schritt** | Bearbeitung fortsetzen | | **Kommunikationszeitpunkt** | Benutzerinformation sicherstellen | | **Lösung oder Erfüllung** | Ergebnis dokumentieren | | **Abschlussbestätigung** | tatsächliches Outcome prüfen | | **verknüpfte Vorgänge** | Zusammenhänge sichtbar machen | Nicht jede Vorgangsart benötigt alle Felder. Ein einfacher Informationskontakt benötigt möglicherweise deutlich weniger Daten als ein kritischer Incident. --- **Meldende Person und betroffener Benutzer unterscheiden** Die Person, die ein Ticket meldet, ist nicht immer selbst betroffen. Beispiele: - Eine Führungskraft meldet eine Störung für ihr Team. - Die Personalabteilung bestellt einen Arbeitsplatz für einen neuen Mitarbeiter. - Monitoring meldet einen technischen Zustand ohne menschlichen Anrufer. - Ein Kollege meldet den Verlust des Geräts einer anderen Person. - Ein externer Kunde meldet eine Störung für mehrere Benutzer. - Ein Administrator erfasst einen Incident aufgrund eigener Beobachtung. Deshalb können getrennte Felder sinnvoll sein für: - meldende Person, - betroffene Person, - betroffene Organisationseinheit, - betroffenen Standort, - und bevorzugten Kommunikationskontakt. > **Typischer Fehler** > > Das Ticket wird automatisch der meldenden Person zugeordnet, obwohl eine andere Person oder ein ganzer Bereich betroffen ist. --- **Der betroffene Service gehört in den Mittelpunkt** Eine serviceorientierte Erfassung fragt nicht nur: > Welche technische Komponente ist defekt? Sondern zuerst: > Welcher Service oder welche Arbeitsfähigkeit ist beeinträchtigt? Beispiel: Technische Komponente: > Datenbankserver DB-02 Betroffener Service: > Warenwirtschaftssystem Geschäftliche Auswirkung: > Lager kann keine Warenausgänge buchen. Die Komponente kann für Diagnose und technische Zuordnung wichtig sein. Der Service ist jedoch entscheidend für: - Auswirkungen, - Kommunikation, - Serviceziele, - Stakeholder, - und Priorisierung. --- **Service und Configuration Item unterscheiden** | Information | Beispiel | |---|---| | **betroffener Service** | zentraler Dateiservice | | **betroffene Anwendung** | Dokumentenmanagement | | **Configuration Item** | Fileserver FS-03 | | **Asset** | physischer Server mit Inventarnummer | | **Standort** | Berlin-Nord | | **Benutzergruppe** | Buchhaltung | Ein Incident kann mehrere Configuration Items betreffen. Ein einzelnes Configuration Item kann mehrere Services unterstützen. Deshalb sollte das Ticket nicht ausschließlich anhand der vermuteten Komponente eingeordnet werden. --- **Einen guten Tickettitel formulieren** Der Titel sollte die Situation kurz und eindeutig zusammenfassen. Ungeeignete Titel: - Problem - Hilfe - Geht nicht - Dringend - Fehler 4711 - Bitte prüfen - Benutzerproblem - Server Bessere Titel: - Anmeldung am Zeiterfassungssystem nicht möglich - Zentrale Dateiablage am Standort Nord nicht erreichbar - Versandetiketten können im Warenausgang nicht gedruckt werden - Standardsoftware für neuen Arbeitsplatz anfordern - Verdächtige Anmeldung für Benutzerkonto erkannt - Wiederherstellung einer gelöschten Projektdatei prüfen Ein guter Titel enthält häufig: - betroffenen Service oder Arbeitsbereich, - beobachtetes Symptom, - und gegebenenfalls betroffenen Standort oder Umfang. > **Praxistipp** > > Der Titel sollte auch für eine Person verständlich sein, die das Ticket nicht selbst erfasst hat. --- **Symptom statt vermuteter Ursache dokumentieren** Zu Beginn eines Incidents ist die tatsächliche Ursache häufig unbekannt. Ungeeignet: > Firewall blockiert Anwendung. wenn dies nur vermutet wird. Besser: > Anwendung ist vom Standort Süd nicht über HTTPS erreichbar. Andere Standorte sind nach aktueller Prüfung nicht betroffen. Eine Firewall-Regel ist eine mögliche, aber noch nicht bestätigte Ursache. Die Dokumentation sollte unterscheiden zwischen: - Beobachtung, - Messergebnis, - Vermutung, - und bestätigter Ursache. | Art | Beispiel | |---|---| | **Beobachtung** | Benutzer erhält „Verbindung nicht möglich“ | | **Messergebnis** | TCP-Verbindung zu Port 443 schlägt fehl | | **Vermutung** | mögliche Blockierung durch Firewall | | **bestätigte Ursache** | Regel FW-182 wurde beim letzten Change nicht übernommen | > **Merke** > > Eine früh eingetragene Vermutung darf nicht unbemerkt zur scheinbar bestätigten Tatsache werden. --- **Fakten und Bewertungen trennen** Ungeeignet: > Benutzer hat wieder die falsche Anwendung benutzt. Besser: > Der Benutzer öffnete die bisher verwendete Anwendungsversion 4.2. Seit dem Change vom 1. August ist Version 5.0 erforderlich. Die bisherige Verknüpfung auf dem Desktop wurde nicht aktualisiert. Ungeeignet: > Netzwerk ist instabil. Besser: > Zwischen 09:10 Uhr und 09:25 Uhr gingen 18 von 100 ICMP-Paketen verloren. Zwei VoIP-Gespräche wurden in diesem Zeitraum unterbrochen. Sachliche Dokumentation verbessert: - Zusammenarbeit, - technische Analyse, - Nachvollziehbarkeit, - und professionellen Umgang. --- **Die ursprünglichen Benutzerangaben erhalten** Die Beschreibung des Benutzers kann wichtige Hinweise enthalten. Beispiel: > „Beim Speichern erscheint immer die Meldung, dass der Datensatz bereits bearbeitet wird.“ Diese ursprüngliche Beobachtung sollte nicht vollständig durch eine technische Interpretation ersetzt werden. Eine gute Dokumentation kann enthalten: - ursprüngliche Benutzerbeschreibung, - strukturierte Zusammenfassung, - technische Beobachtungen, - und durchgeführte Diagnose. Dadurch bleibt nachvollziehbar: - was der Benutzer erlebt hat, - und wie die Organisation die Situation eingeordnet hat. --- **Zeitangaben vollständig erfassen** Zeitinformationen können für Analyse und Korrelation entscheidend sein. Hilfreiche Angaben: - Beginn der Störung, - Zeitpunkt der Meldung, - letzter bekannter erfolgreicher Zugriff, - Zeitpunkt einer Änderung, - Zeitpunkt einzelner Diagnosemaßnahmen, - Wiederherstellungszeitpunkt, - und Abschlusszeitpunkt. Beispiel: > Letzter erfolgreicher Zugriff: 08:47 Uhr > Erste Fehlermeldung: 08:52 Uhr > Meldung beim Service Desk: 09:03 Uhr > letzter relevanter Change: 07:30 Uhr Diese Informationen können mit: - Monitoring, - Logs, - Changes, - Sicherheitsereignissen, - und Lieferantenmeldungen verglichen werden. > **Typischer Fehler** > > Im Ticket steht nur das Erstellungsdatum. Der tatsächliche Beginn der Beeinträchtigung bleibt unbekannt. --- **Auswirkungen vollständig beschreiben** Die Auswirkungen bestimmen, was der Incident für Benutzer und Organisation bedeutet. Zu erfassen sind möglicherweise: - Anzahl betroffener Benutzer, - betroffene Standorte, - betroffene Geschäftsprozesse, - vollständiger oder teilweiser Ausfall, - verfügbare Zwischenlösung, - mögliche Sicherheitsauswirkung, - möglicher Datenverlust, - Kundenwirkung, - und zeitkritische Termine. Unzureichend: > Ein Benutzer betroffen. Besser: > Betroffen ist der einzige Arbeitsplatz, über den die Produktionsfreigabe durchgeführt werden kann. Ohne Freigabe steht die Fertigungslinie ab 10:00 Uhr still. Ein Ersatzarbeitsplatz ist nicht verfügbar. Das Beispiel zeigt: Die reine Benutzeranzahl beschreibt nicht immer die tatsächliche Auswirkung. --- **Dringlichkeit nicht nur vom Benutzer übernehmen** Benutzer können ihre gewünschte Dringlichkeit mitteilen. Die Organisation muss sie jedoch anhand festgelegter Kriterien bewerten. Ein Benutzer kann beispielsweise „sehr dringend“ auswählen, weil: - er unter Zeitdruck steht, - er eine schnelle Bearbeitung erwartet, - oder die Bedeutung der Auswahl nicht erklärt wurde. Das Ticket sollte deshalb unterscheiden zwischen: - vom Benutzer angegebener Dringlichkeit, - organisatorisch bewerteter Dringlichkeit, - Auswirkung, - und daraus bestimmter Priorität. Die genaue Bewertung wird auf der Seite **3.5 Auswirkungen, Dringlichkeit und Priorität** vertieft. --- **Die Beschreibung sollte den Normalzustand enthalten** Für die Diagnose ist hilfreich zu wissen: - Was sollte normalerweise geschehen? - Was geschieht stattdessen? - Unter welchen Bedingungen tritt der Fehler auf? Beispiel: > Normalerweise wird nach Auswahl von „Auftrag abschließen“ innerhalb weniger Sekunden eine PDF-Rechnung erzeugt. Seit heute 08:30 Uhr bleibt der Ladebildschirm dauerhaft sichtbar. Der Auftrag wird nicht abgeschlossen und es wird keine Fehlermeldung angezeigt. Diese Beschreibung ist aussagekräftiger als: > Rechnung funktioniert nicht. --- **Reproduzierbarkeit dokumentieren** Hilfreiche Angaben: - tritt der Fehler immer oder nur manchmal auf, - bei welchen Schritten tritt er auf, - auf welchen Geräten oder Versionen, - bei welchen Benutzern, - mit welchen Daten, - und unter welchen Bedingungen. Beispiel: 1. Anwendung öffnen 2. Auftrag 4711 auswählen 3. „PDF exportieren“ anklicken 4. Anwendung schließt sich ohne Fehlermeldung Zusätzlich: - tritt bei drei getesteten Aufträgen auf, - nur in Version 5.2, - Webversion nicht betroffen. > **Wichtig** > > Reproduktionsschritte dürfen keine vertraulichen Daten oder unsicheren Handlungen unnötig offenlegen. --- **Bereits durchgeführte Maßnahmen dokumentieren** Das Ticket sollte zeigen: - welche Maßnahme durchgeführt wurde, - wer sie durchgeführt hat, - wann sie durchgeführt wurde, - warum sie durchgeführt wurde, - und welches Ergebnis entstand. Unzureichend: > Neustart gemacht. Besser: > 10:12 Uhr – Anwendungsdienst APP-SVC auf Server APP-02 kontrolliert neu gestartet, nachdem der Prozess nicht mehr auf Health Checks reagierte. Dienst startete erfolgreich. Technischer Health Check ist wieder grün. Benutzeranmeldung schlägt jedoch weiterhin fehl. Dadurch wird deutlich: - der Neustart war technisch erfolgreich, - das ursprüngliche Outcome wurde aber noch nicht erreicht. --- **Maßnahme und Ergebnis getrennt dokumentieren** | Maßnahme | Ergebnis | |---|---| | DNS-Cache geleert | Fehler besteht unverändert | | Anwendung neu gestartet | Anmeldung funktioniert einmalig | | anderes Benutzerkonto getestet | ebenfalls betroffen | | Zugriff über Mobilfunk getestet | funktioniert | | Firewall-Regel geprüft | Regel vorhanden und aktiv | | Provider kontaktiert | externe Störung bestätigt | Diese Trennung verhindert unklare Notizen wie: > Alles geprüft. --- **Chronologische Arbeitsnotizen** Eine chronologische Dokumentation unterstützt: - Schichtübergaben, - Major-Incident-Koordination, - Lieferanteneskalation, - spätere Analyse, - und Auditierbarkeit. Beispiel: > **09:05 Uhr:** Incident durch Service Desk erfasst. Fünf Benutzer betroffen. > **09:12 Uhr:** Allgemeine Statusseite geprüft, keine bekannte Herstellerstörung. > **09:18 Uhr:** Anwendung von Standort Nord und Süd getestet. Nur Nord betroffen. > **09:25 Uhr:** Netzwerkteam eingebunden. > **09:40 Uhr:** Standorttunnel zeigt Paketverlust. Providerfall P-8821 eröffnet. > **10:00 Uhr:** Benutzerstatus aktualisiert. Nächstes Update 10:30 Uhr. Arbeitsnotizen sollten nicht nachträglich so verändert werden, dass wesentliche Entscheidungen oder frühere Zustände nicht mehr nachvollziehbar sind. Korrekturen sollten transparent erfolgen. --- **Interne und externe Notizen unterscheiden** Viele Ticketsysteme bieten: - interne Arbeitsnotizen, - und für Benutzer sichtbare Kommentare. **Interne Arbeitsnotizen** Können enthalten: - technische Diagnose, - Hypothesen, - interne Koordination, - sicher freigegebene Protokollauszüge, - und interne Zuständigkeiten. **Benutzersichtbare Kommentare** Sollten enthalten: - verständlichen Status, - Auswirkungen, - nächste Schritte, - Handlungshinweise, - und nächsten Informationszeitpunkt. > **Sicherheitsrelevant** > > Interne Notizen sind nicht automatisch für jede vertrauliche Information geeignet. > > Zugriffsrechte, Aufbewahrung und Datenklassifizierung müssen berücksichtigt werden. --- **Kategorisierung** Kategorisierung ordnet einen Vorgang nach festgelegten Merkmalen ein. Sie kann unterstützen bei: - automatischer oder manueller Zuweisung, - Anzeige passenden Wissens, - Prioritätsregeln, - Service-Level-Zuordnung, - Erkennung ähnlicher Vorgänge, - Trendanalyse, - Problem Management, - und Continual Improvement. Eine Kategorie sollte einen konkreten Nutzen besitzen. > **Typischer Fehler** > > Kategorien werden nur deshalb angelegt, weil das Werkzeug beliebig viele Ebenen ermöglicht. --- **Ein einfaches Kategoriemodell** Eine mögliche Struktur lautet: > Service → Anliegenart → Symptom Beispiel: > Dateiablage → Incident → Zugriff nicht möglich Weitere Beispiele: - E-Mail → Incident → Nachrichtenversand fehlerhaft - Arbeitsplatz → Service Request → Standardsoftware anfordern - Benutzerkonto → Incident → Konto gesperrt - Netzwerkzugang → Incident → WLAN-Verbindung unterbrochen - Berechtigung → Service Request → Gruppenmitgliedschaft beantragen - Informationssicherheit → Sicherheitsmeldung → verdächtige E-Mail Die konkrete Struktur wird von der Organisation festgelegt. --- **Serviceorientierte und technische Kategorien** **Serviceorientierte Kategorien** Beispiele: - E-Mail und Kalender - Dateiablage - Arbeitsplatz - Netzwerkzugang - Warenwirtschaft - Personalverwaltung - Zeiterfassung Vorteile: - für Benutzer verständlicher, - besserer Bezug zu Serviceauswirkungen, - Unterstützung von Serviceberichten. **Technische Kategorien** Beispiele: - DNS - DHCP - Firewall - Datenbank - Betriebssystem - Speicher - Zertifikat Vorteile: - hilfreich für technische Analyse, - Unterstützung spezialisierter Teams, - technische Trendanalyse. Beide Perspektiven können kombiniert werden. > **Praxistipp** > > Der Benutzer wählt möglichst den betroffenen Service oder sein Anliegen. > > Die technische Einordnung kann während der Bearbeitung ergänzt werden. --- **Benutzerkategorie und interne Kategorie unterscheiden** Ein Portal sollte nicht zwingend dieselben Kategorien anzeigen wie das interne Ticketsystem. Benutzerfreundliche Auswahl: - Ich kann mich nicht anmelden. - Ich benötige Zugriff. - Eine Anwendung funktioniert nicht. - Ich habe eine verdächtige E-Mail erhalten. - Ich möchte Software bestellen. Interne Zuordnung: - Service: Identity and Access - Vorgangsart: Incident - Symptom: MFA fehlgeschlagen - technische Domäne: Entra ID - Supportgruppe: Identity Operations Dadurch muss der Benutzer keine interne IT-Struktur kennen. --- **Mehrere Kategorisierungsdimensionen verwenden** Eine einzige hierarchische Kategorie kann schnell zu groß und unübersichtlich werden. Alternativ können mehrere getrennte Merkmale verwendet werden. | Dimension | Beispiel | |---|---| | **Service** | E-Mail | | **Vorgangsart** | Incident | | **Symptom** | Versand nicht möglich | | **technische Domäne** | Mail Gateway | | **Standort** | Berlin | | **Benutzergruppe** | Vertrieb | | **Sicherheitsbezug** | nein | | **Ursachencode** | Zertifikat abgelaufen | | **Lösungscode** | Zertifikat erneuert | Vorteile: - bessere Auswertung, - weniger tiefe Kategorien, - und flexiblere Zuordnung. Nachteile: - mehr Felder, - höherer Pflegeaufwand, - und mögliche uneinheitliche Eingaben. Deshalb sollten nur tatsächlich benötigte Dimensionen verwendet werden. --- **Symptom-, Ursachen- und Lösungskategorien unterscheiden** Diese Kategorien entstehen zu unterschiedlichen Zeitpunkten. | Kategorie | Zeitpunkt | Beispiel | |---|---|---| | **Symptomkategorie** | bei Erfassung | Anmeldung nicht möglich | | **technische Kategorie** | während Diagnose | Identitätsdienst | | **Ursachenkategorie** | nach Bestätigung | Zertifikat abgelaufen | | **Lösungskategorie** | nach Wiederherstellung | Zertifikat erneuert | Zu Beginn darf nicht so kategorisiert werden, als wäre die Ursache bereits bekannt. > **Typischer Fehler** > > Das Ticket wird bei der ersten Meldung als „Netzwerkfehler“ kategorisiert und bleibt dort, obwohl später ein abgelaufenes Anwendungstoken als Ursache bestätigt wird. --- **Kategorien dürfen geändert werden** Eine erste Kategorisierung ist häufig vorläufig. Während der Bearbeitung können neue Erkenntnisse entstehen. Eine Kategorie sollte geändert werden, wenn: - der betroffene Service falsch erkannt wurde, - die Vorgangsart falsch war, - eine technische Ursache bestätigt wurde, - oder eine genauere Einordnung möglich ist. Die Änderung sollte: - nachvollziehbar, - nach festgelegten Regeln, - und ohne Verlust der ursprünglichen Informationen erfolgen. --- **Kategorie „Sonstiges“ kontrolliert verwenden** Eine Kategorie wie: - Sonstiges, - Allgemein, - Unbekannt, - oder Andere kann notwendig sein. Sie darf jedoch nicht zur dauerhaften Standardkategorie werden. Eine hohe Nutzung kann anzeigen: - Kategorien sind unverständlich, - wichtige Services fehlen, - Mitarbeiterschulung ist unzureichend, - das Portal ist schlecht gestaltet, - oder neue Bedarfsmuster sind entstanden. > **Praxistipp** > > Vorgänge in „Sonstiges“ sollten regelmäßig ausgewertet und bei Bedarf neu kategorisiert werden. --- **Nicht zu viele Kategorieebenen verwenden** Ungeeignetes Beispiel: > IT → Infrastruktur → Netzwerk → Standortnetz → LAN → Switch → Cisco → Modell → Port → Fehler Eine solche Struktur kann: - langsam, - fehleranfällig, - schwer wartbar, - und für Benutzer ungeeignet sein. Eine einfachere Kombination kann ausreichen: - Service: Standortnetzwerk - Symptom: Verbindung unterbrochen - betroffenes CI: Switch SW-N-03 - technische Gruppe: Network Operations > **Grundsatz** > > Die Kategorie sollte die Arbeit unterstützen und nicht selbst zu einer zusätzlichen komplizierten Arbeit werden. --- **Kategorien nicht nach Teams aufbauen** Eine Kategorie wie: - First Level - Netzwerkteam - Serverteam - Anwendungsteam beschreibt organisatorische Zuständigkeit, aber nicht unbedingt den Service oder das Anliegen. Teams können sich verändern. Services und Benutzerbedürfnisse bleiben häufig stabiler. Besser ist: - Service und Anliegen kategorisieren, - zuständige Gruppe daraus ableiten, - und Zuweisungsregeln unabhängig pflegen. --- **Vorgangsart richtig bestimmen** Eine wichtige erste Einordnung ist die Unterscheidung zwischen verschiedenen Vorgangsarten. --- **Incident** Ein Incident liegt vor, wenn eine ungeplante negative Auswirkung auf einen Service behandelt werden muss. Beispiele: - Anwendung ist nicht erreichbar. - vorhandener Zugriff funktioniert nicht. - Druckservice liefert keine Aufträge. - Leistung ist erheblich vermindert. - vorhandene Funktion erzeugt Fehler. --- **Service Request** Ein Service Request ist eine vorgesehene Benutzeranfrage. Beispiele: - Standardsoftware anfordern - neuen Zugriff beantragen - Information zu einem Service erhalten - Arbeitsplatzgerät bestellen - Verteilerliste ändern lassen --- **Frage oder Informationskontakt** Beispiele: - Wann findet die Wartung statt? - Welche Software ist freigegeben? - Wie erreiche ich den Service außerhalb der Geschäftszeit? Eine Frage kann möglicherweise direkt beantwortet werden, ohne einen umfangreichen Request-Wertstrom zu starten. --- **Sicherheitsmeldung** Beispiele: - verdächtige E-Mail - verlorenes Gerät - möglicher unberechtigter Zugriff - versehentliche Datenoffenlegung - ungewöhnliches Anmeldeverhalten Eine Sicherheitsmeldung benötigt möglicherweise: - besondere Zugriffsrechte, - vertrauliche Bearbeitung, - und schnelle Weiterleitung an das Sicherheitsteam. --- **Beschwerde oder Feedback** Beispiele: - zugesagte Rückmeldung wurde nicht eingehalten - Portal ist nicht barrierefrei nutzbar - wiederkehrende Störung beeinträchtigt die Arbeit - Servicebeschreibung ist unverständlich Feedback kann mit einem Incident oder Request verbunden sein, besitzt aber möglicherweise einen eigenen Bearbeitungs- und Verbesserungsweg. --- **Fehleinordnungen korrigieren** Beispiel: Ein Benutzer wählt: > Service Request – Kennwort ändern Während der Erfassung wird erkannt: - Das Konto ist aufgrund eines Fehlers im Identitätsdienst gesperrt. - Mehrere Benutzer sind betroffen. - Die normale Selbstverwaltung funktioniert nicht. Der Vorgang sollte dann möglicherweise als Incident behandelt werden. Ein anderes Beispiel: Der Benutzer meldet: > VPN funktioniert nicht. Die Analyse zeigt: - VPN ist grundsätzlich funktionsfähig. - Der Benutzer besitzt noch keine genehmigte VPN-Berechtigung. Dies kann ein Service Request statt eines Incidents sein. > **Merke** > > Die Formulierung oder Portalwahl des Benutzers bestimmt nicht allein die endgültige Vorgangsart. --- **Duplikate erkennen** Bei größeren Störungen entstehen häufig mehrere Tickets zum selben Incident. Duplikaterkennung verhindert: - parallele Diagnose, - widersprüchliche Maßnahmen, - mehrfache Lieferantenmeldungen, - und unklare Statuskommunikation. Vor dem Erstellen eines neuen Incidents kann geprüft werden: - Ist bereits eine bekannte Störung veröffentlicht? - Existiert ein Incident für denselben Service? - Sind Zeitraum, Standort und Symptom identisch? - Besteht ein gemeinsamer technischer Auslöser? - Handelt es sich tatsächlich um denselben oder nur um einen ähnlichen Fehler? --- **Duplikate nicht einfach löschen** Ein Duplikat kann wichtige Informationen enthalten: - zusätzliche betroffene Benutzer, - weiteren Standort, - abweichendes Symptom, - neue Zeitangabe, - oder besondere Auswirkung. Eine sinnvolle Behandlung kann sein: 1. Kontaktinformationen erhalten 2. Ticket mit dem Haupt-Incident verknüpfen 3. betroffene Person oder Gruppe ergänzen 4. Benutzerkommunikation mit dem Haupt-Incident abstimmen 5. Duplikat nachvollziehbar schließen oder unterordnen --- **Parent-, Child- und Sammel-Incidents** Bei einem größeren Incident kann ein Hauptvorgang verwendet werden. **Haupt-Incident** Enthält: - technische Gesamtkoordination, - zentrale Auswirkung, - gemeinsame Statusinformationen, - und Wiederherstellungsstand. **Verknüpfte Meldungen** Enthalten: - einzelne betroffene Benutzer, - lokale Besonderheiten, - individuelle Rückfragen, - und Bestätigung der Wiederherstellung. Das konkrete Modell hängt vom Ticketsystem und der Organisation ab. --- **Verknüpfungen zwischen Vorgängen** Tickets können miteinander verbunden werden. Beispiele: - Incident wurde durch Change verursacht. - mehrere Incidents gehören zu einem Problem. - Service Request benötigt einen Change. - Incident besitzt einen Lieferantenfall. - Major Incident besitzt mehrere technische Aufgaben. - Sicherheitsmeldung führt zu einem Security Incident. - Knowledge-Artikel dokumentiert eine bekannte Lösung. - Verbesserungsidee entsteht aus einer Incident-Auswertung. Mögliche Beziehungstypen: - verursacht durch - betrifft - Duplikat von - gelöst durch - gehört zu - Folge von - blockiert durch - bekanntes Problem - zugehöriger Change - zugehöriger Knowledge-Artikel > **Wichtig** > > Verknüpfungen sollten eine erkennbare Bedeutung besitzen. > > Eine große Menge unklarer Beziehungen verbessert die Nachvollziehbarkeit nicht. --- **Status eines Tickets** Ein Status zeigt den aktuellen Bearbeitungszustand. Mögliche Status sind beispielsweise: - Neu - Erfasst - In Prüfung - In Bearbeitung - Warten auf Benutzer - Warten auf Lieferant - Warten auf Change - Gelöst - Abgeschlossen - Abgebrochen ITIL schreibt kein universelles Statusmodell vor. Die Organisation muss festlegen: - was jeder Status bedeutet, - wer ihn setzen darf, - welche Verantwortung weiterhin besteht, - ob Zielzeiten weiterlaufen, - und welche Kommunikation ausgelöst wird. --- **„Warten“ benötigt einen Grund und nächsten Schritt** Unzureichend: > Status: Warten Besser: > Warten auf Benutzer – benötigt wird ein Screenshot der genauen Fehlermeldung. Rückmeldung bis 5. August erbeten. Falls keine Antwort erfolgt, wird am 6. August ein weiterer Kontaktversuch durchgeführt. Oder: > Warten auf Lieferant – Providerfall P-8821 wurde um 10:40 Uhr eröffnet. Nächste vertragliche Rückmeldung wird bis 12:40 Uhr erwartet. Interner Ansprechpartner bleibt Network Operations. > **Typischer Fehler** > > Ein Ticket wird auf „Warten“ gesetzt, ohne dass erkennbar ist, worauf gewartet wird und wer den Vorgang wieder aufnimmt. --- **Gelöst und abgeschlossen unterscheiden** Eine Organisation kann zwischen: - technisch oder fachlich gelöst, - und formal abgeschlossen unterscheiden. **Gelöst** - Lösung oder Erfüllung wurde durchgeführt. - Ergebnis wird möglicherweise noch bestätigt oder beobachtet. **Abgeschlossen** - Abschlusskriterien wurden erfüllt. - Dokumentation ist vollständig. - offene Folgeaktivitäten sind zugeordnet. - Benutzer wurde informiert. - Vorgang benötigt keine weitere aktive Bearbeitung. Dieses Modell ist möglich, aber nicht verpflichtend. --- **Automatischer Abschluss** Ein Ticket kann nach einer festgelegten Frist automatisch geschlossen werden. Dabei sollte berücksichtigt werden: - Wurde der Benutzer verständlich informiert? - War die Frist angemessen? - Besteht ein einfacher Weg zur Wiederaufnahme? - Ist der Service technisch überprüft? - Handelt es sich um einen kritischen oder sensiblen Vorgang? - Bestehen offene Folgeaktivitäten? Automatischer Abschluss darf nicht nur dazu dienen, Kennzahlen zu verbessern. --- **Ownership und Zuweisung** Ein Ticket sollte jederzeit eine erkennbare Verantwortung besitzen. Mögliche Felder: - verantwortliche Gruppe, - verantwortliche Person, - Service Owner, - Incident-Koordinator, - und Kommunikationsverantwortlicher. Eine Gruppe allein reicht möglicherweise nicht aus, wenn: - niemand den Vorgang aktiv übernimmt, - keine nächste Aktion geplant ist, - oder mehrere Teams beteiligt sind. > **Merke** > > „Zugewiesen“ bedeutet nicht automatisch „wird bearbeitet“. --- **Weiterleitung benötigt vollständige Informationen** Vor einer Weiterleitung sollte geprüft werden: - Ist der betroffene Service bekannt? - Ist die Auswirkung beschrieben? - Ist die Priorität nachvollziehbar? - Wurden geeignete erste Prüfungen durchgeführt? - Sind Ergebnisse dokumentiert? - Ist die Zielgruppe richtig? - Ist klar, welche Unterstützung benötigt wird? - Bleibt die Benutzerkommunikation geregelt? Ungeeignete Weiterleitung: > Bitte prüfen. Besser: > Alle Benutzer am Standort Nord können seit 09:15 Uhr den zentralen Dateiservice nicht erreichen. DNS-Auflösung und lokale Netzwerkverbindung funktionieren. Der Zugriff auf TCP-Port 445 schlägt fehl. Standort Süd ist nicht betroffen. Benötigt wird die Prüfung des Standorttunnels und der Firewall. Nächste Benutzerstatusmeldung wurde für 10:30 Uhr angekündigt. --- **Ticket-Pingpong erkennen** Ticket-Pingpong entsteht, wenn ein Vorgang mehrfach zwischen Gruppen weitergeleitet wird. Mögliche Ursachen: - Kategorien sind unklar, - Verantwortung ist nicht definiert, - Informationen fehlen, - Teams lehnen Vorgänge ohne Abstimmung ab, - Serviceabhängigkeiten sind unbekannt, - oder die Organisation arbeitet zu stark in Silos. Geeignete Maßnahmen: - warme Übergabe, - gemeinsames Swarming, - klare Zuweisungsregeln, - bessere Serviceinformationen, - und Auswertung häufig weitergeleiteter Tickets. --- **Anhänge, Screenshots und Protokolle** Anhänge können die Diagnose unterstützen. Beispiele: - Screenshot einer Fehlermeldung - gekürzter Logauszug - Export technischer Diagnosedaten - Foto eines Hardwarefehlers - Konfigurationsauszug - Testprotokoll Vor der Speicherung sollte geprüft werden: - Wird der Anhang tatsächlich benötigt? - Enthält er personenbezogene Daten? - Sind Kennwörter, Tokens oder Schlüssel sichtbar? - Enthält er vertrauliche Geschäftsangaben? - Besitzen alle Ticketleser die notwendige Berechtigung? - Wie lange wird der Anhang gespeichert? - Kann eine kleinere oder anonymisierte Auswahl ausreichen? --- **Screenshots richtig verwenden** Ein Screenshot sollte möglichst zeigen: - relevante Fehlermeldung, - Anwendung oder Kontext, - Zeitpunkt, falls wichtig, - und notwendige technische Details. Er sollte möglichst nicht zeigen: - private Nachrichten, - vollständige Kundenlisten, - Kennwörter, - Zugriffstokens, - nicht benötigte personenbezogene Daten, - oder andere vertrauliche Fenster. > **Praxistipp** > > Fordere möglichst nur den benötigten Bildausschnitt an und erkläre, welche sensiblen Inhalte vorher geschlossen oder entfernt werden sollen. --- **Protokolldaten sicher behandeln** Logs können enthalten: - Benutzernamen, - IP-Adressen, - Dateipfade, - Session-IDs, - Tokens, - personenbezogene Informationen, - und interne Architekturdetails. Sie sollten: - nur zweckgebunden verwendet, - angemessen geschützt, - nicht unkontrolliert in offene Kommentare kopiert, - und nach den Vorgaben der Organisation aufbewahrt werden. --- **Kennwörter und Zugangsdaten gehören nicht ins Ticket** Nicht gespeichert werden sollten insbesondere: - Kennwörter, - private Schlüssel, - API-Secrets, - vollständige Zugriffstokens, - Wiederherstellungscodes, - und ungeschützte Zugangsdaten. Erhält der Service Desk solche Informationen, müssen die Sicherheitsverfahren der Organisation angewendet werden. Mögliche Maßnahmen: - Information aus dem sichtbaren Vorgang entfernen oder schützen, - betroffene Zugangsdaten widerrufen, - Benutzer informieren, - und Sicherheitsrolle einbinden. --- **Datenschutz und Datenminimierung** Ein Ticket darf nur Informationen enthalten, die für einen legitimen Zweck benötigt werden. Zu prüfen sind: - Welche personenbezogenen Daten sind notwendig? - Wer darf sie sehen? - Wie lange werden sie gespeichert? - Müssen Daten anonymisiert werden? - Sind besondere Kategorien personenbezogener Daten betroffen? - Ist das Ticket für den gewählten Empfängerkreis geeignet? Ungeeignet: > Vollständige Krankheitsdiagnose eines Mitarbeiters im allgemeinen IT-Ticket. Ausreichend kann je nach Situation sein: > Benutzer benötigt aufgrund einer genehmigten Arbeitsplatzanpassung eine alternative Eingabemöglichkeit. Die verbindlichen Regeln ergeben sich aus den Datenschutz- und Sicherheitsvorgaben der Organisation. --- **Besondere Behandlung von Sicherheitsmeldungen** Sicherheitsbezogene Tickets können besondere Anforderungen besitzen. Beispiele: - eingeschränkter Leserkreis, - separate Sicherheitswarteschlange, - unveränderte Beweissicherung, - besondere Aufbewahrung, - sofortige Eskalation, - und kontrollierte Kommunikation. Ein allgemeiner Service-Desk-Mitarbeiter sollte wissen: - welche Hinweise sicherheitsrelevant sind, - welche Informationen er erfassen darf, - was nicht verändert werden darf, - und an wen der Vorgang weitergegeben wird. --- **Ticket-Erfassung bei einem möglichen Major Incident** Bei einem möglichen Major Incident sind besonders wichtig: - genauer Beginn, - betroffene Services, - betroffene Standorte und Benutzergruppen, - Geschäfts- oder Kundenwirkung, - verfügbare Zwischenlösungen, - letzte Changes, - bisherige Maßnahmen, - beteiligte Teams, - Entscheidungs- und Kommunikationsverantwortung, - und nächster Statuszeitpunkt. Ein kurzer Erstbericht darf zunächst unvollständig sein, wenn schnelles Handeln notwendig ist. Die Informationen müssen anschließend kontrolliert ergänzt werden. > **Grundsatz** > > Schnelle Erfassung und ausreichende Qualität müssen ausbalanciert werden. > > Ein kritischer Incident darf nicht wegen eines umfangreichen Pflichtformulars unnötig verzögert werden. --- **Pflichtfelder** Pflichtfelder können Informationsqualität verbessern. Sie können jedoch auch: - Erfassung verzögern, - falsche Platzhalter erzeugen, - Benutzer überfordern, - oder Mitarbeiter zum Umgehen des Systems verleiten. Ein Feld sollte verpflichtend sein, wenn die Information: - regelmäßig benötigt wird, - zum Erfassungszeitpunkt bekannt sein kann, - und einen erkennbaren Nutzen besitzt. Ungeeignetes Pflichtfeld bei der Ersterfassung: > bestätigte technische Ursache Die Ursache ist zu diesem Zeitpunkt häufig noch unbekannt. Besser: > beobachtetes Symptom --- **Dynamische Formulare** Dynamische Formulare zeigen nur Felder an, die zur gewählten Situation passen. Beispiel: Auswahl: > Verdächtige E-Mail Zusätzliche Felder: - Zeitpunkt des Empfangs - wurde Link geöffnet? - wurde Anhang geöffnet? - betroffener Benutzer - sichere Uploadmöglichkeit Auswahl: > Software anfordern Zusätzliche Felder: - benötigte Anwendung - Gerät - geschäftlicher Zweck - benötigter Zeitpunkt - Genehmigung Dadurch können Formulare kürzer und verständlicher werden. --- **Vorlagen und Ticketmodelle** Für häufige Situationen können Vorlagen verwendet werden. Beispiele: - Benutzerkonto gesperrt - Softwareanforderung - Standortausfall - verlorenes Endgerät - verdächtige E-Mail - Druckerstörung - Datenwiederherstellung - Lieferanteneskalation Eine Vorlage kann enthalten: - notwendige Fragen, - Standardaufgaben, - Zuweisungsregeln, - Kommunikationsvorlagen, - und Abschlusskriterien. Vorlagen müssen regelmäßig geprüft werden. Eine veraltete Vorlage kann falsche Diagnose oder unnötige Schritte fördern. --- **Automatisierte Erfassung** Tickets können automatisch entstehen durch: - Monitoring, - E-Mail, - Portal, - Chatbot, - Endpoint Management, - Sicherheitsplattform, - Cloud-Provider, - oder Schnittstellen. Bei automatischer Erfassung sollte geklärt sein: - Ist die Meldung handlungsrelevant? - Existiert bereits ein Vorgang? - Welcher Service ist betroffen? - Welche Kategorie ist zuverlässig bestimmbar? - Welche Priorität darf automatisch gesetzt werden? - Wer überprüft die Information? - Wie werden Fehlalarme behandelt? - Wann werden Benutzer informiert? > **Merke** > > Automatisch erzeugt bedeutet nicht automatisch richtig kategorisiert oder priorisiert. --- **KI-gestützte Kategorisierung** KI kann Vorschläge erzeugen für: - Vorgangsart, - Kategorie, - betroffenen Service, - ähnliche Tickets, - zuständige Gruppe, - Priorität, - und passende Wissensartikel. Mögliche Vorteile: - schnellere Einordnung, - einheitlichere Kategorien, - weniger manuelle Arbeit, - und Erkennung ähnlicher Formulierungen. Mögliche Risiken: - falsche Zuordnung, - unerkannte Sicherheitsmeldungen, - Verzerrungen durch schlechte Trainingsdaten, - Übernahme veralteter Kategorien, - und fehlende Nachvollziehbarkeit. --- **KI-Ausgaben müssen überprüfbar bleiben** Zu klären ist: - Welche Daten verwendet die KI? - Welche Kategorien darf sie automatisch setzen? - Wann ist menschliche Bestätigung erforderlich? - Wie werden Fehlzuordnungen korrigiert? - Wie wird aus Korrekturen gelernt? - Welche sensiblen Daten werden verarbeitet? - Wer trägt Verantwortung? - Wie wird die Qualität gemessen? Bei kritischen oder sicherheitsrelevanten Vorgängen sollte eine ungeprüfte vollautomatische Einordnung vermieden werden. --- **Kategorien regelmäßig pflegen** Ein Kategoriemodell ist nicht dauerhaft unverändert geeignet. Änderungen entstehen durch: - neue Services, - neue Produkte, - organisatorische Veränderungen, - neue Technologien, - neue Lieferanten, - und Erfahrungen aus der Bearbeitung. Regelmäßig zu prüfen sind: - Welche Kategorien werden kaum verwendet? - Welche Kategorien werden zu häufig verwendet? - Wo entstehen viele Fehlzuordnungen? - Welche Kategorien führen regelmäßig zur falschen Gruppe? - Wo wird häufig „Sonstiges“ gewählt? - Welche neuen Muster sind entstanden? - Sind Begriffe für Benutzer verständlich? - Sind Berichte weiterhin sinnvoll? --- **Kategorisierung und Reporting** Kategorien ermöglichen Auswertungen wie: - häufig betroffene Services, - wiederkehrende Symptome, - hohe Incident-Mengen, - Service-Request-Nachfrage, - häufige Weiterleitungen, - Lieferantenabhängigkeiten, - und Verbesserungspotenzial. Die Aussagekraft hängt von der Datenqualität ab. Unzuverlässige Kategorien erzeugen unzuverlässige Berichte. > **Grundsatz** > > Schlechte Eingangsdaten werden durch ein modernes Dashboard nicht automatisch zu guten Entscheidungsinformationen. --- **Keine falschen Anreize durch Kategorien** Mitarbeiter können Kategorien so wählen, dass: - Zielzeiten günstiger erscheinen, - der Vorgang nicht zur eigenen Gruppe zählt, - oder Kennzahlen besser aussehen. Beispiele: - Incident wird als Service Request erfasst. - hoher Prioritätsfall wird heruntergestuft. - wiederkehrender Incident wird unter wechselnden Kategorien gespeichert. - Ticket wird als „Benutzerfehler“ abgeschlossen, ohne die Ursache zu untersuchen. Governance und Qualitätskontrollen müssen solche Fehlanreize berücksichtigen. --- **Ticketqualität messen** Mögliche Qualitätsmerkmale: - betroffener Service eindeutig, - Titel verständlich, - Symptom vollständig, - Auswirkung nachvollziehbar, - Zeitangaben vorhanden, - Kategorie geeignet, - Vorgangsart korrekt, - Maßnahmen und Ergebnisse dokumentiert, - Ownership sichtbar, - nächster Schritt bekannt, - Benutzerkommunikation nachvollziehbar, - Lösung vollständig, - Abschlusskriterien erfüllt, - und Datenschutz eingehalten. Eine reine Vollständigkeitsquote reicht nicht aus. Ein ausgefülltes Feld kann trotzdem: - falsch, - unverständlich, - veraltet, - oder nutzlos sein. --- **Qualitätsprüfung ohne unnötige Bürokratie** Mögliche Verfahren: - Stichproben, - Peer Review, - Coaching, - automatische Plausibilitätsprüfung, - Auswertung wiedereröffneter Tickets, - Analyse häufiger Rückfragen, - und Prüfung häufig weitergeleiteter Vorgänge. Die Qualitätsprüfung sollte vor allem: - Lernen, - einheitliche Arbeitsweise, - und Verbesserung unterstützen. Sie sollte nicht ausschließlich zur persönlichen Fehlerbewertung verwendet werden. --- **Praxisbeispiel: unvollständiges Incident-Ticket** **Ursprüngliches Ticket** > Titel: Outlook geht nicht > Kategorie: Sonstiges > Priorität: Hoch > Beschreibung: Bitte schnell lösen. **Fehlende Informationen** - betroffener Service - tatsächliches Symptom - betroffener Benutzer - Zeitpunkt - weitere Betroffene - Auswirkung - Fehlermeldung - bereits durchgeführte Maßnahmen - Begründung der Priorität **Verbesserte Erfassung** > **Titel:** E-Mail-Versand über Outlook am Standort Süd nicht möglich > **Service:** E-Mail und Kalender > **Vorgangsart:** Incident > **Symptom:** Nachrichten bleiben im Postausgang > **Beginn:** etwa 09:10 Uhr > **Betroffene:** aktuell sieben Benutzer am Standort Süd > **Auswirkung:** externe Nachrichten können nicht versendet werden; Empfang funktioniert > **Fehlermeldung:** „Verbindung zum Ausgangsserver nicht möglich“ > **Prüfung:** Webmail-Versand funktioniert; Outlook und Geräte wurden nicht verändert > **Zwischenlösung:** Versand über Webmail möglich > **Nächster Schritt:** lokale Outlook- und Netzwerkverbindung prüfen --- **Praxisbeispiel: Incident oder Service Request** Benutzermeldung: > Ich komme nicht auf das Projektlaufwerk. **Möglicher Incident** - Zugriff bestand zuvor. - Berechtigung ist weiterhin zugewiesen. - Laufwerk ist plötzlich nicht erreichbar. - weitere Benutzer sind betroffen. **Möglicher Service Request** - Zugriff bestand noch nie. - Benutzer benötigt eine neue Projektberechtigung. - Genehmigung durch Projektverantwortlichen ist erforderlich. **Mögliche Sicherheitssituation** - Benutzer sieht plötzlich Daten eines fremden Projekts. - unberechtigte Berechtigung muss sofort geprüft werden. Dieselbe Formulierung kann zu unterschiedlichen Vorgangsarten führen. --- **Praxisbeispiel: Duplikate bei einer Störung** Innerhalb von zehn Minuten melden 35 Benutzer: > Dateiablage nicht erreichbar. Geeignete Behandlung: 1. gemeinsamen Incident erkennen 2. betroffene Benutzer und Standorte ergänzen 3. Duplikate mit Haupt-Incident verknüpfen 4. technische Bearbeitung zentral koordinieren 5. allgemeine Statusmeldung veröffentlichen 6. individuelle Sonderauswirkungen gesondert dokumentieren 7. Wiederherstellung für betroffene Gruppen prüfen Ungeeignet: - 35 Teams bearbeiten 35 unabhängige Incidents, - oder alle Meldungen werden gelöscht und wichtige Auswirkungen gehen verloren. --- **Praxisbeispiel: falsche Kategorisierung** Ticket wurde erfasst als: > Netzwerk → WLAN → Verbindungsfehler Die Analyse zeigt: - Netzwerkverbindung funktioniert. - Nur eine Anwendung ist betroffen. - Ursache ist eine abgelaufene Anwendungslizenz. Korrektur: - Service: Fachanwendung - Vorgangsart: Incident - Symptom: Anmeldung nicht möglich - technische Ursache: Lizenz abgelaufen - Lösung: Lizenz erneuert Die ursprüngliche Benutzerbeschreibung und bisherige Diagnose bleiben erhalten. --- **Praxisbeispiel: sicherheitskritischer Anhang** Ein Benutzer hängt einen Screenshot an. Darauf sichtbar: - Fehlermeldung, - Benutzername, - vollständiger Zugriffstoken, - interne Serveradresse, - und Kundendaten. Geeignete Reaktion: - Zugriff auf den Anhang einschränken, - Sicherheitsverfahren anwenden, - Token widerrufen, - unnötige Daten entfernen oder geschützt behandeln, - Benutzer über sichere Übermittlung informieren, - und prüfen, ob eine Datenoffenlegung vorliegt. Das Ticket darf nicht unverändert an große Verteiler oder externe Lieferanten weitergeleitet werden. --- **Typische Fehler bei Ticket-Erfassung und Kategorisierung** **Fehler 1: Titel ohne Aussage** „Problem“, „Hilfe“ oder „Dringend“ ermöglichen keine schnelle Einordnung. --- **Fehler 2: vermutete Ursache als Tatsache** Die Diagnose wird früh auf eine möglicherweise falsche Richtung festgelegt. --- **Fehler 3: nur technische Komponente erfassen** Betroffener Service und Geschäftsbezug bleiben unbekannt. --- **Fehler 4: meldende und betroffene Person verwechseln** Kommunikation und Auswirkung werden falsch zugeordnet. --- **Fehler 5: Kategorie nach Supportteam auswählen** Organisatorische Änderungen machen das Modell unbrauchbar. --- **Fehler 6: zu viele Kategorieebenen** Erfassung wird langsam und fehleranfällig. --- **Fehler 7: „Sonstiges“ als Standard verwenden** Trends und Zuständigkeiten bleiben unsichtbar. --- **Fehler 8: Kategorie nach neuen Erkenntnissen nicht korrigieren** Berichte und Wissenszuordnung bleiben falsch. --- **Fehler 9: Maßnahmen ohne Ergebnis dokumentieren** Es ist nicht erkennbar, ob ein Test erfolgreich war. --- **Fehler 10: interne Abkürzungen ohne Erklärung** Andere Teams und spätere Bearbeiter verstehen die Notizen nicht. --- **Fehler 11: Ticketweiterleitung ohne Kontext** Nächste Gruppe muss die gesamte Situation erneut untersuchen. --- **Fehler 12: Status „Warten“ ohne nächsten Schritt** Der Vorgang bleibt unbegrenzt liegen. --- **Fehler 13: Ticket schließen, sobald eine technische Aktion durchgeführt wurde** Das Benutzer-Outcome wurde noch nicht bestätigt. --- **Fehler 14: Duplikate einfach löschen** Zusätzliche Auswirkungen und Kontaktinformationen gehen verloren. --- **Fehler 15: sensible Daten unkontrolliert speichern** Datenschutz- und Sicherheitsrisiken entstehen. --- **Fehler 16: alle Felder verpflichtend machen** Benutzer und Mitarbeiter tragen Platzhalter oder falsche Werte ein. --- **Fehler 17: KI-Kategorie ungeprüft übernehmen** Kritische oder sicherheitsbezogene Meldungen können falsch eingeordnet werden. --- **Fehler 18: Kategorien nie überarbeiten** Neue Services und veränderte Arbeitsweisen werden nicht berücksichtigt. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker erhalten häufig Tickets aus dem Service Desk oder erstellen selbst technische Vorgänge. Vor Beginn der Bearbeitung sollte geprüft werden: - Welcher Service ist betroffen? - Was ist das tatsächliche Symptom? - Welche Auswirkungen bestehen? - Welche Informationen sind bestätigt? - Welche Vermutungen wurden nur angenommen? - Was wurde bereits geprüft? - Welche Ergebnisse liegen vor? - Welche Systeme und Abhängigkeiten sind betroffen? - Wer besitzt den Vorgang? - Wann erwartet der Benutzer eine Rückmeldung? Während der Bearbeitung sollten dokumentiert werden: - technische Prüfungen, - konkrete Ergebnisse, - Änderungen, - Zeitpunkte, - Risiken, - Rückfallmaßnahmen, - und nächste Schritte. Nach der Bearbeitung sollten dokumentiert werden: - wiederhergestellte Funktion, - Benutzerbestätigung, - technische Ursache, falls bekannt, - dauerhafte oder vorläufige Lösung, - offene Folgeaktivitäten, - und mögliche Verbesserungen. --- **30-Sekunden-Prüfung eines Tickets** 1. **Person:** Wer meldet und wer ist betroffen? 2. **Service:** Welcher Service oder Arbeitsprozess ist betroffen? 3. **Symptom:** Was wurde tatsächlich beobachtet? 4. **Zeit:** Seit wann besteht die Situation? 5. **Auswirkung:** Was kann nicht durchgeführt werden? 6. **Umfang:** Wer oder was ist zusätzlich betroffen? 7. **Einordnung:** Incident, Request, Frage, Feedback oder Sicherheitsmeldung? 8. **Kategorie:** Unterstützt die Kategorie Bearbeitung und Auswertung? 9. **Maßnahmen:** Was wurde bereits durchgeführt? 10. **Ergebnisse:** Was haben die Maßnahmen gezeigt? 11. **Ownership:** Wer ist aktuell verantwortlich? 12. **Nächster Schritt:** Was geschieht als Nächstes? 13. **Kommunikation:** Wann erhält der Benutzer eine Rückmeldung? 14. **Sicherheit:** Enthält das Ticket nur zulässige Informationen? 15. **Abschluss:** Wie wird das tatsächliche Outcome bestätigt? --- **Checkliste für die Ersterfassung** - [ ] Ist die meldende Person bekannt? - [ ] Ist die tatsächlich betroffene Person oder Gruppe bekannt? - [ ] Ist der betroffene Service bestimmt? - [ ] Ist der Tickettitel eindeutig? - [ ] Ist das beobachtete Symptom beschrieben? - [ ] Ist der erwartete Normalzustand bekannt? - [ ] Ist der Beginn der Beeinträchtigung erfasst? - [ ] Sind Auswirkungen und Umfang dokumentiert? - [ ] Ist eine vorhandene Zwischenlösung bekannt? - [ ] Ist die Vorgangsart vorläufig bestimmt? - [ ] Ist die Kategorie verständlich und passend? - [ ] Wurden sensible Daten vermieden? - [ ] Ist der nächste Schritt festgelegt? - [ ] Wurde ein realistischer Informationszeitpunkt genannt? --- **Checkliste für technische Arbeitsnotizen** - [ ] Ist jede Maßnahme mit Zeitpunkt dokumentiert? - [ ] Ist der Zweck der Maßnahme erkennbar? - [ ] Ist das Ergebnis der Maßnahme beschrieben? - [ ] Sind Beobachtung und Vermutung getrennt? - [ ] Sind technische Werte ausreichend präzise? - [ ] Werden interne Abkürzungen erklärt? - [ ] Sind Änderungen und Rückfallmaßnahmen dokumentiert? - [ ] Wurden Zugangsdaten und sensible Inhalte entfernt? - [ ] Ist der nächste technische Schritt erkennbar? - [ ] Kann eine andere Person die Bearbeitung übernehmen? --- **Checkliste vor einer Weiterleitung** - [ ] Ist die Zielgruppe fachlich geeignet? - [ ] Ist der betroffene Service eindeutig? - [ ] Sind Auswirkung und Priorität nachvollziehbar? - [ ] Sind bisherige Maßnahmen dokumentiert? - [ ] Sind Ergebnisse und Fehlermeldungen enthalten? - [ ] Ist klar, welche Unterstützung benötigt wird? - [ ] Sind relevante Anhänge sicher beigefügt? - [ ] Ist die weitere Verantwortung geklärt? - [ ] Ist die Benutzerkommunikation geregelt? - [ ] Wurde unnötiges Ticket-Pingpong vermieden? --- **Checkliste für die Kategorisierung** - [ ] Ist die Vorgangsart korrekt? - [ ] Ist der betroffene Service erfasst? - [ ] Beschreibt die Kategorie das Anliegen statt nur das Team? - [ ] Ist die Symptomkategorie angemessen? - [ ] Wurde keine unbestätigte Ursache als Kategorie verwendet? - [ ] Kann die Kategorie bei neuen Erkenntnissen geändert werden? - [ ] Wird „Sonstiges“ nur begründet verwendet? - [ ] Sind Kategorien für die jeweilige Zielgruppe verständlich? - [ ] Unterstützt die Kategorie Berichte oder Bearbeitung? - [ ] Ist die Anzahl der Kategorieebenen angemessen? --- **Checkliste für Anhänge und sensible Informationen** - [ ] Wird der Anhang tatsächlich benötigt? - [ ] Sind Kennwörter, Tokens und Schlüssel entfernt? - [ ] Sind personenbezogene Daten auf das notwendige Maß reduziert? - [ ] Sind vertrauliche Inhalte geschützt? - [ ] Besitzen nur berechtigte Personen Zugriff? - [ ] Ist der Übertragungsweg geeignet? - [ ] Sind Logdaten ausreichend gekürzt oder anonymisiert? - [ ] Darf der Anhang an Lieferanten weitergegeben werden? - [ ] Sind Aufbewahrungs- und Löschregeln berücksichtigt? - [ ] Muss ein Sicherheitsvorfall eröffnet werden? --- **Checkliste vor dem Abschluss** - [ ] Ist das ursprüngliche Anliegen erneut geprüft worden? - [ ] Ist die technische Funktion wiederhergestellt oder der Request erfüllt? - [ ] Kann der Benutzer den benötigten Arbeitsschritt durchführen? - [ ] Ist die Lösung oder Erfüllung verständlich dokumentiert? - [ ] Sind Ursache und Lösung korrekt kategorisiert, soweit bekannt? - [ ] Sind offene Folgeaufgaben verknüpft? - [ ] Muss ein Problem Record erstellt werden? - [ ] Muss ein Knowledge-Artikel erstellt oder aktualisiert werden? - [ ] Muss eine Verbesserung erfasst werden? - [ ] Wurde der Benutzer über das Ergebnis informiert? - [ ] Sind vertrauliche Daten ordnungsgemäß behandelt? - [ ] Sind die Abschlusskriterien erfüllt? --- **Checkliste für das Kategoriemodell der Organisation** - [ ] Orientieren sich Benutzerkategorien an verständlichen Services und Anliegen? - [ ] Sind interne technische Kategorien getrennt pflegbar? - [ ] Besitzt jede Kategorie einen erkennbaren Nutzen? - [ ] Werden unnötig tiefe Hierarchien vermieden? - [ ] Sind Kategorien nicht ausschließlich an Teams gebunden? - [ ] Können Symptome, Ursachen und Lösungen getrennt erfasst werden? - [ ] Wird die Kategorie „Sonstiges“ regelmäßig ausgewertet? - [ ] Werden Fehlzuordnungen gemessen? - [ ] Werden neue Services und Anforderungen ergänzt? - [ ] Werden veraltete Kategorien entfernt? - [ ] Sind Zuweisungsregeln transparent? - [ ] Werden Benutzer und Bearbeiter bei Änderungen informiert? - [ ] Fließen Erkenntnisse in Continual Improvement ein? --- **Schnellreferenz** | Bereich | Zentrale Frage | |---|---| | **Titel** | Ist die Situation auf einen Blick verständlich? | | **Person** | Wer meldet und wer ist betroffen? | | **Service** | Welche Arbeitsfähigkeit oder Leistung ist beeinträchtigt? | | **Symptom** | Was wurde tatsächlich beobachtet? | | **Zeit** | Wann begann die Situation? | | **Auswirkung** | Was kann nicht durchgeführt werden? | | **Vorgangsart** | Incident, Request, Frage, Feedback oder Sicherheitsmeldung? | | **Kategorie** | Unterstützt sie Bearbeitung, Wissen und Auswertung? | | **Maßnahmen** | Was wurde bereits getan? | | **Ergebnisse** | Was wurde dadurch festgestellt? | | **Ownership** | Wer besitzt den nächsten Schritt? | | **Kommunikation** | Wann erhält der Benutzer die nächste Information? | | **Sicherheit** | Sind Daten und Anhänge angemessen geschützt? | | **Abschluss** | Wurde das tatsächliche Outcome bestätigt? | --- **Zusammenfassende Darstellung** > Benutzerkontakt oder technische Meldung > ↓ > meldende und betroffene Personen bestimmen > ↓ > betroffenen Service und tatsächliches Symptom erfassen > ↓ > Auswirkungen, Umfang und Zeitangaben dokumentieren > ↓ > Vorgangsart und vorläufige Kategorie bestimmen > ↓ > Ownership und nächsten Schritt festlegen > ↓ > Maßnahmen und Ergebnisse chronologisch dokumentieren > ↓ > Kategorie bei neuen Erkenntnissen korrigieren > ↓ > verknüpfte Incidents, Requests, Problems, Changes und Lieferantenfälle sichtbar machen > ↓ > Lösung oder Erfüllung dokumentieren > ↓ > Benutzer-Outcome bestätigen > ↓ > Wissen, Muster und Verbesserungsmöglichkeiten weiterverwenden --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.2 Kontaktkanäle und Erreichbarkeit - 3.3 Benutzerkommunikation und professioneller Umgang - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Problem Management - Knowledge Management - Service Configuration Management - Information Security Management - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [PeopleCert: ITIL 4 Practitioner – Incident Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-incident-management-3684) - [PeopleCert: ITIL 4 Practitioner – Service Request Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-request-management-3690) - [PeopleCert: ITIL 4 Specialist – Monitor, Support and Fulfil](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-monitor-support-and-fulfil-batch-1-3682) - [PeopleCert: ITIL 4 Management Practices 2023](https://www.peoplecert.org/news-and-announcements/2023/itil-4-management-practices-2023) - [PeopleCert ATV: Essential Features to Look for in ITSM Software](https://atv.peoplecert.org/essential-features-to-look-for-in-itsm-software/) - [PeopleCert ATV: ITSM Software for Incident Management](https://atv.peoplecert.org/itsm-software-for-incident-management/) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) - [ITIL: ITIL Service Version 5 – An Enterprise-Wide Approach to Service Thinking](https://www.itil.com/Itil-News-and-Announcements/itil-service-version-5) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) **Offiziell bestätigter Stand** Die offiziellen ITIL- und PeopleCert-Quellen bestätigen: - Service Desk, Incident Management und Service Request Management bleiben zentrale ITIL Management Practices. - Die Practices umfassen mehr als einzelne Prozesse und berücksichtigen Rollen, Informationen, Technologien, Wissen, Kommunikation und Wertströme. - Incident-Management-Werkzeuge unterstützen typischerweise die Erfassung, Kategorisierung, Priorisierung, Verlaufsdokumentation, Eskalation und Statusverfolgung. - Service-Desk-Prozesse und Informationen sollen in die Wertströme der Organisation integriert werden. - Datenqualität, Kommunikation, Nachvollziehbarkeit und geeignete Werkzeugunterstützung beeinflussen Serviceleistung und Benutzererfahrung. - ITIL Version 5 führt die Management Practices fort und richtet digitale Produkt- und Servicearbeit stärker an Wert, Outcomes, Erfahrung und Ende-zu-Ende-Zusammenarbeit aus. **Einordnung** Die auf dieser Seite dargestellten: - Ticketfelder, - Kategoriemodelle, - Statusbezeichnungen, - Titelregeln, - Checklisten, - Pflichtfeldempfehlungen, - Beispiele, - und Qualitätskriterien sind herstellerneutrale redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks. ITIL schreibt kein universelles: - Ticketformular, - Feldschema, - Kategoriemodell, - Statusmodell, - Supportgruppenmodell, - Prioritätsmodell, - oder Ticketsystem für alle Organisationen vor. Die konkrete Gestaltung muss angepasst werden an: - Services, - Benutzergruppen, - Wertströme, - Risiken, - Sicherheits- und Datenschutzanforderungen, - Lieferanten, - Fähigkeiten, - und technische Werkzeuge. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.5 Auswirkungen, Dringlichkeit und Priorität > **Kurz erklärt** > > Die Priorität bestimmt, in welcher Reihenfolge und mit welcher Aufmerksamkeit ein Vorgang bearbeitet werden soll. > > Sie sollte nicht allein davon abhängen: > > - wer am lautesten fordert, > - wer hierarchisch am höchsten steht, > - wann das Ticket erstellt wurde, > - oder welche Priorität ein Benutzer selbst auswählt. > > Eine verbreitete betriebliche Vorgehensweise ist, die Priorität anhand von: > > - **Auswirkung** > - und **Dringlichkeit** > > zu bestimmen. > > **Auswirkung** beschreibt, wie stark Benutzer, Services, Geschäftsprozesse oder andere Stakeholder beeinträchtigt sind. > > **Dringlichkeit** beschreibt, wie schnell gehandelt werden muss, bevor sich die Folgen verschlimmern oder ein wichtiges Zeitfenster verloren geht. > > Die Organisation muss selbst festlegen: > > - welche Bewertungsstufen gelten, > - welche Kriterien verwendet werden, > - wie daraus eine Priorität entsteht, > - welche Zielzeiten damit verbunden sind, > - wer die Priorität ändern darf, > - und wann eine Neubewertung erfolgen muss. > > ITIL schreibt keine universelle Prioritätsmatrix vor, die unverändert für jede Organisation übernommen werden kann. --- **Warum eine nachvollziehbare Priorisierung notwendig ist** Eine Serviceorganisation besitzt normalerweise mehr offene Arbeit, als gleichzeitig bearbeitet werden kann. Beispiele: - mehrere Benutzer melden unterschiedliche Incidents, - Service Requests warten auf Erfüllung, - Lieferanten müssen eingebunden werden, - Changes benötigen technische Vorbereitung, - und bereits laufende Vorgänge benötigen weitere Maßnahmen. Ohne nachvollziehbare Priorisierung kann die Reihenfolge bestimmt werden durch: - persönliche Beziehungen, - häufige Nachfragen, - Hierarchie, - Zufall, - technische Vorlieben, - oder das Alter des Tickets. Dadurch können schwerwiegende Situationen übersehen werden, während weniger bedeutsame Vorgänge bevorzugt bearbeitet werden. Beispiel: **Vorgang A** Ein Vorstandsmitglied kann einen zweiten, selten verwendeten Bildschirm nicht nutzen. **Vorgang B** Ein einzelner Produktionsarbeitsplatz kann keine Sicherheitsfreigaben mehr durchführen. Dadurch steht in 20 Minuten eine gesamte Fertigungslinie still. Obwohl bei beiden Vorgängen zunächst nur eine Person betroffen ist, besitzt Vorgang B wahrscheinlich die deutlich größere Auswirkung und Dringlichkeit. > **Merke** > > Priorisierung bewertet nicht die persönliche Wichtigkeit eines Benutzers. > > Sie bewertet die Bedeutung und zeitliche Kritikalität des betroffenen Outcomes. --- **Auswirkung, Dringlichkeit und Priorität unterscheiden** | Begriff | Zentrale Frage | |---|---| | **Auswirkung** | Wie schwerwiegend sind die Folgen für Benutzer, Services oder Organisation? | | **Dringlichkeit** | Wie schnell muss gehandelt werden, bevor die Folgen unvertretbar werden? | | **Priorität** | In welcher Reihenfolge und mit welcher Aufmerksamkeit wird der Vorgang bearbeitet? | Beispiel: Ein Archivsystem ist ausgefallen. **Mögliche geringe Dringlichkeit** - Das System wird erst in drei Tagen benötigt. - Eine sichere alternative Zugriffsmöglichkeit besteht. - Es droht kein Datenverlust. **Mögliche hohe Auswirkung** - Das System enthält geschäftskritische und gesetzlich aufzubewahrende Unterlagen. - Viele Bereiche sind davon abhängig. Die Auswirkung kann damit hoch sein, während die unmittelbare Dringlichkeit zunächst geringer ist. Ein anderes Beispiel: Ein einzelner Benutzer kann eine Präsentation für einen in zehn Minuten beginnenden Kundentermin nicht öffnen. - Auswirkung auf die gesamte Organisation möglicherweise begrenzt - Dringlichkeit aufgrund des unmittelbar bevorstehenden Termins hoch > **Wichtig** > > Auswirkung und Dringlichkeit beschreiben unterschiedliche Perspektiven. > > Eine hohe Auswirkung bedeutet nicht automatisch höchste Dringlichkeit. --- **Priorität ist keine technische Fehlerklasse** Ein technisch kleiner Fehler kann eine hohe geschäftliche Priorität besitzen. Beispiel: Ein abgelaufenes Zertifikat ist möglicherweise schnell erneuerbar. Wenn dadurch jedoch: - die zentrale Anmeldung ausfällt, - sämtliche Benutzer betroffen sind, - und kein sicherer Workaround besteht, kann der Incident höchste Priorität erhalten. Umgekehrt kann ein technisch komplexes Problem eine geringere Priorität besitzen. Beispiel: Ein selten verwendeter Bericht erzeugt unter einer bestimmten Kombination von Filtern einen Darstellungsfehler. Die Analyse kann technisch aufwendig sein. Wenn jedoch: - keine wichtigen Daten verloren gehen, - nur wenige Benutzer betroffen sind, - und eine einfache Alternative besteht, kann eine niedrigere Priorität angemessen sein. > **Merke** > > Technische Schwierigkeit und betriebliche Priorität sind nicht dasselbe. --- **Mögliche Einflussfaktoren auf die Auswirkung** Die Organisation kann mehrere Kriterien berücksichtigen. **Anzahl betroffener Benutzer** Mögliche Abstufung: - einzelne Person - mehrere Personen - gesamtes Team - gesamter Standort - mehrere Standorte - sämtliche Benutzer - externe Kunden oder Partner Die Anzahl allein reicht jedoch nicht aus. Ein einzelner betroffener Benutzer kann eine kritische Aufgabe ausführen. **Kritikalität des betroffenen Service** Beispiele: - zentrale Anmeldung - Produktionssteuerung - Notfallkommunikation - Zahlungsverkehr - E-Mail - Dateiablage - internes Testsystem - freiwillige Zusatzanwendung Die Organisation sollte wichtige Services und deren Abhängigkeiten kennen. **Bedeutung des betroffenen Geschäftsprozesses** Mögliche Auswirkungen: - Produktion steht still. - Rechnungen können nicht erstellt werden. - Kunden können nicht bestellen. - Personal kann keine Gehaltsabrechnung durchführen. - gesetzliche Meldung kann nicht fristgerecht übermittelt werden. - Außendienst kann keine Aufträge erfassen. - interne Schulungsplattform ist vorübergehend nicht erreichbar. **Art der Beeinträchtigung** | Beeinträchtigung | Beispiel | |---|---| | **vollständiger Ausfall** | Service ist nicht nutzbar | | **teilweiser Ausfall** | bestimmte Funktionen fehlen | | **Leistungsminderung** | Service reagiert stark verzögert | | **Qualitätsminderung** | Ergebnisse sind unvollständig oder fehlerhaft | | **Sicherheitsbeeinträchtigung** | Schutzbedarf könnte verletzt sein | | **Datenbeeinträchtigung** | Daten sind verloren, beschädigt oder inkonsistent | | **Erfahrungsbeeinträchtigung** | Service ist technisch verfügbar, aber praktisch kaum nutzbar | **Verfügbarkeit einer Zwischenlösung** Eine geeignete Zwischenlösung kann die Auswirkung oder Dringlichkeit reduzieren. Beispiele: - alternativer Arbeitsplatz - Webversion statt Desktop-Anwendung - zweiter Drucker - manuelle Ersatzbearbeitung - Ausweichstandort - vorübergehender Read-only-Zugriff - alternative Kommunikationsplattform Die Zwischenlösung muss jedoch: - sicher, - zulässig, - ausreichend leistungsfähig, - verständlich, - und für die betroffenen Benutzer tatsächlich nutzbar sein. Ungeeignet wäre beispielsweise: > Benutzer können ihre Dokumente an private E-Mail-Adressen senden. Auch wenn dadurch kurzfristig weitergearbeitet werden könnte, wäre dies möglicherweise aus Sicherheits- und Datenschutzgründen unzulässig. **Dauer und Reichweite** Die tatsächliche Auswirkung kann mit der Zeit wachsen. Beispiel: Ein Bestellsystem fällt am frühen Morgen aus. Zu Beginn bestehen nur wenige offene Bestellungen. Nach mehreren Stunden können entstehen: - wachsender Rückstand, - verpasste Liefertermine, - Kundenbeschwerden, - und finanzielle Schäden. Die Priorität muss deshalb möglicherweise während der Bearbeitung erhöht werden. **Finanzielle Auswirkungen** Mögliche Kriterien: - Umsatzverlust - Produktionsstillstand - Vertragsstrafe - zusätzliche Personalkosten - kostenpflichtige Notfallunterstützung - verlorene Arbeitszeit - drohender Kundenverlust Nicht jede Organisation kann exakte Beträge während der Ersterfassung bestimmen. Eine qualitative Bewertung kann zunächst ausreichen. **Sicherheits- und Datenschutzfolgen** Mögliche Auswirkungen: - unberechtigter Zugriff - Offenlegung vertraulicher Daten - Verlust der Verfügbarkeit - Veränderung von Daten - Schadsoftware - kompromittiertes Konto - verlorenes Gerät - unsichere technische Konfiguration Ein möglicher Sicherheitsvorfall benötigt möglicherweise: - eine eigene Klassifizierung, - einen besonders geschützten Bearbeitungsweg, - und eine sofortige Eskalation. Er darf nicht ausschließlich anhand der Zahl aktuell betroffener Benutzer bewertet werden. **Gesetzliche und regulatorische Auswirkungen** Mögliche Beispiele: - Meldefrist wird gefährdet. - gesetzlich vorgeschriebene Aufzeichnung ist nicht möglich. - Aufbewahrungspflichten könnten verletzt werden. - personenbezogene Daten wurden möglicherweise offengelegt. Die Organisation muss ihre verbindlichen Anforderungen kennen und in die Bewertung einbeziehen. **Auswirkungen auf Kunden, Öffentlichkeit und Reputation** Mögliche Folgen: - Kunden können Leistungen nicht nutzen. - öffentliche Statusseiten zeigen einen Ausfall. - Medien oder soziale Netzwerke berichten über die Störung. - vertraglich zugesagte Leistungen werden nicht erbracht. - Vertrauen in die Organisation sinkt. Reputationsauswirkung sollte nicht nur nach subjektivem Eindruck bewertet werden. Geeignete Eskalations- und Kommunikationsrollen müssen beteiligt werden. **Auswirkungen auf Gesundheit und Sicherheit** In bestimmten Umgebungen können IT-Störungen Auswirkungen besitzen auf: - körperliche Sicherheit, - medizinische Versorgung, - Gebäudezugänge, - Notfallkommunikation, - Maschinensteuerung, - oder sicherheitskritische Überwachung. Solche Situationen benötigen möglicherweise: - besonders schnelle Eskalation, - Notfallverfahren, - Business-Continuity-Maßnahmen, - und autorisierte Entscheidungen außerhalb des normalen Supportablaufs. --- **Mögliche Einflussfaktoren auf die Dringlichkeit** Dringlichkeit beschreibt die verfügbare Zeit bis zu einer wesentlichen Verschlechterung oder bis zum Verlust eines wichtigen Outcomes. **Unmittelbarer Zeitdruck** Beispiele: - Produktion steht bereits still. - Kunden können aktuell nicht bestellen. - ein gesetzlicher Meldetermin endet heute. - ein wichtiger Geschäftstermin beginnt in wenigen Minuten. - Sicherheitslücke wird aktiv ausgenutzt. - Datenverlust setzt sich fort. **Zeit bis zur erwarteten Verschlechterung** Beispiel: Ein Speicherbereich ist zu 95 Prozent belegt. Der Service funktioniert noch. Monitoring zeigt jedoch, dass der Speicher voraussichtlich innerhalb einer Stunde vollständig belegt sein wird. Obwohl noch kein vollständiger Ausfall besteht, kann hohe Dringlichkeit vorliegen. **Verbleibendes Zeitfenster** Beispiele: - Wartungsfenster endet in 30 Minuten. - Lieferantensupport ist nur noch eine Stunde erreichbar. - Abrechnungslauf beginnt am Abend. - Zertifikat läuft in zwei Tagen ab. - Produktionsumstellung beginnt am nächsten Morgen. - Backup-Zeitfenster endet vor Schichtbeginn. **Verfügbarkeit einer Zwischenlösung** Eine sichere und praktikable Zwischenlösung kann die Dringlichkeit reduzieren. Beispiel: Die Desktop-Anwendung ist ausgefallen. Die Webversion ermöglicht alle wichtigen Tätigkeiten. Die Bearbeitung kann dadurch möglicherweise kontrollierter erfolgen. Die Zwischenlösung muss allerdings hinsichtlich folgender Punkte bewertet werden: - Leistungsfähigkeit - Benutzerzahl - Sicherheit - Dauer - Datenkonsistenz - zusätzlicher Aufwand - mögliche Folgefehler **Drohender Datenverlust** Dringlichkeit kann besonders hoch sein, wenn: - Daten weiterhin überschrieben werden, - Speicherfehler weitere Dateien beschädigen, - gelöschte Daten nur begrenzte Zeit wiederherstellbar sind, - oder Logs und Beweise verloren gehen könnten. In solchen Situationen kann die erste Maßnahme darin bestehen: - weitere Veränderungen zu verhindern, - Systeme zu isolieren, - Beweise zu sichern, - oder Schreibzugriffe zu stoppen. Eine vorschnelle normale Fehlerbehebung kann Wiederherstellungsmöglichkeiten verschlechtern. **Sicherheitsbedrohung** Hohe Dringlichkeit kann vorliegen bei: - aktivem Angriff, - kompromittiertem Administratorkonto, - laufender Datenübertragung an Unberechtigte, - Schadsoftwareausbreitung, - oder bekanntem ungeschütztem kritischem Zugang. Die Bearbeitung richtet sich dann nicht nur nach Incident Management, sondern auch nach dem Sicherheitsverfahren der Organisation. **Kommender geschäftskritischer Zeitpunkt** Beispiel: Die Gehaltsabrechnung funktioniert am Montag nicht. Der endgültige Abrechnungslauf beginnt erst am Mittwoch. Die Auswirkung ist bereits erheblich. Die verfügbare Zeit bis Mittwoch beeinflusst jedoch die Dringlichkeit und den möglichen Eskalationsweg. --- **Eine mögliche Auswirkungsskala** Die folgende Skala ist ein redaktionelles Beispiel. Sie ist keine verbindliche ITIL-Vorgabe. | Stufe | Beispielhafte Bedeutung | |---|---| | **Hoch** | kritischer Service, großer Benutzerkreis, erheblicher Geschäfts-, Sicherheits- oder Kundenbezug | | **Mittel** | mehrere Benutzer oder wichtiger Teil eines Service betroffen, begrenzte Zwischenlösung vorhanden | | **Niedrig** | einzelne oder wenige Benutzer, begrenzte Folgen, geeignete Alternative vorhanden | Eine Organisation kann stattdessen verwenden: - vier Stufen, - fünf Stufen, - numerische Werte, - serviceabhängige Kriterien, - oder ein anderes nachvollziehbares Modell. --- **Beispielkriterien für hohe Auswirkung** Eine hohe Auswirkung kann beispielsweise vorliegen, wenn mindestens eines der folgenden Kriterien erfüllt ist: - kritischer Service vollständig ausgefallen - mehrere Standorte betroffen - wichtiger Geschäftsprozess gestoppt - erheblicher Kundenbezug - mögliches erhebliches Sicherheits- oder Datenschutzereignis - erheblicher Datenverlust - Gesundheits- oder Sicherheitsrisiko - keine geeignete Zwischenlösung - erhebliche finanzielle oder vertragliche Folgen Die Organisation muss festlegen, ob: - ein einzelnes Kriterium ausreicht, - mehrere Kriterien gemeinsam erfüllt sein müssen, - oder eine autorisierte Rolle die Gesamtbewertung vornimmt. --- **Eine mögliche Dringlichkeitsskala** Auch diese Skala ist ein redaktionelles Beispiel. | Stufe | Beispielhafte Bedeutung | |---|---| | **Hoch** | sofortiges Handeln erforderlich; Folgen treten bereits ein oder verschlimmern sich sehr schnell | | **Mittel** | zeitnahe Bearbeitung erforderlich; begrenztes Zeitfenster oder zunehmende Folgen | | **Niedrig** | Bearbeitung planbar; Auswirkungen verschlechtern sich voraussichtlich nicht kurzfristig | --- **Beispielkriterien für hohe Dringlichkeit** - Service steht bereits vollständig still. - Schaden nimmt fortlaufend zu. - Sicherheitsbedrohung ist aktiv. - Datenverlust setzt sich fort. - kritische Frist läuft kurzfristig ab. - keine geeignete Zwischenlösung besteht. - Wiederherstellungszeitfenster wird bald überschritten. - weitere Services könnten kurzfristig ausfallen. --- **Eine mögliche Prioritätsmatrix** Die folgende Matrix ist eine Praxisvorlage und keine verbindliche ITIL-Matrix. | Auswirkung | Dringlichkeit hoch | Dringlichkeit mittel | Dringlichkeit niedrig | |---|---:|---:|---:| | **hoch** | P1 | P2 | P3 | | **mittel** | P2 | P3 | P4 | | **niedrig** | P3 | P4 | P4 | Eine Organisation kann auch andere Ergebnisse festlegen. Beispielsweise könnte: - hohe Auswirkung und niedrige Dringlichkeit als P2 behandelt werden, - jeder mögliche Sicherheitsvorfall automatisch einen besonderen Eskalationsweg erhalten, - oder ein kritischer Service eigene Prioritätsregeln besitzen. > **Wichtig** > > Eine Matrix unterstützt Entscheidungen. > > Sie ersetzt nicht die fachliche Bewertung besonderer Situationen. --- **Mögliche Prioritätsstufen** | Priorität | Praxisnahe Bedeutung | |---|---| | **P1 – kritisch** | sofortige koordinierte Bearbeitung; sehr hohe Auswirkung und Dringlichkeit | | **P2 – hoch** | schnelle priorisierte Bearbeitung; erhebliche Beeinträchtigung | | **P3 – mittel** | normale priorisierte Bearbeitung innerhalb vereinbarter Ziele | | **P4 – niedrig** | planbare Bearbeitung bei begrenzter Auswirkung und Dringlichkeit | Manche Organisationen verwenden: - P0 bis P4, - Priorität 1 bis 5, - Kritisch, Hoch, Mittel, Niedrig, - Severity-Level, - oder serviceabhängige Modelle. Die Bedeutung muss eindeutig dokumentiert sein. --- **Priorität und Severity unterscheiden** Der Begriff **Severity** wird in Organisationen unterschiedlich verwendet. Mögliche Bedeutungen: - technische Schwere eines Fehlers, - Ausmaß der Servicebeeinträchtigung, - Softwarefehlerklasse, - oder Einstufung eines Sicherheitsereignisses. Priorität beschreibt dagegen die Bearbeitungsreihenfolge und Aufmerksamkeit. Beispiel: Ein Softwarefehler kann hohe Severity besitzen, weil er bei bestimmten Bedingungen Daten beschädigt. Wenn diese Funktion derzeit deaktiviert ist und kein unmittelbarer Schaden droht, kann die operative Bearbeitungspriorität zunächst anders eingeordnet werden. > **Praxistipp** > > Die Organisation sollte in einem Glossar eindeutig festlegen, wie Severity und Priorität verwendet werden. --- **Priorität und Servicekritikalität unterscheiden** Servicekritikalität ist eine grundsätzlichere Eigenschaft eines Service. Beispiele: - geschäftskritisch - wichtig - unterstützend - nicht produktiv Die Priorität bewertet dagegen einen konkreten Vorgang. Ein Incident an einem kritischen Service besitzt nicht automatisch immer P1. Beispiel: In einer geschäftskritischen Anwendung ist nur eine selten verwendete Berichtsfunktion betroffen. Der Kernservice funktioniert. Eine geeignete Zwischenlösung besteht. Der konkrete Incident kann deshalb eine niedrigere Priorität erhalten. Umgekehrt kann ein normalerweise weniger kritischer Service zu einem bestimmten Zeitpunkt besonders wichtig sein. Beispiel: Eine Schulungsplattform wird während einer verbindlichen Abschlussprüfung benötigt. --- **Priorität und Major Incident unterscheiden** Ein Major Incident ist ein Incident mit besonders erheblicher Bedeutung, der eine besondere Koordination und Kommunikation erfordern kann. Eine Organisation legt eigene Kriterien fest. Ein P1-Incident kann ein Major Incident sein. Dies muss jedoch nicht in jeder Organisation automatisch identisch sein. | Priorität | Major Incident | |---|---| | bestimmt Bearbeitungsreihenfolge und Zielzeiten | aktiviert besondere Koordination und Kommunikation | | kann für unterschiedliche Vorgangsarten gelten | bezieht sich auf besonders schwerwiegende Incidents | | wird häufig aus Auswirkung und Dringlichkeit bestimmt | kann zusätzliche definierte Kriterien besitzen | | kann durch normale Supportstruktur bearbeitet werden | benötigt möglicherweise Incident-Koordination, Krisenkommunikation und Managementbeteiligung | Major-Incident-Kriterien werden auf Seite **3.7 Ownership, hierarchische Eskalation und Major Incidents** vertieft. --- **Priorität und Eskalation unterscheiden** Hohe Priorität kann eine Eskalation auslösen. Eine Eskalation kann jedoch auch notwendig sein, wenn die Priorität nicht besonders hoch ist. Beispiele: - Zielzeit ist gefährdet. - zuständige Fachkenntnis fehlt. - Lieferant reagiert nicht. - Entscheidung liegt außerhalb vorhandener Befugnisse. - mehrere Teams sind uneinig. - Benutzerbeschwerde benötigt Managementbeteiligung. - regulatorische Frage muss geklärt werden. Die Priorität beschreibt nicht vollständig, welcher Eskalationstyp benötigt wird. --- **Priorität und Zielzeiten unterscheiden** Prioritätsstufen können mit unterschiedlichen Zielen verbunden sein. Mögliche Ziele: - Zeit bis zur Annahme - Zeit bis zur qualifizierten Reaktion - Zeit bis zum Beginn der Bearbeitung - Zeit bis zur Wiederherstellung - Zeit bis zur Erfüllung - Statusintervall - Eskalationszeitpunkt Beispielhafte interne Ziele: | Priorität | Qualifizierte Reaktion | Statusintervall | |---|---:|---:| | **P1** | unverzüglich | alle 30 Minuten | | **P2** | innerhalb einer Stunde | alle 2 Stunden | | **P3** | innerhalb eines Arbeitstags | nach wesentlichen Änderungen | | **P4** | nach Planung | nach Vereinbarung | Diese Werte sind nur Beispiele. Die tatsächlichen Ziele müssen zu: - Servicezeiten, - Verträgen, - Servicekritikalität, - Fähigkeiten, - Bereitschaft, - und verfügbaren Ressourcen passen. --- **Reaktionsziel ist kein Lösungsversprechen** Eine Zielzeit für die erste Reaktion bedeutet nicht automatisch, dass der Incident innerhalb dieses Zeitraums gelöst sein muss. Beispiel: > Qualifizierte Reaktion innerhalb von 30 Minuten kann bedeuten: - Situation wurde bewertet, - Ownership wurde übernommen, - erste Diagnose hat begonnen, - und Benutzer erhielt eine verwertbare Rückmeldung. Eine Wiederherstellungszeit hängt unter anderem ab von: - Ursache, - technischer Komplexität, - Abhängigkeiten, - Lieferanten, - und verfügbaren Wiederherstellungsoptionen. > **Merke** > > Serviceziele müssen verständlich benannt werden. > > „Antwort innerhalb einer Stunde“ darf nicht als „Lösung innerhalb einer Stunde“ missverstanden werden. --- **Statusintervalle nach Priorität** Bei hoher Priorität benötigen Stakeholder häufigere Informationen. Ein Statusintervall sollte festlegen: - wie oft informiert wird, - wer informiert, - welche Zielgruppen informiert werden, - und welcher Kanal verwendet wird. Auch wenn keine neue Lösung vorliegt, kann eine Statusmeldung enthalten: - was aktuell geprüft wird, - welche Maßnahmen bereits erfolgten, - welche Abhängigkeit besteht, - welche Zwischenlösung gilt, - und wann die nächste Information folgt. --- **Priorität bei der Ersterfassung** Bei der ersten Meldung liegen häufig noch nicht alle Informationen vor. Eine vorläufige Priorität kann anhand der verfügbaren Angaben gesetzt werden. Danach sollte sie überprüft werden, sobald bekannt ist: - wie viele Benutzer betroffen sind, - welcher Service tatsächlich beeinträchtigt ist, - ob eine Zwischenlösung besteht, - ob weitere Standorte betroffen sind, - und ob Sicherheits- oder Datenrisiken bestehen. > **Wichtig** > > Eine erste Priorität ist keine unveränderliche Entscheidung. --- **Priorität dynamisch neu bewerten** Eine Neubewertung ist sinnvoll, wenn: - weitere Benutzer betroffen sind, - die Störung sich ausbreitet, - eine Zwischenlösung ausfällt, - ein kritischer Termin näher rückt, - Datenverlust erkannt wird, - ein Sicherheitsbezug entsteht, - der Service vollständig ausfällt, - oder die Wiederherstellung länger dauert als erwartet. Die Priorität kann auch gesenkt werden, wenn: - ein wirksamer Workaround eingeführt wurde, - nur eine weniger wichtige Funktion betroffen ist, - oder sich die ursprüngliche Auswirkung als geringer herausstellt. Jede wesentliche Änderung sollte dokumentiert werden. --- **Prioritätsänderungen dokumentieren** Eine nachvollziehbare Dokumentation kann enthalten: - alte Priorität - neue Priorität - Zeitpunkt - Grund - entscheidende Rolle - geänderte Auswirkung oder Dringlichkeit - ausgelöste Eskalation - Kommunikationsmaßnahme Beispiel: > 10:25 Uhr – Priorität von P3 auf P1 erhöht. Ursprünglich war ein einzelner Arbeitsplatz betroffen. Inzwischen können sämtliche Benutzer des Standorts keine Produktionsfreigabe durchführen. Fertigung steht seit 10:20 Uhr. Incident-Koordination und Standortleitung wurden informiert. --- **Wer darf die Priorität ändern?** Die Organisation sollte festlegen: - wer initial priorisiert, - wer eine Priorität erhöhen darf, - wer sie reduzieren darf, - wann Management oder Service Owner beteiligt werden, - und wie Konflikte entschieden werden. Mögliche Rollen: - Service Desk - Incident Manager - Service Owner - technische Supportgruppe - Informationssicherheit - autorisierte Führungskraft Eine Priorität darf nicht allein deshalb geändert werden, weil eine Person eine schnellere Bearbeitung verlangt. --- **Benutzerwunsch und organisatorische Priorität** Benutzer sollen die Auswirkungen und zeitlichen Anforderungen beschreiben können. Sie müssen jedoch nicht zwingend die endgültige Priorität auswählen. Eine geeignete Kommunikation kann lauten: > Sie haben angegeben, dass die Angelegenheit sehr dringend ist. Ich prüfe jetzt zusätzlich, wie viele Benutzer und welcher Geschäftsprozess betroffen sind. Daraus wird die Priorität nach unseren Kriterien bestimmt. Bei abweichender Bewertung: > Ich verstehe, dass Sie die Anwendung heute benötigen. Da aktuell nur eine Person betroffen ist, eine sichere Alternative besteht und keine Frist innerhalb der nächsten Stunden gefährdet ist, wird der Vorgang als P3 bearbeitet. Sollte die Alternative ausfallen oder der Monatsabschluss gefährdet sein, bewerten wir die Priorität erneut. --- **Hierarchie ist kein automatisches Prioritätskriterium** Ein Vorgang einer Führungskraft kann hohe Auswirkung besitzen. Beispiel: Die Person muss eine zeitkritische strategische Entscheidung freigeben. Die hierarchische Position allein genügt jedoch nicht als Begründung. Ungeeignet: > Tickets der Geschäftsführung sind immer P1. Besser: - geschäftliche Auswirkungen erfassen, - Dringlichkeit bestimmen, - organisatorische Kriterien anwenden, - und gegebenenfalls besondere Kommunikationsanforderungen berücksichtigen. > **Grundsatz** > > Eine besondere Kommunikationsbehandlung ist nicht automatisch eine höhere technische Bearbeitungspriorität. --- **VIP-Regelungen kritisch gestalten** Organisationen verwenden teilweise VIP-Kennzeichnungen. Diese können unterstützen bei: - besonderen Kommunikationswegen, - Assistenzkontakten, - erweiterten Servicezeiten, - oder organisatorisch vereinbarten Leistungen. Sie sollten nicht dazu führen, dass: - kritische Incidents anderer Benutzer verdrängt werden, - Sicherheitsprüfungen entfallen, - oder Prioritätskriterien bedeutungslos werden. --- **Zwischenlösungen richtig bewerten** Ein Workaround reduziert möglicherweise die Dringlichkeit. Er löst jedoch nicht automatisch den Incident dauerhaft. Beispiel: Die Desktop-Anwendung ist ausgefallen. Benutzer können vorübergehend die Webversion verwenden. Zu prüfen ist: - Sind alle benötigten Funktionen vorhanden? - Können sämtliche betroffenen Benutzer sie nutzen? - Ist die Lösung sicher? - Entsteht zusätzlicher Aufwand? - Wie lange ist der Workaround tragfähig? - Werden Daten konsistent verarbeitet? Ein Workaround kann damit: - Priorität senken, - Zeit für Ursachenanalyse schaffen, - oder Auswirkungen begrenzen. Er darf aber nicht unkritisch als vollständige Lösung behandelt werden. --- **Priorisierung bei mehreren gleichzeitig kritischen Incidents** Mehrere P1-Incidents können gleichzeitig auftreten. Dann reicht die Prioritätsnummer allein möglicherweise nicht aus. Zusätzlich zu bewerten sind: - Gesundheits- und Sicherheitsrisiken - aktive Sicherheitsbedrohung - Datenverlust - Anzahl und Bedeutung betroffener Services - verfügbare Wiederherstellungsmöglichkeiten - Abhängigkeiten - benötigte Spezialisten - mögliche Kettenreaktionen Governance oder Incident-Koordination muss möglicherweise Ressourcen zwischen den Vorgängen verteilen. --- **Abhängige Services berücksichtigen** Ein Incident kann zunächst nur eine technische Komponente betreffen. Diese kann jedoch mehrere Services unterstützen. Beispiel: Ein zentraler Identitätsdienst zeigt erste Fehler. Aktuell ist nur eine interne Anwendung betroffen. Möglicherweise werden kurz darauf ebenfalls beeinträchtigt: - E-Mail, - VPN, - Cloud-Anwendungen, - Administrationszugänge, - und Self-Service-Portal. Die Priorität sollte potenzielle und bekannte Abhängigkeiten berücksichtigen, ohne unbelegte Worst-Case-Annahmen als Tatsache zu behandeln. --- **Verknüpfte Incidents gemeinsam betrachten** Mehrere scheinbar unabhängige Meldungen können einen gemeinsamen Auslöser besitzen. Beispiele: - Anmeldung funktioniert nicht. - VPN-Verbindung schlägt fehl. - Cloud-Anwendung öffnet nicht. - Kennwort-Self-Service ist nicht erreichbar. Wenn alle Services vom gleichen Identitätsdienst abhängen, kann ein gemeinsamer Incident mit höherer Auswirkung vorliegen. --- **Service Requests priorisieren** Nicht nur Incidents benötigen eine Bearbeitungsreihenfolge. Auch Service Requests können unterschiedliche Dringlichkeit und Bedeutung besitzen. Beispiele: - Standardsoftware für einen zukünftigen Arbeitsplatz - Zugriff für neuen Mitarbeiter - Bestellung eines Ersatzgeräts - Berechtigung für einen zeitkritischen Projekteinsatz - Information zu einem Service Service Requests sollten trotzdem nicht wie Incidents behandelt werden. Bei Requests können zusätzlich relevant sein: - gewünschter Bereitstellungstermin - Genehmigungsstatus - Standardbereitstellungszeit - Verfügbarkeit von Lizenzen oder Assets - vertragliche oder organisatorische Verpflichtung Eine verspätet eingereichte Anfrage wird nicht automatisch zum Incident. Beispiel: Eine Führungskraft beantragt erst am Freitagnachmittag einen vollständigen Arbeitsplatz für Montag. Die Anfrage ist dringend. Es liegt jedoch nicht zwingend eine ungeplante Serviceunterbrechung vor. --- **Notfall durch schlechte Planung** Eine intern verspätete Anfrage sollte nicht automatisch höchste technische Priorität erhalten. Trotzdem muss die Organisation die tatsächlichen Auswirkungen berücksichtigen. Geeignete Vorgehensweise: - Request korrekt klassifizieren, - mögliche Beschleunigung prüfen, - Risiken und Zusatzaufwand transparent machen, - notwendige Entscheidungen eskalieren, - und wiederkehrende Planungsprobleme verbessern. --- **Backlog und Priorität** Innerhalb derselben Priorität kann die Reihenfolge zusätzlich bestimmt werden durch: - Eingangszeit - Serviceziel - Alter des Vorgangs - vorhandene Abhängigkeiten - benötigte Fähigkeiten - zugesagte Termine - Effizienz der gemeinsamen Bearbeitung Ein älteres P3-Ticket sollte nicht dauerhaft durch neue P3-Tickets verdrängt werden. Backlog-Steuerung sollte deshalb auch berücksichtigen: - Ticketalter, - blockierte Vorgänge, - wiederholte Verschiebungen, - und gefährdete Serviceziele. --- **Priorität darf nicht jede Planung zerstören** Hohe Prioritäten sollten tatsächlich besonderen Situationen vorbehalten bleiben. Wenn sehr viele Vorgänge als P1 oder P2 eingestuft werden: - verliert das Modell seine Aussagekraft, - Ressourcen wechseln ständig, - geplante Arbeit wird unterbrochen, - Mitarbeiter werden überlastet, - und wichtige Vorgänge konkurrieren miteinander. Eine hohe Quote kritischer Prioritäten kann hinweisen auf: - unklare Kriterien, - unrealistische Serviceziele, - falsche Benutzerwahl, - organisatorische Fehlanreize, - oder grundsätzlich instabile Services. --- **Prioritätsinflation** Prioritätsinflation entsteht, wenn immer mehr Vorgänge hoch priorisiert werden, um schneller bearbeitet zu werden. Mögliche Anzeichen: - Benutzer wählen regelmäßig „kritisch“. - Führungskräfte verlangen Sonderbehandlung. - Supportgruppen erhöhen Prioritäten zur Eskalation. - Serviceziele werden nur durch formale Umklassifizierung eingehalten. - fast jedes Ticket ist P1 oder P2. Mögliche Maßnahmen: - Kriterien präzisieren, - Benutzerfelder überarbeiten, - Priorität automatisch vorschlagen statt frei auswählen lassen, - Stichproben durchführen, - und Fehlanreize in Kennzahlen beseitigen. --- **Falsche Herabstufung** Prioritäten können ebenfalls zu niedrig angesetzt werden. Mögliche Ursachen: - geschäftlicher Kontext ist unbekannt, - Benutzerzahl wird überbewertet, - Sicherheitsauswirkung wird nicht erkannt, - Servicekritikalität fehlt, - oder Supportteam möchte Zielverletzungen vermeiden. Beispiel: Nur ein Benutzer meldet einen Fehler. Dieser Benutzer ist jedoch für die gesetzlich fristgebundene Meldung verantwortlich. Ohne Kontext könnte der Vorgang fälschlich als geringe Auswirkung bewertet werden. --- **Automatisierte Priorisierung** Werkzeuge können eine Priorität vorschlagen anhand von: - ausgewähltem Service, - Benutzerzahl, - Standort, - Incident-Art, - Servicekritikalität, - Monitoring-Daten, - und bekannten Abhängigkeiten. Vorteile: - schnellere Ersterfassung, - einheitlichere Bewertung, - automatische Eskalation. Risiken: - unvollständige Eingangsdaten, - veraltete Servicekritikalität, - falsche Kategorien, - unerkannte Ausnahmen, - und zu starre Regeln. > **Merke** > > Automatisierung kann Priorisierung unterstützen. > > Sie ersetzt nicht die fachliche Bewertung ungewöhnlicher Situationen. --- **KI-gestützte Priorisierung** KI kann Muster erkennen in: - Tickettexten, - betroffenen Services, - vergangenen Incidents, - Benutzerangaben, - Monitoring-Daten, - Kommunikationsverläufen. Sie kann beispielsweise vorschlagen: - mögliche Auswirkung, - mögliche Dringlichkeit, - Prioritätsstufe, - notwendige Eskalation. Mögliche Risiken: - falsche Interpretation, - Benachteiligung bestimmter Benutzergruppen, - Überbewertung emotionaler Sprache, - unerkannte Sicherheitsmeldungen, - fehlende Nachvollziehbarkeit. Notwendig sind: - menschliche Überprüfung bei kritischen Fällen, - transparente Kriterien, - Qualitätsmessung, - Korrekturmöglichkeiten, - klare Ergebnisverantwortung. --- **Emotionale Sprache und KI** Eine KI darf nicht automatisch eine hohe Priorität setzen, nur weil ein Ticket Wörter enthält wie: - dringend, - sofort, - katastrophal, - Vorstand, - kritisch. Sie muss organisatorisch relevante Auswirkungen erkennen oder zur weiteren Klärung auffordern. Beispiel: > „Extrem dringend: Mauszeiger ist zu langsam.“ Die Formulierung allein beweist keine hohe Auswirkung oder Dringlichkeit. --- **Priorisierung bei Sicherheitsmeldungen** Eine Sicherheitsmeldung benötigt möglicherweise ein separates Bewertungsmodell. Zusätzliche Kriterien können sein: - Art des betroffenen Kontos - Berechtigungsumfang - aktive Ausnutzung - Datenklassifizierung - mögliche Ausbreitung - Beweislage - notwendige Meldefristen Ein scheinbar kleiner Vorfall kann hohe Kritikalität besitzen. Beispiel: Nur ein Administratorkonto zeigt eine verdächtige Anmeldung. Die Benutzerzahl ist gering. Der mögliche Berechtigungsumfang ist jedoch sehr hoch. --- **Priorisierung bei Datenverlust** Zu klären sind: - Welche Daten sind betroffen? - Sind Sicherungen vorhanden? - Werden weiterhin Daten überschrieben? - Wie groß ist das Wiederherstellungsfenster? - Sind rechtliche oder vertragliche Anforderungen betroffen? - Kann die Datenquelle isoliert werden? - Welche weiteren Benutzer oder Systeme sind gefährdet? Die erste Priorität kann darin bestehen, weiteren Schaden zu verhindern. --- **Priorisierung bei Performance-Problemen** Ein Service kann technisch verfügbar sein, aber praktisch nicht ausreichend nutzbar. Zu bewerten sind: - tatsächliche Antwortzeiten, - betroffene Benutzer, - kritische Geschäftszeiten, - Fehlerquote, - mögliche Verschlechterung, - verfügbare Alternativen. Beispiel: Eine Anwendung benötigt statt zwei Sekunden nun 30 Sekunden pro Vorgang. Bei wenigen Vorgängen ist dies möglicherweise begrenzt. Während eines Massenabrechnungslaufs kann dieselbe Verzögerung den gesamten Prozess blockieren. --- **Priorisierung bei geplanten Changes** Ein Incident nach einem Change kann besondere Aufmerksamkeit benötigen. Zu prüfen sind: - zeitlicher Zusammenhang, - betroffene Services, - Rückfallmöglichkeit, - laufendes Wartungsfenster, - Risiko weiterer Auswirkungen. Die Priorität wird weiterhin anhand der tatsächlichen Auswirkung und Dringlichkeit bestimmt. Ein Zusammenhang mit einem Change bedeutet nicht automatisch P1. --- **Priorisierung und Lieferanten** Bei Lieferantenfällen müssen möglicherweise zusätzlich berücksichtigt werden: - Vertragsprioritäten - Service-Level-Vereinbarungen - Supportzeiten - Eskalationswege - Kundennummern - notwendige Nachweise Die interne Priorität und die Lieferantenpriorität können unterschiedliche Bezeichnungen besitzen. Beispiel: Intern: > P1 Beim Provider: > Severity 1 Die Organisation muss die Zuordnung kennen und prüfen, ob die Kriterien tatsächlich übereinstimmen. --- **Kommunikation einer Priorität** Benutzer müssen nicht zwingend jedes interne Prioritätsdetail verstehen. Sie sollten jedoch nachvollziehen können: - wie die Situation bewertet wurde, - welcher nächste Schritt erfolgt, - und wann sie eine Rückmeldung erhalten. Geeignete Formulierung: > Der Vorgang wurde als hohe Priorität eingestuft, weil der gesamte Standort betroffen ist und keine Zwischenlösung besteht. Das Netzwerkteam und der Provider arbeiten bereits an der Wiederherstellung. Die nächste Statusmeldung erfolgt spätestens um 10:30 Uhr. Bei niedrigerer Priorität: > Der Vorgang wird innerhalb der normalen Servicezeit bearbeitet. Aktuell ist ein Benutzer betroffen und ein alternativer Arbeitsplatz steht zur Verfügung. Sollte diese Alternative ausfallen, melden Sie sich bitte unter Angabe der Vorgangsnummer, damit die Priorität neu bewertet werden kann. --- **Keine Prioritätsdiskussion ohne Kontext** Ungeeignet: > Das ist nur P3. Besser: > Nach den aktuellen Informationen ist eine Person betroffen und eine funktionsfähige Alternative vorhanden. Deshalb wird der Vorgang derzeit als P3 bearbeitet. Wenn weitere Benutzer betroffen sind oder die Alternative ausfällt, erhöhen wir die Priorität. --- **Governance der Priorisierung** Eine wirksame Priorisierung benötigt: - dokumentierte Kriterien, - klare Entscheidungsbefugnisse, - nachvollziehbare Änderungen, - geeignete Schulung, - regelmäßige Qualitätsprüfung, - Continual Improvement. Zu klären ist: - Wer definiert die Matrix? - Wer genehmigt Änderungen? - Wie werden kritische Services berücksichtigt? - Wie werden Sicherheitsereignisse behandelt? - Wie werden Zielzeiten festgelegt? - Wie werden Fehlpriorisierungen erkannt? - Welche Kennzahlen werden verwendet? - Wie werden Ausnahmen entschieden? --- **Prioritätsmodell regelmäßig überprüfen** Das Modell kann ungeeignet werden durch: - neue Services, - veränderte Geschäftsprozesse, - neue Standorte, - organisatorische Veränderungen, - neue Sicherheitsanforderungen, - neue Servicezeiten. Regelmäßig zu prüfen sind: - Sind die Kriterien verständlich? - Werden zu viele Tickets hoch priorisiert? - Werden kritische Situationen zuverlässig erkannt? - Passen Zielzeiten zu den Ressourcen? - Werden Workarounds korrekt berücksichtigt? - Sind Servicekritikalitäten aktuell? - Gibt es wiederkehrende Ausnahmen? - Unterstützt das Modell gewünschtes Verhalten? --- **Kennzahlen zur Priorisierung** Mögliche Kennzahlen: - Anzahl der Tickets pro Prioritätsstufe - Anteil nachträglich geänderter Prioritäten - häufige Gründe für Erhöhungen - häufige Gründe für Herabstufungen - Zielerreichung je Priorität - durchschnittliche Wiederherstellungszeit - Anzahl falsch priorisierter Incidents - Anzahl als kritisch gemeldeter, aber niedrig eingestufter Kontakte - Wiedereröffnungsquote - Benutzerbeschwerden über Priorisierung - Anteil von Sicherheitsmeldungen mit korrekter Eskalation - Alter des Backlogs je Priorität Kennzahlen sollten nicht isoliert betrachtet werden. --- **Problematische Kennzahlen** **Möglichst wenige P1-Incidents** Mögliche Fehlwirkung: - kritische Incidents werden als P2 klassifiziert. **Möglichst hohe Zielerreichung** Mögliche Fehlwirkung: - Prioritäten werden herabgesetzt, - Zielzeiten werden gestoppt, - Tickets werden voreilig geschlossen. **Möglichst kurze Lösungszeit** Mögliche Fehlwirkung: - komplexe Ursachen werden nicht ausreichend dokumentiert, - Workarounds werden als dauerhafte Lösung behandelt, - Benutzerbestätigung wird übersprungen. > **Merke** > > Kennzahlen dürfen nicht dazu führen, dass die Prioritätsbewertung manipuliert wird. --- **Praxisbeispiel: Ein Benutzer, hohe Auswirkung** **Meldung** Ein einzelner Mitarbeiter kann eine Produktionsfreigabe nicht durchführen. **Zusätzlicher Kontext** - Nur dieses Konto besitzt aktuell die notwendige Freigabeberechtigung. - Fertigungsaufträge warten. - In 30 Minuten steht die Linie still. - Kein geeigneter Stellvertreter ist verfügbar. **Bewertung** - Benutzerzahl: niedrig - Auswirkung: hoch - Dringlichkeit: hoch - mögliche Priorität: P1 Das Beispiel zeigt, warum Benutzerzahl nicht allein ausreicht. --- **Praxisbeispiel: Viele Benutzer, niedrige Dringlichkeit** **Meldung** Das interne Archivsystem ist für alle Benutzer nicht erreichbar. **Zusätzlicher Kontext** - Es wird für die aktuelle Tagesarbeit nicht benötigt. - Am nächsten Arbeitstag findet eine Prüfung statt. - Alle benötigten Unterlagen wurden vorübergehend exportiert. - Es besteht kein Datenverlust. **Bewertung** - Benutzerkreis: groß - Auswirkung: möglicherweise hoch - unmittelbare Dringlichkeit: mittel oder niedrig - mögliche Priorität: abhängig vom Organisationsmodell P2 oder P3 --- **Praxisbeispiel: Führungskraft mit geringerer Auswirkung** **Meldung** Eine Führungskraft kann einen zweiten Bildschirm nicht verwenden. **Zusätzlicher Kontext** - Hauptbildschirm funktioniert. - alle Anwendungen sind nutzbar. - kein zeitkritischer Termin wird beeinträchtigt. - Ersatzgerät kann am nächsten Tag bereitgestellt werden. **Bewertung** - Auswirkung: niedrig - Dringlichkeit: niedrig - mögliche Priorität: P4 Die Position der meldenden Person verändert die technische Auswirkung nicht automatisch. --- **Praxisbeispiel: Aktive Sicherheitsbedrohung** **Meldung** Ein einzelnes Administratorkonto zeigt mehrere ungewöhnliche Anmeldungen aus einem unbekannten Land. **Zusätzlicher Kontext** - Konto besitzt weitreichende Berechtigungen. - eine Anmeldung war erfolgreich. - Ursache ist noch unbekannt. **Bewertung** - Benutzerzahl: niedrig - mögliche Sicherheitsauswirkung: sehr hoch - Dringlichkeit: hoch - sofortige Sicherheitseskalation erforderlich --- **Praxisbeispiel: Workaround reduziert Dringlichkeit** **Meldung** Die Desktop-Version einer Fachanwendung startet nicht. **Zusätzlicher Kontext** - zehn Benutzer betroffen - Webversion funktioniert vollständig - Daten bleiben konsistent - keine kritische Frist innerhalb der nächsten Stunden **Bewertung vor Workaround** - Auswirkung: mittel oder hoch - Dringlichkeit: hoch **Bewertung nach bestätigtem Workaround** - Auswirkung weiterhin vorhanden - unmittelbare Dringlichkeit möglicherweise geringer - Priorität kann nach festgelegten Regeln neu bewertet werden --- **Praxisbeispiel: Priorität wird erhöht** **Ursprüngliche Situation** Ein Benutzer kann keine Dateien speichern. - ein Benutzer betroffen - alternativer Ordner verfügbar - Priorität P3 **Neue Erkenntnis** Innerhalb von 20 Minuten melden weitere Benutzer dasselbe Problem. Monitoring zeigt: - zentraler Speicher fast vollständig belegt - Schreibvorgänge schlagen für mehrere Services fehl - Datenbankdienst könnte als Nächstes betroffen sein **Neue Bewertung** - Auswirkung: hoch - Dringlichkeit: hoch - Priorität wird auf P1 erhöht - Incident-Koordination wird aktiviert --- **Praxisbeispiel: Request wird nicht zum Incident** Eine Führungskraft meldet am Freitagnachmittag: > Neuer Mitarbeiter beginnt Montag. Notebook, Konto und alle Anwendungen werden dringend benötigt. Die Situation ist zeitkritisch. Es handelt sich jedoch um eine verspätet eingereichte Onboarding-Anfrage und nicht automatisch um einen Incident. Mögliche Behandlung: - Request mit hoher interner Dringlichkeit erfassen - Machbarkeit prüfen - notwendige Genehmigungen und Risiken klären - verfügbare Zwischenlösung anbieten - Planungsproblem anschließend verbessern --- **Typische Fehler bei der Priorisierung** **Fehler 1: Priorität nur nach Benutzerzahl bestimmen** Ein einzelner kritischer Arbeitsplatz wird unterschätzt. **Fehler 2: Priorität nach Hierarchie bestimmen** Führungskräfte erhalten automatisch P1. **Fehler 3: Benutzer bestimmt endgültige Priorität** Subjektive Dringlichkeit ersetzt organisatorische Kriterien. **Fehler 4: Jede Störung eines kritischen Service ist P1** Teilfunktionen und geeignete Workarounds werden nicht berücksichtigt. **Fehler 5: Technische Komplexität mit Priorität verwechseln** Schwierige Fehler werden bevorzugt, obwohl andere Vorgänge größere Auswirkungen besitzen. **Fehler 6: Priorität nach der Ersterfassung nie ändern** Ausbreitung und neue Risiken bleiben unberücksichtigt. **Fehler 7: Workaround automatisch als vollständige Lösung behandeln** Ursache und verbleibende Einschränkungen werden übersehen. **Fehler 8: Sicherheit nur nach Benutzerzahl bewerten** Ein kompromittiertes Administratorkonto wird unterschätzt. **Fehler 9: Zu viele P1- und P2-Tickets** Das Prioritätsmodell verliert seine Steuerungswirkung. **Fehler 10: Hohe Priorität zur Beschleunigung missbrauchen** Normale Requests verdrängen tatsächliche Incidents. **Fehler 11: Priorität senken, um Zielverletzung zu vermeiden** Kennzahlen werden manipuliert. **Fehler 12: Priorität und Major Incident gleichsetzen** Besondere Koordination wird entweder unnötig oder zu spät aktiviert. **Fehler 13: Zielzeit als Lösungsversprechen kommunizieren** Benutzer erhalten falsche Erwartungen. **Fehler 14: Zwischenlösung nicht fachlich prüfen** Unsichere oder unvollständige Alternativen führen zu falscher Herabstufung. **Fehler 15: Prioritätsänderung nicht dokumentieren** Spätere Entscheidungen sind nicht nachvollziehbar. **Fehler 16: Servicekritikalität ist veraltet** Neue geschäftliche Abhängigkeiten werden nicht erkannt. **Fehler 17: KI-Vorschlag ungeprüft übernehmen** Emotionale Sprache oder falsche Kategorien bestimmen die Priorität. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker liefern wichtige Informationen für die Prioritätsbewertung. Sie können beurteilen: - welcher Service betroffen ist, - welche technischen Abhängigkeiten bestehen, - wie weit sich ein Fehler ausbreitet, - ob Datenverlust droht, - ob ein Workaround technisch sicher ist, - und welche weiteren Systeme gefährdet sind. Technische Rückmeldungen sollten nicht nur lauten: > Server ist ausgefallen. Besser: > Der Server unterstützt die zentrale Anmeldung für VPN und drei Cloud-Anwendungen. Aktuell können sich neue Benutzer nicht anmelden. Bestehende Sitzungen funktionieren noch. Ohne Wiederherstellung werden bei Ablauf der Sitzungen zunehmend weitere Benutzer betroffen sein. Ein sicherer Workaround besteht derzeit nicht. Diese Informationen helfen bei der Bewertung von: - Auswirkung, - Dringlichkeit, - Priorität, - Eskalation. --- **30-Sekunden-Prüfung der Auswirkung** 1. Welcher Service ist betroffen? 2. Welche Benutzer oder Kunden sind betroffen? 3. Welcher Geschäftsprozess ist beeinträchtigt? 4. Besteht vollständiger oder teilweiser Ausfall? 5. Gibt es Datenverlust oder Sicherheitsbezug? 6. Besteht eine geeignete Zwischenlösung? 7. Sind weitere Services abhängig? 8. Welche finanziellen, vertraglichen oder rechtlichen Folgen bestehen? 9. Besteht Gesundheits- oder Sicherheitsbezug? 10. Wie stark kann sich die Auswirkung noch vergrößern? --- **30-Sekunden-Prüfung der Dringlichkeit** 1. Tritt der Schaden bereits ein? 2. Verschlimmert sich die Situation? 3. Wann wird ein kritischer Zeitpunkt erreicht? 4. Besteht eine zeitliche Frist? 5. Droht weiterer Datenverlust? 6. Besteht eine aktive Sicherheitsbedrohung? 7. Wie lange ist der Workaround nutzbar? 8. Kann die Bearbeitung sicher geplant werden? 9. Welche Wiederherstellungsfenster bestehen? 10. Wann müssen weitere Rollen oder Lieferanten eingebunden werden? --- **Checkliste für die Ersterfassung** - [ ] Ist der betroffene Service bekannt? - [ ] Sind betroffene Benutzer, Standorte oder Kunden bekannt? - [ ] Ist der betroffene Geschäftsprozess beschrieben? - [ ] Ist der Umfang der Beeinträchtigung bekannt? - [ ] Besteht vollständiger oder teilweiser Ausfall? - [ ] Ist eine sichere Zwischenlösung vorhanden? - [ ] Besteht möglicher Datenverlust? - [ ] Besteht Sicherheits- oder Datenschutzbezug? - [ ] Gibt es eine zeitkritische Frist? - [ ] Wurde Auswirkung getrennt von Dringlichkeit bewertet? - [ ] Ist die vorläufige Priorität begründet? - [ ] Ist ein Zeitpunkt für die Neubewertung festgelegt? --- **Checkliste für hohe Priorität** - [ ] Sind die Kriterien für hohe Priorität tatsächlich erfüllt? - [ ] Ist ein kritischer Service oder Geschäftsprozess betroffen? - [ ] Besteht erheblicher Benutzer- oder Kundenbezug? - [ ] Besteht keine ausreichende Zwischenlösung? - [ ] Nimmt der Schaden weiter zu? - [ ] Besteht Sicherheits-, Datenschutz- oder Datenverlustbezug? - [ ] Sind notwendige Fachteams informiert? - [ ] Ist Incident-Koordination erforderlich? - [ ] Sind Lieferanten erreichbar und eingebunden? - [ ] Ist die Kommunikationsverantwortung geklärt? - [ ] Sind Statusintervalle festgelegt? - [ ] Wird die Priorität regelmäßig neu bewertet? --- **Checkliste für eine Prioritätsänderung** - [ ] Welche neue Information liegt vor? - [ ] Hat sich die Auswirkung verändert? - [ ] Hat sich die Dringlichkeit verändert? - [ ] Ist ein Workaround verfügbar oder ausgefallen? - [ ] Sind weitere Benutzer oder Services betroffen? - [ ] Ist ein neuer Sicherheits- oder Datenbezug entstanden? - [ ] Wer hat die Änderung entschieden? - [ ] Wurde der Grund dokumentiert? - [ ] Wurden Eskalationen angepasst? - [ ] Wurden Benutzer und Stakeholder informiert? - [ ] Wurden Zielzeiten und Statusintervalle aktualisiert? --- **Checkliste für das Prioritätsmodell der Organisation** - [ ] Sind Auswirkung und Dringlichkeit eindeutig definiert? - [ ] Sind die Bewertungsstufen verständlich? - [ ] Sind kritische Services bekannt? - [ ] Werden Sicherheits- und Datenschutzereignisse angemessen behandelt? - [ ] Werden Gesundheits- und Sicherheitsrisiken berücksichtigt? - [ ] Sind Prioritätsstufen eindeutig beschrieben? - [ ] Sind Zielzeiten und Statusintervalle realistisch? - [ ] Ist festgelegt, wer Prioritäten ändern darf? - [ ] Sind Ausnahmen und Eskalationen geregelt? - [ ] Werden Workarounds angemessen berücksichtigt? - [ ] Werden Prioritätsänderungen dokumentiert? - [ ] Werden Fehlpriorisierungen ausgewertet? - [ ] Wird Prioritätsinflation überwacht? - [ ] Wird das Modell regelmäßig verbessert? --- **Schnellreferenz** | Frage | Zu bewertender Bereich | |---|---| | Wie viele Benutzer sind betroffen? | Auswirkung | | Welcher Service ist betroffen? | Auswirkung | | Welcher Geschäftsprozess steht still? | Auswirkung | | Besteht Daten- oder Sicherheitsrisiko? | Auswirkung und Dringlichkeit | | Gibt es einen geeigneten Workaround? | Auswirkung und Dringlichkeit | | Wann verschlimmert sich die Situation? | Dringlichkeit | | Welche Frist läuft ab? | Dringlichkeit | | Wie schnell muss gehandelt werden? | Dringlichkeit | | In welcher Reihenfolge wird bearbeitet? | Priorität | | Welche Zielzeiten gelten? | Priorität und Service Level | | Ist besondere Koordination notwendig? | Eskalation oder Major Incident | | Muss die Bewertung geändert werden? | dynamische Neubewertung | --- **Zusammenfassende Darstellung** > Incident oder Request wird erfasst > ↓ > betroffenen Service und Geschäftsprozess bestimmen > ↓ > Anzahl und Bedeutung der betroffenen Stakeholder bewerten > ↓ > Daten-, Sicherheits-, Finanz- und Kundenfolgen berücksichtigen > ↓ > **Auswirkung bestimmen** > ↓ > Zeitdruck, Verschlechterung, Fristen und Workaround bewerten > ↓ > **Dringlichkeit bestimmen** > ↓ > organisatorische Matrix oder Entscheidungsregel anwenden > ↓ > **Priorität festlegen und begründen** > ↓ > Zielzeiten, Ownership, Eskalation und Kommunikation auslösen > ↓ > Situation fortlaufend beobachten > ↓ > Priorität bei neuen Erkenntnissen erhöhen oder senken > ↓ > Entscheidung und Auswirkungen nachvollziehbar dokumentieren --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.2 Kontaktkanäle und Erreichbarkeit - 3.3 Benutzerkommunikation und professioneller Umgang - 3.4 Tickets vollständig erfassen und kategorisieren - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Information Security Management - Service Level Management - Service Continuity Management - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL 4 Practitioner – Incident Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-incident-management-3684) - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) - [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) **Offiziell bestätigter Stand** Die offiziellen ITIL- und PeopleCert-Quellen bestätigen: - Incident Management dient der schnellen Wiederherstellung des normalen Servicebetriebs nach Störungen. - Incident Management umfasst Prozesse, Rollen, Informationen, Technologien, Partner, Messgrößen und die Integration in organisatorische Wertströme. - Einheitliche Arbeitsweisen und ein gemeinsames Verständnis helfen, inkonsistente Priorisierung und übersehene wichtige Vorgänge zu vermeiden. - Service-Desk- und Incident-Management-Practices müssen an organisatorische Bedürfnisse, Wertströme und Services angepasst werden. - ITIL Version 5 führt die Management Practices fort und richtet digitale Servicearbeit an Outcomes, Erfahrung, Resilienz und Ende-zu-Ende-Zusammenarbeit aus. **Einordnung** Die auf dieser Seite dargestellten: - Auswirkungs- und Dringlichkeitsstufen, - Prioritätsmatrix, - P1-bis-P4-Bezeichnungen, - Zielzeitbeispiele, - Statusintervalle, - Entscheidungskriterien, - Praxisbeispiele, - und Checklisten sind herstellerneutrale redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks. ITIL schreibt keine universelle: - Prioritätsmatrix, - Anzahl von Prioritätsstufen, - Reaktionszeit, - Wiederherstellungszeit, - Severity-Skala, - VIP-Regel, - oder Major-Incident-Grenze für alle Organisationen vor. Die konkrete Gestaltung muss angepasst werden an: - Produkte und Services, - Geschäftsprozesse, - Servicekritikalität, - Benutzer und Kunden, - Sicherheits- und Datenschutzanforderungen, - gesetzliche Verpflichtungen, - Servicezeiten, - Fähigkeiten, - Lieferanten, - verfügbare Ressourcen. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 1/2) > **Kurz erklärt** > > Ziel der Erstdiagnose ist nicht, sofort die eigentliche Ursache zu kennen, sondern möglichst schnell die Situation zu verstehen, Auswirkungen zu begrenzen und den Service wiederherzustellen. > > Gute Diagnosen beruhen auf: > > - Beobachtungen, > - überprüfbaren Fakten, > - strukturierten Tests, > - technischem Wissen, > - vorhandenen Erfahrungen, > - und nachvollziehbaren Entscheidungen. > > ITIL empfiehlt, vorhandenes Wissen systematisch zu nutzen und Incidents möglichst früh dort zu lösen, wo die erforderlichen Fähigkeiten vorhanden sind. --- ## Ziele der Erstdiagnose Nach der Ticketaufnahme beginnt die eigentliche Analyse. Dabei sollten zunächst folgende Fragen beantwortet werden: - Was funktioniert nicht? - Was funktioniert noch? - Seit wann besteht die Störung? - Wer ist betroffen? - Welche Änderungen gab es kurz zuvor? - Welche Systeme hängen zusammen? - Gibt es bereits bekannte Incidents? - Existiert ein Workaround? Die Erstdiagnose soll möglichst schnell klären, - ob der Service wiederhergestellt werden kann, - ob Spezialisten benötigt werden, - oder ob eine funktionale Eskalation notwendig ist. --- ## Erstdiagnose ist keine Ursachenanalyse Ein häufiger Fehler besteht darin, bereits in den ersten Minuten die eigentliche Ursache finden zu wollen. Die Erstdiagnose verfolgt jedoch ein anderes Ziel. | Erstdiagnose | Ursachenanalyse | |---|---| | Service möglichst schnell wiederherstellen | eigentliche Ursache dauerhaft finden | | Minuten bis Stunden | Stunden bis Tage | | Incident Management | Problem Management | | Fokus auf Wiederherstellung | Fokus auf Prävention | Beispiel: Ein Webserver antwortet nicht. Während der Erstdiagnose genügt möglicherweise: - Dienst neu starten, - Funktion prüfen, - Benutzer informieren. Warum der Dienst abgestürzt ist, wird später im Problem Management untersucht. > **Merke** > > Ein gelöster Incident bedeutet nicht automatisch, dass die Ursache beseitigt wurde. --- ## Beobachtung vor Interpretation Techniker neigen häufig dazu, sehr früh Vermutungen aufzustellen. Besser ist folgende Reihenfolge: 1. Beobachten 2. Informationen sammeln 3. Hypothesen bilden 4. Hypothesen testen 5. Ursache bestätigen Beispiel: ❌ "Die Firewall blockiert den Zugriff." Besser: ✅ "HTTPS-Verbindungen schlagen fehl. Andere Protokolle funktionieren. Firewall ist eine mögliche Ursache." --- ## Symptome richtig erfassen Ein Symptom beschreibt das beobachtete Verhalten. Beispiele: - Anmeldung schlägt fehl - Druckauftrag bleibt hängen - Anwendung reagiert nicht - Datei lässt sich nicht öffnen - VPN verbindet nicht Ein Symptom ist noch keine Ursache. --- ## Mögliche Ursachen Für dasselbe Symptom können völlig unterschiedliche Ursachen verantwortlich sein. **Symptom** > Anmeldung nicht möglich Mögliche Ursachen: - Passwort falsch - Konto gesperrt - Active Directory nicht erreichbar - DNS-Problem - Netzwerkfehler - Zertifikat abgelaufen - MFA-Dienst gestört - Cloud-Ausfall Deshalb sollten Vermutungen immer überprüft werden. --- ## Strukturierte Diagnose Eine bewährte Reihenfolge lautet: 1. Problem verstehen 2. Umfang bestimmen 3. Änderungen prüfen 4. Logs prüfen 5. Monitoring prüfen 6. Verbindung testen 7. Komponenten eingrenzen 8. Hypothese testen 9. Ergebnis dokumentieren --- ## Umfang bestimmen Nicht jede Störung betrifft alle Benutzer. Zu klären ist: - Ein Benutzer? - Mehrere Benutzer? - Ein Standort? - Alle Standorte? - Nur Windows? - Auch macOS? - Nur VPN? - Auch intern? Je genauer der Umfang bekannt ist, desto einfacher lässt sich die Ursache eingrenzen. --- ## Änderungen berücksichtigen Viele Incidents entstehen kurz nach Änderungen. Zu prüfen sind beispielsweise: - Software-Updates - neue Firewall-Regeln - Zertifikatswechsel - DNS-Änderungen - neue Switch-Konfiguration - Benutzeränderungen - Gruppenrichtlinien - Cloud-Änderungen Frage: > **Was hat sich kurz vor dem Fehler geändert?** Diese Frage spart häufig sehr viel Diagnosezeit. --- ## Reproduzierbarkeit prüfen Ein Fehler sollte möglichst reproduziert werden. Beispiel: 1. Anwendung starten 2. Benutzer anmelden 3. Auftrag öffnen 4. Speichern Tritt der Fehler jedes Mal auf? Oder nur gelegentlich? Auch diese Information grenzt Ursachen erheblich ein. --- ## Bekannte Fehler nutzen Vor aufwendigen Analysen sollte geprüft werden: - Gibt es einen bekannten Incident? - Existiert ein Knowledge-Artikel? - Hat der Hersteller bereits einen Hinweis veröffentlicht? - Gab es ähnliche Tickets? Viele Incidents lassen sich dadurch deutlich schneller lösen. --- ## Monitoring verwenden Monitoring liefert häufig frühere Hinweise als Benutzer. Beispiele: - CPU-Auslastung - RAM - Festplattenspeicher - Netzwerk - Dienste - Zertifikate - Backup - Hardware Monitoring ersetzt jedoch keine Diagnose. Es zeigt häufig nur Symptome. --- ## Logs richtig einsetzen Logs beantworten häufig Fragen wie: - Wann trat der Fehler auf? - Welche Komponente war beteiligt? - Welche Fehlermeldung wurde erzeugt? - Welche Benutzer waren betroffen? Dabei gilt: Nicht jede Warnung ist automatisch relevant. Logs müssen immer im Zusammenhang betrachtet werden. --- ## Ausschlussverfahren Eine sehr effektive Methode ist das Ausschlussprinzip. Beispiel: VPN funktioniert nicht. Prüfung: - Internet vorhanden ✔️ - DNS funktioniert ✔️ - Anmeldung funktioniert ✔️ - VPN-Server erreichbar ✔️ - Zertifikat gültig ❌ Die Ursache lässt sich dadurch systematisch eingrenzen. --- ## Von einfach nach komplex ITIL empfiehlt keine feste Reihenfolge. In der Praxis hat sich jedoch bewährt: 1. Offensichtliches prüfen 2. Bekannte Fehler prüfen 3. Änderungen prüfen 4. Monitoring prüfen 5. Logs prüfen 6. Detailanalyse Nicht sofort mit der kompliziertesten Hypothese beginnen. --- ## Keine unnötigen Änderungen Während der Diagnose sollte möglichst nicht gleichzeitig an mehreren Komponenten gearbeitet werden. Schlecht: - Firewall ändern - DNS ändern - Server neu starten - Zertifikat erneuern Danach ist kaum nachvollziehbar, welche Maßnahme tatsächlich geholfen hat. Besser: Eine Änderung durchführen. Ergebnis prüfen. Dokumentieren. Erst danach die nächste Maßnahme. --- ## Hypothesen dokumentieren Eine gute Arbeitsnotiz enthält: **Hypothese** DNS-Auflösung fehlerhaft. **Test** Namensauflösung gegen internen DNS geprüft. **Ergebnis** DNS funktioniert. **Schlussfolgerung** Hypothese verworfen. Dadurch vermeiden andere Bearbeiter dieselben Tests. --- ## Wissen systematisch nutzen Erfahrungen sollten nicht ausschließlich im Kopf einzelner Administratoren bleiben. Hilfreich sind: - Knowledge-Artikel - Standardlösungen - Runbooks - Checklisten - bekannte Fehler - Herstellerdokumentation Dadurch steigt die First Contact Resolution deutlich. --- ## First Contact Resolution (FCR) FCR beschreibt den Anteil der Incidents, die bereits beim ersten Kontakt vollständig gelöst werden. Vorteile: - kürzere Wartezeit - zufriedenere Benutzer - weniger Eskalationen - geringere Kosten FCR darf jedoch nicht künstlich erhöht werden, indem Tickets vorschnell geschlossen werden. --- ## Shift Left Shift Left bedeutet, Wissen möglichst früh im Support bereitzustellen. Beispiele: - bessere Wissensdatenbank - Self-Service - Standardlösungen - Automatisierung - KI-Unterstützung - Schulungen Dadurch können mehr Incidents bereits im Service Desk gelöst werden. --- ## Dokumentation während der Diagnose Nicht erst am Ende dokumentieren. Nach jeder wichtigen Maßnahme sollte festgehalten werden: - Zeitpunkt - Maßnahme - Ergebnis - nächster Schritt Dadurch bleiben Übergaben nachvollziehbar. --- ## Merksätze > Symptome sind keine Ursachen. > Beobachtungen sind wichtiger als Vermutungen. > Erst den Service wiederherstellen, anschließend die eigentliche Ursache untersuchen. > Jede Diagnose sollte nachvollziehbar dokumentiert werden. > Bekannte Lösungen sind schneller als neue Vermutungen. # 3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 2/2) > **Kurz erklärt** > > Die Erstdiagnose soll einen Incident schnell verstehen, eingrenzen und möglichst früh beheben. > > Dabei geht es zunächst nicht darum, die endgültige Ursache vollständig zu ermitteln. Das wichtigste Ziel des Incident Managements ist die schnelle Wiederherstellung des vereinbarten Servicebetriebs. > > Kann der Incident mit den vorhandenen Kenntnissen, Werkzeugen oder Berechtigungen nicht gelöst werden, erfolgt eine **funktionale Eskalation** an eine geeignete Fachgruppe. --- **Ziele der Erstdiagnose** Die Erstdiagnose soll möglichst schnell klären: - Was funktioniert nicht? - Was funktioniert weiterhin? - Wer oder was ist betroffen? - Seit wann besteht die Beeinträchtigung? - Welche Auswirkungen entstehen? - Gab es kurz zuvor einen Change? - Ist bereits ein ähnlicher Incident bekannt? - Existiert ein dokumentierter Workaround? - Kann der Service Desk den Incident direkt lösen? - Welche Fachkenntnisse werden andernfalls benötigt? Eine gute Erstdiagnose reduziert: - unnötige Rückfragen, - doppelte Prüfungen, - falsche Eskalationen, - lange Bearbeitungszeiten, - und vermeidbare Serviceunterbrechungen. --- **Erstdiagnose und Ursachenanalyse unterscheiden** Die Erstdiagnose gehört in erster Linie zum Incident Management. Die tiefergehende Ursachenanalyse gehört häufig zum Problem Management. | Erstdiagnose | Ursachenanalyse | |---|---| | Service möglichst schnell wiederherstellen | zugrunde liegende Ursache untersuchen | | kurzfristiger Fokus | langfristiger Fokus | | Workaround oder schnelle Lösung möglich | dauerhafte Lösung vorbereiten | | Incident Management | Problem Management | | Minuten bis Stunden | abhängig von Komplexität auch deutlich länger | Beispiel: Ein Anwendungsdienst reagiert nicht mehr. **Incident Management** - Dienst kontrolliert neu starten - Funktion testen - Benutzer informieren - Service wiederherstellen **Problem Management** - Ursache des Absturzes untersuchen - Speicherverbrauch analysieren - Softwarefehler prüfen - dauerhafte Korrektur planen > **Merke** > > Ein Incident kann gelöst sein, obwohl die eigentliche Ursache noch nicht bekannt oder beseitigt ist. --- **Symptom, Ursache und Auswirkung unterscheiden** | Begriff | Bedeutung | Beispiel | |---|---|---| | **Symptom** | beobachtetes Fehlverhalten | Anmeldung schlägt fehl | | **unmittelbare Ursache** | direkter technischer Auslöser | Zertifikat abgelaufen | | **Grundursache** | tiefer liegende Ursache | Zertifikatsüberwachung fehlte | | **Auswirkung** | Folge für Benutzer oder Geschäftsprozess | Benutzer können nicht arbeiten | Zu Beginn eines Incidents ist häufig nur das Symptom bekannt. Die Ursache darf deshalb nicht vorschnell als bestätigt dokumentiert werden. Ungeeignet: > Die Firewall blockiert die Anwendung. Besser: > HTTPS-Verbindungen zur Anwendung schlagen fehl. Eine Blockierung durch die Firewall ist eine mögliche, noch nicht bestätigte Ursache. --- **Beobachtung und Vermutung trennen** Eine strukturierte Diagnose folgt möglichst dieser Reihenfolge: 1. beobachten 2. Informationen sammeln 3. Umfang bestimmen 4. Hypothesen bilden 5. Hypothesen testen 6. Ergebnisse bewerten 7. Service wiederherstellen 8. Maßnahmen dokumentieren Beobachtungen sollten möglichst messbar sein. Ungeeignet: > Das Netzwerk ist langsam. Besser: > Die Antwortzeit zum Gateway liegt normalerweise unter 5 ms. Aktuell werden zwischen 80 und 150 ms sowie Paketverluste von etwa 12 Prozent gemessen. --- **Den Umfang bestimmen** Der Umfang hilft bei der Eingrenzung. Zu prüfen ist beispielsweise: - Ist nur ein Benutzer betroffen? - Sind mehrere Benutzer betroffen? - Ist ein gesamter Standort betroffen? - Betrifft der Fehler alle Geräte oder nur ein bestimmtes? - Ist nur eine Anwendung betroffen? - Funktioniert der Service intern, aber nicht über VPN? - Sind nur neue Anmeldungen betroffen? - Funktionieren bestehende Sitzungen weiterhin? - Sind bestimmte Betriebssysteme oder Versionen betroffen? Beispiel: Eine Anwendung startet bei einem Benutzer nicht. Prüfung: - anderer Benutzer am selben Gerät: funktioniert - derselbe Benutzer an anderem Gerät: funktioniert nicht - andere Anwendungen: funktionieren Damit liegt die Ursache wahrscheinlich eher im Benutzerkonto oder Benutzerprofil als im Gerät. --- **Den Normalzustand kennen** Für die Diagnose muss bekannt sein, was normalerweise geschehen sollte. Beispiel: > Nach Eingabe der Zugangsdaten sollte innerhalb weniger Sekunden die Startseite erscheinen. Stattdessen bleibt der Ladebildschirm dauerhaft sichtbar. Diese Beschreibung ist aussagekräftiger als: > Anmeldung funktioniert nicht. Hilfreiche Fragen: - Was wollten Sie durchführen? - Was sollte normalerweise geschehen? - Was geschieht stattdessen? - Wird eine Fehlermeldung angezeigt? - Wann hat es zuletzt funktioniert? --- **Änderungen berücksichtigen** Viele Incidents treten nach Änderungen auf. Zu prüfen sind beispielsweise: - Softwareupdates - neue Firewall-Regeln - DNS-Änderungen - Zertifikatswechsel - Gruppenrichtlinien - Benutzer- oder Berechtigungsänderungen - Firmwareupdates - Netzwerkumbauten - Cloud-Konfigurationsänderungen - Änderungen durch Lieferanten Eine wichtige Diagnosefrage lautet: > Was hat sich kurz vor Beginn des Fehlers verändert? Ein zeitlicher Zusammenhang beweist jedoch noch keine Ursache. Der Change muss fachlich überprüft werden. --- **Bekannte Incidents und Fehler prüfen** Vor einer aufwendigen Analyse sollte geprüft werden: - Gibt es bereits einen aktiven Incident? - Ist eine allgemeine Störung bekannt? - Existiert ein Problem Record? - Gibt es einen Known Error? - Ist ein geeigneter Knowledge-Artikel vorhanden? - Hat der Hersteller eine Störung oder ein bekanntes Problem gemeldet? - Wurde dieselbe Kombination aus Symptom und Service bereits dokumentiert? Dadurch lassen sich doppelte Analysen vermeiden. --- **Monitoring verwenden** Monitoring kann wichtige Hinweise liefern. Typische Messwerte: - CPU-Auslastung - Arbeitsspeicher - Speicherplatz - Dienststatus - Netzwerkverbindungen - Antwortzeiten - Fehlerraten - Zertifikatsgültigkeit - Backup-Status - Hardwarezustand - Cloud-Service-Status Monitoring zeigt jedoch häufig nur ein Symptom. Beispiel: > CPU-Auslastung 100 Prozent Dies beweist noch nicht, welcher Prozess oder welche Ursache verantwortlich ist. --- **Logs gezielt auswerten** Logs können zeigen: - wann ein Fehler begann, - welche Komponente beteiligt war, - welche Meldung erzeugt wurde, - welches Konto verwendet wurde, - und welche Aktion fehlgeschlagen ist. Bei der Auswertung sollte geprüft werden: - Passt der Zeitstempel zum Incident? - Betrifft die Meldung wirklich den betroffenen Service? - Ist es ein Fehler, eine Warnung oder nur eine Information? - Tritt die Meldung auch im Normalbetrieb auf? - Gibt es zeitlich passende Changes oder Events? Nicht jede rote Fehlermeldung ist für den aktuellen Incident relevant. --- **Reproduzierbarkeit prüfen** Ein reproduzierbarer Fehler lässt sich leichter eingrenzen. Zu dokumentieren sind: - genaue Arbeitsschritte - verwendete Anwendung - Version - Gerät oder Betriebssystem - Benutzerkonto - verwendete Daten - erwartetes Verhalten - tatsächliches Verhalten - Fehlermeldung Beispiel: 1. Anwendung öffnen 2. Auftrag auswählen 3. „PDF exportieren“ anklicken 4. Anwendung beendet sich ohne Meldung Zusatz: - tritt bei drei getesteten Aufträgen auf - nur Desktop-Version betroffen - Webversion funktioniert --- **Vom Einfachen zum Komplexen** Eine sinnvolle Praxisreihenfolge kann sein: 1. Meldung und Auswirkungen verstehen 2. bekannte Störungen prüfen 3. offensichtliche Voraussetzungen prüfen 4. Änderungen vergleichen 5. Monitoring und Logs auswerten 6. Fehlerbereich eingrenzen 7. Hypothesen testen 8. Spezialisten einbinden Dies ist keine feste ITIL-Vorgabe. Es verhindert jedoch, dass sofort mit besonders aufwendigen oder riskanten Maßnahmen begonnen wird. --- **Ausschlussverfahren** Beim Ausschlussverfahren werden mögliche Fehlerbereiche systematisch geprüft. Beispiel: VPN-Verbindung funktioniert nicht. | Prüfung | Ergebnis | |---|---| | Internetverbindung vorhanden | ja | | DNS-Auflösung funktioniert | ja | | VPN-Gateway erreichbar | ja | | Benutzerkonto aktiv | ja | | MFA erfolgreich | ja | | Client-Zertifikat gültig | nein | Damit wurde der Fehler auf das Zertifikat eingegrenzt. > **Merke** > > Jeder Test sollte eine konkrete Hypothese bestätigen oder verwerfen. --- **Hypothesen dokumentieren** Eine gute Arbeitsnotiz kann folgendermaßen aufgebaut sein: **Hypothese** DNS-Auflösung ist fehlerhaft. **Test** Interne und externe Namensauflösung mit dem vorgesehenen DNS-Server geprüft. **Ergebnis** Name wird korrekt aufgelöst. **Schlussfolgerung** Hypothese verworfen. Dadurch muss die nächste bearbeitende Person denselben Test nicht wiederholen. --- **Nur kontrollierte Maßnahmen durchführen** Während der Diagnose sollten nicht mehrere Änderungen gleichzeitig vorgenommen werden. Ungeeignet: - DNS ändern - Firewall-Regel anpassen - Dienst neu starten - Zertifikat erneuern - Server neu starten Wenn der Service anschließend funktioniert, ist nicht erkennbar, welche Maßnahme wirksam war. Besser: 1. Maßnahme planen 2. Risiko bewerten 3. Maßnahme durchführen 4. Ergebnis prüfen 5. dokumentieren 6. erst danach nächsten Schritt festlegen Produktive Änderungen müssen entsprechend den Regeln des Change Enablement durchgeführt werden. --- **Neustarts bewusst einsetzen** Ein Neustart kann ein sinnvoller Workaround sein. Er darf jedoch nicht reflexartig verwendet werden. Vorher sollte geprüft werden: - Gehen flüchtige Diagnoseinformationen verloren? - Werden Benutzer oder andere Services unterbrochen? - Besteht Datenverlustrisiko? - Ist eine Genehmigung erforderlich? - Gibt es eine weniger eingreifende Maßnahme? - Kann der Fehler nach dem Neustart weiterhin analysiert werden? ... *(Fortsetzung wegen Nachrichtenlängenlimit erforderlich)* # 3.7 Ownership, hierarchische Eskalation und Major Incidents (Teil 1/2) > **Kurz erklärt** > > Jeder Incident muss jederzeit einen eindeutig verantwortlichen Bearbeiter oder eine verantwortliche Gruppe besitzen. > > ITIL bezeichnet dies als **Ownership**. > > Ownership bedeutet nicht zwingend, dass diese Person den Fehler selbst behebt. Sie trägt jedoch die Verantwortung dafür, dass der Incident aktiv verfolgt, koordiniert und bis zum Abschluss begleitet wird. --- **Was bedeutet Ownership?** Ownership beantwortet die Frage: > **Wer kümmert sich aktuell um diesen Incident?** Der Owner sorgt dafür, dass: - der Incident aktiv bearbeitet wird, - keine unnötigen Wartezeiten entstehen, - Eskalationen rechtzeitig erfolgen, - Benutzer informiert werden, - der nächste Schritt bekannt ist, - und der Vorgang sauber abgeschlossen wird. Ownership bleibt bestehen – auch wenn andere Teams beteiligt werden. --- **Ownership ist nicht gleich Bearbeitung** Ein häufiger Irrtum: > Wer gerade technisch arbeitet, ist automatisch für den gesamten Incident verantwortlich. Das stimmt nicht. Beispiel: Der Service Desk erstellt ein Ticket und eskaliert es an das Netzwerkteam. Während das Netzwerkteam analysiert, kann der Service Desk weiterhin Owner bleiben und: - Rückfragen koordinieren, - den Benutzer informieren, - Fortschritte überwachen, - Zielzeiten prüfen, - und notwendige Eskalationen auslösen. Der technische Bearbeiter führt also eine konkrete Aufgabe aus. Der Owner sorgt dafür, dass der Incident insgesamt gesteuert wird. --- **Zuständigkeit, Bearbeitung und Ownership unterscheiden** | Begriff | Bedeutung | |---|---| | **Ownership** | Verantwortung für den gesamten Incident bis zum Abschluss | | **Bearbeitung** | Durchführung aktueller technischer oder organisatorischer Maßnahmen | | **Zuständigkeit** | fachliche Verantwortung für einen bestimmten Service, Bereich oder eine Komponente | | **Kommunikationsverantwortung** | Verantwortung für Statusmeldungen an Benutzer und Stakeholder | | **Entscheidungsverantwortung** | Befugnis, Prioritäten, Ressourcen oder Vorgehen festzulegen | Mehrere Personen oder Teams können gleichzeitig an einem Incident arbeiten. Der Owner sollte jedoch eindeutig festgelegt sein. --- **Warum Ownership wichtig ist** Ohne klaren Owner entstehen häufig: - doppelte Arbeiten, - lange Wartezeiten, - vergessene Tickets, - fehlende Kommunikation, - unklare Verantwortlichkeiten, - Ticket-Pingpong, - verspätete Eskalationen, - und unklare Abschlüsse. Typische Aussage: > Ich dachte, das andere Team kümmert sich darum. Genau solche Situationen soll Ownership verhindern. --- **Aufgaben des Owners** Der Owner überwacht den gesamten Incident. Typische Aufgaben: - Ticket kontrollieren, - Bearbeitung verfolgen, - Priorität prüfen, - Eskalationen auslösen, - Benutzer informieren, - Rückmeldungen koordinieren, - beteiligte Teams abstimmen, - Zielzeiten überwachen, - Workaround oder Lösung nachverfolgen, - Abschluss prüfen. Der Owner muss nicht jede technische Aufgabe selbst durchführen. Er muss aber sicherstellen, dass der Incident nicht stehen bleibt. --- **Ownership während einer funktionalen Eskalation** Auch nach einer funktionalen Eskalation bleibt Ownership bestehen. Beispiel: Benutzer ↓ Service Desk (Owner) ↓ Netzwerkteam ↓ Hersteller Das Netzwerkteam untersucht den Fehler. Der Service Desk sorgt weiterhin dafür, dass: - Statusmeldungen erfolgen, - der Benutzer informiert wird, - Fristen eingehalten werden, - offene Rückfragen geklärt werden, - und der Vorgang bis zur Wiederherstellung verfolgt wird. Eine Eskalation bedeutet also nicht automatisch, dass die Gesamtverantwortung verschwindet. --- **Ownership übertragen** In manchen Organisationen kann Ownership wechseln. Beispiele: - Service Desk → Netzwerkteam - Netzwerkteam → Incident Manager - Incident Manager → Major Incident Manager - Service Desk → Produktteam - internes Team → externer Provider mit interner Koordination Dabei sollte immer dokumentiert werden: - Zeitpunkt, - bisheriger Owner, - neuer Owner, - Grund der Übergabe, - aktueller Status, - nächster Schritt, - und Kommunikationsverantwortung. Eine Übergabe ist nur dann sinnvoll, wenn die neue Verantwortung eindeutig akzeptiert wurde. --- **Ein Ticket darf niemals besitzerlos sein** Ein Incident ohne Owner ist eines der größten Risiken im Support. Jeder Incident sollte jederzeit erkennen lassen: - Wer ist verantwortlich? - Wer arbeitet aktuell? - Wer informiert den Benutzer? - Wer entscheidet über Eskalationen? - Wer verfolgt Zielzeiten? - Wer prüft die Wiederherstellung? - Wer schließt den Vorgang ab? > **Merke** > > Ein zugewiesenes Ticket ist nicht automatisch ein aktiv gesteuerter Incident. --- **Funktionale und hierarchische Eskalation unterscheiden** Diese beiden Begriffe werden häufig verwechselt. | Funktionale Eskalation | Hierarchische Eskalation | |---|---| | fehlendes Fachwissen oder fehlende Berechtigung | Management-Unterstützung oder Entscheidung erforderlich | | Spezialisten notwendig | Priorisierung, Ressourcen oder Risikoentscheidung notwendig | | technischer Fokus | organisatorischer oder geschäftlicher Fokus | | Beispiel: Netzwerkteam einbinden | Beispiel: Service Owner oder Management informieren | | Ziel: richtige Fähigkeit einbinden | Ziel: Hindernisse, Risiken oder Entscheidungen klären | --- **Funktionale Eskalation** Die funktionale Eskalation wurde bereits in **3.6 Erstdiagnose, Lösung und funktionale Eskalation** behandelt. Beispiele: - Service Desk → Netzwerkteam - Service Desk → Serverteam - Service Desk → Datenbankteam - Service Desk → Cloud-Team - internes Team → Hersteller oder Lieferant Ziel: Die richtigen Spezialisten bearbeiten den Incident. Eine funktionale Eskalation ist keine Schuldzuweisung. Sie bedeutet nur, dass zusätzliche Fähigkeiten, Werkzeuge oder Berechtigungen benötigt werden. --- **Hierarchische Eskalation** Bei einer hierarchischen Eskalation wird nicht primär weiteres Fachwissen benötigt. Benötigt werden beispielsweise: - Entscheidungen, - Ressourcen, - Priorisierung, - Budget, - Management-Unterstützung, - Freigaben, - Konfliktlösung, - oder Kommunikation auf höherer Ebene. Beispiele: - SLA wird voraussichtlich verletzt. - Mehrere Fachbereiche sind betroffen. - Management muss informiert werden. - Ein externer Kunde eskaliert. - Ein Lieferant reagiert nicht. - Zusätzliche Ressourcen werden benötigt. - Ein Risiko kann nicht auf operativer Ebene entschieden werden. - Erheblicher Imageschaden ist möglich. --- **Wann sollte eskaliert werden?** Nicht erst, wenn: - ein SLA bereits verletzt wurde, - der Benutzer mehrfach angerufen hat, - Management sich beschwert, - oder ein Incident längere Zeit unbeachtet blieb. Sondern bereits dann, wenn erkennbar wird: - ein Ziel wird wahrscheinlich verfehlt, - weitere Unterstützung wird benötigt, - Risiken steigen, - Ressourcen nicht ausreichen, - Entscheidungen fehlen, - die Kommunikation nicht mehr ausreicht, - oder der Incident eine besondere geschäftliche Bedeutung bekommt. > **Merke** > > Gute Eskalation ist rechtzeitig, begründet und handlungsorientiert. --- **Eskalation bedeutet keine Schuld** Eine Eskalation ist keine Kritik an einzelnen Mitarbeitern. Sie dient dazu: - Hindernisse zu beseitigen, - Entscheidungen schneller zu treffen, - zusätzliche Ressourcen bereitzustellen, - Risiken sichtbar zu machen, - Kommunikation zu verbessern, - und den Service schneller wiederherzustellen. Ungeeignet: > Wir eskalieren, weil das Team es nicht schafft. Besser: > Wir eskalieren, weil die Zielzeit gefährdet ist und zusätzliche Entscheidungskompetenz benötigt wird. --- **Kommunikationseskalation** Manchmal funktioniert die technische Bearbeitung, aber die Kommunikation reicht nicht aus. Beispiele: - Benutzer erhält keine Rückmeldung. - Management verlangt Statusberichte. - Mehrere Standorte müssen informiert werden. - Es gibt widersprüchliche Aussagen. - Ein Kunde benötigt eine abgestimmte externe Meldung. - Der Service Desk besitzt keine freigegebene Kommunikationslinie. Auch hierfür kann eine Eskalation notwendig sein. Die technische Lösung und die Kommunikation müssen beide gesteuert werden. --- **Major Incident** Ein **Major Incident** ist ein besonders schwerwiegender Incident. Er besitzt normalerweise: - hohe Auswirkungen, - hohe Dringlichkeit, - viele betroffene Benutzer, - kritische betroffene Services, - erhebliche geschäftliche Folgen, - erhöhten Kommunikationsbedarf, - oder besondere Risiken. ITIL schreibt keine universelle feste Definition vor. Jede Organisation muss eigene Kriterien festlegen. --- **Mögliche Kriterien für einen Major Incident** Beispiele: - gesamte Produktion steht, - mehrere Standorte sind betroffen, - ein geschäftskritischer Service ist ausgefallen, - zentrale Anmeldung funktioniert nicht, - kritische Cloud-Dienste sind nicht verfügbar, - ein Sicherheitsvorfall wird vermutet, - externer Kundenimpact ist erheblich, - keine geeignete Zwischenlösung ist verfügbar, - gesetzliche oder vertragliche Fristen sind gefährdet, - Management- oder Krisenkommunikation ist notwendig. Die Kriterien sollten dokumentiert und regelmäßig überprüft werden. --- **Major Incident ist nicht automatisch P1** Viele Organisationen setzen: > P1 = Major Incident Dies ist jedoch keine allgemeine ITIL-Vorgabe. Ein P1-Incident kann ein Major Incident sein. Er muss es aber nicht in jeder Organisation automatisch sein. | P1 | Major Incident | |---|---| | beschreibt häufig die höchste operative Priorität | beschreibt einen besonders schwerwiegenden Incident mit besonderer Koordination | | steuert Zielzeiten und Bearbeitungsreihenfolge | aktiviert zusätzliche Rollen, Kommunikation und Steuerung | | kann durch normale Supportstruktur bearbeitet werden | benötigt häufig besondere Koordination | | wird meist aus Auswirkung und Dringlichkeit bestimmt | kann zusätzliche Kriterien enthalten | > **Merke** > > Priorität und Major-Incident-Status sollten bewusst unterschieden oder eindeutig gemeinsam definiert werden. --- **Ziele eines Major-Incident-Verfahrens** Bei normalen Incidents liegt der Fokus häufig auf der technischen Wiederherstellung. Bei Major Incidents kommen zusätzliche Aufgaben hinzu: - Koordination mehrerer Teams, - schnelle Entscheidungsfindung, - klare Kommunikation, - Priorisierung von Ressourcen, - Management-Unterstützung, - Lieferantensteuerung, - Risikoüberwachung, - Dokumentation unter Zeitdruck, - und spätere Nachbereitung. Das Ziel bleibt die Wiederherstellung des Services. Der Weg dorthin benötigt jedoch mehr Steuerung. --- **Major Incident Manager** Viele Organisationen benennen für Major Incidents einen eigenen **Major Incident Manager**. Diese Person repariert normalerweise nichts selbst. Typische Aufgaben: - Teams koordinieren, - Status sammeln, - Entscheidungen vorbereiten, - Kommunikationsfreigaben abstimmen, - Prioritäten überwachen, - Eskalationen auslösen, - War Room steuern, - Statusintervalle einhalten, - und die Nachbereitung vorbereiten. Der Major Incident Manager sorgt dafür, dass Spezialisten arbeiten können, ohne die Gesamtkoordination nebenbei leisten zu müssen. --- **Typischer Ablauf eines Major Incidents** Incident erkannt ↓ erste Bewertung ↓ Major-Incident-Kriterien prüfen ↓ Major Incident bestätigen oder ablehnen ↓ Owner und Major Incident Manager festlegen ↓ Fachteams und Lieferanten einbinden ↓ Kommunikation starten ↓ Workaround oder Wiederherstellung umsetzen ↓ Service stabilisieren ↓ Abschluss und Nachbereitung Nicht jede Organisation verwendet exakt diesen Ablauf. Entscheidend ist eine klare Koordination. --- **Sofortmaßnahmen bei Major Incidents** Zu Beginn sollte schnell geklärt werden: - Was ist betroffen? - Welche Services sind betroffen? - Welche Standorte sind betroffen? - Welche Benutzer oder Kunden sind betroffen? - Welche geschäftlichen Auswirkungen bestehen? - Seit wann besteht die Störung? - Gibt es einen sicheren Workaround? - Welche Teams werden benötigt? - Gibt es Hinweise auf einen Sicherheitsvorfall? - Wer kommuniziert offiziell? - Wann erfolgt die nächste Statusmeldung? Erst danach beginnt die tiefere technische Analyse. --- **Rollen bei Major Incidents** Typische Rollen können sein: - Service Desk, - Incident Manager, - Major Incident Manager, - technische Spezialisten, - Service Owner, - Kommunikationsverantwortliche, - Management, - Informationssicherheit, - Lieferanten, - Fachbereich, - Problem Manager. Nicht jede Organisation benötigt alle Rollen. Wichtig ist, dass Zuständigkeiten und Entscheidungswege bekannt sind. --- **War Room** Bei kritischen Incidents wird häufig ein gemeinsamer Kommunikationskanal eingerichtet. Beispiele: - Telefonkonferenz, - Videokonferenz, - Microsoft Teams, - Slack, - spezieller Incident-Kanal, - Statusboard. Vorteile: - schnellere Abstimmung, - weniger Rückfragen, - keine parallelen Einzelgespräche, - gemeinsame Faktenlage, - bessere Koordination. Ein War Room benötigt klare Regeln. Sonst entsteht schnell Unübersichtlichkeit. --- **Regeln im War Room** Sinnvolle Regeln: - eine Person koordiniert, - Fakten werden von Vermutungen getrennt, - Maßnahmen werden vor Ausführung abgestimmt, - Ergebnisse werden dokumentiert, - Kommunikation nach außen erfolgt abgestimmt, - Nebenunterhaltungen werden begrenzt, - Entscheidungen werden festgehalten, - nächste Schritte werden eindeutig zugewiesen. Ungeeignet: > Alle diskutieren gleichzeitig technische Vermutungen ohne Dokumentation. Besser: > Hypothesen werden gesammelt, priorisiert, getestet und mit Ergebnis dokumentiert. --- **Kommunikation wird wichtiger** Je größer der Incident, desto wichtiger wird regelmäßige Kommunikation. Stakeholder möchten wissen: - Was ist passiert? - Welche Auswirkungen bestehen? - Was wird aktuell getan? - Gibt es einen Workaround? - Was sollen Benutzer tun oder nicht tun? - Wann gibt es neue Informationen? Auch wenn noch keine Lösung vorliegt, ist eine Statusmeldung sinnvoll. Beispiel: > Die Ursache ist noch nicht bestätigt. Netzwerk- und Identitätsdienste werden geprüft. Ein sicherer Workaround ist derzeit nicht verfügbar. Die nächste Statusmeldung erfolgt um 11:30 Uhr. --- **Statusintervalle** Für kritische Incidents sollten Statusintervalle festgelegt werden. Beispiel: - alle 30 Minuten bei Major Incident, - alle 60 Minuten bei hoher Priorität, - nach wesentlichen Änderungen bei normaler Priorität. Die konkreten Zeiten legt die Organisation selbst fest. Nicht geeignet: > Wir melden uns, wenn alles wieder funktioniert. Besser: > Die nächste Statusmeldung erfolgt spätestens um 10:30 Uhr, auch wenn bis dahin noch keine vollständige Lösung vorliegt. --- **Single Point of Communication** Bei großen Incidents sollte möglichst eine abgestimmte Kommunikationsquelle verwendet werden. Beispiele: - Incident Manager, - Kommunikationsverantwortlicher, - Statusseite, - Service Desk mit freigegebenem Text, - zentrale E-Mail oder Portalnachricht. Dadurch werden widersprüchliche Aussagen vermieden. Technische Detaildiskussionen gehören nicht ungefiltert in Benutzerkommunikation. --- **Stakeholder zielgruppengerecht informieren** | Zielgruppe | Benötigte Informationen | |---|---| | **Benutzer** | Auswirkungen, Workaround, nächste Statusmeldung | | **Service Desk** | freigegebene Formulierung, bekannte Symptome, Ticketverknüpfung | | **technische Teams** | Logs, Hypothesen, Messergebnisse, Maßnahmen | | **Management** | geschäftliche Auswirkungen, Risiken, erwartete Entscheidungen | | **Kunden** | Serviceverfügbarkeit, Einschränkungen, nächstes Update | | **Lieferanten** | technische Nachweise, Versionen, Priorität, gewünschte Unterstützung | | **Informationssicherheit** | Sicherheitsbezug, Beweise, Risiko, Schutzmaßnahmen | Nicht jeder Empfänger benötigt dieselbe Detailtiefe. --- **Ressourcen koordinieren** Bei Major Incidents arbeiten oft mehrere Teams gleichzeitig. Der Major Incident Manager oder Incident Coordinator achtet darauf, dass: - Aufgaben verteilt werden, - Doppelarbeit vermieden wird, - Ergebnisse zusammengeführt werden, - blockierende Entscheidungen eskaliert werden, - Lieferanten eingebunden werden, - und niemand ohne Abstimmung riskante Änderungen durchführt. --- **Dokumentation während eines Major Incidents** Auch unter Zeitdruck muss dokumentiert werden. Mindestens festhalten: - Zeitpunkt, - Beobachtung, - Maßnahme, - Ergebnis, - Entscheidung, - Verantwortlicher, - nächster Schritt, - Kommunikationszeitpunkt. Diese Informationen werden später benötigt für: - Review, - Problem Management, - Audits, - Lessons Learned, - und Continual Improvement. --- **Nach der Wiederherstellung** Mit der technischen Wiederherstellung endet die Arbeit häufig noch nicht. Es folgen möglicherweise: - Stabilitätsüberwachung, - Benutzerinformation, - Abschlusskommunikation, - Ursachenanalyse, - Problem Record, - Review, - Verbesserung der Dokumentation, - Monitoring-Anpassung, - Aktualisierung von Runbooks, - und Bewertung der Kommunikation. --- **Major Incident Review** Nach Abschluss sollte geprüft werden: - Was ist passiert? - Wann begann die Störung? - Wann wurde sie erkannt? - Wann wurde eskaliert? - Welche Maßnahmen waren wirksam? - Wo gab es Verzögerungen? - War die Kommunikation ausreichend? - Waren Rollen und Verantwortlichkeiten klar? - Hat der Workaround funktioniert? - Welche Verbesserungen sind notwendig? Ziel ist Lernen, nicht Schuldzuweisung. --- **Lessons Learned** Typische Ergebnisse können sein: - bessere Dokumentation, - neue Checklisten, - Monitoring erweitern, - Alarmgrenzen anpassen, - Runbooks verbessern, - Schulungen durchführen, - Automatisierungen ergänzen, - Serviceabhängigkeiten in der CMDB korrigieren, - Lieferanteneskalation verbessern, - Kommunikationsvorlagen überarbeiten. Lessons Learned haben nur dann Wert, wenn daraus konkrete Maßnahmen entstehen. --- **Problem Management einbeziehen** Ein Major Incident führt häufig zu einem Problem Record. Dadurch kann später untersucht werden: - eigentliche Ursache, - beitragende Faktoren, - bekannte Fehler, - Workaround, - dauerhafte Lösung, - notwendiger Change, - Verbesserungsmaßnahmen. Incident Management stellt den Service wieder her. Problem Management sorgt dafür, dass die Ursache verstanden und zukünftige Wiederholungen möglichst vermieden werden. --- **Typische Fehler** **Fehler 1: Kein eindeutiger Owner** Niemand verfolgt den Incident Ende zu Ende. **Fehler 2: Ownership geht bei Eskalation verloren** Das Ticket wird weitergegeben, aber niemand koordiniert mehr. **Fehler 3: Zu späte Eskalation** Erst nach SLA-Verletzung oder Managementbeschwerde wird reagiert. **Fehler 4: Funktionale und hierarchische Eskalation werden verwechselt** Es wird ein Spezialist benötigt, aber Management informiert – oder umgekehrt. **Fehler 5: Major Incident wird nicht aktiviert** Kriterien sind unklar oder niemand entscheidet. **Fehler 6: Jeder kommuniziert etwas anderes** Es fehlt ein Single Point of Communication. **Fehler 7: Technische Vermutungen werden als Fakten veröffentlicht** Vertrauen geht verloren, wenn Aussagen später korrigiert werden müssen. **Fehler 8: Keine Dokumentation während der Störung** Nachbereitung und Ursachenanalyse werden erschwert. **Fehler 9: War Room ohne Koordination** Viele Personen diskutieren, aber wenige Maßnahmen werden entschieden. **Fehler 10: Nach Wiederherstellung keine Nachbereitung** Die Organisation lernt nicht aus dem Incident. **Fehler 11: Lessons Learned bleiben unverbindlich** Verbesserungen werden beschlossen, aber nicht umgesetzt. **Fehler 12: Problem Management wird nicht gestartet** Die eigentliche Ursache bleibt unbekannt oder unbehandelt. --- **Praxisbeispiel** **08:15 Uhr** Mehrere Standorte melden Ausfälle der zentralen Anmeldung. **08:20 Uhr** Incident wird als Major Incident bewertet. **08:25 Uhr** Major Incident Manager übernimmt die Koordination. **08:30 Uhr** Erste Statusmeldung wird veröffentlicht. **08:40 Uhr** Identity-, Netzwerk- und Cloud-Team arbeiten gemeinsam im War Room. **09:05 Uhr** Ein sicherer Workaround ist verfügbar. **09:40 Uhr** Service ist technisch wiederhergestellt. **10:00 Uhr** Abschlussmeldung wird veröffentlicht. **10:30 Uhr** Review-Termin und Problem Record werden erstellt. --- **Checkliste Ownership** - [ ] Owner eindeutig festgelegt - [ ] Bearbeiter und Owner unterschieden - [ ] Kommunikationsverantwortung geklärt - [ ] Zielzeiten werden überwacht - [ ] nächste Schritte sind dokumentiert - [ ] Eskalationen werden verfolgt - [ ] Abschluss wird geprüft --- **Checkliste Eskalation** - [ ] Eskalationsart korrekt gewählt - [ ] funktionale Eskalation bei fehlendem Fachwissen - [ ] hierarchische Eskalation bei Entscheidungs- oder Ressourcenbedarf - [ ] relevante Informationen vollständig - [ ] richtige Ansprechpartner beteiligt - [ ] Grund der Eskalation dokumentiert - [ ] Benutzerkommunikation geregelt - [ ] Ownership bleibt klar --- **Checkliste Major Incident** - [ ] Major-Incident-Kriterien geprüft - [ ] Major Incident bestätigt oder abgelehnt - [ ] Owner festgelegt - [ ] Major Incident Manager benannt - [ ] War Room oder gemeinsamer Kanal eingerichtet - [ ] beteiligte Teams informiert - [ ] Lieferanten bei Bedarf eingebunden - [ ] Kommunikationsverantwortung festgelegt - [ ] erste Statusmeldung veröffentlicht - [ ] Statusintervalle festgelegt - [ ] Workaround geprüft - [ ] Maßnahmen dokumentiert - [ ] Wiederherstellung bestätigt - [ ] Abschlusskommunikation erfolgt - [ ] Review geplant - [ ] Problem Record erstellt, falls erforderlich --- **Bedeutung für Fachinformatiker für Systemintegration** Auch wenn Fachinformatiker nicht immer selbst Incident Manager sind, sind sie häufig maßgeblich an der technischen Analyse und Wiederherstellung beteiligt. Im Arbeitsalltag bedeutet das: - strukturiert arbeiten, - Ergebnisse sauber dokumentieren, - technische Vermutungen von Fakten trennen, - Änderungen nachvollziehbar durchführen, - rechtzeitig eskalieren, - andere Teams aktiv unterstützen, - und verständlich kommunizieren. Gerade bei größeren Störungen entscheidet oft nicht nur technisches Wissen, sondern auch Zusammenarbeit, Ownership und Koordination über die Dauer des Ausfalls. --- **Zusammenfassung** > Incident übernehmen > ↓ > Owner eindeutig festlegen > ↓ > Bearbeitung koordinieren > ↓ > falls notwendig funktional oder hierarchisch eskalieren > ↓ > Major Incident aktivieren, wenn Kriterien erfüllt sind > ↓ > Rollen, Kommunikation und Statusintervalle festlegen > ↓ > Teams und Lieferanten koordinieren > ↓ > Service wiederherstellen > ↓ > Ergebnis stabilisieren und kommunizieren > ↓ > Review durchführen > ↓ > Erkenntnisse in Problem Management, Knowledge Management und Continual Improvement übernehmen --- **Verwandte Seiten** - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.8 Self-Service, Wissensnutzung und Automatisierung - Problem Management - Knowledge Management - Continual Improvement - Service Level Management - Supplier Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Service Level Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Rollen, - Eskalationswege, - Major-Incident-Kriterien, - Statusintervalle, - War-Room-Regeln, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Major-Incident-Definition, - Eskalationsmatrix, - Supportstufenstruktur, - Statusintervallvorgabe, - War-Room-Struktur, - oder konkrete Rollenbesetzung für alle Organisationen vor. Die konkrete Ausgestaltung muss an: - Services, - Risiken, - Service Levels, - Organisation, - Lieferanten, - Kommunikationswege, - Sicherheitsanforderungen, - und Entscheidungsbefugnisse angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.7 Ownership, hierarchische Eskalation und Major Incidents (Teil 2/2) **Major-Incident-Prozess** Nach der Einstufung als Major Incident beginnt eine koordinierte Bearbeitung. Ein möglicher Ablauf: Major Incident erkannt │ ▼ Owner bestätigen │ ▼ Major Incident Manager benennen │ ▼ Fachteams koordinieren │ ▼ Stakeholder informieren │ ▼ Workaround oder Wiederherstellung │ ▼ Service stabilisieren │ ▼ Incident schließen │ ▼ Problem Management starten Nicht jede Organisation verwendet exakt diesen Ablauf. Entscheidend ist eine klare Koordination. --- **War Room** Bei kritischen Incidents wird häufig ein gemeinsamer Kommunikationskanal eingerichtet. Beispiele: - Microsoft Teams - Slack - Telefonkonferenz - Videokonferenz Alle beteiligten Teams arbeiten dort gemeinsam. Vorteile: - schnellere Entscheidungen - weniger Rückfragen - keine Informationsverluste - bessere Zusammenarbeit --- **Kommunikationsregeln** Während eines Major Incidents sollte Kommunikation: - regelmäßig erfolgen, - sachlich bleiben, - bestätigte Fakten enthalten, - Vermutungen klar kennzeichnen, - Verantwortlichkeiten nennen, - nächste Schritte erläutern. Ungeeignet: > Wir glauben, dass wahrscheinlich vielleicht die Firewall schuld ist. Besser: > Die Ursache wird aktuell untersucht. Firewall und Netzwerk werden geprüft. Nächste Statusmeldung um 11:30 Uhr. --- **Stakeholder** Nicht jeder benötigt dieselben Informationen. | Stakeholder | Benötigte Informationen | |---|---| | Benutzer | Auswirkungen und Workaround | | Service Desk | aktueller Status | | Management | Geschäftsrisiken | | Kunden | Serviceverfügbarkeit | | Technik | Diagnoseinformationen | | Lieferanten | technische Details | Informationen sollten zielgruppengerecht formuliert werden. --- **Single Point of Communication** Bei großen Incidents sollte möglichst nur eine abgestimmte Kommunikationsquelle verwendet werden. Dadurch werden widersprüchliche Aussagen vermieden. Beispiele: - Statusseite - Incident Manager - Kommunikationsverantwortlicher --- **Ressourcen koordinieren** Nicht jedes Team sollte unabhängig arbeiten. Der Major Incident Manager achtet darauf, dass: - Aufgaben verteilt, - Doppelarbeiten vermieden, - Ergebnisse zusammengeführt, - Abhängigkeiten erkannt, - und nächste Schritte eindeutig zugewiesen werden. --- **Dokumentation** Auch unter Zeitdruck muss dokumentiert werden. Mindestens festhalten: - Zeitpunkt - Maßnahme - Ergebnis - Entscheidung - Verantwortlicher Diese Informationen werden später benötigt für: - Problem Management - Lessons Learned - Audits - Verbesserungen --- **Nach der Wiederherstellung** Mit der Wiederherstellung endet der Major Incident nicht vollständig. Es folgen häufig: - Ursachenanalyse - Review - Verbesserung - Knowledge-Artikel - Monitoring-Anpassungen - Automatisierungen --- **Major Incident Review** Nach Abschluss sollte überprüft werden: - Was ist passiert? - Warum? - Welche Maßnahmen waren erfolgreich? - Wo gab es Verzögerungen? - Welche Verbesserungen sind möglich? Ziel ist Lernen – nicht Schuldzuweisung. --- **Lessons Learned** Typische Ergebnisse: - bessere Dokumentation - neue Checklisten - Monitoring erweitern - Alarmgrenzen anpassen - Runbooks verbessern - Schulungen durchführen - Automatisierungen ergänzen --- **Problem Management einbeziehen** Ein Major Incident endet häufig mit einem neuen Problem Record. Dadurch kann später untersucht werden: - eigentliche Ursache - dauerhafte Lösung - Vermeidung zukünftiger Incidents --- **Häufige Fehler** **Fehler 1** Kein eindeutiger Owner. --- **Fehler 2** Mehrere Teams arbeiten ohne Koordination. --- **Fehler 3** Benutzer erhalten keine Statusinformationen. --- **Fehler 4** Zu späte Eskalation. --- **Fehler 5** Jeder kommuniziert etwas anderes. --- **Fehler 6** Techniker diskutieren Vermutungen als Fakten. --- **Fehler 7** Keine Dokumentation während des Incidents. --- **Fehler 8** Nach Wiederherstellung erfolgt keine Nachbereitung. --- **Fehler 9** Lessons Learned werden nicht umgesetzt. --- **Fehler 10** Problem Management wird nicht gestartet. --- **Praxisbeispiel** **08:15 Uhr** Mehrere Standorte melden Ausfälle. **08:20 Uhr** Major Incident aktiviert. **08:25 Uhr** Incident Manager übernimmt Koordination. **08:30 Uhr** Statusmeldung veröffentlicht. **08:40 Uhr** Netzwerk-, Server- und Cloud-Team arbeiten gemeinsam. **09:05 Uhr** Workaround verfügbar. **09:40 Uhr** Service vollständig wiederhergestellt. **10:30 Uhr** Review-Termin geplant. --- **Checkliste Ownership** - [ ] Owner eindeutig festgelegt - [ ] Verantwortlichkeiten bekannt - [ ] Benutzer informiert - [ ] Eskalationen überwacht - [ ] Ticket aktiv verfolgt --- **Checkliste Eskalation** - [ ] richtige Eskalationsart gewählt - [ ] Fachinformationen vollständig - [ ] richtige Ansprechpartner beteiligt - [ ] Entscheidungen dokumentiert - [ ] Status kommuniziert --- **Checkliste Major Incident** - [ ] Major Incident bestätigt - [ ] Incident Manager benannt - [ ] Kommunikationskanal eingerichtet - [ ] Stakeholder informiert - [ ] Workaround geprüft - [ ] Maßnahmen dokumentiert - [ ] regelmäßige Statusmeldungen - [ ] Wiederherstellung bestätigt - [ ] Review geplant - [ ] Problem Record erstellt, falls erforderlich --- **Bedeutung für Fachinformatiker für Systemintegration** Auch wenn Fachinformatiker nicht die Rolle des Incident Managers übernehmen, sind sie häufig maßgeblich an der technischen Analyse beteiligt. Im Arbeitsalltag bedeutet das: - strukturiert arbeiten, - Ergebnisse dokumentieren, - Änderungen nachvollziehbar durchführen, - sauber kommunizieren, - und andere Teams aktiv unterstützen. Gerade bei größeren Störungen entscheidet oft die Zusammenarbeit über die Dauer des Ausfalls. --- **Zusammenfassung** > Incident übernehmen > ↓ > Owner festlegen > ↓ > Bearbeitung koordinieren > ↓ > falls notwendig funktional oder hierarchisch eskalieren > ↓ > Major Incident aktivieren, wenn Kriterien erfüllt > ↓ > Kommunikation sicherstellen > ↓ > Service wiederherstellen > ↓ > Review durchführen > ↓ > Erkenntnisse in Problem Management und Continual Improvement übernehmen --- **Verwandte Seiten** - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.8 Self-Service, Wissensnutzung und Automatisierung - Problem Management - Knowledge Management - Continual Improvement --- **Quellen** - PeopleCert – ITIL 4 / ITIL 5 Incident Management - PeopleCert – ITIL 4 / ITIL 5 Service Desk - PeopleCert – ITIL Practice Guides - ITIL Service Version 5 **Framework-Stand:** ITIL Version 5 **Fachlicher Stand:** August 2026 # 3.8 Self-Service, Wissensnutzung und Automatisierung (Teil 1/2) > **Kurz erklärt** > > Ziel moderner Serviceorganisationen ist es nicht, möglichst viele Tickets zu bearbeiten, sondern Benutzern schnell und effizient zu helfen. > > ITIL fördert deshalb: > > - Self-Service, > - Wissensmanagement, > - Automatisierung, > - Standardisierung, > - und kontinuierliche Verbesserung. > > Dadurch können viele Anfragen ohne direkten Kontakt zum Service Desk gelöst werden. --- **Was bedeutet Self-Service?** Self-Service ermöglicht Benutzern, bestimmte Aufgaben selbstständig durchzuführen. Beispiele: - Passwort zurücksetzen - Software anfordern - VPN beantragen - Drucker installieren - Status eines Incidents prüfen - Knowledge-Artikel lesen - Standardsoftware herunterladen Dadurch werden Wartezeiten reduziert und der Service Desk entlastet. --- **Ziele des Self-Service** Ein gutes Self-Service-Portal soll: - leicht verständlich sein, - schnell zum Ziel führen, - rund um die Uhr verfügbar sein, - häufige Anfragen automatisieren, - den Service Desk entlasten, - die Benutzerzufriedenheit erhöhen. Der Benutzer soll möglichst keine internen IT-Strukturen kennen müssen. --- **Vorteile** Für Benutzer: - schnelle Hilfe - keine Wartezeit - jederzeit verfügbar - transparente Bearbeitung Für die IT: - weniger Standardtickets - geringere Kosten - mehr Zeit für komplexe Incidents - einheitliche Prozesse --- **Grenzen des Self-Service** Nicht jede Anfrage eignet sich für Self-Service. Beispiele: - komplexe Störungen - Sicherheitsvorfälle - Major Incidents - individuelle Beratung - Sonderfreigaben - komplexe Infrastrukturprobleme In solchen Fällen bleibt der persönliche Support notwendig. --- **Serviceportal** Das Self-Service-Portal bildet häufig den zentralen Einstiegspunkt. Typische Inhalte: - Servicekatalog - Ticketerstellung - Statusabfrage - Knowledge Base - Standardanfragen - Genehmigungen - Downloads - FAQ --- **Servicekatalog** Ein Servicekatalog beschreibt, welche Leistungen die IT anbietet. Beispiele: - Benutzerkonto - E-Mail - VPN - Arbeitsplatz - Notebook - Software - Druckservice - Cloud-Dienste Dadurch erkennen Benutzer schneller, welcher Service betroffen ist. --- **Standard Requests** Viele Service Requests lassen sich standardisieren. Beispiele: - neues Benutzerkonto - Passwort zurücksetzen - Monitor bestellen - Software installieren - Gruppenberechtigung beantragen Diese Requests besitzen häufig: - einen festen Ablauf, - definierte Genehmigungen, - standardisierte Bearbeitung. --- **Wissensmanagement** Wissen sollte dauerhaft verfügbar sein. Nicht nur erfahrene Administratoren sollen Lösungen kennen. Typische Wissensquellen: - Knowledge Base - Runbooks - FAQ - Checklisten - Standardlösungen - Herstellerinformationen --- **Knowledge Base** Eine Knowledge Base enthält wiederverwendbare Lösungen. Beispiele: - VPN funktioniert nicht - Outlook-Profil reparieren - Drucker verbinden - WLAN-Probleme - MFA einrichten - Software installieren Gut gepflegte Knowledge-Artikel erhöhen die Lösungsquote erheblich. --- **Eigenschaften guter Artikel** Ein Artikel sollte: - verständlich sein, - aktuell bleiben, - reproduzierbare Schritte enthalten, - Screenshots verwenden, - Voraussetzungen nennen, - Risiken erklären, - regelmäßig überprüft werden. --- **Zielgruppen unterscheiden** Nicht jeder Artikel richtet sich an dieselben Leser. Mögliche Zielgruppen: - Endbenutzer - Service Desk - Administratoren - Spezialisten Ein Benutzerartikel sollte keine internen Diagnoseschritte enthalten. --- **KCS (Knowledge-Centered Service)** Viele Organisationen orientieren sich an den Prinzipien von **Knowledge-Centered Service (KCS)**. Grundidee: Wissen entsteht während der täglichen Bearbeitung. Nicht erst Wochen später. Typischer Ablauf: Incident lösen │ ▼ Lösung dokumentieren │ ▼ Knowledge Base erweitern │ ▼ Nächster Incident schneller lösbar --- **Wissen aktuell halten** Veraltete Artikel verursachen: - falsche Lösungen - unnötige Tickets - Frustration - Sicherheitsprobleme Knowledge-Artikel sollten regelmäßig überprüft werden. --- **Suche verbessern** Ein gutes Wissenssystem benötigt: - verständliche Titel - Schlagwörter - Kategorien - Synonyme - Suchfunktion Benutzer suchen häufig nicht mit Fachbegriffen. Beispiel: Nicht: > SMTP Authentication Error Sondern: > Outlook kann keine E-Mails senden. --- **Automatisierung** Automatisierung übernimmt wiederkehrende Aufgaben. Beispiele: - Benutzer anlegen - Gruppenmitgliedschaften verwalten - Software verteilen - Passwort zurücksetzen - VM bereitstellen - Zertifikate erneuern - Backups prüfen Dadurch werden Fehler reduziert und Abläufe beschleunigt. --- **Vorteile der Automatisierung** - schneller - reproduzierbar - weniger manuelle Fehler - rund um die Uhr verfügbar - besser skalierbar --- **Risiken** Automatisierung ersetzt keine Kontrolle. Fehlerhafte Automatisierungen können: - falsche Benutzer anlegen, - falsche Berechtigungen vergeben, - Systeme löschen, - Daten verändern, - oder Sicherheitslücken erzeugen. Automatisierungen benötigen daher: - Tests, - Dokumentation, - Monitoring, - Rollback-Möglichkeiten, - Freigaben, - und klare Verantwortlichkeiten. --- **Runbooks** Runbooks beschreiben standardisierte Arbeitsabläufe. Beispiele: - Serverneustart - Backup-Wiederherstellung - Zertifikat erneuern - Benutzer sperren - DNS prüfen Sie sorgen für einheitliche Arbeitsweisen. --- **Merksätze** > Self-Service ersetzt nicht den Service Desk. > Wissen ist nur dann wertvoll, wenn es aktuell bleibt. > Gute Dokumentation spart zukünftige Bearbeitungszeit. > Automatisierung unterstützt Menschen – sie ersetzt keine Verantwortung. > Jede gelöste Störung kann neues Wissen erzeugen. # 3.8 Self-Service, Wissensnutzung und Automatisierung (Teil 2/2) **Runbooks und Standardabläufe** Runbooks beschreiben wiederholbare Arbeitsabläufe. Sie helfen dabei, Aufgaben einheitlich, sicher und nachvollziehbar durchzuführen. Beispiele: - Server kontrolliert neu starten - Backup-Wiederherstellung prüfen - Zertifikat erneuern - Benutzerkonto sperren - DNS-Auflösung prüfen - Dienststatus kontrollieren - Speicherplatz erweitern - Logdateien auswerten Ein gutes Runbook enthält: - Zweck des Ablaufs - Voraussetzungen - benötigte Berechtigungen - einzelne Arbeitsschritte - Prüfpunkte - Risiken - Rollback oder Abbruchkriterien - Dokumentationshinweise --- **Runbook und Knowledge-Artikel unterscheiden** | Runbook | Knowledge-Artikel | |---|---| | richtet sich häufig an IT-Mitarbeiter | richtet sich je nach Inhalt an Benutzer oder IT | | beschreibt interne Arbeitsabläufe | beschreibt Lösungen, Erklärungen oder Anleitungen | | enthält technische Prüfschritte | kann auch einfache Benutzerhilfe enthalten | | benötigt oft Berechtigungen | kann öffentlich im Serviceportal stehen | | dient der Standardisierung | dient der Wiederverwendung von Wissen | Beide Formen unterstützen eine schnellere und einheitlichere Bearbeitung. --- **Standardisierung** Standardisierung bedeutet, wiederkehrende Aufgaben nach einem einheitlichen Muster auszuführen. Beispiele: - einheitlicher Onboarding-Prozess - definierte Softwarepakete - standardisierte Berechtigungsgruppen - festgelegte Namenskonventionen - einheitliche Ticketkategorien - wiederverwendbare Kommunikationsvorlagen - geprüfte Standard-Changes - dokumentierte Wiederherstellungsverfahren Standardisierung reduziert: - Fehler, - Rückfragen, - Sonderfälle, - Bearbeitungszeit, - und Abhängigkeit von Einzelpersonen. --- **Standardisierung ist keine Starrheit** Standardisierung bedeutet nicht, dass jede Situation gleich behandelt werden muss. Sie schafft einen sicheren Normalweg. Abweichungen bleiben möglich, sollten aber bewusst entschieden und dokumentiert werden. Beispiel: Ein Standard-Request für Softwareinstallation kann automatisch laufen. Eine sicherheitskritische Spezialsoftware benötigt dagegen zusätzliche Prüfung und Freigabe. --- **Automatisierung sinnvoll einsetzen** Automatisierung sollte dort eingesetzt werden, wo Aufgaben: - häufig wiederkehren, - klar beschrieben sind, - wenig Interpretationsspielraum besitzen, - sicher überprüfbar sind, - und bei Fehlern kontrolliert zurückgenommen werden können. Gute Kandidaten: - Passwort-Reset - Benutzeranlage - Gruppenmitgliedschaften - Softwarebereitstellung - Ticket-Routing - Statusbenachrichtigungen - Standard-Reports - Zertifikatsprüfung - Speicherplatzwarnungen Weniger geeignet sind Aufgaben mit: - hoher Unsicherheit, - unklarer Datenlage, - hohem Sicherheitsrisiko, - vielen Ausnahmen, - oder notwendiger Einzelfallentscheidung. --- **Automatisierung braucht Kontrolle** Eine Automatisierung ist nur dann hilfreich, wenn sie zuverlässig gesteuert wird. Zu klären ist: - Wer besitzt die Automatisierung? - Wer darf sie ändern? - Wie wird sie getestet? - Wie werden Fehler erkannt? - Wie erfolgt ein Rollback? - Welche Logs werden geschrieben? - Welche Berechtigungen nutzt sie? - Welche Daten werden verarbeitet? - Wie wird Missbrauch verhindert? > **Merke** > > Automatisierung entfernt Arbeit nicht vollständig. Sie verlagert Arbeit in Design, Prüfung, Betrieb und Überwachung. --- **Risiken fehlerhafter Automatisierung** Fehlerhafte Automatisierungen können große Auswirkungen haben. Beispiele: - falsche Benutzer werden angelegt - falsche Berechtigungen werden vergeben - Konten werden versehentlich deaktiviert - Software wird auf falschen Geräten installiert - Daten werden überschrieben - Tickets werden falsch priorisiert - Benachrichtigungen werden nicht versendet - Zertifikate werden falsch erneuert Deshalb benötigen Automatisierungen: - Tests, - Freigaben, - Protokollierung, - Monitoring, - Fehlerbehandlung, - und klare Verantwortlichkeiten. --- **Self-Service und Automatisierung kombinieren** Self-Service wird besonders wirksam, wenn Benutzeranfragen im Hintergrund automatisiert bearbeitet werden. Beispiel: Ein Benutzer beantragt Standardsoftware im Serviceportal. Möglicher Ablauf: Benutzer wählt Software im Portal ↓ Berechtigung und Genehmigung werden geprüft ↓ Softwarepaket wird automatisch zugewiesen ↓ Installation startet auf dem Gerät ↓ Benutzer erhält Statusmeldung ↓ Ticket wird automatisch dokumentiert Dadurch muss der Service Desk nicht jeden Standardschritt manuell durchführen. --- **Genehmigungen einbauen** Nicht jede Anfrage darf sofort automatisiert erfüllt werden. Beispiele für genehmigungspflichtige Requests: - kostenpflichtige Software - erhöhte Berechtigungen - Zugriff auf vertrauliche Daten - externe Freigaben - neue Geräte - Administratorrechte - Cloud-Ressourcen mit Kostenfolge Ein guter Workflow unterscheidet zwischen: - automatisch erfüllbaren Standardanfragen, - Anfragen mit Genehmigung, - und Anfragen mit manueller Prüfung. --- **Self-Service muss benutzerfreundlich sein** Ein Self-Service-Portal bringt wenig, wenn Benutzer es nicht verstehen oder nicht finden. Wichtig sind: - klare Sprache, - gute Suche, - verständliche Kategorien, - einfache Formulare, - kurze Beschreibungen, - sichtbarer Bearbeitungsstatus, - mobile Nutzbarkeit, - und sinnvolle Hilfetexte. Benutzer sollten nicht wissen müssen, welches interne Team zuständig ist. Ungeeignet: > Antrag für AD-Gruppenmitgliedschaft CN=APP-FIN-PRD-RW. Besser: > Zugriff auf Finanzanwendung beantragen. --- **Gute Formulare** Ein Formular sollte genau die Informationen erfassen, die für die Bearbeitung notwendig sind. Beispiele: - betroffener Service - gewünschte Leistung - betroffene Person - gewünschter Zeitpunkt - Begründung - Kostenstelle - benötigte Berechtigung - Genehmiger - betroffene Geräte - Standort Zu viele Pflichtfelder führen dazu, dass Benutzer falsche Angaben machen oder den Service Desk direkt kontaktieren. Zu wenige Pflichtfelder führen zu Rückfragen und Verzögerungen. --- **Status transparent machen** Benutzer sollten erkennen können: - ob die Anfrage eingegangen ist, - wer aktuell zuständig ist, - ob eine Genehmigung fehlt, - welcher nächste Schritt erfolgt, - wann eine Rückmeldung zu erwarten ist, - und ob ein Workaround verfügbar ist. Transparenz reduziert Rückfragen. Beispiel: > Ihre Softwareanfrage wartet aktuell auf Genehmigung durch den Fachbereich. Nach Genehmigung startet die automatische Bereitstellung. --- **Wissensartikel aus Tickets erzeugen** Viele gute Knowledge-Artikel entstehen direkt aus realen Tickets. Nach einer Lösung sollte geprüft werden: - War der Fall wiederholbar? - Wird diese Frage wahrscheinlich erneut auftreten? - Ist die Lösung allgemein nutzbar? - Kann der Service Desk sie künftig selbst anwenden? - Kann ein Benutzer sie selbst durchführen? - Muss ein bestehender Artikel angepasst werden? Nicht jeder Incident benötigt einen neuen Artikel. Aber häufige oder lehrreiche Fälle sollten nicht verloren gehen. --- **Qualität von Knowledge-Artikeln sichern** Knowledge-Artikel sollten regelmäßig geprüft werden. Zu prüfen ist: - Ist der Inhalt noch korrekt? - Stimmen Screenshots und Menüpfade? - Gibt es neue Versionen? - Sind Links noch gültig? - Sind Risiken vollständig beschrieben? - Ist die Zielgruppe passend? - Gibt es Rückmeldungen von Benutzern? - Wird der Artikel tatsächlich gefunden? - Führt der Artikel zu weniger Tickets? Veraltetes Wissen kann schädlicher sein als kein Wissen. --- **Feedback nutzen** Benutzer und Service-Desk-Mitarbeiter sollten Feedback geben können. Beispiele: - Artikel hilfreich oder nicht hilfreich - Suchbegriff führte nicht zum Ergebnis - Schritt unverständlich - Screenshot veraltet - Lösung funktioniert nicht mehr - Formular enthält unklare Felder - Automatisierung hat falschen Status geliefert Dieses Feedback sollte regelmäßig ausgewertet werden. --- **Kennzahlen** Mögliche Kennzahlen für Self-Service, Wissensnutzung und Automatisierung: | Bereich | Mögliche Kennzahl | |---|---| | Self-Service | Anteil der Anfragen über Portal | | Knowledge Base | Artikelaufrufe | | Knowledge Base | hilfreiche Bewertungen | | Service Desk | First Contact Resolution | | Automatisierung | automatisch erfüllte Requests | | Automatisierung | Fehlerquote automatisierter Abläufe | | Service Requests | durchschnittliche Erfüllungszeit | | Benutzererfahrung | Zufriedenheit nach Nutzung | | Qualität | Anzahl veralteter Artikel | | Verbesserung | reduzierte Wiederholungstickets | Kennzahlen sollten nicht nur Menge messen, sondern auch Qualität. --- **Problematische Kennzahlen** Nicht jede Kennzahl führt automatisch zu gutem Verhalten. Beispiel: **Viele Knowledge-Artikel** Kann problematisch sein, wenn viele Artikel veraltet, doppelt oder unverständlich sind. Besser: - hilfreiche Artikel, - aktuelle Artikel, - gute Suchtreffer, - weniger Rückfragen. Beispiel: **Viele automatisierte Tickets** Kann problematisch sein, wenn Automatisierungen Fehler erzeugen oder Benutzer nicht verstehen, was passiert. Besser: - erfolgreiche Automatisierung, - geringe Fehlerquote, - nachvollziehbare Ergebnisse, - klare Rückmeldung an Benutzer. --- **Zusammenspiel mit Incident Management** Self-Service und Knowledge Management unterstützen Incident Management. Beispiele: - Benutzer lösen einfache Störungen selbst. - Service Desk findet schneller bekannte Lösungen. - Workarounds werden einheitlich kommuniziert. - Wiederkehrende Incidents werden sichtbar. - Known Errors können dokumentiert werden. - Automatisierte Diagnosen liefern erste Hinweise. Dadurch kann der Service schneller wiederhergestellt werden. --- **Zusammenspiel mit Service Request Management** Viele Service Requests eignen sich besonders gut für Self-Service und Automatisierung. Beispiele: - Standardsoftware anfordern - Zugriff beantragen - Hardware bestellen - Benutzerkonto erstellen - Verteilerliste anpassen - Passwort zurücksetzen Wichtig ist, dass: - der Service verständlich beschrieben ist, - Genehmigungen klar sind, - Bearbeitungszeiten sichtbar sind, - und die Erfüllung nachvollziehbar dokumentiert wird. --- **Zusammenspiel mit Change Enablement** Automatisierung und Self-Service können Changes auslösen. Beispiele: - neue Berechtigung wird gesetzt - Software wird installiert - Firewall-Regel wird beantragt - Cloud-Ressource wird erstellt - Konfiguration wird angepasst Solche Änderungen müssen entsprechend ihrem Risiko behandelt werden. Nicht jede Automatisierung ist automatisch ein Standard-Change. Die Organisation muss festlegen, welche Abläufe vorab geprüft und freigegeben sind. --- **Zusammenspiel mit Information Security Management** Self-Service und Automatisierung betreffen häufig Berechtigungen und Daten. Deshalb müssen Sicherheitsanforderungen berücksichtigt werden. Beispiele: - starke Authentifizierung - Rollen- und Rechteprüfung - Genehmigungsworkflow - Protokollierung - Zugriff nur nach Bedarf - regelmäßige Rezertifizierung - Schutz sensibler Daten - Missbrauchserkennung Benutzerfreundlichkeit darf nicht dazu führen, dass Sicherheitsregeln umgangen werden. --- **Typische Fehler** **Fehler 1** Self-Service wird nur als Ticketformular verstanden. --- **Fehler 2** Benutzer müssen interne IT-Strukturen kennen. --- **Fehler 3** Knowledge-Artikel sind veraltet. --- **Fehler 4** Artikel sind zu technisch für Endbenutzer. --- **Fehler 5** Automatisierungen werden ohne ausreichende Tests produktiv genutzt. --- **Fehler 6** Automatisierungen besitzen zu viele Berechtigungen. --- **Fehler 7** Fehler in automatisierten Abläufen werden nicht überwacht. --- **Fehler 8** Runbooks existieren, werden aber nicht gepflegt. --- **Fehler 9** Self-Service ersetzt persönliche Hilfe auch dort, wo sie notwendig wäre. --- **Fehler 10** Benutzerfeedback wird nicht ausgewertet. --- **Fehler 11** Genehmigungen sind unklar oder zu langsam. --- **Fehler 12** Wissen bleibt bei Einzelpersonen statt in dokumentierten Systemen. --- **Praxisbeispiel: Passwort-Reset** **Ausgangslage** Viele Benutzer rufen den Service Desk an, weil sie ihr Passwort vergessen haben. **Verbesserung** Ein Self-Service-Passwort-Reset wird eingeführt. **Wichtige Anforderungen** - sichere Identitätsprüfung - MFA-Unterstützung - klare Benutzeranleitung - Protokollierung - Sperrmechanismen gegen Missbrauch - Hilfeweg bei Fehlern **Nutzen** - weniger Standardkontakte - schnellere Hilfe für Benutzer - Service Desk hat mehr Zeit für komplexe Incidents --- **Praxisbeispiel: Softwareanforderung** **Ausgangslage** Software wird per E-Mail angefordert. Informationen fehlen häufig. Genehmigungen sind unklar. **Verbesserung** Ein Serviceportal bietet standardisierte Softwareanfragen. **Ablauf** Software auswählen ↓ Kosten und Lizenz prüfen ↓ Genehmigung einholen ↓ Paket automatisch bereitstellen ↓ Benutzer informieren ↓ Ticket dokumentieren **Nutzen** - weniger Rückfragen - klare Genehmigung - schnellere Bereitstellung - bessere Nachvollziehbarkeit --- **Praxisbeispiel: Knowledge-Artikel aus Incident** **Incident** Mehrere Benutzer melden, dass VPN nach einem Client-Update nicht startet. **Lösung** Der Service Desk findet eine sichere Reparaturmaßnahme. **Folgeaktivität** Ein interner Knowledge-Artikel wird erstellt. Inhalt: - betroffene Version - Symptom - Prüfschritte - Lösung - Abbruchkriterien - Eskalation an Netzwerkteam **Nutzen** Der nächste gleichartige Incident kann schneller gelöst werden. --- **Checkliste Self-Service** - [ ] Leistungen sind verständlich beschrieben - [ ] Benutzer müssen keine internen Teamnamen kennen - [ ] Formulare erfassen die richtigen Informationen - [ ] Status ist für Benutzer sichtbar - [ ] Genehmigungen sind klar geregelt - [ ] Hilfeweg bei Problemen ist vorhanden - [ ] Portal ist leicht auffindbar - [ ] Inhalte werden regelmäßig verbessert --- **Checkliste Knowledge Management** - [ ] Artikel besitzen klare Titel - [ ] Zielgruppe ist definiert - [ ] Schritte sind verständlich - [ ] Voraussetzungen sind genannt - [ ] Risiken sind beschrieben - [ ] Inhalte sind aktuell - [ ] Artikel werden gefunden - [ ] Feedback wird ausgewertet - [ ] veraltete Artikel werden überarbeitet oder entfernt - [ ] Lösungen aus Tickets werden bei Bedarf übernommen --- **Checkliste Automatisierung** - [ ] Ablauf ist standardisiert - [ ] Risiken sind bewertet - [ ] Berechtigungen sind minimal notwendig - [ ] Tests wurden durchgeführt - [ ] Fehler werden protokolliert - [ ] Monitoring ist vorhanden - [ ] Rollback oder Abbruchweg ist definiert - [ ] Verantwortlicher ist benannt - [ ] Änderungen sind dokumentiert - [ ] Benutzer erhalten verständliche Rückmeldungen --- **Bedeutung für Fachinformatiker für Systemintegration** Für Fachinformatiker ist dieses Thema besonders wichtig, weil viele praktische Verbesserungen direkt aus dem technischen Alltag entstehen. Beispiele: - wiederkehrende Fehler dokumentieren, - Standardabläufe als Runbook beschreiben, - einfache Prüfungen automatisieren, - Service Desk mit Wissen unterstützen, - sichere Self-Service-Prozesse vorbereiten, - Berechtigungen sauber modellieren, - und Monitoring für Automatisierungen einrichten. Gute technische Arbeit zeigt sich nicht nur darin, ein einzelnes Problem zu lösen. Sie zeigt sich auch darin, dass derselbe Fehler künftig schneller, sicherer oder automatisch bearbeitet werden kann. --- **Zusammenfassung** > Wiederkehrende Anfragen erkennen > ↓ > geeignete Self-Service-Möglichkeiten schaffen > ↓ > Wissen verständlich dokumentieren > ↓ > Standardabläufe definieren > ↓ > geeignete Schritte automatisieren > ↓ > Risiken, Berechtigungen und Monitoring berücksichtigen > ↓ > Benutzerfeedback auswerten > ↓ > Inhalte und Abläufe kontinuierlich verbessern --- **Merksätze** > Self-Service ersetzt nicht den Service Desk, sondern erweitert die Servicefähigkeit. > Wissen muss auffindbar, verständlich und aktuell sein. > Automatisierung braucht klare Verantwortung. > Ein automatisierter Fehler bleibt ein Fehler. > Jede gelöste Störung kann zukünftiges Wissen erzeugen. > Gute Standardisierung schafft Freiraum für komplexe Aufgaben. --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.4 Tickets vollständig erfassen und kategorisieren - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Knowledge Management - Service Request Management - Change Enablement - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Service Request Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Self-Service-Beispiele, - Portalstrukturen, - Knowledge-Artikel-Kriterien, - Runbook-Beispiele, - Automatisierungsregeln, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Portalstruktur, - Knowledge-Artikel-Vorlage, - Automatisierungsquote, - Runbook-Form, - KCS-Einführung, - oder Self-Service-Pflicht für alle Organisationen vor. Die konkrete Ausgestaltung muss an: - Services, - Benutzergruppen, - Sicherheitsanforderungen, - technische Plattformen, - Genehmigungswege, - Service Levels, - Fähigkeiten, - und organisatorische Verantwortung angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk > **Kurz erklärt** > > Kennzahlen helfen dabei, die Arbeit des Service Desks sichtbar, bewertbar und verbesserbar zu machen. > > Sie zeigen jedoch nicht automatisch, ob ein Service wirklich gut ist. > > Entscheidend ist, Kennzahlen richtig zu interpretieren und mit Qualität, Benutzererfahrung und kontinuierlicher Verbesserung zu verbinden. --- **Warum Kennzahlen wichtig sind** Ohne Kennzahlen bleibt die Leistung eines Service Desks schwer bewertbar. Kennzahlen helfen zu erkennen: - wie viele Kontakte eingehen, - welche Themen häufig auftreten, - wie schnell reagiert wird, - wie schnell gelöst wird, - wie zufrieden Benutzer sind, - wo Engpässe entstehen, - welche Services häufig gestört sind, - und wo Verbesserungen notwendig sind. Kennzahlen sollen nicht nur kontrollieren. Sie sollen helfen, bessere Entscheidungen zu treffen. --- **Kennzahlen sind kein Selbstzweck** Eine Kennzahl ist nur dann sinnvoll, wenn klar ist: - was sie misst, - warum sie gemessen wird, - wer sie nutzt, - welche Entscheidung daraus folgt, - und welche Fehlanreize entstehen können. Beispiel: Eine sehr kurze Bearbeitungszeit klingt gut. Sie kann aber problematisch sein, wenn Tickets vorschnell geschlossen werden und Benutzer später erneut Kontakt aufnehmen müssen. > **Merke** > > Eine gute Kennzahl unterstützt bessere Servicequalität. > > Eine schlechte Kennzahl erzeugt falsches Verhalten. --- **Qualität im Service Desk** Qualität bedeutet nicht nur, dass Tickets schnell geschlossen werden. Qualität bedeutet auch: - Anliegen werden korrekt verstanden, - Benutzer erhalten verständliche Rückmeldungen, - Tickets sind vollständig dokumentiert, - Lösungen sind nachvollziehbar, - Eskalationen erfolgen rechtzeitig, - Wiedereröffnungen werden vermieden, - bekannte Lösungen werden genutzt, - und Verbesserungen werden erkannt. Ein Service Desk kann viele Tickets bearbeiten und trotzdem schlechte Qualität liefern. --- **Quantität und Qualität unterscheiden** | Quantität | Qualität | |---|---| | Anzahl der Tickets | Vollständigkeit der Erfassung | | Anzahl geschlossener Vorgänge | tatsächliche Lösung aus Benutzersicht | | durchschnittliche Bearbeitungszeit | Verständlichkeit der Kommunikation | | Anzahl Anrufe | richtige Klassifizierung | | Anzahl Eskalationen | sinnvolle Eskalation mit ausreichendem Kontext | Beide Perspektiven sind wichtig. Nur Mengenkennzahlen reichen nicht aus. --- **Typische Kennzahlen im Service Desk** | Bereich | Mögliche Kennzahl | |---|---| | Kontaktvolumen | Anzahl der Kontakte pro Zeitraum | | Kanäle | Anteil Portal, Telefon, E-Mail, Chat | | Reaktion | Zeit bis zur ersten qualifizierten Rückmeldung | | Lösung | durchschnittliche Lösungszeit | | Wiederherstellung | Zeit bis zur Wiederherstellung des Service | | First Contact Resolution | Anteil beim ersten Kontakt gelöster Anliegen | | Eskalation | Anteil funktional eskalierter Tickets | | Qualität | Anteil vollständig dokumentierter Tickets | | Benutzererfahrung | Zufriedenheit nach Kontakt | | Backlog | Anzahl offener Tickets | | Wiedereröffnung | Anteil wiedergeöffneter Tickets | | Self-Service | Anteil selbst gelöster oder automatisierter Anfragen | | Knowledge | Nutzung und Bewertung von Wissensartikeln | Die konkrete Auswahl hängt von Organisation, Services und Zielsetzung ab. --- **Kontaktvolumen** Das Kontaktvolumen zeigt, wie viele Anfragen, Störungen oder Rückfragen eingehen. Zu betrachten sind: - Anzahl Kontakte pro Tag, Woche oder Monat, - Verteilung nach Kontaktkanal, - Spitzenzeiten, - häufige Services, - häufige Kategorien, - wiederkehrende Themen. Ein hohes Kontaktvolumen bedeutet nicht automatisch schlechte Leistung. Es kann auch bedeuten: - neue Services wurden eingeführt, - Benutzer kennen den Service Desk besser, - Self-Service funktioniert noch nicht, - ein wiederkehrendes Problem erzeugt viele Meldungen, - oder ein Major Incident führt zu vielen Kontakten. --- **Kanäle auswerten** Kontaktkanäle können unterschiedliche Qualität und Kosten verursachen. Beispiele: | Kanal | Typische Stärke | Typisches Risiko | |---|---|---| | Portal | strukturierte Erfassung | Benutzer finden Service nicht | | Telefon | schnelle Klärung | schlechte Dokumentation möglich | | E-Mail | einfach zugänglich | unstrukturierte Angaben | | Chat | schnelle Kurzklärung | komplexe Fälle schwer dokumentierbar | | Self-Service | sofortige Hilfe | ungeeignet bei komplexen Incidents | Die Organisation sollte prüfen, welche Kanäle für welche Anliegen geeignet sind. --- **Zeit bis zur ersten qualifizierten Rückmeldung** Diese Kennzahl misst, wie schnell der Benutzer eine verwertbare Rückmeldung erhält. Eine qualifizierte Rückmeldung ist mehr als: > Ticket wurde erstellt. Besser: > Wir haben den Incident aufgenommen. Betroffen ist der VPN-Zugriff. Erste Prüfungen laufen. Die nächste Rückmeldung erfolgt spätestens um 14:00 Uhr. Diese Kennzahl hilft, gefühlte Untätigkeit zu vermeiden. --- **Lösungszeit und Wiederherstellungszeit unterscheiden** | Kennzahl | Bedeutung | |---|---| | **Lösungszeit** | Zeit bis zur Bearbeitung oder zum Abschluss eines Vorgangs | | **Wiederherstellungszeit** | Zeit bis der betroffene Service wieder nutzbar ist | | **Bearbeitungszeit** | aktive Arbeitszeit am Vorgang | | **Wartezeit** | Zeit, in der auf Benutzer, Lieferanten, Genehmigung oder andere Abhängigkeiten gewartet wird | Diese Werte sollten nicht verwechselt werden. Ein Incident kann technisch wiederhergestellt sein, obwohl die endgültige Ursache noch im Problem Management untersucht wird. --- **First Contact Resolution** Die **First Contact Resolution (FCR)** beschreibt den Anteil der Anliegen, die beim ersten Kontakt ausreichend gelöst werden. Eine hohe FCR kann entstehen durch: - gute Knowledge Base, - geschulte Service-Desk-Mitarbeiter, - klare Standardlösungen, - ausreichende Berechtigungen, - sinnvolle Automatisierung, - gute Self-Service-Angebote. Aber Vorsicht: Eine hohe FCR ist nicht automatisch gut, wenn Tickets voreilig geschlossen werden. Zu prüfen ist deshalb auch: - Wiedereröffnungsquote, - Benutzerzufriedenheit, - Qualität der Dokumentation, - tatsächliche Lösung aus Benutzersicht. --- **SLA-Erfüllung** SLA-Erfüllung zeigt, ob vereinbarte Serviceziele eingehalten wurden. Mögliche SLA-Ziele: - Reaktionszeit, - Wiederherstellungszeit, - Erfüllungszeit für Service Requests, - Verfügbarkeit, - Statusintervalle, - Bearbeitung innerhalb vereinbarter Servicezeiten. Wichtig: SLA-Erfüllung sollte nicht nur formal betrachtet werden. Beispiel: Ein Ticket wurde innerhalb der Zielzeit geschlossen. Wenn der Benutzer danach erneut melden muss, war die Serviceerfahrung trotzdem schlecht. --- **Backlog** Der Backlog zeigt offene Arbeit. Zu betrachten sind: - Anzahl offener Tickets, - Alter offener Tickets, - offene Tickets nach Priorität, - offene Tickets nach Team, - blockierte Tickets, - Tickets mit überschrittener Zielzeit, - wiederholt verschobene Tickets. Ein Backlog ist nicht automatisch schlecht. Problematisch wird er, wenn: - Vorgänge lange unbeachtet bleiben, - Prioritäten nicht mehr gesteuert werden, - Benutzer keine Rückmeldung erhalten, - oder alte Tickets immer wieder verdrängt werden. --- **Wiedereröffnungsquote** Die Wiedereröffnungsquote zeigt, wie oft geschlossene Tickets erneut geöffnet werden. Mögliche Ursachen: - Problem wurde nicht vollständig gelöst, - Benutzer hat Lösung nicht verstanden, - Abschluss erfolgte zu früh, - Workaround wurde als Lösung behandelt, - Ursache bestand weiterhin, - Kommunikation war unklar, - oder ein verwandter Incident wurde falsch zugeordnet. Eine hohe Wiedereröffnungsquote kann auf Qualitätsprobleme hinweisen. --- **Eskalationsquote** Die Eskalationsquote zeigt, wie häufig Tickets an andere Teams weitergegeben werden. Eine hohe Eskalationsquote kann bedeuten: - Service Desk hat zu wenig Wissen, - Knowledge Base ist unzureichend, - Berechtigungen fehlen, - Kategorien sind unklar, - Services sind komplex, - oder Tickets werden korrekt an Spezialisten gegeben. Eine niedrige Eskalationsquote ist nicht automatisch gut. Sie kann auch bedeuten, dass notwendige Eskalationen zu spät erfolgen. --- **Ticketqualität messen** Ticketqualität ist wichtig für Bearbeitung, Übergabe und spätere Auswertung. Zu prüfen ist: - Ist der betroffene Service erfasst? - Ist das Symptom verständlich beschrieben? - Sind Auswirkungen dokumentiert? - Sind Priorität und Begründung nachvollziehbar? - Sind bisherige Maßnahmen dokumentiert? - Sind relevante Anhänge vorhanden? - Ist der Abschluss nachvollziehbar? - Wurde ein Workaround dokumentiert? - Ist eine Folgeaktivität notwendig? Eine gute Ticketdokumentation spart spätere Arbeitszeit. --- **Benutzerzufriedenheit** Benutzerzufriedenheit kann gemessen werden durch: - kurze Umfragen nach Ticketabschluss, - Feedback im Portal, - Service Reviews, - Beschwerden, - Lob, - qualitative Interviews, - wiederkehrende Rückmeldungen. Wichtig ist, nicht nur eine Zahl zu betrachten. Eine Bewertung sollte ergänzt werden durch: - Kommentare, - Ticketinhalt, - Servicekontext, - tatsächliche Lösung, - und Kommunikationsqualität. --- **Customer Satisfaction und Experience** **Customer Satisfaction (CSAT)** misst häufig die Zufriedenheit mit einem konkreten Kontakt. **Experience** betrachtet breiter, wie Benutzer den Service insgesamt erleben. Beispiel: Ein einzelner Service-Desk-Kontakt war freundlich und schnell. Trotzdem kann die Gesamterfahrung schlecht sein, wenn: - das Portal unübersichtlich ist, - dieselbe Störung häufig wiederkehrt, - Genehmigungen lange dauern, - oder Statusinformationen fehlen. --- **Self-Service-Kennzahlen** Mögliche Kennzahlen: - Anzahl Portalaufrufe, - Anteil über Portal erstellter Tickets, - Anteil erfolgreich selbst gelöster Anliegen, - Nutzung bestimmter Knowledge-Artikel, - Abbruchquote in Formularen, - Anzahl automatisiert erfüllter Requests, - Zufriedenheit mit Self-Service, - Rückgang bestimmter Standardkontakte. Nicht nur Nutzung zählt. Wichtig ist auch, ob Benutzer tatsächlich zum Ziel kommen. --- **Knowledge-Management-Kennzahlen** Mögliche Kennzahlen: - Artikelaufrufe, - Suchanfragen ohne Treffer, - hilfreiche Bewertungen, - veraltete Artikel, - neu erstellte Artikel, - aktualisierte Artikel, - Artikel, die zur Lösung beigetragen haben, - wiederkehrende Incidents ohne vorhandenen Artikel. Problematisch wäre, nur die Anzahl der Artikel zu messen. Viele schlechte Artikel helfen weniger als wenige gute. --- **Automatisierungskennzahlen** Mögliche Kennzahlen: - Anzahl automatisierter Abläufe, - Anteil erfolgreich automatisierter Requests, - Fehlerquote, - manuelle Nacharbeit, - durchschnittliche Durchlaufzeit, - eingesparte Bearbeitungsschritte, - fehlgeschlagene Automatisierungen, - Rollbacks, - Sicherheitsereignisse durch Automatisierung. Automatisierung muss nicht nur schnell sein. Sie muss sicher, nachvollziehbar und zuverlässig sein. --- **Trendanalyse** Kennzahlen werden besonders wertvoll, wenn sie über längere Zeit betrachtet werden. Beispiele: - VPN-Incidents steigen seit einem Client-Update. - Passwort-Reset-Anfragen sinken nach Einführung von Self-Service. - Drucker-Incidents häufen sich an einem Standort. - Wiedereröffnungen steigen in einer bestimmten Kategorie. - Backlog wächst regelmäßig zum Monatsende. - Eskalationen an ein Team nehmen stark zu. Trends helfen, Ursachen und Verbesserungsmöglichkeiten zu erkennen. --- **Qualitätssicherung im Service Desk** Qualität kann geprüft werden durch: - Ticket-Stichproben, - Gesprächsauswertung, - Review von Eskalationen, - Prüfung von Abschlussnotizen, - Bewertung von Knowledge-Nutzung, - Analyse wiedereröffneter Tickets, - Feedback der Fachgruppen, - Feedback der Benutzer. Ziel ist nicht Bestrafung. Ziel ist Lernen und Verbesserung. --- **Service Reviews** In Service Reviews werden Ergebnisse regelmäßig betrachtet. Mögliche Inhalte: - SLA-Erfüllung, - häufige Incidents, - Benutzerfeedback, - offene Risiken, - Major Incidents, - Verbesserungsmaßnahmen, - Trends, - Qualität der Kommunikation, - Leistung von Lieferanten, - Stand des Backlogs. Service Reviews verbinden operative Daten mit geschäftlicher Bewertung. --- **Dashboards** Dashboards helfen, wichtige Informationen schnell sichtbar zu machen. Ein gutes Dashboard zeigt: - aktuelle Lage, - Trends, - Engpässe, - Zielverletzungen, - Risiken, - und Verbesserungsbedarf. Ein Dashboard sollte nicht mit Kennzahlen überladen werden. Besser wenige relevante Kennzahlen als viele unklare Zahlen. --- **Ampellogik vorsichtig verwenden** Ampeln sind einfach verständlich. Beispiel: | Farbe | Bedeutung | |---|---| | Grün | Ziel erreicht | | Gelb | Ziel gefährdet | | Rot | Ziel verletzt oder Risiko hoch | Risiko: Eine Ampel kann komplexe Situationen zu stark vereinfachen. Deshalb sollten kritische Kennzahlen immer mit Kontext erklärt werden. --- **Fehlanreize vermeiden** Kennzahlen können unerwünschtes Verhalten erzeugen. Beispiele: | Kennzahl | Möglicher Fehlanreiz | |---|---| | viele geschlossene Tickets | Tickets werden zu früh geschlossen | | kurze Lösungszeit | komplexe Fälle werden gemieden | | niedrige Eskalationsquote | Eskalation erfolgt zu spät | | hohe FCR | Fälle werden oberflächlich gelöst | | hohe SLA-Erfüllung | Prioritäten werden manipuliert | | viele Knowledge-Artikel | Qualität wird durch Menge ersetzt | | viele Automatisierungen | Risiken werden unterschätzt | Kennzahlen müssen deshalb regelmäßig kritisch überprüft werden. --- **Kennzahlen gemeinsam interpretieren** Einzelne Kennzahlen können täuschen. Beispiel: - Lösungszeit sinkt, - aber Wiedereröffnungsquote steigt, - und Benutzerzufriedenheit sinkt. Dann ist die scheinbare Verbesserung wahrscheinlich keine echte Qualitätsverbesserung. Besser ist eine kombinierte Betrachtung. Beispiel: - Reaktionszeit, - Lösungszeit, - Wiedereröffnungen, - Benutzerzufriedenheit, - Dokumentationsqualität, - und SLA-Erfüllung. --- **Continual Improvement im Service Desk** Continual Improvement bedeutet, aus Daten, Feedback und Erfahrungen konkrete Verbesserungen abzuleiten. Möglicher Ablauf: Kennzahl oder Feedback erkennen ↓ Ursache oder Muster untersuchen ↓ Verbesserungsidee erfassen ↓ Nutzen und Aufwand bewerten ↓ Maßnahme umsetzen ↓ Wirkung messen ↓ Standard oder Wissen aktualisieren Verbesserung ist damit ein dauerhafter Bestandteil des Service Desk. --- **Improvement Register** Verbesserungsideen sollten nicht verloren gehen. Ein Improvement Register kann enthalten: - Verbesserungsidee, - betroffener Service, - Auslöser, - erwarteter Nutzen, - Aufwand, - Risiko, - Priorität, - Verantwortlicher, - Status, - Ergebnis, - Lessons Learned. Das Werkzeug ist nicht entscheidend. Wichtig ist, dass Verbesserungen nachvollziehbar erfasst und verfolgt werden. --- **Beispiele für Verbesserungen** | Beobachtung | mögliche Verbesserung | |---|---| | viele Passwort-Tickets | Self-Service-Passwort-Reset einführen | | häufige VPN-Probleme | Knowledge-Artikel und Clientprüfung verbessern | | viele Rückfragen bei Requests | Formulare überarbeiten | | hohe Wiedereröffnungsquote | Abschlussprüfung verbessern | | viele Eskalationen an Netzwerkteam | Service Desk mit Runbook unterstützen | | lange Wartezeiten auf Genehmigungen | Genehmigungsworkflow vereinfachen | | wiederkehrende Drucker-Incidents | Problem Management einbinden | | schlechte Suchtreffer | Knowledge Base neu strukturieren | --- **Qualitative Informationen berücksichtigen** Nicht alles Wichtige ist direkt messbar. Wertvoll sind auch: - Kommentare von Benutzern, - Erfahrungen des Service Desks, - Rückmeldungen von Fachgruppen, - Beobachtungen aus Major Incident Reviews, - Hinweise aus Service Reviews, - Beschwerden, - und wiederkehrende Missverständnisse. Zahlen zeigen oft, wo man suchen sollte. Die Ursachen versteht man häufig erst durch qualitative Informationen. --- **Typische Fehler** **Fehler 1** Es werden viele Kennzahlen gesammelt, aber keine Entscheidungen daraus abgeleitet. --- **Fehler 2** Nur Geschwindigkeit wird gemessen, nicht Qualität. --- **Fehler 3** Tickets werden schnell geschlossen, obwohl der Benutzer nicht arbeitsfähig ist. --- **Fehler 4** SLA-Erfüllung wird wichtiger genommen als tatsächliche Serviceerfahrung. --- **Fehler 5** Wiedereröffnungen werden ignoriert. --- **Fehler 6** Kennzahlen werden ohne Kontext verglichen. --- **Fehler 7** Teams werden für Zahlen verantwortlich gemacht, die sie nicht beeinflussen können. --- **Fehler 8** Benutzerfeedback wird gesammelt, aber nicht ausgewertet. --- **Fehler 9** Dashboards zeigen zu viele Werte ohne klare Aussage. --- **Fehler 10** Verbesserungsideen werden nicht verfolgt. --- **Fehler 11** Automatisierungserfolg wird nur an Geschwindigkeit gemessen. --- **Fehler 12** Knowledge Management wird nur nach Anzahl der Artikel bewertet. --- **Praxisbeispiel: Wiedereröffnete Tickets** **Beobachtung** Die Lösungszeit im Service Desk ist gesunken. Gleichzeitig steigt die Wiedereröffnungsquote. **Analyse** Viele Tickets werden geschlossen, nachdem eine Standardantwort versendet wurde. Benutzer bestätigen jedoch nicht, dass das Problem gelöst ist. **Verbesserung** - Abschlusskriterien definieren, - Benutzer-Outcome prüfen, - Abschlussnotiz verbessern, - Knowledge-Artikel überarbeiten, - Stichproben einführen. **Erfolgskontrolle** Nach zwei Monaten sinkt die Wiedereröffnungsquote. Die Benutzerzufriedenheit steigt. --- **Praxisbeispiel: Viele VPN-Incidents** **Beobachtung** VPN-Incidents steigen nach einem Client-Update stark an. **Analyse** Mehrere Tickets enthalten ähnliche Symptome. Ein Teil der Benutzer nutzt eine veraltete Konfiguration. **Verbesserung** - Known Error dokumentieren, - Knowledge-Artikel erstellen, - Clientprüfung automatisieren, - Self-Service-Hinweis im Portal ergänzen, - Problem Management einbinden. **Erfolgskontrolle** VPN-Tickets gehen deutlich zurück. Der Service Desk kann verbleibende Fälle schneller lösen. --- **Praxisbeispiel: Serviceportal wird kaum genutzt** **Beobachtung** Die meisten Anfragen kommen weiterhin per E-Mail. **Analyse** Benutzer finden die richtigen Services im Portal nicht. Formulare enthalten unklare technische Begriffe. **Verbesserung** - Kategorien vereinfachen, - Suchbegriffe ergänzen, - Formulare kürzen, - verständliche Beschreibungen verwenden, - Benutzerkommunikation verbessern. **Erfolgskontrolle** Portalnutzung steigt. Rückfragen pro Request sinken. --- **Checkliste Kennzahlen** - [ ] Zweck der Kennzahl ist klar - [ ] Datenquelle ist bekannt - [ ] Berechnung ist nachvollziehbar - [ ] Zielwert ist definiert - [ ] Fehlanreize wurden geprüft - [ ] Kennzahl wird regelmäßig bewertet - [ ] Maßnahmen werden daraus abgeleitet - [ ] Qualität wird mit betrachtet - [ ] Benutzererfahrung wird berücksichtigt - [ ] Kennzahl wird bei Bedarf angepasst --- **Checkliste Ticketqualität** - [ ] betroffener Service erfasst - [ ] Symptom verständlich beschrieben - [ ] Auswirkung dokumentiert - [ ] Priorität begründet - [ ] Maßnahmen nachvollziehbar dokumentiert - [ ] Eskalationen enthalten genug Kontext - [ ] Workaround dokumentiert - [ ] Lösung oder Ergebnis klar beschrieben - [ ] Benutzer-Outcome geprüft - [ ] Folgeaktivitäten verknüpft --- **Checkliste Continual Improvement** - [ ] Trends und Muster werden erkannt - [ ] Benutzerfeedback wird ausgewertet - [ ] Verbesserungsideen werden erfasst - [ ] Nutzen und Aufwand werden bewertet - [ ] Verantwortliche sind benannt - [ ] Maßnahmen werden umgesetzt - [ ] Wirkung wird gemessen - [ ] Knowledge Base wird aktualisiert - [ ] Runbooks werden angepasst - [ ] Ergebnisse werden kommuniziert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker liefern wichtige Daten für Kennzahlen und Verbesserungen. Sie dokumentieren: - Symptome, - technische Ursachen, - durchgeführte Maßnahmen, - Workarounds, - betroffene Komponenten, - Serviceabhängigkeiten, - und wiederkehrende Muster. Dadurch können spätere Auswertungen überhaupt erst sinnvoll durchgeführt werden. Gute technische Arbeit endet nicht mit der Reparatur. Sie schafft auch verwertbares Wissen für bessere Services. --- **Zusammenfassung** > Service-Desk-Arbeit erfassen > ↓ > sinnvolle Kennzahlen auswählen > ↓ > Qualität und Benutzererfahrung berücksichtigen > ↓ > Trends und Muster erkennen > ↓ > Verbesserungen ableiten > ↓ > Maßnahmen umsetzen > ↓ > Wirkung messen > ↓ > Wissen, Prozesse und Automatisierung verbessern --- **Merksätze** > Nicht alles, was messbar ist, ist automatisch wichtig. > Geschwindigkeit ohne Qualität ist keine gute Serviceleistung. > Eine Kennzahl braucht immer Kontext. > Benutzerzufriedenheit und Serviceergebnis zählen genauso wie Ticketzahlen. > Gute Dokumentation macht Verbesserung erst möglich. > Continual Improvement beginnt oft mit sauber erfassten Tickets. --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.8 Self-Service, Wissensnutzung und Automatisierung - Service Level Management - Knowledge Management - Continual Improvement - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Kennzahlen, - Qualitätskriterien, - Dashboard-Beispiele, - Checklisten, - Praxisbeispiele, - und Verbesserungsansätze sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - KPI-Liste, - Zielquote, - Dashboard-Struktur, - CSAT-Methode, - Ticketqualitätsprüfung, - oder Verbesserungsmatrix für alle Organisationen vor. Die konkrete Ausgestaltung muss an: - Services, - Service Levels, - Benutzergruppen, - Organisation, - Supportmodell, - Werkzeuge, - Datenqualität, - und geschäftliche Ziele angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 4. Problem Management # 4.1 Problem Management – Ziele, Begriffe und Abgrenzung > **Kurz erklärt** > > Problem Management beschäftigt sich mit den Ursachen von Incidents. > > Während Incident Management vor allem den Service schnell wiederherstellen soll, untersucht Problem Management, warum Incidents entstehen und wie Wiederholungen vermieden werden können. > > Ziel ist nicht nur die schnelle Reparatur, sondern eine nachhaltige Verbesserung der Servicequalität. --- **Warum Problem Management wichtig ist** Viele Störungen treten nicht nur einmal auf. Beispiele: - VPN bricht regelmäßig ab. - Druckerwarteschlangen blockieren immer wieder. - Benutzer melden wiederholt Anmeldeprobleme. - Ein Dienst muss regelmäßig neu gestartet werden. - Nach Updates entstehen ähnliche Fehler. - Ein Speicherbereich läuft immer wieder voll. Wenn solche Fälle nur einzeln gelöst werden, bleibt die eigentliche Ursache bestehen. Problem Management hilft dabei: - wiederkehrende Incidents zu erkennen, - Ursachen systematisch zu untersuchen, - Workarounds bereitzustellen, - dauerhafte Lösungen vorzubereiten, - bekannte Fehler zu dokumentieren, - und zukünftige Incidents zu vermeiden. --- **Incident und Problem unterscheiden** | Incident | Problem | |---|---| | ungeplante Unterbrechung oder Qualitätsminderung eines Service | Ursache oder mögliche Ursache eines oder mehrerer Incidents | | Fokus auf schnelle Wiederherstellung | Fokus auf Ursachenverständnis und Vermeidung | | kurzfristige Bearbeitung | häufig längerfristige Analyse | | Workaround kann ausreichen | dauerhafte Lösung wird angestrebt | | Ziel: Service wieder nutzbar machen | Ziel: Wiederholung verhindern oder Auswirkungen reduzieren | Beispiel: **Incident** Benutzer können sich nicht am VPN anmelden. **Problem** Die Ursache liegt in einer fehlerhaften Zertifikatsverteilung, die regelmäßig zu abgelaufenen Client-Zertifikaten führt. --- **Problem Management ist nicht nur Fehlerbehebung** Problem Management bedeutet nicht nur: > Jemand sucht den technischen Fehler. Es umfasst auch: - Muster erkennen, - Daten auswerten, - Risiken bewerten, - bekannte Fehler dokumentieren, - Workarounds bereitstellen, - Änderungen vorbereiten, - Wissen nutzbar machen, - und Verbesserungen nachverfolgen. Ein Problem kann auch dann angelegt werden, wenn noch keine endgültige Ursache bekannt ist. --- **Problem, Known Error und Workaround unterscheiden** | Begriff | Bedeutung | |---|---| | **Problem** | Ursache oder mögliche Ursache eines oder mehrerer Incidents | | **Known Error** | Problem mit bekannter Ursache oder bekanntem Fehlerzustand | | **Workaround** | vorübergehende Möglichkeit, Auswirkungen zu umgehen oder zu reduzieren | | **dauerhafte Lösung** | Maßnahme, die die Ursache beseitigt oder das Risiko nachhaltig reduziert | Beispiel: **Problem** Mehrere Clients verlieren nach dem Ruhezustand die VPN-Verbindung. **Known Error** Bestimmte Client-Version verursacht nach dem Ruhezustand fehlerhafte Tunnelzustände. **Workaround** VPN-Client vollständig beenden und neu starten. **Dauerhafte Lösung** Client-Version aktualisieren oder Konfiguration ändern. --- **Problem Management und Incident Management arbeiten zusammen** Incident Management liefert wichtige Informationen für Problem Management. Dazu gehören: - betroffene Services, - Symptome, - Zeitpunkte, - Häufigkeit, - betroffene Benutzer, - Workarounds, - technische Maßnahmen, - Logs, - und wiederkehrende Muster. Problem Management liefert zurück: - Known Errors, - Workarounds, - Ursacheninformationen, - Empfehlungen, - Knowledge-Artikel, - und Change-Vorschläge. Dadurch werden zukünftige Incidents schneller lösbar oder vollständig vermieden. --- **Reaktives Problem Management** Reaktives Problem Management beginnt nach Incidents. Auslöser können sein: - wiederkehrende Incidents, - Major Incidents, - hohe Auswirkungen, - unbekannte Ursache, - viele gleichartige Meldungen, - häufige Workarounds, - auffällige Eskalationen, - oder wiederholte SLA-Gefährdung. Beispiel: Nach einem Major Incident wird untersucht, warum ein zentraler Dienst ausgefallen ist und warum Monitoring nicht früher gewarnt hat. --- **Proaktives Problem Management** Proaktives Problem Management sucht nach Problemen, bevor größere Incidents entstehen. Informationsquellen können sein: - Trends, - Monitoringdaten, - Kapazitätsdaten, - Loganalysen, - Service Reviews, - Sicherheitsmeldungen, - Benutzerfeedback, - wiederkehrende kleine Störungen, - technische Schulden, - und Lieferanteninformationen. Beispiel: Monitoring zeigt, dass Speicherplatz auf mehreren Servern regelmäßig kritisch wird. Noch ist kein Ausfall eingetreten. Problem Management kann trotzdem prüfen, warum Kapazitätsplanung, Alarmierung oder Bereinigung nicht ausreichen. --- **Typische Auslöser für einen Problem Record** Ein Problem Record kann sinnvoll sein, wenn: - mehrere ähnliche Incidents auftreten, - ein Major Incident stattgefunden hat, - die Ursache eines wichtigen Incidents unbekannt bleibt, - ein Workaround häufig genutzt werden muss, - ein Service wiederholt instabil ist, - ein technisches Risiko erkennbar wird, - ein Lieferant einen bekannten Fehler bestätigt, - ein Sicherheitsrisiko vermutet wird, - oder ein Trend auf zukünftige Störungen hindeutet. Nicht jeder einzelne Incident benötigt automatisch einen Problem Record. --- **Problem Record** Ein Problem Record dokumentiert die Bearbeitung eines Problems. Typische Inhalte: - Beschreibung des Problems, - betroffener Service, - betroffene Configuration Items, - zugehörige Incidents, - Auswirkungen, - Priorität, - bekannte Symptome, - Hypothesen, - Untersuchungsergebnisse, - Ursache, falls bekannt, - Workaround, - Known-Error-Status, - empfohlene dauerhafte Lösung, - erforderlicher Change, - Verantwortlicher, - Status, - Lessons Learned. Das konkrete Format hängt vom verwendeten ITSM-System und der Organisation ab. --- **Priorisierung von Problems** Problems sollten priorisiert werden. Kriterien können sein: - Anzahl betroffener Incidents, - Auswirkung auf Services, - geschäftliche Kritikalität, - Sicherheitsrisiko, - Häufigkeit, - Kosten, - Aufwand, - Risiko einer Wiederholung, - Verfügbarkeit eines Workarounds, - und Nutzen einer dauerhaften Lösung. Ein Problem mit wenigen Incidents kann trotzdem hohe Priorität besitzen, wenn es einen kritischen Service oder ein hohes Sicherheitsrisiko betrifft. --- **Problem Management und Change Enablement** Dauerhafte Lösungen erfordern häufig Änderungen. Beispiele: - Softwareupdate, - Konfigurationsänderung, - Austausch defekter Hardware, - Änderung einer Firewall-Regel, - Anpassung eines Prozesses, - neues Monitoring, - Änderung eines Deployments, - Architekturverbesserung. Solche Maßnahmen sollten nicht unkontrolliert umgesetzt werden. Sie müssen entsprechend Risiko, Auswirkung und Organisationsregeln über Change Enablement gesteuert werden. --- **Problem Management und Knowledge Management** Problem Management erzeugt wertvolles Wissen. Dieses Wissen sollte nutzbar gemacht werden für: - Service Desk, - Fachgruppen, - Benutzer, - Major-Incident-Bearbeitung, - Self-Service, - Runbooks, - Known-Error-Datenbank, - und Continual Improvement. Beispiele: - bekannter Fehler mit Workaround, - Diagnosehinweise, - Eskalationskriterien, - betroffene Versionen, - Abbruchkriterien, - dauerhafte Lösung nach Change. Wissen darf nicht nur im Kopf einzelner Spezialisten bleiben. --- **Problem Management und Service Configuration Management** Für Ursachenanalysen sind Service- und CI-Informationen wichtig. Hilfreich sind: - betroffene Configuration Items, - Abhängigkeiten zwischen Services, - installierte Versionen, - letzte Änderungen, - Standorte, - Verantwortliche, - Lieferanten, - und technische Beziehungen. Ohne diese Informationen wird Ursachenanalyse oft langsam und ungenau. Beispiel: Mehrere Anwendungen fallen aus. Erst durch die CI-Beziehungen wird erkennbar, dass alle vom gleichen Datenbankcluster abhängig sind. --- **Problem Management und Continual Improvement** Problem Management ist eng mit kontinuierlicher Verbesserung verbunden. Aus Problems können entstehen: - Verbesserungsmaßnahmen, - neue Standards, - bessere Überwachung, - aktualisierte Runbooks, - Knowledge-Artikel, - Schulungen, - Automatisierungen, - Architekturänderungen, - oder Prozessanpassungen. Ein gelöstes Problem sollte deshalb nicht nur abgeschlossen werden. Es sollte geprüft werden, welche Erkenntnisse für zukünftige Arbeit nutzbar sind. --- **Problem Management und Risiko** Nicht jede Ursache kann sofort beseitigt werden. Manchmal ist eine dauerhafte Lösung: - zu teuer, - zu riskant, - technisch noch nicht verfügbar, - abhängig von einem Lieferanten, - nur in einem Wartungsfenster möglich, - oder organisatorisch noch nicht entschieden. Dann muss das verbleibende Risiko bewusst bewertet und dokumentiert werden. Mögliche Maßnahmen: - Workaround bereitstellen, - Monitoring verbessern, - Benutzer informieren, - Risiko akzeptieren, - Change später planen, - Lieferant einbinden, - oder Service-Level-Erwartungen anpassen. --- **Workaround als wichtiger Zwischenschritt** Ein Workaround ist keine endgültige Lösung, kann aber sehr wertvoll sein. Er hilft dabei: - Incidents schneller zu lösen, - Auswirkungen zu reduzieren, - Benutzer arbeitsfähig zu halten, - Zeit für Ursachenanalyse zu gewinnen, - Service Desk zu unterstützen. Ein Workaround sollte dokumentiert werden mit: - Anwendungsbereich, - Voraussetzungen, - Arbeitsschritten, - Risiken, - Einschränkungen, - Gültigkeitsdauer, - und Eskalationshinweisen. --- **Dauerhafte Lösung** Eine dauerhafte Lösung soll die Ursache beseitigen oder das Risiko wesentlich reduzieren. Beispiele: - fehlerhafte Softwareversion aktualisieren, - Zertifikatsüberwachung einführen, - Kapazität erweitern, - defekte Hardware austauschen, - Berechtigungskonzept korrigieren, - Prozesslücke schließen, - Monitoring verbessern, - automatisierte Prüfung einführen, - Schulung durchführen. Nicht jede dauerhafte Lösung ist rein technisch. Auch Prozesse, Kommunikation und Verantwortlichkeiten können Ursachen sein. --- **Technische Ursache und organisatorische Ursache** Ein Problem kann mehrere Ursachenebenen besitzen. Beispiel: Ein Zertifikat läuft ab. **Technische Ursache** Zertifikat ist nicht mehr gültig. **Organisatorische Ursache** Es gab keinen verantwortlichen Owner für Zertifikatsüberwachung. **Prozessursache** Es gab keinen geregelten Ablauf für rechtzeitige Erneuerung. **Verbesserung** Monitoring, Verantwortlichkeit und Erneuerungsprozess werden eingeführt. > **Merke** > > Die technische Ursache ist oft nur ein Teil der Gesamtursache. --- **Problem Management ist keine Schuldsuche** Problem Management soll nicht klären, wer schuld ist. Ziel ist: - verstehen, - lernen, - verbessern, - Wiederholungen vermeiden, - Risiken reduzieren, - Servicequalität erhöhen. Eine Schuldzuweisung führt häufig dazu, dass Informationen zurückgehalten werden. Eine lernorientierte Analyse führt zu besseren Ergebnissen. --- **Praxisbeispiel: Wiederkehrende VPN-Störungen** **Ausgangslage** Mehrere Benutzer melden regelmäßig VPN-Abbrüche. Incident Management stellt den Zugang jeweils durch Neustart des Clients wieder her. **Problem Management** Die Incidents werden gemeinsam ausgewertet. Auffällig ist: - gleiche Client-Version, - gleiche Fehlermeldung, - besonders häufig nach Ruhezustand, - Workaround immer identisch. **Ergebnis** Ein Known Error wird dokumentiert. Ein Workaround wird für den Service Desk bereitgestellt. Ein Change zur Aktualisierung des VPN-Clients wird geplant. --- **Praxisbeispiel: Druckerwarteschlange blockiert** **Ausgangslage** Ein Etikettendrucker im Versand blockiert mehrfach pro Woche. Incident Management entfernt jeweils den fehlerhaften Druckauftrag. **Problem Management** Die Analyse zeigt: - bestimmte PDF-Dateien verursachen den Fehler, - Treiber ist veraltet, - Workaround ist bekannt, - Versand ist regelmäßig betroffen. **Dauerhafte Lösung** Treiber wird getestet und über Change Enablement aktualisiert. Zusätzlich wird ein Knowledge-Artikel für den Service Desk erstellt. --- **Praxisbeispiel: Speicher läuft voll** **Ausgangslage** Ein Server erzeugt regelmäßig Incidents wegen vollem Speicher. Incident Management löscht temporäre Dateien. **Problem Management** Die Untersuchung zeigt: - Logrotation funktioniert nicht korrekt, - Monitoring warnt zu spät, - Verantwortlichkeit für Logwachstum war unklar. **Verbesserung** - Logrotation korrigieren, - Monitoring-Grenzwerte anpassen, - Verantwortlichen festlegen, - Runbook aktualisieren. --- **Typische Fehler** **Fehler 1** Jeder Incident wird einzeln bearbeitet, ohne Muster zu erkennen. --- **Fehler 2** Problem Management wird erst nach sehr großen Störungen genutzt. --- **Fehler 3** Workarounds werden nicht dokumentiert. --- **Fehler 4** Known Errors bleiben nur einzelnen Spezialisten bekannt. --- **Fehler 5** Die technische Ursache wird gefunden, aber organisatorische Ursachen werden ignoriert. --- **Fehler 6** Dauerhafte Lösungen werden ohne Change-Bewertung umgesetzt. --- **Fehler 7** Problems werden eröffnet, aber nicht aktiv verfolgt. --- **Fehler 8** Priorisierung fehlt. --- **Fehler 9** Problem Management wird als Schuldsuche verstanden. --- **Fehler 10** Lessons Learned werden nicht in Knowledge, Monitoring oder Prozesse übernommen. --- **Checkliste Problem erfassen** - [ ] Wiederkehrende oder schwerwiegende Incidents geprüft - [ ] betroffener Service beschrieben - [ ] zugehörige Incidents verknüpft - [ ] Auswirkungen dokumentiert - [ ] Symptome zusammengefasst - [ ] erste Hypothesen dokumentiert - [ ] Priorität bewertet - [ ] Verantwortlicher benannt - [ ] Workaround geprüft - [ ] Knowledge-Bedarf erkannt --- **Checkliste Problem bearbeiten** - [ ] relevante Daten gesammelt - [ ] Incidents verglichen - [ ] Changes geprüft - [ ] Logs und Monitoringdaten ausgewertet - [ ] betroffene CIs geprüft - [ ] Ursachenhypothesen getestet - [ ] Workaround dokumentiert - [ ] Known Error bewertet - [ ] dauerhafte Lösung vorgeschlagen - [ ] Change-Bedarf geprüft - [ ] Risiko dokumentiert - [ ] Stakeholder informiert --- **Checkliste Problem abschließen** - [ ] Ursache ausreichend verstanden oder Risiko bewertet - [ ] Workaround dokumentiert - [ ] Known Error aktualisiert - [ ] dauerhafte Lösung umgesetzt oder bewusst geplant - [ ] zugehörige Incidents berücksichtigt - [ ] Knowledge-Artikel erstellt oder aktualisiert - [ ] Monitoring oder Runbooks angepasst - [ ] Lessons Learned dokumentiert - [ ] Verbesserungsmaßnahmen verfolgt - [ ] Rest Risiko bekannt und akzeptiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker für Systemintegration liefern häufig die wichtigsten technischen Informationen für Problem Management. Dazu gehören: - Logs, - Messwerte, - Konfigurationen, - Versionsstände, - Abhängigkeiten, - Change-Historie, - Workarounds, - Fehlerhäufigkeit, - und technische Hypothesen. Wichtig ist nicht nur, einen Incident schnell zu beheben. Wichtig ist auch, wiederkehrende Ursachen zu erkennen und die Umgebung dauerhaft stabiler zu machen. --- **Zusammenfassung** > Incidents treten auf > ↓ > Muster oder schwere Auswirkungen werden erkannt > ↓ > Problem Record wird erstellt > ↓ > Ursache oder mögliche Ursache wird untersucht > ↓ > Workaround wird dokumentiert > ↓ > Known Error wird bei Bedarf erfasst > ↓ > dauerhafte Lösung wird geplant > ↓ > Change, Knowledge und Improvement werden eingebunden > ↓ > zukünftige Incidents werden reduziert oder schneller lösbar --- **Merksätze** > Incident Management stellt den Service wieder her. > Problem Management versteht und reduziert Ursachen. > Ein Workaround ist hilfreich, aber keine dauerhafte Lösung. > Ein Known Error muss nutzbar dokumentiert sein. > Problem Management ist Lernen, nicht Schuldsuche. > Gute Problem Records machen Services langfristig stabiler. --- **Verwandte Seiten** - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - 4.2 Ursachenanalyse - 4.3 Workarounds und Known Errors - 4.4 Trendanalyse und proaktives Problem Management - Change Enablement - Knowledge Management - Service Configuration Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Problem-Record-Inhalte, - Beispiele, - Checklisten, - Priorisierungskriterien, - Workaround-Hinweise, - und Praxisabläufe sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Problem-Record-Vorlage, - RCA-Methode, - Prioritätsmatrix, - Workaround-Struktur, - Review-Vorgabe, - oder konkrete Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisation, - Datenqualität, - Supportmodell, - Lieferanten, - Service Levels, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 4.2 Ursachenanalyse (Root Cause Analysis – RCA) > **Kurz erklärt** > > Ursachenanalyse bedeutet, systematisch zu untersuchen, warum ein Incident oder Problem entstanden ist. > > Ziel ist nicht, möglichst schnell einen Schuldigen zu finden. > > Ziel ist, die tatsächlichen technischen, organisatorischen oder prozessualen Ursachen zu verstehen, damit Wiederholungen verhindert oder Auswirkungen reduziert werden können. --- **Warum Ursachenanalyse wichtig ist** Ohne Ursachenanalyse werden Incidents häufig nur kurzfristig behoben. Beispiele: - Dienst wird immer wieder neu gestartet. - Speicher wird regelmäßig manuell bereinigt. - Benutzerkonten werden mehrfach entsperrt. - VPN-Client wird immer wieder neu installiert. - Druckwarteschlange wird regelmäßig geleert. - Zertifikate werden erst nach Ablauf erneuert. Solche Maßnahmen können kurzfristig helfen. Sie beantworten aber nicht die Frage: > Warum tritt der Fehler immer wieder auf? Ursachenanalyse hilft dabei: - wiederkehrende Störungen zu vermeiden, - Risiken sichtbar zu machen, - dauerhafte Lösungen vorzubereiten, - Workarounds gezielt zu dokumentieren, - Verbesserungen abzuleiten, - und technische sowie organisatorische Schwachstellen zu erkennen. --- **Incident-Lösung und Ursachenanalyse unterscheiden** | Incident Management | Problem Management / RCA | |---|---| | Service schnell wiederherstellen | Ursache verstehen | | kurzfristiger Fokus | nachhaltiger Fokus | | Workaround kann genügen | dauerhafte Lösung wird vorbereitet | | Ziel: Benutzer wieder arbeitsfähig machen | Ziel: Wiederholung verhindern oder Risiko senken | | Zeitdruck häufig hoch | Analyse kann länger dauern | Beispiel: Ein Webservice ist nicht erreichbar. **Incident Management** - Dienststatus prüfen - Dienst kontrolliert neu starten - Erreichbarkeit testen - Benutzer informieren **Ursachenanalyse** - Warum ist der Dienst abgestürzt? - Warum wurde es nicht früher erkannt? - Warum gab es keinen automatischen Neustart? - Warum war kein Monitoring vorhanden? - Warum trat der Fehler nach einem bestimmten Deployment auf? > **Merke** > > Eine schnelle Wiederherstellung ist wichtig. > > Sie ersetzt aber keine Ursachenanalyse, wenn der Fehler wiederkehren kann. --- **Symptom, Ursache und Grundursache unterscheiden** | Begriff | Bedeutung | Beispiel | |---|---|---| | **Symptom** | sichtbares Fehlverhalten | Benutzer kann sich nicht anmelden | | **direkte Ursache** | unmittelbarer technischer Auslöser | Zertifikat ist abgelaufen | | **Grundursache** | tiefer liegende Ursache | kein Prozess zur Zertifikatsüberwachung | | **beitragender Faktor** | Umstand, der den Fehler begünstigt | Warnung wurde nicht an das richtige Team gesendet | | **Auswirkung** | Folge für Benutzer oder Geschäft | Fachanwendung nicht nutzbar | Ein Problem besitzt häufig nicht nur eine Ursache. Oft wirken mehrere Faktoren zusammen. Beispiel: Ein Server fällt aus, weil der Speicher voll ist. Mögliche Ursachenebenen: - Logdateien wachsen stark. - Logrotation funktioniert nicht. - Monitoring warnt zu spät. - Alarm wird an eine nicht mehr gepflegte Verteilerliste gesendet. - Verantwortlichkeit für den Server ist unklar. Nur die Aussage „Speicher voll“ beschreibt noch nicht die vollständige Ursache. --- **Ursachenanalyse ist keine Schuldzuweisung** Ursachenanalyse soll nicht klären: > Wer hat den Fehler gemacht? Sondern: > Welche Bedingungen haben dazu geführt, dass dieser Fehler entstehen oder unentdeckt bleiben konnte? Eine schuldorientierte Kultur führt häufig dazu, dass: - Informationen zurückgehalten werden, - Fehler verschwiegen werden, - Symptome beschönigt werden, - Mitarbeitende defensiv reagieren, - und echte Ursachen verborgen bleiben. Eine lernorientierte Analyse fragt stattdessen: - Welche Annahmen waren falsch? - Welche Kontrolle hat gefehlt? - Welche Information war nicht verfügbar? - Welcher Prozess war unklar? - Welche technische Schutzmaßnahme hätte geholfen? - Welche Dokumentation war unvollständig? - Welche Automatisierung hätte den Fehler verhindert? --- **Grundprinzip einer guten Ursachenanalyse** Eine gute Ursachenanalyse ist: - faktenbasiert, - nachvollziehbar, - strukturiert, - frei von vorschnellen Schuldzuweisungen, - offen für mehrere Ursachen, - mit Daten belegbar, - und auf Verbesserungen ausgerichtet. Sie trennt: - Beobachtungen, - Vermutungen, - Hypothesen, - bestätigte Fakten, - Schlussfolgerungen, - und Maßnahmen. --- **Beobachtung und Hypothese trennen** Ungeeignet: > Die Firewall war schuld. Besser: > Verbindungen zur Anwendung auf Port 443 schlugen vom Standort Süd fehl. Eine Firewall-Regel ist eine mögliche Ursache und wird geprüft. Ungeeignet: > Der Benutzer hat etwas falsch gemacht. Besser: > Der Fehler trat nach einer Änderung der Berechtigungsgruppe auf. Die Auswirkungen der Gruppenänderung werden geprüft. Ungeeignet: > Das Update hat alles kaputt gemacht. Besser: > Der Incident begann 20 Minuten nach dem Update. Ein Zusammenhang ist möglich, aber noch nicht bestätigt. > **Merke** > > Zeitlicher Zusammenhang ist ein Hinweis. > > Er ist noch kein Beweis. --- **Typischer Ablauf einer Ursachenanalyse** Ein möglicher Ablauf: Problem beschreiben ↓ Fakten sammeln ↓ Zeitlinie erstellen ↓ Umfang und Auswirkungen bestimmen ↓ Hypothesen bilden ↓ Hypothesen prüfen ↓ Ursache und beitragende Faktoren bestimmen ↓ Workaround dokumentieren ↓ dauerhafte Lösung oder Verbesserungen ableiten ↓ Maßnahmen priorisieren und verfolgen Nicht jede Organisation nutzt exakt diesen Ablauf. Wichtig ist, dass die Analyse nachvollziehbar bleibt. --- **Problem klar beschreiben** Am Anfang sollte das Problem eindeutig beschrieben werden. Eine gute Problembeschreibung enthält: - betroffenen Service, - beobachtetes Symptom, - Zeitraum, - betroffene Benutzer oder Standorte, - Auswirkung, - Häufigkeit, - bekannte Auslöser, - und aktuellen Workaround. Ungeeignet: > VPN macht Probleme. Besser: > Seit dem Client-Update vom 12.08.2026 verlieren mehrere Benutzer nach dem Ruhezustand die VPN-Verbindung. Betroffen sind Windows-Notebooks mit Client-Version 5.8. Der Workaround ist ein vollständiger Neustart des VPN-Clients. --- **Fakten sammeln** Geeignete Informationsquellen: - Incident Records, - Problem Records, - Change Records, - Monitoringdaten, - Logdateien, - Fehlermeldungen, - Zeitstempel, - Benutzerfeedback, - Konfigurationsdaten, - CMDB-Informationen, - Herstellerhinweise, - Netzwerkdaten, - Backup- und Restore-Informationen, - Sicherheitsmeldungen, - Service-Statusmeldungen. Wichtig ist, die Daten nicht nur zu sammeln, sondern sie fachlich einzuordnen. Nicht jede Logmeldung ist relevant. Nicht jeder Benutzerbericht beschreibt die technische Ursache. --- **Zeitlinie erstellen** Eine Zeitlinie hilft, Ereignisse in die richtige Reihenfolge zu bringen. Beispiel: | Zeitpunkt | Ereignis | |---|---| | 08:00 Uhr | Deployment abgeschlossen | | 08:20 Uhr | erste Fehlermeldung im Monitoring | | 08:25 Uhr | erste Benutzermeldung | | 08:35 Uhr | Incident als P1 bewertet | | 08:45 Uhr | Rollback vorbereitet | | 09:05 Uhr | Workaround aktiv | | 09:30 Uhr | Service stabil | Eine Zeitlinie hilft bei Fragen wie: - Was geschah vor dem Incident? - Wann begann die Auswirkung? - Welche Änderung war zeitlich relevant? - Wann wurde der Incident erkannt? - Wann wurde eskaliert? - Welche Maßnahme hatte welchen Effekt? - Wo entstanden Verzögerungen? --- **Umfang bestimmen** Zu prüfen ist: - Sind einzelne Benutzer betroffen? - Ist ein Team betroffen? - Ist ein Standort betroffen? - Sind mehrere Standorte betroffen? - Sind externe Kunden betroffen? - Sind alle Funktionen betroffen oder nur einzelne? - Sind bestimmte Versionen betroffen? - Sind bestimmte Geräte betroffen? - Sind bestimmte Netzwerkpfade betroffen? - Sind nur neue Sitzungen betroffen oder auch bestehende? Der Umfang hilft, mögliche Ursachen einzugrenzen. Beispiel: Wenn nur ein Standort betroffen ist, sind zentrale Anwendung und Benutzerkonto möglicherweise weniger wahrscheinlich als Standortnetz, Routing, DNS oder lokale Firewall. --- **Änderungen prüfen** Viele Probleme stehen im Zusammenhang mit Änderungen. Zu prüfen sind: - Softwareupdates, - Konfigurationsänderungen, - Firewall-Regeln, - DNS-Änderungen, - Zertifikatswechsel, - Gruppenrichtlinien, - neue Berechtigungen, - neue Versionen, - Datenbankänderungen, - Netzwerkumbauten, - Lieferantenänderungen, - Cloud-Konfigurationsänderungen. Wichtig: Ein Change ist nicht automatisch die Ursache. Er ist zunächst ein relevanter Untersuchungsgegenstand. --- **5-Why-Methode** Die **5-Why-Methode** fragt mehrfach „Warum?“, um von einem Symptom zu tiefer liegenden Ursachen zu gelangen. Beispiel: **Problem** Ein Webservice war nicht erreichbar. **Warum 1** Warum war der Webservice nicht erreichbar? > Der Dienst war abgestürzt. **Warum 2** Warum ist der Dienst abgestürzt? > Der Speicher war vollständig belegt. **Warum 3** Warum war der Speicher vollständig belegt? > Logdateien sind stark angewachsen. **Warum 4** Warum wurden Logdateien nicht bereinigt? > Die Logrotation war fehlerhaft konfiguriert. **Warum 5** Warum wurde die fehlerhafte Logrotation nicht erkannt? > Es gab kein Monitoring für Logwachstum und keine regelmäßige Prüfung. Mögliche Maßnahmen: - Logrotation korrigieren, - Monitoring ergänzen, - Alarmgrenzen definieren, - Runbook aktualisieren, - Verantwortlichkeit festlegen. --- **Grenzen der 5-Why-Methode** Die 5-Why-Methode ist einfach und nützlich. Sie hat aber Grenzen. Risiken: - zu lineares Denken, - nur eine Ursache wird betrachtet, - komplexe Zusammenhänge werden vereinfacht, - Antworten hängen stark von der Perspektive ab, - Schuldzuweisungen können entstehen, - organisatorische Faktoren werden übersehen. Deshalb sollte sie bei komplexen Incidents mit anderen Methoden kombiniert werden. --- **Ishikawa-Diagramm** Das **Ishikawa-Diagramm** wird auch Ursache-Wirkungs-Diagramm oder Fischgräten-Diagramm genannt. Es hilft, mögliche Ursachen nach Kategorien zu sortieren. Mögliche Kategorien in der IT: - Mensch, - Prozess, - Technik, - Umgebung, - Organisation, - Lieferant, - Dokumentation, - Daten, - Sicherheit. Beispiel: Problem: > Wiederkehrende VPN-Abbrüche. Mögliche Ursachen: | Kategorie | Beispiele | |---|---| | Mensch | Benutzer versetzen Notebook in Ruhezustand | | Prozess | Clientupdates werden nicht getestet | | Technik | fehlerhafte VPN-Client-Version | | Umgebung | instabile WLAN-Verbindung | | Organisation | kein Owner für Clientstandard | | Lieferant | bekannter Fehler in Version | | Dokumentation | Workaround fehlt in Knowledge Base | | Sicherheit | Zertifikatsprüfung schlägt fehl | Das Diagramm zwingt dazu, nicht nur eine technische Ursache zu betrachten. --- **Pareto-Analyse** Die Pareto-Analyse hilft, die wichtigsten Ursachen oder Kategorien zu erkennen. Grundidee: Ein kleiner Teil der Ursachen erzeugt häufig einen großen Teil der Auswirkungen. Beispiel: | Kategorie | Anzahl Incidents pro Monat | |---|---:| | Passwort und MFA | 120 | | VPN | 75 | | Drucker | 40 | | Softwareinstallation | 25 | | Sonstiges | 20 | Wenn Passwort/MFA und VPN den größten Anteil ausmachen, können Verbesserungen dort besonders viel Wirkung entfalten. Die Pareto-Analyse ersetzt keine Ursachenanalyse. Sie hilft bei der Priorisierung. --- **Kepner-Tregoe-Ansatz** Ein strukturierter Ansatz kann sein, zu unterscheiden: - Was ist betroffen? - Was ist nicht betroffen? - Wo tritt es auf? - Wo tritt es nicht auf? - Seit wann tritt es auf? - Seit wann nicht? - Wie stark ist die Auswirkung? - Welche Veränderung passt dazu? Beispiel: | Frage | Antwort | |---|---| | Was ist betroffen? | VPN-Verbindung nach Ruhezustand | | Was ist nicht betroffen? | VPN nach Neustart | | Wo tritt es auf? | Windows-Notebooks | | Wo nicht? | macOS-Geräte | | Seit wann? | seit Client-Version 5.8 | | Veränderung | Clientupdate am Vortag | Diese Gegenüberstellung hilft, Hypothesen gezielt einzugrenzen. --- **Fehlerbaum und Abhängigkeiten** Bei komplexen Services kann eine Abhängigkeitsanalyse helfen. Zu prüfen sind: - Anwendungen, - Datenbanken, - Identitätsdienste, - Netzwerkverbindungen, - DNS, - Zertifikate, - Firewalls, - Load Balancer, - Storage, - Cloud-Dienste, - externe APIs, - Lieferantenservices. Beispiel: Eine Anwendung ist nicht erreichbar. Mögliche Abhängigkeiten: Benutzer ↓ Netzwerk ↓ DNS ↓ Load Balancer ↓ Webserver ↓ Anwendung ↓ Datenbank ↓ Storage Wenn mehrere Anwendungen betroffen sind, kann eine gemeinsame Abhängigkeit wahrscheinlicher sein. --- **Datenqualität beachten** Ursachenanalyse ist nur so gut wie die verfügbaren Daten. Probleme entstehen durch: - fehlende Logs, - falsche Zeitstempel, - unterschiedliche Zeitzonen, - unvollständige Tickets, - veraltete CMDB, - fehlende Change-Dokumentation, - unklare Serviceabhängigkeiten, - fehlende Monitoringdaten, - nicht dokumentierte manuelle Eingriffe. Eine wichtige Verbesserung kann daher sein: > Die Datenbasis für zukünftige Analysen verbessern. --- **Korrelation und Kausalität unterscheiden** Nur weil zwei Ereignisse zeitlich zusammen auftreten, bedeutet das nicht, dass eines das andere verursacht hat. Beispiel: Ein Incident beginnt kurz nach einem Windows-Update. Mögliche Schlussfolgerungen: - Das Update ist die Ursache. - Das Update hat nur eine bestehende Schwäche sichtbar gemacht. - Ein anderer Change trat gleichzeitig auf. - Der Incident wäre unabhängig davon eingetreten. Deshalb müssen Hypothesen geprüft werden. --- **Hypothesen testen** Eine Hypothese sollte überprüfbar sein. Beispiel: **Hypothese** VPN-Abbrüche entstehen durch Client-Version 5.8. **Test** - betroffene Geräteversionen vergleichen, - nicht betroffene Geräte prüfen, - bekannte Herstellerhinweise suchen, - Testgerät mit älterer Version prüfen, - kontrolliertes Update durchführen, - Logs auswerten. **Ergebnis** Wenn nur Version 5.8 betroffen ist und ein Downgrade den Fehler beseitigt, wird die Hypothese stärker. Trotzdem muss geprüft werden, ob weitere Faktoren beteiligt sind. --- **Kontrollierte Tests** Tests sollten möglichst kontrolliert durchgeführt werden. Wichtig: - nicht mehrere Änderungen gleichzeitig, - Testumgebung nutzen, wenn möglich, - Risiko bewerten, - Messwerte vorher und nachher vergleichen, - Ergebnisse dokumentieren, - Rollback planen, - Change-Vorgaben beachten. Ungeeignet: > Wir ändern DNS, Firewall, Zertifikat und Clientversion gleichzeitig. Besser: > Wir testen zuerst die Clientversion auf einem betroffenen Gerät und dokumentieren das Ergebnis. --- **RCA bei Major Incidents** Nach Major Incidents ist eine Ursachenanalyse besonders wichtig. Zu betrachten sind nicht nur technische Ursachen. Auch zu prüfen: - Wurde der Incident rechtzeitig erkannt? - Waren die Alarme verständlich? - Wurde richtig priorisiert? - War Ownership klar? - Wurde rechtzeitig eskaliert? - War Kommunikation ausreichend? - Gab es einen Workaround? - Waren Abhängigkeiten bekannt? - Waren Lieferanten erreichbar? - Wurde der Service stabil wiederhergestellt? Ein Major Incident Review sollte nicht nur fragen: > Warum ist das System ausgefallen? Sondern auch: > Warum waren die Auswirkungen so groß? --- **Technische Ursachen** Mögliche technische Ursachen: - Softwarefehler, - Hardwaredefekt, - fehlerhafte Konfiguration, - abgelaufenes Zertifikat, - Netzwerkausfall, - DNS-Fehler, - Speicher voll, - Datenbankproblem, - fehlgeschlagenes Backup, - Überlastung, - falsche Berechtigungen, - inkompatible Versionen. Technische Ursachen sind oft sichtbar. Sie sind aber nicht immer die tiefste Ursache. --- **Prozessuale Ursachen** Mögliche prozessuale Ursachen: - Change wurde nicht ausreichend geprüft, - Monitoring wurde nicht aktualisiert, - Dokumentation war veraltet, - Genehmigungsweg war unklar, - Eskalationsweg fehlte, - Runbook war unvollständig, - Backup-Wiederherstellung wurde nie getestet, - Serviceübergabe war unvollständig, - Verantwortlichkeit war nicht festgelegt. Prozessuale Ursachen erklären häufig, warum ein technischer Fehler nicht verhindert oder früher erkannt wurde. --- **Organisatorische Ursachen** Mögliche organisatorische Ursachen: - unklare Ownership, - fehlende Ressourcen, - fehlende Schulung, - unklare Prioritäten, - fehlende Abstimmung zwischen Teams, - ungeeignete Lieferantensteuerung, - fehlende Vertretung, - Silodenken, - unklare Entscheidungskompetenz. Diese Ursachen sind oft unangenehm, aber wichtig. Wenn sie ignoriert werden, treten ähnliche Probleme wieder auf. --- **Menschliche Faktoren** Menschen machen Fehler. Gute Ursachenanalyse fragt deshalb nicht nur: > Warum hat jemand falsch gehandelt? Sondern: > Warum war dieser Fehler möglich oder wahrscheinlich? Zu prüfen sind: - unklare Oberfläche, - fehlende Warnung, - Zeitdruck, - unvollständige Anleitung, - fehlende Schulung, - zu viele manuelle Schritte, - ungünstige Berechtigungen, - fehlende Prüfung, - widersprüchliche Informationen. Ziel ist, Systeme und Prozesse robuster zu machen. --- **Beitragende Faktoren dokumentieren** Nicht jede Ursache ist allein verantwortlich. Beispiel: Ein Datenbankserver fällt aus. Beitragende Faktoren: - Speicherplatz war knapp. - Monitoringgrenze war zu hoch gesetzt. - Alarm ging an falschen Verteiler. - Bereinigungsskript war deaktiviert. - Dokumentation war veraltet. - Bereitschaft war nicht informiert. Die Kombination führte zur Störung. Deshalb sollten mehrere Faktoren dokumentiert werden. --- **Maßnahmen ableiten** Aus der Ursachenanalyse sollten konkrete Maßnahmen entstehen. Gute Maßnahmen sind: - eindeutig beschrieben, - einer verantwortlichen Person oder Gruppe zugewiesen, - terminiert, - risikobewertet, - überprüfbar, - und nachverfolgbar. Beispiele: | Ursache | Maßnahme | |---|---| | Zertifikatsablauf wurde nicht überwacht | Monitoring für Zertifikatsgültigkeit einführen | | Logrotation war fehlerhaft | Konfiguration korrigieren und Test ergänzen | | Workaround war unbekannt | Knowledge-Artikel erstellen | | Eskalation erfolgte zu spät | Eskalationskriterien überarbeiten | | Serviceabhängigkeit war unbekannt | CMDB-Beziehung ergänzen | | Lieferant reagierte zu langsam | Lieferanteneskalationsweg prüfen | --- **Maßnahmen priorisieren** Nicht jede Maßnahme kann sofort umgesetzt werden. Zu bewerten sind: - Nutzen, - Aufwand, - Risiko, - Kosten, - Sicherheitsrelevanz, - Häufigkeit des Problems, - Kritikalität des betroffenen Service, - Verfügbarkeit eines Workarounds, - Abhängigkeit von Lieferanten, - notwendige Changes. Eine Maßnahme mit hoher Risikoreduktion kann wichtiger sein als eine einfache technische Optimierung. --- **Wirksamkeit prüfen** Nach Umsetzung einer Maßnahme sollte geprüft werden: - Tritt der Incident erneut auf? - Sind ähnliche Incidents zurückgegangen? - Funktioniert der Workaround? - Hat Monitoring früher gewarnt? - Sind Tickets vollständiger? - Wurde die Eskalation schneller? - Hat sich die Benutzererfahrung verbessert? - Gab es neue Nebenwirkungen? Ursachenanalyse ist erst dann wirklich abgeschlossen, wenn die Verbesserung überprüft wurde oder ein verbleibendes Risiko bewusst akzeptiert ist. --- **RCA-Ergebnis dokumentieren** Eine Abschlussdokumentation kann enthalten: - Problemzusammenfassung, - betroffene Services, - Zeitraum, - Auswirkungen, - zugehörige Incidents, - erkannte Ursachen, - beitragende Faktoren, - durchgeführte Tests, - bestätigter Workaround, - dauerhafte Lösung, - offene Risiken, - Maßnahmen, - Verantwortliche, - Lessons Learned, - benötigte Changes, - aktualisierte Knowledge-Artikel. Die Dokumentation muss nicht übermäßig lang sein. Sie muss nachvollziehbar und nützlich sein. --- **Praxisbeispiel: Zertifikat abgelaufen** **Incident** Benutzer können sich nicht an einer Anwendung anmelden. **Direkte Ursache** Das Zertifikat des Anmeldedienstes ist abgelaufen. **Grundursache** Es gab keinen Prozess zur rechtzeitigen Zertifikatserneuerung. **Beitragende Faktoren** - kein Monitoring auf Zertifikatsablauf, - keine verantwortliche Rolle, - keine Erinnerungsfristen, - keine Dokumentation im Betriebshandbuch. **Maßnahmen** - Zertifikatsmonitoring einführen, - Owner festlegen, - Ablaufdatum in Wartungskalender aufnehmen, - Runbook zur Erneuerung erstellen, - Knowledge-Artikel für Symptome aktualisieren. --- **Praxisbeispiel: Speicher läuft voll** **Incident** Ein Dateiserver ist nicht mehr beschreibbar. **Workaround** Temporäre Dateien werden kontrolliert entfernt. **Ursachenanalyse** - Logdateien wachsen ungewöhnlich stark. - Logrotation greift nicht. - Monitoring warnt erst bei 98 Prozent. - Verantwortlicher erhält keine Benachrichtigung. **Maßnahmen** - Logrotation korrigieren, - Monitoringgrenzen anpassen, - Alarmempfänger aktualisieren, - Kapazitätsbericht ergänzen, - Runbook für Speicherwarnungen erstellen. --- **Praxisbeispiel: Wiederkehrende VPN-Abbrüche** **Problem** Mehrere Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung. **Fakten** - nur Windows-Notebooks betroffen, - nur Client-Version 5.8 betroffen, - Fehler tritt nach Ruhezustand auf, - Neustart des Clients hilft kurzfristig, - Hersteller bestätigt bekannten Fehler. **Known Error** Client-Version 5.8 verursacht nach Ruhezustand fehlerhafte Tunnelzustände. **Workaround** VPN-Client vollständig beenden und neu starten. **Dauerhafte Lösung** Test und Ausrollen einer korrigierten Client-Version über Change Enablement. --- **Typische Fehler** **Fehler 1** Symptom wird als Grundursache dokumentiert. --- **Fehler 2** Die erste Vermutung wird nicht mehr überprüft. --- **Fehler 3** Nur technische Ursachen werden betrachtet. --- **Fehler 4** Organisatorische und prozessuale Faktoren werden ignoriert. --- **Fehler 5** Zeitlicher Zusammenhang wird als Beweis behandelt. --- **Fehler 6** Mehrere Änderungen werden gleichzeitig getestet. --- **Fehler 7** RCA wird zur Schuldzuweisung verwendet. --- **Fehler 8** Workaround wird nicht dokumentiert. --- **Fehler 9** Maßnahmen werden beschlossen, aber nicht verfolgt. --- **Fehler 10** Lessons Learned werden nicht in Knowledge, Monitoring oder Prozesse übernommen. --- **Fehler 11** CMDB- und Serviceabhängigkeiten werden nicht genutzt. --- **Fehler 12** Wirksamkeit der Maßnahmen wird nicht geprüft. --- **Checkliste Ursachenanalyse starten** - [ ] Problem eindeutig beschrieben - [ ] betroffene Services bekannt - [ ] zugehörige Incidents verknüpft - [ ] Auswirkungen dokumentiert - [ ] Zeitlinie begonnen - [ ] relevante Changes geprüft - [ ] Monitoringdaten gesichert - [ ] Logs gesichert - [ ] Workaround bekannt oder gesucht - [ ] Verantwortlicher für Analyse benannt --- **Checkliste Ursachen untersuchen** - [ ] Symptome von Ursachen getrennt - [ ] Hypothesen dokumentiert - [ ] Hypothesen überprüfbar formuliert - [ ] Fakten und Vermutungen getrennt - [ ] Umfang geprüft - [ ] betroffene und nicht betroffene Bereiche verglichen - [ ] technische Ursachen geprüft - [ ] Prozessursachen geprüft - [ ] organisatorische Faktoren geprüft - [ ] menschliche Faktoren berücksichtigt - [ ] beitragende Faktoren dokumentiert --- **Checkliste Maßnahmen ableiten** - [ ] Workaround dokumentiert - [ ] Known Error bewertet - [ ] dauerhafte Lösung beschrieben - [ ] notwendiger Change geprüft - [ ] Risiken bewertet - [ ] Maßnahmen priorisiert - [ ] Verantwortliche benannt - [ ] Termine festgelegt - [ ] Knowledge-Artikel aktualisiert - [ ] Monitoring oder Runbook angepasst - [ ] Wirksamkeitsprüfung geplant --- **Bedeutung für Fachinformatiker für Systemintegration** Für Fachinformatiker ist Ursachenanalyse eine zentrale Fähigkeit. Im Arbeitsalltag bedeutet das: - nicht bei der ersten Vermutung stehen bleiben, - technische Beobachtungen sauber dokumentieren, - Logs und Messwerte sinnvoll auswerten, - Änderungen und Abhängigkeiten prüfen, - wiederkehrende Muster erkennen, - Workarounds nutzbar dokumentieren, - Risiken einschätzen, - und Verbesserungen anstoßen. Gute Ursachenanalyse macht Systeme nicht nur wieder lauffähig. Sie macht sie langfristig stabiler. --- **Zusammenfassung** > Symptom erkennen > ↓ > Problem beschreiben > ↓ > Fakten sammeln > ↓ > Zeitlinie und Umfang prüfen > ↓ > Hypothesen bilden > ↓ > Hypothesen testen > ↓ > technische, prozessuale und organisatorische Ursachen betrachten > ↓ > Workaround und Known Error dokumentieren > ↓ > dauerhafte Maßnahmen ableiten > ↓ > Wirksamkeit prüfen > ↓ > Wissen und Verbesserungen übernehmen --- **Merksätze** > Die erste Erklärung ist nicht immer die richtige Ursache. > Ein Symptom ist noch keine Grundursache. > Ursachenanalyse ist Lernen, nicht Schuldzuweisung. > Viele IT-Probleme haben technische und organisatorische Ursachen. > Workarounds helfen kurzfristig, ersetzen aber keine dauerhafte Lösung. > Eine RCA ist nur wertvoll, wenn daraus konkrete Verbesserungen entstehen. --- **Verwandte Seiten** - 4.1 Problem Management – Ziele, Begriffe und Abgrenzung - 4.3 Workarounds und Known Errors - 4.4 Trendanalyse und proaktives Problem Management - 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management - Incident Management - Change Enablement - Knowledge Management - Service Configuration Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - RCA-Methoden, - 5-Why-Beispiele, - Ishikawa-Kategorien, - Pareto-Beispiele, - Checklisten, - Ursachenarten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - RCA-Methode, - Anzahl von Analysefragen, - Diagrammform, - Review-Struktur, - Maßnahmenmatrix, - oder konkrete Dokumentationsvorlage für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - technische Umgebung, - Datenqualität, - Organisation, - Lieferanten, - Service Levels, - Sicherheitsanforderungen, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 4.3 Workarounds und Known Errors > **Kurz erklärt** > > Ein **Workaround** ist eine vorübergehende Möglichkeit, die Auswirkungen eines Incidents oder Problems zu umgehen oder zu reduzieren. > > Ein **Known Error** ist ein bekanntes Problem oder ein bekannter Fehlerzustand, bei dem Ursache, Zusammenhang oder Fehlerbild ausreichend verstanden sind. > > Workarounds und Known Errors helfen dabei, Incidents schneller zu bearbeiten, Benutzer arbeitsfähig zu halten und Wissen für den Service Desk nutzbar zu machen. --- **Warum Workarounds wichtig sind** Nicht jede Ursache kann sofort dauerhaft beseitigt werden. Gründe können sein: - dauerhafte Lösung benötigt einen Change, - Hersteller muss Fehler beheben, - Wartungsfenster ist erforderlich, - Risiko einer Sofortänderung ist zu hoch, - Ursache ist noch nicht vollständig verstanden, - Ersatzhardware ist nicht sofort verfügbar, - Freigaben fehlen, - oder eine technische Abhängigkeit muss zuerst geklärt werden. Ein Workaround kann in solchen Situationen helfen, die Auswirkungen zu begrenzen. Beispiele: - alternativer Drucker, - Webversion statt Desktop-Anwendung, - Neustart eines betroffenen Dienstes, - anderer Netzwerkzugang, - manuelle Ersatzbearbeitung, - temporäre Umleitung, - Nutzung eines Ersatzsystems. Ein Workaround ist nicht automatisch schlecht. Er wird problematisch, wenn er dauerhaft genutzt wird und die eigentliche Ursache nie bearbeitet wird. --- **Workaround und dauerhafte Lösung unterscheiden** | Workaround | Dauerhafte Lösung | |---|---| | reduziert oder umgeht Auswirkungen | beseitigt Ursache oder Risiko nachhaltig | | oft kurzfristig verfügbar | benötigt häufig Analyse, Planung oder Change | | kann Service schnell wieder nutzbar machen | verhindert Wiederholung besser | | Ursache kann bestehen bleiben | Ursache wird behoben oder kontrolliert | | muss dokumentiert und überwacht werden | muss getestet und dauerhaft übernommen werden | Beispiel: Ein VPN-Client verliert nach dem Ruhezustand die Verbindung. **Workaround** VPN-Client vollständig beenden und neu starten. **Dauerhafte Lösung** Fehlerhafte Client-Version aktualisieren oder Konfiguration korrigieren. --- **Was ist ein Known Error?** Ein Known Error ist ein Problem oder Fehlerzustand, der bekannt und ausreichend beschrieben ist. Typische Merkmale: - Fehlerbild ist bekannt, - betroffene Services oder Komponenten sind bekannt, - Ursache oder wahrscheinliche Ursache ist dokumentiert, - Auswirkungen sind beschrieben, - Workaround ist vorhanden oder geprüft, - dauerhafte Lösung ist geplant, offen oder bewusst zurückgestellt. Ein Known Error muss nicht bedeuten, dass bereits eine endgültige Lösung vorhanden ist. Gerade deshalb ist die Dokumentation wichtig. --- **Problem, Known Error, Workaround und Lösung unterscheiden** | Begriff | Bedeutung | |---|---| | **Problem** | Ursache oder mögliche Ursache eines oder mehrerer Incidents | | **Known Error** | bekanntes Problem oder bekannter Fehlerzustand mit dokumentiertem Wissen | | **Workaround** | vorübergehende Maßnahme zur Umgehung oder Reduzierung der Auswirkungen | | **dauerhafte Lösung** | Maßnahme zur Beseitigung der Ursache oder dauerhaften Risikoreduzierung | Beispiel: **Problem** Mehrere Benutzer verlieren regelmäßig die VPN-Verbindung. **Known Error** VPN-Client-Version 5.8 verursacht nach dem Ruhezustand fehlerhafte Tunnelzustände. **Workaround** VPN-Client vollständig beenden und neu starten. **Dauerhafte Lösung** Getestete Client-Version 5.9 über Change Enablement ausrollen. --- **Ein Workaround ist keine endgültige Lösung** Ein häufiger Fehler besteht darin, einen erfolgreichen Workaround als vollständige Lösung zu behandeln. Beispiel: Ein Dienst stürzt regelmäßig ab. Der Service Desk startet den Dienst jedes Mal neu. Dadurch ist der Service kurzfristig wieder verfügbar. Die Ursache bleibt jedoch bestehen. Mögliche offene Fragen: - Warum stürzt der Dienst ab? - Warum erkennt Monitoring den Fehler nicht früher? - Warum gibt es keinen automatischen Neustart? - Warum wurde die Ursache nicht untersucht? - Warum tritt der Fehler regelmäßig auf? > **Merke** > > Ein Workaround kann einen Incident lösen. > > Er löst aber nicht automatisch das zugrunde liegende Problem. --- **Anforderungen an einen guten Workaround** Ein guter Workaround sollte: - wirksam sein, - verständlich beschrieben sein, - reproduzierbar funktionieren, - sicher sein, - zulässig sein, - keine größeren Folgerisiken erzeugen, - für die Zielgruppe geeignet sein, - dokumentiert sein, - und regelmäßig überprüft werden. Zu prüfen ist außerdem: - Für welche Versionen gilt der Workaround? - Für welche Benutzer oder Services gilt er? - Welche Voraussetzungen bestehen? - Welche Einschränkungen bleiben? - Wie lange darf er genutzt werden? - Wann muss eskaliert werden? - Muss später eine Rücknahme erfolgen? --- **Ungeeignete Workarounds** Ein Workaround ist ungeeignet, wenn er: - Sicherheitsvorgaben umgeht, - Datenschutz verletzt, - Datenverlust riskieren kann, - unkontrollierte Änderungen verursacht, - nur zufällig funktioniert, - nicht dokumentiert ist, - Benutzer überfordert, - oder die Ursache verschlimmern kann. Beispiel: > Benutzer sollen vertrauliche Dokumente über private E-Mail-Konten austauschen, weil der Dateiserver nicht erreichbar ist. Das wäre technisch vielleicht möglich, aber organisatorisch und sicherheitlich ungeeignet. --- **Workaround dokumentieren** Ein Workaround sollte so dokumentiert sein, dass er wiederverwendbar ist. Typische Inhalte: - Titel, - betroffener Service, - Fehlerbild, - Voraussetzungen, - betroffene Versionen oder Komponenten, - genaue Arbeitsschritte, - erwartetes Ergebnis, - Einschränkungen, - Risiken, - Abbruchkriterien, - Eskalationshinweise, - Gültigkeitsdauer, - Verantwortlicher, - Bezug zu Problem Record oder Known Error. Eine ungenaue Notiz reicht nicht aus. Ungeeignet: > Client neu starten. Besser: > VPN-Client vollständig beenden, prüfen ob der Prozess beendet ist, Client neu starten und erneut verbinden. Gilt nur für Windows-Notebooks mit Client-Version 5.8 nach Ruhezustand. Wenn Verbindung weiterhin fehlschlägt, an Netzwerkteam eskalieren. --- **Known Error dokumentieren** Ein Known Error sollte mindestens enthalten: - bekannte Symptome, - betroffener Service, - betroffene Configuration Items, - betroffene Versionen, - Ursache oder wahrscheinliche Ursache, - Auswirkungen, - Workaround, - bekannte Einschränkungen, - dauerhafte Lösung oder geplanter Change, - Status, - Verantwortlicher, - Verknüpfung zu Incidents und Problems, - Datum der letzten Prüfung. Ziel ist, dass Service Desk und Fachgruppen schneller erkennen: - ob ein neuer Incident zu einem bekannten Fehler passt, - welcher Workaround genutzt werden kann, - wann eskaliert werden muss, - und ob eine dauerhafte Lösung geplant ist. --- **Known Error Database** Organisationen können bekannte Fehler in einer **Known Error Database** oder in einem vergleichbaren Wissenssystem dokumentieren. Das Werkzeug ist nicht entscheidend. Möglich sind beispielsweise: - ITSM-System, - Knowledge Base, - Wiki, - CMDB-Verknüpfung, - Problem-Management-Modul, - Runbook-Sammlung. Wichtig ist: - Informationen sind auffindbar, - Inhalte sind aktuell, - Zielgruppen sind klar, - Verknüpfungen zu Incidents und Problems sind vorhanden, - und Workarounds sind verständlich beschrieben. --- **Lebenszyklus eines Known Errors** Ein möglicher Ablauf: wiederkehrender Incident erkannt ↓ Problem Record erstellt ↓ Ursache oder Fehlerzustand analysiert ↓ Known Error dokumentiert ↓ Workaround bereitgestellt ↓ dauerhafte Lösung geplant ↓ Change umgesetzt ↓ Wirksamkeit geprüft ↓ Known Error aktualisiert oder geschlossen Nicht jeder Known Error folgt exakt diesem Ablauf. Entscheidend ist, dass der Status nachvollziehbar bleibt. --- **Known Error offen lassen oder schließen** Ein Known Error sollte nicht einfach vergessen werden. Mögliche Status: - neu, - in Analyse, - Workaround verfügbar, - dauerhafte Lösung geplant, - Change in Vorbereitung, - Lösung umgesetzt, - Wirksamkeit wird geprüft, - geschlossen, - Risiko akzeptiert. Ein Known Error kann offen bleiben, wenn: - dauerhafte Lösung noch nicht verfügbar ist, - Herstellerkorrektur aussteht, - Änderung zu riskant wäre, - Kosten unverhältnismäßig wären, - oder Risiko bewusst akzeptiert wurde. Dann müssen Workaround und Risiko weiterhin bekannt bleiben. --- **Workaround im Incident Management** Incident Management nutzt Workarounds, um den Service schnell wiederherzustellen. Beispiele: - Service Desk nutzt Known Error und Workaround, - Benutzer erhält eine sichere Zwischenlösung, - Incident wird mit Bezug zum Known Error dokumentiert, - Problem Management verfolgt die Ursache weiter. Wichtig: Der Incident kann abgeschlossen werden, wenn der Benutzer wieder arbeitsfähig ist und die Organisation dies so definiert. Das Problem kann trotzdem offen bleiben. --- **Workaround im Problem Management** Problem Management verwendet Workarounds, um Auswirkungen zu reduzieren, während die Ursache weiter untersucht wird. Aufgaben: - Workaround prüfen, - Risiken bewerten, - Dokumentation erstellen, - Service Desk informieren, - Known Error anlegen, - dauerhafte Lösung vorbereiten, - Change-Bedarf klären, - Wirksamkeit überwachen. Ein Workaround ist oft ein wichtiger Zwischenschritt zwischen Analyse und dauerhafter Lösung. --- **Workaround und Change Enablement** Ein Workaround kann selbst eine Änderung enthalten. Beispiele: - DNS-Eintrag temporär ändern, - Dienst auf Ersatzsystem umleiten, - Firewall-Regel vorübergehend anpassen, - Konfiguration zurücksetzen, - Zertifikat austauschen, - Softwareversion zurückrollen. Solche Maßnahmen müssen nach Risiko bewertet werden. Nicht jeder Workaround darf ohne Change-Steuerung durchgeführt werden. Die Organisation muss festlegen, welche Workarounds: - als Standardmaßnahme erlaubt sind, - eine Genehmigung benötigen, - nur im Notfall zulässig sind, - oder über einen Emergency Change laufen müssen. --- **Workaround und Knowledge Management** Workarounds sind nur dann wertvoll, wenn sie gefunden und verstanden werden. Deshalb sollten sie in Knowledge Management eingebunden werden. Zu klären ist: - Wer darf den Artikel sehen? - Ist der Artikel für Benutzer oder nur für IT? - Welche Begriffe nutzen Benutzer bei der Suche? - Muss es eine Kurzversion für den Service Desk geben? - Gibt es Sicherheits- oder Datenschutzhinweise? - Wann wird der Artikel überprüft? - Wer ist für Aktualisierung verantwortlich? Ein Workaround, der nur in einem alten Ticket steht, hilft beim nächsten Incident kaum. --- **Workaround und Service Desk** Der Service Desk benötigt klare Informationen: - Wann passt dieser Workaround? - Wann passt er nicht? - Welche Fragen müssen gestellt werden? - Welche Schritte sind erlaubt? - Welche Risiken bestehen? - Wann muss eskaliert werden? - Wie wird der Incident dokumentiert? - Welche Benutzerinformation ist freigegeben? Beispiel: > Wenn Benutzer nach Ruhezustand keine VPN-Verbindung herstellen können und Client-Version 5.8 verwendet wird, Workaround aus Artikel KB-023 anwenden. Bei anderer Version oder Fehlermeldung an Netzwerkteam eskalieren. --- **Workaround und Benutzerkommunikation** Benutzer sollten verständlich informiert werden. Wichtig ist: - klar sagen, dass es eine Zwischenlösung ist, - keine unsicheren technischen Vermutungen als Ursache darstellen, - Einschränkungen nennen, - nächsten Schritt erklären, - bei Bedarf Statusmeldung ankündigen. Beispiel: > Für diesen Fehler gibt es aktuell eine sichere Zwischenlösung. Bitte starten Sie den VPN-Client vollständig neu und verbinden Sie sich anschließend erneut. Die Ursache wird weiter untersucht. Eine dauerhafte Korrektur ist in Vorbereitung. Ungeeignet: > Das ist ein bekannter Bug, machen Sie einfach Neustart. --- **Risiken dauerhaft genutzter Workarounds** Wenn Workarounds dauerhaft genutzt werden, entstehen Risiken: - Ursache bleibt bestehen, - Benutzer gewöhnen sich an Umwege, - manuelle Fehler nehmen zu, - Supportaufwand bleibt hoch, - Sicherheitsrisiken werden akzeptiert, - technische Schulden wachsen, - und echte Verbesserungen werden verschoben. Ein Workaround sollte deshalb regelmäßig überprüft werden. Fragen: - Wird der Workaround noch gebraucht? - Gibt es inzwischen eine dauerhafte Lösung? - Wie oft wird er genutzt? - Welche Risiken bestehen? - Gibt es Beschwerden? - Ist ein Change geplant? - Wurde Risiko bewusst akzeptiert? --- **Known Error und Risikoakzeptanz** Nicht jeder Known Error wird sofort beseitigt. Beispiel: Ein selten auftretender Fehler betrifft eine alte Anwendung. Der Workaround funktioniert zuverlässig. Eine dauerhafte Lösung wäre sehr teuer und riskant. Die Organisation kann entscheiden, das Risiko vorerst zu akzeptieren. Dann sollte dokumentiert werden: - wer das Risiko akzeptiert, - warum es akzeptiert wird, - welche Einschränkungen bestehen, - wie lange die Akzeptanz gilt, - wann neu bewertet wird, - und welcher Workaround genutzt wird. --- **Known Error bei Lieferantenfehlern** Ein Known Error kann auch durch einen Hersteller oder Lieferanten bestätigt werden. Beispiele: - Software-Bug, - Firmwarefehler, - Cloud-Service-Problem, - Treiberproblem, - API-Verhalten, - Inkompatibilität. Zu dokumentieren ist: - Herstellerreferenz, - betroffene Version, - bestätigte Symptome, - empfohlener Workaround, - erwartete Korrektur, - Lieferantenticket, - interne Auswirkungen, - geplanter interner Umgang. Auch wenn ein Lieferant verantwortlich ist, bleibt die interne Serviceverantwortung bestehen. --- **Known Error und Major Incident** Nach einem Major Incident kann ein Known Error entstehen. Beispiel: Ein zentraler Dienst fällt wegen einer bestimmten Datenbankversion aus. Der Service wurde wiederhergestellt. Die dauerhafte Korrektur benötigt aber ein geplantes Upgrade. Bis dahin wird ein Known Error dokumentiert mit: - Symptomen, - betroffenen Services, - Workaround, - Monitoringhinweisen, - Eskalationsregeln, - geplanter dauerhafter Lösung. Dadurch kann bei Wiederholung schneller reagiert werden. --- **Beispiel: VPN-Client** **Symptom** Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung. **Problem** Mehrere Incidents mit gleichem Muster. **Known Error** VPN-Client-Version 5.8 verursacht nach Ruhezustand fehlerhafte Tunnelzustände. **Workaround** Client vollständig beenden und neu starten. **Dauerhafte Lösung** Version 5.9 testen und ausrollen. **Knowledge** Service Desk erhält einen Artikel mit Prüfschritten, Workaround und Eskalationskriterien. --- **Beispiel: Druckerwarteschlange** **Symptom** Etiketten werden nicht gedruckt. **Problem** Druckwarteschlange blockiert regelmäßig durch bestimmte PDF-Dateien. **Known Error** Der aktuell installierte Druckertreiber verarbeitet bestimmte PDF-Formate fehlerhaft. **Workaround** Fehlerhaften Auftrag entfernen und Datei über alternative Druckoption ausgeben. **Dauerhafte Lösung** Treiberupdate testen und über Change Enablement ausrollen. --- **Beispiel: Zertifikat** **Symptom** Anmeldung an Fachanwendung schlägt fehl. **Problem** Zertifikat des Anmeldedienstes ist abgelaufen. **Known Error** Zertifikatsablauf wird nicht überwacht und kann zu Anmeldeausfällen führen. **Workaround** Kein vollwertiger Workaround verfügbar. **Dauerhafte Lösung** Zertifikat erneuern, Monitoring einführen, Owner festlegen und Runbook erstellen. > **Merke** > > Nicht jeder Known Error besitzt einen geeigneten Workaround. --- **Beispiel: Speicher läuft voll** **Symptom** Server kann keine neuen Daten schreiben. **Problem** Logdateien wachsen unkontrolliert. **Known Error** Logrotation ist fehlerhaft konfiguriert. **Workaround** Temporäre Bereinigung nach Runbook durchführen. **Dauerhafte Lösung** Logrotation korrigieren, Monitoring-Grenzen anpassen und Verantwortlichkeit festlegen. --- **Typische Fehler** **Fehler 1** Workaround wird als dauerhafte Lösung behandelt. --- **Fehler 2** Known Error wird nicht dokumentiert. --- **Fehler 3** Workaround steht nur in einem einzelnen Ticket. --- **Fehler 4** Service Desk kennt den Workaround nicht. --- **Fehler 5** Benutzer erhalten unsichere oder unklare Anweisungen. --- **Fehler 6** Workaround umgeht Sicherheitsregeln. --- **Fehler 7** Risiken und Einschränkungen werden nicht genannt. --- **Fehler 8** Known Errors bleiben dauerhaft offen, ohne Neubewertung. --- **Fehler 9** Dauerhafte Lösung wird nicht geplant oder verfolgt. --- **Fehler 10** Lieferantenfehler werden nicht intern dokumentiert. --- **Fehler 11** Workaround wird nicht getestet. --- **Fehler 12** Nach Umsetzung der dauerhaften Lösung wird der Knowledge-Artikel nicht aktualisiert. --- **Checkliste Workaround erstellen** - [ ] Fehlerbild eindeutig beschrieben - [ ] betroffener Service genannt - [ ] Voraussetzungen dokumentiert - [ ] genaue Schritte beschrieben - [ ] erwartetes Ergebnis beschrieben - [ ] Risiken bewertet - [ ] Einschränkungen genannt - [ ] Abbruchkriterien definiert - [ ] Eskalationsweg beschrieben - [ ] Zielgruppe festgelegt - [ ] Verantwortlicher benannt - [ ] regelmäßige Prüfung vorgesehen --- **Checkliste Known Error dokumentieren** - [ ] Problem oder Fehlerzustand beschrieben - [ ] betroffene Services und Komponenten genannt - [ ] bekannte Symptome dokumentiert - [ ] Ursache oder wahrscheinliche Ursache beschrieben - [ ] Auswirkungen bewertet - [ ] zugehörige Incidents verknüpft - [ ] Workaround vorhanden oder als nicht verfügbar gekennzeichnet - [ ] dauerhafte Lösung oder nächster Schritt dokumentiert - [ ] Status festgelegt - [ ] Verantwortlicher benannt - [ ] Knowledge-Artikel oder Runbook verknüpft - [ ] Datum der nächsten Überprüfung festgelegt --- **Checkliste Workaround im Betrieb nutzen** - [ ] passt das aktuelle Symptom zum Known Error? - [ ] sind Version, Service oder Komponente betroffen? - [ ] ist der Workaround für diesen Fall zulässig? - [ ] wurden Risiken geprüft? - [ ] wurde der Benutzer verständlich informiert? - [ ] wurde die Anwendung dokumentiert? - [ ] muss funktional eskaliert werden? - [ ] muss Problem Management informiert werden? - [ ] ist eine dauerhafte Lösung geplant? - [ ] wurde die Wirksamkeit bestätigt? --- **Checkliste Known Error schließen** - [ ] dauerhafte Lösung umgesetzt - [ ] Wirksamkeit geprüft - [ ] zugehörige Incidents berücksichtigt - [ ] Knowledge-Artikel aktualisiert - [ ] Workaround entfernt oder angepasst - [ ] Monitoring oder Runbook aktualisiert - [ ] Rest Risiko bewertet - [ ] Stakeholder informiert - [ ] Problem Record aktualisiert - [ ] Lessons Learned dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Für Fachinformatiker ist der saubere Umgang mit Workarounds und Known Errors besonders wichtig. Im Arbeitsalltag bedeutet das: - wiederkehrende Fehler erkennen, - wirksame Zwischenlösungen sauber dokumentieren, - Risiken eines Workarounds bewerten, - bekannte Fehler für den Service Desk nutzbar machen, - dauerhafte Lösungen vorbereiten, - Changes fachlich unterstützen, - und Knowledge-Artikel aktuell halten. Ein guter Workaround spart Zeit. Ein gut dokumentierter Known Error verhindert doppelte Analyse. Eine dauerhafte Lösung verbessert den Service nachhaltig. --- **Zusammenfassung** > Incident oder wiederkehrendes Fehlerbild erkennen > ↓ > Problem oder mögliche Ursache untersuchen > ↓ > Known Error dokumentieren > ↓ > sicheren Workaround bereitstellen > ↓ > Service Desk und Benutzer angemessen informieren > ↓ > dauerhafte Lösung planen > ↓ > Change bei Bedarf durchführen > ↓ > Wirksamkeit prüfen > ↓ > Known Error und Knowledge aktualisieren oder schließen --- **Merksätze** > Ein Workaround ist hilfreich, aber nicht automatisch eine Lösung. > Ein Known Error muss auffindbar und verständlich dokumentiert sein. > Nicht jeder Known Error besitzt einen sicheren Workaround. > Workarounds dürfen Sicherheitsregeln nicht aushebeln. > Dauerhaft genutzte Workarounds sind ein Hinweis auf ungelöste Probleme. > Gute Known-Error-Dokumentation macht zukünftige Incidents schneller lösbar. --- **Verwandte Seiten** - 4.1 Problem Management – Ziele, Begriffe und Abgrenzung - 4.2 Ursachenanalyse - 4.4 Trendanalyse und proaktives Problem Management - 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - Knowledge Management - Change Enablement - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Workaround-Beispiele, - Known-Error-Strukturen, - Checklisten, - Statusmodelle, - Dokumentationshinweise, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Known-Error-Datenbank-Struktur, - Workaround-Vorlage, - Statusliste, - Dokumentationstiefe, - Freigaberegel, - oder Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Sicherheitsanforderungen, - Supportmodell, - Knowledge Management, - Change Enablement, - Lieferanten, - und organisatorische Verantwortlichkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 4.4 Trendanalyse und proaktives Problem Management > **Kurz erklärt** > > Trendanalyse und proaktives Problem Management helfen dabei, wiederkehrende Muster frühzeitig zu erkennen. > > Ziel ist es, Problems nicht erst nach großen Störungen zu bearbeiten, sondern mögliche Ursachen und Risiken bereits vorher sichtbar zu machen. > > Dadurch können Incidents reduziert, Auswirkungen begrenzt und Services langfristig stabiler betrieben werden. --- **Warum Trendanalyse wichtig ist** Ein einzelner Incident wirkt oft wie ein isolierter Fehler. Erst durch die Betrachtung vieler Vorgänge wird sichtbar, ob ein Muster besteht. Beispiele: - VPN-Störungen nehmen jede Woche zu. - Druckerprobleme treten immer am gleichen Standort auf. - Anmeldefehler häufen sich nach Passwortänderungen. - Speicherwarnungen treten regelmäßig vor Monatsende auf. - Eine Anwendung wird nach jedem Update instabil. - Ein bestimmter Service erzeugt überdurchschnittlich viele Tickets. Trendanalyse hilft dabei, solche Muster zu erkennen und daraus Verbesserungen abzuleiten. --- **Reaktives und proaktives Problem Management unterscheiden** | Reaktives Problem Management | Proaktives Problem Management | |---|---| | beginnt nach Incidents | sucht nach Risiken und Mustern vor größeren Incidents | | reagiert auf Störungen | verhindert oder reduziert zukünftige Störungen | | nutzt Incident-Daten nach einem Ereignis | nutzt Trends, Monitoring, Reviews und Erfahrungswerte | | häufig nach Major Incidents | häufig durch regelmäßige Analyse | | Ziel: Ursache verstehen | Ziel: Risiken frühzeitig erkennen | Beide Formen sind wichtig. Reaktives Problem Management lernt aus bereits eingetretenen Incidents. Proaktives Problem Management versucht, zukünftige Incidents zu vermeiden. --- **Was ist eine Trendanalyse?** Trendanalyse bedeutet, Daten über einen Zeitraum zu betrachten und Muster zu erkennen. Mögliche Fragen: - Welche Incidents treten besonders häufig auf? - Welche Services sind überdurchschnittlich betroffen? - Welche Standorte melden ähnliche Probleme? - Welche Zeiträume sind auffällig? - Welche Changes stehen zeitlich mit Incidents in Verbindung? - Welche Kategorien wachsen stark an? - Welche Workarounds werden häufig genutzt? - Welche Teams erhalten besonders viele Eskalationen? - Welche Fehler kehren trotz Lösung wieder? Eine Trendanalyse betrachtet nicht nur einzelne Tickets, sondern Zusammenhänge. --- **Mögliche Datenquellen** Geeignete Quellen für Trendanalysen: - Incident Records, - Problem Records, - Known Errors, - Change Records, - Monitoringdaten, - Logdaten, - Service-Desk-Kontakte, - Benutzerfeedback, - SLA-Berichte, - Major-Incident-Reviews, - Service Reviews, - Knowledge-Base-Nutzung, - Self-Service-Daten, - CMDB-Informationen, - Lieferantenberichte, - Sicherheitsmeldungen. Je besser die Datenqualität, desto aussagekräftiger die Analyse. --- **Typische Muster** | Muster | Mögliche Bedeutung | |---|---| | viele gleiche Incidents | wiederkehrendes Problem | | steigende Ticketzahlen | wachsendes Risiko oder schlechter Service | | gleiche Symptome nach Changes | mögliche Change-Ursache | | hohe Wiedereröffnungsquote | unvollständige Lösung | | viele Eskalationen an ein Team | fehlendes Wissen im Service Desk | | häufige Workarounds | dauerhafte Ursache nicht beseitigt | | viele Suchanfragen ohne Treffer | fehlende Knowledge-Artikel | | häufige Störung an einem Standort | lokales Infrastrukturproblem | | wiederkehrende Speicherwarnungen | Kapazitäts- oder Monitoringproblem | --- **Trendanalyse im Service Desk** Der Service Desk ist eine besonders wichtige Quelle für Trends. Dort entstehen täglich Informationen über: - häufige Benutzerprobleme, - unklare Services, - wiederkehrende Fehler, - schlechte Formulare, - unverständliche Knowledge-Artikel, - fehlende Standardlösungen, - unklare Zuständigkeiten, - und wiederholte Eskalationen. Wenn diese Informationen nur in einzelnen Tickets bleiben, gehen wichtige Verbesserungsmöglichkeiten verloren. --- **Zeitliche Muster erkennen** Incidents können sich zeitlich häufen. Beispiele: - viele Anmeldeprobleme am Montagmorgen, - Druckerprobleme zum Schichtbeginn, - Performance-Probleme am Monatsende, - Speicherwarnungen nach nächtlichen Jobs, - Backupfehler nach Wartungsfenstern, - erhöhte Ticketzahlen nach Updates. Solche Muster helfen bei der Ursachenfindung. Beispiel: Wenn ein Speicherbereich jeden Montagmorgen voll ist, kann ein Wochenendjob oder eine fehlende Bereinigung beteiligt sein. --- **Servicebezogene Muster erkennen** Zu prüfen ist: - Welche Services erzeugen die meisten Incidents? - Welche Services verursachen die längsten Ausfälle? - Welche Services haben die meisten Wiedereröffnungen? - Welche Services benötigen häufig Eskalation? - Welche Services haben viele Benutzerbeschwerden? - Welche Services besitzen viele Known Errors? Ein Service mit wenigen, aber sehr kritischen Incidents kann wichtiger sein als ein Service mit vielen kleinen Standardanfragen. --- **Standortbezogene Muster erkennen** Standortbezogene Trends können Hinweise liefern auf: - Netzwerkprobleme, - WLAN-Abdeckung, - lokale Druckinfrastruktur, - defekte Hardware, - unzureichende Schulung, - lokale Prozesse, - Providerprobleme, - oder Standortbesonderheiten. Beispiel: Wenn nur ein Standort häufig VPN-Abbrüche meldet, muss nicht der VPN-Service selbst die Hauptursache sein. Möglicherweise liegt das Problem bei lokaler Internetanbindung, Firewall, WLAN oder Routing. --- **Benutzergruppen und Rollen betrachten** Manchmal treten Incidents vor allem bei bestimmten Benutzergruppen auf. Beispiele: - Außendienst meldet häufig VPN- und Mobilgeräteprobleme. - Buchhaltung meldet wiederkehrende Druck- und Exportfehler. - Lager meldet Probleme mit Scanner- oder Etikettendruck. - neue Mitarbeiter melden viele Zugriffsprobleme. - Führungskräfte melden häufig Kalender- und Freigabethemen. Solche Muster können auf fehlende Schulung, unklare Prozesse oder technische Sonderanforderungen hinweisen. --- **Change-bezogene Muster erkennen** Viele Problems entstehen im Zusammenhang mit Änderungen. Zu prüfen ist: - Häufen sich Incidents nach bestimmten Changes? - Sind bestimmte Change-Typen besonders fehleranfällig? - Treten Fehler nach Softwareupdates auf? - Sind Rollbacks häufig notwendig? - Werden Standard-Changes falsch genutzt? - Werden Tests vor Changes ausreichend durchgeführt? - Sind betroffene Services nach Changes korrekt überwacht? Trenddaten können zeigen, ob Change Enablement verbessert werden muss. --- **Monitoringdaten proaktiv nutzen** Monitoring zeigt nicht nur akute Störungen. Es kann auch zukünftige Risiken sichtbar machen. Beispiele: - Speicher wächst kontinuierlich. - Antwortzeiten steigen über Wochen. - Fehlerquote nimmt langsam zu. - CPU-Auslastung ist regelmäßig nahe am Limit. - Zertifikate laufen bald ab. - Backupdauer überschreitet zunehmend das Zeitfenster. - Datenbankverbindungen nähern sich der Obergrenze. - Warteschlangen werden länger. Solche Signale können ein Problem anzeigen, bevor Benutzer betroffen sind. --- **Kapazitätstrends** Kapazitätstrends helfen zu erkennen, ob Ressourcen bald nicht mehr ausreichen. Zu betrachten sind: - Speicherplatz, - CPU, - Arbeitsspeicher, - Netzwerkbandbreite, - Datenbankgröße, - Anzahl gleichzeitiger Sitzungen, - Lizenzverbrauch, - Backupfenster, - Cloud-Kosten, - API-Limits. Beispiel: Wenn ein Dateiserver jeden Monat um 12 Prozent wächst, kann bereits vor einem Ausfall geplant werden, wie Kapazität erweitert oder Daten bereinigt werden. --- **Known Errors auswerten** Known Errors sollten regelmäßig überprüft werden. Fragen: - Wie oft tritt der Known Error noch auf? - Wie viele Incidents sind damit verbunden? - Funktioniert der Workaround zuverlässig? - Gibt es inzwischen eine dauerhafte Lösung? - Ist das Risiko noch akzeptabel? - Sind Knowledge-Artikel aktuell? - Muss ein Change priorisiert werden? - Gibt es neue betroffene Versionen oder Services? Ein Known Error darf nicht dauerhaft unbeachtet bleiben. --- **Workaround-Nutzung als Warnsignal** Wenn ein Workaround sehr häufig genutzt wird, ist das ein Hinweis auf ein ungelöstes Problem. Beispiel: Der Service Desk startet jede Woche denselben Dienst neu. Der Workaround funktioniert kurzfristig. Trotzdem zeigt die Häufigkeit, dass eine dauerhafte Lösung notwendig ist. Zu prüfen ist: - Wie oft wird der Workaround genutzt? - Welche Benutzer sind betroffen? - Wie viel Arbeitszeit kostet er? - Welche Risiken entstehen? - Welche dauerhafte Lösung wäre möglich? - Warum wurde sie bisher nicht umgesetzt? --- **Knowledge-Base-Daten nutzen** Die Knowledge Base liefert Hinweise auf wiederkehrende Themen. Mögliche Signale: - bestimmte Artikel werden sehr häufig aufgerufen, - Benutzer bewerten Artikel als nicht hilfreich, - viele Suchanfragen führen zu keinem Treffer, - Service Desk nutzt immer denselben Artikel, - Artikel werden nach Updates schnell veraltet, - bestimmte Themen erzeugen trotz Artikel weiterhin viele Tickets. Daraus können Verbesserungen entstehen: - Artikel überarbeiten, - neue Artikel erstellen, - Self-Service verbessern, - Formulare anpassen, - oder technische Ursache untersuchen. --- **Benutzerfeedback auswerten** Benutzerfeedback kann Trends sichtbar machen, die in technischen Daten nicht sofort erkennbar sind. Beispiele: - Anwendung ist langsam, aber Monitoring zeigt keinen Ausfall. - Portal ist unverständlich, obwohl Requests formal korrekt erstellt werden. - Benutzer nutzen E-Mail statt Self-Service, weil sie den Service nicht finden. - Workaround funktioniert technisch, ist aber im Alltag zu umständlich. - Statusmeldungen kommen zu spät oder sind unverständlich. Qualitative Rückmeldungen ergänzen Kennzahlen. --- **Lieferanteninformationen einbeziehen** Auch Lieferanten können wichtige Hinweise liefern. Beispiele: - bekannte Softwarefehler, - Firmwareprobleme, - Sicherheitswarnungen, - Cloud-Service-Störungen, - Versionshinweise, - End-of-Life-Ankündigungen, - Supportfälle anderer Kunden, - Roadmap-Informationen. Ein wiederkehrender interner Incident kann mit einem bekannten Herstellerfehler zusammenhängen. --- **Sicherheitsmeldungen als Problem-Auslöser** Nicht jede Sicherheitsmeldung ist ein Incident. Manche Sicherheitsmeldungen weisen auf ein Problem oder Risiko hin. Beispiele: - wiederholte fehlgeschlagene Anmeldeversuche, - veraltete Softwareversionen, - unsichere Standardkonfiguration, - fehlende Patches, - schwache Berechtigungsprozesse, - wiederkehrende Phishing-Erfolge, - nicht inventarisierte Geräte. Proaktives Problem Management kann helfen, solche Risiken strukturiert zu bearbeiten. --- **Trend, Problem und Verbesserung verbinden** Ein Trend allein ist noch keine Lösung. Ein sinnvoller Ablauf: Daten sammeln ↓ Muster erkennen ↓ Trend bewerten ↓ Problem Record erstellen ↓ Ursache oder Risiko untersuchen ↓ Workaround oder Schutzmaßnahme bereitstellen ↓ dauerhafte Verbesserung planen ↓ Wirkung messen Dadurch wird aus Beobachtung eine steuerbare Verbesserung. --- **Wann aus einem Trend ein Problem Record entsteht** Ein Problem Record kann sinnvoll sein, wenn: - ein Trend wiederholt auftritt, - viele Benutzer betroffen sind, - ein kritischer Service betroffen ist, - die Ursache unbekannt ist, - ein Workaround häufig verwendet wird, - ein Risiko steigt, - Kosten oder Aufwand deutlich zunehmen, - Sicherheitsrelevanz besteht, - oder eine dauerhafte Verbesserung notwendig erscheint. Nicht jede Auffälligkeit benötigt sofort einen Problem Record. Aber wichtige Trends sollten nicht verloren gehen. --- **Priorisierung proaktiver Problems** Proaktive Problems konkurrieren mit anderen Aufgaben. Kriterien zur Priorisierung: - geschäftliche Auswirkung, - Anzahl betroffener Benutzer, - Kritikalität des Service, - Risiko eines zukünftigen Incidents, - Sicherheitsrelevanz, - Häufigkeit, - Kosten, - Aufwand, - Verfügbarkeit eines Workarounds, - erwarteter Nutzen, - Abhängigkeit von Changes oder Lieferanten. Ein Problem ohne aktuellen Ausfall kann trotzdem hohe Priorität besitzen, wenn ein schwerer Ausfall absehbar ist. --- **Beispiel: Speichertrend** **Beobachtung** Monitoring zeigt, dass ein Dateiserver jeden Monat stark wächst. **Trend** Bei gleicher Entwicklung ist der Speicher in sechs Wochen voll. **Proaktives Problem Management** - Ursache des Wachstums prüfen, - Datenarten analysieren, - Verantwortliche identifizieren, - Bereinigungsregeln bewerten, - Kapazitätserweiterung prüfen, - Monitoring-Grenzen anpassen, - Runbook erstellen. **Nutzen** Ein zukünftiger Ausfall wird verhindert. --- **Beispiel: Häufige Passwort- und MFA-Tickets** **Beobachtung** Ein großer Anteil der Service-Desk-Kontakte betrifft Passwort und MFA. **Analyse** Viele Benutzer kennen den Self-Service-Passwort-Reset nicht. MFA-Anleitungen sind veraltet. **Verbesserung** - Knowledge-Artikel aktualisieren, - Portalhinweise verbessern, - Self-Service sichtbarer machen, - Onboarding-Unterlagen ergänzen, - häufige Fehler im Formular erklären. **Nutzen** Weniger Standardkontakte und schnellere Hilfe für Benutzer. --- **Beispiel: VPN-Incidents nach Clientupdate** **Beobachtung** Nach einem Clientupdate steigen VPN-Incidents deutlich an. **Analyse** Betroffen sind nur Windows-Notebooks mit einer bestimmten Version. **Problem Record** Ein Problem wird eröffnet, um Ursache, Workaround und dauerhafte Lösung zu verfolgen. **Maßnahmen** - Known Error dokumentieren, - Workaround bereitstellen, - Herstellerhinweis prüfen, - neue Version testen, - Rollout über Change Enablement planen. --- **Beispiel: Eskalationen an Netzwerkteam steigen** **Beobachtung** Immer mehr Tickets werden vom Service Desk an das Netzwerkteam eskaliert. **Analyse** Viele Eskalationen betreffen einfache DNS- und VPN-Prüfungen. **Verbesserung** - Runbook für Erstdiagnose erstellen, - Service Desk schulen, - Knowledge-Artikel ergänzen, - Diagnosewerkzeug bereitstellen, - Eskalationskriterien präzisieren. **Nutzen** Weniger unnötige Eskalationen und schnellere Bearbeitung. --- **Typische Fehler** **Fehler 1** Trends werden nicht ausgewertet, obwohl Daten vorhanden sind. --- **Fehler 2** Einzelne Incidents werden gelöst, aber Muster bleiben unbeachtet. --- **Fehler 3** Nur technische Kennzahlen werden betrachtet. --- **Fehler 4** Benutzerfeedback wird ignoriert. --- **Fehler 5** Monitoring wird nur für Alarmierung genutzt, nicht für proaktive Analyse. --- **Fehler 6** Known Errors bleiben offen, ohne Häufigkeit und Risiko neu zu bewerten. --- **Fehler 7** Trends werden erkannt, aber keine Maßnahmen abgeleitet. --- **Fehler 8** Proaktive Problems werden immer niedriger priorisiert als akute Tickets. --- **Fehler 9** Datenqualität ist schlecht, wird aber nicht verbessert. --- **Fehler 10** Verbesserungsmaßnahmen werden nicht auf Wirksamkeit geprüft. --- **Fehler 11** Lieferantenhinweise und bekannte Herstellerfehler werden nicht berücksichtigt. --- **Fehler 12** Trendanalysen werden nur einmalig durchgeführt statt regelmäßig. --- **Checkliste Trendanalyse** - [ ] relevante Datenquellen festgelegt - [ ] Zeitraum definiert - [ ] Incidents nach Service ausgewertet - [ ] Incidents nach Kategorie ausgewertet - [ ] Standorte und Benutzergruppen betrachtet - [ ] Wiederholungen erkannt - [ ] Changes zeitlich verglichen - [ ] Monitoringdaten berücksichtigt - [ ] Known Errors ausgewertet - [ ] Workaround-Nutzung geprüft - [ ] Benutzerfeedback berücksichtigt - [ ] auffällige Trends dokumentiert --- **Checkliste proaktives Problem Management** - [ ] Trend oder Risiko beschrieben - [ ] betroffener Service bekannt - [ ] mögliche Auswirkungen bewertet - [ ] Priorität festgelegt - [ ] Problem Record bei Bedarf erstellt - [ ] Verantwortlicher benannt - [ ] Daten und Fakten gesammelt - [ ] Hypothesen formuliert - [ ] Workaround oder Schutzmaßnahme geprüft - [ ] dauerhafte Lösung bewertet - [ ] Change-Bedarf geprüft - [ ] Verbesserung verfolgt - [ ] Wirksamkeit geprüft --- **Checkliste Datenqualität** - [ ] Tickets enthalten betroffenen Service - [ ] Kategorien werden einheitlich verwendet - [ ] Prioritäten sind begründet - [ ] Workarounds sind dokumentiert - [ ] Changes sind nachvollziehbar verknüpft - [ ] Monitoringdaten sind verfügbar - [ ] Zeitstempel sind korrekt - [ ] CMDB-Informationen sind ausreichend aktuell - [ ] Known Errors sind auffindbar - [ ] Abschlussnotizen sind verständlich --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker erkennen Trends häufig direkt im technischen Alltag. Beispiele: - gleiche Fehlermeldung taucht immer wieder auf, - derselbe Server erzeugt regelmäßig Warnungen, - bestimmte Geräteklasse verursacht viele Tickets, - ein Workaround wird ständig wiederholt, - ein Monitoringwert verschlechtert sich langsam, - oder ein Standort meldet auffällig viele Netzwerkprobleme. Wichtig ist, solche Beobachtungen nicht nur mündlich weiterzugeben, sondern nachvollziehbar zu dokumentieren. So können daraus Problems, Known Errors, Changes oder Verbesserungen entstehen. --- **Zusammenfassung** > Incidents, Monitoring und Feedback auswerten > ↓ > Muster und Trends erkennen > ↓ > Risiko und Auswirkung bewerten > ↓ > Problem Record bei Bedarf erstellen > ↓ > Ursache oder mögliche Ursache untersuchen > ↓ > Workaround oder Schutzmaßnahme bereitstellen > ↓ > dauerhafte Verbesserung planen > ↓ > Change, Knowledge oder Continual Improvement einbinden > ↓ > Wirkung messen und Datenqualität verbessern --- **Merksätze** > Trends zeigen, wo wiederkehrende Ursachen verborgen sein können. > Proaktives Problem Management beginnt, bevor der große Ausfall eintritt. > Monitoring ist nicht nur Alarmierung, sondern auch Frühwarnsystem. > Häufig genutzte Workarounds sind ein Hinweis auf ungelöste Problems. > Gute Datenqualität ist die Grundlage guter Trendanalyse. > Ein erkannter Trend ist erst wertvoll, wenn daraus eine konkrete Verbesserung entsteht. --- **Verwandte Seiten** - 4.1 Problem Management – Ziele, Begriffe und Abgrenzung - 4.2 Ursachenanalyse - 4.3 Workarounds und Known Errors - 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Service Level Management - Knowledge Management - Change Enablement - Continual Improvement - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Trendanalyse-Beispiele, - Datenquellen, - Prüffragen, - Checklisten, - Priorisierungskriterien, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Trendanalyse-Methode, - Datenquellenliste, - KPI-Struktur, - Problem-Eröffnungsschwelle, - Analysefrequenz, - oder Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Datenqualität, - Monitoring, - Supportmodell, - Service Levels, - Organisation, - Lieferanten, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management > **Kurz erklärt** > > Problem Management arbeitet nicht isoliert. > > Es ist eng verbunden mit Incident Management, Change Enablement, Knowledge Management, Service Configuration Management und Continual Improvement. > > Nur wenn diese Practices zusammenarbeiten, können Incidents schnell bearbeitet, Ursachen verstanden, dauerhafte Lösungen umgesetzt und Wissen für zukünftige Fälle nutzbar gemacht werden. --- **Warum das Zusammenspiel wichtig ist** Ein Problem entsteht häufig aus wiederkehrenden oder schwerwiegenden Incidents. Die dauerhafte Lösung benötigt oft einen Change. Der Service Desk benötigt Workarounds und Known Errors aus dem Knowledge Management. Service Configuration Management liefert Informationen über betroffene Systeme und Abhängigkeiten. Continual Improvement sorgt dafür, dass Erkenntnisse nicht verloren gehen. Ohne dieses Zusammenspiel entstehen typische Schwächen: - Incidents werden einzeln gelöst, aber Ursachen bleiben bestehen. - Workarounds sind bekannt, aber nicht dokumentiert. - Changes werden durchgeführt, ohne das Problem vollständig zu verstehen. - Knowledge-Artikel werden nicht aktualisiert. - Serviceabhängigkeiten sind unbekannt. - Lessons Learned werden nicht umgesetzt. - dieselben Incidents treten immer wieder auf. --- **Überblick über das Zusammenspiel** Incident tritt auf ↓ Incident Management stellt Service wieder her ↓ wiederkehrendes Muster oder schwere Auswirkung wird erkannt ↓ Problem Management untersucht Ursache ↓ Workaround oder Known Error wird dokumentiert ↓ Knowledge Management stellt Wissen bereit ↓ dauerhafte Lösung wird vorbereitet ↓ Change Enablement steuert Umsetzung ↓ Service wird stabilisiert ↓ Continual Improvement übernimmt Erkenntnisse --- **Problem Management und Incident Management** Incident Management und Problem Management haben unterschiedliche Schwerpunkte. | Incident Management | Problem Management | |---|---| | schnelle Wiederherstellung des Service | Ursache verstehen und Wiederholung vermeiden | | kurzfristiger Fokus | nachhaltiger Fokus | | einzelne Störung bearbeiten | Muster und Ursachen untersuchen | | Workaround kann genügen | dauerhafte Lösung wird angestrebt | | Benutzer schnell arbeitsfähig machen | Service langfristig stabiler machen | Beide Practices ergänzen sich. Incident Management liefert Daten und Erfahrungen. Problem Management liefert Workarounds, Known Errors und dauerhafte Verbesserungen zurück. --- **Was Incident Management an Problem Management liefert** Wichtige Informationen aus Incidents: - betroffener Service, - Symptome, - Fehlermeldungen, - Zeitpunkt, - betroffene Benutzer oder Standorte, - Priorität, - Auswirkungen, - erste Diagnose, - durchgeführte Maßnahmen, - verwendete Workarounds, - Eskalationen, - Logs, - Monitoringdaten, - betroffene Configuration Items, - Benutzerfeedback, - Wiedereröffnungen. Je besser Incidents dokumentiert sind, desto leichter kann Problem Management Muster erkennen. --- **Was Problem Management an Incident Management zurückliefert** Problem Management unterstützt Incident Management durch: - Known Errors, - Workarounds, - Diagnosehinweise, - Eskalationsregeln, - Knowledge-Artikel, - Runbooks, - Hinweise auf betroffene Versionen, - bekannte Symptome, - bekannte Risiken, - und geplante dauerhafte Lösungen. Dadurch kann der Service Desk zukünftige Incidents schneller erkennen und bearbeiten. Beispiel: Wenn ein VPN-Fehler als Known Error dokumentiert ist, muss der Service Desk nicht bei jedem neuen Ticket von vorn analysieren. --- **Wann ein Incident zu einem Problem führen kann** Ein Problem Record kann sinnvoll sein, wenn: - mehrere ähnliche Incidents auftreten, - ein Major Incident stattgefunden hat, - die Ursache unbekannt bleibt, - ein Workaround häufig genutzt wird, - ein Service wiederholt instabil ist, - ein Sicherheitsrisiko vermutet wird, - ein Trend erkennbar ist, - oder ein einzelner Incident sehr hohe Auswirkungen hatte. Nicht jeder Incident benötigt automatisch ein Problem. Die Organisation sollte Kriterien festlegen. --- **Beispiel: Incident zu Problem** **Incident** Mehrere Benutzer melden, dass VPN nach dem Ruhezustand nicht mehr funktioniert. **Incident Management** Der Service Desk stellt die Verbindung durch Neustart des VPN-Clients wieder her. **Problem Management** Mehrere gleichartige Incidents werden verglichen. Es wird erkannt: - gleiche Client-Version, - gleiches Fehlerbild, - gleicher Auslöser, - gleicher Workaround. **Ergebnis** Ein Problem Record wird erstellt. Ein Known Error und ein Workaround werden dokumentiert. Ein Change für eine neue Client-Version wird vorbereitet. --- **Problem Management und Change Enablement** Dauerhafte Lösungen erfordern häufig Änderungen an produktiven Systemen. Beispiele: - Softwareupdate, - Konfigurationsänderung, - Austausch defekter Hardware, - Anpassung einer Firewall-Regel, - Änderung eines Deployments, - Zertifikatserneuerung, - Monitoring-Erweiterung, - Automatisierung, - Prozessänderung. Solche Maßnahmen dürfen nicht unkontrolliert durchgeführt werden. Change Enablement sorgt dafür, dass Änderungen bewertet, geplant, genehmigt, umgesetzt und überprüft werden. --- **Warum dauerhafte Lösungen oft Changes sind** Eine dauerhafte Lösung verändert häufig den Zustand einer Umgebung. Beispiele: | Problem | mögliche dauerhafte Lösung | Bezug zu Change Enablement | |---|---|---| | VPN-Client fehlerhaft | neue Version ausrollen | Software-Change | | Zertifikat läuft ab | Zertifikat erneuern und Monitoring ergänzen | technischer Change | | Speicher läuft voll | Logrotation ändern | Konfigurations-Change | | Druckertreiber fehlerhaft | Treiber aktualisieren | Standard- oder Normal-Change | | Dienst stürzt regelmäßig ab | Anwendungspatch einspielen | Release oder Change | | Berechtigungen falsch modelliert | Rollenkonzept anpassen | organisatorischer und technischer Change | Die Art des Changes hängt von Risiko, Auswirkung und Organisationsregeln ab. --- **Problem Management liefert Input für Changes** Ein guter Change zur Problemlösung sollte auf nachvollziehbaren Informationen beruhen. Problem Management liefert dafür: - Problembeschreibung, - Ursache oder wahrscheinliche Ursache, - Auswirkungen, - betroffene Services, - betroffene Configuration Items, - Risiko bei Nicht-Handeln, - Workaround, - bekannte Einschränkungen, - empfohlene Lösung, - erwarteten Nutzen, - mögliche Nebenwirkungen, - Testhinweise, - Rollback-Hinweise, - Verknüpfung zu Incidents. Dadurch kann Change Enablement besser bewerten, ob und wie die Änderung umgesetzt werden soll. --- **Change Enablement liefert Informationen zurück** Nach einem Change sollte geprüft werden: - Wurde die dauerhafte Lösung erfolgreich umgesetzt? - Sind die betroffenen Incidents zurückgegangen? - Sind neue Fehler entstanden? - Funktioniert der Service stabil? - Muss der Workaround angepasst oder entfernt werden? - Muss der Known Error geschlossen werden? - Müssen Knowledge-Artikel aktualisiert werden? - Muss Monitoring angepasst werden? Ein Problem sollte nicht automatisch geschlossen werden, nur weil ein Change umgesetzt wurde. Die Wirksamkeit muss überprüft werden. --- **Emergency Change und Problem Management** Bei sehr kritischen Situationen kann eine schnelle Änderung notwendig sein. Beispiele: - Sicherheitslücke wird aktiv ausgenutzt, - zentraler Service ist ausgefallen, - Datenverlust droht, - ein Workaround ist nicht verfügbar, - ein Major Incident erfordert sofortige technische Änderung. Auch dann sollten Entscheidungen dokumentiert werden. Nach der Wiederherstellung sollten Problem Management und Review klären: - Warum war ein Emergency Change nötig? - War die Änderung wirksam? - Welche Risiken entstanden? - Welche dauerhafte Lösung ist noch erforderlich? - Wie kann eine ähnliche Situation künftig vermieden werden? --- **Problem Management und Knowledge Management** Problem Management erzeugt Wissen. Dieses Wissen muss auffindbar, verständlich und aktuell sein. Geeignete Inhalte für Knowledge Management: - bekannte Symptome, - Workarounds, - Known Errors, - Prüfschritte, - Eskalationskriterien, - betroffene Versionen, - Abbruchkriterien, - sichere Benutzeranleitungen, - interne Runbooks, - dauerhafte Lösungen, - Lessons Learned. Wenn Wissen nicht dokumentiert wird, müssen Teams dieselben Fälle immer wieder neu analysieren. --- **Unterschiedliche Zielgruppen für Wissen** Nicht jedes Wissen gehört in denselben Artikel. | Zielgruppe | Inhalt | |---|---| | Benutzer | einfache Anleitung, Workaround, Statushinweise | | Service Desk | Prüfschritte, bekannte Symptome, Eskalationsregeln | | Fachteam | technische Details, Logs, Konfigurationen, Ursachen | | Management | Risiko, Auswirkungen, Verbesserungsstatus | | Lieferant | Produktversion, Fehlerbild, technische Nachweise | Ein Benutzerartikel sollte keine internen Diagnoseschritte oder vertraulichen technischen Details enthalten. --- **Known Error als Wissensbaustein** Ein Known Error ist besonders wichtig für Knowledge Management. Er beschreibt: - welches Fehlerbild bekannt ist, - welcher Service betroffen ist, - welche Ursache oder wahrscheinliche Ursache vorliegt, - welcher Workaround gilt, - wann eskaliert werden muss, - welche dauerhafte Lösung geplant ist, - und ob ein Change offen ist. Dadurch kann der Service Desk schneller entscheiden, ob ein neuer Incident zu einem bekannten Fehler passt. --- **Knowledge-Artikel aktuell halten** Nach Problem- und Change-Bearbeitung müssen Wissensartikel geprüft werden. Zu aktualisieren sind möglicherweise: - Workarounds, - Known-Error-Status, - Screenshots, - Menüpfade, - betroffene Versionen, - Eskalationswege, - Sicherheitswarnungen, - Benutzerinformationen, - Runbooks, - Monitoringhinweise, - Abschlusskriterien. Ein gelöster Known Error mit veraltetem Workaround kann später neue Verwirrung erzeugen. --- **Problem Management und Service Configuration Management** Für Problem Management sind Informationen über Configuration Items und Serviceabhängigkeiten sehr wichtig. Hilfreich sind: - betroffene Server, - Anwendungen, - Datenbanken, - Netzwerke, - Zertifikate, - Schnittstellen, - Cloud-Dienste, - Lieferantenservices, - Versionen, - Standorte, - Verantwortliche, - Abhängigkeiten. Ohne diese Informationen ist schwer erkennbar, welche Komponenten gemeinsam betroffen sind. --- **Beispiel: Abhängigkeiten erkennen** Mehrere Anwendungen melden Verbindungsfehler. Einzelne Teams prüfen zunächst ihre Anwendungen getrennt. Durch Service- und CI-Beziehungen wird sichtbar: - alle Anwendungen nutzen denselben Datenbankcluster, - der Datenbankcluster nutzt denselben Storage, - genau dieser Storage zeigt erhöhte Fehlerraten. Problem Management kann dadurch gezielter analysieren. --- **Problem Management und Service Level Management** Service Level Management hilft zu bewerten, welche Problems besonders wichtig sind. Zu berücksichtigen sind: - vereinbarte Service Levels, - betroffene Servicezeiten, - geschäftskritische Services, - wiederholte SLA-Gefährdung, - Benutzer- oder Kundenimpact, - Service Reviews, - Beschwerden, - vertragliche Verpflichtungen. Ein Problem mit wenigen Incidents kann hohe Priorität besitzen, wenn ein kritischer Service oder ein wichtiges Service Level gefährdet ist. --- **Problem Management und Supplier Management** Viele Problems betreffen Lieferanten oder Hersteller. Beispiele: - Software-Bug, - Cloud-Service-Störung, - Firmwarefehler, - Providerproblem, - fehlerhafte Schnittstelle, - Lizenzdienst nicht erreichbar, - Hardwarefehler. Problem Management sollte dokumentieren: - Lieferantenticket, - Herstellerreferenz, - betroffene Version, - empfohlener Workaround, - geplante Korrektur, - interne Auswirkungen, - Eskalationsweg, - offene Risiken. Auch wenn ein Lieferant technisch verantwortlich ist, bleibt die interne Serviceverantwortung bestehen. --- **Problem Management und Continual Improvement** Problem Management liefert viele Verbesserungsideen. Beispiele: - Monitoring erweitern, - Knowledge Base verbessern, - Runbooks erstellen, - Standard-Changes definieren, - Schulungen durchführen, - Automatisierung einführen, - Serviceabhängigkeiten pflegen, - Prozesse verbessern, - Lieferantensteuerung anpassen. Diese Verbesserungen sollten nicht nur mündlich besprochen werden. Sie sollten in einem Improvement Register oder vergleichbaren System verfolgt werden. --- **Problem Management und Information Security Management** Manche Problems haben Sicherheitsbezug. Beispiele: - wiederkehrende kompromittierte Konten, - unsichere Standardkonfiguration, - veraltete Software, - fehlende Patchprozesse, - zu weitreichende Berechtigungen, - unzureichende Protokollierung, - wiederholte Phishing-Erfolge, - fehlende MFA-Ausnahmenkontrolle. Sicherheitsbezogene Problems benötigen möglicherweise: - besondere Vertraulichkeit, - andere Eskalationswege, - Beweissicherung, - Risikobewertung, - Meldefristen, - und Abstimmung mit Informationssicherheit. --- **Problem Management und Monitoring** Monitoring unterstützt Problem Management durch: - Frühwarnungen, - Trends, - Fehlerraten, - Kapazitätsdaten, - Verfügbarkeitsdaten, - Antwortzeiten, - Logereignisse, - Zertifikatsabläufe, - Backupstatus, - Hardwarezustände. Problem Management kann umgekehrt Monitoring verbessern. Beispiele: - neuer Alarm für Zertifikatsablauf, - zusätzliche Überwachung von Logwachstum, - Dashboard für häufig betroffene Services, - bessere Alarmgrenzen, - Überwachung eines Workarounds, - Prüfung nach Change. --- **Zusammenspiel als Kreislauf** Incident-Daten ↓ Problem-Analyse ↓ Known Error und Workaround ↓ Knowledge-Artikel ↓ dauerhafte Lösung ↓ Change ↓ Wirksamkeitsprüfung ↓ Verbesserung von Monitoring, Wissen und Prozessen ↓ weniger oder schneller lösbare Incidents --- **Typische Fehler im Zusammenspiel** **Fehler 1** Incidents werden gelöst, aber nicht mit Problems verknüpft. --- **Fehler 2** Problem Management erhält zu wenig Informationen aus Tickets. --- **Fehler 3** Workarounds werden gefunden, aber nicht in Knowledge Management übernommen. --- **Fehler 4** Known Errors sind nur Spezialisten bekannt. --- **Fehler 5** Dauerhafte Lösungen werden ohne Change-Bewertung umgesetzt. --- **Fehler 6** Nach einem Change wird nicht geprüft, ob das Problem wirklich gelöst ist. --- **Fehler 7** Knowledge-Artikel bleiben nach einer dauerhaften Lösung unverändert. --- **Fehler 8** CMDB- und Serviceabhängigkeiten werden nicht genutzt. --- **Fehler 9** Lieferantenfehler werden intern nicht nachvollziehbar dokumentiert. --- **Fehler 10** Lessons Learned werden nicht in Continual Improvement übernommen. --- **Fehler 11** Sicherheitsbezug wird zu spät erkannt. --- **Fehler 12** Problem Records bleiben offen, ohne Verantwortlichen oder nächsten Schritt. --- **Praxisbeispiel: VPN-Problem** **Incident Management** Mehrere Benutzer melden VPN-Abbrüche. Der Service Desk stellt die Verbindung durch Neustart des Clients wieder her. **Problem Management** Incidents werden verglichen. Die Analyse zeigt: - gleiche Client-Version, - gleiches Fehlerbild, - Auftreten nach Ruhezustand, - bekannter Herstellerfehler. **Knowledge Management** Ein Known Error und ein Workaround werden dokumentiert. Der Service Desk erhält Prüfschritte. **Change Enablement** Eine neue Client-Version wird getestet und kontrolliert ausgerollt. **Continual Improvement** Der Updateprozess wird angepasst, damit Clientupdates künftig besser getestet werden. --- **Praxisbeispiel: Zertifikatsausfall** **Incident Management** Benutzer können sich nicht an einer Anwendung anmelden. Das abgelaufene Zertifikat wird erneuert. **Problem Management** Die Ursache wird untersucht. Ergebnis: - kein Monitoring für Zertifikatsablauf, - kein Owner für Zertifikate, - kein Runbook für Erneuerung. **Knowledge Management** Symptome und Prüfschritte werden dokumentiert. **Change Enablement** Monitoring und Erneuerungsprozess werden eingeführt. **Continual Improvement** Zertifikatsübersicht und Wartungskalender werden als Standard etabliert. --- **Praxisbeispiel: Druckerfehler** **Incident Management** Etikettendrucker blockiert regelmäßig. Der Service Desk leert die Warteschlange. **Problem Management** Bestimmte PDF-Dateien und ein alter Treiber werden als Ursache erkannt. **Knowledge Management** Workaround wird dokumentiert. **Change Enablement** Treiberupdate wird getestet und ausgerollt. **Service Desk** Künftige Incidents können schneller erkannt werden. **Continual Improvement** Druckertreiber werden in einen regelmäßigen Prüfprozess aufgenommen. --- **Checkliste Zusammenspiel mit Incident Management** - [ ] zugehörige Incidents verknüpft - [ ] Symptome aus Incidents zusammengefasst - [ ] Auswirkungen dokumentiert - [ ] Workarounds aus Incidents geprüft - [ ] Wiedereröffnungen berücksichtigt - [ ] Eskalationen ausgewertet - [ ] Service Desk über Known Error informiert - [ ] Incident-Abschlusskriterien geprüft - [ ] neue Incidents dem Problem zugeordnet - [ ] Trenddaten berücksichtigt --- **Checkliste Zusammenspiel mit Change Enablement** - [ ] dauerhafte Lösung beschrieben - [ ] Risiko bewertet - [ ] betroffene Services und CIs bekannt - [ ] Change-Typ geprüft - [ ] Testbedarf beschrieben - [ ] Rollback betrachtet - [ ] Wartungsfenster geprüft - [ ] Kommunikationsbedarf erkannt - [ ] Change mit Problem Record verknüpft - [ ] Wirksamkeit nach Change geprüft --- **Checkliste Zusammenspiel mit Knowledge Management** - [ ] Known Error dokumentiert - [ ] Workaround beschrieben - [ ] Zielgruppe des Artikels festgelegt - [ ] Service Desk informiert - [ ] Benutzerinformation bei Bedarf erstellt - [ ] interne technische Hinweise ergänzt - [ ] Eskalationskriterien beschrieben - [ ] Artikel nach Change aktualisiert - [ ] veraltete Inhalte entfernt - [ ] Lessons Learned übernommen --- **Checkliste Zusammenspiel mit Configuration Management** - [ ] betroffene CIs erfasst - [ ] Serviceabhängigkeiten geprüft - [ ] Versionen dokumentiert - [ ] Standorte berücksichtigt - [ ] Lieferantenbezug geprüft - [ ] letzte Changes berücksichtigt - [ ] CMDB-Abweichungen erkannt - [ ] notwendige Aktualisierungen veranlasst --- **Checkliste Abschluss eines Problems** - [ ] Ursache oder Risiko ausreichend verstanden - [ ] Workaround dokumentiert oder als nicht verfügbar gekennzeichnet - [ ] Known Error aktualisiert - [ ] dauerhafte Lösung umgesetzt oder bewusst zurückgestellt - [ ] Change-Ergebnis geprüft - [ ] Knowledge Base aktualisiert - [ ] zugehörige Incidents berücksichtigt - [ ] Monitoring oder Runbooks angepasst - [ ] Lessons Learned dokumentiert - [ ] Rest Risiko bewertet - [ ] Verantwortliche informiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker für Systemintegration stehen oft genau an der Schnittstelle zwischen Incident, Problem, Change und Knowledge. Im Arbeitsalltag bedeutet das: - Incidents sauber dokumentieren, - wiederkehrende Muster erkennen, - technische Ursachen nachvollziehbar beschreiben, - Workarounds sicher formulieren, - Knowledge-Artikel und Runbooks unterstützen, - Changes fachlich vorbereiten, - CIs und Abhängigkeiten berücksichtigen, - Monitoring verbessern, - und Lessons Learned in dauerhafte Verbesserungen überführen. Gute technische Arbeit endet nicht mit der Wiederherstellung eines Services. Sie hilft auch, zukünftige Incidents zu vermeiden oder schneller zu lösen. --- **Zusammenfassung** > Incident wird bearbeitet > ↓ > Muster oder Ursache wird erkannt > ↓ > Problem Record wird erstellt > ↓ > Ursache, Risiko und Workaround werden untersucht > ↓ > Known Error und Knowledge werden dokumentiert > ↓ > dauerhafte Lösung wird vorbereitet > ↓ > Change Enablement steuert Umsetzung > ↓ > Wirksamkeit wird geprüft > ↓ > Monitoring, Knowledge, Prozesse und Standards werden verbessert > ↓ > zukünftige Incidents werden reduziert oder schneller lösbar --- **Merksätze** > Incident Management stellt den Service wieder her. > Problem Management versteht Ursachen und reduziert Wiederholungen. > Change Enablement sorgt für kontrollierte dauerhafte Lösungen. > Knowledge Management macht Workarounds und Known Errors nutzbar. > Configuration Management zeigt Abhängigkeiten und betroffene Komponenten. > Continual Improvement sorgt dafür, dass Erkenntnisse nicht verloren gehen. > Gute Zusammenarbeit verhindert, dass dieselben Fehler immer wieder neu analysiert werden. --- **Verwandte Seiten** - 4.1 Problem Management – Ziele, Begriffe und Abgrenzung - 4.2 Ursachenanalyse - 4.3 Workarounds und Known Errors - 4.4 Trendanalyse und proaktives Problem Management - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Change Enablement - Knowledge Management - Service Configuration Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Schnittstellen, - Checklisten, - Praxisbeispiele, - Ablaufdarstellungen, - Rollenhinweise, - und Dokumentationshinweise sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Schnittstellenmatrix, - Übergabestruktur, - Problem-Abschlussregel, - Knowledge-Vorlage, - Change-Verknüpfung, - oder konkrete Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisation, - ITSM-Werkzeuge, - Datenqualität, - Supportmodell, - Change-Modell, - Knowledge-Struktur, - Lieferanten, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 5. Change Enablement # 5.1 Change Enablement – Ziele, Begriffe und Abgrenzung > **Kurz erklärt** > > Change Enablement beschäftigt sich damit, Änderungen an Services, Systemen, Prozessen oder Infrastruktur kontrolliert, nachvollziehbar und risikobewusst umzusetzen. > > Ziel ist nicht, Änderungen zu verhindern. > > Ziel ist, nützliche Änderungen zu ermöglichen, ohne unnötige Risiken für laufende Services, Benutzer oder Geschäftsprozesse zu erzeugen. --- **Warum Change Enablement wichtig ist** IT-Umgebungen verändern sich ständig. Beispiele: - Software wird aktualisiert. - Server werden ersetzt. - Firewall-Regeln werden angepasst. - Zertifikate werden erneuert. - Benutzerrechte werden geändert. - Cloud-Ressourcen werden erstellt. - Monitoring wird erweitert. - Anwendungen werden deployed. - Schnittstellen werden angepasst. - Sicherheitsupdates werden eingespielt. Jede Änderung kann Nutzen bringen. Jede Änderung kann aber auch Störungen verursachen. Change Enablement sorgt dafür, dass Änderungen: - bewertet, - geplant, - genehmigt, - umgesetzt, - dokumentiert, - kommuniziert, - und nachbereitet werden. --- **Change Enablement ist kein Änderungsverbot** Ein häufiger Irrtum: > Change Enablement bedeutet, dass jede Änderung möglichst schwer gemacht wird. Das ist falsch. Change Enablement soll Änderungen ermöglichen. Aber Änderungen sollen so durchgeführt werden, dass: - Risiken bekannt sind, - Verantwortlichkeiten klar sind, - Auswirkungen verstanden werden, - Rückfallmöglichkeiten vorhanden sind, - betroffene Personen informiert werden, - und Services möglichst stabil bleiben. > **Merke** > > Gute Change-Steuerung schützt nicht vor Veränderung. > > Sie schützt vor unkontrollierter Veränderung. --- **Was ist ein Change?** Ein Change ist eine Änderung an einem Service oder an einem unterstützenden Bestandteil eines Service. Betroffen sein können beispielsweise: - Anwendungen, - Server, - Netzwerke, - Datenbanken, - Cloud-Ressourcen, - Benutzerrechte, - Konfigurationen, - Sicherheitsregeln, - Zertifikate, - Monitoring, - Prozesse, - Dokumentation, - Schnittstellen, - oder Servicekatalogeinträge. Nicht jede Tätigkeit ist automatisch ein Change im engeren Sinn. Die Organisation muss festlegen, welche Arten von Änderungen über Change Enablement gesteuert werden. --- **Beispiele für Changes** | Change | Beispiel | |---|---| | **Software-Change** | Update einer Fachanwendung | | **Infrastruktur-Change** | Austausch eines Servers | | **Netzwerk-Change** | Anpassung einer Firewall-Regel | | **Cloud-Change** | Erstellen einer neuen Ressourcengruppe | | **Security-Change** | Aktivierung von MFA | | **Konfigurations-Change** | Änderung eines Dienstparameters | | **Datenbank-Change** | Schemaänderung | | **Prozess-Change** | neuer Genehmigungsworkflow | | **Monitoring-Change** | neue Alarmregel | | **Dokumentations-Change** | Aktualisierung eines Runbooks | --- **Ziele von Change Enablement** Change Enablement verfolgt mehrere Ziele: - nützliche Änderungen ermöglichen, - Risiken vorab erkennen, - Auswirkungen auf Services bewerten, - unnötige Störungen vermeiden, - Änderungen nachvollziehbar dokumentieren, - betroffene Stakeholder informieren, - Verantwortlichkeiten festlegen, - erfolgreiche Umsetzung prüfen, - Lernen aus fehlgeschlagenen Changes ermöglichen, - und Servicequalität langfristig verbessern. Change Enablement verbindet Stabilität und Veränderungsfähigkeit. --- **Risiken unkontrollierter Änderungen** Unkontrollierte Änderungen können zu schweren Problemen führen. Beispiele: - Service fällt aus. - Benutzer können nicht arbeiten. - Daten werden beschädigt. - Berechtigungen werden falsch gesetzt. - Sicherheitslücken entstehen. - Schnittstellen funktionieren nicht mehr. - Monitoring schlägt nicht mehr korrekt an. - Backups funktionieren nicht mehr. - Dokumentation stimmt nicht mehr. - Incidents entstehen nach einem Change. Viele Incidents entstehen nicht durch völlig unbekannte Fehler, sondern durch schlecht geplante oder schlecht dokumentierte Änderungen. --- **Change Enablement und Incident Management** Change Enablement steht eng mit Incident Management in Verbindung. Ein Change kann: - einen Incident verursachen, - einen Incident beheben, - einen Workaround ermöglichen, - oder eine dauerhafte Lösung für ein Problem umsetzen. Beispiel: Nach einem Update funktioniert eine Anwendung nicht mehr. Incident Management stellt den Service schnell wieder her. Change Enablement hilft anschließend zu klären: - Welcher Change wurde durchgeführt? - Wurde der Change korrekt bewertet? - Gab es Tests? - Gab es einen Rollback-Plan? - Wurden betroffene Benutzer informiert? - Was muss künftig verbessert werden? --- **Change Enablement und Problem Management** Problem Management liefert häufig den Anlass für Changes. Beispiele: - wiederkehrende VPN-Störung, - ablaufende Zertifikate, - fehlerhafte Softwareversion, - instabiler Druckertreiber, - unzureichendes Monitoring, - falsche Berechtigungsstruktur. Die dauerhafte Lösung eines Problems erfordert oft einen Change. Problem Management beschreibt Ursache, Risiko und Lösungsvorschlag. Change Enablement sorgt für kontrollierte Umsetzung. --- **Change Enablement und Knowledge Management** Änderungen erzeugen neues Wissen. Nach einem Change müssen möglicherweise aktualisiert werden: - Knowledge-Artikel, - Runbooks, - Betriebsdokumentation, - Servicekatalog, - Supportanleitungen, - Benutzerinformationen, - Eskalationswege, - Monitoringhinweise, - Known Errors, - und Schulungsunterlagen. Ein Change ist nicht vollständig abgeschlossen, wenn die Technik funktioniert, aber das Wissen veraltet bleibt. --- **Change Enablement und Service Configuration Management** Service Configuration Management liefert Informationen über Configuration Items und Abhängigkeiten. Für Changes ist wichtig zu wissen: - Welche CIs sind betroffen? - Welche Services hängen davon ab? - Welche Versionen sind installiert? - Welche Standorte nutzen den Service? - Welche Lieferanten sind beteiligt? - Welche Changes wurden zuletzt durchgeführt? - Welche Beziehungen bestehen zu anderen Services? Ohne diese Informationen kann die Auswirkungsbewertung unvollständig sein. --- **Change Enablement und Information Security Management** Viele Changes haben Sicherheitsbezug. Beispiele: - Firewall-Regel ändern, - Administratorrechte vergeben, - MFA aktivieren, - Zertifikat austauschen, - Zugriff auf Daten freigeben, - Logging verändern, - Sicherheitssoftware aktualisieren, - externe Schnittstelle öffnen. Solche Changes benötigen möglicherweise besondere Prüfung durch Informationssicherheit. Dabei geht es nicht darum, jede Änderung zu blockieren. Es geht darum, Risiken bewusst zu bewerten. --- **Change Enablement und Continual Improvement** Change Enablement unterstützt kontinuierliche Verbesserung. Verbesserungen werden oft durch Changes umgesetzt. Beispiele: - Monitoring erweitern, - Self-Service verbessern, - Automatisierung einführen, - Service stabilisieren, - Sicherheitsmaßnahmen erhöhen, - Prozesse vereinfachen, - technische Schulden abbauen. Continual Improvement erkennt Verbesserungsbedarf. Change Enablement sorgt dafür, dass die Änderung kontrolliert umgesetzt wird. --- **Change Request** Ein Change Request beschreibt eine gewünschte Änderung. Typische Inhalte: - Beschreibung der Änderung, - Grund der Änderung, - erwarteter Nutzen, - betroffener Service, - betroffene Systeme oder CIs, - Risiko, - Auswirkungen, - geplanter Zeitpunkt, - Verantwortlicher, - Testplan, - Kommunikationsbedarf, - Rollback-Plan, - Genehmigungsbedarf, - Abhängigkeiten, - und Erfolgsprüfung. Das konkrete Format hängt vom ITSM-Werkzeug und der Organisation ab. --- **Warum ein Change Request wichtig ist** Ein Change Request macht eine Änderung nachvollziehbar. Er beantwortet zentrale Fragen: - Was soll geändert werden? - Warum soll es geändert werden? - Wer ist betroffen? - Wann soll es passieren? - Wer führt es aus? - Welche Risiken bestehen? - Wie wird getestet? - Wie wird zurückgerollt? - Wer muss informiert werden? - Woran erkennt man Erfolg? Ohne diese Informationen kann eine Änderung schwer bewertet werden. --- **Auswirkung und Risiko bewerten** Vor einem Change sollte geprüft werden: - Welche Services sind betroffen? - Welche Benutzer oder Kunden sind betroffen? - Welche Geschäftsprozesse sind betroffen? - Welche Abhängigkeiten bestehen? - Welche Sicherheitsrisiken entstehen? - Welche Daten können betroffen sein? - Welche Service Levels könnten beeinflusst werden? - Wie wahrscheinlich ist ein Fehler? - Wie schwer wären die Folgen? - Gibt es ein Wartungsfenster? - Gibt es einen Rollback? Die Bewertung muss zum Umfang der Änderung passen. Eine kleine Standardänderung benötigt weniger Aufwand als eine kritische Produktionsumstellung. --- **Nutzen bewerten** Neben Risiken muss auch der Nutzen betrachtet werden. Möglicher Nutzen: - Störung dauerhaft beheben, - Sicherheitslücke schließen, - Performance verbessern, - Kapazität erhöhen, - Benutzererfahrung verbessern, - Betrieb vereinfachen, - Kosten senken, - gesetzliche Anforderung erfüllen, - Automatisierung ermöglichen, - technische Schulden reduzieren. Ein Change kann trotz Risiko sinnvoll sein, wenn der Nutzen wichtig genug ist und die Risiken kontrolliert werden. --- **Change Enablement und Geschwindigkeit** Nicht alle Changes dürfen gleich langsam oder gleich schnell behandelt werden. Eine Organisation muss unterscheiden zwischen: - häufigen, risikoarmen Standardänderungen, - normalen Änderungen mit Bewertung, - dringenden Änderungen bei akuten Risiken. Zu viel Kontrolle verlangsamt notwendige Verbesserungen. Zu wenig Kontrolle erzeugt Störungen. Gutes Change Enablement findet ein passendes Gleichgewicht. --- **Typische Change-Arten** Viele Organisationen unterscheiden mindestens: - Standard Change, - Normal Change, - Emergency Change. Die genaue Bezeichnung und Ausgestaltung kann je nach Organisation unterschiedlich sein. ITIL gibt Konzepte vor, aber keine für alle Organisationen identische Prozessform. --- **Standard Change** Ein Standard Change ist eine vorab bewertete, wiederholbare und risikoarme Änderung. Typische Merkmale: - häufig wiederkehrend, - klar dokumentiert, - geringes Risiko, - vorab genehmigt, - standardisierter Ablauf, - bekannte Auswirkungen, - definierte Umsetzungsschritte. Beispiele: - Standardsoftware installieren, - Benutzer zu definierter Gruppe hinzufügen, - Standardgerät bereitstellen, - vorab geprüfte Monitoringregel aktivieren, - Standardzertifikat nach Runbook erneuern. Ein Standard Change benötigt nicht jedes Mal eine vollständige Einzelgenehmigung. Er muss aber sauber definiert und kontrolliert sein. --- **Normal Change** Ein Normal Change ist eine Änderung, die bewertet, geplant und je nach Risiko genehmigt werden muss. Beispiele: - Update einer produktiven Anwendung, - Änderung einer Firewall-Regel, - Datenbankmigration, - Austausch zentraler Infrastruktur, - Änderung einer Schnittstelle, - Einführung eines neuen Services. Normal Changes benötigen typischerweise: - Risiko- und Auswirkungsbewertung, - Planung, - Freigabe, - Kommunikation, - Test, - Umsetzung, - und Nachprüfung. --- **Emergency Change** Ein Emergency Change ist eine dringende Änderung, die notwendig ist, um einen akuten Schaden zu vermeiden oder einen Service schnell wiederherzustellen. Beispiele: - aktive Sicherheitslücke schließen, - kritischen Service nach Ausfall wiederherstellen, - fehlerhafte Konfiguration kurzfristig zurückrollen, - Zertifikat bei produktivem Ausfall erneuern, - Datenverlust verhindern. Emergency Changes dürfen nicht als Abkürzung für schlecht geplante Arbeit missbraucht werden. Auch bei hoher Dringlichkeit sollten Entscheidungen und Maßnahmen dokumentiert werden. Nachträgliche Prüfung ist besonders wichtig. --- **Change Authority** Eine Change Authority ist eine Person oder Gruppe, die Changes bewertet oder genehmigt. Je nach Organisation und Change-Art können das sein: - Service Owner, - Change Manager, - Produktteam, - technisches Fachteam, - Informationssicherheit, - Management, - Change Advisory Board, - Emergency Change Authority. Die Change Authority sollte zur Größe, zum Risiko und zur Auswirkung des Changes passen. Nicht jede Änderung benötigt ein großes Gremium. --- **Change Advisory Board** Ein Change Advisory Board kann bei komplexeren oder risikoreicheren Changes beraten. Mögliche Aufgaben: - Risiken bewerten, - Abhängigkeiten erkennen, - Terminüberschneidungen prüfen, - Kommunikationsbedarf einschätzen, - Fachteams einbinden, - Genehmigung vorbereiten. Ein Change Advisory Board sollte nicht jede kleine Änderung ausbremsen. Es sollte dort unterstützen, wo mehrere Perspektiven notwendig sind. --- **Kommunikation bei Changes** Betroffene Benutzer und Stakeholder sollten rechtzeitig informiert werden. Zu kommunizieren sind je nach Situation: - Was wird geändert? - Warum wird es geändert? - Wann findet die Änderung statt? - Welche Auswirkungen sind zu erwarten? - Gibt es eine Unterbrechung? - Welche Benutzer sind betroffen? - Was müssen Benutzer tun? - Wo gibt es Statusinformationen? - Wann ist die Änderung abgeschlossen? Gute Kommunikation reduziert Unsicherheit und unnötige Tickets. --- **Wartungsfenster** Ein Wartungsfenster ist ein geplanter Zeitraum für Änderungen. Es hilft, Risiken zu begrenzen. Zu beachten: - Servicezeiten, - Benutzergruppen, - Geschäftsprozesse, - Zeitzonen, - Abhängigkeiten, - Lieferantenverfügbarkeit, - Backup- oder Wiederherstellungsmöglichkeiten, - Kommunikationsbedarf. Ein Wartungsfenster sollte nicht nur technisch bequem sein. Es muss auch zur Nutzung des Services passen. --- **Rollback und Backout** Vor riskanten Changes sollte klar sein, wie die Änderung zurückgenommen werden kann. Zu prüfen ist: - Kann die vorherige Version wiederhergestellt werden? - Sind Backups aktuell? - Gibt es Konfigurationssicherungen? - Wie lange dauert der Rollback? - Welche Daten können betroffen sein? - Wann muss abgebrochen werden? - Wer entscheidet über den Rollback? - Welche Kommunikation ist notwendig? Nicht jeder Change kann einfach zurückgerollt werden. Dann muss das Risiko besonders sorgfältig bewertet werden. --- **Testen vor Umsetzung** Tests reduzieren Risiken. Mögliche Tests: - Funktionstest, - Sicherheitstest, - Kompatibilitätstest, - Performance-Test, - Wiederherstellungstest, - Benutzerakzeptanztest, - Smoke Test nach Umsetzung, - Monitoringprüfung. Der Testumfang muss zum Risiko passen. Ein kritischer Change benötigt mehr Prüfung als ein kleiner Standard Change. --- **Erfolg eines Changes prüfen** Nach der Umsetzung sollte geprüft werden: - Wurde die Änderung wie geplant umgesetzt? - Funktioniert der betroffene Service? - Funktionieren abhängige Services? - Sind Monitoring und Logs unauffällig? - Sind Benutzer arbeitsfähig? - Gab es Incidents nach dem Change? - Wurde der erwartete Nutzen erreicht? - Muss Dokumentation aktualisiert werden? Ein Change ist nicht nur deshalb erfolgreich, weil die technische Änderung durchgeführt wurde. Er ist erfolgreich, wenn der gewünschte Nutzen ohne unvertretbare Nebenwirkungen erreicht wurde. --- **Failed Change** Ein Failed Change ist eine Änderung, die nicht wie geplant erfolgreich war oder negative Auswirkungen verursacht hat. Mögliche Ursachen: - unvollständige Auswirkungsbewertung, - unzureichende Tests, - falsche Annahmen, - fehlende Rollback-Möglichkeit, - unklare Verantwortlichkeiten, - schlechte Kommunikation, - unerkannte Abhängigkeiten, - technische Fehler, - fehlende Datenqualität. Failed Changes sollten analysiert werden. Ziel ist Lernen, nicht Schuldzuweisung. --- **Typische Fehler** **Fehler 1** Änderungen werden ohne Bewertung direkt in Produktion durchgeführt. --- **Fehler 2** Change Enablement wird als reine Bürokratie verstanden. --- **Fehler 3** Risiken werden nur technisch, nicht geschäftlich bewertet. --- **Fehler 4** Abhängigkeiten zwischen Services werden nicht geprüft. --- **Fehler 5** Benutzer werden nicht informiert. --- **Fehler 6** Rollback fehlt oder ist unrealistisch. --- **Fehler 7** Tests sind unzureichend. --- **Fehler 8** Emergency Changes werden als Abkürzung genutzt. --- **Fehler 9** Nach dem Change wird der Erfolg nicht geprüft. --- **Fehler 10** Dokumentation und Knowledge Base werden nicht aktualisiert. --- **Fehler 11** Changes werden nicht mit Incidents oder Problems verknüpft. --- **Fehler 12** Failed Changes werden nicht ausgewertet. --- **Praxisbeispiel: Firewall-Regel** **Ausgangslage** Eine neue Schnittstelle zwischen zwei Anwendungen soll freigeschaltet werden. **Change Request** - betroffene Services dokumentieren, - Quell- und Zielsysteme prüfen, - Port und Protokoll festlegen, - Sicherheitsbewertung durchführen, - Testfenster planen, - Rollback beschreiben, - Monitoring nach Umsetzung prüfen. **Risiko** Falsche Regel kann Zugriff verhindern oder ungewollten Zugriff erlauben. **Erfolgskriterium** Die Schnittstelle funktioniert und es gibt keine unerwarteten Verbindungsfreigaben. --- **Praxisbeispiel: Zertifikat erneuern** **Ausgangslage** Ein Zertifikat läuft bald ab. **Change** Zertifikat wird vor Ablauf erneuert. **Prüfung** - betroffene Services identifizieren, - Zertifikatskette prüfen, - Wartungsfenster festlegen, - Backup der alten Konfiguration sichern, - Rollback vorbereiten, - Anmeldung nach Umsetzung testen. **Nutzen** Ausfall durch abgelaufenes Zertifikat wird verhindert. --- **Praxisbeispiel: Emergency Change** **Ausgangslage** Eine kritische Sicherheitslücke wird aktiv ausgenutzt. **Maßnahme** Ein Sicherheitsupdate muss kurzfristig eingespielt werden. **Wichtig** - Risiko bewerten, - Entscheidung dokumentieren, - betroffene Services informieren, - Umsetzung kontrolliert durchführen, - Ergebnis prüfen, - nachträglich reviewen, - Knowledge und Dokumentation aktualisieren. --- **Checkliste Change Request** - [ ] Änderung eindeutig beschrieben - [ ] Grund und Nutzen genannt - [ ] betroffener Service erfasst - [ ] betroffene CIs dokumentiert - [ ] Auswirkungen bewertet - [ ] Risiko bewertet - [ ] Verantwortlicher benannt - [ ] geplanter Zeitpunkt festgelegt - [ ] Testplan vorhanden - [ ] Rollback oder Backout geprüft - [ ] Kommunikationsbedarf bewertet - [ ] Genehmigungsweg klar --- **Checkliste Umsetzung** - [ ] Freigabe liegt vor - [ ] Voraussetzungen geprüft - [ ] Beteiligte informiert - [ ] Wartungsfenster bestätigt - [ ] Backup oder Sicherung geprüft - [ ] Umsetzungsschritte bekannt - [ ] Monitoring beobachtet - [ ] Testergebnis dokumentiert - [ ] Abweichungen dokumentiert - [ ] Rollback-Kriterien bekannt --- **Checkliste Nachbereitung** - [ ] Service funktioniert - [ ] abhängige Services geprüft - [ ] Incidents nach Change geprüft - [ ] Nutzen bewertet - [ ] Dokumentation aktualisiert - [ ] Knowledge Base aktualisiert - [ ] CMDB aktualisiert - [ ] Problem Record aktualisiert, falls relevant - [ ] Lessons Learned dokumentiert - [ ] Failed Change analysiert, falls aufgetreten --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker für Systemintegration führen im Alltag viele Changes durch oder bereiten sie vor. Beispiele: - Server patchen, - Firewall-Regeln ändern, - Benutzerrechte anpassen, - Zertifikate erneuern, - Dienste konfigurieren, - Monitoring erweitern, - Geräte austauschen, - Backups prüfen, - Automatisierungen erstellen. Wichtig ist dabei nicht nur die technische Umsetzung. Wichtig ist auch: - Auswirkungen verstehen, - Risiken einschätzen, - Abhängigkeiten prüfen, - sauber dokumentieren, - Benutzer informieren, - Rollback bedenken, - und aus Ergebnissen lernen. --- **Zusammenfassung** > Änderungsbedarf erkennen > ↓ > Change Request erstellen > ↓ > Nutzen, Risiko und Auswirkungen bewerten > ↓ > Change-Art bestimmen > ↓ > Freigabe oder Vorabgenehmigung prüfen > ↓ > Umsetzung planen > ↓ > Benutzer und Stakeholder informieren > ↓ > Change kontrolliert durchführen > ↓ > Ergebnis testen > ↓ > Dokumentation, Knowledge und CMDB aktualisieren > ↓ > Lessons Learned übernehmen --- **Merksätze** > Change Enablement verhindert nicht Veränderung, sondern ermöglicht sichere Veränderung. > Jede Änderung kann Nutzen und Risiko erzeugen. > Ein kleiner technischer Change kann große geschäftliche Auswirkungen haben. > Rollback muss vor der Umsetzung bedacht werden. > Emergency Changes sind kein Ersatz für schlechte Planung. > Ein Change ist erst erfolgreich, wenn der gewünschte Nutzen erreicht wurde. --- **Verwandte Seiten** - 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management - 5.2 Change-Typen und Risikobewertung - 5.3 Genehmigung, Planung und Umsetzung von Changes - 5.4 Release Management und Deployment Management - 5.5 Change-Erfolg messen und Continual Improvement - Incident Management - Problem Management - Knowledge Management - Service Configuration Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Change-Arten, - Checklisten, - Ablaufbeispiele, - Rollenhinweise, - Risikofragen, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Change-Request-Vorlage, - Genehmigungsmatrix, - CAB-Struktur, - Wartungsfensterregel, - Rollback-Vorlage, - oder Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Service Levels, - Sicherheitsanforderungen, - Organisation, - Lieferanten, - Change-Modell, - Datenqualität, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 5.2 Change-Typen und Risikobewertung > **Kurz erklärt** > > Nicht jede Änderung besitzt dasselbe Risiko. > > Change Enablement unterscheidet deshalb verschiedene Change-Typen und bewertet Änderungen nach Risiko, Auswirkung, Dringlichkeit und Standardisierbarkeit. > > Ziel ist, einfache und risikoarme Änderungen schnell durchführen zu können, während kritische Änderungen sorgfältig geplant und kontrolliert werden. --- **Warum Change-Typen wichtig sind** Eine kleine Standardänderung sollte nicht denselben Aufwand verursachen wie eine kritische Produktionsumstellung. Beispiele: - Passwort eines Testkontos zurücksetzen, - Standardsoftware installieren, - Firewall-Regel in Produktion ändern, - Datenbankmigration durchführen, - Sicherheitsupdate wegen aktiver Schwachstelle einspielen, - zentrale Authentifizierung umstellen. Diese Änderungen unterscheiden sich stark in: - Risiko, - Auswirkung, - Dringlichkeit, - Wiederholbarkeit, - Genehmigungsbedarf, - Testaufwand, - Kommunikationsbedarf, - Rollback-Möglichkeit. Change-Typen helfen dabei, den passenden Umgang mit einer Änderung festzulegen. --- **Grundidee der Change-Klassifizierung** Eine Organisation sollte festlegen: - welche Change-Typen verwendet werden, - welche Kriterien dafür gelten, - wer entscheiden darf, - welche Genehmigung notwendig ist, - welche Dokumentation erwartet wird, - welche Tests erforderlich sind, - wann Kommunikation notwendig ist, - und wie der Erfolg geprüft wird. ITIL schreibt keine für alle Organisationen identische Change-Matrix vor. Die Einteilung muss zur Organisation, zu den Services und zu den Risiken passen. --- **Typische Change-Typen** Viele Organisationen unterscheiden mindestens: | Change-Typ | Kurzbeschreibung | |---|---| | **Standard Change** | vorab bewertete, wiederholbare und risikoarme Änderung | | **Normal Change** | Änderung mit individueller Bewertung, Planung und Genehmigung | | **Emergency Change** | dringende Änderung zur Abwehr akuter Schäden oder zur schnellen Wiederherstellung | | **Major Change** | besonders umfangreiche, geschäftskritische oder risikoreiche Änderung | | **Minor Change** | kleine Änderung mit begrenzter Auswirkung | | **Routine Change** | regelmäßig vorkommende Änderung nach definiertem Ablauf | Nicht jede Organisation verwendet alle Begriffe. Wichtig ist, dass die Begriffe intern eindeutig definiert sind. --- **Standard Change** Ein Standard Change ist eine Änderung, die bereits vorab geprüft und genehmigt wurde. Typische Merkmale: - wiederholt sich häufig, - besitzt geringes Risiko, - Ablauf ist dokumentiert, - Auswirkungen sind bekannt, - Umsetzung ist standardisiert, - Genehmigung ist bereits grundsätzlich erteilt, - Rollen und Schritte sind klar, - Erfolg ist leicht prüfbar. Beispiele: - Standardsoftware aus genehmigtem Katalog installieren, - Benutzer in eine genehmigte Standardgruppe aufnehmen, - Standardarbeitsplatz bereitstellen, - neues Standard-Monitoring für einen Server aktivieren, - Zertifikat nach geprüftem Runbook erneuern, - Standarddrucker einrichten. Ein Standard Change ist nicht ungeprüft. Er wurde nur bereits vorab bewertet. --- **Normal Change** Ein Normal Change wird individuell bewertet, geplant und genehmigt. Typische Merkmale: - nicht vollständig standardisiert, - Risiko muss bewertet werden, - Auswirkungen müssen geprüft werden, - Genehmigung ist erforderlich, - Umsetzung muss geplant werden, - Tests und Rollback müssen betrachtet werden. Beispiele: - Update einer produktiven Anwendung, - Änderung einer Firewall-Regel, - Datenbankänderung, - Umstellung eines Servers, - Anpassung einer Schnittstelle, - Änderung an einem produktiven Netzwerksegment, - Einführung eines neuen Tools. Normal Changes benötigen je nach Risiko unterschiedlich viel Prüfung. --- **Emergency Change** Ein Emergency Change ist eine dringende Änderung, die wegen eines akuten Risikos oder Schadens schnell durchgeführt werden muss. Typische Auslöser: - kritischer Service ist ausgefallen, - Sicherheitslücke wird aktiv ausgenutzt, - Datenverlust droht, - Major Incident benötigt sofortige technische Maßnahme, - kein sicherer Workaround ist verfügbar, - dringende Wiederherstellung ist notwendig. Beispiele: - kritischen Patch kurzfristig einspielen, - fehlerhafte Konfiguration sofort zurückrollen, - abgelaufenes Zertifikat bei Produktionsausfall erneuern, - kompromittierten Zugang sperren, - DNS oder Routing kurzfristig korrigieren. Emergency Changes dürfen nicht als Abkürzung für schlechte Planung genutzt werden. Auch unter Zeitdruck müssen Maßnahmen nachvollziehbar dokumentiert und nachträglich überprüft werden. --- **Major Change** Ein Major Change ist eine Änderung mit besonders hoher Auswirkung oder hohem Risiko. Beispiele: - neues Rechenzentrum anbinden, - zentrales Identity-System migrieren, - ERP-System aktualisieren, - Netzwerkarchitektur grundlegend ändern, - neue Cloud-Plattform einführen, - mehrere Standorte gleichzeitig umstellen, - kritische Datenbank migrieren. Typische Merkmale: - viele Stakeholder betroffen, - hoher Planungsaufwand, - mehrere Teams beteiligt, - umfangreiche Tests notwendig, - Kommunikationsplan erforderlich, - Rollback komplex oder nur eingeschränkt möglich, - Management-Entscheidung notwendig. Ein Major Change ist nicht automatisch ein Emergency Change. Er kann lange geplant sein und trotzdem sehr risikoreich sein. --- **Minor Change** Ein Minor Change ist eine kleinere Änderung mit begrenzter Auswirkung. Beispiele: - kleine Konfigurationsanpassung an einem nicht kritischen System, - Ergänzung einer Monitoringbeschreibung, - Anpassung eines Formularfelds, - Änderung eines nicht produktiven Testsystems, - kleinere Dokumentationsänderung. Auch kleine Changes können Risiken besitzen. Beispiel: Eine scheinbar kleine Firewall-Regel kann große Auswirkungen haben, wenn sie einen kritischen Service betrifft. --- **Change-Typen im Vergleich** | Kriterium | Standard Change | Normal Change | Emergency Change | |---|---|---|---| | Risiko | gering und vorab bewertet | individuell zu bewerten | häufig hoch oder zeitkritisch | | Dringlichkeit | planbar | planbar | akut | | Genehmigung | vorab genehmigt | je nach Risiko erforderlich | beschleunigt oder nachträglich ergänzt | | Ablauf | standardisiert | individuell geplant | schnell, aber kontrolliert | | Dokumentation | standardisiert | vollständig nach Bedarf | mindestens entscheidungsrelevant | | Beispiele | Standardsoftware | produktives Update | kritischer Sicherheitspatch | --- **Risikobewertung** Risikobewertung bedeutet, mögliche negative Folgen eines Changes vor der Umsetzung zu betrachten. Typische Fragen: - Was kann schiefgehen? - Welche Services wären betroffen? - Welche Benutzer oder Kunden wären betroffen? - Wie wahrscheinlich ist ein Fehler? - Wie schwer wären die Auswirkungen? - Wie gut ist der Change getestet? - Gibt es einen Rollback? - Gibt es ein Wartungsfenster? - Gibt es Abhängigkeiten? - Gibt es Sicherheits- oder Datenschutzrisiken? - Wer muss informiert werden? Risiko entsteht aus Wahrscheinlichkeit und Auswirkung. --- **Auswirkung bewerten** Die Auswirkung beschreibt, wie stark Benutzer, Services oder Geschäftsprozesse betroffen wären. Zu prüfen ist: - Ist ein geschäftskritischer Service betroffen? - Sind interne Benutzer betroffen? - Sind externe Kunden betroffen? - Sind mehrere Standorte betroffen? - Gibt es Auswirkungen auf Produktion, Verkauf, Abrechnung oder Support? - Können Daten verloren gehen? - Können Sicherheitsanforderungen verletzt werden? - Sind gesetzliche oder vertragliche Anforderungen betroffen? - Gibt es Abhängigkeiten zu anderen Services? Je größer die mögliche Auswirkung, desto sorgfältiger muss der Change gesteuert werden. --- **Wahrscheinlichkeit bewerten** Die Wahrscheinlichkeit beschreibt, wie wahrscheinlich ein Fehler bei der Änderung ist. Einflussfaktoren: - Komplexität der Änderung, - Erfahrung des Teams, - Qualität der Tests, - Reife des Runbooks, - Anzahl beteiligter Systeme, - Anzahl manueller Schritte, - bekannte Fehler, - Stabilität der Umgebung, - Lieferantenabhängigkeit, - Neuartigkeit der Änderung. Eine Änderung mit geringer Auswirkung, aber hoher Fehlerwahrscheinlichkeit kann trotzdem relevant sein. --- **Dringlichkeit bewerten** Nicht jede dringende Änderung ist automatisch ein Emergency Change. Zu prüfen ist: - Warum ist die Änderung dringend? - Gibt es einen akuten Schaden? - Droht ein Sicherheitsvorfall? - Läuft eine Frist ab? - Gibt es einen Workaround? - Kann die Änderung bis zum nächsten Wartungsfenster warten? - Wird die Dringlichkeit durch schlechte Planung verursacht? - Welche Risiken entstehen durch sofortige Umsetzung? Dringlichkeit darf nicht dazu führen, dass grundlegende Sicherheits- und Dokumentationspflichten ignoriert werden. --- **Nutzen bewerten** Neben Risiko und Dringlichkeit muss der Nutzen betrachtet werden. Möglicher Nutzen: - Incident dauerhaft beheben, - Sicherheitsrisiko reduzieren, - Performance verbessern, - Kosten senken, - Benutzererfahrung verbessern, - gesetzliche Anforderungen erfüllen, - technische Schulden reduzieren, - Stabilität erhöhen, - Automatisierung ermöglichen, - Betrieb vereinfachen. Ein Change kann sinnvoll sein, obwohl er Risiko besitzt. Entscheidend ist, ob Nutzen und Risiko bewusst bewertet wurden. --- **Typische Risikokriterien** | Kriterium | Beispiele | |---|---| | **Servicekritikalität** | produktiv, geschäftskritisch, Testsystem | | **Benutzerimpact** | einzelne Person, Team, Standort, Kunden | | **Technische Komplexität** | einfache Konfiguration, Migration, Architekturänderung | | **Rollback-Fähigkeit** | einfach, schwierig, nicht möglich | | **Testabdeckung** | vollständig getestet, teilweise getestet, nicht getestet | | **Sicherheitsbezug** | Berechtigungen, Firewall, Daten, Logging | | **Zeitpunkt** | Geschäftszeit, Wartungsfenster, Monatsabschluss | | **Abhängigkeiten** | Datenbank, Netzwerk, Identität, Lieferant | | **Erfahrung** | häufig durchgeführt, neu, einmalig | | **Kommunikationsbedarf** | keine Benutzerinfo, interne Info, Kundenkommunikation | --- **Einfache Risikomatrix** Eine einfache Matrix kann helfen. | Auswirkung | Wahrscheinlichkeit niedrig | Wahrscheinlichkeit mittel | Wahrscheinlichkeit hoch | |---|---:|---:|---:| | **hoch** | mittel | hoch | sehr hoch | | **mittel** | niedrig | mittel | hoch | | **niedrig** | niedrig | niedrig | mittel | Diese Matrix ist nur ein Beispiel. Die Organisation muss eigene Bewertungsstufen festlegen. --- **Beispiel für Change-Risikostufen** | Risikostufe | Bedeutung | |---|---| | **Niedrig** | begrenzte Auswirkung, gut getestet, einfacher Rollback | | **Mittel** | mehrere Benutzer oder wichtiger Service betroffen, Rollback möglich | | **Hoch** | kritischer Service, viele Benutzer, komplexe Änderung | | **Sehr hoch** | geschäftskritisch, schwieriger Rollback, erhebliche Sicherheits- oder Datenrisiken | Die Risikostufe beeinflusst: - Genehmigung, - Testtiefe, - Kommunikationsbedarf, - Wartungsfenster, - Dokumentationsumfang, - Beteiligung von Spezialisten, - Nachprüfung. --- **Change Authority passend wählen** Die Genehmigungsinstanz sollte zum Risiko passen. Beispiele: | Change | mögliche Change Authority | |---|---| | Standardsoftware installieren | vorab genehmigter Standardprozess | | kleine Konfigurationsänderung | Team Lead oder Service Owner | | produktives Anwendungsupdate | Change Manager oder Change Advisory Board | | sicherheitskritische Firewall-Regel | Informationssicherheit und Service Owner | | Emergency Security Patch | Emergency Change Authority | | große Plattformmigration | Management, Service Owner, Change Board | Nicht jede Änderung benötigt ein großes Gremium. Aber risikoreiche Änderungen brauchen ausreichend Perspektiven. --- **Wann ein Change Advisory Board sinnvoll ist** Ein Change Advisory Board kann sinnvoll sein, wenn: - mehrere Services betroffen sind, - mehrere Teams beteiligt sind, - hohes Risiko besteht, - der Rollback schwierig ist, - Benutzer oder Kunden informiert werden müssen, - Sicherheitsfragen bestehen, - Lieferanten beteiligt sind, - mehrere Changes zeitlich kollidieren, - oder Managemententscheidungen notwendig sind. Ein CAB sollte beraten und Risiken sichtbar machen. Es sollte nicht jede Routineänderung unnötig verzögern. --- **Emergency Change Authority** Für Emergency Changes kann eine kleinere, schnell erreichbare Entscheidungsgruppe sinnvoll sein. Mögliche Beteiligte: - Incident Manager, - Change Manager, - Service Owner, - Informationssicherheit, - verantwortliches Fachteam, - Management bei hohem Geschäftsrisiko. Wichtig ist: - Entscheidung dokumentieren, - Risiko akzeptieren oder begründen, - Umsetzung kontrollieren, - Ergebnis prüfen, - nachträgliches Review durchführen. --- **Standard Change richtig definieren** Ein Standard Change sollte nicht leichtfertig als Standard eingestuft werden. Vorab zu klären: - Ist der Ablauf wiederholbar? - Ist das Risiko niedrig? - Sind Auswirkungen bekannt? - Gibt es ein geprüftes Runbook? - Sind Berechtigungen klar? - Gibt es definierte Erfolgskriterien? - Gibt es Abbruchkriterien? - Wird die Ausführung protokolliert? - Wird der Standard regelmäßig überprüft? Wenn ein Standard Change häufig fehlschlägt, muss er neu bewertet werden. --- **Emergency Change Missbrauch vermeiden** Emergency Changes sollten nicht genutzt werden, nur weil: - ein Request zu spät gestellt wurde, - Planung vergessen wurde, - Genehmigung umgangen werden soll, - ein Team schneller arbeiten möchte, - normale Change-Zeiten als störend empfunden werden. Ungeeignet: > Wir machen daraus einen Emergency Change, damit wir keine Freigabe brauchen. Besser: > Es liegt kein akuter Schaden vor. Der Change wird als Normal Change mit beschleunigter Planung behandelt. --- **Risiko durch Nicht-Handeln** Nicht nur Durchführung kann riskant sein. Auch Nicht-Handeln kann Risiko erzeugen. Beispiele: - Sicherheitslücke bleibt offen, - Zertifikat läuft bald ab, - Speicher läuft voll, - instabile Version bleibt produktiv, - gesetzliche Frist wird verpasst, - Workaround belastet Betrieb dauerhaft, - bekannte Fehler erzeugen weitere Incidents. Eine gute Bewertung betrachtet deshalb: - Risiko des Changes, - Risiko des Nicht-Handelns, - Risiko einer Verzögerung, - Risiko des Workarounds. --- **Rollback und Backout in der Risikobewertung** Ein Change ist weniger riskant, wenn ein zuverlässiger Rollback möglich ist. Zu prüfen ist: - Kann die Änderung vollständig zurückgenommen werden? - Wie lange dauert der Rollback? - Sind Backups vorhanden? - Wurden Konfigurationen gesichert? - Werden Daten verändert? - Gibt es Abhängigkeiten? - Wer entscheidet über Abbruch? - Wann ist der späteste sichere Abbruchzeitpunkt? Wenn kein Rollback möglich ist, muss besonders sorgfältig getestet und kommuniziert werden. --- **Testumfang nach Risiko** Der Testumfang sollte zur Risikostufe passen. | Risiko | möglicher Testumfang | |---|---| | niedrig | Standardprüfung, kurzer Funktionstest | | mittel | Testsystem, Review, definierter Smoke Test | | hoch | ausführlicher Testplan, Abhängigkeitstest, Rollback-Test | | sehr hoch | Pilot, Lasttest, Sicherheitsprüfung, Managementfreigabe | Tests sollten nicht nur prüfen, ob die Änderung technisch durchgeführt wurde. Sie sollten prüfen, ob der Service danach wie erwartet nutzbar ist. --- **Kommunikationsbedarf nach Risiko** Je höher Risiko und Auswirkung, desto wichtiger wird Kommunikation. Zu informieren sind je nach Change: - betroffene Benutzer, - Service Desk, - Fachbereiche, - Management, - Lieferanten, - Informationssicherheit, - Kunden, - Bereitschaftsdienst. Inhalt der Kommunikation: - Was wird geändert? - Wann wird geändert? - Welche Auswirkungen sind möglich? - Gibt es eine Unterbrechung? - Was müssen Benutzer tun? - Wo gibt es Statusinformationen? - Wann gilt der Change als abgeschlossen? --- **Wartungsfenster bewerten** Ein Wartungsfenster sollte passend gewählt werden. Zu berücksichtigen sind: - Servicezeiten, - Geschäftsprozesse, - internationale Zeitzonen, - Monats- oder Jahresabschluss, - Produktionszeiten, - Kundenverkehr, - Backupfenster, - Lieferantenverfügbarkeit, - Bereitschaft, - Rollbackdauer. Ein technisch bequemes Wartungsfenster ist nicht automatisch geschäftlich sinnvoll. --- **Abhängigkeiten und Change-Kollisionen** Mehrere Changes können sich gegenseitig beeinflussen. Beispiele: - Netzwerkteam ändert Routing, während Anwendungsteam ein Deployment durchführt. - Datenbankwartung fällt mit Reporting-Lauf zusammen. - Cloud-Team ändert Identitätsdienst, während VPN-Client aktualisiert wird. - Backupfenster überschneidet sich mit Datenbankmigration. Change Enablement sollte prüfen: - Welche Changes laufen gleichzeitig? - Betreffen sie gleiche Services oder CIs? - Können sie sich gegenseitig beeinflussen? - Gibt es ein Change Freeze? - Muss eine Reihenfolge festgelegt werden? --- **Change Freeze** Ein Change Freeze ist ein Zeitraum, in dem Änderungen eingeschränkt werden. Beispiele: - Jahresabschluss, - kritische Verkaufsphase, - Produktionshochlauf, - Prüfung oder Audit, - große Migration, - Feiertagsgeschäft. Ein Change Freeze verhindert nicht zwingend jede Änderung. Emergency Changes oder wichtige Sicherheitsmaßnahmen können trotzdem notwendig sein. Dann muss besonders bewusst entschieden werden. --- **Sicherheitsrisiken bewerten** Besonders sorgfältig zu bewerten sind Changes an: - Firewall-Regeln, - Identitätsdiensten, - Administratorrechten, - MFA, - Logging, - Verschlüsselung, - Zertifikaten, - externen Schnittstellen, - Cloud-Berechtigungen, - Datenfreigaben, - Sicherheitssoftware. Fragen: - Werden neue Zugriffe eröffnet? - Werden Rechte erweitert? - Werden Schutzmaßnahmen deaktiviert? - Werden Logs reduziert? - Werden sensible Daten berührt? - Gibt es ein Prüf- oder Rezertifizierungsverfahren? --- **Datenschutz und Compliance** Manche Changes betreffen Datenschutz oder Compliance. Beispiele: - neue Datenverarbeitung, - neue Schnittstelle, - neue Cloud-Ablage, - geänderte Aufbewahrung, - geänderte Protokollierung, - Zugriff auf personenbezogene Daten, - Standortwechsel von Daten, - Einführung eines neuen Tools. Dann können zusätzliche Prüfungen erforderlich sein. Beispielsweise durch Datenschutz, Informationssicherheit, Compliance oder Rechtsabteilung. --- **Lieferantenrisiken** Bei Changes mit Lieferantenbezug zu prüfen: - Ist der Lieferant verfügbar? - Gibt es Support während des Wartungsfensters? - Gibt es Herstellerhinweise? - Ist die Version unterstützt? - Gibt es bekannte Fehler? - Wer führt welche Aufgabe aus? - Welche Eskalationswege gelten? - Welche SLA oder Verträge sind betroffen? - Wie wird das Ergebnis abgenommen? Auch externe Changes müssen intern nachvollziehbar gesteuert werden. --- **Change-Erfolgskriterien** Vor der Umsetzung sollte klar sein, wann ein Change erfolgreich ist. Beispiele: - Anwendung startet ohne Fehler, - Benutzer können sich anmelden, - Schnittstelle überträgt Daten korrekt, - Monitoring ist grün, - keine neuen Fehler in Logs, - Performance bleibt im Zielbereich, - Sicherheitsprüfung erfolgreich, - Service Desk erhält keine Störungswelle, - Fachbereich bestätigt Funktion. Ohne Erfolgskriterien ist die Nachprüfung unklar. --- **Failed Change und Lessons Learned** Ein Change kann fehlschlagen. Wichtig ist dann: - Auswirkungen begrenzen, - Rollback durchführen, falls erforderlich, - Benutzer informieren, - Incident oder Problem verknüpfen, - Ursache des Fehlschlags untersuchen, - Change-Modell verbessern, - Tests anpassen, - Dokumentation korrigieren. Ziel ist Lernen, nicht Schuldzuweisung. --- **Praxisbeispiel: Standard Change** **Änderung** Standardsoftware aus genehmigtem Katalog wird installiert. **Bewertung** - Ablauf ist bekannt, - Software ist geprüft, - Zielgruppe ist definiert, - Risiko ist niedrig, - Installation ist automatisiert, - Rollback ist möglich. **Umgang** Der Change kann als Standard Change über das Serviceportal ausgeführt werden. --- **Praxisbeispiel: Normal Change** **Änderung** Eine produktive Fachanwendung erhält ein Versionsupdate. **Bewertung** - mehrere Fachbereiche betroffen, - Testsystem vorhanden, - Wartungsfenster notwendig, - Rollback möglich, aber zeitaufwendig, - Benutzerkommunikation erforderlich. **Umgang** Der Change wird geplant, getestet, genehmigt und nach Umsetzung geprüft. --- **Praxisbeispiel: Emergency Change** **Änderung** Eine aktiv ausgenutzte Sicherheitslücke muss kurzfristig geschlossen werden. **Bewertung** - Risiko des Nicht-Handelns sehr hoch, - Testzeit begrenzt, - Produktionssystem betroffen, - Management und Informationssicherheit müssen eingebunden werden. **Umgang** Emergency Change wird kontrolliert durchgeführt, dokumentiert und nachträglich reviewed. --- **Praxisbeispiel: Falsch eingestufter Change** **Situation** Eine Firewall-Regel wird als kleine Routineänderung behandelt. **Problem** Die Regel betrifft eine zentrale Schnittstelle zur Warenwirtschaft. Nach Umsetzung kann der Versand keine Aufträge mehr übertragen. **Lerneffekt** Der Change war technisch klein, aber geschäftlich kritisch. Künftig werden Firewall-Changes nach betroffenen Services und Geschäftsprozessen bewertet, nicht nur nach technischem Aufwand. --- **Typische Fehler** **Fehler 1** Jede Änderung wird gleich behandelt. --- **Fehler 2** Ein riskanter Change wird fälschlich als Standard Change eingestuft. --- **Fehler 3** Emergency Change wird als Abkürzung genutzt. --- **Fehler 4** Nur technische Risiken werden bewertet. --- **Fehler 5** Risiko des Nicht-Handelns wird ignoriert. --- **Fehler 6** Rollback wird erst während der Störung überlegt. --- **Fehler 7** Tests passen nicht zum Risiko. --- **Fehler 8** Benutzer und Service Desk werden nicht informiert. --- **Fehler 9** Abhängigkeiten und parallele Changes werden nicht geprüft. --- **Fehler 10** Sicherheits- und Datenschutzrisiken werden zu spät erkannt. --- **Fehler 11** Change-Erfolgskriterien fehlen. --- **Fehler 12** Failed Changes werden nicht ausgewertet. --- **Checkliste Change-Typ bestimmen** - [ ] Ist die Änderung wiederholbar? - [ ] Ist der Ablauf dokumentiert? - [ ] Ist das Risiko vorab bewertet? - [ ] Ist die Änderung bereits vorab genehmigt? - [ ] Gibt es akuten Zeitdruck? - [ ] Droht Schaden bei Verzögerung? - [ ] Ist ein produktiver Service betroffen? - [ ] Sind mehrere Teams beteiligt? - [ ] Ist ein Rollback möglich? - [ ] Gibt es Sicherheits- oder Datenschutzbezug? - [ ] Muss ein Service Owner entscheiden? - [ ] Passt Standard, Normal oder Emergency Change? --- **Checkliste Risikobewertung** - [ ] betroffener Service bekannt - [ ] betroffene CIs bekannt - [ ] Benutzer- oder Kundenimpact bewertet - [ ] geschäftliche Auswirkungen bewertet - [ ] technische Komplexität bewertet - [ ] Sicherheitsrisiken geprüft - [ ] Datenschutz oder Compliance geprüft - [ ] Abhängigkeiten geprüft - [ ] parallele Changes geprüft - [ ] Testumfang festgelegt - [ ] Rollback oder Backout geprüft - [ ] Kommunikationsbedarf bewertet - [ ] Risiko des Nicht-Handelns bewertet --- **Checkliste Emergency Change** - [ ] akuter Schaden oder hohes Risiko liegt vor - [ ] Grund für Dringlichkeit dokumentiert - [ ] Entscheidungsträger eingebunden - [ ] Risiko bewertet - [ ] Mindesttest durchgeführt, soweit möglich - [ ] Rollback geprüft - [ ] Umsetzung dokumentiert - [ ] Service Desk informiert - [ ] Benutzer oder Stakeholder informiert, falls notwendig - [ ] Ergebnis geprüft - [ ] nachträgliches Review geplant - [ ] Folgeproblem oder Improvement erstellt, falls nötig --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker müssen Change-Typen und Risiken praktisch einschätzen können. Im Arbeitsalltag bedeutet das: - nicht jede Änderung sofort produktiv durchführen, - technische und geschäftliche Auswirkungen bedenken, - betroffene Services und Abhängigkeiten prüfen, - Rollback vor der Umsetzung planen, - Tests passend zum Risiko durchführen, - Service Desk und Benutzer informieren, - Changes sauber dokumentieren, - und aus fehlgeschlagenen Changes lernen. Gerade kleine technische Änderungen können große Auswirkungen haben, wenn sie einen kritischen Service betreffen. --- **Zusammenfassung** > Änderung erkennen > ↓ > Change-Typ bestimmen > ↓ > Auswirkung und Wahrscheinlichkeit bewerten > ↓ > Risiko des Changes und Risiko des Nicht-Handelns vergleichen > ↓ > Test, Rollback und Kommunikation planen > ↓ > passende Change Authority einbinden > ↓ > Änderung kontrolliert durchführen > ↓ > Erfolg prüfen > ↓ > Lessons Learned übernehmen --- **Merksätze** > Nicht jede Änderung benötigt denselben Prozessaufwand. > Ein Standard Change ist vorab bewertet, nicht ungeprüft. > Ein Emergency Change ist kein Ersatz für schlechte Planung. > Technisch klein bedeutet nicht automatisch risikoarm. > Risiko entsteht aus Auswirkung, Wahrscheinlichkeit und Kontext. > Auch Nicht-Handeln kann riskant sein. > Der Change-Typ muss zur tatsächlichen Auswirkung passen. --- **Verwandte Seiten** - 5.1 Change Enablement – Ziele, Begriffe und Abgrenzung - 5.3 Genehmigung, Planung und Umsetzung von Changes - 5.4 Release Management und Deployment Management - 5.5 Change-Erfolg messen und Continual Improvement - Incident Management - Problem Management - Service Configuration Management - Information Security Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Information Security Management - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Change-Typen, - Risikokriterien, - Matrizen, - Checklisten, - Praxisbeispiele, - und Bewertungsfragen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Change-Typen-Matrix, - Risikoskala, - Genehmigungsmatrix, - CAB-Pflicht, - Testvorgabe, - oder Emergency-Change-Struktur für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisation, - Service Levels, - Sicherheitsanforderungen, - Change-Modell, - Lieferanten, - Datenqualität, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 5.3 Genehmigung, Planung und Umsetzung von Changes > **Kurz erklärt** > > Ein Change sollte nicht nur technisch durchgeführt werden. > > Vor der Umsetzung müssen Ziel, Risiko, Auswirkungen, Verantwortlichkeiten, Freigaben, Kommunikation, Tests und Rückfallmöglichkeiten geklärt sein. > > Gute Change-Planung sorgt dafür, dass Änderungen kontrolliert, nachvollziehbar und mit möglichst geringem Risiko für laufende Services umgesetzt werden. --- **Warum Genehmigung und Planung wichtig sind** Viele Störungen entstehen nicht durch die Änderung selbst, sondern durch unklare Vorbereitung. Typische Ursachen: - Auswirkungen wurden nicht vollständig geprüft. - Abhängigkeiten waren unbekannt. - Benutzer wurden nicht informiert. - Tests waren unzureichend. - Rollback war nicht möglich. - Zuständigkeiten waren unklar. - mehrere Changes kollidierten zeitlich. - Dokumentation wurde nicht aktualisiert. - Service Desk wusste nichts vom Change. Change Enablement soll solche Risiken reduzieren. --- **Grundprinzip** Ein Change sollte nur dann umgesetzt werden, wenn mindestens klar ist: - was geändert wird, - warum es geändert wird, - welcher Service betroffen ist, - welche Risiken bestehen, - wer zuständig ist, - wann die Umsetzung erfolgt, - wie getestet wird, - wie zurückgerollt werden kann, - wer informiert werden muss, - und woran Erfolg erkannt wird. Je höher Risiko und Auswirkung, desto gründlicher müssen Planung und Genehmigung sein. --- **Typischer Ablauf** Änderungsbedarf erkennen ↓ Change Request erstellen ↓ Risiko und Auswirkung bewerten ↓ Change-Typ bestimmen ↓ Genehmigung oder Vorabgenehmigung prüfen ↓ Umsetzung planen ↓ Kommunikation vorbereiten ↓ Change durchführen ↓ Ergebnis testen ↓ Dokumentation aktualisieren ↓ Change abschließen oder nachbereiten Dieser Ablauf ist ein Praxisbeispiel. Die konkrete Umsetzung hängt von Organisation, Risiko und Change-Modell ab. --- **Change Request erstellen** Ein Change Request beschreibt die gewünschte Änderung. Typische Inhalte: - Titel, - Beschreibung, - Grund der Änderung, - erwarteter Nutzen, - betroffener Service, - betroffene Systeme oder Configuration Items, - Change-Typ, - Risiko, - Auswirkungen, - geplanter Zeitpunkt, - verantwortliche Person oder Gruppe, - Umsetzungsplan, - Testplan, - Rollback oder Backout, - Kommunikationsbedarf, - Genehmigungsbedarf, - Abhängigkeiten, - Erfolgskriterien. Ein Change Request sollte so formuliert sein, dass eine andere Person die Änderung bewerten kann. --- **Gute und schlechte Change-Beschreibung** Ungeeignet: > Update Server. Besser: > Update des produktiven Webservers APP-WEB-01 von Version 2.4.57 auf 2.4.60, um bekannte Sicherheitslücken zu schließen. Betroffen ist der interne Service „Mitarbeiterportal“. Umsetzung im Wartungsfenster am 14.08.2026 von 20:00 bis 21:00 Uhr. Rollback durch Wiederherstellung der vorherigen Paketversion und Konfiguration möglich. Eine gute Beschreibung macht Ziel, Umfang und Risiko sichtbar. --- **Genehmigung** Genehmigung bedeutet, dass eine berechtigte Person oder Gruppe der Umsetzung zustimmt. Dabei wird geprüft: - Ist der Change sinnvoll? - Ist der Nutzen nachvollziehbar? - Sind Risiken bekannt? - Sind Auswirkungen bewertet? - Ist der Zeitpunkt geeignet? - Sind Tests ausreichend? - Ist ein Rollback möglich? - Sind Stakeholder informiert? - Sind Ressourcen verfügbar? - Gibt es Konflikte mit anderen Changes? Genehmigung ist keine reine Formalität. Sie soll eine bewusste Entscheidung ermöglichen. --- **Change Authority** Die Change Authority ist die Person oder Gruppe, die eine Änderung bewertet oder genehmigt. Mögliche Change Authorities: - Service Owner, - Change Manager, - technisches Fachteam, - Produktteam, - Informationssicherheit, - Management, - Change Advisory Board, - Emergency Change Authority. Die passende Change Authority hängt ab von: - Risiko, - Auswirkung, - Change-Typ, - betroffenen Services, - Sicherheitsbezug, - Kosten, - und Dringlichkeit. Nicht jeder Change benötigt dieselbe Genehmigungsstufe. --- **Genehmigung nach Risiko** | Risiko | mögliche Genehmigung | |---|---| | niedrig | vorab genehmigter Standardprozess | | mittel | Team Lead oder Service Owner | | hoch | Change Manager, Service Owner oder CAB | | sehr hoch | Management, Informationssicherheit, CAB oder spezielle Change Authority | | akut kritisch | Emergency Change Authority | Diese Tabelle ist ein Beispiel. Die Organisation muss ihre Genehmigungswege selbst festlegen. --- **Change Advisory Board** Ein Change Advisory Board kann bei umfangreichen oder risikoreichen Changes unterstützen. Mögliche Aufgaben: - Risiken bewerten, - Abhängigkeiten erkennen, - Change-Kollisionen vermeiden, - Fachbereiche einbinden, - Kommunikationsbedarf prüfen, - Rollback bewerten, - Zeitplanung abstimmen, - Entscheidung vorbereiten. Ein CAB sollte nicht jede kleine Änderung ausbremsen. Es ist besonders dann sinnvoll, wenn mehrere Perspektiven benötigt werden. --- **Emergency-Genehmigung** Bei Emergency Changes muss oft schneller entschieden werden. Trotzdem sollten mindestens geklärt werden: - Warum ist die Änderung dringend? - Welcher Schaden droht? - Welche Services sind betroffen? - Welche Risiken entstehen durch Umsetzung? - Welche Risiken entstehen durch Nicht-Handeln? - Wer trifft die Entscheidung? - Wie wird dokumentiert? - Wie wird nachträglich geprüft? Auch ein Emergency Change braucht Kontrolle. Nur der Genehmigungsweg ist beschleunigt. --- **Planung der Umsetzung** Ein Umsetzungsplan beschreibt, wie der Change praktisch durchgeführt wird. Er sollte enthalten: - Vorbereitungsschritte, - Reihenfolge der Umsetzung, - beteiligte Personen, - benötigte Zugänge, - benötigte Werkzeuge, - Startzeit, - erwartete Dauer, - Prüfschritte, - Abbruchkriterien, - Rollback-Schritte, - Kommunikationspunkte, - Dokumentationshinweise. Je kritischer der Change, desto genauer sollte der Plan sein. --- **Schrittfolge definieren** Eine gute Schrittfolge vermeidet Unsicherheit während der Umsetzung. Beispiel: 1. aktuelles Backup prüfen 2. Konfiguration exportieren 3. Benutzerinformation bestätigen 4. Dienst in Wartungsmodus setzen 5. Update installieren 6. Dienst starten 7. Funktionstest durchführen 8. Monitoring prüfen 9. Fachbereichstest bestätigen 10. Wartungsmodus beenden 11. Abschlussmeldung senden 12. Dokumentation aktualisieren Wichtig ist, dass jeder Schritt ein klares Ergebnis besitzt. --- **Vorbereitung** Vor der Umsetzung sollte geprüft werden: - Liegt die Genehmigung vor? - Ist der Zeitpunkt bestätigt? - Sind alle Beteiligten verfügbar? - Ist der Service Desk informiert? - Sind Backups oder Konfigurationssicherungen vorhanden? - Sind Zugangsdaten und Berechtigungen verfügbar? - Sind Installationsdateien oder Pakete geprüft? - Ist der Rollback vorbereitet? - Ist Monitoring aktiv? - Sind Kommunikationsvorlagen bereit? Eine gute Vorbereitung verhindert Hektik während des Change-Fensters. --- **Wartungsfenster** Ein Wartungsfenster ist ein geplanter Zeitraum für Änderungen. Zu berücksichtigen sind: - Servicezeiten, - Geschäftsprozesse, - Benutzergruppen, - internationale Zeitzonen, - Produktionszeiten, - Backupfenster, - Lieferantenverfügbarkeit, - Bereitschaftsdienst, - Rollbackdauer, - Kommunikationsbedarf. Ein Wartungsfenster sollte nicht nur technisch bequem sein. Es muss zur Nutzung des Services passen. --- **Kommunikation vor dem Change** Betroffene Personen sollten rechtzeitig informiert werden. Je nach Change können beteiligt sein: - Benutzer, - Service Desk, - Fachbereiche, - Service Owner, - Management, - Lieferanten, - Informationssicherheit, - Bereitschaftsdienst. Eine Vorabinformation kann enthalten: - was geändert wird, - warum es geändert wird, - wann es passiert, - welche Auswirkungen erwartet werden, - welche Services betroffen sind, - ob eine Unterbrechung entsteht, - was Benutzer beachten müssen, - wo Statusinformationen verfügbar sind, - wann eine Abschlussmeldung erfolgt. --- **Beispiel einer Benutzerinformation** > Am 14.08.2026 zwischen 20:00 und 21:00 Uhr wird das Mitarbeiterportal aktualisiert. In diesem Zeitraum kann der Zugriff kurzzeitig unterbrochen sein. Bitte speichern Sie offene Eingaben vorher. Nach Abschluss informieren wir über die erfolgreiche Umsetzung. Die Kommunikation sollte verständlich und nicht unnötig technisch sein. --- **Service Desk informieren** Der Service Desk muss vor wichtigen Changes wissen: - welcher Service betroffen ist, - wann der Change stattfindet, - welche Symptome normal sind, - welche Meldungen zu erwarten sind, - welche Benutzer betroffen sein können, - welche Statusmeldung freigegeben ist, - wann eskaliert werden muss, - wer Ansprechpartner ist. Sonst entstehen unnötige Incidents und Rückfragen. --- **Tests planen** Ein Testplan beschreibt, wie geprüft wird, ob der Change erfolgreich war. Mögliche Tests: - technischer Funktionstest, - Anmeldung, - Datenzugriff, - Schnittstellenprüfung, - Druck oder Export, - Performanceprüfung, - Sicherheitsprüfung, - Monitoringprüfung, - Fachbereichstest, - Smoke Test. Der Test muss zum Risiko des Changes passen. Bei kritischen Services reicht ein oberflächlicher Test oft nicht aus. --- **Smoke Test** Ein Smoke Test ist eine kurze Grundprüfung nach der Umsetzung. Beispiele: - Service startet, - Login funktioniert, - Startseite lädt, - wichtige Funktion ist erreichbar, - keine kritischen Fehlermeldungen im Monitoring, - Schnittstelle antwortet. Ein Smoke Test ersetzt keine vollständige Abnahme. Er hilft aber, grobe Fehler sofort zu erkennen. --- **Rollback und Backout planen** Rollback oder Backout bedeutet, den Change zurückzunehmen oder in einen sicheren Zustand zu bringen. Zu klären ist: - Wie wird der vorherige Zustand wiederhergestellt? - Welche Sicherungen werden benötigt? - Wie lange dauert der Rollback? - Welche Daten können betroffen sein? - Wer entscheidet über Rollback? - Wann muss abgebrochen werden? - Welche Kommunikation erfolgt bei Rollback? - Wird ein Incident erstellt? - Welche Folgearbeiten sind notwendig? Ein Rollback muss vor der Umsetzung geplant werden, nicht erst während der Störung. --- **Rollback ist nicht immer möglich** Manche Changes lassen sich nicht einfach zurückrollen. Beispiele: - Datenbankmigration, - Datenlöschung, - Änderung von Datenformaten, - externe Schnittstellenumstellung, - Cloud-Ressourcenänderung, - Massenänderung von Berechtigungen. Wenn kein einfacher Rollback möglich ist, müssen Risiko, Testtiefe und Kommunikationsplanung besonders sorgfältig sein. --- **Abbruchkriterien** Abbruchkriterien legen fest, wann ein Change gestoppt oder zurückgerollt wird. Beispiele: - Installation überschreitet geplante Dauer, - kritischer Test schlägt fehl, - Monitoring zeigt schwere Fehler, - Datenbankmigration bricht ab, - Rollback-Zeitfenster wird knapp, - Fachbereich bestätigt Kernfunktion nicht, - Sicherheitsprüfung schlägt fehl. Abbruchkriterien verhindern, dass ein Change trotz deutlicher Warnzeichen weitergeführt wird. --- **Durchführung** Während der Durchführung sollte konzentriert und nachvollziehbar gearbeitet werden. Wichtig: - nur freigegebene Schritte durchführen, - Änderungen dokumentieren, - Abweichungen festhalten, - nicht mehrere ungeplante Änderungen gleichzeitig durchführen, - Monitoring beobachten, - Kommunikationspunkte einhalten, - bei Problemen rechtzeitig eskalieren, - Abbruchkriterien beachten. Ungeeignet: > Während des Updates ändern wir zusätzlich noch ein paar andere Einstellungen. Besser: > Nur der freigegebene Change wird umgesetzt. Zusätzliche Auffälligkeiten werden dokumentiert und separat bewertet. --- **Umgang mit Abweichungen** Während eines Changes können unerwartete Situationen auftreten. Dann sollte geklärt werden: - Ist die Abweichung kritisch? - Ist sie innerhalb der Freigabe abgedeckt? - Erhöht sie das Risiko? - Muss eine Entscheidung eingeholt werden? - Muss der Change abgebrochen werden? - Muss ein Incident erstellt werden? - Muss die Kommunikation angepasst werden? Nicht jede Abweichung darf spontan gelöst werden. Sonst entsteht ein ungeplanter Change im Change. --- **Monitoring während des Changes** Monitoring sollte aktiv beobachtet werden. Zu prüfen sind: - Verfügbarkeit, - Antwortzeiten, - Fehlerraten, - CPU, - Arbeitsspeicher, - Speicherplatz, - Datenbankstatus, - Schnittstellen, - Logs, - Sicherheitsmeldungen, - Benutzeranmeldungen. Monitoring zeigt nicht alles. Es ergänzt technische und fachliche Tests. --- **Kommunikation während des Changes** Bei längeren oder kritischen Changes sollten Zwischenstände kommuniziert werden. Beispiele: - Change gestartet, - Wartungsfenster läuft, - technische Umsetzung abgeschlossen, - Tests laufen, - Verzögerung aufgetreten, - Rollback eingeleitet, - Change erfolgreich abgeschlossen. Kommunikation verhindert Unsicherheit. Sie muss aber sachlich und abgestimmt bleiben. --- **Erfolg prüfen** Nach der Umsetzung sollte geprüft werden: - Wurde die Änderung vollständig umgesetzt? - Funktioniert der betroffene Service? - Funktionieren abhängige Services? - Sind Kernfunktionen nutzbar? - Sind Benutzer oder Fachbereich arbeitsfähig? - Gibt es neue Incidents? - Ist Monitoring unauffällig? - Sind Logs unauffällig? - Wurde der erwartete Nutzen erreicht? - Muss Dokumentation aktualisiert werden? Ein Change ist nicht automatisch erfolgreich, nur weil die technische Tätigkeit abgeschlossen ist. --- **Fachliche Abnahme** Bei wichtigen Services kann eine fachliche Abnahme erforderlich sein. Beispiele: - Fachbereich testet Kernfunktion, - Key User bestätigt Arbeitsablauf, - Produktteam prüft Schnittstelle, - Service Owner bestätigt Nutzbarkeit, - Informationssicherheit bestätigt Schutzanforderung. Technische Erreichbarkeit allein genügt nicht immer. Wichtig ist, ob der Service aus Sicht der Benutzer funktioniert. --- **Abschlussmeldung** Nach erfolgreicher Umsetzung sollte eine Abschlussmeldung erfolgen. Sie kann enthalten: - Change wurde abgeschlossen, - betroffener Service ist wieder verfügbar, - bekannte Einschränkungen, - nächste Schritte, - Ansprechpartner bei Problemen. Beispiel: > Das Update des Mitarbeiterportals wurde erfolgreich abgeschlossen. Der Service ist wieder verfügbar. Bitte melden Sie Auffälligkeiten über das Serviceportal unter Angabe des Services „Mitarbeiterportal“. --- **Dokumentation aktualisieren** Nach dem Change müssen relevante Informationen aktualisiert werden. Mögliche Inhalte: - Change Record, - CMDB, - Servicekatalog, - Knowledge Base, - Runbooks, - Betriebshandbuch, - Monitoringdokumentation, - Known Errors, - Problem Records, - Installationsdokumentation, - Sicherheitsdokumentation. Ein Change ist unvollständig, wenn die technische Umgebung geändert wurde, die Dokumentation aber den alten Zustand zeigt. --- **CMDB aktualisieren** Wenn Configuration Items betroffen sind, sollte die CMDB aktualisiert werden. Beispiele: - neue Version, - neue Beziehung, - geänderte IP-Adresse, - geänderter Standort, - neuer Owner, - ausgetauschte Hardware, - neuer Lieferant, - geänderte Schnittstelle. Fehlende CMDB-Aktualisierung kann spätere Incidents, Problems und Changes erschweren. --- **Knowledge Base aktualisieren** Nach einem Change können Knowledge-Artikel falsch oder veraltet sein. Zu prüfen ist: - Stimmen Menüpfade noch? - Haben sich Screenshots geändert? - Gilt ein Workaround noch? - Muss ein Known Error geschlossen werden? - Müssen Service-Desk-Anleitungen angepasst werden? - Müssen Benutzerhinweise aktualisiert werden? - Gibt es neue Fehlermeldungen? - Gibt es neue Eskalationswege? Wissen muss zum aktuellen Servicezustand passen. --- **Problem Record aktualisieren** Wenn ein Change eine dauerhafte Lösung für ein Problem war, muss der Problem Record aktualisiert werden. Zu prüfen ist: - wurde die Ursache beseitigt? - funktioniert der Workaround noch oder wird er entfernt? - ist der Known Error noch gültig? - sind zugehörige Incidents zurückgegangen? - muss die Wirksamkeit noch beobachtet werden? - gibt es verbleibende Risiken? - kann das Problem geschlossen werden? Ein Problem sollte nicht automatisch geschlossen werden, nur weil ein Change umgesetzt wurde. --- **Failed Change** Ein Change gilt als fehlgeschlagen, wenn: - die Änderung nicht umgesetzt werden konnte, - ein Rollback notwendig war, - neue Incidents entstanden, - Servicequalität schlechter wurde, - Erfolgskriterien nicht erreicht wurden, - unerwartete Risiken auftraten, - oder der Nutzen nicht erreicht wurde. Ein Failed Change sollte nachvollziehbar ausgewertet werden. Ziel ist Verbesserung, nicht Schuldzuweisung. --- **Post Implementation Review** Ein Post Implementation Review prüft nach der Umsetzung, wie der Change verlaufen ist. Mögliche Fragen: - Wurde der Change wie geplant durchgeführt? - Waren Risiko und Auswirkung korrekt bewertet? - Waren Tests ausreichend? - War Kommunikation rechtzeitig und verständlich? - Gab es unerwartete Incidents? - Hat der Rollback funktioniert oder wäre er realistisch gewesen? - Wurde der erwartete Nutzen erreicht? - Was sollte beim nächsten Mal verbessert werden? Nicht jeder kleine Standard Change benötigt ein ausführliches Review. Bei risikoreichen oder fehlgeschlagenen Changes ist es besonders wichtig. --- **Praxisbeispiel: Anwendungsupdate** **Change** Produktive Fachanwendung wird aktualisiert. **Planung** - betroffener Service wird dokumentiert, - Wartungsfenster wird festgelegt, - Fachbereich wird informiert, - Backup wird geprüft, - Testsystem wird verwendet, - Rollback wird vorbereitet, - Smoke Test wird definiert. **Umsetzung** Update wird im Wartungsfenster durchgeführt. **Prüfung** - Anwendung startet, - Benutzeranmeldung funktioniert, - Kernprozess wird vom Fachbereich getestet, - Monitoring ist unauffällig. **Abschluss** Dokumentation und Knowledge-Artikel werden aktualisiert. --- **Praxisbeispiel: Firewall-Regel** **Change** Neue Verbindung zwischen Anwendung und Partner-API wird freigeschaltet. **Planung** - Quell- und Zielsysteme prüfen, - Port und Protokoll dokumentieren, - Sicherheitsfreigabe einholen, - betroffene Services identifizieren, - Testfall definieren, - Rollback durch Entfernen der Regel beschreiben. **Umsetzung** Firewall-Regel wird im genehmigten Zeitfenster gesetzt. **Prüfung** Schnittstelle überträgt Testdaten korrekt. Logs zeigen keine unerwarteten Verbindungen. --- **Praxisbeispiel: Rollback notwendig** **Change** Datenbanktreiber einer Anwendung wird aktualisiert. **Problem** Nach dem Update schlägt der Export von Berichten fehl. **Entscheidung** Abbruchkriterium ist erfüllt. Rollback wird eingeleitet. **Nachbereitung** - Incident wird verknüpft, - Change als fehlgeschlagen dokumentiert, - Ursache wird untersucht, - Testplan wird erweitert, - neuer Change wird vorbereitet. --- **Typische Fehler** **Fehler 1** Change wird ohne klaren Plan umgesetzt. --- **Fehler 2** Genehmigung wird als reine Formalität behandelt. --- **Fehler 3** Service Desk wird nicht informiert. --- **Fehler 4** Benutzer erfahren erst durch eine Störung vom Change. --- **Fehler 5** Rollback ist nicht vorbereitet. --- **Fehler 6** Tests prüfen nur Technik, nicht Benutzer-Outcome. --- **Fehler 7** Abweichungen werden spontan und undokumentiert behoben. --- **Fehler 8** Mehrere zusätzliche Änderungen werden nebenbei durchgeführt. --- **Fehler 9** Change wird abgeschlossen, obwohl Erfolgskriterien nicht geprüft wurden. --- **Fehler 10** Dokumentation, CMDB und Knowledge Base bleiben veraltet. --- **Fehler 11** Problem Record wird nach dauerhafter Lösung nicht aktualisiert. --- **Fehler 12** Failed Change wird nicht ausgewertet. --- **Checkliste Genehmigung** - [ ] Change Request ist vollständig - [ ] Nutzen ist nachvollziehbar - [ ] Risiko ist bewertet - [ ] Auswirkungen sind beschrieben - [ ] betroffene Services sind bekannt - [ ] betroffene CIs sind bekannt - [ ] Rollback ist geprüft - [ ] Tests sind beschrieben - [ ] Kommunikationsbedarf ist bewertet - [ ] Change Authority ist passend - [ ] Genehmigung ist dokumentiert --- **Checkliste Planung** - [ ] Umsetzungszeitpunkt festgelegt - [ ] Wartungsfenster bestätigt - [ ] beteiligte Personen verfügbar - [ ] Service Desk informiert - [ ] Benutzerkommunikation vorbereitet - [ ] technische Voraussetzungen geprüft - [ ] Backup oder Sicherung geprüft - [ ] Schrittfolge dokumentiert - [ ] Testplan vorhanden - [ ] Abbruchkriterien definiert - [ ] Rollback oder Backout vorbereitet - [ ] Lieferanten eingebunden, falls erforderlich --- **Checkliste Umsetzung** - [ ] Start des Changes dokumentiert - [ ] nur freigegebene Schritte durchgeführt - [ ] Abweichungen dokumentiert - [ ] Monitoring beobachtet - [ ] Kommunikationspunkte eingehalten - [ ] Tests nach Umsetzung durchgeführt - [ ] Fachbereich oder Service Owner beteiligt, falls nötig - [ ] Abbruchkriterien geprüft - [ ] Rollback durchgeführt, falls erforderlich - [ ] Ergebnis dokumentiert --- **Checkliste Abschluss** - [ ] Erfolgskriterien geprüft - [ ] Service wieder nutzbar - [ ] abhängige Services geprüft - [ ] Abschlussmeldung erfolgt - [ ] Change Record aktualisiert - [ ] CMDB aktualisiert - [ ] Knowledge Base aktualisiert - [ ] Runbooks aktualisiert - [ ] Problem Record aktualisiert, falls relevant - [ ] Incidents nach Change geprüft - [ ] Review durchgeführt, falls erforderlich - [ ] Lessons Learned dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker setzen Changes häufig technisch um. Dabei reicht es nicht, nur den Befehl oder die Konfiguration zu kennen. Wichtig ist auch: - Auswirkungen zu verstehen, - Risiken zu erkennen, - Vorbereitungen zu treffen, - Benutzer und Service Desk mitzudenken, - Änderungen nachvollziehbar zu dokumentieren, - Tests sinnvoll durchzuführen, - Rollback realistisch zu planen, - und aus Abweichungen zu lernen. Gute Change-Umsetzung verbindet technisches Können mit sauberer Planung. --- **Zusammenfassung** > Change Request prüfen > ↓ > Genehmigung und Change Authority klären > ↓ > Umsetzungsschritte planen > ↓ > Tests, Kommunikation und Rollback vorbereiten > ↓ > Change im vorgesehenen Zeitfenster durchführen > ↓ > Ergebnis technisch und fachlich prüfen > ↓ > Abschluss kommunizieren > ↓ > Dokumentation, CMDB und Knowledge aktualisieren > ↓ > Failed Changes oder Abweichungen auswerten --- **Merksätze** > Ein Change ist mehr als die technische Änderung. > Genehmigung bedeutet bewusste Risikoentscheidung. > Gute Planung reduziert Incidents nach Changes. > Rollback wird vor der Umsetzung geplant, nicht während der Störung. > Der Service Desk muss wichtige Changes kennen. > Ein Change ist erst abgeschlossen, wenn Ergebnis und Dokumentation geprüft sind. --- **Verwandte Seiten** - 5.1 Change Enablement – Ziele, Begriffe und Abgrenzung - 5.2 Change-Typen und Risikobewertung - 5.4 Release Management und Deployment Management - 5.5 Change-Erfolg messen und Continual Improvement - Incident Management - Problem Management - Knowledge Management - Service Configuration Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Genehmigungsschritte, - Planungsinhalte, - Kommunikationshinweise, - Rollback-Fragen, - Testbeispiele, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Genehmigungsmatrix, - CAB-Struktur, - Change-Request-Vorlage, - Rollback-Vorlage, - Kommunikationspflicht, - oder konkrete Testtiefe für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Service Levels, - Organisation, - Sicherheitsanforderungen, - Change-Modell, - Lieferanten, - Datenqualität, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 5.4 Release Management und Deployment Management > **Kurz erklärt** > > Release Management und Deployment Management sorgen dafür, dass neue oder geänderte Services, Anwendungen, Funktionen oder Infrastrukturkomponenten kontrolliert bereitgestellt werden. > > **Release Management** betrachtet vor allem, wann und in welcher Form eine Änderung für Benutzer oder Kunden verfügbar gemacht wird. > > **Deployment Management** betrachtet vor allem, wie technische Komponenten in eine Zielumgebung gebracht werden. > > Beide Bereiche hängen eng mit Change Enablement zusammen. --- **Warum Release und Deployment wichtig sind** Viele Änderungen werden nicht einzeln sichtbar. Oft werden mehrere technische Änderungen gemeinsam bereitgestellt. Beispiele: - neue Anwendungsversion, - Sicherheitsupdate, - neue Funktion im Serviceportal, - neue VPN-Client-Version, - aktualisierte Serverkonfiguration, - geänderte Schnittstelle, - neues Monitoring, - neue Self-Service-Funktion, - aktualisiertes Berechtigungskonzept. Wenn solche Änderungen unkoordiniert ausgerollt werden, können entstehen: - Incidents nach Updates, - Benutzerverwirrung, - fehlende Dokumentation, - inkompatible Versionen, - unklare Verantwortlichkeiten, - fehlende Rollback-Möglichkeiten, - nicht informierter Service Desk, - und unnötige Störungen im Betrieb. Release und Deployment sorgen für geordnete Bereitstellung. --- **Release und Deployment unterscheiden** | Begriff | Bedeutung | |---|---| | **Release** | Bündel neuer oder geänderter Funktionen, Services oder Komponenten, das bereitgestellt und für Nutzung freigegeben wird | | **Deployment** | technische Überführung von Komponenten in eine Zielumgebung | | **Change** | kontrollierte Änderung an einem Service oder unterstützenden Bestandteil | | **Rollout** | Verteilung oder Einführung eines Releases bei Benutzern, Standorten oder Systemen | | **Rollback** | Rücknahme einer Änderung auf einen vorherigen Zustand | | **Backout** | geplanter Ausstieg aus einer Änderung, wenn Abbruchkriterien erfüllt sind | Ein Deployment kann technisch erfolgreich sein, obwohl das Release aus Benutzersicht noch nicht erfolgreich ist. Beispiel: Die neue Version wurde auf dem Server installiert. Benutzer können aber eine wichtige Funktion nicht nutzen. Technisch wurde deployed. Das Release ist fachlich noch nicht erfolgreich. --- **Release Management** Release Management plant, koordiniert und steuert die Bereitstellung neuer oder geänderter Services und Funktionen. Typische Fragen: - Was wird veröffentlicht? - Welche Funktionen oder Änderungen sind enthalten? - Welche Benutzer oder Kunden sind betroffen? - Wann wird das Release verfügbar? - Welche Kommunikation ist notwendig? - Welche Dokumentation muss aktualisiert werden? - Welche Risiken bestehen? - Welche Abhängigkeiten gibt es? - Welche Changes gehören zum Release? - Wie wird der Erfolg geprüft? Release Management verbindet technische Bereitstellung mit Benutzer- und Serviceperspektive. --- **Deployment Management** Deployment Management sorgt dafür, dass technische Komponenten kontrolliert in eine Zielumgebung gebracht werden. Typische Fragen: - Welche Komponenten werden installiert oder geändert? - In welche Umgebung wird deployed? - Welche Version wird bereitgestellt? - Welche Reihenfolge ist notwendig? - Welche Abhängigkeiten bestehen? - Welche Tests sind erforderlich? - Wie wird der technische Zustand geprüft? - Wie wird zurückgerollt? - Welche Automatisierung wird genutzt? - Welche Logs und Nachweise entstehen? Deployment Management besitzt damit einen stärker technischen Fokus. --- **Release, Deployment und Change Enablement im Zusammenspiel** Ein möglicher Zusammenhang: Änderungsbedarf entsteht ↓ Change Request wird erstellt ↓ Risiko und Auswirkung werden bewertet ↓ Release wird geplant ↓ Deployment wird vorbereitet ↓ Change wird genehmigt ↓ Deployment wird durchgeführt ↓ Release wird für Benutzer verfügbar ↓ Erfolg wird geprüft ↓ Dokumentation und Knowledge werden aktualisiert Nicht jede Organisation trennt diese Schritte gleich stark. Wichtig ist, dass technische Umsetzung, Freigabe und Kommunikation zusammenpassen. --- **Beispiel: Anwendungsversion** Eine Fachanwendung erhält eine neue Version. **Change Enablement** - bewertet Risiko, - prüft Freigabe, - legt Wartungsfenster fest, - betrachtet Rollback und Kommunikation. **Release Management** - plant, welche Version wann veröffentlicht wird, - klärt enthaltene Funktionen, - informiert Benutzer und Service Desk, - stellt Release Notes bereit. **Deployment Management** - installiert die neue Version, - führt technische Prüfschritte aus, - kontrolliert Logs und Monitoring, - stellt bei Bedarf zurück. Alle drei Bereiche müssen zusammenarbeiten. --- **Release-Paket** Ein Release-Paket kann alle Bestandteile enthalten, die für eine Bereitstellung notwendig sind. Mögliche Inhalte: - Anwendungsversion, - Konfigurationsdateien, - Datenbankskripte, - Infrastrukturänderungen, - Installationsanleitung, - Testnachweise, - Rollback-Anleitung, - Release Notes, - Benutzerinformation, - aktualisierte Knowledge-Artikel, - Monitoring-Anpassungen, - Sicherheitsfreigaben, - Change-Verknüpfungen. Nicht jedes Release-Paket ist gleich umfangreich. Der Umfang muss zum Risiko und zur Bedeutung des Releases passen. --- **Release-Plan** Ein Release-Plan beschreibt, wann und wie ein Release bereitgestellt wird. Typische Inhalte: - Release-Name oder Version, - betroffene Services, - enthaltene Changes, - Zielumgebungen, - geplanter Zeitraum, - beteiligte Teams, - Abhängigkeiten, - Kommunikationsmaßnahmen, - Teststrategie, - Deployment-Schritte, - Rollback-Plan, - Erfolgskriterien, - Verantwortlichkeiten. Ein Release-Plan muss nicht kompliziert sein. Er muss aber ausreichend klar sein, damit alle Beteiligten wissen, was passiert. --- **Release Notes** Release Notes beschreiben, was sich mit einem Release ändert. Sie können enthalten: - neue Funktionen, - geänderte Funktionen, - behobene Fehler, - bekannte Einschränkungen, - bekannte Fehler, - Workarounds, - betroffene Benutzergruppen, - notwendige Benutzeraktionen, - geänderte Systemanforderungen, - Ansprechpartner oder Supportweg. Release Notes sollten zielgruppengerecht sein. Technische Teams benötigen andere Informationen als Endbenutzer. --- **Benutzerorientierte Release Notes** Ungeeignet: > Backend-Komponente API-GW-PRD wurde auf Build 2026.08.14-rc3 aktualisiert. Besser: > Die Suche im Mitarbeiterportal wurde verbessert. Ergebnisse werden nun schneller angezeigt. Während des Updates kann das Portal am 14.08.2026 zwischen 20:00 und 20:30 Uhr kurzzeitig nicht verfügbar sein. Benutzer müssen verstehen: - Was ändert sich für mich? - Wann passiert es? - Muss ich etwas tun? - Wo bekomme ich Hilfe? --- **Deployment-Plan** Ein Deployment-Plan beschreibt die technische Umsetzung. Mögliche Inhalte: - Zielumgebung, - Version, - betroffene Komponenten, - Reihenfolge der Schritte, - Verantwortliche, - benötigte Berechtigungen, - benötigte Dateien oder Images, - Vorbereitungsaufgaben, - technische Prüfschritte, - Monitoring, - Abbruchkriterien, - Rollback-Schritte, - Dokumentationshinweise. Bei einfachen Deployments kann der Plan kurz sein. Bei kritischen Deployments muss er detaillierter sein. --- **Umgebungen** Viele Organisationen nutzen mehrere Umgebungen. Beispiele: - Entwicklung, - Test, - Integration, - Abnahme, - Staging, - Produktion. Ziel ist, Änderungen vor der Produktion zu prüfen. Typische Fragen: - Entspricht die Testumgebung der Produktion ausreichend? - Sind Testdaten geeignet? - Sind Schnittstellen realistisch abgebildet? - Sind Berechtigungen vergleichbar? - Wurden Konfigurationen korrekt übernommen? - Sind Unterschiede zwischen Umgebungen dokumentiert? Ein Test in einer völlig abweichenden Umgebung gibt nur begrenzte Sicherheit. --- **Test und Abnahme** Vor einem Release sollten geeignete Tests durchgeführt werden. Mögliche Tests: - Funktionstest, - Integrationstest, - Sicherheitstest, - Performance-Test, - Regressionstest, - Benutzerakzeptanztest, - Smoke Test, - Wiederherstellungstest, - Monitoringtest. Der Testumfang hängt vom Risiko ab. Ein kritisches Release benötigt mehr Prüfung als eine kleine, risikoarme Änderung. --- **Regressionstest** Ein Regressionstest prüft, ob bestehende Funktionen nach einer Änderung weiterhin funktionieren. Beispiel: Eine neue Exportfunktion wird eingebaut. Der Regressionstest prüft zusätzlich: - Anmeldung, - Suche, - Speichern, - bestehender Export, - Berechtigungen, - Schnittstellen. Dadurch wird verhindert, dass eine neue Funktion alte Funktionen unbeabsichtigt beschädigt. --- **Smoke Test nach Deployment** Ein Smoke Test ist eine kurze Grundprüfung direkt nach dem Deployment. Beispiele: - Service startet, - Anmeldung funktioniert, - Startseite lädt, - Datenbankverbindung steht, - Schnittstelle antwortet, - Monitoring zeigt keine kritischen Alarme, - zentrale Benutzeraktion funktioniert. Ein Smoke Test ersetzt keine vollständige Abnahme. Er hilft aber, grobe Fehler sofort zu erkennen. --- **Deployment-Methoden** Organisationen können verschiedene Deployment-Methoden nutzen. Beispiele: | Methode | Kurzbeschreibung | |---|---| | **Big Bang** | Bereitstellung für alle Benutzer gleichzeitig | | **phasenweise Bereitstellung** | Einführung in mehreren Gruppen oder Standorten | | **Pilot** | begrenzte Einführung bei kleiner Benutzergruppe | | **Rolling Deployment** | schrittweise Aktualisierung einzelner Systeme | | **Blue-Green Deployment** | Wechsel zwischen zwei vorbereiteten Umgebungen | | **Canary Deployment** | neue Version zunächst für kleinen Teil der Benutzer | | **Feature Toggle** | Funktion wird technisch bereitgestellt, aber gezielt aktiviert oder deaktiviert | Diese Methoden sind Praxisbeispiele. ITIL schreibt keine bestimmte technische Deployment-Methode für alle Organisationen vor. --- **Big-Bang-Deployment** Beim Big-Bang-Deployment wird eine Änderung für alle betroffenen Benutzer oder Systeme gleichzeitig bereitgestellt. Vorteile: - einfacher Zeitplan, - keine parallelen Versionen, - schnelle vollständige Einführung. Risiken: - Fehler betreffen sofort alle Benutzer, - hoher Kommunikationsbedarf, - Rollback kann kritisch sein, - Supportspitzen möglich. Geeignet eher dann, wenn: - Risiko überschaubar ist, - Testqualität hoch ist, - Rollback möglich ist, - und alle Benutzer gleichzeitig wechseln müssen. --- **Phasenweise Bereitstellung** Bei einer phasenweisen Bereitstellung erfolgt der Rollout schrittweise. Beispiele: - zuerst IT-Team, - dann Pilotgruppe, - dann ein Standort, - dann alle Standorte, - dann externe Benutzer. Vorteile: - Fehler werden früher erkannt, - Auswirkungen bleiben zunächst begrenzt, - Support kann Erfahrungen sammeln, - Kommunikation kann angepasst werden. Risiken: - mehrere Versionen parallel, - längere Gesamtdauer, - zusätzlicher Koordinationsaufwand. --- **Pilot** Ein Pilot testet ein Release mit einer begrenzten Benutzergruppe. Geeignet für: - neue Software, - neue Geräte, - neue Prozesse, - größere Updates, - Änderungen mit Benutzerwirkung. Ein Pilot sollte klare Kriterien besitzen: - Wer nimmt teil? - Welche Funktionen werden getestet? - Wie wird Feedback gesammelt? - Wann ist der Pilot erfolgreich? - Wann wird gestoppt? - Was passiert nach dem Pilot? Ein Pilot ohne Auswertung bringt wenig Nutzen. --- **Blue-Green Deployment** Beim Blue-Green Deployment existieren zwei Umgebungen. Beispiel: - Blau = aktuelle produktive Umgebung, - Grün = neue vorbereitete Umgebung. Nach Tests wird der Verkehr auf die neue Umgebung umgeschaltet. Vorteile: - schneller Wechsel möglich, - Rollback kann einfacher sein, - neue Umgebung kann vorbereitet werden. Risiken: - höhere Infrastrukturkosten, - Datenbank- und Datenkonsistenz beachten, - Umschaltung muss sauber getestet sein, - nicht für jede Architektur geeignet. --- **Canary Deployment** Beim Canary Deployment erhält zuerst nur ein kleiner Teil der Benutzer die neue Version. Wenn keine Probleme auftreten, wird der Anteil erhöht. Vorteile: - Risiko wird begrenzt, - echte Nutzung liefert frühe Signale, - Fehler betreffen zunächst wenige Benutzer. Risiken: - Monitoring muss gut sein, - Benutzergruppen müssen steuerbar sein, - parallele Versionen können komplex sein, - Support muss wissen, wer welche Version nutzt. --- **Feature Toggles** Feature Toggles ermöglichen, Funktionen unabhängig vom technischen Deployment zu aktivieren oder zu deaktivieren. Beispiel: Die neue Funktion ist bereits deployed, aber nur für eine Pilotgruppe aktiviert. Vorteile: - kontrollierte Freigabe, - schnelles Deaktivieren bei Problemen, - Trennung von Deployment und Release möglich. Risiken: - zusätzliche Komplexität, - alte Schalter werden vergessen, - Tests werden schwieriger, - falsche Aktivierung kann Incidents erzeugen. Feature Toggles benötigen klare Verwaltung und Dokumentation. --- **Deployment-Automatisierung** Deployments werden häufig automatisiert. Beispiele: - Softwareverteilung, - CI/CD-Pipeline, - Skripte, - Container-Deployment, - Infrastruktur als Code, - Konfigurationsmanagement, - Paketverteilung, - Cloud-Automatisierung. Vorteile: - reproduzierbar, - schneller, - weniger manuelle Fehler, - besser protokollierbar, - leichter wiederholbar. Risiken: - falsche Automatisierung skaliert Fehler schnell, - Berechtigungen können zu weit sein, - Rollback muss ebenfalls berücksichtigt werden, - Tests müssen zuverlässig sein, - Pipeline-Ausfälle können Deployments blockieren. --- **Manuelles Deployment** Manuelle Deployments können notwendig sein, wenn: - Umgebung sehr speziell ist, - Automatisierung noch nicht vorhanden ist, - Änderung einmalig ist, - Risiko eine bewusste Schritt-für-Schritt-Kontrolle erfordert. Risiken manueller Deployments: - Tippfehler, - vergessene Schritte, - unterschiedliche Durchführung, - schlechte Reproduzierbarkeit, - fehlende Protokollierung. Runbooks und Checklisten reduzieren diese Risiken. --- **Release-Kalender** Ein Release-Kalender zeigt geplante Releases und wichtige Change-Zeitpunkte. Er hilft bei: - Koordination, - Vermeidung von Überschneidungen, - Kommunikation, - Ressourcenplanung, - Wartungsfenstern, - Change Freeze, - Lieferantenabstimmung, - Bereitschaftsplanung. Ein Release-Kalender sollte für relevante Teams sichtbar sein. --- **Change Freeze und Release Freeze** Ein Freeze ist ein Zeitraum, in dem Releases oder Changes eingeschränkt werden. Beispiele: - Jahresabschluss, - Feiertagsgeschäft, - Produktionshochlauf, - Auditphase, - Prüfungszeitraum, - große Migration. Ein Freeze bedeutet nicht zwingend, dass gar nichts geändert werden darf. Sicherheitsupdates oder Emergency Changes können trotzdem notwendig sein. Dann muss besonders bewusst entschieden und dokumentiert werden. --- **Kommunikation vor einem Release** Vor einem Release sollten betroffene Gruppen informiert werden. Mögliche Inhalte: - was sich ändert, - wann es sich ändert, - welche Services betroffen sind, - ob Ausfallzeiten entstehen, - welche neuen Funktionen verfügbar sind, - welche bekannten Einschränkungen bestehen, - was Benutzer tun müssen, - wo Hilfe verfügbar ist, - wann die nächste Information folgt. Der Service Desk muss besonders gut vorbereitet sein. --- **Service Desk vorbereiten** Der Service Desk benötigt vor einem Release: - Release Notes, - bekannte Fehler, - Workarounds, - Supportskripte, - Eskalationswege, - betroffene Benutzergruppen, - geplante Ausfallzeiten, - Ansprechpartner, - Statusinformationen, - Knowledge-Artikel. Ohne Vorbereitung steigen nach einem Release unnötige Tickets und Rückfragen. --- **Monitoring während und nach Deployment** Während und nach einem Deployment sollte Monitoring aktiv beobachtet werden. Zu prüfen sind: - Verfügbarkeit, - Antwortzeiten, - Fehlerraten, - CPU und Arbeitsspeicher, - Datenbankverbindungen, - Schnittstellen, - Warteschlangen, - Logfehler, - Sicherheitsmeldungen, - Benutzeranmeldungen, - Ticketaufkommen. Nach kritischen Releases kann eine verstärkte Beobachtungsphase sinnvoll sein. --- **Rollback und Roll Forward** Bei Problemen nach einem Deployment gibt es zwei grundsätzliche Richtungen. | Ansatz | Bedeutung | |---|---| | **Rollback** | Rückkehr zum vorherigen Zustand | | **Roll Forward** | Vorwärtskorrektur durch neue Änderung oder Hotfix | Rollback ist nicht immer möglich. Roll Forward kann sinnvoll sein, wenn: - Daten bereits migriert wurden, - Rückkehr zu riskant wäre, - Fehler schnell korrigierbar ist, - neue Version nur kleine Korrektur benötigt. Beide Wege benötigen Entscheidung, Dokumentation und Risikobewertung. --- **Release-Erfolg prüfen** Nach einem Release sollte geprüft werden: - Wurde das Release wie geplant bereitgestellt? - Funktionieren Kernservices? - Sind Benutzer arbeitsfähig? - Sind Incidents nach dem Release entstanden? - Wurden erwartete Funktionen geliefert? - Sind bekannte Fehler dokumentiert? - Wurde der Service Desk informiert? - Sind Monitoring und Logs unauffällig? - Muss Knowledge aktualisiert werden? - Wurde der erwartete Nutzen erreicht? Ein Release ist nicht erfolgreich, nur weil Dateien deployed wurden. Es muss aus Service- und Benutzersicht funktionieren. --- **Post-Deployment Review** Ein Post-Deployment Review kann nach wichtigen Deployments sinnvoll sein. Fragen: - Was lief gut? - Was lief anders als geplant? - Waren Tests ausreichend? - War Kommunikation ausreichend? - Gab es Incidents? - War Rollback realistisch? - Waren Abhängigkeiten bekannt? - War die Automatisierung zuverlässig? - Muss das Runbook verbessert werden? - Welche Lessons Learned gibt es? Nicht jedes kleine Deployment benötigt ein ausführliches Review. Bei kritischen oder fehlgeschlagenen Deployments ist es wichtig. --- **Release Management und Knowledge Management** Nach einem Release müssen Wissensbestände aktualisiert werden. Mögliche Inhalte: - Benutzeranleitungen, - Service-Desk-Artikel, - Known Errors, - Workarounds, - Runbooks, - FAQ, - Screenshots, - Menüpfade, - Installationsanleitungen, - Monitoringhinweise, - Eskalationswege. Veraltete Knowledge-Artikel erzeugen nach Releases häufig neue Tickets. --- **Release Management und Configuration Management** Nach Releases und Deployments müssen Configuration Items aktuell bleiben. Mögliche Änderungen: - neue Version, - neue Komponente, - geänderte Schnittstelle, - geänderte Abhängigkeit, - neuer Server, - neues Zertifikat, - geänderte Konfiguration, - neuer Owner, - geänderter Lieferant. Wenn die CMDB veraltet bleibt, werden spätere Incidents, Problems und Changes schwieriger. --- **Release Management und Incident Management** Nach Releases können Incidents entstehen. Deshalb sollte Incident Management vorbereitet sein. Wichtig: - Release-Zeitpunkt kennen, - bekannte Änderungen kennen, - betroffene Services erkennen, - typische Symptome kennen, - Known Errors nutzen, - Eskalationswege kennen, - Release-Team erreichbar haben. Ein Anstieg von Incidents nach einem Release kann auf Probleme in Test, Kommunikation oder Deployment hinweisen. --- **Release Management und Problem Management** Wenn nach einem Release wiederkehrende oder schwere Incidents entstehen, kann ein Problem Record notwendig sein. Problem Management prüft dann: - War das Release Ursache oder Auslöser? - Welche Funktion ist betroffen? - Warum wurde der Fehler im Test nicht erkannt? - Welche Abhängigkeit war unbekannt? - Welche Benutzergruppe ist betroffen? - Gibt es einen Workaround? - Ist Rollback oder Roll Forward sinnvoll? - Welche dauerhafte Lösung wird benötigt? --- **Release Management und Change Enablement** Change Enablement sorgt dafür, dass Releases und Deployments kontrolliert umgesetzt werden. Zu klären ist: - Welche Changes gehören zum Release? - Welche Freigaben sind notwendig? - Welche Risiken bestehen? - Sind Wartungsfenster abgestimmt? - Gibt es parallele Changes? - Gibt es ein Rollback? - Ist Kommunikation vorbereitet? - Wurde der Erfolg geprüft? Release und Deployment sollten nicht an Change Enablement vorbei erfolgen. --- **Praxisbeispiel: VPN-Client-Rollout** **Ausgangslage** Eine alte VPN-Client-Version verursacht wiederkehrende Incidents. **Release** Neue VPN-Client-Version wird bereitgestellt. **Deployment** - Pilotgruppe erhält neue Version, - Logs und Verbindungsstabilität werden geprüft, - Service Desk erhält Workaround und Eskalationshinweise, - anschließend phasenweiser Rollout an alle Notebooks. **Erfolgskontrolle** VPN-Incidents gehen zurück. Known Error wird aktualisiert. Knowledge-Artikel wird angepasst. --- **Praxisbeispiel: Mitarbeiterportal** **Ausgangslage** Das Mitarbeiterportal erhält neue Funktionen. **Release Management** - Release Notes erstellen, - Benutzerinformation vorbereiten, - Fachbereich einbinden, - Service Desk briefen. **Deployment Management** - neue Version im Wartungsfenster installieren, - Datenbankskripte ausführen, - Smoke Test durchführen, - Monitoring prüfen. **Nachbereitung** Incidents nach Release beobachten und Knowledge-Artikel aktualisieren. --- **Praxisbeispiel: Fehlgeschlagenes Deployment** **Situation** Eine neue Anwendungsversion wird erfolgreich installiert. **Problem** Nach dem Deployment funktioniert der PDF-Export nicht mehr. **Maßnahmen** - Incident erstellen, - Fachbereich informieren, - Rollback oder Hotfix bewerten, - Problem Record bei wiederkehrendem Fehler prüfen, - Testplan erweitern, - Release Notes und Known Errors aktualisieren. **Lerneffekt** Der Testplan muss künftig auch Exportfunktionen abdecken. --- **Typische Fehler** **Fehler 1** Release und Deployment werden gleichgesetzt. --- **Fehler 2** Technisches Deployment gelingt, aber Benutzer sind nicht vorbereitet. --- **Fehler 3** Service Desk erhält keine Release-Informationen. --- **Fehler 4** Release Notes fehlen oder sind zu technisch. --- **Fehler 5** Tests decken wichtige Geschäftsprozesse nicht ab. --- **Fehler 6** Rollback wird nicht realistisch geplant. --- **Fehler 7** Mehrere Releases kollidieren zeitlich. --- **Fehler 8** Monitoring wird nach Deployment nicht beobachtet. --- **Fehler 9** Known Errors und Workarounds werden nicht dokumentiert. --- **Fehler 10** CMDB und Knowledge Base bleiben nach Release veraltet. --- **Fehler 11** Fehlgeschlagene Deployments werden nicht ausgewertet. --- **Fehler 12** Automatisierung wird genutzt, aber nicht überwacht. --- **Checkliste Release Management** - [ ] Release-Inhalt ist beschrieben - [ ] betroffene Services sind bekannt - [ ] betroffene Benutzergruppen sind bekannt - [ ] enthaltene Changes sind verknüpft - [ ] Risiken sind bewertet - [ ] Release Notes sind vorbereitet - [ ] Service Desk ist informiert - [ ] Kommunikationsplan ist vorhanden - [ ] Testnachweise liegen vor - [ ] Known Errors sind dokumentiert - [ ] Erfolgskriterien sind definiert - [ ] Nachbeobachtung ist geplant --- **Checkliste Deployment Management** - [ ] Zielumgebung ist bekannt - [ ] Version ist eindeutig - [ ] Komponenten sind vollständig - [ ] Deployment-Schritte sind dokumentiert - [ ] Berechtigungen sind vorhanden - [ ] Backups oder Sicherungen sind geprüft - [ ] Rollback oder Roll Forward ist bewertet - [ ] Abbruchkriterien sind definiert - [ ] Monitoring ist aktiv - [ ] Smoke Test ist definiert - [ ] Ergebnis wird dokumentiert - [ ] Abweichungen werden erfasst --- **Checkliste Kommunikation** - [ ] Benutzerinformation vorbereitet - [ ] Service Desk informiert - [ ] Fachbereiche informiert - [ ] Management informiert, falls relevant - [ ] Lieferanten eingebunden, falls relevant - [ ] Ausfallzeit klar benannt - [ ] neue Funktionen verständlich erklärt - [ ] bekannte Einschränkungen genannt - [ ] Supportweg beschrieben - [ ] Abschlussmeldung vorgesehen --- **Checkliste Nachbereitung** - [ ] Release-Erfolg geprüft - [ ] Incidents nach Release ausgewertet - [ ] Monitoring geprüft - [ ] Logs geprüft - [ ] Fachbereichsfeedback eingeholt - [ ] Knowledge Base aktualisiert - [ ] Runbooks aktualisiert - [ ] CMDB aktualisiert - [ ] Known Errors aktualisiert - [ ] Problem Record erstellt, falls erforderlich - [ ] Lessons Learned dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker sind häufig direkt an Deployments beteiligt. Im Alltag bedeutet das: - Versionen sauber dokumentieren, - Deployment-Schritte nachvollziehbar ausführen, - Abhängigkeiten prüfen, - Tests durchführen, - Monitoring beobachten, - Rollback vorbereiten, - Service Desk informieren, - Knowledge-Artikel aktualisieren, - und Fehler nach Releases strukturiert auswerten. Gute technische Bereitstellung bedeutet nicht nur: > Installation erfolgreich. Sondern: > Service funktioniert, Benutzer sind arbeitsfähig, Support ist vorbereitet und Dokumentation stimmt. --- **Zusammenfassung** > Release-Inhalt festlegen > ↓ > Changes, Risiken und Abhängigkeiten prüfen > ↓ > Deployment vorbereiten > ↓ > Service Desk und Benutzer informieren > ↓ > technische Bereitstellung durchführen > ↓ > Smoke Test und Monitoring prüfen > ↓ > Release aus Benutzersicht bewerten > ↓ > Incidents und Feedback beobachten > ↓ > Knowledge, CMDB und Runbooks aktualisieren > ↓ > Lessons Learned übernehmen --- **Merksätze** > Release Management betrachtet die Bereitstellung aus Service- und Benutzersicht. > Deployment Management betrachtet die technische Überführung in eine Zielumgebung. > Ein erfolgreiches Deployment ist nicht automatisch ein erfolgreiches Release. > Service Desk und Benutzer müssen auf wichtige Releases vorbereitet sein. > Rollback und Kommunikation gehören vor dem Deployment geplant. > Nach einem Release müssen Knowledge, CMDB und Monitoring geprüft werden. --- **Verwandte Seiten** - 5.1 Change Enablement – Ziele, Begriffe und Abgrenzung - 5.2 Change-Typen und Risikobewertung - 5.3 Genehmigung, Planung und Umsetzung von Changes - 5.5 Change-Erfolg messen und Continual Improvement - Incident Management - Problem Management - Knowledge Management - Service Configuration Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Release Management - PeopleCert – ITIL Practice Guide: Deployment Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Knowledge Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Deployment-Methoden, - Checklisten, - Release-Plan-Inhalte, - Kommunikationshinweise, - Praxisbeispiele, - und Nachbereitungsfragen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Deployment-Methode, - Release-Kalender-Struktur, - Release-Notes-Vorlage, - Testtiefe, - Rollout-Strategie, - oder Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Benutzergruppen, - technische Architektur, - Change-Modell, - Deployment-Werkzeuge, - Sicherheitsanforderungen, - Lieferanten, - und organisatorische Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 5.5 Change-Erfolg messen und Continual Improvement > **Kurz erklärt** > > Ein Change ist nicht automatisch erfolgreich, nur weil er technisch durchgeführt wurde. > > Erfolgreich ist ein Change erst dann, wenn der gewünschte Nutzen erreicht wurde, der Service stabil bleibt, Benutzer arbeitsfähig sind und keine unvertretbaren Nebenwirkungen entstehen. > > Deshalb müssen Changes nach der Umsetzung bewertet, dokumentiert und für zukünftige Verbesserungen genutzt werden. --- **Warum Change-Erfolg gemessen werden muss** Ohne Erfolgsmessung bleibt unklar, ob ein Change wirklich sinnvoll war. Mögliche Fragen: - Hat der Change das Ziel erreicht? - Funktioniert der betroffene Service stabil? - Gab es neue Incidents nach dem Change? - Wurde der erwartete Nutzen erreicht? - Waren Benutzer ausreichend informiert? - War der Rollback realistisch? - Waren Tests ausreichend? - Gab es ungeplante Auswirkungen? - Muss Wissen oder Dokumentation angepasst werden? - Was sollte beim nächsten Change besser laufen? Change-Erfolg bedeutet mehr als: > Umsetzung abgeschlossen. Entscheidend ist das Ergebnis aus Service-, Benutzer- und Betriebssicht. --- **Technische Umsetzung und Service-Erfolg unterscheiden** | Technische Umsetzung | Service-Erfolg | |---|---| | Paket wurde installiert | Benutzer können wieder arbeiten | | Konfiguration wurde geändert | Service funktioniert stabil | | Server wurde aktualisiert | abhängige Systeme funktionieren weiterhin | | Firewall-Regel wurde gesetzt | Schnittstelle funktioniert sicher und erwartungsgemäß | | Zertifikat wurde erneuert | Anmeldung funktioniert ohne neue Störungen | | Deployment ist abgeschlossen | Release erzeugt den gewünschten Nutzen | Ein Change kann technisch erfolgreich sein und trotzdem aus Service-Sicht Probleme verursachen. Beispiel: Eine neue Anwendungsversion wurde korrekt installiert. Nach dem Update funktioniert jedoch der Export für die Buchhaltung nicht mehr. Technisch war das Deployment erfolgreich. Aus Sicht des Services ist der Change nur teilweise erfolgreich oder fehlgeschlagen. --- **Erfolgskriterien vorab festlegen** Erfolg sollte vor der Umsetzung definiert werden. Gute Erfolgskriterien sind: - eindeutig, - messbar, - überprüfbar, - realistisch, - mit dem Ziel des Changes verbunden, - und für Technik sowie Benutzer verständlich. Beispiele: | Change | mögliches Erfolgskriterium | |---|---| | VPN-Client aktualisieren | VPN-Incidents sinken innerhalb von vier Wochen deutlich | | Zertifikat erneuern | Anmeldung funktioniert und Monitoring erkennt zukünftige Abläufe | | Firewall-Regel setzen | gewünschte Verbindung funktioniert, keine unerwarteten Freigaben | | Anwendung aktualisieren | Kernfunktionen funktionieren nach Smoke Test und Fachbereichstest | | Monitoring erweitern | relevante Warnung wird korrekt ausgelöst und an richtiges Team gesendet | | Druckertreiber aktualisieren | Etikettendruck funktioniert und Incidents treten nicht erneut auf | Ohne Erfolgskriterien wird die Nachprüfung ungenau. --- **Mögliche Kennzahlen für Change-Erfolg** | Bereich | mögliche Kennzahl | |---|---| | Umsetzung | Anteil erfolgreich abgeschlossener Changes | | Qualität | Anzahl fehlgeschlagener Changes | | Stabilität | Incidents nach Changes | | Risiko | Anzahl Emergency Changes | | Planung | Anteil Changes mit Rollback-Plan | | Kommunikation | Beschwerden oder Rückfragen nach Change | | Geschwindigkeit | Durchlaufzeit von Change Request bis Umsetzung | | Wirkung | Rückgang wiederkehrender Incidents | | Wissen | aktualisierte Knowledge-Artikel nach Change | | Verbesserung | Lessons Learned umgesetzt | Nicht jede Organisation benötigt alle Kennzahlen. Wichtig ist, dass die Kennzahlen Entscheidungen und Verbesserungen unterstützen. --- **Change Success Rate** Die Change Success Rate beschreibt den Anteil der Changes, die erfolgreich umgesetzt wurden. Vorsicht: Eine hohe Erfolgsquote ist nur sinnvoll, wenn klar definiert ist, was „erfolgreich“ bedeutet. Ungeeignet: > Change wurde durchgeführt, also erfolgreich. Besser: > Change wurde wie geplant durchgeführt, Erfolgskriterien wurden erreicht, keine relevanten Incidents entstanden, Dokumentation wurde aktualisiert. Eine zu einfache Erfolgsdefinition verfälscht die Kennzahl. --- **Failed Changes** Ein Failed Change ist eine Änderung, die nicht wie geplant erfolgreich war oder unerwünschte Auswirkungen verursacht hat. Mögliche Beispiele: - Change musste abgebrochen werden, - Rollback war notwendig, - Service fiel aus, - Benutzer konnten nicht arbeiten, - neue Incidents entstanden, - Erfolgskriterien wurden nicht erreicht, - Daten wurden beschädigt, - Sicherheitsrisiko entstand, - Kommunikation war unzureichend, - Dokumentation blieb falsch. Failed Changes sind wichtige Lernquellen. Sie sollten nicht versteckt oder beschönigt werden. --- **Incidents nach Changes** Eine wichtige Kennzahl ist die Anzahl der Incidents, die nach Changes entstehen. Zu prüfen ist: - Trat der Incident direkt nach dem Change auf? - Ist ein Zusammenhang wahrscheinlich? - Welche Services sind betroffen? - Wurde der Change korrekt getestet? - Wurden Abhängigkeiten übersehen? - War die Kommunikation ausreichend? - War der Service Desk vorbereitet? - Gab es ähnliche Incidents bei früheren Changes? Nicht jeder Incident nach einem Change wurde durch den Change verursacht. Der zeitliche Zusammenhang ist ein Hinweis, aber kein Beweis. --- **Emergency-Change-Quote** Eine hohe Anzahl von Emergency Changes kann auf Probleme hinweisen. Mögliche Ursachen: - schlechte Planung, - zu spätes Erkennen von Risiken, - fehlendes Monitoring, - unzureichendes Patchmanagement, - instabile Services, - fehlende Wartungsfenster, - langsame Genehmigungswege, - zu viele ungeplante Arbeiten, - oder schlechte Priorisierung. Emergency Changes sind manchmal notwendig. Wenn sie aber zur Regel werden, sollte das Change-Modell überprüft werden. --- **Rollback-Quote** Die Rollback-Quote zeigt, wie oft Changes zurückgenommen werden mussten. Eine hohe Quote kann hinweisen auf: - unzureichende Tests, - schlechte Auswirkungsbewertung, - falsche Annahmen, - fehlende Abhängigkeiten, - ungeeignete Wartungsfenster, - unvollständige Kommunikation, - oder mangelhafte technische Vorbereitung. Eine niedrige Rollback-Quote ist nicht automatisch gut. Sie kann auch bedeuten, dass bei Problemen kein funktionierender Rollback vorhanden war. --- **Durchlaufzeit von Changes** Die Durchlaufzeit beschreibt, wie lange ein Change von der Anforderung bis zur Umsetzung benötigt. Zu betrachten sind: - Zeit bis zur Bewertung, - Zeit bis zur Genehmigung, - Wartezeit auf Informationen, - Wartezeit auf Wartungsfenster, - Zeit für Tests, - Zeit für Umsetzung, - Zeit bis Abschluss. Lange Durchlaufzeiten können auf Engpässe hinweisen. Beispiele: - Change Requests sind unvollständig. - Genehmigungen dauern zu lange. - Tests sind nicht verfügbar. - Fachbereiche reagieren langsam. - Lieferanten blockieren. - CAB-Termine sind zu selten. --- **Qualität der Change Requests** Die Qualität eines Change Requests beeinflusst die gesamte Bearbeitung. Zu prüfen ist: - Ist die Änderung verständlich beschrieben? - Ist der betroffene Service genannt? - Sind CIs dokumentiert? - Ist der Nutzen klar? - Sind Risiken bewertet? - Ist ein Testplan vorhanden? - Ist ein Rollback beschrieben? - Ist Kommunikation berücksichtigt? - Sind Abhängigkeiten genannt? - Sind Erfolgskriterien definiert? Unvollständige Change Requests führen zu Rückfragen, Verzögerungen und höheren Risiken. --- **Change-Kalender auswerten** Ein Change-Kalender zeigt nicht nur geplante Änderungen. Er kann auch zur Verbesserung genutzt werden. Zu prüfen ist: - Häufen sich Changes in bestimmten Zeiträumen? - Gibt es Kollisionen zwischen Changes? - Werden kritische Services zu häufig geändert? - Finden Changes außerhalb geeigneter Wartungsfenster statt? - Gibt es wiederholt Verschiebungen? - Werden Changes während Change Freeze beantragt? - Sind Lieferanten und Bereitschaften richtig eingeplant? Ein gut gepflegter Change-Kalender reduziert Konflikte und Überraschungen. --- **Post Implementation Review** Ein Post Implementation Review prüft nach der Umsetzung, ob der Change erfolgreich war. Mögliche Fragen: - Wurde der Change wie geplant durchgeführt? - Wurden Erfolgskriterien erreicht? - Waren Tests ausreichend? - Waren Risiko und Auswirkung korrekt bewertet? - War die Kommunikation verständlich? - War der Service Desk vorbereitet? - Gab es Incidents nach dem Change? - War Rollback möglich oder notwendig? - Wurde Dokumentation aktualisiert? - Welche Verbesserungen sind notwendig? Nicht jeder kleine Standard Change benötigt ein ausführliches Review. Bei risikoreichen, fehlgeschlagenen oder besonders wichtigen Changes ist es sehr sinnvoll. --- **Review nach Emergency Changes** Emergency Changes sollten besonders sorgfältig nachbereitet werden. Zu prüfen ist: - Warum war die Änderung dringend? - Hätte die Situation früher erkannt werden können? - War der Emergency-Prozess angemessen? - Wer hat entschieden? - Welche Risiken wurden akzeptiert? - War die Dokumentation ausreichend? - Wurde der Service stabil wiederhergestellt? - Sind weitere dauerhafte Maßnahmen notwendig? - Muss ein Problem Record erstellt werden? - Muss Monitoring verbessert werden? Ziel ist nicht, die schnelle Entscheidung nachträglich zu bestrafen. Ziel ist, zukünftige Notfälle zu vermeiden. --- **Review nach Failed Changes** Ein Failed Change sollte analysiert werden. Mögliche Fragen: - Welche Annahme war falsch? - Welche Abhängigkeit wurde übersehen? - Welcher Test fehlte? - War das Wartungsfenster ausreichend? - War der Rollback realistisch? - Waren Rollen klar? - Wurde zu spät abgebrochen? - War die Kommunikation ausreichend? - Welche Dokumentation war fehlerhaft? - Welche Maßnahme verhindert Wiederholung? Failed Changes sind wichtige Daten für Continual Improvement. --- **Lessons Learned** Lessons Learned sind Erkenntnisse aus erfolgreichen und fehlgeschlagenen Changes. Mögliche Ergebnisse: - Change-Vorlage verbessern, - Testplan erweitern, - Rollback-Vorgaben präzisieren, - Service Desk früher informieren, - CAB-Beteiligung anpassen, - Standard Change neu definieren, - Emergency-Kriterien überarbeiten, - CMDB aktualisieren, - Monitoring erweitern, - Knowledge-Artikel aktualisieren, - Automatisierung verbessern, - Schulung durchführen. Lessons Learned sind nur wertvoll, wenn daraus konkrete Maßnahmen entstehen. --- **Continual Improvement im Change Enablement** Change Enablement sollte selbst kontinuierlich verbessert werden. Möglicher Ablauf: Change-Daten sammeln ↓ Trends und Schwachstellen erkennen ↓ Verbesserungsidee erfassen ↓ Nutzen und Aufwand bewerten ↓ Maßnahme umsetzen ↓ Wirkung messen ↓ Change-Modell anpassen Verbesserung kann sich auf Prozesse, Werkzeuge, Kommunikation, Vorlagen, Automatisierung oder Rollen beziehen. --- **Improvement Register** Verbesserungsideen aus Change Reviews sollten nicht verloren gehen. Ein Improvement Register kann enthalten: - Verbesserungsidee, - Auslöser, - betroffener Prozess, - erwarteter Nutzen, - Risiko, - Aufwand, - Priorität, - Verantwortlicher, - Status, - Zieltermin, - Ergebnis. Beispiele: - Checkliste für Firewall-Changes ergänzen, - Service Desk bei Releases früher informieren, - Standard-Change-Katalog überarbeiten, - Emergency-Change-Review verbindlich machen, - Rollback-Vorlage verbessern, - Change-Kalender sichtbarer machen. --- **Standard Changes regelmäßig überprüfen** Standard Changes sind vorab genehmigt. Trotzdem müssen sie regelmäßig geprüft werden. Fragen: - Wird der Ablauf noch korrekt genutzt? - Ist das Risiko weiterhin niedrig? - Gab es Incidents nach Standard Changes? - Sind Runbooks aktuell? - Sind Berechtigungen angemessen? - Sind Erfolgskriterien noch gültig? - Wird der Standard Change missbraucht? - Muss der Ablauf angepasst werden? - Muss der Standard Change entfernt werden? Ein Standard Change darf nicht dauerhaft ungeprüft bleiben. --- **Change-Modell anpassen** Ein Change-Modell beschreibt, wie bestimmte Change-Arten bearbeitet werden. Es sollte angepasst werden, wenn: - Changes regelmäßig zu langsam sind, - Standard Changes zu viele Rückfragen erzeugen, - Emergency Changes zu häufig auftreten, - Failed Changes zunehmen, - Genehmigungen unnötig blockieren, - Risiken nicht erkannt werden, - Service Desk nicht ausreichend informiert wird, - oder Dokumentation häufig fehlt. Ein gutes Change-Modell ist stabil, aber nicht starr. --- **Automatisierung im Change Enablement** Automatisierung kann Change Enablement verbessern. Beispiele: - automatische Pflichtfeldprüfung, - Risikoeinstufung anhand betroffener Services, - automatische Benachrichtigung des Service Desks, - Change-Kollisionen erkennen, - Standard-Change-Workflows, - automatische Deployment-Protokolle, - automatische CMDB-Aktualisierung, - Monitoring nach Change aktivieren, - Erinnerungen an Reviews. Automatisierung muss aber kontrolliert werden. Ein falsch automatisierter Change-Prozess kann Fehler schneller verbreiten. --- **Change-Datenqualität verbessern** Gute Auswertung benötigt gute Daten. Probleme entstehen durch: - unvollständige Change Requests, - falsche Servicezuordnung, - fehlende CI-Verknüpfung, - unklare Abschlussnotizen, - nicht dokumentierte Rollbacks, - fehlende Erfolgskriterien, - nicht verknüpfte Incidents, - fehlende Problem-Verknüpfung, - veraltete CMDB. Eine wichtige Verbesserung kann darin bestehen, die Pflichtinformationen im Change-Prozess zu verbessern. --- **Zusammenhang mit Problem Management** Problem Management ist besonders wichtig für Change-Erfolg. Ein Change kann: - eine dauerhafte Lösung für ein Problem umsetzen, - einen Known Error schließen, - einen Workaround ersetzen, - neue Incidents verursachen, - oder selbst ein neues Problem auslösen. Nach einem Change zur Problemlösung sollte geprüft werden: - Ist das Problem wirklich behoben? - Treten zugehörige Incidents weiter auf? - Ist der Workaround noch nötig? - Kann der Known Error geschlossen werden? - Muss ein neues Problem erstellt werden? --- **Zusammenhang mit Knowledge Management** Nach Changes muss Wissen aktuell bleiben. Zu prüfen ist: - Müssen Knowledge-Artikel angepasst werden? - Sind Screenshots oder Menüpfade veraltet? - Gibt es neue Workarounds? - Ist ein Known Error geschlossen? - Muss der Service Desk neue Prüfschritte kennen? - Müssen Benutzeranleitungen angepasst werden? - Muss ein Runbook aktualisiert werden? Ein Change kann technisch erfolgreich sein und trotzdem Supportprobleme verursachen, wenn Knowledge veraltet bleibt. --- **Zusammenhang mit Service Configuration Management** Nach Changes müssen Configuration Items und Beziehungen aktuell bleiben. Zu prüfen ist: - Wurde eine Version geändert? - Wurde Hardware ersetzt? - Wurde ein neuer Server erstellt? - Wurde eine Schnittstelle geändert? - Wurde eine neue Abhängigkeit erzeugt? - Hat sich der Owner geändert? - Wurde ein Zertifikat erneuert? - Hat sich ein Lieferant geändert? Eine veraltete CMDB erschwert zukünftige Incidents, Problems und Changes. --- **Zusammenhang mit Measurement and Reporting** Measurement and Reporting unterstützt Change Enablement durch: - Kennzahlen, - Trendberichte, - Dashboards, - Erfolgsanalysen, - Service Reviews, - Managementberichte, - und Verbesserungsnachweise. Wichtig ist, nicht nur Zahlen zu zeigen. Berichte sollten erklären: - was passiert ist, - warum es relevant ist, - welche Risiken bestehen, - welche Maßnahmen geplant sind, - und welche Entscheidung benötigt wird. --- **Beispiel: Failed Change** **Situation** Ein Anwendungspatch wurde eingespielt. **Problem** Nach dem Patch funktioniert der PDF-Export nicht mehr. **Analyse** - Testplan enthielt keinen Exporttest. - Fachbereich wurde nicht in die Abnahme einbezogen. - Rollback war möglich und wurde durchgeführt. - Service Desk wurde erst nach Benutzeranrufen informiert. **Verbesserungen** - Testplan um Exportfunktion erweitern, - Fachbereichstest für kritische Funktionen einführen, - Service Desk vor jedem produktiven Patch informieren, - Release Notes ergänzen. --- **Beispiel: Zu viele Emergency Changes** **Beobachtung** Emergency Changes nehmen über mehrere Monate zu. **Analyse** Viele Emergency Changes betreffen ablaufende Zertifikate und Speicherplatzprobleme. **Ursachen** - kein Zertifikatsmonitoring, - keine rechtzeitige Kapazitätsplanung, - fehlende Owner, - veraltete Wartungskalender. **Verbesserungen** - Zertifikatsüberwachung einführen, - Speichertrends monatlich prüfen, - Owner je Service festlegen, - proaktive Problem Records erstellen. --- **Beispiel: Standard Change verbessern** **Situation** Standardsoftware wird über ein Portal bereitgestellt. **Problem** Viele Requests schlagen fehl, weil Geräte nicht erreichbar sind. **Analyse** - Portal prüft den Gerätestatus nicht vorab. - Benutzer erhalten unklare Fehlermeldungen. - Service Desk muss manuell nacharbeiten. **Verbesserungen** - Vorabprüfung des Gerätestatus automatisieren, - Benutzerhinweis verbessern, - Fehler automatisch an Service Desk weiterleiten, - Knowledge-Artikel aktualisieren. --- **Typische Fehler** **Fehler 1** Change gilt als erfolgreich, nur weil er technisch durchgeführt wurde. --- **Fehler 2** Erfolgskriterien werden nicht vorab definiert. --- **Fehler 3** Incidents nach Changes werden nicht ausgewertet. --- **Fehler 4** Failed Changes werden beschönigt oder nicht dokumentiert. --- **Fehler 5** Emergency Changes werden nicht nachbereitet. --- **Fehler 6** Lessons Learned werden gesammelt, aber nicht umgesetzt. --- **Fehler 7** Standard Changes werden nie überprüft. --- **Fehler 8** Kennzahlen erzeugen falsche Anreize. --- **Fehler 9** Change-Datenqualität ist schlecht. --- **Fehler 10** Knowledge Base und CMDB werden nach Changes nicht aktualisiert. --- **Fehler 11** Review-Fragen konzentrieren sich nur auf Technik, nicht auf Servicewirkung. --- **Fehler 12** Verbesserungen bleiben ohne Verantwortlichen und Termin. --- **Problematische Kennzahlen** | Kennzahl | möglicher Fehlanreiz | |---|---| | möglichst viele Changes | unnötige oder schlecht geplante Änderungen | | sehr kurze Durchlaufzeit | unzureichende Prüfung | | hohe Erfolgsquote | Fehler werden nicht ehrlich dokumentiert | | wenige Emergency Changes | dringende Fälle werden falsch klassifiziert | | wenige Failed Changes | Teams melden Fehlschläge nicht transparent | | niedrige Rollback-Quote | Rollback fehlt oder wird vermieden | Kennzahlen müssen deshalb immer mit Kontext betrachtet werden. --- **Gute Kennzahlenkombinationen** Sinnvoll ist eine kombinierte Betrachtung. Beispiele: - Change Success Rate und Incidents nach Changes, - Durchlaufzeit und Qualität der Change Requests, - Emergency-Change-Quote und proaktive Problem Records, - Failed Changes und Lessons Learned, - Standard-Change-Nutzung und Fehlerquote, - Knowledge-Aktualisierungen und Supportanfragen nach Release, - CMDB-Aktualisierungen und spätere Incident-Diagnosequalität. Einzelne Kennzahlen können täuschen. Kombinationen zeigen bessere Zusammenhänge. --- **Checkliste Change-Erfolg prüfen** - [ ] Erfolgskriterien vorab definiert - [ ] Change wie geplant umgesetzt - [ ] Service technisch verfügbar - [ ] Benutzer-Outcome geprüft - [ ] abhängige Services geprüft - [ ] Monitoring geprüft - [ ] Logs geprüft - [ ] Incidents nach Change geprüft - [ ] Service Desk informiert - [ ] Abschluss kommuniziert - [ ] Dokumentation aktualisiert - [ ] Knowledge Base aktualisiert - [ ] CMDB aktualisiert --- **Checkliste Post Implementation Review** - [ ] Ziel des Changes erreicht? - [ ] Risiko korrekt bewertet? - [ ] Auswirkungen korrekt eingeschätzt? - [ ] Tests ausreichend? - [ ] Kommunikation ausreichend? - [ ] Wartungsfenster passend? - [ ] Rollback realistisch? - [ ] Abweichungen dokumentiert? - [ ] neue Incidents entstanden? - [ ] Lessons Learned erfasst? - [ ] Verbesserungen zugewiesen? - [ ] Review-Ergebnis dokumentiert? --- **Checkliste Failed Change** - [ ] Auswirkungen begrenzt - [ ] Incident verknüpft - [ ] Rollback oder Roll Forward bewertet - [ ] Benutzer informiert - [ ] Service Desk informiert - [ ] Ursache des Fehlschlags untersucht - [ ] Problem Record erstellt, falls erforderlich - [ ] Testplan angepasst - [ ] Change-Modell geprüft - [ ] Knowledge aktualisiert - [ ] Lessons Learned dokumentiert - [ ] Verbesserungsmaßnahmen verfolgt --- **Checkliste Continual Improvement im Change Enablement** - [ ] Change-Kennzahlen regelmäßig ausgewertet - [ ] Emergency Changes analysiert - [ ] Failed Changes analysiert - [ ] Standard Changes überprüft - [ ] Change Requests auf Qualität geprüft - [ ] CAB oder Genehmigungswege bewertet - [ ] Service Desk Feedback einbezogen - [ ] Benutzerfeedback berücksichtigt - [ ] CMDB- und Knowledge-Aktualisierung geprüft - [ ] Verbesserungen im Improvement Register erfasst - [ ] Verantwortliche benannt - [ ] Wirksamkeit der Verbesserungen geprüft --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker tragen wesentlich dazu bei, ob Change-Erfolg messbar und nachvollziehbar ist. Im Arbeitsalltag bedeutet das: - Umsetzungsschritte dokumentieren, - Tests sauber durchführen, - technische und fachliche Ergebnisse prüfen, - Monitoring und Logs auswerten, - Abweichungen ehrlich dokumentieren, - Rollbacks nachvollziehbar beschreiben, - Knowledge und Runbooks aktualisieren, - CMDB-Änderungen melden, - Incidents nach Changes erkennen, - und Verbesserungen aus Fehlern ableiten. Gute technische Arbeit endet nicht beim erfolgreichen Befehl. Sie endet erst, wenn der Service stabil funktioniert und die Änderung nachvollziehbar abgeschlossen ist. --- **Zusammenfassung** > Change-Ziel und Erfolgskriterien festlegen > ↓ > Change durchführen > ↓ > technisches Ergebnis prüfen > ↓ > Benutzer-Outcome und Servicewirkung prüfen > ↓ > Incidents, Monitoring und Feedback auswerten > ↓ > Failed Changes und Emergency Changes reviewen > ↓ > Knowledge, CMDB und Dokumentation aktualisieren > ↓ > Lessons Learned erfassen > ↓ > Verbesserungen verfolgen > ↓ > Change-Modell kontinuierlich verbessern --- **Merksätze** > Ein Change ist nicht erfolgreich, nur weil er durchgeführt wurde. > Erfolg muss aus Service- und Benutzersicht geprüft werden. > Failed Changes sind Lernquellen. > Emergency Changes benötigen Nachbereitung. > Kennzahlen ohne Kontext erzeugen falsche Schlüsse. > Lessons Learned sind nur wertvoll, wenn sie umgesetzt werden. > Change Enablement selbst muss kontinuierlich verbessert werden. --- **Verwandte Seiten** - 5.1 Change Enablement – Ziele, Begriffe und Abgrenzung - 5.2 Change-Typen und Risikobewertung - 5.3 Genehmigung, Planung und Umsetzung von Changes - 5.4 Release Management und Deployment Management - 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management - Knowledge Management - Service Configuration Management - Continual Improvement - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Release Management - PeopleCert – ITIL Practice Guide: Deployment Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Kennzahlen, - Review-Fragen, - Checklisten, - Beispiele, - Lessons-Learned-Hinweise, - und Improvement-Ansätze sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Change-Erfolgsquote, - Review-Pflicht für alle Changes, - KPI-Liste, - PIR-Vorlage, - Lessons-Learned-Struktur, - oder Reporting-Form für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Service Levels, - Organisation, - Change-Modell, - Release-Modell, - Datenqualität, - Werkzeuge, - Sicherheitsanforderungen, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6. Service Configuration Management # 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen > **Kurz erklärt** > > Service Configuration Management sorgt dafür, dass wichtige Informationen über Services, Systeme, Komponenten und deren Beziehungen nachvollziehbar gepflegt werden. > > Ziel ist, zu wissen: > > - welche Komponenten vorhanden sind, > - wie sie zusammenhängen, > - wer verantwortlich ist, > - welche Versionen genutzt werden, > - und welche Services von welchen Bestandteilen abhängig sind. > > Dadurch können Incidents, Problems, Changes und Releases besser bewertet und gesteuert werden. --- **Warum Service Configuration Management wichtig ist** IT-Services bestehen selten aus nur einer einzelnen Komponente. Ein scheinbar einfacher Service kann abhängig sein von: - Anwendung, - Datenbank, - Server, - Netzwerk, - DNS, - Zertifikaten, - Identitätsdienst, - Storage, - Cloud-Ressourcen, - Schnittstellen, - Lieferanten, - Monitoring, - Backup, - und Berechtigungen. Wenn diese Zusammenhänge unbekannt sind, entstehen Risiken: - Incidents werden langsamer analysiert, - Changes werden falsch bewertet, - Auswirkungen werden unterschätzt, - Verantwortlichkeiten bleiben unklar, - Problems werden nicht richtig eingegrenzt, - Dokumentation ist veraltet, - und Serviceabhängigkeiten werden erst im Fehlerfall sichtbar. Service Configuration Management schafft dafür eine nachvollziehbare Informationsbasis. --- **Was ist eine Configuration?** Eine Configuration beschreibt, wie ein Service oder System aufgebaut ist. Dazu gehören beispielsweise: - eingesetzte Komponenten, - Versionen, - Einstellungen, - Abhängigkeiten, - Beziehungen, - Standorte, - Verantwortlichkeiten, - Lieferanten, - technische Schnittstellen, - und unterstützende Services. Beispiel: Der Service „VPN-Zugang“ besteht nicht nur aus dem VPN-Gateway. Er kann abhängig sein von: - VPN-Client, - Zertifikaten, - Identity Provider, - MFA, - Firewall, - DNS, - Netzwerkverbindung, - Monitoring, - und Benutzergruppen. --- **Configuration Item** Ein **Configuration Item (CI)** ist ein Bestandteil, der für die Bereitstellung oder Verwaltung eines Service relevant ist. Beispiele: - Server, - Anwendung, - Datenbank, - Netzwerkgerät, - Firewall-Regel, - Zertifikat, - Cloud-Ressource, - Benutzergruppe, - Schnittstelle, - Lizenz, - Dokumentation, - Lieferantenvertrag, - Arbeitsplatzgerät, - Drucker, - Service selbst. Nicht jedes technische Objekt muss automatisch ein CI sein. Die Organisation muss festlegen, welche Elemente wichtig genug sind, um verwaltet zu werden. --- **Beispiele für Configuration Items** | CI-Typ | Beispiel | |---|---| | **Service** | Mitarbeiterportal | | **Anwendung** | Warenwirtschaft | | **Server** | APP-WEB-01 | | **Datenbank** | SQL-Cluster Produktion | | **Netzwerk** | Standort-Firewall | | **Cloud** | Azure App Service | | **Sicherheit** | TLS-Zertifikat | | **Identität** | Entra-ID-Gruppe | | **Dokumentation** | Betriebsrunbook | | **Lieferant** | Supportvertrag Provider | | **Arbeitsplatz** | Notebook | | **Peripherie** | Etikettendrucker | Welche CI-Typen sinnvoll sind, hängt von Organisation, Services und Steuerungsbedarf ab. --- **Ziel von Service Configuration Management** Service Configuration Management soll sicherstellen, dass verlässliche Informationen verfügbar sind über: - Services, - Configuration Items, - Beziehungen, - Versionen, - Status, - Eigentümer, - Standorte, - Lieferanten, - Abhängigkeiten, - und Änderungen. Diese Informationen unterstützen andere ITIL Practices. Beispiele: - Incident Management erkennt betroffene Services schneller. - Problem Management erkennt gemeinsame Ursachen. - Change Enablement bewertet Auswirkungen besser. - Release Management kennt betroffene Komponenten. - Service Level Management versteht Serviceabhängigkeiten. - Information Security Management erkennt kritische Assets. --- **Service Configuration Management ist mehr als Inventarisierung** Inventarisierung beantwortet oft nur: > Was ist vorhanden? Service Configuration Management beantwortet zusätzlich: > Wie hängt es zusammen und warum ist es für den Service wichtig? Beispiel: Eine Inventarliste zeigt: - Server APP-01, - Datenbank DB-01, - Firewall FW-01. Service Configuration Management zeigt zusätzlich: - APP-01 betreibt das Mitarbeiterportal. - APP-01 nutzt DB-01. - FW-01 ermöglicht Zugriff vom Standort Süd. - Das Mitarbeiterportal ist kritisch für interne Anträge. - Service Owner ist die interne IT. - Provider X unterstützt die Firewall. Diese Beziehungen machen die Informationen im Betrieb wertvoll. --- **CI-Beziehungen** Beziehungen zwischen CIs sind besonders wichtig. Typische Beziehungen: - Service nutzt Anwendung, - Anwendung nutzt Datenbank, - Datenbank nutzt Storage, - Server läuft auf Virtualisierungsplattform, - Anwendung ist abhängig von Identity Provider, - Standort nutzt Firewall, - Zertifikat schützt Webservice, - Monitoring überwacht Server, - Lieferant unterstützt Komponente, - Benutzergruppe erhält Zugriff auf Anwendung. Beziehungen helfen zu verstehen, welche Auswirkungen ein Ausfall oder Change haben kann. --- **Beispiel: Serviceabhängigkeiten** Benutzer ↓ Mitarbeiterportal ↓ Webserver ↓ Anwendungsdienst ↓ Datenbank ↓ Storage Zusätzlich abhängig von: - DNS, - Zertifikat, - Identity Provider, - Netzwerk, - Monitoring, - Backup, - Firewall. Wenn die Datenbank ausfällt, ist das Mitarbeiterportal betroffen. Wenn das Zertifikat abläuft, kann die Anmeldung scheitern. Wenn DNS fehlerhaft ist, erscheint der Service möglicherweise komplett unerreichbar. --- **CMDB** Eine **Configuration Management Database (CMDB)** ist ein System oder Datenbestand, in dem Configuration Items und ihre Beziehungen verwaltet werden. Eine CMDB kann enthalten: - CI-Name, - CI-Typ, - Status, - Version, - Umgebung, - Standort, - Owner, - Lieferant, - Kritikalität, - Beziehungen, - letzte Änderung, - verknüpfte Incidents, - verknüpfte Problems, - verknüpfte Changes, - Dokumentationslinks. Eine CMDB muss nicht zwingend ein einzelnes großes Werkzeug sein. Wichtig ist, dass die benötigten Informationen zuverlässig verfügbar und gepflegt sind. --- **CMDB und CMS unterscheiden** Der Begriff **Configuration Management System (CMS)** kann breiter verstanden werden als eine einzelne CMDB. Ein CMS kann mehrere Datenquellen verbinden. Beispiele: - CMDB, - Asset Management, - Monitoring, - Cloud-Inventar, - Netzwerkdokumentation, - Virtualisierungsplattform, - Endpoint Management, - Softwareverteilung, - Dokumentationssystem, - ITSM-Tool. Die CMDB kann ein Teil dieses größeren Systems sein. --- **Configuration Management und Asset Management unterscheiden** | Configuration Management | Asset Management | |---|---| | Fokus auf Servicebeziehungen und Betriebsrelevanz | Fokus auf Besitz, Kosten, Lebenszyklus und Vertragsdaten | | betrachtet CIs und Abhängigkeiten | betrachtet Assets als wirtschaftliche oder verwaltete Objekte | | wichtig für Incident, Problem und Change | wichtig für Einkauf, Lizenzierung und Lifecycle | | Beispiel: Datenbank ist abhängig von Storage | Beispiel: Server wurde am 12.03.2025 gekauft | Ein Objekt kann gleichzeitig Asset und CI sein. Beispiel: Ein produktiver Server ist wirtschaftlich ein Asset und betrieblich ein CI. --- **Welche Informationen sind sinnvoll?** Nicht jedes Detail muss erfasst werden. Sinnvolle CI-Informationen können sein: - eindeutiger Name, - CI-Typ, - Beschreibung, - Servicezuordnung, - Umgebung, - Status, - Version, - Standort, - Owner, - Supportgruppe, - Lieferant, - Kritikalität, - Beziehungen, - Dokumentationslink, - letzte Prüfung, - letzte Änderung, - Sicherheitsklassifizierung. Zu viele ungenutzte Felder machen Pflege schwer. Zu wenige Informationen machen die Daten im Betrieb wertlos. --- **CI-Status** Ein CI kann unterschiedliche Status besitzen. Beispiele: - geplant, - bestellt, - im Aufbau, - aktiv, - in Wartung, - außer Betrieb, - ersetzt, - archiviert. Der Status hilft zu erkennen, ob ein CI produktiv genutzt wird oder nicht. Beispiel: Ein alter Server darf nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen, wenn er bereits außer Betrieb genommen wurde. --- **Umgebungen kennzeichnen** CIs sollten ihrer Umgebung zugeordnet werden. Beispiele: - Entwicklung, - Test, - Abnahme, - Staging, - Produktion, - Disaster Recovery, - Labor, - Schulung. Das ist wichtig, weil ein Change an einem Testsystem anders bewertet wird als ein Change an einem produktiven System. Unklare Umgebungskennzeichnung kann zu gefährlichen Verwechslungen führen. --- **Kritikalität erfassen** Die Kritikalität beschreibt, wie wichtig ein CI oder Service für die Organisation ist. Beispiele: - geschäftskritisch, - hoch, - mittel, - niedrig, - unterstützend, - nicht produktiv. Die Kritikalität hilft bei: - Priorisierung von Incidents, - Risikobewertung von Changes, - Notfallplanung, - Monitoring, - Patchplanung, - Lieferantensteuerung, - und Service Reviews. Wichtig: Die Kritikalität eines CIs sollte aus der Servicebedeutung abgeleitet werden. --- **Owner und Verantwortlichkeiten** Für wichtige CIs sollte klar sein: - Wer ist fachlich verantwortlich? - Wer ist technisch verantwortlich? - Wer betreibt das CI? - Wer darf Änderungen genehmigen? - Wer pflegt die Dokumentation? - Wer ist Ansprechpartner bei Incidents? - Welcher Lieferant unterstützt das CI? Ohne Owner veralten Informationen schnell. Ungeeignet: > Niemand fühlt sich für das System verantwortlich. Besser: > Service Owner, technischer Owner und Supportgruppe sind dokumentiert. --- **Service Owner und CI Owner unterscheiden** | Rolle | Bedeutung | |---|---| | **Service Owner** | Verantwortung für den gesamten Service und dessen Wertbeitrag | | **CI Owner** | Verantwortung für ein bestimmtes Configuration Item | | **Supportgruppe** | bearbeitet Incidents, Changes oder Betriebsaufgaben | | **Lieferant** | unterstützt oder betreibt bestimmte Komponenten | Ein Service kann viele CIs besitzen. Ein CI kann mehrere Services unterstützen. Deshalb sind Beziehungen und Verantwortlichkeiten wichtig. --- **Datenqualität** Service Configuration Management ist nur hilfreich, wenn die Datenqualität ausreichend ist. Typische Probleme: - veraltete Einträge, - fehlende Beziehungen, - falsche Owner, - doppelte CIs, - unklare Namen, - fehlende Versionen, - nicht dokumentierte Changes, - außer Betrieb genommene Systeme bleiben aktiv, - Cloud-Ressourcen werden nicht erfasst, - manuelle Pflege wird vergessen. Schlechte Datenqualität kann gefährlicher sein als keine Daten, weil sie falsche Sicherheit erzeugt. --- **Datenqualität prüfen** Mögliche Prüffragen: - Existiert das CI noch? - Ist der Status korrekt? - Ist der Owner aktuell? - Stimmen Version und Umgebung? - Sind Beziehungen vollständig? - Ist der betroffene Service verknüpft? - Wurde der letzte Change berücksichtigt? - Sind Lieferant und Supportgruppe korrekt? - Gibt es Dubletten? - Wird das CI noch aktiv genutzt? Regelmäßige Prüfung ist notwendig, besonders bei kritischen Services. --- **Discovery** Discovery bezeichnet das automatische Erkennen von Systemen, Komponenten oder technischen Eigenschaften. Beispiele: - Server erkennen, - installierte Software erfassen, - Netzwerkgeräte finden, - Cloud-Ressourcen inventarisieren, - offene Ports erkennen, - Zertifikate finden, - Versionen auslesen, - Beziehungen ableiten. Discovery kann helfen, Daten aktuell zu halten. Es ersetzt aber nicht jede fachliche Bewertung. Ein Tool kann erkennen, dass ein Server existiert. Es weiß nicht automatisch, welcher Geschäftsprozess davon abhängig ist. --- **Manuelle Pflege** Manche Informationen müssen manuell oder organisatorisch gepflegt werden. Beispiele: - Service Owner, - fachliche Kritikalität, - Geschäftsprozessbezug, - Lieferantenverantwortung, - genehmigte Ausnahme, - Risikoakzeptanz, - Dokumentationslink, - geplante Außerbetriebnahme. Automatische Erkennung und manuelle Pflege müssen zusammenarbeiten. --- **Namenskonventionen** Klare Namenskonventionen helfen, CIs eindeutig zu identifizieren. Beispiele: - Standort, - Umgebung, - Funktion, - laufende Nummer, - Servicebezug. Ungeeignet: - Server1, - Testneu, - Alt-System, - Backup-neu-final, - App2. Besser: - PRD-APP-PORTAL-01, - TST-DB-ERP-02, - BER-FW-STANDORT-01. Die konkrete Namenskonvention muss zur Organisation passen. --- **Configuration Baseline** Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand. Beispiele: - Standardkonfiguration eines Servers, - genehmigte Version einer Anwendung, - geprüfte Firewall-Regelbasis, - freigegebene Client-Konfiguration, - definierter Stand eines Release-Pakets. Baselines helfen bei: - Vergleich mit aktuellem Zustand, - Audit, - Fehlersuche, - Rollback, - Compliance, - Standardisierung. Wenn ein System von der Baseline abweicht, sollte bekannt sein, warum. --- **Abweichungen erkennen** Abweichungen können entstehen durch: - manuelle Änderungen, - ungeplante Changes, - Notfallmaßnahmen, - fehlerhafte Automatisierung, - Lieferantenänderungen, - Schatten-IT, - Konfigurationsdrift, - fehlende Dokumentation. Abweichungen sind nicht automatisch falsch. Sie müssen aber nachvollziehbar und bewertet sein. --- **Service Configuration Management und Incident Management** Bei Incidents helfen Configuration-Daten zu verstehen: - welcher Service betroffen ist, - welche Komponenten beteiligt sind, - welche Abhängigkeiten bestehen, - wer zuständig ist, - welche Changes zuletzt durchgeführt wurden, - welche Known Errors existieren, - ob weitere Services betroffen sein könnten. Beispiel: Eine Anwendung ist nicht erreichbar. Durch CI-Beziehungen wird sichtbar, dass Anwendung, Datenbank und Identity Provider relevant sind. Die Diagnose wird schneller und gezielter. --- **Service Configuration Management und Problem Management** Problem Management nutzt Configuration-Daten, um Ursachen zu erkennen. Beispiele: - mehrere Incidents betreffen dieselbe Version, - mehrere Services hängen vom gleichen Datenbankcluster ab, - ein Standort hat wiederkehrende Netzwerkprobleme, - mehrere Anwendungen nutzen dasselbe Zertifikat, - gleiche Hardwaremodellserie verursacht Ausfälle. Ohne Beziehungen bleiben solche Muster oft verborgen. --- **Service Configuration Management und Change Enablement** Bei Changes helfen Configuration-Daten bei der Auswirkungsbewertung. Zu prüfen ist: - Welche CIs werden geändert? - Welche Services hängen davon ab? - Welche Benutzergruppen sind betroffen? - Welche anderen Changes laufen parallel? - Welche Owner müssen beteiligt werden? - Welche Dokumentation muss aktualisiert werden? - Welche Risiken entstehen? Ein Change ohne Kenntnis der Abhängigkeiten kann unerwartete Incidents erzeugen. --- **Service Configuration Management und Release Management** Release und Deployment benötigen verlässliche Informationen über: - Zielumgebungen, - Versionen, - Komponenten, - Abhängigkeiten, - unterstützte Plattformen, - Konfigurationen, - Schnittstellen, - und Rollback-Zustände. Nach einem Release müssen CI-Daten aktualisiert werden. Sonst stimmen spätere Analysen nicht mehr. --- **Service Configuration Management und Information Security Management** Configuration-Daten unterstützen Sicherheitsarbeit. Beispiele: - kritische Systeme identifizieren, - veraltete Versionen erkennen, - fehlende Patches priorisieren, - Zertifikate überwachen, - externe Schnittstellen erfassen, - Administratorzugänge nachvollziehen, - Datenklassifizierung berücksichtigen, - Shadow IT erkennen, - Notfallpläne erstellen. Sicherheitsmaßnahmen hängen stark davon ab, zu wissen, welche Systeme und Abhängigkeiten existieren. --- **Praxisbeispiel: Abgelaufenes Zertifikat** **Incident** Benutzer können sich nicht am Mitarbeiterportal anmelden. **Analyse** Das TLS-Zertifikat ist abgelaufen. **Configuration Management hilft durch:** - Verknüpfung des Zertifikats mit dem Mitarbeiterportal, - Owner des Zertifikats, - Ablaufdatum, - betroffene Services, - Abhängigkeit zum Identity Provider, - Link zum Erneuerungs-Runbook. **Verbesserung** Zertifikate werden künftig als CIs mit Ablaufdatum, Owner und Monitoring erfasst. --- **Praxisbeispiel: Datenbankcluster** **Situation** Mehrere Anwendungen melden Fehler. **Ohne CI-Beziehungen** Jedes Anwendungsteam sucht getrennt. **Mit CI-Beziehungen** Es wird sichtbar: - alle betroffenen Anwendungen nutzen denselben Datenbankcluster, - der Datenbankcluster nutzt denselben Storage, - Storage zeigt Fehler. **Nutzen** Die Ursache wird schneller eingegrenzt. --- **Praxisbeispiel: Change-Auswirkung** **Change** Firewall-Regel soll angepasst werden. **Configuration Management zeigt:** - welche Services über diese Regel kommunizieren, - welche Standorte betroffen sind, - welche Schnittstellen genutzt werden, - welcher Service Owner beteiligt werden muss, - welche Monitoringprüfungen nach dem Change notwendig sind. **Nutzen** Der Change wird besser bewertet und sicherer umgesetzt. --- **Typische Fehler** **Fehler 1** CMDB wird als reine Inventarliste verstanden. --- **Fehler 2** CIs werden erfasst, aber Beziehungen fehlen. --- **Fehler 3** Daten werden einmal erstellt und danach nicht gepflegt. --- **Fehler 4** Owner sind unbekannt oder veraltet. --- **Fehler 5** Changes aktualisieren die CMDB nicht. --- **Fehler 6** Discovery-Daten werden ungeprüft übernommen. --- **Fehler 7** Zu viele unwichtige Details werden gepflegt, aber wichtige Servicebeziehungen fehlen. --- **Fehler 8** Cloud-Ressourcen und externe Services werden nicht berücksichtigt. --- **Fehler 9** CMDB-Daten werden in Incident, Problem und Change nicht genutzt. --- **Fehler 10** Dubletten und uneinheitliche Namen erschweren die Nutzung. --- **Fehler 11** Kritikalität wird technisch statt geschäftlich bewertet. --- **Fehler 12** Dokumentation und CMDB widersprechen sich. --- **Checkliste CI erfassen** - [ ] eindeutiger Name vergeben - [ ] CI-Typ festgelegt - [ ] betroffener Service verknüpft - [ ] Umgebung dokumentiert - [ ] Status gesetzt - [ ] Version oder Konfiguration erfasst - [ ] Standort oder Plattform dokumentiert - [ ] Owner benannt - [ ] Supportgruppe benannt - [ ] Lieferant erfasst, falls relevant - [ ] Kritikalität bewertet - [ ] Beziehungen zu anderen CIs erfasst - [ ] Dokumentationslink ergänzt --- **Checkliste Beziehungen prüfen** - [ ] Service zu Anwendung verknüpft - [ ] Anwendung zu Datenbank verknüpft - [ ] Anwendung zu Identity Provider verknüpft - [ ] Anwendung zu Netzwerk oder Firewall verknüpft - [ ] Zertifikate verknüpft - [ ] Schnittstellen verknüpft - [ ] Monitoring verknüpft - [ ] Backup oder Wiederherstellung berücksichtigt - [ ] Lieferantenbezug verknüpft - [ ] wichtige Benutzergruppen oder Standorte berücksichtigt --- **Checkliste Datenqualität** - [ ] CI existiert tatsächlich - [ ] Status ist aktuell - [ ] Owner ist aktuell - [ ] Version stimmt - [ ] Umgebung stimmt - [ ] Beziehungen sind plausibel - [ ] keine Dublette vorhanden - [ ] letzter Change wurde berücksichtigt - [ ] Dokumentationslink funktioniert - [ ] Kritikalität ist nachvollziehbar - [ ] nicht mehr genutzte CIs sind archiviert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten täglich mit Configuration Items. Beispiele: - Server, - Netzwerke, - Firewalls, - Clients, - Drucker, - Benutzergruppen, - Zertifikate, - Storage, - Backups, - Monitoring, - Cloud-Ressourcen. Wichtig ist nicht nur, diese Komponenten technisch zu betreiben. Wichtig ist auch zu dokumentieren: - wozu sie gehören, - welche Services davon abhängen, - wer verantwortlich ist, - welche Version genutzt wird, - welche Änderungen erfolgt sind, - und welche Risiken bestehen. Gute Configuration-Daten machen Fehleranalyse, Changes und Servicebetrieb deutlich sicherer. --- **Zusammenfassung** > Service und Komponenten identifizieren > ↓ > wichtige Configuration Items festlegen > ↓ > Eigenschaften und Owner dokumentieren > ↓ > Beziehungen zwischen CIs erfassen > ↓ > Datenqualität prüfen > ↓ > Changes und Releases einbeziehen > ↓ > Informationen in Incident, Problem und Change nutzen > ↓ > CMDB oder CMS kontinuierlich pflegen und verbessern --- **Merksätze** > Service Configuration Management ist mehr als Inventarisierung. > Beziehungen zwischen CIs sind oft wichtiger als einzelne technische Details. > Eine CMDB ist nur so wertvoll wie ihre Datenqualität. > Discovery hilft, ersetzt aber keine fachliche Verantwortung. > Ohne aktuelle Configuration-Daten werden Incidents, Problems und Changes riskanter. > Jede wichtige Änderung sollte auch die Configuration-Daten aktualisieren. --- **Verwandte Seiten** - 6.2 Configuration Items und Beziehungen - 6.3 Configuration Management Database - 6.4 Discovery, Pflege und Datenqualität - 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management - Incident Management - Problem Management - Change Enablement - Release Management - Information Security Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: IT Asset Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - CI-Beispiele, - CMDB-Inhalte, - Beziehungsmodelle, - Checklisten, - Praxisbeispiele, - und Datenqualitätskriterien sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - CMDB-Struktur, - CI-Typenliste, - Pflichtfeldliste, - Namenskonvention, - Discovery-Pflicht, - oder konkrete Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisationsgröße, - Toollandschaft, - Datenqualität, - Sicherheitsanforderungen, - Supportmodell, - Change-Modell, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6.2 Configuration Items und Beziehungen > **Kurz erklärt** > > Ein **Configuration Item (CI)** ist ein Bestandteil, der für einen IT-Service wichtig ist und deshalb verwaltet werden soll. > > Beziehungen zwischen CIs zeigen, wie Services, Anwendungen, Systeme, Netzwerke, Datenbanken, Zertifikate, Lieferanten und andere Bestandteile zusammenhängen. > > Der eigentliche Wert entsteht nicht nur durch die Liste einzelner CIs, sondern durch das Verständnis ihrer Abhängigkeiten. --- **Warum Configuration Items wichtig sind** IT-Services bestehen meistens aus mehreren technischen und organisatorischen Bestandteilen. Beispiel: Ein Mitarbeiterportal kann abhängig sein von: - Webserver, - Anwendung, - Datenbank, - Identity Provider, - MFA, - DNS, - Zertifikat, - Load Balancer, - Firewall, - Storage, - Backup, - Monitoring, - Schnittstellen, - Lieferant, - Dokumentation, - und Supportgruppe. Wenn diese Bestandteile nicht bekannt sind, werden Incidents, Problems und Changes schwieriger. Configuration Items helfen dabei, diese Bestandteile strukturiert zu erfassen. --- **Was ist ein Configuration Item?** Ein Configuration Item ist ein Element, das für die Bereitstellung, den Betrieb, die Steuerung oder die Unterstützung eines Service relevant ist. Ein CI kann technisch oder nicht-technisch sein. Beispiele: - Server, - Anwendung, - Datenbank, - Netzwerkgerät, - Firewall-Regel, - Zertifikat, - Cloud-Ressource, - Benutzergruppe, - Service, - Schnittstelle, - Dokumentation, - Lieferantenvertrag, - Lizenz, - Monitoringregel, - Backupjob, - Arbeitsplatzgerät, - Drucker. Nicht jedes vorhandene Objekt muss automatisch ein CI sein. Entscheidend ist, ob das Objekt für Servicebetrieb, Risiko, Support, Change oder Steuerung relevant ist. --- **CI ist nicht gleich Asset** Ein Asset ist häufig ein wirtschaftlich oder vertraglich relevantes Objekt. Ein CI ist ein für den Servicebetrieb relevantes Objekt. | Asset | Configuration Item | |---|---| | Fokus auf Besitz, Kosten, Vertrag oder Lebenszyklus | Fokus auf Servicebeziehung, Abhängigkeit und Betrieb | | wichtig für Einkauf und Lizenzierung | wichtig für Incident, Problem, Change und Release | | Beispiel: Notebook mit Kaufdatum | Beispiel: Notebook als Teil eines verwalteten Arbeitsplatzservices | | Beispiel: Server als Anlagegut | Beispiel: Server als Bestandteil einer produktiven Anwendung | Ein Objekt kann gleichzeitig Asset und CI sein. Beispiel: Ein produktiver Datenbankserver ist ein Asset und gleichzeitig ein CI. --- **Welche Objekte sollten als CI erfasst werden?** Ein Objekt sollte eher als CI erfasst werden, wenn: - ein Service davon abhängig ist, - ein Ausfall Benutzer betrifft, - Changes daran risikoreich sind, - es für Sicherheitsbewertung wichtig ist, - es für Incident-Diagnose benötigt wird, - es eine relevante Version oder Konfiguration besitzt, - es durch einen Lieferanten unterstützt wird, - es eine wichtige Beziehung zu anderen Komponenten hat, - es für Compliance, Audit oder Nachvollziehbarkeit wichtig ist, - oder es in Problem- und Change-Analysen regelmäßig benötigt wird. Ein Objekt muss nicht erfasst werden, nur weil es technisch existiert. Die Pflege muss einen praktischen Nutzen haben. --- **Beispiele für CI-Typen** | CI-Typ | Beispiel | |---|---| | **Business Service** | Mitarbeiterportal | | **Technical Service** | Datenbankplattform | | **Anwendung** | Warenwirtschaft | | **Server** | PRD-APP-PORTAL-01 | | **Datenbank** | SQL-Cluster Produktion | | **Netzwerkgerät** | Standort-Firewall | | **Cloud-Ressource** | App Service, Storage Account | | **Sicherheit** | TLS-Zertifikat, MFA-Richtlinie | | **Identität** | Entra-ID-Gruppe | | **Schnittstelle** | REST-API zum ERP-System | | **Monitoring** | Alarmregel für Zertifikatsablauf | | **Backup** | Backupjob für Datenbank | | **Dokumentation** | Betriebsrunbook | | **Lieferant** | Supportvertrag Provider | Die CI-Typen sollten zur Organisation passen. Zu viele CI-Typen können die Pflege unnötig erschweren. Zu wenige CI-Typen können wichtige Unterschiede verdecken. --- **Service-CI und technische CIs unterscheiden** Ein Service selbst kann als CI betrachtet werden. Beispiel: - Service: Mitarbeiterportal - Anwendung: Portal-App - Server: Webserver - Datenbank: Portal-DB - Zertifikat: portal.example.tld - Identity Provider: zentrale Anmeldung - Supportgruppe: Application Support Der Service ist das, was Benutzer wahrnehmen. Die technischen CIs sind Bestandteile, die den Service ermöglichen. Diese Unterscheidung hilft, technische Informationen mit Benutzer- und Geschäftsbezug zu verbinden. --- **Attribute eines Configuration Items** Ein CI sollte nur so viele Attribute besitzen, wie sinnvoll gepflegt und genutzt werden können. Mögliche Attribute: - CI-Name, - CI-Typ, - Beschreibung, - Status, - Umgebung, - Version, - Standort, - Servicezuordnung, - Owner, - Supportgruppe, - Lieferant, - Kritikalität, - Sicherheitsklassifizierung, - Dokumentationslink, - letzte Änderung, - letzte Prüfung, - Beziehungen, - verknüpfte Incidents, - verknüpfte Problems, - verknüpfte Changes. Wichtig ist nicht maximale Datenmenge. Wichtig ist nutzbare Datenqualität. --- **CI-Name** Der CI-Name sollte eindeutig und verständlich sein. Ungeeignet: - Server1, - AppNeu, - TestAlt, - FirewallFinal, - Datenbank2. Besser: - PRD-APP-PORTAL-01, - TST-DB-ERP-02, - BER-FW-STANDORT-01, - PRD-CERT-PORTAL-2026, - PRD-API-ERP-PARTNER. Eine Namenskonvention kann enthalten: - Umgebung, - Standort, - Funktion, - Servicebezug, - laufende Nummer. Die konkrete Namenskonvention muss zur Organisation passen. --- **CI-Status** Der Status zeigt, in welchem Zustand sich ein CI befindet. Mögliche Status: - geplant, - bestellt, - im Aufbau, - aktiv, - in Wartung, - gesperrt, - außer Betrieb, - ersetzt, - archiviert. Der Status ist wichtig für: - Incident-Diagnose, - Change-Planung, - Sicherheitsbewertung, - Lizenz- und Asset-Abgleich, - Außerbetriebnahme, - und Dokumentationspflege. Ein CI, das außer Betrieb ist, sollte nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen. --- **Umgebung** Die Umgebung zeigt, wo ein CI genutzt wird. Beispiele: - Entwicklung, - Test, - Integration, - Abnahme, - Staging, - Produktion, - Disaster Recovery, - Labor, - Schulung. Ein Change an einem Testsystem ist anders zu bewerten als ein Change an einem produktiven System. Fehlende Umgebungskennzeichnung kann gefährlich sein. Beispiel: Ein Administrator führt eine Änderung auf einem System aus, das für Test gehalten wird, tatsächlich aber produktiv ist. --- **Version und Konfiguration** Für viele CIs ist die Version wichtig. Beispiele: - Betriebssystemversion, - Anwendungsversion, - Datenbankversion, - Firmwareversion, - Clientversion, - Konfigurationsstand, - Zertifikatslaufzeit, - API-Version, - Treiberversion. Versionen helfen bei: - Incident-Diagnose, - Known Errors, - Sicherheitsbewertung, - Patchmanagement, - Release Management, - Problem Management, - und Change-Bewertung. Beispiel: Wenn nur VPN-Client-Version 5.8 betroffen ist, muss diese Information auffindbar sein. --- **Owner und Supportgruppe** Für wichtige CIs sollte klar sein: - Wer ist fachlich verantwortlich? - Wer ist technisch verantwortlich? - Wer betreibt das CI? - Wer unterstützt bei Incidents? - Wer darf Changes genehmigen? - Wer pflegt Dokumentation? - Welcher Lieferant ist beteiligt? Unklare Verantwortlichkeiten führen zu Verzögerungen. Ungeeignet: > Niemand weiß, wem dieser Server gehört. Besser: > Service Owner, technischer Owner, Supportgruppe und Lieferant sind dokumentiert. --- **Kritikalität** Die Kritikalität beschreibt, wie wichtig ein CI oder der zugehörige Service ist. Mögliche Stufen: - geschäftskritisch, - hoch, - mittel, - niedrig, - nicht produktiv. Die Kritikalität beeinflusst: - Incident-Priorisierung, - Change-Risikobewertung, - Monitoring, - Backup-Anforderungen, - Patchplanung, - Notfallplanung, - Lieferantensteuerung, - und Service Reviews. Wichtig: Die Kritikalität sollte nicht nur technisch bewertet werden. Ein unscheinbarer Server kann geschäftskritisch sein, wenn ein zentraler Prozess davon abhängt. --- **Sicherheitsklassifizierung** Manche CIs benötigen zusätzliche Sicherheitsinformationen. Beispiele: - enthält personenbezogene Daten, - verarbeitet vertrauliche Daten, - besitzt Internetzugang, - ist extern erreichbar, - besitzt Administratorzugänge, - ist Teil kritischer Infrastruktur, - ist auditrelevant, - verarbeitet Zahlungsdaten, - besitzt erhöhte Verfügbarkeitspflichten. Solche Informationen helfen bei: - Risikobewertung, - Change Enablement, - Sicherheitsvorfällen, - Patchpriorisierung, - Zugriffskontrolle, - und Compliance. --- **Was sind CI-Beziehungen?** CI-Beziehungen beschreiben, wie Configuration Items miteinander verbunden sind. Beispiele: - Service nutzt Anwendung, - Anwendung läuft auf Server, - Server nutzt Storage, - Anwendung nutzt Datenbank, - Anwendung authentifiziert gegen Identity Provider, - Webservice nutzt Zertifikat, - Standort nutzt Firewall, - Anwendung kommuniziert mit API, - Monitoring überwacht Service, - Backupjob sichert Datenbank, - Lieferant unterstützt System. Beziehungen machen sichtbar, welche Auswirkungen ein Ausfall oder Change haben kann. --- **Warum Beziehungen wichtiger sind als Einzelinformationen** Eine Liste einzelner CIs beantwortet nur: > Was gibt es? Beziehungen beantworten: > Was hängt wovon ab? Beispiel: CI-Liste: - APP-01, - DB-01, - FW-01, - CERT-01. Beziehungen: - Mitarbeiterportal läuft auf APP-01. - APP-01 nutzt DB-01. - APP-01 ist über FW-01 erreichbar. - Mitarbeiterportal nutzt CERT-01. - DB-01 nutzt Storage-Cluster PRD-STO-01. Erst durch Beziehungen wird klar, welche Komponenten gemeinsam einen Service ermöglichen. --- **Typische Beziehungstypen** | Beziehung | Bedeutung | |---|---| | **nutzt** | Ein CI verwendet ein anderes CI | | **läuft auf** | Anwendung läuft auf Server oder Plattform | | **ist abhängig von** | Service funktioniert nur mit anderem CI | | **verbindet zu** | Netzwerk- oder Schnittstellenbeziehung | | **wird überwacht von** | Monitoringbeziehung | | **wird gesichert durch** | Backupbeziehung | | **wird unterstützt von** | Lieferanten- oder Supportbeziehung | | **ist Teil von** | Komponente gehört zu größerem Service | | **ersetzt** | neues CI ersetzt altes CI | | **kommuniziert mit** | technische Schnittstelle zwischen Systemen | Die Beziehungsarten sollten verständlich und einheitlich genutzt werden. --- **Beispiel: Mitarbeiterportal** Mitarbeiterportal ↓ nutzt Portal-Anwendung ↓ läuft auf Webserver PRD-APP-PORTAL-01 ↓ nutzt Datenbank PRD-DB-PORTAL-01 ↓ nutzt Storage PRD-STO-01 Weitere Beziehungen: - Mitarbeiterportal nutzt DNS-Eintrag portal.example.tld. - Mitarbeiterportal nutzt TLS-Zertifikat PRD-CERT-PORTAL. - Mitarbeiterportal nutzt Identity Provider. - Webserver wird durch Monitoring überwacht. - Datenbank wird durch Backupjob gesichert. - Anwendung wird durch Application Support betreut. --- **Beispiel: VPN-Service** VPN-Service ↓ nutzt VPN-Gateway ↓ nutzt Firewall ↓ nutzt Internetanbindung Zusätzliche Abhängigkeiten: - VPN-Client, - Zertifikat, - MFA, - Identity Provider, - Benutzergruppen, - DNS, - Monitoring, - Netzwerkteam, - Lieferant. Wenn MFA ausfällt, kann der VPN-Service betroffen sein, obwohl das VPN-Gateway technisch läuft. --- **Beispiel: Druckservice** Druckservice ↓ nutzt Druckserver ↓ verwaltet Netzwerkdrucker ↓ nutzt Netzwerksegment Weitere Abhängigkeiten: - Druckertreiber, - Benutzerberechtigungen, - Spooler-Dienst, - Papier- und Verbrauchsmaterial, - Standortnetz, - Fachanwendung, - Etikettenvorlagen. Ein Druckproblem kann also viele Ursachen haben. Ohne Beziehungen wird oft nur der Drucker selbst betrachtet. --- **Beispiel: Schnittstelle zwischen Anwendungen** Anwendung A ↓ sendet Daten an API-Gateway ↓ leitet weiter an Anwendung B ↓ schreibt in Datenbank B Zusätzliche Abhängigkeiten: - Zertifikat, - Firewall-Regel, - DNS, - API-Token, - Berechtigungen, - Monitoring, - Lieferant, - Datenformat. Eine kleine Änderung am API-Token kann den gesamten Datenaustausch stoppen. --- **Beziehungen und Incident Management** Bei Incidents helfen Beziehungen, die Auswirkung zu verstehen. Beispiele: - Welcher Service ist betroffen? - Welche CIs sind beteiligt? - Gibt es eine gemeinsame Abhängigkeit? - Welche anderen Services könnten betroffen sein? - Wer ist zuständig? - Welche Changes wurden zuletzt an beteiligten CIs durchgeführt? - Gibt es Known Errors für diese Version oder Komponente? Beispiel: Mehrere Anwendungen melden Fehler. CI-Beziehungen zeigen, dass alle denselben Datenbankcluster nutzen. Die Diagnose wird schneller eingegrenzt. --- **Beziehungen und Problem Management** Problem Management nutzt CI-Beziehungen, um Muster zu erkennen. Beispiele: - wiederkehrende Incidents betreffen dieselbe Hardwaremodellserie, - mehrere Services nutzen dasselbe Zertifikat, - mehrere Anwendungen sind von derselben Schnittstelle abhängig, - ein Standort hat Probleme mit derselben Firewall, - eine bestimmte Clientversion erzeugt viele Tickets. Ohne Beziehungen bleiben solche Muster oft unsichtbar. --- **Beziehungen und Change Enablement** Bei Changes sind Beziehungen besonders wichtig. Zu prüfen ist: - Welche CIs werden geändert? - Welche Services hängen davon ab? - Welche Benutzergruppen sind betroffen? - Welche Schnittstellen werden beeinflusst? - Welche anderen Teams müssen beteiligt werden? - Welche Dokumentation muss aktualisiert werden? - Welche Tests sind notwendig? - Welche Rollback-Auswirkungen gibt es? Ein Change an einem kleinen CI kann große Auswirkungen haben, wenn viele Services davon abhängen. --- **Beispiel: Change-Auswirkung durch Beziehung** **Change** Ein Zertifikat soll erneuert werden. **Ohne Beziehung** Es wird nur der Webserver betrachtet. **Mit Beziehung** Es wird sichtbar: - Zertifikat wird vom Mitarbeiterportal genutzt, - Anmeldung läuft über Identity Provider, - externe Schnittstelle prüft Zertifikatskette, - Monitoring muss nach Erneuerung geprüft werden, - Service Desk muss mögliche Anmeldefehler kennen. Dadurch wird der Change besser geplant. --- **Beziehungen und Release Management** Release Management benötigt Beziehungen, um zu verstehen: - welche Komponenten Bestandteil des Releases sind, - welche Zielumgebungen betroffen sind, - welche Abhängigkeiten bestehen, - welche Versionen zusammenpassen, - welche Benutzergruppen betroffen sind, - welche Knowledge-Artikel aktualisiert werden müssen. Ein Release kann fehlschlagen, wenn eine abhängige Komponente vergessen wird. --- **Beziehungen und Information Security Management** Sicherheitsarbeit benötigt CI-Beziehungen. Beispiele: - Welche Services sind extern erreichbar? - Welche Systeme verarbeiten vertrauliche Daten? - Welche Anwendungen nutzen ein gefährdetes Zertifikat? - Welche Server verwenden eine verwundbare Softwareversion? - Welche Benutzergruppen haben Zugriff? - Welche Schnittstellen übertragen sensible Daten? - Welche Systeme sind von einem kompromittierten Konto betroffen? Ohne Beziehungen ist Sicherheitsbewertung unvollständig. --- **Beziehungen und Notfallplanung** Für Notfallplanung sind Abhängigkeiten entscheidend. Zu klären ist: - Welche Services sind geschäftskritisch? - Welche CIs werden für Wiederherstellung benötigt? - Welche Reihenfolge ist beim Wiederanlauf notwendig? - Welche Datenbanken müssen zuerst verfügbar sein? - Welche Netzwerkverbindungen sind erforderlich? - Welche Lieferanten müssen erreichbar sein? - Welche Backupjobs gehören zu welchem Service? - Welche Dokumentation wird im Notfall benötigt? Ein Wiederanlaufplan ohne Abhängigkeiten ist häufig unvollständig. --- **Tiefe der Beziehungspflege** Nicht jede Beziehung muss bis ins kleinste Detail gepflegt werden. Zu klären ist: - Welche Beziehungen werden wirklich genutzt? - Welche Beziehungen helfen bei Incident, Problem und Change? - Welche Services sind kritisch? - Welche CIs ändern sich häufig? - Welche Daten können automatisiert gepflegt werden? - Welche Daten müssen manuell gepflegt werden? Zu wenig Beziehungspflege macht die CMDB nutzlos. Zu viel Detailtiefe macht sie schwer wartbar. --- **Beispiel für sinnvolle Detailtiefe** Für einen geschäftskritischen Service sinnvoll: - Service, - Anwendung, - Datenbank, - Server, - Netzwerk, - Zertifikat, - Identity Provider, - Backup, - Monitoring, - Owner, - Lieferant, - wichtigste Schnittstellen. Für einen einfachen Testservice kann weniger Detail genügen. Die Pflege muss zum Risiko passen. --- **Horizontale und vertikale Beziehungen** **Vertikale Beziehungen** zeigen den Aufbau eines Service von oben nach unten. Beispiel: Service ↓ Anwendung ↓ Server ↓ Plattform ↓ Storage **Horizontale Beziehungen** zeigen Verbindungen zwischen gleichartigen oder verbundenen Komponenten. Beispiel: Anwendung A ↔ API ↔ Anwendung B Beide Beziehungstypen sind wichtig. Vertikale Beziehungen helfen bei Auswirkungsanalyse. Horizontale Beziehungen helfen bei Schnittstellen- und Kommunikationsproblemen. --- **Upstream und Downstream** Bei Schnittstellen wird oft zwischen Upstream und Downstream unterschieden. | Begriff | Bedeutung | |---|---| | **Upstream** | vorgelagertes System, von dem Daten oder Dienste kommen | | **Downstream** | nachgelagertes System, das Daten oder Dienste erhält | Beispiel: CRM-System ↓ sendet Kundendaten an ERP-System ↓ sendet Rechnungsdaten an Buchhaltungssystem Wenn das CRM-System fehlerhafte Daten liefert, können downstream weitere Probleme entstehen. --- **Single Point of Failure erkennen** CI-Beziehungen können Single Points of Failure sichtbar machen. Beispiel: Mehrere Services nutzen denselben Datenbankserver. Wenn dieser Server ausfällt, sind alle Services betroffen. Mögliche Maßnahmen: - Hochverfügbarkeit prüfen, - Backup und Restore testen, - Monitoring verbessern, - Kapazität planen, - Change-Risiko erhöhen, - Notfallverfahren dokumentieren. Beziehungen helfen also nicht nur bei Dokumentation, sondern auch bei Risikobewertung. --- **Dubletten und Namensprobleme** CI-Beziehungen werden unbrauchbar, wenn CIs mehrfach oder uneinheitlich erfasst sind. Beispiele: - APP-01, - app01, - AppServer Portal, - PRD-APP-PORTAL-01 beschreiben möglicherweise dasselbe System. Folgen: - Incidents werden falsch verknüpft, - Changes wirken unvollständig, - Beziehungen fehlen, - Reports werden ungenau, - Owner erscheinen widersprüchlich. Namenskonventionen und Dublettenprüfung sind deshalb wichtig. --- **Veraltete Beziehungen** Beziehungen können veralten durch: - Migrationen, - Releases, - Servertausch, - Cloud-Umzug, - neue Schnittstellen, - Außerbetriebnahme, - Notfalländerungen, - Lieferantenwechsel, - Prozessänderungen. Veraltete Beziehungen sind riskant. Beispiel: Ein Change wird als unkritisch bewertet, weil eine alte Beziehung fehlt. Nach Umsetzung fällt ein abhängiger Service aus. --- **Beziehungen durch Changes aktualisieren** Jeder relevante Change sollte prüfen: - Wurde ein CI geändert? - Wurde ein CI neu erstellt? - Wurde ein CI entfernt? - Hat sich eine Version geändert? - Hat sich eine Beziehung geändert? - Hat sich ein Owner geändert? - Hat sich eine Schnittstelle geändert? - Hat sich ein Zertifikat geändert? - Muss die CMDB aktualisiert werden? Configuration Management darf nicht getrennt von Change Enablement betrachtet werden. --- **Beziehungen durch Discovery erkennen** Technische Beziehungen können teilweise automatisch erkannt werden. Beispiele: - Server kommuniziert mit Datenbank, - Anwendung öffnet Verbindung zu API, - Zertifikat ist auf Webserver installiert, - Softwareversion ist vorhanden, - Netzwerkgerät ist erreichbar, - Cloud-Ressource existiert. Aber: Discovery erkennt nicht immer fachliche Bedeutung. Ein Tool kann eine Verbindung sehen. Es weiß nicht automatisch, ob diese Verbindung geschäftskritisch ist. --- **Manuell gepflegte Beziehungen** Manuell gepflegt werden oft: - Service Owner, - fachliche Kritikalität, - Geschäftsprozessbezug, - Supportmodell, - Lieferantenverantwortung, - Risikoakzeptanz, - geplante Ablösung, - Dokumentationslinks, - fachliche Schnittstellenbedeutung. Diese Informationen brauchen Verantwortliche und regelmäßige Prüfung. --- **Beziehungen visualisieren** CI-Beziehungen können als Diagramm, Tabelle oder Abhängigkeitsansicht dargestellt werden. Mögliche Formen: - Service Map, - Abhängigkeitsdiagramm, - Schnittstellenübersicht, - Tabellenansicht, - Netzwerkplan, - CMDB-Beziehungsansicht, - Architekturdiagramm. Wichtig ist, dass die Darstellung für den Zweck geeignet ist. Ein Management-Review benötigt andere Details als eine technische Fehleranalyse. --- **Service Map** Eine Service Map zeigt die wichtigsten Bestandteile eines Services. Beispiel: Service: Mitarbeiterportal Benutzer ↓ DNS ↓ Load Balancer ↓ Webserver ↓ Anwendung ↓ Datenbank ↓ Storage Zusätzlich: Identity Provider, Zertifikat, Monitoring, Backup, Supportgruppe Eine Service Map muss nicht jedes Detail enthalten. Sie soll die wichtigsten Abhängigkeiten verständlich machen. --- **Tabellarische Beziehungspflege** Eine einfache Tabelle kann für kleinere Umgebungen ausreichend sein. | Service | CI | Beziehung | Abhängig von | Owner | |---|---|---|---|---| | Mitarbeiterportal | Portal-App | läuft auf | PRD-APP-PORTAL-01 | App-Team | | Mitarbeiterportal | Portal-App | nutzt | PRD-DB-PORTAL-01 | DB-Team | | Mitarbeiterportal | Portal-App | nutzt | Identity Provider | IAM-Team | | Mitarbeiterportal | Webservice | nutzt | TLS-Zertifikat | Plattform-Team | Wichtig ist, dass die Tabelle gepflegt und genutzt wird. --- **CI-Beziehungen in Tickets nutzen** Tickets sollten relevante CIs enthalten. Das hilft bei: - Auswirkungsanalyse, - Priorisierung, - Eskalation, - Trendanalyse, - Problem Management, - Change-Verknüpfung, - Reporting. Beispiel: Ein Incident wird nicht nur als „Anwendung gestört“ erfasst. Er wird mit Service, Anwendungsversion, Datenbank und betroffener Schnittstelle verknüpft. Dadurch können spätere Muster erkannt werden. --- **CI-Beziehungen in Changes nutzen** Ein Change Request sollte betroffene CIs enthalten. Beispiele: - Zielserver, - Anwendung, - Datenbank, - Zertifikat, - Firewall-Regel, - Schnittstelle, - Monitoringregel, - Dokumentation. Zusätzlich sollten abhängige Services geprüft werden. Ein Change an einer zentralen Komponente muss anders bewertet werden als ein Change an einem isolierten Testsystem. --- **CI-Beziehungen in Problems nutzen** Ein Problem Record sollte relevante CIs und Beziehungen enthalten. Beispiel: Mehrere Incidents betreffen verschiedene Anwendungen. Problem Management erkennt: - alle Anwendungen nutzen dieselbe API, - API nutzt ein ablaufendes Zertifikat, - Zertifikatsmonitoring fehlt. Die CI-Beziehung hilft, eine gemeinsame Ursache zu finden. --- **Praxisbeispiel: Datenbank als gemeinsame Abhängigkeit** **Situation** Drei Anwendungen melden Performance-Probleme. **Einzelbetrachtung** Jedes Team sucht zunächst in seiner Anwendung. **CI-Beziehungen zeigen** - alle drei Anwendungen nutzen denselben Datenbankcluster, - Datenbankcluster nutzt denselben Storage, - Storage zeigt hohe Latenz. **Nutzen** Die Analyse wird schneller auf die gemeinsame Abhängigkeit gelenkt. --- **Praxisbeispiel: Zertifikat als CI** **Situation** Anmeldung am Service schlägt fehl. **CI-Beziehungen zeigen** - Service nutzt Webzertifikat, - Zertifikat läuft heute ab, - Identity Provider prüft Zertifikatskette, - Monitoring überwacht nur HTTP-Status, nicht Zertifikatslaufzeit. **Verbesserung** Zertifikate werden künftig als eigene CIs mit Ablaufdatum, Owner und Monitoringbeziehung gepflegt. --- **Praxisbeispiel: Standort-Firewall** **Situation** Ein Standort meldet Zugriffsstörungen. **CI-Beziehungen zeigen** - Standort nutzt bestimmte Firewall, - mehrere Services laufen über dieselbe VPN-Verbindung, - letzte Änderung war eine Firewall-Regel, - betroffene Benutzergruppe sitzt nur an diesem Standort. **Nutzen** Die Fehlersuche wird auf Standortnetz, Firewall und VPN eingegrenzt. --- **Praxisbeispiel: Veraltete Beziehung** **Situation** Eine alte Datenbank wird abgeschaltet. **Problem** In der CMDB ist nicht dokumentiert, dass ein Reporting-Service noch darauf zugreift. **Folge** Nach Abschaltung fällt das Reporting aus. **Lerneffekt** Vor Außerbetriebnahme müssen Abhängigkeiten geprüft und alte Beziehungen bereinigt werden. --- **Typische Fehler** **Fehler 1** Nur technische Geräte werden als CIs betrachtet. --- **Fehler 2** Services selbst werden nicht als CIs erfasst. --- **Fehler 3** Beziehungen zwischen CIs fehlen. --- **Fehler 4** Beziehungen werden einmal erstellt und danach nicht gepflegt. --- **Fehler 5** Zu viele unwichtige Details werden gepflegt, aber wichtige Abhängigkeiten fehlen. --- **Fehler 6** CIs haben keinen Owner. --- **Fehler 7** CI-Namen sind uneinheitlich oder doppelt. --- **Fehler 8** Discovery-Daten werden ohne fachliche Prüfung übernommen. --- **Fehler 9** Changes aktualisieren CI-Beziehungen nicht. --- **Fehler 10** Tickets werden nicht mit betroffenen CIs verknüpft. --- **Fehler 11** Kritikalität wird ohne Servicebezug bewertet. --- **Fehler 12** Schnittstellen, Zertifikate und Cloud-Ressourcen werden vergessen. --- **Checkliste: Ist ein Objekt ein sinnvolles CI?** - [ ] unterstützt es einen Service? - [ ] kann ein Ausfall Benutzer betreffen? - [ ] ist es für Incidents relevant? - [ ] ist es für Problems relevant? - [ ] ist es für Changes relevant? - [ ] besitzt es wichtige Beziehungen? - [ ] besitzt es relevante Versionen oder Konfigurationen? - [ ] hat es Sicherheits- oder Compliance-Bedeutung? - [ ] braucht es einen Owner? - [ ] muss es regelmäßig geprüft werden? - [ ] lohnt sich der Pflegeaufwand? --- **Checkliste CI-Attribute** - [ ] eindeutiger Name - [ ] CI-Typ - [ ] Beschreibung - [ ] Status - [ ] Umgebung - [ ] Version oder Konfigurationsstand - [ ] betroffener Service - [ ] Owner - [ ] Supportgruppe - [ ] Lieferant, falls relevant - [ ] Kritikalität - [ ] Sicherheitsklassifizierung, falls relevant - [ ] Dokumentationslink - [ ] letzte Prüfung - [ ] relevante Beziehungen --- **Checkliste CI-Beziehungen** - [ ] Service zu Anwendung verknüpft - [ ] Anwendung zu Server oder Plattform verknüpft - [ ] Anwendung zu Datenbank verknüpft - [ ] Anwendung zu Schnittstellen verknüpft - [ ] DNS-Abhängigkeit geprüft - [ ] Zertifikate verknüpft - [ ] Identity Provider oder MFA verknüpft - [ ] Netzwerk und Firewall berücksichtigt - [ ] Storage berücksichtigt - [ ] Backup berücksichtigt - [ ] Monitoring berücksichtigt - [ ] Lieferant berücksichtigt - [ ] Supportgruppe verknüpft - [ ] Dokumentation verknüpft --- **Checkliste Beziehungspflege nach Changes** - [ ] neue CIs angelegt - [ ] entfernte CIs archiviert - [ ] geänderte Versionen aktualisiert - [ ] geänderte Schnittstellen dokumentiert - [ ] neue Abhängigkeiten ergänzt - [ ] entfernte Abhängigkeiten gelöscht - [ ] Owner aktualisiert - [ ] Lieferantenbezug aktualisiert - [ ] Dokumentationslinks geprüft - [ ] Monitoring- und Backupbeziehungen geprüft - [ ] Service Map aktualisiert - [ ] Ticket oder Change Record verknüpft --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten praktisch mit vielen Configuration Items. Beispiele: - Server, - Clients, - Firewalls, - Switches, - VPN, - Drucker, - Benutzergruppen, - Zertifikate, - Backupjobs, - Monitoringregeln, - Cloud-Ressourcen, - Anwendungen, - Schnittstellen. Wichtig ist nicht nur, diese Komponenten technisch zu kennen. Wichtig ist auch zu verstehen: - welcher Service davon abhängt, - welche Benutzer betroffen wären, - welche Changes riskant sind, - welche Beziehungen bei Fehleranalyse helfen, - wer zuständig ist, - und welche Informationen aktuell gehalten werden müssen. Gute CI-Beziehungen machen technische Arbeit schneller, sicherer und nachvollziehbarer. --- **Zusammenfassung** > wichtige Services identifizieren > ↓ > relevante Configuration Items bestimmen > ↓ > sinnvolle Attribute erfassen > ↓ > Owner und Kritikalität festlegen > ↓ > Beziehungen zwischen CIs dokumentieren > ↓ > Serviceabhängigkeiten sichtbar machen > ↓ > CIs in Incidents, Problems und Changes nutzen > ↓ > Beziehungen nach Changes aktualisieren > ↓ > Datenqualität regelmäßig prüfen --- **Merksätze** > Ein CI ist nur dann wertvoll, wenn es für den Servicebetrieb relevant ist. > Beziehungen zeigen, welche Auswirkungen ein Ausfall oder Change haben kann. > Eine CI-Liste ohne Beziehungen ist nur begrenzt hilfreich. > Technisch kleine Komponenten können geschäftlich sehr wichtig sein. > Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung. > CI-Beziehungen müssen nach Changes gepflegt werden. > Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management. --- **Verwandte Seiten** - 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen - 6.3 Configuration Management Database - 6.4 Discovery, Pflege und Datenqualität - 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management - Incident Management - Problem Management - Change Enablement - Release Management - Information Security Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: IT Asset Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - CI-Beispiele, - Beziehungstypen, - Service-Maps, - Tabellen, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - CI-Typenliste, - Beziehungstypenliste, - Attributliste, - Service-Map-Struktur, - Namenskonvention, - oder konkrete Modellierungstiefe für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Supportmodell, - Organisationsgröße, - Toollandschaft, - Datenqualität, - Sicherheitsanforderungen, - Change-Modell, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6.3 Configuration Management Database > **Kurz erklärt** > > Eine **Configuration Management Database (CMDB)** ist ein Datenbestand oder Werkzeug, in dem Configuration Items und ihre Beziehungen verwaltet werden. > > Sie hilft dabei, Services, Systeme, Komponenten, Versionen, Verantwortlichkeiten und Abhängigkeiten nachvollziehbar zu dokumentieren. > > Der Wert einer CMDB entsteht nicht durch möglichst viele Einträge, sondern durch aktuelle, verlässliche und nutzbare Informationen für Incident, Problem, Change, Release und Security Management. --- **Warum eine CMDB wichtig ist** IT-Services bestehen aus vielen abhängigen Bestandteilen. Ohne zentrale oder verlässliche Configuration-Daten entstehen typische Probleme: - niemand weiß genau, welcher Service betroffen ist, - Changes werden mit unvollständiger Auswirkungsbewertung durchgeführt, - Incidents werden langsamer analysiert, - Problems werden nicht richtig eingegrenzt, - veraltete Systeme bleiben unentdeckt, - Zertifikate laufen ab, - Abhängigkeiten zu Lieferanten fehlen, - Dokumentation widerspricht der Realität, - und Verantwortlichkeiten bleiben unklar. Eine CMDB soll diese Informationen strukturiert nutzbar machen. --- **Was eine CMDB leisten soll** Eine CMDB soll helfen zu beantworten: - Welche Services gibt es? - Welche Configuration Items gehören dazu? - Welche Systeme sind produktiv? - Welche Versionen sind im Einsatz? - Welche Komponenten hängen voneinander ab? - Welche Changes wurden zuletzt durchgeführt? - Welche Incidents betreffen ein CI? - Welche Problems oder Known Errors sind verknüpft? - Wer ist verantwortlich? - Welche Lieferanten sind beteiligt? - Welche Dokumentation gehört dazu? - Welche Risiken bestehen? Damit unterstützt die CMDB nicht nur Dokumentation, sondern tägliche Betriebsentscheidungen. --- **CMDB ist kein Selbstzweck** Eine CMDB ist nur sinnvoll, wenn sie genutzt wird. Ungeeignet: > Wir erfassen alles, weil eine CMDB vollständig sein muss. Besser: > Wir erfassen die Informationen, die für Servicebetrieb, Support, Changes, Risiken und Entscheidungen wirklich benötigt werden. Eine zu große, ungepflegte CMDB wird schnell unübersichtlich und unzuverlässig. Eine kleine, gut gepflegte CMDB kann deutlich nützlicher sein. --- **CMDB und Configuration Management System** Eine CMDB ist ein Datenbestand für Configuration Items und Beziehungen. Ein **Configuration Management System (CMS)** kann breiter sein. Ein CMS kann mehrere Quellen verbinden, zum Beispiel: - CMDB, - Asset Management, - Monitoring, - Cloud-Inventar, - Endpoint Management, - Netzwerkdokumentation, - Softwareverteilung, - Virtualisierungsplattform, - Dokumentationssystem, - ITSM-Tool, - Security-Werkzeuge. Die CMDB kann also Teil eines größeren Configuration Management Systems sein. --- **CMDB und Inventarliste unterscheiden** | Inventarliste | CMDB | |---|---| | zeigt häufig nur vorhandene Geräte oder Assets | zeigt Configuration Items und Servicebeziehungen | | Fokus auf Bestand | Fokus auf Betrieb, Abhängigkeiten und Wirkung | | Beispiel: Server existiert | Beispiel: Server betreibt Service X und nutzt Datenbank Y | | wichtig für Übersicht | wichtig für Incident, Problem, Change und Risiko | | oft objektbezogen | service- und beziehungsbezogen | Eine Inventarliste beantwortet: > Was haben wir? Eine CMDB beantwortet zusätzlich: > Wofür wird es genutzt und wovon hängt es ab? --- **Typische Inhalte einer CMDB** Eine CMDB kann enthalten: - Configuration Items, - CI-Typen, - CI-Status, - Servicezuordnung, - Versionen, - Umgebungen, - Standorte, - Owner, - Supportgruppen, - Lieferanten, - Kritikalität, - Sicherheitsklassifizierung, - Beziehungen, - Dokumentationslinks, - verknüpfte Incidents, - verknüpfte Problems, - verknüpfte Changes, - verknüpfte Releases, - letzte Prüfung, - letzte Änderung. Nicht jede CMDB benötigt alle Felder. Die Felder müssen zum Zweck und Pflegeaufwand passen. --- **Beispiel für einen CMDB-Eintrag** | Feld | Beispiel | |---|---| | **CI-Name** | PRD-APP-PORTAL-01 | | **CI-Typ** | Server | | **Status** | aktiv | | **Umgebung** | Produktion | | **Service** | Mitarbeiterportal | | **Owner** | Plattform-Team | | **Supportgruppe** | Application Support | | **Version** | Linux Server Version X | | **Standort** | Rechenzentrum Berlin | | **Kritikalität** | hoch | | **Lieferant** | interner Betrieb | | **Dokumentation** | Betriebsrunbook Mitarbeiterportal | | **Beziehungen** | läuft Portal-App, nutzt Datenbank PRD-DB-PORTAL-01 | | **letzte Prüfung** | 02.08.2026 | Dieses Beispiel ist bewusst einfach gehalten. Die tatsächlichen Felder hängen von Organisation und Werkzeug ab. --- **Wichtige CI-Typen in einer CMDB** Mögliche CI-Typen: - Business Service, - Technical Service, - Anwendung, - Server, - Datenbank, - Netzwerkgerät, - Firewall, - Cloud-Ressource, - Zertifikat, - DNS-Eintrag, - Benutzergruppe, - Schnittstelle, - Monitoringregel, - Backupjob, - Dokumentation, - Lieferantenvertrag, - Arbeitsplatzgerät, - Drucker. Wichtig ist eine klare interne Definition. Wenn Teams CI-Typen unterschiedlich verwenden, werden Auswertungen ungenau. --- **Service als zentrales Element** Eine CMDB sollte nicht nur technische Komponenten sammeln. Wichtig ist die Verbindung zum Service. Beispiel: Mitarbeiterportal ↓ nutzt Portal-Anwendung ↓ läuft auf PRD-APP-PORTAL-01 ↓ nutzt PRD-DB-PORTAL-01 ↓ nutzt PRD-STO-01 Zusätzlich: - Zertifikat, - DNS, - Identity Provider, - Monitoring, - Backup, - Supportgruppe, - Service Owner. Erst diese Serviceperspektive macht die CMDB im Betrieb wertvoll. --- **Beziehungen in der CMDB** Beziehungen sind einer der wichtigsten Bestandteile einer CMDB. Typische Beziehungen: - Service nutzt Anwendung, - Anwendung läuft auf Server, - Anwendung nutzt Datenbank, - Server nutzt Storage, - Service nutzt Zertifikat, - Anwendung kommuniziert mit Schnittstelle, - Standort nutzt Firewall, - Monitoring überwacht CI, - Backupjob sichert Datenbank, - Lieferant unterstützt Komponente. Ohne Beziehungen ist eine CMDB oft nur eine Inventarliste. --- **Beispiel: Beziehungskette** Benutzer ↓ Mitarbeiterportal ↓ Webserver ↓ Anwendung ↓ Datenbank ↓ Storage Weitere Abhängigkeiten: - DNS, - Zertifikat, - Identity Provider, - MFA, - Firewall, - Monitoring, - Backup, - Lieferant. Wenn eine Komponente ausfällt, hilft die CMDB zu erkennen, welche Services betroffen sein können. --- **CMDB und Incident Management** Bei Incidents hilft eine CMDB durch: - schnelle Erkennung betroffener Services, - Zuordnung zu verantwortlichen Teams, - Sicht auf Abhängigkeiten, - Anzeige letzter Changes, - Verknüpfung zu Known Errors, - Priorisierung nach Kritikalität, - bessere Eskalation, - schnellere Kommunikation. Beispiel: Ein Benutzer meldet, dass das Mitarbeiterportal nicht erreichbar ist. Die CMDB zeigt: - Portal läuft auf PRD-APP-PORTAL-01, - nutzt PRD-DB-PORTAL-01, - ist abhängig vom Identity Provider, - letzter Change betraf das Zertifikat. Dadurch kann die Diagnose gezielter beginnen. --- **CMDB und Problem Management** Problem Management nutzt CMDB-Daten, um gemeinsame Ursachen zu erkennen. Beispiele: - mehrere Incidents betreffen dieselbe Version, - mehrere Services hängen vom gleichen Datenbankcluster ab, - viele Probleme treten an einem Standort auf, - mehrere Anwendungen nutzen dasselbe Zertifikat, - wiederkehrende Störungen betreffen denselben Lieferanten. Ohne CMDB-Beziehungen werden solche Muster oft erst spät sichtbar. --- **CMDB und Change Enablement** Change Enablement benötigt CMDB-Daten für die Auswirkungsbewertung. Zu prüfen ist: - Welche CIs werden geändert? - Welche Services hängen davon ab? - Welche Benutzer oder Standorte sind betroffen? - Welche Owner müssen einbezogen werden? - Welche anderen Changes betreffen dieselben CIs? - Welche Dokumentation muss aktualisiert werden? - Welche Tests sind notwendig? - Welche Risiken entstehen? Ein Change ohne CMDB-Prüfung kann unerwartete Auswirkungen verursachen. --- **CMDB und Release Management** Release und Deployment benötigen verlässliche Informationen über: - Zielumgebungen, - betroffene Komponenten, - Versionen, - Abhängigkeiten, - Schnittstellen, - Konfigurationen, - Rollback-Zustände, - Monitoring, - Dokumentation. Nach einem Release müssen CMDB-Daten aktualisiert werden. Sonst zeigt die CMDB einen veralteten Zustand. --- **CMDB und Information Security Management** Eine CMDB unterstützt Sicherheitsarbeit durch Informationen über: - kritische Systeme, - externe Erreichbarkeit, - veraltete Versionen, - Zertifikate, - Datenklassifizierung, - privilegierte Systeme, - Schnittstellen, - Lieferanten, - Cloud-Ressourcen, - betroffene Services bei Schwachstellen. Beispiel: Eine Sicherheitslücke betrifft eine bestimmte Softwareversion. Mit CMDB-Daten kann schneller erkannt werden, welche Systeme und Services betroffen sind. --- **CMDB und Service Level Management** Service Level Management kann CMDB-Daten nutzen, um zu verstehen: - welche Komponenten kritische Services unterstützen, - welche Abhängigkeiten Service Levels gefährden, - welche Lieferanten beteiligt sind, - welche CIs besonders hohe Verfügbarkeit benötigen, - welche Changes Service Levels beeinflussen können. Ein Service Level ist schwer zu steuern, wenn die technischen Abhängigkeiten unbekannt sind. --- **CMDB-Datenquellen** Mögliche Datenquellen für eine CMDB: - manuelle Pflege, - Discovery-Werkzeuge, - Monitoring, - Asset Management, - Endpoint Management, - Cloud-Plattformen, - Virtualisierungsplattformen, - Netzwerkmanagement, - Softwareverteilung, - ITSM-Tickets, - Change Records, - Lieferanteninformationen, - Dokumentationssysteme. Keine einzelne Datenquelle ist automatisch vollständig. Die CMDB muss aus passenden Quellen aufgebaut und geprüft werden. --- **Automatische Discovery** Discovery kann technische Informationen automatisch erfassen. Beispiele: - Server, - IP-Adressen, - installierte Software, - Betriebssystemversionen, - Cloud-Ressourcen, - Zertifikate, - offene Dienste, - Netzwerkgeräte, - virtuelle Maschinen, - Container, - Datenbankinstanzen. Discovery ist hilfreich für Aktualität. Aber Discovery erkennt nicht immer: - fachliche Kritikalität, - Service Owner, - Geschäftsprozessbezug, - Risikoakzeptanz, - Dokumentationsqualität, - geplante Ablösung, - oder organisatorische Verantwortung. --- **Manuelle Pflege** Manuelle Pflege bleibt wichtig für Informationen wie: - Service Owner, - fachliche Kritikalität, - Supportmodell, - Lieferantenverantwortung, - Sicherheitsklassifizierung, - Geschäftsprozessbezug, - Runbook-Link, - Notfallinformationen, - Risikoakzeptanz, - geplante Außerbetriebnahme. Diese Informationen benötigen Verantwortliche. Ohne klare Pflegeverantwortung veralten sie schnell. --- **Datenqualität in der CMDB** Eine CMDB ist nur so gut wie ihre Datenqualität. Wichtige Qualitätskriterien: - Vollständigkeit, - Aktualität, - Eindeutigkeit, - Richtigkeit, - Konsistenz, - Nachvollziehbarkeit, - Nutzbarkeit, - Verantwortlichkeit. Schlechte Daten können gefährlich sein. Sie führen zu falschen Entscheidungen, weil Teams der CMDB vertrauen, obwohl sie veraltet ist. --- **Typische Datenqualitätsprobleme** | Problem | Folge | |---|---| | doppelte CIs | Incidents und Changes werden falsch verknüpft | | veraltete Owner | Eskalation dauert länger | | fehlende Beziehungen | Auswirkung wird unterschätzt | | falscher Status | außer Betrieb genommene Systeme erscheinen aktiv | | fehlende Versionen | Sicherheitsbewertung wird ungenau | | fehlende Servicezuordnung | Priorisierung wird schwieriger | | falsche Umgebung | Test und Produktion werden verwechselt | | fehlende Dokumentationslinks | Betrieb dauert länger | --- **Dubletten vermeiden** Dubletten entstehen, wenn dasselbe CI mehrfach erfasst wird. Beispiele: - APP-01, - app01, - Portal Server, - PRD-APP-PORTAL-01. Folgen: - Beziehungen verteilen sich auf mehrere Einträge, - Reports werden falsch, - Changes erscheinen unvollständig, - Incidents werden nicht richtig gebündelt, - Owner widersprechen sich. Gegenmaßnahmen: - Namenskonvention, - eindeutige IDs, - Dublettenprüfung, - klare Erfassungsregeln, - regelmäßige Datenbereinigung. --- **Namenskonventionen** Eine gute Namenskonvention unterstützt Eindeutigkeit. Mögliche Bestandteile: - Umgebung, - Standort, - Funktion, - Servicebezug, - laufende Nummer. Beispiele: - PRD-APP-PORTAL-01, - TST-DB-ERP-02, - BER-FW-STANDORT-01, - PRD-CERT-PORTAL-2026. Die Namenskonvention sollte einfach genug sein, damit sie konsequent genutzt wird. --- **Pflichtfelder und optionale Felder** Nicht jedes Feld sollte verpflichtend sein. Zu viele Pflichtfelder führen dazu, dass Benutzer falsche Werte eintragen, nur um den Datensatz speichern zu können. Sinnvolle Pflichtfelder können sein: - CI-Name, - CI-Typ, - Status, - Umgebung, - Owner oder Supportgruppe, - Servicezuordnung bei produktiven CIs. Optionale Felder können abhängig vom CI-Typ sein. Beispiel: Ein Zertifikat benötigt Ablaufdatum. Ein Drucker benötigt Standort. Eine Anwendung benötigt Version und Service Owner. --- **CMDB-Modell** Das CMDB-Modell beschreibt, welche CI-Typen, Attribute und Beziehungen verwendet werden. Zu klären ist: - Welche CI-Typen gibt es? - Welche Attribute sind notwendig? - Welche Beziehungen sind erlaubt? - Welche Felder sind Pflicht? - Welche Datenquellen werden genutzt? - Wer darf CIs erstellen? - Wer darf CIs ändern? - Wie werden Dubletten verhindert? - Wie wird Qualität geprüft? Ein einfaches, verstandenes Modell ist besser als ein komplexes Modell, das niemand pflegt. --- **Granularität** Granularität beschreibt, wie detailliert CIs erfasst werden. Beispiel: Sehr grob: - Service: Mitarbeiterportal Mittel: - Service, - Anwendung, - Webserver, - Datenbank, - Zertifikat. Sehr fein: - einzelne Konfigurationsdateien, - einzelne Firewall-Regeln, - einzelne Bibliotheken, - einzelne Schnittstellenparameter. Die richtige Granularität hängt vom Nutzen ab. Zu grob hilft bei technischer Analyse wenig. Zu fein ist schwer pflegbar. --- **Beispiel für passende Granularität** Für einen kritischen Webservice sinnvoll: - Service, - Anwendung, - Datenbank, - Server, - Load Balancer, - Zertifikat, - DNS, - Identity Provider, - Monitoring, - Backup, - wichtige Schnittstellen. Nicht immer sinnvoll: - jede einzelne Konfigurationszeile, - jede temporäre Datei, - jedes unkritische Testobjekt. Die CMDB soll Entscheidungen unterstützen, nicht jede technische Kleinigkeit abbilden. --- **CMDB-Lebenszyklus** Ein CI durchläuft einen Lebenszyklus. geplant ↓ erstellt oder beschafft ↓ in Betrieb genommen ↓ geändert ↓ regelmäßig geprüft ↓ außer Betrieb genommen ↓ archiviert oder gelöscht Die CMDB sollte diesen Lebenszyklus abbilden. Besonders wichtig ist die saubere Außerbetriebnahme. --- **Außerbetriebnahme von CIs** Vor dem Entfernen eines CIs sollte geprüft werden: - Welche Services nutzen das CI? - Gibt es noch aktive Beziehungen? - Gibt es offene Incidents oder Problems? - Gibt es geplante Changes? - Wird das CI noch überwacht? - Gibt es Backups oder Archivdaten? - Gibt es Lizenz- oder Vertragsbezug? - Muss Dokumentation angepasst werden? - Muss ein Lieferant informiert werden? Ein CI einfach zu löschen kann spätere Nachvollziehbarkeit zerstören. Oft ist Archivierung sinnvoller. --- **CMDB und Change-Prozess** Changes sollten CMDB-Daten aktualisieren. Beispiele: - neue Version nach Update, - neue Beziehung nach Schnittstellenänderung, - neues Zertifikat nach Erneuerung, - neuer Owner nach Übergabe, - neuer Status nach Außerbetriebnahme, - neue Cloud-Ressource nach Deployment, - neue Monitoringbeziehung nach Alarmregel. Wenn Changes die CMDB nicht aktualisieren, veraltet sie automatisch. --- **CMDB und Dokumentation** Die CMDB ersetzt nicht jede Dokumentation. Sie kann aber auf Dokumentation verweisen. Beispiele: - Betriebsrunbook, - Architekturdiagramm, - Notfallhandbuch, - Installationsanleitung, - Schnittstellendokumentation, - Lieferantenvertrag, - Sicherheitskonzept, - Backup- und Restore-Anleitung. Die CMDB zeigt, welche Dokumentation zu welchem CI oder Service gehört. --- **CMDB und Monitoring** Monitoring und CMDB sollten sich ergänzen. Monitoring zeigt: - Zustand, - Alarme, - Verfügbarkeit, - Performance, - Kapazität, - Fehlerereignisse. CMDB zeigt: - Servicezuordnung, - Kritikalität, - Owner, - Beziehungen, - Version, - Dokumentation. Beispiel: Monitoring meldet Ausfall eines Servers. Die CMDB zeigt, welche Services davon abhängen und wer informiert werden muss. --- **CMDB und Cloud** Cloud-Umgebungen verändern sich oft schnell. Herausforderungen: - Ressourcen entstehen automatisch, - Ressourcen werden schnell gelöscht, - Namen sind uneinheitlich, - Tags fehlen, - Owner sind unklar, - Kostenstellen fehlen, - Beziehungen sind dynamisch, - externe Dienste sind beteiligt. Für Cloud-Ressourcen sind klare Tags, automatisierte Erkennung und regelmäßige Prüfung besonders wichtig. --- **CMDB und Tags** Tags oder Labels können helfen, Cloud- und Plattformressourcen zuzuordnen. Mögliche Tags: - Service, - Umgebung, - Owner, - Kostenstelle, - Kritikalität, - Datenklasse, - Ablaufdatum, - Projekt, - Supportgruppe. Beispiel: | Tag | Wert | |---|---| | Service | Mitarbeiterportal | | Umgebung | Produktion | | Owner | Plattform-Team | | Kritikalität | hoch | | Datenklasse | intern | Tags ersetzen keine vollständige CMDB, können aber wichtige Daten liefern. --- **CMDB und Container** Auch Container-Umgebungen können CMDB-relevant sein. Mögliche CIs: - Container-Plattform, - Cluster, - Namespace, - Anwendung, - Image-Version, - Datenbank, - Volume, - Ingress, - Secret, - Zertifikat, - Monitoring, - Backupjob. Wichtig ist, nicht jeden kurzlebigen Container einzeln dauerhaft zu pflegen. Oft sind Service, Anwendung, Plattform, Version und Abhängigkeiten wichtiger als einzelne temporäre Instanzen. --- **CMDB und Schnittstellen** Schnittstellen werden oft vergessen. Dabei sind sie für Services kritisch. Zu erfassen sind: - Quellsystem, - Zielsystem, - Protokoll, - Authentifizierung, - Zertifikat, - Datenformat, - Owner, - Lieferant, - Kritikalität, - Monitoring, - bekannte Fehler, - Abhängigkeiten. Ein Schnittstellenfehler kann mehrere Services gleichzeitig betreffen. --- **CMDB und Zertifikate** Zertifikate sollten bei wichtigen Services als relevante CIs betrachtet werden. Sinnvolle Informationen: - Name, - betroffener Service, - Hostname, - Ablaufdatum, - Aussteller, - Owner, - Erneuerungsprozess, - Monitoring, - abhängige Systeme, - Dokumentationslink. Viele vermeidbare Incidents entstehen durch abgelaufene oder falsch erneuerte Zertifikate. --- **Berechtigungen und Gruppen als CIs** Auch Benutzergruppen oder Berechtigungskonzepte können CI-relevant sein. Beispiele: - Administratorgruppe, - Rollen für Fachanwendung, - VPN-Zugriffsgruppe, - MFA-Ausnahmegruppe, - Servicekonto, - API-Berechtigung. Solche CIs sind besonders wichtig für: - Sicherheit, - Change Enablement, - Audits, - Incident-Diagnose, - Berechtigungsprobleme, - und Compliance. --- **CMDB-Reports** Nützliche Reports können sein: - aktive produktive Services, - Services ohne Owner, - CIs ohne Servicezuordnung, - CIs ohne aktuelle Prüfung, - ablaufende Zertifikate, - veraltete Versionen, - kritische CIs ohne Monitoring, - Changes pro CI, - Incidents pro CI, - Known Errors pro Service, - CIs mit fehlenden Beziehungen. Reports sollen nicht nur Zahlen liefern. Sie sollen konkrete Verbesserungen ermöglichen. --- **CMDB-Einführung schrittweise beginnen** Eine CMDB sollte nicht zwingend sofort alles abbilden. Sinnvoller Start: 1. kritische Services auswählen 2. wichtigste CIs erfassen 3. zentrale Beziehungen dokumentieren 4. Owner festlegen 5. Change-Prozess anbinden 6. Datenqualität prüfen 7. Nutzung in Incident und Change etablieren 8. schrittweise erweitern Eine CMDB scheitert häufig, wenn zu Beginn zu viel auf einmal erfasst werden soll. --- **Minimal sinnvolle CMDB für kleine Umgebungen** Für kleine Umgebungen kann auch eine einfache Struktur ausreichen. Mögliche Mindestinformationen: - Service, - wichtige Komponenten, - Owner, - Umgebung, - Status, - Version, - wichtigste Abhängigkeiten, - Dokumentationslink, - letzter Change, - letzte Prüfung. Das kann auch in einem einfachen ITSM-Tool, Wiki oder einer strukturierten Tabelle beginnen. Wichtig ist Pflege und Nutzung. --- **Governance der CMDB** CMDB-Governance legt Regeln fest. Zu klären ist: - Wer ist für das CMDB-Modell verantwortlich? - Wer darf CIs erstellen? - Wer darf CIs ändern? - Wer prüft Datenqualität? - Welche Felder sind Pflicht? - Wie werden Dubletten behandelt? - Wie werden Changes eingebunden? - Wie oft werden kritische CIs geprüft? - Welche Reports werden genutzt? - Wie werden Fehler korrigiert? Ohne Governance wird eine CMDB schnell unzuverlässig. --- **Rollen im CMDB-Betrieb** Mögliche Rollen: | Rolle | Aufgabe | |---|---| | **Configuration Manager** | steuert Modell, Qualität und Regeln | | **Service Owner** | verantwortet Serviceinformationen | | **CI Owner** | verantwortet einzelne CIs | | **Supportgruppe** | nutzt und ergänzt Betriebsinformationen | | **Change Manager** | sorgt für Aktualisierung nach Changes | | **Security Team** | nutzt Daten für Sicherheitsbewertung | | **Asset Manager** | liefert Asset- und Vertragsdaten | Die Rollen müssen nicht überall als eigene Stellen existieren. Die Verantwortlichkeiten müssen aber klar sein. --- **Praxisbeispiel: Incident mit CMDB-Nutzen** **Situation** Mehrere Benutzer melden, dass das Mitarbeiterportal nicht erreichbar ist. **CMDB hilft durch:** - Servicezuordnung, - betroffene Anwendung, - Datenbankbeziehung, - Zertifikatsbeziehung, - letzter Change, - zuständige Supportgruppe, - Kritikalität des Services. **Ergebnis** Die Analyse konzentriert sich schneller auf Datenbank, Zertifikat und letzten Change. --- **Praxisbeispiel: Change mit CMDB-Nutzen** **Situation** Ein Datenbankserver soll aktualisiert werden. **CMDB zeigt:** - drei Anwendungen nutzen diesen Server, - eine Anwendung ist geschäftskritisch, - ein Lieferant muss für Test erreichbar sein, - Backupjob muss vor dem Change geprüft werden, - Service Desk muss informiert werden. **Ergebnis** Der Change wird nicht als isoliertes Serverupdate behandelt, sondern als Serviceänderung mit Abhängigkeiten. --- **Praxisbeispiel: Sicherheitslücke** **Situation** Eine kritische Schwachstelle betrifft eine bestimmte Softwareversion. **CMDB hilft durch:** - Liste betroffener Systeme, - Servicezuordnung, - Kritikalität, - Owner, - Umgebung, - externe Erreichbarkeit, - Patchstatus, - Changes zur Behebung. **Ergebnis** Patchpriorisierung wird schneller und nachvollziehbarer. --- **Praxisbeispiel: Abgelaufenes Zertifikat verhindern** **Situation** Mehrere Zertifikate wurden bisher nur in einzelnen Runbooks erwähnt. **Problem** Ablaufdaten wurden nicht zentral überwacht. **Verbesserung** Zertifikate werden als CIs erfasst mit: - Ablaufdatum, - Servicebezug, - Owner, - Monitoring, - Erneuerungsprozess, - Dokumentationslink. **Nutzen** Ausfälle durch abgelaufene Zertifikate werden besser vermeidbar. --- **Typische Fehler** **Fehler 1** CMDB wird als reine Inventarliste aufgebaut. --- **Fehler 2** Zu viele CIs werden erfasst, aber nicht gepflegt. --- **Fehler 3** Services und Beziehungen fehlen. --- **Fehler 4** Owner sind nicht definiert. --- **Fehler 5** Daten werden nicht durch Changes aktualisiert. --- **Fehler 6** Discovery-Daten werden ungeprüft übernommen. --- **Fehler 7** Dubletten und uneinheitliche Namen werden nicht bereinigt. --- **Fehler 8** CMDB wird im Incident- und Change-Prozess nicht genutzt. --- **Fehler 9** Kritikalität wird technisch statt servicebezogen bewertet. --- **Fehler 10** Cloud-Ressourcen, Zertifikate und Schnittstellen fehlen. --- **Fehler 11** Reports zeigen Probleme, aber niemand verfolgt Verbesserungen. --- **Fehler 12** CMDB-Ziel und Pflegeaufwand passen nicht zusammen. --- **Checkliste CMDB-Modell** - [ ] Ziel der CMDB ist klar - [ ] relevante Services sind definiert - [ ] CI-Typen sind festgelegt - [ ] Pflichtfelder sind definiert - [ ] Beziehungstypen sind festgelegt - [ ] Namenskonvention ist beschrieben - [ ] Rollen und Verantwortlichkeiten sind klar - [ ] Datenquellen sind bekannt - [ ] Datenqualitätsregeln sind definiert - [ ] Change-Prozess ist angebunden - [ ] Reporting ist festgelegt - [ ] regelmäßige Prüfung ist vorgesehen --- **Checkliste CMDB-Eintrag** - [ ] CI-Name eindeutig - [ ] CI-Typ korrekt - [ ] Status aktuell - [ ] Umgebung korrekt - [ ] Servicezuordnung vorhanden - [ ] Owner oder Supportgruppe eingetragen - [ ] Version oder Konfigurationsstand gepflegt - [ ] Kritikalität nachvollziehbar - [ ] Beziehungen gepflegt - [ ] Dokumentationslink vorhanden - [ ] letzte Änderung nachvollziehbar - [ ] letzte Prüfung dokumentiert --- **Checkliste Datenqualität** - [ ] keine Dubletten vorhanden - [ ] veraltete CIs archiviert - [ ] produktive CIs besitzen Owner - [ ] kritische CIs besitzen Servicebezug - [ ] wichtige Beziehungen sind gepflegt - [ ] Versionen sind aktuell - [ ] Statuswerte sind plausibel - [ ] Cloud-Ressourcen sind berücksichtigt - [ ] Zertifikate sind erfasst - [ ] Schnittstellen sind erfasst - [ ] Changes aktualisieren CMDB-Daten - [ ] Reports werden regelmäßig geprüft --- **Checkliste CMDB im Change nutzen** - [ ] betroffene CIs im Change verknüpft - [ ] abhängige Services geprüft - [ ] Owner identifiziert - [ ] Kritikalität bewertet - [ ] letzte Changes geprüft - [ ] parallele Changes geprüft - [ ] Dokumentationsbedarf erkannt - [ ] CMDB-Aktualisierung nach Change geplant - [ ] neue Beziehungen ergänzt - [ ] entfernte Beziehungen bereinigt --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker nutzen und pflegen CMDB-Daten im praktischen Betrieb. Wichtig ist: - Systeme eindeutig benennen, - produktive und nicht produktive Umgebungen unterscheiden, - Versionen und Konfigurationen sauber dokumentieren, - Abhängigkeiten erkennen, - Owner und Supportgruppen eintragen, - Changes mit CIs verknüpfen, - veraltete Daten melden, - und CMDB-Daten bei Incidents, Problems und Changes aktiv nutzen. Eine gute CMDB macht technische Arbeit nicht bürokratischer. Sie macht sie nachvollziehbarer, sicherer und schneller. --- **Zusammenfassung** > Ziel der CMDB festlegen > ↓ > relevante Services und CI-Typen bestimmen > ↓ > Attribute und Beziehungen definieren > ↓ > Datenquellen anbinden > ↓ > Owner und Pflegeverantwortung klären > ↓ > CIs und Beziehungen erfassen > ↓ > CMDB in Incident, Problem und Change nutzen > ↓ > Datenqualität regelmäßig prüfen > ↓ > CMDB schrittweise verbessern --- **Merksätze** > Eine CMDB ist nur wertvoll, wenn ihre Daten genutzt und gepflegt werden. > Beziehungen sind wichtiger als eine lange Liste einzelner Systeme. > Eine CMDB ersetzt keine Betriebsdokumentation, sie verknüpft relevante Informationen. > Discovery hilft bei Technik, ersetzt aber keine fachliche Verantwortung. > Jede relevante Änderung sollte auch die CMDB aktualisieren. > Schlechte CMDB-Daten können zu falschen Entscheidungen führen. > Klein anfangen und konsequent pflegen ist besser als groß planen und nicht aktuell halten. --- **Verwandte Seiten** - 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen - 6.2 Configuration Items und Beziehungen - 6.4 Discovery, Pflege und Datenqualität - 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management - Incident Management - Problem Management - Change Enablement - Release Management - Information Security Management - IT Asset Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: IT Asset Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - CMDB-Inhalte, - Feldbeispiele, - Datenqualitätsregeln, - Rollen, - Checklisten, - Reports, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - CMDB-Struktur, - Pflichtfeldliste, - CI-Typenliste, - Beziehungsmatrix, - Namenskonvention, - Discovery-Pflicht, - oder konkrete Toolarchitektur für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisationsgröße, - Toollandschaft, - Datenqualität, - Supportmodell, - Sicherheitsanforderungen, - Change-Modell, - Cloud-Nutzung, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6.4 Discovery, Pflege und Datenqualität > **Kurz erklärt** > > Discovery, Pflege und Datenqualität sorgen dafür, dass Configuration-Daten nicht nur einmal erfasst, sondern dauerhaft aktuell, korrekt und nutzbar bleiben. > > **Discovery** hilft, technische Informationen automatisch zu erkennen. > > **Pflege** sorgt dafür, dass fachliche, organisatorische und servicebezogene Informationen ergänzt und aktuell gehalten werden. > > **Datenqualität** entscheidet, ob Configuration-Daten im Betrieb wirklich verlässlich sind. --- **Warum dieses Thema wichtig ist** Eine CMDB oder ein Configuration Management System ist nur dann hilfreich, wenn die Daten stimmen. Veraltete oder falsche Configuration-Daten führen zu Problemen: - Incidents werden falsch priorisiert, - Changes werden mit falscher Auswirkungsbewertung geplant, - Problems werden nicht richtig eingegrenzt, - Owner sind nicht erreichbar, - Serviceabhängigkeiten fehlen, - Sicherheitslücken werden übersehen, - Zertifikate laufen ab, - Cloud-Ressourcen bleiben unbekannt, - und Dokumentation widerspricht der Realität. Datenqualität ist deshalb kein Nebenthema. Sie ist die Grundlage dafür, dass Service Configuration Management im Alltag funktioniert. --- **Discovery** Discovery bedeutet, technische Informationen automatisch oder halbautomatisch zu erkennen. Mögliche Discovery-Ergebnisse: - Server, - Clients, - Netzwerkgeräte, - virtuelle Maschinen, - Container-Plattformen, - Cloud-Ressourcen, - installierte Software, - Betriebssystemversionen, - IP-Adressen, - offene Dienste, - Zertifikate, - Datenbankinstanzen, - Schnittstellen, - Hardwareinformationen, - Speicher, - Netzwerkverbindungen, - und technische Abhängigkeiten. Discovery kann Daten schneller und regelmäßiger erfassen als rein manuelle Pflege. --- **Was Discovery leisten kann** Discovery kann helfen bei: - Erstbefüllung einer CMDB, - Erkennung unbekannter Systeme, - Aktualisierung technischer Daten, - Abgleich von Ist-Zustand und Soll-Zustand, - Erkennung veralteter Versionen, - Sicherheitsbewertung, - Audit-Vorbereitung, - Cloud-Transparenz, - Netzwerkübersicht, - und Datenqualitätsprüfung. Beispiel: Ein Discovery-Werkzeug erkennt, dass ein Server noch eine alte Softwareversion verwendet. Diese Information kann für Security, Change Enablement und Problem Management wichtig sein. --- **Was Discovery nicht automatisch leisten kann** Discovery erkennt Technik. Discovery versteht aber nicht automatisch den fachlichen Zusammenhang. Ein Discovery-Werkzeug erkennt vielleicht: - ein Server existiert, - ein Dienst läuft, - eine IP-Adresse ist erreichbar, - ein Zertifikat ist installiert, - eine Anwendung kommuniziert mit einer Datenbank. Es weiß aber nicht automatisch: - welcher Geschäftsprozess betroffen ist, - welcher Service Owner verantwortlich ist, - welche Kritikalität der Service besitzt, - ob eine Abweichung genehmigt ist, - ob ein System bald abgelöst wird, - welcher Lieferant verantwortlich ist, - oder welcher Workaround im Störungsfall gilt. Deshalb muss Discovery durch fachliche Pflege ergänzt werden. --- **Discovery und manuelle Pflege ergänzen sich** | Discovery | Manuelle oder organisatorische Pflege | |---|---| | erkennt technische Objekte | ergänzt fachliche Bedeutung | | erkennt Versionen und Eigenschaften | ergänzt Owner und Verantwortlichkeiten | | erkennt Verbindungen | bewertet Serviceabhängigkeiten | | erkennt neue Ressourcen | prüft, ob sie relevant sind | | erkennt Abweichungen | klärt, ob sie erlaubt sind | | liefert Ist-Daten | ergänzt Soll-Zustand und Kontext | Gute Configuration-Daten entstehen durch Kombination aus Automatisierung, Prozessen und Verantwortung. --- **Typische Discovery-Quellen** Mögliche Quellen für technische Erkennung: - Netzwerk-Scanner, - Monitoring-System, - Endpoint-Management, - Softwareverteilung, - Virtualisierungsplattform, - Cloud-Plattform, - Container-Plattform, - Verzeichnisdienst, - Zertifikatsverwaltung, - Backup-System, - Datenbankverwaltung, - Sicherheitswerkzeuge, - ITSM-System, - Asset-Management-System. Keine Quelle ist vollständig. Mehrere Quellen müssen oft abgeglichen werden. --- **Discovery in Cloud-Umgebungen** Cloud-Umgebungen verändern sich häufig schneller als klassische Rechenzentrumsumgebungen. Typische Herausforderungen: - Ressourcen werden automatisch erstellt, - Ressourcen werden schnell gelöscht, - Tags fehlen oder sind uneinheitlich, - Owner sind unklar, - Kostenstellen fehlen, - Testressourcen bleiben aktiv, - Dienste werden extern bereitgestellt, - Abhängigkeiten sind dynamisch. Wichtige Maßnahmen: - verbindliche Tags definieren, - Owner erfassen, - Umgebung kennzeichnen, - automatische Exporte nutzen, - Cloud-Ressourcen regelmäßig prüfen, - nicht genutzte Ressourcen bereinigen, - Sicherheitsklassifizierung ergänzen. --- **Discovery in Container-Umgebungen** In Container-Umgebungen entstehen und verschwinden technische Instanzen oft sehr schnell. Nicht jeder kurzlebige Container sollte dauerhaft als einzelnes CI gepflegt werden. Sinnvoller können sein: - Service, - Anwendung, - Namespace, - Cluster, - Deployment, - Image-Version, - Datenbank, - Volume, - Ingress, - Zertifikat, - Secret, - Monitoring, - Backupjob. Wichtig ist, servicebezogene Informationen zu erfassen, nicht jede temporäre Laufzeitinstanz dauerhaft zu dokumentieren. --- **Discovery und Sicherheitsbewertung** Discovery ist für Sicherheit besonders wichtig. Beispiele: - unbekannte Systeme erkennen, - veraltete Software finden, - offene Dienste prüfen, - externe Erreichbarkeit feststellen, - ablaufende Zertifikate identifizieren, - nicht genehmigte Cloud-Ressourcen erkennen, - nicht inventarisierte Geräte finden, - Systeme mit kritischen Schwachstellen priorisieren. Aber auch hier gilt: Discovery zeigt technische Tatsachen. Die Risikobewertung benötigt zusätzlich Kritikalität, Datenklasse, Servicebezug und Owner. --- **Discovery-Ergebnisse prüfen** Discovery-Daten sollten nicht ungeprüft übernommen werden. Zu prüfen ist: - Ist das erkannte Objekt wirklich relevant? - Ist es bereits als CI vorhanden? - Ist der Name eindeutig? - Ist die Umgebung korrekt? - Ist der Status korrekt? - Gibt es Dubletten? - Ist der Owner bekannt? - Gibt es einen Servicebezug? - Handelt es sich um ein temporäres Objekt? - Muss das Objekt dauerhaft gepflegt werden? Automatisierung ohne Prüfung kann die CMDB mit unbrauchbaren Daten füllen. --- **Datenpflege** Datenpflege bedeutet, Configuration-Daten aktuell und nutzbar zu halten. Dazu gehören: - neue CIs erfassen, - veränderte CIs aktualisieren, - entfernte CIs archivieren, - Beziehungen pflegen, - Owner aktualisieren, - Versionen korrigieren, - Dokumentationslinks prüfen, - Dubletten bereinigen, - Statuswerte anpassen, - und veraltete Einträge entfernen oder archivieren. Pflege ist keine einmalige Projektarbeit. Sie ist eine laufende Betriebsaufgabe. --- **Pflege durch Change Enablement** Changes sind eine der wichtigsten Quellen für CMDB-Aktualisierungen. Nach einem Change kann sich ändern: - Version, - Konfiguration, - Beziehung, - Status, - Umgebung, - Owner, - Lieferant, - Zertifikat, - Schnittstelle, - Monitoring, - Backup, - Dokumentation. Deshalb sollte jeder relevante Change prüfen: > Müssen Configuration-Daten aktualisiert werden? Wenn Changes die CMDB nicht pflegen, veraltet sie automatisch. --- **Pflege durch Release und Deployment** Nach Releases und Deployments ändern sich häufig: - Anwendungsversionen, - Zielumgebungen, - Infrastrukturkomponenten, - Schnittstellen, - Datenbankversionen, - Konfigurationsstände, - Container-Images, - Dokumentation, - Known Errors, - Monitoringregeln. Release- und Deployment-Prozesse sollten deshalb CMDB-Aktualisierung als Abschlussaufgabe enthalten. --- **Pflege durch Incident und Problem Management** Incident und Problem Management können Datenfehler sichtbar machen. Beispiele: - falscher Owner im Incident, - fehlende Servicebeziehung, - veraltete Version, - nicht dokumentierte Schnittstelle, - fehlender Known Error, - nicht erfasstes Zertifikat, - falsche Kritikalität, - fehlender Dokumentationslink. Solche Erkenntnisse sollten nicht im Ticket verschwinden. Sie sollten zur Verbesserung der Configuration-Daten genutzt werden. --- **Pflege durch Service Owner** Service Owner sind wichtig für fachliche Informationen. Sie können prüfen: - stimmt die Servicebeschreibung, - stimmt die Kritikalität, - stimmt der Geschäftsprozessbezug, - stimmen Supportzeiten, - stimmen Benutzergruppen, - stimmen Lieferanten, - sind Abhängigkeiten vollständig, - sind Dokumentationslinks aktuell, - sind Risiken korrekt bewertet. Technische Teams kennen oft die Komponenten. Service Owner kennen den fachlichen Wert und die Auswirkung. --- **Pflege durch technische Teams** Technische Teams pflegen vor allem technische Informationen. Beispiele: - Versionen, - Konfigurationsstände, - Plattformen, - Server, - Datenbanken, - Netzwerkkomponenten, - Zertifikate, - Backupjobs, - Monitoringregeln, - Schnittstellen, - Betriebshandbücher. Wichtig ist, dass technische Änderungen nicht nur umgesetzt, sondern auch nachvollziehbar dokumentiert werden. --- **Pflegeintervalle** Nicht alle Configuration-Daten müssen gleich häufig geprüft werden. Mögliche Prüfintervalle: | CI oder Information | mögliches Prüfintervall | |---|---| | geschäftskritischer Service | regelmäßig und nach jedem relevanten Change | | Zertifikate | automatisch überwachen und regelmäßig prüfen | | produktive Server | nach Changes und in festen Reviews | | Cloud-Ressourcen | häufig oder automatisiert | | Dokumentationslinks | regelmäßig oder nach Releases | | Testsysteme | nach Bedarf | | archivierte CIs | selten, aber nachvollziehbar | Die Häufigkeit sollte sich nach Risiko, Kritikalität und Änderungsdynamik richten. --- **Datenqualität** Datenqualität beschreibt, ob Configuration-Daten für den vorgesehenen Zweck geeignet sind. Wichtige Qualitätsmerkmale: - korrekt, - aktuell, - vollständig genug, - eindeutig, - konsistent, - nachvollziehbar, - auffindbar, - verantwortet, - und nutzbar. Perfekte Vollständigkeit ist selten realistisch. Entscheidend ist, dass die Daten für Incident, Problem, Change, Release und Security Management ausreichend zuverlässig sind. --- **Korrektheit** Korrektheit bedeutet: > Die Information stimmt mit der Realität überein. Beispiele: - Version ist richtig, - Owner ist richtig, - Status ist richtig, - Servicezuordnung ist richtig, - Beziehung ist richtig. Falsche Daten sind gefährlich. Beispiel: Die CMDB zeigt einen Server als Testsystem, obwohl er produktiv genutzt wird. Ein Change wird dadurch zu niedrig bewertet. --- **Aktualität** Aktualität bedeutet: > Die Information ist nicht veraltet. Beispiele für veraltete Daten: - alter Owner, - alte Version, - außer Betrieb genommener Server ist noch aktiv, - neues Zertifikat fehlt, - Cloud-Ressource wurde gelöscht, - Schnittstelle wurde geändert, - Dokumentationslink zeigt auf alte Anleitung. Aktualität entsteht durch Anbindung an Changes, Releases, Reviews und Discovery. --- **Vollständigkeit** Vollständigkeit bedeutet nicht, jedes Detail zu erfassen. Sie bedeutet: > Die für den Zweck notwendigen Informationen sind vorhanden. Beispiel: Für einen kritischen Service sollten mindestens vorhanden sein: - Service Owner, - technische Supportgruppe, - wichtigste CIs, - zentrale Abhängigkeiten, - Kritikalität, - Dokumentation, - Notfallinformationen, - und relevante Lieferanten. Ein unwichtiger Testdienst benötigt weniger Detailtiefe. --- **Eindeutigkeit** Eindeutigkeit bedeutet: > Jedes CI ist klar identifizierbar. Probleme entstehen durch: - doppelte Einträge, - unterschiedliche Schreibweisen, - unklare Namen, - fehlende IDs, - unklare Umgebungen, - ähnliche Systemnamen. Beispiel: - APP01 - app01 - Portal-App-Server - PRD-APP-PORTAL-01 könnten dasselbe CI beschreiben. Solche Dubletten erschweren Reports, Changes und Incidents. --- **Konsistenz** Konsistenz bedeutet: > Daten folgen einheitlichen Regeln. Beispiele: - gleiche Statuswerte, - gleiche CI-Typen, - einheitliche Namenskonvention, - klare Beziehungstypen, - einheitliche Umgebungsbezeichnungen, - definierte Pflichtfelder. Ungeeignet: - Produktion, - Prod, - PRD, - Live werden ohne Regel gemischt. Besser: > Eine definierte Schreibweise wird verbindlich genutzt. --- **Nachvollziehbarkeit** Nachvollziehbarkeit bedeutet: > Es ist erkennbar, woher eine Information kommt und warum sie geändert wurde. Hilfreich sind: - letzter Änderungszeitpunkt, - letzter Prüftermin, - verknüpfter Change, - verantwortliche Person oder Gruppe, - Datenquelle, - Kommentar zur Abweichung, - Archivierung statt unkontrollierter Löschung. Nachvollziehbarkeit ist besonders wichtig bei Sicherheitsfragen, Audits und Major Incidents. --- **Nutzbarkeit** Daten sind nur wertvoll, wenn sie genutzt werden können. Nutzbarkeit bedeutet: - Informationen sind auffindbar, - Felder sind verständlich, - Beziehungen sind sichtbar, - Reports sind sinnvoll, - Daten passen zu Prozessen, - Teams vertrauen den Informationen, - Pflegeaufwand ist realistisch. Eine CMDB mit vielen Feldern, die niemand versteht oder nutzt, erzeugt keinen Mehrwert. --- **Datenqualitätsregeln** Eine Organisation sollte Datenqualitätsregeln definieren. Beispiele: - produktive CIs benötigen Owner, - produktive CIs benötigen Servicezuordnung, - kritische Services benötigen dokumentierte Abhängigkeiten, - Zertifikate benötigen Ablaufdatum und Owner, - Changes müssen betroffene CIs verknüpfen, - außer Betrieb genommene CIs werden archiviert, - Dubletten werden regelmäßig bereinigt, - Cloud-Ressourcen benötigen Tags. Solche Regeln müssen kontrollierbar sein. --- **Datenqualitätskennzahlen** Mögliche Kennzahlen: | Kennzahl | Aussage | |---|---| | CIs ohne Owner | Verantwortlichkeit fehlt | | CIs ohne Servicezuordnung | Servicebezug unklar | | kritische Services ohne Abhängigkeiten | Auswirkungsanalyse unvollständig | | CIs ohne letzte Prüfung | Aktualität unsicher | | ablaufende Zertifikate ohne Owner | hohes Betriebsrisiko | | Dublettenquote | Eindeutigkeit schlecht | | Changes ohne CI-Verknüpfung | CMDB wird im Change-Prozess nicht genutzt | | Incidents ohne CI-Verknüpfung | Trendanalyse erschwert | Kennzahlen sollten nicht nur gemessen werden. Sie müssen zu Verbesserungen führen. --- **Datenqualitätsberichte** Datenqualitätsberichte können regelmäßig zeigen: - welche CIs unvollständig sind, - welche Owner fehlen, - welche Beziehungen fehlen, - welche CIs lange nicht geprüft wurden, - welche Zertifikate bald ablaufen, - welche Versionen veraltet sind, - welche Changes keine CIs verknüpft haben, - welche Services keine Abhängigkeiten besitzen. Solche Berichte sollten Verantwortliche und nächste Schritte enthalten. Nur eine Fehlerliste reicht nicht aus. --- **Dubletten bereinigen** Dubletten entstehen leicht durch manuelle Pflege, Discovery oder unterschiedliche Datenquellen. Vorgehen: 1. mögliche Dubletten erkennen 2. prüfen, ob es wirklich dasselbe CI ist 3. führenden Datensatz festlegen 4. Beziehungen zusammenführen 5. verknüpfte Incidents, Problems und Changes prüfen 6. Dublette archivieren oder löschen 7. Ursache der Dublette beheben Wichtig ist, nicht versehentlich unterschiedliche CIs zusammenzuführen. --- **Veraltete CIs archivieren** Nicht mehr aktive CIs sollten nicht einfach unkontrolliert gelöscht werden. Besser ist oft: - Status auf außer Betrieb setzen, - Beziehungen prüfen, - offene Incidents oder Changes prüfen, - Dokumentation verknüpft lassen, - Archivierungsdatum erfassen, - Grund der Außerbetriebnahme dokumentieren. So bleibt Nachvollziehbarkeit erhalten. Das ist besonders wichtig bei Audits, Sicherheitsvorfällen oder späteren Analysen. --- **Abweichungen erkennen** Abweichungen zwischen CMDB und Realität können entstehen durch: - ungeplante Changes, - manuelle Änderungen, - Notfallmaßnahmen, - nicht dokumentierte Deployments, - fehlerhafte Discovery, - Cloud-Automatisierung, - Lieferantenänderungen, - Schatten-IT, - vergessene Außerbetriebnahmen. Abweichungen sollten nicht nur korrigiert werden. Es sollte geprüft werden, warum sie entstanden sind. --- **Soll-Zustand und Ist-Zustand unterscheiden** | Zustand | Bedeutung | |---|---| | **Soll-Zustand** | freigegebener oder erwarteter Zustand | | **Ist-Zustand** | tatsächlich erkannter Zustand | | **Abweichung** | Unterschied zwischen Soll und Ist | Beispiel: Soll-Zustand: > Server nutzt Version 5.9. Ist-Zustand: > Discovery erkennt Version 5.8. Mögliche Ursachen: - Update fehlgeschlagen, - CMDB nicht aktualisiert, - falscher Server gescannt, - Rollback wurde durchgeführt, - Change nicht dokumentiert. --- **Configuration Drift** Configuration Drift bedeutet, dass Systeme im Laufe der Zeit vom gewünschten Zustand abweichen. Ursachen: - manuelle Änderungen, - Hotfixes, - ungeplante Anpassungen, - unterschiedliche Skriptversionen, - nicht dokumentierte Changes, - Lieferantenarbeiten, - fehlende Automatisierung, - fehlende Kontrolle. Folgen: - Tests werden unzuverlässig, - Deployments schlagen fehl, - Sicherheitslücken entstehen, - Incidents werden schwerer analysiert, - Rollback wird schwieriger. Baselines und regelmäßige Prüfungen helfen gegen Configuration Drift. --- **Baselines nutzen** Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand. Beispiele: - Standardserverkonfiguration, - genehmigte Anwendungsversion, - geprüfte Firewall-Regelbasis, - Standardclient, - freigegebene Cloud-Tag-Struktur, - definierter Release-Stand. Baselines helfen bei: - Vergleich mit aktuellem Zustand, - Fehleranalyse, - Rollback, - Audit, - Standardisierung, - Sicherheitsprüfung. Wenn ein System von der Baseline abweicht, sollte dokumentiert sein, warum. --- **Pflegeverantwortung** Ohne Verantwortung veraltet Configuration Management. Zu klären ist: - Wer ist für das CMDB-Modell verantwortlich? - Wer pflegt technische Daten? - Wer pflegt Serviceinformationen? - Wer prüft Datenqualität? - Wer bereinigt Dubletten? - Wer kontrolliert Reports? - Wer aktualisiert Daten nach Changes? - Wer genehmigt Modelländerungen? - Wer ist Ansprechpartner bei Datenfehlern? Verantwortung kann auf mehrere Rollen verteilt sein. Sie muss aber eindeutig sein. --- **Rollen bei der Datenpflege** | Rolle | mögliche Aufgabe | |---|---| | **Configuration Manager** | Regeln, Modell und Datenqualität steuern | | **Service Owner** | Servicebezug, Kritikalität und fachliche Daten prüfen | | **CI Owner** | einzelne CIs verantworten | | **Supportgruppe** | technische Informationen ergänzen | | **Change Manager** | CMDB-Aktualisierung nach Changes sicherstellen | | **Security Team** | sicherheitsrelevante Daten nutzen und prüfen | | **Asset Manager** | Asset-, Vertrags- und Lebenszyklusdaten liefern | Die Rollen müssen nicht immer eigene Stellen sein. Wichtig sind klare Zuständigkeiten. --- **Pflege durch Prozesse erzwingen** Datenpflege funktioniert besser, wenn sie in Prozesse eingebaut ist. Beispiele: - Change kann nicht abgeschlossen werden, ohne betroffene CIs zu prüfen. - Release-Abschluss enthält CMDB-Aktualisierung. - Incident-Kategorien verlangen Servicezuordnung. - Zertifikate benötigen Owner und Ablaufdatum. - Cloud-Ressourcen ohne Pflicht-Tags werden gemeldet. - Außerbetriebnahme verlangt Abhängigkeitsprüfung. Datenpflege sollte nicht nur auf freiwilliger Erinnerung beruhen. --- **Pflegeaufwand realistisch halten** Zu viel Detailtiefe führt zu Pflegeproblemen. Fragen zur Begrenzung: - Wird dieses Feld wirklich genutzt? - Wer pflegt es? - Wie oft ändert es sich? - Kann es automatisiert werden? - Hilft es bei Incident, Problem, Change oder Security? - Ist es für einen kritischen Service notwendig? - Entsteht durch fehlende Information ein echtes Risiko? Daten, die niemand nutzt und niemand pflegt, sollten kritisch hinterfragt werden. --- **Toolunterstützung** Tools können unterstützen durch: - Pflichtfelder, - Workflows, - Discovery-Import, - Dublettenprüfung, - Beziehungsansichten, - Reports, - Erinnerungen, - Datenqualitätsregeln, - Rollenrechte, - Schnittstellen zu Monitoring und Cloud, - Verknüpfung mit Incidents und Changes. Ein Tool löst aber kein organisatorisches Problem. Ohne klare Regeln und Verantwortung wird auch ein gutes Tool schlechte Daten enthalten. --- **Integration mit ITSM-Prozessen** Configuration-Daten sollten nicht isoliert gepflegt werden. Sie sollten aktiv genutzt werden in: - Incident Management, - Problem Management, - Change Enablement, - Release Management, - Service Level Management, - Information Security Management, - IT Asset Management, - Continual Improvement. Je häufiger die Daten im Alltag genutzt werden, desto eher fallen Fehler auf. Ungenutzte Daten veralten schneller. --- **Datenqualität durch Nutzung verbessern** Wenn Service Desk und Fachteams CMDB-Daten aktiv nutzen, werden Fehler sichtbar. Beispiele: - falscher Owner wird bei Eskalation bemerkt, - fehlende Beziehung fällt bei Change-Bewertung auf, - veraltete Version fällt bei Security-Prüfung auf, - fehlender Dokumentationslink fällt im Incident auf. Wichtig ist, dass solche Fehler einfach gemeldet und korrigiert werden können. --- **Praxisbeispiel: Discovery findet unbekannten Server** **Situation** Discovery erkennt einen Server, der nicht in der CMDB steht. **Prüfung** - Ist der Server produktiv? - Welcher Service nutzt ihn? - Wer ist Owner? - Warum wurde er nicht erfasst? - Gibt es Sicherheitsrisiken? - Gibt es offene Ports? - Muss ein Change oder Problem erstellt werden? **Ergebnis** Der Server wird entweder als CI aufgenommen oder kontrolliert außer Betrieb genommen. --- **Praxisbeispiel: Falscher Owner** **Situation** Ein Incident betrifft eine Anwendung. Die CMDB nennt ein Team, das seit Monaten nicht mehr zuständig ist. **Folge** Eskalation verzögert sich. **Verbesserung** - Owner wird korrigiert, - ähnliche Services werden geprüft, - regelmäßige Owner-Reviews werden eingeführt, - Change-Übergaben müssen künftig Owner aktualisieren. --- **Praxisbeispiel: Veraltete Version** **Situation** Die CMDB zeigt Version 5.9. Discovery erkennt Version 5.8. **Mögliche Ursachen** - Update wurde nicht durchgeführt, - Rollback wurde nicht dokumentiert, - CMDB wurde zu früh aktualisiert, - Discovery scannt falsches System, - mehrere ähnliche CIs existieren. **Verbesserung** Abweichung wird geprüft, korrigiert und mit Change Record verknüpft. --- **Praxisbeispiel: Fehlende Zertifikatsdaten** **Situation** Ein produktives Zertifikat läuft ab. In der CMDB ist kein Ablaufdatum gepflegt. **Folge** Anmeldedienst fällt aus. **Verbesserung** - Zertifikate als eigene CIs erfassen, - Ablaufdatum verpflichtend machen, - Owner festlegen, - Monitoring für Ablaufdaten einführen, - Erneuerungs-Runbook verknüpfen. --- **Praxisbeispiel: Cloud-Ressource ohne Tags** **Situation** Cloud-Report zeigt mehrere Ressourcen ohne Service-Tag. **Risiko** - Kostenstelle unklar, - Owner unbekannt, - Kritikalität unbekannt, - Sicherheitsbewertung schwierig, - Außerbetriebnahme riskant. **Verbesserung** - Pflicht-Tags definieren, - Erstellung ohne Tags technisch verhindern oder melden, - Ressourcen nachträglich zuordnen, - Verantwortliche benennen. --- **Typische Fehler** **Fehler 1** Discovery-Daten werden ungeprüft in die CMDB übernommen. --- **Fehler 2** Manuelle Pflege wird niemandem eindeutig zugeordnet. --- **Fehler 3** CMDB wird einmal aufgebaut und danach nicht gepflegt. --- **Fehler 4** Changes aktualisieren Configuration-Daten nicht. --- **Fehler 5** Dubletten werden ignoriert. --- **Fehler 6** Datenqualitätsberichte werden erstellt, aber nicht bearbeitet. --- **Fehler 7** Zu viele Felder werden gepflegt, obwohl sie niemand nutzt. --- **Fehler 8** Wichtige Beziehungen fehlen trotz vieler technischer Details. --- **Fehler 9** Cloud- und Container-Ressourcen werden nicht berücksichtigt. --- **Fehler 10** Zertifikate, Schnittstellen und Benutzergruppen werden vergessen. --- **Fehler 11** Owner und Kritikalität werden nicht regelmäßig geprüft. --- **Fehler 12** Teams vertrauen der CMDB nicht mehr, weil Fehler nicht korrigiert werden. --- **Checkliste Discovery** - [ ] relevante Datenquellen festgelegt - [ ] Discovery-Bereich definiert - [ ] erkannte Objekte geprüft - [ ] Dublettenprüfung durchgeführt - [ ] Servicebezug ergänzt - [ ] Owner ergänzt - [ ] Umgebung geprüft - [ ] Status geprüft - [ ] technische Versionen übernommen - [ ] fachliche Kritikalität ergänzt - [ ] Sicherheitsrelevanz geprüft - [ ] nicht relevante Objekte ausgeschlossen oder archiviert --- **Checkliste Datenpflege** - [ ] neue CIs werden erfasst - [ ] geänderte CIs werden aktualisiert - [ ] entfernte CIs werden archiviert - [ ] Owner werden gepflegt - [ ] Versionen werden aktualisiert - [ ] Beziehungen werden gepflegt - [ ] Dokumentationslinks werden geprüft - [ ] Zertifikate werden überwacht - [ ] Cloud-Tags werden geprüft - [ ] Changes aktualisieren CMDB-Daten - [ ] Releases aktualisieren CMDB-Daten - [ ] Datenfehler können einfach gemeldet werden --- **Checkliste Datenqualität** - [ ] produktive CIs haben Owner - [ ] produktive CIs haben Servicezuordnung - [ ] kritische Services haben Abhängigkeiten - [ ] CIs haben eindeutige Namen - [ ] Dubletten werden bereinigt - [ ] Statuswerte sind aktuell - [ ] Versionen sind korrekt - [ ] Umgebungen sind eindeutig - [ ] Zertifikate besitzen Ablaufdatum - [ ] Dokumentationslinks funktionieren - [ ] letzte Prüfung ist dokumentiert - [ ] Datenqualitätsberichte werden bearbeitet --- **Checkliste nach Changes** - [ ] betroffene CIs geprüft - [ ] neue CIs angelegt - [ ] entfernte CIs archiviert - [ ] Versionen aktualisiert - [ ] Beziehungen aktualisiert - [ ] Owner geprüft - [ ] Dokumentationslinks aktualisiert - [ ] Monitoringbeziehungen geprüft - [ ] Backupbeziehungen geprüft - [ ] Known Errors aktualisiert, falls relevant - [ ] Service Map aktualisiert - [ ] Change Record mit CMDB verknüpft --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker tragen stark zur Datenqualität bei. Im Alltag bedeutet das: - technische Änderungen nicht nur ausführen, sondern dokumentieren, - Versionen und Konfigurationen korrekt erfassen, - falsche CMDB-Daten melden, - Owner und Servicebezug prüfen, - Discovery-Ergebnisse fachlich einordnen, - nach Changes Beziehungen aktualisieren, - Zertifikate, Schnittstellen und Monitoring berücksichtigen, - und Datenqualität als Teil stabilen Betriebs verstehen. Eine gute CMDB entsteht nicht allein durch ein Tool. Sie entsteht durch saubere technische Arbeit, klare Prozesse und konsequente Pflege. --- **Zusammenfassung** > technische Daten durch Discovery erkennen > ↓ > Ergebnisse prüfen und Dubletten vermeiden > ↓ > fachliche Informationen ergänzen > ↓ > Owner, Servicebezug und Kritikalität pflegen > ↓ > Changes und Releases zur Aktualisierung nutzen > ↓ > Datenqualität regelmäßig messen > ↓ > Abweichungen korrigieren > ↓ > Pflegeaufwand realistisch halten > ↓ > Configuration-Daten aktiv in ITSM-Prozessen nutzen --- **Merksätze** > Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung. > Datenpflege ist eine laufende Betriebsaufgabe, kein einmaliges Projekt. > Eine CMDB veraltet automatisch, wenn Changes sie nicht aktualisieren. > Datenqualität ist wichtiger als Datenmenge. > Schlechte Configuration-Daten können zu falschen Entscheidungen führen. > Je häufiger Daten im Alltag genutzt werden, desto schneller fallen Fehler auf. > Gute Datenqualität braucht Toolunterstützung, Prozesse und Verantwortung. --- **Verwandte Seiten** - 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen - 6.2 Configuration Items und Beziehungen - 6.3 Configuration Management Database - 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management - Change Enablement - Release Management - Incident Management - Problem Management - Information Security Management - IT Asset Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: IT Asset Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Release Management - PeopleCert – ITIL Practice Guide: Information Security Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Discovery-Beispiele, - Datenqualitätsregeln, - Pflegeprozesse, - Prüffragen, - Checklisten, - Datenqualitätskennzahlen, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Discovery-Methode, - Datenqualitätskennzahl, - Pflegefrequenz, - Pflichtfeldstruktur, - Toolintegration, - oder CMDB-Governance-Struktur für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisationsgröße, - Toollandschaft, - Datenquellen, - Cloud-Nutzung, - Sicherheitsanforderungen, - Change-Modell, - Supportmodell, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management > **Kurz erklärt** > > Service Configuration Management liefert wichtige Informationen über Services, Configuration Items, Versionen, Verantwortlichkeiten und Abhängigkeiten. > > Diese Informationen werden besonders in Incident Management, Problem Management und Change Enablement benötigt. > > Ohne aktuelle Configuration-Daten werden Störungen langsamer analysiert, Ursachen schwerer erkannt und Changes riskanter bewertet. --- **Warum das Zusammenspiel wichtig ist** Configuration-Daten sind keine reine Dokumentation. Sie unterstützen tägliche Entscheidungen im IT-Betrieb. Beispiele: - Welcher Service ist von einer Störung betroffen? - Welche Systeme hängen von einer Datenbank ab? - Wer ist Owner eines betroffenen Configuration Items? - Welche Changes wurden zuletzt an einem System durchgeführt? - Welche Version ist installiert? - Welche Services nutzen ein bestimmtes Zertifikat? - Welche Benutzergruppen sind betroffen? - Welche Lieferanten müssen eingebunden werden? - Welche Abhängigkeiten müssen vor einem Change geprüft werden? Service Configuration Management liefert die Informationsbasis. Incident, Problem und Change Management nutzen diese Informationen für Analyse, Bewertung und Steuerung. --- **Grundidee des Zusammenspiels** Service Configuration Management ↓ liefert Services, CIs, Beziehungen, Owner und Versionen ↓ Incident Management nutzt diese Daten für schnelle Diagnose ↓ Problem Management nutzt diese Daten für Ursachenanalyse ↓ Change Enablement nutzt diese Daten für Auswirkungs- und Risikobewertung ↓ Changes, Incidents und Problems liefern neue Erkenntnisse zurück ↓ Configuration-Daten werden aktualisiert und verbessert Der Kreislauf funktioniert nur, wenn Configuration-Daten gepflegt und aktiv genutzt werden. --- **Zusammenspiel mit Incident Management** Incident Management benötigt Configuration-Daten, um Störungen schneller einzuordnen. Wichtige Fragen: - Welcher Service ist betroffen? - Welche CIs gehören zum Service? - Welche Abhängigkeiten bestehen? - Wer ist zuständig? - Welche Kritikalität besitzt der Service? - Welche Changes wurden zuletzt durchgeführt? - Gibt es Known Errors? - Welche anderen Services könnten betroffen sein? - Welche Dokumentation oder Runbooks sind verknüpft? Je besser diese Informationen verfügbar sind, desto schneller kann der Incident bearbeitet werden. --- **Incident Management liefert Informationen zurück** Incidents können zeigen, dass Configuration-Daten falsch oder unvollständig sind. Beispiele: - falscher Owner im Ticket, - fehlende Servicezuordnung, - unbekannte Abhängigkeit, - nicht erfasstes Zertifikat, - veraltete Version, - falscher CI-Status, - fehlender Dokumentationslink, - nicht dokumentierte Schnittstelle. Diese Erkenntnisse sollten nicht im Incident verschwinden. Sie sollten genutzt werden, um die CMDB oder das Configuration Management System zu verbessern. --- **Beispiel: Incident mit fehlender Beziehung** **Situation** Benutzer melden, dass das Mitarbeiterportal nicht erreichbar ist. **Analyse** Der Webserver ist erreichbar. Die Anwendung kann sich aber nicht mit der Datenbank verbinden. **Problem** In der CMDB war die Datenbankbeziehung nicht gepflegt. **Folge** Die Diagnose dauert länger. **Verbesserung** Die Beziehung zwischen Mitarbeiterportal, Anwendung, Datenbank, Storage und Backup wird nachgetragen. --- **Zusammenspiel mit Problem Management** Problem Management nutzt Configuration-Daten, um Ursachen und Muster zu erkennen. Wichtige Fragen: - Betreffen mehrere Incidents dasselbe CI? - Gibt es eine gemeinsame Abhängigkeit? - Ist eine bestimmte Version auffällig? - Sind bestimmte Standorte oder Netzwerkkomponenten betroffen? - Gibt es mehrere Services mit gleichem Zertifikat? - Gibt es bekannte Lieferantenprobleme? - Wurden ähnliche Problems bereits dokumentiert? - Gibt es offene Known Errors? Configuration-Daten helfen, einzelne Incidents in einen größeren Zusammenhang einzuordnen. --- **Problem Management liefert Informationen zurück** Problem Management kann Configuration-Daten verbessern. Beispiele: - neue CI-Beziehung wird erkannt, - Known Error wird mit CI verknüpft, - fehlerhafte Version wird dokumentiert, - gemeinsame Abhängigkeit wird sichtbar, - fehlender Owner wird erkannt, - Zertifikat wird als eigenes CI aufgenommen, - Schnittstelle wird nachträglich dokumentiert, - Service Map wird ergänzt. Eine Ursachenanalyse sollte deshalb auch prüfen, ob Configuration-Daten angepasst werden müssen. --- **Beispiel: Problem durch gemeinsame Abhängigkeit** **Situation** Drei Anwendungen erzeugen ähnliche Fehlermeldungen. **Einzelbetrachtung** Jedes Team untersucht zunächst seine eigene Anwendung. **Configuration-Daten zeigen** - alle Anwendungen nutzen denselben Datenbankcluster, - der Datenbankcluster nutzt denselben Storage, - Storage zeigt erhöhte Latenz. **Ergebnis** Problem Management erkennt eine gemeinsame Ursache schneller. **Verbesserung** Die Serviceabhängigkeiten werden in der CMDB klarer gepflegt. --- **Zusammenspiel mit Change Enablement** Change Enablement benötigt Configuration-Daten für die Auswirkungs- und Risikobewertung. Wichtige Fragen: - Welche CIs werden geändert? - Welche Services hängen davon ab? - Welche Benutzer oder Standorte sind betroffen? - Welche Owner müssen eingebunden werden? - Welche Lieferanten sind beteiligt? - Welche Versionen sind betroffen? - Welche Sicherheitsrisiken entstehen? - Welche anderen Changes betreffen dieselben CIs? - Welche Tests sind erforderlich? - Welche Dokumentation muss aktualisiert werden? Ohne Configuration-Daten wird ein Change schnell zu niedrig bewertet. --- **Change Enablement liefert Informationen zurück** Changes verändern Configuration-Daten. Beispiele: - neue Version, - neue Anwendung, - neue Schnittstelle, - neue Cloud-Ressource, - geänderte Firewall-Regel, - erneuertes Zertifikat, - geänderte Datenbank, - neuer Owner, - außer Betrieb genommenes System, - geänderte Monitoringregel. Nach einem Change muss geprüft werden: > Welche Configuration-Daten müssen aktualisiert werden? Wenn Changes die CMDB nicht aktualisieren, veraltet sie automatisch. --- **Beispiel: Change mit unvollständiger Auswirkungsbewertung** **Situation** Eine Firewall-Regel wird geändert. **Annahme** Nur eine kleine technische Anpassung. **Tatsächliche Auswirkung** Die Regel betrifft eine Schnittstelle zwischen Warenwirtschaft und Versand. Nach dem Change können Aufträge nicht mehr übertragen werden. **Ursache** Die Beziehung zwischen Firewall-Regel, Schnittstelle und Geschäftsprozess war nicht dokumentiert. **Verbesserung** Schnittstellen und Firewall-Abhängigkeiten werden als relevante CIs und Beziehungen gepflegt. --- **Configuration-Daten im Change Request** Ein Change Request sollte relevante Configuration-Daten enthalten. Dazu gehören: - betroffene CIs, - betroffene Services, - Umgebung, - Kritikalität, - Owner, - Supportgruppe, - Version, - Beziehungen, - letzte Changes, - Dokumentationslinks, - bekannte Problems, - Known Errors, - Sicherheitsklassifizierung, - und betroffene Lieferanten. So wird aus einer technischen Änderung eine bewertbare Serviceänderung. --- **Zusammenspiel mit Release und Deployment Management** Release und Deployment Management benötigen Configuration-Daten für kontrollierte Bereitstellung. Wichtige Fragen: - Welche Version wird deployed? - Welche Zielumgebung ist betroffen? - Welche Komponenten gehören zum Release? - Welche Abhängigkeiten bestehen? - Welche Schnittstellen müssen funktionieren? - Welche Services sind betroffen? - Welche Knowledge-Artikel müssen aktualisiert werden? - Welche CIs erhalten einen neuen Status? - Welche CMDB-Daten ändern sich nach dem Deployment? Nach einem Release müssen Versionen, Beziehungen und Dokumentation aktualisiert werden. --- **Beispiel: Release mit Versionsänderung** **Situation** Eine neue Anwendungsversion wird ausgerollt. **Configuration Management muss aktualisieren** - Anwendungsversion, - betroffene Server, - Datenbankversion, falls geändert, - Schnittstellen, - Known Errors, - Dokumentationslink, - Service Map, - Monitoringbeziehung. **Nutzen** Bei späteren Incidents ist sofort sichtbar, welche Version produktiv läuft. --- **Zusammenspiel mit Knowledge Management** Configuration-Daten und Knowledge Management ergänzen sich. Die CMDB zeigt: - welche CIs betroffen sind, - welche Services abhängen, - wer zuständig ist, - welche Versionen genutzt werden, - welche Beziehungen bestehen. Knowledge Management liefert: - Runbooks, - Workarounds, - Known Errors, - Diagnoseanleitungen, - Benutzerinformationen, - Eskalationshinweise, - Betriebsdokumentation. Beide müssen verknüpft sein. Eine CMDB ohne Dokumentationslinks ist weniger nützlich. Eine Knowledge Base ohne Service- und CI-Bezug ist schwerer auffindbar. --- **Beispiel: Knowledge und CMDB** **Situation** Ein VPN-Problem tritt wiederholt auf. **CMDB zeigt** - VPN-Service, - VPN-Gateway, - Clientversion, - MFA-Abhängigkeit, - Identity Provider, - Supportgruppe. **Knowledge Base zeigt** - Known Error, - Workaround, - Prüfschritte, - Eskalationsweg. **Nutzen** Der Service Desk kann neue Incidents schneller erkennen und bearbeiten. --- **Zusammenspiel mit Information Security Management** Information Security Management benötigt Configuration-Daten für Risikobewertung und Schutzmaßnahmen. Wichtige Fragen: - Welche Systeme sind kritisch? - Welche CIs sind extern erreichbar? - Welche Systeme verarbeiten vertrauliche Daten? - Welche Versionen sind verwundbar? - Welche Zertifikate laufen bald ab? - Welche Benutzergruppen haben Zugriff? - Welche Schnittstellen übertragen sensible Daten? - Welche Lieferanten haben Zugriff? - Welche Systeme sind nicht inventarisiert? Ohne Configuration-Daten ist Sicherheitsarbeit unvollständig. --- **Beispiel: Sicherheitslücke** **Situation** Eine kritische Schwachstelle betrifft eine bestimmte Softwareversion. **Mit guter CMDB** Es ist erkennbar: - welche Server diese Version nutzen, - welche Services betroffen sind, - welche Systeme produktiv sind, - welche Systeme extern erreichbar sind, - wer Owner ist, - welche Changes zur Behebung nötig sind. **Nutzen** Patchpriorisierung wird schneller und nachvollziehbarer. --- **Zusammenspiel mit IT Asset Management** IT Asset Management und Service Configuration Management überschneiden sich. IT Asset Management liefert Informationen über: - Besitz, - Beschaffung, - Kosten, - Lizenzen, - Verträge, - Lebenszyklus, - Garantie, - Lieferanten, - wirtschaftliche Nutzung. Service Configuration Management ergänzt: - Servicebezug, - Abhängigkeiten, - Betriebsrelevanz, - Changes, - Incidents, - Problems, - technische Beziehungen. Ein Server kann gleichzeitig Asset und CI sein. Beide Sichten sollten zusammenpassen. --- **Zusammenspiel mit Service Level Management** Service Level Management benötigt Configuration-Daten, um Service Levels realistisch zu bewerten. Wichtige Fragen: - Welche Komponenten unterstützen einen kritischen Service? - Welche CIs benötigen hohe Verfügbarkeit? - Welche Lieferanten beeinflussen Service Levels? - Welche Abhängigkeiten können SLA-Verletzungen verursachen? - Welche Changes gefährden Service Levels? - Welche Incidents betreffen kritische CIs? Service Levels sind schwer steuerbar, wenn die Serviceabhängigkeiten unbekannt sind. --- **Zusammenspiel mit Monitoring** Monitoring und Configuration Management ergänzen sich. Monitoring zeigt: - aktueller Zustand, - Alarme, - Fehler, - Performance, - Kapazität, - Verfügbarkeit. Configuration Management zeigt: - Servicebezug, - Owner, - Kritikalität, - Beziehungen, - Version, - Dokumentationslink. Beispiel: Monitoring meldet einen Serverausfall. Die CMDB zeigt, dass daran ein geschäftskritischer Service hängt. Dadurch kann der Incident korrekt priorisiert und kommuniziert werden. --- **Zusammenspiel mit Continual Improvement** Configuration Management liefert viele Verbesserungsansätze. Beispiele: - CIs ohne Owner, - Services ohne Abhängigkeiten, - Changes ohne CI-Verknüpfung, - Incidents ohne Servicezuordnung, - veraltete Versionen, - Zertifikate ohne Ablaufdatum, - Cloud-Ressourcen ohne Tags, - kritische CIs ohne Monitoring, - Dubletten, - veraltete Dokumentationslinks. Diese Erkenntnisse sollten in Continual Improvement einfließen. --- **Typischer Informationsfluss** Incident erkennt Datenfehler ↓ Datenfehler wird dokumentiert ↓ Configuration Management prüft und korrigiert ↓ Change aktualisiert CI oder Beziehung ↓ Problem Management erkennt Muster ↓ Knowledge Management ergänzt Workaround ↓ Reporting zeigt Datenqualität ↓ Continual Improvement verbessert Prozess und Pflege Configuration Management ist dadurch Teil eines Lernkreislaufs. --- **Wichtige Schnittstelleninformationen** Für das Zusammenspiel mit anderen Practices sind besonders wichtig: - Servicezuordnung, - CI-Beziehungen, - Owner, - Supportgruppe, - Kritikalität, - Umgebung, - Status, - Version, - letzte Changes, - Known Errors, - Dokumentationslinks, - Sicherheitsklassifizierung, - Lieferantenbezug, - Monitoringbezug, - Backupbezug. Diese Informationen sollten nicht nur vorhanden sein, sondern auch aktiv genutzt werden. --- **Praxisbeispiel: Major Incident** **Situation** Ein zentraler Service fällt aus. **Incident Management benötigt** - betroffener Service, - abhängige CIs, - Owner, - Supportgruppen, - Kritikalität, - Kommunikationskontakte, - letzte Changes, - Known Errors. **Configuration Management liefert** - Service Map, - CI-Beziehungen, - betroffene Komponenten, - Dokumentationslinks. **Nachbereitung** - fehlende Beziehungen ergänzen, - falsche Owner korrigieren, - Service Map aktualisieren, - Monitoringbeziehungen prüfen. --- **Praxisbeispiel: Wiederkehrende Druckerprobleme** **Situation** Ein Standort meldet regelmäßig Druckprobleme. **Incident-Daten zeigen** - mehrere Tickets, - gleicher Standort, - unterschiedliche Benutzer. **Configuration-Daten zeigen** - gleicher Druckserver, - gleicher Treiber, - gleiche Standort-Firewall, - gleiche Fachanwendung. **Problem Management erkennt** Der Fehler hängt mit einem alten Treiber und einer bestimmten Anwendung zusammen. **Verbesserung** Treiber wird über Change Enablement aktualisiert. Knowledge-Artikel und CMDB werden angepasst. --- **Praxisbeispiel: Zertifikatsmanagement** **Situation** Ein Zertifikat läuft ab und verursacht einen Incident. **Problem Management erkennt** - Zertifikat war nicht als CI erfasst, - kein Owner dokumentiert, - kein Ablaufmonitoring, - kein Erneuerungs-Runbook. **Change Enablement setzt um** - Zertifikat erneuern, - Monitoring ergänzen, - Owner festlegen, - Runbook erstellen. **Configuration Management aktualisiert** - Zertifikat als CI, - Ablaufdatum, - Servicebeziehung, - Owner, - Monitoringbeziehung, - Dokumentationslink. --- **Praxisbeispiel: Cloud-Ressource ohne Owner** **Situation** Eine Cloud-Ressource erzeugt Kosten und ist sicherheitsrelevant. **Problem** Kein Owner, kein Service-Tag, keine Dokumentation. **Risiko** - niemand fühlt sich verantwortlich, - Sicherheitsbewertung unklar, - Außerbetriebnahme riskant, - Kosten nicht zuordenbar. **Verbesserung** - Tag-Regeln einführen, - Owner verpflichtend machen, - Cloud-Discovery anbinden, - Ressourcen ohne Tags regelmäßig berichten, - Change-Prozess anpassen. --- **Typische Fehler im Zusammenspiel** **Fehler 1** CMDB wird gepflegt, aber im Incident Management nicht genutzt. --- **Fehler 2** Incidents zeigen Datenfehler, aber niemand korrigiert sie. --- **Fehler 3** Problem Management erkennt neue Abhängigkeiten, aber sie werden nicht dokumentiert. --- **Fehler 4** Changes ändern CIs, ohne die CMDB zu aktualisieren. --- **Fehler 5** Release und Deployment aktualisieren Versionen nicht. --- **Fehler 6** Knowledge-Artikel sind nicht mit Services oder CIs verknüpft. --- **Fehler 7** Security bewertet Risiken ohne aktuelle Configuration-Daten. --- **Fehler 8** Monitoring-Alarme enthalten keine Serviceinformationen. --- **Fehler 9** Asset-Daten und CI-Daten widersprechen sich. --- **Fehler 10** Owner und Supportgruppen sind veraltet. --- **Fehler 11** Configuration-Daten werden nur für Audits gepflegt, nicht für den Betrieb. --- **Fehler 12** Datenqualitätsprobleme werden gemessen, aber nicht verbessert. --- **Checkliste Zusammenspiel mit Incident Management** - [ ] Incident enthält betroffenen Service - [ ] relevante CIs sind verknüpft - [ ] Kritikalität ist sichtbar - [ ] Owner und Supportgruppe sind erkennbar - [ ] letzte Changes sind prüfbar - [ ] Known Errors sind auffindbar - [ ] Dokumentationslinks sind vorhanden - [ ] Datenfehler können gemeldet werden - [ ] fehlende Beziehungen werden nachgetragen - [ ] wiederkehrende CI-bezogene Incidents werden ausgewertet --- **Checkliste Zusammenspiel mit Problem Management** - [ ] Problems sind mit relevanten CIs verknüpft - [ ] gemeinsame Abhängigkeiten werden geprüft - [ ] betroffene Versionen werden dokumentiert - [ ] Known Errors werden mit CIs verknüpft - [ ] neue Beziehungen aus RCA werden ergänzt - [ ] fehlende Owner werden korrigiert - [ ] Service Maps werden nach Analyse aktualisiert - [ ] Workarounds werden mit Knowledge verknüpft - [ ] Problem-Erkenntnisse verbessern Configuration-Daten --- **Checkliste Zusammenspiel mit Change Enablement** - [ ] Change Request enthält betroffene CIs - [ ] abhängige Services wurden geprüft - [ ] Kritikalität wurde berücksichtigt - [ ] Owner wurden einbezogen - [ ] Sicherheitsklassifizierung wurde geprüft - [ ] parallele Changes an gleichen CIs wurden geprüft - [ ] CMDB-Aktualisierung ist Teil des Change-Abschlusses - [ ] neue CIs werden erstellt - [ ] entfernte CIs werden archiviert - [ ] geänderte Beziehungen werden aktualisiert --- **Checkliste Zusammenspiel mit Release und Deployment** - [ ] Release enthält betroffene CIs - [ ] Zielumgebung ist korrekt dokumentiert - [ ] Versionen werden nach Deployment aktualisiert - [ ] Schnittstellen werden geprüft - [ ] Known Errors werden aktualisiert - [ ] Service Desk erhält relevante CI-Informationen - [ ] Dokumentationslinks werden aktualisiert - [ ] Monitoringbeziehungen werden geprüft - [ ] CMDB-Abschluss ist Teil der Nachbereitung --- **Checkliste Zusammenspiel mit Security** - [ ] kritische CIs sind gekennzeichnet - [ ] externe Erreichbarkeit ist dokumentiert - [ ] Datenklassifizierung ist gepflegt - [ ] Zertifikate sind als CIs erfasst - [ ] Ablaufdaten werden überwacht - [ ] privilegierte Gruppen sind dokumentiert - [ ] veraltete Versionen sind auswertbar - [ ] Schwachstellen können Services zugeordnet werden - [ ] Lieferantenbezug ist sichtbar - [ ] Sicherheitsrelevante Changes nutzen CI-Daten --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten täglich an der Schnittstelle zwischen Technik, Support und Betrieb. Für sie bedeutet das: - bei Incidents betroffene CIs korrekt erfassen, - bei Problems Abhängigkeiten erkennen, - bei Changes betroffene Services prüfen, - nach Änderungen CMDB-Daten aktualisieren, - Versionen und Konfigurationen nachvollziehbar dokumentieren, - falsche Owner oder Beziehungen melden, - Knowledge-Artikel mit Services oder CIs verknüpfen, - und technische Beobachtungen in nutzbare Betriebsinformationen überführen. Gute Configuration-Daten entstehen nicht nur durch ein Tool. Sie entstehen durch konsequente Nutzung im Alltag. --- **Zusammenfassung** > Configuration-Daten bereitstellen > ↓ > Incident Management nutzt sie für Diagnose und Priorisierung > ↓ > Problem Management nutzt sie für Muster und Ursachen > ↓ > Change Enablement nutzt sie für Risiko- und Auswirkungsbewertung > ↓ > Release und Deployment aktualisieren Versionen und Beziehungen > ↓ > Knowledge Management verknüpft Workarounds und Runbooks > ↓ > Security nutzt Daten für Risiko- und Schwachstellenbewertung > ↓ > Datenfehler und neue Erkenntnisse fließen zurück > ↓ > CMDB, Service Maps und Dokumentation werden verbessert --- **Merksätze** > Configuration-Daten sind nur wertvoll, wenn sie im Betrieb genutzt werden. > Incident Management braucht Service- und CI-Bezug für schnelle Diagnose. > Problem Management braucht Beziehungen, um gemeinsame Ursachen zu erkennen. > Change Enablement braucht Abhängigkeiten für realistische Risikobewertung. > Jeder relevante Change sollte Configuration-Daten aktualisieren. > Knowledge ohne CI-Bezug ist schwerer auffindbar. > Monitoring ohne Servicebezug erschwert Priorisierung. > Gute Configuration-Daten verbessern Support, Stabilität, Sicherheit und Veränderungsfähigkeit. --- **Verwandte Seiten** - 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen - 6.2 Configuration Items und Beziehungen - 6.3 Configuration Management Database - 6.4 Discovery, Pflege und Datenqualität - Incident Management - Problem Management - Change Enablement - Release Management - Knowledge Management - Information Security Management - IT Asset Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Release Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Information Security Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Schnittstellen, - Informationsflüsse, - Praxisbeispiele, - Checklisten, - Rollenhinweise, - und Datenqualitätsbezüge sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Schnittstellenmatrix, - CMDB-Prozessintegration, - Pflichtverknüpfung, - Service-Map-Struktur, - Reporting-Form, - oder Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Organisationsgröße, - Supportmodell, - Change-Modell, - Toollandschaft, - Datenqualität, - Sicherheitsanforderungen, - Cloud-Nutzung, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 7. Knowledge Management # 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen > **Kurz erklärt** > > Knowledge Management sorgt dafür, dass wichtiges Wissen im IT-Betrieb gesammelt, geprüft, strukturiert, auffindbar und nutzbar gemacht wird. > > Ziel ist, dass Mitarbeitende, Service Desk, Fachgruppen und Benutzer nicht jedes Problem immer wieder neu lösen müssen. > > Gute Wissensnutzung verbessert Supportqualität, verkürzt Bearbeitungszeiten, reduziert Wiederholungsfehler und macht IT-Services stabiler. --- **Warum Knowledge Management wichtig ist** Im IT-Betrieb entsteht täglich Wissen. Beispiele: - bekannte Fehlermeldungen, - Workarounds, - Standardlösungen, - Installationsanleitungen, - Betriebsrunbooks, - Eskalationswege, - bekannte Fehler, - Anleitungen für Benutzer, - technische Prüfschritte, - Lessons Learned aus Incidents, - Ergebnisse aus Problem Management, - Änderungen nach Releases, - Sicherheits- und Betriebshinweise. Wenn dieses Wissen nicht dokumentiert wird, entstehen typische Probleme: - dieselben Fragen werden immer wieder gestellt, - Service Desk analysiert bekannte Fehler jedes Mal neu, - Lösungen hängen von einzelnen Personen ab, - neue Mitarbeitende brauchen länger, - Workarounds werden uneinheitlich angewendet, - Benutzer erhalten widersprüchliche Antworten, - Wissen geht bei Krankheit, Urlaub oder Wechsel verloren, - und Incidents dauern länger als nötig. Knowledge Management macht Wissen wiederverwendbar. --- **Ziel von Knowledge Management** Knowledge Management soll sicherstellen, dass richtiges Wissen zur richtigen Zeit für die richtige Zielgruppe verfügbar ist. Ziele sind: - Wissen auffindbar machen, - Lösungen wiederverwendbar machen, - Bearbeitungszeiten reduzieren, - Fehler bei Standardfällen vermeiden, - Self-Service ermöglichen, - Service Desk entlasten, - Qualität von Antworten verbessern, - neue Mitarbeitende schneller einarbeiten, - Lessons Learned sichern, - und kontinuierliche Verbesserung unterstützen. Knowledge Management ist kein reines Dokumentationsarchiv. Es ist ein aktiver Bestandteil des Servicebetriebs. --- **Wissen ist nicht gleich Dokumentation** Dokumentation kann Wissen enthalten. Aber nicht jede Dokumentation ist automatisch nützliches Wissen. | Dokumentation | Nutzbares Wissen | |---|---| | irgendwo abgelegt | auffindbar | | sehr technisch oder unklar | zielgruppengerecht | | veraltet | geprüft und aktuell | | ohne Zusammenhang | mit Service, CI oder Prozess verknüpft | | nur für Spezialisten verständlich | für passende Zielgruppe verständlich | | nicht gepflegt | mit Owner und Review versehen | Beispiel: Ein 80-seitiges Betriebshandbuch kann wichtig sein. Für den Service Desk ist aber oft ein kurzer Artikel mit Symptomen, Prüfschritten, Workaround und Eskalationsweg hilfreicher. --- **Arten von Wissen** Im IT-Betrieb gibt es unterschiedliche Wissensarten. | Wissensart | Beispiel | |---|---| | **Benutzerwissen** | Anleitung zum Zurücksetzen des Passworts | | **Service-Desk-Wissen** | Prüfschritte bei VPN-Problemen | | **Fachwissen** | technische Analyse einer Datenbankstörung | | **Betriebswissen** | Runbook für Neustart eines Dienstes | | **Known-Error-Wissen** | bekannter Fehler mit Workaround | | **Change-Wissen** | Hinweise nach einem Update | | **Sicherheitswissen** | Umgang mit verdächtigen Mails | | **Servicewissen** | Zuständigkeiten, Supportzeiten und Abhängigkeiten | Diese Wissensarten benötigen unterschiedliche Form, Sprache und Zugriffsbeschränkung. --- **Explizites und implizites Wissen** **Explizites Wissen** ist dokumentiert und kann weitergegeben werden. Beispiele: - Knowledge-Artikel, - Runbook, - Checkliste, - FAQ, - Servicebeschreibung, - Known Error, - Installationsanleitung. **Implizites Wissen** ist in den Köpfen von Personen vorhanden. Beispiele: - Erfahrung mit einem instabilen System, - bekannte Eigenheiten eines Lieferanten, - typische Fehler nach Updates, - inoffizielle Abhängigkeiten, - bewährte Diagnosewege. Knowledge Management versucht, wichtiges implizites Wissen in nutzbares explizites Wissen zu überführen. --- **Wissen muss zielgruppengerecht sein** Nicht jede Zielgruppe benötigt dieselben Informationen. | Zielgruppe | braucht typischerweise | |---|---| | **Benutzer** | einfache Anleitung, klare Schritte, keine internen Details | | **Service Desk** | Symptome, Prüfschritte, Workaround, Eskalationsweg | | **Fachteam** | technische Details, Logs, Konfigurationen, Ursachen | | **Management** | Risiko, Auswirkungen, Status, Entscheidungspunkte | | **Security Team** | Schutzmaßnahmen, Meldewege, Klassifizierung | | **Lieferant** | technische Nachweise, Versionen, Fehlerbild | Ein Benutzerartikel sollte keine internen Admin-Schritte enthalten. Ein interner Runbook-Artikel darf technischer und detaillierter sein. --- **Beispiele für Knowledge-Artikel** Mögliche Artikeltypen: - „VPN verbindet nicht nach Ruhezustand“ - „Passwort über Self-Service zurücksetzen“ - „Druckwarteschlange sicher neu starten“ - „TLS-Zertifikat erneuern“ - „Known Error: Client-Version 5.8 verliert Tunnelzustand“ - „Runbook: Datenbankdienst kontrolliert neu starten“ - „Checkliste: Server nach Update prüfen“ - „FAQ: MFA bei neuem Smartphone einrichten“ - „Service Desk: Erstdiagnose bei DNS-Problemen“ - „Benutzerinformation: Wartungsfenster Mitarbeiterportal“ Wichtig ist, dass Titel und Inhalt Suchbegriffe aus der Praxis berücksichtigen. --- **Knowledge Base** Eine Knowledge Base ist ein strukturierter Ort für Wissen. Sie kann enthalten: - Benutzeranleitungen, - interne Supportartikel, - technische Runbooks, - FAQ, - Known Errors, - Workarounds, - Checklisten, - Troubleshooting-Guides, - Servicebeschreibungen, - Release-Hinweise, - Sicherheitsanweisungen. Das Werkzeug ist nicht entscheidend. Möglich sind: - ITSM-System, - Wiki, - Self-Service-Portal, - Dokumentationsplattform, - Knowledge-Modul, - internes Handbuch. Wichtig sind Auffindbarkeit, Aktualität, Qualität und Pflegeverantwortung. --- **Knowledge Management und Self-Service** Knowledge Management unterstützt Self-Service. Benutzer können einfache Anliegen selbst lösen, wenn Informationen verständlich bereitstehen. Beispiele: - Passwort zurücksetzen, - MFA neu einrichten, - WLAN verbinden, - Standardsoftware beantragen, - Drucker hinzufügen, - Status einer Störung prüfen, - häufige Fehlermeldung verstehen. Self-Service funktioniert nur, wenn Artikel: - leicht auffindbar, - verständlich formuliert, - aktuell, - kurz genug, - und praktisch getestet sind. Ein schlechter Self-Service erzeugt zusätzliche Rückfragen. --- **Knowledge Management und Service Desk** Der Service Desk profitiert besonders von guter Wissensbasis. Nützlich sind: - Standardantworten, - Diagnosefragen, - Prüfschritte, - bekannte Symptome, - Workarounds, - Eskalationskriterien, - Priorisierungshinweise, - Kommunikationsvorlagen, - Links zu Runbooks, - Known Errors, - Serviceinformationen. Dadurch kann der Service Desk schneller und einheitlicher arbeiten. Gleichzeitig liefert der Service Desk viele Hinweise, welche Artikel fehlen oder verbessert werden müssen. --- **Knowledge Management und Incident Management** Incident Management nutzt Wissen zur schnellen Wiederherstellung. Beispiele: - bekannter Workaround wird angewendet, - Service Desk findet passenden Artikel, - Incident wird mit Knowledge-Artikel verknüpft, - Benutzer erhält geprüfte Anleitung, - wiederkehrender Fehler wird schneller erkannt. Incident Management liefert auch neues Wissen zurück. Beispiele: - neue Fehlermeldung, - neuer Workaround, - unklare Anleitung, - falscher Artikel, - fehlender Eskalationsweg, - wiederkehrende Benutzerfrage. --- **Knowledge Management und Problem Management** Problem Management erzeugt wichtiges Wissen. Beispiele: - bekannte Ursachen, - Known Errors, - Workarounds, - dauerhafte Lösungen, - beitragende Faktoren, - Lessons Learned, - technische Prüfschritte, - Risikohinweise. Dieses Wissen sollte nicht nur im Problem Record bleiben. Es muss so aufbereitet werden, dass Service Desk, Fachgruppen oder Benutzer es nutzen können. --- **Knowledge Management und Change Enablement** Changes verändern Services und damit auch Wissen. Nach einem Change müssen möglicherweise aktualisiert werden: - Benutzeranleitungen, - Screenshots, - Menüpfade, - Runbooks, - Known Errors, - Workarounds, - Servicebeschreibungen, - Supportwege, - Monitoringhinweise, - Eskalationsregeln. Ein Change ist nicht vollständig abgeschlossen, wenn die Technik geändert wurde, aber das Wissen noch den alten Stand zeigt. --- **Knowledge Management und Release Management** Releases bringen neue oder geänderte Funktionen. Knowledge Management unterstützt durch: - Release Notes, - Benutzerinformationen, - Service-Desk-Briefings, - bekannte Einschränkungen, - neue Workarounds, - aktualisierte FAQ, - Schulungsunterlagen, - Hinweise auf geänderte Prozesse. Nach einem Release steigen oft Rückfragen, wenn Wissen nicht rechtzeitig vorbereitet wurde. --- **Knowledge Management und Service Configuration Management** Configuration-Daten helfen, Wissen besser zuzuordnen. Beispiele: - Artikel gehört zu einem Service, - Workaround gehört zu einem Known Error, - Runbook gehört zu einem CI, - Anleitung gehört zu einer Anwendungsversion, - Sicherheitsartikel gehört zu einer bestimmten Benutzergruppe. Ohne Service- oder CI-Bezug sind Knowledge-Artikel schwerer auffindbar und schwerer aktuell zu halten. --- **Lebenszyklus von Wissen** Wissen sollte einen Lebenszyklus besitzen. Bedarf erkennen ↓ Wissen erfassen ↓ Inhalt prüfen ↓ Artikel veröffentlichen ↓ Artikel nutzen ↓ Feedback sammeln ↓ Artikel aktualisieren ↓ Artikel archivieren oder entfernen Wissen darf nicht dauerhaft ungeprüft online bleiben. Veraltetes Wissen kann falsche Handlungen verursachen. --- **Wissensbedarf erkennen** Wissensbedarf entsteht zum Beispiel durch: - häufige Incidents, - wiederkehrende Benutzerfragen, - neue Services, - neue Releases, - Major Incidents, - bekannte Fehler, - fehlende Runbooks, - neue Mitarbeitende, - Sicherheitsvorfälle, - unklare Eskalationen, - wiederholte Fehlbedienung, - Service-Desk-Rückfragen. Eine gute Frage ist: > Welche Information hätte den letzten Incident schneller lösbar gemacht? --- **Wissen erfassen** Wissen kann erfasst werden aus: - gelösten Incidents, - Problem Records, - Known Errors, - Change Records, - Release Notes, - Betriebsdokumentation, - Expertenwissen, - Benutzerfeedback, - Schulungen, - Lieferanteninformationen, - Monitoring-Analysen, - Major-Incident-Reviews, - Lessons Learned. Wichtig ist, Wissen nicht nur zu sammeln, sondern zu strukturieren und nutzbar zu machen. --- **Wissen prüfen** Vor Veröffentlichung sollte geprüft werden: - Ist der Inhalt fachlich korrekt? - Ist die Zielgruppe klar? - Ist der Artikel verständlich? - Sind Schritte vollständig? - Sind Risiken genannt? - Sind Screenshots aktuell? - Gibt es Sicherheits- oder Datenschutzprobleme? - Ist der Artikel mit Service oder CI verknüpft? - Ist ein Owner eingetragen? - Gibt es ein Review-Datum? Ungeprüfte Artikel können mehr Schaden als Nutzen verursachen. --- **Wissen veröffentlichen** Bei Veröffentlichung ist wichtig: - passender Titel, - klare Suchbegriffe, - sinnvolle Kategorie, - Zielgruppe, - Zugriffsschutz, - Version oder Gültigkeit, - Owner, - Veröffentlichungsdatum, - Review-Datum, - Verknüpfung zu Service, CI, Known Error oder Change. Ein Artikel muss so veröffentlicht werden, dass er im richtigen Moment gefunden wird. --- **Wissen nutzen** Wissen sollte aktiv in Prozesse eingebunden sein. Beispiele: - Service Desk sucht beim Ticketstart nach Artikeln, - Ticketformular schlägt passende Artikel vor, - Benutzer erhalten Self-Service-Vorschläge, - Known Errors sind mit Incidents verknüpft, - Change-Abschluss verlangt Knowledge-Prüfung, - Problem-Abschluss verlangt Workaround- oder Known-Error-Dokumentation. Ungenutztes Wissen veraltet schneller. --- **Feedback sammeln** Feedback hilft, Knowledge-Artikel zu verbessern. Mögliche Signale: - Artikel wird häufig genutzt, - Artikel wird selten gefunden, - Benutzer bewerten Artikel schlecht, - Service Desk ergänzt immer wieder dieselbe Erklärung, - Artikel löst das Problem nicht, - Suchbegriffe führen zu keinem Treffer, - Artikel ist nach Release veraltet, - Schrittfolge ist unklar. Feedback sollte einfach möglich sein. --- **Wissen aktualisieren** Artikel müssen aktualisiert werden, wenn sich etwas ändert. Auslöser: - Change, - Release, - neuer Known Error, - gelöster Known Error, - neue Version, - neuer Menüpfad, - geänderte Zuständigkeit, - geänderter Workaround, - Sicherheitswarnung, - Benutzerfeedback, - neue Screenshots, - geänderter Service. Ein Artikel ohne Pflegeverantwortung veraltet meist schnell. --- **Wissen archivieren** Nicht mehr gültige Artikel sollten archiviert oder entfernt werden. Beispiele: - alter Workaround gilt nicht mehr, - Service wurde abgeschaltet, - Version ist nicht mehr im Einsatz, - Known Error wurde behoben, - Anleitung bezieht sich auf alte Oberfläche, - Sicherheitsanweisung wurde ersetzt. Archivierung kann sinnvoll sein, wenn spätere Nachvollziehbarkeit wichtig ist. Veraltete Artikel sollten aber nicht mehr als aktuelle Lösung erscheinen. --- **Qualitätsmerkmale guter Knowledge-Artikel** Ein guter Artikel ist: - fachlich korrekt, - aktuell, - klar strukturiert, - verständlich, - zielgruppengerecht, - auffindbar, - mit Service oder CI verknüpft, - mit Owner versehen, - risikoarm anwendbar, - getestet, - und regelmäßig überprüft. Ein guter Artikel beantwortet nicht alles. Er beantwortet genau das, was die Zielgruppe in dieser Situation braucht. --- **Struktur eines Supportartikels** Ein Service-Desk-Artikel kann enthalten: - Titel, - Kurzbeschreibung, - Symptome, - betroffener Service, - Zielgruppe, - Voraussetzungen, - Prüfschritte, - Lösung oder Workaround, - Abbruchkriterien, - Eskalationsweg, - Risiken, - verwandte Artikel, - Owner, - Review-Datum. Nicht jeder Artikel benötigt alle Felder. Die Struktur muss zum Zweck passen. --- **Struktur eines Benutzerartikels** Ein Benutzerartikel sollte besonders verständlich sein. Mögliche Struktur: - Was ist das Problem? - Wen betrifft es? - Was kann ich selbst tun? - Schritt-für-Schritt-Anleitung, - erwartetes Ergebnis, - wann muss ich ein Ticket erstellen? - welche Informationen soll ich im Ticket angeben? - Link zu weiterem Support. Benutzerartikel sollten keine unnötigen internen Fachbegriffe enthalten. --- **Struktur eines Runbooks** Ein Runbook ist eine betriebliche Schritt-für-Schritt-Anleitung. Mögliche Inhalte: - Zweck, - betroffener Service, - Voraussetzungen, - benötigte Berechtigungen, - Sicherheits- oder Risiko-Hinweise, - genaue Schritte, - Prüfpunkte, - erwartete Ergebnisse, - Abbruchkriterien, - Rollback, - Eskalation, - Dokumentation nach Durchführung. Runbooks sind besonders wichtig für wiederkehrende technische Betriebsaufgaben. --- **Titel und Suchbegriffe** Der Titel sollte so gewählt werden, dass Benutzer oder Service Desk den Artikel finden. Ungeeignet: > Fehler 0x80231-A Spezialfall Besser: > VPN verbindet nach Ruhezustand nicht mehr Ungeeignet: > Authentifizierungsproblem Anwendung X Besser: > Anmeldung im Mitarbeiterportal schlägt fehl Ein Artikel kann zusätzlich Synonyme oder typische Fehlermeldungen enthalten. --- **Artikel kurz und praktisch halten** Zu lange Artikel werden oft nicht gelesen. Besser sind: - klare Überschriften, - kurze Schritte, - konkrete Beispiele, - Tabellen bei Varianten, - Hinweise auf Risiken, - Links zu tieferer Dokumentation. Ein Artikel sollte nicht versuchen, ein ganzes Handbuch zu ersetzen. Für tiefe technische Details kann auf Runbooks oder Fachteamdokumentation verwiesen werden. --- **Wissensfreigabe** Nicht jeder Artikel darf ohne Prüfung veröffentlicht werden. Freigabe kann erforderlich sein bei: - Sicherheitsanweisungen, - Workarounds mit Risiko, - Benutzerkommunikation, - Anleitungen mit Administratorrechten, - Datenschutzbezug, - Änderungen an kritischen Services, - rechtlichen oder vertraglichen Aussagen. Die Freigabe muss aber zum Risiko passen. Zu viel Freigabeaufwand verhindert schnelle Wissensnutzung. --- **Zugriffsschutz** Knowledge-Artikel können unterschiedliche Sichtbarkeit haben. Beispiele: | Sichtbarkeit | Beispiel | |---|---| | öffentlich für Benutzer | MFA einrichten | | intern für Service Desk | Prüfschritte bei VPN-Störung | | nur Fachteam | Datenbank-Restart-Runbook | | vertraulich | Sicherheitsvorfall-Prozess | | Management | Risiko- und Statusübersicht | Zu viele Einschränkungen verhindern Nutzen. Zu wenig Einschränkung kann Sicherheitsrisiken erzeugen. --- **Knowledge Owner** Ein Knowledge Owner ist verantwortlich für Inhalt und Aktualität eines Artikels. Aufgaben: - fachliche Korrektheit prüfen, - Review durchführen, - Änderungen einarbeiten, - veraltete Inhalte entfernen, - Feedback bewerten, - Gültigkeit bestätigen, - verwandte Artikel prüfen. Ohne Owner veralten Artikel häufig. --- **Review-Datum** Ein Review-Datum zeigt, wann ein Artikel überprüft werden muss. Besonders wichtig bei: - sicherheitsrelevanten Artikeln, - Workarounds, - Known Errors, - Benutzeranleitungen mit Screenshots, - Runbooks, - Artikeln zu kritischen Services, - Lieferantenabhängigkeiten. Ein Artikel kann auch vor dem Review-Datum aktualisiert werden, wenn ein Change oder Release den Inhalt verändert. --- **Wissensqualität messen** Mögliche Kennzahlen: | Kennzahl | mögliche Aussage | |---|---| | häufig genutzte Artikel | wichtiges Wissen | | schlechte Bewertungen | Artikel unklar oder falsch | | Suchanfragen ohne Treffer | Wissenslücke | | Artikel ohne Owner | Pflegeproblem | | Artikel ohne Review | Aktualität unsicher | | Tickets trotz Artikel | Artikel nicht auffindbar oder nicht hilfreich | | Workarounds ohne Artikel | Wissen nicht verfügbar | | alte Artikel mit hoher Nutzung | Risiko veralteter Informationen | Kennzahlen müssen mit Feedback und Kontext bewertet werden. --- **Knowledge Management und KCS** Viele Organisationen orientieren sich an Ansätzen wie **Knowledge-Centered Service (KCS)**. Grundidee: - Wissen entsteht während der Arbeit, - Lösungen werden beim Bearbeiten von Tickets erfasst, - Artikel werden durch Nutzung verbessert, - Wissen wird nicht erst nachträglich als Zusatzaufgabe gepflegt. Wichtig: KCS ist ein Praxisansatz und nicht identisch mit ITIL. Er kann Knowledge Management sinnvoll ergänzen. --- **Wissen während der Arbeit erfassen** Gute Praxis ist: - Wenn ein Incident gelöst wird, prüfe, ob Wissen dokumentiert werden sollte. - Wenn ein Artikel fehlt, erstelle einen Entwurf. - Wenn ein Artikel falsch ist, markiere oder korrigiere ihn. - Wenn ein Workaround genutzt wird, verknüpfe ihn. - Wenn ein Known Error entsteht, veröffentliche passende Informationen. - Wenn ein Release kommt, aktualisiere relevante Artikel. Wissen sollte dort entstehen, wo die Arbeit stattfindet. --- **Typische Fehler** **Fehler 1** Knowledge Base wird als Ablage für alte Dokumente genutzt. --- **Fehler 2** Artikel haben keinen Owner. --- **Fehler 3** Artikel werden veröffentlicht, aber nie überprüft. --- **Fehler 4** Benutzerartikel sind zu technisch. --- **Fehler 5** Interne Runbooks sind für Benutzer sichtbar. --- **Fehler 6** Workarounds stehen nur in Tickets. --- **Fehler 7** Known Errors werden nicht mit Artikeln verknüpft. --- **Fehler 8** Service Desk nutzt vorhandenes Wissen nicht. --- **Fehler 9** Suchbegriffe passen nicht zur Sprache der Benutzer. --- **Fehler 10** Nach Changes und Releases werden Artikel nicht aktualisiert. --- **Fehler 11** Feedback wird gesammelt, aber nicht bearbeitet. --- **Fehler 12** Veraltete Artikel bleiben als aktuelle Lösung sichtbar. --- **Praxisbeispiel: VPN-Fehler** **Situation** Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung. **Problem** Der Service Desk erklärt den Workaround jedes Mal neu. **Knowledge Management** Ein Artikel wird erstellt mit: - Symptomen, - betroffener Clientversion, - Prüfschritten, - Workaround, - Eskalationsweg, - Known-Error-Verknüpfung. **Nutzen** Neue Incidents werden schneller gelöst. Der Service Desk arbeitet einheitlicher. --- **Praxisbeispiel: MFA-Einrichtung** **Situation** Viele Benutzer erstellen Tickets zur MFA-Einrichtung. **Analyse** Der Self-Service-Artikel ist schwer auffindbar und zu technisch. **Verbesserung** - neuer Titel mit Benutzerbegriffen, - klare Schritt-für-Schritt-Anleitung, - Screenshots, - Abschnitt „Wann muss ich ein Ticket erstellen?“, - Link direkt im Serviceportal. **Nutzen** Weniger Tickets und bessere Benutzererfahrung. --- **Praxisbeispiel: Change macht Artikel veraltet** **Situation** Nach einem Release ändern sich Menüpfade im Mitarbeiterportal. **Problem** Der alte Knowledge-Artikel zeigt falsche Schritte. **Folge** Benutzer erstellen Tickets, obwohl die Funktion vorhanden ist. **Verbesserung** Change-Abschluss enthält künftig die Prüfung betroffener Knowledge-Artikel. --- **Praxisbeispiel: Runbook fehlt** **Situation** Ein Dienst muss regelmäßig kontrolliert neu gestartet werden. **Problem** Nur ein erfahrener Administrator kennt die genaue Reihenfolge. **Risiko** Bei Abwesenheit wird der Dienst falsch neu gestartet. **Knowledge Management** Ein Runbook wird erstellt mit: - Voraussetzungen, - Schritten, - Prüfungen, - Abbruchkriterien, - Rollback, - Eskalationsweg. **Nutzen** Die Aufgabe wird sicherer und wiederholbarer. --- **Checkliste Knowledge-Artikel erstellen** - [ ] Zielgruppe festgelegt - [ ] Problem oder Thema klar beschrieben - [ ] betroffener Service genannt - [ ] Symptome oder Anlass beschrieben - [ ] Voraussetzungen genannt - [ ] Schritte verständlich formuliert - [ ] erwartetes Ergebnis genannt - [ ] Risiken oder Einschränkungen beschrieben - [ ] Eskalationsweg angegeben - [ ] verwandte Artikel verknüpft - [ ] Owner eingetragen - [ ] Review-Datum gesetzt --- **Checkliste Benutzerartikel** - [ ] einfache Sprache - [ ] keine unnötigen internen Begriffe - [ ] klare Schrittfolge - [ ] Screenshots aktuell, falls verwendet - [ ] Suchbegriffe der Benutzer berücksichtigt - [ ] Voraussetzungen genannt - [ ] erwartetes Ergebnis beschrieben - [ ] Ticketweg erklärt - [ ] keine vertraulichen internen Informationen enthalten --- **Checkliste interner Supportartikel** - [ ] bekannte Symptome beschrieben - [ ] betroffene Services oder CIs verknüpft - [ ] Prüfschritte enthalten - [ ] Workaround beschrieben - [ ] Abbruchkriterien genannt - [ ] Eskalationskriterien definiert - [ ] Known Error verknüpft, falls vorhanden - [ ] Risiken beschrieben - [ ] Owner und Review-Datum vorhanden --- **Checkliste Knowledge-Pflege** - [ ] Artikel mit hohem Nutzungsgrad geprüft - [ ] schlecht bewertete Artikel überprüft - [ ] Suchanfragen ohne Treffer ausgewertet - [ ] Artikel ohne Owner bereinigt - [ ] Artikel ohne Review-Datum geprüft - [ ] veraltete Artikel archiviert - [ ] Artikel nach Changes aktualisiert - [ ] Artikel nach Releases aktualisiert - [ ] Feedback bearbeitet - [ ] doppelte Artikel zusammengeführt --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker besitzen viel praktisches Betriebswissen. Dieses Wissen ist besonders wertvoll, wenn es dokumentiert und nutzbar gemacht wird. Im Arbeitsalltag bedeutet das: - Lösungen aus Incidents als Wissen sichern, - wiederkehrende Fehler als Artikel dokumentieren, - technische Runbooks schreiben, - Workarounds sauber beschreiben, - bekannte Risiken nennen, - Service Desk mit Prüfschritten unterstützen, - nach Changes Dokumentation aktualisieren, - und veraltete Artikel melden oder korrigieren. Gute Wissensarbeit spart nicht nur Zeit. Sie macht IT-Betrieb zuverlässiger und weniger abhängig von Einzelpersonen. --- **Zusammenfassung** > Wissensbedarf erkennen > ↓ > Wissen während der Arbeit erfassen > ↓ > Zielgruppe und Zweck festlegen > ↓ > Artikel strukturiert erstellen > ↓ > fachlich prüfen > ↓ > veröffentlichen und auffindbar machen > ↓ > in Incident, Problem, Change und Service Desk nutzen > ↓ > Feedback auswerten > ↓ > Artikel aktualisieren oder archivieren > ↓ > Wissensqualität kontinuierlich verbessern --- **Merksätze** > Wissen ist nur wertvoll, wenn es gefunden, verstanden und genutzt wird. > Eine Knowledge Base ist kein Ablageort für beliebige Dokumente. > Benutzer, Service Desk und Fachteam benötigen unterschiedliche Detailtiefe. > Workarounds gehören nicht nur ins Ticket, sondern in nutzbare Knowledge-Artikel. > Nach Changes und Releases muss Wissen aktualisiert werden. > Veraltetes Wissen kann neue Incidents verursachen. > Gute Wissensarbeit reduziert Abhängigkeit von Einzelpersonen. --- **Verwandte Seiten** - 7.2 Knowledge-Artikel, Runbooks und FAQ - 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk - 7.4 Self-Service und Benutzerwissen - 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change - Incident Management - Problem Management - Change Enablement - Release Management - Service Configuration Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Release Management - ITIL Foundation – Version 5 **Ergänzende Praxiseinordnung** - Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support **Einordnung** Die dargestellten: - Artikeltypen, - Checklisten, - Rollenhinweise, - Lebenszyklusmodelle, - Qualitätskriterien, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Knowledge-Artikel-Vorlage, - Review-Frequenz, - Knowledge-Base-Struktur, - Rollenverteilung, - KCS-Nutzung, - oder Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Zielgruppen, - Supportmodell, - Sicherheitsanforderungen, - Knowledge-Werkzeuge, - Datenqualität, - Organisation, - Change-Modell, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 7.2 Knowledge-Artikel, Runbooks und FAQ > **Kurz erklärt** > > Knowledge-Artikel, Runbooks und FAQ sind unterschiedliche Formen von dokumentiertem Wissen. > > **Knowledge-Artikel** helfen bei wiederkehrenden Fragen, Fehlerbildern, Workarounds oder Standardlösungen. > > **Runbooks** beschreiben konkrete betriebliche Abläufe Schritt für Schritt. > > **FAQ** beantworten häufige Fragen kurz und verständlich. > > Entscheidend ist, dass die Wissensform zur Zielgruppe, zum Risiko und zum Anwendungsfall passt. --- **Warum verschiedene Wissensformen wichtig sind** Nicht jedes Wissen sollte gleich dokumentiert werden. Ein Benutzer benötigt eine andere Anleitung als ein Administrator. Der Service Desk benötigt andere Informationen als ein Fachteam. Beispiele: - Benutzer braucht: „Wie richte ich MFA neu ein?“ - Service Desk braucht: „Welche Prüfschritte bei MFA-Problemen?“ - Fachteam braucht: „Wie wird der Identity-Dienst kontrolliert neu gestartet?“ - Management braucht: „Welche Auswirkungen hat der bekannte Fehler?“ - Security Team braucht: „Welche Meldewege gelten bei verdächtigen Anmeldungen?“ Wenn alle Informationen in einem einzigen langen Dokument stehen, wird Wissen schwer nutzbar. Besser ist eine passende Struktur nach Zweck und Zielgruppe. --- **Knowledge-Artikel** Ein Knowledge-Artikel beschreibt nutzbares Wissen zu einem konkreten Thema. Typische Inhalte: - Fehlerbild, - Ursache oder bekannte Ursache, - Lösung, - Workaround, - Prüfschritte, - Eskalationsweg, - Benutzeranleitung, - technische Hinweise, - bekannte Einschränkungen, - verwandte Artikel. Knowledge-Artikel können intern oder für Benutzer sichtbar sein. Wichtig ist, dass sie auffindbar, aktuell und verständlich sind. --- **Typische Knowledge-Artikel** | Artikeltyp | Beispiel | |---|---| | **Lösungsartikel** | VPN verbindet nach Ruhezustand nicht mehr | | **Workaround-Artikel** | PDF-Export schlägt fehl – alternative Ausgabe nutzen | | **Known-Error-Artikel** | Client-Version 5.8 verliert VPN-Tunnelzustand | | **Benutzerartikel** | Passwort über Self-Service zurücksetzen | | **Supportartikel** | Erstdiagnose bei DNS-Problemen | | **Technischer Artikel** | Zertifikat für Webservice prüfen | | **Sicherheitsartikel** | Verdächtige E-Mail melden | | **Serviceartikel** | Supportzeiten und Kontaktweg für Mitarbeiterportal | Der Artikeltyp sollte klar sein, damit Inhalt und Detailtiefe passen. --- **Runbooks** Ein Runbook ist eine konkrete Schritt-für-Schritt-Anleitung für wiederkehrende Betriebsaufgaben. Typische Runbooks: - Dienst kontrolliert neu starten, - Zertifikat erneuern, - Backup prüfen, - Restore testen, - Server nach Update prüfen, - Druckwarteschlange bereinigen, - Monitoringalarm bearbeiten, - Benutzergruppe nach Standardprozess anpassen, - Anwendung nach Deployment testen, - Notfallumschaltung durchführen. Runbooks sind besonders wichtig bei Aufgaben, die korrekt, sicher und wiederholbar ausgeführt werden müssen. --- **FAQ** FAQ bedeutet „Frequently Asked Questions“. Eine FAQ beantwortet häufige Fragen kurz und verständlich. Beispiele: - Wie ändere ich mein Passwort? - Warum muss ich MFA verwenden? - Wo finde ich das Serviceportal? - Wann ist der Service Desk erreichbar? - Was mache ich bei verlorenem Smartphone? - Wie beantrage ich Standardsoftware? - Warum ist ein Wartungsfenster notwendig? FAQ eignen sich besonders für Benutzerwissen. Sie ersetzen aber keine vollständigen Runbooks oder technischen Supportartikel. --- **Knowledge-Artikel, Runbook und FAQ unterscheiden** | Form | Zweck | Zielgruppe | Beispiel | |---|---|---|---| | **Knowledge-Artikel** | Wissen zu Fehler, Lösung oder Workaround bereitstellen | Benutzer, Service Desk, Fachteam | VPN-Fehler erkennen und lösen | | **Runbook** | betriebliche Aufgabe sicher ausführen | IT-Betrieb, Fachteam, Service Desk | Dienst kontrolliert neu starten | | **FAQ** | häufige Fragen kurz beantworten | Benutzer, Service Desk | Wie setze ich mein Passwort zurück? | Die Grenzen können sich überschneiden. Wichtig ist, dass der Inhalt im Alltag gut nutzbar ist. --- **Zielgruppe zuerst klären** Vor dem Schreiben muss klar sein: - Wer liest den Artikel? - Was möchte die Person erreichen? - Wie viel Vorwissen hat sie? - Welche Berechtigungen besitzt sie? - Darf sie die Schritte selbst ausführen? - Welche Risiken bestehen? - Wann muss eskaliert werden? - Welche Begriffe nutzt die Zielgruppe bei der Suche? Ein Benutzerartikel sollte anders geschrieben sein als ein internes Runbook. --- **Beispiel: Gleiches Thema, verschiedene Zielgruppen** Thema: > VPN verbindet nicht. **Benutzerartikel** - einfache Sprache, - wenige Schritte, - keine internen Details, - Hinweis, wann ein Ticket erstellt werden soll. **Service-Desk-Artikel** - Symptome, - Diagnosefragen, - Clientversion prüfen, - Workaround, - Eskalationskriterien. **Fachteam-Runbook** - technische Logs, - Gatewayprüfung, - Zertifikatsprüfung, - Konfigurationsprüfung, - Herstellerhinweise, - dauerhafte Maßnahmen. Ein Thema kann also mehrere Artikel benötigen. --- **Gute Titel** Der Titel entscheidet oft, ob ein Artikel gefunden wird. Ungeeignet: > Fehler 0x23A bei Authentifizierung Besser: > Anmeldung im Mitarbeiterportal schlägt fehl Ungeeignet: > Netzwerkproblem nach Standby Besser: > VPN verbindet nach Ruhezustand nicht mehr Ungeeignet: > Client Workaround Besser: > VPN-Client vollständig neu starten Ein guter Titel nutzt Begriffe, nach denen Zielgruppen tatsächlich suchen. --- **Suchbegriffe berücksichtigen** Artikel sollten typische Begriffe enthalten. Beispiele: - Fehlermeldung, - Symptom, - Service-Name, - Anwendung, - Benutzerbegriff, - technische Bezeichnung, - Abkürzung, - alternative Schreibweise. Beispiel: Ein Artikel zu Mehrfaktor-Authentifizierung sollte auch Begriffe enthalten wie: - MFA, - 2FA, - Authenticator-App, - neues Smartphone, - Anmeldung bestätigen. So wird der Artikel besser gefunden. --- **Struktur eines Knowledge-Artikels** Ein guter Knowledge-Artikel kann enthalten: - Titel, - Kurzbeschreibung, - Zielgruppe, - betroffener Service, - Symptome oder Anlass, - Voraussetzungen, - Lösung oder Workaround, - Schritt-für-Schritt-Anleitung, - erwartetes Ergebnis, - Risiken oder Einschränkungen, - Eskalationsweg, - verwandte Artikel, - Owner, - Review-Datum. Nicht jeder Artikel benötigt alle Punkte. Die Struktur sollte zum Zweck passen. --- **Beispielstruktur für Service-Desk-Artikel** | Abschnitt | Inhalt | |---|---| | **Titel** | VPN verbindet nach Ruhezustand nicht mehr | | **Kurzbeschreibung** | bekannter Fehler bei bestimmter Clientversion | | **Symptome** | Verbindung bricht nach Standby ab | | **Betroffen** | Windows-Notebooks mit Client-Version 5.8 | | **Prüfschritte** | Version prüfen, Fehlerbild abgleichen | | **Workaround** | Client vollständig beenden und neu starten | | **Eskalation** | bei anderer Version an Netzwerkteam | | **Verknüpfung** | Known Error, Problem Record, Change | | **Review** | nach Rollout neuer Clientversion prüfen | Diese Struktur hilft, Fälle schnell und einheitlich zu bearbeiten. --- **Struktur eines Runbooks** Ein Runbook sollte besonders genau sein. Mögliche Struktur: - Zweck, - betroffener Service, - Zielgruppe, - Voraussetzungen, - benötigte Berechtigungen, - benötigte Werkzeuge, - Risiken, - Vorbereitung, - genaue Schritte, - Prüfpunkte, - erwartetes Ergebnis, - Abbruchkriterien, - Rollback oder Rückweg, - Eskalationsweg, - Dokumentation nach Durchführung, - Owner, - Review-Datum. Bei kritischen Aufgaben sind Abbruchkriterien und Rollback besonders wichtig. --- **Beispielstruktur für Runbook** | Abschnitt | Inhalt | |---|---| | **Zweck** | Dienst kontrolliert neu starten | | **Voraussetzungen** | Wartungsfenster oder Freigabe vorhanden | | **Risiko** | Benutzer können kurzzeitig nicht arbeiten | | **Vorbereitung** | Monitoring prüfen, aktuelle Sessions prüfen | | **Schritte** | Dienst stoppen, Status prüfen, Dienst starten | | **Prüfung** | Anmeldung, Logs, Monitoring | | **Abbruchkriterium** | Dienst startet nicht innerhalb definierter Zeit | | **Rollback** | vorherige Konfiguration wiederherstellen | | **Eskalation** | Fachteam oder Bereitschaft informieren | Runbooks sollten so geschrieben sein, dass sie auch unter Zeitdruck verständlich bleiben. --- **Struktur einer FAQ** Eine FAQ sollte kurz und direkt sein. Mögliche Struktur: - Frage, - kurze Antwort, - einfache Schritte, - Link zu ausführlicher Anleitung, - Hinweis auf Supportweg. Beispiel: **Frage** > Wie setze ich mein Passwort zurück? **Antwort** > Nutzen Sie den Self-Service-Passwort-Reset im Serviceportal. Halten Sie Ihre zweite Anmeldemethode bereit. Wenn Sie keinen Zugriff mehr auf MFA haben, erstellen Sie ein Ticket an den Service Desk. FAQ sollten nicht zu langen Handbüchern werden. --- **Benutzerartikel schreiben** Benutzerartikel sollten: - einfache Sprache nutzen, - kurze Schritte enthalten, - Fachbegriffe vermeiden oder erklären, - keine internen Systeme unnötig nennen, - keine vertraulichen Informationen enthalten, - klare Screenshots nutzen, falls sinnvoll, - erwartetes Ergebnis beschreiben, - Supportweg nennen. Ungeeignet: > Prüfen Sie, ob Ihr Identity Provider den Token korrekt verarbeitet. Besser: > Öffnen Sie die Authenticator-App und bestätigen Sie die Anmeldung erneut. --- **Interne Supportartikel schreiben** Interne Supportartikel dürfen technischer sein. Sie sollten enthalten: - Fehlerbild, - betroffene Services, - betroffene Versionen, - typische Ursachen, - Prüfschritte, - Workaround, - Risiken, - Eskalationskriterien, - Verknüpfung zu CI, Problem oder Known Error, - Hinweise zur Dokumentation im Ticket. Service-Desk-Artikel sollten schnell nutzbar sein. Sie sollten keine unnötig langen Hintergrundtexte enthalten. --- **Technische Fachartikel schreiben** Technische Fachartikel können detaillierter sein. Geeignet sind: - Logpfade, - Konfigurationsparameter, - Architekturhinweise, - Schnittstellen, - Abhängigkeiten, - Datenbankdetails, - Versionshinweise, - Fehleranalysen, - Herstellerinformationen, - Risiken und Nebenwirkungen. Wichtig: Technische Fachartikel sollten trotzdem strukturiert und überprüfbar sein. Ein unstrukturierter Expertennotizzettel hilft nur begrenzt. --- **Runbooks und Sicherheit** Runbooks können sicherheitskritische Schritte enthalten. Beispiele: - Administratorrechte verwenden, - Firewall-Regel ändern, - Zertifikat austauschen, - Datenbank wiederherstellen, - Benutzerrechte ändern, - Dienst mit erhöhten Rechten starten, - Sicherheitsalarm bearbeiten. Dann müssen enthalten sein: - Berechtigungsanforderungen, - Freigabeanforderungen, - Risiken, - Abbruchkriterien, - Protokollierung, - Eskalation, - und Zugriffsschutz des Artikels. Nicht jedes Runbook darf für alle sichtbar sein. --- **Screenshots verwenden** Screenshots können helfen, wenn Benutzer eine Oberfläche bedienen müssen. Vorteile: - Schritte werden verständlicher, - Menüpfade sind leichter erkennbar, - Benutzer machen weniger Fehler. Risiken: - Screenshots veralten schnell, - sensible Daten können sichtbar sein, - Oberfläche kann je nach Version abweichen, - Artikel wird schwerer zu pflegen. Screenshots sollten regelmäßig geprüft und bei Changes aktualisiert werden. --- **Tabellen verwenden** Tabellen eignen sich gut für Varianten. Beispiel: | Situation | Vorgehen | |---|---| | Benutzer kennt Passwort | Passwort über Portal ändern | | Benutzer kennt Passwort nicht | Self-Service-Reset nutzen | | Benutzer hat neues Smartphone | MFA-Methode neu registrieren | | Benutzer hat keinen MFA-Zugriff | Ticket an Service Desk erstellen | Tabellen helfen, Entscheidungen schnell sichtbar zu machen. --- **Checklisten verwenden** Checklisten sind sinnvoll für wiederkehrende Prüfungen. Beispiele: - Server nach Update prüfen, - Backupjob kontrollieren, - Change vorbereiten, - Zertifikat erneuern, - neuen Arbeitsplatz bereitstellen, - Incident eskalieren. Eine gute Checkliste ist kurz, eindeutig und vollständig genug. Sie sollte keine wichtigen Entscheidungen verstecken. --- **Entscheidungsbäume verwenden** Entscheidungsbäume helfen bei Diagnose. Beispiel: Benutzer kann sich nicht anmelden ↓ Passwort bekannt? ↓ ja → MFA prüfen ↓ nein → Self-Service-Reset prüfen ↓ kein MFA-Zugriff → Service Desk Ticket ↓ Konto gesperrt → Entsperrprozess prüfen Entscheidungsbäume sollten nicht zu komplex werden. Bei zu vielen Verzweigungen ist eine Tabelle oft besser. --- **Artikel mit Services und CIs verknüpfen** Knowledge-Artikel sollten mit relevanten Services oder Configuration Items verknüpft werden. Vorteile: - Artikel werden im Incident schneller vorgeschlagen, - betroffene Versionen sind erkennbar, - Known Errors werden leichter gefunden, - Service Desk sieht passende Runbooks, - Changes können betroffene Artikel prüfen, - veraltete Artikel fallen eher auf. Beispiel: Ein VPN-Artikel wird verknüpft mit: - VPN-Service, - VPN-Client-Version, - VPN-Gateway, - Identity Provider, - Known Error, - Problem Record. --- **Artikel mit Incidents verknüpfen** Wenn ein Artikel zur Lösung eines Incidents genutzt wurde, sollte er im Ticket verknüpft werden. Nutzen: - häufig genutzte Artikel werden sichtbar, - Artikelqualität kann bewertet werden, - wiederkehrende Fehler werden erkennbar, - Service Desk arbeitet einheitlicher, - Problem Management erkennt Muster. Wenn viele Tickets trotz Artikel entstehen, sollte geprüft werden, ob der Artikel unklar, nicht auffindbar oder technisch unzureichend ist. --- **Artikel mit Problems und Known Errors verknüpfen** Bei bekannten Fehlern ist die Verknüpfung besonders wichtig. Ein Known-Error-Artikel sollte enthalten: - Fehlerbild, - betroffene Versionen, - Ursache oder wahrscheinliche Ursache, - Workaround, - dauerhafte Lösung, - Status, - Eskalationskriterien, - Problem Record, - geplanter Change. Dadurch können zukünftige Incidents schneller bearbeitet werden. --- **Artikel mit Changes und Releases verknüpfen** Changes und Releases können Knowledge-Artikel verändern. Beispiele: - Menüpfad ändert sich, - neue Version hat anderes Fehlerbild, - Workaround ist nicht mehr gültig, - Known Error wird behoben, - neuer Service wird eingeführt, - Supportweg ändert sich, - Screenshots werden veraltet. Deshalb sollte bei Change- und Release-Abschluss geprüft werden: > Welche Knowledge-Artikel müssen aktualisiert werden? --- **Versionierung von Artikeln** Bei wichtigen Artikeln kann Versionierung sinnvoll sein. Zu dokumentieren ist: - Erstellungsdatum, - letzte Änderung, - Autor oder Owner, - fachliche Prüfung, - gültige Serviceversion, - Änderungsgrund, - Review-Datum. Versionierung hilft bei Nachvollziehbarkeit. Besonders wichtig ist sie bei sicherheitskritischen Runbooks, Workarounds und Betriebsanleitungen. --- **Review und Ablaufdatum** Artikel sollten regelmäßig geprüft werden. Besonders wichtig bei: - Workarounds, - Known Errors, - Runbooks, - Sicherheitsartikeln, - Benutzerartikeln mit Screenshots, - Artikeln zu kritischen Services, - Artikeln zu Lieferantenprodukten. Ein Ablaufdatum oder Review-Datum verhindert, dass veraltetes Wissen dauerhaft als aktuelle Lösung erscheint. --- **Owner für Artikel** Jeder wichtige Artikel sollte einen Owner besitzen. Der Owner ist verantwortlich für: - fachliche Korrektheit, - Aktualität, - Review, - Feedbackbewertung, - Freigabe von Änderungen, - Archivierung, - und Verknüpfung mit Services oder CIs. Ohne Owner bleibt unklar, wer einen Artikel korrigieren darf oder muss. --- **Freigabe von Artikeln** Nicht jeder Artikel benötigt dieselbe Freigabe. Beispiele: | Artikel | mögliche Freigabe | |---|---| | einfache FAQ | Service Desk oder Knowledge Owner | | Benutzeranleitung | Service Owner oder Kommunikation | | technisches Runbook | Fachteam | | Sicherheitsartikel | Information Security | | Workaround mit Risiko | Fachteam und Service Owner | | Known Error | Problem Management oder Fachteam | Die Freigabe sollte zum Risiko passen. Zu viel Freigabeaufwand verhindert schnelle Wissensnutzung. --- **Zugriffsschutz** Artikel können unterschiedliche Sichtbarkeit haben. Beispiele: - öffentlich für alle Benutzer, - intern für Service Desk, - nur Fachteam, - nur Management, - nur Security, - vertraulich wegen Sicherheitsdetails. Zu prüfen ist: - enthält der Artikel interne Systeme? - enthält er Sicherheitsinformationen? - enthält er Administratorbefehle? - enthält er personenbezogene Daten? - enthält er Lieferanteninformationen? - darf ein Benutzer diese Schritte selbst ausführen? Falsche Sichtbarkeit kann Sicherheits- oder Datenschutzrisiken erzeugen. --- **Qualität eines Artikels prüfen** Ein Artikel ist gut, wenn: - Zielgruppe klar ist, - Zweck klar ist, - Titel suchbar ist, - Schritte verständlich sind, - Inhalt fachlich stimmt, - Risiken genannt werden, - Eskalation klar ist, - Ergebnis prüfbar ist, - Owner vorhanden ist, - Review-Datum vorhanden ist, - Artikel mit Service oder CI verknüpft ist. Ein Artikel ist nicht gut, nur weil er lang ist. --- **Häufige Qualitätsprobleme** | Problem | Folge | |---|---| | Titel unklar | Artikel wird nicht gefunden | | zu technisch | Benutzer verstehen ihn nicht | | zu allgemein | Service Desk kann ihn nicht anwenden | | kein Owner | Artikel veraltet | | kein Review | Aktualität unklar | | keine Eskalation | falsche Bearbeitung | | keine Risiken | unsichere Anwendung | | keine Servicezuordnung | Artikel wird nicht im richtigen Kontext gefunden | | veraltete Screenshots | Benutzer folgen falschen Schritten | --- **Kurzartikel und Tiefendokumentation kombinieren** Manche Themen brauchen zwei Ebenen. **Kurzartikel** - Symptome, - schnelle Lösung, - Workaround, - Eskalationsweg. **Tiefendokumentation** - technische Ursache, - Architektur, - Konfiguration, - Logs, - Hintergrund, - dauerhafte Lösung. Der Kurzartikel verweist auf die Tiefendokumentation. So bleibt der Artikel im Support schnell nutzbar, ohne Fachdetails zu verlieren. --- **Beispiel: Benutzerartikel MFA** **Titel** MFA auf einem neuen Smartphone einrichten **Zielgruppe** Benutzer **Inhalt** - wann der Artikel gilt, - was vorbereitet werden muss, - Schritt-für-Schritt-Anleitung, - erwartetes Ergebnis, - was bei fehlendem Zugriff zu tun ist, - Link zum Service Desk. **Nicht enthalten** - interne Administrationsschritte, - Sicherheitskonfiguration, - technische Token-Details. --- **Beispiel: Service-Desk-Artikel VPN** **Titel** VPN verbindet nach Ruhezustand nicht mehr **Zielgruppe** Service Desk **Inhalt** - Fehlerbild, - betroffene Clientversion, - Prüfschritte, - Workaround, - Ticketdokumentation, - Eskalation an Netzwerkteam, - Link zum Known Error. **Nutzen** Der Service Desk erkennt den bekannten Fall schneller und handelt einheitlich. --- **Beispiel: Runbook Zertifikat erneuern** **Titel** Runbook: TLS-Zertifikat für Mitarbeiterportal erneuern **Zielgruppe** Plattform-Team **Inhalt** - Voraussetzungen, - Freigabe, - Backup der alten Konfiguration, - Zertifikatsanforderung, - Installation, - Dienstneustart, - Funktionstest, - Monitoringprüfung, - Rollback, - Dokumentation, - CMDB-Aktualisierung. **Besonderheit** Dieses Runbook ist sicherheits- und servicekritisch und benötigt fachliche Prüfung. --- **Beispiel: FAQ Passwort** **Frage** Wie setze ich mein Passwort zurück? **Antwort** Nutzen Sie den Self-Service-Passwort-Reset im Serviceportal. Wenn Sie keinen Zugriff auf Ihre zweite Anmeldemethode haben, erstellen Sie ein Ticket an den Service Desk. **Link** Ausführliche Anleitung: Passwort und MFA verwalten --- **Typische Fehler** **Fehler 1** Alle Informationen werden in einen einzigen langen Artikel geschrieben. --- **Fehler 2** Zielgruppe ist nicht klar. --- **Fehler 3** Benutzerartikel enthalten interne technische Details. --- **Fehler 4** Runbooks enthalten keine Abbruchkriterien. --- **Fehler 5** Workarounds enthalten keine Risiken. --- **Fehler 6** Titel orientieren sich an Technik statt an Suchbegriffen der Zielgruppe. --- **Fehler 7** Artikel haben keinen Owner. --- **Fehler 8** Review-Datum fehlt. --- **Fehler 9** Screenshots werden nach Releases nicht aktualisiert. --- **Fehler 10** Knowledge-Artikel sind nicht mit Services, CIs, Incidents oder Problems verknüpft. --- **Fehler 11** Veraltete Artikel bleiben sichtbar. --- **Fehler 12** FAQ wird als Ersatz für vollständige Supportartikel verwendet. --- **Checkliste Knowledge-Artikel** - [ ] Zielgruppe festgelegt - [ ] Titel ist suchbar - [ ] betroffener Service genannt - [ ] Symptome oder Anlass beschrieben - [ ] Voraussetzungen genannt - [ ] Lösung oder Workaround beschrieben - [ ] Schritte verständlich formuliert - [ ] erwartetes Ergebnis genannt - [ ] Risiken oder Einschränkungen genannt - [ ] Eskalationsweg beschrieben - [ ] verwandte Artikel verknüpft - [ ] Owner eingetragen - [ ] Review-Datum gesetzt --- **Checkliste Runbook** - [ ] Zweck beschrieben - [ ] Zielgruppe festgelegt - [ ] betroffener Service genannt - [ ] Voraussetzungen geprüft - [ ] benötigte Berechtigungen genannt - [ ] Risiken beschrieben - [ ] Vorbereitungsschritte genannt - [ ] Durchführungsschritte eindeutig - [ ] Prüfpunkte enthalten - [ ] erwartetes Ergebnis beschrieben - [ ] Abbruchkriterien definiert - [ ] Rollback oder Rückweg beschrieben - [ ] Eskalationsweg genannt - [ ] Dokumentation nach Durchführung beschrieben - [ ] Owner und Review-Datum vorhanden --- **Checkliste FAQ** - [ ] häufige Frage klar formuliert - [ ] kurze Antwort vorhanden - [ ] einfache Sprache verwendet - [ ] keine unnötigen internen Begriffe - [ ] Link zu ausführlicher Anleitung vorhanden, falls nötig - [ ] Supportweg genannt - [ ] Zielgruppe eindeutig - [ ] Artikel aktuell - [ ] Owner vorhanden - [ ] Review-Datum gesetzt --- **Checkliste Artikelqualität** - [ ] fachlich korrekt - [ ] aktuell - [ ] verständlich - [ ] nicht unnötig lang - [ ] für Zielgruppe geeignet - [ ] über Suche auffindbar - [ ] mit Service oder CI verknüpft - [ ] Zugriffsschutz passend - [ ] keine sensiblen Informationen falsch sichtbar - [ ] Feedbackmöglichkeit vorhanden - [ ] Nutzung wird ausgewertet - [ ] veraltete Inhalte werden archiviert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker erstellen und nutzen viele Wissensformen. Im Alltag bedeutet das: - technische Lösungen als Knowledge-Artikel dokumentieren, - wiederkehrende Betriebsaufgaben als Runbook beschreiben, - Service Desk mit klaren Prüfschritten unterstützen, - Benutzeranleitungen verständlich halten, - Workarounds mit Risiken und Eskalation dokumentieren, - Artikel nach Changes aktualisieren, - veraltete Inhalte melden, - und Wissen mit Services, CIs und Problems verknüpfen. Gute Wissensdokumentation macht Betrieb weniger abhängig von Einzelpersonen und verbessert die Qualität im Support. --- **Zusammenfassung** > Wissensbedarf erkennen > ↓ > Zielgruppe bestimmen > ↓ > passende Wissensform wählen > ↓ > Knowledge-Artikel, Runbook oder FAQ erstellen > ↓ > Inhalt fachlich prüfen > ↓ > Service, CI oder Problem verknüpfen > ↓ > Artikel veröffentlichen > ↓ > Nutzung und Feedback auswerten > ↓ > Artikel aktualisieren oder archivieren --- **Merksätze** > Die Form des Wissens muss zum Zweck passen. > Benutzerartikel, Supportartikel und Runbooks brauchen unterschiedliche Detailtiefe. > Ein guter Titel entscheidet oft, ob Wissen gefunden wird. > Runbooks benötigen klare Schritte, Prüfpunkte und Abbruchkriterien. > FAQ beantworten häufige Fragen, ersetzen aber keine vollständige Betriebsdokumentation. > Jeder wichtige Artikel braucht Owner, Review und passende Sichtbarkeit. > Wissen ist nur nützlich, wenn es gefunden, verstanden und gepflegt wird. --- **Verwandte Seiten** - 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen - 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk - 7.4 Self-Service und Benutzerwissen - 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change - Incident Management - Problem Management - Change Enablement - Release Management - Service Configuration Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Service Desk - ITIL Foundation – Version 5 **Ergänzende Praxiseinordnung** - Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support **Einordnung** Die dargestellten: - Artikelstrukturen, - Runbook-Strukturen, - FAQ-Beispiele, - Checklisten, - Qualitätskriterien, - Freigabehinweise, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Knowledge-Artikel-Vorlage, - Runbook-Vorlage, - FAQ-Struktur, - Freigabematrix, - Review-Frequenz, - oder Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Zielgruppen, - Supportmodell, - Risiken, - Sicherheitsanforderungen, - Knowledge-Werkzeuge, - Service Configuration Management, - Change-Modell, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk > **Kurz erklärt** > > Known Errors und Workarounds sind besonders wichtig für den Service Desk. > > Sie helfen dabei, bekannte Fehlerbilder schneller zu erkennen, Benutzer schneller wieder arbeitsfähig zu machen und wiederkehrende Incidents einheitlich zu bearbeiten. > > Entscheidend ist, dass dieses Wissen verständlich dokumentiert, leicht auffindbar, aktuell und mit Incident-, Problem- und Knowledge Management verknüpft ist. --- **Warum Known Errors und Workarounds im Service Desk wichtig sind** Der Service Desk ist häufig die erste Stelle, die wiederkehrende Fehler bemerkt. Beispiele: - mehrere Benutzer melden denselben VPN-Fehler, - eine Anwendung zeigt nach einem Update immer dieselbe Fehlermeldung, - ein Druckertreiber verursacht wiederkehrende Probleme, - ein Zertifikat läuft ab, - ein Workaround wird regelmäßig angewendet, - ein bekannter Fehler tritt nach bestimmten Bedingungen auf. Ohne dokumentiertes Wissen muss der Service Desk jeden Fall neu analysieren. Mit gut gepflegten Known Errors und Workarounds kann er schneller reagieren. --- **Known Error** Ein **Known Error** ist ein bekannter Fehlerzustand oder ein bekanntes Problem, bei dem Ursache, wahrscheinliche Ursache oder Fehlerbild ausreichend verstanden sind. Ein Known Error kann enthalten: - bekanntes Symptom, - betroffener Service, - betroffene Version, - Ursache oder wahrscheinliche Ursache, - Workaround, - dauerhafte Lösung, - Status, - Risiko, - Eskalationsweg, - Verknüpfung zu Problem Record, - Verknüpfung zu Knowledge-Artikel. Ein Known Error muss nicht bedeuten, dass die endgültige Lösung bereits umgesetzt wurde. --- **Workaround** Ein **Workaround** ist eine vorübergehende Möglichkeit, die Auswirkungen eines Incidents oder Problems zu umgehen oder zu reduzieren. Beispiele: - VPN-Client vollständig neu starten, - alternative Webversion nutzen, - Druckauftrag über anderen Drucker ausgeben, - Dienst kontrolliert neu starten, - temporäre Bereinigung nach Runbook durchführen, - anderes Anmeldeverfahren verwenden, - bekannte fehlerhafte Funktion vorübergehend vermeiden. Ein Workaround ist hilfreich, aber nicht automatisch eine dauerhafte Lösung. --- **Known Error und Workaround unterscheiden** | Begriff | Bedeutung | Beispiel | |---|---|---| | **Known Error** | bekannter Fehlerzustand oder bekanntes Problem | VPN-Client-Version 5.8 verliert nach Ruhezustand Verbindung | | **Workaround** | vorübergehende Maßnahme zur Umgehung | VPN-Client vollständig beenden und neu starten | | **dauerhafte Lösung** | beseitigt Ursache oder reduziert Risiko dauerhaft | neue VPN-Client-Version ausrollen | | **Knowledge-Artikel** | nutzbare Dokumentation für Zielgruppe | Service-Desk-Artikel mit Symptomen und Prüfschritten | --- **Warum Workarounds dokumentiert werden müssen** Ein Workaround, der nur einzelnen Personen bekannt ist, hilft nicht zuverlässig. Typische Folgen fehlender Dokumentation: - Service Desk arbeitet uneinheitlich, - Benutzer erhalten unterschiedliche Antworten, - Incidents dauern länger, - gleiche Analyse wird mehrfach durchgeführt, - Risiken werden übersehen, - Eskalationen erfolgen zu spät, - Problem Management erkennt Muster schlechter, - neue Mitarbeitende müssen Wissen mündlich erfragen. Ein guter Workaround muss für die richtige Zielgruppe auffindbar und verständlich sein. --- **Ein Workaround ist keine endgültige Lösung** Ein häufiger Fehler ist, einen Workaround als Lösung zu behandeln. Beispiel: Ein Dienst stürzt regelmäßig ab. Der Service Desk startet den Dienst jedes Mal neu. Dadurch funktioniert der Service kurzfristig wieder. Die eigentliche Ursache bleibt aber bestehen. Offene Fragen: - Warum stürzt der Dienst ab? - Warum erkennt Monitoring den Fehler nicht früher? - Warum ist kein automatischer Neustart vorgesehen? - Warum tritt der Fehler regelmäßig auf? - Gibt es ein Problem Record? - Gibt es eine geplante dauerhafte Lösung? > **Merke** > > Ein Workaround kann einen Incident abschließen. > > Das zugrunde liegende Problem kann trotzdem offen bleiben. --- **Wissensnutzung im Service Desk** Der Service Desk sollte Knowledge aktiv nutzen. Beispiele: - bei Ticketerstellung nach passenden Artikeln suchen, - bekannte Symptome mit Known Errors vergleichen, - Workaround nach geprüfter Anleitung anwenden, - Ticket mit Knowledge-Artikel verknüpfen, - fehlende oder falsche Artikel melden, - wiederkehrende Incidents an Problem Management geben, - Benutzer mit freigegebenen Informationen versorgen. Knowledge Management ist nur wirksam, wenn das Wissen im Alltag verwendet wird. --- **Service-Desk-Artikel zu Known Errors** Ein guter Service-Desk-Artikel zu einem Known Error enthält: - eindeutigen Titel, - betroffenen Service, - bekannte Symptome, - betroffene Versionen oder Komponenten, - Prüfschritte, - Workaround, - Risiken und Einschränkungen, - wann der Artikel nicht gilt, - Eskalationskriterien, - Verknüpfung zum Problem Record, - geplante dauerhafte Lösung, - Review-Datum, - Owner. Der Artikel muss so geschrieben sein, dass der Service Desk ihn unter Zeitdruck nutzen kann. --- **Beispielstruktur für einen Known-Error-Artikel** | Abschnitt | Inhalt | |---|---| | **Titel** | VPN verbindet nach Ruhezustand nicht mehr | | **Betroffener Service** | VPN-Zugang | | **Symptom** | Verbindung bricht nach Standby ab | | **Betroffen** | Windows-Notebooks mit Client-Version 5.8 | | **Prüfung** | Clientversion und Fehlerbild abgleichen | | **Workaround** | VPN-Client vollständig beenden und neu starten | | **Eskalation** | bei anderer Version an Netzwerkteam | | **Problem Record** | verknüpft | | **Dauerhafte Lösung** | Rollout Version 5.9 geplant | | **Review** | nach Rollout prüfen | --- **Titel und Suchbegriffe** Known-Error-Artikel müssen über typische Suchbegriffe gefunden werden. Ungeeignet: > Fehlercode 0x802-VPN-Tunnelstate Besser: > VPN verbindet nach Ruhezustand nicht mehr Ungeeignet: > Problem mit Auth-Komponente Besser: > Anmeldung im Mitarbeiterportal schlägt fehl Ein guter Titel nutzt die Sprache, die im Ticket oder im Benutzerkontakt tatsächlich vorkommt. --- **Symptome klar beschreiben** Der Service Desk muss schnell erkennen können, ob ein neuer Incident zum Known Error passt. Gute Symptombeschreibungen enthalten: - sichtbare Fehlermeldung, - Zeitpunkt oder Auslöser, - betroffene Anwendung, - betroffene Version, - betroffene Benutzergruppe, - betroffene Umgebung, - typische Begleitumstände, - bekannte Ausschlusskriterien. Beispiel: > Fehler tritt nur nach Ruhezustand auf Windows-Notebooks mit VPN-Client-Version 5.8 auf. Wenn der Fehler direkt nach Neustart oder bei anderer Version auftritt, gilt dieser Known Error nicht automatisch. --- **Prüfschritte** Prüfschritte helfen, den Known Error sicher zu erkennen. Beispiele: - Service prüfen, - Version prüfen, - Benutzergruppe prüfen, - Fehlermeldung vergleichen, - Zeitpunkt prüfen, - letzte Changes prüfen, - Known-Error-Status prüfen, - Monitoring prüfen, - Ticketverlauf prüfen. Prüfschritte sollten kurz, eindeutig und reproduzierbar sein. Ungeeignet: > Prüfen, ob es das bekannte Problem ist. Besser: > VPN-Client-Version prüfen. Gilt nur für Version 5.8. Fehler tritt nach Ruhezustand auf. Wenn Version abweicht, an Netzwerkteam eskalieren. --- **Workaround-Schritte** Ein Workaround muss so beschrieben sein, dass er sicher ausgeführt werden kann. Er sollte enthalten: - genaue Schritte, - Voraussetzungen, - erwartetes Ergebnis, - Risiken, - Einschränkungen, - Abbruchkriterien, - Eskalation bei Fehlschlag, - Hinweis zur Dokumentation im Ticket. Ungeeignet: > Client neu starten. Besser: > VPN-Client vollständig beenden, prüfen ob kein VPN-Prozess mehr läuft, Client erneut starten und Verbindung testen. Wenn Verbindung weiterhin fehlschlägt, Ticket an Netzwerkteam eskalieren. --- **Wann der Workaround nicht angewendet werden darf** Ein guter Artikel beschreibt auch Grenzen. Beispiele: - gilt nur für bestimmte Version, - gilt nicht bei Sicherheitsvorfall, - gilt nicht bei Datenverlust, - gilt nicht bei produktivem Datenbankfehler, - gilt nicht außerhalb eines genehmigten Wartungsfensters, - gilt nicht ohne Freigabe, - gilt nicht bei kritischen Services ohne Eskalation. Diese Grenzen verhindern, dass ein Workaround falsch oder riskant angewendet wird. --- **Risiken eines Workarounds** Workarounds können Risiken haben. Beispiele: - Datenverlust, - Sicherheitsrisiko, - Unterbrechung für andere Benutzer, - falsche Berechtigungen, - Folgefehler, - manuelle Fehler, - unvollständige Wiederherstellung, - Verstoß gegen Vorgaben, - verdeckte Ursache bleibt bestehen. Deshalb sollten Risiken im Artikel genannt werden. Ein Workaround ohne Risikohinweis kann zu falscher Anwendung führen. --- **Eskalationskriterien** Ein Service-Desk-Artikel sollte klar sagen, wann eskaliert werden muss. Beispiele: - Workaround schlägt fehl, - Fehlerbild passt nicht vollständig, - anderer Service ist betroffen, - mehrere Benutzer oder Standort betroffen, - Sicherheitsbezug möglich, - kritischer Service betroffen, - Datenverlust möglich, - gleiche Störung wiederholt sich häufig, - Benutzer hat Sonderrolle, - bekannte Version stimmt nicht. Eskalationskriterien verhindern unnötige Verzögerungen. --- **Ticketdokumentation** Wenn ein Known Error oder Workaround genutzt wurde, sollte das Ticket sauber dokumentiert werden. Wichtige Angaben: - welcher Knowledge-Artikel genutzt wurde, - welcher Known Error vermutet oder bestätigt wurde, - welche Prüfschritte durchgeführt wurden, - ob der Workaround funktioniert hat, - welche Version betroffen war, - ob eskaliert wurde, - ob Benutzer informiert wurde, - ob Folgeproblem erkennbar ist. Gute Ticketdokumentation unterstützt Trendanalyse und Problem Management. --- **Verknüpfung mit Problem Management** Known Errors entstehen oft aus Problem Management. Problem Management liefert: - Ursache oder wahrscheinliche Ursache, - beitragende Faktoren, - bekannte Symptome, - Workaround, - dauerhafte Lösung, - Risiko, - Status, - geplante Changes. Der Service Desk nutzt dieses Wissen im Incident Management. Neue Incidents liefern wiederum Informationen zurück an Problem Management. --- **Wann der Service Desk Problem Management informieren sollte** Problem Management sollte informiert werden, wenn: - ein Workaround sehr häufig genutzt wird, - ein Known Error häufiger auftritt als erwartet, - neue Symptome auftreten, - ein bekannter Workaround nicht mehr funktioniert, - ein neuer wiederkehrender Fehler sichtbar wird, - ein Major Incident droht, - viele Benutzer betroffen sind, - Service Desk auffällige Trends erkennt. Der Service Desk ist eine wichtige Frühwarnquelle. --- **Verknüpfung mit Change Enablement** Eine dauerhafte Lösung für einen Known Error benötigt häufig einen Change. Beispiele: - Softwareupdate, - Konfigurationsänderung, - Treiberupdate, - Zertifikatserneuerung, - Firewall-Anpassung, - Monitoring-Erweiterung, - Berechtigungsänderung, - Austausch einer Komponente. Der Knowledge-Artikel sollte zeigen: - ob ein Change geplant ist, - wann eine dauerhafte Lösung erwartet wird, - ob der Workaround bis dahin gilt, - wann der Artikel überprüft werden muss. --- **Verknüpfung mit Release Management** Nach einem Release kann sich der Status eines Known Errors ändern. Beispiele: - Known Error wurde behoben, - Workaround ist nicht mehr gültig, - neue Version hat anderes Fehlerbild, - Artikel benötigt neue Screenshots, - Service Desk braucht neue Prüfschritte, - Benutzerinformation muss angepasst werden. Nach Releases sollten relevante Knowledge-Artikel geprüft werden. --- **Verknüpfung mit Service Configuration Management** Known Errors und Workarounds sollten mit Services und CIs verknüpft werden. Beispiele: - Service: VPN-Zugang, - CI: VPN-Client-Version 5.8, - CI: VPN-Gateway, - CI: Identity Provider, - CI: Zertifikat, - Problem Record, - Change Record. Vorteile: - Artikel werden im Ticket besser vorgeschlagen, - betroffene Versionen sind erkennbar, - Trendanalyse wird besser, - Changes können Artikel gezielt aktualisieren, - Service Desk findet schneller passende Informationen. --- **Benutzerkommunikation bei Known Errors** Benutzer sollten verständlich informiert werden. Gute Kommunikation enthält: - was betroffen ist, - welche Zwischenlösung verfügbar ist, - was Benutzer tun sollen, - welche Einschränkung besteht, - ob an einer dauerhaften Lösung gearbeitet wird, - wo weitere Informationen stehen. Ungeeignet: > Das ist ein bekannter Bug, einfach neu starten. Besser: > Für dieses VPN-Problem gibt es aktuell eine sichere Zwischenlösung. Bitte schließen Sie den VPN-Client vollständig und starten Sie ihn erneut. Die Ursache ist bekannt, eine dauerhafte Korrektur wird vorbereitet. --- **Interne und externe Artikel trennen** Ein Known Error kann verschiedene Artikel benötigen. **Benutzerartikel** - einfache Erklärung, - sichere Handlung, - Supportweg, - keine internen Details. **Service-Desk-Artikel** - Symptome, - Prüfschritte, - Workaround, - Eskalation, - Ticketdokumentation. **Fachteam-Artikel** - technische Ursache, - Logs, - Konfiguration, - dauerhafte Lösung, - Change-Planung. Nicht jedes Detail gehört in jeden Artikel. --- **Known Error ohne Workaround** Nicht jeder Known Error besitzt einen sicheren Workaround. Beispiele: - Zertifikat ist abgelaufen, - Datenbank ist beschädigt, - Sicherheitslücke wird aktiv ausgenutzt, - zentraler Dienst ist ausgefallen, - Datenverlust droht. Dann muss der Artikel klar sagen: - kein Workaround verfügbar, - sofort eskalieren, - Benutzer nicht zu unsicheren Ersatzwegen anleiten, - Statuskommunikation nutzen, - Problem oder Major Incident prüfen. Ein fehlender Workaround sollte ausdrücklich dokumentiert werden. --- **Known Error mit Risikoakzeptanz** Manche Known Errors bleiben längere Zeit offen. Gründe: - dauerhafte Lösung ist teuer, - Herstellerkorrektur steht aus, - Änderung ist riskant, - Workaround funktioniert ausreichend, - Service wird bald abgelöst, - Risiko wurde bewusst akzeptiert. Dann sollte dokumentiert werden: - wer das Risiko akzeptiert hat, - wie lange die Akzeptanz gilt, - welcher Workaround erlaubt ist, - wann neu bewertet wird, - welche Einschränkungen bestehen. --- **Knowledge-Artikel im Ticket vorschlagen** Viele ITSM-Systeme können Artikel im Ticket vorschlagen. Grundlagen dafür: - guter Titel, - passende Suchbegriffe, - Servicebezug, - Kategorie, - CI-Verknüpfung, - Known-Error-Verknüpfung, - klare Symptome, - aktuelle Inhalte. Automatische Vorschläge helfen nur, wenn die Artikelqualität gut ist. Schlechte Vorschläge führen dazu, dass Mitarbeitende die Funktion ignorieren. --- **Nutzung messen** Die Nutzung von Known-Error- und Workaround-Artikeln sollte ausgewertet werden. Mögliche Fragen: - Welche Artikel werden häufig genutzt? - Welche Workarounds werden besonders oft angewendet? - Welche Artikel lösen Incidents erfolgreich? - Wo brechen Mitarbeitende ab? - Welche Artikel werden schlecht bewertet? - Welche Suchanfragen führen zu keinem Treffer? - Welche Known Errors erzeugen weiterhin viele Tickets? Diese Daten helfen, Wissen und Problems gezielt zu verbessern. --- **Artikelqualität aus Service-Desk-Sicht** Ein Service-Desk-Artikel ist gut, wenn er: - schnell auffindbar ist, - klare Symptome nennt, - Prüfschritte enthält, - Workaround sicher beschreibt, - Eskalationsregeln nennt, - keine unnötige Fachsprache nutzt, - Risiken sichtbar macht, - mit Service oder CI verknüpft ist, - aktuell ist, - und im Ticket nutzbar dokumentiert werden kann. Der Artikel muss im Arbeitsfluss helfen, nicht nur formal existieren. --- **Feedback aus dem Service Desk** Der Service Desk sollte Feedback zu Artikeln geben können. Beispiele: - Artikel nicht gefunden, - Titel unklar, - Schritt fehlt, - Workaround funktioniert nicht mehr, - Fehlerbild hat sich geändert, - Screenshot veraltet, - Eskalationsweg falsch, - Benutzer verstehen Anleitung nicht, - Artikel ist doppelt vorhanden. Feedback muss bearbeitet werden. Sonst verliert der Service Desk Vertrauen in die Knowledge Base. --- **Wissenspflege nach gelösten Incidents** Nach gelösten Incidents sollte geprüft werden: - Gibt es bereits einen passenden Artikel? - Muss der Artikel ergänzt werden? - War der Artikel korrekt? - Sollte ein neuer Artikel entstehen? - Ist ein Known Error erkennbar? - Gibt es einen neuen Workaround? - Sollte Problem Management informiert werden? Diese Prüfung muss nicht bei jedem kleinen Ticket ausführlich sein. Bei wiederkehrenden oder auffälligen Fällen ist sie sehr wertvoll. --- **Wissenspflege nach Problem-Abschluss** Nach Problem Management sollten relevante Artikel aktualisiert werden. Zu prüfen ist: - wurde ein Known Error erstellt, - wurde ein Workaround dokumentiert, - wurde eine dauerhafte Lösung umgesetzt, - ist der Workaround noch gültig, - muss der Service Desk neue Prüfschritte kennen, - muss ein Benutzerartikel erstellt werden, - müssen alte Artikel archiviert werden. Problem-Abschluss ohne Knowledge-Prüfung führt dazu, dass Wissen im Betrieb nicht ankommt. --- **Wissenspflege nach Change oder Release** Nach Changes und Releases muss geprüft werden: - ist der Known Error behoben, - ist der Workaround noch gültig, - haben sich Versionen geändert, - haben sich Menüpfade geändert, - haben sich Symptome geändert, - muss der Artikel archiviert werden, - muss der Service Desk informiert werden, - müssen Benutzerinformationen angepasst werden. Ein veralteter Workaround kann nach einem Release neue Probleme verursachen. --- **Praxisbeispiel: VPN Known Error** **Situation** Nach dem Ruhezustand verlieren Windows-Notebooks die VPN-Verbindung. **Known Error** VPN-Client-Version 5.8 verliert nach Ruhezustand den Tunnelzustand. **Service-Desk-Artikel** - Fehlerbild, - betroffene Version, - Prüfschritte, - Workaround, - Eskalation bei anderer Version, - Problem Record, - geplanter Change auf Version 5.9. **Nutzen** Der Service Desk erkennt den Fall schneller und dokumentiert ihn einheitlich. --- **Praxisbeispiel: Druckertreiber** **Situation** Etikettendruck funktioniert bei bestimmten PDF-Dateien nicht. **Known Error** Der installierte Treiber verarbeitet bestimmte PDF-Formate fehlerhaft. **Workaround** Fehlerhaften Druckauftrag entfernen und alternative Druckoption nutzen. **Dauerhafte Lösung** Treiberupdate testen und ausrollen. **Knowledge-Nutzen** Service Desk kann betroffene Fälle schneller erkennen und vermeidet unnötige Hardwaretauschversuche. --- **Praxisbeispiel: Kein Workaround verfügbar** **Situation** Anmeldung an einer Fachanwendung schlägt wegen abgelaufenem Zertifikat fehl. **Known Error** Zertifikat des Anmeldedienstes ist abgelaufen. **Workaround** Kein sicherer Workaround verfügbar. **Service-Desk-Anweisung** - Incident priorisieren, - an Plattform-Team eskalieren, - Statusmeldung verwenden, - Benutzer nicht auf unsichere Ersatzwege verweisen. **Nutzen** Der Service Desk reagiert klar und sicher. --- **Praxisbeispiel: Artikel veraltet nach Release** **Situation** Nach einem Release ändert sich der Menüpfad für eine Funktion. **Problem** Der alte Benutzerartikel beschreibt den früheren Menüpfad. **Folge** Benutzer erstellen Tickets, obwohl die Funktion verfügbar ist. **Verbesserung** Change- und Release-Abschluss enthalten künftig eine Prüfung betroffener Knowledge-Artikel. --- **Typische Fehler** **Fehler 1** Known Error ist bekannt, aber nicht dokumentiert. --- **Fehler 2** Workaround steht nur in einem alten Ticket. --- **Fehler 3** Service Desk kennt den Workaround nicht. --- **Fehler 4** Artikel beschreibt nicht, wann der Workaround nicht gilt. --- **Fehler 5** Risiken werden nicht genannt. --- **Fehler 6** Known Error wird nicht mit Problem Record verknüpft. --- **Fehler 7** Artikel wird nach Change oder Release nicht aktualisiert. --- **Fehler 8** Benutzer erhalten interne technische Details. --- **Fehler 9** Kein Workaround verfügbar, aber der Artikel sagt das nicht ausdrücklich. --- **Fehler 10** Service Desk dokumentiert nicht, welcher Artikel genutzt wurde. --- **Fehler 11** Häufig genutzte Workarounds werden nicht an Problem Management gemeldet. --- **Fehler 12** Feedback aus dem Service Desk wird nicht bearbeitet. --- **Checkliste Known-Error-Artikel** - [ ] Fehlerbild klar beschrieben - [ ] betroffener Service genannt - [ ] betroffene Version oder Komponente genannt - [ ] Ursache oder wahrscheinliche Ursache beschrieben - [ ] Workaround vorhanden oder ausdrücklich nicht verfügbar - [ ] Risiken genannt - [ ] Einschränkungen genannt - [ ] Prüfschritte enthalten - [ ] Eskalationskriterien beschrieben - [ ] Problem Record verknüpft - [ ] geplanter Change oder dauerhafte Lösung genannt - [ ] Owner und Review-Datum vorhanden --- **Checkliste Workaround** - [ ] genaue Schritte beschrieben - [ ] Voraussetzungen genannt - [ ] Zielgruppe klar - [ ] erwartetes Ergebnis beschrieben - [ ] Risiken bewertet - [ ] Abbruchkriterien definiert - [ ] Eskalationsweg genannt - [ ] Dokumentation im Ticket beschrieben - [ ] Gültigkeitsbereich klar - [ ] Review nach Change oder Release vorgesehen --- **Checkliste Service Desk Nutzung** - [ ] bei bekannten Symptomen Knowledge Base prüfen - [ ] passenden Artikel im Ticket verknüpfen - [ ] Prüfschritte dokumentieren - [ ] Workaround korrekt anwenden - [ ] Ergebnis dokumentieren - [ ] bei Abweichung eskalieren - [ ] bei falschem Artikel Feedback geben - [ ] wiederkehrende Fälle an Problem Management melden - [ ] Benutzer mit freigegebenem Text informieren - [ ] Artikel nicht blind anwenden, wenn Fehlerbild nicht passt --- **Checkliste Wissenspflege** - [ ] häufig genutzte Workarounds auswerten - [ ] Known Errors regelmäßig prüfen - [ ] Artikel nach Changes aktualisieren - [ ] Artikel nach Releases aktualisieren - [ ] gelöste Known Errors archivieren oder anpassen - [ ] Feedback des Service Desk bearbeiten - [ ] Suchbegriffe verbessern - [ ] doppelte Artikel zusammenführen - [ ] veraltete Workarounds entfernen - [ ] Problem Management über neue Muster informieren --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker unterstützen Known Errors und Workarounds durch technisches Verständnis und saubere Dokumentation. Im Arbeitsalltag bedeutet das: - wiederkehrende Fehlerbilder erkennen, - technische Prüfschritte verständlich beschreiben, - Workarounds sicher dokumentieren, - Risiken und Grenzen nennen, - Known Errors mit CIs und Problems verknüpfen, - Service Desk mit klaren Artikeln unterstützen, - nach Changes Artikel aktualisieren, - und häufig genutzte Workarounds als Hinweis auf ungelöste Problems verstehen. Gute Workaround- und Known-Error-Dokumentation spart Zeit und erhöht die Qualität im Support. --- **Zusammenfassung** > Wiederkehrendes Fehlerbild erkennen > ↓ > Problem oder Known Error dokumentieren > ↓ > Symptome und betroffene Versionen beschreiben > ↓ > sicheren Workaround bereitstellen oder Nichtverfügbarkeit kennzeichnen > ↓ > Service-Desk-Artikel erstellen > ↓ > Artikel mit Service, CI, Problem und Change verknüpfen > ↓ > Service Desk nutzt Artikel im Incident > ↓ > Nutzung und Feedback auswerten > ↓ > dauerhafte Lösung verfolgen > ↓ > Artikel nach Change oder Release aktualisieren --- **Merksätze** > Ein Known Error muss auffindbar sein, sonst hilft er dem Service Desk nicht. > Ein Workaround ist hilfreich, aber keine automatische Dauerlösung. > Jeder Workaround braucht Grenzen, Risiken und Eskalationskriterien. > Kein Workaround verfügbar ist ebenfalls eine wichtige Information. > Service Desk Feedback verbessert die Knowledge Base. > Häufig genutzte Workarounds sind ein Hinweis auf ungelöste Problems. > Nach Changes und Releases müssen Known Errors und Workarounds überprüft werden. --- **Verwandte Seiten** - 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen - 7.2 Knowledge-Artikel, Runbooks und FAQ - 7.4 Self-Service und Benutzerwissen - 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change - 4.3 Workarounds und Known Errors - Incident Management - Problem Management - Change Enablement - Service Configuration Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Ergänzende Praxiseinordnung** - Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support **Einordnung** Die dargestellten: - Known-Error-Strukturen, - Workaround-Hinweise, - Service-Desk-Checklisten, - Ticketdokumentation, - Pflegehinweise, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Known-Error-Vorlage, - Workaround-Struktur, - Service-Desk-Artikelpflicht, - Eskalationsmatrix, - Review-Frequenz, - oder Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Supportmodell, - Knowledge-Werkzeuge, - Problem Management, - Change-Modell, - Sicherheitsanforderungen, - Service Configuration Management, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 7.4 Self-Service und Benutzerwissen > **Kurz erklärt** > > Self-Service bedeutet, dass Benutzer einfache Informationen, Anleitungen, Lösungen oder Anfragen selbstständig nutzen können, ohne direkt den Service Desk kontaktieren zu müssen. > > Benutzerwissen ist dafür die Grundlage. > > Gute Self-Service-Angebote helfen Benutzern schnell weiter, reduzieren Standardtickets und entlasten den Service Desk. > > Self-Service funktioniert aber nur, wenn Inhalte verständlich, aktuell, auffindbar und sicher nutzbar sind. --- **Warum Self-Service wichtig ist** Viele Anfragen im IT-Alltag wiederholen sich. Beispiele: - Passwort zurücksetzen, - MFA neu einrichten, - Drucker verbinden, - WLAN einrichten, - Standardsoftware beantragen, - VPN-Anleitung finden, - Status einer Störung prüfen, - häufige Fehlermeldung verstehen, - neues Gerät vorbereiten, - Zugriff beantragen, - Servicezeiten nachlesen. Wenn Benutzer solche Themen selbst lösen können, entstehen Vorteile: - schnellere Hilfe, - weniger Wartezeit, - weniger Standardtickets, - entlasteter Service Desk, - bessere Benutzererfahrung, - einheitliche Antworten, - weniger Rückfragen, - und mehr Zeit für komplexe Störungen. Self-Service ersetzt den Service Desk nicht. Er ergänzt ihn für geeignete Themen. --- **Self-Service ist mehr als eine Knowledge Base** Eine Knowledge Base ist ein wichtiger Bestandteil. Self-Service kann aber mehr umfassen. Beispiele: - Benutzeranleitungen, - FAQ, - Serviceportal, - Statusseite, - Request-Formulare, - Passwort-Reset, - Softwarekatalog, - Chatbot, - automatisierte Standardprozesse, - Benutzerinformationen, - interaktive Hilfen, - geführte Fehlerdiagnose. Self-Service bedeutet: > Benutzer können passende Hilfe oder passende Services eigenständig finden und nutzen. --- **Geeignete Self-Service-Themen** Self-Service eignet sich besonders für: - häufige Fragen, - risikoarme Standardaufgaben, - klare Schritt-für-Schritt-Anleitungen, - wiederkehrende Requests, - einfache Fehlerbilder, - Statusinformationen, - Standardsoftware, - Passwort- und MFA-Themen, - Drucker- und WLAN-Anleitungen, - Onboarding-Informationen, - bekannte Workarounds für Benutzer. Nicht jedes Thema eignet sich für Self-Service. Komplexe, sicherheitskritische oder riskante Tätigkeiten gehören weiterhin in kontrollierte Supportprozesse. --- **Ungeeignete Self-Service-Themen** Self-Service ist ungeeignet, wenn: - Administratorrechte notwendig sind, - Datenverlust möglich ist, - Sicherheitsrisiken entstehen, - Benutzer vertrauliche Informationen sehen würden, - Ursache unklar ist, - mehrere Systeme betroffen sein können, - eine Freigabe erforderlich ist, - gesetzliche oder Compliance-Vorgaben betroffen sind, - falsche Anwendung großen Schaden verursachen kann. Beispiel: Ein Benutzer sollte nicht selbst Firewall-Regeln ändern können. Ein Benutzer kann aber eine verständliche Anleitung erhalten, wie er eine Firewall-Freigabe korrekt beantragt. --- **Benutzerwissen** Benutzerwissen ist Wissen, das für Endbenutzer verständlich und nutzbar aufbereitet ist. Typische Inhalte: - einfache Anleitungen, - kurze FAQ, - Hinweise zu bekannten Störungen, - Schritt-für-Schritt-Hilfen, - Screenshots, - Servicebeschreibungen, - Voraussetzungen, - Antragswege, - Supportkontakte, - Statusinformationen, - Sicherheitsverhalten, - Hinweise zur Ticket-Erstellung. Benutzerwissen sollte nicht wie interne IT-Dokumentation geschrieben sein. Es muss zur Sprache und Situation der Benutzer passen. --- **Interne Sprache und Benutzersprache unterscheiden** Ungeeignet: > Prüfen Sie, ob Ihr Token im Identity Provider korrekt registriert ist. Besser: > Öffnen Sie Ihre Authenticator-App und prüfen Sie, ob Sie die Anmeldung bestätigen können. Ungeeignet: > Der Client verliert nach Sleep den Tunnel State. Besser: > Wenn Ihr VPN nach dem Ruhezustand nicht mehr verbindet, starten Sie den VPN-Client vollständig neu. Ungeeignet: > Erstellen Sie einen Incident mit Kategorie IAM/MFA/Auth. Besser: > Erstellen Sie ein Ticket mit dem Betreff „MFA funktioniert nicht“ und nennen Sie Ihr Gerät und die Fehlermeldung. Benutzerwissen muss verständlich sein, nicht intern perfekt formuliert. --- **Ziele von Self-Service** Self-Service soll: - Benutzer schneller unterstützen, - Standardfragen reduzieren, - einfache Lösungen direkt bereitstellen, - Ticketqualität verbessern, - Anfragen richtig kanalisieren, - Service Desk entlasten, - Wissen einheitlich bereitstellen, - Wartezeiten verringern, - Benutzerzufriedenheit erhöhen, - und Supportprozesse effizienter machen. Self-Service ist nur erfolgreich, wenn Benutzer ihn akzeptieren und nutzen. --- **Voraussetzungen für guten Self-Service** Guter Self-Service benötigt: - verständliche Inhalte, - gute Suche, - klare Kategorien, - aktuelle Artikel, - einfache Formulare, - passende Sprache, - mobile Nutzbarkeit, - Barrierearmut, - klare Supportwege, - gepflegte Serviceinformationen, - regelmäßige Auswertung, - und Rückmeldemöglichkeiten. Ein Portal allein verbessert noch nichts. Die Inhalte und Prozesse müssen funktionieren. --- **Serviceportal** Ein Serviceportal ist ein zentraler Einstiegspunkt für Benutzer. Es kann enthalten: - Knowledge Base, - FAQ, - Servicekatalog, - Request-Formulare, - Ticketstatus, - Störungsmeldungen, - Statusinformationen, - Benutzeranleitungen, - Softwarekatalog, - Passwort-Reset, - Kontaktmöglichkeiten. Ein gutes Serviceportal beantwortet schnell: - Was suche ich? - Was kann ich selbst tun? - Was kann ich beantragen? - Wo sehe ich den Status? - Wann muss ich ein Ticket erstellen? - Welche Informationen werden benötigt? --- **Servicekatalog im Self-Service** Der Servicekatalog beschreibt verfügbare IT-Services aus Benutzersicht. Beispiele: - Standardsoftware beantragen, - neues Benutzerkonto, - Zugriff auf Anwendung, - Hardware bestellen, - Drucker einrichten, - VPN-Zugang beantragen, - Gruppenpostfach beantragen, - Mobilgerät registrieren. Ein guter Servicekatalog erklärt: - wofür der Service ist, - wer ihn nutzen darf, - welche Voraussetzungen bestehen, - welche Genehmigungen nötig sind, - wie lange es ungefähr dauert, - welche Informationen benötigt werden, - und wo Hilfe verfügbar ist. --- **Gute Request-Formulare** Self-Service-Formulare sollten so gestaltet sein, dass Benutzer richtige Informationen liefern können. Ein gutes Formular: - fragt nur notwendige Informationen ab, - nutzt verständliche Feldnamen, - vermeidet interne Kategorien, - bietet passende Auswahlfelder, - erklärt Pflichtfelder, - prüft Eingaben, - zeigt erwartete Bearbeitungszeit, - nennt Genehmigungsschritte, - bietet Hilfetexte, - und erzeugt ein gut bearbeitbares Ticket. Schlechte Formulare erzeugen Rückfragen und falsche Tickets. --- **Beispiel: schlechtes und gutes Formular** Schlecht: | Feld | Problem | |---|---| | Kategorie | Benutzer kennt interne Kategorien nicht | | CI | Benutzer weiß nicht, welches CI betroffen ist | | Priorität | Benutzer bewertet oft zu hoch oder unsicher | | Beschreibung | ohne Hilfe zu ungenau | Besser: | Feld | Vorteil | |---|---| | Welcher Service ist betroffen? | benutzerverständlich | | Was möchten Sie tun? | Ziel wird klar | | Welche Fehlermeldung sehen Sie? | Diagnose wird möglich | | Seit wann tritt das Problem auf? | zeitliche Einordnung | | Sind weitere Personen betroffen? | Auswirkung erkennbar | --- **Ticketqualität durch Self-Service verbessern** Self-Service kann Tickets verbessern, wenn Benutzer geführt werden. Beispiele: - richtige Kategorie wird automatisch gesetzt, - betroffener Service wird abgefragt, - Fehlermeldung wird erfasst, - Screenshots können angehängt werden, - Standort oder Gerät wird abgefragt, - Dringlichkeit wird durch Fragen eingeordnet, - passende Knowledge-Artikel werden vorgeschlagen. Dadurch kann der Service Desk schneller arbeiten. --- **Knowledge-Artikel im Self-Service** Benutzerartikel im Self-Service sollten: - kurze Titel haben, - verständlich formuliert sein, - klare Schritte enthalten, - Screenshots nur bei Nutzen verwenden, - erwartetes Ergebnis beschreiben, - typische Fehler nennen, - Supportweg erklären, - und regelmäßig geprüft werden. Beispielartikel: - Passwort zurücksetzen - MFA auf neuem Smartphone einrichten - VPN auf dem Notebook verbinden - Drucker hinzufügen - Software über das Portal installieren - Verdächtige E-Mail melden --- **Suchfunktion** Die Suche ist entscheidend. Benutzer suchen nicht nach internen IT-Begriffen. Sie suchen nach: - „Passwort vergessen“ - „VPN geht nicht“ - „Drucker offline“ - „neues Handy“ - „MFA funktioniert nicht“ - „Software installieren“ - „E-Mail verdächtig“ - „Portal geht nicht“ Artikel sollten diese Begriffe enthalten. Eine gute Suche berücksichtigt Synonyme, Fehlermeldungen und häufige Formulierungen. --- **Kategorien und Navigation** Neben Suche hilft eine einfache Navigation. Mögliche Kategorien: - Konto und Anmeldung, - Passwort und MFA, - Netzwerk und VPN, - E-Mail und Kalender, - Software, - Hardware, - Drucken, - Dateien und Zugriff, - Sicherheit, - Störungen und Status, - Anträge und Berechtigungen. Kategorien sollten aus Benutzersicht benannt werden. Ungeeignet: - IAM, - Endpoint, - Collaboration, - Network Services, - Infrastructure. Besser: - Anmeldung, - Geräte, - E-Mail, - Netzwerk, - Software, - Zugriff. --- **Statusinformationen** Self-Service kann Benutzer über Störungen informieren. Beispiele: - aktueller Ausfall, - geplantes Wartungsfenster, - bekannte Einschränkung, - Zwischenlösung, - betroffene Services, - nächste Aktualisierung, - Abschlussmeldung. Statusinformationen reduzieren doppelte Tickets. Wenn Benutzer sehen, dass eine Störung bekannt ist, müssen sie nicht erneut nachfragen. --- **Beispiel: Statusmeldung** > Der Service „Mitarbeiterportal“ ist aktuell für einige Benutzer nicht erreichbar. > > Die Ursache wird untersucht. > > Bitte erstellen Sie nur dann ein Ticket, wenn Sie zusätzlich ein anderes Fehlerbild sehen oder dringend individuelle Unterstützung benötigen. > > Nächste Aktualisierung erfolgt um 14:30 Uhr. Statusmeldungen sollten klar, ruhig und verständlich sein. --- **Self-Service bei bekannten Störungen** Bei bekannten Störungen kann Self-Service helfen durch: - sichtbare Statusmeldung, - einfache Erklärung, - Workaround, - Hinweis auf betroffene Benutzer, - Angabe, ob ein Ticket nötig ist, - nächste Aktualisierung, - Link zu weiteren Informationen. Wichtig ist: Benutzer dürfen nicht mit unsicheren Workarounds allein gelassen werden. Bei kritischen Fällen muss der Supportweg klar bleiben. --- **Self-Service und Automatisierung** Self-Service kann mit Automatisierung verbunden sein. Beispiele: - Passwort zurücksetzen, - Standardsoftware bereitstellen, - Benutzer zu genehmigter Gruppe hinzufügen, - Standardgerät bestellen, - Ticket automatisch richtig kategorisieren, - Genehmigungsworkflow starten, - Status automatisch anzeigen, - Knowledge-Artikel automatisch vorschlagen. Automatisierung eignet sich besonders für wiederholbare, risikoarme und klar definierte Aufgaben. --- **Risiken von Automatisierung im Self-Service** Automatisierung muss kontrolliert werden. Risiken: - falsche Berechtigungen, - fehlende Genehmigung, - Missbrauch, - Sicherheitslücken, - falsche Zuordnung, - automatische Fehlerverbreitung, - fehlende Protokollierung, - unklare Verantwortlichkeit. Deshalb müssen automatisierte Self-Service-Prozesse geprüft, überwacht und dokumentiert werden. --- **Genehmigungen im Self-Service** Nicht jeder Self-Service-Request darf sofort ausgeführt werden. Genehmigungen können notwendig sein bei: - Zugriff auf Fachanwendungen, - Berechtigungsänderungen, - kostenpflichtiger Software, - Hardwarebestellung, - externem Zugriff, - Datenfreigabe, - Administratorrechten, - Cloud-Ressourcen, - Sicherheitsausnahmen. Das Portal sollte klar anzeigen: - wer genehmigt, - warum Genehmigung nötig ist, - was der aktuelle Status ist, - und welche Informationen fehlen. --- **Self-Service und Sicherheit** Self-Service muss sicher gestaltet sein. Zu beachten: - Identität des Benutzers prüfen, - Berechtigungen kontrollieren, - sensible Informationen schützen, - keine internen Sicherheitsdetails offenlegen, - Anleitungen mit Risiko einschränken, - Protokollierung sicherstellen, - Missbrauch verhindern, - Datenschutz beachten. Beispiel: Ein Benutzerartikel darf erklären, wie eine verdächtige E-Mail gemeldet wird. Er sollte aber keine internen Erkennungsregeln oder Sicherheitswerkzeuge offenlegen. --- **Self-Service und Datenschutz** Self-Service kann personenbezogene Daten betreffen. Beispiele: - Benutzerkonto, - Gerätedaten, - Standort, - Telefonnummer, - Screenshots, - Ticketbeschreibung, - Zugriffsrechte, - Protokolldaten. Zu prüfen ist: - Welche Daten werden abgefragt? - Sind sie notwendig? - Wer kann sie sehen? - Wie lange werden sie gespeichert? - Wird der Benutzer verständlich informiert? - Gibt es sensible Anhänge? Formulare sollten keine unnötigen personenbezogenen Daten abfragen. --- **Self-Service und Barrierearmut** Self-Service sollte möglichst einfach zugänglich sein. Zu beachten: - klare Sprache, - gut lesbare Struktur, - mobile Nutzbarkeit, - verständliche Links, - sinnvolle Überschriften, - Alternativen zu Bildern, - keine unnötig komplexen Formulare, - ausreichende Kontraste, - verständliche Fehlermeldungen. Ein Self-Service, der schwer zu bedienen ist, erzeugt neue Supportanfragen. --- **Benutzerfeedback** Benutzer sollten Rückmeldung geben können. Mögliche Fragen: - War der Artikel hilfreich? - Haben die Schritte funktioniert? - War etwas unverständlich? - Wurde das Problem gelöst? - Welche Information hat gefehlt? Feedback hilft, Inhalte zu verbessern. Es muss aber regelmäßig ausgewertet werden. Sonst verliert die Feedbackfunktion ihren Wert. --- **Nutzung messen** Mögliche Kennzahlen für Self-Service: | Kennzahl | mögliche Aussage | |---|---| | Artikelaufrufe | welche Themen wichtig sind | | Suchanfragen ohne Treffer | Wissenslücken | | Ticketvermeidung | Self-Service löst Anliegen | | Formularabbrüche | Formular zu kompliziert | | schlechte Bewertungen | Artikel unverständlich oder falsch | | häufige Rückfragen | Inhalt unvollständig | | häufige Requests | Automatisierungspotenzial | | Self-Service-Anteil | Nutzung des Portals | Kennzahlen sollten immer mit Kontext betrachtet werden. Hohe Artikelaufrufe können bedeuten: - Artikel ist wichtig, - Problem tritt häufig auf, - Artikel ist schwer verständlich, - oder Service verursacht viele Fragen. --- **Self-Service-Erfolg messen** Self-Service ist erfolgreich, wenn: - Benutzer passende Hilfe finden, - einfache Anliegen schneller gelöst werden, - Ticketqualität steigt, - Standardtickets sinken, - Service Desk entlastet wird, - Benutzerzufriedenheit steigt, - Inhalte aktuell bleiben, - und keine Sicherheitsrisiken entstehen. Nicht erfolgreich ist Self-Service, wenn Benutzer nur vom Support ferngehalten werden. Self-Service muss Hilfe verbessern, nicht Hilfe erschweren. --- **Ticketvermeidung richtig verstehen** Ticketvermeidung ist nicht immer automatisch positiv. Positiv: - Benutzer löst Passwortproblem selbst. - Benutzer findet passende Anleitung. - Benutzer sieht Statusmeldung und erstellt kein doppeltes Ticket. Negativ: - Benutzer findet keinen Supportweg. - Benutzer gibt frustriert auf. - Benutzer nutzt unsicheren Umweg. - Benutzer meldet echten Incident nicht. Deshalb muss Self-Service immer Benutzererfahrung und Risiko berücksichtigen. --- **Self-Service und Service Desk verbinden** Self-Service und Service Desk sollten zusammenarbeiten. Beispiele: - Service Desk nutzt dieselben Artikel, - Service Desk meldet fehlende Artikel, - Service Desk sieht, welche Artikel Benutzer vorher gelesen haben, - Benutzer können aus einem Artikel direkt ein Ticket erstellen, - Ticketformular übernimmt relevante Informationen, - Artikel werden aus gelösten Tickets verbessert. Self-Service darf nicht getrennt vom Support betrieben werden. --- **Übergang vom Self-Service zum Ticket** Wenn Self-Service nicht hilft, muss der nächste Schritt klar sein. Ein guter Artikel sagt: - Wann soll ein Ticket erstellt werden? - Welche Informationen sollen angegeben werden? - Welche Screenshots sind hilfreich? - Welche Fehlermeldung ist wichtig? - Welche Dringlichkeit ist angemessen? - Gibt es einen alternativen Kontaktweg bei kritischen Störungen? Beispiel: > Erstellen Sie ein Ticket, wenn die Anmeldung nach diesen Schritten weiterhin nicht funktioniert. Geben Sie bitte die Fehlermeldung, Uhrzeit, Gerätetyp und betroffenen Service an. --- **Self-Service bei Onboarding** Beim Onboarding ist Self-Service besonders hilfreich. Mögliche Inhalte: - erstes Login, - Passwort ändern, - MFA einrichten, - E-Mail nutzen, - Kalender nutzen, - WLAN verbinden, - VPN einrichten, - Software installieren, - Drucker hinzufügen, - Serviceportal nutzen, - Sicherheitsregeln, - Supportkontakt. Gutes Onboarding-Wissen reduziert viele Anfangsfragen und verbessert den Start neuer Mitarbeitender. --- **Self-Service bei Offboarding** Auch beim Offboarding kann Self-Service unterstützen. Beispiele: - Checkliste für Führungskräfte, - Rückgabe von Geräten, - Umgang mit Daten, - Weiterleitung oder Deaktivierung von Postfächern, - Entzug von Berechtigungen, - Archivierung, - Software- und Lizenzrückgabe. Diese Themen sind oft sicherheits- und compliance-relevant. Deshalb müssen klare Prozesse und Genehmigungen berücksichtigt werden. --- **Self-Service bei Sicherheitsfragen** Benutzerwissen ist für Informationssicherheit wichtig. Beispiele: - Phishing melden, - verdächtige E-Mail erkennen, - verlorenes Gerät melden, - Passwort sicher ändern, - MFA-Probleme melden, - keine Zugangsdaten weitergeben, - sichere Dateiablage nutzen, - Sicherheitsvorfall melden. Sicherheitsartikel müssen besonders verständlich sein. Benutzer müssen schnell erkennen, was sie tun sollen. --- **Benutzer nicht überfordern** Self-Service sollte Benutzer unterstützen, nicht mit IT-Arbeit belasten. Warnzeichen: - zu viele Pflichtfelder, - unklare Kategorien, - lange technische Texte, - keine Suche, - veraltete Artikel, - komplizierte Genehmigungswege, - keine Rückmeldung, - kein klarer Supportweg. Self-Service darf nicht bedeuten: > Benutzer sollen sich selbst durch schlechte Prozesse kämpfen. --- **Benutzerperspektive testen** Self-Service-Inhalte sollten aus Benutzersicht getestet werden. Fragen: - Findet ein Benutzer den Artikel über typische Begriffe? - Versteht er die Schritte ohne IT-Vorwissen? - Weiß er, wann er stoppen muss? - Weiß er, wann ein Ticket nötig ist? - Funktionieren Links und Screenshots? - Ist der Artikel auf mobilen Geräten nutzbar? - Wird klar, was als nächstes passiert? Ein technisch korrekter Artikel kann trotzdem schlecht sein, wenn Benutzer ihn nicht verstehen. --- **Service Desk als Qualitätsquelle** Der Service Desk erkennt häufig, wo Self-Service scheitert. Beispiele: - Benutzer finden Artikel nicht, - Formulare erzeugen falsche Tickets, - Anleitungen sind unklar, - Artikel sind veraltet, - Kategorien passen nicht, - Suchbegriffe fehlen, - Standardfrage tritt trotz Artikel weiter häufig auf. Deshalb sollte Service-Desk-Feedback regelmäßig in Self-Service-Verbesserungen einfließen. --- **Self-Service-Inhalte nach Changes aktualisieren** Changes können Self-Service-Inhalte veralten lassen. Beispiele: - neue Oberfläche, - anderer Menüpfad, - neue MFA-Methode, - neue VPN-Version, - geänderter Softwarekatalog, - geänderte Genehmigung, - neues Serviceportal, - anderer Supportweg. Change-Abschluss sollte deshalb prüfen: > Welche Benutzerartikel, FAQ oder Formulare müssen aktualisiert werden? --- **Self-Service-Inhalte nach Releases aktualisieren** Releases können Benutzerfragen auslösen. Vor einem Release sollten vorbereitet werden: - Release Notes, - Benutzeranleitung, - FAQ, - bekannte Einschränkungen, - Supportartikel, - Statusinformationen, - Self-Service-Formulare, - Service-Desk-Briefing. Nach dem Release sollten Suchanfragen, Tickets und Feedback beobachtet werden. --- **Self-Service und Continual Improvement** Self-Service sollte kontinuierlich verbessert werden. Möglicher Ablauf: Nutzung analysieren ↓ Suchanfragen ohne Treffer prüfen ↓ häufige Tickets auswerten ↓ Artikel verbessern ↓ Formulare vereinfachen ↓ Automatisierung prüfen ↓ Feedback auswerten ↓ Wirkung messen Guter Self-Service entsteht durch regelmäßige Pflege, nicht durch einmalige Erstellung. --- **Praxisbeispiel: MFA neues Smartphone** **Situation** Viele Benutzer erstellen Tickets, weil sie ein neues Smartphone haben. **Problem** Der alte Artikel ist schwer auffindbar und nutzt interne Begriffe. **Verbesserung** - Titel: „MFA auf neuem Smartphone einrichten“ - Suchbegriffe: MFA, Authenticator, neues Handy, Anmeldung - einfache Schritte, - Screenshots, - Hinweis bei fehlendem Zugriff, - direkter Ticketlink. **Nutzen** Benutzer lösen einfache Fälle selbst. Komplexe Fälle landen mit besseren Informationen beim Service Desk. --- **Praxisbeispiel: VPN-Anleitung** **Situation** Viele Benutzer melden VPN-Probleme im Homeoffice. **Self-Service-Inhalt** - Voraussetzungen prüfen, - Internetverbindung testen, - VPN-Client öffnen, - bekannte Fehlermeldungen erklären, - Workaround bei Ruhezustand, - Ticketweg bei weiterhin bestehendem Fehler. **Wichtig** Sicherheitsrelevante interne Details bleiben im Service-Desk-Artikel. Benutzer erhalten nur sichere, verständliche Schritte. --- **Praxisbeispiel: Software beantragen** **Situation** Benutzer fragen per E-Mail nach Standardsoftware. **Self-Service-Lösung** - Softwarekatalog im Portal, - klare Beschreibung der Software, - automatische Genehmigung bei freigegebener Standardsoftware, - Lizenzhinweis, - Statusanzeige, - automatische Installation, falls möglich. **Nutzen** Weniger manuelle Rückfragen und schnellere Bereitstellung. --- **Praxisbeispiel: Statusseite bei Störung** **Situation** E-Mail-Service ist gestört. **Ohne Statusseite** Viele Benutzer erstellen identische Tickets. **Mit Statusseite** Benutzer sehen: - Störung ist bekannt, - betroffener Service, - aktueller Status, - nächste Aktualisierung, - ob ein Ticket notwendig ist. **Nutzen** Service Desk kann sich stärker auf Behebung und Kommunikation konzentrieren. --- **Typische Fehler** **Fehler 1** Self-Service wird als Ersatz für Support verstanden. --- **Fehler 2** Benutzerartikel sind zu technisch. --- **Fehler 3** Artikel sind nicht auffindbar. --- **Fehler 4** Suchbegriffe der Benutzer fehlen. --- **Fehler 5** Formulare fragen interne IT-Kategorien ab. --- **Fehler 6** Self-Service enthält unsichere Workarounds. --- **Fehler 7** Benutzer wissen nicht, wann sie ein Ticket erstellen sollen. --- **Fehler 8** Statusinformationen fehlen bei bekannten Störungen. --- **Fehler 9** Feedback wird gesammelt, aber nicht ausgewertet. --- **Fehler 10** Artikel werden nach Changes und Releases nicht aktualisiert. --- **Fehler 11** Automatisierung wird ohne ausreichende Kontrolle eingeführt. --- **Fehler 12** Ticketvermeidung wird wichtiger genommen als echte Hilfe. --- **Checkliste Self-Service-Thema auswählen** - [ ] Thema tritt häufig auf - [ ] Lösung ist klar beschreibbar - [ ] Risiko ist niedrig oder kontrollierbar - [ ] Benutzer dürfen die Schritte selbst ausführen - [ ] keine vertraulichen internen Informationen nötig - [ ] Supportweg kann klar beschrieben werden - [ ] Artikel kann aktuell gehalten werden - [ ] Nutzen für Benutzer ist erkennbar - [ ] Service Desk wird entlastet - [ ] Sicherheits- und Datenschutzfragen sind geprüft --- **Checkliste Benutzerartikel** - [ ] Titel nutzt Benutzersprache - [ ] Zielgruppe ist klar - [ ] Problem oder Aufgabe ist verständlich beschrieben - [ ] Voraussetzungen sind genannt - [ ] Schritte sind einfach und kurz - [ ] erwartetes Ergebnis ist beschrieben - [ ] typische Fehler sind genannt - [ ] Supportweg ist klar - [ ] keine internen vertraulichen Informationen enthalten - [ ] Screenshots sind aktuell, falls verwendet - [ ] Owner ist eingetragen - [ ] Review-Datum ist gesetzt --- **Checkliste Serviceportal** - [ ] Suche funktioniert mit Benutzerbegriffen - [ ] Kategorien sind verständlich - [ ] häufige Anliegen sind leicht auffindbar - [ ] Servicekatalog ist aktuell - [ ] Formulare sind einfach - [ ] Ticketstatus ist sichtbar - [ ] Statusmeldungen sind vorhanden - [ ] Feedback ist möglich - [ ] Inhalte sind mobil nutzbar - [ ] Zugriffsschutz ist passend - [ ] Service Desk kann Inhalte pflegen oder Feedback geben --- **Checkliste Self-Service-Formular** - [ ] fragt nur notwendige Informationen ab - [ ] nutzt verständliche Feldnamen - [ ] erklärt Pflichtfelder - [ ] vermeidet interne Kategorien - [ ] bietet passende Auswahlfelder - [ ] schlägt Knowledge-Artikel vor - [ ] prüft Eingaben, soweit möglich - [ ] zeigt Genehmigungen und Status - [ ] nennt erwartete Bearbeitung - [ ] erzeugt ein gut bearbeitbares Ticket --- **Checkliste Self-Service verbessern** - [ ] häufige Tickets ausgewertet - [ ] Suchanfragen ohne Treffer geprüft - [ ] Artikelbewertungen ausgewertet - [ ] Formularabbrüche analysiert - [ ] Service-Desk-Feedback eingeholt - [ ] Benutzerfeedback berücksichtigt - [ ] veraltete Artikel aktualisiert - [ ] neue Artikel für häufige Themen erstellt - [ ] Automatisierungspotenzial geprüft - [ ] Sicherheitsrisiken bewertet - [ ] Wirkung nach Verbesserung gemessen --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker unterstützen Self-Service durch praxisnahes technisches Wissen. Im Arbeitsalltag bedeutet das: - häufige technische Fragen erkennen, - verständliche Benutzerartikel mit vorbereiten, - sichere Workarounds von riskanten Maßnahmen unterscheiden, - Service Desk mit klaren Informationen versorgen, - Formulare aus technischer Sicht verbessern, - Automatisierung für Standardaufgaben unterstützen, - Inhalte nach Changes aktualisieren, - und technische Begriffe in benutzerverständliche Sprache übersetzen. Guter Self-Service entsteht durch Zusammenarbeit von Service Desk, Fachgruppen, Service Ownern und Benutzern. --- **Zusammenfassung** > häufige Benutzeranliegen erkennen > ↓ > prüfen, ob Self-Service geeignet und sicher ist > ↓ > Benutzerwissen verständlich aufbereiten > ↓ > Artikel, FAQ, Formular oder Automatisierung bereitstellen > ↓ > Serviceportal und Suche benutzerfreundlich gestalten > ↓ > Übergang zum Ticket klar beschreiben > ↓ > Nutzung und Feedback auswerten > ↓ > Inhalte nach Changes und Releases aktualisieren > ↓ > Self-Service kontinuierlich verbessern --- **Merksätze** > Self-Service ersetzt den Service Desk nicht, sondern ergänzt ihn. > Benutzerwissen muss in Benutzersprache geschrieben sein. > Ein Artikel hilft nur, wenn er gefunden und verstanden wird. > Gute Formulare verbessern Ticketqualität. > Ticketvermeidung ist nur positiv, wenn Benutzer wirklich Hilfe erhalten. > Self-Service muss sicher, aktuell und gepflegt sein. > Der Service Desk ist eine wichtige Quelle für Self-Service-Verbesserungen. --- **Verwandte Seiten** - 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen - 7.2 Knowledge-Artikel, Runbooks und FAQ - 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk - 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change - Service Desk - Incident Management - Request Fulfilment - Change Enablement - Release Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Service Request Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Ergänzende Praxiseinordnung** - Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support - Allgemeine UX- und Support-Praxis für Self-Service-Portale, Formularqualität und Benutzerkommunikation **Einordnung** Die dargestellten: - Self-Service-Beispiele, - Benutzerartikel-Strukturen, - Formularhinweise, - Checklisten, - Kennzahlen, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Self-Service-Portal-Struktur, - Artikelvorlage, - Formularstruktur, - Suchlogik, - Automatisierungspflicht, - Kennzahlenliste, - oder Toolauswahl für alle Organisationen vor. Die konkrete Umsetzung muss an: - Benutzergruppen, - Services, - Supportmodell, - Sicherheitsanforderungen, - Datenschutz, - Knowledge-Werkzeuge, - Servicekatalog, - Automatisierungsgrad, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change > **Kurz erklärt** > > Knowledge Management wirkt nicht isoliert. > > Es verbindet Wissen aus Incident Management, Problem Management, Change Enablement, Release Management, Service Desk und Service Configuration Management. > > Ziel ist, dass Erfahrungen, Lösungen, Workarounds, Known Errors, Runbooks und Benutzerinformationen im richtigen Moment verfügbar sind. --- **Warum das Zusammenspiel wichtig ist** Im IT-Betrieb entsteht Wissen ständig während der Arbeit. Beispiele: - ein Incident wird gelöst, - ein Workaround wird gefunden, - ein Problem wird analysiert, - ein Known Error wird dokumentiert, - ein Change verändert einen Service, - ein Release bringt neue Funktionen, - ein Benutzerartikel wird nach Rückfragen verbessert, - ein Major Incident erzeugt Lessons Learned. Wenn dieses Wissen nicht in Knowledge Management einfließt, geht es verloren. Dann entstehen typische Probleme: - gleiche Incidents werden immer wieder neu analysiert, - Service Desk nutzt veraltete Informationen, - Workarounds stehen nur in einzelnen Tickets, - Benutzer erhalten widersprüchliche Antworten, - Knowledge-Artikel passen nicht mehr zur aktuellen Version, - Known Errors sind nicht auffindbar, - Changes verändern Services, aber Artikel bleiben alt, - und Verbesserungen werden nicht dauerhaft übernommen. --- **Grundidee des Zusammenspiels** Incident tritt auf ↓ Service Desk nutzt vorhandenes Wissen ↓ fehlendes oder falsches Wissen wird erkannt ↓ Problem Management analysiert wiederkehrende Ursachen ↓ Known Error oder Workaround entsteht ↓ Knowledge Management macht dieses Wissen nutzbar ↓ Change oder Release setzt dauerhafte Lösung um ↓ Knowledge-Artikel, Runbooks und FAQ werden aktualisiert ↓ zukünftige Incidents werden schneller gelöst oder vermieden Knowledge Management ist damit ein Lernkreislauf im IT-Betrieb. --- **Zusammenspiel mit Incident Management** Incident Management nutzt Knowledge, um Services schneller wiederherzustellen. Nützlich sind: - bekannte Symptome, - Standardlösungen, - Workarounds, - Known Errors, - Prüfschritte, - Eskalationsregeln, - Benutzerinformationen, - Runbooks, - Service-Desk-Artikel. Beispiel: Ein Benutzer meldet, dass VPN nach dem Ruhezustand nicht mehr verbindet. Der Service Desk findet einen Knowledge-Artikel mit: - betroffenem VPN-Client, - Prüfschritten, - Workaround, - Eskalationskriterien, - Verknüpfung zum Known Error. Dadurch muss der Incident nicht neu analysiert werden. --- **Incident Management liefert Wissen zurück** Incidents zeigen, welches Wissen fehlt oder verbessert werden muss. Beispiele: - neuer Fehler tritt auf, - bekannter Workaround funktioniert nicht mehr, - Artikel ist unverständlich, - Suchbegriff fehlt, - Eskalationsweg ist falsch, - Benutzer stellen immer dieselbe Frage, - Service Desk ergänzt immer wieder dieselbe Erklärung, - Artikel passt nicht zur aktuellen Version. Diese Erkenntnisse sollten in Knowledge Management zurückfließen. Ein gelöster Incident kann also Auslöser für einen neuen oder verbesserten Knowledge-Artikel sein. --- **Wann aus einem Incident ein Knowledge-Artikel entstehen sollte** Ein Knowledge-Artikel ist sinnvoll, wenn: - der Incident wahrscheinlich wieder auftreten wird, - die Lösung wiederverwendbar ist, - ein Workaround gefunden wurde, - Service Desk künftig schneller reagieren kann, - Benutzer eine Anleitung benötigen, - eine Fehlermeldung häufig vorkommt, - eine Eskalation klar geregelt werden muss, - oder der Fall für neue Mitarbeitende hilfreich ist. Nicht jeder einzelne Incident benötigt einen eigenen Artikel. Aber wiederkehrende oder typische Fälle sollten dokumentiert werden. --- **Zusammenspiel mit Problem Management** Problem Management erzeugt besonders wertvolles Wissen. Beispiele: - Ursachenanalyse, - bekannte Ursachen, - beitragende Faktoren, - Known Errors, - Workarounds, - dauerhafte Lösungen, - Risiken, - Lessons Learned, - wiederkehrende Muster. Dieses Wissen darf nicht nur im Problem Record bleiben. Es muss so aufbereitet werden, dass es im Service Desk, in Fachgruppen oder im Self-Service genutzt werden kann. --- **Problem Management liefert Known Errors** Ein Known Error sollte in Knowledge Management nutzbar gemacht werden. Ein guter Known-Error-Artikel enthält: - Fehlerbild, - betroffener Service, - betroffene Version, - Ursache oder wahrscheinliche Ursache, - Workaround, - Risiken, - Einschränkungen, - Eskalationskriterien, - dauerhafte Lösung, - Status, - Problem-Verknüpfung, - Review-Datum. Dadurch kann Incident Management neue Incidents schneller zuordnen. --- **Knowledge Management unterstützt Problem Management** Knowledge Management hilft Problem Management durch: - historische Artikel, - bekannte Workarounds, - häufig genutzte Lösungen, - Suchanfragen ohne Treffer, - wiederkehrende Service-Desk-Fragen, - schlecht bewertete Artikel, - Hinweise auf Knowledge-Lücken, - Nutzungsauswertungen, - Verknüpfungen zu Incidents. Beispiel: Ein Workaround-Artikel wird sehr häufig genutzt. Das kann ein Hinweis sein, dass ein Problem weiterhin offen ist und eine dauerhafte Lösung benötigt. --- **Zusammenspiel mit Change Enablement** Changes verändern Services, Systeme, Prozesse und Benutzeroberflächen. Dadurch kann Wissen veralten. Nach einem Change müssen möglicherweise aktualisiert werden: - Benutzerartikel, - FAQ, - Service-Desk-Artikel, - Runbooks, - Known Errors, - Workarounds, - Screenshots, - Menüpfade, - Eskalationswege, - Servicebeschreibungen, - Monitoringhinweise, - CMDB-Verknüpfungen. Ein Change ist nicht vollständig abgeschlossen, wenn die technische Änderung umgesetzt wurde, aber das Wissen noch den alten Zustand beschreibt. --- **Knowledge-Prüfung im Change-Abschluss** Beim Abschluss eines Changes sollte geprüft werden: - Welche Artikel sind betroffen? - Haben sich Schritte, Screenshots oder Menüpfade geändert? - Gibt es neue Fehlermeldungen? - Wurde ein Known Error behoben? - Ist ein Workaround noch gültig? - Muss ein Benutzerartikel erstellt werden? - Muss der Service Desk informiert werden? - Muss ein Runbook angepasst werden? - Muss ein Artikel archiviert werden? Diese Prüfung sollte Teil der Change-Nachbereitung sein. --- **Beispiel: Change macht Wissen veraltet** **Situation** Eine Anwendung erhält eine neue Oberfläche. **Problem** Der Self-Service-Artikel beschreibt noch die alte Menüführung. **Folge** Benutzer finden die Funktion nicht und erstellen Tickets. **Verbesserung** Change Enablement ergänzt eine Pflichtprüfung: > Welche Knowledge-Artikel, FAQ und Screenshots müssen vor oder nach dem Change aktualisiert werden? --- **Zusammenspiel mit Release Management** Releases bringen neue oder geänderte Funktionen. Knowledge Management unterstützt Releases durch: - Release Notes, - Benutzerinformationen, - FAQ, - Service-Desk-Briefings, - Known Errors, - bekannte Einschränkungen, - neue Workarounds, - aktualisierte Runbooks, - Schulungsunterlagen. Ein Release ohne Knowledge-Vorbereitung führt häufig zu unnötigen Rückfragen. --- **Release-Wissen vor Veröffentlichung vorbereiten** Vor einem Release sollte geklärt werden: - Was ändert sich für Benutzer? - Welche Funktionen sind neu? - Welche Funktionen ändern sich? - Welche bekannten Einschränkungen bestehen? - Welche Artikel müssen aktualisiert werden? - Welche Fragen werden Benutzer wahrscheinlich stellen? - Welche Informationen benötigt der Service Desk? - Welche Known Errors sind relevant? - Welche Workarounds sind freigegeben? Gute Release-Kommunikation reduziert Incidents nach der Einführung. --- **Zusammenspiel mit Service Desk** Der Service Desk ist gleichzeitig Nutzer und Lieferant von Wissen. Er nutzt Knowledge für: - schnelle Antworten, - Standardlösungen, - Workarounds, - Eskalation, - Benutzerkommunikation, - Ticketdokumentation. Er liefert Knowledge zurück durch: - Feedback zu Artikeln, - Hinweise auf fehlende Inhalte, - wiederkehrende Fragen, - neue Fehlerbilder, - Suchbegriffe aus der Praxis, - Rückmeldungen von Benutzern. Der Service Desk sollte deshalb aktiv in Knowledge Management eingebunden sein. --- **Service Desk als Qualitätsfilter** Der Service Desk erkennt schnell, ob Wissen im Alltag funktioniert. Typische Rückmeldungen: - Artikel wird nicht gefunden, - Titel passt nicht zur Benutzersprache, - Schritte sind unklar, - Screenshot ist veraltet, - Workaround funktioniert nicht, - Eskalationsweg stimmt nicht, - Artikel ist zu lang, - Artikel enthält zu viele interne Details, - Benutzer verstehen die Anleitung nicht. Diese Rückmeldungen sollten regelmäßig ausgewertet werden. --- **Zusammenspiel mit Self-Service** Self-Service nutzt Knowledge, damit Benutzer einfache Anliegen selbst lösen können. Geeignet sind: - FAQ, - Benutzeranleitungen, - Statusinformationen, - bekannte sichere Workarounds, - Servicebeschreibungen, - Request-Formulare, - Passwort- und MFA-Hilfen, - Softwarekatalog, - Onboarding-Anleitungen. Self-Service braucht besonders klare Sprache. Interne Diagnoseschritte oder sicherheitskritische Informationen gehören nicht ungeprüft in Benutzerartikel. --- **Self-Service liefert Wissen zurück** Self-Service-Daten zeigen, was Benutzer wirklich suchen. Wichtige Signale: - häufige Suchanfragen, - Suchanfragen ohne Treffer, - häufig geöffnete Artikel, - schlechte Bewertungen, - hohe Formularabbrüche, - viele Tickets nach Artikelaufruf, - wiederkehrende Begriffe aus Benutzertexten. Diese Daten helfen, Knowledge-Artikel, FAQ und Formulare zu verbessern. --- **Zusammenspiel mit Service Configuration Management** Service Configuration Management liefert Kontext zu Wissen. Wichtige Verknüpfungen: - Artikel zu Service, - Artikel zu Configuration Item, - Known Error zu betroffener Version, - Runbook zu Anwendung oder Server, - Workaround zu Problem Record, - Benutzerartikel zu Servicekatalogeintrag, - Release Notes zu Anwendungsversion. Ohne Service- oder CI-Bezug sind Knowledge-Artikel schwerer auffindbar und schwerer aktuell zu halten. --- **Beispiel: Knowledge und CI-Verknüpfung** Ein Artikel beschreibt einen VPN-Fehler. Sinnvolle Verknüpfungen: - Service: VPN-Zugang, - CI: VPN-Client-Version, - CI: VPN-Gateway, - CI: Identity Provider, - Problem Record, - Known Error, - geplanter Change. Dadurch kann der Artikel bei passenden Incidents automatisch vorgeschlagen oder schneller gefunden werden. --- **Zusammenspiel mit Information Security Management** Sicherheitswissen muss besonders sorgfältig gepflegt werden. Beispiele: - Phishing melden, - verlorenes Gerät melden, - MFA-Probleme, - Passwortregeln, - verdächtige Anmeldung, - Sicherheitsvorfall-Prozess, - Umgang mit sensiblen Daten, - sichere Dateiablage, - Meldewege, - Verhalten bei Verdacht auf Kompromittierung. Sicherheitsartikel müssen verständlich sein. Sie dürfen aber keine internen Schutzmechanismen unnötig offenlegen. --- **Sicherheitsrelevante Knowledge-Artikel** Bei sicherheitsrelevanten Artikeln ist zu prüfen: - Wer darf den Artikel sehen? - Sind interne Details geschützt? - Ist die Anleitung missbrauchssicher? - Gibt es klare Meldewege? - Ist der Inhalt fachlich freigegeben? - Ist der Artikel aktuell? - Ist ein Review-Datum gesetzt? - Sind Datenschutzanforderungen berücksichtigt? Falsches Sicherheitswissen kann zu hohen Risiken führen. --- **Zusammenspiel mit Continual Improvement** Knowledge Management liefert viele Hinweise für Verbesserungen. Beispiele: - häufige Suchanfragen ohne Treffer, - viele Tickets trotz Self-Service-Artikel, - häufig genutzte Workarounds, - schlecht bewertete Artikel, - veraltete Runbooks, - fehlende Knowledge-Verknüpfungen, - wiederkehrende Benutzerfragen, - viele Eskalationen wegen fehlender Prüfschritte. Diese Erkenntnisse sollten in Continual Improvement einfließen. --- **Knowledge als Verbesserungsquelle** Ein sinnvoller Verbesserungsablauf: Knowledge-Daten auswerten ↓ Lücken und Qualitätsprobleme erkennen ↓ Verbesserungsmaßnahme definieren ↓ Owner und Termin festlegen ↓ Artikel, Formular oder Prozess verbessern ↓ Wirkung messen ↓ Ergebnis in Continual Improvement übernehmen Knowledge Management ist damit nicht nur Dokumentation, sondern auch Verbesserungsarbeit. --- **Wissen im Lebenszyklus eines Incidents** Benutzer meldet Störung ↓ Service Desk sucht passenden Artikel ↓ Artikel liefert Prüfschritte oder Workaround ↓ Incident wird gelöst oder eskaliert ↓ Ticket wird mit Artikel verknüpft ↓ Feedback zum Artikel wird dokumentiert ↓ Knowledge-Artikel wird bei Bedarf verbessert So wird jeder Incident zu einer möglichen Quelle für besseres Wissen. --- **Wissen im Lebenszyklus eines Problems** Wiederkehrende Incidents werden erkannt ↓ Problem Record wird erstellt ↓ Ursache oder wahrscheinliche Ursache wird analysiert ↓ Known Error wird dokumentiert ↓ Workaround wird erstellt ↓ Service Desk erhält Knowledge-Artikel ↓ dauerhafte Lösung wird verfolgt ↓ Artikel wird nach Lösung aktualisiert oder archiviert Problem Management und Knowledge Management arbeiten hier besonders eng zusammen. --- **Wissen im Lebenszyklus eines Changes** Change wird geplant ↓ betroffene Artikel und Runbooks werden identifiziert ↓ Service Desk und Benutzerinformationen werden vorbereitet ↓ Change wird umgesetzt ↓ Wissen wird aktualisiert ↓ alte Artikel werden angepasst oder archiviert ↓ Feedback nach Change wird ausgewertet So verhindert Change Enablement, dass veraltetes Wissen im Betrieb bleibt. --- **Wissensverknüpfungen** Gute Knowledge-Arbeit nutzt Verknüpfungen. Mögliche Verknüpfungen: - Knowledge-Artikel zu Incident, - Knowledge-Artikel zu Problem, - Known Error zu Workaround, - Workaround zu Service, - Runbook zu CI, - Benutzerartikel zu Servicekatalog, - Artikel zu Change, - Artikel zu Release, - Artikel zu Sicherheitsmeldung. Verknüpfungen verbessern Auffindbarkeit, Auswertung und Pflege. --- **Rollen im Zusammenspiel** | Rolle | Beitrag zu Knowledge Management | |---|---| | **Service Desk** | nutzt Artikel, gibt Feedback, erkennt Wissenslücken | | **Fachteam** | liefert technische Inhalte und prüft Richtigkeit | | **Problem Management** | liefert Known Errors, Ursachen und Workarounds | | **Change Management** | sorgt für Aktualisierung nach Changes | | **Release Management** | liefert Release Notes und neue Informationen | | **Service Owner** | prüft fachliche Richtigkeit und Benutzerwirkung | | **Security Team** | prüft sicherheitsrelevante Inhalte | | **Knowledge Owner** | verantwortet Pflege, Review und Qualität | Rollen können je nach Organisation unterschiedlich benannt sein. Wichtig sind klare Verantwortlichkeiten. --- **Knowledge Owner** Ein Knowledge Owner sorgt dafür, dass ein Artikel aktuell und korrekt bleibt. Aufgaben: - fachliche Prüfung, - Review, - Feedback bewerten, - Änderungen einarbeiten, - veraltete Inhalte archivieren, - Zielgruppe prüfen, - Zugriffsschutz prüfen, - Verknüpfungen pflegen. Ohne Knowledge Owner veralten wichtige Artikel schnell. --- **Service Owner** Der Service Owner hilft zu klären: - welche Benutzerinformationen nötig sind, - welche Servicebeschreibung korrekt ist, - welche Auswirkungen ein Known Error hat, - welche Kommunikation freigegeben ist, - welche Artikel für den Service wichtig sind, - welche Inhalte nach Changes angepasst werden müssen. Service Owner verbinden technische Informationen mit Service- und Benutzerperspektive. --- **Fachteams** Fachteams liefern technisches Wissen. Beispiele: - Logauswertung, - Ursache, - Konfigurationsdetails, - technische Risiken, - sichere Workarounds, - Runbooks, - Abbruchkriterien, - Rollback-Hinweise, - technische Prüfungen nach Changes. Fachteams sollten Wissen so aufbereiten, dass Service Desk oder Benutzer es passend nutzen können. --- **Wissen für verschiedene Zielgruppen aufbereiten** Ein technischer Sachverhalt kann mehrere Wissensformen benötigen. Beispiel: Zertifikatsproblem **Benutzerartikel** - aktuelle Einschränkung, - was Benutzer tun können, - wo Statusinformationen stehen. **Service-Desk-Artikel** - Symptome, - betroffener Service, - Eskalationsweg, - freigegebene Kommunikation. **Fachteam-Runbook** - Zertifikat prüfen, - Zertifikat erneuern, - Dienst testen, - Monitoring prüfen, - CMDB aktualisieren. Ein Artikel für alle Zielgruppen ist oft nicht sinnvoll. --- **Wissensqualität im Zusammenspiel** Wissensqualität bedeutet: - richtige Information, - richtige Zielgruppe, - richtige Detailtiefe, - richtige Sichtbarkeit, - richtige Verknüpfung, - aktueller Stand, - klarer Owner, - regelmäßiger Review. Ein fachlich richtiger Artikel kann trotzdem schlecht sein, wenn er für die Zielgruppe unverständlich ist. Ein gut geschriebener Artikel kann gefährlich sein, wenn er veraltet ist. --- **Kennzahlen für das Zusammenspiel** Mögliche Kennzahlen: | Kennzahl | mögliche Aussage | |---|---| | Incidents mit verknüpftem Knowledge-Artikel | Nutzung im Service Desk | | häufig genutzte Artikel | wichtige Supportthemen | | Suchanfragen ohne Treffer | Wissenslücken | | Artikel ohne Owner | Pflegeproblem | | Artikel ohne Review-Datum | Aktualitätsrisiko | | Tickets trotz Self-Service-Artikel | Artikel nicht hilfreich oder Problem weiterhin häufig | | Known Errors ohne Artikel | Wissen fehlt im Support | | Changes ohne Knowledge-Prüfung | Risiko veralteter Artikel | | schlechte Artikelbewertungen | Qualitätsproblem | Kennzahlen müssen mit Feedback und fachlicher Bewertung kombiniert werden. --- **Wissen aus Major Incidents** Major Incidents liefern besonders wichtige Erkenntnisse. Nach einem Major Incident sollte geprüft werden: - Welche Informationen haben gefehlt? - Welche Runbooks waren hilfreich? - Welche Artikel waren veraltet? - Welche Kommunikation war unklar? - Welche Workarounds wurden genutzt? - Welche Known Errors entstanden? - Welche Benutzerinformationen müssen verbessert werden? - Welche Lessons Learned gehören in Knowledge Management? Ein Major Incident Review ohne Knowledge-Aktualisierung verschenkt Lernpotenzial. --- **Wissen aus Failed Changes** Auch fehlgeschlagene Changes liefern wertvolles Wissen. Zu prüfen ist: - War das Runbook ausreichend? - War der Rollback beschrieben? - Waren Tests vollständig? - Gab es fehlende Abhängigkeiten? - War Service Desk informiert? - Müssen Change-Vorlagen verbessert werden? - Muss ein neuer Knowledge-Artikel entstehen? - Muss ein Known Error dokumentiert werden? Failed Changes sollten nicht nur technisch korrigiert, sondern auch wissensseitig ausgewertet werden. --- **Wissen aus Releases** Nach Releases sollte beobachtet werden: - Welche Fragen stellen Benutzer? - Welche Incidents entstehen? - Welche Artikel werden häufig aufgerufen? - Welche Suchbegriffe führen zu keinem Treffer? - Welche Screenshots sind veraltet? - Welche Known Errors sind neu? - Welche FAQ fehlt? So kann Knowledge Management schnell auf reale Benutzerfragen reagieren. --- **Praxisbeispiel: VPN-Problem** **Incident Management** Benutzer melden VPN-Abbrüche. **Problem Management** Mehrere Incidents zeigen dasselbe Muster. Ursache ist eine fehlerhafte Client-Version. **Knowledge Management** Ein Known-Error-Artikel wird erstellt. Er enthält: - Fehlerbild, - betroffene Version, - Prüfschritte, - Workaround, - Eskalationskriterien, - geplanten Change. **Change Enablement** Neue Client-Version wird ausgerollt. **Nachbereitung** Knowledge-Artikel wird aktualisiert oder archiviert. --- **Praxisbeispiel: MFA-Self-Service** **Beobachtung** Viele Tickets entstehen wegen neuem Smartphone. **Knowledge Management** Benutzerartikel wird erstellt: - MFA auf neuem Smartphone einrichten, - Screenshots, - Hinweis bei fehlendem Zugriff, - Ticketlink. **Service Desk** Tickets enthalten bessere Informationen. **Continual Improvement** Suchbegriffe und Formular werden verbessert. **Nutzen** Weniger Standardtickets und bessere Benutzererfahrung. --- **Praxisbeispiel: Change veraltet Runbook** **Situation** Nach einem Update ändert sich der Neustartprozess eines Dienstes. **Problem** Das alte Runbook beschreibt noch die frühere Reihenfolge. **Risiko** Administratoren führen im Störungsfall falsche Schritte aus. **Verbesserung** Change-Abschluss enthält künftig: - betroffene Runbooks prüfen, - Knowledge Owner informieren, - Review-Datum setzen, - alte Version archivieren. --- **Praxisbeispiel: Major Incident** **Situation** Ein zentraler Dienst fällt aus. **Review zeigt** - Service Desk hatte keinen passenden Artikel, - Eskalationsweg war unklar, - Statusmeldung musste improvisiert werden, - Runbook für Wiederherstellung war veraltet. **Knowledge-Verbesserungen** - Service-Desk-Artikel erstellen, - Major-Incident-Kommunikationsvorlage ergänzen, - Runbook aktualisieren, - Known Error dokumentieren, - Service Map verlinken. --- **Typische Fehler** **Fehler 1** Knowledge Management wird getrennt von Incident, Problem und Change betrieben. --- **Fehler 2** Gelöste Incidents erzeugen kein wiederverwendbares Wissen. --- **Fehler 3** Problem Management dokumentiert Known Errors, aber der Service Desk findet sie nicht. --- **Fehler 4** Workarounds bleiben nur in Tickets. --- **Fehler 5** Changes aktualisieren Knowledge-Artikel nicht. --- **Fehler 6** Releases erzeugen neue Benutzerfragen, aber keine FAQ. --- **Fehler 7** Service Desk Feedback wird nicht bearbeitet. --- **Fehler 8** Knowledge-Artikel sind nicht mit Services oder CIs verknüpft. --- **Fehler 9** Sicherheitsartikel sind entweder zu offen oder zu stark eingeschränkt. --- **Fehler 10** Major-Incident-Lessons-Learned werden nicht in Knowledge übernommen. --- **Fehler 11** Artikel werden an Kennzahlen gemessen, aber nicht fachlich geprüft. --- **Fehler 12** Niemand ist verantwortlich für Pflege und Review. --- **Checkliste Incident zu Knowledge** - [ ] wiederkehrendes Fehlerbild erkannt - [ ] Lösung oder Workaround dokumentiert - [ ] passende Suchbegriffe ergänzt - [ ] Zielgruppe festgelegt - [ ] Service oder CI verknüpft - [ ] Eskalationsweg beschrieben - [ ] Risiken genannt - [ ] Knowledge-Artikel im Ticket verknüpft - [ ] Feedback aus Ticket berücksichtigt - [ ] Problem Management informiert, falls Muster erkennbar --- **Checkliste Problem zu Knowledge** - [ ] Known Error dokumentiert - [ ] Ursache oder wahrscheinliche Ursache beschrieben - [ ] Workaround beschrieben oder als nicht verfügbar gekennzeichnet - [ ] betroffene Versionen genannt - [ ] betroffene Services und CIs verknüpft - [ ] Service Desk Artikel erstellt - [ ] Benutzerinformation geprüft - [ ] dauerhafte Lösung oder Change vermerkt - [ ] Review-Datum gesetzt - [ ] Artikel nach Lösung aktualisiert oder archiviert --- **Checkliste Change zu Knowledge** - [ ] betroffene Artikel identifiziert - [ ] Benutzerartikel geprüft - [ ] Service-Desk-Artikel geprüft - [ ] Runbooks geprüft - [ ] Screenshots geprüft - [ ] Menüpfade geprüft - [ ] Known Errors geprüft - [ ] Workarounds geprüft - [ ] Service Desk informiert - [ ] Artikel nach Umsetzung aktualisiert - [ ] veraltete Artikel archiviert - [ ] Knowledge-Prüfung im Change Record dokumentiert --- **Checkliste Release zu Knowledge** - [ ] Release Notes erstellt - [ ] neue Funktionen beschrieben - [ ] geänderte Funktionen beschrieben - [ ] bekannte Einschränkungen dokumentiert - [ ] FAQ vorbereitet - [ ] Service Desk gebrieft - [ ] Benutzerkommunikation vorbereitet - [ ] neue Known Errors dokumentiert - [ ] alte Workarounds geprüft - [ ] Suchanfragen nach Release ausgewertet - [ ] Artikel nach Feedback verbessert --- **Checkliste Knowledge-Qualität im Zusammenspiel** - [ ] Artikel besitzt Owner - [ ] Review-Datum vorhanden - [ ] Zielgruppe klar - [ ] Service oder CI verknüpft - [ ] Problem oder Known Error verknüpft, falls relevant - [ ] Change oder Release verknüpft, falls relevant - [ ] Risiken und Grenzen beschrieben - [ ] Eskalationsweg klar - [ ] Zugriffsschutz passend - [ ] Feedbackmöglichkeit vorhanden - [ ] Nutzung wird ausgewertet - [ ] veraltete Inhalte werden archiviert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker stehen häufig genau dort, wo wichtiges Wissen entsteht. Im Arbeitsalltag bedeutet das: - Lösungen aus Incidents dokumentieren, - wiederkehrende Fehler an Problem Management melden, - Workarounds sicher beschreiben, - Known Errors technisch prüfen, - Runbooks für Betriebsaufgaben erstellen, - nach Changes Artikel aktualisieren, - Service Desk mit Prüfschritten unterstützen, - Configuration Items verknüpfen, - Benutzerwissen technisch korrekt vorbereiten, - und Lessons Learned in nutzbare Dokumentation übertragen. Gute Wissensarbeit macht technischen Betrieb stabiler, schneller und weniger abhängig von Einzelpersonen. --- **Zusammenfassung** > Incident liefert Erfahrung > ↓ > Problem Management erkennt Ursachen und Known Errors > ↓ > Knowledge Management macht Wissen nutzbar > ↓ > Service Desk verwendet Artikel im Alltag > ↓ > Change und Release verändern Services > ↓ > Knowledge wird aktualisiert > ↓ > Self-Service stellt Benutzerwissen bereit > ↓ > Feedback und Kennzahlen zeigen Lücken > ↓ > Continual Improvement verbessert Inhalte und Prozesse --- **Merksätze** > Knowledge Management verbindet Lernen mit täglichem IT-Betrieb. > Incidents liefern Hinweise auf fehlendes oder falsches Wissen. > Problem Management liefert Known Errors, Ursachen und Workarounds. > Changes und Releases müssen Knowledge aktualisieren. > Service Desk Feedback ist eine der wichtigsten Quellen für Wissensqualität. > Knowledge ohne Service- oder CI-Bezug ist schwerer nutzbar. > Lessons Learned sind nur wertvoll, wenn sie in nutzbares Wissen überführt werden. --- **Verwandte Seiten** - 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen - 7.2 Knowledge-Artikel, Runbooks und FAQ - 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk - 7.4 Self-Service und Benutzerwissen - Incident Management - Problem Management - Change Enablement - Release Management - Service Configuration Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Release Management - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Ergänzende Praxiseinordnung** - Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support **Einordnung** Die dargestellten: - Schnittstellen, - Informationsflüsse, - Rollenhinweise, - Checklisten, - Praxisbeispiele, - und Qualitätskriterien sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Knowledge-Prozessschnittstelle, - Artikelpflicht nach jedem Incident, - Review-Frequenz, - Verknüpfungsregel, - Rollenmatrix, - oder Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Zielgruppen, - Supportmodell, - Knowledge-Werkzeuge, - Sicherheitsanforderungen, - Problem Management, - Change-Modell, - Release-Modell, - Service Configuration Management, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 8. Service Level Management # 8.1 Service Level Management – Ziele, Begriffe und Grundlagen > **Kurz erklärt** > > Service Level Management sorgt dafür, dass Erwartungen an IT-Services klar beschrieben, messbar gemacht, vereinbart, überwacht und regelmäßig überprüft werden. > > Ziel ist nicht, möglichst viele Kennzahlen zu sammeln. > > Ziel ist, gemeinsam zu verstehen: > > - was ein Service leisten soll, > - welche Qualität erwartet wird, > - welche Ziele vereinbart sind, > - ob diese Ziele erreicht werden, > - und wo Verbesserungen notwendig sind. --- **Warum Service Level Management wichtig ist** Ohne klare Service Levels entstehen häufig Missverständnisse. Beispiele: - Benutzer erwarten sofortige Reaktion, IT arbeitet aber nach Prioritäten. - Fachbereiche erwarten hohe Verfügbarkeit, aber technische Abhängigkeiten sind nicht bekannt. - Supportzeiten sind unklar. - Wiederherstellungszeiten sind nicht vereinbart. - Servicequalität wird nur gefühlt bewertet. - Reports zeigen Zahlen, aber keine Aussage zum tatsächlichen Nutzen. - IT und Fachbereich sprechen über unterschiedliche Erwartungen. Service Level Management macht Erwartungen sichtbar und steuerbar. --- **Was ist ein Service Level?** Ein Service Level beschreibt ein vereinbartes oder erwartetes Qualitätsniveau eines Service. Beispiele: - Verfügbarkeit, - Reaktionszeit, - Wiederherstellungszeit, - Supportzeit, - Bearbeitungszeit, - Antwortzeit einer Anwendung, - Erfolgsquote eines Prozesses, - Erreichbarkeit des Service Desk, - Backup- und Restore-Ziele, - Benutzerzufriedenheit, - Stabilität nach Changes. Ein Service Level sollte verständlich, messbar und für den Service relevant sein. --- **Service Level Management ist mehr als SLA-Verwaltung** Ein häufiger Irrtum: > Service Level Management bedeutet nur, SLAs zu schreiben. Das ist zu kurz gedacht. Service Level Management umfasst auch: - Erwartungen verstehen, - Anforderungen erfassen, - Servicequalität definieren, - messbare Ziele vereinbaren, - passende Kennzahlen auswählen, - Ergebnisse überwachen, - Berichte erstellen, - Service Reviews durchführen, - Abweichungen analysieren, - Verbesserungen anstoßen, - und Kommunikation zwischen IT und Fachbereich verbessern. Ein SLA allein verbessert noch keinen Service. --- **Ziele von Service Level Management** Service Level Management soll: - Erwartungen zwischen IT und Kunden klären, - Servicequalität transparent machen, - realistische Ziele vereinbaren, - Serviceleistung messbar machen, - Risiken sichtbar machen, - Berichte verständlich gestalten, - Verbesserungen priorisieren, - Kundenzufriedenheit unterstützen, - geschäftliche Anforderungen berücksichtigen, - und IT-Leistung mit Servicewert verbinden. Wichtig ist, nicht nur technische Messwerte zu betrachten. Entscheidend ist, ob der Service den benötigten Nutzen liefert. --- **Kunde, Benutzer und Service Provider unterscheiden** | Rolle | Bedeutung | Beispiel | |---|---|---| | **Kunde** | entscheidet oder verantwortet den Bedarf an einem Service | Fachbereichsleitung | | **Benutzer** | nutzt den Service im Alltag | Mitarbeitende im Mitarbeiterportal | | **Service Provider** | stellt den Service bereit oder betreibt ihn | interne IT oder externer Anbieter | | **Service Owner** | verantwortet den Service innerhalb der Organisation | Owner für VPN-Service | | **Stakeholder** | ist vom Service betroffen oder beteiligt | Datenschutz, Security, Management | Kunden und Benutzer haben nicht immer dieselbe Perspektive. Ein Kunde achtet oft auf Nutzen, Kosten und Risiko. Ein Benutzer achtet stärker auf Alltagstauglichkeit, Geschwindigkeit und Verständlichkeit. --- **Service Level Agreement** Ein **Service Level Agreement (SLA)** ist eine Vereinbarung über Serviceziele zwischen Service Provider und Kunde. Ein SLA kann enthalten: - Servicebeschreibung, - Geltungsbereich, - Supportzeiten, - Verfügbarkeitsziele, - Reaktionszeiten, - Wiederherstellungsziele, - Prioritäten, - Messmethoden, - Berichtspflichten, - Verantwortlichkeiten, - Einschränkungen, - Ausnahmen, - Eskalationswege, - Review-Termine. Ein SLA sollte verständlich und realistisch sein. Ein SLA, das niemand liest oder versteht, hilft im Betrieb wenig. --- **Service Level Requirement** Ein **Service Level Requirement (SLR)** beschreibt eine Anforderung an die Servicequalität. Beispiele: - Der Service muss montags bis freitags von 08:00 bis 18:00 Uhr verfügbar sein. - Kritische Incidents müssen innerhalb von 30 Minuten bearbeitet werden. - Die Anwendung soll für normale Benutzeraktionen unter drei Sekunden reagieren. - Passwort-Requests sollen automatisiert bearbeitet werden. - Fachbereich benötigt monatlichen Servicebericht. SLRs helfen, Erwartungen zu erfassen, bevor sie als Serviceziele vereinbart werden. --- **Service Level Target** Ein **Service Level Target** ist ein konkretes Ziel innerhalb eines Service Levels. Beispiele: | Bereich | mögliches Ziel | |---|---| | **Verfügbarkeit** | Service ist während vereinbarter Servicezeit zu 99,5 Prozent verfügbar | | **Reaktion** | P1-Incidents werden innerhalb von 15 Minuten bearbeitet | | **Wiederherstellung** | P1-Incidents werden innerhalb von 4 Stunden gelöst oder umgangen | | **Bearbeitung** | Standardsoftware wird innerhalb von 2 Arbeitstagen bereitgestellt | | **Performance** | Startseite lädt im Normalbetrieb unter 3 Sekunden | | **Kommunikation** | Statusupdates bei Major Incidents alle 30 Minuten | Ein Ziel muss messbar und fachlich sinnvoll sein. --- **Operational Level Agreement** Ein **Operational Level Agreement (OLA)** beschreibt interne Vereinbarungen zwischen unterstützenden Teams. Beispiel: Das SLA verspricht dem Fachbereich eine Wiederherstellung innerhalb von 4 Stunden. Dafür braucht die IT interne Beiträge: - Service Desk reagiert innerhalb von 15 Minuten. - Netzwerkteam übernimmt Eskalationen innerhalb von 30 Minuten. - Datenbankteam prüft kritische Datenbankalarme innerhalb von 30 Minuten. - Plattformteam stellt Wiederherstellungsschritte bereit. Ein OLA unterstützt also die Einhaltung des SLA. --- **Underpinning Contract** Ein **Underpinning Contract** ist ein unterstützender Vertrag mit einem externen Lieferanten. Beispiele: - Provider für Internetanbindung, - Cloud-Anbieter, - Hardwarewartung, - Software-Support, - Rechenzentrumsdienstleister, - Telefonieanbieter. Wenn ein SLA von externen Leistungen abhängt, müssen Lieferantenverträge dazu passen. Beispiel: Ein interner Service kann keine Wiederherstellung innerhalb von 2 Stunden garantieren, wenn der externe Lieferant nur Reaktion am nächsten Arbeitstag zusagt. --- **SLA, OLA und Lieferantenvertrag im Zusammenhang** Kundenanforderung ↓ Service Level Requirement ↓ Service Level Agreement ↓ interne Operational Level Agreements ↓ externe Underpinning Contracts ↓ technische Umsetzung, Monitoring und Reporting Die Ziele müssen zusammenpassen. Sonst werden Versprechen gemacht, die technisch oder organisatorisch nicht erfüllbar sind. --- **Servicebeschreibung als Grundlage** Vor Service Levels muss klar sein, welcher Service gemeint ist. Eine Servicebeschreibung kann enthalten: - Name des Service, - Zweck, - Zielgruppe, - Leistungsumfang, - wichtige Funktionen, - Supportzeiten, - Kontaktweg, - Voraussetzungen, - Einschränkungen, - Service Owner, - beteiligte Supportgruppen, - Abhängigkeiten, - Sicherheitsanforderungen, - und relevante Dokumentation. Ohne klare Servicebeschreibung ist ein SLA schwer verständlich. --- **Beispiel: Servicebeschreibung VPN-Zugang** | Feld | Beispiel | |---|---| | **Service** | VPN-Zugang | | **Zweck** | sicherer Zugriff auf interne Ressourcen von außerhalb | | **Benutzer** | berechtigte Mitarbeitende | | **Supportzeit** | Montag bis Freitag, 08:00 bis 18:00 Uhr | | **Abhängigkeiten** | VPN-Gateway, MFA, Identity Provider, Internet | | **Service Owner** | IT-Infrastruktur | | **Einschränkung** | private Geräte nur nach Freigabe | | **Knowledge** | Benutzeranleitung VPN, Known Error VPN-Client | Solche Informationen helfen, Erwartungen und Ziele sauber zu formulieren. --- **Messbarkeit** Ein Service Level sollte messbar sein. Ungeeignet: > Der Service soll schnell sein. Besser: > Die Startseite soll während normaler Last innerhalb von drei Sekunden laden. Ungeeignet: > Der Support soll zeitnah reagieren. Besser: > Kritische Incidents werden innerhalb von 15 Minuten aufgenommen und priorisiert. Messbarkeit verhindert Diskussionen über unklare Begriffe. --- **Messmethode festlegen** Zu jedem Ziel sollte klar sein: - Was wird gemessen? - Wo wird gemessen? - Wann wird gemessen? - Wie oft wird gemessen? - Welche Datenquelle gilt? - Welche Ausnahmen gibt es? - Wer prüft die Daten? - Wie wird berichtet? Beispiel: Verfügbarkeit kann unterschiedlich gemessen werden: - aus Sicht des Servers, - aus Sicht der Anwendung, - aus Sicht eines Standortes, - aus Sicht externer Benutzer, - während Servicezeiten, - rund um die Uhr, - mit oder ohne geplante Wartung. Ohne Messmethode ist eine Kennzahl schwer vergleichbar. --- **Technische Kennzahl und Benutzererfahrung unterscheiden** Ein Service kann technisch verfügbar sein und trotzdem schlecht nutzbar sein. Beispiele: - Anwendung ist erreichbar, aber extrem langsam. - Login funktioniert, aber wichtige Funktion erzeugt Fehler. - Server läuft, aber Benutzer können wegen MFA-Problem nicht arbeiten. - Service Desk ist erreichbar, aber Benutzer erhalten keine hilfreiche Antwort. - Verfügbarkeit ist hoch, aber häufige kurze Störungen stören den Arbeitsablauf. Service Level Management sollte deshalb technische Messwerte und Benutzererfahrung zusammen betrachten. --- **Geeignete Kennzahlen** Geeignete Kennzahlen sind: - relevant, - verständlich, - messbar, - beeinflussbar, - mit Servicezielen verbunden, - und nicht nur intern technisch interessant. Beispiele: - Serviceverfügbarkeit, - Anzahl kritischer Incidents, - durchschnittliche Wiederherstellungszeit, - Einhaltung von Reaktionszeiten, - Benutzerzufriedenheit, - Ticketvolumen je Service, - Wiedereröffnungsquote, - Anzahl Incidents nach Changes, - Erfüllung von Request-Zielen, - häufige Serviceunterbrechungen. Eine Kennzahl sollte eine Entscheidung oder Verbesserung unterstützen. --- **Problematische Kennzahlen** Kennzahlen können falsche Anreize erzeugen. | Kennzahl | möglicher Fehlanreiz | |---|---| | viele geschlossene Tickets | schnelle Schließung statt guter Lösung | | sehr kurze Bearbeitungszeit | komplexe Fälle werden oberflächlich behandelt | | hohe SLA-Erfüllung | Ziele sind zu niedrig gesetzt | | wenige Eskalationen | notwendige Eskalationen werden vermieden | | hohe Verfügbarkeit | Benutzerprobleme werden übersehen | | viele Knowledge-Artikel | Menge statt Qualität | Kennzahlen müssen deshalb immer mit Kontext bewertet werden. --- **Service Level und Priorität** Service Levels hängen oft mit Prioritäten zusammen. Beispiel: | Priorität | typische Bedeutung | |---|---| | **P1** | kritischer Serviceausfall mit hoher Auswirkung | | **P2** | wichtige Funktion stark eingeschränkt | | **P3** | einzelner Benutzer oder begrenzte Auswirkung | | **P4** | niedrige Auswirkung oder Standardanfrage | Wichtig: Priorität sollte nicht nur aus Dringlichkeit entstehen. Sie sollte Auswirkung und Dringlichkeit gemeinsam betrachten. Ein einzelner Benutzer kann eine hohe Priorität haben, wenn eine geschäftskritische Rolle betroffen ist. --- **Reaktionszeit und Lösungszeit unterscheiden** | Begriff | Bedeutung | |---|---| | **Reaktionszeit** | Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung | | **Lösungszeit** | Zeit bis zur vollständigen Lösung oder vereinbarten Wiederherstellung | | **Wiederherstellungszeit** | Zeit bis der Service wieder nutzbar ist, ggf. mit Workaround | | **Bearbeitungszeit** | Zeit, in der aktiv am Vorgang gearbeitet wird | | **Wartezeit** | Zeit, in der auf Benutzer, Lieferant oder Genehmigung gewartet wird | Diese Begriffe sollten nicht vermischt werden. Ein Ticket kann schnell beantwortet, aber noch lange nicht gelöst sein. --- **Verfügbarkeit** Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist. Wichtige Fragen: - Welche Servicezeit gilt? - Welche Komponenten zählen? - Sind geplante Wartungen ausgeschlossen? - Wird aus Benutzer- oder Systemsicht gemessen? - Zählen kurze Unterbrechungen? - Wie wird Teilausfall bewertet? - Welche Standorte oder Benutzergruppen gelten? Beispiel: 99,5 Prozent Verfügbarkeit während Servicezeit bedeutet etwas anderes als 99,5 Prozent rund um die Uhr. --- **Servicezeit und Supportzeit unterscheiden** | Begriff | Bedeutung | |---|---| | **Servicezeit** | Zeitraum, in dem der Service vereinbarungsgemäß nutzbar sein soll | | **Supportzeit** | Zeitraum, in dem Unterstützung verfügbar ist | | **Wartungsfenster** | geplanter Zeitraum für Änderungen oder Wartung | | **Bereitschaft** | Unterstützung außerhalb normaler Zeiten bei definierten Fällen | Ein Service kann rund um die Uhr verfügbar sein, aber nur zu bestimmten Zeiten vollen Support haben. Diese Unterschiede müssen klar kommuniziert werden. --- **Wartungsfenster** Wartungsfenster sollten in Service Leveln berücksichtigt werden. Zu klären ist: - Wann darf geplant gewartet werden? - Wird Wartung aus Verfügbarkeitsberechnung ausgeschlossen? - Wie früh wird angekündigt? - Wer muss informiert werden? - Welche Services sind betroffen? - Welche Ausnahmen gelten? - Gibt es kritische Geschäftszeiten? Ein Wartungsfenster muss zur Nutzung des Services passen. Ein technisch bequemes Wartungsfenster kann fachlich ungeeignet sein. --- **Service Level und Benutzerkommunikation** Benutzer sollten wissen: - wann Support erreichbar ist, - wie sie Störungen melden, - welche Reaktionszeiten gelten, - wann Statusupdates erfolgen, - welche Informationen im Ticket benötigt werden, - welche Einschränkungen bestehen, - wo Self-Service-Informationen stehen. Unklare Kommunikation führt zu falschen Erwartungen. Service Level Management unterstützt deshalb auch verständliche Kommunikation. --- **Service Review** Ein Service Review ist eine regelmäßige Besprechung zur Servicequalität. Mögliche Inhalte: - erreichte Service Levels, - wichtige Incidents, - Problems und Known Errors, - Changes und Releases, - Benutzerfeedback, - SLA-Abweichungen, - Trends, - Risiken, - offene Verbesserungen, - kommende Änderungen, - Entscheidungen oder Prioritäten. Ein Service Review sollte nicht nur Zahlen vorlesen. Es sollte helfen, Servicequalität zu verstehen und zu verbessern. --- **Reporting** Service Level Reporting stellt Informationen zur Serviceleistung bereit. Gute Reports sind: - verständlich, - zielgruppengerecht, - servicebezogen, - nicht zu technisch, - mit Kontext versehen, - handlungsorientiert, - und regelmäßig. Ein guter Report beantwortet: - Was wurde erreicht? - Was wurde nicht erreicht? - Warum ist das wichtig? - Welche Risiken bestehen? - Welche Maßnahmen laufen? - Welche Entscheidung wird benötigt? --- **SLA-Abweichungen** Eine SLA-Abweichung bedeutet, dass ein vereinbartes Ziel nicht erreicht wurde. Zu prüfen ist: - Welches Ziel wurde verfehlt? - Wie groß war die Abweichung? - Welche Ursache liegt vor? - Welche Benutzer waren betroffen? - War ein Lieferant beteiligt? - Gab es einen Major Incident? - Gab es einen Change davor? - Ist ein Problem Record notwendig? - Welche Verbesserung wird geplant? Eine SLA-Abweichung sollte nicht nur berichtet, sondern analysiert werden. --- **Service Level und Continual Improvement** Service Level Management liefert wichtige Hinweise für Verbesserungen. Beispiele: - wiederholte SLA-Verfehlungen, - schlechte Benutzerzufriedenheit, - steigende Ticketzahlen, - viele Incidents nach Changes, - lange Wiederherstellungszeiten, - wiederkehrende Lieferantenprobleme, - fehlende Knowledge-Artikel, - unklare Servicebeschreibung. Diese Hinweise sollten in Continual Improvement einfließen. --- **Service Level und Kosten** Höhere Service Levels verursachen oft höhere Kosten. Beispiele: - 24/7-Support, - Hochverfügbarkeit, - redundante Infrastruktur, - schnellere Lieferantenreaktion, - häufigere Backups, - kürzere Wiederherstellungszeiten, - größere Bereitschaftsteams. Deshalb müssen Service Levels realistisch und wirtschaftlich sinnvoll sein. Nicht jeder Service benötigt maximale Verfügbarkeit. --- **Service Level und Risiko** Service Levels sollten zum Risiko passen. Fragen: - Was passiert bei Ausfall? - Welche Geschäftsprozesse sind betroffen? - Gibt es manuelle Ersatzverfahren? - Wie lange ist ein Ausfall tolerierbar? - Gibt es gesetzliche Anforderungen? - Gibt es Vertragsstrafen? - Gibt es Sicherheitsrisiken? - Welche Benutzergruppen sind betroffen? Ein Service mit hohem Risiko benötigt strengere Ziele als ein unkritischer interner Testservice. --- **Service Level und Lieferanten** Viele Services hängen von Lieferanten ab. Beispiele: - Internetprovider, - Cloud-Anbieter, - Softwarehersteller, - Hardwarewartung, - externer Support, - Rechenzentrum, - Telekommunikation. Service Level Management muss prüfen: - Passen Lieferantenverträge zu internen SLAs? - Sind Reaktionszeiten kompatibel? - Sind Eskalationswege klar? - Gibt es Berichtspflichten? - Sind Wartungsfenster abgestimmt? - Gibt es Abhängigkeiten von externen Statusseiten? Interne Zusagen dürfen externe Abhängigkeiten nicht ignorieren. --- **Service Level und Monitoring** Monitoring liefert Daten für Service Level Management. Beispiele: - Verfügbarkeit, - Antwortzeiten, - Fehlerraten, - Kapazität, - Zertifikatsablauf, - Backupstatus, - Schnittstellenzustand, - Login-Erfolg, - Transaktionsprüfung. Wichtig ist, dass Monitoring den Service aus relevanter Sicht misst. Ein Server-Ping allein reicht oft nicht aus, um Servicequalität zu bewerten. --- **Service Level und Service Configuration Management** Service Configuration Management hilft zu verstehen: - welche CIs einen Service unterstützen, - welche Abhängigkeiten bestehen, - welche Owner beteiligt sind, - welche Lieferanten unterstützen, - welche Changes einen Service beeinflussen, - welche CIs kritisch sind. Ohne Configuration-Daten sind Service Levels schwer realistisch zu bewerten. --- **Service Level und Incident Management** Incident Management liefert Daten über Servicequalität. Beispiele: - Anzahl Incidents je Service, - Prioritäten, - Reaktionszeiten, - Wiederherstellungszeiten, - Wiedereröffnungen, - Major Incidents, - Benutzerfeedback, - Eskalationen. Diese Daten helfen, SLA-Erfüllung und Verbesserungspotenzial zu bewerten. --- **Service Level und Problem Management** Problem Management unterstützt Service Level Management, wenn Ziele wiederholt verfehlt werden. Beispiele: - Service fällt wiederholt aus, - gleiche Ursache erzeugt viele Incidents, - Workaround wird ständig genutzt, - Lieferant verursacht wiederkehrende Störungen, - Monitoring erkennt Probleme zu spät. Dann reicht Reporting allein nicht aus. Die Ursache muss untersucht und dauerhaft verbessert werden. --- **Service Level und Change Enablement** Changes können Service Levels beeinflussen. Zu prüfen ist: - Wird ein kritischer Service geändert? - Gibt es Ausfallzeit? - Gibt es Wartungsfenster? - Werden Benutzer informiert? - Welche Service-Level-Ziele könnten betroffen sein? - Muss ein SLA wegen geplanter Wartung berücksichtigt werden? - Entstehen Risiken für Verfügbarkeit oder Performance? Change Enablement und Service Level Management sollten deshalb zusammenarbeiten. --- **Praxisbeispiel: Mitarbeiterportal** **Serviceziel** Das Mitarbeiterportal soll montags bis freitags von 08:00 bis 18:00 Uhr verfügbar sein. **Messung** - Verfügbarkeit aus Anwendungssicht, - Login-Funktion, - zentrale Startseite, - geplante Wartungen getrennt ausgewiesen. **Review** Im Monatsbericht wird sichtbar: - Verfügbarkeit erreicht, - aber viele Benutzer melden langsame Antwortzeiten. **Erkenntnis** Technische Verfügbarkeit allein reicht nicht. Performance und Benutzerfeedback müssen zusätzlich betrachtet werden. --- **Praxisbeispiel: Service Desk** **Serviceziel** Kritische Incidents werden innerhalb von 15 Minuten aufgenommen und priorisiert. **Messung** - Zeit von Ticketeingang bis qualifizierter Erstbearbeitung, - P1-Tickets, - Supportzeit, - Eskalationszeit. **Risiko** Wenn nur „erste Antwort“ gemessen wird, kann eine automatische Antwort die Kennzahl erfüllen, ohne echte Bearbeitung zu leisten. **Verbesserung** Gemessen wird qualifizierte Reaktion, nicht nur automatische Eingangsbestätigung. --- **Praxisbeispiel: Lieferantenabhängigkeit** **Serviceziel** Interner Service soll innerhalb von 4 Stunden wiederhergestellt werden. **Problem** Ein externer Lieferant garantiert nur Reaktion innerhalb von 8 Stunden. **Folge** Das interne Ziel ist nicht realistisch, wenn der Lieferant kritisch beteiligt ist. **Verbesserung** - Lieferantenvertrag prüfen, - interne SLA-Ziele anpassen, - technische Redundanz prüfen, - Workaround oder Notfallverfahren definieren. --- **Typische Fehler** **Fehler 1** SLA wird geschrieben, aber nicht aktiv genutzt. --- **Fehler 2** Service Levels sind technisch korrekt, aber für Benutzer nicht verständlich. --- **Fehler 3** Kennzahlen messen Systeme, aber nicht Servicequalität. --- **Fehler 4** Messmethode ist unklar. --- **Fehler 5** Servicezeit, Supportzeit und Wartungsfenster werden vermischt. --- **Fehler 6** Interne SLAs ignorieren Lieferantenabhängigkeiten. --- **Fehler 7** Zu hohe Ziele werden vereinbart, obwohl Ressourcen fehlen. --- **Fehler 8** SLA-Abweichungen werden nur berichtet, aber nicht analysiert. --- **Fehler 9** Benutzerfeedback wird ignoriert. --- **Fehler 10** Service Reviews bestehen nur aus Zahlen ohne Maßnahmen. --- **Fehler 11** Prioritäten werden nur nach Lautstärke des Benutzers gesetzt. --- **Fehler 12** Service Level Management wird als reine Kontrollfunktion verstanden. --- **Checkliste Service Level definieren** - [ ] Service eindeutig beschrieben - [ ] Zielgruppe bekannt - [ ] Kunde und Benutzer unterschieden - [ ] Service Owner benannt - [ ] Supportzeit festgelegt - [ ] Servicezeit festgelegt - [ ] wichtigste Funktionen beschrieben - [ ] Abhängigkeiten bekannt - [ ] Risiken bewertet - [ ] relevante Ziele festgelegt - [ ] Messmethode definiert - [ ] Reporting und Review geplant --- **Checkliste SLA-Inhalte** - [ ] Servicebeschreibung - [ ] Geltungsbereich - [ ] Servicezeiten - [ ] Supportzeiten - [ ] Zielwerte - [ ] Prioritätsdefinition - [ ] Reaktionszeiten - [ ] Wiederherstellungsziele - [ ] Messmethoden - [ ] Ausnahmen - [ ] Wartungsfenster - [ ] Rollen und Verantwortlichkeiten - [ ] Eskalationswege - [ ] Reporting - [ ] Review-Termine --- **Checkliste Messung** - [ ] Kennzahl ist relevant - [ ] Datenquelle ist klar - [ ] Messzeitraum ist klar - [ ] Servicezeit ist berücksichtigt - [ ] geplante Wartung ist geregelt - [ ] Benutzerperspektive ist berücksichtigt - [ ] technische Messung ist nachvollziehbar - [ ] Ausnahmen sind definiert - [ ] Ergebnis ist verständlich berichtbar - [ ] Kennzahl unterstützt Verbesserung --- **Checkliste Service Review** - [ ] vereinbarte Ziele geprüft - [ ] SLA-Abweichungen analysiert - [ ] Major Incidents betrachtet - [ ] wiederkehrende Incidents betrachtet - [ ] Problems und Known Errors geprüft - [ ] Changes und Releases berücksichtigt - [ ] Benutzerfeedback einbezogen - [ ] Lieferantenleistung bewertet - [ ] Risiken besprochen - [ ] Verbesserungsmaßnahmen festgelegt - [ ] Verantwortliche benannt - [ ] nächster Review-Termin geplant --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker unterstützen Service Level Management durch technische Daten und praktische Betriebserfahrung. Im Arbeitsalltag bedeutet das: - Services und Abhängigkeiten verstehen, - Monitoringdaten richtig einordnen, - Incidents sauber dokumentieren, - Wiederherstellungszeiten nachvollziehbar erfassen, - Changes mit Servicewirkung bewerten, - technische Grenzen realistisch erklären, - Workarounds und Known Errors berücksichtigen, - und Verbesserungen aus wiederkehrenden Abweichungen ableiten. Service Level Management hilft dabei, technische Arbeit mit Servicequalität und Benutzererwartung zu verbinden. --- **Zusammenfassung** > Service verstehen > ↓ > Erwartungen und Anforderungen erfassen > ↓ > Service Level Requirements formulieren > ↓ > realistische Ziele vereinbaren > ↓ > Messmethoden festlegen > ↓ > SLA, OLA und Lieferantenabhängigkeiten abstimmen > ↓ > Serviceleistung überwachen > ↓ > verständlich berichten > ↓ > Service Reviews durchführen > ↓ > Abweichungen analysieren > ↓ > Verbesserungen anstoßen --- **Merksätze** > Service Level Management klärt Erwartungen und macht Servicequalität steuerbar. > Ein SLA verbessert nichts, wenn es nicht verstanden, gemessen und genutzt wird. > Technische Verfügbarkeit ist nicht automatisch gute Benutzererfahrung. > Servicezeit, Supportzeit und Wartungsfenster müssen klar getrennt werden. > Interne Ziele müssen zu internen Fähigkeiten und Lieferantenverträgen passen. > Kennzahlen brauchen Kontext, sonst erzeugen sie falsche Schlüsse. > Service Reviews sollen Verbesserungen auslösen, nicht nur Zahlen präsentieren. --- **Verwandte Seiten** - 8.2 SLA, SLR, OLA und Underpinning Contracts - 8.3 Kennzahlen, Messmethoden und Reporting - 8.4 Service Reviews und Continual Improvement - 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management - Incident Management - Problem Management - Change Enablement - Service Configuration Management - Knowledge Management - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Supplier Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - SLA-Beispiele, - Begriffe, - Messfragen, - Review-Inhalte, - Checklisten, - Prioritätsbeispiele, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - SLA-Vorlage, - Kennzahlenliste, - Zielwerttabelle, - Prioritätsmatrix, - Review-Frequenz, - oder Reporting-Struktur für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Kunden, - Benutzergruppen, - Risiken, - Servicezeiten, - Supportmodell, - Lieferanten, - Monitoring, - Organisation, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 8.2 SLA, SLR, OLA und Underpinning Contracts > **Kurz erklärt** > > Service Level Management arbeitet mit mehreren Arten von Vereinbarungen und Anforderungen. > > **SLR** beschreibt, welche Servicequalität benötigt wird. > > **SLA** beschreibt, welche Servicequalität zwischen Kunde und Service Provider vereinbart ist. > > **OLA** beschreibt interne Unterstützungsvereinbarungen zwischen Teams. > > **Underpinning Contracts** beschreiben unterstützende Verträge mit externen Lieferanten. > > Diese Ebenen müssen zusammenpassen, sonst werden Serviceziele vereinbart, die praktisch nicht erfüllbar sind. --- **Warum diese Begriffe wichtig sind** Ein IT-Service wird selten von nur einer Stelle erbracht. Beispiel: Der Service „Mitarbeiterportal“ kann abhängig sein von: - Anwendungsteam, - Datenbankteam, - Netzwerkteam, - Identity Management, - Service Desk, - Monitoring, - Cloud-Anbieter, - Softwarehersteller, - Internetprovider, - und externem Support. Wenn ein SLA dem Fachbereich eine schnelle Wiederherstellung verspricht, müssen alle unterstützenden Teams und Lieferanten dazu beitragen können. Deshalb reicht es nicht, nur ein SLA zu schreiben. Die Vereinbarungen im Hintergrund müssen ebenfalls passen. --- **Grundmodell** Service Level Requirement ↓ beschreibt benötigte Servicequalität ↓ Service Level Agreement ↓ vereinbart Servicequalität mit dem Kunden ↓ Operational Level Agreements ↓ regeln interne Unterstützungsleistungen ↓ Underpinning Contracts ↓ sichern externe Lieferantenleistungen ab ↓ Monitoring, Reporting und Service Reviews ↓ prüfen, ob Ziele erreicht werden Alle Ebenen müssen aufeinander abgestimmt sein. --- **Service Level Requirement** Ein **Service Level Requirement (SLR)** beschreibt eine Anforderung an die Servicequalität. SLRs entstehen häufig aus: - fachlichen Anforderungen, - Benutzererwartungen, - gesetzlichen Vorgaben, - Sicherheitsanforderungen, - Geschäftsprozessen, - Risikobewertungen, - bisherigen Incidents, - Service Reviews, - Projekten, - neuen Services, - oder geänderten Arbeitsweisen. Ein SLR ist noch nicht automatisch eine verbindliche Vereinbarung. Es ist zunächst eine Anforderung, die geprüft, bewertet und verhandelt werden muss. --- **Beispiele für Service Level Requirements** | Bereich | Beispiel für SLR | |---|---| | **Verfügbarkeit** | Mitarbeiterportal soll während Geschäftszeiten verfügbar sein | | **Support** | Benutzer benötigen Support montags bis freitags von 08:00 bis 18:00 Uhr | | **Reaktion** | kritische Störungen sollen sehr schnell aufgenommen werden | | **Wiederherstellung** | zentrale Störungen sollen innerhalb weniger Stunden umgangen oder behoben werden | | **Performance** | häufig genutzte Seiten sollen zügig laden | | **Requests** | Standardsoftware soll innerhalb weniger Arbeitstage bereitgestellt werden | | **Kommunikation** | bei größeren Störungen sollen regelmäßige Statusupdates erfolgen | | **Sicherheit** | Sicherheitsvorfälle sollen sofort eskaliert werden | SLRs sollten so formuliert sein, dass sie später in messbare Ziele überführt werden können. --- **SLR prüfen** Nicht jede Anforderung kann unverändert übernommen werden. Zu prüfen ist: - Ist die Anforderung fachlich notwendig? - Ist sie technisch erreichbar? - Ist sie wirtschaftlich sinnvoll? - Sind Ressourcen vorhanden? - Passen interne Teams dazu? - Passen Lieferantenverträge dazu? - Gibt es Abhängigkeiten? - Ist die Messung möglich? - Welche Risiken entstehen? - Welche Alternative gibt es? Service Level Management hilft, Anforderungen realistisch zu machen. --- **Beispiel: unrealistisches SLR** **Anforderung** > Das System soll immer verfügbar sein. **Problem** „Immer“ ist unklar und praktisch kaum erreichbar. Besser prüfen: - Welche Geschäftszeiten sind kritisch? - Welche Ausfallzeit ist tolerierbar? - Welche Funktionen sind besonders wichtig? - Welche Kosten wären für Hochverfügbarkeit notwendig? - Gibt es manuelle Ersatzverfahren? - Welche Lieferantenabhängigkeiten bestehen? Daraus kann ein realistisches SLA-Ziel entstehen. --- **Service Level Agreement** Ein **Service Level Agreement (SLA)** ist eine Vereinbarung zwischen Service Provider und Kunde über die erwartete und vereinbarte Servicequalität. Ein SLA beschreibt nicht nur technische Werte. Es beschreibt, was der Service leisten soll und wie die Leistung bewertet wird. Typische Inhalte: - Servicebeschreibung, - Geltungsbereich, - Zielgruppe, - Servicezeiten, - Supportzeiten, - Verfügbarkeitsziele, - Reaktionszeiten, - Wiederherstellungsziele, - Prioritätsdefinitionen, - Messmethoden, - Ausnahmen, - Wartungsfenster, - Rollen und Verantwortlichkeiten, - Eskalationswege, - Reporting, - Review-Termine. Ein SLA sollte verständlich, realistisch und überprüfbar sein. --- **SLA ist eine Vereinbarung, kein Wunschzettel** Ein SLA darf keine Ziele enthalten, die nicht erbracht werden können. Ungeeignet: > Fachbereich wünscht 24/7-Verfügbarkeit, obwohl kein 24/7-Betrieb, keine Bereitschaft und kein passender Lieferantenvertrag existieren. Besser: > Verfügbarkeitsziel, Supportzeiten, Bereitschaft und Lieferantenleistungen werden gemeinsam geprüft und realistisch vereinbart. Ein SLA muss zu Fähigkeiten, Budget, Risiko und Organisation passen. --- **Arten von SLAs** Mögliche SLA-Formen: | SLA-Art | Beschreibung | Beispiel | |---|---|---| | **Servicebezogenes SLA** | gilt für einen bestimmten Service | SLA für VPN-Zugang | | **Kundenbezogenes SLA** | gilt für einen bestimmten Kunden oder Fachbereich | SLA für Personalabteilung | | **Mehrstufiges SLA** | kombiniert allgemeine und spezifische Vereinbarungen | allgemeine IT-Supportregeln plus spezielle Ziele für kritischen Service | | **Interner Service Level** | wird intern vereinbart und berichtet | interner Service Desk Support | | **Externer SLA-Bezug** | hängt von Lieferantenvertrag ab | Cloud-Service mit Provider-SLA | Die passende Form hängt von Organisation und Servicekatalog ab. --- **SLA-Inhalte verständlich formulieren** Ein SLA sollte nicht nur juristisch oder technisch formuliert sein. Ungeeignet: > HTTP-Endpunkt antwortet in 99,7 Prozent der Messintervalle mit Statuscode 200. Besser ergänzt: > Der Service gilt als verfügbar, wenn Benutzer die Startseite öffnen und sich anmelden können. Technisches Monitoring prüft zusätzlich den HTTP-Status und die Login-Funktion. Technische Definitionen sind wichtig. Aber der Servicebezug muss verständlich bleiben. --- **Geltungsbereich** Der Geltungsbereich beschreibt, wofür das SLA gilt und wofür nicht. Zu klären ist: - Welche Services sind eingeschlossen? - Welche Benutzergruppen sind eingeschlossen? - Welche Standorte sind eingeschlossen? - Welche Zeiten gelten? - Welche Funktionen gehören zum Service? - Welche Systeme sind ausgeschlossen? - Welche Voraussetzungen müssen Benutzer erfüllen? - Welche Abhängigkeiten bestehen? Ein unklarer Geltungsbereich führt später zu Streit über Erwartungen. --- **Beispiel Geltungsbereich** **Service** VPN-Zugang für berechtigte Mitarbeitende. **Eingeschlossen** - VPN-Client, - VPN-Gateway, - Anmeldung über zentrale Identität, - MFA, - Zugriff auf freigegebene interne Ressourcen. **Nicht eingeschlossen** - private Internetverbindung des Benutzers, - nicht freigegebene Privatgeräte, - externe Websites, - lokale Heimnetzwerkprobleme. Diese Abgrenzung macht Erwartungen klarer. --- **Servicezeit** Die Servicezeit beschreibt, wann ein Service vereinbarungsgemäß nutzbar sein soll. Beispiele: - Montag bis Freitag, 08:00 bis 18:00 Uhr, - Montag bis Samstag, 06:00 bis 22:00 Uhr, - 24 Stunden täglich, - nur während Geschäftszeiten, - nur während Schulungszeiten, - nur innerhalb definierter Projektphasen. Servicezeit ist wichtig für Verfügbarkeitsmessung und Wartungsplanung. --- **Supportzeit** Die Supportzeit beschreibt, wann Unterstützung verfügbar ist. Beispiele: - Service Desk erreichbar von 08:00 bis 17:00 Uhr, - Bereitschaft für P1-Incidents außerhalb der Geschäftszeit, - Lieferantensupport montags bis freitags, - erweiterter Support für kritische Zeiträume. Ein Service kann auch außerhalb der Supportzeit verfügbar sein. Aber bei Störungen gelten dann möglicherweise andere Reaktionszeiten. --- **Servicezeit und Supportzeit unterscheiden** | Begriff | Bedeutung | Beispiel | |---|---|---| | **Servicezeit** | Service soll nutzbar sein | Mitarbeiterportal 24/7 erreichbar | | **Supportzeit** | Hilfe ist verfügbar | Service Desk 08:00 bis 18:00 Uhr | | **Wartungsfenster** | geplante Änderungen erlaubt | Sonntag 22:00 bis 23:00 Uhr | | **Bereitschaft** | definierte Unterstützung außerhalb normaler Zeiten | P1-Rufbereitschaft nachts | Diese Begriffe dürfen nicht vermischt werden. --- **Wartungsfenster** Wartungsfenster regeln, wann geplante Arbeiten stattfinden dürfen. Zu klären ist: - wann Wartung erlaubt ist, - wie früh sie angekündigt wird, - ob sie aus Verfügbarkeitsmessung ausgeschlossen wird, - welche Services betroffen sein dürfen, - wer informiert wird, - ob Fachbereiche zustimmen müssen, - welche Ausnahmen gelten. Ein Wartungsfenster sollte zur Nutzung des Services passen. Ein technisch bequemes Zeitfenster kann fachlich ungeeignet sein. --- **Verfügbarkeit im SLA** Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist. Wichtig ist die genaue Definition. Zu klären ist: - Wird während Servicezeit oder rund um die Uhr gemessen? - Zählen geplante Wartungen mit? - Wird aus Benutzerperspektive gemessen? - Welche Funktionen müssen verfügbar sein? - Wie werden Teilausfälle bewertet? - Welche Standorte zählen? - Welche Datenquelle wird verwendet? - Wie werden externe Abhängigkeiten behandelt? Ohne klare Definition ist eine Verfügbarkeitszahl schwer interpretierbar. --- **Beispiel Verfügbarkeitsziel** Ungeeignet: > Service ist zu 99,9 Prozent verfügbar. Besser: > Der Service gilt während der vereinbarten Servicezeit als verfügbar, wenn Benutzer die Startseite öffnen, sich anmelden und die Hauptfunktion nutzen können. Geplante Wartungsfenster werden separat ausgewiesen. Diese Definition ist für Technik und Benutzer klarer. --- **Reaktionszeit** Reaktionszeit beschreibt die Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung. Wichtig: Eine automatische Eingangsbestätigung ist nicht automatisch eine qualifizierte Reaktion. Beispiele: - P1-Incident wird innerhalb von 15 Minuten qualifiziert bearbeitet. - P2-Incident wird innerhalb von 60 Minuten geprüft. - Standardanfrage erhält innerhalb eines Arbeitstages eine Rückmeldung. Reaktionszeit sollte mit Priorität und Supportzeit verknüpft sein. --- **Wiederherstellungszeit** Wiederherstellungszeit beschreibt, bis wann ein Service wieder nutzbar sein soll. Das kann bedeuten: - vollständige Lösung, - temporäre Wiederherstellung, - nutzbarer Workaround, - Wiederherstellung einer Kernfunktion, - Rollback auf vorherigen Stand. Wichtig ist, genau zu definieren, was als wiederhergestellt gilt. Beispiel: Ein Workaround kann den Benutzer wieder arbeitsfähig machen, obwohl die Ursache noch nicht dauerhaft behoben ist. --- **Lösungszeit** Lösungszeit beschreibt die Zeit bis zur endgültigen Lösung. Sie ist nicht immer identisch mit Wiederherstellungszeit. Beispiel: Ein bekannter Fehler kann durch Workaround kurzfristig umgangen werden. Die dauerhafte Lösung erfolgt erst durch einen späteren Change. Dann ist der Service wiederhergestellt, aber das Problem noch nicht endgültig gelöst. --- **Prioritäten im SLA** SLAs enthalten häufig Prioritätsklassen. Eine Priorität sollte aus Auswirkung und Dringlichkeit entstehen. | Auswirkung | Dringlichkeit | mögliche Priorität | |---|---|---| | viele Benutzer betroffen | sofortige Arbeit blockiert | P1 | | wichtiger Fachbereich betroffen | kurzfristige Bearbeitung nötig | P2 | | einzelner Benutzer betroffen | Arbeit teilweise möglich | P3 | | geringe Auswirkung | kein Zeitdruck | P4 | Die konkrete Matrix muss zur Organisation passen. Wichtig ist, Priorität nicht nur nach Lautstärke oder subjektivem Druck zu vergeben. --- **Auswirkung** Auswirkung beschreibt, wie stark ein Incident, Request oder Problem den Service oder die Organisation betrifft. Kriterien: - Anzahl betroffener Benutzer, - Kritikalität des Services, - betroffener Geschäftsprozess, - Standort, - Sicherheitsrisiko, - finanzielle Auswirkung, - gesetzliche oder vertragliche Folgen, - Reputationsrisiko, - verfügbare Alternativen. Ein einzelner Benutzer kann hohe Auswirkung haben, wenn eine kritische Rolle betroffen ist. --- **Dringlichkeit** Dringlichkeit beschreibt, wie schnell gehandelt werden muss. Kriterien: - Arbeitsfähigkeit, - Frist, - Sicherheitsbezug, - drohende Eskalation, - betroffene Geschäftszeit, - kommende Termine, - vorhandener Workaround, - zeitkritischer Prozess. Hohe Dringlichkeit ohne hohe Auswirkung führt nicht automatisch zu höchster Priorität. Beides muss gemeinsam bewertet werden. --- **Messmethoden im SLA** Ein SLA-Ziel braucht eine klare Messmethode. Zu definieren ist: - Startzeitpunkt, - Endzeitpunkt, - Messzeitraum, - Datenquelle, - Berechnungslogik, - Ausnahmen, - Verantwortlicher für Messung, - Reporting-Form, - Prüfintervall. Beispiel: Bei Reaktionszeit muss klar sein, ob die Zeit ab Ticketeingang, ab Kategorisierung oder ab Supportzeitbeginn zählt. --- **Ausnahmen** SLAs sollten Ausnahmen definieren. Beispiele: - geplante Wartungsfenster, - höhere Gewalt, - Ausfall externer Netze außerhalb der Verantwortung, - Benutzer reagiert nicht, - fehlende Genehmigung, - falsche oder unvollständige Anfrage, - Sicherheitsvorfall mit Sonderprozess, - Lieferantenverzug außerhalb vereinbarter Leistung, - Testsysteme ohne SLA. Ausnahmen dürfen nicht genutzt werden, um Verantwortung zu vermeiden. Sie müssen nachvollziehbar sein. --- **OLA** Ein **Operational Level Agreement (OLA)** ist eine interne Vereinbarung zwischen Teams oder Organisationseinheiten. Ziel: > Interne Teams stellen gemeinsam sicher, dass ein SLA erfüllt werden kann. Beispiele: - Service Desk nimmt P1-Incidents innerhalb von 15 Minuten auf. - Netzwerkteam übernimmt P1-Eskalationen innerhalb von 30 Minuten. - Datenbankteam prüft kritische Datenbankalarme innerhalb von 30 Minuten. - Plattformteam stellt Restore-Unterstützung innerhalb definierter Zeit bereit. - Fachteam aktualisiert Knowledge-Artikel nach Changes. OLAs sind interne Zusagen, keine Kundenzusagen. --- **Warum OLAs wichtig sind** Ein SLA kann nur eingehalten werden, wenn interne Abläufe funktionieren. Ohne OLA entstehen Probleme: - Service Desk wartet zu lange auf Fachteam, - Eskalationswege sind unklar, - Teams priorisieren unterschiedlich, - interne Wartezeiten werden nicht sichtbar, - SLA wird verfehlt, obwohl einzelne Teams „ihren Teil“ erledigt haben, - Verantwortung wird hin- und hergeschoben. OLAs machen interne Beiträge transparent. --- **Beispiel OLA-Kette** SLA: > P1-Incident wird innerhalb von 4 Stunden wiederhergestellt. Dafür notwendige OLA-Beiträge: | Team | interner Beitrag | |---|---| | **Service Desk** | Ticket aufnehmen, priorisieren, Kommunikation starten | | **Monitoring** | Alarm korrekt auslösen | | **Plattformteam** | Serverzustand prüfen | | **Datenbankteam** | Datenbankverfügbarkeit prüfen | | **Netzwerkteam** | Netz- und Firewallpfade prüfen | | **Service Owner** | fachliche Auswirkung bewerten | | **Kommunikation** | Statusupdates unterstützen | Nur zusammen kann das SLA erreicht werden. --- **OLA-Inhalte** Ein OLA kann enthalten: - beteiligte Teams, - unterstützte Services, - interne Reaktionszeiten, - Eskalationswege, - Übergabepunkte, - Verantwortlichkeiten, - Kommunikationsregeln, - benötigte Informationen, - Betriebszeiten, - Bereitschaftsregeln, - Dokumentationspflichten, - Knowledge-Pflege, - Review-Termine. Ein OLA muss praktikabel sein. Zu komplizierte interne Vereinbarungen werden im Alltag nicht genutzt. --- **OLA und Ticketübergabe** OLAs helfen besonders bei Übergaben. Zu klären ist: - Wann darf eskaliert werden? - Welche Informationen muss das Ticket enthalten? - Wer übernimmt Verantwortung? - Wie schnell wird reagiert? - Wann geht das Ticket zurück? - Wie wird der Benutzer informiert? - Wer dokumentiert die Lösung? - Wann wird Problem Management informiert? Klare Übergaben verhindern Verzögerungen und Doppelarbeit. --- **Underpinning Contract** Ein **Underpinning Contract** ist ein unterstützender Vertrag mit einem externen Lieferanten. Er kann Leistungen regeln wie: - Supportzeiten, - Reaktionszeiten, - Wiederherstellungszeiten, - Verfügbarkeit, - Wartungsfenster, - Eskalationswege, - Berichtspflichten, - Sicherheitsanforderungen, - Datenschutz, - Vertraulichkeit, - Vertragsstrafen, - Kündigungsfristen. Underpinning Contracts müssen zu den internen SLAs passen. --- **Warum Underpinning Contracts wichtig sind** Viele IT-Services hängen von externen Leistungen ab. Beispiele: - Internetverbindung, - Cloud-Plattform, - Software-Support, - Hardwarewartung, - Rechenzentrum, - Telefonie, - SaaS-Anwendung, - Sicherheitsdienstleister, - Druckdienstleister. Wenn ein externer Vertrag schwächer ist als das interne SLA, entsteht ein Risiko. Die Organisation verspricht dann möglicherweise mehr, als sie liefern kann. --- **Beispiel Lieferantenabhängigkeit** Interner SLA-Wunsch: > Fachanwendung bei kritischer Störung innerhalb von 4 Stunden wiederherstellen. Externer Softwarevertrag: > Hersteller reagiert innerhalb von 1 Arbeitstag. Risiko: Wenn die Ursache beim Hersteller liegt, kann das interne Ziel nicht sicher eingehalten werden. Mögliche Maßnahmen: - Lieferantenvertrag verbessern, - internes Ziel anpassen, - Workaround definieren, - technische Redundanz schaffen, - eigenes Fachwissen aufbauen, - Risiko bewusst akzeptieren. --- **SLA, OLA und Underpinning Contract abstimmen** Zu prüfen ist: - Unterstützen OLAs das SLA? - Unterstützen Lieferantenverträge das SLA? - Sind Supportzeiten kompatibel? - Sind Eskalationswege klar? - Gibt es Lücken zwischen interner und externer Leistung? - Sind Messmethoden vergleichbar? - Sind Wartungsfenster abgestimmt? - Sind Sicherheitsanforderungen berücksichtigt? - Sind Berichtspflichten geregelt? Eine SLA-Zusage darf nicht isoliert betrachtet werden. --- **Typische Lücke zwischen SLA und OLA** SLA: > P2-Incidents werden innerhalb von 8 Stunden gelöst. Interne Realität: - Service Desk ist schnell, - Fachteam reagiert aber erst nach 2 Arbeitstagen, - keine interne Eskalationsregel, - kein definierter Owner. Folge: Das SLA wird regelmäßig verfehlt. Verbesserung: - OLA mit Fachteam definieren, - Eskalationsweg festlegen, - Prioritäten abstimmen, - Knowledge-Artikel bereitstellen, - Monitoring verbessern. --- **Typische Lücke zwischen SLA und Lieferantenvertrag** SLA: > Service ist Montag bis Freitag von 08:00 bis 18:00 Uhr unterstützt. Lieferantenvertrag: > Hersteller-Support nur von 09:00 bis 17:00 Uhr. Folge: Bei Störung um 17:30 Uhr kann interne IT das SLA möglicherweise nicht erfüllen. Verbesserung: - Vertrag anpassen, - interne Kompetenz erweitern, - SLA-Ziel anpassen, - Einschränkung klar kommunizieren, - Notfallverfahren definieren. --- **Mehrere Lieferanten** Ein Service kann von mehreren Lieferanten abhängen. Beispiel: - Cloud-Anbieter, - Softwarehersteller, - Internetprovider, - externer Identity-Dienst, - Hardwarewartung, - Sicherheitsdienstleister. Dann muss klar sein: - welcher Lieferant wofür zuständig ist, - wer zuerst kontaktiert wird, - welche Eskalationswege gelten, - welche Vertragszeiten gelten, - welche Nachweise benötigt werden, - wer den Gesamtservice koordiniert. Der Benutzer interessiert sich nicht für Lieferantengrenzen. Für ihn zählt, ob der Service funktioniert. --- **SLA und Supplier Management** Supplier Management stellt sicher, dass Lieferantenleistungen die Serviceziele unterstützen. Wichtige Fragen: - Welche Lieferanten sind kritisch? - Welche Services hängen von ihnen ab? - Passen Vertragsziele zu SLAs? - Werden Lieferantenleistungen gemessen? - Gibt es regelmäßige Reviews? - Gibt es Eskalationswege? - Gibt es Risiken durch einzelne Lieferanten? - Gibt es Alternativen oder Notfallpläne? Service Level Management und Supplier Management müssen eng zusammenarbeiten. --- **SLA und Service Configuration Management** Service Configuration Management zeigt, welche CIs und Lieferanten einen Service unterstützen. Das hilft bei SLA-Planung. Beispiele: - Service hängt von Cloud-Datenbank ab, - Service nutzt externen Identity Provider, - Service nutzt bestimmten Internetprovider, - Service nutzt internes Datenbankteam, - Service nutzt Zertifikate mit Ablaufdatum, - Service nutzt Monitoring und Backup. Ohne diese Abhängigkeiten können SLAs falsch bewertet werden. --- **SLA und Monitoring** SLA-Ziele müssen messbar sein. Monitoring liefert Daten für: - Verfügbarkeit, - Antwortzeiten, - Fehlerraten, - Login-Funktion, - Schnittstellenstatus, - Backupstatus, - Kapazität, - Zertifikatsablauf, - Servicezustand. Wichtig ist: Monitoring muss die vereinbarte Servicequalität abbilden. Ein Server-Ping reicht nicht aus, wenn Benutzer sich trotzdem nicht anmelden können. --- **SLA und Reporting** SLA-Reports sollten zeigen: - erreichte Ziele, - verfehlte Ziele, - Ursachen für Abweichungen, - betroffene Services, - betroffene Benutzer, - Trends, - Risiken, - Lieferantenbeiträge, - geplante Verbesserungen. Ein guter Report erklärt nicht nur, ob ein Ziel rot oder grün ist. Er erklärt, warum es relevant ist und was daraus folgt. --- **SLA und Service Review** Im Service Review werden SLA, OLA und Lieferantenleistung gemeinsam betrachtet. Mögliche Fragen: - Wurden SLA-Ziele erreicht? - Welche OLAs haben gut funktioniert? - Wo gab es interne Verzögerungen? - Welche Lieferanten haben Ziele verfehlt? - Welche Incidents waren besonders relevant? - Welche Problems sind offen? - Welche Changes beeinflussen Ziele? - Müssen Zielwerte angepasst werden? - Müssen Verträge angepasst werden? - Welche Verbesserungen werden beschlossen? Service Reviews verbinden Messung mit Entscheidung. --- **SLA-Änderungen** SLAs sollten angepasst werden, wenn sich Rahmenbedingungen ändern. Auslöser: - neuer Service, - geänderter Geschäftsprozess, - neue Benutzergruppe, - geänderte Betriebszeiten, - neue Lieferanten, - Cloud-Migration, - höhere Kritikalität, - wiederholte SLA-Abweichungen, - neue gesetzliche Anforderungen, - geänderte Sicherheitslage, - geändertes Budget. Ein SLA ist kein dauerhaft unveränderliches Dokument. Es muss regelmäßig überprüft werden. --- **SLA-Verhandlung** Bei SLA-Verhandlungen sollten folgende Punkte offen besprochen werden: - gewünschte Servicequalität, - tatsächlicher Bedarf, - technische Machbarkeit, - Kosten, - Risiken, - Lieferantenabhängigkeiten, - Supportzeiten, - Wartungsfenster, - Messmethoden, - Ausnahmen, - Alternativen. Wichtig: Nicht jede hohe Anforderung ist automatisch sinnvoll. Manchmal ist ein realistischer Service Level mit gutem Workaround besser als ein teures Maximalziel. --- **Service Level und Kosten** Höhere Service Levels können höhere Kosten verursachen. Beispiele: - 24/7-Bereitschaft, - redundante Systeme, - schnellerer Lieferantensupport, - Hochverfügbarkeitsarchitektur, - zusätzliche Monitoringprüfungen, - häufigere Backups, - kürzere Restore-Zeiten, - mehr Personal, - mehr Tests. Service Level Management macht sichtbar, welche Qualität benötigt wird und was sie kostet. --- **Service Level und Risikoakzeptanz** Nicht alle Risiken lassen sich vollständig vermeiden. Wenn ein niedrigeres Service Level vereinbart wird, sollte klar sein: - welches Risiko akzeptiert wird, - wer es akzeptiert, - welche Auswirkungen möglich sind, - welche Workarounds existieren, - wann neu bewertet wird, - welche Verbesserungen geplant sind. Beispiel: Ein nicht kritischer Testservice erhält kein 24/7-SLA. Das ist akzeptabel, wenn die Auswirkung gering und bekannt ist. --- **Service Level und Kommunikation** SLA-Inhalte müssen für Benutzer und Stakeholder verständlich kommuniziert werden. Benutzer sollten wissen: - wann der Service verfügbar sein soll, - wann Support erreichbar ist, - wie Störungen gemeldet werden, - welche Prioritäten gelten, - wann Statusupdates erfolgen, - welche Self-Service-Angebote existieren, - welche Einschränkungen bekannt sind. Unklare Kommunikation erzeugt falsche Erwartungen. --- **Praxisbeispiel: VPN-Service** **SLR** Benutzer im Homeoffice benötigen werktags zuverlässigen Zugriff auf interne Systeme. **SLA** VPN-Service soll Montag bis Freitag von 08:00 bis 18:00 Uhr verfügbar sein. P1-Incidents werden innerhalb von 15 Minuten qualifiziert bearbeitet. **OLA** Netzwerkteam übernimmt P1-Eskalationen innerhalb von 30 Minuten. Identity-Team unterstützt bei MFA-Störungen innerhalb definierter Zeit. **Underpinning Contract** Internetprovider und VPN-Hersteller bieten Support innerhalb vereinbarter Zeiten. **Prüfung** Wenn Hersteller-Support nur am nächsten Arbeitstag reagiert, muss das SLA entsprechend bewertet werden. --- **Praxisbeispiel: Mitarbeiterportal** **SLR** Fachbereich benötigt das Portal während der Kernarbeitszeit. **SLA** Servicezeit Montag bis Freitag von 07:00 bis 19:00 Uhr. Geplante Wartung nur außerhalb dieser Zeit. **OLA** Anwendungsteam und Datenbankteam stellen interne Unterstützung während Servicezeit sicher. **Underpinning Contract** Cloud-Datenbank besitzt Provider-Support für kritische Fälle. **Review** Nach mehreren Performancebeschwerden wird ein zusätzliches Performance-Ziel ergänzt. --- **Praxisbeispiel: Standardsoftware bereitstellen** **SLR** Benutzer sollen freigegebene Standardsoftware schnell erhalten. **SLA** Standardsoftware wird innerhalb von 2 Arbeitstagen bereitgestellt. **OLA** Service Desk prüft Anfrage innerhalb eines Arbeitstages. Endpoint-Team stellt Paketierung und Softwareverteilung bereit. **Underpinning Contract** Softwarelieferant stellt Lizenzportal und Support bereit. **Risiko** Wenn Lizenzfreigabe extern länger dauert, muss dies im SLA berücksichtigt werden. --- **Praxisbeispiel: Lieferant passt nicht zum SLA** **Situation** Interner SLA verspricht Wiederherstellung innerhalb von 4 Stunden. **Problem** Der externe Wartungsvertrag garantiert Ersatzteilversand erst am nächsten Arbeitstag. **Folge** Das SLA ist bei Hardwaredefekt nicht erfüllbar. **Mögliche Maßnahmen** - besserer Wartungsvertrag, - Ersatzhardware vorhalten, - redundante Architektur, - SLA anpassen, - Risiko akzeptieren und dokumentieren. --- **Typische Fehler** **Fehler 1** SLR wird ungeprüft direkt als SLA übernommen. --- **Fehler 2** SLA-Ziele sind nicht messbar. --- **Fehler 3** SLA, OLA und Lieferantenverträge passen nicht zusammen. --- **Fehler 4** Supportzeit und Servicezeit werden vermischt. --- **Fehler 5** Wartungsfenster sind nicht geregelt. --- **Fehler 6** Prioritäten sind unklar oder subjektiv. --- **Fehler 7** Messmethode wird nicht definiert. --- **Fehler 8** Ausnahmen werden nicht dokumentiert. --- **Fehler 9** Interne Teams kennen ihre OLA-Beiträge nicht. --- **Fehler 10** Lieferantenabhängigkeiten werden nicht berücksichtigt. --- **Fehler 11** SLA wird nicht regelmäßig überprüft. --- **Fehler 12** SLA wird als Kontrollinstrument genutzt, aber nicht als Grundlage für Verbesserung. --- **Checkliste SLR** - [ ] fachlicher Bedarf beschrieben - [ ] betroffener Service genannt - [ ] Zielgruppe bekannt - [ ] gewünschte Servicequalität beschrieben - [ ] Kritikalität bewertet - [ ] Risiko bei Nichterfüllung beschrieben - [ ] technische Machbarkeit geprüft - [ ] Kostenwirkung geprüft - [ ] Lieferantenabhängigkeiten geprüft - [ ] Messbarkeit geprüft - [ ] Alternative oder Workaround geprüft --- **Checkliste SLA** - [ ] Service eindeutig beschrieben - [ ] Geltungsbereich definiert - [ ] Kunde und Service Provider benannt - [ ] Servicezeiten festgelegt - [ ] Supportzeiten festgelegt - [ ] Wartungsfenster geregelt - [ ] Zielwerte definiert - [ ] Prioritäten beschrieben - [ ] Reaktionszeiten festgelegt - [ ] Wiederherstellungsziele festgelegt - [ ] Messmethoden beschrieben - [ ] Ausnahmen dokumentiert - [ ] Rollen und Verantwortlichkeiten klar - [ ] Reporting geregelt - [ ] Review-Termine festgelegt --- **Checkliste OLA** - [ ] beteiligte interne Teams benannt - [ ] unterstützte Services genannt - [ ] interne Reaktionszeiten definiert - [ ] Übergabepunkte beschrieben - [ ] Eskalationswege festgelegt - [ ] benötigte Ticketinformationen definiert - [ ] Supportzeiten intern abgestimmt - [ ] Bereitschaftsregeln geklärt - [ ] Dokumentationspflichten beschrieben - [ ] Knowledge-Pflege berücksichtigt - [ ] Review vorgesehen - [ ] Beitrag zum SLA nachvollziehbar --- **Checkliste Underpinning Contract** - [ ] unterstützter Service bekannt - [ ] Lieferant und Leistung beschrieben - [ ] Supportzeiten geregelt - [ ] Reaktionszeiten geregelt - [ ] Wiederherstellungs- oder Ersatzzeiten geregelt - [ ] Eskalationswege bekannt - [ ] Berichtspflichten vereinbart - [ ] Wartungsfenster abgestimmt - [ ] Sicherheitsanforderungen geregelt - [ ] Datenschutzanforderungen berücksichtigt - [ ] Vertragsziele passen zum SLA - [ ] Risiken bei Abweichung dokumentiert --- **Checkliste Abstimmung SLA, OLA und Lieferantenvertrag** - [ ] SLA-Ziele sind durch interne Teams unterstützbar - [ ] OLAs decken kritische interne Beiträge ab - [ ] Lieferantenverträge unterstützen relevante Ziele - [ ] Servicezeiten sind kompatibel - [ ] Supportzeiten sind kompatibel - [ ] Eskalationswege sind durchgängig - [ ] Messmethoden widersprechen sich nicht - [ ] Wartungsfenster sind abgestimmt - [ ] Ausnahmen sind klar - [ ] Risiken sind dokumentiert - [ ] Reviews betrachten alle Ebenen gemeinsam --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker müssen SLA, OLA und Lieferantenabhängigkeiten praktisch verstehen. Im Arbeitsalltag bedeutet das: - technische Machbarkeit von Servicezielen einschätzen, - interne Reaktions- und Eskalationswege kennen, - Lieferantenabhängigkeiten erkennen, - Monitoring passend zu SLA-Zielen prüfen, - Incidents korrekt priorisieren, - Wiederherstellungszeiten nachvollziehbar dokumentieren, - Wartungsfenster beachten, - Changes mit Servicezielen abstimmen, - und unrealistische Zusagen früh sichtbar machen. Service Level Management verbindet technische Realität mit vereinbarter Servicequalität. --- **Zusammenfassung** > Service Level Requirement erfassen > ↓ > fachlichen Bedarf, Risiko und Machbarkeit prüfen > ↓ > realistische SLA-Ziele vereinbaren > ↓ > interne OLAs zur Unterstützung festlegen > ↓ > externe Underpinning Contracts abstimmen > ↓ > Messmethoden und Ausnahmen definieren > ↓ > Monitoring und Reporting einrichten > ↓ > Service Reviews durchführen > ↓ > Abweichungen analysieren > ↓ > SLA, OLA oder Lieferantenvertrag verbessern --- **Merksätze** > Ein SLR beschreibt Bedarf, ein SLA beschreibt eine Vereinbarung. > Ein SLA ist nur erfüllbar, wenn OLAs und Lieferantenverträge dazu passen. > Servicezeit und Supportzeit sind nicht dasselbe. > Reaktionszeit ist nicht automatisch Lösungszeit. > Ein Ziel ohne Messmethode ist später kaum bewertbar. > Lieferantenabhängigkeiten müssen vor der SLA-Zusage geprüft werden. > Gute Service Level sind realistisch, messbar und verständlich. --- **Verwandte Seiten** - 8.1 Service Level Management – Ziele, Begriffe und Grundlagen - 8.3 Kennzahlen, Messmethoden und Reporting - 8.4 Service Reviews und Continual Improvement - 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management - Supplier Management - Incident Management - Change Enablement - Service Configuration Management - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Supplier Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - SLR-Beispiele, - SLA-Inhalte, - OLA-Strukturen, - Lieferantenvertragsbezüge, - Checklisten, - Prioritätsbeispiele, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - SLA-Vorlage, - SLR-Vorlage, - OLA-Struktur, - Prioritätsmatrix, - Messmethode, - Vertragsstruktur, - oder Review-Frequenz für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Kunden, - Benutzergruppen, - Risiken, - Kosten, - Supportmodell, - Lieferanten, - Monitoring, - Organisationsstruktur, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 8.3 Kennzahlen, Messmethoden und Reporting > **Kurz erklärt** > > Kennzahlen, Messmethoden und Reporting machen Servicequalität sichtbar. > > Entscheidend ist nicht, möglichst viele Zahlen zu sammeln. > > Entscheidend ist, die richtigen Fragen zu beantworten: > > - Wird der Service wie vereinbart erbracht? > - Wo gibt es Abweichungen? > - Welche Benutzer oder Geschäftsprozesse sind betroffen? > - Welche Ursachen sind erkennbar? > - Welche Verbesserungen sind notwendig? > > Gute Messung unterstützt Entscheidungen. Schlechte Messung erzeugt falsche Sicherheit. --- **Warum Kennzahlen wichtig sind** Ohne Messung bleibt Servicequalität oft subjektiv. Typische Aussagen ohne klare Daten: - „Der Service ist ständig langsam.“ - „Der Support reagiert nie.“ - „Das System fällt dauernd aus.“ - „Die IT hält ihre Zusagen nicht ein.“ - „Der Lieferant ist unzuverlässig.“ - „Die Benutzer sind unzufrieden.“ Kennzahlen helfen, solche Aussagen zu prüfen. Sie zeigen: - wie häufig etwas passiert, - wie stark die Auswirkung ist, - ob Ziele erreicht wurden, - ob sich Trends verschlechtern, - ob Verbesserungen wirken, - und wo genauer analysiert werden muss. --- **Kennzahlen sind kein Selbstzweck** Eine Kennzahl ist nur sinnvoll, wenn sie genutzt wird. Ungeeignet: > Wir messen alles, weil es technisch möglich ist. Besser: > Wir messen das, was für Servicequalität, Steuerung, Risiko und Verbesserung wichtig ist. Zu viele Kennzahlen führen zu unübersichtlichen Reports. Zu wenige Kennzahlen können wichtige Probleme verdecken. Die richtige Auswahl hängt vom Service, den Zielen und den Entscheidungen ab, die unterstützt werden sollen. --- **Gute Kennzahlen** Gute Kennzahlen sind: - verständlich, - messbar, - relevant, - nachvollziehbar, - regelmäßig verfügbar, - vergleichbar, - beeinflussbar, - mit Servicezielen verbunden, - und für Entscheidungen nutzbar. Eine Kennzahl sollte immer eine Frage beantworten. Beispiel: Nicht nur: > Wie viele Tickets wurden geschlossen? Sondern: > Werden Benutzer schneller wieder arbeitsfähig und verbessert sich die Servicequalität? --- **Kennzahl und Ziel unterscheiden** Eine Kennzahl ist ein Messwert. Ein Ziel beschreibt, welcher Wert erreicht werden soll. | Begriff | Bedeutung | Beispiel | |---|---|---| | **Kennzahl** | gemessener Wert | Verfügbarkeit des Service | | **Zielwert** | gewünschter oder vereinbarter Wert | mindestens 99,5 Prozent während Servicezeit | | **Messmethode** | Art der Ermittlung | synthetischer Login-Test alle 5 Minuten | | **Report** | Darstellung und Bewertung | Monatsbericht Servicequalität | | **Maßnahme** | Reaktion auf Ergebnis | Problem Record für wiederholte Ausfälle | Ohne Zielwert ist eine Kennzahl schwer zu bewerten. Ohne Messmethode ist ein Ziel schwer überprüfbar. --- **Messmethode** Die Messmethode beschreibt, wie eine Kennzahl ermittelt wird. Zu klären ist: - Was genau wird gemessen? - Wo wird gemessen? - Wann wird gemessen? - Wie häufig wird gemessen? - Welche Datenquelle gilt? - Welche Zeiträume zählen? - Welche Ausnahmen gelten? - Wer prüft die Daten? - Wie wird das Ergebnis berechnet? - Wie wird berichtet? Eine unklare Messmethode führt zu Diskussionen über Zahlen statt zu Verbesserungen. --- **Beispiel: Verfügbarkeit messen** Unklar: > Der Service war zu 99,9 Prozent verfügbar. Klärende Fragen: - Wurde aus Sicht des Servers oder aus Sicht des Benutzers gemessen? - Zählte nur die Startseite oder auch die Anmeldung? - Wurden geplante Wartungsfenster ausgeschlossen? - Wurde während Servicezeit oder rund um die Uhr gemessen? - Zählten kurze Unterbrechungen? - Waren alle Standorte betroffen oder nur einzelne? - Welche Datenquelle wurde verwendet? Erst mit diesen Angaben ist die Zahl aussagekräftig. --- **Technische Messung und Benutzerperspektive** Technische Messungen sind wichtig, aber nicht ausreichend. Beispiele: | Technische Sicht | Benutzerperspektive | |---|---| | Server antwortet auf Ping | Benutzer kann Anwendung nutzen | | HTTP-Status ist 200 | Anmeldung funktioniert wirklich | | Datenbank läuft | Anwendung verarbeitet Daten korrekt | | CPU-Auslastung ist normal | Oberfläche reagiert schnell genug | | Service Desk Ticket ist geschlossen | Benutzer ist tatsächlich arbeitsfähig | Ein Service kann technisch verfügbar sein und trotzdem für Benutzer schlecht nutzbar sein. --- **Servicebezogene Kennzahlen** Service Level Management sollte möglichst servicebezogen messen. Beispiele: - Verfügbarkeit je Service, - Incidents je Service, - Reaktionszeit je Priorität, - Wiederherstellungszeit je Service, - Benutzerzufriedenheit je Service, - Anzahl Major Incidents je Service, - Anzahl Changes je Service, - Incidents nach Changes, - wiederkehrende Incidents je Service, - offene Problems je Service, - SLA-Erfüllung je Service. Servicebezogene Kennzahlen sind hilfreicher als reine Technikzahlen ohne Kontext. --- **Verfügbarkeit** Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist. Zu definieren ist: - Servicezeit, - Messpunkt, - Messintervall, - betroffene Funktionen, - Ausnahmen, - Wartungsfenster, - Teilausfälle, - Datenquelle. Beispiel: > Der Service gilt als verfügbar, wenn Benutzer während der Servicezeit die Startseite öffnen, sich anmelden und die Hauptfunktion nutzen können. Diese Definition ist aussagekräftiger als nur: > Server ist erreichbar. --- **Berechnung von Verfügbarkeit** Eine einfache Formel: Verfügbarkeit = verfügbare Zeit / vereinbarte Servicezeit × 100 Beispiel: vereinbarte Servicezeit im Monat: 10.000 Minuten Ausfallzeit: 50 Minuten Verfügbarkeit = 9.950 / 10.000 × 100 Verfügbarkeit = 99,5 Prozent Wichtig: Die Berechnung muss definieren, welche Ausfallzeit zählt und welche nicht. --- **Geplante Wartung** Geplante Wartung sollte getrennt betrachtet werden. Zu klären ist: - Wird geplante Wartung aus der Verfügbarkeitsberechnung ausgeschlossen? - War die Wartung angekündigt? - Lag sie im vereinbarten Wartungsfenster? - Wurde das Wartungsfenster überschritten? - Waren Benutzer trotzdem betroffen? - Gab es Incidents nach der Wartung? Geplante Wartung ist nicht automatisch unproblematisch. Auch geplante Arbeiten können die Benutzererfahrung verschlechtern, wenn sie schlecht kommuniziert oder schlecht geplant sind. --- **Teilausfälle** Nicht jeder Ausfall betrifft den gesamten Service. Beispiele: - Anmeldung funktioniert, aber Export nicht. - Service funktioniert an Standort A, aber nicht an Standort B. - interne Benutzer können arbeiten, externe Benutzer nicht. - Anwendung läuft, aber Schnittstelle zum ERP ist gestört. - nur bestimmte Benutzergruppe ist betroffen. Für Teilausfälle muss festgelegt werden, wie sie bewertet werden. Sonst wird Servicequalität zu positiv oder zu negativ dargestellt. --- **Reaktionszeit** Reaktionszeit beschreibt die Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung. Zu klären ist: - Wann startet die Messung? - Wann endet die Messung? - Zählt nur Supportzeit? - Was gilt als qualifizierte Reaktion? - Zählt eine automatische Eingangsbestätigung? - Wird nach Priorität unterschieden? - Werden Wartezeiten auf Benutzer getrennt? Eine automatische Antwort sollte nicht als echte Reaktion gewertet werden, wenn keine Bearbeitung beginnt. --- **Wiederherstellungszeit** Wiederherstellungszeit beschreibt, wann ein Service wieder nutzbar ist. Das kann bedeuten: - vollständige technische Lösung, - Wiederherstellung der Kernfunktion, - funktionierender Workaround, - Rollback, - Ersatzverfahren, - Teilwiederherstellung. Wichtig ist, den Begriff vorher zu definieren. Ein Benutzer kann wieder arbeitsfähig sein, obwohl die Ursache noch nicht dauerhaft behoben ist. --- **Lösungszeit** Lösungszeit beschreibt die Zeit bis zur endgültigen Lösung. Sie unterscheidet sich von Wiederherstellungszeit. Beispiel: Ein Incident wird durch Workaround schnell behoben. Das zugrunde liegende Problem wird erst später durch einen Change dauerhaft gelöst. Dann sind Wiederherstellung und endgültige Lösung unterschiedliche Zeitpunkte. --- **MTTA, MTTR und ähnliche Kennzahlen** Häufig genutzte Kennzahlen: | Kennzahl | Bedeutung | |---|---| | **MTTA** | durchschnittliche Zeit bis zur Annahme oder Reaktion | | **MTTR** | durchschnittliche Zeit bis Wiederherstellung oder Lösung | | **MTBF** | durchschnittliche Zeit zwischen Ausfällen | | **MTRS** | durchschnittliche Zeit bis Service-Wiederherstellung | | **FCR** | First Contact Resolution, Lösung beim ersten Kontakt | Wichtig: Abkürzungen müssen in der Organisation einheitlich definiert werden. MTTR kann je nach Organisation „Mean Time to Repair“, „Mean Time to Restore“ oder anders verstanden werden. --- **Incident-Kennzahlen** Mögliche Incident-Kennzahlen: - Anzahl Incidents je Service, - Anzahl Incidents je Priorität, - Major Incidents, - Reaktionszeit, - Wiederherstellungszeit, - Wiedereröffnungen, - Eskalationen, - Incidents nach Changes, - wiederkehrende Incidents, - Incidents mit Known Error, - Incidents mit Knowledge-Nutzung, - Benutzerzufriedenheit nach Incident. Wichtig ist die Kombination. Eine einzelne Incident-Kennzahl erklärt selten die ganze Situation. --- **Problem-Kennzahlen** Mögliche Problem-Kennzahlen: - offene Problems, - Problems je Service, - Problems mit Known Error, - Problems mit Workaround, - Zeit bis Ursachenanalyse, - wiederkehrende Incidents je Problem, - Problems mit dauerhafter Lösung, - Problems ohne Owner, - gealterte Problems, - Problems mit hohem Risiko. Problem-Kennzahlen helfen, strukturelle Ursachen sichtbar zu machen. Sie sollten nicht dazu führen, Problems vorschnell zu schließen. --- **Change-Kennzahlen** Mögliche Change-Kennzahlen: - Anzahl Changes, - erfolgreiche Changes, - fehlgeschlagene Changes, - Emergency Changes, - Changes mit Rollback, - Incidents nach Changes, - Changes ohne betroffene CIs, - Changes ohne Risikoanalyse, - Changes ohne Knowledge-Prüfung, - Durchlaufzeit von Changes, - Changes außerhalb Wartungsfenster. Change-Kennzahlen helfen, Stabilität und Veränderungsfähigkeit zu bewerten. --- **Request-Kennzahlen** Mögliche Request-Kennzahlen: - Anzahl Service Requests, - Bearbeitungszeit je Request-Typ, - Erfüllung vereinbarter Zielzeiten, - Rückfragenquote, - abgebrochene Requests, - automatisierte Requests, - Self-Service-Anteil, - Genehmigungsdauer, - häufige Standardrequests, - falsch eingereichte Requests. Diese Kennzahlen helfen, Serviceportale, Formulare und Automatisierung zu verbessern. --- **Knowledge-Kennzahlen** Mögliche Knowledge-Kennzahlen: - Artikelaufrufe, - Nutzung im Incident, - Suchanfragen ohne Treffer, - Artikel ohne Owner, - Artikel ohne Review-Datum, - schlecht bewertete Artikel, - häufig genutzte Workarounds, - Knowledge-Artikel nach Major Incidents, - Knowledge-Aktualisierung nach Changes, - veraltete Artikel. Knowledge-Kennzahlen zeigen, ob Wissen im Alltag hilft oder nur abgelegt wird. --- **Benutzerzufriedenheit** Benutzerzufriedenheit ergänzt technische Kennzahlen. Mögliche Methoden: - kurze Umfrage nach Ticketabschluss, - regelmäßige Serviceumfrage, - Feedback im Serviceportal, - Bewertung von Knowledge-Artikeln, - Interviews mit Fachbereichen, - Service Reviews, - Auswertung wiederkehrender Beschwerden. Wichtig: Zufriedenheit ist subjektiv, aber trotzdem wertvoll. Sie zeigt, ob gemessene Servicequalität auch so erlebt wird. --- **Experience Level** Neben klassischen Service Levels kann auch die Benutzererfahrung betrachtet werden. Beispiele: - Wie einfach ist ein Service zu nutzen? - Wie verständlich ist der Self-Service? - Wie hilfreich ist die Kommunikation? - Wie schnell fühlen sich Benutzer unterstützt? - Wie viele Schritte braucht ein Standardrequest? - Wie störend sind kurze Ausfälle im Arbeitsfluss? Technische Ziele allein zeigen nicht immer die tatsächliche Nutzungserfahrung. --- **Reporting** Reporting stellt Kennzahlen und Bewertungen verständlich dar. Ein Report sollte nicht nur Zahlen zeigen. Er sollte erklären: - Was ist passiert? - Was bedeutet es? - Welche Ziele wurden erreicht? - Welche Ziele wurden verfehlt? - Was sind die Ursachen? - Welche Risiken bestehen? - Welche Maßnahmen laufen? - Welche Entscheidungen werden benötigt? Ein guter Report führt zu Handlung, nicht nur zu Ablage. --- **Zielgruppen für Reporting** Verschiedene Zielgruppen benötigen unterschiedliche Reports. | Zielgruppe | benötigt typischerweise | |---|---| | **Management** | Risiken, Trends, Zielerreichung, Entscheidungen | | **Service Owner** | Servicequalität, Abweichungen, Maßnahmen | | **Service Desk** | Tickettrends, Knowledge-Lücken, Eskalationen | | **Fachteam** | technische Ursachen, Changes, Problems | | **Security Team** | Schwachstellen, kritische CIs, Vorfälle | | **Benutzer** | Status, einfache Verfügbarkeit, bekannte Störungen | Nicht jeder Report muss alle Details enthalten. --- **Management-Reporting** Management benötigt meist verdichtete Informationen. Geeignete Inhalte: - wichtigste Serviceziele, - rote und kritische Abweichungen, - große Risiken, - Major Incidents, - Trends, - Lieferantenprobleme, - Kosten- oder Ressourcenbezug, - Entscheidungen, - geplante Verbesserungen. Management-Reports sollten nicht mit technischen Details überladen werden. Sie müssen entscheidungsfähig machen. --- **Operatives Reporting** Operative Teams benötigen mehr Detail. Geeignete Inhalte: - genaue Incident-Daten, - betroffene CIs, - Fehlerkategorien, - wiederkehrende Muster, - technische Messpunkte, - betroffene Versionen, - Eskalationszeiten, - Change-Auswirkungen, - Problem Records, - konkrete Maßnahmen. Operatives Reporting hilft bei Analyse und Verbesserung der täglichen Arbeit. --- **Benutzerorientiertes Reporting** Benutzer benötigen klare und einfache Informationen. Beispiele: - aktueller Status eines Service, - bekannte Störung, - geplantes Wartungsfenster, - erwartete nächste Aktualisierung, - was Benutzer tun sollen, - ob ein Ticket notwendig ist, - ob ein Workaround verfügbar ist. Benutzer brauchen keine internen Detailberichte. Sie brauchen verständliche Orientierung. --- **Dashboards** Dashboards zeigen aktuelle oder regelmäßige Informationen auf einen Blick. Mögliche Inhalte: - Serviceverfügbarkeit, - offene Major Incidents, - SLA-Erfüllung, - Ticketvolumen, - kritische Changes, - offene Problems, - ablaufende Zertifikate, - Lieferantenstatus, - Knowledge-Lücken, - Benutzerzufriedenheit. Ein Dashboard muss gepflegt und richtig interpretiert werden. Ein grünes Dashboard bedeutet nicht automatisch, dass Benutzer zufrieden sind. --- **Ampelstatus** Viele Reports nutzen Ampelfarben. Beispiel: | Status | Bedeutung | |---|---| | **grün** | Ziel erreicht | | **gelb** | Risiko oder leichte Abweichung | | **rot** | Ziel verfehlt oder kritisches Risiko | Wichtig: Ampeln brauchen klare Regeln. Ungeeignet: > Gelb nach Bauchgefühl. Besser: > Gelb, wenn Zielwert um bis zu 10 Prozent verfehlt wird oder ein Risiko für den nächsten Zeitraum besteht. --- **Trends statt Momentaufnahmen** Ein einzelner Monatswert reicht oft nicht aus. Wichtiger sind Trends. Beispiele: - Ticketvolumen steigt seit drei Monaten. - Wiederherstellungszeit verbessert sich. - Benutzerzufriedenheit sinkt trotz SLA-Erfüllung. - Incidents nach Changes nehmen zu. - Suchanfragen ohne Treffer steigen. - Emergency Changes werden häufiger. Trends zeigen, ob sich Servicequalität verbessert oder verschlechtert. --- **Durchschnittswerte vorsichtig nutzen** Durchschnittswerte können täuschen. Beispiel: Die durchschnittliche Lösungszeit beträgt 4 Stunden. Mögliche Realität: - viele kleine Tickets werden sehr schnell gelöst, - wenige kritische Tickets dauern extrem lange, - bestimmte Benutzergruppen sind stark betroffen, - ein Service hat große Probleme, andere nicht. Deshalb sollten Durchschnittswerte ergänzt werden durch: - Median, - Verteilung, - Priorität, - Servicebezug, - Ausreißer, - Anzahl kritischer Fälle. --- **Median und Perzentile** Der Median zeigt den mittleren Wert einer Verteilung. Perzentile zeigen, wie viele Fälle unter einem bestimmten Wert liegen. Beispiel: - 90 Prozent der P2-Incidents werden innerhalb von 8 Stunden wiederhergestellt. - 50 Prozent werden innerhalb von 2 Stunden wiederhergestellt. - 10 Prozent dauern deutlich länger. Das ist oft aussagekräftiger als nur ein Durchschnittswert. --- **Kontext zu Kennzahlen** Kennzahlen brauchen Kontext. Beispiel: Ticketvolumen steigt. Mögliche Ursachen: - neuer Service eingeführt, - Release mit Fehlern, - bessere Meldewege, - mehr Benutzer, - bekannte Störung, - schlechte Self-Service-Artikel, - organisatorische Änderung, - Sicherheitskampagne, - saisonale Belastung. Ohne Kontext kann eine Kennzahl falsch interpretiert werden. --- **Datenqualität im Reporting** Reports sind nur so gut wie ihre Daten. Typische Datenprobleme: - falsche Kategorien, - fehlende Servicezuordnung, - falsche Prioritäten, - nicht gepflegte CIs, - uneinheitliche Statuswerte, - manuell geschönte Werte, - fehlende Zeitstempel, - automatische Antworten als Reaktion gezählt, - Wartezeiten falsch behandelt. Datenqualität muss regelmäßig geprüft werden. --- **Messung kann Verhalten beeinflussen** Kennzahlen beeinflussen, wie Menschen arbeiten. Beispiele: - Wird nur Ticketanzahl gemessen, werden Tickets schnell geschlossen. - Wird nur Bearbeitungszeit gemessen, werden schwierige Fälle vermieden. - Wird nur SLA-Erfüllung gemessen, werden Prioritäten möglicherweise angepasst. - Wird nur Artikelanzahl gemessen, entstehen viele schlechte Knowledge-Artikel. Kennzahlen müssen so gewählt werden, dass sie gutes Verhalten fördern. --- **Falsche Anreize vermeiden** Besser ist eine Kombination von Kennzahlen. Beispiele: | Kombination | besser als | |---|---| | Lösungszeit und Wiedereröffnungsquote | nur schnelle Lösung | | Ticketanzahl und Benutzerzufriedenheit | nur Produktivität | | SLA-Erfüllung und Major-Incident-Analyse | nur grüne Ampel | | Change-Erfolg und Incidents nach Changes | nur Anzahl Changes | | Knowledge-Nutzung und Artikelbewertung | nur Anzahl Artikel | Gute Kennzahlensets betrachten Qualität, Wirkung und Stabilität gemeinsam. --- **Reporting-Frequenz** Die Frequenz hängt vom Zweck ab. | Report | mögliche Frequenz | |---|---| | Live-Dashboard für Betrieb | laufend | | Major-Incident-Status | während Ereignis regelmäßig | | Service-Level-Report | monatlich | | Service Review | monatlich oder quartalsweise | | Lieferantenreport | monatlich oder quartalsweise | | Managementreport | monatlich oder quartalsweise | | Datenqualitätsreport | regelmäßig nach Bedarf | Zu häufige Reports ohne Handlung erzeugen Aufwand. Zu seltene Reports erkennen Probleme zu spät. --- **Reporting und Service Review** Reports sollten Service Reviews vorbereiten. Ein Service Review nutzt Reports, um zu besprechen: - welche Ziele erreicht wurden, - welche Abweichungen relevant sind, - welche Ursachen erkennbar sind, - welche Risiken bestehen, - welche Maßnahmen laufen, - welche Entscheidungen nötig sind, - welche Verbesserungen priorisiert werden. Reporting liefert Daten. Service Review macht daraus Bewertung und Handlung. --- **SLA-Abweichungen berichten** Bei SLA-Abweichungen sollte ein Report enthalten: - betroffenes Ziel, - Zeitraum, - Höhe der Abweichung, - betroffener Service, - betroffene Benutzer, - Ursache oder vermutete Ursache, - beteiligte CIs oder Lieferanten, - Zusammenhang mit Changes oder Problems, - aktuelle Maßnahmen, - geplante Verbesserung, - Verantwortlicher, - Termin. Nur „SLA nicht erreicht“ reicht nicht aus. --- **Beispiel: SLA-Abweichung** **Ziel** P1-Incidents innerhalb von 4 Stunden wiederherstellen. **Ergebnis** Ziel wurde in einem Fall verfehlt. **Ursache** Datenbankproblem wurde zu spät an das zuständige Team eskaliert. **Auswirkung** Mitarbeiterportal war für mehrere Standorte nicht nutzbar. **Maßnahme** OLA-Eskalation wird angepasst. Service Desk erhält neuen Knowledge-Artikel. Monitoringalarm wird geändert. --- **Serviceverbesserung aus Kennzahlen ableiten** Kennzahlen sollen Verbesserungen auslösen. Beispiele: - viele Incidents nach Changes → Change Review verbessern, - viele Tickets zu MFA → Self-Service-Artikel verbessern, - lange Eskalationszeiten → OLA prüfen, - schlechte Benutzerbewertung → Kommunikation und Lösung prüfen, - häufige Workarounds → Problem Management starten, - veraltete Knowledge-Artikel → Review-Prozess verbessern, - wiederholte Lieferantenverzögerung → Supplier Review durchführen. Die wichtigste Frage lautet: > Welche konkrete Handlung folgt aus dem Report? --- **Kennzahlen für Continual Improvement** Continual Improvement nutzt Kennzahlen zur Priorisierung. Hilfreich sind: - Trends, - wiederholte Abweichungen, - Auswirkung auf Benutzer, - Risiko, - Kosten, - Häufigkeit, - Verbesserungspotenzial, - Aufwand, - erwarteter Nutzen. Nicht jede schlechte Kennzahl ist sofort höchste Priorität. Die Bedeutung hängt von Servicekritikalität und Auswirkung ab. --- **Praxisbeispiel: Grüne SLA, unzufriedene Benutzer** **Situation** SLA-Verfügbarkeit wurde erreicht. Trotzdem sind Benutzer unzufrieden. **Analyse** - Anwendung ist verfügbar, - aber häufig langsam, - Suchfunktion reagiert schlecht, - Tickets werden formal schnell beantwortet, - dauerhafte Lösung fehlt. **Erkenntnis** Verfügbarkeit allein misst nicht die Benutzererfahrung. **Verbesserung** Performance-Ziel und Benutzerfeedback werden ergänzt. --- **Praxisbeispiel: Ticketzahlen steigen** **Situation** Ticketanzahl im Service Desk steigt stark. **Mögliche Ursachen** - neuer Service, - schlechtes Release, - fehlender Self-Service, - bessere Meldewege, - echter Qualitätsverlust, - neue Benutzergruppe, - Sicherheitskampagne. **Vorgehen** Tickets nach Service, Kategorie, Priorität und Ursache auswerten. Nicht vorschnell annehmen, dass der Service Desk schlechter arbeitet. --- **Praxisbeispiel: Lieferant erfüllt Ziel nicht** **Situation** SLA-Abweichungen entstehen durch langsame Lieferantenreaktion. **Reporting zeigt** - betroffener Service, - Lieferant, - Reaktionszeiten, - Vertragsziel, - tatsächliche Bearbeitung, - Auswirkung auf Benutzer. **Verbesserung** Supplier Review durchführen. Underpinning Contract prüfen. Internes SLA realistisch bewerten. --- **Praxisbeispiel: Knowledge-Lücke** **Situation** Viele Benutzer suchen im Portal nach „neues Handy MFA“. Es gibt keinen passenden Treffer. **Folge** Viele Tickets entstehen. **Verbesserung** Benutzerartikel „MFA auf neuem Smartphone einrichten“ erstellen. Suchbegriffe ergänzen. Ticketformular verlinken. **Messung** Suchtreffer, Artikelbewertung und Ticketvolumen nach Verbesserung prüfen. --- **Typische Fehler** **Fehler 1** Es werden zu viele Kennzahlen ohne klare Entscheidung gemessen. --- **Fehler 2** Kennzahlen sind technisch korrekt, aber für den Service nicht relevant. --- **Fehler 3** Messmethoden sind nicht definiert. --- **Fehler 4** Reports enthalten Zahlen ohne Bewertung. --- **Fehler 5** Durchschnittswerte verdecken kritische Einzelfälle. --- **Fehler 6** Benutzerzufriedenheit wird ignoriert. --- **Fehler 7** Datenqualität in Tickets und CMDB ist schlecht. --- **Fehler 8** Automatische Antworten werden als echte Reaktion gezählt. --- **Fehler 9** SLA-Abweichungen werden nur gemeldet, aber nicht analysiert. --- **Fehler 10** Kennzahlen erzeugen falsche Anreize. --- **Fehler 11** Reports sind nicht auf Zielgruppen angepasst. --- **Fehler 12** Aus Reports entstehen keine Verbesserungsmaßnahmen. --- **Checkliste Kennzahl auswählen** - [ ] Kennzahl beantwortet eine konkrete Frage - [ ] Kennzahl ist für den Service relevant - [ ] Zielgruppe kennt die Bedeutung - [ ] Zielwert ist definiert - [ ] Messmethode ist klar - [ ] Datenquelle ist verfügbar - [ ] Datenqualität ist ausreichend - [ ] Kennzahl ist beeinflussbar - [ ] Kennzahl erzeugt keine falschen Anreize - [ ] Kennzahl unterstützt Entscheidung oder Verbesserung --- **Checkliste Messmethode** - [ ] Startpunkt der Messung definiert - [ ] Endpunkt der Messung definiert - [ ] Messzeitraum definiert - [ ] Servicezeit berücksichtigt - [ ] Supportzeit berücksichtigt - [ ] Wartungsfenster geregelt - [ ] Ausnahmen definiert - [ ] Datenquelle festgelegt - [ ] Berechnung beschrieben - [ ] Verantwortlicher für Prüfung festgelegt - [ ] Ergebnis nachvollziehbar dokumentiert --- **Checkliste Reporting** - [ ] Zielgruppe definiert - [ ] Servicebezug vorhanden - [ ] Zielwerte sichtbar - [ ] Ist-Werte sichtbar - [ ] Abweichungen markiert - [ ] Ursachen beschrieben - [ ] Trends dargestellt - [ ] Risiken genannt - [ ] Maßnahmen beschrieben - [ ] Verantwortliche benannt - [ ] Termine genannt - [ ] Report führt zu Review oder Entscheidung --- **Checkliste SLA-Abweichung analysieren** - [ ] betroffenes SLA-Ziel benannt - [ ] Zeitraum genannt - [ ] betroffener Service genannt - [ ] betroffene Benutzer oder Standorte beschrieben - [ ] technische Ursache geprüft - [ ] organisatorische Ursache geprüft - [ ] Lieferantenbezug geprüft - [ ] Zusammenhang mit Changes geprüft - [ ] Problem Record geprüft oder erstellt - [ ] Maßnahme definiert - [ ] Owner benannt - [ ] Wirksamkeitsprüfung geplant --- **Checkliste Datenqualität für Reports** - [ ] Tickets haben korrekte Servicezuordnung - [ ] Prioritäten sind nachvollziehbar - [ ] Zeitstempel sind korrekt - [ ] Statuswerte sind einheitlich - [ ] CIs sind verknüpft, falls relevant - [ ] Kategorien werden einheitlich genutzt - [ ] automatische Antworten werden getrennt bewertet - [ ] Wartezeiten sind nachvollziehbar - [ ] Dubletten werden bereinigt - [ ] manuelle Korrekturen sind dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker liefern viele Daten, die für Service Level Management wichtig sind. Im Arbeitsalltag bedeutet das: - Incidents sauber dokumentieren, - betroffene Services und CIs korrekt verknüpfen, - technische Messwerte richtig interpretieren, - Monitoring nicht nur auf Server, sondern auf Servicefunktion ausrichten, - Wiederherstellungszeiten nachvollziehbar erfassen, - Changes und deren Auswirkungen dokumentieren, - wiederkehrende Probleme erkennen, - und Reports nicht nur als Kontrolle, sondern als Verbesserungsgrundlage verstehen. Gute Messung hilft, technische Arbeit sichtbar und steuerbar zu machen. --- **Zusammenfassung** > Serviceziele verstehen > ↓ > passende Kennzahlen auswählen > ↓ > Messmethode eindeutig definieren > ↓ > Datenquellen und Datenqualität sichern > ↓ > technische und Benutzerperspektive kombinieren > ↓ > Ergebnisse verständlich berichten > ↓ > Abweichungen analysieren > ↓ > Trends erkennen > ↓ > Verbesserungsmaßnahmen ableiten > ↓ > Wirkung erneut messen --- **Merksätze** > Eine Kennzahl ist nur sinnvoll, wenn daraus eine Entscheidung oder Verbesserung entstehen kann. > Messmethode und Datenquelle müssen klar sein. > Technische Verfügbarkeit ist nicht automatisch gute Servicequalität. > Durchschnittswerte können kritische Probleme verdecken. > Reports brauchen Kontext, Bewertung und Maßnahmen. > Kennzahlen können Verhalten beeinflussen und falsche Anreize erzeugen. > Reporting ist die Grundlage für Service Reviews und Continual Improvement. --- **Verwandte Seiten** - 8.1 Service Level Management – Ziele, Begriffe und Grundlagen - 8.2 SLA, SLR, OLA und Underpinning Contracts - 8.4 Service Reviews und Continual Improvement - 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management - Measurement and Reporting - Incident Management - Problem Management - Change Enablement - Service Configuration Management - Knowledge Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Kennzahlen, - Messmethoden, - Reporting-Strukturen, - SLA-Abweichungsanalysen, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Kennzahlenliste, - Berechnungsformel, - Reporting-Vorlage, - Dashboard-Struktur, - Ampellogik, - Zielwerttabelle, - oder Review-Frequenz für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Service Level Agreements, - Kunden, - Benutzergruppen, - Supportmodell, - Monitoring, - Toollandschaft, - Datenqualität, - Lieferanten, - Risiken, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 8.4 Service Reviews und Continual Improvement > **Kurz erklärt** > > Service Reviews bewerten regelmäßig, wie gut ein IT-Service seine vereinbarten Ziele erfüllt und ob er den erwarteten Nutzen liefert. > > Dabei werden nicht nur SLA-Werte betrachtet. > > Auch Incidents, Problems, Changes, Benutzerfeedback, Risiken, Lieferantenleistungen und Verbesserungspotenziale gehören dazu. > > Continual Improvement sorgt anschließend dafür, dass aus Erkenntnissen konkrete und überprüfbare Verbesserungen entstehen. --- **Warum Service Reviews wichtig sind** Ein Report allein verbessert keinen Service. Kennzahlen zeigen beispielsweise: - Verfügbarkeit, - Reaktionszeiten, - Wiederherstellungszeiten, - Ticketvolumen, - SLA-Erfüllung, - Benutzerzufriedenheit, - Changes, - Major Incidents. Ein Service Review bewertet zusätzlich: - Warum wurde ein Ziel erreicht oder verfehlt? - Welche Auswirkungen hatten Abweichungen? - Welche Risiken bestehen? - Welche Ursachen sind bekannt? - Welche Maßnahmen laufen bereits? - Welche Entscheidung wird benötigt? - Welche Verbesserung sollte priorisiert werden? Ein Service Review verbindet Daten mit Bewertung, Verantwortung und Handlung. --- **Was ist ein Service Review?** Ein Service Review ist eine regelmäßige strukturierte Betrachtung eines Service. Dabei wird gemeinsam geprüft: - aktuelle Servicequalität, - Zielerreichung, - Benutzererfahrung, - wichtige Incidents, - offene Problems, - relevante Changes, - Lieferantenleistungen, - bekannte Risiken, - geplante Entwicklungen, - und Verbesserungsmaßnahmen. Service Reviews können je nach Kritikalität und Organisation: - monatlich, - quartalsweise, - halbjährlich, - oder anlassbezogen stattfinden. --- **Ziele eines Service Reviews** Ein Service Review soll: - Servicequalität transparent machen, - Abweichungen verstehen, - Risiken frühzeitig erkennen, - Verantwortlichkeiten klären, - Maßnahmen priorisieren, - Entscheidungen vorbereiten, - Kunden- und Benutzerfeedback einbeziehen, - Lieferantenleistung bewerten, - und Continual Improvement unterstützen. Das Review sollte nicht nur rückwärts schauen. Es sollte auch kommende Risiken und Veränderungen betrachten. --- **Service Review ist keine reine Zahlenbesprechung** Ein häufiger Fehler: > Im Service Review werden nur Diagramme und SLA-Werte vorgelesen. Das reicht nicht aus. Ein gutes Service Review beantwortet: - Was bedeutet die Zahl? - Warum ist sie so? - Welche Benutzer waren betroffen? - Ist ein Trend erkennbar? - Muss ein Problem untersucht werden? - Muss ein Change geplant werden? - Muss ein Lieferant eskaliert werden? - Muss ein Service Level angepasst werden? - Welche Maßnahme wird bis wann umgesetzt? > **Merke** > > Reporting liefert Informationen. > > Das Service Review bewertet diese Informationen und löst Entscheidungen aus. --- **Teilnehmer eines Service Reviews** Mögliche Teilnehmer: - Service Owner, - Kunde oder Fachbereich, - Service Level Manager, - Service Desk, - technische Supportgruppen, - Problem Management, - Change Management, - Supplier Management, - Information Security, - Continual Improvement, - Management, - wichtige Lieferanten. Nicht jedes Review benötigt alle Rollen. Die Teilnehmer sollten zum Service und zu den aktuellen Themen passen. --- **Rolle des Service Owners** Der Service Owner trägt eine zentrale Verantwortung. Typische Aufgaben: - Serviceleistung bewerten, - Risiken vertreten, - Stakeholder einbinden, - Verbesserungen priorisieren, - Entscheidungen vorbereiten, - Maßnahmen verfolgen, - Abhängigkeiten berücksichtigen, - und Serviceziele aktuell halten. Der Service Owner muss nicht jede technische Einzelheit kennen. Er muss aber verstehen, welche Auswirkungen technische Themen auf den Service haben. --- **Rolle des Service Level Managers** Der Service Level Manager unterstützt durch: - Vorbereitung des Reviews, - Zusammenstellung von Kennzahlen, - Prüfung der SLA-Erfüllung, - Abstimmung mit Kunden und Teams, - Dokumentation von Abweichungen, - Nachverfolgung von Maßnahmen, - und Pflege der Service-Level-Vereinbarungen. Die Rolle kann je nach Organisation anders benannt oder verteilt sein. --- **Rolle des Service Desk** Der Service Desk liefert wichtige Praxiserkenntnisse. Beispiele: - häufige Benutzerfragen, - wiederkehrende Incidents, - unklare Self-Service-Inhalte, - Probleme bei Eskalationen, - schlechte Knowledge-Artikel, - Benutzerfeedback, - häufige Workarounds, - auffällige Tickettrends. Der Service Desk kennt oft die tatsächliche Benutzerwahrnehmung besser als rein technische Reports. --- **Rolle der technischen Teams** Technische Teams liefern Informationen zu: - Ursachen, - Plattformzustand, - Kapazität, - Monitoring, - technischen Risiken, - Changes, - Releases, - Sicherheitslücken, - Abhängigkeiten, - und geplanten Maßnahmen. Technische Informationen sollten so erklärt werden, dass ihre Servicewirkung verständlich ist. --- **Rolle des Fachbereichs oder Kunden** Fachbereiche und Kunden liefern die Geschäftsperspektive. Wichtige Fragen: - Unterstützt der Service den Arbeitsprozess? - Welche Funktionen sind besonders wichtig? - Welche Störungen waren besonders kritisch? - Haben sich Anforderungen verändert? - Gibt es neue Benutzergruppen? - Sind Support und Kommunikation ausreichend? - Welche Verbesserungen haben den höchsten Nutzen? Servicequalität darf nicht nur aus IT-Sicht bewertet werden. --- **Vorbereitung eines Service Reviews** Vor dem Review sollten relevante Informationen gesammelt werden. Mögliche Inhalte: - SLA- und Service-Level-Berichte, - Verfügbarkeitsdaten, - Incident-Trends, - Major Incidents, - Problem Records, - Known Errors, - häufig genutzte Workarounds, - Change-Ergebnisse, - Failed Changes, - Release-Ergebnisse, - Benutzerfeedback, - Lieferantenberichte, - Security-Risiken, - Kapazitätsdaten, - offene Verbesserungsmaßnahmen. Die Vorbereitung sollte sich auf wichtige Themen konzentrieren. Ein unübersichtlicher Datenberg erschwert Entscheidungen. --- **Mögliche Agenda** Eine kompakte Agenda kann so aussehen: 1. Servicezustand und wichtige Entwicklungen 2. Zielerreichung und SLA-Abweichungen 3. Benutzer- und Kundenfeedback 4. wichtige Incidents und Major Incidents 5. offene Problems und Known Errors 6. Changes und Releases 7. Lieferantenleistung 8. Risiken und kommende Anforderungen 9. Verbesserungsmaßnahmen 10. Entscheidungen, Owner und Termine Die Agenda sollte an den Service angepasst werden. --- **Servicezustand bewerten** Zu Beginn sollte ein Gesamtbild entstehen. Mögliche Fragen: - Ist der Service stabil? - Gibt es aktuell kritische Risiken? - Haben sich Nutzerzahlen verändert? - Hat sich die Nutzung verändert? - Gibt es technische Engpässe? - Gibt es bevorstehende Änderungen? - Sind Lieferantenleistungen stabil? - Gibt es neue Sicherheitsanforderungen? Ein Gesamtbild hilft, einzelne Kennzahlen richtig einzuordnen. --- **SLA-Erfüllung bewerten** Zu prüfen ist: - Welche Ziele wurden erreicht? - Welche Ziele wurden verfehlt? - Wie groß war die Abweichung? - Handelt es sich um einen Einzelfall oder Trend? - Welche Benutzer waren betroffen? - Welche Ursache ist bekannt? - Welche Gegenmaßnahmen laufen? - Muss ein Problem Record erstellt werden? - Muss das SLA angepasst werden? Eine Zielverfehlung muss nicht automatisch bedeuten, dass das Ziel falsch ist. Aber sie muss verstanden werden. --- **Erreichte Ziele kritisch betrachten** Auch grüne Kennzahlen sollten hinterfragt werden. Beispiele: - Wurde das Ziel erreicht, weil es zu niedrig ist? - Wurde eine automatische Antwort als Reaktion gezählt? - Wurden Wartungszeiten großzügig ausgeschlossen? - Sind Benutzer trotzdem unzufrieden? - Werden kritische Einzelfälle durch Durchschnittswerte verdeckt? - Stimmen Daten und Servicewahrnehmung überein? Ein grünes Dashboard ist kein Beweis für einen guten Service. --- **Benutzerfeedback einbeziehen** Benutzerfeedback kann stammen aus: - Ticketumfragen, - Serviceportal, - Interviews, - Beschwerden, - Fachbereichsgesprächen, - Service-Desk-Rückmeldungen, - Artikelbewertungen, - Workshops, - oder Nutzungsanalysen. Zu prüfen ist: - Welche Themen wiederholen sich? - Welche Probleme sind technisch nicht sichtbar? - Welche Prozesse sind zu kompliziert? - Welche Kommunikation ist unverständlich? - Welche Self-Service-Angebote fehlen? - Welche Funktionen sind besonders wichtig? Qualitatives Feedback ergänzt Kennzahlen. --- **Incidents betrachten** Im Service Review sollten nicht alle Incidents einzeln besprochen werden. Wichtig sind: - Major Incidents, - wiederkehrende Incidents, - kritische Incidents, - Incidents mit langer Wiederherstellung, - Incidents nach Changes, - Incidents mit schlechter Kommunikation, - häufige Eskalationen, - auffällige Standorte oder Benutzergruppen. Ziel ist, Muster und Verbesserungsmöglichkeiten zu erkennen. --- **Major Incidents betrachten** Bei Major Incidents sollte geprüft werden: - Was war die Ursache? - Wie schnell wurde reagiert? - War Ownership klar? - War Kommunikation ausreichend? - Funktionierten Eskalationswege? - Waren Runbooks aktuell? - Gab es einen Workaround? - Wurde ein Problem Record erstellt? - Wurden Lessons Learned umgesetzt? - Sind weitere Maßnahmen offen? Ein Major-Incident-Review kann Teil eines Service Reviews sein oder separat stattfinden. --- **Problems und Known Errors betrachten** Wichtige Fragen: - Welche offenen Problems betreffen den Service? - Welche Known Errors bestehen? - Wie häufig werden Workarounds genutzt? - Gibt es eine dauerhafte Lösung? - Ist ein Change geplant? - Ist das Risiko noch akzeptabel? - Sind Service Desk und Benutzer informiert? - Müssen Prioritäten angepasst werden? - Gibt es gealterte Problem Records? Häufig genutzte Workarounds sind ein Warnsignal. --- **Changes betrachten** Zu prüfen ist: - Welche wichtigen Changes wurden umgesetzt? - Haben sie den erwarteten Nutzen erreicht? - Gab es Failed Changes? - Sind Incidents nach Changes entstanden? - Wurde Knowledge aktualisiert? - Wurde die CMDB aktualisiert? - Wurden Risiken korrekt bewertet? - Stehen wichtige Changes bevor? - Gibt es Change-Kollisionen oder Freeze-Zeiten? Changes beeinflussen Servicequalität direkt. --- **Releases betrachten** Bei Releases sind wichtig: - erfolgreiche Einführung, - Benutzerfeedback, - Incidents nach Release, - bekannte Fehler, - neue Workarounds, - Supportaufwand, - aktualisierte Dokumentation, - aktualisierte Knowledge-Artikel, - und erreichte Geschäftsziele. Ein technisch erfolgreiches Deployment kann aus Benutzersicht trotzdem unzureichend sein. --- **Lieferantenleistung betrachten** Bei externen Abhängigkeiten sollte geprüft werden: - Wurden Vertragsziele erreicht? - Waren Reaktionszeiten ausreichend? - Gab es wiederkehrende Störungen? - Waren Eskalationswege wirksam? - War die Kommunikation ausreichend? - Gibt es offene Herstellerfehler? - Müssen Verträge angepasst werden? - Bestehen Abhängigkeiten von einzelnen Lieferanten? - Gibt es Alternativen oder Notfallverfahren? Lieferantenprobleme dürfen nicht einfach als unveränderlich hingenommen werden. --- **Risiken betrachten** Mögliche Servicerisiken: - veraltete Software, - ablaufende Zertifikate, - fehlende Redundanz, - bekannte Kapazitätsgrenzen, - unklare Owner, - fehlende Dokumentation, - häufige Emergency Changes, - unzureichende Lieferantenleistung, - fehlende Backuptests, - Sicherheitslücken, - hohe Abhängigkeit von Einzelpersonen, - geplanter Hersteller-Supportablauf. Risiken sollten mit Auswirkung, Wahrscheinlichkeit, Owner und Maßnahme dokumentiert werden. --- **Kommende Anforderungen betrachten** Ein Service Review sollte auch nach vorne schauen. Beispiele: - neue Benutzergruppen, - steigende Nutzerzahlen, - neue Standorte, - neue gesetzliche Anforderungen, - Cloud-Migration, - neues Release, - Vertragsende, - End of Support, - neue Sicherheitsanforderungen, - geänderte Geschäftszeiten, - neue Schnittstellen, - geplante Umstrukturierung. So können notwendige Changes und Kapazitäten frühzeitig geplant werden. --- **Continual Improvement** Continual Improvement bedeutet, Services, Practices, Prozesse, Werkzeuge und Arbeitsweisen fortlaufend zu verbessern. Verbesserungen können klein oder groß sein. Beispiele: - Knowledge-Artikel korrigieren, - Monitoringalarm verbessern, - Formular vereinfachen, - OLA-Eskalation anpassen, - Zertifikatsüberwachung einführen, - Standard Change definieren, - Runbook aktualisieren, - Lieferantenvertrag verbessern, - Kapazität erweitern, - Self-Service automatisieren. Nicht jede Verbesserung benötigt ein großes Projekt. --- **Continual Improvement ist keine einmalige Maßnahme** Ein häufiger Irrtum: > Nach einem Verbesserungsprojekt ist der Service dauerhaft optimiert. Services verändern sich ständig. Gründe: - neue Anforderungen, - neue Technologien, - neue Benutzer, - neue Risiken, - neue Lieferanten, - neue Sicherheitslage, - neue Fehler, - neue gesetzliche Vorgaben. Deshalb ist Continual Improvement ein fortlaufender Kreislauf. --- **Verbesserungskreislauf** Ein möglicher Ablauf: aktuelle Situation verstehen ↓ Zielzustand festlegen ↓ Verbesserungspotenzial erkennen ↓ Maßnahme priorisieren ↓ Umsetzung planen ↓ Verbesserung durchführen ↓ Wirkung messen ↓ Ergebnis bewerten ↓ nächste Verbesserung auswählen Wichtig ist, nach der Umsetzung zu prüfen, ob die gewünschte Wirkung tatsächlich erreicht wurde. --- **Improvement Register** Ein Improvement Register sammelt Verbesserungsideen und Maßnahmen. Mögliche Felder: - Titel, - Beschreibung, - Auslöser, - betroffener Service, - erwarteter Nutzen, - Risiko, - Priorität, - Aufwand, - Owner, - Zieltermin, - Status, - Abhängigkeiten, - Erfolgskriterien, - Ergebnis. Das Improvement Register kann in einem ITSM-System, Projekttool, Wiki oder einer strukturierten Liste geführt werden. --- **Warum ein Improvement Register wichtig ist** Ohne zentrale Nachverfolgung entstehen typische Probleme: - gute Ideen gehen verloren, - Maßnahmen werden nicht zugewiesen, - gleiche Verbesserung wird mehrfach vorgeschlagen, - niemand kennt den Status, - dringende Themen verdrängen wichtige langfristige Maßnahmen, - Lessons Learned werden nicht umgesetzt. Das Register schafft Transparenz und Verantwortung. --- **Verbesserungsideen erfassen** Verbesserungsideen können entstehen aus: - Service Reviews, - Major Incidents, - Problem Management, - Failed Changes, - Benutzerfeedback, - Service Desk, - Audits, - Security Reviews, - Lieferantenreviews, - Datenqualitätsberichten, - Knowledge-Auswertungen, - Monitoringtrends, - Mitarbeitervorschlägen. Jede Idee sollte kurz beschreiben: - Was ist das Problem? - Welche Auswirkung besteht? - Welche Verbesserung wird vorgeschlagen? - Welcher Nutzen wird erwartet? --- **Verbesserungen priorisieren** Nicht alle Verbesserungen können gleichzeitig umgesetzt werden. Mögliche Kriterien: - geschäftlicher Nutzen, - Risiko, - Anzahl betroffener Benutzer, - Kritikalität des Services, - Sicherheitsrelevanz, - Häufigkeit des Problems, - Kosten, - Aufwand, - Dringlichkeit, - Abhängigkeiten, - gesetzliche Anforderungen, - erwartete Wirkung. Eine einfache Maßnahme mit hohem Nutzen kann vor einem großen Projekt sinnvoll sein. --- **Nutzen und Aufwand vergleichen** Eine einfache Bewertung kann helfen: | Nutzen | Aufwand | mögliche Priorität | |---|---|---| | hoch | niedrig | sehr hoch | | hoch | hoch | strategisch bewerten | | niedrig | niedrig | bei Gelegenheit | | niedrig | hoch | meist geringe Priorität | Diese Matrix ist nur ein Beispiel. Sicherheits- oder Compliance-Themen können unabhängig vom Aufwand hohe Priorität besitzen. --- **Erfolgskriterien für Verbesserungen** Vor Umsetzung sollte klar sein, woran Erfolg erkannt wird. Beispiele: | Verbesserung | Erfolgskriterium | |---|---| | Knowledge-Artikel verbessern | weniger Tickets und bessere Bewertungen | | Monitoring erweitern | Fehler wird vor Benutzerbeschwerden erkannt | | OLA anpassen | Eskalationszeit sinkt | | Self-Service einführen | Standardrequests werden schneller erfüllt | | Zertifikatsmonitoring einführen | keine ungeplanten Ausfälle durch Ablauf | | Change-Checkliste ergänzen | weniger Incidents nach Changes | Ohne Erfolgskriterien bleibt unklar, ob die Verbesserung wirksam war. --- **Kleine Verbesserungen** Kleine Verbesserungen können schnell Wirkung zeigen. Beispiele: - unklaren Artikeltitel ändern, - fehlenden Owner ergänzen, - Ticketformular vereinfachen, - Eskalationskontakt aktualisieren, - Monitoringgrenze korrigieren, - häufigen Workaround dokumentieren, - Service-Desk-Vorlage verbessern. Solche Verbesserungen sollten nicht unnötig durch große Prozesse verzögert werden. --- **Größere Verbesserungen** Größere Maßnahmen können sein: - Hochverfügbarkeit einführen, - Plattform migrieren, - neuen Service Desk einführen, - Lieferanten wechseln, - Self-Service-Portal aufbauen, - CMDB einführen, - Monitoring grundlegend modernisieren, - Service neu gestalten. Solche Maßnahmen benötigen oft: - Business Case, - Projekt, - Changes, - Risikoanalyse, - Budget, - Ressourcen, - Kommunikation, - und Erfolgsüberwachung. --- **Verbesserung und Change Enablement** Viele Verbesserungen werden durch Changes umgesetzt. Beispiele: - neue Monitoringregel, - Konfigurationsänderung, - Automatisierung, - Softwareupdate, - neuer Workflow, - neues Formular, - neue Plattform. Continual Improvement erkennt und priorisiert den Verbesserungsbedarf. Change Enablement sorgt für kontrollierte Umsetzung. --- **Verbesserung und Problem Management** Problem Management liefert Ursachen und dauerhafte Lösungsvorschläge. Beispiele: - wiederkehrende Incidents, - häufig genutzte Workarounds, - technische Schwachstellen, - unklare Abhängigkeiten, - fehlerhafte Versionen. Diese Erkenntnisse können als Improvement erfasst und priorisiert werden. --- **Verbesserung und Knowledge Management** Knowledge Management kann verbessert werden durch: - neue Artikel, - aktualisierte Runbooks, - bessere Suchbegriffe, - klarere Zielgruppen, - neue FAQ, - archivierte Altartikel, - bessere Verknüpfungen, - Review-Prozesse, - Feedbackauswertung. Wissen ist häufig eine schnelle und kostengünstige Verbesserungsmöglichkeit. --- **Verbesserung und Service Configuration Management** Configuration-Daten können verbessert werden durch: - fehlende CIs ergänzen, - Owner aktualisieren, - Beziehungen pflegen, - Zertifikate erfassen, - Cloud-Tags einführen, - Dubletten bereinigen, - Change-Prozess anbinden, - Service Maps erstellen. Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management. --- **Verbesserung und Supplier Management** Lieferantenverbesserungen können sein: - Eskalationsweg klären, - Supportzeiten anpassen, - Reporting verbessern, - Vertragsziel ändern, - Lieferantenreview einführen, - technische Alternative prüfen, - zusätzliche Redundanz schaffen, - Supportkompetenz intern aufbauen. Lieferantenleistung ist Teil der gesamten Servicequalität. --- **Verbesserungen verfolgen** Jede wichtige Maßnahme sollte mindestens besitzen: - klare Beschreibung, - Owner, - Priorität, - Zieltermin, - Status, - erwarteten Nutzen, - Erfolgskriterium. Ungeeignet: > Monitoring verbessern. Besser: > Bis zum 30.09.2026 Zertifikatsmonitoring für alle produktiven Webservices einführen. Erfolg: Warnung mindestens 30 Tage vor Ablauf, Owner je Zertifikat dokumentiert. --- **Status von Verbesserungen** Mögliche Status: - vorgeschlagen, - wird bewertet, - genehmigt, - geplant, - in Umsetzung, - blockiert, - umgesetzt, - Wirkung wird geprüft, - abgeschlossen, - verworfen. Ein klarer Status erleichtert Nachverfolgung. --- **Blockierte Verbesserungen** Verbesserungen können blockiert sein durch: - fehlendes Budget, - fehlende Ressourcen, - Lieferantenabhängigkeit, - technische Abhängigkeit, - fehlende Entscheidung, - Change Freeze, - Sicherheitsprüfung, - unklare Verantwortung. Blockierungen sollten sichtbar sein. Zu dokumentieren ist: - Ursache, - verantwortliche Stelle, - benötigte Entscheidung, - nächste Prüfung, - Risiko der Verzögerung. --- **Wirkung messen** Nach Umsetzung muss geprüft werden: - Hat sich die Kennzahl verbessert? - Ist das ursprüngliche Problem reduziert? - Sind Benutzer zufriedener? - Gibt es weniger Incidents? - Wurde das Risiko reduziert? - Funktioniert der neue Prozess? - Sind neue Nebenwirkungen entstanden? - Muss nachgebessert werden? Eine umgesetzte Maßnahme ist nicht automatisch eine erfolgreiche Verbesserung. --- **Verbesserung schließen** Eine Verbesserung sollte erst geschlossen werden, wenn: - Maßnahme umgesetzt wurde, - Ergebnis geprüft wurde, - Erfolgskriterien bewertet wurden, - Dokumentation aktualisiert wurde, - Rest Risiko bekannt ist, - Stakeholder informiert wurden, - und gegebenenfalls weitere Maßnahmen erfasst wurden. Wenn die Wirkung noch nicht messbar ist, kann der Status „Wirkung wird geprüft“ sinnvoll sein. --- **Service Review dokumentieren** Ein Service Review sollte dokumentieren: - Datum, - Teilnehmer, - betrachteter Zeitraum, - wichtigste Kennzahlen, - Abweichungen, - Risiken, - Entscheidungen, - Maßnahmen, - Owner, - Termine, - offene Fragen, - nächster Review-Termin. Die Dokumentation sollte kompakt und handlungsorientiert sein. --- **Entscheidungen dokumentieren** Wichtige Entscheidungen können sein: - SLA-Ziel anpassen, - Problem Record priorisieren, - Change starten, - Lieferant eskalieren, - Risiko akzeptieren, - zusätzliche Kapazität bereitstellen, - Serviceumfang ändern, - Knowledge verbessern, - Monitoring erweitern. Zu jeder Entscheidung sollte nachvollziehbar sein: - wer entschieden hat, - warum entschieden wurde, - welche Auswirkung erwartet wird, - und wann überprüft wird. --- **Maßnahmenprotokoll** Ein einfaches Maßnahmenprotokoll: | Maßnahme | Owner | Termin | Status | Erfolgskriterium | |---|---|---|---|---| | VPN-Known-Error aktualisieren | Netzwerkteam | 15.08.2026 | offen | Service Desk findet Artikel | | Zertifikatsmonitoring einführen | Plattformteam | 30.09.2026 | geplant | Warnung 30 Tage vor Ablauf | | OLA-Eskalation anpassen | Service Level Manager | 31.08.2026 | in Arbeit | kürzere P1-Eskalationszeit | Ein Maßnahmenprotokoll verhindert, dass Entscheidungen nach dem Review verloren gehen. --- **Folgereview** Im nächsten Service Review sollte geprüft werden: - Wurden Maßnahmen umgesetzt? - Wurden Termine eingehalten? - Welche Wirkung ist erkennbar? - Welche Blockierungen bestehen? - Muss eine Maßnahme angepasst werden? - Sind neue Risiken entstanden? - Kann eine Verbesserung geschlossen werden? Ohne Folgereview verlieren Maßnahmen schnell an Verbindlichkeit. --- **Praxisbeispiel: Wiederkehrende VPN-Incidents** **Beobachtung** VPN-Incidents steigen über drei Monate. **Service Review** - betroffene Clientversion identifiziert, - Workaround wird häufig genutzt, - Benutzerfeedback negativ, - Known Error vorhanden, - dauerhafte Lösung noch nicht umgesetzt. **Verbesserung** - neue Clientversion pilotieren, - Rollout planen, - Knowledge-Artikel aktualisieren, - Incident-Trend nach Rollout prüfen. **Erfolgskriterium** VPN-Incidents sinken innerhalb von vier Wochen deutlich. --- **Praxisbeispiel: SLA erfüllt, Benutzer unzufrieden** **Beobachtung** Verfügbarkeitsziel wurde erreicht. Benutzer melden trotzdem schlechte Performance. **Service Review** - Verfügbarkeit misst nur Erreichbarkeit, - Antwortzeiten werden nicht betrachtet, - Fachbereich meldet lange Ladezeiten. **Verbesserung** - Performance-Kennzahl ergänzen, - synthetische Transaktion einführen, - Kapazitätsanalyse starten, - Benutzerfeedback im nächsten Review prüfen. --- **Praxisbeispiel: Lieferantenproblem** **Beobachtung** Mehrere SLA-Abweichungen entstehen durch langsame Herstellerreaktion. **Service Review** - Underpinning Contract passt nicht zum internen SLA, - Eskalationsweg ist unklar, - kein technischer Workaround vorhanden. **Verbesserung** - Lieferantenvertrag prüfen, - Eskalationsweg definieren, - interne technische Kompetenz ausbauen, - SLA-Risiko transparent machen. --- **Praxisbeispiel: Major Incident** **Review-Erkenntnisse** - Monitoring erkannte Fehler zu spät, - Service Desk hatte kein aktuelles Runbook, - Statuskommunikation war uneinheitlich, - Owner war unklar. **Verbesserungen** - Monitoring erweitern, - Runbook aktualisieren, - Kommunikationsvorlage erstellen, - Ownership im Major-Incident-Prozess festlegen, - Wirksamkeit bei nächster Übung prüfen. --- **Praxisbeispiel: Self-Service verbessern** **Beobachtung** Viele Tickets entstehen zur MFA-Einrichtung. **Analyse** - Artikel schwer auffindbar, - Suchbegriffe fehlen, - Formular ist kompliziert, - Benutzer besitzen neues Smartphone. **Verbesserungen** - neuen Artikel erstellen, - Suchbegriffe ergänzen, - Formular vereinfachen, - Self-Service-Link im Onboarding ergänzen. **Erfolgskriterium** Weniger MFA-Standardtickets und bessere Artikelbewertung. --- **Typische Fehler** **Fehler 1** Service Reviews bestehen nur aus dem Vorlesen von Kennzahlen. --- **Fehler 2** Es nehmen zu viele Personen ohne klare Rolle teil. --- **Fehler 3** Benutzer- und Fachbereichsfeedback fehlt. --- **Fehler 4** Grüne Kennzahlen werden nicht kritisch hinterfragt. --- **Fehler 5** SLA-Abweichungen werden erklärt, aber keine Maßnahmen beschlossen. --- **Fehler 6** Maßnahmen besitzen keinen Owner. --- **Fehler 7** Verbesserungen besitzen kein Erfolgskriterium. --- **Fehler 8** Lessons Learned werden nicht verfolgt. --- **Fehler 9** Lieferantenleistung wird getrennt vom Service betrachtet. --- **Fehler 10** Reviews schauen nur zurück und nicht auf kommende Risiken. --- **Fehler 11** Umgesetzte Maßnahmen werden nicht auf Wirkung geprüft. --- **Fehler 12** Verbesserungsideen gehen außerhalb eines Registers verloren. --- **Checkliste Service Review vorbereiten** - [ ] betrachteter Service ist klar - [ ] Berichtszeitraum festgelegt - [ ] SLA- und Kennzahlendaten vorhanden - [ ] Datenqualität geprüft - [ ] wichtige Incidents ausgewählt - [ ] Major Incidents berücksichtigt - [ ] offene Problems und Known Errors geprüft - [ ] Changes und Releases berücksichtigt - [ ] Benutzerfeedback gesammelt - [ ] Lieferantenleistung geprüft - [ ] Risiken aktualisiert - [ ] offene Maßnahmen aus letztem Review geprüft - [ ] passende Teilnehmer eingeladen --- **Checkliste Service Review durchführen** - [ ] Gesamtzustand des Services bewertet - [ ] Zielerreichung geprüft - [ ] SLA-Abweichungen analysiert - [ ] Benutzererfahrung berücksichtigt - [ ] Incident-Trends betrachtet - [ ] Problems und Workarounds geprüft - [ ] Change- und Release-Wirkung bewertet - [ ] Lieferantenleistung betrachtet - [ ] kommende Risiken besprochen - [ ] Verbesserungen priorisiert - [ ] Entscheidungen dokumentiert - [ ] Owner und Termine festgelegt --- **Checkliste Improvement Register** - [ ] Verbesserung verständlich beschrieben - [ ] Auslöser dokumentiert - [ ] betroffener Service genannt - [ ] erwarteter Nutzen beschrieben - [ ] Risiko bewertet - [ ] Priorität festgelegt - [ ] Aufwand grob bewertet - [ ] Owner benannt - [ ] Zieltermin festgelegt - [ ] Abhängigkeiten dokumentiert - [ ] Erfolgskriterium definiert - [ ] Status aktuell --- **Checkliste Wirkung prüfen** - [ ] Maßnahme vollständig umgesetzt - [ ] Erfolgskriterium messbar - [ ] Kennzahl vor und nach Verbesserung verglichen - [ ] Benutzerfeedback berücksichtigt - [ ] Incident-Entwicklung geprüft - [ ] Risiken neu bewertet - [ ] Nebenwirkungen geprüft - [ ] Dokumentation aktualisiert - [ ] Stakeholder informiert - [ ] weitere Maßnahme bei Bedarf erfasst - [ ] Verbesserung abgeschlossen oder angepasst --- **Checkliste Maßnahmenverfolgung** - [ ] jede Maßnahme besitzt Owner - [ ] jeder Termin ist realistisch - [ ] Status wird regelmäßig aktualisiert - [ ] Blockierungen sind sichtbar - [ ] benötigte Entscheidungen sind benannt - [ ] Risiko bei Verzögerung ist bekannt - [ ] Wirkung wird im nächsten Review geprüft - [ ] abgeschlossene Maßnahmen werden dokumentiert - [ ] offene Maßnahmen werden nicht vergessen --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker liefern wichtige technische Erkenntnisse für Service Reviews und Continual Improvement. Im Arbeitsalltag bedeutet das: - Incident- und Monitoringdaten verständlich einordnen, - technische Risiken früh melden, - wiederkehrende Fehler sichtbar machen, - Workarounds und Known Errors bewerten, - Verbesserungen an Monitoring und Runbooks vorschlagen, - Change-Ergebnisse dokumentieren, - Configuration-Daten aktuell halten, - und die Wirkung technischer Maßnahmen überprüfen. Technische Verbesserung ist besonders wertvoll, wenn sie messbar zu stabileren Services und besserer Benutzerunterstützung führt. --- **Zusammenfassung** > Serviceleistung und Benutzerfeedback sammeln > ↓ > Service Review vorbereiten > ↓ > Ziele, Abweichungen und Risiken bewerten > ↓ > Incidents, Problems, Changes und Lieferanten betrachten > ↓ > Verbesserungen identifizieren > ↓ > Nutzen, Risiko und Aufwand bewerten > ↓ > Maßnahmen priorisieren > ↓ > Owner, Termin und Erfolgskriterien festlegen > ↓ > Verbesserung kontrolliert umsetzen > ↓ > Wirkung messen > ↓ > Ergebnis im nächsten Service Review prüfen --- **Merksätze** > Ein Service Review macht aus Reporting konkrete Entscheidungen. > Grüne Kennzahlen bedeuten nicht automatisch gute Servicequalität. > Benutzerfeedback gehört genauso zum Review wie technische Messwerte. > Jede wichtige Verbesserung braucht Owner, Termin und Erfolgskriterium. > Eine umgesetzte Maßnahme ist erst erfolgreich, wenn ihre Wirkung geprüft wurde. > Continual Improvement besteht aus vielen kleinen und großen Verbesserungen. > Reviews müssen auch kommende Risiken und Anforderungen betrachten. --- **Verwandte Seiten** - 8.1 Service Level Management – Ziele, Begriffe und Grundlagen - 8.2 SLA, SLR, OLA und Underpinning Contracts - 8.3 Kennzahlen, Messmethoden und Reporting - 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management - Continual Improvement - Measurement and Reporting - Incident Management - Problem Management - Change Enablement - Supplier Management - Knowledge Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Continual Improvement - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Supplier Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Review-Agenda, - Improvement-Register-Struktur, - Priorisierungskriterien, - Maßnahmenprotokolle, - Checklisten, - Erfolgskriterien, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Service-Review-Agenda, - Review-Frequenz, - Teilnehmerliste, - Improvement-Register-Vorlage, - Priorisierungsmatrix, - Maßnahmenstruktur, - oder Reporting-Form für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Kritikalität, - Kunden, - Benutzergruppen, - Risiken, - Organisationsgröße, - Supportmodell, - Lieferanten, - Datenqualität, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management > **Kurz erklärt** > > Service Level Management kann Servicequalität nicht allein steuern. > > Es benötigt Informationen aus Incident Management, Problem Management, Change Enablement, Service Configuration Management, Knowledge Management, Supplier Management sowie Measurement and Reporting. > > Gleichzeitig liefert Service Level Management Ziele, Prioritäten und Anforderungen zurück, an denen diese Practices ihre Arbeit ausrichten können. > > Erst durch dieses Zusammenspiel werden Servicequalität, Risiken und Verbesserungsbedarf aus Sicht der Benutzer und des Geschäfts sichtbar. --- **Warum das Zusammenspiel wichtig ist** Ein Service Level beschreibt, welche Qualität ein Service erreichen soll. Ob diese Qualität tatsächlich erreicht wird, hängt jedoch von vielen Bereichen ab. Beispiele: - Incident Management stellt gestörte Services wieder her. - Problem Management untersucht wiederkehrende Ursachen. - Change Enablement steuert Änderungen am Service. - Service Configuration Management zeigt technische Abhängigkeiten. - Knowledge Management stellt Lösungen und Workarounds bereit. - Supplier Management steuert externe Lieferanten. - Monitoring and Event Management liefert Zustandsdaten. - Measurement and Reporting bereitet Kennzahlen auf. - Continual Improvement verfolgt Verbesserungsmaßnahmen. Service Level Management verbindet diese Informationen mit den vereinbarten Servicezielen. --- **Grundidee des Zusammenspiels** Serviceziele und Erwartungen festlegen ↓ Service Level Management definiert messbare Ziele ↓ Incident Management liefert Störungs- und Wiederherstellungsdaten ↓ Problem Management untersucht wiederkehrende Ursachen ↓ Change Enablement setzt Verbesserungen kontrolliert um ↓ Service Configuration Management zeigt Abhängigkeiten ↓ Knowledge Management stellt nutzbares Wissen bereit ↓ Supplier Management bewertet externe Beiträge ↓ Measurement and Reporting zeigt Ergebnisse und Trends ↓ Service Review bewertet Abweichungen und Risiken ↓ Continual Improvement verfolgt Verbesserungen Die Practices arbeiten nicht nacheinander in einer festen Reihenfolge. Sie tauschen fortlaufend Informationen aus. --- **Service Level Management und Incident Management** Incident Management liefert wichtige Informationen darüber, wie stabil und zuverlässig ein Service im Alltag funktioniert. Relevante Informationen: - Anzahl der Incidents je Service, - Prioritäten, - Auswirkung und Dringlichkeit, - Reaktionszeiten, - Wiederherstellungszeiten, - Lösungszeiten, - Major Incidents, - Eskalationen, - Wiedereröffnungen, - Incidents nach Changes, - betroffene Benutzer und Standorte, - verwendete Workarounds, - Benutzerfeedback. Diese Daten helfen zu prüfen, ob vereinbarte Serviceziele erreicht werden. --- **Was Service Level Management an Incident Management liefert** Service Level Management unterstützt Incident Management durch: - vereinbarte Servicezeiten, - Supportzeiten, - Prioritätsregeln, - Reaktionsziele, - Wiederherstellungsziele, - Kommunikationsanforderungen, - Eskalationsregeln, - Kritikalität der Services, - vereinbarte Statusintervalle, - und Erwartungen der Kunden. Dadurch weiß Incident Management, welche Incidents besonders schnell und intensiv bearbeitet werden müssen. --- **Service Level und Incident-Priorität** Die Priorität eines Incidents sollte nicht allein von der Lautstärke eines Benutzers oder der technischen Komplexität abhängen. Zu berücksichtigen sind: - betroffener Service, - Servicekritikalität, - Anzahl betroffener Benutzer, - betroffener Geschäftsprozess, - Dringlichkeit, - vorhandener Workaround, - Sicherheits- oder Datenschutzbezug, - Servicezeit, - vereinbarte Serviceziele. Beispiel: Ein technisch kleiner Fehler kann hohe Priorität besitzen, wenn ein geschäftskritischer Prozess vollständig blockiert wird. --- **Reaktionszeit im Incident Management** Service Level Management definiert möglicherweise ein Reaktionsziel. Incident Management muss dafür nachvollziehbar erfassen: - Zeitpunkt des Eingangs, - Zeitpunkt der Priorisierung, - Zeitpunkt der ersten qualifizierten Bearbeitung, - Zeitpunkt der ersten Benutzerinformation, - Supportzeit, - Wartezeiten, - Eskalationen. Eine automatische Eingangsbestätigung sollte nicht mit einer qualifizierten Bearbeitung verwechselt werden. --- **Wiederherstellung und dauerhafte Lösung unterscheiden** Incident Management konzentriert sich auf die schnelle Wiederherstellung des Service. Service Level Management kann deshalb ein Ziel für die Wiederherstellungszeit besitzen. Beispiel: Ein Workaround macht Benutzer nach zwei Stunden wieder arbeitsfähig. Die dauerhafte Lösung erfolgt erst eine Woche später durch einen Change. Dann gilt: - Service wurde nach zwei Stunden wiederhergestellt. - Das zugrunde liegende Problem blieb zunächst bestehen. - Die endgültige Lösung erfolgte später. Diese Zeitpunkte sollten getrennt gemessen werden. --- **SLA-Verletzung durch Incident** Wenn ein Incident zu einer SLA-Verletzung führt, sollte geprüft werden: - Wurde der Incident richtig priorisiert? - War der Service korrekt zugeordnet? - Wurde rechtzeitig eskaliert? - Waren Zuständigkeiten klar? - War ein Workaround bekannt? - War die Kommunikation ausreichend? - Haben interne OLAs funktioniert? - Hat ein Lieferant verzögert? - War das Ziel realistisch? - Ist ein Problem Record erforderlich? Eine SLA-Verletzung ist häufig nicht nur ein technisches Ereignis. Sie kann auch organisatorische Ursachen besitzen. --- **Beispiel: verspätete Eskalation** **Situation** Ein geschäftskritischer Service fällt aus. **SLA-Ziel** Wiederherstellung innerhalb von vier Stunden. **Problem** Der Service Desk eskaliert erst nach zwei Stunden an das zuständige Fachteam. **Folge** Das Wiederherstellungsziel wird verfehlt. **Analyse** - CI-Zuordnung war unklar. - Eskalationskriterien fehlten. - OLA mit dem Fachteam war nicht eindeutig. - Kein passender Knowledge-Artikel war vorhanden. **Verbesserungen** - Eskalationsregel überarbeiten, - OLA präzisieren, - Service- und CI-Zuordnung verbessern, - Knowledge-Artikel erstellen, - Service Desk schulen. --- **Service Level Management und Problem Management** Problem Management untersucht Ursachen wiederkehrender oder schwerwiegender Incidents. Service Level Management hilft dabei, Problems zu priorisieren. Relevante Kriterien: - wiederholte SLA-Verletzungen, - hohe Anzahl ähnlicher Incidents, - lange Wiederherstellungszeiten, - kritischer Service betroffen, - hohe geschäftliche Auswirkung, - häufig genutzter Workaround, - starke Benutzerunzufriedenheit, - Lieferantenabhängigkeit, - Sicherheitsrisiko, - steigender Trend. Ein Problem kann hohe Priorität besitzen, auch wenn aktuell kein Incident offen ist. --- **Was Problem Management an Service Level Management liefert** Problem Management liefert: - Ursache oder wahrscheinliche Ursache, - Known Errors, - Workarounds, - betroffene Services, - betroffene Versionen, - technische und organisatorische Risiken, - dauerhafte Lösungsvorschläge, - geplante Changes, - erwartete Dauer bis zur Lösung, - verbleibendes Risiko. Diese Informationen helfen, Servicequalität und zukünftige Risiken realistisch zu bewerten. --- **Häufige Workarounds als Service-Level-Risiko** Ein Workaround kann die Wiederherstellung beschleunigen. Wenn er jedoch ständig genutzt wird, kann dies auf ein ungelöstes Problem hinweisen. Zu prüfen ist: - Wie oft wird der Workaround verwendet? - Wie viel Arbeitszeit verursacht er? - Wie stark beeinträchtigt er Benutzer? - Welche Risiken bestehen? - Ist er zuverlässig? - Gibt es eine dauerhafte Lösung? - Warum wurde sie noch nicht umgesetzt? - Wird das SLA nur durch den Workaround formal eingehalten? Ein erreichtes SLA bedeutet nicht automatisch, dass der Service gesund ist. --- **Beispiel: Dienstneustart als Workaround** **Situation** Ein Anwendungsdienst fällt regelmäßig aus. **Workaround** Der Service Desk veranlasst einen Neustart. **Kennzahl** Die Wiederherstellungszeit bleibt innerhalb des SLA. **Tatsächliches Problem** - Service ist regelmäßig instabil. - Benutzer werden häufig unterbrochen. - Fachteam investiert wiederholt Zeit. - Ursache ist weiterhin offen. **Verbesserung** Problem Record priorisieren und dauerhafte Lösung über Change Enablement umsetzen. --- **Problem-Priorisierung nach Servicewirkung** Problem Management sollte nicht nur technische Schwere betrachten. Wichtige Fragen: - Welches SLA wird gefährdet? - Welche Serviceziele werden wiederholt verfehlt? - Welche Benutzergruppen sind betroffen? - Welche Geschäftsprozesse hängen davon ab? - Gibt es einen sicheren Workaround? - Wie häufig tritt der Fehler auf? - Welche Kosten entstehen? - Welche Risiken entstehen bei Nicht-Handeln? Service Level Management liefert dafür die geschäftliche und servicebezogene Perspektive. --- **Service Level Management und Change Enablement** Changes können Servicequalität verbessern oder verschlechtern. Beispiele: - Fehlerbehebung, - Sicherheitsupdate, - Performance-Optimierung, - Kapazitätserweiterung, - neue Funktion, - Plattformmigration, - Firewall-Anpassung, - Zertifikatserneuerung, - Monitoring-Erweiterung. Service Level Management hilft zu bewerten, welche Serviceziele durch einen Change beeinflusst werden. --- **Was Service Level Management an Change Enablement liefert** Für die Change-Bewertung sind wichtig: - Kritikalität des betroffenen Service, - vereinbarte Servicezeit, - Wartungsfenster, - Verfügbarkeitsziele, - Performance-Ziele, - betroffene Benutzergruppen, - Wiederherstellungsanforderungen, - Lieferantenabhängigkeiten, - Kommunikationsanforderungen, - mögliche SLA-Auswirkungen. Dadurch kann ein Change nicht nur technisch, sondern auch servicebezogen bewertet werden. --- **Was Change Enablement an Service Level Management liefert** Change Enablement liefert: - geplante Änderungen, - betroffene Services und CIs, - erwartete Ausfallzeiten, - Risiken, - Wartungsfenster, - Rollback-Möglichkeiten, - Testergebnisse, - Failed Changes, - Incidents nach Changes, - erwarteten Nutzen, - und Ergebnisse der Nachprüfung. Diese Informationen gehören in Service Reviews und Service-Level-Berichte. --- **Geplante Wartung und Service Levels** Geplante Wartung muss klar geregelt sein. Zu prüfen ist: - Liegt die Wartung im vereinbarten Wartungsfenster? - Wurde sie rechtzeitig angekündigt? - Wird sie aus der Verfügbarkeitsberechnung ausgeschlossen? - Welche Benutzer sind betroffen? - Wurde das Wartungsfenster überschritten? - Gab es ungeplante Nebenwirkungen? - Sind abhängige Services betroffen? - Wurde der Service Desk informiert? Nicht jede angekündigte Unterbrechung darf automatisch aus der Messung ausgeschlossen werden. Die Regeln müssen vorher vereinbart sein. --- **Change Freeze und kritische Geschäftszeiten** Service Level Management hilft zu erkennen, wann Changes besonders riskant sind. Beispiele: - Monatsabschluss, - Jahresabschluss, - Verkaufsaktion, - Produktionshochlauf, - Prüfungszeitraum, - wichtige Veranstaltung, - gesetzliche Meldefrist, - hohe saisonale Nutzung. In solchen Zeiträumen kann ein Change Freeze oder eine besonders strenge Bewertung sinnvoll sein. Emergency Changes können trotzdem notwendig sein. Sie benötigen dann eine bewusste Risikoentscheidung. --- **Changes zur Verbesserung von Service Levels** Wenn Serviceziele regelmäßig verfehlt werden, können Changes notwendig sein. Beispiele: - zusätzliche Kapazität bereitstellen, - Hochverfügbarkeit einführen, - Monitoring erweitern, - fehlerhafte Version aktualisieren, - Automatisierung einführen, - Eskalationsworkflow verbessern, - Knowledge Base aktualisieren, - redundante Verbindung einrichten, - Backup- und Restore-Verfahren verbessern. Service Level Management beschreibt den Verbesserungsbedarf. Change Enablement steuert die kontrollierte Umsetzung. --- **Beispiel: Performance-Ziel wird verfehlt** **Beobachtung** Das Mitarbeiterportal ist verfügbar, reagiert aber zu langsam. **Service Review** Das vereinbarte Performance-Ziel wird regelmäßig verfehlt. **Analyse** - Datenbank ist ausgelastet. - Nutzerzahl ist gestiegen. - Kapazitätsplanung wurde nicht angepasst. - Monitoring zeigt nur Verfügbarkeit. **Changes** - Datenbankressourcen erweitern, - Abfragen optimieren, - Performance-Monitoring ergänzen, - Lasttest einführen. **Erfolgskriterium** Die wichtigsten Benutzeraktionen liegen wieder innerhalb des vereinbarten Zielwerts. --- **Service Level Management und Service Configuration Management** Service Configuration Management zeigt, wie ein Service technisch und organisatorisch aufgebaut ist. Wichtige Informationen: - Configuration Items, - Serviceabhängigkeiten, - Versionen, - Standorte, - Owner, - Supportgruppen, - Lieferanten, - Zertifikate, - Schnittstellen, - Monitoring, - Backup, - Kritikalität. Diese Informationen sind notwendig, um Service Levels realistisch festzulegen und Risiken zu verstehen. --- **Warum Serviceabhängigkeiten für SLAs wichtig sind** Ein Service kann nur so zuverlässig sein wie seine kritischen Abhängigkeiten. Beispiel: Das Mitarbeiterportal hängt ab von: - Webserver, - Datenbank, - Identity Provider, - Netzwerk, - DNS, - Zertifikat, - Cloud-Plattform, - externem Lieferanten. Ein hohes Verfügbarkeitsziel ist unrealistisch, wenn eine kritische Abhängigkeit deutlich schwächere Ziele oder keine Redundanz besitzt. --- **Configuration-Daten für SLA-Planung** Zu prüfen ist: - Welche CIs unterstützen den Service? - Welche CIs sind Single Points of Failure? - Welche Komponenten besitzen keinen Owner? - Welche Lieferanten sind beteiligt? - Welche Versionen sind im Einsatz? - Welche Zertifikate oder Lizenzen können ablaufen? - Welche Systeme besitzen keine ausreichende Überwachung? - Welche Abhängigkeiten sind nicht redundant? - Welche CIs haben besonders viele Incidents? Diese Informationen helfen, Serviceziele realistisch zu gestalten. --- **Service Level Management verbessert Configuration Management** Service Reviews können Datenqualitätsprobleme sichtbar machen. Beispiele: - Incident wurde falschem Service zugeordnet. - Kritisches CI besitzt keinen Owner. - Lieferantenbeziehung fehlt. - Service Map ist unvollständig. - Zertifikat ist nicht als CI erfasst. - veraltete Anwendungsversion ist dokumentiert. - Monitoring ist nicht mit dem Service verknüpft. Solche Erkenntnisse sollten in die Pflege der Configuration-Daten einfließen. --- **Beispiel: unbekannte Abhängigkeit** **Situation** Ein interner Service verfehlt sein Verfügbarkeitsziel. **Analyse** Der Service hängt von einer externen API ab. Diese Beziehung war in der CMDB nicht dokumentiert. **Folgen** - Lieferantenabhängigkeit wurde im SLA nicht berücksichtigt. - Monitoring prüfte die API nicht. - Eskalationsweg war unklar. **Verbesserungen** - API als relevante Abhängigkeit dokumentieren, - Lieferant zuordnen, - Monitoring ergänzen, - SLA und Underpinning Contract prüfen. --- **Service Level Management und Knowledge Management** Knowledge Management beeinflusst Reaktions- und Wiederherstellungszeiten. Gutes Wissen kann: - Erstdiagnose beschleunigen, - bekannte Fehler schneller erkennen, - Workarounds bereitstellen, - Eskalationen verbessern, - Benutzerkommunikation vereinheitlichen, - Self-Service ermöglichen, - und wiederkehrende Tickets reduzieren. Knowledge Management trägt damit direkt zur Servicequalität bei. --- **Was Service Level Management an Knowledge Management liefert** Service Level Management zeigt, bei welchen Services und Themen Wissen besonders wichtig ist. Beispiele: - Service mit vielen Incidents, - häufige SLA-Verletzungen, - lange Wiederherstellungszeiten, - viele Eskalationen, - hohe Zahl wiederkehrender Requests, - häufig genutzte Workarounds, - schlechte Benutzerbewertungen, - unklare Statuskommunikation. Daraus können neue oder verbesserte Knowledge-Artikel entstehen. --- **Was Knowledge Management an Service Level Management liefert** Knowledge Management liefert: - Nutzung von Knowledge-Artikeln, - Suchanfragen ohne Treffer, - häufig genutzte Workarounds, - Artikelbewertungen, - Knowledge-Lücken, - Self-Service-Erfolgsdaten, - Runbooks, - Known Errors, - Benutzerfeedback. Diese Informationen helfen zu verstehen, warum bestimmte Serviceziele erreicht oder verfehlt werden. --- **Beispiel: lange Wiederherstellungszeit** **Beobachtung** DNS-Incidents werden regelmäßig zu spät gelöst. **Analyse** - Service Desk besitzt keine einheitlichen Prüfschritte. - Eskalationen enthalten unvollständige Informationen. - Fachteam wiederholt immer dieselbe Diagnose. **Verbesserungen** - Service-Desk-Artikel erstellen, - Diagnose-Checkliste ergänzen, - Eskalationsanforderungen definieren, - Knowledge-Nutzung im Ticket messen. **Erwartete Wirkung** Kürzere Erstdiagnose und schnellere Wiederherstellung. --- **Service Level Management und Supplier Management** Viele Services hängen von externen Lieferanten ab. Beispiele: - Cloud-Anbieter, - Internetprovider, - Softwarehersteller, - Hardwarewartung, - Rechenzentrum, - SaaS-Anbieter, - Telekommunikationsanbieter. Supplier Management sorgt dafür, dass Lieferantenleistungen die vereinbarten Serviceziele unterstützen. --- **Was Service Level Management an Supplier Management liefert** Supplier Management benötigt: - relevante SLA-Ziele, - kritische Services, - Supportzeiten, - Wiederherstellungsziele, - Verfügbarkeitsziele, - Sicherheitsanforderungen, - Eskalationsanforderungen, - Reportingbedarf, - Wartungsfenster, - und Risiken. Daraus können geeignete Lieferantenverträge und Leistungsziele abgeleitet werden. --- **Was Supplier Management an Service Level Management liefert** Supplier Management liefert: - Vertragsziele, - tatsächliche Lieferantenleistung, - Supportzeiten, - Eskalationswege, - Vertragsverletzungen, - geplante Wartungen, - Herstellerprobleme, - Lieferantenrisiken, - End-of-Support-Termine, - und Verbesserungsmaßnahmen. Diese Informationen gehören in Service Reviews. --- **Lieferantenvertrag und internes SLA abstimmen** Ein internes SLA darf nicht stärker sein als die tatsächlich verfügbare Unterstützung, sofern keine eigenen Schutzmaßnahmen bestehen. Beispiel: **Internes Ziel** Wiederherstellung innerhalb von vier Stunden. **Lieferantenvertrag** Hersteller reagiert innerhalb eines Arbeitstages. Mögliche Lösungen: - Vertrag verbessern, - internes Fachwissen erweitern, - Redundanz aufbauen, - Workaround entwickeln, - internes SLA anpassen, - Risiko dokumentieren und akzeptieren. --- **Service Level Management und Monitoring and Event Management** Monitoring liefert technische und servicebezogene Messdaten. Beispiele: - Verfügbarkeit, - Antwortzeiten, - Transaktionsfehler, - Kapazität, - Schnittstellenzustand, - Zertifikatsablauf, - Backupstatus, - Datenbankzustand, - Anmeldefunktion. Service Level Management definiert, welche Serviceeigenschaften gemessen werden müssen. --- **Monitoring aus Serviceperspektive** Unzureichend: > Webserver antwortet auf Ping. Besser: - Startseite ist erreichbar. - Anmeldung funktioniert. - zentrale Benutzeraktion ist erfolgreich. - abhängige Schnittstelle antwortet. - Antwortzeit liegt im Zielbereich. Ein Service kann technisch „grün“ erscheinen, obwohl Benutzer nicht arbeiten können. --- **Monitoring und Messmethode abstimmen** Zu klären ist: - Welche Messpunkte entsprechen dem SLA? - Wird während der richtigen Servicezeit gemessen? - Werden geplante Wartungen gekennzeichnet? - Werden Teilausfälle erkannt? - Werden alle relevanten Standorte berücksichtigt? - Werden technische und synthetische Tests kombiniert? - Werden Alarme einem Service und Owner zugeordnet? - Sind Messdaten für Reporting verfügbar? Monitoring muss zu den vereinbarten Zielen passen. --- **Service Level Management und Measurement and Reporting** Measurement and Reporting bereitet Daten so auf, dass Servicequalität bewertet werden kann. Service Level Management liefert dafür: - Zielwerte, - Servicezeiten, - Messdefinitionen, - relevante Kennzahlen, - Ausnahmen, - Zielgruppen, - Reportingfrequenz, - und Reviewanforderungen. Measurement and Reporting liefert: - Ist-Werte, - Trends, - Abweichungen, - Datenqualitätsinformationen, - Dashboards, - Reports, - und Vergleichswerte. --- **Reporting braucht Kontext aus anderen Practices** Eine Zahl allein erklärt nicht, warum ein Ziel verfehlt wurde. Beispiel: Verfügbarkeit beträgt 98,9 Prozent statt 99,5 Prozent. Für eine sinnvolle Bewertung werden zusätzliche Informationen benötigt: - Incident Management: Welche Ausfälle traten auf? - Problem Management: Welche Ursachen sind bekannt? - Change Enablement: Gab es einen Change davor? - Configuration Management: Welche Abhängigkeit war betroffen? - Supplier Management: War ein Lieferant beteiligt? - Knowledge Management: Gab es einen Workaround? - Continual Improvement: Welche Maßnahmen laufen? Reporting verbindet diese Informationen. --- **Service Level Management und Continual Improvement** Service Level Management erkennt Abweichungen und Verbesserungspotenziale. Continual Improvement sorgt dafür, dass daraus konkrete Maßnahmen entstehen. Mögliche Verbesserungen: - SLA-Ziel anpassen, - Monitoring erweitern, - Problem Record priorisieren, - Workaround dokumentieren, - Change durchführen, - OLA verbessern, - Lieferantenvertrag anpassen, - Configuration-Daten pflegen, - Self-Service verbessern, - Kapazität erweitern, - Benutzerkommunikation verbessern. --- **Verbesserungen aus Service Reviews** Ein möglicher Ablauf: Serviceziel wird verfehlt ↓ Abweichung wird im Report sichtbar ↓ Service Review bewertet Ursache und Auswirkung ↓ Improvement wird erfasst ↓ Owner, Termin und Erfolgskriterium werden festgelegt ↓ Problem, Change, Knowledge oder Supplier Management wird eingebunden ↓ Maßnahme wird umgesetzt ↓ Wirkung wird gemessen ↓ Ergebnis wird im nächsten Service Review geprüft So wird aus einer Kennzahl eine konkrete Verbesserung. --- **Service-Level-Ziele überprüfen** Nicht jede wiederholte Zielverfehlung bedeutet, dass das Ziel gesenkt werden sollte. Zu prüfen ist: - Ist das Ziel weiterhin fachlich notwendig? - Ist die Messmethode korrekt? - Sind Daten zuverlässig? - Sind Ressourcen ausreichend? - Haben sich Anforderungen verändert? - Ist die technische Architektur geeignet? - Unterstützen Lieferanten das Ziel? - Gibt es unverhältnismäßige Kosten? - Welche Risiken entstehen bei Anpassung? Ziele sollten realistisch, aber nicht bequem sein. --- **Neue Service-Level-Ziele aus Verbesserungen** Neue Erkenntnisse können zusätzliche Ziele erforderlich machen. Beispiele: - Performance-Ziel ergänzen, - Statuskommunikation bei Major Incidents definieren, - Self-Service-Erfolgsziel aufnehmen, - Restore-Test-Ziel festlegen, - Lieferantenreaktion messen, - Knowledge-Aktualisierung nach Changes prüfen, - Benutzererfahrung berücksichtigen. Service Levels sollten sich mit dem Service weiterentwickeln. --- **Rollen und Verantwortlichkeiten im Zusammenspiel** | Rolle oder Practice | Beitrag | |---|---| | **Service Owner** | verantwortet Servicequalität und Prioritäten | | **Service Level Management** | definiert, misst und überprüft Serviceziele | | **Service Desk** | liefert Benutzerfeedback und Incident-Daten | | **Incident Management** | stellt Services wieder her | | **Problem Management** | untersucht Ursachen und Wiederholungen | | **Change Enablement** | setzt Änderungen kontrolliert um | | **Configuration Management** | liefert Services, CIs und Abhängigkeiten | | **Knowledge Management** | stellt Lösungen und Workarounds bereit | | **Supplier Management** | steuert externe Leistungen | | **Measurement and Reporting** | bereitet Daten und Trends auf | | **Continual Improvement** | verfolgt Verbesserungen | Die Verantwortlichkeiten müssen klar sein. Servicequalität ist jedoch eine gemeinsame Aufgabe. --- **Informationsfluss zwischen den Practices** Service Level Management ↓ definiert Ziele Incident Management ↓ liefert Störungsdaten Problem Management ↓ liefert Ursachen und Known Errors Change Enablement ↓ liefert Änderungen und Ergebnisse Configuration Management ↓ liefert Abhängigkeiten und Kritikalität Knowledge Management ↓ liefert Workarounds und Nutzungswissen Supplier Management ↓ liefert externe Leistungsdaten Measurement and Reporting ↓ erstellt Berichte und Trends Service Review ↓ beschließt Verbesserungen Continual Improvement ↓ verfolgt Umsetzung und Wirkung Dieser Informationsfluss muss nicht in einem einzigen Werkzeug stattfinden. Wichtig sind verlässliche Verknüpfungen und Verantwortlichkeiten. --- **Praxisbeispiel: VPN-Service** **Service Level Management** Definiert Verfügbarkeit, Supportzeit und Wiederherstellungsziel. **Incident Management** Liefert Daten zu VPN-Abbrüchen und Wiederherstellungszeiten. **Problem Management** Erkennt fehlerhafte Client-Version als gemeinsame Ursache. **Knowledge Management** Stellt Workaround und Prüfschritte bereit. **Change Enablement** Steuert Pilot und Rollout einer neuen Client-Version. **Service Configuration Management** Zeigt betroffene Clientversionen, Gateway und MFA-Abhängigkeit. **Supplier Management** Prüft Herstellerunterstützung. **Continual Improvement** Misst, ob die VPN-Incidents nach dem Rollout sinken. --- **Praxisbeispiel: Zertifikatsausfall** **Incident** Anmeldung am Mitarbeiterportal fällt aus. **Problem** Zertifikat war abgelaufen. **Configuration Management** Zertifikat war nicht als CI mit Owner und Ablaufdatum erfasst. **Service Level Management** Verfügbarkeitsziel wurde verfehlt. **Change Enablement** Zertifikat wird erneuert und Monitoring eingeführt. **Knowledge Management** Runbook und Prüfschritte werden erstellt. **Continual Improvement** Alle produktiven Zertifikate werden erfasst und mindestens 30 Tage vor Ablauf überwacht. --- **Praxisbeispiel: Lieferantenabhängige Störung** **Situation** Ein SaaS-Service ist nicht erreichbar. **Incident Management** Koordiniert Benutzerkommunikation und Eskalation. **Supplier Management** Eskaliert an den Anbieter. **Service Level Management** Prüft Auswirkung auf SLA und Benutzer. **Configuration Management** Zeigt betroffene Geschäftsprozesse und Schnittstellen. **Problem Management** Prüft wiederkehrende Providerstörungen. **Continual Improvement** Bewertet zusätzlichen Workaround, Redundanz oder Vertragsänderung. --- **Praxisbeispiel: Service verfügbar, aber langsam** **Monitoring** Server und Anwendung erscheinen verfügbar. **Benutzerfeedback** Benutzer melden lange Ladezeiten. **Service Level Management** Erkennt, dass nur Verfügbarkeit, aber keine Benutzerperformance gemessen wird. **Configuration Management** Zeigt Datenbank und externe Schnittstelle als Abhängigkeiten. **Problem Management** Untersucht Performanceursache. **Change Enablement** Steuert Kapazitäts- und Konfigurationsänderung. **Measurement and Reporting** Ergänzt Antwortzeit und synthetische Benutzertransaktion. --- **Praxisbeispiel: viele Standardtickets** **Beobachtung** Viele Tickets betreffen Passwort und MFA. **Service Level Management** Erkennt hohe Bearbeitungsmenge und schlechte Benutzererfahrung. **Knowledge Management** Überarbeitet Benutzerartikel und Suchbegriffe. **Service Request Management** Vereinfacht Formulare und Automatisierung. **Service Desk** Liefert häufige Fragen und Rückmeldungen. **Continual Improvement** Misst Ticketentwicklung, Self-Service-Nutzung und Artikelbewertung. --- **Typische Fehler im Zusammenspiel** **Fehler 1** Service Levels werden festgelegt, ohne technische Abhängigkeiten zu prüfen. --- **Fehler 2** Incident-Daten werden gemessen, aber nicht servicebezogen ausgewertet. --- **Fehler 3** Wiederholte SLA-Verletzungen führen nicht zu Problem Management. --- **Fehler 4** Changes werden durchgeführt, ohne Service-Level-Auswirkungen zu prüfen. --- **Fehler 5** Geplante Wartung wird pauschal aus allen Messungen ausgeschlossen. --- **Fehler 6** CMDB-Daten sind veraltet und führen zu falscher Risikobewertung. --- **Fehler 7** Lieferantenverträge unterstützen interne Serviceziele nicht. --- **Fehler 8** Monitoring misst einzelne Server, aber keine nutzbare Servicefunktion. --- **Fehler 9** Workarounds halten SLA-Ziele formal ein, obwohl der Service dauerhaft instabil ist. --- **Fehler 10** Knowledge-Lücken verlängern Wiederherstellungszeiten. --- **Fehler 11** Reports zeigen Abweichungen, aber keine Verantwortlichen oder Maßnahmen. --- **Fehler 12** Verbesserungen werden umgesetzt, aber ihre Wirkung wird nicht gemessen. --- **Checkliste Zusammenspiel mit Incident Management** - [ ] Incident ist dem richtigen Service zugeordnet - [ ] Priorität berücksichtigt Auswirkung und Dringlichkeit - [ ] Servicekritikalität ist bekannt - [ ] Reaktionszeit wird korrekt gemessen - [ ] Wiederherstellungszeit wird korrekt gemessen - [ ] Workaround wird dokumentiert - [ ] SLA-Verletzung wird analysiert - [ ] Eskalationsweg ist bekannt - [ ] OLA-Beiträge sind abgestimmt - [ ] Major Incidents werden im Service Review betrachtet - [ ] Benutzerfeedback wird berücksichtigt --- **Checkliste Zusammenspiel mit Problem Management** - [ ] wiederkehrende SLA-Verletzungen werden untersucht - [ ] Problems sind mit Services verknüpft - [ ] häufige Workarounds werden ausgewertet - [ ] Known Errors sind dokumentiert - [ ] geschäftliche Auswirkung ist bekannt - [ ] Problem-Priorität berücksichtigt Servicekritikalität - [ ] dauerhafte Lösung ist bewertet - [ ] geplanter Change ist verknüpft - [ ] Rest Risiko ist dokumentiert - [ ] Service Review kennt den Problemstatus --- **Checkliste Zusammenspiel mit Change Enablement** - [ ] betroffener Service ist im Change angegeben - [ ] Servicezeit und Wartungsfenster sind geprüft - [ ] mögliche SLA-Auswirkung ist bewertet - [ ] betroffene Benutzergruppen sind bekannt - [ ] abhängige Services sind geprüft - [ ] Service Desk wurde informiert - [ ] Kommunikation wurde vorbereitet - [ ] Erfolgskriterien beziehen sich auf Servicequalität - [ ] Incidents nach dem Change werden geprüft - [ ] Failed Changes werden im Service Review betrachtet - [ ] geplante Wartung wird korrekt berichtet --- **Checkliste Zusammenspiel mit Service Configuration Management** - [ ] Service besitzt dokumentierte CIs - [ ] kritische Abhängigkeiten sind sichtbar - [ ] Single Points of Failure sind bekannt - [ ] Owner und Supportgruppen sind aktuell - [ ] Lieferantenbeziehungen sind dokumentiert - [ ] Zertifikate und Schnittstellen sind berücksichtigt - [ ] Kritikalität ist nachvollziehbar - [ ] Configuration-Daten werden bei SLA-Planung genutzt - [ ] Datenfehler aus Reviews werden korrigiert - [ ] Änderungen aktualisieren die CMDB --- **Checkliste Zusammenspiel mit Knowledge Management** - [ ] häufige Incidents besitzen passende Artikel - [ ] Known Errors sind auffindbar - [ ] Workarounds sind dokumentiert - [ ] Eskalationskriterien sind beschrieben - [ ] Service Desk nutzt Knowledge aktiv - [ ] Knowledge-Lücken werden ausgewertet - [ ] Artikel nach Changes aktualisiert - [ ] Benutzerwissen ist verständlich - [ ] häufige Suchanfragen werden analysiert - [ ] Knowledge-Nutzung wird im Service Review betrachtet --- **Checkliste Zusammenspiel mit Supplier Management** - [ ] kritische Lieferanten sind bekannt - [ ] Lieferantenverträge unterstützen SLA-Ziele - [ ] Supportzeiten sind kompatibel - [ ] Eskalationswege sind dokumentiert - [ ] Wartungsfenster sind abgestimmt - [ ] Lieferantenleistung wird gemessen - [ ] Vertragsverletzungen werden analysiert - [ ] Lieferantenrisiken sind dokumentiert - [ ] Alternativen oder Workarounds sind geprüft - [ ] Supplier Reviews fließen in Service Reviews ein --- **Checkliste Service Review über alle Practices** - [ ] SLA-Ziele und Ist-Werte geprüft - [ ] Incident-Trends betrachtet - [ ] Major Incidents bewertet - [ ] offene Problems und Known Errors geprüft - [ ] Changes und Releases bewertet - [ ] Configuration-Risiken betrachtet - [ ] Knowledge-Lücken berücksichtigt - [ ] Lieferantenleistung bewertet - [ ] Benutzerfeedback einbezogen - [ ] kommende Risiken und Anforderungen betrachtet - [ ] Verbesserungen priorisiert - [ ] Owner, Termin und Erfolgskriterium festgelegt --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker liefern wichtige technische Informationen für das Zusammenspiel der Practices. Im Arbeitsalltag bedeutet das: - Incidents dem richtigen Service und CI zuordnen, - Wiederherstellungszeiten sauber dokumentieren, - wiederkehrende Fehler an Problem Management melden, - Changes auf Serviceauswirkungen prüfen, - technische Abhängigkeiten nachvollziehbar pflegen, - Monitoring aus Serviceperspektive ausrichten, - Knowledge-Artikel und Runbooks aktualisieren, - Lieferantenabhängigkeiten sichtbar machen, - und Verbesserungen technisch umsetzen und überprüfen. Technische Arbeit wird dadurch nicht nur als einzelne Tätigkeit betrachtet. Sie wird mit Servicequalität, Benutzerwirkung und geschäftlichem Nutzen verbunden. --- **Zusammenfassung** > Serviceziele und Erwartungen festlegen > ↓ > Incident Management liefert Störungs- und Wiederherstellungsdaten > ↓ > Problem Management untersucht wiederkehrende Ursachen > ↓ > Change Enablement setzt Verbesserungen kontrolliert um > ↓ > Service Configuration Management zeigt Abhängigkeiten und Risiken > ↓ > Knowledge Management beschleunigt Diagnose und Wiederherstellung > ↓ > Supplier Management steuert externe Beiträge > ↓ > Monitoring und Reporting messen Servicequalität > ↓ > Service Review bewertet Abweichungen und Risiken > ↓ > Continual Improvement verfolgt Maßnahmen und Wirkung --- **Merksätze** > Service Level Management kann Servicequalität nicht allein erzeugen. > Incident Management zeigt, wie sich Störungen auf Serviceziele auswirken. > Problem Management verhindert, dass dieselben SLA-Verletzungen ständig wiederkehren. > Change Enablement setzt Serviceverbesserungen kontrolliert um. > Configuration Management zeigt, wovon ein Service tatsächlich abhängig ist. > Knowledge Management verkürzt Diagnose- und Wiederherstellungszeiten. > Interne Serviceziele müssen durch Teams und Lieferanten unterstützt werden. > Monitoring muss nutzbare Servicefunktionen und nicht nur einzelne Systeme messen. > Ein erreichtes SLA bedeutet nicht automatisch, dass ein Service dauerhaft gesund ist. > Verbesserungen sind erst abgeschlossen, wenn ihre Wirkung gemessen wurde. --- **Verwandte Seiten** - 8.1 Service Level Management – Ziele, Begriffe und Grundlagen - 8.2 SLA, SLR, OLA und Underpinning Contracts - 8.3 Kennzahlen, Messmethoden und Reporting - 8.4 Service Reviews und Continual Improvement - Incident Management - Problem Management - Change Enablement - Service Configuration Management - Knowledge Management - Supplier Management - Monitoring and Event Management - Measurement and Reporting - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Supplier Management - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 - ITIL Service – Version 5 **Einordnung** Die dargestellten: - Informationsflüsse, - Rollenbeiträge, - Schnittstellen, - Checklisten, - Ablaufdarstellungen, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Schnittstellenmatrix, - SLA-Prozessintegration, - Incident- oder Problem-Priorisierung, - Change-Bewertungsvorlage, - Service-Review-Struktur, - Reporting-Form, - oder Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Kunden, - Benutzergruppen, - Risiken, - Service Levels, - Supportmodell, - Organisationsstruktur, - Lieferanten, - Toollandschaft, - Datenqualität, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 9. Service Request Management # 9.1 Ziele und Grundlagen des Service Request Management > **Kurz erklärt** > > Service Request Management beschäftigt sich mit der strukturierten Bearbeitung von Service Requests. > > Ein Service Request ist keine Störung. > > Stattdessen handelt es sich um eine geplante, standardisierte und vom Benutzer angeforderte Serviceleistung. > > Ziel ist es, Anfragen schnell, nachvollziehbar, möglichst automatisiert und mit gleichbleibender Qualität bereitzustellen. --- **Was ist Service Request Management?** Service Request Management ist eine ITIL Practice zur Bearbeitung von standardisierten Benutzeranfragen. Dabei geht es nicht um die Behebung eines Fehlers, sondern um die Bereitstellung einer gewünschten Leistung. Typische Beispiele: - neues Benutzerkonto - Passwort zurücksetzen - Software installieren - VPN-Zugang beantragen - Gruppenberechtigung anfordern - Drucker bereitstellen - Notebook bestellen - Mobiltelefon austauschen - Zugriff auf einen Fileserver beantragen - neue virtuelle Maschine bereitstellen Alle diese Vorgänge können geplant und standardisiert abgewickelt werden. --- **Was ist ein Service Request?** Ein Service Request ist eine formelle Anfrage eines Benutzers oder einer autorisierten Person nach einer definierten Serviceleistung. Ein Service Request kann sich beispielsweise beziehen auf: - Bereitstellung - Änderung - Zugriff - Information - Beratung - Genehmigung - Ersatz - Standardleistung Wichtig: Ein Service Request ist keine Störung. Es funktioniert nichts falsch. Der Benutzer benötigt lediglich eine Leistung der IT. --- **Ziele des Service Request Management** Die wichtigsten Ziele sind: - standardisierte Bearbeitung - schnelle Bereitstellung - hohe Servicequalität - geringe Bearbeitungszeit - klare Verantwortlichkeiten - nachvollziehbare Dokumentation - möglichst hohe Automatisierung - Entlastung des Service Desk - hohe Benutzerzufriedenheit Je standardisierter ein Request ist, desto einfacher kann er automatisiert werden. --- **Warum Service Requests wichtig sind** In vielen Unternehmen bestehen die meisten Tickets nicht aus Incidents. Stattdessen entstehen täglich zahlreiche Standardanfragen. Beispiele: - neues Passwort - zusätzlicher Monitor - Softwarelizenz - Berechtigung - neues Smartphone - VPN-Zugang - Microsoft-365-Lizenz - Druckerinstallation Würde jede Anfrage individuell bearbeitet, entstünde unnötiger Aufwand. Standardisierte Abläufe sorgen für: - kürzere Bearbeitungszeiten, - geringere Fehlerquote, - bessere Planbarkeit, - gleichbleibende Qualität. --- **Incident oder Service Request?** Diese beiden Begriffe werden häufig verwechselt. | Incident | Service Request | |----------|-----------------| | ungeplante Störung | geplante Anfrage | | Service funktioniert nicht wie erwartet | Benutzer wünscht eine Leistung | | Ziel ist Wiederherstellung | Ziel ist Bereitstellung | | häufig hoher Zeitdruck | meist planbare Bearbeitung | | kann Major Incident werden | wird normalerweise nicht eskaliert | --- **Beispiele für Incidents** - Outlook startet nicht - VPN funktioniert nicht - Server ausgefallen - WLAN nicht erreichbar - Drucker druckt nicht - Anmeldung schlägt fehl - Datenbank antwortet nicht Alle diese Fälle beschreiben eine Störung. --- **Beispiele für Service Requests** - neues Notebook bestellen - zweiter Monitor - VPN-Zugang beantragen - neue Software installieren - Benutzerkonto anlegen - Gruppenmitgliedschaft ändern - Berechtigung erweitern - neues Mobiltelefon - Shared Mailbox erstellen - Lizenz freischalten Hier funktioniert nichts falsch. Der Benutzer benötigt lediglich eine zusätzliche Leistung. --- **Typische Kategorien von Service Requests** Service Requests lassen sich beispielsweise einteilen in: - Hardware - Software - Benutzerkonten - Berechtigungen - Netzwerk - Telefonie - Cloud-Dienste - Mobile Geräte - Drucker - Informationen - Beratung - Standardänderungen Eine sinnvolle Kategorisierung erleichtert Automatisierung und Auswertung. --- **Warum Standardisierung wichtig ist** Je ähnlicher Requests bearbeitet werden, desto einfacher lassen sie sich: - dokumentieren, - automatisieren, - messen, - verbessern, - delegieren. Standardisierung sorgt außerdem dafür, dass verschiedene Mitarbeiter zum gleichen Ergebnis gelangen. --- **Service Request oder Change?** Nicht jeder Service Request ist gleichzeitig ein Change. Beispiel: Ein Benutzer beantragt Microsoft Office. Die Installation erfolgt nach einem freigegebenen Standardverfahren. Für den Benutzer handelt es sich um einen Service Request. Im Hintergrund kann die Bereitstellung über einen bereits genehmigten Standard Change erfolgen. --- **Service Request oder Incident?** Ein Benutzer meldet: > "Ich kann Outlook nicht öffnen." → Incident Ein Benutzer meldet: > "Bitte installieren Sie Outlook auf meinem neuen Notebook." → Service Request Der Unterschied liegt nicht im Programm, sondern im Ziel der Anfrage. --- **Wer darf Service Requests stellen?** Je nach Organisation können Requests gestellt werden von: - Mitarbeitern - Führungskräften - Administratoren - externen Dienstleistern - Fachbereichen - Kunden - automatisierten Systemen Häufig gelten dabei Berechtigungen. Nicht jeder Benutzer darf jede Leistung anfordern. --- **Serviceportal als Einstieg** Viele Unternehmen verwenden ein zentrales Serviceportal. Dort können Benutzer: - Requests auswählen, - Formulare ausfüllen, - Genehmigungen verfolgen, - Status einsehen, - Knowledge-Artikel lesen, - den Bearbeitungsstand prüfen. Dadurch sinkt die Anzahl telefonischer Anfragen erheblich. --- **Self-Service und Service Requests** Viele Requests eignen sich hervorragend für Self-Service. Beispiele: - Passwort zurücksetzen - Software auswählen - Drucker installieren - VPN beantragen - Mobilgerät registrieren Dadurch können Benutzer viele Aufgaben selbst durchführen. --- **Typischer Ablauf eines Service Requests** ```text Benutzer │ ▼ Request stellen │ ▼ Prüfung │ ▼ Genehmigung (falls notwendig) │ ▼ Bearbeitung │ ▼ Bereitstellung │ ▼ Benutzer informiert │ ▼ Request schließen ``` Nicht jeder Request benötigt eine Genehmigung. --- **Request oder Information?** Auch reine Informationsanfragen können Service Requests sein. Beispiele: - Wie richte ich VPN ein? - Welche Software darf ich nutzen? - Wo finde ich das Handbuch? - Wie beantrage ich ein Notebook? Oft genügt hierbei bereits ein passender Knowledge-Artikel. --- **Priorität bei Service Requests** Service Requests besitzen ebenfalls Prioritäten. Diese unterscheiden sich jedoch häufig von Incident-Prioritäten. Beispiel: Ein neues Notebook kann durchaus wichtig sein, stellt aber normalerweise keinen Incident dar. Prioritäten orientieren sich häufig an: - Dringlichkeit - geschäftlicher Bedeutung - Lieferzeit - Termin - Genehmigungen --- **Servicequalität** Auch für Service Requests können Ziele definiert werden. Beispiele: - Bereitstellung innerhalb von drei Arbeitstagen - Passwort innerhalb von zehn Minuten - Notebook innerhalb von fünf Arbeitstagen - Softwareinstallation innerhalb eines Arbeitstages Diese Ziele können Bestandteil eines SLA oder Servicekatalogs sein. --- **Dokumentation** Jeder Request sollte nachvollziehbar dokumentiert werden. Mindestens: - Antragsteller - Datum - gewünschte Leistung - Kategorie - Priorität - Bearbeiter - Genehmigungen - Bereitstellung - Abschluss Eine gute Dokumentation erleichtert spätere Auswertungen. --- **Automatisierung** Viele Service Requests lassen sich vollständig automatisieren. Beispiele: - Passwort zurücksetzen - Benutzerkonto erstellen - Gruppenmitgliedschaft ändern - Software verteilen - VM bereitstellen - Lizenz aktivieren Automatisierung reduziert: - Wartezeiten, - Fehler, - Bearbeitungskosten. --- **Vorteile des Service Request Management** Für Benutzer: - schnelle Bearbeitung - transparente Prozesse - klare Zuständigkeiten - nachvollziehbarer Status Für die IT: - weniger manueller Aufwand - bessere Planbarkeit - standardisierte Abläufe - bessere Messbarkeit - einfachere Automatisierung --- **Praxisbeispiel** Ein Mitarbeiter beginnt nächste Woche im Unternehmen. Benötigt werden: - Benutzerkonto - E-Mail - Notebook - VPN - Microsoft 365 - Gruppenberechtigungen Anstatt sechs einzelne Tickets manuell zu bearbeiten, existiert ein standardisierter Onboarding-Request. Alle notwendigen Aufgaben werden automatisch angestoßen. Dadurch sinkt der Bearbeitungsaufwand erheblich. --- **Typische Fehler** **Fehler 1** Incidents werden als Service Requests erfasst. --- **Fehler 2** Service Requests werden unnötig individuell bearbeitet. --- **Fehler 3** Es existieren keine Standardabläufe. --- **Fehler 4** Genehmigungen fehlen oder erfolgen zu spät. --- **Fehler 5** Benutzer kennen das Serviceportal nicht. --- **Fehler 6** Statusinformationen fehlen. --- **Fehler 7** Standardleistungen werden nicht automatisiert. --- **Fehler 8** Dokumentation ist unvollständig. --- **Checkliste Service Request** - [ ] Request korrekt kategorisiert - [ ] gewünschte Leistung eindeutig beschrieben - [ ] Antragsteller berechtigt - [ ] Genehmigung geprüft - [ ] Standardverfahren vorhanden - [ ] Bearbeitung dokumentiert - [ ] Benutzer informiert - [ ] Request abgeschlossen --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker bearbeiten im Arbeitsalltag häufig mehr Service Requests als Incidents. Typische Aufgaben sind: - Benutzerkonten anlegen, - Berechtigungen vergeben, - Software installieren, - Hardware bereitstellen, - Standardänderungen durchführen, - Benutzer unterstützen, - Requests dokumentieren, - Automatisierungen entwickeln. Je besser Service Requests standardisiert sind, desto mehr Zeit bleibt für komplexe technische Aufgaben. --- **Zusammenfassung** > Benutzer benötigt eine definierte Leistung > > ↓ > > Service Request erfassen > > ↓ > > Kategorie bestimmen > > ↓ > > Genehmigung prüfen > > ↓ > > Standardverfahren anwenden > > ↓ > > Leistung bereitstellen > > ↓ > > Benutzer informieren > > ↓ > > Request dokumentieren und schließen --- **Merksätze** > Ein Service Request ist keine Störung. > Service Requests beschreiben standardisierte Leistungen. > Standardisierung ist die Grundlage für Automatisierung. > Gute Serviceportale entlasten den Service Desk. > Service Request Management erhöht Servicequalität und Benutzerzufriedenheit. --- **Verwandte Seiten** - 9.2 Request Model und Standard Requests - 9.3 Genehmigungen und Freigabeverfahren - 9.4 Erfüllung, Automatisierung und Self-Service - 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management - Incident Management - Knowledge Management - Service Level Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Request Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Beispiele, Kategorien, Abläufe und Empfehlungen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine einheitlichen Request-Kategorien oder Genehmigungsabläufe vor. Die konkrete Umsetzung richtet sich nach den angebotenen Services, der Organisationsstruktur und den Geschäftsanforderungen. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 9.2 Request Model und Standard Requests > **Kurz erklärt** > > Wiederkehrende Service Requests sollten nicht jedes Mal neu geplant werden. > > Stattdessen werden sie mithilfe von **Request Models** standardisiert. > > Ein Request Model beschreibt den vollständigen Ablauf eines bestimmten Service Requests – von der Anforderung über Genehmigungen bis zur Bereitstellung und Dokumentation. > > Dadurch werden Bearbeitungszeiten verkürzt, Fehler reduziert und Automatisierungen ermöglicht. --- **Was ist ein Request Model?** Ein Request Model ist eine dokumentierte Vorlage für einen wiederkehrenden Service Request. Es beschreibt: - den genauen Ablauf, - erforderliche Informationen, - Genehmigungen, - Bearbeitungsschritte, - beteiligte Teams, - Kommunikation, - Abschlusskriterien. Jeder gleichartige Request wird möglichst nach demselben Modell bearbeitet. --- **Ziele eines Request Models** Ein Request Model soll: - Bearbeitung standardisieren, - Qualität erhöhen, - Bearbeitungszeit verkürzen, - Fehler vermeiden, - Verantwortlichkeiten festlegen, - Genehmigungen eindeutig regeln, - Automatisierung ermöglichen, - Dokumentation vereinfachen, - Servicequalität verbessern. --- **Warum Request Models wichtig sind** Ohne festgelegte Abläufe entscheidet jeder Bearbeiter unterschiedlich. Dadurch entstehen häufig: - unterschiedliche Bearbeitungszeiten, - unterschiedliche Ergebnisse, - fehlende Informationen, - unnötige Rückfragen, - doppelte Arbeiten, - fehlende Genehmigungen. Ein Request Model sorgt dafür, dass alle Beteiligten nach denselben Regeln arbeiten. --- **Bestandteile eines Request Models** Ein vollständiges Request Model enthält typischerweise: - Name des Requests, - Beschreibung, - Kategorie, - Zielgruppe, - Voraussetzungen, - erforderliche Angaben, - Genehmigungen, - Bearbeitungsschritte, - beteiligte Teams, - Automatisierungen, - Kommunikation, - Abschlusskriterien, - Dokumentation. Je komplexer ein Request ist, desto ausführlicher sollte das Modell sein. --- **Beispiel: Softwareinstallation** Ein mögliches Request Model: ```text Software beantragen │ ▼ Lizenz prüfen │ ▼ Genehmigung Vorgesetzter │ ▼ Software automatisch verteilen │ ▼ Installation prüfen │ ▼ Benutzer informieren │ ▼ Request schließen ``` Der Ablauf bleibt für alle gleich. --- **Was sind Standard Requests?** Ein Standard Request ist ein häufig wiederkehrender Service Request mit einem definierten Ablauf. Typische Beispiele: - Passwort zurücksetzen - Benutzerkonto anlegen - Monitor bestellen - VPN-Zugang beantragen - Software installieren - Gruppenmitgliedschaft ändern - Drucker bereitstellen - E-Mail-Postfach erweitern - Mobiltelefon bestellen - Shared Mailbox erstellen Für Standard Requests existiert normalerweise bereits ein Request Model. --- **Eigenschaften eines Standard Requests** Ein Standard Request ist: - wiederkehrend, - dokumentiert, - planbar, - risikoarm, - standardisiert, - nachvollziehbar, - häufig automatisierbar. Dadurch kann die Bearbeitung weitgehend unabhängig vom Bearbeiter erfolgen. --- **Nicht jeder Request ist ein Standard Request** Einige Anforderungen sind individuell. Beispiele: - Einführung einer neuen Fachanwendung - komplexe Netzwerkanpassung - außergewöhnliche Hardwarebeschaffung - individuelle Spezialsoftware - neue Cloud-Architektur Solche Anforderungen benötigen häufig eine individuelle Planung. --- **Request Models und Servicekatalog** Ein Servicekatalog beschreibt, welche Leistungen angeboten werden. Ein Request Model beschreibt, wie eine bestimmte Leistung erbracht wird. Beispiel: Servicekatalog: > Microsoft 365 Request Model: > Microsoft-365-Lizenz für neuen Mitarbeiter bereitstellen. --- **Informationen des Benutzers** Ein gutes Request Model legt fest, welche Informationen der Benutzer angeben muss. Beispiele: - Name - Abteilung - Kostenstelle - Standort - gewünschte Software - Gerät - gewünschter Termin - Begründung - Ansprechpartner Fehlende Informationen führen häufig zu Verzögerungen. --- **Pflicht- und optionale Angaben** Nicht alle Informationen sind immer erforderlich. Beispiel: Pflichtfelder: - Benutzer - Software - Gerät Optionale Angaben: - gewünschter Installationstermin - Bemerkungen - Projektname Dadurch bleiben Formulare übersichtlich. --- **Genehmigungen im Request Model** Viele Standard Requests benötigen Genehmigungen. Beispiele: - Vorgesetzter - Kostenstellenverantwortlicher - Informationssicherheit - Softwareverantwortlicher - Lizenzmanager - Datenschutz Das Request Model definiert eindeutig, wann welche Genehmigung erforderlich ist. --- **Genehmigungsfreie Requests** Nicht jeder Request benötigt eine Freigabe. Beispiele: - Passwort zurücksetzen - Knowledge-Artikel aufrufen - Druckertreiber herunterladen - Standardsoftware installieren (wenn bereits genehmigt) - FAQ nutzen Dadurch sinkt der Bearbeitungsaufwand erheblich. --- **Bearbeitungsschritte definieren** Ein Request Model beschreibt jeden Bearbeitungsschritt. Beispiel: - Request prüfen - Genehmigung einholen - Lizenz reservieren - Software verteilen - Installation kontrollieren - Benutzer informieren - Dokumentation aktualisieren - Request schließen Jeder Bearbeiter kennt dadurch den vollständigen Ablauf. --- **Verantwortlichkeiten** Für jeden Schritt sollte klar sein, wer verantwortlich ist. Beispiele: | Aufgabe | Verantwortlich | |---------|----------------| | Request prüfen | Service Desk | | Genehmigung | Vorgesetzter | | Lizenzverwaltung | Lizenzmanagement | | Softwareverteilung | Client Management | | Abschluss | Service Desk | Dadurch entstehen keine unklaren Zuständigkeiten. --- **Automatisierung** Viele Schritte können automatisiert werden. Beispiele: - Formular prüfen - Genehmigung versenden - Benutzerkonto erstellen - Gruppenmitgliedschaft vergeben - Software installieren - E-Mail versenden - Ticket schließen - Dokumentation ergänzen Automatisierung reduziert manuelle Tätigkeiten erheblich. --- **Kommunikation** Auch die Kommunikation sollte standardisiert werden. Beispiele: - Eingangsbestätigung - Genehmigung angefordert - Bearbeitung begonnen - Bereitstellung abgeschlossen - zusätzliche Informationen benötigt - Request erfolgreich abgeschlossen Benutzer kennen dadurch jederzeit den aktuellen Stand. --- **Bearbeitungszeiten** Für Standard Requests können Zielzeiten definiert werden. Beispiele: | Request | Zielzeit | |---------|----------| | Passwort zurücksetzen | 15 Minuten | | Softwareinstallation | 1 Arbeitstag | | Benutzerkonto | 4 Stunden | | Monitor bestellen | 3 Arbeitstage | | VPN-Zugang | 1 Arbeitstag | Diese Zeiten dienen als Orientierung für Servicequalität und Planung. --- **Request Models regelmäßig überprüfen** Ein Request Model sollte regelmäßig überprüft werden. Mögliche Fragen: - Sind die Bearbeitungsschritte noch aktuell? - Stimmen die Genehmigungen? - Gibt es neue Automatisierungen? - Haben sich Systeme geändert? - Gibt es häufige Rückfragen? - Entstehen unnötige Wartezeiten? Ein veraltetes Request Model führt schnell zu Fehlern. --- **Versionierung** Änderungen an Request Models sollten nachvollziehbar sein. Dokumentiert werden können: - Versionsnummer - Änderungsdatum - Bearbeiter - Grund der Änderung - betroffene Schritte Dadurch bleibt nachvollziehbar, welcher Ablauf aktuell gültig ist. --- **Praxisbeispiel** Ein neuer Mitarbeiter beginnt am Montag. Der Service Request: > "Neuer Mitarbeiter" startet automatisch: - Benutzerkonto - E-Mail - Microsoft 365 - VPN - Gruppenmitgliedschaften - Notebook - Monitor - Mobiltelefon - Berechtigungen Jede Aufgabe wird automatisch an das zuständige Team weitergeleitet. Der gesamte Ablauf basiert auf einem einzigen Request Model. --- **Typische Fehler** **Fehler 1** Für häufige Requests existiert kein Request Model. --- **Fehler 2** Bearbeiter arbeiten nach unterschiedlichen Abläufen. --- **Fehler 3** Genehmigungen sind nicht eindeutig geregelt. --- **Fehler 4** Zu viele unnötige Pflichtfelder. --- **Fehler 5** Bearbeitungsschritte sind unvollständig dokumentiert. --- **Fehler 6** Automatisierungen werden nicht genutzt. --- **Fehler 7** Verantwortlichkeiten sind unklar. --- **Fehler 8** Veraltete Request Models werden weiterhin verwendet. --- **Checkliste Request Model** - [ ] Request eindeutig beschrieben - [ ] Kategorie festgelegt - [ ] Zielgruppe definiert - [ ] Voraussetzungen beschrieben - [ ] Pflichtinformationen festgelegt - [ ] Genehmigungen geregelt - [ ] Bearbeitungsschritte dokumentiert - [ ] Verantwortlichkeiten festgelegt - [ ] Automatisierungen berücksichtigt - [ ] Kommunikation definiert - [ ] Abschlusskriterien beschrieben - [ ] Version dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten täglich mit Request Models. Typische Aufgaben: - Standardsoftware bereitstellen, - Benutzerkonten anlegen, - Berechtigungen vergeben, - Hardware vorbereiten, - Automatisierungen entwickeln, - Dokumentationen pflegen, - Request Models verbessern, - Bearbeitungszeiten optimieren. Gut gepflegte Request Models sparen im Arbeitsalltag erhebliche Zeit und sorgen für eine gleichbleibend hohe Servicequalität. --- **Zusammenfassung** > Wiederkehrenden Request identifizieren > > ↓ > > Request Model erstellen > > ↓ > > Informationen und Genehmigungen festlegen > > ↓ > > Bearbeitung standardisieren > > ↓ > > Automatisierung nutzen > > ↓ > > Leistung bereitstellen > > ↓ > > Benutzer informieren > > ↓ > > Request dokumentieren und abschließen --- **Merksätze** > Standard Requests sollten immer nach einem Request Model bearbeitet werden. > Ein Request Model beschreibt den gesamten Bearbeitungsablauf. > Standardisierung ermöglicht Automatisierung. > Gute Request Models reduzieren Fehler und Bearbeitungszeit. > Klare Verantwortlichkeiten verbessern die Servicequalität. --- **Verwandte Seiten** - 9.1 Ziele und Grundlagen des Service Request Management - 9.3 Genehmigungen und Freigabeverfahren - 9.4 Erfüllung, Automatisierung und Self-Service - 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management - Service Level Management - Knowledge Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Request Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Request Models, Bearbeitungsschritte, Zielzeiten und Beispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine festen Request Models oder Standardabläufe vor. Organisationen entwickeln diese entsprechend ihrer Services, Sicherheitsanforderungen und Geschäftsprozesse. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 9.3 Genehmigungen und Freigabeverfahren > **Kurz erklärt** > > Nicht jeder Service Request darf sofort ausgeführt werden. > > Viele Leistungen verursachen Kosten, verändern Berechtigungen oder beeinflussen Sicherheit und Compliance. > > Deshalb benötigen bestimmte Requests vor der Bearbeitung eine oder mehrere Genehmigungen. > > Ziel ist es, Risiken zu reduzieren, Verantwortlichkeiten eindeutig festzulegen und gleichzeitig unnötige Wartezeiten zu vermeiden. --- **Warum Genehmigungen notwendig sind** Genehmigungen stellen sicher, dass eine angeforderte Leistung berechtigt, sinnvoll und zulässig ist. Sie helfen dabei: - unberechtigte Zugriffe zu verhindern, - Kosten zu kontrollieren, - Sicherheitsrichtlinien einzuhalten, - gesetzliche Vorgaben umzusetzen, - Verantwortlichkeiten nachzuweisen, - Änderungen nachvollziehbar zu dokumentieren. Eine Genehmigung bedeutet dabei nicht automatisch eine lange Bearbeitungszeit. Gut definierte Standardprozesse können Genehmigungen weitgehend automatisieren. --- **Was ist eine Genehmigung?** Eine Genehmigung ist die formelle Zustimmung einer berechtigten Person oder Stelle zur Durchführung eines Service Requests. Die Genehmigung bestätigt beispielsweise: - der Benutzer darf die Leistung erhalten, - Budget steht zur Verfügung, - Sicherheitsanforderungen sind erfüllt, - Unternehmensrichtlinien werden eingehalten, - Risiken sind akzeptiert. Erst danach beginnt – sofern erforderlich – die eigentliche Bearbeitung. --- **Nicht jeder Request benötigt eine Genehmigung** Viele Standardleistungen können ohne zusätzliche Freigabe bereitgestellt werden. Beispiele: - Passwort zurücksetzen - Entsperren eines Benutzerkontos - Abrufen eines Knowledge-Artikels - Installation bereits freigegebener Standardsoftware - Download eines Druckertreibers Hier würde eine zusätzliche Genehmigung lediglich den Prozess unnötig verzögern. --- **Wann Genehmigungen sinnvoll sind** Eine Genehmigung ist häufig erforderlich bei: - neuer Software - kostenpflichtigen Lizenzen - zusätzlicher Hardware - erweiterten Berechtigungen - Administratorrechten - VPN-Zugängen - Cloud-Ressourcen - neuen Benutzerkonten - Zugriff auf sensible Daten - Änderungen an sicherheitskritischen Systemen Je höher Risiko oder Kosten, desto wichtiger wird eine Freigabe. --- **Typische Genehmigungsstellen** Je nach Organisation können unterschiedliche Stellen beteiligt sein. Beispiele: | Anfrage | Genehmigung | |---------|-------------| | Notebook | Vorgesetzter | | Softwarelizenz | Lizenzmanagement | | Administratorrechte | Informationssicherheit | | SAP-Berechtigung | Fachbereich | | Cloud-Ressourcen | Kostenstellenverantwortlicher | | VPN-Zugang | Vorgesetzter oder IT-Sicherheit | | Mobiltelefon | Einkauf oder Kostenstelle | Die zuständige Stelle sollte im Request Model eindeutig definiert sein. --- **Einfacher Genehmigungsprozess** Ein typischer Ablauf: ```text Benutzer stellt Request │ ▼ Genehmigung erforderlich? │ ┌────┴────┐ │ │ Nein Ja │ │ ▼ ▼ Bearbeitung Genehmigung │ │ └────┬────┘ ▼ Bereitstellung │ ▼ Request schließen ``` Nicht jeder Request durchläuft denselben Ablauf. --- **Mehrstufige Genehmigungen** Komplexere Requests können mehrere Freigaben benötigen. Beispiel: Ein Administratorzugang wird beantragt. Mögliche Reihenfolge: 1. Vorgesetzter 2. Informationssicherheit 3. Systemverantwortlicher Erst nach allen Genehmigungen beginnt die technische Umsetzung. --- **Parallele Genehmigungen** Nicht alle Freigaben müssen nacheinander erfolgen. Sind Genehmigungen unabhängig voneinander, können sie parallel eingeholt werden. Vorteile: - kürzere Bearbeitungszeit, - weniger Wartezeiten, - bessere Planbarkeit. Dies wird von vielen ITSM-Systemen unterstützt. --- **Genehmigungsregeln** Ein Request Model sollte eindeutig festlegen: - Wer genehmigt? - Wann wird genehmigt? - Welche Kriterien gelten? - Wann entfällt eine Genehmigung? - Was passiert bei einer Ablehnung? - Gibt es Vertretungsregelungen? - Welche Fristen gelten? Klare Regeln vermeiden Rückfragen und Verzögerungen. --- **Genehmigung ist keine technische Prüfung** Die Genehmigung beantwortet in erster Linie organisatorische Fragen. Beispiele: - Ist die Software notwendig? - Ist Budget vorhanden? - Darf der Benutzer den Zugriff erhalten? - Ist die Anfrage nachvollziehbar? Die technische Umsetzung erfolgt anschließend durch die zuständigen IT-Teams. --- **Ablehnung eines Requests** Nicht jeder Request wird genehmigt. Mögliche Gründe: - fehlendes Budget, - unzureichende Begründung, - Sicherheitsrisiko, - fehlende Berechtigung, - Lizenz nicht verfügbar, - Richtlinie verbietet die Leistung, - falscher Antrag. Eine Ablehnung sollte dokumentiert und nachvollziehbar begründet werden. --- **Vertretungsregelungen** Genehmigungen dürfen nicht von einzelnen Personen abhängig sein. Deshalb sollten Vertretungen definiert werden. Beispiele: - Abwesenheit wegen Urlaub, - Krankheit, - Dienstreise, - organisatorische Änderungen. Fehlende Vertretungen führen häufig zu langen Bearbeitungszeiten. --- **Fristen für Genehmigungen** Viele Organisationen definieren Zielzeiten. Beispiele: | Genehmigung | Zielzeit | |-------------|----------| | Vorgesetzter | 1 Arbeitstag | | Lizenzmanagement | 4 Stunden | | Informationssicherheit | 2 Arbeitstage | | Einkauf | 3 Arbeitstage | Werden Fristen überschritten, kann eine Erinnerung oder Eskalation erfolgen. --- **Automatische Genehmigungen** Einige Requests können automatisch genehmigt werden. Beispiele: - Standardsoftware innerhalb einer Abteilung - zweiter Monitor nach Unternehmensrichtlinie - Passwort zurücksetzen - Druckertreiber installieren Voraussetzung ist, dass alle Regeln bereits definiert wurden. --- **Bedingte Genehmigungen** Manche Genehmigungen hängen von Bedingungen ab. Beispiele: - Hardwarewert über 1.000 Euro - Administratorrechte länger als 24 Stunden - Zugriff auf personenbezogene Daten - Software außerhalb des Standardportfolios Sind die Bedingungen nicht erfüllt, entfällt die zusätzliche Freigabe. --- **Genehmigungen dokumentieren** Jede Genehmigung sollte nachvollziehbar gespeichert werden. Typische Informationen: - Genehmiger - Datum - Entscheidung - Bemerkung - Version des Requests - eventuelle Auflagen Dadurch bleibt später nachvollziehbar, warum eine Leistung bereitgestellt wurde. --- **Genehmigungen und Compliance** Viele gesetzliche oder interne Vorgaben verlangen dokumentierte Genehmigungen. Beispiele: - ISO/IEC 27001 - Datenschutz - Informationssicherheitsrichtlinien - interne Compliance-Vorgaben - Lizenzmanagement - Finanzvorgaben Eine fehlende Dokumentation kann später zu Problemen bei Audits führen. --- **Genehmigungen und Least Privilege** Das Prinzip der minimalen Berechtigung spielt eine wichtige Rolle. Benutzer sollen nur die Rechte erhalten, die sie tatsächlich benötigen. Deshalb benötigen insbesondere folgende Requests häufig zusätzliche Genehmigungen: - Administratorrechte - Datenbankzugriffe - Domänenadministration - Firewall-Änderungen - Cloud-Administrationsrechte - Zugriff auf personenbezogene Daten --- **Temporäre Berechtigungen** Nicht jede Berechtigung muss dauerhaft vergeben werden. Beispiele: - Administratorrechte für einen Tag - Projektzugriff für vier Wochen - Testumgebung bis Projektende - externer Zugriff bis Wartungsende Nach Ablauf sollte die Berechtigung automatisch entzogen werden. --- **Genehmigungen regelmäßig überprüfen** Genehmigungsprozesse sollten regelmäßig bewertet werden. Fragen dabei: - Gibt es unnötige Freigaben? - Entstehen lange Wartezeiten? - Werden Genehmigungen häufig abgelehnt? - Können Schritte automatisiert werden? - Stimmen Verantwortlichkeiten noch? - Haben sich Richtlinien geändert? Ein effizienter Prozess schützt die Organisation, ohne die Benutzer unnötig auszubremsen. --- **Praxisbeispiel** Ein Entwickler benötigt Administratorrechte auf seinem Notebook. Der Ablauf: 1. Entwickler stellt Request. 2. Vorgesetzter bestätigt die Notwendigkeit. 3. Informationssicherheit prüft das Risiko. 4. IT vergibt die Berechtigung. 5. Die Rechte gelten nur für zwei Wochen. 6. Nach Ablauf werden sie automatisch entfernt. So bleiben Sicherheit und Nachvollziehbarkeit gewährleistet. --- **Typische Fehler** **Fehler 1** Jeder Request benötigt dieselben Genehmigungen. --- **Fehler 2** Genehmigungen sind nicht dokumentiert. --- **Fehler 3** Vertretungen fehlen. --- **Fehler 4** Genehmigungen verzögern Standardleistungen unnötig. --- **Fehler 5** Ablehnungen werden nicht begründet. --- **Fehler 6** Administratorrechte werden dauerhaft vergeben. --- **Fehler 7** Genehmigungsregeln sind unklar. --- **Fehler 8** Abgelaufene Berechtigungen werden nicht entfernt. --- **Fehler 9** Genehmigungen erfolgen außerhalb des ITSM-Systems und sind später nicht nachvollziehbar. --- **Fehler 10** Genehmigungsprozesse werden nie überprüft oder verbessert. --- **Checkliste Genehmigungen** - [ ] Genehmigung erforderlich? - [ ] Genehmiger eindeutig definiert - [ ] Antrag vollständig - [ ] Voraussetzungen erfüllt - [ ] Fristen berücksichtigt - [ ] Vertretung vorhanden - [ ] Entscheidung dokumentiert - [ ] Benutzer informiert - [ ] Bereitstellung durchgeführt - [ ] Request abgeschlossen --- **Checkliste Berechtigungs-Requests** - [ ] Benutzer eindeutig identifiziert - [ ] Berechtigung notwendig - [ ] Least-Privilege-Prinzip eingehalten - [ ] Genehmigung dokumentiert - [ ] Ablaufdatum definiert (falls erforderlich) - [ ] Protokollierung aktiviert - [ ] regelmäßige Überprüfung geplant - [ ] Entzug nach Ablauf vorgesehen --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker setzen viele genehmigte Service Requests technisch um. Typische Aufgaben: - Benutzerkonten erstellen, - Gruppenberechtigungen vergeben, - Administratorrechte einrichten, - Software bereitstellen, - Hardware ausgeben, - Dokumentationen pflegen, - Genehmigungen prüfen, - zeitlich begrenzte Berechtigungen verwalten. Dabei müssen technische Umsetzung und dokumentierte Genehmigung immer zusammenpassen. --- **Zusammenfassung** > Benutzer stellt Request > > ↓ > > Genehmigung erforderlich? > > ↓ > > Genehmiger prüfen Anfrage > > ↓ > > Freigabe oder Ablehnung > > ↓ > > Bereitstellung der Leistung > > ↓ > > Dokumentation > > ↓ > > Benutzer informieren > > ↓ > > Request abschließen --- **Merksätze** > Nicht jeder Service Request benötigt eine Genehmigung. > Genehmigungen schützen Sicherheit, Budget und Compliance. > Standardleistungen sollten möglichst automatisiert freigegeben werden. > Administratorrechte sollten zeitlich begrenzt vergeben werden. > Genehmigungen müssen nachvollziehbar dokumentiert sein. --- **Verwandte Seiten** - 9.1 Ziele und Grundlagen des Service Request Management - 9.2 Request Model und Standard Requests - 9.4 Erfüllung, Automatisierung und Self-Service - 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management - Information Security Management - Service Level Management - Knowledge Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Request Management - PeopleCert – ITIL Practice Guide: Information Security Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Genehmigungsprozesse, Beispiele und Rollen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine festen Genehmigungsstufen oder Freigabeworkflows vor. Organisationen definieren diese anhand ihrer Sicherheitsrichtlinien, Compliance-Anforderungen und Geschäftsprozesse. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 9.4 Erfüllung, Automatisierung und Self-Service > **Kurz erklärt** > > Ein zentrales Ziel des Service Request Management ist es, Service Requests möglichst schnell, zuverlässig und mit gleichbleibender Qualität zu erfüllen. > > Dies wird durch standardisierte Abläufe, Self-Service-Portale und Automatisierungen erreicht. > > Je weniger manuelle Tätigkeiten notwendig sind, desto schneller erhalten Benutzer die gewünschte Leistung und desto mehr Zeit bleibt der IT für komplexe Aufgaben. --- **Was bedeutet Request Fulfilment?** Request Fulfilment beschreibt die eigentliche Bearbeitung und Bereitstellung einer angeforderten Serviceleistung. Nachdem alle notwendigen Informationen vorliegen und erforderliche Genehmigungen erfolgt sind, beginnt die Umsetzung. Typische Tätigkeiten sind: - Benutzerkonto erstellen, - Software installieren, - Berechtigungen vergeben, - Hardware bereitstellen, - Lizenz aktivieren, - virtuelle Maschine erstellen, - Cloud-Service bereitstellen, - Drucker einrichten, - VPN-Zugang konfigurieren. Ziel ist eine schnelle und fehlerfreie Bereitstellung. --- **Ziele der Request-Erfüllung** Eine gute Request-Erfüllung soll: - schnell erfolgen, - reproduzierbar sein, - möglichst fehlerfrei ablaufen, - dokumentiert werden, - Benutzer informieren, - Standards einhalten, - Automatisierung nutzen, - Ressourcen effizient einsetzen. Die eigentliche Bearbeitung sollte möglichst keine improvisierten Einzelschritte enthalten. --- **Standardisierte Abläufe** Standardisierte Prozesse sorgen dafür, dass identische Requests immer gleich bearbeitet werden. Beispiele: - gleiches Installationsverfahren, - identische Benutzerkonten, - einheitliche Gruppenstrukturen, - definierte Softwarepakete, - standardisierte Hardware. Dadurch sinken: - Fehler, - Rückfragen, - Bearbeitungszeit, - Einarbeitungsaufwand. --- **Automatisierung im Service Request Management** Viele wiederkehrende Aufgaben eignen sich hervorragend zur Automatisierung. Beispiele: - Benutzerkonto anlegen - Passwort zurücksetzen - Gruppenmitgliedschaften vergeben - Lizenz aktivieren - Software verteilen - E-Mail-Postfach erstellen - Drucker verbinden - Cloud-Ressourcen bereitstellen - virtuelle Maschinen erzeugen - Zertifikate anfordern Automatisierungen werden häufig über ITSM-Systeme, Identity-Management-Lösungen oder Workflow-Plattformen umgesetzt. --- **Vorteile der Automatisierung** Automatisierung bietet zahlreiche Vorteile: - schnellere Bearbeitung, - geringere Fehlerquote, - gleichbleibende Qualität, - geringere Kosten, - höhere Skalierbarkeit, - bessere Nachvollziehbarkeit, - Entlastung des Service Desk, - kürzere Wartezeiten für Benutzer. Automatisierung ersetzt dabei nicht die Verantwortung für den Prozess. --- **Grenzen der Automatisierung** Nicht jeder Request kann vollständig automatisiert werden. Beispiele: - individuelle Fachsoftware, - komplexe Netzwerkänderungen, - Sonderhardware, - außergewöhnliche Berechtigungen, - Projekte, - sicherheitskritische Entscheidungen. Hier bleibt eine manuelle Prüfung erforderlich. --- **Self-Service** Beim Self-Service führt der Benutzer bestimmte Aufgaben selbst durch. Die IT stellt dafür geeignete Werkzeuge bereit. Beispiele: - Passwort zurücksetzen, - Software auswählen, - VPN beantragen, - Hardware bestellen, - Knowledge-Artikel nutzen, - Status eines Requests verfolgen, - Standardsoftware installieren. Dadurch werden Service Desk und Fachabteilungen entlastet. --- **Self-Service ist mehr als ein Formular** Ein modernes Self-Service-Portal bietet häufig: - Servicekatalog, - Suchfunktion, - Knowledge Base, - Bestellportal, - Genehmigungsstatus, - Request-Historie, - FAQ, - Downloads, - Chatbot, - Statusseite. Der Benutzer soll möglichst viele Aufgaben selbst erledigen können. --- **Der Servicekatalog** Der Servicekatalog bildet die Grundlage vieler Self-Service-Portale. Er beschreibt: - angebotene Leistungen, - Voraussetzungen, - Bearbeitungszeiten, - Kosten (falls vorhanden), - Zielgruppen, - Genehmigungen, - Ansprechpartner. Benutzer sollen ohne technisches Detailwissen erkennen können, welche Leistung sie benötigen. --- **Benutzerfreundliche Formulare** Ein gutes Formular ist: - verständlich, - kurz, - logisch aufgebaut, - mobil nutzbar, - barrierefrei, - fehlervermeidend. Nur notwendige Informationen sollten abgefragt werden. Zu viele Pflichtfelder führen häufig zu Abbrüchen. --- **Dynamische Formulare** Viele ITSM-Systeme unterstützen dynamische Formulare. Beispiel: Wählt der Benutzer: > "Notebook" erscheinen automatisch weitere Felder: - Modell, - Dockingstation, - Monitor, - Tasche. Wählt der Benutzer: > "Software" erscheinen stattdessen: - Produkt, - Version, - Lizenz, - Betriebssystem. Dadurch bleiben Formulare übersichtlich. --- **Workflow-Automatisierung** Ein Workflow steuert den gesamten Ablauf eines Requests. Beispiel: ```text Request │ ▼ Genehmigung │ ▼ Benutzerkonto │ ▼ Gruppenmitgliedschaft │ ▼ Softwareinstallation │ ▼ Benutzer informieren │ ▼ Request schließen ``` Jeder Schritt wird automatisch an die nächste zuständige Stelle übergeben. --- **Automatische Benachrichtigungen** Während der Bearbeitung können automatisch Nachrichten versendet werden. Beispiele: - Request eingegangen, - Genehmigung erforderlich, - Genehmigung erfolgt, - Bearbeitung begonnen, - Rückfrage, - Bereitstellung abgeschlossen, - Request geschlossen. Dadurch muss der Benutzer nicht ständig nachfragen. --- **Identity Management** Viele Benutzer-Requests betreffen Identitäten und Berechtigungen. Identity-Management-Systeme können beispielsweise: - Benutzerkonten erstellen, - Gruppen verwalten, - Rollen vergeben, - Berechtigungen entziehen, - Kennwörter zurücksetzen, - Konten deaktivieren. Dadurch lassen sich viele Standard-Requests vollständig automatisieren. --- **Zero-Touch Provisioning** Bei standardisierten Arbeitsplätzen kann die Bereitstellung nahezu vollständig automatisiert erfolgen. Beispiel: Ein neuer Mitarbeiter wird im HR-System angelegt. Automatisch entstehen: - Benutzerkonto, - E-Mail-Adresse, - Microsoft-365-Lizenz, - Gruppenmitgliedschaften, - VPN-Zugang, - Multifaktor-Authentifizierung, - Notebook-Konfiguration. Die IT muss nur noch kontrollieren oder ausliefern. --- **Automatisierung mit Workflows** Workflow-Systeme können verschiedene Werkzeuge miteinander verbinden. Beispiele: - ITSM-System, - Active Directory, - Microsoft Entra ID, - Microsoft 365, - VMware, - Hyper-V, - Cloud-Plattform, - Lizenzverwaltung, - E-Mail-System, - Inventarisierung. Ein einziger Request kann dadurch zahlreiche Systeme automatisch steuern. --- **Fehlerbehandlung** Auch automatisierte Prozesse benötigen Fehlerbehandlung. Mögliche Situationen: - Lizenz nicht verfügbar, - Genehmigung fehlt, - Benutzer existiert bereits, - Active Directory nicht erreichbar, - Netzwerkproblem, - Cloud-Dienst gestört. In solchen Fällen sollte der Workflow kontrolliert anhalten und den zuständigen Bearbeiter informieren. --- **Rollback** Automatisierungen sollten möglichst rückgängig gemacht werden können. Beispiele: - Benutzerkonto entfernen, - Gruppenmitgliedschaften löschen, - Software deinstallieren, - Lizenz freigeben, - VM löschen. Dadurch lassen sich Fehler einfacher korrigieren. --- **Protokollierung** Jede automatische Bearbeitung sollte nachvollziehbar sein. Typische Informationen: - Zeitpunkt, - gestarteter Workflow, - beteiligte Systeme, - Bearbeitungsschritte, - Fehler, - Abschluss, - Verantwortlicher, - Versionsstand. Eine vollständige Protokollierung erleichtert Fehleranalyse und Audits. --- **Überwachung automatisierter Prozesse** Automatisierungen müssen überwacht werden. Beispiele: - Workflow erfolgreich abgeschlossen? - Genehmigung erhalten? - Software installiert? - Lizenz vergeben? - Benutzer informiert? - Fehlermeldung aufgetreten? Nicht erkannte Fehler können dazu führen, dass Requests unvollständig bearbeitet werden. --- **Self-Service und Knowledge Base** Viele Requests lassen sich bereits durch passende Informationen lösen. Beispiele: - VPN einrichten, - Drucker verbinden, - Outlook konfigurieren, - MFA aktivieren, - WLAN nutzen. Findet der Benutzer die Lösung selbst, muss kein Ticket erstellt werden. --- **Chatbots und virtuelle Assistenten** Viele Serviceportale integrieren Chatbots. Sie können: - Fragen beantworten, - passende Knowledge-Artikel finden, - Requests aufnehmen, - Formulare starten, - Bearbeitungsstatus anzeigen. Komplexe Anfragen werden bei Bedarf an den Service Desk weitergeleitet. --- **Messung der Servicequalität** Auch Self-Service und Automatisierung sollten gemessen werden. Beispiele: - Bearbeitungszeit, - Automatisierungsquote, - Self-Service-Nutzung, - Anzahl manueller Eingriffe, - Fehlerquote, - Benutzerzufriedenheit, - Erfolgsquote der Workflows, - Anzahl abgebrochener Formulare. Diese Kennzahlen helfen, den Service kontinuierlich zu verbessern. --- **Praxisbeispiel** Ein neuer Mitarbeiter wird eingestellt. Der Vorgesetzte startet im Self-Service-Portal den Request: > Neuer Mitarbeiter Automatisch werden: - Genehmigung geprüft, - Benutzerkonto erstellt, - Microsoft-365-Lizenz vergeben, - VPN eingerichtet, - Gruppenmitgliedschaften gesetzt, - Notebook vorbereitet, - E-Mail versendet. Der Service Desk muss den Ablauf lediglich überwachen. --- **Typische Fehler** **Fehler 1** Standard-Requests werden weiterhin vollständig manuell bearbeitet. --- **Fehler 2** Self-Service-Portale sind unübersichtlich. --- **Fehler 3** Automatisierungen besitzen keine Fehlerbehandlung. --- **Fehler 4** Genehmigungen werden nicht automatisch berücksichtigt. --- **Fehler 5** Benutzer erhalten keine Statusinformationen. --- **Fehler 6** Workflows werden nicht überwacht. --- **Fehler 7** Rollback-Möglichkeiten fehlen. --- **Fehler 8** Knowledge-Artikel sind veraltet. --- **Fehler 9** Zu viele unnötige Formularfelder erschweren die Nutzung. --- **Fehler 10** Automatisierungen werden nach Änderungen nicht getestet. --- **Checkliste Self-Service** - [ ] Servicekatalog vorhanden - [ ] Formulare verständlich - [ ] Knowledge Base integriert - [ ] Status jederzeit sichtbar - [ ] mobile Nutzung möglich - [ ] Suchfunktion vorhanden - [ ] häufige Requests verfügbar - [ ] Benutzerfeedback möglich --- **Checkliste Automatisierung** - [ ] Standardprozess definiert - [ ] Workflow dokumentiert - [ ] Genehmigungen integriert - [ ] Fehlerbehandlung vorhanden - [ ] Rollback möglich - [ ] Protokollierung aktiv - [ ] Monitoring eingerichtet - [ ] Tests durchgeführt - [ ] Verantwortlicher benannt - [ ] Dokumentation aktuell --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker entwickeln, betreiben und überwachen häufig automatisierte Serviceprozesse. Typische Aufgaben: - Workflows erstellen, - Benutzerkonten automatisieren, - Softwareverteilung verwalten, - Berechtigungen vergeben, - Identity-Management pflegen, - Fehler analysieren, - Automatisierungen testen, - Self-Service-Portale verbessern. Gut geplante Automatisierungen reduzieren Routinearbeiten erheblich und erhöhen gleichzeitig die Servicequalität. --- **Zusammenfassung** > Benutzer stellt Service Request > > ↓ > > Self-Service oder Service Desk > > ↓ > > Genehmigungen prüfen > > ↓ > > Workflow starten > > ↓ > > Automatisierte Bereitstellung > > ↓ > > Benutzer informieren > > ↓ > > Protokollieren > > ↓ > > Request abschließen --- **Merksätze** > Standardisierte Requests eignen sich besonders für Automatisierung. > Self-Service entlastet den Service Desk. > Automatisierung benötigt Monitoring und Fehlerbehandlung. > Gute Workflows verkürzen Bearbeitungszeiten erheblich. > Jede Automatisierung muss nachvollziehbar dokumentiert werden. --- **Verwandte Seiten** - 9.1 Ziele und Grundlagen des Service Request Management - 9.2 Request Model und Standard Requests - 9.3 Genehmigungen und Freigabeverfahren - 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management - Knowledge Management - Service Level Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Request Management - PeopleCert – ITIL Practice Guide: Knowledge Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Beispiele, Workflows, Self-Service-Funktionen und Automatisierungen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt weder bestimmte Portale noch konkrete Automatisierungsplattformen vor. Die technische Umsetzung hängt von den eingesetzten ITSM-, Identity-Management- und Workflow-Systemen der jeweiligen Organisation ab. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management > **Kurz erklärt** > > Service Request Management arbeitet nicht isoliert. > > Es steht in engem Zusammenhang mit anderen ITIL Practices. > > Erst das Zusammenspiel mit Incident Management, Change Enablement, Knowledge Management, Service Level Management, Information Security Management und Continual Improvement ermöglicht eine schnelle, sichere und qualitativ hochwertige Bearbeitung von Service Requests. > > Jede Practice liefert Informationen oder Leistungen, die den gesamten Request-Prozess unterstützen. --- **Warum das Zusammenspiel wichtig ist** Ein Service Request besteht selten nur aus einer einzelnen Tätigkeit. Beispiel: Ein neuer Mitarbeiter benötigt: - Benutzerkonto, - Microsoft-365-Lizenz, - VPN, - Notebook, - Gruppenberechtigungen, - Mobiltelefon. Für die Bereitstellung arbeiten häufig mehrere Teams und Practices zusammen. Das Service Request Management koordiniert dabei den gesamten Ablauf. --- **Zusammenspiel der Practices** ```text Service Request │ ▼ Genehmigungen │ ▼ Knowledge nutzen │ ▼ Incident vermeiden │ ▼ Changes ausführen │ ▼ Service bereitstellen │ ▼ Servicequalität messen │ ▼ Verbesserungen umsetzen ``` Die Practices arbeiten parallel und ergänzen sich gegenseitig. --- **Service Request Management und Incident Management** Diese beiden Practices werden häufig verwechselt. Der wichtigste Unterschied: | Incident Management | Service Request Management | |----------------------|----------------------------| | Störung beheben | Service bereitstellen | | ungeplantes Ereignis | geplante Anfrage | | Ziel: Wiederherstellung | Ziel: Erfüllung einer Anforderung | | häufig hoher Zeitdruck | planbare Bearbeitung | Trotzdem arbeiten beide eng zusammen. --- **Wenn ein Incident zum Request wird** Manchmal stellt sich während der Bearbeitung heraus, dass gar keine Störung vorliegt. Beispiel: Benutzer meldet: > "Ich kann Photoshop nicht benutzen." Analyse: Photoshop wurde nie installiert. Es liegt keine Störung vor. Der Incident wird geschlossen. Anschließend wird ein Service Request für die Softwareinstallation erstellt. --- **Wenn ein Request zum Incident wird** Auch das Gegenteil ist möglich. Beispiel: Ein Benutzer beantragt VPN. Während der Bereitstellung fällt auf: Der VPN-Gateway ist ausgefallen. Jetzt liegt zusätzlich ein Incident vor. Der Service Request bleibt bestehen, die technische Störung wird jedoch separat als Incident bearbeitet. --- **Parallele Bearbeitung** Ein Service Request und ein Incident können gleichzeitig existieren. Beispiel: - Request: neues Notebook - Incident: Softwareverteilung funktioniert nicht Beide Vorgänge besitzen unterschiedliche Ziele, können sich jedoch gegenseitig beeinflussen. --- **Verknüpfung von Tickets** Viele ITSM-Systeme ermöglichen Verknüpfungen. Beispiel: ```text Service Request │ ├──────── Incident │ ├──────── Change │ ├──────── Knowledge Article │ └──────── Configuration Item ``` Dadurch bleiben Zusammenhänge nachvollziehbar. --- **Service Request Management und Change Enablement** Viele Requests führen zu Änderungen an der IT-Umgebung. Beispiele: - Software installieren, - Benutzerkonto erstellen, - Firewallregel hinzufügen, - virtuelle Maschine bereitstellen, - Cloud-Service aktivieren. Nicht jede dieser Änderungen benötigt jedoch einen eigenen Change. --- **Standard Changes** Viele Service Requests werden über bereits genehmigte Standard Changes umgesetzt. Beispiele: - Office installieren - Gruppenmitgliedschaft vergeben - Notebook bereitstellen - Benutzerkonto anlegen Der Benutzer bemerkt davon häufig nichts. Für ihn bleibt es ein Service Request. --- **Normale Changes** Größere Anforderungen können zusätzlich einen normalen Change benötigen. Beispiel: Ein Fachbereich benötigt eine neue Unternehmenssoftware. Der Service Request startet den Prozess. Die technische Einführung erfolgt anschließend kontrolliert über Change Enablement. --- **Service Request Management und Knowledge Management** Knowledge Management unterstützt Service Requests in nahezu jeder Phase. Beispiele: - Benutzer findet die Lösung selbst. - Service Desk nutzt einen Knowledge-Artikel. - Automatisierung greift auf Dokumentation zurück. - Runbooks beschreiben die Bereitstellung. Je besser die Wissensbasis, desto schneller erfolgt die Bearbeitung. --- **Knowledge vor Ticket** Idealerweise prüft der Benutzer bereits vor der Ticketerstellung, ob ein passender Knowledge-Artikel existiert. Beispiele: - VPN einrichten - Outlook konfigurieren - Drucker verbinden - MFA aktivieren Dadurch werden viele Requests vollständig vermieden. --- **Neue Knowledge-Artikel** Auch Service Requests können neue Dokumentationen erzeugen. Beispiele: - häufige Rückfragen - neue Software - neue Cloud-Dienste - neue Standardhardware - neuer Bereitstellungsprozess Wissen sollte kontinuierlich erweitert werden. --- **Runbooks** Viele Standard Requests besitzen ein Runbook. Ein Runbook beschreibt: - Voraussetzungen, - Reihenfolge, - Prüfungen, - Dokumentation, - Abschluss. Dadurch arbeiten alle Bearbeiter nach demselben Verfahren. --- **Service Request Management und Service Level Management** Auch Service Requests besitzen häufig Serviceziele. Beispiele: - Notebook innerhalb von fünf Arbeitstagen - Benutzerkonto innerhalb von vier Stunden - Passwort innerhalb von zehn Minuten - Software innerhalb eines Arbeitstages Service Level Management überwacht, ob diese Ziele erreicht werden. --- **Kennzahlen** Typische Kennzahlen: - Bearbeitungszeit - Wartezeit auf Genehmigung - Automatisierungsquote - Anzahl offener Requests - durchschnittliche Bereitstellungszeit - Benutzerzufriedenheit - Self-Service-Nutzung - Wiedereröffnungen Diese Kennzahlen helfen bei Verbesserungen. --- **Service Request Management und Information Security Management** Viele Requests betreffen Sicherheitsaspekte. Beispiele: - Administratorrechte - VPN - Multifaktor-Authentifizierung - Cloud-Zugriffe - Gruppenmitgliedschaften - Datenbankberechtigungen Information Security Management definiert häufig die notwendigen Anforderungen. --- **Least Privilege** Service Requests sollten möglichst nach dem Prinzip der geringsten Berechtigung umgesetzt werden. Benutzer erhalten nur die Rechte, die sie tatsächlich benötigen. Dadurch sinkt das Sicherheitsrisiko. --- **Rezertifizierung** Manche Berechtigungen werden regelmäßig überprüft. Beispiele: - Administratorrechte - Projektzugriffe - externe Benutzer - Cloud-Rollen Nicht mehr benötigte Berechtigungen werden entfernt. --- **Service Request Management und Service Configuration Management** Viele Requests verändern Configuration Items. Beispiele: - Notebook ausgeben - Server bereitstellen - virtuelle Maschine erzeugen - Software installieren - Zertifikat erneuern Nach der Bereitstellung sollten die entsprechenden Configuration-Daten aktualisiert werden. --- **Warum Configuration-Daten wichtig sind** Nur aktuelle Daten ermöglichen: - korrekte Inventarisierung, - Incident-Analyse, - Problem Management, - Change Enablement, - Lizenzverwaltung, - Sicherheitsprüfungen. Service Requests verändern häufig genau diese Informationen. --- **Service Request Management und Supplier Management** Externe Lieferanten können an der Bearbeitung beteiligt sein. Beispiele: - Notebooklieferung - Mobiltelefon - Cloud-Service - Softwarelizenz - Hardwarewartung Lieferzeiten externer Partner beeinflussen häufig die gesamte Bearbeitungsdauer. --- **Service Request Management und Continual Improvement** Jeder Request liefert Verbesserungspotenzial. Beispiele: - unnötige Genehmigungen, - schlechte Formulare, - fehlende Automatisierung, - veraltete Knowledge-Artikel, - lange Bearbeitungszeiten, - wiederkehrende Rückfragen. Diese Erkenntnisse fließen in Continual Improvement ein. --- **Verbesserungsmöglichkeiten** Typische Maßnahmen: - Formular vereinfachen - Genehmigungen reduzieren - Workflow automatisieren - Knowledge erweitern - Serviceportal verbessern - Bearbeitungszeiten verkürzen - Kommunikation verbessern Kleine Verbesserungen können große Wirkung entfalten. --- **Zusammenspiel im Onboarding** Ein Beispiel: ```text Neuer Mitarbeiter │ ▼ Service Request │ ▼ Genehmigungen │ ▼ Benutzerkonto │ ▼ Microsoft 365 │ ▼ VPN │ ▼ Notebook │ ▼ CMDB aktualisieren │ ▼ Benutzer informieren ``` Mehrere Practices arbeiten dabei gleichzeitig zusammen. --- **Praxisbeispiel** Ein neuer Mitarbeiter beginnt nächste Woche. Der Request löst automatisch aus: - Benutzerkonto, - E-Mail, - Microsoft 365, - Notebook, - VPN, - Gruppen, - Teams, - Mobiltelefon. Währenddessen: - Knowledge liefert Installationsanleitungen. - Configuration Management dokumentiert neue Geräte. - Service Level Management misst die Bearbeitungszeit. - Information Security prüft Berechtigungen. - Continual Improvement sammelt Kennzahlen. Der Benutzer erlebt einen einzigen zusammenhängenden Service. --- **Typische Fehler** **Fehler 1** Incidents und Requests werden verwechselt. --- **Fehler 2** Service Requests aktualisieren keine Configuration-Daten. --- **Fehler 3** Knowledge wird nicht genutzt. --- **Fehler 4** Genehmigungen verzögern Standardleistungen. --- **Fehler 5** Automatisierungen fehlen. --- **Fehler 6** Serviceziele werden nicht gemessen. --- **Fehler 7** Information Security wird zu spät eingebunden. --- **Fehler 8** Bearbeitung erfolgt außerhalb des ITSM-Systems. --- **Fehler 9** Self-Service wird kaum genutzt. --- **Fehler 10** Verbesserungspotenziale werden nicht ausgewertet. --- **Checkliste Zusammenspiel** - [ ] Request korrekt klassifiziert - [ ] Incident ausgeschlossen - [ ] Knowledge genutzt - [ ] Genehmigungen durchgeführt - [ ] Change erforderlich? - [ ] Configuration-Daten aktualisiert - [ ] Sicherheitsanforderungen erfüllt - [ ] Serviceziel überwacht - [ ] Benutzer informiert - [ ] Verbesserungen dokumentiert --- **Checkliste Automatisierung** - [ ] Workflow vorhanden - [ ] Genehmigungen integriert - [ ] Knowledge eingebunden - [ ] Configuration aktualisiert - [ ] Benutzer informiert - [ ] Fehler protokolliert - [ ] Monitoring vorhanden - [ ] Dokumentation aktuell --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten täglich an den Schnittstellen verschiedener ITIL Practices. Im Arbeitsalltag bedeutet dies: - Service Requests technisch umsetzen, - Incidents von Requests unterscheiden, - Standard Changes anwenden, - Configuration-Daten pflegen, - Knowledge erweitern, - Sicherheitsvorgaben einhalten, - Automatisierungen entwickeln, - Prozesse kontinuierlich verbessern. Erst das Zusammenspiel aller Practices ermöglicht einen professionellen und effizienten IT-Service. --- **Zusammenfassung** > Benutzer stellt Service Request > > ↓ > > Knowledge und Self-Service unterstützen > > ↓ > > Genehmigungen prüfen > > ↓ > > Standard Change nutzen (falls erforderlich) > > ↓ > > Service bereitstellen > > ↓ > > Configuration aktualisieren > > ↓ > > Servicequalität messen > > ↓ > > Verbesserungen umsetzen --- **Merksätze** > Service Request Management arbeitet niemals isoliert. > Incidents beheben Störungen – Service Requests stellen Leistungen bereit. > Knowledge und Automatisierung beschleunigen die Bearbeitung. > Configuration-Daten müssen nach der Bereitstellung aktuell sein. > Continual Improvement verbessert auch Service Requests kontinuierlich. --- **Verwandte Seiten** - 9.1 Ziele und Grundlagen des Service Request Management - 9.2 Request Model und Standard Requests - 9.3 Genehmigungen und Freigabeverfahren - 9.4 Erfüllung, Automatisierung und Self-Service - Incident Management - Change Enablement - Knowledge Management - Service Configuration Management - Service Level Management - Information Security Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Request Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Information Security Management - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Zusammenhänge, Beispiele und Praxisempfehlungen orientieren sich an den ITIL-Practices. Die konkrete technische Umsetzung hängt von den eingesetzten ITSM-Systemen, Automatisierungsplattformen, Identity-Management-Lösungen und organisatorischen Prozessen der jeweiligen Organisation ab. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 10. Monitoring and Event Management # 10.1 Ziele und Grundlagen des Monitoring and Event Management > **Kurz erklärt** > > Monitoring and Event Management sorgt dafür, dass der Zustand von IT-Services und IT-Systemen kontinuierlich überwacht wird. > > Ziel ist es, Abweichungen möglichst früh zu erkennen, bevor daraus Incidents oder Serviceunterbrechungen entstehen. > > Ereignisse (Events) werden gesammelt, bewertet und – je nach Bedeutung – automatisch verarbeitet oder an die zuständigen Teams weitergeleitet. --- **Was ist Monitoring and Event Management?** Monitoring and Event Management ist eine ITIL Practice zur kontinuierlichen Überwachung von Services, Systemen und Infrastruktur. Dabei werden Informationen über den aktuellen Zustand gesammelt und ausgewertet. Beispiele: - Server erreichbar? - CPU-Auslastung zu hoch? - Festplatte fast voll? - Backup erfolgreich? - Zertifikat läuft bald ab? - Datenbank antwortet? - Netzwerkverbindung aktiv? - Webservice erreichbar? - Temperatur im Serverraum normal? Das Ziel besteht darin, Probleme möglichst frühzeitig zu erkennen. --- **Warum Monitoring wichtig ist** Ohne Monitoring werden viele Probleme erst bemerkt, wenn Benutzer sie melden. Dadurch entstehen: - längere Ausfallzeiten, - mehr Incidents, - höhere Kosten, - unzufriedene Benutzer, - größere Geschäftsrisiken. Ein gutes Monitoring erkennt viele Probleme bereits, bevor Benutzer betroffen sind. --- **Ziele des Monitoring and Event Management** Die wichtigsten Ziele sind: - frühzeitige Fehlererkennung, - schnelle Reaktion, - Verfügbarkeit erhöhen, - Ausfälle vermeiden, - automatische Benachrichtigung, - Automatisierung unterstützen, - Servicequalität verbessern, - Trends erkennen, - Ursachenanalyse erleichtern. Monitoring ersetzt dabei keine Fehlerbehebung. Es liefert die notwendigen Informationen. --- **Monitoring und Event Management unterscheiden** Diese beiden Begriffe werden häufig gemeinsam verwendet, beschreiben jedoch unterschiedliche Aufgaben. | Monitoring | Event Management | |------------|------------------| | sammelt Messwerte | bewertet Ereignisse | | überwacht Systeme | entscheidet über Reaktionen | | erkennt Veränderungen | verarbeitet Events | | liefert Daten | löst Aktionen aus | Monitoring erzeugt Events. Event Management verarbeitet diese. --- **Was ist ein Event?** Ein Event ist jede erkennbare Veränderung des Zustands eines Services oder Configuration Items. Ein Event kann beispielsweise entstehen durch: - Anmeldung, - Fehler, - Neustart, - Backup, - Alarm, - Warnung, - Hardwareausfall, - erfolgreiche Aktualisierung, - Zertifikatsablauf, - Überschreiten eines Grenzwerts. Nicht jedes Event bedeutet automatisch ein Problem. --- **Event ist nicht gleich Incident** Ein häufiger Irrtum: > Jedes Event ist ein Incident. Das stimmt nicht. Beispiel: Ein Server startet nach einer geplanten Wartung neu. Das Monitoring erzeugt ein Event. Da die Änderung geplant war, liegt kein Incident vor. --- **Beispiel eines echten Incidents** Das Monitoring erkennt: - Webserver nicht erreichbar. Es existiert: - keine geplante Wartung, - kein geplanter Change. Jetzt entsteht aus dem Event möglicherweise ein Incident. --- **Informationsfluss** ```text Monitoring │ ▼ Event entsteht │ ▼ Bewertung │ ┌────┴────┐ │ │ Normal Reaktion │ │ ▼ ▼ Protokoll Alarm oder Automation ``` Nicht jedes Event benötigt menschliches Eingreifen. --- **Arten von Monitoring** Typische Bereiche: - Server - Netzwerk - Cloud - Datenbanken - Anwendungen - Container - virtuelle Maschinen - Speicher - Backup - Sicherheit - Zertifikate - Hardware - Umgebungsbedingungen Je nach Service kommen unterschiedliche Überwachungen zum Einsatz. --- **Technisches Monitoring** Technisches Monitoring überwacht einzelne Komponenten. Beispiele: - CPU-Auslastung, - RAM-Auslastung, - Festplattenbelegung, - Netzwerkverkehr, - Temperatur, - Lüfter, - Spannungsversorgung, - Hardwarefehler. Es beantwortet die Frage: > Funktioniert das System technisch? --- **Service Monitoring** Service Monitoring betrachtet den Service aus Benutzersicht. Beispiele: - Anmeldung möglich? - Website erreichbar? - E-Mail versendbar? - Datenbankabfrage erfolgreich? - VPN-Anmeldung funktioniert? - API antwortet korrekt? Ein Server kann technisch erreichbar sein, während der eigentliche Service bereits gestört ist. --- **Aktives Monitoring** Beim aktiven Monitoring werden Systeme regelmäßig geprüft. Beispiele: - Ping, - HTTP-Aufruf, - Datenbankanmeldung, - DNS-Abfrage, - SMTP-Test, - API-Aufruf. Die Prüfungen erfolgen automatisch in festgelegten Intervallen. --- **Passives Monitoring** Beim passiven Monitoring senden Systeme selbst Informationen. Beispiele: - Syslog, - Windows Event Log, - SNMP-Traps, - Sicherheitsmeldungen, - Container-Logs, - Anwendungsprotokolle. Hier wartet das Monitoring auf eintreffende Ereignisse. --- **Synthetisches Monitoring** Synthetisches Monitoring simuliert typische Benutzeraktionen. Beispiele: - Benutzer anmelden, - Bestellung durchführen, - Suchfunktion testen, - Datei hochladen, - VPN verbinden. Dadurch wird geprüft, ob ein Service tatsächlich nutzbar ist. --- **Real User Monitoring (RUM)** Beim Real User Monitoring werden echte Benutzeraktionen ausgewertet. Beispiele: - Ladezeiten, - Antwortzeiten, - Fehlermeldungen, - Browserdaten, - Standortinformationen. Dadurch erhält die IT Informationen über die tatsächliche Benutzererfahrung. --- **Überwachungsobjekte** Monitoring kann sich beziehen auf: - Configuration Items, - Services, - Anwendungen, - Netzwerke, - Cloud-Ressourcen, - Container, - Datenbanken, - APIs, - Sicherheitskomponenten, - Backup-Systeme. Nicht jedes Objekt benötigt dieselbe Überwachung. --- **Grenzwerte (Thresholds)** Viele Überwachungen arbeiten mit Grenzwerten. Beispiele: | Messwert | Grenzwert | |----------|-----------| | CPU | über 90 % | | RAM | über 95 % | | Festplatte | über 85 % belegt | | Zertifikat | läuft in 30 Tagen ab | | Backup | fehlgeschlagen | | Antwortzeit | über 2 Sekunden | Grenzwerte sollten regelmäßig überprüft werden. --- **Frühwarnungen** Nicht jeder Alarm muss sofort kritisch sein. Beispiel: Festplatte: - 70 % → normal - 85 % → Warnung - 95 % → kritisch Dadurch bleibt genügend Zeit, Probleme zu beheben. --- **Alarmmüdigkeit (Alert Fatigue)** Zu viele unnötige Alarme führen dazu, dass wichtige Warnungen übersehen werden. Typische Ursachen: - falsche Grenzwerte, - doppelte Alarme, - bekannte Ereignisse, - ungefilterte Meldungen, - schlecht abgestimmtes Monitoring. Ein gutes Monitoring erzeugt möglichst wenige, aber relevante Alarme. --- **Praxisbeispiel** Das Monitoring erkennt: - Zertifikat läuft in 30 Tagen ab. Es entsteht: - Warnung, - Ticket, - Benachrichtigung an den Administrator. Das Zertifikat wird rechtzeitig erneuert. Ein späterer Incident wird vermieden. --- **Typische Fehler** **Fehler 1** Monitoring existiert nur für Server, nicht für Services. --- **Fehler 2** Grenzwerte sind ungeeignet. --- **Fehler 3** Zu viele unnötige Alarme. --- **Fehler 4** Alarme werden nicht bearbeitet. --- **Fehler 5** Backups werden nicht überwacht. --- **Fehler 6** Zertifikate werden nicht überwacht. --- **Fehler 7** Monitoring erkennt Fehler erst nach Benutzerbeschwerden. --- **Fehler 8** Monitoring wird nach Änderungen nicht angepasst. --- **Checkliste Monitoring** - [ ] kritische Services überwacht - [ ] wichtige Configuration Items überwacht - [ ] sinnvolle Grenzwerte definiert - [ ] Alarme getestet - [ ] Benachrichtigungen funktionieren - [ ] Zertifikate überwacht - [ ] Backups überwacht - [ ] Dokumentation aktuell - [ ] Verantwortlichkeiten festgelegt - [ ] regelmäßige Überprüfung geplant --- **Bedeutung für Fachinformatiker für Systemintegration** Monitoring gehört zu den täglichen Aufgaben vieler Fachinformatiker. Typische Tätigkeiten: - Monitoring konfigurieren, - Alarme auswerten, - Grenzwerte anpassen, - Logs analysieren, - Events bewerten, - Incidents erkennen, - Automatisierungen entwickeln, - Monitoring kontinuierlich verbessern. Ein gut aufgebautes Monitoring verhindert viele Störungen, bevor Benutzer sie überhaupt bemerken. --- **Zusammenfassung** > Systeme und Services überwachen > > ↓ > > Messwerte sammeln > > ↓ > > Event erzeugen > > ↓ > > Event bewerten > > ↓ > > Alarm oder Automatisierung > > ↓ > > Incident vermeiden oder bearbeiten > > ↓ > > Service stabil halten --- **Merksätze** > Monitoring sammelt Informationen – Event Management bewertet sie. > Nicht jedes Event ist ein Incident. > Gutes Monitoring erkennt Probleme vor den Benutzern. > Service Monitoring ist wichtiger als reine Serverüberwachung. > Wenige aussagekräftige Alarme sind besser als viele unnötige Warnungen. --- **Verwandte Seiten** - 10.2 Event-Typen, Filter und Priorisierung - 10.3 Alarme, Eskalationen und Automatisierung - 10.4 Monitoring-Werkzeuge, Dashboards und Kennzahlen - 10.5 Zusammenspiel mit Incident, Problem, Change und Service Configuration Management - Incident Management - Service Configuration Management - Service Level Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Monitoring-Arten, Beispiele und Grenzwerte sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine konkreten Monitoring-Werkzeuge oder festen Schwellenwerte vor. Diese richten sich nach den überwachten Services, den Geschäftsanforderungen und der technischen Umgebung. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 10.2 Event-Typen, Filter und Priorisierung > **Kurz erklärt** > > Ein Monitoring-System erzeugt täglich oft tausende oder sogar Millionen von Events. > > Die Aufgabe des Event Managements besteht darin, diese Ereignisse zu bewerten, unwichtige Meldungen herauszufiltern und relevante Events an die richtigen Prozesse oder Personen weiterzuleiten. > > Nur so können Störungen früh erkannt werden, ohne Administratoren mit unnötigen Meldungen zu überlasten. --- **Warum Event Management notwendig ist** Ein modernes Rechenzentrum erzeugt ständig Ereignisse. Beispiele: - Benutzer melden sich an. - Dienste starten. - Backups beginnen. - Container werden erstellt. - Zertifikate werden geprüft. - CPU-Auslastung ändert sich. - Netzwerkverkehr steigt. - Datenbanken schreiben Logeinträge. Ohne Bewertung wären diese Informationen kaum nutzbar. Event Management entscheidet, welche Ereignisse wichtig sind. --- **Lebenszyklus eines Events** Ein typischer Ablauf: ```text Ereignis entsteht │ ▼ Monitoring erkennt Event │ ▼ Event klassifizieren │ ▼ Filtern │ ▼ Priorisieren │ ▼ Aktion auslösen │ ▼ Event protokollieren ``` Nicht jedes Event führt zu einer Aktion. --- **Kategorien von Events** ITIL unterscheidet grundsätzlich drei Event-Typen: | Event-Typ | Bedeutung | |-----------|-----------| | Informational | normale Information | | Warning | mögliche zukünftige Störung | | Exception | Fehler oder kritischer Zustand | Diese Einteilung hilft bei der automatischen Verarbeitung. --- **Informational Events** Informational Events dokumentieren normale Vorgänge. Beispiele: - Server gestartet - Benutzer angemeldet - Backup begonnen - Dienst erfolgreich beendet - Software installiert - VM erstellt - Zertifikat erfolgreich erneuert Diese Events dienen hauptsächlich der Dokumentation. Normalerweise ist keine Reaktion erforderlich. --- **Warning Events** Warning Events weisen auf mögliche zukünftige Probleme hin. Beispiele: - Festplatte zu 85 % belegt - Zertifikat läuft in 30 Tagen ab - CPU dauerhaft hoch ausgelastet - Speicherverbrauch steigt - Backup dauert ungewöhnlich lange - Datenbank wächst stark Noch besteht kein Incident. Es sollte jedoch geprüft werden, ob Maßnahmen erforderlich sind. --- **Exception Events** Exception Events zeigen einen Fehler oder kritischen Zustand an. Beispiele: - Server nicht erreichbar - Backup fehlgeschlagen - RAID degradiert - Zertifikat abgelaufen - Datenbank gestoppt - Webservice antwortet nicht - Netzwerkschnittstelle ausgefallen - Container abgestürzt Diese Events führen häufig zu: - Alarmen, - Tickets, - Automatisierungen, - oder Incidents. --- **Warum nicht jedes Event gleich wichtig ist** Ein Drucker im Lager fällt aus. Ein Domänencontroller fällt aus. Beides sind Exception Events. Die Auswirkungen unterscheiden sich jedoch erheblich. Deshalb erfolgt zusätzlich eine Priorisierung. --- **Priorisierung von Events** Bei der Priorisierung werden unter anderem berücksichtigt: - betroffener Service, - Kritikalität, - Anzahl betroffener Benutzer, - geschäftliche Auswirkungen, - Sicherheitsrelevanz, - Wiederholungen, - Tageszeit, - vorhandene Redundanz. Dadurch entstehen sinnvolle Reaktionen. --- **Beispiel** Zertifikat läuft in 30 Tagen ab. → Warning Zertifikat heute abgelaufen. → Exception Der Event-Typ ändert sich automatisch, obwohl derselbe Sachverhalt überwacht wird. --- **Event-Filter** Nicht alle Events sollen angezeigt werden. Filter unterdrücken beispielsweise: - bekannte Wartungen, - Testsysteme, - doppelte Meldungen, - bereits bestätigte Fehler, - unwichtige Statusänderungen, - Debug-Meldungen. Dadurch sinkt die Anzahl unnötiger Alarme. --- **Warum Filter wichtig sind** Ohne Filter entstehen häufig: - Alarmfluten, - doppelte Tickets, - unnötige Eskalationen, - ignorierte Warnungen, - überlastete Administratoren. Ein gutes Monitoring meldet möglichst nur relevante Ereignisse. --- **Event-Korrelation** Mehrere Events können dieselbe Ursache besitzen. Beispiel: Ein Switch fällt aus. Dadurch entstehen gleichzeitig: - Server nicht erreichbar - Drucker offline - Access Points offline - Telefonanlage nicht erreichbar - NAS nicht erreichbar Eine Event-Korrelation erkennt, dass alle Meldungen wahrscheinlich dieselbe Ursache besitzen. Dadurch entsteht nicht für jedes Event ein separates Incident-Ticket. --- **Deduplizierung** Viele Systeme melden denselben Fehler mehrfach. Beispiel: Alle 30 Sekunden: > Datenbank nicht erreichbar Die Deduplizierung fasst identische Events zusammen. Dadurch entsteht nur ein Alarm. --- **Unterdrückung (Suppression)** Bei geplanten Wartungen können bestimmte Events unterdrückt werden. Beispiel: Während eines genehmigten Changes: - Server wird neu gestartet. Das Monitoring erkennt den Ausfall, erzeugt jedoch keinen Incident, da die Wartung bekannt ist. --- **Zeitliche Bewertung** Auch der Zeitpunkt spielt eine Rolle. Beispiel: CPU: - 95 % für zwei Sekunden → normal - 95 % für zwei Stunden → Warnung - 100 % dauerhaft → Exception Nicht jede kurzfristige Spitze stellt ein Problem dar. --- **Abhängigkeiten berücksichtigen** Ein Service kann aus vielen Komponenten bestehen. Fällt der Router aus, melden gleichzeitig: - Webserver, - Datenbank, - Storage, - Backup, - Telefonie Fehler. Die eigentliche Ursache bleibt jedoch der Router. Deshalb sollten Abhängigkeiten im Monitoring berücksichtigt werden. --- **Business Impact** Nicht jedes technische Problem besitzt dieselbe geschäftliche Bedeutung. Beispiele: Testsystem nicht erreichbar. → geringer Business Impact. Produktionssystem ausgefallen. → hoher Business Impact. Event Management sollte diese Unterschiede berücksichtigen. --- **Automatische Reaktionen** Je nach Event können unterschiedliche Aktionen erfolgen. Beispiele: Informational: - protokollieren. Warning: - E-Mail, - Dashboard, - Ticket. Exception: - Alarm, - Incident, - SMS, - Bereitschaft informieren, - Automation starten. --- **Praxisbeispiel** Monitoring erkennt: Festplatte: 84 % → Information. 85 % → Warning. 95 % → Exception. 98 % → automatischer Incident. 100 % → Notfallmaßnahmen. Die Reaktion wird schrittweise intensiver. --- **Typische Fehler** **Fehler 1** Alle Events besitzen dieselbe Priorität. --- **Fehler 2** Keine Event-Korrelation. --- **Fehler 3** Keine Filter vorhanden. --- **Fehler 4** Doppelte Events erzeugen mehrere Tickets. --- **Fehler 5** Warnungen werden ignoriert. --- **Fehler 6** Business Impact wird nicht berücksichtigt. --- **Fehler 7** Wartungen erzeugen unnötige Alarme. --- **Fehler 8** Grenzwerte werden nie überprüft. --- **Checkliste Event Management** - [ ] Event korrekt klassifiziert - [ ] Priorität festgelegt - [ ] Filter angewendet - [ ] Event-Korrelation aktiv - [ ] Deduplizierung vorhanden - [ ] Wartungsfenster berücksichtigt - [ ] Business Impact bewertet - [ ] automatische Reaktion definiert - [ ] Dokumentation aktuell - [ ] Verantwortlichkeiten bekannt --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker konfigurieren häufig Monitoring- und Event-Management-Systeme. Typische Aufgaben: - Grenzwerte festlegen, - Event-Regeln erstellen, - Filter konfigurieren, - Alarmfluten reduzieren, - Event-Korrelation verbessern, - Dashboards pflegen, - Monitoring kontinuierlich optimieren. Ein gutes Event Management reduziert unnötige Arbeit und sorgt dafür, dass kritische Ereignisse schnell erkannt werden. --- **Zusammenfassung** > Event entsteht > > ↓ > > Event klassifizieren > > ↓ > > Filter anwenden > > ↓ > > Priorität bestimmen > > ↓ > > Event korrelieren > > ↓ > > Reaktion auslösen > > ↓ > > Dokumentieren --- **Merksätze** > Nicht jedes Event ist wichtig. > Informational Events dokumentieren normale Zustände. > Warning Events weisen auf mögliche zukünftige Probleme hin. > Exception Events erfordern häufig eine Reaktion. > Gute Filter und Event-Korrelation verhindern Alarmfluten. --- **Verwandte Seiten** - 10.1 Ziele und Grundlagen des Monitoring and Event Management - 10.3 Alarme, Eskalationen und Automatisierung - 10.4 Monitoring-Werkzeuge, Dashboards und Kennzahlen - 10.5 Zusammenspiel mit Incident, Problem, Change und Service Configuration Management - Incident Management - Problem Management - Service Configuration Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Event-Kategorien (Informational, Warning und Exception) entsprechen der ITIL-Praxis. Die konkreten Prioritäten, Filterregeln, Schwellenwerte und Automatisierungen werden organisationsspezifisch definiert und hängen von den überwachten Services sowie den eingesetzten Monitoring-Werkzeugen ab. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 10.3 Alarme, Eskalationen und Automatisierung > **Kurz erklärt** > > Nicht jedes Event erfordert menschliches Eingreifen. > > Erst wenn ein Ereignis eine definierte Bedeutung besitzt, wird daraus ein Alarm. > > Je nach Schwere können anschließend automatische Aktionen, Eskalationen oder die Erstellung eines Incident-Tickets erfolgen. > > Ziel ist es, Probleme möglichst schnell und möglichst automatisch zu erkennen und zu behandeln. --- **Vom Event zum Alarm** Ein Monitoring-System erzeugt kontinuierlich Events. Nur ein Teil dieser Events wird zu Alarmen. Ein typischer Ablauf: ```text Monitoring │ ▼ Event │ ▼ Bewertung │ ┌────┴────┐ │ │ keine Alarm Aktion │ ▼ Reaktion ``` Die Bewertung erfolgt anhand definierter Regeln. --- **Was ist ein Alarm?** Ein Alarm ist eine Benachrichtigung über ein relevantes Ereignis. Er informiert darüber, dass eine Reaktion erforderlich oder zumindest sinnvoll sein kann. Ein Alarm bedeutet jedoch nicht automatisch, dass bereits ein Incident vorliegt. --- **Beispiele für Alarme** Typische Alarme: - Festplatte fast voll - Backup fehlgeschlagen - RAID degradiert - Server nicht erreichbar - hohe CPU-Auslastung - Zertifikat läuft bald ab - Temperatur überschritten - Netzwerkverbindung unterbrochen - Container abgestürzt - Datenbank antwortet nicht Je nach Kritikalität unterscheiden sich die weiteren Maßnahmen. --- **Alarme priorisieren** Nicht jeder Alarm besitzt dieselbe Bedeutung. Mögliche Kriterien: - betroffener Service, - Business Impact, - Anzahl betroffener Benutzer, - Kritikalität, - Tageszeit, - Sicherheitsrelevanz, - vorhandene Redundanz, - Wiederholungen. Dadurch kann dieselbe technische Meldung unterschiedlich behandelt werden. --- **Alarmstufen** Viele Organisationen verwenden mehrere Alarmstufen. Beispiel: | Stufe | Bedeutung | |--------|-----------| | Information | nur protokollieren | | Warnung | beobachten | | Hoch | Administrator informieren | | Kritisch | sofort reagieren | | Notfall | Eskalation und Incident | Die genaue Anzahl der Stufen ist organisationsabhängig. --- **Alarmkanäle** Alarme können über verschiedene Wege zugestellt werden. Beispiele: - Dashboard - E-Mail - SMS - Push-Nachricht - Microsoft Teams - Slack - Telefonanruf - Bereitschaftssystem - Pager - ITSM-System Der Kanal richtet sich nach der Kritikalität. --- **Alarmrouting** Nicht jeder Alarm geht an dieselbe Person. Beispiele: | Alarm | Empfänger | |--------|-----------| | Netzwerk | Netzwerkteam | | Backup | Backup-Team | | Datenbank | Datenbankadministration | | Cloud | Cloud-Team | | Active Directory | Windows-Team | | Linux | Linux-Team | | Container | Plattform-Team | Dadurch gelangen Informationen direkt an die zuständigen Personen. --- **Automatische Reaktionen** Viele Alarme können automatisiert verarbeitet werden. Beispiele: - Dienst neu starten - Container neu starten - VM verschieben - Backup erneut starten - Speicher bereinigen - DNS umschalten - Last verteilen - Ticket erstellen - Benutzer informieren Nicht jede Situation erfordert sofort einen Administrator. --- **Selbstheilung (Self-Healing)** Self-Healing beschreibt automatische Korrekturmaßnahmen. Beispiele: - Dienst startet automatisch neu. - Container wird neu erstellt. - zweite Netzwerkverbindung wird aktiviert. - Cluster übernimmt den Betrieb. - Load Balancer entfernt fehlerhaften Server. - Speicherplatz wird automatisch erweitert. Dadurch entstehen viele Incidents gar nicht erst. --- **Beispiel** ```text Container beendet sich │ ▼ Monitoring erkennt Fehler │ ▼ Container automatisch neu starten │ ▼ Container läuft wieder │ ▼ Event dokumentieren ``` Der Benutzer bemerkt den Fehler möglicherweise überhaupt nicht. --- **Automatisierte Incident-Erstellung** Nicht jeder Alarm erzeugt automatisch einen Incident. Sinnvoll ist dies beispielsweise bei: - Serverausfall - RAID-Fehler - Datenbank nicht erreichbar - Backup fehlgeschlagen - Zertifikat abgelaufen - Cloud-Service ausgefallen Das ITSM-System erstellt automatisch ein Incident-Ticket. --- **Eskalationen** Kann ein Alarm nicht automatisch gelöst werden, beginnt häufig eine Eskalation. Beispiele: - Bereitschaft informieren, - Spezialisten hinzuziehen, - Incident Manager benachrichtigen, - Major Incident aktivieren. Welche Eskalation erfolgt, hängt von Schwere und Auswirkungen ab. --- **Zeitabhängige Eskalationen** Nicht jeder Alarm wird sofort eskaliert. Beispiel: CPU-Auslastung: - über 90 % für 30 Sekunden → ignorieren - über 90 % für 10 Minuten → Warnung - über 95 % für 30 Minuten → Incident Zeitfilter verhindern unnötige Reaktionen. --- **Mehrstufige Eskalationen** Ein möglicher Ablauf: ```text Alarm │ ▼ Administrator │ ▼ Bereitschaft │ ▼ Teamleiter │ ▼ Incident Manager │ ▼ Major Incident ``` Nicht jeder Alarm erreicht automatisch die höchste Eskalationsstufe. --- **Alarmunterdrückung** Während geplanter Wartungen können Alarme unterdrückt werden. Beispiel: Ein Server wird bewusst neu gestartet. Das Monitoring erkennt: Server nicht erreichbar. Da ein genehmigter Change aktiv ist, wird kein Incident erzeugt. --- **Abhängigkeiten berücksichtigen** Ein ausgefallener Router verursacht häufig viele weitere Alarme. Beispiele: - Webserver offline - NAS offline - Drucker offline - VoIP offline - WLAN offline Durch Abhängigkeitsregeln wird möglichst nur der eigentliche Fehler hervorgehoben. --- **Alarmkorrelation** Mehrere Alarme können zusammengehören. Beispiel: - Datenbank langsam - Anwendung langsam - Webserver meldet Fehler Die eigentliche Ursache: Storage reagiert verzögert. Alarmkorrelation unterstützt Administratoren bei der Ursachenanalyse. --- **Alarmfluten vermeiden** Zu viele Warnungen führen häufig dazu, dass wichtige Alarme übersehen werden. Typische Maßnahmen: - Filter, - Korrelation, - Deduplizierung, - sinnvolle Grenzwerte, - Wartungsfenster, - Zeitfilter. Dadurch steigt die Qualität der Alarmierung. --- **Dashboards** Dashboards stellen Alarme übersichtlich dar. Typische Informationen: - aktuelle Alarme, - kritische Services, - Verfügbarkeit, - offene Incidents, - Trends, - Systemstatus, - Karten, - Serviceübersichten. Sie ermöglichen einen schnellen Überblick. --- **Benachrichtigung außerhalb der Arbeitszeit** Kritische Systeme werden häufig rund um die Uhr überwacht. Außerhalb der Geschäftszeiten können Alarme beispielsweise an: - Rufbereitschaft, - Bereitschaftsdienst, - externen Dienstleister gesendet werden. Dadurch bleibt die Reaktionsfähigkeit erhalten. --- **Praxisbeispiel** Ein RAID-Verbund meldet: Eine Festplatte ausgefallen. Automatisch geschieht: - Alarm erzeugen, - Incident erstellen, - Storage-Team informieren, - Dashboard aktualisieren, - Bereitschaft benachrichtigen, - Dokumentation ergänzen. Die eigentliche Reparatur erfolgt anschließend durch den zuständigen Administrator. --- **Typische Fehler** **Fehler 1** Jeder Alarm erzeugt sofort einen Incident. --- **Fehler 2** Keine automatische Fehlerbehandlung. --- **Fehler 3** Keine Alarmkorrelation. --- **Fehler 4** Zu viele Benachrichtigungen. --- **Fehler 5** Keine Wartungsfenster berücksichtigt. --- **Fehler 6** Falsche Empfänger erhalten Alarme. --- **Fehler 7** Self-Healing wird nicht genutzt. --- **Fehler 8** Bereitschaft wird wegen unwichtiger Warnungen gestört. --- **Fehler 9** Alarmregeln werden nach Änderungen nicht angepasst. --- **Fehler 10** Fehlgeschlagene Automatisierungen bleiben unbemerkt. --- **Checkliste Alarmmanagement** - [ ] Event korrekt bewertet - [ ] Alarmstufe festgelegt - [ ] richtiger Empfänger definiert - [ ] Eskalation vorhanden - [ ] Wartungsfenster berücksichtigt - [ ] Alarm dokumentiert - [ ] Korrelation eingerichtet - [ ] Deduplizierung aktiv - [ ] Dashboard aktualisiert - [ ] regelmäßige Überprüfung geplant --- **Checkliste Automatisierung** - [ ] Self-Healing möglich - [ ] Workflow getestet - [ ] Rollback vorhanden - [ ] Fehler protokolliert - [ ] Monitoring aktiv - [ ] Incident-Erstellung geprüft - [ ] Benachrichtigungen getestet - [ ] Verantwortlichkeiten dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker richten häufig Alarmierungen und automatische Reaktionen ein. Typische Aufgaben: - Alarmregeln definieren, - Eskalationen konfigurieren, - Dashboards pflegen, - Automatisierungen entwickeln, - Self-Healing testen, - Benachrichtigungen überprüfen, - Alarmfluten reduzieren, - Monitoring kontinuierlich verbessern. Ein gut abgestimmtes Alarmmanagement sorgt dafür, dass kritische Ereignisse schnell erkannt und möglichst automatisch behandelt werden. --- **Zusammenfassung** > Monitoring erkennt Event > > ↓ > > Event bewerten > > ↓ > > Alarm erzeugen > > ↓ > > Priorisieren > > ↓ > > Automatische Reaktion oder Eskalation > > ↓ > > Incident (falls erforderlich) > > ↓ > > Dokumentation --- **Merksätze** > Nicht jeder Alarm führt zu einem Incident. > Gute Alarmregeln vermeiden unnötige Benachrichtigungen. > Self-Healing kann viele Incidents vollständig verhindern. > Alarmkorrelation unterstützt die Ursachenanalyse. > Die richtige Information muss zur richtigen Zeit die richtige Person erreichen. --- **Verwandte Seiten** - 10.1 Ziele und Grundlagen des Monitoring and Event Management - 10.2 Event-Typen, Filter und Priorisierung - 10.4 Monitoring-Werkzeuge, Dashboards und Kennzahlen - 10.5 Zusammenspiel mit Incident, Problem, Change und Service Configuration Management - Incident Management - Problem Management - Service Configuration Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Alarmierungsstrategien, Eskalationsmodelle, Self-Healing-Beispiele und Automatisierungen sind herstellerneutrale Praxisempfehlungen. ITIL definiert die Grundprinzipien des Monitoring and Event Management, schreibt jedoch keine konkreten Alarmstufen, Eskalationswege oder Automatisierungsmechanismen vor. Diese werden organisationsabhängig anhand der Servicekritikalität und der eingesetzten Monitoring- und ITSM-Werkzeuge umgesetzt. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 10.4 Monitoring-Werkzeuge, Dashboards und Kennzahlen > **Kurz erklärt** > > Monitoring-Werkzeuge sammeln kontinuierlich Informationen über IT-Services, Anwendungen und Infrastruktur. > > Dashboards bereiten diese Informationen übersichtlich auf, während Kennzahlen (Metrics) helfen, Trends, Risiken und Verbesserungsmöglichkeiten zu erkennen. > > Ziel ist es, aus einer großen Menge technischer Daten verwertbare Informationen für den Betrieb und die Entscheidungsfindung zu gewinnen. --- **Warum Monitoring-Werkzeuge notwendig sind** Moderne IT-Umgebungen bestehen häufig aus: - Servern, - virtuellen Maschinen, - Containern, - Cloud-Diensten, - Datenbanken, - Netzwerkkomponenten, - Firewalls, - Anwendungen, - APIs, - Storage-Systemen, - IoT-Geräten. Eine manuelle Überwachung wäre praktisch unmöglich. Monitoring-Werkzeuge sammeln und bewerten diese Informationen automatisch. --- **Aufgaben eines Monitoring-Werkzeugs** Ein Monitoring-System kann beispielsweise: - Systeme überwachen, - Services überwachen, - Events sammeln, - Alarme erzeugen, - Kennzahlen berechnen, - Trends erkennen, - Dashboards bereitstellen, - Berichte erzeugen, - Benachrichtigungen versenden, - Automatisierungen starten. Das Werkzeug ersetzt dabei nicht die Analyse durch Fachpersonal. Es liefert die notwendigen Informationen. --- **Was ist ein Dashboard?** Ein Dashboard fasst wichtige Informationen übersichtlich zusammen. Es beantwortet Fragen wie: - Welche Systeme sind gestört? - Welche Services sind kritisch? - Welche Alarme sind offen? - Gibt es Kapazitätsprobleme? - Welche Trends sind erkennbar? - Welche Incidents bestehen aktuell? Dadurch entsteht ein schneller Überblick über den aktuellen Zustand der IT. --- **Ziele eines Dashboards** Ein gutes Dashboard soll: - übersichtlich sein, - aktuelle Daten anzeigen, - Prioritäten sichtbar machen, - schnelle Entscheidungen unterstützen, - Trends darstellen, - unnötige Informationen vermeiden, - verschiedene Zielgruppen unterstützen. Nicht jede Person benötigt dieselben Informationen. --- **Verschiedene Dashboards** Je nach Rolle unterscheiden sich Dashboards erheblich. Beispiele: - Service Desk - Netzwerkteam - Serveradministration - Datenbankadministration - Cloud-Team - Informationssicherheit - Management - Rufbereitschaft Jede Zielgruppe benötigt andere Informationen. --- **Service-Desk-Dashboard** Typische Inhalte: - offene Incidents, - offene Service Requests, - aktuelle Alarme, - Major Incidents, - Verfügbarkeit wichtiger Services, - Ticketprioritäten, - SLA-Verletzungen, - Wartungsfenster. Das Dashboard unterstützt die tägliche Bearbeitung. --- **Netzwerk-Dashboard** Mögliche Informationen: - Bandbreitenauslastung, - Switch-Status, - Router, - VPN, - Firewalls, - WLAN, - Paketverluste, - Latenzen, - Verbindungsqualität. Dadurch lassen sich Netzwerkprobleme schnell erkennen. --- **Server-Dashboard** Typische Kennzahlen: - CPU, - RAM, - Festplatten, - Prozesse, - Dienste, - Hardwarezustand, - Temperaturen, - Backupstatus, - Virtualisierung. --- **Cloud-Dashboard** Beispiele: - virtuelle Maschinen, - Kubernetes, - Container, - Storage, - Datenbanken, - Kosten, - Skalierung, - Verfügbarkeit, - Cloud-Regionen. Cloud-Dashboards berücksichtigen häufig zusätzlich wirtschaftliche Kennzahlen. --- **Management-Dashboard** Das Management benötigt meist keine technischen Details. Interessant sind beispielsweise: - Serviceverfügbarkeit, - SLA-Erfüllung, - Major Incidents, - Trends, - Risiken, - Benutzerzufriedenheit, - Kosten, - Verbesserungsmaßnahmen. Dashboards sollten immer an die Zielgruppe angepasst werden. --- **Was sind Kennzahlen (Metrics)?** Kennzahlen beschreiben messbare Eigenschaften eines Systems oder Services. Beispiele: - CPU-Auslastung, - Antwortzeit, - Verfügbarkeit, - Fehlerrate, - Speicherauslastung, - Netzwerkverkehr, - Anzahl Incidents, - Anzahl Alarme, - Backup-Erfolg. Kennzahlen bilden die Grundlage für Berichte und Entscheidungen. --- **Technische Kennzahlen** Typische technische Kennzahlen: - CPU-Auslastung - Arbeitsspeicher - Festplattenbelegung - Netzwerkdurchsatz - Temperatur - Antwortzeit - IOPS - Datenbankverbindungen - Paketverlust - DNS-Antwortzeit Sie beschreiben den technischen Zustand. --- **Servicebezogene Kennzahlen** Beispiele: - Serviceverfügbarkeit, - Anmeldezeit, - Transaktionsdauer, - erfolgreiche Logins, - API-Verfügbarkeit, - Anzahl erfolgreicher Bestellungen, - Wiederherstellungszeit, - SLA-Erfüllung. Sie beschreiben die Sicht des Benutzers. --- **Geschäftsbezogene Kennzahlen** Beispiele: - Bestellungen pro Stunde, - Zahlungsvorgänge, - Produktionsmenge, - Kundenanfragen, - Umsatz, - Bearbeitungszeit, - Benutzerzufriedenheit. Diese Kennzahlen verbinden IT und Geschäftsprozesse. --- **Wichtige Monitoring-Kennzahlen** Beispiele: | Kennzahl | Aussage | |-----------|----------| | Verfügbarkeit | läuft der Service? | | Antwortzeit | wie schnell reagiert der Service? | | CPU | Prozessorauslastung | | RAM | Speicherverbrauch | | Festplatte | freier Speicher | | Netzwerk | Datenverkehr | | Fehlerrate | Anzahl Fehler | | Backup | erfolgreich oder fehlgeschlagen | | Zertifikate | verbleibende Laufzeit | | Alarme | Anzahl kritischer Ereignisse | Nicht jede Kennzahl ist für jeden Service relevant. --- **KPIs (Key Performance Indicators)** KPIs sind besonders wichtige Kennzahlen. Beispiele: - Serviceverfügbarkeit 99,9 % - Wiederherstellungszeit - SLA-Erfüllung - Incident-Anzahl - Benutzerzufriedenheit - erfolgreiche Deployments - Fehlerrate - Mean Time to Detect (MTTD) - Mean Time to Restore (MTTR) KPIs dienen häufig als Grundlage für Service Reviews. --- **MTTD** Mean Time to Detect beschreibt, wie schnell eine Störung erkannt wird. Je kleiner der Wert, desto früher erkennt das Monitoring Probleme. --- **MTTR** Mean Time to Restore beschreibt, wie lange die Wiederherstellung eines Services dauert. Monitoring kann MTTR verkürzen, weil Fehler früher erkannt werden. --- **Trendanalysen** Einzelne Messwerte sind oft wenig aussagekräftig. Trends zeigen Entwicklungen. Beispiele: - Speicherverbrauch steigt seit Wochen. - CPU-Auslastung nimmt kontinuierlich zu. - Datenbank wächst täglich. - Anzahl Incidents sinkt. Trends unterstützen Kapazitätsplanung und Verbesserungen. --- **Historische Daten** Monitoring speichert häufig Messwerte über längere Zeit. Dadurch lassen sich: - Entwicklungen, - Vergleiche, - Kapazitätsplanungen, - Ursachenanalysen durchführen. Historische Daten sind für Continual Improvement besonders wertvoll. --- **Visualisierung** Kennzahlen lassen sich unterschiedlich darstellen. Beispiele: - Tabellen, - Balkendiagramme, - Liniendiagramme, - Kreisdiagramme, - Heatmaps, - Ampelsysteme, - Service Maps. Die Darstellung sollte zur jeweiligen Fragestellung passen. --- **Ampelsysteme** Viele Dashboards verwenden Farben. Beispiel: 🟢 Normal 🟡 Warnung 🔴 Kritisch Farben ermöglichen eine schnelle Orientierung. Sie sollten jedoch nicht die einzige Informationsquelle sein. --- **Service Maps** Service Maps zeigen, welche Systeme zu einem Service gehören. Beispiel: ```text Online-Shop │ ├── Webserver ├── Datenbank ├── Storage ├── DNS ├── Load Balancer └── Payment API ``` Dadurch werden Abhängigkeiten sichtbar. --- **Kapazitätsplanung** Monitoring unterstützt Capacity Management. Beispiele: - Speicher wächst kontinuierlich. - CPU dauerhaft hoch. - Netzwerk regelmäßig ausgelastet. - Datenbank benötigt mehr Ressourcen. Kapazitätsprobleme können früh erkannt werden. --- **Monitoring und Reports** Aus Kennzahlen entstehen Reports. Typische Inhalte: - Verfügbarkeit, - SLA-Erfüllung, - Trends, - Major Incidents, - Alarme, - Wartungsfenster, - Verbesserungen. Reports richten sich häufig an: - Service Owner, - Management, - Kunden, - Administratoren. --- **Praxisbeispiel** Das Dashboard zeigt: - CPU 28 % - RAM 61 % - Storage 78 % - Zertifikat 25 Tage - Backup erfolgreich - keine offenen kritischen Alarme Administratoren erkennen sofort, dass aktuell kein unmittelbarer Handlungsbedarf besteht. --- **Typische Fehler** **Fehler 1** Zu viele Kennzahlen. --- **Fehler 2** Falsche Zielgruppe. --- **Fehler 3** Veraltete Dashboards. --- **Fehler 4** Nur technische Kennzahlen. --- **Fehler 5** Keine Trendanalyse. --- **Fehler 6** KPIs sind unklar definiert. --- **Fehler 7** Service Maps fehlen. --- **Fehler 8** Historische Daten werden nicht ausgewertet. --- **Fehler 9** Dashboards enthalten zu viele Details. --- **Fehler 10** Kennzahlen werden gemessen, aber nicht genutzt. --- **Checkliste Monitoring-Dashboard** - [ ] aktuelle Daten - [ ] passende Zielgruppe - [ ] relevante KPIs - [ ] kritische Services sichtbar - [ ] Trends vorhanden - [ ] Alarme sichtbar - [ ] Service Maps integriert - [ ] übersichtliche Darstellung - [ ] regelmäßige Aktualisierung - [ ] verständliche Visualisierung --- **Checkliste Kennzahlen** - [ ] eindeutig definiert - [ ] messbar - [ ] aktuell - [ ] nachvollziehbar - [ ] historisch auswertbar - [ ] für Entscheidungen geeignet - [ ] Servicebezug vorhanden - [ ] regelmäßig überprüft --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten regelmäßig mit Monitoring-Dashboards und Kennzahlen. Typische Aufgaben: - Dashboards erstellen, - Kennzahlen definieren, - Trends analysieren, - Alarme auswerten, - Reports erstellen, - Service Maps pflegen, - Monitoring verbessern, - Kapazitäten planen. Die Fähigkeit, Messwerte richtig zu interpretieren, ist im IT-Betrieb oft wichtiger als das reine Sammeln der Daten. --- **Zusammenfassung** > Monitoring sammelt Messwerte > > ↓ > > Kennzahlen berechnen > > ↓ > > Dashboard darstellen > > ↓ > > Trends erkennen > > ↓ > > Reports erstellen > > ↓ > > Entscheidungen treffen > > ↓ > > Services verbessern --- **Merksätze** > Ein Dashboard soll Entscheidungen unterstützen – nicht möglichst viele Daten anzeigen. > KPIs konzentrieren sich auf die wichtigsten Kennzahlen. > Trends sind häufig wertvoller als einzelne Messwerte. > Servicebezogene Kennzahlen sind für Benutzer wichtiger als reine Hardwarewerte. > Historische Daten ermöglichen Ursachenanalysen und Kapazitätsplanung. --- **Verwandte Seiten** - 10.1 Ziele und Grundlagen des Monitoring and Event Management - 10.2 Event-Typen, Filter und Priorisierung - 10.3 Alarme, Eskalationen und Automatisierung - 10.5 Zusammenspiel mit Incident, Problem, Change und Service Configuration Management - Service Level Management - Continual Improvement - Capacity and Performance Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Capacity and Performance Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Dashboards, Kennzahlen, KPIs und Visualisierungen sind herstellerneutrale Praxisempfehlungen. ITIL definiert Grundprinzipien für Monitoring und Reporting, schreibt jedoch keine konkreten Werkzeuge, Dashboards oder Kennzahlen vor. Die Auswahl richtet sich nach den überwachten Services, den Geschäftsanforderungen und den Informationsbedürfnissen der jeweiligen Zielgruppen. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 10.5 Zusammenspiel mit Incident, Problem, Change und Service Configuration Management > **Kurz erklärt** > > Monitoring and Event Management arbeitet eng mit anderen ITIL Practices zusammen. > > Monitoring erkennt Ereignisse, bewertet deren Bedeutung und stellt Informationen für andere Prozesse bereit. > > Erst durch das Zusammenspiel mit Incident Management, Problem Management, Change Enablement und Service Configuration Management entsteht ein vollständiger und effizienter IT-Servicebetrieb. --- **Warum das Zusammenspiel wichtig ist** Monitoring allein behebt keine Fehler. Es beantwortet zunächst nur die Frage: > **"Was ist passiert?"** Andere ITIL Practices beantworten anschließend beispielsweise: - Muss eine Störung behoben werden? - Ist die Ursache bekannt? - Muss eine Änderung durchgeführt werden? - Welche Systeme sind betroffen? - Welche Services sind beeinträchtigt? Erst gemeinsam entsteht ein vollständiger Ablauf. --- **Zusammenspiel der Practices** ```text Monitoring │ ▼ Event │ ▼ Bewertung │ ▼ Incident? │ ┌────┴────┐ │ │ Nein Ja │ │ ▼ ▼ Protokoll Incident │ ▼ Problem? │ ▼ Change? │ ▼ Service wiederhergestellt ``` Nicht jedes Event durchläuft alle Schritte. --- **Monitoring und Incident Management** Diese beiden Practices arbeiten besonders eng zusammen. Monitoring erkennt Ereignisse. Incident Management stellt den normalen Servicebetrieb wieder her. Beispiel: Monitoring erkennt: > Webserver antwortet nicht. Anschließend: - Incident erstellen, - Service Desk informieren, - Administrator alarmieren, - Service wiederherstellen. Monitoring erkennt den Fehler. Incident Management behebt ihn. --- **Monitoring erkennt häufig Incidents vor dem Benutzer** Ein großer Vorteil moderner Monitoring-Systeme: Probleme werden oft erkannt, bevor Benutzer sie melden. Beispiele: - Speicher fast voll - Backup fehlgeschlagen - Zertifikat läuft bald ab - RAID degradiert - Datenbank antwortet langsam Viele Incidents können dadurch vollständig vermieden werden. --- **Monitoring und Problem Management** Ein einzelner Alarm ist häufig kein Problem. Wiederholen sich jedoch dieselben Events regelmäßig, kann daraus ein Problem Record entstehen. Beispiel: Jeden Dienstag: - Datenbank langsam. Incident wird jedes Mal behoben. Monitoring zeigt jedoch, dass dieselbe Ursache regelmäßig auftritt. Jetzt beginnt Problem Management mit der Ursachenanalyse. --- **Trendanalysen unterstützen Problem Management** Monitoring speichert historische Daten. Dadurch lassen sich erkennen: - wiederkehrende Fehler, - steigende Auslastung, - häufige Neustarts, - zunehmende Antwortzeiten, - regelmäßig fehlschlagende Backups. Diese Informationen helfen bei der Suche nach der eigentlichen Ursache. --- **Monitoring und Change Enablement** Viele Changes beeinflussen Monitoring. Beispiele: - neuer Server, - zusätzliche VM, - neue Firewall, - neue Anwendung, - Cloud-Service, - Netzwerksegment. Nach einem Change muss häufig auch das Monitoring angepasst werden. --- **Monitoring vor einem Change** Vor Änderungen liefern Monitoring-Daten wichtige Informationen. Beispiele: - aktuelle Auslastung, - Antwortzeiten, - Verfügbarkeit, - Fehlerquote, - Baseline. Dadurch kann später geprüft werden, ob der Change erfolgreich war. --- **Monitoring nach einem Change** Nach der Umsetzung wird kontrolliert: - Service erreichbar? - Fehler aufgetreten? - Antwortzeiten verändert? - CPU erhöht? - neue Alarme? Monitoring bestätigt, ob die Änderung erfolgreich war. --- **Geplante Wartungen** Während eines genehmigten Changes sollten Monitoring-Systeme dies berücksichtigen. Beispiel: Server wird bewusst neu gestartet. Ohne Wartungsfenster: - Alarm, - Incident, - Eskalation. Mit Wartungsfenster: - Event wird dokumentiert, - keine unnötigen Alarme entstehen. --- **Monitoring und Service Configuration Management** Monitoring überwacht Configuration Items. Configuration Management beschreibt diese. Beispiele: - Server, - Switch, - Router, - Datenbank, - Container, - VM, - Storage, - Firewall. Monitoring liefert aktuelle Zustandsinformationen. Configuration Management liefert Struktur und Beziehungen. --- **Warum Configuration Items wichtig sind** Ohne Configuration Management weiß Monitoring häufig nicht, welche Bedeutung ein System besitzt. Beispiel: Server 01 fällt aus. Monitoring erkennt den Ausfall. Erst Configuration Management zeigt: Dieser Server gehört zum: - ERP-System, - Produktionssteuerung, - Rechnungswesen. Dadurch lässt sich die Auswirkung deutlich besser bewerten. --- **Service Maps** Service Maps verbinden Monitoring und Configuration Management. Beispiel: ```text Online-Shop │ ├── Webserver ├── Load Balancer ├── Datenbank ├── Storage ├── DNS └── Payment API ``` Fällt eine Komponente aus, werden die betroffenen Services sofort sichtbar. --- **Abhängigkeiten erkennen** Configuration Management zeigt, welche Systeme voneinander abhängig sind. Dadurch kann Monitoring: - Alarme korrelieren, - Prioritäten anpassen, - Root Causes schneller erkennen. --- **Monitoring und Availability Management** Monitoring liefert die Grundlage zur Messung der Verfügbarkeit. Beispiele: - Server erreichbar? - Anwendung verfügbar? - API antwortet? - Website erreichbar? Availability Management nutzt diese Daten, um Verfügbarkeitsziele zu bewerten. --- **Monitoring und Capacity Management** Monitoring misst kontinuierlich: - CPU, - RAM, - Speicher, - Netzwerk, - Datenbankgröße. Capacity Management nutzt diese Informationen, um zukünftige Ressourcen zu planen. --- **Monitoring und Information Security Management** Monitoring erkennt auch sicherheitsrelevante Ereignisse. Beispiele: - ungewöhnliche Logins, - fehlgeschlagene Anmeldungen, - Malware, - Firewall-Ereignisse, - verdächtiger Netzwerkverkehr, - Privilegienänderungen. Diese Events können an Security-Prozesse weitergeleitet werden. --- **Monitoring und Continual Improvement** Monitoring liefert kontinuierlich Kennzahlen. Dadurch lassen sich Verbesserungen erkennen. Beispiele: - MTTR sinkt, - weniger Incidents, - höhere Verfügbarkeit, - kürzere Antwortzeiten, - bessere Automatisierung. Continual Improvement nutzt diese Daten, um Prozesse weiterzuentwickeln. --- **Monitoring und Service Level Management** Viele SLA-Kennzahlen basieren direkt auf Monitoring-Daten. Beispiele: - Verfügbarkeit, - Antwortzeit, - Ausfallzeit, - Servicequalität. Ohne zuverlässiges Monitoring können SLA-Ziele kaum objektiv gemessen werden. --- **Praxisbeispiel** Das Monitoring erkennt: Die Antwortzeit einer Datenbank steigt seit mehreren Wochen kontinuierlich an. Zunächst entstehen einzelne Warning Events. Später treten wiederholt Incidents auf. Problem Management untersucht die Ursache und stellt fest, dass der verfügbare Speicher nicht mehr ausreicht. Ein genehmigter Change erweitert den Speicher. Nach der Umsetzung zeigt das Monitoring wieder normale Antwortzeiten. Die gewonnenen Erkenntnisse fließen anschließend in Continual Improvement ein. --- **Typische Fehler** **Fehler 1** Monitoring arbeitet unabhängig von Incident Management. --- **Fehler 2** Configuration Items sind nicht aktuell. --- **Fehler 3** Changes berücksichtigen das Monitoring nicht. --- **Fehler 4** Monitoring-Daten werden nicht ausgewertet. --- **Fehler 5** Wiederkehrende Events führen nicht zu Problem Records. --- **Fehler 6** Service Maps fehlen. --- **Fehler 7** Abhängigkeiten werden nicht berücksichtigt. --- **Fehler 8** Monitoring misst keine SLA-Kennzahlen. --- **Fehler 9** Kapazitätsdaten werden nicht ausgewertet. --- **Fehler 10** Verbesserungen basieren nicht auf Messdaten. --- **Checkliste Zusammenspiel** - [ ] Monitoring aktiv - [ ] Event korrekt bewertet - [ ] Incident bei Bedarf erstellt - [ ] Problem Record bei wiederkehrenden Fehlern geprüft - [ ] Change berücksichtigt - [ ] Configuration Items aktuell - [ ] Service Maps gepflegt - [ ] SLA-Kennzahlen verfügbar - [ ] Sicherheitsereignisse erkannt - [ ] Verbesserungspotenziale dokumentiert --- **Checkliste Monitoring-Prozess** - [ ] Events gesammelt - [ ] Filter eingerichtet - [ ] Alarmregeln geprüft - [ ] Eskalationen definiert - [ ] Dashboards aktuell - [ ] KPIs überwacht - [ ] Trends ausgewertet - [ ] Reports erstellt - [ ] Verantwortlichkeiten bekannt - [ ] regelmäßige Optimierung geplant --- **Bedeutung für Fachinformatiker für Systemintegration** Monitoring gehört zu den wichtigsten Werkzeugen im Arbeitsalltag eines Fachinformatikers. Typische Aufgaben: - Monitoring konfigurieren, - Alarme analysieren, - Incidents früh erkennen, - Monitoring nach Changes anpassen, - Configuration-Daten pflegen, - Service Maps aktualisieren, - Trends auswerten, - Automatisierungen verbessern. Ein gut integriertes Monitoring unterstützt nahezu alle Bereiche des IT-Service-Managements. --- **Zusammenfassung** > Monitoring erkennt Events > > ↓ > > Event bewerten > > ↓ > > Incident auslösen (falls erforderlich) > > ↓ > > Problem analysieren > > ↓ > > Change umsetzen > > ↓ > > Monitoring überprüft Ergebnis > > ↓ > > Erkenntnisse für Continual Improvement nutzen --- **Merksätze** > Monitoring erkennt Ereignisse – andere Practices reagieren darauf. > Monitoring liefert die Grundlage für Incident, Problem und Change Management. > Configuration Management erklärt die Beziehungen zwischen den überwachten Systemen. > Gute Service Maps beschleunigen die Ursachenanalyse. > Monitoring-Daten bilden die Grundlage für kontinuierliche Verbesserungen. --- **Verwandte Seiten** - 10.1 Ziele und Grundlagen des Monitoring and Event Management - 10.2 Event-Typen, Filter und Priorisierung - 10.3 Alarme, Eskalationen und Automatisierung - 10.4 Monitoring-Werkzeuge, Dashboards und Kennzahlen - Incident Management - Problem Management - Change Enablement - Service Configuration Management - Service Level Management - Availability Management - Capacity and Performance Management - Information Security Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Availability Management - PeopleCert – ITIL Practice Guide: Capacity and Performance Management - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Zusammenhänge orientieren sich an den offiziellen ITIL-Practices. Monitoring and Event Management stellt Informationen für zahlreiche weitere Practices bereit, übernimmt jedoch selbst weder die Fehlerbehebung noch die Ursachenanalyse oder die Planung von Änderungen. Die konkrete technische Umsetzung hängt von den eingesetzten Monitoring-, ITSM- und CMDB-Systemen der jeweiligen Organisation ab. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 11. Service Configuration Management # 11.1 Ziele und Grundlagen des Service Configuration Management > **Kurz erklärt** > > Service Configuration Management sorgt dafür, dass Informationen über IT-Services und deren Bestandteile vollständig, aktuell und nachvollziehbar verwaltet werden. > > Dazu gehören unter anderem Server, Clients, Netzwerkgeräte, Anwendungen, Cloud-Ressourcen, Dokumentationen und ihre gegenseitigen Beziehungen. > > Ziel ist es, jederzeit zu wissen, **welche Komponenten existieren, wie sie zusammenhängen und welche Auswirkungen Änderungen oder Störungen haben.** --- **Was ist Service Configuration Management?** Service Configuration Management ist eine ITIL Practice zur Verwaltung von Informationen über Services und deren Bestandteile. Dabei werden nicht die Geräte selbst verwaltet, sondern die Informationen über diese Objekte. Beispiele: - Server - Clients - Notebooks - Switches - Router - Firewalls - Drucker - virtuelle Maschinen - Container - Cloud-Ressourcen - Anwendungen - Datenbanken - Zertifikate - Dokumentationen Alle diese Objekte können Bestandteil eines IT-Services sein. --- **Warum Service Configuration Management wichtig ist** In modernen IT-Umgebungen existieren oft tausende oder sogar zehntausende Komponenten. Ohne eine strukturierte Verwaltung entstehen schnell Fragen wie: - Welcher Server gehört zu welchem Service? - Welche Datenbank nutzt diese Anwendung? - Welche Firewall schützt diesen Dienst? - Welche Systeme sind von einem Ausfall betroffen? - Welche Änderungen beeinflussen diesen Service? Service Configuration Management beantwortet genau diese Fragen. --- **Ziele des Service Configuration Management** Die wichtigsten Ziele sind: - aktuelle Informationen bereitstellen, - Beziehungen zwischen Komponenten dokumentieren, - Auswirkungen von Änderungen erkennen, - Incident Management unterstützen, - Problem Management unterstützen, - Change Enablement unterstützen, - Risiken reduzieren, - Transparenz schaffen, - Entscheidungsgrundlagen liefern. --- **Was ist ein Configuration Item (CI)?** Ein Configuration Item (CI) ist jedes Objekt, das für die Bereitstellung oder Verwaltung eines IT-Services relevant ist. Ein CI kann beispielsweise sein: - Server - Switch - Router - Firewall - Notebook - Datenbank - Software - Container - virtuelle Maschine - Cloud-Service - Dokumentation - SLA - Zertifikat Nicht jedes Inventarobjekt muss automatisch ein CI sein. Entscheidend ist die Bedeutung für den Service. --- **Beispiele für Configuration Items** | Kategorie | Beispiele | |-----------|-----------| | Hardware | Server, Notebook, Switch | | Software | Betriebssystem, ERP, Datenbank | | Netzwerk | Router, Firewall, VLAN | | Cloud | virtuelle Maschine, Storage, Load Balancer | | Dokumentation | Runbook, Architekturdiagramm | | Service | E-Mail, VPN, Fileserver | | Verträge | SLA, Wartungsvertrag | --- **Nicht jedes Objekt ist ein CI** Ein einzelnes Netzwerkkabel oder eine Computermaus wird häufig inventarisiert, aber nicht unbedingt als Configuration Item verwaltet. Dagegen besitzen folgende Objekte meist einen direkten Einfluss auf Services: - Server - Netzwerkgeräte - Anwendungen - virtuelle Maschinen - Cloud-Ressourcen - Datenbanken Diese werden häufig als CIs geführt. --- **Was wird über ein CI gespeichert?** Je nach Organisation können unterschiedliche Informationen gespeichert werden. Typische Angaben: - Name - eindeutige ID - Typ - Hersteller - Modell - Seriennummer - Standort - Besitzer - Verantwortlicher - aktueller Status - Version - Beziehungen - Dokumentation Je kritischer das CI, desto umfangreicher sind häufig die gespeicherten Informationen. --- **Der Lebenszyklus eines Configuration Items** Ein CI durchläuft mehrere Phasen. Beispiel: ```text Geplant │ ▼ Beschafft │ ▼ Installiert │ ▼ In Betrieb │ ▼ Geändert │ ▼ Außer Betrieb │ ▼ Entsorgt ``` Alle relevanten Änderungen sollten dokumentiert werden. --- **Status eines Configuration Items** Typische Status: - geplant - bestellt - installiert - produktiv - in Wartung - außer Betrieb - archiviert - entsorgt Der aktuelle Status erleichtert den Überblick. --- **Beziehungen zwischen Configuration Items** Ein großer Vorteil des Service Configuration Managements besteht darin, dass Beziehungen dokumentiert werden. Beispiel: ```text Online-Shop │ ├── Webserver │ │ │ └── Betriebssystem │ ├── Datenbank │ ├── Storage │ └── Firewall ``` Dadurch wird sichtbar, welche Komponenten voneinander abhängig sind. --- **Warum Beziehungen wichtig sind** Fällt eine Datenbank aus, kann dies Auswirkungen haben auf: - Webserver, - ERP, - Online-Shop, - Reporting, - mobile Anwendungen. Durch dokumentierte Beziehungen lassen sich Auswirkungen deutlich schneller erkennen. --- **Service statt Einzelgerät** ITIL betrachtet nicht einzelne Geräte, sondern den gesamten Service. Ein Benutzer interessiert sich beispielsweise nicht dafür, welcher Server ausgefallen ist. Wichtig ist für ihn, ob der E-Mail-Service funktioniert. Service Configuration Management verbindet technische Komponenten mit den bereitgestellten Services. --- **Service Maps** Service Maps zeigen grafisch, welche Configuration Items zu einem Service gehören. Beispiel: ```text VPN-Service │ ├── Firewall ├── VPN-Gateway ├── Active Directory ├── DNS └── Zertifikate ``` Dadurch lassen sich Störungen und Änderungen schneller bewerten. --- **Warum aktuelle Daten wichtig sind** Veraltete Informationen führen häufig zu: - falschen Entscheidungen, - unnötigen Incidents, - fehlerhaften Changes, - längeren Ausfallzeiten, - unvollständigen Analysen. Deshalb müssen Configuration-Daten regelmäßig gepflegt werden. --- **Praxisbeispiel** Ein Webserver fällt aus. Durch Service Configuration Management erkennt die IT sofort, dass betroffen sind: - Kundenportal, - Zahlungsdienst, - API, - Mobile App. Dadurch kann die Priorität schneller bestimmt und der Incident gezielt bearbeitet werden. --- **Typische Fehler** **Fehler 1** Configuration Items sind nicht aktuell. --- **Fehler 2** Beziehungen fehlen. --- **Fehler 3** Services sind nicht dokumentiert. --- **Fehler 4** Änderungen werden nicht nachgetragen. --- **Fehler 5** Verantwortlichkeiten sind unklar. --- **Fehler 6** Zu viele unwichtige Objekte werden als CIs verwaltet. --- **Fehler 7** Service Maps fehlen. --- **Fehler 8** Configuration Management wird nur als Inventarliste genutzt. --- **Checkliste Configuration Items** - [ ] eindeutige CI-ID vorhanden - [ ] aktueller Status gepflegt - [ ] Verantwortlicher dokumentiert - [ ] Beziehungen hinterlegt - [ ] Servicezuordnung vorhanden - [ ] Änderungen nachgeführt - [ ] Dokumentation aktuell - [ ] regelmäßige Überprüfung geplant --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten regelmäßig mit Configuration Items. Typische Aufgaben: - neue Systeme dokumentieren, - Beziehungen pflegen, - Service Maps aktualisieren, - Configuration-Daten nach Changes anpassen, - Incidents anhand der CI-Beziehungen analysieren, - Dokumentationen aktualisieren. Eine gepflegte Configuration-Datenbasis erleichtert nahezu alle Bereiche des IT-Service-Managements. --- **Zusammenfassung** > Service identifizieren > > ↓ > > Configuration Items erfassen > > ↓ > > Beziehungen dokumentieren > > ↓ > > Status aktuell halten > > ↓ > > Änderungen nachführen > > ↓ > > Informationen für Incident, Problem und Change Management bereitstellen --- **Merksätze** > Service Configuration Management verwaltet Informationen – nicht die Hardware selbst. > Ein Configuration Item ist jedes für einen Service relevante Objekt. > Beziehungen zwischen Configuration Items sind oft wichtiger als die einzelnen Komponenten. > Aktuelle Configuration-Daten beschleunigen Incident- und Change-Prozesse. > Gute Service Maps erhöhen die Transparenz komplexer IT-Umgebungen. --- **Verwandte Seiten** - 11.2 Configuration Items, Attribute und Beziehungen - 11.3 CMDB und Configuration Management System (CMS) - 11.4 Pflege, Discovery und Datenqualität - 11.5 Zusammenspiel mit Incident, Problem, Change und Monitoring - Incident Management - Change Enablement - Monitoring and Event Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Beispiele und Vorgehensweisen orientieren sich an der ITIL Practice „Service Configuration Management“. Welche Objekte als Configuration Items geführt werden und welche Informationen gespeichert werden, richtet sich nach Größe, Komplexität und Anforderungen der jeweiligen Organisation. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 11.2 Configuration Items, Attribute und Beziehungen > **Kurz erklärt** > > Ein Configuration Item (CI) besteht nicht nur aus einem Namen. > > Erst durch seine Eigenschaften (Attribute) und seine Beziehungen zu anderen Configuration Items entsteht ein vollständiges Bild eines IT-Services. > > Ziel ist es, jederzeit nachvollziehen zu können, **welche Komponenten existieren, welche Informationen darüber bekannt sind und wie sie miteinander verbunden sind.** --- **Aufbau eines Configuration Items** Jedes Configuration Item besitzt eine Reihe von Informationen, die seinen aktuellen Zustand beschreiben. Typische Bestandteile: - eindeutige CI-ID - Name - Typ - Beschreibung - aktueller Status - Verantwortlicher - Standort - Version - Beziehungen - Dokumentation Je kritischer ein CI ist, desto umfangreicher sind häufig die gespeicherten Informationen. --- **Was sind Attribute?** Attribute sind Eigenschaften eines Configuration Items. Sie beschreiben das CI genauer. Beispiele: - Hersteller - Modell - Seriennummer - Betriebssystem - IP-Adresse - MAC-Adresse - Firmware-Version - Standort - Kostenstelle - Besitzer - Supportgruppe - Installationsdatum Nicht jedes CI benötigt dieselben Attribute. --- **Beispiel: Server als Configuration Item** | Attribut | Beispiel | |----------|-----------| | CI-ID | SRV-00125 | | Name | APP-SRV-01 | | Typ | Virtueller Server | | Betriebssystem | Windows Server 2025 | | IP-Adresse | 10.20.5.15 | | Standort | Rechenzentrum Berlin | | Status | Produktiv | | Verantwortlich | Windows-Team | | Service | ERP-System | Diese Informationen erleichtern die Verwaltung erheblich. --- **Beispiel: Netzwerk-Switch** Ein Switch kann unter anderem folgende Attribute besitzen: - Hersteller - Modell - Seriennummer - Management-IP - Firmware-Version - Rackposition - VLANs - Standort - Verantwortlicher - Wartungsvertrag Dadurch lassen sich Wartung und Fehleranalyse vereinfachen. --- **Pflicht- und optionale Attribute** Nicht alle Informationen sind immer erforderlich. Beispiel: Pflichtattribute: - CI-ID - Name - Typ - Status - Verantwortlicher Optionale Attribute: - Kaufdatum - Garantie - Lieferant - Kosten - interne Bemerkungen Die Organisation legt selbst fest, welche Angaben verpflichtend sind. --- **Eindeutige Identifikation** Jedes Configuration Item sollte eindeutig identifizierbar sein. Geeignet sind beispielsweise: - interne CI-ID, - Asset-Nummer, - Seriennummer, - eindeutiger Hostname. Mehrdeutige Bezeichnungen erschweren den Betrieb. --- **Beziehungen zwischen Configuration Items** Einzelne Configuration Items bilden selten einen vollständigen Service. Erst ihre Beziehungen machen Zusammenhänge sichtbar. Beispiele: - läuft auf - verwendet - verbindet - gehört zu - schützt - repliziert - sichert - kommuniziert mit - ist Bestandteil von Diese Beziehungen ermöglichen eine deutlich bessere Auswirkungsanalyse. --- **Beispiel einer Beziehung** ```text Online-Shop │ ▼ Webserver │ ▼ Datenbank │ ▼ Storage ``` Fällt das Storage-System aus, kann die gesamte Anwendung betroffen sein. --- **Arten von Beziehungen** Typische Beziehungstypen: | Beziehung | Beispiel | |------------|----------| | läuft auf | Anwendung → Server | | verwendet | Anwendung → Datenbank | | verbindet | Switch → Server | | schützt | Firewall → Netzwerk | | repliziert | Datenbank → Datenbank | | enthält | Service → Anwendung | | sichert | Backup → Server | Je genauer Beziehungen dokumentiert sind, desto einfacher lassen sich Auswirkungen erkennen. --- **Service und Configuration Items** Ein Service besteht meist aus mehreren Configuration Items. Beispiel: ```text E-Mail-Service │ ├── Mailserver ├── Datenbank ├── Storage ├── DNS ├── Firewall ├── Active Directory └── Zertifikate ``` Der Service ist mehr als die Summe seiner technischen Komponenten. --- **Auswirkungsanalyse (Impact Analysis)** Beziehungen ermöglichen eine schnelle Bewertung von Auswirkungen. Beispiel: Vor einem geplanten Change soll ein Server neu gestartet werden. Durch die dokumentierten Beziehungen erkennt die IT sofort: Betroffen sind: - ERP-System - Zeiterfassung - Produktionsplanung Dadurch kann das Wartungsfenster besser geplant werden. --- **Root Cause Analysis unterstützen** Auch bei Störungen helfen Beziehungen. Beispiel: Monitoring meldet: - Webserver nicht erreichbar - API nicht erreichbar - Kundenportal nicht erreichbar Die Beziehungen zeigen, dass alle Systeme dieselbe Datenbank verwenden. Die eigentliche Ursache liegt vermutlich dort. --- **Versionen dokumentieren** Viele Configuration Items besitzen unterschiedliche Versionen. Beispiele: - Betriebssystem - Firmware - BIOS - Datenbank - Anwendung - API - Container-Image Versionen erleichtern: - Fehleranalyse, - Sicherheitsupdates, - Patchmanagement, - Audits. --- **Eigentümer und Verantwortliche** Ein Configuration Item sollte einen fachlichen oder technischen Verantwortlichen besitzen. Beispiele: - Windows-Team - Linux-Team - Netzwerk-Team - Datenbankadministration - Cloud-Team - Fachbereich Dadurch ist klar, wer Änderungen oder Entscheidungen verantwortet. --- **Status eines Configuration Items** Typische Statuswerte: - geplant - Test - produktiv - Wartung - außer Betrieb - archiviert - entfernt Der Status sollte jederzeit aktuell sein. --- **Dokumentationen verknüpfen** Zu einem CI können verschiedene Dokumente gehören. Beispiele: - Installationsanleitung - Architekturdiagramm - Runbook - Wartungsvertrag - Lizenznachweis - Sicherheitsrichtlinie - Notfallhandbuch Diese Informationen sollten möglichst direkt mit dem CI verknüpft sein. --- **Automatische Aktualisierung** Viele Attribute können automatisch gepflegt werden. Beispiele: - Betriebssystemversion - IP-Adresse - Speichergröße - CPU - installierte Software - Firmware-Version - Seriennummer Dadurch steigt die Datenqualität. --- **Praxisbeispiel** Ein Administrator plant, die Firmware einer Firewall zu aktualisieren. Durch die Beziehungen erkennt er, dass betroffen sind: - VPN - Internetzugang - E-Mail - Webserver - Cloud-Anbindung Das Wartungsfenster wird entsprechend geplant. --- **Typische Fehler** **Fehler 1** Configuration Items besitzen keine eindeutige ID. --- **Fehler 2** Attribute sind unvollständig. --- **Fehler 3** Beziehungen fehlen. --- **Fehler 4** Verantwortliche sind nicht dokumentiert. --- **Fehler 5** Versionen werden nicht aktualisiert. --- **Fehler 6** Dokumentationen sind nicht verknüpft. --- **Fehler 7** Status stimmt nicht mit der Realität überein. --- **Fehler 8** Zu viele irrelevante Attribute werden gepflegt. --- **Checkliste Configuration Items** - [ ] eindeutige CI-ID vorhanden - [ ] Attribute vollständig - [ ] Verantwortlicher dokumentiert - [ ] Status aktuell - [ ] Version gepflegt - [ ] Beziehungen vorhanden - [ ] Dokumentationen verknüpft - [ ] regelmäßige Aktualisierung geplant --- **Checkliste Beziehungen** - [ ] abhängige Systeme dokumentiert - [ ] Servicezuordnung vorhanden - [ ] Netzwerkbeziehungen gepflegt - [ ] Datenbanken verknüpft - [ ] Cloud-Ressourcen berücksichtigt - [ ] Änderungen nachgeführt - [ ] Auswirkungen nachvollziehbar --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker pflegen Configuration Items häufig direkt im Arbeitsalltag. Typische Aufgaben: - neue Systeme erfassen, - Attribute ergänzen, - Beziehungen dokumentieren, - Versionen aktualisieren, - Verantwortlichkeiten pflegen, - Dokumentationen verknüpfen, - Auswirkungen von Changes bewerten. Je vollständiger die Configuration-Daten sind, desto einfacher werden Incident-, Problem- und Change-Prozesse. --- **Zusammenfassung** > Configuration Item erfassen > > ↓ > > Attribute ergänzen > > ↓ > > Beziehungen dokumentieren > > ↓ > > Verantwortlichkeiten festlegen > > ↓ > > Status aktuell halten > > ↓ > > Informationen für andere ITIL Practices bereitstellen --- **Merksätze** > Ein Configuration Item besteht aus mehr als seinem Namen. > Attribute beschreiben ein CI – Beziehungen verbinden mehrere CIs. > Beziehungen sind entscheidend für Impact- und Ursachenanalysen. > Aktuelle Attribute erhöhen die Qualität der CMDB. > Gute Configuration-Daten erleichtern nahezu alle ITIL Practices. --- **Verwandte Seiten** - 11.1 Ziele und Grundlagen des Service Configuration Management - 11.3 CMDB und Configuration Management System (CMS) - 11.4 Pflege, Discovery und Datenqualität - 11.5 Zusammenspiel mit Incident, Problem, Change und Monitoring - Change Enablement - Incident Management - Monitoring and Event Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Attribute, Beziehungstypen und Beispiele orientieren sich an der ITIL Practice „Service Configuration Management“. Welche Attribute gespeichert und welche Beziehungstypen verwendet werden, hängt von den Anforderungen und dem Datenmodell der jeweiligen Organisation ab. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 11.3 CMDB und Configuration Management System (CMS) > **Kurz erklärt** > > Damit Configuration Items und ihre Beziehungen verwaltet werden können, benötigen Organisationen geeignete Werkzeuge. > > Die bekannteste Datenbank hierfür ist die **Configuration Management Database (CMDB)**. > > ITIL betrachtet jedoch nicht nur eine einzelne Datenbank, sondern ein **Configuration Management System (CMS)**, das Informationen aus verschiedenen Quellen zusammenführt. > > Ziel ist es, jederzeit aktuelle und verlässliche Informationen über Services und deren Bestandteile bereitzustellen. --- **Was ist eine CMDB?** Die Configuration Management Database (CMDB) ist eine Datenbank zur Speicherung von Informationen über Configuration Items und deren Beziehungen. Eine CMDB enthält beispielsweise Informationen über: - Server - Clients - Netzwerkgeräte - Anwendungen - Datenbanken - virtuelle Maschinen - Container - Cloud-Ressourcen - Services - Dokumentationen - Verträge Die CMDB bildet die Grundlage vieler ITSM-Prozesse. --- **Aufgaben einer CMDB** Eine CMDB soll: - Configuration Items speichern, - Beziehungen dokumentieren, - Änderungen nachvollziehbar machen, - Auswirkungen sichtbar machen, - Informationen zentral bereitstellen, - Incident Management unterstützen, - Change Enablement unterstützen, - Problem Management unterstützen. Sie dient als zentrale Informationsquelle für viele ITIL Practices. --- **Was ist ein Configuration Management System (CMS)?** Ein CMS ist mehr als eine einzelne Datenbank. Es verbindet verschiedene Informationsquellen miteinander. Ein CMS kann beispielsweise Informationen aus folgenden Systemen zusammenführen: - CMDB - Monitoring-System - Inventarisierung - Asset Management - Active Directory - Cloud-Plattformen - Virtualisierung - Ticket-System - Dokumentationssystem - Discovery-Werkzeuge Dadurch entsteht ein umfassender Überblick über die IT-Landschaft. --- **CMDB und CMS unterscheiden** Diese Begriffe werden häufig verwechselt. | CMDB | CMS | |------|-----| | einzelne Datenbank | Gesamtsystem | | speichert CI-Daten | verbindet mehrere Datenquellen | | Bestandteil des CMS | umfasst zahlreiche Systeme | | enthält Configuration Items | stellt Informationen bereit | Die CMDB ist also ein Bestandteil des CMS. --- **Aufbau eines CMS** Ein mögliches Beispiel: ```text Monitoring │ Inventarisierung │ Cloud │ Active Directory │ Ticket-System │ Dokumentation │ ▼ Configuration Management System │ ▼ CMDB ``` Das CMS stellt Informationen aus verschiedenen Quellen zusammen. --- **Welche Informationen stammen aus welchen Quellen?** Beispiele: | Informationsquelle | Beispiele | |--------------------|-----------| | Monitoring | Status, Alarme | | Active Directory | Benutzer, Computer | | Virtualisierung | virtuelle Maschinen | | Cloud | Instanzen, Storage | | Inventarisierung | Hardware | | Ticket-System | Incidents, Changes | | Dokumentation | Runbooks, Architektur | Das CMS verbindet diese Informationen logisch miteinander. --- **Warum nicht alles in der CMDB speichern?** Nicht jede Information gehört dauerhaft in die CMDB. Beispiel: CPU-Auslastung verändert sich ständig. Diese Information stammt besser direkt aus dem Monitoring. Die CMDB speichert stattdessen beispielsweise: - Servername, - Betriebssystem, - Verantwortlicher, - Beziehungen, - Servicezuordnung. Aktuelle Zustandsinformationen liefert das Monitoring. --- **Zentrale Datenhaltung** Eine zentrale Datenbasis bietet zahlreiche Vorteile. Beispiele: - einheitliche Informationen, - weniger doppelte Daten, - einfachere Pflege, - bessere Qualität, - schnellere Suche, - bessere Auswirkungsanalyse. Dadurch arbeiten alle ITIL Practices mit denselben Informationen. --- **Beziehungen visualisieren** Viele CMDB-Systeme können Beziehungen grafisch darstellen. Beispiel: ```text CRM-Service │ ├── Webserver ├── Datenbank ├── Storage ├── Firewall └── DNS ``` Solche Darstellungen erleichtern die Fehlersuche erheblich. --- **Serviceorientierte Sicht** ITIL betrachtet bevorzugt Services statt Einzelgeräte. Ein Benutzer interessiert sich beispielsweise dafür, ob der VPN-Service verfügbar ist, nicht dafür, welcher einzelne Server betroffen ist. Das CMS verbindet beide Sichtweisen. --- **Abfragen im CMS** Ein CMS beantwortet beispielsweise Fragen wie: - Welche Server gehören zum ERP-System? - Welche Datenbank nutzt das Kundenportal? - Welche Anwendungen laufen auf diesem Server? - Welche Services sind von diesem Switch abhängig? - Welche Changes betreffen diesen Service? Dadurch lassen sich Entscheidungen schneller treffen. --- **Integration mit Monitoring** Viele CMS-Systeme übernehmen Statusinformationen aus dem Monitoring. Beispiele: - Server erreichbar, - CPU-Auslastung, - Speicherverbrauch, - Zertifikatsstatus, - Netzwerkstatus, - Verfügbarkeit. Dadurch stehen aktuelle Informationen direkt zur Verfügung. --- **Integration mit Change Enablement** Nach einem erfolgreichen Change sollte die CMDB aktualisiert werden. Beispiele: - neue Server, - neue Version, - neue Beziehungen, - geänderte IP-Adresse, - neue Firewallregel, - neuer Service. Nur so bleibt die Datenqualität erhalten. --- **Integration mit Incident Management** Bei einem Incident können Administratoren sofort erkennen: - betroffene Services, - abhängige Systeme, - Verantwortliche, - Dokumentationen, - bekannte Beziehungen. Dadurch verkürzt sich die Analyse erheblich. --- **Integration mit Problem Management** Problem Management nutzt historische Informationen aus dem CMS. Beispiele: - häufig betroffene Systeme, - wiederkehrende Komponenten, - Versionen, - Beziehungen, - frühere Änderungen. Diese Informationen unterstützen die Ursachenanalyse. --- **Discovery-Werkzeuge** Viele Informationen müssen nicht manuell gepflegt werden. Discovery-Werkzeuge erkennen automatisch: - neue Server, - Betriebssysteme, - installierte Software, - Netzwerktopologie, - virtuelle Maschinen, - Cloud-Ressourcen. Dadurch sinkt der Pflegeaufwand. --- **Manuelle Pflege bleibt notwendig** Nicht alle Informationen können automatisch erkannt werden. Beispiele: - Servicezuordnung, - Verantwortlicher, - Geschäftsprozess, - Kritikalität, - Dokumentationen, - Verträge. Diese Angaben müssen häufig manuell gepflegt werden. --- **Datenqualität** Eine CMDB ist nur dann hilfreich, wenn die gespeicherten Informationen korrekt sind. Wichtige Kriterien: - vollständig, - aktuell, - eindeutig, - nachvollziehbar, - konsistent. Schlechte Daten führen zu falschen Entscheidungen. --- **Praxisbeispiel** Ein Administrator plant einen Neustart eines Datenbankservers. Über die CMDB erkennt er sofort: Der Server gehört zu: - ERP, - Zeiterfassung, - CRM, - Reporting. Dadurch wird der Change besser geplant und betroffene Fachbereiche können rechtzeitig informiert werden. --- **Typische Fehler** **Fehler 1** CMDB und CMS werden gleichgesetzt. --- **Fehler 2** Configuration Items werden nicht aktualisiert. --- **Fehler 3** Discovery wird nicht genutzt. --- **Fehler 4** Monitoring ist nicht integriert. --- **Fehler 5** Beziehungen fehlen. --- **Fehler 6** Mehrere Datenquellen liefern widersprüchliche Informationen. --- **Fehler 7** Zu viele Informationen werden manuell gepflegt. --- **Fehler 8** Niemand ist für die Datenqualität verantwortlich. --- **Checkliste CMDB** - [ ] Configuration Items vollständig - [ ] Beziehungen dokumentiert - [ ] Status aktuell - [ ] Verantwortliche gepflegt - [ ] Versionen aktuell - [ ] Services zugeordnet - [ ] Änderungen nachgeführt - [ ] regelmäßige Qualitätssicherung --- **Checkliste CMS** - [ ] CMDB integriert - [ ] Monitoring angebunden - [ ] Discovery aktiv - [ ] Active Directory eingebunden - [ ] Cloud-Systeme integriert - [ ] Dokumentation verknüpft - [ ] Ticket-System verbunden - [ ] Datenquellen abgestimmt --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten regelmäßig mit CMDBs und CMS-Systemen. Typische Aufgaben: - Configuration Items pflegen, - Beziehungen ergänzen, - Discovery prüfen, - Datenqualität verbessern, - Monitoring anbinden, - Services dokumentieren, - Changes nachführen, - Auswirkungsanalysen durchführen. Ein gepflegtes CMS erleichtert nahezu alle administrativen Tätigkeiten im IT-Betrieb. --- **Zusammenfassung** > Configuration Items erfassen > > ↓ > > In der CMDB speichern > > ↓ > > Weitere Datenquellen anbinden > > ↓ > > Informationen im CMS zusammenführen > > ↓ > > Beziehungen darstellen > > ↓ > > Informationen für alle ITIL Practices bereitstellen --- **Merksätze** > Die CMDB ist ein Bestandteil des CMS. > Ein CMS verbindet Informationen aus mehreren Quellen. > Monitoring liefert Zustandsdaten – die CMDB liefert Strukturinformationen. > Discovery verbessert die Datenqualität. > Eine CMDB ist nur so gut wie die Qualität ihrer Daten. --- **Verwandte Seiten** - 11.1 Ziele und Grundlagen des Service Configuration Management - 11.2 Configuration Items, Attribute und Beziehungen - 11.4 Pflege, Discovery und Datenqualität - 11.5 Zusammenspiel mit Incident, Problem, Change und Monitoring - Monitoring and Event Management - Incident Management - Change Enablement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** ITIL unterscheidet klar zwischen einer **Configuration Management Database (CMDB)** als Datenbank und einem **Configuration Management System (CMS)** als übergeordnetem Informationssystem. Welche Datenquellen integriert werden und wie die technische Umsetzung erfolgt, hängt von den eingesetzten ITSM-, Discovery- und Monitoring-Lösungen der jeweiligen Organisation ab. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 11.4 Pflege, Discovery und Datenqualität > **Kurz erklärt** > > Eine Configuration Management Database (CMDB) ist nur dann hilfreich, wenn ihre Informationen aktuell und korrekt sind. > > Deshalb gehören die kontinuierliche Pflege, automatische Discovery-Verfahren und die regelmäßige Überprüfung der Datenqualität zu den wichtigsten Aufgaben des Service Configuration Management. > > Ziel ist es, jederzeit eine zuverlässige Informationsbasis für Incident Management, Problem Management, Change Enablement und andere ITIL Practices bereitzustellen. --- **Warum Datenqualität entscheidend ist** Eine unvollständige oder veraltete CMDB kann mehr Schaden anrichten als gar keine CMDB. Falsche Informationen führen beispielsweise zu: - fehlerhaften Changes, - unnötigen Incidents, - falschen Prioritäten, - längeren Ausfallzeiten, - ungenauen Auswirkungsanalysen, - erhöhtem Arbeitsaufwand. Eine hohe Datenqualität ist daher wichtiger als eine möglichst große Anzahl gespeicherter Configuration Items. --- **Was bedeutet Datenqualität?** Datenqualität beschreibt, wie zuverlässig und nutzbar Informationen sind. Wichtige Qualitätsmerkmale: - vollständig, - aktuell, - korrekt, - eindeutig, - konsistent, - nachvollziehbar, - relevant. Nur wenn diese Eigenschaften erfüllt sind, können andere ITIL Practices auf die Daten vertrauen. --- **Vollständigkeit** Alle erforderlichen Informationen sollten vorhanden sein. Beispiele: - Verantwortlicher, - Status, - Beziehungen, - Version, - Servicezuordnung, - Standort. Fehlende Informationen erschweren spätere Entscheidungen. --- **Aktualität** Configuration-Daten müssen Änderungen zeitnah widerspiegeln. Beispiele: - neuer Server, - neue IP-Adresse, - Firmware-Update, - neuer Standort, - neue Beziehungen, - Außerbetriebnahme. Veraltete Informationen führen schnell zu Fehlentscheidungen. --- **Korrektheit** Die gespeicherten Informationen müssen der Realität entsprechen. Beispiel: Die CMDB enthält: > Windows Server 2022 Tatsächlich läuft: > Windows Server 2025 Solche Abweichungen können Fehleranalysen und Sicherheitsmaßnahmen erheblich erschweren. --- **Konsistenz** Informationen dürfen sich nicht widersprechen. Beispiel: Die CMDB nennt als Verantwortlichen das Linux-Team, während die Dokumentation das Windows-Team aufführt. Solche Widersprüche sollten vermieden werden. --- **Was ist Discovery?** Discovery bezeichnet die automatische Erkennung von Configuration Items und ihren Eigenschaften. Discovery-Werkzeuge können beispielsweise erkennen: - Server, - Betriebssysteme, - virtuelle Maschinen, - Container, - Netzwerkgeräte, - installierte Software, - IP-Adressen, - Dienste, - Cloud-Ressourcen. Dadurch sinkt der manuelle Pflegeaufwand erheblich. --- **Wie funktioniert Discovery?** Je nach Werkzeug kommen unterschiedliche Verfahren zum Einsatz. Beispiele: - Netzwerk-Scans, - SNMP, - WMI, - SSH, - WinRM, - Hypervisor-Schnittstellen, - Cloud-APIs, - Agenten, - Kubernetes-APIs. Welche Methode verwendet wird, hängt von der jeweiligen Infrastruktur ab. --- **Agentenbasierte Discovery** Ein Agent wird direkt auf dem System installiert. Vorteile: - viele Detailinformationen, - regelmäßige Aktualisierung, - hohe Genauigkeit. Nachteile: - zusätzlicher Verwaltungsaufwand, - Software muss installiert werden. --- **Agentenlose Discovery** Hier erfolgt die Erkennung über Netzwerkprotokolle oder Programmierschnittstellen. Vorteile: - keine zusätzliche Software auf den Zielsystemen, - einfache Einführung. Nachteile: - teilweise geringerer Detailgrad, - Zugriff auf geeignete Schnittstellen erforderlich. --- **Automatisch erkannte Informationen** Discovery kann beispielsweise erfassen: - Hostname, - IP-Adresse, - Betriebssystem, - CPU, - Arbeitsspeicher, - Festplatten, - installierte Software, - Netzwerkadapter, - Dienste, - offene Ports. Nicht alle Informationen lassen sich automatisch erkennen. --- **Was Discovery nicht erkennt** Geschäftsbezogene Informationen müssen häufig manuell ergänzt werden. Beispiele: - Service Owner, - Kritikalität, - Geschäftsprozess, - SLA, - Kostenstelle, - Ansprechpartner, - interne Dokumentationen. Diese Informationen entstehen meist außerhalb der technischen Infrastruktur. --- **Regelmäßige Discovery** Discovery sollte regelmäßig ausgeführt werden. Beispiele: - täglich, - stündlich, - nach Changes, - nach Deployments. Dadurch bleiben Änderungen möglichst aktuell. --- **Abgleich mit der CMDB** Nach einer Discovery werden erkannte Änderungen mit der CMDB verglichen. Mögliche Ergebnisse: - neues CI gefunden, - bestehendes CI geändert, - CI entfernt, - Version geändert, - neue Beziehung erkannt. Nicht jede Änderung wird automatisch übernommen. Je nach Organisation erfolgt zunächst eine Prüfung. --- **Manuelle Pflege** Auch bei umfangreicher Discovery bleibt manuelle Pflege notwendig. Typische Aufgaben: - Servicezuordnung, - Verantwortlichkeiten, - Dokumentationen, - Beziehungen, - Kritikalität, - Genehmigungen. Automatische Verfahren ersetzen diese Arbeiten nicht vollständig. --- **Qualitätssicherung** Configuration-Daten sollten regelmäßig überprüft werden. Mögliche Maßnahmen: - Stichproben, - Audits, - automatische Plausibilitätsprüfungen, - Vergleich mit Inventarsystemen, - Vergleich mit Monitoring, - Review nach Changes. Dadurch lassen sich Fehler früh erkennen. --- **Configuration Audits** Ein Configuration Audit überprüft, ob die dokumentierten Informationen der tatsächlichen Umgebung entsprechen. Beispielsweise wird geprüft: - Existiert das CI noch? - Stimmen Versionen? - Sind Beziehungen aktuell? - Wurde ein Change korrekt dokumentiert? - Stimmen Verantwortlichkeiten? Audits erhöhen die Zuverlässigkeit der CMDB. --- **Data Owner** Für wichtige Configuration Items sollte klar geregelt sein, wer für die Daten verantwortlich ist. Typische Verantwortliche: - Windows-Team, - Linux-Team, - Netzwerk-Team, - Datenbankadministration, - Cloud-Team, - Service Owner. Dadurch bleibt die Pflege dauerhaft sichergestellt. --- **Kennzahlen zur Datenqualität** Auch Datenqualität kann gemessen werden. Beispiele: - Anteil vollständiger CIs, - Anzahl veralteter Einträge, - Discovery-Erfolgsquote, - Anzahl widersprüchlicher Datensätze, - Aktualisierungsdauer nach einem Change, - Audit-Ergebnisse. Diese Kennzahlen unterstützen Continual Improvement. --- **Praxisbeispiel** Ein Discovery-Werkzeug erkennt, dass auf einem Server eine neue Version des Betriebssystems installiert wurde. Die Änderung wird erkannt, aber zunächst nicht automatisch übernommen. Nach erfolgreicher Prüfung aktualisiert der Administrator die CMDB. Dadurch bleiben Dokumentation und tatsächlicher Zustand identisch. --- **Typische Fehler** **Fehler 1** Configuration Items werden nie überprüft. --- **Fehler 2** Discovery wird nicht genutzt. --- **Fehler 3** Discovery überschreibt ungeprüft manuelle Angaben. --- **Fehler 4** Verantwortlichkeiten fehlen. --- **Fehler 5** Veraltete Beziehungen bleiben bestehen. --- **Fehler 6** Audits finden nicht statt. --- **Fehler 7** Zu viele irrelevante Informationen werden gespeichert. --- **Fehler 8** Monitoring und CMDB liefern widersprüchliche Daten. --- **Fehler 9** Changes werden nicht in die CMDB übernommen. --- **Fehler 10** Niemand misst die Datenqualität. --- **Checkliste Datenqualität** - [ ] Configuration Items vollständig - [ ] Informationen aktuell - [ ] Beziehungen korrekt - [ ] Verantwortliche gepflegt - [ ] Versionen aktuell - [ ] Dokumentationen verknüpft - [ ] Audits durchgeführt - [ ] Daten regelmäßig überprüft --- **Checkliste Discovery** - [ ] Discovery aktiv - [ ] geeignete Verfahren ausgewählt - [ ] regelmäßige Ausführung geplant - [ ] Änderungen geprüft - [ ] CMDB aktualisiert - [ ] Monitoring abgestimmt - [ ] Fehler protokolliert - [ ] Ergebnisse dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker sorgen häufig dafür, dass Configuration-Daten korrekt und aktuell bleiben. Typische Aufgaben: - Discovery konfigurieren, - neue Systeme erfassen, - Beziehungen pflegen, - Audits durchführen, - Änderungen dokumentieren, - Datenqualität verbessern, - Monitoring mit der CMDB abstimmen. Eine zuverlässige CMDB entsteht nicht einmalig, sondern durch kontinuierliche Pflege. --- **Zusammenfassung** > Configuration Items erfassen > > ↓ > > Discovery durchführen > > ↓ > > Änderungen erkennen > > ↓ > > Daten prüfen > > ↓ > > CMDB aktualisieren > > ↓ > > Datenqualität überwachen > > ↓ > > Regelmäßig auditieren --- **Merksätze** > Eine CMDB ist nur so gut wie ihre Daten. > Discovery reduziert manuellen Pflegeaufwand, ersetzt ihn aber nicht vollständig. > Geschäftsbezogene Informationen müssen häufig manuell ergänzt werden. > Regelmäßige Audits verbessern die Datenqualität. > Aktuelle Configuration-Daten unterstützen nahezu alle ITIL Practices. --- **Verwandte Seiten** - 11.1 Ziele und Grundlagen des Service Configuration Management - 11.2 Configuration Items, Attribute und Beziehungen - 11.3 CMDB und Configuration Management System (CMS) - 11.5 Zusammenspiel mit Incident, Problem, Change und Monitoring - Monitoring and Event Management - Change Enablement - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - ITIL Foundation – Version 5 **Einordnung** Die beschriebenen Discovery-Verfahren, Qualitätskriterien und Auditmaßnahmen orientieren sich an den Empfehlungen der ITIL Practice „Service Configuration Management“. Welche Discovery-Werkzeuge, Schnittstellen und Prüfmechanismen eingesetzt werden, hängt von der jeweiligen IT-Landschaft und den organisatorischen Anforderungen ab. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 11.5 Zusammenspiel mit Incident, Problem, Change und Monitoring > **Kurz erklärt** > > Service Configuration Management arbeitet eng mit vielen anderen ITIL Practices zusammen. > > Die gespeicherten Informationen über Configuration Items (CIs), Services und deren Beziehungen bilden die Grundlage für fundierte Entscheidungen im IT-Betrieb. > > Erst durch das Zusammenspiel mit Incident Management, Problem Management, Change Enablement und Monitoring and Event Management entfaltet Service Configuration Management seinen vollen Nutzen. --- **Warum das Zusammenspiel wichtig ist** Eine CMDB allein behebt keine Störungen und führt keine Änderungen durch. Sie beantwortet jedoch entscheidende Fragen wie: - Welche Systeme gehören zu einem Service? - Welche Komponenten sind betroffen? - Wer ist verantwortlich? - Welche Auswirkungen hat ein Ausfall? - Welche Änderungen betreffen weitere Systeme? Diese Informationen werden anschließend von anderen ITIL Practices genutzt. --- **Zusammenspiel der Practices** ```text Configuration Items │ ▼ CMDB / CMS │ ▼ Incident Problem Change Monitoring │ ▼ Bessere Entscheidungen ``` Die CMDB dient als gemeinsame Informationsbasis. --- **Service Configuration Management und Incident Management** Bei einem Incident muss häufig schnell geklärt werden: - Welcher Service ist betroffen? - Welche Systeme gehören dazu? - Welche Abhängigkeiten bestehen? - Wer ist verantwortlich? Diese Informationen stammen aus der CMDB. --- **Beispiel** Das Monitoring meldet: > Webserver nicht erreichbar. Die CMDB zeigt: - gehört zum Kundenportal, - verwendet Datenbank DB-01, - läuft auf VM-Cluster A, - Service Owner: E-Commerce. Dadurch kann der Incident schneller bewertet werden. --- **Impact Analysis** Die Auswirkungen einer Störung lassen sich mithilfe der Beziehungen zwischen Configuration Items bestimmen. Beispiel: ```text Storage │ ▼ Datenbank │ ▼ ERP-System │ ▼ Produktion ``` Fällt das Storage-System aus, sind mehrere Services betroffen. Dadurch steigt die Priorität des Incidents. --- **Root Cause Analysis** Auch Problem Management nutzt die Beziehungen der CMDB. Beispiel: Mehrere Incidents betreffen: - Webserver, - API, - Mobile App. Die CMDB zeigt, dass alle dieselbe Datenbank verwenden. Dadurch lässt sich die eigentliche Ursache schneller identifizieren. --- **Service Configuration Management und Problem Management** Problem Management untersucht wiederkehrende Ursachen. Configuration-Daten helfen beispielsweise dabei, - betroffene Configuration Items zu identifizieren, - gemeinsame Abhängigkeiten zu erkennen, - Änderungen nachzuvollziehen, - ähnliche Systeme zu vergleichen. Je vollständiger die CMDB, desto effizienter wird die Ursachenanalyse. --- **Known Errors** Wird eine Ursache dauerhaft dokumentiert, kann sie mit betroffenen Configuration Items verknüpft werden. Beispiel: ```text Known Error │ ▼ Firmware-Version 4.2.1 │ ▼ Switch-Serie XY ``` Dadurch lassen sich ähnliche Vorfälle schneller erkennen. --- **Service Configuration Management und Change Enablement** Changes verändern häufig Configuration Items. Beispiele: - neuer Server, - neue IP-Adresse, - Firmware-Update, - zusätzliche Firewall, - neue Datenbank, - neue Cloud-Ressource. Nach jedem erfolgreichen Change sollte die CMDB aktualisiert werden. --- **Vor einem Change** Vor einer Änderung beantwortet die CMDB beispielsweise: - Welche Services sind betroffen? - Welche Systeme hängen davon ab? - Gibt es Redundanzen? - Wer muss informiert werden? - Welche Wartungsfenster sind geeignet? Dadurch sinkt das Risiko von Fehlentscheidungen. --- **Nach einem Change** Nach erfolgreicher Umsetzung werden beispielsweise aktualisiert: - Versionen, - Beziehungen, - Status, - Verantwortliche, - Dokumentationen, - Service Maps. Dadurch bleibt die CMDB aktuell. --- **Service Configuration Management und Monitoring** Monitoring überwacht Configuration Items. Die CMDB beschreibt sie. Beispiel: Monitoring erkennt: Server ausgefallen. Die CMDB ergänzt: - Servicezuordnung, - Kritikalität, - Verantwortlicher, - Beziehungen, - Dokumentation. Erst beide Informationen zusammen ermöglichen eine vollständige Bewertung. --- **Service Maps** Monitoring und CMDB können gemeinsam Service Maps erzeugen. Beispiel: ```text CRM-Service │ ├── Webserver ├── API ├── Datenbank ├── Storage └── Firewall ``` Fällt eine Komponente aus, werden betroffene Services sofort sichtbar. --- **Monitoring nach Changes** Nach einem Change überprüft Monitoring beispielsweise: - Erreichbarkeit, - Antwortzeit, - CPU, - Speicher, - Fehler, - Alarme. Configuration Management dokumentiert, welche Version jetzt produktiv eingesetzt wird. --- **Monitoring unterstützt Discovery** Discovery-Werkzeuge erkennen: - neue Server, - virtuelle Maschinen, - Container, - Cloud-Ressourcen, - Betriebssystemversionen. Die Ergebnisse können anschließend in die CMDB übernommen werden. --- **Service Configuration Management und Service Level Management** SLA-Ziele beziehen sich häufig auf Services. Die CMDB beschreibt, welche Configuration Items zu einem Service gehören. Dadurch können Verfügbarkeiten und Ausfälle korrekt bewertet werden. --- **Service Configuration Management und Availability Management** Availability Management benötigt Informationen darüber, welche Komponenten für einen Service notwendig sind. Beispiele: - Server, - Load Balancer, - Datenbank, - DNS, - Firewall, - Storage. Die CMDB liefert diese Informationen. --- **Service Configuration Management und Capacity Management** Kapazitätsplanung nutzt unter anderem: - Anzahl Server, - Speicher, - CPU, - Datenbanken, - Cluster, - Cloud-Ressourcen. Die CMDB zeigt, welche Ressourcen vorhanden sind und welchen Services sie zugeordnet sind. --- **Service Configuration Management und Information Security Management** Viele sicherheitsrelevante Informationen werden mit Configuration Items verknüpft. Beispiele: - Betriebssystemversion, - Patchstand, - Firewall, - Zertifikate, - Verantwortliche, - Sicherheitsklassifizierung. Dadurch lassen sich Risiken gezielter bewerten. --- **Service Configuration Management und Continual Improvement** Eine gepflegte CMDB unterstützt Verbesserungen. Beispiele: - fehlende Beziehungen erkennen, - Discovery erweitern, - Datenqualität verbessern, - Service Maps ergänzen, - Verantwortlichkeiten aktualisieren. Dadurch steigt der Nutzen der gesamten Configuration-Datenbasis. --- **Praxisbeispiel** Ein Switch wird ersetzt. Vor dem Change zeigt die CMDB: Betroffen sind: - ERP, - VoIP, - WLAN, - Druckserver, - VPN. Nach erfolgreicher Umsetzung werden: - Seriennummer, - Firmware, - Beziehungen, - Dokumentationen, - Status aktualisiert. Monitoring bestätigt anschließend, dass alle Services wieder ordnungsgemäß funktionieren. --- **Typische Fehler** **Fehler 1** Changes werden nicht in der CMDB dokumentiert. --- **Fehler 2** Incident Management nutzt die CMDB nicht. --- **Fehler 3** Monitoring kennt keine Servicebeziehungen. --- **Fehler 4** Discovery-Ergebnisse werden ignoriert. --- **Fehler 5** Service Maps fehlen. --- **Fehler 6** Configuration Items besitzen keine Verantwortlichen. --- **Fehler 7** Problem Management nutzt historische Configuration-Daten nicht. --- **Fehler 8** Mehrere Systeme besitzen widersprüchliche Informationen. --- **Fehler 9** SLA-Bewertungen berücksichtigen keine Serviceabhängigkeiten. --- **Fehler 10** Configuration-Daten werden nur nach größeren Projekten aktualisiert. --- **Checkliste Zusammenspiel** - [ ] Configuration Items aktuell - [ ] Beziehungen gepflegt - [ ] Incident Management nutzt die CMDB - [ ] Changes dokumentiert - [ ] Monitoring integriert - [ ] Discovery aktiv - [ ] Service Maps aktuell - [ ] Verantwortlichkeiten gepflegt - [ ] Dokumentationen verknüpft - [ ] Datenqualität regelmäßig überprüft --- **Checkliste Service Configuration Management** - [ ] CMDB aktuell - [ ] CMS integriert - [ ] Discovery eingerichtet - [ ] Monitoring angebunden - [ ] Incident-Verknüpfungen vorhanden - [ ] Change-Prozess berücksichtigt - [ ] Problem Records verknüpft - [ ] Servicezuordnungen vollständig --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker pflegen und nutzen Configuration-Daten nahezu täglich. Typische Aufgaben: - neue Systeme dokumentieren, - Configuration Items aktualisieren, - Beziehungen ergänzen, - Monitoring integrieren, - Discovery prüfen, - Service Maps pflegen, - Auswirkungen von Changes bewerten, - Incidents schneller analysieren. Eine gepflegte CMDB reduziert Suchaufwand, verbessert Entscheidungen und unterstützt nahezu alle ITIL Practices. --- **Zusammenfassung** > Configuration Items verwalten > > ↓ > > Beziehungen dokumentieren > > ↓ > > Informationen in der CMDB bereitstellen > > ↓ > > Incident, Problem und Change unterstützen > > ↓ > > Monitoring integrieren > > ↓ > > Datenqualität verbessern > > ↓ > > Services sicher betreiben --- **Merksätze** > Service Configuration Management liefert Informationen – andere Practices nutzen sie. > Eine aktuelle CMDB beschleunigt Incident-, Problem- und Change-Prozesse. > Monitoring beschreibt den Zustand – die CMDB beschreibt die Struktur. > Service Maps erleichtern Impact- und Ursachenanalysen. > Gute Configuration-Daten sind eine wichtige Grundlage für professionelles IT-Service-Management. --- **Verwandte Seiten** - 11.1 Ziele und Grundlagen des Service Configuration Management - 11.2 Configuration Items, Attribute und Beziehungen - 11.3 CMDB und Configuration Management System (CMS) - 11.4 Pflege, Discovery und Datenqualität - Incident Management - Problem Management - Change Enablement - Monitoring and Event Management - Availability Management - Capacity and Performance Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Service Configuration Management stellt strukturierte Informationen über Services und Configuration Items bereit, die von Incident Management, Problem Management, Change Enablement, Monitoring und weiteren Practices genutzt werden. Die konkrete technische Umsetzung erfolgt organisationsabhängig mithilfe von CMDB-, CMS-, Monitoring- und ITSM-Systemen. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 12. Service Level Management # 12.1 Ziele und Grundlagen des Service Level Management > **Kurz erklärt** > > Service Level Management stellt sicher, dass IT-Services mit den vereinbarten Anforderungen der Kunden und des Unternehmens übereinstimmen. > > Dazu werden Serviceziele definiert, überwacht und regelmäßig überprüft. > > Ziel ist es, **realistische Erwartungen zu vereinbaren, die Servicequalität messbar zu machen und die kontinuierliche Verbesserung der Services zu unterstützen.** --- **Was ist Service Level Management?** Service Level Management ist eine ITIL Practice zur Vereinbarung, Überwachung und Verbesserung der Qualität von IT-Services. Dabei geht es nicht nur darum, möglichst kurze Reaktionszeiten einzuhalten. Viel wichtiger ist, dass Serviceanbieter und Kunden ein gemeinsames Verständnis darüber entwickeln, welche Leistungen erbracht werden und welche Erwartungen realistisch sind. --- **Warum Service Level Management wichtig ist** Ohne klare Vereinbarungen entstehen häufig Missverständnisse. Typische Fragen: - Wie schnell muss reagiert werden? - Wann muss ein Incident behoben sein? - Welche Verfügbarkeit wird erwartet? - Welche Servicezeiten gelten? - Welche Leistungen gehören überhaupt zum Service? Service Level Management beantwortet diese Fragen. --- **Ziele des Service Level Management** Die wichtigsten Ziele sind: - gemeinsame Erwartungen schaffen, - Servicequalität messbar machen, - realistische Serviceziele vereinbaren, - Serviceleistung überwachen, - Kundenzufriedenheit erhöhen, - kontinuierliche Verbesserungen unterstützen, - Transparenz schaffen, - Prioritäten festlegen, - Zusammenarbeit zwischen IT und Fachbereichen verbessern. --- **Servicequalität** Servicequalität beschreibt, wie gut ein Service die Anforderungen der Benutzer erfüllt. Dabei spielen verschiedene Faktoren eine Rolle. Beispiele: - Verfügbarkeit, - Zuverlässigkeit, - Reaktionszeit, - Wiederherstellungszeit, - Erreichbarkeit, - Benutzerfreundlichkeit, - Kommunikation. Servicequalität umfasst also deutlich mehr als reine Technik. --- **Was ist ein Service Level?** Ein Service Level beschreibt das vereinbarte Qualitätsniveau eines Services. Beispiele: - 99,9 % Verfügbarkeit, - Reaktionszeit innerhalb von 30 Minuten, - Wiederherstellung innerhalb von vier Stunden, - Support montags bis freitags von 08:00 bis 18:00 Uhr. Service Levels werden gemeinsam vereinbart, nicht einseitig festgelegt. --- **Service Level Agreement (SLA)** Ein Service Level Agreement (SLA) dokumentiert die vereinbarten Serviceziele. Ein SLA beschreibt beispielsweise: - bereitgestellte Services, - Servicezeiten, - Verfügbarkeiten, - Reaktionszeiten, - Wiederherstellungszeiten, - Verantwortlichkeiten, - Messverfahren, - Berichtswesen. Ein SLA ist keine technische Anleitung, sondern eine Vereinbarung zwischen Serviceanbieter und Kunde. --- **Bestandteile eines SLA** Ein typisches SLA enthält: - Beschreibung des Services, - Leistungsumfang, - Servicezeiten, - vereinbarte Kennzahlen, - Rollen und Verantwortlichkeiten, - Eskalationsverfahren, - Ausschlüsse, - Berichtswesen, - Review-Termine. Je nach Organisation können weitere Inhalte ergänzt werden. --- **Servicezeiten** Nicht jeder Service muss rund um die Uhr verfügbar sein. Beispiele: | Service | Servicezeit | |----------|-------------| | Büroarbeitsplätze | Mo–Fr 08:00–18:00 Uhr | | Produktionssystem | 24 × 7 | | Intranet | Mo–So 06:00–22:00 Uhr | | Testsystem | nach Bedarf | Die Servicezeit beeinflusst die Bewertung der Servicequalität. --- **Verfügbarkeit** Verfügbarkeit beschreibt, wie lange ein Service innerhalb der vereinbarten Servicezeit nutzbar ist. Beispiele: - 99 % - 99,5 % - 99,9 % - 99,99 % Eine höhere Verfügbarkeit erfordert in der Regel mehr technische und organisatorische Maßnahmen. --- **Erwartungen abstimmen** Ein häufiges Ziel des Service Level Managements besteht darin, realistische Erwartungen zu schaffen. Beispiel: Ein Fachbereich wünscht: > 100 % Verfügbarkeit. Die IT erläutert, dass Wartungsfenster, Hardwarefehler oder externe Einflüsse dies praktisch unmöglich machen. Gemeinsam wird ein realistisches Serviceziel vereinbart. --- **Messbarkeit** Serviceziele sollten eindeutig messbar sein. Geeignete Formulierungen: - Verfügbarkeit mindestens 99,9 % - Reaktionszeit maximal 30 Minuten - Wiederherstellung innerhalb von vier Stunden Ungeeignet sind Formulierungen wie: - möglichst schnell, - hohe Verfügbarkeit, - zeitnahe Bearbeitung. --- **Kundenzufriedenheit** Ein Service kann alle technischen Kennzahlen erfüllen und trotzdem als unzureichend wahrgenommen werden. Deshalb berücksichtigt Service Level Management auch: - Kommunikation, - Transparenz, - Erreichbarkeit, - Benutzerfeedback, - Zufriedenheitsbefragungen. --- **Regelmäßige Reviews** Service Levels werden regelmäßig überprüft. Dabei wird unter anderem betrachtet: - wurden Ziele erreicht? - gab es häufige Incidents? - passen die Serviceziele noch? - haben sich Geschäftsanforderungen geändert? - sind Verbesserungen notwendig? Service Level Management ist deshalb ein kontinuierlicher Prozess. --- **Praxisbeispiel** Ein Unternehmen betreibt einen VPN-Service. Vereinbart wurde: - Servicezeit: 24 × 7 - Verfügbarkeit: 99,9 % - Reaktionszeit: 30 Minuten - Wiederherstellungszeit: vier Stunden Monitoring misst die Verfügbarkeit, Incident Management liefert die Wiederherstellungszeiten und Service Level Management bewertet, ob die vereinbarten Ziele eingehalten wurden. --- **Typische Fehler** **Fehler 1** Serviceziele sind nicht messbar. --- **Fehler 2** Unrealistische Erwartungen. --- **Fehler 3** Kennzahlen werden nicht überwacht. --- **Fehler 4** SLA wird nie überprüft. --- **Fehler 5** Benutzeranforderungen werden nicht berücksichtigt. --- **Fehler 6** Nur technische Kennzahlen werden betrachtet. --- **Fehler 7** Verantwortlichkeiten sind unklar. --- **Fehler 8** Es gibt keine regelmäßigen Service Reviews. --- **Checkliste Service Level Management** - [ ] Service beschrieben - [ ] Serviceziele definiert - [ ] SLA dokumentiert - [ ] Kennzahlen messbar - [ ] Verantwortlichkeiten festgelegt - [ ] Monitoring eingerichtet - [ ] Reviews geplant - [ ] Verbesserungen dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Auch wenn Service Level Agreements häufig vom Service Management erstellt werden, arbeiten Fachinformatiker täglich an deren Einhaltung. Typische Aufgaben: - Verfügbarkeiten sicherstellen, - Incidents bearbeiten, - Monitoring überwachen, - Servicequalität verbessern, - Kennzahlen analysieren, - technische Verbesserungen umsetzen. Damit leisten sie einen wichtigen Beitrag zur Erfüllung der vereinbarten Serviceziele. --- **Zusammenfassung** > Service definieren > > ↓ > > Erwartungen abstimmen > > ↓ > > Serviceziele vereinbaren > > ↓ > > SLA dokumentieren > > ↓ > > Serviceleistung messen > > ↓ > > Ergebnisse bewerten > > ↓ > > Services kontinuierlich verbessern --- **Merksätze** > Service Level Management schafft gemeinsame Erwartungen. > Ein SLA beschreibt vereinbarte Leistungen – keine technischen Lösungen. > Servicequalität muss messbar sein. > Monitoring liefert die Daten, Service Level Management bewertet sie. > Regelmäßige Reviews sind Grundlage für kontinuierliche Verbesserungen. --- **Verwandte Seiten** - 12.2 Service Level Agreements (SLA), OLA und Underpinning Agreements - 12.3 Kennzahlen, Berichte und Service Reviews - 12.4 Kundenzufriedenheit und Continual Improvement - 12.5 Zusammenspiel mit Incident, Problem, Change und Monitoring - Incident Management - Monitoring and Event Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Ziele und Vorgehensweisen orientieren sich an der ITIL Practice „Service Level Management“. Die konkrete Ausgestaltung von Service Levels und Service Level Agreements hängt von den Anforderungen der jeweiligen Organisation und ihrer Kunden ab. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 12.2 Service Level Agreements (SLA), Operational Level Agreements (OLA) und Underpinning Agreements (UC) > **Kurz erklärt** > > Damit ein IT-Service zuverlässig erbracht werden kann, reichen Service Level Agreements (SLAs) allein nicht aus. > > Zusätzlich werden interne Vereinbarungen zwischen IT-Teams sowie Verträge mit externen Dienstleistern benötigt. > > ITIL unterscheidet hierfür drei Ebenen: > > - **Service Level Agreement (SLA)** > - **Operational Level Agreement (OLA)** > - **Underpinning Agreement (UC)** (früher häufig "Underpinning Contract") > > Gemeinsam sorgen sie dafür, dass vereinbarte Serviceziele tatsächlich eingehalten werden können. --- **Warum mehrere Vereinbarungen notwendig sind** Ein Kunde vereinbart beispielsweise: > Der VPN-Service soll innerhalb von vier Stunden wiederhergestellt werden. Damit dieses Ziel erreicht werden kann, müssen häufig mehrere interne und externe Stellen zusammenarbeiten. Beispiele: - Netzwerk-Team, - Windows-Team, - Cloud-Team, - Internetanbieter, - Hardwarehersteller. Deshalb existieren unterschiedliche Vereinbarungen. --- **Service Level Agreement (SLA)** Ein SLA ist eine Vereinbarung zwischen dem Serviceanbieter und dem Kunden. Es beschreibt, welche Leistungen erbracht werden. Typische Inhalte: - Servicebeschreibung, - Servicezeiten, - Verfügbarkeit, - Reaktionszeiten, - Wiederherstellungszeiten, - Rollen, - Eskalationen, - Reporting. Das SLA beschreibt die Erwartungen des Kunden. --- **Operational Level Agreement (OLA)** Ein OLA ist eine interne Vereinbarung innerhalb der Organisation. Beispiele: - Service Desk ↔ Netzwerk-Team - Netzwerk-Team ↔ Server-Team - Windows-Team ↔ Datenbankadministration - Cloud-Team ↔ Security-Team Ein OLA legt fest, welche Leistungen ein internes Team für andere Teams erbringt. Der Kunde sieht diese Vereinbarung normalerweise nicht. --- **Underpinning Agreement (UC)** Ein Underpinning Agreement (UC) ist eine Vereinbarung mit einem externen Dienstleister oder Lieferanten. Beispiele: - Internetprovider, - Cloud-Anbieter, - Hardwarewartung, - Softwarehersteller, - Rechenzentrum, - Managed Service Provider. Diese Vereinbarungen unterstützen die Einhaltung des SLA. --- **Die drei Ebenen** ```text Kunde │ ▼ SLA │ ▼ Interne Teams │ ▼ OLA │ ▼ Externe Lieferanten │ ▼ UC ``` Alle drei Ebenen müssen zusammenpassen. --- **Zusammenhang zwischen SLA, OLA und UC** Beispiel: Das SLA fordert: > Wiederherstellung innerhalb von vier Stunden. Damit dies möglich ist, vereinbart das Netzwerk-Team intern: > Analyse innerhalb von einer Stunde. Der Hardwarelieferant garantiert: > Ersatzhardware innerhalb von zwei Stunden. Nur wenn alle Vereinbarungen zusammenpassen, kann das SLA eingehalten werden. --- **Vergleich** | Merkmal | SLA | OLA | UC | |----------|-----|-----|----| | Vertragspartner | Kunde und Serviceanbieter | interne Teams | externer Dienstleister | | Sichtbar für Kunden | Ja | Nein | normalerweise nein | | Ziel | Servicequalität vereinbaren | interne Zusammenarbeit regeln | externe Leistungen absichern | --- **Beispiel: E-Mail-Service** Ein Unternehmen betreibt einen E-Mail-Service. Das SLA enthält: - Verfügbarkeit 99,9 % - Reaktionszeit 30 Minuten Intern existieren OLAs: - Windows-Team - Netzwerk-Team - Messaging-Team Zusätzlich bestehen UCs mit: - Internetprovider, - Cloud-Anbieter, - Hardwarelieferant. Alle Beteiligten tragen gemeinsam zur Servicequalität bei. --- **Servicezeiten abstimmen** Ein häufiger Fehler: SLA: 24 × 7 OLA: Montag bis Freitag Dadurch kann das SLA praktisch nicht eingehalten werden. Interne und externe Vereinbarungen müssen deshalb zueinander passen. --- **Mehrere SLAs** Eine Organisation kann unterschiedliche SLAs besitzen. Beispiele: - Standard-Support, - Premium-Support, - interne Fachbereiche, - externe Kunden, - geschäftskritische Services. Nicht jeder Service benötigt dieselben Serviceziele. --- **Serviceklassen** Viele Organisationen definieren verschiedene Serviceklassen. Beispiel: | Klasse | Verfügbarkeit | |----------|--------------| | Bronze | 99 % | | Silber | 99,5 % | | Gold | 99,9 % | | Platin | 99,99 % | Je höher die Anforderungen, desto größer sind meist Aufwand und Kosten. --- **Verantwortlichkeiten** Ein SLA beschreibt auch, wer welche Aufgaben übernimmt. Beispiele: Serviceanbieter: - Support leisten, - Monitoring betreiben, - Incidents bearbeiten. Kunde: - Störungen melden, - Ansprechpartner benennen, - Änderungen abstimmen. Klare Verantwortlichkeiten vermeiden Missverständnisse. --- **Messverfahren** Ein SLA sollte festlegen, wie Kennzahlen gemessen werden. Beispiele: - Monitoring-System, - Service Desk, - Ticket-System, - Reports, - Verfügbarkeitsmessung. Nur eindeutig definierte Messverfahren ermöglichen objektive Bewertungen. --- **Ausnahmen** Nicht jede Unterbrechung zählt automatisch als SLA-Verletzung. Typische Ausnahmen: - geplante Wartungen, - höhere Gewalt, - externe Stromausfälle, - vereinbarte Wartungsfenster, - vom Kunden verursachte Ausfälle. Diese Ausnahmen sollten im SLA eindeutig beschrieben werden. --- **Review von Vereinbarungen** SLAs, OLAs und UCs sollten regelmäßig überprüft werden. Fragen dabei sind beispielsweise: - Werden Ziele erreicht? - Sind Servicezeiten noch passend? - Haben sich Geschäftsanforderungen geändert? - Sind neue Lieferanten beteiligt? - Müssen Kennzahlen angepasst werden? Dadurch bleiben Vereinbarungen aktuell. --- **Praxisbeispiel** Ein Unternehmen garantiert: VPN-Service: - 99,9 % Verfügbarkeit, - Reaktionszeit 30 Minuten. Intern besteht ein OLA: Netzwerk-Team: - Analyse innerhalb von 20 Minuten. Mit dem Internetprovider besteht zusätzlich ein UC: - Leitungsstörung innerhalb von zwei Stunden beheben. Alle Vereinbarungen unterstützen gemeinsam die Einhaltung des SLA. --- **Typische Fehler** **Fehler 1** SLA und OLA widersprechen sich. --- **Fehler 2** Externe Lieferanten erfüllen die Anforderungen nicht. --- **Fehler 3** Servicezeiten sind unrealistisch. --- **Fehler 4** Kennzahlen sind nicht messbar. --- **Fehler 5** Verantwortlichkeiten fehlen. --- **Fehler 6** Vereinbarungen werden nie überprüft. --- **Fehler 7** SLA enthält technische Details statt Serviceziele. --- **Fehler 8** Unterschiedliche Teams kennen die Vereinbarungen nicht. --- **Checkliste SLA** - [ ] Service beschrieben - [ ] Servicezeiten definiert - [ ] Kennzahlen messbar - [ ] Verantwortlichkeiten geregelt - [ ] Eskalationen beschrieben - [ ] Ausnahmen dokumentiert - [ ] Reporting vereinbart - [ ] Reviews geplant --- **Checkliste OLA und UC** - [ ] interne Leistungen abgestimmt - [ ] externe Leistungen dokumentiert - [ ] Reaktionszeiten passend - [ ] Verantwortlichkeiten eindeutig - [ ] Vereinbarungen regelmäßig überprüft - [ ] SLA wird unterstützt - [ ] Änderungen nachgeführt - [ ] Ansprechpartner bekannt --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker erstellen SLAs meist nicht selbst, arbeiten jedoch täglich daran, dass deren Ziele erreicht werden. Typische Aufgaben: - Incidents innerhalb der vereinbarten Zeiten bearbeiten, - Monitoring überwachen, - Änderungen dokumentieren, - interne Abstimmungen unterstützen, - externe Dienstleister koordinieren. Dadurch tragen sie direkt zur Einhaltung der Servicequalität bei. --- **Zusammenfassung** > Serviceziele vereinbaren > > ↓ > > SLA mit dem Kunden festlegen > > ↓ > > OLA zwischen internen Teams abstimmen > > ↓ > > UC mit externen Dienstleistern vereinbaren > > ↓ > > Servicequalität messen > > ↓ > > Regelmäßig überprüfen und verbessern --- **Merksätze** > Das SLA beschreibt die Vereinbarung mit dem Kunden. > Das OLA regelt die Zusammenarbeit innerhalb der Organisation. > Das UC beschreibt Vereinbarungen mit externen Dienstleistern. > Alle drei Ebenen müssen zusammenpassen. > Ein SLA ist nur realistisch, wenn OLA und UC seine Einhaltung unterstützen. --- **Verwandte Seiten** - 12.1 Ziele und Grundlagen des Service Level Management - 12.3 Kennzahlen, Berichte und Service Reviews - 12.4 Kundenzufriedenheit und Continual Improvement - 12.5 Zusammenspiel mit Incident, Problem, Change und Monitoring - Incident Management - Monitoring and Event Management - Supplier Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - ITIL Foundation – Version 5 **Einordnung** ITIL unterscheidet zwischen **Service Level Agreements (SLA)**, **Operational Level Agreements (OLA)** und **Underpinning Agreements (UC)**. Gemeinsam stellen sie sicher, dass vereinbarte Serviceziele sowohl intern als auch mit externen Dienstleistern unterstützt werden. Die konkrete Ausgestaltung dieser Vereinbarungen richtet sich nach den Anforderungen der jeweiligen Organisation. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 12.3 Kennzahlen, Berichte und Service Reviews > **Kurz erklärt** > > Vereinbarte Serviceziele sind nur dann sinnvoll, wenn ihre Einhaltung regelmäßig gemessen und bewertet wird. > > Service Level Management nutzt hierfür Kennzahlen (Metrics), Key Performance Indicators (KPIs), Berichte (Reports) und Service Reviews. > > Ziel ist es, die tatsächliche Servicequalität objektiv zu bewerten, Verbesserungspotenziale zu erkennen und gemeinsam mit den Kunden geeignete Maßnahmen abzuleiten. --- **Warum Kennzahlen wichtig sind** Ein Service kann nur verbessert werden, wenn seine Leistung messbar ist. Ohne Kennzahlen bleiben viele Aussagen subjektiv. Beispiele: Nicht messbar: > Der Support arbeitet schnell. Messbar: > 95 % aller Incidents wurden innerhalb von 30 Minuten angenommen. Nur messbare Informationen ermöglichen objektive Bewertungen. --- **Was sind Kennzahlen (Metrics)?** Kennzahlen sind messbare Werte, die Informationen über einen Service liefern. Beispiele: - Verfügbarkeit, - Antwortzeit, - Wiederherstellungszeit, - Anzahl Incidents, - Anzahl Service Requests, - Bearbeitungsdauer, - Fehlerrate, - Kundenzufriedenheit. Nicht jede Kennzahl eignet sich automatisch als KPI. --- **Key Performance Indicators (KPIs)** KPIs sind besonders wichtige Kennzahlen, mit denen die Zielerreichung bewertet wird. Beispiele: - SLA-Erfüllung, - Serviceverfügbarkeit, - MTTR, - MTTD, - Erstlösungsquote, - Kundenzufriedenheit, - Anzahl Major Incidents. KPIs konzentrieren sich auf die wichtigsten Erfolgsfaktoren. --- **Typische Service-Level-Kennzahlen** | Kennzahl | Aussage | |----------|----------| | Verfügbarkeit | Wie lange war der Service nutzbar? | | Reaktionszeit | Wann begann die Bearbeitung? | | Wiederherstellungszeit | Wann war der Service wieder verfügbar? | | SLA-Erfüllung | Wurden die vereinbarten Ziele erreicht? | | Erstlösungsquote | Wie viele Anfragen wurden direkt gelöst? | | Kundenzufriedenheit | Wie bewerten Benutzer den Service? | --- **Verfügbarkeit messen** Die Verfügbarkeit wird häufig in Prozent angegeben. Beispiele: - 99 % - 99,5 % - 99,9 % - 99,99 % Je höher die gewünschte Verfügbarkeit, desto größer werden meist Aufwand und Kosten. --- **Reaktionszeit und Wiederherstellungszeit** Diese beiden Begriffe werden häufig verwechselt. **Reaktionszeit** Zeit zwischen Eingang einer Meldung und Beginn der Bearbeitung. **Wiederherstellungszeit** Zeit bis der Service wieder ordnungsgemäß funktioniert. Ein Incident kann sehr schnell angenommen, aber erst deutlich später vollständig behoben werden. --- **Erstlösungsquote (First Contact Resolution)** Die Erstlösungsquote beschreibt, wie viele Anfragen bereits beim ersten Kontakt vollständig gelöst werden. Eine hohe Erstlösungsquote bedeutet häufig: - geringere Bearbeitungszeiten, - zufriedenere Benutzer, - weniger Eskalationen. Sie ist daher eine wichtige Kennzahl für Service Desks. --- **Kundenzufriedenheit** Technisch erfolgreiche Services führen nicht automatisch zu zufriedenen Benutzern. Typische Bewertungsmöglichkeiten: - Umfragen, - Sternebewertungen, - Feedbackformulare, - Interviews, - Net Promoter Score (NPS), - Customer Satisfaction Score (CSAT). Subjektive Bewertungen ergänzen technische Kennzahlen. --- **Berichte (Reports)** Kennzahlen werden regelmäßig in Berichten zusammengefasst. Typische Inhalte: - SLA-Erfüllung, - Verfügbarkeiten, - Major Incidents, - Trends, - Service Requests, - Verbesserungen, - Risiken, - offene Maßnahmen. Berichte richten sich an unterschiedliche Zielgruppen. --- **Zielgruppen für Berichte** Je nach Rolle unterscheiden sich die Inhalte. Beispiele: | Zielgruppe | Typische Inhalte | |------------|------------------| | Management | KPIs, Trends, Risiken | | Service Owner | SLA-Erfüllung, Verbesserungen | | Service Desk | Incidents, Service Requests | | Kunden | Servicequalität, Verfügbarkeit | | Administratoren | technische Kennzahlen | Jede Zielgruppe benötigt andere Informationen. --- **Service Reviews** Ein Service Review ist ein regelmäßiges Treffen, bei dem die Servicequalität bewertet wird. Typische Fragen: - Wurden SLA-Ziele erreicht? - Gab es häufige Störungen? - Welche Trends sind erkennbar? - Welche Maßnahmen wurden umgesetzt? - Welche Verbesserungen sind geplant? Service Reviews fördern die Zusammenarbeit zwischen IT und Kunden. --- **Typischer Ablauf eines Service Reviews** ```text Kennzahlen sammeln │ ▼ Berichte erstellen │ ▼ Service Review durchführen │ ▼ Abweichungen bewerten │ ▼ Verbesserungen beschließen │ ▼ Maßnahmen umsetzen ``` Service Reviews finden häufig monatlich oder quartalsweise statt. --- **Abweichungen analysieren** Nicht jede Zielabweichung bedeutet automatisch schlechte Servicequalität. Beispiele: - außergewöhnliche Störung, - größere Migration, - Sicherheitsvorfall, - Naturereignis. Wichtig ist, die Ursachen zu verstehen, statt ausschließlich Kennzahlen zu betrachten. --- **Trends erkennen** Einzelne Messwerte liefern oft nur eine Momentaufnahme. Trendanalysen zeigen Entwicklungen. Beispiele: - steigende Verfügbarkeit, - sinkende Incident-Anzahl, - kürzere Wiederherstellungszeiten, - höhere Kundenzufriedenheit. Dadurch werden Verbesserungen sichtbar. --- **Visualisierung** Kennzahlen lassen sich unterschiedlich darstellen. Beispiele: - Tabellen, - Balkendiagramme, - Liniendiagramme, - Ampelsysteme, - Dashboards, - Heatmaps. Die Darstellung sollte übersichtlich und leicht verständlich sein. --- **Benchmarking** Organisationen vergleichen ihre Kennzahlen häufig: - mit früheren Zeiträumen, - zwischen Standorten, - zwischen Services, - mit Branchenwerten. Benchmarking hilft, Verbesserungspotenziale zu erkennen. --- **Serviceverbesserungen ableiten** Service Reviews sollen konkrete Maßnahmen hervorbringen. Beispiele: - Monitoring erweitern, - Prozesse vereinfachen, - Self-Service verbessern, - Knowledge Base ergänzen, - Automatisierungen einführen, - Schulungen durchführen. Kennzahlen dienen also nicht nur der Kontrolle, sondern vor allem der Verbesserung. --- **Praxisbeispiel** Ein Unternehmen bewertet seinen VPN-Service. Ergebnisse: - Verfügbarkeit: 99,95 % - SLA erfüllt - Kundenzufriedenheit gestiegen - Wiederherstellungszeit verbessert - Incident-Anzahl gesunken Im Service Review wird beschlossen, den Self-Service weiter auszubauen, um die Anzahl einfacher Supportanfragen zusätzlich zu reduzieren. --- **Typische Fehler** **Fehler 1** Zu viele Kennzahlen. --- **Fehler 2** KPIs sind nicht eindeutig definiert. --- **Fehler 3** Kennzahlen werden gemessen, aber nicht ausgewertet. --- **Fehler 4** Berichte sind zu technisch. --- **Fehler 5** Service Reviews finden nicht regelmäßig statt. --- **Fehler 6** Nur negative Ergebnisse werden betrachtet. --- **Fehler 7** Kundenzufriedenheit wird nicht gemessen. --- **Fehler 8** Verbesserungsmaßnahmen werden nicht nachverfolgt. --- **Checkliste Kennzahlen** - [ ] eindeutig definiert - [ ] messbar - [ ] aktuell - [ ] nachvollziehbar - [ ] relevante KPIs ausgewählt - [ ] Trends ausgewertet - [ ] Zielwerte bekannt - [ ] regelmäßig überprüft --- **Checkliste Service Reviews** - [ ] Berichte vorbereitet - [ ] SLA bewertet - [ ] Trends analysiert - [ ] Kundenzufriedenheit betrachtet - [ ] Risiken besprochen - [ ] Maßnahmen beschlossen - [ ] Verantwortlichkeiten festgelegt - [ ] Nachverfolgung geplant --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker liefern viele der technischen Informationen, auf denen Service Reviews basieren. Typische Aufgaben: - Monitoring auswerten, - Kennzahlen bereitstellen, - Ursachen analysieren, - Reports unterstützen, - Verbesserungen umsetzen, - Servicequalität erhöhen. Damit tragen sie direkt zur kontinuierlichen Verbesserung der IT-Services bei. --- **Zusammenfassung** > Serviceleistung messen > > ↓ > > Kennzahlen berechnen > > ↓ > > Berichte erstellen > > ↓ > > Service Review durchführen > > ↓ > > Verbesserungen beschließen > > ↓ > > Maßnahmen umsetzen --- **Merksätze** > Kennzahlen machen Servicequalität messbar. > KPIs konzentrieren sich auf die wichtigsten Ziele. > Service Reviews dienen der Verbesserung – nicht der Schuldzuweisung. > Trends sind aussagekräftiger als einzelne Messwerte. > Gute Berichte unterstützen fundierte Entscheidungen. --- **Verwandte Seiten** - 12.1 Ziele und Grundlagen des Service Level Management - 12.2 Service Level Agreements (SLA), Operational Level Agreements (OLA) und Underpinning Agreements (UC) - 12.4 Kundenzufriedenheit und Continual Improvement - 12.5 Zusammenspiel mit Incident, Problem, Change und Monitoring - Monitoring and Event Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Kennzahlen, KPIs, Berichte und Service Reviews orientieren sich an den Empfehlungen der ITIL Practice „Service Level Management“. Welche Kennzahlen tatsächlich erhoben werden, richtet sich nach den vereinbarten Servicezielen und den Anforderungen der jeweiligen Organisation. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 12.4 Kundenzufriedenheit und Continual Improvement > **Kurz erklärt** > > Die Einhaltung von Service Level Agreements allein garantiert noch keinen guten IT-Service. > > Service Level Management betrachtet deshalb neben technischen Kennzahlen auch die Zufriedenheit der Benutzer und Kunden. > > Die gewonnenen Erkenntnisse fließen anschließend in das Continual Improvement ein, um Services langfristig weiterzuentwickeln. --- **Warum Kundenzufriedenheit wichtig ist** Ein Service kann alle vereinbarten Kennzahlen erfüllen, und trotzdem als schlecht wahrgenommen werden. Beispiel: Ein Incident wird innerhalb der vereinbarten vier Stunden behoben. Der Benutzer erhält jedoch während dieser Zeit keinerlei Rückmeldung. Technisch wurde das SLA erfüllt. Die wahrgenommene Servicequalität ist dennoch gering. --- **Servicequalität aus Sicht des Kunden** Kunden bewerten Services häufig nach anderen Kriterien als Administratoren. Typische Fragen sind: - Wurde mein Problem verstanden? - Wurde ich regelmäßig informiert? - War der Support freundlich? - Wurde mein Anliegen ernst genommen? - War die Lösung verständlich? - Hat der Service meine Arbeit unterstützt? Diese Aspekte ergänzen technische Kennzahlen. --- **Objektive und subjektive Bewertung** Servicequalität setzt sich aus beiden Bereichen zusammen. | Objektive Bewertung | Subjektive Bewertung | |---------------------|----------------------| | Verfügbarkeit | Freundlichkeit | | Reaktionszeit | Kommunikation | | Wiederherstellungszeit | Verständlichkeit | | SLA-Erfüllung | Gesamteindruck | | Fehlerrate | Zufriedenheit | Beide Sichtweisen sind wichtig. --- **Kundenzufriedenheit messen** Typische Verfahren: - Feedbackformular - Sternebewertung - Online-Umfrage - Telefoninterview - persönliche Gespräche - Customer Satisfaction Score (CSAT) - Net Promoter Score (NPS) Die Methode richtet sich nach Service und Organisation. --- **Customer Satisfaction Score (CSAT)** Der CSAT misst, wie zufrieden Benutzer unmittelbar nach einer Serviceleistung sind. Beispiel: > "Wie zufrieden waren Sie mit der Bearbeitung Ihres Incidents?" Antwortmöglichkeiten: - sehr zufrieden - zufrieden - neutral - unzufrieden - sehr unzufrieden Der CSAT eignet sich besonders für einzelne Supportfälle. --- **Net Promoter Score (NPS)** Der NPS bewertet, wie wahrscheinlich Kunden den Service weiterempfehlen würden. Typische Frage: > "Wie wahrscheinlich ist es, dass Sie unseren IT-Service weiterempfehlen?" Bewertung: 0 bis 10 Punkte. Der NPS betrachtet eher die langfristige Gesamtzufriedenheit. --- **Feedback ernst nehmen** Nicht jedes negative Feedback bedeutet, dass Prozesse schlecht funktionieren. Es kann beispielsweise aufzeigen: - unklare Kommunikation, - fehlende Informationen, - komplizierte Abläufe, - schlechte Dokumentation, - unrealistische Erwartungen. Feedback liefert wichtige Hinweise für Verbesserungen. --- **Beschwerden analysieren** Beschwerden sollten systematisch ausgewertet werden. Beispiele: - häufige Rückfragen, - lange Wartezeiten, - unverständliche Formulare, - fehlende Statusmeldungen, - komplizierte Genehmigungen. Dadurch lassen sich wiederkehrende Schwachstellen erkennen. --- **Verbesserungen priorisieren** Nicht jede Verbesserung besitzt dieselbe Bedeutung. Typische Kriterien: - Anzahl betroffener Benutzer, - geschäftlicher Nutzen, - Kosten, - Risiken, - Umsetzungsaufwand. Priorisierung hilft, Ressourcen gezielt einzusetzen. --- **Continual Improvement** Continual Improvement ist eine eigenständige ITIL Practice. Ihr Ziel besteht darin, Services, Prozesse und Arbeitsweisen kontinuierlich weiterzuentwickeln. Service Level Management liefert dafür wichtige Informationen. --- **Zusammenspiel** ```text Kennzahlen │ ▼ Feedback │ ▼ Service Review │ ▼ Verbesserungen planen │ ▼ Maßnahmen umsetzen │ ▼ Erneut messen ``` Verbesserung ist ein fortlaufender Kreislauf. --- **Typische Verbesserungsmaßnahmen** Beispiele: - Self-Service ausbauen, - Knowledge Base erweitern, - Formulare vereinfachen, - Genehmigungen beschleunigen, - Monitoring verbessern, - Automatisierungen einführen, - Dashboards erweitern, - Mitarbeiterschulungen durchführen. Auch kleine Änderungen können die Servicequalität deutlich erhöhen. --- **Kommunikation verbessern** Benutzer bewerten häufig nicht nur die Lösung, sondern auch den Umgang während der Bearbeitung. Wichtige Punkte: - regelmäßige Statusmeldungen, - verständliche Sprache, - realistische Zeitangaben, - transparente Informationen, - erreichbare Ansprechpartner. Gute Kommunikation erhöht die Zufriedenheit oft stärker als technische Optimierungen. --- **Erfolge sichtbar machen** Verbesserungen sollten dokumentiert und kommuniziert werden. Beispiele: - kürzere Bearbeitungszeiten, - höhere Verfügbarkeit, - weniger Incidents, - bessere Kundenzufriedenheit, - schnellere Genehmigungen. Dadurch wird der Nutzen des Continual Improvement sichtbar. --- **Langfristige Entwicklung beobachten** Einzelne Umfragen liefern nur Momentaufnahmen. Erst langfristige Entwicklungen zeigen, ob Verbesserungen tatsächlich wirken. Beispiele: - steigende Zufriedenheit, - sinkende Incident-Zahlen, - bessere SLA-Erfüllung, - kürzere Wiederherstellungszeiten. Trendanalysen sind deshalb besonders wertvoll. --- **Praxisbeispiel** Eine Umfrage zeigt, dass Benutzer zwar mit der technischen Lösung zufrieden sind, aber häufig fehlende Statusinformationen bemängeln. Daraufhin führt die IT automatische Statusmeldungen im Ticketsystem ein. Bei der nächsten Befragung steigt die Kundenzufriedenheit deutlich, obwohl sich die technischen Kennzahlen kaum verändert haben. --- **Typische Fehler** **Fehler 1** Nur SLA-Kennzahlen werden betrachtet. --- **Fehler 2** Benutzerfeedback wird ignoriert. --- **Fehler 3** Umfragen finden nur selten statt. --- **Fehler 4** Verbesserungsmaßnahmen werden nicht umgesetzt. --- **Fehler 5** Kommunikation wird unterschätzt. --- **Fehler 6** Nur negatives Feedback wird ausgewertet. --- **Fehler 7** Verbesserungen werden nicht gemessen. --- **Fehler 8** Es gibt keine Verantwortlichen für Verbesserungsmaßnahmen. --- **Checkliste Kundenzufriedenheit** - [ ] Feedback eingeholt - [ ] Ergebnisse ausgewertet - [ ] Trends erkannt - [ ] Beschwerden analysiert - [ ] Kommunikation bewertet - [ ] Verbesserungen geplant - [ ] Maßnahmen umgesetzt - [ ] Erfolg überprüft --- **Checkliste Continual Improvement** - [ ] Kennzahlen ausgewertet - [ ] Service Reviews durchgeführt - [ ] Verbesserungspotenziale identifiziert - [ ] Prioritäten festgelegt - [ ] Verantwortlichkeiten definiert - [ ] Maßnahmen dokumentiert - [ ] Erfolg gemessen - [ ] regelmäßige Wiederholung geplant --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker tragen wesentlich zur Verbesserung der Servicequalität bei. Typische Aufgaben: - Benutzerfeedback aufnehmen, - technische Verbesserungen umsetzen, - Prozesse optimieren, - Automatisierungen entwickeln, - Dokumentationen verbessern, - Monitoring erweitern, - Knowledge Base pflegen. Viele Verbesserungen entstehen direkt aus den Erfahrungen des täglichen IT-Betriebs. --- **Zusammenfassung** > Serviceleistung messen > > ↓ > > Benutzerfeedback einholen > > ↓ > > Ergebnisse auswerten > > ↓ > > Verbesserungen planen > > ↓ > > Maßnahmen umsetzen > > ↓ > > Erfolg erneut messen --- **Merksätze** > SLA-Erfüllung bedeutet nicht automatisch zufriedene Benutzer. > Kommunikation beeinflusst die wahrgenommene Servicequalität erheblich. > Feedback ist eine wichtige Grundlage für Verbesserungen. > Continual Improvement ist ein fortlaufender Prozess. > Jede Verbesserung sollte anschließend erneut bewertet werden. --- **Verwandte Seiten** - 12.1 Ziele und Grundlagen des Service Level Management - 12.2 Service Level Agreements (SLA), Operational Level Agreements (OLA) und Underpinning Agreements (UC) - 12.3 Kennzahlen, Berichte und Service Reviews - 12.5 Zusammenspiel mit Incident, Problem, Change und Monitoring - Continual Improvement - Incident Management - Monitoring and Event Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Verfahren zur Messung der Kundenzufriedenheit und zur kontinuierlichen Verbesserung orientieren sich an den Empfehlungen der ITIL Practices „Service Level Management“ und „Continual Improvement“. Die Auswahl geeigneter Kennzahlen, Umfragen und Verbesserungsmaßnahmen richtet sich nach den Anforderungen der jeweiligen Organisation und ihrer Kunden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 12.5 Zusammenspiel mit Incident, Problem, Change und Monitoring > **Kurz erklärt** > > Service Level Management arbeitet nicht isoliert. > > Die Einhaltung vereinbarter Serviceziele ist nur möglich, wenn verschiedene ITIL Practices eng zusammenarbeiten. > > Incident Management, Problem Management, Change Enablement, Monitoring and Event Management sowie Continual Improvement liefern die Informationen und Maßnahmen, die zur Erfüllung der Service Levels notwendig sind. > > Service Level Management bewertet diese Ergebnisse und entwickelt die Services gemeinsam mit Kunden und Fachbereichen kontinuierlich weiter. --- **Warum das Zusammenspiel wichtig ist** Ein Service Level Agreement beschreibt, welche Leistungen vereinbart wurden. Es sorgt jedoch nicht selbst dafür, dass diese Leistungen erbracht werden. Dafür arbeiten mehrere ITIL Practices zusammen. --- **Zusammenspiel der Practices** ```text Monitoring │ ▼ Incident Management │ ▼ Problem Management │ ▼ Change Enablement │ ▼ Service Level Management │ ▼ Continual Improvement ``` Jede Practice erfüllt dabei eine eigene Aufgabe. --- **Service Level Management und Incident Management** Incident Management stellt den normalen Betrieb möglichst schnell wieder her. Service Level Management bewertet anschließend, ob dabei die vereinbarten Ziele eingehalten wurden. Beispiele: - Reaktionszeit, - Wiederherstellungszeit, - Kommunikationspflichten, - Priorisierung. Incident Management arbeitet operativ. Service Level Management bewertet die Ergebnisse. --- **Beispiel** SLA: - Reaktionszeit: 30 Minuten - Wiederherstellung: vier Stunden Ein Incident wird nach 20 Minuten angenommen und nach drei Stunden behoben. Service Level Management bewertet: SLA erfüllt. --- **Service Level Management und Problem Management** Wiederkehrende SLA-Verletzungen können auf tieferliegende Probleme hinweisen. Beispiele: - regelmäßig langsame Datenbank, - häufige VPN-Ausfälle, - wiederkehrende Storage-Probleme, - ständig überlastete Server. Problem Management untersucht anschließend die eigentliche Ursache. --- **Service Level Management und Change Enablement** Viele Verbesserungen der Servicequalität erfolgen über Changes. Beispiele: - neue Hardware, - Softwareupdates, - Cluster-Erweiterung, - zusätzliche Netzwerkverbindungen, - neue Firewall, - Cloud-Migration. Service Level Management zeigt, welche Verbesserungen notwendig sind. Change Enablement setzt sie kontrolliert um. --- **Monitoring and Event Management** Monitoring liefert die Messwerte, auf denen viele SLA-Kennzahlen basieren. Beispiele: - Verfügbarkeit, - Antwortzeit, - Ausfallzeiten, - Performance, - Alarme, - Servicezustand. Ohne Monitoring wären objektive Bewertungen kaum möglich. --- **Beispiel** Monitoring misst: - Verfügbarkeit 99,93 % SLA fordert: 99,90 % Service Level Management bewertet: SLA erfüllt. --- **Service Configuration Management** Service Configuration Management beschreibt, welche Configuration Items zu einem Service gehören. Dadurch lässt sich feststellen, welche Ausfälle tatsächlich den vereinbarten Service beeinflussen. Außerdem unterstützt die CMDB: - Auswirkungsanalysen, - Service Reviews, - Verbesserungsmaßnahmen, - Planung von Changes. --- **Availability Management** Availability Management entwickelt Maßnahmen, um die Verfügbarkeit eines Services zu erhöhen. Beispiele: - Redundanzen, - Cluster, - Load Balancer, - Failover, - Hochverfügbarkeit. Service Level Management bewertet anschließend, ob die vereinbarten Verfügbarkeitsziele erreicht wurden. --- **Capacity and Performance Management** Kapazitätsengpässe können SLA-Verletzungen verursachen. Capacity and Performance Management überwacht beispielsweise: - CPU, - Arbeitsspeicher, - Storage, - Netzwerk, - Datenbanken. Service Level Management erkennt anhand der Kennzahlen, wann zusätzliche Ressourcen notwendig werden. --- **Information Security Management** Auch Sicherheitsmaßnahmen beeinflussen Service Levels. Beispiele: - Multi-Faktor-Authentifizierung, - Firewalls, - Patchmanagement, - Zugriffskontrollen, - Sicherheitsupdates. Ein ausgewogenes Verhältnis zwischen Sicherheit und Benutzerfreundlichkeit ist wichtig. --- **Supplier Management** Externe Dienstleister beeinflussen häufig direkt die Servicequalität. Beispiele: - Cloud-Anbieter, - Internetprovider, - Hardwarewartung, - Softwarehersteller. Service Level Management überprüft, ob externe Leistungen die vereinbarten Serviceziele unterstützen. --- **Continual Improvement** Service Reviews liefern Verbesserungspotenziale. Diese fließen anschließend in Continual Improvement ein. Beispiele: - Prozesse vereinfachen, - Automatisierung erweitern, - Self-Service verbessern, - Monitoring optimieren, - Dokumentationen ergänzen. Servicequalität wird dadurch kontinuierlich verbessert. --- **Informationsfluss** ```text Monitoring │ ▼ Kennzahlen │ ▼ Service Review │ ▼ Verbesserungsmaßnahmen │ ▼ Change Enablement │ ▼ Monitoring überprüft Ergebnis ``` Dadurch entsteht ein geschlossener Verbesserungszyklus. --- **Praxisbeispiel** Ein Unternehmen stellt fest, dass die Wiederherstellungszeit des VPN-Services regelmäßig das SLA überschreitet. Monitoring liefert die Messdaten. Incident Management dokumentiert die Bearbeitungszeiten. Problem Management erkennt, dass ein einzelner VPN-Gateway überlastet ist. Change Enablement führt einen zweiten Gateway ein. Monitoring bestätigt anschließend, dass die Wiederherstellungszeit deutlich sinkt. Im nächsten Service Review wird festgestellt, dass das SLA nun wieder zuverlässig eingehalten wird. --- **Typische Fehler** **Fehler 1** Service Level Management betrachtet nur SLA-Kennzahlen. --- **Fehler 2** Monitoring liefert unvollständige Daten. --- **Fehler 3** Problem Management wird nicht einbezogen. --- **Fehler 4** Verbesserungen werden nicht umgesetzt. --- **Fehler 5** Changes berücksichtigen Serviceziele nicht. --- **Fehler 6** Supplier erfüllen vereinbarte Leistungen nicht. --- **Fehler 7** Service Reviews führen zu keinen Maßnahmen. --- **Fehler 8** Service Levels werden nach Änderungen nicht angepasst. --- **Fehler 9** Configuration-Daten sind veraltet. --- **Fehler 10** Kennzahlen werden gemessen, aber nicht zur Verbesserung genutzt. --- **Checkliste Zusammenspiel** - [ ] Monitoring liefert aktuelle Kennzahlen - [ ] Incident-Zeiten werden ausgewertet - [ ] Problem Records berücksichtigt - [ ] Changes unterstützen Serviceziele - [ ] CMDB aktuell - [ ] Supplier eingebunden - [ ] Service Reviews durchgeführt - [ ] Verbesserungsmaßnahmen umgesetzt --- **Checkliste Service Level Management** - [ ] SLA aktuell - [ ] OLA abgestimmt - [ ] UC überprüft - [ ] Kennzahlen vollständig - [ ] Reviews geplant - [ ] Kundenzufriedenheit bewertet - [ ] Verbesserungen dokumentiert - [ ] Erfolg nachverfolgt --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker tragen täglich zur Einhaltung der Service Levels bei. Typische Aufgaben: - Incidents bearbeiten, - Monitoring überwachen, - Configuration-Daten pflegen, - Changes durchführen, - Ursachen analysieren, - Services verbessern, - Dokumentationen aktualisieren. Damit unterstützen sie direkt die vereinbarte Servicequalität. --- **Zusammenfassung** > Monitoring liefert Kennzahlen > > ↓ > > Incident Management stellt Services wieder her > > ↓ > > Problem Management beseitigt Ursachen > > ↓ > > Change Enablement setzt Verbesserungen um > > ↓ > > Service Level Management bewertet die Ergebnisse > > ↓ > > Continual Improvement entwickelt den Service weiter --- **Merksätze** > Service Level Management bewertet Leistungen – andere Practices erbringen sie. > Monitoring liefert die Messwerte für SLA-Bewertungen. > Problem Management reduziert zukünftige SLA-Verletzungen. > Service Reviews bilden die Grundlage für kontinuierliche Verbesserungen. > Gute Servicequalität entsteht nur durch das Zusammenspiel mehrerer ITIL Practices. --- **Verwandte Seiten** - 12.1 Ziele und Grundlagen des Service Level Management - 12.2 Service Level Agreements (SLA), Operational Level Agreements (OLA) und Underpinning Agreements (UC) - 12.3 Kennzahlen, Berichte und Service Reviews - 12.4 Kundenzufriedenheit und Continual Improvement - Incident Management - Problem Management - Change Enablement - Monitoring and Event Management - Service Configuration Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Level Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Service Level Management bewertet die Einhaltung vereinbarter Serviceziele, während andere Practices die technischen und organisatorischen Voraussetzungen schaffen. Erst ihr Zusammenspiel ermöglicht eine dauerhaft hohe Servicequalität. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 13. Change Enablement # 13.1 Ziele und Grundlagen des Change Enablement > **Kurz erklärt** > > Änderungen an IT-Systemen gehören zum Alltag jeder Organisation. > > Neue Software wird installiert, Server aktualisiert, Sicherheitslücken geschlossen oder Cloud-Dienste erweitert. > > Ziel des **Change Enablement** ist es, diese Änderungen kontrolliert, nachvollziehbar und mit möglichst geringem Risiko umzusetzen. > > Dabei sollen notwendige Veränderungen ermöglicht werden, ohne die Stabilität der IT-Services unnötig zu gefährden. --- **Was ist Change Enablement?** Change Enablement ist eine ITIL Practice zur Steuerung und Unterstützung von Änderungen an Services und Configuration Items. Sie sorgt dafür, dass Änderungen: - geplant, - bewertet, - genehmigt, - umgesetzt, - überprüft und dokumentiert werden. --- **Warum heißt es nicht mehr Change Management?** Frühere ITIL-Versionen verwendeten den Begriff: > **Change Management** Seit ITIL 4 lautet die offizielle Bezeichnung: > **Change Enablement** Der neue Name verdeutlicht, dass Änderungen nicht verhindert, sondern sicher und effizient ermöglicht werden sollen. --- **Warum Änderungen notwendig sind** Ohne Änderungen wäre eine moderne IT nicht dauerhaft funktionsfähig. Typische Gründe: - Sicherheitsupdates, - neue Hardware, - neue Software, - gesetzliche Anforderungen, - Fehlerbehebungen, - Leistungsverbesserungen, - Cloud-Migrationen, - neue Geschäftsanforderungen. Veränderungen gehören zum normalen IT-Betrieb. --- **Ziele des Change Enablement** Die wichtigsten Ziele sind: - Risiken reduzieren, - erfolgreiche Änderungen ermöglichen, - Serviceunterbrechungen vermeiden, - Auswirkungen bewerten, - Verantwortlichkeiten festlegen, - Änderungen dokumentieren, - Zusammenarbeit verbessern, - kontinuierliche Verbesserungen unterstützen. --- **Was ist ein Change?** Ein Change ist jede geplante Änderung, die Auswirkungen auf Services oder Configuration Items haben kann. Beispiele: - Betriebssystem aktualisieren, - Firewallregel ändern, - Benutzerverwaltung erweitern, - Zertifikat erneuern, - Server austauschen, - Netzwerk erweitern, - Cloud-Service aktivieren, - Software installieren. Nicht jede technische Tätigkeit ist automatisch ein Change. --- **Change ist nicht gleich Incident** Diese Begriffe werden häufig verwechselt. | Incident | Change | |----------|--------| | ungeplante Störung | geplante Änderung | | Ziel: Service wiederherstellen | Ziel: Service verbessern oder anpassen | | häufig Zeitdruck | normalerweise geplant | | reaktive Tätigkeit | proaktive Tätigkeit | Ein Incident kann später einen Change erforderlich machen. --- **Beispiel** Ein Server fällt regelmäßig aus. Incident Management stellt den Betrieb mehrfach wieder her. Problem Management findet die Ursache. Zur dauerhaften Lösung wird: - zusätzlicher Arbeitsspeicher eingebaut. Diese geplante Änderung ist ein Change. --- **Grundprinzip des Change Enablement** Jede Änderung sollte beantwortete Fragen besitzen: - Warum ist die Änderung notwendig? - Welche Systeme sind betroffen? - Welche Risiken bestehen? - Wer genehmigt die Änderung? - Wann wird sie durchgeführt? - Wie wird sie getestet? - Wie erfolgt ein Rollback? - Wer informiert die Benutzer? --- **Typischer Ablauf** ```text Änderungsbedarf │ ▼ Bewertung │ ▼ Risikoanalyse │ ▼ Genehmigung │ ▼ Umsetzung │ ▼ Überprüfung │ ▼ Abschluss ``` Nicht jeder Change durchläuft alle Schritte mit demselben Aufwand. --- **Warum Risiken bewertet werden** Jede Änderung kann unbeabsichtigte Auswirkungen haben. Beispiele: - Server startet nicht mehr, - Anwendung funktioniert nicht, - Netzwerkverbindung fällt aus, - Benutzer können sich nicht anmelden, - Daten gehen verloren. Deshalb bewertet Change Enablement Risiken bereits vor der Umsetzung. --- **Nutzen strukturierter Changes** Ein geregelter Change-Prozess sorgt unter anderem für: - weniger Ausfälle, - bessere Planbarkeit, - höhere Servicequalität, - nachvollziehbare Entscheidungen, - geringere Risiken, - bessere Dokumentation. Dadurch steigt die Stabilität der IT. --- **Nicht jede Änderung ist gleich kritisch** Beispiele: Geringes Risiko: - Druckertreiber aktualisieren. Hohes Risiko: - Active Directory migrieren. Je größer die Auswirkungen, desto sorgfältiger erfolgt Planung und Bewertung. --- **Verantwortlichkeiten** An einem Change können verschiedene Rollen beteiligt sein. Beispiele: - Antragsteller, - Change Manager, - technische Spezialisten, - Service Owner, - Information Security, - Management. Nicht jede Organisation verwendet alle Rollen. --- **Dokumentation** Jeder Change sollte nachvollziehbar dokumentiert werden. Typische Inhalte: - Ziel, - Umfang, - Zeitpunkt, - Verantwortliche, - Risiko, - Genehmigung, - Testergebnisse, - Rollback, - Abschlussbewertung. Eine gute Dokumentation erleichtert spätere Analysen. --- **Praxisbeispiel** Ein Unternehmen möchte den VPN-Server aktualisieren. Vor der Umsetzung werden: - Risiken bewertet, - Wartungsfenster festgelegt, - Benutzer informiert, - Backup erstellt, - Rollback vorbereitet. Nach erfolgreicher Aktualisierung bestätigt das Monitoring, dass der Service wieder ordnungsgemäß funktioniert. --- **Typische Fehler** **Fehler 1** Änderungen erfolgen ohne Planung. --- **Fehler 2** Risiken werden nicht bewertet. --- **Fehler 3** Es existiert kein Rollback. --- **Fehler 4** Benutzer werden nicht informiert. --- **Fehler 5** Änderungen werden nicht dokumentiert. --- **Fehler 6** Monitoring prüft das Ergebnis nicht. --- **Fehler 7** Configuration-Daten werden nicht aktualisiert. --- **Fehler 8** Changes werden direkt in der Produktion getestet. --- **Checkliste Change Enablement** - [ ] Ziel definiert - [ ] Auswirkungen bewertet - [ ] Risiken analysiert - [ ] Genehmigung vorhanden - [ ] Wartungsfenster geplant - [ ] Rollback vorbereitet - [ ] Monitoring berücksichtigt - [ ] Dokumentation vollständig --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker setzen täglich Changes um. Typische Aufgaben: - Updates installieren, - Server migrieren, - Netzwerkänderungen durchführen, - Firewallregeln anpassen, - Dokumentationen aktualisieren, - Monitoring prüfen, - Rollback vorbereiten. Ein strukturierter Change-Prozess reduziert Ausfälle und erhöht die Stabilität der IT. --- **Zusammenfassung** > Änderungsbedarf erkennen > > ↓ > > Risiken bewerten > > ↓ > > Genehmigung einholen > > ↓ > > Änderung umsetzen > > ↓ > > Ergebnis überprüfen > > ↓ > > Dokumentieren und abschließen --- **Merksätze** > Change Enablement ermöglicht Veränderungen – es verhindert sie nicht. > Jede Änderung sollte geplant und bewertet werden. > Je höher das Risiko, desto sorgfältiger die Vorbereitung. > Ein Rollback gehört zu jeder kritischen Änderung. > Gute Dokumentation unterstützt zukünftige Changes. --- **Verwandte Seiten** - 13.2 Change-Typen und Risikobewertung - 13.3 Genehmigungen, CAB und Change-Kalender - 13.4 Umsetzung, Tests und Rollback - 13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring - Incident Management - Problem Management - Service Configuration Management - Monitoring and Event Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Grundlagen orientieren sich an der ITIL Practice „Change Enablement“. ITIL definiert Grundprinzipien für die kontrollierte Durchführung von Änderungen, schreibt jedoch keinen starren Prozess vor. Die konkrete Umsetzung richtet sich nach Größe, Risiken und Anforderungen der jeweiligen Organisation. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 13.2 Change-Typen und Risikobewertung > **Kurz erklärt** > > Nicht jede Änderung besitzt dasselbe Risiko oder denselben Aufwand. > > Deshalb unterscheidet ITIL verschiedene Change-Typen. > > Je nach Risiko, Auswirkungen und Dringlichkeit unterscheiden sich Planung, Genehmigung und Durchführung. > > Ziel ist es, **einfache Änderungen möglichst effizient und risikoreiche Änderungen besonders sorgfältig umzusetzen.** --- **Warum verschiedene Change-Typen?** Eine kleine Änderung, wie das Aktualisieren einer Druckersoftware, benötigt deutlich weniger Planung als die Migration eines Active Directory. Würden beide Änderungen denselben Prozess durchlaufen, wäre der Aufwand unnötig hoch. Deshalb unterscheidet ITIL verschiedene Change-Typen. --- **Die drei Change-Typen nach ITIL** ITIL Version 5 unterscheidet grundsätzlich: | Change-Typ | Beschreibung | |------------|--------------| | Standard Change | geringes Risiko, vorab genehmigt | | Normal Change | individuelle Bewertung und Genehmigung erforderlich | | Emergency Change | schnelle Umsetzung wegen dringender Situation | Diese Einteilung richtet sich nach Risiko und Auswirkungen, nicht nach der technischen Komplexität. --- **Standard Change** Ein Standard Change ist: - bekannt, - dokumentiert, - risikoarm, - getestet, - bereits genehmigt. Für jede Durchführung ist normalerweise keine neue Genehmigung erforderlich. --- **Beispiele für Standard Changes** Mögliche Standard Changes: - Druckertreiber installieren, - Benutzerkonto anlegen, - Standardsoftware installieren, - Zertifikat erneuern, - Gruppenmitgliedschaft ändern, - Standard-Firewallregel aktivieren, - VM nach Vorlage bereitstellen. Diese Änderungen folgen meist einem festen Ablauf. --- **Eigenschaften eines Standard Change** Ein Standard Change besitzt: - klaren Ablauf, - bekannte Risiken, - dokumentierte Arbeitsschritte, - definierte Verantwortlichkeiten, - erprobte Durchführung, - festgelegte Rollback-Möglichkeiten. Dadurch kann er effizient umgesetzt werden. --- **Normal Change** Ein Normal Change ist die häufigste Form einer Änderung. Er wird individuell bewertet. Dabei werden unter anderem betrachtet: - Risiken, - Auswirkungen, - Aufwand, - Ressourcen, - Wartungsfenster, - Genehmigungen. --- **Beispiele für Normal Changes** Typische Beispiele: - Servermigration, - Firewall-Konfiguration ändern, - neue Anwendung einführen, - Datenbank aktualisieren, - Netzwerk erweitern, - Active Directory ändern, - Cluster erweitern. Diese Änderungen benötigen meist eine individuelle Planung. --- **Emergency Change** Ein Emergency Change dient dazu, eine akute Gefahr oder Störung schnell zu beseitigen. Dabei wird der normale Genehmigungsprozess verkürzt, nicht jedoch vollständig ausgelassen. --- **Beispiele für Emergency Changes** Typische Situationen: - kritische Sicherheitslücke, - Ransomware-Angriff, - Zertifikat abgelaufen, - Produktionssystem ausgefallen, - kritischer Softwarefehler, - schwerwiegender Netzwerkausfall. Hier steht die schnelle Wiederherstellung des Betriebs im Vordergrund. --- **Emergency bedeutet nicht ungeplant** Auch Emergency Changes sollten soweit möglich: - dokumentiert, - bewertet, - getestet, - nachbereitet werden. Lediglich der Zeitdruck ist deutlich höher. --- **Vergleich der Change-Typen** | Merkmal | Standard | Normal | Emergency | |----------|----------|---------|-----------| | Risiko | gering | unterschiedlich | häufig hoch | | Genehmigung | vorab | individuell | beschleunigt | | Planung | standardisiert | individuell | verkürzt | | Dokumentation | erforderlich | erforderlich | ebenfalls erforderlich | --- **Risikobewertung** Vor jeder Änderung sollte bewertet werden, welche Risiken bestehen. Typische Fragen: - Welche Services sind betroffen? - Welche Benutzer sind betroffen? - Welche Ausfallzeit entsteht? - Gibt es Redundanzen? - Existiert ein Rollback? - Wurde ausreichend getestet? Die Risikobewertung unterstützt fundierte Entscheidungen. --- **Risikofaktoren** Beispiele für Risikofaktoren: - produktive Systeme, - geschäftskritische Services, - viele Benutzer betroffen, - komplexe Infrastruktur, - neue Technologien, - fehlende Erfahrung, - hoher Zeitdruck, - externe Abhängigkeiten. Je mehr Risikofaktoren vorliegen, desto sorgfältiger sollte geplant werden. --- **Business Impact** Neben technischen Risiken wird auch der geschäftliche Einfluss bewertet. Beispiele: Gering: - Testsystem. Mittel: - internes Intranet. Hoch: - ERP-System, - Produktionssteuerung, - Online-Shop. Business Impact und technisches Risiko sind nicht immer identisch. --- **Wahrscheinlichkeit und Auswirkung** Risiken werden häufig anhand zweier Kriterien bewertet: - Eintrittswahrscheinlichkeit, - Auswirkung. Beispiel: | Wahrscheinlichkeit | Auswirkung | Risiko | |--------------------|------------|---------| | gering | gering | niedrig | | hoch | gering | mittel | | gering | hoch | mittel | | hoch | hoch | hoch | Diese Bewertung unterstützt die Entscheidung über notwendige Maßnahmen. --- **Risikomatrix** Eine vereinfachte Risikomatrix: ```text Auswirkung Niedrig Mittel Hoch Niedrig 🟢 🟢 🟡 Mittel 🟢 🟡 🟠 Hoch 🟡 🟠 🔴 ``` Je höher das Risiko, desto umfangreicher sollten Planung und Genehmigung sein. --- **Risikominimierung** Risiken lassen sich häufig reduzieren. Beispiele: - Tests durchführen, - Wartungsfenster nutzen, - Backup erstellen, - Rollback vorbereiten, - Pilotbetrieb, - Redundanzen verwenden, - Benutzer informieren. Ziel ist nicht, jedes Risiko vollständig auszuschließen, sondern es auf ein akzeptables Maß zu reduzieren. --- **Rest-Risiko** Auch nach sorgfältiger Planung bleibt häufig ein Restrisiko bestehen. Beispiel: Ein Betriebssystem-Update wurde erfolgreich getestet. Trotzdem kann es in der Produktivumgebung zu unerwarteten Problemen kommen. Deshalb gehören Rollback und Monitoring zu jeder kritischen Änderung. --- **Praxisbeispiel** Ein Unternehmen plant ein Firmware-Update für zentrale Switches. Die Bewertung ergibt: - hoher Business Impact, - mittlere Eintrittswahrscheinlichkeit, - vorhandene Redundanz, - getesteter Rollback. Der Change wird als Normal Change durchgeführt. Das Wartungsfenster wird nachts geplant, Monitoring überwacht die Umsetzung und bei Problemen steht ein Rollback bereit. --- **Typische Fehler** **Fehler 1** Alle Änderungen werden gleich behandelt. --- **Fehler 2** Risiken werden nicht dokumentiert. --- **Fehler 3** Business Impact wird unterschätzt. --- **Fehler 4** Emergency Changes werden nicht nachbereitet. --- **Fehler 5** Standard Changes werden nie überprüft. --- **Fehler 6** Es existiert kein Rollback. --- **Fehler 7** Tests fehlen. --- **Fehler 8** Benutzer werden nicht informiert. --- **Fehler 9** Monitoring überwacht den Change nicht. --- **Fehler 10** Risikobewertung erfolgt nur technisch, nicht geschäftlich. --- **Checkliste Risikobewertung** - [ ] Change-Typ bestimmt - [ ] Auswirkungen bewertet - [ ] Business Impact geprüft - [ ] Risiken dokumentiert - [ ] Tests durchgeführt - [ ] Rollback vorbereitet - [ ] Wartungsfenster geplant - [ ] Monitoring berücksichtigt --- **Checkliste Change-Typen** - [ ] Standard Change geeignet? - [ ] Normal Change erforderlich? - [ ] Emergency Change begründet? - [ ] Genehmigung vorhanden - [ ] Dokumentation aktuell - [ ] Verantwortlichkeiten bekannt - [ ] Nachbereitung geplant --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker bewerten und begleiten regelmäßig Änderungen. Typische Aufgaben: - Risiken einschätzen, - Auswirkungen analysieren, - Tests durchführen, - Rollback vorbereiten, - Monitoring überwachen, - Dokumentationen aktualisieren. Eine realistische Risikobewertung gehört zu den wichtigsten Voraussetzungen erfolgreicher Changes. --- **Zusammenfassung** > Änderungsbedarf erkennen > > ↓ > > Change-Typ bestimmen > > ↓ > > Risiken bewerten > > ↓ > > Business Impact analysieren > > ↓ > > Maßnahmen planen > > ↓ > > Genehmigung vorbereiten --- **Merksätze** > Nicht jede Änderung benötigt denselben Aufwand. > Standard Changes sind vorab genehmigt und risikoarm. > Normal Changes werden individuell bewertet. > Emergency Changes beschleunigen den Prozess – sie ersetzen ihn nicht. > Jede Risikobewertung sollte technische und geschäftliche Auswirkungen berücksichtigen. --- **Verwandte Seiten** - 13.1 Ziele und Grundlagen des Change Enablement - 13.3 Genehmigungen, CAB und Change-Kalender - 13.4 Umsetzung, Tests und Rollback - 13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring - Incident Management - Problem Management - Service Configuration Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Change-Typen und Verfahren zur Risikobewertung entsprechen den Empfehlungen der ITIL Practice „Change Enablement“. ITIL schreibt keine feste Risikomatrix oder konkrete Bewertungsmethode vor. Organisationen definieren diese entsprechend ihrer Geschäftsanforderungen und ihrer Risikobereitschaft. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 13.3 Genehmigungen, Change Authority, CAB und Change-Kalender > **Kurz erklärt** > > Nicht jede Änderung darf sofort umgesetzt werden. > > Abhängig vom Risiko, den Auswirkungen und der Bedeutung eines Changes müssen geeignete Personen oder Gremien über dessen Durchführung entscheiden. > > ITIL verwendet hierfür den Begriff **Change Authority**. > > Zusätzlich unterstützen ein **Change Advisory Board (CAB)** sowie ein **Change-Kalender** die koordinierte Planung und Durchführung von Änderungen. --- **Warum Genehmigungen notwendig sind** Änderungen können erhebliche Auswirkungen auf IT-Services haben. Beispiele: - Ausfall geschäftskritischer Systeme, - Sicherheitsprobleme, - Datenverlust, - Unterbrechung der Produktion, - Beeinträchtigung mehrerer Standorte. Deshalb sollte vor der Umsetzung geprüft werden, ob der erwartete Nutzen die möglichen Risiken rechtfertigt. --- **Was ist eine Change Authority?** Die **Change Authority** ist die Person oder Gruppe, die über einen Change entscheidet. ITIL schreibt **keine feste Rolle** vor. Je nach Organisation kann dies beispielsweise sein: - Teamleiter, - Service Owner, - Change Manager, - Fachbereich, - Projektleitung, - IT-Leitung. Die Entscheidung richtet sich nach Risiko und Auswirkungen des Changes. --- **Nicht jeder Change benötigt dieselbe Genehmigung** Ein Standard Change ist bereits vorab genehmigt. Ein Normal Change benötigt häufig eine individuelle Freigabe. Ein Emergency Change nutzt meist ein beschleunigtes Genehmigungsverfahren. Die Genehmigung sollte immer zum Risiko passen. --- **Genehmigungen nach Risiko** Ein mögliches Beispiel: | Risiko | Mögliche Change Authority | |---------|--------------------------| | gering | Teamleitung | | mittel | Change Manager | | hoch | Change Authority oder CAB | | sehr hoch | Management oder Geschäftsleitung | Die konkrete Zuordnung legt jede Organisation selbst fest. --- **Was ist ein Change Advisory Board (CAB)?** Ein **Change Advisory Board (CAB)** ist ein beratendes Gremium. Es unterstützt die Change Authority, indem es Änderungen bewertet und Empfehlungen ausspricht. Das CAB entscheidet **nicht automatisch selbst** über jeden Change. Die endgültige Entscheidung trifft die zuständige Change Authority. --- **Aufgaben des CAB** Das CAB unterstützt beispielsweise bei: - Risikobewertung, - Auswirkungsanalyse, - Terminplanung, - Ressourcenplanung, - Konflikterkennung, - Priorisierung, - Abstimmung zwischen Teams. Dadurch verbessert sich die Qualität von Entscheidungen. --- **Mögliche Teilnehmer eines CAB** Je nach Change können unterschiedliche Personen beteiligt sein. Beispiele: - Change Manager, - Service Owner, - Systemadministratoren, - Netzwerkadministratoren, - Information Security, - Fachbereiche, - Projektleitung, - Lieferanten. Nicht jeder Teilnehmer ist bei jedem Change erforderlich. --- **Emergency CAB (ECAB)** Für besonders dringende Änderungen kann ein **Emergency Change Advisory Board (ECAB)** eingesetzt werden. Es besteht meist aus wenigen entscheidungsbefugten Personen. Dadurch können dringende Entscheidungen schneller getroffen werden. Typische Situationen: - kritische Sicherheitslücke, - Produktionsausfall, - Ransomware-Angriff, - schwerwiegender Netzwerkausfall. --- **Der Change-Kalender** Ein Change-Kalender dokumentiert, wann geplante Änderungen stattfinden. Typische Informationen: - Termin, - betroffene Services, - Verantwortliche, - Wartungsfenster, - Status, - Risiko. Dadurch lassen sich Überschneidungen vermeiden. --- **Vorteile eines Change-Kalenders** Ein Change-Kalender hilft dabei, - Kollisionen zu vermeiden, - Wartungsfenster zu koordinieren, - Ressourcen besser zu planen, - betroffene Teams rechtzeitig zu informieren, - Risiken zu reduzieren. Er verbessert die Übersicht über geplante Änderungen. --- **Beispiel eines Change-Kalenders** | Datum | Service | Art des Changes | |--------|----------|-----------------| | 12.09. | VPN | Softwareupdate | | 13.09. | ERP | Datenbankupdate | | 14.09. | Firewall | Firmwareupdate | | 15.09. | WLAN | Controller-Aktualisierung | So erkennen Administratoren frühzeitig mögliche Konflikte. --- **Warum Terminüberschneidungen problematisch sind** Werden mehrere kritische Änderungen gleichzeitig durchgeführt, kann dies zu Problemen führen. Beispiel: - Firewall-Update, - Core-Switch-Austausch, - Storage-Migration am selben Abend. Bei einer Störung wird die Ursachenanalyse deutlich erschwert. Der Change-Kalender hilft, solche Situationen zu vermeiden. --- **Wartungsfenster** Viele Changes werden innerhalb geplanter Wartungsfenster durchgeführt. Typische Vorteile: - geringere Auswirkungen auf Benutzer, - besser planbare Arbeiten, - ausreichende Zeit für Rollback, - koordinierte Kommunikation. Wartungsfenster sollten frühzeitig angekündigt werden. --- **Kommunikation vor einem Change** Vor größeren Änderungen sollten relevante Personen informiert werden. Beispiele: - Benutzer, - Service Desk, - Administratoren, - Management, - externe Dienstleister. Die Information sollte unter anderem enthalten: - Zeitpunkt, - betroffene Services, - erwartete Auswirkungen, - Ansprechpartner. --- **Dokumentation der Genehmigung** Jede Genehmigung sollte nachvollziehbar dokumentiert werden. Beispiele: - wer genehmigt hat, - Zeitpunkt, - Risiko, - Bedingungen, - besondere Auflagen. Dadurch bleiben Entscheidungen transparent. --- **Praxisbeispiel** Ein Unternehmen plant, die Firmware aller Core-Switches zu aktualisieren. Die Risikobewertung ergibt: - hoher Business Impact, - mehrere Standorte betroffen. Der Change wird: - im CAB besprochen, - in den Change-Kalender eingetragen, - für ein Wartungsfenster am Wochenende geplant. Alle betroffenen Fachbereiche werden vorab informiert. --- **Typische Fehler** **Fehler 1** Änderungen werden ohne Genehmigung durchgeführt. --- **Fehler 2** Der Change-Kalender wird nicht gepflegt. --- **Fehler 3** Mehrere kritische Changes finden gleichzeitig statt. --- **Fehler 4** Das falsche Entscheidungsgremium wird beteiligt. --- **Fehler 5** Emergency Changes werden nicht dokumentiert. --- **Fehler 6** Benutzer werden nicht informiert. --- **Fehler 7** Genehmigungen sind nicht nachvollziehbar. --- **Fehler 8** Wartungsfenster werden nicht eingehalten. --- **Fehler 9** Externe Dienstleister werden zu spät eingebunden. --- **Fehler 10** CAB-Sitzungen beschäftigen sich mit Standard Changes, die bereits vorab genehmigt sind. --- **Checkliste Genehmigung** - [ ] Change-Typ bestimmt - [ ] Risiko bewertet - [ ] Change Authority festgelegt - [ ] Genehmigung dokumentiert - [ ] Verantwortlichkeiten bekannt - [ ] Bedingungen berücksichtigt - [ ] Kommunikation geplant - [ ] Umsetzung freigegeben --- **Checkliste Change-Kalender** - [ ] Termin eingetragen - [ ] Wartungsfenster abgestimmt - [ ] Überschneidungen geprüft - [ ] betroffene Services dokumentiert - [ ] Verantwortliche bekannt - [ ] Benutzer informiert - [ ] Rollback berücksichtigt - [ ] Monitoring vorbereitet --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker sind häufig an der Vorbereitung und Umsetzung von Changes beteiligt. Typische Aufgaben: - Risiken einschätzen, - technische Informationen bereitstellen, - Wartungsfenster abstimmen, - Change-Kalender pflegen, - Änderungen dokumentieren, - Benutzer informieren, - Monitoring nach dem Change überwachen. Sie liefern wichtige Entscheidungsgrundlagen für die Change Authority. --- **Zusammenfassung** > Change planen > > ↓ > > Risiko bewerten > > ↓ > > Change Authority bestimmen > > ↓ > > Genehmigung einholen > > ↓ > > Change-Kalender aktualisieren > > ↓ > > Beteiligte informieren > > ↓ > > Umsetzung vorbereiten --- **Merksätze** > Die Change Authority entscheidet über einen Change. > Das CAB unterstützt die Entscheidung – es ersetzt sie nicht. > Standard Changes benötigen normalerweise keine erneute Genehmigung. > Ein gepflegter Change-Kalender verhindert Konflikte zwischen Änderungen. > Gute Kommunikation reduziert Risiken und Überraschungen. --- **Verwandte Seiten** - 13.1 Ziele und Grundlagen des Change Enablement - 13.2 Change-Typen und Risikobewertung - 13.4 Umsetzung, Tests und Rollback - 13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring - Service Configuration Management - Incident Management - Monitoring and Event Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Einordnung** ITIL verwendet den Begriff **Change Authority** für die Person oder Gruppe, die einen Change genehmigt. Ein **Change Advisory Board (CAB)** besitzt in ITIL eine beratende Funktion und unterstützt die Entscheidungsfindung. Der Einsatz eines CAB, eines Emergency CAB (ECAB) und eines Change-Kalenders richtet sich nach Größe, Komplexität und Risiko der jeweiligen Organisation. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 13.4 Umsetzung, Tests und Rollback > **Kurz erklärt** > > Nach der Genehmigung beginnt die eigentliche Umsetzung eines Changes. > > Ziel ist es, Änderungen kontrolliert, nachvollziehbar und mit möglichst geringem Risiko einzuführen. > > Dazu gehören insbesondere sorgfältige Tests, eine geplante Durchführung, eine Überprüfung des Ergebnisses sowie ein vorbereiteter Rollback für den Fall unerwarteter Probleme. --- **Warum Tests wichtig sind** Auch sorgfältig geplante Änderungen können unerwartete Auswirkungen haben. Beispiele: - Anwendungen starten nicht mehr, - Benutzer können sich nicht anmelden, - Netzwerkverbindungen funktionieren nicht, - Zertifikate werden nicht akzeptiert, - Datenbanken reagieren langsamer. Tests helfen, solche Probleme möglichst früh zu erkennen. --- **Testumgebungen** Änderungen sollten nach Möglichkeit zuerst in einer Testumgebung geprüft werden. Typische Umgebungen: - Entwicklungsumgebung (Development) - Testumgebung (Test) - Integrationsumgebung - Staging - Produktivsystem Je ähnlicher die Testumgebung der Produktivumgebung ist, desto aussagekräftiger sind die Testergebnisse. --- **Warum nicht direkt in der Produktion testen?** Tests im Produktivsystem können zu: - Serviceunterbrechungen, - Datenverlust, - Sicherheitsproblemen, - unerwarteten Ausfällen führen. Deshalb sollten Änderungen möglichst vorab getestet werden. --- **Arten von Tests** Je nach Change können unterschiedliche Tests erforderlich sein. Beispiele: - Funktionstest, - Integrationstest, - Lasttest, - Sicherheitstest, - Regressionstest, - Benutzertest, - Wiederherstellungstest. Nicht jeder Change benötigt alle Testarten. --- **Funktionstest** Beim Funktionstest wird geprüft, ob die neue oder geänderte Funktion wie vorgesehen arbeitet. Beispiel: Nach einer VPN-Aktualisierung wird getestet, ob sich Benutzer erfolgreich verbinden können. --- **Regressionstest** Ein Regressionstest überprüft, ob bestehende Funktionen nach einer Änderung weiterhin ordnungsgemäß arbeiten. Beispiel: Nach einem Datenbankupdate funktionieren weiterhin: - Anmeldung, - Berichtswesen, - Druckfunktionen, - API-Schnittstellen. Regressionstests verhindern unbeabsichtigte Nebenwirkungen. --- **Pilotbetrieb** Bei größeren Änderungen erfolgt häufig zunächst ein Pilotbetrieb. Dabei wird die Änderung nur für einen kleinen Benutzerkreis eingeführt. Vorteile: - geringeres Risiko, - frühes Feedback, - Fehler lassen sich leichter erkennen, - Auswirkungen bleiben begrenzt. Nach erfolgreichem Pilotbetrieb erfolgt die Einführung für alle Benutzer. --- **Wartungsfenster** Produktive Änderungen werden häufig innerhalb geplanter Wartungsfenster umgesetzt. Vorteile: - geringere Auswirkungen, - ausreichende Zeit für Tests, - genügend Zeit für Rollback, - bessere Planbarkeit. Größere Änderungen erfolgen häufig außerhalb der Hauptarbeitszeiten. --- **Durchführung des Changes** Während der Umsetzung sollten alle Schritte dokumentiert werden. Typische Inhalte: - Beginn, - durchgeführte Arbeiten, - Besonderheiten, - Testergebnisse, - Abweichungen, - Abschlusszeit. Eine vollständige Dokumentation erleichtert spätere Analysen. --- **Monitoring nach der Umsetzung** Nach Abschluss überwacht das Monitoring, ob der Service ordnungsgemäß arbeitet. Beispiele: - Erreichbarkeit, - CPU-Auslastung, - Speicherverbrauch, - Fehlermeldungen, - Antwortzeiten, - Netzwerkstatus. Monitoring bestätigt den Erfolg des Changes. --- **Was ist ein Rollback?** Ein Rollback stellt den vorherigen Zustand wieder her, wenn der Change nicht erfolgreich war. Das Ziel besteht darin, die Auswirkungen eines fehlgeschlagenen Changes möglichst gering zu halten. --- **Wann wird ein Rollback durchgeführt?** Beispiele: - kritische Anwendungen funktionieren nicht, - Service ist nicht verfügbar, - Sicherheitsprobleme entstehen, - Performance verschlechtert sich erheblich, - unerwartete Fehler treten auf. Nicht jeder Fehler führt sofort zu einem Rollback. Die Entscheidung richtet sich nach Risiko und Auswirkungen. --- **Rollback-Plan** Ein Rollback sollte bereits vor Beginn des Changes vorbereitet werden. Typische Inhalte: - Auslösekriterien, - Verantwortliche, - Reihenfolge der Schritte, - Wiederherstellung aus Backup, - Zeitbedarf, - Kommunikation. Ein Rollback darf nicht erst während einer Störung geplant werden. --- **Beispiel eines Rollbacks** ```text Neues Update installieren │ ▼ Tests erfolgreich? │ ┌────┴────┐ │ │ Ja Nein │ │ ▼ ▼ Produktiv Rollback weiter durchführen ``` Ein klar definierter Ablauf verkürzt die Wiederherstellungszeit. --- **Backups vor einem Change** Vor vielen Änderungen wird ein Backup erstellt. Beispiele: - virtuelle Maschine, - Datenbank, - Konfiguration, - Firewall, - Netzwerkgerät, - Active Directory. Backups erleichtern den Rollback erheblich. --- **Verifizierung** Nach erfolgreicher Umsetzung wird geprüft, ob der Change tatsächlich erfolgreich war. Typische Fragen: - Funktioniert der Service? - Sind alle Tests erfolgreich? - Gibt es Fehlermeldungen? - Ist das Monitoring unauffällig? - Wurde die Dokumentation aktualisiert? Erst danach gilt der Change als abgeschlossen. --- **Post Implementation Review (PIR)** Nach größeren Änderungen wird häufig ein **Post Implementation Review (PIR)** durchgeführt. Dabei wird bewertet: - Wurde das Ziel erreicht? - Gab es Probleme? - War die Planung ausreichend? - Hat der Rollback funktioniert? - Welche Verbesserungen sind möglich? Der PIR dient der kontinuierlichen Verbesserung zukünftiger Changes. --- **Dokumentation aktualisieren** Nach erfolgreichem Change sollten unter anderem aktualisiert werden: - CMDB, - Netzpläne, - Runbooks, - Architekturdiagramme, - Knowledge Base, - Betriebshandbücher. Dadurch bleiben Informationen aktuell. --- **Praxisbeispiel** Ein Unternehmen aktualisiert seine zentrale Firewall. Vorher: - Backup erstellt, - Rollback vorbereitet, - Testplan erstellt. Nach der Aktualisierung: - Funktionstest erfolgreich, - Monitoring ohne Auffälligkeiten, - VPN-Verbindungen geprüft, - Dokumentation aktualisiert. Der Change wird anschließend erfolgreich abgeschlossen. --- **Typische Fehler** **Fehler 1** Änderungen werden direkt produktiv getestet. --- **Fehler 2** Es existiert kein Rollback. --- **Fehler 3** Backups fehlen. --- **Fehler 4** Monitoring überprüft den Change nicht. --- **Fehler 5** Regressionstests werden ausgelassen. --- **Fehler 6** Dokumentationen werden nicht aktualisiert. --- **Fehler 7** Benutzer werden nicht informiert. --- **Fehler 8** Der Change wird zu früh abgeschlossen. --- **Fehler 9** Erfahrungen werden nicht ausgewertet. --- **Fehler 10** Testumgebung unterscheidet sich stark von der Produktivumgebung. --- **Checkliste Umsetzung** - [ ] Genehmigung vorhanden - [ ] Testumgebung vorbereitet - [ ] Wartungsfenster aktiv - [ ] Monitoring eingerichtet - [ ] Verantwortlichkeiten bekannt - [ ] Dokumentation vorbereitet - [ ] Kommunikation erfolgt - [ ] Durchführung protokolliert --- **Checkliste Rollback** - [ ] Rollback definiert - [ ] Backup vorhanden - [ ] Verantwortliche benannt - [ ] Zeitbedarf bekannt - [ ] Wiederherstellung getestet - [ ] Monitoring berücksichtigt - [ ] Dokumentation vorhanden - [ ] Auslösekriterien definiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker setzen die meisten Changes praktisch um. Typische Aufgaben: - Testsysteme vorbereiten, - Backups erstellen, - Änderungen durchführen, - Monitoring überwachen, - Funktionstests durchführen, - Rollback vorbereiten, - Dokumentationen aktualisieren, - Erfahrungen für zukünftige Changes festhalten. Eine sorgfältige Umsetzung entscheidet häufig über den Erfolg eines Changes. --- **Zusammenfassung** > Genehmigung erhalten > > ↓ > > Tests durchführen > > ↓ > > Backup erstellen > > ↓ > > Change umsetzen > > ↓ > > Monitoring überprüfen > > ↓ > > Bei Bedarf Rollback durchführen > > ↓ > > Dokumentation aktualisieren > > ↓ > > Post Implementation Review durchführen --- **Merksätze** > Änderungen sollten möglichst nicht direkt in der Produktivumgebung getestet werden. > Ein Rollback muss vor Beginn des Changes geplant sein. > Monitoring bestätigt den Erfolg einer Änderung. > Dokumentationen gehören zum Abschluss jedes Changes. > Erfahrungen aus abgeschlossenen Changes verbessern zukünftige Änderungen. --- **Verwandte Seiten** - 13.1 Ziele und Grundlagen des Change Enablement - 13.2 Change-Typen und Risikobewertung - 13.3 Genehmigungen, Change Authority, CAB und Change-Kalender - 13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring - Service Configuration Management - Monitoring and Event Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Einordnung** Die beschriebenen Vorgehensweisen zu Tests, Rollback, Monitoring und Post Implementation Review orientieren sich an den Empfehlungen der ITIL Practice „Change Enablement“. ITIL schreibt keine festen Testverfahren vor, empfiehlt jedoch ausdrücklich eine risikoorientierte Planung, geeignete Testmaßnahmen und eine nachvollziehbare Nachbereitung von Änderungen. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring > **Kurz erklärt** > > Change Enablement arbeitet eng mit vielen anderen ITIL Practices zusammen. > > Änderungen entstehen häufig aus Incidents oder Problems, beeinflussen Configuration Items und werden durch Monitoring überwacht. > > Erst das Zusammenspiel dieser Practices ermöglicht sichere Änderungen, stabile IT-Services und eine kontinuierliche Verbesserung der gesamten IT-Landschaft. --- **Warum das Zusammenspiel wichtig ist** Ein Change wird selten isoliert durchgeführt. Vor einer Änderung müssen beispielsweise folgende Fragen beantwortet werden: - Warum ist die Änderung notwendig? - Welche Services sind betroffen? - Welche Configuration Items werden verändert? - Welche Risiken bestehen? - Wie wird der Erfolg überprüft? Diese Informationen stammen aus verschiedenen ITIL Practices. --- **Zusammenspiel der Practices** ```text Incident │ ▼ Problem │ ▼ Change Enablement │ ▼ Service Configuration Management │ ▼ Monitoring │ ▼ Continual Improvement ``` Jede Practice liefert wichtige Informationen für die nächste. --- **Change Enablement und Incident Management** Viele Changes entstehen als Folge eines Incidents. Beispiel: Ein Server fällt regelmäßig aus. Incident Management stellt den Betrieb zunächst wieder her. Die eigentliche Ursache bleibt jedoch bestehen. Zur dauerhaften Lösung wird ein Change geplant. Incident Management arbeitet also häufig kurzfristig, während Change Enablement eine nachhaltige Verbesserung ermöglicht. --- **Beispiel** ```text Serverausfall │ ▼ Incident Management │ ▼ Service wiederhergestellt │ ▼ Hardware ersetzen │ ▼ Change Enablement ``` Der Incident endet mit der Wiederherstellung, der Change beseitigt anschließend die eigentliche Ursache. --- **Change Enablement und Problem Management** Problem Management untersucht, warum Incidents wiederholt auftreten. Wird eine dauerhafte Lösung gefunden, führt diese häufig zu einem Change. Beispiele: - Software aktualisieren, - Hardware austauschen, - Netzwerk erweitern, - Architektur ändern. Problem Management liefert also häufig den Anlass für einen Change. --- **Known Errors** Ein Known Error kann eine empfohlene Änderung enthalten. Beispiel: Bekannter Fehler: Firmware-Version 5.2 verursacht Abstürze. Empfohlene Lösung: Firmware-Version 5.3 installieren. Die eigentliche Umsetzung erfolgt anschließend über Change Enablement. --- **Change Enablement und Service Configuration Management** Vor jeder Änderung muss bekannt sein, welche Configuration Items betroffen sind. Die CMDB liefert beispielsweise: - betroffene Server, - Anwendungen, - Datenbanken, - Netzwerke, - Verantwortliche, - Beziehungen. Dadurch können Auswirkungen besser bewertet werden. --- **Impact Analysis** Vor einem Change wird häufig geprüft, welche Services betroffen sind. Beispiel: ```text Firewall │ ├── VPN ├── Internet ├── VoIP └── E-Mail ``` Ein Firmware-Update betrifft somit mehrere Services. Diese Information stammt aus der CMDB. --- **CMDB aktualisieren** Nach erfolgreicher Umsetzung werden unter anderem aktualisiert: - Versionen, - Status, - Beziehungen, - Dokumentationen, - Verantwortlichkeiten. Dadurch bleibt die Configuration-Datenbasis aktuell. --- **Change Enablement und Monitoring** Monitoring überwacht, ob Änderungen erfolgreich umgesetzt wurden. Beispiele: - Server erreichbar, - CPU normal, - Speicher ausreichend, - Netzwerk stabil, - keine neuen Alarme, - Services verfügbar. Monitoring bestätigt somit den Erfolg eines Changes. --- **Monitoring vor einem Change** Auch vor einer Änderung liefert Monitoring wichtige Informationen. Beispiele: - aktuelle Auslastung, - bekannte Fehler, - bestehende Alarme, - Performance, - Verfügbarkeit. Diese Informationen unterstützen die Risikobewertung. --- **Monitoring nach einem Change** Nach der Umsetzung werden häufig überprüft: - Erreichbarkeit, - Antwortzeiten, - Fehlermeldungen, - Auslastung, - Benutzeranmeldungen, - Dienste. Erst wenn diese Prüfungen erfolgreich sind, gilt der Change als abgeschlossen. --- **Change Enablement und Release Management** Ein Release kann mehrere Changes enthalten. Beispiel: Ein Software-Release umfasst: - neue Funktionen, - Fehlerbehebungen, - Sicherheitsupdates, - Konfigurationsänderungen. Change Enablement bewertet und genehmigt die Änderungen, Release Management plant und verteilt das Gesamtpaket. --- **Change Enablement und Deployment Management** Nach der Genehmigung erfolgt häufig die technische Bereitstellung. Deployment Management übernimmt beispielsweise: - Software verteilen, - Container aktualisieren, - Images bereitstellen, - Anwendungen installieren. Change Enablement steuert den organisatorischen Rahmen, Deployment Management die technische Umsetzung. --- **Change Enablement und Information Security Management** Viele Changes dienen der Verbesserung der Sicherheit. Beispiele: - Sicherheitsupdates, - Firewallregeln, - MFA einführen, - Zertifikate erneuern, - Verschlüsselung aktivieren. Dabei müssen Sicherheitsanforderungen und Serviceverfügbarkeit gleichermaßen berücksichtigt werden. --- **Change Enablement und Continual Improvement** Erfahrungen aus abgeschlossenen Changes fließen in Continual Improvement ein. Beispiele: - Planung verbessern, - Testverfahren erweitern, - Dokumentation optimieren, - Genehmigungen vereinfachen, - Standard Changes definieren. Dadurch entwickelt sich der Change-Prozess kontinuierlich weiter. --- **Praxisbeispiel** Ein Unternehmen stellt fest, dass nach jedem Betriebssystemupdate ähnliche Probleme auftreten. Problem Management analysiert die Ursache. Es zeigt sich, dass wichtige Regressionstests fehlen. Change Enablement ergänzt daraufhin den Testplan. Monitoring bestätigt, dass zukünftige Updates deutlich störungsärmer verlaufen. Die neue Vorgehensweise wird anschließend als Standardprozess dokumentiert. --- **Typische Fehler** **Fehler 1** Changes werden unabhängig von Incidents geplant. --- **Fehler 2** Configuration Items werden nicht aktualisiert. --- **Fehler 3** Monitoring überprüft Änderungen nicht. --- **Fehler 4** Problem Management wird nicht einbezogen. --- **Fehler 5** Release und Change werden verwechselt. --- **Fehler 6** Deployment erfolgt ohne Genehmigung. --- **Fehler 7** Auswirkungen auf andere Services werden unterschätzt. --- **Fehler 8** Erfahrungen aus früheren Changes werden nicht genutzt. --- **Fehler 9** CMDB und Monitoring liefern widersprüchliche Informationen. --- **Fehler 10** Verbesserungsmaßnahmen werden nicht dokumentiert. --- **Checkliste Zusammenspiel** - [ ] Incident analysiert - [ ] Problem bewertet - [ ] Change genehmigt - [ ] Configuration Items geprüft - [ ] Monitoring vorbereitet - [ ] Dokumentation aktualisiert - [ ] Erfolg überprüft - [ ] Verbesserungen dokumentiert --- **Checkliste erfolgreicher Change** - [ ] Risiko bewertet - [ ] Tests erfolgreich - [ ] Rollback vorbereitet - [ ] Monitoring aktiv - [ ] CMDB aktualisiert - [ ] Benutzer informiert - [ ] Post Implementation Review durchgeführt - [ ] Lessons Learned dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker begleiten nahezu den gesamten Lebenszyklus eines Changes. Typische Aufgaben: - Incidents analysieren, - Ursachen dokumentieren, - Configuration-Daten pflegen, - Monitoring überwachen, - Änderungen durchführen, - Rollback vorbereiten, - Dokumentationen aktualisieren, - Verbesserungen ableiten. Dadurch leisten sie einen wesentlichen Beitrag zu einem sicheren und stabilen IT-Betrieb. --- **Zusammenfassung** > Incident erkennen > > ↓ > > Ursache analysieren > > ↓ > > Change planen > > ↓ > > Auswirkungen bewerten > > ↓ > > Änderung umsetzen > > ↓ > > Monitoring prüfen > > ↓ > > CMDB aktualisieren > > ↓ > > Verbesserungen übernehmen --- **Merksätze** > Viele Changes entstehen aus Incidents oder Problems. > Die CMDB liefert die Grundlage für Impact-Analysen. > Monitoring bestätigt den Erfolg eines Changes. > Deployment setzt Änderungen technisch um – Change Enablement steuert sie organisatorisch. > Erfahrungen aus abgeschlossenen Changes verbessern zukünftige Änderungen. --- **Verwandte Seiten** - 13.1 Ziele und Grundlagen des Change Enablement - 13.2 Change-Typen und Risikobewertung - 13.3 Genehmigungen, Change Authority, CAB und Change-Kalender - 13.4 Umsetzung, Tests und Rollback - Incident Management - Problem Management - Service Configuration Management - Monitoring and Event Management - Release Management - Deployment Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Monitoring and Event Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Change Enablement koordiniert Änderungen organisatorisch und arbeitet dabei eng mit Incident Management, Problem Management, Service Configuration Management, Monitoring sowie weiteren Practices wie Release und Deployment Management zusammen. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026