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.