Wie sich ERP, PIM und Pricing API ideal ergänzen

Produktdaten, Preisdaten und Preisentscheidungen sind nicht dasselbe

Wenn in Unternehmen über Preise gesprochen wird, werden häufig sehr unterschiedliche Themen miteinander vermischt. Einerseits geht es um die Verwaltung von Preisdaten, andererseits um Produktinformationen und schließlich um die eigentliche Logik, die aus diesen Daten einen gültigen Verkaufspreis ermittelt.

Genau diese Unterscheidung ist für die Architektur moderner Systemlandschaften entscheidend. Produktdaten, Preisdaten und Preisentscheidungen sind nicht dasselbe und sollten deshalb auch nicht als dieselbe Aufgabe betrachtet werden.

Viele Diskussionen über „Preise im PIM“ oder „Preislogik im ERP“ entstehen letztlich dadurch, dass drei unterschiedliche Fragestellungen miteinander vermengt werden:

• Woher stammen die kaufmännischen Preisgrundlagen?
• Wo werden Produktinformationen verwaltet und veröffentlicht?
• Wo wird die Geschäftslogik ausgeführt, die aus allen verfügbaren Informationen eine Preisentscheidung ableitet?

Erst wenn diese Fragen getrennt betrachtet werden, wird deutlich, welche Rolle ERP, PIM und Pricing API tatsächlich spielen.

Das ERP als führende Quelle für kaufmännische Preisdaten

In vielen Unternehmen ist das ERP-System eine zentrale bzw. führende Quelle für kaufmännische Preisdaten. Dort werden kundenbezogene Konditionen, Verträge, Aufträge, Rechnungen und weitere kaufmännische Geschäftsdaten verwaltet.

Diese Rolle hat sich in der Praxis bewährt. Das ERP ist darauf ausgelegt, kaufmännische Prozesse abzubilden und die dafür notwendigen Daten konsistent bereitzustellen. Entsprechend besteht das Ziel moderner Pricing-Architekturen nicht darin, das ERP zu ersetzen oder dessen Verantwortung zu übernehmen.

Vielmehr liefert das ERP die Informationen, auf deren Basis spätere Preisentscheidungen getroffen werden können.

Typische Beispiele hierfür sind:

• Einkaufspreise
• Preislisten
• Kundenkonditionen
• Vertragsvereinbarungen
• Währungsinformationen
• Lieferantenpreise
• Verkaufsdaten

Diese Informationen können die Grundlage für Preisentscheidungen bilden, sind jedoch noch nicht die Preisentscheidung selbst.

Die Rolle des PIM

Während das ERP kaufmännische Informationen verwaltet, konzentriert sich ein PIM-System auf Produktinformationen. Attribute, Kategorien, Klassifikationen, Medien, Produkttexte, Datenqualität und Veröffentlichungsprozesse gehören typischerweise in den Verantwortungsbereich eines PIM.

Auf den ersten Blick scheint Preislogik damit wenig zu tun zu haben. In der Praxis entsteht jedoch häufig eine enge Verbindung zwischen Preisen und Produktprozessen.

Ein Produkt kann beispielsweise nur dann veröffentlicht werden, wenn ein gültiger Verkaufspreis vorliegt, definierte Mindestmargen eingehalten werden, alle preisrelevanten Informationen vollständig vorhanden sind oder notwendige Freigaben erteilt wurden. Spätestens an diesem Punkt beeinflussen Preisentscheidungen unmittelbar die Produktqualität und die Veröffentlichbarkeit eines Produkts. In einem entscheidungsgetriebenen PIM wird der Preis dadurch nicht nur zu einer kaufmännischen Information, sondern gleichzeitig zu einem Bestandteil der Product Readiness.

In einem entscheidungsgetriebenen PIM werden solche Regeln nicht mehr als isolierte Prüfungen verstanden. Sie werden Bestandteil eines übergreifenden Entscheidungsmodells, das Produktdaten, Preisinformationen und Geschäftsregeln miteinander verbindet.

Damit wird deutlich, dass das PIM nicht die Aufgabe hat, Kaufpreise oder Preislisten zu verwalten. Es benötigt jedoch häufig die Ergebnisse von Preisentscheidungen, um Produktprozesse zuverlässig steuern zu können.

Warum Preislogik häufig in Excel landet

Obwohl die führenden kaufmännischen Preisdaten häufig im ERP liegen, entwickelt sich die eigentliche Preislogik in vielen Unternehmen an anderer Stelle weiter.

Der Grund dafür ist einfach: Fachbereiche müssen auf Marktveränderungen, neue Produkte, Rabattaktionen, veränderte Margenziele oder neue Kundengruppen reagieren. Änderungen lassen sich in Excel häufig schneller umsetzen als innerhalb klassischer ERP-Anpassungsprojekte.

Im Laufe der Zeit entstehen dadurch umfangreiche Excel-Modelle für:

• Staffelpreise
• Kundengruppenpreise
• Rabattlogik
• Margenkalkulationen
• Preisfaktoren
• Währungsumrechnungen
• Länderlogiken
• Sondervereinbarungen
• Vertriebsaktionen

Viele dieser Modelle enthalten das eigentliche Know-how des Unternehmens. Sie beschreiben nicht nur Preise, sondern die Regeln, nach denen Preise entstehen.

Excel wird dadurch zur Modellierungsumgebung für Preisentscheidungen.

Das ist grundsätzlich kein Problem. Im Gegenteil: Fachbereiche können ihre Logik dort oft wesentlich verständlicher und flexibler beschreiben als in Anwendungscode oder proprietären Regelsprachen.

Der eigentliche Engpass entsteht nicht bei der Modellierung

Mit zunehmender Komplexität wird jedoch nicht die Modellierung der Preislogik zum Problem, sondern deren Ausführung.

In vielen Unternehmen entstehen Prozesse wie diese:

Typischer manueller Preisprozess

flowchart TD

ERP["ERP-System<br/>Preislisten, Kunden, Konditionen"]

EXCEL["Excel-Preismodell<br/>Rabatte, Margen, Staffelpreise"]

ERP2["ERP-System<br/>Aktualisierte Verkaufspreise"]

ERP --> EXCEL
EXCEL --> ERP2

oder

Preisprozess mit mehreren Zielsystemen

flowchart TD

ERP["ERP-System<br/>Einkaufspreise, Konditionen"]

EXCEL["Excel-Preismodell<br/>Preislogik und Berechnungen"]

PIM["PIM-System<br/>Produktdaten und Publishing"]

SHOP["Shop / E-Commerce"]

ERP --> EXCEL
EXCEL --> PIM
PIM --> SHOP

Neue Einkaufspreise werden aus dem ERP exportiert, in Excel mit Margen-, Rabatt- und Staffelregeln verarbeitet und anschließend als Ergebnis wieder in ERP-, PIM- oder Shop-Systeme importiert.

Solche Abläufe funktionieren technisch oft erstaunlich lange. Der eigentliche Engpass liegt jedoch selten in der Anzahl der Zeilen oder Formeln.

Viel entscheidender ist die Tatsache, dass Preisberechnungen zu einem manuellen Geschäftsprozess werden.

Neue Preise entstehen nur dann, wenn Mitarbeiter die Berechnungen tatsächlich durchführen. Preisaktualisierungen müssen geplant werden. Änderungen warten auf verfügbare Ressourcen. Fachwissen konzentriert sich häufig auf wenige Personen.

Dadurch entstehen typische Risiken:

• Preisänderungen benötigen manuelle Arbeit.
• Aktualisierungen erfolgen nur zu festgelegten Zeitpunkten.
• Wissen über die Preislogik verbleibt bei einzelnen Mitarbeitern.
• Urlaubszeiten verzögern Preisanpassungen.
• Krankheitsausfälle blockieren Preisprozesse.
• Tagesaktuelle Preise werden praktisch unmöglich.

Die Herausforderung besteht dann nicht mehr darin, Preislogik zu beschreiben. Die eigentliche Herausforderung besteht darin, Preisentscheidungen jederzeit verfügbar, konsistent und automatisiert für alle beteiligten Systeme bereitzustellen.

Excel bleibt dabei ein hervorragendes Werkzeug zur Modellierung von Preislogik. Als Runtime für Preisentscheidungen über ERP, PIM, Shop, Kundenportal und CPQ-Systeme hinweg stößt dieser Ansatz jedoch häufig an organisatorische und technische Grenzen.

Preisdaten sind nicht Preisentscheidungen

Genau an dieser Stelle wird der Unterschied zwischen Daten und Entscheidungen sichtbar.

Preisdaten sind beispielsweise:

• Einkaufspreise
• Preislisten
• Kundenkonditionen
• Rabattgruppen
• Lieferantenpreise

Preisentscheidungen beantworten hingegen Fragen wie:

• Welcher Verkaufspreis gilt für diesen Kunden?
• Welche Staffel muss verwendet werden?
• Welche Marge darf angewendet werden?
• Ist ein Rabatt zulässig?
• Muss eine Preisfreigabe erfolgen?
• Darf ein Produkt veröffentlicht werden?

Auch wenn konkrete Preise oder Konditionen im ERP oder PIM gespeichert sein können, entsteht die eigentliche Preisentscheidung häufig erst durch die Anwendung von Geschäftslogik auf die verfügbaren Daten.

Die Rolle einer Pricing API

Eine Pricing API stellt diese Geschäftslogik als zentralen Service bereit.

Bei Contene wird dieser Ansatz durch die Contene Logic Engine (CLE) umgesetzt. CLE stellt Entscheidungslogik als eigenständige Pricing API und Decision Engine bereit und kann Preisentscheidungen für ERP-Systeme, PIM-Lösungen, Shops, Portale oder CPQ-Anwendungen zentral ausführen.

Anstatt Preisentscheidungen in mehreren Systemen separat zu berechnen, werden die relevanten Daten an einen zentralen Entscheidungsservice übergeben, der das Ergebnis für alle beteiligten Anwendungen bereitstellt.

Die Architektur verändert sich dadurch grundlegend:

Zielbild: Zentrale Preislogik als Service

flowchart TD

ERP["ERP-System<br/>Preislisten, Kunden,<br/>Einkaufspreise, Verträge"]

PIM["PIM-System<br/>Produktdaten,<br/>Datenqualität, Publishing"]

API["Pricing API<br/>CLE"]

RESULT["Preisentscheidung"]

PRICE["Verkaufspreis"]
MARGIN["Marge"]
DISCOUNT["Rabatt"]
TIER["Staffelpreis"]
APPROVAL["Freigabe"]

CHANNELS["Shop, Portal,<br/>CPQ, ERP, PIM"]

ERP --> API
PIM --> API

API --> RESULT

RESULT --> PRICE
RESULT --> MARGIN
RESULT --> DISCOUNT
RESULT --> TIER
RESULT --> APPROVAL

PRICE --> CHANNELS
MARGIN --> CHANNELS
DISCOUNT --> CHANNELS
TIER --> CHANNELS
APPROVAL --> CHANNELS

Eine solche Architektur bedeutet nicht, dass alle Anwendungen denselben Preis erhalten müssen.

Vielmehr greifen alle Anwendungen auf dieselbe zentrale Preislogik zurück und liefern dabei ihren jeweiligen Kunden-, Produkt-, Kanal- oder Kontextbezug mit.

Dadurch bleibt die Preisentscheidung konsistent, nachvollziehbar und zentral steuerbar.

Unternehmen, die eine solche Architektur außerhalb eines PIM umsetzen möchten, können Preisentscheidungen beispielsweise über CLE als eigenständige Pricing API und Decision Engine bereitstellen.

Wie Contene und CLE diesen Ansatz unterstützen

Im entscheidungsgetriebenen PIM-Ansatz von Contene können Preisentscheidungen direkt Bestandteil von Produkt- und Veröffentlichungslogiken werden. Preisregeln, Plausibilitätsprüfungen, Freigaben und Veröffentlichungsentscheidungen werden dabei gemeinsam mit den Produktregeln modelliert und ausgeführt.

Dadurch können Preisinformationen nicht nur dargestellt, sondern aktiv für die Steuerung von Produktprozessen genutzt werden.

Contene integriert diesen Ansatz direkt in das PIM. Für bestehende ERP-, Shop-, Portal-, CPQ- oder Individualsoftware-Landschaften stellt CLE dieselbe Entscheidungslogik als eigenständige Pricing API bereit.

Fazit

In vielen Unternehmen ist das ERP die führende Quelle für kaufmännische Preisdaten. Das PIM verantwortet Produktinformationen, Datenqualität und Veröffentlichungsprozesse. Komplexe Preislogik entsteht häufig in Excel, weil Fachbereiche dort flexibel auf neue Anforderungen reagieren können.

Mit wachsender Komplexität wird jedoch nicht die Modellierung der Preislogik zum Engpass, sondern ihre zuverlässige, automatisierte und systemübergreifende Ausführung.

Eine Pricing API stellt diese Entscheidungslogik zuverlässig, automatisiert und systemübergreifend bereit.

ERP, PIM und Pricing API konkurrieren daher nicht miteinander. Sie übernehmen unterschiedliche, sich ergänzende Aufgaben innerhalb derselben Architektur.

Das ERP liefert die kaufmännischen Daten. Das PIM verwaltet die Produktinformationen. Eine Pricing API kann diese Geschäftslogik als zentralen Service bereitstellen. Bei Contene übernimmt die Contene Logic Engine (CLE) diese Rolle als Decision Engine und Pricing API.

Weiterführend: Mehr zur Pricing API und Geschäftslogik mit der Contene Logic Engine (CLE).