CPQ-SELECT · MARKT- UND WISSENSPLATTFORM

Orientierung im Markt der industriellen Produktkonfiguration

Systemklassen, Begriffe und Entscheidungsfragen – ohne Ranking und ohne Herstellerwerbung.

CPQ-SELECT ordnet einen Markt, der häufig unter einem einzigen Kürzel zusammengefasst wird, tatsächlich aber sehr unterschiedliche Aufgaben, Produktmodelle, Systemrollen und Ergebnisobjekte umfasst.

KERNAUSSAGE

Nicht das System definiert die Aufgabe. Produktlogik, Prozessklasse, Ergebnisobjekte und Zielarchitektur bestimmen, welche Systemrollen benötigt werden.

Ein Markt, viele Ausgangspunkte

CPQ steht für Configure, Price und Quote. Im industriellen Umfeld endet die relevante Prozesskette jedoch selten beim Angebot.

Sie beginnt bei Kunden- und Anwendungsanforderungen, führt über Produktauswahl, technische Konfiguration, Auslegung, Preis- und Kostenlogik sowie Dokumentenerzeugung und reicht bis zu belastbaren Übergaben an CRM, PLM, CAD, ERP, Fertigung, Service und Analytics. PIM stellt dabei in der Regel produkt- und vertriebsrelevante Informationen für CPQ bereit; Rückschreibungen aus CPQ in das PIM sind eher die Ausnahme.

Genau daraus entsteht die Unübersichtlichkeit des Marktes. Manche Lösungen sind aus CRM, Revenue Management und Angebotssteuerung gewachsen. Andere beginnen bei technischer Produktlogik, Variantenkonfiguration, Produktstrukturen, Konstruktion, Visualisierung oder operativer Auftragsabwicklung. Ähnliche Funktionsbezeichnungen verdecken diese Unterschiede eher, als dass sie sie erklären.

CPQ-SELECT beginnt deshalb nicht mit einer Rangliste von Produkten. Die Plattform fragt zuerst: Welche Nutzer arbeiten mit dem System? Welche Produkt- und Prozessklassen liegen vor? Welche Regeln, Preise, Dokumente und technischen Ergebnisse müssen entstehen? Welche Systeme führen Produktdaten, Stücklisten, Gültigkeiten und Aufträge? Erst aus dieser Ordnung wird ein belastbarer Marktvergleich.

Sechs Betrachtungsebenen schaffen ein gemeinsames Bild

Der Markt lässt sich entlang von sechs miteinander verbundenen Ebenen betrachten. Sie bilden keine starre Prozesskette und keine Rangfolge. Sie zeigen vielmehr, an welcher Stelle eine Lösung ihren fachlichen Schwerpunkt besitzt und welche Objekte dort verbindlich entstehen.

Ein System kann mehrere Ebenen unterstützen. Dennoch muss für jedes zentrale Objekt geklärt sein, welches System fachlich führt und welche Systeme Informationen lediglich nutzen, anreichern oder in eine andere Sicht überführen. Ohne diese Rollenklärung entstehen doppelte Merkmale, Regeln, Preise, Dokumente oder Strukturen – mit unterschiedlichen Gültigkeiten und Verantwortlichkeiten.

01Markt & VertriebAnforderung · Preis · Angebot
02ProduktlogikRegeln · Varianten · Berechnungen
03Produkt & LifecycleStruktur · Gültigkeit · Version
04Engineering & VisualisierungAuslegung · CAD · Geometrie
05Auftrag & WertschöpfungMaterial · BOM · Fertigung
06Publikation & NutzungPIM · DAM · Dokumente · BI
Aufgaben und Ergebnisobjekte im Detail
EbeneZentrale AufgabeTypische Objekte und Ergebnisse
1. Markt und VertriebBedarf erfassen, Lösung führen, konfigurieren, Preise und Angebote steuern.Anforderung, Opportunity, Auswahl, Preis, Rabatt, Angebot, Freigabe.
2. ProduktlogikZulässige Varianten, Regeln, Berechnungen und Abhängigkeiten beherrschen.Merkmale, Ausprägungen, Constraints, Berechnungen, Variantenraum, Konfigurationsstatus.
3. Produkt und LifecycleProduktdefinition, Gültigkeiten, Optionen und Änderungen über den Lebenszyklus steuern.Produktstruktur, Optionen, Gültigkeit, eBOM, Freigabe, Version, Baseline.
4. Engineering und VisualisierungGeometrie, technische Auslegung und kundenspezifische Ergebnisse automatisieren.CAD/ECAD, Zeichnung, Berechnung, Layout, Rendering, 2D/3D, BIM/IFC.
5. Auftrag und WertschöpfungKonfiguration in Auftrag, Material, Stückliste, Arbeitsplan, Kosten und Fertigung überführen.Auftrag, 100-%-BOM, mBOM, BOP, Material, Costing, Fertigungsauftrag.
6. Publikation und NutzungFreigegebene Produktinformationen, Medien, Dokumente und Nutzungsdaten für Kanäle bereitstellen.Katalogdaten, Medien, Datenblatt, Dokument, BIM-Objekt, Portalinhalt, Analyse.
Die Ebenen zeigen fachliche Schwerpunkte und Ergebnisobjekte – keine Rangfolge von Systemen.

Fünf Einstiege in CPQ-SELECT

Die Plattform ist bewusst als Referenz und Arbeitsinstrument aufgebaut. Jede Seite erfüllt eine eigene Rolle; keine Seite versucht, Marktordnung, Auswahlmethodik, Anbieterregister und Fachglossar gleichzeitig zu ersetzen.

01

Marktübersicht

Wie greifen Produkt-, Vertriebs-, Engineering-, Daten- und Auftragswelten ineinander?

Gemeinsames Bild der Systemrollen und Informationsflüsse
02

Systemklassen

Welche Lösungsarten übernehmen welche Kernaufgaben?

Sieben Klassen mit Ausgangspunkt, Ergebnisobjekten, Grenzen und Prüffragen
03

Anbieter A–Z

Welche Unternehmen und Marken sind aktuell sichtbar?

Neutraler, alphabetischer Ausgangspunkt mit offizieller Quelle und sichtbarem redaktionellen Stand
04

Glossar

Was bedeuten die zentralen Begriffe – und was gerade nicht?

110 präzise Definitionen, Entsprechungen, Abgrenzungen und Anker
05

Auswahlkriterien

Was muss vor Longlist, Shortlist und Proof of Concept geklärt sein?

Belastbare Entscheidungsstruktur ohne duplizierte Projektmethodik

MARKTORDNUNG

Sieben Systemklassen statt einer CPQ-Schublade

Ein reiner Funktionsvergleich erzeugt im CPQ-Markt schnell Scheingenauigkeit. Fast jedes etablierte System kann konfigurieren, Preise verarbeiten oder Dokumente erzeugen. Entscheidend ist, wie tief diese Funktionen ausgeprägt sind, auf welchem Produkt- und Regelmodell sie beruhen, wie Änderungen gepflegt werden und welche Ergebnisobjekte zuverlässig entstehen.

CPQ-SELECT unterscheidet deshalb sieben Systemklassen. Die Klassifikation dient der Klärung von Rollen, Erwartungen und Architekturgrenzen – nicht der dauerhaften Etikettierung eines Herstellers.

KEINE STARREN SCHUBLADEN

Moderne Plattformen überschneiden sich. Viele Unternehmen kombinieren mehrere Systeme.

Querschnittsfähigkeiten, die jede Klasse anders löst

Pricing, Visualisierung, Dokumente, Datenformate, Analytics, KI und Lifecycle sind keine zusätzlichen Systemklassen. Sie durchziehen mehrere Klassen und müssen deshalb immer im Zusammenhang mit Produktlogik und Zielarchitektur bewertet werden.

01

Pricing

Die Spannweite reicht von Cost-plus und Mark-up über merkmals-, options-, segment- und wertbasierte Modelle bis zu hybriden und dynamischen Ansätzen. Entscheidend sind nicht nur Formeln, sondern auch Preisobjekt, Datenquelle, Floor und Target Price, Discount-Governance, Freigaben, historische Reproduzierbarkeit und die Frage, ob Preis und technische Konfiguration im selben System geführt werden sollen.

02

Visualisierung

Visualisierung reicht von unterstützenden Bildern über Echtzeit-2D/3D, Rendering und AR/VR bis zu raumbezogener Konfiguration, CAD/ECAD-Ergebnissen und BIM-Objekten. Eine überzeugende Darstellung ist jedoch kein Nachweis für technische Gültigkeit, Preisrichtigkeit oder Herstellbarkeit. Sie muss aus einer belastbaren Logik abgeleitet werden oder mit ihr kontrolliert synchronisiert sein.

03

Dashboards und Analytics

Dashboards schließen den Regelkreis. Nutzungs-, Durchlaufzeit-, Preis-, Rabatt-, Margen-, Ausnahme- und Modellqualitätsdaten sind nur dann wertvoll, wenn sie eine konkrete Managemententscheidung stützen. Die Zahl der Charts ist kein Qualitätsmerkmal; maßgeblich sind eindeutige Definitionen, belastbare Datenquellen und verantwortliche Rollen.

AUSWAHLLOGIK

Auswahl beginnt vor der Software

Eine tragfähige Auswahl beginnt nicht mit Produktdemos. Zunächst müssen Zielbild, Scope, Nutzergruppen, Produkt-Prozess-Klassen, Produkt- und Regelkomplexität, Pricing und Costing, Ergebnisobjekte sowie Datenhoheit und Integrationsrollen geklärt werden.

Erst danach lässt sich bewerten, welche Systemklassen grundsätzlich passen und welche Anbieter in eine Longlist gehören. Ein Proof of Concept wird dann nicht zur Präsentation allgemeiner Funktionen, sondern zum Nachweis kritischer End-to-End-Szenarien mit realen Produktdaten, Regeln, Preisen, Dokumenten und Übergaben.

Die beste Lösung ist nicht das System mit der längsten Funktionsliste. Geeignet ist ein System, wenn Modellierungsansatz, Systemrolle, Ergebnisobjekte und Betriebsmodell zur konkreten Produkt-, Prozess- und Datenarchitektur des Unternehmens passen und über Jahre beherrschbar bleiben.

Was CPQ-SELECT leistet – und was nicht

CPQ-SELECT leistet

  • Einordnung von Markt, Systemrollen und Systemklassen.
  • Klärung zentraler Begriffe und Abgrenzungen.
  • Orientierung zu Auswahlkriterien und Nachweisen.
  • Neutrale, datierte Anbieterübersicht.
  • Verweise auf strategische und methodische Vertiefung.

CPQ-SELECT leistet nicht

  • Keine Rangliste einzelner Anbieter.
  • Keine Sterne, Scores oder Leader-Quadranten.
  • Keine bezahlten Platzierungen oder Herstellerwerbung.
  • Keine pauschale Produktempfehlung ohne Zielbild.
  • Keine zweite Beratungswebsite und kein Ersatz für Projektarbeit.

NEUTRALITÄTSGRUNDSATZ

Anbieter werden nicht nach Qualität, Marktstellung oder vermeintlicher Eignung bewertet. Die fachliche Orientierung erfolgt über Aufgaben, Systemklassen und Auswahlkriterien – nicht über Siegerlisten.

Rollenverteilung

PLATTFORM

CPQ-SELECT

Ordnet Markt, Systemklassen, Begriffe, Daten- und Ergebnisobjekte.

VERTIEFUNG

wuepping.com

Vertieft Strategie, Modularisierung, Produktarchitektur, Readiness und Vorgehensweisen in Executive Insights.

English executive summary

CPQ-SELECT provides a structured and neutral view of industrial product configuration. The platform explains system classes, terminology, architecture questions and selection criteria before individual software products are compared.

The market is not homogeneous. Sales-centric CPQ suites, industrial CPQ and product configuration, ERP-centric variant configuration, Configuration Lifecycle Management, PLM-centric variant management, design and engineering automation, and visual and spatial configuration address different parts of the value chain. Similar feature names often conceal major differences in modelling depth, lifecycle coverage, maintainability and output objects.

CPQ-SELECT does not rank vendors, publish scores or accept paid placements. Its core principle is simple: clarify product logic, process classes, result objects and target architecture first. Software selection is the consequence, not the starting point.