CPQ-SYSTEMKLASSEN
Sieben CPQ-Systemklassen im Markt der Produktkonfiguration
Ausgangspunkt, Systemrolle, Ergebnisobjekte und Grenzen
CPQ-SELECT unterscheidet sieben CPQ-Systemklassen, um die fachlichen und technischen Unterschiede bereits vor einer Anbieterbetrachtung sichtbar zu machen. Die Lösungen stammen aus sehr unterschiedlichen Systemwelten und folgen deshalb nicht derselben Logik.
Stand: August 2026
KLASSIFIKATIONSPRINZIP
Eine Systemklasse beschreibt den fachlichen Schwerpunkt einer Lösung. Sie ist weder Qualitätsurteil noch Aussage, dass ein Produkt nur diese eine Rolle beherrscht.
Warum CPQ-Systemklassen?
Ähnliche Funktionslisten bedeuten nicht dieselbe Systemlogik, Modellierungstiefe oder Verbindlichkeit der Ergebnisse.
Wie die CPQ-Marktübersicht zeigt, erzeugt ein reiner Funktionsvergleich schnell Scheingenauigkeit. Guided Selling, Konfiguration, Pricing, Dokumentenerzeugung, Stücklistenübergabe oder 3D-Visualisierung erscheinen in vielen Portfolios. Die gleiche Bezeichnung kann jedoch eine einfache Vertriebsfunktion, ein tiefes technisches Regelmodell oder eine vollständig integrierte Lifecycle-Funktion beschreiben.
CPQ-Systemklassen reduzieren diese Unschärfe. Sie ordnen Lösungen nach ihrem typischen Ausgangspunkt, ihrem führenden Modell, ihrer fachlichen Hauptrolle und den Ergebnisobjekten, die sie verlässlich erzeugen. Damit wird sichtbar, warum zwei Systeme trotz ähnlicher Oberfläche nicht austauschbar sind und warum ein Unternehmen für die gesamte Prozesskette häufig mehrere verbundene Systeme benötigt.
Viele Plattformen decken mehrere Klassen ab. Für die Einordnung ist deshalb nicht die Breite einer Produktbroschüre ausschlaggebend, sondern die primäre Systemlogik: Welche Objekte werden geführt? Wo werden Regeln gepflegt? Welche Ergebnisse entstehen verbindlich? Welche Rolle übernimmt das System im Änderungs-, Freigabe- und Betriebsprozess?
DIREKTEINSTIEG
Die sieben CPQ-Systemklassen
Die Klassen beschreiben typische fachliche Schwerpunkte, nicht die gesamte Bandbreite einzelner Produkte. Sie dienen als Marktordnung und Prüfrahmen – nicht als starres Anbieteretikett.
Orientierung auf einen Blick
Die Übersicht verdichtet Ausgangspunkt und Ergebnisobjekte der sieben Klassen. Die Detailprofile erläutern anschließend Fokus, Abgrenzung und zentrale Prüffrage.
Systemklassen, Ausgangspunkte und typische Ergebnisobjekte
| Nr. | Systemklasse | Typischer Ausgangspunkt | Typische Ergebnisobjekte |
|---|---|---|---|
| 1 | Vertriebszentrierte CPQ-Suiten | CRM, Opportunity, Quote und Revenue-Prozess. | Auswahl, Preis, Rabatt, Angebot, Freigabe, Vertrags-/Auftragsvorlage. |
| 2 | Industrielle CPQ- und Produktkonfiguration | Technische Produktlogik und Variantenprodukte. | Validierte Konfiguration, Spezifikation, Merkmale, technische Übergaben. |
| 3 | ERP-nahe Variantenkonfiguration | Material, Auftrag und operative Ausführung. | Auftragskonfiguration, BOM, Routing/BOP, Kosten, Fertigungsbezug. |
| 4 | Configuration Lifecycle Management | Konsistenz über Systeme und Lebenszyklus. | Versionierte Modelle, Regeln, Gültigkeiten, Konfigurationsstände. |
| 5 | PLM-nahe Variantenführung | Produktfamilie, Optionen, Struktur und Änderung. | Variantenstrukturen, Gültigkeiten, eBOM, Baselines, Freigaben. |
| 6 | Design- und Engineering-Automation | Berechnung, Geometrie und Engineering. | Berechnung, CAD/ECAD, Zeichnung, Layout, technische Dokumente. |
| 7 | Visuelle und raumbezogene Konfiguration | Interaktion, Darstellung, Planung und Raumbezug. | 2D/3D-Szene, Rendering, Layout, BIM-Objekt, visuelle Auswahl. |
DETAILPROFILE
Die CPQ-Systemklassen im Detail
Jede Klasse wird nach demselben Raster beschrieben: typischer Ausgangspunkt, fachliche Stärke, Grenzen, Ergebnisobjekte und die zentrale Frage für Architektur und Auswahl.
Die sieben Klassen sind Orientierungsprofile. Ihre konkrete Ausprägung bleibt produkt-, prozess- und architekturabhängig.
01
Vertriebszentrierte CPQ-Suiten
Vertriebszentrierte CPQ-Suiten beginnen beim Kunden-, Opportunity- und Angebotsprozess. Sie unterstützen den Vertrieb dabei, Bedarfe zu erfassen, passende Produkte oder Leistungen zusammenzustellen, Preise und Rabatte anzuwenden, Genehmigungen zu steuern und konsistente Angebote zu erzeugen. Die Nähe zu CRM, Revenue Management, Deal Desk und Quote-to-Cash prägt Benutzerführung und Prozesslogik.
Ihre Stärke liegt in der kommerziellen Orchestrierung: mehrere Vertriebskanäle, Rollen, Währungen, Preislisten, Konditionen, Freigaben, Dokumente, Vertragsbezüge und wiederkehrende Erlösmodelle können in einem kontrollierten Prozess verbunden werden. Guided Selling und Konfiguration dienen hier häufig dazu, den Vertrieb sicher durch ein Portfolio zu führen und ungültige Angebotskombinationen zu verhindern.
Die Grenze zeigt sich bei technisch tiefen Produkten. Herstellbarkeit, mehrstufige Stücklisten, Engineering-Berechnungen, Geometrie oder Lifecycle-gesteuerte Produktstrukturen können ein separates Produktmodell, PLM-, ERP- oder Engineering-System erfordern. Deshalb ist zu prüfen, ob die technische Tiefe für die verbindlichen Übergaben genügt oder ob die Suite bewusst als vertriebsnahe Schicht eingesetzt wird.
Fokus, Ergebnisobjekte, Abgrenzung und Prüffrage
| Aspekt | Einordnung |
|---|---|
| Typischer Fokus | Guided Selling, Opportunity- und Quote Management, Preis- und Rabattlogik, Genehmigungen, Dokumentenerzeugung, Partner- und Kanalunterstützung. |
| Typische Ergebnisobjekte | Bedarfsprofil, Produktauswahl, Preis, Rabatt, Angebot, Freigabestatus, Vertrags- oder Auftragsvorlage. |
| Abgrenzung | Technische Modellierungstiefe, Herstellbarkeitsprüfung und produktionsnahe Ergebnisse können begrenzt sein. |
| Zentrale Prüffrage | Reicht die technische Tiefe für Produktlogik und verbindliche Übergaben an Engineering und ERP? |
02
Industrielle CPQ- und Produktkonfiguration
Diese Klasse richtet den Blick auf technisch komplexe, variantenreiche Produkte. Im Mittelpunkt stehen Produktmodelle, Merkmale, Regeln, Berechnungen, Abhängigkeiten und die Absicherung zulässiger oder herstellbarer Konfigurationen. Die Systeme verbinden häufig Vertrieb, Produktmanagement, Application Engineering und nachgelagerte operative Systeme.
Der Wert entsteht aus der formalen Beherrschung des Lösungsraums. Vertriebsmerkmale werden in technische Ausprägungen übersetzt, Constraints schließen unzulässige Kombinationen aus, Berechnungen dimensionieren Komponenten und Ableitungen erzeugen strukturierte Ergebnisse. Je nach Lösung reicht der Scope von der Produktauswahl bis zu Stücklisten, technischen Dokumenten, Preisen und Auftragsdaten.
Entscheidend ist die Pflegefähigkeit des Produktmodells. Eine leistungsfähige Engine schafft noch kein tragfähiges Betriebsmodell. Wiederverwendung, Testbarkeit, Versionierung, regionale Gültigkeiten, Freigaben, Massenänderungen und verständliche Modellierung bestimmen, ob die Lösung langfristig beherrschbar bleibt.
Fokus, Ergebnisobjekte, Abgrenzung und Prüffrage
| Aspekt | Einordnung |
|---|---|
| Typischer Fokus | Technische Produktauswahl, regelbasierte Konfiguration, Plausibilitäts- und Herstellbarkeitsprüfung, Berechnungen, technische Dokumentation. |
| Typische Ergebnisobjekte | Validierte Konfiguration, Spezifikation, Merkmalsausprägungen, strukturierte Übergabedaten, gegebenenfalls Vertriebs- oder Produktionsstücklisten. |
| Abgrenzung | Pricing, komplexe Vertragslogik, operative Auftragsabwicklung oder Lifecycle-Governance können außerhalb liegen. |
| Zentrale Prüffrage | Wie belastbar, pflegbar und wiederverwendbar ist das Produktmodell über Vertrieb, Engineering und Ausführung? |
03
ERP-nahe Variantenkonfiguration
ERP-nahe Variantenkonfiguration verankert die Konfigurationslogik dicht an Materialstamm, Auftrag, Stückliste, Arbeitsplan, Kostenrechnung und Fertigung. Sie ist besonders relevant, wenn ein konfiguratives Ergebnis unmittelbar in operative Objekte und Prozesse überführt werden muss und das ERP als führendes System für Auftrags- und Produktionsabwicklung gesetzt ist.
Die Stärke liegt in der Durchgängigkeit zur Wertschöpfung. Merkmale und Regeln beeinflussen Materialpositionen, Stücklistenauflösung, Routing, Costing, Beschaffung, Termine und Fertigungsaufträge. Die Konfiguration ist damit nicht nur eine vertriebliche Auswahl, sondern Teil des transaktionalen Kerns.
Grenzen entstehen bei moderner Benutzerführung, anwendungsorientiertem Guided Selling, anonymen Webkanälen oder komplexen Lösungsdialogen. Häufig wird deshalb eine vertriebsnahe Schicht ergänzt. Die Architektur muss dann vermeiden, dass Vertriebs- und Produktionslogik doppelt gepflegt werden oder unterschiedliche Konfigurationsstände entstehen.
Fokus, Ergebnisobjekte, Abgrenzung und Prüffrage
| Aspekt | Einordnung |
|---|---|
| Typischer Fokus | Konfigurierbare Materialien, Auftragskonfiguration, Stücklisten- und Arbeitsplanauflösung, Costing, Beschaffung und Produktionsintegration. |
| Typische Ergebnisobjekte | Konfigurierter Auftrag, Material-/Variantenbezug, Produktionsstückliste, Arbeitsplan/BOP, Kosten und Termine. |
| Abgrenzung | Vertriebsführung, externe Kanäle und moderne Nutzererfahrung benötigen häufig eine ergänzende Schicht. |
| Zentrale Prüffrage | Soll das ERP die führende Konfigurationslogik tragen, und wie werden Vertrieb und externe Kanäle angebunden? |
04
Configuration Lifecycle Management
Configuration Lifecycle Management, kurz CLM, adressiert die Konsistenz von Varianten, Regeln und Konfigurationswissen über mehrere Prozesse und Systeme hinweg. Die Klasse entsteht aus der Erkenntnis, dass Produktlogik nicht nur im Angebot, sondern auch in Produktentwicklung, Engineering, Produktion, Service und Änderungswesen wirksam sein muss.
CLM kann als gemeinsame Modell-, Validierungs- oder Publikationsschicht dienen. Regeln und Optionen werden versioniert, auf Gültigkeit geprüft und für verschiedene Kanäle oder Systeme bereitgestellt. Konfigurationsstände und Baselines lassen sich über Releases und Lebenszyklusphasen nachvollziehen. Der Schwerpunkt liegt damit weniger auf einer einzelnen Oberfläche als auf Konsistenz und Governance.
Die zentrale Architekturfrage lautet, ob CLM tatsächlich eine führende, systemübergreifende Logik schafft oder nur ein weiteres Produktmodell neben PLM, CPQ und ERP einführt. Nutzen entsteht nur, wenn Objektverantwortung, Synchronisierung, Mapping, Freigabe und Exit-Fähigkeit klar geregelt sind.
Fokus, Ergebnisobjekte, Abgrenzung und Prüffrage
| Aspekt | Einordnung |
|---|---|
| Typischer Fokus | Systemübergreifende Modell- und Regelkonsistenz, Wiederverwendung, Gültigkeit, Versionierung, Validierung und Nachvollziehbarkeit. |
| Typische Ergebnisobjekte | Versionierte Modelle und Regeln, freigegebene Konfigurationsstände, Gültigkeiten, Mapping- und Validierungsinformationen. |
| Abgrenzung | CLM ist nicht automatisch Vertriebsfrontend, ERP-Ausführung oder Engineering-Automation. |
| Zentrale Prüffrage | Schafft die Lösung eine führende Lifecycle-Logik – oder lediglich ein weiteres Produktmodell? |
05
PLM-nahe Variantenführung
PLM-nahe Variantenführung beginnt bei Produktfamilien, Plattformen, Optionen, Produktstrukturen, Gültigkeiten, Freigaben und Änderungen. Sie unterstützt die Beherrschung von Vielfalt in der Produktdefinition und schafft die Grundlage dafür, Varianten über Entwicklung und Lifecycle nachvollziehbar zu führen.
Typisch sind 150-Prozent-Strukturen, Options- und Effectivity-Logik, eBOM, Baselines, Änderungsstände und die Verbindung zu technischen Dokumenten. Die Variantenlogik ist eng mit Reifegrad und Produktdefinition verbunden. Dadurch kann das PLM eine stabile Quelle für vertriebliche und operative Sichten bilden.
Die Grenze liegt häufig in Angebotsprozess, Pricing, Quote Management und vertriebsorientierter Benutzerführung. Auch die Umsetzung in mBOM, Arbeitsplan und Auftrag erfordert geklärte Übergaben. Entscheidend ist, wie die freigegebene Produktdefinition für Vertrieb, Konfiguration und Produktion nutzbar gemacht wird, ohne mehrere konkurrierende Modelle zu schaffen.
Fokus, Ergebnisobjekte, Abgrenzung und Prüffrage
| Aspekt | Einordnung |
|---|---|
| Typischer Fokus | Produktfamilien, Optionslogik, 150-%-Strukturen, Variantenregeln, Effectivity, Änderungs- und Freigabeprozesse, eBOM. |
| Typische Ergebnisobjekte | Optionen, Variantenstrukturen, freigegebene Produktdefinition, Gültigkeiten, eBOM, Dokumente und Baselines. |
| Abgrenzung | Angebotsprozess, Pricing und operative Auftragsabwicklung liegen meist nicht im Kern. |
| Zentrale Prüffrage | Soll die Produktdefinition im PLM die Variantenlogik führen, und wie wird sie für Vertrieb und Produktion nutzbar? |
06
Design- und Engineering-Automation
Design- und Engineering-Automation automatisiert technische Auslegung und konstruktive Ergebnisse. Sie wird relevant, wenn eine gültige Produktauswahl allein nicht genügt, sondern Geometrie, Berechnungen, Zeichnungen, Schaltpläne, Layouts, Stücklisten oder kundenspezifische Engineering-Dokumente erzeugt werden müssen.
Die Klasse arbeitet mit Parametrik, Regeln, Vorlagen, Skelett- oder Templatemodellen, Berechnungswissen und Knowledge-Based Engineering. Sie kann CTO+-Prozesse industrialisieren und wiederkehrende ETO-Anteile beschleunigen. Der wirtschaftliche Nutzen entsteht dort, wo Engineering-Aufgaben ausreichend wiederholbar, formal beschreibbar und testbar sind.
Design Automation ersetzt nicht automatisch Guided Selling, Pricing, Angebotssteuerung oder Lifecycle-Governance. Zu klären sind das auslösende Produktmodell, die Quelle der Parameter, der Status der erzeugten Engineering-Objekte und die Rückführung in PLM, ERP oder Dokumentation. Ein automatisch erzeugtes CAD-Modell ist nur dann belastbar, wenn Version, Regeln, Freigabe und Reproduzierbarkeit gesichert sind.
Fokus, Ergebnisobjekte, Abgrenzung und Prüffrage
| Aspekt | Einordnung |
|---|---|
| Typischer Fokus | Regel- und wissensbasierte Auslegung, Berechnung, CAD-/ECAD-Automation, Parametrik, Zeichnungs- und Dokumentengenerierung. |
| Typische Ergebnisobjekte | Berechnungsergebnis, dimensioniertes Produkt, CAD/ECAD, Zeichnung, Layout, Stückliste und technische Dokumentation. |
| Abgrenzung | Vertriebsprozess, Pricing und Lifecycle-Governance sind nicht automatisch abgedeckt. |
| Zentrale Prüffrage | Welche Engineering-Ergebnisse müssen automatisiert entstehen, und welches System führt die erforderliche Logik? |
07
Visuelle und raumbezogene Konfiguration
Visuelle und raumbezogene Konfiguration macht Produkte, Varianten und räumliche Zusammenhänge interaktiv sichtbar. Die Klasse reicht von produktbegleitender 2D- oder 3D-Darstellung über visuelles Guided Selling und Rendering bis zu Layoutplanung, Raumbezug, Augmented Reality, Virtual Reality und BIM-nahen Anwendungsfällen.
Die Visualisierung kann reine Präsentationsschicht sein oder aktiv in die Auswahl eingreifen. Geometrische Platzierung, Kollisionsprüfung, Mengenbildung und räumliche Beziehungen können das Konfigurationsergebnis beeinflussen. In Möbeln, Gebäudetechnik, Anlagenlayout und Komponentenplanung entstehen dadurch eigenständige Planungs- und Ergebnisobjekte.
Eine überzeugende Darstellung ist jedoch kein Nachweis für technische Gültigkeit, Preisrichtigkeit oder Herstellbarkeit. Zu klären ist, ob die Visualisierung aus einem führenden Produktmodell abgeleitet wird, ob sie eigene Regeln enthält und wie Änderungen synchronisiert werden. BIM- und 3D-Assets benötigen zudem definierte Eigenschaften, Detailgrade, Versionen und Freigaben.
Fokus, Ergebnisobjekte, Abgrenzung und Prüffrage
| Aspekt | Einordnung |
|---|---|
| Typischer Fokus | Interaktive Produktdarstellung, visuelle Auswahl, 2D/3D-Konfiguration, Raum- und Layoutplanung, Rendering, AR/VR und BIM. |
| Typische Ergebnisobjekte | Visualisierte Konfiguration, Szene, Rendering, Layout, Platzierung, Bild-/3D-Daten und BIM-Objekte. |
| Abgrenzung | Visualisierung allein belegt weder technische Gültigkeit noch Preisrichtigkeit oder Herstellbarkeit. |
| Zentrale Prüffrage | Ist die Visualisierung nur Präsentationsschicht – oder konsistenter Bestandteil der Produkt- und Konfigurationslogik? |
Überlappungen und hybride Plattformen
Die sieben Klassen sind bewusst fachlich definiert. Reale Softwareportfolios überschneiden sich. Eine vertriebszentrierte CPQ-Suite kann technische Regeln und 3D-Visualisierung enthalten; ein industrieller Konfigurator kann Pricing und Angebotsdokumente erzeugen; ein PLM- oder ERP-System kann eigene Konfigurationsfunktionen bereitstellen. Übernahmen, Produktbündel und Plattformstrategien verstärken diese Annäherung.
Für eine belastbare Einordnung reicht es deshalb nicht, Produktmodule zu zählen. Entscheidend ist, wo die führenden Modelle und Objekte liegen, wie Änderungen gepflegt werden, welche Ergebnisse verbindlich sind und welche Systemrolle im Zielbild tatsächlich übernommen werden soll.
Leitfragen für die Einordnung hybrider Plattformen
| Kriterium | Leitfrage für die Einordnung |
|---|---|
| Ausgangspunkt | Beginnt die Lösung bei Kunde und Quote, Produktlogik, Produktdefinition, Auftrag, Engineering oder Visualisierung? |
| Führendes Modell | Welches Produkt-, Regel-, Varianten-, Struktur-, Preis- oder Geometriemodell ist fachlich maßgeblich? |
| Ergebnisobjekte | Entstehen Angebot, valide Konfiguration, Stückliste, Arbeitsplan, CAD-Modell, Baseline, BIM-Objekt oder Visualisierung? |
| Lifecycle | Wie werden Versionen, Gültigkeiten, Freigaben, Änderungen und historische Reproduktion beherrscht? |
| Systemrolle | Ist die Lösung führendes System, Frontend, Ausführungssystem, Orchestrierungsschicht oder spezialisierter Service? |
Typische Kombinationen in der Systemarchitektur
Die Klassen erklären auch, warum CPQ-Architekturen in Industrieunternehmen unterschiedlich aussehen. Abhängig von Produkt, Prozessklasse und bestehender Systemlandschaft entstehen verschiedene Kombinationen. Nicht die Zahl der Systeme entscheidet über Qualität, sondern die Klarheit der Rollen und Übergaben.
Fünf typische Architekturmuster
| Architekturmuster | Typische Kombination | Charakteristische Fragestellung |
|---|---|---|
| Vertriebsgeführt | CRM und Sales CPQ plus technischer Konfigurator und ERP. | Wie wird einfache Vertriebsführung mit belastbarer technischer Logik verbunden? |
| ERP-geführt | ERP-nahe Variantenkonfiguration plus externes Vertriebsfrontend. | Wie werden ERP-Logik und moderne Nutzerführung ohne doppelte Regeln zusammengeführt? |
| PLM-/Lifecycle-geführt | PLM oder CLM plus CPQ-Kanäle und ERP-Ausführung. | Wie wird freigegebene Produktlogik systemübergreifend publiziert und geändert? |
| Engineering-geführt | Industrielle Konfiguration plus Design- und Engineering-Automation und ERP. | Wie werden CTO+ oder ETO-Ergebnisse automatisiert und reproduzierbar erzeugt? |
| Visuell erweitert | CPQ oder Konfigurator plus visuelle und raumbezogene Konfiguration. | Wie bleibt Darstellung synchron mit Regeln, Preis und Herstellbarkeit? |
Was die Systemklasse für die Auswahl bedeutet
Eine Longlist sollte nicht mit allen Anbietern beginnen, die den Begriff CPQ verwenden. Zuerst ist zu klären, welche Systemrolle im Unternehmen fehlt oder neu geordnet werden soll. Erst danach lässt sich entscheiden, welche Klassen grundsätzlich relevant sind und welche Überschneidungen gewünscht oder riskant sind.
Die Produkt-Prozess-Klasse verändert die Gewichtung. PTO, MTO, CTO, CTO+ und ETO erzeugen unterschiedliche Anforderungen an Regeln, Auslegung, Stücklisten, Engineering-Ergebnisse und Freigaben. Ebenso bestimmen Nutzer, Kanäle, Pricing, Datenhoheit und bestehende Kernsysteme, welche Kombination tragfähig ist.
Der Proof of Concept sollte nicht nur eine Oberfläche zeigen. Er muss den kritischen Pfad nachweisen: Modellierung, Konfiguration, Änderung, Test, Preis, Dokument, Ergebnisobjekte, Integration, Betrieb und Governance. Die Systemklasse schafft dafür den Prüfrahmen.
ARCHITEKTURGRUNDSATZ
Nicht ein System muss alle Klassen vollständig abdecken. Entscheidend ist eine klare Rollenverteilung: Wer führt Produktlogik, Preise, Strukturen, Geometrie und Auftrag – und wie bleiben diese Objekte konsistent?
Verbindliche englische Klassennamen
Deutsch–englische Bezeichnungen
| Deutsch | Englisch |
|---|---|
| Vertriebszentrierte CPQ-Suiten | Sales-centric CPQ suites |
| Industrielle CPQ- und Produktkonfiguration | Industrial CPQ and product configuration |
| ERP-nahe Variantenkonfiguration | ERP-centric variant configuration |
| Configuration Lifecycle Management | Configuration Lifecycle Management |
| PLM-nahe Variantenführung | PLM-centric variant management |
| Design- und Engineering-Automation | Design and engineering automation |
| Visuelle und raumbezogene Konfiguration | Visual and spatial configuration |
English executive summary
CPQ-SELECT distinguishes seven system classes in the market for industrial product configuration: 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.
The classes are defined by their primary starting point, leading model, lifecycle role and output objects. They are not vendor rankings and do not imply that a product can cover only one class. Modern platforms often combine several roles. A sound assessment therefore asks which system owns product logic, prices, structures, geometry and operational execution, and how these objects remain consistent across CRM, PIM, PLM, CAD, ERP and engineering.
The classification structures the market before a longlist is created. The relevant class depends on scope, users, product-process classes, required output objects, data ownership, lifecycle governance and the target architecture.