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

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:
 

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: