Migration ERP : avant ou après la planification Supply Chain ?

À retenir :
Une migration ERP et un projet de planification Supply Chain ne jouent pas sur le même terrain. L'ERP remplace votre référentiel de transactions. La planification influence les décisions qui sont prises par dessus. Attendre, c'est renoncer à 12 à 24 mois de prévisions, de stocks tampons et de décisions d'achat, pour éviter de rebrancher un seul flux de données.

Posez la question à une équipe de planification en pleine migration ERP : quand comptez-vous vous attaquer aux prévisions et aux stocks ? La réponse tombe presque toujours pareil : après. C'est prudent, c'est ordonné, un projet à la fois, et c'est exactement ce que la DSI a envie d'entendre.

Souvent, c'est aussi l'inverse de ce qu'il faudrait faire. Une migration ERP est le meilleur argument pour traiter la planification tout de suite, pas pour la repousser. Pendant la bascule, les planificateurs perdent leurs rapports “maison” et leurs exports habituels, les données de référence bougent, le taux de service devient fragile, et la demande, elle, ne s'arrête pas. C’est donc précisément le mauvais moment pour manquer de visibilité sur les fluctuations de la demande.

« On le fera après l'ERP » : ce n'est pas un report, c'est une décision

L'attente n’est pas une option neutre. C'est le choix assumé de garder 12 à 24 mois de plus le processus actuel, le niveau de ruptures et et de surstock, pour préserver un bel enchaînement de projets.

Le vrai problème : la date que vous attendez n'est pas vraiment une date. Le rapport ERP 2026 de Panorama Consulting Group relève que plus d'un quart des entreprises dépassent le budget de leur projet, d'abord à cause de besoins techniques découverts en route, et qui décale les plannings autant que les budgets. Quiconque a vécu une bascule connaît la mécanique : on sait quand un projet ERP démarre, rarement quand il se termine.

Et l'incertitude se cumule. Chez un industriel de taille intermédiaire, le responsable planification décrivait une refonte ERP en discussion depuis une dizaine d'années, sans échéance visible, et sa conclusion était sans détour : plus la décision sur la planification est repoussée, moins elle a de chances d'être validée un jour. Ailleurs, un groupe de distribution européen rédigeait encore le cahier des charges de son futur ERP, appel d'offres à venir, nouveau système réaliste dans deux à trois ans. Dans les deux cas, « après l'ERP » n'était pas une question de priorité. C'était une façon de faire une croix sur le projet.

‍

‍

L'ERP enregistre, la planification décide

Le débat sur l'ordre cache une confusion sur la nature des projets. Un ERP enregistre ce qui s'est produit et exécute : commandes, réceptions, mouvements, factures. Une couche de planification tranche ce qui doit arriver ensuite : combien prévoir, quel stock tampon tenir, quoi commander et quand. Changer d'outil d'enregistrement n'améliore aucune de ces décisions.

Autant être précis sur ce qu'une migration apporte côté planification : dans la majorité des cas, la même logique MRP sur une base plus propre. Le MRP part d'une prévision à un seul chiffre, la propage dans des délais d'approvisionnement figés et applique un stock de sécurité statique. Un ERP récent fait tourner ce calcul plus vite. Pas mieux : la limite n'est pas la base de données, c'est l'idée que la demande et les délais tiennent dans un chiffre unique.

L’ERP sort un plan, puis réclame tellement d'arbitrages manuels sur les mini-maxi que le vrai outil de planification reste le tableur utilisé à côté. La concurrence réelle, ce n'est pas un éditeur contre un autre : c'est un ERP plus un fichier Excel, très bon pour produire de longues listes, très mauvais pour dire au planificateur quelles vingt lignes comptent aujourd'hui.

Les trois craintes derrière le choix d’attendre

L'argument de l'ordre relève rarement de la stratégie. Il se ramène à trois craintes concrètes, qui méritent des réponses concrètes plutôt que des paroles rassurantes.

« Il faudrait faire l'intégration deux fois »

C'est l'objection de la DSI, et elle suppose qu'une intégration de planification ressemble à une interface ERP. Ce sont deux choses différentes. Une couche de planification lit un jeu de tables restreint et stable : historique de demande, stock actuel, commandes en cours et en transit, données de référence articles et fournisseurs derrière les délais d'approvisionnement, les quantités minimales et les tailles de lot. Ces tables existent dans tous les ERP, et ce sont celles que la migration doit de toute façon reproduire.

Les rebrancher sur une nouvelle source, c'est quelques jours de paramétrage et de recette, pas une seconde implémentation. Face à un programme ERP qui court sur plusieurs années, l'écart est négligeable, et le travail se fait une fois, à la date que vous choisissez. S'il existe un entrepôt de données, le schéma le plus propre consiste à lire dedans : le déploiement de la planification devient alors indépendant du calendrier de migration.

« Nos données de référence ne sont pas prêtes »

C'est la plus légitime objection des trois, et aussi celle qui risque le plus de s'installer durablement. Un responsable Supply Chain chez un grand équipementier automobile résumait le piège : impossible d'évaluer des solutions sans gouvernance des données de référence, mais tant que l'entreprise livre et gagne de l'argent, personne ne finance le chantier. Il reste au second plan indéfiniment, y compris pendant le projet ERP, dont le périmètre porte sur les transactions et non sur les paramètres de planification.

Un APS demande beaucoup moins de données de référence qu'un ERP, et n'a pas besoin qu'elles soient parfaites au premier jour. Quand un champ manque ou n'est pas fiable, un délai d'approvisionnement ou une fréquence de commande se saisit et se maintient dans l'outil de planification, sans bloquer le projet. Mieux : le travail de cartographie produit exactement la liste des trous que votre programme ERP devra combler plus tard. Commencer par la planification, c'est offrir à la migration un cahier des charges plus net.

« La DSI n'a pas de bande passante »

Ceux qui portent la bascule sont ceux qui porteront le nouveau flux. La réponse consiste à échelonner l'intégration, pas le projet : démarrer par des exports de fichiers plats programmés en CSV ou XLSX, une demande modeste ; mettre les planificateurs au travail sur de vraies prévisions et de vrais stocks tampons ; puis passer à une connexion base de données ou à une API une fois la bascule digérée. C'est un parcours d'onboarding standard, pas un contournement, et il garde le projet de planification hors du chemin critique de la migration.

‍

À retenir : aucune des trois objections ne porte sur l'intérêt d'une meilleure planification. Chacune parle d'effort d'intégration, de qualité des données de référence ou de charge DSI, et chacune a une réponse concrète qui n'exige pas d'attendre la bascule.

‍

‍

Le jour de la bascule, mieux vaut avoir déjà une couche de planification en route

Une migration perturbe l'exploitation. Ce n'est pas un reproche, c'est arithmétique : en un week-end, vous changez de référentiel pour toutes les transactions de l'entreprise. Les rapports cassent, les exports changent de forme, et l'outillage informel que les planificateurs ont bâti pendant des années ne fonctionne plus le lundi matin.

Une couche de planification qui recalcule chaque jour la demande probabiliste, la variabilité des délais et les stocks tampons est précisément ce qui absorbe ce bruit. Quand la variabilité monte, les tampons s'élargissent d'eux-mêmes, au lieu d'attendre qu'un planificateur le remarque trois semaines et deux ruptures plus tard. Pendant les phases de test, elle apporte autre chose de précieux : une vision indépendante du stock cible, seule façon de distinguer une erreur de reprise de données d'un vrai signal de demande.

Le point plus large : les gains de disponibilité viennent de la couche de décision, pas du paysage applicatif. L'activité de distribution de pièces de rechange de Saint-Gobain Sekurit n'a pas refondu son SI pour améliorer son service. Elle a posé des stocks tampons dynamiques et probabilistes sur l'existant, à l'échelle de son réseau de centres de distribution, et a réduit ses stocks de 9,25 % en portant son taux de service de 95,8 % à 97,2 %. Deux courbes dans le bon sens en même temps, ce qu'un stock de sécurité statique ne sait pas faire, et sans nouvel ERP.

Ce qu'il faut décider ce trimestre, plutôt qu'après la bascule

Pas besoin de trancher le débat dans l'abstrait. Trois questions suffisent.

1. Combien coûte réellement un mois de report, en surstock et en ventes perdues ? Si personne n'a chiffré, la comparaison n'est pas « un projet contre deux », c'est « un projet contre un montant invisible ».
2. Pouvez-vous obtenir des exports programmés d'une demi-douzaine de tables depuis le système actuel sans monter un projet informatique ? Si oui, l'objection de la bande passante tombe, puisque vous ne demandez pas d'intégration à la DSI pendant la bascule.
3. Existe-t-il un entrepôt de données à lire à la place de l'ERP ? Si oui, le projet de planification et la migration se croisent à peine.

Répondez à ces trois questions et l'ordre cesse d'être une affaire de principe. Vos planificateurs décident mieux dès maintenant, et votre programme ERP hérite d'une spécification de données plus nette et d'une Supply Chain plus stable pour atterrir.

Vous êtes en pleine migration et voulez voir ce que cela donne sur vos propres données ? Réservez une démo : nous déroulons le séquencement avec votre système actuel, pas avec celui que vous n'avez pas encore.

‍