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

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

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

Revision #1
Created 1 August 2026 21:38:23 by Admin
Updated 1 August 2026 21:38:36 by Admin