On-Demand Webinar: Produktdaten effizient managen

Das erfahren Sie im Webinar:

Die Tatsache, dass Produktdaten der Schlüssel zum Erfolg sind, trifft nicht nur auf die Erfüllung von Anforderungen und Zielen aus der Businesssicht unserer Kunden zu. Unsere Erfahrungen aus der Praxis zeigen zusätzlich, dass auch die Umsetzung eines Digitalisierungsprojektes mit der Zulieferung von Produktdaten positiv wie auch negativ beeinflusst werden kann. Gemeinsam stellen wir diesen Erfolgsfaktor nachhaltig auf qualitativ hochwertige Beine, so dass sie in Zeiten stetig wandelnder Ansprüche Ihrer Zielgruppen an Frontends und Kanäle Ihre Produktdaten in Gold verwandeln.    

In diesem Webinar zeigen wir anhand von Problemfälle aus der Praxis auf, wie Sie durch den Einsatz eines Product Information Managements (PIM) Mehrwerte bereits im Implementierungsprojekt schaffen können und so hohe Kosten auf Ihrem Weg in eine digitale Zukunft sparen können.

Transkript zum Webinar Produktdaten effizient managen

Vorstellung & Begrüßung

Hanni Gummel: Herzlich willkommen zu unserem heutigen diva-e Webinar. Es geht heute um das Thema Produktdaten, wie diese effizient gemanagt werden können und wie auch Herausforderungen in der Praxis nachhaltig gelöst werden können. Mein Name ist Hanni Gummel. Ich bin Teil des Marketingteams und darf heute das Webinar begleiten. Und an dieser Stelle ganz herzlich unsere Referentin und Referenten vorstellen. Die Jacqueline Els. Sie ist Expert Consultant und Team Lead bei der diva-e und ihre beiden Kollegen Robert Saul und Tobias Watermann. Sie sind beide PIM Consultant. Schön, dass ihr da seid und heute eure Expertise und Erfahrung aus dem Bereich mit uns teilt. Und ich gebe jetzt ab an euch direkt und wünsche allen Teilnehmenden ganz spannende Erkenntnisse im Webinar.

Jacqueline Els: So, vielen lieben Dank Hanni für die Vorrede und die Einleitung. Ich hoffe, man sieht den richtigen Screen? Wunderbar. Dann herzlich willkommen, auch von unserer Seite, ein Hallo in die Welt. Was haben wir heute mitgebracht? Wir haben heute einige Beispiele aus dem Bereich Herausforderungen rund um Produktdaten mitgebracht. Produktdaten, Produktdateninformationsmanagement ist, wie Hanni schon gesagt hat, unsere Hauptdomäne, unser tägliches Ziel. Und es bleibt nicht aus, dass wir in den vielen Projekten, die wir betreuen, ab und zu auch mal auf Herausforderungen stoßen. Da haben wir uns einige Beispiele herausgezogen, mitgebracht und haben auch ein paar Lösungen mitgebracht, wie man auf solche Produktdatenherausforderungen reagieren kann. Zunächst ein paar Worte zur diva-e. Wer sind wir, was machen wir? Einige von euch kennen uns mit Sicherheit. Kennen uns auch vielleicht schon aus gemeinsamen Projekten. Wir sind eine der größten Digitalagenturen in Deutschland. Beschäftigen 800 Experten in verschiedenen Bereichen der Digitalisierung und können mit stolz behaupten, dass wir auf Erfahrung seit 1995 zurückblicken können. Der Fokus in unserer Arbeit liegt in der kompletten digitalen Wertschöpfungskette im B2B und B2C Bereich. Wir beraten von der ersten Idee, von der Strategie über die Systemauswahl, über die Implementierung bis hin zu den kompletten Maintenace-Aufgaben, die dann im Nachgang, im laufenden E-Commerce-Projekt, anfallen. Ja, wir sind Nummer eins Digitalpartner, wie gesagt, in Bereichen Content, Commerce, Performancemarketing et cetera. Haben Partnerschaft mit allen namhaften und relevanten Technologien, die man am Markt kennt. Und meine Kollegen und ich sind heute stellvertretend für den Bereich PIM/MDM hier dabei. Das Team hat jetzt mittlerweile über 20 Experten. Darunter auch zertifizierte Consultants und Entwickler. Und Partnerschaften haben wir aktuell mit Akeneo und mit Stibo Systems. Kennen uns aber auch in allen anderen namhaften PIM/MDM Technologien aus. Das gehört zu unserem Job. Genau. Kunden in unseren Referenzen sind beispielsweise Klöckner, SCHOTT, ZEISS und viele, viele mehr. Und wir können stolz sein, dass wir Platz sieben im Arbeitnehmerranking belegt haben im letzten Jahr durch die Great Place to work Umfrage. Das heißt, die Kollegen und Experten, die bei uns arbeiten, arbeiten auch recht gerne bei uns. Wir sind ein sehr angenehmer Arbeitgeber.

Ja, was ist unsere Hauptaufgabe im PIM/MDM Bereich?

Jacqueline Els: Was ist so unsere Mission, die uns jeden Tag erneut antreibt? Wir sind uns sicher, dass wir ein erfolgreiches Business für unsere Kunden und letztendlich aber auch in unseren Projekten sicherstellen können, in dem wir kanalspezifische und gut strukturierte Produktdaten zur Verfügung stellen, die sich letztendlich aber in Ihrem daily Business oder in eurem daily Business auch effizient be- und verarbeiten lassen. Daten sind für Digitalprojekte jeglicher Art so das Muss, ja. Ohne geht es nicht. Und natürlich macht es das ganze runder, wenn diese Daten auch strukturiert zugearbeitet und verarbeitet werden können. Schauen wir kurz auf die Agenda. Was haben wir heute mitgebracht? Wir werfen einen ganz kleinen Blick auf das Thema PIM. Was ist es, was kann ich mir darunter vorstellen? Als nochmal Summary am Anfang. Dann schauen wir uns mal an, welchen Herausforderungen wir im Projektalltag begegnen. Da haben wir uns dann zwei Beispiele herausgepickt. Haben hierzu mal eine Ausarbeitung gemacht oder einen Vorschlag gemacht, wie eine Lösung auf diese Herausforderung aussehen kann. Welche Benefits bringt das mit sich?

Nicht nur für unsere Kunden, sondern direkt weg auch für das Projektteam und dann sind wir natürlich auch gerne noch für Fragen da und beantworten diese noch. Genau. Ja. Um sich vorstellen zu können: Was ist ein PIM? Was hat es für Aufgaben? Und warum brauche ich in meiner Systemlandschaft noch zusätzlich ein System, was Produktdaten innehält und Produktdaten strukturiert. Um das zu erklären, steigen wir recht gerne mit einem Blick auf den digitalen Kunden-Lebenszyklus ein. Das Ganze hat sich geändert über die letzten Jahre. Ich denke, da erzähle ich hier niemandem etwas Neues. Ursprünglich traditionell ist es schon so gewesen: Der Kunde hat recherchiert in Medien wie schon Online, aber auch Kataloggeschäft, Point of Sale, solche Geschichten. Hat einen Lieferanten und ein Produkt gefunden. Man hat sich das angeschaut, hat gekauft. Und wenn man sich dabei recht gut angestellt hat, Service gestimmt hat, Lieferzeit, Preis/Leistung gestimmt hat, dann ist es oftmals auch so gewesen, dass der Kunde schon recht treu war. Das Ganze haben wir heute nicht mehr. Heute sind die Kanäle, in denen ich mich über Produkte informiere, in denen ich das Produkt, was ich brauche, suche, sehr, sehr vielfältig. Und diesen Fakt haben wir nicht nur im B2C, sondern tatsächlich auch im B2B. Sei es, dass man abends auf der Couch nochmal nach einem Produkt sucht. Dass man gegebenenfalls auch Erfahrungsberichte von anderen Nutzern wissen möchte bis hin zu Bewertungen oder Bedienungsanleitungen. Videos, die über YouTube gestreut werden. Das sind die unterschiedlichsten Kanäle und je mehr Kanäle wir haben, desto höher sind auch die Anforderungen an die kanalspezifischen Produktdaten. Das machen wir immer ganz gerne an einem Beispiel fest. Wir haben das Medium Katalog, in dem ein Produkt abgebildet wird und stellen das mal gegenüber dem Onlineshop, in dem das Produkt verkauft werden soll. Da ist natürlich ein ganz klarer Unterschied in den Anforderungen. Im Katalog habe ich immer nur kleine Teilbereiche, wenig Platz zur Verfügung, muss mich auf das Wesentliche konzentrieren und hier das Produkt beschreiben. Im Onlineshop habe ich dann die Anforderungen, dass ich natürlich auch suchmaschinenoptimierten Text zur Verfügung stellen muss. So dass letztendlich auch organischer Traffic auf die Seite kommt, ja. Es ist eine Herausforderung, all diese Anforderungen tatsächlich abzubilden, wenn ich jetzt ein ERP zur Verfügung habe. Oder letztendlich vielleicht auch nur eine Excel-Tabelle, die Produktdaten beinhaltet. Weil ich natürlich dafür Sorge tragen muss, dass kanalspezifisch der Content und alle Informationen irgendwo in einem System nachgehalten werden sollen. Ja.

Hier kommt das Produktinformationsmanagement bzw. auch das Master-Data-Management ins Spiel

Jacqueline Els: Und ganz kurz erklärt gibt es hier oder funktioniert ein PIM in drei Schritten. Wir haben auf der linken Seite im ersten Schritt natürlich alle Datenquellen, die wir sammeln, die wir analysieren in unseren Projekten. Und die wir im ersten Schritt auch an das PIM-System andocken. Wie ich vorhin schon gesagt habe, das ist nicht nur ein ERP oder die Daten vom Lieferanten. Das ist stellenweise auch der Produktkatalog, der beim Kollegen XY hinten im Regal steht oder die Excel-Tabelle oder noch ein zusätzliches Word. Vielleicht auch Medien, die abgelegt sind in einem Data-Asset-Management. Da sind die Möglichkeiten sehr umfangreich. Erster Schritt ist also, wir docken das an das PIM-System an und schauen, welche Daten wir hier für das PIM-System benötigen und schauen im zweiten Schritt, wie wir das im PIM-System quasi abbilden. Es geht dann darum, die Produktdaten hier auch anzureichen, kanalspezifisch anzureichern und eine Produkt-Daten-Qualität zu erhalten, die einfach dafür sorgt, dass der Kunde letztendlich unser Produkt kauft und dass hier keine Fragen mehr offen sind. Das Ganze wird begleitet von einem Workflow-Management, so dass Sie oder ihr für euer Unternehmen auch sicherstellen könnt, dass die Produktdatenpflege sehr effektiv läuft. Ja. Hier haben wir mal ein Beispiel mitgebracht. Wenn man mit Übersetzungsagenturen arbeitet, ist die Kommunikation mit Übersetzungsagenturen oftmals sehr umfangreich oder erhöht. Und man kann über einen Workflow im PIM-System einfach dafür sorgen, dass auch die Übersetzer Zugriff auf die Produkte haben. Nur die Bereiche sehen, die sie letztendlich wirklich übersetzen müssen und dann ihre Arbeit ohne große Absprachen per Mail, per Telefon et cetera tun können. Im dritten Schritt geht es darum, die Daten an die Ausgabekanäle zu geben. Und hier ist auch eine hohe Vielfalt gegeben. Wir haben nicht nur die typischen Geschichte wie, ja, E-Commerce, Mobile Apps und Prints. Sondern auch die Voice-Assistants, die jetzt dazugekommen sind. Marktplätze, aber auch Produktdaten, die in Newslettern zum Kunden geschickt werden. Diese Ausgabekanäle werden auch recherchiert, analysiert und festgelegt. Und es geht letztendlich da drum, dann über eine Schnittstelle die Produktdaten in Regelmäßigkeit dort auszuweiten. Was bringt uns das für Vorteile? Letztendlich je höher die Qualität Ihrer Produkte, desto höher ist auch die Chance, Ihren Erfolg zu steigern, ja. Wir erhöhen somit Conversion Rates, es bleiben keine Fragen mehr offen beim Kunden. Der Kunde weiß wirklich, was er kauft. Und dadurch, dass der Kunde alle Informationen zum Produkt hat, senken wir hier auch beispielsweise die Retourenquoten. Was wiederum zu niedrigeren Kosten in Ihrem Unternehmen führt. Zusätzlich dazu haben alle PIM-Systeme, MDM-Systeme die Möglichkeit, natürlich auch Up-Sell-Produkte, Cross-Sell-Produkte oder Zubehör zuordnen zu lassen. Was wiederum Ihren Warenkorbswert steigert, beziehungsweise auch die Möglichkeit des Nachkaufs. Wir haben alle Produktdaten an einem Ort, können sie sehr strukturiert aufarbeiten, sehr effizient aufarbeiten. Was dazu führt, dass wir natürlich auch die Chance auf eine höhere Reichweite haben. Wir können sehr viel schneller neue Absatzmärkte konfigurieren beziehungsweise anschließen. Wenn man sich überlegt: Okay, ich möchte auf Marktplatz XY meine Daten ausspielen, dann schaut man sich an, welche Anforderungen, welche Anpassungen muss ich noch tun. Ich habe die Daten aber einmal an einem Ort und kann sie dann nach Anpassung auch recht schnell ausspielen und diesen neuen Kanal zur Verfügung stellen. Strukturierte Workflows sorgen intern auch für eine Prozesskostenoptimierung. Man kann diesen kompletten Produktpflegeprozess sehr viel effektiver darstellen und durch eine clevere Umsetzung dieser Workflows im PIM weiß auch jeder Kollege, wann er was zu tun hat. Die Abstimmung wird sehr viel einfacher. Letztendlich erhöhen wir die Qualität unserer Produktdaten, das hatte ich Eingangs schon gesagt, und reagieren auf die Anforderungen, die die einzelnen Kanäle haben. Ja. Unsere Projekte, es ist schon der Fall, dass auch in unseren Projektdaten, Rundumproduktdaten es die ein oder andere Herausforderung gibt, die wir meistern müssen. Die wir zusammen mit unseren Kunden meistern müssen. Wenn Sie vielleicht ein eigenes Digitalisierungsprojekt haben oder Shopprojekt haben wissen Sie: Produktdaten, das kann schon ordentlich sein, wenn sie nicht ganz so strukturiert sind. Das fängt an, dass wir mitunter mehrere Datenquellen anknüpfen müssen, die unterschiedliche Ausgabeformate auch haben, ja. Wir müssen also im PIM-System darauf reagieren, dass Daten in unterschiedlichen Formaten zur Verfügung gestellt haben. Wir haben Daten von Lieferanten, die wo wir den Fall haben, dass wir zum gleichen Produkt, wenn wir es von verschiedenen Lieferanten geliefert bekommen oder einkaufen, dass wir natürlich auch unterschiedliche Daten zur Verfügung gestellt bekommen. Hier muss man schauen: Wie vereinheitlicht man die, wie bildet man die in dem PIM-System ab. Gleichzeitig muss man aber schauen. Lieferanten liefern natürlich ihren Content auch an mehrere Händler. Ja. Und man muss schauen, dass man hier unique Content schafft, dass man sich von dem Rest abhebt. Und dass man hier auch im PIM-System die Möglichkeit dazu hat, sich vom Rest abzuheben. Weiterhin kennen wir es, dass standardisierte Daten oftmals auch mit komplexen Logiken oder Abhängigkeiten zueinander, dass das in Frage kommt, ja. Das wiederum muss auch im System abgebildet werden. Wenn wir schauen, wenn ihr euch international aufstellen wollt, gibt es auch hier verschiedene Anforderungen. Unterschiedliche Maßeinheiten, unterschiedliche Sprachen. Auch unterschiedlicher Content mitunter, der hier abgebildet werden muss. Ein Übersetzungsprozess, der dahinter geschallten werden muss. Auch das führt dazu, dass wir gegebenenfalls Produktdaten nicht so schnell zugeliefert bekommen, wie wir es für Digitalisierungsprojekte benötigen. Auf der nächsten Seite nochmal ein paar Beispiele. Die Vereinheitlichungen von Angaben. In Ihrem Produktmanagement sitzen, weiß ich nicht, zehn Personen, fünf Personen, je nachdem. Die natürlich alle eine andere Auffassung haben, welcher Blauton das jetzt beispielsweise ist. Für den einen ist es ein Dunkelblau, für den nächsten ist es ein Azurblau. Und wenn ich hier im Pflegeprozess keine Regeln setze, ja, dann habe ich im Onlineshop beispielsweise das Problem, dass der Kunde verschiedene Blautöne im Filter hat und das Shopsystem dafür sorgen muss, dass er quasi nur einen Filter hat, der heißt blau. Ein großes Thema ist oftmals die Bildung eines Master-Varianten Konzepts. Da gehen wir später auch noch darauf ein. Das ist eine sehr, sehr wichtige Sache, die man Anfangs schon klären sollte. Denn auf solchen Konzepten baut natürlich auch dann das komplette Back-End und Front-End von Shopsystemen auf. Wenn man im Nachgang nochmal sehr umfangreiche Änderungen an dem Produktkonzept, an dem Datenkonzept macht, dann ist das einfach mit Aufwand verbunden. Pflegeprozesse habe ich bereits genannt.

Warum sind Pflegeprozesse bei Ihnen intern Herausforderungen in den folgenden Implementierungsprojekten?

Jacqueline Els: Weil wir einfach Produktdaten natürlich auch zeitnah und pünktlich zur Verfügung gestellt bekommen müssen, ja. Das sind so Herausforderungen, die wir in der Praxis haben. Sicherlich gibt es da noch einige mehr. Auch ihr in eurem Unternehmen wisst sicherlich die ein oder andere Herausforderung. Ich möchte jetzt aber ganz gerne mal an den Tobias übergeben, der das erste Beispiel Datenquellen und Zielsysteme mal genauer betrachtet.

Tobias Watermann: Genau. Vielen Dank, Jacqueline. Wie bereits erwähnt würde ich mich gerne jetzt mit dem Thema Datenquellen und Zielsysteme beschäftigen. Oder beziehungsweise da mal einen Ausblick geben, was uns in den Projekten dann immer so erwartet, beziehungsweise welche Herausforderungen wir mit diesen zwei Themen eigentlich so haben.

Datenquellen

Tobias Watermann: Ganz typisch für uns, in so einem Projekt, ist erstmal die Tatsache, dass Produktinformationen immer von ganz unterschiedlichen Quellen kommen. Und dass diese auch immer in ganz unterschiedlichen Formaten zur Verfügung stehen. Das heißt, wir haben zum Beispiel verschiedene Abteilungen, die unabhängig voneinander an Produkt-Informationen arbeiten. Sei es jetzt zum Beispiel die Marketingabteilung oder das Produktmanagement, die jeder für sich irgendwie dort Produktinformationen behandeln, aber es auf ihre ganz eigene Art und Weise tun. Und das sehen wir auch ganz oft, dass dann im Prinzip die Mitarbeitenden überhaupt selbst nicht wissen, wo diese Daten teilweise herkommen. Also, sie haben sie einfach nur zur Verfügung, nehmen diese. Aber wo eigentlich diese Information herkommt, beziehungsweise wo die gepflegt wird, diese Information ist nicht vorhanden in den einzelnen Abteilungen. Und das liegt unter anderem daran, dass wir hier also keinen Single Point of truth, oder wie wir es nennen, der Produktinformation haben. Das heißt, für uns ist erstmal die erste Herausforderung, wenn es um das Thema Datenquellen geht: Wer sind eigentlich die verantwortlichen Personen, die sich darum kümmern? Und wie kommen diese an diese Information? Daraus resultierend stehen wir dann meistens aber auch vor so einer Art Datenchaos. Also, wie ich das gerade schon erwähnt habe. Die einzelnen Abteilungen arbeiten vielleicht sogar in Systemen, die gar nicht dafür geeignet sind, Produktinformationen zu befüllen, weil diese natürlich auch nicht untereinander oder miteinander sprechen. Wie zum Beispiel ein ERP-System und ein Shopsystem. Dann befüllt irgendjemand Produktinformationen im Shop oder im ERP-System. Und trotzdem muss irgendwie darauf geachtet werden, dass die synchron miteinander sind. Und dann haben wir Tabellen und ganz viele andere Tools. Und ich nenne das immer Inselwissen. Also, es gibt dann immer in ganz vielen unterschiedlichen Abteilungen Wissen, wo welche Information liegt, aber die andere Abteilung weiß nichts von der anderen. Und da ist dann halt für uns auch wieder in der Situation die Herausforderung wieder ganz genau: Wie kommen wir an diese Information und an die Formate? Und dann natürlich auch: Wie bekommen wir diese ganzen Formate zusammengeführt? Und in der folgenden Grafik sehen wir dann auch, was unser Zweck ist. Nämlich der sogenannte Golden Record. Der Golden Record ist bei uns der Zustand, der die Wahrheit kennt über das Produkt. Heißt, wir führen alle diese Quellen, die wir finden, zusammen. Tragen alle diese Informationen zusammen und haben dann am Ende hier dieses gelbe Feld, nämlich unseren Golden Record. Und dann haben wir nämlich ein System, was die Wahrheit spricht, was die Wahrheit kennt und wo auch weiterhin die Wahrheit dann gepflegt wird. Also, das ist unser Ziel in der ganzen Datenquellen-Thematik.

Und um da auch wirklich hinzukommen, müssen wir uns in einem Projekt, gerade am Anfang, Fragen stellen

Tobias Watermann: Und das sind die folgenden Fragen: Wer und was und wo und wie. Eigentlich ziemlich einfach, aber es sind sehr essenzielle Fragen für uns. Und fangen wir mal mit wer und was an. Wie wir das ja vorhin schon gesagt haben. Wer sind die verantwortlichen Personen und wie kommen wir an diese Informationen? Und ein ganz wichtiger Bestandteil, um an diese Information zu kommen, sind für uns Workshops. Und wir nehmen dafür alle Verantwortlichen und alle an Produktinformationen arbeitenden Menschen und schauen uns erstmal alles an. Was gibt es für Prozesse? Welche Produktinformationen werden wo gepflegt? Und, ja, zusammen erarbeiten wir das dann an der Stelle. Und sobald wir einen Überblick über all diese Quellen und Informationen haben, analysieren wir diese, sammeln diese und können dann auch schon anfangen, diese zu konsolidieren. Und die ganzen unterschiedlichen Datenstrukturen und aus Exporte aus anderen Systemen schauen wir uns auch an. Und, ja, haben dann schonmal einen Überblick, was es eigentlich gibt. Die nächste Frage ist dann wo und wie. Also, wie werden all diese Informationen zusammengeführt? Und da ist dann für uns auch schon eigentlich einer der wichtigsten Aspekte. Die richtige Wahl des PIM-Systems. Weil wenn wir ganz viele unterschiedliche Formate beispielsweise von unseren Quellen haben, dann müssen wir uns ja fragen: Wie soll das PIM-System diese Information verarbeiten und wie sollen diese Produkte am Ende abgebildet werden? Dass, was sich dann wieder mit dem Datenmodell beschäftigt. Darauf kommen wir später nochmal zu sprechen. Braucht mein PIM-System beispielsweise eine Funktion wie ein Mapping? Also muss ich beispielsweise Formate übernehmen, die in ein neues Format bringen. Muss ich dafür gewisse Felder mappen können? Und wen wir diese ganzen Fragen erstmal geklärt haben und wir uns auf ein PIM-System geeinigt haben, beziehungsweise eins für, ja, für den Aspekt richtiges PIM-System empfunden haben, dann kommen wir der sogenannten Urladung, nämlich dem ersten initialen Import, wo wir all diese Informationen nehmen, die wir jetzt erarbeitet haben in den Workshops. Und, ja, alles an einen Ort, nämlich unser PIM-System dann importieren. Und dort kennen wir dann im Prinzip unsere Wahrheit über das PIM-System. Nämlich die zentrale Stelle, wo all die Informationen gehalten werden. Das ist dann der erste Schritt von diesen drei Schritten, die wir eben gerade bei Jacqueline noch in der Grafik gesehen haben. Und ich gehe dann jetzt nochmal auf den letzten Schritt. Also, nicht auf den mittleren sondern auf die Ausleitung ein, nämlich die Zielsysteme. Und hier haben wir die Herausforderung, dass Zielsysteme, also unsere ganzen Kanäle, eigentlich immer gleichzeitig mit Informationen versorgt werden müssen. Am besten noch in unterschiedlichen Sprachen und das halt auch synchron. Und hier haben wir auch ganz oft die Herausforderung, dass bis zu einem Einsatz von einem PIM-System die Abteilungen unabhängig voneinander diese Daten ausleiten. Also, das heißt es gibt verschiedene BUs, Business Units, Abteilungen, die sich dann um den Web-Shop kümmern, um die Homepage, um was auch immer. Und die arbeiten natürlich für sich selbst und machen das auf ihre Art und Weise. Das heißt, da gibt es dann eine Tabelle, die gefüllt wird. Manchmal auch manuell. Manche Sachen passieren schon automatisch. Und wie auch bei den Datenquellen ist es auch ganz oft hier der Fall, dass es kein allgemeines Wissen gibt über die Zielsysteme. Es gibt kein allgemeines Wissen. Was für Zielsysteme gibt es überhaupt und wie werden diese befüllt? Was uns dann auch zu der Frage führt. Aber wenn wir uns die Zielsystem anschauen, müssen wir uns natürlich auch diese Datenverteilung anschauen. Also, wie bringen wir das jetzt überhaupt vom PIM in die jeweiligen Zielsysteme. Und im besten Fall kann ein Kanal direkt vom PIM mit Produktinformationen versorgt werden oder ruft sich diese ab. Zum Beispiel via RP oder einem Hot Folder. Also da, wo dort Daten abgelegt werden, dort zieht sich das System dann sozusagen die Produktinformation, die das PIM zur Verfügung stellt. Das ist natürlich der beste Fall für uns. Aber wenn es dann ein bisschen komplexer wird und wir auf ganz viele Anfragen eingehen müssen für x-beliebig viel tausende Produkte kann es halt auch sein, dass so ein PIM-System ganz schnell an seine Grenzen kommt. Und wir dann aufgrund von ganz vielen Live-Abfragen, also Echtzeit-Abfragen, das System überlasten. Das muss man dann halt auch abwägen. Und je mehr Ausgabekanäle ich habe, müssen wir halt auch schauen, wie wir das ganze Problem dann lösen. Und dann kann zum Beispiel eine Art Enterprise Service Bus Abhilfe schaffen, indem wir so etwas dann in dieser Architektur abbilden. Und das sehen wir hier. Wir haben dann zum Beispiel ganz unten sieht man das PIM-System. Und die blauen Felder dort oben sind unsere Ausgabekanäle beziehungsweise unsere Kanäle generell. Und in der Mitte sehen wir diesen Enterprise Service Bus. Und dieser macht es jetzt für mich sehr komfortabel Daten auszuleiten als auch Daten zu empfangen. Ich bin also in der Lage, dem Enterprise Service Bus etwas zur Verfügung zu stellen und der weiß ganz genau: Ah, okay, ich muss das jetzt so in der Art an die Website, an die Kataloge, an die Webshops, ans ERP-System schicken. Und dieser Enterprise Service Bus weiß auch ganz genau: Ah, okay, ich bekomme etwas vom ERP-System, beispielsweise. Und ich weiß, wie das PIM-System das braucht. Und da auf diesem Bereich können natürlich auch ganz viele Abfragen stattfinden. Live-Abfragen über Produktinformationen, weil dieser genau dafür ausgelegt ist. Entscheidet man sich natürlich jetzt hier an der Stelle auch also so eine Art von Architektur einzuführen, dann haben wir hier natürlich auch wieder Herausforderungen in der Datenverteilung. Dazu komme ich auf der nächsten Seite. Genau. Nämlich wenn man sich jetzt entscheidet, so ein Layer oder Integrationsware wie er auch gerne mal genannt wird, einzuführen, kann das natürlich auch Aufwand in der Entwicklung verursachen. Weil eventuell Daten oder beziehungsweise, ja, Daten neu konvertiert werden müssen für die jeweiligen Zielsysteme, wenn das nicht automatisiert möglich ist. Und wenn zum Beispiel ein PIM-Export nicht optimal zur Verfügung gestellt wird, also ich keine Channel-spezifischen Exporte, wie das manche PIM-Systeme können, zur Verfügung stellen kann, dann habe ich dadurch natürlich auch mehr Aufwand, weil ich das wieder vom Integration-Layer lösen muss. Und diese Daten dann nochmal erneut angefasst werden müssen, konvertiert, gefiltert. Und das ist natürlich für uns eigentlich unnötiger Aufwand in der Entwicklung. Also, was habe ich hier nochmal in der Datenverteilung für Herausforderungen? Wie muss das PIM-System die Produktinformation liefern, dass ich den kleinstmöglichen Aufwand auch dann beispielsweise für so ein Integration Service Bus habe, Enterprise Service Bus. Und welche Daten braucht der Layer vom PIM für welches System? Und welche Produktdaten, welchen Ausschnitt zum Beispiel von Produktdaten braucht welches System? Dazu sieht man, dass in der folgenden Grafik sieht man das auch nochmal ganz gut. Hier hätte ich nämlich ein Beispiel, wo aus dem Golden Record, dass er unsere Wahrheit spricht, einfach einen Datenstamm an den Layer geht und dieser verteilt das. Und wir wollen natürlich, dass, wie wir das gerade schon gesagt haben, mit dem kleinstmöglichen Aufwand die Daten verteilt werden. Und dazu schauen wir uns dann halt auch nochmal in Workshops die Prozesse an. Wie wird das gelöst? Welche Channels gibt es? Wie brauchen diese Channels die Information? Damit wir dann am Ende nicht auf dieses Ergebnis dieser Grafik kommen, sondern auf das nächste Ergebnis. Nämlich dass der Golden Record schon Einzelteile meines Gesamtsortiments spezifisch für den Ausgabekanal zur Verfügung stellt, sodass der Integration-Layer nur noch diese Teile nehmen muss und die weitergibt an die bekannten Ausgabekanäle. Und so kommen wir dann natürlich an ein ganz gutes Ergebnis, um die Daten weiter auszuleiten. Und das fasst dann auch ganz gut unsere Ziele zusammen, die wir in Bezug auf Datenquellen und Zielsysteme haben. Nämlich erstes Ziel, ganz klar, wir wollen das richtige PIM für den richtigen Zweck. Es gibt ganz viele unterschiedliche PIM-Systeme und wir müssen schauen, welches passt für welches Projekt am besten. Und welches erfüllt seinen Zweck an der Stelle. Wir brauchen also unser Ziel aus diesen ganzen Workshops und das Erarbeiten und das Analysieren der Daten. Wir brauchen eine Single Source of truth oder einen Golden Record, wie wir das auch nennen, so dass ein System die ganze Wahrheit kennt. Und wir wollen natürlich auch verhindern, dass dieses ganze aufwändige zusammensuchen und mappen der Daten aus den verschiedenen Systemen, dass das ausgelagert wird und vom PIM vorgenommen wird. Und dass das dann im Prinzip häppchenweise an diese Ausgabekanäle weitergegeben wird und dass wir dadurch keine redundanten Konfigurationen oder Aufwände mehr haben. Und was uns dann im Endeffekt ganz simpel zu mehr Effizienz in der Weiterleitung von Produktinformationen führt. Und das sind unsere Main-Goals im Thema Datenquellen und Zielsysteme. Man sieht, wir haben hier schon viele Herausforderungen, wo wir aber einen klaren Weg haben. Und ein Bestandteil von diesem ganzen ist die Variantenbildung und auch Datenmodel. Und da würde ich jetzt gerne an der Stelle an Robert weitergeben, der darüber mehr erzählen möchte.

Robert Saul: Vielen Dank für die super Überleitung, Tobi. Genau. Also, wir hatten das jetzt schon häufiger gehört in den vorangegangen zwei Teilen. Die beiden Wörter Variantenbildung und Datenmodell. Und deshalb ist es uns jetzt wirklich auch mal wichtig, in ein sehr spezifisches PIM-Thema auch einzusteigen und diesen einen, sehr speziellen, Bestandteil eines PIMs auch mal noch genauer zu beleuchten. Dazu haben wir auf der ersten Folie zu dem Themenkomplex zwei Grafiken mitgebracht. Auf der linken Seite ist jetzt exemplarisch einfach mal die Struktur eines Datenmodells aufgezeichnet. Die, wie man schon auf den ersten Blick erkennen kann, wirklich sehr, sehr komplex und wahrscheinlich auch gar nicht so gut nutzbar sein wird. Zumindest wenn es nur um Produktdaten gehen soll. Deshalb haben wir auf der rechten Seite dann nochmal eine andere Lösung mitgebracht, die uns letztes Jahr zusammen mit einem Kunden im Fashion-Bereich erarbeitet haben. Ich hoffe, man hört meinen Hund nicht. Doch? Ist gleich ruhig. Und da sieht man das wirklich, dass es in mehreren Hierarchieebenen untergliedert ist. Und dass dann wirklich das Produkt, was man schlussendlich kauft, was dann schlussendlich in den Warenkorb gesteckt werden kann, dass das noch mehrere andere Produkte übergeordnet hat. Also es noch mehrere Produkthierarchien darüber gibt, die auch irgendwie eine Art Produkt sind, aber halt in unserem Sinne dann einfach nur virtuelle Produkte, die dazu da sind, alle darunterliegenden Produkte zu gruppieren. Und da sieht man dann auch schon in diesem Datenmodell, was auf der rechten Seite abgebildet ist. Ganz rechts unten steht da Product Variants: Size.

Was genau ist eine Produktvariante?

Robert Saul: Und dazu würde ich mal mein Lieblingsbeispiel zitieren, was jetzt hier auch ganz gut passt zu dem Datenmodell aus dem Fashionbereich. Nämlich geht es um T-Shirts, ja? Also, wir stellen uns vor, wir haben zwei verschiedene T-Shirts. Das eine ist rot, das andere ist blau. Ansonsten unterscheiden sich diese beiden T-Shirts nicht. Das heißt, die wurden aus demselben Garn hergestellt, sie sind in der gleichen Größe, gleiche Passform, gleiche Qualität. Haben den gleichen Kragen. Das einzige, sie unterscheiden sich in der Farbe. Wenn es jetzt nicht nur rote und blaue T-Shirts geben sollte, sondern sagen wir es gibt zwölf verschiedene Farben und auch für jede dieser zwölf Farben nochmal sechs verschiedene Größen und nochmal einen V-Neck und einen Round-Neck. Wenn man das ausmultipliziert kommt man wirklich auf sehr, sehr verschiedene Varianten. Wenn wir uns jetzt vorstellen, dass diese Varianten alle ausmultipliziert auf der Product Listing Page auftreten, aber die alle wirklich eigentlich nur das eine einzige Produkt darstellt, wo sich dann der Endkunde dann selber noch auf der Product Detail Page selber vielleicht noch zusammenstellen können sollte: Okay, ich trage wirklich jetzt nur eine L und blau ist meine Lieblingsfarbe, ja.

Wieso müssen wir dann die Product Listing Page dann so damit überfrachten mit diesen vielen verschiedenen Varianten? Das ist der eine Grund. Deshalb fassen wir das zusammen zu einem Rohling. Legen fest, okay, auf der Product Listing Page möchte ich bitte jetzt von diesem Modell das rote T-Shirt ausspielen. Also, das war jetzt der Vorteil in der Zielseite. Also in der Seite, wo die Produktinformationen ausgespielt werden, auf den Verkaufskanälen. Aber auch schon während der Produktdatenpflege ergeben sich dadurch Vorteile, wenn man gleichartige Produkte in Form von Varianten zusammenfasst. Und zwar heißt das dann einfach, dass man die gleichartigen Informationen, das heißt, wenn ich einen Fließtext schreiben möchte über die Passform und über den Tragekomfort des blauen T-Shirts, dann ist das auch das gleiche beim roten T-Shirt.

Das heißt, ich müsste diesen einen Text dann nach dorthin kopieren. Es könnte auch sein, dass ich es nicht nur übertrage, sondern dass vielleicht erst ein halbes Jahr später noch ein zusätzliches rotes T-Shirt dazu kommt. Dass es vorhin schon das blaue gab. Und ich dann nochmal den neuen Text schreiben muss und Arbeitszeit investiere. Und die eventuell auch dort widersprüchliche Angaben zu den davor getroffenen nochmal angebe. Was halt einfach nicht gut wäre, wenn sich die Daten widersprechen und nicht ein einheitliches Bild abgeben. Die Lösung ist dann hier, dass diese verschiedenen Varianten einen gemeinsamen Parent haben. Also, wenn wir uns nochmal das Bild von vorher ins Gedächtnis rufen, dann gibt es ja verschiedene Produkthierarchien. Wo man dann jetzt hier zum Beispiel sieht: Product Variants: Size. Ganz unten rechts. Das ist dann das rote und das. Ach, nein. Das ist dann das Shirt in L und XL. Die beiden haben wahrscheinlich den gleichen Tragekomfort, der dann wahrscheinlich sogar zwei Ebenen weiter höher auf Style gepflegt werden kann. Das heißt, dass wirklich alle T-Shirts, unabhängig von der Farbe und von der Größe den Fließtext zum Tragekomfort auf Style gepflegt haben und man den dort nur an einer Stelle angeben muss und der dann automatisiert für alle darunterliegenden Produkte übernommen wird.

Warum ist es denn jetzt eine Herausforderung?

Robert Saul: Eine Herausforderung ist es, denn es sind ja nicht alles immer nur T-Shirts. Also selbst in der Fashion-Branche gibt es auch einzelne Produktgruppen, die da auch nicht so ganz einfach zu überschauen sind. Und es gibt ja auch noch ganz andere Branchen. Ich denke jetzt zum Beispiel an die Chemie-Branche. Wo es wirklich schwer ist, da als Außenstehender, der da noch nicht mehrere Jahre in dem Unternehmen arbeitet, das Datenmodell zu durchschauen und da einen Vorschlag ad hoc zu unterbreiten. Das heißt, es ist ein sehr, sehr abstraktes Thema, dem man sich wirklich strategisch nähern muss. Weil ansonsten kommt man nämlich zu diesen Nachteilen, die ich am Anfang beleuchtet habe. Dann würde ich jetzt nochmal einen Schritt größer greifen und sagen: Was ist denn überhaupt ein Datenmodell. Dazu auf der nächsten Folie dann auch noch darauf eingehen: Was kann denn alles passieren, wenn das Datenmodell falsch ist oder schlecht ist oder nicht optimal für mich. Und woran erkenne ich das überhaupt. Also Datenmodell, das auf der rechten Seite dieses Bildchen mit den hierarchischen Strukturen. Das heißt, ich versuche für mein Sortiment, was ich anbiete, ein Datenmodell zu finden, wo alle Produkte wirklich optimal hereinpassen. Das heißt, ich habe als Hersteller oder als Händler unterschiedliche Produkte, die in unterschiedliche Produktkategorien einsortiert werden können. Und das müssen nicht alles nur T-Shirts sein, das können nämlich, um jetzt bei der Fashion-Branche zu sein. Das können auch Röcke sein oder Unterwäsche oder Jacken. Und dort können sich die Informationen unterschiedlicher Art rein und in unterschiedlicher Art können die Hierarchie aufgebaut werden. Dann ist es jetzt eine Abwägungssache. Wie wird denn jetzt das Datenmodell aufgebaut? Denn das Ziel sollte nämlich sein, dass alle Produkte aus dem Sortiment in dieses eine Datenmodell passen und es nicht einzelne Produkte gibt, die sich dort so unbequem wiederfinden. Das könnte dann nämlich dazu führen, dass zum Beispiel die Vererbung, also eben, dass ich diesen einen Wert, den sich alle Varianten darunterliegend teilen, dass diese Vererbung innerhalb einzelner Produktkategorien anders funktioniert als bei anderen. All das muss schon bei der initialen Implementierung des Datenmodells mitbedacht werden. Weil ansonsten sind Fehler dann tatsächlich unvermeidbar. Darauf sind wir auch schon eingegangen, welche Nachteile das dann mit sich zieht, wenn man fehlerhafte Produktinformationen anbietet. Weitere Sachen sind dann hier zum Beispiel, wenn ich die Master Varianten Logik auch nicht richtig abbilde, dann kann es auch wirklich tatsächlich sein schlussendlich, dass mich Suchmaschinen in meinen Productlistings auch abstrafen, indem sie halt einfach denken, dass diese beiden Shirts, rotes und blaues Shirt, was sich jetzt nur in einem kleinen Wort und einem Bild unterscheidet auf meiner Product Detail Page, dass das halt einfach duplicate Content ist und deshalb nicht weiterhin so hoch geranked wird, wie es eigentlich sein sollte. Oder es kann halt auch sein, dass dann widersprüchliche sind. Auf dem roten T-Shirt steht das, auf dem blauen das. Schlussendlich ist man sich dann unschlüssig als Endkunde und bricht dann halt doch lieber den Kauf ab. Und natürlich dass die ganze Produktdatenpflege auch weitaus effizienter wird, wenn ich diesen einen Wert, der bei vielen Produkten gleich ist, auch nur einmal eingeben und auch nur einmal ausarbeiten muss. Okay. Dann würde ich das Ganze gerne zusammenfassen. Und sagen, wie man mit Expertenwissen dort auf einen wirklich guten Weg kommt. Denn es ist nämlich, um das nochmal zusammenzufassen.

Es gibt kein Schema F

Robert Saul: Also, wir können nicht einmal ganz fleißig sein und bei dem einen Kunden das Fashion-Datenmodell erarbeiten und dann noch zu zehn anderen Kunden gehen und dort dieses Datenmodell präsentiert als das ist das richtige. Weil jeder Kunde hat eine andere Produktdatenstruktur. Jeder hat unterschiedliche Produkte, händelt die anders und hat auch eine ganz andere zugrunde liegende IT-System Architektur, die nämlich auch einen Einflussfaktor auf das Datenmodell darstellt. Das heißt, wir müssen uns nämlich genau anschauen, welche Ausgabekanäle gibt es denn und in welcher Form wollen denn die Ausgabekanäle die Daten bereitgestellt haben? Es kann nämlich sein, dass es ein Job-System gibt, was wirklich nur flache Produkte annimmt. Also wirklich nur die Varianten und gar nicht darüber Informationen haben möchte: Wer ist denn jetzt der Master dieser jeweiligen Varianten. Auch dafür müssen wir gewappnet sein und müssen dann halt auf den Weg zur Ausgabe dann halt, wenn es das Datenmodell nicht zulässt, dann auch Mappings vorbereiten, um die Daten wirklich häppchenweise an die Ausgabekanäle auszugeben. Und ganz am Ende, darauf möchte ich gerne noch eingehen. Wir, als die PIM-Consultants, verstehen uns nämlich als die Mediatoren zwischen dem Datenmodell, was jetzt wirklich schon ein recht trockenes Thema ist, wie das jetzt so geklungen hat auf den letzten Folien. Und denjenigen, die sich wirklich super mit den Produktdaten auskennen, also den Produktdatenmanagern. Denjenigen, den man wirklich 50 Artikelnummern um die Uhren werfen kann und die halt wirklich genau wissen:

Okay, ich kenne die Produkte, ich weiß genau, was das ist. Nur anhand der Artikelnummer. Das erleben wir wirklich häufig, dass es so etwas gibt. Aber für denjenigen ist es mitunter schwierig, ein Datenmodell aufzubauen. Weil wir wollen auch medienneutral vorgehen. Und wir haben im PIM haben wir ein zentrales medienneutrales Datenmodell und versuchen, dieses Datenmodell so ausführlich und so effizient zu gestalten, dass trotzdem alle anderen Ausgabekanäle und auch alle einleitenden Kanäle, wie zum Beispiel das ERP, trotzdem ihre Daten richtig speichern und erhalten können. Und deshalb ist es so eine Art von wir versuchen die Sprache des Product Data Managements zu lernen und andersherum. Dass er halt unsere trockene Datenmodellsprache in dem Rahmen dann halt lernt, zu verstehen. Ja, ganz am Ende wollen wir dann nochmal die allgemeinen Benefits herausstellen für das Projektteam und auch allgemein für das E-Commerce-Projekt.

Denn es wirkt ja erstmal so als wäre das PIM jetzt einfach noch ein weiterer Bestandteil meiner Systemarchitektur. Noch ein System, was erstmal implementiert werden muss. Was dann gewartet werden muss. Wo Nutzer darauf geschult werden muss. Aber eigentlich will ich doch nur ein neues Shop-System mit einer schönen, neuen UX, um wirklich meine Kunden überzeugen zu können. Aber das stimmt halt nicht. Ja, also es geht halt wirklich darum: Wir arbeiten mit dem E-Commerce-Team Hand in Hand. Es gibt zwei Teams, die sitzen bei uns im Büro wirklich einen Gang weiter. Wir kennen uns schon sehr, sehr gut. Und wenn es dort dann Anforderungen gibt, die halt sowohl in Richtung Shop gehen als auch in Richtung PIM, dann haben wir halt wirklich sehr, sehr kurze Laufweg und können uns da entsprechend absprechen. Das heißt nämlich auch, wir können Aufgaben abnehmen, die ursprünglicher Weise auch bei dem E-Commerce-Team lagen. Also das heißt, die Transformation der Daten aus dem ERP, was wir vorhin schonmal aufgezeigt hatten als nicht so ein optimales System, um Produktinformationsdaten zu pflegen bis hin zum Shop. Die übernehmen ja wir. Das heißt, wir behandeln die Produktinformationsdaten in genau der Form vor, wie der Ausgabekanal sie braucht. Das heißt, der Ausgabekanal gibt uns vor: Okay, ich möchte gerne eine XML haben in diesem Schema. Das heißt, wir bereiten die Daten auf, stecken sie in das Schema und geben sie dann häppchenweise weiter. Das heißt, die E-Commerce Entwickler brauchen sich nicht mehr im Datenmappings darum kümmern. Oder auch um noch weitergefasst in der Implementierungsphase. Die E-Commerce Entwickler brauchen nicht Workshops durchführen, die halt sich um die Produktdatenmigration drehen, sondern das machen wir. Und wir haben da halt auch gezielt Wissen aufgebaut. Und das ist unser daily Doing und nicht das Beiwerk einer E-Commerce Entwicklers. Die restlichen zwei Punkte würde ich noch gerne an Tobi übergeben.

Tobias Watermann: Ja, Danke schön. Eigentlich kurz gesagt, wir können mit der Einführung eines PIM-Systems so ein Projekt auch gut verkürzen, beziehungsweise die Timeline auch ein bisschen knackiger machen, weil wir halt schon die anderen Teams mit vorgelagerten Produktinformationen versorgen können. Beziehungsweise die ganze Produktdatenberatung passiert im Vorfeld oder kann im Vorfeld passieren. Und, ja, was auch für uns noch ein ganz wichtiges Ding bei dem ganzen Projekt ist. Wir sind durch den Einsatz eines PIM-Systems sind wir auch flexibel in der Architektur. Das heißt, wir können damit unsere Systemarchitektur immer wieder durch vorhandene Systeme erweitern oder können vorhandene Systeme ersetzen oder gar streichen und können immer noch gewährleisten, dass die Produktinformationen einheitlich gepflegt werden, ausgeleitet werden. Sei es jetzt auch an ein neues System, beispielsweise.

Key Takeaways

Tobias Watermann: Dass wir das nochmal kurz nochmal zusammenfassen. Wir haben das jetzt mal hier in den drei Punkten zusammengefasst. Was wirklich auch nochmal ganz gut zusammenfasst, was wir gerade erzählt haben. Also, dass ein PIM-System nicht nur irgendein zusätzliches System ist, sondern dass das PIM-System uns hilft oder beziehungsweise diesen ganzen Prozess bezüglich E-Commerce-Transformation vereinfacht und wirklich auch beschleunigt. In komplexen IT-System-Landschaften kann sich der Einsatz von einem PIM-System in Kombination mit einer Middle-Wear, also diesem Integration Layer oder Enterprise Service Bot, von dem wir gesprochen hatten. Kann das ganze ergänzen. Und die Synchronisation und die Syndizierung, also die Verteilung der Produktdaten wirklich vereinfachen. Und zum Schluss haben wir noch gesagt, dass ein medienneutrales Datenmodell die Grundvoraussetzung für alle anderen Prozesse, die Produktinformationen behandeln, ja, dass es dafür die Grundvoraussetzung ist. Genau. Und das wären unsere drei Key Takeaways von unserer Vorstellung heute. Und ich glaube, dann hätten wir jetzt noch zum Schluss würde ich dann nochmal an Hanni übergeben, richtig?

Q&A

Hanni Gummel: Ja, sehr gut. Vielen Dank, dass ihr uns jetzt in dem Bereich Product Information Management aufgeschlaut habt. Und wir steigen jetzt in die Fragerunde ein. Ihr habt jetzt die Möglichkeit, eure Fragen an unsere Experten zu stellen. Nutz dafür gerne wieder rechts an dem Bildschirm das rote Webinar Bedienpanel, in der Fragebox, schreibt da eure Fragen rein. Dann können wir diese gleich klären. Und da trudeln auch schon die ersten Fragen rein und ich starte.

Welche Reihenfolge würdet ihr vorschlagen, wenn wir eine PIM-Implementierung haben und eine E-Commerce-Implementierung?

Jacqueline Els: Ja, Hanni, ich würde vielleicht mal darauf eingehen. In einer perfekten Welt, ja, ist es natürlich von Vorteil, wenn ich mir im ersten Schritt Gedanken über meine Produktdaten mache und im zweiten Schritt in einem E-Commerce-Projekt, in einem Shop-Projekt mich darum kümmere, die Produktdaten dem Endkunden sichtbar zu machen, ja. Ich kann im vorgelagerten PIM-Projekt natürlich schon auch Anforderungen aus dem Shop-Projekt reagieren. Aus dem jeweiligen Kanal reagieren. Und kann so die Datenstruktur in PIM schon, ja, darauf abgestimmt zur Verfügung stellen. Da wir aber nicht immer in einer perfekten Welt sind, ist, ich glaube die wichtigere Frage, wenn ein laufendes Shop-Projekt schon oder ein Shop-Projekt schon besteht. Sehr viele unserer Kunden haben bereits Online-Shops, Online-Plattformen, ja. Dass wir uns mit einem guten Austausch im Team, im Entwicklungsteam einfach auch darüber verständigen: Was sind jetzt die Anforderungen und wie kann man darauf reagieren? Es geht beides. In einer perfekten Welt ist natürlich das PIM dasjenige, was vorne stehen sollte.

Hanni Gummel: Vielen Dank. Eine Frage, die sich jetzt hier noch anschließt, ist:

Wie synchronisieren sich denn dann das PIM und das E-Commerce Team während so einer Implementierung?

Jacqueline Els: Wenn wir davon ausgehen, dass beide Gewerke auf unserer Seite sind, auf Seiten diva-e sind, dann ist es schon so, dass wir ein Projektteam sind, ja. Und dass wir uns so organisieren, dass die PIM-Consultants sehr eng mit den Entwicklern, mit den Experten auf Implementierungsseite dann tatsächlich auch austauschen. Sind es zwei unterschiedliche Unternehmen und wir betreuen tatsächlich nur das PIM-Umfeld, dann ist auch hier ein guter, partnerschaftlicher Austausch notwendig, damit wir das gut gemeinsam auf die Straße bekommen.

Hanni Gummel: Wunderbar. Und noch eine Frage.

Ihr habt von ESB gesprochen. Könnt ihr das nochmal ganz kurz erklären?

Tobias Watermann: Ja, das war das Beispiel des Enterprise Service Bus. Also auch quasi in einer Art Middle Wear. Und diese Middle Wear ist eigentlich nur dafür da, um andere Systeme anzuschließen. Weil diese Middle Wear kennt im Prinzip, hat den direkten Kontakt zu den Systemen. Und wir im PIM liefern diese Middle Wear einfach nur mit den nötigen Daten. Das heißt, wir müssen uns an der Stelle gar nicht damit beschäftigen, wie schließe ich System X oder System Y an. Sondern wir wissen ganz genau: Okay, das will System X und System Y. Und wir geben dieser Middle Wear einfach diese Produktdaten über. Und diese Middle Wear beschäftigt sich mit nichts anderem, außer Daten an die entsprechenden Ziele zu geben. Und, ja, im Prinzip die nochmal auszuleiten, zu verteilen. Das verstehen wir unter ESB, beziehungsweise unter einer Middle Wear in Kombination mit einem PIM-System.

Hanni Gummel: Alles klar, vielen Dank. So die nächste Frage. Ihr habt ja unterschiedlichste Datenquellen genannt.

Wie bewerkstelligt ihr die Migration der Daten?

Tobias Watermann: Würde ich auch nochmal darauf antworten. Ja, die Zusammensetzung ist natürlich auch kein Schema F. Das muss man immer schauen, wie wir die ganzen Daten zusammenführen. Aber auch hier schauen wir durch diese ganzen Workshops. Wo sind die Quellen und wie können wir die Quellen am besten anzapfen. Und im besten Fall führen wir über Konsolidierung diese ganzen Datenquellen zusammen und machen das zum Beispiel über diese Urladung, diesen initialen Import, zu einem Gesamtkonzept dann im PIM-System. Und im besten Fall können wir alle Quellen, sei es jetzt Systeme, auch ansprechen und können uns von den Systemen auch die einzelnen Puzzleteile dann automatisiert geben lassen.

Hanni Gummel: Okay. Gut. Dann eine letzte Frage noch zum Thema Datenmodel.

In meinem Magento Shopsystem habe ich schon ein gut funktionierendes Datenmodel. Kann ich das nicht einfach ins PIM übertragen?

Robert Saul: Das ist eine gute Frage. Ja, tatsächlich. Also, es liegt erstmal nahe, natürlich, dass man sagt: „Okay, Magento ist jetzt mein einziger Ausgabekanal aktuell. Da gibt es ja schon alles und ich habe da auch schon ganz viel Hirnschmalz reingesteckt, um halt dieses Datenmodell aufzubauen.“ Aber Magento zum Beispiel in dem Fall ist, so wie ich es kenne, sehr hierarchisch flach. Also ich kenne es so, dass es da nur zwei Hierarchieebenen geben kann. Nämlich Master und Variante. Alles, was dort oben drüber abgebildet wird, wird nicht mehr direkt in der Produktdatenhierarchie abgebildet, sondern müsste dann über Umwege abgebildet werden. Das heißt, wir würden da eventuell Potential verschenken, wenn wir das einfach so übernehmen. Es wäre natürlich möglich. Je nachdem halt, wie die Produktdatenstruktur halt auch aussieht, welche Produkte das sind, die dort angeboten werden. Aber pauschal könnte ich jetzt nicht sagen, dass das eine gute Idee ist. Also, eine gute Idee ist es, auf jeden Fall erstmal das medienneutral abzubilden. Also, das heißt wirklich genau im PIM sich anzuschauen, wie kann ich die Produkte idealerweise hier untereinander abbilden, so dass möglichst viel Produktinformationen, die gleich sind, auf den jeweiligen Parent ausgelagert werden und dann halt zum Beispiel über Vererbung wieder nach unten vererbt werden. Dass ich halt diesem Ziel, die Produktinformationsdatenqualität zu maximieren, dass ich dem mit diesem Ziel halt alleine schon über das Datenmodell sehr nahekomme. Also, grundsätzlich nicht unbedingt, aber es ist möglich.

Hanni Gummel: Gut, sehr gut. Ja, das scheinen jetzt erstmal alle Fragen gewesen zu sein. Vielen Dank euch erstmal. Sollte darüber hinaus noch mehr Bedarf bestehen, dann könnt ihr euch einfach gerne direkt an die Jacqueline oder an den Guido, das ist der verantwortliche Sales Manager hier in dem Punkt, wenden. Sie freuen sich auf eure Fragen und den Austausch mit euch. Und natürlich erhaltet ihr die Aufzeichnung der Präsentation, ja wie schon gesagt, im Nachgang. Und damit sind wir am Ende. Vielen Dank für eure Teilnahme. Ein riesengroßes Dankeschön an Jacqueline, Robert und Tobias heute für eure Zeit und für euren spannenden Input. Und wir würden natürlich uns freuen, wenn ihr uns eine kleine Bewertung da lasst in der Umfrage, die gleich erscheinen wird, damit wir einfach wissen, wie wir uns weiterentwickeln können. Damit, ja, wünschen wir euch einen schönen Tag noch, bis zum nächsten Mal. Ja, alles Gute und bleibt gesund. Bis dann, Tschüss.

Jacqueline Els: Vielen Dank, Tschüss.

Tobias Watermann: Tschüss.