Ideas sobre la evolución tecnológica de Lokad
La tecnología de Lokad ha evolucionado tanto que las personas que tuvieron la oportunidad de probar Lokad incluso hace dos años apenas reconocerían la aplicación tal y como es hoy.
El Lokad “antiguo” estaba completamente centrado en nuestro forecasting engine - es decir, lo que hoy puedes ver como un forecasting project en tu cuenta de Lokad. Como resultado, nuestro forecasting engine fue ganando gradualmente un montón de funcionalidades que ni remotamente estaban relacionadas con la estadística. Hace aproximadamente dos años, nuestro forecasting engine se había convertido en un todoterreno encargado de casi todo:
- data preparation con la posibilidad de acomodar una gran diversidad de formatos de datos
- reporting analytics con un informe Excel forecasting algo complejo y algo flexible
- scheduled execution mediante una integración webcron o a través de la API
Luego, durante los últimos dos años, hemos ido introduciendo gradualmente sustituciones independientes para aquellas funcionalidades que ahora residen fuera de nuestro forecasting engine. Sin embargo, llamar a esas nuevas funcionalidades simples replacements es injusto, ya que esas sustituciones son muchísimo más potentes que sus contrapartes originales.
- Ahora podemos procesar archivos muy diversos, que varían en tamaño, en complejidad e incluso en formatos de datos. Además, contamos también con muchos data connectors.
- Las capacidades de nuestro antiguo informe Excel forecasting son opacadas por las nuevas capacidades de reporting de Envision.
- La programación y orquestación son ahora elementos de primera categoría que también abarcan la recuperación de datos de otras apps.
Debido a que esas nuevas funcionalidades son claramente superiores a las antiguas, estamos eliminando gradualmente the cruft, es decir, eliminando todas aquellas cosas no relacionadas con forecast que aún residen dentro de nuestro forecasting engine.
Para mantener el proceso fluido, estamos migrando gradualmente - pero activamente - a todos nuestros clientes del viejo Lokad al nuevo Lokad; y cuando una funcionalidad antigua ya no se utiliza, la eliminamos por completo.
El antiguo informe Excel forecasting es un caso complicado para nosotros. El desafío no es simplemente duplicar el informe dentro de Envision (eso por sí solo no es difícil en absoluto) - el desafío es que el thinking subyacente que se invirtió en este informe está ahora bastante desfasado. De hecho, a lo largo de los años, Lokad ha introducido tecnologías de better forecasting - siendo la última iteración forecast probabilísticos - que no pueden ser adaptados a este informe. Por diseño, este único informe está encasillado en un enfoque legacy de forecast, que desafortunadamente no resulta tan adecuado en lo que se refiere a la optimización de inventarios.
En contraste, combinar forecast probabilísticos con economic drivers requiere más esfuerzos tanto por parte de Lokad como del cliente, pero los resultados empresariales simplemente no se comparan. Lo primero se trata de optimizar los porcentajes de error, mientras que lo segundo optimiza los dólares de error. No es de extrañar que, una vez que nuestros clientes se den cuenta de cuánto dinero dejan sobre la mesa al no hacer lo segundo, nunca consideren volver a lo primero.
Luego, nuestras integraciones de datos están experimentando actualmente una transformación similar y no menos radical. Cuando empezamos a desarrollar data connectors, intentamos encajar todos los datos que recuperábamos dentro del marco establecido por nuestro forecasting engine; es decir, producir archivos como Lokad_Items.tsv, Lokad_Orders.tsv, etc. Este enfoque resultó inicialmente atractivo porque forzaba una normalization sobre los datos recuperados y procesados por Lokad.
Desafortunadamente, esta abstracción - como todas las abstracciones - is leaky. No todas las apps coinciden en lo que exactamente es un product o un order; hay montones de diferencias sutiles que deben tenerse en cuenta, y simplemente no fue posible acomodar todas las sutilezas del negocio mediante algún tipo de data normalization.
Así, hemos empezado a abordar el desafío de la integración de datos desde otro ángulo: recuperar los datos de la app mientras se preserva lo máximo posible las estructuras y conceptos originales. La principal desventaja de este enfoque es que requiere más esfuerzos iniciales para obtener resultados, ya que los datos no se transforman de antemano para ser compatibles con todas las expectativas predeterminadas de Lokad.
However, debido a que los datos no sufren transformaciones erróneas, también significa que Lokad no se queda atrapado en no poder acomodar las sutilezas del negocio porque no encajan en the framework. Con algo de pegamento programático, acomodamos las necesidades del negocio hasta el más mínimo detalle.
De manera similar a nuestro antiguo informe Excel forecasting, la transición hacia native data - en contraposición a normalized data - sigue nuestra experiencia, la cual indica que invertir un poco más para alinear los números con el negocio produce muchos más resultados.
