La supply chain necesita sistemas programables, no productos configurables
I have recently published Introduction to Supply Chain as a free, online book. In it, I argue that supply chain decisions should be produced by programmatic systems rather than by “configurable” software products. Since the book is intentionally broad, I want to use this post to focus on one specific idea: why Lokad has embraced a deeply programmatic stance, and why this puts us at odds with the mainstream view of supply chain software.
No discutiré proveedores específicos. Lo que me interesa es la filosofía subyacente: ¿qué tipo de software es apropiado para la supply chain?
Por qué el software genérico tiene dificultades con las supply chain concretas
La mayoría del software vendido en supply chain hoy en día sigue una historia similar.
Primero, se parte de una columna vertebral transaccional: algo que registra pedidos, recibos, movimientos de stock, facturas, envíos. Esta capa está relativamente estandarizada. Funciona con entidades familiares: clientes, órdenes de compra, SKUs, ubicaciones. Se espera que sea genérica y reutilizable en muchas industrias, lo cual en gran medida es cierto.
Sobre esta columna vertebral, se añaden módulos de “planificación” u “optimización”. Esos módulos prometen transformar datos pasados y presentes en mejores decisiones: órdenes de compra, transferencias, planes de producción, asignaciones, precios, y demás. Los proveedores suelen presentar estas capacidades como aplicaciones configurables. No se escribe la lógica; se configura. Se definen reglas. Se establecen parámetros. Se afinan modelos. Se adoptan procesos de “mejores prácticas”.
A primera vista, este enfoque parece completamente razonable. Después de todo, vemos problemas muy similares en todas partes: cuánto comprar, dónde ubicarlo, cuándo moverlo, qué prometer, qué descontar. Seguramente una plataforma genérica puede abordar esos problemas de una manera reutilizable.
Sin embargo, cuando se observa de cerca las supply chain de la vida real, algo obstinado se interpone: las idiosincrasias.
Un distribuidor de cables descubre que diez mil metros de cable no es “un número”; depende de cómo se dividan esos metros entre carretes, qué longitudes piden realmente los clientes, qué desperdicio de corte es aceptable y qué cortes se pueden prometer sin arruinar los márgenes.
Una compañía aeroespacial descubre que “una pieza en stock” puede ocultar un componente serializado con su propio historial de mantenimiento, restricciones de certificación y reglas complejas de sustitución.
Un minorista de moda aprende que la demanda no es solo por “SKUs” sino por surtidos: ciertas combinaciones de talla y color deben estar presentes juntas, de lo contrario, toda la categoría rinde por debajo, sin importar cuántas piezas individuales haya en stock.
Cuando intentamos comprimir estas situaciones en un motor de decisión genérico, no se comportan como casos marginales. Son el núcleo del negocio. Cada empresa tiene su propia versión de estos “cables”: restricciones y economías que no encajan en un modelo, pero que determinan la rentabilidad de toda la operación.
El resultado, en la práctica, es familiar: módulos de planificación configurables en el centro, hojas de cálculo en los márgenes, y planificadores humanos parcheando constantemente las brechas.
Por qué la configuración no es suficiente
El sueño detrás del software de planificación configurable es que la complejidad se puede domar mediante opciones: más parámetros, más interruptores, más tipos de reglas, más plantillas. No deberías tener que programar; deberías ser capaz de “enseñar” al software qué hacer a través de la configuración.
Desafortunadamente, la configuración tiene límites estrictos.
La configuración funciona cuando ya conoces la forma del problema. Si todas las empresas compartieran la misma estructura de restricciones y economías, el mismo modelo conceptual de cómo se comporta la demanda y cómo responde el inventario, entonces elegir valores para un conjunto predefinido de reglas sería suficiente.
Pero una supply chain real no es un rompecabezas fijo que espera los parámetros adecuados. Es un objetivo móvil, moldeado por competidores, regulaciones, redes logísticas y hábitos de los clientes que están en constante cambio. Además, las restricciones más impactantes son a menudo precisamente aquellas que no encajan en el modelo estándar de nadie.
Cuando el modelo del mundo incorporado en el software no coincide con el mundo en el que operas, solo tienes dos opciones.
O cambias tu negocio para conformarlo al software. Esto es ocasionalmente sensato para procesos puramente administrativos, pero peligroso cuando afecta tu ventaja competitiva.
O compensas fuera del sistema: hojas de cálculo auxiliares, ajustes manuales, manejo de excepciones, sobreescrituras de último minuto. El software central se convierte en una especie de motor de sugerencias elaborado, mientras el control real vuelve a manos humanas y archivos de Excel.
Cuanto más intentas extender un producto de planificación genérico para acomodar tus especificidades, más terminas con una configuración enredada que nadie entiende completamente, y que es difícil de evolucionar. No has escapado a la complejidad; la has enterrado en metadatos.
Por qué la programabilidad es inevitable
Si la configuración no es suficiente, lo que queda es la programación.
La palabra “programación” se comprende a menudo de manera errónea aquí. No estoy defendiendo que cada planificador deba convertirse en ingeniero de software, ni que cada empresa deba construir una pila completa desde cero. Simplemente estoy afirmando algo que creo es ineludible:
Si quieres que un sistema asuma la responsabilidad de tus decisiones de supply chain, debes ser capaz de expresar, con precisión, la lógica mediante la cual se toman esas decisiones.
Esa lógica incluye:
- Cómo se trata la incertidumbre: demanda, tiempos de entrega, confiabilidad del proveedor, promociones, interrupciones.
- Cómo se codifican las economías: costo de faltante de stock, costo de exceso, costo de mantenimiento, restricciones de capital, compromisos de servicio, penalizaciones.
- Cómo se hacen cumplir las restricciones: empaque, cantidades mínimas de pedido, capacidades de camiones y contenedores, vida útil, reglas de sustitución, restricciones regulatorias.
- Cómo se hacen compensaciones entre objetivos conflictivos.
Cada uno de estos elementos es específico de tu negocio. Cada uno cambia con el tiempo. Y cada uno interactúa con los demás de maneras que ningún catálogo de opciones de configuración puede anticipar.
Por eso digo que la programabilidad no es una preferencia estilística. Es un reconocimiento de la realidad. La pregunta no es “¿Deberíamos programar?” sino “¿Dónde, y utilizando qué tipo de herramientas?”
Las hojas de cálculo son una forma de programación. Son sumamente populares en supply chain precisamente porque permiten a los practicantes expresar una lógica que no encaja en ninguna aplicación estándar. Desafortunadamente, escalan mal, fomentan la duplicación de la lógica y no se prestan a una automatización robusta.
Los lenguajes de programación de propósito general pueden expresar cualquier cosa, pero vienen con otro problema: si intentas construir toda la inteligencia de la supply chain en una pila genérica, rápidamente te encuentras dirigiendo una empresa de productos de software disfrazada. Tienes que ensamblar y mantener bases de datos, computación distribuida, interfaces, seguridad y pipelines de despliegue que tienen poco que ver con tu negocio real.
El desafío, entonces, es adoptar la programación mientras se evita tanto la fragilidad de las hojas de cálculo como la sobrecarga de construir una plataforma genérica desde cero.
Cómo esto moldea las decisiones tecnológicas de Lokad
En 2012, tomamos una decisión deliberada: no intentaríamos producir un “producto de planificación” universal que pretendiera funcionar de inmediato solo mediante configuración.
En cambio, nos propusimos construir un entorno donde la lógica de decisiones de supply chain pueda expresarse como código, de una manera que sea:
-
Lo suficientemente poderoso como para codificar la complejidad real de un negocio.
-
Lo suficientemente compacto como para ser comprensible y auditable.
-
Lo suficientemente operativo como para funcionar todos los días, a escala, sobre sistemas transaccionales existentes.
Primero, tratamos los datos provenientes de ERPs y otros sistemas transaccionales como materia prima, no como algo que simplemente se reporta. Asumimos que el valor real proviene de transformar esos datos en decisiones concretas: órdenes de compra, transferencias de stock, programas de producción, políticas de precios y descuentos, decisiones de surtido.
Segundo, expresamos esa transformación como una colección de scripts, escritos en un lenguaje específico de dominio diseñado específicamente para supply chain: grandes conjuntos de datos tabulares, demanda probabilística, optimización económica, y así sucesivamente. Este lenguaje no es un lenguaje de programación empresarial genérico; es un entorno enfocado en hacer que las recetas de decisiones numéricas sean concisas y legibles.
Tercero, insistimos en que el resultado de nuestros cálculos no sea un panel de control, sino un conjunto de acciones propuestas que puedan aplicarse a los sistemas transaccionales. Si nuestro trabajo no se traduce en órdenes modificadas, stock modificado, precios cambiados, entonces no tiene razón de existir en producción.
Finalmente, estructuramos todo de modo que pueda ser reescrito. Si el mundo cambia, si una pandemia redefine la demanda, si una nueva categoría de producto se comporta de manera inesperada, nuestro objetivo es cambiar el código de forma rápida y segura, y no esperar años por una nueva versión de un producto.
Esta es una mentalidad muy diferente a intentar acumular más y más “características” genéricas en un producto de software. No intentamos ser todo para todos. Intentamos proporcionar un instrumento preciso que pueda usarse para expresar la lógica que realmente importa para una empresa determinada.
La visión convencional y dónde divergemos
El enfoque convencional de la tecnología de supply chain se basa en una aspiración razonable: estandarizar e industrializar los procesos de planificación. Enfatiza suites integradas, mejores prácticas predefinidas y una configuración amigable para el usuario. Promete un despliegue más rápido y una menor dependencia de habilidades técnicas escasas.
Hay situaciones en las que este enfoque aporta valor, especialmente cuando el negocio está relativamente cercano a los modelos estándar asumidos por el software, y donde los objetivos primarios son la visibilidad, la gobernanza y una coordinación básica.
Donde divergimos es en la respuesta a una pregunta específica:
¿Dónde debería una empresa situar la inteligencia que realmente decide qué hacer?
La respuesta convencional es: dentro de un producto configurable, mantenido por el proveedor, adaptado mediante parámetros, flujos de trabajo y extensiones.
Nuestra respuesta en Lokad es: dentro de una capa compacta y programable, operada por un pequeño equipo que posee la lógica de decisión y puede modificarla a medida que la realidad cambia.
De esta diferencia se derivan muchas consecuencias prácticas.
Desde un punto de vista centrado en el producto, la dificultad central es elegir e implementar el producto adecuado, y luego alinear a la organización con sus procesos y funcionalidades. Una vez que el producto está en funcionamiento, la atención se desplaza a usarlo correctamente: asegurar que la gente revise los paneles, siga los flujos de trabajo y complete las entradas.
Desde un punto de vista programático, la dificultad central es construir y mantener una buena receta numérica: una que refleje las economías reales del negocio, maneje la incertidumbre de manera significativa y pueda ser revisada rápidamente cuando sea necesario. La plataforma de software se juzga por lo bien que respalda ese esfuerzo: ¿podemos expresar restricciones complejas sin convertir la lógica en un revoltijo? ¿Podemos reejecutar las decisiones de ayer para entender qué ocurrió? ¿Podemos experimentar de manera segura con nuevas ideas?
Ambos enfoques cuentan con algoritmos, forecast, optimización e interfaces atractivas. La diferencia radica en quién controla en última instancia la lógica y cuán adaptable es esa lógica.
Un camino estrecho, pero necesario
El camino programático no es el más fácil de explicar. “Tendrás código que expresa tus decisiones de supply chain” suena menos glamoroso que “Tendrás un sistema inteligente con mejores prácticas configurables.” También requiere cierta disciplina: una propiedad clara, control de versiones riguroso, la instrumentación adecuada, y un despliegue cuidadoso.
Sin embargo, después de casi dos décadas observando el software de supply chain en la práctica, no veo ninguna alternativa viable si nos tomamos en serio la automatización.
Si queremos sistemas que hagan más que sugerir y visualizar; si queremos que asuman la responsabilidad de decisiones que mueven miles de millones de dólares en mercancías; si queremos que sobrevivan a choques y se adapten a restricciones recién descubiertas, entonces debemos darnos los medios para expresar la lógica con precisión y revisarla sin temor.
Eso es lo que ofrece la programabilidad.
Lokad existe porque creo que la supply chain es demasiado importante para dejarla a configuraciones opacas y productos rígidos. Se merece un software que reconozca la realidad desordenada y peculiar de cada negocio, y que brinde a quienes gestionan la supply chain las herramientas que necesitan para codificar su comprensión en una forma que pueda realmente actuar.
Esta perspectiva explica tanto las decisiones tecnológicas que hemos tomado como la forma en que trabajamos con nuestros clientes. No vendemos una caja que pretenda contener inteligencia. Ofrecemos una forma de construirla, perfeccionarla y mantenerla viva.
