Achats aerospatiaux optimises : demo guidee des solutions de Lokad

Back to Lokad TV

00:00:00 Achats aerospatiaux : incertitude et priorites economiques
00:05:58 Visibilite de la flotte, objectifs de taux de service et couts d’investissement
00:11:47 Rotables, consommables et investissements classes economiquement
00:17:23 Priorites sous contraintes budgetaires et operationnelles
00:23:56 Classer les investissements par gains de taux de service par dollar
00:29:43 Valider les donnees et modeliser une demande incertaine
00:35:48 Combiner l’incertitude de la demande et des temps de rotation
00:41:42 Integration systeme et opportunites de cession
00:47:15 Echanges, priorites de reparation et integration fournisseurs
00:53:29 Preparation des donnees et exigences de mise en oeuvre
00:58:44 Simulations historiques et tracabilite des decisions
01:04:10 Priorites economiques, consommables et retards fournisseurs
01:09:14 Prevision de maintenance et suivi de l’adhesion aux recommandations
01:14:05 Automatisation des achats, plateformes d’approvisionnement et priorites de reparation
01:19:52 Enseignements principaux et conclusion

Resume

Conor Doherty et Fabian Hoehner montrent comment Lokad transforme une demande incertaine, des temps de reparation variables et des budgets limites en decisions d’achat aerospatiales classees. L’approche evalue chaque unite supplementaire selon sa contribution attendue au taux de service, ou a l’evitement d’un aircraft-on-ground, par rapport a son cout. Le meme raisonnement soutient les cessions, la priorisation des reparations et les transferts de stock. Lokad fonctionne aux cotes des systemes existants, avec des supply chain scientists et des experts operationnels qui affinent les calculs. Les simulations historiques aident a expliquer les decisions passees, tandis que l’automatisation depend de la valeur et de la complexite des achats concernes.

Resume etendu

Les achats aerospatiaux consistent a arbitrer entre des usages concurrents de ressources rares. Acheter une piece de rechange supplementaire peut reduire le risque d’immobiliser un appareil, mais immobilise aussi des capitaux qui pourraient proteger une autre operation plus importante. Dans cette demonstration en direct, Conor Doherty et Fabian Hoehner expliquent comment Lokad evalue ces choix. La question centrale est de savoir combien de taux de service additionnel, ou d’evitement d’AOG, chaque dollar peut raisonnablement acheter. Les quantites en stock decoulent de cette comparaison, ainsi que des contraintes dans lesquelles l’entreprise opere.

La demonstration commence avec une flotte aerienne illustrative et un pool de rotables : des pieces qui peuvent etre reparees puis remises en service. Leur disponibilite depend a la fois de la demande et du temps passe dans les processus de reparation et de logistique. Posseder cinq unites n’offre pas la meme protection que disposer immediatement de cinq unites utilisables. Lokad extrait les donnees transactionnelles des systemes existants pour etablir cette image operationnelle, puis calcule des recommandations d’investissement. Dans l’exemple, environ 68 millions de dollars de stock procurent un taux de service attendu de 95,7 % ; un investissement supplementaire d’environ 1,2 million de dollars le rapproche de 98 %. Les gains ulterieurs deviennent de plus en plus couteux.

Les recommandations sont classees unite par unite. Une unite supplementaire d’un PN donne entre en concurrence avec des unites supplementaires d’autres PNs, y compris des pieces aux prix et profils de demande tres differents. La premiere unite couvre generalement plus d’incertitude que la deuxieme ou la troisieme. Ce rendement decroissant compte : acheter plusieurs unites d’une meme piece peut avoir moins de valeur que repartir l’investissement. Le caractere essentiel compte aussi. Une piece no-go relativement peu couteuse peut justifier une disponibilite plus elevee qu’une piece chere dont l’absence a des consequences moins graves. Une liste classee facilite aussi l’application des limites de budget, de capacite d’achat et de reception.

Ces comparaisons exigent un traitement realiste de l’incertitude. La demande aerospatiale est souvent rare et irreguliere, tandis que les temps de rotation peuvent varier fortement. Les moyennes masquent precisement les situations exceptionnelles contre lesquelles une compagnie aerienne veut se proteger. Lokad modelise donc des distributions de demande et de delais de reapprovisionnement, puis les combine pour estimer la demande sur differents horizons futurs possibles. Hoehner illustre comment les reparations peuvent se concentrer autour d’une duree courte lorsque tout se passe bien, et d’une duree beaucoup plus longue lorsque des complications surviennent. Remplacer ce schema par une moyenne unique peut fausser le stock requis. Les evenements de maintenance connus, les nomenclatures probabilistes et les tendances de temps de rotation peuvent egalement alimenter les calculs.

Les estimations financieres rendent les arbitrages discutables. Le cout d’un evenement AOG peut etre difficile a etablir, mais une estimation approximative donne aux equipes une base pour comparer les decisions et reviser les hypotheses. La connaissance operationnelle reste essentielle : une housse de siege ou une machine a cafe peut avoir des consequences que les classifications techniques de navigabilite ne capturent pas seules. Les utilisateurs examinent les recommandations au moyen d’inspecteurs d’articles et de tableaux de bord, contestent les resultats surprenants et aident a affiner le modele. Les achats couteux de rotables exigent generalement encore une validation experte et des devis fournisseurs ; les consommables et expendables de moindre valeur offrent davantage de possibilites d’execution automatique.

Le meme raisonnement s’etend aux cessions, aux reparations et a l’allocation. La cession compare la tresorerie liberee a la protection du taux de service abandonnee. La priorisation des reparations identifie quelles unites non utilisables justifient le plus urgemment une depense ou une expedition. Les transferts comparent les couts de transport et le risque accru au site fournisseur avec les benefices ailleurs et l’alternative consistant a acheter davantage de stock. Ce sont des decisions economiques liees, meme si chacune requiert ses propres details operationnels. Une opportunite theorique de cession depend par exemple encore de la possibilite de trouver un acheteur et d’etablir une valeur de marche realiste.

Lokad fonctionne comme un systeme d’intelligence aux cotes des logiciels transactionnels. Ses supply chain scientists adaptent la solution aux donnees et aux processus du client ; les fournisseurs n’ont pas besoin d’adopter une nouvelle plateforme. Les decisions utiles aident aussi a reveler quels defauts de donnees meritent l’attention, au lieu de chercher indefiniment a tout nettoyer d’abord. Hoehner decrit environ six mois comme duree typique de mise en oeuvre, avec une forte variabilite. Les executions historiques restent disponibles pour analyse, ce qui permet aux equipes de distinguer une contrainte budgetaire d’une mauvaise hypothese ou d’un risque accepte. La discipline generale est continue : quantifier l’incertitude, comparer les consequences et ameliorer les decisions a mesure que les preuves s’accumulent.

Transcription complete

Conor Doherty : Bienvenue dans la toute premiere demo live de Lokad. Aujourd’hui, nous allons vous montrer comment Lokad genere des decisions d’investissement et de cession dans l’aerospatiale. Nous allons vous montrer quels PNs doivent etre prioritaires.

Aujourd’hui, nous allons vous montrer comment diviser un budget limite, et comment vos contraintes, qu’il s’agisse des delais fournisseurs, des temps de rotation, des couts ou du budget lui-meme, influencent les decisions que nous generons pour vous. C’est un evenement en direct, donc n’hesitez pas a poser vos questions. Nous y repondrons probablement dans environ 30 minutes. Cela dependra de la duree de nos apartes.

Mais qui sommes-nous ? Je suis Conor, directeur marketing chez Lokad. Et je suis accompagne en studio par mon tres bon ami et directeur des comptes strategiques, Fabian Hoehner. Guten Tag, Herr Hoehner, wie geht’s ?

Fabian Hoehner : Bonjour, Conor.

Conor Doherty : Das ist wunderbar. Donc, Fabi, comme les gens peuvent le voir dans le coin de l’ecran, ou devraient deja pouvoir le voir, nous allons bientot regarder un compte de demo d’achat aerospatial. Nous allons nous concentrer sur les achats, mais certaines personnes presentes, et d’autres qui regarderont plus tard, ne connaissent pas forcement tres bien Lokad. Certaines oui, mais beaucoup non.

Prenons donc une minute avant d’entrer dans le sujet. Peux-tu repondre a deux questions rapides ? Premierement, comment Lokad voit-il exactement le probleme des achats dans l’aerospatiale ? Deuxiemement, si les gens ne regardent que les premieres minutes, quels sont les deux ou trois concepts essentiels qu’ils doivent retenir ?

Fabian Hoehner : Tu ne m’avais pas pose cette question pendant la preparation, donc c’est…

Conor Doherty : Non, je ne l’avais pas fait. Je voulais de l’improvisation.

Fabian Hoehner : Oui. D’accord. Il y aura un melange de personnes familieres et non familieres avec le sujet. Nous allons donc essayer de rester a un niveau eleve, tout en allant un peu en profondeur sur certains points. Les deux choses que j’aimerais que les gens retiennent sont, d’une part, la facon dont nous traitons l’incertitude.

Par incertitude, dans les sujets dont nous parlons, j’entends principalement l’incertitude cote fournisseurs, donc les temps de rotation, les delais, et d’autre part l’incertitude de la demande. Le deuxieme aspect est l’optimisation economique, la priorisation economique. Avec une ressource disponible limitee, comment faire au mieux, en quelque sorte ? Comment acheter efficacement dans ce cas ? Ce sont les deux grands points que j’aimerais que les gens retiennent aujourd’hui.

Conor Doherty : Donc, en une phrase, pour chaque euro, dollar, ou toute autre devise dans laquelle vous travaillez, pour chaque euro investi dans votre stock, quel est essentiellement le gain attendu de taux de service ?

Fabian Hoehner : Oui. Pour etre plus precis, ce que vous voulez faire, et nous allons entrer dans les details, c’est maximiser le gain de taux de service par dollar, ou reduire l’AOG, donc aircraft on ground, par dollar depense. C’est le chemin le plus efficace vers votre objectif, et nous esperons que ce sera l’un des messages principaux pour les personnes qui nous ecoutent aujourd’hui.

Conor Doherty : Tres bien. Maintenant que nous avons pose le decor, ne tardons pas davantage. Passons directement au compte de demo.

Max, notre producteur, tu peux basculer quand tu veux, assure-toi juste que tout va bien. Subcto. Tres bien. Fabi, je regarde mon propre ecran parce que ma vue est terrible, mais qu’est-ce que nous regardons exactement ?

Explique-le aux gens pour qu’ils comprennent : quel est le contexte ici ? Est-ce de l’aviation ? Du MRO ? Est-ce de l’IA ? Est-ce qu’on fait de l’IA ?

Fabian Hoehner : Oui, nous faisons toujours de l’IA, bien sur. Nous entrerons dans les details de ce que nous faisons en matiere d’IA, mais nous sommes bien sur un compte de demo. Lokad en 20 secondes : nous concevons des solutions personnalisees d’optimisation des stocks pour nos clients dans differents domaines, et aujourd’hui nous allons nous concentrer sur l’aeronautique. Cela pourrait etre du MRO, donc maintenance, repair and overhaul, mais nous allons nous concentrer sur un exemple venant essentiellement d’une compagnie aerienne.

La grande question que nous allons nous poser est donc la suivante : pour une flotte donnee, comment obtenir le chemin d’investissement, et potentiellement de cession, le plus efficace pour mon stock ? C’est la question generale. Tres rapidement, voyons ou nous sommes ici. Vous voyez que nous sommes sur go.lokad.com.

Ceci est un compte de demo. Tous nos clients sont sur la meme plateforme. C’est donc une application multi-tenant, mais nous ecrivons une solution individuelle pour chaque client. C’est ce qui rend les demos difficiles d’une certaine facon, parce que chaque client est tres different.

Conor Doherty : Different. Oui, bien sur.

Fabian Hoehner : C’est donc, je dirais, notre USP : personnaliser ce que nous faisons. L’objectif aujourd’hui est de montrer les deux principes auxquels j’ai fait allusion au debut. D’une part, comment nous voyons l’incertitude.

Le mot-cle sera la prevision probabiliste. Les personnes qui nous suivent un peu l’ont deja entendu de nombreuses fois, mais aujourd’hui nous allons etre tres pratiques. Et ensuite, deuxieme point : l’optimisation economique sur un exemple specifique. S’il y a des questions, bien sur, posez-les en cours de route.

Souvent, ma reponse sera : “oui, si c’est logique, nous pouvons le construire, ou nous l’avons deja construit par le passe”, mais aujourd’hui nous regardons seulement un exemple specifique. Voila ce que je propose d’examiner. D’autres questions ? Sinon, on se lance.

Conor Doherty : Je dirais : lancons-nous, parce qu’il y a deja beaucoup de questions. Comme les gens le savent, j’ai deja echange avec beaucoup de personnes avant cet evenement. Il y a donc des questions tres concretes auxquelles nous reviendrons plus tard, mais comme je l’ai dit, si quelque chose interpelle quelqu’un qui regarde, n’hesitez pas a commenter, et nous developperons cela en temps voulu.

Fabian Hoehner : Oui. Et tu me connais, donc interromps-moi. Sinon, je…

Conor Doherty : Je le ferai, ne t’inquiete pas.

Fabian Hoehner : Je peux me laisser emporter. Tres bien. Encore une fois, c’est un compte de demo, et ce que nous voyons ici est simplement une vue d’ensemble. Je pourrais cliquer sur ce que je veux, mais aujourd’hui nous allons plonger seulement dans deux ou trois ecrans.

Dans ce cas, nous regardons un tableau de bord de synthese. Nous allons fonctionner en pyramide inversee. Nous allons commencer par la vue d’ensemble, puis descendre jusqu’au niveau le plus fin. Ici, ce serait une vue de management ou l’on peut voir la performance du pool.

Dans ce cas, vous voyez que c’est un pool. Il pourrait venir de plusieurs compagnies aeriennes. L’essentiel est que nous regardons une flotte, en l’occurrence des Triple 7. Que cela vienne d’une ou de plusieurs compagnies aeriennes importe peu ; ce qui compte, ce sont les pieces dont j’ai besoin pour servir cette flotte.

C’est donc le concept general ici. Dans ce cas, vous pouvez voir un affichage historique de consommation, et bien sur il monte parce que Lokad optimise, donc les choses s’ameliorent toujours. Et il y a quelques vues supplementaires sur la situation operationnelle actuelle. Ou se trouve mon stock ?

En aeronautique, nous parlons toujours de boucles. C’est un concept tres important. Evidemment, la plupart des gens qui regardent aujourd’hui connaissent bien cela. Mais le stock n’est pas simplement du stock en aeronautique.

Il s’agit d’avoir du stock serviceable et du stock unserviceable, et de savoir ou il se trouve dans le processus. Avoir cinq unites, avoir cinq unites serviceable, avoir quatre unites dans un cycle de reparation, une unite serviceable : ce sont des interpretations tres differentes de votre realite. Donc ceci est simplement un tableau de bord de synthese. Comment en sommes-nous arrives la ? Par integration…

Conor Doherty : J’allais litteralement te poser exactement cette question, j’etais en train d’ouvrir la bouche pour le faire.

Fabian Hoehner : Oui. Donc, typiquement, dans ce cas, d’ou viennent les donnees ? De differents systemes ERP, systemes MRP, mais au fond ce sont des donnees transactionnelles que nous importons sur la plateforme, Lokad etant une plateforme d’intelligence. Le systeme transactionnel, ERP, MRP, indique simplement “ou sont mes affaires”, le niveau transactionnel. Nous prenons cela quotidiennement, puis nous faisons, disons, la manipulation big data pour obtenir l’information : “j’ai 186 unites qui sont actuellement dans un processus de retour”. Bien, ou est-ce que tu…

Conor Doherty : Non, c’etait tres clair.

Fabian Hoehner : Parfait. Donc, vue d’ensemble de haut niveau, puis nous allons directement plonger dans le resultat. Nous allons commencer par ce a quoi peut ressembler le resultat d’une optimisation, et dans ce cas, ce que nous regardons ici est l’optimisation de l’investissement.

Nous regardons donc un investissement que nous voulons obtenir pour, dans ce cas, un taux de service cible de 98 %. On voit ici un petit simulateur avec un menu deroulant, qui me permet de simuler differents scenarios deja pre-calcules, ici pour aller vite. Nous pourrions aussi le concevoir autrement, avec un petit champ a remplir pour tester soi-meme, mais dans ce cas nous avons pre-calcule pour accelerer la demo. Et ce que nous voyons ici, pour une situation donnee, c’est notre stock actuel, dans ce cas 68 millions, et ces 68 millions sont censes me donner un taux de service de 95,7 %.

Conor Doherty : Mhm.

Fabian Hoehner : 95,7 % de disponibilite par rapport aux delais individuels de toutes les differentes pieces, et pondere par leur consommation.

Conor Doherty : D’accord.

Fabian Hoehner : Ensuite, dans ce cas, selectionnons 98 ici. Nous selectionnons : “d’accord, nous voulons une disponibilite moyenne de 98 %, ponderee par la consommation, etc.” Et dans ce cas, le simulateur me dit : “d’accord, je dois investir 1,2 million”, et je vais atteindre ma cible, ici 97,99. C’est ce que j’aurais obtenu.

C’est donc le niveau le plus eleve. Je pourrais jouer avec cela, et si nous le faisions, nous verrions quelque chose de tres typique en aeronautique, que la majorite de l’audience connait certainement tres bien : la longue traine est la ou se trouvent les couts. Donc, si nous regardons, je suis passe de 98 ou 98,5 a 99,5.

Essayons d’aller a 99. Nous avons donc 1 %. Ce que l’on voit, c’est que le premier point de pourcentage que nous voulions gagner, ou les deux premiers points, nous coute un million de dollars d’investissement, puis le suivant va couter 2,5. Cette augmentation exponentielle pour gagner ces points de taux de service est extremement importante quand nous parlons, au debut, de la technologie.

Pourquoi est-ce important ? Que faisons-nous differemment ? Le bon ajustement de Lokad dans cette industrie, c’est la comprehension de la maniere de traiter une demande clairsemee et erratique, qui constitue la majorite des problemes aeronautiques. Cela signifie : comment mieux comprendre la probabilite des extremes, donc ces percentiles au-dela de 90 %, parce que c’est essentiellement la ou se joue l’aeronautique. L’aeronautique est un secteur extremement averse au risque ; etre en rupture de stock coute enormement d’argent.

Conor Doherty : Oui. Bien plus que la piece individuelle dans de nombreux cas.

Fabian Hoehner : Traditionnellement, en aeronautique, tout le monde est surstocke. “En cas de doute, achetez-en une autre.” C’est l’approche typique.

Comprendre la probabilite d’un scenario a 99 ou 99,5 est donc extremement important au niveau de la piece individuelle. Nous y reviendrons a un niveau plus detaille. Pour l’instant, a haut niveau, pourquoi regardons-nous tous ces extremes ?

Parce que c’est la que nous jouons en aeronautique. Personne ne veut savoir quelle est la moyenne. Cela signifierait que vous avez assez de stock dans 50 % des cas. Cela ne vous interesse pas.

Vous voulez savoir quelle est la probabilite de couvrir les extremes. Donc, en regardant cela, encore une fois, nous allons du haut niveau vers le niveau plus bas. Ici nous avons l’investissement, et maintenant c’est mon investissement total. Ce que l’on veut savoir, typiquement pour le client, c’est : quelles sont les quantites ? Dans ce cas, nous avons tres simplement une liste de “voici mes articles et voici les quantites dans lesquelles nous investissons”.

Conor Doherty : Pour clarifier, a ce stade, nous regardons des rotables ou des consommables ? Ici, ce sont uniquement des rotables.

Fabian Hoehner : Oui, des rotables.

Conor Doherty : Oui, absolument. Mais nous regarderons les consommables plus tard, ou nous aborderons la logique correspondante.

Fabian Hoehner : Oui, nous aborderons la logique, mais…

Conor Doherty : Mais ce sont essentiellement les pieces les plus couteuses. C’est pour cela que nous les regardons.

Fabian Hoehner : Tu as vu que les valeurs que nous voyons ici sont assez importantes, parce que oui, nous regardons bien des rotables. La majorite des concepts sont transferables aux consommables. La principale difference, c’est que la piece rotable, par definition, a une rotation, donc une boucle, au lieu de plusieurs boucles de reparation.

En theorie, vous pouvez faire cela en interne, ou vous avez une mise au rebut. Un consommable, lui, vous l’achetez et il sort. Il y a donc quelques differences dans les mathematiques, mais les principes sous-jacents auxquels je faisais reference au debut, l’incertitude, ou la quantification de l’incertitude, et la priorisation economique, restent les memes.

Conor Doherty : D’accord.

Fabian Hoehner : La question maintenant est : pourquoi recommandons-nous quatre, trois, cinq, et ainsi de suite ? Pour cela, nous allons entrer un peu plus dans le detail, mais d’abord rester a un niveau encore assez eleve. Ce que nous voyons ici est, encore une fois, la meme liste que precedemment, mais avec des informations supplementaires. La premiere chose que nous voulons voir intuitivement, et je vais vous montrer plusieurs ecrans avec beaucoup de chiffres.

Je vais vous dire, a toi et au public, quelles sont les choses a regarder. Dans ce cas, voici ma liste, et voici les pieces que je recommande d’acheter. Vous voyez quatre unites ici, trois la, cinq, etc. Ce qui est important, c’est ce que l’optimisation devrait faire intuitivement.

Je vais expliquer comment nous y arrivons. Nous irons de plus en plus en profondeur. Mais d’abord : est-ce que cela a intuitivement du sens ? Intuitivement, que devrait faire une optimisation qui cherche l’efficacite ?

Si l’efficacite correspond a la reduction d’AOG par dollar depense, ou a l’augmentation du taux de service par dollar depense, alors nous devrions voir que les pieces qui sont, A, relativement bon marche et, B, tres importantes, sont surponderees en disponibilite par rapport aux pieces qui sont cheres et peu importantes. Donc, si nous regardons cette liste, prenons les deux premieres pieces, parce qu’elles ont un prix unitaire assez similaire. Ce que nous voyons, c’est qu’une piece est beaucoup plus elevee. Le taux de service final, le taux de service actuel, correspond a ce que je couvre avec le stock actuel que je possede.

Le taux de service final est celui auquel j’arrive apres optimisation. Dans ce cas, nous amenons celle-ci a 94 % et celle-ci a 80 %. Pourquoi ? Si nous regardons, celle-ci a une essentiality : no-go. Et celle-ci est go-if.

Donc, au fond, la consequence d’une rupture de stock ici est beaucoup plus couteuse. C’est pourquoi elle est relativement surstockee, et c’est l’intuition a garder. Si nous descendons dans la liste, nous devrions voir la meme chose. Ici, nous voyons une piece a 99. Dis-moi si c’est trop petit, d’accord ?

Conor Doherty : C’est mieux. Merci. Oui, au moins pour moi, parce que je suis presque aveugle.

Fabian Hoehner : Oui. Ici, nous voyons 99,5. La piece est relativement bon marche, a 8 000 dollars, et c’est une piece no-go. Cette intuition doit donc rester valable partout : les pieces que nous stockons agressivement par rapport aux autres doivent etre no-go et assez peu couteuses, tandis que celles que nous stockons moins agressivement devraient etre… ici, on voit que c’est une piece go qui n’est pas vraiment chere, mais seulement go.

Voila la logique sous-jacente de depart, celle qu’il faut garder en tete. Maintenant, la question est : comment arrive-t-on exactement a quatre, trois, cinq, etc. ? Intuitivement, cela a du sens. Tres bien.

Deuxieme etape : comment arrive-t-on exactement a cela ? C’est ici que, pour la premiere fois, nous voyons deja, a haut niveau, qu’un concept de priorisation economique est cache la-dedans. Maintenant, comment y arrivons-nous plus en detail ? C’est ce que nous appelons une priorisation classee. Dans ce cas, une liste d’investissements classee.

Ce que nous faisons ici, c’est regarder chaque achat individuel, ou dans ce cas chaque possibilite d’investissement, et simuler quelle serait la consequence economique d’investir dans cette piece. Si vous regardez les deux ou trois premieres lignes, vous pouvez voir qu’il s’agit du meme PN, mais pas de la meme unite de stock, parce que nous achetons la premiere piece, puis la deuxieme, puis la troisieme. C’est exactement ce que nous faisons partout. Nous simulons l’achat de chaque piece individuelle que nous pourrions acheter. Cette liste est donc pratiquement infinie. Je pourrais faire defiler sans fin, et c’est ce que nous faisons.

Conor Doherty : C’est limite par le budget, j’imagine, parce que je vois que c’est classe, encore une fois. L’investissement total augmente a mesure que vous faites defiler. Donc, j’imagine que vous pourriez fixer une limite stricte, par exemple : “je n’ai que X ; mon budget est X. Il n’est pas infini. Optimisez donc jusqu’a ce point, et pas plus loin.” Fabian Hoehner : Oui. Dans ce cas, ce n’est pas limite par le budget, mais par mon objectif, ici 98 %. Mais tu as tout a fait raison. En gros, les 98 % aboutissent a un budget de 1,2 ou 1,25 million. Donc ce que nous allons faire est exactement cela.

Nous allons simplement faire defiler ici jusqu’a atteindre un investissement total de 1,25. Dans ce cas, nous l’avons fait differemment. Nous avons essaye d’atteindre 98 %, et 1,2 million a ete le resultat. Mais j’aurais pu faire l’inverse. J’aurais pu dire…

Conor Doherty : Oui, bien sur.

Fabian Hoehner : C’est la meme chose, simplement vue sous un angle different. Tres bien. Passons maintenant a quelques exemples pour montrer comment fonctionne cette logique de priorisation economique. Un bon test, y compris pour les membres du public qui font leur propre optimisation, est toujours le suivant : pouvez-vous dire, si je vous annonce “vous avez 100 000 dollars, quel serait l’article le plus important a acheter aujourd’hui ?”

C’est un concept tres important. Ce ne sera pas le cas pour cette premiere piece, mais de maniere generale il faut prioriser chaque action que vous entreprenez, car avec cette logique vous pouvez introduire toutes les contraintes que vous avez : “mon equipe achats ne peut traiter que cinq pieces par jour”, “mon entrepot ne peut en recevoir que dix par jour”, quelle que soit la contrainte, ou encore “j’ai un million de budget”. Si vous n’avez pas une vue priorisee, c’est tres difficile lorsque vous avez seulement un oui/non. Par exemple : “mon objectif est d’avoir la piece A a 99 %, la piece B a 95 %, et la piece C a 91 %.”

C’est extreme, mais d’accord. Dans ce cas, c’est seulement oui ou non, et vous n’avez pas de systeme de classement. Or ce concept est incroyablement important ici, parce que ce que nous pouvons faire est justement prioriser. Vous devez toujours le faire : temps limite, budget, ou autre contrainte. Donc, encore une fois, la question pour le public serait : “pouvez-vous identifier l’unique article le plus important dont j’ai besoin aujourd’hui ?” Et, encore une fois, peu importe le premier seulement : quels sont les 50 plus importants ?

C’est bien ce que nous pouvons faire ici, et nous allons le faire en regardant la premiere ligne. Nous regardons le 1338. Nous allons regarder le 1338 pendant un bon moment, donc soyez patients.

Nous voyons qu’actuellement nous n’en avons aucun en stock. Nous envisageons d’en acheter un. Nous voyons combien ont ete demandes au cours de l’annee precedente. Ensuite, nous achetons une unite, qui coute 1 200 dollars, et actuellement nous avons zero taux de service, ou zero taux de service attendu.

Pourquoi ? Nous avons zero en stock. Donc si vous avez zero, vous ne couvrez aucune incertitude. C’est essentiellement ce que cela signifie.

Mon taux de service attendu signifie : quelle part de l’incertitude future est-ce que je couvre ? Ce que cela veut dire exactement, nous allons y revenir a l’etape suivante. Comme je l’ai dit, nous allons du haut niveau vers le bas niveau. Vous pourriez vous arreter a “voici les articles que vous devriez acheter”, et ce serait tout. Mais evidemment, nous voulons aller un peu plus loin et comprendre d’ou cela vient.

Conor Doherty : Je me permets d’intervenir, parce que c’est un bon point. J’ai recu plusieurs versions de la meme question : “l’idee est interessante, cela semble tres bien”, parce que certaines personnes connaissent deja Lokad, “mais a quoi cela ressemble-t-il pour, disons, mon equipe de planification ?” Tu viens de dire : “regardez ces tableaux de bord, voici les decisions classees.”

Puis tu as dit : “nous allons faire une analyse beaucoup plus profonde”, mais tu as aussi dit qu’on pouvait s’arreter ici. Donc, essentiellement, l’equipe de planification pourrait s’arreter a ce stade. Vous avez deja les decisions. Si vous faites confiance au systeme, vous pouvez executer. Si vous voulez en savoir plus, vous pouvez enqueter sur la raison pour laquelle cette unite, ce PN, est au-dessus de celui-ci, etc.

Fabian Hoehner : Oui.

Conor Doherty : D’accord.

Fabian Hoehner : Effectivement. En supposant que nous ayons mis en place le systeme. Nous pouvons discuter du temps que cela prend, mais disons qu’apres six mois, vous avez un systeme qui fonctionne. Vous pourriez simplement dire : “je fais confiance au systeme”, et les recommandations sont exportees puis executees par les systemes operationnels.

Encore une fois, nous ne sommes pas un systeme transactionnel. Nous sommes un systeme d’intelligence. Nous sommes la pour executer des simulations compliquees puis renvoyer l’intelligence vers le systeme operationnel.

Conor Doherty : Vas-y, continue.

Fabian Hoehner : Je viens de le dire. Cela etant dit…

Conor Doherty : Oui.

Fabian Hoehner : Il y aurait tres peu de gens qui, si l’on se souvient des pieces vues tout a l’heure, une piece a 46 000 dollars, ne vont pas simplement lancer cela automatiquement. Et ce n’est pas…

Conor Doherty : Oui.

Fabian Hoehner : Ce n’est pas ainsi que cela fonctionne. Ce sont des pieces pour lesquelles il faut effectivement demander un devis. En aeronautique, ce n’est pas comme le e-commerce d’Amazon.

Non, vous demanderiez le prix de la piece, et le prix que nous avons ici est une hypothese jusqu’a validation. C’est donc un processus manuel, ou qui peut etre automatise, mais mon point est le suivant : les pieces rotable que nous regardons ici ne sont probablement pas quelque chose que vous automatiseriez entierement. Vous pourriez bien sur, mais effectivement…

Conor Doherty : L’execution de la decision ne l’est pas forcement, mais l’analyse et la generation effective de la decision sont automatisees.

Fabian Hoehner : Ta question est essentiellement : “que regardent les gens ?” Je dirais que, typiquement, si cela ne vaut pas le temps, par exemple si les pieces sont en dessous de 2 000 dollars environ, ou si nous regardions des C&E, alors vous pouvez, et nous le faisons effectivement, tout automatiser. Cela met a jour les systemes operationnels quotidiennement et pousse automatiquement une commande. Si nous parlons d’investissements rotable, c’est typiquement quelque chose que des experts regardent pour valider beaucoup de choses.

Dans ce cas, nous faisons quelque chose de tres similaire a ce que nous faisons ici. Nous avons la recommandation, qui dit “achetez cinq unites de cela”. Ensuite, un expert qui fait ce travail va challenger ce resultat. Au debut, il le challenge pour construire, concevoir et ameliorer le systeme avec nous, puis aussi pour enqueter. Le processus d’investigation, le raisonnement permettant d’arriver a “achetez cinq unites”, c’est exactement ce que je fais ici, ce que je vous montre. Comment suis-je arrive a cela ? Donc, pour revenir a ce que je disais, si tu ne m’avais pas interrompu, ce serait deja fait, mais bon.

Conor Doherty : Mes excuses.

Fabian Hoehner : Nous regardons donc le 1338, et nous avons dit : “acheter une unite nous amene a 47 %.” Cela couvre donc 47 % de l’incertitude. Le delta de 0 a 47 est 47.

Puis nous mettons cela en relation avec l’ensemble du catalogue. Quel est mon delta sur le catalogue ? Cela depend de la consommation de cette piece. Evidemment, une piece dont la consommation est plus elevee aura ici un impact plus eleve, etc.

Ensuite, il y a mon gain sur le taux de service global, la reduction d’AOG en dollars. Comment arrivons-nous a cela ? Encore une fois, nous construisons cela sur mesure, et je ne m’attends pas a ce que beaucoup de personnes dans le public, ni meme nos clients au debut, aient un chiffre fixe en disant : “je sais ce que coute un AOG”. Notre approche consiste toujours a dire : “mieux vaut etre approximativement juste qu’exactement faux.” Dans ce cas, oui, il est tres difficile d’identifier precisement ce que coute un AOG.

Typiquement, ce que vous voulez voir ici, c’est par exemple combien d’AOG nous avons eus qui etaient lies a des evenements, ou pour lesquels un evenement de stock etait la cause, et quelle est mon estimation de haut niveau du cout. Par exemple, nous pouvons aussi voir que j’ai du faire un achat d’urgence. Quelle est la valeur de cela ? De cette facon, je peux essayer de deduire une valeur approximativement correcte.

Encore une fois, l’argument est le suivant : mieux vaut avoir un chiffre en dollars que rien du tout. Parce que si vous n’en avez pas, vous volez toujours un peu a l’aveugle avec des taux de service, ou vous ne pouvez pas vraiment discuter : “devrions-nous etre a 99 ou a 99,5 ?” Je ne sais pas. Mais a partir du moment ou vous mettez des dollars sur quelque chose, vous pouvez discuter, y compris entre departements.

Conor Doherty : Oui.

Fabian Hoehner : Et vous pouvez aussi changer ce chiffre au fil du temps. Ce n’est pas un probleme. Si un an plus tard vous dites : “d’accord, je pense que nos estimations sont fausses ici, ou sur ce type de flotte c’est correct, mais sur ce type de flotte cela devrait etre plus cher”, peu importe. A partir du moment ou vous quantifiez les choses, vous pouvez vraiment…

Conor Doherty : Vous donnez un langage commun aux gens pour discuter des divergences d’opinion.

Fabian Hoehner : Exactement. Parfait. Cela nous amene finalement a la reduction d’AOG par dollar depense, ou au gain de taux de service par dollar depense. Les deux menent a un score qui indique essentiellement ou se trouve mon chemin d’investissement le plus efficace. Maintenant, je vais simplement vous emmener a la deuxieme et a la troisieme ligne, puis nous passerons a la suite.

La deuxieme ligne montre en fait la meme piece. C’est le meme ID, mais nous n’achetons pas la meme piece. Cette fois, nous achetons la deuxieme unite. La premiere a deja ete achetee, donc nous ne pouvons maintenant investir que dans une deuxieme unite. Ce que nous allons voir, c’est que celle-ci va nous amener a… tu peux toujours me dire de zoomer.

Conor Doherty : Non, c’est bon. C’est bon.

Fabian Hoehner : Je me penche un peu. Donc cela nous amene a 72 % dans ce cas, ce qui signifie que nous obtenons 25 % de taux de service supplementaire. La premiere unite couvre evidemment le plus d’incertitude. Quoi, 50 %, et la deuxieme seulement 25.

Quelle est donc la consequence logique ? La deuxieme piece, et c’est assez evident, a moins de valeur pour notre operation. Nous allons donc voir toutes les valeurs diminuer. Mon augmentation de taux de service est plus faible, mon cout AOG est plus faible, et donc mon score de classement est plus faible.

D’accord, ce n’est pas une revolution de dire : “la deuxieme piece a moins de valeur que la premiere.” Je ne peux evidemment pas acheter la deuxieme avant la premiere. Mais maintenant, regardons la troisieme ligne. Meme logique, exactement la meme chose.

Je ne gagne que 14 % pour cette piece. Je paie toujours 1 200 dollars. Mon score de classement va donc baisser. La partie interessante est maintenant la quatrieme ligne, ou nous voyons simplement un numero de piece different.

Tout est different pour cette piece. Elle a une demande de temps de delai differente. Vous voyez ici un TAT sous-jacent different. Vous pouvez avoir un temps de delai sous-jacent different.

Le prix est different. Tout est different sur cette piece. Pourtant, ce qui reste identique, c’est ma logique de classement : quelle est ma reduction d’AOG ? On peut aussi la rapporter a mon investissement.

C’est le seul concept central que nous allons appliquer ici. Je fais une petite parenthese. Bien sur, en realite, nous allons plus loin dans la complexite, et dans ces calculs aussi, nous ajoutons des facteurs sur no-go, if, etc. Dans ce cas, c’est inclus dans le cout AOG.

Pour simplifier, le cout AOG est plus eleve si vous avez une piece no-go. Cela peut devenir extremement complique. Nous avons ensuite, et ce n’est pas parce que nous sommes des genies, le retour de nos clients. Vous regardez un resultat, et nous appelons cela l’optimisation experimentale. Vous montrez une liste a quelqu’un et dites : “voila ce que je ferais a votre place”, puis vous discutez avec les experts, et les experts vous disent : “oui, d’accord, cinq semble raisonnable, mais moi j’en aurais pris vingt.”

Dans ce cas, il y a quelque chose qui me manque, parce que les experts operationnels savent typiquement ce qu’ils font. Cela pourrait etre, par exemple, une housse de siege. Vous pourriez dire : “ce n’est pas techniquement une piece no-go. L’avion peut voler avec.”

Mais les operations vous diront : “oui, mais cela a l’air affreux”, et le cout de faire entrer quelqu’un dans un bel avion et de voir, par exemple, une piece avec du ruban rouge… “nous devons mettre un ruban rouge dessus, nous ne pouvons pas…” Oui. C’est un no-go. C’est donc extremement couteux.

Fait amusant : les machines a cafe, no-go. Vous ne pouvez pas ne pas avoir de machines a cafe. Techniquement, oui, l’avion vole sans elles, mais… Ce sont les choses que nous apprenons ensemble, puis nous adaptons la recette. Cela peut aussi varier d’une compagnie aerienne a l’autre. Quelles sont les priorites ?

Quelles ne le sont pas ? Ce que nous faisons ici, c’est classer tout par le score de classement : quel est le gain de taux de service par dollar depense, l’evitement d’AOG par dollar depense, puis descendre dans la liste. Vous voyez que cela diminue regulierement. Ainsi, une piece qui coute 46 000 dollars et une piece qui coute 5 000 dollars deviennent comparables, parce que la question est simplement : a quel moment est-il logique d’acheter le sixieme exemplaire d’une piece bon marche ou le deuxieme exemplaire d’une piece chere ?

C’est exactement ce que nous faisons ici. La question suivante est donc : comment arrivons-nous a ces valeurs, ou plus concretement, au niveau operationnel ? Tu demandais tout a l’heure ce que regarderaient les operations. Elles regarderaient une liste comme celle-ci.

Ce serait tout a fait raisonnable. Mais elles iraient aussi dans ce que nous appelons ici un item inspector. Dans ce cas, et c’est aussi pour nous. Au final, c’est un tableau de bord KPI, mais il explique comment nous sommes arrives aux valeurs que nous avons vues avant.

Typiquement, cela peut etre utilise par les clients qui investiguent eux-memes, mais aussi par nos supply chain scientists. Ce sont les personnes qui codent et qui servent de sparring partners. J’imagine que la plupart des personnes connaissent le concept de supply chain scientists. Si vous assistez a cette conference, vous avez probablement deja vu quelque chose de Lokad. En bref, ce sont les personnes qui implementent et challengent avec le client.

Nous utilisons donc les memes ecrans d’evaluation que ceux que le client pourrait utiliser pour juger ou evaluer : est-ce une decision raisonnable que nous donnons ? On descend toujours depuis le haut : “achetez cinq”, jusqu’au pourquoi. D’abord, nous avons regarde un classement economique, et maintenant nous regardons tous les details. Si nous ne sommes pas d’accord, typiquement nous venons ici et nous verifions : avons-nous la meme vision de la realite ? Parce que, surtout au debut d’un projet, la majorite des cas ou nous ne sommes pas alignes viennent de… as-tu une idee ?

Conor Doherty : La valeur economique des decisions ?

Fabian Hoehner : Non, les donnees. C’est toujours les donnees. En gros, vous n’etes pas alignes sur la realite que vous regardez. Nos clients complexes, et les entreprises aeronautiques, ont typiquement fait beaucoup d’achats. Voir six systemes ERP differents avec de l’heritage est assez courant, plus trois fichiers Excel ici et la.

Obtenir simplement la bonne interpretation, ou la meme interpretation, d’une meme realite n’est pas facile. La premiere etape est donc : avons-nous la meme vision de la realite ? Voyons-nous les memes unites qui sont, dans ce cas… regardons une autre piece, si nous en trouvons une. Oui, avons-nous le meme nombre d’unites qui sont actuellement dans un processus de retour, de reparation, de logistique ?

Oui, non, peut-etre ? C’est tres important a voir. Et supposons que les donnees soient effectivement coherentes. Alors nous regardons : quelle est notre projection de demande ?

Comment arrivons-nous a cela ? C’est ici que… nous avons parle de priorisation economique. Au tout debut, j’ai dit qu’il y avait deux grands concepts que je voulais que les gens retiennent : la priorisation economique. Nous en avons couvert une partie. Et j’ai parle d’incertitude, de prevision probabiliste, et c’est ce que nous allons regarder maintenant.

Encore une fois, pour certaines personnes, ce sera assez evident, mais je vais avancer un peu lentement pour que tout le monde suive. Ce que nous voyons ici est un historique de consommation extremement typique. Au passage, nous restons avec notre favori, le 1338. D’accord. Donc nous…

Conor Doherty : La meme piece pour ce voyage. D’accord.

Fabian Hoehner : Nous traversons effectivement le parcours de cette piece. Ce que nous voyons est un historique de consommation tres typique : clairseme et erratique. Donc rien, un, un, un, deux, puis deux, un. Cela signifie qu’il est extremement difficile a prevoir.

Et si vous regardiez cela, et je sais qu’en aeronautique tres peu de gens feraient cela, mais si vous le regardiez sous l’angle d’une consommation moyenne avec une moyenne glissante, voila ce que cela donnerait. Est-ce que cela vous aide ? Dans ce cas, cela vous dit 0,17 unite. D’accord, tres bien.

Qu’est-ce que cela m’apporte ? Presque rien. La vue que vous voulez avoir, et ce que nous allons faire, est une vue probabiliste, qui va nous dire : quelle est la probabilite d’une consommation sur un horizon donne ? Quand je dis sur un horizon donne, commencons simplement. Et encore une fois, pour tous ceux qui ont fait des statistiques…

Conor Doherty : Suppose que je suis idiot. Tu peux me parler avec condescendance, ce n’est pas grave.

Fabian Hoehner : Ce sera une hypothese difficile a faire. Donc cet histogramme ici, commencons simplement, serait ou etait une representation de la realite. Juste le passe. En realite, bien sur, nous regardons vers l’avenir, nous faisons des previsions, nous faisons des choses tres intelligentes, mais pour simplifier, disons que nous regardons simplement le passe.

Que fait un histogramme ici ? Nous disons simplement, je ne sais pas si… oui, je pense qu’on peut voir les petites barres ici. Disons que nous supposons qu’une periode que nous regardons se situe entre ces barres. Disons 30 jours, et maintenant je dis arbitrairement : si le passe represente l’avenir, et que nous choisissons aleatoirement un point dessus.

Dans ce cas, cela voudrait dire : a quelle frequence est-ce que j’obtiens une demande de un dans une fenetre de 30 jours ? A quelle frequence est-ce que j’obtiens zero ? A quelle frequence est-ce que j’obtiens deux, trois, etc. ? C’est ce que cela indique.

Donc cela dit que, aleatoirement, dans 25 % des cas, nous allons obtenir zero. Dans 34 % des cas, nous allons obtenir 1, 2, 3, 4, 5, etc. C’est le cas theorique, et nous pouvons voir ici que, si j’avais cet intervalle, ce serait une demande de trois. Si l’intervalle etait plus grand, il inclurait tout cela.

Maintenant, c’est la theorie simple. La pratique, et c’est la que nous en venons a ce que je disais au debut, apprecier et embrasser l’incertitude, c’est : quel est l’horizon sur lequel prevoir ? Parce que ce n’est pas 30 jours. 30 jours serait un nombre fixe, et nous insistons beaucoup sur le fait que l’incertitude existe et que vous ne pouvez pas l’eliminer par planification. Il est confortable de supposer que c’est toujours 30 jours pour avoir une valeur deterministe et simplifier la planification, mais cela ne la rend pas plus reelle. La realite, c’est que parfois cela prend 30 jours, parfois 50, parfois 60, parfois 180, ou…

Conor Doherty : cela ne revient pas du tout.

Fabian Hoehner : Exactement, c’est une mise au rebut. Nous regardons ici des pieces rotable. Les pieces rotable sont normalement reparees. Nous ne regardons donc pas des temps de delai, mais typiquement des turnaround times.

Combien de temps faut-il pour que ma piece redevienne serviceable ? Je recois ma piece, l’avion arrive, la piece unserviceable sort. Je la remplace par une piece serviceable que j’avais en stock, et la piece unserviceable entre alors dans une longue boucle eternelle. Idealement, j’ai les donnees pour identifier chaque station de cette boucle et disposer de nombreuses petites distributions, mais l’essentiel pour moi est de comprendre : quels sont tous les delais possibles auxquels je pourrais faire face ?

C’est l’horizon sur lequel je veux prevoir, parce que je veux comprendre les extremes. Si une piece pouvait etre reparee en un jour, vous n’auriez pas besoin de stock du tout, ou pas de stock supplementaire. Une unite suffirait. Chaque fois que l’avion arrive, une piece unserviceable sort, une piece serviceable entre, la piece unserviceable est reparee : un stock de un suffirait. La realite n’est evidemment pas cela, mais nous voyons que la determination de cette periode est absolument essentielle, et c’est exactement ce que nous faisons ici.

Ici, dans ce cas, cela s’appelle temps de delai de reapprovisionnement ; cela peut etre un turnaround time, peu importe. Enfin, cela importe, mais du point de vue du principe, ce que nous voulons comprendre est : quel est l’horizon sur lequel nous faisons la prevision ? On voit que c’est lisse, evidemment, et que c’est une distribution bimodale. Quelle pourrait en etre l’explication ? Typiquement, en aeronautique, ce pic autour de 80 correspondrait a “tout se passe bien”.

Vous avez une piece, vous l’envoyez a l’atelier de reparation, elle est reparee, tout est parfait. Et ceci represente le fait que quelque chose est casse, doit etre repare, et prend du temps. Cela vous donne une belle distribution bimodale. Le message important ici est qu’il est tres different de dire que, dans la majorite des cas, disons dans 80 % des cas, c’est autour de 80, et dans 20 % des cas c’est 150, plutot que de dire que c’est toujours la moyenne, 110 unites.

Conor Doherty : ce qui arrive tres rarement dans cette distribution.

Fabian Hoehner : Oui. Evidemment, ici c’est lisse, ce sont des donnees de demo, etc. Mais cela pourrait etre un cas tres reel, que l’on voit assez frequemment. Soit tout se passe bien, dans ce cas c’est 80 jours, soit ce n’est pas le cas, et alors c’est 120.

Je ne tire aucune conclusion ici. Je ne dis pas : “choisissez l’un des scenarios.” Non, je dis simplement que ce que vous voulez faire, c’est comprendre que l’incertitude existe et prevoir sur tous les futurs possibles qui existent. Au debut, j’ai dit : “d’accord, supposons que nous prenions un intervalle de 30 jours.” 30 jours. Dans ce cas, c’est une probabilite tres faible, inferieure a 1 %. Mais l’essentiel est que nous allons construire une distribution, une distribution de demande, sur tous les horizons de demande possibles. Donc imaginez simplement, que ce soit fait exactement comme cela ou non n’a pas d’importance pour l’explication visuelle, imaginez que vous avez maintenant une centaine de distributions differentes sur tous les horizons differents qui existent.

Nous les prenons et nous les condensons en une seule distribution, celle-ci. Qu’est-ce que cela fait ? Cela nous donne la demande sur tous les futurs possibles. Pourquoi ces dix dernieres minutes ?

Parce que cela nous donne la representation la plus precise de la demande sur un futur incertain, et c’est incroyablement important. En aeronautique, comme nous l’avons dit au tout debut, la seule chose qui m’interesse, ce sont les extremes. Donc mes scenarios au-dela du 90e percentile. Dans ce cas, il est extremement important de comprendre ou je me situe dans cette distribution. Regardons-en quelques-unes rapidement.

Voila. Nous voyons qu’il est tres typique d’avoir ces distributions avec beaucoup de zeros et une asymetrie a droite. Cela signifie qu’il y a une longue traine que l’on voit tout le temps, et qu’en fait l’absence de demande sur l’horizon est souvent le scenario le plus probable. Mais, encore une fois, comprendre exactement quelle est la probabilite des valeurs extremes, c’est la que se trouve l’importance. Si cette piece nous coute 20 000 dollars, la question est : pour ces quelques pourcents supplementaires, disons ces 7 % supplementaires, meme si ce n’est pas exactement le bon calcul, voulons-nous investir encore 40 000 dollars, ou voulons-nous seulement obtenir les premieres unites ? C’est exactement ce que nous avons fait avant.

C’est pourquoi il est absolument critique de comprendre la forme de la distribution. C’est la premiere etape. Et si nous voulons entrer dans plus de details, ou revenir a notre piece, souvenons-nous, peut-etre ici : si nous mettions une piece, nous obtiendrions un taux de service attendu de 47 %. La deuxieme nous amenerait a 72, puis a 87, et si nous…

Conor Doherty : c’est ce qui etait dans la liste.

Fabian Hoehner : Tres bien. Tu…

Conor Doherty : J’etais attentif.

Fabian Hoehner : Parfait. Donc si nous revenons ici et regardons a nouveau, nous voyons que nous etions a 47 pour la premiere, puis 72, et ainsi de suite. C’est essentiellement le chemin inverse pour comprendre comment nous y sommes arrives. Cela explique comment nous avons obtenu exactement ce nombre. Je respire une seconde, donc si tu…

Conor Doherty : Je pense qu’a ce stade, j’ai deja quelques questions soumises, et c’est un bon moment pour faire la transition, parce que l’une des choses que l’on m’a demandees encore et encore quand j’ai parle aux gens avant cet evenement etait : comment tout ce que les gens viennent de voir s’integre-t-il dans un workflow preexistant ? Evidemment, toute entreprise, tout client que nous avons, ou tout futur client potentiel, aura ses propres logiciels et ses propres workflows existants. Donc est-ce que Lokad… faut-il tout arracher pour mettre cela en place ? Est-ce que cela fonctionne a cote ? Comment cela marche-t-il ?

Fabian Hoehner : Oui, ce serait une tres mauvaise question si c’etait vrai.

Conor Doherty : Oui, exactement, evidemment.

Fabian Hoehner : Non, nous nous plaçons au-dessus. Et je vais vous montrer une chose, litteralement quelques secondes, pour montrer ce qu’il y a en arriere-plan. Donc ceci est…

Conor Doherty : c’est de l’IA, non ?

Fabian Hoehner : Oui, c’est de la magie. Evidemment, c’est de la magie noire. Non, ceci est notre langage de programmation, appele Envision.

Au final, Lokad est plusieurs choses. D’une part, c’est une plateforme big data tres puissante concue pour l’optimisation des stocks, et il y a effectivement de nombreuses fonctionnalites d’IA. Par exemple, nous pouvons ecrire ce langage avec des agents internes, etc. Mais ce que je voulais montrer ici, c’est… tu as pose la question des donnees.

Nous nous adaptons a tout le monde. Nous ne demandons a personne de pre-concevoir quoi que ce soit. Nous voulons simplement les extractions brutes, et une grande partie du travail consiste a manipuler les donnees de notre cote, a les rendre correctes, ou a rendre correcte la manipulation des donnees pour qu’elles aient du sens. Donc, coherence des donnees.

Par exemple, pour vous donner un exemple, la juste valeur d’une piece est quelque chose d’assez complexe a obtenir. En aeronautique, beaucoup de pieces existent depuis tres longtemps. Vous pouvez amortir une piece sur huit ans, et dans votre valeur comptable cette piece vaudra un dollar. Mais la piece peut toujours etre remplacee, et le nouvel achat coute, je ne sais pas, 50 000 dollars. Quelle est donc la bonne valeur a supposer ? Quelle est la juste valeur de la piece ?

Ce n’est pas une reponse facile. Vous avez deux systemes differents. Le systeme comptable dit que c’est un dollar, parce que vous laissez un dollar comptable dedans. Et si vous voulez la racheter, c’est 50 000.

Comment obtenez-vous les bonnes donnees la-dessus ? Cela prend du temps, cela demande des discussions, et de notre point de vue cela demande surtout de la flexibilite. C’est pourquoi nous avons, pour beaucoup de raisons, mais au fond c’est pourquoi nous avons un langage de programmation pour nous adapter a cela. Tous nos clients ont des configurations tres differentes, et nous nous plaçons simplement au-dessus.

Qu’ils aient AMOS, TRAX, SAP, et le plus souvent un melange de tout cela, c’est simplement une partie du systeme d’intelligence. Nous le construisons. Est-ce que cela repond a la question ?

Conor Doherty : Oui, plus ou moins, parce que la raison pour laquelle je demandais cela, c’est que je paraphrase la question. La preoccupation portait plutot sur l’evitement des transactions dupliquees. Si vous avez plusieurs systemes, dois-je reconcilier entre le systeme A et Lokad, et inversement ? C’etait essentiellement le sens sous-jacent de la question.

Fabian Hoehner : Oui. Si tu demandes s’il y a doublonnage de fonctions, je pense qu’il faut revenir un pas en arriere. Vous avez vos systemes transactionnels, qui sont la pour les transactions. Donc…

Conor Doherty : ERP.

Fabian Hoehner : Oui. ERP, M… En gros, je prends une unite du stock et je l’installe. C’est quelque chose que vous voulez voir en millisecondes. Tout doit etre mis a jour partout.

Ce n’est pas Lokad. Nous executons des simulations complexes qui peuvent prendre 20 minutes. Ce n’est pas un probleme. Ici, vous voyez que c’est pre-calcule.

Cela ne prend pratiquement pas de temps parce que nous l’avons pre-calcule. Celui-ci passerait probablement en quelques secondes, mais les calculs les plus compliques peuvent prendre plus longtemps, et ce n’est pas grave, parce que ce n’est pas notre role transactionnel. Notre role est l’intelligence : fournir les meilleures analyses, le meilleur support de decision, les meilleures decisions automatisees, puis les renvoyer aux systemes automatises. Pour y parvenir, nous avons aussi pas mal de dashboards d’analyse.

Donc un systeme de rapports. Systeme d’enregistrement, puis au-dessus, typiquement, systeme de rapports : Tableau, quel est l’autre ? Peu importe. Power BI, ce genre d’outils, puis le systeme d’intelligence, c’est la classe dans laquelle nous operons.

Pour faire cela, oui, bien sur. Une fois que j’ai les donnees, nous construisons beaucoup de dashboards qui donnent une explication. Par exemple, ces dashboards d’investigation que nous regardons ici sont evidemment aussi un systeme de rapport. Ce dashboard est simplement un rapport. Je veux dire, le calcul se fait ailleurs. Mais donc, pour repondre a votre question, est-ce qu’on duplique certaines choses ? Oui, on peut en dupliquer certaines, mais globalement, notre ambition n’est pas de devenir un systeme de reporting. C’est seulement pour nous, en interne, et aussi pour les clients, afin de valider ce que nous faisons, parce que, oui, nous ne voulons pas regarder uniquement du code. On veut voir ce que cela produit.

Conor Doherty : D’accord. En parlant de ce que cela produit, au tout debut, j’ai dit que nous regarderions les decisions d’investissement et de desinvestissement. Je me rends compte que nous nous sommes beaucoup concentres sur les decisions d’investissement.

Pouvez-vous nous montrer quelque chose du type : “j’en ai trop” ? Encore une fois, nous parlions de rotables. “J’ai trop de stock. Comment identifier les unites dont je devrais probablement me separer pour liberer du capital ?”

Fabian Hoehner : Oui. Comme si vous aviez su que j’avais cela quelque part. Brillant.

Oui. Donc, fondamentalement, dans ce cas, la encore, le dashboard est concu comme nous le voulons. C’est un dashboard de demo. C’est simplement le choix que nous avons fait ici.

Dans ce cas, nous avons les opportunites de desinvestissement et d’investissement dans le meme dashboard global. Et ici, ce que nous regardons, ce sont effectivement les opportunites de desinvestissement. Donc, au final, le desinvestissement est presque la meme chose que l’investissement, mais quand nous regardons un investissement, nous prenons le stock actuel que nous avons et nous nous demandons : et si j’ajoutais une unite de plus, puis une autre, puis une troisieme, une quatrieme, etc., pour chaque possibilite de stock ? Ensuite, nous construisons notre score de classement.

Ici, pour une opportunite de desinvestissement, nous regardons tout le stock que nous possedons et nous faisons la meme chose. Nous nous demandons donc : si je desinvestis une unite de stock que je possede, combien de taux de service est-ce que je perds et combien de cash est-ce que je libere ? C’est essentiellement la meme logique, et je ne vais pas tout detailler, mais en gros, dans une liste comme celle-ci, vous voulez voir des articles avec un prix unitaire eleve, et vous voulez voir une faible perte de taux de service. Donc, dans ce cas, on voit que l’on perd moins d’un pour cent sur cette piece.

Et si l’on regarde la perte totale, elle est arrondie. On ne la voit meme pas. Evidemment, il y a des pieces dont vous avez tout simplement trop. Ensuite, vous voyez l’augmentation d’AOG qui en resulte, puis le classement.

Nous devrions probablement ajouter quelques zeros pour que vous puissiez le voir. Mais si nous descendons, vous pouvez voir que cela va augmenter. Donc, au fond, l’impression que vous devez avoir ici, c’est : prix unitaire eleve, faible perte de taux de service, et c’est la logique inverse. Et ensuite, en theorie, vous pouvez meme trouver un point ideal entre les deux, et dire : “d’accord, je veux investir dans tous ceux-ci et desinvestir jusqu’a atteindre un bon equilibre.”

C’est plutot theorique, parce que la realite est plus complexe en ce qui concerne les justes valeurs de marche. Donc, encore une fois, ce n’est pas Amazon ou vous sortez en disant : “oh, j’ai 10 exemplaires en trop d’une piece qui coute 85 000 dollars, vendu.” Non, il faut les vendre. Il faut trouver quelqu’un, faire un transfert de localisation, etc.

Mais ce sont effectivement des dashboards tres utiles pour les clients qui veulent desinvestir des actifs, puis dire : “d’accord, oui, cela a du sens. Nous en avons au moins cinq ici qui servent, au fond, uniquement pour un evenement tres, tres longue traine.” Donc vraiment, si toute notre flotte a un probleme le meme jour, c’est la que cela serait necessaire. Voila donc l’idee generale du desinvestissement.

Conor Doherty : Oui. Pour moi, encore une fois, si nous differencions simplement la facon dont nous allouons le budget selon, pardon, la facon dont nous generons des decisions selon qu’il s’agit d’investissement ou de desinvestissement, et comment ces decisions different legerement. Une question de suivi a ete envoyee en amont. Une personne en achats operationnels voulait savoir : “comment une recommandation d’achat devrait-elle changer, ou comment change-t-elle, selon que l’unite est acquise pour un echange ou pour un achat ferme ?”

Fabian Hoehner : Ca depend. La reponse est toujours…

Conor Doherty : Ces questions demandent en fait pas mal de temps, donc je vous demande des reponses concises. Je sais que si nous n’entrons pas dans tous les details, nous pourrons faire un suivi, ce n’est pas un probleme.

Fabian Hoehner : Oui, bien sur.

Conor Doherty : Mais une reponse generale.

Fabian Hoehner : Oui. Donc la question ici serait : dans ce cas, nous regardons typiquement le pool que vous possedez. Quel est le niveau de stock global que j’ai ? Ce sont donc tous les investissements qui vont augmenter votre niveau global de pool.

Si c’est seulement pour un echange, alors le nombre dans le pool ne change normalement pas, parce que vous l’echangez et vous le rendez a un moment donne. La question serait donc plutot d’evaluer cela. Vous pourriez le faire parce que vous en avez trop dans un… En theorie, vous avez assez de pieces, mais elles sont toutes bloquees dans une boucle de reparation. Vous n’avez donc pas vraiment besoin de plus de stock, mais vous devez couvrir une periode avant qu’elles ne reviennent. Ce serait donc essentiellement une optimisation differente.

Ce que nous regardons ici, ce sont les investissements qui entrent dans le pool. Cela irait aussi vers la priorisation des reparations. Au final, la question sous-jacente serait : si j’ai un nombre donne de pieces dans mon processus de reparation, lesquelles dois-je prioriser pour etre reparees ? Parfois, on peut le changer, mais chaque entreprise a, si nous revenons a la vue d’ensemble, nous avons vu qu’actuellement 500 unites passent par un processus de reparation. Elles ne sont pas toutes aussi importantes.

Et ce que nous pourrions faire ici, et nous le faisons avec, fondamentalement, encore une liste priorisee ou nous disons : d’accord, celles-ci devraient etre… Nous avons ensuite des actions d’acceleration ou vous pouvez voir quelles sont les priorites et si vous pourriez reduire les temps de delai, parce que pour le fournisseur, cela ne change rien. Il a 20 de vos pieces, il les repare toutes, et il ne sait pas lesquelles sont importantes pour vous. Mais nous, nous disons : “nous avons encore cinq pieces serviceable disponibles, et ce n’est pas parce que nous l’avons envoyee plus tot que nous devons la recuperer plus tot.” Cela pourrait donc etre tres typique de ce dont je parlais avec la priorisation. Encore une fois, laquelle a l’impact le plus important pour nous ? Donc, oui, au final, ce ne sont que des listes de ce que nous devons faire pour obtenir le plus fort impact.

Conor Doherty : D’accord. Je peux continuer ? Vous etes bon ? D’accord, parfait.

Comme vous avez mentionne les fournisseurs, cela mene a une autre question cle et concrete qui a ete posee. Je l’ai note ici. Elle vient de quelqu’un qui a deja vu des fournisseurs refuser de rejoindre une nouvelle plateforme a cause des couts d’onboarding ou des frais d’abonnement. Donc, essentiellement, “les fournisseurs doivent-ils changer leur facon de travailler avec le client pour que Lokad puisse faire tout cela ou generer de la valeur ?”

Fabian Hoehner : Les fournisseurs au sens de quoi, les fournisseurs des clients ?

Conor Doherty : Oui. Oui. Donc…

Fabian Hoehner : Non, typiquement, ils sont… Je veux dire, avons-nous besoin des donnees des fournisseurs ? La reponse courte : non. Nous avons seulement besoin des donnees du client, parce qu’il a toutes les donnees.

Est-ce possible ? Oui, nous integrons effectivement certains fournisseurs en plus, typiquement pour les timestamps. Donc vous etes le MRO, vous reparez. Je suis la compagnie aerienne.

J’envoie simplement mes donnees a Lokad, et la seule chose que je sais, c’est que j’envoie la piece et je sais quand elle revient. Si j’ai vos donnees disant “elle est actuellement en reparation, elle est actuellement a la frontiere, ou quoi que ce soit, elle a ete inspectee”, si j’ai ces donnees, et nous avons certains clients qui ont de bonnes relations avec nos clients, cela peut etre aussi simple qu’une feuille Excel envoyee regulierement a Lokad, alors nous pouvons mieux mettre a jour ces points de donnees.

Donc, pour repondre a votre question, si je suis integre avec mon fournisseur et que j’ai les donnees dans mon ERP, dans ce cas je recupere simplement les donnees depuis l’ERP, c’est tres bien. Termine. Mais nous sommes tres flexibles, et c’est probablement l’avantage que nous avons pour nous integrer avec un fournisseur tiers. Encore une fois, nous sommes une entreprise IT.

Pour nous, il est probablement beaucoup plus facile de nous integrer a un tiers, a n’importe quel flux de donnees, que pour une grande organisation d’integrer des donnees tierces dans un ERP. Pour elle, c’est un projet de transition. Pour nous, c’est quelques jours. C’est probablement la grande difference.

Conor Doherty : D’accord. Mais en conclusion, il y a au moins deux categories de donnees. Il y a les donnees utiles et les donnees indispensables.

Et les donnees fournisseur que vous venez de decrire sont utiles. Essentiellement, c’est utile. Cela aide, mais ce n’est pas bloquant.

Fabian Hoehner : Oui, absolument. Donc, juste pour etre clair, oui, bon point.

Conor Doherty : Je veux etre concret, n’est-ce pas ?

Fabian Hoehner : Oui. La question des donnees est toujours bonne. De quel type de donnees avons-nous besoin ?

En gros, dans l’aeronautique, vous devez tout tracer. Donc il y a assez de donnees. La question est : “en avons-nous assez ?” Oui, vous en avez.

La question est : sont-elles jolies ? Sont-elles propres ? Non, jamais. Mais il y a suffisamment de donnees, et ensuite le travail commence pour arriver a la meme interpretation des donnees.

Les donnees ne sont que des donnees, mais comment les interpretez-vous ? C’est la question. Oui, l’historique de consommation, c’est evidemment important. Les niveaux de stock, le catalogue, oui, tout cela, mais aussi les standards.

Et puis il y a beaucoup de donnees utiles. Les niveaux de stock historiques par localisation, des choses comme ca. Et puis, evidemment, les timestamps fournisseur, c’est tres difficile. Typiquement, vous ne les voyez pas.

Vous voyez simplement le turnaround time sous forme de deux valeurs : sortie et entree, et c’est tout. Si vous avez les timestamps intermediaires, c’est tres puissant, mais si vous ne les avez pas, alors vous avez seulement une distribution, large, de ces valeurs. Sinon, vous avez plusieurs distributions.

Conor Doherty : Vous avez commente plus tot, a propos de donnees potentiellement desordonnees, en disant “ensuite le travail commence.” Mais pour clarifier, et c’est aussi quelque chose qui a ete demande au sujet de la preparation des donnees, qu’est-ce qui est requis des clients ? Et cela rejoint, je suppose, ce que vous disiez plus tot sur le supply chain scientist.

Fabian Hoehner : Oui. Normalement, notre attitude est de le faire ensemble, parce que, encore une fois, c’est ce pour quoi nous sommes concus. Nous sommes une plateforme big data.

Nous sommes rapides la-dessus. Nous sommes typiquement beaucoup plus rapides que nos clients, meme pour preparer les donnees. Nous avons simplement besoin d’extractions brutes. Cela dit, evidemment, avoir des personnes qui connaissent les donnees, qui savent ou elles sont, c’est important, cela a de la valeur, et cela accelere un projet.

Je ne vais donc pas dire que ce n’est pas excellent d’avoir des personnes qui ont deja regarde les donnees et qui savent ce qu’elles signifient. Mais sinon, notre approche consiste a aller au niveau de la decision. C’est cela qui est beau. Si je vous dis, encore une fois, “achetez quatre pieces, faites cela”, les problemes sous-jacents deviennent assez evidents. Faire une mission de nettoyage de donnees…

En gros, j’ai vu beaucoup d’entreprises dire : “nous ne sommes pas prets. Nous voulons d’abord nettoyer nos donnees.” Puis vous leur reparlez deux ans plus tard, et la reponse est : “nous nettoyons toujours nos donnees”, parce qu’il est incroyablement difficile de savoir par ou commencer. Il y a toujours des donnees desordonnees, une categorisation incorrecte, des hierarchies de produits. Oui.

Oui. D’accord, tres bien. Pour nous, il serait utile d’avoir une meilleure categorisation. La cartographie des interchangeabilites, evidemment, les interchangeabilites en aeronautique, unidirectionnelles, bidirectionnelles, c’est tres important.

Donc, oui, ce n’est pas propre. Serait-il beaucoup mieux que ce soit propre ? Oui, absolument. Mais en allant jusqu’a la decision, allez-vous aussi voir tres clairement quelles donnees ont de la valeur ?

Oui, parce que prenons l’interchangeabilite. Une nouvelle piece, puis-je l’utiliser sur un ancien equipement ou non ? Oui ou non. Cela deviendra assez evident si je donne une mauvaise recommandation. Evidemment, si j’ai une piece compatible dans les deux sens, je veux l’avoir plus agressivement. C’est interessant.

Donc si ma recommandation est tres fausse pour un utilisateur, je dis “cinq”, et l’utilisateur dit : “he, pourquoi ? Nous n’avons plus besoin de l’ancienne piece. La nouvelle peut reparer l’ancienne et la nouvelle, donc nous en voulons 20.” Dans ce cas, en regardant l’inspector, etc., nous arrivons tres vite a la conclusion : “ah oui, nous ne savions pas que cette piece fonctionnait pour ces deux scenarios de demande.”

Pourquoi ? Parce que les donnees n’etaient pas correctes. Et alors vous savez : “oui, ce sont des donnees qui valent la peine d’etre corrigees”, parce que nous regardons effectivement des points de donnees qui nous aident. Alors que si vous nettoyez simplement pour nettoyer, vous n’arriverez jamais nulle part et vous n’arreterez jamais de nettoyer.

Conor Doherty : Bien.

Fabian Hoehner : Pourquoi souriez-vous ?

Conor Doherty : Quelqu’un nous felicite… Alex vient de se qualifier lui-meme d’intelligent. Il est assez intelligent. C’est un garcon intelligent. Oui.

Donc, encore une fois, l’une des questions, et j’ai fusionne plusieurs versions de cette question en une version generale, concerne essentiellement l’implementation. Donc, plus precisement, les efforts d’integration, les exigences de donnees, vous avez deja aborde les exigences de donnees, mais aussi l’integration, les donnees, la securite, le support, la scalabilite sur une large base de fournisseurs, l’ingenierie, les exigences de calendrier, etc. Je comprends bien, combien mesure un bout de ficelle ? Cela depend de chaque cas. Je le comprends, mais il faut une reponse a grands traits pour les personnes qui regardent et pourraient etre interessees.

Fabian Hoehner : Six mois.

Conor Doherty : D’accord. Approximativement, cela peut etre plus rapide, cela peut etre plus long.

Fabian Hoehner : Oui. Et oui. D’accord.

Alors, d’accord. Typiquement, cela depend de tout, mais deux mois pour obtenir les donnees et arriver a une comprehension approximative de ce que l’on regarde, donc la sante des donnees a haut et bas niveau, ou l’on partage simplement la meme interpretation des donnees. Deux mois pour une optimisation approximative. Nous sommes en fait assez rapides la-dessus, puis encore deux mois pour affiner, mais aussi pour tourner en parallele, parce que notre mode de fonctionnement est, encore une fois, que tout le monde fait deja ce que nous faisons ici.

Les entreprises avec lesquelles nous travaillons prennent deja des decisions au quotidien sur “que devrais-je acheter ? Dans quoi devrais-je investir ?” Donc, en gros, vous faites tourner cela en parallele de leurs processus, et c’est la que vous obtenez l’amelioration. Cela m’amene en fait a une petite fonctionnalite concernant l’historique : comment comparer au passe, ou comment evaluer ?

Une fonctionnalite que j’aime souligner sur la plateforme, c’est que nous sommes entierement compatibles avec l’evaluation du passe. Qu’est-ce que je veux dire par la ? Si nous regardons l’historique, je peux voir toutes les executions passees que j’ai. Par exemple, je peux litteralement voir ce que j’ai fait aujourd’hui.

Je peux regarder le dashboard que j’ai execute il y a quelques heures. Et ce que je peux faire ici, et ce que vous pouvez voir que j’ai fait, c’est que j’ai suppose que vous me poseriez une question sur le budget. Dans ce cas, j’ai mis le budget a, pardon, 1 million au lieu de 10 millions. Et donc maintenant, si nous revenons a nos 98 %, avant, quel etait l’investissement, vous vous souvenez ?

Conor Doherty : 1,2… 2 millions.

Fabian Hoehner : Tres bien. Donc, ce que nous faisons ici maintenant, c’est que nous n’arrivons plus qu’a 900 000, parce que j’ai mis une limite de 1 million. Et nous pouvons effectivement jouer avec ce dashboard. Je peux l’executer.

Je peux faire cela avec n’importe quel dashboard que j’avais dans le passe. Je peux vous dire que la plupart des gens ne pensent pas que ce soit une fonctionnalite tres importante, mais elle est en fait incroyablement precieuse, surtout si vous voulez remonter dans le temps a n’importe quel moment et voir ce que nous avons fait. Tres souvent, quand il y a une situation AOG, les entreprises vont, je ne veux pas dire paniquer, mais elles passent en mode investigation : “comment est-ce arrive ? Qu’avons-nous mal fait ?”

Et dans ce cas, cela devient incroyablement, je veux dire, nous parlons de temps de delai de six mois pour une piece, et il devient incroyablement difficile de challenger votre systeme et ce que vous faites si vous n’etes pas capable de vous replacer dans la situation ou vous etiez en janvier 2026. Mais ici, je peux simplement aller dans ma simulation 2026, et je verrai potentiellement que “oui, nous voulions obtenir une troisieme unite de celle-ci. C’etait interessant a acheter. Cependant, nous etions contraints et nous n’avions qu’un budget de, je ne sais pas, 10 millions, et c’est donc la raison pour laquelle nous ne l’avons pas achetee.”

Mais alors nous le savons. La consequence pourrait etre : “oui, nous devrions augmenter nos budgets et disposer de plus d’argent.” Ou la consequence pourrait aussi etre : “en fait, oui, nous n’avons pas bien priorise cela.” Nous aurions du donner une penalite plus elevee a la rupture de stock, et la consequence est que nous changeons l’algorithme. C’est absolument crucial. Vous passez d’une investigation, je dirais, un peu inutile, au fait de challenger le systeme sous-jacent, et la consequence est alors soit de dire “l’algorithme a fait ce qu’il devait faire et c’est bon.”

Oui. Parfois, vous avez des evenements extremes et vous avez des ruptures de stock. Ici, nous disons que nous allons a 98 %. Cela signifie que dans 2 % des cas, nous aurons des ruptures.

C’est simplement de la statistique. Mais vous pourriez aussi dire : “regardez au-dela de cela. Nous devrions changer l’algorithme pour qu’a l’avenir il soit meilleur”, mais c’est un processus continu. L’optimisation est un processus continu.

C’est un flux continu ou vous essayez de tendre vers la perfection, que par definition vous n’atteignez jamais. Donc voila. C’est pourquoi avoir quelque chose qui permet de regarder l’historique, et meme d’executer de nouvelles donnees sur un ancien code, est important. Je peux prendre les calculs, la ponderation, la penalite que nous donnons pour une piece visible par le client, etc.

Je peux executer les donnees d’aujourd’hui avec un code ou un algorithme vieux de six mois, ou inversement, prendre les anciennes donnees et dire : “d’accord, que ferait-il si je les mettais dans l’optimiseur d’aujourd’hui ?” Encore une fois, tres peu de gens poseront la question, mais c’est une fonctionnalite extremement puissante, qui a ete creee au depart pour corriger des bugs, parce que c’est important. Si les donnees changent d’un jour a l’autre, le bug peut tout simplement disparaitre, et c’est penible, parce que vous savez qu’il y a quelque chose, mais vous ne pouvez pas le localiser. Bref, je m’egare.

Conor Doherty : D’accord, ne vous egarez pas. C’est bien d’avoir ces informations concretes au dossier. Nous avons encore quelques questions.

Vous etes pret ? On continue. Parfait.

Fabian Hoehner : Non, pardon.

Conor Doherty : Tres bien. Celle-ci, encore une fois, n’est pas explicitement sur les achats. Elle porte plutot sur d’autres optionalites.

Donc, essentiellement : tres bien. “Lokad peut-il decider si nous devrions acheter une autre unite ou deplacer une unite existante entre des localisations ?” Nous nous eloignons un peu du sujet du jour. Nous n’allons pas ouvrir un autre dashboard, mais une reponse de haut niveau ?

Fabian Hoehner : Oui. Donc…

Conor Doherty : Oui. Question suivante.

Fabian Hoehner : D’accord. Termine. Non.

C’est la que la priorisation economique intervient. Au final, et ce sera probablement tres ennuyeux, ma reponse sera toujours : “si c’est logique, nous pouvons le faire.” Quelle logique devrions-nous appliquer ici ? La question est simplement que, d’abord, vous voulez simuler : quelle est la probabilite de besoin ?

Dans ce cas, pour un probleme d’allocation, vous devez d’abord simuler la demande par localisation. Par exemple, vous avez des MBK dans 100 outstations, il faut le faire. C’est evidemment difficile. Il est plus difficile de prevoir quand c’est encore plus sparse, mais il faut le faire. Nous disons toujours : “ce n’est pas la facilite du calcul qui decide du niveau de simulation, mais la decision que vous voulez prendre.”

Donc, si je veux simuler le besoin d’une piece par localisation, je dois prevoir au niveau de la localisation. Maintenant, pour repondre a la question : que devons-nous faire ? Devons-nous acheter davantage pour le stock central ou devons-nous reallouer ? C’est une question d’economie, au final.

C’est simplement la question du cout de deplacement de la piece par rapport a… Vous deplacez la piece. Cela signifie que vous exposez davantage au risque la station depuis laquelle vous deplacez la piece, et donc risque accru plus cout logistique contre cout d’investissement externe. C’est le cout du capital. Oui, au final, c’est assez logique et calculable.

Oui, et pour nous, le point essentiel est toujours que nous pouvons le faire a l’euro, au dollar, a la livre, peu importe. Mais la question est toujours : quelle est l’ampleur du probleme, et a quelle frequence se pose-t-il ? Vous pouvez aussi resoudre cela avec une simple regle de trois. Mais si c’est une question pertinente et a forte valeur, alors nous pouvons aller exactement a ce niveau.

Conor Doherty : D’accord. Quelques…

Fabian Hoehner : Dites-moi si ce n’est pas clair.

Conor Doherty : Non, non, non. Parfaitement clair. Je suis aussi conscient qu’il y a d’autres questions a traiter, et je ne veux pas ralentir. Encore une fois, pour tout ce qui n’est pas clair, j’ai deja recu quelques messages de personnes disant qu’elles veulent faire un suivi, parce que cela prendrait trop longtemps : “d’accord, et dans cette situation ? et cette situation ?”

Fabian Hoehner : Juste pour etre clair, je ne veux pas… Mon point, c’est que je voulais m’assurer que nous retenions ces deux principes : l’incertitude, donc, fondamentalement, differentes incertitudes, turnaround time et demande melanges, nous donnent une vue de l’incertitude, et la priorisation economique. Avec cela, nous pouvons repondre a presque 95 % de toutes les questions sous-jacentes. Que ce soit, comme vous l’avez demande au debut, les consommables et expendables. Maintenant, nous avons parle de la boucle.

D’accord, la boucle est plus compliquee, mais au final, les C&E sont la meme chose. C’est simplement du stock qui entre et qui sort, donc 100 % de rebut, si vous voulez le dire ainsi. Et le principe sous-jacent est quelque peu le meme. Vous pouvez faire exactement la meme optimisation economique.

Vous pouvez le faire, mais vous n’y etes pas oblige. Si le probleme sous-jacent est simple, vous pouvez aussi le resoudre plus simplement. Nous ne sommes donc pas obliges de le faire avec ce type d’optimisation. Mais ce serait normalement la forte recommandation. Encore une fois, si nous devons simplement faire du quick and dirty, nous pouvons toujours commencer quick and dirty pour avoir quelque chose de meilleur que l’existant et automatise, parce que l’automatisation bat presque toujours l’humain.

Puis passer a la deuxieme etape. Oui, donc juste… J’ai des tonnes et des tonnes d’autres dashboards, mais je ne veux pas entrer dedans. Simplement, pour l’allocation, oui, bien sur, vous pouvez avoir un dashboard qui vous dit : “vous devez allouer depuis une localisation vers une autre.” D’accord, tres bien. Encore une fois, je ne veux pas entrer dans les mathematiques ici.

Conor Doherty : Oui, ce sera le sujet d’un suivi. Cela va brouiller les pistes.

Fabian Hoehner : Les choses de haut niveau que je voulais souligner, mais oui, nous avons, je dirais que cela depend toujours de ce que vous appelez un module. Est-ce que les differents temps de delai sur les turnaround times qui montent en charge, est-ce un module ? Cela depend. Ou est-ce seulement les achats dans le module ? Mais on peut dire que nous avons 20 modules differents, donc on voit quelques idees ici.

Conor Doherty : Oui. D’ailleurs, sur ce point, encore une fois, peut-etre que quelqu’un a manque une section precedente, mais c’est une question en direct, donc nous allons la poser. Elle vient de Saddaf, j’espere que je prononce correctement. “Pouvez-vous commenter un peu plus la facon dont Lokad gere les retards fournisseurs lors du calcul de la quantite d’achat optimale ?”

Fabian Hoehner : Oui. Donc, je veux dire…

Conor Doherty : Vous pouvez remontrer si vous voulez revenir dans le dashboard, pour ceux qui auraient manque cette partie plus tot.

Fabian Hoehner : Oui, bien sur. La question est : qu’est-ce qu’un retard, par rapport a quelque chose qu’il faut simplement prendre en compte ? Un retard signifie que vous avez une valeur attendue, et maintenant cela prend plus de temps. Il y a donc deux reponses a cela.

La premiere serait l’action d’acceleration. En gros, vous aviez suppose que cela prendrait 30 jours, et maintenant vous etes au jour 40. Dans ce cas, ce que nous fournissons typiquement, c’est une liste de priorites classee : qui appelez-vous en premier ? Parce que, encore une fois, si j’ai une piece en retard de 10 jours, mais que j’ai cinq pieces serviceable disponibles, je me fiche qu’elle soit en retard.

Ce n’est vraiment pas important pour moi. A l’inverse, si j’en ai une qui n’est meme pas en retard, nous sommes au jour 25, mais je suis en rupture de stock et je sais que c’est super urgent, je veux probablement prendre le telephone et leur dire : “he, pouvez-vous vraiment faire tout ce que vous pouvez pour faire rentrer la piece ?” C’est donc la moitie de la reponse sur la facon dont nous gerons les retards. La question est : pouvez-vous faire quelque chose ?

Puis donner aux utilisateurs la possibilite de prioriser, n’est-ce pas ? Et c’est toujours : quel est l’impact de quelque chose qui ne va pas ? C’est la premiere moitie de la reponse. Et la deuxieme moitie serait ce que nous avons regarde ici…

Conor Doherty : Quelle est la definition de retarde ?

Fabian Hoehner : Oui. Au final, nous dirions plutot qu’il y a differents temps de delai. C’est bien d’avoir dans un contrat “60 jours”. Si dans la realite cela prend toujours 120 jours, ce que vous voulez faire, c’est l’integrer dans votre recommandation d’achat.

C’est exactement ce que nous avons fait ici. Vous ne dites donc pas “c’est toujours 80” ou “c’est toujours 120”, peu importe les chiffres ici. Vous dites “il y a toutes ces possibilites”, puis, encore une fois, la distribution de demande que nous voyons ici est une distribution de demande sur tous les temps de delai possibles. C’est exactement pour cela que nous faisons tout cela.

Pour embrasser l’incertitude qui est incontrolable, et les turnaround times ainsi que les temps de delai fournisseur en sont une grande partie. Et, pour etre tres clair, nous ne sommes pas entres dedans, mais cela aussi est prevu. J’ai toujours parle en simplifiant : nous disons que nous regardons le passe et que le passe represente le futur.

Nous savons evidemment que le passe ne represente pas toujours le futur. Nous etions evidemment la pendant le COVID avec nos clients et apres le COVID, donc baisse puis reprise, et augmentations incroyables des turnaround times. Nous pourrions aussi voir, si un turnaround time suivait cette trajectoire, nous ne dirions pas “le passe represente le futur”. Non.

Evidemment, nous prevoyons alors les turnaround times, puis nous prevoyons la demande sur des distributions de turnaround time prevues. Et j’anticipe encore une question. J’ai dit que nous regardions l’annee passee. Evidemment, nous pouvons regarder les checks a venir. Donc si j’ai un… Oui, allez-y si vous avez une question.

Conor Doherty : Non, non, cela va justement faire partie d’une question plus tard. Continuez, s’il vous plait.

Fabian Hoehner : D’accord, donc la question typique serait : comment prevoyez-vous la demande future ? Regardez-vous simplement le passe ? Ca depend. Si vous avez une operation de mille avions, donc un grand MRO, et beaucoup de masse statistique, alors regarder le passe est en fait une assez bonne representation du futur.

Cependant, si vous avez plus d’information, et c’est toujours la question, quel est le niveau d’information que vous avez ? Par exemple, vous savez que vous avez une serie de D-checks qui arrive. Alors, bien sur, nous allons prendre la BOM probabiliste, la bill of materials, qui est elle-meme incertaine, en theorie. Pour certaines pieces, vous savez que vous allez les remplacer, donc vous avez 100 % de probabilite de remplacer une piece consommable. Mais pour d’autres, vous savez seulement que vous allez ouvrir…

Conor Doherty : et ensuite vous voyez de la corrosion que vous n’attendiez pas.

Fabian Hoehner : Oui. Ou vous savez que, sur la base des C-checks passes, vous remplacez la piece dans 30 % des cas. C’est une bill of materials probabiliste ou vous dites : “voici les 100 pieces dont je vais avoir besoin avec leurs probabilites.” Et si je sais que cet evenement aura lieu dans deux mois, alors je peux le planifier.

C’est exactement ce que nous faisons. Maintenant, la realite est bien sur plus compliquee parce que lorsque vous dites “nous avons un C-check dans deux mois”, combien de fois cela sera-t-il vraiment dans deux mois ? Il y a aussi de l’incertitude la-dessus. Donc, encore une fois, quand je dis que j’ai introduit deux incertitudes principales, en realite nous pouvons en avoir encore plus, et cela ne fait qu’augmenter mon incertitude, elargir les distributions, mais au final cela revient a la meme question : quelle couverture est-ce que j’obtiens si j’investis dans une piece de plus, et est-ce que cela en vaut la peine ? Suis-je pret a depenser, je ne sais pas combien celle-ci coute, 10 000 dollars, pour obtenir encore, quoi, 0 point, ou encore 4 %, ou quoi que ce soit ?

Conor Doherty : C’est clair pour moi. Encore une fois, c’est aussi utile de le souligner : c’est pourquoi avoir les dashboards ici est si critique. Une question de suivi vient de Metan, pardonnez-moi si je prononce mal. Elle porte en fait sur un point tres important qui avait deja ete souleve, c’est-a-dire que generer, disons, le meilleur ensemble de decisions d’investissement, de desinvestissement ou d’allocation est formidable, mais s’il y a un manque d’adherence, autrement dit si les gens n’executent tout simplement pas, c’est un probleme.

La question est donc : comment savez-vous vraiment, c’est une question publique, “comment savez-vous vraiment si l’entreprise, disons un client, a effectivement achete la piece suggeree ?” Donc, vous parliez de tracabilite plus tot. Peut-on suivre que “dans X pour cent des cas, ces decisions ont ete suivies ?”

Fabian Hoehner : Ah, d’accord. Oui. Donc…

Conor Doherty : Simple audit, auditabilite, pardon.

Fabian Hoehner : Comment suivriez-vous cela, Conor ?

Conor Doherty : Avec un ordinateur.

Fabian Hoehner : Oui. D’accord. Super. Donc, au fond, nous voyons l’execution. Si je recois quotidiennement les historiques de transactions sur tout.

Cela inclut les achats. Je vois litteralement si quelqu’un a suivi ma recommandation. Evidemment, je simplifie beaucoup ici, mais disons simplement que lundi j’ai recommande cinq. Le run s’est execute dimanche soir. Lundi matin, l’operateur voit : “d’accord, cinq recommandes.”

Et ensuite, lors du run du mardi, je vois cinq. Alors je peux dire : “j’ai 100 % d’adherence.” Je simplifie beaucoup, et en realite c’est plus complique que cela, parce que dans ce type de questions, il peut evidemment y avoir de longs delais avant de faire une proposition, etc. Mais, au fond, oui, nous suivons cela, et pour quelque chose d’automatise, si nous parlons de consommables, vous pouvez tres bien le suivre.

La, c’est beaucoup plus simple. Vous avez simplement de la masse. C’est plus facile. Ici, donc sur tout le cote rotable dont nous avons parle, je dirais que le feedback humain est probablement le plus important. Litteralement, ces listes, nous les regardons avec nos clients, et encore une fois, nous sommes tres bons en mathematiques, en statistiques, mais quand je dis nous, je veux dire…

Conor Doherty : oui, vous etes un genie absolu.

Fabian Hoehner : Non, je veux dire, c’est une plateforme tres puissante, et nous avons des ingenieurs intelligents, et c’est notre expertise. Nous sommes dans le secteur aeronautique depuis environ 13 ans. Nous avons accumule pas mal d’expertise, mais nous ne pretendons jamais connaitre l’aeronautique mieux que nos clients. Quand un retrofit arrive-t-il ? Encore une fois, quand nous sommes avec des entreprises aeronautiques, ce sont des gens tres passionnes. Quand ils voient un avion, ils savent immediatement quel avion c’est, quelles sont les pieces dedans, etc. Nous, nous sommes plutot le cote statistique.

Qu’est-ce que cela signifie ? Nous nous appuyons toujours fortement sur l’expertise et le feedback des utilisateurs, puis nous concevons aussi les dashboards a 100 % pour eux. S’ils nous disent : “oui, je veux que cela ait un aspect different. Je veux des couleurs differentes. Je veux ceci ou cela.”

Oui, nous ecoutons, et nous le concevons pour cet usage. Et reconstruire cela, le redesigner, c’est une demi-journee pour nous. Meme pas. Si vous voulez, je peux parler d’IA, mais c’est un autre sujet.

Conor Doherty : Non, je vais continuer. C’est plutot un commentaire. Pardon, attendez. Oui.

Cela concerne essentiellement la part du processus manuel d’achat qui peut effectivement etre supprimee en travaillant avec Lokad, parce que je ne veux pas mal representer les choses. Vous avez aborde cela plus tot lorsque vous avez parle des rotables. Encore une fois, selon le prix que vous payez, vous aurez evidemment toujours un expert dans la boucle pour valider un achat a 90 000 dollars, mais quelle part de ce processus peut vraiment etre… quelle part du temps investi dans ce processus peut etre liberee ? Et meme question quand on parle de C&E.

Fabian Hoehner : Oui, je vais reprendre ma reponse de tout a l’heure.

Conor Doherty : Oui, je lis simplement.

Fabian Hoehner : Oui. Non, bien sur. Mais cela depend de la complexite de ce que vous faites. Et je dirais que les C&E peuvent vraiment etre automatises dans une tres large mesure.

Et quand je dis cela, je veux dire au-dela… Oui, je sais que beaucoup est deja automatise avec les points de reorder. Nous avons du min-max. Nous pouvons automatiser cela, mais avec un systeme beaucoup plus intelligent. Quelque chose comme cela peut potentiellement, par exemple, reinitialiser les points de reorder, si nous le voulons, chaque jour, afin d’executer la decision que nous voulons.

Nous le faisons pour certains clients. Et je dirais qu’il y a aussi d’enormes gains de temps la-dedans. Mais quand, encore une fois, vous achetez des pieces a plusieurs millions de dollars, je dirais qu’a ce stade, il s’agit moins des gains de temps, qui existent definitivement et sont assez importants, que du fait d’etre meilleur. C’est vraiment le coeur du sujet. Vous evitez quelques AOG, et alors les couts deviennent presque non pertinents, dans une certaine mesure.

Conor Doherty : Je pense avoir couvert, puisqu’il est maintenant 17 h 45. Cela fait environ 75 minutes que nous sommes en ligne. Je sais qu’il y avait une contrainte ferme autour de 18 h, donc je pense… ah non, il reste une derniere question, pardon. Je pense que quiconque a regarde la demo la comprendra, mais pour etre concret, la question est : en quoi Lokad est-il different des autres plateformes d’achats que l’on trouve dans ce domaine, comme par exemple Aeroxchange, parce qu’une personne compare activement deux categories et veut comprendre la distinction entre l’optimisation des decisions et des choses comme le traitement des RFQ, la comparaison des devis, le traitement des PO, etc. ?

Fabian Hoehner : Donc, il y a differents aspects que… Non, je dis simplement qu’il y a differents aspects qu’Aeroxchange couvre, mais a haut niveau, je veux juste dire que nous ne sommes pas, en soi, une plateforme d’achats. Encore une fois, un systeme d’intelligence. Donc la difference…

Conor Doherty : La prise de decision.

Fabian Hoehner : Oui. Encore une fois, vous avez vos systemes transactionnels. Nous sommes au-dessus. Nous sommes le cerveau, et nous renvoyons les meilleures decisions possibles que les statistiques et la business intelligence peuvent fournir, et qui doivent ensuite etre executees. Aeroxchange a aussi davantage de fonctionnalites d’achat pour automatiser la fonction achat elle-meme, la communication.

Ce n’est pas ce que nous faisons. Encore une fois, nous pouvons nous integrer avec differents fournisseurs, donc faire correspondre des choses et avoir de la communication, mais ce n’est pas notre modele metier. Nous ne listons pas les prix ou ce genre de choses. Ce n’est tout simplement pas notre business model. Je ne nous appellerais donc pas une plateforme d’achats. Je dirais plutot automatisation de decision, aide a la decision et systeme d’intelligence, en resume.

Conor Doherty : D’accord. Une derniere, c’est plutot un commentaire. Les gens semblent etre plus a l’aise, ce qui se comprend, pour envoyer des DM que pour commenter publiquement. Et je lis mot pour mot : “sympa, mais je suis plus interesse par les reparations. Cette approche peut-elle etre appliquee pour prioriser les reparations et l’expediting ?”

Fabian Hoehner : Oui. C’etait facile, non ? Oui.

Conor Doherty : Faites un peu plaisir au public avec celle-la.

Fabian Hoehner : Non, plus serieusement, c’est encore une fois la meme logique. Donc maintenant, au lieu d’acheter une piece, je me demande si je dois reparer mon unserviceable. Disons que vous avez 10 unserviceables et zero en stock. Alors, au lieu d’acheter, vous le rendez simplement serviceable.

Le rendre serviceable, dans ce cas, c’est une reparation avec une boucle de reparation, donc un turnaround time, et cela coute quelque chose. Qu’elle soit interne ou externe, les deux ont un cout, mais prenons une reparation externe parce que c’est plus simple. Disons que cela coute 50 000 pour rendre la piece serviceable. La question est d’abord : comment prioriser ?

Parce que j’ai un budget de reparation que je veux envoyer, ou meme une capacite physique. Je peux traiter 50 pieces par jour. Lesquelles sont les plus urgentes ? Et meme lesquelles sont economiquement faisables a reparer ou non ?

Par exemple, apres le COVID, c’etait un gros sujet. Pour certains de nos clients, le cash devenait evidemment un vrai probleme. Il n’y avait tout simplement pas de cash. Donc la question est : que faites-vous ?

Parce que vous avez toujours tous vos leasings, etc., mais vous n’avez plus de rentrees de cash. La premiere chose que vous pouviez faire etait exactement cela : simplement suspendre les reparations, parce qu’il y a une grosse sortie de cash rien qu’en reparant des pieces unserviceable. Vous pouvez donc cannibaliser votre stock existant et les laisser unserviceable, ce qui, a ce moment-la, etait tres raisonnable : laisser des choses non reparees, parce que, evidemment, si vous n’avez pas de demande, pendant le COVID, 20 % de la flotte vole, cela va reduire tres fortement votre demande de pieces serviceable. Vous arretez simplement, mais vous ne pouvez pas, et c’est encore le probleme, dire simplement : “je ne repare plus.”

Vous avez besoin d’une liste priorisee. Vous devez donc prioriser entre certaines pieces cruciales, qu’il faut quand meme reparer parce que si vous ne les avez pas, cela va vraiment vous mettre en difficulte, et d’autres ou vous avez 10 en stock et cinq unserviceable. Vous savez quoi ? Vous irez bien en prenant un peu plus de risque et en en laissant quelques-unes de plus unserviceable, ou en n’en reparant qu’une.

Donc, meme logique. Oui. Et les turnaround times deviennent encore plus importants. Si vous avez ensuite des timestamps supplementaires, la probabilite de rebut est tres importante la-dedans. Oui, mais meme logique sous-jacente, et oui, nous avons aussi des dashboards pour cela, mais cela mene vers un autre sujet.

Conor Doherty : Tres bien. Ma pensee de cloture est la suivante : si vous deviez resumer, pour boucler la boucle, les points cles que les gens devraient retenir de tout cela, s’ils viennent seulement de nous rejoindre ou s’ils sautent directement a la section Q&A, comment resumeriez-vous l’approche des decisions d’achat, d’investissement et de desinvestissement dans l’aerospace ? Et encore une fois, quels sont les points a retenir ?

Fabian Hoehner : D’abord, ils devraient avoir honte de ne pas avoir tout ecoute. Deuxiemement…

Conor Doherty : Tres bien. Le troisieme pour…

Fabian Hoehner : Je vais donc repeter : appreciez l’incertitude. Cela signifie que l’incertitude existe sous de nombreuses formes, que ce soit les turnaround times, la demande, ou la bill of materials probabiliste. Elle existe partout, et ne la faites pas disparaitre du tableau par simplification. Donc acceptez-la, et il existe une technologie pour mieux le faire.

Ensuite, deuxiemement, priorisez avec les consequences economiques. Dans l’aeronautique, typiquement, la consequence est le gain de taux de service ou l’evitement d’AOG par dollar depense. Ce sont les concepts centraux a retenir. Et que faisons-nous chez Lokad ? Nous avons une plateforme puissante pour le faire, et nous avons de brillants supply chain scientists qui la concoivent avec nos clients. Voila Lokad en quelques mots pour l’aeronautique.

Conor Doherty : Tres bien. Fabi, je n’ai plus d’autres questions. Merci beaucoup de m’avoir rejoint aujourd’hui. C’est un plaisir de vous avoir en studio, et j’espere que tous les autres ont aime ecouter votre voix autant que moi.

Fabian Hoehner : Trop aimable.

Conor Doherty : Vous faites honneur a l’humanite, monsieur.

Fabian Hoehner : Merci.

Conor Doherty : Aucun probleme. Et merci a tous de nous avoir regardes. Merci pour vos commentaires, vos questions.

Un merci special a toutes les personnes a qui j’ai parle au cours du dernier mois environ. Nous avons promu cet evenement pendant a peu pres un mois. J’ai echange avec beaucoup de gens, j’ai demande a beaucoup de personnes : “que vouliez-vous voir ?” Et, comme vous pouvez le voir, j’ai pris les retours et j’ai essaye d’adapter ce que nous avons vu aujourd’hui, ou ce que nous avons montre aujourd’hui, aux attentes du public.

Maintenant, s’il y a des choses que nous n’avons pas couvertes et qui vous interessent vraiment, n’hesitez pas a contacter Fab et moi directement sur LinkedIn. Vous nous voyez clairement. Nous aimons parler. Nous sommes adorables.

Cliquez sur le profil, envoyez-nous un message. Ou, si vous etes deja convaincu et que vous voulez reserver un appel pour en savoir un peu plus, il devrait y avoir un lien dans le chat. Sinon, vous pouvez nous envoyer directement un email a contact@lokad.com. Comme Fabi l’a montre un peu plus tot, il y a d’autres modules dont nous pouvons parler dans l’aerospace.

Nous ne les avons pas couverts aujourd’hui, mais nous reviendrons plus tard pour les traiter. Mais jusqu’a ce jour, il ne reste rien a dire sauf : oui, retournez au travail. Ah, d’accord. S’il vous plait.