Insights CCM
A legacy output management system that almost no one remembered how to run. A migration path that removed the dependency entirely — and opened the door to something more flexible.
The Situation
For years, a large Nordic energy company had been running Columbus Output Manager (Columbus OM) as the bridge between SAP and its CCM platform. The setup was straightforward in concept: SAP generated print files, Columbus OM intercepted them, applied routing logic, and handed them off to the CCM tool for formatting and delivery.
In practice, the setup had become a liability. Columbus OM was ageing, lightly documented, and — critically — understood in depth by only a handful of people. When something broke, diagnosing it required institutional knowledge that was increasingly hard to find. Vendor support had thinned. Every maintenance window came with risk.
The question was no longer whether to replace Columbus OM. It was what to replace it with — and how to avoid trading one fragile dependency for another.
The Old Architecture
The original flow looked like this:
- SAP generates a spool file (print output) as part of a business process — an invoice, a notice, a document.
- Columbus OM picks up the spool file and routes it based on configured rules.
- The routed output is passed to the CCM platform for composition and delivery — or sent directly to a physical printer.
It worked, for a long time. But the routing logic lived inside Columbus OM, which meant any change to output behaviour required touching a system that fewer and fewer people were comfortable with. The CCM platform could not be reached without going through Columbus OM first.
The Replacement: SAPsprint + ENIT Flowbuilder
ENIT's approach was to remove Columbus OM entirely and replace its two core functions — spool file capture and output routing — with a leaner, more transparent stack.
SAPsprint
SAPsprint is a SAP-provided Windows service that replaces the older SAPlpd as the transfer program for SAP print output on Microsoft Windows environments. Its role is specific: when the SAP spool server and the Windows host spooler are on different machines, SAPsprint acts as the bridge — receiving print data from the SAP spool system and forwarding it to the Windows spooler for delivery to the physical printer.
It handles the SAPWIN data stream natively, converting it to GDI calls that Windows printer drivers can process. Compared to SAPlpd, SAPsprint is more resilient — errors on one device don't block output to others, and it is configured by default to restart automatically after a failure. For the customer, replacing Columbus OM's capture function with SAPsprint meant moving to a SAP-supported, Windows-integrated component with no external vendor dependency.
ENIT Flowbuilder
The routing intelligence — previously buried in Columbus OM — was rebuilt using ENIT Flowbuilder, ENIT's own integration and workflow tooling. Flowbuilder was configured to:
- Fetch the spool file from SAPsprint once it became available.
- Apply routing logic to determine the correct destination.
- Forward the output to the physical printer — or, where applicable, onward to the CCM platform.
Because Flowbuilder uses a visual, configuration-driven approach, the routing rules are now visible, editable, and owned by the customer's team — not locked inside a black box.
What the old setup never provided was observability. Every print job that SAP generates is now logged and forwarded to the customer's monitoring tools — Splunk and New Relic — where it is tracked against what was actually delivered across all output channels. If SAP records 1,200 invoices sent to print and the downstream channels account for 1,198, that gap is visible immediately. Previously, it wasn't. This closes a longstanding blind spot: the ability to match what SAP says it printed against what was confirmed delivered — whether to a physical printer, a digital archive, or any other channel.
What Changed
The functional outcome was the same: SAP-generated documents reached their destination. But the operational picture was meaningfully different:
- Columbus OM was decommissioned, eliminating a system with no viable support path and fragile institutional knowledge.
- The new flow is fully visible — Flowbuilder surfaces the routing logic in a way that any administrator can follow and modify.
- SAPsprint sits within the SAP and Windows landscape, making spool transfer a standard, supported operation rather than a separate speciality.
- Print jobs are now logged to Splunk and New Relic, giving the team end-to-end visibility from SAP spool to delivered output across all channels.
- The customer's IT team now owns the configuration, reducing dependence on external expertise for day-to-day changes.
Decommissioning Columbus OM wasn't just a technical migration. It was a knowledge transfer — moving routing logic from an undocumented legacy system into something the team could actually see, manage, and monitor.
A Note on ENIT Flowbuilder
This project is one example of how ENIT Flowbuilder gets applied in CCM environments. It is not a CCM platform itself — it sits alongside platforms like OpenText, Quadient, and Smart Communications to handle the integration and routing work that those platforms don't own natively.
Common use cases include fetching output from source systems like SAP, applying conditional routing, transforming or enriching data before it reaches the CCM tool, and managing delivery to printers, archives, or digital channels. The Columbus OM replacement was a clean fit: a well-defined routing problem that needed a maintainable, observable solution.
Final Thought
Legacy output management systems tend to survive longer than they should because replacing them feels risky. Columbus OM had been running for years — which made it feel stable, even when the real risk was that no one fully understood it anymore.
For this customer, the migration removed a silent dependency and replaced it with something the team could actually operate and observe. That's often the more durable outcome: not just solving the technical problem, but making it visible enough that someone can solve it again next time.
