La resiliencia de supply chain requiere ancho de banda

Joannes Vermorel

Los últimos años no han sido amables con supply chains. De hecho, lo único que parece no haber estado en falta son las fuerzas de disrupción: confinamientos, guerras, inflación, etc. Como resultado, ha surgido un renovado interés en los supply chains ‘resilientes’. Naturalmente, los sospechosos habituales – consultores, profesores y software vendors (incluyéndome a mí) – han estado ocupados ideando ‘soluciones’ que, al menos, mitiguen el impacto de esas disrupciones, y que, en el mejor de los casos, eliminen por completo algunas clases de disrupciones. Sin embargo, mis observaciones casuales indican que esas ‘soluciones’, sin importar su mérito percibido, suelen no ser más que ilusiones.

De hecho, durante la última década, he observado que la mayoría de los directores de supply chain y sus equipos ya están sepultados bajo microcrisis, incluso durante períodos en su mayoría exentos de cualquier tipo de disrupciones a gran escala. Así, la mayoría de las divisiones de supply chain no tienen el lujo de siquiera pensar en la gestión de crisis (o en cualquier tipo de gran plan estratégico): están completamente comprometidos en apagar una corriente interminable de incendios.

Hace unas décadas, la industria del software acuñó un término para referirse a este mismo problema: falta de ancho de banda, cuando la gerencia ni siquiera puede permitirse pensar en otro problema más porque su atención ya está demasiado dividida entre múltiples asuntos. Lo que hace que el concepto de ancho de banda sea tan relevante tanto para el software como para la supply chain es que, en ambas situaciones, la respuesta corporativa habitual ante una carga de trabajo excesiva – es decir, asignar más personas al caso – no funciona. Esta es la esencia de la Ley de Brooks: agregar mano de obra adicional a un proyecto de software que ya está retrasado solo sirve para retrasarlo aún más. En la industria del software, una de las que cuenta con algunas de las empresas más rentables que jamás han operado en mercados libres, este problema de ancho de banda es sumamente irritante. Aunque la empresa pueda ser lo suficientemente rentable como para duplicar la plantilla y su gestión, no lograría remediar el problema ¹.

Quizás sorprendentemente (o tal vez no), la causa raíz de esta corriente interminable de microcrisis en supply chain es casi exclusivamente el software. Contradictoriamente, no es la guerra en Ucrania ni la posibilidad de tener otra en Asia lo que agota el ancho de banda de la división de supply chain, sino, por lo general, problemas que se calificarían mejor como “totalmente anecdóticos”, como por ejemplo que el WMS esté desincronizado con el ERP (…otra vez); o hacer politicaje con IT para obtener un campo personalizado extra en la base de datos para los stocks “reservados” ²; o perseguir algunos forecast totalmente irrazonables tal como los entrega el proceso de S&OP.

En una galería de pícaros de software que agotan el ancho de banda, los productos analíticos son, de lejos, los peores infractores. Estas herramientas – especialmente las de planificación – requieren no solo una considerable mano de obra para operar, sino que también generan sus propias mini burocracias. Como resultado, la gestión de la supply chain no solo soluciona problemas relacionados con el software, sino también aquellos relacionados con los procesos generados por la propia burocracia. 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. Sin embargo, hace años desarrollamos el antídoto a través del cuarto punto de nuestro manifiesto ³: Tener el control requiere la automatización de cada tarea mundana. Nos dimos cuenta de que había que lograr un delicado equilibrio entre la gestión y la optimización. Por ejemplo, si la generación de las órdenes diarias de compra/producción consume la totalidad del presupuesto de ancho de banda de la división de supply chain, no queda nada en las arcas para mejoras (en términos de resiliencia o cualquier otra cosa).

Por el contrario, si todas las tareas mundanas se automatizan por completo, esto libera una gran cantidad de ancho de banda en la organización de supply chain. Sin embargo, este proceso lleva tiempo. No es una casualidad que cuando Lokad comienza a trabajar para un cliente, usualmente nos lleve alrededor de un año antes de poder centrarnos directamente en cualquier tema que se considere estratégico (como la resiliencia). Lokad no solo tiene que llegar a producción (lo que toma alrededor de 6 meses), sino que la organización también debe aprender a ceder el control de todos los procesos que ahora han sido automatizados (lo que requiere otros 6 meses, o más en organizaciones más grandes).

Sin embargo, al automatizar las decisiones mundanas, los equipos de supply chain recuperan algo que usualmente perdieron hace décadas cuando su organización se digitalizó: la capacidad de elegir sus batallas. Este es probablemente el beneficio único más importante de la automatización, eclipsando los ahorros en productividad. No estoy diciendo que la transición a una supply chain digital en los años 1980 y 1990, operada a través de una colección de ERPs, MRPs y APSs, no haya sido el movimiento correcto. Dicho de forma simple, si bien este camino digital fue necesario, trajo consigo serias desventajas: las empresas (de libre mercado) nunca han estado tan inmersas en su propio paisaje aplicativo, donde las migraciones y actualizaciones se miden típicamente en años. Muchas supply chains han estado sumidas en su “combate digital contra incendios” durante tanto tiempo que pocos empleados recuerdan comenzar la jornada laboral sin una corriente interminable de alertas, excepciones y problemas. Esto sin mencionar la igualmente interminable cantidad de reuniones para abordar dichas alertas, excepciones y problemas. Todos estos procesos tienen costos directos en términos de ancho de banda, y la cuenta mental siempre está en aumento.

Como evidencia anecdótica, consideremos que en menos de 5 años (de 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 ello mientras equilibraba una oferta y demanda en constante cambio. Ford tampoco lo tuvo fácil: el Pánico de 1907 fue una de las crisis financieras más grandes y severas de todos los tiempos. Hoy en día, con 5 años de “negocios como de costumbre”, muchas (¿la mayoría?) empresas ni siquiera pueden finalizar la actualización de su ERP.

Así, para volverse resiliente, una supply chain debe liberar ancho de banda. La resiliencia es un tema difícil y esquivo, por lo que 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 supply chain, como la industria del software descubrió hace décadas, no puede solucionarse simplemente arrojando enormes sumas de dinero ⁴. Más bien, el mejor camino hacia la resiliencia es uno indirecto: automatizar sin piedad las decisiones mundanas para ganar la libertad de pensar y ejecutar las decisiones estratégicas, incluida la resiliencia.