Was Interessenten uns wirklich fragen: sechs Fragen aus jeder PIM-Evaluierung

Wenn eine Anfrage bei uns eingeht, sieht sie selten aus wie ein Feature-Wunschzettel. Sie sieht aus wie eine Risikoanalyse.

Die Menschen, die uns schreiben, bauen gerade eine Infrastruktur auf, die sie die nächsten fünf bis zehn Jahre begleiten wird. Sie haben ein führendes ERP-System, das sie nicht anfassen wollen. Sie haben Märkte in zwanzig Ländern und ein Team, das keine zwanzig Lektorinnen und Lektoren umfasst. Und sie haben schon einmal erlebt, wie aus einer „vollautomatischen Synchronisation“ nach sechs Monaten ein Ordner voller Excel-Workarounds wurde.

Die Fragen, die sie stellen, wiederholen sich mit erstaunlicher Präzision. Hier sind die sechs häufigsten – und die Antworten, die wir geben. Auch dort, wo sie unbequem sind.

1. „Wie ausgereift ist KI-Übersetzung wirklich – und wie viel manuelles Lektorat bleibt übrig?“

Das ist die ehrlichste Frage im ganzen Katalog, weil sie die richtige Erwartung mitbringt: dass die Antwort nicht „null“ lautet.

Unsere Antwort lautet auch nicht „null“. Sie lautet: Der Review-Aufwand hängt nicht von der Sprache ab, sondern von der Art des Inhalts. Wer 25 Sprachen als eine einzige Aufgabe behandelt, plant garantiert falsch. Wir unterscheiden drei Klassen.

Strukturierte und technische Attribute

Abmessungen, Anschlussarten, Materialangaben, Variantenbezeichnungen. Sobald Terminologie und Attributwerte einmal sauber hinterlegt sind, läuft das praktisch ohne Review. Der Translation Agent überträgt hier keine Sätze, sondern kontrollierte Werte – „Small“ und „s“ werden zu „S“, verschiedene Blautöne zu „blau“. Das ist Normalisierung, nicht Kreativität, und entsprechend zuverlässig.

Marketing- und Beschreibungstexte

Das, was wir intern emotionale Daten nennen – Titel, Bullet Points, Beschreibungen, die eine Kaufentscheidung tragen sollen. Hier ist Übersetzung nicht der Punkt; Anpassung ist der Punkt. Der Translation Agent überträgt nicht wörtlich, sondern markt- und sprachgerecht. Trotzdem gilt: In Ihren zwei oder drei umsatzstärksten Sprachen sollten Sie lektorieren. In den übrigen zwanzig genügt in aller Regel eine Stichprobe plus ein Terminologie-Check.

Regulatorische Angaben

Energieeffizienzklassen, gesetzliche Kennzeichnungen, Textilkennzeichnung. Diese Inhalte werden automatisch ergänzt und konvertiert – aber sie gehören in einen dokumentierten Freigabeprozess. Nicht weil die KI hier schwächer wäre, sondern weil Sie im Zweifelsfall nachweisen müssen, wer freigegeben hat. Dafür gibt es den Workflow Agent.

Dazu kommt der Teil, den Übersetzung allein nie löst: Metrik-Konvertierung. Zentimeter zu Zoll, EUR zu USD, Schuhgrößen EU zu UK. Wer in EMEA und MENA gleichzeitig verkauft, verliert genau hier Zeit – nicht an der Sprache, sondern an den Einheiten.

Sie ersetzen kein Lektorat. Sie verschieben es von „alles übersetzen und alles prüfen“ zu „nichts übersetzen und gezielt prüfen“. Das ist der eigentliche Hebel.

2. „Welche Übersetzungs-Engine nutzen Sie im Hintergrund?“

Diese Frage bekommen wir oft, und wir verstehen, warum. Trotzdem halten wir sie für die falsche Frage.

Unser CEO Lorenz Schneidmadel formuliert seine Position dazu regelmäßig öffentlich: Die Kernkompetenz liegt in der Orchestrierung, nicht im Modell. Je nach Use Case wird unterschiedlich orchestriert; welches Modell wo läuft, ist eine Implementierungsentscheidung, die sich ändern kann und ändern soll – sonst hätten Sie in achtzehn Monaten den Stand von heute eingekauft.

Die Fragen, die Ihre Ergebnisse tatsächlich bestimmen, sind andere:

• Terminologiekontrolle. Können Sie verbindlich festlegen, dass Ihr Produktbegriff im Polnischen immer so und nie anders heißt?
• Kontext. Sieht das System beim Übersetzen nur den Textschnipsel – oder Kategorie, Attribute und Nutzungskontext des Produkts?
• Nachvollziehbarkeit. Können Sie sehen, woher ein Wert stammt und wie sicher er ist? Bei unserer Deep Research wird jedes Attribut mit Quelle und Confidence-Bewertung ausgewiesen – genau deshalb.
• Wechselbarkeit. Sind Sie an eine Engine gebunden, wenn eine bessere kommt?

Wer nur nach dem Engine-Namen fragt, bekommt eine Antwort, die in einem Jahr veraltet ist. Wer nach diesen vier Punkten fragt, bekommt eine Antwort, die trägt.

3. „Ist die ERP-Anbindung eine zertifizierte native App oder eine individuell gebaute Schnittstelle?“

Hinter dieser Frage steckt nie technische Neugier. Sie steckt voller Narben. Übersetzt lautet sie: Baut ihr mir eine Sonderlocke, die beim nächsten Upgrade bricht und die hinterher niemand mehr versteht?

Die Antwort ist: weder noch – und das ist beabsichtigt.

Unsere Business-Central-Integration ist ein produktisierter Standard-Konnektor mit API-basierter Anbindung. Sie ist kein Projekt-Artefakt, das für Sie einmalig geschrieben wird: Sie wird als Produkt gepflegt, versioniert und weiterentwickelt. Konfiguriert wird sie trotzdem – Feldzuordnung, Synchronisationsrichtung, Frequenz, Formate (XML, JSON, CSV). Das ist Konfiguration, nicht Individualentwicklung. Der Unterschied zeigt sich in dem Moment, in dem Sie Support brauchen.

Der bewusste Verzicht auf eine Erweiterung, die innerhalb des ERP läuft, hat einen Grund: Solcher Code muss bei jedem Business-Central-Upgrade mitgetestet werden. Eine API-basierte Anbindung entkoppelt beide Systeme. Ihr ERP bleibt Standard. Ihr PIM bleibt Standard. Die Verbindung dazwischen ist ein Vertrag, kein Eingriff.

Prüfen Sie bei jedem Anbieter deshalb weniger das Zertifikat und mehr diese drei Dinge: Wird der Konnektor als Produkt oder als Projekt geführt? Wer trägt die Wartung bei einem ERP-Update? Und ist die Feldzuordnung für Sie einsehbar – oder liegt sie in einer Blackbox?

4. „Wie werden Konflikte bei bidirektionaler Synchronisation gelöst?“

Das ist die technisch beste Frage der Liste – und die einzige, bei der wir die Prämisse zurückweisen.

Gut gebaute bidirektionale Synchronisation löst keine Konflikte. Sie macht sie unmöglich.

Der Fehler liegt fast immer in der Annahme, „bidirektional“ bedeute „jedes Feld fließt in beide Richtungen“. Das tut es nicht und soll es nicht. Bidirektional heißt: manche Felder fließen von A nach B, andere von B nach A. Auf Feldebene, nicht auf Systemebene.

In der Praxis sieht die Aufteilung fast immer so aus: Das ERP führt Artikelnummer, Preise, Bestände, Logistikdaten und kaufmännische Stammdaten. Das PIM führt Marketingtexte, Bilder, Videos, technische Unterlagen, Konformitätserklärungen, kanalspezifische Inhalte und Übersetzungen.

Ein Feld hat genau einen Eigentümer. Im jeweils anderen System ist es lesend. Damit gibt es nichts mehr zu „lösen“ – es kann gar kein Konflikt entstehen.

Für die Fälle, in denen tatsächlich mehrere Quellen dieselbe Information liefern – typischerweise bei Lieferantendaten, nicht im ERP-Verhältnis – arbeiten wir mit dem Golden Record: Alle Quellen fließen in einen zentralen Datensatz pro Produkt, und Sie priorisieren die Quellen. Höher gewichtete Informationen überschreiben niedrigere, nach Regel und nicht nach Zufall.

Der Satz, den wir jedem Interessenten mitgeben: Wenn ein Anbieter Ihnen eine ausgefeilte Konfliktlösungs-Logik präsentiert, fragen Sie zuerst, warum das Datenmodell überhaupt Konflikte zulässt.

5. „Wie passen Assets, Dokumente und Print in dasselbe System?“

Diese drei Themen kommen fast immer im Nachsatz – und sie sind der Grund, warum reine ERP-Erweiterungen scheitern.

Assets

Bilder und Videos liegen bei uns nicht neben dem PIM, sondern darin. Das DAM ist vollständig integriert, Medien werden automatisch mit Produkten verknüpft. Dazu kommen Versionierung, Lizenzmanagement mit automatischer Erkennung abgelaufener Nutzungsrechte, Duplikatscheck beim Import und kanalspezifische Bildanpassung. Der Media Agent erzeugt ALT-Texte und Medienmetadaten automatisch – was inzwischen weniger eine SEO- als eine Barrierefreiheitsanforderung ist.

Dokumente mit Mehrfachzuordnung

Konformitätserklärungen, Datenblätter und Zertifikate gelten selten für genau ein Produkt. Ein Dokument wird deshalb einmal gepflegt und mit beliebig vielen Produkten verknüpft – nicht kopiert. Läuft ein Zertifikat aus, tauschen Sie eine Datei aus, nicht dreihundert Verknüpfungen.

Print, Leaflets und PDF-Kataloge

Hier gibt es zwei Wege. Der PDF-Export erzeugt CI-konforme Produktdatenblätter und Sortimentsübersichten auf Knopfdruck, live aus den geprüften PIM-Daten – für Angebote, Messen, Händler-Onboarding und Ausschreibungen, ohne Wartezeit auf die Grafikabteilung. Für gestaltete Kataloge gibt es die Adobe-InDesign-Anbindung. Der entscheidende Punkt ist in beiden Fällen derselbe: Es gibt keine zweite Wahrheit fürs Print. Was im PIM freigegeben ist, steht im Katalog.

6. „Und was ist mit EDI und unseren Handelspartnern?“

Hier antworten wir mit einer Abgrenzung, weil alles andere unseriös wäre.

Ein PIM ist kein EDI-System. Klassische EDI-Transaktionen – Bestellungen, Lieferavise, Rechnungen – gehören ins ERP oder in Ihre Middleware, und dort sollen sie auch bleiben.

Was ein PIM übernimmt, ist die Produktcontent-Seite des Partneraustauschs: die Kataloge, Sortimentsdaten und Klassifizierungen, die Sie Ihren Handelspartnern bereitstellen. Dafür gibt es strukturierte Ausgangskanäle – API, Webhooks, FTP/SFTP, JSON, CSV, XML, PDF – und die Branchenstandards BMEcat und ETIM, die im Großhandel und technischen Handel die eigentliche Währung sind.

Die saubere Arbeitsteilung: Ihr ERP tauscht Transaktionen aus. Ihr PIM liefert den Content, über den transagiert wird. Wer beides in ein System zwingt, bekommt am Ende keines von beidem richtig.