Les projets SAP dans l’industrie ne ratent pas parce que le système SAP est mal fait. Ils ratent parce que la complexité a été sous-estimée et parce que personne n’a dit les choses difficiles au bon moment.
Parmi ces ratages, il y a des règles métier mal comprises, implicites et jamais identifiées, des contraintes réglementaires découvertes trop tard, des interfaces équipements mal cartographiées.
A cela s’ajoute aujourd’hui la pression des migrations ECC vers S/4HANA dans un écosystème cloud public, private ou hybride que peu d’organisations maîtrisent encore vraiment..
Dans ce nouvel article, j’avais envie d’explorer la complexité et les situations critiques que j’ai eu aussi l’occasion de vivre sur des projets SAP et dans des secteurs que je connais bien comme la chimie, la pharmaceutique, l’industrie du papier et des emballages carton…
La complexité sur les projets SAP
Les projets SAP échouent pour des raisons techniques mais en y regardant de plus près et avec un peu de recul, ils échouent parce que la complexité a été sous-estimée, mal cartographiée ou ignorée. Ils échouent quand on atteint le paroxysme de la complexité c’est-à-dire une crise.
Comprendre cette complexité, savoir d’où elle vient, comment elle se manifeste et comment la gérer, c’est ce qui sépare un projet qui tient ses promesses d’un projet qui finit en un champ de bataille où tout le monde s’affole un lundi matin de Go-Live.
D’où vient vraiment la complexité ?
On a tendance à attribuer la complexité d’un projet SAP à la taille du périmètre, au nombre de consultants, de business users sur le plateau projet, au volume de données à migrer etc… Ce sont des facteurs qui sont bien évidemment la base de tout projet. Ils sont bien réels et sont à traiter avec méthodologie mais ils ne sont pas les plus complexes.
La complexité la plus difficile à gérer est celle qui est invisible, au moment de la conception ou sur des phases critiques mal calibrées et elle peut se cacher dans plusieurs endroits.
Premier endroit “classique” : les règles métier implicites.
Dans toute organisation industrielle, il existe des pratiques qui ne sont écrites nulle part parce qu’elles sont évidentes pour ceux qui les appliquent depuis des années. Ces règles implicites sur la gestion des priorités de production, les tolérances acceptables en écart de pesée, les unités de mesures spécifiques à certains clients, les conditions de libération d’un lot de production, tout cela doit être explicitement capturé et configuré dans SAP. Si on ne le fait pas, le système fonctionnera correctement en théorie ou dans 80% des cas mais il fonctionnera mal en pratique ou pas du tout dans 20% des cas.
Deuxième endroit : les contraintes liées au secteur d’activité.
Dans les industries chimique, pharmaceutique, papier & emballages que je connais plutôt bien, SAP ne se limite pas à un ERP généraliste. Ses modules solutions permettent de reproduire la réalité des processus et des exigences réglementaires.
Par exemple, le module QM (Quality Management) utilisé en pharmaceutique structure le contrôle qualité et la traçabilité des lots indispensables pour respecter les bonnes pratiques de fabrication imposées par les autorités de santé.
Le module PP (Production Planning) gère les recettes, les pertes de matières premières et les co-produits, là où la production est continue ou semi-continue.
Le module VC (Variant Configuration) utilisé dans le Make to Order des emballages carton et le secteur de l’automobile permet de maîtriser la complexité des options Produits tout en évitant la multiplication des références produit.
Enfin, EHS (Environment, Health & Safety) couvre la gestion des substances dangereuses et la conformité réglementaire.
Ces modules sont puissants mais leur richesse implique un paramétrage fin et une dépendance forte à la qualité des données.
La complexité est réelle et elle se révèle aussi pleinement lors des migrations vers S/4HANA ou dans des architectures Cloud, surtout de type Public où on doit adopter un mindset Standard et limiter le Custom.
En toute logique, un système peu paramétré fait peu de dégâts. Un système configuré sans comprendre les contraintes réelles du secteur finira inévitablement par créer des situations critiques à la mesure de ses capacités.
Dans plusieurs projets industriels, on observe que ces modules spécifiques sont initialement activés avec un paramétrage minimal, faute de temps ou de maîtrise, puis progressivement enrichis après le go-live. Cette approche limite les risques à court terme mais peut conduire à une dette fonctionnelle qui complique les évolutions ultérieures.
Les organisations les plus matures et qui misent sur la préparation plutôt que la rapidité abordent ces briques non pas comme de simples modules à configurer mais comme des leviers de transformation en impliquant dès le départ les experts métiers capables de traduire les contraintes réelles du terrain dans le système.
Troisième endroit : les interfaces entre SAP et les équipements, le matériel industriel
Dans une usine moderne, SAP ne fonctionne pas seul. Il est connecté à des systèmes MES (Manufacturing Execution Systems), des automates, des balances, des capteurs, des LIMS (Laboratory Information Management System), des systèmes de gestion d’entrepôt automatisés avec des robots, des convoyeurs ou de la RFID (Radio Frequency Identification) pour gérer les flux, les stocks, la préparation des commandes, faire le picking, le packing, peser les camions et valider les sorties de marchandises.
Chaque interface est un point de friction potentiel. Chaque équipement a son propre fournisseur avec sa propre logique, ses propres unités, ses propres fréquences de transmission des données. Tant que ces interfaces fonctionnent, personne ne les voit. Quand elles dysfonctionnent, elles paralysent.
J’ai vu sur une première journée de Go-Live, une file de dizaines de camions en attente, bloquant une bonne partie de la route nationale avant l’usine parce que les douchettes connectées dans l’entrepôt n’avaient pas été testées correctement. Cette erreur a non seulement ralenti les livraisons et la fluidité des commandes mais a aussi jeté le discrédit sur les équipes projets alors que tout le reste s’était déroulé sans heurts. Cela a fini par rentrer dans l’ordre et a fini avec une soirée de Go-Live réussie mais ce problème impactant directement le réel aurait pu être évité.
Les formes que prend la complexité selon les secteurs
Chimie : la complexité du process et des équipements connectés
Dans l’industrie chimique, la complexité commence dans le réacteur ;-). Un ordre de fabrication SAP PP doit refléter fidèlement ce qui se passe physiquement : les quantités de matières chargées, les conditions opératoires, les pertes de procédé, les sous-produits récupérables. Si la modélisation de la recette dans SAP ne correspond pas à la réalité du process, tout ce qui en découle, bilans matières, coûts de revient, traçabilité des lots, est faux.
Les équipements connectés amplifient cette complexité. Dans un site chimique moderne, les réacteurs, cuves de stockage et systèmes de dosage remontent les données vers SAP via des interfaces MES. Un réacteur de synthèse peut transmettre des centaines de points de mesure, température, pression, pH, débit, qui alimentent automatiquement les journaux de fabrication dans SAP.
Quand le mapping qui a été fait entre les tags de l’automate et les champs SAP est incorrect, les données semblent cohérentes mais sont fausses. Personne ne le détecte immédiatement parce que les valeurs ont l’air raisonnables.
Dans une migration ECC vers S/4HANA, cette complexité est démultipliée. Les interfaces qui fonctionnaient avec l’ancienne version doivent être requalifiées. Les recettes PP doivent être vérifiées dans le nouveau modèle de données.
Les balances de pesée connectées posent un problème similaire. Dans un site de chimie fine, les pesées de matières premières sont confirmées automatiquement dans SAP à partir de la balance. Si la conversion d’unité entre la balance et SAP n’est pas correctement paramétrée, les consommations réelles et les consommations théoriques divergent. Le bilan matière se dégrade, les coûts de revient dérivent et quand l’anomalie est détectée, il faut remonter des mois en arrière pour comprendre l’origine de l’écart.
Options de résolution : Réaliser un audit systématique des interfaces équipements avant la phase de conception, en impliquant les automaticiens et les techniciens process, pas seulement l’IT. Tester les interfaces en conditions réelles de production, avec des volumes et des fréquences réalistes. Dans le cadre d’une migration S/4HANA, traiter la requalification des interfaces comme un chantier à part entière avec son propre budget et son propre planning, pas comme une ligne dans le planning global.
Pharmacie : la complexité réglementaire
La gestion des statuts de lot dans SAP QM illustre bien cette réalité. En théorie, un lot est en contrôle, libéré, ou bloqué. En pratique, dans un site pharmaceutique, il existe des états intermédiaires : libération provisoire pour tests de stabilité en cours, quarantaine pour enquête sur anomalie analytique, envoi en retest après résultat hors spécification, destruction programmée.
Si SAP ne modélise pas fidèlement ces états, les opérateurs créent des pratiques parallèles. Ces pratiques parallèles en environnement industriel sont exactement ce qu’un inspecteur FDA (Food and Drug Administration) ou ANSM (Agence nationale de sécurité du médicament et des produits de santé) va pointer lors d’un audit.
Dans une migration vers S/4HANA Cloud, la question de la validation du système devient encore plus complexe. Un site pharmaceutique qui opère sous la norme CFR Part 11 (s’applique aux dossiers électroniques relatifs à l’innovation et à la technologie en matière de santé publique, d’alimentation et de dispositifs médicaux) doit valider son système informatisé.
Or, dans un modèle cloud public avec des mises à jour automatiques gérées par SAP, la validation continue devient un défi permanent. Chaque mise à jour peut potentiellement affecter des fonctionnalités validées. Les organisations pharmaceutiques qui choisiraient le cloud public sans avoir pensé à leur stratégie de validation continue se retrouvent dans une situation intenable.
Les équipements de laboratoire connectés à SAP ou à un LIMS interfacé avec SAP ajoutent une dimension critique. Les appareils de mesure des laboratoires transmettent leurs résultats directement dans le système. Si l’interface n’a pas été correctement revalidée après la migration S/4HANA, le site est en situation de non-conformité, même si les données sont exactes.
Options de résolution : Impliquer dès le choix du modèle de déploiement les responsables qualité et les personnes qualifiées, le cloud public n’est pas compatible avec toutes les stratégies de validation. Construire un plan de validation du système S/4HANA qui intègre la gestion des mises à jour automatiques dès la conception. Traiter la revalidation des interfaces équipements comme une activité critique du projet de migration, pas comme un détail de fin de projet.
Papier et emballage : la complexité des variantes, des machines et du code custom
L’industrie papier-carton-emballage combine deux sources de complexité qui se renforcent mutuellement : une gestion des variantes-produit extrêmement dense, des équipements de production à logique propriétaire (dépendants du fabricant) et souvent, une dette de code custom particulièrement élevée accumulée pour gérer ces spécificités.
Les logiciels de calcul des plans de coupe sur les machines, les systèmes de gestion des bobines, les interfaces avec les machines d’impression graphique : tout cela a souvent été développé en code Z sur ECC parce que SAP standard ne couvrait pas ces cas. Dans une migration S/4HANA, ce code doit être revu, retesté et souvent réécrit.
La maintenance des équipements ajoute une troisième couche. Une imprimante graphique à l’arrêt, c’est plusieurs dizaines de milliers d’euros de perte par heure. SAP PM gère la maintenance préventive mais dans S/4HANA, les gammes de maintenance et les fiches équipements ont évolué. Les données PM migrées depuis ECC doivent être vérifiées et souvent enrichies pour exploiter les nouvelles capacités, maintenance prédictive, intégration IoT, tableaux de bord de disponibilité équipements.
Options de résolution : Réaliser un inventaire complet du code custom avant de choisir le modèle de déploiement, c’est cet inventaire qui doit éclairer le choix, pas l’inverse. Traiter la structuration de la base articles comme un chantier stratégique à part entière. Impliquer les techniciens de maintenance dans la migration des données PM, pas seulement l’IT.
Trois principes pour maîtriser la complexité
Rendre la complexité visible dès le début
La complexité qu’on n’a pas cartographiée au départ se retrouve toujours dans le planning à la fin mais sous forme de retard, de surcoût ou de crise. Un atelier de conception qui dure deux jours de plus parce qu’on a pris le temps de comprendre les interfaces équipements, les règles métier implicites et l’état réel du code custom peut éviter un mois de correction post go-live.
Ne pas confondre complexité fonctionnelle et complexité organisationnelle
Certains projets sont fonctionnellement simples mais organisationnellement complexes : plusieurs sites, plusieurs cultures, des résistances au changement. D’autres sont l’inverse. Les traiter avec les mêmes méthodes est une erreur. Une migration S/4HANA dans un contexte pharmaceutique multi-sites n’a pas besoin du même dispositif qu’un déploiement logistique sur un site unique.
Construire des filets de sécurité
Dans un projet complexe, viser zéro anomalie au go-live est une illusion qui génère du déni. Ce qui fonctionne, c’est identifier les risques résiduels, les prioriser et avoir un plan de gestion pour chacun. Pas parce qu’on accepte l’échec, mais parce qu’on préfère avoir un plan B plutôt que de devoir improviser à 3h du matin. D’ailleurs, le ficher de gestion des risques fait partie intégrante de la méthodologie de projets, il me semble.
Les situations critiques
Comment naît une situation critique
Une situation critique ne surgit pas de nulle part. Elle est presque toujours le résultat visible d’une accumulation de signaux faibles qui n’ont pas été pris en compte. Un test de recette validé sous réserve. Une interface équipement qui fonctionnera en production. Un utilisateur clé qui n’a pas eu le temps de se former correctement. Une migration de données faite dans l’urgence. Et tout ce qui relève de l’assumption en anglais (hypothèse en français). Référence à un de mes managers qui disait à ses équipes Never assume, always verify.
Les typologies de situations critiques
1. La crise de go-live
C’est la situation critique la plus visible et la plus traumatisante. Le système bascule et dans les premières heures ou les premiers jours, des dysfonctionnements apparaissent qui bloquent des processus critiques.
Dans un entrepôt logistique équipé de terminaux RFID et de convoyeurs automatisés reliés à SAP EWM, un go-live raté peut paralyser les flux physiques. Les opérateurs ne savent plus où sont leurs produits. Les convoyeurs attendent des confirmations que SAP ne génère pas. Les camions de livraison attendent. En quelques heures, l’impact est réel.
Dans le contexte d’une migration S/4HANA, la crise de go-live peut avoir une dimension supplémentaire : même en ayant reçu une formation avant, les utilisateurs ne retrouvent plus leurs repères. Les transactions ont changé. Fiori remplace SAP GUI. Les processus ont été redessinés. Un utilisateur qui maîtrisait parfaitement ECC depuis dix ans se retrouve en difficulté car il est sous pression et il lui faut aussi du temps pour s’habituer au nouveau système.
Comment la gérer ?
La première décision à prendre est la plus difficile, on continue ou on fait marche arrière ? Cette décision doit être préparée avant le go-live, avec des critères clairs et des seuils de tolérance définis. Constituer immédiatement une cellule de crise avec des rôles clairs. Stabiliser les processus critiques en mode dégradé documenté si nécessaire. Et communiquer vers les utilisateurs, vers le management, vers les clients si l’impact est externe de manière factuelle et sans minimiser.
2. La dégradation silencieuse
C’est souvent la plus dangereuse parce qu’elle est invisible. Le système fonctionne. Les processus tournent. Mais des données incorrectes s’accumulent progressivement, stocks mal valorisés, consommations mal imputées, lots mal tracés, jusqu’au moment où la réalité rattrape le système.
Dans un site chimique, des balances mal interfacées avec SAP génèrent des écarts de consommation infimes à chaque ordre de fabrication. Sur six mois, ces écarts s’accumulent. Le stock théorique diverge du stock physique. Quand l’inventaire annuel arrive, l’écart est significatif et il faut remonter six mois de production pour en comprendre l’origine.
Dans le contexte d’une migration S/4HANA, la dégradation silencieuse peut venir d’une migration de données incomplète. Des données qui n’ont pas été correctement converties, des paramètres de calcul qui ont changé de logique entre ECC et S/4HANA, des cumuls financiers qui ne correspondent plus aux transactions détaillées. Ces incohérences peuvent passer inaperçues pendant des semaines avant d’être détectées, souvent lors d’une clôture comptable ou d’un contrôle qualité.
Comment la gérer ?
Mettre en place dès le go-live des indicateurs de qualité des données, bilans matières hebdomadaires, contrôles de cohérence entre stocks physiques et stocks SAP, réconciliation financière rapprochée en période post go-live. Dans le contexte d’une migration, prévoir une période de réconciliation intensive dans les 30 à 90 jours post go-live avec des ressources dédiées.
3. La crise réglementaire
Spécifique aux secteurs pharmaceutique, chimique et agroalimentaire, c’est une situation où le dysfonctionnement du système génère une non-conformité réglementaire réelle ou potentielle.
Dans un site pharmaceutique en cours de migration S/4HANA, si le système de gestion des documents qualité n’a pas été correctement migré, des procédures opératoires standard peuvent ne plus être accessibles aux opérateurs pendant la période de transition. Or, travailler sans procédures à jour est une déviation. La migration elle-même devient un risque réglementaire si elle n’est pas gérée comme un projet de validation.
Comment la gérer ?
Isoler le risque d’abord, identifier précisément les lots ou les processus affectés et les sécuriser. La reconstruction documentaire ensuite. La correction du système avec validation formelle avant remise en service. Et documenter l’ensemble du processus dans le système de gestion des déviations y compris les actions correctives et préventives pour éviter la récurrence.
4. La crise de performance
Le système fonctionne mais est devenu trop lent pour être utilisé efficacement. Dans S/4HANA, ce type de crise peut surgir si le dimensionnement de l’infrastructure cloud a été sous-estimé ou si des requêtes non optimisées sur la base HANA consomment des ressources excessives.
Dans une usine d’emballage avec une machine générant des centaines d’ordres de fabrication par jour, un MRP mal paramétré dans S/4HANA peut saturer les ressources système. Mais contrairement à ECC on-premise où l’équipe IT pouvait directement intervenir sur le serveur, en environnement cloud privé ou public, l’intervention nécessite de passer par SAP ou le partenaire cloud avec des délais de réponse qui peuvent aggraver la crise.
Comment la gérer ?
Diagnostiquer précisément l’origine avant d’agir. Dans un environnement cloud, avoir préalablement défini les niveaux de service et les escalades contractuelles (SLA – Service Level Agreement) avec SAP ou le partenaire cloud. Ne pas attendre la crise pour tester les performances, les tests de charge en conditions réelles doivent faire partie du plan de recette.
Ce qui fait la différence dans la gestion de crise
La gestion d’une situation critique sur un projet SAP met à l’épreuve trois compétences qui ont peu à voir avec la maîtrise technique du système.
La capacité à diagnostiquer vite et sous pression
Dans une crise, le temps est compté et les informations sont incomplètes. Les consultants qui gèrent bien les crises cartographient d’abord le périmètre réel du problème avant de chercher la cause racine.
Qu’est-ce qui ne fonctionne pas exactement ? Depuis quand ? Quels processus sont bloqués ? Cette cartographie rapide permet de prioriser et d’éviter de perdre du temps sur des symptômes secondaires.
La capacité à communiquer clairement vers des interlocuteurs non techniques
Un directeur d’usine en crise n’a pas besoin de comprendre pourquoi le mapping MES > SAP est incorrect ou pourquoi la conversion des tables de données COPA a échoué. Il a besoin de savoir combien de temps ça va durer, ce qu’il peut faire en attendant et ce qui va changer pour que ça ne se reproduise pas.
La capacité à dire ce qui ne va pas avant que ça n’explose
La compétence la plus rare et la plus précieuse dans un projet SAP et encore plus dans une migration S/4HANA n’est pas de gérer les crises. C’est d’éviter qu’elles arrivent en disant les choses difficiles au bon moment.
Qu’un planning est irréaliste. Qu’un choix de déploiement cloud est incompatible avec les contraintes métier. Qu’une interface équipement n’est pas prête. Ces conversations sont inconfortables dans un projet sous pression. Elles sont toujours moins coûteuses que la crise qu’elles évitent.
En synthèse
La complexité des projets SAP n’a jamais été aussi élevée qu’aujourd’hui. À la complexité fonctionnelle et sectorielle toujours présente s’ajoute désormais la complexité technologique d’un écosystème en transition, ECC qui s’éteint, S/4HANA qui exige une transformation profonde, un choix de déploiement cloud vs on-premise qui engage l’organisation pour des années.
Dans ce contexte, les organisations qui s’en sortent sont celles qui ont changé de mindset. Qui traitent leurs projets SAP comme des transformations organisationnelles et non comme des projets IT. Qui investissent dans la gouvernance des données et la gestion du changement autant que dans la configuration du système. Qui écoutent leurs consultants quand ils signalent des risques, au lieu de les mettre sous pression pour tenir un planning irréaliste.
Et les consultants qui créent de la valeur réelle dans cet environnement sont ceux qui combinent expertise technique, compréhension du terrain industriel et capacité à naviguer dans la complexité organisationnelle, pas seulement ceux qui connaissent les transactions S/4HANA.
