Kompetenzfeld 02
CPQ & Produktkonfiguration
Richtig konfigurieren. Profitabel bepreisen. Sicher anbieten.
Wir verbinden Kundenbedarf, Produktlogik, Pricing, Freigaben, Dokumente und Ergebnisobjekte zu einem durchgängigen Prozess – vom Guided Selling bis zu Auftrag und Stückliste.
02
Wirkung
Geschwindigkeit
Preisqualität
Durchgängigkeit
Schneller von der Anfrage zur gültigen, bepreisten und ausführbaren Lösung.
End-to-End statt Einzellösung
CPQ ist mehr als ein Konfigurator.
Ein belastbarer CPQ-Prozess führt drei Disziplinen gleichwertig zusammen. Configure übersetzt Kundenbedarf in eine technisch gültige Lösung. Price entwickelt daraus einen nachvollziehbaren und wirtschaftlich tragfähigen Preis. Quote verbindet Lösung, Preis, Visualisierung und Dokumente zu einem reproduzierbaren Angebot.
Bei variantenreichen Industrieprodukten müssen alle drei Disziplinen auf derselben freigegebenen Produktlogik aufsetzen. Andernfalls bleiben lange Angebotslaufzeiten, frühe Engineering-Beteiligung, inkonsistente Preisstände und fehlende Ergebnisobjekte lediglich digitalisiert.
C
Configure
Bedarf in eine gültige, berechnete und für den jeweiligen Nutzer verständliche Lösung übersetzen.
P
Price
Produktlogik, Kosten, Markt, Kundennutzen, Konditionen, Marge und Freigaben zusammenführen.
Q
Quote
Lösung, Preis, Positionen, Dokumente und Freigabestand zu einem belastbaren Angebot verbinden.
Entscheidend: Die Kette wird erst durchgängig, wenn fachliche Objekte, Systemrollen und Verantwortung an jeder Übergabe geklärt sind.
Configure
Vom Kundenbedarf zur gültigen, reproduzierbaren Lösung.
Produktkonfiguration beginnt nicht mit einer Oberfläche. Sie beginnt mit der Frage, wie Kundenanforderungen in einen beherrschten Lösungsraum übersetzt werden. Geführte Auswahl, Expertenkonfiguration und technische Detailbearbeitung dürfen unterschiedliche Sichten bieten – müssen aber dieselbe freigegebene Produkt- und Regelbasis verwenden.
Bedarf und Nutzersicht
Guided Selling erfasst Anwendung, Leistungsbedarf, Einsatzbedingungen und Präferenzen in verständlicher Marktsprache. Empfehlungen, Defaults und unterschiedliche Konfigurationstiefen unterstützen Kunde, Vertrieb, Expert Sales und Engineering.
Produkt- und Regelmodell
Merkmale, Werte, Optionen, Module, Abhängigkeiten, Constraints und bevorzugte Lösungen werden verständlich benannt, versioniert und testbar modelliert. Wiederverwendbare Lösungen behalten in Vertrieb, Engineering und Ausführung dieselbe Bedeutung.
Auslegung und Ergebnisobjekte
Mehrpositions- und Systemkonfiguration, Dimensionierung, Kennlinien und technische Berechnung werden dort eingebunden, wo sie Auswahl und Validierung absichern. Konfigurations-ID, Spezifikation, Parameter, Dokumente und Strukturinformationen entstehen reproduzierbar.
Prozessgrenzen und Engineering
CTO, CTO+ und ETO benötigen klare Übergabepunkte. Regelbasierte Konfiguration, Parametrierung und begrenzte Engineering-Anteile können zusammenwirken, ohne Sonderlösungen unkontrolliert in neue Dauerkomplexität zu überführen.
Prozessgrenzen: MTS, PTO, ATO, MTO, CTO, CTO+ und ETO sind keine lineare Reifegradfolge. Pro Produktfamilie ist zu klären, welcher Anteil regelbasiert entsteht, wann Engineering einsetzt und welche Ergebnisobjekte benötigt werden.
Anwendungskontext
Markt, Produkt und Prozess bestimmen den richtigen Ausgangspunkt.
Eine markt- und vertriebsnahe Angebotssteuerung stellt andere Anforderungen als ein technisch tiefer Produktkonfigurator, eine ERP-nahe Auftragskonfiguration oder Engineering Automation. Die Systemklasse ist deshalb zunächst eine fachliche Einordnung des Anwendungsfalls – keine Rangfolge von Technologien und keine Produktbewertung.
Systemklassen × Anwendungs- und Funktionsschwerpunkte
Welche Systemklasse passt zu welchem Produkt- und Anwendungskontext?
Systemklassen folgen unterschiedlichen Markt-, Produkt- und Prozesssituationen. Die Matrix zeigt ihren fachlichen Ausgangspunkt, ihre typischen Anwendungsfelder und die Funktionsrollen, in denen sie führt, ergänzt oder integriert.
| Systemklasse |
|---|
Die Einordnung beschreibt typische Schwerpunkte und keine Produktbewertung. Konkrete Rollen hängen von Produktausprägung, Modulen und Zielarchitektur ab. Vollständige Klassenprofile mit Ausgangspunkt, Abgrenzung und Prüffragen stehen auf CPQ-SELECT.
Price
Preislogik, Marge und Governance gehören in denselben Entscheidungsprozess.
Pricing ist kein nachgelagerter Rechenschritt. Bei komplexen Produkten entsteht der Preis aus Konfiguration, Kostenbasis, Markt, Kundennutzen, Vertrag, Serviceumfang und Deal-Situation. Deshalb wird zuerst die Preisarchitektur geklärt und erst danach ihre technische Verteilung auf ERP, CPQ und CRM.
Preisarchitektur
Price Waterfall und Governance für variantenreiche Produkte
Preisfindung von der Kostenbasis bis zum Nettopreis. Entscheidend ist nicht die Höhe der Stufen, sondern wer sie verantwortet, welches System sie führt — und wo auf dem Weg regelmäßig Marge verloren geht.
1 · Preismechaniken
2 · Price Waterfall
Schematische Darstellung der Stufenlogik. Die Höhen sind Proportionen zur Veranschaulichung und stellen keine Kennzahlen dar.
3 · Systemlandschaft und Rollen
Zielbild: eine transparente, regelbasierte und wertorientierte Preisfindung — bei der jede Stufe einen benannten Eigner hat und der realisierte Nettopreis in die Preisarchitektur zurückfließt.
Leitlinie: Konfiguration und Pricing dürfen dieselbe Produktlogik nicht unabhängig voneinander nachbauen. Kosteninformation, Preisbestandteile, Margensicht, Overrides und Freigaben benötigen eindeutige Datenhoheiten.
Quote und Übergabe
Aus der gewählten Lösung wird ein belastbares und ausführbares Ergebnis.
Quote ist mehr als Dokumentgenerierung. Der Kunde muss Lösung, Leistungsumfang, Alternativen und kaufmännische Auswirkungen verstehen. Intern müssen Konfiguration, Preisstand, Visualisierung, Dokumente und Freigaben gemeinsam versioniert und reproduzierbar bleiben.
Angebot und Alternativen
Haupt- und Nebenpositionen, Optionen, Pakete, Lieferumfänge, Ausschlüsse und Variantenvergleiche werden zu einer konsistenten Angebotsstruktur zusammengeführt.
Dokumente und Visualisierung
Technische Daten, Texte, Zeichnungen, Layouts sowie 2D-/3D-Darstellungen werden aus dem freigegebenen Stand abgeleitet – nicht als Show-Effekt, sondern als eindeutiger Bestandteil des Angebots.
Auftrag und Ergebnisobjekte
Konfigurations-ID, Positionen, Merkmale, Preisbestandteile und Freigabestatus bilden die kontrollierte Übergabe an Auftrag, Change Orders und die Ableitung der auftragsspezifischen 100%-Stückliste.
Architekturprinzip: CPQ muss nicht selbst die fertigungsgerechte Stückliste erzeugen. Es muss jedoch einen eindeutigen, reproduzierbaren Ergebnisstand liefern, aus dem CPQ, PLM, ERP oder ein gekoppelter Prozess die vorgesehenen Downstream-Objekte zuverlässig ableiten kann.
Wirkung über die Prozesskette
Früher belastbare Produktbeschreibung. Weniger Schleifen bis zum Produktionsbeginn.
Der wesentliche Hebel entsteht nicht allein durch eine schnellere Angebotserstellung. Produktwissen wird früher verfügbar, Entscheidungen werden reproduzierbar und Engineering konzentriert sich stärker auf echte neue Lösungsanteile statt auf wiederkehrende Auftragsklärung.
Anwendung: hochkomplexer Maschinen-, Anlagen- und Großanlagenbau
Qualitative Darstellung: Der konkrete Vorsprung und das Ausgangsniveau variieren je Produktbereich, Produktarchitektur und Umfang der vorab definierten Produktlogik.
Unser Beratungsprinzip
Fünf Perspektiven machen CPQ betriebsfähig.
Ein belastbarer CPQ-Prozess entsteht nur, wenn Lösungsraum, Ablauf, Datenobjekte, Systemrollen und Verantwortung gemeinsam gestaltet werden.
Beitrag zum gemeinsamen Zielbild
Produkt
Lösungsraum, Produktstruktur, Optionen, Services und benötigte Ergebnisobjekte bilden den fachlichen Ausgangspunkt.
Leitfrage: Welche Lösungen dürfen angeboten werden – und welche Ergebnisse müssen daraus entstehen?
Vorgehen und Ergebnisse
Vom gewachsenen Angebotsprozess zum belastbaren CPQ-Zielmodell.
Der Einstieg erfolgt über reale Produktfamilien und repräsentative End-to-End-Fälle. Kriterienlisten allein reichen nicht: Ein PoC belegt technische Machbarkeit, ein Pilot zeigt Betriebsfähigkeit, Pflegeaufwand und Governance.
01
Ausgangslage und Abgrenzung
Produktfamilien, Nutzer, Prozessklassen, Angebotslaufzeiten, Engineering-Anteile, Pricing-Probleme, Ergebnisobjekte und Geschäftsziele transparent machen.
02
Zielbild und Pilot
Produkt- und Regelmodell, Guided Selling, Preisarchitektur, Systemrollen und Übergabeobjekte an realistischen Use Cases sowie 10–20 repräsentativen Grenzfällen pro Produktfamilie entwickeln und validieren.
03
Betrieb und Skalierung
Rollen, Pflege, Tests, Releasekalender, Monitoring, Training und KPIs verankern sowie Produktfamilien, Regionen und Kanäle kontrolliert ausrollen.
Typische Ergebnisse
- Freigegebener Lösungsraum für Guided Selling, Konfiguration und Engineering
- Nachvollziehbare Preisarchitektur mit Margensicht und Freigaben
- Reproduzierbare Angebote, Dokumente und Versionsstände
- Definierte Ergebnisobjekte für Auftrag und Downstream-Prozesse
Messbare Steuerung
- Angebotsdurchlaufzeit, Fehlerquote und Engineering-Anteil
- Hit Rate, Rabattquote, Marge und Freigabeaufwand
- Wiederverwendung und Aufwand für Produktmodelländerungen
- Releasequalität, Regression, Monitoring und kontinuierliche Verbesserung
Häufige Fragen
Wichtige Entscheidungen vor einer CPQ-Initiative.
Wie grenzen wir MTS, PTO, ATO, MTO, CTO, CTO+ und ETO für CPQ ab?
Über klare Prozess- und Scope-Grenzen pro Produktfamilie. Entscheidend ist, welcher Anteil regelbasiert im freigegebenen Lösungsraum entsteht, wann Engineering einsetzt, welche Ergebnisobjekte benötigt werden und welche Systeme beteiligt sind.
Wo liegt die Konfigurationslogik zwischen CPQ, PLM und ERP?
Das hängt von Produktstruktur, Konfigurationstiefe und Prozessmuster ab. Guided Selling und vertriebliche High-Level-Logik können im CPQ liegen, während PLM oder ERP struktur- und stücklistennahe Logik führen. Wichtig sind gemeinsame Semantik, eindeutige Gültigkeiten und keine unkontrolliert doppelten Regeln.
Wie gelingt die Übergabe von Konfiguration und Angebot an Auftrag und Stückliste?
Durch definierte Ergebnisobjekte und eine reproduzierbare Konfigurations-ID. Positionen, Merkmale, Dokumente, Preisbestandteile und Freigabestatus werden so übergeben, dass Auftrag und 100%-Stückliste im vorgesehenen Zielsystem eindeutig abgeleitet werden können.
Wie prüfen wir, ob eine CPQ-Lösung fachlich und technisch passt?
Nicht allein mit Kriterienlisten. Entscheidend sind realistische Use Cases und Grenzfälle für Guided Selling, Konfiguration, Pricing, Dokumente, Änderungen, Integration und Stücklistenableitung. Ein PoC belegt Machbarkeit; ein Pilot zeigt, ob Modellierung, Betrieb und Governance tragfähig sind.
Wie bleiben Konfigurationen und Angebote über Änderungen reproduzierbar?
Produkte, Optionen, Regeln, Preise, Dokumente und Schnittstellen werden gemeinsam versioniert, getestet und freigegeben. Historische Stände müssen für Re-Konfiguration, Change Orders, Retrofit, Ersatzteil- und Serviceangebote nachvollziehbar bleiben.
Unabhängig. Erfahren. Umsetzungsnah.
CPQ-, Konfigurations- oder End-to-End-Thema fundiert einordnen.
In einem ersten Gespräch klären wir Ausgangssituation, Produkt- und Prozesskontext, Konfigurations- und Pricing-Logik, Ergebnisobjekte, Systemlandschaft und wesentliche Risiken. Anschließend bewerten wir, ob ein fokussierter Review, ein Zielbild, ein PoC oder ein Pilot der richtige Einstieg ist.