Pourquoi l'intégration d'un système legacy commence avant la signature
Un système legacy est rarement un problème en soi. Beaucoup gèrent encore la finance, les stocks et les commandes de manière fiable, et c'est pour cela que les entreprises les gardent. Mais ils ont été conçus avant que les boutiques en ligne et les PIM (product information management) attendent des données en direct à la demande. Ce décalage reste invisible jusqu'à ce qu'un nouveau système doive s'appuyer sur eux.
L'entreprise continue d'acheter autour du système qu'elle conserve. Elle ajoute peut-être une boutique en ligne pour un nouveau canal, un PIM pour un catalogue qui s'étoffe ou un WMS (warehouse management system) pour un second site. Chaque nouvel éditeur fait sa démo avec des données d'exemple propres et planifie comme si l'ancien système allait suivre.
S'il ne suit pas, deux décisions coûteuses s'imposent souvent : un remplacement de l'ERP que personne n'avait budgété, ou une liste restreinte réduite à ce que l'ancien ERP peut gérer. L'intégration d'un système legacy commence avant que l'une ou l'autre soit prise, avec des questions auxquelles seule l'équipe de l'entreprise peut répondre.
Ce que votre équipe doit établir sur l'intégration du système legacy
Six points déterminent ce que l'ancien système peut offrir à un nouveau. Aucun n'apparaît dans une démo d'éditeur, car chacun dépend de la façon dont ce système a été exploité.
- Le nouveau système hérite des anciens identifiants : références articles, codes clients et structures de listes de prix ont été définis dans l'ancien ERP. Demandez lesquels la nouvelle boutique ou le PIM doit reprendre et lesquels il peut mapper.
- Le nouvel éditeur suppose des choses que l'ancien système ne fait peut-être pas : une démo de boutique suppose un stock à jour et des commandes réécrites directement. Demandez si l'ancien ERP sait faire l'un ou l'autre, ou s'il met à jour le stock par un traitement nocturne.
- Les codes de statut veulent dire ce que des années d'usage en ont fait : un code créé pour « on hold » peut aujourd'hui signifier « en attente de contrôle de crédit ». Un nouveau système le lira au pied de la lettre, alors interrogez les personnes qui l'utilisent.
- L'ancien système ne supporte qu'un volume de lectures limité : la clôture mensuelle, le traitement nocturne et un matériel vieux de dix ans limitent la fréquence à laquelle on peut l'interroger. Demandez à l'informatique quand il peut être lu sans ralentir ses utilisateurs.
- Tout ce qui vient de l'extérieur du réseau doit être autorisé : un ERP on-premise se trouve généralement derrière un pare-feu pour de bonnes raisons. Demandez qui décide comment une plateforme externe y accède, et à quelles conditions.
- Personne hors de l'entreprise ne peut approuver une modification : le nouveau système aura peut-être besoin d'un champ supplémentaire, comme une date de livraison promise. Demandez qui peut autoriser une modification dans l'ancien système.
Les six réponses relèvent de la première étape d'un projet système, vue depuis le système qui reste. Tout ce qui suit cette étape, jusqu'à la question de savoir qui gère les intégrations après la mise en ligne, figure dans la checklist d'intégration. Les identifiants et les hypothèses des éditeurs sont généralement ce qui modifie le plus le périmètre.
Comment l'intégration d'un système legacy modifie-t-elle le périmètre du nouveau logiciel ?
Le périmètre d'un nouveau système est rédigé par son éditeur, à partir de ses propres hypothèses. L'intégration d'un système legacy réécrit une partie de ce périmètre tant qu'il est encore négociable.
Si l'ancien ERP ne met à jour le stock que la nuit, la boutique affiche un chiffre du matin, et la promesse de livraison au moment du paiement doit en tenir compte.
La voie la plus rapide pour intégrer des systèmes legacy est souvent un script écrit directement sur l'ancienne base de données. Cela fonctionne, mais sa logique réside dans un code que seul son auteur connaît, et l'éditeur de l'ERP ne prend peut-être pas en charge ce type d'accès. Une plateforme d'intégration offre une troisième voie, entre remplacer l'ERP et le contourner.
Comment une plateforme d'intégration connecte le système que vous conservez
Un iPaaS (integration Platform as a Service) est un hub central dans le cloud auquel une entreprise connecte ses systèmes un par un. Il transforme les données dans le format attendu par chaque système et automatise l'échange des commandes, des stocks et des données produit, en temps réel ou selon un planning, au lieu d'un lien distinct pour chaque paire.
Pour une entreprise qui conserve son ERP, cela change la décision d'achat. La nouvelle boutique ou le nouveau PIM se connecte au hub, pas à l'ERP. Il peut être choisi selon les besoins de l'entreprise, et non selon ce que l'ancien ERP peut gérer. Là où les deux ne concordent pas, l'écart peut être résolu dans le hub, et l'ERP lui-même reste généralement tel quel.
La plateforme d'intégration Alumio offre des fonctionnalités configurables pour résoudre ces écarts :
- Les commandes web arrivent en comptabilité sans ressaisie : une Route peut être construite de la boutique vers l'ERP pour livrer chaque commande dans un format que l'ERP accepte.
- Les clients voient le stock que détient l'ERP : une Route entre l'ERP et la boutique peut transmettre le stock aussi souvent que l'ERP le supporte.
- Le nouveau catalogue garde les anciens codes en état de marche : un Transformer entre l'ERP et la boutique peut mapper les références articles et traduire des codes de statut comme « on hold ».
- Un champ manquant peut venir de l'extérieur de l'ERP : une Route peut combiner des données de l'ERP et de l'entrepôt pour fournir à la boutique une date de livraison promise.
B&S International, distributeur de biens de consommation, a connecté son ERP sur mesure à Akeneo PIM et Adobe Commerce via Alumio. Des tâches de données qui prenaient des semaines prennent désormais quelques jours, et ses business analysts ajustent eux-mêmes les flux.
Comment l'intégration d'un système legacy protège la prochaine mise en ligne
Un ERP legacy qui gère encore bien la finance est un atout. Il ne devient un handicap que lorsque les logiciels achetés autour de lui sont planifiés sur des hypothèses que personne n'a vérifiées. Le coût se traduit alors par une mise en ligne retardée.
L'intégration d'un système legacy menée avant la signature change cela. Établir ce que l'ancien système peut ou non fournir transforme les hypothèses du nouvel éditeur en un périmètre sur lequel il peut planifier. Une plateforme d'intégration donne ensuite à l'ancien ERP et à la nouvelle boutique un seul endroit pour échanger commandes, stocks et données produit.
Elle laisse aussi la décision suivante ouverte. Le moment venu de remplacer l'ERP, la plateforme peut faire tourner l'ancien et le nouveau côte à côte au fil d'une migration de système legacy par étapes. La boutique peut être mise en ligne selon le plan pour lequel elle a été achetée, et l'ERP est remplacé quand l'entreprise le décide, pas quand un nouveau système l'impose.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
