So lassen sich „ESLs“ in Ihre „POS“, „ERP“ und Ihren E-Commerce integrieren

Wenn Sie die Person sind, die entscheiden muss, ob elektronische Regaletiketten in Ihrer Systemlandschaft tatsächlich funktionieren, ist der E-Paper-Bildschirm Ihre geringste Sorge. Die eigentliche Frage ist, ob ein Etikettennetzwerk Daten aus Ihrem „POS“, Ihrem „ERP“ und Ihrem Online-Shop auslesen kann, ohne dass Sie eine Umstellung auf eine neue Plattform vornehmen müssen – und wie viel von dieser Arbeit auf Ihr Team entfällt. Dieser Artikel erläutert, wie die Integration aufgebaut ist, an welche Systeme sie angebunden wird, wie der Datenfluss verläuft und welche Fragen den Unterschied zwischen einem reibungslosen und einem mühsamen Projekt ausmachen.

Warum die Integration – und nicht die Bezeichnung – darüber entscheidet, ob das Projekt erfolgreich ist

Die Integration entscheidet über Erfolg oder Misserfolg von „ESL“-Projekten, denn ein Preisschild ist immer nur so korrekt wie die Daten, mit denen es gespeist wird. Die Hardware ist kein Problem mehr: Wählen Sie ein seriöses Preisschild, und es wird über Jahre hinweg genau das anzeigen, was ihm mitgeteilt wird. Was sich von Projekt zu Projekt enorm unterscheidet, ist die Frage, ob die Preis-, Werbe- und Produktdaten zuverlässig und im richtigen Format ins Regal gelangen, ohne dass jemand einen anfälligen Export manuell pflegen muss. Bei einem Pilotprojekt mit fünfzig Etiketten fällt das nicht auf; bei einer Flotte von fünfzigtausend Etiketten in vielen Filialen wird es jedoch sofort offensichtlich. Bewerten Sie also zuerst die Anbindung an Ihre Systeme und erst in zweiter Linie den Bildschirm.

Die Synchronisierungs-Engine: Wie sie zwischen Ihren Systemen und dem Regal fungiert

Das Herzstück von „ESLs“ ist eine Synchronisierungs-Engine – ein Dienst, der zwischen Ihren Stammdatensystemen und dem Label-Netzwerk angesiedelt ist. Auf der einen Seite fließen Ihre Daten ein; die Engine ermittelt, was sich geändert hat, findet heraus, welche Labels davon betroffen sind, und überträgt das neue Bild über Zugriffspunkte in den Filialen auf der anderen Seite an diese Labels. Sie kommunizieren zu keinem Zeitpunkt mit einzelnen Labels, und Ihre Quellsysteme kommunizieren zu keinem Zeitpunkt direkt mit dem Regal. Sie kommunizieren ausschließlich mit der Engine.

Diese mittlere Ebene sorgt dafür, dass die Integration oberflächlich bleibt. Ihr „POS“ muss nicht wissen, was ein Access Point ist; Ihr „ERP“ benötigt kein Plugin pro Label-Modell. Sie übergeben Preise und Produktdaten auf die gleiche Weise, wie sie bereits Daten exportieren, und die Engine übernimmt die Übersetzung, die Bündelung, die Wiederholungsversuche und die Weiterleitung an Tausende von Bildschirmen. Sie können diese Struktur in unserem Integrationsdiagramm erkennen: Datenbank, „POS“, „ERP“ und E-Commerce speisen die Synchro-Synchronisations-Engine, die die Labels in jedem Geschäft aktualisiert.

Mit welchen Systemen es verbunden ist – POS, ERP /SAP/Oracle/Dynamics, Datenbanken, E-Commerce

Die Engine lässt sich mit allen Systemen verbinden, in denen Ihre Preise und Produktdaten bereits gespeichert sind – Sie behalten Ihre aktuellen Systeme bei, und es findet keine Migration statt. In der Praxis bedeutet das eine oder mehrere der folgenden Möglichkeiten:

Verkaufsstelle. Die Kasse ist oft die maßgebliche Quelle für den Verkaufspreis, daher sorgt die Synchronisierung über POS dafür, dass Regal und Kasse prinzipiell identisch sind. Cloud-POS-Plattformen (z. B. Odoo oder Hiboutik) stellen diese Daten in der Regel über eine API bereit; lokal installierte Kassen bieten sie meist als Datenbankansicht oder als geplanten Export an.
ERP — SAP, Oracle, Microsoft Dynamics und ähnliche Systeme. Wenn Preise, Werbeaktionen und Stammdaten im „ERP“ verwaltet werden, bezieht die Engine die Daten von dort. Diese Systeme sind auf die Integration ausgelegt: SAP über IDocs/BAPIs oder dessen OData- und REST-Dienste, Oracle über dessen REST- und Integrationsschichten, Dynamics 365 über dessen Web-API- und Dataverse-Dienste. Sie stellen die Preis- und Artikelentitäten bereit, über die Sie bereits berichten; Sie erstellen innerhalb des „ERP“ keine spezifischen Elemente für „ESL“.
Datenbanken und Flatfiles. Wenn die eigentliche Datenquelle eine SQL-Datenbank oder ein nächtlicher CSV-/XML-Import ist, liest die Engine diese Daten direkt ein. Dies ist gängige Praxis und absolut zuverlässig – viele große Flotten werden über einen zeitgesteuerten Dateifeed betrieben.
E-Commerce-Plattformen. Durch die Anbindung Ihres Online-Katalogs (Shopify, Magento/Adobe Commerce, WooCommerce oder eine Headless-Commerce-API) gilt für die Website und im Ladengeschäft derselbe Preis – dies bildet die Grundlage für die Preisparität zwischen Online- und Offline-Handel.

Es geht nicht um eine endlose Liste vorgefertigter Schnittstellen. Vielmehr geht es darum, dass die Engine Ihre Daten in genau der Form verarbeitet, in der sie bereits vorliegen – sei es als „API“, in einer Datenbank oder als Datei –, anstatt Sie zu zwingen, auf eine neue Plattform umzusteigen.

So funktioniert Integration in der Praxis: APIs, Middleware, Batch-Verarbeitung vs. Nahe-Echtzeit

Mechanisch gesehen gibt es zwei Vorgehensweisen, und in den meisten praktischen Anwendungsfällen wird eine Kombination aus beiden verwendet. Welche davon die richtige ist, hängt davon ab, wie schnell eine Preisänderung im Regal umgesetzt werden muss, und nicht von einer persönlichen Präferenz.

Nahezu in Echtzeit, über API oder Webhooks. Wenn sich ein Preis in Ihrem System ändert, wird die Engine aufgerufen (oder die Engine abonniert einen Änderungs-Feed), und die betroffenen Preisschilder werden innerhalb von Sekunden neu dargestellt. Dies ist das richtige Verfahren für dynamische Preisgestaltung, Blitzangebote und wettbewerbsorientierte Preisneufestsetzung.
Batch-/geplante Synchronisierung. Die Engine führt nach einem festgelegten Zeitplan – jede Nacht, jede Stunde oder alle paar Minuten – einen vollständigen oder Delta-Export durch. Dies ist einfacher zu implementieren, leicht zu überprüfen und völlig ausreichend, wenn sich die Preise in vorhersehbaren Abständen ändern. Ein nächtlicher Batch-Lauf aktualisiert die gesamte Flotte, bevor die Türen geöffnet werden.

Die Middleware in der Mitte gleicht die chaotische Realität zwischen diesen beiden idealisierten Szenarien aus: Sie entfernt Duplikate bei Änderungen, wiederholt fehlgeschlagene Übertragungen, stellt Aktualisierungen in eine Warteschlange, wenn es zu Netzwerkstörungen bei einer Filiale kommt, und führt einen Abgleich durch, sodass ein Etikett, bei dem eine Aktualisierung übersehen wurde, beim nächsten Durchlauf korrigiert wird. Diese Ausfallsicherheit ist der eigentliche Grund, warum Sie Ihre „ERP“ nicht direkt mit dem Regal verbinden.

Einmalige Integration vs. fortlaufender Datenfluss: einmal vs. nie wieder

Die Integration erfolgt einmalig; der anschließende Datenfluss läuft automatisch und ohne manuelles Eingreifen ab. Es ist hilfreich, diese beiden Aspekte klar voneinander zu trennen:

Einmal: Sie gewähren Zugriff auf eine Datenquelle (API-Zugangsdaten, einen Datenbankbenutzer mit Lesezugriff oder einen „Drop“-Ordner) und legen die Feldzuordnung fest. Wir ordnen Ihre Daten zu und schlagen die Brücke von Ihrer Infrastruktur zum Label-Netzwerk – ganz ohne Migration und ohne neue Tools, die Ihr Team erst erlernen müsste.
Nie wieder: Ab dem Go-Live wird eine Preisänderung in Ihrem System automatisch bis ins Regal weitergegeben. Niemand exportiert manuell eine Datei, niemand läuft mit einem Etikettendrucker durch die Gänge. Ihre Mitarbeiter arbeiten weiterhin genau mit den Systemen, die sie bereits nutzen; die Etiketten werden automatisch nachgeliefert.

Diese Aufteilung ist die Antwort auf die Frage, die sich die meisten IT-Verantwortlichen eigentlich stellen: Der Aufwand konzentriert sich auf die Anfangsphase und ist begrenzt – es handelt sich nicht um eine dauerhafte operative Belastung.

Datenabgleich: Was die Engine von Ihnen benötigt

Der Kern dieser einmaligen Aufgabe ist das Data Mapping – also der Engine mitzuteilen, welche Ihrer Felder welche Bedeutung haben. Das ist keine Hexerei, und genau dieser Teil sollte bei der Festlegung des Projektumfangs genau geklärt werden. Die Engine benötigt mindestens:

Ein stabiler Produktschlüssel (SKU /EAN/GTIN). Dieser dient als Anker, der ein physisches Etikett mit einem Datensatz in Ihrer Datenbank verknüpft; daher muss er eindeutig und unveränderlich sein. Die meisten Integrationsprobleme lassen sich auf eine instabile oder inkonsistente Produktkennung zurückführen.
Preisangaben. Der reguläre Preis sowie alle weiteren Preise, die Sie anzeigen – Mitgliedspreis, Stückpreis (pro kg/l), inklusive bzw. exklusive Steuern – und welche Angabe maßgeblich ist, wenn die Systeme voneinander abweichen.
Aktionsdaten. Der Aktionspreis sowie die Zeitstempel für Beginn und Ende der Aktion, damit das Label rechtzeitig auf das Aktionslayout umschalten und nach Ablauf der Aktion automatisch wieder zum Normalzustand zurückkehren kann.
Produktmerkmale, die auf dem Etikett stehen sollen: Name, Marke, Größe, Herkunft, Nährwertangaben oder gesetzliche Hinweise, QR-Codes/Treuecodes.
Lagerbestandsfelder, falls Sie möchten, dass die Verfügbarkeit oder ein niedriger Lagerbestand am Regalrand angezeigt wird.

Sauberere Stammdaten sorgen für eine schnellere Integration. Wenn Ihre SKUs einheitlich sind und Ihre Preise an einem zentralen Ort verwaltet werden, geht die Zuordnung schnell von der Hand; wenn die Preise jedoch über Tabellenkalkulationen und Übersteuerungen verstreut sind, lohnt es sich, dies vor – oder im Rahmen – des Projekts zu ordnen.

Bidirektionale Datenübertragung: Rückmeldung von Bestands- und Kommissionierdaten aus dem Regal

Die Integration muss nicht einseitig sein. Moderne Etiketten sind mit einer LED und einer Taste ausgestattet, und die Engine kann Signale sowohl an Ihre Systeme als auch an das Regal zurücksenden. Ein Kommissionierer kann auf ein Etikett drücken, um eine Entnahme zu bestätigen oder einen Bestandsengpass zu melden, und dieses Ereignis wird an Ihr Bestands- oder Auftragsverwaltungssystem zurückgemeldet; bei einer „Click-and-Collect“-Bestellung können die Etiketten der Artikel auf der Liste aufleuchten, sodass das Personal sie in Sekundenschnelle findet. Das Prinzip ist dasselbe wie beim Ausgangsprozess – Ihre Systeme kommunizieren mit der Engine, die Engine kommuniziert mit den Etiketten –, nur in umgekehrter Richtung. Betrachten Sie den bidirektionalen Datenfluss als eine Funktion der zweiten Phase: Bei den meisten Einführungen wird zunächst die Preissynchronisation in Ausgangsrichtung getestet, und erst wenn die Grundlagen solide sind, werden Rückmeldungen hinzugefügt.

Was man einen Anbieter bezüglich des Integrationsaufwands und der Schnittstellen fragen sollte

Fragen Sie die Anbieter, wie sie eine Anbindung an Ihre spezifischen Systeme herstellen und wer die Arbeit übernimmt – vage Aussagen wie „lässt sich mit allem integrieren“ sind ein Warnsignal. Eine kurze, prägnante Checkliste:

Wie stellt man eine Verbindung zu unseren genauen POS / ERP her – per API, Datenbank oder Datei – und gibt es dafür einen vorgefertigten Konnektor oder eine individuelle Lösung?
Unterstützen Sie eine Synchronisierung nahezu in Echtzeit, geplante Batch-Verarbeitungen oder beides, und wie hoch ist die typische End-to-End-Latenz von einer Preisänderung bis zur Anzeige auf dem Etikett?
Welche Zugriffsrechte benötigen Sie von uns, und was ist der Unterschied zwischen Lesezugriff und Lese-/Schreibzugriff?
Wer ist für den Integrations-Build und die laufende Wartung zuständig – Sie, wir oder ein Dritter – und was passiert, wenn unser „ERP“ aktualisiert wird?
Wie gehen Sie mit versäumten Aktualisierungen und der Datenabgleichung um, damit ein Etikett niemals unbemerkt einen veralteten Preis anzeigt?
Wie sieht die Feldzuordnung aus, und wie werden Werbeaktionen mit Start- und Endzeiten sowie mehreren Preisarten gehandhabt?
Wie sieht der realistische Zeitplan aus und was wird während dieser Zeit von unserem Team erwartet?

Die Qualität der Antworten – spezifisch auf Ihre Technologieplattform zugeschnitten und ehrlich in Bezug auf den Aufwand – sagt mehr über einen Anbieter aus als jedes Datenblatt. Was die über die Integration hinausgehenden Kaufkriterien betrifft, decken das ROI-Framework und der Vergleich „ESL vs. paper“ die Kosten- und Betriebsseite ab, während der Leitfaden „ESL“ die Grundlagen behandelt.

Sehen Sie sich die Zuordnung zu Ihren eigenen Systemen an

Der schnellste Weg, um die Machbarkeit zu sichern, besteht darin, Ihre aktuelle Technologieumgebung offenzulegen. In einer Demo ordnen wir Ihre POS, ERP, Datenbank und E-Commerce-Lösung der Synchronisierungs-Engine zu, zeigen Ihnen, welches Verbindungsmodell am besten passt, und vermitteln Ihnen ein klares Bild vom einmaligen Aufwand – damit Sie das Projekt genehmigen können, wobei Sie genau wissen, was Ihr Team tun muss und was es nie wieder tun muss.