Interaktiver Entscheidungs- und Pilotpfad

Jede Stufe braucht eine Entscheidung, ein Ergebnis und einen Realitätscheck.

Wählen Sie eine Stufe. Die Darstellung zeigt, was fachlich entschieden, als Ergebnis belastbar beschrieben und vor dem Übergang zur nächsten Stufe geprüft werden muss.

01Markt, Portfolio & Scope 02Funktionen & Variantentreiber 03Architektur, Module & Schnittstellen 04Produktlogik & Prozessklassen 05Simulation, Pilot & Governance

Markt, Portfolio und Scope

Stufe 01 von 05

Entscheidung

Welche Märkte, Produktfamilien, Leistungsbereiche und Grenzen soll das künftige Programm tragen?

Belastbares Ergebnis

Ein verbindlicher Scope mit Leistungsversprechen, Differenzierung und bewusst ausgeschlossenen Angeboten.

Realitätscheck

Erklärt der Scope reale Kundenanfragen – und kann die Organisation auch begründet Nein sagen?

ProduktProzessDatenSystemeOrganisation

Keine starre Wasserfalllogik: Erkenntnisse wirken auf frühere Entscheidungen zurück. Dennoch bleibt die fachliche Richtung erhalten: erst Scope und Funktion, dann Architektur, Module und digitale Ausführung.

1. Warum Modularisierung meist an der falschen Stelle beginnt

Modularisierungsvorhaben beginnen fast immer dort, wo etwas Greifbares vorliegt. In der Entwicklung sind das die vorhandenen Konstruktionsdaten und Stücklisten, in der Beschaffung der Teilebestand, im Produktmanagement die Liste der aktiven Ausführungen. Der erste Arbeitsschritt besteht dann darin, diesen Bestand zu ordnen: Gleichteile zu suchen, Ausführungen zu gruppieren, Wiederholteile zu markieren, Module zu benennen. Der Zugang ist verständlich, denn er ist planbar, messbar und liefert nach wenigen Wochen ein vorzeigbares Zwischenergebnis. Er hat nur einen Nachteil: Er beginnt am Ende. Ebenso häufig beginnt ein Vorhaben mit der Einführung eines Systems, weil dort ein Budget vorhanden ist und ein Termin existiert. Auch das ist ein Anfang am Ende, nur mit größerer Wirkung.

Alles, was in diesen Daten steht, ist bereits das Ergebnis von Entscheidungen. Welche Produktfamilien geführt werden, welches Leistungsversprechen sie tragen, welche Vielfalt angeboten wird und welche Funktionen dafür bereitzustellen sind, war entschieden, bevor die erste Zeichnung entstand. Eine Analyse des Bestands kann diese Entscheidungen sichtbar machen, aber sie kann sie nicht ersetzen. Wird sie dennoch zum Ausgangspunkt gemacht, entsteht eine Ordnung, die die Vergangenheit sauber abbildet und die Zukunft nicht vorbereitet. Der Aufwand ist erheblich, das Ergebnis technisch korrekt und wirtschaftlich folgenlos. Erkennbar ist dieser Verlauf daran, dass am Ende eines solchen Vorhabens jede Frage nach dem künftigen Produktprogramm unverändert offen ist.

Modularisierung ist deshalb keine Konstruktionsmethode. Sie ist die Übersetzung einer Unternehmensstrategie in eine Produktlogik, die über Jahre beherrschbar bleibt. Module stehen dabei nicht am Anfang, sondern sind ein Ergebnis, das sich aus vorangegangenen Festlegungen ergibt. Der Weg dorthin ist eine Folge von Entscheidungen, von denen jede die vorherige voraussetzt und keine vorgezogen werden kann, ohne die folgenden zu beschädigen. Dieser Beitrag beschreibt diese Folge, so wie sie sich in industriellen Produktprogrammen bewährt hat. Sie beginnt am Markt und endet in der digitalen Abbildung, und sie verläuft in dieser Richtung, weil jede Umkehr eine Entscheidung an eine Stelle verlagert, die sie nicht verantworten kann.

Einordnung auf einen Blick

Entscheidungsstufe	Leitfrage	Ergebnis
Markt und Produktstrategie	Welche Produktfamilien und welche Vielfalt sollen künftig getragen werden?	Scope und Leistungsversprechen
Funktionale Gliederung	Welche Funktionen sind stabil, welche variieren und warum?	Funktionale Ordnung
Architektur und Schnittstellen	Wo liegen stabile Bereiche und kontrollierte Variationsstellen?	Architekturschnitt und Schnittstellenregeln
Module und Granularität	Welche Funktionen gehören zusammen und auf welcher Ebene?	Module mit wirtschaftlicher Größe
Produktlogik und digitale Abbildung	Wie werden Merkmale, Regeln, Strukturen und Prozessklassen konsistent verbunden?	Steuerbares Produktmodell

2. Der Ausgangspunkt: Produkt-Markt-Strategie

Am Anfang steht die Frage, für welche Märkte und Kundensegmente ein Unternehmen künftig antritt, welche Produktfamilien es dafür führt, welches Leistungsversprechen jede Familie trägt und worin es sich vom Wettbewerb unterscheiden will. Aus diesen Antworten ergibt sich der Scope, also der Umfang dessen, was das Produktprogramm abdecken soll: die Leistungsbereiche, die bedienten Anwendungen, die Regionen mit ihren jeweiligen Anforderungen und die Grenzen, jenseits derer bewusst nicht angeboten wird. Ohne diese Festlegung fehlt jeder späteren Strukturentscheidung der Maßstab, denn eine Struktur lässt sich nur daran beurteilen, wofür sie tragen soll. Der Scope ist damit keine Marktbeschreibung, sondern eine Selbstverpflichtung: Er benennt ebenso, was künftig nicht mehr angeboten wird. Ein Scope, der alles offenlässt, ist keine Strategie, sondern die Beschreibung des heutigen Zustands.

Dem Scope steht der Scale gegenüber, also die Frage, wie dieser Umfang wirtschaftlich getragen wird. Er entsteht aus Wiederverwendung: aus der Absicht, denselben Anteil an Lösung in möglichst vielen Produkten, Familien und Generationen einzusetzen. Beide Größen sind gegenläufig und müssen gemeinsam entschieden werden. Ein weiter Scope ohne Scale erzeugt ein Programm, das der Markt schätzt und das Unternehmen nicht bezahlen kann. Ein hoher Scale ohne definierten Scope erzeugt ein effizientes Programm, das an den Anforderungen vorbeigeht. Die Aufgabe besteht nicht darin, eine der beiden Größen zu maximieren, sondern ihr Verhältnis bewusst festzulegen. Diese Abwägung ist der Kern der Produktstrategie und lässt sich weder an die Entwicklung noch an den Vertrieb allein übertragen, weil beide jeweils nur eine der beiden Seiten verantworten.

Bezugsgröße dieser Festlegung ist die Produktfamilie, nicht das Gesamtunternehmen und nicht das einzelne Erzeugnis. Wie Familien voneinander abgegrenzt werden, welche Anwendungen sie bedienen und wo eine Familie endet und die nächste beginnt, ist deshalb selbst Gegenstand der Entscheidung und nicht Ergebnis der vorhandenen Nummernsystematik. Wer an dieser Stelle unscharf bleibt, kann später keinen Architekturschnitt begründen, weil die Frage, wofür eine Struktur tragen soll, unbeantwortet ist. Der gesamte weitere Prozess ruht auf dieser ersten Festlegung. Sie ist zugleich die Stelle, an der ein Unternehmen die angebotene Vielfalt unmittelbar festlegt; alles Weitere gestaltet nur noch, wie diese Vielfalt erzeugt wird.

3. Von Produkten zu Funktionen

Der zweite Schritt löst sich bewusst von den vorhandenen Erzeugnissen. Gefragt wird nicht, aus welchen Baugruppen die heutigen Produkte bestehen, sondern welche Funktionen ein Produktprogramm erfüllen muss, um das zuvor beschriebene Leistungsversprechen einzulösen. Eine Funktion ist dabei eine Wirkung, die das Produkt erbringt, unabhängig davon, mit welcher Lösung sie heute erzeugt wird. Zwei Erzeugnisse, die technisch wenig gemeinsam haben, können funktional weitgehend übereinstimmen, und genau diese Übereinstimmung bleibt verborgen, solange nur der Bestand betrachtet wird. Diese Unterscheidung ist der eigentliche Hebel des gesamten Vorgehens, denn sie trennt die dauerhafte Anforderung von der historisch gewählten Antwort darauf. In der Praxis ist dieser Schritt der ungewohnteste, weil Entwicklung und Vertrieb gewohnt sind, in Erzeugnissen und Ausführungen zu denken, und weil eine Funktion sich nicht zeichnen lässt.

Die so erfassten Funktionen werden anschließend nach ihrem Verhalten unterschieden. Ein Teil ist über Jahre stabil und für alle Produkte gleich. Ein zweiter Teil variiert kundenseitig, weil Anwendungen, Leistungspunkte oder Einbaubedingungen unterschiedliche Ausprägungen verlangen. Ein dritter Teil entwickelt sich technologisch weiter und wird in der Lebensdauer des Programms mehrfach erneuert. Ein vierter Teil schließlich unterscheidet die Produktfamilien voneinander und trägt damit die Differenzierung im Markt. Diese vier Kategorien sind keine akademische Einteilung, sondern die Grundlage jeder späteren Entscheidung über Stabilität und Beweglichkeit. Sie beantworten die Frage, welche Anteile eines Programms Investitionen binden dürfen und welche beweglich bleiben müssen, und sie tun das unabhängig davon, wie diese Anteile heute konstruiert sind.

Das Ergebnis dieses Schritts ist die funktionale Gliederung, also die erste fachliche Ordnung des Produktprogramms. Sie enthält weder Bauteile noch Baugruppen, weder Zeichnungen noch Nummern. Sie beschreibt, was ein Programm leistet und wo sich diese Leistung unterscheidet. Genau deshalb ist sie tragfähiger als jede Zerlegung des Bestands: Sie beschreibt Anforderungen, die auch dann noch gelten, wenn die heutigen Lösungen längst ersetzt sind. Damit ist sie zugleich die einzige Grundlage, auf der sich mehrere Produktfamilien überhaupt vergleichen lassen, denn Funktionen sind über Familiengrenzen hinweg vergleichbar, gewachsene Konstruktionen sind es nicht.

4. Der erste Architekturschnitt

Erst an dieser Stelle beginnt Modularisierung im eigentlichen Sinn. Der Architekturschnitt legt fest, welche Bereiche des Programms dauerhaft stabil bleiben, an welchen Stellen Unterschiede zwischen Produkten entstehen dürfen, wie die entstehenden Einheiten über Schnittstellen verbunden sind und wer für welchen Bereich entscheidet. Die Stabilitätsbereiche binden Investitionen und schaffen die Voraussetzung für Wiederverwendung; sie entsprechen den Funktionen, die als dauerhaft stabil eingeordnet wurden. Die Variationsstellen nehmen genau die Vielfalt auf, die der zuvor bestimmte Scope verlangt, und keine weitere. In dieser Zuordnung liegt die eigentliche Übersetzungsleistung: Eine Marktentscheidung wird zu einer technischen Festlegung, die sich prüfen und einhalten lässt.

Die Schnittstellen sind dabei der eigentliche Gegenstand der Arbeit. Sie umfassen die mechanische Verbindung, die Übergabe von Energie und Signalen, die zugesicherten Eigenschaften und die Bedingungen ihrer Gültigkeit. Solange sie eingehalten werden, kann jede Einheit dahinter unabhängig weiterentwickelt, ersetzt oder in einer anderen Familie eingesetzt werden. Hinzu kommen die Verantwortlichkeiten: Für jeden Bereich muss festgelegt sein, wer ihn ändern darf und wer bei einer Änderung zu beteiligen ist. Eine Architektur ohne zugewiesene Verantwortung ist eine Beschreibung, keine Regel. Zu jeder Schnittstelle gehört daher eine benannte Stelle, die über ihre Veränderung entscheidet, und ein Verfahren, nach dem eine Abweichung beantragt und bewertet wird.

Die Produktarchitektur bestimmt damit die Regeln, nicht die Module. Das ist mehr als eine Formulierung, denn es entscheidet über die Reihenfolge der Arbeit. Wer zuerst Module benennt und danach ihre Verbindungen sucht, erhält Schnittstellen, die aus den gefundenen Modulen folgen, und damit aus der Vergangenheit. Wer zuerst die Regeln festlegt, erhält Module, die diesen Regeln genügen. Fehler an dieser Stelle sind die teuersten des gesamten Prozesses, weil sie sich über die gesamte Lebensdauer des Programms in jeder Änderung wiederholen. Sie lassen sich später auch nicht durch Sorgfalt in den folgenden Schritten ausgleichen, denn alle folgenden Schritte setzen auf ihnen auf.

Die Produktarchitektur bestimmt die Regeln, nicht die Module.

5. Modulbildung

Die Modulbildung fasst zusammen, was funktional zusammengehört und gemeinsam variiert. Ausgangspunkt sind die Funktionen und ihr Verhalten, nicht die vorhandenen Bauteile. Ein Modul entsteht dort, wo mehrere Funktionen dieselbe Stabilität besitzen, denselben Änderungsrhythmus haben und über eine gemeinsame Schnittstelle angebunden werden können. Erst danach wird geprüft, welche vorhandenen Lösungen sich dafür eignen und welche neu entstehen müssen. Damit fällt zugleich die Entscheidung, welche Vielfalt innerhalb eines Moduls aufgenommen wird und welche zwischen den Modulen entsteht. Beides ist wirtschaftlich sehr unterschiedlich, denn Vielfalt innerhalb eines Moduls bleibt lokal, Vielfalt zwischen Modulen wirkt auf das gesamte Programm. Aus diesem Grund ist die Modulbildung keine Zerlegungsübung, sondern die Entscheidung darüber, wo künftige Unterschiede wirtschaftlich getragen werden. Ein Modulschnitt ist erst dann industriell tragfähig, wenn er nicht nur funktional und konstruktiv überzeugt, sondern auch zu Beschaffung, Eigenfertigung, Montage, Prüfung und Wertschöpfungstiefe passt. Die Frage lautet deshalb nicht nur, welche Funktionen gemeinsam variieren, sondern auch, an welcher Stelle der Wertschöpfung eine Variante wirtschaftlich entstehen soll. Dieses Produkt-Prozess-Engineering verbindet die Produktarchitektur mit dem späteren Fertigungs- und Montageprinzip.

Aus dem Verhalten der Funktionen lassen sich typische Rollen von Modulen ableiten. Standardmodule tragen die stabilen Anteile und sind der eigentliche Ort der Wiederverwendung; für sie gelten eine ausdrückliche Gleichteilestrategie und der bewusste Carry-over in die nächste Generation. Variantenmodule nehmen die marktseitig geforderten Unterschiede auf und sind darauf ausgelegt, in mehreren Ausprägungen zu bestehen. Innovationsmodule schließlich sind absichtlich beweglich gehalten, weil in ihnen die technologische Weiterentwicklung stattfindet; ihre Schnittstellen sind deshalb besonders sorgfältig zu stabilisieren. Erst diese Unterscheidung erlaubt es, ein Produktprogramm über Jahre weiterzuentwickeln, ohne es bei jeder technologischen Veränderung als Ganzes anzufassen.

Das Ziel ist nicht maximale Standardisierung, sondern wirtschaftliche Differenzierung. Ein Programm, in dem alles vereinheitlicht wird, verliert die Unterschiede, für die der Markt zahlt, und erkauft die Gleichheit häufig mit Überdimensionierung. Ein Programm, das überall Unterschiede zulässt, trägt sie in jeder Einheit mit. Die erreichte Kommunalität, also der Anteil gemeinsam genutzter Funktionen, Lösungen, Schnittstellen und gegebenenfalls Gleichteile, ist deshalb kein Ziel, das isoliert vorgegeben wird, sondern ein Ergebnis, das sich aus der Zuordnung dieser Rollen einstellt und im Nachhinein gemessen werden kann. Wird sie umgekehrt als Vorgabe gesetzt, richtet sich die Struktur nach der Kennzahl und nicht nach dem Markt.

6. Granularität entscheidet über die Beherrschbarkeit

Kein anderer Punkt wird in Modularisierungsvorhaben so häufig unterschätzt wie die Granularität. Die horizontale Granularität beschreibt, wie breit ein Modul gefasst wird, also wie viele Funktionen es zusammenfasst. Werden Module zu breit geschnitten, sinkt die Kombinierbarkeit: Jede kleine Abweichung erzwingt eine weitere Ausprägung des gesamten Moduls, und die Zahl der Modulvarianten wächst schneller als die Marktvielfalt. Werden sie zu schmal geschnitten, steigt die Zahl der Module und mit ihr die Zahl der Schnittstellen, die zu pflegen, abzusichern und bei jeder Änderung zu prüfen sind. Beide Fehler wirken in dieselbe Richtung: Der Aufwand steigt, während die wahrgenommene Vielfalt gleich bleibt.

Die vertikale Granularität beschreibt, wie tief modularisiert wird, also bis auf welche Ebene die Ordnung reicht. Reicht sie zu tief, entsteht ein Regelwerk, das jede Einzelheit beschreibt und dessen Pflege mehr Kapazität bindet, als die Ordnung einspart. Bleibt sie zu flach, verschwindet die Vielfalt in den Modulen: Nach außen wirkt das Programm geordnet, während innerhalb der Einheiten unverändert Sonderlösungen entstehen. Beide Fehler sind an denselben Anzeichen erkennbar, nämlich an langen Klärungszeiten und an Änderungen, deren Auswirkungen niemand vollständig überblickt. Hinzu kommt ein drittes Anzeichen: Die Zahl der freigegebenen Einheiten wächst schneller als die Zahl der angebotenen Ausprägungen.

Falsche Granularität erzeugt damit mehr Komplexität, als sie beseitigt, und zwar unabhängig davon, wie sorgfältig die übrige Arbeit ausgeführt wurde. Der Maßstab für die richtige Wahl liegt nicht in der Eleganz der Struktur, sondern außerhalb: in der Vielfalt, die der Markt tatsächlich verlangt, in der Art, wie Fertigung und Montage segmentiert sind, und in der Frage, welche Einheiten sinnvoll beschafft, geprüft und verantwortet werden können. Granularität ist deshalb keine konstruktive Feinheit, sondern eine Entscheidung über die Beherrschbarkeit des gesamten Programms. Sie lässt sich zudem nicht einmalig treffen: Verändert sich die Marktvielfalt erheblich, ist die gewählte Granularität erneut zu prüfen.

7. Variantenlogik, Konfigurierbarkeit und Prozessklassen

Erst wenn Architektur, Module und Granularität feststehen, entsteht die Variantenlogik. Jetzt werden die Merkmale beschrieben, die ein Kunde wählt, ihre zulässigen Ausprägungen, die Abhängigkeiten zwischen ihnen und die Regeln, nach denen aus einer Auswahl eine gültige Lösung wird. Erst in dieser Reihenfolge ergibt der Variantenraum ein tragfähiges Bild, denn jede Regel hat nun eine Struktur, auf die sie sich bezieht. Wird die Variantenlogik früher entwickelt, legt sie ein Regelwerk über eine ungeklärte Struktur und bildet Ausnahmen ab statt Ordnung. Der Umfang eines solchen Regelwerks wächst dann nicht mit der Zahl der Produkte, sondern mit der Zahl der Abhängigkeiten, und damit weit über das hinaus, was dauerhaft gepflegt werden kann.

Anschließend ist über die Konfigurierbarkeit zu entscheiden. Sie ist keine Eigenschaft, die sich von selbst ergibt, sondern eine bewusste Festlegung: Nicht jede Funktion, nicht jedes Modul und nicht jede Produktfamilie muss konfigurierbar sein. Sinnvoll ist Konfigurierbarkeit dort, wo die Vielfalt bekannt, wiederkehrend und aus wiederverwendeten Lösungen erzeugbar ist. Die Produktkonfiguration bildet dann ausschließlich den zuvor entwickelten Lösungsraum operativ ab. Sie erzeugt keine Produktlogik und kann eine fehlende nicht ersetzen. Wo eine Familie diese Voraussetzungen nicht erfüllt, ist der Verzicht auf Konfigurierbarkeit keine Lücke, sondern eine wirtschaftlich richtige Entscheidung.

Zuletzt wird jede Produktfamilie ihrer Produkt-Prozess-Klasse zugeordnet. Diese Zuordnung steht bewusst am Ende und nicht am Anfang, denn sie ist das Ergebnis der vorangegangenen Arbeit: Erst wenn feststeht, wie viel Vielfalt vorab beschrieben ist und wie hoch die Wiederverwendung ausfällt, lässt sich beurteilen, welcher Entstehungsweg für eine Familie wirtschaftlich trägt. Ein Unternehmen, das diese Zuordnung vorwegnimmt, legt sich auf einen Ablauf fest, dessen Voraussetzungen es noch gar nicht geschaffen hat. Umgekehrt fällt die Zuordnung an dieser Stelle beinahe von selbst, weil die Grundlagen dafür in den vorangegangenen Schritten bereits erarbeitet wurden. In der Praxis verläuft dieser Weg dabei nicht in einem Zug. Architekturschnitt, Modulbildung, Granularität und Konfigurierbarkeit bringen regelmäßig Erkenntnisse hervor, die auf Scope und Scale zurückwirken; entscheidend ist nicht, dass jeder Schritt nur einmal durchlaufen wird, sondern dass die Richtung erhalten bleibt.

Software steht am Ende der Entscheidungsfolge. Sie macht Produktlogik ausführbar, aber sie erzeugt sie nicht.

8. Von der Produktstruktur zur steuerbaren Produktlogik

Die Produktstruktur übersetzt die Ordnung in die Sichten, mit denen im Unternehmen tatsächlich gearbeitet wird. Entwicklung, Fertigung und Vertrieb benötigen unterschiedliche Ausprägungen derselben Sache, und diese Sichten müssen auseinander ableitbar bleiben, statt nebeneinander gepflegt zu werden. Wo ein Produktprogramm konfigurierbar ist, tritt an die Stelle einzelner Erzeugnisstrukturen eine gemeinsame Obermenge, aus der die konkrete Ausprägung erzeugt wird und die je nach Sprachgebrauch als MaxBOM oder als 150-Prozent-Struktur bezeichnet wird. Entscheidend ist nicht die Benennung, sondern dass alle Sichten aus derselben Festlegung hervorgehen. Wo Entwicklungs-, Fertigungs- und Vertriebssicht unabhängig voneinander gepflegt werden, entstehen Abweichungen, die niemand beabsichtigt hat und die im Auftrag zu Rückfragen und Fehlern führen.

Erst danach folgt die digitale Umsetzung. Das Produktmodell führt Funktionen, Module, Schnittstellen, Merkmale, Regeln und Strukturen zu einer gemeinsamen Beschreibung zusammen und bildet damit die fachliche Single Source of Truth, auch wenn ihre Objekte technisch über mehrere Systeme verteilt geführt werden. Die Systemlandschaft übernimmt anschließend die Rollen, die zu ihr passen: PLM, PIM, CPQ, ERP und CRM bilden jeweils einen Ausschnitt dieser Logik ab, keines von ihnen erzeugt sie. Welche Rolle jedes System übernimmt, ist eine Folge der Produktlogik und keine Voraussetzung für sie. Ebenso wichtig ist die Governance: Ohne festgelegte Verantwortung für Architektur, Module, Regeln und Lebenszyklus zerfällt die Ordnung innerhalb weniger Produktgenerationen, weil jede Einzelentscheidung sie ein Stück weit aufweicht. Governance ist deshalb kein nachgelagerter Verwaltungsakt, sondern der Teil des Vorhabens, der über seine Haltbarkeit entscheidet.

Damit schließt sich der Weg, der bei Markt, Portfolio und Produktstrategie begonnen hat. Modularisierung mündet nicht in einem abgeschlossenen Baukasten, sondern in einer dauerhaft steuerbaren Produktlogik, die Markt, Entwicklung, Produktion und Digitalisierung über den gesamten Produktlebenszyklus verbindet. Wer diesen Weg in der beschriebenen Reihenfolge geht, erhält kein Ergebnis, das nach dem Projekt fertig ist, sondern eine Ordnung, die mit dem Programm weiterlebt und bei jeder Produktgeneration erneut wirkt. Genau darin liegt der Unterschied zwischen einem abgeschlossenen Vorhaben und einer Fähigkeit, die ein Unternehmen dauerhaft besitzt.

9. Früh pilotieren, belastbar entscheiden, kontrolliert skalieren

Ein Zielbild ist erst belastbar, wenn es reale Aufträge und Grenzfälle beherrscht. Deshalb sollte die Pilotierung nicht erst nach vollständiger Detaillierung beginnen. Eine repräsentative Produktfamilie, typische Aufträge und bewusst ausgewählte Ausnahmen zeigen früh, ob Scope, Funktionen, Schnittstellen, Modulgrenzen, Regeln und Ergebnisobjekte tatsächlich zusammenpassen. Der Pilot ist damit kein bereinigtes Demonstrationsmodell, sondern ein Realitätscheck unter Bedingungen, die später im Betrieb gelten.

Die Skalierung folgt nicht automatisch aus einem erfolgreichen Pilotprodukt. Sie benötigt eine priorisierte Roadmap für weitere Produktfamilien, Datenmigration, Systemrollen, Methodenbefähigung und Governance. Je nach Ausgangslage können Arbeitspakete parallel laufen; die Abhängigkeiten bleiben jedoch verbindlich. So wird Readiness nicht zum Verzögerungsargument, sondern zur Voraussetzung dafür, dass technische Umsetzung erst dort beginnt, wo fachliche Entscheidungen ausreichend belastbar sind.

Nicht der vollständig modellierte Baukasten ist der erste Beweis. Der erste Beweis ist ein reales Produkt, das sich aus dem Zielmodell reproduzierbar anbieten, auslegen, fertigen, ändern und betreuen lässt.

10. Anonymisierter Referenzfall: vom Moving Target zur CTO-Prozesskette

Der folgende Fall ist ein vereinfachtes Lernbeispiel auf Basis neutralisierter Projektdaten. Dargestellt wird der Kernbaukasten einer industriellen Verpackungsmaschine. Das vollständige Kundenmodell war wesentlich umfangreicher und umfasste zusätzliche Optionen, werkzeug- und formbezogene CTO+-Umfänge sowie echte ETO-Anpassungen. Diese Bestandteile bleiben aus Gründen der Vertraulichkeit außerhalb der Darstellung.

Die Ausgangslage war nicht ungeordnet. Baugruppen und Referenzmaschinen wurden klassifiziert abgelegt, und Konstrukteure versuchten, ähnliche Lösungen wiederzuverwenden. Diese Referenztechnik blieb jedoch personengebunden und auftragsbezogen. Ein stabiler CTO-Kern war nicht erkennbar: Wiederkehrende CTO-Bausteine, auftragsbezogene MTO- und CTO+-Anpassungen sowie echte ETO-Neuentwicklung waren in den Referenzmaschinen miteinander vermischt. Weder im Vertrieb noch in der technischen Klärung existierte eine verbindliche Konfigurationsvorlage. Merkmale, Modulgrenzen, Schnittstellen und Regeln waren nicht als gemeinsames Produktmodell geführt; im ERP entstand keine regelbasiert abgeleitete CTO-Stückliste.

Referenztechnik fand Ähnliches. Der neue Baukasten erzeugt reproduzierbar Zulässiges.

Vereinfachtes Lernbeispiel · neutralisierte Projektdaten

Fünf Schritte machen den verborgenen CTO-Kern sichtbar und nutzbar.

Wählen Sie eine Station. Die Darstellung trennt historische Wiederverwendung, Datenanalyse, Baukastenbildung, digitale Ausführung und Wirkung. Absolute Werte beschreiben den vereinfachten CTO-Kern; Optionen, CTO+ und ETO kommen ergänzend hinzu.

01Ausgangslage 02Kernanalyse 03CTO-Baukasten 04Prozesskette 05Wirkung

Klassifizierte Referenzen – aber kein stabiler Lösungsraum

Wiederverwendung fand statt, blieb aber von Suche, Erfahrung und manueller Anpassung abhängig. Mit jedem Auftrag veränderten sich Baugruppen, Sachnummern und Übergaben. Der vermeintliche Baukasten war ein Moving Target.

Historische Referenztechnik

Referenzmaschine A · Dateiablage

Baugruppe B · klassifiziert

Auftrag C · kopiert und angepasst

Stückliste D · neu ergänzt

→

Folge im nächsten Auftrag

Technische Klärung

Ähnliche Lösung suchen, Unterschiede bewerten, Konstruktion anpassen und erneut freigeben.

Operations

Neue oder geänderte Sachnummern, spätere Stücklisten, Einzelbeschaffung und schwankende Wiederholraten.

Nicht mangelnde Disziplin war das Problem. Es fehlte ein verbindliches Produktmodell, das Marktmerkmale, technische Funktionen, Module, Regeln und Ergebnisobjekte über Vertrieb, Engineering und ERP zusammenführte.

Der Fall zeigt, weshalb eine Baukastenentwicklung nicht bei einer Teileklassifikation enden darf. Der technische Modulschnitt, die wirtschaftliche Granularität, der datenbasierte Abdeckungsnachweis und die digitale Prozesskette sind unterschiedliche Aufgaben – ihre Wirkung entsteht jedoch erst im Zusammenspiel. Ohne stabile Architektur bleibt das Systemmodell ein Moving Target; ohne digitale Ausführung bleibt der Baukasten auf einzelne Experten angewiesen.

25 Modulvarianten und 4.800 theoretische Konfigurationen sind keine direkte Reduktionsrechnung. Die erste Zahl beschreibt den freigegebenen Vorrat, die zweite den dadurch aufgespannten Lösungsraum.

Begriffs- und Entscheidungshilfe

Drei Ebenen. Drei unterschiedliche Aufgaben.

Die drei Begriffe beschreiben keine Alternativen. Sie beantworten nacheinander drei verschiedene Gestaltungsfragen.

03

Produktbaukasten

Der freigegebene und gepflegte Vorrat an Modulen, Bausteinen und Varianten, aus dem konkrete Lösungen gebildet werden.

Was steht zur Wiederverwendung bereit?

04

Plattform

Der bewusst stabil gehaltene technische Kern, der Investition und Absicherung über Produkte und Generationen trägt.

Was soll über längere Zeit gleich bleiben?

05

Modulare Produktarchitektur

Der verbindliche Ordnungsrahmen für Funktionen, Modulgrenzen, Schnittstellen, Variationsstellen und zulässige Kombinationen.

Nach welchen Regeln entsteht Vielfalt?

1. Drei Begriffe, die dasselbe zu meinen scheinen

Sobald ein Unternehmen entschieden hat, welche Vielfalt es künftig anbieten und tragen will, stellt sich die Frage nach der inneren Ordnung. In den Gesprächen, die dann geführt werden, tauchen drei Begriffe auf: Produktbaukasten, Plattform und modulare Produktarchitektur. Sie werden häufig in einem Atemzug genannt, gelegentlich als Alternativen behandelt und regelmäßig als Synonyme verwendet. In Zielbildern und Projektaufträgen erscheinen sie nebeneinander, ohne dass definiert wäre, was jeder von ihnen bezeichnet und welche Entscheidung mit ihm verbunden ist. Der Auftrag lautet dann, einen Baukasten auf Basis einer Plattform mit modularer Architektur zu schaffen, und jeder Beteiligte liest daraus etwas anderes heraus.

Die Unschärfe fällt zunächst nicht auf, weil alle drei Begriffe in dieselbe Richtung zeigen. Sie stehen für Ordnung statt Wildwuchs, für Wiederverwendung statt Einzellösung, für Beherrschbarkeit statt Zufall. Eine Geschäftsleitung, die einen Baukasten fordert, eine Entwicklungsleitung, die eine Plattform aufbauen will, und ein Produktmanagement, das von modularer Architektur spricht, sind sich einig, dass etwas geordnet werden soll. Worüber sie sich nicht einig sind, ist der Gegenstand der Ordnung, ihr Geltungsbereich und der Zeitpunkt, zu dem sie wirkt. Solange nur über die Richtung gesprochen wird, bleibt dieser Unterschied verdeckt. Er tritt erst zutage, wenn konkrete Festlegungen zu treffen sind und sich zeigt, dass die Beteiligten verschiedene Ergebnisse erwarten.

Tatsächlich beschreiben die drei Begriffe unterschiedliche Ebenen derselben Sache. Der Baukasten bezeichnet einen Vorrat, die Plattform einen gemeinsamen Kern, die Architektur die Regel, nach der beides überhaupt funktioniert. Sie stehen damit nicht zur Wahl, sondern in einem Verhältnis zueinander. Wer sie als Alternativen behandelt, führt eine Auswahlentscheidung, wo eine Gestaltungsentscheidung ansteht, und schließt ein Projekt ab, das nur einen Teil der Aufgabe gelöst hat. Die folgenden Abschnitte bestimmen deshalb jeden der drei Begriffe für sich und beschreiben anschließend, in welchem Verhältnis sie zueinander stehen.

Einordnung auf einen Blick

Ebene	Gegenstand	Leitfrage	Ergebnis
Produktbaukasten	Wiederverwendbare Elemente	Aus welchen Elementen entstehen Varianten?	Geordneter Bausteinvorrat
Plattform	Gemeinsame Grundlagen und Kerntechnologien	Was wird über Produkte oder Familien hinweg gemeinsam getragen?	Gemeinsamer technischer Kern
Modulare Produktarchitektur	Funktionen, Module, Schnittstellen und Regeln	Wie bleibt das Gesamtsystem differenzierbar und veränderbar?	Dauerhaft steuerbare Produktordnung

2. Warum begriffliche Unschärfe wirtschaftlich wird

Begriffe sind in der Produktentwicklung keine Frage des Stils. Sie legen fest, worüber entschieden wird und wer die Entscheidung trägt. Solange nicht geklärt ist, ob ein Vorhaben einen Vorrat wiederverwendbarer Einheiten aufbauen, einen gemeinsamen Kern für mehrere Produktfamilien schaffen oder die Regeln der Zerlegung festlegen soll, bleiben Ziel, Umfang und Erfolgsmaßstab offen. Jeder Beteiligte arbeitet dann auf sein eigenes Bild hin, und alle können am Ende zu Recht behaupten, ihren Teil geliefert zu haben. Der Konflikt bricht nicht aus, weil niemand widersprochen hat. Er verlagert sich lediglich in die Zeit nach dem Projekt.

Die Folge zeigt sich nicht in der Diskussion, sondern im Ergebnis. Ein Vorhaben, das Bausteine sammelt, ohne die Regeln ihrer Kombination zu bestimmen, erzeugt eine Auswahl, aus der niemand verlässlich kombinieren kann. Ein Vorhaben, das einen gemeinsamen Kern definiert, ohne festzulegen, an welchen Stellen Produkte sich unterscheiden dürfen, erzeugt eine Basis, an der die eigentliche Vielfalt vorbeiläuft. Beides sind vollständig abgearbeitete Projekte mit unvollständiger Wirkung, und beides wird erst Jahre später sichtbar, wenn die nächste Produktgeneration entsteht. Zu diesem Zeitpunkt ist der Aufwand längst abgeschrieben, die Verantwortlichen haben gewechselt, und die Ursache lässt sich kaum noch benennen. Übrig bleibt der Eindruck, das Vorhaben habe wenig gebracht.

Deshalb steht am Anfang der Strukturarbeit keine Methodendiskussion, sondern eine Verständigung über drei Fragen: Was ist vorhanden und wird wiederverwendet? Was bleibt über Produkte und Generationen hinweg gleich? Und nach welchen Regeln darf sich etwas unterscheiden? Diesen drei Fragen entsprechen der Baukasten, die Plattform und die modulare Produktarchitektur. Sie lassen sich getrennt beantworten, aber keine der Antworten ersetzt eine andere. Erst wenn alle drei beantwortet sind, ist die innere Ordnung eines Produktprogramms beschrieben.

3. Der Produktbaukasten

Ein Produktbaukasten ist ein definierter Vorrat wiederverwendbarer Einheiten, aus denen sich unterschiedliche Produkte zusammensetzen lassen. Die Einheiten können Bauteile, Baugruppen, Funktionseinheiten oder ganze Aggregate sein. Entscheidend ist nicht ihre Größe, sondern dass sie beschrieben, freigegeben und für die Wiederverwendung vorgesehen sind. Ein Baukasten ist damit zunächst eine Bestandsaussage: Er sagt, was zur Verfügung steht und in welchen Ausführungen. Ein Baukasten ist keine Sammlung des Vorhandenen, sondern eine Auswahl aus ihm. Sein wirtschaftlicher Nutzen entsteht aus der Häufigkeit der Wiederverwendung, denn jede Einheit trägt ihren einmaligen Aufwand über die Zahl ihrer Einsätze. Entwicklung, Absicherung, Qualifizierung, Dokumentation und Lieferantenanbindung fallen einmal an, während der Nutzen mit jedem weiteren Einsatz wächst. Eine Gleichteilestrategie konkretisiert diese Absicht, indem sie festlegt, welche Funktionen und Lösungen bewusst über Produkte hinweg gemeinsam genutzt werden sollen. Kommunalität beschreibt anschließend den tatsächlich erreichten Anteil gemeinsamer Lösungen. Sie ist damit ein Ergebnis der Baukastenentscheidung und kein Ersatz für sie. Ein Baukasten wirkt deshalb umso stärker, je klarer sein Umfang begrenzt, je konsequenter seine Einheiten freigegeben und je häufiger sie tatsächlich eingesetzt werden.

Ein Baukasten allein macht jedoch keine Aussage darüber, welche Einheiten miteinander kombinierbar sind. Genau diese Aussage entscheidet über seinen praktischen Wert. Ohne festgelegte Kombinationsregeln bleibt jede Zusammenstellung eine Einzelfallprüfung, die technische Klärung erfordert und damit den Zeitvorteil aufzehrt, den die Wiederverwendung erzeugen sollte. Der Baukasten wirkt dann wie ein gut geordnetes Lager, aus dem nur derjenige zuverlässig entnehmen kann, der die Zusammenhänge ohnehin kennt. Diese Abhängigkeit von wenigen Personen ist eines der verlässlichsten Anzeichen für einen Baukasten ohne Architektur. Sichtbar wird sie daran, dass Angebote weiterhin technische Rückfragen auslösen, obwohl alle benötigten Einheiten längst vorhanden sind.

Ebenso wenig sagt der Baukasten etwas darüber aus, für welches Produktprogramm er gedacht ist. Wird er aus der Analyse vorhandener Produkte abgeleitet, bildet er den erreichten Zustand ab. Er enthält dann Einheiten für Anforderungen, die nur einmal aufgetreten sind, und es fehlt ein Kriterium, das seinen Umfang begrenzt. Ein Baukasten ist folglich ein Ergebnis und keine Ordnung: Er entsteht aus Entscheidungen, die anderswo getroffen wurden, und er kann sie nicht ersetzen. Wird er dennoch zum Ausgangspunkt gemacht, übernimmt er unbemerkt die Rolle einer Produktstrategie, ohne je als solche geprüft worden zu sein.

03

Vom freigegebenen Modulvorrat zur konfigurierten Maschine

Wählen Sie eine Konfiguration. Die benötigten Modulvarianten und ihre Verbindungslinien werden hervorgehoben; rechts setzt sich daraus die zugehörige Maschine zusammen.

Konfiguration 1Konfiguration 2Konfiguration 3

Funktionsmodul A

A1A2A3

Funktionsmodul B

B1B2

Funktionsmodul C

C1C2C3

Optionsmodul D

D1D2

Konfiguration 1

Maschine 1

Modul A1

Modul B2

Modul C1

Freigegebene Kombination ohne Optionsmodul D

Konfiguration 2

Maschine 2

Modul A2

Modul B1

Modul C3

Option D1

Freigegebene Kombination mit Option D1

Konfiguration 3

Maschine 3

Modul A3

Modul B2

Modul C2

Option D2

Freigegebene Kombination mit Option D2

4. Die Plattform

Eine Plattform ist der Teil eines Produktprogramms, der über mehrere Produkte, Produktfamilien oder Produktgenerationen hinweg unverändert bleibt. Sie umfasst typischerweise die tragende Struktur, die zentralen Funktionsträger, die Energie- und Signalführung und die grundlegenden Anschlussgeometrien. Der Begriff bezeichnet damit keinen Bauteilvorrat, sondern einen Anteil des Produkts, der als unveränderlich gesetzt ist. Ihr wirtschaftlicher Kern liegt in der Trennung von Investition und Nutzung: Der Aufwand für Entwicklung, Absicherung und Qualifizierung fällt einmal an und wird über alle Produktfamilien und Produktgenerationen getragen, die auf ihr aufsetzen. Der gezielte Carry-over tragender Lösungen in die nächste Generation ist deshalb kein bloßes Übernehmen vorhandener Teile, sondern Ausdruck einer bewussten Plattformstrategie. Er erhält getätigte Investitionen dort, wo Stabilität wirtschaftlich wertvoller ist als eine erneute technische Differenzierung. Je länger eine Plattform trägt und je mehr Produkte auf ihr entstehen, desto stärker wirkt dieser Effekt. Umgekehrt bindet jede Plattform Kapital und Entscheidungen: Was einmal festgelegt ist, lässt sich nur mit erheblichem Aufwand ändern, weil alle darauf aufsetzenden Produkte betroffen sind.

Die Plattform ist deshalb eine Entscheidung über Stabilität. Was zur Plattform gehört, darf sich nicht mit jedem Produkt ändern, denn andernfalls entfällt genau der Effekt, um dessentwillen sie besteht. Diese Festlegung hat eine unternehmerische und keine technische Begründung. Sie verlangt eine Aussage darüber, welche Anforderungen über einen längeren Zeitraum als gesetzt gelten, welche Leistungsbereiche abgedeckt werden sollen und welche Entwicklungen absehbar sind. Wird die Plattform zu eng ausgelegt, trägt sie das künftige Programm nicht. Wird sie zu weit ausgelegt, wird sie teuer und für kleine Produkte überdimensioniert. Die Festlegung ist damit eine Wette auf die Entwicklung des eigenen Marktes und gehört in die Hände derjenigen, die diese Entwicklung einschätzen müssen.

Was die Plattform nicht leistet, ist eine Aussage über die Vielfalt an ihrer Oberfläche. Sie legt fest, was gleich bleibt, nicht wie sich Produkte unterscheiden dürfen. Fehlt diese zweite Festlegung, entsteht ein bekanntes Bild: Eine sorgfältig entwickelte gemeinsame Basis existiert, und daneben wächst eine Reihe von Anpassungen, die an ihr vorbei entstehen, weil die zulässigen Unterschiede nie definiert wurden. Die Plattform ist dann vorhanden, aber sie ordnet nichts. Sie senkt den Aufwand im gemeinsamen Kern und lässt ihn an der Peripherie unverändert wachsen, dort also, wo die Kundenanforderungen tatsächlich eintreffen.

04

Prinzipbild Plattform

Drei Produktfamilien tragen denselben abgesicherten Kern. Differenziert wird oberhalb der Plattform – nicht in jeder Familie erneut im Fundament.

Produktfamilie A

Anwendung ALeistungsklasse 1

gemeinsamer Kern

Produktfamilie B

Anwendung BLeistungsklasse 2

gemeinsamer Kern

Produktfamilie C

Anwendung CLeistungsklasse 3

gemeinsamer Kern

Einmal entwickeln und absichern · mehrfach nutzen · gezielt über Generationen tragen

5. Die modulare Produktarchitektur

Die modulare Produktarchitektur ist die Regel, nach der ein Produktprogramm zerlegt ist. Sie legt fest, welche Funktionen in welchen Einheiten zusammengefasst werden, wie diese Einheiten über Schnittstellen miteinander verbunden sind und an welchen Stellen Unterschiede zwischen Produkten entstehen dürfen. Sie beschreibt damit nicht einen Bestand und nicht einen Kern, sondern eine Ordnung: die Zuordnung von Funktion zu Einheit, die Vereinbarung an den Übergabepunkten und die Festlegung der Stellen, an denen Vielfalt zugelassen ist. Die Architektur definiert dabei nicht einzelne Module. Sie definiert die Regeln, nach denen Module gebildet, abgegrenzt, verändert und miteinander verbunden werden. Eine Schnittstelle ist mehr als eine Geometrie. Sie umfasst die mechanische Verbindung, die Übergabe von Energie und Signalen, die zugesicherten Eigenschaften und die Bedingungen, unter denen sie gelten.

Diese Ordnung ist der eigentliche Träger der Wirkung. Sie macht den Baukasten kombinierbar, weil die Schnittstellen bekannt und stabil sind. Sie macht die Plattform tragfähig, weil sie beschreibt, wie Produkte an den gemeinsamen Kern anschließen, ohne ihn zu verändern. Sie schafft zugleich die Voraussetzung für wirtschaftliche Kommunalität: Gleichteile entstehen nicht dadurch, dass vorhandene Bauteile nachträglich vereinheitlicht werden, sondern dadurch, dass Funktionen und Schnittstellen so angelegt sind, dass dieselbe Lösung in unterschiedlichen Produkten eingesetzt werden kann. Sie macht Änderungen beherrschbar, weil erkennbar ist, welche Einheiten von einer Anpassung berührt werden und welche nicht, und begrenzt damit den Aufwand, den eine einzelne Änderung im Programm auslöst. Und sie macht die Vielfalt planbar, weil die Zahl der zulässigen Kombinationen aus der Architektur folgt und nicht aus der Summe der Einzelentscheidungen. Die Architektur ist damit der Ort, an dem die zuvor getroffene Entscheidung über die angebotene Vielfalt technisch verbindlich wird.

Anders als Baukasten und Plattform ist die Architektur nicht sichtbar. Sie liegt weder im Lager noch in der Konstruktion eines bestimmten Produkts, sondern in den Festlegungen, die beide erst ermöglichen. Genau deshalb wird sie in Projekten am häufigsten übersprungen: Sie erzeugt kein vorzeigbares Zwischenergebnis, ihre Wirkung tritt erst mit dem zweiten und dritten Produkt ein, und ihre Qualität zeigt sich nicht bei der Einführung, sondern bei der ersten größeren Änderung. Wer den Aufwand einer Architektur bewerten will, muss deshalb nicht das erste Produkt betrachten, sondern das dritte.

05

Prinzipbild modulare Produktarchitektur

Funktionen werden geeigneten Funktionsträgern zugeordnet. Schnittstellen und Regeln begrenzen die Wirkung von Änderungen und führen die zulässige Vielfalt.

Funktionssicht

Modul M1
Transport

Modul M2
Prozess

Modul M3
Qualität

Plattformkern

Transportieren

trägt

–

–

steuert

Positionieren

integriert

übergibt

–

synchronisiert

Bearbeiten

–

trägt

–

versorgt

Prüfen

–

–

trägt

synchronisiert

Dokumentieren

–

–

integriert

führt Daten

FunktionsintegrationMehrere Funktionen dürfen wirtschaftlich in einem Modul zusammengefasst werden.

SchnittstellenMechanik, Energie, Medien, Signale und Daten werden an den Modulgrenzen verbindlich.

VariationsstellenNur freigegebene Module und Kombinationen erzeugen zulässige Produktvarianten.

Aus denselben Modulen entstehen unterschiedliche Produktvarianten

Produkt AM1-AM2-AM3-AKern

Produkt BM1-AM2-BM3-AKern

Produkt CM1-BM2-BM3-CKern

Der Baukasten bezeichnet einen Vorrat, die Plattform einen gemeinsamen Kern, die Architektur die Regeln ihres Zusammenspiels.

6. Prinzipbeispiel: Funktionen und Module einer Verpackungsmaschine

Bei einer Blister- oder Tiefziehverpackungsmaschine beginnt die Modularisierung nicht mit einer Liste vorhandener Baugruppen. Ausgangspunkt sind die unterschiedlichen Markt- und Einsatzanforderungen: Produktart, Packungsformat, Leistung, Hygiene, Prüfanforderung und Kennzeichnung. Daraus ergibt sich eine Funktionskette aus Materialbereitstellung, Formen, Befüllen, Versiegeln, Prüfen und Ausschleusen. Erst wenn geklärt ist, welche Anforderungen welche Funktionen verändern, lässt sich entscheiden, wo Funktionsgrenzen, Modulgrenzen und Variationsstellen liegen sollen.

Funktionsisolierung bedeutet dabei nicht, jede Funktion zwangsläufig in ein eigenes Modul zu überführen. Manche Funktionen lassen sich wirtschaftlich in einem Funktionsträger integrieren; andere müssen bewusst getrennt werden, weil sie unterschiedlichen Variantentreibern, Änderungszyklen oder Verantwortlichkeiten folgen. Entscheidend ist, dass eine Änderung am Packungsformat, an der Dosierung oder an der Inspektion nicht unkontrolliert in Grundrahmen, Transport, Steuerung und benachbarte Stationen durchschlägt. Stabile mechanische, elektrische, mediale und informationstechnische Schnittstellen begrenzen diese Auswirkungen.

Der gemeinsame Plattformkern kann Grundrahmen und Transportprinzip, Steuerungs- und Sicherheitsarchitektur, HMI, Kommunikation sowie ein einheitliches Daten- und Diagnosemodell umfassen. Der Produktbaukasten enthält dagegen die freigegebenen Varianten der Folien-, Form-, Befüll-, Siegel-, Inspektions- und Auslaufmodule. Die modulare Produktarchitektur verbindet beides: Sie legt fest, welche Module zusammenpassen, welche Leistungs- und Formatbereiche zulässig sind und wie Änderungen über Maschinenfamilien und Produktgenerationen geführt werden.

Anwendungsprinzip · Verpackungsmaschine

Die Funktionskette wird sichtbar – die Modulgrenzen werden gestaltet.

Wählen Sie eine geänderte Marktanforderung. Die Darstellung zeigt, welche Funktionsmodule angepasst werden müssen – und welche innerhalb stabiler Schnittstellen unverändert bleiben.

Packungsformat ändernDosierung ändernPrüfumfang ändern

01Material bereitstellenRollenaufnahme, Bahnführung, Materialwechsel

02FormenHeizen, Tiefziehen, formatspezifische Kavität

03BefüllenZuführen, dosieren, einlegen, Anwesenheit prüfen

04VersiegelnDeckmaterial, Temperatur, Druck, Siegelzeit

05PrüfenKamera, Dichtheit, Code, dokumentierte Freigabe

06AusschleusenKennzeichnen, schneiden, sortieren, übergeben

Packungsformat ändern

Form- und Siegelmodul werden angepasst. Materialbereitstellung, Befüllung, Prüfung und Ausschleusung bleiben innerhalb ihrer definierten Schnittstellen stabil.

PlattformkernGrundrahmen, Transport, Steuerung und Sicherheit

BaukastenFreigegebene Varianten der sechs Funktionsmodule

ArchitekturSchnittstellen, Leistungsbereiche und Kombinationsregeln

Nicht die sichtbare Zerlegung macht eine Maschine modular, sondern die begrenzte Wirkung von Änderungen über definierte Funktions- und Schnittstellengrenzen.

Vom Prinzip zur Umsetzung: Dieses Beispiel erklärt die Rollen von Baukasten, Plattform und Architektur. Der vollständige anonymisierte Projektverlauf – von der historischen Referenztechnik über die Fünfjahresanalyse und den CTO-Baukasten bis zur digitalen Prozesskette – wird in Insight 105: Modularisierung als strategischer Entwicklungsprozess dargestellt.

7. Wie die drei Ebenen zusammenwirken

Aus den drei Bestimmungen ergibt sich ein klares Verhältnis. Die Architektur ist die oberste Ebene, denn sie enthält die Regeln. Die Plattform ist der stabile Anteil, den diese Regeln als unveränderlich festlegen. Der Baukasten ist der variable Anteil, den dieselben Regeln als kombinierbar zulassen. Ein Produktprogramm besitzt idealerweise alle drei: eine Ordnung, die beschreibt, wie es aufgebaut ist, einen gemeinsamen Kern, der Aufwand bündelt, und einen Vorrat, aus dem die zugelassene Vielfalt erzeugt wird. Die Architektur definiert damit die Regeln der Wiederverwendung, die Plattform bestimmt den langfristig stabilen Kern, und der Baukasten stellt die tatsächlich wiederverwendeten Lösungen bereit. Kennzahlen wie Kommunalität, Gleichteilequote oder Carry-over beschreiben den Erfolg dieser Entscheidungen; sie ersetzen die Entscheidungen selbst nicht. Fehlt eine der drei Ebenen, übernehmen die verbleibenden ihre Aufgabe nicht. Sie erzeugen lediglich den Eindruck, die Ordnung sei hergestellt.

Die drei Ebenen entstehen nicht gleichzeitig, und sie altern unterschiedlich. Der Baukasten verändert sich laufend, weil Einheiten hinzukommen und entfallen. Die Plattform ist auf Jahre angelegt und wird nur mit einer Produktgeneration erneuert. Die Architektur liegt dazwischen: Sie ist stabiler als der Baukasten und beweglicher als die Plattform, denn sie muss neue Anforderungen aufnehmen können, ohne die Schnittstellen preiszugeben. Diese unterschiedlichen Geschwindigkeiten sind kein Nachteil, sondern der eigentliche Zweck der Trennung. Sie erlaubt, den Vorrat laufend zu pflegen, ohne die Architektur anzutasten, und die Architektur weiterzuentwickeln, ohne die Plattform aufzugeben.

Damit lässt sich auch die Ausgangsfrage beantworten. Ein Unternehmen entscheidet nicht zwischen Baukasten, Plattform und modularer Produktarchitektur. Es entscheidet, wie viel seines Programms dauerhaft gleich bleiben soll, welche Unterschiede zugelassen sind und aus welchem Vorrat sie erzeugt werden. Diese drei Entscheidungen fallen unterschiedlich häufig, sie werden von unterschiedlichen Personen getroffen, und sie haben unterschiedliche Reichweite. Die drei Begriffe benennen die Ergebnisse dieser Entscheidungen. Sie werden erst dann zu Alternativen, wenn man vergisst, dass sie unterschiedliche Fragen beantworten. Für die Praxis heißt das: Ein Zielbild, das nur einen der drei Begriffe nennt, ist unvollständig, und zwar unabhängig davon, welcher genannt wird. Erst das Zusammenspiel aller drei Ebenen erzeugt die wirtschaftliche Wirkung.

8. Was die Verwechslung im Projekt anrichtet

In Vorhaben, die ohne diese Klärung starten, wiederholen sich drei Verläufe. Im ersten wird ein Baukasten aufgebaut, ohne die Architektur festzulegen. Es entsteht ein Vorrat beschriebener Einheiten, deren Kombination in jedem Einzelfall geprüft werden muss. Mehr Einheiten werden wiederverwendet, die Durchlaufzeit sinkt jedoch nicht, und der Vertrieb bemerkt keine Veränderung. Gemessen wird der Bestand, gewirkt hätte die Regel. Der zweite Verlauf betrifft die Plattform: Sie wird entwickelt und trägt mehrere Produktfamilien und Produktgenerationen, aber die zulässigen Unterschiede sind nicht definiert. Neben der Plattform entsteht eine wachsende Zahl von Anpassungen, die niemand als Vielfalt zählt. Die Kennzahlen weisen ein einheitliches Programm aus, während die Auftragsabwicklung mit einer Vielzahl von Sonderfällen arbeitet.

Der dritte Verlauf ist der aufwendigste. Die Architektur wird sorgfältig erarbeitet, in Unterlagen beschrieben und vorgestellt, aber weder in einen Vorrat freigegebener Einheiten noch in einen verbindlichen gemeinsamen Kern überführt. Sie bleibt eine Beschreibung, die niemanden bindet. Alle drei Verläufe haben denselben Ausgang: Das Vorhaben gilt als abgeschlossen, die erwartete Wirkung tritt nicht ein, und weil die Ursache begrifflicher Natur ist, wird sie meist gar nicht gesucht. Stattdessen entsteht der Eindruck, Modularisierung wirke in diesem Unternehmen eben nicht. Damit wird eine begriffliche Lücke zu einer Aussage über die eigene Leistungsfähigkeit umgedeutet.

Wirtschaftlich sind diese Verläufe deshalb so belastend, weil sie das nächste Vorhaben behindern. Der Aufwand ist angefallen, die Erwartung wurde enttäuscht, und die Bereitschaft, das Thema erneut aufzugreifen, ist gesunken. Die Klärung der Begriffe kostet dagegen wenige Arbeitstage. Sie besteht darin, für das eigene Programm festzuhalten, was als Plattform gilt, was der Baukasten umfasst und welche Schnittstellen und Variationsstellen die Architektur festlegt. Häufig wird stattdessen eine höhere Gleichteilequote als Ziel vorgegeben. Damit wird eine Ergebniskennzahl zum Gestaltungsprinzip erhoben. Maximale Gleichheit ist jedoch nicht automatisch wirtschaftlich: Sie kann zu Überdimensionierung, technischen Kompromissen und dem Verlust marktseitiger Differenzierung führen. Entscheidend ist die wirtschaftlich sinnvolle Wiederverwendung innerhalb des definierten Produktprogramms. Kaum ein anderer Schritt in der Strukturarbeit besitzt ein vergleichbares Verhältnis von Aufwand und langfristiger Wirkung wie die verbindliche Klärung dieser Ordnung. Die Festlegung muss dabei nicht vollständig sein, aber sie muss verbindlich sein und einer benannten Stelle gehören.

Eine Sammlung wiederverwendbarer Komponenten ist noch keine modulare Produktarchitektur.

9. Die Produktarchitektur ist eine unternehmerische Festlegung

Die Entscheidung, was dauerhaft gleich bleibt und wo Unterschiede zugelassen sind, wird häufig als konstruktive Frage behandelt. Sie ist es nicht. Sie legt fest, welche Leistungsbereiche ein Unternehmen künftig abdecken kann, wie schnell es auf neue Anforderungen reagiert, welche Investitionen über welchen Zeitraum getragen werden und wie teuer die nächste Produktgeneration wird. Wer diese Festlegung an die Entwicklung delegiert, delegiert eine Aussage über die künftige Marktfähigkeit an eine Stelle, die den Markt nicht verantwortet. Die Entwicklung kann und soll die Architektur ausgestalten. Ihren Rahmen zu setzen, ist eine andere Aufgabe.

Die Architektur bindet damit die Entscheidungen der vorangegangenen Schritte. Der Umfang der angebotenen Vielfalt bestimmt, wie viele Variationsstellen die Architektur vorsehen muss. Die Aussage darüber, welche Vielfalt bewusst erhalten bleiben soll, bestimmt, wo diese Stellen liegen. Und die erwartete Lebensdauer des Programms bestimmt, wie viel davon in einer Plattform gebunden werden kann. Eine Architektur ohne diese Vorgaben ist beliebig, und eine Portfolioentscheidung ohne Architektur bleibt ohne Konsequenz. In dieser Verbindung liegt der Grund, warum die Begriffsklärung keine akademische Übung ist: Sie entscheidet, ob die zuvor getroffenen unternehmerischen Festlegungen im Produkt überhaupt ankommen.

Damit ist beschrieben, wie die Vielfalt, die ein Unternehmen bewusst führen will, im Inneren geordnet wird und warum Baukasten, Plattform und modulare Produktarchitektur unterschiedliche Aufgaben beschreiben. Nicht jedes Produkt eines Programms muss dieser Ordnung jedoch in gleicher Weise folgen. Offen bleibt, welche Produkte vollständig vorbestimmt angeboten werden, welche innerhalb eines festgelegten Lösungsraums entstehen und welche weiterhin eigens entwickelt werden müssen.

Interaktive Entscheidungshilfe

Nicht zählen. Erst einordnen.

Beantworten Sie drei Fragen für eine konkrete Variante oder Anforderung. Das Ergebnis zeigt die sachgerechte Handlungsrichtung – nicht als automatischen Beschluss, sondern als Ausgangspunkt für Portfolio- und Architekturentscheidungen.

Entscheidungsregel
Marktwert bestimmt, ob Vielfalt erhalten werden soll. Bestand bestimmt, ob vermieden oder reduziert wird. Wiederholbarkeit bestimmt, ob Konfiguration trägt oder eine bewusste Projektklasse erforderlich bleibt.

01

Schafft die Ausprägung erkennbaren Marktwert?Kundennutzen, Anwendung, Marktzugang, Preisbereitschaft oder strategische Bedeutung

JaNein

02

Ist die Variante bereits im Produktprogramm vorhanden?Bestehender Bestand oder neue Anforderung vor ihrer Einführung

BestehendNeu

03

Ist die Anforderung wiederholbar und stabil regelbildbar?Wiederkehrende Funktionen, bekannte Grenzen, valide Module und reproduzierbare Ergebnisobjekte

JaNein

Empfohlene Handlungsrichtung

Marktwertige Vielfalt beherrschen

Die Vielfalt bleibt erhalten. Produktarchitektur, Module, Standards, Regeln und späte Differenzierung sorgen dafür, dass die interne Komplexität nicht proportional mitwächst.

Vermeiden

Neue Vielfalt ohne ausreichenden Marktwert nicht entstehen lassen.

Reduzieren

Bestehende Vielfalt ohne Marktwert bereinigen oder vereinheitlichen.

Beherrschen

Marktwertige, wiederholbare Vielfalt modularisieren und konfigurieren.

Bewusst abgrenzen

Echte Neuheit oder Unsicherheit als MTO-/ETO-Aufgabe projektbezogen führen.

Die Entscheidungshilfe ersetzt keine Wirtschaftlichkeitsbewertung. Lebenszyklusbeitrag, Folgekosten, Verpflichtungen, Risiken und strategische Bedeutung müssen ergänzend geprüft werden. Sie verhindert jedoch, dass jede Vielfalt reflexartig reduziert oder in ein Konfigurationsmodell gezwungen wird.

1. Weniger Varianten ist kein Ziel

In variantenreichen Industrieunternehmen folgt auf die Erkenntnis, dass die Vielfalt gewachsen ist, fast immer dieselbe Reaktion: Sie soll reduziert werden. Ein Reduzierungsprogramm wird aufgesetzt, eine Zielgröße festgelegt, ein Prozentsatz vereinbart. Der Fortschritt lässt sich anschließend an einer einzigen Zahl ablesen, an der Anzahl der Sachnummern, der Verkaufsvarianten oder der aktiven Produkte. Diese Zahl ist einfach zu erheben und einfach zu kommunizieren. Sie ist jedoch kein Maß für Wirtschaftlichkeit, denn sie sagt nichts darüber aus, welche Vielfalt Erträge sichert und welche ausschließlich Aufwand erzeugt.

Der Reduzierung liegt eine Gleichsetzung zugrunde, die selten ausgesprochen und noch seltener geprüft wird. Vielfalt gilt als Komplexität, Komplexität gilt als Kosten, und Kosten sollen sinken. Aus dieser Kette folgt scheinbar zwingend, dass weniger Varianten ein besseres Ergebnis bedeuten. Tatsächlich hält keines der beiden Gleichheitszeichen einer genaueren Betrachtung stand. Vielfalt, die Kaufentscheidungen beeinflusst oder Marktzugang ermöglicht, ist zunächst eine Ertragsquelle. Komplexität, die im Unternehmen entsteht, ohne am Markt sichtbar zu werden, ist zunächst ein Aufwandstreiber. Beide fallen nicht zusammen und lassen sich auch nicht gegeneinander verrechnen.

Die praktische Folge dieser Verwechslung ist gut beobachtbar. Gestrichen wird, was in den Auswertungen sichtbar ist, also die marktseitige Vielfalt mit geringen Stückzahlen. Was nicht in den Auswertungen erscheint, bleibt bestehen: die intern erzeugte Vielfalt an Lösungen, Teilen, Dokumenten und Abläufen, die kein Kunde jemals bemerkt. Das Programm erreicht seine Zielgröße, das Ergebnis verändert sich kaum, und der Vertrieb verliert Zugänge, die er später zurückfordert. Die Ausgangsfrage war falsch gestellt. Sie lautet nicht, wie viele Varianten ein Unternehmen führt, sondern welche Vielfalt es führt, welchen Beitrag sie leistet und an welcher Stelle sie entsteht. Erst diese Fassung der Frage erlaubt eine Entscheidung, die das Ergebnis verbessert und nicht nur eine Kennzahl.

Einordnung auf einen Blick

Handlungsart	Adressiert	Zentrales Mittel	Wirkung
Vermeiden	Künftige Vielfalt ohne ausreichenden Marktwert	Standards, Entscheidungsregeln, Verantwortung	Folgekosten entstehen gar nicht erst
Reduzieren	Bestehende Vielfalt ohne Marktwert	Portfolio- und Lösungsbereinigung	Bestand und Pflegeaufwand sinken
Beherrschen	Marktwertige, wiederholbare Vielfalt	Modularisierung, Produktmodell, Konfiguration	Vielfalt wird schneller und zuverlässiger lieferbar
Bewusst abgrenzen	Marktwertige, aber nicht stabil wiederholbare Neuheit	MTO-/ETO-Projektklasse, Reviews und Freigaben	Echte Neuheit bleibt möglich, ohne das Regelmodell zu überdehnen

2. Zwei Arten von Vielfalt, die sorgfältig zu trennen sind

Marktwertige oder externe Vielfalt ist die Vielfalt, die der Kunde wahrnimmt und in seiner Entscheidung berücksichtigt. Sie umfasst die angebotenen Produkte, die wählbaren Merkmale und Ausprägungen sowie die zulässigen Kombinationen. Sie ist Gegenstand des Leistungsversprechens und damit Bestandteil der Marktposition. Interne Vielfalt ist die Zahl unterschiedlicher Lösungen, mit denen ein Unternehmen dieses Versprechen erfüllt: Konstruktionsstände, Teile, Werkstoffe, Zeichnungen, Prüfvorschriften, Arbeitspläne, Lieferantenbeziehungen und Abläufe. Sie ist am Markt nicht als eigenständige Differenzierung wahrnehmbar. Für das Unternehmen bestimmt sie einen erheblichen Teil des laufenden Aufwands. Der Unterschied ist grundlegend: Die eine Vielfalt ist Gegenstand eines Versprechens an den Markt, die andere ist eine Eigenschaft der eigenen Organisation. Über die erste entscheidet das Unternehmen gemeinsam mit dem Markt, über die zweite entscheidet es allein.

Beide Größen sind nicht proportional zueinander, und genau darin liegt der Ansatzpunkt jeder wirtschaftlichen Bewertung. Ein Unternehmen kann ein schmales, überschaubares Produktprogramm anbieten und intern eine hohe Vielfalt unterhalten, weil vergleichbare Funktionen über Jahre mehrfach und unterschiedlich gelöst wurden. Ebenso kann ein Unternehmen ein breites Angebot mit vielen wählbaren Ausprägungen führen und intern mit einer begrenzten Zahl wiederverwendeter Lösungen auskommen. Das erste Unternehmen wirkt nach außen einfach und ist innen teuer. Das zweite wirkt nach außen vielfältig und ist innen beherrschbar. Die Zahl der Varianten unterscheidet die beiden Fälle nicht.

Aus dieser Trennung ergibt sich die eigentliche Bewertungsfrage. Für jede Variante ist zu klären, ob sie einen erkennbaren Beitrag zur Marktposition leistet und ob der Aufwand, mit dem sie erzeugt wird, dem Marktwert entspricht. Vielfalt mit Marktwert ist zu erhalten und wirtschaftlich bereitzustellen. Vielfalt ohne Marktwert ist zu beseitigen oder zu vermeiden. Erst mit dieser Unterscheidung wird aus einem Reduzierungsprogramm eine unternehmerische Entscheidung. Ohne sie wird die falsche Größe optimiert, und zwar meist diejenige, die am leichtesten zu messen ist.

3. Wie interne Vielfalt entsteht, ohne dass jemand sie entscheidet

Interne Vielfalt ist selten das Ergebnis einer Entscheidung. Sie entsteht in Situationen, in denen die Entscheidung nicht getroffen werden muss. Ein Entwicklungsprojekt steht unter Termindruck und löst eine Aufgabe eigenständig, weil die Prüfung vorhandener Lösungen Zeit kostet. Eine Nachfolgeentwicklung löst die Vorgängerlösung nicht ab, sondern tritt neben sie. Ein zweiter Lieferant bringt eine funktionsgleiche, aber nicht identische Ausführung mit. Eine Länderanforderung wird durch eine gesonderte Ausführung erfüllt, statt in die bestehende Lösung integriert zu werden. Jeder dieser Vorgänge ist für sich betrachtet vertretbar. Ihre Summe ist es nicht.

Verstärkt wird dieser Verlauf durch die Art, wie Aufwand zugerechnet wird. Die Kosten einer zusätzlichen internen Lösung entstehen verteilt und zeitversetzt, in der Arbeitsvorbereitung, in der Beschaffung, in der Qualitätssicherung, in der Dokumentation, in der Bevorratung und im Service. In der Kalkulation eines einzelnen Auftrags erscheinen sie kaum, weil sie über Zuschläge auf alle Produkte verteilt werden. Die Entscheidung, eine neue Lösung anzulegen, ist damit an der Stelle, an der sie getroffen wird, praktisch kostenfrei. Wer sie trifft, trägt ihre Folgen nicht, und wer die Folgen trägt, ist an der Entscheidung nicht beteiligt. Hinzu kommt, dass der Aufwand einer einzelnen zusätzlichen Lösung tatsächlich gering ist. Spürbar wird erst die Summe, und die Summe hat keinen Verursacher, dem sie zugerechnet werden könnte.

Diese Asymmetrie erklärt, warum interne Vielfalt zuverlässig wächst und warum sie so schwer sichtbar wird. Sie erklärt zugleich, weshalb Reduzierungsprogramme regelmäßig am falschen Ende ansetzen. Sichtbar ist die marktseitige Vielfalt, denn sie steht in Katalogen, Preislisten und Absatzstatistiken. Unsichtbar ist die interne Vielfalt, denn sie steht in keiner Auswertung, die einer Geschäftsleitung regelmäßig vorgelegt wird. Ein Unternehmen, das seine Vielfalt wirtschaftlich bewerten will, muss deshalb zuerst die Zurechnung verändern und nicht die Zahl der Varianten.

Vielfalt, die der Kunde bezahlt, ist nicht dasselbe wie Komplexität, die intern Kosten erzeugt.

Anonymisierter Praxisfall

Jährlich bereinigt. Intern trotzdem komplexer.

Ein Hersteller technischer Serienprodukte hielt sein vertrieblich aktives Katalogprogramm durch eine jährliche ABC(D)-Bereinigung bei rund 10.000 Varianten. Die Kennzahl blieb stabil – während die interne Sachnummernvielfalt und der Pflegeaufwand schleichend weiterwuchsen.

Jährliche Katalogbereinigung Verwendungslogik & Entwicklungsrahmen

Die Marktkennzahl wurde stabilisiert. Die innere Vielfalt nicht.

Im Jahresverlauf kamen kontinuierlich mehrere hundert, in einzelnen Jahren bis zu rund 1.000 neue verkaufsfähige Sachnummern hinzu. Erst zum Jahreswechsel wurden schwach oder nicht drehende Katalogvarianten gesperrt, eingeschränkt oder aus dem Programm genommen und die aktive Zahl wieder auf rund 10.000 zurückgeführt. Der Bestand war damit zahlenmäßig stabil, aber nicht identisch: Alte Varianten gingen, neue traten an ihre Stelle. Kleine technische Änderungen hatten intern bereits zusätzliche Komponenten, Unterlagen und Pflegeobjekte erzeugt; deren jährliche Bereinigung blieb deutlich geringer als ihr Zugang.

MarktseiteDie Zahl stieg im Jahresverlauf kontinuierlich und wurde erst zum Jahreswechsel auf rund 10.000 zurückgesetzt. Die Menge blieb ähnlich, ihre Zusammensetzung nicht.

Interne SeiteAuch intern wurde bereinigt. Die Rückgänge waren jedoch kleiner als die Zugänge; Sachnummern, Pflegeaufwand und Komplexität stiegen im Mehrjahrestrend.

A/B sichernTragende Katalogvarianten blieben aktiv.

C gezielt steuernNischenvarianten wurden eingeschränkt oder kundenspezifisch freigegeben.

D bereinigenNicht drehende Endvarianten wurden gesperrt oder ausgesteuert.

Blinder FleckDie Verwendung der darunterliegenden Komponenten blieb unbewertet.

≈ 10.000aktive Katalogvarianten als jährlich stabilisierte Managementgröße

bis ≈ 1.000neue verkaufsfähige Sachnummern in einzelnen Jahren vor der Bereinigung

− rund 40 %interne Sachnummernvielfalt nach fünf Jahren gegenüber der Ausgangsbasis

Die entscheidende Korrektur: Nicht nur die Bestandszahl am Jahresende normieren, sondern Zugang, Abgang und Zusammensetzung getrennt führen – auf der Marktseite für Katalogvarianten und intern über die Verwendungslogik von Komponenten. Konfiguration war hier nicht der Ausgangspunkt; ein modularer Baukasten entstand erst schrittweise aus dem neuen Entwicklungsrahmen.

Anonymisierter Projektauszug. Die Darstellung ist keinem Unternehmen der Referenzliste zugeordnet. Kurven und Zwischenverläufe sind schematisch; die genannten Größenordnungen beschreiben den dokumentierten Referenzfall. Eine zusätzliche marktseitige Reduktion ist nicht dargestellt: Sie hätte Funktionsintegration, die Zusammenlegung von Leistungsangeboten oder eine veränderte Produktdefinition vorausgesetzt.

4. Vielfalt vermeiden

Die erste und wirksamste Möglichkeit im Umgang mit Vielfalt setzt an, bevor sie entsteht. Vermeiden bedeutet, den Entstehungspunkt neuer Varianten zu kontrollieren: die Klärung von Anforderungen, die Freigabe neuer Teile und Lösungen, die verbindliche Prüfung auf Wiederverwendung und die Vorgabe eines zugelassenen Lösungsraums für Entwicklung und Vertrieb. Der Aufwand, der so gar nicht erst entsteht, muss später nicht getragen, verwaltet und wieder abgebaut werden. Kaum ein anderer Eingriff besitzt ein vergleichbar günstiges Verhältnis von Aufwand und langfristiger Wirkung. Das gilt besonders für die frühen Phasen: Ob eine Anforderung eine neue Lösung erfordert oder ob eine vorhandene angepasst werden kann, entscheidet sich in wenigen Stunden Klärungsarbeit, während die Folgen dieser Entscheidung über Jahre wirken.

Dennoch ist Vermeiden die unbeliebteste der drei Möglichkeiten, und das aus einem nachvollziehbaren Grund. Ihre Wirkung ist nicht darstellbar. Sie besteht in Kosten, die nicht angefallen sind, in Teilen, die nicht angelegt wurden, und in Ausführungen, die nie existiert haben. Ein Vermeidungserfolg lässt sich in keinem Bericht als Einsparung ausweisen. Zugleich wird die Einschränkung sofort spürbar: Entwicklung und Vertrieb erleben die Vorgabe als Verlust an Freiheitsgraden und als zusätzlichen Abstimmungsaufwand. Der Nutzen ist abstrakt und tritt verzögert ein, die Belastung ist konkret und tritt sofort ein.

Wirksam wird Vermeidung deshalb nur, wenn sie verbindlich ist und wenn die Entscheidung dort getroffen wird, wo die Folgekosten getragen werden. Eine Wiederverwendungsvorgabe, von der jeder Bereich im Einzelfall abweichen darf, ist keine Vorgabe, sondern eine Empfehlung. Ebenso wenig genügt es, Vermeidung als Haltung zu formulieren. Sie braucht einen definierten Lösungsraum, aus dem heraus Anfragen bedient werden, und eine benannte Instanz, die über Abweichungen entscheidet. Wo dieser Rahmen fehlt, verlagert sich die Vielfalt lediglich von der sichtbaren auf die unsichtbare Seite. Ebenso wichtig ist die Zeitachse: Vermeidung wirkt ausschließlich auf künftige Vorgänge und verändert am Bestand nichts. Ein Unternehmen, das ausschließlich auf Vermeidung setzt, hält den erreichten Zustand fest, statt ihn zu verbessern.

5. Vielfalt reduzieren

Reduzieren ist der Eingriff in das Bestehende und damit die aufwendigste der drei Möglichkeiten. Sie tritt in zwei sehr unterschiedlichen Formen auf, die in der Praxis häufig vermischt werden. Die erste ist die marktseitige Straffung: Produkte, Ausprägungen oder Kombinationen werden nicht mehr angeboten. Sie verändert das Leistungsversprechen und ist deshalb eine Portfolioentscheidung. Die zweite ist die interne Bereinigung: funktionsgleiche Lösungen werden zusammengeführt, Teile substituiert, Ausführungen vereinheitlicht, ohne dass sich am Angebot etwas ändert. Sie ist für den Kunden nicht wahrnehmbar und in vielen gewachsenen Produktprogrammen die wirtschaftlich ergiebigere der beiden Formen.

Die zweite Form wird gleichwohl seltener betrieben, weil sie schwerer zu organisieren ist. Sie verlangt Kenntnis darüber, welche internen Lösungen funktionsgleich sind, und diese Kenntnis liegt selten vollständig vor. Sie erfordert Abstimmung zwischen Entwicklung, Beschaffung, Fertigung und Qualitätssicherung, und sie erzeugt zunächst Aufwand: Substitution bedeutet Änderungen an Unterlagen, gegebenenfalls erneute Qualifizierung, Anpassung von Prüfungen und Werkzeugen sowie den Abbau vorhandener Bestände. Der Nutzen entsteht dagegen erst danach und dauerhaft, verteilt über viele Vorgänge und Bereiche. Eine Bewertung, die nur den Umstellungsaufwand betrachtet, wird die Maßnahme regelmäßig ablehnen und damit einen Zustand fortschreiben, dessen Kosten sie nicht ausweist. Sinnvoll ist deshalb, die interne Bereinigung nicht als eigenes Vorhaben zu führen, sondern an ohnehin anstehende Anlässe zu koppeln, etwa an eine Produktpflege, einen Lieferantenwechsel oder eine Neuentwicklung innerhalb derselben Produktfamilie.

Für die marktseitige Straffung gilt eine zusätzliche Grenze. Eine Variante kann geringe Stückzahlen erreichen und dennoch unverzichtbar sein, weil sie eine Anwendung erschließt, eine Baureihe vervollständigt, eine Zulassung in einem Zielmarkt sichert oder Folgegeschäft im Service trägt. Ebenso bestehen Verpflichtungen über den Auslauf hinaus, etwa in der Ersatzteilversorgung. Wer streicht, ohne diese Bindungen zu prüfen, verlagert Kosten in die Zukunft, statt sie zu senken. Reduzierung ist deshalb kein Rechenvorgang über Absatzzahlen, sondern eine Abwägung über den gesamten Lebenszyklus einer Variante. Sie gehört dorthin, wo Marktposition und Ergebnis gemeinsam verantwortet werden, und sie braucht eine belastbare Aussage darüber, was an die Stelle des Gestrichenen tritt.

6. Vielfalt beherrschen

Die dritte Möglichkeit verzichtet darauf, die Vielfalt zu verändern, und verändert stattdessen die Art ihrer Erzeugung. Beherrschen bedeutet, dass die angebotene Vielfalt erhalten bleibt, die interne Vielfalt aber nicht in gleichem Maß mitwächst. Erreicht wird das durch konsequente Wiederverwendung, durch eine begrenzte Zahl innerer Lösungen, die in vielen Ausprägungen kombiniert werden, und durch die Verlagerung der Variantenbildung an einen möglichst späten Punkt der Wertschöpfung. Je später sich ein Auftrag von einem gemeinsamen Stand unterscheidet, desto geringer ist der Anteil der Wertschöpfung, der variantenspezifisch erbracht werden muss.

Beherrschen ist nicht die Verlegenheitslösung für den Fall, dass Reduzierung nicht durchsetzbar war. Für marktwertige Vielfalt ist es die einzige sachgerechte Antwort, denn diese Vielfalt soll gerade nicht verschwinden. Ein Unternehmen, das seine Vielfalt beherrscht, kann Kundenanforderungen bedienen, ohne dass jede Anforderung einen neuen internen Stand erzeugt. Es kann Angebote schneller abgeben, weil die zulässigen Kombinationen bekannt sind. Es kann Aufträge zuverlässiger abwickeln, weil die Ableitung der Fertigungsunterlagen einer bekannten Logik folgt. Der Vorteil liegt nicht allein in den Kosten, sondern ebenso in Geschwindigkeit und Zuverlässigkeit. Beherrschte Vielfalt verändert damit auch die Verhandlungsposition gegenüber dem Kunden, denn eine Sonderanfrage muss nicht mehr grundsätzlich abgelehnt oder grundsätzlich angenommen werden. Sie lässt sich daraufhin prüfen, ob sie innerhalb des vorhandenen Lösungsraums erfüllbar ist.

Eine Grenze bleibt jedoch wesentlich: Nicht jede marktwertige Anforderung ist wiederholbar oder bereits so weit geklärt, dass sie stabil in Merkmale, Regeln, Module und Ergebnisobjekte übersetzt werden kann. Echte technische Neuheit und hohe Unsicherheit gehören deshalb nicht zwangsläufig in ein Konfigurationsmodell. Sie werden bewusst als MTO- oder ETO-Aufgabe abgegrenzt und mit einer eigenen Projekt-, Risiko-, Review- und Freigabelogik geführt. Beherrschen bedeutet in diesem Fall nicht Standardisierung um jeden Preis, sondern eine saubere Trennung zwischen wiederholbarer Produktlogik und auftragsspezifischer Entwicklung.

Die drei Möglichkeiten stehen dabei nicht zur Auswahl im Sinne eines Entweder-oder. Sie adressieren unterschiedliche Zustände: Vermeiden wirkt auf künftige Vielfalt, Reduzieren auf bestehende ohne Marktwert, Beherrschen auf bestehende mit Marktwert. Ein Unternehmen benötigt alle drei gleichzeitig, und die Zuordnung ergibt sich aus der Bewertung, nicht aus einer Präferenz. Wo diese Zuordnung fehlt, wird meist genau eine Möglichkeit gewählt und auf alle Fälle angewendet, und das ist in der Regel die Reduzierung, weil sie sich am einfachsten beschließen und am einfachsten berichten lässt.

Der wirtschaftliche Vorteil entsteht nicht aus möglichst wenigen Varianten, sondern aus der richtigen Vielfalt.

7. Die wirtschaftliche Wirkung zeigt sich über den Lebenszyklus

Der Aufwand einer Variante entsteht nicht bei ihrer Einführung, sondern über ihre gesamte Lebensdauer. Zur Entwicklung und Freigabe kommen Qualifizierung und Erstmusterprüfung, die Anlage und Pflege der Unterlagen, die Aufnahme in Beschaffung und Lieferantenbetreuung, die Bevorratung, die Einrichtung von Prüfung und Fertigung, die Schulung in Vertrieb und Service, die Behandlung von Änderungen sowie die Ersatzteilversorgung nach dem Auslauf. Ein erheblicher Teil dieses Aufwands fällt unabhängig von der abgesetzten Menge an. Deshalb belasten gerade Varianten mit kleinen Stückzahlen das Ergebnis überproportional, obwohl sie in der Kalkulation unauffällig bleiben.

Der Beitrag einer Variante entsteht ebenso über die Zeit und nicht allein im Verkauf des Produkts. Eine Ausprägung kann den Zugang zu einer Anwendung eröffnen, eine Lieferbeziehung sichern, Folgeaufträge nach sich ziehen oder über Jahre Servicegeschäft tragen. Wird dieser Beitrag nicht betrachtet, erscheinen genau jene Varianten als unwirtschaftlich, die eine Marktposition sichern. Wird umgekehrt nur der Umsatz betrachtet, erscheinen Varianten als tragfähig, deren interner Aufwand ihren Beitrag längst überschreitet. Beide Fehler entstehen aus derselben Ursache, nämlich aus einer Bewertung, die einen Zeitpunkt betrachtet statt einen Zeitraum.

Für die Praxis folgt daraus ein anderer Umgang mit Zahlen. Nicht die Stückzahl des vergangenen Jahres entscheidet, sondern das Verhältnis von erwartetem Beitrag und erwartetem Aufwand über die verbleibende Lebensdauer. Diese Betrachtung verlangt keine aufwendige Kostenrechnung. Sie verlangt vor allem, dass der variantenbedingte Aufwand überhaupt einer Variante zugeordnet wird, statt ihn über Zuschläge zu verteilen. Sobald diese Zuordnung besteht, verändert sich die Diskussion. Sie führt weg von der Frage, wie viele Varianten gestrichen werden, und hin zu der Frage, welche Vielfalt das Unternehmen künftig tragen will. Damit verändert sich auch der Zeitpunkt der Entscheidung. Sie fällt nicht mehr nachträglich in einem Bereinigungsprogramm, sondern vorab bei der Planung einer Produktfamilie, und dort ist sie ungleich wirksamer und deutlich günstiger.

8. Vielfalt ist eine unternehmerische Entscheidungsgröße

Damit verschiebt sich die Aufgabe von einer Kennzahl zu einer Entscheidung. Zu klären ist nicht, wie viele Varianten ein Unternehmen führt, sondern welche Vielfalt es bewusst anbietet, welche Vielfalt es intern zulässt und welche es weder anbieten noch zulassen will. Diese Klärung erfolgt entlang der Produktfamilien, weil dort Marktanforderung und innere Lösung aufeinandertreffen. Sie ist keine Aufgabe des Controllings, das den Aufwand sichtbar macht, und auch keine Aufgabe der Entwicklung, die die Lösungen gestaltet. Sie ist eine Portfolioentscheidung mit Ergebnisverantwortung.

Wo diese Entscheidung getroffen wird, verändert sich auch der Charakter der Vielfalt selbst. Sie ist dann nicht mehr das Ergebnis vieler Einzelvorgänge, sondern eine bewusst gewählte Position: ein definierter Umfang an Marktleistung, für den das Unternehmen einsteht, und ein begrenzter Vorrat innerer Lösungen, mit dem es diesen Umfang erbringt. Die Zahl der angebotenen Varianten kann dabei steigen, während der interne Aufwand sinkt. Genau diese Kombination unterscheidet ein beherrschtes Produktprogramm von einem gewachsenen, und sie ist der eigentliche Gegenstand des Variantenmanagements.

Der wirtschaftliche Vorteil entsteht folglich nicht aus möglichst wenigen Varianten, sondern aus der richtigen Vielfalt: aus einem Angebot, das der Markt honoriert, und aus einer inneren Ordnung, die dieses Angebot ohne proportional wachsenden Aufwand trägt. Ein Unternehmen, das beides trennt und beides entscheidet, verliert weder Marktzugänge noch Ergebnis. Es verliert lediglich die Vielfalt, die niemand jemals bestellt hat. Damit ist entschieden, welche Vielfalt bestehen bleiben soll. Offen bleibt, wie diese Vielfalt im Inneren strukturiert wird.

Geltungsbereich des Leitmodells

Die Kompressionslogik gilt für modulare, konfigurierbare Produktarchitekturen.

Der in diesem Insight beschriebene Zusammenhang setzt einen wiederkehrenden, regelbasiert beschreibbaren Lösungsraum voraus. Marktseitig wird er durch Merkmale, Ausprägungen und Funktionen beschrieben; produktseitig durch Funktionsträger, Module, Schnittstellen und zulässige Kombinationen.

Wo die Logik trägt

Viele marktseitige Varianten werden auf einer tieferen Produktstrukturebene auf eine begrenzte Zahl wiederverwendbarer Funktionsträger und Module komprimiert. Der Konfigurationsknoten liegt oberhalb dieser Struktur und leitet – bei Bedarf mehrstufig – aus Kundenmerkmalen valide Kombinationen und Ergebnisobjekte ab.

Wo sie nur bedingt trägt

Bei einfachen Produkten, die lediglich aus wenigen Komponenten zusammengestellt werden, oder bei MTO- und ETO-Lösungen ohne wiederholbaren, konfigurierbaren Kern greift diese Logik nur eingeschränkt. Variantenmanagement ordnet dort vor allem Portfolio, Auftragsoptionen oder Projektklassen; modulare Kompression ist nicht automatisch der wirtschaftliche Hebel.

Entscheidend ist deshalb zuerst die Produkt- und Prozessklasse: Nur wenn Wiederholungen strukturell nutzbar sind, wird aus äußerer Vielfalt eine intern beherrschbare Variantenarchitektur.

Interaktives Leitmodell

Marktentscheidung und Strukturentscheidung zusammenführen

Wählen Sie eine Sicht. Variantenmanagement entscheidet den zulässigen Lösungsraum; Modularisierung gestaltet seine wirtschaftlich beherrschbare innere Struktur.

Variantenmanagement Modularisierung Zusammenspiel

Von außen nach innenMarkt & Portfolio

01Kundennutzen

Relevante Vielfalt, Anwendungen und Zahlungsbereitschaft verstehen.

02Produktfamilien

Leistungsversprechen, Marktsegmente und Grenzen des Portfolios festlegen.

03Zulässiger Lösungsraum

Bewusst entscheiden, welche Varianten angeboten werden – und welche nicht.

Von innen nach außenProduktarchitektur

01Funktionen

Wiederkehrende und variable Anforderungen strukturell trennen.

02Module & Schnittstellen

Entkopplung, Wiederverwendung und zulässige Kombinationen gestalten.

03Beherrschbare Struktur

Vielfalt spät erzeugen und interne Standards begrenzen.

Marktmerkmale und Kundenanforderungen

Verbindende LogikProduktkonfiguration

Valide Module, Strukturen und Ergebnisobjekte

Marktvielfalt ermöglichen

Das Leistungsversprechen bleibt differenzierend und bewusst gewählt.

Interne Komplexität begrenzen

Wiederverwendung und stabile Schnittstellen reduzieren Sonderwege.

Auftragsabwicklung skalieren

Regeln machen die entschiedene Produktlogik durchgängig nutzbar.

Die Darstellung ist ein Entscheidungsmodell, keine lineare Projektabfolge. In der Praxis wirken beide Disziplinen iterativ zusammen; die Führungsrichtung bleibt jedoch eindeutig: Die Struktur folgt der Portfolioentscheidung.

1. Zwei Disziplinen, die regelmäßig verwechselt werden

In variantenreichen Industrieunternehmen fällt ein Satz besonders häufig: Man wolle modularisieren, um die Variantenvielfalt endlich in den Griff zu bekommen. Der Satz klingt schlüssig und ist doch der Ausgangspunkt vieler enttäuschter Projekte, denn er verknüpft zwei sachlich getrennte Aufgaben zu einer einzigen Erwartung. Modularisierung, also die Gestaltung des Produktprogramms aus wiederverwendbaren Bausteinen mit stabilen Schnittstellen, wird damit zum Werkzeug erklärt, mit dem eine Frage beantwortet werden soll, die sie gar nicht beantworten kann: die Frage, welche Vielfalt ein Unternehmen überhaupt anbieten will. Wer sie nicht vorher beantwortet, überträgt sie stillschweigend an die Konstruktion.

Variantenmanagement und Modularisierung sind zwei eigenständige Disziplinen mit unterschiedlichem Ausgangspunkt, unterschiedlichen Entscheidungsträgern und unterschiedlichem Wirkungsbereich. Variantenmanagement entscheidet, welche Vielfalt am Markt angeboten werden soll und welche nicht. Es ist eine Entscheidung über das Leistungsversprechen des Unternehmens. Modularisierung gestaltet, wie die als notwendig erkannte Vielfalt technisch und organisatorisch wirtschaftlich erzeugt wird. Sie ist eine Entscheidung über die innere Ordnung des Produktprogramms. Die erste Disziplin arbeitet von außen nach innen, die zweite von innen nach außen. Beide treffen sich in der Produktfamilie, also in der Gruppe verwandter Produkte, die eine gemeinsame Grundfunktion in unterschiedlichen Ausprägungen erfüllen.

Wo diese Trennung nicht bewusst ist, entsteht ein charakteristisches Missverständnis. Die Vielfalt wird als technisches Problem gedeutet und folgerichtig an die Technik delegiert. Ein Modularisierungsprojekt wird aufgesetzt, in der Entwicklung verankert und mit dem Ziel versehen, Teilezahlen und Konstruktionsaufwände zu senken. Der Markt bleibt dabei unangetastet, das Portfolio ebenso. Das Ergebnis ist regelmäßig ein sauber gebauter Bausteinvorrat, der die vorhandene Vielfalt effizienter herstellt, statt sie zu ordnen. Die erwartete Wirkung auf Durchlaufzeiten, Angebotsqualität und Ergebnis bleibt aus, obwohl fachlich gute Arbeit geleistet wurde. Der Fehler liegt nicht in der Ausführung, sondern in der Reihenfolge.

Einordnung auf einen Blick

Kriterium	Variantenmanagement	Modularisierung
Ansatzpunkt	Markt, Portfolio, Produktfamilien	Innere Struktur des Produktprogramms
Leitfrage	Welche Vielfalt wird angeboten?	Wie wird diese Vielfalt erzeugt?
Gegenstand	Externe, marktwirksame Vielfalt	Interne Vielfalt und Wiederverwendung
Ergebnis	Definierter Vielfaltsraum	Stabile Schnittstellen und Bausteine
Wirkt auf	Umsatz, Marktzugang, Leistungsversprechen	Kosten, Durchlaufzeit, Änderbarkeit
Fehlannahme	Weniger Varianten sind automatisch besser	Struktur ersetzt die Portfolioentscheidung

2. Variantenmanagement beginnt am Markt

Variantenmanagement setzt an Markt, Portfolio und Produktfamilien an. Seine Leitfrage lautet nicht, wie viele Varianten ein Unternehmen beherrschen kann, sondern welche Vielfalt Kunden tatsächlich benötigen und honorieren. Dahinter steht eine Beobachtung, die sich in nahezu jedem gewachsenen Produktprogramm bestätigt: Variantenvielfalt entsteht selten aus einer Strategie. Sie wächst über Jahre aus Einzelentscheidungen, aus einem gewonnenen Projekt mit Sonderwunsch, aus einer regionalen Anforderung, aus einer Anpassung für einen Schlüsselkunden, aus einer Nachfolgeentwicklung, die die Vorgängerlösung nicht ablöst, sondern ergänzt. Jede dieser Entscheidungen war für sich betrachtet richtig. In der Summe entsteht ein Programm, das niemand mehr bewusst gestaltet hat.

Variantenmanagement führt diese gewachsene Struktur zurück in eine Entscheidung. Es klärt, welche Ausprägungen einen erkennbaren Kundennutzen stiften, welche Varianten wirtschaftlich tragfähig sind und welche Angebote bewusst nicht weitergeführt werden. Der letzte Punkt ist der anspruchsvollste, denn er verlangt, Umsatzmöglichkeiten aktiv aufzugeben. Genau dort liegt der Unterschied zwischen einer Analyse und einer Entscheidung. Ohne diese Entscheidung bleibt jede Auswertung folgenlos. Deshalb ist Variantenmanagement keine Aufgabe, die ein Fachbereich allein trägt. Sie berührt Vertriebsstrategie, Preislogik, Produktroadmap und Ergebnisverantwortung und gehört damit auf die Ebene, die diese Größen zusammenführt.

Zum Marktbezug gehört auch das Verständnis, wofür Kunden Vielfalt überhaupt nachfragen. In technischen Investitionsgütern ist die gewünschte Variabilität selten Ausdruck einer Vorliebe. Sie folgt der Einbausituation und den Anschlussmaßen, den geforderten Leistungspunkten, den Netz- und Schnittstellenbedingungen am Einsatzort, den Umgebungsbedingungen und den Zulassungsanforderungen einzelner Zielmärkte. Diese Treiber sind unterschiedlich stabil. Manche werden dauerhaft bestehen, andere sind Relikte einzelner Projekte. Variantenmanagement unterscheidet zwischen beidem und legt damit fest, welcher Vielfaltsraum künftig verbindlich bedient wird. Erst dieser definierte Raum ist eine belastbare Vorgabe für die Gestaltung der Produktstruktur. Er beschreibt nicht, welche Varianten heute existieren, sondern welche das Unternehmen künftig verantworten will, und unterscheidet sich darin grundlegend von einer Bestandsaufnahme des Produktprogramms.

3. Modularisierung beginnt an der Produktstruktur

Modularisierung setzt an der inneren Struktur des Produktprogramms an. Sie beantwortet, wie die benötigte Vielfalt mit hoher Wiederverwendung, stabilen Schnittstellen und beherrschbarer interner Komplexität bereitgestellt wird. Ihr Gegenstand ist nicht das einzelne Produkt, sondern das Programm als Ganzes: die Zerlegung in Module, also in funktional abgeschlossene Einheiten mit definierten Übergabepunkten, und die Festlegung, welche dieser Einheiten variabel sind und welche unverändert bleiben. Der Modulschnitt entscheidet damit, an welchen Stellen des Produkts Vielfalt entstehen darf und an welchen Stellen sie ausdrücklich nicht entstehen soll. Er legt zugleich fest, an welcher Stelle der Wertschöpfung die Variante erzeugt wird, ob früh in der Konstruktion, in der Fertigung eines Basismoduls oder erst spät in Montage und Parametrierung.

Die eigentliche Substanz liegt dabei weniger in den Modulen als in ihren Schnittstellen. Eine Schnittstelle, also die geometrische, funktionale und informationstechnische Vereinbarung zwischen zwei Modulen, wirkt wie ein Vertrag: Solange sie eingehalten wird, können die dahinterliegenden Lösungen unabhängig voneinander weiterentwickelt, ersetzt oder in anderen Produktfamilien wiederverwendet werden. Stabile Schnittstellen erzeugen Freiheitsgrade. Instabile Schnittstellen erzeugen Abhängigkeiten, die sich bei jeder Änderung durch das gesamte Programm fortpflanzen. Wer Module definiert, ohne die Schnittstellen zu stabilisieren, hat die Struktur zwar benannt, aber nicht entkoppelt.

Aus dieser Logik folgt der ökonomische Kern der Modularisierung: Aus einer begrenzten Zahl beherrschter Bausteine entsteht durch Kombination eine große Zahl marktseitig unterscheidbarer Produkte. Die Vielfalt, die der Kunde wahrnimmt, wächst multiplikativ, während die Vielfalt, die das Unternehmen entwickeln, beschaffen, fertigen und pflegen muss, additiv bleibt. Damit ist Modularisierung ein Hebel auf die Kostenseite und zugleich auf die Reaktionsfähigkeit. Sie erzeugt jedoch keinen Marktvorteil aus sich heraus. Welche Kombinationen überhaupt angeboten werden sollen, ist keine Frage der Struktur, sondern eine Vorgabe an sie. Ebenso wenig ergibt sich aus der Struktur, wie viele Bausteine ein Programm verträgt. Diese Grenze wird durch die Zahl der Produktfamilien und den zugelassenen Lösungsraum gesetzt, nicht durch die technische Machbarkeit der Zerlegung.

Anonymisierter Referenzfall · Industrielle Sensorik

Mehr Vielfalt am Markt. Weniger interne Sachnummern.

Ein Hersteller entwickelte drei Produktfamilien grundlegend neu. Der Markt sollte deutlich mehr Merkmale, Funktionen und Ausprägungen erhalten; intern sollten Wiederverwendung, Modularität und Konfigurationsfähigkeit steigen.

Vorgängergeneration Neue Architektur

Markt: Merkmale · Funktionen · AusprägungenAusgangsbasis = 100 %Marktvarianz nahezu verdoppelt

100 % normiertMarktseitiger Lösungsraum

nahezu 200 %Marktseitiger Lösungsraum

Konfigurationsknoten

100 % normiertInterne Sachnummern

unter 50 %Interne Sachnummern

Funktionsträger · Module · Schnittstellen · modulares Bausteinmodell

Variantentreiber isoliertVeränderliche Anforderungen wurden strukturell voneinander entkoppelt.

Funktionen neu zugeordnetFunktionsträger und Module erhielten eindeutige Aufgaben und Grenzen.

Schnittmuster verbessertStabile Übergaben erhöhten Austauschbarkeit und Wiederverwendung.

Kombinatorik beherrschtZulässige Kombinationen wurden mehrstufig und regelbasiert konfigurierbar.

≈ +100 %marktseitige Varianz aus Merkmalen, Funktionen und Ausprägungen

< 50 %interne Vielfalt der Sachnummern gegenüber der Vorgängergeneration

≈ 4×normierter Kompressionsgrad gegenüber der Vorgängergeneration

1,5–22Bandbreite der Wiederholraten – abhängig vom jeweiligen Baustein

Die Marktvielfalt wurde nicht reduziert. Sie wurde auf tieferen Produktstrukturebenen in weniger Sachnummern, wiederverwendbare Funktionsträger und stabile Schnittstellen komprimiert.

Normierte Darstellung auf Basis der Vorgängergeneration. Die Wiederholraten bildeten nach der Kompression – abhängig von Funktion und Baustein – eine neue, annähernd gaußförmige Verteilung innerhalb der Bandbreite von 1,5 bis 22. Die anonymisierten Projektaussagen sind keinem Unternehmen der Referenzliste zugeordnet.

4. Warum die Reihenfolge über die Wirkung entscheidet

Modularisierung ist eine Optimierung unter Nebenbedingungen. Sie sucht die günstigste Struktur für einen gegebenen Vielfaltsraum. Fehlt dieser Raum, fehlt die Zielgröße, an der sich der Entwurf ausrichten könnte. Der Modulschnitt orientiert sich dann an dem, was vorgefunden wird, also an der historisch gewachsenen Konstruktion und an den Anforderungen abgeschlossener Projekte. Genau hier entscheidet die Reihenfolge über die Wirkung: Variantenmanagement definiert den Möglichkeitsraum, Modularisierung gestaltet ihn aus. Wird diese Abfolge umgekehrt, konserviert die Struktur die Vergangenheit, statt die Zukunft vorzubereiten. Der umgekehrte Fall ist ebenso wirkungslos: Eine Portfolioentscheidung, die keine Struktur findet, in der sie sich abbilden lässt, bleibt eine Absichtserklärung, weil weder Angebotserstellung noch Auftragsabwicklung ihr folgen können.

Im Maschinenbau wird Variantenmanagement teilweise weiter gefasst und als übergreifende Beherrschung der Vielfalt vom Markt bis zur Produktion verstanden. Diese Sicht widerspricht der Trennung der Disziplinen nicht, sofern ihre Rollen klar bleiben. Variantenmanagement bestimmt den Umfang und die Grenzen des angebotenen Lösungsraums. Modularisierung schafft die strukturelle Voraussetzung, diesen Raum mit begrenzten internen Standards, Modulen und Schnittstellen abzudecken. Die Produktkonfiguration verbindet beide Ebenen, indem sie marktseitige Merkmale und Ausprägungen in zulässige technische Lösungen, Produktstrukturen und Auftragsdaten übersetzt. Wo überwiegend aus vordefinierten Produkten und Ausprägungen ausgewählt wird, steht die geführte Auswahl im Vordergrund. Entsteht das konkrete Produkt dagegen erst aus dem Zusammenspiel von Merkmalen, Regeln und modularer Produktstruktur, verschiebt sich das Gewicht deutlich: Je größer der konfigurierbare Lösungsraum ist, desto stärker wird Modularisierung zum Enabler seiner wirtschaftlichen Beherrschung.

An dieser Stelle wird eine Unterscheidung praktisch bedeutsam, die den weiteren Beiträgen dieser Säule zugrunde liegt: die Unterscheidung zwischen externer, also marktwirksamer Vielfalt, die der Kunde wählt und bezahlt, und interner Vielfalt, die im Unternehmen entsteht, ohne am Markt sichtbar zu werden. Variantenmanagement adressiert vor allem die externe Vielfalt, Modularisierung vor allem die interne. Ein Programm kann nach außen schlank wirken und intern hochkomplex sein, und ebenso ist der umgekehrte Fall möglich. Wie beide Formen der Vielfalt wirtschaftlich zu bewerten sind, ist Gegenstand von Insight 102 und wird hier nicht ausgeführt.

Die Reihenfolge ist dabei keine starre Sequenz. In der Praxis laufen beide Disziplinen überlappend, weil die Strukturarbeit zeigt, welche Vielfalt besonders teuer erkauft ist, und weil diese Erkenntnis in die Portfolioentscheidung zurückwirkt. Entscheidend ist nicht der zeitliche Abstand, sondern die Führungsrichtung. Die Struktur folgt der Portfolioentscheidung, nicht umgekehrt. Wo diese Richtung offen bleibt, entstehen drei Fehlmuster, die in variantenreichen Unternehmen mit bemerkenswerter Regelmäßigkeit auftreten und die den folgenden drei Abschnitten zugrunde liegen.

Die Struktur folgt der Portfolioentscheidung, nicht umgekehrt.

5. Modularisierung ohne geklärtes Portfolio

Das erste Fehlmuster beginnt unauffällig. Ein Modularisierungsprojekt wird in der Entwicklung aufgesetzt, die bestehende Produktstruktur wird analysiert, Gleichteile und Wiederholteile werden identifiziert, Varianten werden gruppiert, und am Ende steht ein Baukasten mit definierten Bausteinen und Schnittstellen. Die Arbeit ist methodisch sauber, das Ergebnis dokumentiert und nachvollziehbar. Unbeantwortet bleibt allein die Frage, welches Produktprogramm damit künftig bedient werden soll. Der Baukasten entsteht gegen die Vergangenheit, weil die Vergangenheit die einzige verfügbare Grundlage ist.

Die Ursache liegt in der Verteilung der Konflikte. Portfolioentscheidungen sind konfliktbehaftet, denn sie berühren Kundenbeziehungen, Umsatzerwartungen und die Interessen einzelner Vertriebsregionen. Strukturarbeit dagegen lässt sich weitgehend konfliktfrei delegieren, sie ist messbar, planbar und bleibt im eigenen Haus. Ein Unternehmen, das die schwierige Entscheidung meidet, wendet sich deshalb der lösbaren Aufgabe zu und erlebt dies als Fortschritt. Eine Sonderform desselben Musters ist die Baukastenentwicklung ohne Produktfamilienlogik, also ohne vorherige Klärung, welche Produktfamilien es künftig geben soll, wie sie voneinander abgegrenzt sind und welche Marktsegmente sie bedienen.

Die Konsequenz zeigt sich erst im Betrieb. Der Baukasten bildet die historische Vielfalt ab und wird dadurch selbst umfangreich, denn er enthält Bausteine für Anforderungen, die nur ein einziges Mal aufgetreten sind. Weil die Produktfamilienlogik fehlt, existiert kein Ordnungskriterium, das die Zahl der Bausteine begrenzt. Neue Kundenanfragen, die nicht in das Raster passen, werden weiterhin außerhalb des Baukastens bearbeitet, und diese Sonderlösungen wachsen parallel weiter. Das Unternehmen unterhält danach zwei Systeme statt eines: den dokumentierten Baukasten und den gelebten Sonderweg. Die interne Komplexität ist höher als vor dem Projekt, und der Baukasten verliert seine Autorität, weil er in genau den Fällen nicht trägt, die Aufmerksamkeit erzeugen.

6. Variantenreduzierung ohne Marktbezug

Das zweite Fehlmuster ist das Spiegelbild des ersten. Hier wird die Portfolioentscheidung getroffen, aber ohne den Markt. Eine Auswertung der Absatz- und Umsatzdaten zeigt, dass ein großer Teil der Varianten nur geringe Stückzahlen erreicht. Daraus wird eine Streichliste abgeleitet und mit einem Termin versehen. Die Maßnahme wirkt entschlossen und ist intern gut begründbar, denn sie stützt sich auf belastbare Zahlen des eigenen Hauses. Sie beantwortet jedoch nur, welche Varianten wenig verkauft wurden, nicht, welche Rolle sie im Marktauftritt spielen.

Die Ursache ist eine ausschließlich nach innen gerichtete Sicht auf Vielfalt. Vielfalt erscheint als Kostentreiber, und Kostentreiber werden reduziert. Dabei bleibt unberücksichtigt, dass einzelne Varianten eine Zugangsfunktion haben. Sie erschließen eine Anwendung, sichern die Position bei einem Kunden mit hohem Folgevolumen oder erfüllen eine normative Anforderung, ohne die ein ganzer Zielmarkt verschlossen bleibt. Auch der Zusammenhang zwischen Varianten wird übersehen, etwa wenn eine selten verkaufte Ausprägung Voraussetzung für die Vollständigkeit einer Baureihe ist. Die Stückzahl allein ist kein Maß für Bedeutung.

Die Konsequenz tritt zeitversetzt ein und wird selten dem ursprünglichen Beschluss zugerechnet. Zunächst gehen einzelne Aufträge verloren, dann meldet der Vertrieb Bedarf an Ausnahmen, und diese Ausnahmen werden genehmigt, weil der konkrete Auftrag vor der abstrakten Regel steht. Die gestrichenen Varianten kehren als Sonderlösungen zurück, nun jedoch ohne Serienreife, ohne gepflegte Dokumentation und außerhalb der eingespielten Prozesse. Nach kurzer Zeit ist die frühere Variantenzahl wieder erreicht, die Struktur ist unsauberer als zuvor, und die Bereitschaft, ein weiteres Vorhaben dieser Art mitzutragen, ist im Unternehmen aufgebraucht. Erschwerend kommt hinzu, dass der Vertrieb aus einem solchen Verlauf eine Lehre zieht, die spätere Vorhaben belastet: Regeln zum Produktprogramm gelten als verhandelbar, sofern der Auftrag groß genug ist. Damit verliert nicht nur die einzelne Maßnahme ihre Wirkung, sondern das Instrument der verbindlichen Portfolioentscheidung insgesamt.

7. Digitalisierung einer ungeklärten Vielfalt

Das dritte Fehlmuster tritt häufig auf, wenn die ersten beiden bereits stattgefunden haben. Die Vielfalt ist unübersichtlich, die Angebotserstellung bindet technische Kapazität, weil kaum eine Anfrage ohne Rückfrage in die Entwicklung beantwortet werden kann, und die Fehlerquote in Auftragsklärung und Stücklistenerzeugung ist hoch. Als Antwort wird die Durchgängigkeit von der Anfrage bis zur Fertigung digitalisiert. Regelwerke werden aufgebaut, Konfigurationslogik wird hinterlegt, Systeme werden verbunden. Das Vorhaben ist technisch anspruchsvoll und wird mit hoher Aufmerksamkeit betrieben. Abgebildet wird dabei jedoch der vorgefundene Zustand.

Die Ursache liegt in einer Erwartung an Software, die diese nicht einlösen kann. Ein digitales Regelwerk verspricht Beherrschbarkeit, ohne dass zuvor eine Entscheidung über die Vielfalt getroffen werden muss. Es scheint möglich, jede bestehende Ausprägung zu erhalten und dennoch Ordnung zu gewinnen, indem die Zusammenhänge lediglich formalisiert werden. Tatsächlich verlangt jede nicht getroffene Entscheidung an dieser Stelle eine zusätzliche Regel, und jede Ausnahme, die im Vertrieb bislang durch Erfahrung getragen wurde, muss nun ausdrücklich modelliert werden. Der Aufwand wächst nicht mit der Zahl der Produkte, sondern mit der Zahl der Abhängigkeiten zwischen ihnen.

Die Konsequenz ist ein Regelwerk, dessen Pflege mehr Kapazität bindet, als die Automatisierung im Prozess einspart. Jede Produktänderung erzeugt Nacharbeit an vielen Stellen, die Verantwortung für die Regeln wandert zu wenigen Personen, und die Reaktionszeit auf Marktanforderungen sinkt, statt zu steigen. Wo die Abbildung zu langsam wird, weicht der Vertrieb wieder auf manuelle Wege aus, und die Durchgängigkeit ist genau an der Stelle unterbrochen, an der sie den größten Nutzen hätte. Digitalisierung wirkt hier als Verstärker. Sie fixiert eine ungeklärte Vielfalt und macht sie zugleich teurer veränderbar. Der Umkehrschluss ist dabei keine Absage an die Digitalisierung: Eine geklärte Vielfalt mit sauber geschnittenen Modulen und stabilen Schnittstellen lässt sich mit vergleichsweise wenigen Regeln beschreiben, weil die Produktarchitektur bereits einen großen Teil der Ordnungsarbeit geleistet hat. Die Produktkonfiguration wird dann zur verbindenden Logik zwischen den vom Markt gewählten Merkmalen und Ausprägungen, den intern verfügbaren Modulen und Standards sowie den daraus entstehenden Auftragsstrukturen. Die Systemauswahl folgt einer bekannten Produktlogik, statt sie ersetzen zu müssen.

Software macht eine entschiedene Produktlogik ausführbar. Sie entscheidet sie nicht.

8. Beide Disziplinen gehören in eine Verantwortung

Allen drei Fehlmustern liegt dieselbe Ursache zugrunde. Die Aufgabe wird geteilt, obwohl die Entscheidung zusammengehört. Das Portfolio verantwortet der Vertrieb, die Struktur die Entwicklung, die Durchgängigkeit die Digitalisierung, und jede Seite optimiert innerhalb ihrer Grenzen richtig. Die Wirkung entsteht jedoch erst im Zusammenspiel. Modularisierung ist deshalb kein rein technisches Artefakt, das eine Abteilung liefert, sondern die strukturelle Umsetzung eines unternehmerisch definierten Variantenraums. Als solche wirkt sie unmittelbar auf Entscheidungen: Sie legt fest, welche Varianten überhaupt verkauft werden dürfen, wie ein Angebot entsteht und in welcher Zeit, wie Stücklisten erzeugt werden und nach welcher Logik die Fertigung segmentiert ist.

Damit greift sie tief in Bereiche ein, die formal nicht zur Entwicklung gehören. Ein Modulschnitt, der die Fertigungssegmentierung ignoriert, erzeugt Rüstaufwand an unerwarteter Stelle. Ein Baukasten, der die Angebotslogik des Vertriebs nicht abbildet, wird umgangen. Eine Portfolioentscheidung, die die Struktur nicht kennt, streicht die falschen Varianten. Startet ein Vorhaben ausschließlich im Engineering, verpufft seine Wirkung nicht deshalb, weil die Arbeit schlecht wäre, sondern weil die Entscheidungen, die es voraussetzt, an anderer Stelle getroffen werden. Variantenmanagement und Modularisierung gehören deshalb in eine gemeinsame Verantwortung mit ausreichender Reichweite über Markt, Produkt und Prozess. Praktisch bedeutet das eine Instanz, die über den Zuschnitt des Produktprogramms und über den Zuschnitt der Module gemeinsam entscheidet und beide Entscheidungen gegeneinander abwägen darf, statt sie nacheinander in getrennten Gremien zu behandeln.

Damit lässt sich das Zusammenspiel auf eine einfache Ordnung bringen. Variantenmanagement bestimmt Umfang und Grenzen der Marktvielfalt. Modularisierung schafft die Skalierbarkeit durch begrenzte interne Standards und konsequente Wiederverwendung. Die Produktkonfiguration verbindet beide Ebenen zu einem durchgängigen Lösungs- und Auftragsprozess. Wer diese drei Ebenen einzeln betreibt, erzeugt drei erfolgreiche Teilprojekte und kein besseres Produktprogramm. Wer sie zusammenführt, gewinnt nicht weniger Vielfalt, sondern eine Vielfalt, die das Unternehmen bewusst gewählt hat und wirtschaftlich liefern kann. Die wirtschaftliche Bewertung dieser Vielfalt sowie die saubere Abgrenzung von Baukasten, Plattform und modularer Produktarchitektur vertiefen die folgenden Beiträge dieser Säule. Der Ausgangspunkt bleibt in allen Fällen derselbe: Erst die Produktlogik verstehen, danach die Struktur gestalten und zuletzt die Software auswählen.