# 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