"We hebben een complex product met veel varianten. Dit gaan we configureren."
Ik kom in de praktijk regelmatig configurators tegen die vanuit die gedachte zijn gebouwd.
U herkent ze aan de lange vragenlijst. Vraag na vraag. Keuze na keuze. En soms ziet u dat zelfs een ervaren productspecialist moeite heeft om alle vragen goed te beantwoorden. Niet omdat hij het product niet kent. Maar omdat hij zich afvraagt: waarom moet ik dit eigenlijk allemaal invullen?
Dat vind ik interessant. Want wat u dan eigenlijk aan het doen bent, is de complexiteit van engineering vertalen naar een configurator. Alle regels erin. Alle uitzonderingen erin. Alle afhankelijkheden erin. En vervolgens verwachten dat sales of een productspecialist daarmee een goede configuratie kan maken.
Maar is dat wel het doel?
Volgens mij begint een goed CPQ-traject ergens anders. Niet met de vraag: "Hoe kunnen we dit complexe product configureren?" Maar met: "Welke varianten verkopen we morgen daadwerkelijk?" En: "Welke opties staan er eigenlijk alleen maar bij, maar worden zelden gekozen of leveren vooral discussie op?"
Dat is de stap van Engineering-to-Order naar Configure-to-Order: eerst het product simpeler maken, voordat u het configureert.
"Niet de engineer digitaliseren, maar het product zo organiseren dat u hem minder vaak nodig heeft voor losse projecten."
Bij een klant waar ik aan werkte, bleek uit de historische offertes dat ongeveer 80% van de configuraties met een beperkt aantal standaardmodules kon worden opgebouwd. Die 80% hebben we gestandaardiseerd. Een deel van de resterende opties bleek bovendien, door ze net iets anders te ontwerpen, geschikt te maken voor meerdere toepassingen tegelijk — waardoor het aantal varianten verder terugliep. De overige 20% bleef bewust maatwerk.
Het resultaat: voor die 80% werd de engineeringtijd meer dan tien keer zo kort. Lees de volledige case →
En engineering verdween niet. Die schoof op: van het uitwerken van losse projecten naar het bouwen van die standaardmodules zelf.
Dat is geen kleine verbetering. Dat is een ander bedrijfsmodel voor uw offertetraject. Daar begint wat mij betreft de echte stap van ETO naar CTO: niet de engineer digitaliseren, maar het product zo organiseren dat u hem minder vaak nodig heeft voor losse projecten — en meer voor het bouwen van standaarden.
Herkent u dit vanuit sales: dat u twijfelt bij een vraag in de configurator, omdat u niet weet wat de impact van uw keuze is? En werkt u zelf al met een CPQ-systeem: wordt bij u eerst het product vereenvoudigd, of wordt de complexiteit van engineering rechtstreeks in de configurator gebouwd?