La résilience de la supply chain nécessite de la bande passante

Joannes Vermorel

Les dernières années n’ont pas été tendres avec les supply chains. En fait, la seule chose qui n’a pas été en pénurie semble être les forces de perturbation : les confinements, les guerres, l’inflation, etc. Par conséquent, un nouvel intérêt pour les supply chains ‘résilientes’ a émergé. Naturellement, les suspects habituels - les consultants, les professeurs et les vendeurs de logiciels (y compris votre humble serviteur) - ont été occupés à trouver des ‘solutions’ qui permettraient, au moins, de réduire l’ampleur de l’impact de ces perturbations, et qui permettraient, au mieux, d’éliminer certaines classes de perturbations. Cependant, mes observations occasionnelles indiquent que ces ‘solutions’, quelle que soit leur valeur perçue, ne sont généralement rien de plus que des vœux pieux.

En effet, au cours de la dernière décennie, j’ai observé que la plupart des directeurs de supply chain, ainsi que leurs équipes, sont déjà submergés par des micro-crise, même pendant des périodes principalement dépourvues de toute perturbation à grande échelle. Ainsi, la plupart des divisions de supply chain n’ont pas le luxe de penser même à la gestion de crise (ou à tout autre type de plan stratégique d’envergure) : elles sont entièrement engagées dans l’extinction d’un flux incessant d’incendies.

Il y a quelques décennies, l’industrie du logiciel a inventé un terme pour désigner ce problème : le manque de bande passante, lorsque la direction ne peut même pas se permettre de penser à un autre problème car son attention est déjà trop dispersée sur trop de problèmes. Ce qui rend le concept de bande passante si pertinent pour le logiciel et la supply chain, c’est que, dans les deux situations, la réponse habituelle de l’entreprise à une charge de travail excessive - c’est-à-dire ajouter plus de personnel sur le cas - ne fonctionne pas. C’est là l’essence de la loi de Brooks : ajouter des effectifs supplémentaires à un projet logiciel déjà en retard ne fait que retarder encore plus le projet. Dans l’industrie du logiciel, qui compte parmi les entreprises les plus rentables ayant jamais opéré sur les marchés libres, ce problème de bande passante est particulièrement vexant. Même si l’entreprise était suffisamment rentable pour doubler les effectifs et la direction, cela ne résoudrait pas le problème [^problème].

Peut-être de manière surprenante (ou peut-être pas), la cause première de ce flux incessant de micro-crise dans la supply chain est presque exclusivement le logiciel. Contre-intuitivement, ce ne sont pas la guerre en Ukraine ou la possibilité d’une autre guerre en Asie qui épuisent la bande passante de la division de la supply chain, mais généralement des problèmes qui pourraient être qualifiés de “totalement anecdotiques”, tels que le WMS qui n’est pas synchronisé avec l’ERP (…encore une fois) ; ou des manœuvres politiques avec l’informatique pour obtenir un champ personnalisé supplémentaire dans la base de données pour les stocks “réservés” ¹ ; ou la poursuite de prévisions totalement déraisonnables fournies par le processus S&OP.

Dans une galerie des logiciels qui épuisent la bande passante, les produits analytiques sont de loin les pires coupables. Ces outils - en particulier les outils de planification - nécessitent souvent non seulement une main-d’œuvre importante pour les faire fonctionner, mais ils génèrent également leurs propres mini-bureaucraties. En conséquence, la gestion de la supply chain résout les problèmes liés aux logiciels, en plus de résoudre les problèmes liés aux processus générés par la bureaucratie elle-même. Ce processus devient frustrant et gaspille de plus en plus de bande passante.

Lokad, faisant partie de cet écosystème de logiciels analytiques, n’est pas à l’abri de ce problème. Il y a plusieurs années, nous avons cependant développé l’antidote grâce au quatrième point de notre manifeste ² : Être en contrôle nécessite l’automatisation de chaque tâche banale. Nous avons réalisé qu’il y avait un équilibre délicat à trouver entre la gestion et l’optimisation. Par exemple, si la génération des commandes d’achat/production quotidiennes consomme tout le budget de bande passante de la division de la supply chain, il ne reste rien dans les caisses pour l’amélioration (en termes de résilience ou autre).

Au contraire, si toutes les tâches banales sont entièrement automatisées, cela libère une quantité massive de bande passante de l’organisation de la supply chain. Ce processus, cependant, prend du temps. Ce n’est pas un hasard si lorsque Lokad commence à travailler pour un client, il nous faut généralement environ un an avant de pouvoir nous concentrer directement sur un sujet considéré comme stratégique (comme la résilience). Lokad doit non seulement arriver en production (ce qui prend environ 6 mois), mais l’organisation doit également apprendre à abandonner le contrôle de tous les processus qui ont maintenant été automatisés (ce qui nécessite encore 6 mois, voire plus dans les grandes organisations).

En automatisant les décisions banales, cependant, les équipes de la supply chain retrouvent quelque chose qu’elles ont généralement perdu il y a des décennies lorsque leur organisation est devenue numérique : la capacité de choisir leurs batailles. C’est probablement le bénéfice le plus important de l’automatisation, qui dépasse largement les économies de productivité. Je ne dis pas que la transition vers une supply chain numérique dans les années 1980 et 1990, exploitée à travers une collection de ERP, MRP et APS, n’était pas la bonne décision. En bref, bien que cette voie numérique était nécessaire, elle avait des inconvénients majeurs : les entreprises (du marché libre) n’ont jamais été aussi ancrées dans leur paysage applicatif, où les migrations et les mises à niveau sont généralement mesurées en années. De nombreuses supply chains sont englouties dans leur “lutte contre les incendies numériques” depuis si longtemps que peu d’employés se souviennent d’avoir commencé la journée de travail sans un flux incessant d’alertes, d’exceptions et de problèmes. Sans parler du flux interminable de réunions pour traiter ces alertes, exceptions et problèmes. Tous ces processus ont des coûts en termes de bande passante, et le compte mental est toujours en cours.

À titre d’anecdote, considérons que en moins de 5 ans (1903 à 1908), Henry Ford est passé de rien à la Model T. Ford a révolutionné la production industrielle, en introduisant plus d’une douzaine de modèles dans le processus (Model A, Model B, Model C, etc.), tout en jonglant avec une offre et une demande en constante évolution. Ford n’a pas eu la tâche facile non plus : la Panique de 1907 a été l’une des plus grandes et des plus graves crises financières de tous les temps. De nos jours, avec 5 ans de “business as usual”, beaucoup (la plupart ?) d’entreprises ne peuvent même pas finaliser la mise à niveau de leur ERP.

Ainsi, pour devenir résiliente, une supply chain doit libérer de la bande passante. La résilience est un sujet difficile et insaisissable, donc beaucoup de bande passante est nécessaire, ce qui rend la tâche d’autant plus difficile. Pire encore, la pénurie de bande passante disponible dans la supply chain, comme l’a découvert l’industrie du logiciel il y a des décennies, ne peut pas simplement être résolue en jetant des sommes d’argent considérables ³. En revanche, le meilleur chemin vers la résilience est indirect : automatiser impitoyablement les décisions banales pour gagner la liberté de réfléchir et d’exécuter les décisions stratégiques, y compris la résilience.