Die vier Prinzipien für mehr Produktgeschwindigkeit
Ich komme mir inzwischen wie eine zerkratzte Schallplatte vor: Wir haben ein Wettberwerbsproblem, wir müssen bessere Produkte schneller entwickeln. So weit, so gut. Doch wie stellen wir das an? In diesem Artikel stelle ich vier Prinzipien vor, die das Fundament dafür darstellen. Die Prinzipien sind kein Allheilmittel; sie sind aber so universell, dass sie sowohl auf Führungsebene als auch von den Praktikern verstanden und angewendet werden können. Gleichzeitig sind sie spezifisch genug, um allen Beteiligten eine klare Richtung und gemeinsames Verständnis zu geben.
Für das Systems Engineering (SE) sind diese Prinzipien besonders relevant. Denn SE ist der Ort, an dem Werteflüsse, Architektur, Compliance und V&V zusammenlaufen.
Was hier unter „Prinzipien“ verstanden wird
Ein Prinzip ist in diesem Kontext eine grundlegende Leitidee, die Entscheidungen systematisch führt. Prinzipien wirken auf einer höheren Abstraktionsebene und beantworten die Frage: „Worauf kommt es grundsätzlich an?“.
Prinzipien können auf verschiedenen Flugebenen wirken. Die Prinzipien von Reinertsen, zum Beispiel, sind viel feingranularer, sind jedoch genauso grundlegend und wirkungsvoll. In vielen Fällen fungieren sie als Muster oder Entscheidungsheuristiken, die in bestimmten Situationen angewendet werden können, insbesondere wenn die Flow im Mittelpunkt steht.
In ähnlicher Weise formuliert Industrial DevOps eine breitere Reihe von Prinzipien, die auf die Integration des Lebenszyklus und die digitale Kontinuität abzielen. Es gibt deutliche Überschneidungen, insbesondere in Bereichen wie Feedback-Schleifen und Systemintegration. Die hier vorgestellten Prinzipien fassen jedoch das Wesentliche in nur vier übergreifenden Prinzipien zusammen, die das gesamte Entwicklungssystem prägen.
Kurz gesagt, die Prinzipien von Product Velocity sind systemische Verpflichtungen. Sie beeinflussen, wie wir Erfolg definieren, wie wir die Architektur strukturieren, wie wir die Arbeit validieren und wie wir Produkte über ihren gesamten Lebenszyklus pflegen..
Die vier Prinzipien
Hier nun die vier Prinzipien für Product Velocity. Dabei bette ich konkrete Fallstudien ein, die das entsprechende Prinzip anhand einer echten Case Study zeigen:
1. Value Thinking: Definieren & Ausrichten
In vielen Organisationen entsteht mangelnde Geschwindigkeit nicht nur durch explodierende Komplexität, sondern durch Unklarheit darüber, was wirklich für den Erfolg wichtig ist. Teams optimieren lokal, während der Kundenwert implizit, und damit oft auf der Strecke bleibt. Diese Fehlanreize führen zu Rework, Verzögerung und Verlust von Verantwortung.
Value Thinking beginnt mit einer einfachen, aber anspruchsvollen Verpflichtung: Wir definieren messbare Ergebnisse und richten alle relevanten Akteure konsequent darauf aus. Dazu schärfen wir kontinuierlich die Stakeholder Needs und machen transparent, wie jede Aktivität zum Wertfluss beiträgt.
Value Thinking stärkt die Business-Perspektive, indem wir Stakeholder-Intention in gemeinsame, messbare Zielgrößen übersetzen und Architektur- sowie Engineering-Entscheidungen konsequent daran spiegeln. Es geht weniger um Priorisierung im engen Sinn, sondern um Kohärenz im Gesamtsystem.
Ein praktisches Beispiel liefert die Ameru Smart Bin Fallstudie. Das Team definierte Erfolg von Anfang an nicht als „bessere Genauigkeit“, sondern über messbare Stakeholder-Ergebnisse: Die Entsorgung musste für Nutzer genauso bequem sein wie bei herkömmlichen Mülleimern, Betreiber mussten deutlich weniger Wertstoffe im Restmüll verlieren, und die Recyclingquote musste so steigen, dass sich die Investition rechnet. Diese klaren KPIs prägten das Design, die KI-Klassifikationsschwellen und Service-Entscheidungen. Weil das Team auf Stakeholder-Wert statt isolierte technische Performance optimierte, führten Verbesserungen direkt zu wirtschaftlicher Wirkung und einem belastbaren Return on Investment.
2. Architect for Flow: Strukturieren & Skalieren
Architecting for Flow zeigt, dass Geschwindigkeit nicht durch Improvisation, sondern durch bewusste Struktur entsteht. Wir bauen ein modulares, skalierbares Rückgrat, das Ergebnisse schnell zum Nutzer bringt, ohne dass dieselben Fragen immer wieder diskutiert werden.
In cyber-physischen Systemen entscheidet Architektur darüber, wie schnell sich Änderungen umsetzen lassen, wie sicher wir experimentieren können und wie sich Wissen über Produktgenerationen hinweg aufbaut. Schnittstellen, Plattformstrategien und integrierte Modelle sind dabei wirksamme ökonomische Mechanismen. Unklare Grenzen erzeugen Koordinationsaufwand und fragile Integrationen. Klare Modularisierung erlaubt Teams, weitgehend eigenständig zu arbeiten und dennoch Systemkohärenz zu sichern.
Dieses Prinzip stärkt primär die Architektur-Perspektive, wirkt aber auf das gesamte System. Wenn Struktur explizit ist und Schnittstellen stabil bleiben, beschleunigen wir Engineering und senken das Risiko in der Implementierung.
Ein anschauliches Beispiel liefert Wagners langfristige Modellierungsstrategie für sicherheitskritische Brandschutzsysteme. Statt einer einmaligen Transformation hob Wagner schrittweise Abstraktionsebenen an, stärkte Kapselung und etablierte Contract-Based Design als bewusste Architekturrichtung. Aus vielen kleinen Schritten entstand eine konsistente Entwicklungsplattform mit Automatisierung, Regressionstests und skalierbarer Wiederverwendung. So verkürzten sich Zertifizierungszyklen deutlich. Die Architekturdisziplin verankerte Fluss direkt in der Struktur des Systems.
3. Shift Left: Bauen & Validieren
Shift Left adressiert eine der hartnäckigsten Ursachen verlorener Geschwindigkeit: späte Erkenntnisse. Wenn wir Integration, Verifikation und Validierung aufschieben, stauen sich Unsicherheiten unbemerkt auf, bis wir plötzlich in der Krise stecken.
Shift Left heißt, Lernen systematisch nach vorne zu ziehen. Dazu gehören kontinuierliche Integration von Software und Hardware, frühe Schnittstellensimulationen, modellbasierte Verifikation und zunehmend KI-gestützte Analysen von Anforderungen und Testartefakten. Wir automatisieren nicht nur bestehende Schritte, sondern verkürzen strukturell die Distanz zwischen Absicht und Feedback.
Dieses Prinzip strafft die Engineering-Perspektive, indem wir Unbekanntes so früh wie möglich in validiertes Wissen verwandeln. Dadurch sinken Änderungskosten und Iterationszyklen werden kürzer.
Ein Beispiel liefert ZF bei der Entwicklung von Hochleistungselektronik. Früher dominierte die Validierung als Engpass und beanspruchte durch umfangreiche physische Tests und rechenintensive Simulationen bis zu zwölf Monate. ZF verlagerte Verifikation und Validierung konsequent nach vorne und etablierte modellbasierte Digitale Zwillinge. Mit strukturierter Modellierung und KI-gestützter Modellreduktion, die Laufzeiten beherrschbar hält, entstand eine wiederholbare, vertrauensbildende Validierungsfähigkeit im Entwicklungsfluss. So verkürzte sich die Validierungszeit von zwölf auf zwei Monate bei gleichbleibenden Sicherheits- und Compliance-Standards.
4. Accelerate: Betreiben & Weiterentwickeln
Das letzte Prinzip macht klar: Wir sichern Geschwindigkeit nur, wenn Entwicklung nicht mit dem Markteintritt endet. Accelerate versteht Produktentwicklung als fortlaufenden Evolutionsprozess, in dem Betrieb, Feedback und Iteration eng miteinander verzahnt sind.
In klassischen Modellen entwickeln und liefern wir Produkte und frieren sie dann bis zur nächsten großen Revision ein. In einer Product-Velocity-Umgebung markiert der Release den Übergang in eine neue Lernphase. Betriebsdaten, Digitale Zwillinge und Update-Mechanismen erlauben es uns, das Produkt gemeinsam mit Nutzerverhalten und Umweltbedingungen weiterzuentwickeln.
Dieses Prinzip stärkt die Delivery-Perspektive und verbindet sie wieder mit Business und Architektur. Feedback aus dem Einsatz beeinflussen Backlog-Priorisierung, Architekturentscheidungen und sogar Plattformstrategien.
Für Saab bedeutet Accelerate, schnelle Entscheidungsfindung als operative Fähigkeit zu institutionalisieren. Saab etablierte einen täglichen Eskalationsrhythmus, in dem Blocker sichtbar werden und bei Bedarf noch am selben Morgen die Führungsebene erreichen. Das Management reserviert täglich Zeit, um Hindernisse aufzulösen, und macht Entscheidungsverzögerung zu einer aktiv gesteuerten Größe statt zu einem administrativen Nebeneffekt. Probleme, die sonst Wochen liegen blieben, lösen Teams innerhalb weniger Stunden und schützen so den Designfluss.
Was bedeuten diese Prinzipien konkret für das Systems Engineering?
In unserer Rolle als Systems Engineers können wir die Prinzipien sehr konkret als Kompass bei unserer Arbeit benutzen:
Value Thinking im SE: Wir stellen sicher, dass sich alle Aspekte unserer Arbeit auf einen messbaren Stakeholder Value zurückführen lässt und idealerweise damit verknüpft ist. Wir fragen systematisch:
- Welches Problem wird ökonomisch oder funktional gelöst?
- Welche Zielgröße verändert sich?
- Woran erkennen wir Erfolg?
SE wird damit vom Dokumentations- zum Wertvermittler. Requirements werden nicht nur verwaltet, sondern begründet.
Architect for Flow im SE: Hier liegt die klassische Stärke des Systems Engineering, wird aber oft nicht konsequent genug genutzt. Architekturentscheidungen bestimmen:
- Wie stark Teams voneinander abhängig sind
- Wie aufwendig Änderungen werden
- Wie gut Modelle integrierbar sind
- Wie viel Wiederverwendung möglich ist
Architect for Flow fordert ein bewusstes Management von Schnittstellen, Abstraktionsebenen und Modellkohärenz. MBSE wird kritisch hinterfragt und zum Mittel zur Reduktion von Koordinationskosten.
Shift Left im SE: SE ist traditionell eng mit Verifikation und Validierung verknüpft. Doch in vielen Organisationen bleibt V&V sequenziell organisiert. Shift Left im Systems Engineering bedeutet:
- Frühe Modellvalidierung
- Kontinuierliche Konsistenzprüfungen
- Simulation vor Hardware
- Requirements-Qualitätsanalyse vor Implementierung
- Durchgängige Traceability, die tatsächlich genutzt wird
Das reduziert Änderungsaufwände exponentiell und macht Unsicherheiten früh sichtbar.
Accelerate im SE: Für das Systems Engineering heißt Accelerate, dass die Systemdefinition nicht bei der Auslieferung endet. Wir denken nicht in Projekten, sondern in Produkten, später sogar Plattformen.
Rückmeldungen aus dem Betrieb müssen strukturiert in Modelle, Anforderungen und Architektur zurückfließen. Digitale Zwillinge, OTA-Updates und datengetriebene Weiterentwicklung verändern die Rolle des SE fundamental.
SE wird zur kontinuierlichen Systemverantwortung über den gesamten Lebenszyklus hinweg.
Das Buch: Product Velocity
In meinem kommenden Buch Product Velocity zeige ich, wie Organisationen diese vier Prinzipien systematisch umsetzen.
Das Buch verbindet Systems Engineering, Architektur, Ökonomie und Organisationsdesign zu einem kohärenten Gesamtbild. Es geht nicht um einzelne Tools oder Methoden, sondern um strukturelle Hebel, mit denen Unternehmen nachhaltige Geschwindigkeit aufbauen können.
Viele der dort beschriebenen Fallstudien stammen aus realen Industrieprojekten und zeigen, wie sich diese Prinzipien konkret anwenden lassen.
Fazit
Wettbewerbsfähigkeit im 21. Jahrhundert entsteht nicht durch ein besseres Spaltmaß, sondern durch das Schaffen von Wert für die Stakeholder. Die vier Prinzipien liefern ein Fundament, auf dem Systems Engineering seine volle Wirkung entfalten kann:
- Wert explizit machen
- Architektur als Flussinstrument verstehen
- Lernen frühzeitig erzwingen
- Entwicklung und Betrieb koppeln
Wer diese Prinzipien ernst nimmt, verändert nicht nur Prozesse. Er verändert das System, in dem entwickelt wird.
