Möchten Sie OpenText auf Communications in der Cloud umstellen?

Hier ist der Kompromiss beim Zebradruck, den Sie kennen sollten.

OpenText On-Premise unterstützt die Ausgabe von Zebra-Etiketten (ZPL). Die Communications Cloud Edition tut dies nicht. Wenn der Zebra-Druck Teil Ihres Prozesses ist, sollten Sie dies vor der Migration einplanen.

OpenText ist eine leistungsstarke CCM-Plattform. Bei On-Premise-Implementierungen wird die ZPL-Ausgabe – die Sprache, die Zebra-Thermodrucker steuert – bereits seit langem als Teil eines umfassenden Portfolios an Ausgabekanälen unterstützt. Etiketten für Lager, Versand, klinische Umgebungen und Fertigungsbereiche: Der On-Premise-Stack ist dafür bestens gerüstet.

Bei der Cloud-Edition sieht die Sache anders aus. Die Ausgabe im ZPL-Format wird nicht unterstützt. Wenn Ihr Unternehmen im Rahmen seiner Dokumenten- oder Kommunikationsprozesse auf den Druck von Zebra-Etiketten angewiesen ist, steht Ihnen diese Funktion nach dem Umstieg auf OpenText nicht mehr zur Verfügung.

Das ist keine nebensächliche Randnotiz. Für Unternehmen, in denen der Etikettendruck eine wichtige Rolle im Betriebsablauf spielt, ist dies eine Lücke, für die ein Plan erforderlich ist, bevor die Migration beginnt – und nicht erst danach.

Warum dies bei Migrationsprojekten erst spät zutage tritt

Der Etikettendruck fällt in der Regel in den Zuständigkeitsbereich der operativen Abteilungen und nicht in den des Teams, das die CCM-Migration plant. Der CCM-Arbeitsbereich konzentriert sich auf kundenorientierte Ausgabedokumente: Briefe, Kontoauszüge, Rechnungen und digitale Zustellungen. Etiketten werden als logistische Angelegenheit betrachtet, die von einem separaten Team bearbeitet wird und oft auf einer Infrastruktur läuft, die deutlich älter ist als die CCM-Plattform.

Das Ergebnis ist, dass die ZPL-Fähigkeit als aktuelles Merkmal von Exstream On-Premise abgebildet wird, die Cloud-Edition anhand der für das Projektteam wichtigsten Aspekte der Dokumentenausgabe bewertet wird und die Lücke bei der Etikettenausgabe erst spät entdeckt wird – manchmal sogar erst, wenn die Planung für die Inbetriebnahme bereits im Gange ist.

An diesem Punkt stehen meist nur unbefriedigende Optionen zur Auswahl: die Migration verzögern, in ein separates Etikettenverwaltungssystem investieren oder eine manuelle Notlösung akzeptieren, die genau die betriebliche Komplexität wieder einführt, die man eigentlich beseitigen wollte.

Was diese Lücke tatsächlich für Ihre Architektur bedeutet

ZPL (Zebra Programming Language) ist der Standard für den Thermodruck von Etiketten. Die Sprache deckt alle Anforderungen des Etikettendrucks ab: variable Textfelder, Adressblöcke, Chargennummern, Verfallsdaten, Konformitätskennzeichnungen, Logos, grafische Layoutelemente und – ganz entscheidend – Barcodes und QR-Codes, die direkt auf der Druckerhardware generiert werden.

Wenn Ihre CCM-Plattform kein ZPL mehr generieren kann, tritt in der Regel einer der folgenden drei Fälle ein:

• Der Etikettierungsprozess wird vollständig von der CCM-Ebene entkoppelt und an ein eigenständiges Etikettenverwaltungssystem übertragen – was eine doppelte Erfassung von Daten, Logik und Integrationsarbeit bedeutet
• Ein Entwickler erstellt einen benutzerdefinierten ZPL-Generator, der außerhalb der Plattform läuft – was zunächst gut funktioniert, bis es irgendwann nicht mehr klappt und zu einem Wartungsaufwand wird
• Die Etikettierungsanforderung wird zurückgestellt oder manuell bearbeitet – was bei den üblichen Arbeitsmengen selten tragbar ist

Keine dieser Antworten ist richtig. Die richtige Lösung besteht darin, die Lücke auf der Integrationsebene zu schließen – und zwar mit einem Tool, das speziell für diese Art der Prozessorchestrierung entwickelt wurde.

Wie ENIT Flowbuilder die Lücke schließt

ENIT Flowbuilder ist eine Low-Code-Integrationsplattform, die genau für diese Art der Prozessorchestrierung entwickelt wurde. Sie ist nicht auf einen bestimmten Ausgabetyp beschränkt – sie kann strukturierte Daten aus beliebigen Quellen verarbeiten und an jeden beliebigen Ausgabekanal weiterleiten, einschließlich eines korrekt formatierten ZPL-Datenstroms, der direkt an einen Zebra-Drucker oder einen Endpunkt für die Etikettenverwaltung gesendet wird.

Für die Erstellung von Etiketten übernimmt ein Flowbuilder-Flow die gesamte Aufgabe:

• Aus Quelldaten gefüllte Textfelder – Namen, Adressen, Produktcodes, Chargennummern, Verfallsdaten
• Grafische Elemente und Strukturen der Beschriftungsanordnung
• Bilder – Logos, Compliance-Symbole, Produktbilder – in der richtigen Auflösung für den Thermodruck
• Barcodes und QR-Codes: Code 128, EAN-13, DataMatrix, QR und andere gängige Standards
• Korrekt formatierte ZPL-Ausgabe, bereit zum direkten Drucken oder zur Weiterleitung an nachfolgende Systeme

Entscheidend ist, dass hierfür kein Austausch OpenText erforderlich ist. Die Architektur ist additiv: Die Communications Cloud übernimmt weiterhin die Ausgabe von kundenorientierten Dokumenten, während Flowbuilder die Kanäle abdeckt, die die Cloud-Edition nicht erreicht. Beide beziehen ihre Daten aus demselben vorgelagerten Datenereignis. Die Lücke bei der Etikettenerstellung wird geschlossen, ohne dass ein neues Silo oder eine parallele CCM-Investition erforderlich wird.

Das Gespräch über Migration, das man frühzeitig führen sollte

Wenn Ihr Unternehmen einen Wechsel von der On-Premise-Version von Exstream zur Cloud-Edition in Erwägung zieht – oder wenn dieser Prozess bereits läuft –, lohnt es sich, die Frage nach der Etikettenausgabe jetzt anzusprechen. Folgende Fragen sollten Sie sich stellen:

• Welche Geschäftsprozesse sind derzeit von der ZPL-Ausgabe von Exstream On-Premise abhängig?
• Sind diese Prozesse geschäftskritisch oder fallen sie so geringfügig aus, dass sie anders gehandhabt werden können?
• Woher stammen die Daten für die Etikettenerstellung – und werden diese bereits über Ihre Integrationsschicht geleitet?
• Wie sieht eine reibungslose Übergabe der Verantwortung für die Etiketten aus, und wer ist nach der Migration dafür zuständig?

Diese Antworten bereits vor Abschluss der Migrationsplanung zu erhalten, ist deutlich kostengünstiger, als die Lücke erst während der Benutzerakzeptanztests zu entdecken.

Der übergeordnete Zusammenhang für Architekten und Prozessverantwortliche

Die Cloud-Migration von CCM-Plattformen für Unternehmen ist kein einfacher, eins-zu-eins-Übertragungsprozess. Funktionen, die im On-Premise-Stack vorhanden sind – Ausgabekanäle, Treiberunterstützung, Integrationsmuster – sind in der Cloud-Version möglicherweise nicht vorhanden, und dies geht aus der Dokumentation nicht immer eindeutig hervor.

Die ZPL-Unterstützung in OpenText ist ein konkretes Beispiel dafür. Das Prinzip lässt sich verallgemeinern: Bevor Sie sich für eine CCM-Migration in die Cloud entscheiden, sollten Sie Ihre aktuellen Ausgabekanäle mit den tatsächlichen Funktionen der Cloud-Plattform abgleichen – und nicht mit deren Marketingmaterialien.

Wo Lücken bestehen, lassen sie sich schließen – doch dies muss auf Architekturebene geschehen, und zwar mit den richtigen Werkzeugen, noch bevor die Migration abgeschlossen ist. Die nachträgliche Integration von Ausgabemöglichkeiten nach der Inbetriebnahme ist immer teurer als deren Einplanung im Vorfeld.

ENIT Flowbuilder ist ein Teil dieser Lösung. Wenn Sie dies für OpenText, Quadient, Smart Communications oder eine andere CCM-Plattform umsetzen, zeigen wir Ihnen gerne, wie das in Ihrer konkreten Umgebung aussieht.