Een formule begint in een spreadsheet. Een paar componentkeuzes komen in iLogic. Sales krijgt eigen regels in CPQ. Productie maakt nog een tabel omdat de eerste drie systemen niet bevatten wat de werkplaats nodig heeft.
Geen van die keuzes is automatisch fout. Het probleem begint wanneer dezelfde productregel op verschillende plaatsen bestaat en elke versie net iets anders betekent.
Ik denk niet dat er één systeem is dat alle productlogica moet bezitten. Ik denk wel dat elk soort kennis een duidelijke thuis nodig heeft.
CAD is goed in geometrische en modelspecifieke logica
CAD is vaak de meest natuurlijke plaats voor logica die alleen binnen het technische model betekenis heeft.
Een maat kan afhangen van een andere maat. Een component kan onderdrukt worden wanneer een samenstelling te smal wordt. Een gatenpatroon kan de lengte van een plaat volgen. Een tekening kan veranderen wanneer een optie aanwezig is.
Autodesk Inventor en iLogic zijn daar heel praktisch voor omdat de logica dicht bij de geometrie zit die ze bestuurt.
Dat wordt minder interessant wanneer een rule niet meer alleen over geometrie gaat.
Als dezelfde materiaalkeuze ook prijs, levertijd, beschikbare opties en productieroute beïnvloedt, maak je het hele proces afhankelijk van het CAD-model wanneer die kennis alleen daar zit.
Op dat moment beschrijft de rule het product, niet alleen het model.
CPQ is goed in productgeldigheid en commerciële keuzes
Een configurator moet weten welk product verkocht kan worden.
Daar horen beschikbare opties, geldige combinaties, afhankelijkheden, commerciële verpakkingen en soms pricing bij. Constraint-based CPQ kan ook technische relaties tussen keuzes modelleren.
Dat maakt CPQ een logische plaats voor kennis zoals welke productvarianten aangeboden worden, welke waarden geldig zijn voor een parameter, welke combinaties technisch toegestaan zijn, welke optie een andere vereist of uitsluit en welke klantvereiste naar welke productkeuze leidt.
Maar CPQ moet daarom niet automatisch de plaats worden waar elke geometrische formule of elk fabricagedetail opnieuw gebouwd wordt.
Als een plooitoeslag, gedetailleerd gatenpatroon of Inventor-specifieke featuredefinitie alleen nodig is om geometrie te maken, kan die logica in de configurator stoppen het productmodel net minder duidelijk maken.
Eigen software wordt interessant aan de grenzen
Sommige productkennis past niet mooi binnen CAD of CPQ.
Een webconfigurator kan een lichte geometry engine nodig hebben. Een calculation service kan een technisch model moeten evalueren zonder CAD te openen. Een productiecontrole kan een geconfigureerd onderdeel tegen machinecapaciteit moeten toetsen. Een API kan dezelfde productdefinitie aan verschillende tools beschikbaar maken.
Daar wordt eigen engineering software voor mij interessant.
Niet omdat het doel is elk bestaand systeem te vervangen, maar omdat een kleine softwarelaag gedeelde productkennis een neutralere plaats kan geven.
De bron van waarheid is meestal niet één bestand
Er wordt vaak over een single source of truth gesproken alsof dat één database of één applicatie moet zijn.
Voor configureerbare technische producten vind ik dat te eenvoudig.
De nuttigere vraag is: welk systeem is voor welke betekenis autoritair?
CAD kan autoritair zijn voor exacte geometrie.
CPQ kan autoritair zijn voor aangeboden keuzes en configuratiegeldigheid.
ERP kan autoritair zijn voor vrijgegeven artikelnummers en commerciële stockdata.
Een manufacturing-capability service kan autoritair zijn voor wat een bepaalde fabriek of machine kan maken.
Het productmodel moet dan duidelijke relaties tussen die verantwoordelijkheden hebben.
Het doel is niet één gigantisch masterbestand. Het is één samenhangende definitie van het product zonder tegenstrijdig eigenaarschap.
Scheid productbetekenis van implementatiedetails
Een nuttige test is vragen of een rule nog betekenis heeft wanneer de implementatie verandert.
Neem bijvoorbeeld:
Een inox plaat dikker dan 4 mm kan niet op deze plooibank geplooid worden.
Dat is product- en manufacturingkennis. Ze blijft waar wanneer de geometrie in Inventor, een webkernel of een ander CAD-systeem opgebouwd wordt.
Vergelijk dat met:
Suppress de CAD-flange feature wanneer de front return uitgeschakeld is.
Dat is implementatielogica. Ze hoort dicht bij het Inventor-model omdat ze beschrijft hoe dat specifieke model het product realiseert.
De eerste rule mag niet verdwijnen wanneer CAD verandert.
De tweede hoeft waarschijnlijk niet gepromoveerd te worden tot bedrijfsbreed productmodel.
Dat onderscheid is voor mij één van de duidelijkste manieren om te beslissen waar logica thuishoort.
Productstructuur hoort boven geometrie
Daarom probeer ik productstructuur ook steeds meer van geometrie te scheiden.
Een component kan een poot, frame, afdekking, steun of werkblad zijn voor het exacte vlakken en randen heeft. Het kan een rol, materiaal, relaties, parameters en constraints hebben voor er één CAD-feature gegenereerd wordt.
Geometrie kan daarna uit die technische beschrijving afgeleid worden.
Zo kan dezelfde productdefinitie verschillende gebruikers voeden: configuratie, pricing, geometrie, stuklijstgeneratie of productiecontrole.
En je vermijdt dat CAD-featurenamen stilaan de taal van het product worden.
Hou commerciële en technische logica onderscheidbaar
Commerciële logica en technische logica komen vaak samen, maar zijn niet hetzelfde.
Een optie kan technisch mogelijk zijn maar in een bepaalde markt niet verkocht worden.
Een component kan maakbaar zijn maar deze maand commercieel niet beschikbaar.
Een product kan engineeringtechnisch geldig zijn maar toch een goedkeuring vragen omwille van marge of leveringsrisico.
Die verschillen zijn belangrijk omdat ze op een ander tempo veranderen en vaak een andere eigenaar hebben.
Ik hou ze daarom liever onderscheidbaar, ook wanneer één systeem ze allebei evalueert.
Een configurator blijft makkelijker onderhoudbaar wanneer duidelijk is of een keuze geblokkeerd wordt omdat het product niet gemaakt kan worden, omdat het bedrijf het niet wil verkopen, of omdat de order review nodig heeft.
Manufacturinglogica verdient een eigen plaats
Manufacturing is vaak de laatste plaats waar productlogica opnieuw gedupliceerd wordt.
Engineering definieert het product, maar de werkplaats houdt daarna eigen kennis bij over maximale lengtes, beschikbare processen, voorkeursstock, tooling of machinelimieten.
Een deel daarvan hoort rechtstreeks bij het product. Een ander deel hoort bij de fabriek.
Het belangrijke is dat de configurator die informatie kan gebruiken zonder te doen alsof zulke limieten permanente eigenschappen van het product zelf zijn.
Een plaat kan als product perfect geldig zijn maar in één werkplaats niet geplooid kunnen worden. Dat is een capability constraint en niet noodzakelijk een product constraint.
Dat onderscheid wordt belangrijk zodra hetzelfde product op verschillende sites gemaakt kan worden of wanneer machinecapaciteit verandert.
Een praktische opdeling
Voor het soort producten waar ik mee werk, denk ik steeds meer in lagen.
Productmodel beschrijft wat bestaat: structuur, componenten, parameters, materialen, relaties en technische intentie.
Configuratielogica beschrijft wat mag bestaan: domains, rules, constraints en geldige combinaties.
Commerciële logica beschrijft wat aangeboden mag worden: markten, prijzen, approvals en commerciële beschikbaarheid.
Geometry / CAD implementation beschrijft hoe een geldig product exacte geometrie, tekeningen en CAD-specifieke features wordt.
Manufacturing capability beschrijft wat een fabriek, proces of machine werkelijk kan produceren.
Output adapters beschrijven hoe het geconfigureerde product stuklijst, offerte, CAD, CNC-data of een andere downstream representatie wordt.
Die lagen hoeven geen aparte applicaties te zijn.
Ze hebben wel aparte betekenissen nodig.
De test die ik gebruik
Wanneer ik twijfel waar een stuk logica thuishoort, stel ik een paar vragen.
Beschrijft de rule het product, of alleen één CAD-implementatie?
Blijft de rule waar wanneer we van CAD-systeem veranderen?
Moet sales dit begrijpen?
Is manufacturing de eigenaar?
Kan dit per fabriek verschillen?
Is het commerciële policy of technische geldigheid?
Berekent het een waarde, beperkt het een keuze, of beschrijft het hoe output gegenereerd wordt?
Met die vragen wordt de grens meestal veel duidelijker.
Waarom dit belangrijk wordt
Een productconfigurator kan jaren werken met logica verspreid over CAD, CPQ, spreadsheets en code.
Het probleem is niet dat zo'n systeem meteen faalt.
Het probleem is dat elke toekomstige wijziging moeilijker te begrijpen wordt. Niemand weet nog zeker welke kopie van de rule autoritair is en elke integratie moet opnieuw een stuk van het product reconstrueren.
Voor mij is de betere richting niet alles blind centraliseren.
Het is productkennis expliciet genoeg maken zodat elk stuk een duidelijke eigenaar heeft en elk downstream systeem weet wat het ervan mag afleiden.
Dat is ook de architectuur waar ik in mijn eigen werk naartoe probeer te bouwen.