Wie gehe ich ein Pimcore Projekt an? Datengrundlage, Endpunkte und Phasenmodell für B2B-Handel

Zuletzt aktualisiert: Juli 2026

Ein Pimcore-Projekt startet man richtig, indem man zuerst die eigene Datengrundlage klärt, dann die Ausgabekanäle (Endpunkte) definiert, Datenqualität technisch über Pflichtfelder und Workflows erzwingt und den Katalog anschließend in fünf Phasen statt per Big Bang ausrollt. Entscheidend ist nicht die Länge der Feature-Wunschliste, sondern ein tragfähiges Datenmodell.

Wer ein Pimcore Projekt startet, landet schnell bei einer langen Wunschliste: Mehrsprachigkeit, automatische Feeds, Lieferanten-Portal, KI-gestützte Texte. All das ist grundsätzlich machbar. Die Frage, die die meisten Projekte entscheidet, klingt aber viel weniger aufregend: Wie sieht eigentlich meine Datengrundlage aus?

Besonders im technischen Handel und Großhandel ist diese Frage unterschätzt. Wer mit 50.000 Artikeln, vier Lieferanten-Formaten und einer historisch gewachsenen Excel-Systematik startet, braucht vor allem eines: Klarheit über den Ist-Zustand. Erst dann ergibt ein Phasenmodell Sinn. Und erst dann lohnt es sich, über Features nachzudenken.

Dieser Beitrag zeigt, wie ein Pimcore Projekt strukturiert angegangen wird: von der Datengrundlage bis zur Roadmap.

Schritt 1: Wie ist meine Datengrundlage?

Vor jedem anderen Schritt steht eine ehrliche Bestandsaufnahme. Produktdaten kommen im B2B-Großhandel selten aus einer einzigen Quelle. Stattdessen verteilen sie sich typischerweise auf mehrere Systeme, die über Jahre gewachsen sind.

Häufige Datenquellen im technischen Handel:

• ERP-System: Artikel-Stammdaten, Preise, Bestände, Lieferanten-Zuordnungen
• Excel-Tabellen: historisch gewachsene Produktlisten, oft mit inkonsistenten Strukturen
• Lieferanten-Exporte: verschiedene Formate (BMEcat, Excel, CSV, PDF-Datenblätter)
• PLM-Systeme: technische Spezifikationen, Zertifizierungen, Normen
• DAM-Lösungen oder Ordnerstrukturen: Produktbilder, Datenblätter, CAD-Zeichnungen

Die entscheidende Frage ist nicht, welche Systeme vorhanden sind. Sondern: Welches System ist die autoritative Quelle für welche Daten? Wer darf was pflegen? Und welche Felder existieren überhaupt in strukturierter Form?

Typische Datenprobleme im Großhandel

Wer diesen Punkt ehrlich bearbeitet, stößt meistens auf drei bis vier der folgenden Probleme:

• Dubletten: Dasselbe Produkt mit leicht abweichenden Bezeichnungen in mehreren Systemen
• Fehlende Attribute: Technische Spezifikationen existieren auf dem Datenblatt des Lieferanten, aber nicht strukturiert im ERP
• Inkonsistente Einheiten: Längen in mm, cm und Zoll, Gewichte in kg und Gramm, gemischt und ungeprüft
• Lückenhafte Bilder: Viele Artikel haben kein Produktbild oder nur minderwertige Scans älterer Kataloge
• Sprachliche Inkonsistenz: Manche Artikel stammen aus deutschen Lieferantenimporten, andere aus englischen Quellen, ohne Bereinigung

Ehrlich gesagt: Eine perfekte Datenbasis gibt es selten. Das Ziel ist nicht Perfektion vor dem Projektstart, sondern ein realistisches Bild davon, was vorhanden ist und was bereinigt werden muss. Zwei Strategien sind grundsätzlich möglich: Bereinigung vor der Migration oder Nachbereinigung im Product Information Management System. Welcher Weg sinnvoller ist, hängt vom Umfang und Qualitätsgrad der bestehenden Daten ab.

So weit die Bestandsaufnahme. Damit steht die Grundlage für die nächste Frage: Wohin gehen die Daten?

Schritt 2: Welche Endpunkte habe ich?

Ein Datenmanagement-System wie Pimcore ist kein Datengrab. Es ist eine Zentrale, die Produktdaten empfängt, anreichert und an verschiedene Ausgabekanäle liefert. Diese Kanäle, die Endpunkte, zu kennen, ist entscheidend für das Datenmodell.

Typische Endpunkte im B2B-Handel und Großhandel umfassen sehr unterschiedliche Anforderungen an Format, Vollständigkeit und Aktualität:

• Online-Shop (z.B. Shopware): Marketing-Texte, Bilder, Kategorien, SEO-Attribute (Richtung: Pimcore zum Shop)
• ERP-System: Stammdaten herein, Status und Preise zurück (bidirektionale Verbindung)
• Marktplätze (Amazon, Google Shopping): Formatspezifische Pflichtattribute, Feed-Export
• Katalog / Printmedien: Vollständigkeit, normierte Felder, druckfähige Assets
• EDI-Partner / Geschäftskunden: BMEcat, ETIM, individuelle Formate
• CRM / Kundenservice: Technische Referenzdaten für Beratung und Vertrieb

Wer seine Endpunkte kennt, kann das Datenmodell von Anfang an so aufbauen, dass kanalspezifische Felder sauber abgebildet sind, statt später mit Workarounds zu arbeiten. Das ist einer der wichtigsten Hebel für das gesamte B2B Commerce-Projekt. Die Frage ist nur: Wie stellt man sicher, dass die Daten in diesem Modell auch sauber bleiben?

Das Datenmodell muss den Ausgabekanälen folgen, nicht dem Bauchgefühl. Wer zuerst die Endpunkte definiert und erst dann die Feldstruktur baut, spart sich die teuerste Sorte Nacharbeit: das Umbauen eines Modells, an dem bereits Shop, ERP und Marktplätze hängen.

Philipp Foreman

Geschäftsführer, onacy GmbH

Schritt 3: Wie sichert man Datenqualität technisch ab?

Datenqualität ist kein Zustand, den man einmal herstellt. Sie ist ein Prozess. Pimcore bietet dafür ein umfangreiches technisches Toolset, allerdings muss man die richtigen Features auch bewusst einsetzen.

Validierungen und Pflichtfelder

Der einfachste und wirksamste Schutzmechanismus: Kein Artikel kann publiziert werden, wenn Pflichtfelder leer sind. Pimcore erlaubt dabei sehr feine Konfigurationen ohne Programmieraufwand:

• Globale Pflichtfelder: z.B. EAN, Artikelbezeichnung, Primärbild, für alle Artikel gleich
• Kategorieabhängige Pflichtfelder: Elektronikartikel brauchen Spannung und Leistung, Schrauben brauchen Norm und Werkstoff
• Kanalspezifische Anforderungen: Was für den Katalog reicht, genügt für Amazon möglicherweise nicht

Zusätzlich lassen sich Regex-Validierungen konfigurieren, die Formate prüfen: EAN-Nummern auf 13 Stellen, Maßangaben auf numerische Werte, E-Mail-Adressen auf korrekte Syntax. Alles ohne Programmierung konfigurierbar.

Datenqualitäts-Scores

Pimcore kann jedem Produkt einen Qualitätsscore zuweisen, basierend auf individuell konfigurierten Regeln. Statt zu sagen „Dieser Artikel ist unvollständig“, sieht man: 70%, es fehlen noch Bilder und zwei Marktplatz-Attribute. Das Dashboard zeigt, wo der größte Handlungsbedarf liegt, und Redakteure können gezielt priorisieren.

Dieser Ansatz ist besonders für große Kataloge wertvoll. Ein Großhändler für Industriebedarf mit 30.000 Artikeln kann so strukturiert vorgehen: Artikel unter 60% Score bekommen in Phase 1 Priorität, bevor der neue Kanal live geht.

Workflow-gesteuerte Freigaben

Kein Artikel geht ohne Freigabe online. Das klingt selbstverständlich, ist aber in der Praxis oft nicht umgesetzt. Pimcore erlaubt mehrstufige Workflows mit klaren Zuständigkeiten:

1. Datenpfleger erfasst Grunddaten aus ERP-Import
2. Fachredakteur ergänzt Marketing-Text und Bilder
3. Qualitätsprüfung validiert Vollständigkeit automatisch
4. Verantwortlicher gibt frei
5. Automatische Publikation an die definierten Kanäle

Das verhindert, dass halbfertige Artikel öffentlich sichtbar werden, ein häufiges Problem, wenn Redaktionsprozesse nur durch Absprachen und nicht durch das System selbst gesteuert werden.

KI-gestützte Qualitätsprüfung

Der Pimcore Copilot nutzt maschinelles Lernen, um Qualitätsprobleme automatisch zu erkennen: semantische Inkonsistenzen, ungewöhnliche Werteabweichungen bei technischen Daten, fehlende Übersetzungen. Das entlastet das Redaktionsteam bei großen Katalogen erheblich. So weit die technische Seite. Entscheidend ist, was man daraus macht, und wie man Features sinnvoll priorisiert.

Schritt 4: Welche Feature-Wünsche gehören wann ins Projekt?

Fast jedes Pimcore Projekt startet mit einer langen Wunschliste. Das ist auch richtig so. Wer sich vorab keine Gedanken über Feature-Wünsche macht, baut ein System, das von Anfang an zu klein gedacht ist.

Typische Feature-Wünsche im B2B-Großhandel, geordnet nach Aufwand und Häufigkeit:

• Mehrsprachigkeit, Produktinhalte in DE, EN, FR für internationale Kunden und Niederlassungen
• Variantenmanagement, Schrauben in 40 Längen, 6 Materialien, 3 Oberflächen als strukturierte Produktfamilien
• Cross-Selling und Up-Selling Relationen, Zubehör, Ersatzteile, Kombinationsvorschläge
• Lieferanten-Onboarding-Portal, Lieferanten pflegen eigene Daten direkt ins PIM ein
• Staffelpreise und Preisgruppen, Kundenspezifische Preise, Mengenrabatte
• KI-gestützte Textgenerierung, Automatische Beschreibungen auf Basis technischer Attribute
• Zertifikats-Management, Datenblätter, CE-Konformitätserklärungen, Sicherheitsdatenblätter

Die Liste lässt sich beliebig verlängern. Das Problem: Nicht alles davon ist zum Projektstart sinnvoll. Und nicht alles hat denselben Aufwand. Die Frage ist, wie man von dieser Liste zu einem realistischen Plan kommt.

Schritt 5: Warum ein Phasenmodell statt Big Bang?

Der häufigste Fehler bei PIM-Projekten: alles auf einmal. Der „Big Bang“-Ansatz, alle Daten migrieren, alle Features einschalten, alle Kanäle aktivieren, klingt effizient. Er ist es nicht. Systeme, die zu komplex gestartet werden, haben längere Anlaufzeiten, mehr Fehlerquellen und frustrierte Redaktionsteams.

Ein strukturiertes Phasenmodell reduziert Risiken und schafft frühe Erfolge, die das Team motivieren und das Management überzeugen:

Phase 1: Analyse & Konzept (4–6 Wochen)

Diese Phase ist die wichtigste und wird am häufigsten unterschätzt. Hier werden Datenhoheiten geklärt, das Zieldatenmodell definiert und Anforderungen aus allen beteiligten Abteilungen aufgenommen. Am Ende steht ein klares Konzept: Was kommt aus welchem System, wer pflegt was, welche Kanäle werden in welcher Reihenfolge angebunden?

Phase 2: MVP: Minimum Viable Product (6–8 Wochen)

Ein lauffähiges System mit einem definierten Produktsortiment, einem Kanal und einer Sprache. Nicht mehr, nicht weniger. Das ermöglicht frühzeitig echte Erfahrungen: Wie verhält sich das Datenmodell in der Praxis? Welche Validierungen fehlen noch? Das MVP schafft Vertrauen, intern wie beim Management.

Phase 3: Migration & Rollout (8–12 Wochen)

Nach dem MVP-Beweis folgt die schrittweise Migration des Gesamtkatalogs. Parallel werden weitere Kanäle angebunden und Workflows verfeinert. Schulungen für Redaktionsteams gehören in diese Phase, nicht als nachgelagerte Pflichtübung, sondern als Teil des Rollout-Plans.

Phase 4: Stabilisierung (4–6 Wochen)

Erste Reibungspunkte werden analysiert und beseitigt. Qualitäts-Scores zeigen, wo der Katalog noch Lücken hat. Das Team etabliert feste Datenpflegeprozesse. Diese Phase verhindert, dass sich schlechte Gewohnheiten einschleichen, bevor der Regelbetrieb beginnt.

Phase 5: Ausbau & Erweiterung (laufend)

Jetzt kommen die Feature-Wünsche aus der langen Projektliste ins Spiel, die im ersten Schritt zurückgestellt wurden. Lieferanten-Portal, KI-Textgenerierung, Marktplatz-Integration: auf einem stabilen Fundament sind diese Erweiterungen deutlich einfacher umzusetzen.

Think Big, Start Small: Grundlagen heute richtig legen

„Think Big, Start Small“ klingt nach einer Motivationsphrase. Im Pimcore-Kontext ist es echter strategischer Ratschlag, und der Punkt, den viele Projekte unterschätzen.

Das Prinzip: Nicht alle Features müssen zum Start live sein. Aber das Fundament, also das Datenmodell, die Architektur, die Klassifikationen, muss von Anfang an groß genug gedacht werden. Wer das nicht tut, zahlt später einen hohen Preis.

Konkrete Beispiele aus B2B-Projekten

Mehrsprachigkeit: Ein Großhändler für Industriebedarf startet zunächst nur mit deutschen Produktinhalten. Mehrsprachigkeit kommt später. Der Fehler: Das Textfeld für die Produktbeschreibung wird als einfaches String-Feld angelegt, nicht als mehrsprachiges Feld. Zwei Jahre später kostet die Umstellung auf Mehrsprachigkeit ein komplettes Projektbudget für Datenmigration.

Richtig: Alle Textfelder von Anfang an als „lokalisiert“ anlegen, auch wenn nur eine Sprache befüllt wird. Der Mehraufwand beim Start: nahezu null. Der Vorteil später: Mehrsprachigkeit ist ohne Migration aktivierbar.

Lieferanten-Onboarding: Der Aufbau eines Lieferanten-Portals ist ein komplexes Feature, zum Projektstart nicht sinnvoll. Aber das Datenmodell sollte Lieferantenattribute von Anfang an strukturiert ablegen: Lieferantennummer, Lieferanten-Artikelnummer, Herkunftsland, Mindestbestellmenge. Wer das vom Start an sauber macht, hat beim späteren Portal-Aufbau bereits die richtigen Daten an der richtigen Stelle.

Klassifikationssysteme: ETIM oder eClass werden im ersten Schritt oft als „zu aufwändig“ zurückgestellt. Wenn die Klassifikation aber nicht von Anfang an im Datenmodell vorgesehen ist, muss später eine komplette Datenstruktur ergänzt werden, mit allen Konsequenzen für bestehende Schnittstellen. Stattdessen: das Klassifikationsfeld anlegen, auch wenn es zunächst leer bleibt.

Nachträgliche Anpassungen an einem produktiv genutzten PIM-System sind grundsätzlich teurer als sorgfältige Vorarbeit. Die Daten sind verteilt, Schnittstellen hängen daran, Redakteure haben sich an Strukturen gewöhnt. Deshalb entscheidet sich der Erfolg eines Pimcore-Projekts nicht im Betrieb, sondern im Datenmodell und in einem realistischen Phasenplan.

Béla Yannik Hahne

Project Management & Operations, onacy GmbH

Das Prinzip dahinter: Es geht nicht darum, alles zum Start umzusetzen. Sondern darum, die Weichen so zu stellen, dass spätere Features kein strukturelles Umbauprojekt erfordern. In realen B2B-Projekten entscheidet genau dieser Unterschied darüber, ob die zweite Ausbaustufe planbar bleibt oder zum Budgetrisiko wird. Als Pimcore Platinum Partner begleiten wir diese Weichenstellung von Anfang an.

Zusammengefasst: Was ein gutes Pimcore Projekt ausmacht

Vier Punkte entscheiden darüber, ob ein Pimcore Projekt ein stabiles Fundament bekommt oder später teuer nachgebessert werden muss:

1. Datengrundlage zuerst: Wer die eigene Datensituation nicht kennt, baut auf unsicherem Boden, egal wie gut das System ist.
2. Endpunkte definieren: Das Datenmodell folgt den Ausgabekanälen, nicht umgekehrt. Das verhindert spätere Anpassungsschleifen.
3. Datenqualität technisch erzwingen: Pflichtfelder, Validierungen und Workflows sind keine Kür, sondern Voraussetzung für skalierbare Datenpflege.
4. Phasen statt Big Bang: Frühzeitige Erfolge halten das Projekt auf Kurs, schaffen Vertrauen und ermöglichen echtes Lernen aus der Praxis.

Und der übergeordnete Rat: Denken Sie bei der Konzeption groß, starten Sie klein. Das Datenmodell ist das langlebigste Element eines jeden PIM-Projekts. Es lohnt sich, hier zu investieren, bevor die erste Zeile Code geschrieben wird.

Häufige Fragen zum Pimcore-Projektstart

Wie lange dauert ein Pimcore-Projekt?

Ein strukturiertes Pimcore-Projekt im B2B-Großhandel dauert von der Analyse bis zum stabilen Betrieb typischerweise 22 bis 32 Wochen: 4 bis 6 Wochen Analyse und Konzept, 6 bis 8 Wochen MVP, 8 bis 12 Wochen Migration und Rollout sowie 4 bis 6 Wochen Stabilisierung. Der anschließende Ausbau mit weiteren Features läuft fortlaufend.

Braucht man perfekte Daten, bevor man startet?

Nein. Eine perfekte Datenbasis gibt es in der Praxis selten. Ziel vor dem Projektstart ist nicht Perfektion, sondern ein realistisches Bild des Ist-Zustands: Welche Quellen existieren, wo sind Dubletten, fehlende Attribute oder inkonsistente Einheiten? Bereinigt wird entweder vor der Migration oder nachgelagert im PIM, je nach Umfang und Qualität der Bestandsdaten.

Big Bang oder Phasenmodell, was ist besser?

Das Phasenmodell ist in nahezu allen Fällen die sicherere Wahl. Der Big-Bang-Ansatz, bei dem alle Daten, Features und Kanäle gleichzeitig live gehen, klingt effizient, führt aber zu längeren Anlaufzeiten, mehr Fehlerquellen und frustrierten Teams. Ein Phasenmodell reduziert Risiken und schafft früh sichtbare Erfolge, die intern Vertrauen aufbauen.

Was bedeutet „Think Big, Start Small“ bei Pimcore?

Das Prinzip trennt Fundament und Features. Nicht jedes Feature muss zum Start live sein, aber das Datenmodell, die Architektur und die Klassifikationen müssen von Anfang an groß genug gedacht werden. Textfelder gleich als mehrsprachig anlegen, Lieferanten- und Klassifikationsfelder vorsehen, auch wenn sie zunächst leer bleiben. So werden spätere Erweiterungen kein teures Umbauprojekt.

Welche Systeme lassen sich an Pimcore anbinden?

Pimcore fungiert als zentrale Datendrehscheibe und bedient sehr unterschiedliche Endpunkte: Online-Shops wie Shopware, ERP-Systeme in bidirektionaler Verbindung, Marktplätze wie Amazon oder Google Shopping, Katalog- und Printmedien, EDI-Partner über BMEcat oder ETIM sowie CRM- und Kundenservice-Systeme. Welche Kanäle zuerst angebunden werden, bestimmt das Datenmodell und die Reihenfolge im Rollout.

Autor

Béla Yannik Hahne

Project Management & Operations, onacy GmbH

Béla Yannik Hahne verantwortet bei der onacy GmbH das Projektmanagement und die Operations von E-Commerce- und PIM-Einführungen. Sein Fokus liegt auf realistischen Phasenplänen, sauberen Meilensteinen und Pimcore-Projekten, die tatsächlich live gehen, statt an einem zu groß gedachten Big-Bang-Start zu scheitern.