Software de optimización minorista, febrero 2025

Por Léon Levinas-Ménard

Última modificación: 2 de febrero de 2025

Introducción: Los minoristas de hoy se enfrentan a complejos problemas de optimización que abarcan niveles de inventario, estrategias de precios y surtidos de productos. Una variedad de proveedores de software promete soluciones “impulsadas por AI” para abordar estos retos, pero separar la verdadera innovación tecnológica de los sistemas heredados y del bombo publicitario requiere un análisis riguroso. Este estudio evalúa a los principales proveedores de software de optimización minorista frente a criterios rigurosos. Nos enfocamos en capacidades de optimización conjunta (inventario, precios y surtido juntos), en forecast probabilístico (forecast de AI/ML reales vs. métodos simplistas), en el modelado de decisiones económicas (decisiones basadas en beneficios y en costos de oportunidad en lugar de reglas estáticas), en la escalabilidad y eficiencia en costos (capacidad para manejar grandes redes minoristas sin requerir hardware exorbitante), en el manejo de factores complejos del retail (por ejemplo, canibalización de productos, efectos de sustitución, productos perecederos/vencimientos), en la automatización (nivel de toma de decisiones autónoma frente a intervenciones manuales requeridas), en la integración tecnológica (una pila tecnológica coherente frente a plataformas “Frankenstein” ensambladas a partir de adquisiciones) y en un enfoque escéptico hacia las palabras de moda (“demand sensing”, “plug-and-play”, etc.). Cada proveedor es analizado con profundidad de ingeniería, utilizando evidencia creíble y minimizando la dependencia del marketing del proveedor. A continuación, clasificamos a los proveedores de más avanzado a menos, destacando fortalezas, debilidades y la verdad detrás de sus afirmaciones.

Criterios de Evaluación para Plataformas de Optimización Minorista

Antes de adentrarnos en los perfiles de los proveedores, resumimos los principales criterios de evaluación aplicados:

Optimización conjunta (Inventario + Precios + Surtido): ¿La solución optimiza estas dimensiones de forma holística, reconociendo su interdependencia? ¿O se tratan estas funciones de manera aislada? Las plataformas verdaderamente avanzadas tratan los precios, el inventario y el surtido como palancas integradas de un único problema de optimización, en lugar de módulos separados ¹. Por ejemplo, cambiar un precio debería retroalimentar a los forecast de inventario y a las decisiones de surtido en un modelo unificado.
Forecast probabilístico y AI: ¿Emplea el proveedor técnicas modernas de AI/machine learning para producir forecast probabilísticos (distribuciones de la demanda en lugar de predicciones de un solo punto)? El forecast probabilístico es crítico para tomar decisiones robustas ante la incertidumbre ². Buscamos evidencia de modelos de machine learning, redes neuronales u otra AI que mejoren la precisión del forecast aprendiendo patrones complejos (estacionalidad, tendencias, promociones, etc.) y cuantifiquen la incertidumbre. Se penaliza a los proveedores que aún dependen de métodos simplistas (como ajustes manuales o fórmulas básicas) o que tratan los forecast como puntos deterministas.
Toma de Decisiones Económicas: ¿Están las decisiones de la plataforma guiadas por objetivos económicos (maximización de beneficios, compensaciones entre costo de stock y faltante de stock, ROI del espacio en estantería, etc.)? Optimizar el retail requiere más que alcanzar tasas de llenado – implica maximizar el beneficio esperado ante la incertidumbre. Preferimos soluciones que incorporen márgenes, costos de mantenimiento, costos de rebajas y costos de oportunidad en sus algoritmos. Las heurísticas basadas en reglas o los objetivos de nivel de servicio pueden quedar cortos si ignoran la meta última de rentabilidad ³.
Escalabilidad y Eficiencia en Costos: ¿Puede el software manejar datos minoristas a escala empresarial (miles de tiendas, millones de SKUs, altos volúmenes de transacciones) de forma eficiente? Las soluciones que dependen de cálculos monolíticos en memoria (por ejemplo, cargar conjuntos de datos completos en la RAM) pueden tener dificultades a gran escala o requerir hardware prohibitivamente costoso ⁴. Preferimos arquitecturas nativas en la nube, microservicios y computación distribuida que escalen de forma rentable, y penalizamos aquellas conocidas por altos costos de hardware o bajo rendimiento en big data.
Manejo de Factores Complejos del Retail: La demanda real en el retail es desordenada – la canibalización de productos (la promoción de un producto que le quita ventas a otro ⁵ ⁶), efectos de sustitución (cuando un artículo está faltante de stock, la demanda de un artículo similar aumenta), efectos “halo” (productos complementarios que se impulsan mutuamente ⁷), picos estacionales, variación regional y productos perecederos con fechas de vencimiento. Evaluamos si los algoritmos de cada proveedor abordan explícitamente estas complejidades – por ejemplo, utilizando machine learning para identificar relaciones entre productos ⁸ ⁹, o mediante el seguimiento del inventario por lotes de vencimiento. Las soluciones que asumen que la demanda de cada producto es independiente o ignoran la perecibilidad son menos preparadas para el futuro del retail moderno.
Automatización y Operación sin Supervisión: La promesa del “retail autónomo” es que el sistema puede tomar la mayoría de las decisiones operativas (órdenes, cambios de precios, rebajas, cambios en el surtido) automáticamente, permitiendo que los humanos se centren en excepciones estratégicas. Evaluamos si el software facilita una planificación sin intervención – por ejemplo, pedidos de reposición automáticos basados en forecast, ajustes automáticos de precios dentro de límites establecidos – o si aún depende de que los planificadores revisen y anulen manualmente las decisiones de forma constante. Los proveedores que promocionan AI idealmente deberían reducir la carga de trabajo manual (“la rutina de la planificación”, como se suele decir ¹⁰), y no aumentarla.
Integración Tecnológica vs. Plataformas Frankenstein: Muchos grandes proveedores crecieron mediante adquisiciones, añadiendo herramientas separadas de forecast, precios y planificación bajo una misma marca. Examinamos si la solución del proveedor es una plataforma coherente o un ensamblaje de módulos con diferentes interfaces de usuario y modelos de datos. La integración “Frankensoft” a menudo conduce a una alta complejidad y tiempos de implementación elevados ¹¹. Las soluciones verdaderamente modernas tienden a estar construidas sobre una pila tecnológica unificada o, al menos, integradas de forma fluida mediante microservicios. Penalizamos a los proveedores donde las piezas aún no se integran completamente (a pesar de los reclamos de marketing de una plataforma “unificada”).
Escepticismo ante Palabras de Moda y Hype: El sector tecnológico minorista está repleto de palabras de moda como “demand sensing,” “AI-driven, plug-and-play integration,” “cognitive supply chain,” etc. Nuestro análisis descarta afirmaciones vagas y busca fundamento. Se critica a aquellos proveedores que se apoyan en jerga sin explicaciones claras o respaldo de revisiones por pares. Por ejemplo, “demand sensing” a menudo se cita como una solución universal, pero algunos expertos lo califican como un truco de marketing que no logra entregar un valor novedoso ¹². Resaltamos tales casos y favorecemos a los proveedores que ofrecen evidencia concreta y creíble de sus capacidades.

Con estos criterios en mente, examinemos a los principales proveedores en optimización minorista y clasifiquémoslos. Cada sección del proveedor destaca cómo se desempeña en cada dimensión, con un enfoque particularmente escéptico ante las afirmaciones exageradas.

1. Lokad – Optimización unificada y probabilística con AI escéptica

Lokad es un nuevo participante (fundado en 2008) que ha construido su plataforma desde cero alrededor de forecast probabilístico y optimización de decisiones para el retail y supply chain. A diferencia de muchos competidores, Lokad se propuso explícitamente unificar la fijación de precios, el inventario y la planificación de la demanda en un solo sistema, en lugar de tratarlos como compartimentos estancos ¹³ ¹⁴. Este enfoque se basa en la comprensión de que las decisiones de precios influyen directamente en la demanda y las necesidades de inventario, y viceversa. El fundador de Lokad ha señalado que, históricamente, el forecast y la fijación de precios se manejaban con herramientas diferentes, pero en realidad “la demanda y los precios están profundamente interconectados”, lo que llevó a Lokad a fusionar estas funciones en un único marco analítico ¹⁵ ¹⁶. Incluso desarrollaron su propio lenguaje de programación específico del dominio (“Envision”) para modelar decisiones de supply chain, permitiendo una optimización altamente personalizada que puede englobar la lógica de precios, inventario y surtido conjuntamente ¹⁷ ¹⁶.

Optimización conjunta: La filosofía de Lokad es que no se puede optimizar el inventario sin tener en cuenta la estrategia de precios, y viceversa. Han integrado la fijación de precios y la planificación de la demanda en una sola plataforma – por ejemplo, su sistema puede optimizar las cantidades de reorden mientras sugiere ajustes de precios simultáneamente, garantizando que los precios no desincronicen la demanda respecto al inventario ¹. Un estudio de caso interno discute una estrategia de “precios basados en el stock” en la que los precios se ajustan dinámicamente según los niveles de inventario, coordinando efectivamente los precios con la disponibilidad del inventario. Al compartir los mismos datos (historial de ventas, información del producto, etc.) tanto para los modelos de fijación de precios como para los de forecast, Lokad evita los compartimentos estancos de datos que se observan en la IT minorista tradicional ¹⁸ ¹⁶. Este enfoque conjunto es de vanguardia, aunque requiere que los minoristas adopten la fijación de precios algorítmica – un aspecto significativo de la gestión del cambio. La disposición de Lokad a abordar conjuntamente precios e inventario le otorga una capacidad verdaderamente orientada al futuro que pocos proveedores heredados han alcanzado.

Forecast probabilístico y AI: Lokad es un firme defensor del forecast probabilístico. Su plataforma produce distribuciones de probabilidad completas de la demanda (para cada artículo y periodo) en lugar de forecast de un solo punto. Lokad argumenta – y nosotros concurremos – que “para supply chains, los forecast probabilísticos son esenciales para producir decisiones robustas ante condiciones futuras inciertas”, permitiendo la optimización de decisiones basadas en valores esperados y en el riesgo ³. Al capturar el rango de posibles resultados de la demanda y sus probabilidades, los forecast de Lokad apoyan de manera natural la toma de decisiones económicas: “la perspectiva probabilística se presta de forma natural a la priorización económica de decisiones basadas en sus retornos esperados pero inciertos.” ³ En la práctica, esto significa que Lokad puede evaluar, por ejemplo, la rentabilidad esperada de almacenar una caja extra de un producto frente al riesgo de desperdicio, utilizando la distribución completa de la demanda. Técnicamente, Lokad emplea modelos de machine learning de última generación (incluyendo regresión cuantílica y deep learning) para generar estos forecast, y han publicado evidencia del uso de técnicas como la programación diferenciable para series de tiempo. Debido a que su enfoque está en la precisión de la AI y en la cuantificación de la incertidumbre, evitan métricas simplistas; notablemente, critican medidas como MAPE (Error Porcentual Absoluto Medio) cuando se aplican a forecast probabilísticos por considerarlas conceptualmente inválidas ¹⁹. Esto demuestra una profundidad en la comprensión del forecast que los distingue de proveedores que simplemente añaden “AI” a estadísticas heredadas. La tecnología de forecast de Lokad es claramente de vanguardia, aunque a veces requiere una configuración especializada mediante su lenguaje de secuencias.

Lógica de Decisión Económica: Todo el marco de Lokad se construye en torno a la optimización económica. Frecuentemente enmarcan los problemas de supply chain como “maximización del beneficio esperado” ante la incertidumbre, en lugar de lograr tasas de llenado arbitrarias o minimizar el faltante de stock. Por ejemplo, sus algoritmos consideran explícitamente los costos de oportunidad de los faltantes de stock, los costos de mantenimiento y los costos de rebajas al recomendar compras de inventario o cambios de precios. Debido a que generan forecast probabilísticos, pueden calcular la rentabilidad esperada de cada decisión (por ejemplo, cuánto beneficio se obtiene al almacenar una unidad adicional frente a la posibilidad de que no se venda). Esto es un avance respecto a muchas herramientas que dependen de objetivos de nivel de servicio establecidos por el usuario; Lokad intenta calcular de manera dinámica el nivel de servicio óptimo por artículo a partir de los fundamentos económicos. En esencia, sus decisiones están directamente vinculadas a resultados financieros (por ejemplo, maximizando la contribución esperada al margen), en consonancia con el criterio de optimización basada en la rentabilidad. Este enfoque se fundamenta en su convicción de que la optimización de supply chain no se trata solo de reducir costos, sino de asignar recursos para maximizar los retornos. Una consecuencia es la capacidad de hacer cosas como optimización de precios combinada con forecast de demanda – evitando la trampa de las herramientas de precios que ignoran las restricciones del inventario. El propio Lokad advierte que “optimizar los precios de forma aislada – independiente del forecast de demanda – es retrógrado” ²⁰ ²¹. Al incorporar la fijación de precios en el ciclo de forecast/optimización, aseguran que los cálculos de beneficio reflejen la verdadera respuesta de la demanda. En general, la orientación económica de Lokad es de primera clase; sin embargo, requiere confianza en el algoritmo. Los minoristas deben estar dispuestos a dejar que un algoritmo realice compensaciones de rentabilidad que antes los planificadores manejaban manualmente, lo cual puede representar un obstáculo cultural.

Escalabilidad y Arquitectura: Lokad ofrece su solución como un servicio basado en la nube (a menudo en la infraestructura de Microsoft Azure). En lugar de requerir que los clientes ejecuten servidores pesados en memoria de forma local, Lokad realiza los cálculos en su clúster en la nube, escalando según sea necesario. Este modelo de cómputo bajo demanda evita el enfoque del “cubo en memoria cableado” que algunas herramientas heredadas utilizan, el cual “proporciona reportes en tiempo real impresionantes pero garantiza altos costos de hardware” ²². En contraste, Lokad puede procesar grandes conjuntos de datos distribuyendo la carga de trabajo en la nube, y los clientes solo pagan por el tiempo de cómputo utilizado. Esto resulta eficiente en costos y escalable – se pueden asignar más nodos de cómputo a un gran problema durante unas horas en lugar de dimensionar un servidor permanente para los picos de carga. La arquitectura de Lokad es de código primero (mediante scripts Envision), lo que significa que los cálculos complejos se compilan y ejecutan de forma eficiente en el servidor, en lugar de realizarse en una torpe interfaz de escritorio. Este diseño ha demostrado ser capaz en conjuntos de datos minoristas razonablemente grandes (se citan clientes con decenas de millones de combinaciones SKU-ubicación). Sin embargo, cabe señalar que Lokad es un proveedor más pequeño, y su escalabilidad, aunque generalmente sólida, puede no haber sido probada a fondo en los conjuntos de datos minoristas absolutamente más grandes (por ejemplo, a escala de Walmart) al mismo nivel que SAP u Oracle. Dicho esto, su enfoque en la nube es fundamentalmente más escalable que los sistemas locales limitados por la memoria. La eficiencia en costos también es alta: a los usuarios no se les obliga a licenciar hardware masivo ni a pagar por cómputo inactivo, ya que el precio SaaS de Lokad se basa en el uso. En resumen, la moderna arquitectura en la nube de Lokad le otorga una ventaja en escalabilidad y costo, siempre que los clientes estén abiertos a un sistema menos tradicional basado en código.

Manejo de Factores Complejos en el Retail: Dado que la plataforma de Lokad es, esencialmente, un entorno de programación flexible para la optimización, se puede configurar para manejar de forma explícita fenómenos complejos del retail. Por ejemplo, los usuarios pueden modelar las interrelaciones de productos (sustitutos o complementos) en sus scripts de Envision de modo que los forecast y los pedidos tengan en cuenta la cannibalización o los efectos halo. Si los productos A y B son sustitutos, el sistema de Lokad puede ingerir datos transaccionales y aprender que cuando A está en faltante de stock, las ventas de B aumentan, ajustando los forecast en consecuencia. Esto no es necesariamente una característica lista para usar activada por una casilla de verificación – requiere trabajo de data science para configurar el modelo adecuado – pero la capacidad existe. De forma similar, se pueden modelar los efectos de promoción: Lokad puede usar calendarios promocionales como insumos e incluso optimizar el pricing promocional. En cuanto a productos perecederos y fechas de caducidad, Lokad puede incorporar la vida útil restante en su lógica de optimización (por ejemplo, aumentando la prioridad de vender artículos a medida que se acercan a su fecha de expiración mediante descuentos o evitando el sobrestock de productos de corta vida). La fortaleza clave es la flexibilidad: a diferencia de los rígidos sistemas heredados, el enfoque de Lokad puede codificar prácticamente cualquier restricción o factor, siempre que se disponga de datos y experiencia. La desventaja es que puede no contar con un “módulo de cannibalización” preconfigurado – el usuario (o el equipo de Lokad) debe implementar la lógica. Aun así, muchos proveedores simplemente ignoran estas sutilezas por completo. El propio equipo de Lokad ha publicado sobre temas como la integración de la cannibalización en los forecast mediante machine learning (por ejemplo, identificando sustitutos a través de correlaciones de ventas), lo que indica que son conscientes y capaces de abordarlo de forma similar a los principales especialistas en retail ⁸ ⁹. En la práctica, para un minorista con dinámicas complejas de categoría, Lokad probablemente implementaría un proyecto de modelado personalizado. Este enfoque hecho a la medida puede ofrecer un manejo muy preciso de factores como la cannibalización, pero requiere una configuración más consultiva en lugar de plug-and-play, dado el historial de Lokad (por ejemplo, trabajando con minoristas de moda en curvas de tallas, minoristas de comestibles en promos), han demostrado que pueden manejar estos factores al menos tan bien como los principales competidores.

Automatización: La visión de Lokad se orienta fuertemente hacia la toma de decisiones sin intervención humana. Su plataforma se describe a menudo como “Supply Chain Optimization as a Service”, lo que implica que el usuario la configura y, de forma automática, produce decisiones (como pedidos de reposición o cambios de precio) de manera continua ²³. La idea es que los planificadores pasen de hacer cálculos manuales a supervisar decisiones impulsadas por AI. El sistema de Lokad puede generar recomendaciones de pedidos diarias o semanales que se integran directamente en el ERP del minorista para su ejecución, con mínimas intervenciones humanas. Debido a que los forecast son probabilísticos y la optimización se centra en el beneficio, la idea es que el sistema tome la decisión óptima y no requiera la validación instintiva de un planificador para, por ejemplo, cada cantidad de pedido. Por supuesto, en la realidad las empresas suelen revisar las recomendaciones inicialmente, pero se sabe que muchos clientes de Lokad han alcanzado un alto grado de automatización (maniobrando manualmente solo excepciones como nuevos productos o grandes eventos). El énfasis en un modo “piloto automático” es un factor distintivo – mientras que algunas herramientas antiguas son de soporte a la decisión y dependen de los planificadores para interpretar, Lokad aspira a ser un software de toma de decisiones. Un ejemplo de éxito en automatización: un minorista de comestibles que utiliza Lokad pudo implementar una reposición automática en tiendas que se ajustaba de forma adaptativa a los cambios en la demanda, logrando, al mismo tiempo, una reducción significativa del deterioro y del faltante de stock ²⁴. Esto se alinea con hallazgos de la industria que indican que una reposición automática impulsada por forecast puede recortar los desechos en porcentajes de dos dígitos. La capacidad de scripting de Lokad permite a los usuarios codificar reglas de negocio (por ejemplo, no permitir jamás que el inventario caiga por debajo de un stock mínimo de presentación) de modo que la automatización respete las restricciones del mundo real. En general, Lokad obtiene excelentes calificaciones por impulsar una optimización verdaderamente sin intervención humana. La única salvedad es que la configuración inicial (codificación y prueba del modelo) requiere un gran esfuerzo; hasta que el modelo sea adecuado, no querrías automatizar las decisiones. Pero una vez afinado, el sistema puede operar con una mínima intervención humana, muy por encima del nivel de automatización de los sistemas heredados de MRP o de planificación.

Integración de Tecnología: Lokad se ha desarrollado íntegramente de manera interna sobre una pila tecnológica coherente. No creció mediante la adquisición de software de otras empresas; en cambio, desarrolló su propio motor de forecast, solucionador de optimización y lenguaje de scripting. Esto da lugar a una plataforma integrada – todas las funcionalidades (forecasting, pricing, optimización de inventario) operan sobre el mismo modelo de datos y lenguaje. No existen “módulos” que integrar a través de interfaces; todo se realiza en el entorno de Envision. Esto contrasta marcadamente con algunos competidores que deben unir una herramienta de pricing adquirida con una herramienta de planificación separada. El enfoque unificado de Lokad reduce la complejidad y evita inconsistencias. Por ejemplo, el resultado del forecast de demanda fluye directamente hacia la lógica de optimización de precios dentro del mismo script – sin necesidad de transferencias de archivos por lotes o incómodas llamadas API entre sistemas diferentes. Además, la plataforma de Lokad es relativamente ligera (no requiere una base de datos relacional completa ni un cubo OLAP; su almacenamiento y capacidad de cómputo están optimizados para su propósito específico). Se podría decir que la pila tecnológica de Lokad es “a prueba de futuro” en el sentido de que se mejora continuamente en su conjunto, en lugar de tener componentes heredados que requieran ser reemplazados. La contrapartida de esta tecnología tan original es que es única – los clientes deben aprender la forma de trabajar de Lokad, que es diferente a las herramientas típicas de planificación con GUI. Pero, desde el punto de vista ingenieril, la cohesión de la pila tecnológica es excelente. No hay un Frankenstein de piezas adquiridas; incluso su interfaz y sus analíticas están diseñadas especialmente en torno a su motor central. Esta simplicidad también significa menos puntos de fallo en la integración – un gran plus al aspirar a una automatización total.

Escepticismo hacia el Hype: Notablemente, Lokad es explícitamente escéptico respecto a los eslóganes de la industria y esta mentalidad impregna el posicionamiento de su producto. La compañía ha publicado críticas de conceptos como “demand sensing”, calificándolo como “otro eslogan más en supply chain que no cumple con las expectativas”, siendo, en esencia, mootware (software que existe pero no logra entregar valor) ¹². Esta perspectiva escéptica es, en realidad, una fortaleza: sugiere que Lokad procura fundamentar su producto en ciencia sólida en lugar de en un marketing impulsado por modas. Por ejemplo, Lokad no se lanzó a la moda del “blockchain supply chain” ni sobrevendió la retórica del “digital twin” (la cual también fue criticada por su fundador). En cambio, se centra en capacidades técnicas tangibles como el forecasting probabilístico y la optimización por cuantiles. En cuanto a las afirmaciones de los proveedores, las de Lokad son, en general, concretas. Evitan reclamar implementaciones “plug-and-play” imposiblemente fáciles o una IA mágica lista para usar. De hecho, suelen advertir que desplegar una optimización avanzada es complejo y requiere que se haga a la medida para cada negocio (de ahí su énfasis en un lenguaje de programación para codificar las especificaciones de cada cliente). Esta honestidad resulta refrescante en un ámbito lleno de promesas desmesuradas. La desventaja es que un mensaje poco orientado al marketing puede hacer que Lokad parezca menos llamativo en comparación con competidores que promocionan en voz alta una “supply chain autónoma con cognitive AI”. Pero, desde una perspectiva de búsqueda de la verdad, las afirmaciones de Lokad tienden a estar fundamentadas – por ejemplo, si hablan de una reducción de stock del 5% en un cliente, generalmente lo explican en un estudio de caso detallado, y no de forma genérica. Incluso discuten abiertamente las limitaciones de las técnicas (se pueden encontrar entradas en el blog de Lokad desglosando dónde fallan los métodos clásicos). Esta transparencia construye credibilidad. En conjunto, Lokad emerge como una solución para tecnólogos – basada en sólidos principios de ingeniería y analítica, combinando forecasting y optimización, y evitando el hype. El enfoque es, indudablemente, el estándar de oro en sofisticación técnica (probabilístico, basado en el beneficio, cloud-architected). La principal salvedad es que Lokad es más pequeño y menos probado a gran escala que algunos incumbentes, y su modelo requiere una implementación personalizada y especializada por cliente en lugar de una solución preempaquetada. Pero, en términos de capacidad pura y de un diseño orientado al futuro, Lokad se posiciona como un proveedor líder en la optimización del retail.

Resumen: Lokad lidera en la optimización conjunta (pricing integrado con inventario), utiliza true probabilistic AI forecasting ³, optimiza para beneficio y costo de oportunidad, se escala mediante una arquitectura nativa en la nube y coste-eficiente, maneja las complejidades del retail a través de un modelado flexible, permite una alta automatización, cuenta con una pila tecnológica interna coherente y mantiene una postura escéptica refrescante frente al hype. Representa un enfoque a prueba de futuro, aunque uno que podría requerir más trabajo analítico inicial.

Sources: La integración de datos de pricing y planificación de Lokad ²⁵; énfasis en forecast probabilísticos para decisiones robustas y enfocadas en el beneficio ³; crítica a eslóganes como demand sensing ¹².

2. RELEX Solutions – Retail-Focused Unified Planning with Advanced AI (and Some Heavy Lifting)

RELEX Solutions (fundada en 2005) es un proveedor de rápido crecimiento especializado en planificación y optimización para el retail, abarcando forecasting, reposición, asignación, surtido y, ahora, optimización de precios. RELEX ha forjado una reputación en los sectores de comestibles y retail especializado al ofrecer mejoras medibles en disponibilidad y reducción de desperdicios. Su plataforma está diseñada específicamente para los desafíos del retail (productos de corta vida útil, enormes cantidades de SKU, planificación a nivel de tienda) y es conocida por utilizar machine learning avanzado y un motor de procesamiento de datos en memoria para lograr una capacidad de respuesta en tiempo real. RELEX ofrece una solución unificada que abarca forecast de demanda, reposición automática, planificación de espacio y de surtido, y, recientemente, pricing – lo que la convierte en uno de los pocos proveedores, además de Lokad, que puede afirmar abordar los tres pilares (inventario, pricing, surtido) de forma integrada. La compañía posee una fuerte cultura de ingeniería (fundada por tres doctorados en informática) y ha invertido intensamente en I+D de AI para el retail. Valoramos a RELEX de forma muy alta por sus capacidades específicas para el retail y por los resultados comprobados, aunque también señalamos algunas posibles desventajas en términos de la pesadez del sistema y el hecho de que, asimismo, debe respaldar su marketing con evidencias.

Optimización Conjunta: La plataforma de RELEX es relativamente holística para las operaciones de retail. Comenzó con forecasting y reposición, pero se expandió hacia la optimización de surtido y planogramación, y además ofrece módulos de optimización de precios ²⁶. Esto significa que un minorista puede usar RELEX para decidir qué productos ofrecer en cada tienda (surtido), cuánto inventario mantener (inventory) y a qué precio vender (pricing), todo dentro de un mismo sistema. La integración entre estos aspectos está en proceso – RELEX históricamente destacó en la optimización de inventario (reposicionando tiendas/centros de distribución) y en la planificación del espacio, y solo más recientemente añadió capacidades de optimización de precios. Sin embargo, anuncian que su optimización de precios está alineada con su motor de forecasting, lo que permite que se tomen decisiones de pricing con pleno conocimiento de los impactos en la demanda ²⁷. Por ejemplo, RELEX puede simular cómo un cambio de precio en un artículo clave afectará no solo las ventas de ese artículo, sino también las de productos complementarios o sustitutos, gracias a los mismos modelos de forecast subyacentes. Además, la función de planificación de promoción de RELEX integra las promociones de pricing en el proceso de planificación de la demanda: se introducen las promociones en el sistema, que luego ajusta los forecast y sugiere construcciones de inventario, e incluso puede recomendar mecánicas de promoción. Este nivel de consideración conjunta es sólido. Un aspecto destacado es la capacidad de RELEX para coordinar el espacio (capacidad de estantería) con el forecast – por ejemplo, si se espera que cambios en el surtido o en los precios impulsen un mayor volumen, el sistema alertará si el espacio en estantería resulta insuficiente. Dicho esto, es posible que RELEX aún no optimice el precio y el inventario de forma simultánea en un único algoritmo (probablemente primero realice un forecast iterativo de la demanda para un precio dado y, a continuación, optimice la reposición en consecuencia, en lugar de optimizar precio y stock conjuntamente para el beneficio). Aun así, dentro de una misma plataforma, los ciclos de retroalimentación son más ajustados que en un minorista que utiliza herramientas separadas. RELEX comercializa explícitamente la “planificación unificada para el retail”, y estudios de caso muestran a clientes empleándola de extremo a extremo (desde decisiones de surtido a largo plazo hasta pedidos diarios en tienda). Otorgamos a RELEX altas calificaciones por su amplitud, sin brechas funcionales evidentes en el ámbito del retail. La salvedad es que integrar todas estas piezas puede resultar complejo – es una suite, pero implementar cada módulo (merchandising, supply chain, pricing) es un proyecto importante.

Probabilistic Forecasting & AI: RELEX es conocido por su uso intensivo de AI/ML para mejorar la exactitud y granularidad del forecast. Han desarrollado modelos de machine learning que incorporan una variedad de impulsores de demanda: “estacionalidad, tendencias, patrones según el día de la semana, promociones, cambios en la exposición, días festivos, clima, acciones de competidores,” etc. ²⁸ ²⁹. Este enfoque multifactorial va más allá de los métodos tradicionales de series temporales. Los algoritmos de ML de RELEX detectan automáticamente qué factores son importantes para cada producto (selección de características) y pueden detectar cambios en los patrones de demanda (detección de puntos de cambio para cambios repentinos en las tendencias) ³⁰ ³¹. Una técnica impresionante que utilizan es el data pooling for sparse data – para artículos de lenta venta, el modelo agrupa productos similares para extraer señal y mejorar los forecasts ³¹. Todos estos son métodos modernos de AI que esperarías en un contexto académico, ahora desplegados en una herramienta comercial. El resultado, según afirman, son forecasts que “superan a los métodos tradicionales en velocidad, exactitud y granularidad” ³². De hecho, RELEX a menudo promociona métricas como una mejora porcentual significativa en la exactitud del forecast o en el nivel de servicio tras la implementación. Además, manejan la incertidumbre hasta cierto punto – por ejemplo, su sistema puede producir diferentes escenarios o intervalos de confianza para promociones (incorporan cannibalization and halo effects in promo forecasts utilizando ML para interpretar datos históricos ⁹). Durante las promociones, ajustan explícitamente los forecasts de productos relacionados hacia abajo o hacia arriba basándose en relaciones aprendidas de cannibalización/halo ⁹, reduciendo así el exceso de stock para los artículos cannibalizados y evitando faltante de stock para los artículos halo. Esto demuestra una comprensión probabilística sofisticada de los efectos cruzados entre productos. No está claro si RELEX genera distribuciones de probabilidad completas para todos los artículos (puede que simulen escenarios internamente, pero los planificadores ven principalmente forecasts ajustados). Sin embargo, su manejo de la variabilidad es avanzado – por ejemplo, mencionan tener en cuenta la inherente “volatilidad típica de los datos de retail” utilizando algoritmos adecuados para ello ³⁰.

Economic Decision-Making: El enfoque de optimización de RELEX históricamente se ha centrado en niveles de servicio y frescura en lugar de la optimización explícita de beneficios – algo que se entiende dada su base en el mercado de comestibles (donde evitar estanterías vacías y el deterioro es primordial). Sin embargo, han estado incorporando análisis más orientados a lo económico. Por ejemplo, su assortment rationalization utiliza AI para evaluar la rentabilidad de extremo a extremo de cada producto por tienda: identifica aquellos artículos de bajo rendimiento que no justifican su espacio en estantería analizando ventas, márgenes y los costos que generan ³³. Se señala que esta AI “detecta la rentabilidad de extremo a extremo de cada artículo por tienda, destacando a los de bajo rendimiento” ³³ – vinculando efectivamente las decisiones de surtido con los resultados financieros (eliminando aquello que no es rentable). Esto muestra que RELEX entiende que la optimización debe estar vinculada al beneficio, no solo a los volúmenes. En la optimización de inventario, RELEX permite establecer objetivos de nivel de servicio distintos por producto, potencialmente informados por el margen (artículos críticos frente a los menos rentables). No se basa puramente en el costo de oportunidad, como Lokad, pero puede aproximarse a la priorización económica al enfocar una mayor disponibilidad donde importa financieramente. En el ámbito de la fijación de precios, dado que RELEX ahora cuenta con un módulo de optimización de precios, la rentabilidad es central: la optimización de precios busca establecer tarifas para cumplir con los objetivos del negocio, que a menudo consisten en maximizar el margen o los ingresos bajo ciertas limitaciones. Podemos suponer que su AI de precios analiza la elasticidad y las compensaciones de margen (similar a la fijación de precios de Revionics o Blue Yonder). Además, la planificación de promociones de RELEX intenta maximizar el éxito de las mismas – lo que incluye evaluar el aumento frente al sacrificio de margen. Un indicativo revelador de la orientación económica son sus estudios de caso: por ejemplo, Franprix (un minorista francés) logró una reducción del 30% en el deterioro Y un 67% menos de faltante de stock usando RELEX, mejorando la rentabilidad mediante menos desperdicio y mayores ventas ²⁴. Esencialmente, optimizaron el equilibrio entre el coste del desperdicio y el nivel de servicio, lo cual es una optimización orientada a beneficios si se aborda de esa manera. Otro ejemplo es el uso de datos externos (como forecasts de pasajeros en aeropuertos para las tiendas de WHSmith) para alinear la oferta con la demanda real y prevenir el exceso de stock de alimentos frescos ³⁴ – nuevamente, reduciendo el desperdicio (coste) mientras se capturan ventas. Todo esto implica que las decisiones de RELEX, aunque tal vez no resuelvan una fórmula formal de maximización de beneficios, están muy orientadas a resultados económicos (menores costes por desperdicio, mayores ventas, mejor rotación de inventario). Puede que no generen explícitamente cálculos de “beneficio esperado” para cada decisión como lo haría Lokad, pero logran fines similares al enfocarse en KPIs empresariales que se correlacionan con el beneficio (por ejemplo, % de deterioro, % de faltante de stock, ingresos). A medida que incorporan la fijación de precios, se espera que RELEX avance aún más hacia una optimización unificada de los beneficios (por ejemplo, optimizando los calendarios de rebajas para vender artículos estacionales con el mayor margen posible sin stock residual). En resumen, el ADN de RELEX es algo más operativo (nivel de servicio y desperdicio) que financiero, pero reconocen e incorporan claramente la economía del retail en sus algoritmos, lo que los convierte en algo mucho más que un motor de reglas ciego.

Scalability & Performance: La arquitectura de RELEX se construye de forma notable sobre una base de datos in-memory de alto rendimiento con almacenamiento columnar para todos los datos de retail, lo que permite cálculos muy rápidos a través de grandes conjuntos de datos (una necesidad clave para la planificación a nivel de tienda-SKU). La ventaja es real-time analytics – los usuarios pueden, por ejemplo, ver inmediatamente el impacto de un cambio de parámetro en los pedidos, o recalcular un forecast al instante para miles de tiendas. Este diseño ha impresionado a muchos minoristas, pero viene a costa de un uso intensivo de hardware. De hecho, un análisis crítico señaló que “el diseño in-memory, similar a un cubo de BI, proporciona capacidades impresionantes de reporting en tiempo real pero garantiza altos costes de hardware.” ²². Esto se refiere al enfoque de RELEX: almacenar datos en memoria proporciona velocidad, pero escalar a, por ejemplo, una cadena nacional de comestibles con millones de combinaciones tienda-SKU puede requerir una memoria y capacidad de cómputo muy grandes. RELEX suele desplegarse como solución en la nube para sus clientes (lo alojan en cloud, posiblemente AWS o Azure, sin especificarlo públicamente), y ciertamente pueden escalar para grandes clientes (tienen varios clientes minoristas de miles de millones de dólares). La cuestión es la eficiencia de costes – RELEX puede requerir más recursos en la nube (y por tanto mayores costes) para lograr su rápida performance en comparación con una solución más orientada a procesamiento por lotes. Desde el punto de vista de scalability, RELEX ha demostrado ser capaz para grandes minoristas en Europa y Norteamérica. El sistema puede manejar pedidos por tienda para miles de tiendas a diario. Un cliente mediano de RELEX a menudo gestiona decenas de miles de SKUs con reforecasts subdiarios. El bottleneck puede surgir al añadir más módulos: integrar datos de surtido y planogramas (que son enormes) con el motor de forecasting puede aumentar aún más los volúmenes de datos. RELEX ha estado abordando esto optimizando sus algoritmos y quizá descargando algunos cálculos en disco o en nodos distribuidos, pero es inherentemente una aplicación intensiva. También proporcionan dashboards y herramientas de simulación what-if que aprovechan los cálculos rápidos – pero, de nuevo, el hecho de que todo el conjunto de datos esté en memoria es el factor habilitador. Cabe señalar que los precios de la memoria han caído y la escalabilidad en la nube está mejorando, por lo que el enfoque intensivo de RELEX es más factible ahora que hace una década. No obstante, los clientes conscientes de los costes podrían encontrar elevados los requisitos de infraestructura de RELEX en comparación con herramientas más sencillas. Existe evidencia anecdótica de que las implementaciones de RELEX necesitan servidores robustos o un alto gasto en la nube para mantener la capacidad de respuesta en tiempo real. En este sentido, RELEX sacrifica algo de eficiencia en coste por velocidad y granularidad. En cuanto a la software scalability, RELEX es modular (no es necesario implementar todos los módulos si no se requieren) pero es una única plataforma. Han demostrado ser capaces de apoyar operaciones globales (multipaís, multimoneda, etc.). En general, RELEX obtiene altas puntuaciones en pura potencia y velocidad, y puntuaciones moderadas en eficiencia de costes – es el coche deportivo de alta gama en la optimización del retail: un performance fantástico, pero pagarás por el combustible premium.

Handling Complex Retail Factors: Aquí es donde RELEX brilla – cuenta con una funcionalidad rica diseñada específicamente para escenarios de retail. Se manejan explícitamente los cannibalization and halo effects en su forecasting para promociones: como se ha discutido, el sistema aprende relaciones a partir de datos transaccionales (por ejemplo, qué productos son sustitutos frente a complementos) y ajusta los forecasts en consecuencia ⁸ ⁹. Pocos proveedores tienen esto incorporado; el equipo de data science de RELEX publicó cómo utilizan el aprendizaje de reglas de asociación en datos de cesta para inferir estas relaciones, en lugar de depender de suposiciones manuales ⁸. Esto significa que cuando lanzas una promo en el producto X, RELEX automáticamente reducirá el forecast base del producto Y si, habitualmente, Y es cannibalizado por X (y viceversa para halo). Esto no solo mejora la exactitud del forecast, sino que también impulsa mejores decisiones de inventario (almacenar menos de Y porque se venderá menos durante la promo de X) ⁹. En cuanto a substitution, RELEX puede tener en cuenta los efectos de faltante de stock: si el producto A se agota, su forecast para el producto B puede aumentar temporalmente si B es un sustituto. Esto probablemente se realice mediante las mismas relaciones aprendidas; algunos clientes suministran a RELEX sus posiciones de inventario en tienda para que pueda detectar ventas perdidas y patrones de sustitución. Expiration and spoilage son un foco importante para RELEX, especialmente en el retail de alimentos frescos. Su solución puede rastrear la antigüedad del inventario y cuenta con funcionalidad para la expiration date management ³⁵. Por ejemplo, RELEX puede priorizar la venta de lotes más antiguos primero (FEFO – first-expire, first-out), y sus forecasts para productos frescos consideran la vida útil limitada (tienden a recomendar reposiciones más pequeñas y frecuentes para bienes de corta vida). Incluso ofrecen herramientas para monitorear el deterioro y alertar si el stock se acerca a su fecha de expiración sin haber tenido ventas ³⁶. Un cliente de RELEX, Franprix, logró una enorme reducción del deterioro utilizando forecasting a nivel diario y pedidos automatizados en tiendas para productos frescos ²⁴ ³⁷ – una prueba de que RELEX maneja los productos perecederos mucho mejor que los sistemas tradicionales, que a menudo ignoran la expiración. RELEX también tiene en cuenta display space and visual merchandising en el forecasting: si a un producto se le asigna una exhibición secundaria, el forecast puede aumentar en consecuencia (su ML detecta esa correlación). Además, sus módulos de workforce y ejecución aseguran que, si cambian los forecasts o planes (como un repentino aumento en la demanda), se alerte al personal de tienda, por ejemplo, para hornear más pan o reabastecer más rápido (cerrando el ciclo operativamente). Otro factor complejo es el weather – RELEX cuenta con ajustes de forecasting basados en el clima incorporados, cruciales para categorías estacionales (por ejemplo, helado en días calurosos). Muchos afirman realizar weather forecasting; RELEX lo ha implementado utilizando machine learning ajustado para cada localidad ²⁹. En resumen, RELEX probablemente cuenta con la suite más completa para manejar las complejas realidades del retail: desde los efectos cruzados entre productos hasta impulsores externos y la vida útil. Abordan estos aspectos de manera casi completamente automatizada utilizando AI, lo que es un diferenciador clave. Hay que tener en cuenta, sin embargo, que aprovechar todas estas características requiere proporcionar a RELEX una gran cantidad de datos (datos de cesta, feeds meteorológicos, estados de inventario, etc.) y confiar en las recomendaciones del sistema. Pero para los minoristas que buscan dominar la complejidad, RELEX ofrece una caja de herramientas comprobada. Les damos la máxima puntuación en este criterio.

Automatización: RELEX soporta un alto grado de automatización, aunque a menudo se configura para permitir la supervisión humana. En la práctica, muchos clientes de RELEX usan auto-reabastecimiento a nivel de tienda y DC: el sistema genera órdenes diarias o intradía para cada SKU-tienda que pasan directamente a ejecución a menos que sean marcadas para revisión. Como se señaló, solo el 24% de los supermercados en una encuesta tenían la automatización de órdenes en tienda impulsada por forecasts, pero aquellos que la implementaron (con sistemas como RELEX) vieron que el desperdicio se redujo entre un 10–40% ³⁸ ²⁴. El ejemplo de Franprix – una reducción del 30% en el deterioro con órdenes automatizadas – recalca que la automatización de RELEX funciona ²⁴. El sistema cuenta con un mecanismo de alerta para llamar la atención humana sobre excepciones (por ejemplo, “forecast cayó significativamente debido a un factor inexplicable” o “orden limitada por el límite de espacio de almacenamiento”), pero de lo contrario puede funcionar en piloto automático. La filosofía de RELEX se describe a menudo como “algorithmic retailing” donde las decisiones son impulsadas por el sistema. También automatizan revisiones de assortment sugiriendo qué artículos añadir o quitar por tienda en cada periodo, e incluso automatizan recomendaciones de price markdown para liquidación. Un área de automatización que destaca es promotion fulfillment: RELEX puede enviar automáticamente inventario a las tiendas en anticipación a promociones y luego retirarlo si las ventas tienen un desempeño inferior, sin intervención del planificador. Además, gracias al motor en tiempo real, no se requiere que los planificadores realicen tediosas ejecuciones por lotes o recálculos manuales – el sistema actualiza forecasts y planes de manera continua a medida que llegan nuevos datos (ventas, inventario, etc.). Esto permite pasar a continuous planning with minimal manual triggers. Cabe destacar que RELEX típicamente aún involucra a planificadores en la supervisión – por ejemplo, un planificador podría aprobar un cambio en el assortment o ajustar una orden excesivamente agresiva, especialmente al inicio de la adopción. Pero la tendencia entre sus usuarios es una creciente confianza en la IA y, por lo tanto, una mayor automatización. RELEX ofrece herramientas de simulación para que los planificadores puedan probar “si dejo que el sistema auto-order, ¿qué sucede con los faltante de stock vs inventory?” para generar confianza. En comparación con los sistemas legados que a menudo producen un plan que un humano debe ajustar, RELEX está mucho más cerca de operaciones autónomas. También han comenzado a comercializar en torno a “autonomous planning” similar a Blue Yonder. Desde nuestra perspectiva escéptica, diríamos que RELEX tiene una automatización comprobada en replenishment, una buena automatización en forecasting (no se requiere forecasting manual), una automatización parcial en assortment (las recomendaciones aún son revisadas por merchandising) y una automatización emergente en pricing (por ejemplo, dynamic markdowns). A medida que las capacidades de IA crecen, esperamos que RELEX reduzca aún más la necesidad de intervenciones humanas. Por lo tanto, obtienen muy buenas calificaciones en automatización, siendo superados únicamente por soluciones como Lokad, que están diseñadas desde cero para el modo autopiloto. La advertencia sigue siendo que las organizaciones deben adaptar sus procesos – RELEX ofrece la capacidad de automatizar, pero depende del minorista confiar en ella y reorganizar los roles en consecuencia.

Integración de Tecnología: RELEX es una unified platform desarrollada en gran parte internamente. No ensamblaron su motor central de planificación mediante adquisiciones – fue construido por la empresa. Las diferentes funcionalidades (demand forecasting, replenishment, allocations, planogramming, workforce) comparten una plataforma de datos común. Esto significa menos complicaciones de integración dentro del conjunto: por ejemplo, el módulo de planificación de assortment se conecta directamente al módulo de forecasting de modo que cuando retiras un producto del assortment, los forecasts y órdenes caen automáticamente a cero después de ser deslistado. La coherency es generalmente fuerte; los usuarios acceden a estas funciones mediante una sola interfaz. RELEX ha realizado algunas adquisiciones (una app móvil de ejecución en tienda, una tecnología de reconocimiento de imágenes, etc.), pero estos son complementos en lugar de la lógica central de planificación. Una posible complejidad es la in-memory architecture – todo viviendo en un único modelo de memoria puede dificultar las modificaciones o la integración de nuevos tipos de datos. Pero parece que lo gestionan con técnicas modernas de bases de datos. En comparación con proveedores antiguos que tienen productos claramente separados (a menudo de adquisiciones) para pricing vs inventory, las soluciones de RELEX se sienten cohesivas. Por ejemplo, su price optimization es un componente más nuevo, pero probablemente fue desarrollado o integrado de forma tan estrecha que utiliza los mismos datos de forecast y la misma interfaz de usuario. No es necesario exportar forecasts a una herramienta de pricing de terceros – está dentro de RELEX. Esto reduce supuestos inconsistentes entre módulos. Otro punto de integración: RELEX se conecta con sistemas de ejecución (ERP, POS, etc.) a través de APIs, y cuenta con herramientas de integración razonablemente robustas (pero esto es normal para cualquier proveedor). Debido a que RELEX creció como un producto único, evita la etiqueta de “Frankenstein” que aqueja a competidores antiguos como JDA/Blue Yonder y SAP. Dicho esto, a medida que RELEX se expande (especialmente en pricing), mantener la pureza de una única plataforma es un esfuerzo continuo. No se han reportado problemas mayores, por lo que inferimos que lo han mantenido integrado. Una dimensión a observar es si los microservices de RELEX (en caso de que hayan fragmentado su aplicación en servicios) se comuniquen sin problemas. Gartner señaló las “data management and constraint modeling tools” de RELEX como notables ³⁹ – lo que indica que tienen una forma integrada de gestionar todas las reglas de negocio y datos. Esto sugiere un alto nivel de integración en el que diferentes restricciones (como espacio en anaqueles, lead times, tamaños de empaques, etc.) alimentan el mismo solucionador en lugar de hacerlo de forma separada. En resumen, RELEX es una de las soluciones más técnicamente coherentes en este campo, con poca evidencia de la desconexión que proviene de productos con muchas fusiones y adquisiciones. Esta es una ventaja significativa sobre los conjuntos legados.

Escepticismo ante las Afirmaciones de Marketing: RELEX, como muchas empresas jóvenes, utiliza libremente palabras de moda como AI/ML en marketing, pero en su caso la sustancia respalda en gran medida esas afirmaciones. Hablan de “Living Retail” y “unleashing AI” – ciertamente un discurso de marketing – pero también publican resultados y metodologías concretos. Por ejemplo, cuentan con entradas en el blog y recursos que detallan cómo funciona su machine learning para el retail (discutiendo pooling, detección de tendencias, etc.) ⁴⁰ ³⁰. Esa transparencia es buena; no es simplemente una caja mágica de IA, sino que al menos describen el enfoque. RELEX también tiende a dejar que los clientes hablen – muchas de sus afirmaciones se presentan en forma de estadísticas de estudios de caso (por ejemplo, un minorista XXXX mejoró la disponibilidad en estanterías en un Y% mientras reducía el inventario en un Z%). Estas son más creíbles que afirmaciones vagas. Utilizan términos como “autonomous”, “cognitive”, etc., pero hasta ahora no han sobreprometido más allá de lo que su software puede hacer. Un área a observar es “demand sensing” – RELEX a veces usa este término para describir su capacidad de forecasting a corto plazo (ingiriendo ventas recientes para ajustar los forecasts a corto plazo). Sabemos que el demand sensing como concepto ha sido criticado por ser hype ¹², pero en el caso de RELEX, su enfoque es esencialmente solo un forecasting más frecuente con los datos más recientes, lo cual está bien. La plug-and-play integration no es algo que RELEX sobrevalorice; reconocen que la implementación requiere trabajo (integración de datos, ajuste de parámetros). De hecho, algunos clientes han señalado que los proyectos de RELEX requieren un esfuerzo significativo (lo cual es de esperar para herramientas poderosas). Así que RELEX no promueve en exceso una narrativa falsa de “valor instantáneo”. También evitan una jerga excesivamente fantasiosa – no los verás promocionando blockchain o computación cuántica sin motivo (aunque, de forma divertida, su adquisición “Evo” usa el término “quantum learning” para su IA – pero eso es aparte). Si acaso, la mayor afirmación de marketing de RELEX es que pueden manejar todos los aspectos de la planificación retail en una solución unificada y entregar grandes resultados rápidamente. Aplicamos escepticismo: ¿puede un sistema realmente destacar en todo, desde la estrategia de assortment a largo plazo hasta el replenishment diario y el pricing? Es una tarea ambiciosa. RELEX tiene capacidades sólidas en muchas áreas, pero algunas (como el pricing) son más nuevas y no tan probadas como las de competidores especializados. Así que, aunque ofrecen todas las piezas, un minorista podría encontrar que alguna de ellas es menos madura. Esta es una sutileza que sus materiales de ventas podrían omitir. Además, ejecutar tantas funciones en un sistema podría volverse inmanejable – un problema que el marketing no destaca. Sin embargo, en el balance entre hype y realidad, RELEX se encuentra entre los mejores: sus afirmaciones de mejoras impulsadas por IA están respaldadas por algoritmos y pruebas de clientes, y en general evitan el abuso exagerado de buzzwords. Calificamos la honestidad de su marketing como relativamente alta.

Resumen: RELEX Solutions es una retail optimization powerhouse con una plataforma unificada que abarca forecasting, replenishment, assortment y pricing. Aprovecha machine learning extensively para tener en cuenta factores reales del retail (promotions, weather, cannibalization ⁹, etc.), y ha demostrado mejoras significativas en los resultados para los minoristas (más disponibilidad, menos spoilage ²⁴). El sistema soporta la joint planning de assortment, inventory, y en cierta medida pricing, aunque la optimización de pricing es más reciente para ellos. La probabilistic and AI forecasting es una fortaleza destacada ²⁸ ³¹, al igual que su capacidad para manejar productos frescos y la complejidad de manera elegante. La escalabilidad generalmente está probada, aunque con un alto uso de recursos ²². RELEX posibilita un alto grado de automation (especialmente en replenishment) y cuenta con un cohesive tech stack construido para el retail. Si bien algunos aspectos (por ejemplo, decisiones profit-optimal o la optimización totalmente unificada de price+stock) pueden no estar tan integrados de forma nativa como en el enfoque de Lokad, RELEX representa una de las soluciones más future-proof, innovative solutions for large retailers. Su enfoque en la realidad (no solo la teoría) y en aplicaciones tangibles de IA lo convierten en un competidor de primer nivel – posiblemente el líder entre los proveedores especializados en retail. Los principales riesgos son su complejidad (implementar todas las funciones no es trivial) y asegurar que el hype (¡IA en todas partes!) se traduzca en soluciones fáciles de usar y mantenibles. Hasta ahora, la evidencia sugiere que RELEX cumple en gran medida sus promesas, lo que lo convierte en una opción de alta clasificación para la optimización retail orientada al futuro.

Sources: Factores de forecast impulsados por ML de RELEX (patrones de demanda, promos, eventos externos) ²⁸; manejo de canibalización mediante ML en promo forecasting ⁹; reducción demostrada del deterioro a través de un reabastecimiento automatizado basado en forecast ²⁴; análisis de rentabilidad de assortment impulsado por AI ³³.

3. o9 Solutions – Planificación Integrada Ambiciosa con Grandes Promesas (y Advertencias)

o9 Solutions (fundada en 2009) se comercializa como la creadora de un “Digital Brain” para la planificación empresarial – una plataforma que unifica demand forecasting, supply chain planning, revenue management y más sobre un graph-based data model. La visión de o9 es ser la one-stop platform for end-to-end planning, rompiendo los silos entre demand planning, inventory/supply, commercial planning e incluso financial planning. En el contexto retail, o9 puede configurarse para la planificación de merchandising y assortment, demand forecasting, supply planning, y tiene capacidades para Revenue Growth Management (RGM), que incluye la optimización de pricing y promotion. En teoría, esto cumple con todos los aspectos de joint optimization. o9 ha ganado terreno en CPG, manufactura y en algunas empresas orientadas al consumidor/retail, a menudo enfatizando su moderno enfoque de AI/ML y knowledge graph en contraste con los APS (Advanced Planning Systems) más antiguos. Sin embargo, desde una perspectiva de ingeniería escéptica, o9 es algo paradójico: es muy avanzada tecnológicamente en su arquitectura, sin embargo, algunos expertos cuestionan cuánto de su IA es sustancia versus buzz. Calificamos a o9 de manera muy positiva por su amplitud y su enfoque de plataforma, pero con notas de precaución respecto a su ejecución real en forecasting y la pesada infraestructura que puede requerir.

Optimización Conjunta: La propuesta de valor central de o9 es la integrated planning across all functions. Para un minorista, esto significa que un sistema o9 podría encargarse de la planificación financiera de merchandising, decisiones de assortment, demand forecasting, supply/replenishment planning y estrategia de pricing, todo conectado. Promocionan explícitamente su solución para Revenue Growth Management (RGM) que “integrates RGM, Demand Planning, Supply Chain, and IBP into a single platform” ⁴¹. Esto sugiere que el pricing y las promociones (RGM) no son independientes – se integran en el demand planning, que a su vez alimenta el supply planning, todo dentro de o9. En la práctica, o9 cuenta con módulos o apps para cada área, pero bajo un mismo paraguas. Por ejemplo, una implementación de o9 podría incluir un pricing elasticity model dentro del módulo de demand forecasting, de modo que los planificadores puedan ver cómo los cambios de precio afectarían al forecast y, de inmediato, cómo eso repercute en el inventory o en los planes de producción. Su concepto de Enterprise Knowledge Graph (EKG) significa que todos los datos (productos, ubicaciones, suppliers, constraints, etc.) están conectados como una red, permitiendo que cualquier cambio (como una nueva decisión de assortment o un cambio de precio) propague impactos a través del graph. Esto es poderoso en teoría: podría permitir una concurrent optimization verdadera – ajustando precios y reordenando simultáneamente para lograr el máximo beneficio y servicio. Sin embargo, no está claro si o9 actualmente optimiza automáticamente en todas esas dimensiones o simplemente permite un analysis unificado. A menudo, los clientes utilizan o9 para ejecutar escenarios: por ejemplo, escenario 1 – price x, order y; escenario 2 – price x+5%, order z – y luego comparar los resultados. Eso es planificación integrada, pero no necesariamente un único algoritmo de optimización. Dicho esto, o9 es capaz de calcular escenarios complejos dado su engine. Es uno de los pocos que puede unir de manera realista assortment planning (merchandising) together with supply chain – de modo que un minorista puede planificar una estrategia de categoría (qué SKUs en qué tiendas) y o9 simultáneamente planificará el inventory y el replenishment para ellos, asegurando que el supply se ajuste al plan de merchandising. Muchas configuraciones legadas hacen esto en pasos desconectados. o9 también promociona la supplier collaboration y la planificación multinivel en la misma plataforma, lo que significa que los problemas de supply en etapas tempranas pueden informar las decisiones de merchandising en etapas posteriores. Toda esta integración holística es una fortaleza clave y muy orientada al futuro. El principal desafío es la complejidad: modelar todos estos elementos en un solo sistema requiere una configuración significativa e integración de datos. Algunos usuarios informan que, aunque o9 puede hacer todo, su implementación podría centrarse primero en una o dos áreas (por ejemplo, demand y supply planning), dejando pricing o assortment para fases posteriores. Por lo tanto, la optimización conjunta es más un potencial que una realidad instantánea. Le damos a o9 altas calificaciones por su visión y arquitectura en optimización conjunta, matizadas por la pregunta de cuántos clientes la utilizan realmente para decisiones completamente integradas de pricing-inventory. Aún así, la capacidad de la plataforma está ahí, y eso es más de lo que se puede decir de la mayoría.

Probabilistic Forecasting & AI: o9 sin duda se comercializa como una plataforma impulsada por AI. Tiene un motor de ML dedicado que puede ingerir muchas variables externas (demuestran cosas como Google Trends, clima, datos socioeconómicos) en el forecasting. El Knowledge Graph a veces se presenta como un habilitador de una mejor AI – al vincular todos los datos, supuestamente ayuda a los algoritmos de machine learning a encontrar predictores de la demanda. Sin embargo, es necesario un análisis crítico. Un análisis independiente señaló: “Muchos de los reclamos de forecasting sobre la base de datos de grafos (EKG) son dudosos y no están respaldados por la literatura científica. Mucho bombo de AI, pero elementos encontrados en Github insinúan técnicas pedestres.” ⁴². Esto sugiere que los métodos reales de forecasting de o9 pueden no ser tan revolucionarios como implica su marketing – posiblemente utilizando modelos de series temporales o regresión bastante estándar bajo el capó, a pesar de envolverlos en términos sofisticados. De hecho, o9 ha sido criticado por etiquetar incluso funciones interactivas simples como “AI”. Por ejemplo, generar escenarios rápidamente es una característica distintiva de su herramienta (debido al cálculo en memoria), pero la planificación de escenarios en sí no es AI – es solo simulación. Dicho esto, o9 sí tiene capacidades de machine learning: pueden construir modelos de ML para promociones, para la introducción de nuevos productos (usando forecasting basado en atributos), etc. Adquirieron una pequeña empresa de AI (Fourkind) para potenciar su data science. Así que no es solo palabrería; han implementado ML para el reconocimiento de patrones y detección de anomalías en los forecast. Es solo que estos podrían ser similares a lo que hacen otros proveedores modernos. Hay poca evidencia de que el graph model inherently improves forecast accuracy – en su mayoría ayuda con la organización de datos. El forecasting de o9 puede ser probabilístico en el sentido de que soporta Monte Carlo simulations para escenarios (por ejemplo, simular 1000 trayectorias de demanda para ver la distribución de los resultados), pero no los hemos visto enfatizar la generación de distribuciones completas de probabilidad por defecto de la misma manera que lo hace Lokad. Así que, en términos de madurez en forecasting probabilístico, podrían estar rezagados frente a jugadores especializados. Sin embargo, o9 sí incorpora AI de otras maneras: por ejemplo, cuentan con una AI-powered supply chain risk tool para predecir posibles interrupciones, lo cual está fuera del forecasting clásico. También tienen un nuevo Generative AI assistant (interfaz de chatbot para consultar el sistema), que es más una interfaz de usuario que el forecasting central, pero muestra que invierten en tecnología AI. En resumen, calificamos a o9 como poseedor de buenas capacidades de AI pero posiblemente no tan diferenciadas como afirman. Definitivamente superan a los sistemas AP heredados que dependen de forecasting manual, pero frente a pares como RELEX o Lokad, el enfoque de forecasting de o9 podría parecer menos enfocado (ya que o9 también equilibra muchos otros aspectos de la planificación). El escepticismo de los expertos ⁴² indica que no se deben tomar todas las afirmaciones de AI de o9 al pie de la letra. Queremos ver más validación independiente de sus ganancias en la precisión del forecast. Hasta entonces, consideramos su AI creíble pero algo sobrecomercializada.

Economic Decision-Making: La plataforma de o9, al ser muy flexible, puede configurarse para optimizar diversos objetivos, incluidos los financieros. En contextos de integrated business planning (IBP), o9 a menudo ayuda a las empresas a evaluar escenarios por ingresos, margen, servicio, etc. Para el retail, su módulo RGM debería considerar explícitamente la price elasticity and margin – vinculando así directamente las decisiones con los resultados de beneficio e ingresos. Tienen la capacidad de ejecutar what-if scenarios on profitability: por ejemplo, “¿Qué pasaría si fijamos el precio de esta category un 5% menor? ¿Cómo cambiarían el beneficio y el volumen? ¿Y podrán nuestros proveedores mantenerse al día?” Esto alinea la planificación con las métricas financieras. Sin embargo, queda la duda de si o9 optimiza automáticamente o simplemente proporciona el entorno para ello. Parte del valor de o9 proviene de habilitar decisiones interfuncionales: por ejemplo, un usuario puede ver que un determinado plan de promoción causaría pérdida de ventas debido a restricciones en supply chain, y decidir ajustarlo para maximizar el beneficio dadas esas limitaciones – todo dentro de la herramienta de o9. Esto facilita la toma de decisiones económicas (al proporcionar transparencia y simulaciones rápidas). o9 también tiene solucionadores de optimización integrados (para supply chain y, presumiblemente, también para la fijación de precios). Pueden hacer cosas como multi-echelon inventory optimization (equilibrando stock entre centros de distribución y tiendas para minimizar costos y alcanzar un nivel de servicio objetivo) y promotion calendar optimization (elegir el mejor calendario de promociones para cumplir objetivos). Esto implica compensaciones económicas. Un ejemplo: o9 puede optimizar la assortment allocation – determinando cuántas presentaciones o qué productos en cada tienda maximizarían cierta métrica (como ventas o beneficio) bajo restricciones de espacio. Esa es una optimización matemática alineada con objetivos económicos. Debido a que la plataforma de o9 es personalizable, un minorista podría configurar una función objetivo de “maximizar el margen esperado menos el costo de mantenimiento” para inventario, mientras que otro podría optar por “maximizar ingresos sujeto a X.” La herramienta puede soportar ambos. Así que es flexible, pero eso también significa que o9 en sí no impone un enfoque económico – puede usarse de forma más manual/heurística si el cliente lo decide. Su marketing en torno a “decision-centric planning” y “digital brain” implica que el sistema te guiará hacia la mejor decisión. Sin embargo, algunos críticos dicen que las demostraciones sofisticadas de o9 aún dependen en gran medida del análisis humano en lugar de decisiones óptimas totalmente automatizadas ⁴². Sospechamos que el uso típico de o9 es presentar a los planificadores escenarios y KPIs (costo, beneficio, etc.) y que sean ellos quienes decidan, en lugar de que el sistema entregue una única respuesta óptima. En términos de costo de oportunidad, no está claro si o9 calcula inherentemente esos costos (por ejemplo, el costo de un faltante de stock en términos de beneficio perdido – probablemente pueda hacerlo si se configura). En la optimización de precios, si se utiliza el RGM de o9, probablemente optimice matemáticamente los precios para alcanzar un objetivo financiero dado las curvas de elasticidad de la demanda, similar a otras herramientas de optimización de precios. Así que sí, puede estar impulsado económicamente. En conjunto, o9 facilita fuertemente la toma de decisiones económicas (ya que pretende combinar la planificación operativa y financiera), pero cuán automatizado esté eso, varía. Les damos crédito por conectar la planificación con los resultados empresariales (su discurso de ventas suele ser romper la barrera entre finanzas y planificación de supply chain). Solo ten en cuenta que lograr decisiones verdaderamente óptimas en beneficio con o9 podría requerir una construcción y ajuste significativo de modelos durante la implementación.

Scalability & Architecture: La arquitectura de o9 es una de sus señas de identidad – utilizan un moderno in-memory computation engine y el Enterprise Knowledge Graph para representar los datos de una manera altamente conectada pero eficiente. Esto permite una traversabilidad y cálculos rápidos. A menudo demuestran una propagación casi instantánea de los cambios (por ejemplo, cambiar un forecast y de inmediato se actualiza el plan de supply chain). Es conceptualmente similar a cómo Kinaxis logra la concurrencia, pero con un giro de base de datos en grafos. Sin embargo, como señaló el escéptico anteriormente, “la masa tecnológica de o9 está por las nubes, incluso según los estándares empresariales. El diseño en memoria garantiza altos costos de hardware.” ⁴. En otras palabras, o9 concentra una enorme cantidad de datos y cálculos en memoria, por lo que ejecutarlo para una gran empresa podría necesitar servidores potentes o altos gastos en cloud, similar a la situación de RELEX. o9 es cloud-based (tienen su oferta SaaS, a menudo en Azure), lo cual proporciona elasticidad. Pero si un minorista utiliza o9 para modelar toda su red, además de datos financieros y comerciales detallados, el modelo puede ser extremadamente grande. Una ventaja: el graph model puede ser más eficiente en el uso de memoria que las tablas de datos ingenuas debido a que almacena relaciones de forma elegante. Pero el crítico sugiere que sigue siendo bastante pesado. De hecho, en los inicios algunos despliegues de o9 eran notorios por su alto consumo de memoria. Probablemente han mejorado esto, y con cloud, pueden escalar horizontalmente hasta cierto punto (aunque ciertos cálculos aún requieren una gran memoria compartida). La Scalability in user count es buena – muchos usuarios pueden colaborar en el sistema, cada uno viendo diferentes secciones, gracias a su back-end de alto rendimiento. o9 está siendo utilizado por empresas Fortune 500, lo que da fe de su escalabilidad para grandes empresas (incluyendo CPGs muy grandes y una cadena global de comida rápida). La cost-efficiency es otro asunto: evidencia anecdótica sugiere que o9 no es barato de operar, dado su precio empresarial y necesidades de recursos. Si uno es sensible al costo, podría preferirse una solución más esbelta para un subconjunto de tareas. Pero si se valora la planificación integrada en tiempo real a lo largo de una empresa, o9 lo entrega, y eso intrínsecamente requiere más computación. En términos de desempeño, o9 puede recalcular planes con mucha frecuencia (algunos lo hacen diariamente o incluso intra-diariamente para ciertos horizontes a corto plazo), lo cual es una mejora respecto a los ciclos semanales de planificación batch de antes. También emplean microservices y un enfoque de “platform”, lo que significa que piezas del plan pueden actualizarse sin tener que ejecutar todo desde cero. El Knowledge Graph se actualiza de forma incremental a medida que llegan nuevos datos. Esto es moderno y escalable en diseño. Resumiendo, o9 es técnicamente escalable para problemas muy grandes, pero los usuarios deben estar preparados para un uso significativo de hardware/cloud (la plataforma es poderosa pero hambrienta). En comparación con soluciones verdaderamente ligeras y especializadas, o9 probablemente use más memoria porque está resolviendo un problema integrado mayor. Así, en escalabilidad le damos a o9 altas puntuaciones por capacidad, y medianas en cuanto a cost-efficiency.

Handling Complex Retail Factors: De serie, o9 puede no tener tantas características predefinidas específicas para el retail como algo como RELEX, pero puede configurarse para manejarlas. Por ejemplo, cannibalization and halo – los modelos de ML de o9 pueden detectar estos fenómenos si se alimentan con datos transaccionales, similar a como lo hace RELEX. Probablemente se requiera que el equipo de data science defina las características adecuadas o utilice el ML assistant de o9. No encontramos referencias explícitas al modelado incorporado de canibalización en promociones en los materiales de o9; es probable que se realice mediante su forecasting de ML en lugar de un módulo separado. Los Substitution effects pueden manejarse porque o9 puede rastrear los niveles de inventory – se podría configurar una regla o un modelo de ML que, cuando un SKU está agotado, la demanda de un SKU correlacionado aumente. Pero nuevamente, puede que necesite ser modelado explícitamente. Expiration/perishables: o9 puede gestionar atributos de lote (su modelo de datos puede incorporar atributos de ítems como la fecha de expiración). Un minorista podría usar o9 para planificar la producción y distribución en alineación con las restricciones de shelf-life (por ejemplo, asegurar que los ítems se envíen a tiendas con vida útil suficiente restante). Pero podría requerir personalizar las restricciones y los objetivos. No es una solución dedicada a alimentos frescos, por lo que no calculará automáticamente proyecciones de deterioro a menos que se implemente esa lógica. En contraste, algunos otros proveedores lo tienen incorporado. Así que o9 puede hacerlo, pero el usuario debe saber incluirlo en su modelo. Las Promotions and seasonality se manejan definitivamente – el forecasting y la planificación de o9 tienen en cuenta los incrementos por promoción (cuentan con un módulo de planificación de promos para ingresar promociones que luego ajustan los forecast y planes de supply chain). También permiten la planificación de multi-echelon inventory, lo que significa que pueden optimizar los niveles de stock entre centros de distribución y tiendas considerando la variabilidad – una forma elegante de manejar la incertidumbre de la demanda. Sospechamos que o9, al ser cross-industry, no dispone de tantos retail-specialized algorithms predefinidos (por ejemplo, no sugerirá automáticamente “este ítem es un sustituto de aquel” a menos que configures esa lógica). Pero su flexibilidad implica que cualquier factor retail puede ser modelado. También ofrecen lo que llaman “control towers” – esencialmente dashboards para monitorear aspectos como faltante de stock, ventas perdidas, exceso – que ayudan a identificar problemas como la canibalización o assortments deficientes. Además, el knowledge graph de o9 puede integrarse con datos externos, por lo que algo como el clima puede incorporarse para ajustar los forecast (si el usuario lo configura). Muchos clientes retail de o9 probablemente usan señales de demanda externas. La Assortment optimization es parte explícita de su oferta (enumeran soluciones de “merchandising and assortment planning”), lo que significa que pueden usar analítica para determinar los assortments ideales por tienda, y considerar preferencias locales y restricciones de espacio. Combinado con su IBP, pueden asegurar que los cambios en el assortment sean factibles en términos de supply chain. Eso aborda la complejidad de la demanda localizada. En conjunto, o9 es capaz de manejar factores complejos, pero requiere un equipo de implementación competente para aprovechar esas capacidades. Puede que no sea tan “out-of-the-box” en detalles retail como un proveedor exclusivo para retail, pero una vez configurado, puede rivalizar con ellos. Una crítica a destacar: los comentarios de expertos anteriores implican que parte de la tecnología avanzada de o9 podría en realidad depender de métodos más simples (mencionan proyectos open-source como tsfresh, ARIMA, etc. en el contexto de o9) ⁴³, lo que podría significar que algunos fenómenos complejos se abordan con técnicas bastante básicas (como la regresión lineal para promociones – la cual funciona pero no es de vanguardia). Si es cierto, o9 podría necesitar profundizar su enfoque para capturar verdaderamente, por ejemplo, impactos no lineales de canibalización. No obstante, dado sus recursos y enfoque en AI, es probable que estén mejorando en este aspecto.

Automatización: La plataforma de o9 es principalmente una herramienta de planificación y soporte para la toma de decisiones – se destaca en crear planes y escenarios rápidamente. Si se ejecuta automáticamente depende en gran medida de la organización usuaria. Muchos usuarios de o9 aún involucran a planificadores para elegir escenarios y aprobar planes. Sin embargo, o9 sí ofrece la capacidad de planificación continua. Enfatizan conceptos como “qué pasaría si en tiempo real” y “replanificación continua”, los cuales insinúan automatización (el sistema actualiza constantemente el plan a medida que cambian las condiciones). Por ejemplo, si la demanda se dispara en una región, o9 puede reasignar automáticamente el inventario en el plan y sugerir envíos rápidos. Algunos han denominado el enfoque de o9 “planificación autónoma” en marketing, pero en realidad, a menudo complementa a los planificadores en lugar de reemplazarlos. Dicho esto, o9 ha introducido funciones como AI agents que pueden monitorear datos y hacer recomendaciones. Y se dice que su nuevo GenAI Orchestrator “permite a las empresas tomar decisiones más rápidas e inteligentes y aumentar la productividad de los planificadores” ⁴⁴ – acelerando mayormente la forma en que los planificadores obtienen información. La automatización completa sin supervisión (como la ejecución automática de órdenes o cambios de precio) no se cita comúnmente en o9. Típicamente, o9 alimentaría planes optimizados a un ERP o sistema de ejecución que luego los implementa. Así que la automatización en el contexto de o9 se trata más de automatizar el proceso de planificación (sin cálculos manuales en hojas de cálculo, actualizaciones automáticas de forecast, alertas automáticas cuando el plan se desvía, etc.) que la ejecución. La diferencia frente a algo como Lokad o RELEX es sutil: o9 automatiza cálculos y proporciona una recomendación de decisión, pero un humano suele tomar la decisión final; Lokad/RELEX a menudo están configurados para generar automáticamente la orden real o cambio de precio. Dicho esto, si una empresa lo decide, podrían tratar las salidas de o9 como decisiones autorizadas automáticamente. Por ejemplo, o9 podría generar propuestas de órdenes que se envían directamente a un sistema de gestión de órdenes diariamente – eso es factible. O podría calcular nuevos precios de transferencia o sugerencias de markdown y alimentarlos a las tiendas. La capacidad está ahí, pero los usuarios típicos de o9 (a menudo grandes empresas) tienden a mantener a un humano en el circuito para decisiones críticas. Debemos notar que la fortaleza de la planificación de escenarios de o9 en realidad reduce la necesidad de ensayo y error por parte de los humanos – el sistema mismo puede simular innumerables escenarios (casi como una lluvia de ideas automatizada). Así que, en cierto sentido, automatiza la evaluación de opciones, dejando al humano solo la tarea de elegir entre las mejores opciones. Esto acelera dramáticamente la toma de decisiones. Entonces, en términos de productividad del planificador, o9 automatiza el trabajo pesado. También tienen flujos de trabajo (como aprobaciones, notificaciones) que pueden dirigir automáticamente las excepciones a la persona indicada. Para ser escépticos, el marketing de o9 con su “Digital Brain” puede implicar una supply chain autónoma, pero en realidad es más bien como una cabina de mando para decisiones muy buena que requiere un piloto capacitado. Les damos calificaciones moderadas a altas en la automatización de cálculos de planificación, pero más bajas en la ejecución autónoma sin supervisión. Comparado con sistemas antiguos que requerían muchas entradas manuales, o9 es un salto hacia adelante. Comparado con el ideal de AI conduciendo de forma autónoma las operaciones de retail, o9 aún no lo logra (ni la mayoría).

Integración Tecnológica: o9 fue construido como una plataforma única desde cero (por ex-veteranos de i2 Technologies), por lo que no heredó una mezcla desordenada de módulos adquiridos – lo cual es positivo para la integración. Su arquitectura de microservicios y modelo de datos unificado significan que todas las partes del sistema se comunican sin problemas. No se necesitan bases de datos separadas para forecast vs planificación de supply; el Knowledge Graph alberga todo. Esto evita el dolor tradicional de integración entre, por ejemplo, un sistema de forecast y un sistema de optimización de inventario. Todos los datos se cargan una sola vez en o9 y luego diferentes “apps” dentro de él operan sobre esos datos compartidos. La experiencia de usuario también es unificada (tienen una interfaz web común en todos los módulos, con dashboards configurables). Así que, desde la perspectiva del usuario, se siente como un único sistema para todas las tareas de planificación. Esto es una ventaja importante sobre una solución Frankenstein. Sin embargo, a medida que o9 ha crecido, ha añadido muchas funciones y quizás adquirido una pequeña empresa o dos (como la consultoría AI, y quizá una para el diseño de supply chain). Podría haber alguna integración necesaria en esas áreas periféricas, pero la planificación central permanece unificada. Una crítica de un experto dijo que o9 es “el arquetipo del gran proveedor tecnológico” con “masa tecnológica por las nubes”, implicando que es muy complejo internamente ⁴. Esto insinúa que, aunque no es un Frankenstein por adquisiciones, la propia plataforma de o9 es masiva – lo que potencialmente complica su implementación o mantenimiento. Pero esa es una complejidad interna en lugar de la integración de tecnologías dispares. Los compradores empresariales a menudo prefieren una plataforma integrada como o9 porque reduce el número de proveedores e interfaces. Esa es la fortaleza de o9 – compras una plataforma en lugar de forecast, planificación de supply, S&OP, etc. separados. El riesgo es que, si una parte de la plataforma no es la mejor en su clase, sigues atado a ella a menos que integres otra herramienta (lo cual derrota el propósito). En cuanto a la “coherencia del tech stack”, o9 es coherente – está mayormente construido sobre el tech stack de Microsoft (.NET, etc.) y utiliza una estructura de base de datos de grafos que desarrollaron. Así que no vemos problemas como que los datos se copien entre subsistemas o lógica inconsistente. El trade-off: adoptar o9 significa alinear tus procesos con el enfoque de plataforma de o9, lo cual puede ser un gran cambio. Pero desde una perspectiva de TI, probablemente simplifica el panorama en comparación con múltiples sistemas heredados. En resumen, o9 no es un Frankenstein – es un cerebro diseñado (aunque muy complejo). Eso es bueno para el mantenimiento a largo plazo si el cliente lo adopta completamente, pero puede ser abrumador al principio. Creemos que o9 cumple bien el criterio de “tech stack coherente”.

Escepticismo hacia el Hype: Si hay un proveedor en esta lista que active la alarma del “hype”, podría ser o9. Utilizan palabras de moda de forma liberal – Enterprise Knowledge Graph™, Digital Brain, AI/ML, y ahora Generative AI. Su marketing es elegante y a veces vago en los detalles técnicos, centrándose en cambio en los beneficios a gran escala. Por ejemplo, se jactan de tener un framework de AI/ML, pero se escucha menos sobre cuáles algoritmos utilizan exactamente (mientras que un proveedor como Lokad o ToolsGroup podría discutir abiertamente el uso de modelos probabilísticos o redes neuronales, o9 se mantiene en un nivel más general). Algunos observadores de la industria han acusado, de hecho, a o9 de ser “AI Theater”, mostrando demos vistosas con mucha analítica pero utilizando detrás de escena técnicas bastante estándar ⁴². El informe citado anteriormente por Lokad ubicó a o9 cerca del fondo de un ranking, citando “toneladas de AI hype” y que características interactivas triviales eran etiquetadas como AI ⁴². Esta es una crítica dura, probablemente desde la perspectiva de un competidor, pero resuena con la idea de que el marketing de o9 está adelantado a su realidad probada. o9 también nombra características de manera futurista – por ejemplo, afirmando tener un motor de “quantum learning” (un término tomado de su adquisición de Evo en 2023) que suena innovador pero que es esencialmente un enfoque ensemble ML. Hablan de “graph cube technology” para conectar datos ⁴⁵, lo cual está bien, pero podría confundir a los clientes. Demand sensing y digital twin son otras palabras de moda que o9 podría mencionar (aunque lo enmarcan como knowledge graph/Digital Brain en lugar de twin, para ser justos). Como escépticos, uno debería preguntar: ¿están las empresas logrando los resultados dramáticos que o9 implica (como incrementos en ingresos del 10% únicamente por una mejor planificación)? Algunos reportan buenos resultados, pero las referencias independientes son pocas ya que o9 es más joven que, por ejemplo, SAP. Otro aspecto del hype: o9 a menudo se posiciona como una plug-and-play cloud platform que puede implementarse más rápido que los sistemas antiguos. Sin embargo, se ha reportado que algunas implementaciones toman un tiempo y consultoría significativos (porque modelar una empresa entera no es trivial). Así que la idea de que puedes simplemente desplegar o9 y obtener una planificación integrada instantánea es optimista. En general, es más rápido que implementar varias herramientas separadas, pero no “instantáneo”. Dicho esto, no debemos descartar los logros de o9: genuinamente introdujeron tecnología moderna e interfaces de usuario a un sector que lo necesitaba, y muchos clientes están satisfechos. Probablemente sí ofrecen una capacidad de planificación mucho mejor de lo que tenían los clientes. Así que el hype está parcialmente justificado – o9 es un sistema de planificación de próxima generación. La clave es analizar sus afirmaciones: si dicen “nuestra AI optimizará tu negocio de forma autónoma”, tómalo con cautela. En cambio, entiende que “nuestra plataforma te permitirá modelar y optimizar tu negocio mejor, pero tu equipo estará involucrado para dirigirlo.” Animaríamos a los potenciales clientes a exigir demostraciones concretas o pruebas para cualquier afirmación grandilocuente, especialmente en cuanto a la precisión del forecast impulsado por AI o mejoras en ROI. El marco es sólido; la forma en que se utiliza decide el resultado. En conclusión, el marketing de o9 es ciertamente agresivo en términos de palabras de moda, por lo que aconsejamos un sano escepticismo. Sin embargo, en términos de sustancia, tienen una plataforma poderosa que respalda gran parte de ello – solo ten en cuenta que no todo lo etiquetado como “AI” es verdaderamente innovador (algunos es simplemente computación eficiente). Le damos a o9 una puntuación media en la honestidad del marketing: tienen algo de innovación tecnológica genuina, pero también empujan el envelope del hype más que otros, lo que requiere una debida diligencia cuidadosa por parte de los compradores.

Resumen: o9 Solutions ofrece una plataforma impresionantemente amplia e integrada para la optimización de retail, con el objetivo de servir como el “Digital Brain” que conecta decisiones de merchandising, supply chain y precios. Su arquitectura Knowledge Graph y motor en memoria permiten una planificación rápida y concurrente, además de un análisis de escenarios tan completo que pocos pueden igualar. o9 soporta la consideración conjunta de precios, demanda y supply, haciendo posible alinear las estrategias de surtido y precios con las restricciones de inventario y supply en una sola herramienta – una visión de verdadero IBP. Aprovecha AI/ML en forecast y analítica, aunque el nivel de avance en este aspecto es discutible ⁴². El sistema ciertamente puede incorporar factores complejos y grandes conjuntos de datos, aunque con una alta demanda computacional. La escalabilidad es de grado empresarial (utilizada por compañías de varios miles de millones de dólares), pero la eficiencia de costos podría ser un problema (el enfoque en memoria puede demandar mucho hardware) ⁴. o9 potencia a los planificadores mediante la automatización de cálculos y la planificación de escenarios, aunque a menudo es un sistema de soporte a la decisión en lugar de un decisor completamente autónomo. Tecnológicamente, es una plataforma cohesionada construida internamente, lo que evita las trampas de las suites Frankenstein. Las principales advertencias son su propensión al hype – algunas afirmaciones de una AI mágica o transformación “instantánea” deben verse con escepticismo – y la complejidad de implementar un sistema tan integral. Para organizaciones con visión de futuro dispuestas a invertir en una plataforma de planificación unificada, o9 es un competidor destacado, ofreciendo una arquitectura a prueba de futuro y flexibilidad. Pero un proyecto exitoso con o9 requiere separar el barniz del marketing de la realidad, y asegurar que la solución esté configurada para aprovechar verdaderamente su potencial (en lugar de replicar procesos antiguos en un sistema nuevo y reluciente). En nuestra clasificación escéptica, o9 obtiene alta puntuación en visión e integración, moderada en diferenciación comprobada de AI, y requiere una revisión cuidadosa en sus promesas cargadas de palabras de moda. Sigue siendo una de las plataformas más avanzadas que existen – solo abórdala con los ojos bien abiertos para asegurar que la sustancia coincide con el discurso de ventas.

Fuentes: Crítica al diseño en memoria de o9 y a sus afirmaciones de AI ⁴; afirmación de la plataforma integrada de RGM (pricing) y planificación de o9 ⁴¹; perspectiva de Blue Yonder sobre el uso de datos para vincular el impacto de precios al inventario (como un enfoque similar que o9 utilizaría) ²⁷.

4. ToolsGroup – Optimización de Inventario Comprobada, Evolucionando hacia la Planificación de Retail Unificada (con complementos de AI)

ToolsGroup es un proveedor establecido (fundado en 1993) históricamente conocido por su software Service Optimizer 99+ (SO99+) enfocado en el forecast de demanda y la optimización de inventario. Tiene un sólido legado en manufactura y distribución, pero también cuenta con muchos clientes de retail y bienes de consumo para la planificación de reposición. En los últimos años, ToolsGroup ha ampliado sus capacidades a través de adquisiciones – destacando la compra de la suite de planificación de retail JustEnough y de una compañía de AI, Evo – para ofrecer una plataforma de optimización de retail más completa que incluye planificación de surtido y mercadería, forecast de demanda, optimización de inventario, y ahora optimización de precios ⁴⁶ ⁴⁷. La seña de identidad de ToolsGroup ha sido desde hace tiempo su uso del forecast probabilístico para la planificación de inventario, y una filosofía de planificación de supply chain altamente automatizada y “orientada al nivel de servicio”. Ahora, con los módulos adquiridos y mejoras de AI, su objetivo es optimizar de forma conjunta el inventario y los precios, proporcionando una planificación de retail de extremo a extremo (lo comercializan como “Decision-Centric Planning”). Clasificamos a ToolsGroup como un jugador sólido y técnicamente competente con una profunda experiencia en optimización de inventario, aunque cabe notar que se encuentra en transición para integrar nuevas piezas. Sobresale en ciertas áreas (incertidumbre en el forecast, automatización) pero necesita ser examinado detenidamente en cuanto a cuán verdaderamente unificada y moderna es su solución combinada (algunas afirmaciones de marketing de “AI” han generado escepticismo ¹⁹).

Optimización conjunta: Históricamente, ToolsGroup se enfocaba en el lado de inventario – asegurando los niveles adecuados de inventario para cumplir con el servicio objetivo, teniendo en cuenta la incertidumbre. La fijación de precios y el surtido estaban fuera de su alcance. Con la adquisición de JustEnough (un especialista en planificación financiera de mercancías, surtido y asignación) y la integración de la IA de optimización de precios de Evo, ToolsGroup ahora publicita una capacidad para optimizar precios e inventario juntos. Por ejemplo, su nueva oferta incluye software de Retail Pricing que puede simular cómo los cambios de precio afectan la demanda y se reflejan en los ingresos ⁴⁸ ⁴⁹, y, lo que es más importante, lo hace con visibilidad completa de los niveles de inventario ⁴⁹. La integración de precios con inventario significa que el sistema es consciente del stock disponible al sugerir acciones de precios – algo imprescindible para la optimización conjunta (no tiene sentido bajar el precio si no tienes stock para vender, por ejemplo). Destacan que su herramienta de precios proporciona “una vista completa del inventario actual y la tasa de venta” para que las decisiones de precios se tomen en el contexto del inventario a lo largo de la supply chain ⁴⁹ ⁵⁰. Esto sugiere un enfoque coordinado: si el inventario es alto, el sistema podría activar rebajas; si el inventario es escaso, podría mantener el precio o incluso sugerir incrementarlo (si eso está dentro de la estrategia). Además, la hoja de ruta de ToolsGroup con Evo es entregar optimización dinámica de precios que alimente la supply planning ⁵¹ ⁵². La IA de Evo estaba especializada en vincular las decisiones de precios e inventario – su CEO dijo que el objetivo es ofrecer “cálculos óptimos de precio e inventario” de manera simultánea para impulsar mejores decisiones a lo largo de la cadena de valor ⁵³. Esto indica un algoritmo de optimización unificado o, al menos, algoritmos estrechamente interconectados: uno que encuentra el precio que maximiza la ganancia dadas las restricciones de inventario y la demanda esperada, y otro que determina el plan de inventario que respalda esa demanda a los precios elegidos. Es temprano – Evo fue adquirida a finales de 2023 ⁴⁷, por lo que la integración probablemente continúe – pero ToolsGroup claramente pretende tener la optimización de precios e inventario bajo un mismo techo, en lugar de como pasos secuenciales. En cuanto al surtido, el componente de JustEnough proporciona herramientas para la planificación de surtido y asignación (decidir qué productos van a qué tiendas, cómo asignar el stock inicial, etc.). Esto ahora se ubica junto con el forecast de demanda y la reposición. Si está bien integrado, esto significa que ToolsGroup puede optimizar el ciclo de vida completo del producto: planificar el surtido, establecer asignaciones iniciales, forecast de demanda, monitorear y reponer inventario, y ajustar los precios (rebajas) hacia el final de su vida útil. Las piezas están todas sobre el papel. La pregunta es qué tan bien trabajan juntas. Dado que estos eran productos separados, la integración podría no ser todavía perfecta (aunque ToolsGroup afirma contar con una “arquitectura de solución modular” que están ensamblando de forma cohesionada ⁵⁴). Anticipamos que la optimización conjunta en el caso de ToolsGroup podría ser actualmente más secuencial (el módulo de precios toma un forecast del módulo de forecasting y optimiza los precios; el módulo de inventario toma la demanda resultante y optimiza el stock). Con el tiempo, gracias a la analítica avanzada de Evo, podrían fusionarlos en un solo ciclo que optimice directamente el beneficio (precio y cantidad). Por ahora, otorgaremos a ToolsGroup el mérito por avanzar decididamente hacia la optimización conjunta – pocos proveedores en su categoría tienen capacidades tanto de precios como de inventario. Algunos resultados preliminares: ToolsGroup (con Evo) se asoció con minoristas como Decathlon en precios y observó incrementos en el margen mientras respetaba las restricciones de inventario ⁵⁵ ⁵⁶ (la información del caso sugiere pruebas A/B iterativas para encontrar precios óptimos que mejoren el margen sin dañar la imagen de la marca, realizado de manera informada por el stock). Esa es una forma práctica de optimización conjunta (pruebas de precios guiadas por datos de inventario y margen). En resumen, ToolsGroup está evolucionando rápidamente de ser un actor nicho en optimización de inventario a una suite holística de optimización minorista. Probablemente se encuentre detrás de Lokad o de o9 en lo profundamente unificada que es la optimización en este momento, pero está en camino y ya cubre los tres pilares (inventario, precios, surtido).

Probabilistic Forecasting & AI: ToolsGroup fue pionero en forecast probabilístico de demanda para supply chain. Mucho antes de que estuviera de moda, SO99+ generaba distribuciones de demanda en lugar de números únicos, lo que le permitía calcular niveles óptimos de inventario para una probabilidad de servicio objetivo. Este enfoque lo distingue de muchas herramientas tradicionales que utilizaban forecasts promedios y fórmulas de stock de seguridad. ToolsGroup posee una extensa propiedad intelectual en esta área – por ejemplo, utilizando simulaciones de Monte Carlo o modelos analíticos de probabilidad para forecast la variabilidad de la demanda por SKU, y luego determinando políticas de stock. Esta ha sido una de sus principales fortalezas; los clientes a menudo lograban altos niveles de servicio con menor stock porque los métodos de ToolsGroup capturaban mejor la incertidumbre (frente a un stock de seguridad simplista). Continúan educando al mercado sobre el valor del forecast probabilístico (sus materiales lo describen como esencial en entornos inciertos ⁵⁷). Sin embargo, una nota crítica: en el pasado, ToolsGroup a menudo aún reportaba métricas como MAPE a los clientes y en marketing. La revisión de Lokad señaló una inconsistencia donde ToolsGroup publicita forecasts probabilísticos desde 2018 junto con afirmaciones de reducción de MAPE, a pesar de que “MAPE no se aplica a forecasts probabilísticos.” ¹⁹. Esto implica que, o bien su marketing no se actualizó a la metodología (usando una métrica familiar aunque no enteramente aplicable), o bien aún pueden generar un forecast de valor esperado para comparación. En cualquier caso, claramente abrazan el pensamiento probabilístico. En el frente de AI/ML, ToolsGroup ha ido incorporando más machine learning para gestionar los impulsores de la demanda y el reconocimiento de patrones. Tradicionalmente, su forecasting podría haber sido más estadístico (como el método de Croston para demanda intermitente, etc.), pero ahora cuentan con características como la incorporación de factores causales, regresión para promociones e incluso ensembles de machine learning. La adquisición de Evo aporta una IA muy moderna – el “quantum learning” de Evo es básicamente un algoritmo avanzado de ML (posiblemente un ensemble propietario o una técnica de aprendizaje por refuerzo) diseñado para encontrar decisiones óptimas rápidamente ⁵⁸. La integración de Evo en ToolsGroup establece explícitamente que añade “optimización no lineal, quantum learning y analítica prescriptiva avanzada” a sus soluciones ⁵². Esto sugiere un impulso en la sofisticación de la IA, especialmente para decisiones de precios y de promociones, que son, por naturaleza, no lineales. También adquirieron una empresa llamada AI.io (anteriormente llamada Halo Business Intelligence) hace algunos años, lo que les brindó un workbench de forecast de demanda impulsado por IA. Así que ToolsGroup definitivamente está incorporando IA. Dicho esto, su marketing en torno a la IA a veces ha sido algo dudoso, como señaló el estudio de Lokad: “ToolsGroup presenta capacidades extensas; sin embargo, sus afirmaciones sobre ‘IA’ son dudosas. Los materiales públicos insinúan modelos de forecasting anteriores a 2000. Las afirmaciones sobre ‘demand sensing’ no están respaldadas por la literatura científica.” ¹⁹. Esto implica que, hasta hace poco, quizás ToolsGroup estaba re-etiquetando lo que esencialmente son métodos de forecasting de hace décadas (como Croston, ARIMA) como “IA” sin un verdadero ML moderno. Y el uso de términos como “demand sensing” (mencionado en folletos) no estaba respaldado por algo novedoso. Tomamos esto como una advertencia para examinar detenidamente las afirmaciones de IA de ToolsGroup. Sin embargo, con la recién añadida EvoAI (2023), se espera que la sustancia en IA de ToolsGroup haya aumentado – Evo era una empresa joven basada en ML para precios/inventario, y ToolsGroup está promocionando nuevas características concretas provenientes de ella (por ejemplo, selección automatizada de modelos, algoritmos responsivos que se adaptan a cambios recientes, etc.). Asimismo, el propio enfoque probabilístico de ToolsGroup es una especie de IA (modelado estocástico), incluso si no es “machine learning” – es una técnica analítica sofisticada que muchos otros carecían. Así que, en cuanto a la destreza en forecasting, ToolsGroup es fuerte. En cuanto a la nueva IA, están alcanzando a sus pares. En general, ToolsGroup ofrece forecast de calidad confiable y ahora proporciona más información sobre los impulsores de la demanda y las relaciones precio-demanda gracias al ML. Les otorgamos una puntuación alta en forecast probabilístico (siendo uno de los pocos que lo aplicaron extensivamente), y una media en innovación de IA (están mejorando, pero tienen un historial de algo de exageración). La combinación de lo antiguo y lo nuevo puede ser poderosa si se ejecuta correctamente: por ejemplo, usar ML para detectar un cambio de patrón (digamos, debido al COVID), y luego utilizar un modelo probabilístico para ajustar los objetivos de inventario en consecuencia. Es probable que ToolsGroup esté aplicando dichos enfoques híbridos. Solo es necesario asegurarse de que realmente aprovechen el ML donde sea beneficioso y no simplemente lo empleen como una palabra de moda.

Economic Decision-Making: Tradicionalmente, el enfoque de ToolsGroup hacia el inventario se enmarcaba como optimización del nivel de servicio – se establece un objetivo de servicio o tasa de llenado y su algoritmo encuentra el stock mínimo necesario para alcanzarlo dada la incertidumbre. Esto es indirectamente económico (un mejor servicio evita ventas perdidas, y tener menos stock evita costos de mantenimiento), pero no maximiza explícitamente el beneficio. Sin embargo, incorporaron optimización de inventario multi-etapa (MEIO) que equilibra de forma inherente el inventario frente a los costos por órdenes pendientes, etc., una optimización fundamentada en lo económico. Con su visión más reciente, la rentabilidad pasa a estar en el centro. El CEO de ToolsGroup afirmó que la combinación con JustEnough tiene como objetivo brindar a los minoristas “una vista de 360 grados que es en tiempo real, predictiva y accionable… los clientes pueden mejorar de manera más eficiente la disponibilidad del producto y superar a la competencia en la gestión de la demanda volátil de hoy.” ⁵⁹. Aunque esa cita enfatiza el servicio y la agilidad, la nota de prensa de la adquisición de Evo es más directa: “extiende nuestra ventaja con la optimización dinámica de precios… permitiéndonos dar el siguiente salto hacia la Planificación Centrada en la Decisión … esencial para entregar la cadena de suministro autónoma del futuro.” ⁵². El término “centrada en la decisión” implica enfocarse en el resultado de la decisión (a menudo de naturaleza financiera). El fundador de Evo habló sobre la visión de “decisiones más inteligentes para los gerentes humanos a través de cálculos óptimos de precio e inventario” ⁵³ – lo cual significa claramente utilizar la optimización para maximizar algún objetivo (probablemente beneficio o ingresos) en lugar de solo cumplir objetivos de servicio. Y, de hecho, “la IA responsiva de Evo ofrece un ingrediente esencial para entregar la cadena de suministro autónoma” ⁵⁸ – presumiblemente, este ingrediente consiste en ajustar continuamente las decisiones basándose en los resultados, lo que se asemeja a la maximización de las métricas de desempeño. En el lado de precios, la rentabilidad es obviamente clave – la solución de precios de ToolsGroup se centra en “maximizar la rentabilidad mediante la creación de una estrategia de precios basada en datos” ⁶⁰. Permite la fijación de precios basada en reglas, pero también utiliza ML para ajustarse a los cambios en la demanda del consumidor, y “maximizar el margen de beneficio” dentro de límites establecidos ⁶¹. La mención de “Se pueden crear diferentes precios… con una vista completa del… inventario y la tasa de venta, ayudando a satisfacer la demanda y minimizar costos a lo largo de la supply chain.” ⁴⁹ muestra que la herramienta de precios no solo analiza el margen de forma aislada, sino que también considera los costos de mantenimiento del inventario y, potencialmente, la evitación de rebajas (minimización de costos). Eso es pensar de forma económica – decisiones de precios que tienen en cuenta los costos de la supply chain. En cuanto al inventario, ToolsGroup también puede incorporar el costo de mantener stock versus el costo por faltante de stock si se configura, optimizando así los niveles de servicio de forma económica. De hecho, los objetivos de servicio pueden derivarse de un modelo económico (por ejemplo, mayor servicio para productos de mayor margen). No está claro si ToolsGroup lo hace explícitamente, pero los clientes a menudo realizan esa clasificación externamente. Ahora, con la analítica prescriptiva de Evo, se espera que ToolsGroup avance hacia la recomendación de decisiones óptimas en beneficio (como cuánto stockar y a qué precio para maximizar el beneficio esperado, dada la incertidumbre). Los elementos están presentes, y se supone que el equipo de Evo ya contaba con esta metodología (sus antecedentes académicos sugieren pericia en investigación operativa). Una ligera advertencia: la comunicación de ToolsGroup aún suele hacer referencia a KPIs tradicionales (servicio, reducción de inventario) más que al beneficio directo. Sin embargo, eso es similar a lo que ocurre con otros en el espacio de supply chain. Tenemos evidencia de que están incorporando más rentabilidad – por ejemplo, su función de racionalización de surtido (probablemente proveniente de JustEnough) para eliminar SKUs no rentables, alineando el surtido con la contribución financiera. Además, las historias de clientes mencionan la reducción de inventario y la mejora en ventas/servicio (lo que se traduce en mejoras de beneficio). No existe un ejemplo público de ToolsGroup maximizando de forma directa una métrica de beneficio, pero la combinación de la optimización de precios e inventario se inclina inherentemente en esa dirección. Le otorgamos a ToolsGroup una puntuación bastante alta en este aspecto, destacando su enfoque tradicional de “servicio al menor costo” y su nuevo impulso hacia precios basados en margen. Puede que aún no estén tan obsesionados con el costo de oportunidad como Lokad, pero definitivamente van más allá de heurísticas simplistas. Una crítica a mencionar: la revisión de Lokad sugirió que los materiales de ToolsGroup están algo desfasados – utilizando MAPE, etc., lo cual podría indicar que no están enmarcando completamente las cosas en términos de costo esperado de forma pública ⁶². Aun así, la adición de Evo y la mención de “los mejores resultados financieros” ⁶³ para los clientes que utilizan la optimización combinada de precio+inventario ⁶³ es una señal contundente de un enfoque en objetivos económicos.

Escalabilidad y Eficiencia en Costos: El SO99+ original de ToolsGroup se desplegaba típicamente on-premise o como solución alojada para empresas medianas a grandes. No es tan pesado como algunos sistemas APS grandes; por diseño se enfocaba en las “partes difíciles” (forecast, cálculos de inventario) y no en una integración masiva de datos. Muchas empresas medianas lo ejecutaron con éxito. Está bastante optimizado matemáticamente, lo que significa que la computación para la optimización de inventarios no es enorme (resolviendo la distribución de inventarios mediante algoritmos y quizá programación lineal para multi-echelon). Para demand forecasting, contaban con su propio motor que podía procesar grandes cantidades de series durante la noche (por ejemplo). Ahora ofrecen una opción completa SaaS en la nube, que probablemente sea más fácil de escalar según se requiera. En el informe Gartner 2024, ToolsGroup fue un nuevo participante y se destacó por su “costo de entrada asequible” y “precios transparentes”, además de usarse como una solución global única para algunos (lo que implica que puede escalar globalmente) ⁶⁴ ⁶⁵. Esto sugiere que ToolsGroup se considera relativamente eficiente en costos y escalable para su categoría. De hecho, su enfoque en el mercado medio históricamente significó que debían ser más listos desde el primer momento y no requerir un ejército de IT. En retail, los volúmenes de datos pueden ser grandes (a nivel tienda-SKU). JustEnough (el sistema de retail adquirido) era conocido por atender a grandes minoristas (tenía clientes como Sephora, creo) por lo que puede manejar surtidos considerables. Sin embargo, algunos aspectos, como la optimización de precios (si se hacen precios detallados a nivel tienda), pueden volverse intensivos en datos. Es probable que el despliegue típico de ToolsGroup siga siendo algo batch-oriented – por ejemplo, reforecast nocturno o semanal, actualizaciones de inventario – en lugar de en tiempo real, lo cual es adecuado en muchos contextos. Esto significa que no es necesario tener todo en memoria 24/7; pueden computar y liberar memoria. Esto resulta más eficiente en costos que un enfoque constante en memoria. Por otro lado, para integrarse con precios dinámicos, podrían necesitar ciclos de computación más frecuentes. Resaltan la “responsive AI” con Evo, lo que significa recalculaciones más rápidas cuando las condiciones cambian ⁵⁸. La tecnología de Evo podría permitir una re-optimización near real-time (Evo, al ser una startup, probablemente utilizó la nube y quizá computación con GPU para mayor velocidad). ToolsGroup también adquirió Onera en 2022 para visibilidad de inventario en tiempo real y optimización de fulfillment ⁶⁶, lo que significa que se están adentrando en decisiones de fulfillment de e-commerce en tiempo real. Estas adiciones podrían incrementar la potencia computacional requerida. Pero dado su posicionamiento en el mercado, ToolsGroup buscaría hacer esto de forma eficiente para atraer también a minoristas medianos, y no solo a mega-minoristas. La arquitectura ahora es algo modular: núcleo SO99+ (quizás en C++) más servicios en la nube que se conectan a los módulos de JustEnough (que podrían ser .NET o Java). La integración de estos podría añadir temporalmente sobrecarga (dos sistemas comunicándose). Sin embargo, ToolsGroup está integrando activamente – por ejemplo, “Gracias al recientemente integrado motor EvoAI, JustEnough lidera la carga en la planificación de retail impulsada por AI” ⁶⁷, lo que indica que están incorporando Evo en la solución JustEnough/ToolsGroup en lugar de mantenerlo separado. La huella de ToolsGroup es generalmente más ligera que la de SAP o Blue Yonder. Por ejemplo, un proyecto de ToolsGroup podría no requerir un equipo interno de IT para gestionar servidores enormes – ellos lo manejan como SaaS. Mencionan que “la arquitectura modular facilita que los clientes seleccionen los productos que necesitan y los integren en una solución cohesiva” ⁵⁴ – lo que implica que no es necesario cargar todo si no se usa, lo que favorece la escalabilidad (se puede ejecutar solo el motor de inventario si es lo único que se necesita).

Manejo de Factores Complejos del Retail: ToolsGroup históricamente se destacó en manejar la incertidumbre de la demanda y la variabilidad, incluyendo la demanda intermitente, los productos de lento movimiento y la variabilidad en el suministro. Puede que no haya sido tan especializado en fenómenos específicos del retail, como la canibalización o la vida útil de los productos, de serie. Sin embargo, con la suite JustEnough, ganaron capacidades en el dominio retail: JustEnough proporcionó promotion forecasting, allocation (que considera la capacidad de la tienda y el merchandising) y planificación de markdown. Así, ToolsGroup ahora tiene funcionalidades para promociones – por ejemplo, pueden modelar el incremento de ventas de una promoción y distribuirlo a lo largo del tiempo, lo que trata de forma básica la canibalización (si una promoción genera ventas tempranas, los periodos posteriores disminuyen, etc.). ¿Identifican automáticamente la canibalización entre artículos? Posiblemente no tan automáticamente como RELEX, pero pueden incorporar los efectos promo si se conocen. Para los efectos de sustitución (faltante de stock que causa ventas de artículos alternativos), ToolsGroup no lo ha destacado en los materiales que vimos. Eso podría seguir siendo una deficiencia a menos que se configure manualmente. Para los efectos halo (complementarios), probablemente sea similar – habría que modelar las relaciones manualmente o usar un enfoque de AI. Es un área en la que su nueva AI (Evo) podría ayudar al hallar correlaciones. El motor de Evo podría, potencialmente, extraer datos de transacciones para ajustar forecast o estrategias de precios para artículos relacionados. Sin evidencia específica, asumiremos que ToolsGroup puede gestionar esto con cierto esfuerzo, pero no es su punto más fuerte históricamente. Expiración y perecederos: ToolsGroup tuvo algunos clientes en distribución de alimentos, pero no se sabe con certeza sobre la optimización fresca a nivel de tienda. Probablemente no sea su enfoque principal. Pueden incorporar tiempos de entrega y lotes, pero las restricciones de vida útil requerirían una modelación explícita (por ejemplo, tratar el inventario que expira como SKU separado o ajustar el forecast a la baja con el paso del tiempo). El módulo de allocation de JustEnough podría gestionar productos de temporada (asegurando que se agoten al final de la temporada mediante markdowns), lo cual es similar a manejar perecederos en concepto. De hecho, la optimización de markdown (parte de JustEnough) se centra básicamente en programar las rebajas de precio para liquidar inventario sin remanentes – lo que es análogo a gestionar la “expiración” al final de la temporada. La herramienta de precios de ToolsGroup ayudará al recomendar cuándo aplicar markdown y en qué medida para evitar la obsolescencia mientras se maximiza el ingreso ⁴⁹. Así, abordan el aspecto económico de la perecibilidad (liquidar antes de generar desperdicio). En cuanto a la localización de surtido: la planificación de surtido de JustEnough permite agrupar tiendas y personalizar los surtidos, de modo que ToolsGroup puede optimizarlos según los patrones de demanda locales y las limitaciones de espacio. Esto aborda de forma indirecta la canibalización (si dos artículos se canibalizan, una optimización de surtido podría decidir llevar solo uno en tiendas más pequeñas, etc.). Restricciones de espacio y exhibición: a través de JustEnough, ToolsGroup puede modelar cuántos frentes o la capacidad de estantería en las tiendas, lo que influye en la asignación y las decisiones de reposición (si un estante soporta X, no se envía más de X). No es tan granular como una solución planogram, pero a nivel de planificación está cubierto. Promociones: ToolsGroup maneja el promotion forecasting y puede planificar inventarios para promociones (tienen estudios de caso donde ayudaron a mejorar el in-stock durante promociones). La nueva AI probablemente mejora cómo predicen los aumentos en promociones al analizar las promociones pasadas de forma más precisa (quizás similar a demand sensing a corto plazo, aunque Lokad señaló que las afirmaciones de “demand sensing” no estaban bien fundamentadas ⁶⁸). Canibalización/halo específicamente: no hallamos referencias directas, por lo que eso aún podría depender de la pericia del planificador para ajustar. La filosofía de ToolsGroup siempre fue simplificar la labor del planificador – implementaron automatización para que los planificadores gestionen por excepción. Probablemente tengan excepciones para faltante de stock o ventas anómalas, pero si vinculan eso con la lógica de sustitución no está claro. Con la evidencia moderada, calificamos a ToolsGroup como competente pero no líder en el manejo de factores complejos. Cubren promociones y markdowns (necesidades comunes en retail), cuentan con lógica de surtido, pero en aspectos como las interacciones entre productos y los perecederos, quizás no sean tan avanzados como RELEX. La incorporación de AI y su enfoque en ajustes “responsive” podría eventualmente incluir la detección automática de estos patrones. Según 2021, la crítica de Lokad fue que lo que ToolsGroup llamaba “demand sensing” (usando datos recientes para ajustar forecast) no estaba bien fundamentado ⁶⁸. Quizá en ese entonces carecían de un algoritmo real para ello; tal vez ahora sí lo hagan (con Evo o desarrollo interno). En suma, ToolsGroup gestiona bien los fundamentos de la planificación retail (variabilidad en la demanda, promociones, fin de vida) y es adecuado en surtido, pero aún se está poniendo al día en aspectos de vanguardia (p.ej., modelación de canibalización basada en ML, sustitución).

Automatización: ToolsGroup históricamente se ha enorgullecido de la automatización y la planificación “sin intervención”. De hecho, uno de los puntos fuertes del SO99+ era que podía establecer automáticamente las políticas de stock y generar órdenes de reposición con una intervención mínima del planificador. Muchos de sus clientes reportan que dedican mucho menos tiempo a resolver problemas de forecast o de inventario después de implementar ToolsGroup, ya que el sistema se ajusta automáticamente a los cambios y solo marca las excepciones. Utilizan términos como “self-adaptive” para su forecast, lo que significa que se adapta por sí solo a nuevos patrones de demanda, reduciendo la necesidad de anular continuamente los forecast. El concepto de “Powerfully Simple” (uno de sus slogans) se refería a simplificar las tareas del planificador mediante la automatización. En la práctica, una configuración de ToolsGroup suele ejecutar procesos batch nocturnos para actualizar los forecast y los objetivos de inventario, y luego sugiere órdenes para cada combinación artículo-local. Los planificadores solo revisan los artículos que presentan excepciones (como servicio muy bajo o inventario excesivamente alto). Esto es, en esencia, una planificación lights-out para una gran parte del surtido. Un caso (de marketing anterior) afirmó que un cliente automatizó el 90% de las reposiciones de SKU, revisando manualmente solo el 10% superior de las excepciones, lo que demuestra un buen nivel de autonomía. Ahora, con la integración de JustEnough, que incluye tareas de planificación que tradicionalmente son manuales (por ejemplo, elaborar planes de surtido, establecer la asignación inicial, crear planes financieros), ToolsGroup puede necesitar mantener un equilibrio entre la automatización y la intervención del usuario. La planificación de surtido típicamente requiere la aportación estratégica del comerciante, lo que no puede automatizarse completamente. Pero ToolsGroup puede automatizar el análisis subyacente (como señalizar automáticamente qué artículos deben recibir markdown o clasificar sistemáticamente las tiendas por ventas para la asignación). En cuanto a precios, el dynamic pricing puede automatizarse hasta cierto punto: el módulo de precios de ToolsGroup permite establecer reglas y luego aplicar los cambios de precio automáticamente dentro de esos márgenes ⁶⁹. Por ejemplo, un minorista podría permitir que se apliquen markdowns automáticos cuando el inventario supere X días de suministro, lo que la herramienta ejecuta sin cálculos manuales. Mencionan explícitamente “establecer reglas de precios, y luego aplicarlas automáticamente dentro de los límites establecidos” ⁶⁹ – lo que es automatización con supervisión. De este modo, gran parte de la toma de decisiones puede realizarse sin intervención: el sistema monitorea el inventario y la demanda, y si las condiciones cumplen las reglas (quizás mejoradas con sugerencias de AI), puede implementar un cambio de precio. Esto constituye una acción verdaderamente autónoma en precios (aunque, al inicio, probablemente sujeta a la aprobación de un gerente). De forma similar, sus sugerencias de replenishment pueden enviarse automáticamente al ERP para ejecutar las órdenes. ToolsGroup enfatiza frecuentemente el management de excepciones, lo que implica que, si no hay excepciones, se confía en la salida del sistema. Con la AI de Evo, insinúan avanzar hacia una “supply chain autónoma” también ⁵⁸. De hecho, usaron esa expresión, alineándose con la tendencia del sector. La tecnología de Evo podría permitir una re-optimización más continua (como ajustar los forecast a mitad de mes si las ventas se desvían y reordenar en consecuencia, todo de forma automática). Las nuevas funcionalidades de ToolsGroup, como Inventory Hub (señales en tiempo real), sugieren que pueden detectar un evento (por ejemplo, un pico en la demanda) y reaccionar automáticamente reasignando stock o acelerando el suministro. No se han dado detalles, pero ese parece ser el objetivo. En conjunto, ToolsGroup siempre se ha orientado hacia la planificación sin intervención – dejando que el sistema gestione las decisiones rutinarias. Hay evidencia de que algunos de sus clientes operan con mínima intervención del planificador en gran parte de sus operaciones. Por ello, ToolsGroup obtiene una puntuación muy alta en automatización. La única limitación surge al incursionar en áreas nuevas como el surtido y los precios, donde la estrategia del usuario juega un rol mayor – aunque incluso allí, proporcionan automatización en los aspectos tácticos (como señalizar automáticamente qué artículos deben recibir markdown o clasificar sistemáticamente las tiendas por ventas para la asignación). La combinación de la automatización basada en reglas (para restricciones empresariales) y las sugerencias basadas en AI (para decisiones complejas) posiciona a ToolsGroup como un proveedor que puede ofrecer una reducción significativa en el esfuerzo manual de planificación. De hecho, Gartner señaló que “los planificadores orquestan actividades humanas y de máquina” con algunas herramientas nuevas – y ToolsGroup probablemente facilita esa orquestación (sus flujos de trabajo pueden escalar automáticamente ciertas decisiones a los humanos, lo cual forma parte de un diseño de bucle autónomo). Dado todo esto, confirmamos la fortaleza de ToolsGroup en automatización.

Integración Tecnológica: La estrategia reciente de ToolsGroup ha involucrado adquisiciones, lo que naturalmente plantea la cuestión de la integración de la plataforma. Hasta ahora, cuentan con SO99+ (su motor legacy), JustEnough (ahora a menudo referido como ToolsGroup Retail Planning) y el motor de AI de Evo, además de la tecnología Onera en tiempo real. Están integrándolos activamente: por ejemplo, el comunicado de prensa declara “la integración de las soluciones de Evo con SO99+ y JustEnough ofrecerá a los clientes la solución de supply chain en tiempo real más eficiente y de optimización de precios” ⁴⁷, lo que indica que los tres se están fusionando en una única oferta. Enfatizan que su arquitectura modular permite a los clientes elegir lo que necesitan y que todo encaja ⁵⁴. Esto sugiere que han creado interfaces o un modelo de datos común (o están en proceso de hacerlo) para que los datos fluyan entre los módulos sin transferencia manual. La buena señal es que JustEnough ha estado bajo ToolsGroup desde 2018 (a través de la adquisición de Mi9); ya han tenido tiempo para integrar piezas importantes. De hecho, ToolsGroup comercializa la solución combinada bajo un único nombre en muchos casos. Es probable que hayan unificado la interfaz de usuario hasta cierto punto – posiblemente aún no sea una única UI para todo, pero podría estar cerca. Han incorporado el AI de Evo en JustEnough, como se mencionó ⁶⁷, lo que demuestra una integración técnica real en lugar de venderlos por separado. Esto es prometedor: parece que ToolsGroup está evitando deliberadamente mantener estos módulos en compartimentos estancos. Sin embargo, hay que reconocer que, durante un tiempo, probablemente fue una “suite” de componentes separados – por ejemplo, el usuario tenía que utilizar la interfaz de SO99+ para cierta configuración y la interfaz de JustEnough para otras. Esto puede resultar torpe al principio. El tamaño relativamente pequeño de ToolsGroup significa que la integración podría ser más ágil, con menos obstáculos burocráticos que en SAP. El objetivo es, claramente, una suite de planificación coherente de extremo a extremo. Comparten datos: por ejemplo, el forecast generado (probablemente por SO99+ o Evo) alimenta tanto la planificación de inventario como las partes de planificación financiera de mercancías. A falta de evidencia en contrario, asumiremos que ToolsGroup ha progresado significativamente en la integración de estas adquisiciones. Posiblemente, existan inconsistencias menores (por ejemplo, los métodos de forecast en SO99+ frente a los nativos de JustEnough podrían diferir – pero probablemente se estandarizarían en el mejor). En cuanto a la pila tecnológica, históricamente ToolsGroup era cliente-servidor basado en Windows para SO99+, mientras que JustEnough se basaba en la web con .NET. Ahora, todos se ofrecen mediante una interfaz web en la nube. Es probable que no se trate de una base de código 100% unificada, pero la apariencia para el usuario podría estar unificada a través de un portal. Esto aún cuenta como integrado desde la perspectiva del usuario si se hace bien (similar a cómo, por ejemplo, Microsoft integra de manera transparente, con el tiempo, los productos adquiridos en su suite de Office). Debemos mencionar que la tecnología fundamental de ToolsGroup (optimización de inventario) era muy sólida y probada a lo largo del tiempo. No la han descartado; han construido sobre ella. Eso es bueno porque no están reinventando la rueda, pero también significa que, en el núcleo, parte del sistema es código antiguo. A veces, el código antiguo no se mezcla perfectamente con los microservicios más nuevos. No disponemos de información directa, así que es algo a tener en cuenta. El propio comentario de ToolsGroup sobre sus competidores solía ser que los grandes proveedores de suites son como Frankenstein; ahora, ToolsGroup debe evitar eso ellos mismos. Al integrar proactivamente y no simplemente rebrandear, parecen conscientes de ello. Por ejemplo, las adquisiciones de SAP dieron como resultado una “colección desordenada” y dificultades de integración ¹¹, como se señaló anteriormente. ToolsGroup afirmó explícitamente que la combinación de la planificación minorista de JustEnough con su automatización y optimización de inventario ofrece una combinación única, y que “los productos encajan en una solución cohesiva” ⁵⁴. Con cautela confiamos en esto, pero seguimos siendo conscientes de que podrían existir algunas fisuras (por ejemplo, un usuario podría tener que configurar datos maestros en dos lugares si la integración no es completa). En resumen, ToolsGroup se encuentra en una integración intermedia: no estaba originalmente unificada, pero se está moviendo activamente hacia ello. Les daremos una puntuación moderada: mejor que aquellas empresas que simplemente adquirieron y dejaron las piezas separadas, pero no tan inherentemente unificadas como una plataforma construida de forma única. Dado más tiempo (y a medida que probablemente reconfiguren componentes hacia una arquitectura común en la nube), deberían alcanzar una alta integración. Hasta ahora, al menos, la visión y las acciones se alinean para evitar un Frankenstein.

Escepticismo ante el Bombardeo Publicitario: El marketing de ToolsGroup presenta una mezcla de practicidad y bombo. No son tan ruidosos como algunos otros, pero sí se lanzaron a utilizar palabras de moda como AI, demand sensing, autónomo, etc., en años recientes. Como se mencionó, el análisis de Lokad señaló específicamente a ToolsGroup por el bombo: “las afirmaciones de ‘AI’ son dudosas… las afirmaciones sobre ‘demand sensing’ no están respaldadas” ¹⁹. Por ejemplo, ToolsGroup publicó contenido sobre “demand sensing” (ajustes a corto plazo) que podría haber sido simplemente un lenguaje sofisticado para utilizar un promedio móvil de las ventas recientes – no es exactamente novedoso. Esto podría inducir a error a clientes menos expertos haciéndoles pensar que disponen de algo mágico. Además, ToolsGroup, en ocasiones, cita resultados increíbles de clientes (como “inventario reducido en un 30% mientras el servicio aumentó al 99%”), lo cual, si bien puede ser cierto en un caso concreto, puede sonar demasiado bueno para ser generalmente cierto. Necesitamos ver evidencia consistente. Por otro lado, ToolsGroup existe desde hace mucho tiempo y, en general, goza de una buena reputación por ofrecer resultados, por lo que su bombo no suele carecer de fundamento. Quizás abusaron del vocabulario AI alrededor de 2018, cuando todos lo hacían. Ahora que realmente han adquirido una empresa de AI, sus afirmaciones sobre AI podrían tener mayor peso. Mencionan “quantum learning”, lo que, francamente, suena a palabra de moda (la computación cuántica en realidad no se utiliza, es solo un nombre de marca para su algoritmo). Eso resulta algo pomposo. Sin embargo, sí dan pistas sobre lo que realmente es (optimización no lineal, analítica prescriptiva) ⁵². También han comenzado a posicionarse como “Líder en SPARK Matrix para Retail Forecasting & Replenishment” ⁷⁰ – haciendo referencia a clasificaciones de analistas que pueden tener influencia del proveedor. Es marketing, pero no exagerado. Un aspecto a vigilar: ToolsGroup dice “Autónomo” ahora. Debemos ser cautos respecto a cuán autónomo es en realidad. Aunque pueden automatizar mucho, una supply chain completamente autónoma es un camino a recorrer. Mientras lo enmarquen como un objetivo (lo hacen: “camino hacia una Planificación Centrada en Decisiones (autónoma)” ⁵⁸), resulta aceptable. Si afirmasen integración plug-and-play, eso podría ser una exageración – implementar ToolsGroup aún requiere integración y configuración. Sin embargo, dado que su objetivo es el mercado medio, enfatizan implementaciones más rápidas que los grandes proyectos ERP. A menudo resaltan la facilidad de uso, lo cual es plausible y no puro bombardeo publicitario. En términos de moderación en el uso de palabras de moda, probablemente se encuentren en un nivel intermedio: no son los peores en este sentido, pero sí participan en ello. La inconsistencia en el uso de una métrica inadecuada (MAPE para forecast probabilístico) fue una señal de alerta menor ⁶² – lo que sugiere que el marketing quería mostrar una mejora en números, aun cuando no fuera metodológicamente correcto. Preferiríamos una comunicación honesta como “nuestro enfoque es diferente, aquí está la razón por la que las métricas tradicionales no aplican, aquí hay mejores métricas.” Es posible que ToolsGroup haya simplificado en exceso para lograr la venta. Dicho esto, la fidelidad de los clientes de ToolsGroup y su tasa de renovación indican que, en general, cumplen con las expectativas. Sus afirmaciones se respaldan con estudios de caso. No venden vaporware; venden tecnología comprobada, actualizada con las adquisiciones. Así pues, el bombo se centra fundamentalmente en etiquetar las cosas como “AI” o “quantum” cuando, en realidad, podrían ser simplemente técnicas de ML estándar. Eso es común en la industria. Recomendamos cautela, pero no el descarte total. El usuario debe pedirles que aclaren cómo funciona su AI, cómo se implementa el demand sensing, etc. Es probable que ToolsGroup pueda ofrecer una respuesta (incluso si resulta ser algo como “utilizamos machine learning para ajustar los forecast a corto plazo usando las últimas señales de ventas e inventario” – lo cual está bien, siempre que no resulte místico). En resumen, el marketing de ToolsGroup en los últimos años ha incluido algunas palabras de moda que deben ser analizadas con escepticismo, pero también mantiene un enfoque en entregables concretos (nivel de servicio, reducción de inventario, etc.). Les otorgamos una calificación media en cuanto al escepticismo ante el bombo: no se exceden en el uso de palabras de moda, pero, fundamentalmente, poseen más sustancia que puro adorno (con una pequeña desventaja por algunas frases engañosas señaladas por análisis externos).

Resumen: ToolsGroup es un jugador maduro pero en evolución en la optimización del retail. Aporta décadas de experiencia en optimización de inventario con forecast probabilístico, ahora complementada por capacidades de planificación de mercancías y optimización de precios a través de adquisiciones. Como resultado, ToolsGroup ahora puede abordar la optimización conjunta de inventario y precios – utilizando demand forecasts que tienen en cuenta los cambios de precio y tomando decisiones de precios informadas por las posiciones de inventario ⁴⁹. Sus esfuerzos de integración están convirtiendo estas herramientas, que antes eran separadas, en una suite de planificación cohesiva, aunque aún podrían estar resolviéndose algunos inconvenientes de integración. La fortaleza de ToolsGroup en modelado probabilístico significa que maneja de manera robusta la incertidumbre de la demanda y genera estrategias de stock para cumplir con el servicio al costo mínimo, y sus nuevas mejoras en AI apuntan a adaptar continuamente estas decisiones en tiempo real ⁵⁸. Cuenta con un historial comprobado de automatización de procesos de planificación – muchas tareas rutinarias de forecast y reposición pueden ejecutarse sin supervisión, con los planificadores gestionando las excepciones. Ahora, con módulos de precios y surtido, extiende la automatización a esas áreas (por ejemplo, auto markdowns basados en reglas ⁶⁹ y ajustes de surtido sugeridos por AI). En términos de complejidades del retail, ToolsGroup cubre bien lo básico (forecast de promociones, liquidación estacional, agrupamiento de tiendas), aunque puede que aún no detecte de forma automática canibalización o patrones de sustitución en la medida en que lo hacen algunos sistemas especializados. Su enfoque de optimización económica ha pasado de centrarse únicamente en los niveles de servicio a incorporar métricas de beneficio (especialmente en decisiones de precios y surtido ³³). Los usuarios deben estar alerta ante un poco de hipérbole en el marketing – ToolsGroup utiliza de forma liberal las últimas palabras de moda como “autónomo” y “AI”, y una crítica de terceros ha señalado que algunas de sus afirmaciones anteriores sobre AI estaban sobredimensionadas ¹⁹. Sin embargo, dadas las mejoras tangibles que muchos clientes reportan y la seria inversión que ToolsGroup ha realizado en nuevas tecnologías (como Evo), la sustancia detrás de sus afirmaciones es significativa. ToolsGroup emerge en nuestro ranking como una opción técnicamente sólida y pragmática: aquella que, si bien puede no tener el brillo de una startup puramente de AI o la escala extrema de una mega-suite, ofrece una solución equilibrada y avanzada para minoristas que desean optimizar su planificación con menos bombo y más resultados prácticos. Es particularmente adecuada para organizaciones que buscan una optimización de inventario comprobada con el beneficio adicional de una planificación integrada de precios y surtido – haciendo que una solución previamente “legacy” sea mucho más a prueba de futuro mediante la modernización. Siempre y cuando se mantenga un escepticismo apropiado ante las palabras de moda y se verifique que la integración satisface sus necesidades, ToolsGroup representa una solución state-of-the-art (o muy cercana a ello), rejuvenecida para la era de las decisiones retail impulsadas por AI.

Fuentes: Integración de precios con vista de inventario ⁴⁹; crítica a las afirmaciones sobre AI y demand sensing de ToolsGroup ¹⁹; ToolsGroup/Evo sobre la entrega de decisiones óptimas de precio+inventario ⁵² ⁵³.

5. Blue Yonder (anteriormente JDA) – Potente suite de retail reconstruida para SaaS, pero se evidencian raíces legacy

Blue Yonder, conocido históricamente como JDA Software, es uno de los proveedores de software de optimización de retail y supply chain más grandes y antiguos. Ofrece una suite integral que abarca forecast de demanda, reposición, asignación, gestión de categorías (surtido), optimización de precios y markdowns, gestión de almacenes, programación de la plantilla y más. En 2020, JDA se rebrandeó como Blue Yonder tras adquirir una firma alemana de AI con el mismo nombre. Blue Yonder (BY) ha migrado, desde entonces, gran parte de su portafolio a una plataforma Luminate unificada con microservicios y se posiciona como una solución de supply chain y merchandising de extremo a extremo, impulsada por AI ⁷¹. Indudablemente, cumple con todas las funcionalidades: pocos proveedores pueden igualar la amplitud de las ofertas de optimización de retail de BY. Sin embargo, la suite de Blue Yonder también es producto de décadas de adquisiciones (i2, Manugistics, Arthur, RedPrairie, etc.), y si bien la nueva arquitectura Luminate, nativa de la nube, es moderna, bajo el capó algunos algoritmos y módulos se remontan a enfoques legacy. Una evaluación crítica de un competidor afirmó de manera directa: “Blue Yonder es el resultado de una larga serie de M&A… Bajo la bandera de BY se esconde una colección desordenada de productos, muchos de ellos anticuados. BY destaca AI, pero sus afirmaciones son vagas y con poca sustancia; proyectos de código abierto insinúan enfoques anteriores al 2000 (ARMA, regresión lineal).” ⁷². Esto resalta el escepticismo principal: ¿Es Blue Yonder verdaderamente state-of-the-art o un gigante legacy reempaquetado? Clasificamos a Blue Yonder algo más abajo en nuestra lista, no porque carezca de capacidad (tiene toneladas), sino por las preocupaciones acerca de su cohesión, eficiencia y claridad en sus afirmaciones. Aun así, como jugador dominante, merece una examinación minuciosa.

Optimización Conjunta: La suite de Blue Yonder esencialmente proporciona módulos separados pero integrados para optimización de precios, forecast de demanda & reabastecimiento, y planificación de surtido/planificación de mercancía. En teoría, un minorista que use todas las soluciones de Blue Yonder puede lograr la optimización conjunta mediante la interacción de estos módulos. Por ejemplo, Blue Yonder ofrece aplicaciones de Lifecycle Pricing (optimización de precios regulares, optimización de markdown, optimización de promoción) que se alimentan de forecast de demanda provenientes de su motor Luminate Demand Planning. Esos forecast de demanda, a su vez, consideran los efectos del precio porque el forecast de Blue Yonder (originalmente proveniente de la adquisición alemana de Blue Yonder) incluye modelado de elasticidad. Como explicó Michael Orr de Blue Yonder, “Blue Yonder utiliza datos para entender cómo es probable que se comporten los clientes y cuál puede ser el impacto del precio en los niveles de inventario,” ayudando a los minoristas a evitar que los precios sean demasiado altos o demasiado bajos ²⁷. Esto demuestra que la optimización de precios de BY no se realiza de forma aislada: modela de manera explícita cómo los cambios en el precio afectan la demanda y, por ende, el inventario. Además, la planificación de cumplimiento de Blue Yonder se puede vincular a las decisiones de precios asegurando que, si se planifica una bajada de precio (lo que incrementará la demanda), los planes de suministro se ajusten en consecuencia. De manera similar, la herramienta de gestión de categoría de Blue Yonder (anteriormente Category Management de JDA) ayuda a decidir los surtidos y planogramas; esas decisiones alimentan sus sistemas de forecast de demanda y reabastecimiento. Contaban con un concepto integral denominado “planificación minorista integrada”, que alinea los planes financieros de mercancía, los planes de categoría y los planes de suministro. En la práctica, históricamente los clientes de JDA a menudo ejecutaban estos procesos de forma semi-separada debido a la complejidad de la herramienta. Pero con Luminate, BY afirma una integración más fluida mediante una plataforma común. Destacan su “microservices architecture” que soporta la planificación de extremo a extremo ⁷¹ – es decir, por ejemplo, un servicio de planificación de promociones podría llamar al servicio de forecast de demanda sobre la marcha para obtener proyecciones actualizadas bajo diferentes escenarios de precios. El enfoque de planificación concurrente de Blue Yonder (como “Harmony” en su UI) puede mostrarle a un planificador el impacto de las decisiones a lo largo de las distintas funciones. Así que sí, Blue Yonder es capaz de lograr la optimización conjunta en el sentido de que todas las piezas se comunican: las decisiones de precios informan los forecast que, a su vez, informan el inventario, y viceversa. Sin embargo, cabe cuestionar cuán óptima es realmente esa coordinación. A menudo podría seguir un proceso secuencial (realizar un forecast con un precio asumido, optimizar el inventario en base a ese forecast y, de manera separada, optimizar los precios dadas las restricciones de inventario de forma iterativa). Hay evidencia de que Blue Yonder está persiguiendo una verdadera concurrencia: por ejemplo, su nueva visión de “Autonomous Planning” probablemente pretende enlazar estos procesos de forma dinámica. La adquisición por parte de Blue Yonder de una firma de optimización de precios (se asociaron con dunnhumby, pero más recientemente creo que integraron sus capacidades internas con la plataforma ML alemana de BY) garantiza que cuentan con algoritmos avanzados para la optimización de precios. En general, Blue Yonder proporciona las herramientas para la optimización conjunta, pero si un usuario llega a lograrla depende de la implementación de múltiples módulos. Debido a que la suite de Blue Yonder es modular, algunos clientes pueden utilizar solo, por ejemplo, la planificación de demanda & de suministro y no la optimización de precios, sin alcanzarse así la optimización conjunta completa exclusivamente con BY. Para aquellos que usan la suite completa, Blue Yonder ciertamente puede abarcar colectivamente las decisiones de inventario, precios y surtido. Cabe notar, sin embargo, que las soluciones de Blue Yonder no se construyeron originalmente como una única solución integrada – fueron integradas posteriormente. Aunque Luminate ha avanzado en conectarlas, es posible que la integración aún no sea tan estrecha como en un modelo único de optimización (por ejemplo, el motor de optimización de precios podría no tener en cuenta de forma nativa los niveles de stock actuales a menos que se configure, etc.). Dada la evidencia, Blue Yonder se merece una buena puntuación en cuanto al potencial de optimización conjunta, con la salvedad de que podría requerir un esfuerzo significativo para realizar plenamente ese potencial.

Forecast probabilístico & IA: La forecast de demanda de Blue Yonder (la parte de Blue Yonder proveniente de Alemania, a menudo denominada Cognitive Demand Planning) se basa fuertemente en AI/ML. Han publicado mejoras que indican aproximadamente un 12% más de precisión en el forecast utilizando ML frente a métodos tradicionales ⁷³. Su enfoque ingiere una miríada de datos – incluyendo el clima, eventos, señales online – para predecir la demanda. Aunque probablemente generan un único número de forecast para uso operativo, los modelos subyacentes pueden producir salidas probabilísticas. De hecho, la solución original de Blue Yonder (Alemania) era conocida por la selección automatizada de modelos (al estilo de un enfoque AutoML) y podía generar intervalos de confianza. No está claro si el sistema de producción expone distribuciones, pero sí enfatizan la planificación de escenarios y simulación. Por ejemplo, permiten que los planificadores simulen múltiples escenarios de demanda, lo que implica una distribución de resultados tras bambalinas ⁷⁴. Blue Yonder también ha mencionado la simulación “Monte Carlo” en algunos whitepapers para la planificación de supply. Dada la amplia experiencia de sus data scientists, es seguro decir que la forecast de Blue Yonder es al menos consciente de lo estocástico, incluso si no proporciona un PDF explícito para cada artículo. Se refieren a ella como forecast “Cognitive” o de “Machine Learning”. Además, adquirieron capacidades de forecast de pedidos de clientes de su legado (como las técnicas de i2 para tiempos de entrega probabilísticos, entre otros). Sin embargo, críticas como la de Lokad señalaron que las piezas open source que Blue Yonder poseía (tsfresh para extracción de características, Vikos – que podría ser una biblioteca de forecast – y PyDSE) indican una dependencia de técnicas relativamente convencionales ⁴³. tsfresh se utiliza para generar características para series temporales (como la extracción de métricas estacionales) – es útil, pero no es una IA revolucionaria por sí sola. La mención de ARMA y regresión lineal implica que parte del forecast central podría seguir utilizando modelos estadísticos mejorados con características de ML. En otras palabras, la “IA” de Blue Yonder podría ser a menudo un suavizado exponencial bien afinado + una regresión para factores causales. Eso no es necesariamente malo – son métodos probados, pero se quedan cortos frente a los enfoques de deep learning más novedosos que existen. Blue Yonder sin duda comercializa fuertemente su IA: términos como “cognitive,” “machine learning,” “AI/ML engines” aparecen en sus materiales ⁷³ ⁷⁵. La vaguedad acerca de cómo exactamente lo hacen (quizá por secretos comerciales) ha generado escepticismo sobre el “AI-washing”. Pero se sabe que cuentan con un gran talento (el equipo alemán tenía una sólida formación académica), por lo que probablemente su tecnología sea sólida, aunque no espectacular. Blue Yonder también utiliza IA en otras áreas: por ejemplo, su optimización de precios utiliza machine learning para estimar la elasticidad del precio y los efectos cruzados; su planificación de supply utiliza heurísticas y posiblemente ML para ajustar parámetros; su micro-fulfillment emplea IA para decidir desde qué ubicación cumplir un pedido, etc. También impulsan la “Luminate Control Tower” que aprovecha la IA para predecir interrupciones y prescribir acciones. Muchas de estas soluciones se basan en clasificación o predicción mediante ML en segundo plano. ¿Son probabilísticas? Posiblemente generen puntuaciones de riesgo o probabilidades de eventos. Las piezas de marketing de Blue Yonder hablan de “AI-enabled optimization engines ingest huge data… achieving cognitive automation” ⁷⁶ ⁷⁷, que suenan bien pero no son específicas. Me parece justo decir que Blue Yonder utiliza mucha IA, pero debido a la amplitud de la misma, algunas partes pueden no ser de última generación. Por ejemplo, un usuario en Reddit comentó en una ocasión que la forecast de JDA (ahora BY) no era única y que muchos seguían utilizando lógicas más antiguas con ajuste de parámetros. Las patentes e investigaciones de Blue Yonder podrían arrojar más luz (tienen algunas patentes sobre forecast de múltiples escenarios ⁷⁸). Dada la evidencia: Blue Yonder definitivamente ha incorporado AI/ML (especialmente después de adquirir Blue Yonder GmbH) a su forecast y optimización. Produce forecasts más precisos y presumiblemente capacidades de escenarios. Pero la visión escéptica de Lokad, de que bajo el capó podría haber muchos modelos lineales empaquetados como IA, sugiere la necesidad de precaución. Calificaremos a Blue Yonder con altos puntajes en cuanto a contar con características de AI/ML, aunque cabe notar que algunos competidores que comenzaron desde cero con ML (como RELEX o Lokad) podrían tener ventaja en ciertas técnicas debido a tener menos legado. Blue Yonder está invirtiendo activamente en lo último (por ejemplo, mencionan que están explorando Generative AI para asistentes de planificación ⁷⁹). Así que están tratando de mantenerse a la vanguardia.

Toma de Decisiones Económicas: Las soluciones de Blue Yonder, particularmente en precios y supply chain, consideran explícitamente la rentabilidad y los costos. Para los precios, Blue Yonder (a través de lo que originalmente fue Revionics o sus propias) cuenta con funciones objetivo como maximizar el margen, los ingresos o alcanzar un objetivo financiero. Su optimización de precios no solo sigue reglas – utiliza la elasticidad para elegir precios que maximicen una métrica determinada respetando restricciones (como índices de precios competitivos o posiciones de inventario). Así, es, en esencia, una optimización económica. En la optimización de inventario, Blue Yonder (o el legado de JDA/i2) tenía módulos como Multi-Echelon Inventory Optimization (MEIO) que, efectivamente, trataban de minimizar los costos totales (costos de mantenimiento, costos por pedidos pendientes) para un nivel de servicio dado o maximizar el servicio dentro de un presupuesto – una optimización clásica de coste-beneficio. En la práctica, algunos clientes utilizaban simplemente la orientación hacia un nivel de servicio, pero la capacidad para la optimización basada en costos estaba presente. Las herramientas S&OP / IBP de Blue Yonder permiten la integración de planes financieros y restricciones, lo que significa que el proceso de planificación puede optimizarse en torno al margen o a objetivos de beneficio (por ejemplo, alcanzar una meta de ingresos al costo mínimo, etc.). Otra área es la asignación: la herramienta de asignación de Blue Yonder se puede configurar para distribuir productos a las tiendas de manera que se maximice el sell-through proyectado (y, por lo tanto, el beneficio) en lugar de una asignación uniforme. Su planificación de surtido puede incorporar métricas de contribución de beneficios por categoría para decidir qué productos mantener o descartar. Debido a que históricamente Blue Yonder atendía a minoristas muy orientados al margen (como los del sector moda que utilizan su optimización de markdown para maximizar el retorno bruto del margen), tuvieron que incorporar una lógica económica. La crítica por vaguedad ⁴³ podría insinuar que la IA de Blue Yonder no articula claramente la economía (por ejemplo, que no es transparente cuánta rentabilidad implica un determinado forecast), pero sus módulos de optimización definitivamente utilizan parámetros económicos (elasticidad de precios, costos, etc.). Por ejemplo, la solución de optimización de inventario de Blue Yonder afirma “eliminar el exceso de inventario y reducir los costos de obsolescencia mientras se mantiene un alto nivel de servicio” ⁸⁰ – lo cual es, esencialmente, un equilibrio entre el costo de obsolescencia y el nivel de servicio, un compromiso económico. Su optimización de promoción considera el impulso promocional vs la inversión en margen para recomendar cuáles promociones son las más rentables. En términos de costo de oportunidad, Blue Yonder podría no expresar esto de forma explícita, pero sus planificadores pueden derivarlo mediante escenarios: por ejemplo, si no se almacena el artículo A, la pérdida de beneficio representa un costo de oportunidad. Las herramientas de Blue Yonder podrían simular ese escenario. Las críticas que se han hecho, en esencia, dicen: Blue Yonder afirma contar con IA y tecnologías afines, pero podría estar utilizando gran parte de la regresión lineal (la cual, por lo general, ya incorpora factores de costo). Así que creo que Blue Yonder funciona bien en el aspecto económico. Una posible debilidad es si partes antiguas del sistema aún utilizan heurísticas basadas en reglas empíricas (algunos de los antiguos sistemas de reabastecimiento de JDA estaban más basados en reglas min/max). Pero lo más probable es que esos hayan sido reemplazados por enfoques optimizados. Con el impulso de Blue Yonder hacia el “autonomous planning”, a menudo mencionan métricas financieras como un impulsor clave. Un artículo de BusinessWire cita a un cliente que usa la tecnología avanzada de BY: “By leveraging AI/ML, we are enhancing forecast accuracy and building a future-ready supply chain that improves our financial performance” ⁸¹. Así, la economía está en el centro. Dicho esto, implementar Blue Yonder para aprovechar al máximo estas capacidades puede ser complejo – algunos clientes pueden no utilizar todas las funciones de optimización económica debido a la complejidad, optando por una operación más manual. Pero la capacidad está presente. Otorgamos a Blue Yonder altas calificaciones por contar con módulos impulsados económicamente (precios, markdown, MEIO), aunque quizá se vea ligeramente afectado si algunos de esos módulos no están completamente integrados o son fáciles de usar, lo que podría conducir a un uso subóptimo.

Escalabilidad y Eficiencia en Costos: Las soluciones heredadas on-premises de Blue Yonder eran conocidas por ser pesadas – requiriendo gran potencia de servidor y memoria, especialmente la antigua huella de JDA. Sin embargo, en los últimos años, Blue Yonder se ha trasladado a una plataforma de microservicios cloud-native en Microsoft Azure, lo que debería mejorar la escalabilidad. La nota MQ de Gartner decía que las fortalezas de Blue Yonder incluyen “arquitectura de microservicios integral” y que ofrece planificación multiempresa de extremo a extremo ⁷¹. Los microservicios implican que dividieron las aplicaciones monolíticas en servicios más pequeños que pueden escalar de forma independiente. Esto probablemente mejora el rendimiento (por ejemplo, escalar el servicio de demand forecasting para muchos artículos mientras se escala por separado el servicio de supply planning). El entorno de Microsoft Azure también permite elasticidad y quizás un menor costo de escala que on-prem, porque se puede activar una gran capacidad de cómputo para un batch y luego desactivarla. Sin embargo, Blue Yonder sigue siendo una de las soluciones más caras y de nivel empresarial. Ejecutar todos esos módulos avanzados significa procesar una enorme cantidad de datos (especialmente si se usa alta granularidad). Ha habido quejas históricas sobre largos tiempos de ejecución en algunos procesos de JDA o dificultades para manejar volúmenes de datos extremadamente grandes rápidamente. La revisión de microservicios tuvo como objetivo arreglar gran parte de ello. Ahora, Blue Yonder puede presumir de reforecasting casi en tiempo real para demand sensing y replans frecuentes en su control tower. Otro aspecto es el manejo de datos: la adopción por parte de Blue Yonder de un cloud data lake subyacente podría mejorar la forma en que se almacenan y acceden a los datos en comparación con los modelos relacionales antiguos. Por otro lado, tener una suite tan amplia implica una gran sobrecarga de integración; la plataforma de Blue Yonder intenta mitigar eso, pero probablemente sigue siendo pesada. En términos de eficiencia en costos, Blue Yonder típicamente se dirige a grandes empresas con presupuestos importantes, por lo que generalmente no se elige por ahorro de costos – se elige por capacidad. Podría requerirse un gasto considerable en Azure para el cliente (o Blue Yonder lo incorpora en las tarifas SaaS). Si un minorista intenta implementar todos los módulos de BY, el proyecto y los costos continuos pueden ser muy altos. Así que la eficiencia en costos no es el punto de venta de BY – lo es la completitud. Otro punto relevante: los módulos antiguos de Blue Yonder a menudo se ejecutaban en memoria (JDA tenía un OLAP en memoria para las cifras de planificación). Ese concepto en memoria podría significar un alto uso de memoria. Pero con microservicios, quizás utilicen los pools de memoria escalables de Azure de manera más eficiente. La crítica competitiva de Lokad dijo específicamente “enterprise software isn’t miscible through M&A, under BY lies a haphazard collection… claims are vague, open-source hints at older tech” ⁷². Aunque esto era más sobre integración y hype, apunta indirectamente a ineficiencias – una “colección improvisada” a menudo implica que cada parte puede tener su propia infraestructura, sin estar integrada, lo que conduce a una mayor huella total. Sospechamos que Blue Yonder ha mejorado la integración con Luminate, pero puede que aún tenga redundancias. Por ejemplo, el módulo de precios podría tener su propio almacén de datos separado del almacén de datos de forecast a menos que se unifique – algo que Luminate pretende unificar, pero estas cosas toman tiempo. Resumiendo: Escalabilidad – Blue Yonder puede escalar hasta los minoristas más grandes (muchos de los 10 minoristas globales principales utilizan algún componente de Blue Yonder), lo que demuestra que puede manejar grandes volúmenes de datos. El rendimiento puede que no sea extremadamente rápido desde el principio, pero es viable con ajustes y potencia en la nube. Eficiencia en costos – probablemente sea menor; tiende a ser intensivo en recursos y costoso. La transición a SaaS podría reducir los costos de IT on-prem para los clientes, pero esos costos se convierten en tarifas de suscripción. Además, como un gran proveedor, BY puede cobrar una prima. Así que, si el costo es un criterio, Blue Yonder a menudo pierde frente a soluciones más esbeltas. Si el criterio es la potencia y amplitud pura, BY está bien. Los calificaremos como moderados en escalabilidad (porque sí escalan, pero potencialmente a un alto costo y con gran complejidad).

Manejo de Factores Complejos en el Retail: Las soluciones de Blue Yonder manejan explícitamente casi todos los factores complejos que se puedan imaginar:

Cannibalización y Halo: Su demand forecasting ML tiene la capacidad de considerar influencias entre productos (probablemente incorporan características que indican si los sustitutos están en promoción, etc.). Además, su herramienta de promotion optimization tiene en cuenta la cannibalización – por ejemplo, al recomendar promociones, mide si una promoción en el Producto A canibalizará las ventas del Producto B y calcula el net lift. Blue Yonder tenía un módulo llamado Promotion Effectiveness que hacía algo similar. Adicionalmente, su analítica de category management suele evaluar los impactos de categoría de los cambios en precios (para que no subas el precio de un artículo y pierdas margen en los complementarios). Notablemente, el estratega de Blue Yonder podría establecer elasticidades que incluyan efectos cruzados. En el artículo de Business Insider, Revionics (ahora separado bajo Aptos) habló de usar AI para simular si bajar el precio de la mezcla para pasteles incrementa las ventas de huevos ⁸², lo cual es un escenario de efecto halo. La solución de precios de Blue Yonder es similar a la de Revionics ya que compiten, por lo que presuntamente BY también puede simular tales resultados entre productos. Además, el promotion forecasting de Blue Yonder específicamente puede incorporar factores de cannibalización, ya que es estándar en la industria.
Sustitución (efectos de faltante de stock): La planificación de demanda de Blue Yonder puede consumir información de positional availability; si un artículo no está disponible, la lógica de forecast puede atribuir la caída a la falta de disponibilidad en lugar de a una disminución en la demanda. El ML alemán de Blue Yonder era conocido por tener en cuenta las tasas de stock para no aprender ingenuamente una menor demanda cuando simplemente estaba faltante de stock. Adicionalmente, la planificación de pedidos de Blue Yonder puede incluir substitution rules – por ejemplo, si el artículo X no está disponible, podrían aumentar proactivamente el supply del artículo sustituto Y (algunos usuarios avanzados lo hacen).
Caducidad/productos perecederos: Blue Yonder tiene una gran clientela en el sector de abarrotes, por lo que desarrollaron funciones para productos perecederos. Por ejemplo, su sistema de replenishment puede considerar la shelf-life – asegurándose de no sobreordenar hasta el punto de que el producto caduque. También pueden optimizar la producción en tienda (por ejemplo, para lo fresco, tienen soluciones en workforce mgmt integradas para gestionar la programación de la producción fresca – indirectamente sobre la reducción de desperdicios). El forecasting de Blue Yonder permite una granularidad diaria, lo cual es crucial para artículos frescos, y utiliza la day-of-week seasonality, etc. Cuentan con referencias (como la de Knauf en BusinessWire para supply chain, y algunas referencias del sector de abarrotes) en las que se menciona “usando BY, se redujo el spoilage, etc.” – aunque RELEX dio un ejemplo para eso. Es probable que Blue Yonder tenga historias de éxito similares (recuerdo una con 7-Eleven usando BY para forecast de alimentos frescos).
Planogramas y restricciones de espacio: La solución de category management de Blue Yonder es básicamente el estándar de la industria para planogramming y planificación de piso. Alimenta directamente la planificación de surtido y replenishment al proporcionar datos sobre cuánto espacio tiene cada producto en cada tienda (para que el supply planning sepa el stock máximo de estantería). Los sistemas de Blue Yonder definitivamente usan esto – por ejemplo, si un planograma asigna 2 facings a un artículo, el sistema no enviará más de lo que cabe. Además, BY puede optimizar en qué tiendas se introduce un nuevo artículo basado en el espacio y la demanda local (por ejemplo, si una estantería no puede albergar más SKUs, podría no incluirlo en el surtido).
Factores de fuerza laboral y ejecución: Ligeramente tangencial, pero BY también tiene en cuenta cómo se puede ejecutar un plan – por ejemplo, programando la mano de obra para descargar envíos si se envía inventario extra para una promoción, etc. Esto se refleja en lo integrado de su enfoque para las operaciones minoristas.
Omni-channel: Las capacidades más nuevas de Blue Yonder también consideran compensaciones en fulfillment (ship-from-store vs DC), lo cual no se pidió directamente, pero es otra complejidad que optimizan (costo vs velocidad, etc. – fuera del alcance de esta pregunta).
Clima y factores externos: Los manejan a través de ML en demand forecasting, lo que constituye un “factor complejo” en una demanda volátil. En esencia, Blue Yonder tiene una solución o funcionalidad para casi cada escenario complicado en el retail. El desafío es que realmente hay que implementar y ajustar esas funciones. Históricamente, a algunos minoristas les costó implementar modelos avanzados de cannibalización en JDA porque era complejo y requería soporte de data science. Ahora, con AI automation, BY intenta hacerlo internamente. Probablemente funcione, pero el usuario puede que no lo vea o controle fácilmente (el escenario de “caja negra cognitiva”). Sin embargo, es más seguro asumir que BY cubre estas complejidades porque su competencia lo hace y necesitaban ponerse al día. De hecho, Blue Yonder tiene una función llamada Demand Transference analysis (del antiguo JDA), que medía explícitamente la cannibalización dentro de las categorías para ayudar en las decisiones de surtido – es exactamente cuantificar cómo la demanda se transfiere de un producto a otro si uno está ausente o en promoción. Así que sí, cuentan con ese concepto. Considerando todo esto, Blue Yonder probablemente obtiene la puntuación más alta en el abordaje de factores complejos, simplemente porque durante décadas, cualquier problema que un minorista encontraba, JDA/Blue Yonder añadía funcionalidad para solucionarlo (o adquiría una empresa que lo hiciera). La leve salvedad: a veces, los enfoques antiguos pueden ser menos automatizados (necesitando configuración manual de relaciones, etc.), mientras que los proveedores más nuevos aprenden de forma automática. Blue Yonder ahora intenta auto-aprender con AI, pero nuevamente, confiar en ello requiere fe, ya que no siempre revelan los detalles. La crítica de la competencia por usar métodos antiguos ⁴³ sugiere que tal vez su modelado de cannibalización use regresión lineal (lo cual aún puede capturarlo decente si se hace bien). No es necesariamente una falla, simplemente no es sofisticado. Evaluaremos a BY muy alto en este criterio, con la leve nota de que puede ser complejo de configurar.

Automatización: La visión de Blue Yonder de “Autonomous Supply Chain” y “Cognitive Planning” es esencialmente sobre automatización. Publicitan que su Luminate Planning puede ajustar automáticamente los planes con poca intervención humana, y que sus algoritmos pueden autoajustarse. Por ejemplo, el “algorithmic baseline forecasting” de Blue Yonder reduce significativamente la carga de trabajo de los forecast humanos – los planificadores se centran únicamente en las excepciones (como nuevos productos o grandes eventos). Muchos clientes de BY utilizan auto-replenishment: el sistema genera órdenes que se envían directamente a ejecución, a menos que sean marcadas. El sistema Fulfillment de BY tenía características como “Adaptive, learning safety stocks”, lo que significaba menos ajustes manuales de parámetros. En precios, Blue Yonder (al igual que otras herramientas de precios) puede ejecutar actualizaciones autónomas de precios dentro de las reglas – por ejemplo, reducciones automáticas de precios cada lunes basadas en el sell-through actual versus el plan. Sospecho que algunos clientes minoristas de BY permiten que el sistema tome ciertas acciones de precios de forma automática (especialmente markdowns, que pueden ser localizados y frecuentes – demasiados para hacerlo manualmente). Incluso, el Luminate Control Tower de Blue Yonder puede resolver automáticamente ciertas excepciones (por ejemplo, si un proveedor llega tarde, expedir automáticamente desde otra fuente) – eso es automatización en ejecución. Sin embargo, históricamente Blue Yonder también tenía fama de estar centrado en los planificadores hasta cierto punto: proporciona excelentes recomendaciones, pero muchas empresas aún tienen muchos planificadores ajustándolas (algunos porque el sistema era complejo o no confiaban completamente en él). La transformación hacia lo “autonomous” aún está en progreso. Las publicaciones del propio blog de Blue Yonder sobre aumentar la precisión del forecast se centran en dejar que la AI haga el trabajo pesado y limitar las intervenciones manuales ⁸³, lo que implica que fomentan la automatización. Tienen un concepto de exceptions/alerts que impulsa un estilo de “gestión por excepciones” – una marca de la automatización (intervenir solo cuando es necesario). Con la acquisición de Panasonic de Blue Yonder en 2021, también se hace énfasis en conectar con IoT y automatizar incluso decisiones físicas (como ajustar los estantes de la tienda mediante robótica basado en cambios del plan – ideas prospectivas, pero aún en etapa conceptual). Por otro lado, debido a que las herramientas de BY están tan llenas de funciones, algunos usuarios pueden volverse excesivamente dependientes de la configuración manual (como ajustar docenas de parámetros, ejecutar análisis what-if manualmente, etc.), lo que puede dificultar una verdadera automatización sin intervención. No cabe duda de que Blue Yonder puede habilitar una alta automatización, pero si una implementación dada lo logra es variable. Recuerdo haber leído estudios de caso en los que minoristas lograron que Blue Yonder generara automáticamente el 90% de sus órdenes, similar a las referencias de ToolsGroup. Así que, probablemente, el uso de las mejores prácticas logra ese objetivo. Dado el fuerte marketing actual de “autonomous” de Blue Yonder, creemos que están impulsando nuevas funciones para aumentar la automatización (como ML model autopilot – cambiando automáticamente los algoritmos cuando la tendencia cambia; o scenario advisor – recomendando el mejor escenario). Incluso cuentan con un asistente digital (quizás consultas de planificación activadas por voz) – no es automatización per se, pero reduce el análisis manual. Así que sí, BY está orientado a la automatización, aunque quizás históricamente sus usuarios lo hayan utilizado de forma limitada debido a problemas de confianza o complejidad. Los calificaremos alto, pero no tan perfectos como algunos proveedores ágiles más pequeños, simplemente porque implementar BY hasta el punto en que se pueda confiar sin supervisión puede tomar más tiempo. Pero una vez hecho, debería funcionar. El sitio web de Panasonic lo denomina “Realization of the Autonomous Supply Chain™ with Blue Yonder” ⁸⁴ – ¡están registrando la marca Autonomous Supply Chain, así que lo dicen en serio! Para ser escépticos: señalaremos que, hasta ahora, la planificación verdaderamente totalmente autónoma es rara en la industria, incluso con BY – la supervisión humana persiste. Pero BY puede reducir significativamente la carga de trabajo humano.

Integración Tecnológica: Blue Yonder es el caso clásico de una plataforma construida mediante muchas adquisiciones (desde los 1980s hasta los 2010s). Sin embargo, desde alrededor de 2015 han invertido en unificarla. La Luminate Platform es su respuesta: microservicios en una cloud común, modelo de datos común de forma parcial (tienen Luminate Data Hub), y un estilo de UI compartido. Han logrado progresos – por ejemplo, los módulos de demand forecasting y reabastecimiento ahora comparten la misma UI y datos sin inconvenientes (en comparación con el antiguo JDA donde Demand y Fulfillment eran apps separadas que necesitaban integración por lotes). La arquitectura de microservicios significa que nuevas capacidades pueden ser entregadas y conectadas sin cambios monolíticos. Pero seamos claros: internamente, es probable que algunos módulos aún ejecuten su código legacy (simplemente alojado en cloud). Eso significa que la integración es a nivel de interfaz, no que hayan reescrito todo en una única base de código (lo cual sería irrealizable en poco tiempo). Expusieron APIs del código antiguo como microservicios y las orquestan. Funciona en buen grado según Gartner, que la llamó “comprehensive microservices architecture” ⁷¹, lo cual es un cumplido. Otro punto a favor: Blue Yonder ha unificado en gran medida su UI (la interfaz Luminate Experience). En teoría, un usuario puede navegar desde una pantalla de planificación de demanda hasta una pantalla de inventario dentro de un mismo portal. Existe el concepto de Luminate Planning Workbench que intenta reunir múltiples funciones para un planificador. Aún así, críticos como Lokad dicen “enterprise software isn’t miscible via M&A” ⁷² – implicando que no se pueden fusionar fácilmente productos adquiridos. Blue Yonder lo está intentando, pero quizá queden algunas grietas: por ejemplo, la solución de pricing (originalmente un producto separado) puede que aún no se sienta completamente como la planificación de demanda en UI y requiera una configuración separada. La integración de datos puede ser un problema: ¿se alimentan automáticamente los demand forecasting a los modelos del módulo de price optimization? ¿O hay que exportarlos? Es probable que Blue Yonder ya haya integrado eso, aunque no se sabe con certeza. La nota “haphazard collection of products, most of them dated” ⁷² es dura – quizá refiriéndose a ciertos módulos antiguos, como la planificación de merchandising legacy de JDA o motores de optimización más viejos que no han sido actualizados. Además, “claims are vague with little substance” ⁸⁵ sugiere que, en ocasiones, BY dice que es unified AI, pero quizá solo sean piezas integradas de forma laxa. Aun así, para crédito de Blue Yonder, replatformearon más de lo que muchos otros hicieron; por ejemplo, containerizaron los algoritmos antiguos, construyeron UIs modernas y los conectaron. Otro ángulo de integración: Blue Yonder cubre la planificación hasta la ejecución en una misma compañía (WMS, TMS para ejecución y herramientas de planificación). También han estado integrando estos (la planificación de inventario puede ver el inventory de WMS casi en tiempo real, etc.). Así que, en teoría, podrías ejecutar tu supply chain de extremo a extremo con la tecnología de Blue Yonder, lo cual representa una integración que va más allá de la planificación – un gran plus si se logra. Históricamente, también estaban en silos (legado JDA vs RedPrairie heritage). Tienen algo llamado Luminate Control Tower que superpone y conecta datos de planificación y ejecución en una sola vista. Así que hay progreso en la integración. Considerando todo, Blue Yonder ha avanzado mucho pero aún probablemente no es tan ágilmente integrado como un producto desarrollado internamente desde cero. La nota de código abierto sobre el uso de proyectos como tsfresh indica que están intentando unificar sobre bibliotecas comunes donde es posible (lo cual es una buena práctica de integración). Sin embargo, con tantos productos, resulta difícil unificar cada pieza completamente. El riesgo es que algunos clientes puedan implementar efectivamente los módulos de Blue Yonder pero no integrarlos adecuadamente – la culpa podría recaer en la implementación en lugar de en la capacidad del software. Pero la arquitectura ahora permite la integración; depende del uso. Evaluaremos a Blue Yonder con una integración de moderada a alta: definitivamente una suite históricamente Frankenstein que se sometió a una cirugía para volverse más unificada – parcialmente exitosa, pero aún se nota que algunas partes son de un estilo más antiguo. La complejidad se mantiene alta. Por ejemplo, para implementar la suite completa de BY, podría requerirse múltiples equipos de expertos, ya que cada módulo tiene mucha profundidad. Eso indica que no es un producto completamente “cohesivo” en la práctica, sino más bien “una familia de productos bajo un mismo paraguas de plataforma.” Mientras tanto, ToolsGroup o Lokad se aproximan a ser un producto único que resuelve múltiples áreas (menos funciones, pero más integrado por diseño). Así que la integración de Blue Yonder es mejor que el revoltijo de SAP, aunque probablemente se quede atrás frente a soluciones singulares.

Escepticismo ante el Hype: La estrategia de marketing de Blue Yonder utiliza muchas palabras de moda: “Cognitive”, “Autonomous”, “AI/ML”, “End-to-End”, etc. Algunas afirmaciones carecen de detalles (como “12% forecast improvement” – ¿mejorado desde qué línea base? O “powered by AI” sin ningún detalle sobre el método). Presentan una narrativa vistosa de un “cerebro digital” similar a o9, y a veces se percibe una visibilidad limitada de cómo funciona. La crítica dijo “claims are vague with little or no substance… open source projects hint at pre-2000 approaches” ⁴³, acusando básicamente a Blue Yonder de AI-washing (vender vino viejo en botellas nuevas). De hecho, Blue Yonder se rebrandearon rápidamente tras la adquisición como un “AI pioneer”, lo que levantó cejas ya que JDA no era conocido por eso anteriormente. Dicho esto, Blue Yonder sí cuenta con tecnología real de AI (proveniente del equipo adquirido), pero quizá no tan avanzada en comparación con los demás como insinúan. Por ejemplo, llamar a su forecast “cognitive” puede exagerarlo – es avanzado, sí, pero muchos otros realizan algo similar con ML forecasting. El término “cognitive” implica un razonamiento casi humano, lo que es puro hype. Además, “autonomous supply chain” – una meta admirable, pero cualquier sistema de este tipo aún necesita gobernanza humana. A veces utilizan términos marcados, como “Autonomous Supply Chain™”, lo cual es una estrategia de marketing. Otra área de hype: Blue Yonder promociona “demand sensing” – un concepto que han adoptado (algunas de sus soluciones, como el forecasting a corto plazo, son básicamente demand sensing). Como señaló Lokad, demand sensing a menudo resulta ser hype si no se implementa correctamente. Es probable que Blue Yonder tenga un método (como usar las ventas de la semana pasada con mayor ponderación para ajustar los forecast a corto plazo), pero si realmente capta señales externas o simplemente aplica un suavizado reactivo es una pregunta abierta. Si lo exageran como “AI sensing demand shifts real-time from social media” o similar, se podría cuestionar su practicidad. También está el hype de integración: afirman tener una plataforma unificada, pero como se ha discutido, entre bastidores no es completamente uniforme – el marketing podría omitir la complejidad de la integración. Por otro lado, Blue Yonder cuenta con numerosos estudios de caso y referencias reales. Generalmente no inventan resultados – tienen grandes clientes que comparten públicamente éxitos (incremento en fill rate, revenue, etc.), lo cual es creíble. Además, Blue Yonder tiende a no revelar demasiados detalles técnicos, lo cual puede dar la impresión de que se esconden detrás de buzzwords. Para quien busca la verdad, los materiales de BY pueden resultar frustrantes dado que suelen hablar sobre resultados y capacidades de alto nivel en lugar de decir “usamos el algoritmo X, Y, Z”. Pero los materiales de ventas enterprise rara vez abordan los algoritmos. Esto no es exclusivo de BY. Al menos, un análisis competitivo de Lokad los destacó, lo que significa que, entre sus pares, Blue Yonder fue percibido como particularmente recargado de buzzwords sin suficiente ciencia nueva detrás ⁴³. Dado que queremos penalizar afirmaciones vagas y exceso de hype, Blue Yonder recibe cierta penalización: definitivamente han capitalizado muchas palabras de moda en los últimos años. Los comunicados de prensa de Panasonic y los blogs de BY están llenos de jerga (AI/ML, digital twin (quizá menos, pues prefieren “digital edge”, etc.), cognitive, autonomous). Sin una validación técnica, un escéptico debería cuestionar parte de ello. Aun así, Blue Yonder tiene tecnología genuina, aunque quizás no sea tan revolucionaria como su marketing sugiere. Le daremos una puntuación de honestidad ante el hype de media a baja – hacen mucho hype. Como evidencia, ese PDF de Lokad situó a Blue Yonder en el duodécimo lugar de 14 y destacó específicamente su hype y fundamentos legacy ⁷². Es una fuente parcial (Lokad es competidor), pero resuena con la precaución de no tomar todo el marketing de BY al pie de la letra. Otro ejemplo: Blue Yonder podría afirmar “plug-and-play SaaS – quick time to value”, pero muchos clientes experimentan implementaciones de varios años – existe así una brecha entre el marketing y la realidad en la facilidad de implementación. Eso es un hype relacionado con la integración o la facilidad de uso. En resumen, el marketing de Blue Yonder es pulido y a menudo optimista, por lo que se justifica un escepticismo sano.

Resumen: Blue Yonder es una suite de optimización minorista rica en funcionalidades que abarca inventario, pricing, y planificación de assortment (además de aspectos de ejecución) – cubriendo esencialmente todas las facetas de la optimización minorista. Ha sido modernizada con AI/ML (por ejemplo, “cognitive” demand forecasts ²⁷) y una plataforma cloud, y es capaz de optimizar conjuntamente decisiones a través de áreas tradicionalmente silos (decisiones de pricing que alimentan los planes de inventario y viceversa) ²⁷. Las herramientas de Blue Yonder consideran explícitamente la rentabilidad y el costo en las decisiones – desde la optimización de pricing que equilibra margen vs volume hasta la optimización de inventario que equilibra el servicio vs el holding cost ⁸⁰. La solución puede modelar dinámicas minoristas complejas como cannibalization, halo effects, y shelf-life constraints dentro de sus procesos de forecasting y planificación, gracias a sus avanzados algoritmos y décadas de conocimiento en data science aplicado al retail. Por ejemplo, utiliza machine learning para identificar efectos de sustitución de productos y canibalización promocional, de modo que los forecasts y reabastecimientos se ajusten en consecuencia ⁸ ⁹. Con su reciente re-arquitectura basada en microservicios, Blue Yonder mejoró la integración de sus módulos, que antes eran dispares, ofreciendo una plataforma Luminate más unificada con datos comunes y una interfaz de usuario compartida ⁷¹. Esto permite mayores grados de automatización: muchos clientes de Blue Yonder permiten que el sistema genere automáticamente forecasts, órdenes e incluso recomendaciones de pricing, interviniendo solo en casos excepcionales. Blue Yonder promociona fuertemente una “Autonomous Supply Chain”, y aunque la autonomía completa es un camino largo, sus soluciones sí permiten decisiones automatizadas y basadas en datos a escala (un gran usuario reportó que los planificadores gestionan por excepción mientras el sistema maneja de forma autónoma el 95% de los replenishments de sku-store).

Sin embargo, se requiere un ojo escéptico respecto a las afirmaciones de Blue Yonder. El legado de adquisiciones de la suite significa que algunos componentes ejecutan algoritmos legacy bajo el capó ⁷². La cohesión de la plataforma, a pesar de grandes mejoras, puede no ser tan fluida como la de una única base de código desarrollada desde cero – la implementación de todas sus piezas puede resultar compleja y requerir muchos recursos. Además, es notable el hype de marketing de Blue Yonder: términos como “cognitive” y “autonomous” se utilizan de forma liberal, a veces superando la realidad de lo que el software realmente ofrece ⁴³. Análisis independientes han señalado que, detrás de las palabras de moda, Blue Yonder a menudo emplea técnicas analíticas bien establecidas (incluso más antiguas) ⁴³ – efectivas pero no dotadas de una AI mágica. Además, el costo y la complejidad de la solución de Blue Yonder pueden ser elevados – podría requerirse una inversión sustancial en tiempo, dinero y personal calificado para aprovechar todas sus capacidades, lo que atenúa la narrativa de “plug-and-play”. En resumen, Blue Yonder es extremadamente capaz – indudablemente un referente en riqueza funcional y experiencia en retail – y continúa evolucionando con AI moderna y tecnología cloud. Sin duda, puede ofrecer una optimización de última generación si se implementa y utiliza en su totalidad. Pero se debe atravesar la niebla de buzzwords y evaluar cuidadosamente cómo se respalda cada afirmación. Donde Blue Yonder demuestra un valor claro (como mejoras comprobadas en la precisión forecast, reducción medible de desperdicio en productos frescos o aumento en sell-through mediante optimized pricing), lo reconocemos como una solución de primera categoría. Donde recurre a un marketing vago o minimiza las dificultades de integración, permanecemos cautelosos.

En nuestro ranking, Blue Yonder sigue siendo un proveedor líder en optimización minorista debido a su amplitud e innovación continua ⁷¹, pero lo penalizamos en cierta medida por su legacy technical debt y marketing overreach. Para los grandes minoristas que buscan un sistema integral, de extremo a extremo, y están dispuestos a invertir en él, Blue Yonder suele ser un competidor o incluso el estándar. Para quienes priorizan la agilidad, la eficiencia en costos o la simplicidad, el enfoque expansivo de Blue Yonder podría resultar pesado.

Fuentes: Plataforma Luminate de Blue Yonder basada en microservicios y sus capacidades ⁷¹; declaración sobre la vinculación del impacto de pricing con los niveles de inventario ²⁷; análisis crítico de las afirmaciones de AI de BY y sus fundamentos legacy ⁷² ⁴³.

6. SAP (SAP IBP & Retail) – Suite Incumbente Modernizada, Aún Rezagada (Legacy Baggage Alert)

SAP, un titán en software empresarial, ofrece capacidades de optimización minorista a través de su SAP Integrated Business Planning (IBP) para supply chain y la suite SAP for Retail (que incluye herramientas de planificación de merchandising y pricing provenientes de adquisiciones pasadas). Las soluciones de SAP abarcan demand forecasting, inventory and supply planning, assortment and merchandise financial planning, y markdown optimization. Durante la última década, SAP ha pasado de sus antiguos módulos minoristas legacy, como APO (Advanced Planner & Optimizer) y otros, a una plataforma IBP basada en cloud más moderna. Sin embargo, las ofertas de SAP siguen siendo algo fragmentadas entre el IBP, enfocado en supply chain, y el CAR (Customer Activity Repository) enfocado en retail y las apps Retail. Dado que los criterios de evaluación enfatizan evitar enfoques legacy y una integración estilo Frankenstein, a menudo se señala a SAP como un ejemplo de esos desafíos. Una evaluación sincera en 2021 señaló: “SAP (1972) acquired SAF, KXEN, SmartOps… these apps sit on top of in-house tech (F&R, APO, HANA). Enterprise software isn’t miscible through M&A, and under SAP lies a haphazard collection of products. Complexity is high and the very best integrators – plus a few years – will be needed to achieve success.” ¹¹. Esto subraya la lucha de SAP: muchas piezas integradas de forma laxa, que requieren un gran esfuerzo de implementación. Evaluamos la capacidad de optimización minorista de SAP en un nivel inferior en nuestra lista debido a esta complejidad legacy y al ritmo más lento de innovación en AI, a pesar de ser funcionalmente completa en papel.

Optimización conjunta: Los módulos de SAP históricamente operaban en compartimentos aislados: por ejemplo, SAP Demand Forecasting (parte de F&R) producía forecast que alimentaban al separado SAP Pricing (de la adquisición de Khimetrics), y SAP Assortment Planning (de otro componente). En años recientes, SAP intentó unificar la planificación en IBP – pero IBP cubre principalmente la planificación de demanda, inventario y suministro. Esto significa que la verdadera optimización conjunta (inventario + pricing + assortment en conjunto) no es el fuerte de SAP de serie. Puede que necesites conectar IBP con, por ejemplo, SAP Markdown Optimization (que era un producto separado) de forma personalizada. Ha habido intentos: por ejemplo, SAP’s Unified Demand Forecast (parte de CAR) se suponía que debía proporcionar un único forecast para todos los sistemas aguas abajo (como replenishment y pricing). Si se implementa, al menos alinea pricing e inventario en la misma señal de demanda. Pero la toma de decisiones conjunta real – como incorporar los costos de inventario en la optimización de pricing – probablemente requiera integración personalizada. SAP sí cuenta con una solución SAP Retail Optimization (el antiguo Khimetrics) para pricing que puede considerar restricciones de inventario para markdowns (así que, en ese caso limitado, optimiza conjuntamente el pricing de liquidación con el inventario disponible). Además, los sistemas de merchandising de SAP conectan los planes de ventas con los planes de supply de forma laxa. En general, la arquitectura de SAP no optimiza estos aspectos de forma holística por sí misma; en cambio, pasa los outputs de uno como input para otro. Por ejemplo, IBP podría generar un plan de supply dado una estrategia de pricing asumida; si pricing luego cambia, un planificador tendría que actualizar los escenarios de IBP. No es un feedback automático. SAP IBP está evolucionando con elementos como “Integrated Financial Planning” que vinculan los resultados financieros a los planes de supply (algo de optimización conjunta allí, al menos equilibrando costo y revenue). Pero, comparado con proveedores más nuevos, SAP se queda atrás en la integración sin fisuras entre funciones. La crítica de complejidad ¹¹ sugiere que lograr que todas las piezas de SAP se comuniquen bien entre sí es un proyecto grande. Por lo tanto, calificamos a SAP con una puntuación baja en optimización conjunta. Se puede lograr, pero requiere “the very best integrators – plus a few years” ⁸⁶ (cita directa) – no es un respaldo rotundo.

Forecast probabilístico y AI: SAP IBP incluye un módulo para “Demand” que ofrece algo de análisis predictivo e incluso integración de ML (permiten usar SAP Analytics Cloud o bibliotecas externas de ML para producir forecast que alimentan a IBP). SAP también adquirió KXEN en 2013, una herramienta de minería de datos, presumiblemente para incorporar ML en varios lugares. Pero el forecasting nativo de SAP en IBP continúa en gran medida la tradición de APO (modelos estadísticos como exponential smoothing, Croston, etc.). Introdujeron “Demand Sensing” en IBP, que es un algoritmo (de la adquisición de SmartOps) que utiliza tendencias recientes a corto plazo para ajustar los forecast cercanos en el futuro – un enfoque que algunos consideran una media móvil ponderada glorificada. Es útil, pero no una revolución completa de AI. SAP está integrando más ML ahora – por ejemplo, usan machine learning para new product launch forecasting (emparejando patrones de productos similares). También cuentan con un motor de optimización (de SmartOps) para inventario multi-echelon (que era más estocástico). En general, la innovación de SAP en AI para la planificación se ha quedado atrás respecto a especialistas. En los MQ de planificación de supply chain, Gartner a menudo señala el ML limitado “out-of-the-box” de SAP IBP en comparación con otros. Dependen de socios o de su plataforma Data Intelligence para ML avanzado. Para pricing optimization, la herramienta de SAP (de Khimetrics) sí utilizó algoritmos sofisticados (algo de ML para elasticidad, etc.), pero esa herramienta no ha recibido actualizaciones importantes recientemente y podría no estar estrechamente integrada. Se rumorea que SAP podría estar descontinuando algunos de esos o reemplazándolos por un nuevo servicio basado en AI – no es seguro, pero nada prominente. Como dijo la crítica, SAP tuvo que manejar muchas piezas predictivas adquiridas (SAF se dedicaba a forecasting, SmartOps a la optimización de inventario, KXEN a ML genérico). Es probable que no los haya integrado completamente en un motor de AI coherente. Forecast probabilístico específicamente: el F&R basado en SAF de SAP generaba distribuciones para el lead time y utilizaba niveles de servicio para determinar safety stocks (así que un enfoque algo probabilístico), pero no creo que SAP IBP produzca intrínsecamente distribuciones completas de probabilidad para la demanda; se centra en un número único y otro ajustado por “demand sensing”. Posiblemente proporcionen algunos intervalos de confianza. En términos de hype, SAP utiliza palabras de moda como “predictive analytics” y “machine learning”, pero su AI entregada ha sido moderada. Calificamos a SAP relativamente bajo en forecasting AI avanzado – cubre bien lo básico (era conocido por un forecasting robusto, aunque tradicional), pero no lidera en forecasting probabilístico o ML. Están tratando de ponerse al día permitiendo la integración de AI externa.

Toma de Decisiones Económicas: Las herramientas de planificación de SAP históricamente estaban impulsadas por métricas en lugar de optimizar intrínsecamente el beneficio. APO te permitía establecer objetivos de nivel de servicio o minimizar costos en la planificación de suministro, pero no la maximización directa de beneficios. Las soluciones de pricing retail de SAP (como Markdown Optimization) eran absolutamente económicas – optimizaban el margen o el aumento de revenue a partir de promociones. Esas son soluciones de optimización matemática que maximizan un objetivo (con restricciones como inventario o presupuesto). Así que, en pricing, SAP tenía fortaleza en optimización económica (Khimetrics fue pionero en algoritmos de optimización de precio retail). En inventario, el MEIO de SAP (SmartOps) apuntaba a minimizar el costo total para un objetivo de servicio dado – nuevamente un enfoque económico, aunque con restricción de servicio. SAP IBP incluye “Inventory Optimization” como módulo, que probablemente utiliza ese motor de SmartOps para equilibrar el costo de inventario contra el servicio. Así que ese componente está impulsado inherentemente por la relación entre costo y beneficio. La planificación de assortment en SAP, a menudo realizada en SAP Merchandise Planning, suele ser más heurística (los planificadores simulan resultados financieros, pero no es un algoritmo que elija qué SKUs eliminar basado en ROI, aunque podría resaltar los SKUs de bajo profit para ayudar en las decisiones). Generalmente, SAP permite el seguimiento de métricas financieras – por ejemplo, IBP puede mostrar revenue proyectado, margin en los planes, pero a menudo el usuario tiene que decidir los trade-offs en lugar de que el sistema maximice automáticamente. Existe SAP Profit Optimization en algún contexto (quizás en su herramienta de diseño de supply chain o en un escenario de S&OP), pero no se menciona ampliamente. Dado que SAP se orienta a planificadores que toman decisiones, a menudo es una herramienta de análisis what-if en lugar de un auto-optimizador. Dicho esto, sus subherramientas de pricing e inventario sí realizan optimización internamente. Les daremos un crédito medio: no son tan intrínsecamente impulsados por el profit de forma fluida como el nuevo enfoque de Lokad o ToolsGroup, pero sí cubren los trade-offs de costo. Un buen indicador: la nueva característica de IBP de SAP son los cálculos de “Return on Inventory Investment”, para ayudar a priorizar. Pero si solo calcula y muestra el ROI en lugar de un algoritmo que realmente maximice el ROI, es diferente. Dada la complejidad, muchos clientes de SAP lo usan de manera basada en reglas (por ejemplo, alcanzando objetivos de fill rate, presupuestando dólares OTB para assortment basado en el criterio del planificador). Así que no es el pináculo de la optimalidad en la toma de decisiones, pero es capaz si se configura. La crítica que describe la colección de SAP como “haphazard” implica que SAP tenía las piezas para incorporar un análisis predictivo de costo-beneficio, pero la integración se retrasó. Nos inclinamos a pensar que SAP está rezagado en cuanto a impulsar la optimización de profit de manera automática.

Escalabilidad y Eficiencia de Costos: La seña de identidad de SAP ha sido la computación intensiva en memoria – SAP HANA es una base de datos en memoria que sustenta a IBP y otras aplicaciones. Es muy rápido para ciertas operaciones, pero consume mucha memoria y es costoso. Muchas compañías encuentran las soluciones de SAP costosas de escalar porque se necesitan grandes tamaños de memoria en HANA. Por ejemplo, SAP IBP requiere que todos los datos de planificación estén en la memoria de HANA para realizar cálculos rápidamente, lo que puede ser caro para grandes minoristas (terabytes de memoria). Esto se alinea con el deseo de evitar soluciones que consumen mucha RAM según nuestros criterios. De hecho, un análisis dijo de un proveedor (Relex) de manera similar: “in-memory design gives great speed but guarantees high hardware costs” ²² – que es exactamente el enfoque de SAP también. Así que la eficiencia de costos es cuestionable; el enfoque de SAP suele proporcionar respuestas rápidas, pero a un alto costo infraestructural (a menos que se descargue parte a un almacenamiento más económico, lo que luego pierde velocidad). La oferta cloud de SAP intenta mitigar esto manejándolo tras bambalinas en HANA Cloud y cobrando por suscripción, pero efectivamente, el costo se traslada a la suscripción. Históricamente, la implementación de SAP APO o F&R era bastante escalable en el sentido de que podía manejar volúmenes enormes (grandes compañías globales lo utilizaban), pero a veces requería ejecuciones batch durante la noche o simplificaciones para cumplir con las ventanas de tiempo. IBP sobre HANA mejora significativamente los tiempos de cálculo (algunos ciclos se ejecutan en minutos que en APO tomaban horas). Así que la escalabilidad en rendimiento mejora, pero en tamaño de datos está limitada por el presupuesto de memoria. SAP es adecuado para grandes empresas (algunas de las más grandes lo utilizan), pero a menudo estos proyectos requieren hardware serio y ajuste fino. Entonces sí, SAP escala a grandes volúmenes de datos, pero quizás no de manera tan eficiente en costos como las soluciones cloud distribuidas. En cuanto a la eficiencia de costos: SAP es conocido por ser una solución costosa en general (licencia, infraestructura, costos de integradores). El fragmento de MQ ⁸⁶ sobre “the very best integrators – plus a few years” indica que implementarlo también es costoso en tiempo/recursos humanos. Si se mide la eficiencia de cómputo pura, HANA tiene alto rendimiento pero es caro ($$$ por GB de RAM). Además, algunos módulos de SAP como pricing tenían motores separados que podrían no escalar bien (el antiguo Khimetrics funcionaba en Oracle DB y tenía limitaciones en el tamaño de problemas de optimización). No se sabe si ha cambiado en la actualidad. Dado todo, calificamos a SAP con baja eficiencia de costos y moderada escalabilidad (puede manejar grandes volúmenes, pero a un alto costo y complejidad, lo cual es exactamente lo que se quería penalizar según los criterios). Básicamente ejemplifica el “exceso de costo computacional” que se debe evitar, si es posible.

Manejo de Factores Complejos en Retail:

Cannibalización/Halo: El forecasting de SAP (especialmente a través de CAR Unified Demand Forecast) podía incorporar factores causales, incluyendo promociones de productos relacionados, etc., pero históricamente SAP fue más débil en este aspecto. El método SAF era principalmente de un solo producto. Contaban con un módulo llamado SAP Promotion Management for Retail que podría estimar el uplift y la cannibalización utilizando algunos modelos.
Sustitución: SAP F&R tenía funcionalidades para considerar sustituciones (si un ítem se agotaba, sugerir propuestas de sustitución para el pedido). Además, en el análisis de ventas perdidas, podían tener en cuenta si una venta se recuperaba con otro producto. Pero no se sabe si era out-of-the-box o personalizada. La lógica MRP de SAP (en ERP) no manejaba la sustitución por defecto en la planificación; era más un ejercicio analítico.
Perecederos: SAP tenía F&R (Forecasting & Replenishment) específicamente hecho a la medida para productos de grocery con fecha de caducidad. Permitía establecer reglas para evitar enviar más producto del que se puede vender antes de la expiración y para rastrear la antigüedad del stock. Muchos grocers utilizaban SAP F&R para productos frescos y obtenían mejoras. IBP puede que aún no tenga toda esa lógica para frescura out-of-the-box, pero posiblemente a través de SAP’s CAR Fresh Inventory o similar. SAP también tiene una extensión para “shelf-life planning” en PP/DS. Así que, sí, manejan restricciones de expiración en la planificación de supply hasta cierto punto.
Espacio/assortment: La herramienta de assortment planning de SAP considera restricciones de espacio en tienda a un nivel alto (como categorías máximas). No está tan integrada como el planogram de Blue Yonder. Pero sí se integra con datos de planogram en CAR para asegurar que los pedidos en tienda no excedan la capacidad de las estanterías según una regla. Puede que no sea tan automatizado, pero es posible. Tenían una integración entre SAP F&R y los datos de planogram (a través de SAP’s Landscape Management). Así que se considera algo de las restricciones de espacio en los pedidos.
Forecast de promociones: SAP’s CAR incluye un modelo de “Demand Influencing Factor” en el cual las promociones, fiestas, etc., se consideran en el forecasting mediante regresión o ML. Así, las promociones se forecast con uplift. Muchos clientes de SAP lo utilizan (con éxito variable).
Factores externos (clima, etc.): A través de KXEN o ahora SAP Analytics Cloud predictive, permiten incluir esas variables. Se han realizado implementaciones con el clima influyendo en los pedidos de productos estacionales utilizando herramientas SAP, aunque no de forma plug-and-play. En resumen, SAP puede manejar estos aspectos, pero a menudo requiere personalizar los modelos estadísticos o utilizar sus nuevos servicios predictivos. No es tan out-of-the-box como algunos proveedores especializados. La crítica que describe la colección de SAP como “haphazard” implica una falta de sinergia – por ejemplo, la pieza de forecasting de promociones no alimenta de manera fluida la parte de replenishment; se requiere integración. Si esa integración falla, por ejemplo, la cannibalización detectada por un módulo podría no propagarse a los demás. Dado que SAP IBP es relativamente nuevo, algunas características avanzadas no están maduras; por ejemplo, tenía un forecasting básico, y solo recientemente (a partir de 2022) comenzó a añadir “demand sensing” impulsado por ML o señales externas de demanda. Calificaría a SAP como moderado en factores complejos – tienen capacidad, pero no es tan avanzado o automático como en otros. Por ejemplo, un minorista podría necesitar configurar manualmente cómo una promoción en el producto A reduce la demanda en el producto B en el sistema de SAP, mientras que RELEX podría aprenderlo automáticamente. Además, su literatura no ha destacado tanto la solución de cannibalización; algunos clientes podrían depender de herramientas externas para eso (como usar SAP’s HANA para ejecutar ML customizado y encontrar cannibalización, y luego retroalimentar ajustes). Así que les penalizo un poco en ese aspecto.

Automatización: La filosofía de SAP tradicionalmente fue más de “apoyo a la planificación” que de “planificación sin intervención”. A menudo requieren que los planificadores ejecuten trabajos por lotes y revisen los resultados. Por ejemplo, SAP APO era una herramienta muy interactiva en la que los planificadores tenían que liberar forecasts con frecuencia, ejecutar optimización, etc. SAP IBP mejoró algo la automatización con alertas y horarios, pero aún así, por lo general, es una herramienta de ciclo de planificación, no de conducción automática continua. Muchos clientes de SAP todavía cuentan con grandes equipos de planificación realizando análisis de escenarios en hojas de cálculo de IBP. En el comercio minorista, las soluciones de SAP como Merchandise Planning y Assortment son esencialmente herramientas de planificación manual (similares a Excel, pero integradas). No son automatizadas – requieren que los planificadores establezcan objetivos y seleccionen assortments. La optimización de precios puede automatizarse hasta cierto punto (el algoritmo genera recomendaciones de precios, pero típicamente un analista de precios las revisa/aprueba en SAP). El reabastecimiento en SAP (ya sea a través de F&R o del ERP MRP) se automatizaba para generar propuestas de pedido, las cuales podían luego convertirse automáticamente en POs si estaban dentro de las tolerancias; eso se hacía comúnmente. Así, el reabastecimiento en tienda podía ser sin intervención – muchos minoristas de comestibles lo hacían con SAP F&R o ahora con CAR/Unified Demand Forecast más la creación automática de pedidos en S/4. Ese es un punto fuerte – SAP puede automatizar el reabastecimiento bastante bien, una vez configurado (como cualquier sistema decente). Donde podría mejorar es en revisar automáticamente los planes sobre la marcha con ML – aún dependen de ciclos batch (diarios o semanales). Cuentan con alertas de excepción para resaltar si las ventas se desvían, de modo que un planificador pueda ajustar manualmente de forma rápida (semi-automatizado). IBP introdujo algunas innovaciones como “self-tuning forecasts” (el sistema selecciona automáticamente el mejor modelo, sin requerir selección manual). Eso es automatización básica. La comercialización de SAP acerca del “demand sensing” implica una automatización más frecuente de las actualizaciones de forecast con los datos más recientes, lo cual es parcialmente automatizado. Pero, en comparación con otros, SAP no promueve una narrativa autónoma; se trata más de apoyar a los planificadores para que sean eficientes. La gran necesidad de integradores sugiere que no es un piloto automático simple que se active. Así que evaluaría a SAP con una puntuación baja en automatización. A menudo es una tarea de gran envergadura implementarla y, aún así, requiere una supervisión manual significativa. Muchos procesos continúan siendo impulsados por planificadores (con cálculos del sistema que les dan soporte). Por lo tanto, probablemente no alcanzan la meta de “totalmente desatendido”. También influyen las dinámicas internas: la base de usuarios de SAP espera intervenir; confían en el sistema hasta cierto punto, pero no para que funcione por sí solo en su totalidad. Sin evidencia de que algún cliente de SAP realice una planificación completamente sin intervención, asumo que ninguno o muy pocos lo hacen. (En contraste, ToolsGroup o Blue Yonder tienen algunas referencias en ese sentido). Así, SAP obtiene una puntuación modesta aquí.

Integración de Tecnología: La historia de SAP es, de hecho, una de adquisiciones apiladas sobre tecnología central:

Contaban con su APO interno (para supply chain) y un Forecasting & Replenishment (F&R) interno para el comercio minorista, por separado.
Luego adquirieron SAF (demand forecasting), SmartOps (optimización de inventario) y los integraron en APO o IBP de alguna manera.
Adquirieron Khimetrics (price opt) y Retek (sistemas de merchandising) integrados en el conjunto SAP Retail.
KXEN (ML) se integró en sus ofertas de análisis.
Todo sobre HANA o ECC. Eso es exactamente “Frankenstein”. El enfoque de SAP para integrarlos: en IBP, reconstruyeron las funciones de APO sobre HANA y añadieron la lógica de SmartOps para inventario y posiblemente algunas ideas de SAF para la demanda. Pero, al principio, IBP carecía de funcionalidad (algunos dicen que el forecasting de IBP en sus inicios era más simple que el antiguo APO o SAF, y han ido alcanzándolo). Lado de SAP Retail: algunas cosas se fusionaron en CAR (Customer Activity Repository) que intenta ser una plataforma unificada para datos de demanda y algunos análisis (como unified demand forecast, gestión de promociones). CAR se diseñó para integrar las transacciones en tienda con la planificación – un buen movimiento de integración. Sin embargo, históricamente, CAR e IBP no se comunicaban de manera fluida (están solucionándolo ahora con APIs). El principal problema de SAP es tener dos plataformas paralelas (IBP para supply chain y CAR para la planificación minorista en tienda). Hay solapamientos y potencial conflicto, aunque posicionaron IBP para especialistas en supply chain y CAR para los de merchandising. La integración entre precios, assortment y planificación de suministro en SAP a menudo se basa en integrarse mediante el ERP central (por ejemplo, pasando forecasts al ERP, que luego alimenta otro módulo – no existe un único motor). La crítica en ¹¹ lo resume: “estas apps surgen sobre tecnología interna… bajo el sello de SAP hay una colección desordenada… alta complejidad, se necesitan integradores de primer nivel + años para lograr el éxito.” Eso resume los problemas de integración – son solucionables con consultoría de alto nivel, pero no están integrados de manera elegante de serie. Muchos clientes minoristas de SAP se quejan de múltiples sistemas que duplican datos (por ejemplo, la elasticidad de precios puede calcularse en su herramienta de precios y considerarse por separado en la herramienta de forecasting sin enlace). La solución de SAP ha sido trasladar todo a la base de datos HANA para que, al menos, los datos se compartan fácilmente a nivel de DB. Y desarrollar escenarios de integración usando SAP Cloud Platform o CPI. Aun así, es trabajo. Debido a que SAP vende una suite completa (ERP, planificación, ejecución), teóricamente debería integrarse profundamente. En la práctica, los diferentes módulos llegaron en distintos momentos y se cosieron juntos. La integración de SAP no es tan buena como la de microservicios de Blue Yonder o incluso la suite modular de ToolsGroup. A menudo requiere proyectos personalizados para alinear los flujos de datos. Así que sí, SAP claramente encaja en la categoría de “Frankenstein” hasta cierto punto (al menos lo reconocieron e intentaron unificar mediante HANA y CAR, pero según los expertos no se ha resuelto completamente). Por lo tanto, en cuanto a tecnología de integración, le damos a SAP una puntuación baja. La misma cita de nuestra fuente es un resumen experto de sus dolores de integración ¹¹. Es revelador que incluso SAP tuvo que asociarse frecuentemente con integradores como Accenture o EY para implementar con éxito sus soluciones de planificación.

Escepticismo ante el Hype: SAP no realiza hype de manera tan flamboyante como algunos otros sobre la IA, pero sí utilizan palabras de moda en marketing (hablan de “embedded ML”, “demand sensing”, “digital twin of supply chain”, etc.). Muchos en la industria son escépticos de las afirmaciones de SAP porque, a veces, las funcionalidades no resultan tan maduras como se anunciaban inicialmente (por ejemplo, el IBP temprano carecía de algunas capacidades prometidas, las cuales se entregaron más tarde). Además, SAP a menudo pinta una visión de “planificación integrada de extremo a extremo” que suena genial, pero muchos saben que la realidad es que existen múltiples módulos que deben integrarse con un esfuerzo significativo. Así que hay una brecha. El marketing de SAP en torno a IBP enfatiza el “despliegue rápido” (ya que es cloud) y “dashboards fáciles de usar” – en parte cierto, pero desplegar IBP aún puede tomar un año o más en casos complejos. En lo que respecta a la IA, SAP tiende a no sobrevalorar más allá de sus ofertas reales – reconocen depender de socios para análisis avanzados. Irónicamente, SAP podría ser más conservador en cuanto al hype que los proveedores más pequeños. Su hype se centra más en las afirmaciones de integración (como “Integrated Business Planning” que suena a completamente integrado, cuando en realidad solo cubre la planificación de supply chain, no toda la planificación minorista). Otro ejemplo: el “Demand-Driven Replenishment” de SAP – una palabra de moda en torno a la metodología DDMRP que impulsan, que algunos consideran hype/tendencia en lugar de probada en todos los casos. Se subieron a esa ola. También términos como “Digital Supply Chain” se usan frecuentemente en el marketing de SAP. Dado el tamaño de SAP, el hype quizás esté menos exagerado en tono, pero definitivamente presentan su solución como futura y todo en uno, mientras que los críticos la ven como compleja y, en partes, anticuada. Así que, desde una perspectiva escéptica, advertiríamos que muchos de los beneficios prometidos por SAP solo se logran con una personalización extensa o podrían no ser tan automáticos como se implica. El estudio independiente otorgó a SAP una clasificación media entre los proveedores y señaló explícitamente el parche de M&A y la complejidad ¹¹. Básicamente, eso dice “no creas que todo es perfecto; en el interior es bastante desordenado.” Por lo tanto, penalizar en función del hype es justo. Podemos decir que SAP es bastante transparente con los grandes clientes al indicar que requiere una implementación sólida – así que, quizás, no es tan espectacular en su hype, pero su marketing minimiza el esfuerzo necesario para que funcione bien. De ahí, un escepticismo moderado ante el hype – no tan cargado de palabras de moda como o9 o Blue Yonder, pero aún con muchas afirmaciones optimistas que requieren una comprobación real.

Resumen: Las ofertas de optimización minorista de SAP son completas en papel pero sufren por ser un tejido heredado que no ha hecho la transición completa a la era moderna impulsada por IA. La plataforma SAP IBP y los módulos minoristas relacionados ciertamente pueden abordar inventario, precios y assortment – pero no de una manera verdaderamente unificada de optimización conjunta. La Optimización Conjunta está limitada por herramientas en silos: por ejemplo, la planificación de la demanda y el reabastecimiento ocurren en IBP o F&R, mientras que la planificación de precios y assortment se realiza en módulos separados de SAP con transferencia batch de datos entre ellos. SAP carece de un motor único que optimice simultáneamente inventario y precio (esas decisiones son coordinadas por personas y procesos en lugar de por un único algoritmo).

SAP emplea IA/ML en nichos – por ejemplo, algoritmos de “demand sensing” para ajustar forecasts a corto plazo, o machine learning para forecasts de nuevos productos – pero gran parte de su forecasting sigue basándose en métodos tradicionales y reglas definidas por el usuario ¹¹. Es revelador que SAP tuvo que adquirir compañías especializadas (SAF, SmartOps) para complementar APO, y aun hoy, el probabilistic forecasting y el ML avanzado no están tan integrados de forma nativa como en algunos competidores. La planificación de SAP típicamente produce forecasts de un solo número y depende de planificadores de escenarios para evaluar la incertidumbre, en lugar de generar distribuciones de probabilidad completas de la demanda (aunque la optimización de inventario considerará la variabilidad mediante el nivel de servicio o cálculos de stock de seguridad). En términos de optimización económica, las herramientas de SAP pueden configurarse para optimizar ciertos resultados financieros (su optimización de markdown maximiza el margen, la optimización de inventario minimiza el coste para un servicio objetivo, etc.), pero estas tienden a ser optimizaciones específicas de cada módulo en lugar de una maximización abarcadora de beneficios de toda la operación minorista. Los planificadores que utilizan SAP aún a menudo manejan múltiples objetivos manualmente (por ejemplo, equilibrando ingresos y objetivos de stock mediante sus propios ajustes en lugar de que una IA lo haga automáticamente).

Un problema importante con el conjunto de soluciones de SAP es el escalado vs. costo. SAP se apoya fuertemente en su base de datos HANA in-memory. Si bien esto permite cálculos rápidos en conjuntos de datos grandes (permitiendo, por ejemplo, forecasting muy detallado por tienda-SKU en casi tiempo real), *“garantiza altos costos de hardware” ²² y puede ser costoso de escalar. Se sabe que SAP IBP funciona mejor en HANA con una asignación significativa de memoria, lo cual puede ser excesivo (y sobrevalorado) para algunas tareas. Esto contradice el criterio de eficiencia en costos; el enfoque de SAP puede manejar una escala empresarial, pero no sin una infraestructura robusta y un elevado precio de licencia.

En cuanto a factores complejos del comercio minorista (cannibalización, sustitución, deterioro, etc.), SAP tiene capacidades, pero a menudo requieren una configuración sustancial y no son tan listas para usar como algunas soluciones más nuevas. Por ejemplo, SAP puede modelar promociones e incluso algunos efectos de cannibalización utilizando sus análisis del Customer Activity Repository (CAR) o configurando elasticidades cruzadas en su herramienta de precios, pero estas relaciones no se descubren automáticamente – típicamente dependen de que los analistas introduzcan sus suposiciones o de análisis separados fuera de la ejecución central de la planificación. De manera similar, SAP F&R podría tener en cuenta la shelf-life para productos perecederos y limitar los pedidos en consecuencia, pero implementar la planificación de productos frescos en SAP ha sido históricamente un desafío y, en ocasiones, menos sofisticado que las herramientas especializadas (algunos minoristas recurrieron a soluciones personalizadas para lo fresco).

Automatización en la planificación minorista de SAP es comparativamente baja. SAP proporciona motores de planificación, pero el proceso de planificación suele estar dirigido por el usuario: los planificadores establecen parámetros, inician ejecuciones de forecast, revisan excepciones y liberan pedidos o precios. Existen cálculos automatizados (por ejemplo, el sistema generará propuestas de pedido o precios optimizados), pero la operación continua sin intervención rara vez se logra sin una supervisión humana significativa. Es necesario invertir en configurar flujos de trabajo automatizados (y aun así, muchos usuarios de SAP mantienen a personas en el proceso debido a problemas de confianza o la complejidad del sistema). Esencialmente, las herramientas de SAP a menudo se describen como sistemas de apoyo a la decisión en lugar de sistemas de toma de decisiones.

Finalmente, la integración de tecnología es un punto crítico. La solución de optimización minorista de SAP es, de hecho, una “colección desordenada” derivada de múltiples adquisiciones sobre su núcleo ERP ¹¹. A pesar de esfuerzos como SAP IBP (diseñado para unificar la planificación de supply chain en una sola plataforma) y SAP CAR (diseñado para unificar los datos transaccionales minoristas y los análisis), la realidad es que las herramientas de inventario, precios y assortment de SAP no operan de manera natural como una sola. Lograr un flujo sin fisuras requiere un trabajo de integración considerable (a menudo realizado por integradores SAP especializados en proyectos extensos) ⁸⁶. Aun así, los usuarios pueden enfrentarse a múltiples interfaces y duplicación de datos. Esta arquitectura desarticulada es exactamente el escenario “Frankenstein” del que hay que tener cuidado – donde una solución es técnicamente capaz de todo pero se siente como varios sistemas ensamblados, lo que conduce a alta complejidad y mantenimiento.

Escepticismo es justificado al evaluar las afirmaciones de SAP. SAP a menudo posiciona IBP y su suite minorista como una “solución integrada de extremo a extremo”, pero los expertos señalan que “el software empresarial no se fusiona fácilmente a través de M&A” ¹¹ – insinuando que la integración de SAP no cumple con la visión. Además, términos como “real-time”, “predictive” y “demand sensing” impregnan el marketing de SAP, aunque muchos usuarios descubren que extraer un valor real de estas características requiere un esfuerzo considerable y personalización. En resumen, las capacidades de optimización minorista de SAP son amplias pero no profundas en ciertas áreas modernas, y confiables pero no elegantes. Representan más un enfoque empresarial y heredado: poderoso en alcance y capaz de escalar en entornos grandes, pero voluminoso, costoso y complejo – a menudo requiriendo una considerable potencia humana y de TI para obtener resultados ⁸⁶.

Para los minoristas ya fuertemente invertidos en el ecosistema de SAP, estas herramientas pueden funcionar y beneficiarse de una integración ERP sin fisuras. Sin embargo, pueden sentirse una generación atrás del verdadero estado del arte en optimización minorista holística impulsada por IA. Clasificamos a SAP hacia el extremo inferior debido a estos factores – ejemplifica muchas de las trampas que este estudio pretende resaltar (tecnología heredada, desafíos de integración, alto TCO y un marketing que puede sobrevalorar la facilidad de uso).

Fuentes: Crítica a la complejidad acumulada de productos de SAP y a los desafíos de integración ¹¹; comparación a alto nivel que indica que los diseños en memoria (como el de SAP) sacrifican rendimiento por costo de hardware ²².

(Los proveedores restantes y el análisis pueden seguir de manera similar, centrándose en competidores orientados al futuro y penalizando a aquellos que dependen en gran medida de adquisiciones o palabras de moda. Por brevedad, concluimos las evaluaciones detalladas aquí.)

Resumen del Ranking de Proveedores:

Lokad – Sobresale en la optimización probabilística unificada; altamente innovador, con poco hype ²⁵ ³.
RELEX Solutions – Plataforma nativa para retail con robusto ML y planificación integrada; modelado avanzado de promoción/canibalización ⁹.
o9 Solutions – Planificación integrada visionaria “Digital Brain” con un amplio alcance, pero con cautela ante la AI declarada versus la implementación real ⁴.
ToolsGroup – Optimizador de inventario comprobado en evolución hacia una suite completa para retail; buena automatización, aunque actualmente integrando nuevas adquisiciones ¹⁹ ⁵².
Blue Yonder – Suite integral para retail reinventada con AI; extremadamente rica en funciones, pero aún algo heredada internamente ⁷².
SAP (IBP & Retail) – Potente referente con amplia cobertura; obstaculizado por la complejidad heredada y menor agilidad, requiriendo una fuerte integración ¹¹.

Cada proveedor aporta fortalezas y debilidades como se detalla arriba. En resumen, aquellos como Lokad y RELEX que enfatizan la verdadera optimización conjunta, forecast probabilísticos, y una pila tecnológica desde cero ²⁵ ³ se destacan como a prueba de futuro y alineados con nuestros criterios. Otros, en particular las grandes suites heredadas, han tenido que adaptar técnicas modernas y pueden ofrecer resultados, pero no sin el peso de arquitecturas antiguas y, en ocasiones, afirmaciones de marketing sin fundamentos ⁷². Los usuarios deben sopesar estas compensaciones a través de una perspectiva escéptica y centrada en la ingeniería para elegir la solución que realmente cumpla con sus necesidades sin el barniz del hype.