Ihre Portale sollten Ihren PIM-Vertrag überleben

Die PIM-Verlängerung liegt auf Ihrem Tisch, und die Zahl hat sich bewegt. Irgendwo in der Prüfung der Alternativen weist jemand darauf hin, dass Kundenportal, Grosshandels-Feed und Shop-Anbindung allesamt in diesem PIM gebaut wurden — und aus der Lizenzentscheidung wird ein zweijähriges Replatforming.

Genau diese Kopplung ist der wahre Preis eines PIM-eigenen Portals, und beim Kauf wird sie selten eingepreist.

Was PIM-eigene Portale tatsächlich koppeln

Ein Portal als Modul Ihres PIM erbt vier Abhängigkeiten auf einmal:

• Lizenzierung. Portal-Nutzer fallen meist unter das Nutzer- oder Seat-Modell des PIM. Deshalb sind nach aussen gerichtete Portale häufig der teuerste Posten eines PIM-Vertrags.
• Datenmodell. Berechtigungen, Katalogansichten und Portalinhalte sind im Objektmodell dieses PIM formuliert. Herausheben lassen sie sich nicht.
• Release-Zyklus. Die Roadmap Ihres Portals ist die Roadmap des PIM-Herstellers. Eine Änderung, die Ihre Kunden wollen, wartet auf ein Versionsupgrade.
• Ausstieg. Ein PIM-Wechsel bedeutet: Portal neu bauen, externe Nutzer neu schulen, Zugänge neu ausstellen, jede nachgelagerte Integration neu verhandeln.

Die letzte Abhängigkeit ist die teure, weil sie Ihre Verhandlungsposition entfernt. Der Anbieter weiss, dass das Portal drinsteckt.

Die Alternative: eine kanonische Ebene zwischen Quelle und Kanal

Die architektonische Lösung ist alt und unspektakulär: eine Ebene zwischen die Systeme, die Daten halten, und die Kanäle, die sie verbrauchen — und diese Ebene, nicht das Quellsystem, zu dem machen, wovon die Kanäle abhängen.

Konkret bedeutet das drei Eigenschaften:

• Ein kanonisches Schema. Quellen werden auf ein Produktmodell mit typisierten Attributen, Einheiten, Sprachen und Marktkennzeichen abgebildet. Portal, Feed oder API-Consumer lesen den kanonischen Datensatz und erfahren nie, welches System ihn erzeugt hat.
• Berechtigungen gehören der Ebene. Wer welche Produkte, Kategorien, Märkte, Sprachen und Assets sehen darf, wird dort konfiguriert, wo die Kanäle sind, nicht im Quellsystem. Genau das lässt Portalzugänge einen Quellwechsel überleben.
• Ein stabiler Vertrag nach aussen. Eine versionierte REST-API, Webhooks, geplante Auslieferungen und Delta auf Feldebene, damit Consumer nur Geändertes abholen. Eine Quelle hinzufügen berührt keinen Kanal; einen Kanal hinzufügen berührt keine Quelle.

Die Prüffrage ist einfach: Können Sie ein zweites Quellsystem anbinden, ohne dass ein nachgelagerter Consumer es merkt? Wenn die Antwort ein Release im Shop verlangt, haben Sie eine Pipeline, keine Ebene.

Warum eine PIM-Migration damit ein anderes Projekt wird

Mit dieser Ebene hört die Migration auf, eine Wochenendumstellung zu sein, und wird zu einer Folge kleiner, umkehrbarer Schritte. Der Mechanismus, den wir Migrationsbrücke nennen, funktioniert so:

1. Das neue PIM als zweite Quelle anbinden. Das alte bleibt führend; nachgelagert ändert sich nichts.
2. Auf dasselbe kanonische Schema mappen. Jetzt können beide Systeme dasselbe Produkt in derselben Form ausdrücken.
3. Feld für Feld vergleichen. Für dieselben Produkte sehen, was die alte und was die neue Quelle liefert. Hier stecken die Überraschungen — und sie hier statt in der Produktion zu finden, ist der ganze Zweck.
4. Pro Attributgruppe umstellen. Identifikatoren und Marketingtexte aus dem neuen PIM, technische Attribute und Assets noch aus dem alten. Eine Gruppe nach der anderen, jede geprüft, bevor die nächste folgt.
5. Das alte System abschalten, sobald jede Gruppe auf dem neuen läuft.

Und die Eigenschaft, die die anderen vier erst benutzbar macht: Rollback pro Attributgruppe. Sehen die Marketingtexte nach der Umstellung falsch aus, geht diese Gruppe zurück auf die alte Quelle, während Sie das Mapping korrigieren. Keine Wiederherstellung, kein Ausfall, keine Beteiligung der Kanäle.

Für Kundenportal, Grosshandels-Feed und Shop bleibt die Migration unsichtbar. Sie erhalten durchgehend dieselben kanonischen Datensätze, im selben Schema, im selben Takt.

Derselbe Mechanismus deckt die Konsolidierung ab, den in Konzernen häufigeren Fall: mehrere Marken- oder Länder-PIM speisen ein Gate, konvergieren auf ein kanonisches Modell und werden dann in dem Tempo zusammengeführt, das das Geschäft verträgt.

Versionierung macht das Zurückgehen erst sicher

Umkehrbarkeit ist keine Funktion, die man zum Umstellungstermin ergänzt; sie ist eine Folge davon, Historie zu führen. Wenn jeder Export als nummerierte Version gespeichert ist und sich zwei beliebige auf Feldebene vergleichen lassen, gilt:

• Die Prüfung wird mechanisch. Vergleichen Sie den letzten Export der alten Quelle mit dem ersten der neuen. 37 Produkte geändert, 112 Felder — ist das die erwartete Menge? Wenn nicht, wissen Sie es, bevor ein Kanal es sieht.
• Regressionen sind zuordenbar. Meldet ein Grosshändler einen falschen Wert, finden Sie die Version, in der er sich geändert hat, statt darüber zu diskutieren.
• Rollback ist definiert. Zurückgehen heisst, in einen Zustand zurückzugehen, der existiert und den Sie ansehen können.

Das ist zugleich die Voraussetzung für Delta auf Feldebene überhaupt — nur senden kann, was sich geändert hat, wer den vorherigen Stand kennt. Erfahrungsgemäss ist das die eine Fähigkeit, die das Gefühl einer Migration am stärksten verändert, weil sie «wir glauben, es hat funktioniert» in ein lesbares Diff verwandelt.

Fragen an Ihren PIM-Anbieter

Vor einer Verlängerung zu stellen, und unabhängig von der Entscheidung nützlich:

• Was passiert mit dem Portal, wenn wir das PIM ersetzen — wird es neu gebaut, und wer zahlt?
• Sind Portal-Endnutzer lizenzpflichtig, und nach welcher Einheit?
• Lassen sich unsere Berechtigungsregeln so exportieren, dass ein anderes System sie lesen könnte?
• Gibt es eine API, auf die sich ein Kanal unabhängig vom Release-Zyklus des PIM verlassen kann, mit einem Delta-Mechanismus?
• Können zwei Quellsysteme gleichzeitig denselben Kanal speisen?

Die Antworten zeigen meist deutlich, wo das Lock-in sitzt. Sie schärfen auch die Frage, was überhaupt ins PIM gehört: führende Stammdaten ja; das Berechtigungsmodell für Ihre externen Zielgruppen eher nicht.

Wo PIM Gate steht

PIM Gate ist diese Ebene als Produkt. Es läuft neben Ihrem PIM, statt es zu ersetzen — liest über XML, REST oder geplantes SFTP, bildet auf ein kanonisches Schema ab und bedient daraus Kunden-, Lieferanten- und Vertriebsportale sowie eine versionierte API. Als Quellen arbeitet es mit Viamedici, Akeneo, Pimcore, Stibo und Censhare; die Migrationsbrücke betreibt Alt und Neu parallel, mit Umstellung und Rollback pro Attributgruppe, und jeder Export ist versioniert und vergleichbar. Delta-Sync auf Feldebene bedeutet rund 95 % kleinere Payloads als Vollexporte. Portal-Endnutzer sind in jeder Version unbegrenzt — damit entfällt neben der architektonischen auch die lizenzrechtliche Kopplung.

In Ihr PIM wird nichts zurückgeschrieben, ausser Sie konfigurieren es. Das PIM bleibt führend; was sich ändert, ist, dass Ihre Kanäle nicht mehr davon abhängen, welches PIM das ist.

Wichtigste Punkte

• PIM-eigene Portale koppeln Lizenzierung, Datenmodell, Release-Zyklus und Ausstieg an einen Anbieter — die Ausstiegskopplung kostet Sie die Verhandlungsposition.
• Eine kanonische Ebene zwischen Quellen und Kanälen löst das: ein Schema, Berechtigungen bei der Ebene, ein stabiler versionierter Vertrag nach aussen.
• Prüffrage: Lässt sich eine zweite Quelle anbinden, ohne dass ein nachgelagerter Consumer es merkt?
• Eine Migrationsbrücke macht aus dem Big Bang eine Folge von Umstellungen pro Attributgruppe, jede mit Rollback.
• Versionierte Exporte mit Vergleich auf Feldebene machen die Prüfung mechanisch und das Zurückgehen definiert.
• Fragen Sie Ihren Anbieter, was beim Wechsel mit dem Portal geschieht, wie Portal-Nutzer lizenziert sind und ob zwei Quellen einen Kanal speisen können.