Insights Tracking
Ein veraltetes Ausgabemanagementsystem, an dessen Bedienung sich fast niemand mehr erinnern konnte. Ein Migrationspfad, der diese Abhängigkeit vollständig beseitigte – und den Weg für eine flexiblere Lösung ebnete.
Die Situation
Seit Jahren setzte ein großes nordisches Energieunternehmen den Columbus Output Manager (Columbus OM) als Schnittstelle zwischen SAP und seiner CCM-Plattform ein. Das Konzept war einfach: SAP erzeugte Druckdateien, Columbus OM fing diese ab, wandte die Weiterleitungslogik an und leitete sie zur Formatierung und Zustellung an das CCM-Tool weiter.
In der Praxis hatte sich die Infrastruktur zu einer Belastung entwickelt. Columbus OM war veraltet, nur unzureichend dokumentiert und – was entscheidend war – nur von einer Handvoll Personen wirklich verstanden. Wenn etwas ausfiel, erforderte die Fehlerdiagnose institutionelles Wissen, das immer schwerer zu finden war. Der Support durch den Anbieter war zurückgegangen. Jedes Wartungsfenster war mit Risiken verbunden.
Die Frage war nicht mehr, ob Columbus OM ersetzt werden sollte. Es ging vielmehr darum, womit man es ersetzen sollte – und wie man vermeiden konnte, eine anfällige Abhängigkeit gegen eine andere einzutauschen.
Die alte Architektur
Der ursprüngliche Ablauf sah folgendermaßen aus:
- SAP erstellt im Rahmen eines Geschäftsprozesses eine Spool-Datei (Druckausgabe) – eine Rechnung, eine Mitteilung, ein Dokument.
- Columbus OM ruft die Spulen-Datei ab und leitet sie gemäß den konfigurierten Regeln weiter.
- Die weitergeleitete Ausgabe wird zur Zusammenstellung und Zustellung an die CCM-Plattform weitergeleitet – oder direkt an einen physischen Drucker gesendet.
Es funktionierte lange Zeit. Doch die Routing-Logik war in Columbus OM integriert, was bedeutete, dass jede Änderung am Ausgabeverhalten Eingriffe in ein System erforderte, mit dem sich immer weniger Mitarbeiter wohlfühlten. Die CCM-Plattform war nicht erreichbar, ohne zuvor Columbus OM zu durchlaufen.
Die Alternative: SAPsprint + ENIT Flowbuilder
ENIT verfolgte den Ansatz, Columbus OM vollständig zu entfernen und seine beiden Kernfunktionen – die Erfassung von Spool-Dateien und die Weiterleitung der Ausgabe – durch einen schlankeren, transparenteren Stack zu ersetzen.
SAPsprint
SAPsprint ist ein von SAP bereitgestellter Windows-Dienst, der den älteren SAPlpd als Übertragungsprogramm für SAP-Druckausgaben in Microsoft Windows-Umgebungen ersetzt. Seine Aufgabe ist klar definiert: Wenn sich der SAP-Spool-Server und der Windows-Host-Spooler auf unterschiedlichen Rechnern befinden, fungiert SAPsprint als Brücke – er empfängt Druckdaten vom SAP-Spool-System und leitet sie an den Windows-Spooler weiter, der sie an den physischen Drucker übermittelt.
Es verarbeitet den SAPWIN-Datenstrom nativ und wandelt ihn in GDI-Aufrufe um, die von Windows-Druckertreibern verarbeitet werden können. Im Vergleich zu SAPlpd ist SAPsprint ausfallsicherer – Fehler auf einem Gerät blockieren nicht die Ausgabe auf anderen Geräten, und es ist standardmäßig so konfiguriert, dass es nach einem Ausfall automatisch neu startet. Für den Kunden bedeutete der Ersatz der Erfassungsfunktion von Columbus OM durch SAPsprint den Umstieg auf eine von SAP unterstützte, in Windows integrierte Komponente ohne Abhängigkeit von externen Anbietern.
ENIT Flowbuilder
Die Routing-Funktionen – die zuvor in Columbus OM verborgen waren – wurden mithilfe von ENIT Flowbuilder, dem hauseigenen Integrations- und Workflow-Tool von ENIT, neu aufgebaut. Flowbuilder wurde so konfiguriert, dass:
- Laden Sie die Spool-Datei von SAPsprint herunter, sobald sie verfügbar ist.
- Wende die Routing-Logik an, um das richtige Ziel zu ermitteln.
- Leiten Sie die Ausgabe an den physischen Drucker weiter – oder gegebenenfalls an die CCM-Plattform.
Da Flowbuilder einen visuellen, konfigurationsgesteuerten Ansatz verfolgt, sind die Routing-Regeln nun einsehbar, editierbar und liegen in der Verantwortung des Kundenteams – sie sind nicht mehr in einer Blackbox eingeschlossen.
Was die alte Konfiguration nie bot, war Observability. Jeder von SAP generierte Druckauftrag wird nun protokolliert und an die Überwachungstools des Kunden – Splunk und New Relic – weitergeleitet, wo er mit den tatsächlich über alle Ausgabekanäle gelieferten Daten abgeglichen wird. Wenn SAP 1.200 zum Druck gesendete Rechnungen erfasst und die nachgelagerten Kanäle 1.198 ausweisen, wird diese Diskrepanz sofort sichtbar. Früher war dies nicht der Fall. Damit wird eine seit langem bestehende Lücke geschlossen: die Möglichkeit, die von SAP gemeldeten Druckvorgänge mit den bestätigten Auslieferungen abzugleichen – sei es an einen physischen Drucker, ein digitales Archiv oder einen anderen Kanal.
Was hat sich geändert?
Das funktionale Ergebnis war dasselbe: Die von SAP generierten Dokumente erreichten ihren Bestimmungsort. Doch das operative Bild sah ganz anders aus:
- Columbus OM wurde außer Betrieb genommen, wodurch ein System ohne tragfähige Support-Struktur und mit lückenhaftem institutionellem Wissen abgeschafft wurde.
- Der neue Ablauf ist vollständig einsehbar – Flowbuilder stellt die Routing-Logik so dar, dass jeder Administrator sie nachvollziehen und ändern kann.
- SAPsprint ist in die SAP- und Windows-Umgebung integriert, wodurch die Spool-Übertragung zu einem standardmäßigen, unterstützten Vorgang wird und nicht mehr als separate Spezialfunktion betrachtet wird.
- Druckaufträge werden nun in Splunk und New Relic protokolliert, wodurch das Team einen lückenlosen Überblick vom SAP-Spool bis zur Ausgabedatei über alle Kanäle hinweg erhält.
- Das IT-Team des Kunden ist nun für die Konfiguration verantwortlich, wodurch die Abhängigkeit von externem Fachwissen bei alltäglichen Änderungen verringert wird.
Die Stilllegung von Columbus OM war nicht nur eine technische Migration. Es handelte sich um einen Wissenstransfer – die Verlagerung der Routing-Logik von einem undokumentierten Altsystem in eine Umgebung, die das Team tatsächlich einsehen, verwalten und überwachen konnte.
Ein Hinweis zu ENIT Flowbuilder
Dieses Projekt ist ein Beispiel dafür, wie ENIT Flowbuilder in CCM-Umgebungen eingesetzt wird. Es handelt sich dabei nicht um eine CCM-Plattform an sich – es wird neben Plattformen wie OpenText, Quadient und Smart Communications eingesetzt, um die Integrations- und Weiterleitungsaufgaben zu übernehmen, die diese Plattformen nicht von Haus aus bieten.
Zu den gängigen Anwendungsfällen gehören das Abrufen von Daten aus Quellsystemen wie SAP, die Anwendung bedingter Weiterleitung, die Transformation oder Anreicherung von Daten, bevor diese das CCM-Tool erreichen, sowie die Steuerung der Auslieferung an Drucker, Archive oder digitale Kanäle. Der Einsatz von Columbus OM passte perfekt: ein klar definiertes Weiterleitungsproblem, das eine wartungsfreundliche und überwachbare Lösung erforderte.
Abschließender Gedanke
Ältere Output-Management-Systeme bleiben oft länger im Einsatz, als sie sollten, weil ihre Ablösung als riskant empfunden wird. Columbus OM war schon seit Jahren im Einsatz – was den Eindruck von Stabilität vermittelte, obwohl das eigentliche Risiko darin bestand, dass niemand das System mehr vollständig verstand.
Für diesen Kunden wurden durch die Migration versteckte Abhängigkeiten beseitigt und durch etwas ersetzt, das das Team tatsächlich bedienen und überwachen konnte. Das ist oft das nachhaltigere Ergebnis: nicht nur das technische Problem zu lösen, sondern es so sichtbar zu machen, dass es beim nächsten Mal wieder gelöst werden kann.
