Ü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]
5
✅
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
❌
Wertströme und Prozesse
❌
Partner und Lieferanten
✅
Organisationen und Menschen
Richtig ist D: Diese Dimension umfasst Rollen, Verantwortlichkeiten, Kompetenzen, Kommunikation und Kultur. Zu den anderen Optionen: A – Informationen und Technologie ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Wertströme und Prozesse beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Partner und Lieferanten liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Wertströme und Prozesse
❌
Partner und Lieferanten
✅
Organisationen und Menschen
❌
Informationen und Technologie
Richtig ist C: Diese Dimension umfasst Rollen, Verantwortlichkeiten, Kompetenzen, Kommunikation und Kultur. Zu den anderen Optionen: A – Wertströme und Prozesse beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Partner und Lieferanten liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Informationen und Technologie ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Merksatz:
Wo Menschen ohne klare Rollen und Organisation ohne Kultur aufeinandertreffen, herrscht Chaos – das „Menschliche Chaos“ blockiert den Erfolg, nicht die Technik.
Warum die anderen falsch sind:
Wertströme und Prozesse: Konzentriert sich auf den Ablauf von Aktivitäten und Wertschöpfungsaktivitäten, nicht auf die agierenden Personen und deren Kultur.
Partner und Lieferanten: Betrifft die Verträge und Beziehungen zu externen Drittanbietern, die hier gar keine Rolle spielen.
Informationen und Technologie: Fokussiert auf Daten, Wissen und technische Infrastruktur, die laut Fallbeschreibung explizit nicht* das Problem sind.
❌
Partner und Lieferanten
✅
Organisationen und Menschen
❌
Informationen und Technologie
❌
Wertströme und Prozesse
Richtig ist B: Diese Dimension umfasst Rollen, Verantwortlichkeiten, Kompetenzen, Kommunikation und Kultur. Zu den anderen Optionen: A – Partner und Lieferanten liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Informationen und Technologie ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Wertströme und Prozesse beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Organisationen und Menschen
❌
Informationen und Technologie
❌
Wertströme und Prozesse
❌
Partner und Lieferanten
Richtig ist A: Diese Dimension umfasst Rollen, Verantwortlichkeiten, Kompetenzen, Kommunikation und Kultur. Zu den anderen Optionen: B – Informationen und Technologie ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Wertströme und Prozesse beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Partner und Lieferanten liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
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]
5
✅
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.
❌
Organisationen und Menschen
❌
Informationen und Technologie
✅
Wertströme und Prozesse
❌
Partner und Lieferanten
Richtig ist C: Die Dimension Wertströme und Prozesse fokussiert Workflows, Aktivitäten und deren Organisation. Zu den anderen Optionen: A – Organisationen und Menschen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Informationen und Technologie liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Partner und Lieferanten ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Merksatz:
Wenn der Fluss stockt und Übergaben haken, musst du den
Strom visualisieren: „Arbeits- und Informations
fluss“ = Wert
ströme und Prozesse!
Warum die anderen falsch sind:
Organisationen und Menschen: Fokussiert sich auf Rollen, Kultur und Kompetenzen, nicht auf den Ablauf der Arbeitsschritte.
Informationen und Technologie: Betrifft die genutzten Tools und Daten (wie App oder Fahrzeugdaten), löst aber nicht das strukturelle Übergabeproblem.
- Partner und Lieferanten: Bezieht sich auf Verträge und die Zusammenarbeit mit Dritten, nicht auf den internen Arbeitsfluss der Teams.
❌
Informationen und Technologie
✅
Wertströme und Prozesse
❌
Partner und Lieferanten
❌
Organisationen und Menschen
Richtig ist B: Die Dimension Wertströme und Prozesse fokussiert Workflows, Aktivitäten und deren Organisation. Zu den anderen Optionen: A – Informationen und Technologie liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Partner und Lieferanten ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Organisationen und Menschen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Wenn der Fluss von Arbeit und Übergaben stockt, fließen die
Wertströme und Prozesse nicht rund – visualisiere den "Arbeitsfluss" wie einen Fluss, der durch Dämme (Verzögerungen) blockiert wird.
Informationen und Technologie ist falsch, weil es um den Ablauf der Zusammenarbeit geht, nicht um die genutzten Tools oder Daten.
Partner und Lieferanten ist falsch, da die Verzögerung zwischen internen Teams (Service Desk, Betrieb, Produkt) und nicht durch externe Dienstleister entsteht.
- Organisationen und Menschen ist falsch, da nicht die Teamstruktur oder Zuständigkeiten analysiert werden, sondern der konkrete Ablauf (Informationsfluss) der Tätigkeit.
✅
Wertströme und Prozesse
❌
Partner und Lieferanten
❌
Organisationen und Menschen
❌
Informationen und Technologie
Richtig ist A: Die Dimension Wertströme und Prozesse fokussiert Workflows, Aktivitäten und deren Organisation. Zu den anderen Optionen: B – Partner und Lieferanten ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Organisationen und Menschen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Informationen und Technologie liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Wenn du den
Fluss von Arbeit und Information zeichnest, folgst du dem
Strom – das ist die Dimension „Wert
ströme und Prozesse“ (Value Streams and Processes).
Warum die anderen falsch sind:
Partner und Lieferanten: Fokussiert fälschlicherweise nur auf die Verträge und Beziehungen zu den externen Plattformen, nicht auf den internen Arbeitsfluss.
Organisationen und Menschen: Betrifft die Aufbauorganisation (Organigramme, Rollen, Kultur) und nicht den sequentiellen Ablauf der Übergaben.
- Informationen und Technologie: Konzentriert sich auf die genutzten Tools und Datenbestände, nicht auf den dynamischen Prozessweg der Ticket-Bearbeitung.
❌
Partner und Lieferanten
❌
Organisationen und Menschen
❌
Informationen und Technologie
✅
Wertströme und Prozesse
Richtig ist D: Die Dimension Wertströme und Prozesse fokussiert Workflows, Aktivitäten und deren Organisation. Zu den anderen Optionen: A – Partner und Lieferanten ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Organisationen und Menschen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Informationen und Technologie liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
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
Dimensionen im Alltag [Dimensionen]
1
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.
Merksatz: Wenn du "Sourcing" hörst, denke sofort an "Partner und Lieferanten" – es geht immer um die Wahl des richtigen externen Helfers oder die Entscheidung, alles selbst zu machen. Es ist die Dimension, die den Rahmen für die Zusammenarbeit mit Dritten bildet.
Warum die anderen falsch sind:
Organisationen und Menschen: Fokus auf interne Strukturen, Rollen und Fähigkeiten.
Wertströme und Prozesse: Beschreibt die Abläufe und die Wertschöpfungskette.
- Informationen und Technologie: Bezieht sich auf Daten, Systeme und Tools.
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
Merksatz: "OP IV" –
Organisationen & Menschen,
Partner & Lieferanten,
Informationen & Technologie,
Vertströme & Prozesse. Denke an eine Operation, die vier wichtige Bereiche abdeckt, um Wert zu schaffen.
Warum die anderen falsch sind:
- (Keine anderen Optionen gegeben, da die Frage nach der Auswahl aller vier richtigen Optionen fragt. Wenn es falsche Optionen gäbe, würde hier die Begründung stehen.)
Externe Faktoren im eigenen Unternehmen [Dimensionen]
1
Übung [Dimensionen]
22
❌
Partner und Lieferanten
❌
Wertströme und Prozesse
❌
Organisationen und Menschen
✅
Information und Technologie
Die Dimension 'Information und Technologie' umfasst Daten, Informationen und Technologien.
✅
Partner und Lieferanten
❌
Information und Technologie
❌
Organisationen und Menschen
❌
Wertströme und Prozesse
Die Dimension 'Partner und Lieferanten' betrifft externe Beziehungen und Verträge.
❌
Partner und Lieferanten
❌
Wertströme und Prozesse
❌
Information und Technologie
✅
Organisationen und Menschen
Kultur, Führung, Fähigkeiten und Kommunikation gehören zur Dimension 'Organisationen und Menschen'.
Merksatz:
Menschen brauchen Vertrauen: Psychologische Sicherheit und Lernen betreffen direkt die Kultur und das Verhalten von
Personen in der
Organisation.
Warum die anderen falsch sind:
Partner und Lieferanten: Bezieht sich auf externe Verträge und Beziehungen, nicht auf die interne Teamkultur.
Wertströme und Prozesse: Fokussiert sich auf Arbeitsabläufe und Aktivitäten, nicht auf das menschliche Wohlbefinden.
- Information und Technologie: Betrifft Daten und IT-Systeme, welche keine Gefühle oder Lernprozesse besitzen.
❌
Sie legen Organisationshierarchien fest
✅
Sie zeigen, wie Aktivitäten koordiniert werden, um Wert zu schaffen und zu liefern
❌
Sie beschreiben Lieferantenverträge
❌
Sie definieren die genutzten Werkzeuge zur Überwachung
Die Dimension zeigt, wie Aktivitäten zur Wertschöpfung und -lieferung koordiniert werden.
❌
Sie ersetzen die vier Dimensionen
✅
Sie beeinflussen alle vier Dimensionen und müssen berücksichtigt werden
❌
Sie betreffen nur die Dimension Information und Technologie
❌
Sie sind für das Servicemanagement unerheblich
Externe Faktoren (PESTLE) wirken auf alle vier Dimensionen und sind zu berücksichtigen.
❌
Information und Technologie
❌
Partner und Lieferanten
✅
Organisationen und Menschen
❌
Wertströme und Prozesse
Fähigkeiten, Kultur und Kommunikation gehören zur Dimension 'Organisationen und Menschen'.
✅
Organisationen und Menschen, Informationen und Technologie, Partner und Lieferanten sowie Wertströme und Prozesse
❌
Discover, Design, Acquire und Build
❌
Grundprinzipien, Governance, Wertschöpfungskette und Practices
❌
Wert, Ergebnis, Kosten und Risiko
„vier Dimensionen des Produkt- und Servicemanagements von ITIL“ wird in den Quellen inhaltlich als „Organisationen und Menschen, Informationen und Technologie, Partner und Lieferanten sowie Wertströme und Prozesse“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
✅
Damit Produkt- und Servicemanagement ganzheitlich ausgerichtet werden und keine Dimension isoliert optimiert wird
❌
Damit Governance durch eine einzelne Dimension ersetzt wird
❌
Damit ausschließlich Technologieentscheidungen priorisiert werden
❌
Damit Wertströme ohne Menschen und Partner gestaltet werden
Die Quelle betont den ganzheitlichen Ansatz der vier Dimensionen; isolierte Optimierung passt nicht zur ITIL Logik.
❌
Wertströme und Prozesse
✅
Organisationen und Menschen
❌
Informationen und Technologie
❌
Partner und Lieferanten
Die Dimension „Organisationen und Menschen“ behandelt Struktur, Rollen, Verantwortlichkeiten, Kompetenzen und Kommunikation.
Merksatz:
Menschen arbeiten in
Organisationen – sie brauchen klare
Rollen und
Kompetenzen, um miteinander zu
kommunizieren.
Warum die anderen falsch sind:
Wertströme und Prozesse: Konzentriert sich auf Aktivitäten, Abläufe und die Wertschöpfung, nicht auf die agierenden Personen.
Informationen und Technologie: Fokussiert auf Daten, Wissen, Software und IT-Infrastruktur statt auf menschliche Strukturen.
- Partner und Lieferanten: Betrifft Verträge und die Zusammenarbeit mit externen Drittanbietern, nicht das interne Personal.
✅
Politische, wirtschaftliche, soziale, technologische, rechtliche und ökologische Faktoren
❌
Prozesse, Events, Services, Tests, Lieferanten und Ergebnisse
❌
Produkte, Experiences, Stakeholder, Teams, Levels und Effizienz
❌
Practices, Risiken, Rollen, Releases, Ressourcen und Kunden
Der Syllabus nennt PESTLE als externe Faktoren, die die vier Dimensionen beeinflussen.
Merksatz:
Denke bei
PESTLE an das englische Wort für Mörserkeule (
Pestle), mit der du die
Umwelt (ökologisch/rechtlich) und die
Gesellschaft (Politik, Wirtschaft, Soziales, Technologie) zermahlst, um die
externen Einflüsse auf dein Unternehmen zu analysieren.
Warum die anderen falsch sind:
Prozesse, Events, Services... ist falsch, da dies rein interne IT-Betriebsbegriffe sind und keine externen Umweltfaktoren beschreiben.
Produkte, Experiences, Stakeholder... ist falsch, weil diese Begriffe Elemente des Service-Designs und der Wertschöpfung sind, aber nicht das PESTLE-Muster abbilden.
- Practices, Risiken, Rollen... ist falsch, da es sich hierbei um interne Governance- und Management-Konzepte von ITIL handelt, nicht um externe Makro-Einflüsse.
❌
Organisationen und Menschen
❌
Informationen und Technologie
❌
Partner und Lieferanten
✅
Wertströme und Prozesse
Die Dimension Wertströme und Prozesse behandelt Workflows und Aktivitäten zur Wertschaffung.
Merksatz:
Denke an eine
Fabrik: Auf dem
Fließband (Prozess) fließt ein
Wertstrom aus Aktivitäten und Workflows, um das fertige Produkt zu erschaffen.
Organisationen und Menschen: Konzentriert sich auf Kultur, Rollen und Zuständigkeiten, nicht auf den Ablauf von Aktivitäten.
Informationen und Technologie: Fokussiert sich auf Wissen, Daten und IT-Systeme zur Unterstützung der Services.
- Partner und Lieferanten: Befasst sich mit Verträgen und den Beziehungen zu externen Dienstleistern.
✅
Sie umfasst Informationen, Wissen und Technologien, die für Produkte und Services benötigt werden
❌
Sie beschreibt nur Servicekonsumentenrollen
❌
Sie ersetzt die Wertschöpfungskette
❌
Sie ist identisch mit einem SLA
Die Dimension behandelt Informationen, Wissen und Technologie.
Merksatz:
„Daten, Wissen, Technik pur – das ist die IT-Dimension auf der Spur!“ Stell dir einen IT-Spezialisten vor, der mit einem Laptop (Technologie) und einem dicken Handbuch (Informationen & Wissen) den perfekten Service baut.
Falsche Konsumentenrollen: Diese gehören zur Dimension Partner und Lieferanten
bzw. Organisationen und Menschen
– Technologie ist viel umfassender als nur Nutzerrollen.
Kein Ersatz der Wertschöpfungskette: Die Service-Wertschöpfungskette (SVC) ist das zentrale Betriebsmodell von ITIL und kann niemals durch eine einzelne Dimension ersetzt werden.
- Keine Identität mit dem SLA: Ein Service Level Agreement (SLA) ist lediglich ein spezifisches Dokument zur Servicevereinbarung, keine ganzheitliche ITIL-Dimension.
❌
Kultur ersetzt alle Rollen
❌
Kultur betrifft nur Lieferanten
❌
Kultur ist ein Deployment-Verfahren
✅
Kultur ist Teil der Identität, des Images und des Erfolgs oder Misserfolgs einer Organisation
Die Quelle beschreibt Kultur als wichtigen Bestandteil organisatorischen Erfolgs.
❌
PESTLE ersetzt die vier Dimensionen
✅
Interne und externe Faktoren sollten gemeinsam und ohne feste Hierarchie betrachtet werden
❌
Technologie hat immer Vorrang vor Menschen
❌
Jede Dimension wird isoliert optimiert
Die Quelle fordert eine gemeinsame, ganzheitliche Betrachtung.
❌
Sie beschreibt nur Kultur
❌
Sie ist ein Incident
❌
Sie ist ein Known Error
✅
Die Dimension umfasst Beziehungen einer Organisation zu anderen Organisationen, die an Design, Entwicklung, Deployment, Lieferung, Support oder Verbesserung beteiligt sind
Partner und Lieferanten behandelt Organisationsbeziehungen.
✅
KI kann tiefere Einblicke, Reaktionen in Echtzeit und Automatisierung von Routineaufgaben unterstützen
❌
KI ersetzt Governance vollständig
❌
KI betrifft nur Warentransfer
❌
KI verhindert Datenqualität
KI unterstützt Entscheidungsfindung, Einblicke und Automatisierung.
Merksatz:
Stell dir KI wie einen
super-intelligenten Roboter-Assistenten vor: Er liest blitzschnell Daten für tiefe Einblicke, reagiert sofort in Echtzeit und nimmt dir die lästige Fließband-Routinearbeit ab.
Warum die anderen falsch sind:
Governance ersetzen: Ein Werkzeug kann niemals die menschliche Führung, Verantwortung und strategische Kontrolle (Governance) komplett überflüssig machen.
Nur Warentransfer: Diese extreme Einschränkung ignoriert, dass KI primär immaterielle Daten, Informationen und wissensbasierte Dienstleistungen verarbeitet.
- Datenqualität verhindern: Das Gegenteil ist der Fall; KI wird gezielt eingesetzt, um Datenfehler zu finden, zu bereinigen und die Qualität zu steigern.
✅
Eine Reihe miteinander verbundener oder interagierender Aktivitäten, die Inputs in Outputs umwandeln
❌
Eine Budgetrolle
❌
Ein digitaler Service
❌
Ein Hauptwertstrom
Prozess wird als Aktivitätenfolge zur Umwandlung von Inputs in Outputs definiert.
Merksatz:
Ein
Prozess ist wie eine
Fabrik-Maschine: Vorne wirfst du Rohstoffe (
Inputs) hinein, die Zahnräder greifen ineinander (
Aktivitäten), und hinten kommt das fertige Produkt (
Outputs) heraus.
Warum die anderen falsch sind:
Budgetrolle: Das ist eine finanzielle Zuständigkeit für Geldmittel, kein Ablauf von Aktivitäten.
Digitaler Service: Dies beschreibt das fertige Endprodukt (den Nutzen für den Kunden), nicht den Weg dorthin.
- Hauptwertstrom: Ein Wertstrom (Value Stream) ist eine übergeordnete Reise zur Wertschöpfung, die zwar Prozesse nutzt, aber nicht mit einem einzelnen Prozess gleichzusetzen ist.
✅
Management-Practices ermöglichen und unterstützen Aktivitäten der Wertschöpfungskette
❌
Aktivitäten ersetzen Practices
❌
Practices sind nur Lieferanten
❌
Wertströme sind SLA
Die Quelle beschreibt Practices als unterstützend für Aktivitäten der Wertschöpfungskette.
❌
Sie ist ein SLA
✅
Die Dimension konzentriert sich darauf, welche Aktivitäten durchgeführt werden und wie sie organisiert sind, um Wert zu ermöglichen
❌
Sie behandelt nur Kultur
❌
Sie beschreibt nur PESTLE
Die Dimension fokussiert Aktivitäten und Organisation von Workflows.
❌
Sie betreffen nur Lieferanten
❌
Sie ersetzen interne Faktoren
❌
Sie sind nur Improvement-Schritte
✅
Sie können alle vier Dimensionen beeinflussen und sollten gemeinsam betrachtet werden
Externe Faktoren beeinflussen die vier Dimensionen.
❌
Kommunikation ist nur Technologie
✅
Effektivität benötigt neben Struktur auch Kultur, Kapazität und Kompetenzen
❌
Effektivität entsteht nur durch Autorität
❌
Kultur ist irrelevant
Die Quelle nennt Struktur, Kultur, Kapazität und Kompetenzen.
Merksatz:
Menschen sind keine Maschinen – für echten Erfolg braucht ein Team nicht nur ein Organigramm, sondern das
KKK-Prinzip:
Kultur (gutes Miteinander),
Kapazität (genug Zeit) und
Kompetenz (das nötige Wissen).
Kommunikation ist nur Technologie: Falsch, weil Technologie nur das Werkzeug ist, echte Kommunikation aber auf menschlicher Interaktion und Empathie basiert.
Effektivität entsteht nur durch Autorität: Falsch, da blinder Gehorsam Motivation blockiert und moderne Zusammenarbeit auf Vertrauen statt reinem Befehlston beruht.
- Kultur ist irrelevant: Falsch, da die gemeinsame Kultur der unsichtbare Klebstoff ist, der Teams zusammenhält und die Arbeitsweise maßgeblich prägt.
❌
Menschen sind keine Dimension
✅
Entscheidungen sollten alle vier Dimensionen und relevante Faktoren berücksichtigen
❌
Nur Technologie zählt
❌
Partner werden ausgeschlossen
Der Ansatz der vier Dimensionen ist ganzheitlich.
Vier Dimensionen ganzheitlich anwenden [Dimensionen]
4
✅
Alle vier Dimensionen sollten gemeinsam betrachtet werden
❌
Partner und Lieferanten sind erst nach Transition relevant
❌
Wertströme und Prozesse ersetzen Organisationen und Menschen
❌
Informationen und Technologie ist immer ausreichend
Richtig ist A: ITIL fordert eine ganzheitliche Betrachtung der vier Dimensionen. Zu den anderen Optionen: B – Partner und Lieferanten sind erst nach Transition relevant ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Wertströme und Prozesse ersetzen Organisationen und Menschen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Informationen und Technologie ist immer ausreichend liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Wer nur an der Technik schraubt, dem wird der Erfolg geraubt – ITIL gelingt nur, wenn alle vier Dimensionen wie Zahnräder ineinandergreifen.
Warum die anderen falsch sind:
Partner erst nach Transition: Partner müssen von Anfang an (Design-Phase) eingebunden werden, um spätere Vertrags- und Schnittstellenprobleme zu vermeiden.
Wertströme ersetzen Organisationen: Prozesse können Menschen nicht ersetzen, da es ohne die richtige Organisationsstruktur und Kultur an Verantwortlichen für die Ausführung fehlt.
- Technologie ist immer ausreichend: Ein rein technologischer Fokus ignoriert die nötigen Workflows, Kompetenzen und Partner, was unweigerlich zum Scheitern des Portals führt.
❌
Partner und Lieferanten sind erst nach Transition relevant
❌
Wertströme und Prozesse ersetzen Organisationen und Menschen
❌
Informationen und Technologie ist immer ausreichend
✅
Alle vier Dimensionen sollten gemeinsam betrachtet werden
Richtig ist D: ITIL fordert eine ganzheitliche Betrachtung der vier Dimensionen. Zu den anderen Optionen: A – Partner und Lieferanten sind erst nach Transition relevant ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Wertströme und Prozesse ersetzen Organisationen und Menschen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Informationen und Technologie ist immer ausreichend liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Wertströme und Prozesse ersetzen Organisationen und Menschen
❌
Informationen und Technologie ist immer ausreichend
✅
Alle vier Dimensionen sollten gemeinsam betrachtet werden
❌
Partner und Lieferanten sind erst nach Transition relevant
Richtig ist C: ITIL fordert eine ganzheitliche Betrachtung der vier Dimensionen. Zu den anderen Optionen: A – Wertströme und Prozesse ersetzen Organisationen und Menschen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Informationen und Technologie ist immer ausreichend liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Partner und Lieferanten sind erst nach Transition relevant ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Informationen und Technologie ist immer ausreichend
✅
Alle vier Dimensionen sollten gemeinsam betrachtet werden
❌
Partner und Lieferanten sind erst nach Transition relevant
❌
Wertströme und Prozesse ersetzen Organisationen und Menschen
Richtig ist B: ITIL fordert eine ganzheitliche Betrachtung der vier Dimensionen. Zu den anderen Optionen: A – Informationen und Technologie ist immer ausreichend liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Partner und Lieferanten sind erst nach Transition relevant ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Wertströme und Prozesse ersetzen Organisationen und Menschen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Ein Tisch steht nur stabil auf allen
vier Beinen – wer beim Portal nur an die Technik denkt, stolpert über fehlende Rollen, Verträge und Prozesse.
„Informationen und Technologie ist immer ausreichend“: Falsch, da reine Software ohne passende Prozesse und geschulte Menschen im Chaos endet.
„Partner und Lieferanten sind erst nach Transition relevant“: Falsch, da externe Lieferanten von Anfang an in die Planung integriert werden müssen.
- „Wertströme und Prozesse ersetzen Organisationen und Menschen“: Falsch, da Abläufe wertlos sind, wenn keine qualifizierten Menschen da sind, die sie ausführen.
PESTLE und externe Faktoren [Dimensionen]
4
❌
Externe Faktoren betreffen nur Partner und Lieferanten
✅
Externe Faktoren können alle vier Dimensionen beeinflussen
❌
PESTLE ersetzt die vier Dimensionen
❌
Rechtliche Faktoren gehören ausschließlich zu Governance
Richtig ist B: PESTLE-Faktoren beeinflussen das Produkt- und Servicemanagement über alle Dimensionen hinweg. Zu den anderen Optionen: A – Externe Faktoren betreffen nur Partner und Lieferanten liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – PESTLE ersetzt die vier Dimensionen ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Rechtliche Faktoren gehören ausschließlich zu Governance beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Externe Faktoren können alle vier Dimensionen beeinflussen
❌
PESTLE ersetzt die vier Dimensionen
❌
Rechtliche Faktoren gehören ausschließlich zu Governance
❌
Externe Faktoren betreffen nur Partner und Lieferanten
Richtig ist A: PESTLE-Faktoren beeinflussen das Produkt- und Servicemanagement über alle Dimensionen hinweg. Zu den anderen Optionen: B – PESTLE ersetzt die vier Dimensionen ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Rechtliche Faktoren gehören ausschließlich zu Governance beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Externe Faktoren betreffen nur Partner und Lieferanten liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
PESTLE ersetzt die vier Dimensionen
❌
Rechtliche Faktoren gehören ausschließlich zu Governance
❌
Externe Faktoren betreffen nur Partner und Lieferanten
✅
Externe Faktoren können alle vier Dimensionen beeinflussen
Richtig ist D: PESTLE-Faktoren beeinflussen das Produkt- und Servicemanagement über alle Dimensionen hinweg. Zu den anderen Optionen: A – PESTLE ersetzt die vier Dimensionen ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Rechtliche Faktoren gehören ausschließlich zu Governance beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Externe Faktoren betreffen nur Partner und Lieferanten liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Rechtliche Faktoren gehören ausschließlich zu Governance
❌
Externe Faktoren betreffen nur Partner und Lieferanten
✅
Externe Faktoren können alle vier Dimensionen beeinflussen
❌
PESTLE ersetzt die vier Dimensionen
Richtig ist C: PESTLE-Faktoren beeinflussen das Produkt- und Servicemanagement über alle Dimensionen hinweg. Zu den anderen Optionen: A – Rechtliche Faktoren gehören ausschließlich zu Governance beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Externe Faktoren betreffen nur Partner und Lieferanten liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – PESTLE ersetzt die vier Dimensionen ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Merksatz:
„PESTLE-Stürme wehen durch alle vier Wände“ – Externe Faktoren (wie Datenschutz, Kundenerwartungen und Cloud-Kosten) machen an keiner Grenze halt, sondern treffen und verändern immer das gesamte Haus der vier Dimensionen (Organisation, Technologie, Partner, Prozesse).
Warum die anderen falsch sind:
Rechtliche Faktoren nur bei Governance: Ein Denkfehler, da neue Gesetze (wie die DSGVO) direkt Technologie, Verträge und Arbeitsweisen in allen Dimensionen erzwingen.
Externe Faktoren betreffen nur Partner: Zu kurz gedacht, da beispielsweise steigende Cloud-Kosten oder Kundenerwartungen auch die interne IT-Architektur und Mitarbeiterkompetenzen massiv beeinflussen.
PESTLE ersetzt Dimensionen: Ein fundamentaler Irrtum, da PESTLE die äußeren Einflüsse analysiert, während die vier Dimensionen die internen Aspekte* des Service Managements strukturieren.
Komponenten Übersicht [Value System]
1
✅
Grundprinzipien, Governance, Wertschöpfungskette, Management-Practices, Continual Improvement
❌
Wertströme, Projekte, Releases, Incidents, Changes
❌
Grundprinzipien, Governance, Discover, Deliver
❌
Produkte, Services, Kunden, Lieferanten, Partner
Die 5 Komponenten sind: Grundprinzipien, Governance, Wertschöpfungskette, Management-Practices und Continual Improvement.
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.
Merksatz:
Das Ganze ist mehr als die Summe seiner Teile: Wer „ganzheitlich“ denkt, sieht das gesamte Uhrwerk und nicht nur die einzelnen Zahnräder, damit am Ende die richtige Uhrzeit (der Wert) herauskommt.
Warum die anderen falsch sind:
Nur ein Team fokussieren: Ignoriert die notwendigen Schnittstellen und führt zu gefährlichem Silodenken.
Zusammenarbeit vermeiden: Verhindert den essenziellen Informationsfluss, der für ein funktionierendes Gesamtsystem zwingend nötig ist.
- Nur Technik berücksichtigen: Vernachlässigt die ebenso kritischen Dimensionen wie Menschen, Prozesse und Partner.
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]
1
✅
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]
1
✅
Sieben
❌
Vier
❌
Fünf
❌
Neun
Sieben Grundprinzipien.
7 Leitprinzipien — Merksatz "FIZ-KISS-O":
Fokus auf Wert
Dort anfangen, wo man steht (
Ist-Zustand nutzen)
Iterativ mit Feedback
Zusammenarbeit & Sichtbarkeit fördern
Ganzheitlich denken (Komplettbild)
Einfach & praktikabel (
Keep it simple)
- Optimieren, dann automatisieren
Merke: erst optimieren, DANN automatisieren — nie umgekehrt!
Governance [Value System]
1
✅
Evaluate, Direct, Monitor — bewerten, ausrichten, überwachen
❌
Planen, Bauen, Betreiben
❌
Design, Build, Run
❌
Kaufen, Verkaufen, Prüfen
Evaluate, Direct, Monitor (EDM) — bewerten, ausrichten, überwachen.
E-D-M — Evaluate, Direct, Monitor
Evaluate: bewerten (Lagebild verschaffen)
Direct: ausrichten (Richtung vorgeben)
- Monitor: überwachen (Fortschritt kontrollieren)
Merke: Governance gibt die Richtung vor, Management setzt um.
Practices – Begriff [Value System]
1
✅
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]
1
✅
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.
Merksatz:
Die 34 Practices sind wie
Umzugskartons: Der Inhalt bleibt komplett derselbe, sie stehen jetzt nur in anderen Zimmern (Kategorien) des neuen ITIL 5-Hauses.
Warum die anderen falsch sind:
Vollständig ersetzt: Ein fataler Denkfehler, da bewährte ITIL-Grundlagen nicht einfach über Bord geworfen werden.
Hälfte gestrichen: Falsche Annahme eines Kahlschlags; ITIL 5 optimiert die Struktur, statt wertvolles Praxiswissen zu halbieren.
- Keine neuen Inhalte: Ignoriert die kontinuierliche Weiterentwicklung, da ITIL 5 sehr wohl neue, moderne Aspekte in die bestehenden Practices integriert.
Continual Improvement [Value System]
1
✅
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]
1
✅
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?").
Merksatz: "Visionär starten, den Zielberg sehen!" – Das Continual Improvement Model beginnt immer mit der Frage nach der Vision, dem großen Ganzen, dem Gipfel, den man erreichen will. Ohne klares Ziel ist jede Verbesserung blind.
Warum die anderen falsch sind:
Wie viel kostet die Verbesserung? – Kosten sind nachrangig zur Zieldefinition, eine spätere Betrachtung.
Wer ist schuld am aktuellen Zustand? – Schuldzuweisungen sind kontraproduktiv und nicht der Startpunkt für Verbesserung.
- Wann ist die nächste Prüfung? – Dies ist ein externer Termin, nicht der interne Startpunkt für die Verbesserung.
Ganzheitlicher Ansatz [Value System]
1
✅
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]
1
✅
PESTLE-Analyse
❌
RACI-Matrix
❌
SWOT ausschließlich
❌
Gantt-Diagramm
PESTLE-Analyse (politisch, wirtschaftlich, sozial, technologisch, rechtlich, ökologisch).
Merksatz: Stell dir vor, ein
PEST (Schädling) greift dein
Landwirtschaftliches
Erzeugnis (Value System) an. Um die externen Bedrohungen zu verstehen, musst du eine
PESTLE-Analyse durchführen.
Warum die anderen falsch sind:
- RACI-Matrix: Fokus auf Rollen und Verantwortlichkeiten innerhalb von Prozessen, nicht auf externe Faktoren.
- SWOT ausschließlich: SWOT betrachtet interne Stärken/Schwächen und externe Chancen/Risiken, aber PESTLE ist spezifischer für externe Faktoren und bietet eine detailliertere Struktur.
- Gantt-Diagramm: Dient der Projektplanung und Zeitdarstellung, nicht der Analyse externer Umwelteinflüsse.
Wertorientierung [Value System]
5
✅
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.
❌
Iterative Weiterentwicklung mit Feedback
❌
Optimieren und automatisieren
❌
Auf Einfachheit und Praktikabilität achten
✅
Wertorientierung
Richtig ist D: Der Schwerpunkt liegt auf dem wahrgenommenen Nutzen und den Ergebnissen für Stakeholder. Zu den anderen Optionen: A – Iterative Weiterentwicklung mit Feedback ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; B – Optimieren und automatisieren kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; C – Auf Einfachheit und Praktikabilität achten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
„Der Kunde ist König, sein Nutzen ist der Thron“ – Wenn du Features nicht für dein eigenes Ego baust, sondern dich fragst: „Löst das ein echtes Problem und bringt es dem Kunden und uns echten Nutzen?“, dann folgst du dem Kompass der
Wertorientierung.
Warum die anderen falsch sind:
Iterative Weiterentwicklung mit Feedback: Falsch, weil es hier nicht um schrittweises Vorgehen in kleinen Schleifen geht, sondern um das grundlegende Ziel (den Nutzen) der Arbeit.
Optimieren und automatisieren: Falsch, da es nicht darum geht, bestehende Prozesse effizienter zu machen oder Technologie einzuführen, sondern die richtigen Dinge zu priorisieren.
- Auf Einfachheit und Praktikabilität achten: Falsch, da der Fokus nicht auf dem Weglassen von Komplexität liegt, sondern auf dem messbaren Mehrwert für den Anwender.
❌
Optimieren und automatisieren
❌
Auf Einfachheit und Praktikabilität achten
✅
Wertorientierung
❌
Iterative Weiterentwicklung mit Feedback
Richtig ist C: Der Schwerpunkt liegt auf dem wahrgenommenen Nutzen und den Ergebnissen für Stakeholder. Zu den anderen Optionen: A – Optimieren und automatisieren kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; B – Auf Einfachheit und Praktikabilität achten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; D – Iterative Weiterentwicklung mit Feedback ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund..
Merksatz:
„Wert ist kein internes Bauchgefühl, sondern das gelöste Problem des Kunden.“ Stell dir ein digitales Pflaster vor: Es heilt den Schmerz des Patienten (Nutzen für den Kunden) und spart der Klinik Zeit (Nutzen für den Provider) – das ist pure Wertorientierung.
Warum die anderen falsch sind:
Optimieren und automatisieren: Konzentriert sich auf die Effizienz bestehender Abläufe, nicht auf die grundlegende Ausrichtung am Kundennutzen.
Auf Einfachheit und Praktikabilität: Fokussiert das Weglassen überflüssiger Schritte, löst aber nicht primär die Frage nach dem geschaffenen Wert.
- Iterative Weiterentwicklung mit Feedback: Beschreibt das schrittweise Vorgehen in Schleifen, nicht die wertbasierte Priorisierung von Features.
❌
Auf Einfachheit und Praktikabilität achten
✅
Wertorientierung
❌
Iterative Weiterentwicklung mit Feedback
❌
Optimieren und automatisieren
Richtig ist B: Der Schwerpunkt liegt auf dem wahrgenommenen Nutzen und den Ergebnissen für Stakeholder. Zu den anderen Optionen: A – Auf Einfachheit und Praktikabilität achten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; C – Iterative Weiterentwicklung mit Feedback ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; D – Optimieren und automatisieren kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios..
Merksatz:
„Der Kunde ist König, nicht die eigene Technik-Begeisterung!“ Stell dir vor, du baust eine Brücke (Produkt) nur dort, wo Bürger tatsächlich den Fluss überqueren wollen (reale Probleme lösen), statt eine goldene Brücke im Nirgendwo zu errichten – das schafft echten
Wert für beide Seiten.
Warum die anderen falsch sind:
Auf Einfachheit und Praktikabilität achten: Falsch, weil es hier nicht um das Weglassen überflüssiger Prozessschritte geht, sondern um den grundlegenden Nutzen.
Iterative Weiterentwicklung mit Feedback: Falsch, da kein schrittweises Vorgehen in kleinen Schleifen (Sprints) oder das Einholen von Rückmeldungen beschrieben wird.
- Optimieren und automatisieren: Falsch, weil es nicht um die Effizienzsteigerung oder Technisierung eines bereits bestehenden Ablaufs geht.
✅
Wertorientierung
❌
Iterative Weiterentwicklung mit Feedback
❌
Optimieren und automatisieren
❌
Auf Einfachheit und Praktikabilität achten
Richtig ist A: Der Schwerpunkt liegt auf dem wahrgenommenen Nutzen und den Ergebnissen für Stakeholder. Zu den anderen Optionen: B – Iterative Weiterentwicklung mit Feedback ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; C – Optimieren und automatisieren kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; D – Auf Einfachheit und Praktikabilität achten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
Der
Wert steht im Fokus, wenn das Team nicht nach eigener Begeisterung bastelt, sondern sich fragt: „Löst das ein echtes Problem und bringt es dem Kunden echten Nutzen?“ (Nutzen + Ergebnis = Wertorientierung).
Iterative Weiterentwicklung mit Feedback: Falsch, weil es hier nicht um schrittweises Vorgehen in kleinen Schleifen geht, sondern um das strategische Ziel des Nutzens.
Optimieren und automatisieren: Falsch, da kein bestehender Prozess durch Technologie effizienter oder schneller gemacht wird.
- Auf Einfachheit und Praktikabilität achten: Falsch, da es nicht darum geht, Komplexität und überflüssige Schritte zu eliminieren, sondern den Nutzen zu maximieren.
Servicebetrieb [Value System]
1
✅
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.
Merksatz: Servicebetrieb ist der ITIL-Motor, der die bestehenden Services am Laufen hält und sie bei Bedarf schnell wieder repariert – wie ein zuverlässiger Mechaniker für dein Auto.
Warum die anderen falsch sind:
Ausschließlich die Konzeptionsphase neuer Services: Dies ist Service-Design, nicht der Betrieb bestehender Services.
Nur die Vertragsverhandlung mit Lieferanten: Dies ist Teil des Lieferantenmanagements, nicht des täglichen Servicebetriebs.
- Die endgültige Außerbetriebnahme eines Service: Dies ist Service-Retirement, der Abschluss, nicht die fortlaufende Unterstützung.
Releases [Value System]
1
✅
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]
1
✅
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]
1
✅
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]
1
✅
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.
CSF vs. KPI — nicht verwechseln!
CSF = das Ziel/die Voraussetzung ("Wir müssen zuverlässig liefern")
KPI = die Messzahl dafür ("MTTR < 4 Stunden")
Merke: ein CSF kann mehrere KPIs haben, aber ein KPI allein ist nie der CSF selbst.
KPI vs. CSF [Value System]
1
✅
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.
Merksatz: Der
Chef
Sucht
Fortschritt (CSF) und misst diesen mit mehreren
Klaren
Punkten der
Information (KPIs). Ein CSF ist das Ziel, die KPIs sind die Messinstrumente dafür.
Warum die anderen falsch sind:
KPI und CSF sind exakt dasselbe: Verwechselt Ziel mit Messgröße.
Ein CSF misst immer nur genau einen einzigen KPI, nie mehrere: Ignoriert die Komplexität von Zielen, die oft mehrere Indikatoren benötigen.
- KPIs sind übergeordnet, CSFs untergeordnete Details davon: Verdreht die Hierarchie; das Ziel (CSF) ist übergeordnet, die Messungen (KPIs) sind die Details.
Projektmanagement im Lebenszyklus [Value System]
1
✅
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]
1
✅
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]
1
✅
Fokus auf Wert
✅
Dort anfangen, wo man steht
❌
Automatisieren vor Optimieren
✅
Iterativ mit Feedback vorgehen
Merksatz:
„Wertvoll starten, schrittweise Feedback ernten“ – Du stehst am Anfang, blickst fest auf den Wert (Fokus auf Wert), startest genau dort, wo du stehst (Dort anfangen...) und gehst dann Schritt für Schritt mit Feedback weiter (Iterativ mit Feedback...).
Warum die anderen falsch sind:
Automatisieren vor Optimieren:* Falsch, denn die richtige Reihenfolge lautet immer erst „Optimieren und dann erst Automatisieren“ (sonst automatisiert man nur Ineffizienz).
Governance-Aktivitäten [Value System]
1
✅
Evaluate — bewerten
✅
Direct — ausrichten
✅
Monitor — überwachen
❌
Deploy — bereitstellen
Merksatz: Der Governance-Zyklus ist wie ein Kapitän auf einem Schiff: Er
evaluiert ständig die Lage,
richtet dann den Kurs
aus und
überwacht anschließend, ob das Schiff auf Kurs bleibt.
Warum die anderen falsch sind:
- Deploy – bereitstellen: Dies ist eine operative Aktivität, kein Governance-Prinzip.
Practice-Kategorien (aus ITIL 4 übernommen) [Value System]
1
✅
General Management Practices
✅
Service Management Practices
✅
Technical Management Practices
❌
Financial Compliance Practices
Merksatz:
Das ITIL-Management-Trio ist wie ein
GST-Guthaben (General, Service, Technical): Nur diese drei Säulen tragen das gesamte ITIL-Praxis-Haus – Finanzen sind darin nur ein kleiner Teilbereich, keine eigene Hauptkategorie.
Warum die anderen falsch sind:
- Financial Compliance Practices: Dies ist lediglich eine spezifische Unterfunktion (wie Financial Management) und keine der drei übergeordneten Hauptkategorien im ITIL-Framework.
Komponenten Value System [Value System]
1
✅
Governance
✅
Guiding Principles
✅
Continual Improvement
❌
Externe Marktanalyse als eigenständige Komponente
Merksatz: Das ITIL-Wertsystem ist wie ein Kompass mit drei Himmelsrichtungen: „Gouvernante“ (Governance) und „Prinzipien“ (Guiding Principles) leiten den Weg, während „Kontinuierliche Verbesserung“ (Continual Improvement) dafür sorgt, dass man immer besser wird.
Warum die anderen falsch sind:
- Externe Marktanalyse als eigenständige Komponente: Ist eher eine Eingangsgröße oder Aktivität innerhalb des Wertsystems, keine eigenständige Komponente.
Grundprinzipien im Konflikt [Value System]
1
Governance in der Praxis [Value System]
1
Merksatz:
Stell dir den Vorstand als Kapitän eines Schiffes vor:
1. Evaluate (Bewerten): Der Kapitän prüft die Seekarten und schaut, ob sich die Route durch die Karibik lohnt. ("Sollen wir da lang?")
2. Direct (Steuern): Er dreht das Steuer, setzt den Kurs auf 90 Grad Ost und gibt das Tempo vor. ("Wir fahren genau hier lang!")
3. Monitor (Überwachen): Er blickt regelmäßig auf den Kompass und das Radar, um zu prüfen, ob das Schiff auf Kurs bleibt oder ob er korrigieren muss. ("Sind wir noch auf Kurs?")
Kurz: Prüfen (Evaluate), Befehlen (Direct), Beobachten (Monitor).
Continual Improvement Model anwenden [Value System]
1
Merksatz:
Stell dir eine Bergsteigertruppe vor, die einen Gipfel bezwingt:
1. Vision: „Wir wollen auf den Mount Everest!“ (Wo wollen wir hin?)
2. Ist-Zustand: „Wir stehen im Basislager ohne Ausrüstung.“ (Wo stehen wir jetzt?)
3. Ziel: „Morgen erreichen wir Lager 1 auf 6000 Metern.“ (Wo wollen wir genau hin?)
4. Planung: „Wir packen Seile, Sauerstoff und planen die Route.“ (Wie kommen wir dorthin?)
5. Umsetzung: „Wir steigen Schritt für Schritt hinauf.“ (Maßnahmen ergreifen)
6. Erfolgskontrolle: „GPS-Check: Sind wir wirklich auf 6000 Metern?“ (Haben wir das Ziel erreicht?)
7. Dynamik: „Super! Wie halten wir den Schwung für den nächsten Gipfel?“ (Wie halten wir die Dynamik aufrecht?)
Merkwort-Kette: Sehen (Vision) – Stehen (Ist) – Wollen (Ziel) – Planen – Gehen (Umsetzen) – Messen (Erfolg) – Weiterlaufen (Dynamik).
CSF und KPI selbst formulieren [Value System]
1
Merksatz:
Der CSF (Critical Success Factor) ist das Navigationsziel (WAS wollen wir erreichen?), die KPIs (Key Performance Indicators) sind die Tachonadeln (WIE GENAU messen wir den Erfolg?).
Service: Online-Banking-App
CSF (Das Ziel): "Sicheren und schnellen Login für Kunden gewährleisten."
KPI 1 (Messwert Zeit): "Durchschnittliche Login-Dauer unter 2 Sekunden."
KPI 2 (Messwert Sicherheit): "Erfolgreiche Abwehr von Brute-Force-Angriffen zu 100%."
Eselsbrücke: Der CSF beschreibt den Traum (sicher & schnell), die KPIs liefern die nackten Zahlen (Sekunden & Prozent). Ohne Zahl ist es kein KPI!
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.
Merksatz: Eine Standard-Änderung ist wie ein "Standard-Menü" im Restaurant: Risikoarm, bekannt, immer vorab genehmigt und wiederkehrend bestellt. Man weiß genau, was man bekommt, und es läuft routiniert ab.
Warum die anderen falsch sind:
- Immer höchstes Risiko und Eilbedürftigkeit: Dies beschreibt eher eine Notfalländerung, nicht Standard.
- Nie zuvor durchgeführt: Dies wäre eine neue, möglicherweise große Änderung, die mehr Prüfung erfordert.
- Erfordert immer eine Vorstandsentscheidung: Standardänderungen sind routinemäßig und benötigen keine Eskalation auf Vorstandsebene.
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.
Merksatz: „Iterativ mit Feedback“ ist wie ein Koch, der kleine Probierhäppchen serviert, auf die Reaktion der Gäste achtet und dann das Rezept anpasst, um das perfekte Gericht zu kreieren. Ständiges Probieren, Anpassen und Verbessern basierend auf Rückmeldungen.
Warum die anderen falsch sind:
Ganzheitlich denken und arbeiten: Hier fehlt der Fokus auf die schrittweise Anpassung durch Feedback.
Einfach und praktikabel: Beschreibt eher eine Eigenschaft der Lösung, nicht den Prozess der Entwicklung.
- Dort anfangen, wo man steht: Betont den Startpunkt, nicht die iterative Verbesserungsschleife.
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
Merksatz:
Ein CSF (Critical Success Factor) ist das Fundament deines Erfolgs-Hauses, das du mit mehreren KPI-Messbändern vermisst – ein einzelnes Band (KPI) ist niemals das ganze Fundament.
Warum die anderen falsch sind:
Ein CSF ist identisch mit einem einzelnen KPI: Ein CSF ist das strategische Ziel (z. B. "Kundenzufriedenheit"), während KPIs die konkreten Metriken zur Messung sind – sie gleichzusetzen verwechselt das Ziel mit dem Maßband.
CSFs sind ausschließlich finanzieller Natur: CSFs decken alle Dimensionen ab (wie Qualität, Zeit oder Kundenzufriedenheit), da rein finanzielle Kennzahlen für den ganzheitlichen ITIL-Wertstrom viel zu kurz greifen.
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
Governance vs. Management eigenständig [Value System]
1
Practice-Kategorie zuordnen [Value System]
1
Merksatz: Der General (General Management) verhandelt die Verträge mit den externen Lieferanten (Supplier), um das gesamte Reich (die Organisation) strategisch abzusichern.
Kategorie: General Management Practices
Begründung: Supplier Management ist eine strategische, organisationsweite Disziplin. Es geht um den Aufbau und die Pflege von Beziehungen zu externen Partnern über alle Bereiche hinweg, nicht nur um rein technische Details oder den täglichen Servicebetrieb.
Continual Improvement im eigenen Team [Value System]
1
Merksatz:
Der „Schritt-für-Schritt-Kompass“ führt jedes Mini-Projekt zum Erfolg: Erst das Ziel bestimmen (Vision & Ist-Zustand), dann den Pfad planen (Soll-Zustand & Weg), den Schritt wagen (Handeln), den Erfolg messen (Ziel erreicht?) und den neuen Standard im Team einmeißeln (Schwung erhalten).
Konkretes Beispiel (Tägliches 5-Minuten-Standup):
1. Was ist die Vision? Bessere Team-Abstimmung.
2. Wo stehen wir? Informationsverlust im E-Mail-Chaos.
3. Wo wollen wir hin? Täglich kurzes, fokussiertes Update.
4. Wie kommen wir dahin? Einführung eines 5-Minuten-Standups um 9:00 Uhr.
5. Aktion ausführen: Das Standup wird zwei Wochen lang durchgeführt.
6. Haben wir das Ziel erreicht? Ja, E-Mails wurden um 30 % reduziert.
7. Wie halten wir den Schwung? Das Standup wird als fester Kalendertermin für alle verankert.
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.
Leitungsorgan [Value System]
1
✅
Es ist für Leistung und Compliance auf höchster Ebene verantwortlich
❌
Es ist für das operative Tagesgeschäft verantwortlich
❌
Es managt die technischen Details digitaler Produkte direkt
❌
Es konzentriert sich ausschließlich auf finanzielles Reporting
Das Leitungsorgan trägt die Verantwortung für Leistung und Compliance auf höchster Ebene - es steuert nicht das operative Tagesgeschäft.
Zweck und Betriebsmodell [Value System]
1
✅
Der Zweck bestimmt, warum die Organisation existiert, das Betriebsmodell zeigt, wie sie diesen Zweck erfüllt
❌
Das Betriebsmodell definiert die finanzielle Strategie zur Erreichung des Zwecks
❌
Das Betriebsmodell ersetzt den Zweck, sobald die Wertschöpfungskette definiert ist
❌
Zweck und Betriebsmodell stehen in keinem Zusammenhang zueinander
Der Zweck der Organisation bestimmt WARUM sie existiert, das Betriebsmodell zeigt WIE dieser Zweck operativ umgesetzt wird.
Event [Value System]
1
✅
Eine Statusänderung, die für das Management eines Services oder Configuration Items von Bedeutung ist
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„Event“ wird in den Quellen inhaltlich als „Eine Statusänderung, die für das Management eines Services oder Configuration Items von Bedeutung ist“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Service Request [Value System]
1
✅
Ein Request eines Anwenders oder Bevollmächtigten, der eine vereinbarte Serviceaktion einleitet
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„Service Request“ wird in den Quellen inhaltlich als „Ein Request eines Anwenders oder Bevollmächtigten, der eine vereinbarte Serviceaktion einleitet“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Known Error [Value System]
1
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein Problem, das analysiert, aber nicht gelöst wurde
„Known Error“ wird in den Quellen inhaltlich als „Ein Problem, das analysiert, aber nicht gelöst wurde“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Katastrophe [Value System]
1
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein plötzliches ungeplantes Ereignis, das einer Organisation großen Schaden oder schweren Verlust zufügt
„Katastrophe“ wird in den Quellen inhaltlich als „Ein plötzliches ungeplantes Ereignis, das einer Organisation großen Schaden oder schweren Verlust zufügt“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Eine Katastrophe ist wie ein plötzlicher, unvorhergesehener Asteroideneinschlag – er bricht ohne Vorwarnung über uns herein und hinterlässt nichts als massiven Schaden und tiefe Krater des Verlusts.
Warum die anderen falsch sind:
Das System zur Leitung und Steuerung beschreibt die Governance (Führung), nicht ein zerstörerisches Ereignis.
Die Abfolge zur Wertschöpfung definiert die Wertschöpfungskette (Service Value Chain), die planvoll und positiv besetzt ist.
Die Reihe organisatorischer Ressourcen beschreibt die Definition von Organisationen oder Ressourcen*, was strukturierte Kapazitäten statt eines unvorhergesehenen Unglücks darstellt.
Übung [Value System]
87
❌
Wertströme, Projekte, Releases, Incidents, Changes
✅
Grundprinzipien, Governance, Wertschöpfungskette, Management-Practices und Continual Improvement
❌
Produkte, Services, Kunden, Lieferanten, Partner
❌
Grundprinzipien, Governance, Discover und Deliver
Das ITIL Value System besteht aus Grundprinzipien, Governance, Wertschöpfungskette, Management-Practices und Continual Improvement.
❌
Einfach und praktisch bleiben
✅
Iterativ mit Feedback vorangehen
❌
Zusammenarbeiten und Sichtbarkeit fördern
❌
Auf Wert fokussieren
Kleine Iterationen mit Rückmeldeschleifen sind der Kern von 'Iterativ mit Feedback vorangehen'.
❌
Alle Aktivitäten sofort automatisieren
✅
Prozesse zuerst optimieren und danach automatisieren
❌
Prozesse automatisieren, bevor sie optimiert werden
❌
Menschen in allen Bereichen durch Technik ersetzen
Erst optimieren, dann automatisieren — sonst automatisiert man Ineffizienz.
✅
Man verliert wertvolle vorhandene Fähigkeiten und Ressourcen und verschwendet Zeit
❌
Man erhöht die Sicherheit der Lösung
❌
Man vereinfacht die Zusammenarbeit im Team
❌
Man beschleunigt die Feedbackaufnahme
'Beginne dort, wo du stehst' warnt davor, Bestehendes wegzuwerfen und Zeit sowie Fähigkeiten zu verlieren.
❌
Ausschließlich auf höheren Umsatz
✅
Auf den Nutzen für die Organisation, ihre Kunden und Stakeholder
❌
Auf die Zufriedenheit der Mitarbeitenden
❌
Auf einen dominierenden Marktanteil
Jede Aktivität soll einen Bezug zum Wert für Organisation, Kunden und Stakeholder haben.
❌
Stärkere Gesamtsteuerung der Risiken
✅
Unnötige Komplexität
❌
Schnellere und konsistentere Ergebnisse
❌
Mehr Transparenz für Stakeholder
Das verstößt gegen 'Einfach und praktisch bleiben' und erzeugt unnötige Komplexität.
❌
Bewerten (Evaluate)
❌
Ausrichten (Direct)
✅
Überwachen (Monitor)
❌
Entdecken (Discover)
Governance besteht aus Bewerten, Ausrichten und Überwachen; das Monitoring prüft Leistung und Konformität.
❌
Eine Abfolge von Schritten zur Erstellung und Lieferung von Produkten
✅
Eine Menge organisatorischer Ressourcen und Fähigkeiten, die für die Ausführung von Arbeit oder das Erreichen eines Ziels bestimmt ist
❌
Eine visuelle Darstellung, wie eine Organisation Wert mitgestaltet
❌
Eine Menge zusammenhängender Aktivitäten zur Produkterstellung
Eine Practice ist ein Satz von Ressourcen und Fähigkeiten für einen bestimmten Zweck.
❌
Mit der Frage 'Wo stehen wir jetzt?'
✅
Mit der Frage 'Was ist die Vision?'
❌
Mit dem Schritt 'Maßnahmen ergreifen'
❌
Mit der Frage 'Wie kommen wir voran?'
Der erste Schritt klärt die Vision, damit Verbesserungen an den Zielen der Organisation ausgerichtet sind.
❌
Was ist die Vision?
✅
Wo stehen wir jetzt?
❌
Wohin wollen wir?
❌
Maßnahmen ergreifen
Das Erheben des Ausgangszustands entspricht dem Schritt 'Wo stehen wir jetzt?'.
❌
Sie legen den Zweck und die Strategie der Organisation fest
✅
Sie stellen die für die Aktivitäten benötigten Fähigkeiten bereit
❌
Sie stellen sicher, dass Aktivitäten in fester Reihenfolge ablaufen
❌
Sie ersetzen die Aktivitäten durch standardisierte Prozesse
Practices liefern die Fähigkeiten, die die Wertschöpfungsketten-Aktivitäten ermöglichen.
✅
Indem sie strategische Absicht in koordinierte Abläufe überführen, die Ergebnisse für Stakeholder ermöglichen
❌
Indem sie Governance-Kontrollen über alle Managementebenen festlegen
❌
Indem sie feste Servicequalitätsziele vorgeben
❌
Indem sie Betriebsverfahren standardisieren und vereinheitlichen
Die Wertschöpfungsketten-Aktivitäten setzen strategische Absicht in koordinierte, wertschöpfende Abläufe um.
❌
Nacheinander in fester Reihenfolge
❌
Unabhängig voneinander
✅
Gemeinsam und je nach Situation ausbalanciert
❌
Immer alle mit gleichem Gewicht
Die Grundprinzipien werden kollektiv und situationsabhängig gewichtet angewandt.
❌
Verantwortung für Verbesserungen einem einzelnen Team zuzuweisen
✅
Alle Komponenten des Value Systems bei Entscheidungen zu berücksichtigen
❌
Wiederholbare Aufgaben zu automatisieren
❌
Nach jeder Iteration Feedback zu erfassen
Ganzheitlich denken heißt, das Zusammenspiel aller Bestandteile des Value Systems zu beachten.
Merksatz:
„Ganzheitlich“ ist wie ein Puzzle: Nur wenn du
alle Teile des gesamten Value Systems zusammenlegst, siehst du das vollständige Bild und kannst die richtige Entscheidung treffen.
Warum die anderen falsch sind:
Einzelnes Team: Widerspricht dem ganzheitlichen Ansatz, da es Silos bildet, statt das Gesamtsystem zu betrachten.
Automatisierung: Gehört zum Prinzip „Optimieren und Automatisieren“, nicht zur ganzheitlichen Betrachtung.
- Feedback nach Iteration: Ist der Kern von „Iterative Weiterentwicklung mit Feedback“, nicht des ganzheitlichen Denkens.
✅
Indem Stakeholder einbezogen und Informationen mit ihnen geteilt werden
❌
Indem Kommunikation auf das Management beschränkt wird
❌
Indem bestehende Prozesse wo möglich wiederverwendet werden
❌
Indem erst nach Projektende berichtet wird
Das Prinzip fordert Einbindung der Stakeholder und offene Informationsweitergabe.
❌
Bewerten (Evaluate)
✅
Ausrichten (Direct)
❌
Überwachen (Monitor)
❌
Umsetzen (Operate)
Direct legt Richtung und Richtlinien fest und weist Verantwortlichkeiten zu.
Merksatz:
Der
Direktor (Direct/Ausrichten) zeigt mit dem Zeigefinger die
Richtung und weist Aufgaben zu.
Bewerten (Evaluate): Prüft nur den aktuellen Zustand und die Optionen, statt aktiv Anweisungen zu erteilen.
Überwachen (Monitor): Schaut passiv zu und kontrolliert Ergebnisse, ohne selbst Richtung oder Regeln vorzugeben.
- Umsetzen (Operate): Führt die Arbeit operativ aus, statt sie aus der Governance-Perspektive zu steuern.
✅
Bewerten (Evaluate)
❌
Ausrichten (Direct)
❌
Überwachen (Monitor)
❌
Entdecken (Discover)
Evaluate bewertet Organisation, Strategie und Portfolios als Grundlage für Direct und Monitor.
Merksatz:
Wer
bewertet, der testet – um den Wert der Strategie zu ermitteln, musst du sie zuerst genau
bewerten (
Evaluate).
Warum die anderen falsch sind:
Ausrichten (Direct) gibt die Richtung und Richtlinien vor, statt den Ist-Zustand zu analysieren.
Überwachen (Monitor) kontrolliert nur laufend die Einhaltung der Vorgaben, statt die Strategie selbst zu hinterfragen.
- Entdecken (Discover) ist keine offizielle Governance-Aktivität im ITIL-Modell (EDM: Evaluate, Direct, Monitor).
✅
Er definiert messbare Zielzustände auf Basis der Vision
❌
Er erhebt den Ist-Zustand
❌
Er setzt Maßnahmen um
❌
Er prüft den Fortschritt
'Wohin wollen wir?' legt messbare Zielzustände fest, abgeleitet aus Vision und Ist-Analyse.
✅
Um Organisationen das Verstehen und Anwenden verschiedener Practices zu erleichtern
❌
Um eine feste Reihenfolge der Umsetzung zu erzwingen
❌
Um einheitliche Werkzeuge vorzuschreiben
❌
Um die Flexibilität der Einführung einzuschränken
Die einheitliche Struktur erleichtert Verständnis und Anwendung unterschiedlicher Practices.
❌
Die Ursachen von Incidents dauerhaft beseitigen
✅
Die negativen Auswirkungen von Incidents minimieren, indem der Normalbetrieb schnellstmöglich wiederhergestellt wird
❌
Genehmigung und Planung von Changes
❌
Vordefinierte Anwenderanfragen bearbeiten
Incident Management minimiert die Auswirkung von Incidents durch möglichst schnelle Wiederherstellung des Normalbetriebs.
❌
Incidents schnell wiederherstellen
✅
Die Wahrscheinlichkeit und Auswirkung von Incidents durch Analyse von Ursachen und Verwaltung von Workarounds und bekannten Fehlern verringern
❌
Changes autorisieren
❌
Serviceniveaus vereinbaren
Problem Management senkt Wahrscheinlichkeit/Impact von Incidents über Ursachenanalyse, Workarounds und Known Errors.
✅
Die Zahl erfolgreicher Service- und Produktänderungen maximieren, indem Risiken bewertet, Changes autorisiert und der Zeitplan gesteuert wird
❌
Den Servicedesk als zentrale Anlaufstelle betreiben
❌
Informationssicherheit gewährleisten
❌
Lieferantenverträge verhandeln
Change Enablement maximiert erfolgreiche Changes durch Risikobewertung, Autorisierung und Zeitplansteuerung.
❌
Service Level Management
✅
Service Desk
❌
Supplier Management
❌
Continual Improvement
Der Service Desk ist der zentrale Kontaktpunkt (Single Point of Contact) für Anwender.
Merksatz:
Der
Service Desk ist dein persönlicher
„Service-Tresen“ – die zentrale Anlaufstelle, an der Anwender und Anbieter direkt miteinander sprechen, um Fragen und Probleme zu klären.
Warum die anderen falsch sind:
Service Level Management verhandelt und überwacht nur Service-Zusagen (SLA), führt aber keine tägliche Nutzerkommunikation.
Supplier Management kümmert sich ausschließlich um externe Lieferanten und Verträge, nicht um die Anwender.
- Continual Improvement optimiert Services und Prozesse im Hintergrund, statt als direkter Kommunikationskanal zu dienen.
❌
Verträge mit Lieferanten zu steuern
✅
Klare, geschäftsbasierte Serviceziele zu setzen und Leistung dagegen zu überwachen und zu steuern
❌
Incidents zu beheben
❌
Releases bereitzustellen
Service Level Management setzt geschäftsbasierte Ziele und überwacht/steuert die Leistung dagegen.
✅
Die Vertraulichkeit, Integrität und Verfügbarkeit der Informationen der Organisation zu schützen
❌
Serviceanfragen zu bearbeiten
❌
Wertströme abzubilden
❌
Prototypen zu erstellen
Information Security Management schützt Vertraulichkeit, Integrität und Verfügbarkeit von Informationen.
✅
Deployment verschiebt Komponenten in Zielumgebungen; Release macht neue oder geänderte Funktionen für die Nutzung verfügbar
❌
Beide bezeichnen exakt dasselbe
❌
Deployment betrifft nur Hardware, Release nur Software
❌
Release verschiebt Komponenten, Deployment gibt sie zur Nutzung frei
Deployment bewegt Komponenten in Umgebungen; Release stellt Funktionen zur Nutzung bereit — beides ist entkoppelt.
✅
Sicherzustellen, dass Lieferanten und deren Leistung so gesteuert werden, dass nahtlose, hochwertige Produkte und Services entstehen
❌
Die Vision der Organisation festzulegen
❌
Anwender bei Incidents zu unterstützen
❌
Wertströme zu identifizieren
Supplier Management steuert Lieferanten und deren Leistung für nahtlose Servicequalität.
❌
Ein dokumentierter Service Level zwischen Provider und Kunde
❌
Eine Liste einzelner Prozesse ohne Governance
✅
Ein System, das beschreibt, wie alle Komponenten und Aktivitäten einer Organisation zusammenarbeiten, um Wertschöpfung zu ermöglichen
❌
Eine Technik zur visuellen Darstellung von Wertströmen
„ITIL Value System (ITIL VS)“ wird in den Quellen inhaltlich als „Ein System, das beschreibt, wie alle Komponenten und Aktivitäten einer Organisation zusammenarbeiten, um Wertschöpfung zu ermöglichen“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Discover, Design, Acquire, Build und Transition
❌
Utility, Warranty, User Experience und Nachhaltigkeit
❌
Sponsor, Kunde, Anwender und Service Provider
✅
Grundprinzipien, Governance, Wertschöpfungskette, Management-Practices und Continual Improvement
Der Syllabus nennt diese fünf Komponenten des ITIL Value Systems.
✅
Alles sollte direkt oder indirekt auf Wert für Stakeholder ausgerichtet sein
❌
Alle Entscheidungen sollten ausschließlich interne Effizienz erhöhen
❌
Verbesserungen sollten erst nach vollständiger Automatisierung beginnen
❌
Bestehende Services sollten ohne Betrachtung der Konsumenten optimiert werden
Das Grundprinzip fokussiert Wert für Stakeholder und verlangt, Servicekonsumenten zu verstehen.
❌
Alle bestehenden Elemente sollten vor einer Verbesserung verworfen werden
❌
Verbesserungen sollten ohne Bewertung des Ist-Zustands starten
❌
Messungen sollten erst nach Abschluss der Initiative erfolgen
✅
Bestehende Services, Prozesse, Programme, Projekte und Menschen sollten untersucht und sinnvoll genutzt werden
Das Prinzip empfiehlt, den aktuellen Zustand objektiv zu bewerten und vorhandene nützliche Elemente zu nutzen.
✅
Arbeit in kleinere Abschnitte aufteilen und Feedback zur Anpassung nutzen
❌
Eine einzige große Veränderung ohne Zwischenfeedback planen
❌
Feedback nur nach vollständigem Rollout sammeln
❌
Iterationsschleifen vermeiden, wenn Unsicherheit besteht
Die Quelle beschreibt iterative Arbeit und Feedback als Mittel, Fortschritt zu prüfen und Richtung anzupassen.
Merksatz:
Denk an ein
Navi beim Wandern: Du gehst in kleinen Etappen (Iterationen) und checkst nach jedem Teilstück die Karte (Feedback), statt blind bis zum Abgrund durchzumarschieren.
Warum die anderen falsch sind:
Einzige große Veränderung: Ist das riskante „Big Bang“-Prinzip, das unkontrollierbare Fehler provoziert und Feedback völlig ignoriert.
Feedback erst nach Rollout: Kommt viel zu spät, da Fehler bereits teuer im Live-System gelandet sind und nicht mehr frühzeitig korrigiert werden können.
- Iterationsschleifen vermeiden bei Unsicherheit: Genau das Gegenteil ist richtig; gerade bei Unsicherheit braucht man kurze Schleifen, um das Risiko durch schnelles Lernen zu minimieren.
❌
Ausschließliche Steuerung durch formale Hierarchie
✅
Ein gemeinsames Verständnis, Beteiligung relevanter Stakeholder und sichtbare Arbeit
❌
Reduzierte Sichtbarkeit, damit Teams ungestört arbeiten
❌
Entscheidungen ohne Servicekonsumenten und Partner
Das Prinzip betont Zusammenarbeit, Transparenz und die Einbindung relevanter Stakeholder.
✅
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
❌
Eine Methode zum Lenken und Steuern einer Organisation
„Governance“ wird in den Quellen inhaltlich als „Ein System zur Leitung, Steuerung und Überwachung einer Organisation“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Governance ist das Lenkrad, Steuer und Überwachungs-Radar der Organisation – merk dir das Trio: Leitung, Steuerung, Überwachung (L-S-Ü).
Eine Abfolge von Aktivitäten... beschreibt die Wertschöpfungskette (Value Chain), nicht die Führungsebene.
Eine Reihe organisatorischer Ressourcen... definiert Service-Management-Fähigkeiten und das Betriebssystem, nicht die übergeordnete Richtlinienkompetenz.
Eine Methode zum Lenken... greift zu kurz, da eine bloße „Methode“ (Werkzeug) nicht das umfassende, dauerhafte System* aus Strukturen und Kontrollen abbildet.
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
❌
Eine Methode zum Lenken und Steuern einer Organisation
✅
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Wertschöpfungskette“ wird in den Quellen inhaltlich als „Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Die Wertschöpfungskette ist die „Transformations-Fabrik“: Vorne geht die Nachfrage rein, hinten kommt der Wert raus – eine lückenlose Kette von Aktivitäten, die Wünsche in echten Nutzen verwandelt.
Warum die anderen falsch sind:
System zur Leitung...: Das beschreibt die Governance (Führung), nicht den operativen Fluss der Wertschöpfung.
Reihe organisatorischer Ressourcen...: Dies definiert Organisationen oder Kapazitäten, die zwar Werkzeuge sind, aber selbst keine Aktivitäten-Abfolge darstellen.
Methode zum Lenken...: Dies ist ebenfalls Teil der Governance* und des Managements, nicht die eigentliche Kette der wertschöpfenden Schritte.
✅
Eine Beschreibung der Anforderungen an ein Produkt
❌
Eine ungeplante Unterbrechung eines Services
❌
Ein Problem, das analysiert, aber nicht gelöst wurde
❌
Eine dokumentierte Vereinbarung über Service Levels
„Produktspezifikation“ wird in den Quellen inhaltlich als „Eine Beschreibung der Anforderungen an ein Produkt“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Statusänderung eines Configuration Items
❌
Eine notwendige Voraussetzung für Resultate
✅
Ein Modell eines Produkts, das verwendet wird, um Konzepte zu testen und Feedback zu erhalten
❌
Eine Reihe von Management-Practices
„Produktprototyp“ wird in den Quellen inhaltlich als „Ein Modell eines Produkts, das verwendet wird, um Konzepte zu testen und Feedback zu erhalten“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine ungeplante Unterbrechung oder Qualitätsminderung eines Services
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Incident“ wird in den Quellen inhaltlich als „Eine ungeplante Unterbrechung oder Qualitätsminderung eines Services“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Ein Incident ist der „Unfall“ (Accident) im IT-Verkehr – er bremst den Service ungeplant aus oder beschädigt seine Qualität.
Warum die anderen falsch sind:
Wertumwandlung: Beschreibt die Wertschöpfungskette (Service Value Chain), nicht die Störung selbst.
Ressourcen und Fähigkeiten: Definiert eine Organisation oder Praxis, die zur Arbeit benötigt wird.
System zur Steuerung: Beschreibt die Governance* (Führung und Überwachung) des gesamten Unternehmens.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Reihe von Techniken und Tools, die Codeänderungen häufig in ein zentrales Repository integrieren, gefolgt von automatisierten Builds und Tests
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Continuous Integration“ wird in den Quellen inhaltlich als „Eine Reihe von Techniken und Tools, die Codeänderungen häufig in ein zentrales Repository integrieren, gefolgt von automatisierten Builds und Tests“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Continuous Integration ist wie das automatische Einsortieren (Integrieren) von Puzzleteilen in eine Kiste (Repository), die sofort geprüft (Build/Test) wird, damit das Bild immer passt.
Warum die anderen falsch sind:
Ressourcen und Fähigkeiten: Das beschreibt die allgemeine Definition einer „Organisation“ oder von „Service Management“, nicht die CI-Technik.
System zur Leitung/Steuerung: Das ist die Definition von „Governance“ (Führung/Steuerung).
Aktivitäten zur Wertumwandlung:* Das beschreibt die „Service-Wertschöpfungskette“ (Service Value Chain).
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Reihe von Techniken und Tools, die es ermöglicht, Softwareupdates jederzeit in die Produktion zu überführen
„Continuous Delivery“ wird in den Quellen inhaltlich als „Eine Reihe von Techniken und Tools, die es ermöglicht, Softwareupdates jederzeit in die Produktion zu überführen“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Continuous Delivery ist wie ein vollgetankter Lieferwagen, der dank moderner
Technik und Tools jederzeit bereitsteht, um
Softwareupdates direkt an die
Produktionsrampe zu liefern.
Warum die anderen falsch sind:
- Leitung, Steuerung und Überwachung: Das beschreibt die Governance (Führungssystem) der Organisation, nicht die Softwarebereitstellung.
- Abfolge von Aktivitäten zur Wertschöpfung: Das definiert die Service-Wertschöpfungskette (Service Value Chain) als Ganzes.
- Ressourcen und Fähigkeiten: Das ist die Definition von Service Management an sich, kein spezifischer Delivery-Ansatz.
❌
Governance ist nur Wertstromdarstellung
✅
Governance lenkt und überwacht, damit Organisationen Ziele erreichen und Wert ermöglichen
❌
Governance ersetzt Practices durch Projektpläne
❌
Governance besteht nur aus Service Requests
Governance leitet, steuert und überwacht mit befähigender Rolle im ITIL VS.
Merksatz:
Governance ist der Kapitän am Steuer: Er
lenkt das Schiff und
überwacht den Kurs, damit die Mannschaft sicher das Ziel erreicht und wertvolle Fracht liefert.
Warum die anderen falsch sind:
Nur Wertstromdarstellung: Das greift viel zu kurz, da Wertströme (Value Streams) nur operative Werkzeuge und nicht die übergeordnete Führungsebene sind.
Ersetzt Practices durch Projektpläne: Ein fataler Denkfehler, da Governance Praktiken niemals abschafft, sondern diese strategisch ausrichtet und steuert.
- Besteht nur aus Service Requests: Dies verwechselt die strategische Führungsebene (Governance) mit simplen, operativen Standardanfragen des Alltagsgeschäfts.
❌
Feedback wird erst am Ende genutzt
✅
Das Ganze sollte verstanden und Arbeit über alle vier Dimensionen hinweg koordiniert werden
❌
Nur ein Prozess wird isoliert verbessert
❌
Transparenz bleibt nur beim Leitungsgremium
Das Prinzip fordert Betrachtung der Gesamtsituation und der vier Dimensionen.
Merksatz:
Wer „ganzheitlich“ denkt, sieht den ganzen Wald statt nur einen Baum: Stell dir ein vierbeiniges Pferd vor – bricht ein Bein (eine der 4 Dimensionen) weg, stürzt das ganze Pferd. Nur wenn alle vier Beine koordiniert zusammenarbeiten, läuft das System stabil.
Warum die anderen falsch sind:
Feedback erst am Ende: Verhindert agiles Gegensteuern und führt zu späten, teuren Fehlern.
Isolierter Prozess: Erzeugt Silodenken und optimiert nur ein Einzelteil auf Kosten des Gesamtsystems.
- Transparenz nur beim Leitungsgremium: Blockiert die notwendige Zusammenarbeit und das Vertrauen der operativen Teams.
❌
Wertorientierung durch Dokumentationsumfang ersetzen
✅
Nur das Nötige tun und unnötige Komplexität vermeiden
❌
Alle Kontrollen ohne Nutzen einführen
❌
Arbeit ohne Analyse duplizieren
Das Prinzip betont Einfachheit und Praktikabilität.
❌
Automatisierung nur für Governance einsetzen
❌
Optimierung vermeiden
✅
Zuerst optimieren und dann Automatisierung sinnvoll einsetzen
❌
Jede Aktivität sofort automatisieren
Die Quelle beschreibt Optimierung vor Automatisierung.
❌
Immer nur ein Grundprinzip darf angewendet werden
❌
Sie gelten nur für Continual Improvement
❌
Sie ersetzen die Wertschöpfungskette
✅
Sie sollten gemeinsam angewendet und an den Kontext angepasst werden
Die Grundprinzipien wirken zusammen und werden kontextabhängig angewendet.
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Version eines Services oder anderen Configuration Items, die zur Nutzung bereitgestellt wird
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Release“ wird in den Quellen inhaltlich als „Eine Version eines Services oder anderen Configuration Items, die zur Nutzung bereitgestellt wird“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Aktivität, mit der überprüft wird, ob ein Produkt, Service oder anderes Configuration Item Anforderungen erfüllt
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Test“ wird in den Quellen inhaltlich als „Eine Aktivität, mit der überprüft wird, ob ein Produkt, Service oder anderes Configuration Item Anforderungen erfüllt“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Reihe von Techniken und Tools, die jede Änderung, die automatisierte Tests bestanden hat, ohne zusätzliche Autorisierung automatisch in die Produktionsumgebung deployt
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Continuous Deployment“ wird in den Quellen inhaltlich als „Eine Reihe von Techniken und Tools, die jede Änderung, die automatisierte Tests bestanden hat, ohne zusätzliche Autorisierung automatisch in die Produktionsumgebung deployt“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
✅
Die Fähigkeit eines Produkts, Services oder anderen Configuration Items, seine vorgesehene Funktion für einen festgelegten Zeitraum oder eine festgelegte Anzahl von Zyklen auszuführen
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„Zuverlässigkeit“ wird in den Quellen inhaltlich als „Die Fähigkeit eines Produkts, Services oder anderen Configuration Items, seine vorgesehene Funktion für einen festgelegten Zeitraum oder eine festgelegte Anzahl von Zyklen auszuführen“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
✅
Eine Disziplin, die Aspekte der Softwareentwicklung auf Infrastruktur- und Betriebsprobleme anwendet
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„Site Reliability Engineering (SRE)“ wird in den Quellen inhaltlich als „Eine Disziplin, die Aspekte der Softwareentwicklung auf Infrastruktur- und Betriebsprobleme anwendet“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
SRE ist die Brücke von Software zur Realität der Erde (Infrastruktur): Stell dir einen Software-Entwickler vor, der mit Code-Schraubenschlüsseln die physischen Server repariert und betreibt.
Falsch: Ein System zur Leitung, Steuerung und Überwachung einer Organisation beschreibt die Governance (Führungsebene), nicht die technische Betriebsebene.
Falsch: Die Abfolge zur Umwandlung von Nachfrage in Wert definiert die Service-Wertschöpfungskette (Service Value Chain), keinen konkreten IT-Ansatz.
Falsch: Ressourcen und Fähigkeiten zur Durchführung von Aufgaben beschreiben allgemein Organisationen und Menschen oder Ressourcen*, nicht die spezifische SRE-Disziplin.
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Die Fähigkeit, den internen Zustand eines komplexen Systems anhand externer Outputs wie Metriken, Protokolle, Log-Dateien und Traces zu verstehen
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Observability (Beobachtbarkeit)“ wird in den Quellen inhaltlich als „Die Fähigkeit, den internen Zustand eines komplexen Systems anhand externer Outputs wie Metriken, Protokolle, Log-Dateien und Traces zu verstehen“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
✅
Eine Ursache oder mögliche Ursache für einen oder mehrere Incidents
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„Problem“ wird in den Quellen inhaltlich als „Eine Ursache oder mögliche Ursache für einen oder mehrere Incidents“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein Mangel oder eine Schwachstelle, der bzw. die zu Incidents führen kann
„Fehler“ wird in den Quellen inhaltlich als „Ein Mangel oder eine Schwachstelle, der bzw. die zu Incidents führen kann“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Ein Fehler ist die offene Falltür (Schwachstelle) im Boden – wer hineinstolpert, erleidet einen Unfall (Incident).
Warum die anderen falsch sind:
System zur Leitung... beschreibt die Governance (Führungsebene), nicht den operativen Fehler.
Abfolge von Aktivitäten... definiert die Wertschöpfungskette (Value Chain) zur Wertgenerierung.
Reihe organisatorischer Ressourcen... meint die Fähigkeiten* (Capabilities) und Ressourcen einer Organisation zur Serviceerbringung.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Darstellung, wie eine Organisation Wert schafft und betrieben wird
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Betriebsmodell“ wird in den Quellen inhaltlich als „Eine Darstellung, wie eine Organisation Wert schafft und betrieben wird“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Das Betriebsmodell ist das
„Fotoalbum des Erfolgs“: Es zeigt das gesamte Bild,
wie die Organisation im Alltag läuft (
betrieben wird) und dabei
Wert schafft.
Ressourcen und Fähigkeiten: Beschreibt nur die Werkzeuge (Service Management), nicht das gesamte Modell.
Leitung, Steuerung und Überwachung: Das ist Governance (Führung), nicht das operative Betriebsmodell.
- Abfolge von Aktivitäten: Das ist die Service-Wertschöpfungskette (Value Chain), also nur der Prozessweg, nicht das Gesamtbild.
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Methode zum Lenken und Steuern einer Organisation
✅
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Management-Practice“ wird in den Quellen inhaltlich als „Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Es ist ein Fragenkatalog
✅
Es unterstützt Organisationen dabei, Produkte und Services zu managen und gemeinsame Wertschöpfung zu ermöglichen
❌
Es ersetzt Servicebeziehungen durch Projekte
❌
Es beschreibt nur technische Architektur
Das ITIL VS beschreibt das Zusammenwirken der Komponenten zur Wertschöpfung.
❌
Alle Practices gehören nur zur Governance
❌
Practices sind nicht Bestandteil des ITIL VS
✅
ITIL unterscheidet allgemeine Practices sowie Produkt- und Servicemanagement-Practices
❌
ITIL unterscheidet nur technische und finanzielle Practices
Der Syllabus nennt diese Practice-Gruppen.
❌
Sie ersetzen Grundprinzipien
❌
Sie werden nur außerhalb des ITIL VS verwendet
❌
Sie sind ausschließlich SLAs
✅
Sie unterstützen die Wertschöpfungskette und helfen, Qualität von Produkten und Services sicherzustellen
Practices unterstützen die Wertschöpfungskette.
❌
Sie ersetzen Servicekonsumenten
❌
Sie gelten nur für PRINCE2
✅
Sie bieten detaillierte Leitlinien für Practices und deren Integration in das ITIL VS
❌
Sie sind nur Syllabus-Gewichtung
Practice-Leitfäden bieten detaillierte Leitlinien.
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein Mittel zur Messung oder Bewertung einer Aktivität, eines Produkts, Services oder einer anderen Einheit
„Messgröße“ wird in den Quellen inhaltlich als „Ein Mittel zur Messung oder Bewertung einer Aktivität, eines Produkts, Services oder einer anderen Einheit“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Das Massband für den Messwert: Eine Messgröße ist immer das konkrete Mittel zum Messen und Bewerten.
Warum die anderen falsch sind:
Leitung/Steuerung: Das beschreibt die Governance (Führungsebene), nicht das Messen selbst.
Abfolge von Aktivitäten: Das ist die Definition der Wertschöpfungskette (Service Value Chain).
Ressourcen und Fähigkeiten: Das definiert die Service-Management-Kapazität* (Organisation als Ganzes).
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine notwendige Voraussetzung für das Erreichen angestrebter Resultate
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Kritischer Erfolgsfaktor (CSF)“ wird in den Quellen inhaltlich als „Eine notwendige Voraussetzung für das Erreichen angestrebter Resultate“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
✅
Schritt 1
❌
Schritt 3
❌
Schritt 5
❌
Schritt 7
Schritt 1 verknüpft Verbesserungen mit Vision und Zielen.
Merksatz:
Der
1. Blick geht immer zum Horizont – am Anfang (Schritt 1) steht die Vision.
Schritt 3 ist falsch: Hier plant man den Weg ("Wie kommen wir dahin?"), anstatt das ferne Ziel (die Vision) zu definieren.
Schritt 5 ist falsch: Hier handelt man bereits ("Wie gelangen wir dorthin?"), was die konkrete Umsetzung und nicht die strategische Vision betrifft.
- Schritt 7 ist falsch: Hier feiert man den Erfolg ("Wie halten wir den Schwung aufrecht?"), nachdem die Vision längst realisiert wurde.
❌
Schritt 4
❌
Schritt 6
✅
Schritt 2
❌
Schritt 1
Schritt 2 bewertet den Ist-Zustand.
✅
Schritt 3
❌
Schritt 2
❌
Schritt 5
❌
Schritt 7
Schritt 3 definiert das nächste Ziel.
Merksatz:
Denk an ein
3-Sterne-Restaurant als dein Traumziel: Bei Schritt
3 fragst du dich, wo du hinwillst („Wo wollen wir hin?“ = Zieldefinition).
Schritt 2 ist falsch, weil man hier erst den aktuellen Stand ermittelt („Wo stehen wir jetzt?“), statt das Ziel festzulegen.
Schritt 5 ist falsch, weil hier bereits gehandelt wird („Wie kommen wir dahin?“), anstatt nur das Ziel zu definieren.
- Schritt 7 ist falsch, weil dies der allerletzte Schritt zur Dynamik-Erhaltung ist („Wie halten wir den Schwung aufrecht?“).
❌
Schritt 1
❌
Schritt 6
❌
Schritt 7
✅
Schritt 4
Schritt 4 plant den Weg zur Verbesserung.
Merksatz:
Bei Schritt
4 machen wir uns auf den
Weg (wie ein Allrad-Antrieb:
4x
4 bringt uns dorthin!).
Schritt 1 („Was ist die Vision?“) klärt nur das ferne Startziel, nicht den konkreten Weg dorthin.
Schritt 6 („Haben wir das Ziel erreicht?“) prüft im Nachhinein den Erfolg, statt die Route zu planen.
- Schritt 7 („Wie halten wir den Schwung aufrecht?“) sichert den Erfolg langfristig, wenn wir schon längst da sind.
❌
Schritt 3
❌
Schritt 7
✅
Schritt 5
❌
Schritt 2
Schritt 5 setzt den Verbesserungsplan um.
Merksatz:
Bei Schritt
5 klatschen wir in die Hände (
High Five) und packen tatkräftig an, um die
Maßnahmen konkret zu ergreifen („Take action“).
Warum die anderen falsch sind:
Schritt 3 („Wo wollen wir hin?“) definiert nur das Ziel, anstatt bereits aktiv zu handeln.
Schritt 7 („Wie halten wir den Schwung aufrecht?“) sichert den Erfolg im Nachgang, statt die Maßnahme erst zu starten.
- Schritt 2 („Wo stehen wir jetzt?“) analysiert lediglich die aktuelle Ausgangslage.
❌
Schritt 5
✅
Schritt 6
❌
Schritt 1
❌
Schritt 4
Schritt 6 prüft Fortschritt.
Merksatz:
Schritt
6 ist der
Sechser-Schritt für „
Sind wir schon da?“ – Stell dir einen Wanderer vor, der nach 6 Kilometern auf die Karte schaut und fragt: „Kommen wir voran?“ (Messung des Fortschritts).
Schritt 5 („Take action“ / Maßnahmen ergreifen): Falsch, weil man hier erst losläuft, statt den Fortschritt zu überprüfen.
Schritt 1 („What is the vision?“ / Vision definieren): Falsch, da man hier nur das Startziel festlegt, ohne dass eine Bewegung stattgefunden hat.
- Schritt 4 („How do we get there?“ / Weg planen): Falsch, weil dies nur die Reiseplanung (Design) ist und noch kein realer Fortschritt gemessen werden kann.
❌
Schritt 2
❌
Schritt 3
❌
Schritt 6
✅
Schritt 7
Schritt 7 stellt Relevanz und Verankerung sicher.
Merksatz:
Am
7. Tag ruht man nicht nur, sondern fragt sich: „Wie halten wir den
Schwung (7) für immer am Laufen?“ – Schritt 7 sichert das Überleben der Verbesserung.
Warum die anderen falsch sind:
Schritt 2 (Wo stehen wir jetzt?): Analysiert nur den aktuellen Ist-Zustand, statt die Zukunft zu sichern.
Schritt 3 (Wo wollen wir hin?): Definiert lediglich die messbaren Ziel-Zustände.
- Schritt 6 (Haben wir das Ziel erreicht?): Prüft nur den Erfolg der konkreten Aktion, nicht deren langfristige Relevanz.
❌
Damit Konsumenten ausgeschlossen werden
❌
Damit Metriken nicht benötigt werden
❌
Damit Schritte immer linear bleiben
✅
Damit Verbesserungen die Ziele der Organisation unterstützen und nicht lokal oder wertarm optimieren
Ohne Vision können Verbesserungen lokal optimieren oder keinen Wert schaffen.
❌
Sie erfolgt nur am Ende
❌
Sie verhindert Messungen
✅
Sie schafft ein gemeinsames Verständnis des Ausgangspunkts und ermöglicht späteres Messen des Verbesserungsgrades
❌
Sie ersetzt den Zielzustand
Schritt 2 definiert den Ausgangspunkt und ermöglicht Messung.
Merksatz:
Wer wandert, muss wissen, wo er startet: Nur wer den Ist-Zustand (Startpunkt) kennt, kann später auf der Karte sehen, wie viele Kilometer (Verbesserungsgrad) er schon geschafft hat.
Warum die anderen falsch sind:
„Nur am Ende“: Eine Ist-Analyse gehört an den Anfang, da man sonst kein Fundament für den gesamten Verbesserungsprozess hat.
„Verhindert Messungen“: Das Gegenteil ist der Fall; sie ist die zwingende Nullmessung, die zukünftige Messungen überhaupt erst möglich macht.
- „Ersetzt den Zielzustand“: Der Startpunkt ersetzt nicht das Ziel, da man ohne Zielrichtung orientierungslos im Kreis läuft.
✅
Das Ziel ist das Erreichen der gewünschten Resultate und nicht die starre Beibehaltung einer einzigen Sichtweise
❌
Damit Messgrößen vermieden werden
❌
Damit Feedback ausgeschlossen wird
❌
Damit die Vision ignoriert wird
Die Quelle betont Offenheit für Veränderung während Schritt 5.
✅
Eine Organisation bildet Management-Aktivitäten zu einer Wertschöpfungskette, die auf ihren Zweck zugeschnitten ist
❌
Die Wertschöpfungskette ist überall identisch
❌
Das Betriebsmodell ersetzt Practices
❌
Eine Wertschöpfungskette besteht nur aus Service Requests
Die Wertschöpfungskette wird auf den Zweck der Organisation zugeschnitten.
Merksatz:
Der
Maßanzug des Erfolgs: Jede Organisation schneidert sich ihre eigene Wertschöpfungskette (Aktivitäten) exakt passend auf ihren individuellen Zweck zu – kein Einheitsbrei von der Stange!
Warum die anderen falsch sind:
„Überall identisch“ ist falsch: Jedes Unternehmen ist einzigartig; eine starre Einheitskette würde individuelle Geschäftsmodelle ignorieren und blockieren.
„Ersetzt Practices“ ist falsch: Das Betriebsmodell integriert und nutzt Practices (wie Incident Management), anstatt diese bewährten Werkzeuge abzuschaffen.
- „Besteht nur aus Service Requests“ ist falsch: Dies reduziert die gesamte Wertschöpfung fälschlicherweise auf einen einzigen, kleinen operativen Teilbereich (Standardanfragen).
❌
Sie sind immer lineare Phasen
❌
Sie ersetzen die vier Dimensionen
✅
Sie werden durch mehrere Management-Practices ermöglicht und unterstützt
❌
Sie werden nur durch ein SLA ermöglicht
Aktivitäten der Wertschöpfungskette werden durch Practices unterstützt.
❌
Incident und Problem sind identisch
✅
Ein Incident ist eine ungeplante Unterbrechung oder Qualitätsminderung; ein Problem ist eine Ursache oder mögliche Ursache für Incidents
❌
Ein Problem ist immer ein gelöster Incident
❌
Ein Incident ist ein Known Error
Incident und Problem sind unterschiedliche Konzepte.
❌
Ein Fehler ist ein SLA
❌
Ein Problem ist eine Serviceaktion
✅
Ein Fehler ist ein Mangel oder eine Schwachstelle; ein Known Error ist ein analysiertes, aber nicht gelöstes Problem
❌
Ein Known Error ist ein gelöster Incident
Die Quelle unterscheidet Fehler, Problem und Known Error.
❌
Continuous Delivery ist Governance ohne Tests
❌
Beide sind Servicekonsumentenrollen
✅
Continuous Delivery ermöglicht Softwareupdates jederzeit in Produktion; Continuous Deployment deployt bestandene Änderungen automatisch ohne zusätzliche Autorisierung
❌
Continuous Deployment ist Warentransfer
Die Definitionen unterscheiden Continuous Delivery und Continuous Deployment.
❌
Observability ist Budgetrolle
❌
Beide sind Serviceangebote
✅
SRE wendet Softwareentwicklung auf Infrastruktur- und Betriebsprobleme an; Observability nutzt externe Outputs zum Verständnis interner Systemzustände
❌
SRE ist ein SLA
SRE und Observability sind unterschiedliche Konzepte für Betrieb und Systemverständnis.
❌
Ein Service Request ist eine Ursache von Incidents
✅
Ein Service Request leitet eine vereinbarte Serviceaktion ein, die normaler Bestandteil der Servicebereitstellung ist
❌
Ein Service Request ist eine Katastrophe
❌
Ein Service Request ist ein Produktprototyp
Service Request ist ein Request für vereinbarte Serviceaktionen.
Merksatz:
Ein Service Request ist der „Normalo-Knopf“ im Alltag: Du drückst drauf (z. B. für ein neues Passwort) und startest damit eine ganz normale, vorher vereinbarte Standard-Aktion des Service-Teams.
Warum die anderen falsch sind:
Ursache von Incidents: Das wäre ein Problem (die Ursache von Störungen), während ein Request ein geplanter Standardwunsch ist.
Katastrophe: Das wäre ein schwerwiegender Major Incident oder ein Desasterszenario, kein harmloser Standard-Request.
Produktprototyp: Das gehört in die Entwicklung (Design/Transition*), ein Request ist jedoch ein bereits etablierter, operativer Service-Bestandteil.
❌
Es ist ein einzelner KI-Prompt
✅
Es stellt dar, wie eine Organisation mit Kunden und Stakeholdern Wert schafft und betrieben wird
❌
Es ist nur eine Anwenderanfrage
❌
Es ist eine Serviceunterbrechung
Betriebsmodell beschreibt Wertschöpfung und Betrieb einer Organisation.
❌
Sie enthalten nur PESTLE
❌
Sie ersetzen Glossardefinitionen
❌
Sie sind nur Mock Exams
✅
Sie unterstützen das Verständnis der Rolle einer Practice und ihre Integration in Wertströme
Practice-Leitfäden unterstützen Practices und ihre Integration.
❌
Ein KPI ist Warentransfer
✅
Ein CSF ist eine notwendige Vorbedingung; ein KPI ist eine Messgröße zur Bewertung des Erfolgs bei der Zielerreichung
❌
Ein KPI genehmigt Budget
❌
CSF und KPI sind Utility und Warranty
CSF und KPI werden im Continual Improvement Model definiert.
❌
Feedback ist nicht vorgesehen
❌
Das Modell gilt nur bei geringer Unsicherheit
✅
Die Schritte müssen nicht linear ausgeführt werden; frühere Schritte können erneut bewertet werden
❌
Die Schritte sind strikt einmalig
Die Schritte müssen nicht linear sein und können erneut bewertet werden.
✅
Der Verbesserungsplan wird umgesetzt; Aktionen und Experimente können nacheinander, gleichzeitig oder unabhängig durchgeführt werden
❌
Der Ausgangspunkt wird erstmals bewertet
❌
Die Vision wird ohne Umsetzung definiert
❌
Alle Verbesserungen werden beendet
Schritt 5 setzt den Verbesserungsplan um.
Merksatz:
Beim „Maßnahmen ergreifen“ (Take Action) wird der Plan lebendig: Wir starten die Motoren und experimentieren auf allen Bahnen gleichzeitig, nacheinander oder völlig frei, um das Ziel zu erreichen.
Warum die anderen falsch sind:
- Ausgangspunkt bewerten: Das gehört zum Schritt „Wo stehen wir jetzt?“ (Startpunkt bestimmen), nicht zur eigentlichen Umsetzung.
- Vision ohne Umsetzung: Das beschreibt lediglich den allerersten Schritt „Was ist die Vision?“ und bleibt reine Theorie.
- Verbesserungen beenden: Das widerspricht dem Prinzip der kontinuierlichen Verbesserung und beendet den Kreislauf vorzeitig, statt ihn aktiv zu gestalten.
❌
Nur das Budget wird genehmigt
❌
Ein Service Request wird erstellt
❌
Produkte werden live eingeführt
✅
Es wird geprüft, ob der aktuelle Zustand besser ist und der Vereinbarung näherkommt
Schritt 6 prüft Fortschritt.
✅
Kontinuierliches Lernen kann zur Änderung, Unterbrechung oder Neupriorisierung von Verbesserungsinitiativen führen
❌
Verbesserungen werden nie wieder betrachtet
❌
Change Management darf nicht genutzt werden
❌
Stakeholder werden nicht informiert
Schritt 7 behandelt Relevanz, Lernen und Verankerung.
✅
Das ITIL VS wird von den ITIL Grundprinzipien geleitet
❌
Grundprinzipien werden nur außerhalb genutzt
❌
Grundprinzipien ersetzen Continual Improvement
❌
Grundprinzipien sind PESTLE
Das ITIL VS wird von Grundprinzipien geleitet.
❌
Sie wird ausschließlich durch Warentransfer erreicht
❌
Sie hängt nur von einem Sponsor ab
❌
Sie wird durch den Ausschluss von Feedback erreicht
✅
Die Anpassungsfähigkeit und kontinuierliche Verbesserung des ITIL VS wird durch das Continual Improvement Model ermöglicht
Die Quelle nennt das Continual Improvement Model als Ermöglichung von Anpassungsfähigkeit und kontinuierlicher Verbesserung.
Dort beginnen, wo man steht [Value System]
4
❌
Optimieren und automatisieren
❌
Zusammenarbeiten und Transparenz fördern
✅
Dort beginnen, wo man steht
❌
Ganzheitlich denken und arbeiten
Richtig ist C: Das Team bewertet und nutzt den Ist-Zustand, bevor Änderungen geplant werden. Zu den anderen Optionen: A – Optimieren und automatisieren kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; B – Zusammenarbeiten und Transparenz fördern ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; D – Ganzheitlich denken und arbeiten ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund..
Merksatz:
„Erst den alten Werkzeugkasten prüfen, statt blind im neuen Shop zu wüten.“ Stell dir vor, du reparierst dein Auto: Du wirfst nicht sofort alle alten Schlüssel weg, sondern schaust zuerst, was noch perfekt passt – das spart Zeit und rettet Bewährtes.
Warum die anderen falsch sind:
Optimieren und automatisieren: Ist falsch, weil hier noch nichts vereinfacht oder in Code gegossen wird, sondern erst der Ist-Zustand erfasst wird.
Zusammenarbeiten und Transparenz fördern: Ist falsch, da der Fokus auf der Bestandsaufnahme der Ressourcen liegt und nicht auf der Verbesserung der Team-Kommunikation.
- Ganzheitlich denken und arbeiten: Ist falsch, da es hier um das Nutzen vorhandener Assets geht und nicht um das Verknüpfen aller Systemteile im Unternehmen.
❌
Zusammenarbeiten und Transparenz fördern
✅
Dort beginnen, wo man steht
❌
Ganzheitlich denken und arbeiten
❌
Optimieren und automatisieren
Richtig ist B: Das Team bewertet und nutzt den Ist-Zustand, bevor Änderungen geplant werden. Zu den anderen Optionen: A – Zusammenarbeiten und Transparenz fördern ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; C – Ganzheitlich denken und arbeiten ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; D – Optimieren und automatisieren kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios..
Merksatz:
Erst den alten Werkzeugkasten prüfen, bevor man teures neues Werkzeug kauft – wer Vorhandenes (Messdaten, Tools, Prozesse) scannt statt blind alles neu zu bauen, steht fest auf dem Boden der Realität und „beginnt dort, wo er steht“.
Warum die anderen falsch sind:
Zusammenarbeiten und Transparenz fördern: Falsch, weil es hier um die Bestandsaufnahme von Ressourcen geht und nicht um Teamarbeit oder den Abbau von Silos.
Ganzheitlich denken und arbeiten: Falsch, weil der Fokus auf dem Ist-Zustand der Support-Workflows liegt, nicht auf dem Zusammenspiel des gesamten Klinik-Ökosystems.
- Optimieren und automatisieren: Falsch, weil zuerst die Analyse des Bestehenden erfolgt; die eigentliche Verbesserung und Automatisierung ist erst der nächste Schritt.
✅
Dort beginnen, wo man steht
❌
Ganzheitlich denken und arbeiten
❌
Optimieren und automatisieren
❌
Zusammenarbeiten und Transparenz fördern
Richtig ist A: Das Team bewertet und nutzt den Ist-Zustand, bevor Änderungen geplant werden. Zu den anderen Optionen: B – Ganzheitlich denken und arbeiten ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; C – Optimieren und automatisieren kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; D – Zusammenarbeiten und Transparenz fördern ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
„Erst den alten Werkzeugkasten prüfen, bevor man neuen Schrott kauft.“ Stell dir vor, du willst dein Haus renovieren und sichtest im Keller zuerst deine vorhandenen Hammer und Schrauben, statt direkt teuer im Baumarkt neu zu bestellen – du startest genau dort, wo du stehst.
Warum die anderen falsch sind:
Ganzheitlich denken und arbeiten: Fokussiert das Zusammenspiel aller vier Dimensionen, nicht die bloße Bestandsaufnahme vorhandener Ressourcen.
Optimieren und automatisieren: Setzt erst
nach der Analyse an, um Prozesse effizienter zu machen, statt nur den Ist-Zustand zu prüfen.
- Zusammenarbeiten und Transparenz fördern: Zielt auf Kommunikation und Silo-Abbau ab, nicht auf das Erfassen bestehender Messdaten und Tools.
❌
Ganzheitlich denken und arbeiten
❌
Optimieren und automatisieren
❌
Zusammenarbeiten und Transparenz fördern
✅
Dort beginnen, wo man steht
Richtig ist D: Das Team bewertet und nutzt den Ist-Zustand, bevor Änderungen geplant werden. Zu den anderen Optionen: A – Ganzheitlich denken und arbeiten ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; B – Optimieren und automatisieren kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; C – Zusammenarbeiten und Transparenz fördern ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
Erst inventarisieren, dann investieren: Wer den Ist-Zustand (Messdaten, Tools, informelle Wege) vor dem Umbau scannt, wirft nichts funktionierendes weg und spart sich den teuren Neustart auf der grünen Wiese.
Warum die anderen falsch sind:
Ganzheitlich denken und arbeiten: Der Fokus liegt hier nicht auf dem Zusammenspiel aller vier Dimensionen, sondern auf der Analyse des Status quo.
Optimieren und automatisieren: Man kann nichts sinnvoll verbessern oder automatisieren, bevor man den aktuellen Ausgangspunkt verstanden hat.
- Zusammenarbeiten und Transparenz fördern: Es geht im Szenario um das Erfassen von Artefakten und Prozessen, nicht um die Einbindung von Stakeholdern oder Silo-Abbau.
Iterative Weiterentwicklung mit Feedback [Value System]
4
❌
Auf Einfachheit und Praktikabilität achten
✅
Iterative Weiterentwicklung mit Feedback
❌
Wertorientierung
❌
Dort beginnen, wo man steht
Richtig ist B: Kleine Schritte und Feedbackschleifen stehen im Mittelpunkt. Zu den anderen Optionen: A – Auf Einfachheit und Praktikabilität achten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; C – Wertorientierung ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; D – Dort beginnen, wo man steht kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios..
✅
Iterative Weiterentwicklung mit Feedback
❌
Wertorientierung
❌
Dort beginnen, wo man steht
❌
Auf Einfachheit und Praktikabilität achten
Richtig ist A: Kleine Schritte und Feedbackschleifen stehen im Mittelpunkt. Zu den anderen Optionen: B – Wertorientierung ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; C – Dort beginnen, wo man steht kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; D – Auf Einfachheit und Praktikabilität achten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
❌
Wertorientierung
❌
Dort beginnen, wo man steht
❌
Auf Einfachheit und Praktikabilität achten
✅
Iterative Weiterentwicklung mit Feedback
Richtig ist D: Kleine Schritte und Feedbackschleifen stehen im Mittelpunkt. Zu den anderen Optionen: A – Wertorientierung ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; B – Dort beginnen, wo man steht kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; C – Auf Einfachheit und Praktikabilität achten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
„Schritt für Schritt im Feedback-Loop“ – Wer in kleinen Zyklen (iterativ) baut und nach jedem Schritt die Nutzer fragt (Feedback), der tastet sich wie ein Wanderer mit Echo-Ortung sicher ans Ziel.
Warum die anderen falsch sind:
Wertorientierung: Konzentriert sich primär darauf, für wen
Nutzen geschaffen wird, nicht auf den zyklischen Prozess der Anpassung.
Dort beginnen, wo man steht: Fokussiert auf die Analyse und Nutzung des
bestehenden Ist-Zustands zu Beginn, nicht auf das fortlaufende Vorwärtstasten.
- Auf Einfachheit achten: Zielt auf das Eliminieren von Verschwendung und Komplexität ab, nicht auf den rhythmischen Regelkreis aus Aktion und Reaktion.
❌
Dort beginnen, wo man steht
❌
Auf Einfachheit und Praktikabilität achten
✅
Iterative Weiterentwicklung mit Feedback
❌
Wertorientierung
Richtig ist C: Kleine Schritte und Feedbackschleifen stehen im Mittelpunkt. Zu den anderen Optionen: A – Dort beginnen, wo man steht kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; B – Auf Einfachheit und Praktikabilität achten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; D – Wertorientierung ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund..
Merksatz:
„Schritt für Schritt im Kreis drehen und auf die Echos hören“ – Kleine Zyklen (Schritte) kombiniert mit Daten- und Feedback-Bewertung (Echos) vor dem nächsten Schritt verkörpern perfekt die Spirale der iterativen Weiterentwicklung.
Dort beginnen, wo man steht: Konzentriert sich fälschlicherweise auf die Ist-Analyse des Altsystems, statt auf den fortlaufenden, zyklischen Verbesserungsprozess.
Auf Einfachheit und Praktikabilität achten: Zielt fälschlicherweise auf das Weglassen von Komplexität ab, nicht auf das schrittweise Vorgehen mit Feedbackschleifen.
Wertorientierung:* Ist zwar das Endziel, beschreibt hier aber zu allgemein den Nutzen, statt der konkreten Methode der schrittweisen Anpassung durch Rückmeldungen.
Zusammenarbeiten und Transparenz fördern [Value System]
4
✅
Zusammenarbeiten und Transparenz fördern
❌
Ganzheitlich denken und arbeiten
❌
Wertorientierung
❌
Optimieren und automatisieren
Richtig ist A: Der Fokus liegt auf gemeinsamer Arbeit, Sichtbarkeit und Stakeholder-Einbindung. Zu den anderen Optionen: B – Ganzheitlich denken und arbeiten ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; C – Wertorientierung kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; D – Optimieren und automatisieren ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
❌
Ganzheitlich denken und arbeiten
❌
Wertorientierung
❌
Optimieren und automatisieren
✅
Zusammenarbeiten und Transparenz fördern
Richtig ist D: Der Fokus liegt auf gemeinsamer Arbeit, Sichtbarkeit und Stakeholder-Einbindung. Zu den anderen Optionen: A – Ganzheitlich denken und arbeiten ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; B – Wertorientierung kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; C – Optimieren und automatisieren ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
❌
Wertorientierung
❌
Optimieren und automatisieren
✅
Zusammenarbeiten und Transparenz fördern
❌
Ganzheitlich denken und arbeiten
Richtig ist C: Der Fokus liegt auf gemeinsamer Arbeit, Sichtbarkeit und Stakeholder-Einbindung. Zu den anderen Optionen: A – Wertorientierung kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; B – Optimieren und automatisieren ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; D – Ganzheitlich denken und arbeiten ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund..
❌
Optimieren und automatisieren
✅
Zusammenarbeiten und Transparenz fördern
❌
Ganzheitlich denken und arbeiten
❌
Wertorientierung
Richtig ist B: Der Fokus liegt auf gemeinsamer Arbeit, Sichtbarkeit und Stakeholder-Einbindung. Zu den anderen Optionen: A – Optimieren und automatisieren ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; C – Ganzheitlich denken und arbeiten ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; D – Wertorientierung kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios..
Merksatz:
Wenn alle im Dunkeln tappen und aneinander vorbeireden, reißt das Team die Wände ein, macht die Arbeit für jeden sichtbar und holt alle Partner an einen Tisch – sie
arbeiten zusammen und machen alles
transparent.
Optimieren und automatisieren: Konzentriert sich auf Effizienz und Technologie, löst aber keine menschlichen Kommunikationskonflikte.
Ganzheitlich denken und arbeiten: Schaut auf das gesamte System und die Zusammenhänge, fokussiert hier aber nicht die aktive Einbindung der Akteure.
- Wertorientierung: Richtet sich primär an den Kundenbedürfnissen und dem Nutzen aus, statt an der internen Zusammenarbeit der Teams.
Ganzheitlich denken und arbeiten [Value System]
4
❌
Dort beginnen, wo man steht
❌
Auf Einfachheit und Praktikabilität achten
❌
Iterative Weiterentwicklung mit Feedback
✅
Ganzheitlich denken und arbeiten
Richtig ist D: Das Szenario betrachtet die gesamte Arbeitsumgebung über mehrere Dimensionen hinweg. Zu den anderen Optionen: A – Dort beginnen, wo man steht ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; B – Auf Einfachheit und Praktikabilität achten kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; C – Iterative Weiterentwicklung mit Feedback ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
Das
Ganze im Blick: Wer nicht nur am Tool schraubt, sondern Rollen, Partner, Daten und Kunden wie Zahnräder zu einem Uhrwerk zusammensetzt, denkt und arbeitet
ganzheitlich – alles greift ineinander.
Dort beginnen, wo man steht: Falsch, weil es hier nicht um die Analyse und Nutzung des Ist-Zustands geht, sondern um die Breite der aktuellen Veränderung.
Auf Einfachheit und Praktikabilität achten: Falsch, da das Vermeiden von Komplexität und das Weglassen überflüssiger Schritte hier nicht im Fokus stehen.
- Iterative Weiterentwicklung mit Feedback: Falsch, da der Schwerpunkt auf der Vollständigkeit der Perspektiven liegt und nicht auf dem Vorgehen in kleinen, überprüfbaren Schritten.
❌
Auf Einfachheit und Praktikabilität achten
❌
Iterative Weiterentwicklung mit Feedback
✅
Ganzheitlich denken und arbeiten
❌
Dort beginnen, wo man steht
Richtig ist C: Das Szenario betrachtet die gesamte Arbeitsumgebung über mehrere Dimensionen hinweg. Zu den anderen Optionen: A – Auf Einfachheit und Praktikabilität achten kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; B – Iterative Weiterentwicklung mit Feedback ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; D – Dort beginnen, wo man steht ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund..
❌
Iterative Weiterentwicklung mit Feedback
✅
Ganzheitlich denken und arbeiten
❌
Dort beginnen, wo man steht
❌
Auf Einfachheit und Praktikabilität achten
Richtig ist B: Das Szenario betrachtet die gesamte Arbeitsumgebung über mehrere Dimensionen hinweg. Zu den anderen Optionen: A – Iterative Weiterentwicklung mit Feedback ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; C – Dort beginnen, wo man steht ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; D – Auf Einfachheit und Praktikabilität achten kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios..
✅
Ganzheitlich denken und arbeiten
❌
Dort beginnen, wo man steht
❌
Auf Einfachheit und Praktikabilität achten
❌
Iterative Weiterentwicklung mit Feedback
Richtig ist A: Das Szenario betrachtet die gesamte Arbeitsumgebung über mehrere Dimensionen hinweg. Zu den anderen Optionen: B – Dort beginnen, wo man steht ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; C – Auf Einfachheit und Praktikabilität achten kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; D – Iterative Weiterentwicklung mit Feedback ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
Wer Rollen, Daten, Partner und Workflows wie Puzzleteile zu einem großen Gesamtbild zusammensetzt, denkt und arbeitet
ganzheitlich – das Ganze ist mehr als nur das Tool.
Warum die anderen falsch sind:
Dort beginnen, wo man steht: Es wird kein Ist-Zustand analysiert oder Altes wiederverwendet, sondern direkt ein umfassender neuer Ansatz geplant.
Auf Einfachheit und Praktikabilität achten: Der Fokus liegt auf der Vollständigkeit aller Dimensionen, nicht auf der Reduzierung von Komplexität oder dem Weglassen von Schritten.
- Iterative Weiterentwicklung mit Feedback: Es geht hier nicht um kleine, schrittweise Verbesserungen (Schleifen) oder das Einholen von Kundenfeedback, sondern um die Breite der Betrachtung.
Auf Einfachheit und Praktikabilität achten [Value System]
4
❌
Wertorientierung
❌
Dort beginnen, wo man steht
✅
Auf Einfachheit und Praktikabilität achten
❌
Optimieren und automatisieren
Richtig ist C: Die Arbeit wird vereinfacht, ohne notwendige Kontrollen zu entfernen. Zu den anderen Optionen: A – Wertorientierung kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; B – Dort beginnen, wo man steht ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; D – Optimieren und automatisieren ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund..
❌
Dort beginnen, wo man steht
✅
Auf Einfachheit und Praktikabilität achten
❌
Optimieren und automatisieren
❌
Wertorientierung
Richtig ist B: Die Arbeit wird vereinfacht, ohne notwendige Kontrollen zu entfernen. Zu den anderen Optionen: A – Dort beginnen, wo man steht ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; C – Optimieren und automatisieren ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; D – Wertorientierung kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios..
✅
Auf Einfachheit und Praktikabilität achten
❌
Optimieren und automatisieren
❌
Wertorientierung
❌
Dort beginnen, wo man steht
Richtig ist A: Die Arbeit wird vereinfacht, ohne notwendige Kontrollen zu entfernen. Zu den anderen Optionen: B – Optimieren und automatisieren ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; C – Wertorientierung kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; D – Dort beginnen, wo man steht ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
„Schlank statt schwerfällig“: Wenn du unnötigen Ballast und sinnlose Bürokratie über Bord wirfst, um nur das Wesentliche für Sicherheit und Wert zu behalten, machst du es einfach und praktikabel – wie ein schlanker digitaler Bürgerdienst ohne Papierkram.
Warum die anderen falsch sind:
Optimieren und automatisieren: Ein falscher Fokus, da hier nichts technisch beschleunigt, sondern erst einmal überflüssiger Ballast komplett eliminiert wird.
Wertorientierung: Zu allgemein, da es hier spezifisch um das Vereinfachen von Prozessen durch das Weglassen von Schritten geht, nicht um die reine Definition von Nutzen.
- Dort beginnen, wo man steht: Unpassend, da nicht der Ist-Zustand als Startpunkt analysiert, sondern ein bestehender Prozess radikal entschlackt wird.
❌
Optimieren und automatisieren
❌
Wertorientierung
❌
Dort beginnen, wo man steht
✅
Auf Einfachheit und Praktikabilität achten
Richtig ist D: Die Arbeit wird vereinfacht, ohne notwendige Kontrollen zu entfernen. Zu den anderen Optionen: A – Optimieren und automatisieren ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; B – Wertorientierung kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; C – Dort beginnen, wo man steht ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
Merksatz:
Schlank wie ein Paket ohne Füllmaterial: Wer unnötigen Ballast und bürokratische Genehmigungen wegschneidet, bis nur noch das Wesentliche übrig bleibt, handelt nach dem Prinzip „Keep it simple“ – also
auf Einfachheit und Praktikabilität achten.
Warum die anderen falsch sind:
Optimieren und automatisieren: Konzentriert sich auf das technologische Standardisieren und maschinelle Ausführen, nicht auf das bloße Weglassen von Schritten.
Wertorientierung: Fokussiert primär darauf, den direkten Nutzen für den Kunden zu verstehen, statt interne Prozesse zu entschlacken.
- Dort beginnen, wo man steht: Befasst sich mit der Bestandsaufnahme des Ist-Zustands, statt mit dem aktiven Vereinfachen von Abläufen.
Optimieren und automatisieren [Value System]
4
❌
Ganzheitlich denken und arbeiten
✅
Optimieren und automatisieren
❌
Iterative Weiterentwicklung mit Feedback
❌
Zusammenarbeiten und Transparenz fördern
Richtig ist B: Die Reihenfolge Optimierung vor Automatisierung ist entscheidend. Zu den anderen Optionen: A – Ganzheitlich denken und arbeiten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; C – Iterative Weiterentwicklung mit Feedback ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; D – Zusammenarbeiten und Transparenz fördern kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios..
Merksatz:
Erst das Chaos aufräumen, dann den Roboter bauen – wer unnötigen Ballast abwirft und standardisiert, bevor er auf den Startknopf drückt, lebt das Prinzip
Optimieren und automatisieren.
Warum die anderen falsch sind:
Ganzheitlich denken und arbeiten: Fokussiert das Zusammenspiel aller vier Dimensionen, nicht den konkreten Ablauf einer Prozessbereinigung.
Iterative Weiterentwicklung mit Feedback: Zielt auf kleine, schrittweise Verbesserungen durch Rückmeldungen ab, nicht auf die logische Reihenfolge von Prozessvereinfachung vor Technikeinsatz.
- Zusammenarbeiten und Transparenz fördern: Betrifft die Teamarbeit und den Informationsfluss über Silogrenzen hinweg, nicht die methodische Optimierung von Arbeitsabläufen.
✅
Optimieren und automatisieren
❌
Iterative Weiterentwicklung mit Feedback
❌
Zusammenarbeiten und Transparenz fördern
❌
Ganzheitlich denken und arbeiten
Richtig ist A: Die Reihenfolge Optimierung vor Automatisierung ist entscheidend. Zu den anderen Optionen: B – Iterative Weiterentwicklung mit Feedback ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; C – Zusammenarbeiten und Transparenz fördern kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; D – Ganzheitlich denken und arbeiten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
❌
Iterative Weiterentwicklung mit Feedback
❌
Zusammenarbeiten und Transparenz fördern
❌
Ganzheitlich denken und arbeiten
✅
Optimieren und automatisieren
Richtig ist D: Die Reihenfolge Optimierung vor Automatisierung ist entscheidend. Zu den anderen Optionen: A – Iterative Weiterentwicklung mit Feedback ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund.; B – Zusammenarbeiten und Transparenz fördern kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; C – Ganzheitlich denken und arbeiten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario..
❌
Zusammenarbeiten und Transparenz fördern
❌
Ganzheitlich denken und arbeiten
✅
Optimieren und automatisieren
❌
Iterative Weiterentwicklung mit Feedback
Richtig ist C: Die Reihenfolge Optimierung vor Automatisierung ist entscheidend. Zu den anderen Optionen: A – Zusammenarbeiten und Transparenz fördern kann unterstützend wirken, beantwortet aber nicht den Schwerpunkt des Szenarios.; B – Ganzheitlich denken und arbeiten ist plausibel, beschreibt jedoch nicht die primäre Entscheidungslogik im Szenario.; D – Iterative Weiterentwicklung mit Feedback ist ein relevantes Grundprinzip, steht hier aber nicht im Vordergrund..
Discover und Business Analysis [Value System]
4
❌
Architecture Management
❌
Portfolio Management
✅
Business Analysis
❌
Risk Management
Richtig ist C: Business Analysis unterstützt das Verstehen und Dokumentieren von Bedürfnissen und Anforderungen. Zu den anderen Optionen: A – Architecture Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; B – Portfolio Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; D – Risk Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern..
❌
Portfolio Management
✅
Business Analysis
❌
Risk Management
❌
Architecture Management
Richtig ist B: Business Analysis unterstützt das Verstehen und Dokumentieren von Bedürfnissen und Anforderungen. Zu den anderen Optionen: A – Portfolio Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; C – Risk Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; D – Architecture Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt..
Merksatz:
Der
Business Analyst ist der „Bedürfnis-Dolmetscher“: Er analysiert die Wünsche (Anforderungen) der Stakeholder und übersetzt sie in konkrete Kriterien für den neuen Service.
Portfolio Management ist falsch, weil es strategisch über das gesamte Service-Budget und die Investitionen entscheidet, statt konkrete Detailanforderungen einzelner Services zu analysieren.
Risk Management ist falsch, weil es sich primär auf die Identifikation und Minimierung von Bedrohungen konzentriert, nicht auf das Verstehen von Nutzerbedürfnissen.
- Architecture Management ist falsch, weil es die technologische Struktur und das Zusammenspiel der Systeme plant, anstatt die fachlichen Akzeptanzkriterien der Stakeholder zu erheben.
✅
Business Analysis
❌
Risk Management
❌
Architecture Management
❌
Portfolio Management
Richtig ist A: Business Analysis unterstützt das Verstehen und Dokumentieren von Bedürfnissen und Anforderungen. Zu den anderen Optionen: B – Risk Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; C – Architecture Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; D – Portfolio Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
Merksatz:
Der
Analyst versteht die
Bedürfnisse: Stell dir einen Detektiv mit Lupe vor, der Stakeholder befragt, um die genauen Anforderungen und Akzeptanzkriterien für den neuen Bürgerdienst aufzudecken.
Warum die anderen falsch sind:
Risk Management: Fokussiert sich auf Bedrohungen und Unsicherheiten, nicht auf das detaillierte Verstehen von Service-Bedürfnissen.
Architecture Management: Plant die technologische Struktur und Schablonen, statt Anforderungen im direkten Stakeholder-Dialog zu erheben.
- Portfolio Management: Trifft strategische Investitionsentscheidungen über das gesamte Service-Angebot, statt konkrete Akzeptanzkriterien einzelner Dienste auszuarbeiten.
❌
Risk Management
❌
Architecture Management
❌
Portfolio Management
✅
Business Analysis
Richtig ist D: Business Analysis unterstützt das Verstehen und Dokumentieren von Bedürfnissen und Anforderungen. Zu den anderen Optionen: A – Risk Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; B – Architecture Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; C – Portfolio Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
Merksatz:
Business Analysis ist der „Übersetzer“: Sie analysiert die Wünsche der Stakeholder (Bedürfnisse, Anforderungen, Kriterien) und übersetzt sie in die Blaupause für den neuen digitalen Service.
Risk Management ist falsch, weil es Bedrohungen und Chancen steuert, statt Anforderungen für neue Services zu ermitteln.
Architecture Management ist falsch, weil es die strukturelle Gesamtlandschaft (Technologie/Prozesse) plant, statt konkrete Stakeholder-Bedürfnisse im Detail zu erheben.
- Portfolio Management ist falsch, weil es Investitionen und die strategische Service-Auswahl priorisiert, statt operative Akzeptanzkriterien einzelner Services auszuarbeiten.
Acquire und Supplier Management [Value System]
4
❌
IT Asset Management
✅
Supplier Management
❌
Architecture Management
❌
Service Financial Management
Richtig ist B: Supplier Management ist für Lieferantenbeziehungen und Vereinbarungen der deutlichste Ermöglicher. Zu den anderen Optionen: A – IT Asset Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; C – Architecture Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; D – Service Financial Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt..
Merksatz:
Wer
Cloud-Services und
externe Software einkauft, Verträge verhandelt und Partner managt, braucht den
Supplier (Lieferanten) an Bord – der
Supplier liefert die externe Power für den Mobility-Service!
IT Asset Management: Fokussiert nur auf den Lebenszyklus und Wert von physischen/virtuellen IT-Komponenten, nicht auf die Partner-Beziehung.
Architecture Management: Plant die technologische Struktur und Standards, verhandelt aber keine Verträge mit externen Anbietern.
- Service Financial Management: Verwaltet nur Budgets, Kosten und Abrechnungen, steuert aber nicht die operative Lieferanten-Zusammenarbeit.
✅
Supplier Management
❌
Architecture Management
❌
Service Financial Management
❌
IT Asset Management
Richtig ist A: Supplier Management ist für Lieferantenbeziehungen und Vereinbarungen der deutlichste Ermöglicher. Zu den anderen Optionen: B – Architecture Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; C – Service Financial Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; D – IT Asset Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
❌
Architecture Management
❌
Service Financial Management
❌
IT Asset Management
✅
Supplier Management
Richtig ist D: Supplier Management ist für Lieferantenbeziehungen und Vereinbarungen der deutlichste Ermöglicher. Zu den anderen Optionen: A – Architecture Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; B – Service Financial Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; C – IT Asset Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
Merksatz:
Wenn du
Anbieter bewertest,
Verträge verhandelst und die
Zusammenarbeit planst, managst du deine Zulieferer – das ist das
Supplier Management (Zulieferer = Suppliers).
Warum die anderen falsch sind:
Architecture Management: Fokussiert sich auf die Struktur und das Zusammenspiel von Technologie und Prozessen, nicht auf die vertragliche Beziehung zu externen Partnern.
Service Financial Management: Beschäftigt sich rein mit der Budgetierung, Kostenrechnung und Preisgestaltung, nicht mit der operativen Anbietersteuerung.
- IT Asset Management: Verwaltet den gesamten Lebenszyklus von physischen und digitalen IT-Vermögenswerten (Lizenzen, Hardware), steuert aber keine partnerschaftlichen Kooperationen.
❌
Service Financial Management
❌
IT Asset Management
✅
Supplier Management
❌
Architecture Management
Richtig ist C: Supplier Management ist für Lieferantenbeziehungen und Vereinbarungen der deutlichste Ermöglicher. Zu den anderen Optionen: A – Service Financial Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; B – IT Asset Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; D – Architecture Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern..
Build und Software Development and Management [Value System]
4
✅
Software Development and Management
❌
Service Validation and Testing
❌
Deployment Management
❌
Release Management
Richtig ist A: Die Erstellung und Änderung von Softwarefunktionen liegt primär bei Software Development and Management. Zu den anderen Optionen: B – Service Validation and Testing unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; C – Deployment Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; D – Release Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
Merksatz:
„Der Code-Bäcker knetet den Teig“ – Bevor Brötchen ausgeliefert werden, muss der Bäcker in der Backstube Zutaten mischen (Code integrieren) und die Qualität prüfen (automatisierte Tests/Builds). Das Erstellen, Integrieren und fehlerfreie Vorbereiten von Software ist die Kernarbeit der Software-Entwicklung (
Software Development and Management).
Warum die anderen falsch sind:
Service Validation and Testing: Konzentriert sich rein auf die unabhängige Qualitätsprüfung fertiger Services vor der Freigabe, nicht auf das Erstellen und Integrieren des Codes selbst.
Deployment Management: Befasst sich ausschließlich mit dem physischen Verschieben von Softwarekomponenten in verschiedene Umgebungen, nicht mit der Code-Entwicklung.
- Release Management: Plant und koordiniert die Bereitstellung von Services für die Nutzung, greift aber nicht aktiv in die Code-Erstellung oder automatisierte Builds ein.
❌
Service Validation and Testing
❌
Deployment Management
❌
Release Management
✅
Software Development and Management
Richtig ist D: Die Erstellung und Änderung von Softwarefunktionen liegt primär bei Software Development and Management. Zu den anderen Optionen: A – Service Validation and Testing unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; B – Deployment Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; C – Release Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
❌
Deployment Management
❌
Release Management
✅
Software Development and Management
❌
Service Validation and Testing
Richtig ist C: Die Erstellung und Änderung von Softwarefunktionen liegt primär bei Software Development and Management. Zu den anderen Optionen: A – Deployment Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; B – Release Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; D – Service Validation and Testing unterstützt unter Umständen, ist aber im Szenario nicht der Kern..
Merksatz:
Software-Handwerker erschaffen das Werk: Wenn ein Team Code schreibt, integriert, baut, testet und Fehler behebt, bevor überhaupt etwas verteilt wird, ist das die schöpferische Arbeit der Practice
Software Development and Management (Entwicklung & Verwaltung).
Warum die anderen falsch sind:
Deployment Management ist falsch, weil es den fertigen Code nur auf die Server verschiebt, aber nicht selbst programmiert oder baut.
Release Management ist falsch, weil es nur die Freigabe und Planung steuert, statt Code zu schreiben und Defekte zu beheben.
- Service Validation and Testing ist falsch, weil es die Qualität unabhängig prüft, aber nicht die Software selbst entwickelt oder integriert.
❌
Release Management
✅
Software Development and Management
❌
Service Validation and Testing
❌
Deployment Management
Richtig ist B: Die Erstellung und Änderung von Softwarefunktionen liegt primär bei Software Development and Management. Zu den anderen Optionen: A – Release Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; C – Service Validation and Testing unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; D – Deployment Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt..
Transition und Deployment Management [Value System]
4
❌
Service Validation and Testing
❌
Release Management
❌
Change Enablement
✅
Deployment Management
Richtig ist D: Das Überführen in die Live-Umgebung ist Deployment; Release Management steuert eher Freigabe und Bündelung. Zu den anderen Optionen: A – Service Validation and Testing unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; B – Release Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; C – Change Enablement ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
Merksatz:
Deployment ist der physische Transporteur: Er drückt den roten Knopf, um die Software-Kisten auf den Live-Laster zu laden, während das Release Management den Lieferschein schreibt und Change Enablement die Erlaubnis erteilt.
Warum die anderen falsch sind:
Service Validation and Testing: Prüft nur vorher, ob die Qualität stimmt, führt aber selbst keine Live-Überführung durch.
Release Management: Plant und paketiert die Funktionen (macht sie "ready"), ist aber nicht das technische Werkzeug für das eigentliche "Drücken des Auslösers".
- Change Enablement: Bewertet Risiken und gibt die Freigabe (das "Go"), führt die technische Migration aber nicht selbst aus.
❌
Release Management
❌
Change Enablement
✅
Deployment Management
❌
Service Validation and Testing
Richtig ist C: Das Überführen in die Live-Umgebung ist Deployment; Release Management steuert eher Freigabe und Bündelung. Zu den anderen Optionen: A – Release Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; B – Change Enablement ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; D – Service Validation and Testing unterstützt unter Umständen, ist aber im Szenario nicht der Kern..
Merksatz:
Das
Deployment ist der physische „Sprengmeister“, der nach dem Startsignal (Release) den roten Knopf drückt, um die Software tatsächlich in die Live-Umgebung zu verschieben.
Warum die anderen falsch sind:
Release Management: Gibt nur das konzeptionelle „Go“ (die Freigabe) und plant das Paket, führt aber nicht das technische Verschieben selbst durch.
Change Enablement: Ist das Kontrollgremium, das das Risiko bewertet und die Genehmigung erteilt, statt den technischen Auslöser zu drücken.
- Service Validation and Testing: Überprüft und testet die Qualität im Vorfeld, ist aber nicht für die eigentliche Überführung in den Live-Betrieb zuständig.
❌
Change Enablement
✅
Deployment Management
❌
Service Validation and Testing
❌
Release Management
Richtig ist B: Das Überführen in die Live-Umgebung ist Deployment; Release Management steuert eher Freigabe und Bündelung. Zu den anderen Optionen: A – Change Enablement ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; C – Service Validation and Testing unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; D – Release Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt..
Merksatz:
Das
Deployment Management ist der „Umzugswagen“, der die Software physisch in die Live-Umgebung fährt und dort den „Auslöser“ drückt, während das Release Management nur den Schlüssel übergibt.
Change Enablement: Ist falsch, weil es nur die Freigabe und Risikobewertung steuert, nicht aber die technische Überführung.
Service Validation and Testing: Ist falsch, weil diese Practice die Qualität vorab prüft, anstatt die Live-Inbetriebnahme selbst durchzuführen.
- Release Management: Ist falsch, weil es die Bereitstellung plant und bündelt (Entscheidung), während das Deployment die rein technische Umsetzung (Auslöser) vollzieht.
✅
Deployment Management
❌
Service Validation and Testing
❌
Release Management
❌
Change Enablement
Richtig ist A: Das Überführen in die Live-Umgebung ist Deployment; Release Management steuert eher Freigabe und Bündelung. Zu den anderen Optionen: B – Service Validation and Testing unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; C – Release Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; D – Change Enablement ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
Merksatz:
Deployment ist der physische
Transporteur, der die Kiste (Software) auf Knopfdruck ins Live-System schiebt – während das Release nur die Schleife drumherum bindet.
Warum die anderen falsch sind:
Service Validation and Testing: Ist bereits abgeschlossen, da die Tests schon bestanden wurden und es hier um die tatsächliche Überführung geht.
Release Management: Plant und gibt die Versionen organisatorisch frei, führt aber nicht die technische Übertragung (den "Knopfdruck") selbst aus.
- Change Enablement: Holt die Risikobewertung und die formelle Freigabe (Decision) ein, führt aber die technische Implementierung nicht durch.
Continuous Delivery und Continuous Deployment [Value System]
4
❌
Continuous Integration
✅
Continuous Delivery
❌
Continuous Deployment
❌
Deployment Management
Richtig ist B: Continuous Delivery ermöglicht Produktion jederzeit, während Deploymententscheidungen fallweise getroffen werden; Continuous Deployment automatisiert jede bestandene Änderung. Zu den anderen Optionen: A – Continuous Integration liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Continuous Deployment ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Deployment Management beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Delivery (Lieferung) bedeutet, das Paket liegt versandbereit an der Haustür, aber der Kunde entscheidet selbst, wann er es öffnet – genau wie das manuelle, fallweise Freischalten von Updates in der Produktion.
Warum die anderen falsch sind:
Continuous Integration greift zu kurz, da es nur das automatische Zusammenführen und Testen von Code in der Entwicklung beschreibt.
Continuous Deployment ist falsch, weil hierbei
jede Codeänderung ohne menschliche Entscheidung vollautomatisch bis in die Produktion durchläuft.
- Deployment Management ist lediglich die allgemeine ITIL-Praxis für das Verschieben von Software, nicht der spezifische Pipeline-Ansatz.
✅
Continuous Delivery
❌
Continuous Deployment
❌
Deployment Management
❌
Continuous Integration
Richtig ist A: Continuous Delivery ermöglicht Produktion jederzeit, während Deploymententscheidungen fallweise getroffen werden; Continuous Deployment automatisiert jede bestandene Änderung. Zu den anderen Optionen: B – Continuous Deployment ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Deployment Management beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Continuous Integration liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Delivery liefert das Paket bis zur Haustür (bereit für Produktion), aber der Kunde entscheidet selbst, wann er es öffnet (manueller Start) – während
Deployment es ungefragt direkt ins Haus stellt (vollautomatisch live).
Warum die anderen falsch sind:
Continuous Deployment ist falsch, weil hier jedes Update ohne manuelle Entscheidung vollautomatisch direkt live geht.
Deployment Management ist falsch, da es nur den reinen technischen Prozess des Verschiebens beschreibt, nicht die strategische Lieferpipeline.
- Continuous Integration ist falsch, weil es sich nur auf das Zusammenführen und Testen von Code in der Entwicklung bezieht, nicht auf die Bereitstellung.
❌
Continuous Deployment
❌
Deployment Management
❌
Continuous Integration
✅
Continuous Delivery
Richtig ist D: Continuous Delivery ermöglicht Produktion jederzeit, während Deploymententscheidungen fallweise getroffen werden; Continuous Deployment automatisiert jede bestandene Änderung. Zu den anderen Optionen: A – Continuous Deployment ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Deployment Management beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Continuous Integration liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Continuous Delivery ist wie ein Lieferdienst, der das Paket fix und fertig bis an die Haustür bringt – aber du entscheidest selbst, wann du die Tür öffnest und es hereinlässt (manueller Release-Knopf).
Warum die anderen falsch sind:
Continuous Deployment: Hier wird das Paket ohne Zwischenstopp sofort automatisch ins Haus getragen (vollautomatisch ohne manuelle Freigabeentscheidung).
Deployment Management: Das ist nur der allgemeine Prozess des Verschiebens von Software, nicht der spezifische Fluss bis zur Release-Bereitschaft.
- Continuous Integration: Betrifft nur das regelmäßige Zusammenführen und Testen von Code in der Entwicklung, nicht die Bereitstellung für den Betrieb.
❌
Deployment Management
❌
Continuous Integration
✅
Continuous Delivery
❌
Continuous Deployment
Richtig ist C: Continuous Delivery ermöglicht Produktion jederzeit, während Deploymententscheidungen fallweise getroffen werden; Continuous Deployment automatisiert jede bestandene Änderung. Zu den anderen Optionen: A – Deployment Management beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Continuous Integration liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Continuous Deployment ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Merksatz:
Delivery liefert das Paket bis an die Rampe (bereit zur Freigabe), aber erst der Chef entscheidet, wann es geöffnet wird – Deployment hingegen packt es sofort automatisch aus.
Warum die anderen falsch sind:
Deployment Management: Beschreibt nur den rein technischen Prozess des Verschiebens von Software, nicht die strategische Release-Bereitschaft.
Continuous Integration: Betrifft lediglich das regelmäßige Zusammenführen und Testen von Code in der Entwicklungsumgebung, nicht die Bereitstellung.
Continuous Deployment: Hierbei würde jedes Update vollautomatisch und ohne* manuelle Entscheidung direkt für den Endnutzer live gehen.
Operate und Monitoring and Event Management [Value System]
4
❌
Problem Management
✅
Monitoring and Event Management
❌
Service Desk
❌
Incident Management
Richtig ist B: Monitoring and Event Management ist für Beobachtung und Event-Erkennung der deutlichste Ermöglicher. Zu den anderen Optionen: A – Problem Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; C – Service Desk unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; D – Incident Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt..
Merksatz:
Das
Monitoring and Event Management ist das „Frühwarnsystem (Radar)“ des Betriebs: Es beobachtet, erkennt Anomalien und schlägt Alarm, noch bevor der Anwender im Nebel kollidiert.
Warum die anderen falsch sind:
Problem Management: Sucht nach den tieferen Ursachen bekannter Fehler, statt Live-Metriken auf Anomalien zu überwachen.
Service Desk: Ist der menschliche Kontaktpunkt für Nutzermeldungen, kein automatisiertes System für technisches Event-Monitoring.
- Incident Management: Reagiert erst auf bereits eingetretene Störungen, um den Service schnellstmöglich wiederherzustellen, statt präventiv Datenströme zu scannen.
✅
Monitoring and Event Management
❌
Service Desk
❌
Incident Management
❌
Problem Management
Richtig ist A: Monitoring and Event Management ist für Beobachtung und Event-Erkennung der deutlichste Ermöglicher. Zu den anderen Optionen: B – Service Desk unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; C – Incident Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; D – Problem Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
❌
Service Desk
❌
Incident Management
❌
Problem Management
✅
Monitoring and Event Management
Richtig ist D: Monitoring and Event Management ist für Beobachtung und Event-Erkennung der deutlichste Ermöglicher. Zu den anderen Optionen: A – Service Desk unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; B – Incident Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; C – Problem Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
❌
Incident Management
❌
Problem Management
✅
Monitoring and Event Management
❌
Service Desk
Richtig ist C: Monitoring and Event Management ist für Beobachtung und Event-Erkennung der deutlichste Ermöglicher. Zu den anderen Optionen: A – Incident Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; B – Problem Management ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; D – Service Desk unterstützt unter Umständen, ist aber im Szenario nicht der Kern..
Support und Problem Management [Value System]
4
✅
Problem Management
❌
Monitoring and Event Management
❌
Incident Management
❌
Service Desk
Richtig ist A: Problem Management untersucht Ursachen oder mögliche Ursachen für Incidents. Zu den anderen Optionen: B – Monitoring and Event Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; C – Incident Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; D – Service Desk ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
Merksatz:
Probleme löst man an der Wurzel: Wenn du nach der
Ursache (Root Cause) forschst und einen
Known Error (bekannten Fehler) mit
Workaround dokumentierst, bist du der Detektiv im
Problem Management.
Warum die anderen falsch sind:
Monitoring and Event Management beobachtet nur den Systemzustand und schlägt Alarm, analysiert aber keine tieferen Fehlerursachen.
Incident Management will den Service nur
schnellstmöglich wiederherstellen (Symptombekämpfung), statt die dauerhafte Ursache zu finden.
- Service Desk ist nur die kommunikative Schnittstelle (SPOC) für Anwender und führt selbst keine tiefgehende Ursachenanalyse durch.
❌
Monitoring and Event Management
❌
Incident Management
❌
Service Desk
✅
Problem Management
Richtig ist D: Problem Management untersucht Ursachen oder mögliche Ursachen für Incidents. Zu den anderen Optionen: A – Monitoring and Event Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; B – Incident Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; C – Service Desk ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt..
Merksatz:
Das
Problem Management ist der Detektiv von ITIL: Es sucht nicht nach schnellen Pflastern, sondern ermittelt die tiefere
Ursache hinter den Symptomen (Incidents) und heftet den Täter als
Known Error mit
Workaround in die Akte.
Warum die anderen falsch sind:
Monitoring and Event Management beobachtet nur den Systemzustand und schlägt Alarm, statt Ursachenanalysen durchzuführen.
Incident Management will den Service nur schnellstmöglich wiederherstellen („Pflaster“), nicht die fundamentale Ursache lösen.
- Service Desk ist die reine Anlaufstelle (Schnittstelle) für User, kein analytisches Untersuchungsteam für Fehlermuster.
❌
Incident Management
❌
Service Desk
✅
Problem Management
❌
Monitoring and Event Management
Richtig ist C: Problem Management untersucht Ursachen oder mögliche Ursachen für Incidents. Zu den anderen Optionen: A – Incident Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt.; B – Service Desk ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; D – Monitoring and Event Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern..
❌
Service Desk
✅
Problem Management
❌
Monitoring and Event Management
❌
Incident Management
Richtig ist B: Problem Management untersucht Ursachen oder mögliche Ursachen für Incidents. Zu den anderen Optionen: A – Service Desk ist eine plausible benachbarte Practice, adressiert jedoch einen anderen Schwerpunkt.; C – Monitoring and Event Management unterstützt unter Umständen, ist aber im Szenario nicht der Kern.; D – Incident Management ist in der Praxis häufig beteiligt, ist aber nicht der deutlichste Ermöglicher im beschriebenen Schwerpunkt..
Merksatz:
Das
Problem Management ist der Detektiv von ITIL: Es sucht nach der tiefen
Ursache (Problem) hinter den Symptomen und hinterlässt als Ermittlungsergebnis einen bekannten Fehler (
Known Error) mit einer Notlösung (
Workaround).
Warum die anderen falsch sind:
Service Desk: Ist nur die zentrale Anlaufstelle (SPOC) für Nutzer, löst aber keine tiefen Ursachenanalysen aus.
Monitoring and Event Management: Beobachtet nur den Systemzustand und schlägt bei Abweichungen Alarm, analysiert aber keine Fehlermuster.
- Incident Management: Will Störungen nur so schnell wie möglich im Alltag beseitigen, statt die langfristige Ursache zu erforschen.
Practice-Leitfäden [Value System]
4
❌
Der Abschnitt zu Rollen und Kompetenzen ohne Tooling-Bezug
❌
Der Abschnitt zu Zweck und Beschreibung der Practice
✅
Der Abschnitt zur Anwendung der Practice über die vier Dimensionen, einschließlich Automatisierung und Tooling
❌
Der Abschnitt zu Practice Success Factors
Richtig ist C: Die Struktur der Practice-Leitfäden enthält Anwendung über die vier Dimensionen einschließlich Automatisierung und Tooling. Zu den anderen Optionen: A – Der Abschnitt zu Rollen und Kompetenzen ohne Tooling-Bezug beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Der Abschnitt zu Zweck und Beschreibung der Practice liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Der Abschnitt zu Practice Success Factors ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Der Abschnitt zu Zweck und Beschreibung der Practice
✅
Der Abschnitt zur Anwendung der Practice über die vier Dimensionen, einschließlich Automatisierung und Tooling
❌
Der Abschnitt zu Practice Success Factors
❌
Der Abschnitt zu Rollen und Kompetenzen ohne Tooling-Bezug
Richtig ist B: Die Struktur der Practice-Leitfäden enthält Anwendung über die vier Dimensionen einschließlich Automatisierung und Tooling. Zu den anderen Optionen: A – Der Abschnitt zu Zweck und Beschreibung der Practice liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Der Abschnitt zu Practice Success Factors ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Der Abschnitt zu Rollen und Kompetenzen ohne Tooling-Bezug beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Denk an die
vier Dimensionen als die vier tragenden Säulen der Klinik: Nur wo alle vier zusammenarbeiten, fließen auch
Automatisierung und Tools (Technologie-Dimension) direkt in die
praktische Anwendung ein.
Zweck und Beschreibung: Liefert nur die theoretische Definition und das "Warum", aber keine konkreten Werkzeuge für die Praxis.
Practice Success Factors: Beschreiben die strategischen Erfolgsfaktoren (was erreicht werden muss), nicht das technische "Wie" der Umsetzung.
- Rollen und Kompetenzen: Fokussiert sich rein auf das Personal und dessen Fähigkeiten, klammert die technologische Ebene jedoch völlig aus.
✅
Der Abschnitt zur Anwendung der Practice über die vier Dimensionen, einschließlich Automatisierung und Tooling
❌
Der Abschnitt zu Practice Success Factors
❌
Der Abschnitt zu Rollen und Kompetenzen ohne Tooling-Bezug
❌
Der Abschnitt zu Zweck und Beschreibung der Practice
Richtig ist A: Die Struktur der Practice-Leitfäden enthält Anwendung über die vier Dimensionen einschließlich Automatisierung und Tooling. Zu den anderen Optionen: B – Der Abschnitt zu Practice Success Factors ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Der Abschnitt zu Rollen und Kompetenzen ohne Tooling-Bezug beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Der Abschnitt zu Zweck und Beschreibung der Practice liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Die
vier Dimensionen sind das Schweizer Taschenmesser von ITIL – nur wenn du alle vier ausklappst, hast du auch das Werkzeug (
Tooling) und die
Automatisierung (Dimension 2: Information & Technologie) für die praktische Anwendung in der Hand.
Warum die anderen falsch sind:
Practice Success Factors (PSFs) beschreiben nur die abstrakten Erfolgsfaktoren (das „Was“), nicht die konkreten Werkzeuge zur Umsetzung.
Rollen und Kompetenzen fokussieren sich rein auf den Faktor Mensch (Dimension 1) und klammern Technologie bewusst aus.
- Zweck und Beschreibung liefern nur die High-Level-Definition und das Ziel der Practice, bieten aber keinerlei praktische Anleitung für Tools.
❌
Der Abschnitt zu Practice Success Factors
❌
Der Abschnitt zu Rollen und Kompetenzen ohne Tooling-Bezug
❌
Der Abschnitt zu Zweck und Beschreibung der Practice
✅
Der Abschnitt zur Anwendung der Practice über die vier Dimensionen, einschließlich Automatisierung und Tooling
Richtig ist D: Die Struktur der Practice-Leitfäden enthält Anwendung über die vier Dimensionen einschließlich Automatisierung und Tooling. Zu den anderen Optionen: A – Der Abschnitt zu Practice Success Factors ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Der Abschnitt zu Rollen und Kompetenzen ohne Tooling-Bezug beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Der Abschnitt zu Zweck und Beschreibung der Practice liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Denke bei Werkzeugen und Automatisierung an die „Vier Dimensionen“ (speziell
Information & Technologie): Nur wo die vier Dimensionen draufstehen, sind auch das praktische Tooling und die Automatisierung der Practice drin.
Warum die anderen falsch sind:
Practice Success Factors: Beschreiben nur die kritischen Erfolgsfaktoren (das „Was“ für den Wertbeitrag), nicht die technische Umsetzung.
Rollen und Kompetenzen: Fokussieren sich rein auf den Faktor Mensch und organisatorische Strukturen, klammern Technologie also bewusst aus.
- Zweck und Beschreibung: Liefern nur das theoretische Fundament und die Definition der Practice, keine konkrete Anleitung zur Automatisierung.
Governance und Continual Improvement [Value System]
4
❌
Governance ersetzt Continual Improvement
✅
Governance lenkt und überwacht Entscheidungen; Continual Improvement sorgt für Anpassung und Lernen
❌
Continual Improvement ersetzt Entscheidungsrechte
❌
Beide Konzepte gelten nur für Support
Richtig ist B: Governance und Continual Improvement wirken im ITIL VS zusammen, erfüllen aber unterschiedliche Rollen. Zu den anderen Optionen: A – Governance ersetzt Continual Improvement liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Continual Improvement ersetzt Entscheidungsrechte ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Beide Konzepte gelten nur für Support beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Governance ist das Steuerrad, Continual Improvement der Motor mit GPS.
Das Leitungsgremium lenkt (Gleisvorgabe), während das Lernen aus Messwerten die Fahrt kontinuierlich verbessert – beide arbeiten Hand in Hand und ersetzen sich niemals.
Governance ersetzt Continual Improvement: Falsch, da Kontrolle ohne ständige Verbesserung zur Starre führt, statt sie zu ersetzen.
Continual Improvement ersetzt Entscheidungsrechte: Falsch, da Lernen zwar optimiert, aber formelle Leitplanken und Verantwortlichkeiten (Governance) weiterhin zwingend benötigt werden.
- Beide Konzepte gelten nur für Support: Falsch, da sie das gesamte Service Value System (App, Fahrzeuge, Partner) umspannen und nicht auf eine einzelne Abteilung beschränkt sind.
✅
Governance lenkt und überwacht Entscheidungen; Continual Improvement sorgt für Anpassung und Lernen
❌
Continual Improvement ersetzt Entscheidungsrechte
❌
Beide Konzepte gelten nur für Support
❌
Governance ersetzt Continual Improvement
Richtig ist A: Governance und Continual Improvement wirken im ITIL VS zusammen, erfüllen aber unterschiedliche Rollen. Zu den anderen Optionen: B – Continual Improvement ersetzt Entscheidungsrechte ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Beide Konzepte gelten nur für Support beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Governance ersetzt Continual Improvement liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Continual Improvement ersetzt Entscheidungsrechte
❌
Beide Konzepte gelten nur für Support
❌
Governance ersetzt Continual Improvement
✅
Governance lenkt und überwacht Entscheidungen; Continual Improvement sorgt für Anpassung und Lernen
Richtig ist D: Governance und Continual Improvement wirken im ITIL VS zusammen, erfüllen aber unterschiedliche Rollen. Zu den anderen Optionen: A – Continual Improvement ersetzt Entscheidungsrechte ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Beide Konzepte gelten nur für Support beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Governance ersetzt Continual Improvement liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Beide Konzepte gelten nur für Support
❌
Governance ersetzt Continual Improvement
✅
Governance lenkt und überwacht Entscheidungen; Continual Improvement sorgt für Anpassung und Lernen
❌
Continual Improvement ersetzt Entscheidungsrechte
Richtig ist C: Governance und Continual Improvement wirken im ITIL VS zusammen, erfüllen aber unterschiedliche Rollen. Zu den anderen Optionen: A – Beide Konzepte gelten nur für Support beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Governance ersetzt Continual Improvement liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Continual Improvement ersetzt Entscheidungsrechte ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
KI-Reifegradstufen [KI]
1
✅
Den aktuellen Stand einzuordnen und einen realistischen Entwicklungspfad aufzuzeigen
❌
Ausschließlich die Anzahl der Server zu zählen
❌
Ausschließlich Marketingzwecke zu erfüllen
❌
Reifegradmodelle sind für KI laut ITIL nicht sinnvoll
Den aktuellen Stand des KI-Einsatzes einzuordnen und einen realistischen Entwicklungspfad aufzuzeigen.
KI und Datenqualität [KI]
1
✅
Weil KI-Systeme aus Daten lernen und schlechte Qualität zu unzuverlässigen Ergebnissen führt
❌
Datenqualität hat keinen Einfluss auf KI-Ergebnisse
❌
Nur bei Bild-KI relevant, nicht bei Text-KI
❌
Datenqualität betrifft ausschließlich die IT-Sicherheit
KI-Systeme lernen aus Daten — schlechte Datenqualität führt zu unzuverlässigen oder verzerrten Ergebnissen.
Change Management für KI-Einführung [KI]
1
✅
Organizational Change Management
❌
Service Financial Management ausschließlich
❌
Supplier Management ausschließlich
❌
Service Catalogue Management ausschließlich
Organizational Change Management — Menschen müssen durch die Veränderung begleitet werden.
Merksatz:
Wenn die
KI kommt, muss der
Mensch mitziehen – neue Technologie scheitert ohne Akzeptanz, darum steuert
Organizational Change Management den menschlichen Wandel.
Service Financial Management: Konzentriert sich nur auf das Budget und die Kosten der KI, ignoriert aber völlig die entscheidende Akzeptanz der Mitarbeiter.
Supplier Management: Regelt nur die Verträge mit den KI-Anbietern, hilft aber nicht dabei, die internen Arbeitsabläufe und Ängste der Belegschaft zu transformieren.
- Service Catalogue Management: Bildet die KI-Services lediglich im Leistungskatalog ab, statt die tatsächliche Nutzung und den Kulturwandel im Betrieb aktiv zu gestalten.
Transparenz bei KI-Entscheidungen [KI]
1
✅
Damit Fehler erkannt, Verantwortlichkeiten geklärt und Vertrauen aufgebaut werden können
❌
Erklärbarkeit ist für ITIL irrelevant
❌
Nur bei staatlichen Organisationen notwendig
❌
Erklärbarkeit widerspricht dem Sinn von KI grundsätzlich
Damit Fehler erkannt, Verantwortlichkeiten geklärt und Vertrauen in Entscheidungen aufgebaut werden können.
KI und Continual Improvement [KI]
1
✅
Durch automatisierte Muster-/Trenderkennung, die Verbesserungspotenziale aufzeigt
❌
KI kann laut ITIL nicht mit Continual Improvement kombiniert werden
❌
Nur durch vollständigen Ersatz menschlicher Entscheidungen
❌
Ausschließlich durch höhere Rechenleistung
Z.B. durch automatisierte Muster- und Trenderkennung in großen Datenmengen, die Verbesserungspotenziale aufzeigt.
Verantwortungsvoller KI-Einsatz [KI]
1
✅
Menschliche Aufsicht beibehalten
✅
Risiken aktiv managen
✅
Erst optimieren, dann automatisieren
❌
Vollständiger Verzicht auf jede Kontrolle
Merksatz: „ITILs KI-Gedanke: Der Mensch wacht, Risiken werden gemanagt, erst optimieren, dann wird automatisiert.“
Warum die anderen falsch sind:
- Vollständiger Verzicht auf jede Kontrolle – Dies widerspricht dem ITIL-Prinzip der kontinuierlichen Verbesserung und Steuerung.
KI-Reife im eigenen Unternehmen einschätzen [KI]
1
Merksatz:
Stell dir die KI-Reife deines Unternehmens wie eine Treppe vor: Du musst erst wissen, auf welcher Stufe du stehst, um den nächsten Schritt sicher zu planen.
Für die Prüfung gilt: Jede Antwort zu dieser Frage ist richtig, solange sie zwei feste Ankerpunkte hat:
1. Der Ist-Zustand (Wo stehen wir?): Eine ehrliche, begründete Einschätzung (z. B. "Stufe 1: Erste Experimente mit ChatGPT").
2. Der Folgeschritt (Wo gehen wir hin?): Ein konkreter, logischer nächster Meilenstein (z. B. "Einführung einer internen KI-Richtlinie" oder "Schulung des Teams").
Kurzformel: Status Quo bestimmen + Logischer Folgeschritt = Volle Punktzahl.
KI-Governance-Richtlinie skizzieren [KI]
1
Merksatz:
Denk an das
V-A-M-P-I-R-System für eine sichere KI:
Verantwortlichkeiten (Wer hat den Hut auf?)
Anwendungsfälle (Was ist erlaubt?)
Menschliche Prüfung (Keine kritische Entscheidung ohne Mensch!)
Pflicht zur
Integrität sensibler Daten (Datenschutz!)
- Regelmäßige Überprüfung (Die Richtlinie aktuell halten!)
Kurzform: Ein
VAMPIR schützt deine KI vor dem Kontrollverlust!
KI-Reife [KI]
1
✅
Wie systematisch, verantwortungsvoll und wirksam eine Organisation KI einsetzt
❌
Ausschließlich die Anzahl eingesetzter KI-Tools
❌
Das Alter der eingesetzten KI-Modelle
❌
Die Anzahl der KI-Zertifikate der Mitarbeitenden
Wie weit eine Organisation KI systematisch, verantwortungsvoll und wirksam einsetzt.
Generative KI [KI]
1
✅
Sie erzeugt neue Inhalte wie Text, Bilder oder Code basierend auf gelernten Mustern
❌
Sie kann ausschließlich vorhandene Daten sortieren, nie neue Inhalte erzeugen
❌
Sie ist nur für Bildbearbeitung nutzbar
❌
Sie ersetzt zwangsläufig menschliche Entscheidungen vollständig
Sie erzeugt neue Inhalte (Text, Bild, Code etc.) basierend auf gelernten Mustern.
Merksatz:
GenAI ist wie ein kreativer ITIL-Koch: Er nutzt Rezepte (Muster) aus der Vergangenheit, um völlig neue, eigene Gerichte (Texte, Bilder, Code) zu kreieren – er wärmt nicht nur Reste auf.
Warum die anderen falsch sind:
Nur Sortieren: Ein fataler Denkfehler, da GenAI durch neuronale Netze schöpferisch tätig ist und eben gerade neue
Daten erschafft.
Nur Bildbearbeitung: Zu stark eingeschränkt, da GenAI auch Code schreibt, Texte verfasst und Musik komponiert.
- Ersetzt Menschen vollständig: Falsch, da GenAI in ITIL als Assistenzwerkzeug dient; die finale Verantwortung und ethische Entscheidung liegt immer beim Menschen.
Agentic KI [KI]
1
✅
Sie kann eigenständig mehrstufige Aufgaben planen und ausführen
❌
Sie kann ausschließlich Bilder generieren
❌
Sie benötigt grundsätzlich keinerlei menschliche Aufsicht
❌
Sie ist ein Synonym für GenAI ohne inhaltlichen Unterschied
Agentic KI kann eigenständig mehrstufige Aufgaben planen und ausführen, nicht nur auf einzelne Prompts reagieren.
GenAI erzeugt, Agentic KI handelt.
GenAI: antwortet auf EINEN Prompt (Text/Bild/Code)
Agentic KI: plant und führt MEHRSTUFIGE Aufgaben eigenständig aus
Merke: Agentic = "agiert wie ein Agent", nicht nur ein Werkzeug.
KI-Governance [KI]
1
✅
Für Steuerung, Verantwortlichkeit und Risikomanagement beim KI-Einsatz
❌
Ausschließlich für die technische Wartung von Servern
❌
Für die Preisgestaltung von KI-Lizenzen
❌
Für die Marketingkommunikation zu KI-Produkten
Für Steuerung, Verantwortlichkeit und Risikomanagement beim Einsatz von KI-Systemen.
KI im Lebenszyklus [KI]
1
✅
Grundsätzlich in mehreren bis allen Stufen, je nach Anwendungsfall
❌
Ausschließlich in der Stufe Discover
❌
Ausschließlich in der Stufe Operate
❌
KI ist laut ITIL nur außerhalb des Lebenszyklus relevant
Grundsätzlich in mehreren/allen Stufen — von Discover (Trendanalyse) bis Deliver und Support (z.B. Chatbots).
Risiken von KI [KI]
1
✅
Fehlerhafte oder erfundene Ausgaben sowie übermäßiges Vertrauen ohne menschliche Prüfung
❌
KI-Systeme haben laut ITIL grundsätzlich keinerlei Risiken
❌
Das einzige Risiko ist ein zu hoher Stromverbrauch
❌
Risiken betreffen ausschließlich die Hardware-Kosten
Fehlerhafte/erfundene Ausgaben (Halluzinationen) und übermäßiges Vertrauen ohne menschliche Prüfung.
Menschliche Aufsicht [KI]
1
✅
Um Fehler, Verzerrungen und unangemessene Entscheidungen zu erkennen und zu korrigieren
❌
Weil KI-Systeme laut ITIL generell verboten sind
❌
Weil menschliche Aufsicht gesetzlich für jede Software vorgeschrieben ist
❌
Nur aus historischen Gründen, ohne praktischen Nutzen
Um Fehler, Verzerrungen (Bias) und unangemessene Entscheidungen frühzeitig zu erkennen und zu korrigieren.
KI und Grundprinzipien [KI]
1
✅
Optimize and automate
❌
Keep it simple and practical
❌
Start where you are
❌
Collaborate and promote visibility
Optimize and automate — KI sollte bereits sinnvolle, optimierte Abläufe unterstützen, nicht ineffiziente Abläufe nur beschleunigen.
Merksatz: KI ist wie ein Koch, der erst das Rezept perfektioniert (optimiert), bevor er die Großküche automatisiert.
Warum die anderen falsch sind:
Keep it simple and practical: Betont Einfachheit, nicht die Reihenfolge Optimierung vor Automatisierung.
Start where you are: Fokus liegt auf dem aktuellen Zustand, nicht auf der Prozessverbesserung vor der Automatisierung.
- Collaborate and promote visibility: Bezieht sich auf Zusammenarbeit und Transparenz, nicht auf die Reihenfolge der Prozessschritte.
KI-Einsatz kritisch bewerten [KI]
1
Merksatz:
Der KI-Copilot steuert das IT-Support-Ticket blitzschnell ins Ziel – doch wenn er „halluziniert“, fliegt das System blind in den Abgrund.
Die Eselsbrücke für die Prüfung:
Sinnvoller Einsatz (Nutzen): Der KI-Assistent als Turbo-Unterstützung – z.B. automatische Kategorisierung von Support-Tickets oder Erstentwürfe für Code.
Kritisches Risiko (Gefahr): Blinde Technologie-Gläubigkeit. Eine fehlerhafte KI-Ausgabe (Halluzination) führt ungeprüft zu einer falschen Systemkonfiguration oder Fehlentscheidung im Service Management.
Prüfungs-Formel: KI bringt Effizienz, braucht aber immer das menschliche Vier-Augen-Prinzip zur Qualitätskontrolle.
Agentic KI in der Praxis [KI]
1
Merksatz: Der "KI-Tech-Support" ist ein autonomer Detektiv und Ersthelfer: Er spürt den Fehler auf, kennt die Standard-Heilmittel und reicht sie an. Doch sobald es um die "große OP am offenen System" geht, muss der erfahrene "Mensch-Chirurg" das Skalpell in die Hand nehmen und die finale Freigabe erteilen. Die KI bereitet vor, der Mensch entscheidet das Kritische.
KI-Fähigkeitsmodell Zweck [KI]
1
✅
Um die KI-Bereitschaft einer Organisation zu bewerten und Verbesserungspotenzial zu identifizieren
❌
Um KI-Tools mit vordefinierten Industriestandards zu vergleichen
❌
Um Governance-Entscheidungen im gesamten ITIL Value System vollständig zu automatisieren
❌
Um KI-Investitionen ausschließlich nach finanzieller Rendite zu priorisieren
Es dient dazu, die Bereitschaft (Reifegrad) einer Organisation für KI-Einsatz zu bewerten und Verbesserungspotenzial zu identifizieren.
Merksatz:
Das KI-Fähigkeitsmodell ist das
„KI-Fitnessstudio“ deiner Organisation: Es misst deinen aktuellen Trainingszustand (Bereitschaft) und zeigt dir den Trainingsplan für die Muskeln, die du noch aufbauen musst (Verbesserungspotenzial).
Warum die anderen falsch sind:
Vergleich mit Industriestandards: Das Modell ist ein internes Diagnosewerkzeug für die eigene Reife, kein reiner Produkt- oder Tool-Vergleichsmaßstab.
Governance-Entscheidungen automatisieren: KI unterstützt und informiert die Governance, aber sie ersetzt niemals die menschliche Verantwortung und Steuerung im Service Value System.
- Priorisierung nur nach Rendite: Die Bewertung erfolgt ganzheitlich über alle vier Dimensionen des Service Managements, nicht nur starr nach dem finanziellen Profit.
Übung [KI]
7
❌
Um KI-Werkzeuge gegen feste Industriestandards zu benchmarken
✅
Um die Reife bzw. Bereitschaft im Umgang mit KI zu bewerten und Verbesserungsfelder zu identifizieren
❌
Um Governance-Entscheidungen automatisch zu treffen
❌
Um KI-Investitionen allein nach finanzieller Rendite zu priorisieren
Das Modell dient der Reife-/Bereitschaftsbewertung und dem Aufzeigen von Verbesserungsfeldern.
✅
Sie erzeugt neue Inhalte auf Basis erlernter Muster
❌
Sie handelt vollständig autonom ohne jede Vorgabe
❌
Sie ersetzt jegliche Governance
❌
Sie überwacht ausschließlich Systeme
Generative KI erzeugt neue Inhalte (Text, Bild, Code) auf Basis gelernter Muster.
✅
KI-Nutzung durch Richtlinien und Kontrollen verantwortungsvoll und regelkonform zu steuern
❌
KI-Modelle möglichst schnell zu trainieren
❌
Jede menschliche Entscheidung zu ersetzen
❌
Ausschließlich Kosten zu senken
KI-Governance stellt über Richtlinien und Kontrollen einen verantwortungsvollen, regelkonformen KI-Einsatz sicher.
✅
Ein System zum Lenken, Steuern und Überwachen der Nutzung künstlicher Intelligenz
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„KI-Governance“ wird in den Quellen inhaltlich als „Ein System zum Lenken, Steuern und Überwachen der Nutzung künstlicher Intelligenz“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Die KI-Governance ist das Lenkrad, Steuer und Kontrollzentrum (Lenken, Steuern, Überwachen) speziell für dein KI-Fahrzeug – ohne dieses System gerät die künstliche Intelligenz außer Kontrolle.
Warum die anderen falsch sind:
...einer Organisation: Das beschreibt die allgemeine ITIL-Definition von Governance (ohne den spezifischen Fokus auf KI).
...Nachfrage in Wert umgewandelt: Dies ist die Definition der Service-Wertschöpfungskette (Service Value Chain).
...Ressourcen und Fähigkeiten: Das definiert den Begriff Kompetenzen oder Organisationen und Menschen* (Ressourcen-Dimension).
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Technologie, die Systeme befähigt, zu lernen, sich an neue Inputs anzupassen und Aufgaben auszuführen, die bisher menschliche Beteiligung erforderten
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Künstliche Intelligenz (KI)“ wird in den Quellen inhaltlich als „Technologie, die Systeme befähigt, zu lernen, sich an neue Inputs anzupassen und Aufgaben auszuführen, die bisher menschliche Beteiligung erforderten“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
✅
KI-Systeme, die neue Inhalte wie Text, Bilder, Code oder andere Outputs erstellen können, basierend auf Mustern aus vorhandenen Daten
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„Generative KI (GenAI)“ wird in den Quellen inhaltlich als „KI-Systeme, die neue Inhalte wie Text, Bilder, Code oder andere Outputs erstellen können, basierend auf Mustern aus vorhandenen Daten“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
KI-Systeme, die im Namen von Anwendern innerhalb vereinbarter Grenzen autonom handeln, während menschliche Aufsicht und Governance bestehen bleiben
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Agentische KI“ wird in den Quellen inhaltlich als „KI-Systeme, die im Namen von Anwendern innerhalb vereinbarter Grenzen autonom handeln, während menschliche Aufsicht und Governance bestehen bleiben“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Agentische KI ist dein digitaler Agent mit Handlungsspielraum: Er agiert selbstständig im Rahmen seiner Befugnisse (autonom in Grenzen), während du als Chef die Fäden in der Hand behältst (menschliche Aufsicht).
Warum die anderen falsch sind:
Option 1 beschreibt die Wertschöpfungskette (Service Value Chain), nicht eine Technologie.
Option 2 definiert Ressourcen und Fähigkeiten (allgemeine ITIL-Kapazitäten), was viel zu unspezifisch für KI ist.
Option 4 ist die klassische Definition von Governance* (Führung und Überwachung einer Organisation).
KI-Fähigkeitsmodell [KI]
4
❌
Kommunikation
❌
Erstellung
❌
Klarstellung
✅
Erkennung
Richtig ist D: Erkennung beschreibt das Erkennen von Mustern, Anomalien oder Korrelationen zur Analyse und Prognose. Zu den anderen Optionen: A – Kommunikation beschreibt eine andere Interaktion mit KI.; B – Erstellung ist eine KI-Fähigkeit, beschreibt aber eine andere Art der Unterstützung.; C – Klarstellung ist plausibel, steht hier jedoch nicht im Vordergrund..
❌
Erstellung
❌
Klarstellung
✅
Erkennung
❌
Kommunikation
Richtig ist C: Erkennung beschreibt das Erkennen von Mustern, Anomalien oder Korrelationen zur Analyse und Prognose. Zu den anderen Optionen: A – Erstellung ist eine KI-Fähigkeit, beschreibt aber eine andere Art der Unterstützung.; B – Klarstellung ist plausibel, steht hier jedoch nicht im Vordergrund.; D – Kommunikation beschreibt eine andere Interaktion mit KI..
❌
Klarstellung
✅
Erkennung
❌
Kommunikation
❌
Erstellung
Richtig ist B: Erkennung beschreibt das Erkennen von Mustern, Anomalien oder Korrelationen zur Analyse und Prognose. Zu den anderen Optionen: A – Klarstellung ist plausibel, steht hier jedoch nicht im Vordergrund.; C – Kommunikation beschreibt eine andere Interaktion mit KI.; D – Erstellung ist eine KI-Fähigkeit, beschreibt aber eine andere Art der Unterstützung..
Merksatz:
Erkennung ist der „Röntgenblick“ der KI: Sie durchleuchtet Protokolle und Metriken, um Anomalien und Muster unsichtbar im Hintergrund zu
erkennen, bevor es brennt.
Warum die anderen falsch sind:
Klarstellung: Falsch, weil kein unklarer Input (wie unstrukturierter Text) interpretiert oder präzisiert wird.
Kommunikation: Falsch, weil kein interaktiver Austausch oder Dialog mit Menschen (wie durch Chatbots) stattfindet.
- Erstellung: Falsch, weil keine neuen Inhalte, Berichte oder Codes aktiv generiert werden.
✅
Erkennung
❌
Kommunikation
❌
Erstellung
❌
Klarstellung
Richtig ist A: Erkennung beschreibt das Erkennen von Mustern, Anomalien oder Korrelationen zur Analyse und Prognose. Zu den anderen Optionen: B – Kommunikation beschreibt eine andere Interaktion mit KI.; C – Erstellung ist eine KI-Fähigkeit, beschreibt aber eine andere Art der Unterstützung.; D – Klarstellung ist plausibel, steht hier jedoch nicht im Vordergrund..
Merksatz:
Das AIOps-Werkzeug verhält sich wie ein
Detektiv mit Lupe, der Spuren (Protokolle, Metriken) liest und Gefahren (Anomalien, Engpässe)
erkennt, bevor der Schaden entsteht.
Kommunikation ist falsch: Es findet kein interaktiver Dialog oder Informationsaustausch mit Menschen statt.
Erstellung ist falsch: Das System generiert keine neuen Inhalte, Berichte oder Codes, sondern analysiert nur Bestehendes.
- Klarstellung ist falsch: Es geht hier nicht um das Präzisieren oder Vereinfachen von unklaren Nutzeranfragen, sondern um das Aufspüren von Systemmustern.
Gemeinsame Werte ITIL/DevOps [Rahmenwerke]
1
✅
Kontinuierliche Verbesserung
❌
Vollständige Vermeidung von Automatisierung
❌
Strikt sequenzielle Abläufe ohne Iteration
❌
Ausschließlich manuelle Prozesse
Kontinuierliche Verbesserung ist ein zentraler gemeinsamer Wert.
SRE Fehlerbudget [Rahmenwerke]
1
✅
Ein akzeptierter Spielraum an Ausfallzeit, innerhalb dessen Änderungsrisiken erlaubt sind
❌
Das jährliche IT-Budget für Fehlerbehebung in Euro
❌
Eine Strafzahlung an Kunden bei Ausfällen
❌
Ein Konzept, das mit Zuverlässigkeit nichts zu tun hat
Ein akzeptierter Spielraum an Ausfallzeit/Fehlern, innerhalb dessen Teams Änderungsrisiken eingehen dürfen.
PRINCE2 Kernidee [Rahmenwerke]
1
✅
Zeitlich begrenzt mit definiertem Ergebnis, im Gegensatz zu fortlaufendem Betrieb
❌
PRINCE2-Projekte laufen laut Definition unbegrenzt
❌
PRINCE2 und laufender Servicebetrieb sind identisch
❌
PRINCE2 kennt keine Projektendtermine
Projekte sind zeitlich begrenzt und liefern ein definiertes Ergebnis — Servicebetrieb ist fortlaufend.
Merksatz:
Ein PRINCE2-Projekt ist wie eine
Schwangerschaft: Es hat einen klaren Anfang, ein definiertes Ende (Geburt/Ergebnis) und ist zeitlich streng begrenzt – im Gegensatz zum Servicebetrieb, der das Kind lebenslang pflegt.
"unbegrenzt": Falsch, da Projekte per Definition temporär sind und keine Endlosschleifen.
"identisch": Falsch, da Betrieb auf Stabilität und Wiederholung setzt, während Projekte einmalig und verändernd sind.
- "keine Projektendtermine": Falsch, da ohne festes Enddatum kein geordneter Projektabschluss nach PRINCE2 möglich ist.
DevOps und Kultur [Rahmenwerke]
1
✅
Weil es enge Zusammenarbeit und gemeinsame Verantwortung erfordert, nicht nur Werkzeuge
❌
Weil DevOps ausschließlich ein Marketingbegriff ohne Substanz ist
❌
Weil DevOps keinerlei technische Komponente hat
❌
Weil DevOps identisch mit klassischem Wasserfallvorgehen ist
Weil es enge Zusammenarbeit zwischen Entwicklung und Betrieb sowie gemeinsame Verantwortung erfordert, nicht nur Werkzeuge.
Übergabepunkt Projekt zu Betrieb [Rahmenwerke]
1
✅
Die saubere Übergabe inkl. Wissenstransfer und Klärung von Betriebsverantwortlichkeiten
❌
Es gibt laut ITIL keinerlei kritischen Übergabepunkt
❌
Der Übergang findet automatisch ohne jede Abstimmung statt
❌
Projekte und Betrieb dürfen sich laut ITIL nie überschneiden
Die saubere Übergabe (Transition) inkl. Wissenstransfer und Klärung von Betriebsverantwortlichkeiten.
DevOps-Praktiken [Rahmenwerke]
1
✅
Continuous Integration
✅
Continuous Delivery
✅
Site Reliability Engineering
❌
Jährliche Großreleases ohne Zwischenschritte
Merksatz:
DevOps ist wie eine moderne, superschnelle Post-Zustellung: Der Brief wird sofort geschrieben (
Continuous Integration), direkt in den Lieferwagen geladen (
Continuous Delivery) und die Postboten sorgen mit modernster Technik dafür, dass die Zustell-Infrastruktur niemals abstürzt (
Site Reliability Engineering).
- Jährliche Großreleases: Sind das absolute Gegenteil von DevOps, da sie das Risiko maximieren, Feedback verzögern und den modernen Fluss agiler, schneller Wertschöpfung komplett blockieren.
ITIL-Governance mit DevOps-Tempo [Rahmenwerke]
1
Framework-Kombination begründen [Rahmenwerke]
1
ITIL und DevOps [Rahmenwerke]
1
✅
Beide betonen Zusammenarbeit, Automatisierung und kontinuierliche Verbesserung
❌
Beide schließen sich gegenseitig grundsätzlich aus
❌
DevOps ersetzt ITIL vollständig
❌
ITIL lehnt Automatisierung grundsätzlich ab
Beide betonen Zusammenarbeit, Automatisierung und kontinuierliche Verbesserung.
3 gemeinsame Werte: Z-A-K
Zusammenarbeit (statt Silodenken)
Automatisierung (wo sinnvoll)
- Kontinuierliche Verbesserung
Merke: ITIL und DevOps sind keine Gegner — DevOps liefert das Tempo, ITIL den Rahmen.
CI/CD [Rahmenwerke]
1
✅
Continuous Integration / Continuous Delivery (oder Deployment)
❌
Central Infrastructure / Central Deployment
❌
Customer Insight / Customer Delivery
❌
Change Implementation / Change Documentation
Continuous Integration und Continuous Delivery/Deployment.
Site Reliability Engineering [Rahmenwerke]
1
✅
Site Reliability Engineering — Zuverlässigkeit von Systemen technisch messbar/steuerbar machen
❌
Software Requirements Engineering — Anforderungserhebung
❌
System Recovery Execution — reine Notfallwiederherstellung
❌
Service Relationship Evaluation — Kundenbewertung
Site Reliability Engineering — Zuverlässigkeit von Systemen technisch messbar und steuerbar machen.
Merksatz:
SRE steht für
Site
Reliability
Engineering: Stell dir einen
Sicherheits-
Roboter-
Engineer vor, der die Zuverlässigkeit einer Website mit dem
Messen und Steuern von Zahnrädern technisch garantiert.
Software Requirements Engineering: Beschäftigt sich nur mit der Analyse von Software-Anforderungen vor der Entwicklung, nicht mit dem laufenden Betrieb.
System Recovery Execution: Fokussiert sich fälschlicherweise nur auf die reine Notfallwiederherstellung (reaktiv) statt auf die proaktive, kontinuierliche Zuverlässigkeit.
- Service Relationship Evaluation: Bezieht sich auf die Bewertung von Kundenbeziehungen, was ein reines Management-Thema ohne technischen Systemfokus ist.
Observability [Rahmenwerke]
1
✅
Observability erklärt auch unbekannte/neuartige Probleme aus dem Systemzustand, nicht nur bekannte Metriken
❌
Beide Begriffe sind exakt identisch
❌
Observability betrifft ausschließlich die Benutzeroberfläche
❌
Monitoring ist umfassender als Observability
Observability zielt darauf ab, aus Systemzustand auch unbekannte/neuartige Probleme erklärbar zu machen, nicht nur bekannte Metriken zu überwachen.
ITIL und PRINCE2 [Rahmenwerke]
1
✅
ITIL fokussiert laufendes Servicemanagement, PRINCE2 die Steuerung zeitlich begrenzter Projekte
❌
Beide Rahmenwerke behandeln exakt dasselbe Themenfeld
❌
PRINCE2 ersetzt Servicemanagement vollständig
❌
ITIL und PRINCE2 dürfen laut Anbieter nicht gemeinsam genutzt werden
ITIL fokussiert auf laufendes Servicemanagement, PRINCE2 auf die Steuerung zeitlich begrenzter Projekte.
Komplexitätsdenken [Rahmenwerke]
1
✅
Den angemessenen Umgang mit unvorhersehbaren, nicht-linearen Systemen
❌
Ausschließlich das Vereinfachen jeder Situation auf einen einzigen Faktor
❌
Die vollständige Vermeidung von Komplexität um jeden Preis
❌
Es hat keinen Bezug zu modernen IT-Umgebungen
Den Umgang mit unvorhersehbaren, nicht-linearen Systemen statt starrer, rein linearer Planung.
Merksatz:
Komplexitätsdenken ist wie Segeln im Sturm: Man kann den Wind nicht kontrollieren, aber man reagiert flexibel und angemessen auf die unvorhersehbaren, wilden Wellen (nicht-lineare Systeme), anstatt starr geradeaus zu steuern.
Warum die anderen falsch sind:
Einziger Faktor: Reduziert die Realität fälschlicherweise auf ein unrealistisches Schwarz-Weiß-Bild, was in dynamischen IT-Systemen scheitert.
Vollständige Vermeidung: Verkennt, dass moderne IT-Landschaften von Natur aus komplex sind und sich diese Komplexität nicht einfach wegzaubern lässt.
- Kein Bezug: Ignoriert die Tatsache, dass gerade moderne, agile Cloud- und Microservice-Architekturen Paradebeispiele für hochkomplexe Systeme sind.
Workflowoptimierung [Rahmenwerke]
2
✅
Effiziente Workflows sind Voraussetzung, damit Automatisierung wirklich Nutzen bringt
❌
Workflowoptimierung ist unabhängig von jeder Automatisierung
❌
Sie betrifft ausschließlich das Marketing
❌
Sie widerspricht grundsätzlich dem ITIL-Grundgedanken
Effiziente, reibungsarme Workflows sind Voraussetzung dafür, dass Automatisierung (CI/CD) überhaupt Nutzen bringt.
✅
Die kontinuierliche Verbesserung von Arbeitsabläufen zur Reduktion von Verschwendung und Engpässen
❌
Die einmalige Dokumentation aller Arbeitsschritte zu Projektbeginn
❌
Ein anderer Name für das magische Dreieck des Projektmanagements
❌
Die Automatisierung ausschließlich von HR-Prozessen
Workflowoptimierung meint die kontinuierliche Untersuchung und Verbesserung von Arbeitsabläufen, um Verschwendung, Engpässe und unnötige Übergaben zu reduzieren und den Fluss der Wertschöpfung zu verbessern.
Ergänzung statt Konkurrenz [Rahmenwerke]
1
✅
Als ergänzendes, integrierbares Rahmenwerk, das mit anderen kombiniert werden kann
❌
Als einzig zulässiges Rahmenwerk, alle anderen sind ausgeschlossen
❌
Als reine Konkurrenz, die andere Ansätze ersetzen soll
❌
ITIL äußert sich laut Foundation-Syllabus nicht zu anderen Rahmenwerken
Als ergänzendes, integrierbares Rahmenwerk, nicht als exklusive Alternative.
ITIL und DevOps kombiniert [Rahmenwerke]
1
ITIL und PRINCE2 im Zusammenspiel [Rahmenwerke]
1
Merksatz:
PRINCE2 baut die neue Straße (Projekt), ITIL regelt danach den laufenden Verkehr (Betrieb).
Die Brücke im Unternehmen:
Ein PRINCE2-Projektteam entwickelt und liefert eine neue HR-Software. Sobald diese fertiggestellt ist, übernimmt das ITIL-Servicemanagement den täglichen Support (Service Desk) und die Wartung.
Der Kern:
PRINCE2 steuert den befristeten Aufbau (Change/Projekt), ITIL sichert den dauerhaften Nutzen (Betrieb/Wertschöpfung).
Continuous Integration [Rahmenwerke]
1
✅
Codeänderungen häufig zusammenführen und automatisiert testen, um Integrationsprobleme früh zu erkennen
❌
Eine einmalige, große Codeintegration kurz vor dem Release
❌
Ein Werkzeug zur manuellen Freigabe von Releases
❌
Ein Synonym für Continuous Deployment
CI führt Codeänderungen mehrerer Beteiligter häufig (oft mehrmals täglich) in ein gemeinsames Repository zusammen und lässt automatisierte Tests laufen, um Integrationsprobleme früh statt spät zu erkennen.
CD: Delivery vs. Deployment [Rahmenwerke]
1
✅
Delivery hält den Code jederzeit release-fähig mit manueller Freigabe, Deployment automatisiert auch die Freigabe selbst
❌
Delivery und Deployment sind vollständig identisch
❌
Deployment betrifft nur Testumgebungen, Delivery nur Produktion
❌
Delivery erfordert immer eine Änderungsanfrage, Deployment nie
Bei Continuous Delivery ist der Code jederzeit produktionsreif, die Freigabe für den produktiven Einsatz erfolgt aber manuell. Bei Continuous Deployment entfällt dieser manuelle Schritt, jede erfolgreich getestete Änderung geht automatisch in Produktion.
Merksatz:
Delivery liefert das Paket nur bis an die Haustür (manuelle Freigabe/Knopfdruck nötig), während
Deployment direkt ins Haus stürmt und es selbstständig auspackt (vollautomatisch bis in die Produktion).
Warum die anderen falsch sind:
Identisch: Falsch, da der entscheidende Unterschied im Grad der Automatisierung des finalen Releases liegt.
Test- vs. Produktion: Falsch, da beide Konzepte darauf abzielen, Software sicher in die echte Produktionsumgebung zu bringen.
- Änderungsanfrage (RFC): Falsch, da der Unterschied in der Automatisierung liegt und nicht an starre, manuelle ITIL-Prozessdokumente gekoppelt ist.
CI/CD und Grundprinzipien [Rahmenwerke]
1
✅
Optimieren und automatisieren
❌
Einfach und praktikabel bleiben (isoliert betrachtet, ohne Automatisierungsbezug)
❌
Dort anfangen, wo man steht
❌
Ganzheitlich denken und arbeiten (ohne Automatisierungsbezug)
CI/CD automatisiert wiederkehrende Build-, Test- und Bereitstellungsschritte und passt damit unmittelbar zum Grundprinzip "Optimieren und automatisieren".
Merksatz:
Denke bei CI/CD an eine vollautomatische Fließband-Fabrik: Erst wird der Prozess optimiert (standardisiert), dann durch die Pipeline komplett automatisiert. Ohne diesen Turbo läuft kein modernes Deployment!
Einfach und praktikabel bleiben: Zielt auf die Reduzierung von Komplexität ab, ignoriert aber den technologischen Kern der CI/CD-Werkzeugketten.
Dort anfangen, wo man steht: Befasst sich nur mit der Ist-Analyse und dem Erhalt bestehender Werte, nicht mit der kontinuierlichen Auslieferung.
Ganzheitlich denken und arbeiten:* Fokussiert das gesamte Service-Ökosystem, vernachlässigt jedoch den konkreten, technischen Automatisierungsaspekt von CI/CD.
CI/CD als Wertstrom [Rahmenwerke]
1
✅
Als unterstützender Wertstrom, der primäre Wertströme befähigt
❌
Als primärer Wertstrom mit direktem Kundenkontakt
❌
Als eigenständige ITIL-Dimension
❌
Als Ersatz für den gesamten Produkt- und Servicelebenszyklus
Die Pipeline selbst liefert keinen direkten externen Kundennutzen, sondern befähigt (enabled) primäre Wertströme wie die Bereitstellung neuer Funktionen — damit ist sie ein klassischer unterstützender Wertstrom.
Merksatz:
Die CI/CD-Pipeline ist wie die
Zubringerstraße (unterstützend), die LKWs schneller auf die
Autobahn (primärer Wertstrom) bringt – sie liefert selbst kein Produkt an den Endkunden, macht den Hauptweg aber rasend schnell.
Als primärer Wertstrom mit direktem Kundenkontakt: Falsch, da CI/CD ein rein internes technisches Werkzeug ist, das der Endkunde niemals direkt sieht oder nutzt.
Als eigenständige ITIL-Dimension: Falsch, da CI/CD ein Prozess/Werkzeug ist und nicht zu den vier übergeordneten Dimensionen (wie Organisationen oder Partner) gehört.
- Als Ersatz für den gesamten Produkt- und Servicelebenszyklus: Falsch, da CI/CD nur die Bereitstellung automatisiert, aber strategische Planung, Support und Ausmusterung nicht ersetzen kann.
CI/CD Risiken und Nutzen [Rahmenwerke]
1
✅
Häufige, kleine Änderungen reduzieren das Risiko großer, riskanter Integrationen
✅
CI/CD liefert schnelleres Feedback zur Codequalität als seltene Großintegrationen
❌
CI/CD macht automatisierte Tests überflüssig
❌
Continuous Delivery bedeutet zwingend vollautomatische Produktionsfreigabe ohne jede manuelle Kontrolle
CI/CD reduziert Integrationsrisiken durch kleine, häufige Änderungen und ermöglicht schnelleres Feedback — ersetzt aber weder Tests noch macht es eine manuelle Freigabe zwingend überflüssig (das ist bei Continuous Delivery bewusst nicht der Fall).
Merksatz: "Kleine, schnelle Schritte reduzieren große Risiken und geben sofortiges Feedback zur Qualität." Denk an einen Bergsteiger, der kleine, sichere Griffe nutzt und sofort spürt, ob ein Griff hält, statt einen riesigen Sprung zu wagen.
Warum die anderen falsch sind:
CI/CD macht automatisierte Tests überflüssig: Falsch, CI/CD basiert stark auf automatisierten Tests, sie sind das Fundament für Vertrauen.
Continuous Delivery bedeutet zwingend vollautomatische Produktionsfreigabe ohne jede manuelle Kontrolle: Falsch, CD bereitet die Freigabe vor, die Entscheidung kann manuell bleiben.
CI/CD erklären [Rahmenwerke]
1
Merksatz: CI ist der "tägliche Frühsport" der Entwickler: Code wird ständig zusammengeführt und getestet, um fit zu bleiben. CD/CD ist der "Lieferdienst": Delivery macht das Produkt lieferbereit (Warte auf den Kunden-Knopf), Deployment liefert es sofort aus (Auto-Knopf gedrückt). Beides beschleunigt die Wertlieferung vom Reißbrett zum Kunden, fördert schnelles Feedback und passt zu den Phasen Build, Transition und Deliver.
Observability Definition [Rahmenwerke]
1
✅
Die Fähigkeit, den internen Zustand eines Systems anhand seiner Ausgaben zu verstehen, auch bei unbekannten Problemen
❌
Ein anderer Begriff für regelmäßige, geplante Wartungsfenster
❌
Die Fähigkeit eines Teams, Meetings virtuell abzuhalten
❌
Ein Synonym für Service Level Agreement
Observability beschreibt, wie gut sich der interne Zustand eines Systems anhand seiner nach außen sichtbaren Ausgaben (z.B. Logs, Metriken, Traces) verstehen und nachvollziehen lässt — auch bei Problemen, die vorher nicht bekannt waren.
Merksatz:
Observability ist wie ein
Röntgenblick: Du schaust von außen auf die Signale (Ausgaben) eines Körpers, um sofort zu verstehen, was tief im Inneren schiefläuft – selbst wenn es eine völlig neue Krankheit (unbekanntes Problem) ist.
Warum die anderen falsch sind:
Wartungsfenster: Verwechselt die proaktive Diagnose im laufenden Betrieb mit geplanten Service-Unterbrechungen.
Virtuelle Meetings: Verwechselt die technische Systemüberwachung fälschlicherweise mit der Kollaborationsfähigkeit von Mitarbeitern.
- Service Level Agreement: Verwechselt die technische Erkennung von Systemzuständen mit vertraglich vereinbarten Service-Zielen.
Monitoring vs. Observability [Rahmenwerke]
1
✅
Monitoring prüft bekannte Zustände, Observability erlaubt auch das Verstehen unbekannter, neuer Probleme
❌
Monitoring und Observability sind vollständig austauschbare Begriffe
❌
Observability betrifft ausschließlich die Netzwerkebene
❌
Monitoring ist ein Teilbereich der Wertschöpfungskette, Observability nicht
Monitoring prüft im Wesentlichen bekannte, vorab definierte Zustände und Schwellenwerte. Observability geht weiter: sie liefert genug Kontext, um auch unbekannte, neuartige Probleme zu diagnostizieren, für die noch kein Alarm eingerichtet wurde.
Merksatz:
Monitoring ist wie die Ölkontrollleuchte im Auto (sie blinkt nur bei bekannten Problemen), während Observability wie die On-Board-Diagnose ist, mit der du auch völlig neue, unerwartete Motorfehler tiefgründig analysieren kannst.
Warum die anderen falsch sind:
Austauschbar: Sie sind keine Synonyme, da Observability tiefer geht und auf den inneren Systemzustand schließt.
Ausschließlich Netzwerkebene: Observability umfasst das gesamte System (Anwendungen, Infrastruktur, Logs), nicht nur das Netzwerk.
- Wertschöpfungskette: Beide Konzepte sind integraler Bestandteil der ITIL-Wertschöpfungskette (insb. „Erhalten/Unterstützen“), da sie die Servicequalität sichern.
Säulen der Observability [Rahmenwerke]
1
✅
Logs (protokollierte Ereignisse)
✅
Metriken (numerische Messwerte über die Zeit)
❌
Handbücher für Endanwender
❌
Vertragsdokumente mit Lieferanten
Die drei klassischen Säulen der Observability sind Logs, Metriken (Metrics) und Traces — hier abgefragt sind Logs und Metriken als zwei der drei.
Merksatz: "Logische Metriken" sind die Observability-Säulen, die uns die IT-Welt verständlich machen. Logs protokollieren, Metriken messen.
Warum die anderen falsch sind:
Handbücher für Endanwender: Beschreiben die Nutzung, liefern aber keine Echtzeit-Betriebsdaten.
Vertragsdokumente mit Lieferanten: Regeln Beziehungen, sind keine technischen Überwachungsdaten.
Observability und SRE [Rahmenwerke]
1
✅
Sie liefert die Datengrundlage, um Zuverlässigkeitsziele/Fehlerbudgets zu überwachen und Ursachen schnell zu finden
❌
SRE und Observability sind laut ITIL zwei Namen für dieselbe Practice
❌
Observability ersetzt in SRE-Teams die Notwendigkeit von Incident Management vollständig
❌
Sie betrifft ausschließlich die Design-Phase des Lebenszyklus
SRE arbeitet mit klar definierten Zuverlässigkeitszielen (SLOs) und Fehlerbudgets — ohne gute Observability lässt sich weder erkennen, ob diese Ziele eingehalten werden, noch lässt sich die Ursache einer Verletzung schnell finden.
Observability und Dimensionen [Rahmenwerke]
1
✅
Informationen und Technologie
❌
Partner und Lieferanten
❌
Organisationen und Menschen (als primäre Zuordnung)
❌
Wertströme und Prozesse (als primäre Zuordnung)
Observability basiert auf technischen Werkzeugen und Daten (Logging-/Monitoring-Systeme, Metriken, Traces) — das ordnet sie klar der Dimension "Informationen und Technologie" zu, auch wenn sie Auswirkungen auf alle vier Dimensionen hat.
Merksatz:
Observability ist das digitale
Röntgenauge für deine IT: Du brauchst
Informationen (Daten, Logs, Metriken) und
Technologie (Monitoring-Tools), um das Innere deines Systems zu durchleuchten.
Warum die anderen falsch sind:
Partner und Lieferanten: Hier geht es um Verträge und externe Dienstleister, nicht um die technische Systemüberwachung.
Organisationen und Menschen: Betrifft Zuständigkeiten, Kultur und Teamstrukturen, liefert aber selbst keine Datenströme.
- Wertströme und Prozesse: Beschreibt den Ablauf der Aktivitäten zur Wertschöpfung, nicht die technischen Werkzeuge zur Systembeobachtung.
Observability im eigenen Umfeld [Rahmenwerke]
1
Merksatz:
Monitoring ist der Rauchmelder, der nur bei bekanntem Rauch schrillt. Observability ist die Wärmebildkamera, mit der du den unsichtbaren Schwelbrand in den Wänden ortest.
Wenn der Onlineshop ohne Alarm schleicht, weil kein einzelner Sensor anschlägt, liefert Observability das Röntgenbild: Durch die Kombination von Traces (dem Weg der Anfrage), Logs (dem Protokoll der Dienste) und Metriken (dem Lastverlauf) rekonstruierst du das unbekannte Kettenspiel der Systeme live. Du suchst nicht nach der Nadel im Heuhaufen, sondern folgst einfach dem glühenden Faden.
Komplexitätsdenken Definition [Rahmenwerke]
1
✅
Die Anerkennung, dass Serviceumgebungen komplexe, adaptive Systeme mit oft nicht-linearem Ursache-Wirkungs-Verhältnis sind
❌
Ein festes, mehrstufiges Freigabeverfahren für komplexe Änderungen
❌
Ein Synonym für die Anzahl der Konfigurationselemente in einer CMDB
❌
Eine Methode zur Berechnung von Projektkosten
Komplexitätsdenken erkennt an, dass moderne Serviceumgebungen komplexe, adaptive Systeme sind, in denen Ursache und Wirkung nicht immer linear oder vorhersehbar sind — im Gegensatz zu einfachen, klar planbaren Prozessen.
Komplexitätsdenken und Grundprinzip [Rahmenwerke]
1
✅
Kleine iterative Schritte mit Feedback erlauben Anpassung an unvorhersehbare Wirkungen statt eines starren Gesamtplans
❌
Iteratives Vorgehen ist bei komplexen Systemen ausdrücklich zu vermeiden
❌
Komplexitätsdenken ersetzt das Grundprinzip vollständig
❌
Der Zusammenhang besteht laut ITIL nicht
Da sich Wirkungen in komplexen Systemen nicht vollständig im Voraus planen lassen, passt ein iteratives Vorgehen mit kleinen Schritten und schnellem Feedback besser als ein starrer Gesamtplan — man lernt aus jedem Schritt und passt den nächsten an.
Workflowoptimierung und Wertströme [Rahmenwerke]
1
✅
Value Stream Mapping
❌
Das magische Dreieck
❌
Die RACI-Matrix (nicht der primäre Bezugspunkt)
❌
Das Continual Improvement Model (verwandt, aber nicht das direkteste Werkzeug)
Value Stream Mapping macht den Ist-Zustand eines Wertstroms sichtbar, einschließlich Engpässen und nicht-wertschöpfenden Schritten — genau die Grundlage, auf der Workflowoptimierung ansetzt.
Merksatz: Stell dir vor, du bist ein Detektiv, der den "Wert-Strom" eines Flusses verfolgt. Du zeichnest eine "Karte" (Mapping), um Engpässe und Verschwendung zu finden und so den Fluss zu optimieren. Value Stream Mapping ist genau das: Eine Karte zur Optimierung von Wertströmen und Workflows.
Warum die anderen falsch sind:
Das magische Dreieck: Fokussiert auf Kosten, Zeit, Qualität von Projekten, nicht auf Workflow-Optimierung.
Die RACI-Matrix: Klärt Rollen und Verantwortlichkeiten, optimiert aber nicht direkt den Workflow-Ablauf.
- Das Continual Improvement Model: Ist ein übergeordneter Zyklus für Verbesserungen, kein spezifisches Werkzeug zur Workflow-Visualisierung und -Optimierung.
Komplexitätsdenken Merkmale [Rahmenwerke]
1
✅
Kleine Änderungen können unerwartet große Auswirkungen haben
✅
Flexible, anpassungsfähige Vorgehensweisen sind oft wirksamer als starre Vorabplanung
❌
In komplexen Systemen ist jede Ursache-Wirkungs-Beziehung vollständig vorhersehbar
❌
Komplexitätsdenken gilt laut ITIL nur für sehr große Konzerne
Komplexitätsdenken betont Anpassungsfähigkeit statt starrer Vorabplanung und erkennt an, dass kleine Änderungen große, teils unerwartete Auswirkungen haben können — beides typische Merkmale komplexer adaptiver Systeme.
Merksatz:
Ein winziger Flügelschlag (Schmetterlingseffekt) bringt das starre Kartenhaus zum Einsturz – nur ein biegsamer Bambusstab (Flexibilität) übersteht den Sturm.
Warum die anderen falsch sind:
Vollständig vorhersehbar: In komplexen Systemen sind Zusammenhänge chaotisch und erst im Nachhinein (retrospektiv) erkennbar, niemals vorab präzise berechenbar.
Nur für große Konzerne: Moderne Dynamik und unvorhersehbare Marktänderungen treffen jede Organisationsgröße, vom Start-up bis zum Weltkonzern.
Komplexitätsdenken Beispiel [Rahmenwerke]
1
Übung [Rahmenwerke]
7
✅
ITIL liefert das Rahmenwerk, DevOps steuert Praktiken und Techniken bei
❌
ITIL ersetzt DevOps-Praktiken durch standardisierte Prozesse
❌
ITIL beschränkt DevOps auf die Softwareentwicklung
❌
ITIL positioniert DevOps als Governance-Rahmen über ITIL
ITIL und DevOps ergänzen sich: ITIL als Rahmenwerk, DevOps mit Praktiken und Techniken.
✅
Bei Continuous Deployment werden Änderungen automatisch in die Produktion ausgerollt, bei Continuous Delivery ist die Freigabe eine bewusste Entscheidung
❌
Continuous Delivery verhindert häufige Releases
❌
Continuous Deployment schließt Tests aus
❌
Beide bezeichnen dasselbe
Continuous Delivery hält Code stets auslieferbar (manuelle Freigabe); Continuous Deployment rollt automatisch in die Produktion aus.
✅
Das Verstehen des Systemverhaltens anhand von Ausgaben wie Logs, Metriken und Traces
❌
Das automatische Verhindern jeglicher Incidents
❌
Das Genehmigen von Changes vor dem Deployment
❌
Das Ersetzen von Monitoring durch Automatisierung
Observability macht das Systemverhalten über Logs, Metriken und Traces verständlich.
❌
ITIL und DevOps sollten getrennt bleiben, weil sie gegensätzliche Prinzipien haben
❌
DevOps konzentriert sich ausschließlich auf Projekt-, Programm- und Portfoliomanagement
✅
ITIL bietet den Rahmen für das Management digitaler Produkte und Services; DevOps-Praktiken unterstützen Geschwindigkeit, Feedback und Betrieb
❌
DevOps ersetzt Governance und macht ITIL Practices überflüssig
Die Quelle beschreibt DevOps als komplementär zu ITIL und nennt gemeinsame Prinzipien wie Wertorientierung, iterative Weiterentwicklung mit Feedback und transparente Zusammenarbeit.
❌
Projektmanagement verhindert iterative Weiterentwicklung mit Feedback
✅
Projekt-, Programm- und Portfolio Management unterstützen Veränderungen unterschiedlicher Größe und Geschwindigkeit
❌
Projektmanagement ersetzt das ITIL Value System
❌
Projektmanagement wird nur für Service Requests verwendet
PRINCE2 ergänzt ITIL durch Projekt-, Programm- und Portfolio Management.
❌
PRINCE2 ersetzt das ITIL Value System
❌
ITIL ist nur Projektmanagement
❌
PRINCE2 verhindert ITIL Practices
✅
ITIL fokussiert Management digitaler Produkte und Services; PRINCE2 ergänzt mit Best Practice für Projekt-, Programm- und Portfolio Management
PRINCE2 ergänzt ITIL für Projekt-, Programm- und Portfolio Management.
Merksatz:
ITIL baut das Haus (Services & Produkte), PRINCE2 leitet die Baustelle (Projekt, Programm & Portfolio). Beide arbeiten Hand in Hand: ITIL liefert den Bauplan für den laufenden Betrieb, PRINCE2 das Werkzeug für die termingerechte Umsetzung.
PRINCE2 ersetzt das ITIL Value System: Falsch, da PRINCE2 kein Service-Framework ist, sondern ein reines Projektmanagement-Werkzeug, das ITIL sinnvoll erweitert, statt es zu ersetzen.
ITIL ist nur Projektmanagement: Falsch, weil ITIL den gesamten Lebenszyklus von Services abdeckt und kein reines Projektmanagement-Framework ist.
- PRINCE2 verhindert ITIL Practices: Falsch, da PRINCE2 die Umsetzung von ITIL-Praktiken durch strukturierte Projektsteuerung überhaupt erst erfolgreich ermöglicht, statt sie zu blockieren.
❌
Warentransfer, Budgetgenehmigung und SLA-Vermeidung
❌
Nur technische Automatisierung ohne Stakeholder
✅
Wertorientierung, iterative Weiterentwicklung mit Feedback und transparente Zusammenarbeit
❌
Ausschluss von Governance, lineare Entwicklung und isolierte Teams
Die Quelle nennt diese gemeinsamen Prinzipien.
Merksatz:
Das IT-Dreamteam (ITIL, PRINCE2, DevOps) zieht an einem Strang: Sie jagen den Wert für den Kunden, gehen Schritt für Schritt mit Feedback voran und arbeiten transparent zusammen statt in Silos.
Warum die anderen falsch sind:
Warentransfer...: Fokussiert fälschlicherweise auf physische Güter und starre Bürokratie statt auf modernen Service-Wert.
Nur technische Automatisierung...: Ignoriert den Menschen, obwohl alle drei Methoden den Faktor Mensch (Kultur und Stakeholder) ins Zentrum stellen.
Ausschluss von Governance...:* Falsch, da PRINCE2 und ITIL Governance aktiv einfordern und lineare Entwicklung der agilen DevOps-Philosophie widerspricht.
ITIL und PRINCE2/DevOps [Rahmenwerke]
4
❌
DevOps ersetzt ITIL Governance vollständig
✅
PRINCE2 ergänzt ITIL durch Projekt-, Programm- und Portfolio Management
❌
PRINCE2 ist nur für den täglichen Servicebetrieb gedacht
❌
ITIL verbietet die Nutzung anderer Frameworks
Richtig ist B: PRINCE2 ergänzt ITIL insbesondere für Projekt-, Programm- und Portfolio Management. Zu den anderen Optionen: A – DevOps ersetzt ITIL Governance vollständig liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – PRINCE2 ist nur für den täglichen Servicebetrieb gedacht ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – ITIL verbietet die Nutzung anderer Frameworks beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
PRINCE ist der königliche Bauherr, der das Schloss (Projekt/Portfolio) plant und finanziert, während
ITIL der Butler ist, der den täglichen Service im Schloss perfekt organisiert. Beide arbeiten Hand in Hand.
DevOps ersetzt ITIL nicht: DevOps optimiert die Entwicklung und den Betrieb (Kollaboration), ersetzt aber nicht die übergeordnete Unternehmens-Governance.
PRINCE2 ist nicht für den Betrieb: PRINCE2 ist ein reines Projektmanagement-Framework und ungeeignet für den laufenden Linienbetrieb.
- ITIL verbietet andere Frameworks nicht: ITIL ist explizit non-proprietär und fördert die Kombination mit anderen Best Practices (wie PRINCE2 oder DevOps) zur Wertschöpfung.
✅
PRINCE2 ergänzt ITIL durch Projekt-, Programm- und Portfolio Management
❌
PRINCE2 ist nur für den täglichen Servicebetrieb gedacht
❌
ITIL verbietet die Nutzung anderer Frameworks
❌
DevOps ersetzt ITIL Governance vollständig
Richtig ist A: PRINCE2 ergänzt ITIL insbesondere für Projekt-, Programm- und Portfolio Management. Zu den anderen Optionen: B – PRINCE2 ist nur für den täglichen Servicebetrieb gedacht ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – ITIL verbietet die Nutzung anderer Frameworks beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – DevOps ersetzt ITIL Governance vollständig liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
PRINCE2 ist nur für den täglichen Servicebetrieb gedacht
❌
ITIL verbietet die Nutzung anderer Frameworks
❌
DevOps ersetzt ITIL Governance vollständig
✅
PRINCE2 ergänzt ITIL durch Projekt-, Programm- und Portfolio Management
Richtig ist D: PRINCE2 ergänzt ITIL insbesondere für Projekt-, Programm- und Portfolio Management. Zu den anderen Optionen: A – PRINCE2 ist nur für den täglichen Servicebetrieb gedacht ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – ITIL verbietet die Nutzung anderer Frameworks beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – DevOps ersetzt ITIL Governance vollständig liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
ITIL verbietet die Nutzung anderer Frameworks
❌
DevOps ersetzt ITIL Governance vollständig
✅
PRINCE2 ergänzt ITIL durch Projekt-, Programm- und Portfolio Management
❌
PRINCE2 ist nur für den täglichen Servicebetrieb gedacht
Richtig ist C: PRINCE2 ergänzt ITIL insbesondere für Projekt-, Programm- und Portfolio Management. Zu den anderen Optionen: A – ITIL verbietet die Nutzung anderer Frameworks beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – DevOps ersetzt ITIL Governance vollständig liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – PRINCE2 ist nur für den täglichen Servicebetrieb gedacht ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Übersicht [Lebenszyklus]
1
✅
Acht
❌
Sechs
❌
Fünf
❌
Zehn
Acht Stufen: Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support.
D-D-A-B-T-O-D-S
Discover — Bedarf erkennen
Design — Lösung konzipieren
Acquire — beschaffen
Build — selbst entwickeln
Transition — Übergang in den Betrieb
Operate — laufender Betrieb
Deliver — bereitstellen
Support — unterstützen
Merke: nicht starr nacheinander — iterativ, Stufen können übersprungen oder wiederholt werden.
Discover [Lebenszyklus]
5
✅
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.
PESTLE hilft beim Discover:
Politisch · Wirtschaftlich · Sozial · Technologisch · Rechtlich · Ökologisch
Merke: Discover fragt "WARUM/OB" ein Bedarf besteht — Design fragt erst danach "WIE" die Lösung aussieht.
❌
Design
✅
Discover
❌
Portfolio Management
❌
Relationship Management
Richtig ist B: Discover dient dem Verständnis von Märkten, Stakeholdern, Bedürfnissen, Chancen und Einschränkungen. Zu den anderen Optionen: A – Design ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit.; C – Portfolio Management kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; D – Relationship Management ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit..
Merksatz:
Wer
entdecken will, was der Markt braucht und wo Chancen oder Risiken lauern, schaut durch das Fernglas der
Discover-Phase – wir suchen nach neuen Pfaden, bevor wir überhaupt etwas planen oder bauen.
Warum die anderen falsch sind:
Design: Hier wird das Produkt bereits konkret gestaltet und nicht erst nach Trends und ungelösten Bedürfnissen geforscht.
Portfolio Management: Das ist die strategische Investitionsentscheidung über das gesamte Service-Portfolio, nicht die Detailanalyse eines einzelnen Produkts.
- Relationship Management: Dies pflegt die Beziehungen zu den Stakeholdern, statt systematisch Markttrends und Produktchancen zu analysieren.
✅
Discover
❌
Portfolio Management
❌
Relationship Management
❌
Design
Richtig ist A: Discover dient dem Verständnis von Märkten, Stakeholdern, Bedürfnissen, Chancen und Einschränkungen. Zu den anderen Optionen: B – Portfolio Management kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; C – Relationship Management ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; D – Design ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit..
Merksatz:
Wer
Detektiv spielt und nach Trends, Risiken sowie unentdeckten Bedürfnissen sucht, will Neues
Discovern (entdecken) – die Lupe vor dem ersten Schritt.
Portfolio Management ist falsch: Weil hier noch keine Entscheidungen über Investitionen oder die Zusammensetzung des gesamten Service-Katalogs getroffen werden.
Relationship Management ist falsch: Weil es um die analytische Marktforschung geht und nicht um den aktiven Beziehungsaufbau oder die Pflege von Stakeholder-Kontakten.
- Design ist falsch: Weil das Team noch in der Erkundungsphase ist und noch keine konkreten Blaupausen oder Spezifikationen für die neue Version erstellt.
❌
Portfolio Management
❌
Relationship Management
❌
Design
✅
Discover
Richtig ist D: Discover dient dem Verständnis von Märkten, Stakeholdern, Bedürfnissen, Chancen und Einschränkungen. Zu den anderen Optionen: A – Portfolio Management kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; B – Relationship Management ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; C – Design ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit..
Merksatz:
Discover ist wie das
Aufdecken von Neuland mit der Lupe: Bevor die Reise weitergeht,
entdeckst du Trends, Risiken und versteckte Bedürfnisse im Ist-Zustand.
Portfolio Management ist falsch, weil es um die strategische Investitionsentscheidung und Freigabe des gesamten Katalogs geht, nicht um die Detailanalyse von Trends und Bedürfnissen.
Relationship Management ist falsch, weil es Beziehungen und Empathie zu Stakeholdern pflegt, statt strukturierte Markt- und Risikoanalysen für das Produkt durchzuführen.
- Design ist falsch, weil hier bereits konkrete Lösungen und Architekturen gestaltet werden, anstatt erst nach den grundlegenden Chancen und Anforderungen zu forschen.
❌
Relationship Management
❌
Design
✅
Discover
❌
Portfolio Management
Richtig ist C: Discover dient dem Verständnis von Märkten, Stakeholdern, Bedürfnissen, Chancen und Einschränkungen. Zu den anderen Optionen: A – Relationship Management ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; B – Design ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit.; D – Portfolio Management kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität..
Merksatz:
Bevor die Reise losgeht, schlägt das Team die Augen auf und nutzt den
Kompass (Discover), um den Horizont nach Trends, Bedürfnissen und Risiken abzusuchen – wer
entdeckt, plant noch nicht.
Warum die anderen falsch sind:
Relationship Management: Konzentriert sich auf die Pflege von Beziehungen zu Stakeholdern, nicht auf die strategische Marktanalyse.
Design: Gestaltet bereits konkrete Lösungen und Services, anstatt erst nach Chancen und Trends zu forschen.
- Portfolio Management: Trifft die finalen Investitionsentscheidungen über das gesamte Service-Portfolio, statt die vorgelagerte Detailanalyse durchzuführen.
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 [Lebenszyklus]
1
✅
Notwendige Ressourcen sichern und effizient zuweisen
❌
Funktionstüchtige Prototypen für Tests erstellen
❌
Incidents beheben und Wiederherstellungsverfahren durchführen
❌
Services bereitstellen und das Anwender-Onboarding managen
Acquire sichert die notwendigen Ressourcen (z.B. durch Einkauf, Lizenzierung, Beauftragung externer Anbieter) und weist sie effizient zu - als eigenständige Stufe getrennt von "Build".
Merksatz: "Acquire" ist wie ein IT-Einkäufer, der die besten Werkzeuge und Leute für ein Projekt beschafft und klug verteilt, damit die Arbeit optimal laufen kann. Es geht um die Sicherstellung und Zuteilung von allem Nötigen.
Warum die anderen falsch sind:
Funktionstüchtige Prototypen für Tests erstellen: Das gehört eher zu Design und Transition, nicht primär zu Acquire.
Incidents beheben und Wiederherstellungsverfahren durchführen: Das ist Operation, also der Betrieb.
- Services bereitstellen und das Anwender-Onboarding managen: Das ist eher Transition und Operation.
Transition [Lebenszyklus]
5
✅
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.
✅
Transition
❌
Operate
❌
Deliver
❌
Build
Richtig ist A: Transition führt neue oder geänderte Produkte und Services in Live-Umgebungen ein. Zu den anderen Optionen: B – Operate kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; C – Deliver ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; D – Build ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit..
Merksatz:
Die
Transition ist die „Brücke zur Live-Umgebung“: Sobald gebaut wurde, packst du die Koffer (Datenmigration, Schulung, Monitoring) und ziehst kontrolliert in das neue Live-Heim um.
Warum die anderen falsch sind:
Operate: Ist falsch, weil hier noch nicht der laufende Regelbetrieb und Support stattfinden, sondern erst die Übergabe dorthin vorbereitet wird.
Deliver: Ist falsch, weil dies die laufende Erbringung und den tatsächlichen Werttransfer des Services beschreibt, nicht die technische Einführung.
- Build: Ist falsch, weil die Entwicklung und das Testen bereits abgeschlossen sind und die Erstellungsphase somit hinter uns liegt.
❌
Operate
❌
Deliver
❌
Build
✅
Transition
Richtig ist D: Transition führt neue oder geänderte Produkte und Services in Live-Umgebungen ein. Zu den anderen Optionen: A – Operate kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; B – Deliver ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; C – Build ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit..
❌
Deliver
❌
Build
✅
Transition
❌
Operate
Richtig ist C: Transition führt neue oder geänderte Produkte und Services in Live-Umgebungen ein. Zu den anderen Optionen: A – Deliver ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; B – Build ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit.; D – Operate kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität..
❌
Build
✅
Transition
❌
Operate
❌
Deliver
Richtig ist B: Transition führt neue oder geänderte Produkte und Services in Live-Umgebungen ein. Zu den anderen Optionen: A – Build ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit.; C – Operate kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; D – Deliver ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit..
Merksatz:
Denke bei
Transition an die „Transit-Zone“ am Flughafen: Du reist vom sicheren Entwicklungsland (Build) ab, nimmst dein Gepäck (Datenmigration und Schulung) mit und gehst durch die Schleuse in die Live-Welt.
Warum die anderen falsch sind:
Build: Ist bereits abgeschlossen, da Entwicklung und Tests hiernach fertiggestellt sind.
Operate: Findet erst statt, wenn das Portal im laufenden Regelbetrieb läuft und der Übergang komplett vollzogen ist.
- Deliver: Bezieht sich auf die fortlaufende Bereitstellung von Services im Alltag, nicht auf die einmalige Überführungsphase.
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 [Lebenszyklus]
5
✅
Management des Anwender-Onboardings
❌
Monitoring von Support-Systemen
❌
Entwerfen von Produktprototypen
❌
Beschaffung von Lieferantenressourcen
Deliver ist eine EIGENSTÄNDIGE Stufe (nicht mit Support zusammengefasst): sie macht den fertigen Service für die Nutzer:innen zugänglich, u.a. durch Anwender-Onboarding.
Merksatz:
Bei Deliver wird geliefert und der Gast an den Tisch gesetzt – das Onboarding bringt den Anwender direkt ins gemachte Nest des Service-Betriebs.
Monitoring von Support-Systemen: Gehört zu Monitor (Überwachung der Infrastruktur, nicht die Bereitstellung an den Nutzer).
Entwerfen von Produktprototypen: Gehört zu Design (Konzeptionierung und Entwurf vor der eigentlichen Übergabe).
Beschaffung von Lieferantenressourcen: Gehört zu Source* (Einkauf und Bereitstellung von externen Mitteln).
❌
Support
❌
Operate
❌
Transition
✅
Deliver
Richtig ist D: Deliver umfasst Servicebereitstellung, Service Requests und vereinbarte Serviceaktionen. Zu den anderen Optionen: A – Support kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; B – Operate ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; C – Transition ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit..
Merksatz:
Deliver liefert den fertigen Service direkt an den Kunden aus – so wie der Paketbote das bestellte Paket (Material, Zugriff, Onboarding) direkt an der Haustür übergibt.
Warum die anderen falsch sind:
Support: Hilft erst, wenn nach der Übergabe Probleme oder Fragen auftreten.
Operate: Sichert den laufenden Betrieb und die Überwachung im Hintergrund, statt neue User aktiv aufzunehmen.
- Transition: Plant und testet die Veränderung von Services, führt aber nicht das tägliche, standardisierte operative Onboarding durch.
❌
Operate
❌
Transition
✅
Deliver
❌
Support
Richtig ist C: Deliver umfasst Servicebereitstellung, Service Requests und vereinbarte Serviceaktionen. Zu den anderen Optionen: A – Operate ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; B – Transition ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit.; D – Support kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität..
Merksatz:
Deliver liefert das fertige Paket direkt an den Kunden aus: Onboarding, Materialübergabe und Standardzugriffe sind wie das Überreichen der Zimmerschlüssel im Hotel – der Service wird in diesem Moment aktiv bereitgestellt und übergeben.
Warum die anderen falsch sind:
Operate: Ist falsch, weil hier der laufende Systembetrieb und die Infrastrukturüberwachung im Hintergrund stattfinden, nicht die konkrete Übergabe an den Nutzer.
Transition: Ist falsch, weil diese Phase das Planen, Testen und Freigeben neuer Services beschreibt, während hier bereits ein bestehender Service genutzt wird.
- Support: Ist falsch, weil Support erst greift, wenn im laufenden Betrieb Fehler auftreten oder Fragen zu klären sind (reaktive Hilfe).
❌
Transition
✅
Deliver
❌
Support
❌
Operate
Richtig ist B: Deliver umfasst Servicebereitstellung, Service Requests und vereinbarte Serviceaktionen. Zu den anderen Optionen: A – Transition ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit.; C – Support kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; D – Operate ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit..
✅
Deliver
❌
Support
❌
Operate
❌
Transition
Richtig ist A: Deliver umfasst Servicebereitstellung, Service Requests und vereinbarte Serviceaktionen. Zu den anderen Optionen: B – Support kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; C – Operate ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; D – Transition ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit..
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.
Merksatz:
Der Kompass spart die Irrfahrt: Schon der erste Schritt im Nebel (Discover) schafft unbezahlbaren Wert, indem er den falschen Weg verhindert – Erkenntnis ist das erste Gold!
Warum die anderen falsch sind:
Ausschließlich in "Operate" falsch: Ignoriert, dass Planung und Design bereits teure Fehlentwicklungen verhindern und somit früh Wert stiften.
Ausschließlich in "Deliver und Support" falsch: Reduziert Wert rein auf den Betrieb, obwohl strategische Weichenstellungen den eigentlichen Grundstein legen.
- Erst nach allen 8 Stufen falsch: Setzt fälschlicherweise voraus, dass Wert starr linear entsteht, statt agil und inkrementell in jeder Phase.
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]
5
✅
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.
❌
Transition
❌
Operate
✅
Support
❌
Deliver
Richtig ist C: Support konzentriert sich auf Anwenderunterstützung, Incidents, Probleme und Service Requests. Zu den anderen Optionen: A – Transition ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; B – Operate ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit.; D – Deliver kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität..
❌
Operate
✅
Support
❌
Deliver
❌
Transition
Richtig ist B: Support konzentriert sich auf Anwenderunterstützung, Incidents, Probleme und Service Requests. Zu den anderen Optionen: A – Operate ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit.; C – Deliver kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; D – Transition ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit..
Merksatz:
Wenn Anwender rufen und der Betrieb gestört ist, leistet das Team
Support als Retter in der Not – sie nehmen Anfragen an, stellen den Normalzustand wieder her und analysieren Fehler im laufenden Betrieb.
Warum die anderen falsch sind:
Operate: Ist falsch, weil diese Phase das reine, reibungslose Laufenlassen der Services beschreibt, nicht aber die aktive Entgegennahme von Störungen und die Hilfe für Anwender.
Deliver: Ist falsch, weil hier Services erst bereitgestellt, ausgerollt und übergeben werden, statt bestehende Probleme im Live-Betrieb zu lösen.
- Transition: Ist falsch, weil dies die Phase der Veränderung und des Testens (Überführung von Neuem in den Betrieb) ist, nicht die tägliche Störungsbehebung.
✅
Support
❌
Deliver
❌
Transition
❌
Operate
Richtig ist A: Support konzentriert sich auf Anwenderunterstützung, Incidents, Probleme und Service Requests. Zu den anderen Optionen: B – Deliver kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; C – Transition ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; D – Operate ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit..
Merksatz:
Der
Support ist dein Rettungsring im Alltag: Wenn Bürger stranden, nimmt er die Hand (Anfragen), wirft den Rettungsring (Wiederherstellung) und flickt danach das Boot (Fehleranalyse).
Warum die anderen falsch sind:
Deliver ist falsch, weil hier kein neuer Service übergeben, sondern der bestehende im Alltag gerettet wird.
Transition ist falsch, weil es um die Veränderung und Inbetriebnahme geht, nicht um die laufende Störungsbehebung.
- Operate ist falsch, weil dies die rein technische Überwachung und Systempflege im Hintergrund beschreibt, ohne den direkten, helfenden Anwenderkontakt.
❌
Deliver
❌
Transition
❌
Operate
✅
Support
Richtig ist D: Support konzentriert sich auf Anwenderunterstützung, Incidents, Probleme und Service Requests. Zu den anderen Optionen: A – Deliver kann im Umfeld vorkommen, ist im Szenario aber nicht die Hauptaktivität.; B – Transition ist plausibel, passt jedoch weniger genau zur beschriebenen Arbeit.; C – Operate ist eng verwandt, beschreibt aber nicht den primären Schwerpunkt der beschriebenen Arbeit..
Merksatz:
Support ist die Feuerwehr im Alltag: Sobald Anwender rufen (Störungen/Fragen) und du den Normalbetrieb rettest (wiederherstellst) oder Fehler analysierst, leistest du
Support – du hältst dem laufenden Betrieb den Rücken frei.
Warum die anderen falsch sind:
Deliver: Ist falsch, weil hier kein neuer Service übergeben oder bereitgestellt wird, sondern ein bestehender repariert wird.
Transition: Ist falsch, weil kein Wechsel oder keine Inbetriebnahme (Go-Live) einer neuen Softwareversion stattfindet.
- Operate: Ist falsch, weil hier der Fokus auf der reinen Systemüberwachung und dem Routinebetrieb liegt, nicht auf der direkten Störungsbehebung für den Anwender.
Stufenreihenfolge [Lebenszyklus]
1
✅
Discover
✅
Transition
❌
Governance
✅
Deliver und Support
Merksatz: "Dein DISCOVER-Projekt TRANSLATE-iert, dann DELIVER-t es und SUPPORT-iert sich selbst."
Warum die anderen falsch sind:
Governance: Ist ein übergreifendes Konzept, keine spezifische Lebenszyklusphase.
Die anderen Optionen sind keine Bestandteile der 8 Stufen des Produkt- und Servicelebenszyklus.
Nicht-lineares Vorgehen [Lebenszyklus]
1
Discover vs. Design [Lebenszyklus]
1
Merksatz:
Discover ist der Detektiv, Design ist der Architekt.
Discover (Entdecken) fragt nach dem WARUM: Gibt es überhaupt einen Schatz (Bedarf) zu heben? Es geht um die Erkennung und Validierung der Chance.
Design (Gestalten) fragt nach dem WIE: Wie bauen wir die Kiste (Lösung), um den Schatz sicher zu bergen? Es geht um die konkrete Konzeption.
Kurz: Discover findet das Problem, Design entwirft die Lösung.
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.
Merksatz: Stell dir einen Fluss (Wertstrom) vor, der durch verschiedene Landschaften (Lebenszyklusstufen) fließt – er berührt immer mehrere gleichzeitig, um sein Ziel zu erreichen.
Warum die anderen falsch sind:
- Nein, ein Wertstrom entspricht immer genau einer Stufe: Ignoriert die End-to-End-Natur von Wertströmen.
- Nein, Wertströme und Lebenszyklus sind unabhängig: Verkennt die Integration des ITIL-Frameworks.
- Nur bei sehr kleinen Organisationen möglich: Schränkt die Skalierbarkeit und Flexibilität von ITIL unnötig ein.
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
Merksatz:
Der ITIL-Lebenszyklus ist kein starrer Einbahnstraßen-Tunnel, sondern ein flexibler Agilitäts-Spielplatz: Du darfst Stufen überspringen, wie beim Kastenbrot hin- und herspringen und naschst die süßen Früchte des Erfolgs (Wert) schon lange vor dem Spielende!
Warum die anderen falsch sind:
„Genau einmal durchlaufen“ ist falsch*, weil starres Wasserfall-Denken der agilen Realität widerspricht und Iteration ständige Wiederholungen fordert.
Eigenes Lebenszyklus-Beispiel [Lebenszyklus]
1
Wann zurück zu Design? [Lebenszyklus]
1
Build [Lebenszyklus]
1
✅
Build
❌
Acquire
❌
Design
❌
Transition
Build ist die eigenständige Stufe der internen Eigenentwicklung/Konfiguration, getrennt von Acquire (externe Beschaffung).
Merksatz: Der
Build-Meister
baut die Servicekomponenten intern zusammen, wie ein Lego-Experte, der aus Einzelteilen ein fertiges Modell erstellt.
Warum die anderen falsch sind:
Acquire: Konzentriert sich auf den externen Einkauf oder die Beschaffung, nicht die interne Erstellung.
Design: Legt fest,
was gebaut werden soll, nicht
wie oder die tatsächliche Erstellung.
- Transition: Bezieht sich auf die Überführung des fertigen Services in den Betrieb, nicht auf seine Entwicklung.
Erfolgsmessgrößen Discover [Lebenszyklus]
1
✅
Service-Performance im Vergleich zu vereinbarten SLA-Zielen
❌
Strategische Übereinstimmung der Produkt- und Serviceangebote mit den Unternehmenszielen
❌
Marktrelevanz der identifizierten Produkt- und Serviceideen
❌
Stakeholder-Zufriedenheit mit den erhobenen Anforderungen
Service-Performance im Vergleich zu vereinbarten SLA-Zielen ist eine Betriebs-Messgröße (z.B. für Operate), keine Discover-Messgröße.
Merksatz: „Discover“ ist wie ein Detektiv, der neue Spuren sucht. Er bewertet nicht, ob der alte Fall (SLA-Ziele) gut gelöst wurde, sondern ob er neue, relevante Hinweise (Ideen, Anforderungen) findet, die zum Ziel führen.
Warum die anderen falsch sind:
Strategische Übereinstimmung: Misst, ob die gefundenen Ideen zur Strategie passen.
Marktrelevanz: Misst die Relevanz der identifizierten Ideen.
Stakeholder-Zufriedenheit: Misst die Zufriedenheit mit den erhobenen* Anforderungen.
Erfolgsmessgrößen Acquire [Lebenszyklus]
1
✅
Qualität der von Lieferanten bezogenen Ressourcen und Services
❌
Anzahl und Auswirkung von Incidents und Performance-Abweichungen
❌
Service-Performance im Vergleich zu vereinbarten SLA-Zielen
❌
Negative Auswirkung von Changes auf Serviceverfügbarkeit
Die Qualität der von Lieferanten bezogenen Ressourcen und Services ist die zentrale Acquire-Messgröße - es geht um erfolgreiche Beschaffung.
Merksatz: „Acquire“ ist wie der Einkauf im Supermarkt: Die Qualität der eingekauften Produkte (Ressourcen & Services) ist entscheidend für den späteren Genuss.
Warum die anderen falsch sind:
Anzahl und Auswirkung von Incidents und Performance-Abweichungen: Misst eher den Betrieb (Operate), nicht den Erwerb.
Service-Performance im Vergleich zu vereinbarten SLA-Zielen: Misst die Service-Nutzung und -Erfüllung, nicht den Beschaffungsprozess.
- Negative Auswirkung von Changes auf Serviceverfügbarkeit: Fokussiert auf Änderungsmanagement (Change Enablement), nicht auf den Erwerb.
Übung [Lebenszyklus]
25
❌
Build
✅
Transition
❌
Deliver
❌
Operate
Transition überführt neue/geänderte Produkte nahtlos in den Betrieb.
❌
Support
✅
Operate
❌
Deliver
❌
Transition
Operate ist für Aufrechterhaltung und Überwachung des laufenden Betriebs zuständig.
Merksatz:
Operate ist der „Operator“ im Cockpit, der das laufende System im täglichen
Betrieb steuert und auf den Monitoren
überwacht.
Support ist falsch, weil dies nur die reaktive Hilfe bei Störungen ist, nicht der laufende Betrieb selbst.
Deliver ist falsch, da hierbei Produkte nur bereitgestellt und übergeben, aber nicht dauerhaft betrieben werden.
- Transition ist falsch, weil diese Phase nur den Übergang (die Veränderung) steuert, nicht den regulären Zustand.
❌
Incidents lösen und Wiederherstellung durchführen
✅
Benötigte Ressourcen effizient beschaffen und bereitstellen
❌
Anwender onboarden und Services bereitstellen
❌
Prototypen für Tests erstellen
Acquire beschafft und alloziert die benötigten Ressourcen effizient.
✅
Design
❌
Build
❌
Discover
❌
Transition
Design erstellt Prototypen und Spezifikationen als Grundlage für die weitere Umsetzung.
Merksatz:
Wer
designt, zeichnet den Bauplan – Prototypen und Spezifikationen sind die Skizzen des Architekten, bevor die Maurer anrücken.
Warum die anderen falsch sind:
Build: Hier wird bereits konkret programmiert und erschaffen, nicht mehr nur spezifiziert oder als Prototyp entworfen.
Discover: Dies ist die reine Erkundungs- und Analysephase, in der Anforderungen gesammelt, aber noch keine konkreten Prototypen erstellt werden.
- Transition: Hier geht es um die Überführung und Inbetriebnahme des fertigen Produkts in den Live-Betrieb, die Entwicklung ist bereits abgeschlossen.
❌
Servicearchitekturen entwerfen
✅
Anwender unterstützen und die Serviceleistung aufrechterhalten
❌
Lösungskomponenten erstellen
❌
Neue Geschäftschancen entdecken
Support unterstützt Anwender und hält die Serviceleistung aufrecht (Incidents, Probleme, Anfragen).
✅
Produktfähigkeiten mit den Bedürfnissen der Konsumenten und der Strategie in Einklang bringen
❌
Ressourcen beschaffen
❌
Produkte in den Betrieb überführen
❌
Anwender unterstützen
Discover richtet Produktfähigkeiten an Konsumentenbedürfnissen und Strategie aus.
❌
Design
✅
Build
❌
Transition
❌
Operate
Build erstellt oder ändert Produkte gemäß den Anforderungen.
Merksatz:
Wer etwas
erstellt oder
verändert, der
baut es physisch auf:
Build ist die Werkstatt, in der Produkte aktiv gehämmert, geschraubt und nach Anforderungen fertiggestellt werden.
Design ist falsch: Hier wird nur der theoretische Bauplan gezeichnet, aber noch nichts real erschaffen oder verändert.
Transition ist falsch: Diese Phase überführt das bereits fertige Produkt nur in die Live-Umgebung (Logistik, nicht Produktion).
- Operate ist falsch: Hier wird das Produkt im laufenden Betrieb nur genutzt und unterstützt, nicht mehr konstruiert.
✅
Erfolgsquote der in die Live-Umgebung überführten Releases
❌
Zahl neuer Serviceideen
❌
Durchschnittskosten pro Serviceanfrage
❌
Anteil abgebildeter Wertströme
Die Erfolgsquote der Überführung in den Betrieb misst die Leistung von Transition.
❌
Zahl innerhalb der Ziele gelöster Incidents
✅
Qualität der Produktlösungen
❌
Erstlösungsquote von Serviceanfragen
❌
Kundenzufriedenheit nach der Servicebereitstellung
Die Qualität der erstellten Produktlösungen ist die passende Erfolgsgröße für Build.
❌
Governance, Wertschöpfungskette, Practices, Grundprinzipien und Improvement
✅
Discover, Design, Acquire, Build, Transition, Operate, Deliver und Support
❌
Plan, Improve, Engage, Design, Obtain/Build, Deliver and Support
❌
Strategy, Design, Transition, Operation und Continual Improvement
Der Syllabus listet die acht Aktivitäten des Lebenszyklusmanagements digitaler Produkte und Services.
Merksatz:
Der Servicelebenszyklus ist wie der Bau eines Hauses: Erst musst du das Grundstück entdecken (
Discover) und planen (
Design), die Steine erwerben (
Acquire) und mauern (
Build), die Schlüssel übergeben (
Transition), einziehen und wohnen (
Operate) sowie das Haus pflegen und instand halten (
Deliver und Support).
Warum die anderen falsch sind:
Governance, Wertschöpfungskette...: Das sind die fünf Kernkomponenten des ITIL-Service-Wertsystems (SVS), keine Lebenszyklus-Aktivitäten.
Plan, Improve, Engage...: Das beschreibt die sechs Aktivitäten der ITIL-Service-Wertschöpfungskette (Value Chain), nicht den gesamten Produktlebenszyklus.
- Strategy, Design, Transition...: Das ist der veraltete Lebenszyklus aus ITIL v3, der in der aktuellen Version so nicht mehr existiert.
❌
Produkte und Services in Live-Umgebungen betreiben
❌
Vereinbarte Serviceaktionen für Anwender erfüllen
❌
Incidents und Probleme untersuchen und lösen
✅
Märkte, Stakeholder, Bedürfnisse, Chancen und Einschränkungen verstehen
Die Quelle beschreibt den Zweck von „Discover“ entsprechend dieser Antwort; die anderen Optionen gehören zu anderen Aktivitäten des Produkt- und Servicelebenszyklus.
❌
Vereinbarte Serviceaktionen für Anwender erfüllen
❌
Incidents und Probleme untersuchen und lösen
✅
Neue oder geänderte Produkte und Services in Live-Umgebungen einführen
❌
Produkte und Services in Live-Umgebungen betreiben
Die Quelle beschreibt den Zweck von „Transition“ entsprechend dieser Antwort; die anderen Optionen gehören zu anderen Aktivitäten des Produkt- und Servicelebenszyklus.
Merksatz:
Transition ist die Brücke zur Realität: Stell dir vor, du fährst mit einem Transit-Transporter (Transition) neue Produkte direkt in die Live-Umgebung (Einführung).
Warum die anderen falsch sind:
Serviceaktionen erfüllen: Das ist die operative Servicebereitstellung (Deliver and Support), die tägliche Anfragen abarbeitet.
Incidents und Probleme lösen: Dies gehört zum laufenden Betrieb und Support (Deliver and Support), nicht zur Einführung.
Produkte im Live-Betrieb betreiben: Das ist der dauerhafte Betrieb (Deliver and Support*), während die Transition nur den Übergang dorthin gestaltet.
❌
Ausschließlich als Projektphasen mit einmaliger Übergabe
❌
Nur dann, wenn ein Service Level Agreement fehlt
✅
Nicht sequenziell oder linear, sondern iterativ und kontextabhängig
❌
Immer in einer festen Reihenfolge von Discover bis Support
Der Syllabus fordert das Verständnis, dass die Aktivitäten weder sequenziell noch linear sind und iterativ genutzt werden können.
❌
Service Requests erfüllen
❌
Märkte analysieren
✅
Produkte und Services gestalten, die den Anforderungen der Stakeholder entsprechen
❌
Incidents lösen
Design gestaltet Produkte und Services anhand der Anforderungen.
❌
Live-Betrieb sicherstellen
❌
Anwender unterstützen
❌
Servicequalität messen
✅
Externe Ressourcen, Produkte und Services beschaffen, die für das Produkt- und Servicemanagement benötigt werden
Acquire beschafft benötigte externe Ressourcen, Produkte und Services.
❌
Produkte prototypisieren
❌
Lieferanten onboarden
❌
Vision definieren
✅
Produkte und Services in Live-Umgebungen betreiben und sicherstellen, dass sie erwartungsgemäß funktionieren
Operate betreibt Produkte und Services in Live-Umgebungen.
✅
Services bereitstellen und vereinbarte Serviceaktionen für Servicekonsumenten ausführen
❌
KI-Governance etablieren
❌
Codeänderungen integrieren
❌
Märkte verstehen
Deliver umfasst Servicebereitstellung und Serviceaktionen.
✅
Produkte und Services erstellen oder ändern, sodass sie den Anforderungen entsprechen
❌
Budget genehmigen
❌
SLA vereinbaren
❌
PESTLE analysieren
Build erstellt oder ändert Produkte und Services.
Merksatz:
„Build“ baut die Lösung: Stell dir einen Bauarbeiter auf einer Baustelle vor, der mit Helm und Kelle ein Haus exakt nach Bauplan hochzieht oder umbaut – er erschafft das konkrete Produkt.
Budget genehmigen: Dies ist eine reine Management- und Finanzentscheidung (Plan/Govern) und kein operativer Erstellungsprozess.
SLA vereinbaren: Das Verhandeln von Service-Level-Agreements gehört zur Aktivität „Design and Transition“ oder „Engage“ (Kundenkontakt), nicht zum eigentlichen Bauen.
- PESTLE analysieren: Diese strategische Umweltanalyse (Politisch, Ökonomisch etc.) findet ganz am Anfang in der „Plan“-Phase statt, lange bevor der erste Stein gelegt wird.
❌
Vision definieren
❌
Code automatisch deployen
✅
Anwender unterstützen und Incidents, Probleme und Service Requests bearbeiten
❌
Waren übertragen
Support unterstützt Anwender und behandelt Incidents, Probleme und Service Requests.
❌
Sie betreibt Services live
❌
Sie erfüllt Service Requests
❌
Sie deployt Releases
✅
Sie schafft Verständnis über Märkte, Stakeholder und Chancen, bevor Lösungen gestaltet werden
Discover dient dem Verstehen von Märkten, Stakeholdern und Chancen.
Merksatz:
Discover ist der „Entdecker“: Bevor du die Segel setzt (Lösungen gestaltest), musst du die Landkarte zeichnen – du erkundest den Markt, die Stakeholder und deine Chancen.
Warum die anderen falsch sind:
Services live betreiben: Das ist die Betriebsphase (Run / Deliver & Support), nicht das erste Entdecken.
Service Requests erfüllen: Dies ist das operative Tagesgeschäft (Fulfill) für bereits bestehende Services.
Releases deployen: Das ist die technische Bereitstellung (Deploy / Transition*), die erst viel später nach der Konzeption stattfindet.
❌
Deliver ist Governance
✅
Deliver umfasst Servicebereitstellung, Erfüllung von Service Requests und andere Serviceaktionen
❌
Deliver ist Codeerstellung
❌
Deliver ist Beschaffung
Deliver umfasst Servicebereitstellung und Service Requests.
❌
Deliver
❌
Support
✅
Transition
❌
Build
Transition führt Lösungen in Live-Umgebungen ein.
Merksatz:
Denke an den
„Transit-Bereich“ am Flughafen: Hier findet der Übergang statt – die
Transition bringt Services sicher von der Entwicklung direkt in die Live-Umgebung (den „Zielflughafen“).
Warum die anderen falsch sind:
Deliver: Fokussiert sich auf die laufende Bereitstellung und den Betrieb für den Nutzer, nicht auf die eigentliche Einführung.
Support: Kümmert sich um die Behebung von Störungen im laufenden Betrieb, wenn das Produkt bereits live ist.
- Build: Erstellt und testet die Services nur in der Entwicklungsumgebung, führt sie aber noch nicht live.
❌
Acquire
❌
Design
✅
Operate
❌
Discover
Operate betreibt Produkte und Services live.
✅
Acquire
❌
Support
❌
Deliver
❌
Transition
Acquire beschafft benötigte externe Ressourcen, Produkte und Services.
Merksatz:
Acquire klingt wie das deutsche „Akquirieren“ – wer Ressourcen, Produkte und Services von außen beschafft,
akquiriert (Acquire) sie für sein Unternehmen.
Warum die anderen falsch sind:
Support: Ist für den laufenden Support und die Behebung von Störungen da, nicht für den Einkauf.
Deliver: Liefert fertige Services an die Kunden aus, anstatt Vorprodukte einzukaufen.
- Transition: Überführt Services in den Live-Betrieb, beschafft aber selbst keine Ressourcen.
✅
Design
❌
Operate
❌
Support
❌
Deliver
Design gestaltet Produkte und Services.
Begriff Wertstrom [Wertströme]
1
✅
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.
Haupt- vs. unterstützender Wertstrom:
Hauptwertstrom → Wert direkt für externe Stakeholder
Unterstützender Wertstrom → ermöglicht den Hauptwertstrom im Hintergrund
Merkhilfe: "Hauptwertstrom sieht der Kunde, unterstützender Wertstrom sieht er nicht."
Hauptwertstrom [Wertströme]
1
✅
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
Merksatz:
Ein Wertstrom ist wie ein Flusslauf: Er fließt in einer Abfolge von Schritten, mündet als Hauptstrom direkt im Ozean (externer Wert) und seine Engpässe werden durch eine Landkarte (Mapping) sichtbar gemacht.
Warum die anderen falsch sind:
Unterstützende Wertströme sind für die Organisation ohne Bedeutung:* Falsch, da sie zwar keinen direkten Kundennutzen stiften, aber als internes Fundament (z. B. HR oder IT-Infrastruktur) für das Funktionieren der Hauptwertströme absolut überlebenswichtig sind.
Engpass im eigenen Wertstrom finden [Wertströme]
1
Value Stream Mapping durchführen [Wertströme]
1
Unterstützender Wertstrom [Wertströme]
1
✅
Er ermöglicht die Hauptwertströme, liefert aber selbst keinen direkten externen Wert
❌
Er ist wichtiger als jeder Hauptwertstrom
❌
Er richtet sich ausschließlich an externe Kunden
❌
Er ersetzt die Notwendigkeit von Hauptwertströmen
Er ermöglicht/unterstützt die Hauptwertströme im Hintergrund, ohne selbst direkten externen Wert zu liefern.
Value Stream Mapping [Wertströme]
1
✅
Um einen Wertstrom zu visualisieren und Verbesserungspotenziale sichtbar zu machen
❌
Um ausschließlich Budgetpläne zu erstellen
❌
Um Mitarbeitergehälter zu berechnen
❌
Um Serverkapazitäten zu dimensionieren
Um einen Wertstrom zu visualisieren und Verbesserungspotenziale (z.B. Engpässe) sichtbar zu machen.
Beispiel Hauptwertstrom [Wertströme]
1
✅
Der Weg von einer Kundenanfrage bis zur ausgelieferten Lösung
❌
Interne Schulung neuer Mitarbeitender im Servicedesk
❌
Interne IT-Sicherheitsaudits ohne Kundenkontakt
❌
Die interne Buchhaltung
Der Ablauf von der Kundenanfrage bis zur ausgelieferten Lösung erzeugt direkt externen Wert.
Merksatz: Ein Hauptwertstrom ist wie eine Autobahn, die direkt vom Kundenwunsch zum fertigen Produkt oder Service führt und dabei alle notwendigen Schritte integriert.
Warum die anderen falsch sind:
Interne Schulung neuer Mitarbeitender im Servicedesk: Unterstützt den Wertstrom, ist aber kein direkter End-to-End-Wertstrom für den Kunden.
Interne IT-Sicherheitsaudits ohne Kundenkontakt: Wichtige interne Kontrolle, aber keine direkte Wertschöpfung aus Kundensicht.
- Die interne Buchhaltung: Essenzielle unterstützende Funktion, aber kein kundenorientierter Hauptwertstrom.
Beispiel unterstützender Wertstrom [Wertströme]
1
✅
Interne Schulung von Mitarbeitenden, die später im Kundenkontakt arbeiten
❌
Direkte Auslieferung eines bestellten Produkts an den Kunden
❌
Die Kundenkommunikation während einer Bestellung
❌
Der direkte Verkaufsabschluss mit dem Kunden
Interne Mitarbeiterschulung liefert keinen direkten Wert an externe Kunden, ermöglicht aber Hauptwertströme.
Wertstromdarstellung [Wertströme]
5
✅
Die Abfolge der Schritte mit Zeit-/Ressourcen-/Übergabepunkten, um Engpässe zu erkennen
❌
Ausschließlich Finanzkennzahlen
❌
Nur die Organisationsstruktur
❌
Die Vertragslaufzeiten mit Lieferanten
Die Abfolge der Schritte inkl. Zeit-, Ressourcen- oder Übergabepunkte, um Engpässe erkennbar zu machen.
❌
Ausschließlich neue Service Levels vereinbaren
❌
Nur ein Organigramm aktualisieren
❌
Nur die Prozessdokumentation unverändert veröffentlichen
✅
Wertstromdarstellung nutzen, um den tatsächlichen Fluss von Arbeit, Informationen und Wert zu analysieren
Richtig ist D: Wertstromdarstellung analysiert tatsächliche Wertströme, nicht nur Workflows wie designt. Zu den anderen Optionen: A – Ausschließlich neue Service Levels vereinbaren ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Nur ein Organigramm aktualisieren beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Nur die Prozessdokumentation unverändert veröffentlichen liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Wenn die Theorie (Prozess) von der Realität abweicht, musst du den
Weg des Wassers (Wertstrom) verfolgen: Nur die
Wertstromdarstellung macht die echten Blockaden, Wartezeiten und den tatsächlichen Fluss von Arbeit sichtbar.
SLA-Anpassung: Kosmetik an den Zielvorgaben löst keine operativen Engpässe oder Wartezeiten im realen Ablauf.
Organigramm-Update: Ändert nur Zuständigkeiten auf dem Papier, behebt aber nicht den fehlerhaften Informationsfluss zwischen den Teams.
- Prozessdokumentation veröffentlichen: Ignoriert die Realität und zwingt die Mitarbeiter in ein theoretisches Korsett, das in der Praxis bereits scheitert.
❌
Nur ein Organigramm aktualisieren
❌
Nur die Prozessdokumentation unverändert veröffentlichen
✅
Wertstromdarstellung nutzen, um den tatsächlichen Fluss von Arbeit, Informationen und Wert zu analysieren
❌
Ausschließlich neue Service Levels vereinbaren
Richtig ist C: Wertstromdarstellung analysiert tatsächliche Wertströme, nicht nur Workflows wie designt. Zu den anderen Optionen: A – Nur ein Organigramm aktualisieren beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Nur die Prozessdokumentation unverändert veröffentlichen liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Ausschließlich neue Service Levels vereinbaren ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Nur die Prozessdokumentation unverändert veröffentlichen
✅
Wertstromdarstellung nutzen, um den tatsächlichen Fluss von Arbeit, Informationen und Wert zu analysieren
❌
Ausschließlich neue Service Levels vereinbaren
❌
Nur ein Organigramm aktualisieren
Richtig ist B: Wertstromdarstellung analysiert tatsächliche Wertströme, nicht nur Workflows wie designt. Zu den anderen Optionen: A – Nur die Prozessdokumentation unverändert veröffentlichen liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Ausschließlich neue Service Levels vereinbaren ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Nur ein Organigramm aktualisieren beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Wertstromdarstellung nutzen, um den tatsächlichen Fluss von Arbeit, Informationen und Wert zu analysieren
❌
Ausschließlich neue Service Levels vereinbaren
❌
Nur ein Organigramm aktualisieren
❌
Nur die Prozessdokumentation unverändert veröffentlichen
Richtig ist A: Wertstromdarstellung analysiert tatsächliche Wertströme, nicht nur Workflows wie designt. Zu den anderen Optionen: B – Ausschließlich neue Service Levels vereinbaren ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Nur ein Organigramm aktualisieren beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Nur die Prozessdokumentation unverändert veröffentlichen liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Wertströme und Lebenszyklus [Wertströme]
1
✅
Ein Wertstrom kombiniert typischerweise mehrere Lebenszyklusstufen zu einem konkreten Ablauf
❌
Wertströme und Lebenszyklusstufen haben nichts miteinander zu tun
❌
Ein Wertstrom ist immer identisch mit genau einer einzelnen Stufe
❌
Wertströme ersetzen den Lebenszyklus vollständig
Ein Wertstrom kombiniert typischerweise mehrere Lebenszyklusstufen zu einem konkreten Ende-zu-Ende-Ablauf.
Merksatz:
Ein
Wertstrom ist wie eine
Kette, die sich die besten
Perlen (Lebenszyklusstufen) herauspickt und sie flexibel zu einem glänzenden Ablauf verbindet – er starrt nicht auf eine einzelne Perle, sondern schafft den Gesamtwert.
Haben nichts miteinander zu tun: Falsch, da Wertströme die theoretischen Lebenszyklusstufen in der Praxis erst lebendig machen und miteinander verknüpfen.
Identisch mit genau einer Stufe: Falsch, da ein Wertstrom fast immer mehrere Phasen (von der Idee bis zum Betrieb) durchläuft, um echten Nutzen zu stiften.
- Ersetzen den Lebenszyklus vollständig: Falsch, da der Lebenszyklus das strukturierende Rahmenwerk bleibt, während der Wertstrom den konkreten, dynamischen Weg darin beschreibt.
Eigenen Wertstrom skizzieren [Wertströme]
1
Haupt- vs. unterstützend im eigenen Kontext [Wertströme]
1
Merksatz:
Der Hauptwertstrom ist die Autobahn direkt zum Kunden (erzeugt den unmittelbaren Kundennutzen, z. B. „Software-Feature entwickeln“), während der unterstützende Wertstrom die Tankstelle im Hintergrund ist (hält den Betrieb am Laufen, z. B. „Mitarbeiter-Onboarding“ oder „Server-Wartung“).
Hauptwertstrom: Direkt wertschöpfend für den externen Kunden (Beispiel: Entwicklung einer neuen Banking-App). Begründung: Erzeugt direkt Umsatz und Kundennutzen.
Unterstützender Wertstrom: Notwendig, aber ohne direkten Kundenkontakt (Beispiel: Bereitstellung von Entwickler-Laptops durch die interne IT). Begründung: Sichert die Arbeitsfähigkeit des Hauptwertstroms, ohne dass der Endkunde es direkt sieht.
Wertstrommanagement vs. -darstellung [Wertströme]
1
✅
Wertstromdarstellung identifiziert den Wertfluss, Wertstrommanagement sichert die Performance über die Zeit
❌
Wertstromdarstellung dient nur dem Reporting, Wertstrommanagement nur dem Auditing
❌
Wertstromdarstellung gilt nur für Services, Wertstrommanagement nur für Produkte
❌
Wertstromdarstellung fokussiert Kosten, Wertstrommanagement fokussiert Risikovermeidung
Wertstromdarstellung zeigt, WIE der Wert fließt (Visualisierung); Wertstrommanagement stellt sicher, dass der Wertstrom über die Zeit effektiv performt (Steuerung).
Übung [Wertströme]
12
✅
Mapping zeigt, wie Wert fließt; Management sorgt dafür, dass der Wertstrom dauerhaft wirksam bleibt
❌
Mapping dient nur der Berichterstattung, Management nur der Prüfung
❌
Mapping gilt für Services, Management für Produkte
❌
Mapping fokussiert Kostenkontrolle, Management Risikovermeidung
Mapping macht den Wertfluss sichtbar; Management stellt die dauerhafte Wirksamkeit sicher.
✅
Er unterstützt den effektiven Betrieb der Hauptwertströme
❌
Er ersetzt die Hauptwertströme
❌
Er definiert Kundenergebnisse und Serviceerwartungen
❌
Er bildet die primäre Schnittstelle zu den Konsumenten
Enabling Value Streams unterstützen die Kern-Wertströme, treten aber nicht selbst direkt zum Kunden auf.
❌
Identifikation des Wertstroms
❌
Abbildung des Ist-Zustands ('as-is')
❌
Abbildung des Soll-Zustands ('to-be')
✅
Wertstrommanagement
Wertstrommanagement ist kein Mapping-Schritt; die drei Schritte sind Identifikation, Ist- und Soll-Abbildung.
Merksatz:
Ein
Maler zeichnet ein Bild (Abbildung/Mapping), aber er
leitet nicht die gesamte Galerie (Management). Das
Management ist der dauerhafte, übergeordnete Prozess und kein einzelner Schritt beim Zeichnen der Karte.
Warum die anderen falsch sind:
Identifikation des Wertstroms: Ist falsch, weil man zuerst wissen muss, welchen Weg man überhaupt zeichnet.
Abbildung des Ist-Zustands ('as-is'): Ist falsch, weil das Erfassen der aktuellen Realität der logische Startpunkt jeder Kartierung ist.
- Abbildung des Soll-Zustands ('to-be'): Ist falsch, weil das Zeichnen des zukünftigen Idealzustands das Ziel des Mappings darstellt.
✅
Er schafft direkt Wert für die Konsumenten
❌
Er unterstützt nur andere Wertströme
❌
Er dient ausschließlich der Berichterstattung
❌
Er ersetzt die Management-Practices
Ein Kern-Wertstrom schafft direkt Konsumentenwert; unterstützende (enabling) Wertströme stützen ihn.
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Reihe von Schritten zur Entwicklung und Bereitstellung von Produkten und Services für einen Servicekonsumenten
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Wertstrom“ wird in den Quellen inhaltlich als „Eine Reihe von Schritten zur Entwicklung und Bereitstellung von Produkten und Services für einen Servicekonsumenten“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Der Wertstrom ist der konkrete Schritt-für-Schritt-Weg (wie ein Fließband), auf dem ein Produkt oder Service direkt zum Konsumenten wandert – von der ersten Idee bis zur Auslieferung.
Warum die anderen falsch sind:
Nachfrage in Wert umgewandelt: Beschreibt das übergeordnete Konzept der Service-Wertschöpfungskette (SVS), nicht den spezifischen Strom.
Ressourcen und Fähigkeiten: Definiert den Begriff der "Organisation" oder "Kompetenz", nicht den Ablauf eines Wertstroms.
System zur Leitung und Steuerung:* Beschreibt das "Governance"-Modell (Führungssystem) der Organisation.
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein Wertstrom, der die Bereitstellung von Wert für Konsumenten in der vom Betriebsmodell vorgesehenen Form ermöglicht
„Hauptwertstrom“ wird in den Quellen inhaltlich als „Ein Wertstrom, der die Bereitstellung von Wert für Konsumenten in der vom Betriebsmodell vorgesehenen Form ermöglicht“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Der
Hauptwertstrom ist die „Autobahn des Betriebsmodells“ – er liefert den Wert genau so an den Kunden aus, wie es der Bauplan des Unternehmens (das Betriebsmodell) vorschreibt.
Warum die anderen falsch sind:
Leitung, Steuerung und Überwachung: Dies beschreibt das Governance-System, nicht einen Wertstrom.
Abfolge von Aktivitäten: Das ist die allgemeine Definition eines Standard-Wertstroms, greift aber für den
Hauptwertstrom im Betriebsmodell zu kurz.
- Ressourcen und Fähigkeiten: Dies definiert Ressourcen und Kompetenzen (Assets), nicht den dynamischen Ablauf eines Wertstroms.
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein Wertstrom, der Wert für interne Kunden schafft, um die Hauptwertströme der Organisation zu unterstützen
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„unterstützender Wertstrom“ wird in den Quellen inhaltlich als „Ein Wertstrom, der Wert für interne Kunden schafft, um die Hauptwertströme der Organisation zu unterstützen“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Ein unterstützender Wertstrom ist wie die Boxencrew beim Formel-1-Rennen: Sie arbeitet im Hintergrund für das interne Team (den Fahrer), damit dieser auf der Hauptstrecke den Sieg (den echten Kundenwert) einfahren kann.
Warum die anderen falsch sind:
Abfolge von Aktivitäten...: Beschreibt die allgemeine Definition eines Wertstroms (Service Value Stream), nicht die spezifisch unterstützende Variante.
Reihe organisatorischer Ressourcen...: Das definiert „Fähigkeiten“ (Capabilities) oder „Ressourcen“, ist aber kein dynamischer Wertstrom.
System zur Leitung, Steuerung...:* Dies beschreibt das Governance-System der Organisation, nicht einen operativen Wertstrom.
✅
Eine Technik zur visuellen Darstellung und Analyse von Wertströmen
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„Wertstromdarstellung“ wird in den Quellen inhaltlich als „Eine Technik zur visuellen Darstellung und Analyse von Wertströmen“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Die Wertstromdarstellung ist wie eine Landkarte (visuelle Darstellung) und ein Navi (Analyse) – sie zeigt dir das Bild des Weges, nicht den Weg selbst.
Warum die anderen falsch sind:
System zur Leitung...: Das beschreibt die Governance (Führungsebene), nicht eine visuelle Analysemethode.
Abfolge von Aktivitäten...: Das ist die Definition des Wertstroms selbst, nicht seiner grafischen Darstellung.
Reihe organisatorischer Ressourcen...: Dies definiert Fähigkeiten (Capabilities) oder Organisationen*, nicht das Werkzeug zur Prozessvisualisierung.
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Managementaktivität zur Steuerung, Analyse und Verbesserung von Wertströmen
„Wertstrommanagement“ wird in den Quellen inhaltlich als „Eine Managementaktivität zur Steuerung, Analyse und Verbesserung von Wertströmen“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Weil nur Governance Wert schafft
✅
Weil tatsächliche Flüsse kontextspezifisch sind und fortlaufend dargestellt, analysiert und optimiert werden sollten
❌
Weil Wertströme keine Informationen enthalten
❌
Weil Prozesse immer exakt ausgeführt werden
Tatsächliche Flüsse sind kontextspezifisch und müssen fortlaufend analysiert werden.
❌
Ein unterstützender Wertstrom ist ein SLA
❌
Ein Hauptwertstrom ist ein Known Error
✅
Ein Hauptwertstrom ermöglicht Wert für Konsumenten; ein unterstützender Wertstrom schafft Wert für interne Kunden zur Unterstützung der Hauptwertströme
❌
Beide sind PESTLE-Faktoren
Hauptwertstrom und unterstützender Wertstrom haben unterschiedliche Zielgruppen.
❌
Nur politische Faktoren
✅
Fluss von Informationen, Arbeit und Wert für einen Servicekonsumenten
❌
Nur Warentransfer
❌
Nur Budgetgenehmigungen
Wertstromdarstellung fokussiert Informations-, Arbeits- und Wertfluss.
Merksatz:
Ein digitaler Wertstrom ist wie ein
moderner Fluss: Er transportiert keine schweren Kisten, sondern lässt
Informationen, Arbeit und Wert blitzschnell direkt zum Kunden fließen.
Warum die anderen falsch sind:
Nur politische Faktoren: Dies vernachlässigt die tatsächliche operative Arbeit und die Technologie komplett.
Nur Warentransfer: Dies ist ein veraltetes, rein physisches Logistik-Denken und ignoriert die immateriellen digitalen Werte.
- Nur Budgetgenehmigungen: Dies reduziert den gesamten Wertstrom fälschlicherweise auf einen einzigen, rein administrativen Teilschritt.
Hauptwertstrom und unterstützender Wertstrom [Wertströme]
4
✅
Der Buchungsfluss ist eher Hauptwertstrom; das Lieferanten-Onboarding eher unterstützender Wertstrom
❌
Beide sind nur Prozesse, keine Wertströme
❌
Das Lieferanten-Onboarding ist immer der primäre Konsumentenwertstrom
❌
Beide sind immer Hauptwertströme
Richtig ist A: Hauptwertströme liefern Wert für Konsumenten; unterstützende Wertströme schaffen Wert für interne Kunden zur Unterstützung. Zu den anderen Optionen: B – Beide sind nur Prozesse, keine Wertströme ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Das Lieferanten-Onboarding ist immer der primäre Konsumentenwertstrom beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Beide sind immer Hauptwertströme liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Beide sind nur Prozesse, keine Wertströme
❌
Das Lieferanten-Onboarding ist immer der primäre Konsumentenwertstrom
❌
Beide sind immer Hauptwertströme
✅
Der Buchungsfluss ist eher Hauptwertstrom; das Lieferanten-Onboarding eher unterstützender Wertstrom
Richtig ist D: Hauptwertströme liefern Wert für Konsumenten; unterstützende Wertströme schaffen Wert für interne Kunden zur Unterstützung. Zu den anderen Optionen: A – Beide sind nur Prozesse, keine Wertströme ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Das Lieferanten-Onboarding ist immer der primäre Konsumentenwertstrom beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Beide sind immer Hauptwertströme liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Das Lieferanten-Onboarding ist immer der primäre Konsumentenwertstrom
❌
Beide sind immer Hauptwertströme
✅
Der Buchungsfluss ist eher Hauptwertstrom; das Lieferanten-Onboarding eher unterstützender Wertstrom
❌
Beide sind nur Prozesse, keine Wertströme
Richtig ist C: Hauptwertströme liefern Wert für Konsumenten; unterstützende Wertströme schaffen Wert für interne Kunden zur Unterstützung. Zu den anderen Optionen: A – Das Lieferanten-Onboarding ist immer der primäre Konsumentenwertstrom beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Beide sind immer Hauptwertströme liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Beide sind nur Prozesse, keine Wertströme ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Merksatz:
Der Bürger bucht direkt das Auto – das ist die Hauptstraße (Hauptwertstrom) für den Kunden. Der neue Bezahldienst im Hintergrund ist wie der Straßenbau – er unterstützt nur, damit die Fahrt reibungslos läuft (unterstützender Wertstrom).
Lieferanten-Onboarding als primärer Strom: Falsch, da der Endkunde (Bürger) vom Onboarding des Dienstleisters keinen direkten, sofortigen Nutzen spürt.
Beide sind immer Hauptwertströme: Falsch, da das Onboarding nur internen Zwecken dient und nicht direkt den primären Service für den Endnutzer erbringt.
- Beide sind nur Prozesse: Falsch, da beide Aktivitäten einen vollständigen Wertschöpfungsfluss (End-to-End) von der Nachfrage bis zur Wertrealisierung darstellen, was sie zu echten Wertströmen macht.
❌
Beide sind immer Hauptwertströme
✅
Der Buchungsfluss ist eher Hauptwertstrom; das Lieferanten-Onboarding eher unterstützender Wertstrom
❌
Beide sind nur Prozesse, keine Wertströme
❌
Das Lieferanten-Onboarding ist immer der primäre Konsumentenwertstrom
Richtig ist B: Hauptwertströme liefern Wert für Konsumenten; unterstützende Wertströme schaffen Wert für interne Kunden zur Unterstützung. Zu den anderen Optionen: A – Beide sind immer Hauptwertströme liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Beide sind nur Prozesse, keine Wertströme ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Das Lieferanten-Onboarding ist immer der primäre Konsumentenwertstrom beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
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.
Merksatz:
Warranty ist das Wie: Es sichert zu, dass der Service im Alltag funktioniert (fit for use – wie ein maßgeschneiderter Schuh, der perfekt passt, weil Verfügbarkeit, Kapazität und Sicherheit stimmen).
Grundsätzliche Funktionalität: Das ist Utility (Nutzen/„fit for purpose“ – was der Service tut, nicht wie er es sichert).
Gesetzliche Garantiezeit: Ein juristischer Begriff, der nichts mit dem ITIL-Wertversprechen im Betrieb zu tun hat.
Kundenerwartung an den Preis:* Beschreibt die finanzielle Wahrnehmung (Value/Kosten), nicht die Service-Garantie.
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]
5
✅
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.
❌
Services vermeiden jede Form von Risiko vollständig
❌
Services bestehen nur aus dokumentierten Service Levels
❌
Services übertragen immer Eigentum an allen Ressourcen
✅
Services erleichtern gewünschte Ergebnisse, ohne dass der Kunde bestimmte Kosten und Risiken managen muss
Richtig ist D: Servicekonsum bedeutet nicht Risikofreiheit, sondern dass bestimmte Kosten und Risiken vom Kunden nicht selbst gemanagt werden müssen. Zu den anderen Optionen: A – Services vermeiden jede Form von Risiko vollständig ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Services bestehen nur aus dokumentierten Service Levels beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Services übertragen immer Eigentum an allen Ressourcen liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Services bestehen nur aus dokumentierten Service Levels
❌
Services übertragen immer Eigentum an allen Ressourcen
✅
Services erleichtern gewünschte Ergebnisse, ohne dass der Kunde bestimmte Kosten und Risiken managen muss
❌
Services vermeiden jede Form von Risiko vollständig
Richtig ist C: Servicekonsum bedeutet nicht Risikofreiheit, sondern dass bestimmte Kosten und Risiken vom Kunden nicht selbst gemanagt werden müssen. Zu den anderen Optionen: A – Services bestehen nur aus dokumentierten Service Levels beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Services übertragen immer Eigentum an allen Ressourcen liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Services vermeiden jede Form von Risiko vollständig ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Services übertragen immer Eigentum an allen Ressourcen
✅
Services erleichtern gewünschte Ergebnisse, ohne dass der Kunde bestimmte Kosten und Risiken managen muss
❌
Services vermeiden jede Form von Risiko vollständig
❌
Services bestehen nur aus dokumentierten Service Levels
Richtig ist B: Servicekonsum bedeutet nicht Risikofreiheit, sondern dass bestimmte Kosten und Risiken vom Kunden nicht selbst gemanagt werden müssen. Zu den anderen Optionen: A – Services übertragen immer Eigentum an allen Ressourcen liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Services vermeiden jede Form von Risiko vollständig ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Services bestehen nur aus dokumentierten Service Levels beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Services erleichtern gewünschte Ergebnisse, ohne dass der Kunde bestimmte Kosten und Risiken managen muss
❌
Services vermeiden jede Form von Risiko vollständig
❌
Services bestehen nur aus dokumentierten Service Levels
❌
Services übertragen immer Eigentum an allen Ressourcen
Richtig ist A: Servicekonsum bedeutet nicht Risikofreiheit, sondern dass bestimmte Kosten und Risiken vom Kunden nicht selbst gemanagt werden müssen. Zu den anderen Optionen: B – Services vermeiden jede Form von Risiko vollständig ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Services bestehen nur aus dokumentierten Service Levels beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Services übertragen immer Eigentum an allen Ressourcen liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Ein Service ist wie ein
Rundum-Sorglos-Mietwagen: Du kommst ans Ziel (Ergebnis), ohne dich um teure Werkzeuge, Spezialisten oder das Pannenrisiko (Kosten & Risiken) selbst kümmern zu müssen – der Anbieter nimmt dir diese Last ab.
Warum die anderen falsch sind:
Risiko vollständig vermeiden: Ein Restrisiko bleibt immer bestehen und kann nie zu 100 % eliminiert werden.
Nur aus Service Levels bestehen: SLAs sind nur Dokumente; ein Service lebt von echten Ressourcen, Menschen und Prozessen.
- Immer Eigentum übertragen: Beim Service mietet oder nutzt man Ressourcen meist nur, anstatt sie zu kaufen und zu besitzen.
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).
Merksatz:
Der Sponsor zahlt die Zeche, die Kundschaft definiert die Wünsche und die Anwender:innen nutzen das System – zusammen bilden sie das Konsumenten-Trio, das den Service „konsumiert“.
Warum die anderen falsch sind:
Provider, Lieferant, Partner: Das sind die Erbringer (Wertschöpfungspartner) des Services, nicht die Konsumenten.
Administrator, Entwickler:in, Tester:in: Dies sind interne IT-Rollen der Service-Erstellung und des Betriebs, keine Konsum-Rollen.
Vorstand, Abteilungsleitung, Sachbearbeitung: Das sind allgemeine Hierarchiestufen* eines Unternehmens, keine spezifischen ITIL-Konsumentenrollen.
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.
Merksatz: Ein Service Provider ist wie ein Koch, der Gerichte (Services) zubereitet, die dem Gast (Konsumenten) schmecken und ihn satt machen (Wert ermöglichen).
Warum die anderen falsch sind:
Ausschließlich Hardware verkaufen: Ignoriert den Fokus auf den Servicegedanken und die Wertschöpfung.
Nur interne Audits durchführen: Beschreibt eine interne Kontrollfunktion, nicht die Kernleistungserbringung.
- Verträge zwischen zwei Kunden vermitteln: Dies ist eine Maklerfunktion, nicht die direkte Servicebereitstellung.
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.
Merksatz: Die Konsumenten-WG: Der
Kunde ist der Architekt der Wünsche, der
Anwender der tägliche Bewohner und der
Sponsor der Vermieter, der die Miete zahlt.
Warum die anderen falsch sind:
- Alle drei Rollen müssen zwingend von unterschiedlichen Personen wahrgenommen werden: Typischerweise können Rollen überlappen oder von derselben Person ausgeführt werden, ITIL legt hier keine strikte Trennung fest.
Utility und Warranty kombiniert [Begriffe]
1
Merksatz:
Utility ist das WAS (die Funktion), Warranty ist das WIE (die Qualität).
Stell dir ein Auto vor:
Utility (Fit for Purpose): Das Auto hat Sitze und einen Motor – es kann dich theoretisch transportieren.
Warranty (Fit for Use): Das Auto ist fahrbereit, sicher und springt zuverlässig an.
Ein Auto ohne Motor (keine Utility) ist nutzlos. Ein Rennwagen ohne Bremsen und Reifen (keine Warranty) ist lebensgefährlich und unbrauchbar.
Erst wenn beide zusammenkommen, entsteht echter Wert (Value). Utility liefert die Leistung, Warranty sichert das Versprechen.
Wert als Ko-Kreation [Begriffe]
1
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.
Merksatz:
Der
Output ist das greifbare
Produkt (wie der fertiggedruckte
Bericht auf dem Tisch), während der
Outcome die
Wirkung ist (was man damit erreicht).
Warum die anderen falsch sind:
- Bessere Geschäftsentscheidung: Das ist die Wirkung (Outcome) des Berichts, nicht das Produkt selbst.
- Langfristige Kundenzufriedenheit: Dies ist ein strategisches Resultat (Outcome) aus vielen guten Entscheidungen.
- Gestiegener Marktanteil: Das stellt das übergeordnete Geschäftsergebnis (Outcome) dar, kein direktes Arbeitsergebnis.
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).
Merksatz: "Jeder Topf hat seinen Deckel – und seine Kosten." Sowohl der Service-Provider (Topf) als auch der Service-Konsument (Deckel) tragen jeweils ihre eigenen spezifischen Kosten, um die Servicebeziehung aufrechtzuerhalten und zu nutzen.
Warum die anderen falsch sind:
Nur Provider Kosten: Ignoriert die Investitionen des Konsumenten in Nutzung und Integration.
Nur Konsument Kosten: Verkennt die Aufwände des Providers für Bereitstellung und Betrieb.
- Kosten nur bei physischen Produkten: Falsche Annahme, ITIL berücksichtigt immaterielle Services und deren Kosten umfassend.
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.
Merksatz: Servicequalität ist wie ein maßgeschneiderter Anzug: Er muss perfekt den Wünschen des Trägers (Stakeholder) entsprechen und die vereinbarten Anforderungen erfüllen, damit er als "gut" empfunden wird.
Warum die anderen falsch sind:
Ausschließlich am technischen Aufwand der Bereitstellung: Verwechselt den internen Aufwand mit dem extern wahrgenommenen Wert.
Ausschließlich am Preis des Service: Reduziert Qualität auf Kosten, ignoriert den Nutzen.
- An der Anzahl eingesetzter Mitarbeitender: Quantität der Ressourcen sagt nichts über die Ergebnisqualität aus.
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).
Merksatz: Die "Garantie" (Warranty) eines Services ist wie die Zusage eines Handwerkers: Er garantiert, dass der Service "läuft" – also
verfügbar ist und die vereinbarte Leistung erbringt. Stell dir vor, du kaufst ein Gerät mit Garantie: Es muss funktionstüchtig sein, sprich, verfügbar, wenn du es brauchst.
Warum die anderen falsch sind:
Funktionsumfang: Beschreibt, was
der Service tut (Utility), nicht wie gut
er läuft.
Bedienfreundlichkeit: Betrifft die Nutzungserfahrung (Usability), nicht die Kernzusage der Leistungserbringung.
- Marktpreis: Ist ein Wertaspekt, aber keine Dimension der Serviceleistung oder -garantie selbst.
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)
Merksatz: Warranty ist wie die "3 K + S" für den störungsfreien Betrieb:
Kapazität,
Kontinuität (impliziert Verfügbarkeit),
Konformität (impliziert Sicherheit) – alles für die
Service-Qualität. Stell dir vor, du kaufst ein Auto: Die Warranty garantiert dir, dass es die versprochene Leistung (Kapazität), jederzeit (Verfügbarkeit) und sicher (Sicherheit) erbringt.
Warum die anderen falsch sind:
- Grundfunktionalität (Utility): Beschreibt, WAS der Service tut, nicht WIE gut er funktioniert.
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
Merksatz:
Stell dir den „Bäcker-Dienst“ vor:
1. Rollen: Der Bäcker ist der Provider, du bist der hungrige Konsument.
2. Bereitstellung: Der Bäcker backt frische Brötchen und legt sie in die Auslage.
3. Nutzung: Du kaufst und isst die Brötchen.
4. Beziehungsmanagement: Ihr sprecht miteinander – du gibst Feedback („Die Croissants waren super!“) und der Bäcker passt sein Sortiment an.
Der Kern für die Prüfung:
Eine vollständige Servicebeziehung braucht immer dieses Trio: Anbieten (Bereitstellung), Nutzen (Konsum) und Reden (Management/Feedback).
Utility/Warranty im Alltag [Begriffe]
1
Merksatz:
Utility ist das Was (Nutzen), Warranty ist das Wie (Garantie).
Denk an ein Auto:
Utility (Zweckmäßigkeit): Es bringt dich von A nach B (erfüllt den Zweck/die Funktion).
Warranty (Gewährleistung): Es ist sicher, hat Airbags und springt auch bei -10 Grad zuverlässig an (Verfügbarkeit, Kapazität, Sicherheit, Kontinuität).
Kurz: Utility ist der Motor, Warranty ist der TÜV.
Kosten und Risiko im eigenen Umfeld [Begriffe]
1
Merksatz: Denk an den "Wolken-Wächter": Dein Cloud-Anbieter ist wie ein Bodyguard für deine Daten, der die Gefahren (Kosten und Risiken wie Hardware-Ausfall oder Datenverlust) auf sich nimmt, damit du dich sicher fühlst und dich um wichtigere Dinge kümmern kannst. Du mietest quasi einen sorgenfreien Daten-Parkplatz, statt selbst eine teure und riskante Garage zu bauen und zu warten.
Sichtbarkeitsbereich [Begriffe]
1
✅
Er repräsentiert alle Aspekte, die zwischen Provider- und Konsumentenorganisation sichtbar sind
❌
Er umfasst nur die Aktivitäten, die für den Service Provider sichtbar sind
❌
Er gilt ausschließlich für rein technologiebasierte digitale Services
❌
Er definiert den vollständigen internen Pfad der Servicebereitstellung
Der Sichtbarkeitsbereich umfasst alle Aspekte einer Serviceinteraktion, die sowohl für die Provider- als auch für die Konsumentenorganisation sichtbar sind - nicht nur die interne Sicht des Providers.
Merksatz:
Der
Sichtbarkeitsbereich ist wie ein großes, gemeinsames Schaufenster: Beide Seiten – Provider und Konsument – können hineinsehen und alles erkennen, was dort gemeinsam geschieht.
Nur für Provider sichtbar: Falsch, da der Bereich zwingend die Schnittstelle und Interaktion zwischen beiden
Parteien umfasst, nicht nur eine Seite.
Nur für technologiebasierte Services: Falsch, da dieses Konzept für
alle Arten von Services gilt, egal ob digital, physisch oder menschlich.
- Vollständiger interner Pfad: Falsch, da interne Prozesse hinter den Kulissen (Backstage) für den Konsumenten unsichtbar bleiben und somit außerhalb dieser Grenze liegen.
Digitaler Service [Begriffe]
1
✅
Ein Service, der vollständig oder weitgehend auf digitalen Produkten basiert
❌
Jede Kombination aus Technologieressourcen unabhängig vom Kundennutzen
❌
Der reine Warentransfer vom Provider zum Konsumenten
❌
Ein bloßer Katalog verfügbarer Services für Konsumenten
Ein digitaler Service ist ein Service, der vollständig oder weitgehend auf digitalen Produkten basiert.
Servicebeziehungstypen [Begriffe]
1
✅
Einfache Beziehung
❌
Auf Kooperation basierende Beziehung
❌
Auf Zusammenarbeit basierende Beziehung
❌
Partnerbeziehung
Die einfache Beziehung (Basic Relationship) fokussiert auf standardisierte, effiziente Services mit geringem Abstimmungsaufwand.
Merksatz: "Einfach" wie ein Stecker, der perfekt in die Buchse passt: standardisiert, zuverlässig, effizient. So ist die "Einfache Beziehung" – unkompliziert, auf Support und Effizienz ausgelegt.
Warum die anderen falsch sind:
Auf Kooperation basierende Beziehung: Fokus auf gemeinsame Ziele, nicht primär auf Standard-Support.
Auf Zusammenarbeit basierende Beziehung: Tiefere Integration, gemeinsame Entwicklung, komplexer als standardisierter Support.
- Partnerbeziehung: Langfristige, strategische Bindung, oft mit geteiltem Risiko und Gewinn.
Service Journey [Begriffe]
5
✅
End-to-End-Interaktionen zwischen Service Provider und Servicekonsument
❌
Ausschließlich die internen Workflows und Prozesse des Service Providers
❌
Den End-to-End-Lebenszyklus eines Produkts
❌
Die reine Abfolge der Aktivitäten des Produkt- und Servicelebenszyklus
Die Service Journey beschreibt die End-to-End-Interaktionen zwischen Service Provider und Servicekonsument über die gesamte Nutzungserfahrung hinweg.
❌
Wertstromdarstellung
✅
Service Journey
❌
Service Configuration Management
❌
Continuous Integration
Richtig ist B: Die Service Journey betrachtet die Beziehung und Interaktionen zwischen Provider und Konsument über den Verlauf hinweg. Zu den anderen Optionen: A – Wertstromdarstellung liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Service Configuration Management ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Continuous Integration beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Die
Service Journey ist die gesamte „Reise“ des Kunden – vom ersten Funken Interesse (Bedarf) über die Nutzung bis zum Abschied, genau wie eine lückenlose Urlaubsreise von der Buchung bis zur Heimkehr.
Warum die anderen falsch sind:
Wertstromdarstellung: Fokussiert sich primär auf den internen Fluss von Aktivitäten zur Wertschöpfung, nicht auf die lückenlose Kundenerfahrung über alle Touchpoints hinweg.
Service Configuration Management: Verwaltet lediglich logische Beziehungen von IT-Komponenten (CIs) und keine Kundeninteraktionen.
- Continuous Integration: Ist ein technischer Softwareentwicklungs-Prozess und kein ganzheitliches Service-Konzept für die Kundenbeziehung.
✅
Service Journey
❌
Service Configuration Management
❌
Continuous Integration
❌
Wertstromdarstellung
Richtig ist A: Die Service Journey betrachtet die Beziehung und Interaktionen zwischen Provider und Konsument über den Verlauf hinweg. Zu den anderen Optionen: B – Service Configuration Management ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Continuous Integration beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Wertstromdarstellung liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Die
Service Journey ist die gesamte „Reise“ des Kunden vom ersten Kennenlernen (Bedarf) über die Nutzung bis zum Abschied – wie die lückenlose Begleitung eines Patienten von der Aufnahme im Krankenhaus bis zur Nachsorge.
Warum die anderen falsch sind:
Service Configuration Management verwaltet nur die technischen Komponenten (CIs) und deren Beziehungen im Hintergrund, nicht das Kundenerlebnis.
Continuous Integration ist ein rein technischer Begriff aus der Softwareentwicklung für das regelmäßige Zusammenführen von Code.
- Wertstromdarstellung (Value Stream Mapping) optimiert interne Arbeitsschritte zur Wertschöpfung, statt die Interaktionen aus der direkten Kundenperspektive abzubilden.
❌
Service Configuration Management
❌
Continuous Integration
❌
Wertstromdarstellung
✅
Service Journey
Richtig ist D: Die Service Journey betrachtet die Beziehung und Interaktionen zwischen Provider und Konsument über den Verlauf hinweg. Zu den anderen Optionen: A – Service Configuration Management ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Continuous Integration beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Wertstromdarstellung liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Die
Service Journey ist die gesamte „Reise“ des Kunden – vom ersten Kennenlernen (Bedarf) über die Nutzung bis zum Abschied, genau wie eine Urlaubsreise alle Stationen von der Buchung bis zur Heimkehr umfasst.
Warum die anderen falsch sind:
Service Configuration Management: Verwaltet nur die technischen Beziehungen von CIs (Hardware/Software), nicht die emotionale und prozessuale Kundenreise.
Continuous Integration: Ist eine rein technische Softwareentwicklungsmethode zur Code-Zusammenführung und kein kundenorientiertes Service-Konzept.
- Wertstromdarstellung (Value Stream Mapping): Fokussiert intern auf die Effizienz von Arbeitsschritten zur Wertschöpfung, statt auf die ganzheitliche Erfahrung und alle Interaktionspunkte des Kunden.
❌
Continuous Integration
❌
Wertstromdarstellung
✅
Service Journey
❌
Service Configuration Management
Richtig ist C: Die Service Journey betrachtet die Beziehung und Interaktionen zwischen Provider und Konsument über den Verlauf hinweg. Zu den anderen Optionen: A – Continuous Integration beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Wertstromdarstellung liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Service Configuration Management ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Merksatz:
Die
Service Journey ist die
Reise des Kunden: Sie beginnt beim ersten Kennenlernen (Bedarf) und geht über die gemeinsame Fahrt (Onboarding, Nutzung) bis zur Bewertung der Reise (Review) – ein ganzer Lebensweg statt nur ein kurzes Ticket.
Warum die anderen falsch sind:
Continuous Integration ist ein rein technischer Software-Entwicklungsbegriff und kein ganzheitliches Kundeninteraktions-Konzept.
Wertstromdarstellung (Value Stream Mapping) optimiert interne Prozessschritte und Flüsse, bildet aber nicht die direkte, emotionale Customer Experience ab.
- Service Configuration Management verwaltet nur die technischen Daten (CIs) und Beziehungen der IT-Infrastruktur, nicht die Kundenbeziehung.
digitales Produkt [Begriffe]
1
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Kombination der Ressourcen einer Organisation, die auf digitaler Technologie basieren und darauf ausgelegt sind, den Konsumenten Wert zu bieten
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„digitales Produkt“ wird in den Quellen inhaltlich als „Eine Kombination der Ressourcen einer Organisation, die auf digitaler Technologie basieren und darauf ausgelegt sind, den Konsumenten Wert zu bieten“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Anbieter digitaler Produkte [Begriffe]
5
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Organisation, die für die Erstellung und das Continual Improvement digitaler Produkte und zugehöriger Serviceangebote verantwortlich ist
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Anbieter digitaler Produkte“ wird in den Quellen inhaltlich als „Eine Organisation, die für die Erstellung und das Continual Improvement digitaler Produkte und zugehöriger Serviceangebote verantwortlich ist“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Der digitale Bäcker backt das Brot (Erstellung) und verfeinert ständig das Rezept (Continual Improvement), um die besten Brötchen (Produkte & Services) anzubieten.
Warum die anderen falsch sind:
Abfolge von Aktivitäten...: Dies beschreibt die Wertschöpfungskette (Value Chain), nicht die Organisation selbst.
Reihe organisatorischer Ressourcen...: Das definiert allgemein Fähigkeiten (Capabilities) oder Praktiken, greift aber für den spezifischen Anbieter zu kurz.
System zur Leitung, Steuerung...:* Hierbei handelt es sich um die Definition von Governance (Führungssystem), was nichts mit der operativen Rolle eines Produktanbieters zu tun hat.
✅
Anbieter digitaler Produkte
❌
Sponsor
❌
Externer Kunde
❌
Servicekonsument
Richtig ist A: Der Anbieter digitaler Produkte ist für Erstellung und Continual Improvement digitaler Produkte und zugehöriger Serviceangebote verantwortlich. Zu den anderen Optionen: B – Sponsor ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Externer Kunde beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Servicekonsument liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Sponsor
❌
Externer Kunde
❌
Servicekonsument
✅
Anbieter digitaler Produkte
Richtig ist D: Der Anbieter digitaler Produkte ist für Erstellung und Continual Improvement digitaler Produkte und zugehöriger Serviceangebote verantwortlich. Zu den anderen Optionen: A – Sponsor ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Externer Kunde beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Servicekonsument liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Der
Anbieter digitaler Produkte ist der „Bäcker“, der das digitale Brötchen (die App) backt, verfeinert und im Laden (Serviceangebot) bereitstellt – er erschafft und pflegt das Produkt selbst.
Warum die anderen falsch sind:
Sponsor: Gibt nur das Geld frei und steuert das Budget, entwickelt aber keine Apps.
Externer Kunde: Definiert die Anforderungen und kauft den Service, statt ihn selbst zu erstellen.
- Servicekonsument: Nutzt die fertige App (wie Patienten oder Ärzte), anstatt sie kontinuierlich zu verbessern und anzubieten.
❌
Externer Kunde
❌
Servicekonsument
✅
Anbieter digitaler Produkte
❌
Sponsor
Richtig ist C: Der Anbieter digitaler Produkte ist für Erstellung und Continual Improvement digitaler Produkte und zugehöriger Serviceangebote verantwortlich. Zu den anderen Optionen: A – Externer Kunde beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Servicekonsument liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Sponsor ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Servicekonsument
✅
Anbieter digitaler Produkte
❌
Sponsor
❌
Externer Kunde
Richtig ist B: Der Anbieter digitaler Produkte ist für Erstellung und Continual Improvement digitaler Produkte und zugehöriger Serviceangebote verantwortlich. Zu den anderen Optionen: A – Servicekonsument liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Sponsor ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Externer Kunde beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Das Produktteam ist der
„Digitale Bäcker“: Sie backen (erstellen) die App, verfeinern das Rezept (kontinuierliche Verbesserung) und bieten die Brötchen (Serviceangebot) an – sie stellen das digitale Produkt bereit.
Warum die anderen falsch sind:
Servicekonsument: Falsch, da das Team die App aktiv bereitstellt und verbessert, statt sie als Endanwender zu nutzen.
Sponsor: Falsch, da das Team die App operativ entwickelt und pflegt, statt das Budget und die finanzielle Freigabe zu liefern.
- Externer Kunde: Falsch, da es sich um ein internes Team handelt, das die Lösung kreiert, und nicht um einen externen Abnehmer, der die Leistung bezahlt.
Serviceaktionen [Begriffe]
1
❌
Materielle Ressourcen mit Eigentumsübertragung
❌
Ein System zur Leitung und Steuerung
❌
Ein visueller Wertstrom
✅
Aktivitäten, die von einem Service Provider durchgeführt werden, um die Bedürfnisse eines Servicekonsumenten zu erfüllen
Serviceaktionen sind Provideraktivitäten zur Erfüllung von Konsumentenbedürfnissen.
Übung [Begriffe]
69
❌
Der monatliche Bericht selbst
✅
Die fundierteren Entscheidungen, die der Kunde dadurch treffen kann
❌
Die Serviceaktion, die den Bericht erzeugt
❌
Die für den Bericht genutzte Datenbank
Ein Outcome ist das Resultat für einen Stakeholder, das durch einen oder mehrere Outputs (hier der Bericht) ermöglicht wird.
❌
Utility (Zweckdienlichkeit)
✅
Warranty (Gewährleistung)
❌
Outcome
❌
Output
Warranty = 'fit for use': Verfügbarkeit, Kapazität, Sicherheit und Kontinuität. Utility wäre 'fit for purpose'.
❌
Allein von den Betriebskosten des Anbieters
✅
Vom Verhältnis der erreichten Ergebnisse zu Kosten und Risiken aus Sicht des Konsumenten
❌
Von der Anzahl der Anbieter am Markt
❌
Von der Höhe der vom Anbieter investierten Mittel
Wert ist eine Wahrnehmung und ergibt sich aus Outcomes im Verhältnis zu Kosten und Risiken.
Merksatz:
„Die Service-Waage des Kunden“ – Der Kunde legt auf die eine Waagschale seine erwünschten
Ergebnisse (Nutzen) und auf die andere seine
Kosten und Risiken. Nur wenn die Waage zugunsten der Ergebnisse ausschlägt, entsteht für ihn echter Wert.
Warum die anderen falsch sind:
Allein von den Betriebskosten: Ignoriert völlig den tatsächlichen Nutzen und die Risiken auf Kundenseite.
Von der Anzahl der Anbieter: Beschreibt die Marktsituation (Konkurrenz), bestimmt aber nicht den individuellen Wert eines konkreten Services.
- Von der Höhe der investierten Mittel: Ein Anbieter kann Millionen verschwenden, ohne dass der Kunde dadurch einen Mehrwert spürt.
❌
Warentransfer
✅
Zugang zu Ressourcen
❌
Serviceaktion
❌
Service Journey
Zugang zu Ressourcen: Nutzung von Anbieter-Ressourcen gemäß vereinbarten Bedingungen.
Merksatz:
Der Cloud-Schlüssel: Wenn der Kunde nur die "Tür aufgeschlossen" bekommt, um den Speicher selbst zu nutzen (ohne dass ihm die Server gehören), hat er
Zugang zu Ressourcen – wie ein Bibliotheksausweis, der Zutritt zu den Büchern gewährt.
Warum die anderen falsch sind:
Warentransfer: Falsch, weil kein physischer Besitz übertragen wird (der Server bleibt beim Anbieter).
Serviceaktion: Falsch, weil der Anbieter nicht aktiv eine Handlung für den Kunden ausführt (wie z. B. ein Backup-Support).
- Service Journey: Falsch, weil dies die gesamte Customer Experience über alle Berührungspunkte hinweg beschreibt, nicht eine einzelne Angebotskomponente.
❌
Zugang zu Ressourcen
✅
Warentransfer
❌
Serviceaktion
❌
Utility
Warentransfer (transfer of goods): Eigentum an einem Gut geht dauerhaft über.
❌
Anwender
✅
Kunde
❌
Sponsor
❌
Lieferant
Der Kunde definiert Anforderungen und verantwortet die Outcomes der Servicenutzung.
Merksatz:
Der
Kunde ist der König, der die Regeln bestimmt (Anforderungen) und am Ende die Zeche zahlt sowie die Verantwortung für den Erfolg trägt – wie ein Bauherr, der das Haus bestellt und bewohnt.
Anwender: Nutzt den Service im Alltag nur operativ (z. B. Software bedienen), entscheidet aber nicht über Anforderungen oder geschäftliche Verantwortung.
Sponsor: Gibt lediglich das Geld frei (Finanzier), definiert aber nicht die fachlichen Anforderungen oder die Nutzungsergebnisse.
- Lieferant: Erbringt die Leistung im Hintergrund, nutzt den Service aber nicht selbst und trägt keine Verantwortung für die Ergebnisse des Kunden.
❌
Kunde
❌
Anwender
✅
Sponsor
❌
Anbieter
Der Sponsor autorisiert das Budget für den Servicekonsum.
❌
Ein Problem ist eine ungeplante Serviceunterbrechung
✅
Ein Problem ist die Ursache eines oder mehrerer Incidents
❌
Ein Problem ist eine vom Anwender ausgelöste Serviceanfrage
❌
Ein Problem ist ein Incident mit besonders hoher Priorität
Ein Problem ist die Ursache (root cause) eines oder mehrerer Incidents; ein Incident ist die ungeplante Unterbrechung selbst.
Merksatz:
Ein Problem ist die Wurzel (Ursache), aus der die Unkraut-Incidents sprießen. Erst wenn du die Wurzel (das Problem) ausgräbst, verhinderst du, dass immer wieder neue Unkraut-Blätter (Incidents) an der Oberfläche auftauchen.
Falsch: Eine ungeplante Serviceunterbrechung ist die Definition eines Incidents selbst, nicht des Problems.
Falsch: Eine vom Anwender ausgelöste Serviceanfrage ist ein Service Request (z. B. Passwort-Reset), kein Problem.
- Falsch: Ein Incident mit besonders hoher Priorität bleibt ein Incident (Major Incident) und wird dadurch nicht automatisch zur Ursachenquelle (Problem).
❌
Ein Incident, dessen Ursache unbekannt ist
✅
Ein Problem, das analysiert wurde, aber (noch) nicht behoben ist
❌
Eine genehmigte Standard-Serviceanfrage
❌
Ein geplanter Change im Betrieb
Ein Known Error ist ein Problem, dessen Ursache verstanden ist, das aber noch nicht dauerhaft behoben wurde.
❌
Ein rechtlicher Vertrag über Vertragsstrafen zwischen zwei Lieferanten
✅
Eine dokumentierte Vereinbarung zwischen Anbieter und Kunde, die Services und ihre vereinbarten Niveaus festlegt
❌
Eine informelle Absprache zwischen Anwendern über Erwartungen
❌
Ein internes Richtliniendokument ohne Kundenbeteiligung
Ein SLA ist eine dokumentierte Vereinbarung zwischen Anbieter und Kunde über Services und deren Zielniveaus.
Merksatz:
Das
SLA ist das
Schriftliche
Leistungs-
Abkommen: Ein offizieller Vertrag zwischen
Anbieter und Kunde, der genau festlegt, welche Service-Qualität geliefert werden muss.
Warum die anderen falsch sind:
Rechtlicher Vertrag zwischen Lieferanten: Ein SLA verbindet Anbieter und Kunden, nicht zwei externe Lieferanten untereinander.
Informelle Absprache: Ein SLA ist niemals informell oder unverbindlich, sondern eine formelle, dokumentierte Vereinbarung.
- Internes Richtliniendokument: Ohne den Kunden ist es kein SLA, sondern nur eine interne Richtlinie (wie ein OLA).
❌
Die anfängliche Testversion eines Produktdesigns
✅
Die wesentlichen Anforderungen und Merkmale eines Produkts
❌
Die Fähigkeit eines Systems, betriebsbereit zu bleiben
❌
Den Vorgang, Code in ein zentrales Repository zusammenzuführen
Eine Produktspezifikation beschreibt die Anforderungen und Merkmale eines Produkts.
✅
Ein Mittel zur Wertschöpfung, indem Ergebnisse ermöglicht werden, ohne dass der Kunde bestimmte Kosten und Risiken selbst tragen muss
❌
Ein physisches Produkt, das dauerhaft an den Kunden übereignet wird
❌
Eine interne Arbeitsanweisung für IT-Teams
❌
Ein Vertrag über Vertragsstrafen zwischen zwei Anbietern
Ein Service ermöglicht Wert-Co-Creation, indem er gewünschte Outcomes erleichtert, ohne dass der Kunde die spezifischen Kosten und Risiken managen muss.
❌
Eine formale Beschreibung eines Service für Konsumenten
✅
Eine Kombination von Ressourcen auf Basis digitaler Technologie, die Konsumenten Wert bieten soll
❌
Der dauerhafte Transfer von Gütern an den Kunden
❌
Eine vom Anbieter ausgeführte Serviceaktion
Ein digitales Produkt ist eine Kombination von Ressourcen auf Basis digitaler Technologie, die Wert bieten soll.
✅
Er verlässt sich vollständig oder überwiegend auf digitale Produkte
❌
Er ist immer auf interne IT-Systeme beschränkt
❌
Er ist unabhängig von jeglicher Technologie
❌
Er ersetzt die Notwendigkeit von Produkten
Ein digitaler Service beruht ganz oder überwiegend auf digitalen Produkten bzw. Informationstechnologie.
❌
Eine informelle Absprache über Erwartungen
✅
Eine formale Beschreibung eines oder mehrerer Services für eine Zielgruppe
❌
Der Betrieb eines Rechenzentrums
❌
Ein Bericht über die Servicequalität
Ein Serviceangebot beschreibt formal Services für eine Zielgruppe und kann Güter, Ressourcenzugang und Serviceaktionen umfassen.
❌
Ein Output ist das Resultat für den Stakeholder, ein Outcome die erbrachte Leistung
✅
Ein Output ist ein Liefergegenstand einer Aktivität, ein Outcome das dadurch ermöglichte Resultat für den Stakeholder
❌
Beide bezeichnen dasselbe
❌
Ein Outcome ist immer materiell, ein Output immer immateriell
Ein Output ist ein Liefergegenstand; ein Outcome ist das durch Outputs ermöglichte Resultat für einen Stakeholder.
❌
Sponsor
❌
Kunde
✅
Anwender
❌
Leitungsorgan
Der Anwender (User) nutzt den Service; der Kunde definiert Anforderungen, der Sponsor genehmigt das Budget.
Merksatz:
Der
Anwender wendet den Service praktisch
an – so wie ein Autofahrer das Auto täglich nutzt, ohne es selbst beim Hersteller bestellt oder konfiguriert zu haben.
Sponsor: Gibt nur das Geld frei (das Budget), nutzt den Service aber oft gar nicht selbst.
Kunde: Definiert die Anforderungen und schließt den Vertrag ab, ist aber nicht zwingend der alltägliche Nutzer.
- Leitungsorgan: Richtet die Organisation strategisch aus und überwacht sie, statt im operativen Alltag Services zu nutzen.
❌
Als Problem
✅
Als Incident
❌
Als Serviceanfrage
❌
Als Change
Eine ungeplante Unterbrechung oder Qualitätsminderung eines Service ist ein Incident.
✅
Jede Zustandsänderung, die für das Management eines Service oder Konfigurationselements bedeutsam ist
❌
Eine ungeplante Serviceunterbrechung
❌
Eine geplante Wartung
❌
Eine Beschwerde eines Kunden
Ein Event ist eine Zustandsänderung, die für das Management eines Service oder CI von Bedeutung ist.
Merksatz:
Ein Event ist der "Zustands-Wächter": Er schlägt immer dann Alarm (oder macht eine Notiz), wenn sich der Zustand von etwas Wichtigem (Service/CI) ändert.
Warum die anderen falsch sind:
Ungeplante Serviceunterbrechung: Das ist ein Incident (Vorfall), der schnellstmöglich behoben werden muss.
Geplante Wartung: Das ist ein Change (Änderung) bzw. ein Standard-Verfahren, kein bloßes Erkennen einer Zustandsänderung.
Beschwerde eines Kunden:* Das ist ein Service Request (Serviceanfrage) oder Beschwerdeprozess, der manuell über den Service Desk eingeht.
❌
Eine ungeplante Unterbrechung eines Service
✅
Eine vordefinierte, vom Anwender ausgelöste Anforderung, die Teil der normalen Servicebereitstellung ist
❌
Die Ursache mehrerer Incidents
❌
Ein sicherheitskritischer Fehler
Eine Serviceanfrage ist eine vordefinierte, normale Anforderung eines Anwenders im Rahmen der Servicebereitstellung.
✅
Basisbeziehung
❌
Kooperative Beziehung
❌
Partnerschaft
❌
Strategische Allianz
Die Basisbeziehung ist transaktional und auf Effizienz durch Standardisierung ausgerichtet.
Merksatz:
Die
Basisbeziehung ist das solide Fundament (die „Basis“) im Keller: Sie läuft unauffällig, vollautomatisch und standardisiert im Hintergrund, um dem Alltag stabilen Halt und maximale Effizienz zu geben.
Kooperative Beziehung: Falsch, weil sie bereits aktive, gemeinsame Abstimmung und Flexibilität erfordert, statt rein standardisierter Abläufe.
Partnerschaft: Falsch, weil hier gemeinsame Wertschöpfung und hohes Risiko-Sharing im Fokus stehen, nicht bloße Standard-Unterstützung.
- Strategische Allianz: Falsch, weil dies eine langfristige, geschäftskritische Verbindung auf Augenhöhe ist, die weit über einfache Effizienzservices hinausgeht.
❌
Utility
❌
Warranty
✅
Nachhaltigkeit
❌
User Experience
Verantwortungsvoller Ressourceneinsatz mit Blick auf ökologische, soziale und ökonomische Langzeitwirkung ist Nachhaltigkeit.
❌
Wie eine Organisation ihre Ressourcen anordnet
✅
Was eine Organisation für ihre Konsumenten und Stakeholder tut und warum
❌
Die finanzielle Strategie einer Organisation
❌
Die Abfolge der Wertschöpfungsketten-Aktivitäten
Der Zweck beschreibt, was die Organisation für Stakeholder tut und warum; das Betriebsmodell zeigt, wie sie das erfüllt.
❌
Es legt fest, warum eine Organisation existiert
✅
Es zeigt, wie eine Organisation ihren Zweck erfüllt
❌
Es ersetzt die Governance
❌
Es definiert ausschließlich die Finanzstrategie
Das Betriebsmodell beschreibt, wie eine Organisation ihren Zweck über Ressourcen und Wertströme erfüllt.
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine Reihe spezialisierter organisatorischer Fähigkeiten zur Ermöglichung von Wert für Kunden in Form digitaler Produkte und Services
„Management digitaler Produkte und Services“ wird in den Quellen inhaltlich als „Eine Reihe spezialisierter organisatorischer Fähigkeiten zur Ermöglichung von Wert für Kunden in Form digitaler Produkte und Services“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Service-Management ist die digitale Wert-Schaufel: Stell dir ITIL als eine Schaufel vor, die aus spezialisierten Fähigkeiten (Ressourcen & Know-how) besteht, um für den Kunden echten Wert in Form von digitalen Produkten zu graben.
Warum die anderen falsch sind:
Leitung, Steuerung und Überwachung: Dies beschreibt die Governance (Führung) einer Organisation, nicht das operative Service-Management.
Abfolge von Aktivitäten: Das ist die Definition der Service-Wertschöpfungskette (Service Value Chain), die nur den Prozessablauf darstellt.
Ressourcen und Fähigkeiten zur Durchführung von Aufgaben: Dies ist zu allgemein und beschreibt lediglich eine Organisation* an sich, ohne den spezifischen Fokus auf den Kundennutzen und digitale Services.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein Service, der vollständig oder weitgehend auf digitalen Produkten basiert
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„digitaler Service“ wird in den Quellen inhaltlich als „Ein Service, der vollständig oder weitgehend auf digitalen Produkten basiert“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine formale Beschreibung eines oder mehrerer Services, die auf die Bedürfnisse einer Zielgruppe zugeschnitten sind
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Serviceangebot“ wird in den Quellen inhaltlich als „Eine formale Beschreibung eines oder mehrerer Services, die auf die Bedürfnisse einer Zielgruppe zugeschnitten sind“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
✅
Der wahrgenommene Nutzen, die Nützlichkeit und Bedeutung von etwas
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
„Wert“ wird in den Quellen inhaltlich als „Der wahrgenommene Nutzen, die Nützlichkeit und Bedeutung von etwas“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Wert liegt im Auge des Betrachters: Stell dir eine glänzende Wert-Münze vor, auf der die drei Buchstaben N-N-B eingraviert sind – Nutzen, Nützlichkeit und Bedeutung. Nur wenn der Kunde diese drei Eigenschaften wahrnimmt, existiert echter Wert.
Warum die anderen falsch sind:
System zur Leitung...: Das beschreibt die Governance (Steuerung), nicht den Wert selbst.
Abfolge von Aktivitäten...: Dies definiert die Service-Wertschöpfungskette (Service Value Chain) als Prozessweg.
Reihe organisatorischer Ressourcen...: Hierbei handelt es sich um die Definition von Service-Management* als organisatorische Fähigkeit.
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein Resultat für einen Stakeholder, das durch einen oder mehrere Outputs ermöglicht wird
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Ergebnis“ wird in den Quellen inhaltlich als „Ein Resultat für einen Stakeholder, das durch einen oder mehrere Outputs ermöglicht wird“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Ein Ergebnis (Outcome) ist das glückliche Gesicht des Kunden, wenn er das Auto tatsächlich fährt (Resultat/Wert) – ermöglicht durch den Schlüssel und das Auto selbst, die nur die physischen Liefergegenstände (Outputs) sind.
Warum die anderen falsch sind:
Abfolge von Aktivitäten... beschreibt die Wertschöpfungskette (Service Value Chain), nicht das Ziel.
Reihe organisatorischer Ressourcen... definiert die Serviceorganisation oder Fähigkeiten, also die Mittel zum Zweck.
System zur Leitung und Steuerung... meint die Governance* (Führung), was nichts mit dem konkreten Nutzen für den Stakeholder zu tun hat.
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Der Geldbetrag, der für eine bestimmte Aktivität, Ressource oder Zielsetzung aufgewendet wird
„Kosten“ wird in den Quellen inhaltlich als „Der Geldbetrag, der für eine bestimmte Aktivität, Ressource oder Zielsetzung aufgewendet wird“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Kosten sind die Kasse: Wo immer Geld für Aktivitäten, Ressourcen oder Ziele abfließt, entstehen Kosten – merk dir das „K“ für Kosten, Kasse und Konkreten Geldbetrag.
Warum die anderen falsch sind:
Option 1 (System zur Leitung...): Beschreibt die Governance (Führung/Steuerung), nicht den finanziellen Aufwand.
Option 2 (Abfolge von Aktivitäten...): Definiert den Wertstrom (Value Stream), der den Weg zum Nutzen beschreibt.
Option 3 (Reihe organisatorischer Ressourcen...): Bezieht sich auf Fähigkeiten/Praktiken* (Practices) zur Leistungserbringung, nicht auf Geld.
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Ein mögliches Event, das zu einem Schaden oder Verlust führen oder das Erreichen von Zielen erschweren könnte
„Risiko“ wird in den Quellen inhaltlich als „Ein mögliches Event, das zu einem Schaden oder Verlust führen oder das Erreichen von Zielen erschweren könnte“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Die Funktionalität, die von einem Produkt oder Service angeboten wird, um einem bestimmten Bedürfnis gerecht zu werden
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Utility“ wird in den Quellen inhaltlich als „Die Funktionalität, die von einem Produkt oder Service angeboten wird, um einem bestimmten Bedürfnis gerecht zu werden“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
Merksatz:
Utility ist die Nützlichkeit (Fit for Purpose) – also das Werkzeug, das genau das TUT, was ich brauche. Stell dir ein Schweizer Taschenmesser vor: Die Klinge (Funktionalität) löst mein konkretes Problem (Bedürfnis), eine Dose zu öffnen.
Warum die anderen falsch sind:
Ressourcen und Fähigkeiten: Das beschreibt das Service Management an sich, nicht den Nutzen des einzelnen Services.
Leitung, Steuerung und Überwachung: Das definiert die Governance (Führung) und nicht die Funktionalität.
Aktivitäten zur Wertumwandlung: Das ist die Definition der Service-Wertschöpfungskette* (Service Value Chain), die den Weg zum Wert beschreibt.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Die Zusicherung, dass ein Produkt oder ein Service die vereinbarten Anforderungen erfüllt
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Warranty“ wird in den Quellen inhaltlich als „Die Zusicherung, dass ein Produkt oder ein Service die vereinbarten Anforderungen erfüllt“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Reihe organisatorischer Ressourcen und Fähigkeiten zur Durchführung von Aufgaben
✅
Eine dokumentierte Vereinbarung über benötigte Services und erwartete Service Levels
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
❌
Eine Abfolge von Aktivitäten, mit der Nachfrage in Wert umgewandelt wird
„Service Level Agreement (SLA)“ wird in den Quellen inhaltlich als „Eine dokumentierte Vereinbarung über benötigte Services und erwartete Service Levels“ beschrieben; die anderen Optionen beschreiben andere ITIL Konzepte.
❌
Eine Ursache oder mögliche Ursache für einen oder mehrere Incidents
✅
Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert zu bieten
❌
Eine dokumentierte Vereinbarung über benötigte Services und erwartete Service Levels
❌
Ein System zur Leitung, Steuerung und Überwachung einer Organisation
„Produkt“ wird als Konfiguration von Ressourcen zur Wertbereitstellung beschrieben.
❌
Eine Technik zur visuellen Darstellung von Wertströmen
❌
Eine Statusänderung, die für das Management eines Services von Bedeutung ist
✅
Eine Möglichkeit, gemeinsame Wertschöpfung zu ermöglichen, indem Ergebnisse erleichtert werden, die Kunden erzielen wollen, ohne dass der Kunde bestimmte Kosten und Risiken managen muss
❌
Eine Version eines Configuration Items
Die Service-Definition verbindet gemeinsame Wertschöpfung, Ergebnisse sowie Kosten und Risiken.
Merksatz:
Ein Service ist wie ein Rundum-sorglos-Taxi: Du bestimmst das Ziel (dein Ergebnis/Wert), aber der Fahrer übernimmt die Kosten für Benzin und das Risiko eines Plattfusses (Kunde managt Kosten und Risiken nicht selbst).
Warum die anderen falsch sind:
Visuelle Darstellung von Wertströmen: Das beschreibt Value Stream Mapping, nicht den Service selbst.
Statusänderung von Bedeutung: Dies ist die offizielle ITIL-Definition für ein Event (Ereignis).
Version eines Configuration Items: Das definiert einen Baseline-Zustand oder ein spezifisches Release*, kein Service-Konzept.
❌
Ein Service, der vollständig oder weitgehend auf digitalen Produkten basiert
❌
Eine Aktivität zur Untersuchung von Problemen
❌
Eine Reihe von Grundprinzipien
✅
Materielle Ressourcen, die von einem Service Provider auf einen Servicekonsumenten zusammen mit Eigentum und damit verbundenen Rechten und Pflichten übertragen werden
Waren werden als materielle Ressourcen mit Eigentumsübertragung beschrieben.
❌
Eine KI-Fähigkeit zur Erstellung neuer Outputs
✅
Die Gewährung des Rechts, Ressourcen unter vereinbarten Bedingungen zu nutzen
❌
Eine Schwachstelle, die Incidents verursachen kann
❌
Eine dokumentierte SLA-Vereinbarung
Zugang zu Ressourcen ist Nutzung unter vereinbarten Bedingungen, nicht Eigentumsübertragung.
❌
Ein Resultat für einen Stakeholder
❌
Eine Servicekonsumentenrolle
❌
Ein Governance-Muster
✅
Ein materielles oder immaterielles Lieferergebnis einer Aktivität
Output ist das Lieferergebnis einer Aktivität.
❌
Ein Request eines Anwenders
❌
Ein Product Backlog
✅
Eine Person oder Gruppe von Personen, die eigene Funktionen mit Verantwortlichkeiten, Befugnissen und Beziehungen hat, um Ziele zu erreichen
❌
Eine Statusänderung eines Configuration Items
Organisation wird über Funktionen, Verantwortlichkeiten, Befugnisse, Beziehungen und Ziele definiert.
❌
Eine Rolle, die Budget genehmigt
❌
Eine Technik zur Wertstromanalyse
✅
Eine Organisation, die Services bereitstellt
❌
Eine Rolle, die Services nutzt
Der Service Provider stellt Services bereit.
Merksatz:
Der PROvider PROduziert und stellt bereit – stell dir einen Pizzabäcker (Organisation) vor, der die Pizza (Service) liefert.
Warum die anderen falsch sind:
Budget genehmigen: Das ist der Sponsor, der das Geld freigibt, nicht der Bereitsteller.
Wertstromanalyse: Dies ist eine Methode (wie Value Stream Mapping), keine Organisation.
Services nutzen: Das ist der Konsument (Consumer) oder Anwender* (User), der die Pizza am Ende isst.
❌
Ein analysiertes, nicht gelöstes Problem
✅
Eine Organisation, die Services nutzt
❌
Eine Organisation, die Governance bereitstellt
❌
Ein Lieferergebnis einer Aktivität
Der Servicekonsument nutzt Services.
❌
Die Rolle, die technische Tests automatisiert
❌
Die Rolle, die alle Releases deployt
✅
Die Rolle, die das Budget für den Servicekonsum genehmigt
❌
Die Rolle, die Services nutzt
Sponsor ist die Budget-genehmigende Rolle.
✅
Die Rolle, die Anforderungen für Services definiert und Verantwortung für Ergebnisse des Servicekonsums übernimmt
❌
Die Rolle, die Services nutzt
❌
Eine Organisation, die Services bereitstellt
❌
Eine Technik zur Analyse von Wertströmen
Der Kunde definiert Anforderungen und übernimmt Verantwortung für Ergebnisse.
Merksatz:
Der Kunde ist der König mit dem Zepter: Er bestimmt, was er will (Anforderungen) und trägt am Ende die Krone der Verantwortung für das Ergebnis.
Die Rolle, die Services nutzt: Das ist der Anwender (User), der das Werkzeug nur benutzt, aber nicht die strategische Verantwortung trägt.
Eine Organisation, die Services bereitstellt: Das ist der Dienstanbieter (Service Provider), also der Lieferant, nicht der Empfänger.
Eine Technik zur Analyse von Wertströmen: Das beschreibt Value Stream Mapping*, eine Methode und keine Personenrolle.
❌
Eine Wertschöpfungskette
✅
Die Rolle, die Services nutzt
❌
Die Rolle, die Budget genehmigt
❌
Eine Management-Practice
Anwender ist die Rolle, die Services nutzt.
❌
Eine einzelne Projektphase
❌
Ein Warentransfer
❌
Ein Service Request
✅
Eine wiederkehrende organisatorische Aktivität, die auf allen Ebenen durchgeführt wird, um sicherzustellen, dass die Performance einer Organisation kontinuierlich die Erwartungen der Stakeholder erfüllt
Continual Improvement ist eine wiederkehrende Aktivität zur Erfüllung von Stakeholder-Erwartungen.
✅
Ein Modell der Aktivitäten des Managements digitaler Produkte und Services über deren Lebenszyklus hinweg
❌
Eine dokumentierte Vereinbarung über Service Levels
❌
Eine Liste externer PESTLE-Faktoren
❌
Eine einzelne Servicekonsumentenrolle
Der Lebenszyklus beschreibt Aktivitäten für digitale Produkte und Services.
Merksatz:
Der
Lebenszyklus ist wie der Lebensweg eines Produkts: Von der Wiege bis zur Bahre steuert das
Modell alle
Aktivitäten des Managements von Anfang bis Ende.
Warum die anderen falsch sind:
Eine vereinbarte Servicequalität ist ein SLA (Service Level Agreement), kein ganzer Lebenszyklus.
PESTLE-Faktoren beschreiben nur das externe Umfeld (politisch, ökonomisch etc.), nicht den internen Produktlebensweg.
- Eine einzelne Rolle (wie der Kunde) ist nur ein kleiner Akteur und kein umfassendes Prozessmodell.
❌
Ein Budgetgenehmiger
❌
Ein Deployment-Verfahren
✅
Die Gesamtheit der Merkmale eines Services, die für seine Fähigkeit relevant sind, festgelegte und vorausgesetzte Bedürfnisse zu erfüllen
❌
Ein Service Request
Servicequalität bezieht sich auf Merkmale eines Services zur Bedürfnis-Erfüllung.
✅
Eine oder mehrere Messgrößen, die erwartete oder erreichte Servicequalität definieren
❌
Ein plötzliches ungeplantes Ereignis
❌
Eine Ursache für Incidents
❌
Ein KI-Fähigkeitsmodell
Service Level definieren erwartete oder erreichte Servicequalität über Messgrößen.
✅
Die Summe der funktionalen und emotionalen Interaktionen mit einem Service und Service Provider, wie sie von einem Serviceanwender wahrgenommen werden
❌
Eine rein technische Verfügbarkeitsmessung
❌
Eine Produktprototypbeschreibung
❌
Eine PESTLE-Kategorie
UX wird als Summe funktionaler und emotionaler Interaktionen beschrieben.
❌
Die Automatisierung jedes Deployments
❌
Eine Ursache für mehrere Incidents
❌
Ein Request eines Anwenders
✅
Die Zusicherung, dass ein Produkt oder Service Anforderungen an ökologische Verantwortung, sozialen Fortschritt und wirtschaftliches Wachstum erfüllt und weiterhin erfüllen wird
Nachhaltigkeit umfasst ökologische, soziale und wirtschaftliche Anforderungen.
❌
Beide Begriffe sind identisch
❌
Ein Output ist immer ein Risiko
❌
Ein Ergebnis ist immer ein SLA
✅
Ein Output ist ein Lieferergebnis einer Aktivität; ein Ergebnis ist ein Resultat für einen Stakeholder, das durch Outputs ermöglicht wird
Die Quellen unterscheiden Lieferergebnis und Stakeholder-Resultat.
Merksatz:
Der
Output ist das gebackene Brot (das gelieferte Produkt), das
Ergebnis (Outcome) ist der gestillte Hunger des Kunden (der tatsächliche Wert für den Stakeholder).
Identisch: Output und Ergebnis sind grundverschieden, da das eine nur die Leistung ist und das andere den realen Nutzen beschreibt.
Immer ein Risiko: Ein Output ist ein konkretes Lieferergebnis und kein inhärentes Risiko, auch wenn seine Erstellung Risiken bergen kann.
- Immer ein SLA: Ein SLA ist lediglich eine formelle Servicevereinbarung, nicht das tatsächliche, für den Stakeholder spürbare Endresultat.
❌
Kosten und Risiken werden ignoriert
❌
Kosten und Risiken sind nur Governance-Begriffe
❌
Risiken werden nur in Releases definiert
✅
Services helfen Kunden, gewünschte Ergebnisse zu erzielen, ohne bestimmte Kosten und Risiken selbst managen zu müssen
Die Service-Definition verbindet Ergebnisse mit Kosten und Risiken.
❌
Es gibt nur Warentransfer
❌
Die Beziehung ist ein KI-System
✅
Service Provider und Servicekonsument arbeiten eng zusammen und teilen Verantwortung für die gemeinsame Wertschöpfung
❌
Der Provider arbeitet ohne Konsumentenkontakt
Die Quelle beschreibt Zusammenarbeit als engere Beziehung beziehungsweise Partnerschaft.
Merksatz:
„Zusammenarbeit ist wie ein Tandem-Rennen“ – Beide Partner (Provider und Konsument) müssen aktiv in die Pedale treten und lenken, um gemeinsam das Ziel (Wertschöpfung) sicher zu erreichen.
Warum die anderen falsch sind:
Nur Warentransfer: Dies beschreibt lediglich eine reine Warenlieferung ohne jegliche Interaktion oder Beziehungsaufbau.
KI-System: Ein technisches Werkzeug ersetzt keine zwischenmenschliche, partnerschaftliche Beziehung.
- Ohne Konsumentenkontakt: Ohne direkten Kontakt ist eine gemeinsame Wertschöpfung (Co-Creation) völlig unmöglich.
❌
Governance, Practice und Wertstrom
❌
Discover, Build und Support
❌
Provider, Lieferant und Event
✅
Sponsor, Kunde und Anwender
Die Rollen Sponsor, Kunde und Anwender repräsentieren Servicekonsumenten.
Merksatz:
Der Kunde bestellt und bezahlt das Auto (Sponsor), damit der Fahrer (Anwender) damit zur Arbeit fahren kann – alle drei nutzen und konsumieren den Service gemeinsam.
Warum die anderen falsch sind:
Governance, Practice und Wertstrom sind Bestandteile des Service-Wertsystems (SVS) und keine Personen oder Rollen.
Discover, Build und Support beschreiben Phasen oder Aktivitäten im Service-Lebenszyklus, keine Konsumenten-Rollen.
Provider und Lieferant stehen auf der erbringenden* Seite des Services, während Event ein Betriebsvorkommnis ist.
✅
Er stellt Services für Servicekonsumenten bereit
❌
Er genehmigt nur Budget
❌
Er nutzt Services als Anwender
❌
Er ist immer ein Produktprototyp
Service Provider stellen Services bereit.
❌
Er deployt jede Änderung automatisch
❌
Er ersetzt Governance
❌
Er ist eine Testaktivität
✅
Er nutzt Services und kann durch Sponsor, Kunde und Anwender repräsentiert werden
Servicekonsumenten nutzen Services und werden durch Rollen repräsentiert.
Merksatz:
Der
Konsument nutzt den Service am
SKA-T-Tisch: Er
Sponsert (zahlt), ist
Kunde (definiert Anforderungen) und
Anwender (nutzt ihn täglich).
Er deployt jede Änderung automatisch: Verwechselt den Konsumenten mit automatisierten Deployment-Tools (CI/CD-Pipeline) der IT.
Er ersetzt Governance: Governance (Führung) bleibt immer Aufgabe der Organisationsebene, ein Konsument kann diese Richtlinien nicht auflösen.
- Er ist eine Testaktivität: Ein Konsument ist eine aktive Rolle (Person/Gruppe) und kein Prozessschritt der Qualitätssicherung.
❌
Wert wird nur vom Provider erzeugt
❌
Wert entsteht nur durch Warentransfer
❌
Wert ist unabhängig von Ergebnissen
✅
Wert wird durch aktive Zusammenarbeit zwischen Service Providern, Servicekonsumenten und anderen Stakeholdern ermöglicht
Die Quelle beschreibt Service als Möglichkeit gemeinsamer Wertschöpfung.
❌
Es ist nur ein SLA
❌
Es ist ein Incident
❌
Es ist ein Known Error
✅
Es beschreibt Services für eine definierte Zielgruppe und kann Waren, Zugang zu Ressourcen und Serviceaktionen umfassen
Serviceangebote beschreiben Services und können Waren, Zugang und Serviceaktionen enthalten.
Merksatz:
Das
Serviceangebot ist wie eine
bunte Geschenkbox für eine bestimmte Zielgruppe: Drinnen liegen
Waren (Hardware), der
Zugang (Software-Lizenz) und
Aktionen (Support).
Warum die anderen falsch sind:
Nur ein SLA: Ein SLA (Service Level Agreement) regelt lediglich die Qualitätsstufen, ist aber nicht das physische oder digitale Gesamtpaket.
Ein Incident: Ein Incident ist eine ungeplante Störung und kein strukturiertes Angebot für Kunden.
- Ein Known Error: Ein Known Error ist ein bekannter Fehler mit Workaround und beschreibt keine nutzbaren Services.
❌
Sie übertragen immer Eigentum
❌
Sie sind Known Errors
❌
Sie ersetzen Anwender
✅
Sie werden von einem Service Provider durchgeführt, um Bedürfnisse eines Servicekonsumenten zu erfüllen
Serviceaktionen erfüllen Bedürfnisse eines Servicekonsumenten.
Merksatz:
Serviceaktionen sind die helfenden Hände des Providers: Er
tut etwas (Aktion), um dem Kunden direkt einen Wunsch zu erfüllen – wie ein Kellner, der das Essen serviert.
Warum die anderen falsch sind:
Eigentumsübertragung: Serviceaktionen stellen Ressourcen bereit oder führen Handlungen aus, aber Güter (wie Hardware) wechseln dabei nicht zwingend den Besitzer.
Known Errors: Dies sind dokumentierte Probleme mit bekannten Ursachen und keine proaktiven oder reaktiven Dienstleistungen für den Nutzer.
- Anwender ersetzen: Serviceaktionen unterstützen oder befähigen den Anwender bei seiner Arbeit, anstatt ihn komplett wegzurationalisieren.
❌
Es wird nur Zugang gewährt
❌
Es wird ein Incident gemeldet
❌
Es wird ein KPI definiert
✅
Materielle Ressourcen werden zusammen mit Eigentum und damit verbundenen Rechten und Pflichten übertragen
Waren beinhalten materielle Ressourcen und Eigentumsübertragung.
❌
Es ist eine Ursache für Incidents
❌
Es ist Schritt 5 des Improvement Models
✅
Ein Konsument erhält das Recht, Ressourcen unter vereinbarten Bedingungen zu nutzen
❌
Eigentum wird immer übertragen
Zugang ist Nutzung unter vereinbarten Bedingungen.
❌
Beide sind Sponsorrollen
✅
Utility beschreibt, was ein Service tut; Warranty beschreibt, wie ein Service leistet beziehungsweise ob er zur Nutzung geeignet ist
❌
Utility ist Governance
❌
Warranty ist Wertstromdarstellung
Utility betrifft Funktionalität; Warranty betrifft vereinbarte Anforderungen.
❌
Sie ersetzt Servicequalität
❌
Sie ist nur Nachhaltigkeit
✅
Sie umfasst funktionale und emotionale Interaktionen mit Service und Service Provider aus Sicht des Serviceanwenders
❌
Sie ist nur Verfügbarkeit
UX umfasst funktionale und emotionale Interaktionen.
❌
Sie ist nur Verfügbarkeit
❌
Sie ist Continuous Deployment
❌
Sie ist Sponsor
✅
Sie bezieht sich auf ökologische Verantwortung, sozialen Fortschritt und wirtschaftliches Wachstum
Nachhaltigkeit umfasst ökologische, soziale und wirtschaftliche Aspekte.
Merksatz:
Nachhaltigkeit im Service Level ist wie ein stabiler dreibeiniger Hocker: Er steht sicher auf
Ökologie (grün),
Soziales (Mensch) und
Wirtschaft (Wachstum) – bricht ein Bein weg, kippt der Service um.
Warum die anderen falsch sind:
Nur Verfügbarkeit: Das ist ein zu enger, rein technischer Fokus, der die soziale und ökologische Dimension komplett ignoriert.
Continuous Deployment: Dies ist eine reine Software-Auslieferungsmethode und kein ganzheitliches Nachhaltigkeitskonzept.
- Sponsor: Der Sponsor ist lediglich die Rolle, die das Budget freigibt, nicht die inhaltliche Definition von Nachhaltigkeit.
✅
Sie beschreibt Interaktionen zwischen Service Provider und Servicekonsument über die Beziehung hinweg
❌
Sie ist nur Build und Test
❌
Sie ist ein SLA
❌
Sie ist ein KI-Prompt
Die Service Journey ist ein Schlüsselkonzept von Servicebeziehungen.
Merksatz:
Die Service Journey ist wie eine
gemeinsame Urlaubsreise: Sie beginnt beim ersten Kennenlernen, geht über das gemeinsame Erlebnis und endet erst, wenn Provider und Konsument getrennte Wege gehen – sie umfasst die
gesamte Beziehung.
Warum die anderen falsch sind:
Nur Build und Test: Dies greift viel zu kurz, da es nur zwei isolierte, rein technische Phasen der Entwicklung beschreibt.
Ein SLA: Ein Service Level Agreement ist lediglich eine formelle, schriftliche Vereinbarung über Leistungsparameter, keine dynamische Kundenreise.
- Ein KI-Prompt: Dies ist nur eine Eingabeaufforderung für künstliche Intelligenz und hat keinen Bezug zum ganzheitlichen ITIL-Beziehungsmodell.
❌
Sie sind nur interne Kunden
❌
Sie sind Governance-Muster
✅
Sie beruhen auf einer begrenzten Interaktion zwischen Service Provider und Servicekonsument
❌
Sie sind immer Partnerschaften
Die Quelle unterscheidet einfache Beziehungen von Kooperation und Zusammenarbeit.
Merksatz:
Eine
einfache Beziehung ist wie der schnelle Kauf beim Bäcker: Man redet kurz, tauscht Geld gegen Brötchen und geht wieder – die Interaktion ist also streng
begrenzt.
Warum die anderen falsch sind:
Nur interne Kunden: Falsch, da Servicebeziehungen natürlich auch mit externen Kunden und Partnern stattfinden.
Governance-Muster: Falsch, denn Governance ist die übergeordnete Führung und Steuerung, kein Beziehungsmodell.
- Immer Partnerschaften: Falsch, da eine echte Partnerschaft (wie Shared Services) eine tiefe, gemeinsame Wertschöpfung erfordert und nicht bloß "einfach" ist.
✅
Provider und Konsument stimmen sich stärker ab als in einfachen Beziehungen
❌
Sie schließen Feedback aus
❌
Sie sind ausschließlich Warentransfers
❌
Sie ersetzen den Konsumenten
Kooperation bedeutet stärkere Abstimmung.
Merksatz:
„Kooperation braucht Kommunikation“ – Je enger die Partner zusammenarbeiten, desto intensiver müssen sie sich absprechen (stärkere Abstimmung), um gemeinsam Werte zu schaffen.
Warum die anderen falsch sind:
„schließen Feedback aus“: Kooperation lebt zwingend von kontinuierlichem Feedback, um sich gemeinsam zu verbessern.
„ausschließlich Warentransfers“: Einfache Warentransfers sind rein transaktional und das Gegenteil einer partnerschaftlichen Kooperation.
- „ersetzen den Konsumenten“: Ohne Konsumenten gibt es keine Servicebeziehung, er kann niemals durch Kooperation ersetzt werden.
❌
Sie sind keine Vereinbarungsbestandteile
✅
Service Level-Metriken können Utility, Warranty, Nachhaltigkeit und Experience umfassen
❌
Sie werden nur durch CI bestimmt
❌
Sie sind nur Budget
Die Quelle nennt diese vier Kategorien von Service Level-Metriken.
Serviceangebot, Waren, Zugang zu Ressourcen, Serviceaktionen [Begriffe]
4
✅
Serviceangebot
❌
Wertstrom
❌
Produktprototyp
❌
Service Level Agreement
Richtig ist A: Ein Serviceangebot kann Services, Waren, Zugang zu Ressourcen und Serviceaktionen für eine Zielgruppe beschreiben. Zu den anderen Optionen: B – Wertstrom ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Produktprototyp beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Service Level Agreement liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Wertstrom
❌
Produktprototyp
❌
Service Level Agreement
✅
Serviceangebot
Richtig ist D: Ein Serviceangebot kann Services, Waren, Zugang zu Ressourcen und Serviceaktionen für eine Zielgruppe beschreiben. Zu den anderen Optionen: A – Wertstrom ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Produktprototyp beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Service Level Agreement liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Das
Serviceangebot ist wie ein bunter
Geschenkkorb (Paket) für den Kunden: Es enthält verschiedene Leckereien wie Waren (Token), Zugang zu Ressourcen (Software) und Serviceaktionen (Schulung/Beratung), geschnürt für eine bestimmte Zielgruppe.
Warum die anderen falsch sind:
Wertstrom: Beschreibt den internen Fluss von Aktivitäten zur Wertschöpfung, nicht das fertige, vertragliche Kundenpaket.
Produktprototyp: Ist nur ein unfertiges Testmodell zur Validierung, kein produktives, vertraglich vereinbartes Leistungspaket.
- Service Level Agreement: Dokumentiert lediglich die vereinbarten Qualitätsstandards und Service-Ziele, ist aber nicht das physische Paket aus Ressourcen und Services selbst.
❌
Produktprototyp
❌
Service Level Agreement
✅
Serviceangebot
❌
Wertstrom
Richtig ist C: Ein Serviceangebot kann Services, Waren, Zugang zu Ressourcen und Serviceaktionen für eine Zielgruppe beschreiben. Zu den anderen Optionen: A – Produktprototyp beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Service Level Agreement liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Wertstrom ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Service Level Agreement
✅
Serviceangebot
❌
Wertstrom
❌
Produktprototyp
Richtig ist B: Ein Serviceangebot kann Services, Waren, Zugang zu Ressourcen und Serviceaktionen für eine Zielgruppe beschreiben. Zu den anderen Optionen: A – Service Level Agreement liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Wertstrom ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Produktprototyp beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Das
Serviceangebot ist wie eine gepackte
Kombinations-Box im Supermarkt: Es schnürt Waren (Token), Ressourcenzugang (Software) und Serviceaktionen (Schulung, Beratung) zu einem fertigen Paket für eine Zielgruppe.
Warum die anderen falsch sind:
Service Level Agreement: Ist nur die Qualitätsvereinbarung (Messgrößen) für den laufenden Betrieb, nicht das physische Ressourcenpaket selbst.
Wertstrom: Beschreibt den dynamischen Arbeitsfluss (Schritte) zur Wertschöpfung, nicht die konkreten Bestandteile des Angebots.
- Produktprototyp: Ist ein unfertiges Testmodell zur Entwicklung und kein vertraglich vereinbartes, produktives Leistungspaket für Kunden.
Utility, Warranty, User Experience, Nachhaltigkeit [Begriffe]
4
❌
User Experience
❌
Nachhaltigkeit
❌
Utility
✅
Warranty
Richtig ist D: Warranty betrifft die Zusicherung, dass vereinbarte Anforderungen und Service Levels erfüllt werden. Zu den anderen Optionen: A – User Experience ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Nachhaltigkeit beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Utility liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Warranty (Gewährleistung) ist das Versprechen,
wie ein Service läuft – ohne die „Vier Musketiere“ Kapazität, Verfügbarkeit, Sicherheit und Kontinuität (SLA-Werte) ist das Versprechen gebrochen, selbst wenn die Funktion (Utility) da ist.
Utility ist falsch: Die Funktion („Was“ der Service tut – das Buchen) ist gegeben, also ist Utility erfüllt.
User Experience ist falsch: UX ist zwar beeinträchtigt, aber das ist nur die Folge des tieferliegenden, messbaren Warranty-Mangels (Verfügbarkeit/Antwortzeit).
- Nachhaltigkeit ist falsch: Ökologische oder soziale Aspekte spielen bei diesem rein technischen Performance-Problem keine Rolle.
❌
Nachhaltigkeit
❌
Utility
✅
Warranty
❌
User Experience
Richtig ist C: Warranty betrifft die Zusicherung, dass vereinbarte Anforderungen und Service Levels erfüllt werden. Zu den anderen Optionen: A – Nachhaltigkeit beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Utility liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – User Experience ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Utility
✅
Warranty
❌
User Experience
❌
Nachhaltigkeit
Richtig ist B: Warranty betrifft die Zusicherung, dass vereinbarte Anforderungen und Service Levels erfüllt werden. Zu den anderen Optionen: A – Utility liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – User Experience ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Nachhaltigkeit beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Warranty
❌
User Experience
❌
Nachhaltigkeit
❌
Utility
Richtig ist A: Warranty betrifft die Zusicherung, dass vereinbarte Anforderungen und Service Levels erfüllt werden. Zu den anderen Optionen: B – User Experience ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Nachhaltigkeit beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Utility liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Output und Ergebnis [Begriffe]
4
❌
Kosten und Risiko
❌
Produkt und Service
✅
Output und Ergebnis
❌
Service Request und Incident
Richtig ist C: Die Funktion ist ein Output; der verbesserte Nutzen für den Stakeholder ist das Ergebnis. Zu den anderen Optionen: A – Kosten und Risiko beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Produkt und Service liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Service Request und Incident ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Produkt und Service
✅
Output und Ergebnis
❌
Service Request und Incident
❌
Kosten und Risiko
Richtig ist B: Die Funktion ist ein Output; der verbesserte Nutzen für den Stakeholder ist das Ergebnis. Zu den anderen Optionen: A – Produkt und Service liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Service Request und Incident ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Kosten und Risiko beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Merksatz:
Output ist das Werkzeug, Ergebnis ist der Nutzen. Das Dashboard ist der sichtbare Ausstoß (
Output), aber der wahre Wert (
Ergebnis/Outcome) zeigt sich erst in der Wirkung: weniger Leerfahrten und schnellere Entscheidungen.
Produkt und Service: Ein Produkt ist die materielle/immaterielle Basis, während der Service die Wertschöpfung beschreibt – hier geht es aber konkret um die Wirkung
des gelieferten Dashboards.
Service Request und Incident: Dies sind betriebliche Prozesse (Anfragen vs. Störungen) und keine Konzepte zur Wertbeurteilung von Liefergegenständen.
- Kosten und Risiko: Diese Faktoren beeinflussen zwar den Wert, beschreiben aber nicht den direkten Unterschied zwischen der reinen Lieferung und dem tatsächlichen Nutzen.
✅
Output und Ergebnis
❌
Service Request und Incident
❌
Kosten und Risiko
❌
Produkt und Service
Richtig ist A: Die Funktion ist ein Output; der verbesserte Nutzen für den Stakeholder ist das Ergebnis. Zu den anderen Optionen: B – Service Request und Incident ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Kosten und Risiko beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Produkt und Service liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Der
Output ist das gelieferte Werkzeug (das Dashboard), aber das
Ergebnis (Outcome) ist das, was der Nutzer damit erreicht (weniger Leerfahrten und schnellere Entscheidungen).
Service Request und Incident: Falsch, da es hier nicht um Standard-Nutzeranfragen oder die Behebung von Störungen geht.
Kosten und Risiko: Falsch, da weder finanzielle Aufwände noch potenzielle Bedrohungen oder Unsicherheiten der Dashboard-Nutzung im Fokus stehen.
- Produkt und Service: Falsch, da dieser Vergleich die Bündelung von Ressourcen (Produkt) mit dem gemeinsamen Wertschöpfungsprozess (Service) betrifft, nicht aber den Unterschied zwischen Lieferung und tatsächlichem Nutzen.
❌
Service Request und Incident
❌
Kosten und Risiko
❌
Produkt und Service
✅
Output und Ergebnis
Richtig ist D: Die Funktion ist ein Output; der verbesserte Nutzen für den Stakeholder ist das Ergebnis. Zu den anderen Optionen: A – Service Request und Incident ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Kosten und Risiko beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Produkt und Service liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Servicekonsumentenrollen [Begriffe]
4
❌
Service Provider, Lieferant und Partner
✅
Sponsor, Kunde und Anwender
❌
Practice Owner, Process Owner und Product Manager
❌
Incident Manager, Service Desk und Anwender
Richtig ist B: Sponsor genehmigt Budget, Kunde definiert Anforderungen und Anwender nutzt Services. Zu den anderen Optionen: A – Service Provider, Lieferant und Partner liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Practice Owner, Process Owner und Product Manager ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Incident Manager, Service Desk und Anwender beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Sponsor, Kunde und Anwender
❌
Practice Owner, Process Owner und Product Manager
❌
Incident Manager, Service Desk und Anwender
❌
Service Provider, Lieferant und Partner
Richtig ist A: Sponsor genehmigt Budget, Kunde definiert Anforderungen und Anwender nutzt Services. Zu den anderen Optionen: B – Practice Owner, Process Owner und Product Manager ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Incident Manager, Service Desk und Anwender beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Service Provider, Lieferant und Partner liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Der
Sponsor zahlt die Zeche, der
Kunde bestimmt die Ansprüche (Requirements), und der
Anwender nutzt das Werkzeug täglich – denk an das Trio
Sparbuch,
König und
Arbeiter (
S-K-A).
Practice Owner, Process Owner und Product Manager: Dies sind interne ITIL-Management-Rollen und keine Rollen des Servicekonsumenten.
Incident Manager, Service Desk und Anwender: Incident Manager und Service Desk sind Rollen des Service-Providers, nicht des Konsumenten.
- Service Provider, Lieferant und Partner: Diese beschreiben die Anbieterseite der Wertschöpfungskette, nicht die konsumierenden Rollen im Klinikverbund.
❌
Practice Owner, Process Owner und Product Manager
❌
Incident Manager, Service Desk und Anwender
❌
Service Provider, Lieferant und Partner
✅
Sponsor, Kunde und Anwender
Richtig ist D: Sponsor genehmigt Budget, Kunde definiert Anforderungen und Anwender nutzt Services. Zu den anderen Optionen: A – Practice Owner, Process Owner und Product Manager ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Incident Manager, Service Desk und Anwender beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Service Provider, Lieferant und Partner liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Der
Sponsor zahlt (Finanzierer), der
Kunde definiert die Anforderungen (Product Owner) und der
Anwender nutzt das System täglich (Mitarbeitende) – das Trio des Servicekonsums.
Practice Owner, Process Owner und Product Manager: Dies sind interne Steuerungsrollen des Service Providers, keine Rollen der Servicekonsumenten.
Incident Manager, Service Desk und Anwender: Beschreibt Support-Funktionen und vernachlässigt die strategische Rolle des Kunden sowie die finanzielle des Sponsors.
- Service Provider, Lieferant und Partner: Dies sind Akteure der Wertschöpfungskette auf der Anbieterseite, nicht auf der Konsumentenseite.
❌
Incident Manager, Service Desk und Anwender
❌
Service Provider, Lieferant und Partner
✅
Sponsor, Kunde und Anwender
❌
Practice Owner, Process Owner und Product Manager
Richtig ist C: Sponsor genehmigt Budget, Kunde definiert Anforderungen und Anwender nutzt Services. Zu den anderen Optionen: A – Incident Manager, Service Desk und Anwender beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Service Provider, Lieferant und Partner liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Practice Owner, Process Owner und Product Manager ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Digitale Produkte und digitale Services [Begriffe]
4
✅
Digitale Services können vollständig oder weitgehend auf digitalen Produkten basieren
❌
Digitale Services bestehen ausschließlich aus Serviceaktionen
❌
Digitale Produkte können nicht gleichzeitig genutzt und verbessert werden
❌
Digitale Produkte sind immer physisch zu liefern
Richtig ist A: Digitale Services basieren vollständig oder weitgehend auf digitalen Produkten; digitale Produkte kombinieren digitale Ressourcen. Zu den anderen Optionen: B – Digitale Services bestehen ausschließlich aus Serviceaktionen ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Digitale Produkte können nicht gleichzeitig genutzt und verbessert werden beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Digitale Produkte sind immer physisch zu liefern liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Ein
digitales Produkt ist das unsichtbare Fundament (wie die Cloud-App im Hintergrund), auf dem der
digitale Service (die sichtbare, nutzbare Buchung für den Kunden) wie ein Haus aufgebaut ist.
Warum die anderen falsch sind:
„ausschließlich aus Serviceaktionen“: Falsch, da digitale Services auch physische Ressourcen und Waren umfassen können, nicht nur reine Interaktionen.
„nicht gleichzeitig genutzt und verbessert werden“: Falsch, da moderne digitale Produkte (z. B. durch CI/CD-Updates im Hintergrund) im laufenden Betrieb optimiert werden.
- „immer physisch zu liefern“: Falsch, da digitale Produkte per Definition immateriell sind und über das Netzwerk (wie die Cloud) bereitgestellt werden.
❌
Digitale Services bestehen ausschließlich aus Serviceaktionen
❌
Digitale Produkte können nicht gleichzeitig genutzt und verbessert werden
❌
Digitale Produkte sind immer physisch zu liefern
✅
Digitale Services können vollständig oder weitgehend auf digitalen Produkten basieren
Richtig ist D: Digitale Services basieren vollständig oder weitgehend auf digitalen Produkten; digitale Produkte kombinieren digitale Ressourcen. Zu den anderen Optionen: A – Digitale Services bestehen ausschließlich aus Serviceaktionen ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Digitale Produkte können nicht gleichzeitig genutzt und verbessert werden beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Digitale Produkte sind immer physisch zu liefern liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Digitale Produkte können nicht gleichzeitig genutzt und verbessert werden
❌
Digitale Produkte sind immer physisch zu liefern
✅
Digitale Services können vollständig oder weitgehend auf digitalen Produkten basieren
❌
Digitale Services bestehen ausschließlich aus Serviceaktionen
Richtig ist C: Digitale Services basieren vollständig oder weitgehend auf digitalen Produkten; digitale Produkte kombinieren digitale Ressourcen. Zu den anderen Optionen: A – Digitale Produkte können nicht gleichzeitig genutzt und verbessert werden beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Digitale Produkte sind immer physisch zu liefern liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Digitale Services bestehen ausschließlich aus Serviceaktionen ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
Merksatz:
Ein
digitales Produkt (Cloud, Daten, Schnittstellen) ist das unsichtbare Fundament, auf dem der
digitale Service (die Buchungs-App) als sichtbares Gebäude für den Kunden thront.
Warum die anderen falsch sind:
Gleichzeitig nutzen und verbessern: Falsch, da agile IT (DevOps) Produkte im laufenden Betrieb kontinuierlich optimiert.
Immer physisch liefern: Falsch, da digitale Produkte rein virtuell über Netzwerke bereitgestellt werden.
- Ausschließlich Serviceaktionen: Falsch, da Services neben Aktionen auch auf Ressourcen (Servern) und Gütern basieren.
❌
Digitale Produkte sind immer physisch zu liefern
✅
Digitale Services können vollständig oder weitgehend auf digitalen Produkten basieren
❌
Digitale Services bestehen ausschließlich aus Serviceaktionen
❌
Digitale Produkte können nicht gleichzeitig genutzt und verbessert werden
Richtig ist B: Digitale Services basieren vollständig oder weitgehend auf digitalen Produkten; digitale Produkte kombinieren digitale Ressourcen. Zu den anderen Optionen: A – Digitale Produkte sind immer physisch zu liefern liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Digitale Services bestehen ausschließlich aus Serviceaktionen ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Digitale Produkte können nicht gleichzeitig genutzt und verbessert werden beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
Servicebeziehungen [Begriffe]
4
❌
Warentransfer
❌
Einfache Servicebeziehung
✅
Auf Zusammenarbeit basierende Servicebeziehung (Partnerschaft)
❌
Auf Kooperation basierende Servicebeziehung
Richtig ist C: Die enge gemeinsame Planung und geteilte Verantwortung entsprechen einer partnerschaftlichen, auf Zusammenarbeit basierenden Servicebeziehung. Zu den anderen Optionen: A – Warentransfer beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Einfache Servicebeziehung liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Auf Kooperation basierende Servicebeziehung ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Einfache Servicebeziehung
✅
Auf Zusammenarbeit basierende Servicebeziehung (Partnerschaft)
❌
Auf Kooperation basierende Servicebeziehung
❌
Warentransfer
Richtig ist B: Die enge gemeinsame Planung und geteilte Verantwortung entsprechen einer partnerschaftlichen, auf Zusammenarbeit basierenden Servicebeziehung. Zu den anderen Optionen: A – Einfache Servicebeziehung liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Auf Kooperation basierende Servicebeziehung ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Warentransfer beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Auf Zusammenarbeit basierende Servicebeziehung (Partnerschaft)
❌
Auf Kooperation basierende Servicebeziehung
❌
Warentransfer
❌
Einfache Servicebeziehung
Richtig ist A: Die enge gemeinsame Planung und geteilte Verantwortung entsprechen einer partnerschaftlichen, auf Zusammenarbeit basierenden Servicebeziehung. Zu den anderen Optionen: B – Auf Kooperation basierende Servicebeziehung ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Warentransfer beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Einfache Servicebeziehung liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Echte
Partner planen den Weg gemeinsam auf einer
Roadmap, teilen sich die Daten und tragen zusammen die Verantwortung für den Erfolg – wie in einer guten Ehe (Partnerschaft).
Kooperation: Ist ein Ablenkungsbegriff; ITIL nutzt offiziell „Zusammenarbeit/Partnerschaft“ für diese tiefe, beidseitige Wertschöpfung.
Warentransfer: Passt nicht, da hier physische Güter den Besitzer wechseln (z. B. PC-Kauf) statt einer fortlaufenden, interaktiven Beziehung.
- Einfache Servicebeziehung: Greift zu kurz, da sie nur aus standardisierter Bereitstellung und Nutzung besteht, ohne gemeinsame strategische Roadmap-Planung.
❌
Auf Kooperation basierende Servicebeziehung
❌
Warentransfer
❌
Einfache Servicebeziehung
✅
Auf Zusammenarbeit basierende Servicebeziehung (Partnerschaft)
Richtig ist D: Die enge gemeinsame Planung und geteilte Verantwortung entsprechen einer partnerschaftlichen, auf Zusammenarbeit basierenden Servicebeziehung. Zu den anderen Optionen: A – Auf Kooperation basierende Servicebeziehung ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Warentransfer beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Einfache Servicebeziehung liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Servicequalität und Service Level [Begriffe]
4
❌
Service Request
✅
Service Level
❌
Known Error
❌
Produktprototyp
Richtig ist B: Service Level definieren erwartete oder erreichte Servicequalität über Messgrößen, unter anderem Utility, Warranty, Nachhaltigkeit und Experience. Zu den anderen Optionen: A – Service Request liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Known Error ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Produktprototyp beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Service Level
❌
Known Error
❌
Produktprototyp
❌
Service Request
Richtig ist A: Service Level definieren erwartete oder erreichte Servicequalität über Messgrößen, unter anderem Utility, Warranty, Nachhaltigkeit und Experience. Zu den anderen Optionen: B – Known Error ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Produktprototyp beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Service Request liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Known Error
❌
Produktprototyp
❌
Service Request
✅
Service Level
Richtig ist D: Service Level definieren erwartete oder erreichte Servicequalität über Messgrößen, unter anderem Utility, Warranty, Nachhaltigkeit und Experience. Zu den anderen Optionen: A – Known Error ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Produktprototyp beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Service Request liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Produktprototyp
❌
Service Request
✅
Service Level
❌
Known Error
Richtig ist C: Service Level definieren erwartete oder erreichte Servicequalität über Messgrößen, unter anderem Utility, Warranty, Nachhaltigkeit und Experience. Zu den anderen Optionen: A – Produktprototyp beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Service Request liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Known Error ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
SLA und Serviceangebot [Begriffe]
4
❌
Serviceangebot und SLA sind identisch
❌
SLA ersetzt Serviceaktionen und Zugang zu Ressourcen
❌
SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte
✅
Serviceangebot beschreibt das Paket; SLA dokumentiert benötigte Services und erwartete Service Levels
Richtig ist D: Serviceangebot und SLA sind eng verbunden, aber nicht identisch. Zu den anderen Optionen: A – Serviceangebot und SLA sind identisch ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – SLA ersetzt Serviceaktionen und Zugang zu Ressourcen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Das
Serviceangebot ist die bunte
Speisekarte (Paket für Zielgruppen), während das
SLA die verbindliche
Bestellung mit der exakten Lieferzeit und Qualität (erwartete Service Levels) ist.
Warum die anderen falsch sind:
SLA und Serviceangebot sind identisch: Ignoriert, dass das Angebot eine unverbindliche Option vor dem Vertrag ist, während das SLA verbindliche Qualitätszusagen nach dem Vertrag regelt.
SLA ersetzt Serviceaktionen und Zugang: Ein SLA ist ein reines Steuerungsdokument und kann physische Ressourcen oder konkrete Support-Aktionen nicht ersetzen.
- SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte: Vertauscht die Definitionen komplett, da Angebote sich an Zielgruppen richten und SLAs die Messwerte (Levels) festlegen.
❌
SLA ersetzt Serviceaktionen und Zugang zu Ressourcen
❌
SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte
✅
Serviceangebot beschreibt das Paket; SLA dokumentiert benötigte Services und erwartete Service Levels
❌
Serviceangebot und SLA sind identisch
Richtig ist C: Serviceangebot und SLA sind eng verbunden, aber nicht identisch. Zu den anderen Optionen: A – SLA ersetzt Serviceaktionen und Zugang zu Ressourcen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Serviceangebot und SLA sind identisch ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte
✅
Serviceangebot beschreibt das Paket; SLA dokumentiert benötigte Services und erwartete Service Levels
❌
Serviceangebot und SLA sind identisch
❌
SLA ersetzt Serviceaktionen und Zugang zu Ressourcen
Richtig ist B: Serviceangebot und SLA sind eng verbunden, aber nicht identisch. Zu den anderen Optionen: A – SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Serviceangebot und SLA sind identisch ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – SLA ersetzt Serviceaktionen und Zugang zu Ressourcen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Serviceangebot beschreibt das Paket; SLA dokumentiert benötigte Services und erwartete Service Levels
❌
Serviceangebot und SLA sind identisch
❌
SLA ersetzt Serviceaktionen und Zugang zu Ressourcen
❌
SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte
Richtig ist A: Serviceangebot und SLA sind eng verbunden, aber nicht identisch. Zu den anderen Optionen: B – Serviceangebot und SLA sind identisch ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – SLA ersetzt Serviceaktionen und Zugang zu Ressourcen beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – SLA beschreibt Zielgruppen; Serviceangebot dokumentiert nur Messwerte liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
Merksatz:
Das
Angebot schnürt das Paket für den Kunden im Schaufenster, aber erst das
SLA nagelt die konkreten Leistungswerte im Vertrag fest.
Warum die anderen falsch sind:
Identisch: Ein Angebot ist unverbindliche Auswahl, das SLA eine verbindliche Leistungsvereinbarung.
SLA ersetzt Aktionen/Ressourcen: Das SLA misst die Leistung, ersetzt aber niemals die tatsächlichen Ressourcen oder Support-Aktionen.
- SLA beschreibt Zielgruppen / Angebot dokumentiert Messwerte: Genau umgekehrt – das Angebot richtet sich an Zielgruppen, das SLA definiert die harten Messwerte.
Continual Improvement [Begriffe]
4
❌
Warentransfer
❌
Transition
✅
Continual Improvement
❌
Service Request Management
Richtig ist C: Continual Improvement ist eine wiederkehrende Aktivität zur Verbesserung auf allen Ebenen. Zu den anderen Optionen: A – Warentransfer beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; B – Transition liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; D – Service Request Management ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario..
❌
Transition
✅
Continual Improvement
❌
Service Request Management
❌
Warentransfer
Richtig ist B: Continual Improvement ist eine wiederkehrende Aktivität zur Verbesserung auf allen Ebenen. Zu den anderen Optionen: A – Transition liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept.; C – Service Request Management ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; D – Warentransfer beschreibt einen anderen Aspekt des Produkt- und Servicemanagements..
✅
Continual Improvement
❌
Service Request Management
❌
Warentransfer
❌
Transition
Richtig ist A: Continual Improvement ist eine wiederkehrende Aktivität zur Verbesserung auf allen Ebenen. Zu den anderen Optionen: B – Service Request Management ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; C – Warentransfer beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; D – Transition liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..
❌
Service Request Management
❌
Warentransfer
❌
Transition
✅
Continual Improvement
Richtig ist D: Continual Improvement ist eine wiederkehrende Aktivität zur Verbesserung auf allen Ebenen. Zu den anderen Optionen: A – Service Request Management ist fachlich relevant, trifft aber nicht den entscheidenden Unterschied im Szenario.; B – Warentransfer beschreibt einen anderen Aspekt des Produkt- und Servicemanagements.; C – Transition liegt nahe, verwechselt aber einen benachbarten ITIL Begriff mit dem im Szenario geprüften Konzept..