Hombres, máquinas, y el trabajo real de supply chain
Cuando me siento con ejecutivos para hablar sobre supply chain, casi siempre comienzan con almacenes, camiones, personas y, a veces, proveedores. Las computadoras aparecen en algún lugar del trasfondo: un sistema de planificación aquí, una hoja de cálculo allá, y por supuesto el ERP “en el que todo funciona.” La imagen implícita es siempre la misma: las personas están en el centro, las máquinas están allí para ayudar.
Exploré una imagen muy diferente en mi libro Introduction to Supply Chain, donde argumenté que la mayor parte de lo que llamamos “práctica supply chain” es, de hecho, un problema de software disfrazado. En este ensayo quiero reafirmar esa idea en términos más sencillos y confrontarla directamente con la visión dominante que impera tanto en los libros de texto como en las salas de juntas.
Cómo relegamos silenciosamente a las computadoras
En gran parte de la literatura y en la mayoría de las empresas, las computadoras se tratan como palas sofisticadas.
Se supone que debes tenerlas, por supuesto. Nadie administraría una red global con papel y fax. Los sistemas capturan transacciones, almacenan datos maestros, generan reportes y producen forecast. Los planificadores inician sesión cada mañana, miran los dashboards, combinan lo que dice el sistema con su “sentido de negocio” y deciden qué hacer.
El tono es siempre similar: la tecnología brinda soporte. Recoge datos, ejecuta cálculos, muestra indicadores rojos y verdes, y quizá propone una cantidad de pedido recomendada. Pero se espera que el humano se apropie de la decisión. El software es el analista; el planificador es el tomador de decisiones.
En teoría, esto suena tranquilizador. Respeta la experiencia, la intuición y la responsabilidad. Evita el temor de que “el sistema esté dirigiendo el negocio.” Encaja con nuestra intuición de que las decisiones serias deben ser tomadas por personas serias.
El problema es que esta imagen ya no se corresponde con la escala y la complejidad de las modernas supply chain.
Supply chain como un entramado de pequeñas apuestas
Cada día, tu empresa asume un número asombroso de pequeños compromisos.
Tú decides cuántas unidades de cada artículo comprar a cada proveedor. Escoges qué almacén debe recibir qué cantidades. Asignas el stock escaso entre canales y clientes. Aceptas o rechazas órdenes urgentes. Decides qué artículos merecen espacio en el estante y a qué precio. Aceptas ciertos plazos de entrega de los proveedores de transporte y rechazas otros.
Cada uno de estos compromisos es una pequeña apuesta sobre un futuro incierto: una apuesta a que este pedido llegará a tiempo, a que esta promoción impulsará el volumen, a que este safety stock será suficiente pero no excesivo. Ninguna de estas apuestas es particularmente heroica por sí sola, pero en conjunto pueden determinar el éxito o fracaso del P&L.
La característica distintiva de las modernas supply chain no es que sean globales o rápidas; eso ya es conocido. Es que el número de tales apuestas se ha disparado. Las gamas de productos crecen. Los canales se multiplican. Los plazos de entrega fluctúan. Las expectativas de los clientes aumentan. La “superficie de decisiones” se vuelve demasiado grande para que cualquier equipo de humanos pueda monitorizar, y mucho menos optimizar, manualmente.
En este entorno, el modelo dominante—humanos en el centro, máquinas brindando soporte de decisiones—simplemente no escala. Las personas se convierten en cuellos de botella en el lugar equivocado: no en el puerto o en el almacén, sino frente a las pantallas.
Por qué las computadoras deben estar en el centro
Las computadoras tienen un superpoder: son muy buenas haciendo una gran cantidad de pequeños cálculos estructurados, una y otra vez, sin cansarse ni aburrirse.
Supply chain es precisamente ese tipo de problema. La mayoría de las decisiones operativas que consumen el tiempo de los equipos de planificación son repetitivas. Se repiten día tras día, con variaciones en los datos pero con una estructura similar. Tienen entradas claras: forecast, costos, capacidades, restricciones, reglas de negocio. Tienen salidas claras: cantidades, fechas, ubicaciones, precios. No son triviales, pero están estructuradas.
Cuando aceptas esto, se sugiere una arquitectura diferente.
En lugar de pensar en las computadoras como herramientas para preparar información para los humanos, comienzas a verlas como máquinas que en realidad toman las decisiones de rutina. No como máquinas “asistentes”, sino como máquinas de “decisión”.
Esto no significa construir un cerebro monolítico gigante que controle todo. Significa construir deliberadamente un software que, bajo circunstancias normales, pueda:
- leer los datos relevantes,
- evaluar muchas opciones posibles,
- elegir una de acuerdo a un objetivo económico explícito,
- y emitir una instrucción concreta: una línea de orden de compra, una transferencia de stock, una asignación, un precio.
Los humanos siguen existiendo en este mundo, pero ya no pasan sus días empujando órdenes individuales. Trabajan alrededor de la maquinaria de decisión en lugar de a través de ella.
Ese es el cambio fundamental: de computadoras que apoyan las decisiones a computadoras que toman decisiones en todos los lugares donde las decisiones son pequeñas, numerosas y repetitivas.
Para qué sirven realmente las personas
Poner las máquinas en el centro no hace que las personas sean menos importantes; las hace responsables de cosas diferentes.
Primero, las personas deben decidir qué se permite que haga el software en absoluto. Esto significa definir el espacio de opciones admisibles. ¿Se permite el cross-docking entre estos sitios? ¿Se permiten sustituciones entre estos dos SKUs? ¿Podemos enviar órdenes parciales a este cliente? ¿Podemos usar transporte aéreo para ese producto en esa región? Las computadoras no inventan opciones; seleccionan entre las que ponemos a disposición.
Segundo, las personas deben decidir qué significa “bueno”. Esto no se trata de aspiraciones vagas como “excelencia en el servicio” o “inventario lean”, sino de compensaciones explícitas. ¿Qué tan doloroso es un faltante de stock, en términos financieros, para diferentes productos y clientes? ¿Qué tan costosa es la obsolescencia? ¿Cuánto valoramos realmente el lead time frente al costo en una base por carril? ¿Cómo deberíamos arbitrar entre dos unidades de negocio que compiten por la misma capacidad limitada?
Cuando respondemos estas preguntas de forma precisa, le damos al software una función objetivo. Le decimos lo que queremos, en un lenguaje que puede aplicar a cada decisión.
Tercero, las personas deben proteger el significado de los datos. Con el tiempo, los campos en un sistema se vuelven a usar, se reinterpretan y se abusan. Una columna que antes significaba “fecha de entrega prometida” y ahora a veces significa “fecha solicitada”. Una bandera que una vez indicaba una familia de productos es discretamente reutilizada para señalar una promoción interna. Si nadie presta atención, el software continuará calculando absurdos muy precisos.
Finalmente, las personas deben intervenir cuando el mundo cambia más rápido que los modelos o las reglas. Deben ser capaces de decir: esta restricción ya no es válida; esta penalización es demasiado alta; esta opción de sourcing ahora es políticamente inaceptable; este lead time ya no es confiable. No intervienen editando a mano miles de órdenes, sino cambiando las suposiciones que generan esas órdenes.
Así, en esta visión, los humanos no son empleados de oficina puliendo hojas de cálculo. Son diseñadores, economistas y guardianes de la maquinaria de decisión. Su trabajo es diseñar el juego, establecer la puntuación y vigilar cuándo el juego ya no refleja la realidad.
La visión convencional, expresada claramente
Permítanme ahora exponer la visión convencional de una manera que la mayoría de los profesionales reconocerán.
En una empresa típica, el panorama de software tiene tres capas.
En la base, los sistemas de transacciones registran lo que sucede: pedidos, recibos, envíos, facturas. Por encima de ellos, las herramientas de reporting y los dashboards resumen esa historia en muchos cortes: por producto, cliente, región, período de tiempo. Encima de eso, se encuentran sistemas de planificación que toman datos de abajo, procesan forecast, ejecutan heurísticas o optimizaciones, y producen “propuestas.”
Esas propuestas son luego revisadas por los planificadores. Las comparan con su conocimiento del mercado, las peculiaridades de los proveedores, la política de los clientes, la realidad de los almacenes. Aceptan algunas, ajustan otras y anulan el resto. En muchas organizaciones, gran parte de este último paso ocurre en hojas de cálculo, fuera de cualquier sistema formal.
La filosofía implícita es clara: los sistemas están ahí para informar y asistir. Los humanos, especialmente los planificadores, están ahí para decidir. Si algo sale mal, la explicación suele ser que “el sistema no es lo suficientemente flexible”, o “los datos estaban equivocados”, o “el algoritmo no entendió este caso especial”, por lo que “se necesitaba un planificador para corregirlo.”
Los libros de texto refuerzan este patrón. La tecnología de la información se describe como un “motor” o un “facilitador” del desempeño de supply chain. Proporciona visibilidad, integración, velocidad y sofisticación analítica. Pero siempre hay un paso en el que el tomador de decisiones humano reaparece en la cima de la pirámide, a quien el sistema reporta.
Esta imagen no es del todo incorrecta. Capturó la realidad de lo que era factible durante mucho tiempo. Los sistemas eran rígidos. La optimización a gran escala era costosa. La calidad de los datos era terrible. Incluir a un humano en el proceso era una decisión segura y pragmática.
Pero hemos mantenido ese modelo por más tiempo del que merece.
Donde discrepo con la visión convencional
Mi desacuerdo con la visión convencional puede expresarse en una sola frase:
Para la mayoría de las decisiones operativas, ya no deberíamos apuntar al soporte de decisiones; deberíamos apuntar a la automatización de decisiones.
Esto no significa automatización ciega. Significa que cuando una decisión es pequeña, frecuente y estructuralmente similar en muchas instancias, deberíamos diseñar software que la tome de principio a fin, con los humanos enfocándose en el diseño y monitoreo del mecanismo en lugar de en su ejecución diaria.
De esta sencilla afirmación, siguen varias confrontaciones.
La visión convencional invierte fuertemente en añadir más dashboards y más planificadores. Yo preferiría invertir en menos planificadores que se comporten más como quantitative product owners y en más ingenieros que puedan codificar la lógica del negocio en código en lugar de configuración.
La visión convencional intenta comprar sistemas que sean lo suficientemente “configurables” para manejar la mayoría de las situaciones desde el principio. Espero que cualquier supply chain serio contenga muchas peculiaridades y restricciones específicas de la empresa que no puedan ser capturadas de manera significativa solo con casillas de verificación y tablas de parámetros. En algún momento, alguien tendrá que escribir código.
La visión convencional trata la combinación de ERP, módulos de planificación y BI como una pila completa: datos en la base, perspectiva en el medio, decisiones en la cima. Yo veo esa pila como solo medio construida. La capa faltante es la que asume la responsabilidad de la mayoría de los compromisos reales en el negocio.
Sobre todo, la visión convencional insiste en que los humanos sigan siendo quienes “toman” las decisiones. Yo insisto en que, para la gran mayoría de las decisiones rutinarias, es mejor emplear a los humanos decidiendo cómo se deben tomar las decisiones, y no tomarlas una por una.
“¿Pero qué pasa si el sistema está equivocado?”
Una objeción común es inmediata y legítima: ¿qué ocurre cuando el sistema está equivocado?
Si dejamos que el software coloque pedidos, asigne stock y fije precios, y el software cometa un error, las consecuencias pueden ser severas. Con un humano en el proceso, al menos alguien podría haberlo detectado.
Creo que esta objeción es importante, pero corta en ambas direcciones.
Cuando confías en los humanos para corregir la salida de sistemas que están fundamentalmente mal especificados, intercambias un tipo de fallo por otro. Los errores individuales pueden ser detectados, pero los errores estructurales persisten. Nadie tiene el tiempo o la capacidad cognitiva para ver que la lógica completa del sistema está ligeramente equivocada, que una penalización está mal calibrada, o que una restricción se ha desviado. La gente se ocupa de emergencias; rara vez rediseñan.
En un sistema automatizado, estás obligado a tratar este riesgo de manera explícita.
Necesitas un monitoreo que no solo observe los niveles de servicio y los giros de inventario, sino que pueda atribuir los fallos a supuestos específicos. Necesitas la capacidad de pausar la automatización para un subconjunto de productos o regiones cuando se detecta una anomalía. Necesitas registros de auditoría: registros claros de por qué el sistema eligió una decisión particular, con qué entradas y cuál lógica interna.
Lo más importante es que necesitas una cultura que acepte que el software es un activo de primera clase. Se merece diseño, pruebas, refactorización y gobernanza. No puede ser una caja negra opaca que “el proveedor maneje” o “TI se encargue.” Si el software está ejecutando el negocio día a día, entonces enriquecer y corregir su comportamiento es una de las responsabilidades fundamentales de la organization del supply chain.
Eso puede sonar más arriesgado que pedir a los planificadores que “mantengan un ojo en las propuestas,” pero en la práctica a menudo reduce el riesgo en lugar de aumentarlo. Los fallos son más rastreables. Las correcciones son sistémicas en lugar de locales. El aprendizaje se acumula en el código en lugar de desaparecer cuando un planificador experimentado se va.
Donde aún estoy de acuerdo con la visión convencional
A pesar de estos desacuerdos, hay áreas en las que estoy completamente alineado con la visión convencional.
Estoy de acuerdo en que la información es central. Sin datos oportunos y confiables, cualquier ambición de automatización es una fantasía.
Estoy de acuerdo en que los silos organizacionales son un obstáculo importante. Si compras, logística, ventas y finanzas no pueden ponerse de acuerdo en definiciones básicas y objetivos compartidos, ningún sistema los rescatará.
Estoy de acuerdo en que el supply chain no se trata solo de matemáticas y máquinas. Las relaciones con los proveedores, la confianza entre los socios, las restricciones regulatorias y los choques geopolíticos importan enormemente. Un hermoso motor de decisiones no puede hacer aparecer un barco en un canal bloqueado.
Mi punto es más preciso: cuando se trata del trabajo diario de decidir cantidades, tiempos y asignaciones a través de grandes redes, estamos subutilizando de manera dramática las máquinas que ya tenemos. Estamos atrapando a personas talentosas en bucles clericales donde añaden muy poco valor marginal, pero absorben una gran cantidad de energía organizacional.
Un destino diferente
Si tomas mi punto de vista en serio, el destino se ve algo así.
La mayoría de las decisiones operativas del día a día—qué pedir, dónde asignar, cuánto enviar, cuándo reabastecer—son tomadas automáticamente por el software, en circunstancias normales. El software opera bajo reglas claras y explícitas y objetivos económicos, y su comportamiento es visible y auditable.
Los planificadores no comienzan su día desplazándose por listas de excepciones. Comienzan su día observando el comportamiento de la propia maquinaria de decisión: dónde está funcionando bien, dónde es errática, dónde las suposiciones pueden haberse quedado obsoletas. Trabajan con ingenieros para refinar la lógica, mejorar los datos, ajustar las compensaciones económicas.
Cuando ocurren interrupciones, los humanos intervienen no micromanageando pedidos individuales, sino cambiando los parámetros del juego: prohibiendo ciertos modos de transporte, abriendo opciones temporales de sourcing, revisando penalizaciones y prioridades. El sistema luego recomputa la miríada de pequeñas apuestas implícitas en esas nuevas condiciones.
Las carreras en supply chain evolucionan en consecuencia. Se dedica menos tiempo a “combatir el sistema” y “arreglar el plan.” Se dedica más tiempo a comprender la economía del negocio, codificar ese entendimiento en software y diseñar conjuntos de opciones resilientes para un mundo incierto.
En tal organización, las computadoras ya no son palas. Son la maquinaria de la supply chain. Las personas son las arquitectas, economistas y guardianes de esa maquinaria.
Esa es la perspectiva que quería aclarar aquí. Difiere radicalmente de la narrativa convencional de TI como soporte y las personas como principales tomadores de decisiones. Pero creo que está más cerca de la realidad de hacia dónde pueden, y deben, dirigirse las supply chains a continuación.
