Configure. Price. Quote. End-to-End.
Richtig konfigurieren. Profitabel bepreisen. Sicher anbieten.
Von Kundenbedarf und Guided Selling bis zu Angebot und Auftrag.
Wir verbinden Produktlogik, Pricing, Freigaben, Dokumente und Ergebnisobjekte zu einem durchgängigen CPQ-Prozess.
WIRKUNG
Geschwindigkeit
Schneller von der Anfrage zur gültigen, bepreisten Lösung.
Preisqualität
Preislogik, Marge, Rabatt und Freigabe nachvollziehbar steuern.
Durchgängigkeit
Angebot, Auftrag, Dokumente und Stückliste konsistent ableiten.
CPQ ist mehr als ein Konfigurator.
CPQ ist mehr als ein Konfigurator und mehr als ein Angebotsgenerator. Ein belastbarer CPQ-Prozess führt drei Disziplinen gleichwertig zusammen: Configure übersetzt Kundenbedarf in eine gültige technische Lösung, Price entwickelt daraus einen nachvollziehbaren und wirtschaftlich tragfähigen Preis, und Quote führt Lösung, Preis, Visualisierung und Dokumente zu einem belastbaren Angebot zusammen.
Bei variantenreichen Industrieprodukten müssen C, P und Q auf derselben freigegebenen Produktlogik aufsetzen. Guided Selling und Konfiguration erschließen den Lösungsraum; Pricing verbindet Preisstrategie, konfigurationsabhängige Preisbestandteile, Costing-Anbindung, Konditionen und Freigaben; Quote macht die gewählte Lösung verständlich und überführt sie konsistent in Angebot, Dokumente, Auftrag und weitere Downstream-Prozesse. Typische Auslöser sind lange Angebotslaufzeiten, frühe Engineering-Beteiligung, inkonsistente Preis- und Dokumentenstände oder fehlende Ergebnisobjekte für Auftrag und Stückliste.
Configure – Price – Quote als durchgängige Kette
Die drei Disziplinen greifen auf dieselbe freigegebene Produktlogik zu und führen gemeinsam bis zu Auftrag, Dokumenten und Stückliste.
Kundenbedarf → Guided Selling → Configure → Price → Quote → Freigabe → Auftrag → 100%-Stückliste
Guided Selling – vom Kundenbedarf zur passenden Lösung
Produktkonfiguration beginnt nicht mit einem Tool, sondern mit der Frage, wie Kundenanforderungen in eine passende Lösung übersetzt werden. Guided Selling arbeitet mit einer verständlichen Marktsprache: Anwendung, Leistungsbedarf, Einsatzbedingungen und Präferenzen. Die technische Produktlogik übersetzt diese Angaben in Merkmale, Optionen, Module und Regeln.
Für Experten kann eine technische Detailkonfiguration sinnvoll sein; andere Nutzer brauchen geführte Fragen, Empfehlungen, sinnvolle Voreinstellungen und gegebenenfalls eine schrittweise Visualisierung der Lösung. Nicht jeder Nutzer muss denselben Konfigurator sehen – aber alle Wege müssen auf denselben freigegebenen Lösungsraum zugreifen.
Configure – gültige Produkte und Lösungen konfigurieren
Produkt- und Datenbasis
Geordnetes Portfolio, konfigurierbare Produktstruktur und ein klares Produktdatenmodell bilden die Grundlage. Merkmale und Werte müssen verständlich benannt, Variantenobjekte versioniert und Regeln testbar sein. Wiederverwendbare technische Lösungen werden so modelliert, dass sie in Vertrieb, Engineering und Produktion dieselbe fachliche Bedeutung behalten.
Prozessklassen und Scope
Je nach Geschäfts- und Produktmodell unterscheiden wir MTS, PTO, ATO, MTO, CTO, CTO+ und ETO. Diese Klassen sind keine lineare Reifegradfolge, sondern beschreiben unterschiedliche Anteile aus Lagerfertigung, Auswahl, Montage, Fertigung, Konfiguration und Engineering. Für den CPQ-Scope ist entscheidend, wie viel der Lösung regelbasiert entsteht, wann Engineering einsetzt, welche Ergebnisobjekte benötigt werden und welche Systeme beteiligt sind.
System- und Mehrpositionskonfiguration
Bei Maschinen, Anlagen und technischen Systemen reicht die Konfiguration häufig über ein einzelnes Produkt hinaus. Mehrere Positionen, Baugruppen, Zubehör, Services oder Subsysteme müssen gemeinsam dimensioniert und auf übergreifende Abhängigkeiten geprüft werden. Wir klären, welche Beziehungen regelbasiert im Konfigurator beherrscht werden, welche Berechnungen erforderlich sind und wie systemweite Ergebnisobjekte entstehen.
CTO+, Parametrierung und ETO-Anteile
Nicht jede Kundenanforderung passt vollständig in einen vordefinierten Variantenraum. In CTO+-Prozessen können regelbasierte Konfiguration, technische Berechnung, Parametrierung und begrenzte Engineering-Anteile zusammenwirken. Für ETO-Anteile definieren wir klare Übergabepunkte, Referenzlösungen und Rückführungsmechanismen, damit Sonderlösungen nicht unkontrolliert zu neuer Dauerkomplexität werden.
Technische Berechnung und Ergebnisobjekte
Dimensionierung, Kennlinien, Leistungswerte und abgeleitete Parameter gehören dort in den Prozess, wo sie für Auswahl, Validierung oder Downstream benötigt werden. Wir trennen Produktlogik, Berechnung und Ergebnisobjekte bewusst und definieren, welche Werte angezeigt, gespeichert, versioniert und an Angebot, Auftrag, Dokumente oder Stückliste übergeben werden.
Nutzersichten und Konfigurationstiefe
Kunde, Vertrieb, Expert Sales und Engineering benötigen unterschiedliche Sichten und Freiheitsgrade. Nicht jeder Nutzer muss dieselbe Oberfläche oder dieselben technischen Details sehen; alle Rollen müssen jedoch auf dieselbe freigegebene Produkt- und Regelbasis zugreifen. So lassen sich geführte Auswahl, Expertenkonfiguration und technische Detailbearbeitung in einem konsistenten Gesamtprozess verbinden.
Regelwerk, Gültigkeit und Test
Regeln müssen technische Gültigkeit sichern, aber auch verständlich, wartbar und testbar bleiben. Wir strukturieren Abhängigkeiten, Constraints, Ableitungen und Defaults so, dass Fachbereiche Änderungen kontrolliert einspielen und Grenzfälle regressionssicher testen können.
- Merkmale, Optionen und Wertebereiche.
- Constraints, Abhängigkeiten und Ableitungen.
- Defaults und bevorzugte Lösungen.
- Technische Machbarkeit und Prozessgrenzen.
- 10–20 repräsentative Grenzfälle pro Produktfamilie plus Regression bei Änderungen.
Price – Preislogik, Architektur und Governance
Pricing ist kein nachgelagerter Rechenschritt. Bei komplexen Produkten entsteht der Preis aus Produktkonfiguration, Kostenbasis, Markt, Kundennutzen, Vertrag, Serviceumfang und Deal-Situation. Deshalb klären wir zunächst die Pricing-Logik und erst danach deren technische Verteilung und Umsetzung.
1. Pricing-Ansätze und hybride Preislogik
Bei Industrieprodukten existiert selten nur eine Pricing-Methode. Cost-plus Pricing leitet Preise aus einer definierten Kostenbasis sowie Zuschlägen oder Zielmargen ab. Merkmals- und optionsbasiertes Pricing bepreist Leistungsmerkmale, Optionen, Kapazitäten, Software oder Services. Value-based Pricing orientiert sich stärker am Kundennutzen, Segment, Anwendungsfall oder wirtschaftlichen Wert der Lösung. Hybride Modelle kombinieren diese Ansätze bewusst – zum Beispiel Kostenbasis plus merkmalsabhängige Preisanteile, ergänzt um Markt-, Segment- und Value-Komponenten.
2. Preisarchitektur, Datenhoheit und Systemrollen
Zunächst wird die Preisarchitektur festgelegt: Listen- oder Basispreise, Preisbücher, Regionen, Währungen, Kundengruppen, Verträge und Gültigkeiten. Für jede Preisart braucht es eine eindeutige Datenhoheit. ERP kann Stammpreise, Konditionen und Kosten führen; CPQ kann konfigurationsabhängige Preisbildung, Deal-Simulation, Margensicht und Freigaben orchestrieren; CRM kann kunden- und opportunitybezogene Informationen liefern. Die konkrete Verteilung hängt von der vorhandenen Systemlandschaft ab und muss bewusst entschieden und getestet werden.
3. Konfigurations- und merkmalsabhängige Preisbildung
Optionen, Merkmalsausprägungen, Leistungsklassen, Kapazitäten, Funktionen, Software, Services, Zubehör und technische Zuschläge können den Preis beeinflussen. Entscheidend ist, dass dieselbe Produktlogik nicht in Konfiguration und Pricing unabhängig voneinander nachgebaut wird. Preisregeln müssen auf freigegebenen Konfigurationsergebnissen und stabilen Produktobjekten aufsetzen.
4. Mark-up, Discounting, Margen und Freigaben
Mark-up und Discounting sind zwei unterschiedliche Steuerungsmechanismen und sollten nicht vermischt werden. Mark-ups erhöhen Referenz- oder Listenpreise beispielsweise aufgrund von Region, Markt, Anwendung, Kundensegment, technischer Ausprägung, Risiko oder Serviceanteil. Discounting reduziert Preise auf Basis von Kundenkonditionen, Mengen, Projekt- oder Deal-Situation. Dafür braucht es klare Rabattkorridore, Rollen, Eskalationsstufen und Genehmigungen. Margen sollten dort sichtbar werden, wo Entscheidungen getroffen werden – mit eindeutigem Umgang mit Kostenständen, Zuschlägen, Overrides und Sonderfreigaben.
5. Costing und Pricing sauber verbinden
Costing ist keine Konfigurationsfunktion. Es nutzt das Ergebnis der Konfiguration und ergänzt es um Material-, Fertigungs-, Beschaffungs-, Projekt- oder Servicekosten. Der Verkaufspreis ist wiederum nicht zwangsläufig Kosten plus Aufschlag. Cost-plus, merkmalsbasierte, value-based und hybride Preislogiken können parallel wirken. Wichtig sind die klare Trennung der Rollen sowie die definierte Verbindung von Konfigurationsergebnis, Kosteninformation, Preislogik und Margensicht.
6. Price Waterfall und Nachvollziehbarkeit
Ein nachvollziehbarer Price Waterfall zeigt, wie der Netto-Angebotspreis entsteht. Die konkrete Ausprägung variiert, typischerweise werden Basispreis, Options- und Leistungszuschläge, Markt- und Kundenkonditionen, Projekt- oder Deal-Rabatte sowie Freigaben transparent zusammengeführt. Ziel ist nicht ein bestimmtes UI, sondern Nachvollziehbarkeit: Wer hat welchen Preisbestandteil warum verändert und mit welcher Wirkung auf Marge und Ergebnis?
Quote – Angebot, Dokumente und Visualisierung
Aus Konfiguration und Pricing entsteht ein belastbares Angebot. Dazu gehören eine nachvollziehbare Positions- und Lieferumfangsstruktur, Preisbestandteile, Alternativen, technische und kaufmännische Dokumente, Bedingungen, Versionen und Freigabestatus. Quote ist mehr als Dokumentgenerierung: Der Kunde muss die gewählte Lösung, ihren Leistungsumfang, Varianten und kaufmännische Auswirkungen verstehen können; intern müssen Angebot und Konfiguration reproduzierbar bleiben.
Angebotsstruktur, Positionen und Alternativen
Bei Mehrpositions- oder Anlagenangeboten müssen Produktkonfiguration, Preise, optionale Leistungen und Alternativen zu einer konsistenten Angebotsstruktur zusammengeführt werden. Dazu gehören Haupt- und Nebenpositionen, Variantenvergleiche, optionale Pakete, Lieferumfänge, Ausschlüsse sowie technische und kaufmännische Abhängigkeiten zwischen Positionen.
Visualisierung und konfigurationsgetriebene Darstellung
Visualisierung kann – je nach Produkt und Vertriebsprozess – gewählte Optionen, technische Merkmale, Lieferumfang, Leistungsgrenzen und Einbausituationen verständlich machen. Dazu gehören 2D-/3D-Darstellungen, konfigurationsgetriebene Zeichnungen, Layouts oder schematische Ansichten. Entscheidend ist nicht der Show-Effekt, sondern die konsistente Ableitung aus dem freigegebenen Konfigurationsstand und die eindeutige Zuordnung zum Angebot.
Dokumente, Varianten und reproduzierbare Angebotsstände
Zur Quote-Logik gehören länder-, markt- und kundenspezifische Texte, technische Datenblätter, Zeichnungen, Vertragsanhänge und digitale Angebotsformen. Konfiguration, Preisstand, Visualisierung und Dokumente müssen gemeinsam versioniert und reproduzierbar bleiben. Bei Änderungen muss nachvollziehbar sein, welche Produkt-, Regel- und Preisstände einem konkreten Angebot zugrunde lagen und welche Unterschiede zwischen Angebotsversionen entstanden sind. Nach dem Zuschlag endet diese Logik nicht: Auftragsänderungen, Nachträge und Change Orders müssen mit Konfiguration, Preis, Dokumenten, Freigaben und Stücklistenständen verbunden bleiben.
Auftrag, Ergebnisobjekte und Stückliste
Ein CPQ-Prozess ist erst dann durchgängig, wenn sein Ergebnis downstream eindeutig genutzt werden kann. CPQ muss nicht in jedem Architekturmodell selbst die fertigungsgerechte Stückliste erzeugen. Entscheidend sind reproduzierbare Ergebnisobjekte – etwa Konfigurations-ID, Positionen, Merkmale, Dokumente, Preisbestandteile und Freigabestatus – sowie ein definierter Übergang zur Ableitung einer auftragsspezifischen 100%-Stückliste aus 150%- beziehungsweise Maximalstrukturen. Je nach Systemlandschaft kann diese Ableitung im CPQ, PLM, ERP oder in einem gekoppelten Prozess erfolgen; fachliche Verantwortung und Rückverfolgbarkeit müssen eindeutig sein. Die Struktur-, Objekt- und Systemarchitektur dahinter vertiefen wir im Kompetenzfeld Produktstrukturen & Systemdurchgängigkeit.
Integration und Betrieb
PLM, CPQ, ERP und gegebenenfalls CRM/PIM benötigen klare Rollen und Schnittstellenprinzipien. Dazu gehören Datenflüsse, Trigger, Monitoring, Fehlerhandling, Versionen, Releasekalender und Regressionstests. Die Architektur muss nicht nur im Happy Path, sondern bei Änderungen und Grenzfällen funktionieren. Die fachliche Zuordnung von Produktmodellen, eBOM, mBOM, Maximalstrukturen und Ergebnisobjekten behandeln wir vertieft unter Produktstrukturen & Systemdurchgängigkeit.
Configuration Lifecycle – Modelle, Gültigkeiten und Releases
Ein Konfigurationsmodell ist kein einmaliges Implementierungsobjekt. Produkte, Optionen, Regeln, Preise, Dokumente, Visualisierungen und Schnittstellen ändern sich über Releases und Produktgenerationen. Deshalb müssen Modellierung, Test, Gültigkeit, Release, Regression und Rückverfolgbarkeit von Beginn an Teil des CPQ-Konzepts sein. Historische Konfigurationen müssen reproduzierbar bleiben; Re-Konfiguration, Auftragsänderungen beziehungsweise Change Orders, Retrofit, Ersatz- und Serviceangebote benötigen nachvollziehbare Produkt-, Regel-, Preis- und Stücklistenstände.
Systemauswahl, PoC und Testing
Kriterienlisten allein entscheiden keine CPQ-Auswahl. Wir vergleichen Lösungen an realistischen Use Cases und Grenzfällen: komplexe Konfigurationen, Pricing, Rabatte, Freigaben, Dokumente, BOM-Ableitung, Änderungen und Integration. Ein PoC zeigt technische Machbarkeit; ein Pilot zeigt Betriebsfähigkeit.
Operating Model, KPIs und Governance
- Rollen für Produktmodell, Regeln, Pricing, Dokumente und Integrationen.
- Change-, Freigabe-, Test- und Releaseprozess.
- Monitoring und Fehlerbehandlung.
- Training und fachliche Befähigung.
- KPIs: Angebotsdurchlaufzeit, Fehlerquote, Engineering-Anteil, Hit Rate, Rabattquote, Marge, Wiederverwendung und Änderungsaufwand.
Ergebnisse
- Ein einheitlicher, freigegebener Lösungsraum für Guided Selling, Konfiguration und Engineering.
- Eine nachvollziehbare Preisarchitektur mit klaren Datenhoheiten, Margensicht und Freigaben.
- Reproduzierbare Angebote mit konsistenten Positionen, Dokumenten, Visualisierungen und Versionen.
- Definierte Ergebnisobjekte für Auftrag, Downstream-Prozesse und die Ableitung zur 100%-Stückliste.
- Ein belastbares Operating Model für Pflege, Test, Release, Monitoring und kontinuierliche Verbesserung.
Typisches Projektmuster
Ausgangslage
Angebote entstehen langsam, Konfiguration, Pricing und Dokumente folgen unterschiedlichen Logiken, Engineering wird früh eingebunden und Margen werden erst spät transparent.
Vorgehen
Scope und Prozessklassen klären, Produkt- und Regelmodell strukturieren, Pricing-Architektur und Ergebnisobjekte definieren sowie realistische End-to-End-Testfälle und einen Pilot aufbauen.
Wirkung
Schnellere und belastbarere Angebote, weniger Fehler und Engineering-Aufwand, transparente Margen sowie eine konsistente Übergabe an Auftrag, Dokumente und Stückliste.
Häufige Fragen
Wie grenzen wir MTS, PTO, ATO, MTO, CTO, CTO+ und ETO für CPQ ab?
Über klare Prozess- und Scope-Grenzen pro Produktfamilie. Die Klassen beschreiben unterschiedliche Anteile aus Lagerfertigung, Auswahl, Montage, Fertigung, Konfiguration und Engineering. 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 eine 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 oder gekoppelten Prozess 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, Integrationen und Stücklistenableitung. Ein PoC belegt Machbarkeit; ein Pilot zeigt, ob Modellierung, Betrieb und Governance tragfähig sind.
CPQ-, Konfigurations- oder End-to-End-Thema einordnen
In einem ersten Gespräch klären wir Ausgangssituation, Produkt- und Prozessscope, 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.