Sistema CPQ manutenibile
SI ha firmato diciotto mesi fa. Nessuno interno spiega perché regola nesting blocca dealer tier-two.
Maintainable · architecture
Structured reuse · not spaghetti rules
Pump Family A ├─ Attributes ├─ Components ├─ Dependencies ├─ Constraints ├─ Pricing └─ Outputs
Reusable sets
Motor Rule Set
used by Pump A · Pump B · Pump C
Regional Pricing
used by EU · UK · US
La sfida
SI ha firmato diciotto mesi fa. Nessuno interno spiega perché regola nesting blocca dealer tier-two.
Un OEM macchine finitura tessile vende telai stenter, linee termofissazione e moduli larghezza via dealer tier-one e tier-two. Partner implementazione consegnò CPQ in tempo e slide passaggio. Fine contratto, product ops ereditò set regole da script custom annidati e notazione che solo team SI capiva.
Product manager devono regolare bande larghezza quando esce nuova linea tessuto. Aprono console admin, trovano nomi regola fuori linguaggio catalogo e si fermano perché piccola edit ruppe preventivi intera regione. Workaround si accumulano in fogli. Vendita non chiede più fix CPQ. Configurator deriva da catalogo che fabbrica spedisce realmente.
Pagine CPQ low-code centrano team business che pubblicano cambi regola senza ticket dev. Pagine config self-maintained riducono dipendenza vendor su update routine. Pagine integrazione coprono REST, SDK e sandbox. Sistema CPQ manutenibile differisce: Mercura progettato perché chi possiede catalogo post go-live legga, spieghi e evolva regole anni dopo senza black box proprietarie né progetti reimplementazione programmati.
Richiesta → config → prezzo → approvazione → ordine non deve dipendere da consulenti usciti mentre portfolio cambia ogni stagione.
Regole leggibili
Logica IF/THEN senza script per product manager
Intent documentato
Note cambio spiegano perché esistono vincoli
Traccia versioni
Nuove assunzioni vedono come logica evolvette
Come funziona
Come Mercura mantiene CPQ manutenibile dopo fine implementazione
Regole config e prezzo usano strutture IF/THEN esplicite con selettori attributi invece script proprietari annidati. Autori allegano note cambio con intent business su ogni vincolo. Storico versioni mostra chi cambiò cosa quando così nuovi product manager tracciano decisioni senza intervistare ex-consulenti. Regole raggruppate per famiglia prodotto mantengono logica stenter, termofissazione e moduli navigabile quando catalogo cresce. Staging testa edit prima che dealer le vedano. Governance e workflow approvazione possono gate publish mentre manutenzione quotidiana resta su product ops. Mercura non rimuove pensiero catalogo o audit regole periodici; rimuove interpreti specialisti per ogni aggiustamento banda larghezza.
Structure
Spaghetti vs maintainable model
Before
Rule A → Rule B → Rule C → Rule D
duplicated across products
- · copied rules
- · hidden dependencies
- · tribal knowledge
- · unclear ownership
Maintainable
Product family
↓ reusable rule sets
- · shared pricing
- · shared constraints
- · shared modules
- · clear ownership
Validation
Representative configurations before publish
Staging preview · documented in current product copy · illustrative outcomes
1 regression found · review before publish
Lifecycle
Build · own · maintain
Cosa include
Cosa copre sistema CPQ manutenibile
Structure
- Strutture IF/THEN piatte leggibili product manager
- Raggruppamento famiglia prodotto scala con ampiezza catalogo
Reuse
- Con governance, controllo versioni e autoria low-code
Trace
- Note cambio in-rule documentano intent e contesto business
- Storico versioni completo logica config e prezzo
- Export logica config per archivi ingegneria
Change
- Ambiente staging valida edit prima publish produzione
- Complessità incrementale: vincoli solo dove prodotto richiede
La differenza
Ownership CPQ prima e dopo design manutenibile
Black box SI
- 01 Logica regole leggibile solo partner implementazione originale
- 02 Team interno evita edit perché conseguenze sembrano imprevedibili
- 03 Workaround foglio sostituiscono update configurator
- 04 Deriva catalogo finché reimplementazione ri-discussa
- 05 Conoscenza istituzionale esce quando consulenti ruotano
Con Mercura
- 01 Product ops legge e spiega vincoli senza training script
- 02 Staging e validazione rendono edit routine prevedibili
- 03 Note cambio e storico onboardano nuovi maintainer più veloce
- 04 Set regole evolvono con cambi catalogo stagionali
- 05 CPQ resta operabile anni dopo fine contratto SI
Applicazione reale
Esempio: regola larghezza stenter dopo passaggio SI
Before
- Copied rules
- Hidden nesting
- Tribal knowledge
Change
- Flat IF/THEN models
- Shared rule sets
- Change notes + versions
After
- Team can explain rules
- Safe edits years later
OEM telai stenter, forni termofissazione e moduli larghezza tessuto via dealer tier-one e tier-two. Dopo uscita partner, dealer tier-two segnalarono vincolo nesting bloccava combinazioni larghezza valide indecifrabili. Product management migrò regole Mercura, ricostruì famiglia stenter IF/THEN piatto e note per banda larghezza, usò storico versioni vs export legacy. Preventivi tier-two ripresero dopo validazione staging. Stesso team product ops mantenne regole termofissazione e moduli su due refresh catalogo senza riaprire richiesta cambio SI.
Impatto sul business
Perché manutenibilità separa asset CPQ da passivo CPQ
Sistema CPQ manutenibile cattura valore su anni cambio catalogo, non solo a go-live. Completa autoria low-code, operazione self-maintained, controllo versioni e governance. Mercura non sostituisce documentazione prodotto fuori CPQ o review architettura enterprise. Qualcuno deve tenere igiene regole e ritirare vincoli obsoleti. Se dolore è «abbiamo paura toccare regole SI», strutture leggibili e storico documentato allineano richiesta, config, prezzo, approvazione e ordine con sistema che team porta dopo uscita implementatore.
Business impact
Lower configuration debt
Reusable rule sets replace duplicated copy-paste logic.
Safer change
Structure, notes, and version history keep intent visible.
Easier onboarding
New hires can read IF/THEN logic without tribal scripts.
Compare
Low-code vs maintainable
Low-Code
Makes change easier to implement
Create rule
Maintainable
Makes accumulated change easier to understand over time
1000 rules → structured architecture
Compare
Self-maintained vs maintainable
Self-Maintained
Ownership question
Can our own team operate this?
Maintainable
Complexity question
Will the system still be understandable in three years?
Mappa di implementazione
Build with low-code tooling → own day-to-day changes → keep the system maintainable as complexity grows
Build
CPQ low-code
Operate
Configurazione prodotto self-maintained
Scale over time
Sistema CPQ manutenibile
Surrounded by governance · version control · audit · access control
Reusable model · structure intact
Veda product ops leggere, spiegare e aggiornare regole che SI non portò via
Prenoti demo e percorra leggibilità regole, note cambio, storico versioni e staging con team che possiederà CPQ post implementazione.
Parliamo del vostro progetto.
Aiutiamo i produttori a gestire al meglio la modellazione dei prodotti, semplificare il processo di preventivazione, ridurre gli errori e, infine, offrire ai clienti soluzioni su misura.