Das 1. Gesetz des Systems Engineering

CSD&M ist die französische INCOSE-Konferenz, die letzte Woche in Paris stattfand. Die mit Abstand spannendste Keynote wurde von Prof. Olivier de Weck gehalten, der auf der Suche eines universellen Gesetzes der Komplexität ist. Im Folgenden werde ich das Gesetz der Komplexität vorstellen, welches er entdeckt hat.

„Gesetze“ in den Naturwissenschaften können trügerisch einfach sein, wie zum Beispiel E=mc² (Äquivalenz von Masse und Energie) oder ΔU = Q – W (1. Gesetz der Thermodynamik).

Welche quantifizierbare Eigenschaft lässt sich in den Systemwissenschaften finden? Komplexität!

Olivier de Weck hat es sich zum Ziel gesetzt, auch für die Systemwissenschaften eine Gesetzmäßigkeit zu finden. Dazu stellte er erst die Frage, welche zentrale, quantifizierte Eigenschaft von Systemen dazu herangezogen werden sollte. Hier sind die Folien des Vortrags.

So eine Eigenschaft sollte zwei Eigenschaften haben. Zum einen soll sie nützlich, zum anderen quantifizierbar sein. Schnell stieß er dabei auf Komplexität, die beides erfüllt.

Komplexität messen

Eine nützliche Metrik für Komplexität ist zum Beispiel eine Design Strcture Matrix, mit der sich schnell Komplexität in der Form eines Prozentzahl ausdrücken lässt. Nützlich, aber bei weitem nicht genau genug.

Statt dessen identifizierte er drei Komponenten der Komplexität, über die die Gesamtkomplexität berechnet werden kann:

C1 – Inherente Komplexität, es gibt schließlich einfache Komponenten (bspw. Schraube) und komplexe (bspw. Integrierte Schaltung).

C2 – Anzahl und Komplexität der Schnittstellen

C3 – Topologische Komplexität, bspw. ist eine verteilte Architektur komplexer als eine zentralisierte Architektur mit der selben Anzahl von Komponenten.

Mit diesen Variablen kann nun das 1. Gesetz des Systems Engineering formuliert werden:

Konsequenzen

Diese Gesetzmäßigkeit hat konkrete Auswirkungen. Insbesondere brauchen wir eine gewisse Komplexität – ansonsten würde niemand unsere Produkte kaufen, wenn sie nicht mehr können würden als die Produkte, die bereits auf dem Markt sind. Das folgend Bild zeigt diese Dynamik, mit Kunden und Wettbewerb als Komplexitätstreiber.

Neben der funktionalen und strukturellen Komplexität kommt hier noch die organisatorische Komplexität hinzu, die, nach Conways Gesetz, von der Komplexität des zu entwickelnden Produkts abhängt.

Da es unser Ziel sein sollte, den Aufwand für die Entwicklung zu minimieren ohne den Erfolg in Gefahr zu bringen, lassen sich aus aus dem bisher gesagten mehrere Erkenntnisse ableiten:

• Wir sollten ein Budget für Komplexität setzen – genauso wie Zeit, Geld und Ressourcen budgetiert werden, sollten auch Budgets für Komplexität gesetzt werden
• Iso-Complexitäts-Tradeoffs – wir haben drei Komponenten der Komplexität beschrieben, aber was ist sinnvoller: Komplexe Komponenten mit einer einfachen Architektur, oder einfache Komponenten bei einer komplexen Struktur? Zum Teil hängt dies an den Kompetenzen der umsetzenden Organisation.
• Entwicklungsaufwand kann optimiert werden – mit Hilfe dieser Zusammenhänge können wir die Entwicklung optimieren, und zwar nicht nur bezüglich der Kosten, sondern auch bezüglich des Kundenmehrwerts.

Noch nicht am Ende

Vieles von dem Vorgetragenen muss noch sauber wissenschaftlich belegt und weiter untersucht werden, aber die bisherigen Ergebnisse sind hochspannend, und nicht nur das: Sie sind von praktischer Relevanz. Ich werde mich weiter mit diesem Thema auseinandersetzen.

Bildquellen Michael Jastram (Cover), Olivier de Weck (Diagramm)