DWC Insight 203 · Decision Guide

CPQ Readiness: Trägt die Produktlogik vor der Systemauswahl?

Was Portfolio, Prozessklassen, Daten, Systeme und Organisation vor Longlist, Proof of Concept und Pilot leisten müssen.

Eine CPQ-Lösung kann nur ausführen, was fachlich entschieden und dauerhaft verantwortet werden kann. Dieser Insight zeigt, welche Voraussetzungen vor der Systemauswahl geklärt sein müssen – und welche Fragen bewusst erst im Pilot beantwortet werden können.

Executive Summary

Readiness entscheidet vor der Systemauswahl.

Ein CPQ-Projekt wird nicht dadurch tragfähig, dass eine leistungsfähige Plattform ausgewählt wird. Entscheidend ist, ob das Unternehmen den zulässigen Lösungsraum, die Produkt-Prozess-Klassen, die benötigten Ergebnisobjekte und die Verantwortung für Produktlogik und Daten so weit geklärt hat, dass Anbieter sinnvoll bewertet werden können.

Die vollständige Readiness umfasst neun Dimensionen. Für die Entscheidung lassen sie sich über fünf Perspektiven führen: Produkt, Prozess, Daten, Systeme und Organisation. Die Perspektiven sind keine Reifestufen und werden nicht nacheinander abgearbeitet. Sie bilden einen gemeinsamen Prüfrahmen.

Der Maßstab ist nicht maximale Vorbereitung. Der Maßstab ist ausreichende Klarheit für die nächste irreversible Entscheidung.

Wenn die Software bereit ist, das Unternehmen aber nicht

CPQ-Projekte beginnen häufig mit einer attraktiven Zielsetzung: Angebote sollen schneller entstehen, Varianten sicher beherrscht, Preise konsistent berechnet und technische Ergebnisse ohne Medienbruch an Engineering und Produktion übergeben werden. Anbieter zeigen überzeugende Oberflächen, leistungsfähige Regelwerke und weitreichende Integrationsmöglichkeiten. Dennoch geraten viele Vorhaben früh ins Stocken – nicht zwingend, weil die Software ungeeignet ist, sondern weil Aufgabe, Produktlogik und Verantwortung noch nicht ausreichend geklärt sind.

Ein CPQ Readiness Assessment bewertet deshalb keine Anbieter. Es klärt, ob das Unternehmen seine Produktvielfalt beschreiben, Prozessklassen unterscheiden, Datenquellen benennen und Verantwortlichkeiten verbindlich festlegen kann. Readiness ist damit weder ein allgemeines Digitalisierungsranking noch eine Vorstudie ohne Konsequenz. Sie schafft Entscheidungsfähigkeit für Auswahl, Proof of Concept und Pilot.

Insight 202 beschreibt das Auswahlvorgehen von Zielbild und Kriterien bis zu Use-Case-Benchmark, Proof of Concept, Pilot und Entscheidungsvorlage. Insight 203 vertieft die fachlichen Voraussetzungen der ersten Entscheidungstore: Er klärt, ob bereits ein belastbarer Maßstab existiert, an dem Anbieter und Lösungsarchitekturen geprüft werden können.

Fünf Perspektiven führen neun Readiness-Dimensionen zusammen

Die bestehende Readiness-Systematik umfasst neun fachlich unterschiedliche Dimensionen. Für die Entscheidungsarbeit werden sie nicht reduziert, sondern in fünf Perspektiven geordnet. Dadurch bleibt sichtbar, welche Fragen zusammengehören und an welchen Übergängen zwischen Fachbereich, Datenmodell und Systemarchitektur die eigentlichen Risiken liegen.

Ein gemeinsamer Prüfrahmen – keine lineare Reifegradfolge

Perspektive wählen · 9 Dimensionen bleiben vollständig erhalten

01

Produkt

• Portfolio und Scope
• Zulässiger Lösungsraum
• Bestandsvarianten und Ablösung

02

Prozess

• Produkt-Prozess-Klassen
• Guided Selling und Nutzerführung
• Pricing, Costing und Dokumente

03

Daten

• Produktstruktur und Datenmodell
• Version, Gültigkeit und Reproduzierbarkeit
• Ergebnis- und Übergabeobjekte

04

Systeme

• Systemrollen und Integration
• Visualisierung und Automation
• Betriebsmodell und Sicherheit

05

Organisation

• Governance und Modellpflege
• Entscheidungs- und Änderungsrechte
• Kapazität nach dem Go-live

Entscheidungsfrage

Ist entschieden, welche Produktfamilien, Varianten und kundenspezifischen Anteile in den Scope gehören?

Kritischer Übergang

Produktentscheidung → Regelmodell und Pilot-Scope

Entscheidend: Die Perspektiven beeinflussen sich gegenseitig. Ein ungeklärtes Datenobjekt kann ebenso eine Produktentscheidung wie eine System- oder Verantwortungsfrage sein.

01 · Produkt: Portfolio und Scope begrenzen den Lösungsraum

Jede CPQ-Initiative beginnt beim Portfolio. Ohne eine klare Sicht auf Produktfamilien, Optionen, Zubehör, Dienstleistungen und kundenspezifische Anteile bleibt unklar, was ausgewählt, konfiguriert oder projektiert werden soll. Umfangreiche Produktkataloge und ERP-Stammdaten ersetzen keine konsistente Sicht auf den kommerziell und technisch zulässigen Variantenraum.

Readiness zeigt sich daran, ob Varianten marktseitig Wert schaffen oder lediglich aus historischen Sonderlösungen, regionalen Abweichungen und uneinheitlicher Pflege entstanden sind. Ebenso muss entschieden werden, was mit dem Bestand geschieht: Welche Produktfamilien werden übernommen, welche schrittweise abgelöst und welche nur noch im Service geführt? CPQ soll wertschöpfende Vielfalt beherrschbar machen – nicht jede historische Ausnahme dauerhaft digital konservieren.

Der Scope muss gleichzeitig repräsentativ und beherrschbar sein. Ein zu breiter Einstieg bindet Ressourcen, bevor ein tragfähiges Modell existiert. Ein zu enger Pilot erzeugt ein lokales Werkzeug, das sich später nicht skalieren lässt. Geeignet ist eine Produktfamilie, die das künftige Geschäftsmodell abbildet und zugleich reale Varianten, Grenzfälle und Systemübergaben enthält.

02 · Prozess: Nicht jedes Geschäft folgt derselben Logik

Standardprodukte, auswählbare Optionen, konfigurierbare Maschinen, kontrollierte Engineeringanteile und echtes Engineering-to-Order dürfen nicht in denselben Angebotsprozess gedrängt werden. MTS, PTO, ATO, MTO, CTO, CTO+ und ETO sind keine linearen Reifegrade. Sie beschreiben unterschiedliche Aufgabenlogiken und können innerhalb eines Portfolios nebeneinander bestehen.

Besondere Aufmerksamkeit verdient die Grenze zwischen CTO, CTO+ und ETO. Sicher konfiguriert werden kann nur, was innerhalb eines vorab beschriebenen Lösungsraums liegt. Verlässt eine Kundenanforderung diesen Raum, benötigt sie einen kontrollierten Engineering- und Freigabeprozess. Ohne diese Grenze entstehen entweder überkomplexe Regelwerke oder eine gefährliche Scheinsicherheit.

Guided Selling beginnt nicht bei der Oberfläche, sondern bei der Übersetzung von Kundenbedarf in zulässige Lösungen. Nicht jede technische Eigenschaft ist eine sinnvolle Kundenfrage, und nicht jede Kundenformulierung lässt sich unmittelbar in ein Konfigurationsmerkmal überführen. Zwischen Kundensprache und Produktlogik liegt eine fachliche Übersetzungsleistung, die Vertrieb, Produktmanagement und Engineering gemeinsam tragen müssen.

Zur Readiness gehört auch die Klärung der Nutzerrollen. Interne Vertriebsingenieure, Händler, Serviceorganisationen und anonyme Webnutzer benötigen unterschiedliche Dialoge, Berechtigungen und Ergebnistiefen. Entscheidend ist, welche Entscheidungen der jeweilige Nutzer sicher treffen darf und wann technische Expertise oder eine Freigabe erforderlich wird.

Technische Konfiguration allein erzeugt noch kein belastbares Angebot. Verkaufspreise, Herstellkosten, Zuschläge, Rabatte, Länderlogiken, Währungen und Konditionen folgen unterschiedlichen Regeln. Pricing kann markt-, kunden- oder vertragsbezogen sein; Costing ergibt sich unter anderem aus Materialien, Arbeitsgängen, Standorten, Beschaffung, Losgrößen und Engineeringaufwand. Wer beides vermischt, kann schnell rechnen und dennoch keine belastbare Marge ausweisen.

Auch Angebotsunterlagen, technische Spezifikationen, Datenblätter, Zeichnungen und Freigabedokumente sind Ergebnis des Produkt- und Prozessmodells. Liegen Texte, Ausschlüsse und Leistungsdaten nur in individuellen Vorlagen oder persönlichen Dateien, wird die Dokumentenerzeugung zu einem eigenen Transformationsprojekt.

03 · Daten: Produktstruktur und Ergebnisobjekte müssen tragfähig sein

CPQ arbeitet nicht mit abstrakten Funktionen, sondern mit Produktobjekten. Merkmale, Werte, Regeln, Module, Beziehungen, Preise, Kosten, Texte, Dokumente und Stücklisten bilden gemeinsam das Produktmodell. Readiness verlangt keine vollständig bereinigte Datenlandschaft, wohl aber eine eindeutige Semantik und ein belastbares Zielbild: Welche Objekte gibt es, wie stehen sie zueinander, und wo werden Version und Gültigkeit geführt?

Vertriebsmerkmale können anders strukturiert sein als technische Parameter. Sales-BOM, eBOM, mBOM und as-built-Struktur erfüllen unterschiedliche Zwecke. Entscheidend ist nicht, alle Sichten in einem System zu führen, sondern ihre Ableitung und Identität nachvollziehbar zu beherrschen. Gleiches gilt für das Ergebnis der Konfiguration: Die nachfolgenden Prozesse benötigen ein reproduzierbares Objekt mit Konfigurationsstand, Preisstand, Dokumenten, Freigaben und einer eindeutigen Referenz zur späteren Auftragsstruktur.

Readiness zeigt sich auch in der Datenverantwortung. Wer pflegt Merkmale? Wer genehmigt Regeln? Wo entstehen Dokumente? Welches System führt Materialien, Preise, Kosten und Gültigkeiten? Eine abgeleitete Kopie mit definiertem Aktualisierungsmechanismus kann beherrschbar sein. Zwei gleichrangige Originale sind es nicht.

04 · Systeme: Integration folgt der fachlichen Rollenverteilung

Die Integrationsdiskussion beginnt häufig mit Schnittstellenlisten. Zuerst muss jedoch geklärt werden, welches System welche fachliche Aufgabe übernimmt. CRM, PIM, PLM, CPQ, CAD und ERP besitzen unterschiedliche Rollen. Kein System sollte allein deshalb führend werden, weil es bereits vorhanden ist oder eine bestimmte Funktion ebenfalls anbietet.

Erst aus den Objekt- und Rollenentscheidungen entstehen sinnvolle Übergaben: Wo wird Produktlogik modelliert? Wo werden Preise gepflegt? Welches System erzeugt das vertriebliche Ergebnisobjekt? Wer übernimmt es in Auftrag, Engineering und Fertigung? Integration ohne diese Klärung verbindet Anwendungen technisch und konserviert fachliche Widersprüche.

Dreidimensionale Visualisierung, automatisierte Zeichnungen und Design Automation gehören zu den sichtbarsten Versprechen moderner Lösungen. Ihre Tragfähigkeit hängt jedoch davon ab, ob Geometrien, Parameter, Schnittstellen und Konstruktionsregeln standardisiert sind. Wo CAD-Modelle nicht parametrisch aufgebaut oder Regeln nur personengebunden vorhanden sind, wird Automation zu einem eigenständigen Entwicklungsprojekt.

Nicht jede Produktfamilie benötigt denselben Automatisierungsgrad. In einem Fall genügt die regelbasierte Auswahl vorhandener Dokumente, im anderen ist die automatische Erzeugung auftragsspezifischer Geometrien wirtschaftlich. Ein eindrucksvoller Demo-Fall beweist noch keine dauerhaft betreibbare Lösung.

SaaS, Private Cloud und On-Premises unterscheiden sich nicht nur im technischen Betrieb. Sie bestimmen, wie tief ein Unternehmen in Datenmodell und Software eingreifen kann, ohne Aktualisierbarkeit und Releasefähigkeit zu verlieren. Jede Sonderentwicklung erhöht kurzfristig die Passgenauigkeit und kann langfristig Pflege- und Upgradeaufwand erzeugen.

Auch die Nutzungssituation gehört in diese Entscheidung. Eine interne Anwendung für wenige Vertriebsingenieure stellt andere Anforderungen als eine globale Plattform für Tochtergesellschaften, Händler und anonyme Webnutzer. Welche Produkt-, Preis- und Kostendaten das Unternehmen verlassen dürfen, ist eine Vorgabe an die Architektur und keine nachgelagerte Sicherheitsprüfung.

05 · Organisation: Governance trägt das Modell nach dem Projekt

Mit dem Go-live beginnt die dauerhafte Arbeit. Produktmodelle verändern sich, Optionen entstehen, Preise werden angepasst, Länder kommen hinzu und Regelwerke müssen getestet werden. Fachliche Modellverantwortung, Datenpflege, Qualitätssicherung, Freigabe, Releaseplanung und Support benötigen deshalb benannte Rollen und Entscheidungswege.

Die IT verantwortet Plattform, Sicherheit und technischen Betrieb, kann aber die Produktlogik nicht dauerhaft allein tragen. Produktmanagement, Engineering, Vertrieb, Pricing und Operations müssen ihre fachlichen Aufgaben übernehmen. Readiness bedeutet nicht, vorab eine große Organisation aufzubauen. Sie bedeutet, die dauerhaften Aufgaben anzuerkennen und ausreichend Kapazität sowie klare Änderungsrechte vorzusehen.

Anonymisiertes Projektmuster

Die Softwareauswahl war gestartet – der fachliche Maßstab fehlte.

Das folgende Muster verdichtet wiederkehrende Situationen aus Projekten mit variantenreichen Industrieprodukten. Es ist bewusst anonymisiert und enthält keine erfundenen Ergebniskennzahlen.

Ausgangslage

Eine Produktfamilie sollte in einer neuen CPQ-Plattform abgebildet werden. Eine Anbieterliste und erste Funktionsbewertungen lagen bereits vor.

Befund

CTO-, CTO+- und ETO-Anteile waren nicht getrennt. Vertriebsmerkmale, technische Parameter, Pricingdateien und ERP-Strukturen folgten unterschiedlichen Logiken.

Korrektur

Der Pilot wurde auf eine repräsentative Produktfamilie fokussiert. Prozessklassen, Kernobjekte, Verantwortungen und reale Grenzfälle wurden vor dem Anbieterbenchmark geklärt.

Wirkung

Die Shortlist konnte gegen ein belastbares Zielbild geprüft werden. Der Proof of Concept testete Architektur- und Übergaberisiken statt eines idealisierten Demo-Falls.

Entscheidungshilfe

Sechzehn Fragen für eine erste fachliche Einordnung

Der Kurzcheck ersetzt kein Readiness Assessment. Er zeigt ohne Punktzahl und ohne Reifegradetikett, in welchen Perspektiven bereits belastbare Antworten vorliegen und wo vor Auswahl, Proof of Concept oder Pilot noch Entscheidungen erforderlich sind.

Fachlicher Kurzcheck

Produktlogik vor Systemauswahl

Bevor ein Konfigurations- oder CPQ-System ausgewählt wird, entscheidet die fachliche Grundlage über den Erfolg. Sechzehn Fragen über fünf Perspektiven zeigen, was bereits geklärt ist und was vor der nächsten Entscheidung vertieft werden sollte.

16 Fragen ca. 6 Minuten Ohne Registrierung · keine Datenübertragung

Ergebnis anzeigen Zurücksetzen

Das Ergebnis ist eine strukturierte Selbsteinschätzung, keine Bewertung und kein Reifegrad. Prozessklassen und Architekturentscheidungen sind keine linearen Reifestufen; entscheidend ist die Passung zur jeweiligen Produktfamilie.

Vom Klärungsprofil zur belastbaren Auswahl

Nicht jede Lücke muss vor Projektbeginn vollständig geschlossen sein. Voraussetzungskritisch sind jedoch ein klarer Scope, nachvollziehbare Produkt-Prozess-Klassen, eindeutige Kernobjekte und eine verantwortbare Zielarchitektur. Andere Fragen können im Pilot vertieft werden, sofern Annahmen und Risiken transparent dokumentiert sind.

Eine belastbare Roadmap verbindet fachliche Vorarbeiten, Datenaufbereitung, Systemauswahl, Proof of Concept, Pilot und Roll-out. Damit wird Readiness nicht zum Verzögerungsargument, sondern verhindert, dass technische Arbeit beginnt, bevor die dafür maßgeblichen fachlichen Entscheidungen getroffen wurden.

Fazit für Entscheider

Readiness schafft Entscheidungsfähigkeit.

Ein CPQ Readiness Assessment soll keine zusätzliche Analysephase ohne Konsequenz erzeugen. Sein Wert liegt in der Entscheidung, ob ein Unternehmen bereits sinnvoll auswählen kann, ob zunächst Produkt- und Datenarbeit erforderlich ist oder ob der geplante Scope angepasst werden muss. Ebenso kann das Ergebnis lauten, dass kein neues CPQ-System benötigt wird, sondern bestehende Strukturen, Rollen oder Werkzeuge besser genutzt werden sollten.

CPQ-Erfolg entsteht aus dem Zusammenspiel von Portfolio, Produktarchitektur, Prozessklassen, Datenmodell, Pricing, Dokumenten, Systemrollen und Organisation. Software macht dieses Zusammenspiel ausführbar. Sie schafft es nicht von selbst.

English Executive Summary

CPQ Readiness Before System Selection

A CPQ initiative does not become viable merely because a powerful platform has been selected. What matters is whether the company has sufficiently defined the permissible solution space, its product-process classes, the required result objects and the ownership of product logic and data to evaluate vendors meaningfully.

This insight organizes nine readiness dimensions through five perspectives: product, process, data, systems and organization. These perspectives are not maturity stages. Together, they show whether a robust business standard exists for system selection, proof of concept and pilot.

Readiness does not require every detail to be finalized before the project begins. It requires sufficient clarity for the next irreversible decision. Critical foundations include a defined scope, transparent product and process classes, unambiguous core objects, clear system roles and long-term ownership of the product model.

The integrated quick check therefore provides a clarification profile rather than a score or ranking. Insight 203 ends with a validated pilot scope and a robust basis for comparison. Insight 202 then addresses criteria, longlist, shortlist, use-case benchmark, proof of concept and the final decision proposal.