Rezension Learning to See: Wertstromanalyse für das Systems Engineering

Das Buch Learning to See von Mike Rother und John Shook ist die kanonische Einführung in die Wertstromanalyse. Der Fokus ist bewusst in Produktion und Logistik verankert. Physisches Material bewegt sich, Lagerbestände wachsen und die Durchlaufzeit lässt sich mit Stoppuhr und Klemmbrett messen.

Genau dieser Fokus ist eine Stärke des Buchs, keine Einschränkung. Das Buch lehrt Dich eine neue Art, Systeme zu sehen. Und das ist der Punkt, an dem die Perspektive der klassischen Systems Engineering Praxis ins Spiel kommt: Auch dort geht es nicht um Einzeldisziplinen, sondern um das Verhalten des Gesamtsystems über den gesamten Lebenszyklus. Wenn wir die Logik verstanden haben, ist der Sprung von der Fabrikhalle ins Systems Engineering kleiner, als er aussieht. Dieser Beitrag fasst zunächst das Buch in seinem ursprünglichen Kontext zusammen. Danach übertrage ich die Ideen auf Systems Engineering und Produktentwicklung. Ich zeige die typischen Muster, die ich in Entwicklungsorganisationen aus klassischer Systems Engineering Sicht beobachte.

Rezension

Learning to See ist kein Management Manifest sondern ein Arbeitsbuch. Die Autoren empfehlen, mit Bleistift, Papier und Stoppuhr zu arbeiten und die Produktion physisch abzulaufen. Ziel ist, zu verstehen, wie Wert tatsächlich fließt, nicht wie Prozessdiagramme behaupten, dass er fließt.

Das Buch ist in fünf Teile gegliedert:

Teil 1: Das Ganze sehen

Die Autoren führen den Wertstrom als Einheit der Analyse ein. Also nicht Abteilungen, Maschinen, Rollen, etc. Der Wertstrom beginnt bei der Bestellung des Kunden und endet bei der Auslieferung. Allein diese Umdeutung zeigt, warum lokale Effizienz so oft die Gesamtleistung nicht verbessert.

Aus Sicht des klassischen Systems Engineering entspricht das einem Perspektivenwechsel von der Optimierung der Komponente zur Optimierung des Systems. Man kann ein Teilsystem perfektionieren und trotzdem das Gesamtsystem verschlechtern, weil Schnittstellen, Rückkopplungen und Warteschlangen dominieren. Wertstromdenken zwingt uns, genau diese Dynamik ernst zu nehmen.

Teil 2: Den Ist-Zustand abbilden

Die Ist-Wertstromkarte zeigt, wie Dinge heute wirklich funktionieren. Materialfluss, Informationsfluss, Bestände, Zykluszeiten, Rüstzeiten. Der Schwerpunkt liegt auf Fakten, die am Ort des Geschehens beobachtet werden, nicht auf Durchschnittswerten aus Reports. Das Ergebnis ist oft unangenehm klar.

The point of value stream mapping is not the map, but understanding the flow of information and material.

Mike Rother und John Shook, Learning to See

Teil 3: Den Soll-Zustand entwerfen

Die Soll-Wertstromkarte ist eine disziplinierte Anwendung von Lean Prinzipien auf denselben Wertstrom. Sie identifiziert, wo Fluss Losgrößen ersetzt, wo Pull Planung ersetzt und wo eine Steuerung durch einen Taktgeber etabliert werden sollte. Der Soll Zustand ist nicht Wunschdenken, sondern ein kohärentes Design.

In klassischer Systems Engineering Sprache ist das ein Systementwurf, der nicht bei Dokumenten beginnt, sondern bei Fluss, Kopplung und Stabilität. Wir definieren nicht nur Aktivitäten, sondern eine Architektur der Wertentstehung. Das ist näher an Systemarchitektur, als vielen Lean Einsteigern bewusst ist.

Teil 4: Umsetzen durch Kaizen

Die Autoren betonen, dass Karten zunächst einmal keine Veränderung erzeugen. Menschen tun das. Die Soll Karte wird zum Bauplan für fokussierte Verbesserungsaktivitäten. Jedes Kaizen wird dem Gesamtentwurf des Wertstroms untergeordnet statt isolierten lokalen Gewinnen.

Both flow kaizen (value stream improvement) and process-level kaizen (elimination of waste at the shop floor team level) are necessary in your company; improvement in one improves the other.

Mike Rother und John Shook, Learning to See

Teil 5: Erhalten und wiederholen

Wertstromanalyse ist keine einmalige Übung. Wenn Nachfrage, Produkte und Randbedingungen sich ändern, muss der Wertstrom neu gesehen und neu gestaltet werden. Sehen lernen ist eine dauerhafte Fähigkeit, kein Projektergebnis.

Genau hier dockt Systems Engineering sauber an: Wir arbeiten mit einem lebenden System, nicht mit einem eingefrorenen Plan. Sobald sich Anforderungen, Schnittstellen oder Technologien ändern, ändert sich auch die Systemdynamik. Kontinuierliches Sehen ist in der Entwicklung genauso notwendig wie in der Fertigung.

Wie sich das auf das Systems Engineering übertragen lässt

Das Buch ist heute schon ein Klassiker. Es hat gerade einmal 120 Seiten, aber sie sind voll mit praktischen, handwerklichen Hinweisen.

Seine Disziplin, seine Einfachheit und sein systemisches Denken lassen sich erstaunlich gut auf das Systems Engineering übertragen. Wir müssen natürlich mit nicht sichtbaren Artefakten arbeiten. Dann sehen wir, dass dass wir vier Wirkrichtungen haben:

• Unsichtbares sichtbar machen: Design in Process explizit und diskutierbar darstellen
• Informationsfluss kartieren: Aufdecken, wie Entscheidungen und Annahmen weitergereicht werden
• Systemische Engpässe identifizieren: Die Zwänge finden, die die Ende zu Ende Lerngeschwindigkeit bestimmen
• Einen Soll Zustand entwerfen: Ein kohärentes Zielbild für schnellere Rückkopplung und Fluss entwickeln

1. Unsichtbares sichtbar machen

Die Kernidee lautet: Bestand verdeckt Probleme. In der Entwicklung existiert Bestand als Design-in-Process (DIP) statt als Work-in-Process (WIP). Unfertige Entwürfe, offene Entscheidungen, halb validierte Annahmen. Das hat keine physische Form und ist finanziell oft unsichtbar, weil Forschung und Entwicklung Kosten sofort als Aufwand verbucht werden.

Übertragen auf Produktgeschwindigkeit zwingt Dich das Mapping, diesen unsichtbaren Bestand explizit darzustellen. Wartende Designs, auf Halde liegende Entscheidungen und festgefahrene Reviews werden genauso sichtbar wie Paletten in der Fabrik. In klassischer Systems Engineering Arbeit ist das besonders relevant, weil die vermeintliche Sicherheit durch Dokumente oft darüber hinwegtäuscht, wie viel tatsächlich unentschieden ist.

Der Nutzen ist Unterscheidungsfähigkeit. wir erkennen den Unterschied zwischen Fortschritt und zielloser Aktivität. Verschwendung wird sichtbar, besprechbar und dadurch reduzierbar.

2. Informationsfluss kartieren

Die Autoren behandeln Informationsfluss als untrennbar vom Materialfluss. Die Produktion schreitet ja nicht von allein voran, sondern weil neue Information die Bewegung auslöst.

In der Produktentwicklung ist Information die Arbeit. Entscheidungen, Randbedingungen, Schnittstellen und Annahmen fließen zwischen Menschen und Werkzeugen. Wenn wir diesen Fluss kartieren, sehen wir, wo Entscheidungen hängen bleiben, wo Kontext verloren geht und wo unvalidierte Annahmen nachgelagert weitergereicht werden.

In Systems Engineering kartieren wir nicht nur Prozessschritte, wir kartieren Entscheidungspunkte, Schnittstellenverantwortung und Rückkopplungsschleifen. Viele späte Integrationsprobleme sind keine Technikprobleme, sondern Informationsflussprobleme.

Der Nutzen ist kausale Klarheit. Verzögerungen, Nacharbeit und späte Integrationsausfälle wirken nicht mehr mysteriös. Wir können sie auf konkrete Brüche im Informationsfluss zurückführen.

3. Systemische Engpässe identifizieren

Wertstromanalyse lehnt die Idee ab, dass jeder Teil des Systems jederzeit gleich wichtig ist. Manche Zwänge dominieren die Durchlaufzeit. Andere nicht.

In der Entwicklung sind diese Engpässe häufig knappe Experten, Integrationen, Testumgebungen oder Freigabegremien. Wenn wir den gesamten Wertstrom abbilden, erkennen wir, wo Arbeit sich staut und warum lokale Optimierung anderswo wenig Effekt hat.

Der Nutzen ist Hebelwirkung. Verbesserung verschiebt sich von „alle müssen schneller werden“ zu „dieser Engpass bestimmt die Lerngeschwindigkeit“. Genau dort gewinnen wir Produktgeschwindigkeit.

4. Der Bauplan für einen Soll Zustand

Die Soll Karte ist der am meisten unterschätzte Beitrag des Buches. Sie ist ein qualitativer Systementwurf, kein Kennzahlen Dashboard.

In der Produktentwicklung beschreibt der Soll Zustand, wie Lernen fließen soll. Die Granularität wird feiner, zum Beispiel von Designentscheidungen. Wir nutzen Pull-Systeme, die auf validierten Hypothesen basieren statt auf Vermutungen oder Milestones im Kalender. Explizite Taktungen für Review und Integration können Varianz reduzieren.

Wenn wir vom klassischen Systems Engineering geprägt sind, werden wir hier eine Parallele zur Architekturarbeit sehen: Wir definieren die Struktur, in der Entscheidungen getroffen, verifiziert und integriert werden. Damit gestalten wir die Dynamik des Entwicklungsystems, nicht nur die Geschwindigkeit einzelner Tätigkeiten.

Der Nutzen ist Kohärenz. Lokale Prozessänderungen kämpfen nicht mehr gegeneinander. Wir verstehen nicht nur, was zu ändern ist, sondern warum das System genau so geformt werden soll.

Konkretes Industriebeispiel

Stellen wir uns einen Automobilzulieferer vor, der ein Steuergerät für ein Fahrerassistenzsystem entwickelt. Klassisch organisiert existieren getrennte Bereiche für Requirements, Architektur, Software, Hardware, Test, Safety und Freigabe. Jede Einheit optimiert sich lokal: Requirements streben nach Vollständigkeit, die Architektur nach Stabilität, der Test nach möglichst reifen Builds, Safety nach belastbaren Nachweisen. Das Ergebnis sind große Batches: Integration findet nur alle paar Monate statt, Reviews erfolgen in Gremien, Testumgebungen sind knapp, Freigaben stauen sich.

Eine Wertstromanalyse über den gesamten Entwicklungswertstrom macht sichtbar, dass nicht „die Entwicklung zu langsam“ ist, sondern dass sich Design-in-Process an wenigen, klar identifizierbaren Stellen aufstaut: bei Architekturentscheidungen, die auf Rückfragen aus der Safety warten, bei der Systemintegration aufgrund überbuchter HIL-Umgebungen und bei der Freigabe, weil die Nachweisführung erst spät konsolidiert wird. Der Soll-Zustand lässt sich dann sehr konkret formulieren: kleinere Integrationspakete in einem festen Rhythmus, Pull für Features nur dann, wenn Testkapazität verfügbar ist, sowie eine frühe und kontinuierliche Nachweisführung, die Safety und Engineering eng verzahnt. Die Produktgeschwindigkeit steigt, ohne zusätzliche Ressourcen, weil der Fluss von Entscheidungen und Verifikationen stabiler und vorhersehbarer wird.

Fazit

Mike Rother und John Shook haben Learning to See für Fabriken geschrieben, aber das Buch lehrt Systemdenken und ist im Systems Engineering ebenso relevant. Produktentwicklung leidet am gleichen Grundproblem wie Produktion vor Lean: Arbeit wird lokal optimiert, während Wert global stagniert.

Wertstromanalyse bieten uns einen Ausweg. Wenn wir Design-in-Process (DIP) sichtbar machen, Informationsfluss kartieren, echte Engpässe identifizieren und einen Soll Zustand bewusst entwerfen, können wir Lernen beschleunigen, ohne Chaos zu erhöhen. Und aus klassischer Systems Engineering Perspektive ist das nichts anderes als Systemgestaltung: Wir arbeiten am Verhalten des Gesamtsystems.