Übersicht [Dimensionen]
1
❌
Vier
✅
Drei
❌
Fünf
❌
Sechs
Es sind vier Dimensionen: Organisationen & Menschen, Partner & Lieferanten, Informationen & Technologie, Wertströme & Prozesse.
Organisationen und Menschen [Dimensionen]
1
❌
Organisationsstruktur, Rollen, Kultur und Kompetenzen
✅
Ausschließlich das Organigramm
❌
Nur die eingesetzte Software
❌
Nur die vertraglichen Vereinbarungen mit Lieferanten
Strukturen, Rollen, Kultur und Kompetenzen der beteiligten Menschen.
Informationen und Technologie [Dimensionen]
1
❌
Die genutzten Informationen/Daten sowie die eingesetzten Technologien
✅
Ausschließlich die Hardware-Ausstattung
❌
Nur externe Datenschutzvorgaben
❌
Die Kommunikationskultur im Team
Wissen/Daten und die eingesetzten Technologien inkl. deren Beziehungen zueinander.
Partner und Lieferanten [Dimensionen]
1
❌
Beziehungen zu externen Organisationen, die an Wertschöpfung beteiligt sind (z.B. Sourcing, Verträge)
✅
Ausschließlich interne Teamstrukturen
❌
Nur die technische Infrastruktur
❌
Kundenzufriedenheitsbefragungen
Um Beziehungen zu anderen Organisationen, die an Design, Entwicklung, Bereitstellung etc. beteiligt sind.
Wertströme und Prozesse [Dimensionen]
1
❌
Wie Aktivitäten, Workflows und Verfahren organisationsweit zusammenwirken
✅
Ausschließlich die IT-Prozesslandschaft
❌
Die Vertragsbedingungen mit Lieferanten
❌
Die physische Büroausstattung
Wie die verschiedenen Teile der Organisation zusammenarbeiten, um Aktivitäten, Workflows, Kontrollen und Verfahren umzusetzen.
Externe Faktoren [Dimensionen]
1
❌
PESTLE (politisch, wirtschaftlich, sozial, technologisch, rechtlich, ökologisch)
✅
SWOT ausschließlich
❌
Nur das Betriebsklima
❌
RACI-Matrix
PESTLE (politisch, wirtschaftlich, sozial, technologisch, rechtlich, umweltbezogen) ist das gängige Analysemodell.
Ganzheitliche Betrachtung [Dimensionen]
1
❌
Weil Ungleichgewichte in einer Dimension die anderen negativ beeinflussen können
✅
Weil nur eine Dimension pro Projekt relevant ist
❌
Weil die Dimensionen sich gegenseitig ausschließen
❌
Weil ITIL Prozesse generell ablehnt
Ein Ungleichgewicht in einer Dimension kann die anderen beeinträchtigen — ganzheitliche Balance ist nötig.
Beispiel Partner & Lieferanten [Dimensionen]
1
❌
Partner und Lieferanten
✅
Informationen und Technologie
❌
Wertströme und Prozesse
❌
Organisationen und Menschen
Auslagerung/Sourcing betrifft primär die Dimension Partner und Lieferanten.
Beispiel Organisationen & Menschen [Dimensionen]
1
❌
Organisationen und Menschen
✅
Informationen und Technologie
❌
Wertströme und Prozesse
❌
Partner und Lieferanten
Kompetenzentwicklung und Rollen fallen unter Organisationen und Menschen.
Zusammenspiel der Dimensionen [Dimensionen]
1
❌
Es entsteht ein Ungleichgewicht, das die Wertschöpfung insgesamt gefährden kann
✅
Das ist unproblematisch, da Dimensionen unabhängig voneinander sind
❌
Die Technologie-Dimension gleicht das automatisch aus
❌
Das betrifft ausschließlich die Lieferanten-Dimension
Das zeigt exemplarisch, wie ein Ungleichgewicht zwischen Dimensionen den Erfolg gefährdet.
Zuordnung Dimensionen [Dimensionen]
1
❌
Wertströme und Prozesse betreffen, wie Aktivitäten zusammenwirken
✅
Partner und Lieferanten betreffen externe, an der Wertschöpfung beteiligte Organisationen
✅
Informationen und Technologie betreffen ausschließlich Hardware-Kauf
❌
Organisationen und Menschen betreffen Struktur, Rollen und Kultur
PESTLE-Anwendung [Dimensionen]
1
Musterantwort: z.B. Rechtlich: neue Datenschutzgesetze beeinflussen die Dimension Informationen und Technologie. Wirtschaftlich: eine Rezession kann Budgetkürzungen erzwingen, die Partner- und Lieferantenbeziehungen (Dimension Partner und Lieferanten) betreffen.
Dimensionen im Alltag [Dimensionen]
1
Musterantwort: Individuelle Antwort — sollte alle vier Dimensionen konkret benennen und ihr Zusammenspiel erklären, nicht nur eine isoliert betrachten.
Kompetenzen [Dimensionen]
1
❌
Organisationen und Menschen
✅
Informationen und Technologie
❌
Partner und Lieferanten
❌
Wertströme und Prozesse
Kompetenzaufbau ist Teil der Dimension Organisationen und Menschen.
Sourcing-Strategie [Dimensionen]
1
❌
Partner und Lieferanten
✅
Organisationen und Menschen
❌
Wertströme und Prozesse
❌
Informationen und Technologie
Sourcing-Entscheidungen betreffen primär Partner und Lieferanten.
Datenqualität [Dimensionen]
1
❌
Informationen und Technologie
✅
Organisationen und Menschen
❌
Partner und Lieferanten
❌
Wertströme und Prozesse
Daten und Informationen sind Kern der Dimension Informationen und Technologie.
Kontrollen und Workflows [Dimensionen]
1
❌
Wertströme und Prozesse
✅
Informationen und Technologie
❌
Partner und Lieferanten
❌
Organisationen und Menschen
Wertströme und Prozesse befassen sich mit Workflows, Kontrollen und Verfahren.
Vertragsgestaltung [Dimensionen]
1
❌
Partner und Lieferanten
✅
Wertströme und Prozesse
❌
Organisationen und Menschen
❌
Informationen und Technologie
Verträge mit externen Anbietern fallen unter Partner und Lieferanten.
Technologische Einflussfaktoren [Dimensionen]
1
❌
Technologisch
✅
Politisch
❌
Sozial
❌
Rechtlich
Der technologische Faktor (T in PESTLE) betrifft direkt Technologieentscheidungen.
Kulturwandel [Dimensionen]
1
❌
Organisationen und Menschen
✅
Wertströme und Prozesse
❌
Informationen und Technologie
❌
Partner und Lieferanten
Kulturfragen fallen unter Organisationen und Menschen.
Balance der Dimensionen [Dimensionen]
1
❌
Weil die Dimensionen zusammenwirken und einseitige Optimierung den Gesamterfolg gefährden kann
✅
Weil ITIL nur eine einzige Dimension als relevant ansieht
❌
Weil alle vier Dimensionen ohnehin identisch sind
❌
Weil Optimierung grundsätzlich unerwünscht ist
Weil die Dimensionen zusammenwirken — Optimierung einer einzelnen Dimension kann andere vernachlässigen und den Gesamterfolg gefährden.
4 Dimensionen korrekt benennen [Dimensionen]
1
❌
Organisationen und Menschen
✅
Informationen und Technologie
✅
Partner und Lieferanten
✅
Wertströme und Prozesse
Externe Faktoren im eigenen Unternehmen [Dimensionen]
1
Musterantwort: Individuelle Antwort — z.B. politisch: neue Exportregelungen beeinflussen Partner und Lieferanten. Sozial: veränderte Erwartungen an Homeoffice beeinflussen Organisationen und Menschen.
Komponenten Übersicht [Value System]
1
❌
Governance, Grundprinzipien, Practices und Continual Improvement
✅
Ausschließlich die 34 Management-Practices
❌
Nur Governance und Kostenmanagement
❌
Ausschließlich der Produktlebenszyklus
Governance, Grundprinzipien, Practices und Continual Improvement wirken im Value System zusammen.
Grundprinzip: Fokus auf Wert [Value System]
1
❌
Jede Aktivität sollte sich am Wert für die relevanten Stakeholder orientieren
✅
Ausschließlich der Aktienkurs zählt
❌
Nur der IT-interne Nutzen ist relevant
❌
Kosten sind grundsätzlich zweitrangig
Alle Aktivitäten sollen sich direkt oder indirekt am Wert für Stakeholder orientieren.
Grundprinzip: Dort anfangen, wo man steht [Value System]
1
❌
Bestehendes bewerten und sinnvoll weiternutzen, statt grundlos neu zu beginnen
✅
Immer bei null anfangen, unabhängig vom Ist-Zustand
❌
Nur neue Mitarbeitende dürfen Prozesse gestalten
❌
Historische Daten grundsätzlich verwerfen
Bestehende Strukturen/Prozesse nutzen und bewerten, statt grundlos alles neu aufzubauen.
Grundprinzip: Iterativ mit Feedback [Value System]
1
❌
In kleinen, überschaubaren Schritten vorgehen und regelmäßig Feedback einholen
✅
Große Änderungen ausschließlich in einem einzigen Schritt umsetzen
❌
Feedback erst nach vollständigem Projektabschluss einholen
❌
Iterationen nur bei Softwareprojekten anwenden
In überschaubaren Schritten vorgehen und regelmäßig Feedback einholen statt alles auf einmal umzusetzen.
Grundprinzip: Zusammenarbeit und Sichtbarkeit [Value System]
1
❌
Relevante Beteiligte einbinden und Arbeit/Ergebnisse transparent sichtbar machen
✅
Ausschließlich das Management informieren
❌
Zusammenarbeit auf die IT-Abteilung beschränken
❌
Informationen grundsätzlich vertraulich halten
Beteiligte einbeziehen und Arbeit/Fortschritt für Betroffene sichtbar machen.
Grundprinzip: Ganzheitlich denken und arbeiten [Value System]
1
❌
Ergebnisse als Zusammenspiel des Gesamtsystems betrachten statt isolierte Teile
✅
Sich ausschließlich auf ein einzelnes Team konzentrieren
❌
Abteilungsübergreifende Zusammenarbeit vermeiden
❌
Nur technische Aspekte berücksichtigen
Ergebnisse aus der Perspektive des gesamten Systems statt isolierter Einzelteile betrachten.
Grundprinzip: Einfach und praktikabel [Value System]
1
❌
Den einfachsten praktikablen Weg zum Ziel wählen, unnötige Komplexität vermeiden
✅
Immer die technisch komplexeste Lösung wählen
❌
Dokumentation grundsätzlich weglassen
❌
Nur für kleine Organisationen relevant
Den einfachsten Weg wählen, der das Ziel erreicht — unnötige Komplexität vermeiden.
Grundprinzip: Optimieren und automatisieren [Value System]
2
❌
Erst optimieren, dann automatisieren
✅
Erst automatisieren, Optimierung ist danach unnötig
❌
Beides gleichzeitig, Reihenfolge spielt keine Rolle
❌
Automatisierung ersetzt grundsätzlich Optimierung
Erst optimieren, dann automatisieren — sonst werden ineffiziente Abläufe nur schneller ausgeführt.
❌
Erst optimieren, dann automatisieren
✅
Erst automatisieren, Optimierung ist danach unnötig
❌
Beides gleichzeitig, Reihenfolge spielt keine Rolle
❌
Automatisierung ersetzt grundsätzlich Optimierung
Erst optimieren, dann automatisieren — sonst werden ineffiziente Abläufe nur schneller ausgeführt.
Anzahl Grundprinzipien [Value System]
2
❌
Sieben
✅
Vier
❌
Fünf
❌
Neun
Sieben Grundprinzipien.
❌
Sieben
✅
Vier
❌
Fünf
❌
Neun
Sieben Grundprinzipien.
Governance [Value System]
2
❌
Evaluate, Direct, Monitor — bewerten, ausrichten, überwachen
✅
Planen, Bauen, Betreiben
❌
Design, Build, Run
❌
Kaufen, Verkaufen, Prüfen
Evaluate, Direct, Monitor (EDM) — bewerten, ausrichten, überwachen.
❌
Evaluate, Direct, Monitor — bewerten, ausrichten, überwachen
✅
Planen, Bauen, Betreiben
❌
Design, Build, Run
❌
Kaufen, Verkaufen, Prüfen
Evaluate, Direct, Monitor (EDM) — bewerten, ausrichten, überwachen.
Practices – Begriff [Value System]
2
❌
Ein Satz organisierter Ressourcen, konzipiert für die Durchführung von Arbeit oder das Erreichen eines Ziels
✅
Ein einzelnes IT-Tool
❌
Ausschließlich ein Dokument mit Handlungsanweisungen
❌
Eine gesetzliche Vorgabe
Eine Practice ist ein Satz organisierter Ressourcen zur Durchführung von Arbeit oder Zielerreichung.
❌
Ein Satz organisierter Ressourcen, konzipiert für die Durchführung von Arbeit oder das Erreichen eines Ziels
✅
Ein einzelnes IT-Tool
❌
Ausschließlich ein Dokument mit Handlungsanweisungen
❌
Eine gesetzliche Vorgabe
Eine Practice ist ein Satz organisierter Ressourcen zur Durchführung von Arbeit oder Zielerreichung.
34 Practices erhalten [Value System]
2
❌
Nein, alle 34 bleiben erhalten, einige wurden lediglich anders kategorisiert
✅
Ja, sie wurden vollständig durch ein neues System ersetzt
❌
Ja, die Hälfte wurde ersatzlos gestrichen
❌
Nein, aber es kamen keine neuen Inhalte hinzu
Nein — alle 34 bleiben erhalten, einige wurden lediglich neu kategorisiert.
❌
Nein, alle 34 bleiben erhalten, einige wurden lediglich anders kategorisiert
✅
Ja, sie wurden vollständig durch ein neues System ersetzt
❌
Ja, die Hälfte wurde ersatzlos gestrichen
❌
Nein, aber es kamen keine neuen Inhalte hinzu
Nein — alle 34 bleiben erhalten, einige wurden lediglich neu kategorisiert.
Continual Improvement [Value System]
2
❌
Weil sich Anforderungen und Umfeld ständig ändern — Verbesserung muss fortlaufend eingebettet sein
✅
Weil es gesetzlich vorgeschrieben ist, jährlich neu zu starten
❌
Weil ein einmaliges Projekt ausreichend wäre, wenn gut geplant
❌
Weil Continual Improvement nur für Startups relevant ist
Weil sich Anforderungen und Umfeld laufend ändern und Verbesserung dauerhaft in alle Aktivitäten eingebettet sein muss.
❌
Weil sich Anforderungen und Umfeld ständig ändern — Verbesserung muss fortlaufend eingebettet sein
✅
Weil es gesetzlich vorgeschrieben ist, jährlich neu zu starten
❌
Weil ein einmaliges Projekt ausreichend wäre, wenn gut geplant
❌
Weil Continual Improvement nur für Startups relevant ist
Weil sich Anforderungen und Umfeld laufend ändern und Verbesserung dauerhaft in alle Aktivitäten eingebettet sein muss.
Continual Improvement Model [Value System]
2
❌
Was ist die Vision?
✅
Wie viel kostet die Verbesserung?
❌
Wer ist schuld am aktuellen Zustand?
❌
Wann ist die nächste Prüfung?
Es beginnt mit der Frage nach der Vision ("Was ist die Vision?").
❌
Was ist die Vision?
✅
Wie viel kostet die Verbesserung?
❌
Wer ist schuld am aktuellen Zustand?
❌
Wann ist die nächste Prüfung?
Es beginnt mit der Frage nach der Vision ("Was ist die Vision?").
Ganzheitlicher Ansatz [Value System]
2
❌
Interne und externe Faktoren sowie alle Dimensionen werden gemeinsam betrachtet
✅
Nur technische Faktoren werden berücksichtigt
❌
Externe Einflüsse werden bewusst ignoriert
❌
Nur die Kostenperspektive zählt
Interne und externe Faktoren sowie alle 4 Dimensionen werden gemeinsam betrachtet, nicht isoliert.
❌
Interne und externe Faktoren sowie alle Dimensionen werden gemeinsam betrachtet
✅
Nur technische Faktoren werden berücksichtigt
❌
Externe Einflüsse werden bewusst ignoriert
❌
Nur die Kostenperspektive zählt
Interne und externe Faktoren sowie alle 4 Dimensionen werden gemeinsam betrachtet, nicht isoliert.
Externe Einflussfaktoren [Value System]
2
❌
PESTLE-Analyse
✅
RACI-Matrix
❌
SWOT ausschließlich
❌
Gantt-Diagramm
PESTLE-Analyse (politisch, wirtschaftlich, sozial, technologisch, rechtlich, ökologisch).
❌
PESTLE-Analyse
✅
RACI-Matrix
❌
SWOT ausschließlich
❌
Gantt-Diagramm
PESTLE-Analyse (politisch, wirtschaftlich, sozial, technologisch, rechtlich, ökologisch).
Wertorientierung [Value System]
2
❌
Entscheidungen konsequent am geschaffenen Wert für Stakeholder ausrichten
✅
Ausschließlich am günstigsten Preis orientieren
❌
Wert nur am Ende eines Projekts bewerten
❌
Wertorientierung betrifft nur das Marketing
Entscheidungen konsequent daran auszurichten, welchen Wert sie für Stakeholder schaffen.
❌
Entscheidungen konsequent am geschaffenen Wert für Stakeholder ausrichten
✅
Ausschließlich am günstigsten Preis orientieren
❌
Wert nur am Ende eines Projekts bewerten
❌
Wertorientierung betrifft nur das Marketing
Entscheidungen konsequent daran auszurichten, welchen Wert sie für Stakeholder schaffen.
Servicebetrieb [Value System]
2
❌
Die operative Aufrechterhaltung und Unterstützung laufender Services
✅
Ausschließlich die Konzeptionsphase neuer Services
❌
Nur die Vertragsverhandlung mit Lieferanten
❌
Die endgültige Außerbetriebnahme eines Service
Die operative Aufrechterhaltung und Unterstützung laufender Services im Tagesgeschäft.
❌
Die operative Aufrechterhaltung und Unterstützung laufender Services
✅
Ausschließlich die Konzeptionsphase neuer Services
❌
Nur die Vertragsverhandlung mit Lieferanten
❌
Die endgültige Außerbetriebnahme eines Service
Die operative Aufrechterhaltung und Unterstützung laufender Services im Tagesgeschäft.
Releases [Value System]
2
❌
Neue oder geänderte Komponenten/Services für die Nutzung bereitstellen
✅
Ausschließlich Fehler dokumentieren
❌
Kundendaten archivieren
❌
Lieferantenverträge kündigen
Ein Release macht neue oder geänderte Komponenten für die Nutzung verfügbar.
❌
Neue oder geänderte Komponenten/Services für die Nutzung bereitstellen
✅
Ausschließlich Fehler dokumentieren
❌
Kundendaten archivieren
❌
Lieferantenverträge kündigen
Ein Release macht neue oder geänderte Komponenten für die Nutzung verfügbar.
Problemmanagement [Value System]
2
❌
Es sucht die zugrunde liegende Ursache, um künftige, wiederkehrende Vorfälle zu vermeiden
✅
Es ist inhaltlich identisch mit der Vorfallbehebung
❌
Es befasst sich ausschließlich mit Hardware-Defekten
❌
Es findet nur einmal jährlich statt
Problemmanagement sucht die zugrunde liegende Ursache, um wiederkehrende Vorfälle zu vermeiden.
❌
Es sucht die zugrunde liegende Ursache, um künftige, wiederkehrende Vorfälle zu vermeiden
✅
Es ist inhaltlich identisch mit der Vorfallbehebung
❌
Es befasst sich ausschließlich mit Hardware-Defekten
❌
Es findet nur einmal jährlich statt
Problemmanagement sucht die zugrunde liegende Ursache, um wiederkehrende Vorfälle zu vermeiden.
Messgrößen [Value System]
2
❌
Um Fortschritt und Erfolg objektiv nachvollziehbar zu machen und zu steuern
✅
Ausschließlich zur Mitarbeiterbewertung
❌
Nur für die Buchhaltung relevant
❌
Um Fehler zu vertuschen
Um Fortschritt und Erfolg objektiv nachvollziehbar zu machen und zu steuern.
❌
Um Fortschritt und Erfolg objektiv nachvollziehbar zu machen und zu steuern
✅
Ausschließlich zur Mitarbeiterbewertung
❌
Nur für die Buchhaltung relevant
❌
Um Fehler zu vertuschen
Um Fortschritt und Erfolg objektiv nachvollziehbar zu machen und zu steuern.
Critical Success Factor [Value System]
2
❌
Eine notwendige Voraussetzung zur Zielerreichung, gemessen über einen oder mehrere KPIs
✅
Ein einzelner beliebiger Messwert ohne strategischen Bezug
❌
Eine gesetzliche Auflage für Zertifizierungen
❌
Ein Synonym für Risiko
Eine notwendige Voraussetzung, um beabsichtigte Ergebnisse zu erreichen, gemessen über KPIs.
❌
Eine notwendige Voraussetzung zur Zielerreichung, gemessen über einen oder mehrere KPIs
✅
Ein einzelner beliebiger Messwert ohne strategischen Bezug
❌
Eine gesetzliche Auflage für Zertifizierungen
❌
Ein Synonym für Risiko
Eine notwendige Voraussetzung, um beabsichtigte Ergebnisse zu erreichen, gemessen über KPIs.
KPI vs. CSF [Value System]
2
❌
Ein oder mehrere KPIs machen einen CSF messbar
✅
KPI und CSF sind exakt dasselbe
❌
Ein CSF misst immer nur genau einen einzigen KPI, nie mehrere
❌
KPIs sind übergeordnet, CSFs untergeordnete Details davon
Ein CSF wird über einen oder mehrere KPIs messbar gemacht.
❌
Ein oder mehrere KPIs machen einen CSF messbar
✅
KPI und CSF sind exakt dasselbe
❌
Ein CSF misst immer nur genau einen einzigen KPI, nie mehrere
❌
KPIs sind übergeordnet, CSFs untergeordnete Details davon
Ein CSF wird über einen oder mehrere KPIs messbar gemacht.
Projektmanagement im Lebenszyklus [Value System]
2
❌
Als unterstützende Disziplin, die zeitlich begrenzte Vorhaben über mehrere Lebenszyklusstufen liefert
✅
Ausschließlich innerhalb der Stufe "Operate"
❌
Projektmanagement ist Teil von ITIL nicht relevant
❌
Nur bei Hardware-Beschaffung relevant
Als unterstützende Practice/Disziplin, die zeitlich begrenzte Vorhaben über verschiedene Lebenszyklusstufen liefert.
❌
Als unterstützende Disziplin, die zeitlich begrenzte Vorhaben über mehrere Lebenszyklusstufen liefert
✅
Ausschließlich innerhalb der Stufe "Operate"
❌
Projektmanagement ist Teil von ITIL nicht relevant
❌
Nur bei Hardware-Beschaffung relevant
Als unterstützende Practice/Disziplin, die zeitlich begrenzte Vorhaben über verschiedene Lebenszyklusstufen liefert.
Wertschöpfungskette und Betriebsmodell [Value System]
2
❌
Wie die Organisation Ressourcen und Aktivitäten strukturiert, um Wert zu liefern
✅
Ausschließlich die IT-Netzwerktopologie
❌
Nur das Organigramm der Geschäftsführung
❌
Die vertragliche Preisgestaltung
Wie die Organisation ihre Ressourcen und Aktivitäten strukturiert, um Wert zu liefern.
❌
Wie die Organisation Ressourcen und Aktivitäten strukturiert, um Wert zu liefern
✅
Ausschließlich die IT-Netzwerktopologie
❌
Nur das Organigramm der Geschäftsführung
❌
Die vertragliche Preisgestaltung
Wie die Organisation ihre Ressourcen und Aktivitäten strukturiert, um Wert zu liefern.
Guiding Principles Zuordnung [Value System]
2
❌
Fokus auf Wert
✅
Dort anfangen, wo man steht
✅
Automatisieren vor Optimieren
❌
Iterativ mit Feedback vorgehen
❌
Fokus auf Wert
✅
Dort anfangen, wo man steht
✅
Automatisieren vor Optimieren
❌
Iterativ mit Feedback vorgehen
Governance-Aktivitäten [Value System]
2
❌
Evaluate — bewerten
✅
Direct — ausrichten
✅
Monitor — überwachen
✅
Deploy — bereitstellen
❌
Evaluate — bewerten
✅
Direct — ausrichten
✅
Monitor — überwachen
✅
Deploy — bereitstellen
Merksatz:
Der Chef
dirigiert (Direct) das Orchester, während der Kontrolleur mit dem
Monitor (Monitor) alles überwacht, damit das Team die Software fehlerfrei
bereitstellen (Deploy) kann.
- Evaluate (bewerten) ist falsch: Dies ist ein klassischer Ablenkungsfehler, da „Evaluate“ zwar im englischen Originalbegriff vorkommt, in dieser spezifischen ITIL v5 Governance-Systematik jedoch durch die operative Umsetzungskomponente ersetzt wurde.
Practice-Kategorien (aus ITIL 4 übernommen) [Value System]
2
❌
General Management Practices
✅
Service Management Practices
✅
Technical Management Practices
✅
Financial Compliance Practices
❌
General Management Practices
✅
Service Management Practices
✅
Technical Management Practices
✅
Financial Compliance Practices
Komponenten Value System [Value System]
2
❌
Governance
✅
Guiding Principles
✅
Continual Improvement
✅
Externe Marktanalyse als eigenständige Komponente
❌
Governance
✅
Guiding Principles
✅
Continual Improvement
✅
Externe Marktanalyse als eigenständige Komponente
Grundprinzipien im Konflikt [Value System]
2
Musterantwort: z.B. Bei der Einführung eines neuen Tools will man es einfach halten, muss aber gleichzeitig alle betroffenen Abteilungen (ganzheitlich) einbeziehen — Lösung: Grundfunktion einfach halten, aber Rollout-Kommunikation ganzheitlich planen. Kein Prinzip hat absoluten Vorrang, sie werden situativ gewichtet.
Musterantwort: z.B. Bei der Einführung eines neuen Tools will man es einfach halten, muss aber gleichzeitig alle betroffenen Abteilungen (ganzheitlich) einbeziehen — Lösung: Grundfunktion einfach halten, aber Rollout-Kommunikation ganzheitlich planen. Kein Prinzip hat absoluten Vorrang, sie werden situativ gewichtet.
Governance in der Praxis [Value System]
2
Musterantwort: z.B. Evaluate: Die Leitung bewertet einen Vorschlag zur Cloud-Migration. Direct: Sie gibt die Richtung vor (Budget, Zeitrahmen, Anbieterwahl). Monitor: Sie überwacht regelmäßig den Fortschritt und greift bei Abweichungen ein.
Musterantwort: z.B. Evaluate: Die Leitung bewertet einen Vorschlag zur Cloud-Migration. Direct: Sie gibt die Richtung vor (Budget, Zeitrahmen, Anbieterwahl). Monitor: Sie überwacht regelmäßig den Fortschritt und greift bei Abweichungen ein.
Continual Improvement Model anwenden [Value System]
2
Musterantwort: Individuelle Antwort — sollte grob folgende Schritte enthalten: Vision klären, Ist-Zustand erheben, Ziel definieren, Maßnahmen planen, umsetzen, Erfolg prüfen, Verbesserungsdynamik aufrechterhalten.
Musterantwort: Individuelle Antwort — sollte grob folgende Schritte enthalten: Vision klären, Ist-Zustand erheben, Ziel definieren, Maßnahmen planen, umsetzen, Erfolg prüfen, Verbesserungsdynamik aufrechterhalten.
CSF und KPI selbst formulieren [Value System]
2
Musterantwort: z.B. CSF: "Zuverlässiger Servicebetrieb sicherstellen." KPIs: "Verfügbarkeit ≥ 99,5% pro Monat", "Mittlere Wiederherstellungszeit (MTTR) unter 2 Stunden".
Musterantwort: z.B. CSF: "Zuverlässiger Servicebetrieb sicherstellen." KPIs: "Verfügbarkeit ≥ 99,5% pro Monat", "Mittlere Wiederherstellungszeit (MTTR) unter 2 Stunden".
Practices vs. Prozesse [Value System]
1
❌
Eine Practice bündelt mehrere Ressourcenarten (Personen, Prozesse, Informationen, Technologie), ein Prozess ist enger gefasst
✅
Beide Begriffe sind exakt identisch
❌
Ein Prozess ist immer umfassender als eine Practice
❌
Practices existieren laut ITIL nicht mehr in Version 5
Eine Practice ist umfassender: sie bündelt Ressourcen wie Personen, Prozesse, Informationen und Technologie für ein Ziel.
General Management Practices [Value System]
1
❌
Organisationsweite Themen wie Strategie, Risiko, Finanzen
✅
Ausschließlich technische Infrastruktur-Themen
❌
Ausschließlich Kundenservice-Themen
❌
Nur Marketing-relevante Themen
Organisationsweite Themen wie Strategie, Risiko, Finanzen — nicht spezifisch Service- oder Technikbezogen.
Service Management Practices [Value System]
1
❌
Themen rund um Betrieb und Support laufender Services
✅
Ausschließlich strategische Unternehmensplanung
❌
Ausschließlich Software-Entwicklung
❌
Nur die Finanzplanung
Themen rund um Betrieb und Support laufender Services, z.B. Incident-, Problem-, Change-Management.
Technical Management Practices [Value System]
1
❌
Technologienahe Themen wie Infrastruktur, Plattformen, Softwareentwicklung
✅
Ausschließlich Vertragsmanagement
❌
Ausschließlich Personalentwicklung
❌
Nur Marketingaktivitäten
Technologienahe Themen wie Infrastruktur, Plattformen und Softwareentwicklung.
Grundprinzipien als Ganzes [Value System]
1
❌
Gemeinsam und situativ gewichtet, nicht isoliert
✅
Immer alle sieben in exakt derselben Reihenfolge
❌
Jeweils nur eines pro Projekt, nie kombiniert
❌
Nur das erste Prinzip ist praktisch relevant
Gemeinsam und situativ gewichtet, nicht isoliert nacheinander abgearbeitet.
Governance und Management [Value System]
1
❌
Governance gibt Richtung vor und überwacht, Management setzt operativ um
✅
Beide Begriffe sind exakt identisch
❌
Management ist immer übergeordnet gegenüber Governance
❌
Governance betrifft nur externe Prüfer
Governance gibt Richtung vor und überwacht, Management setzt um.
CSF-Beispiel [Value System]
1
❌
Hohe Kundenzufriedenheit sicherstellen
✅
Die Serverfarbe im Rechenzentrum
❌
Die Anzahl der Kaffeemaschinen im Büro
❌
Das Logo-Design der Firma
Ein CSF ist eine Voraussetzung für Erfolg — "hohe Kundenzufriedenheit sicherstellen" ist so eine Voraussetzung, messbar über KPIs.
KPI-Beispiel [Value System]
1
❌
Customer Satisfaction Score (CSAT) ≥ 90%
✅
Anzahl der Server im Rechenzentrum
❌
Bürogröße in Quadratmetern
❌
Anzahl geplanter Meetings pro Woche
Der Customer Satisfaction Score (CSAT) ist ein direkt messbarer Indikator für Kundenzufriedenheit.
Change Enablement Grundidee [Value System]
1
❌
Änderungen risikoangemessen bewerten und freigeben, ohne unnötig zu bremsen
✅
Jede Änderung grundsätzlich zu verhindern
❌
Änderungen ausschließlich einmal jährlich zuzulassen
❌
Nur der IT-Leitung Änderungsrechte zu geben
Änderungen risikoangemessen zu bewerten und freizugeben, ohne unnötig zu bremsen.
Standard-, Normal- und Notfalländerung [Value System]
1
❌
Risikoarm, gut verstanden, vorab genehmigt, wiederkehrend
✅
Immer höchstes Risiko und Eilbedürftigkeit
❌
Nie zuvor durchgeführt
❌
Erfordert immer eine Vorstandsentscheidung
Sie ist risikoarm, gut verstanden, vorab genehmigt und wird wiederkehrend nach etabliertem Verfahren durchgeführt.
Kontinuierliche Verbesserung im Alltag [Value System]
1
❌
Als Verantwortung aller Beteiligten, nicht nur einer isolierten Abteilung
✅
Ausschließlich als Aufgabe der Geschäftsführung
❌
Ausschließlich als Aufgabe externer Berater
❌
Als einmalige Aufgabe zu Projektbeginn
Als Verantwortung aller, nicht nur einer isolierten Abteilung.
Messgrößen richtig wählen [Value System]
1
❌
Eine einzelne Kennzahl kann ein verzerrtes Bild geben und Aspekte übersehen
✅
Mehrere Kennzahlen sind laut ITIL grundsätzlich verboten
❌
Eine einzelne Kennzahl ist immer ausreichend
❌
Messgrößen spielen im Value System keine Rolle
Eine einzelne Kennzahl kann ein verzerrtes Bild geben und wichtige Aspekte übersehen.
Servicebetrieb und Releases Zusammenspiel [Value System]
1
❌
Releases bringen Änderungen in den Betrieb, der Betrieb sorgt für stabilen laufenden Einsatz
✅
Beide Begriffe sind komplett unabhängig voneinander
❌
Releases finden nur nach Beendigung des Servicebetriebs statt
❌
Der Servicebetrieb ersetzt die Notwendigkeit von Releases
Releases bringen neue/geänderte Komponenten in den Betrieb, der Servicebetrieb sorgt für deren stabilen laufenden Einsatz.
Projektmanagement als unterstützende Disziplin [Value System]
1
❌
Weil Projekte oft genutzt werden, um Änderungen im Lebenszyklus umzusetzen
✅
Weil ITIL Projektmanagement grundsätzlich ablehnt
❌
Weil Projektmanagement identisch mit Governance ist
❌
Weil Projekte laut ITIL nie zeitlich begrenzt sind
Weil Projekte oft genutzt werden, um Änderungen am Produkt-/Servicelebenszyklus umzusetzen, nicht als Selbstzweck.
Grundprinzip Praxisbeispiel Feedback [Value System]
1
❌
Iterativ mit Feedback vorgehen
✅
Ganzheitlich denken und arbeiten
❌
Einfach und praktikabel
❌
Dort anfangen, wo man steht
Progress iteratively with feedback.
Grundprinzip Praxisbeispiel Wiederverwendung [Value System]
1
❌
Dort anfangen, wo man steht
✅
Optimieren und automatisieren
❌
Zusammenarbeit und Sichtbarkeit fördern
❌
Fokus auf Wert
Start where you are.
Charakteristika von CSFs [Value System]
1
❌
Ein CSF ist eine notwendige Voraussetzung für Erfolg
✅
Ein CSF wird über einen oder mehrere KPIs messbar gemacht
✅
Ein CSF ist identisch mit einem einzelnen KPI
❌
CSFs sind ausschließlich finanzieller Natur
Merkmale von Change Enablement [Value System]
1
❌
Es gibt unterschiedliche Änderungsarten mit unterschiedlichem Risiko
✅
Standard-Changes sind vorab genehmigt
✅
Jede Änderung muss immer den identischen Genehmigungsweg durchlaufen
❌
Notfalländerungen erfordern meist einen beschleunigten Prozess
Eigene CSF/KPI-Kette [Value System]
1
Musterantwort: z.B. CSF: "Störungen schnell beheben, um Geschäftsauswirkungen zu minimieren." KPI: "Durchschnittliche Wiederherstellungszeit (MTTR) unter 4 Stunden."
Governance vs. Management eigenständig [Value System]
1
Musterantwort: Individuelle Antwort — sollte erklären, dass Governance Richtung/Kontrolle gibt und Management ohne sie ziellos werden kann, während Governance ohne Management wirkungslos bliebe.
Practice-Kategorie zuordnen [Value System]
1
Musterantwort: General Management Practices — da es sich um eine organisationsweite Disziplin handelt (Steuerung von Lieferantenbeziehungen), nicht um ein rein technisches oder rein servicebetriebliches Thema.
Continual Improvement im eigenen Team [Value System]
1
Musterantwort: Individuelle Antwort — sollte grob die Schritte Ist-Zustand, Ziel, Maßnahme, Umsetzung, Erfolgskontrolle erkennbar durchlaufen.
Wertschöpfungskette Begriff [Value System]
1
❌
Wie organisationsweite Aktivitäten ineinandergreifen, um Wert zu liefern
✅
Ausschließlich die Lieferkette physischer Waren
❌
Ein Synonym für Governance
❌
Ausschließlich die IT-Infrastruktur
Wie organisationsweite Aktivitäten ineinandergreifen, um letztlich Wert zu liefern.
Betriebsmodell Beispiel [Value System]
1
❌
Entscheidung zwischen zentraler und dezentraler Serviceerbringung
✅
Die Wahl der Bürofarbe
❌
Die Wahl des Kaffeeanbieters
❌
Die Anzahl der Firmenwagen
Die Wahl zwischen zentraler und dezentraler Serviceerbringung ist eine klassische Betriebsmodell-Frage.
Übersicht [Lebenszyklus]
1
❌
Acht
✅
Sechs
❌
Fünf
❌
Zehn
Acht Stufen: Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support.
Merksatz:
Denke an eine perfekte
Wabe mit 6 Ecken – so wie die Bienen fleißig Honig produzieren, durchläuft jedes ITIL-Produkt genau
sechs Lebenszyklus-Stufen von der Idee bis zur Einstellung.
Acht: Zu viele Stufen; dies verwechselt den schlanken Service-Lebenszyklus mit den detaillierten ITIL-Praktiken.
Fünf: Das ist veraltetes Wissen; die fünf Kernpublikationen gehörten zur alten ITIL V3-Struktur.
- Zehn: Viel zu komplex; eine zweistellige Zahl würde den agilen und flexiblen Fluss moderner ITIL-Prozesse blockieren.
Discover [Lebenszyklus]
1
❌
Bedarf und Chancen erkennen, bevor eine Lösung konzipiert wird
✅
Die technische Entwicklung abschließen
❌
Den Livebetrieb überwachen
❌
Support-Tickets bearbeiten
Bedarf, Chancen und Anforderungen im Markt/Unternehmen erkennen, bevor eine Lösung entsteht.
Design [Lebenszyklus]
1
❌
Konzeption der Lösung unter Berücksichtigung aller relevanten Dimensionen
✅
Ausschließlich Marktforschung
❌
Der Abbau eines nicht mehr genutzten Service
❌
Die Rechnungsstellung an Kunden
Eine Lösung wird konzipiert, unter Berücksichtigung aller vier Dimensionen.
Acquire und Build [Lebenszyklus]
1
❌
Acquire steht für Beschaffung/Einkauf, Build für Eigenentwicklung
✅
Beide Begriffe sind vollständig identisch
❌
Acquire betrifft nur Personal, Build nur Software
❌
Build findet immer vor Acquire statt
Acquire = Beschaffung von außen, Build = Eigenentwicklung.
Transition [Lebenszyklus]
1
❌
Den kontrollierten Übergang in den Produktivbetrieb sicherstellen
✅
Ausschließlich die erste Marktanalyse
❌
Die endgültige Stilllegung eines Service
❌
Die jährliche Budgetplanung
Der kontrollierte Übergang einer Lösung in den Produktivbetrieb.
Operate [Lebenszyklus]
1
❌
Der laufende, tägliche Betrieb
✅
Die erstmalige Konzeption
❌
Die Marktbeobachtung vor Projektstart
❌
Die vertragliche Ausschreibung
Der laufende, tägliche Betrieb des Produkts/Service.
Deliver und Support [Lebenszyklus]
1
❌
Bereitstellung an Nutzer:innen und deren Unterstützung
✅
Ausschließlich die technische Architektur
❌
Die Stilllegung veralteter Komponenten
❌
Die reine Marktanalyse
Bereitstellung an die Nutzer sowie deren Unterstützung, um vereinbarte Leistungen sicherzustellen.
Iteratives Vorgehen [Lebenszyklus]
1
❌
Iterativ und nicht-linear, Wert kann in jeder Stufe entstehen
✅
Immer streng sequenziell von Stufe 1 bis 8
❌
Nur die ersten vier Stufen sind für Foundation überhaupt relevant
❌
Rückwärts, von Support zu Discover
Iterativ und nicht-linear, je nach Bedarf, nicht zwingend streng sequenziell.
Wertschöpfung im Lebenszyklus [Lebenszyklus]
1
❌
Ja, z.B. durch wertvolle Erkenntnisse, die spätere Fehlentscheidungen vermeiden
✅
Nein, Wert entsteht ausschließlich in "Operate"
❌
Nein, Wert entsteht ausschließlich in "Deliver und Support"
❌
Nein, Wert entsteht erst nach vollständigem Abschluss aller 8 Stufen
Ja — z.B. durch gewonnene Erkenntnisse, die Fehlinvestitionen vermeiden.
Vergleich zu ITIL 4 [Lebenszyklus]
1
❌
Version 5 nutzt 8 Lebenszyklus-Stufen statt der 6 Service-Value-Chain-Aktivitäten aus ITIL 4
✅
Es gibt keinerlei Unterschied
❌
ITIL 4 hatte mehr Stufen als Version 5
❌
Version 5 verzichtet komplett auf einen Lebenszyklus-Gedanken
V5 nutzt 8 Stufen statt der 6 Aktivitäten der ITIL-4 Service Value Chain.
Support [Lebenszyklus]
1
❌
Weil Nutzer:innen bei Problemen Unterstützung brauchen, damit der vereinbarte Wert tatsächlich realisiert wird
✅
Weil Support ausschließlich vor dem Livegang stattfindet
❌
Weil Support identisch mit Design ist
❌
Weil Support nur bei Hardware-Produkten relevant ist
Support stellt sicher, dass Nutzer:innen bei Problemen begleitet werden, damit vereinbarter Wert tatsächlich ankommt.
Stufenreihenfolge [Lebenszyklus]
1
❌
Discover
✅
Transition
✅
Governance
❌
Deliver und Support
Nicht-lineares Vorgehen [Lebenszyklus]
1
Musterantwort: z.B. Während des laufenden Betriebs (Operate) fällt auf, dass eine Funktion die Nutzer:innen nicht wie gedacht unterstützt — das Team geht zurück zu Design, um die Lösung anzupassen, was iteratives statt lineares Arbeiten zeigt.
Discover vs. Design [Lebenszyklus]
1
Musterantwort: Discover klärt, OB und WARUM ein Bedarf/eine Chance besteht (Bedarfserkennung), Design klärt WIE die konkrete Lösung dafür aussehen soll (Konzeption).
Startpunkt des Lebenszyklus [Lebenszyklus]
1
❌
Nein, durch das iterative Vorgehen kann an unterschiedlichen Stufen eingestiegen werden
✅
Ja, jeder Durchlauf muss zwingend bei Discover beginnen
❌
Ja, aber nur bei komplett neuen Produkten
❌
Nein, er beginnt immer bei Operate
Nein — durch die iterative, nicht-lineare Natur kann ein Team an jeder passenden Stufe einsteigen.
Feedback-Schleifen [Lebenszyklus]
1
❌
Als Feedback zurück in frühere Stufen wie Design, um zu verbessern
✅
Sie werden grundsätzlich nicht weiterverwendet
❌
Sie fließen ausschließlich in die Rechnungsstellung
❌
Sie betreffen nur zukünftige, komplett neue Produkte
Sie fließen als Feedback zurück in frühere Stufen wie Design, um die Lösung zu verbessern.
Acquire vs. Build Entscheidung [Lebenszyklus]
1
❌
Von Kosten, Kompetenzen, Zeitrahmen und strategischer Bedeutung
✅
Ausschließlich vom Zufallsprinzip
❌
Build ist laut ITIL immer die bessere Wahl
❌
Acquire ist laut ITIL immer verboten
Von Faktoren wie Kosten, verfügbaren Kompetenzen, Zeitrahmen und strategischer Bedeutung der Komponente.
Transition und Risiko [Lebenszyklus]
1
❌
Weil eine neue/geänderte Lösung erstmals auf die Produktivumgebung trifft
✅
Weil in dieser Stufe keine Tests stattfinden dürfen
❌
Weil diese Stufe laut ITIL optional ist
❌
Risiko ist in dieser Stufe geringer als in allen anderen
Weil hier eine neue/geänderte Lösung erstmals auf die Produktivumgebung trifft — Fehler wirken sich direkt auf den Betrieb aus.
Support als Werttreiber [Lebenszyklus]
1
❌
Er stellt sicher, dass Nutzer:innen den vollen Wert tatsächlich realisieren können
✅
Support hat laut ITIL keinen Einfluss auf Wertschöpfung
❌
Support ersetzt die Notwendigkeit von gutem Design
❌
Support ist nur für interne Mitarbeitende relevant
Guter Support stellt sicher, dass Nutzer:innen den vollen Wert tatsächlich realisieren können, statt an Hürden zu scheitern.
Lebenszyklus und Wertströme [Lebenszyklus]
1
❌
Ja, ein Wertstrom kombiniert oft mehrere Stufen
✅
Nein, ein Wertstrom entspricht immer genau einer Stufe
❌
Nein, Wertströme und Lebenszyklus sind unabhängig
❌
Nur bei sehr kleinen Organisationen möglich
Ja, ein Wertstrom kombiniert oft mehrere Stufen zu einem Ende-zu-Ende-Ablauf.
Design-Stufe und alle Dimensionen [Lebenszyklus]
1
❌
Weil eine nur technisch gute, aber z.B. organisatorisch nicht tragfähige Lösung scheitern kann
✅
Weil das gesetzlich für jede Software vorgeschrieben ist
❌
Weil Design ausschließlich die Dimension Technologie betrifft
❌
Dimensionen spielen in der Design-Stufe keine Rolle
Weil eine Lösung, die nur technisch gut, aber z.B. organisatorisch nicht tragfähig ist, in der Praxis scheitern kann.
Reihenfolge kann variieren [Lebenszyklus]
1
❌
Stufen können übersprungen werden, wenn sinnvoll
✅
Ein Team kann zwischen Stufen hin- und herspringen
✅
Jede Stufe wird in der Praxis genau einmal durchlaufen
❌
Wert kann bereits vor Projektende entstehen
Eigenes Lebenszyklus-Beispiel [Lebenszyklus]
1
Musterantwort: Individuelle Antwort — sollte für jede der 8 Stufen eine konkrete, plausible Aktivität nennen, bezogen auf das gewählte Produkt.
Wann zurück zu Design? [Lebenszyklus]
1
Musterantwort: z.B. wiederkehrende Beschwerden zu einer bestimmten Funktion; deutlich höhere Supportkosten als erwartet, die auf ein strukturelles Designproblem hindeuten.
Begriff Wertstrom [Wertströme]
2
❌
Eine Abfolge von Schritten, mit denen eine Organisation Wert für Konsumenten schafft und liefert
✅
Ein einzelner isolierter Arbeitsschritt ohne Kontext
❌
Ein rein finanzielles Reporting-Instrument
❌
Ein Synonym für "Prozess" ohne inhaltlichen Unterschied
Eine Abfolge von Schritten, mit denen eine Organisation Produkte/Services für Konsumenten schafft und liefert.
❌
Eine Abfolge von Schritten, mit denen eine Organisation Wert für Konsumenten schafft und liefert
✅
Ein einzelner isolierter Arbeitsschritt ohne Kontext
❌
Ein rein finanzielles Reporting-Instrument
❌
Ein Synonym für "Prozess" ohne inhaltlichen Unterschied
Eine Abfolge von Schritten, mit denen eine Organisation Produkte/Services für Konsumenten schafft und liefert.
Hauptwertstrom [Wertströme]
2
❌
Er schafft direkt Wert für externe Stakeholder
✅
Er ist ausschließlich intern und ohne Kundenbezug
❌
Er existiert nur in der IT-Abteilung
❌
Er ist identisch mit einem unterstützenden Wertstrom
Er schafft direkt Wert für externe Stakeholder/Konsumenten.
❌
Er schafft direkt Wert für externe Stakeholder
✅
Er ist ausschließlich intern und ohne Kundenbezug
❌
Er existiert nur in der IT-Abteilung
❌
Er ist identisch mit einem unterstützenden Wertstrom
Er schafft direkt Wert für externe Stakeholder/Konsumenten.
Wertstrom vs. Practice [Wertströme]
1
❌
Ein Wertstrom ist ein Ende-zu-Ende-Ablauf, der mehrere Practices kombinieren kann
✅
Beide Begriffe sind exakt identisch
❌
Eine Practice ist immer umfassender als ein Wertstrom
❌
Wertströme existieren unabhängig von jeder Practice
Ein Wertstrom ist ein Ende-zu-Ende-Ablauf, der typischerweise mehrere Practices kombiniert.
Engpässe erkennen [Wertströme]
1
❌
Um Engpässe, Wartezeiten und nicht-wertschöpfende Schritte zu erkennen
✅
Ausschließlich zur Erstellung von Organigrammen
❌
Ausschließlich zur Budgetplanung
❌
Es hat keinen praktischen Nutzen über die Visualisierung hinaus
Um Engpässe, Wartezeiten und nicht-wertschöpfende Schritte im Ablauf zu identifizieren.
Wertstrom über Abteilungsgrenzen [Wertströme]
1
❌
Weil Wertschöpfung meist mehrere Funktionen/Abteilungen einbindet
✅
Weil Abteilungsgrenzen laut ITIL abgeschafft werden sollen
❌
Wertströme bleiben laut Definition immer innerhalb einer Abteilung
❌
Das ist nur bei sehr großen Konzernen der Fall
Weil die Wertschöpfung für den externen Konsumenten meist mehrere Funktionen (z.B. Vertrieb, Entwicklung, Support) einbindet.
Wertstrom-Optimierung [Wertströme]
1
❌
Optimieren und automatisieren
✅
Keep it simple ausschließlich
❌
Start where you are ausschließlich
❌
Kollaboration ausschließlich
Optimize and automate — nachdem der Wertstrom verstanden und optimiert ist, kann automatisiert werden.
Merkmale von Wertströmen [Wertströme]
1
❌
Ein Wertstrom besteht aus einer Abfolge von Schritten
✅
Hauptwertströme schaffen direkten externen Wert
✅
Unterstützende Wertströme sind für die Organisation ohne Bedeutung
❌
Value Stream Mapping macht Engpässe sichtbar
Engpass im eigenen Wertstrom finden [Wertströme]
1
Musterantwort: Individuelle Antwort — sollte einen konkreten Engpass benennen (z.B. lange Wartezeit auf Freigabe) und einen plausiblen Lösungsansatz vorschlagen (z.B. Delegation von Standard-Freigaben).
Value Stream Mapping durchführen [Wertströme]
1
Musterantwort: Individuelle Antwort — sollte grob enthalten: Start-/Endpunkt festlegen, alle Schritte erfassen, Zeiten/Übergaben markieren, Engpässe identifizieren, Verbesserungen ableiten.
Servicebegriff [Begriffe]
1
❌
Ein Mittel, das Wertschöpfung ermöglicht, indem gewünschte Ergebnisse ohne Übernahme spezifischer Kosten/Risiken durch den Kunden ermöglicht werden
✅
Ein physisches Produkt, das an den Kunden verkauft wird
❌
Eine einmalige technische Dienstleistung ohne laufende Verantwortung
❌
Ein Vertrag zwischen zwei IT-Abteilungen
Ein Service ermöglicht Wertschöpfung, ohne dass der Kunde bestimmte Kosten und Risiken selbst tragen muss.
Produktbegriff [Begriffe]
1
❌
Eine Konfiguration der Ressourcen einer Organisation, die für einen Kunden Wert schaffen kann
✅
Ausschließlich Software, die verkauft wird
❌
Ein Synonym für "Service"
❌
Ein internes Dokument zur Leistungsbeschreibung
Produkt = Konfiguration von Ressourcen einer Organisation, die für Kunden Wert schaffen kann.
Serviceangebot [Begriffe]
1
❌
Eine Beschreibung eines oder mehrerer Services, ggf. inkl. Waren, Ressourcenzugang und Service-Aktionen
✅
Ausschließlich der Preis eines Services
❌
Nur die technische Spezifikation eines Produkts
❌
Der Vertrag zwischen zwei Lieferanten
Ein Serviceangebot kann Waren, Zugang zu Ressourcen und Service-Aktionen umfassen.
Output vs. Outcome [Begriffe]
1
❌
Output ist ein greifbares/nicht-greifbares Zwischenergebnis, Outcome das dadurch ermöglichte Ergebnis für einen Stakeholder
✅
Output und Outcome sind Synonyme
❌
Outcome ist immer finanzieller Natur, Output nie
❌
Output entsteht nur in der Design-Phase
Output ist das greifbare Ergebnis einer Aktivität, Outcome das dadurch ermöglichte Resultat für einen Stakeholder.
Utility [Begriffe]
1
❌
Die Funktionalität eines Service, die ihn für den vorgesehenen Zweck geeignet macht ("fit for purpose")
✅
Die Zusicherung, dass ein Service verfügbar und sicher ist
❌
Die Kundenzufriedenheit mit dem Service
❌
Der finanzielle Wert eines Service
Utility = "fit for purpose", die Funktionalität, die einen Service für den vorgesehenen Zweck geeignet macht.
Warranty [Begriffe]
1
❌
Die Zusicherung, dass ein Produkt/Service den vereinbarten Anforderungen entspricht ("fit for use")
✅
Die grundsätzliche Funktionalität eines Service
❌
Eine gesetzliche Garantiezeit für Software
❌
Die Kundenerwartung an den Preis
Warranty = "fit for use", z.B. Verfügbarkeit, Kapazität, Sicherheit, Kontinuität wie vereinbart.
Utility vs. Warranty [Begriffe]
1
❌
Warranty — die Verfügbarkeit als vereinbarte Eigenschaft ist nicht gegeben
✅
Utility — die Funktionalität fehlt komplett
❌
Value — der Shop hat gar keinen Wert
❌
Cost — der Shop ist zu teuer
Häufige Ausfälle betreffen die Verfügbarkeit — ein Warranty-Aspekt, nicht die Funktionalität (Utility).
Value [Begriffe]
1
❌
Als wahrgenommener Nutzen, Bedeutung oder Wichtigkeit — subjektiv und ko-kreiert
✅
Als objektiv festgelegter Geldbetrag im Vertrag
❌
Ausschließlich als Kosteneinsparung
❌
Als reine Zufriedenheitsbewertung im Kundensupport
Wert ist subjektiv/wahrgenommen und entsteht durch Zusammenarbeit der Beteiligten (Wert-Co-Kreation).
Kosten und Risiko [Begriffe]
1
❌
Ein Kernnutzen von Services ist, dem Kunden bestimmte Kosten und Risiken abzunehmen
✅
Kosten und Risiko spielen in ITIL keine Rolle
❌
Nur der Service-Provider trägt jemals Risiko, nie der Kunde
❌
Kosten sind identisch mit dem Preis eines Service
Wert entsteht auch dadurch, dass der Service-Provider dem Kunden bestimmte Kosten/Risiken abnimmt.
Servicebeziehung [Begriffe]
1
❌
Die Zusammenarbeit zwischen Service-Provider und -Konsument: Bereitstellung, Nutzung und Beziehungsmanagement
✅
Ausschließlich der unterschriebene Vertrag
❌
Nur die technische Schnittstelle zwischen zwei Systemen
❌
Die private Beziehung zwischen zwei Mitarbeitenden
Servicebeziehung = Zusammenarbeit zwischen Provider und Konsument über Bereitstellung, Nutzung und Beziehungsmanagement.
Rollen: Konsument [Begriffe]
1
❌
Kundschaft, Anwender:innen, Sponsor
✅
Provider, Lieferant, Partner
❌
Administrator, Entwickler:in, Tester:in
❌
Vorstand, Abteilungsleitung, Sachbearbeitung
Kundschaft (definiert Anforderungen), Anwender:innen (nutzen den Service), Sponsor (finanziert).
Sponsor [Begriffe]
1
❌
Die Person/Organisation, die das Budget für den Servicekonsum bereitstellt
✅
Wer den Service täglich operativ nutzt
❌
Der externe Anbieter des Service
❌
Wer die Prüfungsordnung eines Zertifikats festlegt
Der Sponsor stellt das Budget für den Servicekonsum bereit.
SLA [Begriffe]
1
❌
Service Level Agreement — dokumentierte Vereinbarung über zu erbringende Leistungsziele
✅
Service Logic Architecture — technische Systemarchitektur
❌
System Level Authorization — Zugriffsrechteverwaltung
❌
Standard Legal Agreement — allgemeiner Rechtsvertrag
SLA = Service Level Agreement, dokumentiert vereinbarte Leistungsziele zwischen Provider und Konsument.
Servicemanagement [Begriffe]
1
❌
Ein Satz spezialisierter organisatorischer Fähigkeiten, um Wert durch Services zu ermöglichen
✅
Ausschließlich die IT-Abteilung eines Unternehmens
❌
Ein Synonym für Projektmanagement
❌
Eine Software zur Ticketverwaltung
Service Management = spezialisierte organisatorische Fähigkeiten zur Wertschöpfung durch Services.
Best Practice [Begriffe]
1
❌
Bewährte, in der Praxis über Organisationen hinweg erprobte Vorgehensweisen
✅
Eine gesetzlich vorgeschriebene Methode
❌
Die teuerste verfügbare Lösung
❌
Eine rein theoretische, unerprobte Idee
Bewährte Vorgehensweisen, die sich in der Praxis über mehrere Organisationen hinweg als wirksam erwiesen haben.
Nachhaltigkeit [Begriffe]
1
❌
Sie wird als eigener Aspekt bei Gestaltung und Bewertung von Produkten/Services stärker betont
✅
Sie spielt in ITIL keine Rolle
❌
Sie ersetzt vollständig den Begriff "Value"
❌
Sie betrifft ausschließlich die Hardware-Beschaffung
Nachhaltigkeit ist als eigenständiger Aspekt bei der Servicegestaltung/-bewertung stärker verankert als zuvor.
User Experience [Begriffe]
1
❌
Weil das subjektive Nutzungserlebnis zunehmend als eigener Werttreiber verstanden wird
✅
Weil UX identisch mit Warranty ist
❌
Weil UX nur für Consumer-Apps relevant ist, nicht für Business-Services
❌
Weil UX ausschließlich vom Sponsor bewertet wird
UX rückt das subjektive Erlebnis der Nutzenden stärker in den Fokus, ergänzend zu reiner Funktionserfüllung.
Digitale Produkte und Services [Begriffe]
1
❌
Ein stärkerer Fokus auf Produktdenken über den gesamten Lebenszyklus statt nur auf Servicebereitstellung
✅
Der vollständige Verzicht auf den Servicebegriff
❌
Die Abschaffung von SLAs
❌
Der ausschließliche Fokus auf interne IT-Kunden
Der Fokus verschiebt sich von reiner Servicebereitstellung hin zu Produktdenken über den gesamten Lebenszyklus.
Service Provider [Begriffe]
1
❌
Services bereitstellen, die dem Konsumenten Wert ermöglichen
✅
Ausschließlich Hardware verkaufen
❌
Nur interne Audits durchführen
❌
Verträge zwischen zwei Kunden vermitteln
Ein Service Provider stellt Services bereit, die dem Konsumenten Wert schaffen.
Rollen im Wertschöpfungsnetzwerk [Begriffe]
1
❌
Die Kundschaft definiert Anforderungen an den Service
✅
Anwender:innen nutzen den Service im Alltag
✅
Der Sponsor finanziert den Servicekonsum
✅
Alle drei Rollen müssen zwingend von unterschiedlichen Personen wahrgenommen werden
Kundschaft, Anwender:innen und Sponsor sind die drei möglichen (teils überlappenden) Konsumentenrollen.
Utility und Warranty kombiniert [Begriffe]
1
Musterantwort: z.B. Ein Buchungssystem hat Utility (kann Buchungen verarbeiten) — ohne Warranty (Verfügbarkeit, Sicherheit) wäre es trotzdem wertlos, wenn es ständig ausfällt oder Daten verliert. Beide Eigenschaften zusammen ergeben "fit for purpose and fit for use".
Wert als Ko-Kreation [Begriffe]
1
Musterantwort: z.B. Wert entsteht im Zusammenspiel: der Provider stellt den Service bereit, aber der Konsument muss ihn aktiv und richtig nutzen, damit tatsächlich Nutzen entsteht — beide Seiten tragen zur Wertschöpfung bei.
Service Offering vs. Service [Begriffe]
1
❌
Ja, derselbe Service kann Bestandteil unterschiedlicher Serviceangebote sein
✅
Nein, jeder Service gehört immer zu genau einem Angebot
❌
Nein, Services und Serviceangebote sind identisch
❌
Nur bei physischen Produkten möglich
Ja — ein Service kann in verschiedenen Kombinationen/Preismodellen als Teil verschiedener Angebote auftreten.
Output-Beispiel [Begriffe]
1
❌
Ein fertiggestellter Analysebericht
✅
Die dadurch ermöglichte bessere Geschäftsentscheidung
❌
Die langfristige Kundenzufriedenheit
❌
Der gestiegene Marktanteil
Ein erstellter Bericht ist ein greifbares Zwischenergebnis (Output); die dadurch ermöglichte bessere Entscheidung wäre der Outcome.
Kosten für Provider vs. Konsument [Begriffe]
1
❌
Ja, beide Seiten haben jeweils eigene Kosten
✅
Nein, nur der Provider hat Kosten
❌
Nein, nur der Konsument hat Kosten
❌
Kosten entstehen laut ITIL nur bei physischen Produkten
Ja — beide Seiten tragen typischerweise Kosten (Bereitstellung bzw. Nutzung).
Risiko-Transfer [Begriffe]
1
❌
Das Risiko wird reduziert oder verlagert, aber nicht zwingend vollständig beseitigt
✅
Risiko verschwindet dadurch immer vollständig
❌
Der Konsument trägt dadurch automatisch mehr Risiko
❌
Risikoabnahme ist laut ITIL kein relevantes Konzept
Viele Services reduzieren oder verlagern Risiko, beseitigen es aber nicht vollständig.
Anwender:in vs. Kundschaft [Begriffe]
1
❌
Ja, das ist möglich, muss aber nicht zwingend so sein
✅
Nein, das schließt sich laut ITIL-Definition immer aus
❌
Nein, Anwender:innen sind immer Mitarbeitende des Providers
❌
Ja, aber nur bei digitalen Services
Ja, in vielen Fällen (z.B. Privatkunden) sind Kundschaft und Anwender:in identisch — bei Unternehmen oft getrennt.
Servicequalität [Begriffe]
1
❌
An der Erfüllung vereinbarter Anforderungen aus Stakeholder-Sicht
✅
Ausschließlich am technischen Aufwand der Bereitstellung
❌
Ausschließlich am Preis des Service
❌
An der Anzahl eingesetzter Mitarbeitender
An der Erfüllung vereinbarter Anforderungen (Utility und Warranty gemeinsam) aus Sicht der Stakeholder.
SLA-Inhalt [Begriffe]
1
❌
Interne technische Implementierungsdetails der Umsetzung
✅
Vereinbarte Verfügbarkeitsziele
❌
Reaktionszeiten bei Störungen
❌
Verantwortlichkeiten beider Vertragsparteien
Interne technische Implementierungsdetails sind kein SLA-Bestandteil — SLAs beschreiben vereinbarte Leistungsziele, nicht die interne Umsetzung.
Produkt vs. Serviceangebot [Begriffe]
1
❌
Ein Serviceangebot basiert auf einem oder mehreren Produkten
✅
Ein Produkt basiert immer auf mehreren Serviceangeboten
❌
Beide Begriffe sind komplett identisch
❌
Produkte existieren laut ITIL nur im Einzelhandel
Ein Serviceangebot basiert auf einem oder mehreren Produkten.
Warranty-Dimensionen [Begriffe]
1
❌
Verfügbarkeit
✅
Funktionsumfang
❌
Bedienfreundlichkeit
❌
Marktpreis
Verfügbarkeit ist ein klassischer Warranty-Aspekt (fit for use).
Nutzen ohne Eigentum [Begriffe]
1
❌
Weil Kosten und Risiken des Eigentums beim Provider verbleiben können
✅
Weil Services immer günstiger sind als Eigentum
❌
Weil Eigentum laut ITIL grundsätzlich verboten ist
❌
Das ist kein relevanter Aspekt von Servicedenken
Der Konsument profitiert vom Nutzen, ohne die vollen Kosten/Risiken des Eigentums (z.B. Wartung, Investition) zu tragen.
Rolle: Kundschaft [Begriffe]
1
❌
Anforderungen an den Service definieren und für Ergebnisse verantwortlich sein
✅
Ausschließlich das Budget bereitstellen
❌
Ausschließlich den Service technisch betreiben
❌
Ausschließlich Supportanfragen bearbeiten
Sie definiert Anforderungen an den Service und ist für dessen Ergebnisse verantwortlich.
Digitale Transformation [Begriffe]
1
❌
Sie verändert Geschäftsmodelle und Prozesse grundlegend, nicht nur die Technik
✅
Beide Begriffe sind exakt identisch
❌
Digitale Transformation betrifft nur die Serverlandschaft
❌
IT-Modernisierung ist immer umfassender als digitale Transformation
Digitale Transformation verändert Geschäftsmodelle/Prozesse grundlegend, nicht nur die eingesetzte Technik.
Nachhaltigkeit als Anforderung [Begriffe]
1
❌
Z.B. als Vorgabe zu Energieverbrauch oder CO2-Fußabdruck
✅
Nachhaltigkeit kann laut ITIL nie Teil einer Anforderung sein
❌
Nur als freiwillige Marketingaussage ohne Vertragsbezug
❌
Ausschließlich bei Hardware-Produkten relevant
Z.B. als Vorgabe zu Energieverbrauch oder CO2-Fußabdruck bei der Servicebereitstellung.
Elemente eines Serviceangebots [Begriffe]
1
❌
Waren (Goods)
✅
Zugang zu Ressourcen
✅
Service-Aktionen
✅
Ausschließlich Software-Lizenzen
Warranty-Aspekte [Begriffe]
1
❌
Verfügbarkeit
✅
Kapazität
✅
Sicherheit
✅
Grundfunktionalität (Utility)
Serviceprovider-Rollen [Begriffe]
1
❌
Ja, das ist je nach betrachtetem Service möglich
✅
Nein, eine Organisation kann laut ITIL nur eine Rolle einnehmen
❌
Nein, das gilt nur für IT-Abteilungen
❌
Nur bei staatlichen Organisationen möglich
Ja — eine Organisation kann in Bezug auf Service A Provider und in Bezug auf Service B Konsument sein.
Best Practice vs. Standard [Begriffe]
1
❌
Best Practices sind Empfehlungen, Standards meist verbindlich vorgeschrieben
✅
Beide Begriffe sind gesetzlich exakt gleichbedeutend
❌
Standards sind immer freiwillig, Best Practices verpflichtend
❌
Best Practices gelten nur für kleine Unternehmen
Best Practices sind empfohlene, bewährte Ansätze — Standards sind meist verbindlich vorgeschrieben.
Servicebeziehung eigenständig erklären [Begriffe]
1
Musterantwort: Individuelle Antwort — sollte konkret benennen, wer Provider und Konsument ist, wie der Service bereitgestellt/genutzt wird, und wie die Beziehung gepflegt wird (z.B. regelmäßige Reviews).
Utility/Warranty im Alltag [Begriffe]
1
Musterantwort: z.B. Ein Regenschirm: Utility = schützt vor Regen (Funktionalität); Warranty = hält auch bei starkem Wind, ohne kaputtzugehen (Zuverlässigkeit/Robustheit).
Kosten und Risiko im eigenen Umfeld [Begriffe]
1
Musterantwort: Individuelle Antwort — z.B. Cloud-Speicher: Risiko von Datenverlust durch Hardware-Ausfall wird vom Anbieter getragen, nicht vom Nutzer selbst.