Refrescar todo cada día

Joannes Vermorel

La supply chain practice de Lokad es refrescar todas las data pipelines - forecast incluidos - al menos una vez al día, incluso cuando se trata de cálculos mensuales o trimestrales. Para muchos profesionales, esta práctica puede parecer contraintuitiva. ¿Por qué refrescar forecast trimestrales más de una vez por trimestre? ¿Qué sucede con las inestabilidades numéricas? ¿Y la fricción involucrada? Esto va en contra de la mayoría de las prácticas de supply chain establecidas, especialmente aquellas de las empresas que cuentan con un proceso de S&OP implementado. Sin embargo, una década de experiencia nos ha enseñado que no cumplir con esta práctica de “refresh all the things” es la receta para una interminable serie de problemas de producción. En esencia, este problema debe abordarse de forma frontal y en profundidad a través de un diseño sin estado versionado del software encargado de la predictive optimization de la supply chain. Este punto se revisita con mayor detalle en lo que sigue, pero comencemos observando de cerca el problema en sí.

En el mundo del enterprise software, los problemas / fallos / bugs / incidencias ocurren todo el tiempo. Esto es especialmente cierto para las supply chains donde el applicative landscape es invariablemente una colección azarosa de piezas de software (ERP, EDI, MRP, WMS, OMS, ecommerce, etc.) ensambladas a lo largo de décadas de actividad: cada app es una fuente potencial de problemas ya que termina interactuando con muchas otras apps¹. Cada cambio realizado en cualquiera de esas apps tiene la posibilidad de romper algo en otro lugar, es decir, no se trata solo de romper la app en sí. No todas las empresas son iguales en lo que respecta a la gestión de su landscape aplicativa; sin embargo, más allá de los 1000 empleados, incluso las compañías mejor gestionadas sufren más de un “glitch” en la supply chain impulsado por software cada día.

Así, las empresas de cierto tamaño enfrentan una serie interminable de problemas de software que deben ser solucionados. La responsabilidad de resolver tales problemas varía. Puede recaer en el departamento de IT, en un proveedor externo, en un equipo operativo, en un proveedor, etc. Sin embargo, una vez que cualquiera de esos problemas se supone que ha sido solucionado, se requieren de 5 a 10 rounds² para asegurarse de que el problema realmente esté solucionado. De hecho, la mayoría de los problemas son casos atípicos, que pueden o no presentarse en cada ocasión. Así, aunque un problema pueda parecer resuelto por haber desaparecido tras aplicar una solución de algún tipo, es posible que aún no lo esté. Las supply chains son sistemas complejos que involucran muchas piezas interdependientes, algunas de las cuales ni siquiera están bajo el control total de la empresa (por ejemplo, EDI con proveedores). La gente falla rutinariamente en entregar soluciones definitivas no porque sea perezosa o incompetente, sino simplemente debido a la complejidad ambiental irreducible.

Como consecuencia, si una data pipeline se ejecuta diariamente tras un incidente de producción, se necesita de 5 a 10 días para volver a la estabilidad. Si la data pipeline se ejecuta mensualmente, el mismo proceso de resolución toma 5 a 10 meses. Es el número de rounds lo que importa, no el tiempo en reloj. Se requieren múltiples rounds para evaluar de manera positiva que el caso atípico ha sido abordado. Como evidencia anecdótica, en Lokad tuvimos un bug en la programación de tareas relacionado con el cambio de hora que tomó dos años en solucionarse, precisamente porque las condiciones que activaban el problema eran tan raras - dos veces al año por zona horaria. Sin embargo, aunque ciertos problemas - como los cambios de hora - son inherentemente infrecuentes, la mayoría de los problemas pueden reproducirse “a voluntad” simplemente aumentando la frecuencia de los “rounds”.

Poner a prueba constantemente las data pipelines end-to-end es la única manera de asegurar que los problemas se solucionen en un plazo razonable. La ejecución infrecuente conduce invariablemente a que el estado predeterminado del sistema sea roto. Las compañías que operan data pipelines intermitentes - por ejemplo, trimestrales - terminan invariablemente con grandes burocracias que existen únicamente para revivir la pipeline una vez por trimestre. Peor aún, todo suele ser tan disfuncional que la burocracia termina dedicando la mayor parte del trimestre a asegurar el “refresh” del siguiente trimestre. Por el contrario, las pipelines en tiempo real - como las que atienden las páginas web del sitio corporativo - apenas requieren de alguien para mantenerlas operativas.

En Lokad, optamos por daily refreshes (o más) por pura necesidad hace más de una década. Desde entonces, aún no hemos identificado otra forma de lograr una calidad de servicio decente desde la perspectiva de supply chain. Probablemente no exista ninguna. La analítica predictiva es compleja y, por lo tanto, propensa a “bugs” de todo tipo. Los daily refreshes aseguran que los problemas se aborden de manera pronta en lugar de permanecer indefinidamente en limbos³. En este sentido, nuestros hallazgos están lejos de ser originales. Netflix fue pionero en todo el campo de chaos engineering siguiendo líneas de pensamiento similares: para diseñar un sistema robusto, se debe aplicar estrés; sin estrés, la robustez nunca se incorpora a la mentalidad de ingeniería. La mayoría de las compañías de software serias - especialmente los GAFAM - han adoptado enfoques incluso más estrictos de este método.

Además, los refreshes infrecuentes de las data pipelines no solo conducen a problemas de producción desde una perspectiva específica de supply chain, sino que también enfatizan una serie de malas prácticas y malas tecnologías.

Siempre que los forecast se refrescan de manera infrecuente, se vuelve sumamente tentador ajustarlos manualmente. De hecho, los forecast se quedan estancados la mayor parte del tiempo por diseño, precisamente debido al refresh infrecuente. Así, con solo echar un vistazo a los datos de ayer, el Supply Chain Scientist puede mejorar un forecast que fue producido por el sistema hace tres semanas. Sin embargo, este trabajo del Supply Chain Scientist no aporta ningún valor añadido duradero para la empresa: no es acumulativo. Si las numerical recipes que generan el forecast son tan deficientes que necesitan ajustes manuales, entonces esas numerical recipes deben ser arregladas. Si el proveedor de software no puede entregar la solución, entonces la empresa necesita un proveedor mejor.

Los refreshes frecuentes de forecast exageran las inestabilidades numéricas de los modelos estadísticos subyacentes, es decir, ejecutar el forecast dos veces y obtener dos resultados distintos. Esto es a good thing⁴. Los modelos numéricos inestables son perjudiciales para la supply chain debido a efectos de cremallera: una vez que se pasa una orden de producción o una orden de compra, la empresa queda atrapada con las consecuencias de esa orden. Si se pasa una orden, es preferible que sea por mejores razones que por una cuestión de inestabilidad numérica. Cuanto antes la empresa elimine las numerical recipes inestables de su supply chain practice, mejor. Intentar ocultar el problema subyacente reduciendo la frecuencia del refresh de forecast es absurdo: la inestabilidad numérica no desaparece porque la empresa decide dejar de prestarle atención. Si las numerical recipes son tan deficientes que no pueden mantener una consistencia fuerte⁵ de un día para otro, se necesitan numerical recipes mejores. Nuevamente, si un proveedor de software se encuentra en medio del problema y no puede entregar una deep fix, entonces la empresa también necesita un proveedor mejor.

Los daily refreshes de todas las data pipelines pueden parecer extravagantes en términos de recursos computacionales. Sin embargo, considerando el hardware computacional moderno y un software diseñado adecuadamente, este costo es pequeño incluso al considerar recetas sofisticadas como el forecast probabilístico⁶. Además, las supply chains se enfrentan rutinariamente a condiciones excepcionales que requieren una corrección inmediata a gran escala. Si la empresa no puede refrescar todas sus cifras de supply chain en menos de 60min cuando es necesario, entonces se garantiza que las emergencias quedarán sin atender de vez en cuando, causando estragos en el terreno. La regla de 5 a 10 rounds - discutida previamente - aún se aplica: una vez que se descubre una solución, se requieren múltiples ejecuciones - posiblemente con ajustes variados - para tener la confianza de que esta corrección de emergencia está funcionando. Así, si la data pipeline es demasiado costosa para ejecutarse “a voluntad”, la producción se utilizará como testing grounds y se desatará el caos.

Desde una perspectiva de productividad, los daily refreshes eliminan la tolerancia a configuraciones deficientes que siguen generando resultados basura. Nuevamente, es a good thing. No hay razón para ser tolerante con una numerical recipe que sigue generando basura. La planificación de la demanda no es una especie de creación artística que desafíe el análisis numérico. Las numerical recipes disfuncionales deben ser tratadas como software bugs y solucionadas en consecuencia. Sin embargo, ofrecer una deep fix frecuentemente requiere mucha más reflexión que recurrir a un ajuste manual ad hoc. La mayoría de las empresas se preguntan por qué sus equipos de supply chain siguen recurriendo a sus spreadsheets. Resulta que, frecuentemente, las spreadsheets son el único lugar donde las correcciones numéricas - que ya deberían formar parte de los sistemas - se implementan, precisamente porque iterar rápidamente sobre una spreadsheet no es un problema (a diferencia de iterar sobre el sistema empresarial subyacente).

Sin embargo, los daily refreshes (o más) son solo un aspecto operativo del problema. En términos de diseño de software, este enfoque debe complementarse con un primer ingrediente clave: statelessness. Una data pipeline no debería usar datos precomputados y comenzar de nuevo a partir de los datos transaccionales sin procesar cada vez. De hecho, cada bug o fallo podría corromper los datos precomputados, retrasando a la empresa por un período indefinido: la lógica puede ser corregida pero los datos defectuosos permanecen. La solución es sencilla: la data pipeline no debe tener ningún estado, es decir, no debe haber datos precomputados de ningún tipo. Comenzar de cero asegura que todas las correcciones se aprovechen de inmediato en la mayor medida posible.

A su vez, el versioning, otro principio de diseño de software y segundo ingrediente de interés, complementa la statelessness del sistema: más específicamente, el data versioning. De hecho, si la data pipeline en sí no tiene estado, entonces, combinar simplemente la lógica de la pipeline - que existe como código fuente versioned - y los datos de entrada debería ser suficiente para reproducir exactamente cualquier problema encontrado durante la ejecución de la pipeline. En otras palabras, hace que los problemas sean reproducible. Sin embargo, lograr esto requiere preservar una copia exacta de los datos tal como estaban durante la ejecución de la data pipeline. Dicho de otro modo, los datos deben versionarse junto al código. El data versioning asegura que las correcciones puedan probarse en las mismas condiciones exactas que desencadenaron el problema en primer lugar.

Lokad ha sido diseñado en torno a estos principios. Promovemos un daily refresh end-to-end de todo. Nuestras data pipelines son stateless y versioned, tanto en la lógica como en los datos. ¿Qué hay de tu empresa?