Regelbaseret produktkonfiguration
Gør regnearkslogik og tavs viden til en visuel regelmotor. Hvert tilbud følger de samme kompatibilitetsregler fra forespørgsel til godkendelse.
Rules engine · session
Industrial pump line
Region
Active logic
- R-088 · IF power > 5kW → Cooling = required
- R-112 · IF region = EU → Voltage = 400V
- R-140 · LOOKUP power + duty → Frame F-240
- R-144 · IF outdoor → Enclosure = IP65
- R-201 · IF outdoor → Heater = Added
- R-240 · IF outdoor → Indoor Panel = Hidden
Rule trace
Selected: Outdoor
- R-144 Enclosure = IP65
- R-201 Heater = Added
- R-240 Indoor Panel = Hidden
Cooling
Required
Voltage
400V
Frame
F-240
Enclosure
IP65
Hvad dette styrer
Hvert trin
Kompatibilitet ved hvert valg
Ét regelsæt
Samme logik for direkte salg og kanal
Før tilbud
Ugyldige kombinationer filtreres under konfiguration
Udfordringen
Produktregler sidder i hovederne, ikke i tilbudsflowet
Sælgerne kender kataloget, men den reelle logik ligger i applikationsguider, Excel-ark og hos få senioringeniører. Hver kompleks forespørgsel bliver en tråd: passer denne motor til det hus?, er denne overflade ok i food-zone?, gælder denne rabat på den option?
Inside sales sender konfigurationer til applications engineering for godkendelse. Forhandlere arbejder ud fra gamle prislister og hukommelse. Når nogen opdager en inkompatibel kombination, ligger tilbuddet hos kunden eller ordren i produktionen.
Regnearks-konfiguratorer knækker, når I tilføjer en produktlinje eller et nyt marked. Træning skalerer ikke: hvert launch betyder nye slides og flere eskaleringer. Tilbudsprocessen bliver langsommere, selvom engineering allerede har frigivet optionerne.
Flaskehalsen er ikke manglende produktdetaljer. Det er, at kompatibilitetslogik ikke håndhæves, hvor tilbud bygges: i konfiguratoren, i forhandlerportalen, i selve valget.
Sådan fungerer det
Sådan anvender Mercura regler under konfiguration
Produkt- og operationsteams modellerer logik i Mercuras visuelle regel-editor: IF/THEN-betingelser, obligatoriske optioner, gensidige udelukkelser og dynamiske filtre pr. valg. Inkompatible valg forsvinder, obligatoriske linjer tilføjes, pris genberegnes mod samme regelsæt. Ingen separat validering før tilbuddet. Når engineering opdaterer en regel, gælder den i alle kanaler med det produktmodel. Målet er ikke at erstatte teknisk skøn på særlige forespørgsler, men at holde rutinetilbud ude af engineering-køen.
Rule pipeline
Orchestration across every logic type
Hvad er inkluderet
Hvad I modellerer i regelmotoren
Orchestrate
- Visuel IF/THEN uden custom code
- Vis, skjul eller kræv optioner ud fra tidligere valg
Evaluate
- Gensidige udelukkelser mellem materiale, tryk og overflade
- Obligatoriske tillæg ved valgt basisoption
Act
- Regelsæt delt på tværs af familier og revisioner
- Versionshistorik ved katalogændringer
Output
- Samme regler i inside sales, forhandlerportal og embedded configurator
- Supplerer constraint- og afhængighedslogik
Forskellen
Tilbud før og efter kodede regler
Regler i regneark og hukommelse
- 01 Kompatibilitet tjekkes manuelt på komplekse tilbud
- 02 Applications engineering på kopi ved rutine
- 03 Forhandlere tilbyder kombinationer der fejler ved ordre
- 04 Nye optioner betyder træning, ikke regelopdatering
- 05 Fejl ses efter kunden har PDF'en
Med Mercura
- 01 Logik håndhæves ved hvert konfigurationstrin
- 02 Standardkonfigurationer uden engineering-godkendelse
- 03 Sælgere og forhandlere deler ét vedligeholdt regelsæt
- 04 Katalogændringer som regelopdatering, ikke mailbølger
- 05 Ugyldige stier fjernes før pris og godkendelse
Forretningseffekt
Hvorfor kode regler i CPQ
Regelbaseret konfiguration gør ekspertviden tilbudsgivbar i skala. Det er laget, der holder salget i gang på logik engineering allerede har defineret. Det erstatter ikke CAD, PLM eller strukturberegning på one-offs. Regler kræver ejerskab: ændrer kataloget sig, skal modellen opdateres. Teams der vedligeholder logikken centralt, ser færre sene rettelser, mindre støj i applications engineering og forhandlere der tilbyder inden for klare rammer.
Business impact
Centralized product knowledge
IF/THEN, lookups, dependencies, and constraints in one engine.
Scalable sales execution
Same ruleset for direct sales and dealers.
Consistent validation
Every selection re-evaluates before the quote leaves.
Compare
Rules engine vs one relationship type
RULE ENGINE
umbrella orchestration layer
- ├─ Dependencies
- ├─ Constraints
- ├─ Lookups
- ├─ Set values
- ├─ Hide / show
- └─ Formulas
Dependency
One relationship type · A → B changes
Constraint
One validation type · A+B invalid
Konfigurationskort
Produktdefinition → regelorkestrering → kommerciel pakning → gyldig konfiguration, pris og stykliste
Produktdefinition
Logik
Kommerciel pakning
Output
Gyldig konfiguration · Pris · Stykliste
Valid rule trace · BOM updated
Se produktregler under konfiguration
Book en demo og gå igennem, hvordan Mercura IF/THEN-logik sættes op for inside sales og kanal.
Lad os konfigurere sammen.
Vi giver virksomheder mulighed for at lave produktmodellering, strømline tilbudsprocessen, reducere fejl og i sidste ende levere de skræddersyede løsninger, som kunderne efterspørger.