2.8 Value Streams und Value Stream Mapping

Kurz erklärt

Ein Value Stream beschreibt den Ende-zu-Ende-Weg, durch den aus einem Bedarf, einer Nachfrage oder einer Chance ein nutzbares Ergebnis und Wert für Stakeholder entstehen.

Value Stream Mapping macht diesen Weg sichtbar.

Dabei werden nicht nur einzelne Prozessschritte betrachtet, sondern auch:

beteiligte Personen und Teams,

Management Practices,

Informationen,

Technologien,

Partner und Lieferanten,

Entscheidungen,

Kontrollen,

Übergaben,

Wartezeiten,

Nacharbeit,

Risiken,

und Rückmeldungen.

Ziel ist nicht, ein besonders umfangreiches Ablaufdiagramm zu erstellen.

Ziel ist, den tatsächlichen Arbeitsfluss zu verstehen und gezielt zu verbessern.

Warum Value Streams wichtig sind

Digitale Produkte und Services entstehen normalerweise nicht innerhalb eines einzigen Teams.

Ein benötigtes Outcome kann Beiträge erfordern von:

Benutzern,

Fachabteilungen,

Service Desk,

Systemadministration,

Netzwerkbetrieb,

Entwicklung,

Informationssicherheit,

Einkauf,

Personalabteilung,

Lieferanten,

Cloud-Providern,

und Führungskräften.

Jeder Beteiligte kann seinen eigenen Arbeitsschritt korrekt ausführen.

Der gesamte Ablauf kann trotzdem:

langsam,

unübersichtlich,

fehleranfällig,

unnötig kompliziert,

oder für den Benutzer unbefriedigend

sein.

Beispiel:

Ein neuer Mitarbeiter benötigt einen arbeitsfähigen IT-Arbeitsplatz.

Alle beteiligten Teams können ihre jeweilige Aufgabe korrekt ausführen:

Personalabteilung meldet den Eintritt.

Führungskraft nennt benötigte Zugriffe.

Einkauf bestellt das Endgerät.

IT erstellt das Benutzerkonto.

Informationssicherheit prüft Berechtigungen.

Service Desk übergibt das Gerät.

Der Mitarbeiter kann am ersten Arbeitstag trotzdem nicht arbeiten, wenn:

die Meldung zu spät erfolgte,

notwendige Informationen fehlten,

eine Freigabe liegen blieb,

die Lizenz nicht verfügbar war,

das Endgerät nicht rechtzeitig geliefert wurde,

oder niemand das Ende-zu-Ende-Ergebnis kontrollierte.

Merke

Die Qualität einzelner Arbeitsschritte garantiert noch kein gutes Ende-zu-Ende-Ergebnis.

Was ist ein Value Stream?

Ein Value Stream ist eine zusammenhängende Abfolge von Schritten, durch die ein bestimmtes Outcome und Wert für einen Stakeholder ermöglicht werden.

Ein Value Stream besitzt normalerweise:

einen erkennbaren Auslöser,

einen bestimmten Bedarf oder eine Chance,

einen oder mehrere Stakeholder,

ein gewünschtes Outcome,

mehrere miteinander verbundene Schritte,

beteiligte Rollen und Fähigkeiten,

benötigte Informationen und Technologien,

sowie ein überprüfbares Ergebnis.

Beispiele für Value Streams:

neuen Mitarbeiter arbeitsfähig machen

einen Incident bearbeiten und den Service wiederherstellen

einen genehmigten Zugriff bereitstellen

eine neue Anwendung einführen

eine Schwachstelle dauerhaft beheben

einen Arbeitsplatz austauschen

einen Service verbessern

eine neue Produktfunktion bereitstellen

einen Lieferanten ablösen

einen nicht mehr benötigten Service außer Betrieb nehmen

Wichtig

Ein Value Stream sollte anhand des benötigten Outcomes benannt werden.

Ein Name wie „Ticket bearbeiten“ ist häufig zu eng.

Ein geeigneterer Name kann beispielsweise lauten:

„Benutzer nach einer Störung wieder arbeitsfähig machen.“

Auslöser, Output, Outcome und Wert

Diese Begriffe müssen unterschieden werden.

Begriff	Bedeutung	Beispiel
Auslöser	Ereignis, Nachfrage oder Chance, die den Wertstrom startet	neuer Mitarbeiter tritt ein
Input	benötigte Informationen oder Ressourcen	Eintrittsdatum, Rolle und genehmigte Zugriffe
Aktivität	durchgeführter Arbeitsschritt	Benutzerkonto erstellen
Output	direkt erzeugtes Ergebnis einer Aktivität	Benutzerkonto wurde angelegt
Outcome	durch Stakeholder ermöglichtes Ergebnis	Mitarbeiter kann seine Aufgaben ausführen
Wert	wahrgenommener Nutzen unter Berücksichtigung von Outcomes, Kosten und Risiken	produktiver und sicherer Arbeitsbeginn

Ein Output ist nicht automatisch das gewünschte Outcome.

Beispiel:

Output: Das VPN wurde installiert.

Outcome: Der Benutzer kann sicher auf die benötigten Anwendungen zugreifen.

Merke

Value Streams werden vom benötigten Outcome aus betrachtet und nicht nur anhand erledigter technischer Tätigkeiten.

Value Stream und Value Stream Mapping

Begriff	Bedeutung
Value Stream	tatsächlicher oder geplanter Ende-zu-Ende-Weg zum Outcome
Value Stream Mapping	strukturierte Darstellung und Untersuchung dieses Weges
Value Stream Management	fortlaufende Steuerung, Messung und Verbesserung des Wertstroms

Value Stream Mapping ist damit keine einmalige Zeichenübung.

Die Abbildung soll dabei helfen:

tatsächliche Arbeit sichtbar zu machen,

Probleme und Engpässe zu erkennen,

Verbesserungen zu priorisieren,

Verantwortlichkeiten zu klären,

und die Wirkung von Änderungen später zu überprüfen.

Value Stream, Value Chain und Lifecycle unterscheiden

Begriff	Bedeutung
ITIL Value System	übergeordneter Rahmen für Wertschöpfung innerhalb der Organisation
Value Chain	flexibles operatives Modell innerhalb des ITIL Value Systems
Product and Service Lifecycle	acht allgemeine Aktivitäten über den Lebenszyklus digitaler Produkte und Services
Value Stream	konkrete Ende-zu-Ende-Abfolge für ein bestimmtes Outcome
Prozess	strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen
Management Practice	organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Customer oder User Journey	Erfahrung eines Kunden oder Benutzers über mehrere Interaktionen hinweg

Beispiel: neue Anwendung für eine Fachabteilung

Lifecycle

Discover

Design

Acquire

Build

Transition

Operate

Deliver

Support

Value Stream

Bedarf der Fachabteilung erfassen
→ Lösung auswählen und bereitstellen
→ Benutzer befähigen
→ produktive Nutzung bestätigen

Beteiligte Practices

Business Analysis

Service Design

Architecture Management

Supplier Management

Change Enablement

Deployment Management

Information Security Management

Service Desk

Continual Improvement

Prozesse

Beschaffung

Change-Bewertung

Benutzeranlage

Softwareverteilung

Support

User Journey

Bedarf melden

Informationen erhalten

Anwendung testen

Schulung nutzen

Support anfordern

Erfahrung bewerten

Merke

Der Lifecycle stellt allgemeine Aktivitäten bereit.

Der Value Stream zeigt den konkreten Weg zum Outcome.

Practices liefern die dafür benötigten Fähigkeiten.

Value Streams überschreiten Organisationsgrenzen

Ein Value Stream endet nicht automatisch an einer Team-, Abteilungs- oder Unternehmensgrenze.

Beispiel: Internetzugang eines Standorts wiederherstellen

Mögliche Beteiligte:

Benutzer am Standort

Service Desk

Netzwerkteam

lokaler Techniker

Internetprovider

Hardwarehersteller

Incident-Koordination

Service Owner

Der Wertstrom endet nicht bereits dann, wenn das interne Netzwerkteam ein Ticket an den Provider übermittelt hat.

Er endet erst, wenn das gewünschte Outcome erreicht oder eine andere vereinbarte Entscheidung getroffen wurde.

Mögliches Outcome:

Der Standort besitzt wieder einen stabilen und ausreichend leistungsfähigen Internetzugang.

Typischer Fehler

Ein Team betrachtet seinen eigenen Arbeitsschritt als abgeschlossen, obwohl das Ende-zu-Ende-Outcome noch nicht erreicht wurde.

Die Grenzen eines Value Streams festlegen

Vor der Abbildung muss geklärt werden:

Welches konkrete Outcome wird betrachtet?

Welches Ereignis startet den Wertstrom?

Wann gilt der Wertstrom als abgeschlossen?

Für welche Benutzer- oder Kundengruppe gilt er?

Welche Produkt- oder Servicevariante wird untersucht?

Welche Ausnahmen gehören noch zum Umfang?

Welche angrenzenden Wertströme werden nicht betrachtet?

Unklare Abgrenzung:

Wir bilden den gesamten IT-Support ab.

Bessere Abgrenzung:

Wir bilden den Wertstrom ab, durch den ein Benutzer nach einer gemeldeten Arbeitsplatzstörung wieder arbeitsfähig wird.

Eine klare Grenze verhindert, dass die Darstellung:

zu groß,

unübersichtlich,

nicht messbar,

oder praktisch nicht verbesserbar

wird.

Aktueller und zukünftiger Zustand

Beim Value Stream Mapping werden häufig zwei Zustände unterschieden.

Zustand	Zweck
Ist-Zustand	zeigt, wie die Arbeit tatsächlich heute erfolgt
Zielzustand	zeigt, wie der verbesserte Wertstrom künftig funktionieren soll

Der Ist-Zustand darf nicht ausschließlich aus vorhandenen Prozessdokumentationen übernommen werden.

Er sollte anhand tatsächlicher Informationen untersucht werden.

Geeignete Quellen können sein:

Beobachtung realer Vorgänge,

Tickets,

Systemprotokolle,

Monitoring-Daten,

Zeitmessungen,

Gespräche mit Beteiligten,

Benutzerfeedback,

bestehende Dokumentationen,

Lieferanteninformationen,

und Stichproben.

Wichtig

Dokumentierter Prozess und tatsächlich gelebter Ablauf können deutlich voneinander abweichen.

Was in einer Value-Stream-Darstellung enthalten sein kann

Eine praktische Darstellung kann folgende Elemente enthalten:

Element	Beispiel
Auslöser	Benutzer meldet einen Incident
Stakeholder	Benutzer, Service Desk und technisches Team
gewünschtes Outcome	Benutzer kann wieder arbeiten
Schritt	Incident erfassen
verantwortliche Rolle	Service-Desk-Mitarbeiter
benötigte Information	Symptome und betroffener Service
verwendetes Werkzeug	Ticketsystem
beteiligte Practice	Incident Management
Bearbeitungszeit	10 Minuten
Wartezeit	45 Minuten
Übergabe	Service Desk an Netzwerkteam
Entscheidung	Eskalation erforderlich?
Kontrolle	Benutzer bestätigt Wiederherstellung
Nacharbeit	Ticket wegen fehlender Informationen zurückgegeben
Lieferant	Internetprovider
Risiko	falsche Priorisierung
Messgröße	gesamte Wiederherstellungszeit
Verbesserungsmöglichkeit	Pflichtinformationen bei Erfassung verbessern

Nicht jede Darstellung muss alle Elemente enthalten.

Der Detaillierungsgrad richtet sich nach:

Ziel der Untersuchung,

Risiko,

Komplexität,

verfügbarer Zeit,

und benötigter Entscheidung.

Eine einfache Darstellungsform

Für kleinere Wertströme kann eine Tabelle ausreichen.

Nr.	Schritt	Verantwortlich	Ergebnis	Bearbeitungszeit	Wartezeit	Problem
1	Anfrage erfassen	Service Desk	vollständiges Ticket	10 Min.	0 Min.	Pflichtangaben fehlen häufig
2	Zugriff prüfen	Fachverantwortlicher	fachliche Freigabe	5 Min.	2 Tage	keine Vertretung
3	Zugriff einrichten	Administration	technische Berechtigung	15 Min.	4 Std.	manuelle Gruppensuche
4	Funktion testen	Administration	technischer Test	10 Min.	0 Min.	Benutzer nicht beteiligt
5	Nutzung bestätigen	Benutzer	bestätigtes Outcome	5 Min.	1 Tag	Rückmeldung wird nicht nachverfolgt

Gesamte Bearbeitungszeit:

45 Minuten

Gesamte Wartezeit:

mehr als 3 Tage

Das Beispiel zeigt:

Die lange Durchlaufzeit entsteht nicht hauptsächlich durch langsame technische Ausführung.

Sie entsteht überwiegend durch:

Warteschlangen,

fehlende Vertretung,

manuelle Übergaben,

und verzögerte Rückmeldungen.

Bearbeitungszeit und Durchlaufzeit unterscheiden

Begriff	Bedeutung
Bearbeitungszeit	Zeit, in der aktiv an einem Vorgang gearbeitet wird
Wartezeit	Zeit, in der keine wertstromrelevante Bearbeitung erfolgt
Durchlaufzeit	gesamte Zeit vom Auslöser bis zum abgeschlossenen Outcome
Übergabezeit	Zeit und Aufwand beim Wechsel zwischen Rollen, Teams oder Systemen
Nacharbeitszeit	zusätzlicher Aufwand aufgrund unvollständiger oder fehlerhafter Arbeit

Beispiel:

aktive Bearbeitung: 40 Minuten

Wartezeit: 3 Tage

Nacharbeit: 20 Minuten

gesamte Durchlaufzeit: mehr als 3 Tage

Merke

Eine lange Durchlaufzeit bedeutet nicht automatisch, dass Mitarbeiter langsam arbeiten.

Häufig entstehen Verzögerungen zwischen den aktiven Arbeitsschritten.

Weitere mögliche Messgrößen

Je nach Wertstrom können unter anderem betrachtet werden:

gesamte Durchlaufzeit

aktive Bearbeitungszeit

Wartezeit

Anzahl der Übergaben

Anzahl beteiligter Teams

Anzahl notwendiger Freigaben

Nacharbeitsquote

Fehlerquote

Abbruchquote

Wiederholungsquote

Automatisierungsgrad

First-Time-Right-Quote

Wiederherstellungszeit

Benutzeraufwand

Kosten pro Vorgang

Erreichung des gewünschten Outcomes

Benutzer- oder Kundenerfahrung

Anzahl ungeklärter Ausnahmen

Eine einzelne Kennzahl sollte nicht isoliert optimiert werden.

Beispiel:

Eine geringere Bearbeitungszeit kann erreicht werden, indem Tickets schneller an andere Teams weitergegeben werden.

Dadurch können jedoch:

mehr Übergaben,

längere Gesamtdauer,

schlechtere Kommunikation,

und mehr Nacharbeit

entstehen.

Übergaben sichtbar machen

Übergaben sind Stellen, an denen Arbeit, Verantwortung oder Informationen von einer Rolle, einem Team oder einem System zu einem anderen wechseln.

Beispiele:

Benutzer an Service Desk

Service Desk an Fachteam

internes Team an Lieferanten

Entwicklung an Betrieb

Einkauf an technische Administration

Führungskraft an Berechtigungsmanagement

automatisiertes System an menschlichen Bearbeiter

An Übergaben können entstehen:

Informationsverluste,

Missverständnisse,

Wartezeiten,

doppelte Erfassung,

unklare Verantwortung,

falsche Priorisierung,

und Rückfragen.

Bei jeder Übergabe sollte geprüft werden:

Welche Informationen werden benötigt?

Sind sie vollständig und verständlich?

Wer trägt danach die Verantwortung?

Ist der nächste Schritt eindeutig?

Wie wird der Empfang bestätigt?

Muss das Ergebnis zurückgemeldet werden?

Ist die Übergabe überhaupt notwendig?

Kann sie vereinfacht oder automatisiert werden?

Warteschlangen und Engpässe

Ein Engpass begrenzt den Fluss des gesamten Wertstroms.

Mögliche Engpässe sind:

einzelne Fachpersonen,

manuelle Genehmigungen,

fehlende Informationen,

begrenzte Testumgebungen,

Lieferzeiten,

unzureichende Lizenzen,

langsame technische Systeme,

überlastete Teams,

oder nicht automatisierte Routinetätigkeiten.

Anzeichen für einen Engpass:

Vorgänge sammeln sich vor einem bestimmten Schritt.

Die Wartezeit ist deutlich länger als die Bearbeitungszeit.

Viele Vorgänge benötigen dieselbe einzelne Person.

Nachgelagerte Teams warten regelmäßig auf Ergebnisse.

Aufgaben werden häufig eskaliert.

Mitarbeiter umgehen den vorgesehenen Ablauf.

Prioritäten werden ständig geändert.

Fehler entstehen durch Zeitdruck.

Wichtig

Wird nur ein Schritt vor dem eigentlichen Engpass beschleunigt, kann sich die Warteschlange am Engpass weiter vergrößern.

Nacharbeit und Rückschleifen

Nacharbeit entsteht, wenn ein Schritt erneut durchgeführt oder korrigiert werden muss.

Mögliche Ursachen:

unvollständige Anforderungen

falsche Kategorisierung

fehlende Freigabe

fehlerhafte technische Umsetzung

ungeeignete Testdaten

unklare Verantwortlichkeiten

veraltete Dokumentation

widersprüchliche Informationen

nicht berücksichtigte Abhängigkeiten

fehlende Benutzerbestätigung

Beispiel:

Benutzer beantragt Zugriff.

Administration richtet den Zugriff ein.

Fachverantwortlicher stellt fest, dass der falsche Berechtigungsumfang gewählt wurde.

Zugriff muss entfernt und erneut eingerichtet werden.

Die Nacharbeit erhöht:

Durchlaufzeit,

Kosten,

Risiko,

und Arbeitsbelastung.

Sie kann außerdem das Vertrauen der Stakeholder beeinträchtigen.

Kontrollen und Freigaben untersuchen

Kontrollen können notwendig sein für:

Sicherheit,

Datenschutz,

Qualität,

Risiko,

gesetzliche Anforderungen,

finanzielle Verantwortung,

und Nachvollziehbarkeit.

Beim Mapping sollte nicht automatisch jede Kontrolle entfernt werden.

Stattdessen wird geprüft:

Welches Risiko behandelt die Kontrolle?

Ist sie an der richtigen Stelle?

Wird sie tatsächlich fachlich durchgeführt?

Ist sie mehrfach vorhanden?

Passt ihr Umfang zum Risiko?

Sind Entscheidungskriterien eindeutig?

Besteht eine Vertretung?

Kann die Kontrolle automatisiert unterstützt werden?

Werden Ergebnisse dokumentiert?

Wird die Kontrolle regelmäßig auf ihre Wirksamkeit geprüft?

Typischer Fehler

Eine Genehmigung wird entfernt, nur weil sie Zeit kostet.

Zuerst muss verstanden werden, welches Risiko oder welche Verpflichtung sie behandelt.

Arbeit mit und ohne direkten Wertbeitrag

Nicht jeder notwendige Schritt erzeugt unmittelbar einen für den Benutzer sichtbaren Wert.

Eine praktische Unterscheidung kann sein:

Kategorie	Bedeutung	Beispiel
direkter Wertbeitrag	unterstützt unmittelbar das gewünschte Outcome	benötigten Zugriff bereitstellen
notwendige unterstützende Arbeit	ist für Sicherheit, Steuerung oder Zuverlässigkeit erforderlich	Berechtigung prüfen
vermeidbare Arbeit	besitzt keinen ausreichenden Nutzen oder entsteht durch Fehler	dieselben Daten erneut erfassen
Nacharbeit	korrigiert unvollständige oder fehlerhafte Ergebnisse	falsche Berechtigung entfernen

Nicht sichtbare Arbeit ist nicht automatisch unnötig.

Beispiele für notwendige unterstützende Tätigkeiten:

Sicherheitsprüfung

Protokollierung

Dokumentation

Test

Backup

Freigabe

Compliance-Nachweis

Diese Tätigkeiten sollten jedoch:

einen klaren Zweck besitzen,

angemessen gestaltet,

und möglichst effizient ausgeführt

werden.

Value Stream Mapping und die vier Dimensionen

Eine vollständige Untersuchung berücksichtigt alle vier Dimensionen.

Organizations and People

Welche Rollen und Teams sind beteiligt?

Sind Verantwortung und Befugnisse eindeutig?

Bestehen ausreichende Fähigkeiten und Kapazitäten?

Wie funktionieren Kommunikation und Zusammenarbeit?

Information and Technology

Welche Informationen werden benötigt?

Welche Systeme und Werkzeuge werden verwendet?

Sind Daten korrekt und aktuell?

Wo bestehen Medienbrüche oder manuelle Übertragungen?

Welche Automatisierung ist möglich?

Partners and Suppliers

Welche externen Anbieter sind beteiligt?

Welche Wartezeiten und Abhängigkeiten entstehen?

Sind Eskalationswege vorbereitet?

Unterstützen Verträge das benötigte Outcome?

Value Streams and Processes

Welche Schritte, Entscheidungen und Übergaben existieren?

Wo entstehen Wartezeiten, Nacharbeit und Engpässe?

Welche Prozesse und Practices werden verwendet?

Wie wird das Outcome überprüft?

Value Streams und der Product and Service Lifecycle

Die acht Lifecycle-Aktivitäten können in einem Value Stream unterschiedlich kombiniert werden.

Beispiel: neue Monitoring-Lösung einführen

Lifecycle-Aktivität	Möglicher Beitrag zum Value Stream
Discover	Bedarf, Ausfälle und heutige Überwachung verstehen
Design	Zielarchitektur, Alarmierung und Betriebsmodell gestalten
Acquire	Plattform, Lizenzen oder externe Leistungen beschaffen
Build	Lösung konfigurieren, integrieren und testen
Transition	Pilot und kontrollierte Einführung durchführen
Operate	Plattform zuverlässig betreiben
Deliver	relevante Monitoring-Leistungen für Teams bereitstellen
Support	Benutzer und Administratoren bei Problemen unterstützen

Ein anderer Value Stream verwendet möglicherweise nur einen Teil dieser Aktivitäten oder wiederholt einzelne Aktivitäten mehrfach.

Merke

Der Lifecycle liefert allgemeine Aktivitätsbereiche.

Der Value Stream verbindet die konkret benötigten Schritte für ein bestimmtes Outcome.

Value Streams und Management Practices

Ein Value Stream verwendet normalerweise mehrere Practices.

Beispiel: Incident eines extern betriebenen Cloud-Service

Schritt	Mögliche beteiligte Practice
Störung erkennen	Monitoring and Event Management
Benutzerkontakt erfassen	Service Desk
Auswirkungen und Priorität bewerten	Incident Management
Abhängigkeiten ermitteln	Service Configuration Management
bekannte Lösung suchen	Knowledge Management
Anbieter einbinden	Supplier Management
Service wiederherstellen	Incident Management und technische Practices
Ursache untersuchen	Problem Management
dauerhafte Korrektur steuern	Change Enablement
Erfahrung auswerten	Continual Improvement

Practices dürfen dabei nicht als getrennte Teilprozesse betrachtet werden, zwischen denen ein Vorgang nur weitergereicht wird.

Sie sollen gemeinsam das Ende-zu-Ende-Outcome unterstützen.

Praxisnahe Vorgehensweise zum Value Stream Mapping

Die folgende Vorgehensweise ist eine redaktionelle Praxisempfehlung dieses Buches.

Sie ist keine vorgeschriebene offizielle ITIL-Schrittfolge.

1. Zweck und Outcome festlegen

Zuerst wird geklärt:

Welcher Value Stream wird untersucht?

Welches Problem soll gelöst werden?

Welches Outcome soll erreicht werden?

Für welche Stakeholder?

Wie wird Erfolg erkannt?

Beispiel:

Ziel ist, neue Mitarbeiter spätestens zum vereinbarten Eintrittszeitpunkt mit einem vollständig nutzbaren und sicheren IT-Arbeitsplatz auszustatten.

2. Auslöser und Abschluss bestimmen

Auslöser:

Die Personalabteilung übermittelt eine vollständige und bestätigte Eintrittsmeldung.

Abschluss:

Der Mitarbeiter bestätigt, dass Anmeldung, Endgerät und benötigte Services funktionieren.

Dadurch wird vermieden, dass der Wertstrom zu früh endet.

3. Beteiligte Stakeholder bestimmen

Mögliche Beteiligte:

neuer Mitarbeiter

Personalabteilung

Führungskraft

Service Desk

Einkauf

IT Asset Management

Identitätsmanagement

Endgeräteverwaltung

Informationssicherheit

Lieferant

Zusätzlich sollte geklärt werden:

Wer besitzt die Ergebnisverantwortung?

Wer koordiniert den Wertstrom?

Wer darf Entscheidungen treffen?

Wer muss informiert werden?

4. Tatsächliche Schritte erfassen

Die Beteiligten beschreiben, wie ein realer Vorgang heute abläuft.

Nicht nur:

Wie sollte der Prozess funktionieren?

Sondern:

Was geschieht tatsächlich?

Dabei können reale Tickets oder Fälle verfolgt werden.

Mögliche Schritte:

Eintritt melden

Rolle und Zugriffe bestimmen

Freigaben einholen

Endgerät bestellen

Benutzerkonto erstellen

Lizenzen zuweisen

Endgerät konfigurieren

Sicherheitsmaßnahmen aktivieren

Zugriffe testen

Gerät übergeben

Arbeitsfähigkeit bestätigen

5. Informationen, Werkzeuge und Practices ergänzen

Für jeden Schritt wird geprüft:

Welche Information wird benötigt?

Woher stammt sie?

In welchem System wird sie gespeichert?

Welches Werkzeug wird verwendet?

Welche Practice unterstützt den Schritt?

Welche Lieferanten sind beteiligt?

Beispiel:

Schritt	Information	Werkzeug	Practice
Endgerät bereitstellen	Rolle und Hardwarestandard	Asset- und Ticketsystem	IT Asset Management
Konto erstellen	Name, Eintrittsdatum und Organisationseinheit	Verzeichnisdienst	Service Request Management
Zugriffe einrichten	genehmigter Berechtigungsumfang	IAM-System	Information Security Management
Nutzung bestätigen	Benutzerfeedback	Ticket oder Portal	Service Desk

6. Zeiten und Übergaben erfassen

Für jeden Schritt können erfasst werden:

Bearbeitungszeit

Wartezeit

Übergabe

Rückfrage

Wiederholung

Fehler

und Abbruch

Nicht jede Zeit muss auf die Minute genau bekannt sein.

Auch eine erste Einteilung kann hilfreich sein:

wenige Minuten

mehrere Stunden

ein Arbeitstag

mehrere Tage

stark schwankend

7. Probleme und Risiken kennzeichnen

Mögliche Beobachtungen:

Eintrittsmeldung kommt zu spät.

Führungskraft nennt unvollständige Zugriffe.

Bestellung benötigt manuelle E-Mail.

Es gibt keine Vertretung für die Freigabe.

Kontoanlage und Lizenzzuweisung erfolgen in getrennten Systemen.

Benutzer wird bei der Funktionsprüfung nicht beteiligt.

Lieferzeit ist nicht transparent.

Abschluss erfolgt ohne Bestätigung der Arbeitsfähigkeit.

Probleme sollten möglichst mit Fakten oder Beispielen belegt werden.

8. Ursachen untersuchen

Nicht jedes sichtbare Problem ist die eigentliche Ursache.

Beispiel:

Symptom: Endgerät ist am ersten Arbeitstag nicht verfügbar.

Mögliche Ursachen:

Eintritt wurde zu spät gemeldet.

Gerätebestand ist nicht bekannt.

Beschaffung dauert länger als geplant.

Hardwarestandard ist unklar.

Bestellung benötigt mehrere Freigaben.

kein Mindestbestand ist definiert.

Lieferantenleistung wird nicht überwacht.

Eine Verbesserung sollte möglichst die relevante Ursache behandeln und nicht nur das Symptom verschieben.

9. Zielzustand gestalten

Der Zielzustand beschreibt, wie der Wertstrom künftig funktionieren soll.

Mögliche Verbesserungen:

vollständiges digitales Eintrittsformular

klare Mindestvorlaufzeit

rollenbasierte Standardpakete

definierte Vertretungsregelung

transparenter Gerätebestand

automatische Kontoanlage nach Freigabe

gemeinsame Statusübersicht

standardisierte Funktionsprüfung

verbindliche Bestätigung der Arbeitsfähigkeit

Messung von Durchlaufzeit und Fehlern

Der Zielzustand sollte:

verständlich,

realistisch,

risikogerecht,

und messbar

sein.

10. Verbesserungen priorisieren und umsetzen

Verbesserungen können bewertet werden nach:

erwarteter Wirkung

Dringlichkeit

Risiko

Aufwand

Kosten

Abhängigkeiten

Umsetzbarkeit

und benötigten Fähigkeiten

Nicht alle Verbesserungen müssen gleichzeitig umgesetzt werden.

Ein iteratives Vorgehen kann beispielsweise beginnen mit:

vollständige Eintrittsmeldung sicherstellen

klare Verantwortlichkeit festlegen

Status sichtbar machen

Standardpakete definieren

geeignete Schritte automatisieren

Wirkung messen

weitere Engpässe bearbeiten

Value Stream Management nach dem Mapping

Nach der ersten Abbildung muss der Wertstrom fortlaufend gesteuert werden.

Dazu gehören:

Verantwortlichkeit festlegen

relevante Messgrößen überwachen

Abweichungen untersuchen

Feedback auswerten

Risiken beobachten

Verbesserungen priorisieren

Änderungen am Wertstrom kontrollieren

Dokumentation aktuell halten

und den Wertstrom regelmäßig erneut betrachten

Mögliche Fragen:

Wird das gewünschte Outcome erreicht?

Hat sich die Durchlaufzeit verbessert?

Entsteht weniger Nacharbeit?

Wurden Engpässe nur verlagert?

Hat sich die Benutzererfahrung verbessert?

Sind neue Risiken entstanden?

Werden Kontrollen weiterhin wirksam durchgeführt?

Passen die Messgrößen noch zum Ziel?

Governance von Value Streams

Für wichtige Value Streams sollte geklärt sein:

Wer trägt die Ende-zu-Ende-Verantwortung?

Welche Outcomes und Ziele gelten?

Welche Risiken dürfen akzeptiert werden?

Welche Kontrollen sind verbindlich?

Wer darf den Wertstrom verändern?

Wie werden Leistung und Abweichungen überwacht?

Wie werden Konflikte zwischen Teams entschieden?

Welche Verbesserungen erhalten Priorität?

Welche Lieferantenabhängigkeiten bestehen?

Ein Value Stream kann mehrere organisatorische Verantwortungsbereiche überschreiten.

Trotzdem muss eine geeignete Koordination des Gesamtergebnisses bestehen.

Typischer Fehler

Jeder Schritt besitzt einen Verantwortlichen, aber niemand verantwortet das gesamte Ende-zu-Ende-Outcome.

Value Stream Mapping bei einem Incident

Beispielwertstrom:

Benutzer nach einem Serviceausfall wieder arbeitsfähig machen

Mögliche Schritte:

Störung erkennen oder melden

Incident erfassen

Auswirkungen und Dringlichkeit bewerten

betroffenen Service bestimmen

erste Diagnose durchführen

zuständiges Fachwissen einbinden

Service wiederherstellen

Funktion technisch prüfen

Nutzbarkeit mit dem Benutzer bestätigen

Kommunikation abschließen

notwendige Folgeaktivitäten einleiten

Mögliche Probleme:

Benutzer muss dieselben Informationen mehrfach nennen.

Ticket wird mehrfach weitergeleitet.

Serviceabhängigkeiten sind unbekannt.

Lieferantenkontakt beginnt zu spät.

Statusinformationen sind widersprüchlich.

technische Wiederherstellung wird nicht aus Benutzersicht geprüft.

wiederkehrende Incidents werden nicht an Problem Management übergeben.

Mögliche Messgrößen:

Zeit bis zur Erfassung

Zeit bis zur ersten qualifizierten Reaktion

gesamte Wiederherstellungszeit

Anzahl der Übergaben

erneute Kontaktaufnahme

wiederholte Incidents

Benutzerbestätigung

Qualität der Kommunikation

Value Stream Mapping bei einem Service Request

Beispielwertstrom:

genehmigte Standardsoftware für einen Benutzer nutzbar bereitstellen

Mögliche Schritte:

Software anfordern

Berechtigung und Bedarf prüfen

Lizenzverfügbarkeit kontrollieren

erforderliche Freigabe einholen

Software bereitstellen

Installation oder Zuweisung prüfen

Benutzer informieren

Nutzbarkeit bestätigen

Asset- und Lizenzinformationen aktualisieren

Mögliche Verbesserungen:

verständliches Serviceangebot

rollenbasierte Standardgenehmigung

automatische Lizenzprüfung

automatisierte Softwareverteilung

automatische Statusinformationen

technische Erfolgskontrolle

Abschluss erst nach bestätigter Nutzbarkeit

Value Stream Mapping bei einem Change

Beispielwertstrom:

Sicherheitsupdate kontrolliert und ohne vermeidbare Serviceunterbrechung bereitstellen

Mögliche Schritte:

Handlungsbedarf erkennen

betroffene Produkte und Services bestimmen

Risiko und Dringlichkeit bewerten

Update testen

Umsetzungs- und Rückfallplan erstellen

Autorisierung einholen

Beteiligte informieren

Update bereitstellen

technische Funktion prüfen

Service-Nutzbarkeit prüfen

Monitoring fortführen

Dokumentation und Konfigurationsinformationen aktualisieren

Mögliche Probleme:

unklare Abhängigkeiten

fehlende Testumgebung

lange Wartezeit auf Freigabe

manuelle Wiederholung derselben Prüfungen

fehlende Rückfallkriterien

Service Desk wird nicht informiert

technischer Erfolg wird ohne Serviceprüfung angenommen

Value Streams und Automatisierung

Automatisierung kann den Fluss verbessern, wenn:

der Wertstrom verstanden wurde,

Eingabedaten zuverlässig sind,

Regeln eindeutig sind,

Ausnahmen behandelt werden,

und Ergebnisse kontrolliert werden.

Geeignete Beispiele:

automatische Ticketanlage aus relevanten Events

automatische Vollständigkeitsprüfung von Anträgen

standardisierte Genehmigungsweiterleitung

automatische Softwareverteilung

automatische Aktualisierung von Asset-Daten

Statusbenachrichtigungen

automatische technische Tests

Erkennung von Wartezeiten und Eskalationsbedarf

Ungeeignet ist Automatisierung, wenn:

der Ablauf unklar ist,

Verantwortlichkeiten fehlen,

Eingabedaten unzuverlässig sind,

Ausnahmen nicht bekannt sind,

oder der Schritt keinen ausreichenden Nutzen besitzt.

Grundsatz

Einen schlechten Wertstrom zu automatisieren kann dazu führen, dass Fehler und Verschwendung nur schneller ausgeführt werden.

Künstliche Intelligenz in Value Streams

KI kann innerhalb von Value Streams beispielsweise unterstützen bei:

Klassifizierung von Anfragen

Erkennung ähnlicher Vorgänge

Zusammenfassung von Informationen

Prognose möglicher Engpässe

Analyse von Durchlaufzeiten

Vorschlägen für passende Wissensartikel

Erkennung wiederkehrender Muster

und Unterstützung der Kommunikation

Dabei müssen unter anderem berücksichtigt werden:

Datenqualität

Datenschutz

Informationssicherheit

Nachvollziehbarkeit

mögliche Verzerrungen

menschliche Kontrolle

Fehlerbehandlung

und Verantwortung

Beispiel:

Eine KI schlägt die automatische Genehmigung eines Zugriffs vor.

Vor einer solchen Automatisierung muss geklärt sein:

Welche Zugriffe dürfen standardisiert genehmigt werden?

Welche Rollen und Risiken sind betroffen?

Welche Daten verwendet die KI?

Wer überprüft Ausnahmen?

Wie werden falsche Entscheidungen erkannt?

Wer trägt die Ergebnisverantwortung?

Sicherheitsrelevant

Die Verwendung von KI verändert nicht automatisch bestehende Verantwortlichkeiten und Governance-Anforderungen.

Value Streams und Continual Improvement

Value Stream Mapping liefert eine Grundlage für Continual Improvement.

Möglicher Verbesserungszyklus:

benötigtes Outcome bestimmen

aktuellen Wertstrom erfassen

Daten und Feedback sammeln

Engpässe und Risiken erkennen

Ursachen untersuchen

Zielzustand gestalten

Verbesserungen priorisieren

schrittweise umsetzen

Wirkung messen

Wertstrom erneut bewerten

Verbesserungen können betreffen:

einzelne Schritte,

Übergaben,

Informationen,

Rollen,

Technologien,

Lieferanten,

Kontrollen,

oder den gesamten Aufbau des Wertstroms.

Merke

Value Stream Mapping zeigt nicht nur, wo Arbeit stattfindet.

Es zeigt, wo Wertfluss behindert wird und wo Verbesserungen ansetzen können.

Typische Fehler beim Value Stream Mapping

Fehler 1: Nur den dokumentierten Soll-Prozess abbilden

Der tatsächlich gelebte Arbeitsablauf bleibt unbekannt.

Fehler 2: An Abteilungsgrenzen aufhören

Der gesamte Weg zum Stakeholder-Outcome wird nicht betrachtet.

Fehler 3: Zu großen Umfang wählen

Der Wertstrom wird so umfangreich, dass keine konkreten Verbesserungen mehr erkennbar sind.

Fehler 4: Nur technische Schritte betrachten

Menschen, Informationen, Lieferanten, Kontrollen und Benutzererfahrung fehlen.

Fehler 5: Nur Bearbeitungszeiten messen

Wartezeit, Übergaben, Nacharbeit und Verzögerungen bleiben unsichtbar.

Fehler 6: Jede nicht sichtbare Tätigkeit als Verschwendung betrachten

Notwendige Sicherheits-, Qualitäts- oder Compliance-Kontrollen werden ungeprüft infrage gestellt.

Fehler 7: Das Diagramm als Endergebnis betrachten

Probleme werden sichtbar gemacht, aber Verbesserungen werden nicht priorisiert oder umgesetzt.

Fehler 8: Mitarbeiter für Probleme im Wertstrom verantwortlich machen

Systemische Ursachen wie fehlende Informationen, ungeeignete Werkzeuge und widersprüchliche Ziele werden übersehen.

Fehler 9: Nur einen idealen Einzelfall betrachten

Ausnahmen, Fehler, Eskalationen und Lieferantenabhängigkeiten bleiben unbekannt.

Fehler 10: Lokale Kennzahlen optimieren

Einzelne Teams verbessern ihre Werte, während sich das Ende-zu-Ende-Outcome verschlechtert.

Fehler 11: Zielzustand ohne Messgrößen gestalten

Später kann nicht festgestellt werden, ob die Verbesserung tatsächlich wirksam war.

Fehler 12: Zu früh automatisieren

Ein ungeeigneter oder instabiler Ablauf wird technisch festgeschrieben.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sehen häufig nur einen Teil des gesamten Wertstroms.

Beispiele:

Benutzerkonto erstellen

Server konfigurieren

Firewall-Regel ändern

Software verteilen

Incident untersuchen

Backup wiederherstellen

Monitoring-Alarm bearbeiten

Value-Stream-Denken ergänzt folgende Fragen:

Welcher Auslöser führte zu meiner Aufgabe?

Welches Outcome soll erreicht werden?

Welche Schritte fanden bereits statt?

Welche Informationen fehlen mir?

Wer arbeitet nach meinem Schritt weiter?

Welche Auswirkungen besitzt eine Verzögerung?

Welche Rückmeldung muss ich liefern?

Welche Practices und Teams sind beteiligt?

Wie wird der Erfolg aus Benutzersicht geprüft?

Kann mein Arbeitsschritt vereinfacht oder automatisiert werden?

Erzeuge ich möglicherweise unnötige Nacharbeit für andere?

Praxistipp

Dokumentiere nicht nur, was du getan hast.

Dokumentiere auch das Ergebnis, relevante Abhängigkeiten und den nächsten notwendigen Schritt.

30-Sekunden-Prüfung eines Value Streams

Auslöser: Was startet den Wertstrom?

Stakeholder: Für wen wird das Outcome benötigt?

Outcome: Wann ist das tatsächliche Ziel erreicht?

Schritte: Welche Tätigkeiten sind notwendig?

Verantwortung: Wer entscheidet und wer führt aus?

Informationen: Welche Daten werden benötigt?

Übergaben: Wo wechselt die Arbeit zwischen Beteiligten?

Fluss: Wo entstehen Wartezeit, Nacharbeit oder Engpässe?

Kontrollen: Welche Prüfungen sind wirklich erforderlich?

Messung: Wie wird Erfolg festgestellt?

Verbesserung: Welcher nächste Schritt verbessert den Wertstrom?

Checkliste vor dem Mapping

Checkliste für die Ist-Aufnahme

Checkliste für den Zielzustand

Checkliste nach der Verbesserung

Schnellreferenz

Frage	Bedeutung
Was startet den Wertstrom?	Auslöser bestimmen
Für wen wird gearbeitet?	Stakeholder bestimmen
Was soll erreicht werden?	Outcome definieren
Welche Schritte finden statt?	tatsächlichen Arbeitsfluss erfassen
Wer ist beteiligt?	Rollen, Teams und Lieferanten bestimmen
Welche Informationen werden benötigt?	Informationsfluss untersuchen
Wo wartet die Arbeit?	Warteschlangen erkennen
Wo wird Arbeit wiederholt?	Nacharbeit erkennen
Wo wechselt Verantwortung?	Übergaben untersuchen
Welche Kontrollen sind notwendig?	Risiken und Vorgaben berücksichtigen
Wie wird Erfolg gemessen?	geeignete Messgrößen bestimmen
Was sollte zuerst verbessert werden?	Verbesserungen priorisieren

Zusammenfassende Darstellung

Bedarf, Nachfrage oder Chance
↓
Auslöser des Value Streams
↓
miteinander verbundene Schritte
↓
Menschen · Practices · Informationen · Technologien · Lieferanten
↓
Übergaben · Entscheidungen · Kontrollen · Rückmeldungen
↓
Output
↓
überprüftes Outcome
↓
gemeinsam ermöglichter Wert
↓
Feedback und Continual Improvement

Aufbau einer einfachen Value-Stream-Karte

Auslöser

Was startet den Wertstrom?

↓

Schritt 1

Verantwortliche Rolle · benötigte Information · Ergebnis

↓ Übergabe oder Wartezeit

Schritt 2

Verantwortliche Rolle · verwendete Practice · Werkzeug

↓ Entscheidung oder Kontrolle

Schritt 3

technische oder organisatorische Umsetzung

↓

Ergebnisprüfung

Funktioniert das Produkt oder der Service technisch?

↓

Outcome-Prüfung

Kann der Stakeholder das benötigte Ergebnis erreichen?

↓

Feedback und Verbesserung

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.6 Der Product and Service Lifecycle

2.7 Die ITIL Management Practices

2.9 Continual Improvement

2.10 ITIL an den eigenen Kontext anpassen

Incident Management

Service Request Management

Change Enablement

Problem Management

Measurement and Reporting

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert: ITIL Foundation – Version 5

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

ITIL: Moving from ITIL 4 to ITIL Version 5 – Value Streams and Digital Lifecycle

ITIL: ITIL Product – Version 5

PeopleCert: ITIL Product – Version 5

ITIL: New ITIL Product and Service Lifecycle Model

Offiziell bestätigter Stand

Die offiziellen ITIL-Version-5-Informationen bestätigen:

Value Stream Mapping and Management ist Bestandteil von ITIL Foundation Version 5.

Value Streams sollen identifiziert, abgebildet und gesteuert werden.

Ziel sind besserer Fluss, höhere Sichtbarkeit und bessere Outcomes über digitale Produkte und Services hinweg.

Geschäfts-Wertströme und der Product and Service Lifecycle sollen gemeinsam betrachtet werden, um die Unterstützung des Geschäfts durch digitale Technologie zu verstehen.

ITIL Version 5 verwendet weiterhin das ITIL Value System und eine vereinfachte Value Chain.

Digitale Produkte können als integrierte Value Streams über ihren vollständigen Lebenszyklus betrachtet werden.

Einordnung

Die auf dieser Seite dargestellte Vorgehensweise zur:

Abgrenzung eines Value Streams,

Erfassung von Bearbeitungs- und Wartezeiten,

Untersuchung von Übergaben,

Gestaltung eines Zielzustands,

Priorisierung von Verbesserungen,

und Verwendung der Checklisten

ist eine praxisnahe redaktionelle Methode dieses unabhängigen Nachschlagewerks.

Sie ist keine wörtliche offizielle ITIL-Methode und keine für jede Organisation vorgeschriebene Notation.

Die konkrete Darstellungsform und der benötigte Detaillierungsgrad müssen an Ziel, Risiko, Komplexität und verfügbare Informationen angepasst werden.

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