Back to blog

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 motor de previsión, es decir, lo que hoy puedes ver como un forecasting project en tu cuenta de Lokad. Como resultado, nuestro motor de previsión fue ganando gradualmente un montón de funcionalidades que ni remotamente estaban relacionadas con la estadística. Hace aproximadamente dos años, nuestro motor de previsión 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 de previsión en Excel 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 motor de previsión. 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 de previsión en Excel 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 la previsión que aún residen dentro de nuestro motor de previsión.

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 de previsión en Excel 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 mejor previsión, siendo la última iteración las previsiones probabilísticas, que no pueden ser adaptadas a este informe. Por diseño, este único informe está encasillado en un enfoque legacy de previsión, que desafortunadamente no resulta tan adecuado en lo que se refiere a la optimización de inventarios.

En contraste, combinar previsiones probabilísticas 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 motor de previsión; 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 de previsión en Excel, 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.