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

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

Revision #1
Created 1 August 2026 22:12:11 by Admin
Updated 1 August 2026 22:12:34 by Admin