Lors de chaque initiative de Supply Chain Quantiative gérée par Lokad, 80 % des efforts portent sur la « préparation des données », parfois également appelée « nettoyage des données » ou « prétraitement des données ». L’utilité de cette étape est souvent mal comprise, même par des professionnels expérimentés en logistique. Pourtant, nous avons pu observer que les problèmes de données sont la cause principale des échecs en matière d’optimisation logistique, dans presque tous les secteurs d’activité, des aliments frais à l’aéronautique. En matière de logistique, si certains échecs sont assez spectaculaires pour faire les gros titres, la plupart sont passés sous silence. La connaissance de tels échecs est pourtant primordiale, pour ne pas les répéter.
Échecs dûs aux données
Bien souvent, les projets d’optimisation logistique se soldent par un échec. En effet, d’après les observations empiriques des clients de Lokad, le taux échec des initiatives d’optimisation logistique qui reposent sur la mise en œuvre d’un logiciel approche les 80 %. Tous les secteurs d’activité sont touchés. Malheureusement, peu d’éditeurs de logiciel sont prêts à admettre que les projets de leurs clients se soldent très souvent par un échec.
L’un des paradoxes de la logistique moderne est qu’il est moins risqué de déplacer du stock d’un continent à l’autre que des données sur le stock entre deux ordinateurs distants d’un mètre.
Lorsqu’un projet se passe mal, le client et l’éditeur n’ont aucun intérêt à révéler cette information. Ainsi, la grande majorité des échecs sont discrètement oubliés et le sujet n’est plus jamais abordé. De temps en temps, les revers sont tellement spectaculaires que les journaux en parlent :
Même si l’explication de ces échecs n’est pas unique, à chaque fois, un gros problème avec les données entraîne de très mauvaises décisions au niveau logistique.
Cependant, les échecs ne sont généralement pas aussi retentissants. Même avec un nouveau système censé être plus performant que les précédents, les professionnels de la logistique ont tendance à rester méfiants vis-à-vis des chiffres générés et à continuer à utiliser leurs tableaux Excel. Le système est généralement abandonné après quelques mois. Les conséquences sur l’entreprise ne sont pas très importantes, mais du temps et de l’énergie ont été gaspillés.
La difficulté de l’interprétation des données
Les données historiques d’une entreprise sont très ambiguës et subtiles. Ces aspects sont relativement contre-intuitifs et sont donc souvent mal compris. D’après notre expérience, c’est cette incompréhension qui est à l’origine des difficultés rencontrées avec les données lors des initiatives logistiques.
Prenons l’exemple simple d’un historique de ventes : une table liste les quantités vendues par produit et par jour au cours des années précédentes. Cet historique des ventes devrait donner une idée de la direction que prend l’entreprise, mais ce n’est pas le cas :
- L’historique peut contenir des lots de produits et les quantités ne sont alors pas représentatives du niveau d’activité de l’entreprise.
- L’historique peut contenir les retours, qui représentent potentiellement une grande partie des ventes. L’activité peut sembler être en hausse alors qu’elle décline si les retours augmentent.
- L’historique peut contenir les promotions au cours desquelles les marges sont réduites pour liquider le stock. La demande observée alors n’est pas représentative de la demande en temps normal.
De plus, les « quantités par jour » associées à des dates données, ces dernières recèlent en elles-mêmes certaines ambiguïtés. Il peut s’agir du jour :
- de la commande du client ;
- de la confirmation de la précommande du client ;
- de l’envoi du produit ;
- de l’enregistrement de la commande dans l’ERP ;
- de la dernière modification de la commande dans l’ERP ;
- de la réception du paiement du client ;
- etc.
Chaque variante est correcte, mais présente ses propres subtilités. Ces données sont trop souvent considérées comme un simple historique des ventes passées alors que rien n’est jamais simple dans ce domaine.
De plus, dès lors que ces subtilités sont combinées, leurs conséquences augmentent de façon exponentielle. Rien n’est plus générateur de surstock qu’un biais positif qui gonfle les ventes combiné à un biais négatif qui minimise les stocks futurs.
Nous avons remarqué que, d’une manière générale, au moins une page de description pour chaque colonne de chaque table est nécessaire pour bien documenter les données. Pourtant, nous mesurons notre chance lorsque nous disposons d’une ligne d’explication par colonne (c’est-à-dire par champ de données) au début d’un projet.
Même lorsque de la documentation existe, elle passe souvent à côté de l’essentiel. Il est évident qu’une colonne intitulée DateCommande contient des dates ou qu'une colonne intitulée CodeStatut contient une liste de codes. Lorsque la documentation est plus technique, les aspects informatiques des données sont détaillés, mais les enjeux métier totalement mis de côté. Ces derniers sont pourtant essentiels en matière d’optimisation.
Dans le domaine de l’informatique, les anglophones disent : « garbage in, garbage out », si vous entrez de mauvaises données, vous obtiendrez de mauvais résultats. Par conséquent, chez Lokad, nous tenons à décomposer les données et à documenter tous les résultats dès que nous sommes chargés d’une initiative logistique. La plupart de nos clients sont surpris du volume de documentation que nous produisons en passant en revue leur système, leurs données et leurs processus. Mais nous n’avons jamais regretté ces efforts de documentation.
Toutes les installations sont différentes
La question que l’on nous pose le plus souvent lors d'initiatives de Supply Chain Quantiative est : « Est-ce que cette optimisation est compatible avec le système XYZ ? » La réponse est la plupart du temps « oui », « oui, mais cela nécessite quelques efforts ». Grâce au protocole FTP, même avec une connexion Internet modeste, d’importants volumes de données peuvent être déplacés. La véritable difficulté réside dans la compréhension détaillée des données traitées. Les systèmes informatiques sont très flexibles, même si les entreprises n’en sont pas toujours conscientes. Ils peuvent paraître rigides à leurs utilisateurs, mais le sont rarement en réalité.
En effet, la flexibilité est au centre de la concurrence entre les éditeurs de logiciels depuis des années et les systèmes qui enferment les tâches dans un déroulement unique sont rares. La plupart des systèmes offrent des moyens innombrables d’obtenir un résultat identique. Par conséquent, même si les données sont issues d’un même logiciel, leur préparation reste différente. En réalité, la préparation des données dépend beaucoup des pratiques de l’entreprise et du déroulement des activités en son sein. Ainsi, des enregistrements de données identiques seront interprétés différemment d’une entreprise à l’autre. Au premier abord, ces différences peuvent sembler mineures, mais elles entraînent souvent d’importantes incohérences entre la logique d’optimisation et les besoins métiers réels.
Toute stratégie nécessite des données
« Bonne nouvelle : les ordinateurs font ce qu’on leur dit.
Mauvaise nouvelle : les ordinateurs font ce qu’on leur dit. » Ted Nelson
La plupart des dirigeants comptent sur leur équipe pour mettre en œuvre la stratégie de l’entreprise même si cette dernière n’est pas formalisée ni consignée par écrit. Pourtant, l’optimisation quantitative ne tolère aucun objectif implicite : les chiffres qui résultent des données d’entrée reflètent précisément le cadre numérique qui a été mis en place. Par conséquent, les résultats initiaux fournis par les solutions d’optimisation quantitative sont potentiellement déconcertants : parfaitement corrects à plusieurs égards, mais passant à côté de l’essentiel à de nombreux autres.
Les objectifs de l’entreprise n’étant que rarement spécifiés dès le début d’un projet, c’est souvent les premiers résultats fournis par la logique d’optimisation quantitative qui pointent les manques. Ces derniers peuvent être de plusieurs natures :
- les clients importants qui requièrent un niveau de service plus élevé ;
- les produits au bord de l’obsolescence qui représentent un risque pour le stock ;
- les fournisseurs avec quantités de commande minimales par SKU et par commande ;
- les entrepôts presque pleins pour lesquels les réapprovisionnements doivent être limités ;
- etc.
La résolution de toutes ces difficultés nécessite des données supplémentaires et les entreprises prennent généralement conscience que les données concernées ne sont pas disponibles ou alors disséminées dans les nombreuses feuilles de calcul Excel des différentes équipes. L’importance de ces fichiers est souvent sous-estimée et ces derniers sont, la plupart du temps, simplement archivés dans les boîtes mail.
Ainsi, la préparation doit porter sur les données transactionnelles comme celles extraites d’un ERP, mais également sur les données qui déterminent la stratégie de l’entreprise. La tâche est d’autant plus ardue que ces données de haut niveau sont plus difficiles à préparer. En effet, à la différence des données transactionnelles, elles n’ont généralement jamais été mises en cohérence sur l’ensemble de l’entreprise. Par conséquent, lors de la préparation de ces données, il n’est pas rare de constater que la stratégie de l’entreprise ne peut pas être appliquée à certains cas limites.
Pour mettre en adéquation la logique d’optimisation avec les objectifs de l’entreprise, l’approche la plus directe consiste à tout exprimer en euros ou en dollars (ou toute autre monnaie). Le point de vue financier n’est pas intrinsèquement meilleur que les autres, mais il permet aux différents services d’une entreprise d’utiliser une unité cohérente et nécessite peu de coordination. Dans la pratique, ce point de vue financier peut créer des tensions si l’entreprise n’utilise habituellement que des indicateurs non financiers ou, pire encore, aucun indicateur.
Il n’y a jamais assez de documentation
Une bonne préparation des données passe par une bonne documentation. Cet ingrédient est simple et pourtant souvent négligé ou considéré comme une tâche qui n’est ni urgente ni importante. Néanmoins, notre expérience nous a montré qu’une bonne documentation des données est à la fois urgente et importante.
La documentation doit expliquer la raison d’être de chaque source de données et même de chaque champ. Il est capital d’expliquer à quoi servent les données pour que celles-ci soient traitées correctement par la suite. Malgré tout, lorsqu’une documentation existe, elle ne fait que paraphraser le nom des champs.
« Exemple de mauvaise documentation »
COMMANDES.DATE : date associée à la commande.
« Exemple d’une meilleure documentation »
COMMANDES.DATE : date à laquelle le client a fait part de son intention d’acheter le produit, représente le cœur de la demande. Cette date peut être comparée à
COMMANDES.DATELIVRAISON pour déterminer le temps passé entre la commande initiale et la livraison du point de vue du client.
La documentation des données d’entrée ne doit pas être considérée comme un élément informatique, mais plutôt comme une ressource métier. Même si l’équipe informatique est très motivée et serviable, elle ne dispose pas des informations métier nécessaires à la compréhension en profondeur des données.
Par conséquent, dès que Lokad démarre un projet avec un nouveau client, nous passons du temps très en amont à rédiger la documentation, petit à petit, après chaque conversation avec notre client (qui nous fournit des informations sur son expertise métier). La valeur ajoutée de ce processus n’est pas toujours évidente de prime abord, car d’autres sujets peuvent sembler plus pressants. Cependant, les semaines passant, de petits détails sur les données sont oubliés et la documentation écrite reste la seule façon d’éviter de rencontrer le même problème à plusieurs reprises.
