Die Entwicklung von Lösungen ist von Natur aus ein unsicherer Prozess. Technische Schwankungen und Marktschwankungen sind während des gesamten Entwicklungsprozesses vorhanden. Innovative neue Systeme sind per Definition noch nie zuvor entwickelt worden, so dass es keinen garantierten Weg zum Erfolg gibt. Wäre dies der Fall, würde es sich nicht um Innovation handeln. Deshalb lieben wir dieses Geschäft.

Um den Fortschritt zu sichern, neigen Systementwickler dazu, die Variabilität so schnell wie möglich zu reduzieren. Je deterministischer die Dinge sind, desto besser fühlen wir uns. Das liegt einfach in der menschlichen Natur. Je mehr wir zu wissen glauben und je mehr wir bereits entschieden haben, desto weiter glauben wir zu sein. Bis zu einem gewissen Punkt stimmt das auch, aber selbst dann ist die Variabilität eine ständige Präsenz.

Variabilität ist an sich weder schlecht noch gut – sie ist einfach, was sie ist. Aber es sind die wirtschaftlichen Aspekte, die mit dem Zeitpunkt und der Art der Variabilität verbunden sind, die das Ergebnis bestimmen. Das Ziel ist es, die Variabilität zu managen und Optionen zu bewahren, um den Teams die Kontrolle und Flexibilität zu geben, die sie für die Entwicklung großartiger Lösungen benötigen.

In diesem Artikel wird beschrieben, wie Variabilität verwaltet und Optionen mit setbasiertem Design bewahrt werden können. Mehr zum Thema Variabilitätsmanagement finden Sie unter:
Prinzip Nr. 7 – Kadenz anwenden; mit bereichsübergreifender Planung synchronisieren.

Optionen bewahren mit Set-Based Design

Die Erkenntnis, dass es bei der Entwicklung immer wieder zu Schwankungen kommt, veranlasst uns, unseren Ansatz zu überdenken. Herkömmliche, sequentielle, stufenweise Entwicklungspraktiken treiben die Entwickler dazu, sich schnell auf eine einzige Option zu einigen – einen vereinbarten Punkt im Anforderungs- und Designlösungsraum – und dann das Design so lange zu ändern, bis es schließlich die volle Systemabsicht erfüllt. Jeder hat das gute Gefühl, dass er die richtigen Anforderungen und den richtigen Entwurf hat. Zumindest für eine gewisse Zeit.

In der Tat kann dies ein effektiver Ansatz sein – es sei denn, man wählt den falschen Ausgangspunkt. Dann können die nachfolgenden Iterationen zur Verfeinerung der Lösung Zeit verschwenden und zu erheblichen Lieferproblemen führen, wie in Abbildung 1 [2] dargestellt.

Es bleibt einfach nicht genug Zeit, um sich zu erholen. Das liegt daran, dass wir – bewusst oder unbewusst – schon früh im “Kegel der Ungewissheit” [3] operieren und versuchen, durch das Einfrieren von Anforderungen und Design Gewissheit zu erzwingen. Je größer und technisch innovativer das System ist, desto höher ist die Wahrscheinlichkeit, dass der vereinbarte Ausgangspunkt nicht der beste war.

Ein besserer Ansatz, der als Set-Based Design (SBD) oder Set-Based Concurrent Engineering (SBCE) bezeichnet wird, ist in Abbildung 2 [4] dargestellt.

Bei diesem Ansatz werfen die Entwickler zunächst ein breiteres Designnetz aus, indem sie zu Beginn mehrere Designoptionen in Betracht ziehen. Danach bewerten sie fortlaufend die wirtschaftlichen und technischen Kompromisse, die sich in der Regel aus den objektiven Beweisen ergeben, die an integrationsbasierten Lernpunkten präsentiert werden. Wie in Abbildung 3 dargestellt, werden die schwächeren Optionen im Laufe der Zeit eliminiert und schließlich auf der Grundlage der bis dahin gewonnenen Erkenntnisse ein endgültiges Design festgelegt.

Dieser Prozess lässt die Entwurfsoptionen so lange wie möglich offen, konvergiert, wenn nötig, und führt zu optimaleren technischen und wirtschaftlichen Ergebnissen.

(Hinweis: Aufgrund des Umfangs und der wirtschaftlichen Auswirkungen von großen Systemen ist die Mengenplanung ein grundlegendes Konstrukt von Large Solution SAFe. Für weitere Informationen, einschließlich einer Anleitung zur Anwendung von Set-Based Design auf feste Terminverpflichtungen, Planungsauswirkungen und wirtschaftliche Kompromisse, lesen Sie den Artikel Set-Based Design und die Anleitung im Artikel zur Kompetenz Enterprise Solution Delivery).

Erfahren Sie mehr
[1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.
[2] Iansiti, Marco. Shooting the Rapids: Managing Product Development in Turbulent Environments. California Management Review, 38. 1995.
[3] McConnell, Steve. Software Project Survival Guide. Microsoft Press, 1997.
[4] Ward, Allan C., and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute Inc., 2014.