Service Value Chain
Die Service Value Chain (SVC) ist das operative Herzstück des Service Value System aus der vorigen Lektion. Sie beantwortet die zentrale Frage: Was passiert konkret, wenn aus „Opportunity" oder „Demand" am Ende „Value" entstehen soll? Die Antwort ist ein Netz aus sechs vernetzten Aktivitäten – nicht ein linearer Ablauf wie das alte V3-Lifecycle, sondern ein flexibler Verbund, bei dem jede Aktivität mit jeder anderen verbunden ist. Welche Aktivitäten in welcher Reihenfolge zum Einsatz kommen, entscheidet der konkrete Anwendungsfall – ein neues Self-Service-Portal nimmt einen anderen Pfad durch die Chain als ein Hardware-Ausfall in der Nacht. Diese Lektion zeigt dir alle sechs Aktivitäten, ihre Aufgaben, und wie sie sich zu konkreten Value Streams verknüpfen.
1) Die sechs Aktivitäten
Klick die Aktivitäten an, um zu sehen, was jede tut, welche Inputs sie typisch braucht und welche Outputs sie erzeugt:
2) Value Streams – konkrete Pfade durch die Chain
Die SVC ist ein Möglichkeitsraum. Was tatsächlich durchläuft, sind Value Streams – konkrete Reihen von Schritten, mit denen ein bestimmtes Ergebnis erzeugt wird. Beispiel: ein neuer Mitarbeiter braucht einen Laptop. Klick „Stream starten", um zu sehen, wie ein typischer Onboarding-Stream durch die Chain läuft:
3) Aktivität ist nicht Verantwortung
Wichtige Klarstellung: die sechs Aktivitäten sind nicht sechs Abteilungen. Eine Person kann an mehreren Aktivitäten beteiligt sein, eine Aktivität wird oft von mehreren Rollen gemeinsam getragen. „Plan" beispielsweise ist nicht „die Strategie-Abteilung", sondern die Aktivität des Planens – die kann auch von einem Service Owner gemacht werden, wenn er den Roadmap-Eintrag für seinen Service abstimmt. „Engage" ist nicht der Service Desk, sondern jede Form von Stakeholder-Kontakt – vom Kundenanruf bis zur Vertragsverhandlung.
4) Wer welche Practices wo einsetzt
Die 34 ITIL-4-Practices verteilen sich auf die SVC-Aktivitäten. Eine Practice kann mehreren Aktivitäten zugeordnet sein:
| Aktivität | Typische Practices |
|---|---|
| Plan | Strategy Management, Portfolio Management, Architecture Management, Risk Management |
| Engage | Service Desk, Service Request Management, Relationship Management, Supplier Management |
| Design & Transition | Service Design, Change Enablement, Release Management, SLM |
| Obtain/Build | Deployment Mgmt, Supplier Mgmt, Software Dev & Mgmt, Infrastructure & Platform Mgmt |
| Deliver & Support | Incident, Problem, Monitoring & Event Mgmt, Service Desk |
| Improve | Continual Improvement, Measurement & Reporting, Workforce Mgmt |
5) Wie sich das in der Praxis anfühlt
Eine Praxis-Geschichte hilft, das Modell zu verinnerlichen. Stell dir vor, deine Firma will eine neue Self-Service-Funktion einführen („Passwort selbst zurücksetzen"). Was passiert in der SVC?
- Plan: Service Owner prüft, ob das in die IT-Strategie passt. Kosten-Nutzen, Ressourcen, Risiken (Sicherheitsfragen!).
- Engage: Betriebsrat einbinden (Beschäftigtendatenschutz), Fachbereich abklären, IT-Sicherheit konsultieren.
- Design & Transition: Konzept ausarbeiten – Selbstidentifikation per MFA, Auditing, Logging.
- Obtain/Build: Software einkaufen oder eigene Lösung bauen, in Testumgebung deployen.
- Deliver & Support: In Produktion gehen, Service Desk schulen, Monitoring aktivieren.
- Improve: Nach 3 Monaten messen – wie viele Resets, wie viele Helpdesk-Anrufe vermieden, welche Lücken sichtbar geworden? Anpassen.
Du siehst: die SVC bricht das Vorhaben in handhabbare Aktivitäten auf, jede mit klarer Aufgabe. Die Reihenfolge ist nicht starr – Engage findet z. B. mehrfach statt – aber der Zweck jeder Aktivität ist klar definiert.
6) Häufige Fallstricke
- SVC als linear missverstehen. „Erst Plan, dann Design, dann Obtain, dann Deliver" – das ist V3-Denken. Die Aktivitäten laufen parallel und iterativ.
- „Improve" als optional sehen. Improve ist nicht das schöne Schluss-Kapitel, sondern permanent aktiv. Jeder Incident ist eine Lerngelegenheit, jeder SLA-Report ein Verbesserungs-Anlass.
- SVC mit Aufbau-Organigramm verwechseln. SVC beschreibt was getan wird, nicht wer es tut. In kleinen IT-Teams macht eine Person mehrere Aktivitäten gleichzeitig.
- Practices an Aktivitäten kleben wollen. Eine Practice wie „Service Desk" wird hauptsächlich in „Engage" und „Deliver & Support" genutzt – ist aber nicht nur dort präsent.
Zusammenfassung
Die Service Value Chain (SVC) ist das operative Modell innerhalb des Service Value System. Sechs Aktivitäten – Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support – sind miteinander vernetzt, nicht sequenziell. Eingaben: Demand und Opportunity; Ausgabe: Value. Konkrete Abläufe durch die Chain heißen Value Streams; sie wählen die Aktivitäten, die für ihren Zweck nötig sind, in der jeweils passenden Reihenfolge. Jede Aktivität nutzt verschiedene Practices – „Service Desk" gehört zu Engage und Deliver & Support, „Incident Management" zu Deliver & Support, etc. Häufige Missverständnisse: SVC ist kein linearer Lifecycle, keine Abteilungsstruktur, und „Improve" ist permanent. Damit löst die SVC den starren Lifecycle aus ITIL V3 ab und schafft Raum für agile/DevOps-Arbeitsweisen.
Verwandte Lektionen: Service Value System · ITIL-Grundprinzipien · Continual Improvement · und mehrWeitere relevante LektionenWas ist ITIL?SLAService DeskIncident ManagementChange ManagementProblem ManagementCMDB