Pimcore für Publishing – ein Titel, sechs Länder, ein Datenmodell.
Titelmetadaten, ONIX-Export, Mehrmarkt-Ausgaben: Wir haben genau dieses Problem für einen internationalen Fachverlag gelöst, nachdem ein Vorgänger-Dienstleister zwölf Monate erfolglos daran gearbeitet hatte.
Verlage verwalten selten nur Bücher oder Artikel. Sie verwalten Titelmetadaten, die über Länderausgaben, Sprachversionen und Vertriebskanäle hinweg konsistent bleiben müssen, während sich Auflagen, Rechte und Ausgabenformate laufend ändern. Ein Datenmodell, das Titel, Ausgaben und Metadaten nicht sauber voneinander trennt, wird bei jeder neuen Länderausgabe oder jedem neuen Vertriebspartner zum Flaschenhals, weil sich Änderungen nicht zentral, sondern in jeder Kopie einzeln nachziehen lassen.
Typische PIM-Muster in Publishing
Titelmetadaten als eigenständige, wiederverwendbare Struktur. Titel, Autor, ISBN, Sprache und Ausgabeinformationen gehören strukturiert getrennt vom eigentlichen Inhalt geführt, damit eine neue Sprachausgabe oder ein neues Format dieselben Metadaten erben kann, statt sie zu duplizieren.
ONIX- und Branchenformat-Export. Der Buchhandel und viele Vertriebspartner erwarten Titeldaten in standardisierten Austauschformaten. Ein Datenmodell, das diese Exportlogik direkt aus den strukturierten Titeldaten ableitet, erspart einen separaten, fehleranfälligen manuellen Aufbereitungsschritt.
Mehrmarkt- und Mehrsprachen-Ausgaben aus einer Quelle. Derselbe Titel existiert oft in mehreren Länderausgaben mit eigenen Umschlägen, Preisen und teils redaktionellen Anpassungen. Vererbung sorgt dafür, dass gemeinsame Metadaten zentral gepflegt werden und nur tatsächliche Länderunterschiede separat erfasst werden müssen.
Gewachsene, stark individualisierte Altsysteme. Verlagsplattformen wachsen häufig über viele Jahre organisch und werden stark kundenspezifisch angepasst. Ein Versions-Upgrade auf einer solchen Plattform ist selten ein Standardvorgang, sondern verlangt automatisierte Regressionstests über die gesamte Individualisierung hinweg.
Wie wir arbeiten
Ein dokumentierter Fall zeigt das Muster konkret: Ein internationaler Fachverlag im Medizinbereich mit Plattformen in sechs Ländern hatte eine über fünf Jahre gewachsene, stark individualisierte Pimcore-5-Plattform. Ein Vorgänger-Dienstleister war zwölf Monate mit dem Upgrade beauftragt, ohne Erfolg. Wir haben einen maßgeschneiderten Migrationsplan gebaut, die Versions-Migration auf Version 11 automatisiert und die gesamte Individualisierung über automatisierte Regressionstests abgesichert, nach demselben Muster wie in jedem Pimcore Rescue und jeder Upgrades & Migration. Ergebnis: Plattform sauber auf aktuellem Stand, Funktionalität vollständig gesichert, Betrieb stabil, nach zwölf Monaten Stillstand beim Vorgänger. Für die zugrunde liegende Titelmetadaten-Struktur über mehrere Länder hinweg bauen wir zusätzlich ein Golden-Record-Datenmodell auf, Teil unserer Enterprise-Daten & MDM-Arbeit, damit Metadaten-Änderungen an einer Stelle über alle Ausgaben wirken.
Häufige Fragen
Was tun, wenn ein Vorgänger-Dienstleister an einem Pimcore-Upgrade bereits gescheitert ist?
Genau das ist der Rescue-Regelfall. Wir übernehmen die bestehende, oft stark individualisierte Plattform, bauen einen eigenen Migrationsplan und sichern die Individualisierung über automatisierte Regressionstests ab, statt bei null neu zu beginnen.
Wie bleibt ein Titel über sechs Länderausgaben hinweg konsistent, wenn sich Metadaten ändern?
Über strukturierte Vererbung: gemeinsame Titelmetadaten liegen zentral, länderspezifische Abweichungen werden separat erfasst. Eine Änderung an der zentralen Ebene wirkt automatisch über alle Ausgaben, ohne manuelles Nachpflegen jeder Kopie.
Unterstützt Pimcore ONIX-Export nativ?
Pimcore selbst ist datenmodell-agnostisch, ONIX- oder andere Branchenformat-Exporte werden als Ausgabelogik auf Basis der strukturierten Titeldaten aufgebaut. Der entscheidende Faktor ist, dass die zugrunde liegenden Daten sauber strukturiert sind, nicht das Exportformat allein.
Wie geht man mit einer über Jahre stark individualisierten Verlagsplattform um, ohne die Individualisierung zu verlieren?
Über automatisierte Regressionstests, die vor und während der Migration die bestehende Funktionalität absichern. Im dokumentierten Fachverlag-Case war genau das der Unterschied zum gescheiterten Vorgänger-Versuch.
Bereit für Ihr Publishing-Projekt?
Wir übernehmen auch dort, wo ein Vorgänger bereits gescheitert ist.
Publishing-Projekt besprechen