Dossier de consultation / DAF et DSI
Multi-ERP : organiser les flux de facturation
Comparez hub mutualisé et raccordements séparés pour plusieurs ERP, avec identité des documents, supervision et migration progressive.
Mis à jour le .
Cartographier les applications plutôt que les marques
Un groupe peut disposer de plusieurs ERP, d’un outil métier et d’une application achats. La cartographie doit identifier ce que chaque système produit et reçoit. Le même logiciel peut jouer des rôles différents selon les filiales. Décrivez les flux et les personnes responsables avant de choisir une architecture. Le nombre d’applications ne détermine pas à lui seul le nombre de plateformes à retenir.
Repérez les documents créés dans un système puis comptabilisés dans un autre. Le projet doit préciser quelle source fait foi et à quel moment. Sans cette décision, deux applications peuvent proposer d’émettre le même document. La séparation des objets et des responsabilités doit être visible dans le schéma d’ensemble. Les exigences de transmission restent à examiner avec la plateforme et les documents officiels applicables.
Comparer hub et connexions distinctes
Un hub peut mutualiser transformation, contrôles et supervision. Il peut aussi devenir un point de dépendance commun à plusieurs flux. Demandez comment les incidents sont isolés et comment les équipes retrouvent leur propre périmètre. L’offre doit préciser les environnements, les droits et la maintenance du composant central. La mutualisation n’est pas un bénéfice automatique si chaque source conserve des règles incompatibles.
Des raccordements séparés peuvent permettre une progression par application. Ils peuvent multiplier les configurations et les procédures de support. Comparez les options sur un même ensemble de cas et de contraintes. Identifiez les règles qui doivent rester communes et celles qui sont propres à une activité. Faites chiffrer la supervision et les modifications, sans présumer qu’une connexion déjà construite sera réutilisable partout.
Préserver l’identité des factures
La corrélation doit tenir compte de l’entité et du système source. Un numéro de facture identique dans deux ERP ne suffit pas à désigner le même document. Définissez les clés de rapprochement et les références conservées à chaque étape. Le système doit permettre de retrouver un événement sans ambiguïté et de distinguer notification en double et document distinct.
La DAF doit décider quelle application porte les corrections comptables. La DSI documente le chemin technique de la correction et le retour des réponses. Une réplication de données entre applications peut provoquer des boucles si les rôles ne sont pas séparés. Faites tester le parcours complet avec une facture de chaque source, puis une reprise technique du même échange.
Centraliser la vue sans confondre les responsabilités
La supervision peut proposer une vision commune des files en attente et des anomalies. Chaque erreur doit néanmoins être affectée au bon propriétaire. Un incident d’authentification sur un ERP ne doit pas bloquer les corrections métier d’un autre. Demandez des filtres par entité, source et famille de flux. Les utilisateurs doivent consulter uniquement les informations nécessaires à leur rôle.
Le support doit disposer d’un schéma et d’une matrice d’escalade. Un contrat unique ne supprime pas les dépendances aux éditeurs des différentes applications. Décrivez les preuves à fournir lors d’un ticket et les conditions d’accès aux environnements. Les engagements d’intervention relèvent des contrats ; ne les déduisez pas d’une promesse de supervision centralisée.
Organiser une migration par périmètre
La bascule peut être étudiée par source ou par flux, à condition de maîtriser les documents en cours. Préparez un inventaire et un rapprochement avant changement. Déterminez ce qui reste sur l’ancien parcours et ce qui passe sur le nouveau. Les périodes de coexistence doivent être explicites pour éviter une double émission.
Les jeux de régression communs permettent de vérifier chaque nouvelle source. Ajoutez les cas propres à son activité. Le dossier de réception doit constater les résultats et les réserves avant l’ouverture du flux. Une architecture destinée à durer doit aussi permettre le retrait d’un ERP et la récupération de ses journaux. Demandez cette procédure dans l’offre initiale.
Grille à joindre à la consultation
| Point | Preuve à demander |
|---|---|
| Source | Application créatrice, application comptable et moment de validation distingués pour chaque famille de documents. |
| Architecture | Hub et connexions séparées comparés avec les mêmes cas, dépendances et coûts de maintenance. |
| Identité | Entité, source et références associées pour éviter les collisions de numérotation et les boucles. |
| Supervision | Vue commune filtrable, propriétaires d’anomalies identifiés et accès limités au périmètre autorisé. |
| Bascule | Coexistence, documents en cours et rapprochement préparés avant ouverture d’un nouveau parcours. |
Livrable attendu
Le livrable d’architecture comporte le schéma des flux, les règles de corrélation et la stratégie de migration. Demandez une preuve de reprise pour chaque source et une procédure de retrait d’application. La décision doit comparer les coûts d’exploitation et les responsabilités, pas uniquement le nombre d’interfaces. Les données manquantes dans un ERP doivent rester visibles comme une dépendance spécifique. Un hub ne doit pas masquer ces écarts derrière une promesse de traitement uniforme.