Planung der Operationalisierung – Top Down

Beteiligte Rollen	Experten aus strategischen Abteilungen (Strategie, Marketing, Produktprogrammleiter)
Inputs	Liste relevanter dynamischer Einflussfaktoren APZ-Zahlen und Schalenmodell Produkt-Roadmap
Outputs	High-Level-Roadmap mit priorisierten Entwicklungsaktivitäten und Kapazitätsbetrachtung
Eingesetzte Methoden	Roadmapping↗

Ziel von Phase 2 ist die Planung der operativen Umsetzung der in der vorangegangenen Phase definierten Flexibilität in Form einer Roadmap↗. Das heißt vorauszuplanen, wann und in welchem Ausmaß auf antizipierte Änderungen mit neuen Lösungen (Features) reagiert werden soll. Zu diesem Zeitpunkt sind zwar noch keine Informationen über zukünftig mögliche Lösungskonzepte vorhanden, die Bestimmung der benötigten Flexibilität der Produkteigenschaften und -funktionen gibt jedoch Hinweise darauf, in welcher Frequenz eine neue Lösung erwartet wird. Aufbauend auf diesen Informationen wird eine sogenannte High-Level-Roadmap erstellt, die eine lösungsneutrale Grobstruktur von zukünftigen Entwicklungsaktivitäten darstellt. Diese wird in enger Abstimmung mit der Entwicklungsabteilung auf Basis der Modul-Roadmap (siehe hier↗) kontinuierlich durch konkrete Entwicklungsaktivitäten verfeinert.

High-Level-Roadmap

Die Definition zukünftig geforderter Flexibilität in Phase 1 ermöglicht es über die Lebensdauer der Plattform Entwicklungsaktivitäten zu planen. In einer High- Level-Roadmap wird ein Zeitplan definiert, wann welche Eigenschaft oder Funktion eines Produktes durch eine neue technische Lösung (Feature) adressiert werden soll. Dabei wird nicht festgelegt, um welche konkrete Lösung es sich handeln wird, sondern nur, dass eine neue Lösung entwickelt werden soll.

Die primäre Betrachtungsdimension bei der Erstellung der High-Level-Roadmap ist die Zeit. Es können drei grundsätzliche Treiber unterschieden werden, die Zeitimplikationen zur Terminierung der nötigen Entwicklungsaktivitäten liefern.

Betrachtung der Änderungsfrequenz für Eigenschaften und Funktionen

Die Ermittlung der Änderungsprioritätszahlen (APZ↗) in Phase 1 (hier↗) zeigt, dass für verschiedene Produkteigenschaften und -funktionen unterschiedlich häufig neue Lösungen vorgesehen werden. Das ist beispielsweise auf eine unterschiedlich hohe Konsumentensichtbarkeit der Funktionen, auf die unterschiedliche Dynamik der zugrundeliegenden Trends oder auch auf strategische oder wettbewerbsbezogene Gründe zurückzuführen. Basierend auf zwei Informationsbestandteilen lässt sich bereits eine erste generische High-Level- Roadmap erstellen (vgl. Abb. 4.5): (1) Frequenz der Einführungen neuer Feature (vgl. Schalenmodell hier↗) und (2) Kenntnis, wann das letzte Mal oder das nächste Mal (bereits festgelegt) ein entsprechendes Feature bereitgestellt wurde bzw. sein wird.

Abb. 4.5 Generische High-Level-Roadmap für Feature-Entwicklungen

Betrachtung definierter Zeitpunkte

Die generische Roadmap kann durch die Betrachtung bekannter, definierter Zeitpunkte, zu denen die Bereitstellung neuer Features sinnvoll ist, optimiert werden. Dabei kann es sich um extern definierte Zeitpunkte handeln (z. B. Messen), zu denen neue Lösungen präsentiert werden. Auch Zeitpunkte, zu denen rechtliche Änderungen neue Lösungen erzwingen, zeitlich bekannte Wettbewerberaktivitäten oder auch eine terminierte Trenddynamik, die die Reaktion zu einem definierten Zeitpunkt nahelegen, sind zu betrachten. Auch intern festgelegte Zeitpunkte aus der Marketingstrategie oder anderen übergeordneten Überlegungen können Zeitpunkte für die Bereitstellung neuer Feature vorgeben. Besonders zu berücksichtigen ist dabei die Planung der vorgesehenen Produkteinführungen und Weiterentwicklungen in der Produktprogrammstrategie, welche aus einer vorhandenen Produkt-Roadmap abgelesen werden kann. Dafür ist die in Abb. 4.6 dargestellte Tabelle hilfreich. Ist eine Funktion für ein bestimmtes Produkt besonders relevant, so wird aus dem Termin der geplanten Produktweiterentwicklung (im Beispiel April 2020, Evolution von Produkt 2) ein Termin abgeleitet, wann die Entwicklung eines Features abgeschlossen sein muss, um im neuen Produkt angeboten zu werden. Der ursprüngliche Termin aus der Feature-Frequenz (Mai 2020, Feature 4 der Funktion 1) wird dann entsprechend angepasst.

Abb. 4.6 Tabelle zur Verknüpfung zukünftig vorzusehender Feature mit Informationen aus der Produktprogrammstrategie

Relative zeitliche Abstimmung der Feature-Entwicklungen

Die bisherige Roadmap stellt eine idealisierte Auflistung dar, wann ein neues Feature vorgesehen werden sollte. Da von begrenzten internen Kapazitäten ausgegangen werden muss, ist es notwendig die Feature-Entwicklungen aufeinander abzustimmen und zu priorisieren. Ausgehend von der groben Abschätzung des Aufwands zur Realisierung neuer Features erfolgt eine Kapazitätsbetrachtung. Die Produkt-Roadmap wird von den strategischen Abteilungen (Marketing und Strategie) erstellt. Hier fließen Betrachtungen unterschiedlicher Kundensegmente mit ein. Die nötige Priorisierung erfolgt dann hinsichtlich der externen und internen Relevanz eines Features.

Die externe Relevanz beschreibt, wie sehr von den Konsumenten ein neues Feature zur Realisierung der jeweiligen Funktion gewünscht ist. Für diese Einschätzung kann der Wert (K) Änderungen für Konsumenten und Wettbewerbsfähigkeit aus der APZ-Methode herangezogen werden.

Die interne Relevanz eines Features beschreibt, wie gut es zum Produktportfolio und den übergeordneten strategischen und marketingseitigen Überlegungen des Unternehmens passt. Dabei kann angenommen werden, dass ein Feature aus interner Sicht besonders relevant ist, wenn es als wichtiger Bestandteil in vielen und umsatzrelevanten Produkten vorgesehen werden soll. Zusätzlich zeigt der Abgleich von Features und Produkten, wie wichtig einzelne Feature für die verschiedenen Produktfamilien sind (vgl. Einteilung in Lead Product, Key Feature und Nice to have in Abb. 4.6). Durch die Quantifizierung der Einteilung und unter Berücksichtigung unterschiedlicher relativer Wichtigkeiten verschiedener Produkte und Evolutionsstufen lässt sich eine Gesamtbewertung ableiten. Diese spiegelt die interne Relevanz der verschiedenen Features wider. Die resultierende Gesamtbewertung der internen Relevanz der Feature wird (normiert und gegebenenfalls gewichtet) mit der Bewertung der externen Relevanz der jeweils zugrundeliegenden Eigenschaften und Funktionen multipliziert. Auf diese Weise wird die Gesamtrelevanzbewertung gebildet, die zur Priorisierung benötigt wird.

Im Anschluss werden die einzelnen zu planenden Features zur Erfüllung der Anforderungen gemäß ihrer momentanen zeitlichen Planung sowie der Relevanz- und Aufwandsbewertung aufgetragen (vgl. Abb. 4.7). Die zu erwartenden Aufwände in Mannmonaten werden von Experten abgeschätzt.

Abb. 4.7 Tabelle zur Priorisierung und zeitlichen Planung von Feature- Entwicklungen in der Zukunft

Parallel dazu kann der erwartete Ressourcenbedarf, beispielsweise wie in Abb. 4.8, dargestellt werden. Durch Anpassung der Start- und Endpunkte der Entwicklung und durch Priorisierung der Feature-Entwicklungsprojekte kann dann die Auslastung der Entwicklung optimiert werden.

Abb. 4.8 Diagramm zur Kapazitätsbetrachtung zukünftiger Feature- Entwicklungen

Kontinuierliches Roadmapping

Für kleinere Planungshorizonte (z. B. ein Jahr) wird die lösungsneutrale High- Level-Roadmap regelmäßig detailliert. Für vorgesehene neue Feature wird dabei die technische Implementierung einer neuen Lösung festgelegt. Die damit verbundenen Entwicklungsaktivitäten werden auf Basis der Produkt-Roadmap in Produktentwicklungsprojekten geplant. Hier steht die Koordination von Vorentwicklung der Features (prinzipielle Lösungsbereitstellung) und Serienentwicklung (Integration neuer Features in ein Produkt) im Vordergrund. Die detaillierte Planung der lösungsspezifischen Features sowie des Entwicklungsaufwands erfolgt in der Modul-Roadmap aus der Bottom-Up-Perspektive (siehe hier↗).

Planung der Operationalisierung - Bottom Up

Beteiligte Rollen	Experten aus strategischen (Planung) und technischen Abteilungen (Technik, Entwicklung)
Inputs	Architekturanalysen, Bauteil- und Merkmalsflexibilität High-Level-Roadmap, konkrete Features
Outputs	Zyklengerechte und dokumentierte Modul- und Plattformarchitektur Modul-Roadmap inkl. der notwendigen Modulüberarbeitungen /-neuentwicklungen sowie der Auslastung der Entwicklungsteams
Eingesetzte Methoden	Portfolio Roadmapping↗

In der zweiten Phase werden im Bottom-Up-Ansatz die Analyseergebnisse aus der ersten Phase genutzt, um eine zyklengerechte modulare Produktplattform unter Berücksichtigung der erwarteten Änderungen zu gestalten. Die erzeugte modulare Produktplattform wird mittels Architekturregeln und -standards dokumentiert. Dadurch wird die Entwicklung befähigt, diese Plattformarchitektur zu entwickeln.

Weiterhin wird – basierend auf der Änderungshäufigkeit der anzubietenden Features (vgl. Top-Down-Ansatz hier↗) – eine Modul-Roadmap entwickelt. Diese stellt die mittelfristige Planung der zukünftigen Entwicklungsaktivitäten während der Nutzungsphase der Produktplattform auf Lösungsebene dar und berücksichtigt dabei die vorhandene Entwicklungskapazität.

Entwicklung der zyklenrobusten Modul- und Plattformarchitektur

Im diesem Schritt werden die Ergebnisse bezüglich der aktuellen Flexibilität und der zukünftig benötigten Flexibilität genutzt, um eine zyklenrobuste Architektur zu erstellen. Das heißt, dass die Bauteile in flexible Module oder Plattformmodulen gruppiert werden. Der analysierte Ist-Stand wird in den definierten Soll-Stand überführt.

Um ein Bauteil flexibel in einer Produktarchitektur einzubetten und somit viele effiziente Änderungen im Produktlebenszyklus zu realisieren, muss die aktuelle Änderungsfähigkeit in Form der Vernetzung des Bauteils betrachtet werden. Je weniger Schnittstellen ein Bauteil bereits besitzt, desto einfacher ist es eine Flexibilität zu realisieren. Hochvernetzte Bauteile sollten aus einer strukturellen Perspektive eher robust gehalten werden, da eine Änderung eines solchen Bauteils viele andere Bauteile ändern kann und somit die Änderung eine hohe Auswirkung im Gesamtsystem erzeugt. Um die Bauteile bezüglich ihrer Vernetzung und Änderungsauswirkung zu charakterisieren, wird die Kritikalität der Elemente aus der physischen und funktionalen Vernetzung berechnet. Die Kritikalität spiegelt die Rolle eines Elements in einer Struktur basierend auf der Anzahl ihrer Ein- und Ausgänge wider. Je höher die Kritikalität, desto sensitiver ist das Element (in dieser Betrachtung das Bauteil) gegenüber Änderungen und sollte daher robust gehalten werden, zum Beispiel durch Standardisierung.

Für die Überführung der Ist-Architektur in eine zyklenrobuste Soll-Architektur werden die Kritikalität und die Dynamik der Bauteile in einem Kritikalitäts- Dynamik-Portfolio gegenübergestellt (siehe Abb. 4.17). Bauteile mit hoher Kritikalität und zeitlicher Robustheit sollten in die Plattform integriert werden, wohingegen wenig vernetze und sich oft ändernde Bauteile für eine Implementierung in einem flexiblen Modul realisiert werden sollten.

Abb. 4.17 Kritikalitäts-Dynamik-Portfolio

Das Portfolio ist in sechs Sektoren unterteilt (vgl. Abb. 4.17). Für jedes Feld sind Maßnahmen für die Bauteile und ihre Schnittstellen definiert, um eine zyklenrobuste Plattform- und Modularchitektur zu erzeugen:

Sektor I: Bauteile in diesem Feld ändern sich während des geplanten Lebenszyklus sehr selten bis gar nicht und besitzen eine hohe Kritikalität. Deshalb werden diese Bauteile standardisiert und in die Plattform aufgenommen.
Sektor II: Diese Bauteile ändern sich mäßig häufig, sind aber stark in die Struktur eingebunden. Wegen der hohen Kritikalität sollten sie in die Plattform integriert werden. Die häufigen Änderungen können zum Beispiel durch Überdimensionierung umgangen werden.
Sektor III: Bauteile in diesem Sektor ändern sich sehr oft und besitzen eine hohe Kritikalität. Um die häufigen Änderungen mit vertretbarem Aufwand zu bewerkstelligen, sollten diese Bauteile in Module implementiert werden. So können die Änderungen in einem Modul gekapselt werden. Um die Kritikalität und somit die Änderungsauswirkung zu verringern, sollten die Schnittstellen des entsprechenden Bauteils standardisiert werden, so dass sich eine Änderung am Bauteil nicht fortpflanzen kann.
Sektor IV: Diese Bauteile werden wegen ihrer geringen Kritikalität und hohen Änderungsdynamik in Modulen umgesetzt.
Sektor V: Die Bauteile in diesem Sektor sollten ebenfalls Modulen zugeordnet werden. Sie besitzen eine geringe Kritikalität und ändern sich mehrmals im Laufe des Produktlebenszyklus. Sie können als produktdifferenzierende oder innovative Elemente des Produkts dienen.
Sektor VI: Da diese Bauteile selten bis gar nicht geändert werden müssen, werden sie in die Plattform integriert. Dies kann beispielsweise durch Standardisierung und einer produktübergreifenden Verwendung des Bauteils realisiert werden.

Diese Handlungsempfehlungen befähigen die Entwicklungsabteilung, die aktuelle Plattformarchitektur so zu modifizieren, dass die benötigte Flexibilität bei gleichzeitiger Standardisierung realisiert wird.

Um die zyklenrobuste Gestaltung der Plattformarchitektur auch während des Produktlebenszyklus einzuhalten, müssen Architekturregeln definiert werden. Diese umfassen die Freiheitsgrade zur Pflege und geplanten Überarbeitung der flexiblen Module sowie Änderungsverbote, zum Beispiel für standardisierte Bauteile und Schnittstellen. In der Dokumentation sollten auch die Schnittstellen zwischen den Modulen festgehalten werden. Dafür wird das analog dem im ersten Schritt des Bottom-Up-Vorgehens erzeugte Modulkonzept, welches die Bauteilabhängigkeiten sowie organisatorischen Zuständigkeiten enthält, eingesetzt . Jedes Entwicklungsteam kann so vor der Implementierung einer geplanten Änderung mit Hilfe dieses Modells eine Auswirkungsanalyse durchführen. So werden mögliche Auswirkungen auf andere Module identifiziert, die entweder durch geschickte Gestaltung vermieden oder proaktiv an das betroffene Modulteam kommuniziert werden. Neben den definierten Architekturregeln und möglichen Kommunikationspfaden können noch weitere Moduleigenschaften, wie z. B. die Dynamik der enthaltenen Bauteile, deren aktuelle Varianz, die definierten Architekturregeln sowie die vorhandenen Freiheitsgrade dokumentiert und den jeweiligen Entwicklungsteams zugänglich gemacht werden (siehe Abb. 4.18).

Abb. 4.18 Exemplarischer Modulsteckbrief

Entwicklung von Modul-Roadmaps

Basierend auf der High Level Feature-Roadmap (siehe hier↗), deren zeitliche Planung auf den dynamischen Einflussfaktoren und einer Marktsicht beruht, wird die Modul-Roadmap terminiert. Die Modul-Roadmap stellt die zeitliche Planung der Modul-Entwicklung dar (siehe Abb. 4.19 oben). Dies umfasst pro Modul die Dauer der Überarbeitung und der Pflege der Bauteile, wodurch neue Modulausprägungen für neue Varianten erzeugt werden. Außerdem können in einem Modul auch neue Bauteile hinzukommen, um neue Modulvarianten zu entwickeln, zum Beispiel bei der Einführung eines neuen Features.

Zur realistischen Durchführung der Modulentwicklungen und -überarbeitungen der Modul-Roadmap ist ein Abgleich dieser Planung mit den vorhandenen Entwicklungskapazitäten notwendig. Dazu wird pro Entwicklung die Dauer und somit die Auslastung pro Modulteam bestimmt. Dies geschieht über eine aktivitätenbasierte Bestimmung des Entwicklungsaufwands unter Berücksichtigung möglicher Änderungsauswirkungen (eingesetzte Methode und Toolunterstützung siehe hier↗). Dadurch kann die Auslastung jedes Modulteams pro Zeitperiode bestimmt werden. Basierend auf dem Ergebnis der Auslastungsberechnung entsteht ein Informationsrückfluss der Modul- zur High-Level-Roadmap, um diese gegebenenfalls unter dem Auslastungsaspekt anzupassen. Die abstraktere Planung der High-Level-Roadmap wird entweder bestätigt oder in der Reihenfolge oder Priorisierung der zu entwickelnden Features umgestaltet.

Das Ziel dieser Planung ist es, durch die Taktung und Synchronisation der Modul-Roadmap das Überschreiten der Kapazitätsgrenze zu vermeiden sowie Schwankungen der Auslastung von Modulteams zu minimieren (siehe Abb. 4.19 unten). Ist keine auslastungsgerechte Terminierung möglich, erfolgt eine Synchronisierung mit der High-Level-Roadmap.

Abb. 4.19 Synchronisierung der Modul-Roadmap und der Entwicklungskapazitäten

Lebenszyklus-Management