00:00:00 Introduction à l’interview
00:00:47 Le parcours de Paul Jan et son expérience d’enseignement
00:02:16 Le rôle des données en supply chain et en enseignement
00:04:00 Collaboration avec Lokad et son impact
00:06:20 Les défis concrets de la supply chain et les obstacles pédagogiques
00:10:49 Explication des “wicked problems” en supply chain
00:14:37 L’impact du message de l’entreprise sur la perception du produit
00:16:11 Analyse continue des données et limites d’Excel
00:19:11 La gestion des données relationnelles et les lacunes d’Excel
00:21:49 Transition vers SQL pour le traitement des données
00:24:11 Les avantages d’introduire Lokad aux étudiants
00:26:33 Les considérations de coûts dans l’enseignement de la supply chain
00:29:13 Utilisation d’Envision et critique des logiciels d’entreprise
00:32:24 Pensée solution et limites des outils
00:35:16 De meilleurs outils pour de meilleures solutions supply chain
00:37:57 L’expérience d’enseignement et la philosophie de Joannes Vermorel
00:41:15 Les structures de données fondamentales et les limites de la prévision
00:45:31 Méthodes pédagogiques visuelles et hypothèses fortes
00:48:32 La nécessité d’une disruption dans l’industrie de la supply chain
00:51:12 La supply chain comme un ensemble de “wicked problems”
00:54:24 Être approximativement correct en supply chain
00:57:55 Enseigner la gestion des “wicked problems” en supply chain
01:00:47 Mots de conclusion et importance de l’investissement du secteur privé
01:03:24 Surmonter la peur des statistiques et remarques de clôture
Résumé
Conor Doherty, animateur de Lokad TV, s’est récemment entretenu avec Joannes Vermorel, fondateur de Lokad, et Paul Jan, professeur de supply chain à l’Université de Toronto. La conversation s’est centrée sur l’évolution de la gestion de la supply chain, le rôle des données et l’importance de l’éducation. Vermorel a introduit le concept de “wicked problems” en supply chain, soulignant les limites d’Excel et la nécessité d’outils comme SQL Server. Jan a partagé son expérience de transition d’Excel vers des options plus programmatiques, en louant l’outil Envision de Lokad. Tous deux ont souligné la nécessité d’une disruption dans l’industrie et l’importance de l’éducation dans la gestion de la supply chain.
Résumé Étendu
Dans une interview récente, Conor Doherty, l’animateur, s’est engagé dans une discussion stimulante avec Joannes Vermorel, le fondateur de Lokad, et Paul Jan, professeur associé en opérations et gestion de la supply chain à la Rotman School of Management. La conversation portait sur l’évolution du paysage de la gestion de la supply chain, le rôle des données et l’importance de l’éducation dans ce domaine.
Paul Jan, fort de son expérience étendue en consulting et dans le monde corporatif américain, enseigne des cours d’analyse des opérations et de la supply chain à l’Université de Toronto depuis environ quatre ans. Ses cours, qui comprennent une classe fondamentale sur la gestion de la supply chain et une classe en collaboration avec Lokad, visent à combler le fossé entre théorie et pratique. Jan reconnaît que, bien que les données soient devenues plus présentes dans l’industrie, les étudiants manquent souvent de confiance pour appliquer ce qu’ils apprennent dans le monde réel. C’est ici que la collaboration avec Lokad intervient, en offrant un environnement prêt à l’emploi pour que les étudiants travaillent sur des tâches de supply chain, leur permettant de se concentrer sur les aspects supply chain plutôt que sur les subtilités de la mise en place d’un environnement de codage.
Vermorel a introduit le concept de “wicked problems” en supply chain, c’est-à-dire des problèmes qui défient une analyse directe et de premier niveau et nécessitent un parcours de découverte. Il a souligné les limites d’Excel dans la gestion des données de la supply chain moderne, affirmant qu’Excel ne peut pas évoluer à la hauteur requise par les supply chains d’aujourd’hui. Vermorel a suggéré que la réponse de Microsoft à ce problème est SQL Server et d’autres outils capables de gérer des données relationnelles. Il a également mentionné que le playground de Lokad vise à exposer les étudiants à la réalité des données relationnelles.
Jan a partagé son expérience de transition d’Excel vers des options plus programmatiques, étant d’accord avec les observations de Vermorel concernant les limites d’Excel. Il a mentionné qu’il avait appris SQL lors d’un de ses projets et apprécié sa capacité à traiter et simplifier les données. Jan a également loué Envision, l’outil de Lokad, pour sa simplicité et sa facilité d’utilisation, qui ont permis de simplifier le processus d’ajustement des hypothèses et de réduire les erreurs pouvant survenir avec Excel.
La conversation a ensuite porté sur l’état d’esprit nécessaire pour utiliser ces outils et sur la question de savoir si des concepts tels que le coût d’opportunité sont enseignés en classe. Jan a répondu que, bien que le concept de coût d’opportunité ne soit pas simple, les étudiants ayant une formation en économie peuvent le comprendre. Il a noté un fossé entre ce que comprennent et auquel prêtent attention les cadres et les opérationnels, les premiers se concentrant sur les résultats financiers et les seconds sur des indicateurs traditionnels.
Vermorel a acquiescé aux propos de Jan et a évoqué les limites d’une réflexion confinée au paradigme Excel. Il a expliqué que si l’on ne pense qu’à Excel, cela limite les solutions envisageables. Vermorel a critiqué l’idée selon laquelle les technologies digitales changeraient constamment et que les connaissances dans ce domaine seraient jetables. Il a soutenu que de nombreux sujets fondamentaux, tels que la structure des données relationnelles et les types de données de base, sont peu susceptibles de changer de manière significative au fil du temps.
L’interview s’est conclue avec Vermorel et Jan soulignant la nécessité d’une disruption dans l’industrie et l’importance de l’éducation dans la gestion de la supply chain. Vermorel a expliqué que la gestion de la supply chain implique une série de problèmes complexes en raison de la nature interconnectée des entreprises modernes. Il a plaidé pour l’utilisation de paradigmes et d’outils capables de gérer ces problèmes complexes, plutôt que de chercher des solutions exactes qui pourraient être erronées. Jan, quant à lui, a décrit son approche pédagogique comme à la fois progressive et disruptive, en commençant par des théories traditionnelles avant d’introduire des complexités du monde réel via la collaboration avec des entreprises telles que Lokad. Il a reconnu la difficulté d’enseigner les “wicked problems”, qui sont complexes et dépendent des actions d’autrui.
Transcription complète
Conor Doherty: Bon retour sur Lokad TV. Les compétences requises pour exceller en supply chain ont évolué de manière spectaculaire au cours des 20 dernières années et continueront de le faire pour l’instant. Rien de tout cela, bien sûr, n’est une nouveauté pour les invités d’aujourd’hui. Nous accueillons à distance, depuis la Rotman School of Management, le professeur associé en opérations et gestion de la supply chain, Paul Jan. Paul, bienvenue sur Lokad. Merci de m’avoir invité. C’est un plaisir d’être ici.
Conor Doherty: Maintenant Paul, je disais, bienvenue sur Lokad, bien que ce soit un peu un nom trompeur. Enfin, nous sommes déjà très familiers. Vous avez collaboré avec nous depuis un certain temps et, en fait, vous nous avez rendu visite ici dans les nouveaux bureaux à Paris. Mais pour ceux qui ne connaissent pas votre travail, pourriez-vous vous présenter et décrire votre parcours, s’il vous plaît ?
Paul Jan: Merci de m’avoir invité. Je m’appelle Paul Jan. Je suis actuellement professeur à l’Université de Toronto, où j’enseigne des cours d’analyse des opérations et de la supply chain. Je viens d’un milieu industriel avec une vaste expérience en conseil ainsi que dans le secteur des entreprises américaines. J’ai passé environ 15 ans dans l’industrie et le conseil, et maintenant j’enseigne, partageant mes connaissances et mon expérience avec tous les étudiants de l’UofT.
Conor Doherty: Et depuis combien de temps enseignez-vous à la Rotman School of Management ?
Paul Jan: Je suis à Rotman depuis environ quatre ans, et avant cela, j’étais à l’Université de Californie, Irvine. Donc, au total, j’enseigne depuis environ sept ans.
Conor Doherty: Et comment les cours sur la supply chain ont-ils évolué, même sur ce court laps de temps ?
Paul Jan: Ici à Rotman, j’enseigne un cours fondamental, qui est une introduction aux opérations et à la gestion de la supply chain. C’est là que les étudiants apprennent les théories de base, les applications et certaines pratiques. J’enseigne également un autre cours en collaboration avec Lokad. L’objectif est de mettre en action ces théories et pratiques au sein d’une entreprise. Au fil des années, il y a de plus en plus de données provenant des ERP des entreprises, et même des entreprises de taille moyenne à petite, qui disposent toutes d’un système de collecte de données ou d’ERP. Ainsi, les données sont devenues plus importantes, et d’après ce que j’ai observé, les étudiants manquent de confiance et d’expérience pour appliquer ce qu’ils apprennent à l’école dans le monde réel.
Conor Doherty: Eh bien, et Joannes, je reviendrai vers vous dans un instant, mais je voulais juste enchaîner sur ce point, car vous avez une vaste expérience dans le secteur privé. Lorsque vous sélectionnez les théories fondamentales à enseigner aux étudiants, quelle part de celles-ci relève des connaissances traditionnelles en supply chain et quelle part est influencée par votre expérience étendue ?
Paul Jan: Dans le cours fondamental que j’enseigne, je n’ai pas beaucoup de marge de manœuvre. Je dois suivre un programme et respecter les exigences fixées par l’université et le département. La plupart de ces éléments sont donc les théories et modèles traditionnels que les étudiants apprendront. Ce que je fais, c’est les compléter par des anecdotes et des histoires, ou des points auxquels il faut faire attention, comme complément pour les étudiants lorsqu’ils entrent dans la vie professionnelle. Mais, en tant qu’exigence de l’école, les fondations reposent sur les théories traditionnelles, ce qu’ils apprendront dans ce cours. Dans l’autre, en collaboration avec Lokad, j’ai la liberté d’appliquer un enseignement plus orienté du point de vue du praticien. En termes de prise de conscience des réalités, notamment des résultats financiers, les théories traditionnelles de base ne prennent pas cela en compte. Or, dans la pratique, les cadres se pencheront sur l’impact financier de la réalisation de telle ou telle action. Voilà la différence entre les deux et la manière dont j’applique mon expérience dans ces différents cours.
Conor Doherty: Eh bien, merci, Paul. Et maintenant, Joannes, à vous de prendre la parole : pourriez-vous décrire en quoi consiste exactement la collaboration avec Paul dans le cadre de l’initiative éducative plus large de Lokad ?
Joannes Vermorel: Oui, chez Lokad, nous avons lancé une initiative il y a environ un an pour rendre notre pile technologique plus largement accessible. Lokad se présente normalement sous forme d’un logiciel d’entreprise, accessible uniquement à nos prospects VIP et clients. Ce que nous avons fait, c’est de reconditionner cela sous ce que nous appelons un playground, qui est une version légèrement simplifiée de Lokad accessible sur tr.lo.com. Cela donne accès à un environnement de codage propulsé par Envision et à un petit système de fichiers. Pour des fins éducatives, l’idée est d’organiser une série d’ateliers où les étudiants peuvent prendre un ensemble de données, une version simplifiée de ce que l’on trouve dans des configurations réelles, mais toujours assez représentative. Nous ne voulions pas rendre la tâche trop facile ou trop théorique. L’idée est de fournir un environnement prêt à l’emploi où l’étudiant peut directement commencer avec un ensemble de données et un petit défi de supply chain à exécuter sur cet ensemble. Cela reflète le genre de défis auxquels les personnes peuvent être confrontées lorsqu’elles rejoignent une entreprise où il y a des problèmes avec les fournisseurs. Il faut analyser et déterminer quels sont les fournisseurs qui ne parviennent pas à livrer à temps et en intégralité, ou vouloir prévoir la demande ou toute autre tâche analytique supply chain. L’idée est que Lokad souhaite fournir un environnement pour cela. Le fait est que les étudiants qui étudient le matériel de supply chain ne sont pas des ingénieurs logiciels. Donc oui, si vous demandiez à une classe pleine de futurs ingénieurs logiciels de faire cela, ils pourraient prendre le temps de configurer un environnement Python, de mettre en place leur propre data pipeline et une logique d’analyse, pour pouvoir travailler sur un ensemble de données en utilisant des technologies open-source. Le problème est que, compte tenu du délai dont nous disposons pour des étudiants qui ne sont pas ingénieurs logiciels mais bien ingénieurs en supply chain ou futurs ingénieurs en supply chain, nous avons besoin d’un environnement prêt pour un atelier qui porte principalement sur la supply chain, et non sur les subtilités de l’analyse d’un fichier CSV en Python. Ce genre de préparation doit être effectué à l’avance, et c’est ce que nous pouvons faire avec cet environnement. Nous partageons un environnement où les données ont déjà été préparées, le script qui lit les données est déjà écrit, de sorte qu’ils peuvent directement se lancer dans l’essentiel du problème, qui est de déterminer quoi faire avec une supply chain, avec un fournisseur, avec la demande, et d’appliquer un raisonnement supply chain à l’aide d’un outil programmatique. Notre ambition est de permettre à ces curriculums, qui sont généralement très légers en termes d’outils techniques, de proposer des choses plus avancées sans pour autant être complètement noyés dans des détails purement techniques.
Conor Doherty: Et Paul, juste une question de suivi à ce sujet. Quelles sont la difficulté de ces compétences d’ingénierie, comme le codage, pour un étudiant moyen de niveau fondamental en supply chain ?
Paul Jan: Je peux vous donner un exemple concret du monde réel où nous avons démarré le semestre ici il y a quelques semaines. Je dirais qu’environ 20% de cette nouvelle promotion possède une certaine expérience préalable en codage, mais dans ce cas, ils ont suivi, par exemple, un cours de Python en classe auparavant. La majorité n’en a pas. Ainsi, quand ils arrivent, je pense qu’ils sont enthousiastes car ils réalisent que c’est une compétence qui leur sera bénéfique à l’avenir, puisque beaucoup de choses évoluent, il y a beaucoup plus de données, et Excel devient tout simplement encombrant lorsqu’il s’agit d’analyser une si grande quantité de données. Le codage aide à simplifier ce processus. Mais en même temps, ils sont aussi un peu effrayés, inquiets, car ils n’ont pas l’expérience. C’est une compétence très importante aujourd’hui, mais c’est aussi quelque chose qui manque dans la formation des étudiants en commerce, pas seulement en supply chain, mais en commerce en général.
Conor Doherty: Eh bien, merci. Et cela fait une transition parfaite. Joannes, quelque chose que j’attendais depuis longtemps de te demander. Tu as décrit par le passé dans tes cours que les problèmes en supply chain étaient pervers. Donc, il y a deux volets dans cette question. Premièrement, que veux-tu exactement dire par problèmes pervers en supply chain ? Et deuxièmement, en se basant sur ce que Paul vient de dire, pourquoi des outils comme Excel ne sont-ils pas équipés pour gérer ces problèmes pervers ?
Joannes Vermorel: La notion de problème pervers ne vient pas de moi. Ce sont essentiellement des problèmes qui défient une analyse directe, de premier niveau. C’est quelque chose qui doit être un parcours, quoi qu’il en soit, au cours duquel tu découvriras le problème lui-même.
Un exemple de cela est : qu’est-ce qu’une bonne publicité ? Si je te demande de calculer la surface d’une forme géométrique en pouces carrés ou en centimètres carrés, la forme peut être très compliquée, donc le calcul peut être difficile, mais c’est un problème clos. Il existe une solution analytique qui te donnera soit la réponse exacte, soit une très bonne approximation.
Mais si je te demande ce qu’est une bonne publicité, la réponse dépend vraiment, et cela dépend également de ce que font tes concurrents. Par exemple, si tu crées une publicité fantastique, mais que tes concurrents te copient au point que ta publicité, qui était brillante, devient désormais indiscernable de toute la concurrence, c’était une très bonne publicité mais elle est devenue une mauvaise publicité simplement parce que tout le monde l’a copiée.
Voilà le genre de perversité. La réponse même que tu donnes peut potentiellement annuler sa propre validité. C’est assez étrange. Je donne une très bonne réponse et, parce qu’elle est très bonne, elle est copiée, et du fait qu’elle est copiée, elle devient une mauvaise réponse. Voilà le genre de problème pervers.
La supply chain est pleine de problèmes pervers. Tu décides de placer un centre de distribution quelque part pour surpasser quelqu’un d’autre. Ce quelqu’un d’autre décide alors de répliquer et de réorganiser ses propres centres de distribution pour te surpasser. C’est ce genre de chose.
La situation n’est donc pas stable. Une réponse n’est pas stable. Ces problèmes pervers sont de nature compétitive. Il y a des gens qui réagissent à ce que tu fais. Ce n’est pas comme le problème de calculer la surface d’une forme géométrique, qui est un problème où la réponse ne dépend pas de ce que fait le reste de l’univers, de ce que décident les autres. Ce problème est bien isolé.
Et puis tu as aussi des problèmes où tu n’es même pas sûr de formuler correctement le problème. Que signifie la qualité de service ? Oui, nous pouvons dire que la qualité de service consiste à augmenter le taux de service, mais la réalité est que la qualité de service est dans l’œil du client et que cela signifie quoi réellement ? C’est une question très difficile.
Pour certaines personnes, il se peut qu’elles pensent que, s’il existe des substituts, ce n’est pas grave. Elles ne s’attendent pas à ce que ce produit soit toujours disponible. Peut-être que, s’il y a des substituts, cela convient. D’autres personnes pourraient ne pas être d’accord. Elles pourraient avoir une conception très limitée de ce dont elles ont réellement besoin et dire : « Je veux exactement ce code-barres, sinon ça ne fonctionne pas. »
Et puis, selon le message que l’entreprise véhicule, la communication globale, tu pourrais en fait amplifier ou diminuer la perception que les gens ont de voir d’autres produits comme des substituts ou non. Si ta communication affirme que ce produit est complètement unique, qu’il n’existe aucun substitut, alors ne sois pas surpris que les gens ne soient même pas disposés à considérer d’autres produits de ta gamme comme substituts parce que c’est ce que dit ta communication. Cela peut être efficace contre la concurrence, mais cela peut s’avérer plus difficile si tu veux convaincre les gens d’accepter des alternatives.
Les situations sont incroyablement variées. En somme, concernant ces problèmes pervers — et c’est une manière typique de penser chez Lokad —, c’est que généralement, lorsqu’on fait face à ces problèmes pervers, il vaut mieux itérer sur le problème avec des données plutôt que d’agir sans données.
Peu importe la question posée, par exemple, s’il s’agit d’une bonne publicité, il est plus facile de répondre à cette question si tu peux mesurer les ventes et les corréler un peu à tes dépenses publicitaires, par exemple. Cela ne signifie pas que cela résoudra entièrement la question, mais tu seras mieux informé plutôt que d’essayer d’y répondre sans aucune donnée.
En général, même si tu fais face à un problème pervers, disposer de données est utile. Le problème est que, en raison de la nature perverse, tu dois être capable de réviser ta position sur le type d’analyse et de traitement, ce qui signifie qu’il n’y aura pas de réponse universelle. Tu traiteras les données, puis tu réfléchiras, et ensuite tu poseras peut-être une question légèrement différente en fonction de ce qui se passe.
Ainsi, les problèmes pervers, c’est là que nous intervenons. Lorsque tu es confronté à un problème pervers, disposer de données est avantageux car cela te permet d’être mieux informé, ce qui est généralement préférable. Mais cela signifie aussi que tu devras répéter ton analyse de temps en temps, car il n’y aura pas de réponse définitive.
Excel est bien à cet égard. Excel te permet de réviser ton analyse aussi souvent que tu le souhaites. Le problème est qu’Excel ne se dimensionne pas autant que requièrent modern supply chains. De nos jours, nous parlons de dizaines de milliers de produits, de millions de transactions, d’une multitude de données transactionnelles. Excel n’est tout simplement pas adapté à cela.
La principale difficulté est que les données de la supply chain moderne dépassent ce qui peut raisonnablement tenir dans Excel, et ce dépassement s’exprime de deux manières. Premièrement, le nombre de lignes dépasse. Excel est limité à un million de lignes. Mais cette contrainte n’est pas réellement le gros problème. En théorie, Microsoft pourrait réingénieriser Excel pour le faire tenir jusqu’à 100 millions de lignes. Ce n’est pas impossible, et, en réalité, quelques concurrents d’Excel en sont capables.
Mais quand on dit qu’une supply chain moderne dépasse, c’est que fondamentalement, Excel fonctionne selon une logique d’une table à la fois. Il part du principe que les données se présentent sous forme d’une table plate. Or, en réalité, les données transactionnelles d’une supply chain se répartissent sur plusieurs tables. Tu as une table pour les fournisseurs, une table pour les transactions, une table pour les clients, une table pour les produits, une table pour les couleurs, les formes ou autre.
Tu te retrouves très souvent à gérer au moins une demi-douzaine de tables. Et ce qui te manque, c’est quelque chose comme une algèbre relationnelle, qui est vraiment au cœur de tes données transactionnelles. Tes données en supply chain sont transactionnelles et relationnelles. Tu as une demi-douzaine de tables, et c’est là qu’Excel ne fonctionne vraiment pas.
Non seulement tu as cette contrainte sur le nombre de lignes (qui pourrait être corrigée), mais, plus généralement, tu es limité en termes de sémantique. Excel ne te fournit pas cette capacité multi-tables.
Et d’ailleurs, c’est pour cette raison, bien plus profonde, que Microsoft ne s’est même pas vraiment donné la peine d’élargir cette limite d’un million. Les équipes de Microsoft savent, et le savent depuis longtemps, que même s’ils pouvaient porter la limite à 100 millions de lignes, l’étape suivante serait : « Oh, il nous faut plusieurs tables », et alors Excel ne fonctionnerait plus très bien.
C’est pourquoi la réponse de Microsoft a été : « Si tu veux des données relationnelles, tu as SQL Server, ou tu disposes d’outils qui traitent les données relationnelles comme des citoyens de première classe », plutôt que d’essayer d’intégrer cela dans une feuille de calcul. Et d’ailleurs, c’est aussi ce que nous essayons de faire avec ce playground, à savoir exposer les étudiants à cette réalité des données relationnelles en leur proposant un langage qui traite les données relationnelles comme des citoyens de première classe.
Parce que c’est quelque chose que je crois inévitable. Dans quarante ans, les ERP auront toujours des tables et des colonnes. Ce concept a été établi il y a quatre décennies, et il constitue donc un aspect très stable de la digital supply chain depuis plus de quarante ans déjà.
Conor Doherty: Paul, un point intéressant à approfondir, car tu as une vaste expérience dans le secteur privé et as été formellement formé dans ce domaine. Lorsque tu débutais et développais ton expérience, je présume que tu travaillais avec Excel. Et si c’est le cas, à quel moment as-tu dit : « Il me faut envisager des options plus riches et plus programmatiques » ? Qu’est-ce qui a provoqué la divergence par rapport à Excel ?
Paul Jan: La divergence est ce à quoi Joannes faisait allusion précédemment. Excel est génial, tu sais, c’est une approche d’une table à la fois, et il est très fastidieux de lier toutes ces tables ou onglets dans Excel. Et même si tu y parviens, c’est aussi une tâche extrêmement chronophage si tu dois modifier tes hypothèses, tes variables pour revérifier tous les changements apportés dans Excel.
Tu te retrouves souvent face à des erreurs. Tu fais presque toujours des fautes à la fin parce que tu oublies de modifier telle variable ou telle hypothèse, ce qui fait que le résultat final diffère légèrement. Je pense donc que ce fut peut-être après quelques années que j’ai eu l’occasion d’apprendre SQL. Je ne connaissais pas SQL auparavant, mais je l’ai appris dans le cadre d’un projet, et j’ai vraiment apprécié le langage ainsi que la puissance qu’il procure pour traiter et simplifier, du moins la première étape, qui consiste à extraire les données descriptives et à identifier les anomalies dans les données elles-mêmes.
Cela simplifie au moins la première phase, celle de trouver les données descriptives et d’identifier les anomalies dans les données elles-mêmes. S’assurer que les données sont propres et trouver des moyens d’intégrer différentes sources de données a vraiment nettement simplifié les choses. C’est à ce moment-là que j’ai véritablement opéré une transition. À l’époque, SQL est devenu mon premier choix d’outils analytiques pour traiter, ou plutôt prétraiter, les données afin de comprendre leur structure et de détecter d’éventuelles anomalies. Par la suite, je réalisais la première analyse descriptive à partir de celles-ci, et Excel était utilisé plutôt pour faciliter la visualisation. Une fois cela terminé, nous visualisions plus aisément avec Excel en créant des tableaux et des graphiques, et ainsi de suite.
J’aimerais ajouter ce que Joannes a mentionné au sujet de la découverte de Lokad. J’ai moi aussi découvert Lokad il y a quelques années, mais je n’ai pas pris une initiative similaire à celle que j’ai prise l’année dernière pour l’introduire aux étudiants. J’avais peur, pour être honnête, que l’aspect codage ne dissuade les étudiants d’utiliser l’outil et d’apprécier ou d’apprendre du cours. Mais je dois dire que je me suis trompé. Au cours des derniers mois de nos collaborations, j’ai découvert qu’Envision est un outil très facile à comprendre. Même avec mon expérience en programmation et en bases de données, c’est très simple à appréhender, et je pense que c’est également plus facile pour les étudiants, car les codes se lisent comme dans un langage courant.
C’est différent, par exemple, de Python et d’autres langages où parfois les choses n’ont pas beaucoup de sens et ne s’enchaînent pas sans l’explication de la personne qui a écrit le programme. Jusqu’à présent, cela a été un exercice très utile à introduire. Cela a vraiment simplifié le processus d’ajustement des hypothèses, des éléments que nous n’avions peut-être pas pris en compte dans les données, en permettant de les mettre à jour directement dans le code et de les refléter ensuite dans le dashboard pour que l’étudiant puisse observer le résultat.
Je qualifierais encore cela de niveau introductif. Pour les étudiants, c’est l’occasion de comprendre, de manière globale, ce que fait une entreprise et comment elle s’y prend en se basant sur des données descriptives telles que le nombre de clients qu’elle possède, les ventes les plus élevées, la tendance ABC de leurs produits. À partir de là, ils peuvent comprendre comment ils structurent la supply chain, puis nous approfondissons ensuite leur supply chain. Disposer de ce programme, de cette expérience de codage avec Envision, a vraiment aidé de manière spectaculaire à cet égard et a également réduit les erreurs que nous pouvions commettre sur Excel.
Conor Doherty: Je vais revenir vers toi, Paul, puis vers Joannes. Ainsi, bienvenue, c’est une question de philosophie qui devrait te plaire. Il me vient à l’esprit que nous avons parlé des outils, donc Envision représente l’outil, mais l’utilisation ou le levier de cet outil s’accompagne d’un certain état d’esprit. Comme tu l’as évoqué, l’une des bases de ce que Lokad fait avec Envision est d’adopter une perspective purement financière des problèmes de supply chain et de réduire les erreurs en dollars ou en euros. C’est un mélange, j’imagine, d’économie mais c’est aussi un peu philosophique, comprendre très précisément que si je fais ceci, je ne peux pas faire cela, le coût d’opportunité.
En ce qui concerne l’état d’esprit, comprendre comment utiliser ces outils, est-ce quelque chose que tu dois également enseigner en classe ou les étudiants comprennent-ils automatiquement, « Oh oui, le coût d’opportunité, j’utiliserai simplement cet outil et c’est immédiatement évident pour eux » ?
Paul Jan: Je ne dirais pas que c’est immédiatement évident, mais les étudiants ont été formés en économie, ils comprennent donc ce qu’est le compromis, le coût d’opportunité. Même dans le cours fondamental de supply chain ou d’opérations que j’enseigne ici, nous présentons aux étudiants le coût excédentaire, le coût de reprise, les différents coûts associés à la décision que tu prends, notamment combien stocker en termes de stocks et quand le faire. Ces notions sont compréhensibles et proches des étudiants une fois que tu leur expliques que la manière dont nous établissons cette rentabilité financière est basée sur l’ABC.
En pratique, ces résultats financiers sont également ce que nous essayons de quantifier pour les dirigeants dans tout type de projets de conseil. Les dirigeants comprennent que lorsque vous leur indiquez que tel est votre coût en dollars ou votre opportunité en dollars. Mais pour les personnes de la supply chain, je dirais, ou pour les personnes des opérations, elles sont principalement conduites par les indicateurs traditionnels, les rotations, forecast accuracy. Elles comprennent, mais y prêtent davantage attention. Il existe donc un léger fossé entre ce que comprennent les dirigeants et ce que les opérationnels, ou du moins ceux à qui l’on a enseigné ou ordonné de suivre, saisissent. Du point de vue d’un étudiant, introduire ou expliquer ces concepts n’est pas une tâche difficile.
Conor Doherty : Merci, Paul. Et Joannes, à toi. Donc, en nous appuyant à nouveau sur ce qui vient d’être dit, je comprends parfaitement pourquoi des outils comme Python, SQL, et évidemment Envision, notre langage spécifique au domaine, peuvent sembler inédits aux nouveaux praticiens de la supply chain. Mais le concept de ressources rares et d’usages alternatifs, socle de l’économie, a plus d’un siècle d’existence. Alors, pourquoi cet aspect de la mentalité économique serait-il si différent dans les cercles de la supply chain par rapport à, comme Paul vient de le décrire, le fait qu’il soit intuitivement compris en classe ?
Joannes Vermorel : J’aimerais d’abord rebondir sur la remarque de Paul. Lorsque tu disais être inquiet à l’idée d’utiliser Envision, je pense que tu avais raison. Pour le public, ma conviction personnelle est que la grande majorité des enterprise software est de la pure merde, littéralement de la pure merde. Et en matière d’achat de logiciels, je te regarde, toi. Il est donc tout à fait raisonnable, par défaut, de présumer que ce sera de la pure merde et d’être agréablement surpris si ce n’en est pas le cas. Mais je trouve que c’est une hypothèse raisonnable. Je suis fermement convaincu qu’Envision ne fait pas partie de ce lot, nous avons fait du bon travail. Mais encore une fois, il faut par défaut s’attendre à ce que les enterprise software soient de très mauvaise qualité, surtout par rapport aux projets open source populaires. C’est une hypothèse juste et très rationnelle concernant le paysage applicatif.
Maintenant, le hic avec ce genre d’état d’esprit financier, et lorsque Paul a mentionné l’ABC dans le sens du coût basé sur les activités, d’ailleurs, et non ABC analysis bien sûr. Le fait est qu’il est très difficile de penser aux problèmes si l’on ne peut pas imaginer la solution. Dès lors, quand on dit que les gens souhaitent réfléchir en termes de précision ou de taux de service, il s’agit d’indicateurs très classiques. Le problème, c’est que si tout ce dont vous disposez est une feuille de calcul Excel, c’est à peu près tout ce que vous pouvez implémenter. Par conséquent, si vous ne pouvez penser qu’en termes de feuilles de calcul, vous aurez du mal à envisager ces aspects, puisqu’ils nécessitent de penser aux problèmes. Comment vais-je transformer tout cela en dollars alors que vous avez tant de difficulté à concevoir la solution ?
Les gens pensent souvent à la solution avant de concevoir le problème. Il est très difficile d’énoncer un problème sans imaginer d’abord une solution. Vous tomberez d’abord sur une solution approximative, puis, lorsque vous voudrez expliquer ce que vous avez réalisé à quelqu’un, vous finirez par inventer le problème correspondant à la solution. Les gens imaginent instinctivement la solution en premier et, ensuite, pour pouvoir en parler, ils inventent le problème.
Votre capacité à concevoir des solutions dépend des outils dont vous disposez mentalement. Si vous n’avez en tête qu’Excel, alors toutes les solutions auxquelles vous pouvez penser seront celles qui peuvent fonctionner dans Excel. Cela vous limite au paradigme de la précision et du taux de service, car ce sont précisément ce genre de choses que vous pouvez réaliser dans Excel.
C’est pourquoi il est très important, dans les cours fondamentaux, de familiariser les étudiants avec de meilleurs outils qui leur permettent de penser, par exemple, en termes de tableaux, de colonnes et de concepts tels que SQL. Le problème n’est pas SQL en soi, c’est le paradigme que vous offre SQL – tableaux, filtres, agrégations, colonnes, types de valeurs comme les chaînes de caractères par opposition aux nombres, aux booléens. Ces éléments sont très importants et, soudainement, lorsque vous disposez de ces paradigmes, vous pouvez envisager des classes de solutions plus élaborées.
Pour penser aux indicateurs financiers, vous devez relier le coût de stockage, ce qui vous oblige à disposer d’un autre tableau fournissant certaines hypothèses sur ce coût. Vous devez aussi connaître le coût de la rupture de stock, ainsi cette information doit figurer ailleurs. Ce n’est pas que les gens soient traditionnellement incapables de penser au coût de stockage ou au coût de l’assurance, ils le savent. Mais lorsqu’il s’agit d’imaginer une solution, si Excel est tout ce à quoi ils peuvent songer, il leur est très difficile de concevoir une feuille de calcul capable d’intégrer ces vingt éléments différents.
Mais si vous pouvez penser en données relationnelles, alors, soudainement, vous disposez des outils qui vous permettent de penser : “D’accord, je vais brancher tous ces coûts avec autant de tableaux que nécessaire.” Et, conceptuellement, si ces coûts sont individuellement simples, il s’agit simplement de tout agréger.
C’est une longue explication, mais c’est également la raison pour laquelle la gestion de la supply chain traditionnelle est très hésitante. Ils n’ont pas eu l’opportunité de bénéficier de ce type d’éducation qui leur permet de véritablement réfléchir avec des outils plus modernes.
Paul Jan : Je suis tout à fait d’accord avec l’évaluation de Joannes. Si nous devions réaliser une évaluation des compétences dans les opérations supply chain de n’importe quelle entreprise, je pense que vous constateriez un grand fossé dans leur compréhension de ce dont nous venons de parler. C’est vraiment le défi pour éduquer cette nouvelle génération de jeunes professionnels à adopter une mentalité différente et à innover.
Joannes Vermorel : J’enseigne depuis sept ans, non pas la supply chain, mais l’informatique distribuée et le génie logiciel. Ma philosophie, lorsque j’enseignais à l’École Normale Supérieure de Paris, où je bénéficiais d’une totale liberté quant au contenu, était de me concentrer sur des sujets qui seraient encore pertinents dans quarante ans.
Ma plus grande crainte était d’enseigner quelque chose qui ne serait qu’une mode passagère, quelque chose qui, cinq ans plus tard, se révélerait n’être qu’une subtilité désormais obsolète. Ainsi, mon approche consistait toujours à me demander : est-ce quelque chose qui résistera à l’épreuve du temps ? Quarante ans plus tard, cela aura-t-il encore une grande importance ?
Par exemple, SQL est établi comme standard depuis 1989. Il a évolué, mais l’essentiel n’a pas changé depuis. Le modèle sous-jacent, les données relationnelles, n’ont pas évolué depuis la fin des années 70. Il s’est avéré incroyablement performant, avec pratiquement 99 % du marché des ERP qui utilisent ce format de données relationnelles d’une manière ou d’une autre.
Les gens ont l’impression que les technologies numériques sont en perpétuel changement, qu’il faut apprendre quelque chose et qu’en deux ans, cela disparaîtra. Je crois que c’est un problème, car cela donne l’impression que ce savoir est jetable. Cela donne également à la direction l’illusion qu’elle peut passer outre et qu’elle s’en moque, puisque dans deux ans, ce sera autre chose.
Si c’est bien fait, nous avons de nombreux sujets extrêmement fondamentaux. La structure des données relationnelles en est un exemple. Les types de données de base – texte, booléens, nombres – étaient déjà ainsi à la fin des années 70. Même Python 3, la dernière version, conserve cela au cœur de son fonctionnement. C’est quelque chose qui est très peu susceptible de changer au cours des quarante prochaines années.
De même, si nous pensons à la prévision, l’idée de concevoir l’avenir, les séries temporelles, quelles sont les limitations des séries temporelles, ce qu’une prévision des séries temporelles nous apporte, ce qu’elle ne nous apporte pas, ce que cette approche ne peut fournir par conception, cela ne changera pas. Le type de prévision le plus basique dans quarante ans restera une prévision des séries temporelles par jour, par semaine, par mois, et sa limitation restera la même.
Si je devais enseigner la prévision, plutôt que de me concentrer sur quel est le meilleur modèle de prévision des séries temporelles – modèle qui évoluera –, je me concentrerais sur les hypothèses intrinsèques à la prévision des séries temporelles, sur ce qu’elle vous apporte et ce qu’elle ne vous apporte pas, ainsi que sur ses limitations dangereuses et la manière de penser l’incertitude.
Je comprends que c’est un très grand défi. La plupart des professeurs d’université n’ont pas eu le luxe que j’ai eu, où l’administration se fichait éperdument de ce que j’enseignais réellement.
Conor Doherty : Paul, lorsque tu abordes la prévision de la demande en cours, évoques-tu les distributions de probabilité pour appréhender l’incertitude de l’avenir ?
Paul Jan : Dans le cours fondamental, nous en parlons, ainsi que dans la gestion de la demande, la prévision et la gestion du stock. Mais nous partons du principe que les variabilités et les incertitudes suivent la distribution normale, ce qui facilite grandement l’enseignement.
Cependant, en appliquant l’approche probabiliste, qui examine la probabilité des variations d’un produit, vous pouvez visualiser cela graphiquement. Les gens étant visuels, ils peuvent ainsi comprendre pourquoi un produit se comporte différemment d’un autre.
Ce semestre, j’envisage d’intégrer certains contenus du cours avancé dans le cours fondamental afin d’expliquer les incertitudes et les variations de manière plus visuelle.
Joannes Vermorel : Faire des hypothèses fortes à des fins pédagogiques, c’est acceptable. Je me souviens qu’à l’université, un de mes professeurs de physique simplifiait les calculs en supposant qu’une vache était une sphère. Évidemment, une vache n’est pas une sphère, mais pour l’exercice, il était raisonnable de permettre aux étudiants d’effectuer un calcul simplifié. Cela les aide à expérimenter les concepts sans se noyer dans les calculs.
Cependant, dans le monde de la supply chain, les gens font des hypothèses équivalentes, comme supposer que la demande suit une distribution normale. Il s’agit d’une hypothèse pédagogique qui ne tient pas dans le monde réel. Pourtant, les fournisseurs d’[enterprise software] restent attachés à ces hypothèses en les codant en dur dans leurs logiciels. C’est de la folie. C’est comme si General Motors codait en dur des hypothèses sur des sphères et des passagers dans leurs voitures. Les gens trouveraient cela insensé. On ne devrait pas faire cela pour une vraie voiture qui va circuler dans le monde réel.
Pourtant, bizarrement, les fournisseurs de logiciels supply chain affirment qu’il n’y a aucun problème à intégrer ces hypothèses en dur dans leurs logiciels. Voilà ma réaction face au statu quo dans cette industrie, que je trouve un peu insensé. Il y a un besoin de disruption. Pour des raisons étranges, il semble que les fournisseurs de logiciels supply chain traduisent directement dans leurs produits ces hypothèses farfelues introduites à des fins pédagogiques.
Mais peut-être n’est-il pas juste d’exiger cela des professeurs. Peut-être que ce sont les fournisseurs d’[enterprise software] de la supply chain eux-mêmes qui doivent se confronter à la réalité.
Conor Doherty : C’est justement ce que j’allais demander. Du point de vue de Paul, à la Rotman School of Management, il est de sa responsabilité d’enseigner ces concepts. Mais pour Lokad, fournisseur de software supply chain, pourquoi l’éducation est-elle une chose si importante ? Pourquoi y accorder autant d’attention ?
Joannes Vermorel : La supply chain est un ensemble de problèmes épineux du fait que nous rassemblons toutes les forces des entreprises. Par définition, la supply chain unit l’entreprise, ce qui signifie que nous réunissons les ventes, la production, le transport, le marketing, la finance, tout. Ce n’est pas une proposition simple. Les entreprises modernes opèrent dans de nombreux pays, ainsi non seulement il y a les ventes contre le marketing, mais il peut également y avoir la France contre l’Italie contre l’Espagne.
La supply chain est, par nature ou par conception, une série de problèmes épineux qui connectent de nombreux intérêts conflictuels tant à l’intérieur qu’à l’extérieur de l’entreprise. Nous devons penser en termes de paradigmes et d’outils qui nous permettent d’aborder ces problèmes épineux, même de manière approximative. Au lieu d’opter pour l’approximativement correct, les gens se tournent vers ce qui est exactement faux et redoublent d’efforts avec une multitude de recettes numériques bien plus précises qu’elles ne devraient l’être.
Conor Doherty : Nous arrivons à la fin, mais je tiens à te redonner la parole. La conception de la supply chain par Joannes me semble profondément philosophique. Quand nous parlons de problèmes du premier et du second ordre, c’est presque à la manière de Wittgenstein. Je suis curieux : adoptes-tu une approche tout aussi profondément philosophique de la supply chain ? L’administration te le permet-elle ? Dès le premier jour, devons-nous repenser entièrement l’univers des philosophies supply chain ? Est-ce le genre de choses que tu dis aux étudiants, que nous devons repenser complètement la roue, ou est-ce plus progressif ?
Paul Jan : C’est à la fois progressif et disruptif. À l’université, lorsqu’un étudiant apprend, il débute par les bases, puis suit un cours intermédiaire de gestion des opérations supply chain, et enfin il assiste à un cours plus avancé que j’enseigne ce semestre en collaboration avec Lokad. Ils apprennent progressivement les théories et applications traditionnelles. Mais la disruption survient lorsque, dans ce cours, du moins d’après mon expérience, je ne sais comment enseigner aux étudiants l’aspect épineux de la supply chain sans qu’ils ne le vivent eux-mêmes. C’est pourquoi nous collaborons avec une entreprise. Nous manipulons de vraies données et réfléchissons à l’aide d’un outil. Ils constatent l’aspect épineux, l’incertitude, et réalisent que ce qu’ils ont appris lors des un ou deux cours précédents ne peut pas être appliqué immédiatement. Vous pouvez y parvenir, mais cela peut ne pas avoir de sens.
Donc, c’est une question philosophique. Et, d’ailleurs, c’est un problème ouvert. Si vous consultez la page Wikipédia sur les problèmes épineux, toutes les disciplines confrontées à ce type de problème – où une bonne ou une mauvaise réponse à une problématique dépend de ce que font les autres – sont incroyablement difficiles à enseigner. Ce n’est pas spécifique à la supply chain, il existe d’autres domaines où c’est tout simplement extrêmement difficile.
Joannes Vermorel : Il existe même des domaines où, par exemple, nous avons récemment reçu un invité parlant de trading sur les marchés publics, où le simple fait de révéler comment vous procédez compromettrait votre propre solution et votre propre source de revenus. Ainsi, le secret est primordial dans ce genre de choses. Si vous comprenez quelque chose, vous ne devriez pas en parler professionnellement, car si vous le faites, les gens s’en serviront contre vous.
Mais selon moi, Lokad continuera d’essayer. Nous continuerons à soutenir les bonnes universités qui, comme l’Université de Toronto, tentent d’aller dans cette direction. Nous n’attendons aucune solution, mais tout pas dans cette direction est déjà mieux que de faire comme si cela n’existait pas.
Conor Doherty: Exactement, approximativement correct. Eh bien, Paul, il est d’usage ici de laisser le dernier mot à l’invité. Y a-t-il quelque chose que tu aimerais dire aux gens ou conseiller à tes étudiants concernant les examens finaux?
Paul Jan: Pas encore de conseils pour les examens finaux, mais j’aimerais revenir sur le commentaire de Joannes concernant les raisons pour lesquelles les secteurs privés investissent dans l’éducation. Vous investissez dans les conférences, les articles, et les blogs, et j’apprécie cela. Beaucoup de ces étudiants, après avoir obtenu leur diplôme, se tournent vers des vendeurs, des fournisseurs et des sites web pour trouver des informations, ou pour comprendre ce qu’est la gestion de la supply chain, ou pour rafraîchir leur mémoire.
Par exemple, les statistiques sont une matière très redoutée par les étudiants. Ainsi, ne pas supposer que tout est normal rend les choses beaucoup plus simples car cela dissipe cette peur. Mais si vous disposez de véritables arguments pour étayer différents comportements, alors ils pourraient être plus enclins à apprendre afin de surmonter cette peur. Après l’université, vos informations leur deviennent plus accessibles, devenant ainsi un renforcement pour nous aider à sortir de cet état d’esprit où nous appliquons la même solution à tous les différents problèmes épineux.
Conor Doherty: Parfait. Sur ce, je n’ai en fait plus de questions. Joannes, merci pour votre temps.
Joannes Vermorel: Merci beaucoup pour le vôtre et pour votre collaboration continue.
Conor Doherty: Et merci à tous de nous avoir regardés. On se retrouve la prochaine fois.
