De 2011 à 2018, Lidl a travaillé à remplacer son système de gestion des marchandises par un logiciel bâti sur SAP. En juillet 2018, l’enseigne a arrêté le projet, après environ 500 M€ dépensés selon les estimations publiées. Le mécanisme rapporté par la presse peut se retrouver, à plus petite échelle, dans le projet d’une PME.
Auteur
Tudor HilcuFondateur & CEO, THG Conseil
Publié le
Lecture
6 min
Thèmes
Projets, ERP
Sommaire8
En juillet 2018, Lidl arrête eLWIS, le projet qui devait remplacer son système de gestion des marchandises par un logiciel bâti sur SAP for Retail. Le projet avait été lancé en 2011. La décision est d’abord annoncée aux salariés, puis confirmée à la presse par Lidl et par SAP. Selon les estimations publiées par la presse allemande, environ 500 M€ y avaient été engagés ; ni Lidl ni SAP n’ont confirmé ce montant.
Lidl présentait ce chantier comme le plus grand projet de transformation de son histoire. Selon Handelsblatt, plus de 1 000 salariés de Lidl et de SAP y travaillaient, avec plus d’une centaine de consultants. Le nouveau système tournait déjà dans trois pays : en Autriche depuis mai 2015, en Irlande du Nord et aux États-Unis.
C’est le cas concret n°01 de la série que je publie sur LinkedIn ; voici la version complète, avec ses sources. Il s’agit d’un géant de la distribution, mais le mécanisme peut se retrouver, à son échelle, dans une PME qui change de logiciel de gestion, d’ERP ou d’outil de facturation.
L’écart de départ : une question de méthode
Lidl et le logiciel standard SAP for Retail ne valorisaient pas les stocks de la même façon, et Lidl tenait à sa méthode, qui le distingue de beaucoup de ses concurrents. Handelsblatt et heise online décrivent le même point de départ : deux façons de compter la marchandise, qui ne se rejoignent pas.
Deux voies s’ouvraient alors : changer la méthode de Lidl, ou adapter le logiciel. Selon la presse, Lidl n’a pas voulu changer de méthode. Un initié cité par Handelsblatt explique qu’il aurait fallu revoir tous les processus, et que la direction n’y était pas prête. Le logiciel a donc été remanié pour suivre les pratiques de l’enseigne, à grands frais.
Ces adaptations ont mobilisé beaucoup d’heures de consultants. Handelsblatt rappelle le mécanisme général : des modifications qui s’additionnent rendent un logiciel plus complexe, plus fragile et plus coûteux. Sur les responsabilités, la presse a rapporté des reproches croisés, sans rien de tranché.
L’arrêt, et le retour à l’ancien système
Dans leur lettre aux salariés, citée par la presse, les dirigeants de Lidl écrivent que les objectifs stratégiques de départ ne sont plus atteignables à un coût raisonnable. L’analyse des coûts et des avantages plaide pour faire évoluer l’ancien système maison, appelé Wawi. Lidl présente cette décision comme un choix pour son propre système, pas contre SAP : la coopération continue dans d’autres domaines.
Ce que l’on retient du dossier tient en une question, présente dès le départ : fallait-il changer la méthode, ou adapter l’outil ?
La même question, à l’échelle d’une PME
Une PME ne dépense pas 500 M€ dans un logiciel. Elle rencontre pourtant la même question dès qu’elle change d’outil : quand le logiciel standard ne fait pas comme nous, change-t-on notre façon de travailler, ou fait-on adapter le logiciel ?
Il n’y a pas de réponse valable partout. Une méthode qui fait votre différence auprès des clients peut justifier une adaptation. Une simple habitude, beaucoup moins. Le vrai risque est ailleurs : laisser la question sans réponse, et accepter les adaptations une par une, sans que personne ne regarde le total.
Cinq décisions à prendre, avant et pendant le projet
Faites la liste des écarts avant de signer. Demandez une démonstration sur vos propres cas : une commande type, un retour, une facture, une fin de mois. Notez chaque endroit où l’outil standard ne fait pas comme vous.
Pour chaque écart, tranchez par écrit : changer la méthode ou adapter l’outil. Avec le nom de la personne qui décide et une date limite. Un écart sans décision finit en adaptation par défaut.
Chiffrez chaque adaptation sur toute sa durée de vie. Le développement, mais aussi les tests, la maintenance et les mises à jour de l’éditeur, qu’il faudra refaire passer à chaque version. Demandez ce chiffre à votre éditeur ou à votre intégrateur avant d’accepter.
Tenez un compteur visible. Le nombre d’adaptations et leur coût cumulé, revus à chaque comité de pilotage. L’empilement se voit pendant qu’on peut encore l’arrêter.
Fixez à l’avance les points où l’on peut tout arrêter. Des dates et des critères écrits : coût, délai, périmètre. À chacun de ces points, posez franchement la question : continuer, réduire ou arrêter. L’argent déjà dépensé n’est pas une raison de continuer.
Exemple fictif : le registre des écarts d’une PME de négoce qui change de logiciel de gestion
Remises par client calculées à la main. Décision : changer la méthode et prendre la grille de remises de l’outil. Qui tranche : le directeur commercial, avant le 15 novembre.
Bon de livraison avec des mentions propres au métier. Décision : adapter l’outil avec un nouveau modèle de document. Qui tranche : le dirigeant, avant le 30 novembre.
Inventaire tournant chaque semaine. Décision : à trancher. Qui tranche : le comité de pilotage, avant le 6 décembre.
Trois écarts, trois noms, trois dates. Le troisième n’est pas encore tranché, et le registre le montre : la décision a une échéance, elle ne peut plus traîner sans que tout le monde le voie.
Ce que j’en ai appris
J’ai retrouvé ce mécanisme sur mes missions, à plus petite échelle. Pour The Walt Disney Company, j’ai coordonné 21 équipes et 5 partenaires sur un programme ERP Oracle et WMS Blue Yonder, et tenu son budget en lien direct avec le contrôle de gestion. Ce lien régulier entre le programme et la finance évite que les écarts se découvrent à la clôture : une adaptation de plus se voit le mois où elle est décidée.
Mes sociétés m’ont appris l’autre versant : ce que coûte une décision quand c’est mon nom en bas du contrat. Une décision de méthode qui attend coûte aussi, même quand personne ne la voit passer.
Les limites de ce cas
Les faits viennent de la presse allemande et des propos de Lidl qu’elle rapporte. Le montant d’environ 500 M€ est une estimation publiée, que ni Lidl ni SAP n’ont confirmée. Les raisons du choix d’adapter le logiciel sont rapportées par des initiés, pas par Lidl. Aucune source ne permet d’attribuer l’échec à SAP, à un intégrateur ou à Lidl seul : je m’en tiens au mécanisme. La situation du système de Lidl aujourd’hui n’a pas été vérifiée pour cet article.
Par où commencer cette semaine
Listez les adaptations déjà demandées, ou prévues, sur l’outil de votre projet en cours.
Pour chacune, notez qui l’a décidée et à quelle date. Celles qui n’ont ni nom ni date sont vos décisions qui traînent.
Inscrivez les deux plus coûteuses au prochain comité, avec une seule question : changer la méthode ou adapter l’outil ?
Dix minutes de travail, et vous savez quelles décisions attendent encore.
Un projet dérape le plus souvent pour une raison simple : une décision de méthode qui traîne.
Le cas suivant de la série, Revlon et SAP, montre l’autre risque : cette fois, la bascule a lieu. Pour suivre chaque semaine le planning, le budget, les risques et les décisions d’un projet, le modèle de reporting PMO est gratuit. Si un projet de logiciel vous échappe, Piloter vos projets décrit comment j’interviens, et le diagnostic express prend deux minutes, et rien n’est envoyé : vous choisissez ensuite de m’appeler ou de m’écrire.
