Déploiement d'un logiciel supply chain : durée et étapes réalistes
Le déploiement d'un logiciel supply chain dure de quelques semaines pour un outil en superposition à plusieurs années pour un APS intégré. Les phases, ce qui allonge, et comment prouver la valeur avant la fin.
L'essentiel
Le déploiement d'un logiciel supply chain dure de quelques semaines pour un outil en superposition à plusieurs années pour un APS intégré. Les phases, ce qui allonge, et comment prouver la valeur avant la fin.
Les phases d'un déploiement, quelle que soit la famille d'outil
Tout déploiement de logiciel supply chain traverse les mêmes phases, et c'est leur durée relative qui change d'une famille d'outil à l'autre. Le cadrage fixe le périmètre, les objectifs mesurables et les responsabilités. La phase de données inventorie, extrait, nettoie et connecte ce que l'outil va lire, référentiels articles, nomenclatures, historiques de ventes, délais fournisseurs, stocks. Le paramétrage et l'intégration configurent l'outil sur vos règles et construisent les interfaces avec l'ERP et les autres briques. La recette vérifie que les résultats sont justes sur des cas connus, la formation et la bascule mettent les utilisateurs devant l'outil en conditions réelles, et la stabilisation corrige ce que l'usage révèle. Ces phases s'enchaînent rarement de façon linéaire ; dans les projets qui réussissent, elles se recouvrent, et la première décision utile sort bien avant la fin de la dernière.
Des semaines à des années : les durées selon la famille d'outil
Les ordres de grandeur qui suivent viennent de ce que l'on observe sur le marché des ETI industrielles, et chaque projet les déplace selon son contexte. Un outil de pilotage ou de décision qui se superpose à l'existant, en lisant les données de l'ERP et des tableurs sans migration, se met en service sur un périmètre pilote en quatre à huit semaines, et son extension à d'autres sites ou familles se compte en mois. Un module de prévision de la demande ou d'optimisation des stocks, branché sur l'ERP avec un paramétrage réel, demande plutôt un trimestre ou deux. Un APS intégré à capacité finie, avec modélisation des contraintes de production et interfaces bidirectionnelles, se déploie en neuf à dix-huit mois selon le nombre de sites. Une suite complète ou un projet couplé à une refonte de l'ERP se mesure en années, souvent deux ou trois. Ces écarts ne disent rien de la qualité des outils, ils disent ce que chacun touche dans votre système d'information, et c'est cette profondeur d'intrusion, plus que la richesse fonctionnelle, qui fixe le calendrier.
Ce qui allonge : les données
La donnée est la première cause de dérive, et la moins visible au moment de signer. On découvre en cours de projet que les codes articles diffèrent entre l'ERP et le WMS, que les nomenclatures ne sont à jour que sur un site, que les délais fournisseurs saisis dans le système n'ont pas été revus depuis cinq ans. Et l'historique de ventes contient les promotions sans le dire. Chaque découverte déclenche un chantier de correction qui n'était pas au planning, et les projets qui exigent une donnée propre avant de démarrer y passent des mois sans avoir rien mis en service. L'expérience montre que la donnée ne devient propre qu'une fois utilisée, parce que c'est l'usage qui révèle les erreurs qui comptent, pas l'audit. La question à poser à l'éditeur est donc de savoir si son outil tolère une donnée imparfaite le temps de la corriger, ou s'il faut tout nettoyer avant de voir le premier résultat ; la réponse pèse davantage sur la durée que n'importe quelle fonctionnalité.
Ce qui allonge : l'intégration et l'adoption
L'intégration vient en deuxième position, avec les interfaces ERP à construire, les développements spécifiques que personne ne voulait au départ et les fenêtres de mise en production que la DSI accorde avec parcimonie. L'adoption vient ensuite, et elle est souvent sous-estimée parce qu'elle ne se planifie pas comme une tâche technique. Dans une ETI, les personnes qui doivent paramétrer, tester et apprendre l'outil sont celles qui font tourner les opérations, et chaque pic d'activité ou chaque crise fournisseur repousse le projet d'autant. Les experts clés, dont la mémoire fait la valeur du paramétrage, sont les moins disponibles, et un outil qui contredit leurs habitudes sans leur montrer vite un gain est un outil qu'ils contourneront. Il vaut mieux compter dès le départ un tiers de temps en plus pour ces deux causes que découvrir en cours de route qu'il fallait le prévoir. Une gouvernance qui tranche vite les accès aux données et les priorités fait gagner plus de semaines que n'importe quel outil de gestion de projet.
Prouver la valeur avant la fin du déploiement
Le risque principal d'un déploiement long tient à ce que la valeur promise n'est mesurée qu'à la fin, quand il est trop tard pour corriger. Il faut donc remplacer les jalons techniques par des jalons de valeur : à telle date, l'outil a produit sa première alerte utile, sa première recommandation suivie, son premier arbitrage chiffré, et l'on compare ce qu'il a changé à la situation mesurée avant le projet. Un périmètre pilote, une famille ou un site, permet de faire cette mesure en quelques semaines même dans un projet qui durera un an, et de décider en connaissance de cause de l'extension. Le déploiement parfait n'existe pas plus que la prévision parfaite : aucun projet ne livre à la date prévue la totalité de ce qui était écrit. Ce qui compte, c'est la date à laquelle l'outil aide à prendre une meilleure décision le jour où le réel dévie du plan, et cette date peut arriver au deuxième mois d'un projet de dix-huit si l'on a choisi de commencer par le périmètre où la marge se perd.
Le calendrier à demander à l'éditeur
Un calendrier de déploiement sérieux se reconnaît à quelques questions. Demandez la date de la première décision utile plutôt que la date de mise en production, ce sont rarement les mêmes. Demandez ce qui dépend de vous et de vos équipes, en jours-hommes, parce que c'est presque toujours là que les projets glissent, et demandez ce que devient le planning si vos données ne sont pas prêtes à la date prévue. Demandez sur quels clients comparables le calendrier proposé a été tenu, et ce qui a fait déraper les autres. Demandez enfin ce qu'il est possible d'arrêter ou de réduire en cours de route si le pilote déçoit, et ce que cela coûte. Un éditeur qui répond à ces questions avec précision a déjà vécu vos difficultés ; celui qui répond par un diagramme de Gantt en couleurs vous vend un calendrier théorique, et le réel se chargera de le corriger.
Cet article part d'une conviction : la prévision parfaite n'existe pas, ce qui compte c'est la décision d'après.
- Les phases d'un déploiement, quelle que soit la famille d'outil
- Des semaines à des années : les durées selon la famille d'outil
- Ce qui allonge : les données
- Ce qui allonge : l'intégration et l'adoption
- Prouver la valeur avant la fin du déploiement
- Le calendrier à demander à l'éditeur
Clevizio
Clevizio est la couche de décision qui se branche sur vos outils existants : elle détecte l'imprévu, simule vos options et garde la mémoire de chaque arbitrage. Découvrir comment fonctionne le copilote de décision.
Questions fréquentes
Combien de temps dure le déploiement d'un logiciel supply chain ?
De quelques semaines à plusieurs années selon la famille d'outil. Un outil en superposition, qui lit l'existant sans migration, se met en service sur un périmètre pilote en quatre à huit semaines. Un module de prévision ou d'optimisation des stocks demande un ou deux trimestres, un APS intégré neuf à dix-huit mois, une suite complète couplée à une refonte ERP deux à trois ans. La qualité des données et la disponibilité des équipes internes déplacent ces ordres de grandeur.
Quelles sont les étapes du déploiement d'un logiciel supply chain ?
Cadrage, inventaire et connexion des données, paramétrage et intégration avec l'ERP, recette, formation et bascule des utilisateurs, puis stabilisation. Le cadrage fixe le périmètre et les objectifs, la recette vérifie les résultats sur des cas connus. Dans les projets qui réussissent, ces phases se recouvrent et la première décision utile sort sur un périmètre pilote bien avant la fin de la dernière.
Pourquoi les déploiements de logiciels supply chain prennent-ils du retard ?
Trois causes reviennent presque toujours, des données moins propres que prévu, des intégrations ERP plus lourdes qu'annoncé et des équipes internes indisponibles. Les défauts de données se découvrent en cours de projet, et les équipes font tourner les opérations en parallèle. Prévoir un tiers de temps en plus pour ces causes et mesurer la valeur sur un pilote limitent les dégâts.
À lire aussi
Mettez enfin un chiffre sur ce que vos imprévus vous coûtent chaque année.
Commençons par estimer ce que vos imprévus vous coûtent réellement. C'est gratuit, ça prend 30 minutes, et vous repartez avec un chiffre que personne dans votre entreprise ne connaît aujourd'hui.
