Insights
CCM
Ett äldre system för utskriftshantering som nästan ingen kom ihåg hur man körde. En migreringsväg som helt eliminerade beroendet – och öppnade dörren för något mer flexibelt.
Situationen
I åratal hade ett stort nordiskt energibolag använt Columbus Output Manager (Columbus OM) som brygga mellan SAP och dess CCM-plattform. Upplägget var enkelt i konceptet: SAP genererade utskriftsfiler, Columbus OM fångade upp dem, tillämpade dirigeringslogik och överlämnade dem till CCM-verktyget för formatering och leverans.
I praktiken hade upplägget blivit en belastning. Columbus OM var åldrande, sparsamt dokumenterat och – kritiskt – djupt förstått av endast en handfull människor. När något gick sönder krävdes institutionell kunskap för att diagnostisera det, kunskap som blev allt svårare att hitta. Leverantörsstödet hade minskat. Varje underhållsfönster medförde risker.
Frågan var inte längre om man skulle ersätta Columbus OM. Det var vad man skulle ersätta det med – och hur man skulle undvika att byta ett bräckligt beroende mot ett annat.
Den gamla arkitekturen
Det ursprungliga flödet såg ut så här:
- SAP genererar en spool-fil (utskriftsutdata) som en del av en affärsprocess – en faktura, ett meddelande, ett dokument.
- Columbus OM hämtar spool-filen och dirigerar den baserat på konfigurerade regler.
- Den dirigerade utdatan skickas till CCM-plattformen för komposition och leverans – eller skickas direkt till en fysisk skrivare.
Det fungerade länge. Men dirigeringslogiken fanns inuti Columbus OM, vilket innebar att varje ändring av utskriftsbeteendet krävde att man rörde ett system som färre och färre människor var bekväma med. CCM-plattformen kunde inte nås utan att först gå via Columbus OM.
Ersättningen: SAPsprint + ENIT Flowbuilder
ENITs strategi var att helt ta bort Columbus OM och ersätta dess två kärnfunktioner – fångst av spoolfiler och utskriftsdirigering – med en smidigare och mer transparent arkitektur.
SAPsprint
SAPsprint är en SAP-tillhandahållen Windows-tjänst som ersätter den äldre SAPlpd som överföringsprogram för SAP-utskrifter i Microsoft Windows-miljöer. Dess roll är specifik: när SAP-spoolservern och Windows-värdspoolern finns på olika maskiner, fungerar SAPsprint som en brygga – som tar emot utskriftsdata från SAP-spoolsystemet och vidarebefordrar dem till Windows-spoolern för leverans till den fysiska skrivaren.
Den hanterar SAPWIN-dataströmmar nativt och konverterar dem till GDI-anrop som Windows-skrivardrivrutiner kan bearbeta. Jämfört med SAPlpd är SAPsprint mer robust – fel på en enhet blockerar inte utskrifter till andra, och den är som standard konfigurerad att starta om automatiskt efter ett fel. För kunden innebar att ersätta Columbus OM:s fångstfunktion med SAPsprint att man gick över till en SAP-stödd, Windows-integrerad komponent utan beroende av externa leverantörer.
ENIT Flowbuilder
Routningsintelligensen – tidigare dold i Columbus OM – byggdes om med hjälp av ENIT Flowbuilder, ENITs eget verktyg för integration och arbetsflöden. Flowbuilder konfigurerades för att:
- Hämta spoolfilen från SAPsprint så snart den blev tillgänglig.
- Tillämpa routningslogik för att bestämma rätt destination.
- Vidarebefordra utskriften till den fysiska skrivaren – eller, i förekommande fall, vidare till CCM-plattformen.
Eftersom Flowbuilder använder en visuell, konfigurationsdriven metod är routningsreglerna nu synliga, redigerbara och ägs av kundens team – inte inlåsta i en svart låda.
Vad den gamla installationen aldrig erbjöd var observerbarhet. Varje utskriftsjobb som SAP genererar loggas nu och vidarebefordras till kundens övervakningsverktyg – Splunk och New Relic – där det spåras mot vad som faktiskt levererats över alla utskriftskanaler. Om SAP registrerar 1 200 fakturor som skickats till utskrift och de nedströms kanalerna redovisar 1 198, är den skillnaden omedelbart synlig. Tidigare var den inte det. Detta täpper till en långvarig blind fläck: förmågan att matcha vad SAP säger att det har skrivit ut mot vad som bekräftats levererat – oavsett om det är till en fysisk skrivare, ett digitalt arkiv eller någon annan kanal.
Vad som ändrades
Det funktionella resultatet var detsamma: SAP-genererade dokument nådde sin destination. Men den operativa bilden var markant annorlunda:
- Columbus OM avvecklades, vilket eliminerade ett system utan en hållbar supportväg och med bräcklig institutionell kunskap.
- Det nya flödet är helt synligt – Flowbuilder visar routningslogiken på ett sätt som varje administratör kan följa och ändra.
- SAPsprint ligger inom SAP- och Windows-landskapet, vilket gör spoolöverföring till en standardiserad, stödd operation snarare än en separat specialitet.
- Utskriftsjobb loggas nu till Splunk och New Relic, vilket ger teamet end-to-end-synlighet från SAP-spool till levererad utskrift över alla kanaler.
- Kundens IT-team äger nu konfigurationen, vilket minskar beroendet av extern expertis för dagliga ändringar.
Avvecklingen av Columbus OM var inte bara en teknisk migrering. Det var en kunskapsöverföring – att flytta routningslogik från ett odokumenterat äldre system till något som teamet faktiskt kunde se, hantera och övervaka.
En anmärkning om ENIT Flowbuilder
Detta projekt är ett exempel på hur ENIT Flowbuilder tillämpas i CCM-miljöer. Det är inte en CCM-plattform i sig – utan det fungerar tillsammans med plattformar som opentext, Quadient och Smart Communications för att hantera integrations- och routningsarbetet som dessa plattformar inte hanterar nativt.
Vanliga användningsfall inkluderar att hämta utskrifter från källsystem som SAP, tillämpa villkorlig routning, transformera eller berika data innan de når CCM-verktyget, och hantera leverans till skrivare, arkiv eller digitala kanaler. Ersättningen av Columbus OM passade perfekt: ett väldefinierat routningsproblem som krävde en underhållbar och observerbar lösning.
Slutord
Äldre system för utskriftshantering tenderar att överleva längre än de borde eftersom det känns riskabelt att ersätta dem. Columbus OM hade varit i drift i åratal – vilket fick det att kännas stabilt, även när den verkliga risken var att ingen längre förstod det fullt ut.
För denna kund tog migreringen bort ett tyst beroende och ersatte det med något som teamet faktiskt kunde hantera och observera. Det är ofta det mer hållbara resultatet: inte bara att lösa det tekniska problemet, utan att göra det tillräckligt synligt så att någon kan lösa det igen nästa gång.
