00:00:13 Les défis de la mise en œuvre de proofs of concept dans la supply chain.
00:01:00 Quand les proofs of concept fonctionnent bien et en quoi la supply chain diffère.
00:02:29 La supply chain comme un problème ouvert et les difficultés de mesure de son succès.
00:03:31 Limitations des proofs of concept dans l’industrie de la supply chain.
00:06:30 Importance d’une approche holistique et des délais dans l’optimisation de la supply chain.
00:08:00 Importance de se concentrer sur les aspects non changeants d’une initiative.
00:08:54 Difficulté de collecte des données dans les proofs of concept.
00:11:55 Problèmes de simplification d’une initiative à la seule prévision.
00:13:54 Les limites des prévisions de séries temporelles.
00:15:17 Expériences douloureuses avec les proofs of concept et leurs lacunes.
00:17:36 Alternatives aux POC pour évaluer les fournisseurs de logiciels de supply chain.
00:20:25 L’avenir des POC dans l’industrie de la supply chain et leurs limites.
00:21:31 Importance d’adopter une approche holistique de l’optimisation de la supply chain.
00:22:52 Évaluation des performances des fournisseurs sur une base hebdomadaire plutôt que de se fier aux POC.
Résumé
Lors d’une interview, Joannes Vermorel, fondateur de Lokad, et l’animateur Kieran Chandler discutent de l’optimisation de la supply chain et des limites des proofs of concept (POC). Vermorel explique pourquoi Lokad décline souvent les demandes de POC, citant des préjudices pour les deux parties. Il estime que les POC fonctionnent mieux pour des problèmes étroitement définis, tels que le choix d’un client de messagerie électronique, mais qu’ils sont insuffisants pour des processus complexes et transformateurs comme l’optimisation de la supply chain. Les supply chains impliquent plusieurs parties et présentent un défi distribué que les POC simplifient souvent à l’excès. Il conseille de se concentrer sur les aspects stables et les perspectives holistiques basées sur les données. Vermorel suggère également d’évaluer régulièrement les performances des fournisseurs et de mettre fin aux relations qui ne montrent pas de progrès satisfaisants.
Résumé détaillé
Lors de l’interview, Kieran Chandler, l’animateur, et Joannes Vermorel, fondateur de Lokad, engagent une discussion détaillée sur les proofs of concept (POC) dans le contexte des logiciels de supply chain et de leurs limites. Vermorel explique pourquoi Lokad décline fréquemment les demandes de POC de la part des clients potentiels, citant les préjudices potentiels pour l’entreprise du client et pour Lokad.
Vermorel commence par reconnaître que les POC existent depuis deux décennies et ne sont pas intrinsèquement préjudiciables. Ils fonctionnent efficacement lorsqu’ils sont appliqués à un problème étroitement défini. L’archétype d’une situation où un POC fonctionnerait bien est le choix d’un client de messagerie électronique comme Microsoft Outlook ou Gmail. Il s’agit d’un problème standardisé avec une solution connue. L’utilisateur a des attentes claires et connaît les points douloureux. Ce processus n’est plus transformateur ; il s’agit simplement de passer d’un client de messagerie électronique à un autre.
Cependant, le défi se pose lorsque les POC sont appliqués à l’optimisation de la supply chain, que Vermorel qualifie de “l’opposé” d’un problème étroitement défini. Il suggère que c’est un processus transformateur pour une entreprise, le caractérisant comme un problème non local couvrant plusieurs sites et potentiellement de nombreux pays. La complexité est amplifiée en raison de la nature interconnectée de la supply chain.
Approfondissant l’idée d’un “problème ouvert”, Vermorel décrit l’optimisation de la supply chain comme l’idée de vouloir optimiser, ce qui nécessite intrinsèquement une mesure. L’établissement d’une mesure significative en termes monétaires nécessite des efforts substantiels, et les métriques obtenues ne sont que le début. Le voyage se poursuit avec le raffinement de la “recette numérique” pour évaluer l’impact des actions sur les opérations de l’entreprise. Il donne l’exemple de l’évaluation du coût précis de chaque rupture de stock ou de l’impact spécifique sur la fidélité du client pour chaque client.
Lorsqu’on lui demande si les POC sont inefficaces exclusivement pour la supply chain quantitative ou pour l’ensemble de l’industrie de la supply chain, Vermorel affirme que la plupart des problèmes de supply chain sont difficiles à formuler en tant que POC en raison de leur nature interconnectée. Il explique que les supply chains impliquent plusieurs parties - fournisseurs, clients, entrepôts de stockage et usines de production. Ils présentent un défi distribué, par opposition à un défi localisé, comme l’optimisation d’un processus de fabrication en isolation.
Vermorel souligne que les supply chains sont intrinsèquement liées aux fournisseurs et aux clients, ce qui rend difficile l’identification de quelque chose à la fois local et significatif. Il met en garde contre le fait qu’il est facile de réaliser des optimisations locales dans les supply chains, mais que ces efforts aboutissent généralement à déplacer simplement les problèmes. Par exemple, un effort important pour optimiser un produit à un endroit peut involontairement créer des problèmes ailleurs dans la supply chain.
Vermorel explique que l’optimisation de la supply chain est difficile pour les POC car ils ont tendance à se concentrer sur des micro-optimisations sans tenir compte de l’ensemble du tableau. Cela peut entraîner des problèmes pour les fournisseurs et les clients. De plus, les délais de livraison compliquent davantage le processus car il est difficile d’optimiser une supply chain dans un délai plus court que le délai de livraison lui-même. Cela entraîne souvent des POC qui prennent beaucoup plus de temps que prévu.
Chandler et Vermorel discutent de l’importance de prendre en compte l’ensemble du tableau lors de la tentative d’optimisation des supply chains. Ils mentionnent que les POCs ne tiennent souvent pas compte des délais de livraison complets nécessaires pour une véritable compréhension de la supply chain. Vermorel conseille d’adopter une approche capitaliste à chaque étape de la méthodologie, en se concentrant sur ce qui ne changera pas quel que soit le fournisseur ou la solution choisie.
Un défi rencontré lors des POCs est la collecte et la mesure des données. Vermorel estime que l’on ne peut pas optimiser ce que l’on ne mesure pas, il faut donc donner la priorité à la collecte de données. Cependant, la réalité rend souvent la collecte de données pour les POCs plus difficile que prévu. Cela est dû à la complexité des situations réelles, telles que les réseaux de vente au détail avec plusieurs entrepôts, unités de production et lieux de distribution.
Vermorel donne un exemple de la difficulté d’évaluer avec précision la demande historique. Des problèmes tels que les ruptures de stock, les promotions et autres anomalies peuvent fausser les données de commande historiques, rendant difficile la compréhension des véritables tendances de la demande. Lorsque les POCs rencontrent ces problèmes, ils reviennent souvent à des méthodes de prévision classiques, telles que les prévisions hebdomadaires des séries chronologiques. Cette approche simplifie le problème mais ignore les complexités et subtilités de l’optimisation de la supply chain.
Le backtesting, ou l’utilisation de données historiques pour tester les prévisions, est un autre outil utilisé dans l’optimisation de la supply chain. Bien qu’il fonctionne d’un point de vue statistique, Vermorel soutient que cela ne représente qu’une fraction du tableau d’ensemble de la gestion de la supply chain. Par exemple, les schémas d’achat peuvent être influencés par des facteurs tels que les prix négociés et les quantités minimales de commande (MOQ), qui ne sont pas pris en compte dans le backtesting.
Vermorel souligne que l’optimisation de la supply chain n’est pas un problème unidimensionnel qui peut être résolu en se concentrant uniquement sur la précision des prévisions. Il soutient que les processus existants doivent être réexaminés et ajustés pour rendre l’optimisation possible. Le principal problème de se concentrer sur les prévisions est qu’il néglige le tableau d’ensemble et repose sur un type spécifique de prévision qui peut ne pas être applicable à toutes les situations.
Vermorel souligne que les supply chains sont numérisées depuis des décennies, mais de nombreuses entreprises continuent de s’appuyer sur des feuilles Excel et ignorent les chiffres générés par divers systèmes. Il suggère que les entreprises devraient se concentrer sur les fondamentaux, tels que la consolidation des données dans un lac de données et la création d’une documentation significative qui reflète la sémantique de leur supply chain.
En se concentrant sur les aspects stables d’une supply chain, tels que les fournisseurs, les unités de production, les entrepôts et les canaux de distribution, les entreprises peuvent élaborer des indicateurs qui reflètent leurs intérêts financiers à long terme. Vermorel souligne que le principal défi réside dans la compréhension de la sémantique des données et dans la garantie que les bonnes données sont disponibles pour l’optimisation.
Lorsqu’il s’agit d’alternatives aux POCs, Vermorel propose de se concentrer sur ce qui ne change pas dans une supply chain et de rechercher un fournisseur capable de fournir une perspective holistique basée sur les données. Bien que les POCs puissent offrir certaines informations, il met en garde contre des attentes trop élevées vis-à-vis des expériences à petite échelle, car les problèmes complexes nécessitent des approches plus approfondies.
Il suggère également que travailler avec des fournisseurs ne devrait pas être un engagement à long terme. Les entreprises peuvent s’engager dans des initiatives lean et évaluer les performances du fournisseur sur une base hebdomadaire pour garantir des progrès. Si les progrès ne sont pas satisfaisants, il vaut mieux mettre fin à la relation tôt plutôt que de continuer avec un fournisseur sous-optimal.
Transcription complète
Kieran Chandler: Aujourd’hui, nous allons comprendre exactement pourquoi les POC ne fonctionnent pas et également comprendre quelles sont les alternatives qui s’offrent à un client pour choisir parmi la multitude de logiciels de supply chain disponibles. Alors, Joannes, les POC existent depuis deux décennies maintenant, donc ils ne peuvent pas tous être mauvais. Dans quels secteurs fonctionnent-ils réellement ?
Joannes Vermorel: Les preuves de concept fonctionnent bien lorsque vous avez un problème étroit et précis que vous souhaitez résoudre, lorsque vous n’avez pas à penser à de vastes possibilités ouvertes. Par exemple, l’archétype d’un domaine où un POC fonctionnerait bien serait si je vous demandais de choisir votre client de messagerie électronique parce que vous avez utilisé un client de messagerie électronique, disons Microsoft Outlook ou Gmail, pendant des années. Donc, vous savez à quoi vous attendre, vous connaissez vos points douloureux. Il s’agit d’un problème assez standardisé avec des solutions standardisées, et vous ferez une comparaison très précise car vous savez exactement ce que vous devez rechercher. Pour votre entreprise, il s’agit fondamentalement de quelque chose qui n’est pas transformateur ; cela l’était il y a des décennies lorsque les gens ont commencé à utiliser le courrier électronique, mais à ce stade, il s’agit simplement de passer d’un client de messagerie électronique à un autre. Les POC fonctionnent bien pour ces problèmes super tactiques et bien définis. Le grand défi est que la supply chain quantitative est un peu l’opposé. C’est quelque chose qui transformera fondamentalement votre entreprise, et c’est fondamentalement quelque chose qui est complètement non local. Vous ne pouvez pas exécuter une supply chain localement depuis votre bureau. C’est parce qu’il y a un réseau qui s’étend sur de nombreux endroits, potentiellement de nombreux pays, que les choses deviennent vraiment compliquées.
Kieran Chandler: Alors, qu’est-ce qui caractérise cela comme un problème ouvert ?
Joannes Vermorel: La supply chain est d’abord une idée que nous voulons optimiser, et pour optimiser, vous devez mesurer. Le simple fait que vous souhaitiez mesurer les choses en euros ou en dollars nécessite un effort considérable pour obtenir une mesure qui ait réellement du sens. La métrique, le point de départ, est en réalité un voyage pour affiner la manière dont votre recette numérique évalue si vous faites quelque chose de bon ou de mauvais pour votre entreprise. De toute évidence, servir les clients est bon, avoir un énorme nombre de ruptures de stock est mauvais, mais la question devient exactement comment évaluer le coût précis de chaque rupture de stock, l’impact précis sur la fidélité des clients pour chaque client ?
Kieran Chandler: Donc, lorsque vous dites que les preuves de concept ne fonctionnent fondamentalement pas, est-ce seulement pour la supply chain quantitative qu’elles ne fonctionnent pas, ou est-ce pour l’ensemble de l’industrie de la supply chain ?
Joannes Vermorel: La plupart des problèmes de supply chain sont très difficiles à formuler en termes de preuves de concept. Par définition, les supply chains impliquent plusieurs parties : vous avez de nombreux fournisseurs, de nombreux clients, des entrepôts de stockage, des usines de production. C’est un défi très distribué dans son essence, contrairement à quelque chose qui serait extrêmement local, comme l’optimisation d’un processus de fabrication qui est complètement isolé du reste du monde. Les supply chains sont complètement connectées à vos fournisseurs et à vos clients. Donc, pratiquement par définition, il est difficile de trouver quelque chose qui soit à la fois local et significatif, car le problème avec les supply chains est qu’il est très facile de réaliser une optimisation locale. Le problème est que lorsque vous faites cela, vous finissez généralement par déplacer les problèmes. Donc, oui, vous avez fait beaucoup. Donc, vous avez créé un problème pour votre fournisseur et peut-être aussi pour quelques clients en faisant cela. Vous n’avez pas résolu le tableau d’ensemble ; vous avez simplement micro-optimisé quelque chose localement. Cela rend la supply chain très difficile pour les preuves de concept en général. Et puis il y a une autre couche de difficulté dans le cas de Lokad. Parce que nous voulons aborder l’avenir et les incertitudes, il y a les délais de livraison qui doivent être pris en compte. Donc, chaque fois que nous traitons d’une industrie où les délais de livraison sont, disons, vous devez planifier et exécuter les choses en pensant trois mois à l’avance. Cela signifie que quelle que soit l’optimisation numérique que vous faites pour votre supply chain, une itération prend à peu près autant de temps que votre délai de livraison pour se réaliser. Donc, cela signifie que vous ne pouvez pas vraiment faire quoi que ce soit dans un délai plus court que votre délai de livraison, et plus réaliste, vous aurez besoin de deux ou trois itérations. Donc, si vous avez des délais de trois mois environ, et nous parlons de deux ou trois itérations, nous parlons de six à neuf mois. Ce n’est pas excessivement long pour un logiciel d’entreprise, mais nous commençons à nous éloigner beaucoup de ce que les gens pensent lorsqu’ils pensent à une preuve de concept rapide.
Kieran Chandler: Essayons de décomposer cela un peu. Donc, ce que vous dites, c’est qu’une preuve de concept ne regarde essentiellement qu’une petite image, et pour qu’une solution fonctionne vraiment et se prouve, elle doit regarder l’ensemble de l’image plus grande. Et puis la deuxième chose que vous avez mentionnée concerne les délais de livraison, et vous dites qu’une preuve de concept est normalement assez courte, donc nous ne prenons pas en compte les délais de livraison complets pour vraiment obtenir les résultats et comprendre ce qui se passe. Combien de temps devriez-vous vraiment persévérer avec une preuve de concept avant de voir réellement des résultats ?
Joannes Vermorelr: Le point est que si vous attendez de finaliser vos mesures et qu’il est absolument clair que vous pouvez mesurer les avantages et les codifier, cela prendra trop de temps. C’est pourquoi, en général, ce que nous suggérons, c’est d’avoir une méthodologie qui est très capitaliste à chaque étape et qui est guidée par la vision. Ce que je veux dire par capitaliste à chaque étape, c’est que peu importe comment vous voulez optimiser votre supply chain, vous aurez besoin de données pour exécuter cette optimisation. Le processus va prendre un peu de temps, mais il est indépendant du fournisseur ou de la solution que vous choisissez, que vous souhaitiez le faire en interne ou avec une entreprise externe. Vous devrez suivre ce processus. Si vous pouvez exécuter votre initiative de manière à vous concentrer sur ce qui ne changera pas par rapport au fournisseur choisi, le cas échéant, à la fin de l’initiative, alors vous pouvez être très capitaliste. Par exemple, vous ne pouvez pas optimiser ce que vous ne mesurez pas, donc vous devriez commencer à collecter des données pour les mesures. Cet effort même va probablement dépasser ce que vous pensez être éligible pour un effort de taille de preuve de concept.
Kieran Chandler: Cela surprendra probablement beaucoup de nos téléspectateurs car, dans les preuves de concept, la collecte des données devrait être la partie facile fournie lorsque vous commencez la preuve de concept. Alors pourquoi est-ce si difficile ?
Joannes Vermorel: C’est toujours difficile car la réalité a ses propres moyens de s’assurer que vos tentatives de preuve de concept échouent de la manière la plus misérable qui soit. Mais plus sérieusement, prenons une situation réelle de ce qui se passe. Disons que vous avez un réseau de vente au détail qui comprend quelques entrepôts, quelques unités de production et peut-être quelques sites de distribution. Maintenant, vous lancez votre initiative où vous dites.
Kieran Chandler: Parlons des clients satisfaits de la façon dont vous les servez. Donc, vous réalisez que vous voulez commencer votre preuve de concept et vous constatez que obtenir toutes les données transactionnelles est plus difficile qu’il n’y paraissait au départ. Pourquoi est-ce ?
Joannes Vermorel: Eh bien, par exemple, vous pourriez dire que les commandes des clients devraient être faciles. Oui et non, car vous pouvez avoir beaucoup de situations étranges, comme un client qui vous envoie une commande que vous ne pouvez pas exécuter en raison d’une rupture de stock. Vous enregistrez consciencieusement dans le système que la commande n’a pas pu être exécutée. Le lendemain, le client passe une autre commande, encore plus importante. Pourquoi ? Parce que vous n’avez pas exécuté la commande du jour précédent. Mais si vous aviez exécuté la première commande, il n’y aurait probablement pas eu de deuxième commande le lendemain. Donc, vous voulez refléter la demande historique, pas seulement le flux historique brut des commandes du client qui ont été impactées pour diverses raisons. Vous réalisez que c’est plus compliqué que cela ne semble.
Kieran Chandler: Que se passe-t-il généralement avec une initiative de preuve de concept lorsque vous êtes confronté à tous ces problèmes ?
Joannes Vermorel: Vous essayez de trouver des moyens de simplifier les problèmes et vous revenez inévitablement à une preuve de concept de prévision classique, comme une prévision de séries temporelles hebdomadaire. Vous pensez en termes de prévision de la demande basée sur la demande historique, et vous pouvez tester cela immédiatement. Vous ignorez les ruptures de stock, les promotions et tous les facteurs bizarres. Le résultat final est quelque chose qui correspond à la définition d’une preuve de concept, mais en faisant cela, vous vous êtes complètement écarté du problème que vous essayiez de résoudre.
L6 Kieran Chandler: Parlons un peu du backtesting. C’est regarder les données historiques passées, faire des prévisions et les comparer. Pourquoi le backtesting ne fonctionne-t-il pas vraiment ?
Joannes Vermorel: Le backtesting fonctionne d’un point de vue statistique, mais il a des limites. D’un point de vue de la supply chain, le backtesting n’est qu’un petit outil numérique qui n’est qu’une fraction de l’image globale. Si vous commencez à réfléchir à l’optimisation des schémas d’achat de vos équipes, il s’avère que peut-être toutes ces quantités de commande minimales ne sont pas gravées dans la pierre. Peut-être que ces achats peu fréquents sont causés par le fait que votre équipe d’achat a négocié des prix bas, mais avec des quantités de commande minimales excessivement élevées. Cela force votre équipe à mettre un délai supplémentaire entre les commandes d’achat, ce qui complique tout et augmente les délais de livraison.
Ce que je veux dire, c’est que l’optimisation n’est pas seulement une chose unidimensionnelle, comme la réduction de l’erreur d’un point de vue de l’exactitude des prévisions. Il s’agit également d’embrasser et de revoir tous les processus existants et d’ajuster ce qui est fait lorsque cela est possible afin que l’optimisation devienne réellement possible. De plus, vous devez réfléchir à ce que vous mesurez réellement. Le problème est que ces petits projets de preuve de concept, qui finissent inévitablement par des références d’exactitude des séries temporelles, se retrouvent avec une erreur exprimée en pourcentage au lieu de dollars. Encore une fois, nous sommes très loin de tout fondement commercial.
Kieran Chandler: Donc, le véritable problème avec la prévision, c’est que vous vous concentrez uniquement sur cet aspect et ne regardez pas le tableau d’ensemble ? C’est un type très spécifique de prévision. Rassembler toutes les données pertinentes est difficile, donc vous pouvez être assuré que votre preuve de concept sera une prévision classique de séries temporelles avec des données hebdomadaires en entrée et une prévision hebdomadaire en sortie, et c’est censé être tout. Je suppose que ce que nous décrivons aujourd’hui découle un peu de la douleur de l’expérience, des choses que vous avez essayées dans le passé et des POC que vous avez réalisés. Alors, quels sont certains des problèmes clés que vous avez rencontrés lorsque vous avez réalisé des POC ?
Joannes Vermorel: Le pire, c’est que parfois vous pouvez réussir complètement dans le POC, et c’était probablement la chose qui a fait le plus mal. En tant qu’entreprise de logiciels, vous ne remportez pas chaque opportunité qui se présente, donc perdre des opportunités fait partie de la vie. Ce qui fait vraiment mal, c’est lorsque vous remportez le POC parce que, oui, dans le POC vous performez le mieux, potentiellement avec une marge énorme, et puis lorsque vous essayez de traduire cela dans une situation de production, tout explose complètement et ne répond à aucune des attentes du client. Vous réalisez que c’est parce que vous êtes passé d’un problème fictif à un problème réel. Peut-être que tout ce que vous aviez fait pour le problème fictif fonctionnait très bien sur cette portée limitée avec une métrique bien définie, mais cela ignorait complètement tous les fondements commerciaux. Lorsque vous passez à la situation de production, vous réalisez que votre solution est loin de fournir une réponse.
Le pire, c’est que parce que les chaînes d’approvisionnement ont été numérisées depuis quelques décennies maintenant, pour les grandes entreprises, vous réalisez que la solution que vous apportez à l’entreprise va être comme les tentatives précédentes. Elle produira une masse de chiffres qui seront complètement ignorés par tout le monde. Inévitablement, toutes les équipes de la chaîne d’approvisionnement reviennent à leurs feuilles Excel habituelles, ignorant complètement les chiffres dysfonctionnels produits par un autre système.
Kieran Chandler: Regardons maintenant les choses du point de vue d’une entreprise. Le bon côté des POC (Proof of Concept) est que vous pouvez voir les différentes façons dont les fournisseurs de logiciels abordent un problème et comment ils réagissent réellement à certains défis. Mis à part cela, quelles sont les alternatives que les entreprises peuvent utiliser à la place d’un POC ? Que peuvent-elles faire d’autre pour voir comment différentes entreprises se comportent ?
Joannes Vermorel: L’alternative est de se concentrer sur les fondamentaux. Je soulignais qu’il y a le défi de la consolidation des données. La manière moderne de le faire actuellement est de construire un lac de données. L’étape suivante consiste à fournir une documentation significative du point de vue de la chaîne d’approvisionnement. Pour réussir, vous devez vous concentrer sur ce qui ne change pas. Votre chaîne d’approvisionnement ne changera probablement pas de manière fondamentale. Vous aurez toujours des fournisseurs, des unités de production, des entrepôts et des canaux de distribution. Il y a beaucoup de choses qui sont censées être relativement stables, donc concentrez-vous là-dessus. Lorsque vous consolidez les données, consolidez également la documentation pertinente car le grand défi est toujours la sémantique des données.
Que signifient ces données ? Lorsque nous avons une date de commande, s’agit-il de la date à laquelle vous avez produit la commande à envoyer au fournisseur, de la date à laquelle l’entrée a été enregistrée dans votre système ou de la date à laquelle votre fournisseur a accusé réception de la commande ? Il y a une douzaine de possibilités. La question est, où toutes ces choses sont-elles documentées ? Si vous n’avez pas accès aux données et à la sémantique des données, il n’y a aucun espoir d’optimiser quoi que ce soit. Encore une fois, par exemple, lorsque j’ai décrit une approche de chaîne d’approvisionnement quantitative, oui, il y a Lokad en tant que plateforme de cloud computing pour exécuter à grande échelle toutes ces recettes numériques. Mais les choses qui sont très capitalistiques pour le client sont la consolidation de toutes les données pertinentes, la compréhension de la sémantique de la chaîne d’approvisionnement, la création de métriques qui reflètent vraiment l’intérêt financier à long terme de votre entreprise, ce qui est difficile. La création de processus qui s’adaptent bien aux contraintes physiques de votre chaîne d’approvisionnement, et tout cela se trouve à l’intérieur et est largement indépendant de l’ensemble d’outils que vous utilisez pour exécuter ces calculs numériques.
Kieran Chandler: Si nous commençons à rassembler les choses et à conclure aujourd’hui, les POC existent dans l’industrie de la chaîne d’approvisionnement depuis des décennies maintenant. Je veux dire, pouvez-vous vraiment envisager un moment où les POC n’existeront plus du tout ?
Joannes Vermorel: Évidemment, il y aura toujours des jeunes qui ne savent pas mieux et qui demanderont un autre POC. Vous savez, c’est juste un fait de la vie. Et peut-être auront-ils raison, car encore une fois, il y a des situations, même dans les chaînes d’approvisionnement, où un POC est vraiment la voie à suivre. Si vous avez une nouvelle imprimante à codes-barres qui semble compatible avec le système, qui possède les anciennes imprimantes à codes-barres, mais que la nouvelle est simplement meilleure, plus rapide, moins chère, plus efficace, et ainsi de suite. C’est un problème où vous pouvez acheter une autre imprimante à codes-barres et la tester dans votre entrepôt préféré. Donc, il y a des situations et des problèmes où un POC est simplement la voie à suivre. Cependant, lorsque vous voulez réfléchir à un défi d’optimisation à l’échelle de la chaîne d’approvisionnement qui prend vraiment une perspective holistique de votre chaîne d’approvisionnement, je dirais de ne pas attendre trop de petites expériences à petite échelle. C’est juste qu’inévitablement, vous vous rendrez compte que le problème est complexe, et si vous ne vous donnez pas suffisamment de mal, vous échouerez simplement parce que vous n’avez même pas suffisamment essayé de résoudre le problème.
Kieran Chandler: Donc, en conclusion, le message clé d’aujourd’hui est que les POC peuvent vous donner une certaine idée, mais n’en attendez pas trop, et ils ne fonctionnent pas vraiment dans leur ensemble ?
Joannes Vermorel: Oui, et l’opposé d’un POC ne devrait pas être un engagement de dix ans avec un fournisseur. Je veux dire, c’est aussi une autre chose. Ce n’est pas parce que vous ne faites pas un POC que vous ne pouvez pas dire : “Je suppose que nous pouvons travailler avec un fournisseur. Ce que nous aimerions, c’est démarrer des initiatives, vous savez, une industrie lean, donc cela ne doit pas être très cher, et ensuite nous avancerons avec vous semaine après semaine.” Au lieu de prêter attention au fait que nous sommes censés encadrer les initiatives dans les dix semaines, c’est plutôt, est-ce que la vitesse de progression de l’initiative vous satisfait ? D’une semaine à l’autre, progressez-vous à un rythme satisfaisant ?
Si vous choisissez un fournisseur et qu’après trois semaines vous réalisez que les choses semblent toujours très lentes, alors vous devriez abandonner, même dans un délai plus court qu’un POC typique. La question est plutôt, vous pensez dix ans à l’avance, mais c’est votre vision. Vous vous concentrez sur un élément qui sera très capitaliste pour votre entreprise au cours de la prochaine décennie. Mais quand il s’agit de mettre un fournisseur d’entreprise à la porte parce qu’il ne livre tout simplement pas, c’est plus une évaluation hebdomadaire où vous réévaluez si les choses progressent et s’il y a une sorte de dynamique qui se construit. Vous recherchez tous ces petits signes, avec une planification indéfinie à l’esprit.
Kieran Chandler: Nous devons en rester là, mais nous verrons si nous avons fait peur à tout le monde.
