Más rápido que “un clic”: Por qué los supply chain programables ganan en velocidad

Joannes Vermorel

En supply chain, hablamos mucho sobre velocidad. Velocidad de reposición. Velocidad de respuesta. Velocidad de recuperación cuando algo sale mal. Sin embargo, cuando se trata de los sistemas destinados a respaldar estas decisiones, la conversación sobre la velocidad se reduce rápidamente a una única métrica: ¿cuántas semanas se tarda en “entrar en funcionamiento” después de firmar un contrato de software?

La mayoría de los grandes proveedores de software para supply chain tienen una respuesta muy clara a esa pregunta. Prometen un rápido retorno de la inversión a través de contenido preconfigurado, modelos de datos estándar y “mejores prácticas de la industria.” Si observas el marketing de suites de planificación integrada y sistemas de planificación avanzada, la narrativa es notablemente consistente: comienza con su modelo de referencia, aplica una colección de plantillas, y puedes estar en producción en “unas pocas semanas” o “tan solo 12 semanas,” a veces expresado explícitamente como “de Excel a planificación avanzada en semanas.”

Recientemente, intenté distanciarme de esta narrativa en mi libro Introducción a Supply Chain, donde enmarco supply chain como el negocio de tomar decisiones rentables bajo incertidumbre, día tras día. Si tomamos ese punto de vista en serio, la pregunta “¿qué tan rápido podemos desplegar el software?” se convierte en “¿qué tan rápido podemos poner decisiones automatizadas de alta calidad en producción—y mantenerlas alineadas con el negocio a medida que cambia?” Esa es una pregunta muy diferente.

Desde ahí, llego a una conclusión que va en contra de la corriente principal: para iniciativas serias de supply chain, un enfoque programable no solo es más poderoso que el software empaquetado tradicional; en realidad, es más rápido obtener resultados significativos en producción.

Permíteme explicar por qué.

La reconfortante promesa del software de supply chain preconfigurado

Los proveedores tradicionales de planificación empresarial ofrecen una historia reconfortante.

Comienzan con un modelo de datos canónico para supply chain: ubicaciones, productos, jerarquías, listas de materiales, calendarios, tiempos de entrega, restricciones. Además de este modelo, entregan procesos preconfigurados (“mejores prácticas”), conjuntos de datos de muestra, dashboards de plantilla, alertas, algoritmos estándar y guías de configuración. Todo este material está diseñado explícitamente para acelerar la implementación y reducir el riesgo del proyecto.

La lógica es perfectamente coherente. Si los datos y procesos de cada cliente pueden describirse como una modesta variación de una plantilla compartida, entonces la mayor parte del trabajo debería ser reutilizable. El proyecto de implementación se convierte en un asunto de mapear los campos del ERP en el modelo de planificación, activar las funciones relevantes, ajustar parámetros y enseñar a las personas cómo usar las pantallas.

En ese mundo, la personalización es un mal necesario. Se acepta para casos “especiales”, pero también se reconoce como la principal fuente de retrasos, sobrecostos y complejidad a largo plazo. Así, se impulsa la “configuración, no la personalización”—y más recientemente, las herramientas de low‑code y no‑code—para mantenerse dentro del margen seguro de lo que el software ya sabe hacer.

Bajo estas suposiciones, la idea de que el software empaquetado se despliega más rápidamente es perfectamente razonable.

La dificultad es que los supply chain reales rara vez se ajustan a esas suposiciones.

Donde los proyectos realmente se ralentizan: la semántica, no las pantallas

Cuando observas detenidamente dónde se invierte realmente el tiempo en implementaciones de grandes sistemas de supply chain, no es en instalar el software ni siquiera en capacitar a los usuarios. Es en entender lo que significan los datos.

La mayoría de las grandes empresas tienen uno o más ERPs, además de una colección dispersa de otros sistemas—CRM, WMS, TMS, PIM, ecommerce, etc. Juntos, contienen miles de tablas. Oficialmente, estas entidades tienen significados documentados; en la práctica, su verdadera semántica es el resultado de años de soluciones alternativas, convenciones locales, compromisos y limpiezas parciales. El comportamiento real del sistema se codifica en cómo lo usan las personas, no en cómo el proveedor original pretendía que se usara.

Cuando llega una suite de planificación, trae su propio modelo de datos y sus propias expectativas. Incluso cuando proviene del mismo proveedor que el ERP, la semántica no encaja de manera uniforme. Un campo llamado “tipo de ubicación” o “safety stock” no significa lo mismo en la configuración, en las operaciones diarias, en los informes y en el motor de planificación.

Alguien tiene que conciliar todo esto.

Esa persona suele ser un equipo mixto de TI, consultores y partes interesadas del negocio. Deben decidir qué tablas son autorizadas, qué campos son confiables, cómo manejar las excepciones, y cómo mapear la caótica realidad de la empresa en las estructuras limpias que espera el software de planificación. Escriben trabajos de extracción y transformación; añaden indicadores y atributos personalizados; inventan convenciones para codificar restricciones que el modelo estándar no puede expresar.

Este es el punto en el que el despliegue supuestamente “de un clic” a menudo se transforma en un esfuerzo de integración extenso. El software en sí puede estar en funcionamiento desde el primer día, pero los datos que necesita—los datos precisos, confiables y diarios que requiere un motor de optimización serio—toman meses o años en estabilizarse realmente.

Esto no es un fallo de implementación. Es un síntoma de un hecho más profundo: la semántica es local, y no existe una representación universal y lista para usar de la supply chain de una empresa determinada.

Supply chain como software, no como configuración

Si aceptamos que la semántica es local, y que sigue evolucionando a medida que el negocio cambia, entonces la distinción habitual entre “configuración” y “personalización” se vuelve engañosa.

Bajo la superficie, una iniciativa ambiciosa de supply chain siempre es un ejercicio de software. Es el acto de especificar, de forma precisa y ejecutable, cómo la empresa desea tomar decisiones sobre compras, producción, inventario, precios, asignación, y así sucesivamente, dadas los datos y restricciones disponibles.

En el modelo empaquetado tradicional, este software está formado por tablas de configuración, parámetros, diagramas de flujo, conectores personalizados y ocasionales “user exits” escritos en un lenguaje de propósito general. La esperanza es que la mayor parte de la lógica pueda expresarse mediante configuración, y solo los extremos requieran código.

En mi experiencia, especialmente en entornos complejos, sucede lo contrario. La lógica más crítica y diferenciadora termina implementándose de maneras frágiles: sobrecargando campos, superponiendo hojas de Excel y notebooks de Python junto al sistema oficial, y enseñando a los planificadores a interpretar los dashboards de una manera específica que en realidad no está codificada en ningún lugar.

El resultado neto es que el “sistema” está parcialmente en el software y parcialmente en la mente de las personas.

En Lokad, decidimos hace más de una década abrazar la naturaleza de software del problema en lugar de combatirla. Desarrollamos nuestro propio lenguaje específico de dominio, Envision, dirigido a los supply chain practitioners en lugar de a ingenieros de software profesionales. La idea es simple: representar todas las transformaciones de datos, todos los forecast, todas las restricciones y todas las decisiones como scripts que puedan ser leídos, versionados, probados y modificados de manera controlada.

Desde el exterior, esto se parece a un entorno de programación. Internamente, es nuestra respuesta al problema semántico: en lugar de forzar la compleja realidad en un modelo prefabricado, nos proporcionamos un lenguaje flexible para describir esa realidad tal como es en realidad.

Esto nos lleva de nuevo a la velocidad.

¿Qué significa ser “rápido” en supply chain?

Si la velocidad se define como “el tiempo hasta que el proveedor del software pueda declarar un go‑live de acuerdo con su lista de verificación,” entonces las suites preconfiguradas a menudo parecerán más rápidas. El plan del proyecto está optimizado para ese hito. El modelo canónico está diseñado para llenarse rápidamente. El material de capacitación y las mejores prácticas están alineados con ese objetivo específico.

Sin embargo, si la velocidad se define como “el tiempo hasta que tengamos un flujo de decisiones automatizado en vivo en el que confiemos con dinero real,” el panorama cambia.

En un enfoque programable, la secuencia del proyecto típicamente se ve así:

Primero, establece extracciones diarias confiables de los sistemas existentes, sin tratar de forzarlos a un nuevo modelo canónico. Esto sigue siendo un trabajo arduo, pero en su mayoría se trata de fontanería: extraer los datos en bruto, tal como son, en toda su fealdad.

Luego, en el entorno programable, expresa la lógica del negocio paso a paso: limpiar y conciliar los datos; expresar restricciones y prioridades; modelar la incertidumbre; y finalmente, calcular decisiones concretas como cantidades de pedido, planes de producción o opciones de asignación. Debido a que esta lógica se escribe en un lenguaje hecho a la medida, el ciclo de cambio es corto: un Supply Chain Scientist puede refinarla a diario o semanalmente a medida que aparecen casos extremos y nuevos requisitos.

Finalmente, pon estas decisiones en ejecución dual: compara lo que proponen los scripts con lo que realmente hacen los planificadores, mide el impacto financiero y ajusta en consecuencia. Cuando la confianza sea lo suficientemente alta, permite que los scripts tomen el control de partes bien seleccionadas del portafolio.

El punto crucial es que esta secuencia es iterativa. En ningún momento esperamos que la primera versión de la lógica sea perfecta. Tampoco esperamos que el entorno se mantenga estático. En cambio, asumimos que las reglas de decisión tendrán que reescribirse sustancialmente cada año o dos a medida que el surtido, la red, las promesas de servicio y el panorama competitivo evolucionen.

En ese contexto, el principal determinante de la “velocidad” no es la fecha del primer go‑live. Es el tiempo promedio para cambiar: cuánto tiempo se tarda en ajustar el sistema cuando el negocio decide cambiar su forma de operar.

Si una política de precios tarda seis meses en codificarse en una suite de planificación monolítica, es irrelevante que la implementación original se haya completado a tiempo hace tres años.

Por qué la programabilidad se vuelve más rápida a lo largo de la vida completa del sistema

Visto desde el exterior, la programabilidad parece una carga. ¿No debe ser seguramente más lento escribir código que configurar una pantalla existente?

En casos simples, puede serlo. Si la supply chain es relativamente pequeña, estable y cercana al modelo de referencia del proveedor, entonces una solución preconfigurada podría, de hecho, alcanzar un estado estable aceptable rápidamente. Muchas empresas no exigen mucho a sus herramientas de planificación; las utilizan como hojas de cálculo estructuradas con interfaces de usuario más agradables y algunas alertas. En ese contexto, el enfoque empaquetado puede ser adecuado y, en un sentido limitado, más rápido.

El panorama cambia dramáticamente en cuanto nos trasladamos a entornos que son:

• grandes y heterogéneos (múltiples ERPs, diferentes unidades de negocio, muchos tipos de productos y canales),
• volátiles (surtidos, tiempos de entrega y promesas de servicio que cambian frecuentemente),
• y ambiciosos (con el objetivo de altos grados de automatización, no solo de soporte de decisiones).

En esos casos, las soluciones preconfiguradas enfrentan tres desafíos estructurales.

Primero, la brecha semántica es demasiado amplia. Cuantas más excepciones y convenciones locales haya, más habrá que ajustar el modelo canónico para adaptarse a ellas. Cada ajuste se convierte en un truco de configuración, una extensión personalizada o un proceso secundario. Con el tiempo, el sistema acumula capas de casos especiales que son difíciles de entender y aún más difíciles de limpiar.

Segundo, el coste del cambio está controlado externamente. Cambiar la lógica de una suite de planificación importante generalmente implica múltiples capas: TI interna, consultores externos, a veces el propio proveedor. Existen ciclos de lanzamiento, protocolos de pruebas y procesos de gobernanza diseñados para la seguridad, no para la agilidad. Esto es comprensible, pero significa que incluso cambios sensatos y moderados pueden tardar meses.

Tercero, la lógica en sí se envejece rápidamente. Las reglas de supply chain que tenían sentido hace tres años rara vez son óptimas hoy. Cuando el coste de revisarlas es alto, las organizaciones tienden a posponer el esfuerzo. Parchean los bordes con hojas de cálculo, ajustes y soluciones de emergencia.

En contraste, un enfoque programable paga la mayor parte de su coste por adelantado: debes aceptar que esencialmente estás escribiendo software. Pero una vez que tienes un entorno dedicado para este software—uno que es lo suficientemente especializado como para ser accesible a los expertos en supply chain, pero lo suficientemente expresivo como para describir la realidad del negocio—la economía del cambio se invierte.

Agregar una nueva restricción, integrar una nueva fuente de datos o revisar la forma en que manejas las promociones se convierte en una cuestión de editar scripts en lugar de negociar una nueva fase de implementación. Debido a que la lógica de decisión es explícita, puedes versionarla, probarla y revertirla. Debido a que está centralizada en lugar de dispersa en tablas de configuración y archivos auxiliares, puedes razonar sobre ella en su totalidad.

A lo largo de la vida útil del sistema, esta capacidad de cambiar rápidamente tiende a dominar el beneficio puntual de un go‑live inicial rápido.

Esto no es un rechazo al software mainstream

Sería un error interpretar esto como un argumento contra todo el software empaquetado para supply chain. Estos sistemas resuelven muchos problemas de manera efectiva. Proporcionan un procesamiento de transacciones robusto; se integran con un amplio ecosistema; ofrecen interfaces de usuario, modelos de seguridad, auditabilidad y características de cumplimiento que serían costosas de reproducir desde cero.

Tampoco es un llamado a que cada empresa desarrolle todo internamente utilizando lenguajes de programación de propósito general. Ese camino conduce rápidamente a su propio tipo de fragilidad, con scripts hechos a medida proliferando sin disciplina.

Lo que estoy proponiendo es diferente: un núcleo programático para la lógica de decisión, rodeado por lo mejor de los sistemas empaquetados para todo lo demás.

En otras palabras, utiliza tu ERP, WMS y TMS para lo que son buenos: registrar lo que realmente ocurrió, hacer cumplir reglas de negocio simples y orquestar flujos de trabajo. Usa suites de planificación especializadas donde sus características estándar realmente se ajusten a tus necesidades. Pero no esperes que esas herramientas empaquetadas sean el lugar donde resida la lógica de decisión más importante, dinámica y diferenciadora.

Para eso, necesitas algo que acepte desde el principio que tu supply chain es única, que cambiará, y que toda iniciativa seria eventualmente se enfrentará a detalles semánticos que ninguna plantilla anticipó.

Un lenguaje de dominio específico como Envision es una posible respuesta. Es el que hemos construido y afinado en Lokad durante muchos años, precisamente para dar a los expertos en supply chain la capacidad de expresar y mantener su propia lógica directamente, sin tener que pasar por capas de intermediarios.

Otros proveedores han perseguido ideas similares en diferentes formas; lo que importa no es la etiqueta “DSL”, sino el principio subyacente: la lógica de decisión debe ser de primera clase, programable y propiedad de las personas que entienden la economía del negocio.

Repensando la velocidad

Si redefinimos la velocidad como “¿qué tan rápido podemos poner en producción decisiones robustas y automatizadas, y qué tan rápido podemos revisarlas siempre que sea necesario?”, la conclusión es ineludible.

A corto plazo, las suites preconfiguradas a menudo parecen más rápidas porque minimizan el trabajo visible al principio y optimizan para una puesta en marcha ceremonial. A mediano y largo plazo, su rigidez y el costo del cambio las hacen más lentas precisamente donde la velocidad es más necesaria: cuando el entorno empresarial cambia.

Un enfoque programático acepta más trabajo desde el principio, pero genera dividendos cada vez que la realidad se desvía de las suposiciones iniciales—es decir, todo el tiempo. En un mundo donde la incertidumbre es la norma en lugar de la excepción, ese tipo de velocidad importa más que el número de semanas en una diapositiva de implementación.

La cuestión, entonces, no es si quieres escribir software para tu supply chain. Si tu negocio es lo suficientemente grande y complejo, ya lo haces—mediante configuración, mediante hojas de cálculo, mediante scripts locales y convenciones manuales. La única pregunta real es si quieres que ese software sea explícito, coherente y esté bajo tu control.

Mi respuesta es clara: si nos importa la velocidad en un sentido significativo, el supply chain debe ser programable.