Es ist nicht die stärkste Spezies die überlebt auch nicht die intelligenteste, sondern eher diejenige die am ehesten fähig ist sich anzupassen.Charles Darwin

Dieses Zitat von Charles Darwin gilt nicht nur in der Tier- und Pflanzenwelt, sondern lässt sich auch auf die Produktentwicklung in Unternehmen unterschiedlichster Industrien übertragen. Um die Anpassungsfähigkeit und Flexibilität in den Unternehmen zu erhöhen, kommen nicht nur in der Produktentwicklung unterschiedlichste Ansätze zur Anwendung, die sich u. a. auf Design Thinking oder agile Methoden abstützen. Das hier beschriebene Modell des „Decoupled Development“ beschreibt eine Entwicklung, die jeden Produktumfang in der optimalen, sich an dem spezifischen Lebenszyklus orientierenden Geschwindigkeit entwickelt. Lassen Sie uns aber in einem ersten Schritt die Motivation für ein solches Modell genauer betrachten.

Um sich in globalisierten, sich immer schneller weiterentwickelnden Märkten mit erhöhtem Konkurrenzkampf durchzusetzen, muss die Produktentwicklung flexibler und ihre Produkte aktueller werden. Zusätzlich muss die Komplexität der Produkte beherrschbar bleiben.

Der fortschreitende technische Wandel in den Hochtechnologiebranchen, der zu immer innovativeren Produkten führt, zwingt dazu, schnell auf Änderungen reagieren zu können. Unter anderem durch das Internet, welches einen beinahe unbegrenzten Zugang zu Informationen ermöglicht, ändern Kunden Ihre Meinungen heute schneller, reagieren umgehender auf Trends und erwarten eine hohe Produktaktualität. Des Weiteren sind Hochtechnologieunternehmen heute mit einer steigenden Komplexität ihrer Produkte konfrontiert. Beispielsweise ist die theoretisch mögliche Anzahl an Varianten im Automobilbau von unter 10 beim Ford T-Modell (1910er Jahre) auf bis zu 1020 Varianten bei heutigen Automobilbauern explodiert.

Zusätzlich fördern die heute (noch) weit verbreiteten, eher planungsorientierten Managementansätze wie „Stage Gate“ oder „Six Sigma“ sowie die mangelnde Fehlertoleranz („Null-Fehler-Strategie“) in den Unternehmen nicht gerade die Flexibilität, schnell auf Änderungen reagieren zu können. Diese Änderungen können unterschiedlichster Art sein:

• Kunden können ihre Anforderungen an ein Produkt meist erst klar definieren, wenn sie es sehen bzw. in den Händen halten.
• Marktanforderungen ändern sich aufgrund von regulatorischen Eingriffen oder dem Eintritt neuer Unternehmen.
• Neue Technologien eröffnen neue Chancen, können aber auch zum Risiko werden.
• Organisatorische Änderungen im Unternehmen führen zu einem Wechsel der Entwicklungsmannschaft und so gegebenenfalls zu Änderungen am Produkt.

Grundsätzlich ergeben sich unterschiedliche denkbare Reaktionsmöglichkeiten, um diesen Veränderungen gegenüberzutreten.

Als erste Möglichkeit können Unternehmen und deren Management versuchen, detaillierter zu planen und die Veränderungen zu antizipieren. Diese Reaktion ist klassisch für traditionell geprägte Manager, die sich an den planungsgetriebenen Managementansätzen orientieren. Hierbei lehrt uns jedoch die Realität, dass die Wahrscheinlichkeit, alle möglichen Eventualitäten und Änderungen über einen längeren Zeitraum zu antizipieren, sehr begrenzt ist. In diesem Zusammenhang ist sicherlich auch das beliebte „Frontloading“ zu nennen, das richtig angewandt zur früheren Produktreife führen kann, jedoch oft dazu führt, dass mit der Entwicklung noch früher begonnen wird als bisher, aber die Entwicklung nur selten frühzeitig abgeschlossen wird. Diese längere Entwicklungszeit zwischen SoD („Start of Development“) und SoP „Start of Production“) führt dann in einem dynamischen Umfeld in letzter Konsequenz dazu, dass es noch schwieriger wird, die richtigen Vorhersagen und somit Entscheidungen zu treffen.

Eine zweite denkbare Reaktion ist es, schneller zu werden, um möglichen Veränderungen weniger Angriffsfläche zu bieten. Ein methodischer Ansatz hierfür sind bspw. agile Arbeitsformen, die heute in aller Munde sind. Diese teilen die Entwicklung in kleine Iterationen von wenigen Wochen auf und stellen u. a. die flexible Reaktion auf Änderungen und nicht die strikte Planerfüllung in den Mittelpunkt ihres Handelns.

Drittens können Prozesse und Tools etabliert werden, die zum einen die Auswirkungen von Änderungen kontrollierbarer gestalten und zum anderen die Reaktionsfähigkeit auf Änderungen erhöhen.

Das in diesem Artikel beschriebene Modell der Produktentwicklung der multiplen Geschwindigkeiten greift die zwei letztgenannten Reaktionsmöglichkeiten auf und kombiniert sie mit weiteren methodischen und technologischen Ansätzen, die in Summe dazu führen, deutlich flexibler zu entwickeln. Bevor jedoch die Bestandteile des Konzeptes detailliert werden, wird am Beispiel eines Automobilherstellers aufgezeigt, welche Merkmale im heutigen Entwicklungsprozess eine stärkere Flexibilisierung verhindern. Der Automobilhersteller steht dabei stellvertretend für viele produzierende Konzerne in Deutschland. Das Beispiel verdeutlicht die Motivation hinter dem Konzept „Decoupled Development“.

Die Fahrzeugentwicklung ist typischerweise Derivats-getrieben, d. h., die Entwicklung erfolgt in einzelnen Projekten für die einzelnen Fahrzeugtypen und -modelle. Die Vielzahl der Subsysteme und Komponenten werden im Rahmen eines Fahrzeugprojektes mitentwickelt und orientieren sich somit stark am übergreifenden Fahrzeugentwicklungsablauf. Die einzelnen Entwicklungsumfänge des Fahrzeugs werden nur selten herausgelöst – mit Ausnahme von ausgewählten Baukastenumfängen – und zeitlich unabhängig vom Gesamtsystem entwickelt. Die ganze Organisation orientiert sich stark an lange im Vorfeld festgelegten Bau- oder Berichts-Events. Diese Events takten mit Abständen von mehreren Monaten das Fahrzeugprojekt und die angegliederten Subsystem- und Komponentenentwicklungsprojekte. Vor allem im Vorfeld zu diesen Ereignissen entstehen in allen beteiligten Organisationseinheiten hohe Aufwände für die Aufbereitung von Daten, Entwicklungsergebnissen, Erstellung von Managementberichten etc. Zusätzlich ist die Integration und Absicherung der Entwicklungsumfänge stark hardwaregetrieben, was auf Grund der Werkzeugbeschaffungszeiten und starren Bauphasen zu langen Vorlauf- bzw. Wartezeiten führt. Produktseitig bietet die Fahrzeugarchitektur mit engen Wechselwirkungen und komplexen Abhängigkeiten sowie Schnittstellen der technischen Umfänge nur wenig Möglichkeiten, einzelne Umfänge weitgehend autonom zu entwickeln. Des Weiteren erschweren fehlende Produktvorhalte, wie bspw. zusätzlich vorgehaltene Sensoren für nachträgliche Produkt-Updates, die Möglichkeit, die Produktaktualität auch nach Auslieferung weiterhin sicherzustellen und somit auf geänderte Marktbedürfnisse zu reagieren. Statische, stark an der physischen Produktarchitektur orientierte und kleinteilig agierende Organisationsstrukturen werden der heute notwendigen Flexibilität nicht mehr gerecht. Das Selbstverständnis und Handeln des Managements sind klassisch planungsorientiert und Entscheidungen bis in die Tiefen des Fahrzeuges werden oft auf den oberen Managementebenen getroffen. Dies lässt sich u. a. in der nur wenig ausgeprägten Fehlerkultur begründen. Begünstigende Technologien wie z. B. „Rapid Prototyping“, durchgängige Virtualisierung oder eine stärkere Automatisierung der Entwicklungsprozesse werden noch nur vereinzelt genutzt.

Acht Prinzipien der Produktentwicklung multipler Geschwindigkeiten

Die Produktentwicklung der multiplen Geschwindigkeiten definiert sich über acht Prinzipien, die ausgehend vom Status quo den Zielzustand beschreiben.

1) Dominanter virtueller Pfad

Heutige Produktentwicklungsprozesse etablierter Industrieunternehmen zeichnen sich oft durch ihre starke Hardwareorientierung aus. Die Entwicklung als solches orientiert sich an Hardwareprototypen, die bei komplexen Produkten wie bspw. einem Automobil ab mehreren Jahren vor und bis zum eigentlichen Start der Serienproduktion in mehreren Bauphasen und in ansteigender Stückzahl (hunderte Einheiten in Summe) entwickelt und produziert werden. Im Kontext der Produktentwicklung multipler Geschwindigkeiten steht ein dominanter virtueller Pfad im Mittelpunkt. Dieses virtuelle Abbild, bestehend aus Daten unterschiedlichster Quellen (z.B. CAD-Daten, Simulationsdaten, Funktionsmodelle) des Produktes und dessen Systemen, ermöglicht es so spät wie möglich, aber so früh wie nötig in Hardware zu gehen, um z. B. Verifikations- und Validierungsmaßnahmen durchzuführen. Physische Prototypen werden nur noch für die technischen Umfänge gebaut, bei denen das virtuelle Modell nicht ausreicht. Ein
(nahezu) vollkommener Entfall von Hardwareprototypen ist hierbei allerdings auf Grund der aktuell noch nicht virtuell abzubildenden Wirkzusammenhänge und Abhängigkeiten nicht vorstellbar.

2) Lebenszyklusorientierte Entwicklungszeiten

Die meisten Entwicklungsabteilungen, die heute komplexe mechatronische Systeme entwickeln, orientieren sich typischerweise an der Zeitschiene des Gesamtsystems, die meist auf die „long-lead Items“ ausgerichtet ist und deshalb die minimal mögliche Durchlaufzeit vorgibt. Diese Zeitschiene wird dann auch für die Teilsysteme und Komponenten angesetzt, die eigentlich schneller oder in für ihre Produktaktualität optimierten Zeiträumen entwickelt werden könnten. Um die Produktaktualität vor Kunde deutlich zu verbessern, setzt das Konzept der multiplen Geschwindigkeiten auf komponentenspezifische, lebenszyklusorientierte Entwicklungszeiten. Ein gutes Beispiel technischer Umfänge aus der Automobilindustrie, die von einer derartigen Vorgehensweise profitieren würden, sind beispielsweise Infotainmentsysteme, die in der heutigen Entwicklung mehrere Jahre vor SoP spezifiziert werden und damit eigentlich bereits veraltet sind, sobald sie in das Fahrzeug kommen.

3) Übergeordneter, fester Takt

Synchronisationspläne über alle beteiligten Entwicklungsfunktionen und wichtigen Schnittstellenpartner takten in vielen Unternehmen die Produktentwicklung. Jedoch weisen diese Synchronisationspläne keinen übergeordneten, gleichmäßigen Takt auf, sondern strukturieren die Entwicklung in sich an der Menge der Entwicklungsaufwände orientierenden, unterschiedlich langen Zeiträumen (von Meilenstein zu Meilenstein). Um jedoch die Synchronisation zwischen den verschiedensten Fakultäten in der Entwicklung möglichst einfach zu gestalten und zu koordinieren, ist es vorteilhaft, eine Gleichartigkeit in der zeitlichen Abfolge zu gewährleisten.

Aus dem Ansatz der lebenszyklusorientierten Entwicklungszeiten resultieren individuelle Produktentwicklungsprozesse, die in einem übergeordneten, festen Takt zu synchronisieren sind. Für Umfänge, die eine sehr starke Abhängigkeit mit dem Gesamtsystem haben, wie bspw. das Fahrwerk beim Automobil, und bei denen eine Entkopplung wenig Mehrwert bringt, ist es weiterhin sinnvoll, diese Umfänge als Basiskomponenten im Gesamtsystem-Entwicklungsprozess zu entwickeln. Bei der Entkopplung ist es essentiell, dass eine starke Ordnungsfunktion, z. B. Chief Architect, ähnlich eines Dirigenten des Orchesters, den Prozess der unterschiedlich „einsetzenden“ Teilentwicklungen und der Integration auf den verschiedenen Systemebenen etc. orchestriert.

4) Permanentes, durchgängiges Gesamtmodell

Damit bei diesem „Konzert“ der unterschiedlichen Geschwindigkeiten jeder genau weiß, welcher Datenstand im dominanten virtuellen Pfad gerade der aktuelle bzw. relevante ist, ist es essentiell von einem heute vorherrschenden virtuellen Modell des Gesamtsystems, das sich aus verschiedenen Einzelmodellen der Fachfunktionen ohne wirklichen Gesamtkontext zusammensetzt, zu einem permanenten Gesamtmodell des Fahrzeuges zu kommen. Dieses Gesamtmodell bildet, sich an der Softwareindustrie orientierend, zu jedem Zeitpunkt 100 % des Gesamtsystems ab, das dann über die Entwicklungszeit an Granularität und Detaillierung zunimmt.

5) Kurze, schnelle Integrationszyklen

In vielen Unternehmen dauert die Ergebnisrückführung im Rahmen der Integration und Absicherung leider so lange, dass Prototypenstufen ausgelassen werden müssen und Erkenntnisse nicht umgehend in die Entwicklung zurückgeführt werden können. Hieraus resultieren Totzeiten, die vermieden werden sollten. Um den virtuellen, aber auch vor allem den physischen Integrationsprozess zu flexibilisieren, sind kurze, schnelle Integrationszyklen mit minimiertem zeitlichem Versatz, die den unterschiedlichen Entwicklungsgeschwindigkeiten Rechnung tragen, umzusetzen.

6) Flexible, spätestmögliche Integration

In der Produktentwicklung komplexer mechatronischer Systeme kommt es schon relativ früh, d.h. deutlich über ein Jahr vor Anlauf, zum „Freeze“ von Entwicklungsständen, um z. B. Werkzeug mit langen Laufzeiten zu beschaffen oder die Bestellung von komplexen Zulieferteilen auszulösen. Diese frühzeitige Festlegung von Entwicklungsumfängen erschwert die Sicherstellung der immer wichtiger werdenden Produktaktualität, indem die Flexibilität, auf späte Änderungen (Wettbewerb, Kunde etc.) zu reagieren, eingeschränkt wird. Deshalb sollte es für Umfänge, bei denen Aktualität unabdingbar ist, wie z.B. Infotainment, möglich sein, diese möglichst spät in das Gesamtprodukt zu integrieren. Hierzu müssen nicht nur prozessual, sondern auch auf Seiten der Produktarchitektur Vorhalte vorgesehen werden.

7) Schnittstellenoptimierte und elastische Produktarchitekturen

Die Möglichkeit, in unterschiedlichen Geschwindigkeiten entkoppelt voneinander zu entwickeln, ist stark von der Fähigkeit abhängig, die einzelnen Umfänge so vom Gesamtsystem zu entkoppeln, dass eine unabhängige Betrachtung möglich wird. Hierzu sind im Rahmen der Produktentwicklung schnittstellenoptimierte und elastische Architekturen zu entwickeln, die eine An- und Einbindung von Systemen unterschiedlichster Entwicklungsstände zu unterschiedlichen Zeitpunkten ermöglichen.

8) Asynchroner Reifeaufwuchs

Heutige Entwicklungsprozesse fokussieren stark darauf eine ähnlich hohe Produktreife über alle Systeme und Komponenten zu einem festgelegten Zeitpunkt zu erzeugen. Dieser einheitliche Reifeaufwuchs, der die Entwicklungsumfänge gleich taktet und die Flexibilität stark einschränkt, wird durch einen asynchronen bewusst definierten Reifeaufwuchs je Entwicklungsumfang ersetzt. An diesem Reifewuchs orientieren sich dann auch die Messung der Zielerreichung und das Reporting der einzelnen Umfänge.

Alle diese Prinzipien in einem Schritt zu implementieren, wird jedoch beinahe unmöglich sein. Vielmehr geht es darum, in einem ersten Schritt zu analysieren und dann zu entscheiden, wo die Entkopplung einzelner Entwicklungsumfänge vom Gesamtsystem den meisten Mehrwert entfaltet. Beantworten Sie sich z. B. die Frage, welche Entwicklungsumfänge besonders von mehr Produktaktualität profitieren würden oder wo die enge Wechselwirkung zwischen Komponente und Gesamtsystem keine Entkopplung zulässt. Wenn Sie diese Umfänge identifiziert haben, probieren Sie beispielsweise eine Vorintegration dieser Entwicklungsumfänge außerhalb des Gesamtsystemes einmal aus und versuchen Sie, dies auf weitere Umfänge zu übertragen.

Hinterfragen Sie auch die Entwicklungszeiten einzelner Systeme und Komponenten. Stehen diese in einem guten Verhältnis zu Ihrer Einsatzzeit im Lifecycle bis zur erneuten Überarbeitung oder Neuentwicklung? Überdenken Sie auch die aktuelle Festlegung Ihrer Prototypen und Ihre Absicherungsstrategie. Welche Umfänge der Produktentwicklung können Sie heute bereits virtuell abdecken und nicht wie bisher in Hardware?

Über diese und weitere Fragen können Sie sich einer Entkopplung Ihrer Entwicklung nähern und entscheiden, bei welchem der Prinzipien Sie ansetzen.

Zusammenfassung

Multiple Geschwindigkeiten im Produktentwicklungsprozess zu beherrschen, ist eine wesentliche Voraussetzung, um Reaktionsfähigkeit auf Marktänderungen zu ermöglichen und Kundenwünsche schnell und flexibel zu bedienen. Um eine Umsetzung wirklich erfolgreich zu gestalten, sind jedoch Voraussetzungen zu schaffen, wie beispielsweise

• die Fähigkeit, die Produktstruktur so aufzusetzen, dass die Abhängigkeiten minimal und die Freiheitsgrade maximal sind,
• die Fähigkeit nahezu in Echtzeit Entwicklungsfortschritte abzubilden oder
• eine Integrationslogik zu implementieren, die ein iteratives, auf Teilsystem- und Komponentenebene asynchrones Vorgehen unterstützen.

Unsere Beratungsprojekte haben gezeigt, dass die acht genannten Prinzipien gleichermaßen zu realisieren sind, um den „klassischen“ Produktentwicklungsprozess vollständig zu entkoppeln und auf multiple Geschwindigkeiten auszurichten.