Kein Produkt entsteht aus dem Nichts: Was das PGE-Modell über technische Entscheidungen lehrt

Es war ein Prüfstandsprojekt bei der Robert Bosch GmbH. Das bestehende Kalibrierungssystem für Dieseleinspritzpumpen sollte modernisiert werden: neue Hardware, neue Software, erweiterter Funktionsumfang. Was zunächst wie eine klare technische Aufgabe wirkte, entpuppte sich als komplexes Geflecht aus Abhängigkeiten – von Vorgängersystemen, von bestehenden Messverfahren, von impliziten Annahmen, die niemand mehr explizit kannte.

Die Bachelorarbeit, die ich damals im Kontext dieses Projekts schrieb, beschäftigte sich mit dem Modell der Produktgenerationsentwicklung (PGE) nach Albert Albers. Was ich dort gelernt habe, hat meine Art, über technische Entwicklung nachzudenken, nachhaltig verändert.

Was das PGE-Modell sagt – und warum es wichtig ist

Das Modell der Produktgenerationsentwicklung stellt eine These auf, die einfach klingt, aber weitreichende Konsequenzen hat: Jedes neue Produkt ist eine Weiterentwicklung mindestens eines Referenzsystems. Es entsteht nicht aus dem Nichts – es baut immer auf bestehenden Lösungen, Prinzipien und Gestaltungen auf.

Diese Weiterentwicklung geschieht über drei Variationsarten:

• Übernahmevariationen: Elemente des Referenzsystems werden unverändert übernommen
• Prinzipvariationen: Das Wirkprinzip eines Elements wird grundlegend verändert
• Gestaltsvariationen: Die Gestalt wird angepasst, das Prinzip bleibt

Das Problem in der Praxis: Implizite Referenzsysteme

Das PGE-Modell beschreibt nicht nur, wie Produkte entstehen – es zeigt auch, wo Entwicklungsprojekte systematisch schiefgehen.

In vielen Teams gibt es ein implizites Referenzsystem: das Vorgängerprodukt, das alte System, den bestehenden Prozess. Jeder im Team weiß intuitiv davon. Aber es wird selten explizit gemacht. Das bedeutet: Übernahmevariationen werden nicht als solche erkannt, Prinzipvariationen werden unterschätzt, und Abhängigkeiten bleiben unsichtbar – bis sie in der Integrations- oder Validierungsphase als Problem auftauchen.

Was das für technische Entscheidungen bedeutet

Das PGE-Modell ist kein akademisches Konzept – es ist ein praktisches Werkzeug für drei konkrete Situationen:

Beim Start eines Entwicklungsprojekts: Was ist unser Referenzsystem? Welche Elemente übernehmen wir – und welche verändern wir fundamental? Wo liegen die Prinzipvariationen, und welcher Validierungsaufwand entsteht daraus?

Bei Engineering Changes: Jede Änderung in einem bestehenden System ist eine Variation. Die Frage ist nicht nur „Was ändern wir?" – sondern „Was ist das Referenzsystem dieser Änderung, und welche Abhängigkeiten trägt sie in sich?"

Bei technischen Reviews: Wenn Simulationsergebnisse und Messdaten sich widersprechen, liegt die Ursache häufig in nicht explizit gemachten Variationen. Das Modell setzt Annahmen voraus, die aus dem Referenzsystem stammen – und die in der realen Neuentwicklung nicht mehr gelten.

Warum Entwicklungsteams das selten explizit machen

Die Antwort ist simpel: Zeitdruck. Das Referenzsystem explizit zu beschreiben, die Variationsarten zu kartieren, Abhängigkeiten sichtbar zu machen – das kostet Zeit zu Beginn eines Projekts, wenn der Druck am größten ist.

Die Konsequenz dieser Investition zeigt sich erst später – in der Integrationsphase, im Validierungsprozess, bei der Serienfreigabe. Projekte, die diese Arbeit frühzeitig leisten, treffen weniger Überraschungen. Projekte, die sie überspringen, erkaufen sich Geschwindigkeit am Anfang mit Aufwand am Ende.

Das ist kein Vorwurf an die Teams. Es ist eine strukturelle Realität. Und es ist einer der Gründe, warum ein externer methodischer Blick am Anfang eines Projekts – wenn er die richtigen Fragen stellt – mehr bewirkt als jeder Review am Ende.

Drei Fragen, die jedes Entwicklungsteam stellen sollte

• Was ist unser explizites Referenzsystem – und was nehmen wir implizit von ihm mit?
• Welche Elemente unseres Konzepts sind Prinzipvariationen – und haben wir den Validierungsaufwand dafür eingeplant?
• Wo könnten nicht kommunizierte Variationen später als Widerspruch zwischen Simulation und Messung auftauchen?

Diese drei Fragen lassen sich in einem halbtägigen Workshop mit dem Entwicklungsteam beantworten. Der Aufwand ist überschaubar. Die Wirkung auf die Qualität späterer Entscheidungen ist erheblich.