En synthèse exécutive
Le sujet ne doit pas être traité comme un point technique isolé. Il doit être lu comme un enjeu de transformation industrielle : qualité de décision, robustesse opérationnelle, capacité de run et création de valeur mesurable.
La différence entre une approche standard et une approche premium tient à la profondeur du diagnostic. Il ne suffit pas d’identifier ce qui dysfonctionne. Il faut comprendre pourquoi l’organisation a laissé ce dysfonctionnement s’installer, quelles décisions n’ont pas été prises, quels indicateurs ont masqué le problème et quelle gouvernance permettra d’éviter sa réapparition.
La performance digitale industrielle ne vient pas de l’empilement d’outils. Elle vient de l’alignement entre processus, données, responsabilités, systèmes et routines de management.
Le statut quo : beaucoup de comités, peu de décisions
La plupart des programmes ERP/MES disposent déjà d’une gouvernance formelle : comité projet, comité de pilotage, planning, registre d’actions, comptes rendus. Pourtant, les sujets critiques restent souvent ouverts pendant des semaines : frontière ERP/MES, standard ou spécifique, responsabilités sur les données, reprise des historiques, critères de recette, règles de contournement, niveau de support au démarrage.
Le problème n’est donc pas l’absence de gouvernance. Le problème est la confusion entre gouvernance d’information et gouvernance de décision. Une gouvernance d’information présente l’état du projet. Une gouvernance de décision transforme les zones grises en arbitrages documentés, assumés et exécutables.
Dans un programme industriel, chaque arbitrage non pris finit par être pris par le planning. Lorsque la date de go-live approche, la solution par défaut devient souvent : livrer avec dette, contourner avec Excel, reporter au run ou demander au site de s’adapter. Cette mécanique détruit la confiance et reporte le coût sur les utilisateurs.
Définir les droits de décision : qui tranche quoi, à quel niveau et avec quels critères ?
Une gouvernance robuste commence par une cartographie des décisions. Toutes ne doivent pas remonter au même niveau. Un choix de libellé écran peut rester opérationnel ; une dérogation au template MES ou une modification du processus de libération qualité doit être arbitrée avec une lecture risque, coût, adoption et conformité.
La matrice de décision doit être explicite. Elle évite deux dérives fréquentes : la sur-escalade, qui ralentit tout, et la sous-escalade, qui laisse des décisions structurantes être prises localement sans vision transverse.
| Type de décision | Niveau recommandé | Critères d’arbitrage |
|---|---|---|
| Écart local au template | Design authority / comité métier transverse | Valeur métier, contrainte réglementaire, effort de run, réutilisabilité |
| Frontière ERP/MES | Architecture + métier + programme | Propriété de la donnée, temps réel, criticité, supportabilité |
| Spécifique SAP ou MES | Comité d’arbitrage solution | Alternative standard, dette technique, coût de maintenance, impact adoption |
| Go-live readiness | Steering committee | Risques résiduels, continuité d’activité, hypercare, utilisateurs, data |
| Priorisation backlog | Product owner métier / PMO | Impact business, urgence réglementaire, dépendance projet, effort |
Le RACI utile : sortir du tableau administratif
Un RACI rempli pour satisfaire une méthodologie projet a peu de valeur. Un RACI utile clarifie les responsabilités au moment où il y a tension : donnée incorrecte, incident interface, arbitrage de processus, retard de recette, demande de spécifique, écart site, support post go-live.
Dans un projet ERP/MES, les zones grises sont nombreuses. La supply chain pense parfois que les méthodes sont propriétaires des nomenclatures ; les méthodes estiment que la production valide les gammes ; la DSI considère que le métier décide des flux ; l’intégrateur attend une validation formelle ; le site attend une solution opérationnelle. Sans clarification, les sujets critiques circulent sans propriétaire.
Arbitrer standard versus spécifique avec une logique économique
Le débat standard/spécifique est souvent mal posé. Le standard n’est pas toujours vertueux et le spécifique n’est pas toujours mauvais. La vraie question est : quelle option protège le mieux la valeur industrielle sur le cycle de vie complet ?
Un spécifique peut être justifié lorsqu’il répond à une contrainte réglementaire, un avantage compétitif réel ou une sécurité opérationnelle indispensable. À l’inverse, un spécifique demandé pour préserver une habitude locale non différenciante crée une dette durable. Il complexifie les tests, le support, les upgrades, la formation et les rollouts.
| Critère | Question à poser | Signal de vigilance |
|---|---|---|
| Valeur | Quel gain mesurable ou risque évité justifie l’écart ? | Argument fondé uniquement sur le confort utilisateur |
| Standard SAP/MES | Existe-t-il une alternative standard acceptable ? | Spécifique demandé avant exploration réelle du standard |
| Run | Qui supportera la solution dans 18 mois ? | Absence de propriétaire support ou documentation faible |
| Scalabilité | La solution est-elle réutilisable sur d’autres sites ? | Solution conçue pour un cas local non représentatif |
| Risque | Quel est le risque industriel si l’on ne fait pas l’écart ? | Risque non quantifié, arbitrage émotionnel |
Cas concret anonymisé : le planning affichait vert, la décision était rouge
Dans un programme ERP/MES multi-sites, le planning consolidé indiquait un avancement satisfaisant : ateliers réalisés, design documenté, développements lancés. Pourtant, plusieurs décisions structurantes n’étaient pas tranchées : règles de consommation composants, synchronisation des statuts d’ordre entre ERP et MES, gestion des lots bloqués qualité, responsabilité sur les corrections post-déclaration.
Le risque n’apparaissait pas dans les jalons. Il apparaissait dans les conversations : chaque équipe avait une hypothèse différente. L’intégrateur construisait selon une interprétation technique, le site pilote projetait ses pratiques locales, la qualité voulait préserver une validation manuelle, la supply chain attendait une synchronisation stricte.
La remise à plat a consisté à créer un registre de décisions, chaque décision étant associée à un impact business, un risque go-live, un propriétaire, une date limite et un scénario de test. Ce simple changement de gouvernance a déplacé le débat : on ne discutait plus de préférences, mais d’impacts et d’options. C’est exactement le rôle d’une gouvernance premium : objectiver ce qui est trop souvent politique.
Piloter les risques par impact industriel, pas par couleur PowerPoint
Les matrices de risques projet sont souvent trop génériques. Dans un programme manufacturing, le risque doit être qualifié par conséquence opérationnelle : arrêt ligne, blocage expédition, erreur de traçabilité, surconsommation, rupture composant, incapacité de libération qualité, perte de stock, non-conformité réglementaire, surcharge support.
Un risque doit contenir cinq informations minimales : scénario, impact industriel, probabilité, délai de mitigation, propriétaire. Sans propriétaire et sans décision associée, le risque n’est qu’une observation.
| Risque | Impact industriel | Mitigation attendue |
|---|---|---|
| Interface MES → SAP non testée en reprise | Déclarations bloquées ou incohérentes après incident technique | Scénarios dégradés, file d’attente, monitoring, procédure de rejouabilité |
| Données articles non prêtes | MRP instable, ordres inexécutables, erreurs de consommation | Data readiness par famille critique, contrôle qualité, ownership métier |
| Key users non disponibles | Recette superficielle, adoption faible, support insuffisant | Backfill opérationnel, engagement management site, planning de validation |
| Écart template non arbitré | Spécifique tardif, retard design, dette de run | Comité d’arbitrage hebdomadaire, critères standard/spécifique |
La comitologie cible : moins de réunions, plus de décisions
Une gouvernance performante ne multiplie pas les réunions. Elle sépare clairement les lieux d’analyse, de décision et d’escalade. Le comité opérationnel traite les actions et les risques court terme. La design authority arbitre les règles structurantes. Le comité de pilotage tranche les impacts coût, délai, périmètre, risque et valeur. Les rituels site captent l’adoption terrain.
Le point clé est la qualité des entrées. Un comité de pilotage ne doit pas recevoir un problème brut. Il doit recevoir une note d’arbitrage : contexte, options, impacts, recommandation, décision demandée. C’est cette discipline qui transforme un comité en instance de direction.
Checklist de décision
- Créer un registre de décisions séparé du registre d’actions.
- Définir les droits de décision par type de sujet : data, process, template, spécifique, go-live.
- Qualifier chaque risque par impact industriel concret.
- Formaliser les critères standard/spécifique avant les premiers arbitrages sensibles.
- Imposer une note d’arbitrage pour toute décision structurante.
- Connecter les rituels projet aux irritants terrain et aux signaux de recette.
Conclusion opérationnelle
La gouvernance ERP/MES n’est pas une couche administrative. C’est le mécanisme qui protège la valeur industrielle lorsque les intérêts métier, IT, intégrateur, groupe et sites divergent. Une gouvernance faible produit du reporting. Une gouvernance forte produit des décisions.
Fenlynks positionne la gouvernance comme un levier de sécurisation : clarifier les responsabilités, objectiver les arbitrages, accélérer les décisions et éviter que le planning ne masque les risques.
Fenlynks intervient en cadrage, audit flash, AMOA, gouvernance projet, sécurisation de recette, trajectoire SAP/MES, conduite du changement et stabilisation post go-live.