ERP, PIM, CRM, CPQ – Überblick für Produktmanager
Autor: Elisabeth Sonnleitner
Produktmanager sehen sich heute mit einer Vielzahl an Systemen konfrontiert, die alle einen Teil der Produktwelt abbilden: ERP, PIM, CPQ, Shop, CRM. Jedes dieser Systeme verfolgt einen klaren Zweck – zumindest aus Sicht der jeweiligen Fachabteilung.
In der Praxis entsteht jedoch häufig ein anderes Bild:
Produktmanager sollen Produkte strukturieren, Varianten beherrschbar machen und gleichzeitig sicherstellen, dass Vertrieb, Marketing, Produktion und das Händlernetzwerk mit denselben Informationen arbeiten.
Dabei ist oft unklar, welches System eigentlich wofür zuständig ist – und welches nicht. Dieser Artikel soll dabei helfen, die Rollen der wichtigsten Systeme einzuordnen und eine fundierte Entscheidungsgrundlage zu schaffen.
Warum die Systemlandschaft für Produktmanager immer unübersichtlicher wird
Viele Systeme sind historisch gewachsen. ERP-Systeme wurden zuerst eingeführt, später kamen Shops, danach PIM-Systeme und schließlich Konfiguratoren oder CPQ-Lösungen.
Mit jedem zusätzlichen System wächst die funktionale Überschneidung:
- Unklare Zuständigkeiten: Mehrere Systeme verwalten dieselben Produktaspekte. Oft ist nicht eindeutig, welches System wofür verantwortlich ist.
- Doppelte und widersprüchliche Daten: Produktinformationen, Preise oder Varianten werden parallel gepflegt – Inkonsistenzen sind vorprogrammiert.
- Unterschiedliche Produktsichten: ERP, PIM, CRM und CPQ betrachten dasselbe Produkt aus völlig unterschiedlichen Perspektiven, die schwer zusammenzuführen sind.
- Komplexe Produkte lassen sich schlecht abbilden: Varianten, Abhängigkeiten und Regeln passen selten sauber in klassische ERP- oder PIM-Strukturen.
- Hoher Abstimmungsaufwand zwischen Teams: Produktmanagement, Vertrieb, Marketing und IT arbeiten mit unterschiedlichen Systemen – Entscheidungen brauchen viel Koordination.
Für Produktmanager heißt das: Sie sind verantwortlich für Themen, die sich über mehrere Systeme verteilen – oft ohne klare Zuständigkeiten. Die Folgen sind langsame Prozesse, fehlerhafte Informationen und Vertrauensverlust, intern wie extern.
Sehen wir uns die Systeme im Detail an:
1. ERP (Enterprise Resource Planning) - das operative Rückgrat
Ein ERP-System bildet die operative Realität eines Unternehmens ab. Es verwaltet Artikelnummern, Stücklisten, Preise, Lagerbestände, Lieferzeiten, Aufträge und Rechnungen. Für Produktmanager ist das ERP vor allem wichtig, weil dort die wirtschaftlich relevanten Daten liegen. Gleichzeitig ist das ERP meist stark prozessorientiert und auf Stabilität ausgelegt.
Herausforderungen:
- Begrenzte Flexibilität: ERPs sind auf stabile Prozesse ausgelegt, nicht auf sich schnell ändernde Produktlogiken oder Varianten.
- Komplexe Produkte schwer abbildbar: Varianten, Abhängigkeiten oder konfigurierbare Produkte lassen sich oft nur mit Workarounds darstellen.
- Produktdenken vs. Prozessdenken: Produktmanager denken in Angebotslogiken, das ERP in Stücklisten, Aufträgen und Buchungen.
- Änderungen sind teuer: Anpassungen im ERP sind meist IT-getrieben, zeitaufwendig und risikobehaftet.
Das ERP sorgt für Stabilität im Tagesgeschäft, ist aber für variantenreiche Produktkombinationen nicht ausgelegt.
2. PIM (Product Information Management) – Struktur für Produktinformationen
Ein PIM-System dient der zentralen Verwaltung von Produktinformationen: Attribute, Texte, Bilder, Übersetzungen und Klassifikationen. Systeme wie PIMCORE sind darauf spezialisiert, Produktdaten konsistent über verschiedene Kanäle hinweg bereitzustellen.
Für Produktmanager ist ein PIM besonders wertvoll, wenn:
- viele Produkte existieren
- mehrere Vertriebskanäle bedient werden
- Inhalte regelmäßig angepasst oder lokalisiert werden
Ein PIM schafft Ordnung und Transparenz. Es hält Produktdaten sauber und aktuell.
Es sagt aber nicht, was mit diesen Daten möglich ist – zum Beispiel, welche Teile sich miteinander kombinieren lassen.
3. CRM (Customer Relationship Management) – Kundensicht ohne Produkttiefe
Ein CRM-System verwaltet Kunden, Leads, Kontakte und Vertriebsaktivitäten. Es bildet ab, wer kauft, wie gekauft wird und in welchem Kontext sich eine Kundenbeziehung befindet.
Für Produktmanager ist das CRM vor allem als Feedbackquelle relevant: Es liefert Einblicke in Kundensegmente, Kaufverläufe und wiederkehrende Rückfragen aus Vertrieb und Service.
Produkte selbst sind im CRM jedoch nur vereinfacht abgebildet – als Angebotspositionen oder Auswahlfelder. Die zugrunde liegende Produkt-, Varianten- oder Preislogik stammt immer aus anderen Systemen.
4. E-Commerce / Shopsysteme – Verkaufskanal statt Produktlogik
Ein E-Commerce-System ist der digitale Verkaufskanal. Es stellt Produkte dar, ermöglicht Auswahl, Preisanzeige, Warenkorb, Checkout und Zahlungsabwicklung. Für Kunden ist es die sichtbare Oberfläche des Produktangebots.
Für Produktmanager ist E-Commerce wichtig, weil hier Sortimentsentscheidungen unmittelbar wirksam werden: Welche Produkte sind sichtbar? Welche Varianten sind auswählbar? Wie klar und konsistent werden Preise, Optionen und Inhalte dargestellt?
Gleichzeitig sind Shopsysteme nicht dafür ausgelegt, komplexe Produktlogik zu definieren. Varianten, Abhängigkeiten oder Regeln lassen sich meist nur eingeschränkt abbilden oder führen schnell zu unübersichtlichen Produktseiten.
Der Shop beantwortet die Frage:
Was kann der Kunde kaufen – und wie?
Nicht: Was ist technisch, wirtschaftlich oder logisch korrekt konfiguriert?
Je komplexer Produkte werden, desto stärker ist ein Shopsystem auf vorgelagerte Systeme wie PIM, CPQ oder ERP angewiesen.
Das fehlende Bindeglied: Produktlogik
Zwischen ERP, PIM, CRM und Shop entsteht eine Lücke. Diese Lücke betrifft die Produktlogik:
- Welche Optionen sind miteinander kombinierbar?
- Welche Merkmale sind abhängig von anderen?
- Welche Ausprägungen sind technisch oder wirtschaftlich ausgeschlossen?
- Wie verändert eine Konfiguration hinsichtlich, Preis, Machbarkeit oder Lieferzeit?
In vielen Unternehmen ist diese Logik nicht explizit modelliert. Sie existiert in Dokumenten, Excel-Listen oder im Erfahrungswissen einzelner Mitarbeiter:innen. Das macht sie schwer skalierbar und fehleranfällig.
CPQ (Configure, Price, Quote) – strukturierte Produktlogik
Eine CPQ Software setzt genau dort an, wo andere Systeme an ihre Grenzen kommen: bei der eigentlichen Produktlogik. Es macht explizit, welches Produktwissen im Unternehmen existiert, und überführt dieses Wissen direkt in den Angebotsprozess.
Dabei greift CPQ auf Produktdaten aus PIM und ERP zurück und ergänzt sie um Regeln, Abhängigkeiten und Entscheidungslogik. So stellt das System sicher, dass:
- nur gültige Konfigurationen entstehen
- Preise konsistent angewendet werden
- Angebote unabhängig von einzelnen Experten korrekt sind
Für Produktmanager ist CPQ der zentrale Ort, an dem Produktwissen formalisiert wird. Varianten lassen sich dort kontrolliert steuern, statt implizit in Excel-Tabellen, Köpfen einzelner Experten oder ERP-Workarounds zu liegen. Gleichzeitig überwindet CPQ die Grenzen einzelner Systeme, weil es Produktlogik nicht an Prozesse oder Kanäle bindet.
Wichtig dabei: CPQ ersetzt weder ERP noch PIM – und auch nicht CRM oder Shop.
Das ERP bleibt zuständig für operative Fakten und Abwicklung, das PIM für strukturierte Produktinformationen.
Das CRM hält Kunden-, Kontakt- und Vertriebsinformationen und bildet den Beziehungskontext ab. Der Shop ist der Vertriebskanal, über den Produkte gefunden, konfiguriert und bestellt werden. CPQ verbindet diese Systeme und setzt ihre Daten in Beziehung. Es sorgt dafür, dass Produktlogik, Preise und Optionen im jeweiligen Kontext korrekt angewendet werden – unabhängig davon, ob ein Angebot im Vertrieb, im CRM oder direkt im Shop entsteht.
Ein gutes CPQ-System fügt sich nahtlos in bestehende Systemlandschaften ein und vereint relevante Informationen, ohne vollständig von allen angebundenen Systemen abhängig zu sein. Produktlogiken, die beispielsweise nicht im ERP abgebildet sind, können direkt im CPQ ergänzt werden. Ebenso lassen sich Rabattstaffeln oder Preislogiken im CPQ pflegen – auch dann, wenn kein CRM im Einsatz ist.
Ein CPQ-System (Configure, Price, Quote) setzt genau an dieser Stelle an. Es ist darauf ausgelegt, Produktlogik explizit abzubilden, nutzbar zu machen und in den Angebotsprozess überzuführen.
Erst durch CPQ wird klar, welche Optionen für einen Kunden überhaupt relevant sind, welche Kombinationen zulässig sind und welche Preise in der jeweiligen Konfiguration gelten. Ohne CPQ sind Produktdaten zwar korrekt, aber oft interpretationsbedürftig. Mit CPQ werden sie entscheidungsfähig.
Wie sich diese Rollenverteilung konkret auswirkt, zeigt sich erst im praktischen Einsatz. Anhand der folgenden Beispiele wird deutlich, wie Unternehmen CPQ gezielt einsetzen, um typische Systemgrenzen zu überwinden und Produktlogik beherrschbar zu machen.
3 Beispiele aus der Praxis
Praxisbeispiel 1: CPQ vor ERP eingeführt
- Problem: Ein B2B-Hersteller verkauft stark konfigurierbare Maschinen. Angebote entstehen aus Excel-Listen und Erfahrungswissen, Regeln sind nicht eindeutig festgehalten. Preis- und Konfigurationsfehler sind häufig.
- Entscheidung: Statt Produktlogik ins ERP zu drücken, wird früh ein CPQ eingeführt und an CRM angebunden, um Regeln zentral zu definieren.
- Wirkung: Konfigurationsregeln sind eindeutig definiert, Preise konsistent, Angebote lassen sich schneller und reproduzierbar erstellen.
Praxisbeispiel 2: CPQ verhindert teure ERP-Anpassungen
- Problem: Jede neue Produktoption erfordert Anpassungen im ERP.
- Entscheidung: Produktlogik wird im CPQ gepflegt, das ERP bleibt auf Standardprozesse beschränkt, ohne produktspezifische Sonderfälle.
- Wirkung: Produktänderungen werden schneller umsetzbar, während das ERP stabil und wartbar bleibt.
Praxisbeispiel 3: CPQ schafft Angebotssicherheit vor Auftrag
- Problem: Aufträge gelangen ins ERP, obwohl Konfigurationen technisch oder wirtschaftlich nicht zulässig sind, Fehler werden erst spät erkannt.
- Entscheidung: CPQ prüft Konfiguration und Preis, bevor ein Auftrag erzeugt wird, noch vor Übergabe an das ERP.
- Wirkung: Weniger Nacharbeit, weniger Stornos, höhere Datenqualität im ERP.
Fazit: Orientierung statt Systemdebatten
Produktmanager brauchen keine weiteren Systeme – sondern Klarheit.
ERP, PIM und Shop erfüllen jeweils eine wichtige Aufgabe. Doch erst mit einem CPQ-System entsteht eine durchgängige Produktlogik, die diese Systeme sinnvoll miteinander verbindet.
CPQ ist kein Ersatz, sondern ein Bindeglied. Es macht Produktdaten konsistent nutzbar – für Vertrieb, E-Commerce und interne Prozesse. Für Produktmanager bedeutet das vor allem eines: Kontrolle über die eigene Produktlogik.
Gerne unterstützen wir Sie bei der Wahl des richtigen Systems.
Kontakt aufnehmen
Das könnte Sie auch interessieren: