2.6 Der Product and Service Lifecycle

Kurz erklärt

Der ITIL Product and Service Lifecycle beschreibt den gemeinsamen Lebenszyklus digitaler Produkte und Services.

Er verbindet Produktentwicklung, Beschaffung, technische Umsetzung, Betrieb, Bereitstellung und Unterstützung in einem gemeinsamen Modell.

Die acht Lifecycle-Aktivitäten sind:

Discover

Design

Acquire

Build

Transition

Operate

Deliver

Support

Die Aktivitäten bilden keinen starren linearen Ablauf. Sie können sich überschneiden, wiederholt werden und sich gegenseitig beeinflussen.

Warum ein gemeinsamer Lebenszyklus notwendig ist

Digitale Produkte und Services wurden in Organisationen häufig getrennt betrachtet.

Produktteams konzentrierten sich beispielsweise auf:

Anforderungen,

Funktionen,

Entwicklung,

Releases,

Roadmaps,

und technische Weiterentwicklung.

Serviceteams konzentrierten sich dagegen auf:

Betrieb,

Servicequalität,

Benutzerunterstützung,

Incidents,

Service Requests,

Service Levels,

und Kommunikation.

Diese Trennung kann zu Problemen führen.

Beispiele:

Eine neue Funktion wird veröffentlicht, ohne den Service Desk vorzubereiten.

Eine Anwendung wird entwickelt, ohne Monitoring und Wiederherstellung ausreichend zu berücksichtigen.

Ein Produktteam bewertet den Release als erfolgreich, obwohl Benutzer den Service nicht zuverlässig verwenden können.

Betriebserfahrungen erreichen die Produktentwicklung nicht.

Anforderungen an Sicherheit, Support und Servicequalität werden erst kurz vor der Einführung betrachtet.

Technische Schulden werden zwischen Entwicklung und Betrieb hin- und hergeschoben.

Produkt- und Serviceteams verwenden unterschiedliche Ziele und Kennzahlen.

ITIL Version 5 verbindet beide Perspektiven deshalb in einem gemeinsamen Product and Service Lifecycle.

Merke

Produkt und Service sind keine voneinander unabhängigen Alternativen.

Sie sind zwei miteinander verbundene Perspektiven auf eine technologiebasierte Lösung.

Produkt- und Serviceperspektive

Die Produktperspektive betrachtet unter anderem:

Fähigkeiten und Funktionen,

technische Architektur,

Roadmap,

Entwicklung,

Investitionen,

Versionen,

technische Schulden,

und den Lebenszyklus der Lösung.

Die Serviceperspektive betrachtet unter anderem:

Nutzung,

Outcomes,

Servicequalität,

Erfahrung,

Support,

Servicebeziehungen,

Verfügbarkeit,

Kontinuität,

und die Zusammenarbeit mit Stakeholdern.

Beispiel: VPN-Lösung

Produktperspektive	Serviceperspektive
VPN-Gateway und Clientsoftware	sicherer Fernzugriff für Benutzer
Authentifizierungsfunktionen	verständlicher und zuverlässiger Anmeldevorgang
unterstützte Betriebssysteme	Nutzbarkeit auf den benötigten Endgeräten
technische Kapazität	ausreichende Leistung für die Benutzer
Softwareversionen	kontrollierte und möglichst störungsarme Aktualisierung
Protokollierung	Unterstützung bei Störungen und Sicherheitsanalysen
Hersteller-Roadmap	langfristige Nutzbarkeit des Fernzugriffs

Beide Perspektiven müssen gemeinsam betrachtet werden.

Eine technisch leistungsfähige VPN-Plattform ermöglicht noch keinen verlässlichen Fernzugriffsservice, wenn:

Benutzer nicht eingerichtet sind,

Berechtigungen fehlen,

der Support nicht vorbereitet wurde,

keine verständliche Anleitung existiert,

die Internetverbindung ungeeignet ist,

oder Störungen nicht wirksam bearbeitet werden.

Die acht Lifecycle-Aktivitäten im Überblick

Aktivität	Zentrale Aufgabe
Discover	Bedürfnisse, Chancen, Ausgangslage und Umfeld verstehen
Design	geeignete Produkte, Services und Lösungen gestalten
Acquire	benötigte Ressourcen, Produkte, Leistungen und Fähigkeiten beschaffen oder zuordnen
Build	Lösungen erstellen, konfigurieren, integrieren und testen
Transition	neue oder geänderte Bestandteile kontrolliert in die vorgesehene Nutzung überführen
Operate	Produkte, Plattformen und technische Fähigkeiten zuverlässig betreiben
Deliver	Services und Serviceangebote für Stakeholder bereitstellen und steuern
Support	Benutzer, Kunden, Produkte und Services bei Fragen, Anfragen und Störungen unterstützen

Die Beschreibungen in dieser Tabelle sind praxisnahe Zusammenfassungen.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen dar.

Lifecycle-Aktivitäten statt starrer Phasen

Die Begriffe können zunächst den Eindruck einer festen Reihenfolge vermitteln:

Discover → Design → Acquire → Build → Transition → Operate → Deliver → Support

Das Modell ist jedoch nicht als starres Wasserfallmodell gedacht.

Jede Aktivität kann:

Erkenntnisse für andere Aktivitäten liefern,

erneut erforderlich werden,

gleichzeitig mit anderen Aktivitäten stattfinden,

Rücksprünge auslösen,

und unterschiedliche Versionen eines Produkts oder Service betreffen.

Beispiel:

Während Version 1 einer Anwendung betrieben, bereitgestellt und unterstützt wird, kann gleichzeitig:

Version 2 gestaltet werden,

eine neue Komponente beschafft werden,

ein Update erstellt und getestet werden,

und eine zukünftige Version untersucht werden.

Produkt- oder Serviceversion	Mögliche aktuelle Aktivität
Version 1.0	Operate, Deliver und Support
Version 1.1	Build und Test
Version 1.2	Design
zukünftige Hauptversion	Discover
abzulösende Altversion	Transition und Operate

Merke

Ein Produkt oder Service befindet sich nicht dauerhaft nur in einer einzigen Lifecycle-Aktivität.

Transitions können zwischen verschiedenen Aktivitäten stattfinden

Transition ist nicht ausschließlich ein einmaliger Schritt zwischen Build und Operate.

Eine kontrollierte Überführung kann an unterschiedlichen Stellen notwendig sein.

Beispiele:

Übergabe neuer Erkenntnisse von Discover an Design

Überführung eines Entwurfs in Beschaffung oder Entwicklung

Übergang von einer Testumgebung in eine Pilotumgebung

Übergang von einem Pilotbetrieb in die allgemeine Nutzung

Übergabe einer neuen Funktion an Betrieb und Support

Migration von einem alten zu einem neuen Anbieter

Außerbetriebnahme einer bisherigen Produktversion

Überführung einer Zwischenlösung in eine dauerhafte Lösung

Die konkrete Form einer Transition hängt vom jeweiligen Produkt, Service, Risiko und Wertstrom ab.

Wichtig

Transition bedeutet nicht, dass ein Team seine Arbeit beendet und die Verantwortung vollständig an ein anderes Team abgibt.

Produkt-, Service-, Betriebs- und Supportverantwortung müssen über den Übergang hinweg zusammenwirken.

Lifecycle, Value System und Value Stream unterscheiden

Begriff	Bedeutung
ITIL Value System	verbindet die übergeordneten Bestandteile der Organisation zur Wertschöpfung
Product and Service Lifecycle	beschreibt acht gemeinsame Aktivitäten über den Lebenszyklus digitaler Produkte und Services
Value Chain	flexibles operatives Modell innerhalb des ITIL Value Systems
Value Stream	konkrete Abfolge von Schritten zur Erreichung eines bestimmten Outcomes
Management Practice	organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Prozess	strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen
Projekt	zeitlich begrenztes Vorhaben zur Erreichung definierter Ziele

Beispiel: Einführung einer neuen Monitoring-Plattform

Der Lifecycle hilft, alle Aktivitäten von Discovery bis Support zu betrachten.

Der Value Stream beschreibt den konkreten Weg von der Anforderung bis zur wirksam eingesetzten Plattform.

Die Practices stellen Fähigkeiten wie Monitoring and Event Management, Change Management und Supplier Management bereit.

Ein Projekt kann Teile der Einführung zeitlich organisieren.

Das Value System verbindet Governance, Prinzipien, Practices, Wertschöpfung und Verbesserung.

Lifecycle und Projektlebenszyklus unterscheiden

Ein Projekt besitzt normalerweise:

einen definierten Anfang,

festgelegte Ziele,

einen begrenzten Umfang,

einen Zeitplan,

und ein formales Ende.

Ein digitales Produkt oder ein Service besteht häufig über das Projekt hinaus.

Beispiel:

Ein Projekt führt eine neue E-Mail-Plattform ein.

Nach Projektende müssen weiterhin durchgeführt werden:

Betrieb,

Monitoring,

Incident-Bearbeitung,

Benutzerunterstützung,

Kapazitätsplanung,

Sicherheitsaktualisierungen,

Lieferantensteuerung,

Verbesserungen,

und spätere Ablösung.

Typischer Fehler

Die Produkt- und Serviceverantwortung endet mit dem Projektabschluss.

Dadurch bleiben Betrieb, Support, technische Schulden und langfristige Weiterentwicklung ungeklärt.

1. Discover

Zentrale Frage

Was wird benötigt, warum wird es benötigt und welche Ausgangslage besteht?

Discover dient dazu, Bedürfnisse, Chancen, Probleme und Rahmenbedingungen zu verstehen.

Mögliche Auslöser sind:

neue Benutzeranforderung,

geändertes Geschäftsziel,

wiederkehrender Incident,

Sicherheitsrisiko,

technische Schulden,

neue gesetzliche Anforderung,

Rückmeldung von Kunden,

neue Technologie,

Lieferantenänderung,

oder mögliches Verbesserungspotenzial.

Discover sollte nicht nur bestätigen, was ein einzelner Anforderer bereits als Lösung vorgeschlagen hat.

Zuerst sollte das zugrunde liegende Bedürfnis verstanden werden.

Beispiel:

Anforderung:

Wir benötigen einen neuen Server.

Mögliche zugrunde liegende Bedürfnisse:

zusätzliche Kapazität,

Ablösung eines nicht unterstützten Systems,

Trennung verschiedener Anwendungen,

bessere Verfügbarkeit,

neue Testumgebung,

oder Erfüllung einer Sicherheitsanforderung.

Erst nach dieser Klärung kann bewertet werden, ob ein neuer Server tatsächlich die geeignete Lösung darstellt.

Typische Inhalte von Discover

Bedürfnisse und Erwartungen

betroffene Stakeholder

gewünschte Outcomes

aktuelle Probleme

vorhandene Produkte und Services

technische und organisatorische Ausgangslage

Chancen und Risiken

Markt- und Technologieentwicklung

gesetzliche und vertragliche Anforderungen

Nachhaltigkeitsanforderungen

Benutzer- und Kundenerfahrung

vorhandene Daten und Messwerte

mögliche Einschränkungen

Annahmen und Unsicherheiten

Leitfragen zu Discover

Welches Problem oder Bedürfnis besteht?

Wer nimmt den erwarteten Wert wahr?

Welches Outcome soll erreicht werden?

Wie sieht der aktuelle Zustand aus?

Was funktioniert bereits?

Welche Daten belegen das Problem?

Welche Stakeholder sind beteiligt?

Welche gesetzlichen und betrieblichen Vorgaben gelten?

Welche Chancen und Risiken bestehen?

Welche Annahmen müssen überprüft werden?

Welche Auswirkungen hätte es, nichts zu verändern?

Welche bestehenden Produkte oder Services könnten angepasst werden?

Muss überhaupt eine neue Lösung entstehen?

Mögliche Ergebnisse von Discover

verständlich beschriebener Bedarf

bekannte Stakeholder

gewünschte Outcomes

erste Wert- und Risikobewertung

dokumentierte Ausgangslage

bekannte Einschränkungen

erste Lösungsoptionen

priorisierte Anforderungen

Entscheidung über weitere Untersuchung

Entscheidung, ein Vorhaben nicht weiterzuverfolgen

Merke

Ein sinnvolles Ergebnis von Discover kann auch die Entscheidung sein, keine neue Lösung einzuführen.

Praxisbeispiel: wiederkehrende Anmeldeprobleme

Mehrere Benutzer können sich regelmäßig nicht anmelden.

Eine vorschnelle Lösung wäre:

Der Verzeichnisdienst muss ersetzt werden.

Discover untersucht zunächst:

Welche Benutzer sind betroffen?

Wann treten die Fehler auf?

Welche Fehlermeldungen erscheinen?

Welche Systeme sind beteiligt?

Gab es kürzlich Changes?

Sind DNS und Zeitsynchronisation stabil?

Liegen Probleme mit MFA oder Zertifikaten vor?

Sind Benutzerprozesse verständlich?

Besteht ein Kapazitätsproblem?

Welche bisherigen Maßnahmen wurden durchgeführt?

Erst danach kann eine geeignete Designentscheidung getroffen werden.

Typische Fehler bei Discover

Lösung festlegen, bevor das Problem verstanden wurde

nur mit einem Stakeholder sprechen

vorhandene Daten ignorieren

Benutzererfahrung nicht berücksichtigen

technische Symptome mit der eigentlichen Ursache verwechseln

bestehende Fähigkeiten und Lösungen übersehen

Unsicherheiten nicht dokumentieren

keine Kriterien für Erfolg definieren

jede technische Neuerung automatisch als Chance betrachten

2. Design

Zentrale Frage

Wie müssen Produkt und Service gestaltet werden, damit das gewünschte Outcome sicher und nachhaltig unterstützt wird?

Design übersetzt Bedürfnisse und Erkenntnisse in eine geeignete Gesamtlösung.

Dabei werden nicht nur technische Funktionen gestaltet.

Zu berücksichtigen sind ebenfalls:

Serviceerfahrung,

Betriebsmodell,

Support,

Sicherheit,

Wiederherstellung,

Informationen,

Prozesse,

Rollen,

Lieferanten,

und Lebenszyklusanforderungen.

Funktionale und nichtfunktionale Anforderungen

Funktionale Anforderungen beschreiben, was eine Lösung leisten soll.

Beispiele:

Benutzer können sich anmelden.

Dateien können gemeinsam bearbeitet werden.

Administratoren können Berechtigungen verwalten.

Monitoring erkennt den Ausfall eines Dienstes.

Nichtfunktionale Anforderungen beschreiben Eigenschaften und Qualitätsanforderungen.

Beispiele:

Verfügbarkeit

Leistung

Skalierbarkeit

Sicherheit

Datenschutz

Wartbarkeit

Bedienbarkeit

Barrierefreiheit

Wiederherstellbarkeit

Protokollierung

Kompatibilität

Nachhaltigkeit

Typischer Fehler

Die Funktionen werden gestaltet, während Betrieb, Support, Sicherheit und Wiederherstellung erst kurz vor der Einführung betrachtet werden.

Design betrachtet alle vier Dimensionen

Organizations and People

Welche Rollen und Fähigkeiten werden benötigt?

Wer verantwortet Produkt und Service?

Wie werden Benutzer und Supportmitarbeiter geschult?

Information and Technology

Welche Architektur, Daten und Technologien werden benötigt?

Wie werden Integration, Sicherheit und Wiederherstellung gestaltet?

Partners and Suppliers

Welche externen Leistungen werden benötigt?

Welche Anforderungen müssen Verträge und Supportvereinbarungen erfüllen?

Value Streams and Processes

Wie erfolgen Bestellung, Bereitstellung, Nutzung, Support und Verbesserung?

Welche Übergaben und Kontrollen sind notwendig?

Leitfragen zu Design

Welche Outcomes und Erfahrungen sollen unterstützt werden?

Welche Funktionen werden benötigt?

Welche Qualitätsanforderungen gelten?

Welche Sicherheits- und Datenschutzanforderungen bestehen?

Wie wird der Service betrieben und unterstützt?

Welche Abhängigkeiten und Schnittstellen bestehen?

Welche Daten werden verarbeitet?

Welche Kapazität und Verfügbarkeit werden benötigt?

Wie erfolgen Backup und Wiederherstellung?

Welche Rollen und Fähigkeiten werden benötigt?

Welche Lieferanten werden beteiligt?

Wie wird die Lösung überwacht?

Wie werden Updates und Changes durchgeführt?

Wie kann die Lösung später erweitert oder abgelöst werden?

Wie wird der Erfolg überprüft?

Betrieb und Support bereits im Design berücksichtigen

Ein Produkt sollte nicht erst nach seiner Entwicklung „betriebsfähig gemacht“ werden.

Bereits im Design sollten unter anderem berücksichtigt werden:

Monitoring

Protokollierung

Fehlerdiagnose

Backup

Wiederherstellung

Kapazität

Verfügbarkeit

Patch- und Updateverfahren

Zugriffskontrolle

Supportinformationen

Service-Desk-Vorbereitung

bekannte Fehlerszenarien

Eskalationswege

Dokumentation

Außerbetriebnahme

Merke

Operability und Supportability sind keine nachträglichen Zusatzfunktionen.

Sie gehören zur Gestaltung eines nutzbaren und nachhaltigen digitalen Produkts und Service.

Mögliche Ergebnisse von Design

Lösungsentwurf

Produkt- und Serviceanforderungen

Architektur

Prototyp

Serviceangebot

Sicherheitskonzept

Supportmodell

Monitoring-Konzept

Betriebs- und Wiederherstellungskonzept

Lieferantenanforderungen

Teststrategie

Transition-Planung

Erfolgskriterien

Plan für spätere Ablösung

Typische Fehler bei Design

nur sichtbare Funktionen gestalten

Benutzer und Support nicht einbeziehen

Betriebsanforderungen zu spät berücksichtigen

Sicherheitskontrollen nachträglich ergänzen

keine Exit- oder Ablösungsplanung

Lieferantenabhängigkeiten übersehen

unklare Erfolgskriterien

unnötige Komplexität aufbauen

Design nicht anhand von Feedback überprüfen

3. Acquire

Zentrale Frage

Welche Produkte, Leistungen, Ressourcen und Fähigkeiten werden benötigt und wie werden sie beschafft oder bereitgestellt?

Acquire umfasst die Beschaffung oder Zuordnung benötigter Bestandteile.

Dazu können gehören:

Hardware

Software

Cloud-Services

Lizenzen

externe Dienstleistungen

Daten

Infrastrukturkapazität

Fachwissen

Schulungen

Personal

Entwicklungsleistungen

Supportverträge

und Lieferantenressourcen

Acquire bedeutet nicht automatisch, dass etwas von einem externen Anbieter gekauft werden muss.

Mögliche Entscheidungen sind:

selbst entwickeln

intern wiederverwenden

Standardprodukt kaufen

Cloud-Service abonnieren

Open-Source-Lösung einsetzen

Dienstleistung auslagern

gemeinsam mit einem Partner entwickeln

oder eine bestehende Fähigkeit erweitern

Make, Buy, Reuse oder Partner

Möglichkeit	Beispiel
Make	eigene Anwendung oder Automatisierung entwickeln
Buy	Standardsoftware oder Hardware beschaffen
Reuse	vorhandene Plattform oder Komponente weiterverwenden
Subscribe	Cloud- oder SaaS-Service abonnieren
Partner	Lösung gemeinsam mit einem externen Partner entwickeln
Outsource	Tätigkeit oder Servicebestandteil extern erbringen lassen

Die Entscheidung sollte nicht nur anhand des Anschaffungspreises erfolgen.

Zu berücksichtigen sind beispielsweise:

benötigte Outcomes

Gesamtkosten

Geschwindigkeit

vorhandene Fähigkeiten

Integrationsaufwand

Sicherheit

Datenschutz

Lieferantenabhängigkeit

Datenportabilität

Wartung

Support

Skalierbarkeit

und spätere Ablösung

Leitfragen zu Acquire

Welche Ressourcen und Fähigkeiten werden benötigt?

Was ist bereits vorhanden?

Was kann intern bereitgestellt werden?

Was muss extern beschafft werden?

Welche Lieferanten kommen infrage?

Welche Anforderungen müssen vertraglich geregelt werden?

Welche Lizenzen werden benötigt?

Welche Sicherheits- und Datenschutzanforderungen gelten?

Welche Abhängigkeiten entstehen?

Können Daten und Konfigurationen später exportiert werden?

Welche internen Fähigkeiten müssen erhalten bleiben?

Wie wird die Lieferantenleistung überwacht?

Was geschieht bei Vertragsende oder Lieferantenausfall?

Sind Beschaffungszeit und Verfügbarkeit realistisch?

Beschaffung ist mehr als Bestellung

Eine technische Bestellung allein stellt noch keine nutzbare Ressource bereit.

Beispiel: neue Firewall

Zusätzlich zur Hardware können benötigt werden:

Lizenzen

Supportvertrag

Rackplatz

Stromversorgung

Netzwerkanschlüsse

Managementzugang

Zertifikate

Administrationswissen

Ersatzteile

Monitoring

Dokumentation

Backup der Konfiguration

und ein Ablösungsplan

Typischer Fehler

Der Kaufpreis wird geplant, während Betriebskosten, Lizenzen, Support und notwendige Fähigkeiten nicht berücksichtigt werden.

Lieferanten und Exit-Planung

Bei externen Leistungen sollte bereits während Acquire geprüft werden:

Wie werden Daten zurückgegeben?

Welche Exportformate existieren?

Welche Unterauftragnehmer werden eingesetzt?

Welche Support- und Eskalationswege gelten?

Welche Serviceziele werden zugesichert?

Welche Sicherheitsnachweise existieren?

Wie werden Vertragsänderungen behandelt?

Welche Kosten entstehen bei einer Migration?

Wie kann die Leistung später ersetzt werden?

Welche internen Kenntnisse müssen erhalten bleiben?

Mögliche Ergebnisse von Acquire

beschaffte Produkte und Leistungen

zugewiesene interne Ressourcen

Lizenzen und Nutzungsrechte

Verträge und Vereinbarungen

Lieferantenbeziehungen

bereitgestellte Umgebungen

benötigte Fähigkeiten und Schulungen

bekannte Lieferantenrisiken

Exit- und Übergangsanforderungen

geprüfte Liefergegenstände

Typische Fehler bei Acquire

nur den niedrigsten Preis bewerten

Betriebskosten übersehen

Fähigkeiten und Schulungen nicht einplanen

Supportanforderungen nicht vertraglich klären

Lieferantenabhängigkeit ignorieren

keine Datenportabilität vorsehen

Lizenzen falsch dimensionieren

Beschaffung und technische Integration nicht abstimmen

Exit-Planung auf später verschieben

4. Build

Zentrale Frage

Wie wird die entworfene Lösung erstellt, konfiguriert, integriert und überprüft?

Build umfasst die praktische Erstellung und technische Umsetzung.

Dazu können gehören:

Softwareentwicklung

Hardwareinstallation

Systemkonfiguration

Cloud-Bereitstellung

Integration

Datenmigration

Automatisierung

Erstellung von Schnittstellen

Konfiguration von Monitoring

Sicherheitsmaßnahmen

Dokumentation

und Tests

Build bedeutet nicht ausschließlich Programmierung.

Auch die Konfiguration einer Standardsoftware oder der Aufbau einer Infrastruktur kann Teil dieser Aktivität sein.

Build und Test gehören zusammen

Eine erstellte Lösung muss überprüft werden.

Mögliche Testarten sind:

Funktionstest

Integrationstest

Sicherheitstest

Leistungstest

Wiederherstellungstest

Kompatibilitätstest

Benutzerakzeptanztest

Failover-Test

Migrationstest

Überwachungstest

Rückfalltest

und Test der Supportfähigkeit

Tests sollten sich an Anforderungen und Risiken orientieren.

Merke

Ein erfolgreicher Funktionstest beweist nicht automatisch, dass eine Lösung sicher, betreibbar, wiederherstellbar und für Benutzer geeignet ist.

Leitfragen zu Build

Entspricht die Umsetzung dem Design?

Welche Komponenten müssen erstellt oder konfiguriert werden?

Welche Standards und Sicherheitsvorgaben gelten?

Welche Abhängigkeiten bestehen?

Wie werden Änderungen versioniert?

Welche Umgebungen werden verwendet?

Wie werden Zugangsdaten und Geheimnisse geschützt?

Welche Tests sind notwendig?

Sind Testdaten geeignet und zulässig?

Wie werden Fehler dokumentiert und korrigiert?

Wie wird die Konfiguration reproduzierbar?

Werden Betrieb, Monitoring und Support vorbereitet?

Ist die Dokumentation ausreichend?

Ist eine Rückfallmöglichkeit vorhanden?

Reproduzierbarkeit

Technische Lösungen sollten möglichst reproduzierbar aufgebaut werden.

Geeignete Maßnahmen können sein:

dokumentierte Konfiguration

Versionsverwaltung

Infrastructure as Code

automatisierte Bereitstellung

standardisierte Images

Konfigurationsmanagement

automatisierte Tests

und nachvollziehbare Abhängigkeiten

Reproduzierbarkeit unterstützt:

Wiederherstellung

Skalierung

Fehleranalyse

Tests

Sicherheit

und spätere Änderungen

Build umfasst Betriebsbereitschaft

Während Build sollten nicht nur Produktfunktionen erstellt werden.

Ebenfalls vorzubereiten sind:

Monitoring

Alarmierung

Protokollierung

Backup

Wiederherstellung

Administrationszugänge

Sicherheitskontrollen

Betriebsdokumentation

Supportinformationen

bekannte Fehler

Kapazitätsgrenzen

und Eskalationsinformationen

Mögliche Ergebnisse von Build

erstellte oder konfigurierte Lösung

integrierte Komponenten

getestete Produktversion

technische Dokumentation

Betriebsdokumentation

automatisierte Bereitstellung

bekannte Fehler und Einschränkungen

Testergebnisse

Sicherheitsnachweise

Monitoring und Protokollierung

vorbereitete Transition

Typische Fehler bei Build

nur den Normalfall testen

produktive Änderungen manuell und undokumentiert durchführen

Betrieb und Support nicht einbeziehen

Konfiguration nicht versionieren

Zugangsdaten unsicher behandeln

keine Wiederherstellung testen

Test- und Produktivumgebung stark voneinander abweichen lassen

bekannte Fehler nicht dokumentieren

eine technisch fertige Lösung automatisch als einsatzbereit betrachten

5. Transition

Zentrale Frage

Wie wird eine neue oder geänderte Lösung kontrolliert in die vorgesehene Nutzung und Verantwortung überführt?

Transition verbindet Entwicklung, Beschaffung und Aufbau mit der tatsächlichen Verwendung, dem Betrieb, der Bereitstellung und dem Support.

Mögliche Bestandteile sind:

Change-Bewertung

Releaseplanung

Deployment

Datenmigration

Pilotbetrieb

Benutzerkommunikation

Schulung

Wissensübergabe

Betriebsfreigabe

Servicevalidierung

Rückfallplanung

und Erfolgskontrolle

Transition ist mehr als Deployment

Deployment beschreibt die technische Übertragung von Komponenten in eine Zielumgebung.

Transition umfasst zusätzlich die organisatorische und servicebezogene Einsatzbereitschaft.

Deployment	Transition
Software wird installiert.	Produkt und Service werden kontrolliert in die Nutzung überführt.
Konfiguration wird verteilt.	Betrieb, Support und Stakeholder sind vorbereitet.
technische Komponente wird aktiviert.	Funktion, Erfahrung, Risiken und Outcomes werden überprüft.
Daten werden migriert.	Datenqualität, Benutzerzugriff und Geschäftsabläufe werden validiert.

Merke

Technisch bereitgestellt bedeutet nicht automatisch betriebsbereit, supportfähig oder für Benutzer nutzbar.

Operational Readiness

Vor einer produktiven Nutzung sollte geprüft werden:

Ist die Lösung ausreichend getestet?

Ist Monitoring aktiv?

Sind Backup und Wiederherstellung vorbereitet?

Sind Rollen und Verantwortlichkeiten bekannt?

Ist der Service Desk informiert?

Existieren Support- und Eskalationswege?

Sind Dokumentationen verfügbar?

Wurden Benutzer informiert oder geschult?

Sind Lizenzen und Verträge gültig?

Ist die Sicherheitsfreigabe erfolgt?

Sind bekannte Einschränkungen akzeptiert?

Ist ein Rückfallplan vorhanden?

Wie wird der Erfolg nach der Einführung kontrolliert?

Leitfragen zu Transition

Was wird überführt?

Welche Produkte und Services sind betroffen?

Welche Stakeholder müssen beteiligt werden?

Welche Risiken bestehen?

Welche Autorisierung ist erforderlich?

Wie wird die Einführung geplant?

Ist ein Pilot sinnvoll?

Welche Daten müssen migriert werden?

Welche Unterbrechungen können entstehen?

Wie werden Benutzer informiert?

Wie werden Betrieb und Support vorbereitet?

Welche Rückfallmöglichkeiten bestehen?

Wer entscheidet über Fortsetzung oder Abbruch?

Wie wird die erfolgreiche Nutzung bestätigt?

Welche Nacharbeiten sind notwendig?

Rückfall und Wiederherstellung

Ein Rückfallplan sollte möglichst klären:

Unter welchen Bedingungen wird zurückgefallen?

Wer darf die Entscheidung treffen?

Wie wird der vorherige Zustand wiederhergestellt?

Welche Datenänderungen müssen berücksichtigt werden?

Wie lange dauert der Rückfall?

Welche Benutzer sind betroffen?

Wie wird kommuniziert?

Wie wird das Ergebnis kontrolliert?

Ein Rückfall ist nicht immer die beste oder technisch mögliche Option.

Bei Datenmigrationen oder unumkehrbaren Änderungen kann stattdessen ein alternativer Wiederherstellungsplan notwendig sein.

Mögliche Ergebnisse von Transition

kontrolliert eingeführte Produktversion

aktivierter Service

migrierte Daten

vorbereiteter Betrieb

vorbereiteter Support

geschulte Beteiligte

aktualisierte Dokumentation

validierte Servicefunktion

dokumentierte Einschränkungen

überwachte Einführungsphase

abgeschlossene oder geplante Nacharbeiten

Typische Fehler bei Transition

Transition mit Installation gleichsetzen

Service Desk und Benutzer zu spät informieren

keine Betriebsbereitschaft prüfen

ungetestete Migration durchführen

Rückfallplan nur formal dokumentieren

Erfolg nur technisch prüfen

bekannte Fehler nicht kommunizieren

Verantwortungsübergabe ohne Wissenstransfer

direkt nach Deployment alle Beteiligten aus dem Vorhaben abziehen

6. Operate

Zentrale Frage

Wie werden Produkte, Plattformen und technische Fähigkeiten zuverlässig, sicher und wirtschaftlich betrieben?

Operate betrachtet den laufenden technischen Betrieb.

Dazu gehören beispielsweise:

Systembetrieb

Überwachung

Wartung

Kapazitätssteuerung

Verfügbarkeitsmanagement

Sicherheitsbetrieb

Backup

Wiederherstellung

Patchmanagement

Jobsteuerung

Verwaltung technischer Konfigurationen

und Behandlung betrieblicher Ereignisse

Operate sorgt dafür, dass die technischen Fähigkeiten vorhanden bleiben, auf denen Services aufbauen.

Operate und Deliver unterscheiden

Operate konzentriert sich stärker auf den laufenden Betrieb der technischen Produkt- und Plattformbestandteile.

Deliver konzentriert sich stärker darauf, Services und Serviceangebote für Stakeholder nutzbar bereitzustellen.

Beispiel: E-Mail

Operate

Mailplattform betreiben

Kapazität überwachen

Sicherheitsupdates installieren

Warteschlangen kontrollieren

Backup und Wiederherstellung sicherstellen

technische Verfügbarkeit überwachen

Deliver

E-Mail-Service für Benutzer bereitstellen

Zugänge und Leistungsumfang steuern

Serviceerwartungen abstimmen

Nutzung und Servicequalität bewerten

Benutzererfahrung berücksichtigen

Beide Aktivitäten überschneiden und beeinflussen sich.

Leitfragen zu Operate

Welche Komponenten müssen betrieben werden?

Welche Betriebsziele gelten?

Wie werden Verfügbarkeit und Leistung überwacht?

Welche Wartungsarbeiten sind notwendig?

Wie werden Patches und Updates durchgeführt?

Wie werden Kapazitätsgrenzen erkannt?

Wie werden Sicherheitsereignisse behandelt?

Funktionieren Backup und Wiederherstellung?

Sind technische Abhängigkeiten bekannt?

Welche Automatisierungen werden überwacht?

Wie werden technische Schulden behandelt?

Welche Bereitschaft oder Rufbereitschaft ist notwendig?

Wie wird bei Lieferantenausfällen reagiert?

Wann muss eine Komponente ersetzt oder abgelöst werden?

Stabilität und Veränderung

Operate bedeutet nicht, technische Systeme möglichst unverändert zu lassen.

Ein stabiler Betrieb benötigt regelmäßig:

Sicherheitsupdates

Kapazitätsanpassungen

Fehlerkorrekturen

Zertifikatserneuerungen

Konfigurationsverbesserungen

Austausch veralteter Komponenten

und Anpassung an neue Anforderungen

Diese Änderungen müssen kontrolliert erfolgen.

Merke

Stabilität entsteht nicht durch Stillstand.

Sie entsteht durch kontrollierte Veränderung, Überwachung und angemessene Wiederherstellungsfähigkeit.

Technische Schulden im Betrieb

Technische Schulden können sich zeigen durch:

nicht unterstützte Software

veraltete Hardware

manuelle Sonderkonfigurationen

fehlende Automatisierung

nicht dokumentierte Abhängigkeiten

dauerhaft verwendete Zwischenlösungen

unsichere Altprotokolle

oder nicht reproduzierbare Systeme

Sie sollten:

sichtbar gemacht,

hinsichtlich Risiko bewertet,

priorisiert,

verantwortet,

und kontrolliert reduziert

werden.

Mögliche Ergebnisse von Operate

laufende technische Fähigkeiten

überwachte Plattformen

durchgeführte Wartung

gesicherte und wiederherstellbare Daten

bekannte Kapazität

behandelte Events

dokumentierte technische Risiken

aktuelle Konfigurationsinformationen

betriebliche Leistungsdaten

identifizierte Verbesserungsmöglichkeiten

Typische Fehler bei Operate

nur auf Verfügbarkeit achten

Warnungen ohne klare Reaktion erzeugen

Backup-Erfolg mit Wiederherstellbarkeit verwechseln

technische Schulden nicht sichtbar machen

Wartung dauerhaft verschieben

Abhängigkeiten nicht dokumentieren

Betrieb ausschließlich reaktiv gestalten

technische Kennzahlen nicht mit Service-Outcomes verbinden

7. Deliver

Zentrale Frage

Wie werden Services und Serviceangebote so bereitgestellt, dass Stakeholder die vorgesehenen Outcomes erreichen können?

Deliver betrachtet die tatsächliche Bereitstellung und Steuerung des Service gegenüber Benutzern, Kunden und weiteren Stakeholdern.

Dazu können gehören:

Serviceangebote

Zugangs- und Nutzungsbereitstellung

Servicebeziehungen

Abstimmung von Erwartungen

Servicequalität

Service Levels

Kommunikation

Erfüllung vereinbarter Leistungen

Benutzererfahrung

und Überprüfung erreichter Outcomes

Technische Verfügbarkeit und Servicebereitstellung

Ein technisches System kann verfügbar sein, während der Service für den Benutzer nicht nutzbar ist.

Beispiele:

Die Anwendung läuft, aber der Benutzer besitzt keine Lizenz.

Das VPN-Gateway ist erreichbar, aber MFA funktioniert nicht.

Der Fileserver ist verfügbar, aber Berechtigungen fehlen.

Die E-Mail-Plattform läuft, aber DNS ist fehlerhaft.

Das Portal ist erreichbar, aber der Geschäftsprozess kann nicht abgeschlossen werden.

Deliver betrachtet deshalb nicht nur technische Funktion, sondern auch die tatsächliche Nutzbarkeit und Leistung des Service.

Leitfragen zu Deliver

Welcher Service wird bereitgestellt?

Welche Serviceangebote bestehen?

Wer darf den Service nutzen?

Welche Outcomes werden erwartet?

Welche Erwartungen und Vereinbarungen gelten?

Welche Zugänge und Ressourcen werden benötigt?

Wie wird die Nutzung ermöglicht?

Welche Qualität wird wahrgenommen?

Welche Servicezeiten und Serviceziele gelten?

Wie werden Abweichungen kommuniziert?

Wie werden Rückmeldungen erfasst?

Werden vereinbarte Leistungen tatsächlich erreicht?

Entspricht der Service weiterhin dem Bedarf?

Welche Verbesserungen sind notwendig?

Serviceangebot

Ein Serviceangebot kann unterschiedliche Bestandteile verbinden:

Waren oder übertragene Ressourcen

Zugang zu Ressourcen

Servicehandlungen

Praxisbeispiel: Arbeitsplatzservice

Mögliche Bestandteile:

Endgerät

Benutzerkonto

Softwarelizenzen

Netzwerkzugang

Dateiablage

E-Mail

Support

Geräteaustausch

Sicherheitsmaßnahmen

und Wartung

Der Benutzer benötigt normalerweise nicht jeden technischen Bestandteil einzeln.

Er benötigt einen arbeitsfähigen Arbeitsplatz als nutzbares Gesamtergebnis.

Servicequalität und Erfahrung

Servicequalität kann sowohl objektive als auch subjektive Aspekte besitzen.

Mögliche objektive Informationen:

Verfügbarkeit

Reaktionszeit

Lösungszeit

Leistung

Fehlerquote

Erfüllungsquote

Wiederherstellungszeit

Mögliche Erfahrungsaspekte:

Verständlichkeit

Zuverlässigkeit aus Benutzersicht

Einfachheit der Nutzung

Qualität der Kommunikation

Vertrauen

wahrgenommene Geschwindigkeit

und Aufwand für den Benutzer

Merke

Ein Service kann technische Zielwerte erfüllen und trotzdem eine schlechte Benutzererfahrung erzeugen.

Mögliche Ergebnisse von Deliver

nutzbarer Service

erfüllte Service Requests

bereitgestellte Zugänge

abgestimmte Erwartungen

gemessene Serviceleistung

bekannte Benutzererfahrung

dokumentierte Serviceabweichungen

aktualisierte Serviceangebote

identifizierte Verbesserungen

erreichte oder teilweise erreichte Outcomes

Typische Fehler bei Deliver

Servicebereitstellung mit technischem Betrieb gleichsetzen

nur interne Kennzahlen verwenden

Benutzererfahrung nicht berücksichtigen

Serviceangebote unverständlich beschreiben

Zugangs- und Berechtigungsprozesse nicht einbeziehen

Leistungen zusagen, die technisch oder organisatorisch nicht unterstützt werden

Servicequalität ohne Stakeholderfeedback bewerten

8. Support

Zentrale Frage

Wie werden Benutzer, Kunden, Produkte und Services bei Fragen, Anfragen, Problemen und Störungen wirksam unterstützt?

Support umfasst die Unterstützung während der Nutzung eines Produkts oder Service.

Dazu können gehören:

Service Desk

Incident-Bearbeitung

Service Requests

technische Unterstützung

Wissensbereitstellung

Kommunikation

Eskalation

Problem Management

Benutzerberatung

und Rückmeldungen an Produkt- und Serviceteams

Support beschränkt sich nicht darauf, Tickets möglichst schnell zu schließen.

Das Ziel besteht darin, negative Auswirkungen zu begrenzen, Nutzung zu ermöglichen und wertvolle Erkenntnisse zurück in den Lebenszyklus zu führen.

Support als Informationsquelle

Support erhält häufig direkte Informationen über:

Benutzerprobleme

unklare Funktionen

wiederkehrende Fehler

fehlende Dokumentation

Schulungsbedarf

schlechte Benutzererfahrung

nicht erfüllte Erwartungen

und Verbesserungspotenzial

Diese Erkenntnisse sollten nicht ausschließlich im einzelnen Ticket bleiben.

Sie können zurückfließen in:

Discover

Design

Build

Operate

Deliver

Problem Management

Knowledge Management

und Continual Improvement

Merke

Support ist nicht nur die letzte Aktivität des Modells.

Support liefert Erkenntnisse für den gesamten Product and Service Lifecycle.

Leitfragen zu Support

Welche Unterstützung benötigen Benutzer und Kunden?

Wie erreichen sie die zuständige Stelle?

Welche Informationen müssen erfasst werden?

Wie werden Incidents und Service Requests unterschieden?

Wie werden Auswirkungen und Dringlichkeit bewertet?

Welche Lösungen und Wissensartikel existieren?

Wann muss eskaliert werden?

Wie werden Benutzer informiert?

Welche Lieferanten müssen eingebunden werden?

Wie wird die Wiederherstellung geprüft?

Welche wiederkehrenden Muster bestehen?

Welche Erkenntnisse müssen an Produkt- und Serviceteams weitergegeben werden?

Wie wird die Supporterfahrung bewertet?

Welche Unterstützung kann verhindert oder vereinfacht werden?

Supportfähigkeit bereits vorher aufbauen

Wirksamer Support benötigt unter anderem:

verständliche Serviceinformationen

eindeutige Kontaktwege

geschulte Mitarbeiter

technische Diagnosemöglichkeiten

Zugriffsberechtigungen

aktuelle Dokumentation

Knowledge-Artikel

Monitoring- und Protokolldaten

bekannte Eskalationswege

Lieferantenkontakte

und klare Verantwortlichkeiten

Diese Voraussetzungen müssen bereits in Design, Build und Transition berücksichtigt werden.

Mögliche Ergebnisse von Support

wiederhergestellte Services

erfüllte Benutzeranfragen

gelöste technische Fragen

bereitgestelltes Wissen

dokumentierte Incidents

identifizierte Probleme

weitergeleitetes Benutzerfeedback

verbesserte Supportinformationen

bekannte Produkt- und Servicefehler

Vorschläge für Continual Improvement

Typische Fehler bei Support

Ticketabschluss mit erreichtem Outcome gleichsetzen

Benutzer mehrfach dieselben Informationen liefern lassen

nur Symptome behandeln

bekannte Lösungen nicht dokumentieren

wiederkehrende Incidents nicht an Problem Management übergeben

Support nicht vor Releases informieren

Benutzerfeedback nicht weiterverwenden

interne Kennzahlen wichtiger behandeln als die tatsächliche Wiederherstellung

Zusammenwirken der acht Aktivitäten

Praxisbeispiel: Einführung eines neuen sicheren Fernzugriffs

Discover

Bedarf an Remote-Arbeit verstehen

Benutzergruppen und Anwendungen bestimmen

bisherige Probleme und Risiken untersuchen

gewünschte Outcomes festlegen

Design

VPN- oder Zero-Trust-Lösung gestalten

Identität, MFA, Endgeräte und Support einplanen

Sicherheits-, Verfügbarkeits- und Erfahrungsanforderungen definieren

Acquire

Plattform, Lizenzen und Supportleistungen beschaffen

benötigte Schulungen und externe Fähigkeiten organisieren

Build

Systeme konfigurieren

Integrationen erstellen

Sicherheitsregeln, Monitoring und Dokumentation aufbauen

Funktion, Leistung und Wiederherstellung testen

Transition

Pilotgruppe einführen

Benutzer und Service Desk vorbereiten

Daten und Konfigurationen überführen

Rückfall- und Kommunikationsplan bereitstellen

Operate

Gateways, Identitätsdienste und Zertifikate betreiben

Leistung, Sicherheit und Kapazität überwachen

Updates und Wartung durchführen

Deliver

Fernzugriffsservice für berechtigte Benutzer bereitstellen

Serviceerwartungen und Nutzungsbedingungen kommunizieren

Qualität und Erfahrung bewerten

Support

Anmeldeprobleme und Anfragen bearbeiten

Wissen bereitstellen

wiederkehrende Fehler untersuchen

Feedback an Produkt- und Serviceteams zurückführen

Continual Improvement über den gesamten Lifecycle

Continual Improvement ist nicht auf das Ende des Lebenszyklus beschränkt.

Jede Aktivität kann verbessert werden.

Lifecycle-Aktivität	Beispiel für eine Verbesserung
Discover	Benutzerfeedback früher und systematischer erfassen
Design	Betriebs- und Sicherheitsanforderungen früher berücksichtigen
Acquire	Exit-Anforderungen in Lieferantenbewertungen aufnehmen
Build	Tests und Bereitstellung stärker automatisieren
Transition	Pilot- und Rückfallverfahren verbessern
Operate	wiederkehrende Wartung automatisieren
Deliver	Serviceangebote verständlicher gestalten
Support	bekannte Lösungen schneller auffindbar machen

Erkenntnisse aus späteren Aktivitäten können frühere Aktivitäten erneut auslösen.

Beispiel:

Support erkennt viele Anfragen zu einer unverständlichen Funktion.

Dies kann führen zu:

erneutem Discover der Benutzerbedürfnisse,

angepasstem Design,

verändertem Build,

neuer Transition,

und verbesserter Bereitstellung.

Governance über den gesamten Lifecycle

Governance wirkt auf alle acht Aktivitäten.

Zu klären sind unter anderem:

Welche Ziele und Prioritäten gelten?

Wer besitzt Entscheidungsbefugnis?

Welche Risiken dürfen akzeptiert werden?

Welche gesetzlichen und vertraglichen Anforderungen gelten?

Welche Kontrollen sind notwendig?

Wie werden Investitionen priorisiert?

Wie werden Ergebnisse überwacht?

Wer trägt Verantwortung für Produkt und Service?

Wann muss eine Aktivität erneut bewertet werden?

Wann muss ein Produkt oder Service beendet werden?

Governance sollte nicht erst bei der produktiven Einführung beginnen.

Ungeeignete Grundentscheidungen in Discover, Design oder Acquire können später nur mit hohem Aufwand korrigiert werden.

Die Guiding Principles im Lifecycle

Guiding Principle	Anwendung im Lifecycle
Focus on value	jede Aktivität am benötigten Outcome ausrichten
Start where you are	bestehende Produkte, Fähigkeiten und Daten berücksichtigen
Progress iteratively with feedback	Versionen, Piloten und kontrollierte Schritte verwenden
Collaborate and promote visibility	Produkt-, Service-, Betriebs- und Supportteams verbinden
Think and work holistically	alle acht Aktivitäten und vier Dimensionen berücksichtigen
Keep it simple and practical	unnötige Übergaben und Komplexität vermeiden
Optimize and automate	Arbeitsweisen verbessern und geeignete Teile automatisieren

Künstliche Intelligenz im Lifecycle

KI kann in allen Lifecycle-Aktivitäten verwendet werden.

Beispiele:

Aktivität	Mögliche KI-Unterstützung
Discover	Muster in Feedback und Nutzungsdaten erkennen
Design	Varianten analysieren oder Prototypen unterstützen
Acquire	Angebote und Anforderungen vergleichen
Build	Code-, Konfigurations- oder Testunterstützung
Transition	Risiken und Migrationsdaten analysieren
Operate	Anomalien und mögliche Ausfälle erkennen
Deliver	Services personalisieren oder Interaktionen unterstützen
Support	Tickets klassifizieren und Lösungsvorschläge bereitstellen

Dabei bleiben notwendig:

klare Verantwortlichkeit

Datenqualität

Datenschutz

Informationssicherheit

menschliche Kontrolle

Überwachung

Nachvollziehbarkeit

und Risikobewertung

Sicherheitsrelevant

KI-Unterstützung ersetzt nicht die Verantwortung der zuständigen Personen und Organisation.

Wo befindet sich die Außerbetriebnahme?

Das offizielle ITIL-Version-5-Modell nennt acht Aktivitäten und enthält keine separate neunte Aktivität mit der Bezeichnung Retire.

Die Ablösung oder Außerbetriebnahme eines Produkts oder Service muss trotzdem kontrolliert gestaltet werden.

Dazu können Beiträge aus mehreren Aktivitäten gehören:

Discover

Warum soll die bisherige Lösung beendet werden?

Welche Stakeholder und Abhängigkeiten sind betroffen?

Design

Wie sieht die Ziel- oder Übergangslösung aus?

Welche Archivierungs- und Aufbewahrungsanforderungen gelten?

Acquire und Build

Welche Ersatzlösung und Migrationswerkzeuge werden benötigt?

Transition

Wie werden Benutzer, Daten und Abhängigkeiten überführt?

Wie wird die alte Lösung kontrolliert deaktiviert?

Operate

Wie lange muss die Altumgebung parallel betrieben werden?

Wie werden Restzugriffe und technische Risiken überwacht?

Deliver und Support

Wie werden Serviceangebote, Benutzerinformationen und Support angepasst?

Wie werden Fragen während der Ablösung behandelt?

Zusätzlich können Practices wie folgende beteiligt sein:

Change Management

IT Asset Management

Service Configuration Management

Information Security Management

Supplier Management

Knowledge Management

und Continual Improvement

Wichtig

Außerbetriebnahme bedeutet nicht nur, ein System auszuschalten.

Daten, Zugänge, Verträge, Assets, Dokumentationen, Abhängigkeiten und Sicherheitsanforderungen müssen ebenfalls behandelt werden.

Anwendung bei einem Incident

Ein Incident findet hauptsächlich während Operate, Deliver oder Support statt.

Seine Erkenntnisse können jedoch den gesamten Lifecycle beeinflussen.

Beispiel:

Ein Zertifikat läuft ab und verursacht einen Serviceausfall.

Support

Incident erfassen

Benutzer informieren

Wiederherstellung koordinieren

Operate

Zertifikat erneuern

Systeme und Abhängigkeiten kontrollieren

Discover

untersuchen, warum das Risiko nicht rechtzeitig erkannt wurde

Design

Zertifikatsverwaltung und Verantwortlichkeiten verbessern

Acquire

falls notwendig geeignetes Zertifikats- oder Monitoring-Werkzeug beschaffen

Build

automatisierte Erfassung und Alarmierung erstellen

Transition

neue Überwachung kontrolliert einführen

Deliver

prüfen, ob der Service wieder vollständig nutzbar ist

Anwendung bei einem Change

Ein Change kann mehrere Lifecycle-Aktivitäten betreffen.

Beispiel: Datenbank-Upgrade

Discover: Notwendigkeit, Risiken und Abhängigkeiten verstehen

Design: Zielversion, Architektur und Migrationsweg festlegen

Acquire: Lizenzen, Support oder zusätzliche Ressourcen beschaffen

Build: Zielumgebung konfigurieren und Migration testen

Transition: Upgrade kontrolliert durchführen

Operate: neue Version überwachen und warten

Deliver: Servicefunktion und Leistung aus Stakeholdersicht prüfen

Support: bekannte Fehler und Benutzerfragen bearbeiten

Merke

Change Management unterstützt die kontrollierte Veränderung.

Der Product and Service Lifecycle zeigt den größeren Zusammenhang, in dem die Veränderung stattfindet.

Anwendung bei einem kleinen Standardservice

Nicht jede Servicebereitstellung benötigt ein umfangreiches Projekt.

Beispiel: Standardsoftware für einen Mitarbeiter bereitstellen

Discover

benötigte Software und geschäftlichen Zweck klären

Design

vorgesehenes Standardpaket und Berechtigungsmodell verwenden

Acquire

vorhandene Lizenz zuordnen oder zusätzliche Lizenz beschaffen

Build

Softwarepaket und Konfiguration bereitstellen

Transition

kontrolliert auf das Endgerät verteilen

Operate

Plattform und Paketverwaltung betreiben

Deliver

Anwendung für den Benutzer freischalten

Support

Installation und Nutzung bei Bedarf unterstützen

Bei einem standardisierten und risikoarmen Fall können viele Schritte automatisiert und sehr kompakt ausgeführt werden.

Typische Missverständnisse

Missverständnis 1: Die Aktivitäten werden immer einmal nacheinander durchgeführt

Tatsächlich können sie wiederholt, übersprungen, kombiniert oder gleichzeitig durchgeführt werden.

Missverständnis 2: Nach Transition beginnt ausschließlich der Betrieb

Auch während Operate, Deliver und Support können neue Discovery-, Design- und Build-Aktivitäten stattfinden.

Missverständnis 3: Build bedeutet nur Softwareentwicklung

Build kann auch Installation, Konfiguration, Integration, Automatisierung und technische Tests umfassen.

Missverständnis 4: Acquire bedeutet nur Einkauf

Acquire kann auch interne Ressourcen, Fähigkeiten, Daten, Lizenzen und wiederverwendete Komponenten umfassen.

Missverständnis 5: Operate und Deliver bedeuten dasselbe

Operate konzentriert sich stärker auf den technischen Betrieb. Deliver betrachtet stärker die tatsächliche Servicebereitstellung und das Stakeholder-Outcome.

Missverständnis 6: Support beginnt erst nach der Einführung

Supportfähigkeit muss bereits während Design, Build und Transition vorbereitet werden.

Missverständnis 7: Lifecycle und Value Stream sind identisch

Der Lifecycle stellt allgemeine Aktivitäten bereit. Ein Value Stream verbindet konkrete Schritte für ein bestimmtes Outcome.

Missverständnis 8: Ein Produkt ist nach dem ersten Release fertig

Digitale Produkte und Services werden weiter betrieben, unterstützt, verändert und verbessert.

Missverständnis 9: Eine erfolgreiche Transition beendet die Verantwortung des Produktteams

Produkt-, Service-, Betriebs- und Supportverantwortung müssen weiterhin zusammenarbeiten.

Missverständnis 10: Das Modell besitzt automatisch für jede Organisation dieselben Rollen

Die konkrete Rollenverteilung wird von der jeweiligen Organisation gestaltet.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sind nicht nur in Operate und Support beteiligt.

Sie können Beiträge über den gesamten Lifecycle leisten.

Aktivität	Möglicher Beitrag
Discover	technische Ausgangslage und bestehende Probleme erklären
Design	Architektur, Betrieb, Sicherheit und Wiederherstellung mitgestalten
Acquire	technische Anforderungen an Produkte und Lieferanten bewerten
Build	Systeme installieren, konfigurieren, integrieren und testen
Transition	Migration, Deployment und Betriebsübernahme unterstützen
Operate	Infrastruktur und Plattformen betreiben
Deliver	Servicebereitstellung und Nutzbarkeit sicherstellen
Support	Incidents, Anfragen und technische Probleme bearbeiten

Praxistipp

Bringe Betriebs- und Supportwissen möglichst früh ein.

Viele spätere Probleme können bereits während Discover, Design und Build verhindert werden.

30-Sekunden-Prüfung

Bei einem Produkt, Service oder Change kannst du acht Kurzfragen stellen:

Discover: Verstehen wir den tatsächlichen Bedarf?

Design: Ist die Gesamtlösung einschließlich Betrieb und Support gestaltet?

Acquire: Sind alle notwendigen Ressourcen und Fähigkeiten verfügbar?

Build: Wurde die Lösung erstellt, integriert und ausreichend getestet?

Transition: Kann sie kontrolliert und mit Rückfallmöglichkeit eingeführt werden?

Operate: Kann sie zuverlässig und sicher betrieben werden?

Deliver: Ist der Service für Stakeholder tatsächlich nutzbar?

Support: Können Benutzer und Service wirksam unterstützt werden?

Checkliste zu Discover

Ist das zugrunde liegende Bedürfnis verstanden?

Sind Stakeholder und gewünschte Outcomes bekannt?

Wurde der aktuelle Zustand untersucht?

Sind Daten und Rückmeldungen verfügbar?

Sind Chancen, Risiken und Einschränkungen bekannt?

Wurden bestehende Lösungen berücksichtigt?

Sind Annahmen und Unsicherheiten dokumentiert?

Ist klar, wie Erfolg bewertet wird?

Checkliste zu Design

Sind funktionale und nichtfunktionale Anforderungen berücksichtigt?

Wurden alle vier Dimensionen betrachtet?

Sind Sicherheit und Datenschutz integriert?

Sind Betrieb, Monitoring und Wiederherstellung gestaltet?

Sind Support und Benutzererfahrung berücksichtigt?

Sind Rollen und Fähigkeiten geklärt?

Sind Lieferantenanforderungen bekannt?

Ist die spätere Ablösung berücksichtigt?

Checkliste zu Acquire

Ist bekannt, welche Ressourcen benötigt werden?

Wurden vorhandene Ressourcen und Fähigkeiten geprüft?

Wurde Make, Buy, Reuse oder Partner angemessen bewertet?

Sind Gesamtbetriebskosten berücksichtigt?

Sind Lizenzen und Nutzungsrechte geklärt?

Sind Sicherheit und Datenschutz vertraglich berücksichtigt?

Sind Support- und Eskalationswege vereinbart?

Besteht eine Exit- und Übergangsplanung?

Checkliste zu Build

Entspricht die Umsetzung dem Design?

Sind Konfigurationen nachvollziehbar und reproduzierbar?

Sind Schnittstellen und Abhängigkeiten getestet?

Wurden Sicherheitsanforderungen umgesetzt?

Wurden Funktion, Leistung und Wiederherstellung getestet?

Sind Monitoring und Protokollierung vorbereitet?

Sind Dokumentationen vorhanden?

Sind bekannte Fehler und Einschränkungen erfasst?

Checkliste zu Transition

Ist die Lösung ausreichend getestet?

Sind Change und Autorisierung geklärt?

Sind Betrieb und Support vorbereitet?

Sind Benutzer und Stakeholder informiert?

Ist die Datenmigration geprüft?

Besteht ein geeigneter Rückfall- oder Wiederherstellungsplan?

Sind Verantwortlichkeiten während der Einführung eindeutig?

Wird das Ergebnis nach der Einführung überwacht?

Wird die Nutzbarkeit aus Stakeholdersicht bestätigt?

Checkliste zu Operate

Sind Betriebsverantwortlichkeiten eindeutig?

Werden Verfügbarkeit, Leistung und Kapazität überwacht?

Sind Wartung und Patchmanagement geregelt?

Funktionieren Backup und Wiederherstellung?

Werden Sicherheitsereignisse behandelt?

Sind technische Abhängigkeiten bekannt?

Werden technische Schulden sichtbar gemacht?

Bestehen geeignete Eskalations- und Bereitschaftswege?

Fließen Betriebsdaten in Verbesserungen ein?

Checkliste zu Deliver

Ist der Service für berechtigte Stakeholder nutzbar?

Sind Serviceangebot und Leistungsumfang verständlich?

Sind Erwartungen und Vereinbarungen abgestimmt?

Werden Serviceleistung und Outcomes gemessen?

Wird die Benutzer- und Kundenerfahrung berücksichtigt?

Werden Abweichungen transparent kommuniziert?

Sind Zugangs- und Berechtigungswege wirksam?

Wird geprüft, ob der Service weiterhin zum Bedarf passt?

Checkliste zu Support

Existiert ein eindeutiger Kontaktweg?

Sind Mitarbeiter, Werkzeuge und Informationen vorbereitet?

Sind Incident und Service Request richtig einzuordnen?

Sind Auswirkungen und Dringlichkeit nachvollziehbar?

Sind Wissen und Diagnoseinformationen verfügbar?

Sind Eskalations- und Lieferantenwege bekannt?

Wird die Wiederherstellung aus Benutzersicht geprüft?

Werden wiederkehrende Muster erkannt?

Fließen Erkenntnisse in Produkt, Service und Verbesserung zurück?

Gesamtcheck für den Product and Service Lifecycle

Schnellreferenz

Aktivität	Kurzfrage
Discover	Was wird benötigt und warum?
Design	Wie muss die Gesamtlösung gestaltet sein?
Acquire	Welche Ressourcen und Fähigkeiten werden benötigt?
Build	Wie wird die Lösung erstellt und getestet?
Transition	Wie wird sie kontrolliert in die Nutzung überführt?
Operate	Wie wird sie zuverlässig und sicher betrieben?
Deliver	Wie wird der Service für Stakeholder nutzbar bereitgestellt?
Support	Wie werden Benutzer, Produkt und Service unterstützt?

Zusammenfassende Darstellung

Discover
Bedarf, Chancen und Ausgangslage verstehen
↓
Design
Produkt, Service und Gesamtlösung gestalten
↓
Acquire
Ressourcen, Produkte und Fähigkeiten beschaffen
↓
Build
erstellen, konfigurieren, integrieren und testen
↓
Transition
kontrolliert in die vorgesehene Nutzung überführen
↓
Operate
technische Fähigkeiten zuverlässig betreiben
↓
Deliver
Services für Stakeholder bereitstellen
↓
Support
Benutzer, Produkte und Services unterstützen
↓
Feedback und Continual Improvement
↓
erneutes Discover, Design oder eine andere benötigte Aktivität

Die Darstellung dient als Lernhilfe.

Das offizielle Modell ist nicht starr oder ausschließlich linear. Jede Aktivität kann Erkenntnisse für jede andere Aktivität liefern.

Verwandte Seiten

2.1 Was ist ITIL und wie ist das Framework aufgebaut?

2.2 Das ITIL Value System

2.3 Die sieben Guiding Principles

2.4 Governance und Verantwortlichkeit

2.5 Die vier Dimensionen des Produkt- und Service-Managements

2.7 Die ITIL Management Practices

2.8 Value Streams und Value Stream Mapping

2.9 Continual Improvement

2.10 ITIL an den eigenen Kontext anpassen

Change Management

Deployment Management

Release Management

Service Design

Service Desk

Incident Management

Supplier Management

Monitoring and Event Management

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert: ITIL Foundation – Version 5

ITIL: ITIL Foundation Version 5 – What’s New?

ITIL: The New ITIL Product and Service Lifecycle Model – A Connected Ecosystem Approach

ITIL: The New ITIL Product and Service Lifecycle Model

ITIL: New ITIL Explained for Certified Professionals

ITIL: ITIL Product – Version 5

ITIL: ITIL Service – Version 5

Einordnung

ITIL Version 5 verwendet einen gemeinsamen Product and Service Lifecycle mit acht Aktivitäten:

Discover

Design

Acquire

Build

Transition

Operate

Deliver

Support

Die offiziellen Veröffentlichungen beschreiben das Modell als ganzheitlich, flexibel und nicht starr linear.

Aktivitäten können sich gegenseitig beeinflussen, wiederholt werden und für unterschiedliche Versionen eines Produkts oder Service gleichzeitig stattfinden.

Die detaillierten Leitfragen, Beispiele, Checklisten und praktischen Einordnungen auf dieser Seite sind eigene herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebenen Arbeitsabläufe dar.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026