00:00:13 Défis de la mise en œuvre des POCs dans la supply chain.
00:01:00 Quand les POCs fonctionnent bien et en quoi la supply chain diffère.
00:02:29 La supply chain comme problème ouvert et les difficultés à mesurer son succès.
00:03:31 Limitations des POCs dans l’industrie de la supply chain.
00:06:30 Importance d’une approche holistique et des lead times dans l’optimization de la supply chain.
00:08:00 Importance de se concentrer sur les aspects stables d’une initiative.
00:08:54 Difficulté à collecter des données dans les POCs.
00:11:55 Problèmes liés à la simplification d’une initiative en une simple prévision.
00:13:54 Les limitations des prévisions des séries temporelles.
00:15:17 Expériences douloureuses avec les POCs et leurs lacunes.
00:17:36 Alternatives aux POCs pour évaluer les fournisseurs de logiciels pour la supply chain.
00:20:25 L’avenir des POCs dans l’industrie de la supply chain et leurs limitations.
00:21:31 Importance d’adopter une approche holistique de l’optimization de la supply chain.
00:22:52 Évaluer la performance des fournisseurs sur une base hebdomadaire au lieu de compter sur les POCs.
Résumé
Dans une interview, Joannes Vermorel, fondateur de Lokad, et l’animateur Kieran Chandler discutent de l’optimization de la supply chain et des limitations des POCs. Vermorel explique pourquoi Lokad décline souvent les demandes de POC, invoquant un préjudice pour les deux parties. Il estime que les POCs fonctionnent mieux pour des problèmes étroitement définis, comme le choix d’un client de messagerie, mais qu’ils sont insuffisants pour des processus complexes et transformateurs tels que l’optimization de la supply chain. Les supply chains impliquent plusieurs parties et présentent un défi distribué que les POCs simplifient souvent à l’excès. Il conseille de se concentrer sur les aspects stables et d’adopter une approche holistique et basée sur les données. Vermorel suggère également d’évaluer régulièrement la performance des fournisseurs et de mettre fin aux relations qui n’affichent pas de progrès satisfaisants.
Résumé détaillé
Dans l’interview, Kieran Chandler, l’animateur, et Joannes Vermorel, fondateur de Lokad, se livrent à une discussion détaillée sur les POCs dans le contexte des logiciels de supply chain et leurs limitations. Vermorel explique pourquoi Lokad décline fréquemment les demandes de POC de la part de clients potentiels, invoquant un préjudice potentiel pour l’entreprise du client et pour Lokad.
Vermorel commence par reconnaître que les POCs existent depuis deux décennies et ne sont pas intrinsèquement nuisibles. Ils fonctionnent efficacement lorsqu’ils sont appliqués à un problème étroitement défini. L’exemple type d’une situation où un POC fonctionnerait bien serait de choisir un client de messagerie comme Microsoft Outlook ou Gmail. C’est un problème standardisé avec une solution connue. L’utilisateur a des attentes claires et connaît ses points de douleur. Ce processus n’est plus transformateur ; il consiste simplement à passer d’un client de messagerie à un autre.
Cependant, le défi survient lorsque les POCs sont appliqués à l’optimization de la supply chain, que Vermorel qualifie de « l’inverse » d’un problème étroitement défini. Il suggère qu’il s’agit d’un processus transformateur pour une entreprise, le qualifiant de problème non local couvrant plusieurs emplacements et potentiellement de nombreux pays. La complexité est amplifiée par la nature interconnectée de la supply chain.
En développant l’idée de « problème ouvert », Vermorel décrit l’optimization de la supply chain comme le désir d’optimiser, ce qui nécessite intrinsèquement de mesurer. L’établissement d’une mesure significative en termes monétaires demande un effort considérable, et les indicateurs obtenus ne sont qu’un point de départ. Le parcours continue par l’affinement de la « recette numérique » pour évaluer l’impact des actions sur les opérations de l’entreprise. Il donne l’exemple d’évaluer le coût précis de chaque rupture de stock ou l’impact spécifique sur la fidélité de chaque client.
Lorsqu’on lui demande si les POCs sont inefficaces exclusivement pour la Supply Chain Quantitative ou pour l’industrie de la supply chain dans son ensemble, Vermorel affirme que la plupart des problèmes de supply chain sont difficiles à encadrer en tant que POCs en raison de leur nature interconnectée. Il explique que les supply chains impliquent plusieurs parties — fournisseurs, clients, warehouses, et usines de production. Ils présentent un défi distribué, par opposition à quelque chose d’extrêmement local, comme l’optimization d’un processus de fabrication isolé.
Vermorel souligne que les supply chains sont intrinsèquement liées aux fournisseurs et aux clients, rendant difficile l’identification de tout ce qui soit à la fois local et significatif. Il met en garde contre le fait que, bien qu’il soit facile d’effectuer des optimisations locales dans les supply chains, ces efforts se résument souvent à déplacer les problèmes. Par exemple, un effort considérable pour optimiser un produit dans un site peut, involontairement, créer des problèmes ailleurs dans la supply chain.
Vermorel explique que l’optimization de la supply chain est difficile pour les POCs parce qu’ils se concentrent généralement sur des micro-optimisations sans tenir compte de la vision d’ensemble. Cela peut entraîner des problèmes pour les fournisseurs et les clients. De plus, les lead times compliquent encore le processus, car il est difficile d’optimiser une supply chain sur un délai inférieur au lead time lui-même. Cela conduit souvent à des POCs prenant bien plus de temps que prévu.
Chandler et Vermorel discutent de l’importance d’adopter une vision globale lorsqu’il s’agit d’optimiser les supply chains. Ils mentionnent que les POCs ne prennent souvent pas en compte les lead times 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 des défis rencontrés 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, ainsi la collecte des données doit être une priorité. Cependant, la réalité rend souvent la collecte de données pour les POCs plus difficile que prévu. Cela est dû à la complexité de situations réelles, telles que des réseaux de distribution avec de multiples warehouses, unités de production et points de distribution.
Vermorel donne l’exemple de la difficulté d’évaluer avec précision la demande historique. Des problèmes tels que les ruptures de stock, les promotions, et d’autres anomalies peuvent fausser les données historiques de commandes, rendant difficile la compréhension des véritables schémas de demande. Lorsque les POCs rencontrent ces problèmes, ils recourent souvent aux méthodes de prévision, comme aux prévisions hebdomadaires des séries temporelles. Cette approche simplifie le problème, mais ignore les complexités et les subtilités de l’optimization de la supply chain.
Backtesting, ou l’utilisation de données historiques pour tester des prévisions, est un autre outil utilisé dans l’optimization de la supply chain. Bien que cela fonctionne d’un point de vue statistique, Vermorel soutient que cela ne représente qu’une fraction de la vision d’ensemble de la gestion de la supply chain. Par exemple, les schémas d’achat peuvent être affectés par des facteurs tels que les prix négociés et les quantités minimales de commande (MOQs), qui ne sont pas pris en compte dans le backtesting.
Vermorel souligne que l’optimization 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 revus et ajustés pour rendre l’optimisation possible. Le principal problème de se focaliser sur les prévisions est que cela néglige la vision globale et repose sur un type spécifique de prévision qui peut ne pas convenir à toutes les situations.
Vermorel souligne que les supply chains ont été digitalisées depuis des décennies, mais de nombreuses entreprises s’appuient encore 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 data lake 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 warehouses 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’on envisage des 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 et basée sur les données. Bien que les POCs puissent offrir quelques aperçus, il met en garde contre le fait d’en attendre trop d’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 se lancer dans des initiatives lean et évaluer la performance du fournisseur sur une base hebdomadaire afin de s’assurer que des progrès sont réalisés. Si les progrès ne sont pas satisfaisants, il vaut mieux mettre fin à la relation rapidement plutôt que de continuer avec un fournisseur sous-optimal.
Transcription complète
Kieran Chandler: Aujourd’hui, nous allons comprendre exactement pourquoi les POCs ne fonctionnent pas et quelles sont les alternatives dont dispose un client pour choisir parmi la multitude de logiciels de supply chain existants. Alors, Joannes, les POCs existent depuis deux décennies maintenant, donc ils ne peuvent pas tous être mauvais. Dans quels secteurs fonctionnent-ils réellement ?
Joannes Vermorel: Les proofs of concept fonctionnent bien lorsqu’on a un problème étroit et précis à résoudre, quand il n’est pas nécessaire de penser à des possibilités massives et ouvertes. Par exemple, l’exemple type d’un domaine où un POC fonctionnerait bien serait si je vous demandais de choisir votre client de messagerie, car vous utilisez, par exemple, Microsoft Outlook ou Gmail depuis des années. Vous savez donc ce à quoi vous attendre, vous connaissez vos points de douleur. Il s’agit d’un problème assez standardisé avec des solutions standardisées, et vous ferez une comparaison très précise parce que vous savez exactement ce qu’il faut rechercher. Pour votre entreprise, c’est fondamentalement quelque chose qui n’est pas transformateur ; cela l’était il y a des décennies lorsque l’on a commencé à utiliser le courrier électronique, mais à ce stade, il s’agit simplement de passer d’un client de messagerie à un autre. Les POCs fonctionnent bien pour ces problèmes super tactiques et bien définis. Le grand défi est que la Supply Chain Quantitative est en quelque sorte le contraire. C’est quelque chose qui transformera fondamentalement votre entreprise, et c’est fondamentalement quelque chose de complètement non local. Vous ne pouvez pas exécuter une supply chain localement depuis votre bureau. C’est parce qu’il existe un réseau qui s’étend sur de nombreux emplacements, potentiellement de nombreux pays, que les choses se compliquent réellement.
Kieran Chandler: Alors, qu’est-ce qui caractérise cela comme un problème ouvert ?
Joannes Vermorel: La supply chain, c’est d’abord l’idée que nous voulons optimiser, et pour optimiser, il faut mesurer. Rien que le fait de vouloir mesurer des choses en euros ou en dollars demande 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 cheminement pour affiner la façon dont votre recette numérique évalue si vous faites quelque chose de bien ou de mal pour votre entreprise. Évidemment, servir les clients est bien, avoir un nombre énorme de ruptures de stock est mauvais, mais la question devient : comment évaluer le coût précis de chaque rupture de stock, l’impact précis sur la fidélité de chaque client ?
Kieran Chandler: Alors, lorsque vous dites que les proofs of concept ne fonctionnent fondamentalement pas, est-ce uniquement pour la Supply Chain Quantitative qu’ils ne fonctionnent pas, ou cela concerne-t-il l’industrie de la supply chain dans son ensemble ?
Joannes Vermorel: La plupart des problèmes de la supply chain sont très difficiles à encadrer en tant que proofs of concept. Par définition, les supply chains impliquent plusieurs parties : vous avez de nombreux fournisseurs, de nombreux clients, des warehouses, des usines de production. C’est essentiellement un défi distribué, par opposition à quelque chose d’extrêmement local, comme l’optimization d’un processus de fabrication complètement isolé du reste du monde. Les supply chains sont reliées à vos fournisseurs et à vos clients. Il est donc, par définition, 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 d’effectuer une optimisation locale. Le fait est que, lorsque vous faites cela, ce que vous obtenez généralement, c’est simplement le déplacement des problèmes. Autrement dit, vous créez un problème pour votre fournisseur et peut-être pour quelques clients également. Vous n’avez pas résolu la vision d’ensemble ; vous avez juste micro-optimisé quelque chose localement. Cela rend la supply chain très difficile à aborder avec des proofs of concept en général. Et il y a une autre couche de difficulté dans le cas de Lokad. Parce que nous voulons aborder le futur et les incertitudes, il y a les lead times qui doivent être pris en compte. Chaque fois que nous traitons d’une industrie où les lead times – c’est-à-dire qu’il faut planifier et exécuter les choses en pensant trois mois d’avance – sont présents, cela signifie que, peu importe la façon dont vous optimisez les recettes numériques de votre supply chain, une itération prend à peu près aussi longtemps que le lead time pour se réaliser. Autrement dit, vous ne pouvez rien faire dans un délai plus court que votre lead time et, de manière plus réaliste, vous aurez besoin de deux ou trois itérations. Donc, si vous avez des lead times d’environ trois mois, et que nous parlons de deux ou trois itérations, nous parlons de six à neuf mois. Ce n’est pas abusivement long pour un logiciel d’entreprise, mais nous commençons à nous éloigner de ce à quoi les gens pensent lorsqu’ils imaginent un proof of concept rapide.
Kieran Chandler: Décomposons cela un peu. Ce que vous dites, c’est qu’à partir d’une preuve de concept, on ne regarde essentiellement qu’une petite partie, et que pour qu’une solution fonctionne réellement et se prouve, elle doit examiner l’ensemble du tableau. Et puis la deuxième chose que vous avez mentionnée concerne les délais, et vous dites qu’une preuve de concept est normalement assez courte, et que nous ne prenons donc pas en compte les délais complets pour obtenir vraiment les résultats et comprendre ce qui se passe. Combien de temps devez-vous réellement persévérer avec une preuve de concept avant de voir des résultats ?
Joannes Vermorelr: Le fait est que si vous attendez d’avoir finalisé vos mesures et qu’il soit absolument clair que vous pouvez mesurer les bénéfices et les codifier, cela prendra trop de temps. C’est pourquoi, typiquement, ce que nous suggérons est de disposer d’une méthodologie qui soit fortement capitaliste à chaque étape et guidée par la vision. Par “fortement capitaliste à chaque étape”, j’entends que, peu importe comment vous souhaitez 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 en quelque sorte indépendant de tout fournisseur ou solution que vous choisissiez, même si vous souhaitez le faire en interne ou avec une entreprise externe. Vous devrez suivre ce processus. Si vous pouvez mener 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 fortement capitaliste. Par exemple, vous ne pouvez pas optimiser ce que vous ne mesurez pas, vous devriez donc commencer à collecter des données pour les mesures. Cet effort va probablement dépasser ce que vous pensez être envisageable pour une preuve de concept.
Kieran Chandler: C’est probablement assez surprenant pour beaucoup de nos téléspectateurs car, dans les preuves de concept, la collecte des données devrait être la partie facile, celle qui est fournie au début de 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 lamentable. Mais plus sérieusement, prenons un cas réel de ce qui se passe. Supposons que vous disposiez d’un réseau de distribution impliquant quelques entrepôts, quelques unités de production, et peut-être quelques points de distribution. Vous lancez alors votre initiative en déclarant.
Kieran Chandler: Parlons des clients qui sont satisfaits de votre service. Vous vous rendez compte que vous souhaitez démarrer votre preuve de concept, et vous découvrez que l’obtention de toutes les données transactionnelles est plus difficile que ce qu’il n’y paraissait initialement. Pourquoi cela ?
Joannes Vermorel: Eh bien, par exemple, vous pourriez dire que les commandes clients devraient être faciles. Oui et non, car il peut y avoir de nombreuses situations étranges, comme lorsqu’un client vous envoie une commande que vous ne pouvez pas satisfaire en raison d’une rupture de stock. Vous enregistrez consciencieusement dans le système que la commande n’a pas pu être satisfaite. Le lendemain, le client passe une autre commande, encore plus importante. Pourquoi ? Parce que vous n’aviez pas satisfait la commande du jour précédent. Ainsi, vous souhaitez refléter la demande historique, et pas seulement le flux brut historique des commandes clients qui ont été impactées pour diverses raisons. Vous vous rendez compte que c’est plus compliqué qu’il n’y paraît.
Kieran Chandler: Alors, que se passe-t-il typiquement 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 hebdomadaire des séries temporelles. Vous pensez en termes de prévision de la demande à partir de la demande historique, et vous pouvez le back tester 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 ce faisant, vous vous êtes complètement éloigné du problème que vous tentiez de résoudre.
Kieran Chandler: Parlons un peu du back testing. Cela consiste à examiner des données historiques, à faire des prévisions et à comparer les deux. Pourquoi le back testing ne fonctionne-t-il pas réellement ?
Joannes Vermorel: Le back testing fonctionne d’un point de vue statistique, mais il a ses limites. Du point de vue de la supply chain, le back testing n’est qu’un petit outil numérique qui ne représente qu’une fraction de l’ensemble. 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 minimales de commande ne sont pas gravées dans le marbre. Peut-être que ces achats peu fréquents sont causés par le fait que votre équipe d’achats a négocié des prix bas, mais avec des quantités minimales de commande extrêmement élevées. Cela oblige votre équipe à espacer davantage les commandes, ce qui complique tout et augmente les délais.
Ce que je dis, c’est que l’optimisation n’est pas une affaire unidimensionnelle, comme réduire l’erreur d’un point de vue de la précision des prévisions. Il s’agit aussi d’adopter et de revoir tous les processus existants et d’ajuster ce qui est fait, lorsque c’est possible, pour 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 reviennent inévitablement aux références de précision des séries temporelles, finissent par avoir une erreur exprimée en pourcentage au lieu de dollars. Encore une fois, nous sommes très éloignés de tout fondement commercial.
Kieran Chandler: Donc, le véritable problème avec les prévisions, c’est que vous vous concentrez uniquement sur cet aspect et que vous ne regardez pas l’ensemble du tableau ? C’est un type de prévision très spécifique. La collecte de toutes les données pertinentes est difficile, si bien que vous pouvez être assuré que votre preuve de concept sera une prévision classique des séries temporelles avec des données hebdomadaires en entrée et des prévisions hebdomadaires en sortie, et c’est censé être tout. Je suppose que ce que nous décrivons aujourd’hui provient d’une certaine douleur d’expérience, des choses que vous avez essayé dans le passé et des preuves de concept que vous avez réalisées. Quels sont alors certains des problèmes clés que vous avez rencontrés lors de la réalisation de ces preuves de concept ?
Joannes Vermorel: Le pire, c’est que parfois vous pouvez complètement réussir dans la preuve de concept, et c’est probablement ce qui fait le plus mal. En tant qu’entreprise de logiciels d’entreprise, vous ne remportez pas chaque lead qui se présente, donc perdre des leads fait simplement partie de la vie. Ce qui fait vraiment mal, c’est lorsque vous gagnez la preuve de concept, car oui, dans la preuve de concept, vous obtenez les meilleures performances, potentiellement avec une marge énorme, et ensuite, lorsque vous essayez de transposer cela en situation de production, tout explose et ne répond à aucune des attentes du client. Vous vous rendez compte que c’est parce que vous êtes passé d’un problème jouet à un problème réel. Peut-être que ce que vous aviez fait pour le problème jouet fonctionnait très bien dans ce cadre limité 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, puisque les supply chains ont été digitalisées depuis quelques décennies maintenant, pour les grandes entreprises, vous réalisez que la solution que vous introduisez dans l’entreprise sera semblable aux tentatives précédentes. Elle produira une masse de chiffres qui sera complètement ignorée par tous. Inévitablement, toutes les équipes supply chain retombent sur leurs feuilles Excel habituelles, ignorant complètement les chiffres dysfonctionnels produits par un système de plus.
Kieran Chandler: Regardons désormais les choses du point de vue d’une entreprise. L’avantage des preuves de concept, c’est que vous pouvez voir les différentes approches des fournisseurs de logiciels face à un problème et la manière dont ils réagissent à certains défis. À part cela, quelles sont les alternatives que les entreprises peuvent utiliser à la place d’une preuve de concept ? Que pourraient-elles faire d’autre pour voir comment différentes entreprises performent ?
Joannes Vermorel: L’alternative consiste à se concentrer sur les fondamentaux. J’indiquais qu’il y a le défi de la consolidation des données. La méthode moderne en ce moment est de construire un data lake. L’étape suivante est de fournir une documentation significative du point de vue de la supply chain. Pour réussir, vous devez vous concentrer sur ce qui ne change pas. Votre supply chain ne changera probablement pas dans ses aspects les plus fondamentaux. 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 devraient rester relativement stables, alors focalisez-vous sur cela. Lorsque vous consolidez les données, consolidez également la documentation pertinente, car le grand défi demeure toujours la sémantique des données.
Que signifient ces données ? Lorsque nous avons une date de commande, s’agissait-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 existe une dizaine de possibilités. La question est : où sont documentées toutes ces choses ? Si vous n’avez pas accès aux données et à leur sémantique, il n’y a aucun espoir de jamais optimiser quoi que ce soit. Encore une fois, par exemple, lorsque j’ai décrit une approche de Supply Chain Quantitative, oui, il y a Lokad en tant que plateforme de cloud computing pour exécuter à grande échelle toutes ces recettes numériques. Mais ce qui est fortement capitaliste pour le client, c’est la consolidation de toutes les données pertinentes, la compréhension de la sémantique de la supply chain, l’élaboration de métriques qui reflètent véritablement l’intérêt financier à long terme de votre entreprise, ce qui est difficile. L’élaboration de processus qui s’accordent bien avec les contraintes physiques de votre supply chain, et tout cela se situe à l’intérieur et est largement indépendant de l’outil que vous utilisez pour exécuter ces calculs numériques.
Kieran Chandler: Si nous commençons à rassembler les choses et à conclure aujourd’hui, les preuves de concept existent dans l’industrie de la supply chain depuis des décennies. Je veux dire, pouvez-vous vraiment imaginer un moment où les preuves de concept n’existeraient pas du tout ?
Joannes Vermorel: Évidemment, il y aura toujours des jeunes qui ne savent pas mieux et qui demanderont encore une preuve de concept. Vous savez, c’est simplement une réalité. Et peut-être auront-ils raison, car encore une fois, il existe des situations, même dans les supply chains, où une preuve de concept est vraiment la solution. Si vous disposez d’une nouvelle imprimante de codes-barres qui semble compatible avec le système, qui possède les anciennes imprimantes de codes-barres, mais que la nouvelle est tout simplement meilleure, plus rapide, moins chère, plus efficace, etc. C’est un problème où vous pouvez acheter une imprimante de codes-barres supplémentaire et la tester dans votre entrepôt préféré. Ainsi, il y a des situations et des problèmes où une preuve de concept est la solution. Pourtant, lorsque vous souhaitez envisager un défi d’optimisation à l’échelle de la supply chain qui adopte une perspective holistique sur votre supply chain, je dirais de ne pas trop attendre des expériences à petite échelle. Inévitablement, vous réaliserez que le problème est complexe, et si vous ne vous y investissez pas sérieusement, vous échouerez simplement parce que vous n’y avez même pas suffisamment tenté.
Kieran Chandler: Donc, en guise de message clé final pour aujourd’hui, est-ce que cela signifie que les preuves de concept peuvent vous donner un certain aperçu, mais qu’il ne faut pas trop en attendre, et qu’elles ne fonctionnent pas vraiment dans leur ensemble ?
Joannes Vermorel: Oui, et l’alternative à une preuve de concept 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 de preuve de concept que vous ne pouvez pas dire : “Je suppose que nous pouvons travailler avec un fournisseur. Ce que nous aimerions, c’est lancer des initiatives, vous savez, dans une industrie allégée, donc cela ne doit pas être très coûteux, et ensuite nous avancerons semaine après semaine avec vous.” Plutôt que de prêter attention au fait que nous sommes censés cadrer les initiatives dans un délai de dix semaines, c’est plutôt de savoir si la vitesse de progression de l’initiative vous satisfait. D’une semaine à l’autre, faites-vous des progrès à un rythme satisfaisant ?
Si vous choisissez un fournisseur et qu’après trois semaines vous réalisez que les choses semblent encore très lentes, vous devriez alors abandonner, même dans un délai inférieur à celui d’une preuve de concept typique. La question est plutôt que vous pensez à dix ans, mais c’est votre vision. Vous vous concentrez sur un élément qui sera fortement capitaliste pour votre entreprise pour la prochaine décennie. Mais lorsqu’il s’agit de congédier un fournisseur d’entreprise parce qu’il ne fournit tout simplement pas, il s’agit davantage d’une évaluation hebdomadaire où vous réexaminez si les choses progressent et s’il se crée une sorte d’élan. Vous recherchez tous ces petits signes, en gardant une planification indéfinie à l’esprit.
Kieran Chandler: Nous allons devoir nous arrêter ici, mais il faudra voir si nous avons effrayé tout le monde.
