Lorsqu'une entreprise décide de développer l'EDI en interne, la décision commence et se termine généralement avec l'IT. L'IT évalue la faisabilité technique, estime le coût de développement et formule une recommandation ; les opérations sont brièvement consultées ; et la finance approuve ou refuse le budget.
Cependant, les informations auxquelles l'IT a accès couvrent uniquement l'aspect technique de la décision. Elles ne couvrent ni les obligations de conformité dont les opérations sont responsables, ni l'exposition aux pénalités que la finance gère, ni les risques de continuité liés aux ressources humaines. Ces dimensions apparaissent en production, généralement à un coût que personne n'avait budgété.
« La plupart des décisions de développement en interne semblent raisonnables jusqu'à ce que vous demandiez qui est responsable du système à 23h un dimanche soir, avant une fenêtre de livraison le lundi », déclare Taylor Bond, Directeur Senior de l'Ingénierie GTM et de l'IA chez SPS Commerce. « Cette question met généralement fin à la conversation assez rapidement. »
Cet article fournit à l'IT, aux opérations et à la finance un ensemble commun de questions à examiner avant qu'une décision de développement interne ne soit prise, afin de mieux comprendre comment tirer parti de ces outils.
Questions auxquelles répondre avant de développer en interne
Ce ne sont pas des questions purement techniques, et les examiner relève de la diligence raisonnable dans une décision de développement interne versus achat d'une solution. Une décision de développement prise avec une contribution transversale complète est plus solide et plus défendable qu'une décision basée uniquement sur une évaluation technique.
Avec quels distributeurs travaillez-vous aujourd'hui, et lesquels pensez-vous raisonnablement ajouter dans les 24 prochains mois ?
Chaque distributeur a ses propres exigences EDI : jeux de transactions, qualificateurs de segments, fenêtres de timing et protocoles de test. Un développement calibré pour vos partenaires commerciaux actuels nécessitera souvent une refonte significative lorsqu'un nouveau distributeur sera intégré. Les opérations ont généralement la vision la plus claire de la croissance probable du réseau de distributeurs. L'IT a besoin de cette information avant de définir le périmètre du développement.
Qui est responsable du suivi de la conformité, et à quoi ressemble le processus de gestion des exceptions lorsqu'une transaction échoue ?
Cette question se situe à la frontière IT/opérations. Un développement qui génère des erreurs sans chemin d'escalade défini crée des problèmes en aval. L'IT peut construire la notification d'erreur, mais les opérations doivent être responsables du processus de réponse. Si cette responsabilité n'est pas établie avant le développement, elle l'est de manière réactive, après que le premier échec a déjà coûté quelque chose.
Quel est votre taux actuel de pénalités (chargebacks), et quel niveau d'exposition la finance considère-t-elle comme acceptable ?
Les pénalités liées à la non-conformité EDI (ASN en retard, segments manquants, erreurs de timing, etc.) sont un coût direct des lacunes dans la couche EDI. La finance ne connaît souvent pas en détail le taux actuel de pénalités ; les opérations ne savent peut-être pas quel seuil la finance a implicitement accepté. Réunir les deux équipes dans la même conversation avant un développement révèle si l'exposition actuelle est un problème que le développement doit résoudre, ou un problème qu'il pourrait aggraver.
De plus, les trois équipes ne considèrent peut-être même pas l'EDI comme étant lié aux pénalités et déductions. À moins qu'il n'existe une équipe transversale dédiée aux pertes de revenus, la visibilité complète sur le risque financier ne sera pas au niveau requis.
Avez-vous modélisé ce à quoi ressemble le cycle de pénalités d'un seul distributeur si votre système EDI tombe en panne pendant 48 heures ?
Les développements internes nécessitent des fenêtres de maintenance internes, une réponse aux incidents en interne et une reprise interne. Les temps d'arrêt correspondent à des distributeurs spécifiques, des volumes de transactions spécifiques et un risque de pénalités spécifique. La finance doit comprendre ce modèle avant que la décision de développement ne soit prise.
Si la personne principale qui développe et maintient ce système part, quel est le plan de transition ?
Les systèmes EDI internes ont tendance à devenir très personnalisés, développés par un seul développeur ou une petite équipe dont la compréhension de l'implémentation réside largement dans leur tête. C'est un risque de continuité des ressources qui apparaît rarement dans l'estimation initiale du développement.
Disposer d'une documentation détaillée sur le développement, accessible à l'ensemble de l'organisation, est essentiel pour maintenir une solution développée en interne sur le long terme.
Votre équipe actuelle dispose-t-elle d'une expertise spécifique en EDI, ou allez-vous la développer pendant la construction ?
Développer une expertise EDI tout en construisant simultanément une infrastructure EDI est lent et coûteux. La courbe d'apprentissage des standards EDI, des exigences spécifiques aux distributeurs et de la logique de gestion des exceptions est difficile. Les estimations de l'IT sont souvent basées sur la capacité de développement générale, et non sur la capacité spécifique à l'EDI. Les opérations doivent signaler toute échéance
de conformité qui fait de cette courbe d'apprentissage un risque métier.
Une solution EDI managée et connectée à un réseau élimine entièrement ce problème : l'expertise spécifique aux distributeurs est déjà intégrée, votre équipe n'a donc pas à la développer de zéro pendant que le temps presse.
Certaines de vos relations distributeurs sont-elles soumises à des seuils de conformité EDI qui affectent votre scorecard fournisseur ?
Certains distributeurs lient les performances de conformité EDI aux métriques du scorecard fournisseur, ce qui affecte le placement en rayon, le volume de commandes et le statut de fournisseur privilégié. Les équipes commerciales et de gestion de comptes détiennent généralement cette information. Si un retard de développement ou une lacune de couverture affecte les performances du scorecard, le coût s'étend bien au-delà des pénalités.
Quel est le délai réaliste d'intégration d'un nouveau distributeur sur votre système interne, et quel est le coût en termes de revenus de ce délai par rapport aux alternatives ?
L'intégration EDI d'un distributeur implique des protocoles de test, des exigences de certification et des fenêtres de mise en production spécifiques. La question pertinente n'est pas de savoir si un développement interne peut éventuellement supporter un nouveau distributeur, mais s'il peut le faire dans le délai que cette relation exige. Les opérations et les ventes connaissent ce délai. La finance doit voir le coût d'un dépassement.
Que comprend l'estimation du développement, et que ne comprend-elle pas ?
Les estimations initiales couvrent généralement le temps de développement, l'infrastructure et l'intégration. Elles ne couvrent souvent pas la maintenance continue, les mises à jour de conformité lorsque les distributeurs modifient leurs exigences, les tests internes pour chaque nouveau partenaire commercial, ni le temps du personnel nécessaire pour gérer les exceptions.
Quel est le point de comparaison des coûts, et est-ce une comparaison équivalente ?
Les comparaisons développer-vs-acheter mesurent souvent le coût du développement par rapport aux frais de licence d'une solution managée, sans tenir compte des coûts opérationnels et de personnel qu'une solution managée absorbe. La comparaison n'est significative que si elle prend en compte le coût total de la propriété interne.
Comment assurerez-vous l'intégrité des données si la logique EDI fonctionne en dehors de votre ERP ?
Lorsque le traitement EDI s'effectue dans un système qui ne partage pas un modèle de données avec votre ERP, la réconciliation devient un processus manuel ou semi-manuel. Les écarts entre les enregistrements de transactions EDI et les données ERP créent des problèmes en aval dans la facturation, l'exécution des commandes et le reporting financier.
Le développement inclut-il un support natif des protocoles de communication requis comme AS2, ou ceux-ci sont-ils traités via des solutions tierces ?
AS2 est le protocole de transport sécurisé standard pour l'EDI avec la plupart des grands distributeurs. Si le support natif AS2 ne fait pas partie du développement, cette lacune est généralement comblée par une solution tierce, ce qui ajoute un coût et un point de défaillance supplémentaire.
Votre système détectera-t-il les erreurs de formatage structurel avant l'envoi, ou le découvrirez-vous par une amende de non-conformité ?
La validation pré-transmission est la différence entre détecter un problème en interne et laisser un distributeur le détecter pour vous. Et cette différence est coûteuse, puisque les distributeurs facturent le coût de vos erreurs de formatage. Un développement sans validation robuste avant envoi transfère ce coût aux opérations et à la finance, souvent de
manière invisible jusqu'à l'exécution du cycle de pénalités.
Avez-vous un plan pour un environnement de test en mode shadow afin de valider la logique de mapping par rapport aux données réelles des partenaires sans risquer les transactions en production ?
Le test en mode shadow (c'est-à-dire exécuter une logique EDI nouvelle ou mise à jour en parallèle avec des données de transactions réelles avant la mise en production) est le moyen le plus fiable de détecter les erreurs de mapping avant qu'elles ne deviennent des échecs de conformité. Cela nécessite un investissement délibéré dans le développement et n'est pas toujours inclus dans le cadrage initial.
Pas prêt à développer en interne ? Il existe une autre solution
Si vos équipes ne parviennent pas à s'aligner sur les réponses à ces questions (ou si les réponses révèlent plus de risques que ce que l'estimation du développement prenait en compte), une solution EDI managée peut être le meilleur choix pour votre entreprise.
SPS Commerce Fulfillment prend en charge le mapping spécifique aux distributeurs, le
suivi de la conformité et le support des protocoles qui rendent les développements internes coûteux à maintenir à grande échelle. Pour les entreprises qui échangent avec plus d'une poignée de distributeurs (ou qui prévoient de croître), un système interne tend à coûter plus cher à maintenir que l'argent économisé.
