Skip to Main Content
Levi, Ray & Shoup, Inc.

PAAS - Ein echter Fall in einem Handelsunternehmen

Language Options

Vor einiger Zeit habe ich einen Blog über Printing as a Service (PAAS) von meinem Kollegen Brent Black gelesen. Damals hätte ich nie erwartet, an einem Projekt rund um das Thema PAAS beteiligt zu sein. Dies hat sich durch ein aktuelles Kundenbeispiel geändert. Die Zielsetzung des Unternehmens waren eine flexible Anpassung an neue Anforderungen und eine Vereinfachung der Druckinfrastruktur.

Das Handelsunternehmen wandte sich an uns, weil es eine neue Java-Anwendung entwickelte. Diese Anwendung erstellt Dokumente anhand von typischen Java-Bibliotheken zur Zusammenstellung von Dokumenten, wie iText oder Crystal Reports. Die Java-Bibliotheken produzieren Dokumente im PDF-Format, was nicht immer das beste Format für den Druck ist. Die verschiedenen Dokumententypen, wie Rechnungen und Verkaufsscheine, enthalten diverse Papierformate (A4, A5, A6) mit unterschiedlichen Schriftarten und Stilen. All diese Dokumente müssen auf tausend verschiedenen Druckgeräten von unterschiedlichen Herstellern druckbar sein und die verschiedenen Drucksprachen von Laserdruckern, Thermodruckern, etc. unterstützen.

Dieses komplexe Szenario würde einen hohen Entwicklungsaufwand erfordern. Abgesehen von der Erstellung einer geeigneten Java-Anwendung zur Verwaltung der Informationen müsste die Applikation steuern, wo das Dokument gedruckt und wie die entsprechenden Dokumentenformate für jeden Gerätetyp generiert werden sollen. Dazu gehört die Auswahl der richtigen Druckersprache sowie der entsprechenden Druckerbefehle für jede Druckermarke oder jedes Modell. Beispielsweise würde die Erstellung von Dokumenten für verschiedene Papierformate eine Integration von diversen Druckerbefehlen zur Auswahl des geeigneten Druckerschachts erfordern. Dadurch besteht die Gefahr, dass die Anwendung immer komplexer und schwieriger zu pflegen wird, wenn neue Drucker hinzugefügt oder neue Dokumentenformate erstellt werden.

Wie viele andere Handelsunternehmen nutzt auch dieser Kunde den Ausdruck, um das Einkaufserlebnis des Kunden zu steigern. Bei der Erstellung eines Kaufbelegs werden im Rahmen des Verkaufsvorgangs auch eine Reihe von Rabattcoupons und Werbemaßnahmen gedruckt. Diese Belege sind so konzipiert, dass sie beim Verkauf vom Thermodrucker individuell gedruckt und zugeschnitten werden. Im Gegensatz zu anderen Ausgabegeräten verwenden solche Drucker keine Standarddrucksprachen, sondern eine spezielle Seitenbeschreibungssprache (PDL), die hauptsächlich für den Etikettendruck verwendet wird. Der Händler hat weitere Neuerungen eingeführt, wie z.B. ein kundenorientiertes Fachpersonal mit PDA-Geräten zur Unterstützung des Verkaufs. Somit kann das Personal den Kunden auf der Suche nach Produkten belgleiten und Artikel spontan in die Kundenbestellung aufnehmen. Wenn der Kunde mit dem Einkauf fertig ist, bringt der Verkäufer den PDA in die Nähe des Druckers, wo alle Belege gedruckt werden. Mithilfe der NFC-Technologie wird der Drucker identifiziert und die Java-Anwendung angewiesen, alle Belege an den ausgewählten Drucker zu senden.

Zweifellos machen all diese Anforderungen im Laufe der Zeit die Anwendung schwieriger und teurer in der Entwicklung und Wartung.

Aber was wäre, wenn wir alle diese Funktionen auf eine bestimmte Infrastrukturebene verlagern, die den Rest des Systems von diesen druckbezogenen Aufgaben entlasten würde? In den letzten Jahren haben wir von vielen dieser Dienste gehört und gelesen - oft über das Internet und weniger über lokale bzw. on-site Dienste -  bei denen die Software auf Abonnementbasis lizenziert wird.

Wenden Sie nun dieses Konzept auf den Druck an. Man kann sich leicht vorstellen, dass ein Dienst als einzelne Middleware-Architektur läuft, die mit verschiedenen Anwendungen kommuniziert. Diese Anwendungen können auf Windows, UNIX, Linux oder anderen Plattformen ausgeführt werden und jede Art von Dokument an eine Vielzahl von Druckern liefern. Die Middleware muss das ursprünglich erstellte Format in ein druckfertiges Formular konvertieren, welches für das Zielgerät geeignet ist. Eine solche Lösung vereinfacht die Anwendungen drastisch und macht sie langfristig wartungsfreundlicher.

Zurück zum Kundenbeispiel.... Mit der LRS Output-Management-Software werden die Anwendungen, die Dokumente in verschiedenen Formaten und PDLs produzieren, von der Druckbelastung befreit. Es müssen nur die Dokumentdaten und die ID des Zieldruckers übergeben werden. Des Weiteren besteht keine Notwendigkeit, sich Gedanken über die unterstützen Druckersprachen, das Hinzufügen von speziellen geräteabhängigen Befehlen zur Festlegung des entsprechenden Eingabefachs zu machen und auch nicht mehr zu prüfen, ob das Dokument korrekt gedruckt wurde. All diese Aufgaben können von der LRS-Software über eine der vielen mitgelieferten APIs erledigt werden. Diese APIs können nicht nur zum Senden des Dokuments verwendet werden, sondern auch um sicherzustellen, dass die richtigen Dokumente rechtzeitig und passend zum Abschluss des Geschäftsprozesses geliefert werden. Wenn neue Druckermodelle in die Flotte aufgenommen werden, müssen diese nur in der LRS-Software hinzugefügt werden und stehen anschließend direkt zum Druck bereit.

Beim Drucken der Verkaufsbelege über den PDA des Mitarbeiters konvertiert die LRS Software die Informationen in eine PDL, damit diese mit dem POS-Thermodrucker verarbeitet werden können. Außerdem bündelt es den Verkaufsbeleg und die zugehörigen Coupons oder Werbemaßnahmen in einem einzigen Dokument. Auf diese Weise muss die Anwendung nicht nachverfolgen, welche Belege für welche Transaktion freigegeben wurden. Senden Sie einfach jeden Beleg an die LRS-Lösung (zusammen mit der zugehörigen Transaktions-ID) und lassen Sie die LRS-Software alle Belege zusammenführen, sobald die letzten Daten empfangen wurden. Ebenfalls können durch die LRS-Software spezielle Befehle hinzufügt werden, damit der Drucker das Papier nach jedem einzelnen Beleg zuschneidet. Wenn der Verkäufer also jetzt mit seinem PDA zum Drucker geht, sind die Belege bereit, ohne Verzögerung an den Drucker übermittelt und in einem einzigen Bündel zusammengefasst zu werden. Dadurch wird sichergestellt, dass jeder Verkäufer nur die Belege erhält, die er erwartet.

Dieses Beispiel zeigt, wie der Einsatz der LRS Software as a Service für den Druck die Anwendungsentwicklung, durch Reduzierung der Aufgaben-Anzahl und bessere Steuerung des Dokumentenflusses, vereinfachen kann. Die Vorteile erstrecken sich auch auf andere Systeme, da alle LRS-definierten Drucker auch für andere Anwendungen auf verschiedenen Plattformen verfügbar sind. Die LRS-Lösung richtet ein zentrales Treiber-Repository und einen Mechanismus ein, der zur Nachverfolgung des Druckverhaltens (wer was druckt) und Einhaltung der Druckrichtlinien zur Reduzierung von Papierabfall dienen soll. Kurz gesagt, dieser Printing as a Service-Ansatz etabliert eine neue Art des Druckens, die einen zentralen Kontrollpunkt für alle Dokumente eines Unternehmens bietet.

Das ist noch nicht alles. Wir alle haben Erfahrungen mit Unternehmen gemacht, die den Versand von Belegen per E-Mail anstatt Druck bevorzugen - für den Anbieter ist es billiger, für den Kunden einfacher und für die Umwelt besser. Die Umstellung bestehender Anwendungen auf die elektronische Dokumentenübermittlung kann kompliziert sein, wenn Druckfunktionen in der Anwendung fest programmiert sind. Wenn Sie jedoch die Methodik von Printing as a Service bereits übernommen haben, ist es einfach, einige Änderungen an der Konfiguration vorzunehmen.

Stellen Sie sich die Vorteile dieses serviceorientierten Druckansatzes für Ihr Unternehmen vor. Und jetzt hören Sie auf zu träumen und fangen Sie an zu handeln. Es ist an der Zeit, dies zu verwirklichen und LRS kann Ihnen bei diesem Projekt helfen.

Back to Posts