Por qué ERP nunca gestionará tu supply chain
Los proveedores de software empresarial suelen llamar a sus plataformas la “columna vertebral digital” de la empresa. En el supply chain, esta columna generalmente se traduce en ERP, acompañado por un elenco de sistemas como MRP, WMS, TMS, CRM y otros similares. Para muchas organizaciones, el siguiente paso natural parece obvio: si el ERP ya gestiona las transacciones, ¿por qué no dejarle gestionar también las decisiones? Agrega algunos módulos de planificación, un motor de forecast, algunas funcionalidades de IA, y la supply chain se encargará, más o menos, de sí misma.
Después de casi dos décadas dedicadas a construir software que hace exactamente lo contrario, he llegado a una conclusión algo descortés: los proveedores transaccionales habituales están estructuralmente mal preparados para ofrecer sistemas de decisión de supply chain satisfactorios. Esto no es una queja sobre su competencia. Se trata de la categoría de software que venden, los incentivos económicos a los que se enfrentan y las expectativas que el mercado ha puesto sobre ellos.
Exploro este argumento en profundidad en mi libro Introduction to Supply Chain, pero quiero destacar un aspecto aquí: por qué “dónde reside el cerebro” en tu paisaje de software importa más de lo que admite la mayor parte de la literatura.
Lo que realmente le pedimos al software que haga
Las supply chain modernas no se tratan solo de mover cajas de manera eficiente. Se tratan de apostar en condiciones de incertidumbre, cada día.
¿Debemos comprar un contenedor o tres? ¿Retrasar una promoción o adelantarla? ¿Enviar stock escaso a Europa o a EE. UU.? ¿Aceptar la cantidad mínima de pedido de este proveedor o rechazarla y arriesgar una ruptura? Cada decisión es una pequeña apuesta con consecuencias asimétricas. Algunos errores cuestan poco; otros cuestan mucho y siguen costando durante meses.
Hace cincuenta años, los humanos podían plausiblemente mantener la mayoría de estas apuestas en la mente, asistidos por libros contables y hojas de cálculo. Hoy, incluso las empresas medianas gestionan decenas de miles de SKUs, cientos de ubicaciones, tiempos de entrega volátiles y patrones de demanda que reaccionan a precios, clima, marketing, competidores y disrupciones en el suministro. La combinatoria está simplemente fuera del alcance del juicio humano sin ayuda.
Así que pedimos la ayuda del software. Pero “software” no es una sola cosa. En una empresa típica, coexisten tres tipos muy diferentes de sistemas:
Primero, están los sistemas transaccionales: ERP, MRP, WMS, TMS, OMS. Su función es capturar todo lo que sucede: órdenes, recibos, envíos, facturas, movimientos de entrada y salida de ubicaciones. Son libros contables glorificados con flujos de trabajo. Sus principales virtudes son la fiabilidad, la trazabilidad, los permisos y la auditabilidad. Si un envío se realiza dos veces o un pago desaparece, todo lo demás carece de sentido.
En segundo lugar, están los sistemas de reportes y analytics: herramientas BI, dashboards, portales de KPI, hojas de cálculo alimentadas por data warehouses. Su función es resumir y visualizar lo que ha ocurrido, y a veces lo que podría ocurrir. Están diseñados para que los humanos los inspeccionen: gráficos, tablas, listas de excepciones, reportes de variación.
Por último, hay algo que en la práctica en su mayoría falta: un verdadero motor de decisiones. Con esto me refiero a un software cuya función principal es tomar todos esos datos en bruto, comprender sus patrones, evaluar opciones y luego emitir decisiones concretas y auditables: órdenes de compra, movimientos de asignación, planes de producción, cambios de precio, cambios de surtido. Estas decisiones deberían producirse de forma rutinaria y sin supervisión, y luego ser reinsertadas en los sistemas transaccionales como si un planificador muy consistente y muy rápido hubiera realizado el trabajo.
La visión dominante tiende a difuminar estos tres roles. Si la “columna vertebral” del ERP ya integra datos y gestiona los procesos, seguramente también puede planificar y optimizar. Si no, otra plataforma polivalente lo hará: un “digital core”, una “control tower” o una “unified planning suite”. En la literatura, rutinariamente se describe al ERP como el núcleo del procesamiento de la información empresarial y la columna vertebral de la empresa, presentándose la planificación y ejecución de la supply chain como extensiones naturales de esa misma plataforma.
En teoría, esto resulta atractivo. En la práctica, es precisamente donde empiezan a salir mal las cosas.
Por qué los proveedores transaccionales están en el negocio equivocado para construir el cerebro
Para entender el desajuste, es útil alejarse del branding y observar lo que el ERP y sus primos realmente son.
En su esencia, estos sistemas son grandes bases de datos multiusuario con reglas estrictas sobre quién puede cambiar qué, y en qué secuencia. Están optimizados para muchas operaciones pequeñas, simples y bien estructuradas que ocurren simultáneamente: registrar esta orden, contabilizar esa factura, confirmar este recibo. Cuando los libros de texto sobre ERP los denominan la “columna vertebral” de la empresa, lo dicen en sentido literal: transportan los nervios y los vasos sanguíneos de las operaciones diarias.
Un verdadero motor de decisiones, en contraste, no está optimizado para miles de clics ligeros. Está optimizado para el pensamiento profundo.
Necesita ingerir grandes cantidades de datos, a menudo de múltiples sistemas. Necesita explorar muchos futuros posibles, no solo extrapolar un forecast único. Necesita evaluar opciones según criterios económicos, no solo niveles de servicio o objetivos de tiempo de entrega. Necesita realizar cálculos que ocasionalmente son costosos: modelos probabilísticos, simulaciones, optimizaciones combinatorias. Y debe hacer todo esto de una manera que pueda ser auditada posteriormente: ¿por qué compramos veinte palets de este artículo en ese día, en lugar de quince o ninguno?
No se trata de cuestión de lenguaje de programación o de optimización ingeniosa. Es un perfil de tiempo de ejecución diferente, distintos compromisos de ingeniería y diferentes formas de responsabilidad. Colocar este tipo de motor en el mismo entorno que gestiona tus facturas diarias y pantallas de almacén es como montar un motor a reacción dentro de un autobús urbano. No es simplemente excesivo; interfiere activamente con el funcionamiento del autobús.
A partir de ahí, surgen varios problemas estructurales.
El primero es operacional. Si intentas ejecutar análisis avanzados y grandes trabajos de optimización directamente en tu plataforma transaccional, o bien limitas el trabajo analítico para evitar ralentizar las operaciones, o arriesgas comprometer los tiempos de respuesta cuando los humanos intentan realizar su trabajo. Cuanto más logres incorporar “inteligencia”, más se degrada la misión principal del sistema: no perder nunca una transacción y nunca bloquear a un usuario.
El segundo es semántico. Las empresas modernas rara vez operan con un único monolito. Tienen ERP para las finanzas y operaciones centrales, WMS para almacenes, TMS para transporte, CRM para interacciones con clientes, e‑commerce platforms, y a veces sistemas especializados para manufactura o venta al por menor. Cada uno de estos sistemas tiene su propio vocabulario y su propia versión de la verdad. Sin embargo, un motor de decisiones útil debe abarcarlos todos. La tendencia natural de los proveedores de ERP, no obstante, es tratar su propio esquema como el centro del universo. Todo lo demás se mapea en él de manera con pérdida o se ignora.
El tercero es económico. Los grandes proveedores transaccionales son mayormente remunerados por licencias, asientos, módulos y almacenamiento; en la era de la computación en la nube, se añaden niveles de suscripción y consumo. No se les paga en función de cuántas decisiones pueden automatizar de manera segura o de cuánto efectivo devuelven a tu P&L. De hecho, un motor de decisiones verdaderamente efectivo reduciría el número de asientos de “planner” y simplificaría muchos flujos de trabajo. Esto no es lo que su modelo de precios está diseñado para recompensar.
Superponiendo esto al ecosistema de certificaciones, la imagen se vuelve aún más clara. El programa APICS/ASCM CPIM, por ejemplo, se presenta explícitamente como el estándar global para la planificación y gestión de inventario, y el material de capacitación señala abiertamente que los sistemas ERP incorporan reglas de negocio derivadas de este cuerpo de conocimiento.
En otras palabras: se asume que la lógica de planificación estándar reside dentro del ERP. Se espera que los proveedores la codifiquen; se espera que los profesionales la configuren y sigan. La misión es alinear la práctica con el canon, no replantear la arquitectura del software o la economía de las decisiones.
Finalmente, está la cultura. Construir sistemas de registro tiende a atraer, recompensar y promover una mentalidad de ingeniería particular: aquella que valora la estabilidad, la compatibilidad retroactiva y la cobertura de casos extremos. Con el paso de las décadas, estos sistemas acumulan capas de funcionalidad, módulos, personalizaciones e integraciones. Se vuelven extremadamente capaces, pero también extremadamente complejos. Agregar otro módulo de planificación o característica de IA es culturalmente más fácil que eliminar cualquier cosa. El resultado es una masa en constante crecimiento de pantallas de configuración y parámetros, entretejidos en flujos de trabajo que ya son frágiles.
Pedirle a esta máquina que se reinvente como un motor de decisiones agudo y con opinión propia es, en el mejor de los casos, optimista.
La narrativa dominante, en sus propias palabras
Si lees material de los proveedores, white papers, y gran parte de la literatura académica y profesional, verás la misma historia repetida con variaciones menores.
El ERP se presenta como una plataforma unificadora que integra todos los datos y procesos, “harmonizando” la adquisición, el inventario, el procesamiento de órdenes y la distribución, al tiempo que incorpora herramientas de analytics y planificación. Se describe como la base de software del negocio, el “digital core” que sustenta todo, desde las finanzas hasta la manufactura y la supply chain. Sobre esta base se nos prometen características cada vez más avanzadas: demand forecasting impulsado por predictive analytics, modelado de escenarios, planificación empresarial integrada y más.
En paralelo, el canon de la gestión operativa proporciona los modelos mentales: el cuerpo de conocimiento CPIM, marcos de S&OP, fórmulas de stock de seguridad, lógica MRP. Estos se codifican como mejores prácticas, programas de exámenes y modelos de madurez. La promesa implícita es simple: si implementas el ERP adecuado, lo configuras de acuerdo con estos estándares y capacitas a tus planners en consecuencia, tu supply chain se comportará adecuadamente.
Si la realidad no coincide con la promesa, las explicaciones habituales son conocidas: calidad de los datos, gestión del cambio, alcance del proyecto, falta de patrocinio ejecutivo, capacitación insuficiente. El remedio es siempre lo mismo: implementaciones más cuidadosas, procesos más disciplinados y una adopción más completa del cuerpo de conocimiento estándar.
Observa lo que rara vez se cuestiona: la suposición de que el “cerebro” de la supply chain debe residir dentro de los mismos sistemas que registran órdenes e imprimen facturas.
Lo que realmente sucede en el terreno
En la práctica, la mayoría de las organizaciones terminan con un patrón desconcertantemente consistente a través de industrias y geografías.
Los sistemas transaccionales cumplen razonablemente bien su función. Las órdenes fluyen, el stock se mueve, las facturas se emiten, se realizan los cierres financieros. Siempre hay rarezas y frustraciones, pero en general los libros contables se mantienen.
Alrededor de este núcleo, proliferan los reportes. Herramientas BI se conectan a data warehouses, que extraen datos del ERP y sus satélites. Los equipos construyen dashboards, scorecards, cockpits y control towers. Los planners dedican una creciente fracción de su tiempo navegando por estas pantallas, conciliando discrepancias entre ellas, exportando datos a hojas de cálculo y reimportando números “ajustados”.
Existen módulos de planificación y optimización en muchos de estos sistemas. Generan forecasts, proponen cantidades de reposición, emiten alertas. Sin embargo, la mayor parte del trabajo pesado sigue siendo manual. Los forecasts se anulan. Las órdenes sugeridas se “revisan” una por una. Las listas de excepciones se alargan hasta que nadie puede despejarlas razonablemente en una jornada laboral, así que las personas desarrollan heurísticas locales: confiar en estos indicadores, ignorar aquellos, favorecer siempre a este proveedor, nunca tocar esos artículos.
La automatización toma principalmente la forma de lógica condicional dentro de los sistemas transaccionales: si la disponibilidad está por encima de cierto nivel, liberar esta orden; si está por debajo, colocarla en una cola de excepciones. A distancia, esto puede parecer un comportamiento inteligente. De cerca, son reglas frágiles más estrategias de afrontamiento humano.
A veces llamo a esta situación “automation as paperwork”: los sistemas son elaborados, ajetreados, incluso impresionantes, pero rara vez asumen la plena responsabilidad de una decisión que tiene un peso financiero real. Siempre se espera que un humano haga clic en “OK” en algún lugar, incluso si ese clic se ha convertido en un ritual.
Esto no es lo que parece un motor de decisiones maduro.
Una separación de preocupaciones diferente
Si tomamos en serio la idea de que la supply chain es una práctica diaria de toma de decisiones económicas bajo incertidumbre, entonces deberíamos diseñar el paisaje de software para reflejar eso.
En ese paisaje, los sistemas transaccionales continúan haciendo lo que mejor saben hacer: siguen siendo el registro autorizado de lo que ha ocurrido y lo que está actualmente comprometido. Sus esquemas y flujos de trabajo seguirán evolucionando, y seguirán siendo críticos. Pero dejamos de pedirles que sean ingeniosos.
Los sistemas de reporting continúan haciendo lo que mejor saben hacer: ayudan a los humanos a ver, entender y discutir lo que está sucediendo. Los buenos dashboards y las analytics seguirán siendo invaluables. Pero dejamos de confundir la visualización con la optimización.
Luego, por separado, introducimos un motor de decisiones dedicado.
Este motor recibe flujos regulares de datos en bruto de todos los sistemas transaccionales relevantes: órdenes, posiciones de stock, capacidades, tiempos de entrega, precios, restricciones. No le importa si estos datos provienen del ERP, WMS, TMS o de cualquier otro sistema. Reconstruye una visión coherente del mundo a partir de estos hechos, reconoce explícitamente la incertidumbre en la demanda y el suministro, y evalúa acciones alternativas según sus consecuencias financieras: margen esperado, riesgo de faltante de stock, costo de obsolescencia, costos de oportunidad en recursos limitados.
La salida de este motor no es un dashboard. Es un flujo de acciones propuestas: comprar esta cantidad de ese SKU de ese proveedor en esa fecha; enviar estos palets de este almacén a aquel esta noche; aumentar el precio de este artículo en dos por ciento; eliminar gradualmente esa variante durante el próximo mes. Cada acción viene acompañada de suficiente contexto para que un humano pueda auditarla si es necesario: qué datos utilizó, qué patrones infería, qué compensaciones realizó.
Crucialmente, estas acciones se reescriben en los sistemas transaccionales utilizando interfaces bien definidas. La orden de compra se crea en ERP como si un planificador la hubiera tecleado. La transferencia de stock aparece en el WMS como si un encargado de almacén la hubiese iniciado. El cambio de precio se refleja en el sistema de precios con una fecha de validez clara.
Los humanos no desaparecen del circuito. Su rol cambia. Se convierten en custodios de la receta numérica: deciden qué costos incluir, cómo valorar el riesgo, qué restricciones son reales y qué escenarios son aceptables. Revisan y refinan el comportamiento del motor, en lugar de microgestionar cada línea que produce.
Esta arquitectura suena exótica solo si has pasado demasiado tiempo en la narrativa centrada en ERP. Desde la perspectiva de la ingeniería de software y la economía, es simplemente una separación limpia de responsabilidades: libros contables para los hechos, dashboards para la comprensión, motores para las decisiones.
Cómo esto confronta la visión dominante
Visto desde este ángulo, la narrativa dominante no es “incorrecta” tanto como incompleta.
Es perfectamente razonable querer una columna vertebral transaccional integrada. Las empresas se beneficiaron enormemente del alejamiento de sistemas fragmentados de contabilidad, inventario y manufactura hacia un ERP integrado. También es razonable desear buenos reportes y estandarizar la terminología y los procesos en toda la profesión. Iniciativas como CPIM han jugado un papel importante al proporcionar a las personas un lenguaje compartido y un conjunto básico de herramientas.
Donde discrepo del enfoque dominante es en el supuesto implícito de que, si seguimos enriqueciendo la columna vertebral transaccional con más módulos de planificación, más forecast features, más análisis y más opciones de configuración, eventualmente llegaremos a decisiones de supply chain efectivas y automatizadas.
No creo que esta convergencia ocurra.
Mientras se espera que el “cerebro” viva dentro de sistemas cuya misión primaria y modelo de negocio sean el registro, flujos de trabajo basados en roles y prácticas genéricas, seguiremos atrapados en un patrón de interfaces impresionantes y automatización tímida. Continuaremos viendo organizaciones donde los planificadores pasan sus días manipulando listas de alertas en lugar de moldear la lógica económica que genera dichas alertas.
La alternativa no es desechar el ERP ni ignorar los métodos establecidos. Es tratarlos por lo que son: infraestructura necesaria y un valioso legado profesional, pero no el lugar donde se deben tomar las decisiones reales.
Una vez que aceptamos esta distinción, se vuelve posible una conversación más honesta. Podemos pedir a nuestros proveedores transaccionales excelentes libros contables e interfaces limpias, en lugar de “optimización potenciada por AI”. Podemos solicitar a nuestros equipos de BI vistas simples y veraces de la realidad, en lugar de dashboards animados que pretenden ser salas de control. Y podemos exigir a nuestros motores de decisiones—y a las personas que los construyen y operan—un estándar más alto: decisiones nocturnas, no atendidas, responsables en efectivo, continuamente mejoradas.
Esta es la dirección que hemos seguido en Lokad durante muchos años. No es el único camino, pero es uno que parte de una observación simple: cuando tu supply chain está efectivamente limitada por software, entonces dónde coloques el “cerebro” de ese software hace toda la diferencia.
