Als Lean Six Sigma Black Belt, habe ich da es im Gartner Hype Cycle auch nochmal erwähnt wurde mit dem Thema Value Stream Mapping oder klassisch Wertstromanalyse auseinandergesetzt.
Wertstromanalyse ist ein altes Tool der Optimierung, welches schon im TPS (Toyota Production System) Anwendung gefunden hat.
Es folgt sehr einfachen Schritten:
- Wähle das umsatzstärkste Produkt oder Service
- Bringe einen oder zwei Repräsentanten aller direkt an der Erstellung beteiligten Personen in einen Workshop Raum
- Am Whiteboard kommt die Produktlieferung ganz Rechts und ganz Links der Trigger -> meist der Kundenauftrag
- Mit ausreichend Spezifikationen, damit alle wissen, was hergestellt wird. Damit wir über das gleiche Sprechen.
- Mit monatlichen Nummern: Herstellungszahlen, Kosten pro Einheit, Lieferfrequenz und anderes.
- IST Zustand erheben: Wir definieren jeden Schritt, der notwendig ist, um bei dem Endprodukt anzukommen. Üblicherweise:
- Pro Arbeitsstation ein Schritt.
- Einzelne Arbeitsschritte pro Arbeitsstation werden zusammengefasst, aber trotzdem notiert.
- Wie viele Einheiten (Stückzahl) pro Zeiteinheit produziert werden kann und was bei diesem Schritt zeitlich genau passiert.
- ZZ: Zykluszeit
- RZ: Rüstzeit
- BZ: Bearbeitungszeit
- MV: Maschinenverfügbarkeit
- VA: Verfügbare Arbeitszeit
- Wie viel Ausschuss produziert wird:
- Q: Prozentualer Anteil nicht in Ordnung Teile
- Aggregierte Werte zwischen den einzelnden Stationen
- Bestand der Varianten
- Wartezeit zwischen den Station
- Bearbeitungstakt: Mit welchem Takt wird ein Produkt fertiggestellt
- Analyse: 7 Arten der Verschwendung
- Transport
- Bestände
- Bewegung
- Wartezeit
- Überproduktion
- Übererfüllung der Anforderungen
- Ausschuss
- Massnahmen ableiten
- Rhythmus und Fluss
- Steuerung und Sequenz
- Prozesse und Hilfsmittel
- KPIs messen
- Wertschöpfungsgrad
- EPEI
- Wertstrom Quotienten: Anteil der Bearbeitungszeit an der gesamten Durchlaufzeit
- OTIF (On Time in Full)
- OEE (Overall equipment efficiency) Gesamtanlageneffektivität
- Wertstromdesign
- Einen neuen Sollzustand der Zeiten und des Prozesses definieren
Dann führt man das ganze ein und durchläuft im Prinzip den Zyklus so häufig wie es notwendig ist, um ein Pareto Optimum zu erreichen.
Etwas ausführlicher finden wir dieses hier
Nun sehe ich, das versucht wird diese Wertstromanalyse auf Deployments bzw. IT Prozesse anzuwenden.
Das ist ein löblicher Schritt in Richtung kontinuierliche Verbesserung.
Hierbei müssen wir uns allerdings klar machen, dass IT Prozesse wie z.B. Deployments variable sind. Das heißt, ich kann eine CI/CD Pipeline laufen lassen und muss nicht alle Teile benutzen. Z.B. kann ich einige Tests bei kleineren Hotfixes weglassen oder andere Zeit-intensive Schritte, wenn ich diese im vorherigen Deployment habe laufen lassen und die Risiken minimal sind.
Das ist bei Industrieprozessen einfach nicht möglich. Wir können nicht einfach die Reifen weglassen am Fahrrad. In der IT können wir die Reifen weglassen, da diese schon existieren, allerdings keiner Änderung unterliegen. Software is not Hardware.
Dafür stellen die Industrie bestimmt hunderte Fahrräder pro Woche her. Das heißt, wir haben ggf. nicht mal die gleichen statistischen Grundlagen, dafür allerdings bessere Daten. Die meisten der Schritte sind im IT-System minutiös hinterlegt und können auf den Einzelfall zurückverfolgt werden.
Die Wertstromanalyse deckt Probleme, auf die ich üblicherweise sofort anfange zu bekämpfen, da ich sie in nahezu allen Organisationen finde.
Deployment Pain ist der mentale Schmerz, den wir empfinden, wenn wir unsere Pipelines laufen lassen. Wir sind uns einfach nicht sicher, ob der Build durchläuft oder in Produktion Probleme verursacht. Diese Unsicherheit sorgt dafür, dass wir solche Sprüche hören wie: Never deploy on Fridays!
Wenn es weh tut, mach es öfter!
Martin Fowler
Dieser Ausschuss ist für das Fahrrad in der Auswirkung nicht besonders groß. Das Fahrrad geht zurück und gut. Bei Software ist es problematischer. Wir wissen gar nicht das ein BUG besteht, bis er gefunden wird. Hier ist ein Post Mortem Analyse ggf. besser geeignet, um auf die Spur des teilweise teuren Problems zu kommen.
Meine Lieblinge für Post Mortems die einfach zu erheben sind:
- Abweichung von der Schätzung über 50%
- Bugs
- Ausfallzeiten
- Ungeplante Arbeit (Tickets, die in den Sprint gezogen wurden)
- Fokus Break (Tickets mussten unterbrochen werden)
Hier empfiehlt sich eigentlich immer die 5W Technik, der Ursachenanalyse des Einzelfalls.
Wertstromanalysen sind ein guter Ausgangspunkt, um über einen Prozess zu reden und ihn in ökonomisch quantifizierte Einheiten zu zerlegen. Er kommt allerdings aus einer anderen Welt, die teilweise anderen Regeln folgt.
Wir können in der Welt der Software über APIs an Systemen wie GIT, JIRA oder Jenkins durchaus automatisierte Auswertungen fahren und diese uns dann in Post Mortems Fallweise anschauen.
Bei anderen Prozessen, wie zum Beispiel dem Ticketprozess, welcher weniger Software spezifisch ist kann die Wertstromanalyse durchaus sehr erfolgreich alleine genutzt werden. Aber es braucht mehr Informationen die um Themen, wie Developer Experience oder spezifischer Deployment Pains gehen, um die richtigen Handlungen abzuleiten.
Einen Sonderfall gibt es tatsächlich. Developer Platforms. Wenn das Deployment in goldenen Pfaden hoch standardisiert ist, sind quantitative Tools sehr gut, um die Pfade kontinuierlich zu verbessern.