ITIL Foundation (Version 5) – Referenz & Glossar

Eigene Unterseiten: Glossar Themen Modelle Fragen

Fachbegriff-Glossar

Lade…

Lern-Podcasts & Videos

Kurze Audio- und Video-Lektionen zu wichtigen Themen für unterwegs.

Lade Podcasts...

Wichtige Modelle & Merkhilfen

🧭 7 Leitprinzipien

Guiding Principles — gelten für jede Situation

Fokus auf Wert — Alles am Wert für Stakeholder ausrichten

Dort anfangen, wo man steht — Bestehendes nutzen statt bei null zu beginnen

Iterativ mit Feedback — Kleine Schritte, regelmäßiges Feedback

Zusammenarbeit & Sichtbarkeit — Beteiligte einbinden, Arbeit sichtbar machen

Ganzheitlich denken — Das Gesamtsystem betrachten

Einfach & praktikabel — Unnötige Komplexität vermeiden

Optimieren & automatisieren — Erst optimieren, dann automatisieren

Merkhilfe: erst verstehen, dann verbessern, dann erst automatisieren.

🧱 Die 4 Dimensionen

Ganzheitliche Sicht auf Produkt- und Servicemanagement

Organisationen und Menschen — Struktur, Rollen, Kultur, Kompetenzen

Informationen und Technologie — Wissen, Daten, eingesetzte Technik

Partner und Lieferanten — Externe Beziehungen und Sourcing

Wertströme und Prozesse — Wie Aktivitäten zusammenwirken

Externe Einflüsse auf alle vier: PESTLE (politisch, wirtschaftlich, sozial, technologisch, rechtlich, ökologisch).

🔄 Produkt- & Servicelebenszyklus

8 Stufen, iterativ und nicht-linear genutzt

Discover — Bedarf und Chancen erkennen

Design — Lösung konzipieren

Acquire — Beschaffen

Build — Selbst entwickeln

Transition — Übergang in den Betrieb

Operate — Laufender Betrieb

Deliver — Bereitstellung an Nutzer:innen

Support — Unterstützung bei Problemen

Nicht streng sequenziell — Stufen werden je nach Bedarf wiederholt oder übersprungen.

💎 ITIL Value System

Komponenten im Zusammenspiel

Governance — Evaluate, Direct, Monitor

Guiding Principles — Die 7 Leitprinzipien

Practices — Organisierte Ressourcen zur Zielerreichung

Wertströme — Ende-zu-Ende-Abläufe zur Wertschöpfung

Continual Improvement — Durchgängiges Verbesserungsprinzip

Größter Prüfungsblock: 40% aller Fragen (16 von 40 Punkten).

🌍 PESTLE

Externe Einflussfaktoren auf alle 4 Dimensionen

Politisch — Gesetzgebung, Regierungspolitik

Wirtschaftlich — Konjunktur, Budgets, Märkte

Sozial — Werte, Demografie, Erwartungen

Technologisch — Neue Technologien, Innovation

Rechtlich — Gesetze, Regulierung, Compliance

Ökologisch — Umwelt, Nachhaltigkeit

Syllabus-Landkarte

43 Themenelemente über 7 Bereiche. Klicke auf ein Element für eine Lernhilfe.

📖 Wichtige ITIL-Begriffe (6)

ITIL-Grundbegriffe und Definitionen

Basisvokabular: Service, Produkt, Wert, Outcome, Nutzen

Servicequalität und Service Level Agreements (SLA)

Wie Leistungsversprechen vereinbart und gemessen werden

Utility, Warranty, User Experience, Nachhaltigkeit

Nutzen vs. Zusicherung, Erlebnisqualität, ESG-Bezug

Produkte, Services, Serviceangebote

Abgrenzung der drei Grundbegriffe

Servicekonsument, Service Provider, Sponsor, Kundschaft, Anwender:innen

Die Rollen im Wertschöpfungsnetzwerk

Management digitaler Produkte und Services

Was sich gegenüber klassischem IT-Servicemanagement ändert

🧭 Die 4 Dimensionen (4)

Organisationen und Menschen

Strukturen, Rollen, Kultur, Kompetenzen

Partner und Lieferanten

Beziehungen zu externen Organisationen

Informationen und Technologie

Wissen, Daten, eingesetzte Technologien

Wertströme und Prozesse

Wie Aktivitäten zusammen Wert erzeugen

🔄 Produkt- & Servicelebenszyklus (8)

Discover

Bedarf und Marktchancen erkennen

Design

Lösung konzipieren

Acquire und Build

Beschaffen bzw. selbst entwickeln

Transition

Übergang in den Produktivbetrieb

Operate

Laufender Betrieb

Deliver und Support

Bereitstellung und Unterstützung der Nutzer:innen

Iterative und nicht-lineare Nutzung des Lebenszyklus

Kein starrer Wasserfall — Stufen werden je nach Bedarf wiederholt/übersprungen

Wertschöpfung im Produkt- und Servicelebenszyklus

Wo in welcher Stufe Wert entsteht

💎 ITIL Value System (11)

Komponenten des ITIL Value Systems

Governance, Wertschöpfungskette, Practices, Grundprinzipien, Continual Improvement im Zusammenspiel

ITIL Grundprinzipien

7 Leitprinzipien, u.a. Fokus auf Wert, dort anfangen wo man steht, iterativ vorgehen

Governance

Steuerung und Kontrolle auf Organisationsebene

Wertschöpfungskette und Betriebsmodell

Wie Aktivitäten organisationsweit ineinandergreifen

Management-Practices und Practice-Leitfäden

Organisierte Ressourcen zur Zielerreichung

Continual Improvement

Kontinuierliche Verbesserung als durchgängiges Prinzip

Ganzheitlicher Ansatz und externe Einflussfaktoren

PESTLE-artige Betrachtung des Umfelds

Wertorientierung, Zusammenarbeit und Optimierung

Kernhaltungen hinter den Grundprinzipien

Servicebetrieb, Releases und Problemmanagement

Operative Kernthemen im Value System verankert

Messgrößen und Critical Success Factors (CSF)

Erfolg sichtbar und steuerbar machen

Projektmanagement im Produkt- und Servicelebenszyklus

Wo klassisches PM in ITIL andockt

🔀 Wertströme (4)

Wertstromidentifizierung, -abbildung und -management

Value Stream Mapping als Werkzeug

Hauptwertströme

Die zentralen, wertschöpfenden Abläufe

Unterstützende Wertströme

Ströme, die die Hauptwertströme ermöglichen

Wertstromdarstellung

Visualisierung und Lesart eines Wertstroms

🤖 ITIL und KI (5)

Künstliche Intelligenz (KI) und KI-Reife

Reifegradmodell für den KI-Einsatz in Organisationen

Generative KI (GenAI)

Inhaltserzeugende KI-Systeme im Servicekontext

Agentic KI

Autonom handelnde KI-Agenten

KI im Produkt- und Servicelebenszyklus

Wo KI in welcher Lebenszyklusstufe unterstützt

KI-Governance

Steuerung, Verantwortung und Risiken beim KI-Einsatz

🔗 ITIL und andere Rahmenwerke (5)

ITIL und DevOps

Gemeinsamkeiten und Ergänzung der beiden Ansätze

Continuous Integration, Delivery, Deployment (CI/CD)

Automatisierte Bereitstellungspraxis

Site Reliability Engineering (SRE) und Observability

Zuverlässigkeit technisch messbar machen

Komplexitätsdenken und Workflowoptimierung

Umgang mit komplexen, nicht-linearen Systemen

ITIL und PRINCE2

Zusammenspiel von Servicemanagement- und Projektmanagement-Rahmenwerk

Alle Prüfungsfragen

624 Fragen 570 Single 19 Multi 35 Offen

Die 4 Dimensionen

Übersicht [Dimensionen] 1 Unterseite →

☝️ Single Wie viele Dimensionen des Produkt- und Servicemanagements definiert ITIL?

✅ Vier

❌ Drei

❌ Fünf

❌ Sechs

Es sind vier Dimensionen: Organisationen & Menschen, Partner & Lieferanten, Informationen & Technologie, Wertströme & Prozesse.

Organisationen und Menschen [Dimensionen] 5 Unterseite →

☝️ Single Was fällt primär unter die Dimension "Organisationen und Menschen"?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein neues Produkt scheitert nicht an Technologie, sondern an unklaren Verantwortlichkeiten, fehlenden Kompetenzen, widersprüchlichen Kommunikationswegen und einer Kultur, die Feedback vermeidet. Welche Dimension ist AM DEUTLICHSTEN betroffen?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein neues Produkt scheitert nicht an Technologie, sondern an unklaren Verantwortlichkeiten, fehlenden Kompetenzen, widersprüchlichen Kommunikationswegen und einer Kultur, die Feedback vermeidet. Welche Dimension ist AM DEUTLICHSTEN betroffen?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein neues Produkt scheitert nicht an Technologie, sondern an unklaren Verantwortlichkeiten, fehlenden Kompetenzen, widersprüchlichen Kommunikationswegen und einer Kultur, die Feedback vermeidet. Welche Dimension ist AM DEUTLICHSTEN betroffen?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein neues Produkt scheitert nicht an Technologie, sondern an unklaren Verantwortlichkeiten, fehlenden Kompetenzen, widersprüchlichen Kommunikationswegen und einer Kultur, die Feedback vermeidet. Welche Dimension ist AM DEUTLICHSTEN betroffen?

✅ 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 Unterseite →

☝️ Single Was umfasst die Dimension "Informationen und Technologie"?

✅ 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 Unterseite →

☝️ Single Worum geht es in der Dimension "Partner und Lieferanten"?

✅ 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 Unterseite →

☝️ Single Was beschreibt die Dimension "Wertströme und Prozesse"?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Incident wird technisch schnell gelöst, aber die Übergaben zwischen Service Desk, Betriebsteam und Produktteam erzeugen Verzögerungen. Das Team stellt den tatsächlichen Arbeits- und Informationsfluss dar. Welche Dimension wird AM STÄRKSTEN adressiert?

❌ 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 Informationsfluss“ = Wertströ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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Incident wird technisch schnell gelöst, aber die Übergaben zwischen Service Desk, Betriebsteam und Produktteam erzeugen Verzögerungen. Das Team stellt den tatsächlichen Arbeits- und Informationsfluss dar. Welche Dimension wird AM STÄRKSTEN adressiert?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Incident wird technisch schnell gelöst, aber die Übergaben zwischen Service Desk, Betriebsteam und Produktteam erzeugen Verzögerungen. Das Team stellt den tatsächlichen Arbeits- und Informationsfluss dar. Welche Dimension wird AM STÄRKSTEN adressiert?

✅ 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 „Wertströ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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Incident wird technisch schnell gelöst, aber die Übergaben zwischen Service Desk, Betriebsteam und Produktteam erzeugen Verzögerungen. Das Team stellt den tatsächlichen Arbeits- und Informationsfluss dar. Welche primäre Dimension wird AM STÄRKSTEN adressiert?

❌ 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 Unterseite →

☝️ Single Welches Modell wird häufig genutzt, um externe Einflussfaktoren auf alle 4 Dimensionen zu betrachten?

✅ 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 Unterseite →

☝️ Single Warum betrachtet ITIL die 4 Dimensionen bewusst gemeinsam statt isoliert?

✅ 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 Unterseite →

☝️ Single Ein Unternehmen lagert seinen Service Desk komplett an einen externen Anbieter aus. Welche Dimension steht dabei im Vordergrund?

✅ 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 Unterseite →

☝️ Single Ein Unternehmen führt ein neues Kompetenzmodell und Weiterbildungsprogramm ein. Welche Dimension betrifft das primär?

✅ 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 Unterseite →

☝️ Single Was passiert, wenn eine Organisation z.B. neue Technologie einführt (Dimension Information & Technologie), ohne die Mitarbeitenden zu schulen (Dimension Organisationen & Menschen)?

✅ 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 Unterseite →

✌️ Multi Ordne zu: Welche Aussagen beschreiben korrekt eine der 4 Dimensionen? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Nenne für zwei der sechs PESTLE-Faktoren je ein Beispiel, wie sie eine der 4 Dimensionen beeinflussen könnten.

Dimensionen im Alltag [Dimensionen] 1 Unterseite →

✍️ Offen Beschreibe an einem selbst gewählten Beispiel aus deinem Arbeitsumfeld, wie alle 4 Dimensionen bei der Einführung eines neuen Services zusammenspielen müssten.

Kompetenzen [Dimensionen] 1 Unterseite →

☝️ Single In welche Dimension fällt der Aufbau spezifischer fachlicher Kompetenzen im Team?

✅ 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 Unterseite →

☝️ Single Welche Dimension steht im Vordergrund, wenn eine Organisation zwischen Eigenentwicklung und externer Beschaffung (Sourcing) entscheidet?

✅ 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 Unterseite →

☝️ Single In welche Dimension fällt die Sicherstellung guter Datenqualität für Entscheidungsfindung?

✅ 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 Unterseite →

☝️ Single Welche Dimension deckt Kontrollen und Workflows als Steuerungsinstrumente ab?

✅ 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 Unterseite →

☝️ Single In welcher Dimension wird die konkrete Vertragsgestaltung mit einem externen Anbieter behandelt?

✅ 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 Unterseite →

☝️ Single Welcher PESTLE-Faktor betrifft am direktesten die Dimension Informationen und Technologie?

✅ Technologisch

❌ Politisch

❌ Sozial

❌ Rechtlich

Der technologische Faktor (T in PESTLE) betrifft direkt Technologieentscheidungen.

Kulturwandel [Dimensionen] 1 Unterseite →

☝️ Single Ein Unternehmen möchte eine offenere Fehlerkultur etablieren. Welche Dimension ist primär betroffen?

✅ Organisationen und Menschen

❌ Wertströme und Prozesse

❌ Informationen und Technologie

❌ Partner und Lieferanten

Kulturfragen fallen unter Organisationen und Menschen.

Balance der Dimensionen [Dimensionen] 1 Unterseite →

☝️ Single Warum reicht es laut ITIL nicht aus, nur eine der vier Dimensionen zu optimieren?

✅ 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 Unterseite →

✌️ Multi Welche vier Begriffe entsprechen exakt den offiziellen vier Dimensionen? (Mehrfachauswahl — wähle alle vier)

✅ 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 Unterseite →

✍️ Offen Nenne für dein Unternehmen (oder ein fiktives Beispiel) je einen politischen und einen sozialen Einflussfaktor und ordne sie einer Dimension zu.

Übung [Dimensionen] 22 Unterseite →

☝️ Single Welche Dimension betrifft die Daten und Technologien, die zur Bereitstellung digitaler Produkte und Services genutzt werden?

❌ Partner und Lieferanten

❌ Wertströme und Prozesse

❌ Organisationen und Menschen

✅ Information und Technologie

Die Dimension 'Information und Technologie' umfasst Daten, Informationen und Technologien.

☝️ Single Welche Dimension befasst sich mit den Beziehungen zu externen Organisationen?

✅ Partner und Lieferanten

❌ Information und Technologie

❌ Organisationen und Menschen

❌ Wertströme und Prozesse

Die Dimension 'Partner und Lieferanten' betrifft externe Beziehungen und Verträge.

☝️ Single Führungskräfte fördern psychologische Sicherheit und kontinuierliches Lernen. Welche Dimension wird dadurch direkt beeinflusst?

❌ 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.

☝️ Single Warum sind 'Wertströme und Prozesse' als Dimension wichtig?

❌ 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.

☝️ Single Wozu dienen externe Faktoren (z. B. politisch, wirtschaftlich, rechtlich) im Modell der vier Dimensionen?

❌ 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.

☝️ Single Welche Dimension stellt sicher, dass die richtigen Fähigkeiten, Kultur und Kommunikation vorhanden sind?

❌ 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'.

☝️ Single Welche Option beschreibt „vier Dimensionen des Produkt- und Servicemanagements von ITIL“ AM BESTEN?

✅ 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.

☝️ Single Warum sollten die vier Dimensionen gemeinsam betrachtet werden?

✅ 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.

☝️ Single Welche Dimension adressiert Rollen, Verantwortlichkeiten, Kompetenzen und Kommunikationssysteme?

❌ 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.

☝️ Single Welche externen Faktoren werden mit PESTLE zusammengefasst?

✅ 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.

☝️ Single Welche Dimension konzentriert sich auf Workflows und organisierte Aktivitäten?

❌ 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.

☝️ Single Welche Aussage passt zur Dimension „Informationen und Technologie“?

✅ 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.

☝️ Single Welche Aussage beschreibt Kultur in der Dimension „Organisationen und Menschen“?

❌ 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.

☝️ Single Welche Aussage beschreibt den ganzheitlichen Ansatz der vier Dimensionen?

❌ 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.

☝️ Single Welche Aussage passt zu „Partner und Lieferanten“?

❌ 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.

☝️ Single Welche Aussage passt zu KI in „Informationen und Technologie“?

✅ 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.

☝️ Single Was ist ein Prozess?

✅ 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.

☝️ Single Wie stehen Management-Practices und Aktivitäten der Wertschöpfungskette zueinander?

✅ 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.

☝️ Single Welche Aussage zu „Wertströme und Prozesse“ ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu externen Faktoren ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu „Organisationen und Menschen“ ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu ganzheitlichem Produkt- und Servicemanagement ist KORREKT?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Team will ein neues Self-Service-Portal ausschließlich durch eine neue Plattform verbessern. Im Review zeigt sich, dass Rollen, Lieferantenverträge, Datenqualität und Support-Workflows ebenfalls angepasst werden müssen. Welche Aussage entspricht ITIL AM BESTEN?

✅ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Team will ein neues Self-Service-Portal ausschließlich durch eine neue Plattform verbessern. Im Review zeigt sich, dass Rollen, Lieferantenverträge, Datenqualität und Support-Workflows ebenfalls angepasst werden müssen. Welche Aussage entspricht ITIL AM BESTEN?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Team will ein neues Self-Service-Portal ausschließlich durch eine neue Plattform verbessern. Im Review zeigt sich, dass Rollen, Lieferantenverträge, Datenqualität und Support-Workflows ebenfalls angepasst werden müssen. Welche Aussage entspricht ITIL AM BESTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Team will ein neues Self-Service-Portal ausschließlich durch eine neue Plattform verbessern. Im Review zeigt sich, dass Rollen, Lieferantenverträge, Datenqualität und Support-Workflows ebenfalls angepasst werden müssen. Welche Aussage entspricht ITIL AM BESTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Neue Datenschutzanforderungen, veränderte Kundenerwartungen und steigende Cloud-Kosten beeinflussen zugleich Architektur, Lieferantenverträge, Workflows und Kompetenzen. Welche Aussage ist AM BESTEN?

❌ 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..

☝️ Single Fallkontext Klinikverbund: In diesem Umfeld beschreibt ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Neue Datenschutzanforderungen, veränderte Kundenerwartungen und steigende Cloud-Kosten beeinflussen zugleich Architektur, Lieferantenverträge, Workflows und Kompetenzen. Welche Aussage ist AM BESTEN?

✅ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Neue Datenschutzanforderungen, veränderte Kundenerwartungen und steigende Cloud-Kosten beeinflussen zugleich Architektur, Lieferantenverträge, Workflows und Kompetenzen. Welche Aussage ist AM BESTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: In diesem Umfeld beschreibt ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Neue Datenschutzanforderungen, veränderte Kundenerwartungen und steigende Cloud-Kosten beeinflussen zugleich Architektur, Lieferantenverträge, Workflows und Kompetenzen. Welche Aussage ist AM BESTEN?

❌ 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.

ITIL Value System

Komponenten Übersicht [Value System] 1 Unterseite →

☝️ Single Welche Option listet die Komponenten des ITIL Value System KORREKT auf?

✅ 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 Unterseite →

☝️ Single Was fordert das Grundprinzip "Fokus auf Wert"?

✅ 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 Unterseite →

☝️ Single Was bedeutet das Grundprinzip "Dort anfangen, wo man steht"?

✅ 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 Unterseite →

☝️ Single Was fordert "Progress iteratively with feedback"?

✅ 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 Unterseite →

☝️ Single Worum geht es beim Grundprinzip "Zusammenarbeit und Sichtbarkeit fördern"?

✅ 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 Unterseite →

☝️ Single Was fordert "Think and work holistically"?

✅ 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 Unterseite →

☝️ Single Was bedeutet "Keep it simple and practical"?

✅ 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 Unterseite →

☝️ Single In welcher Reihenfolge sollte laut ITIL bei "Optimize and automate" vorgegangen werden?

✅ 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 Unterseite →

☝️ Single Wie viele ITIL-Grundprinzipien (Guiding Principles) gibt es?

✅ 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 Unterseite →

☝️ Single Welche drei Kernaktivitäten umfasst Governance im ITIL-Value-System typischerweise?

✅ 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 Unterseite →

☝️ Single Wie definiert ITIL eine "Practice" (Management-Practice)?

✅ 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 Unterseite →

☝️ Single Wurden die 34 aus ITIL 4 bekannten Management-Practices in Version 5 abgeschafft?

✅ 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 Unterseite →

☝️ Single Warum ist "Continual Improvement" laut ITIL kein einmaliges Projekt?

✅ 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 Unterseite →

☝️ Single Mit welcher Frage beginnt das Continual Improvement Model typischerweise?

✅ 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 Unterseite →

☝️ Single Was bedeutet der "ganzheitliche Ansatz" im Kontext des Value Systems?

✅ 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 Unterseite →

☝️ Single Welches Werkzeug wird typischerweise genutzt, um externe Einflussfaktoren auf das Value System zu strukturieren?

✅ 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 Unterseite →

☝️ Single Was bedeutet "Wertorientierung" als Grundhaltung hinter den Guiding Principles?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Produktteam priorisiert Features nicht nach interner Begeisterung, sondern danach, ob sie reale Anwenderprobleme lösen, gewünschte Ergebnisse unterstützen und langfristig Nutzen für Kunden sowie Provider schaffen. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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.

☝️ Single Fallkontext Klinikverbund: In diesem Umfeld beschreibt ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Produktteam priorisiert Features nicht nach interner Begeisterung, sondern danach, ob sie reale Anwenderprobleme lösen, gewünschte Ergebnisse unterstützen und langfristig Nutzen für Kunden sowie Provider schaffen. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. In diesem Umfeld beschreibt ein Produktteam priorisiert Features nicht nach interner Begeisterung, sondern danach, ob sie reale Anwenderprobleme lösen, gewünschte Ergebnisse unterstützen und langfristig Nutzen für Kunden sowie Provider schaffen. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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.

☝️ Single Fallkontext Handelslogistik: In diesem Umfeld beschreibt ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Produktteam priorisiert Features nicht nach interner Begeisterung, sondern danach, ob sie reale Anwenderprobleme lösen, gewünschte Ergebnisse unterstützen und langfristig Nutzen für Kunden sowie Provider schaffen. Welche primäres ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

✅ 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 Unterseite →

☝️ Single Was ist unter "Servicebetrieb" im Rahmen des Value Systems zu verstehen?

✅ 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 Unterseite →

☝️ Single Was ist der Zweck eines "Release" im Servicebetrieb?

✅ 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 Unterseite →

☝️ Single Was unterscheidet Problemmanagement grundsätzlich von der Behebung eines einzelnen Vorfalls?

✅ 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 Unterseite →

☝️ Single Wofür werden Messgrößen (Metriken) im Value System benötigt?

✅ 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 Unterseite →

☝️ Single Was ist ein "Critical Success Factor" (CSF)?

✅ 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 Unterseite →

☝️ Single Wie hängen KPI und CSF zusammen?

✅ 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 Unterseite →

☝️ Single Wo im Value System bzw. Lebenszyklus verortet sich klassisches Projektmanagement typischerweise?

✅ 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 Unterseite →

☝️ Single Was beschreibt das "Betriebsmodell" im Kontext des Value Systems?

✅ 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 Unterseite →

✌️ Multi Welche der folgenden sind tatsächlich Guiding Principles? (Mehrfachauswahl)

✅ 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 Unterseite →

✌️ Multi Welche Aktivitäten gehören zum Governance-Zyklus Evaluate-Direct-Monitor? (Mehrfachauswahl)

✅ 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 Unterseite →

✌️ Multi Welche drei Kategorien von Management-Practices wurden aus ITIL 4 übernommen? (Mehrfachauswahl)

✅ 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 Unterseite →

✌️ Multi Welche gehören zu den Komponenten des ITIL Value Systems? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Zwei Grundprinzipien können in einer konkreten Situation im Spannungsverhältnis stehen — z.B. "Keep it simple" und "Think and work holistically". Beschreibe an einem Beispiel, wie man damit umgehen könnte.

Governance in der Praxis [Value System] 1 Unterseite →

✍️ Offen Erkläre an einem Beispiel aus der Praxis, wie sich Evaluate, Direct und Monitor konkret unterscheiden.

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 Unterseite →

✍️ Offen Skizziere anhand eines selbst gewählten Beispiels alle Schritte des Continual Improvement Model, von der Vision bis zur Erfolgskontrolle.

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 Unterseite →

✍️ Offen Formuliere für einen frei gewählten Service einen CSF und zwei passende KPIs.

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 Unterseite →

☝️ Single Was unterscheidet eine "Practice" von einem einzelnen "Prozess"?

✅ 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 Unterseite →

☝️ Single Welche Art von Themen deckt die Kategorie "General Management Practices" typischerweise ab?

✅ 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 Unterseite →

☝️ Single Welche Art von Themen deckt die Kategorie "Service Management Practices" ab?

✅ 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 Unterseite →

☝️ Single Welche Art von Themen deckt die Kategorie "Technical Management Practices" ab?

✅ 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 Unterseite →

☝️ Single Wie sollten die 7 Grundprinzipien laut ITIL idealerweise angewendet werden?

✅ 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 Unterseite →

☝️ Single Wie unterscheidet sich Governance grundsätzlich von operativem Management?

✅ 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 Unterseite →

☝️ Single Welches der folgenden ist ein plausibles Beispiel für einen CSF?

✅ 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 Unterseite →

☝️ Single Welches der folgenden ist ein plausibler KPI für den CSF "hohe Kundenzufriedenheit"?

✅ 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 Unterseite →

☝️ Single Was ist die Kernidee hinter "Change Enablement"?

✅ Ä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 Unterseite →

☝️ Single Was zeichnet eine "Standard-Änderung" typischerweise aus?

✅ 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 Unterseite →

☝️ Single Wie sollte Continual Improvement laut ITIL organisatorisch verankert sein?

✅ 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 Unterseite →

☝️ Single Warum ist es riskant, nur eine einzelne Messgröße zur Erfolgsbewertung zu nutzen?

✅ 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 Unterseite →

☝️ Single Wie hängen Releases und der laufende Servicebetrieb zusammen?

✅ 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 Unterseite →

☝️ Single Warum wird Projektmanagement im ITIL-Kontext eher als unterstützende Disziplin denn als eigenständiges Rahmenwerk behandelt?

✅ 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 Unterseite →

☝️ Single Ein Team veröffentlicht eine kleine Funktion, sammelt Nutzerfeedback und passt danach an. Welches Grundprinzip zeigt sich hier am deutlichsten?

✅ 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 Unterseite →

☝️ Single Ein Team nutzt eine bestehende, bewährte Vorlage statt bei null anzufangen. Welches Grundprinzip zeigt sich hier?

✅ 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 Unterseite →

✌️ Multi Welche Aussagen zu Critical Success Factors treffen zu? (Mehrfachauswahl)

✅ 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 Unterseite →

✌️ Multi Welche Aussagen zu Change Enablement treffen zu? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Formuliere für die Practice "Incident Management" einen sinnvollen CSF und einen passenden KPI.

Governance vs. Management eigenständig [Value System] 1 Unterseite →

✍️ Offen Erkläre in eigenen Worten, warum eine Organisation sowohl Governance als auch operatives Management braucht, und was passiert, wenn eines davon fehlt.

Practice-Kategorie zuordnen [Value System] 1 Unterseite →

✍️ Offen Ordne die Practice "Supplier Management" einer der drei Kategorien (General/Service/Technical Management Practices) zu und begründe kurz.

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 Unterseite →

✍️ Offen Beschreibe eine konkrete kleine Verbesserung, die dein Team/deine Organisation kürzlich umgesetzt hat, und ordne sie den Schritten des Continual Improvement Model zu.

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 Unterseite →

☝️ Single Was beschreibt der Begriff "Wertschöpfungskette" im Value-System-Kontext?

✅ 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 Unterseite →

☝️ Single Welches Beispiel zeigt am ehesten eine Betriebsmodell-Entscheidung?

✅ 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 Unterseite →

☝️ Single Welche Rolle spielt ein Leitungsorgan (Governing Body) in einer Organisation?

✅ 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 Unterseite →

☝️ Single Wie hängen "Zweck der Organisation" und "Betriebsmodell" AM BESTEN zusammen?

✅ 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 Unterseite →

☝️ Single Welche Option beschreibt „Event“ AM BESTEN?

✅ 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 Unterseite →

☝️ Single Welche Option beschreibt „Service Request“ AM BESTEN?

✅ 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 Unterseite →

☝️ Single Welche Option beschreibt „Known Error“ AM BESTEN?

❌ 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 Unterseite →

☝️ Single Welche Option beschreibt „Katastrophe“ AM BESTEN?

❌ 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 Unterseite →

☝️ Single Welche Bestandteile bilden zusammen das ITIL Value System?

❌ 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.

☝️ Single Statt ein Jahr an einer Komplettlösung zu arbeiten, veröffentlicht ein Team monatlich kleine, nutzbare Zwischenstände und passt danach an. Welches Grundprinzip wird angewandt?

❌ 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'.

☝️ Single Wie ist das Grundprinzip 'Optimieren und automatisieren' korrekt anzuwenden?

❌ 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.

☝️ Single Was ist das Hauptrisiko, wenn man eine Verbesserung komplett neu beginnt, ohne Vorhandenes zu berücksichtigen?

✅ 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.

☝️ Single Worauf sollen laut dem Grundprinzip 'Auf Wert fokussieren' alle organisatorischen Aktivitäten zurückführbar sein?

❌ 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.

☝️ Single Ein Team versucht, in einem neuen Ablauf jede denkbare Ausnahme im Voraus abzudecken. Welches Risiko entsteht dabei vor allem?

❌ 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.

☝️ Single Welche Governance-Aktivität umfasst das Überwachen der Leistung und der Einhaltung von Vorgaben?

❌ Bewerten (Evaluate)

❌ Ausrichten (Direct)

✅ Überwachen (Monitor)

❌ Entdecken (Discover)

Governance besteht aus Bewerten, Ausrichten und Überwachen; das Monitoring prüft Leistung und Konformität.

☝️ Single Was ist eine Management-Practice?

❌ 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.

☝️ Single Womit beginnt das ITIL Continual Improvement Model typischerweise?

❌ 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.

☝️ Single Ein Unternehmen erhebt zunächst den Ist-Zustand mit Kennzahlen, bevor es Verbesserungsmaßnahmen plant. Welcher Schritt des Continual Improvement Model ist das?

❌ 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?'.

☝️ Single Warum sind Management-Practices für die Aktivitäten der Wertschöpfungskette wichtig?

❌ 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.

☝️ Single Wie tragen die Aktivitäten der Wertschöpfungskette zum Zweck einer Organisation bei?

✅ 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.

☝️ Single Wie sollen die ITIL-Grundprinzipien gemeinsam angewandt werden?

❌ 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.

☝️ Single Was betont das Grundprinzip 'Ganzheitlich denken und arbeiten'?

❌ 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.

☝️ Single Wie wird das Grundprinzip 'Zusammenarbeiten und Sichtbarkeit fördern' korrekt angewandt?

✅ 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.

☝️ Single Welche Governance-Aktivität weist Verantwortlichkeiten zu und gibt Richtung sowie Richtlinien vor?

❌ 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.

☝️ Single Welche Governance-Aktivität bewertet die Organisation, ihre Strategie und Portfolios?

✅ 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).

☝️ Single Welcher Schritt des Continual Improvement Model beantwortet die Frage 'Wohin wollen wir?'

✅ 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.

☝️ Single Warum folgen die ITIL Official Practice Guides einer einheitlichen Struktur über alle Practices hinweg?

✅ 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.

☝️ Single Was ist der Zweck der Practice 'Incident Management'?

❌ 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.

☝️ Single Was ist der Zweck der Practice 'Problem Management'?

❌ 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.

☝️ Single Was ist der Zweck der Practice 'Change Enablement'?

✅ 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.

☝️ Single Welche Practice bildet den zentralen Kommunikationspunkt zwischen Anbieter und Anwendern?

❌ 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.

☝️ Single Was ist das Ziel der Practice 'Service Level Management'?

❌ 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.

☝️ Single Was ist der Zweck der Practice 'Information Security Management'?

✅ 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.

☝️ Single Worin unterscheiden sich die Practices 'Deployment Management' und 'Release Management'?

✅ 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.

☝️ Single Was ist der Zweck der Practice 'Supplier Management'?

✅ 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.

☝️ Single Welche Option beschreibt „ITIL Value System (ITIL VS)“ AM BESTEN?

❌ 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.

☝️ Single Welche Komponenten gehören zum ITIL Value System?

❌ 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.

☝️ Single Was fordert das Grundprinzip „Wertorientierung“?

✅ 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.

☝️ Single Was bedeutet „Dort beginnen, wo man steht“?

❌ 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.

☝️ Single Was ist bei „Iterative Weiterentwicklung mit Feedback“ zentral?

✅ 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.

☝️ Single Was unterstützt „Zusammenarbeiten und Transparenz fördern“?

❌ 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.

☝️ Single Welche Option beschreibt „Governance“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Wertschöpfungskette“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Produktspezifikation“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Produktprototyp“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Incident“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Continuous Integration“ AM BESTEN?

❌ 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).

☝️ Single Welche Option beschreibt „Continuous Delivery“ AM BESTEN?

❌ 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.

☝️ Single Was beschreibt die befähigende Natur von Governance AM BESTEN?

❌ 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.

☝️ Single Was verlangt „Ganzheitlich denken und arbeiten“?

❌ 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.

☝️ Single Was verlangt „Auf Einfachheit und Praktikabilität achten“?

❌ 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.

☝️ Single Was verlangt „Optimieren und automatisieren“?

❌ 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.

☝️ Single Wie wirken ITIL Grundprinzipien zusammen?

❌ 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.

☝️ Single Welche Option beschreibt „Release“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Test“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Continuous Deployment“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Zuverlässigkeit“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Site Reliability Engineering (SRE)“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Observability (Beobachtbarkeit)“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Problem“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Fehler“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Betriebsmodell“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Management-Practice“ AM BESTEN?

❌ 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.

☝️ Single Welche Aussage beschreibt den Zweck des ITIL VS AM BESTEN?

❌ 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.

☝️ Single Welche Aussage passt zu Management-Practice-Gruppen?

❌ 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.

☝️ Single Welche Rolle haben Management-Practices im ITIL Value System?

❌ 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.

☝️ Single Welchen Nutzen haben ITIL Practice-Leitfäden?

❌ 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.

☝️ Single Welche Option beschreibt „Messgröße“ AM BESTEN?

❌ 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).

☝️ Single Welche Option beschreibt „Kritischer Erfolgsfaktor (CSF)“ AM BESTEN?

❌ 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.

☝️ Single Welcher Schritt des Continual Improvement Models fragt „Was ist unsere Vision?“

✅ 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.

☝️ Single Welcher Schritt des Continual Improvement Models fragt „Wo stehen wir jetzt?“

❌ Schritt 4

❌ Schritt 6

✅ Schritt 2

❌ Schritt 1

Schritt 2 bewertet den Ist-Zustand.

☝️ Single Welcher Schritt des Continual Improvement Models fragt „Wo wollen wir hin?“

✅ 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?“).

☝️ Single Welcher Schritt des Continual Improvement Models fragt „Wie kommen wir dorthin?“

❌ 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: 4x4 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.

☝️ Single Welcher Schritt des Continual Improvement Models heißt „Maßnahmen ergreifen“?

❌ 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.

☝️ Single Welcher Schritt des Continual Improvement Models fragt „Kommen wir voran?“

❌ 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.

☝️ Single Welcher Schritt des Continual Improvement Models fragt, wie Verbesserungen relevant bleiben?

❌ 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.

☝️ Single Warum sollten Verbesserungen mit der Vision verknüpft werden?

❌ 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.

☝️ Single Warum ist die Bewertung des Ist-Zustands wichtig?

❌ 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.

☝️ Single Warum muss während der Umsetzung Offenheit für Veränderung bestehen?

✅ 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.

☝️ Single Welche Aussage zu Wertschöpfungskette und Betriebsmodell ist KORREKT?

✅ 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).

☝️ Single Welche Aussage zu Aktivitäten der Wertschöpfungskette ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Incident und Problem ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Problem, Fehler und Known Error ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Continuous Delivery und Continuous Deployment ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu SRE und Observability ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Service Request ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu einem Betriebsmodell ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Practice-Leitfäden ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu CSF und KPI ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zur Reihenfolge des Continual Improvement Models ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu „Maßnahmen ergreifen“ ist KORREKT?

✅ 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.

☝️ Single Welche Aussage zu „Kommen wir voran?“ ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu „Wie stellen wir sicher, dass die Verbesserungen relevant bleiben?“ ist KORREKT?

✅ 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.

☝️ Single Welche Aussage zu ITIL Grundprinzipien im ITIL VS ist KORREKT?

✅ 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.

☝️ Single Welche Aussage zur Anpassungsfähigkeit des ITIL VS ist KORREKT?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Vor einer Restrukturierung der Support-Workflows prüft ein Team vorhandene Messdaten, bestehende Tools, funktionierende informelle Übergaben und bekannte Einschränkungen, statt sofort ein neues Modell einzuführen. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Vor einer Restrukturierung der Support-Workflows prüft ein Team vorhandene Messdaten, bestehende Tools, funktionierende informelle Übergaben und bekannte Einschränkungen, statt sofort ein neues Modell einzuführen. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Vor einer Restrukturierung der Support-Workflows prüft ein Team vorhandene Messdaten, bestehende Tools, funktionierende informelle Übergaben und bekannte Einschränkungen, statt sofort ein neues Modell einzuführen. Welches ITIL Grundprinzip wird in diesem Szenario am präzisesten angewendet?

✅ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Vor einer Restrukturierung der Support-Workflows prüft ein Team vorhandene Messdaten, bestehende Tools, funktionierende informelle Übergaben und bekannte Einschränkungen, statt sofort ein neues Modell einzuführen. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Portal wird in kleinen Verbesserungszyklen erweitert. Nach jeder Änderung werden Nutzungsdaten, Supportkontakte und Stakeholderfeedback bewertet, bevor der nächste Schritt festgelegt wird. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Portal wird in kleinen Verbesserungszyklen erweitert. Nach jeder Änderung werden Nutzungsdaten, Supportkontakte und Stakeholderfeedback bewertet, bevor der nächste Schritt festgelegt wird. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

✅ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Portal wird in kleinen Verbesserungszyklen erweitert. Nach jeder Änderung werden Nutzungsdaten, Supportkontakte und Stakeholderfeedback bewertet, bevor der nächste Schritt festgelegt wird. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Portal wird in kleinen Verbesserungszyklen erweitert. Nach jeder Änderung werden Nutzungsdaten, Supportkontakte und Stakeholderfeedback bewertet, bevor der nächste Schritt festgelegt wird. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Release scheitert mehrfach an Missverständnissen zwischen Produktteam, Betrieb, Service Desk und Lieferant. Das Team macht Arbeit, Risiken und Entscheidungen sichtbar und bindet relevante Stakeholder früh ein. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

✅ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Release scheitert mehrfach an Missverständnissen zwischen Produktteam, Betrieb, Service Desk und Lieferant. Das Team macht Arbeit, Risiken und Entscheidungen sichtbar und bindet relevante Stakeholder früh ein. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Release scheitert mehrfach an Missverständnissen zwischen Produktteam, Betrieb, Service Desk und Lieferant. Das Team macht Arbeit, Risiken und Entscheidungen sichtbar und bindet relevante Stakeholder früh ein. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Release scheitert mehrfach an Missverständnissen zwischen Produktteam, Betrieb, Service Desk und Lieferant. Das Team macht Arbeit, Risiken und Entscheidungen sichtbar und bindet relevante Stakeholder früh ein. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Eine Verbesserung der Incident-Lösung wird nicht nur als Toolwechsel geplant. Das Team betrachtet Rollen, Daten, Lieferanten, Workflows, Monitoring, Wissensartikel und Auswirkungen auf Konsumenten gemeinsam. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Eine Verbesserung der Incident-Lösung wird nicht nur als Toolwechsel geplant. Das Team betrachtet Rollen, Daten, Lieferanten, Workflows, Monitoring, Wissensartikel und Auswirkungen auf Konsumenten gemeinsam. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Eine Verbesserung der Incident-Lösung wird nicht nur als Toolwechsel geplant. Das Team betrachtet Rollen, Daten, Lieferanten, Workflows, Monitoring, Wissensartikel und Auswirkungen auf Konsumenten gemeinsam. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Eine Verbesserung der Incident-Lösung wird nicht nur als Toolwechsel geplant. Das Team betrachtet Rollen, Daten, Lieferanten, Workflows, Monitoring, Wissensartikel und Auswirkungen auf Konsumenten gemeinsam. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

✅ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Team entfernt Genehmigungsschritte, die keine Risiken reduzieren und keine Stakeholder-Entscheidung unterstützen. Übrig bleiben nur Kontrollen, die für Wert, Sicherheit oder Compliance notwendig sind. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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..

☝️ Single Fallkontext Klinikverbund: In diesem Umfeld beschreibt ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Team entfernt Genehmigungsschritte, die keine Risiken reduzieren und keine Stakeholder-Entscheidung unterstützen. Übrig bleiben nur Kontrollen, die für Wert, Sicherheit oder Compliance notwendig sind. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. In diesem Umfeld beschreibt ein Team entfernt Genehmigungsschritte, die keine Risiken reduzieren und keine Stakeholder-Entscheidung unterstützen. Übrig bleiben nur Kontrollen, die für Wert, Sicherheit oder Compliance notwendig sind. Welches ITIL Grundprinzip wird in diesem Szenario am präzisesten angewendet?

✅ 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.

☝️ Single Fallkontext Handelslogistik: In diesem Umfeld beschreibt ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Team entfernt Genehmigungsschritte, die keine Risiken reduzieren und keine Stakeholder-Entscheidung unterstützen. Übrig bleiben nur Kontrollen, die für Wert, Sicherheit oder Compliance notwendig sind. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Vor der Automatisierung der Service-Request-Erfüllung analysiert ein Team Varianten, entfernt unnötige Schritte, standardisiert Eingaben und automatisiert erst danach wiederkehrende Aufgaben. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Vor der Automatisierung der Service-Request-Erfüllung analysiert ein Team Varianten, entfernt unnötige Schritte, standardisiert Eingaben und automatisiert erst danach wiederkehrende Aufgaben. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

✅ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Vor der Automatisierung der Service-Request-Erfüllung analysiert ein Team Varianten, entfernt unnötige Schritte, standardisiert Eingaben und automatisiert erst danach wiederkehrende Aufgaben. Welches ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Vor der Automatisierung der Service-Request-Erfüllung analysiert ein Team Varianten, entfernt unnötige Schritte, standardisiert Eingaben und automatisiert erst danach wiederkehrende Aufgaben. Welche primäres ITIL Grundprinzip wird in diesem Szenario AM BESTEN angewendet?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Team arbeitet mit internen und externen Stakeholdern, um Bedürfnisse, Anforderungen, Einschränkungen und Akzeptanzkriterien für einen möglichen digitalen Service zu verstehen. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Team arbeitet mit internen und externen Stakeholdern, um Bedürfnisse, Anforderungen, Einschränkungen und Akzeptanzkriterien für einen möglichen digitalen Service zu verstehen. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Team arbeitet mit internen und externen Stakeholdern, um Bedürfnisse, Anforderungen, Einschränkungen und Akzeptanzkriterien für einen möglichen digitalen Service zu verstehen. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

✅ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Team arbeitet mit internen und externen Stakeholdern, um Bedürfnisse, Anforderungen, Einschränkungen und Akzeptanzkriterien für einen möglichen digitalen Service zu verstehen. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Für ein neues Produkt werden Cloud-Services und externe Software benötigt. Das Team bewertet Anbieter, verhandelt Vereinbarungen und plant die laufende Zusammenarbeit. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Für ein neues Produkt werden Cloud-Services und externe Software benötigt. Das Team bewertet Anbieter, verhandelt Vereinbarungen und plant die laufende Zusammenarbeit. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

✅ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Für ein neues Produkt werden Cloud-Services und externe Software benötigt. Das Team bewertet Anbieter, verhandelt Vereinbarungen und plant die laufende Zusammenarbeit. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Für ein neues Produkt werden Cloud-Services und externe Software benötigt. Das Team bewertet Anbieter, verhandelt Vereinbarungen und plant die laufende Zusammenarbeit. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Produktteam erstellt neue Funktionen, integriert Code häufig, führt automatisierte Builds und Tests aus und behebt Defekte vor der Übergabe an Release und Deployment. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

✅ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Produktteam erstellt neue Funktionen, integriert Code häufig, führt automatisierte Builds und Tests aus und behebt Defekte vor der Übergabe an Release und Deployment. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Produktteam erstellt neue Funktionen, integriert Code häufig, führt automatisierte Builds und Tests aus und behebt Defekte vor der Übergabe an Release und Deployment. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Produktteam erstellt neue Funktionen, integriert Code häufig, führt automatisierte Builds und Tests aus und behebt Defekte vor der Übergabe an Release und Deployment. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Team drückt nach bestandenen Tests kontrolliert den Auslöser, der ein Release in die Live-Umgebung überführt. Die Entscheidung zur Freigabe wurde zuvor getroffen. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext Klinikverbund: In diesem Umfeld beschreibt ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Team drückt nach bestandenen Tests kontrolliert den Auslöser, der ein Release in die Live-Umgebung überführt. Die Entscheidung zur Freigabe wurde zuvor getroffen. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. In diesem Umfeld beschreibt ein Team drückt nach bestandenen Tests kontrolliert den Auslöser, der ein Release in die Live-Umgebung überführt. Die Entscheidung zur Freigabe wurde zuvor getroffen. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext Handelslogistik: In diesem Umfeld beschreibt ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Team drückt nach bestandenen Tests kontrolliert den Auslöser, der ein Release in die Live-Umgebung überführt. Die Entscheidung zur Freigabe wurde zuvor getroffen. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

✅ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Team kann Softwareupdates jederzeit in Produktion überführen. Häufige Deployments sind möglich, aber jede produktive Bereitstellung wird fallweise entschieden. Welcher Begriff passt AM BESTEN?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Team kann Softwareupdates jederzeit in Produktion überführen. Häufige Deployments sind möglich, aber jede produktive Bereitstellung wird fallweise entschieden. Welcher Begriff passt AM BESTEN?

✅ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Team kann Softwareupdates jederzeit in Produktion überführen. Häufige Deployments sind möglich, aber jede produktive Bereitstellung wird fallweise entschieden. Welcher Begriff passt AM BESTEN?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Team kann Softwareupdates jederzeit in Produktion überführen. Häufige Deployments sind möglich, aber jede produktive Bereitstellung wird fallweise entschieden. Welcher Begriff passt AM BESTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Betriebsteam beobachtet Metriken, Protokolle und Events, erkennt Anomalien früh und löst Eskalationen aus, bevor Anwender breit betroffen sind. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Betriebsteam beobachtet Metriken, Protokolle und Events, erkennt Anomalien früh und löst Eskalationen aus, bevor Anwender breit betroffen sind. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

✅ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Betriebsteam beobachtet Metriken, Protokolle und Events, erkennt Anomalien früh und löst Eskalationen aus, bevor Anwender breit betroffen sind. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Betriebsteam beobachtet Metriken, Protokolle und Events, erkennt Anomalien früh und löst Eskalationen aus, bevor Anwender breit betroffen sind. Welche primäre Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Mehrere Incidents wurden vorübergehend gelöst. Nun analysiert ein Team wiederkehrende Muster, identifiziert eine zugrunde liegende Ursache und dokumentiert einen Known Error mit Workaround. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

✅ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Mehrere Incidents wurden vorübergehend gelöst. Nun analysiert ein Team wiederkehrende Muster, identifiziert eine zugrunde liegende Ursache und dokumentiert einen Known Error mit Workaround. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Mehrere Incidents wurden vorübergehend gelöst. Nun analysiert ein Team wiederkehrende Muster, identifiziert eine zugrunde liegende Ursache und dokumentiert einen Known Error mit Workaround. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Mehrere Incidents wurden vorübergehend gelöst. Nun analysiert ein Team wiederkehrende Muster, identifiziert eine zugrunde liegende Ursache und dokumentiert einen Known Error mit Workaround. Welche Management-Practice ermöglicht diese Arbeit AM DEUTLICHSTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Eine Organisation möchte wissen, welcher Teil eines Practice-Leitfadens Empfehlungen zur Automatisierung, Tooling und praktischen Anwendung der Practice enthält. Welche Antwort ist AM BESTEN?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Eine Organisation möchte wissen, welcher Teil eines Practice-Leitfadens Empfehlungen zur Automatisierung, Tooling und praktischen Anwendung der Practice enthält. Welche Antwort ist AM BESTEN?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Eine Organisation möchte wissen, welcher Teil eines Practice-Leitfadens Empfehlungen zur Automatisierung, Tooling und praktischen Anwendung der Practice enthält. Welche Antwort ist AM BESTEN?

✅ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Eine Organisation möchte wissen, welcher Teil eines Practice-Leitfadens Empfehlungen zur Automatisierung, Tooling und praktischen Anwendung der Practice enthält. Welche Antwort ist AM BESTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Leitungsgremium legt Entscheidungsrechte für KI-gestützte Releases fest. Gleichzeitig werden nach jedem Release Messwerte genutzt, um Risiken, Kontrollen und Prioritäten anzupassen. Welche Aussage beschreibt die Kombination AM BESTEN?

❌ 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.

☝️ Single Fallkontext Klinikverbund: In diesem Umfeld beschreibt ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Leitungsgremium legt Entscheidungsrechte für KI-gestützte Releases fest. Gleichzeitig werden nach jedem Release Messwerte genutzt, um Risiken, Kontrollen und Prioritäten anzupassen. Welche Aussage beschreibt die Kombination AM BESTEN?

✅ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. In diesem Umfeld beschreibt ein Leitungsgremium legt Entscheidungsrechte für KI-gestützte Releases fest. Gleichzeitig werden nach jedem Release Messwerte genutzt, um Risiken, Kontrollen und Prioritäten anzupassen. Welche Aussage beschreibt die Kombination AM BESTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: In diesem Umfeld beschreibt ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Leitungsgremium legt Entscheidungsrechte für KI-gestützte Releases fest. Gleichzeitig werden nach jedem Release Messwerte genutzt, um Risiken, Kontrollen und Prioritäten anzupassen. Welche Aussage beschreibt die Kombination AM BESTEN?

❌ 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..

ITIL und KI

KI-Reifegradstufen [KI] 1 Unterseite →

☝️ Single Was ist typischerweise das Ziel eines KI-Reifegradmodells für Organisationen?

✅ 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 Unterseite →

☝️ Single Warum ist Datenqualität besonders wichtig für den erfolgreichen KI-Einsatz?

✅ 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 Unterseite →

☝️ Single Welche ITIL-Practice ist besonders relevant, wenn KI-Systeme neu in Arbeitsabläufe eingeführt werden?

✅ 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 Unterseite →

☝️ Single Warum ist Nachvollziehbarkeit ("Erklärbarkeit") von KI-Entscheidungen wichtig?

✅ 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 Unterseite →

☝️ Single Wie kann KI das Continual-Improvement-Prinzip praktisch unterstützen?

✅ 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 Unterseite →

✌️ Multi Welche Aspekte gehören zu verantwortungsvollem KI-Einsatz laut ITIL-Grundgedanken? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Schätze grob ein, auf welcher Reifestufe dein Unternehmen (oder ein fiktives Beispiel) beim KI-Einsatz steht, und was der nächste sinnvolle Schritt wäre.

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 Unterseite →

✍️ Offen Skizziere in Stichpunkten, was eine einfache KI-Governance-Richtlinie für ein Unternehmen mindestens enthalten sollte.

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 Unterseite →

☝️ Single Was beschreibt das Konzept "KI-Reife" (AI maturity) einer Organisation?

✅ 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 Unterseite →

☝️ Single Was kennzeichnet "Generative KI" (GenAI)?

✅ 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 Unterseite →

☝️ Single Was unterscheidet "Agentic KI" von klassischer generativer KI?

✅ 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 Unterseite →

☝️ Single Wofür sorgt "KI-Governance" im ITIL-Kontext?

✅ 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 Unterseite →

☝️ Single In welchen Stufen des Produkt- und Servicelebenszyklus kann KI unterstützend eingesetzt werden?

✅ 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 Unterseite →

☝️ Single Welches Risiko wird im Zusammenhang mit KI-Einsatz typischerweise besonders betont?

✅ 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 Unterseite →

☝️ Single Warum bleibt menschliche Aufsicht ("human oversight") bei KI-gestützten Entscheidungen wichtig?

✅ 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 Unterseite →

☝️ Single Welches Guiding Principle passt besonders gut zum verantwortungsvollen Einsatz von KI ("erst optimieren, dann automatisieren")?

✅ 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 Unterseite →

✍️ Offen Nenne ein Beispiel, wie KI in deinem beruflichen Umfeld sinnvoll eingesetzt werden könnte, und ein mögliches Risiko dabei.

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 Unterseite →

✍️ Offen Beschreibe ein Szenario, in dem Agentic KI im IT-Servicemanagement eigenständig mehrstufig handeln könnte — und wo trotzdem menschliche Kontrolle nötig bleibt.

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 Unterseite →

☝️ Single Wozu dient das ITIL KI-Fähigkeitsmodell primär?

✅ 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 Unterseite →

☝️ Single Wozu dient das ITIL AI Capability Model in erster Linie?

❌ 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.

☝️ Single Was leistet generative KI (Generative AI) primär?

✅ 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.

☝️ Single Was ist das Ziel von KI-Governance?

✅ 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.

☝️ Single Welche Option beschreibt „KI-Governance“ AM BESTEN?

✅ 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).

☝️ Single Welche Option beschreibt „Künstliche Intelligenz (KI)“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Generative KI (GenAI)“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Agentische KI“ AM BESTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein AIOps-Werkzeug analysiert Protokolle und Metriken, erkennt ungewöhnliche Muster, prognostiziert mögliche Kapazitätsengpässe und weist auf Anomalien hin, bevor viele Anwender betroffen sind. Welche KI-Fähigkeit aus dem ITIL KI-Fähigkeitsmodell wird AM BESTEN beschrieben?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein AIOps-Werkzeug analysiert Protokolle und Metriken, erkennt ungewöhnliche Muster, prognostiziert mögliche Kapazitätsengpässe und weist auf Anomalien hin, bevor viele Anwender betroffen sind. Welche KI-Fähigkeit aus dem ITIL KI-Fähigkeitsmodell wird AM BESTEN beschrieben?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein AIOps-Werkzeug analysiert Protokolle und Metriken, erkennt ungewöhnliche Muster, prognostiziert mögliche Kapazitätsengpässe und weist auf Anomalien hin, bevor viele Anwender betroffen sind. Welche KI-Fähigkeit aus dem ITIL KI-Fähigkeitsmodell wird AM BESTEN beschrieben?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein AIOps-Werkzeug analysiert Protokolle und Metriken, erkennt ungewöhnliche Muster, prognostiziert mögliche Kapazitätsengpässe und weist auf Anomalien hin, bevor viele Anwender betroffen sind. Welche primäre KI-Fähigkeit aus dem ITIL KI-Fähigkeitsmodell wird AM BESTEN beschrieben?

✅ 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.

ITIL und andere Rahmenwerke

Gemeinsame Werte ITIL/DevOps [Rahmenwerke] 1 Unterseite →

☝️ Single Welcher Wert wird sowohl von ITIL als auch von DevOps stark betont?

✅ 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 Unterseite →

☝️ Single Was ist ein "Fehlerbudget" (Error Budget) im SRE-Kontext grundsätzlich?

✅ 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 Unterseite →

☝️ Single Was ist eine Kerneigenschaft von PRINCE2-Projekten im Gegensatz zu laufendem Servicebetrieb?

✅ 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 Unterseite →

☝️ Single Warum wird DevOps oft nicht nur als Technik, sondern auch als "Kultur" beschrieben?

✅ 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 Unterseite →

☝️ Single Was ist ein typischer kritischer Punkt beim Übergang von einem PRINCE2-Projekt in den laufenden ITIL-Servicebetrieb?

✅ 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 Unterseite →

✌️ Multi Welche der folgenden gehören zu typischen DevOps-nahen Praktiken? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Wie könnte ein Unternehmen Change-Enablement-Governance so gestalten, dass sie das hohe Tempo von DevOps/CI-CD nicht ausbremst?

Framework-Kombination begründen [Rahmenwerke] 1 Unterseite →

✍️ Offen Begründe, warum es sinnvoller sein kann, ITIL mit einem anderen Rahmenwerk zu kombinieren, statt sich auf eines allein zu verlassen.

ITIL und DevOps [Rahmenwerke] 1 Unterseite →

☝️ Single Was verbindet ITIL und DevOps grundsätzlich?

✅ 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 Unterseite →

☝️ Single Wofür steht CI/CD im DevOps-Kontext?

✅ 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 Unterseite →

☝️ Single Wofür steht die Abkürzung SRE und was ist ihr Kernanliegen?

✅ 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 Unterseite →

☝️ Single Was ist der Kernunterschied zwischen klassischem Monitoring und "Observability"?

✅ 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 Unterseite →

☝️ Single Wie ergänzen sich ITIL und PRINCE2 typischerweise?

✅ 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 Unterseite →

☝️ Single Was fördert "Komplexitätsdenken" (complexity thinking) im ITIL-Kontext?

✅ 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 Unterseite →

☝️ Single Warum ist "Workflowoptimierung" gerade im Zusammenspiel mit DevOps/CI-CD-Praktiken relevant?

✅ 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.

☝️ Single Was ist mit "Workflowoptimierung" im ITIL-Kontext gemeint?

✅ 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 Unterseite →

☝️ Single Wie positioniert ITIL sich generell gegenüber anderen Rahmenwerken wie DevOps oder PRINCE2?

✅ 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 Unterseite →

✍️ Offen Beschreibe an einem Beispiel, wie ein Unternehmen ITIL-Practices (z.B. Change Enablement) mit DevOps-Praktiken (z.B. CI/CD) sinnvoll kombinieren könnte.

ITIL und PRINCE2 im Zusammenspiel [Rahmenwerke] 1 Unterseite →

✍️ Offen Nenne ein Beispiel, wie ein PRINCE2-Projekt und laufendes ITIL-Servicemanagement im selben Unternehmen zusammenwirken könnten.

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 Unterseite →

☝️ Single Was ist der Kernzweck von Continuous Integration (CI)?

✅ 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 Unterseite →

☝️ Single Was unterscheidet Continuous Delivery von Continuous Deployment?

✅ 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 Unterseite →

☝️ Single Welches ITIL-Grundprinzip wird durch CI/CD-Praktiken besonders unterstützt?

✅ 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 Unterseite →

☝️ Single Wie lässt sich eine CI/CD-Pipeline im Sinne der ITIL-Wertströme am ehesten einordnen?

✅ 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 Unterseite →

✌️ Multi Welche zwei Aussagen zu CI/CD treffen zu?

✅ 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 Unterseite →

✍️ Offen Erkläre in eigenen Worten den Unterschied zwischen Continuous Integration und Continuous Delivery/Deployment, und wie beides zusammen zur Wertschöpfung im Produkt- und Servicelebenszyklus beiträgt.

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 Unterseite →

☝️ Single Was bezeichnet der Begriff "Observability" im Kontext moderner IT-Services?

✅ 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 Unterseite →

☝️ Single Worin unterscheidet sich Observability grundsätzlich von klassischem Monitoring?

✅ 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 Unterseite →

✌️ Multi Welche zwei der folgenden gelten typischerweise als Datenquelle/"Säule" der Observability?

✅ 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 Unterseite →

☝️ Single Warum ist Observability besonders eng mit Site Reliability Engineering (SRE) verknüpft?

✅ 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 Unterseite →

☝️ Single Welcher der vier ITIL-Dimensionen lässt sich Observability am ehesten zuordnen?

✅ 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 Unterseite →

✍️ Offen Beschreibe an einem Beispiel, wie Observability dabei helfen kann, ein unbekanntes Problem in einem IT-Service schneller zu diagnostizieren als reines Monitoring.

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 Unterseite →

☝️ Single Was versteht ITIL unter "Komplexitätsdenken" (Complexity Thinking)?

✅ 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 Unterseite →

☝️ Single Wie hängt Komplexitätsdenken mit dem Grundprinzip "Iterativ mit Feedback vorgehen" zusammen?

✅ 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 Unterseite →

☝️ Single Mit welchem ITIL-Werkzeug/Konzept ist Workflowoptimierung besonders eng verbunden?

✅ 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 Unterseite →

✌️ Multi Welche zwei Aussagen passen zum Komplexitätsdenken in modernen Serviceorganisationen?

✅ 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 Unterseite →

✍️ Offen Nenne ein Beispiel, wie Komplexitätsdenken die Herangehensweise an ein IT-Problem im Vergleich zu einem rein linearen, plangetriebenen Ansatz verändert.

Übung [Rahmenwerke] 7 Unterseite →

☝️ Single Wie arbeitet ITIL mit DevOps-Praktiken zusammen?

✅ 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.

☝️ Single Worin unterscheiden sich 'Continuous Delivery' und 'Continuous Deployment'?

✅ 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.

☝️ Single Was ermöglicht Observability im Management digitaler Produkte und Services?

✅ 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.

☝️ Single Wie können ITIL und DevOps gemeinsam genutzt werden?

❌ 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.

☝️ Single Warum ist Projektmanagement in ITIL wichtig?

❌ 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.

☝️ Single Wie ergänzen ITIL und PRINCE2 einander?

❌ 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.

☝️ Single Welche gemeinsamen Prinzipien teilen ITIL, PRINCE2 und DevOps laut OfficialBook?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Eine Organisation nutzt ITIL für das Management digitaler Produkte und Services. Für eine größere Transformation mit mehreren Abhängigkeiten, Budgetsteuerung und Nutzenrealisierung sucht sie ergänzende strukturierte Leitlinien. Welche Aussage ist AM BESTEN?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Eine Organisation nutzt ITIL für das Management digitaler Produkte und Services. Für eine größere Transformation mit mehreren Abhängigkeiten, Budgetsteuerung und Nutzenrealisierung sucht sie ergänzende strukturierte Leitlinien. Welche Aussage ist AM BESTEN?

✅ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Eine Organisation nutzt ITIL für das Management digitaler Produkte und Services. Für eine größere Transformation mit mehreren Abhängigkeiten, Budgetsteuerung und Nutzenrealisierung sucht sie ergänzende strukturierte Leitlinien. Welche Aussage ist AM BESTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Eine Organisation nutzt ITIL für das Management digitaler Produkte und Services. Für eine größere Transformation mit mehreren Abhängigkeiten, Budgetsteuerung und Nutzenrealisierung sucht sie ergänzende strukturierte Leitlinien. Welche Aussage ist AM BESTEN?

❌ 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..

Produkt- & Servicelebenszyklus

Übersicht [Lebenszyklus] 1 Unterseite →

☝️ Single Aus wie vielen Stufen besteht der Produkt- und Servicelebenszyklus in ITIL Foundation (Version 5)?

✅ 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 Unterseite →

☝️ Single Was ist der Kernzweck der Stufe "Discover"?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Vor einer Entscheidung über die nächste Produktversion analysiert ein Team Markttrends, nicht erfüllte Stakeholderbedürfnisse, Risiken und Chancen im bestehenden Serviceangebot. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Vor einer Entscheidung über die nächste Produktversion analysiert ein Team Markttrends, nicht erfüllte Stakeholderbedürfnisse, Risiken und Chancen im bestehenden Serviceangebot. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

✅ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Vor einer Entscheidung über die nächste Produktversion analysiert ein Team Markttrends, nicht erfüllte Stakeholderbedürfnisse, Risiken und Chancen im bestehenden Serviceangebot. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Vor einer Entscheidung über die nächste Produktversion analysiert ein Team Markttrends, nicht erfüllte Stakeholderbedürfnisse, Risiken und Chancen im bestehenden Serviceangebot. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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 Unterseite →

☝️ Single Was passiert in der Stufe "Design"?

✅ 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 Unterseite →

☝️ Single Was ist der PRIMÄRE Zweck der Aktivität "Acquire" im Produkt- und Servicelebenszyklus?

✅ 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 Unterseite →

☝️ Single Was ist der Zweck der Stufe "Transition"?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Team hat Entwicklung und Tests abgeschlossen. Nun werden Anwenderdaten migriert, Schulungen durchgeführt, Monitoring aktiviert und das Portal kontrolliert in die Live-Umgebung überführt. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

✅ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Team hat Entwicklung und Tests abgeschlossen. Nun werden Anwenderdaten migriert, Schulungen durchgeführt, Monitoring aktiviert und das Portal kontrolliert in die Live-Umgebung überführt. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Team hat Entwicklung und Tests abgeschlossen. Nun werden Anwenderdaten migriert, Schulungen durchgeführt, Monitoring aktiviert und das Portal kontrolliert in die Live-Umgebung überführt. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Team hat Entwicklung und Tests abgeschlossen. Nun werden Anwenderdaten migriert, Schulungen durchgeführt, Monitoring aktiviert und das Portal kontrolliert in die Live-Umgebung überführt. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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 Unterseite →

☝️ Single Was steht im Mittelpunkt der Stufe "Operate"?

✅ 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 Unterseite →

☝️ Single Welche der folgenden Optionen gehört zum Zweck der Aktivität "Deliver"?

✅ 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).

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Provider nimmt neue Anwender in einen bestehenden Arbeitsplatzservice auf, erfüllt standardisierte Zugriffsanforderungen, stellt vereinbarte Materialien bereit und führt Onboarding-Sitzungen durch. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Provider nimmt neue Anwender in einen bestehenden Arbeitsplatzservice auf, erfüllt standardisierte Zugriffsanforderungen, stellt vereinbarte Materialien bereit und führt Onboarding-Sitzungen durch. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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).

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Provider nimmt neue Anwender in einen bestehenden Arbeitsplatzservice auf, erfüllt standardisierte Zugriffsanforderungen, stellt vereinbarte Materialien bereit und führt Onboarding-Sitzungen durch. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Provider nimmt neue Anwender in einen bestehenden Arbeitsplatzservice auf, erfüllt standardisierte Zugriffsanforderungen, stellt vereinbarte Materialien bereit und führt Onboarding-Sitzungen durch. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

✅ 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 Unterseite →

☝️ Single Wie werden die 8 Stufen des Lebenszyklus in der Praxis durchlaufen?

✅ 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 Unterseite →

☝️ Single Kann Wertschöpfung bereits in frühen Stufen wie "Discover" entstehen, obwohl noch kein fertiges Produkt existiert?

✅ 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 Unterseite →

☝️ Single Was ist ein struktureller Unterschied des Lebenszyklus in Version 5 gegenüber der Service Value Chain in ITIL 4?

✅ 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 Unterseite →

☝️ Single Warum ist "Support" als eigenständiger Teil der letzten Stufe wichtig?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Anwender melden Störungen und Fragen. Das Team nimmt Anfragen an, stellt den normalen Servicebetrieb soweit möglich wieder her und analysiert wiederkehrende Fehlerbilder mit Betriebsdaten. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Anwender melden Störungen und Fragen. Das Team nimmt Anfragen an, stellt den normalen Servicebetrieb soweit möglich wieder her und analysiert wiederkehrende Fehlerbilder mit Betriebsdaten. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Anwender melden Störungen und Fragen. Das Team nimmt Anfragen an, stellt den normalen Servicebetrieb soweit möglich wieder her und analysiert wiederkehrende Fehlerbilder mit Betriebsdaten. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

✅ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Anwender melden Störungen und Fragen. Das Team nimmt Anfragen an, stellt den normalen Servicebetrieb soweit möglich wieder her und analysiert wiederkehrende Fehlerbilder mit Betriebsdaten. Welche Lebenszyklusmanagement-Aktivität wird PRIMÄR durchgeführt?

❌ 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 Unterseite →

✌️ Multi Welche der folgenden gehören zu den 8 Stufen des Produkt- und Servicelebenszyklus? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Erkläre an einem Beispiel, wie ein Team von "Operate" zurück zu "Design" springen könnte, ohne dass das ein Rückschritt ist.

Discover vs. Design [Lebenszyklus] 1 Unterseite →

✍️ Offen Worin unterscheidet sich "Discover" inhaltlich von "Design", auch wenn beide früh im Lebenszyklus liegen?

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 Unterseite →

☝️ Single Muss der Lebenszyklus zwingend bei "Discover" beginnen?

✅ 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 Unterseite →

☝️ Single Wie werden Erkenntnisse aus "Operate" typischerweise genutzt?

✅ 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 Unterseite →

☝️ Single Wovon hängt typischerweise ab, ob eine Organisation "Acquire" oder "Build" wählt?

✅ 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 Unterseite →

☝️ Single Warum ist die Stufe "Transition" besonders risikobehaftet?

✅ 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 Unterseite →

☝️ Single Wie trägt "Support" konkret zur Wertschöpfung bei, auch wenn die eigentliche Lösung schon fertig ist?

✅ 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 Unterseite →

☝️ Single Kann ein einzelner Wertstrom mehrere Lebenszyklusstufen gleichzeitig berühren?

✅ 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 Unterseite →

☝️ Single Warum sollten in der Stufe "Design" alle vier Dimensionen berücksichtigt werden?

✅ 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 Unterseite →

✌️ Multi Welche Aussagen zum iterativen Charakter des Lebenszyklus sind zutreffend? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Wähle ein eigenes (fiktives oder reales) Produkt und ordne kurz zu, was in jeder der 8 Stufen konkret passieren würde.

Wann zurück zu Design? [Lebenszyklus] 1 Unterseite →

✍️ Offen Nenne zwei konkrete Signale aus dem laufenden Betrieb (Operate/Support), die ein Team veranlassen sollten, zurück zur Design-Stufe zu gehen.

Build [Lebenszyklus] 1 Unterseite →

☝️ Single Welche Aktivität des Lebenszyklusmanagements konzentriert sich auf die interne Erstellung, Entwicklung und Konfiguration von Servicekomponenten?

✅ 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 Unterseite →

☝️ Single Welche der folgenden Optionen ist KEINE typische Erfolgsmessgröße für die Aktivität "Discover"?

✅ 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 Unterseite →

☝️ Single Welche der folgenden Optionen ist eine zentrale Erfolgsmessgröße für die Aktivität "Acquire"?

✅ 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 Unterseite →

☝️ Single Welche Lebenszyklus-Aktivität sorgt dafür, dass neue oder geänderte Produkte reibungslos in die Live-Umgebung überführt werden?

❌ Build

✅ Transition

❌ Deliver

❌ Operate

Transition überführt neue/geänderte Produkte nahtlos in den Betrieb.

☝️ Single Welche Lebenszyklus-Aktivität ist primär für Betrieb und Überwachung digitaler Produkte und unterstützender Systeme zuständig?

❌ 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.

☝️ Single Was ist der primäre Zweck der Aktivität 'Acquire'?

❌ 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.

☝️ Single Welche Lebenszyklus-Aktivität konzentriert sich auf das Erstellen von Prototypen und Spezifikationen?

✅ 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.

☝️ Single Was ist der Zweck der Aktivität 'Support'?

❌ 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).

☝️ Single Was ist der Hauptzweck der Aktivität 'Discover'?

✅ 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.

☝️ Single Welche Aktivität erstellt oder verändert Produkte so, dass sie die Anforderungen erfüllen?

❌ 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.

☝️ Single Welche Kennzahl eignet sich am besten, um die Aktivität 'Transition' zu bewerten?

✅ 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.

☝️ Single Welche Kennzahl passt am besten zur Bewertung der Aktivität 'Build'?

❌ 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.

☝️ Single Welche Aktivitäten gehören zum ITIL Produkt- und Servicelebenszyklus?

❌ 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.

☝️ Single Welcher Zweck gehört zur Aktivität „Discover“?

❌ 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.

☝️ Single Welcher Zweck gehört zur Aktivität „Transition“?

❌ 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.

☝️ Single Wie sollten die Aktivitäten des Lebenszyklusmanagements genutzt werden?

❌ 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.

☝️ Single Welcher Zweck gehört zur Aktivität „Design“?

❌ 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.

☝️ Single Welcher Zweck gehört zur Aktivität „Acquire“?

❌ 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.

☝️ Single Welcher Zweck gehört zur Aktivität „Operate“?

❌ 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.

☝️ Single Welcher Zweck gehört zur Aktivität „Deliver“?

✅ Services bereitstellen und vereinbarte Serviceaktionen für Servicekonsumenten ausführen

❌ KI-Governance etablieren

❌ Codeänderungen integrieren

❌ Märkte verstehen

Deliver umfasst Servicebereitstellung und Serviceaktionen.

☝️ Single Welcher Zweck gehört zur Aktivität „Build“?

✅ 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.

☝️ Single Welcher Zweck gehört zur Aktivität „Support“?

❌ 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.

☝️ Single Was beschreibt „Discover“ AM BESTEN?

❌ 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.

☝️ Single Was beschreibt „Deliver“ AM BESTEN?

❌ 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.

☝️ Single Welche Aktivität führt neue oder geänderte Produkte und Services in Live-Umgebungen ein?

❌ 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.

☝️ Single Welche Aktivität betreibt Produkte und Services in Live-Umgebungen?

❌ Acquire

❌ Design

✅ Operate

❌ Discover

Operate betreibt Produkte und Services live.

☝️ Single Welche Aktivität beschafft externe Ressourcen, Produkte und Services?

✅ 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.

☝️ Single Welche Aktivität gestaltet Produkte und Services auf Grundlage verstandener Anforderungen?

✅ Design

❌ Operate

❌ Support

❌ Deliver

Design gestaltet Produkte und Services.

Wertströme

Begriff Wertstrom [Wertströme] 1 Unterseite →

☝️ Single Wie ist ein "Wertstrom" (Value Stream) definiert?

✅ 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 Unterseite →

☝️ Single Was zeichnet einen "Hauptwertstrom" aus?

✅ 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 Unterseite →

☝️ Single Wie unterscheidet sich ein Wertstrom grundsätzlich von einer einzelnen Practice?

✅ 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 Unterseite →

☝️ Single Wofür ist Value Stream Mapping besonders nützlich, abgesehen von der reinen Visualisierung?

✅ 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 Unterseite →

☝️ Single Warum überschreitet ein typischer Hauptwertstrom oft mehrere Abteilungsgrenzen?

✅ 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 Unterseite →

☝️ Single Welches Guiding Principle passt besonders gut zur Optimierung eines Wertstroms?

✅ 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 Unterseite →

✌️ Multi Welche Aussagen zu Wertströmen treffen zu? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Beschreibe einen konkreten Engpass oder Wartepunkt in einem Wertstrom aus deinem beruflichen Umfeld und einen möglichen Verbesserungsansatz.

Value Stream Mapping durchführen [Wertströme] 1 Unterseite →

✍️ Offen Beschreibe stichpunktartig, wie du ein Value Stream Mapping für einen selbst gewählten Ablauf durchführen würdest.

Unterstützender Wertstrom [Wertströme] 1 Unterseite →

☝️ Single Was ist die Funktion eines "unterstützenden Wertstroms"?

✅ 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 Unterseite →

☝️ Single Wofür wird "Value Stream Mapping" eingesetzt?

✅ 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 Unterseite →

☝️ Single Welches der folgenden Beispiele beschreibt am ehesten einen Hauptwertstrom?

✅ 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 Unterseite →

☝️ Single Welches Beispiel beschreibt eher einen unterstützenden Wertstrom?

✅ 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 Unterseite →

☝️ Single Was zeigt eine typische Wertstromdarstellung typischerweise auf einen Blick?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Service Provider kennt seine Prozessbeschreibungen, aber die tatsächliche Bearbeitung eines Service Requests weicht regelmäßig ab. Das Team beobachtet reale Übergaben, Wartezeiten, Informationsflüsse und Nacharbeit. Welche Empfehlung passt AM BESTEN?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Service Provider kennt seine Prozessbeschreibungen, aber die tatsächliche Bearbeitung eines Service Requests weicht regelmäßig ab. Das Team beobachtet reale Übergaben, Wartezeiten, Informationsflüsse und Nacharbeit. Welche Empfehlung passt AM BESTEN?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Service Provider kennt seine Prozessbeschreibungen, aber die tatsächliche Bearbeitung eines Service Requests weicht regelmäßig ab. Das Team beobachtet reale Übergaben, Wartezeiten, Informationsflüsse und Nacharbeit. Welche Empfehlung passt am präzisesten?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Service Provider kennt seine Prozessbeschreibungen, aber die tatsächliche Bearbeitung eines Service Requests weicht regelmäßig ab. Das Team beobachtet reale Übergaben, Wartezeiten, Informationsflüsse und Nacharbeit. Welche Empfehlung passt AM BESTEN?

✅ 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 Unterseite →

☝️ Single Wie hängen Wertströme mit dem 8-stufigen Produkt- und Servicelebenszyklus zusammen?

✅ 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 Unterseite →

✍️ Offen Skizziere in Stichpunkten einen Hauptwertstrom aus deinem beruflichen Umfeld — von Auslöser bis Wertschöpfung.

Haupt- vs. unterstützend im eigenen Kontext [Wertströme] 1 Unterseite →

✍️ Offen Nenne für deinen Arbeitsbereich je ein Beispiel für einen Haupt- und einen unterstützenden Wertstrom und begründe die Zuordnung.

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 Unterseite →

☝️ Single Was ist der wesentliche Unterschied zwischen "Wertstromdarstellung" und "Wertstrommanagement"?

✅ 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 Unterseite →

☝️ Single Worin unterscheiden sich Wertstromabbildung (Mapping) und Wertstrommanagement?

✅ 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.

☝️ Single Wie trägt ein unterstützender (enabling) Wertstrom zur Wertschöpfung bei?

✅ 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.

☝️ Single Welche der folgenden ist KEIN Schritt der Wertstromabbildung (Value Stream Mapping)?

❌ 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.

☝️ Single Wodurch zeichnet sich ein Haupt-Wertstrom (Core Value Stream) aus?

✅ 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.

☝️ Single Welche Option beschreibt „Wertstrom“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Hauptwertstrom“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „unterstützender Wertstrom“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Wertstromdarstellung“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Wertstrommanagement“ AM BESTEN?

❌ 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.

☝️ Single Warum ist Wertstromdarstellung kein einmaliges Projekt?

❌ 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.

☝️ Single Welche Aussage zu Hauptwertstrom und unterstützendem Wertstrom ist KORREKT?

❌ 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.

☝️ Single Welche Elemente stehen bei Wertstromdarstellung im Fokus einer digital-first-Umgebung?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Team stellt den End-to-End-Fluss von der Buchungsanfrage bis zur erfolgreichen Fahrzeugübernahme dar. Daneben wird ein interner Workflow zum Onboarding eines neuen Zahlungsdienstleisters betrachtet. Welche Aussage ist AM BESTEN?

✅ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Team stellt den End-to-End-Fluss von der Buchungsanfrage bis zur erfolgreichen Fahrzeugübernahme dar. Daneben wird ein interner Workflow zum Onboarding eines neuen Zahlungsdienstleisters betrachtet. Welche Aussage ist AM BESTEN?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Team stellt den End-to-End-Fluss von der Buchungsanfrage bis zur erfolgreichen Fahrzeugübernahme dar. Daneben wird ein interner Workflow zum Onboarding eines neuen Zahlungsdienstleisters betrachtet. Welche Aussage ist AM BESTEN?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Team stellt den End-to-End-Fluss von der Buchungsanfrage bis zur erfolgreichen Fahrzeugübernahme dar. Daneben wird ein interner Workflow zum Onboarding eines neuen Zahlungsdienstleisters betrachtet. Welche Aussage ist AM BESTEN?

❌ 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..

Wichtige ITIL-Begriffe

Servicebegriff [Begriffe] 1 Unterseite →

☝️ Single Was ist laut ITIL die Kerndefinition eines "Service"?

✅ 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 Unterseite →

☝️ Single Wie ist ein "Produkt" im ITIL-Sinne definiert?

✅ 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 Unterseite →

☝️ Single Was umfasst ein "Serviceangebot" (Service Offering)?

✅ 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 Unterseite →

☝️ Single Worin unterscheiden sich "Output" und "Outcome"?

✅ 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 Unterseite →

☝️ Single Was beschreibt der Begriff "Utility" (Nutzen/Funktionalität)?

✅ 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 Unterseite →

☝️ Single Was beschreibt der Begriff "Warranty" (Zusicherung)?

✅ 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 Unterseite →

☝️ Single Ein Onlineshop ist zwar funktional voll nutzbar, fällt aber regelmäßig für Stunden aus. Welche Eigenschaft fehlt ihm primär?

✅ 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 Unterseite →

☝️ Single Wie wird "Value" (Wert) im ITIL-Kontext grundsätzlich verstanden?

✅ 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 Unterseite →

☝️ Single Warum sind "Cost" (Kosten) und "Risk" (Risiko) für das Verständnis von Wert wichtig?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Kunde nutzt einen Managed Service, damit er die Kosten für Spezialisten, Monitoring-Tools und Verfügbarkeitsrisiken nicht vollständig selbst tragen muss. Welche Aussage passt AM BESTEN zur Service-Definition?

❌ 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..

☝️ Single Fallkontext Klinikverbund: In diesem Umfeld beschreibt ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Kunde nutzt einen Managed Service, damit er die Kosten für Spezialisten, Monitoring-Tools und Verfügbarkeitsrisiken nicht vollständig selbst tragen muss. Welche Aussage passt AM BESTEN zur Service-Definition?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. In diesem Umfeld beschreibt ein Kunde nutzt einen Managed Service, damit er die Kosten für Spezialisten, Monitoring-Tools und Verfügbarkeitsrisiken nicht vollständig selbst tragen muss. Welche Aussage passt am präzisesten zur Service-Definition?

❌ 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..

☝️ Single Fallkontext Handelslogistik: In diesem Umfeld beschreibt ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Kunde nutzt einen Managed Service, damit er die Kosten für Spezialisten, Monitoring-Tools und Verfügbarkeitsrisiken nicht vollständig selbst tragen muss. Welche Aussage passt AM BESTEN zur Service-Definition?

✅ 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 Unterseite →

☝️ Single Was umfasst eine "Servicebeziehung" (Service Relationship)?

✅ 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 Unterseite →

☝️ Single Welche drei Rollen können innerhalb eines "Service-Konsumenten" unterschieden werden?

✅ 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 Unterseite →

☝️ Single Welche Rolle beschreibt der Begriff "Sponsor" im ITIL-Sprachgebrauch?

✅ 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 Unterseite →

☝️ Single Wofür steht die Abkürzung SLA und wofür wird sie genutzt?

✅ 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 Unterseite →

☝️ Single Wie definiert ITIL "Service Management" als Begriff?

✅ 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 Unterseite →

☝️ Single Was versteht ITIL unter "Best Practice"?

✅ 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 Unterseite →

☝️ Single Welche Rolle spielt "Nachhaltigkeit" in ITIL Foundation (Version 5)?

✅ 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 Unterseite →

☝️ Single Warum wird "User Experience" (UX) in Version 5 stärker betont als zuvor?

✅ 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 Unterseite →

☝️ Single Was ist eine zentrale Neuerung im "Management digitaler Produkte und Services" gegenüber klassischem IT-Servicemanagement?

✅ 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 Unterseite →

☝️ Single Was ist die Kernaufgabe eines "Service Providers"?

✅ 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 Unterseite →

✌️ Multi Welche der folgenden Aussagen zu Konsumentenrollen treffen zu? (Mehrfachauswahl)

✅ 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 Unterseite →

✍️ Offen Erkläre anhand eines eigenen Beispiels, warum ein Service sowohl Utility als auch Warranty braucht, um echten Wert zu schaffen.

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 Unterseite →

✍️ Offen Was bedeutet es, dass Wert laut ITIL "ko-kreiert" wird, statt einseitig vom Provider geliefert zu werden?

Service Offering vs. Service [Begriffe] 1 Unterseite →

☝️ Single Kann ein einzelner Service Teil mehrerer unterschiedlicher Serviceangebote sein?

✅ 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 Unterseite →

☝️ Single Welches der folgenden ist ein Beispiel für einen "Output" (nicht Outcome)?

✅ 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 Unterseite →

☝️ Single Können sowohl Service-Provider als auch Service-Konsument eigene Kosten im Rahmen einer Servicebeziehung haben?

✅ 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 Unterseite →

☝️ Single Was bedeutet es, wenn ein Service "Risiko abnimmt" statt es zu "eliminieren"?

✅ 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 Unterseite →

☝️ Single Können Anwender:in und Kundschaft dieselbe Person sein?

✅ 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 Unterseite →

☝️ Single Woran wird "Servicequalität" typischerweise festgemacht?

✅ 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 Unterseite →

☝️ Single Was gehört typischerweise NICHT in ein Service Level Agreement?

✅ 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 Unterseite →

☝️ Single Wie verhalten sich "Produkt" und "Serviceangebot" zueinander?

✅ 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 Unterseite →

☝️ Single Welche der folgenden gehört typischerweise zu den Warranty-Aspekten eines Service?

✅ 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 Unterseite →

☝️ Single Warum ist es für viele Konsumenten attraktiv, einen Service zu nutzen statt das zugrunde liegende Produkt selbst zu besitzen?

✅ 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 Unterseite →

☝️ Single Was ist die Kernaufgabe der Rolle "Kundschaft" (Customer)?

✅ 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 Unterseite →

☝️ Single Was unterscheidet "digitale Transformation" von reiner "IT-Modernisierung"?

✅ 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 Unterseite →

☝️ Single Wie kann Nachhaltigkeit konkret in eine Serviceanforderung einfließen?

✅ 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 Unterseite →

✌️ Multi Welche Elemente kann ein Serviceangebot laut ITIL umfassen? (Mehrfachauswahl)

✅ Waren (Goods)

✅ Zugang zu Ressourcen

✅ Service-Aktionen

❌ Ausschließlich Software-Lizenzen

Warranty-Aspekte [Begriffe] 1 Unterseite →

✌️ Multi Welche der folgenden gehören typischerweise zu Warranty-Aspekten? (Mehrfachauswahl)

✅ 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 Unterseite →

☝️ Single Kann eine Organisation gleichzeitig Service-Provider und Service-Konsument sein (für unterschiedliche Services)?

✅ 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 Unterseite →

☝️ Single Worin unterscheidet sich eine "Best Practice" grundsätzlich von einem verpflichtenden "Standard"?

✅ 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 Unterseite →

✍️ Offen Beschreibe an einem selbst gewählten Beispiel eine vollständige Servicebeziehung inkl. Bereitstellung, Nutzung und Beziehungsmanagement.

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 Unterseite →

✍️ Offen Finde ein eigenes Alltagsbeispiel (nicht IT) für Utility und Warranty und ordne es korrekt zu.

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 Unterseite →

✍️ Offen Nenne einen Service aus deinem Alltag, bei dem dir bewusst Kosten oder Risiko abgenommen werden, statt dass du sie selbst trägst.

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 Unterseite →

☝️ Single Was beschreibt der Begriff "Sichtbarkeitsbereich" (Visibility Boundary) in einer Serviceinteraktion?

✅ 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 Unterseite →

☝️ Single Was ist ein "digitaler Service" im Sinne von ITIL Version 5?

✅ 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 Unterseite →

☝️ Single Welcher Typ von Servicebeziehung konzentriert sich typischerweise auf Support und Effizienz durch standardisierte Services?

✅ 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 Unterseite →

☝️ Single Was beschreibt eine "Service Journey"?

✅ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Provider analysiert nicht nur Vertragsabschluss und Lieferung, sondern alle Interaktionen von der Bedarfserkundung über Onboarding, Nutzung, Support, Review und Verbesserung. Welches Schlüsselkonzept steht AM STÄRKSTEN im Vordergrund?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Provider analysiert nicht nur Vertragsabschluss und Lieferung, sondern alle Interaktionen von der Bedarfserkundung über Onboarding, Nutzung, Support, Review und Verbesserung. Welches Schlüsselkonzept steht AM STÄRKSTEN im Vordergrund?

✅ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Provider analysiert nicht nur Vertragsabschluss und Lieferung, sondern alle Interaktionen von der Bedarfserkundung über Onboarding, Nutzung, Support, Review und Verbesserung. Welches Schlüsselkonzept steht AM STÄRKSTEN im Vordergrund?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Provider analysiert nicht nur Vertragsabschluss und Lieferung, sondern alle Interaktionen von der Bedarfserkundung über Onboarding, Nutzung, Support, Review und Verbesserung. Welches Schlüsselkonzept steht AM STÄRKSTEN im Vordergrund?

❌ 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 Unterseite →

☝️ Single Welche Option beschreibt „digitales Produkt“ AM BESTEN?

❌ 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 Unterseite →

☝️ Single Welche Option beschreibt „Anbieter digitaler Produkte“ AM BESTEN?

❌ 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.

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein internes Produktteam erstellt die mobile App, verbessert sie kontinuierlich und pflegt das zugehörige Serviceangebot, während ein anderer Bereich den täglichen Support übernimmt. Welche Rolle beschreibt das Produktteam AM BESTEN?

✅ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein internes Produktteam erstellt die mobile App, verbessert sie kontinuierlich und pflegt das zugehörige Serviceangebot, während ein anderer Bereich den täglichen Support übernimmt. Welche Rolle beschreibt das Produktteam AM BESTEN?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein internes Produktteam erstellt die mobile App, verbessert sie kontinuierlich und pflegt das zugehörige Serviceangebot, während ein anderer Bereich den täglichen Support übernimmt. Welche Rolle beschreibt das Produktteam AM BESTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein internes Produktteam erstellt die mobile App, verbessert sie kontinuierlich und pflegt das zugehörige Serviceangebot, während ein anderer Bereich den täglichen Support übernimmt. Welche primäre Rolle beschreibt das Produktteam AM BESTEN?

❌ 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 Unterseite →

☝️ Single Welche Option beschreibt „Serviceaktionen“ AM BESTEN?

❌ 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 Unterseite →

☝️ Single Ein Kunde erhält einen monatlichen Auswertungsbericht und trifft dadurch fundiertere Entscheidungen. Was ist in diesem Beispiel das Ergebnis (Outcome)?

❌ 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.

☝️ Single Ein Service ist rund um die Uhr verfügbar, ausreichend dimensioniert und abgesichert. Welchem Aspekt ist dies zuzuordnen?

❌ 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'.

☝️ Single Wovon hängt maßgeblich ab, ob ein Konsument einen Service als wertvoll wahrnimmt?

❌ 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.

☝️ Single Ein Anbieter gewährt einem Kunden gemäß vereinbarten Bedingungen Zugriff auf eine Cloud-Speicherplattform. Welche Komponente eines Serviceangebots liegt vor?

❌ 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.

☝️ Single Ein Händler übereignet einem Kunden dauerhaft ein Notebook. Welche Komponente eines Serviceangebots ist das?

❌ Zugang zu Ressourcen

✅ Warentransfer

❌ Serviceaktion

❌ Utility

Warentransfer (transfer of goods): Eigentum an einem Gut geht dauerhaft über.

☝️ Single Wer legt in einer Servicebeziehung die Anforderungen fest und trägt die Verantwortung für die Ergebnisse der Servicenutzung?

❌ 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.

☝️ Single Welche Rolle genehmigt das Budget für einen Service?

❌ Kunde

❌ Anwender

✅ Sponsor

❌ Anbieter

Der Sponsor autorisiert das Budget für den Servicekonsum.

☝️ Single Wie unterscheidet sich ein Problem von einem Incident?

❌ 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).

☝️ Single Was ist ein bekannter Fehler (Known Error)?

❌ 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.

☝️ Single Was beschreibt ein Service Level Agreement (SLA) am besten?

❌ 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).

☝️ Single Was beschreibt eine Produktspezifikation in erster Linie?

❌ 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.

☝️ Single Was ist ein Service in ITIL?

✅ 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.

☝️ Single Was beschreibt ein digitales Produkt am besten?

❌ 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.

☝️ Single Was kennzeichnet einen digitalen Service?

✅ 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.

☝️ Single Was ist ein Serviceangebot (Service Offering)?

❌ 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.

☝️ Single Worin unterscheiden sich Output und Outcome?

❌ 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.

☝️ Single Welche Rolle nutzt einen Service im Alltag, ohne notwendigerweise die Anforderungen festzulegen?

❌ 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.

☝️ Single Ein Anwender meldet, dass eine Anwendung unerwartet ausgefallen ist. Wie ist dieser Vorfall einzuordnen?

❌ Als Problem

✅ Als Incident

❌ Als Serviceanfrage

❌ Als Change

Eine ungeplante Unterbrechung oder Qualitätsminderung eines Service ist ein Incident.

☝️ Single Was ist ein Event (Ereignis) im Sinne von ITIL?

✅ 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.

☝️ Single Was ist eine Serviceanfrage (Service Request)?

❌ 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.

☝️ Single Welcher Typ von Servicebeziehung zielt vor allem auf Unterstützung und Effizienz durch standardisierte Services?

✅ 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.

☝️ Single Ein Anbieter verpflichtet sich zu recycelbaren Komponenten, geringeren Emissionen und transparenten Lieferketten. Welches Konzept beschreibt das?

❌ Utility

❌ Warranty

✅ Nachhaltigkeit

❌ User Experience

Verantwortungsvoller Ressourceneinsatz mit Blick auf ökologische, soziale und ökonomische Langzeitwirkung ist Nachhaltigkeit.

☝️ Single Was beschreibt der Begriff 'Zweck einer Organisation' (Organization's purpose)?

❌ 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.

☝️ Single Was leistet ein Betriebsmodell (Operating Model)?

❌ 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.

☝️ Single Welche Option beschreibt „Management digitaler Produkte und Services“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „digitaler Service“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Serviceangebot“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Wert“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Ergebnis“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Kosten“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Risiko“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Utility“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Warranty“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Service Level Agreement (SLA)“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Produkt“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Service“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Waren“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Zugang zu Ressourcen“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Output“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Organisation“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Service Provider“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Servicekonsument“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Sponsor“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Kunde“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Anwender“ AM BESTEN?

❌ Eine Wertschöpfungskette

✅ Die Rolle, die Services nutzt

❌ Die Rolle, die Budget genehmigt

❌ Eine Management-Practice

Anwender ist die Rolle, die Services nutzt.

☝️ Single Welche Option beschreibt „Continual Improvement“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „ITIL Produkt- und Servicelebenszyklus“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Servicequalität“ AM BESTEN?

❌ 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.

☝️ Single Welche Option beschreibt „Service Level“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „User Experience (UX)“ AM BESTEN?

✅ 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.

☝️ Single Welche Option beschreibt „Nachhaltigkeit“ AM BESTEN?

❌ 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.

☝️ Single Was unterscheidet Output und Ergebnis AM BESTEN?

❌ 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.

☝️ Single Wie tragen Kosten und Risiken zur gemeinsamen Wertschöpfung bei?

❌ 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.

☝️ Single Was kennzeichnet eine auf Zusammenarbeit basierende Servicebeziehung?

❌ 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.

☝️ Single Welche Rollen repräsentieren eine Servicekonsumenten-Organisation?

❌ 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.

☝️ Single Welche Rolle übernimmt ein Service Provider?

✅ 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.

☝️ Single Welche Rolle übernimmt ein Servicekonsument?

❌ 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.

☝️ Single Welche Aussage beschreibt gemeinsame Wertschöpfung AM BESTEN?

❌ 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.

☝️ Single Was beschreibt ein Serviceangebot im Verhältnis zu digitalen Services?

❌ 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.

☝️ Single Welche Aussage zu Serviceaktionen ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Warentransfer ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Zugang zu Ressourcen ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Utility und Warranty ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu User Experience ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu Nachhaltigkeit in Service Levels ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zur Service Journey ist KORREKT?

✅ 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.

☝️ Single Welche Aussage zu einfachen Servicebeziehungen ist KORREKT?

❌ 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.

☝️ Single Welche Aussage zu auf Kooperation basierenden Servicebeziehungen ist KORREKT?

✅ 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.

☝️ Single Welche Aussage zu Servicequalität und Service Level ist KORREKT?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Provider stellt einem neuen Kunden nach einem größeren Release Softwarezugang, Einweg-Token, Administrationsschulungen und wiederkehrende Beratungsleistungen bereit. Der Vertrag beschreibt diese Bestandteile als ein Paket für eine definierte Anwendergruppe. Welche Option beschreibt dieses Paket AM BESTEN?

✅ 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..

☝️ Single Fallkontext Klinikverbund: In diesem Umfeld beschreibt ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Provider stellt einem neuen Kunden während der Einführung eines neuen digitalen Service Softwarezugang, Einweg-Token, Administrationsschulungen und wiederkehrende Beratungsleistungen bereit. Der Vertrag beschreibt diese Bestandteile als ein Paket für eine definierte Anwendergruppe. Welche Option beschreibt dieses Paket AM BESTEN?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. In diesem Umfeld beschreibt ein Provider stellt einem neuen Kunden bei der Modernisierung eines bestehenden Produkts Softwarezugang, Einweg-Token, Administrationsschulungen und wiederkehrende Beratungsleistungen bereit. Der Vertrag beschreibt diese Bestandteile als ein Paket für eine definierte Anwendergruppe. Welche Option beschreibt dieses Paket AM BESTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: In diesem Umfeld beschreibt ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Provider stellt einem neuen Kunden nach mehreren Rückmeldungen aus dem Service Desk Softwarezugang, Einweg-Token, Administrationsschulungen und wiederkehrende Beratungsleistungen bereit. Der Vertrag beschreibt diese Bestandteile als ein Paket für eine definierte Anwendergruppe. Welche Option beschreibt dieses Paket AM BESTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Buchungssystem erfüllt alle funktionalen Anforderungen, aber in Stoßzeiten sind Antwortzeiten und Verfügbarkeit unterhalb der vereinbarten Werte. Anwender können grundsätzlich buchen, erleben den Service aber nicht zuverlässig. Welches Konzept ist in diesem Szenario AM STÄRKSTEN betroffen?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Buchungssystem erfüllt alle funktionalen Anforderungen, aber in Stoßzeiten sind Antwortzeiten und Verfügbarkeit unterhalb der vereinbarten Werte. Anwender können grundsätzlich buchen, erleben den Service aber nicht zuverlässig. Welches Konzept ist in diesem Szenario AM STÄRKSTEN betroffen?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Buchungssystem erfüllt alle funktionalen Anforderungen, aber in Stoßzeiten sind Antwortzeiten und Verfügbarkeit unterhalb der vereinbarten Werte. Anwender können grundsätzlich buchen, erleben den Service aber nicht zuverlässig. Welches Konzept ist in diesem Szenario AM STÄRKSTEN betroffen?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Buchungssystem erfüllt alle funktionalen Anforderungen, aber in Stoßzeiten sind Antwortzeiten und Verfügbarkeit unterhalb der vereinbarten Werte. Anwender können grundsätzlich buchen, erleben den Service aber nicht zuverlässig. Welches Konzept ist in diesem Szenario AM STÄRKSTEN betroffen?

✅ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Team liefert eine neue Dashboard-Funktion aus. Der Kunde bewertet jedoch nicht die ausgelieferte Funktion selbst, sondern ob Disponenten dadurch Leerfahrten reduzieren und schneller Entscheidungen treffen können. Welche Unterscheidung wird hier AM BESTEN geprüft?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Team liefert eine neue Dashboard-Funktion aus. Der Kunde bewertet jedoch nicht die ausgelieferte Funktion selbst, sondern ob Disponenten dadurch Leerfahrten reduzieren und schneller Entscheidungen treffen können. Welche Unterscheidung wird hier AM BESTEN geprüft?

❌ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Team liefert eine neue Dashboard-Funktion aus. Der Kunde bewertet jedoch nicht die ausgelieferte Funktion selbst, sondern ob Disponenten dadurch Leerfahrten reduzieren und schneller Entscheidungen treffen können. Welche Unterscheidung wird hier AM BESTEN geprüft?

✅ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Team liefert eine neue Dashboard-Funktion aus. Der Kunde bewertet jedoch nicht die ausgelieferte Funktion selbst, sondern ob Disponenten dadurch Leerfahrten reduzieren und schneller Entscheidungen treffen können. Welche primäre Unterscheidung wird hier AM BESTEN geprüft?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Fachbereich finanziert den Service, ein Product Owner legt Anforderungen an Berichte fest, und mehrere Mitarbeitende nutzen die Berichte täglich. Welche Rollen sind in dieser Servicekonsumenten-Organisation AM BESTEN abgebildet?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Fachbereich finanziert den Service, ein Product Owner legt Anforderungen an Berichte fest, und mehrere Mitarbeitende nutzen die Berichte täglich. Welche Rollen sind in dieser Servicekonsumenten-Organisation AM BESTEN abgebildet?

✅ 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.

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Fachbereich finanziert den Service, ein Product Owner legt Anforderungen an Berichte fest, und mehrere Mitarbeitende nutzen die Berichte täglich. Welche Rollen sind in dieser Servicekonsumenten-Organisation AM BESTEN abgebildet?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Fachbereich finanziert den Service, ein Product Owner legt Anforderungen an Berichte fest, und mehrere Mitarbeitende nutzen die Berichte täglich. Welche Rollen sind in dieser Servicekonsumenten-Organisation AM BESTEN abgebildet?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Unternehmen betreibt eine App, die auf Cloud-Infrastruktur, Datenmodellen und Schnittstellen basiert. Der Konsument erlebt nicht die einzelnen Ressourcen, sondern einen digitalen Service zur Reservierung und Änderung von Buchungen. Welche Aussage beschreibt den Zusammenhang AM BESTEN?

✅ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Unternehmen betreibt eine App, die auf Cloud-Infrastruktur, Datenmodellen und Schnittstellen basiert. Der Konsument erlebt nicht die einzelnen Ressourcen, sondern einen digitalen Service zur Reservierung und Änderung von Buchungen. Welche Aussage beschreibt den Zusammenhang AM BESTEN?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Unternehmen betreibt eine App, die auf Cloud-Infrastruktur, Datenmodellen und Schnittstellen basiert. Der Konsument erlebt nicht die einzelnen Ressourcen, sondern einen digitalen Service zur Reservierung und Änderung von Buchungen. Welche Aussage beschreibt den Zusammenhang AM BESTEN?

❌ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Unternehmen betreibt eine App, die auf Cloud-Infrastruktur, Datenmodellen und Schnittstellen basiert. Der Konsument erlebt nicht die einzelnen Ressourcen, sondern einen digitalen Service zur Reservierung und Änderung von Buchungen. Welche Aussage beschreibt den Zusammenhang AM BESTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Provider und ein Konsument planen Roadmaps gemeinsam, teilen Nutzungsdaten, bewerten Verbesserungen zusammen und übernehmen jeweils aktive Verantwortung für Ergebnisse. Welche Art von Servicebeziehung wird AM BESTEN beschrieben?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Provider und ein Konsument planen Roadmaps gemeinsam, teilen Nutzungsdaten, bewerten Verbesserungen zusammen und übernehmen jeweils aktive Verantwortung für Ergebnisse. Welche Art von Servicebeziehung wird AM BESTEN beschrieben?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Provider und ein Konsument planen Roadmaps gemeinsam, teilen Nutzungsdaten, bewerten Verbesserungen zusammen und übernehmen jeweils aktive Verantwortung für Ergebnisse. Welche Art von Servicebeziehung wird AM BESTEN beschrieben?

✅ 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.

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Provider und ein Konsument planen Roadmaps gemeinsam, teilen Nutzungsdaten, bewerten Verbesserungen zusammen und übernehmen jeweils aktive Verantwortung für Ergebnisse. Welche Art von Servicebeziehung wird AM BESTEN beschrieben?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Ein Service erfüllt Funktionen, ist aber aus Sicht des Kunden nur akzeptabel, wenn Verfügbarkeit, Antwortzeit, Nachhaltigkeitsziele und Anwendererfahrung messbar vereinbart sind. Welches Konzept verbindet diese Messgrößen AM BESTEN?

❌ 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..

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Ein Service erfüllt Funktionen, ist aber aus Sicht des Kunden nur akzeptabel, wenn Verfügbarkeit, Antwortzeit, Nachhaltigkeitsziele und Anwendererfahrung messbar vereinbart sind. Welches Konzept verbindet diese Messgrößen AM BESTEN?

✅ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Ein Service erfüllt Funktionen, ist aber aus Sicht des Kunden nur akzeptabel, wenn Verfügbarkeit, Antwortzeit, Nachhaltigkeitsziele und Anwendererfahrung messbar vereinbart sind. Welches Konzept verbindet diese Messgrößen AM BESTEN?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Ein Service erfüllt Funktionen, ist aber aus Sicht des Kunden nur akzeptabel, wenn Verfügbarkeit, Antwortzeit, Nachhaltigkeitsziele und Anwendererfahrung messbar vereinbart sind. Welches Konzept verbindet diese Messgrößen AM BESTEN?

❌ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Vor Vertragsabschluss beschreibt der Provider mehrere Servicepakete für verschiedene Zielgruppen. Nach Auswahl eines Pakets vereinbaren Provider und Kunde konkrete erwartete Service Levels. Welche Unterscheidung ist AM BESTEN?

❌ 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.

☝️ Single Fallkontext Klinikverbund: Ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Vor Vertragsabschluss beschreibt der Provider mehrere Servicepakete für verschiedene Zielgruppen. Nach Auswahl eines Pakets vereinbaren Provider und Kunde konkrete erwartete Service Levels. Welche Unterscheidung ist AM BESTEN?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Vor Vertragsabschluss beschreibt der Provider mehrere Servicepakete für verschiedene Zielgruppen. Nach Auswahl eines Pakets vereinbaren Provider und Kunde konkrete erwartete Service Levels. Welche Unterscheidung ist am präzisesten?

❌ 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..

☝️ Single Fallkontext Handelslogistik: Ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Vor Vertragsabschluss beschreibt der Provider mehrere Servicepakete für verschiedene Zielgruppen. Nach Auswahl eines Pakets vereinbaren Provider und Kunde konkrete erwartete Service Levels. Welche Unterscheidung ist AM BESTEN?

✅ 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 Unterseite →

☝️ Single Fallkontext Mobility-Service: Ein internationaler Mobilitätsanbieter verbindet App, Fahrzeugdaten, Partnernetzwerk und Supportorganisation. Nach jedem Release bewertet ein Team Messergebnisse, Anwenderfeedback und Risiken, um kleinere Verbesserungen im Produkt, in Practices und im Betriebsmodell zu priorisieren. Welches zentrale Konzept wird AM BESTEN beschrieben?

❌ 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..

☝️ Single Fallkontext Klinikverbund: In diesem Umfeld beschreibt ein Gesundheitsdienstleister modernisiert Patientenportale, digitale Terminservices und den technischen Support. Nach jedem Release bewertet ein Team Messergebnisse, Anwenderfeedback und Risiken, um kleinere Verbesserungen im Produkt, in Practices und im Betriebsmodell zu priorisieren. Welches zentrale Konzept wird AM BESTEN beschrieben?

❌ 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..

☝️ Single Fallkontext öffentliche Verwaltung: Eine Behörde baut digitale Bürgerdienste mit externen Plattformen, internen Fachbereichen und Service Desk aus. Nach jedem Release bewertet ein Team Messergebnisse, Anwenderfeedback und Risiken, um kleinere Verbesserungen im Produkt, in Practices und im Betriebsmodell zu priorisieren. Welches zentrale Konzept wird AM BESTEN beschrieben?

✅ 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..

☝️ Single Fallkontext Handelslogistik: In diesem Umfeld beschreibt ein Retail-Unternehmen verbessert Bestellplattform, Lagerintegration, Lieferpartner und Anwendersupport. Nach jedem Release bewertet ein Team Messergebnisse, Anwenderfeedback und Risiken, um kleinere Verbesserungen im Produkt, in Practices und im Betriebsmodell zu priorisieren. Welches zentrale Konzept wird AM BESTEN beschrieben?

❌ 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..