CONFIGURATIE & MODULARITEIT

CPQ is niet CTO

Waarom snellere offertes uw engineering-bottleneck niet oplossen — en waarom de transitie naar modulariteit de investering is die er werkelijk toe doet.

Leestijd: ~8 min Bronnen: Hvam et al. (2008), Gartner, Felfernig et al. (2014), Kristjansdottir et al. (2018) CPQ · CTO · Modulariteit · Productarchitectuur

WAAROM DIT ERTOE DOET

De markt verwart twee fundamenteel verschillende concepten

CPQ en CTO worden door softwareleveranciers door elkaar gebruikt. Prospects die “CPQ” zoeken, hebben in veel gevallen een CTO-transformatie nodig. Het verschil begrijpen voorkomt een verkeerde investering — en bespaart jaren aan technische schuld.

CPQ (Configure-Price-Quote) automatiseert het offerteproces. Gartner definieert het als een verkoopautomatiseringstool: configuratie, prijsbepaling, offertegeneratie en orderplaatsing. Het zit in het verkoopproces en verandert niets aan uw productarchitectuur.

CTO (Configure-to-Order) is een productiestrategie gebaseerd op modulaire productarchitectuur. Het herstructureert producten zodat ze configureerbaar zijn vanuit vooraf gedefinieerde modules — in plaats van per order opnieuw ontworpen. CTO raakt engineering, productie, inkoop en verkoop.

Het cruciale verschil: CPQ maakt uw huidige proces sneller. CTO verandert het proces zelf.

DEFINITIES

Twee begrippen, twee werelden

CPQ — Configure-Price-Quote

Verkoopautomatisering
  • Genereert offertes op basis van productcatalogus en prijsregels
  • Primaire gebruiker: verkoopteam
  • Verandert de productarchitectuur niet
  • Verandert het productieproces niet
  • Output: offertedocument
  • Werkt voor zowel ETO als CTO bedrijven

CTO — Configure-to-Order

Productietransformatie door modulariteit
  • Herstructureert producten voor configuratie vanuit modules
  • Primaire stakeholders: engineering, productie, inkoop
  • Verandert de productarchitectuur fundamenteel
  • Verplaatst het KOOP naar later in de keten
  • Output: configureerbare productstructuur met gevalideerde modules
  • Maakt CPQ triviaal als bijproduct

CPQ is een tool. CTO is een transformatie. Het een koopt u; het ander bouwt u op.

EEN TOOL, TWEE WERELDEN

CPQ werkt voor ETO en CTO — maar het resultaat verschilt fundamenteel

CPQ-leveranciers bedienen zowel ETO als CTO bedrijven. Tacton, encoway en Epicor bieden allemaal oplossingen voor beide productiemodellen. Maar het resultaat is fundamenteel anders:

Dimensie CPQ in ETO CPQ in CTO
Wat het oplevert Snellere offerte Productie-ready specificatie
Na de offerte Engineering review nodig Direct naar productie
Regelgroei Exponentieel (constraint-explosie) Lineair (moduletoevoegingen)
Wie onderhoudt het CPQ-developer/programmeur Engineers (domeinexperts)
Downstream impact Geen — processen blijven ETO Volledig — KOOP verschuift
Implementatie-complexiteit Hoog (open oplossingsruimte) Laag (begrensd door modulaire architectuur)
ROI-horizon Beperkt tot offerteproces Breed: engineering, inkoop, productie, service

Haug, Shafiee & Hvam (2019) documenteerden dat ETO bedrijven wél voordelen behalen uit CPQ — snellere offertes, minder specificatiefouten — maar dat het CPQ-systeem het downstream fulfilment-model niet verandert. De offerte is sneller; engineering, inkoop en productie blijven ETO.

“CPQ was never designed to support or acknowledge engineering changes and does not manage engineering tolerances, rules, nor specifications.”

— CPQ-Pro, industrieanalyse

CONFIGURATIEAANPAK

Waarom ETO-projecten programmeurs nodig hebben — en CTO-projecten niet

De manier waarop een configuratiesysteem werkt, hangt af van de onderliggende productarchitectuur. Bij ETO is de oplossingsruimte open — er zijn geen vooraf gedefinieerde modules. Bij CTO is de oplossingsruimte begrensd door de modulaire architectuur.

Configuratieaanpak: constraint-based vs model-based
Constraint-based configuratie (ETO-patroon)
De oplossingsruimte is open en onbegrensd. Elke productvariant wordt gedefinieerd door honderden of duizenden constraints die vastleggen wat wel en niet kan. Dit vereist SAT-solvers, constraint satisfaction en gespecialiseerde CPQ-programmeurs. Elke productwijziging vereist developer-interventie. Felfernig et al. (2014): “requires technical expertise of how to define and solve the underlying configuration problem.”
Model-based configuratie (CTO-patroon)
De oplossingsruimte is begrensd door de modulaire productarchitectuur. Configuratieregels volgen natuurlijk uit de productstructuur: welke modules, welke varianten, welke interfaces. Engineers definiëren en onderhouden de modellen zelf — geen tussenkomst van programmeurs nodig. Mittal & Frayman (1989): configuratie als “a type of design activity in which a set of pre-defined components can be combined.”
SharedBrains is regelgebaseerd en model-gebaseerd

Ontworpen voor CTO-omgevingen waar engineers hun eigen productmodellen definiëren met bedrijfsregels. Geen constraint-programmering, geen afhankelijkheid van CPQ-developers. De configuratie volgt uit de productarchitectuur — niet andersom.

HET RISICO

CPQ zonder CTO bouwt technische schuld op

Wanneer een ETO-bedrijf CPQ implementeert zonder eerst de productarchitectuur te herstructureren, volgt een voorspelbaar patroon. De offerte wordt sneller — maar het downstream proces blijft even complex. De constraints stapelen zich op, de developer-afhankelijkheid groeit, en binnen enkele jaren is het CPQ-systeem zelf het probleem.

CPQ zonder CTO: het technische schuld-traject
Jaar 1Snelle offertes, initieel enthousiasme. Het systeem werkt voor de meest voorkomende configuraties.
Jaar 2Regelonderhoud begint developer-tijd te consumeren. Elke nieuwe productvariant voegt constraints toe die interageren met alle bestaande regels.
Jaar 3Onverwachte configuraties. Constraint-interacties produceren combinaties die technisch “geldig” zijn maar niet maakbaar. Engineering reviewt nog steeds elke offerte.
Jaar 4Te complex om veilig te wijzigen. Workarounds prolifereren. Niemand durft de regelbasis aan te passen zonder risico op regressie.
Jaar 5Het CPQ is legacy. 40% meer onderhoudskosten dan bedrijven die het vroeg aanpakken (Cincom, 2024). De volgende leverancierspitch begint.
Schijnautomatisering

79% van de fabrikanten worstelt nog steeds met offertekwaliteit ondanks CPQ-systemen (Panorama Consulting). De offerte is snel, maar het downstream proces — engineering, inkoop, productie — blijft even complex als voorheen. CPQ zonder CTO automatiseert de symptomen, niet de oorzaak.

DE BUSINESS CASE

Waarom de transitie naar modulariteit loont

De business case voor ETO-naar-CTO modularisatie is overweldigend. Academisch onderzoek en industrie-casestudies tonen dezelfde patronen: bedrijven die eerst investeren in modulaire productarchitectuur, plukken daar breed de vruchten van — niet alleen in het offerteproces, maar in de hele waardeketen.

842%

ROI over 5 jaar
Kristjansdottir et al. (2018)

64%

Doorlooptijdreductie
Specificatieproces

50×

Meer configuraties
met 75% minder componenten

15–20%

Materiaalkosten lager
McKinsey (2019)

Doorlooptijd en schaalbaarheid

Modulaire architectuur elimineert per-order engineering. Hvam et al. (2013) documenteerden doorlooptijdreductie, minder resource-inzet per specificatie en verbeterde leverbetrouwbaarheid over vier bedrijven. CommScope realiseerde 50% kortere ontwikkeltijd. HVAC-fabrikanten reduceerden engineering-werkbelasting per order naar nul voor geconfigureerde productfamilies.

Kennisborging en personeelsrisico

Wanneer engineering-kennis in productmodellen zit in plaats van in hoofden van experts, is de organisatie weerbaar tegen pensioen, verloop en groei. Harlou (2006) toonde bij Bang & Olufsen, Vestas, Alfa Laval en LEGO dat productarchitectuur als expliciet, overdraagbaar artefact de afhankelijkheid van sleutelpersonen structureel verlaagt.

Supply chain voordelen

Gestandaardiseerde modules maken volume-inkoop, kortere doorlooptijden en voorspelbare leveringen mogelijk. CommScope reduceerde het leveranciersbestand van 777 naar minder dan 250. McKinsey documenteerde 15–20% reductie in directe materiaalkosten door componentstandaardisatie.

CPQ wordt een bijproduct

Wanneer modulaire architectuur bestaat, is het configuratiesysteem een natuurlijke interface naar het productmodel. Het hoeft niet als apart project te worden geïmplementeerd — het volgt uit de productstructuur. Daarom rapporteren CTO-bedrijven dramatisch hogere configuratie-ROI dan ETO-bedrijven die CPQ implementeren zonder architectuurfundament.

DE LOGISCHE VOLGORDE

Eerst modulariteit, dan configuratie

Het KOOP (Klant Order Ontkoppel Punt) is het punt in de supply chain waar een klantorder activiteit triggert. Het is het structurele verschil tussen ETO en CTO:

  • ETO = vroeg KOOP. Elke klantorder triggert de gehele keten: engineering, inkoop, productie, assemblage, logistiek. De klant wacht op alles.
  • CTO = laat KOOP. Modules zijn vooraf ontworpen en vaak vooraf geproduceerd. De klantorder triggert alleen eindconfiguratie en assemblage. Engineering-kennis zit al in het productmodel.

Deze structurele verschuiving splitst de supply chain in twee zones:

  1. Efficiëntiezone (vóór KOOP) — geoptimaliseerd voor kosten door lean, modulestandaardisatie en volume-inkoop.
  2. Snelheidszone (na KOOP) — geoptimaliseerd voor klantresponstijd. Hier worden de doorlooptijdreducties gerealiseerd.

CTO maakt CPQ triviaal. Wanneer de productarchitectuur modulair is, schrijven de configuratieregels zichzelf. De oplossingsruimte is gedefinieerd door de modulefamilies en hun interfaces. Er hoeven geen constraints te worden geprogrammeerd — het model bévat de regels al. Kristjansdottir et al. (2018) documenteerden 842% ROI wanneer modulaire architectuur voorafging aan het configuratiesysteem.

WAT CTO WEL IS

CTO is geen tool — het is een transformatie op drie pijlers

CTO is niet één capability — het is het snijvlak van drie onderling afhankelijke pijlers. Alle drie moeten samen worden aangepakt. Wanneer CTO mono-disciplinair wordt geïmplementeerd (alleen engineering, alleen IT, alleen sales), is het resultaat partieel — en vaak teleurstellend.

Orderspecificatie

PIJLER 1

Het vermogen om klantspecifieke producten te configureren vanuit modulaire bouwstenen zonder per-order engineering. Hier leven de configuratieregels, productmodellen en expertkennis.

SharedBrains: MPS-module — regelgebaseerde configuratie waar engineers hun eigen modellen beheren.

Technische modulariteit

PIJLER 2

De productarchitectuur die configuratie mogelijk maakt. Modules moeten ontworpen zijn voor hercombinatie — niet alleen voor interne standaardisatie. De modularisatie-as moet marktopties volgen, niet engineering-gemak.

SharedBrains: Modularity-First methodologie — assessment en herstructurering van productarchitectuur.

Supply chain inrichting

PIJLER 3

De operationele infrastructuur voor module-gebaseerde productie, laat KOOP en gestroomlijnde levering. Zonder supply chain gereedheid stromen geconfigureerde orders nog steeds door ETO-processen.

SharedBrains: GATE + Shopfloor Control — productie-uitvoering vanuit hetzelfde productmodel.

De “Engineering Feestje”-valkuil

In de praktijk wordt ETO-naar-CTO transformatie bijna altijd gezien als een puur engineering-initiatief. Verkoop, inkoop, productie, finance en service voelen zich buitenstaanders. Ze haken af, en het initiatief verliest het multi-disciplinaire draagvlak dat het nodig heeft. CTO is een bedrijfstransformatie, geen IT-project.

VEELGEHOORD BEZWAAR

"Onze klanten willen maatwerk" — CTO vergroot de mogelijkheden

Het meest gehoorde bezwaar tegen modularisatie: “Wij zijn maatwerk, standaardisatie past niet bij ons.” Dit berust op een misverstand. CTO betekent niet standaardiseren — het betekent diversiteit creëren door modules.

Contra-intuïtief levert modulaire architectuur meer klantspecifieke combinaties op dan ETO, omdat de beperkende factor verschuift van engineering-capaciteit naar het aantal modulevarianten:

  • 5 modulefamilies × 4 varianten = 1.024 mogelijke configuraties
  • Dat is meer dan een ETO-team per order kan ontwerpen
  • CommScope realiseerde 50× meer configuraties met 75% minder componenten

Salvador, de Holan & Piller (2009) bevestigden op basis van 200+ fabrieken in 8 landen dat mass customization succesvol is wanneer modulaire capability op zijn plaats is — de architectuur maakt de variatie mogelijk, niet het per-order engineering.

SAMENVATTING

Zes redenen waarom CPQ niet CTO is

Ander doel

CPQ genereert offertes. CTO herstructureert producten voor modulariteit. Het een is verkoopautomatisering; het ander is een bedrijfstransformatie.

Ander bereik

CPQ zit in het verkoopproces en laat downstream onaangetast. CTO raakt engineering, productie, inkoop en de gehele supply chain.

Andere aanpak

ETO CPQ = constraint-based, vereist programmeurs. CTO = model-based, engineers beheren zelf. Regelgroei exponentieel vs. lineair.

Andere volgorde

CTO maakt CPQ triviaal. Eerst modulariteit, dan configuratie. Zonder modulaire architectuur is CPQ een constraint-programmeerproject.

Ander risico

CPQ zonder CTO bouwt technische schuld op: constraint-explosie, developer-afhankelijkheid, 40% hogere onderhoudskosten. CTO elimineert deze risico's structureel.

Andere ROI

Modularisatie levert 842% ROI, 64% doorlooptijdreductie, 50× meer configuraties. CPQ alleen raakt alleen de offerte — niet de kern.

Eerst modulariteit. Configuratie volgt.

Wij zijn geen betere CPQ. Wij maken CTO mogelijk — waardoor CPQ triviaal wordt. Het platform begint waar anderen stoppen: bij de productarchitectuur. Onze Modularity-First methodologie combineert 50+ jaar bewezen modulariteitsexpertise met software — zodat uw organisatie in 90 dagen de eerste waarde realiseert, niet na 18 maanden.

Academische bronnen

Hvam, L., Mortensen, N.H. & Riis, J. (2008). Product Customization. Springer Berlin Heidelberg.

Pine, B.J. II (1993). Mass Customization: The New Frontier in Business Competition. Harvard Business School Press.

Salvador, F., de Holan, P.M. & Piller, F.T. (2009). Cracking the Code of Mass Customization. MIT Sloan Management Review, 50(3), 71–78.

Felfernig, A., Hotz, L., Bagley, C. & Tiihonen, J. (2014). Knowledge-Based Configuration. Morgan Kaufmann.

Mittal, S. & Frayman, F. (1989). Towards a Generic Model of Configuration Tasks. IJCAI, Vol. 2, 1395–1401.

Kristjansdottir, K. et al. (2018). Return on investment from the use of product configuration systems. Computers in Industry, 100, 57–69.

Haug, A., Shafiee, S. & Hvam, L. (2019). The costs and benefits of product configuration projects in ETO companies. Computers in Industry, 105, 133–142.

Hvam, L. et al. (2013). Observed benefits from product configuration systems. Int. J. Industrial Engineering, 20(5–6), 329–338.

Harlou, U. (2006). Developing product families based on architectures. DTU PhD thesis.

Bredahl Rasmussen, J. et al. (2018). Cost of Not Maintaining a Product Configuration System. IJIEM, 10(1).

Forza, C. & Salvador, F. (2007). Product Information Management for Mass Customization. Palgrave Macmillan.

Wyrwich, C. et al. (2020). Model-Based Product Configuration of High Variety Product Portfolios. Proceedings of the Design Society, 1, 2435–2444.

Industriebronnen

Gartner IT Glossary — CPQ Application Suites.

McKinsey (2019). Platforming and modularity: Smart answers to ever-increasing complexity.

Modular Management — CommScope Case Study: Accelerated Product Configurations.

Panorama Consulting — Is A CPQ Failed Implementation On Your Horizon?

Cincom (2024). The Hidden Costs of Delaying a Legacy CPQ Replacement.

Tacton — Constraint-Based vs. Rules-Based Configuration.

CPQ-Pro — Understanding the Difference Between ETO and CPQ.