Für E-Commerce-Experten und diejenigen, die an der digitalen Transformation beteiligt sind, ist das Produktinformationsmanagement (PIM) wohl das wichtigste System, das es zu berücksichtigen gilt. Es sorgt für Konsistenz und Qualität über alle Vertriebskanäle hinweg. Wenn Unternehmen die Implementierung eines neuen PIM-Systems in Erwägung ziehen, stellt sich vor allem die Frage, ob eine vollständige Implementierung das Risiko wert ist oder ob eine Proof-of-Concept-Implementierung (POC) der sinnvollere Weg ist.
Bei PIM mag der Verzicht auf den Proof of Concept (POC) als der schnellste Weg erscheinen, um Ressourcen zu sparen, aber er führt wahrscheinlich zu kostspieligen Nacharbeiten, Verzögerungen und überforderten, verärgerten Mitarbeitern. Ein POC ist mehr als nur ein Test; er ist eine strategische Versicherungspolice, die hilft, geschäftliche und technische Fehlentwicklungen zu vermeiden.
In etwa 50 % der Fälle, in denen PIM von großen Unternehmen wie Acer oder Bridgestone (beides unsere Kunden) implementiert wird, wird ein Proof-of-Concept-Projekt (POC) durchgeführt, bevor wir mit der vollständigen AtroPIM-Implementierung beginnen.
Warum sich mit einem POC beschäftigen?
Ein PIM Proof-of-Concept (POC) ist eine kurze, sehr zielgerichtete Initiative, die vor einer größeren Investition bestätigt, dass die ausgewählte Softwareplattform Ihre spezifischen geschäftlichen und technischen Anforderungen erfüllt. Der POC verwandelt das Projekt von einem theoretischen Konzept in eine praktische Realität.
Ein POC sollte unbedingt in Betracht gezogen werden, wenn:
- Planung komplexer Arbeitsabläufe: Ein POC stellt sicher, dass die Plattform einzigartige oder komplizierte Produktdaten-Workflows für Ihr Unternehmen verarbeiten kann (z. B. benutzerdefinierte, mehrschichtige Sprachlokalisierung, dynamische Datenvererbung oder komplizierte Genehmigungsprozesse).
- Bewertung spezifischer Funktionalitäten: Wenn Ihre Anforderungen komplexer, branchenspezifischer oder kundenspezifischer werden (z. B. Taschen mit Geschäftsregeln), ist ein POC entscheidend, um das Risiko einer Inkompatibilität mit der Plattform zu bewerten.
- PIM als strategisches und skalierbares Werkzeug: Wenn PIM als strategisches Tool betrachtet wird, von dem erwartet wird, dass es schnell über verschiedene Marken, Regionen oder Kanäle hinweg eingesetzt werden kann, sollte der POC die Architektur des Systems und die mögliche Leistung und Skalierbarkeit vor einer breiten Einführung validieren.
Zusätzlich zu all den oben beschriebenen komplizierten Elementen wird ein POC in einem wichtigen Fall verpflichtend:
Wenn Sie das Gefühl haben, dass PIM für Sie nicht funktionieren könnte.
Dieses Gefühl kommt normalerweise von:
- keine interne PIM-Erfahrung: Ihre Mitarbeiter sind neu im Bereich PIM und haben die technische Machbarkeit und Nutzbarkeit noch nicht bewertet.
- Zweifel der Hauptinteressenten: Wichtige Geschäftsinhaber, insbesondere im Marketing, in der Produktentwicklung usw., sind nicht davon überzeugt, dass das System ihre Probleme wirklich lösen wird.
Was ist möglich, um an einem PIM POC zu arbeiten?
Ein gezielter POC ermöglicht es Ihrem Team, das System in die Hand zu nehmen und einige kritische Basiselemente mit einem kleinen Teil Ihrer Daten zu validieren.
1. Datenmodell-Flexibilität (fast immer)
Überprüfen Sie, ob das PIM-System Ihre komplizierten Produktstrukturen genau modellieren kann. Dies können Sie tun, indem Sie eine Beispiel-Produkthierarchie erstellen und benutzerdefinierte Attribute und Attributgruppen einrichten. Sie können auch das komplizierte Varianten-/SKU-Management für komplexe Produkte testen, z. B. Bekleidung mit einer Größen-/Farbmatrix.
2. Geschäftsprozessflexibilität und Zugriffsmanagement
Stellen Sie fest, ob das System Ihre spezifischen Arbeitsabläufe zur Erstellung von Inhalten und zur Qualitätskontrolle unterstützen kann. Sie können einen einfachen Datenanreicherungs-Workflow verwenden (z. B. von "Entwurf" zu "Bereit für das Web"), um Benutzerrollen und Berechtigungen sowie definierte Datenqualitätsregeln (z. B. Pflichtfelder für Vollständigkeit) festzulegen.
Implementieren Sie wichtige Benutzerrollen, die Ihre Organisationsstruktur widerspiegeln (z. B. Produktmanager, Inhaltsersteller, Genehmiger, Systemadministrator). Stellen Sie sicher, dass jede Rolle über die entsprechenden Sichtbarkeits- und Bearbeitungsberechtigungen für bestimmte Datenelemente wie Attribute, Kategorien und Kanäle verfügt.
Vergewissern Sie sich, dass das System den Zugriff auf Basis von Teilmengen von Daten einschränken kann. Stellen Sie beispielsweise sicher, dass ein Content Writer für die Region X nur Produkte anzeigen und bearbeiten kann, die der Kategorie X oder der Sprachversion der Daten zugeordnet sind, und testen Sie so die Granularität des Sicherheitsmodells.
3. Systemintegrationsfunktionalität für Daten- und Systemintegration (in seltenen Fällen)
Testen Sie die technische Machbarkeit der PIM-Konnektivität mit anderen wichtigen Unternehmenssystemen. Testen Sie Integration, Latenzzeit und Datenzuordnung. Stellen Sie eine grundlegende, schreibgeschützte API-Verbindung zu einem Stammdaten-ERP-System oder einem Asset-DAM-System her, um zu sehen, ob gehostete Daten sichtbar werden.
Dies ist der am schwierigsten zu überprüfende Aspekt, da Sie die Integration vor dem Testen entwickeln müssen. Folglich würden hier in den meisten Fällen die Kosten anfallen, im Gegensatz zum "normalen" Anwendungsfall, nicht zum "POC"-Fall.
Wann können Sie den POC überspringen?
Unter bestimmten begründeten Umständen kann ein Unternehmen getrost auf einen formalen Proof of Concept (POC) verzichten, insbesondere wenn das Risiko gering ist und eine schnelle, unkomplizierte Implementierung angestrebt wird.
Insbesondere werden POCs oft nicht benötigt, wenn:
- Kleiner Umfang, schrittweiser Rollout: Ihr anfänglicher Rollout ist absichtlich auf eine kleine Anzahl von SKUs, ein paar Kernattribute und einen einzigen, nicht kritischen Kanal (z. B. eine einfache E-Commerce-Website) beschränkt. Sie planen, die Funktionalität in späteren Phasen zu erweitern.
- Industrieweit anerkannte Standardlösung: Sie haben sich für ein PIM-System entschieden, das sich in Ihrer Branche als führend erwiesen hat und über öffentlich dokumentierte Standardintegrationen für alle gängigen Systeme in Ihrem Tech-Stack verfügt (z. B. Konnektoren für wichtige ERP-Systeme oder E-Commerce-Plattformen).
- Geschäftsprozess-Fokus: Sie haben festgestellt, dass die Hauptherausforderung in der Definition und Vereinbarung Ihrer Produktdatenanforderungen (ein Geschäftsproblem) liegt und nicht in der technischen Fähigkeit oder Machbarkeit der PIM-Software selbst.
- Hohes internes Fachwissen: Ihr Team hat bereits Erfahrung mit der erfolgreichen Implementierung der spezifischen PIM-Plattform, die Sie in Betracht ziehen, was Ihrem Unternehmen ein hohes Maß an internem Fachwissen und Vertrauen in die Plattform verleiht.
- Vereinfachtes Datenmodell: Ihre Produktdatenstruktur ist von Natur aus flach, einfach und nicht variantenbasiert und erfordert nur minimale Anpassungen an das Standarddatenmodell des PIM.
- Open-Source mit Entwicklerunterstützung: Sie setzen eine hochaktive Open-Source-PIM-Plattform ein und verfügen über ein starkes internes Entwicklerteam, das mit der direkten Anpassung der Plattform und der Fehlerbehebung vertraut ist, was die Abhängigkeit von den bewährten Methoden der Anbieter verringert.
In diesen Fällen ist es sinnvoller, sich auf die Dokumentation Ihrer Anforderungen zu konzentrieren und eine kleine Pilotimplementierung zu starten, als einen formellen, eigenständigen POC zu erstellen.
Es gibt eine Brücke zwischen PIM-Implementierung und Kundenerfahrung. Ein POC ist ein technischer Stresstest, der sicherstellt, dass die Brücke nicht unter dem Druck der Geschäftsanforderungen zusammenbricht.