DWC Insight 106 · Executive Guide
Von ETO zu CTO+: Konfigurieren anstatt Konstruieren
Wiederkehrendes Engineering beherrschbar machen, ohne echte Neuentwicklung in ein starres Regelwerk zu pressen.
Die Transformation beginnt nicht mit einem Konfigurator und endet nicht bei standardisierten Baugruppen. Sie verlagert wiederkehrendes Wissen aus einzelnen Aufträgen in Produktarchitektur, Regeln, Daten und validierte Ergebnisobjekte – ohne notwendige Kundendifferenzierung zu verlieren.
Executive Summary
Nicht ETO ist das Problem. Problematisch ist wiederkehrendes ETO.
Kundenspezifisches Engineering ist im Maschinen- und Anlagenbau häufig notwendig und wirtschaftlich sinnvoll. Kritisch wird es, wenn bekannte Anforderungen, Berechnungen, Schnittstellen und Lösungsprinzipien Auftrag für Auftrag erneut geklärt, konstruiert, geprüft und dokumentiert werden.
Der Weg zu CTO führt deshalb nicht über eine pauschale Standardisierung. Pro Produktfamilie wird entschieden, welche Vielfalt am Markt Wert schafft, welche Lösungsanteile wiederholbar sind und wo echte technische Unsicherheit verbleibt. CTO+ bildet den kontrollierten Übergang: Ein validierter Kern wird konfiguriert; klar abgegrenzte Deltas werden parametriert, berechnet oder konstruktiv ergänzt.
Die Transformation erfordert zunächst hohe Vorleistungen in Produktarchitektur, Regeln, Datenmodellen, CPQ und Validierung. Auch die Pflege bleibt dauerhaft bestehen. Der Hebel entsteht, wenn diese Arbeit für viele Aufträge nutzbar wird und der wiederkehrende Auftragsaufwand nicht länger annähernd proportional mit dem Umsatz wächst.
Das Ziel ist nicht 100 % CTO. CTO, CTO+ und ETO bleiben als drei bewusst geführte Lösungsbereiche bestehen.
Wiederkehrendes ETO bindet Engineering an den Auftrag
Engineer to Order ist kein Mangel. Wenn Anforderungen neu sind, technische Risiken nicht vorab beherrscht werden können oder eine Lösung tatsächlich erstmals entsteht, gehört Engineering in den Auftrag. Die Aufgabe besteht nicht darin, diesen Anteil künstlich in ein Regelwerk zu pressen.
Anders ist die Situation bei wiederkehrendem ETO. Hier unterscheiden sich Aufträge zwar sichtbar, die zugrunde liegenden Funktionen, Dimensionierungswege, Schnittstellen und Lösungsmuster wiederholen sich jedoch. Die Organisation behandelt bekannte Arbeit weiterhin wie Neuentwicklung: Anforderungen werden erneut interpretiert, bestehende Projekte gesucht und kopiert, Berechnungen in persönlichen Werkzeugen geführt und Ergebnisstrukturen spät erzeugt.
Dieses Muster bleibt lange wirtschaftlich unauffällig. Engineeringstunden werden einem Auftrag zugerechnet, während Folgewirkungen in Einkauf, Produktionsplanung, Qualität, Dokumentation und Service an anderen Stellen entstehen. Wachstum wird dann durch zusätzliche Fachkräfte getragen, nicht durch höhere Wiederverwendung.
Die Kosten des Auftragsengineerings entstehen nicht nur im Engineering
Der sichtbare Konstruktionsaufwand ist nur ein Teil der Wirkung. Neue oder veränderte Lösungen erzeugen Klärungsschleifen, zusätzliche Prüfungen, neue Material- und Dokumentstände sowie Unsicherheit in Beschaffung und Fertigung. Je später belastbare Ergebnisobjekte vorliegen, desto länger bleiben nachgelagerte Prozesse abhängig von Annahmen, Excel-Listen und persönlichen Rückfragen.
Technische Klärung vor Angebot, unsichere Liefertermine und Risikoaufschläge.
Suche, Kopie und erneute Auslegung verdrängen Plattformpflege und echte Innovation.
Geänderte Lösungen müssen erneut validiert, dokumentiert und freigegeben werden.
Neue Teile, späte Spezifikationen und geringe Wiederholung erschweren Planung und Bündelung.
Späte Strukturen, Sonderprozesse und wachsende installierte Vielfalt erhöhen den Folgeaufwand.
Skalierbarkeit entsteht durch Vorleistung – nicht durch weniger Engineeringwissen.
Eine modulare und konfigurierbare Produktplattform erfordert zunächst einen hohen Aufbauaufwand in Entwicklung und CPQ. Produktarchitektur, Regeln, Berechnungen, Datenmodelle, Ergebnisobjekte und Validierung müssen vor dem skalierbaren Betrieb erarbeitet werden. Auch danach bleibt dauerhafte Pflege erforderlich. Der wirtschaftliche Hebel entsteht nicht durch weniger Wissen, sondern dadurch, dass freigegebenes Wissen über viele Angebote und Aufträge wiederverwendet wird.
Im konventionellen ETO ist dieser anfängliche Plattformaufwand geringer. Dafür kehren Klärung, Auslegung, Prüfung und Dokumentation in jedem Auftrag wieder. Referenzierung, Kopie und Ähnlichkeitssuche können den Aufwand begrenzen, ersetzen jedoch keine verbindliche Produktlogik. Mit wachsendem Geschäft steigt die benötigte Engineeringkapazität deshalb annähernd mit – und begrenzt ein ressourcenschonendes Wachstum.
Der Hebel endet nicht im Engineering. Früh belastbare Strukturen und Ergebnisobjekte ermöglichen Skaleneffekte, stabilere Kosten, wiederholbare Fertigungs- und Montageabläufe, frühere Beschaffung sowie kürzere Durchlauf- und Lieferzeiten. Dieselbe Durchgängigkeit verbessert im Service Reaktionsfähigkeit, Verfügbarkeit, Ersatzteilversorgung und Retrofit-Fähigkeit.
Interaktives Transformationsmodell
Wo Engineeringarbeit entsteht – und wie sie wiederverwendbar wird
Wählen Sie ETO, CTO+ oder CTO. Das Modell zeigt, wo Arbeit entsteht und wie sich die jeweilige Produkt-Prozess-Klasse auf Wertschöpfung und Service auswirkt.
1 · Auftragsneutrale Entwicklung und Pflege
Hoher Anteil = mehr Wissen wird unabhängig vom Auftrag vorbereitet2 · Wiederkehrende Aufwände je Angebot und Auftrag
Hoher Anteil = mehr Arbeit entsteht bei jedem Auftrag erneut3 · Wirkung in der Wertschöpfung
Hoher Anteil = stärkere operative Wirkung bei passender Umsetzung4 · Wirkung in Service und Lifecycle
Hoher Anteil = bessere Beherrschbarkeit über die NutzungsphaseLeselogik: Die Balken zeigen qualitative Profile und Wirkungspotenziale – keine addierbaren Kosten-, Zeit- oder KPI-Werte. Die tatsächliche Wirkung hängt von Produktarchitektur, Umsetzungsqualität und konsequenter Pflege ab. Ein Unternehmen benötigt häufig alle drei Lösungsbereiche parallel; entscheidend ist ihre saubere Segmentierung.
Klärungsgrad der Produktbeschreibung
Eigenständige Darstellung · keine AufwandskurveAlle drei Lösungsbereiche müssen spätestens zum Produktionsstart einen belastbaren Produktstand erreichen. Der Unterschied liegt darin, wie früh Produktbeschreibung, Ergebnisobjekte und Freigaben belastbar vorliegen.
Qualitative Darstellung. Der tatsächliche Verlauf hängt von Produktfamilie, Vertragsmodell, technischer Unsicherheit und Freigabelogik ab. Die Kurven beschreiben ausschließlich den Klärungsgrad – nicht den Aufwand.
Drei Lösungsbereiche bleiben dauerhaft bestehen.
Die Transformation bedeutet nicht, ETO vollständig abzuschaffen. Sie segmentiert den Lösungsraum und ordnet Produkt, Struktur, Prozess, Daten und Systeme so, dass jeder Bereich nach seiner eigenen Logik geführt und gepflegt werden kann.
CTO · Freigegebener Lösungsraum
Die Lösung entsteht vollständig in einem freigegebenen und validierten Lösungsraum.
- Produkt
- Definierte Marktoptionen und zulässige Kombinationen
- Struktur
- Modulare 150-%-Struktur mit reproduzierbarer Ableitung
- Prozess
- Konfigurieren, prüfen und freigeben
- Daten
- Frühe, eindeutige Ergebnisobjekte
- Systeme
- CPQ führt Regeln aus; PLM und ERP übernehmen definierte Objekte
CTO+ · Kern mit Engineering-Delta
Ein freigegebener Kern wird konfiguriert; ein begrenztes Delta wird kontrolliert ergänzt.
- Produkt
- Validierter Kern plus klar begrenzter Lösungsanteil
- Struktur
- Stabile Kernstruktur mit definierten Engineeringpaketen
- Prozess
- Konfigurieren, Delta bearbeiten, validieren und rückführen
- Daten
- Kern früh belastbar; Delta versioniert und freigegeben
- Systeme
- Klare Übergabe zwischen CPQ, PLM und Engineeringautomation
ETO · Auftragsspezifische Neuentwicklung
Echte technische Neuheit und Unsicherheit bleiben bewusst auftragsspezifisch.
- Produkt
- Neuer Lösungsinhalt außerhalb des freigegebenen Raums
- Struktur
- Referenzarchitektur plus auftragsspezifische Struktur
- Prozess
- Engineeringprojekt mit Risiko-, Review- und Freigabelogik
- Daten
- Reifegrad wächst kontrolliert im Projekt
- Systeme
- Engineering- und Projektsysteme; Referenzen unterstützen, sind aber nicht bindend
ETO, CTO+ und CTO sind keine linearen Reifegrade
Ein Portfolio kann alle drei Klassen gleichzeitig benötigen. Die richtige Zuordnung richtet sich nach technischer Vorhersehbarkeit, Wiederholgrad, Risiko und wirtschaftlichem Nutzen – nicht nach dem Wunsch, möglichst viel zu automatisieren.
01
ETO
Die Spezifikation enthält unvorhergesehene Anforderungen oder Kombinationen mit technischem Risiko. Die konkrete Lösung entsteht im Auftrag. Referenzarchitekturen und Standards bleiben dennoch nutzbar.
02
CTO+
Der Kern liegt im kontrollierten Lösungsraum. Begrenzte, beschriebene Deltas werden auftragsspezifisch ausgelegt oder konstruktiv ergänzt. Übergabe, Prüfung und Rückführung sind definiert.
03
CTO
Anforderungen, Kombinationen und Ergebnisableitungen sind vorhergesehen. Komponenten und Regeln sind freigegeben; der Auftrag löst eine zulässige Lösung aus, keine neue Produktentwicklung.
Insight 104 ordnet die vollständige Systematik von MTS, PTO, ATO, MTO, CTO, CTO+ und ETO. Für die Transformation ist vor allem die Grenze zwischen CTO+, CTO und ETO entscheidend: Was ist vollständig vorgedacht, was ist als begrenztes Delta beherrschbar und was bleibt echte Neuentwicklung?
Die Transformation erfolgt produktfamilienweise – nicht als pauschales CTO-Programm
Ein vollständiger Umbau des Portfolios in einem Schritt überfordert Organisation und Datenmodell. Tragfähiger ist ein abgegrenzter Weg: eine relevante Produktfamilie auswählen, reale Aufträge analysieren, wiederkehrende Lösungsanteile strukturieren und das Zielmodell an Standard- und Grenzfällen pilotieren.
01
Erkennen
Wiederkehrende Anforderungen, Funktionen, Berechnungen, Teile, Schnittstellen und Klärungsschleifen sichtbar machen.
02
Entscheiden
Marktwert, Wiederholgrad und technische Unsicherheit bewerten. Kern, Plus-Anteil und echtes ETO abgrenzen.
03
Industrialisieren
Module, Regeln, Parameter, Ergebnisobjekte, Prüfungen und Systemrollen in ein tragfähiges Modell überführen.
04
Pilotieren
Reale Standard- und Grenzfälle durchspielen, Übergaben testen und neue Erkenntnisse kontrolliert zurückführen.
01
Zu breit starten
Zu viele Produktfamilien, Länder, Varianten und Systeme werden gleichzeitig einbezogen. Das Zielmodell bleibt abstrakt, während der erste belastbare Pilot ausbleibt.
02
ETO vollständig abschaffen
Echte Neuheit wird in ein Regelwerk gezwängt oder wandert als unkontrollierte Ausnahme neben die Plattform. Beides erhöht statt senkt die Komplexität.
03
Pflege unterschätzen
Produkt, Struktur, Prozess, Daten und Systeme erhalten nach dem Pilot keine dauerhaften Eigentümer, Releasezyklen und Freigaben. Das Modell veraltet.
Acht Arbeitsschritte führen vom Auftragswissen zum Lösungsraum
Wiederholungen aus realen Aufträgen ermitteln
Nicht nur Teile zählen. Wiederkehrend können Anforderungen, Funktionen, Berechnungsgänge, Dokumente, Freigaben und Lösungsmuster sein.
Marktwert von historischer Ausnahme trennen
Welche Vielfalt beeinflusst Kaufentscheidung, Einsatzfähigkeit oder Preis – und welche entsteht nur aus Gewohnheit, regionalen Sonderwegen oder unklarer Verantwortung?
Produktfamilie und Transformationsscope bestimmen
Der Scope muss wirtschaftlich relevant und zugleich pilotierbar sein. Ein idealisierter Sonderfall beweist keine Skalierbarkeit.
Stabilen Kern und echte Deltas abgrenzen
Funktionen, Module und Schnittstellen definieren den wiederverwendbaren Kern. CTO+-Deltas und echte Neuentwicklung erhalten klare Grenzen.
Engineeringwissen formalisieren
Parameter, Tabellen, Berechnungen, Regeln und Freigabebedingungen ersetzen nicht das Fachwissen. Sie machen wiederholbare Entscheidungen reproduzierbar.
Ergebnisobjekte und Übergaben definieren
Konfiguration muss mehr als eine Auswahl liefern: technische Spezifikation, Preise, Dokumente, Identitäten und Strukturen für nachgelagerte Prozesse.
Reale Grenzfälle früh validieren
Der Pilot muss Standard, Plus-Anteil und bewusstes ETO enthalten. Erst Grenzfälle zeigen, ob Regelwerk und Engineeringübergabe tragen.
Neues Wissen kontrolliert zurückführen
Wiederkehrende Deltas werden nach Bewertung in Plattform, Regeln und Prüfungen übernommen. Nicht jede Sonderlösung wird automatisch zum Standard.
CTO+ benötigt mehr als Module und einen Konfigurator
Ein modularer Produktaufbau ist notwendig, aber nicht hinreichend. Wenn Regeln nur in persönlichen Werkzeugen liegen, Ergebnisobjekte spät entstehen oder Systeme dieselben Objekte unabhängig pflegen, verlagert sich die Komplexität in Schnittstellen und manuelle Orchestrierung.
Fachliche Grundlage
Ein belastbarer Lösungsraum verbindet vier Ebenen.
Funktionen, Module, Schnittstellen und zulässige Kombinationen begrenzen den Lösungsraum.
Parameter, Regeln, Berechnungen und Freigaben machen wiederholbare Entscheidungen ausführbar.
Spezifikation, Preis, Dokumente und Strukturen entstehen früh genug für Vertrieb, Engineering und Operations.
Systemhoheit, Änderung, Gültigkeit, Test und Rückführung bleiben über den Lifecycle nachvollziehbar.
Die Softwareauswahl folgt dieser fachlichen Architektur. Je nach Aufgabe können CPQ, PLM, ERP, CAD-Automation oder spezialisierte Engineeringwerkzeuge unterschiedliche Rollen übernehmen. Entscheidend ist nicht maximale Funktionsbreite in einem System, sondern eine klare Arbeitsteilung mit eindeutiger Datenhoheit.
Anonymisiertes Langzeitbeispiel: Wachstum von Engineeringkapazität entkoppeln
Referenzverlauf · Technologieunternehmen
Der Umsatz stieg von 1,1 auf 3,9 Mrd. Euro – die Engineeringkapazität um rund 30 %.
Bei einem Technologieunternehmen wuchs der Umsatz innerhalb von zehn Jahren von 1,1 auf 3,9 Mrd. Euro; die jährlichen Wachstumsraten lagen dabei zwischen knapp 10 und fast 20 %. Die CTO-Transformation war die notwendige Voraussetzung, dieses Wachstum mit lediglich rund 30 % zusätzlicher Engineeringkapazität operativ bewältigen zu können.
Umsatzentwicklung innerhalb von zehn Jahren bei hohen jährlichen Wachstumsraten.
Gezielter Kapazitätsaufbau, jedoch deutlich unterproportional zum Umsatzwachstum.
Produktfamilien und reale Aufträge wurden nach CTO, CTO+ und ETO segmentiert. Wiederkehrendes Wissen floss in Plattform, Regeln, Ergebnisobjekte und Systemlogik.
Bei unveränderter Arbeitsweise hätte die Engineeringkapazität in annähernd derselben Größenordnung wie der Umsatz wachsen müssen. Unter den verfügbaren Ressourcen-, Kosten- und Lieferzeitbedingungen wäre dieses Wachstum nicht realisierbar gewesen.
Die Kapazitätswirkung war nur ein Teil des Nutzens. Wiederverwendete Module und definierte Ergebnisobjekte eröffneten zusätzlich Skaleneffekte in Beschaffung und Wertschöpfung, frühere Planbarkeit sowie kürzere und stabilere Durchlauf- und Lieferzeiten. Die konkrete Ausprägung unterschied sich nach Produktfamilie und Prozessklasse.
Einordnung: Das Beispiel ist ein anonymisierter Referenzverlauf und keine allgemeine Benchmark. Es zeigt den Skalierungsmechanismus einer konsequenten CTO-Transformation im konkreten Unternehmenskontext.
Ist wiederkehrendes Engineering ein Kandidat für CTO+?
Die folgenden Fragen ersetzen keine Produktanalyse. Sie zeigen jedoch, ob sich eine Produktfamilie für eine gezielte Transformation eignet. Mehrere klare Antworten sprechen für einen begrenzten Pilot – nicht automatisch für vollständiges CTO.
Wiederholen sich Kundenanforderungen und Funktionen, obwohl die konkrete Ausführung variiert?
Werden frühere Aufträge regelmäßig gesucht, kopiert oder manuell angepasst?
Lassen sich Deltas über wenige Parameter, Berechnungen oder klar definierte Pakete beschreiben?
Bleiben technische Risiken für einen abgrenzbaren Kern über Aufträge hinweg stabil?
Entstehen Klärung, Stücklisten, Dokumente oder Beschaffungsinformationen heute zu spät?
Verbraucht wiederholte Auftragsarbeit Engineeringkapazität, die für Plattform und Innovation fehlt?
Kann ein reales Set aus Standard- und Grenzfällen für einen Pilot zusammengestellt werden?
Gibt es eine benennbare Verantwortung für Produktlogik, Regeln und Rückführung nach dem Pilot?
Abgrenzung zu Insight 104
Insight 104 erklärt, welche Produkt-Prozess-Klassen für ein Portfolio sinnvoll sind. Insight 106 setzt danach an und zeigt, wie wiederkehrendes Auftragswissen schrittweise in einen kontrollierten CTO+- oder CTO-Lösungsraum überführt wird.
Fazit für Entscheider
Die wirtschaftliche Frage lautet nicht ETO oder CTO.
Die relevante Entscheidung lautet: Welche Vielfalt schafft für den Kunden erkennbaren Wert, welche Lösungsanteile wiederholen sich und welcher Engineeringanteil bleibt technisch oder wirtschaftlich bewusst auftragsspezifisch? Erst diese Trennung macht aus einer allgemeinen Standardisierungsforderung eine belastbare Produkt- und Prozessstrategie.
CTO und CTO+ entlasten das Engineering nicht dadurch, dass weniger technisches Wissen benötigt wird. Das Wissen muss früher, strukturierter und über Produkt, Prozess, Daten, Systeme und Organisation hinweg nutzbar werden.
Das Ziel ist keine maximale Konfigurierbarkeit. Das Ziel ist eine bewusste Grenze zwischen wiederverwendbarer Produktlogik und wertschöpfender Neuentwicklung.
English Executive Summary
From ETO to CTO+: Configure Instead of Redesigning Each Order
Engineer to Order is not inherently inefficient. It remains appropriate when requirements are genuinely new, technical risks cannot be resolved in advance or a solution must be developed for the first time. The problem is recurring ETO: familiar requirements, calculations, interfaces and solution patterns are clarified, engineered, validated and documented again for each order.
The transition to Configure to Order therefore does not begin with a configurator or a blanket standardization program. For each product family, companies must distinguish customer-relevant variety from historical exceptions, identify repeatable solution content and define where genuine technical uncertainty remains.
CTO+ provides the controlled transition. A validated core is configured, while clearly bounded deltas are parameterized, calculated or engineered for the order. Handover, validation and feedback into the product platform are explicitly designed. CTO applies where requirements, combinations, components and result derivation have been anticipated and approved. ETO remains where genuine new solution content is created.
The transformation requires substantial upfront investment in product architecture, rules, data models, CPQ, result objects and validation. Ongoing platform maintenance also remains necessary. The economic lever arises when this work can be reused across many quotations and orders, reducing the recurring order-specific effort and partially decoupling growth from engineering capacity.
The target is not 100 percent CTO. CTO, CTO+ and ETO remain three permanent solution domains that must be segmented and managed consistently across product, structure, process, data and systems. Starting too broadly, forcing genuine novelty into configuration rules or neglecting ongoing ownership are common reasons why transformations fail.
In one anonymized long-term reference, revenue grew from EUR 1.1 billion to EUR 3.9 billion within ten years, with annual growth rates ranging from just under 10 to almost 20 percent. The CTO transformation was the necessary operational prerequisite for handling this growth with only about 30 percent additional engineering capacity. Under the previous way of working, engineering capacity would have had to grow in almost the same order of magnitude as revenue; the growth could not have been realized under the available resource, cost and lead-time constraints.
Weiterführende Insights
Position: Säule 1 · Modularisierung und Variantenmanagement · Beitrag 6 von 6
Vorheriger Beitrag: Insight 105 – Modularisierung als strategischer Entwicklungsprozess
Nächster Beitrag: — Abschluss der Säule