La resiliencia de la cadena de suministro requiere ancho de banda

Joannes Vermorel

Los últimos años no han sido amables con las cadenas de suministro. De hecho, lo único que no ha escaseado son las fuerzas de interrupción: confinamientos, guerras, inflación, etc. Como resultado, ha surgido un nuevo interés en las cadenas de suministro ‘resilientes’. Naturalmente, los sospechosos habituales: consultores, profesores y proveedores de software (incluido el que suscribe) han estado ocupados buscando ‘soluciones’ que, al menos, mitiguen el impacto de esas interrupciones y, en el mejor de los casos, eliminen por completo ciertas clases de interrupciones. Sin embargo, mis observaciones informales indican que esas ‘soluciones’, sin importar su supuesto mérito, suelen ser poco más que deseos piadosos.

De hecho, durante la última década, he observado que la mayoría de los directores de cadena de suministro y sus equipos ya están abrumados por microcrisis, incluso durante períodos en su mayoría carentes de cualquier tipo de interrupción a gran escala. Por lo tanto, la mayoría de las divisiones de cadena de suministro no tienen el lujo de pensar siquiera en la gestión de crisis (o cualquier tipo de plan estratégico a gran escala): están completamente comprometidas en apagar un flujo interminable de incendios.

Hace algunas décadas, la industria del software acuñó un término para referirse a este problema: falta de ancho de banda, cuando la dirección ni siquiera puede permitirse pensar en otro problema porque su atención está dispersa en demasiados problemas. Lo que hace que el concepto de ancho de banda sea relevante tanto para el software como para la cadena de suministro es que, en ambas situaciones, la respuesta corporativa habitual a una carga de trabajo excesiva, es decir, agregar más personal al caso, no funciona. Esta es la esencia de la Ley de Brooks: añadir más personal a un proyecto de software que ya está retrasado solo sirve para retrasarlo aún más. En la industria del software, que presume de algunas de las empresas más rentables que han operado en mercados libres, este problema de ancho de banda es muy desafiante. Aunque la empresa pueda ser lo suficientemente rentable como para duplicar la fuerza laboral y su gestión, no haría una mella en el problema [^problema].

Quizás sorprendentemente (o tal vez no), la causa raíz de este flujo interminable de microcrisis en la cadena de suministro es casi exclusivamente el software. Contrariamente a la intuición, no es la guerra en Ucrania o la posibilidad de tener otra en Asia lo que agota el ancho de banda de la división de la cadena de suministro, sino problemas que podrían calificarse mejor como “totalmente anecdóticos”, como la falta de sincronización entre el WMS y el ERP (… nuevamente); o hacer política con TI para obtener un campo personalizado adicional en la base de datos para los stocks “reservados” ¹; o perseguir pronósticos totalmente irrazonables entregados por el proceso de S&OP.

En una galería de software que agota el ancho de banda, los productos analíticos son, con mucho, los peores infractores. Estas herramientas, especialmente las de planificación, a menudo requieren no solo una gran cantidad de personal para operar, sino que también generan sus propias mini burocracias. Como resultado, la gestión de la cadena de suministro soluciona problemas relacionados con el software, además de solucionar problemas relacionados con el proceso generados por la burocracia misma. Este proceso se vuelve frustrantemente reflexivo y desperdicia cada vez más ancho de banda.

Lokad, al ser parte de este ecosistema de software analítico, no es inmune a este problema. Hace años, sin embargo, desarrollamos el antídoto a través del cuarto punto de nuestro manifiesto ²: Estar en control requiere la automatización de cada tarea mundana. Nos dimos cuenta de que había un delicado equilibrio entre la gestión y la optimización. Por ejemplo, si generar las órdenes diarias de compra/producción consume todo el presupuesto de ancho de banda de la división de la cadena de suministro, eso no deja nada en las arcas para la mejora (en términos de resiliencia o cualquier otra cosa).

Por el contrario, si todas las tareas mundanas están completamente automatizadas, esto libera una gran cantidad de ancho de banda de la organización de la cadena de suministro. Sin embargo, este proceso lleva tiempo. No es casualidad que cuando Lokad comienza a trabajar para un cliente, generalmente nos lleva alrededor de un año antes de poder enfocarnos directamente en cualquier tema que se considere estratégico (como la resiliencia). Lokad no solo tiene que llegar a la producción (lo que lleva aproximadamente 6 meses), sino que la organización también debe aprender a renunciar al control de todos los procesos que ahora se han automatizado (lo que requiere otros 6 meses, más en organizaciones más grandes).

Al automatizar las decisiones mundanas, sin embargo, los equipos de la cadena de suministro recuperan algo que generalmente perdieron hace décadas cuando su organización se digitalizó: la capacidad de elegir sus batallas. Este es probablemente el beneficio más importante de la automatización, superando los ahorros de productividad. No estoy diciendo que la transición a una cadena de suministro digital en los años 80 y 90, operada a través de una colección de ERPs, MRPs y APSs, no fuera el movimiento correcto. En pocas palabras, si bien este camino digital era necesario, vino con graves desventajas: las empresas (de libre mercado) nunca han estado tan arraigadas en su propio panorama aplicativo, donde las migraciones y actualizaciones generalmente se miden en años. Muchas cadenas de suministro han estado inmersas en su “lucha contra incendios digitales” durante tanto tiempo que pocos empleados recuerdan cómo comenzar el día de trabajo sin una corriente interminable de alertas, excepciones y problemas. Esto sin mencionar la correspondiente corriente interminable de reuniones para abordar dichas alertas, excepciones y problemas. Todos estos procesos tienen costos en términos de ancho de banda, y la cuenta mental siempre está en marcha.

A modo de evidencia anecdótica, consideremos que en menos de 5 años (1903 a 1908), Henry Ford pasó de la nada al Modelo T. Ford revolucionó la producción industrial, introduciendo más de una docena de modelos en el proceso (Modelo A, Modelo B, Modelo C, etc.), todo mientras manejaba una oferta y demanda en constante cambio. Ford tampoco la tuvo fácil: el Pánico de 1907 fue una de las mayores y más graves crisis financieras de todos los tiempos. Hoy en día, dada una “rutina empresarial”, muchas (¿la mayoría?) de las empresas ni siquiera pueden finalizar la actualización de su ERP.

Por lo tanto, para ser resiliente, una cadena de suministro debe liberar ancho de banda. La resiliencia es un tema difícil y esquivo, por lo tanto, se necesita mucho ancho de banda, lo que lo hace aún más desafiante. Peor aún, la escasez de ancho de banda disponible en la cadena de suministro, como descubrió la industria del software hace décadas, no se puede solucionar simplemente arrojando grandes sumas de dinero ³. Más bien, el mejor camino hacia la resiliencia es indirecto: automatizar sin piedad las decisiones mundanas para ganar la libertad de pensar y ejecutar las decisiones estratégicas, incluida la resiliencia.