Approfondimenti sull'evoluzione tecnologica di Lokad
La tecnologia di Lokad si è evoluta così tanto che chi ha avuto la possibilità di testare Lokad anche solo due anni fa a malapena riconoscerebbe l’app com’è oggi.
Il Lokad “vecchio” era completamente incentrato sul nostro forecasting engine - cioè, su quello che oggi puoi vedere come un forecasting project nel tuo account Lokad. Di conseguenza, il nostro forecasting engine ha gradualmente acquisito una marea di funzionalità non nemmeno lontanamente correlate alla statistics. Circa due anni fa, il nostro forecasting engine era diventato un tuttofare responsabile di quasi tutto:
- data preparation con la possibilità di accogliere una grande diversità di formati di dati
- reporting analytics con un report Excel di previsione alquanto complesso e flessibile
- scheduled execution tramite un’integrazione webcron o tramite l’API
Poi, negli ultimi due anni, abbiamo progressivamente introdotto soluzioni autonome per quelle funzionalità che ora risiedono al di fuori del nostro forecasting engine. Tuttavia, definire queste nuove funzionalità semplici replacements non è giusto, perché esse sono di gran lunga più potenti dei loro equivalenti originali.
- Ora possiamo elaborare file molto diversi, variabili per dimensione, complessità e persino per formati di dati. Inoltre, disponiamo anche di numerosi data connectors.
- Le capacità del nostro vecchio report Excel di previsione sono messe in ombra dalle nuove funzionalità di reporting di Envision.
- La pianificazione e l’orchestrazione sono ormai elementi di prima classe che comprendono anche il recupero dei dati da altre app.
Poiché queste nuove funzionalità sono nettamente superiori a quelle vecchie, stiamo progressivamente eliminando the cruft, cioè tutte quelle parti non correlate alle previsioni che ancora risiedono all’interno del nostro forecasting engine.
Per mantenere il processo fluido, stiamo progressivamente - ma attivamente - migrando tutti i nostri clienti dal vecchio Lokad al nuovo Lokad; e quando una funzionalità vecchia non viene più utilizzata, la rimuoviamo del tutto.
Il vecchio report Excel di previsione è un caso complicato per noi. La sfida non consiste nel duplicare semplicemente il report stesso all’interno di Envision (ciò di per sé non è affatto difficile) - la sfida è che il thinking sottostante che ha guidato questo report è ormai piuttosto superato. Infatti, nel corso degli anni, Lokad ha introdotto tecnologie di better forecasting - l’ultima iterazione sono le probabilistic forecasts - che non possono essere adattate a questo report. Per progettazione, questo report è legato a un approccio legacy alla previsione, che purtroppo non risulta particolarmente adatto all’ottimizzazione dell’inventario.
Al contrario, combinare le probabilistic forecasts con i economic drivers richiede sicuramente maggiori sforzi sia da parte di Lokad sia da parte dei clienti, ma i risultati commerciali semplicemente non sono paragonabili. Il primo riguarda l’ottimizzazione dei percents of error mentre il secondo ottimizza i dollars of error. Non sorprende che, una volta che i nostri clienti si rendano conto di quanti soldi lasciano sul tavolo non adottando quest’ultimo, non considerino mai di tornare al primo approccio.
Successivamente, le nostre integrazioni dati stanno attualmente subendo una trasformazione simile, e non meno radicale. Quando abbiamo iniziato a sviluppare i data connectors, abbiamo cercato di incasellare tutti i dati raccolti nel quadro di riferimento stabilito dal nostro forecasting engine; ovvero, producendo file come Lokad_Items.tsv, Lokad_Orders.tsv, ecc. Questo approccio era inizialmente allettante perché imponeva una normalization sui dati raccolti e processati da Lokad.
Sfortunatamente, questa astrazione - come tutte le astrazioni - is leaky. Non tutte le app concordano su cosa sia esattamente un product o un order; ci sono innumerevoli sottili differenze da considerare, e semplicemente non è stato possibile accogliere tutte le sottigliezze del business attraverso una sorta di data normalization.
Pertanto, abbiamo iniziato ad affrontare la sfida dell’integrazione dei dati da un’altra angolazione: recuperare i dati dell’app preservando il più possibile le strutture e i concetti originali. Il principale svantaggio di questo approccio è che richiede maggiori sforzi iniziali per ottenere risultati, poiché i dati non vengono trasformati in anticipo per essere compatibili con tutte le aspettative predefinite di Lokad.
However, poiché i dati non subiscono trasformazioni errate, ciò significa anche che Lokad non rimane bloccata nell’incapacità di gestire le sottigliezze del business perché non rientrano the framework. Con un po’ di “glue” programmatico, soddisfiamo le esigenze aziendali fino ai minimi dettagli.
Analogamente al nostro vecchio report Excel, la transizione verso native data - in opposizione a normalized data - segue la nostra esperienza, che indica che investire a little more per allineare i numeri al business produce a lot more results.
