Een product dat eigenlijk een deel van een hele productfamilie is

Een industriële deur kan op veel meer punten verschillen dan alleen afmetingen.

De opbouw kan uit verschillende lagen en materialen bestaan. Brandvereisten beïnvloeden wat toegelaten is. Sloten kunnen zichtbaar of verborgen zijn. Frames kunnen in staal uitgevoerd worden. Sommige varianten hebben heel specifieke toepassingen, waaronder deuren voor gevangenisomgevingen.

Dat zijn geen onafhankelijke dropdowns. Een keuze in één deel van het product kan veranderen wat elders nog mogelijk is.

Het werk ging daarom minder over opties toevoegen en meer over een productfamilie beschrijven.

Het model moest eigenschappen, mogelijke waarden, productstructuur en de relaties ertussen voorstellen. Een materiaalkeuze kon een brandklasse beïnvloeden. Een type slot kon beperkingen opleggen aan de opbouw. Een framekeuze kon andere componenten afdwingen of uitsluiten.

Daar begint een productconfigurator meer op een engineeringmodel te lijken dan op een vragenlijst.

Ik werkte binnen het project als CPQ engineer, vooral aan de complexere deurstructuren in Tacton en Autodesk Inventor.

Tacton was de plaats waar configuratielogica en geldigheid uitgedrukt moesten worden. Inventor stelde de technische productstructuur en geometrie voor die uit die keuzes voortkwam. Mijn werk zat rond die grens: de constructie goed genoeg begrijpen om het configureerbare product te modelleren zonder het te reduceren tot een verzameling uitzonderingen.

Ik heb de stap naar productie niet meer meegemaakt. Daarom claim ik hier ook geen productieresultaat of downstream KPI die ik zelf niet gevolgd heb.

Je kan een complex product met directionele regels beschrijven, en voor veel relaties blijft dat de eenvoudigste oplossing.

De moeilijkheid begint wanneer verschillende selecties elkaar tegelijk beïnvloeden. Dan worden lange ketens van if/then-regels gevoelig voor uitvoeringsvolgorde en beginnen uitzonderingen zich op te stapelen.

Constraint-based configuratie stelt een andere vraag: welke eigenschappen bestaan er, welke domains zijn geldig en welke relaties moeten altijd waar blijven, ongeacht in welke volgorde de gebruiker keuzes maakt?

Dat was een belangrijke stap in hoe ik productconfiguratie ben gaan bekijken.

Een complexe configurator wordt niet onderhoudbaar door meer regels toe te voegen.

Hij wordt duidelijker wanneer het productmodel zelf duidelijker wordt: eerst structuur, daarna de logica die die structuur geldig houdt.

Dat idee komt vandaag opnieuw terug in mijn werk rond semantische productmodellen, CAD automation en configure-to-order systemen.