In 2008 betekende dat vooral: een product goed begrijpen, het correct modelleren en zorgen dat er bruikbare tekeningen uit kwamen. Dat lijkt misschien ver weg van productconfiguratie, maar voor mij ligt daar net de basis. Je leert er hoe een product echt opgebouwd is, welke maten belangrijk zijn en waar problemen pas zichtbaar worden wanneer iemand het stuk effectief moet maken.
Toen ik in 2012 als zelfstandige onder Kubuz begon, werkte ik onder andere aan trappen, bordessen, grootkeukenapparatuur en machines. Rond diezelfde periode begon ik ook veel serieuzer te kijken naar parametrisch modelleren en iLogic in Autodesk Inventor.
Dat was voor mij een belangrijk kantelpunt.
Niet omdat iLogic op zich magisch is, maar omdat CAD plots programmeerbaar werd.
Eerst automatiseer je een model
De eerste stap is meestal vrij eenvoudig.
Je hebt een bestaand model en je wil bepaalde maten automatisch laten volgen. Als de breedte verandert, moet een dwarsligger mee veranderen. Als de hoogte stijgt, worden de poten langer. Als een optie uit staat, verdwijnt een bepaald onderdeel. Dat soort automatisering geeft snel winst: je vermijdt repetitief werk en verkleint de kans dat iemand één maat vergeet aan te passen.
Maar in deze fase denk je nog vooral vanuit het CAD-model.
Het model bestaat al, en je maakt het slimmer.
Daarna merk je dat variatie zelf gemodelleerd moet worden
Bij eenvoudige producten kom je daar best ver mee.
Bij complexere producten merk je na een tijd dat niet elke variatie gewoon een andere maat is. Soms verandert de hele productstructuur. Een optie voegt een component toe, een materiaalkeuze beperkt beschikbare diktes en een bepaalde uitvoering vraagt een andere opbouw of productiemethode. Dan ben je niet meer alleen een model aan het automatiseren. Dan ben je eigenlijk de variatie van het product zelf aan het modelleren.
Voor mij is dat het moment waarop parametrische CAD begint over te gaan in productconfiguratie.
iLogic maakte dat verschil zichtbaar
Nog vóór mijn eerste echte configurator had ik daar al mee geëxperimenteerd in industrieel CAD-werk, onder andere bij AZO.
Daar merkte ik hoe krachtig het is wanneer regels rechtstreeks op een technisch model werken. Je kan parameters berekenen, onderdelen aan- en uitzetten, tekeningen sturen en verschillende uitvoeringen uit dezelfde basis laten ontstaan. Maar je merkt ook vrij snel waar de grens ligt. Als alle productkennis in losse iLogic-regels terechtkomt, wordt het model moeilijker leesbaar.
Dan duiken andere vragen op.
Waarom bestaat deze parameter? Welke keuze is echte input en welke maat is alleen een gevolg? Welke combinaties zijn geldig, en hoe weet je welke logica eerst moet lopen? Dat zijn eigenlijk geen zuivere CAD-vragen meer. Dat zijn vragen over het productmodel.
Rond 2019 werd het een echte configurator
Bij Technics & Applications bouwde ik rond 2019 mijn eerste echte productconfigurator in een industriële context.
Daar verschoof de focus heel duidelijk. Het ging niet meer alleen over het aanpassen van een model. De configurator moest keuzes begrijpen, berekeningen maken en uiteindelijk informatie opleveren die verder ging richting productie. Bij hun zwembadafdekkingen bepaalt de vorm van het zwembad bijvoorbeeld de lengte van elke afzonderlijke lamel. Bij bogen en afrondingen zijn die lengtes niet allemaal gelijk, en die informatie moet daarna ook bruikbaar zijn voor productie.
Op zo’n moment voel je dat een parameter in CAD niet genoeg meer is.
Je hebt productlogica nodig die begrijpt wat die parameter betekent en welke gevolgen eruit volgen.
Een configurator stelt andere vragen dan een CAD-model
Bij CAD denk je vaak in termen van geometrie.
Hoe lang is dit onderdeel? Waar ligt dit vlak? Hoeveel gaten zitten hierin? Welke componenten staan aan? Bij productconfiguratie komen daar andere vragen bovenop. Welke keuzes mag de gebruiker maken? Welke combinaties zijn geldig? Wat is invoer en wat is afgeleid? Welke informatie moet naar pricing, engineering of productie?
Het CAD-model blijft belangrijk, maar het is niet meer het volledige systeem.
Tacton veranderde opnieuw mijn manier van kijken
Toen ik in 2023 met Tacton en constraint-based CPQ begon te werken, werd dat onderscheid nog scherper.
Tot dan dacht ik sterk in regels en afhankelijkheden: als A gebeurt, zet B. Dat werkt goed en ik gebruik het nog altijd. Maar bij zeer configureerbare producten kan die logica snel een groot netwerk worden. In de deurenconfiguratie waar ik aan werkte, konden opbouw, materiaal, brandvereisten, sloten, staalframes en verschillende deurtypes elkaar allemaal beïnvloeden.
Constraint-based configuratie dwingt je dan om minder te denken in uitvoeringsvolgorde en meer in relaties die tegelijk geldig moeten blijven.
Dat bracht mij opnieuw een stap verder weg van “een slim CAD-model” en dichter bij “een model van het product zelf”.
Parametrische CAD is dus niet hetzelfde als CPQ
Die twee worden soms makkelijk door elkaar gehaald, omdat ze allebei varianten kunnen maken.
Toch vertrekken ze vanuit iets anders. Een parametrisch CAD-model zegt vooral: als deze parameters veranderen, hoe verandert de geometrie? Een productconfigurator moet daarnaast ook kunnen beschrijven welke configuraties bestaan, welke combinaties geldig zijn en wat een keuze betekent voor de rest van het product.
Dat verschil wordt groter naarmate het product complexer wordt.
Een tafel met drie afmetingen kan bijna volledig in CAD leven. Een machinefamilie met verschillende modules, motoren, materialen, veiligheidsopties en productiemethodes heeft een veel explicieter productmodel nodig.
CAD blijft wel een belangrijke basis
Ik zie productconfiguratie daarom niet als iets dat CAD vervangt.
Mijn voordeel is net dat ik beide kanten ken. Als je zelf mechanisch ontwerpt, voel je sneller waar een configurator te simplistisch wordt. Een product is niet alleen een dropdown met opties. Een keuze kan betekenen dat een plaat anders geplooid moet worden, dat een profiel niet meer past of dat een tekening anders opgebouwd moet worden. Dat soort dingen gaan makkelijk verloren wanneer configuratie alleen vanuit software of sales bekeken wordt.
Andersom helpt softwaredenken ook om CAD beter te structureren. Je gaat explicieter nadenken over inputs, afhankelijkheden, interfaces en herbruikbare componenten.
Waar ik vandaag het verschil leg
Ik probeer tegenwoordig drie dingen uit elkaar te houden.
Het productmodel beschrijft wat het product is: structuur, parameters, domains, regels, constraints, materialen en relaties. De engineeringlogica berekent wat daaruit volgt. En CAD of een geometry kernel maakt er uiteindelijk de exacte geometrie en technische output van.
Voor eenvoudige automatisering mogen die drie gerust dicht bij elkaar zitten. Ik wil geen architectuur bouwen omdat het kan. Maar zodra een configurator groter wordt, helpt die scheiding enorm.
Ze maakt ook duidelijk waarom mijn werk zo natuurlijk van CAD naar configuratie en software is verschoven.
Voor mij was dat nooit echt een overstap naar een andere wereld.
Het was telkens dezelfde vraag, maar op een hoger niveau:
hoe leg je genoeg kennis over een product vast zodat je niet elke variant opnieuw moet ontwerpen?