Pimcore Entwicklung und Beratung für Österreich und Süddeutschland

Ein Pimcore-Datenmodell ist eine Reihe von Entscheidungen darüber, wo welches Attribut liegt, und diese Entscheidungen altern. Einfache Klassenfelder sind schnell abfragbar und leicht zu überblicken, werden aber von jedem Produkt mitgetragen, ob sie passen oder nicht. Object Bricks hängen einen optionalen, entwicklerseitig definierten Block an einzelne Objekte. Der Classification Store hält Attribute als gruppierte Schlüssel-Wert-Daten, die Datenverantwortliche ohne Deployment pflegen können.

Was zu einer langsamen, unhandlichen Instanz führt, ist fast nie eine falsche Entscheidung am Anfang. Es ist, dass niemand sie überprüft hat, als sich der Katalog verändert hat. Eine Klasse, die mit zwei Produktfamilien sinnvoll war, ist mit elf eine Wand aus überwiegend leeren Feldern. Genau das ist die Arbeit: entscheiden, was umziehen muss, und es umziehen, ohne die Integrationen zu zerlegen, die darauf lesen.

• Struktur aus Klassen, Bricks, Field Collections und Classification Store, und welches Attribut wohin gehört
• Lokalisierung: welche Felder lokalisiert sind, welche Märkte sich eine Sprache teilen und wo Fallbacks greifen
• Relationen und Abhängigkeiten, inklusive jener, die Listings bei Volumen langsam machen
• Varianten- und Vererbungsstruktur für Kataloge, in denen sich Produkte in wenigen Attributen unterscheiden

Pimcore sitzt in der Mitte: das ERP ist meist das Vorsystem und führend für kommerzielle Daten, Shop und Kanäle liegen dahinter, DAM und Übersetzung daneben. Pimcore-Datenintegration heißt vor allem, festzulegen, welches System welches Feld besitzt, und diese Festlegung im Code durchzuhalten.

Für lesende Zugriffe ist der GraphQL-Endpunkt des Data Hub meist die bessere Wahl als selbstgebautes REST, weil ein Konsument genau die Felder anfragt, die er braucht, und ein neues Attribut unsichtbar bleibt, bis die Endpunkt-Konfiguration es freigibt. Schreibende Importe sollten idempotent und auf eine externe ID geschlüsselt sein, damit dieselbe Datei zweimal verarbeitet keine Duplikate erzeugt. Und Fehler brauchen einen Ort, an dem tatsächlich jemand hinsieht.

• Zeitgesteuerte ERP-Importe, die vor dem Schreiben auf Live-Objekte gestaged und validiert werden
• Data-Hub-GraphQL- und REST-Endpunkte für Shops, Kanäle und interne Konsumenten
• DAM-Synchronisierung, damit am Produkt das freigegebene Asset hängt und keine Kopie
• Übersetzungs-Rückläufe in lokalisierte Felder, ohne neuere Änderungen zu überschreiben

Pimcore kann alle drei, und daraus eine einzige Entscheidung zu machen, ist der Punkt, an dem Projekte kippen. Als PIM ist es stark: strukturierte Produktdaten, Varianten, Vererbung und Lokalisierung über Märkte hinweg sind genau das, wofür das Datenobjekt-Modell gebaut ist.

Als DAM ist es brauchbar, aber nicht immer die richtige Antwort. Wenn Ihr Asset-Workflow Rechteverwaltung, Freigabeketten und große Mengen Rohmaterial umfasst, ist ein eigenes DAM neben Pimcore oft die bessere Aufstellung. Genau so lief es bei dem Medizintechnik-Hersteller aus unserer Fallstudie. Als CMS funktioniert Pimcore gut, wenn die Website im Wesentlichen eine Sicht auf die Produktdaten ist, und weniger gut, wenn der Marketing-Auftritt ein Eigenleben führt.

• Klein, etwa ein bis zwei Wochen: eine einzelne Integration, eine auf eine Klasse begrenzte Datenmodell-Korrektur, ein Performance-Fix an einem langsamen Listing oder Export, ein Upgrade über Minor-Versionen
• Mittel, etwa drei bis sechs Wochen: eine Datenmodell-Umstrukturierung samt Migration, eine neue Kanal- oder Shop-Integration von Anfang bis Ende, ein Major-Upgrade bei ein bis zwei Versionen Rückstand
• Groß, ein Quartal oder mehr: eine Katalog-Migration aus Tabellen oder einem Alt-PIM, ein mehrsprachiger Markt-Rollout oder ein Major-Upgrade bei mehreren übersprungenen Versionen und viel Custom Code
• Laufend: die monatliche Betreuung, bei der die Arbeit aus vielen kleinen Änderungen plus einem geplanten Upgrade-Pfad besteht statt aus einem Projekt

Das ist der Regelfall und das, worauf wir eingerichtet sind. Jemand anderes hat Ihr Pimcore eingeführt, die Personen von damals sind weitergezogen, und was Sie brauchen, ist jemand, der ein fremdes System schnell liest und ehrlich über seinen Zustand spricht.

Der Einstieg dafür ist das Audit: eine Woche, 2.500 € fix, ein schriftlicher Bericht zu Versionsrisiko, Datenmodell, Integrationen, Performance und Sicherheit, mit priorisierter Maßnahmenliste. Danach haben Sie entweder die Grundlage, um jemand anderen zu beauftragen, oder wir arbeiten die Liste ab.

Bei einem Katalog mit ein paar hundert Produkten, stabilem Attributset und einem Vertriebskanal ist Pimcore mehr Plattform, als das Problem braucht. Eine fokussierte Eigenentwicklung ist dann im Betrieb günstiger und leichter zu ändern.

Wenn Sie zwischen Pimcore, Akeneo und einer Eigenentwicklung stehen, ist das eine Auswahlfrage und keine Entwicklungsfrage. Wir haben den Vergleich aufgeschrieben und sagen es klar, wenn die Antwort nicht das System ist, auf das wir spezialisiert sind.