Pimcore-Implementierung: So klappt die Einführung reibungslos

Von der Strategie bis zur Nutzerakzeptanz: Wie du die Implementierung von Pimcore als PIM, DAM und DXP erfolgreich implementierst

Pimcore-Implementierung
Inhalt
  1. Die 6 kritischen Implementierungspunkte
  2. 1. Die Strategie: W-Fragen beantworten
  3. 2. Das Datenmodell: Der Schlüssel zur Langlebigkeit
  4. 3. Die Prozesse: Pimcore ist Diener des Business
  5. 4. Die Schnittstellen: Datensilos geht es an den Kragen
  6. 5. Die Nutzer*innen: ohne Akzeptanz kein Erfolg
  7. 6. Die Migration: Aus alt mach neu
  8. Fazit: Schrittweise Implementierung statt „Big Bang“
Du evaluierst Pimcore oder stehst kurz vor der Implementierung? Dann weißt du vermutlich schon: Pimcore ist eine der vielseitigsten Lösungen am Markt, mit einem breiten Anwendungsspektrum. Die Software, lässt sich grob in zwei Bereiche einteilen: Zum einen das Datenmanagement für Produktdaten (PIM), digitale Medien und Assets (DAM), Kundendaten (CDP) und jede andere Art von Daten (MDM für Master Data Management). Zum anderen die Realisation von digitalen Touchpoints, egal ob Websites, Portale, E-Commerce-getriebene Anwendungen oder Produktkonfiguratoren. 
Dieser Funktionsumfang, gepaart mit extrem hoher Erweiterungsfähigkeit, macht Pimcore zu einem Alleskönner auch für sehr komplexe Anwendungsfälle. Aber auch zur Stolperfalle. Viele Möglichkeiten erfordern speziell bei der Implementierung ein strukturiertes Vorgehen. Gemeinsam mit den Pimcore-Expert*innen von Arrabiata beleuchten wir in diesem Implementierungsguide die erfolgskritischen Punkte: von der Strategie über Datenmodell, Prozesse und Schnittstellen bis zur Nutzerakzeptanz. 

Das Wichtigste in Kürze

  • Pimcore ist eine hochflexible All-in-One-Plattform für Datenmanagement (PIM, DAM, MDM, CDP) und digitale Touchpoints – erfordert aber eine klare Strategie und strukturiertes Vorgehen.
  • Der Erfolg der Implementierung beginnt mit den W-Fragen zu Zielbild, Rollen, Beteiligten, Roadmap und Migrationsstrategie.
  • Ein durchdachtes, zukunftsfähiges Datenmodell ist der zentrale Hebel für Skalierbarkeit, Effizienz und langfristige Wartbarkeit.
  • Sauber definierte Prozesse, klare Schnittstellen und eine konsequente „Single Source of Truth“ verhindern Datensilos und schaffen einen belastbaren Golden Record.
  • Nutzerakzeptanz, schrittweise Einführung und ein professionelles Migrationskonzept sind entscheidend, um Risiken eines „Big Bang“ zu vermeiden.
Implementierungsguide
Dein Onboarding in Bestzeit: Mit unserem „Implementierungsguide“ erhältst du die wichtigsten Insights von Expert*innen. Wir zeigen die entscheidenden Schritte, um dein System in Bestzeit live zu schalten.

Die 6 kritischen Implementierungspunkte

Der Start in ein Projekt mit einer neuen Softwarelösung ist oft mit viel Energie, Hoffnungen und Erwartungen verbunden. Das ist gut so, denn eine moderne Software wie Pimcore hat tatsächlich das Potential, ein Unternehmen voranzubringen und schon lange bestehende Problematiken in der Datenverwaltung und der Websteuerung zu lösen. 
Damit die Energie nicht erlahmt und die Erwartungen auch wirklich erfüllt werden, ist es bei der Implementierung allerdings entscheidend, strategisch und strukturiert vorzugehen und einige Fallstricke zu beachten. Hierfür liefert dieser Implementierungsguide die sechs wichtigsten, kritischen Punkte.  

1. Die Strategie: W-Fragen beantworten

Bei der Einführung von Pimcore spielt die Strategie eine zentrale Rolle. Das klingt erstmal kompliziert und nach umfangreichen Workshops. In der Praxis hilft allerdings schon eine einfache Methode, die aus dem Journalismus bekannt ist: Stelle dir die grundlegenden W-Fragen: Warum führt dein Unternehmen Pimcore ein, was wollt ihr erreichen, welche Rolle soll Pimcore spielen und wer ist daran beteiligt? 

Warum Pimcore einführen?

Die erste Frage enthält die zentralen strategischen Gedanken. Was ist der Zweck und welche Ziele verfolgen wir. Die Spannbreite kann groß sein, in der Praxis sind sehr häufig die Themen Datenverwaltung, Aggregation und Ausspielen von Daten sowie der Bau von beliebigen Customer-Touchpoints zu finden. 
Hier ein paar Beispiele aus der Praxis:
  • Die Datenverwaltung soll auf das nächste Level gehoben werden.
  • Die Bearbeitung von Produkt- und anderen Marketing-relevanten Daten soll vereinheitlicht werden.
  • Datensilos wie alte Excel-Dateien und Co. sollen abgelöst werden. 
  • Daten sollen für verschiedene Marketingkanäle von E-Commerce-Marktplätzen, Social Media, Web-Touchpoints bis KI-Applikation vorbereitet und ausgespielt werden. 
  • Eine Vielzahl an digitalen Anwendungen, Websites, Portalen, Konfiguratoren etc. soll einheitlich verwaltet und gesteuert und zum digitalen Ökosystem ausgebaut werden.
Der wichtigste Rat ist: Formuliere den Zweck und die dahinter stehenden Ziele explizit. Je genauer die Vorstellung davon ist, was die Einführung von Pimcore erreichen soll, desto erfolgreicher wird das Einführungsprojekt verlaufen.

Welche Rolle(n) soll Pimcore spielen?

Aus dem Zweck ergibt sich auch, welche Rolle Pimcore eigentlich spielen soll. Pimcore ist viel mehr als nur ein Product Information Management, das Produktdaten aggregiert, anreichert und dann z.B. in Kataloge verwandelt. 
Pimcore enthält ein vollwertiges CMS (Content Management System), ein E-Commerce-Framework, ein MDM (Master Data Management) für alle Arten von Daten und ein DAM (Digital Asset Management) zur Verwaltung von Bildern und Medien. Die Verbindung aus Datenspezialist und Experience-Plattform, mit der sich digitale Touchpoints realisieren lassen, ist die eigentliche Besonderheit von Pimcore. 
Du kannst all diese Fähigkeiten in einer integrierten Software nutzen, musst es aber nicht. Eine Möglichkeit ist es auch, schrittweise vorzugehen: So kannst du mit den PIM-Fähigkeiten starten und anschließend nach und nach digitale Portale oder E-Commerce-Sites ergänzen.
Grafiken für Artikel-03.png
Die Fähigkeiten von Pimcore im offiziellen Überblick

Wer ist beteiligt?

Die dritte W-Frage führt uns zu den Beteiligten: Damit sind Stakeholder*innen im Unternehmen gemeint, also Abteilungen wie Produktmanagement, Marketing und Vertrieb, aber auch Zielgruppen für deine Informationen, z.B. Kundengruppen oder Händler. Und auch die technischen Akteure sind zu beachten: Mit welchen Systemen muss Pimcore verknüpft werden, um eine optimale Systemarchitektur zu gewährleisten?
Außerdem ist hier das Kernteam zur Einführung des Systems zu definieren. Das geht los mit dem oder den Hauptverantwortlichen – je nach Projektmanagement-Ansatz Product Owner oder Projektmanager*in. Aber auch aus den zentralen Abteilungen kommen oft Beteiligte, die zum Kernteam der Einführung gehören. 
Neben diesen internen Projektbeteiligten gibt es zusätzlich externe Beteiligte. Da ist zum einen Pimcore selbst, das Softwarelizenz und auf Wunsch auch ein PaaS-Betriebsmodell bereitstellt. Bei der Einführung kommt dann meist ein auf Pimcore spezialisierter Dienstleister mit an Bord. Pimcore selbst zertifiziert dazu so genannte Solution Partner, die sich auf Pimcore spezialisiert haben. 
Hier ist es wichtig, frühzeitig in der Strategie zu entscheiden, welche Aufgaben du einem Pimcore-Dienstleister überlassen und welche du intern abdecken möchtest. Möglich sind hier alle Varianten von komplettem Outsourcing bis zu einer (fast) eigenständigen Implementierung. In der Praxis am häufigsten ist ein kooperatives Modell, in dem einerseits Systemwissen innerhalb des Unternehmens aufgebaut wird, andererseits ein Pimcore-Dienstleister als Beschleuniger und für Entwicklungs- und Supportleistungen genutzt wird. 
Ebenfalls nicht vergessen werden sollten externe Dienstleister anderer Systeme, die wiederum mit Pimcore verknüpft werden sollen. In der Praxis sorgen oft mangelnde Ressourcen, z.B. seitens des ERP-Systemanbieters, für eine Verzögerung in einem klassischen PIM-Projekt. 
Tobias Hauser_Zitat

„Ein mächtiges Werkzeug wie Pimcore entfaltet seine volle Kraft erst dann, wenn die Business-Ziele präzise definiert sind – Technik folgt immer der Strategie.“

- Tobias Hauser, Geschäftsführer bei Arrabiata Solutions GmbH

Wie soll die Implementierung erfolgen?

Je mehr Funktionen das System im Unternehmen ausfüllen soll, desto komplexer wird natürlich auch das Einführungsprojekt. Hier macht es der Erfahrung nach viel Sinn, die Implementierung in Meilensteine zu unterteilen und Komponente für Komponente einzuführen. 
Mit der Wahl des Projektmanagement-Ansatzes wird ebenfalls das „Wie“ gesteuert: In einem agilen Projekt denkt man üblicherweise strikt aus Sicht eines MVP (Minimal Viable Product, ein gerade noch lebensfähiges Produkt). Das könnte z.B. heißen, dass im ersten Schritt das Datenmodell, ein Import und ein erster Touchpoint realisiert wird, aber nicht mehr. Beschränkung auf das Wesentliche ist allerdings auch bei anderen Projektmanagement-Methoden, wie z.B. dem klassischen Wasserfall, sinnvoll.
Bei sehr umfangreichen Projekten kann es bei der Pimcore-Einführung anfangs sinnvoll sein, zuerst auf einen so genannten Proof of Concept (POC) zu setzen. Dabei ist noch kein lauffähiges Produkt wie beim MVP angestrebt, sondern nur ein Beweis, dass Pimcore die richtige Lösung ist. Gründe für einen POC vor dem eigentlichen Implementierungsprojekt können neben der Komplexität z.B. auch hohe Performance-Anforderungen oder sehr spezielle Schnittstellen sein, von denen das Projekt in hohem Maße abhängt. 
Ein Tipp zum Thema POC wird anhand eines Beispiels verständlich: Stell dir eine Gruppe mit fünf Projektbeteiligten des Kernteams vor, drei davon intern, zwei extern, z.B. vom Pimcore-Dienstleister. Nun wirf in den Raum, dass ihr unbedingt einen POC machen wollt, um sicherzustellen, dass die Pimcore-Einführung auch funktioniert. Wenn du jetzt alle Beteiligten aufforderst, den POC still, also unabhängig von den anderen, zu definieren, wie viele deutlich voneinander abweichende Ergebnisse wirst du bekommen? Je nach Gruppe liegt die Antwort üblicherweise irgendwo zwischen drei und fünf. 
Das heißt, der Begriff POC ist sehr unzureichend definiert. Beispielsweise kann er sich auf ein oder zwei sehr kritische Funktionalitäten beschränken. Oder er bildet eine komplette Prozesskette vom Import über die Datenverarbeitung bis zur Ausgabe im Touchpoint ab, nur in stark reduzierter Form. Die folgenden Fragen könnten bei der Eingrenzung helfen:
  • Was soll der POC beweisen? 
  • Welche Funktionalitäten oder Schnittstellen sind so kritisch, dass sie für einen Misserfolg im Implementierungsprojekt sorgen können?
  • Wo liegen die größten Risiken im Projekt (z. B. Datenmenge, Schnittstellen, Importe oder Touchpoints)?
  • Wie zuversichtlich ist das Projektteam bezüglich des Projekterfolgs? 
Je zuversichtlicher das Team ist, desto wichtiger ist es, dass der POC so durchgeführt wird, dass die Arbeiten auch im weiteren Projekt genutzt werden können. Bei geringerer Zuversicht ist es dagegen entscheidender, die Machbarkeit zu beweisen, auch auf die Gefahr hin, dass die eigentliche Implementierung später deutlich vom POC abweichen kann.

Wann sollte Pimcore implementiert werden?

Die fünfte W-Frage gießt die Antworten auf die ersten vier W-Fragen in einen Zeitstrahl. Hier entsteht die Roadmap des Implementierungsprojekts: 
  • Die Umsetzung des Datenmodells
  • Die Abbildung der benötigten Prozesse
  • Die Realisierung der Schnittstellen für den Im- und Export
  • Die Touchpoints, also Websites, E-Commerce-Lösungen, Portale, Produktkonfiguratoren, Datenblätter, Kataloge etc.
Je nach „Wie“ – also abhängig vom Implementierungsansatz und von der Projektmanagementmethode –  erfolgt die Planung der Roadmap u.a. in Meilensteinen oder Sprints. Zu beachten ist auch hier: Nimm dir für die erste Projektphase einen Ausschnitt vor, der nicht zu umfangreich ist. Gleichzeitig solltest du allerdings schon das große Ganze im Kopf haben, denn vor allem beim Datenmodell ist es von Anfang an wichtig, die richtigen Entscheidungen zu treffen. 

Unser Pimcore-Profi
Tobias Hauser ist Geschäftsführer der Arrabiata Solutions GmbH und gilt als einer der profiliertesten Experten für Pimcore im deutschsprachigen Raum. Als Berater begleitet er mittelständische und große Unternehmen seit Jahren durch den gesamten Lebenszyklus komplexer Pimcore-Projekte – von der initialen Implementierung über die Architekturberatung bis hin zur laufenden Optimierung. Unter seiner Leitung hat sich Arrabiata Solutions bereits 2019 als Pimcore Platinum Partner etabliert.

 
 

2. Das Datenmodell: Der Schlüssel zur Langlebigkeit

Egal, ob du Pimcore „nur“ zur Datenverwaltung oder auch für deine digitalen Touchpoints einsetzen möchtest, der Schlüssel zum Erfolg ist das Datenmodell. Ein Datenmodell besteht aus Datenobjekten, beispielsweise den Produkten oder Assets und ihren Attributen. Diese Datenobjekte stehen untereinander in Beziehung und sind damit über Relationen verknüpfbar. 
Im Gegensatz zu klassischen PIM- und DAM-Systemen gibt Pimcore dabei keine feste Struktur vor, sondern erlaubt die Abbildung von beliebigen Branchen- und unternehmensspezifischen Datenmodellen. Pimcore ist nicht beschränkt auf die Verwaltung von Produkt- und Assetdaten, sondern kann beliebige andere Datenobjekte verwalten, z.B. Events, Marketinginhalte, Kundendaten, Bestellungen und vieles mehr. Für verschiedene Arten von Daten bietet Pimcore darüber hinaus spezielle Funktionalitäten, wie
  • für Produktdaten im Rahmen des PIMs die Verwaltung von Klassifizierungssystemen nach internationalen Standards wie ETIM, eCl@ss, GS1 und UNSPSC
  • für Assets ein umfangreiches Metadatensystem zur Anreicherung und Verwaltung von Produkten
  • für Kundendaten eine Customer Data Platform zur Modellierung von z.B. personalisierten Kundeninformationen

Konzeption

Für die Implementierung bedeuten diese umfangreichen Möglichkeiten, dass du dich in der Konzeptionsphase zuerst damit beschäftigen musst, welche Datenobjekte in Pimcore abgebildet werden sollen. Anschließend legst du fest, welche Beziehungen zwischen den Datenobjekten bestehen. 
Bei Produktdaten ist in der Praxis die wichtigste Frage, welche Hierarchiestruktur du wählst: Pimcore macht auch hier keine Vorgaben, bietet allerdings sehr spannende Möglichkeiten. Wenn du beispielsweise Produktkategorien bildest, kannst du dort zentral Marketingwerte pflegen und diese an die darunter liegenden Produkte vererben. Auch Produktbeschreibungen lassen sich so auf Produktebene pflegen und dann z.B. auf Farb- oder Materialvarianten vererben. Häufig vorkommende und komplexere Eigenschaften, z.B. Materialbeschreibungen, lassen sich auch als eigene Datenobjekte modellieren und komfortabel mit den Produkt-Datenobjekten verknüpfen. 
Tipp: Um einen Eindruck von der Abbildung des Datenmodells zu gewinnen , lohnt ein Blick in die offizielle Pimcore-Standarddemo. Sie dreht sich rund um das Thema Oldtimer. Auf der obersten Ebene der Produktkategorien sind die Automarken wie Porsche, dann folgen die Typen wie z.B. der 911, anschließend die verschiedenen Varianten wie Coupe oder Targa. Erst darunter sind die eigentlichen Artikel, nämlich ein grünes oder rotes 911er Coupe. Die entsprechenden Produkt- und Marketinginformationen werden so weit oben in der Hierarchie wie möglich gepflegt und dann herunter vererbt. 
Wichtige bzw. komplexe Attribute wie die Autoklasse, der Hersteller und auch die Karosserieform sind eigene Datenobjekte, die mit dem Produktdatensatz verknüpft werden. Pimcore zeigt das mit einem roten Zielkreuz. Diese Art des Aufbaus erfüllt zwei Zwecke: Zum einen wird der Pflegeaufwand minimiert, zum anderen erlaubt der flexible Aufbau, die Daten in jeder erdenklichen Form zu filtern und z.B. in digitalen Touchpoints auszugeben.

Umsetzung

Die Datenobjekte, und damit das vollständige Datenmodell, lassen sich über die visuelle Oberfläche des Pimcore-Backends komfortabel erstellen und bearbeiten. Bei der Ersterstellung bist du sehr frei, sobald das Datenmodell im Einsatz ist, sollten Änderungen allerdings nur noch vorsichtig und mit dem nötigen Hintergrundwissen durchgeführt werden. So gehen bei der Änderung des Datenmodells keine Informationen verloren. Hier solltest du die Rechte zur Änderung des Datenmodells in Pimcore nur an entsprechend qualifizierte Nutzer*innen vergeben. 
Unter der Haube werden aus den Datenobjekten in Pimcore Dateien, die in der Programmiersprache von Pimcore, PHP, erstellt sind. Sie enthalten die Datenobjekte als programmierte Klassen. Pimcore erstellt dann automatisch die Programmstrukturen. In größeren Projekten ist es auch empfehlenswert, das Datenmodell direkt in solchen PHP-Klassen zu erstellen, in diesem Fall sind allerdings Programmierkenntnisse erforderlich. 
Abbildung_Datenobjekte.png
Die Struktur von Datenobjekten lässt sich in der Pimcore-Oberfläche direkt bearbeiten
 
 

3. Die Prozesse: Pimcore ist Diener des Business

Die größte Stärke von Pimcore ist Flexibilität. Um diese Stärke zu nutzen, ist zweierlei wichtig: Du solltest die bestehenden Prozesse kennen und die einmalige Chance nutzen, die Prozesse durch die Einführung des neuen Systems sinnvoll anzupassen. 

Konzeption

In der Konzeption ist der erste Schritt, alle IST-Prozesse zu definieren, die für den Datenfluss notwendig sind. Der nächste Schritt ist, davon die SOLL-Prozesse abzuleiten. Als Methode hat sich in Pimcore-Projekten tatsächlich der klassische Standard BPMN (Business Process Model and Notation) bewährt. Hier hast du den Vorteil, dass eine Großzahl an Softwarelösungen zur Erfassung zur Verfügung steht und auch Projektteilnehmende aus verschiedenen Unternehmen sich auf eine „Sprache“ einigen können. 
Grafiken für Artikel.png
Ein BPMN-basierter Prozess

Umsetzung

Aus Pimcore-Sicht lassen sich Prozesse üblicherweise in drei Teile aufteilen:
  1. Import von Daten, Assets etc. aus externen Quellen
  2. Workflows innerhalb von Pimcore zur Bearbeitung von Daten, Inhalten und Assets
  3. Export von Daten über den Datahub 
Ein Business-Prozess kann dabei natürlich auch zwei oder alle drei Teile umfassen. 
Gerade bei internen Prozessen zur Bearbeitung von Daten etc. spielt das Workflow Management von Pimcore seine Stärken aus. Es basiert grundlegend auf den Workflow-Komponenten des darunter liegenden PHP-Frameworks Symfony. Das heißt, es kann sowohl per Programmierung genutzt werden als auch per Backend-Oberfläche. 
Hiermit sind auch komplexe Workflows möglich. Beispielsweise könnte ein neues Produkt nach dem Einkauf bzw. der Produktion zuerst überprüft werden, anschließend landet es beim Fotografen und parallel entsteht die Produktbeschreibung. Erst wenn beides vorhanden ist, landet das Produkt in der Marketingabteilung, wo die Beschreibung der wichtigsten Verkaufsargumente ergänzt wird. Diese Funktionalitäten lassen sich mit der Rechtesteuerung von Pimcore verbinden, so dass die Bearbeitenden nur die Informationen sehen, die sie benötigen. Daneben bietet Pimcore mit den Workflows auch ein Status-Management, Benachrichtigungsfunktionen und eine Historie. Die damit gebauten Prozesse lassen sich sogar in einer Prozessansicht grafisch darstellen. 
 
 

4. Die Schnittstellen: Datensilos geht es an den Kragen

Eine der großen Stärken von Pimcore ist es, Datensilos im Unternehmen aufzulösen. Für die Implementierung solltest du dich dementsprechend auf die Suche machen nach Excel-basierten Produktlisten, Webanwendungen ohne Anbindung an die zentrale Datenhaltung und schlecht erweiterbaren ERP-Systemen
Sind die Silos identifiziert, wird entschieden, ob die darin enthaltenen Daten in Pimcore gespeichert und die ursprüngliche Datenquelle ersetzt werden soll oder, ob eine Schnittstelle zu den Daten mehr Sinn ergibt. Für diese Entscheidung ziehst du am besten grundlegende Prinzipien des Datenmanagements zu Rate: Frage dich, wo der sinnvolle Ursprung von Daten ist, das heißt der Ort, an dem sie ursprünglich erstellt und bearbeitet werden. Anschließend musst du dich fragen, welches das System sein soll, an dem bestimmte Datenobjekte zentral abgerufen werden. Der Begriff dafür ist die „Single Source of Truth“. 

Schauen wir uns als Beispiel das Thema Produktdaten an: 

Bei einem Excel Sheet, das in Produktentwicklung und -management verwendet wird, um Produktattribute zu pflegen, lautet die Antwort wahrscheinlich, dass die Integration in Pimcore Sinn macht, denn das PIM sollte hier für alle produktrelevanten Daten die „Single Source of Truth“ sein und die Bearbeitung von Produktattributen sollte ebenfalls im PIM erfolgen. Hier ist also keine Schnittstelle notwendig, sondern das alte Excel wird abgelöst.
Einige Produktdaten wie z.B. die SKUs, also eindeutige Produktkennungen, und auch die Preise könnten im ERP-System verwaltet sein. Hier würde man dementsprechend SKUs und Preise über eine Schnittstelle in das PIM übertragen, die Bearbeitung aber dem ERP-System überlassen. In dem Fall ist das ERP-System die „Single Source of Truth“ für SKUs und Preise, Pimcore wiederum sammelt diese Daten und ergänzt die im PIM gepflegten Produktattribute. Die Daten aus dem ERP werden also im PIM angereichert. In Pimcore entsteht damit ein so genannter Golden Record. Dieser Begriff bezeichnet einen vollständigen und qualitativ hochwertigen Datensatz des gesamten Produktes inklusive aller Attribute, der SKUs und der Preise. Pimcore wäre damit für diesen vollständigen Produktdatensatz selbst die „Single Source of Truth“.
Eine Webanwendung, die bisher noch nicht mit einem PIM verbunden war, hat noch keinen automatisierten Zugriff auf eine „Single Source of Truth“ für Produktdaten. Die Konsequenz daraus ist, dass die Daten doppelt bzw. manuell gepflegt werden. In diesem Fall macht es Sinn, die Webanwendung per Schnittstelle direkt an Pimcore anzudocken oder alternativ sie direkt mit dem DXP von Pimcore zu realisieren. 

Tipps zur Konzeption

In der Konzeption von Schnittstellen helfen klassische Architekturschaubilder, die die beteiligten Systeme und Datenflüsse zeigen. Für die einzelnen Schnittstellen sind einfache Schnittstellensteckbriefe empfehlenswert. Auch hier helfen einfache W-Fragen:
  • Welche Daten werden ausgetauscht? Z.B. der Lagerbestand von Produkten.
  • Welche Systeme sind beteiligt? Z.B. die Lagerverwaltungssoftware und Pimcore.
  • Wie oft werden die Daten übermittelt? Z.B. stündlich.
  • Wer ruft die Daten ab? Z.B. ruft Pimcore eine von der Lagerverwaltung bereitgestellte API ab.
  • Welche Schnittstellentechnologie kommt zum Einsatz? Z.B. der Abruf einer REST-basierten API. 
  • Wie wird die Kommunikation abgesichert? Z.B. über SSL und Secret.

Welche Schnittstellentechnologie?

Bei der Wahl der Schnittstellentechnologie erlaubt Pimcore viele Freiheiten. Darunter beispielsweise Data Importer, die CSV, Excel (xlsx), XML-Formate und JSON importieren und über ein Mapping in Pimcore-interne Datenobjekte verwandelt werden können. 
Basis für den Import von Daten, aber auch für die Weitergabe von Daten in Pimcore, ist standardmäßig der Pimcore Datahub. Er bietet eine einfache REST-Schnittstelle, aber auch eine über die Pimcore-Oberfläche sehr frei konfigurierbare GraphQL-Schnittstelle. Hiermit ist es auch ohne Programmierung möglich, alle in Pimcore bereitgestellten Daten über moderne Schnittstellen bereitzustellen – ein echter API-first-Ansatz
Wenn dies für komplexe Anwendungsfälle nicht ausreicht, bietet Pimcore eine flexible Erweiterungsarchitektur, mit der PHP-basiert jede Art von Schnittstellen realisiert werden kann. Auch ETL-Tools zur Datentransformation und Workflow-Funktionen sind in Pimcore direkt integriert. 
Grafiken für Artikel-02.png
Einfache Architekturdarstellung
Tobias Hauser_Zitat

„Die beste Software scheitert, wenn sie am Arbeitsalltag vorbeigeht – echte Akzeptanz entsteht durch frühes Zuhören und die konsequente Einbindung der Anwender*innen.“

- Tobias Hauser, Geschäftsführer bei Arrabiata Solutions GmbH

 
 

5. Die Nutzer*innen: ohne Akzeptanz kein Erfolg

Die Erfahrung zeigt: Die Implementierung eines Systems wie Pimcore kann noch so gut gemacht sein, wenn die Nutzer*innen nicht überzeugt sind, wird die Einführung kein Erfolg. Diese Nutzerorientierung startet idealerweise schon im Projektmanagement bei der Konzeption, indem Beteiligte frühzeitig eingebunden werden. Vor allem redaktionell tätige Mitarbeitende sollten bei der Prozesserfassung mit einbezogen werden. 
Der nächste Schritt in der Umsetzung ist, die Pimcore-Oberfläche soweit anzupassen, dass sie optimal aufgebaut ist. Der erste Schritt hierzu ist, die notwendigen Bearbeitungsrollen zu identifizieren und die Rechte für diese Rollen anzupassen. Pimcore bietet allerdings noch wesentlich mehr Möglichkeiten: Das Backend ist modular aufgebaut und – sollte es wirklich notwendig sein – auch stark anpassbar. Und selbstverständlich kann auch das Workflow Management zur Optimierung der Arbeitsprozesse genutzt werden.
Das dritte Element für hohe Akzeptanz bei einer Pimcore-Einführung ist, die zukünftigen Nutzer*innen zu schulen und mit dem notwendigen Wissen zu versorgen. Bei größeren Teams bietet es sich an, Key User zu bestimmen, diese zu schulen und auf interne Wissensweitergabe zu setzen. 
Abbildung_Nutzersicht.png
Eine reduzierte Ansicht für Nutzer*innen
 
 

6. Die Migration: Aus alt mach neu

Falls dein Unternehmen gerade noch kein Vorgängersystem hat, das abgelöst werden muss, herzlichen Glückwunsch, das macht das Implementierungsprojekt deutlich leichter. Allerdings eignet sich Pimcore auch sehr gut dazu, bereits etablierte „Legacy“-Software abzulösen. Das heißt, dort existieren bereits etablierte Prozesse und Datenstrukturen. Unabhängig davon, welche Ziele du mit Pimcore verfolgst, erfordert eine erfolgreiche Migration mehr als den reinen Systemwechsel: Bestehende Businesslogik, gewachsene Prozesse und relevante Daten aus einem oder mehreren Bestandssystemen müssen konsistent in die neue Struktur überführt werden. Schauen wir uns dementsprechend unsere ersten fünf wichtigen Punkte aus dem Implementierungsguide nochmal mit Bezug auf das Thema Migration an. 

1. Strategie und Migration

Bei der Strategie sind zwei Fragen entscheidend: Benötigt ihr die meisten oder alle Funktionen aus dem Altsystem und müsst ihr die Anwendung vollständig zu einem bestimmten Stichtag umziehen? Dieser „Big-Bang“ hat wie der Name schon andeutet durchaus die Gefahr einer Explosion. Dementsprechend ist es dann wichtig, Testphasen einzubauen und sich strategisch nicht in eine gefährliche Lage zu bringen, in dem das Altsystem z.B. schon zu einem Stichtag gekündigt ist. 
Eine schrittweise Migration ist dem gegenüber risikoärmer, erfordert allerdings für eine bestimmte Zeit den Parallelbetrieb von Alt- und Neusystem mit den entsprechenden Kosten und auch internen Aufwänden. Hier ist es umgekehrt sehr wichtig, diese Parallelphase möglichst kurz zu halten, da das „Legacy“-System sonst über Monate oder Jahre mitgeschleppt wird. Der häufigste Fehler ist hier, dass mit dem neuen System schon neue Funktionalitäten realisiert werden, wodurch dann Kapazität gebunden ist, die eigentlich noch für die finalen Migrationsschritte vom Altsystem notwendig wären. 
Insgesamt lässt sich sagen, gerade im Projektmanagement ist die Gefahr, bei der Migration zu viel zu wollen. Das Altsystem ist zwar meist nicht mehr beliebt und jeder möchte es loswerden, aber es ist oft auch über Jahre aufgebaut und funktional erweitert worden. Gehe hier die Funktionsliste kritisch durch und streiche alles, was nicht unbedingt gebraucht wird. Das erhöht die Chancen einer erfolgreichen Implementierung immens. 

2. Datenmodell, Daten und Migration

Die Migration von Daten ist einer der Knackpunkte, denn Daten lassen sich nicht beliebig anpassen oder verändern. Sowohl die Inhalte als auch die Beziehungen zwischen den einzelnen Datenobjekten müssen beim Umzug aus fachlicher Sicht vollständig erhalten bleiben, um Konsistenz, Nachvollziehbarkeit und Vertrauen in das neue System sicherzustellen. Gleichzeitig macht es aber oft Sinn, das Datenmodell zu modernisieren. 
Aber nicht nur die Struktur der Daten ist eine Herausforderung. In der Regel ist auch die Datenmenge zu groß, um sie einfach per Copy & Paste zwischen den Systemen zu übertragen. Außerdem bringen Stamm- und Bewegungsdaten eigene Herausforderungen mit sich: Während der Implementierung des neuen Systems verändern sich Daten im Bestandssystem oder es entstehen neue. Das heißt, die Daten können nicht zeitversetzt migriert werden, sondern müssen am Stichtag automatisiert übermittelt werden. 
Was also tun? Es braucht ein Migrationskonzept. Grundlage dafür ist ein fachlich definiertes SOLL-Datenmodell. Dieses entspricht einem idealen Entwurf, der unabhängig von den Einschränkungen der aktuellen Systeme erstellt wird. Für die erfolgreiche Migration ist außerdem das Datenmodell aus IST-Perspektive notwendig. Meistens sind die beiden nicht identisch und das Migrationskonzept legt fest, wie die Daten transformiert werden. 
Techniker*innen denken an dieser Stelle häufig reflexartig an ETL-Prozesse (Extract, Transform, Load) und Migrationsskripte. Zunächst ist jedoch eine grundlegende Entscheidung zu treffen: Reicht ein einmaliger initialer Datenimport aus, oder verändern sich die Daten während der Entwicklungsphase so, dass zum Rollout eine erneute Erstbefüllung mit den dann gültigen Daten erforderlich ist? Oder ist die Situation noch komplexer, weil die im Rahmen der Erstbefüllung importierten Daten während der Entwicklung weiterbearbeitet werden müssen, während sich dieselben Daten parallel in den Altsystemen verändern?
Wenn du diese Fragen geklärt hast, kann die technische Umsetzung geplant werden. In vielen Fällen ist die Erstellung eines temporären ETL- bzw. Migrationsskripts ausreichend, das einmalig ausgeführt wird. In komplexeren Szenarien bietet sich ein zusätzlicher Delta-Export bzw. -Import an, der zum Rollout angestoßen wird und zwischenzeitlich entstandene Änderungen berücksichtigt. In sehr komplexen Fällen kann schließlich eine temporäre Middleware eingesetzt werden, die Änderungen aus dem Bestandssystem live in das neue System überträgt. In all diesen Fällen unterstützt Pimcore mit dem hochgradig flexiblen Datenmodell, den integrierten Importern und dem eigenen Datahub. 

3. Prozesse und Migration

Ähnlich wie bei den Daten ist eine IST- und SOLL-Analyse in der Migration von Prozessen der richtige Weg. Das angenehme ist, wenn die SOLL-Prozesse entstanden sind, kannst Du Dich auf deren Umsetzung konzentrieren und musst die „alten“ Prozesse nicht mehr beachten. 
Der häufigste Fehler bei Prozessen in der Migration ist, die IST-Analyse zu vernachlässigen. Das ist emotional oft verständlich, das Altsystem ist in die Jahre gekommen und „verbaut“. Niemand möchte sich damit zu ausführlich beschäftigen und im neuen System wird alles besser. Damit das aber auch wirklich so geschieht, solltest Du Dir dennoch ganz genau anschauen, wie es aktuell läuft. Nur so stellst Du sicher, dass Du keinen Prozess vergisst. Unsere Erfahrung zeigt, oftmals stecken in Altsystemen auch durchaus gute Ideen und nützliche Prozesse, wenn man also die IST-Analyse zu sehr abkürzt, verliert man wertvolles Prozesswissen.

4. Schnittstellen und Migration

Die drei Grundfragen der Schnittstellenanalyse sind: Aus welchen Systemen kommen Daten, wie geht Pimcore mit diesen Daten um und in welche Systeme sollen Daten geliefert werden. Für die Migration bietet sich an, sich zuerst mit der Frage zu beschäftigen, woher die Daten kommen, denn wie oben schon erläutert, ist die Datenmigration der riskanteste Teilschritt. 
Hier kann sich erfahrungsgemäß auch herausstellen, dass die bisherige Datenquelle nicht mehr optimal ist und sich eine Alternative anbietet. Eine Migration bietet in einem solchen Fall die Chance, nochmal grundlegend über die Systemarchitektur nachzudenken und unter Umständen Anpassungen vorzunehmen. 
Nachdem geklärt ist, welche Daten woher bezogen werden, richtet sich dein Blick auf Exportschnittstellen. Du forschst nach, an welche Systeme das Altsystem auf welchen Wegen bisher Daten weitergibt. 
Für die Exportschnittstellen gibt es in der Migration wichtige Tipps, die die Erfolgschancen des Implementierungsprojekts massiv erhöhen: 
  1. Wenn möglich und technisch sinnvoll, erhalte die Bereitstellungsmethode und Datenstruktur der alten Schnittstelle. Um die Komplexität des Migrationsprojekts zu reduzieren, kann es z.B. sinnvoll sein, eine alte CSV-Schnittstelle erstmal 1-zu-1 nachzubauen, statt sie mit einer modernen REST-API abzulösen. 
  2. Das große ABER zu Tipp 1: Wenn die Schnittstelle zentrale Bedeutung hat, ist eine sofortige Modernisierung oft besser. 
  3. Wenn du eine Schnittstelle verändern musst, definiere sie aus Pimcore-Sicht frühzeitig, das heißt, bevor du die Daten importierst oder die Prozesse zur Datenumwandlung und -anreicherung gebaut hast. Der Vorteil: Das System, dem du die Daten übermitteln möchtest, kann mit diesen Informationen schon parallel mit der Implementierung der Schnittstelle starten, die gesamte Projektlaufzeit verkürzt sich. Pimcores Datahub bietet hier mit den REST- und GraphQL-APIs sehr gute Möglichkeiten, auch eine Dummy-Schnittstelle bereitzustellen.

5. Nutzer*innen und Migration

Das Erfolgsgeheimnis ist, gut zuzuhören. Oft nutzen Nutzer*innen das Altsystem auf Arten, die den Projektverantwortlichen gar nicht bekannt sind. Kleine Tricks und Abkürzungen haben sich etabliert, manche Funktionen sind überhaupt nicht dokumentiert und dennoch im Alltag wichtig. Je besser du hier in der Anforderungsanalyse gearbeitet hast, desto reibungsloser läuft die Migration.
Höre auch zu bei Verbesserungsvorschlägen: Bleiben sie unbeachtet, entsteht daraus nicht selten eine Art Schatten-IT. Anwender*innen lösen Aufgaben über externe Werkzeuge wie Excel oder ähnliche Hilfsmittel scheinbar einfacher und schneller, aber leider am zentralen System vorbei und oftmals mit stark personenabhängigem Wissen.
Aber egal wie gut ihr zuhört und mitdenkt, an alles kann man unmöglich denken. Das bedeutet auch, dass ihr kein perfektes System entwickeln werdet. Dementsprechend ist es wichtig, dass das Projektteam den Anwender*innen in der Testphase vor der Systemeinführung Zeit einräumen sollte. Klingt selbstverständlich, aber wenn der Zeitplan wackelt, sieht die Testphase doch schnell aus wie eine komfortable Pufferzone. 
Nach der Migration solltest du den Anwender*innen außerdem immer eine Möglichkeit zur Meldung von Problemen und Verbesserungsvorschlägen geben. Damit kannst du eventuell „vergessene“ Prozesse, Daten und Funktionen noch abfangen. 
 
 

Fazit: Schrittweise Implementierung statt „Big Bang“

Auf den ersten Blick kann ein Datenmanagement- oder DXP-Projekt herausfordernd wirken. Mit Pimcore und einem strategischen Vorgehen anhand der Schritte unseres Guides bietet es allerdings auch immenses Potential. Starte mit der Business-Sicht und den W-Fragen. Erst danach folgt die Technik in Form des Datenmodells und der Schnittstellen. Die fachlichen Prozesse verbinden die Technik mit dem Erfolg der Plattform und sorgen für Nutzerakzeptanz. 
Tobias Hauser
Autor*In
Tobias Hauser

Tobias Hauser ist Geschäftsführer der Arrabiata Solutions GmbH sowie Autor, Trainer und Berater mit Schwerpunkt E-Learning und E-Commerce. Als Autor schreibt er seit über zwanzig Jahren zu wichtigen Web- und E-Commerce-Themen und berät Kunden von der Implementierung bis hin zur Umsetzung und Optimierung von Pimcore in mittelständischen und großen Unternehmen. Arrabiata Solutions ist bereits seit 2019 zertifizierter Pimcore Platinum Partner und realisiert seit sieben Jahren komplexe Datenmanagement- und E-Commerce-Projekte – von der strategischen Planung über die Softwarearchitektur bis zur erfolgreichen Vermarktung.

Alle Artikel von Tobias Hauser

Im Artikel erwähnte Softwares

Im Artikel erwähnte Software- oder Service-Kategorien

Im Artikel erwähnte Services

Ähnliche Artikel

Komm in die OMR Reviews Community & verpasse keine Neuigkeiten & Aktionen rund um die Software-Landschaft mehr.