PIM-Systeme und Konfiguratoren (CPQ)

PIM-Systeme zeichnen sich seit jeher dadurch aus, dass sie die vermarktbare Produktvielfalt eines Unternehmens darstellen und diese an alle nur erdenklichen anderen Systeme oder Werkzeuge je nach Verwendungszweck ausleiten.

Der Übergang vom vorherigen reinen Database-Publishing zu PIM-Systemen, hat die ursprüngliche Printausleitung um weitere Optionen wie Webshop, Website, CRM-Systeme und andere Ausleitungen erweitert. Das war im Sinne der Wertschöpfungskette aus der Marketingsicht der erste große Schritt, der den Weg von der reinen Printausleitung in die digitale Welt ebnete, also vom analogen Stück Papier hin zu digitalen Marketingoptionen.

Heutzutage kommt auf die aktuellen PIM-Systeme der nächste Schritt in eine neue Richtung zu. Die immer weiter fortschreitende Individualisierung der Gesellschaft, hat auch vor der Marketingwelt nicht haltgemacht und fordert diese nun heraus, auch bei den vermarktbaren Produktoptionen nicht das fertige Produkt als Kaufentscheidung zu präsentieren, auf welche analogen oder digitalen Wegen auch immer, sondern hier dem Kunden ebenso die Möglichkeit zu bieten, sich sein Endprodukt nach seinen persönlichen Wünschen oder auch technischen oder gesetzlichen Notwendigkeiten zusammenzustellen.

Für ein PIM-System bedeutet dies nun, dass im Produktbaum des Systems, oder den Produktbäumen, als Endpunkt nicht mehr nur ein Artikel im Sinne der Vermarktung stehen kann, sondern eben auch die einzelnen Bestandteile eines von Kunden konfigurierbaren Produktes. Diese Bestandteile werden dann als Optionen im Konfigurator dem Kunden als mögliche Bausteine für sein Zielprodukt zur Verfügung gestellt, abhängig von den Bedingungen seiner Auswahl.

Den Meisten sind diese Optionen sicher bei den Konfiguratoren der Automobilmarken bekannt, wo man sich für ein Wunschautomobil seinen Motor, seine Ausstattung und Optionen in einer Konfiguration , abhängig von den erlaubten und nicht erlaubten Kombinationen, zusammenstellen kann.

Hier kann ein Konfigurator eine notwendige Logik integriert haben, die den Auswahlprozess für den Endanwender steuern kann. Dabei muss dann ein PIM-System nur als Datenlieferant dienen.

Bietet nun ein Konfigurator keine eigene Logik an, um die einzelnen Bestandteile mit Ihren Abhängigkeiten für den User verknüpfbar zu machen, kann die Aufgabe deutlich komplexer werden.

Zu verhindern ist dabei der Weg, die Abhängigkeiten der Bestandteile dann statt im Konfigurator im PIM-System abzubilden. Die meisten PIM-Systeme sind hierzu noch nicht in der Lage und sollten deswegen auch diese Aufgabe nicht übernehmen.

Die Lösung kann hier eine Datenbank sein, die zwischen dem PIM-System und dem Konfigurator steht. Das PIM-System liefert also dann seine Daten nicht an den Konfigurator, sondern an diese dazwischen geschaltete Datenbank. Die Logik, d.h. im Wesentlichen die Abhängigkeiten der einzelnen Bestandteile, können dann in dieser Datenbank aufbereitet werden und von dort an den Konfigurator geliefert werden.

Wenn man nun für diese einzelnen Bestandteile darüber hinaus nicht nur eine Quelle hat, wie z.B. ein Warenwirtschafts- bzw. ERP-System, sondern die Daten aus verschiedenen Quellen bekommt und diese auch keinen gemeinsamen, eineindeutigen Schlüssel wie eine Material- oder Teilenummer haben, wird die Thematik noch komplexer.

Eine derart komplexe Systemlandschaft kann sich z.B. wie folgt darstellen:

1. PIM-System
2. Quellsysteme:

• ERP-System mit fertig konfigurierten Endprodukten „von der Stange“ (mit Materialnummern),
• Datenbank mit Kombinationsmöglichkeiten der Bestandteile der konfigurierbaren Produkte (ohne Materialnummern, Anzahl der Kombinationen liegt im zweistelligen Millionenbereich, Eindeutigkeit der einzelnen Kombinationen nur über eine bestimmte Anzahl von Attributen möglich) – Keine PIM-Objekte
• Datenbank mit den Einzelkomponenten der Endprodukte (ohne Materialnummern)
• liefert Eigenschaften der Bestandteile und Endprodukte
• liefert Optionen für die konfigurierten bzw. Endprodukte

3. Zielsysteme:

• Zwischendatenbank mit dahinter geschaltetem Konfigurator
• 12 weitere Ausleitungen wie Webshop, Website, CMS, Print Katalog, Print Datenblätter, Übersetzungssystem usw.

Dabei wurden in einem Projekt alle Daten im PIM-System zusammengeführt, wobei die „millionenschwere“ Datenbank mit den Kombinationsmöglichkeiten im PIM-System nur auf Datenbankebene durchgeschleust wurde. Sie waren zwar rudimentär bearbeitbar, die Einträge zählten aber nicht als PIM-Objekte. Sie waren allerdings exportierbar. Der Export konnte wiederum so konfiguriert werden, dass die Daten aus dem PIM-System und der durchgeschleusten Kombinationsdatenbank für die Zwischendatenbank entsprechend zusammengestellt werden konnten, jedoch ohne die notwendige Logik, was Aufgabe der Zwischendatenbank war.

Welche Daten aus dem PIM-System (Einzelkomponenten, Optionen, Eigenschaften) an die Konfigurator-Datenbank ausgeliefert werden sollten, wurde mittels Tags gesteuert.

Fehlende Materialnummern wurden beim Export per Attributs-Kombinationen u.a. mit der PIM-internen Objektnummer eindeutig gemacht. Damit konnte dann auch dem Konfigurator aus dieser Nummernvergabe die Logik des Typs des Bestandteils mitgegeben werden.

Fazit:
Für zukünftige Aufgabenstellungen aus der Ausleitung an Konfiguratoren müssen einige PIM-Systeme besser als heute angepasst werden. Dies wird auf Seiten der Hersteller von PIM-Systemen der nächste Schritt in der Thematik Ausleitung werden. Es bleibt also spannend!

Über Kai-Uwe Heidenreich:

Seit 1993 ist Herr Heidenreich in der PIM-Branche tätig, als Projektmanager, Business-Consultant und Teamleiter. Dabei hat er bei allen Beteiligten agiert, dem Dienstleister, dem Kunden und dem Software-Hersteller. Die Projekte und Tätigkeiten waren fast immer im Retail und der Industrie beheimatet. Schwerpunkte bildeten die Themen PIM, MAM, MRM, W2P und Database Publishing.