Holimization: Por qué la optimización no es suficiente
Durante la mayor parte de mi carrera, me han dicho que “optimización” es la respuesta. Si tan solo pudiéramos formular el modelo correcto, alimentarlo con suficientes datos, y dejar correr a un potente solucionador, la máquina produciría tranquilamente las mejores decisiones posibles.
Sin embargo, en los supply chains reales, esta promesa rara vez se materializa. Las empresas despliegan software sofisticado, ajustan innumerables parámetros, y aún así se encuentran lidiando con faltante de stock, exceso de inventario, y planificadores nerviosos que ya no confían en el sistema. Las matemáticas dentro de la caja negra pueden ser hermosas; las decisiones en el piso del almacén a menudo no lo son.
En Introducción a Supply Chain, particularmente en los capítulos dedicados a las decisiones y recetas numéricas, argumenté que el verdadero cuello de botella no es la falta de solucionadores, sino la falta de un marco adecuado alrededor de la optimización misma. En este ensayo quiero llevar esta idea un paso más allá y darle un nombre: holimization, y su verbo, to holimize, formado por la contracción de “holistic optimization”.
Cuando la optimización se enmarca en la pregunta equivocada
La optimización clásica, en su forma más simple, parte de una postura muy tentadora:
“Dime qué quieres maximizar o minimizar, enumera las restricciones, y encontraré la mejor decisión posible.”
En una pizarra esto suena perfectamente razonable. En un supply chain, esconde casi todo lo que realmente importa.
¿Qué es exactamente lo que estamos “maximizando”? ¿El beneficio de este mes? ¿Durante un año? ¿El crecimiento a lo largo de varios años? ¿La satisfacción del cliente en un sentido no del todo medible? ¿La resiliencia ante interrupciones? ¿Una combinación de todo lo anterior?
¿Cuáles son exactamente las restricciones? ¿Las formales, como la capacidad y los tiempos de entrega, o también las no documentadas, como “este equipo de almacén no puede manejar de manera realista más de 5,000 cartones entrantes por día” o “esta máquina no puede reiniciarse dos veces en la misma semana”?
¿Y cómo deberíamos medir el daño? ¿Es un faltante de stock peor que una liquidación? ¿Cuánto peor, en términos monetarios, y para qué productos?
Cuando desplegamos un motor de optimización clásica dentro de un supply chain, nos vemos obligados a responder estas preguntas codificándolas—explícita o implícitamente—en una función objetivo y una colección de restricciones. Una vez hecho esto, el solucionador en efecto encontrará decisiones “óptimas” relativas a esa codificación. Desafortunadamente, si la codificación está incluso ligeramente desalineada con la realidad, simplemente obtenemos las decisiones incorrectas más rápido.
He visto muchas variaciones de la misma historia. Un minorista implementa un nuevo sistema de reposición que orgullosamente maximiza el “nivel de servicio” sujeto a los costos de inventario y logística. Los faltantes de stock disminuyen sobre el papel, pero las tiendas ahora tienen demasiados talles y colores de baja rotación que los clientes no desean. Un fabricante instala un sistema avanzado de planificación que optimiza los cronogramas de producción frente a un modelo simplificado de capacidad; el plan resultante se ve elegante en la interfaz, pero la planta pasa su tiempo improvisando soluciones alternativas porque el modelo nunca capturó cuellos de botella críticos en el piso de producción.
En cada uno de estos casos, la optimización en sí funciona. La computadora hace exactamente lo que le pedimos. El problema es que hicimos la pregunta equivocada.
Nombrar la disciplina ausente
La noción que quiero introducir es esta:
Holimization (n.) – La disciplina de optimización holística para sistemas complejos y en evolución, donde el objeto principal de diseño es el marco de optimización en sí: los objetivos, restricciones, semántica de datos y gramática de decisiones. Holimization trata la optimización como un proceso iterativo y experimental en el que la función objetivo, el modelo y la instrumentación coevolucionan bajo retroalimentación del mundo real.
To holimize (v.) – Orquestar tal proceso: enmarcar, instrumentar, optimizar y refactorizar el sistema de decisiones de manera repetida para que se mantenga alineado con la realidad económica y la intención organizacional.
La optimización, en el sentido estricto, se centra en el bucle interno: dado un objetivo fijo y una representación fija del mundo, encontrar decisiones que extremicen este objetivo. Holimization se centra en el bucle externo: cómo diseñamos ese objetivo, cómo representamos el mundo, cómo instrumentamos el sistema y cómo todo esto cambia con el tiempo.
En otras palabras, la optimización responde: “¿Qué es lo mejor, asumiendo que el mundo se ve así?” Holimization pregunta: “¿Estamos mirando el mundo de una manera que permita que ‘lo mejor’ tenga sentido en absoluto?”
Este no es un punto filosófico abstracto. En un entorno desordenado y en evolución, como un supply chain, la pregunta que estamos optimizando sigue cambiando bajo nuestros pies. Los mercados cambian, los surtidos cambian, los canales aparecen y desaparecen, las regulaciones evolucionan, y las prioridades internas se mueven. Si nuestro marco de optimización permanece fijo mientras el mundo se mueve a su alrededor, la divergencia entre lo que es “óptimo” en la pantalla y lo que es sensato en la realidad crece de forma constante con el tiempo.
Holimization es el nombre que propongo para la disciplina de tratar el marco en sí como un objeto de trabajo de primera clase.
Lo que significa holimizar un supply chain
Permítanme concretar esto con ejemplos de supply chain, ya que es donde he pasado la mayor parte de mi tiempo.
Imagina un minorista de moda que quiere “mejorar el servicio” en las tiendas. Si tomamos la optimización en el sentido estricto, podríamos comenzar definiendo el servicio como la probabilidad de no tener un faltante de stock cuando entra un cliente, y podríamos establecer un objetivo como “nivel de servicio del 95%”. Luego codificaríamos los faltantes de stock como un costo, los excesos de inventario como otro costo, y dejaríamos que un motor de optimización equilibrara ambos.
Esto conduce a decisiones que son numéricamente ordenadas pero estéticamente extrañas. Las tiendas terminan con un número técnicamente suficiente de unidades, sin embargo, la mayoría de ellas están en talles equivocados o todas en los mismos colores seguros. Desde la perspectiva del modelo, todo está bien: se cumple el objetivo de servicio y los costos están dentro de los límites. Desde la perspectiva del cliente que entra a la tienda, la colección se ve sin vida.
Si en cambio holimizamos, aceptamos que el “servicio” aún no está formulado adecuadamente. Convertimos el despliegue del sistema de decisiones en un experimento sobre nuestras propias suposiciones.
Comenzamos implementando una receta de decisiones real, impulsada por datos y optimización, pero la rodeamos con instrumentación diseñada para evidenciar decisiones “insanas”: surtidos que cualquier comprador humano juzgaría de inmediato como perjudiciales, incluso si el sistema aún no puede expresar el porqué. Monitoreamos las tiendas donde el modelo insiste en enviar una mezcla inverosímil de talles y gemas en artículos de liquidación. Escuchamos atentamente a los planificadores que se quejan de que el sistema sigue privando de variedad a ciertas tiendas.
Cada vez que encontramos tal insania, lo rastreamos. Quizás nuestra función objetivo no tiene forma de recompensar la diversidad de surtido, solo la disponibilidad de unidades. Quizás nunca capturamos el límite práctico de cuán a menudo se puede reiniciar una tienda. Quizás nuestros datos históricos ocultan efectos de sustitución que hacen que ciertos faltantes de stock sean mucho menos perjudiciales que otros.
Luego cambiamos el marco. Introducimos una noción cuantificada de diversidad en el objetivo, con un valor financiero asociado. Reemplazamos una restricción estricta por un costo, o viceversa. Añadimos una nueva clase de decisiones a la receta, como cuándo renovar una exhibición o cómo escalonar las entregas para tiendas frágiles. Ampliamos la instrumentación para visualizar estos nuevos aspectos de modo que la siguiente tanda de insania, si ocurre, sea más fácil de diagnosticar.
Hemos holimizado la situación: en lugar de culpar al solucionador o ignorar el sistema, usamos los mismos errores de las decisiones como señales de que nuestro marco estaba incompleto y necesitaba evolucionar.
Una historia similar se desarrolla en las operaciones de mantenimiento y reparación. Supongamos que gestionas repuestos para motores de aeronaves. El enfoque ingenuo de optimización es tratar cada pieza de manera independiente: estimar con qué frecuencia se necesitará, asignar un costo a los faltantes de stock y un costo al mantenimiento del inventario, y dejar que la máquina encuentre el mejor punto de reorden.
En la práctica, así no se reparan los motores. El daño real ocurre cuando se retrasa una reparación porque falta una pieza crítica, incluso si estás inundado de inventario de docenas de otras piezas. El costo no es un faltante de stock en una línea de una hoja de cálculo; son días de inactividad para una aeronave.
Holimization nos obliga a replantear el objetivo en torno a algo más cercano a la realidad: por ejemplo, la reducción de días de retraso esperados por motor por unidad de presupuesto. Nos impulsa a instrumentar el proceso con visiones que hagan obvio qué piezas son repetidamente responsables de bloquear las reparaciones. Cuando el sistema sugiere almacenar una gran cantidad de una pieza que nunca impide realmente las reparaciones, eso es una señal de insania. Cuando priva de suministro a una pieza que repetidamente retrasa los motores, esa es otra.
No tratamos estos fallos como errores embarazosos para ocultar. Los tratamos como nuestra mejor fuente de información sobre dónde está equivocado nuestro marco. Luego ajustamos la forma en que medimos el daño, los vínculos entre eventos y costos, y la manera en que estructuramos las decisiones para que optimizaciones futuras se realicen en un espacio más fiel.
Holimization, entonces, no se trata de deshacerse de la optimización. Se trata de rodear la optimización con una práctica disciplinada de aprendizaje a partir de sus errores.
El trabajo oculto alrededor del motor de optimización
Si entras en una gran empresa que está “haciendo optimización”, la mayor parte del esfuerzo que verás no está en diseñar algoritmos. Está en dar sentido a los datos, manejar excepciones y reconciliar lo que el sistema dice con lo que la realidad permite.
Holimization hace explícito y estructurado ese trabajo oculto.
Gran parte de la dificultad radica en la semántica de los datos. Los sistemas operativos contienen un número desconcertante de campos, códigos y peculiaridades históricas. Cuando un motor de decisiones toma estos datos al pie de la letra, inevitablemente interpreta algunos de ellos de forma incorrecta. Un límite que antes tenía sentido podría haberse vuelto obsoleto. Un campo que parece ser “lead time” puede, de hecho, ser una combinación de retrasos en el tránsito y administrativos. Una bandera que parece ser “on promotion” puede utilizarse de manera inconsistente en distintas regiones.
Sin una mentalidad de holimization, estos problemas se descubren por accidente, a menudo después de que se haya causado daño. Con holimization, asumimos desde el principio que nuestra interpretación de los datos es provisional. Construimos pruebas, comparaciones y controles de sensatez que intentan refutar nuestra lectura de los datos. Cuando el sistema propone una decisión que sobrecargaría un muelle, no lo atribuimos a “mala suerte”; lo tomamos como evidencia de que falta una restricción en nuestra visión del mundo.
Otro componente importante es la instrumentación. Un motor de optimización por sí solo es ciego: recibe datos, emite decisiones, y no tiene opinión sobre si estas decisiones son sensatas. Holimization requiere una capa de visibilidad diseñada no solo para rastrear indicadores clave de desempeño, sino también para resaltar dónde el sistema se comporta de maneras que los humanos encuentran absurdas.
Esto puede adoptar muchas formas: vistas de viaje en el tiempo que nos permiten reproducir decisiones contra datos pasados; microscopios en un solo producto o sitio, que muestran cómo evolucionó la decisión a lo largo del tiempo; dashboards que resaltan los valores atípicos en lugar de los promedios. El objetivo es siempre el mismo: convertir las variables “insanas” en un canal de retroalimentación estructurado, no en una fuente de frustración.
Finalmente, está la velocidad y seguridad de la iteración. Holimization es experimental por naturaleza. Necesitamos probar nuevos marcos y objetivos revisados sin poner en riesgo todo el negocio cada vez. Eso implica capacidades técnicas—versionamiento de recetas de decisiones, despliegues controlados, modos shadow—pero también organizativas: responsabilidades claras, una cultura que acepte los experimentos como necesarios, y una administración que entienda la diferencia entre una regla de producción estable y una prueba exploratoria.
Todo esto es trabajo. Sin embargo, es un trabajo que ya estamos realizando de forma informal cada vez que nos quejamos de que “el sistema no lo entiende.” Holimization es un intento de darle a ese trabajo un nombre y un método adecuados.
Por qué importa una palabra nueva
Podrías preguntar razonablemente: ¿por qué crear un término nuevo? ¿Por qué no hablar simplemente de “buena práctica de optimización” o “modelado experimental”?
Mi experiencia es que sin un nombre distinto, el bucle externo es absorbido por el interno. Una vez que la palabra “optimización” está sobre la mesa, la atención se dirige hacia algoritmos, solucionadores y benchmarks de desempeño. La conversación se desplaza hacia si un método particular converge más rápido o se escala mejor, y se aleja de la pregunta, más incómoda, de si estamos optimizando lo correcto desde el principio.
Por el contrario, “holimization” lleva, en su misma construcción, el recordatorio de que la optimización es solo un ingrediente en una disciplina más amplia. Indica que nos importa todo el arco desde la realidad, pasando por los datos, la decisión y de vuelta a la realidad. Sugiere que nuestro artefacto principal no es el solucionador, sino el marco en evolución en el que opera el solucionador.
Para mi propia empresa, Lokad, este nombre también aclara lo que estamos tratando de construir. No somos, en esencia, un proveedor de un motor de optimización más. Estamos intentando proporcionar una plataforma donde las empresas puedan holimizar sus supply chains: un lugar donde los datos puedan ser reconfigurados, donde los objetivos puedan expresarse en términos financieros, donde las decisiones puedan automatizarse pero sigan siendo comprensibles, y donde cada fallo del sistema se trate como una valiosa oportunidad de aprendizaje sobre cómo debe evolucionar el marco.
La palabra es nueva, pero la necesidad que captura no lo es. Los supply chains, y muchos otros sistemas complejos, se han estado holimizando silenciosamente durante años a través de prueba y error, soluciones caseras con hojas de cálculo y reuniones interminables. Mi esperanza es que al darle a este proceso un nombre y una forma más clara, podamos hacerlo más deliberado, más riguroso y, en última instancia, más efectivo.
La optimización, al igual que las matemáticas, no va a desaparecer; si acaso, seguirá mejorando. Holimization es la invitación a dar un paso más alto, a tratar nuestros modelos, objetivos y restricciones no como sagrados, sino como hipótesis a ser comprobadas contra el mundo. Solo entonces, “optimal” dejará de ser una etiqueta formal en un informe y empezará a asemejarse a las decisiones que realmente queremos en la práctica.
