# 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:
>
> 1. **Discover**
> 2. **Design**
> 3. **Acquire**
> 4. **Build**
> 5. **Transition**
> 6. **Operate**
> 7. **Deliver**
> 8. **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:

1. **Discover:** Verstehen wir den tatsächlichen Bedarf?
2. **Design:** Ist die Gesamtlösung einschließlich Betrieb und Support gestaltet?
3. **Acquire:** Sind alle notwendigen Ressourcen und Fähigkeiten verfügbar?
4. **Build:** Wurde die Lösung erstellt, integriert und ausreichend getestet?
5. **Transition:** Kann sie kontrolliert und mit Rückfallmöglichkeit eingeführt werden?
6. **Operate:** Kann sie zuverlässig und sicher betrieben werden?
7. **Deliver:** Ist der Service für Stakeholder tatsächlich nutzbar?
8. **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**

- [ ] Werden Produkt und Service gemeinsam betrachtet?
- [ ] Sind gewünschte Outcomes und Stakeholder bekannt?
- [ ] Sind alle acht Aktivitäten angemessen berücksichtigt?
- [ ] Wurde das Modell nicht als starrer Ablauf verwendet?
- [ ] Sind mehrere gleichzeitig aktive Produktversionen berücksichtigt?
- [ ] Arbeiten Produkt-, Service-, Betriebs- und Supportteams zusammen?
- [ ] Werden alle vier Dimensionen betrachtet?
- [ ] Sind Governance und Verantwortlichkeit geklärt?
- [ ] Werden Risiken und technische Schulden sichtbar behandelt?
- [ ] Sind Betrieb, Support und Ablösung frühzeitig berücksichtigt?
- [ ] Werden Feedback und Betriebsdaten zurückgeführt?
- [ ] Ist Continual Improvement in allen Aktivitäten verankert?
- [ ] Wird der tatsächliche Wert statt nur technischer Outputs bewertet?

---

**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](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154)
- [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide)
- [ITIL: The New ITIL Product and Service Lifecycle Model – A Connected Ecosystem Approach](https://www.itil.com/Itil-News-and-Announcements/itil-product-and-service-lifecycle-model)
- [ITIL: The New ITIL Product and Service Lifecycle Model](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-service-lifecycle-model)
- [ITIL: New ITIL Explained for Certified Professionals](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-explained)
- [ITIL: ITIL Product – Version 5](https://www.itil.com/professionals/certifications/ITIL-Product-Version-5)
- [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/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