Insights
Tracking
Un ancien système de gestion des sorties dont presque plus personne ne savait comment se servir. Une stratégie de migration qui a complètement éliminé cette dépendance — et ouvert la voie à une solution plus flexible.
La situation
Depuis des années, une grande entreprise énergétique nordique utilisait Columbus Output Manager (Columbus OM) comme passerelle entre SAP et sa plateforme CCM. Le principe était simple : SAP générait des fichiers d'impression, Columbus OM les interceptait, appliquait la logique de routage, puis les transmettait à l'outil CCM pour la mise en forme et la diffusion.
Dans la pratique, cette configuration était devenue un véritable handicap. Columbus OM commençait à dater, était peu documenté et, surtout, n’était maîtrisé en profondeur que par une poignée de personnes. En cas de panne, le diagnostic exigeait un savoir-faire institutionnel de plus en plus difficile à trouver. L’assistance du fournisseur s’était réduite. Chaque fenêtre de maintenance comportait un risque.
La question n'était plus de savoir s'il fallait remplacer Columbus OM, mais par quoi le remplacer — et comment éviter de troquer une dépendance fragile contre une autre.
L'architecture ancienne
Le flux initial se présentait comme suit :
- SAP génère un fichier spool (fichier d'impression) dans le cadre d'un processus métier — une facture, un avis, un document.
- Columbus OM récupère le fichier de file d'attente et le transfère conformément aux règles configurées.
- La sortie acheminée est transmise à la plateforme CCM pour être assemblée et diffusée — ou envoyée directement à une imprimante physique.
Cela a fonctionné pendant longtemps. Mais la logique de routage était intégrée à Columbus OM, ce qui signifiait que toute modification du comportement de sortie nécessitait d'intervenir sur un système avec lequel de moins en moins de personnes se sentaient à l'aise. Il était impossible d'accéder à la plateforme CCM sans passer d'abord par Columbus OM.
La solution de remplacement : SAPsprint + ENIT Flowbuilder
L'approche d'ENIT consistait à supprimer complètement Columbus OM et à remplacer ses deux fonctions principales — la capture des fichiers de spool et l'acheminement des sorties — par une pile plus légère et plus transparente.
SAPsprint
SAPsprint est un service Windows fourni par SAP qui remplace l'ancien SAPlpd en tant que programme de transfert pour les sorties d'impression SAP dans les environnements Microsoft Windows. Son rôle est bien défini : lorsque le serveur de spool SAP et le spouleur hôte Windows se trouvent sur des machines différentes, SAPsprint sert de passerelle : il reçoit les données d'impression du système de spool SAP et les transmet au spouleur Windows pour qu'elles soient envoyées à l'imprimante physique.
Il gère nativement le flux de données SAPWIN en le convertissant en appels GDI que les pilotes d'imprimante Windows peuvent traiter. Comparé à SAPlpd, SAPsprint est plus résilient : les erreurs sur un périphérique ne bloquent pas la sortie vers les autres, et il est configuré par défaut pour redémarrer automatiquement après une panne. Pour le client, le remplacement de la fonction de capture de Columbus OM par SAPsprint a signifié le passage à un composant pris en charge par SAP et intégré à Windows, sans dépendance vis-à-vis d'un fournisseur externe.
ENIT Flowbuilder
Les fonctionnalités de routage — auparavant intégrées à Columbus OM — ont été repensées à l'aide d'ENIT Flowbuilder, l'outil d'intégration et de gestion des flux de travail développé par ENIT. Flowbuilder a été configuré pour :
- Téléchargez le fichier de spool depuis SAPsprint dès qu'il est disponible.
- Appliquez la logique de routage pour déterminer la destination correcte.
- Transmettez le résultat à l'imprimante physique — ou, le cas échéant, à la plateforme CCM.
Comme Flowbuilder repose sur une approche visuelle et axée sur la configuration, les règles de routage sont désormais visibles, modifiables et gérées par l'équipe du client — elles ne sont plus enfermées dans une boîte noire.
Ce que l'ancienne configuration n'offrait pas, c'était l'observabilité. Chaque tâche d'impression générée par SAP est désormais enregistrée et transmise aux outils de surveillance du client — Splunk et New Relic — où elle est comparée à ce qui a été effectivement livré sur l'ensemble des canaux de sortie. Si SAP enregistre 1 200 factures envoyées à l'impression et que les canaux en aval en comptabilisent 1 198, cet écart est immédiatement visible. Auparavant, ce n'était pas le cas. Cela comble un angle mort de longue date : la capacité de faire correspondre ce que SAP déclare avoir imprimé avec ce qui a été confirmé comme livré — que ce soit vers une imprimante physique, une archive numérique ou tout autre canal.
Qu'est-ce qui a changé ?
Le résultat fonctionnel était le même : les documents générés par SAP sont bien parvenus à leur destinataire. Mais la situation opérationnelle était très différente :
- Le système Columbus OM a été mis hors service, ce qui a permis de supprimer un système ne bénéficiant d'aucune voie de support viable et dont le savoir-faire institutionnel était fragile.
- Le nouveau flux est entièrement visible : Flowbuilder présente la logique de routage de manière à ce que tout administrateur puisse la comprendre et la modifier.
- SAPsprint s'intègre dans l'environnement SAP et Windows, faisant ainsi du transfert de spools une opération standard prise en charge, plutôt qu'une fonctionnalité distincte.
- Les tâches d'impression sont désormais enregistrées dans Splunk et New Relic, ce qui offre à l'équipe une visibilité de bout en bout, depuis la file d'attente SAP jusqu'à la sortie des documents sur tous les canaux.
- L'équipe informatique du client est désormais responsable de la configuration, ce qui réduit le recours à des experts externes pour les modifications quotidiennes.
La mise hors service de Columbus OM n'était pas seulement une migration technique. Il s'agissait d'un transfert de connaissances : transférer la logique de routage d'un système hérité non documenté vers un environnement que l'équipe pouvait réellement visualiser, gérer et surveiller.
Remarque concernant ENIT Flowbuilder
Ce projet illustre la manière dont ENIT Flowbuilder est utilisé dans les environnements CCM. Il ne s'agit pas d'une plateforme CCM en soi : il vient compléter des plateformes telles OpenText, Quadient et Smart Communications pour prendre en charge les tâches d'intégration et de routage que ces dernières ne gèrent pas en natif.
Parmi les cas d'utilisation courants, on peut citer la récupération des données issues de systèmes sources tels que SAP, l'application d'un routage conditionnel, la transformation ou l'enrichissement des données avant leur arrivée dans l'outil de gestion de contenu client (CCM), ainsi que la gestion de la diffusion vers des imprimantes, des archives ou des canaux numériques. Le remplacement de Columbus OM s'est avéré être un choix tout à fait approprié : il s'agissait d'un problème de routage bien défini qui nécessitait une solution facile à maintenir et à surveiller.
Conclusion
Les anciens systèmes de gestion des sorties ont tendance à rester en service plus longtemps qu'ils ne le devraient, car leur remplacement semble risqué. Columbus OM fonctionnait depuis des années, ce qui donnait l'impression qu'il était stable, alors que le véritable risque était que plus personne ne le comprenait vraiment.
Pour ce client, la migration a permis de supprimer une dépendance cachée et de la remplacer par un élément que l'équipe pouvait réellement gérer et surveiller. C'est souvent là le résultat le plus durable : il ne s'agit pas seulement de résoudre le problème technique, mais aussi de le rendre suffisamment visible pour que quelqu'un puisse le résoudre à nouveau la prochaine fois.
