AUSWAHLKRITERIEN
CPQ-Auswahl beginnt mit der Aufgabe – nicht mit der Demo
Zwölf exemplarische Klärungsfelder vor Longlist, Shortlist und Proof of Concept
Eine belastbare Auswahl von CPQ- und Produktkonfigurationssystemen setzt voraus, dass Zielbild, Produktlogik, Prozessklassen, Ergebnisobjekte und Systemrollen vor der Anbietersichtung geklärt werden.
ENTSCHEIDUNGSREGEL
Nicht die Summe erfüllter Funktionen entscheidet. Maßgeblich ist, ob die kritischen Szenarien mit vertretbarem Modellierungs-, Integrations- und Pflegeaufwand beherrscht werden.
GRENZEN EINES REIN ÖFFENTLICHEN KRITERIENVERGLEICHS
Kriterienlisten sind leicht erzeugbar – belastbare Eignungsbewertungen nicht
Mit Suchmaschinen und generativer KI lässt sich heute in kurzer Zeit ein umfangreiches Kriterienset aus öffentlich verfügbaren Quellen zusammenstellen. Das ist hilfreich für Begriffsbildung, erste Strukturierung und Vollständigkeitskontrollen. Eine lange Liste ist jedoch noch keine belastbare Auswahlmethodik.
Öffentliche Informationen sind strukturell asymmetrisch. Hersteller veröffentlichen Funktionen, Stärken, Referenzen und erfolgreiche Anwendungen. Nicht geeignete Einsatzfelder, gescheiterte Modellierungsansätze, problematische Integrationen, dauerhaft hoher Pflegeaufwand oder organisatorische Voraussetzungen werden dagegen nur selten offen, vergleichbar und kontextbezogen dokumentiert.
Die eigentliche Schwierigkeit beginnt deshalb nach der Auswahl eines Kriteriums: Relevanz, Nachweis, Gewichtung und Erfüllungsgrad müssen für das konkrete Produkt-, Prozess- und Architekturmodell beurteilt werden. Ohne Projekterfahrung, Vergleichsmaßstäbe und einen realen Use Case bleibt die Bewertung häufig auf positive Herstellerangaben und formal vorhandene Funktionen beschränkt.
KI kann öffentliches Wissen schneller strukturieren. Sie kann jedoch nicht selbstständig Erfahrungswissen, negative Evidenz und Vergleichsmaßstäbe ersetzen, die öffentlich nicht verfügbar sind.
Öffentlich sichtbar und tatsächlich entscheidungsrelevant
Die zwölf Klärungsfelder und die nachfolgenden Nachweise sind bewusst exemplarisch. Der vollständige CPQ-SELECT-Kriterienraum umfasst mehr als 500 Einzelkriterien. In einem konkreten Auswahlprojekt werden daraus – abhängig von Zielbild, Produkt- und Prozessklassen, Systemlandschaft und Risikoprofil – typischerweise etwa 70 bis 120 priorisierte und bewertbare Kriterien relevant. Auch die Clusterung ist projektspezifisch und kann beispielsweise nach Nutzergruppen, Technologie und Sicherheit, Visualisierung und BIM, PLM/CAD und Engineering, Pricing und Costing, Daten und Integration, Betrieb und Governance oder Internationalisierung und Vertriebskanälen aufgebaut werden.
| Öffentlich leicht ermittelbar | Entscheidungsrelevant, aber selten öffentlich |
|---|---|
| Funktions- und Modulbeschreibungen | Tatsächlicher Modellierungsaufwand, Pflegefähigkeit und Abhängigkeit von Spezialwissen. |
| API-, Connector- und Cloud-Claims | Objektverantwortung, Fehlerverhalten, Versionsrisiken und End-to-End-Robustheit. |
| Security-Zertifikate und Betriebsangaben | Konkrete Passung zu IAM, Datenresidenz, Offline-Anforderungen, Werken und Governance. |
| Referenzen und Erfolgsgeschichten | Nicht geeignete Einsatzfelder, gescheiterte Muster, Voraussetzungen und Grenzen. |
ERFAHRUNGSBASIS
Knowledge Base aus mehr als 100 CPQ- und Konfigurationsprojekten
Die Kriterienlogik von CPQ-SELECT basiert nicht allein auf Funktionslisten und Herstellerangaben. Sie verdichtet Erfahrungen aus mehr als 100 CPQ- und Konfigurationsprojekten über unterschiedliche Branchen, Produkt-Prozess-Klassen, Systemarchitekturen und Reifegrade hinweg.
Die Wüpping Knowledge Base umfasst Anbieter- und Systemprofile, typische Stärken und Grenzen, Modellierungs- und Integrationsmuster, projektspezifische Benchmarks sowie kontextbezogene Eignungsgrade. Diese Inhalte sind nicht öffentlich zugänglich, weil sie aus vertraulichen Projekterfahrungen stammen und ohne Kontext leicht als allgemeingültiges Ranking missverstanden würden.
Ein zentrales Arbeitsmittel ist das Pilotdatenmodell – ein aus realen oder realitätsnahen Produktdaten des Unternehmens aufgebautes Testszenario – als realer Use Case. Es verbindet Produktstruktur, Merkmale, Regeln, Guided Selling, Pricing, Ergebnisobjekte, Dokumente und Systemübergaben in einem überprüfbaren End-to-End-Szenario. Dadurch wird sichtbar, welche Kriterien tatsächlich entscheidungsrelevant sind und wo Modellierungs-, Integrations- oder Betriebsrisiken liegen.
Erfahrungen aus Auswahl, Zielarchitektur, Produktmodellierung, Pilotierung, Integration und Roll-out.
Nicht öffentliche Anbieterprofile, typische Stärken und Grenzen, Benchmarks, Eignungsgrade und Risikomuster.
Reale Produktlogik, Regeln, Preise, Dokumente und Übergaben werden mit konkreten Daten nachgewiesen.
Auswahl in drei Stufen
Die Auswahl erfolgt in drei Stufen: Zunächst werden Aufgabe, Zielbild und Architektur geklärt. Anschließend wird eine begründete Longlist und Shortlist gebildet. Schließlich werden die kritischen Szenarien mit realen Daten in Pilotdatenmodell und Proof of Concept nachgewiesen.
Die größte Aussagekraft besitzen nicht allgemeine Produktdemos, sondern konkrete End-to-End-Szenarien vom Kundenbedarf bis zu Angebot, technischer Struktur, Preis, Dokument und Übergabe in die operativen Systeme. Eine professionelle Präsentation kann Orientierung geben, ersetzt aber keinen Nachweis für Modellierung, Änderung, Test, Integration und Betrieb.
Wirkung, Scope, Produkt- und Prozessklassen, Ergebnisobjekte, Datenhoheit und Zielarchitektur festlegen.
Öffentliche Primärquellen, Knowledge Base, Benchmarks, Ausschlussbedingungen und Eignungsgrade verbinden.
Reale Daten im Pilotdatenmodell und Proof of Concept einsetzen und Modellierung, Änderung, Integration und Betrieb prüfen.
BEISPIELHAFTE VERTIEFUNG INNERHALB DES ORIENTIERUNGSRAHMENS
Ein mögliches Cluster für Betrieb, Technologie und Sicherheit
Die zwölf Klärungsfelder bilden die oberste Struktur. Je nach Projekt werden einzelne Felder in detaillierte Untercluster und bewertbare Einzelkriterien zerlegt. Das folgende Beispiel zeigt eine mögliche Vertiefung; andere Projekte können stattdessen Visualisierung und BIM, PLM/CAD und Engineering, Pricing und Costing, Datenintegration oder internationale Kanäle wesentlich detaillierter gliedern.
Personas, interne und externe Nutzer, Rollenmodell, Berechtigungen, Funktionstrennung, Administration und nachvollziehbare Freigaben.
SaaS, PaaS, On-Premises oder Hybrid, Mandantenfähigkeit, Regionen, Datenresidenz, Verfügbarkeit, Skalierung und Offline-Fähigkeit.
SSO, MFA, IAM, Verschlüsselung, Logging, Auditierbarkeit, Schwachstellenmanagement, Datenschutz und relevante Nachweise.
Umgebungen, Releases, Monitoring, Backup und Wiederanlauf, API, Events, Batch, Performance, Support und Exit-Fähigkeit.
Die vier Untercluster sind keine vollständige Checkliste. Sie illustrieren, wie ein einzelner Bewertungsblock aus dem Gesamtbestand von mehr als 500 Kriterien projektspezifisch verdichtet werden kann.
DETAILPRÜFUNG
Die zwölf Klärungsfelder im Detail
01
Zielbild und wirtschaftlicher Auftrag
Vor jeder Systemdiskussion muss klar sein, welche Wirkung erreicht werden soll. Schnellere Angebote, höhere Angebotsqualität, bessere Margentransparenz, digitale Vertriebskanäle, Entlastung des Engineerings oder die durchgängige Ableitung von Stücklisten führen zu unterschiedlichen Schwerpunkten. Ein Zielbild muss deshalb Nutzen, Scope, Prioritäten, Zeithorizont und messbare Erfolgsgrößen verbinden.
PRÜFFRAGE
Welche messbare Verbesserung soll die erste Ausbaustufe erzielen – und welcher heutige Engpass muss dafür tatsächlich entfallen?
02
Produkt- und Prozessklassen
PTO, ATO, MTO, CTO, CTO+ und ETO stellen unterschiedliche Anforderungen an Produktmodell, Regeln, Engineering und Ergebnisobjekte. Ein einfaches Auswahl- und Angebotsmodell darf nicht unreflektiert mit einer ETO-Automation vermischt werden. Für jede Produktfamilie ist zu klären, welcher Teil stabil, wiederholbar und wirtschaftlich relevant genug ist, um in einem standardisierten Konfigurationsmodell abgebildet zu werden.
PRÜFFRAGE
Welche Produktfamilien und Prozessanteile sind stabil genug für Regelmodellierung – und wo bleibt bewusst Engineering?
03
Nutzer, Kanäle und Guided Selling
Interner Vertrieb, Händler, Service, Engineering, Planer und Endkunde benötigen unterschiedliche Einstiege, Sichten und Rechte. Ein gutes System trennt Produktwissen von der Benutzerführung und ermöglicht zielgruppengerechte Dialoge, ohne mehrere unverbundene Regelwerke aufzubauen. Guided Selling muss Bedarf und Anwendung verständlich erfassen und zugleich transparent machen, wie Empfehlungen entstehen. Das Rollen- und Berechtigungskonzept muss interne und externe Identitäten, Administration, Funktionstrennung und Freigaben nachvollziehbar abbilden.
PRÜFFRAGE
Welche Nutzer benötigen welche Entscheidungstiefe, und wie bleibt eine gemeinsame Produktlogik über alle Kanäle erhalten?
04
Produktmodell, Regelwerk und Pflege
Der langfristige Aufwand entsteht weniger durch die erste Oberfläche als durch Aufbau, Test, Freigabe und Änderung der Produktmodelle. Zu prüfen sind Ausdrucksmächtigkeit, Verständlichkeit, Wiederverwendung, Variantenraum, Versionsführung, Testbarkeit und die Trennung von Daten, Regeln und Darstellung. Dauerhafte Abhängigkeit von wenigen Spezialisten oder einem Implementierungspartner ist ein wesentliches Architektur- und Betriebsrisiko.
PRÜFFRAGE
Kann das Unternehmen Modelle, Regeln, Tests und Releases selbst beherrschen, dokumentieren und weiterentwickeln?
05
Pricing, Costing und kommerzielle Regeln
Preisfindung kann von Listenpreis und Rabatt bis zu Cost-plus, Mark-up, Zielmarge, merkmals- und optionsbasierten Zuschlägen, Value-based Pricing, Segmentlogik, Preis-Guidance und dynamischen Leitplanken reichen. Entscheidend ist, welche Logik im CPQ liegt, welche Werte aus ERP oder Pricing Engine kommen und wie Floor Price, Target Price, Discount und Freigaben zusammenwirken. Preis und technische Konfiguration müssen abgestimmt sein, sind aber nicht automatisch im selben System führend.
PRÜFFRAGE
Welche Preis- und Kostenobjekte werden wo geführt, und wie bleibt das Angebot historisch reproduzierbar?
06
Ergebnisobjekte und Durchgängigkeit
Die Qualität einer Lösung zeigt sich an den Ergebnissen, die nach der Konfiguration belastbar vorliegen. Ein Angebot ist nur eines davon. Abhängig vom Prozess können Spezifikationen, 100-%-Stücklisten, Arbeitspläne, Materialstämme, CAD/ECAD-Modelle, Zeichnungen, BIM-Objekte, Kalkulationen, Serviceinformationen oder Bestellpositionen erforderlich sein. Für jedes Ergebnis sind Identität, Version, Freigabe und Empfänger zu definieren.
PRÜFFRAGE
Welche Ergebnisobjekte müssen ohne manuelle Übersetzung entstehen, und welches System bestätigt ihre Gültigkeit?
07
Datenhoheit, Formate und Systemarchitektur
CRM, CPQ, PIM, PLM, CAD, ERP, DAM, DMS und Analytics besitzen unterschiedliche fachliche Autoritäten. Für Merkmale, Regeln, Produktstrukturen, Preise, Geometrie und Dokumente muss festgelegt sein, wo sie erzeugt, gepflegt, freigegeben und konsumiert werden. APIs und Datenformate lösen keine ungeklärte Verantwortung. Cloud- und Betriebsmodell, Mandantenfähigkeit, Regionen, Datenresidenz, Offline-Fähigkeit, Events, Batch, Fehlerbehandlung, IAM, Verschlüsselung, Logging, Security und Werkestrukturen gehören in dasselbe Bild.
PRÜFFRAGE
Welches System führt welches Objekt, wie wird es versioniert, und was geschieht bei Fehler, Änderung oder Rückfluss?
08
Visualisierung, Dokumente und digitale Assets
2D/3D, Rendering, AR/VR, CAD/ECAD, BIM/IFC, Datenblätter, Zeichnungen und Angebotsdokumente erfüllen unterschiedliche Zwecke. Eine visuelle Darstellung kann Beratung und Sicherheit verbessern, darf aber keine getrennte Produktlogik aufbauen. Zu prüfen sind Synchronität, Detailgrad, Performance, Rechte, Asset-Pipeline, Dokumentvorlagen, Sprachvarianten und Freigabestatus.
PRÜFFRAGE
Ist das visuelle oder dokumentarische Ergebnis aus der verbindlichen Konfiguration abgeleitet und für seinen Zweck freigegeben?
09
Analytics, Dashboards und Lernkreislauf
Nutzungs-, Prozess-, Preis-, Margen-, Rabatt- und Modellqualitätsdaten zeigen, ob die Lösung Wirkung erzielt. Kennzahlen benötigen eindeutige Definitionen, Datenquellen, Verantwortlichkeiten und eine steuerbare Entscheidung. Ein Dashboard ohne Governance produziert Aufmerksamkeit, aber keine Verbesserung. Auch Datenschutz, Rollen und zulässige Auswertung sind zu klären.
PRÜFFRAGE
Welche Entscheidung soll jede Kennzahl stützen, und wer ist für die Konsequenz verantwortlich?
10
Longlist und Shortlist
Eine Longlist wird aus der passenden Systemklasse, den Muss-Kriterien und den zwingenden Architekturbedingungen abgeleitet. Für die Shortlist werden nur wenige Anbieter vertieft betrachtet. Eine breite Demo-Runde ohne geklärte Prioritäten erzeugt viel Information, aber wenig Entscheidungssicherheit. DACH-Lieferfähigkeit, Partner, Produktstrategie und Betriebsmodell sind getrennt von Funktionsclaims zu prüfen.
PRÜFFRAGE
Welche Kriterien schließen einen Anbieter aus, bevor Zeit in Demos und Workshops investiert wird?
11
Proof of Concept
Der Proof of Concept ist kein Schönheitswettbewerb. Er soll Risiken sichtbar machen. Dazu werden reale Produkte, Regeln, Preise, Dokumente und Übergaben verwendet. Der Anbieter muss nicht nur ein vorbereitetes Ergebnis zeigen, sondern Modellierung, Änderung, Fehleranalyse, Test, Release und Betrieb nachvollziehbar demonstrieren. Kritische Szenarien werden vorab mit Erwartung, Messpunkt und Abbruchkriterium definiert.
PRÜFFRAGE
Welche zwei bis drei End-to-End-Szenarien entscheiden tatsächlich über Tragfähigkeit und Risiko?
12
Betrieb, Governance und Exit-Fähigkeit
Nach dem Go-live beginnt der eigentliche Lebenszyklus. Rollen, Verantwortlichkeiten, Releasezyklen, Testautomatisierung, Monitoring, Support, Security, Kostenentwicklung und Schulung bestimmen den nachhaltigen Nutzen. Ebenso wichtig sind Backup, Wiederanlauf, Auditierbarkeit, Schwachstellen- und Berechtigungsmanagement sowie Exit-Fähigkeit: Daten, Regeln, Templates, Skripte und Modelle müssen dokumentiert und soweit möglich exportierbar sein. Ein Projektwerkzeug kann wertvoll sein, ohne dauerhaft führendes System zu werden; dann müssen Ergebnisse kontrolliert in Kernsysteme überführt werden.
PRÜFFRAGE
Wie bleibt das Unternehmen handlungsfähig, wenn Produkt, Plattform, Implementierer oder Betriebsmodell sich ändern?
VORSELEKTION
Vorselektion auf belastbarer Bewertungsbasis
Die öffentliche Marktübersicht und der Kriterienrahmen zeigen die methodische Struktur, nicht jedoch die vollständige Bewertungsbasis. Für die Vorselektion werden aktuelle öffentliche Primärquellen mit der nicht öffentlich zugänglichen Wüpping Knowledge Base verbunden.
Die daraus abgeleiteten Eignungsgrade sind keine allgemeingültigen Rankings. Sie werden für das jeweilige Zielbild, die Produkt- und Prozessklassen, die bestehende Systemarchitektur und die kritischen Ergebnisobjekte neu gewichtet. Die Vorselektion reduziert den Markt auf fachlich plausible Kandidaten; sie ersetzt weder die Prüfung aktueller Produktstände noch Deep Dives und Proof of Concept.
Aktuelle Produktinformationen, Dokumentation, Referenzen, Architektur- und Betriebsangaben sowie regionale Lieferfähigkeit.
Nicht öffentlich zugängliche Erfahrungswerte aus mehr als 100 Projekten, Anbieterprofilen, Modellierungsansätzen und Integrationsmustern.
Projektbezogene Vergleichswerte und gewichtete Eignungsgrade für Systemklasse, Produktlogik, Architektur, Betrieb und kritische Szenarien.
Die internen Vergleichswerte sind keine käuflichen Platzierungen und keine öffentliche Rangliste. Sie dienen als begründeter Risikofilter und werden im konkreten Projekt anhand aktueller Nachweise validiert.
Strukturierte Longlist und Shortlist
- 01
Muss-Kriterien, Ausschlusskriterien und Bewertungslogik festlegen.
- 02
Relevante Systemklassen und Architekturvarianten bestimmen.
- 03
Anbieter anhand aktueller Primärquellen, Knowledge Base, Benchmarks, Lieferfähigkeit und Betriebsmodell vorsortieren.
- 04
Drei bis fünf Systeme in strukturierten Deep Dives mit identischen Szenarien vergleichen.
- 05
Zwei bis drei kritische Kandidaten im Proof of Concept mit realen Daten prüfen.
Nachweise im Proof of Concept
Die folgenden Szenarien sind exemplarisch. Der konkrete PoC konzentriert sich auf die wenigen End-to-End-Pfade, die Tragfähigkeit, Integrationsrisiko, Pflegeaufwand und Betriebsfähigkeit tatsächlich unterscheiden.
| PoC-Szenario | Nachweis |
|---|---|
| Guided Selling | Vom Kundenbedarf zu einer begründeten Produktempfehlung; Umgang mit unvollständigen Angaben und Alternativen. |
| Technische Konfiguration | Komplexe Regeln, Konfliktauflösung, Berechnung, Erklärbarkeit und valide Konfigurationsstände. |
| Änderung am Modell | Pflegeaufwand, Test, Version, Freigabe, Veröffentlichung und Rücknahme. |
| Pricing und Costing | Kostenquelle, Mark-up/Marge, Konditionen, Floor/Target, Freigabe und historische Reproduktion. |
| Dokumente und Visualisierung | Angebot, Datenblatt, Zeichnung, CAD/ECAD, 2D/3D oder BIM aus derselben Konfiguration. |
| End-to-End-Übergabe | CRM/CPQ bis ERP, PLM oder Engineering mit vollständigen Ergebnisobjekten und Fehlerbehandlung. |
| Betrieb | Rollen, Monitoring, Support, Security, Release, Skalierung und Exit-Fähigkeit. |
AUSWAHLGRUNDSATZ
Nicht Funktionsfülle, sondern beherrschbare Wirkung entscheidet
Eine belastbare Entscheidung verbindet priorisierte Kriterien mit Erfahrungswissen, aktuellen Nachweisen, realen Produktdaten und einem tragfähigen Betriebsmodell. Die Bewertungsmatrix entsteht aus dem Projekt – nicht aus einer universellen Demo-Checkliste.
English executive summary
Selecting a CPQ or product configuration platform should start with the business task, product-process classes, required output objects and the target architecture. Feature lists and generic demonstrations provide limited evidence because similar functions can be implemented with very different modelling depth, maintenance effort and lifecycle coverage.
Search engines and generative AI can quickly assemble extensive criteria lists from public sources. However, public information is structurally biased towards positive product claims and successful references. Non-fit cases, failed implementation patterns, maintenance effort, integration limits and organisational prerequisites are rarely available in a comparable form. The difficult task is therefore not generating criteria, but interpreting, weighting and validating them in context.
The twelve fields shown on this page are an illustrative management framework. The complete CPQ-SELECT criteria space contains more than 500 individual criteria; a specific project typically narrows these down to approximately 70 to 120 prioritised and assessable criteria. The clustering itself is project-specific.
The assessment combines current public primary sources with a non-public Wüpping knowledge base based on more than 100 CPQ and configuration projects, project-specific benchmarks and context-dependent suitability scores. A pilot data model serves as a real use case before critical candidates are tested in a proof of concept with real product data.