SAP Digital Manufacturing vs MES traditionnel : comment arbitrer ?

En synthèse

Arbitrer entre SAP Digital Manufacturing et un MES traditionnel ne doit pas être un débat de conviction technologique. Les deux options peuvent être pertinentes selon le contexte industriel, l’écosystème SAP, les exigences atelier, la stratégie cloud, les contraintes réglementaires, le niveau d’automatisation et la capacité de run.

SAP DM apporte une cohérence forte avec S/4HANA, une logique cloud et une intégration naturelle dans l’univers SAP. Un MES spécialisé peut offrir une profondeur fonctionnelle, une proximité équipement ou une adaptation sectorielle plus avancée dans certains environnements.

La bonne décision repose sur les cas d’usage, pas sur la marque. Elle doit comparer la couverture standard, les écarts à développer, les interfaces, la maintenabilité, la cybersécurité, le modèle de support, le coût de run et la trajectoire multi-sites.

Commencer par les cas d’usage critiques

Un comparatif solution par solution reste trop théorique s’il n’est pas rattaché aux cas d’usage. Les questions structurantes sont concrètes : instructions opérateur, suivi d’opérations, collecte temps réel, eBR, pesée, sérialisation, qualité en cours, performance, arrêts, traçabilité, genealogy, ordonnancement fin, intégration équipements, mobilité, paperless, analytics.

Chaque cas d’usage doit être classé selon criticité, fréquence, exigence réglementaire, complexité équipement, besoin de temps réel et valeur attendue. C’est cette matrice qui doit piloter l’arbitrage.

Clarifier l’architecture cible ERP/MES/OT

La solution MES ne peut pas être choisie indépendamment de l’architecture cible. Il faut définir les responsabilités : SAP S/4HANA pour le plan et l’ordre ? MES pour l’exécution ? Équipements pour la mesure ? Historien pour les données process ? Data platform pour l’analytics ?

Une mauvaise frontière génère des doublons de vérité. Par exemple, si SAP et le MES portent tous deux des statuts d’ordre ou des quantités corrigées sans règle de réconciliation, les écarts deviendront structurels.

Comparer la couverture standard et la dette spécifique

Le critère n’est pas seulement la richesse fonctionnelle. Il faut évaluer ce qui est couvert en standard, ce qui nécessite du paramétrage, ce qui nécessite du développement et ce qui créera une dette de run.

Une solution qui couvre 80 % des cas critiques avec peu de spécifique peut être plus robuste qu’une solution très puissante mais fortement customisée. À l’inverse, ignorer une exigence atelier critique sous prétexte de rester standard peut générer des contournements durables.

Évaluer la proximité avec les équipements et l’OT

Certains environnements nécessitent une intégration fine avec automates, balances, machines, systèmes de vision, supervision, historians ou OPC UA. Le choix doit tenir compte de la latence acceptable, de la granularité des données, du besoin offline, de la cybersécurité et de la responsabilité support.

Si les équipements sont hétérogènes, anciens ou fortement spécifiques, le sujet OT peut peser autant que le sujet ERP.

Intégrer le run et les compétences dans l’arbitrage

Un MES devient un système critique. Il doit être supervisé, documenté, maintenu, mis à jour, supporté et sécurisé. Les compétences disponibles — SAP, MES éditeur, OT, infrastructure, cybersécurité — sont donc un critère de décision.

Le coût de run ne se limite pas aux licences. Il inclut support, monitoring, corrections, montée de version, gestion des interfaces, formation, évolutions réglementaires, dépendance éditeur et réversibilité.

Penser multi-sites dès le pilote

Un pilote peut réussir localement et échouer à l’échelle si les variantes site, langues, équipements, pratiques qualité, données et maturités ne sont pas intégrées dès le design. Le template doit être conçu pour absorber des écarts justifiés tout en éliminant les habitudes locales sans valeur.

Le bon arbitrage SAP DM vs MES traditionnel doit donc inclure la stratégie de rollout : standard groupe, variantes autorisées, gouvernance d’écarts, modèle de support et capitalisation post-pilote.

Matrice de décision

La décision doit combiner stratégie IT, réalité atelier et capacité de déploiement.

Exemple concret anonymisé

Une organisation envisageait SAP DM pour harmoniser ses sites sous S/4HANA. L’analyse des cas d’usage a confirmé la pertinence sur suivi d’opérations, intégration ordre, confirmations et performance. En revanche, une ligne fortement automatisée avec contraintes d’acquisition process très spécifiques nécessitait une architecture complémentaire avec historien et couche OT dédiée. La décision n’a pas été binaire : SAP DM comme socle d’exécution standard, avec intégration maîtrisée à des composants spécialisés pour les cas machines critiques.

Questions de direction

• Le choix est-il piloté par les cas d’usage critiques ou par préférence éditeur ?
• Les frontières SAP, MES, OT, historien et data platform sont-elles claires ?
• La dette spécifique future est-elle quantifiée ?
• Le run, les compétences et la cybersécurité sont-ils intégrés au business case ?
• Le pilote est-il conçu pour être généralisable ou seulement démonstratif ?

Checklist opérationnelle

• Lister et prioriser les cas d’usage par criticité, valeur et complexité.
• Évaluer couverture standard, écarts, développements et dette de run.
• Cartographier responsabilités ERP/MES/OT et interfaces critiques.
• Inclure support, compétences, cybersécurité et montée de version dans l’arbitrage.
• Définir dès le pilote les règles de template et variantes multi-sites.

Conclusion

SAP DM et MES traditionnel ne doivent pas être opposés par principe. Le bon choix est celui qui sert le modèle industriel cible, couvre les cas d’usage critiques, reste maintenable et permet un passage à l’échelle maîtrisé. L’arbitrage premium consiste à choisir l’architecture de valeur, pas seulement l’outil.