Sobre la complejidad accidental de los sistemas de la cadena de suministro

Joannes Vermorel

El hardware informático moderno es extremadamente capaz. Un modesto teléfono inteligente ofrece miles de millones de FLOPS (operaciones de punto flotante por segundo) mientras almacena cientos de gigabytes de datos. Un solo teléfono inteligente podría técnicamente ejecutar una asignación de inventario predictiva para una red minorista muy grande. Los datos históricos requerirían una representación adecuada¹ y en el lado del procesamiento de datos, se tendrían que utilizar técnicas más eficientes como la programación diferenciable. Por lo tanto, los sistemas de cadena de suministro de alto rendimiento deberían ser algo obvio. Seguramente, las empresas pueden permitirse algo mejor que un teléfono inteligente para ejecutar y optimizar sus cadenas de suministro. Sin embargo, una observación casual de los sistemas de cadena de suministro de nuestros clientes en Lokad indica lo contrario: estos sistemas casi siempre son lentos y con frecuencia tortuosos.

Los líderes actuales en software de cadena de suministro (ERP, WMS, MRP, etc.) tienen dificultades para mantener incluso 1 solicitud por segundo en su backend de API. En Lokad, se nos recuerda dolorosamente estas actuaciones horribles a diario, ya que estamos en la primera línea del proceso de recuperación de datos. Para una docena de clientes aproximadamente, la recuperación inicial de datos tomó casi un mes². La lentitud de las diversas APIs representa el 99.9% del problema. Son pocos los sistemas capaces de mantener 1MB/segundo para su extracción de datos. Los sistemas que no nos obligan a extraer innecesariamente los mismos datos una y otra vez, para llegar a las partes más recientes, son aún más raros. Estos sistemas suelen tener más de 100 recursos informáticos a su disposición en comparación con lo que tenían hace 2 décadas, y sin embargo, no son fundamentalmente más rápidos³ ni hacen las cosas radicalmente mejor. Algunos de los proveedores más progresistas que aprovechan la computación en memoria requieren varios terabytes de RAM para manejar redes minoristas, lo cual es una cantidad sorprendentemente grande⁴ de RAM considerando lo que se está haciendo con esos recursos.

Esta “complejidad accidental” de muchos (¿la mayoría?) de los sistemas de cadena de suministro se puede atribuir a dos causas fundamentales: en primer lugar, expectativas incorrectas sobre el progreso del hardware informático en sí, y en segundo lugar, una falta de cuidado en el diseño interno de la solución.

En cuanto al progreso del hardware informático, hasta hace una década, no había una sola empresa (grande) donde no se hubiera mencionado la primera ley de Moore docenas de veces (generalmente de manera incorrecta). Existía la sensación de que las computadoras se estaban volviendo ridículamente más rápidas todo el tiempo. Desafortunadamente, esto dejó de ser trivialmente cierto desde principios de la década de 2000. Esta perspectiva incorrecta de un progreso indefinido llevó a muchas empresas de software, mucho más allá del mundo de la cadena de suministro, a cometer errores masivos. Muchos de los problemas asociados con Windows Vista (lanzado en 2006) se podían atribuir a las expectativas originales, en 2001 cuando se lanzó Windows XP, de los ingenieros de Microsoft de que las CPU tendrían una velocidad de reloj de 6Ghz para 2006. Estamos llegando al final de 2020 y las CPU de juegos de alta gama apenas alcanzan los 5Ghz. El hardware informático nunca dejó de progresar; sin embargo, simplemente dejó de progresar de manera trivial, al menos en lo que respecta a las empresas de software.

En la década de 1980 y 1990, tan pronto como un software funcionaba, incluso si era algo lento en la fecha de lanzamiento, se daba por sentado que al año siguiente su velocidad sería decente y al siguiente año sería excelente. Empresas de software agresivas como Microsoft jugaron muy bien esta carta: sus ingenieros recibían (y aún reciben) el mejor hardware informático que el dinero puede comprar, y sistemáticamente empujaban el rendimiento del software hasta el límite de lo que seguía siendo aceptable, sabiendo que el hardware esencialmente resolvería el problema de rendimiento en uno o dos años. Después del desastre de Vista, los equipos de ingeniería de Microsoft se dieron cuenta de la magnitud del problema y cambiaron su enfoque, siendo Windows 7 una mejora importante. Sin embargo, pasaron diez años para que Windows se recuperara realmente en cuanto al rendimiento. Hoy en día, la perspectiva es casi exactamente lo contrario: los mejores equipos de Microsoft ya no confían en el hardware futuro y se centran casi exclusivamente en ofrecer un rendimiento superior inmediato a través de un software superior⁵.

Sin embargo, el mundo del software empresarial resultó ser mucho más lento en darse cuenta del problema y siguió construyendo software durante la década de 2010 como si el hardware informático futuro estuviera a punto de resolver todos sus problemas, como había sucedido muchas veces en el pasado. Desafortunadamente, para la mayoría de los proveedores de software empresarial, si bien el hardware informático sigue progresando, hace una década dejó de progresar de manera trivial⁶ donde el proveedor simplemente puede esperar a que ocurra el rendimiento. El software tiende a acumular basura con el tiempo (más funciones, más opciones, más pantallas, etc.). Por lo tanto, la tendencia natural del software complejo es volverse más lento con el tiempo, no mejorar, a menos que haya un esfuerzo dedicado intenso en este sentido.

Lamentablemente, desde una perspectiva de ventas, el rendimiento es en su mayoría un problema secundario. Las demostraciones se realizan con cuentas de prueba que solo incluyen una fracción ínfima de la carga de trabajo de datos a la que se enfrentaría el sistema en producción. Además, las pantallas de interés para la alta dirección reciben una cantidad desproporcionada de atención en comparación con las destinadas a los empleados de la empresa. Sin embargo, estas últimas son precisamente las pantallas que se utilizarán miles de veces al día y, por lo tanto, las que merecen más atención. Sospecho que las API a menudo ofrecen un rendimiento terrible porque pocos compradores investigan si las API realmente ofrecen un rendimiento alineado con su propósito previsto. Los proveedores de software saben esto y alinean sus inversiones en ingeniería en consecuencia.

Esto me lleva al segundo aspecto del problema de rendimiento: la falta de atención al diseño interno de la solución. En la actualidad, se requieren decisiones estratégicas de diseño de software para aprovechar la mayor parte de las mejoras continuas del hardware. Sin embargo, una decisión de diseño es una espada de doble filo: empodera pero también limita. Se necesita un liderazgo sólido para comprometerse tanto en el aspecto empresarial como en el técnico con una decisión de diseño. La indecisión es más fácil, pero por otro lado, como ilustra la gran mayoría del software empresarial, el rendimiento (y la experiencia de usuario en general) sufre mucho.

Una trampa del software moderno (no solo del empresarial) es la sobreabundancia de capas. Los datos se copian, se canalizan, se agrupan, se sincronizan, … a través de docenas de capas internas dentro del software. Como resultado, la mayor parte de los recursos informáticos se desperdician lidiando con la “fontanería interna”, que en sí misma no aporta ningún valor añadido. En términos de diseño, la solución es tanto simple de concebir como difícil de ejecutar: se debe hacer un uso frugal de los componentes de terceros, especialmente aquellos que implican una capa de algún tipo⁷. Desde la perspectiva de un proveedor de software, agregar una capa más es la forma más rápida de agregar más “funciones geniales” al producto, sin importar el exceso de peso.

En Lokad, hemos optado por una pila de integración extensiva al diseñar toda nuestra plataforma en torno a un núcleo compilador. Por otro lado, perdemos la opción de conectar fácilmente cualquier proyecto de código abierto al diseño. Las integraciones siguen siendo posibles, pero generalmente requieren cambios más profundos en el propio compilador. Por otro lado, logramos un rendimiento “a nivel de hardware” que generalmente se considera impensable en lo que respecta al software empresarial. En general, considerando que los componentes de código abierto están envejeciendo mal, este enfoque ha demostrado ser particularmente efectivo en la última década⁸.

La multi-tenencia mutualizada es otra elección de diseño que impacta radicalmente el rendimiento, al menos desde una perspectiva de “relación calidad-precio”. La mayoría del software empresarial, incluido el software de cadena de suministro, tiene requisitos de recursos informáticos altamente intermitentes. Por ejemplo, en el extremo más extremo del espectro, tenemos la receta numérica de pronóstico, que se ejecuta solo una vez al día (más o menos), pero tiene que procesar todos los datos históricos cada vez. Tener un conjunto estático de recursos informáticos⁹ dedicados a un cliente es altamente ineficiente.

Nuevamente, en Lokad, hemos optado por una infraestructura completamente mutualizada. Este enfoque reduce nuestros costos operativos en la nube al tiempo que ofrece un rendimiento que de otra manera no sería económicamente viable (los costos en la nube superarían los beneficios de la cadena de suministro). Para garantizar una orquestación general fluida de todas las cargas de trabajo, hemos diseñado un alto grado de “previsibilidad” para nuestro propio consumo de recursos informáticos. El DSL (lenguaje de programación específico del dominio) de Lokad, llamado Envision, ha sido diseñado para respaldar esta tarea. Es por eso que no existen clases completas de construcciones de programación, como bucles arbitrarios, en Envision: esas construcciones no son compatibles con los requisitos de “alta previsibilidad” que implica el procesamiento de datos de la cadena de suministro.

En conclusión, no espere que un sistema de cadena de suministro obeso se ponga en forma en poco tiempo si aún no lo está. Si bien el hardware informático sigue progresando, ya es bastante rápido. Si el sistema es lento, lo más probable es que sea porque se enfrenta a su hardware subyacente, no porque el hardware sea insuficiente. Solucionar el problema es posible, pero en su mayoría es una cuestión de diseño. Desafortunadamente, el diseño del software central es una de las cosas que tiende a ser casi imposible de solucionar en el software empresarial después de la etapa de diseño del producto. Sin embargo, es posible recuperarse, como lo demuestra Microsoft, pero no todas las empresas (tanto proveedores como clientes) pueden permitirse la década que lleva hacerlo.