Wartbares CPQ-System
SI unterschrieb vor achtzehn Monaten ab. Niemand intern kann erklären warum Nesting-Regel Tier-Two-Händler blockiert.
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
Die Herausforderung
SI unterschrieb vor achtzehn Monaten ab. Niemand intern kann erklären warum Nesting-Regel Tier-Two-Händler blockiert.
Ein OEM für Textil-Finishing-Maschinen verkauft Stenter-Rahmen, Fixieranlagen und Breitenmodule über Tier-One- und Tier-Two-Händler. Implementierungspartner lieferte CPQ planmäßig und übergab Folien. Nach Vertragsende erbte Product Ops Regelsätze aus verschachtelten Custom-Skripten und Kurznotation nur das SI-Team verstand.
Product Manager müssen Breitenbänder anpassen wenn neue Stofflinie startet. Sie öffnen Admin-Konsole, finden Regelnamen die nicht zur Katalogsprache passen und stoppen weil kleine Edit einmal Angebote einer ganzen Region brach. Workarounds stapeln sich in Spreadsheets. Vertrieb fordert keine CPQ-Fixes mehr. Configurator driftet vom Katalog den Fabrik tatsächlich liefert.
Low-Code-CPQ-Seiten fokussieren Business-Teams die Regeländerungen ohne Entwickler-Tickets publizieren. Self-maintained-Seiten reduzieren Vendor-Abhängigkeit für Routine-Updates. Integrationsseiten decken REST, SDK und Sandbox ab. Wartbares CPQ-System ist anders: Mercura ist so architektiert dass wer Katalog nach Go-live besitzt Regeln Jahre später lesen, erklären und evolvieren kann ohne proprietäre Black Boxes oder geplante Re-Implementierungsprojekte.
Anfrage → Konfiguration → Preis → Freigabe → Auftrag soll nicht von Consultancies abhängen die gingen während Portfolio sich jede Saison ändert.
Lesbare Regeln
IF/THEN-Logik ohne Skripte für Product Manager
Dokumentierte Absicht
Änderungsnotizen erklären warum Constraints existieren
Versionspfad
Neue Mitarbeiter sehen wie Logik evolvierte
So funktioniert es
So hält Mercura CPQ wartbar nach Implementierungsende
Konfigurations- und Preisregeln nutzen explizite IF/THEN-Strukturen mit Attribut-Selektoren statt verschachtelter proprietärer Skripte. Autoren hängen Änderungsnotizen mit Business-Intent an jede Constraint. Versionshistorie zeigt wer was wann änderte damit neue Product Manager Entscheidungen nachverfolgen ohne Ex-Consultants zu befragen. Regeln gruppiert nach Produktfamilie halten Stenter-, Fixier- und Modul-Logik navigierbar wenn Katalog wächst. Staging testet Edits bevor Händler sie sehen. Governance und Freigabe-Workflows können Publish gaten während Alltags-Wartung bei Product Ops bleibt. Mercura entfernt nicht Katalog-Denken oder periodische Regel-Audits; es entfernt Spezial-Interpreter für jede Breitenband-Anpassung.
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
Im Lieferumfang enthalten
Was wartbares CPQ-System abdeckt
Structure
- Flache IF/THEN-Regelstrukturen lesbar für Product Manager
- Produktfamilien-Gruppierung skaliert mit Katalogbreite
Reuse
- Mit Governance, Versionskontrolle und Low-Code-Autorenschaft
Trace
- In-Rule-Änderungsnotizen mit Business-Intent und Kontext
- Vollständige Versionshistorie für Konfigurations- und Preislogik
- Export der Konfigurationslogik für Engineering-Akten
Change
- Staging-Umgebung validiert Edits vor Produktions-Publish
- Inkrementelle Komplexität: Constraints nur wo Produkt es braucht
Der Unterschied
CPQ-Ownership vor und nach wartbarem Design
SI-Black-Box
- 01 Regellogik nur für ursprünglichen Implementierungspartner lesbar
- 02 Internes Team vermeidet Edits weil Folgen unvorhersehbar wirken
- 03 Spreadsheet-Workarounds ersetzen Configurator-Updates
- 04 Katalog-Drift bis Re-Implementierung wieder diskutiert wird
- 05 Institutionswissen geht wenn Consultants rotieren
Mit Mercura
- 01 Product Ops liest und erklärt Constraints ohne Skript-Schulung
- 02 Staging und Validierung machen Routine-Edits vorhersehbar
- 03 Änderungsnotizen und Historie onboarden neue Maintainer schneller
- 04 Regelsätze evolvieren mit saisonalen Katalogänderungen
- 05 CPQ bleibt operabel Jahre nach SI-Vertragsende
Praxisbeispiel
Beispiel: Stenter-Breitenregel nach SI-Übergabe
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 Stenter-Rahmen, Fixieröfen und Stoffbreitenmodule über Tier-One- und Tier-Two-Händler. Nach Partner-Abgang meldeten Tier-Two-Händler Nesting-Constraint blockiere gültige Breitenkombinationen die niemand decodieren konnte. Product Management migrierte Regeln zu Mercura, baute Stenter-Familie mit flachem IF/THEN und Notizen je Breitenband, nutzte Versionshistorie gegen Legacy-Export. Tier-Two-Angebote nahmen nach Staging-Validierung wieder auf. Dasselbe Product-Ops-Team pflegte Fixier- und Modulregeln durch zwei Katalog-Refreshs ohne SI-Change-Request.
Geschäftlicher Nutzen
Warum Wartbarkeit CPQ-Asset von CPQ-Passiva trennt
Wartbares CPQ-System fängt Wert über Jahre Katalogwandel, nicht nur bei Go-live. Ergänzt Low-Code-Autorenschaft, self-maintained Betrieb, Versionskontrolle und Governance. Mercura ersetzt nicht Produktdokumentation außerhalb CPQ oder Enterprise-Architektur-Review. Jemand muss Regel-Hygiene halten und obsolete Constraints retiren. Wenn Schmerz ist "wir trauen uns nicht SI-Regeln anzufassen", bringen lesbare Strukturen und dokumentierte Historie Anfrage, Konfiguration, Preis, Freigabe und Auftrag mit System in Einklang das Ihr Team nach Implementierer-Abgang trägt.
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?
Implementierungskarte
Build with low-code tooling → own day-to-day changes → keep the system maintainable as complexity grows
Build
Low-Code CPQ
Operate
Self-maintained Produktkonfiguration
Scale over time
Wartbares CPQ-System
Surrounded by governance · version control · audit · access control
Reusable model · structure intact
Product Ops liest, erklärt und aktualisiert Regeln die SI nicht mitnahm
Buchen Sie Demo und gehen Sie Regel-Lesbarkeit, Änderungsnotizen, Versionshistorie und Staging mit Team durch das CPQ nach Implementierung besitzt.
Lassen Sie uns gemeinsam bauen.
Wir ermöglichen es Herstellern, die Produktmodellierung zu beherrschen, den Angebotsprozess zu optimieren, Fehler zu reduzieren und letztendlich maßgeschneiderte Lösungen zu liefern, die Kunden nachfragen.