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: neues Produkt auswählen bestehende Daten vollständig verwerfen neue Kategorien entwerfen 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: Testumgebung verwenden begrenzte Pilotgruppe auswählen technische und servicebezogene Ergebnisse prüfen Rückmeldungen auswerten Konfiguration anpassen kontrolliert auf weitere Systeme ausweiten 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: Outcome und Zweck verstehen aktuellen Ablauf erfassen unnötige Schritte entfernen Übergaben und Abhängigkeiten verbessern Ablauf vereinheitlichen geeignete Tätigkeiten automatisieren Ergebnisse überwachen 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: Wert: Welches Outcome soll erreicht werden? Ausgangslage: Was ist bereits vorhanden und funktionsfähig? Schritte: Kann kontrolliert und iterativ vorgegangen werden? Zusammenarbeit: Wer muss beteiligt und informiert werden? Gesamtsicht: Welche Abhängigkeiten und Auswirkungen bestehen? Einfachheit: Welche Schritte sind tatsächlich erforderlich? 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 ITIL: ITIL Foundation – Version 5 ITIL: ITIL Foundation Version 5 – What’s New? ITIL: New ITIL Explained for Certified Professionals PeopleCert: ITIL 4 Foundation ITIL: AI-Enabled Service Management 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