PIM-Replatforming – Chance aber auch Herausforderung

Die Erfolgsbilanz von IT-Projekten ist ernüchternd. Die Erfolgsquote liegt, abhängig von der jeweiligen Untersuchung, nur zwischen 20 und 45%. Dabei spielt es keine Rolle, ob es sich um ein komplett neues IT-Projekt, d.h. die Einführung einer neuen Technologie bzw. eines neuen Tools oder die Ablösung vorhandener Technologien durch eine neue Lösung handelt.

Der Fokus liegt dabei darin, weg von klassischen, häufig monolithisch angelegten IT-Infrastrukturen hin zu flexiblen Architekturen zu kommen, die die kurzen Halbwertszeiten von Prozessen und Features berücksichtigen. Hier spricht man dann häufig von sogenannten Replatforming. Aus eigener Erfahrung wissen wir, dass gerade letzteres aus verschiedenen Gründen häufig eine noch größere Herausforderung darstellt als ein komplett neues Projekt “auf der grünen Wiese”. Im Prinzip kann man hier sehr gute Parallelen zum Hausbau ziehen, wonach sich ein Umbau bzw. die Renovierung eines vorhandenen Gebäudes häufig als anspruchsvoller herausstellt als ein kompletter Neubau. In diesem Artikel möchten wir auf einige Parameter beim Replatforming eingehen und mögliche Lösungsansätze vorstellen, um am Ende ein erfolgreiches Projekt abzuliefern. Der Fokus liegt dabei auf dem Bereich der Product Information Management Systeme (PIM Systeme), wobei sich die zugrunde liegenden Ansätze und Ideen auch auf beliebige andere Technologien übertragen lassen.

Vier Parameter bei einem Replatforming-Projekt im Kontext Product Information Management

1. Projekt- und Prozessverständnis

Wenn wir als Dienstleister in ein IT-Projekt einsteigen, versuchen wir uns zu Beginn ein vollkommen eigenes Bild des Status Quo zu machen. Ein “Klassiker” in diesem Zusammenhang ist dabei folgender Satz, den sicherlich viele von Ihnen schon mal gehört haben:

“Funktion X haben wir bislang gehabt und brauchen das daher auch 1:1 im neuen System wieder.”

Wir versuchen natürlich zum einen diesem Wunsch nachzukommen, gleichzeitig aber durch ein gut abgestimmtes Methoden-Set an den richtigen und wichtigen Stellen kritisch zu hinterfragen, ob bestehende Prozesse wirklich in der - häufig historisch gewachsenen Art - sinnvoll sind. Häufig ergeben sich bereits durch eine strukturierte Analyse bestehender Prozesse Verbesserungspotenziale. Ergänzt durch unsere Erfahrung führen wir dann die Optimierung durch und machen die Mitarbeiter und das ganze Unternehmen bereit für digitale Geschäftsmodelle.

2. Vorhandene Datenstruktur & Qualität

Der bekannte Satz “Shit in, Shit out” verdeutlicht auf sehr plakative und leicht verständliche Weise, dass Software in den allermeisten Fällen kein Allheilmittel darstellt. Auch wenn durch die zunehmende Verbreitung von künstlicher Intelligenz und den damit verbundenen Möglichkeiten immer mehr aus vorhandenen und teilweise auch schlecht gepflegten Daten geholt werden kann, gilt das genannte Prinzip insbesondere für PIM-Systeme. Anders ausgedrückt kann man sich bei einem Replatforming-Projekt durch intensive Vorbereitung und entsprechend konzeptionelle Vorarbeit enorm viel Zeit, Geld und auch Ärger ersparen. Durch statistische Analysen identifizieren wir die Bereiche mit dem höchsten Handlungspotential und erarbeiten dort gemeinsam mit allen relevanten Stakeholdern im Kontext des Product Information Managements Konzepte zur Verbesserung. Dabei ist es entscheidend nicht nur die Produktdaten sondern auch die Strategien hinter den diversen Ein- und Ausleitungskanälen zu berücksichtigen.

3. Migration

Die zentrale Fragestellung hierzu lautet: Wie bekommt man die vorhandenen Daten & Datenstrukturen in das gewünschte/neue Zielformat und damit in die neue Software? Mindestens genauso wichtig ist allerdings die Frage welche Daten ich tatsächlich benötige und in welcher Form diese Vorliegen bzw. ggf. entsprechend transformiert werden müssen. Ein Beispiel hierfür wären falsche Attributstypen wie z.B. die Verwendung von Boolean Werten (ja/nein bzw. 0/1) anstatt von Multi-Select-Werten. Bei der Migration würden hier unnötige Datenmenge und auch eine falschen Datenstruktur an das Zielsystem übertragen werden. Wir verfahren hier normalerweise so, dass wir die Migration auf dem Altsystem beginnen und hierfür folgende Attributstypen anlegen und entsprechend vorbereiten/anreichern::

• Standard-Attribute: Diese werden ohne Anpassung ins Zielsystem übertragen
• Migrations-Attribute: Diese werden im Altsystem erstellt und befüllt um dann anstelle eines Alt-Attributes ins Zielsystem übertragen zu werden.
• Transformations-Attribute: Diese Attribute dienen als Hilfsmittel und Anweisung an unser Migrationstool nach dem Muster “Mach’ aus X im Altsystem Y im neuen Zielsystem”

4. Software

Nachdem ein PIM-System ja bereits per Definition als Hub für Produktdaten gesehen wird und demnach mit unterschiedlichen Drittsystemen verbunden wird - hierzu zählen insbesondere ERP-Systeme und Shop-Systeme - müssen die involvierten Systeme hinsichtlich ihres jeweiligen Datenhandlings genau geprüft werden. D.h. wie werden dort die unterschiedlichen Daten und Datenstrukturen abgebildet und wie können diese sinnvoll miteinander verknüpft werden ohne Datenverluste zu erleiden. Ein Beispiel hierzu wäre die Unterscheidung von sog. Simple- bzw. Configurable Products in der Shopsoftware Magento. Simple Products sind dabei einzelne und für sich alleine stehende Produkte während das klassische Beispiel für ein Configurable Product ein T-Shirt in unterschiedlichen Größen und Farben darstellt. Akeneo bietet zur Abbildung von Produkten dabei nicht nur zwei Achsen wie in Magento, sondern drei an, was Softwareseitig beim Import in Magento gelöst werden muss. Ergänzend lässt sich natürlich auch das PIM System selbst entsprechend anpassen um Bedienbarkeit und Funktionsumfang für Anwender zu optimieren.

Ein Praxisbeispiel

Nachfolgendes Praxisbeispiel soll einige Ideen und erste Anregungen für eine zielgerichtete Vorgehensweise bei einem Replatforming liefern. Die Ausgangslage sieht hier wie folgt aus:

• Erfolgreiches Handelsunternehmen mit umfangreichem Produktsortiment
• Produktdaten werden in Akeneo gepflegt
• Print-Katalog mit mehreren hundert Seiten ist zentrales Marketing-Instrument und wird in Indesign mit Produktdaten aus Akeneo erstellt
• Es besteht ein Magento 1 Shop mit Anbindung an Akeneo

Das Unternehmen möchte sich digital neu und möglichst zukunftsorientiert aufstellen und hat uns hierzu in einem ersten Schritt mit einem Beratungsprojekt beauftragt, über das folgende Fragestellungen geklärt werden sollen:

• Wie gut ist die vorhandene Datenstruktur? Ist das jetzige Akeneo System durch TechDivision maintainbar?
• Ist ein Update bzw. eine Migration auf die aktuelle Akeneo Version mit dem bestehenden System/den bestehenden Datenstrukturen möglich?

Folgende Übersicht zeigt einige Kennzahlen des bestehenden Systems:

Analyse der vorhandenen Daten und Datenstrukturen

In der täglichen Praxis hat sich ein zweistufiges Vorgehensmodell bei uns bewährt. Hierzu erfolgt in einem ersten Schritt eine Sichtprüfung der wichtigsten Kennzahlen, von denen ein Großteil davon in obiger Tabelle exemplarisch aufgeführt wird. Im Rahmen eines Replatformings erfolgt dann noch einmal eine detailliertere Analyse wie oben beschrieben. Beim Blick auf die Kennzahlen des bestehenden Systems fällt insbesondere folgendes auf:

• Locales / Gebietschemata: Es wurden 9 verschiedene locales angelegt, scheinbar werden aber nur 2 (DE & EN) tatsächlich genutzt.
• Kategorien: Der Kategoriebaum spiegelt die Struktur der Website aber nur größtenteils die des Katalogs wieder. Außerdem werden Kategorien zur Realisierung von Workflows genutzt (Neuanlage) und die "Sale" Kategorie manuell gepflegt.
• Attribute: Insgesamt sind mehr als 600 Attribute im System angelegt. Es ist erkennbar, dass viele dieser Attribute exakt für eine Produktart und nicht für ganze Produktkategorien oder gar global definiert wurden. Durch die Funktion in Akeneo v1 manuell Attribute zu Produkten hinzuzufügen, kann in Folge der über 30 User und der mangelnden Familien davon ausgegangen werden, dass dies nicht einheitlich erfolgt ist und die Daten hoch inkonsistent sind.
• Familien: Familien wurden nicht nennenswert verwendet. Lediglich zwei Base Families wurden angelegt. Für jedes Produkt wurden manuell weitere Attribute nach Bedarf hinzugefügt.
• Models (Produkte): Es gibt Models, die bis zu 5 Axen haben (!). Insgesamt haben 303 von 2781 (11%) mehr als 2 Axen. Die Codes sind teilweise einfach durchnummeriert, teilweise aber auch sprechend vergeben. (Inkonsistenz!)

Hier wird bereits ersichtlich, dass im Bereich der Attribute mit über 600 vorhandenen Attributen sowie bei den Produktfamilien ein genauerer Blick notwendig ist. Wie weiter oben ersichtlich wird, sind insbesondere durch die Verwendung der Attribute sowie fehlende Produktfamilien entsprechende Inkonsistenzen und damit Probleme vorprogrammiert, die nichts mit der geplanten Software bzw. Softwareversion zu tun haben. Bei derartigen Mengengerüsten ist eine manuelle Prüfung nicht mehr effizient möglich. Hier empfiehlt es sich automatisierte Prüfroutinen zu verwenden, die in einem solche Fall u.a. folgende abfragen durchführen:

• Welche Attribute werden am häufigsten bzw. bei einem Großteil der Produkte verwendet?
• Welche Attribute finden kaum oder gar keine Anwendung?

Das Ergebnis einer solchen Prüfung dient dann als Basis für die Attributsbereinigung. In unserem Beispiel kann damit die bestehende Anzahl von über 600 Attributen auf rund 200 Attribute reduzierte werden ohne dabei signifikante Informationsverluste hinnehmen zu müssen. Durch diese Reduzierung wird das System zum einen verschlankt was sich positiv auf die Performance auswirken kann. Zum anderen wird die zukünftige Pflege dadurch erleichtert, da das System übersichtlicher gehalten wird. In unserem Beispiel fällt weiter auf, dass in der Vergangenheit faktisch mit nur einer Produktfamilien gearbeitet wurde. Unter einer Produktfamilie versteht man im Kontext von Akeneo einen Satz von Attributen, der von Produkten, die zur selben Familie gehören, geteilt wird. Mit anderen Worten, eine Familie kann als etwas Ähnliches wie eine Produktvorlage oder eine Produktpflegemaske betrachtet werden. Wenn ein Produkt zu einer Familie hinzugefügt wird, nutzt es alle auf der Familienebene definierten Attribute - und genau nur diese. Ein Produkt kann nur zu einer Familie gehören welche auch auf Attributsebene die Vollständigkeit eines Produktes regelt. Nachfolgend einige Beispiele für Produktfamilien:

• eine Camcorder-Familie,
• eine Becher-Familie,
• eine Familie von Sofas,
• eine Familie mit Kühlschränken,
• eine Hammer-Familie…

Alle diese Arten von Produkten haben ihre eigenen Merkmale, ein Camcorder hat zum Beispiel die folgenden Attribute in seiner Produktfamilie:

• eine Produktkennung (z.B. ein Sku),
• einen GTIN/EAN/UPC/ASIN-Code,
• eine Marke,
• einen Sensortyp,

Die Camcorder der entsprechenden Produktfamilie nutzen all diese Attribute und werden automatisch bei der Neuanlage eines Produktes in der Familie verwendet. Ein Hammer hat auch eine Produktkennung (z.B. einen SKU), einen GTIN/EAN-Code, einen Namen, eine Beschreibung, aber er hat auch seine eigenen Attribute, wie z.B. eine Grifflänge, Griffmaterial, Gewicht, etc. Eine Familie kann also alle im PIM verfügbaren Attribute verwenden, und ein und dasselbe Attribut kann in mehreren Familien verwendet werden Die meisten Ihrer Produkte werden eine Beschreibung, einen Namen, einen Identifikator haben…

Durch eine intelligente Anlage von Attributen und entsprechenden Produktfamilien lässt sich zum einen die Übersichtlichkeit des PIM Systems signifikant verbessern, die Zeit für die Produktpflege massiv verkürzen und am Ende Zeit und Kosten einsparen ohne dabei Einbußen bei der Qualität der Produktdaten hinnehmen zu müssen. In unserem Beispiel wird schnell klar, dass bei einem Kunden mit mehr als 20.000 Artikeln und einem sehr breiten Sortiment eine Größenordnung von einer einzigen Familie zu unnötiger Komplexität in der Verwaltung und Anlage führen kann. Ein tiefergehenderer Blick auf den Status Quo bestätigte dies dann auch. Produktfamilien wurden bei der Konzeption des bestehenden Systems nicht berücksichtigt und auch im Nachgang nicht ergänzt, wodurch zum einen unnötiger Pflegeaufwand entsteht und zum anderen die Vorteile von Akeneo nur zum Teil genutzt werden.

Analyse der Prozesse

Zur Analyse vorhandener Prozesse, z.B. bei der Einstellung oder Freigabe von Produkten, bei der Ausleitung von Werbemitteln uvm., können, abhängig vom jeweiligen Kunden und Projektumfang, eigene Bücher geschrieben werden. Wir haben hierbei häufiger die Erfahrung gemacht, dass sich Prozesse oder Workarounds über einen längeren Zeitraum entwickeln und etablieren können und aufgrund einer gewissen “Betriebsblindheit” auch nicht mehr in Frage gestellt werden. Ein Beispiel aus unserer Praxis gefällig? Einer unserer Kunden erhält von unterschiedlichsten Lieferanten Produktdaten per Excel-Files. Jeder Lieferant kocht hier jedoch sein eigenes Süppchen und liefert die Daten in seinem Format. Auf Kundenseite bedeutet dies entsprechend hohen Aufwand die unterschiedlichen Daten weiter zu verarbeiten. Unser Vorschlag hier war so einfach wie auch logisch nachvollziehbar: Zukünftig stellt der Kunden seinen Lieferanten ein einheitliches Schema zur Verfügung, das gewährleistet, dass alle notwendigen Daten in der richtigen Form geliefert werden. Klingt erstmal sehr trivial, jedoch stellt man in der Praxis einfach zu oft fest, dass nach dem Modus “Das haben wir immer schon so gemacht!” verfahren wird und damit die Chance auf eine Optimierung und Verbesserung für alle involvierten Stakeholder bereits zu Beginn vertan wird.

Analyse der Systemlandschaft

PIM Systeme nehmen in der heutigen Zeit auch aufgrund der zunehmende Anzahl an Kanälen (u.a. Print und Online) immer häufiger eine sehr zentrale Rolle ein, da sie meist mit unterschiedlichen Systemen wie z.B. einem ERP-System, einem Online-Shop sowie beispielsweise auch DTP-Software wie Indesign verbunden sind. Insofern ist es häufig nicht damit getan, sich nur alleine mit dem PIM zu beschäftigen. Ein frühzeitiger Blick über den Tellerrand und die involvierten Systeme ist dabei zwingend erforderlich, um sich unnötige Mehraufwände sowie im schlimmsten Fall ein böses Erwachen auf der Zielgeraden zu ersparen. Nachfolgende Skizze einer Systemlandschaft soll dies verdeutlichen:

Bei Bloodstream und Pacemaker handelt es sich im Prinzip um Middleware-Lösungen mit denen Daten aus unterschiedlichen Systemen konvertiert (Bloodstream) sowie Importprozesse modelliert werden können (Pacemaker). In vorliegendem Beispiel ist aktuell zusätzlich ein dedizierten Digital-Asset -Management-System im Einsatz, über das insbesondere Produktbilder, Anleitungen und Technische Datenblätter verwaltet werden. Bei einer Migration müssen solche Szenarien von Beginn an beleuchtet werden. Unter Umständen ergeben sich auch hier Optimierungsansätze, da die aktuelle Version von Akeneo beispielsweise ein neues DAM-Modul bereitstellt, wodurch möglicherweise eine externe Lösung hinfällig werden kann.

Fazit: PIM-Replatforming

Letztlich lässt sich zusammenfassen, dass PIM-Replatforming aus unserer Sicht hauptsächlich eine intensive Beschäftigung mit Prozessen, Datenstrukturen und Datenverarbeitung bedeutet - Viele Faktoren, die erstmal System-Agnostisch sind. Erst wenn diese Faktoren ausführlich betrachtet wurden, kommt die Frage nach der Software. Wir, TechDivision, haben uns hier für Akeneo entschieden, weil die Denkweise, den Endanwender in den Mittelpunkt aller Entwicklungsleistung zu stellen, sich sehr gut mit unserer Denk- und Arbeitsweise deckt. Theoretisch lässt sich aber nach den ersten drei Schritten immer noch jedes beliebige PIM System einführen. Denn: Replatforming sollte nicht über Software oder einzelne Lösungen, sondern über das große Ganze definiert werden.

---

Über die Autoren

Dr.-Ing. Sebastian Zürcher war Forscher im Bereich der chemischen Industrie und arbeitet seit über 15 Jahren mit mathematischen Modellen und Datenanalyse. Im Verlauf seiner Karriere war er Projekt Management Officer, ebenfalls in der Forschung, und hat in den letzten Jahren als Lean Six Sigma Black Belt in einem globalen Unternehmen für Spezialchemikalien Geschäftsprozesse optimiert. In der TechDivision arbeitet er sowohl als Data Scientist als auch PIM Consultant. Sein Ziel ist es Daten zugänglich zu machen und auf Basis deren Auswertung Prozesse zu optimieren und faktenbasierte Entscheidungen zu fördern. Markus Neef ist Digital Marketing Specialist bei TechDivision. Er ist Master of Science (M.Sc.) in Web Communication und Information Systems und nutzt sein Wissen aus den beiden Bereiche um bei Projekten Marketingaspekte mit technischen Strukturen zu kombinieren und so nachhaltig erfolgreiche Website und -shop Konzepte sowie Digitalisierungsstrategien zu entwickeln. Eines seiner Fokusgebiete ist dabei der Bereich Produkt Information Management.