CPQ-Systemauswahl ist kein Softwarevergleich

1. Warum Funktionslisten in die Irre führen

Funktionslisten erzeugen den Eindruck von Objektivität. Sie ordnen Anbieter entlang einer gemeinsamen Skala und suggerieren, dass die Lösung mit den meisten erfüllten Kriterien die beste sei. Tatsächlich verschieben sie die Bewertung häufig auf eine Ebene, auf der die relevanten Unterschiede kaum sichtbar werden. Nahezu jedes ernstzunehmende CPQ-System kann konfigurieren, Preise berechnen, Angebote erzeugen und Dokumente ausgeben. Ob es dies auf eine Weise tut, die zum Produktmodell, zur Datenhoheit und zur Zielarchitektur eines konkreten Unternehmens passt, lässt sich durch eine allgemeine Häkchenliste nicht beurteilen.

Zwei Systeme können dieselbe Funktion anbieten und dennoch grundlegend verschieden arbeiten. Das eine erwartet ein zentrales Produktmodell, das andere verteilt Logik auf mehrere Komponenten. Das eine eignet sich für eine tiefe technische Konfiguration mit Stücklistenauflösung, das andere ist stärker auf vertriebliche Paketierung und Angebotsprozesse ausgerichtet. Das eine integriert sich eng in eine bestimmte ERP- oder CRM-Welt, das andere ist bewusst offener angelegt. Eine Funktionsliste macht diese architektonischen Unterschiede häufig unsichtbar, obwohl genau sie später über Integrationsaufwand, Pflegefähigkeit und Skalierbarkeit entscheiden.

Hinzu kommt ein zweites Problem: Funktionslisten lenken den Blick auf Symptome. Ein Unternehmen mit langen Angebotszeiten sucht dann nach einem schnellen Angebotsprozess. Die Ursache liegt jedoch häufig nicht im fehlenden Werkzeug, sondern in unklaren Produktstrukturen, uneinheitlichen Stammdaten, unzureichender Modularisierung oder einer fehlenden Trennung zwischen Standard-, Varianten- und Projektgeschäft. Ein System, das auf ein ungelöstes Strukturproblem gesetzt wird, beschleunigt im Zweifel nur dessen Verbreitung. Software kann eine tragfähige Produktlogik operationalisieren. Sie kann sie nicht ersetzen.

2. Die falsche Reihenfolge

Viele Auswahlprojekte beginnen mit einer Ausschreibung. Damit wird stillschweigend unterstellt, die Anforderungen seien bereits bekannt und müssten nur noch dem Markt vorgelegt werden. Projekterfahrung zeigt jedoch, dass die Anforderungsdefinition der schwierigste und wertvollste Teil des Vorhabens ist. Wird sie verkürzt, beschreibt die Ausschreibung häufig nicht das zukünftige Zielbild, sondern den heutigen Zustand mit seinen Medienbrüchen, Doppelarbeiten und historisch gewachsenen Sonderwegen.

Anbieter beantworten solche Ausschreibungen in der Regel korrekt. Sie beantworten aber möglicherweise nicht die eigentliche Frage des Unternehmens. Der Zuschlag geht dann an das System, das im Vergleich am besten abschneidet, nicht an das System, das die zukünftige Aufgabe am besten löst. Die Folgen werden meist erst in der Einführung sichtbar: Das gewählte Werkzeug setzt eine Produktlogik voraus, die nicht vorhanden ist; Schnittstellen müssen nachträglich neu gedacht werden; Verantwortlichkeiten bleiben ungeklärt; oder das Unternehmen versucht, bestehende Schwächen durch kundenspezifische Anpassungen zu konservieren.

Software kann eine tragfähige Produktlogik operationalisieren. Sie kann sie nicht ersetzen.

3. Vorbereitung ist die eigentliche Auswahlleistung

Am Anfang steht ein belastbares Zielbild. Es beschreibt, welche Kundengruppen und Vertriebskanäle unterstützt werden sollen, welche Teile des Portfolios standardisiert oder konfiguriert werden können, wo Engineering erforderlich bleibt und welche Ergebnisse der Prozess liefern muss. Dazu gehören nicht nur Angebote, sondern je nach Geschäftsmodell auch technische Spezifikationen, Preise, Kosten, Zeichnungen, Stücklisten, Arbeitsvorbereitung, Freigaben und Übergaben an nachgelagerte Systeme.

Das Zielbild verbindet Geschäftsmodell, Portfolio und Prozess. Es schafft einen gemeinsamen Maßstab für Vertrieb, Produktmanagement, Engineering, Operations und IT. Ohne diesen Maßstab bleibt die Auswahl eine Sammlung von Einzelanforderungen. Jede Fachfunktion optimiert dann ihren eigenen Ausschnitt, während das Gesamtmodell ungeklärt bleibt. Genau daraus entstehen später widersprüchliche Erwartungen: Der Vertrieb fordert maximale Flexibilität, das Engineering belastbare Regeln, die IT geringe Komplexität und die Fertigung stabile Strukturen. Eine tragfähige Auswahl muss diese Perspektiven vor dem Marktvergleich zusammenführen.

4. Portfolio und Produkt-Prozess-Klassen als Ordnungsrahmen

Den Ausgangspunkt bildet das Portfolio. Ein Unternehmen, das überwiegend standardisierte Produkte in hoher Stückzahl verkauft, benötigt eine andere Lösung als ein Maschinen- oder Anlagenbauer, dessen Wertschöpfung zu wesentlichen Teilen in kundenspezifischem Engineering liegt. Die Portfolioanalyse trennt Produktfamilien, Varianten, Optionen, Wiederholteile, Ausläufer und Einzelfälle. Sie zeigt, wo Modularisierung bereits trägt, wo Produktlogik nur in Köpfen oder Excel-Dateien existiert und welche Bereiche für eine automatisierte Konfiguration überhaupt geeignet sind.

Dabei bewährt sich die Einordnung in Produkt-Prozess-Klassen. MTS, PTO, ATO, MTO, CTO, CTO+ und ETO beschreiben nicht nur unterschiedliche Fertigungs- oder Auftragsarten. Sie markieren verschiedene Grade von Vorfertigung, Konfigurierbarkeit, auftragsspezifischer Anpassung und Engineering. Die Klassen geben damit einen Ordnungsrahmen für die Frage, welche Produktanteile ausgewählt, konfiguriert, konstruktiv angepasst oder vollständig neu entwickelt werden.

Diese Einordnung ist auswahlentscheidend. Ein PTO- oder ATO-Geschäft benötigt vor allem sichere Auswahl, Paketierung, Verfügbarkeit und kommerzielle Abwicklung. Ein CTO-Geschäft verlangt belastbare Merkmals- und Regelmodelle sowie die Ableitung ausführbarer Strukturen. CTO+ verbindet standardisierte Konfiguration mit klar abgegrenzten Anpassungsspielräumen. ETO benötigt zusätzlich eine kontrollierte Übergabe in Engineering- und Projektprozesse. Wer diese Unterschiede nicht explizit macht, versucht häufig, sehr verschiedene Geschäftsarten mit einem einheitlichen Prozess und einem einheitlichen Modell abzudecken. Das führt entweder zu Überkomplexität oder zu unzulässiger Vereinfachung.

5. Produktstruktur, Datenmodell und Stammdaten

Konfiguration setzt eine tragfähige Produktstruktur voraus. Aus vertrieblichen Merkmalen und Regeln muss ein Ergebnis entstehen, das in Konstruktion, Fertigung und Auftragsabwicklung weiterverarbeitet werden kann. Dabei sind mehrere Sichten zu unterscheiden. Die Sales BOM beschreibt die vertriebliche Struktur und das, was gegenüber dem Kunden angeboten oder ausgewiesen wird. Die Engineering BOM bildet die konstruktive Produktsicht ab. Die Manufacturing BOM beschreibt die fertigungsgerechte Struktur. Diese Sichten beziehen sich auf dasselbe Produkt, folgen aber unterschiedlichen Zwecken und dürfen nicht unreflektiert gleichgesetzt werden.

Eine besondere Rolle spielt die Maximal- oder 150-Prozent-Struktur. Sie beschreibt den zulässigen Variantenraum, aus dem für einen konkreten Auftrag eine eindeutige Ausprägung abgeleitet wird. Wo diese Struktur geführt wird, welches System die Regeln verantwortet und an welcher Stelle die Transformation von der Vertriebssicht zur Engineering- oder Fertigungssicht erfolgt, sind zentrale Architekturentscheidungen. Sie bestimmen nicht nur die technische Umsetzung, sondern auch Pflegeaufwand, Änderungsprozesse und Verantwortlichkeiten.

Stammdatenqualität ist dabei keine nachgelagerte Fleißarbeit. Fehlende Eindeutigkeit bei Merkmalen, Materialien, Einheiten, Klassifikationen oder Gültigkeiten führt unmittelbar zu unsicheren Konfigurationsergebnissen. Ein CPQ-System kann nur so verlässlich arbeiten wie die Produktdaten, auf denen es aufsetzt. Wer Datenbereinigung und Modellierung in die Einführungsphase verschiebt, verlagert das Projektrisiko lediglich nach hinten.

6. Mehr als Konfiguration: Guided Selling, Pricing, Costing und Dokumente

Ein industrielles CPQ-Zielbild umfasst mehr als die technische Gültigkeit einer Variante. Guided Selling übersetzt Kundenanforderungen in eine geeignete Produkt- oder Lösungswahl. Dabei geht es nicht nur um komfortable Dialoge, sondern um die bewusste Führung durch Portfolio, Einsatzbedingungen, Leistungsgrenzen und kaufmännische Alternativen. Gerade bei komplexen Produkten muss klar getrennt werden, welche Fragen der Kunde beantworten kann, welche Informationen der Vertrieb ergänzt und an welcher Stelle technische Expertise erforderlich wird.

Pricing und Costing sind ebenfalls getrennt zu betrachten. Der Verkaufspreis kann aus Listenpreisen, Optionspreisen, Zuschlägen, Rabatten, Ländern, Kundengruppen oder Vertragskonditionen entstehen. Die Herstellkosten folgen einer anderen Logik und können Materialien, Arbeitsgänge, Standorte, Losgrößen, Beschaffung, Engineering-Aufwand und Risiken berücksichtigen. Im Maschinen- und Anlagenbau ist die kostenbezogene Bewertung einer Konfiguration häufig anspruchsvoller als die reine Preisfindung. Ein System, das Pricing gut beherrscht, ist deshalb nicht automatisch für belastbares Costing geeignet.

Angebotsdokumente, technische Spezifikationen, Zeichnungen und Visualisierungen greifen auf dasselbe Produktmodell zurück. Sie sind keine dekorativen Zusatzfunktionen, sondern sichtbare Ergebnisse der zugrunde liegenden Architektur. Eine überzeugende Visualisierung kann den Vertrieb unterstützen, ersetzt aber keine konsistente Produktstruktur. Ein hochwertiges Angebotsdokument ist nur dann belastbar, wenn Konfiguration, Preise, technische Daten und Gültigkeiten aus kontrollierten Quellen stammen.

7. Systemrollen, Datenhoheit und Zielarchitektur

Kein einzelnes System führt sämtliche Produktinformationen sinnvoll allein. CRM hält Kunden, Opportunities und Vertriebsaktivitäten. PIM stellt marktorientierte Produktinformationen bereit. PLM verantwortet Produktdefinitionen, Strukturen, Dokumente, Stände und Änderungen. CPQ verbindet Anforderungen, Auswahl, Konfiguration, Preisbildung und Angebot. CAD erzeugt konstruktive Geometrien und Unterlagen. ERP führt Materialien, Beschaffung, Fertigung, Kosten, Auftrag und Logistik. Je nach Unternehmen kommen weitere Systeme für MDM, E-Commerce, Dokumentenmanagement oder Projektabwicklung hinzu.

Die entscheidende Frage lautet nicht, welches System möglichst viele Aufgaben übernehmen kann. Sie lautet, welches System für welches Datenobjekt in welcher Lebenszyklusphase führend sein soll. Datenhoheit ist deshalb nicht pauschal einem System zuzuweisen. Sie muss für Merkmale, Regeln, Module, Preise, Kosten, Dokumente, Stücklisten, Gültigkeiten und Ergebnisobjekte differenziert definiert werden. Ebenso wichtig ist die Festlegung, wer fachlich für diese Objekte verantwortlich ist und wie Änderungen freigegeben werden.

Erst aus dieser Rollenverteilung entsteht die Zielarchitektur. Sie beschreibt, wo Produktlogik entsteht, wie sie genutzt und wie sie an nachgelagerte Systeme übergeben wird. Wo dieselbe Logik mehrfach modelliert wird, entstehen Doppelpflege, widersprüchliche Ergebnisse und dauerhaft erhöhte Betriebskosten. Eine belastbare Architektur minimiert nicht jede Redundanz um jeden Preis, macht sie aber bewusst, beherrschbar und eindeutig verantwortlich.

Dabei sind nicht nur einzelne Produkte, sondern auch Lösungsverbünde zu bewerten. SAP AVC kann beispielsweise in einer geeigneten Gesamtarchitektur eine belastbare industrielle Konfigurationskomponente bilden, etwa im Zusammenspiel mit SAP CPQ oder mit Frontend- und Orchestrierungsansätzen wie MOCA. Ebenso können spezialisierte Lösungen, beispielsweise von SAE Schaarschmidt, für bestimmte Produktmodelle und Prozesskontexte passend sein. Diese Beispiele sind weder Rangliste noch Empfehlung. Sie zeigen vielmehr, dass die Eignung nicht am Produktnamen, sondern an Systemrolle, Modellierungslogik, Integrationsfähigkeit und Betriebsmodell zu beurteilen ist.

8. Governance entscheidet über die Dauerhaftigkeit

Viele CPQ-Projekte behandeln Governance erst nach der Systementscheidung. Das ist zu spät. Produktmodelle, Merkmale, Regeln, Preise und Dokumente verändern sich kontinuierlich. Ohne klare Eigentümerschaft veralten sie, werden lokal ergänzt oder in Schattenlösungen umgangen. Die Einführung eines CPQ-Systems schafft daher neue dauerhafte Aufgaben: Modellverantwortung, Freigabe, Qualitätssicherung, Änderungsmanagement, Releaseplanung und Support.

Diese Aufgaben lassen sich nicht an die IT delegieren. Sie verantwortet Plattform, Integration, Sicherheit und Betrieb; die fachliche Verantwortung für Produktlogik und kommerzielle Regeln liegt dagegen in Produktmanagement, Engineering, Vertrieb oder Pricing. Die konkrete Ausgestaltung kann variieren. Vor der Auswahl muss jedoch erkennbar sein, wer das spätere Modell dauerhaft führt und weiterentwickelt.

9. Betriebsmodell, Sicherheit und Releasefähigkeit

Neben der fachlichen Architektur prägen übergreifende Anforderungen die Auswahl. Dazu gehören SaaS, Private Cloud, On-Premises sowie Single- oder Multi-Tenant-Modelle. Diese Begriffe sind nicht als einfache Rangfolge zu verstehen. Entscheidend ist, welches Betriebsmodell zu Sicherheitsanforderungen, Integrationsbedarf, Datenklassifikation, globaler Organisation und gewünschter Innovationsgeschwindigkeit passt.

Identity Management, Rollen- und Rechtekonzepte, Mandantentrennung, Protokollierung, Verfügbarkeit und Wiederanlauf müssen früh betrachtet werden. Gerade bei externen Nutzern, Partnern, Händlern oder anonymen Webzugängen entstehen andere Anforderungen als bei einer rein internen Vertriebslösung. Auch die Frage, welche Produkt- und Kundendaten eine Cloud-Umgebung verlassen dürfen, kann die Architektur maßgeblich beeinflussen.

Ebenso relevant ist die Releasefähigkeit. Ein System muss über Jahre aktualisiert werden können, ohne dass kundenspezifische Anpassungen jeden Versionswechsel blockieren. Die vermeintlich komfortable Sonderentwicklung während der Einführung kann später zur teuersten Form der Abhängigkeit werden. Deshalb sind Erweiterungsmechanismen, Konfigurierbarkeit, APIs, Testbarkeit und Migrationspfade nicht technische Nebenthemen, sondern Kriterien für die langfristige Wirtschaftlichkeit.

Die entscheidende Frage lautet nicht, welches System möglichst viele Aufgaben übernimmt, sondern welches System für welches Datenobjekt in welcher Lebenszyklusphase führend sein soll.

10. KI unterstützt die Auswahl, ersetzt aber keine Architekturentscheidung

Künstliche Intelligenz kann Marktinformationen strukturieren, Anforderungen konsolidieren, Dokumente vergleichen und Lücken sichtbar machen. Auch bei Use Cases, Bewertungsfragen und Testfällen entsteht ein erheblicher Produktivitätsgewinn. Für Recherche, Strukturierung und Dokumentation ist KI damit ein wertvolles Werkzeug.

Ihre Grenze liegt dort, wo nicht öffentliche Projekterfahrung, Unternehmenskontext und architektonisches Urteil erforderlich sind. Tatsächliche Integrationsaufwände, gescheiterte Einführungen, Herstellerstrategien, organisatorische Widerstände und spätere Pflegekosten sind nur begrenzt öffentlich verfügbar. Ob eine Modellierungslogik zum Unternehmen passt, lässt sich daher nicht aus allgemeinen Produktbeschreibungen ableiten.

11. Gewichtete Kriterien statt Häkchenlisten

Nach der fachlichen und architektonischen Klärung können Auswahlkriterien formuliert werden. Sie sollten aus Zielbild, Use Cases und Risiken abgeleitet sein. Dabei ist nicht jedes Kriterium gleich wichtig. Einige Funktionen sind komfortabel, aber ersetzbar. Andere entscheiden über die Tragfähigkeit der gesamten Lösung. Die Fähigkeit, eine relevante Produktstruktur abzubilden, kann beispielsweise wesentlich höher zu gewichten sein als eine einzelne Oberfläche oder Standardvorlage.

Eine belastbare Bewertungsmethodik unterscheidet fachliche Eignung, Architektur, Integration, Betrieb, Sicherheit, Implementierbarkeit, Anbieter- und Partnerfähigkeit sowie Wirtschaftlichkeit. Sie macht Muss-Kriterien sichtbar, verhindert aber zugleich, dass die Auswahl auf eine rein binäre Erfüllungslogik reduziert wird. Entscheidend ist nicht nur, ob eine Anforderung grundsätzlich erfüllt wird, sondern mit welchem Modellierungsaufwand, welchen Abhängigkeiten und welchen Folgen für den späteren Betrieb.

12. Von Longlist und Shortlist zum belastbaren Nachweis

Die Shortlist verengt den Kreis anhand weniger, gewichteter und architekturkritischer Kriterien. Anbieterworkshops sollten nicht aus einer Folge standardisierter Produktpräsentationen bestehen. Sie müssen konkrete, für alle Teilnehmer vergleichbare Szenarien adressieren. Dazu gehören typische Vertriebsfälle, komplexe Grenzfälle, Änderungen, Fehlerbehandlung, Preis- und Kostenlogik, Dokumente sowie Übergaben an andere Systeme. Nur so wird sichtbar, wie ein System tatsächlich arbeitet und welche Annahmen es über Datenmodell und Prozesse trifft.

Der Proof of Concept verlagert die Bewertung von der Aussage zum Nachweis. Ein repräsentativer Ausschnitt des eigenen Portfolios wird mit realen Merkmalen, Regeln, Strukturen und Daten abgebildet. Dabei sollten nicht nur ideale Standardfälle demonstriert werden. Aussagekräftig sind vor allem die architekturkritischen Stellen: mehrstufige Strukturen, Abhängigkeiten, regionale Varianten, Änderungen, Ableitungen, Integrationen und Grenzfälle zwischen CTO und ETO.

Ein Pilot geht darüber hinaus. Er prüft nicht nur technische Machbarkeit, sondern auch Arbeitsweise, Governance, Datenversorgung, Rollen und Betriebsfähigkeit in einem begrenzten realen Umfang. Proof of Concept und Pilot dürfen deshalb nicht verwechselt werden. Der Proof of Concept beantwortet die Frage, ob und wie eine Lösung eine kritische Aufgabe abbildet. Der Pilot zeigt, ob das Unternehmen mit dieser Lösung unter realen Bedingungen arbeiten kann.

13. Architekturentscheidung statt Einkaufsentscheidung

Die Auswahl eines CPQ-Systems ist keine isolierte Einkaufsentscheidung. Sie legt fest, wie ein Unternehmen seine Produktvielfalt strukturiert, wie es Kundenanforderungen in gültige Lösungen übersetzt und wie es Ergebnisse durch Vertrieb, Engineering, Fertigung und Service führt. Das gewählte System ist Ausdruck dieser Architektur, nicht ihr Ausgangspunkt.

Wer die Reihenfolge umkehrt und mit dem Werkzeug beginnt, passt häufig die eigene Produkt- und Prozesslogik an die Annahmen der Software an. Das kann in Einzelfällen sinnvoll sein, wenn diese Annahmen bewusst übernommen werden. Problematisch wird es, wenn diese Anpassung unbemerkt geschieht und erst während der Einführung sichtbar wird. Dann wird aus einer vermeintlichen Softwareauswahl eine kostspielige nachträgliche Klärung von Produktmodell, Organisation und Systemrollen.

Die eigentliche Softwarebewertung ist deshalb der letzte Schritt eines längeren Weges. Sie gewinnt ihre Aussagekraft aus der Vorbereitung, die ihr vorausgeht. Ein Unternehmen, das Zielbild, Portfolio, Produkt-Prozess-Klassen, Produktstruktur, Datenmodell, Governance und Zielarchitektur geklärt hat, weiß, wonach es sucht. Es kann Anbieter gezielt prüfen, Aussagen belastbar verifizieren und Risiken bewusst abwägen.

Die wichtigste Frage einer CPQ-Auswahl lautet daher nicht: Welches System ist das beste? Sie lautet: Welche Produkt-, Prozess- und Systemarchitektur soll das Unternehmen künftig beherrschen – und welches Werkzeug unterstützt sie dauerhaft am zuverlässigsten? Erst dann wird aus einem Softwarevergleich eine belastbare unternehmerische Entscheidung.

ENGLISH EXECUTIVE SUMMARY

CPQ System Selection Is Not a Software Comparison

A robust CPQ selection does not start with a vendor list. It starts with a clear target picture: which customers, sales channels and product-process classes must be supported, which parts of the portfolio can be standardized or configured, and which outputs are required for sales, engineering, manufacturing and order execution.

Feature checklists provide only superficial comparability. What matters are the underlying product model, data ownership, integration logic, governance, operating model and the ability to derive reliable commercial and technical results. SAP AVC, SAP CPQ, MOCA-oriented architectures and specialized industrial solutions must therefore be assessed as components of an overall solution architecture rather than as isolated products.

Only after this preparation do a longlist, shortlist, scenario workshops, proof of concept and pilot become meaningful. Selecting CPQ is therefore not merely a software procurement decision. It is a decision about the future product, process and system architecture of the company.