Aperçu de l'évolution technologique de Lokad

Joannes Vermorel

La technologie de Lokad a tellement évolué que les personnes qui ont eu la chance d’essayer Lokad il y a seulement deux ans à peine reconnaîtraient à peine l’application telle qu’elle est aujourd’hui.

L’ancien Lokad était entièrement centré autour de notre moteur de prévision - c’est-à-dire ce que vous pouvez voir comme un projet de prévision dans votre compte Lokad aujourd’hui. En conséquence, notre moteur de prévision a progressivement acquis de nombreuses fonctionnalités qui n’ont même pas de rapport lointain avec les statistiques. Il y a environ deux ans, notre moteur de prévision était devenu un couteau suisse responsable de presque tout :

• préparation des données avec la possibilité de prendre en charge une grande diversité de formats de données
• analyse de rapports avec un rapport de prévision Excel quelque peu complexe et flexible
• exécution planifiée via une intégration webcron ou via l’API

Ensuite, au cours des deux dernières années, nous avons progressivement introduit des remplacements autonomes pour ces fonctionnalités qui vivent maintenant en dehors de notre moteur de prévision. Cependant, qualifier ces nouvelles fonctionnalités de simples remplacements est injuste, car ces remplacements sont bien plus puissants que leurs homologues d’origine.

• Nous pouvons maintenant traiter des fichiers très divers, de tailles variables, de complexité variable et même de formats de données différents. De plus, nous disposons de nombreux connecteurs de données.
• Les capacités de notre ancien rapport de prévision Excel sont éclipsées par les nouvelles capacités de reporting d’Envision.
• La planification et l’orchestration sont désormais des éléments essentiels qui englobent également la récupération de données à partir d’autres applications.

Étant donné que ces nouvelles fonctionnalités sont nettement supérieures aux anciennes, nous éliminons progressivement les éléments superflus, c’est-à-dire toutes les fonctionnalités non liées à la prévision qui se trouvent encore dans notre moteur de prévision.

Afin de rendre le processus fluide, nous migrons progressivement - mais activement - tous nos clients de l’ancien Lokad vers le nouveau Lokad ; et lorsque une ancienne fonctionnalité n’est plus utilisée, nous la supprimons complètement.

L’ancien rapport de prévision Excel pose un problème difficile pour nous. Le défi n’est pas de simplement dupliquer le rapport lui-même dans Envision (cela seul n’est pas du tout difficile) - le défi réside dans le fait que la réflexion sous-jacente qui a été intégrée à ce rapport est maintenant assez dépassée. En effet, au fil des années, Lokad a introduit de meilleures technologies de prévision - la dernière itération étant les prévisions probabilistes - qui ne peuvent pas être intégrées à ce rapport. Par conception, ce rapport est bloqué avec une approche héritée de la prévision, qui malheureusement ne convient pas vraiment à l’optimisation des stocks.

En revanche, combiner les prévisions probabilistes avec les moteurs économiques nécessite plus d’efforts tant du côté de Lokad que du côté du client, mais les résultats commerciaux ne sont tout simplement pas comparables. Le premier consiste à optimiser les pourcentages d’erreur, tandis que le second optimise les dollars d’erreur. Sans surprise, une fois que nos clients réalisent combien d’argent ils laissent sur la table en n’optant pas pour la seconde option, ils ne considèrent jamais revenir à la première.

Ensuite, nos intégrations de données sont actuellement en train de subir une transformation similaire, et tout aussi radicale. Lorsque nous avons commencé à développer des connecteurs de données, nous avons essayé d’adapter toutes les données que nous récupérions au cadre établi par notre moteur de prévision ; c’est-à-dire produire des fichiers tels que Lokad_Items.tsv, Lokad_Orders.tsv, etc. Cette approche était initialement attrayante car elle imposait une normalisation des données récupérées et traitées par Lokad.

Malheureusement, cette abstraction - comme toutes les abstractions - est imparfaite. Toutes les applications ne s’accordent pas sur ce qu’est exactement un produit ou une commande ; il y a des tonnes de différences subtiles à prendre en compte, et il n’était tout simplement pas possible de tenir compte de toutes les subtilités commerciales grâce à une sorte de normalisation des données.

Ainsi, nous avons commencé à aborder le défi de l’intégration des données sous un autre angle : récupérer les données de l’application tout en préservant autant que possible les structures et concepts d’origine. Le principal inconvénient de cette approche est qu’elle nécessite plus d’efforts initiaux pour obtenir des résultats, car les données ne sont pas transformées à l’avance pour être compatibles avec toutes les attentes par défaut de Lokad.

Cependant, parce que les données ne subissent pas de transformations erronées, cela signifie également que Lokad n’est pas bloqué dans sa capacité à prendre en compte les subtilités commerciales parce qu’elles ne correspondent pas au cadre. Avec un peu de programmation, nous répondons aux besoins commerciaux jusqu’aux moindres détails.

De la même manière que notre ancien rapport Excel, la transition vers les données natives - par opposition aux données normalisées - suit notre expérience qui indique qu’investir un peu plus pour aligner les chiffres avec l’activité génère beaucoup plus de résultats.