Perspectives sur l'évolution technologique de Lokad
La technologie de Lokad a tellement évolué que les personnes ayant eu la chance d’essayer Lokad il y a même deux ans reconnaîtraient à peine l’application telle qu’elle est aujourd’hui.
L’ancien Lokad était entièrement centré autour de notre forecasting engine - c’est-à-dire ce que vous pouvez voir comme un projet de prévision dans votre compte Lokad aujourd’hui. En conséquence, notre forecasting engine a progressivement gagné une multitude de fonctionnalités qui n’ont même pas le moindre rapport avec les statistiques. Il y a environ deux ans, notre forecasting engine était devenu un touche-à-tout responsable de presque tout :
- préparation des données avec la possibilité de gérer une grande diversité de formats de données
- reporting analytics avec un rapport Excel de prévision à la fois assez complexe et assez flexible
- scheduled execution via une intégration webcron ou via l’API
Ensuite, au cours des deux dernières années, nous avons progressivement introduit des alternatives autonomes pour ces fonctionnalités qui résident désormais en dehors de notre forecasting engine. Cependant, qualifier ces nouvelles fonctionnalités de simples replacements n’est pas juste, car ces alternatives sont bien plus puissantes que leurs homologues d’origine.
- Nous pouvons désormais traiter des fichiers très divers, variant en taille, en complexité et même en formats de données. De plus, nous disposons également de nombreux connecteurs de données.
- Les capacités de notre ancien rapport Excel de prévision sont éclipsées par les capacités de reporting plus récentes d’Envision.
- La planification et l’orchestration sont désormais au premier plan, englobant également la récupération de données depuis d’autres applications.
Parce que ces nouvelles fonctionnalités sont clairement supérieures aux anciennes, nous supprimons progressivement the cruft, c’est-à-dire éliminons toutes les choses non liées à la prévision qui résident encore dans notre forecasting engine.
Afin de maintenir le processus fluide, nous migrons progressivement - mais activement - tous nos clients de l’ancien Lokad vers le nouveau Lokad; et lorsqu’une ancienne fonctionnalité n’est plus utilisée, nous la supprimons entièrement.
Le vieux rapport Excel de prévision est un cas difficile pour nous. Le défi n’est pas simplement de dupliquer le rapport lui-même dans Envision (ce qui, à lui seul, n’est pas difficile du tout) - le défi est que la pensée sous-jacente qui a guidé ce rapport est désormais assez dépassée. En effet, au fil des années, Lokad a introduit des technologies de meilleures prévisions - la dernière itération étant prévisions probabilistes - qui ne peuvent pas être intégrées dans ce rapport. Par conception, ce rapport est bloqué avec une approche legacy de la prévision, qui malheureusement n’est pas très adaptée en ce qui concerne l’optimisation de stocks.
En revanche, combiner prévisions probabilistes avec facteurs économiques requiert effectivement plus d’efforts tant du côté de Lokad que du côté des clients, mais les résultats commerciaux n’ont tout simplement pas la même envergure. Le premier consiste à optimiser les pourcentages d’erreur tandis que les seconds optimisent les dollars d’erreur. Sans surprise, une fois que nos clients se rendent compte de l’argent qu’ils laissent sur la table en ne faisant pas ces derniers, ils ne songent plus jamais à revenir aux premiers.
Ensuite, nos intégrations de données subissent actuellement une transformation similaire, et non moins radicale. Lorsque nous avons commencé à développer des connecteurs de données, nous avons essayé de faire correspondre toutes les données que nous récupérions au cadre établi par notre forecasting engine ; c’est-à-dire produire des fichiers tels que Lokad_Items.tsv
, Lokad_Orders.tsv
, etc. Cette approche avait initialement du charme 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 leaky. Toutes les applications ne s’accordent pas sur ce qu’est exactement un product ou une order; il existe une multitude de différences subtiles à prendre en compte, et il était tout simplement impossible de prendre en charge toutes les subtilités commerciales par le biais d’une sorte de normalisation des données.
Ainsi, nous avons commencé à aborder le défi de l’intégration de 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 originaux. L’inconvénient principal de cette approche est qu’elle nécessite davantage d’efforts initiaux pour obtenir des résultats, car les données ne sont pas transformées a priori 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 ne se retrouve pas incapable de tenir compte des subtilités commerciales parce qu’elles ne correspondent pas au framework. Avec un peu de colle programmatique, nous répondons aux besoins commerciaux jusque dans les moindres détails.
De même que pour notre ancien rapport Excel, la transition vers des données natives - contrairement aux données normalisées - suit notre expérience qui indique qu’investir un peu plus pour aligner les chiffres sur l’activité génère beaucoup plus de résultats.