Actualizar todo todos los días

Joannes Vermorel

La práctica de Lokad en la gestión de la cadena de suministro es actualizar todas las tuberías de extracción de datos, incluidos los pronósticos, al menos una vez al día, incluso al tratar con cálculos mensuales o trimestrales. Para muchos profesionales, esta práctica puede parecer contraintuitiva. ¿Por qué actualizar los pronósticos trimestrales más de una vez por trimestre? ¿Qué pasa con las inestabilidades numéricas? ¿Qué pasa con la fricción involucrada? Esto va en contra de la mayoría de las prácticas establecidas en la cadena de suministro, especialmente las de las empresas que tienen un proceso de planificación de ventas y operaciones (S&OP) implementado. Sin embargo, una década de experiencia nos ha enseñado que no cumplir con esta práctica de “actualizar todo” es la receta para una corriente interminable de problemas de producción. En el fondo, este problema debe abordarse frontalmente, en profundidad, a través de un diseño versionado y sin estado del software encargado de la optimización predictiva de la cadena de suministro. Este punto se aborda con más detalle a continuación, pero comencemos por analizar más de cerca el problema en sí.

En el mundo del software empresarial, los problemas / fallas / errores / incidencias ocurren todo el tiempo. Esto es especialmente cierto en las cadenas de suministro, donde el panorama de aplicaciones es inevitablemente una colección caótica de piezas de software (ERP, EDI, MRP, WMS, OMS, ecommerce, etc.) reunidas a lo largo de décadas de actividad: cada aplicación es una fuente potencial de problemas, ya que termina interactuando con muchas otras aplicaciones¹. Cada cambio realizado en cualquiera de esas aplicaciones tiene la posibilidad de romper algo en otro lugar, es decir, no solo romper la aplicación en sí. Sin embargo, todas las empresas no son iguales en cuanto a la gestión de su panorama de aplicaciones; sin embargo, más allá de las 1000 empleados, incluso las empresas mejor administradas tienen más de una “falla” en la cadena de suministro impulsada por software al día.

Por lo tanto, las empresas de cierto tamaño se enfrentan a una corriente interminable de problemas de software que deben abordarse. La responsabilidad de resolver dichos problemas varía. La responsabilidad puede recaer en el departamento de TI, un proveedor externo, un equipo operativo, un proveedor, etc. Sin embargo, una vez que se “supone” que se ha solucionado alguno de esos problemas, se necesitan de 5 a 10 rondas² para asegurarse de que el problema realmente se haya solucionado. De hecho, la mayoría de los problemas son casos límite, que pueden o no presentarse en cada momento. Por lo tanto, aunque un problema pueda parecer resuelto porque desapareció después de aplicar una solución de algún tipo, esto aún puede no ser el caso. Las cadenas de suministro son sistemas complejos que involucran muchas piezas interdependientes, algunas de las cuales ni siquiera están bajo el control total de la empresa (es decir, EDI con proveedores). Las personas rutinariamente no logran entregar soluciones definitivas no porque sean perezosas o incompetentes, sino simplemente debido a la complejidad ambiental irreducible.

Como consecuencia, si se ejecuta un pipeline de datos diariamente después de un incidente de producción, se necesitan de 5 a 10 días para que vuelva a la estabilidad. Si el pipeline de datos se ejecuta mensualmente, el mismo proceso de resolución lleva de 5 a 10 meses. Lo que importa son el número de rondas, no el tiempo en el reloj. Se necesitan múltiples rondas para evaluar positivamente que el caso límite se ha abordado. A modo de evidencia anecdótica, en Lokad, tuvimos un error de programación de trabajos relacionado con el cambio de hora que tardó dos años en solucionarse, precisamente porque las condiciones que desencadenaban 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 se pueden reproducir “a voluntad” simplemente aumentando la frecuencia de las “rondas”.

Desafiar constantemente los pipelines de datos de principio a fin es la única forma de asegurarse de que los problemas se solucionen en un plazo razonable. La ejecución infrecuente inevitablemente lleva a que el estado predeterminado del sistema sea “roto”. Las empresas que operan pipelines de datos intermitentes, por ejemplo, trimestrales, inevitablemente terminan con grandes burocracias que solo están allí para revivir el pipeline una vez por trimestre. Peor aún, todo el proceso suele ser tan disfuncional que la burocracia termina pasando la mayor parte del trimestre asegurando la “actualización” del próximo trimestre. Por el contrario, los pipelines en tiempo real, como el servicio de páginas web para el sitio web corporativo, apenas necesitan a alguien para que sigan funcionando.

En Lokad, optamos por las “actualizaciones diarias” (o más) por pura necesidad hace más de una década. Desde entonces, aún no hemos identificado ninguna otra forma de lograr una calidad de servicio decente desde una perspectiva de cadena de suministro. Probablemente no haya ninguna. El análisis predictivo es complejo y, por lo tanto, propenso a “errores” de todo tipo. Las actualizaciones diarias aseguran que los problemas se aborden de manera oportuna en lugar de persistir para siempre en el limbo³. En este sentido, nuestros hallazgos están lejos de ser originales. Netflix fue pionero en el campo completo de la ingeniería del caos 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 empresas de software serias, especialmente las GAFAM, han adoptado enfoques aún más rigurosos.

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

Cuando las previsiones se actualizan con poca frecuencia, resulta muy tentador ajustarlas manualmente. De hecho, las previsiones se estancan la mayor parte del tiempo por diseño, precisamente debido a la falta de actualización frecuente. Así, simplemente echando un vistazo a los datos de ayer, el demand planner puede mejorar una previsión que fue producida por el sistema hace tres semanas. Sin embargo, este trabajo del demand planner no aporta ningún valor añadido duradero para la empresa: no es acumulativo. Si las recetas numéricas que generan las previsiones son tan deficientes que necesitan ajustes manuales, entonces esas recetas numéricas deben corregirse. Si el proveedor de software no puede proporcionar la solución, entonces la empresa necesita un proveedor mejor.

Las actualizaciones frecuentes de las previsiones exacerban las inestabilidades numéricas de los modelos estadísticos subyacentes, es decir, se ejecuta la previsión dos veces y se obtienen dos resultados distintos. Esto es algo bueno⁴. Los modelos numéricos inestables son perjudiciales para la cadena de suministro debido a los efectos de trinquete: una vez que se pasa una orden de producción o una orden de compra, la empresa queda atrapada con las consecuencias de esta orden. Si se pasa una orden, es mejor que sea por mejores razones que una cuestión de inestabilidad numérica. Cuanto antes la empresa elimine las recetas numéricas inestables de su práctica de cadena de suministro, mejor. Intentar ocultar el problema subyacente reduciendo la frecuencia de actualización de las previsiones no tiene sentido: la inestabilidad numérica no desaparece porque la empresa decida dejar de mirarla. Si las recetas numéricas son tan deficientes que no pueden mantener una fuerte consistencia⁵ de un día para otro, se necesitan mejores recetas numéricas. Nuevamente, si un proveedor de software se encuentra en medio del problema y no puede proporcionar una solución profunda, entonces la empresa también necesita un proveedor mejor.

Las actualizaciones diarias de todos los pipelines de datos pueden parecer extravagantes en términos de recursos informáticos. Sin embargo, teniendo en cuenta el hardware informático moderno y el software correctamente diseñado, este costo es pequeño incluso cuando se consideran recetas sofisticadas como la previsión probabilística⁶. Además, las cadenas de suministro se enfrentan rutinariamente a condiciones excepcionales que requieren correcciones a gran escala de inmediato. Si la empresa no puede actualizar todas sus cifras de cadena de suministro en menos de 60 minutos porque es necesario, entonces las emergencias están garantizadas a permanecer sin abordar de vez en cuando, causando estragos en el terreno. La regla de las 5 a 10 rondas -discutida anteriormente- sigue aplicándose: una vez que se descubre una solución, se necesitan múltiples ejecuciones, posiblemente con configuraciones variadas, para ganar confianza en que esta corrección de emergencia está funcionando. Por lo tanto, si el pipeline de datos es demasiado costoso para ejecutarse “a voluntad”, la producción se utilizará como campo de pruebas y se producirá el caos.

Desde una perspectiva de productividad, las actualizaciones diarias eliminan la tolerancia a las configuraciones incorrectas que siguen generando resultados basura. Nuevamente, es algo bueno. No hay razón para ser tolerante con una receta numérica que sigue generando basura. La planificación de la demanda no es una especie de creación artística que desafía el análisis numérico. Las recetas numéricas disfuncionales deben tratarse como errores de software y corregirse en consecuencia. Sin embargo, lograr la corrección profunda a menudo requiere mucho más pensamiento que recurrir a una anulación manual ad hoc. Muchas empresas se preguntan por qué sus equipos de cadena de suministro siguen volviendo a sus hojas de cálculo. Resulta que con frecuencia, las hojas de cálculo son el único lugar donde se implementan las correcciones numéricas, que ya deberían formar parte de los sistemas, precisamente porque iterar rápidamente sobre una hoja de cálculo no es un problema (a diferencia de iterar sobre el sistema empresarial subyacente).

Sin embargo, las actualizaciones diarias (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: estado sin memoria. Un pipeline de datos no debe utilizar ningún dato precalculado y comenzar de nuevo desde los datos transaccionales en bruto cada vez. De hecho, cada error o falla es probable que corrompa los datos precalculados, reteniendo a la empresa durante un período indefinido de tiempo: la lógica puede estar corregida, pero los datos defectuosos permanecen. La solución es sencilla: el pipeline de datos no debe tener ningún estado, es decir, no debe tener datos precalculados de ningún tipo. Comenzar desde cero garantiza que todas las correcciones se aprovechen al máximo.

A su vez, versionar, otro principio de diseño de software y el segundo ingrediente de interés, complementa la ausencia de estado del sistema: más específicamente, la versión de los datos. De hecho, si el propio pipeline de datos no tiene estado, entonces, simplemente combinar la lógica del pipeline, que existe como código fuente versionado, y los datos de entrada debería ser suficiente para reproducir exactamente cualquier problema encontrado durante la ejecución del pipeline. En otras palabras, hace que los problemas sean reproducibles. Sin embargo, lograr esto requiere preservar una copia exacta de los datos tal como estaban durante la ejecución del pipeline de datos. En otras palabras, los datos deben tener una versión junto con el código. La versión de los datos garantiza que las correcciones se puedan probar en las mismas condiciones exactas que desencadenaron el problema en primer lugar.

Lokad ha sido diseñado en torno a estos principios. Promovemos una actualización diaria de extremo a extremo de todo. Nuestros pipelines de datos son sin estado y versionados, tanto la lógica como los datos. ¿Y qué hay de tu empresa?