Projet WMS : quatre-vingt-dix jours, quatre phases, cinq pièges

Un projet WMS n'est pas un projet informatique avec une part de logistique : c'est un projet de données avec une part de logiciel à la fin. Il demande environ quatre-vingt-dix jours quand il est mené sur une solution configurée, et il déborde presque toujours pour la même raison — les données articles. Cette page décrit les quatre phases, ce que vous devez fournir, et les cinq pièges qui coûtent le plus de temps.

Elle s'adresse aux dirigeants et responsables d'exploitation de PME qui tiennent leur propre entrepôt et abordent une première mise en place. Elle n'est pas écrite pour les déploiements multi-sites menés en vagues, ni pour les entrepôts automatisés : les phases restent les mêmes, les durées non.

D'abord : la question qui précède celle-ci

Si vous hésitez encore sur le principe, ce n'est pas la bonne page. La question « en avez-vous besoin » se traite dans système WMS, et celle du périmètre fonctionnel dans système de gestion d'entrepôt. Ce guide commence une fois la décision prise.

Ce que vous engagez

Il est plus honnête de commencer par là, parce que c'est la partie que les plannings éditeurs présentent en dernier.

Quatre rôles, de votre côté. Une personne pour piloter le projet, à hauteur de deux jours par semaine et non en plus de son poste. Un référent par équipe, qui absorbera les premières questions de ses collègues. Quelqu'un qui connaît votre ERP, en interne ou chez votre intégrateur, pour les interfaces. Et le responsable d'entrepôt disponible le jour du test, la journée entière.

Les projets qui glissent d'un trimestre à deux glissent presque toujours parce que l'un de ces quatre rôles n'était pas tenu. Cela ne tient pas au logiciel.

Les quatre phases d'un projet WMS

Quatre-vingt-dix jours : trois semaines de données, quatre de paramétrage, quatre de tests, deux de démarrage. L'ordre n'est pas négociable.

Semaines 1 à 3 — données articles et emplacements

Commencez par nettoyer les données articles : références uniques, codes-barres corrects, dimensions et poids, unités de conditionnement, et l'indication du suivi par lot ou par date limite quand il s'applique. Une SKU présente deux fois reste invisible sur un bon de préparation papier pendant des années. Au premier scan, c'est un arrêt.

C'est la phrase à retenir de toute la phase : le logiciel révèle les erreurs de données que le papier vous permettait d'ignorer. Ce n'est pas un reproche, c'est la raison pour laquelle on prévoit trois semaines et non trois jours.

Ensuite la structure d'emplacements. Chaque emplacement reçoit un code selon un schéma unique — allée, travée, niveau, alvéole — et le même schéma partout. Ce code déterminera les trajets de vos préparateurs, donc votre productivité, puisque c'est lui qui ordonne la liste de prélèvement. Quel article va à quel emplacement est une autre question, celle de l'affectation des emplacements.

Semaines 3 à 7 — paramétrage et interfaces

On paramètre les processus : réception des marchandises, rangement, réapprovisionnement, stratégies de prélèvement, emballage, expédition et retours.

Une règle sauve plus de projets que toutes les autres : partez du flux standard et ajoutez les exceptions ensuite. Chaque entreprise a une poignée de cas particuliers et chacune les croit plus fréquents qu'ils ne le sont. Les paramétrer en semaine quatre revient à les paramétrer deux fois.

Les interfaces avancent en parallèle. BizBloqs est en production avec Sage 50, SAP Business One, Business Central, Exact Globe et Exact Online, AFAS, Uniconta, Newbase et Dynamics 365 F&O ; la liste complète est sur la page intégrations. Celles dont vous avez besoin dépendent de votre ERP, pas de la longueur de la liste.

Testez chaque liaison — ERP, boutique, places de marché, transporteurs tels que Colissimo, Chronopost ou Mondial Relay — sur quatre scénarios : commande nouvelle, modification, annulation, retour. Les deux premiers passent presque toujours. Les deux derniers sont ceux qui produiront des tickets après le démarrage.

Semaines 7 à 11 — tests et formation

Rejouez une journée de production complète dans l'environnement de test. Avec de vraies commandes de la semaine passée, et avec les personnes qui scanneront ensuite. Un test que le chef de projet déroule seul valide le logiciel, pas l'exploitation.

Formez par rôle et non par intitulé de poste : réception, prélèvement, emballage, retours, encadrement. Deux à quatre heures par rôle suffisent quand le rôle est délimité ; c'est insuffisant dès qu'une personne en cumule quatre.

Désignez un référent par équipe. C'est la raison pour laquelle, en semaine douze, tout ne remonte pas jusqu'à vous.

Semaines 11 à 13 — démarrage et suivi

Choisissez un jour calme en milieu de semaine, jamais juste avant une période de pointe.

Le démarrage lui-même est court : on gèle le stock, on compte les emplacements, on charge les résultats, on lance. Prévoyez les trois premiers jours en effectif renforcé, avec un interlocuteur joignable chez l'éditeur. Ensuite, passez aux comptages tournants plutôt que d'arrêter à nouveau l'activité.

Les cinq pièges

Des données sales. De loin la première cause de retard : codes-barres absents, références en double, unités de conditionnement inconnues.

Un démarrage juste avant la pointe. La courbe d'apprentissage et le pic de volume tombent ensemble, et les deux sont perdants.

L'exploitation tenue à l'écart. Si les personnes qui scannent découvrent le système le jour du démarrage, il sera contourné et non utilisé. C'est un problème d'association, pas de paramétrage.

Des exceptions traitées trop tôt. Standard d'abord, ajustement après deux semaines de production réelle. À ce moment-là, vous savez lesquelles existent vraiment.

Pas de chiffres de départ. Sans mesure avant le lancement, vous ne pourrez pas démontrer le résultat, ni à vous-même ni à votre associé.

Mesurer : quatre chiffres, deux dates

Relevez quatre chiffres en semaine un, puis les mêmes en semaine deux et en semaine quatre après le démarrage : lignes préparées par heure, erreurs par millier de lignes, taux de concordance entre un comptage d'échantillon et le système, délai entre la réception d'une commande et la remise au transporteur.

Quatre chiffres, trois relevés, dix minutes à chaque fois. C'est ce qui distingue un projet dont on sent qu'il a marché d'un projet dont on peut le montrer. Pour une estimation avant d'engager le budget, le calculateur ROI donne une indication, et non une économie garantie.

Questions fréquentes

Combien de temps dure un projet WMS ?

Une mise en place standardisée et configurée demande environ quatre-vingt-dix jours : trois semaines de préparation des données, quatre semaines de paramétrage et d'interfaces, quatre semaines de tests et de formation, deux semaines de démarrage et de suivi.

Qu'est-ce qui retarde le plus un projet WMS ?

Des données articles sales. Codes-barres manquants, références en double et unités de conditionnement inconnues : tout cela remonte au premier scan, pas avant.

Quel est le bon moment pour démarrer ?

Un jour calme en milieu de semaine, et largement avant une période de pointe, pour que l'exploitation absorbe la courbe d'apprentissage.

Que devons-nous fournir de notre côté ?

Une personne pour piloter le projet deux jours par semaine, un référent par équipe, quelqu'un qui connaît l'ERP pour les interfaces, et le responsable d'entrepôt disponible le jour du test.

À lire ensuite

• Système WMS — la question qui précède : en avez-vous besoin ?
• Système de gestion d'entrepôt — le périmètre fonctionnel
• Fonctionnalités — la liste complète
• Logiciel de gestion de stock — le détail sous le total
• Intégrations — les connexions disponibles

Deux questions sur votre propre projet

Combien de vos articles ont aujourd'hui un code-barres unique, une unité de conditionnement renseignée et un poids juste — comptés, et non estimés ?

Lequel des quatre rôles ci-dessus n'est pas encore attribué chez vous ?