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, welche die kurzen Halbwertszeiten von Prozessen und Features berücksichtigen, zu kommen. Hier spricht man dann häufig von sogenanntem 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 vorliegendem 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 Produktinformationsmanagement 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 Produkt Informationsmanagement
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 kennen bzw. zumindest 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 Methodenset an den richtigen und wichtigen Stellen kritisch zu hinterfragen, ob bestehende Prozesse wirklich in der – häufig historisch gewachsenen – Art sinnvoll sind. Oft ergeben sich bereits durch eine strukturierte Analyse bestehender Prozesse Verbesserungspotentiale. 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 die damit verbundenen Möglichkeiten immer mehr aus vorhandenen und teilweise auch schlechten 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 Produktinformations 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 tatsächlich benötigt werden und in welcher Form diese vorliegen oder 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 Datenmengen und auch eine falsche 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:
- Standardattribute: Diese werden ohne Anpassung ins Zielsystem übertragen
- Migrationsattribute: Diese werden im Altsystem erstellt und befüllt, um dann anstelle eines Alt-Attributes ins Zielsystem übertragen zu werden.
- Transformationsattribute: Diese Attribute dienen als Hilfsmittel und Anweisung an unser Migrationstool nach dem Muster “Mach´ aus X im Altsystem Y im neuen System (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- und Shopsysteme), 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.
► 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 V1 gepflegt
- Printkatalog mit mehreren hundert Seiten ist zentrales Marketinginstrument 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
Version | Akeneo 1.6 | Anzahl der Locals | 9 |
Anzahl der Nutzer | > 30 | Anzahl der Familien | 4 |
Anzahl Währungen | 1 (EUR) | Anzahl der Product Models | > 2.700 |
Anzahl Attribute | > 600 | Anzahl Kategorien | > 1.100 |
Anzahl Attributsgruppen | 13 | Anzahl Kategoriebäume | 1 |
Anzahl Produkte | > 20.000 | Anzahl Kanäle | 2 |
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:
Locals | Es wurden 9 verschiedene locals 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 inkonsequent 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 Achsen haben! (in Akeneo v3 nur noch max. 2 möglich) -->Insgesamt haben 303 von 2781 (11%) mehr als 2 Achsen. 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 aus der Tabelle 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 sogenannten Produktfamilie 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 selbst einem Laien recht 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ötige Pflegeaufwände entstehen 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 u.v.m. können – abhängig vom jeweiligen Kunden und Projektumfang – eigene Bücher geschrieben werden. Wir haben hierbei häufiger die Erfahrung gesammelt, dass sich Prozesse oder Workarounds über einen längeren Zeitraum beim Kunden entwickeln und etablieren und aufgrund einer gewissen “Betriebsblindheit”, die in einem gewissen Umfang irgendwann normal ist, 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 Onlineshop 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 Worst-Case 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
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 systemagnostisch sind. Erst wenn diese Faktoren ausführlich betrachtet wurden, kommt die Frage nach der Software. Wir haben uns hier für Akeneo entschieden, weil die Denkweise – nämlich 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.
Autor
Sebastian Zürcher
Data Scientist und PIM Consultant bei TechDivision
Dr.-Ing. Sebastian Zürcher war Forscher im Bereich der chemischen Industrie und arbeitet seit über 15 Jahren mit mathematischen Modellen und Datenanalyse. Im Ver- lauf 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 Un- ternehmen 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 Entschei- dungen zu fördern.

Autor
Markus Neef
Digital Marketing Specialist bei TechDivision
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.
www.techdivision.com
m.neef(at)techdivision.com