Voor mij begint dat één stap te laat.
Voor een bedrijf een product betrouwbaar kan configureren, moet eerst duidelijk zijn welk deel van de engineering werkelijk herhaalbaar is, hoe de productfamilie is opgebouwd en welke beslissingen nog echt bij engineering horen. De configurator komt daarna.
ETO en CTO zijn geen tegenpolen
Engineer-to-order is logisch wanneer een klantorder werkelijk nieuwe engineering vraagt. De vereisten kunnen de constructie, interfaces, afmetingen of prestaties zo sterk beïnvloeden dat een engineer een nieuwe oplossing moet uitwerken.
Configure-to-order vertrekt van een andere aanname. Het product heeft al een afgebakende ruimte van geldige varianten. Een klantorder kiest een punt binnen die ruimte in plaats van telkens een nieuw ontwerp vanaf nul te starten.
In de praktijk zitten veel technische producten ergens tussen die twee uitersten.
Een bedrijf kan een terugkerend machineplatform hebben maar voor elk project nog enkele interfaces uitwerken. Een deur kan uit een gekende productfamilie komen terwijl een zeldzame uitvoering nog manuele controle nodig heeft. Een procesinstallatie kan modules hergebruiken zonder ooit een volledig configureerbaar product te worden.
De nuttige vraag is daarom niet of een bedrijf ETO of CTO is.
Ze is: welke engineeringbeslissingen komen vaak genoeg terug om deel van het productmodel te worden?
Start met herhaalbare beslissingen, niet met software
Wanneer engineers gelijkaardige producten opnieuw en opnieuw opbouwen, hergebruiken ze meestal veel meer kennis dan je in de uiteindelijke CAD-bestanden ziet.
Ze weten welke modules samengaan, welke maten uit andere maten volgen, welk materiaal geldig is voor een bepaalde toepassing, wanneer een zwaarder profiel nodig is of welke optie een ander component doet wijzigen.
Een deel van die kennis zit misschien al in CAD-parameters of iLogic. Een ander deel leeft in spreadsheets, berekeningen, werkinstructies of gewoon in het hoofd van ervaren engineers.
Dat is de grondstof voor configure-to-order.
De eerste stap is herhaalbare productkennis scheiden van echte projectengineering. Als elke uitzondering in de configurator geduwd wordt, wordt het model moeilijk onderhoudbaar. Als te veel erbuiten blijft, doet de configurator weinig meer dan opties verzamelen.
De productfamilie komt voor de rules
Een veelgemaakte fout is te vroeg met rules beginnen.
Rules zijn nuttig, maar ze hebben iets stabiels nodig waarop ze werken. Ik probeer daarom eerst de structuur van de productfamilie te begrijpen: componenten, modules, eigenschappen, parameters en de mogelijke varianten van die structuur.
Pas daarna wordt het nuttig om de logica ertussen te beschrijven.
Een breedte kan het aantal steunen bepalen. Een brandvereiste kan materialen beperken. Een motorkeuze kan van het nodige koppel afhangen. Een plaat mag niet langer zijn dan wat de plooibank aankan.
Sommige van die relaties zijn berekeningen. Sommige zijn directionele rules. Andere werken beter als constraints die gewoon altijd geldig moeten blijven.
De precieze techniek is minder belangrijk dan de productkennis expliciet maken.
CAD automation is vaak een tussenstap
Bij veel bedrijven begint de eerste stap weg van pure ETO niet met CPQ.
Ze begint in CAD.
Een parametrisch Autodesk Inventor-model kan terugkerende maten en componentkeuzes al vastleggen. iLogic kan suppression, vervanging, tekeningsupdates en andere voorspelbare handelingen automatiseren. Daarmee kan je veel repetitieve engineering wegnemen zonder het commerciële proces meteen te veranderen.
Maar CAD automation en productconfiguratie lossen een ander deel van het probleem op.
CAD automation beantwoordt vooral: als deze parameters veranderen, hoe moet het model dan veranderen?
Productconfiguratie moet daarnaast beantwoorden: welke combinaties van parameters zijn toegelaten, en welk product stellen die keuzes voor?
Dat verschil wordt belangrijk zodra configuratie meer moet bedienen dan alleen de engineer die het CAD-model gebruikt.
Bepaal waar elk soort kennis thuishoort
Niet alle productlogica moet in één systeem geduwd worden.
Geometriespecifieke logica zit vaak natuurlijk in CAD of een geometry engine. Commerciële regels kunnen in CPQ thuishoren. Productgeldigheid kan in een constraint-model zitten. Productiebeperkingen kunnen uit de mogelijkheden van de werkplaats komen.
Het doel is niet één gigantische applicatie bouwen die alles bezit.
Het doel is vermijden dat dezelfde productkennis telkens opnieuw vertaald wordt tussen verkoop, engineering en productie.
Daarom kijk ik steeds meer naar het productmodel als centrum, met CAD, pricing, offerte en manufacturing als verschillende gebruikers van dezelfde onderliggende definitie.
Configure-to-order moet verder kunnen dan de offerte
Een product is niet klaar wanneer de configuratie geldig is.
Iemand moet het nog engineeren, bestellen en maken.
Om configure-to-order echt nuttig te maken, moet de configuratie technische output kunnen aandrijven: een stuklijst, CAD-geometrie, tekeningen, berekende maten of productiegegevens.
De case van Technics & Applications is daar een eenvoudig voorbeeld van. Een zwembadsvorm werd geconfigureerd, maar de bruikbare output liep door naar de berekende lengtes en volgorde van de individuele lamellen voor CNC-productie.
Inoxplus onderzoekt hetzelfde idee vanuit een andere richting. Productkeuzes, geometrie, prijs en offerte kunnen naar hetzelfde geconfigureerde werkblad verwijzen in plaats van elk een aparte versie van het product bij te houden.
Hoe dichter configuratie komt bij iets waar engineering en productie werkelijk mee verder kunnen, hoe minder kennis downstream opnieuw opgebouwd moet worden.
Wat moet engineer-to-order blijven?
Niet alles moet configureerbaar worden.
Sommige klantvereisten zijn werkelijk nieuw. Sommige producten worden te weinig verkocht om formele modellering terug te verdienen. Sommige beslissingen hangen af van context, judgement of engineeringanalyse die moeilijk tot stabiele logica te reduceren zijn.
Dat is geen mislukking van configuratie.
Een goed configure-to-order model heeft een grens. Binnen die grens kan het systeem een technisch geldige variant opleveren. Buiten die grens wordt de order opnieuw een engineeringtaak.
Die grens expliciet maken is veel gezonder dan doen alsof elke toekomstige uitzondering geautomatiseerd kan worden.
Een praktische evolutie
Ik zie de stap meestal als geleidelijk.
Eerst worden terugkerende engineeringbeslissingen zichtbaar. Daarna worden parameters en productstructuur bewuster opgebouwd. CAD automation haalt voorspelbaar modelwerk weg. Rules en constraints definiëren een stabiele configureerbare ruimte. Pas daarna wordt het logisch om sales, pricing, CAD, stuklijstgeneratie en manufacturing nauwer te verbinden.
Een bedrijf kan op elk van die stappen stoppen als het echte probleem daarmee al opgelost is.
Het doel is niet zoveel mogelijk automatiseren. Het is herhaalbaar werk naar een betrouwbaar model verschuiven zonder engineering judgement weg te automatiseren waar die nog waarde heeft.
Waarom dit mij interesseert
Ik ben via mechanisch ontwerp en parametrische CAD in productconfiguratie terechtgekomen.
Daardoor vind ik de stap van ETO naar CTO interessant omdat hij exact op de grens tussen engineering en software zit. Je lost hem niet alleen op door een CPQ-platform te kiezen, en ook niet alleen door het CAD-model slimmer te maken.
Je moet het product eerst goed genoeg begrijpen om te kunnen zeggen wat standaard is, wat mag variëren, wat geldig moet blijven en wat nog echte engineering verdient.
Eens dat duidelijk is, wordt de softwarekeuze veel eenvoudiger.