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 manqué semble être les forces de perturbation : confinements, guerres, inflation, etc. En conséquence, un nouvel intérêt pour des supply chains « résilientes » a émergé. Naturellement, les suspects habituels – consultants, professeurs, et software vendors (y compris moi-même) – se sont affairés à élaborer des « solutions » qui, au minimum, atténueraient l’impact de ces perturbations, et qui, au mieux, élimineraient certaines catégories de perturbations. Cependant, mes observations informelles indiquent que ces « solutions », quel que soit leur mérite perçu, ne sont généralement que de vaines espérances.

Effectivement, au cours de la dernière décennie, j’ai observé que la plupart des directeurs de supply chain, et leurs équipes, sont déjà submergés par des micro-crises, même durant des périodes essentiellement dépourvues de tout type de perturbations à grande échelle. Ainsi, la plupart des divisions de supply chain n’ont pas le luxe de penser à la gestion de crise (ou à quelque type de grand plan stratégique) : elles sont entièrement mobilisées pour éteindre un flot incessant d’incendies.

Il y a quelques décennies, l’industrie du logiciel a inventé un terme pour désigner ce problème précis : manque de bande passante, quand la direction ne peut même pas se permettre de penser à un problème de plus parce que son attention est déjà trop diluée entre trop d’enjeux. Ce qui rend le concept de bande passante si pertinent tant pour le logiciel que pour la supply chain, c’est que, dans les deux situations, la réponse habituelle de l’entreprise face à une surcharge de travail – c’est-à-dire affecter plus de personnes au dossier – ne fonctionne pas. C’est l’essence même de la loi de Brooks : ajouter du personnel supplémentaire à un projet logiciel déjà en retard ne fait que le retarder davantage. Dans l’industrie du logiciel, qui compte parmi les entreprises les plus rentables ayant jamais opéré sur des marchés libres, ce problème de bande passante est particulièrement épineux. Alors que l’entreprise pourrait être suffisamment rentable pour doubler ses effectifs et sa direction, cela ne ferait qu’effleurer le problème ¹.

Peut-être de manière surprenante (ou peut-être pas), la cause fondamentale de ce flot incessant de micro-crises dans la supply chain est presque exclusivement liée aux logiciels. De façon contre-intuitive, ce n’est pas la guerre en Ukraine ni la possibilité d’en avoir une autre en Asie qui épuise la bande passante de la division de la supply chain, mais typiquement des problèmes que l’on qualifierait volontiers d’« entièrement anecdotiques », tels que le WMS qui n’est pas synchronisé avec l’ERP (…encore une fois) ; ou des manœuvres avec le service 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 telles que fournies par le processus de S&OP.

Dans une galerie de logiciels voraces en bande passante, les produits analytiques sont de loin les plus grands coupables. Ces outils – et particulièrement ceux de planification – nécessitent fréquemment non seulement une main-d’œuvre considérable pour être exploités, mais ils engendrent également leurs propres mini-bureaucraties. En conséquence, la gestion de la supply chain doit résoudre non seulement les problèmes liés aux logiciels, mais aussi ceux liés aux processus générés par la bureaucratie elle-même. Ce processus devient frustrant par sa réflexivité et gaspille toujours 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 quelques années, nous avons néanmoins mis au point l’antidote grâce au quatrième point de notre manifeste ³ : Maîtriser la situation requiert l’automatisation de chaque tâche banale. Nous avons compris qu’il fallait trouver un équilibre délicat entre gestion et optimisation. Par exemple, si la génération des commandes d’achat/production quotidiennes absorbe l’intégralité du budget de bande passante de la division de la supply chain, il ne reste rien dans les caisses pour l’amélioration (que ce soit en termes de résilience ou d’autre chose).

Au contraire, si toutes les tâches banales sont entièrement automatisées, cela libère une quantité massive de bande passante au sein de l’organisation de la supply chain. Ce processus, cependant, prend du temps. Il n’est pas étonnant que lorsqu’une collaboration avec Lokad démarre, il nous faille généralement environ un an avant de pouvoir nous concentrer directement sur un sujet que l’on considérerait comme stratégique (tel que la résilience). Lokad doit non seulement atteindre la phase de production (ce qui prend environ 6 mois), mais l’organisation doit également apprendre à renoncer au contrôle de tous les processus désormais automatisés (ce qui nécessite encore 6 mois, voire plus dans les grandes organisations).

En automatisant les décisions banales, les équipes de la supply chain retrouvent ce qu’elles avaient généralement perdu il y a des décennies lorsque leur organisation s’est digitalisée : la capacité à choisir leurs batailles. Il s’agit probablement de l’avantage le plus important de l’automatisation, éclipsant les gains de productivité. Je ne dis pas que la transition vers une supply chain digitale dans les années 1980 et 1990, opérée via un ensemble d’ERPs, de MRPs et d’APSs, n’était pas la bonne décision. Tout simplement, bien que cette trajectoire digitale fût nécessaire, elle s’est accompagnée d’inconvénients majeurs : les entreprises (sur un marché libre) ne se sont jamais retrouvées aussi enfermées dans leur propre paysage applicatif, où les migrations et les mises à jour se mesurent généralement en années. De nombreuses supply chains ont été englouties par leur « lutte contre les incendies digitaux » pendant si longtemps que peu d’employés se souviennent avoir commencé leur journée sans un flot incessant d’alertes, d’exceptions et de problèmes. Sans parler du flot interminable de réunions pour traiter ces alertes, exceptions et problèmes. Tous ces processus engendrent des coûts en termes de bande passante, et la facture mentale ne cesse de s’accumuler.

À titre d’anecdote, considérons que, en moins de 5 ans (de 1903 à 1908), Henry Ford est passé de rien au Model T. Ford a révolutionné la production industrielle, en introduisant plus d’une dizaine de modèles dans le processus (Model A, Model B, Model C, etc.), tout en jonglant avec une offre et une demande en perpétuelle évolution. Ford n’a pas eu la vie facile non plus : la Panique de 1907 fut l’une des crises financières les plus importantes et les plus sévères de tous les temps. Aujourd’hui, après 5 ans de « business as usual », de nombreuses (voire la plupart) entreprises n’arrivent 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, nécessitant beaucoup de bande passante, ce qui le rend d’autant plus complexe. Pire encore, la rareté de la 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 dépensant des sommes d’argent considérables ⁴. Au contraire, la meilleure voie vers la résilience est une voie indirecte : automatiser impitoyablement les décisions banales afin de gagner la liberté de penser et d’exécuter les décisions stratégiques, résilience comprise.