Regelbaserad produktkonfiguration
Gör kalkylbladslogik och tyst kunskap till en visuell regelmotor. Varje offert följer samma kompatibilitetsregler från förfrågan till godkännande.
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
Vad detta styr
Varje steg
Kompatibilitet vid varje val
Ett regelverk
Samma logik för direktförsäljning och kanal
Före offert
Ogiltiga kombinationer filtreras vid konfiguration
Utmaningen
Produktregler sitter i huvudet, inte i offertflödet
Era säljare känner katalogen, men den verkliga logiken ligger i applikationsguider, Excel-ark och hos några seniora ingenjörer. Varje komplex förfrågan blir en tråd: passar den här motorn till det huset?, är den här ytbehandlingen ok i food-zon?, gäller den här rabatten på det valet?
Inside sales skickar konfigurationer till applications engineering för godkännande. Återförsäljare jobbar med gamla prislistor och minne. När någon ser en inkompatibel kombination ligger offerten redan hos kunden eller ordern i produktionen.
Kalkylblads-konfiguratorer brister när ni lägger till en produktlinje eller ny marknad. Utbildning skalar inte: varje lansering innebär nya presentationer och fler eskaleringar. Offertprocessen blir långsammare trots att engineering redan släppt optionerna.
Flaskhalsen är inte brist på produktdetaljer. Det är att kompatibilitetslogik inte verkställs där offerter byggs: i konfiguratorn, i återförsäljarportalen, i själva valet.
Så här fungerar det
Så tillämpar Mercura regler under konfiguration
Produkt- och operationsteam modellerar logik i Mercuras visuella regel-editor: IF/THEN-villkor, obligatoriska val, ömsesidiga uteslutningar och dynamiska filter per val. Inkompatibla val försvinner, obligatoriska rader tillkommer, pris räknas om mot samma regelverk. Inget separat valideringssteg före offerten. När engineering uppdaterar en regel gäller den i varje kanal som använder produktmodellen. Målet är inte att ersätta tekniskt omdöme på unika förfrågningar, utan att hålla rutinofferter utanför engineering-kön.
Rule pipeline
Orchestration across every logic type
Vad som ingår
Vad ni modellerar i regelmotorn
Orchestrate
- Visuell IF/THEN utan custom code
- Visa, dölj eller kräv val utifrån tidigare val
Evaluate
- Ömsesidiga uteslutningar mellan material, tryck och ytbehandling
- Obligatoriska tillägg vid vald basoption
Act
- Regelverk delat över familjer och revisioner
- Versionshistorik vid katalogändringar
Output
- Samma regler i inside sales, återförsäljarportal och inbäddad configurator
- Kompletterar constraint- och beroendelogik
Skillnaden
Offert före och efter kodade regler
Regler i kalkylark och minne
- 01 Kompatibilitet manuellt på komplexa offerter
- 02 Applications engineering på kopia vid rutin
- 03 Återförsäljare offertar kombinationer som faller vid order
- 04 Nya val innebär utbildning, inte regeluppdatering
- 05 Fel syns efter att kunden har PDF:en
Med Mercura
- 01 Logik verkställs vid varje konfigurationssteg
- 02 Standardkonfigurationer utan engineering-godkännande
- 03 Säljare och återförsäljare delar ett underhållet regelverk
- 04 Katalogändringar som regeluppdatering, inte mailvågor
- 05 Ogiltiga vägar bort före pris och godkännande
Affärspåverkan
Varför koda regler i CPQ
Regelbaserad konfiguration gör expertkunskap offertbar i skala. Det är lagret som håller försäljningen i rörelse på logik engineering redan definierat. Det ersätter inte CAD, PLM eller strukturberäkning på one-offs. Regler kräver ägare: ändras katalogen måste modellen uppdateras. Team som underhåller logiken centralt ser färre sena rättningar, mindre brus i applications engineering och återförsäljare som offertar inom tydliga ramar.
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
Konfigurationskarta
Produktdefinition → regelorkestrering → kommersiell paketering → giltig konfiguration, pris och stycklista
Produktdefinition
Logik
Kommersiell paketering
Utdata
Giltig konfiguration · Pris · Stycklista
Valid rule trace · BOM updated
Se produktregler under konfiguration
Boka en demo och gå igenom hur Mercura kodar IF/THEN-logik för inside sales och kanal.
Låt oss bygga tillsammans.
Vi hjälper tillverkare att bemästra produktmodellering, effektivisera offertprocessen, minska fel och leverera skräddarsydda lösningar som kunderna kräver.