AI / ML in planning — what works, what does not · D02 Supply Chain Planning · SCRA

01What it isQué es

A disciplined AI/ML-in-planning practice asks not "should we use ML" but "where does ML beat the baseline" — selecting techniques by where they demonstrably outperform established statistical methods, benchmarking every model against a simple baseline, and deploying only where the lift is real and the data supports it, instead of applying ML by hype to problems a simpler method already solves better.

Una práctica disciplinada de IA/ML en planeación no pregunta "¿debemos usar ML?" sino "¿dónde ML le gana al baseline?" — seleccionando técnicas por dónde superan demostrablemente a los métodos estadísticos establecidos, comparando cada modelo contra un baseline simple, y desplegando solo donde el lift es real y los datos lo soportan, en vez de aplicar ML por hype a problemas que un método más simple ya resuelve mejor.

02Why it mattersPor qué importa

Makridakis, Spiliotis & Assimakopoulos 2018 (Makridakis et al., 2018 — peer-reviewed), comparing machine-learning and statistical forecasting methods, found that the ML methods did not systematically outperform far simpler statistical ones and were often beaten by them — while costing far more in computation and complexity. The result is not anti-ML; it is that the technique must be matched to the problem, and complexity is not a proxy for accuracy. Planning organizations routinely ignore this, applying black-box ML to smooth series a simple model forecasts better, or launching ML on data that cannot support it. The pilots fail to beat the baseline they were never measured against, and each failure erodes leadership's trust — so that the genuine ML opportunities, where the lift is real, get starved of credibility by the hype-driven ones that never should have launched.

Makridakis, Spiliotis & Assimakopoulos 2018 (Makridakis et al., 2018 — peer-reviewed), comparando métodos de pronóstico de machine learning y estadísticos, encontró que los métodos de ML no superaban sistemáticamente a otros mucho más simples y a menudo eran vencidos por ellos — mientras costaban mucho más en cómputo y complejidad. El resultado no es anti-ML; es que la técnica debe emparejarse al problema, y la complejidad no es un proxy de precisión. Las organizaciones de planeación ignoran esto de rutina, aplicando ML de caja negra a series suaves que un modelo simple pronostica mejor, o lanzando ML sobre datos que no pueden soportarlo. Los pilotos fallan en vencer al baseline contra el que nunca se midieron, y cada fracaso erosiona la confianza del liderazgo — de modo que las oportunidades genuinas de ML, donde el lift es real, quedan hambreadas de credibilidad por las impulsadas por hype que nunca debieron lanzarse.

03How it is doneCómo se hace

Start from the problem, not the technique. Define the planning problem and ask what method fits it, rather than starting with "we want to use ML." Technique-first projects look for a problem to justify the tool; problem-first projects find the method — sometimes ML, often not — that actually wins.

Benchmark every model against a simple baseline. The naive seasonal forecast and a standard statistical model are the bar. An ML model that does not beat them out-of-sample has failed regardless of its sophistication, and deploying it anyway is paying more for less.

Target ML where it has a structural edge. ML earns its complexity on problems with many interacting drivers, non-linearities, rich external signals, or high-dimensional patterns — demand sensing, complex promotions, image/text inputs. It rarely beats a good statistical model on a clean, smooth univariate series. Match the method to the problem's shape.

Verify the data can support the model. ML is more data-hungry and more sensitive to data quality than statistical methods. On fragmented or thin data, a complex model overfits and underperforms. Confirm the integrated data foundation exists before launching the model that depends on it.

Keep the model interpretable enough to trust and govern. A black-box forecast planners cannot interrogate will be overridden or ignored, destroying its value. Favor models whose drivers can be explained, and measure forecast value-add so the model's contribution is visible and accountable.

Industrialize only what survives the benchmark. Move a model from pilot to production only after it beats the baseline on out-of-sample data with a maintainable pipeline. Scaling a model that never cleared the bar institutionalizes the cost and the distrust; scaling a proven one is where the real value compounds.

Worked example — illustrativeA company launched a deep-learning forecasting initiative across the entire catalog — baseline: never benchmarked against the existing statistical forecast, beaten by it on the smooth A-items, ML pilot declared a failure, leadership trust in analytics damaged. It restarted problem-first: kept statistical methods for smooth series, targeted ML only at demand sensing and complex promotions where it had an edge, benchmarked everything against the naive and statistical baselines. Results: ML deployed on the ~20% of problems where it genuinely beat the baseline, measurable accuracy lift there, and analytics credibility rebuilt — because the technique was finally matched to the problem.

Empieza por el problema, no la técnica. Define el problema de planeación y pregunta qué método le ajusta, en vez de empezar con "queremos usar ML". Los proyectos técnica-primero buscan un problema que justifique la herramienta; los proyectos problema-primero encuentran el método — a veces ML, a menudo no — que de verdad gana.

Compara cada modelo contra un baseline simple. El pronóstico estacional ingenuo y un modelo estadístico estándar son la vara. Un modelo de ML que no les gana fuera de muestra ha fallado sin importar su sofisticación, y desplegarlo de todos modos es pagar más por menos.

Apunta el ML donde tiene una ventaja estructural. El ML gana su complejidad en problemas con muchos drivers que interactúan, no-linealidades, señales externas ricas o patrones de alta dimensión — demand sensing, promociones complejas, inputs de imagen/texto. Rara vez le gana a un buen modelo estadístico en una serie univariada limpia y suave. Empareja el método a la forma del problema.

Verifica que los datos puedan soportar el modelo. El ML es más hambriento de datos y más sensible a la calidad de datos que los métodos estadísticos. Sobre datos fragmentados o escasos, un modelo complejo sobreajusta y rinde peor. Confirma que el cimiento de datos integrado existe antes de lanzar el modelo que depende de él.

Mantén el modelo lo bastante interpretable para confiar y gobernar. Un pronóstico de caja negra que los planeadores no pueden interrogar será anulado o ignorado, destruyendo su valor. Favorece modelos cuyos drivers puedan explicarse, y mide el valor agregado del pronóstico para que la contribución del modelo sea visible y rendible.

Industrializa solo lo que sobrevive el benchmark. Mueve un modelo de piloto a producción solo después de que le gane al baseline en datos fuera de muestra con un pipeline mantenible. Escalar un modelo que nunca pasó la vara institucionaliza el costo y la desconfianza; escalar uno probado es donde el valor real se compone.

Ejemplo trabajado — ilustrativoUna empresa lanzó una iniciativa de pronóstico con deep learning a través de todo el catálogo — base: nunca comparada contra el pronóstico estadístico existente, vencida por él en los A-items suaves, piloto de ML declarado un fracaso, confianza del liderazgo en analítica dañada. Reinició problema-primero: mantuvo métodos estadísticos para series suaves, apuntó el ML solo a demand sensing y promociones complejas donde tenía ventaja, comparó todo contra los baselines ingenuo y estadístico. Resultados: ML desplegado en el ~20% de los problemas donde de verdad le ganó al baseline, lift de precisión medible ahí, y credibilidad de analítica reconstruida — porque la técnica por fin se emparejó al problema.

04The concept in depthEl concepto a fondo

⚖️Complexity is not accuracy›

The empirical evidence is that sophisticated ML does not systematically beat simple statistical methods across forecasting problems — and is frequently beaten by them at far higher cost. The right method depends on the problem's structure, not on how advanced it sounds. Treating complexity as a proxy for accuracy is the root assumption behind most failed planning-AI initiatives.

🎯Where ML has a structural edge›

ML earns its complexity where the problem has many interacting drivers, non-linearities, high-frequency external signals, or high-dimensional inputs — demand sensing, complex promotional response, unstructured data. On a clean, smooth univariate series, a well-chosen statistical model usually wins. Knowing the shape of problem that suits ML is the difference between a hype project and a value project.

🔍The benchmark and interpretability discipline›

Two disciplines separate ML that works from ML that fails: benchmarking every model against a naive and statistical baseline out-of-sample, and keeping it interpretable enough that planners trust and govern it. A black box that beats nothing measurable, and that planners cannot interrogate, is a cost with no defensible value.

⚖️La complejidad no es precisión›

La evidencia empírica es que el ML sofisticado no le gana sistemáticamente a los métodos estadísticos simples a través de los problemas de pronóstico — y con frecuencia es vencido por ellos a costo mucho mayor. El método correcto depende de la estructura del problema, no de qué tan avanzado suena. Tratar la complejidad como proxy de precisión es el supuesto raíz detrás de la mayoría de las iniciativas fallidas de IA en planeación.

🎯Dónde el ML tiene ventaja estructural›

El ML gana su complejidad donde el problema tiene muchos drivers que interactúan, no-linealidades, señales externas de alta frecuencia o inputs de alta dimensión — demand sensing, respuesta promocional compleja, datos no estructurados. En una serie univariada limpia y suave, un modelo estadístico bien elegido usualmente gana. Conocer la forma de problema que conviene al ML es la diferencia entre un proyecto de hype y uno de valor.

🔍La disciplina de benchmark e interpretabilidad›

Dos disciplinas separan el ML que funciona del que falla: comparar cada modelo contra un baseline ingenuo y estadístico fuera de muestra, y mantenerlo lo bastante interpretable para que los planeadores confíen y lo gobiernen. Una caja negra que no le gana a nada medible, y que los planeadores no pueden interrogar, es un costo sin valor defendible.

05In practiceEn la práctica

🧪Baseline-benchmark every model›

Make beating the naive and statistical baseline out-of-sample a mandatory gate before any model advances. The benchmark is the single discipline that prevents complexity from masquerading as value; no model earns deployment without clearing it.

🎯Match technique to problem shape›

Reserve ML for problems with the structure that rewards it and keep statistical methods where they win. A portfolio that uses the right method per problem outperforms one that applies a single fashionable technique everywhere — and costs less to run and maintain.

📊Measure forecast value-add on every model›

Track whether each model — and each human override of it — adds or destroys accuracy versus the baseline. FVA makes the model's real contribution visible and turns "we use AI" into "the AI adds X points of accuracy here," which is the only claim worth making.

🔗Sequence ML after data and process maturity›

Deploy ML only once the integrated data layer and sound process exist beneath it. ML on fragmented data and a broken process amplifies the dysfunction and fails the benchmark; the maturity sequence — process, data, then advanced analytics — is what gives ML the foundation it needs to actually win.

🧪Compara contra baseline cada modelo›

Haz de vencer al baseline ingenuo y estadístico fuera de muestra una compuerta obligatoria antes de que cualquier modelo avance. El benchmark es la única disciplina que evita que la complejidad se disfrace de valor; ningún modelo se gana el despliegue sin pasarla.

🎯Empareja la técnica a la forma del problema›

Reserva el ML para problemas con la estructura que lo premia y mantén los métodos estadísticos donde ganan. Un portafolio que usa el método correcto por problema supera a uno que aplica una sola técnica de moda en todos lados — y cuesta menos correr y mantener.

📊Mide el valor agregado del pronóstico en cada modelo›

Rastrea si cada modelo — y cada override humano de él — agrega o destruye precisión versus el baseline. El FVA hace visible la contribución real del modelo y convierte "usamos IA" en "la IA agrega X puntos de precisión aquí", que es la única afirmación que vale la pena hacer.

🔗Secuencia el ML después de la madurez de datos y proceso›

Despliega ML solo una vez que la capa de datos integrada y el proceso sólido existen debajo. El ML sobre datos fragmentados y un proceso roto amplifica la disfunción y falla el benchmark; la secuencia de madurez — proceso, datos, luego analítica avanzada — es lo que le da al ML el cimiento que necesita para de verdad ganar.

06What you would useQué se usa

📌 AI / ML IN PLANNING

🟦o9 / SAP IBP / Kinaxis — embedded ML in planning›

Planning platforms with embedded ML for demand sensing, forecasting, and pattern detection, governed within the planning workflow and benchmarked against statistical baselines. (o9, SAP, Kinaxis — vendor) The choice when ML should live inside the plan with FVA and benchmark discipline built in.

🟩Blue Yonder / RELEX — applied ML for retail/CPG›

Strong applied ML for demand sensing, promotions, and replenishment where the problem structure rewards it. (Blue Yonder, RELEX — vendor) A solid fit where ML targets the high-driver problems — promotions, store-level sensing — it genuinely improves.

🟥Data-science platforms (Databricks, open-source ML)›

General ML and data-science platforms for custom models where packaged planning ML falls short. (Databricks, open-source frameworks — vendor) The vertical option when the ML problem is bespoke and the team has the capability to build and govern it rigorously.

⬜For operations that don't need ML yet›

Well-chosen statistical methods (Python statsforecast, R fable) benchmarked rigorously — which beat misapplied ML on most planning problems. The honest answer for many organizations is that the baseline is the right tool; ML is the next step only where a benchmarked pilot proves it wins.

📌 IA / ML EN PLANEACIÓN

🟦o9 / SAP IBP / Kinaxis — ML embebido en planeación›

Plataformas de planeación con ML embebido para demand sensing, pronóstico y detección de patrones, gobernado dentro del workflow de planeación y comparado contra baselines estadísticos. (o9, SAP, Kinaxis — vendor) La opción cuando el ML debe vivir dentro del plan con disciplina de FVA y benchmark incorporada.

🟩Blue Yonder / RELEX — ML aplicado para retail/CPG›

ML aplicado sólido para demand sensing, promociones y reabasto donde la estructura del problema lo premia. (Blue Yonder, RELEX — vendor) Un buen ajuste donde el ML apunta a los problemas de muchos drivers — promociones, sensing a nivel tienda — que de verdad mejora.

🟥Plataformas de ciencia de datos (Databricks, ML open-source)›

Plataformas generales de ML y ciencia de datos para modelos a la medida donde el ML de planeación empaquetado se queda corto. (Databricks, frameworks open-source — vendor) La opción vertical cuando el problema de ML es a la medida y el equipo tiene la capacidad de construirlo y gobernarlo rigurosamente.

⬜Para operaciones que aún no necesitan ML›

Métodos estadísticos bien elegidos (Python statsforecast, R fable) comparados rigurosamente — que le ganan al ML mal aplicado en la mayoría de los problemas de planeación. La respuesta honesta para muchas organizaciones es que el baseline es la herramienta correcta; el ML es el siguiente paso solo donde un piloto comparado prueba que gana.

The bottom lineEn corto

Operations that benchmark ML against a simple baseline and deploy it only where it wins capture real lift and protect their analytics credibility; operations that apply ML by hype launch pilots that lose to a naive forecast and burn the trust the genuine opportunities needed. The most expensive AI mistake in planning is not under-investing — it is deploying complexity where a simple method already wins, then mistaking the failure for proof that AI does not work. Match the technique to the problem, measure against the baseline, and let the lift, not the hype, decide.

Las operaciones que comparan el ML contra un baseline simple y lo despliegan solo donde gana capturan lift real y protegen su credibilidad de analítica; las que aplican ML por hype lanzan pilotos que pierden contra un pronóstico ingenuo y queman la confianza que las oportunidades genuinas necesitaban. El error de IA más caro en planeación no es sub-invertir — es desplegar complejidad donde un método simple ya gana, y luego confundir el fracaso con prueba de que la IA no funciona. Empareja la técnica al problema, mide contra el baseline, y deja que el lift, no el hype, decida.

← PreviousAnteriorPlanning data architecture & MDMArquitectura de datos de planeación y MDM NextSiguiente →Planning talent model & operating rhythmModelo de talento de planeación y ritmo operativo

All D02 componentsTodos los componentes de D02 D02 artifactsArtifacts de D02 SCRA