Dessiner les échanges
Listez chaque système qui échange avec le MES : ERP, boutique en ligne, équipement de production, outil de planification ou solution d’étiquetage. Pour chaque flux, précisez qui crée la donnée, qui l’utilise, le sens, la fréquence et l’événement déclencheur. Un schéma utile distingue les systèmes et les messages; il n’est pas une simple liste de logos.
Définissez les identifiants qui permettent de rapprocher une commande, une réception, un colis ou un mouvement. Précisez le format, les unités, les champs obligatoires et les règles de correction. Demandez un exemple représentatif et anonymisé. Un champ portant le même nom peut avoir une définition différente dans deux logiciels.
Clarifiez si l’échange est synchrone, périodique ou manuel. Fixez la latence acceptable selon le processus, en précisant qui la décide. N’assumez pas qu’un rafraîchissement instantané est utile partout; faites correspondre la fréquence aux opérations et aux limites du fournisseur.
Traiter les erreurs et doublons
Demandez ce qui se passe si un message manque, arrive deux fois, arrive tard ou contient une valeur inconnue. Définissez l’endroit où l’erreur apparaît, l’équipe qui la surveille et la personne qui peut la corriger. La reprise doit éviter d’enregistrer deux fois une expédition ou un mouvement après une reconnexion.
Précisez les mécanismes de rapprochement : identifiant de message, accusé de réception, journal, file d’erreurs, relance ou annulation. Faites démontrer un échec contrôlé en environnement d’essai et observez comment l’équipe retrouve l’état final. Un schéma d’interface ne prouve pas que les incidents sont surveillés.
Attribuez les responsabilités entre fournisseur MES, intégrateur et éditeur tiers. Qui ouvre le ticket? Qui fournit les journaux? Qui teste une nouvelle version? Qui approuve le changement de format? Écrivez les réponses dans une matrice et rapprochez-les des contrats de support concernés.
Délimiter les échanges avec l’atelier
Décrivez les objets qui passent entre ERP, MES et équipement : ordre, opération, quantité, lot, état, arrêt et résultat. Indiquez quelle application est source de vérité pour chaque champ. La référence ISA-95 peut aider les équipes à nommer les frontières entre fonctions d’entreprise et gestion des opérations; elle ne fournit pas votre architecture prête à déployer. Faites tester les messages perdus, répétés et reçus dans le désordre.
Chiffrer la création et la maintenance
Distinguez le connecteur inclus, la configuration, le développement, l’hébergement éventuel, les tests et le support récurrent. Demandez le nombre d’interfaces couvertes et les limites. Vérifiez le coût des environnements de test et la prise en charge des versions. Une mention « API disponible » ne dit pas qui construit ou maintient l’intégration.
Incluez la charge interne de coordination et de test, surtout lorsque plusieurs fournisseurs interviennent. La disponibilité de chaque équipe influe sur le calendrier. Faites apparaître une dépendance comme risque plutôt que d’ajouter un montant spéculatif. Si un devis est estimatif, demandez ses hypothèses et la méthode de révision.
Modélisez la maintenance sur la même durée que les autres postes : évolutions, surveillance, correctifs et rposte de travail d’un système tiers. Les montants futurs doivent provenir d’une clause ou rester un scénario hypothétique. Ne présentez pas un prix non publié comme un tarif du marché.
Tester un parcours complet
Préparez une opération de bout en bout qui part d’une commande, traverse l’ERP ou le canal d’entrée, apparaît dans le MES, se transforme en préparation puis transmet le résultat au système destinataire. Incluez une exception et vérifiez la trace. Testez les responsabilités manuelles réellement présentes au lieu de supposer que toute étape est automatisée.
Définissez les jeux d’essai, les comptes, les versions et les preuves conservées. Fixez les critères d’acceptation avant l’exécution : messages attendus, données rapprochées, état final et traitement de l’erreur. Les utilisateurs opérationnels doivent valider que la séquence correspond au travail réel.
Une interface qui passe un essai ne garantit pas son fonctionnement dans toutes les conditions. Conservez les limites, les cas non couverts et la procédure de surveillance. Les documentations d’éditeurs peuvent illustrer un format ou un mécanisme, mais votre contrat reste la référence pour votre intégration.
Sources et limites
Les sources éclairent des questions de cadrage; elles ne valident pas votre architecture ni un fournisseur. Les standards et documentations cités restent la propriété de leurs éditeurs et ne remplacent pas l’analyse de votre site.