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

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

Revision #1
Created 1 August 2026 22:29:49 by Admin
Updated 1 August 2026 22:30:05 by Admin