MARKTTRENDS
Marktentwicklung: Strukturelle Veränderungen statt kurzfristiger News
Zehn Entwicklungslinien für Produktmodelle, Systemarchitekturen und Investitionsentscheidungen
CPQ-SELECT beobachtet Entwicklungen, die Produktmodelle, Systemarchitekturen und Investitionsentscheidungen nachhaltig beeinflussen. Messeberichte und einzelne Release-Meldungen gehören nicht zu diesem Auftrag.
KERNAUSSAGE
Der Markt verschiebt sich vom Funktionsvergleich einzelner CPQ-Produkte zur durchgängigen Betrachtung von Produktmodellen, Lifecycle, Integrationen, Pricing, Analytics und Pflegefähigkeit.
REDAKTIONELLE EINORDNUNG
Trends beschreiben Richtungen – keine Anbieter
Die Seite benennt bewusst keine einzelnen Anbieter oder Produkte. Bereits die Auswahl eines Beispiels erzeugt Sichtbarkeit und kann als Hervorhebung oder implizite Systemklassenzuordnung gelesen werden. Die Entwicklungslinien werden deshalb konsequent anbieterneutral beschrieben.
Die Einordnung ist weder Marktanteilsanalyse noch Prognose. Sie verdichtet wiederkehrende Muster aus technischen Dokumentationen, Standards, Auswahlprojekten und realen Betriebsfragen. Eine Entwicklungslinie bleibt nur bestehen, wenn sie über einzelne Releases hinausreicht und Auswirkungen auf Produktmodell, Architektur, Ergebnisobjekte, Governance oder Betrieb hat.
ZEHN ENTWICKLUNGSLINIEN
Strukturelle Themen im Überblick
Die Übersicht führt direkt zu den zehn Entwicklungslinien. Entscheidend ist jeweils nicht die technische Möglichkeit allein, sondern ihre Wirkung auf Produktmodell, Architektur, Governance und Betrieb.
Die zehn Entwicklungslinien im Detail
Jede Entwicklungslinie wird an einer Managementfrage gespiegelt. Damit bleibt die Seite auf die langfristige Beherrschbarkeit ausgerichtet – nicht auf kurzfristige Funktionsversprechen.
01
Produktmodelle werden zum architektonischen Kern
Der Wert verschiebt sich von isolierten Oberflächen und Funktionslisten zu versionierten Produkt-, Regel-, Preis- und Ableitungsmodellen. Anbieterwechsel und Integration werden wesentlich davon bestimmt, wie nachvollziehbar, testbar und portabel diese Modelle sind.
Damit rückt eine oft unterschätzte Frage ins Zentrum: Ist das Modell ein dauerhaftes Unternehmensasset oder faktisch an Methode, Implementierer und Plattform gebunden? Exportformate allein reichen nicht. Begriffe, Regeln, Tests, Variantenstrukturen, Templates und Freigaben müssen dokumentiert und in ein nachvollziehbares Betriebsmodell eingebettet sein.
MANAGEMENTFRAGE
Ist das Produktmodell ein beherrschtes Unternehmensasset oder eine schwer lösbare Plattformabhängigkeit?
02
Lifecycle statt einmaliger Konfiguration
Konfigurationen müssen nicht nur gültig erzeugt, sondern über Änderungen, Freigaben, Aufträge, Service und historische Reproduktion beherrscht werden. Configuration Lifecycle Management gewinnt deshalb an Bedeutung.
Version, Gültigkeit, Baseline und Änderungswirkung werden zu gemeinsamen Themen von PLM, CPQ, ERP und Service. Unternehmen müssen entscheiden, ob eine zusätzliche Lifecycle-Schicht Konsistenz schafft oder nur ein weiteres Modell einführt.
MANAGEMENTFRAGE
Welches System führt Version, Gültigkeit und Baseline – und wie werden Änderungen über den Lebenszyklus nachgewiesen?
03
Headless, API-first und Ereignisarchitekturen
Konfigurations-, Pricing- und Dokumentfunktionen werden häufiger als Dienste in Portale, Commerce, CRM oder Apps eingebettet. Plattformen betonen API-first, REST-Schnittstellen, Events und komponierbare Revenue- oder Konfigurationsservices.
Der Nutzen entsteht nur, wenn fachliche Objektgrenzen, Versionen, Idempotenz und Fehlerbehandlung mit der technischen Entkopplung Schritt halten. Eine moderne API beseitigt keine doppelte Datenhoheit.
MANAGEMENTFRAGE
Sind Objektverantwortung, Wiederholbarkeit und Fehlerbehandlung ebenso klar wie die technische Schnittstelle?
04
KI wird Assistenz, nicht alleinige Instanz
KI unterstützt Bedarfsermittlung, Suche, Angebotstexte, Dokumente, Modellpflege, Anomalieerkennung und Analyse. Plattformen und Anwendungen werden um Assistenten für Modellierung, Guided Selling und Revenue-Prozesse erweitert.
Freigaberelevante Produkt-, Preis- und Baubarkeitsentscheidungen benötigen weiterhin kontrollierte Regeln, Quellen und Verantwortlichkeiten. KI kann Vorschläge erzeugen, Informationen strukturieren oder Ausnahmen erkennen; sie ersetzt nicht automatisch das freigegebene Produktmodell.
MANAGEMENTFRAGE
Welche KI-Ergebnisse sind Vorschlag, welche werden deterministisch geprüft und wer trägt die Freigabeverantwortung?
05
Pricing wird differenzierter und datenreicher
Cost-plus bleibt wichtig, wird aber mit merkmals-, segment-, wert- und marktbasierten Logiken kombiniert. Hybride Modelle, Mark-up- und Discount-Governance, Price Guidance, Floor und Target Price sowie dynamische Leitplanken erhöhen Nutzen und Architekturanspruch.
Die Trennung zwischen CPQ, Pricing Engine, ERP-Kosten, CRM-Konditionen und Data Platform wird damit wichtiger. Der Preis muss nicht nur richtig sein, sondern erklärbar, genehmigt und historisch reproduzierbar.
MANAGEMENTFRAGE
Welches System führt Kosten, Preis, Kondition und Freigabe – und wie bleibt die Entscheidung historisch erklärbar?
06
Dashboards schließen den Lernkreislauf
Nutzungs-, Prozess-, Preis-, Margen- und Qualitätsdaten fließen stärker in Produktmodell, Guided Selling und Governance zurück. Entscheidend ist nicht die Zahl der Charts, sondern die belastbare Verbindung zwischen Kennzahl und steuerbarer Entscheidung.
Price Realization, Discount, Margin Leakage, Quote Conversion, Ausnahmequote, Modelltestabdeckung und Datenqualität können unterschiedliche Verantwortliche adressieren. Ohne Definition und Entscheidungsprozess entsteht Beobachtung, aber keine Verbesserung.
MANAGEMENTFRAGE
Welche Kennzahl löst welche Entscheidung aus – und welche Rolle verantwortet die daraus folgende Änderung?
07
Visualisierung wird Teil der Entscheidung
Echtzeit-3D, Rendering, AR/VR und raumbezogene Konfiguration verbessern Verständnis und Sicherheit. Visualisierung wird zunehmend mit Produktlogik, Pricing, Dokumenten und Planung verbunden.
In Bauprodukten und Gebäudetechnik gewinnen BIM-Objekte und IFC-Austausch an Bedeutung. Dabei ist klar zu trennen zwischen Marketingvisualisierung, Planungsobjekt, Austauschgeometrie und freigegebenem Engineering-Ergebnis.
MANAGEMENTFRAGE
Welches visuelle Ergebnis dient nur der Kommunikation – und welches ist ein freigegebenes Planungs- oder Engineering-Objekt?
08
Semantische Interoperabilität wird wichtiger als reine Konnektivität
APIs sind verfügbar, doch unterschiedliche Objektbedeutungen bleiben die eigentliche Hürde. Klassifikations-, Katalog-, Engineering- und BIM-Standards helfen, ersetzen aber keine unternehmensspezifische Semantik und Governance.
ECLASS, ETIM, BMEcat, IFC, AutomationML, STEP, JT, glTF, OData oder OPC UA lösen jeweils bestimmte Austauschprobleme. Sie definieren nicht automatisch, welches System ein Merkmal, eine Gültigkeit oder eine freigegebene Konfiguration führt.
MANAGEMENTFRAGE
Wer verantwortet Bedeutung, Identität und Gültigkeit eines Objekts, wenn mehrere Standards und Systeme beteiligt sind?
09
Systemgrenzen werden durchlässiger – Rollen bleiben notwendig
CPQ, PIM, PLM, ERP, Commerce, Design Automation und Analytics nähern sich funktional an. Portfolios werden erweitert, Nachbarfunktionen integriert und Produkte zu Plattformen gebündelt.
Gerade deshalb müssen führende Objekte, Rückflüsse und Verantwortlichkeiten explizit bleiben. Eine Suite kann Übergaben erleichtern; sie hebt die fachliche Notwendigkeit klarer Rollen nicht auf.
MANAGEMENTFRAGE
Welches System ist für welches Objekt führend – und wie werden Rückflüsse, Konflikte und Freigaben gesteuert?
10
Exit-Fähigkeit wird Teil der Architekturqualität
SaaS- und Plattformmodelle erhöhen Geschwindigkeit, können aber Abhängigkeiten in Daten, Regeln, Templates, Skripten, Integrationen und Betriebsprozessen erzeugen. Portabilität, Dokumentation und reproduzierbare Exporte werden zu Auswahlkriterien.
Die größte Abhängigkeit entsteht selten durch die Benutzeroberfläche. Sie entsteht durch das Produktmodell und die Organisation, die es pflegt. Unternehmen sollten deshalb bereits bei der Einführung klären, welche Ergebnisse in Kernsysteme überführt werden, welche Modelle exportierbar sind und wie ein Wechsel praktisch möglich wäre.
MANAGEMENTFRAGE
Welche Modelle, Regeln, Daten und Ergebnisobjekte müssen portierbar sein – und wurde ein Wechsel praktisch durchgespielt?
BEOBACHTUNGSBASIS
Anbieterneutral, strukturell und rücknehmbar
Die Einordnung stützt sich nicht auf einzelne Messeclaims oder Produktankündigungen, sondern auf wiederkehrende Muster in technischen Dokumentationen, herstellerunabhängigen Standards, Auswahlprojekten und realen Betriebsfragen.
CPQ-SELECT nennt auf dieser Seite bewusst keine Systeme. Die Beobachtung beschreibt eine Richtung, nicht die Überlegenheit eines Produkts. Jede Aussage wird regelmäßig darauf geprüft, ob sie strukturell trägt, präzisiert werden muss oder entfernt werden sollte.
Eine Entwicklung muss über einzelne Releases und kurzfristige Marketingthemen hinausreichen.
Keine Produktnennung, keine Rangfolge und keine implizite Zuordnung eines Herstellers zu einer Systemklasse.
Nicht mehr belastbare Aussagen werden entfernt statt durch immer neue Zusätze künstlich fortgeschrieben.
Jährliche Prüffragen
Die Seite wird nicht durch zusätzliche Absätze aktuell gehalten. Aussagen, die nicht mehr tragen, werden präzisiert oder entfernt.
- 01
Welche Systemklassen oder Anbieterrollen haben sich tatsächlich verändert?
- 02
Welche Formate, Standards oder Betriebsmodelle sind für industrielle Anwendungen praktisch relevant geworden?
- 03
Welche Pricing- und Analytics-Fähigkeiten sind vom Pilotstatus in belastbaren Betrieb übergegangen?
- 04
Wo entstehen neue Abhängigkeiten durch Produktmodelle, KI-Dienste oder proprietäre Datenstrukturen?
- 05
Welche Aussagen dieser Seite sind nicht mehr belastbar und müssen entfernt statt fortgeschrieben werden?
NEUTRALE REFERENZPUNKTE
Standards an den Schnittstellen von CPQ, Produktdaten und Engineering
Die folgenden Standards sind keine CPQ-Standards. Sie werden relevant, wenn Produkt-, Merkmals- und Konfigurationsergebnisse zwischen CPQ, PIM, PLM, ERP, CAD, BIM, Engineering, Visualisierung und industriellen Anwendungen ausgetauscht werden. Die Auswahl ist exemplarisch und keine Empfehlung. Sie konkretisiert die in Abschnitt 8 beschriebenen Schnittstellen- und Semantikthemen, belegt jedoch weder die Verbreitung einer bestimmten Softwarefunktion noch die Eignung eines Systems.
Produktsemantik und Katalogdaten
Engineering, BIM und 3D-Austausch
Datendienste und industrielle Informationsmodelle
EINORDNUNGSGRUNDSATZ
Technologietrends sind nur relevant, wenn sie Beherrschbarkeit verbessern
Maßgeblich ist nicht, ob eine Funktion modern klingt. Entscheidend ist, ob Produktmodell, Ergebnisobjekte, Integration, Verantwortlichkeiten und Betrieb dadurch nachvollziehbarer, pflegbarer und weniger abhängig werden.
English executive summary
This page tracks structural developments rather than short-lived news or individual product releases. The ten themes cover lifecycle-controlled product models, API and event-driven architectures, AI-assisted work, advanced pricing, analytics, visual and spatial configuration, semantic interoperability, governance and exit capability.
The central shift is from comparing isolated product features to assessing the long-term quality of product models, result objects, integrations, maintainability and operating responsibilities. Technology creates value only when ownership, validity, testing, approval and change are governed across the lifecycle.
Vendor and product names are deliberately omitted. The trends describe directions, not rankings, recommendations or assignments of individual vendors to system classes. Neutral standards are referenced only where they clarify interoperability and data semantics.