Simpatía Mecánica: El Ingrediente Perdido en el Software de supply chain
Cuando comencé a trabajar en problemas de supply chain hace casi veinte años, esperaba que la parte difícil fuera la física: camiones, barcos, pallets, contenedores, líneas de producción. En cambio, me encontré lidiando con pantallas que tardaban varios segundos en actualizarse, lotes nocturnos que rutinariamente se extendían hasta la mañana siguiente, y motores de “optimización” que tuvieron que simplificarse hasta ser apenas mejores que una hoja de cálculo.
El verdadero cuello de botella no fue el acero ni el concreto. Fue el software. Más precisamente, fue nuestra indiferencia colectiva hacia la máquina que ejecuta ese software.
En mi libro Introduction to Supply Chain, sostengo que los supply chain modernos son, ante todo, motores de toma de decisiones bajo incertidumbre. La calidad de esas decisiones depende de la calidad del software que las prepara, y ese software, a su vez, está limitado por el hardware de computación subyacente, desde las cachés de CPU hasta el ancho de banda de la memoria.
En la última década, he llegado a creer que la práctica de supply chain no puede progresar mucho más a menos que desarrollemos lo que yo llamo simpatía mecánica: un sentir instintivo de cómo se comporta realmente el cómputo, y una disposición a diseñar nuestros métodos en torno a esa realidad en lugar de ignorarla.
Lo Que Quiero Decir con “Simpatía Mecánica”
La frase proviene originalmente de las carreras de motor. Un buen piloto no sólo es hábil en seguir la línea de carrera; también “siente” lo que el coche puede y no puede hacer. Evita maniobras bruscas que sobrecalientan los frenos, escucha el motor, y se percata cuando los neumáticos están a punto de perder adherencia. Simpatiza con la máquina.
En la computación, el equivalente es entender que un servidor moderno no es una calculadora mágica y sin fricción que realiza “operaciones por segundo” de manera abstracta. Es un objeto físico con peculiaridades: cachés diminutas que son rápidas pero pequeñas, memoria principal que es más lenta, discos que son aún más lentos, y redes con una latencia que no se puede desear que desaparezca. La diferencia entre respetar esas limitaciones e ignorarlas sistemáticamente se traduce en ganancias de uno o dos órdenes de magnitud en rendimiento.
Tenemos un ejemplo sorprendente en la historia de deep learning. La literatura temprana sobre redes neuronales estaba obsesionada con la inspiración biológica: neuronas, sinapsis, reglas de aprendizaje que sonaban a neurociencia. El avance se produjo cuando los investigadores abandonaron cualquier pretensión de imitar el cerebro y, en cambio, optimizaron sin piedad para GPUs y estabilidad numérica. Unidades lineales rectificadas, mini-batches, capas densas, aritmética de precisión mixta: muchas de estas ideas tienen menos que ver con la neurociencia y más con acomodar el hardware. El campo despegó en el momento en que mostró simpatía mecánica por el silicio.
El supply chain no es, por supuesto, reconocimiento de imágenes. Pero es igual de computacional, y tiene tanto que ganar al respetar la máquina.
Supply Chain como un Problema Computacional
Los supply chain a menudo se describen en términos de flujos físicos: fábricas, almacenes, camiones y tiendas. Lo que no es tan obvio a primera vista es que detrás de cada pallet que se mueve, hay docenas de pequeñas decisiones: qué comprar, qué producir, cuánto enviar, dónde almacenar, a qué precio vender, cuándo rebajar precios, qué orden priorizar.
Cada una de esas decisiones se toma bajo incertidumbre. La demanda puede dispararse o desplomarse. Los tiempos de entrega se retrasan. Los proveedores fallan. La capacidad de transporte se evapora de la noche a la mañana. Si queremos hacer que esas decisiones sean sistemáticamente mejores que la intuición humana, necesitamos algoritmos que consideren muchos escenarios, no solo un forecast; que comparen opciones en términos de beneficio esperado, no solo en nivel de servicio; que propaguen las limitaciones a través de toda la red en lugar de tratar cada almacén o tienda de forma aislada.
Todo esto es computacionalmente costoso. Un enfoque probabilístico que rastrea miles de futuros plausibles y evalúa las decisiones contra cada uno de ellos realizará mucha más aritmética que una fórmula simplista de safety stock. Una visión a nivel de red que acople inventario, fijación de precios y planificación de capacidad hará pasar muchos más datos a través de la máquina que un cálculo local de punto de reorden.
Aquí es donde la simpatía mecánica se vuelve decisiva. Si la pila de software y hardware subyacente es descuidada, si cada consulta desencadena docenas de viajes de ida y vuelta a una base de datos transaccional, si los algoritmos están escritos de manera que anulan la caché y el paralelismo, entonces estos métodos más sofisticados simplemente no se ajustan al intervalo de tiempo disponible. Terminas reduciendo el problema hasta que se adapta a la máquina, en lugar de mejorar la máquina para que pueda abordar el problema real.
Cuando veo una empresa cuya “optimización” de reposición debe comenzar a las 6 p.m. para terminar a las 6 a.m., sé que la organización nunca experimentará seriamente con alternativas. Cada nueva idea se convierte en un proyecto de varias semanas, porque ejecutar una sola simulación toma medio día. La economía de la experimentación colapsa.
La Visión Convencional: El Hardware como algo Secundario
Si observas los libros de texto convencionales de supply chain, encontrarás extensas discusiones sobre diseño de red, estrategias de abastecimiento, contratos, políticas de inventario, modos de transporte y métricas de rendimiento. También encontrarás capítulos sobre “tecnología de la información” que describen sistemas ERP, herramientas de planificación e integración. Lo que casi nunca encontrarás es una discusión seria sobre cómo se comporta realmente la computación subyacente.
La TI se trata como un facilitador neutral. El mensaje, en líneas generales, es que una vez que has elegido tu software e integrado tus datos, puedes centrarte en el diseño de procesos y palancas gerenciales. La vida interna de la máquina –cómo se organiza la memoria, cómo se almacenan los datos, cómo se planifica el cómputo– pertenece a los proveedores y técnicos.
La misma mentalidad impregna la mayoría del software empresarial en nuestro campo. Los sistemas de planificación se construyen sobre bases de datos transaccionales que fueron diseñadas originalmente para registrar pedidos y actualizar niveles de stock, no para calcular miles de billones de escenarios probabilísticos durante la noche. La arquitectura suele estar organizada en torno a pantallas y formularios que crean, leen, actualizan y eliminan registros. Se añaden módulos adicionales de “optimización”: un motor de forecast aquí, un solucionador de rutas allí, una heurística de inventario en algún otro lugar.
Desde fuera, esto parece lo suficientemente moderno: interfaces web, despliegue en la computación en la nube, APIs, e incluso “AI” en el folleto de marketing. Sin embargo, bajo el capó, el núcleo computacional a menudo está desprovisto. Los cálculos se despachan a través de capas de abstracción que fragmentan los datos, dispersan el trabajo y anulan las fortalezas del hardware. El resultado es un software que lucha por mantenerse al día con los volúmenes de datos actuales a pesar de ejecutarse en máquinas miles de veces más rápidas que las de hace treinta años.
Niklaus Wirth comentó famosamente que el software se está volviendo más lento más rápidamente de lo que el hardware se vuelve más rápido. En supply chain, puedes ver esto directamente: aún se necesitan varios segundos para abrir la página de “detalles” de una combinación de producto y ubicación en muchos sistemas grandes, a pesar de que el hardware subyacente debería ser capaz de escanear millones de esos registros en el mismo tiempo. Hemos logrado consumir casi todo el progreso del hardware en capas de ineficiencia.
Una vez que la ineficiencia está incorporada en la arquitectura, las consecuencias no son meramente técnicas; son doctrinales. Si tu plataforma no puede permitirse hacer el seguimiento de miles de escenarios para cada SKU, entonces favorecerás metodologías que solo requieran un único forecast. Si tu motor no puede evaluar el impacto financiero de las decisiones a nivel de red, te inclinarás hacia reglas locales e indicadores clave de rendimiento que se pueden calcular de forma aislada. Las limitaciones “teóricas” se convierten rápidamente en dogmas “prácticos”.
Qué Cambia Cuando Te Importa la Máquina
¿Qué sucede si invertimos la historia? Supongamos que partimos de la premisa de que la máquina importa.
Primero, empezamos a diseñar flujos de datos que respeten la localidad. En lugar de dispersar la información en docenas de tablas y pedir a la base de datos que las reconstruya para cada cómputo, organizamos los datos de modo que una única pasada por la memoria proporcione todo lo que un algoritmo necesita. Esto por sí solo puede aumentar el rendimiento en un orden de magnitud completo.
Segundo, favorecemos operaciones batch y vectorizadas sobre el procesamiento charlatán, fila por fila. El hardware es extraordinariamente bueno haciendo la misma operación una y otra vez en grandes arreglos. Es terrible respondiendo a miles de pequeñas preguntas no relacionadas que requieren saltar por la memoria y a través de la red. Cuando la parte analítica de un sistema de supply chain se expresa como un programa coherente en lugar de un enjambre de transacciones impulsadas por formularios, se vuelve mucho más fácil aprovechar esta fortaleza.
Tercero, observamos toda la cadena de decisión, desde los datos en crudo hasta las cantidades que aparecen en las órdenes de compra y listas de picking, como algo que se puede y se debe perfilar, optimizar y reingeniar con el tiempo. Dejamos de tratar “el modelo” como una caja negra y empezamos a tratar la receta como software. Esto es precisamente lo que permitió a campos como la computer graphics y la scientific computing evolucionar de prototipos lentos a herramientas industriales: ingenieros pasaron años eliminando ineficiencias en cada capa.
El beneficio directo es la velocidad. Un cómputo que solía tardar seis horas, ahora podría tardar seis minutos o seis segundos. Pero el beneficio más profundo no es el número en bruto; es lo que la velocidad permite. Si tu equipo puede ejecutar cien variantes de una política de reposición en un día en lugar de una variante por semana, explorarán ideas que antes eran impensables. Refinarán los modelos en respuesta a las interrupciones, probarán supuestos alternativos y avanzarán gradualmente la frontera de lo económicamente alcanzable.
Esto No Es Vanidad Geek, Es Economía
Algunos lectores pueden preocuparse de que todo esto suene a la obsesión de un ingeniero por la elegancia por sí misma. ¿A quién le importa cuántos fallos de caché cometa un algoritmo, siempre y cuando las estanterías estén abastecidas y los camiones salgan a tiempo?
La respuesta es que la ineficiencia no es gratis. En la era de la computación en la nube, pagas por ello dos veces.
Pagas directamente, en forma de infraestructura sobredimensionada. Si tu software requiere diez veces más cómputo y almacenamiento del necesario para producir las mismas decisiones, pagarás diez veces más a tu proveedor de cloud o por tu hardware, o aceptarás tiempos de ejecución diez veces mayores, lo que es simplemente otra forma de coste.
También pagas de manera indirecta, en forma de una lógica de decisiones más débil. Debido a que los sistemas ineficientes tienen dificultades para calcular políticas sofisticadas a escala, los proveedores simplifican las matemáticas para ajustarlas a la máquina. Reducen las distribuciones de probabilidad a números únicos. Desacoplan procesos que en la realidad están estrechamente vinculados para que puedan calcularse en pasadas separadas. Ocultan aproximaciones burdas detrás de paneles pulidos. Puede que nunca veas los atajos, pero los sentirás en forma de safety stock en exceso, ventas perdidas y reacciones frágiles ante choques.
La simpatía mecánica, en cambio, te permite invertir tu presupuesto computacional donde más importa: en explorar la incertidumbre y las compensaciones. Un sistema eficiente puede permitirse simular miles de futuros y elegir decisiones que maximicen el beneficio esperado mientras controlan el riesgo, en lugar de depender de reglas empíricas. Puede permitirse recalcular frecuentemente, de modo que las decisiones se mantengan frescas frente a nuevos datos. Puede permitirse mantener toda la red en vista en lugar de optimizar miope cada nodo de forma aislada.
En ese sentido, la simpatía mecánica no es una preferencia técnica; es una postura económica. Dice: no malgastaremos recursos computacionales escasos en gastos generales gratuitos; los emplearemos en los cálculos que realmente cambian nuestros flujos de caja.
Lo Que Espero de los Líderes de supply chain
Nada de esto significa que cada ejecutivo de supply chain deba convertirse en un programador de sistemas. Pero creo que los equipos de liderazgo necesitan una noción básica de escala y dirección. No tienes que diseñar motores para saber que un camión que consume tres veces más combustible que sus pares en la misma ruta es un problema. No tienes que ser diseñador de chips para reconocer que un sistema que tarda horas en realizar un cálculo que razonablemente se podría hacer en segundos es un problema.
Cuando seleccionas software o un proveedor, deberías sentirte cómodo haciendo preguntas como:
¿Con qué frecuencia podemos recomputar de manera realista todas las decisiones clave para toda la red?
¿Qué sucede si duplicamos el número de SKUs o ubicaciones – ¿se duplican los tiempos de ejecución, o se disparan?
¿Cuánto hardware requiere esta plataforma para procesar nuestros datos, y qué tan confiados estamos en que esos requerimientos no se inflarán en dos años?
Si las respuestas son evasivas, o si nadie en la sala puede siquiera estimar órdenes de magnitud, algo está mal. En la conversación de LokadTV sobre recursos computacionales, comparé esto con la geografía básica: no necesitas conocer la elevación exacta de cada montaña, pero sí deberías saber si una carretera determinada cruza los Alpes o una llanura.
Del mismo modo, se debe alentar a los equipos internos a ver su trabajo analítico como código que puede ser perfilado y mejorado, y no como “modelos” estáticos que son correctos o incorrectos. La capacidad para razonar sobre el rendimiento es parte de la competencia profesional, así como la habilidad para razonar sobre la economía unitaria es parte de las finanzas.
Un Tipo Diferente de Simpatía
La simpatía mecánica es, en última instancia, una forma de respeto.
Es el respeto hacia la máquina: reconocer que nuestros servidores no son infinitos, que sus peculiaridades y límites son reales, y que ignorarlos es un riesgo.
Es el respeto hacia las personas que dependen de esas máquinas: planificadores que necesitan recomendaciones oportunas y confiables; gerentes que requieren espacio para experimentar; ejecutivos que deben comprometer capital en base a lo que el software les indique.
Y es el respeto hacia la disciplina del supply chain en sí mismo. Si afirmamos que nuestro campo se trata de tomar mejores decisiones bajo incertidumbre, entonces no podemos hacer la vista gorda ante la calidad de la maquinaria que produce esas decisiones. Se lo debemos a nosotros mismos – y a las empresas que confían en nosotros – tratar los recursos computacionales con la misma seriedad con que tratamos los almacenes y las flotas.
La visión general ha sido tratar los internos de hardware y software como una preocupación de backstage, algo que “IT se encargará.” Creo que esa visión ha llegado al fin de su utilidad. Cuanto más nuestras supply chain dependan de algoritmos y datos, más necesitamos poner la máquina en el centro de atención.
La simpatía mecánica no significa convertir a cada planificador en un programador. Significa cultivar, a todos los niveles, una curiosidad informada sobre cómo funcionan realmente nuestras herramientas – y una negativa a aceptar la lentitud, la opacidad y el desperdicio como algo inevitable.
