Pareto VS Benford - 3ème volet de "la guerre des indicateurs"

Ce message est disponible sur le nouveau blog à partir de ce lien

Je m'étais décidé à revenir sur les fondamentaux du LSS mais je reste définitivement passionné par cette lutte acharnée que se livrent les "Indicateurs célèbres" et les "Indicateurs de l'ombre". D'un côté nous avons les pantouflards et illusionnistes de Moyenne, Min et Max et de l'autre nous avons les besogneux et robustes Médiane, Quartiles, Ecart Type. A ce jour il paraît bien difficile de les départager... Alors, sur le ring, deux lois de distributions viennent faire le show...! ;-)

A ma droite, taillé comme un boeuf, du haut de ses 20-80 nous avons : M. Pareto...
A ma gauche, allongé comme une logarithme, à la précision aléatoire : M. Benford...

DDDDDDDRRRRRRRRrrrrrrrrrrriiiiiiiinnnnnnnnnnngggggggggg !!!

Bon...là je pense que vous êtes assez conditionnés pour rentrer dans le vif du sujet. Il a quelques années, je fus amené à mettre en place un calcul de coût de revient logistique des produits stockés sur une plateforme. J'avais donc des masses de charges à répartir sur chaque article en fonction de clés de répartition (appelées également unités d'oeuvre). Vous en conviendrez, pour les aspects logistiques comme le stockage ou les expéditions il était opportun de prendre en considération le volume des colis. Aussi la plupart de nos calcul réaffectaient les charges en fonction du volume (volume stocké, volume réceptionné, volume expédié...etc). Donc j'ai fait une jolie matrice sous excel, avec des belles macro pour mettre à jour le zinzin et après quelques jours de travail j'avais devant mes yeux les coûts de revient par produit... Oh miracle...!

Puis vint le temps de l'analyse... Et là : problème ! Je me suis retrouvé avec des articles qui génèraient des coûts faramineux... En cherchant un peu, je finis pas me rendre compte que les mesures de certains produits étaient incohérentes... :-(
J'en appela au responsable logistique et lui demanda de vérifier les produits que j'avais identifiés... Il revint avec les bonnes mesures... Alors je refis mouliner le zinzin et pareil... des articles remontaient à la surface avec des erreurs...!
Le problème c'est qu'il était impossible de demander de remesurer l'ensemble des 6000 produits stockés sur la plateforme ! J'avais donc un joli dilemme devant moi : comment faire pour être certain de la fiabilité de mes données sans avoir à mesurer l'ensemble de mes produits et à refaire des itérations à n'en plus finir sur la prise nouvelle de mesures...!?

Mon premier réflexe fut de me tourner vers la loi de Pareto. Comme chacun sait Pareto a mis en avant une loi de distribution qui est "archi-utilisée" dans les entreprises. Cette loi dit par exemple que 80% de mon CA est généré par 20% de mes clients. Je décide donc de sortir les 20% de mes articles qui génèrent 80% de mes volumes. Par ailleurs je sors les 80% de mes produits en stocks qui représentent 20% de ma valeur de stock global. Ainsi, si je croise mes deux fichiers je me retrouve avec les articles qui ont les plus forts volumes avec les valeurs les plus faibles ce qui me permet de cerner les aberrations ! Au seul détail près que je partais du principe (un peu discutable ;-) que mes articles les plus volumineux étaient forcément les plus coûteux. Et effectivement je pu cerner de nouvelles aberrations...

Alors : Je relança le zinzin... et toujours pareil... Il restait des articles avec des erreurs... Mais j'avais un problème supplémentaire : les erreurs avaient une moins grande ampleur car j'avais corrigé les 20% de mes article qui généraient 80% de mes volumes erronés (sacré Pareto va ! ;-P).

Après quelques jours la lumière s'éclaira. Si la loi de distribution de Pareto trouvait sa limite dans mon problème : alors j'allais utiliser une autre loi de distribution, celle-ci bien moins connue, mais bien plus efficace pour le problème que j'avais à résoudre : la loi de Benford.

Pour ceux qui ne le savent pas : la loi de Benford fait état d'un constat du phénomène aléatoire que nous réserve la nature. Dans une distribution numérique quelconque (le liste des prix d'une grande surface, le liste des dimension de l'ensemble des arbres du territoire, la liste salaires net des habitants d'un pays...etc) si nous prenons le premier chiffre (différent de 0) et que nous comptabilisons ces chiffres : alors nous auront systématiquement cette distribution :


Étrange non...!? Quoi que vous preniez comme distribution, si vous comptabilisez le nombre de 1 en première position, de 2 en première position...etc, vous obtiendrez toujours ce %. Plus étrange encore c'est qu'il y ait plus de 1 que de 2, de 2 que de 3...etc. Mais c'est comme ça... Si tant est que la distribution soit aléatoire celle-ci ressemblerait à cela.

Je décida donc de comparer ma distribution avec celle de Benford et voici ce que j'obtins :
Le résultat était flagrant ! J'avais beaucoup trop de 5 et pas assez de trois. Je fis donc une extraction de tous mes articles avec un 5 dans le premier caractère de mon volume et je passa en revu la liste. Je visualisa rapidement que tous les articles d'une famille (celles des chaussures) avaient la même taille. L'ingratitude de la tâche avait amené les personnes en charge des mesures de faire des copier-coller. Ils se justifièrent par le fait que toutes les boîtes à chaussures faisaient la même taille. Dans une certaine proportion peut-être mais on ne peut pas prendre la loi de Benford, en défaut, de la sorte...! Les boîtes à chaussures ne font pas la même taille lorsqu'il s'agit de chaussures de ville, de bottes de pêche ou de chaussons pour enfants...etc.

Après la mesure de chacune des références de la famille chaussure présentes dans l'entrepôt, je refis une analyse de ma nouvelle distribution et voici ce que cela donna :
Cette fois mon fichier paraissait fiable... Je remoulina le zinzin et obtins avec succès le calcul de mes coûts de revient tant espérés... ;-)

Pour les projets LSS j'aurai le loisir, dans un post à venir, de vous parler de l'outil qui test la fiabilité des données à l'enregistrement de celles-ci (le GR&R) mais bien souvent un projet démarre avec des données dores et déjà enregistrées et dans un tel cas il est nécessaire de vérifier la cohérence de ces données avant d'en fournir une quelconque analyse...!

Bravo à vous M. Benford... Vous avez gagné ce combat haut la main ! ;-P