Pourquoi votre intégration EDI est liée à votre ancien ERP
Les connexions EDI (Electronic Data Interchange) semblent appartenir au partenaire. En pratique, elles appartiennent au système qui se trouve derrière.
Un client qui vous envoie un bon de commande l'envoie dans un format convenu, avec des identifiants convenus, vers un point de terminaison convenu. Ces identifiants viennent de votre ERP. Les références article, les codes clients, les conventions d'unités de mesure et les codes de TVA forment le vocabulaire de votre système, traduit une fois lors de la création de la connexion et figé depuis.
Cette traduction contient généralement quatre éléments :
- Identifiants produit : vos références article mappées sur les références catalogue du partenaire, article par article
- Codes partenaires et sites : quel client, quelle adresse de livraison, quelle agence, exprimés dans des codes émis par votre ERP
- Structure des documents : quels champs sont obligatoires dans une commande, un avis d'expédition ou une facture, et dans quel ordre
- Règles de validation : ce que le partenaire rejette, y compris les tolérances sur la quantité, le prix et la fenêtre de livraison
Dans la plupart des entreprises, rien de tout cela n'est documenté à un seul endroit. Tout se trouve dans la connexion elle-même et dans la mémoire de la personne qui l'a construite. Cela devient un problème dès que le système sous-jacent change.
Ce qui casse quand l'ERP sous-jacent change
Un nouvel ERP émet ses propres identifiants. Les références article changent, les codes clients changent, et le modèle de données sur lequel reposait le mapping d'origine n'existe plus.
La panne est rarement spectaculaire. Une commande arrive et est rejetée parce qu'un champ attendu par le partenaire est désormais vide. Une facture est acceptée puis contestée parce que le code de TVA est mappé différemment. Un avis d'expédition part avec une unité de mesure que le partenaire lit comme des cartons au lieu de palettes.
Ces erreurs apparaissent un partenaire à la fois, et c'est ce qui les rend coûteuses. Une entreprise qui compte des dizaines de partenaires EDI ne subit pas une seule erreur. Elle en subit une file d'attente, chacune nécessitant qu'une personne différente dans une entreprise différente confirme une correction.
Le même schéma s'applique plus largement à la migration de données, comme l'explique l'article sur la migration des données ERP et WMS avec une plateforme d'intégration. L'EDI en est la version où quelqu'un hors de votre entreprise doit donner son accord avant que quoi que ce soit soit corrigé.
Ce que coûte réellement la refonte d'une intégration EDI
Le remapping n'est pas la partie coûteuse. Un analyste reconstruit un mapping en quelques heures. Ce qu'il en coûte à l'entreprise se situe autour de ce travail :
- Des commandes rejetées chez le partenaire : un champ manquant empêche la commande d'atteindre votre système, et le client vous relance au lieu de solliciter sa propre équipe EDI
- Des factures contestées au lieu d'être payées : un code de TVA mappé différemment devient un avoir, une discussion avec la finance et une trésorerie qui arrive un mois plus tard
- Vos plus grands clients sollicités : les changements EDI exigent des tests côté partenaire, si bien qu'un remplacement de système devient une demande adressée aux entreprises auxquelles vous essayez de vendre
- Le même travail la prochaine fois : des mappings reconstruits sur le nouvel ERP y sont tout aussi liés, si bien que le remplacement suivant coûtera autant
- Un remplacement reporté ou évité : les entreprises dotées de grands parcs EDI reportent souvent les changements de système à cause du coût de la refonte
Ce dernier point est le vrai prix. L'EDI cesse d'être une obligation technique et devient une raison de ne jamais changer de système.
Comment une plateforme d'intégration gère l'intégration EDI
Un iPaaS (integration Platform as a Service) donne à une entreprise un seul endroit où tous ses systèmes se connectent. Chaque système s'y connecte une fois au lieu de se connecter directement aux autres, et la plateforme déplace et transforme les données entre eux. Les entreprises l'utilisent pour le travail quotidien : les commandes de la boutique en ligne vers l'ERP, les stocks en retour, les données d'expédition vers un transporteur.
L'EDI fonctionne selon le même principe, avec une différence qui compte ici. Le partenaire se connecte à la plateforme plutôt qu'à l'ERP. Le mapping entre le format du partenaire et votre modèle de données réside dans la plateforme, et non dans la connexion, si bien que changer ce qui se trouve derrière ne change pas ce que voit le partenaire.
La plateforme d'intégration Alumio offre des fonctionnalités configurables pour garder les connexions EDI stables pendant un changement d'ERP :
- Le point de terminaison du partenaire ne bouge pas : les partenaires continuent d'envoyer au même endroit dans le même format, si bien qu'un remplacement derrière la plateforme n'exige aucun changement de leur côté
- Les mappings sont visibles et modifiables : un Transformer contient la traduction entre les formats des partenaires et vos identifiants, si bien que remapper vers un nouvel ERP est une modification de configuration que votre propre équipe peut effectuer
- Les deux systèmes peuvent tourner en parallèle : les flux peuvent pointer vers l'ancien et le nouvel ERP pendant la bascule, si bien que personne ne dépend d'une date de bascule unique
- Vous voyez ce que chaque partenaire a envoyé : les journaux de messages montrent exactement ce qui est arrivé et ce qui a été renvoyé, ce qui règle un litige avec un partenaire au lieu de le prolonger
Alumio propose aussi un EDI Broker pour les entreprises qui préfèrent faire gérer la connexion plutôt que de la construire. Le même principe s'applique en dehors de l'EDI. AGU connecte son ERP Centric à Adobe Commerce et à Akeneo via Alumio plutôt qu'en direct, avec des données normalisées qui pourront ensuite être reliées à d'autres outils. Les nouveaux canaux peuvent alors s'ajouter sous forme de Routes supplémentaires, sans reconstruire ce qui tourne déjà.
Ce que vous apporte une intégration EDI indépendante des partenaires
L'EDI est généralement traité comme une obligation héritée, maintenue parce que les grands clients l'exigent. C'est pour cette raison qu'il arrive en dernier dans le plan et en premier dans les retards.
L'ERP n'est pas non plus le problème. Une entreprise doit pouvoir le remplacer lorsque l'ancien ne convient plus, et elle maîtrise l'essentiel de ce projet. Ce qui rend la décision plus difficile qu'elle ne devrait l'être, c'est que l'ERP finit par contenir des traductions pour des systèmes bien au-delà de lui-même : les partenaires commerciaux, mais aussi la boutique en ligne, l'entrepôt et les transporteurs. Déplacer ces traductions dans une couche d'intégration sépare les deux, si bien que les partenaires gardent leur point de terminaison et que l'ERP redevient simplement un ERP.
L'entreprise obtient un paysage de systèmes qu'elle peut faire évoluer à son rythme, où remplacer l'ERP est un projet plutôt qu'une négociation, et où l'intégration EDI survit au système pour lequel elle avait été construite.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
