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 Ist der Zweck der Untersuchung eindeutig? Ist das gewünschte Outcome bekannt? Sind Auslöser und Abschluss festgelegt? Ist der Umfang ausreichend eingegrenzt? Sind relevante Stakeholder beteiligt? Stehen reale Vorgänge und Daten zur Verfügung? Ist geklärt, wer die Untersuchung koordiniert? Werden alle vier Dimensionen berücksichtigt? Sind wichtige Lieferanten einbezogen? Ist bekannt, wie Ergebnisse verwendet werden sollen? Checkliste für die Ist-Aufnahme Wurden tatsächliche und nicht nur dokumentierte Schritte erfasst? Sind Rollen und Verantwortlichkeiten sichtbar? Sind benötigte Informationen und Werkzeuge erfasst? Sind beteiligte Practices bekannt? Sind Lieferanten und externe Abhängigkeiten enthalten? Sind Bearbeitungs- und Wartezeiten erkennbar? Sind Übergaben sichtbar? Sind Nacharbeit und Rückschleifen erfasst? Sind Kontrollen und Freigaben enthalten? Sind Ausnahmen und Eskalationen berücksichtigt? Wurde das tatsächliche Stakeholder-Outcome geprüft? Checkliste für den Zielzustand Behandelt der Zielzustand die festgestellten Ursachen? Unterstützt er das gewünschte Outcome? Sind Verantwortung und Entscheidungsbefugnisse eindeutig? Werden unnötige Übergaben reduziert? Werden benötigte Informationen früher bereitgestellt? Bleiben notwendige Kontrollen wirksam? Sind Lieferanten und Verträge berücksichtigt? Ist der Zielzustand technisch und organisatorisch realistisch? Sind Automatisierungen kontrollierbar? Sind Messgrößen definiert? Kann die Verbesserung iterativ umgesetzt werden? Sind mögliche neue Risiken bewertet? Checkliste nach der Verbesserung Wurde die Verbesserung wie geplant umgesetzt? Hat sich die Durchlaufzeit verändert? Wurde Wartezeit reduziert? Entsteht weniger Nacharbeit? Wurden Engpässe beseitigt oder nur verlagert? Hat sich die Benutzer- oder Kundenerfahrung verbessert? Werden Outcomes zuverlässiger erreicht? Sind Kontrollen weiterhin wirksam? Sind neue Risiken entstanden? Wurden Rollen und Dokumentationen aktualisiert? Sind weitere Verbesserungen notwendig? Wird der Wertstrom fortlaufend überwacht? 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