SAP MII / PCo : maintenir, sécuriser ou moderniser ?

En synthèse

SAP MII et SAP PCo sont encore présents dans de nombreuses architectures industrielles. Ils connectent SAP, MES, bases de données, équipements, supervision, fichiers et systèmes locaux. Ils portent parfois des fonctions critiques : collecte machine, transactions opérateur, orchestration de flux, reporting, étiquetage, appels RFC, OPC, échanges fichiers ou logique de transformation.

La question n’est pas de décider dogmatiquement s’il faut tout remplacer. La vraie question est de qualifier la valeur de l’existant, son risque de run, sa dette documentaire, sa criticité industrielle et sa trajectoire cible dans un paysage S/4HANA, SAP DM, BTP, middleware moderne ou MES spécialisé.

Une modernisation réussie commence par une cartographie factuelle. Remplacer sans comprendre revient souvent à reconstituer ailleurs les mêmes fragilités.

Cartographier l’existant au niveau transactionnel

Un inventaire applicatif général ne suffit pas. Il faut descendre au niveau des transactions MII, destinations, requêtes, jobs, services, connecteurs PCo, agents, tags OPC, mappings, tables temporaires, utilisateurs, droits, logs, dépendances et horaires d’exécution.

Dans beaucoup de contextes, certains flux critiques ne sont connus que d’un expert historique. La première valeur d’un diagnostic est donc de rendre visible ce qui soutient réellement l’usine.

Distinguer valeur métier et dette technique

Un flux MII ancien peut être techniquement peu élégant mais opérationnellement critique. À l’inverse, une transaction sophistiquée peut ne plus servir à aucun processus actif. La modernisation doit éviter deux erreurs : sanctuariser l’existant par peur, ou tout remplacer par principe.

Chaque composant doit être classé selon usage réel, criticité industrielle, fréquence d’incident, complexité de maintenance, dépendance expert, sécurité et alternative cible.

Évaluer les risques de run : supervision, compétences, sécurité

Les principaux risques MII/PCo sont rarement visibles dans les démonstrations. Ils apparaissent en run : logs non exploités, absence de monitoring, erreurs intermittentes, timeout, destinations instables, droits excessifs, serveurs non patchés, dépendance à une seule personne, absence de tests de non-régression.

Une trajectoire de sécurisation peut parfois apporter plus de valeur à court terme qu’un remplacement massif. Documenter, superviser, rationaliser et tester l’existant peut réduire l’exposition opérationnelle pendant que la cible se construit.

Choisir entre maintenir, sécuriser, simplifier ou remplacer

Tous les flux ne doivent pas avoir la même trajectoire. Certains peuvent être maintenus sans investissement majeur. D’autres doivent être sécurisés rapidement parce qu’ils portent un risque. Certains doivent être simplifiés car ils compensent une faiblesse process. D’autres doivent être remplacés parce qu’ils sont obsolètes, non supportables ou incompatibles avec l’architecture cible.

Cette segmentation permet d’éviter le big bang et de construire une roadmap par criticité.

Préparer la transition vers SAP DM, BTP, middleware ou MES cible

Une cible moderne peut inclure SAP Digital Manufacturing, SAP BTP Integration Suite, middleware d’entreprise, API S/4HANA, MES éditeur, historian ou couche IoT. Le choix dépend des cas d’usage, de la stratégie SAP, des exigences OT, de la cybersécurité et du run.

La transition doit inclure des tests de non-régression, des règles de coexistence, un plan de cutover, une politique de rollback et une reprise de monitoring. Le risque principal est d’interrompre un flux qui n’avait pas été identifié comme critique.

Ne pas moderniser une faiblesse process sous forme de technologie

Certaines transactions MII existent parce qu’un processus n’a jamais été clarifié : double saisie, correction manuelle, contournement d’un manque SAP, extraction Excel, logique locale. Les remplacer à l’identique dans une technologie moderne revient à pérenniser la dette.

Chaque flux à moderniser doit donc être challengé : sert-il encore un besoin réel ? Le besoin doit-il être couvert par SAP standard, MES, reporting ou process ? Peut-on supprimer le flux au lieu de le migrer ?

Matrice de décision

La segmentation suivante permet de décider sans dogmatisme.

Exemple concret anonymisé

Un site disposait d’une transaction MII utilisée pour envoyer des confirmations partielles vers SAP. L’analyse a révélé que la logique compensait une règle métier non tranchée sur la correction opérateur. Avant de migrer la transaction vers une architecture cible, le processus a été clarifié : qui corrige, dans quel délai, avec quel statut et quelle trace. Le flux modernisé est devenu plus simple que l’existant, car il ne portait plus des exceptions implicites.

Questions de direction

• Quels flux MII/PCo sont réellement critiques pour l’usine ?
• L’organisation sait-elle diagnostiquer une erreur sans dépendre d’un expert unique ?
• Quels flux doivent être maintenus, sécurisés, simplifiés, modernisés ou supprimés ?
• La modernisation cible-t-elle une valeur métier ou seulement une obsolescence technique ?
• Les tests de coexistence et de non-régression sont-ils prévus avant migration ?

Checklist opérationnelle

• Inventorier transactions, agents, destinations, flux, mappings, jobs et dépendances.
• Classer les flux par criticité industrielle, usage réel et risque de run.
• Mettre en place monitoring et documentation sur les flux critiques.
• Challenger les flux qui compensent des faiblesses process historiques.
• Construire une trajectoire progressive vers la cible sans big bang inutile.

Conclusion

SAP MII/PCo ne doit être ni sacralisé ni remplacé aveuglément. La bonne posture consiste à comprendre la valeur portée, réduire les risques immédiats, simplifier les flux hérités et moderniser progressivement ce qui sert réellement la trajectoire industrielle.