Software de optimización para eCommerce, febrero 2025

Por Léon Levinas-Ménard

Última modificación: 2 de febrero de 2025

Introducción

El mercado de software de optimización para eCommerce está lleno de afirmaciones audaces de una magia impulsada por IA, pero un examen minucioso revela que solo unos pocos proveedores cumplen verdaderamente la promesa de optimizar conjuntamente inventario, precios y surtido con tecnología de última generación. En este estudio, evaluamos las soluciones líderes para el eCommerce puro (minoristas online sin tiendas físicas) y clasificamos a los proveedores más relevantes – incluidos Lokad, RELEX Solutions, Blue Yonder y ToolsGroup – según sus méritos técnicos e inconvenientes. Lokad se destaca como líder debido a su enfoque unificado y probabilístico y su alto grado de automatización, mientras que RELEX y Blue Yonder ofrecen suites integrales matizadas por la complejidad de IA de caja negra y por cargas heredadas, respectivamente. ToolsGroup proporciona una optimización comprobada de inventario basada en matemáticas sólidas, pero enfrenta desafíos de integración al expandirse hacia la fijación de precios y surtido. A lo largo del análisis, aplicamos una perspectiva profundamente escéptica: despojándonos de la palabrería del marketing, examinando las afirmaciones de los proveedores frente a evidencia independiente y destacando las advertencias a menudo no mencionadas (por ejemplo, la falta de optimizar las decisiones de manera holística, o la dependencia de arquitecturas costosas). El objetivo es un análisis técnico narrativo que sitúe la verdad por encima del bombo publicitario, para que los actores del eCommerce puedan entender quién realmente impulsa el estado del arte – y quién se queda corto.

Los criterios del estándar de oro: Optimización conjunta y tecnología avanzada

Cualquier proveedor puede alardear de IA o de big data, pero optimizar verdaderamente un negocio de eCommerce requiere cumplir con altos estándares de criterios técnicos y funcionales. Lo primordial es la optimización conjunta: la capacidad de optimizar simultáneamente los niveles de inventario, la fijación de precios y las decisiones de surtido de productos. Tratar estos aspectos de forma aislada – como hacen muchos sistemas antiguos – es fundamentalmente defectuoso, ya que están estrechamente interrelacionados (el precio afecta la demanda, lo que a su vez influye en el inventario, los cambios en el surtido afectan a ambos, etc.). Una solución de optimización para eCommerce debe coordinar los tres; por ejemplo, podría decidir almacenar menos de un producto y ofrecer un descuento más pronto si los forecast revelan ventas lentas, o aumentar los precios de ciertos artículos para evitar faltante de stock. Las soluciones que optimizan el inventario pero ignoran la fijación de precios, o viceversa, dejan dinero sobre la mesa y son subóptimas por diseño.

Más allá de la optimización conjunta, las soluciones verdaderamente de última generación deberían aprovechar técnicas y arquitecturas modernas:

Forecast probabilístico: En lugar de previsiones de demanda puntuales, se deben utilizar distribuciones de probabilidad para capturar la incertidumbre en la demanda. Esto es crucial para el eCommerce, con sus patrones de demanda volátiles y su “long tail” de SKUs. Las herramientas tradicionales (por ejemplo, módulos antiguos de SAP u Oracle) que generan un solo número y un stock de seguridad a menudo subestiman la verdadera variabilidad ¹ ². Los proveedores líderes ahora enfatizan modelos probabilísticos o “estocásticos” que cuantifican el rango de resultados.
Optimización económica: Las decisiones deben estar guiadas por objetivos económicos (beneficio, costo, objetivos de nivel de servicio) y no solamente por reglas heurísticas. Por ejemplo, un sistema verdaderamente optimizado considerará los márgenes de beneficio y los costos de mantenimiento de los productos al determinar los niveles de stock y los precios. Priorizará acciones que maximicen el beneficio esperado o minimicen el costo total, en lugar de alcanzar ciegamente una tasa de cumplimiento. Esto requiere incorporar parámetros de costo/ingresos en los algoritmos.
Escalabilidad y eficiencia en costos: Los datos de eCommerce son masivos (potencialmente millones de SKUs, transacciones diarias, múltiples canales). El software debe manejar datos a gran escala sin costos exorbitantes en hardware ni un rendimiento lento. Las arquitecturas que mantienen todo en memoria (RAM) de manera ingenua pueden volverse prohibitivamente costosas a escala. Los diseños modernos utilizan la computación en la nube de forma inteligente, por ejemplo, procesamiento distribuido, almacenes de datos en disco y algoritmos eficientes. Una solución que requiera una granja de servidores o plataformas costosas (como el uso excesivo de la nube de datos de Snowflake) podría erosionar el ROI. Por el contrario, una ingeniería inteligente puede procesar conjuntos de datos a escala de terabytes en pocas horas en instancias de computación en la nube de bajo costo ³ ⁴.
Efectos de canibalización y sustitución: En las decisiones de surtido y fijación de precios, el sistema debe tener en cuenta que los productos pueden afectar la demanda de otros. Por ejemplo, si dos productos son sustitutos cercanos, dejar de ofrecer uno puede desviar la demanda hacia el otro (un efecto de canibalización). Manejar esto requiere algo más que un análisis OLAP simple o grupos de productos definidos manualmente; requiere modelos que aprendan las elasticidades cruzadas o tasas de adhesión. Muchas herramientas heredadas asumen que la demanda de cada producto es independiente, lo que lleva a errores tanto en el forecast como en la planificación del surtido. Un proveedor de última generación debería modelar explícitamente tales relaciones (por ejemplo, utilizando machine learning en datos de transacciones para inferir afinidades entre productos).
Impactos del mercado y la competencia: Los actores puros del eCommerce a menudo se ven influenciados por la dinámica del mercado, por ejemplo, la competencia en Amazon o eBay, vendedores terceros, etc. El software de optimización debería, idealmente, incorporar señales como la fijación de precios de los competidores o los faltantes de stock en los marketplaces. Pocos lo hacen bien. Es una frontera compleja pero cada vez más relevante: por ejemplo, si un competidor sufre un faltante de stock en un artículo popular, su sistema debería detectar esa oportunidad y ajustar su precio o gasto en publicidad en consecuencia. De manera similar, si vende tanto de forma directa como en marketplaces, el sistema debería optimizar entre canales (evitando, por ejemplo, sobrestockear en su propio sitio cuando el producto se vende a través de Amazon FBA).
Capacidades multicanal y omnicanal: Incluso sin tiendas físicas, un comerciante de eCommerce puede tener múltiples canales en línea (su propio sitio web, marketplaces, quizá sitios regionales). El motor de optimización debe gestionar de forma holística la demanda y el inventario multicanal, reconociendo, por ejemplo, que el inventario es compartido o que las decisiones de fijación de precios en un canal pueden afectar a otro. La planificación “end-to-end” no es solo una palabra de moda; significa que el software ve el panorama completo (desde proveedores hasta clientes, a través de todas las corrientes de ventas).
Alto grado de automatización (“robotización”): La promesa última de estos sistemas es la toma de decisiones autónoma. Teóricamente, deberían ser capaces de funcionar sin supervisión, generando órdenes de reposición, actualizaciones de precios, etc., sin que los usuarios tengan que ajustar parámetros cada día. En la realidad, todos los proveedores aún permiten la configuración por parte del usuario, pero favorecemos a aquellos que minimizan la necesidad de ajustes manuales. Cuidado con las soluciones que se jactan de la automatización pero exponen docenas de configuraciones (parámetros, factores de ponderación, reglas); eso es una contradicción interna. La verdadera automatización proviene de dejar que los algoritmos encuentren los ajustes óptimos, en lugar de pedir a los usuarios que recalibren constantemente. Los mejores sistemas utilizan técnicas como modelos autoaprendices que se ajustan a medida que llegan nuevos datos, de modo que con el tiempo las decisiones se mantengan óptimas sin intervención manual ⁵. Cuantos menos “ajustes” tenga que mantener un usuario, más creíble es la automatización.
Arquitectura robusta y rentable: Ya hablamos de eficiencia en costos, pero vale la pena señalarlo explícitamente: algunas soluciones modernas han adoptado almacenes de datos en la nube (como Snowflake) para escalar. Esto puede eliminar los dolores de cabeza de la infraestructura, pero introduce un modelo de costos basado en el uso. Si una herramienta de planificación requiere procesar enormes cantidades de datos en una plataforma como Snowflake, los costos pueden dispararse (de manera similar a la tarificación basada en MIPS de IBM en la década de 1990, donde un mayor uso de CPU significaba tarifas exponencialmente más altas). Una solución ideal maneja los grandes datos con algoritmos inteligentes para mantener el uso en la nube (y, por ende, el costo) razonable ⁴. De igual manera, las soluciones construidas a través de adquisiciones podrían terminar siendo un conjunto parcheado de módulos en diferentes stacks tecnológicos, lo que conduce a altos costos de integración para el cliente (ya sea en dinero o en latencia del sistema). Ser nativo en la nube e integrado desde el primer momento es una ventaja, pero solo si la arquitectura elimina verdaderamente el movimiento redundante de datos sin introducir nuevos cuellos de botella.

Con estos criterios establecidos, ahora nos dirigimos a los proveedores. Clasificamos a Lokad, RELEX, Blue Yonder y ToolsGroup como los actores más relevantes para la optimización de eCommerce, y evaluamos a cada uno conforme a los criterios mencionados. El análisis tiene un estilo narrativo – centrado en cómo cada proveedor aborda el problema y dónde se justifica el escepticismo – en lugar de una lista de características. Es importante destacar que nos basamos en evidencia creíble (y citas directas) siempre que es posible, evitando la trampa común de tomar las afirmaciones de los proveedores al pie de la letra.

1. Lokad – Optimización Cuantitativa Unificada con respaldo probabilístico

Lokad se destaca como un proveedor construido explícitamente en torno a la idea de la optimización conjunta utilizando tecnología de punta. A diferencia del software tradicional de cadena de suministro, Lokad no se presenta como un conjunto de módulos (forecast, MRP, etc.) para ser ajustados, sino como una plataforma programática en la que se implementa una lógica de optimización unificada para cada cliente. Este enfoque, que denominan “Supply Chain Quantitativa”, puede requerir más ciencia de datos desde el inicio, pero ofrece una solución hecha a la medida para optimizar todas las decisiones conjuntamente – inventario, precios, reposición, todo en uno. La filosofía de Lokad es que los forecast son solo un medio para alcanzar un fin; el verdadero objetivo es optimizar las decisiones (por ejemplo, cuánto comprar, qué precio establecer) considerando todas las restricciones y compromisos económicos.

En el núcleo se encuentra el forecast probabilístico. Lokad fue uno de los pioneros en utilizar distribuciones de probabilidad completas para la demanda, e incluso demostró su capacidad en el ámbito neutral de las competencias de forecasting. En la prestigiosa Competencia M5 Forecasting (2020), un equipo de Lokad se ubicó en el sexto lugar a nivel mundial de entre 909 equipos ⁶ – una validación impresionante de su tecnología, dado que M5 se centró en datos minoristas granulares (del tipo que enfrentan las empresas de eCommerce). Es notable que M5 requirió forecast probabilísticos (por cuantiles), lo que se alinea con la fortaleza de Lokad. Este resultado indica no solo destreza académica, sino también relevancia práctica: sus forecast estuvieron entre los mejores, lo que sustenta cualquier optimización de inventario y fijación de precios. Además, el CEO de la compañía ha destacado que, más allá de cierto punto, las mejoras en la precisión del forecast generan retornos decrecientes en comparación con un mejor modelado de las decisiones ⁷. En otras palabras, Lokad enfatiza la optimización de las decisiones (cantidades de pedido, asignaciones, etc.) utilizando los forecast probabilísticos, en lugar de perseguir una pequeña mejora en la precisión del forecast que puede no afectar materialmente los resultados. Esta perspectiva es refrescante e importante para el eCommerce: reconoce que el manejo de aspectos como faltantes de stock, demanda intermitente y efectos de sustitución a menudo importa más que una pequeña mejora porcentual en una métrica de forecasting ⁷.

Desde el punto de vista tecnológico, Lokad es de última generación y está fuertemente orientado a la ingeniería. Han construido su propia pila tecnológica nativa en la nube (incluyendo un lenguaje específico de dominio personalizado llamado “Envision” para escribir scripts de optimización). Esta pila está diseñada para procesar grandes volúmenes de datos de manera eficiente y económica. Por ejemplo, el sistema de Lokad procesa rutinariamente desde gigabytes hasta terabytes de datos de clientes (órdenes, clics, etc.) en pocas horas durante la noche, para generar decisiones para el día siguiente ⁸ ³. Para lograr esto, evitan cargar todo en RAM; en su lugar, utilizan archivos mapeados en memoria y almacenamiento columnar en disco, permitiendo que conjuntos de datos mayores que la memoria de una máquina se manejen de forma transparente mediante el uso de SSDs rápidos ³ ⁹. Señalan explícitamente que Envision (su motor) soporta conjuntos de datos mayores que la memoria incluso de todo el clúster al “derramar inteligentemente a unidades NVMe”, y que las operaciones embarrasilmente paralelas se distribuyen automáticamente entre los núcleos/máquinas ³. El efecto neto: Lokad puede escalar a surtidos de SKUs extremadamente grandes sin requerir que el cliente invierta en cantidades absurdas de RAM o en dispositivos especializados. De hecho, enfatizan que se requiere poco hardware para funcionar – evitando situaciones en las que “hacer clic en un botón de ejecución cuesta cientos de dólares” en tarifas de computación en la nube ⁴. Este es un punto sutil pero crucial: lo diferencia de algunos sistemas empresariales pesados que, aunque técnicamente pueden manejar big data, lo hacen a gran costo. El enfoque de Lokad se asemeja más a una tubería optimizada para big data, similar a Apache Spark o Google BigQuery, pero diseñada específicamente para cálculos de cadena de suministro. Este enfoque en la eficiencia mantiene la solución rentable a medida que escala – un gran plus para los eTailers con millones de registros.

El manejo de fijación de precios y surtido por parte de Lokad no se realiza mediante módulos separados, sino a través de la misma lógica de optimización. Dado que la plataforma se basa esencialmente en código, se pueden modelar las interacciones. Por ejemplo, se puede escribir un script que diga: “para cada producto, considera la demanda probabilística a diferentes puntos de precio, ten en cuenta la disponibilidad de stock y el tiempo de reabastecimiento, y luego elige el precio que maximice el margen esperado menos el costo de mantenimiento, sujeto a que no se produzca faltante de stock con demasiada frecuencia” – esta es una descripción simplificada, pero ilustra que la fijación de precios y el inventario pueden decidirse conjuntamente. Si un producto tiene exceso de inventario, el código podría decidir aplicar un descuento para acelerar las ventas; si es escaso, podría aumentar el precio para asignar el inventario a los clientes que pagan más. Pocos otros proveedores permiten este nivel de interacción. La solución de Lokad básicamente genera sus propias políticas de decisión hechas a la medida basadas en los datos del comerciante.

Los efectos de canibalización y sustitución se manejan de forma natural si se proporcionan los datos correctos. Por ejemplo, se puede incorporar una entrada que indique: “si el artículo A no está disponible, ¿cuánto de su demanda se dirige al artículo B?” – tales relaciones pueden aprenderse de datos históricos (analizando faltantes de stock pasados o cambios en el surtido) y luego integrarse en la optimización. Debido a que Envision es un lenguaje de programación completo, estas dinámicas de demanda compleja pueden codificarse. La documentación de Lokad indica que lo hacen activamente: el sistema “descubre correlaciones entre productos, canales y períodos de tiempo” y calcula las decisiones en consecuencia, en lugar de asumir que cada SKU es independiente ¹⁰. No se basa en una extrapolación simplista de series temporales; calcula distribuciones de probabilidad completas para la demanda que tienen en cuenta promociones, faltantes de stock, cambios estacionales, etc. ¹¹. Al capturar estos factores (incluyendo cuando se perdió demanda por falta de stock), Lokad evita el clásico problema de garbage-in al hacer forecast con datos de ventas sesgados.

Otro ámbito en el que Lokad destaca es la inteligencia competitiva e integración de datos externos. La plataforma puede ingerir cualquier dato que sea relevante – por ejemplo, precios de competidores, tráfico web, incluso calendarios de campañas de marketing – como señales de entrada adicionales. Mencionan explícitamente la capacidad de incorporar “señales externas como los precios de competidores” y calendarios de marketing, y de experimentar fácilmente con nuevos algoritmos o entradas gracias al diseño programático ¹². En términos prácticos, si una empresa eCommerce tiene, por ejemplo, datos extraídos de los precios de competidores o sabe que el nivel de stock de un socio del marketplace es un indicador, puede conectarlo al modelo de Lokad para refinar las decisiones. Esto es mucho más flexible que la mayoría de las soluciones preconfiguradas que podrían manejar solo datos internos. Habla de un enfoque de “caja de cristal”: en lugar de ocultar la lógica, Lokad te permite hacerlo a la medida. Dicho esto, el enfoque de Lokad requiere un Supply Chain Scientist para configurarlo – no es una interfaz de usuario de apuntar y hacer clic para un novato. Esto podría verse como una desventaja para algunos; sin embargo, la recompensa es una solución que se ajusta exactamente a la empresa y puede automatizar verdaderamente las decisiones dadas las reglas únicas del negocio.

Automatización y autonomía: Lokad es, posiblemente, el planificador de supply chain más cercano a estar “totalmente robotizado” dentro de este grupo. La filosofía es que, una vez que los scripts (lógica) están configurados y validados, el sistema puede funcionar diariamente (o intradiariamente) y producir decisiones recomendadas sin intervención humana. Muchos usuarios de Lokad confían efectivamente en que produzca órdenes de compra y sugerencias de precios que los planificadores luego revisan brevemente o incluso ejecutan automáticamente. Debido a que el sistema es auto-adaptativo (reentrena los forecast cada día con los datos más recientes y re-optimiza en consecuencia), no requiere ajuste manual de parámetros. De hecho, Lokad critica de manera bastante enfática el hábito de la industria de ajustes interminables – destacan que su sistema “no se basa en métodos simplistas de series temporales” y funciona sin ajustes manuales constantes por parte de los usuarios ¹⁰. La mayor tarea de ajustar por estacionalidad, eventos o demanda errática la realizan los algoritmos, no los planificadores que modifican los forecast. Un aspecto clave es la acción: Lokad produce decisiones (o recomendaciones accionables) en lugar de solo diagnósticos. Por ejemplo, en lugar de simplemente señalar que un cierto artículo podría tener un faltante de stock (como hacen algunos dashboards de “torre de control”), recomendará directamente una cantidad de pedido o un cambio de precio para solucionarlo. Su objetivo es “recomendar acciones correctivas en lugar de simplemente mostrar una alerta”, lo cual es crucial si se desea una operación sin supervisión. En un entorno eCommerce de rápido movimiento, un sistema que simplemente te dice que hay un problema no es suficiente – quieres que te indique qué hacer al respecto, o incluso que lo ejecute. Lokad está construido para hacer lo último.

Dado este elogio, ¿dónde se debería ser escéptico respecto a Lokad? La principal advertencia es que el enfoque de Lokad es altamente personalizado y técnico. No es un SaaS plug-and-play donde lo enciendes y de inmediato ves una interfaz de usuario agradable con todas las respuestas. Exige un cierto nivel de madurez en los datos y confianza en métodos cuantitativos por parte de la empresa usuaria. También existe una dependencia implícita en el equipo de Lokad (los “Supply Chain Scientists”), especialmente durante la configuración inicial – efectivamente, actúan como tu equipo extendido para implementar la solución. Este es un modelo diferente al de, por ejemplo, instalar un software bien definido. Si un cliente no está preparado para comprometerse en ese proceso colaborativo y con alto contenido de ingeniería, podría tener dificultades. Sin embargo, este modelo es también lo que permite la profundidad de la optimización. Es un clásico compromiso: flexibilidad y potencia contra facilidad de uso. Lokad claramente optimiza para la potencia y la flexibilidad.

Desde una perspectiva de marketplace, la propuesta de valor de Lokad parece particularmente alineada con las necesidades de eCommerce. Las empresas eCommerce enfrentan muchos desafíos – faltantes de stock, excesos de inventario, picos volátiles de demanda debido a promociones o éxitos de influencers, etc. – y a menudo recurren a ensamblar herramientas (dashboards de BI, scripts de Python ad-hoc, etc.) para suplir las lagunas dejadas por su ERP o WMS. Lokad se posiciona esencialmente como la capa especializada que recoge todas esas señales y genera un plan casi óptimo. Se contrastan explícitamente con las herramientas simplistas proporcionadas por marketplaces o ERPs, señalando que estas “abordan solo una fracción” de lo que enfrentan las empresas eCommerce ¹³ ¹⁴. Por ejemplo, un marketplace de Amazon podría darte un forecast de demanda para la próxima semana – pero no integraría tus costos de supply chain ni tu inventario de múltiples almacenes. La tecnología de Lokad está diseñada para manejar cada señal relevante hasta el nivel SKU, sin fallar, y sin que los usuarios tengan que manipular manualmente hojas de cálculo ¹⁵. Esta es una propuesta de valor fuerte si se entrega según lo anunciado.

Para resumir Lokad: Se ubica en la cima de nuestra lista por su capacidad de optimización holística y tecnología avanzada. Cumple de manera directa con el criterio de optimización conjunta – el inventario, los precios y más pueden optimizarse juntos mediante su plataforma programática. Aprovecha forecast probabilístico y drivers económicos (ya realizaban forecast cuantiles antes de que fuera tendencia, como lo evidencia su éxito en la competencia M5 ⁶) y no rehúye efectos complejos como la sustitución o las correlaciones multicanal. Su arquitectura es escalable y consciente de costos, evitando la trampa del computing en memoria a la fuerza bruta ³ ⁴. La automatización es muy alta, requiriendo un ajuste manual mínimo y enfocándose en producir decisiones, no solo insights ¹⁶. El escepticismo que se pudiera aplicar a Lokad está menos relacionado con si la tecnología funciona – la evidencia sugiere que sí – y más bien con si una organización está dispuesta a adoptar una solución tan cargada de data science. También está la cuestión del historial a gran escala; Lokad es más pequeño que algunos competidores, aunque cuenta con clientes notables (por ejemplo, distribuidores industriales de postventa, eTailers de moda, etc., según sus estudios de caso). Dado lo anterior, Lokad obtiene una clasificación superior como un proveedor de optimización eCommerce verdaderamente de vanguardia en nuestro estudio.

2. RELEX Solutions – Optimización Minorista Potenciada por AI (con salvedades)

RELEX Solutions es un proveedor nacido en Finlandia que ha ascendido rápidamente en el ámbito de la planificación minorista, a menudo mencionado en la misma línea que gigantes tradicionales en forecast y reposición. RELEX ofrece una plataforma unificada que abarca el forecast de demanda, la reposición de inventario, la asignación, el surtido, la programación de personal y, recientemente, la optimización de precios y promociones. Su fortaleza principal ha sido en grocery y retail (incluyendo tiendas físicas), pero también comercializan activamente a actores de eCommerce, enfatizando su capacidad para planificar a través de canales en línea y fuera de línea. Para los usuarios puramente de eCommerce, el valor de RELEX reside en su planificación integral – asegurando el inventario correcto en el lugar indicado, con el precio y las promociones adecuados, utilizando algoritmos avanzados para reaccionar ante los cambios en la demanda.

RELEX promueve de manera intensa su uso de AI y machine learning. De hecho, su CEO Mikko Kärkkäinen es un ferviente defensor de la “AI pragmática” en el retail. Según Kärkkäinen, “los sistemas de gestión de inventario impulsados por AI procesan cientos de factores que influyen en la demanda” para aumentar la precisión del forecast ¹⁷. Incluso destaca que algo como los datos meteorológicos no es un solo factor, sino “cientos de factores diferentes” (temperatura, humedad, etc.) que sus modelos de machine learning consideran ¹⁸. Esto ejemplifica el enfoque de RELEX: lanzar una red amplia para captar señales predictivas (clima, promociones, días festivos, tendencias en redes sociales, etc.) y utilizar ML para correlacionarlas con las ventas. El beneficio es que el sistema puede detectar patrones complejos (por ejemplo, cómo una ola de calor repentina afecta la demanda de ciertas bebidas en combinación con que sea un fin de semana festivo). La visión escéptica, sin embargo, es que promocionar “cientos de factores” podría ser más marketing que una mejora significativa. En forecast, después de cierto punto, agregar más entradas ofrece rendimientos decrecientes o incluso puede degradar la precisión si el modelo se sobreajusta al ruido. Además, convierte al modelo en una caja negra – es prácticamente imposible para un humano entender un modelo que realmente utiliza cientos de variables. RELEX intenta contrarrestar la preocupación de la caja negra abogando por un enfoque de “caja de cristal” (transparencia en AI). Han mencionado proporcionar visibilidad en los forecast y no solo un resultado, permitiendo a los planificadores ver los impulsores clave. Pero, de forma realista, una red neuronal o un modelo de gradient boosting con cientos de características no será completamente interpretable. Los planificadores tendrán que confiar en el sistema. Este es un compromiso general con AI/ML: RELEX está del lado de “lanzar muchos datos al problema y dejar que los algoritmos lo resuelvan.”

¿Da esto resultados? Los clientes de RELEX a menudo reportan una mejora en los forecast y menos faltantes de stock, especialmente en situaciones promocionales y estacionales donde los métodos tradicionales tenían dificultades. Por ejemplo, RELEX integra forecast meteorológicos y ha afirmado una reducción de hasta el 75% en el error del forecast para ciertos productos sensibles al clima durante condiciones meteorológicas inusuales ¹⁹. Tomamos estas afirmaciones específicas con cautela – podrían ser seleccionadas. No obstante, es probable que el enfoque de RELEX añada valor en el forecast a corto plazo (“demand sensing”) al ajustar los forecast basándose en la información más reciente. En esencia, sus modelos de ML están afinando continuamente el forecast base con nuevas señales de datos. Esto es similar a lo que algunos llaman demand sensing (usar datos casi en tiempo real para actualizar los forecast a corto plazo). RELEX, en sus materiales, integra el demand sensing en su forecast de ML más amplio en lugar de tratarlo como un módulo separado. Ellos impulsan el “re-forecast continuo y automatizado” a medida que las situaciones cambian.

En el frente de la optimización conjunta, ¿qué tan bien cubre RELEX la optimización de precios y surtido además del inventario? Históricamente, RELEX fue más fuerte en reposición y asignación (asegurando que las tiendas o DCs no se queden sin stock). La planificación de surtido (decidir qué productos van a qué tiendas o qué SKUs llevar) también formaba parte de su oferta, al igual que la optimización de planogramas (planificación del espacio). La optimización de precios era una brecha hasta hace poco – pero en 2022, RELEX introdujo una capacidad de optimización de precios impulsada por AI ²⁰ ²¹. La están posicionando como integrada sin inconvenientes con su planificación de promociones. Por ejemplo, su herramienta de planificación de promociones y la de optimización de precios comparten los mismos datos y UI, de modo que un minorista puede planificar una promoción y el sistema puede recomendar la profundidad de descuento óptima, el momento, etc., considerando automáticamente las implicaciones en el inventario. Esto ciertamente se encamina hacia la optimización conjunta. Sin embargo, no está claro si RELEX realmente optimiza el precio y el inventario juntos o si aún lo hace de forma secuencial (primero decide el precio y luego se ajusta el flujo de inventario). En una optimización conjunta ideal, se considerarían las restricciones de inventario al fijar precios (por ejemplo, no promover agresivamente un artículo si la supply chain está limitada). Es probable que la plataforma integrada de RELEX habilite ese pensamiento interfuncional – por ejemplo, su sistema notaría “no tenemos suficiente stock en el DC para apoyar esta promoción en todas las tiendas” y podría marcarlo o ajustarlo. Mencionan alinear los precios y promociones con la supply chain para asegurar que los planes sean ejecutables ²². Por lo tanto, RELEX es consciente de la necesidad de romper los silos.

Una perspectiva interna: el atractivo de RELEX es que reúne todo (demanda, supply, operaciones) en una sola plataforma para el usuario. Por ejemplo, los merchandise planners pueden ver forecast compartidos y restricciones entre departamentos ²². Esto significa que un planificador puede entender el impacto que una decisión de precios tendrá en la supply chain y viceversa. Esa visibilidad es una gran mejora sobre las herramientas aisladas. Pero la visibilidad no es lo mismo que una optimización totalmente algorítmica. Sospechamos que, si bien RELEX ofrece una experiencia de usuario y un modelo de datos muy coherentes, parte de la toma de decisiones podría seguir siendo escalonada. La optimización de precios podría producir un precio ideal y, a partir de ahí, el módulo de inventario planificaría en torno a él. La integración estrecha asegura que no entren en conflicto, pero no necesariamente resuelve un único problema de optimización que maximice el beneficio considerando los costos de inventario simultáneamente. Lograr lo último es complejo y no muchos proveedores (excepto quizás Lokad, como se discutió) lo intentan de forma explícita.

Desde el punto de vista de la arquitectura tecnológica, RELEX es bastante avanzado. Construyeron su propio motor de base de datos en memoria en los primeros días (una DB columnar optimizada para series temporales y datos jerárquicos) que les permitió calcular forecast para miles de tiendas por SKUs rápidamente. Muchos estudios de caso citan a RELEX por reemplazar hojas de cálculo y sistemas heredados, siendo inmediatamente capaz de manejar una granularidad de datos mucho mayor (como pasar de una planificación semanal a diaria, o de una planificación única a una específica por tienda). Para eCommerce, esto significa que RELEX probablemente puede gestionar forecast a nivel SKU para una tienda online global sin problema. Tienen despliegues en la nube y pueden escalar. No encontramos quejas específicas sobre el costo de la tecnología de RELEX; si acaso, se enorgullecen de su computación eficiente (sus fundadores académicos optimizaron mucho los algoritmos). Una de las ideas que tienen es el concepto de “Live database” en memoria, que, si se configura mal, podría requerir mucha RAM – pero eso es especulativo. En general, la escalabilidad de RELEX no ha sido una señal de alerta en el mercado; atienden a grandes cadenas de grocery con decenas de miles de SKUs y muchas tiendas, lo cual es analógico o incluso mayor en volumen de datos que muchos e-tailers.

Automatización y el papel de los planificadores: RELEX a menudo habla de “planificación autónoma” pero también de “decisiones aumentadas.” No posicionan su herramienta como una caja negra que elimina al planificador. De hecho, enfatizan la usabilidad – por ejemplo, su UI, tableros configurables y gestión de excepciones. El sistema generará automáticamente órdenes de compra o recomendaciones de transferencia, pero normalmente un planificador las revisa y aprueba (especialmente en las etapas tempranas de adopción). RELEX tiene un concepto de “forecast exceptions” donde, si el forecast de la IA se desvía demasiado debido a alguna anomalía, lo marca. También cuentan con una capacidad de simulación donde los planificadores pueden ver por qué el sistema sugiere algo (al menos en términos generales, como “porque el clima estuvo caluroso, predecimos +50% lift”). Mikko Kärkkäinen ha declarado: “las soluciones best-in-class aprovechan la IA pragmática y el poder computacional para optimizar tareas… de manera autónoma sin intervención humana” ²³, y también describe “una planificación minorista autónoma que se autoaprende y se autoajusta para derribar los silos” ⁵. Así que, al menos en teoría, RELEX apunta a un sistema en gran medida auto-conducido. Seguimos siendo algo escépticos respecto a la autonomía completa aquí: los grandes minoristas que usan RELEX aún tienen equipos de planificación. Pero es probable que esos equipos ahora gestionen por excepción, lo cual es una forma de autonomía parcial.

Una de las contradicciones a tener en cuenta con RELEX (y proveedores similares) es la promesa de flexibilidad extrema y automatización extrema. Afirman que el sistema es muy flexible (por ejemplo, se puede configurar cómo funcionan las reglas de pricing, o ajustar los modelos de forecast), sin embargo, también aseguran que se autoajusta. Existe una tensión: si un usuario puede anular manualmente mucho, en la práctica el sistema podría depender de esos ajustes manuales. Si realmente confían en la IA, deberían tener que anular menos y menos. La referencia de RELEX a “self-tuning” implica lo último – que el sistema requerirá menos ajustes manuales de parámetros con el tiempo ⁵. Vimos que el enfoque de RELEX convierte a los planificadores en más supervisores. Por ejemplo, un artículo señaló que el sistema de RELEX liberó a los planificadores de tareas manuales para centrarse en movimientos estratégicos ²⁴. Aun así, una fuente de SelectHub que recopiló reseñas indicó que algunos usuarios encontraron partes de RELEX “pesadas” y tuvo problemas como el forecasting de ciertas restricciones (límites de flete) que requerían soluciones alternativas ²⁵. Esto indica que no es pura magia; los usuarios aún se topan con situaciones en las que deben intervenir o donde la herramienta no funciona con la fluidez esperada.

Problemas o preocupaciones conocidos: No existen casos documentados públicamente de “fallas” para RELEX como los que hay para algunos (sin titulares de demandas). La empresa generalmente goza de una percepción positiva. Sin embargo, el charla interna anonimizada a veces menciona que implementar RELEX en entornos muy grandes y complejos puede sacar a la luz problemas. Por ejemplo, la integración de datos puede ser un desafío (garbage in, garbage out – si los datos del cliente son un desastre, RELEX podría generar planes deficientes y la culpa recaería ya sea en la herramienta o en los datos). Además, el crecimiento agresivo de RELEX (han incorporado a muchos clientes rápidamente) significa que algunos clientes podrían no recibir el mismo acompañamiento que, por ejemplo, ofrece Lokad. Esto no es una crítica al software per se, sino a los resultados en el mundo real: ¿cuántos proyectos de RELEX cumplen los KPIs prometidos? A los proveedores les encanta citar mejoras en el mejor de los casos (“¡X% de reducción de stock at Y customer!”), pero rara vez se mencionan casos en los que los números no se materializaron. Sospechamos que RELEX, al igual que todos los proveedores, ha tenido algunos proyectos que no cumplieron con lo prometido, posiblemente debido a una mala gestión del cambio o a que el minorista no confió lo suficiente en el sistema para actuar en consecuencia. En una cumbre de socios, incluso Blue Yonder admitió que la ineficaz gestión del cambio y los problemas de datos causan la mayoría de las fallas en los proyectos ²⁶ – lo mismo probablemente se aplique a las implementaciones de RELEX.

Otro aspecto destacado: RELEX tiende a incorporar muchos datos externos, incluyendo cosas como Google Trends, datos de ubicación móvil para predicciones de footfall, etc. Para un actor de eCommerce, algunos de estos (como footfall) son irrelevantes, pero otros (clima, tendencias) no lo son. Uno debería preguntarse: ¿realmente necesito todos estos feeds de datos? Para algunos e-businesses, modelos simples basados en el historial de ventas podrían ser casi igual de buenos. RELEX sin duda venderá la idea de que más datos generan mejores forecast. Los resultados de la competencia M5 (en la que, hasta donde sabemos, RELEX no participó públicamente) mostraron que los modelos sofisticados sí superaron a los más simples, pero a menudo por márgenes pequeños. Los métodos principales eran a menudo conjuntos de muchos modelos, no muy diferentes a lo que RELEX podría estar haciendo internamente. Pero, curiosamente, un enfoque puramente de machine learning no aplastó categóricamente a los métodos tradicionales en esos concursos – una combinación de modelos estadísticos cuidadosamente ajustados tendía a ganar. Así que, si contrastamos las afirmaciones de RELEX con benchmarks como M5: vemos que el forecast probabilístico es, en efecto, valioso (lo cual ellos hacen), pero también vemos que no existe una sola fórmula mágica entre los enfoques principales – se trata de un modelado cuidadoso. En ausencia de que RELEX publique su precisión en conjuntos de datos estándar, nos mantenemos cautelosos. El consejo del escéptico para cualquiera que considere RELEX es: solicite evidencia específica de mejora y defina una línea base clara. Por ejemplo, si RELEX afirma “hemos mejorado la precisión del forecast en un 30%,” aclare “¿30% relativo a qué métrica y línea base?” Muchas veces, los proveedores miden el aumento en comparación con un escenario que halaga su herramienta (por ejemplo, comparado con forecasts ingenuos o con un mal año). La orientación de este estudio: exija claridad en las líneas base para cualquier afirmación de rendimiento.

En resumen, RELEX Solutions se posiciona como un proveedor destacado porque aborda las áreas clave (demanda, inventario, pricing) de manera integrada y utiliza extensamente técnicas modernas de AI/ML. Sus fortalezas incluyen un forecast muy granular que tiene en cuenta una miríada de factores, fuertes capacidades de promoción y planificación estacional, y una plataforma unificada que ofrece a todas las partes interesadas una única fuente de verdad. Cumple en escalabilidad (demostrada en grandes minoristas), en el manejo de canibalización (a través de modelos avanzados de forecast que consideran efectos cruzados entre productos ²⁷), en marketplace/omni-channel (el sistema puede planificar para online y offline de manera concurrente y, probablemente, incorporar datos de competidores si se proporcionan). RELEX también impulsa la automatización, con afirmaciones de modelos autoajustables y decisiones autónomas, aunque en la práctica sigue habiendo cierta supervisión del usuario. Las principales advertencias son la complejidad y opacidad que conlleva su enfoque intensivo en IA – los usuarios deben confiar en la caja negra hasta cierto punto – y la necesidad de separar el bombo publicitario de la realidad en su marketing. Valoramos a RELEX muy positivamente, pero con un asterisco: es una herramienta poderosa, pero que requiere una implementación cuidadosa y una cultura orientada a los datos para aprovecharla al máximo. También animamos a los usuarios potenciales a estar atentos al “AI washing” en la industria; el mensaje de RELEX es de los más creíbles (ya que cuentan con tecnología real bajo el capó), pero incluso las declaraciones de Mikko sobre “cientos de factores” ¹⁷ deben ser vistas más como entusiasmo por la IA que como garantía de resultados drásticamente mejores que los de un competidor. En un contexto de eCommerce, RELEX ciertamente puede hacer el trabajo, solo asegúrese de medir sus resultados rigurosamente y de vigilar que todas esas características sofisticadas se estén utilizando realmente en su caso o simplemente queden inactivas en el software.

3. Blue Yonder – Juggernaut legado transformándose (Afirmaciones vs. Realidad)

Blue Yonder (anteriormente conocido como JDA Software) es un gigante en software de supply chain, con décadas de historia en sistemas de planificación para el comercio minorista y la fabricación. Cuenta con una suite integral que abarca forecast, reposición, gestión de almacenes, transporte, fuerza laboral y precios (tras adquirir al especialista en pricing Revionics en 2020). Para los actores de eCommerce, Blue Yonder ofrece soluciones originalmente desarrolladas para grandes minoristas y empresas de CPG – piénselo como el coloso empresarial en este ámbito. Sin embargo, con ese legado vienen tanto fortalezas (funcionalidad robusta, escalabilidad, experiencia en el sector) como debilidades significativas (tecnología desactualizada en algunas partes, problemas de integración derivados de múltiples adquisiciones y un historial que incluye algunos fracasos de alto perfil).

En términos de optimización conjunta, la historia de Blue Yonder es algo mixta. Ellos sí cuentan con componentes para todas las piezas: por ejemplo, su Luminate Demand Edge para forecast, Luminate Allocation/Replenishment para inventario, y Revionics para pricing. Sobre el papel, se podrían usar los tres y lograr una estrategia coordinada – por ejemplo, el forecast alimenta tanto el plan de inventario como los modelos de optimización de precios, y la optimización de pricing puede incorporar la elasticidad de la demanda (que es esencialmente forecast de la demanda a diferentes puntos de precio). Blue Yonder ciertamente comercializa la idea de “end-to-end, from planning to execution” unificada bajo su plataforma Luminate. En la práctica, sin embargo, muchos de estos módulos evolucionaron por separado y solo recientemente se han integrado. El motor de optimización de pricing de Revionics, por ejemplo, tiene su propia herencia y fue incorporado tras la adquisición. El desafío de Blue Yonder es lograr que esto se sienta como una solución coherente. La compañía reconoció que históricamente tenía una suite fragmentada; como resultado, en 2023 anunciaron una gran transformación arquitectónica: pasar a un “single data model and application platform” en la nube de Snowflake ²⁸. Esto es algo importante – básicamente, reingeniar sus productos para que todos lean/escriban desde un gran repositorio de datos en la nube (Snowflake) de modo que los silos de datos desaparezcan. El CEO declaró una visión de un “supply chain operating system for the world” en el que todas las aplicaciones de BY comparten los datos de manera fluida ²⁸.

Consideramos esta visión como prometedora y problemática. Prometedora, porque si se logra, de hecho solucionaría muchos problemas de integración (por ejemplo, ya no habría interfaces batch entre la planificación de la demanda y el pricing – literalmente, mirarían los mismos datos en Snowflake). Problemática, porque es sumamente ambiciosa y arriesgada. Incluso la firma consultora asociada de Blue Yonder señaló, “Aunque visionario, creemos que eliminar por completo las integraciones puede ser demasiado optimista para la mayoría de los clientes.” ²⁹. Los clientes tienen datos en muchos lugares, y no todo se alojará ordenadamente en Snowflake, por lo que aún se necesitarán integraciones personalizadas para sistemas que no sean de Blue Yonder ²⁹. En resumen, la estrategia de Blue Yonder es un trabajo en progreso – una respuesta a ser considerados como “legacy”. Explicitaron que no forzarán “eventos de precipicio” (abandonar la tecnología antigua de la noche a la mañana) sino que gradualmente convertirán en microservicios los módulos legacy, permitiendo a los clientes migrar a su propio ritmo ³⁰ ³¹. Esto significa que, actualmente, un cliente de Blue Yonder podría seguir utilizando, por ejemplo, la antigua planificación de demanda de JDA on prem, con una integración a Revionics en cloud. La plataforma completamente unificada podría estar a un par de años de su disponibilidad general. Mientras tanto, la optimización conjunta es más manual con Blue Yonder: se pueden usar sus herramientas de forma tandem, pero a menudo depende del usuario coordinar (por ejemplo, asegurarse de que las acciones del equipo de pricing se integren en el plan de inventario).

Blue Yonder cumple en marcar muchas casillas tecnológicas en el papel: ahora integran machine learning en el forecast (aprovechando tecnología de la empresa Blue Yonder GmbH, que adquirieron en 2018, y que se especializaba en AI para el retail). Afirman utilizar “explainable AI, machine learning, e incluso generative AI” en diversas aplicaciones ³². Ciertamente, cuentan con algoritmos avanzados para aspectos como la optimización de reposición, la asignación, etc., desarrollados durante décadas. Pero se debe ser escéptico, ya que Blue Yonder también acumula una gran deuda técnica. Muchos de sus algoritmos centrales fueron desarrollados en los años 90 o a principios de los 2000 por i2 Technologies o JDA. Han sido mejorados, sí, pero hasta la reciente reescritura en la nube, gran parte funcionaba en arquitecturas antiguas (algunas soluciones necesitaban bases de datos Oracle, etc.). Así que, cuando Blue Yonder comercializa “planificación cognitiva impulsada por ML”, hay que preguntarse: ¿es verdaderamente tecnología nueva o es solo un nuevo branding? Por ejemplo, su planificación de demanda ahora podría usar ML para estimar aumentos en el forecast durante días festivos, lo cual es bueno, pero ¿está la arquitectura subyacente aprovechando de verdad el poder computacional en la nube de hoy, o está limitada por estar adaptada a un sistema legacy?

Un problema histórico concreto: Blue Yonder (JDA) adquirió i2 Technologies en 2010. i2 era conocida por soluciones intensivas en optimización, pero también por implementaciones fallidas en ocasiones. Famosamente, después de que JDA compró i2, Dillard’s (una gran tienda departamental) ganó una demanda por $246M alegando que el software de i2 no cumplió sus promesas ³³ ³⁴. Esto fue un gran golpe – esencialmente, el software y el proyecto fallaron tan estrepitosamente que el cliente recibió indemnizaciones que superaron 30 veces lo que pagó por el software. Esa saga, aunque ocurrida hace 15 años, resalta que incluso proveedores de alta reputación pueden cometer grandes errores si la tecnología promete de más o no se implementa adecuadamente. Blue Yonder tuvo que absorber ese costo y aprender lecciones (se espera). Esto subraya por qué mantenemos el escepticismo: los grandes proveedores pueden alardear de “productos de clase mundial” pero existe evidencia de que, en algunos casos, no funcionan como se anunciaban. Cada proveedor tiene fallas; Blue Yonder, al menos, tuvo una llevada a los tribunales públicos.

Para reconocer el mérito de Blue Yonder, se han mostrado más abiertos a la hora de abordar los problemas. En su cumbre de socios de 2023, discutieron abiertamente sobre “red projects” (implementaciones problemáticas) y concluyeron que las causas principales no eran los algoritmos per se, sino “la ineficaz gestión del cambio y los problemas con la migración/integración de datos” ²⁶. Señalaron que acertar en los datos y apoyar al cliente en la adaptación de los procesos era fundamental. Esta introspección es positiva – significa que Blue Yonder no es ajeno a las razones por las que los proyectos fracasan. También se alinea con nuestro tema central de análisis: a menudo, no es que las matemáticas estén equivocadas, sino que la integración en el mundo real es complicada. Que Blue Yonder identifique los desafíos de integración de datos es muy revelador: refleja la complejidad de su suite. Porque, si sus módulos estuvieran verdaderamente integrados sin fisuras, la migración de datos no sería un dolor de cabeza. El hecho de que lo sea implica que los clientes podrían haber tenido que realizar una reconciliación importante de datos para utilizar la suite completa. La capa unificada de datos de Snowflake tiene como objetivo solucionar esto, pero, como se dijo, es temprano.

Examinemos las capacidades actuales de Blue Yonder para un escenario de eCommerce:

Pronóstico de Demanda: Blue Yonder Luminate Demand (especialmente con Demand Edge) utiliza aprendizaje automático para incorporar muchos factores (clima, eventos, precios). También se han movido hacia forecast probabilísticos; al menos, soportan el uso de intervalos de confianza o cuantiles en la planificación. Un ejemplo de su blog: no usan IA simplemente para agregar factores a una línea base, sino para reconstruir el forecast desde cero cada día utilizando los datos más recientes, contabilizando automáticamente aspectos como cambios en el calendario y autocorregiéndose a medida que llegan nuevos datos reales ³⁵ ³⁶. Afirman que esto elimina la necesidad de que los planificadores mantengan ajustes manuales o perfiles para la estacionalidad – el modelo los aprende y se adapta ³⁶. Esto está muy en línea con la práctica de forecast de vanguardia. El enfoque de Blue Yonder aquí es sólido en teoría: aprendizaje continuo, reconocimiento de la incertidumbre (hablan sobre el riesgo de sobre/infra-forecast y los compromisos de costo ³⁷), y el uso de ML para detectar relaciones complejas (como cómo diferentes condiciones climáticas o promociones impulsan la demanda, sin que un humano codifique explícitamente esas relaciones).
Inventario y Reabastecimiento: Esto ha sido durante mucho tiempo una fortaleza de JDA/Blue Yonder. Ofrecen optimización de inventario de múltiples niveles (MEIO), lo que significa que pueden optimizar los niveles de stock a través de DCs y centros de cumplimiento para ecommerce, teniendo en cuenta tiempos de entrega, variabilidad en la demanda, etc., para alcanzar los niveles de servicio objetivo. Las herramientas de Blue Yonder pueden generar cantidades de pedido recomendadas, stocks de seguridad, y demás. Históricamente, estos algoritmos se basaban más en reglas/heurísticas o utilizaban programación lineal para problemas específicos. Probablemente ahora se están complementando con predicciones basadas en ML, pero la optimización central es probablemente una mezcla de investigación operativa y simulación. BY sin duda puede manejar la planificación de SKU a gran escala; muchos minoristas de Fortune 500 utilizaban JDA para el reabastecimiento en tienda, lo cual es análogo en escala a un gran almacén de e-comm que suministra a los clientes.
Surtido: Blue Yonder cuenta con herramientas de gestión de categoría que ayudan a decidir los surtidos (qué combinación de productos en qué tiendas). Para un jugador exclusivo de ecommerce, la planificación de surtido podría significar decidir qué nuevos productos listar o eliminar. Las herramientas de BY pueden usar atributos y datos de rendimiento para evaluar cambios en el surtido. Sin embargo, eso es típicamente un proceso estratégico periódico, no continuo.
Optimización de Precios: Con la adquisición de Revionics, Blue Yonder ganó un robusto motor de optimización de precios que se utiliza ampliamente en el retail (especialmente en cadenas de comestibles y mercancías generales) para establecer precios base, descuentos promocionales y rebajas. Revionics utiliza IA para modelar la elasticidad del precio e incluso los impactos de precios competitivos, y luego recomienda cambios de precio que logran objetivos como el crecimiento del margen o de ingresos, considerando reglas de precios (por ejemplo, que los precios terminen en .99, etc.). Como parte de Blue Yonder, Revionics ahora se conoce como Luminate Pricing. En teoría, ese motor, combinado con los forecast de demanda de Blue Yonder, cierra el ciclo – puedes simular cómo un cambio de precio afectará la demanda y el inventario, y elegir un precio óptimo. Blue Yonder comercializa esto como “autonomous pricing powered by AI”, capaz de funcionar tan a menudo como sea necesario (incluso intradiariamente para ecommerce si se desea).

Una gran pregunta: ¿Qué tan bien trabajan estas piezas en conjunto hoy en día? Blue Yonder afirma que sí. Por ejemplo, podrían decir que su solución de precios puede tomar forecast de su solución de demanda y generar precios que la solución de inventario luego utiliza para planificar pedidos. Pero si esas integraciones no son en tiempo real o requieren trabajo IT personalizado, el ciclo puede no ser tan ajustado como se esperaría. Realísticamente, un usuario de Blue Yonder en ecommerce en 2023 podría usar la herramienta de precios separadamente de la herramienta de supply, quizás con actualizaciones por lotes semanales de la elasticidad del forecast. Eso es planificación conjunta, pero no el santo grial de la optimización conjunta instantánea.

Sobre las afirmaciones de AI/ML, Blue Yonder a veces sufre de excesos de palabras de moda en el marketing. Utilizan términos como “cognitive”, “machine learning-driven”, etc. Debemos inspeccionar si hay sustancia. Existe cierta evidencia de sustancia: por ejemplo, Blue Yonder (la subsidiaria alemana originalmente) había desarrollado algoritmos que se publicaron (su equipo ganó una temprana competencia de forecast en retail en 2014 utilizando neural nets). Además, el portafolio de patentes de Blue Yonder es grande (más de 400 patentes) lo que indica una gran inversión en I+D ³⁸. Sin embargo, la cantidad de patentes no equivale a la calidad del producto – solo demuestra que han probado muchas técnicas. La perspectiva escéptica es pedir a Blue Yonder resultados específicos: por ejemplo, ¿participaron en M5 o en algún benchmark neutral? No públicamente. ¿Existen estudios de caso con cifras concretas de antes y después? Los tienen algunos, pero a menudo los estudios de caso de proveedores son optimistas y carecen de claridad en la línea base. Blue Yonder dice cosas como “X minorista vio un aumento del Y% en beneficios utilizando nuestro pricing” – pero sin contexto, eso es marketing.

También se debe considerar el costo y la complejidad con Blue Yonder. Estos son grandes sistemas empresariales. La implementación puede llevar muchos meses o años, e involucrar no solo la configuración del software, sino también el rediseño de procesos de negocio. Blue Yonder típicamente requiere ya sea sus servicios profesionales o una firma asociada para implementar. El costo total de propiedad puede ser muy alto (licencia + servicios + IT). Para un jugador puro de ecommerce, especialmente uno de tamaño mediano, Blue Yonder podría ser excesivo o demasiado lento de implementar en comparación con soluciones SaaS más ágiles. Incluso grandes compañías a veces se resisten: un evento significativo en la industria fue Lidl (el gran minorista global) cancelando un proyecto SAP de €500M en 2018 después de que no cumpliera con los requerimientos ³⁹. Eso fue SAP, no Blue Yonder, pero ilustra que proyectos enormes pueden fracasar, consumiendo presupuestos enormes. Los proyectos de Blue Yonder son igualmente complejos; de hecho, su socio JBF Consulting señaló que el competidor Manhattan Associates tomó un enfoque diferente (requería reimplementación para su nueva plataforma), mientras que BY está intentando una migración más suave ⁴⁰. El hecho de que Manhattan eligiera un camino de “reimplementar para ir a nueva tecnología” sugiere que estas transiciones no son triviales. Blue Yonder está tratando de evitar actualizaciones de pesadilla evolucionando lentamente – pero eso también significa que los clientes pueden estar usando una tecnología que no es del todo moderna, esperando lo nuevo.

Desde el punto de vista de la automatización, Blue Yonder hoy es probablemente menos automatizado de lo que Lokad o RELEX pretenden ser. Muchos clientes de BY usan las herramientas para generar recomendaciones que luego los planificadores aprueban o ajustan. Blue Yonder impulsa el concepto de una “autonomous supply chain” (especialmente desde que fue adquirida por Panasonic en 2021, hablan de conectar datos de IoT a decisiones automatizadas) ⁴¹. Pero es seguro decir que gran parte de su base de clientes aún está en un modo híbrido: confiando en el sistema para algunas decisiones y anulando manualmente otras. Por ejemplo, un escenario común es que el sistema sugiere órdenes, pero un planificador revisa las excepciones (tal como ocurre con RELEX). O el sistema de precios sugiere cambios, pero un gerente de merchandising los revisa, quizás rechazando algunos que no se alineen con la estrategia de marca. El software puede hacer mucho, pero las empresas tienen procesos establecidos que no cambian de la noche a la mañana.

Inteligencia competitiva y marketplaces: La solución de precios de Blue Yonder (Revionics) sí incorpora datos de precios competitivos – tiene una función para competitive response y puede incorporar los precios de los rivales para ajustar los tuyos ⁴². Así que para ecommerce, si tienes un feed de precios de competidores, Revionics puede incluir eso en su optimización (por ejemplo, no fijar precios por encima de un competidor por más de X% para mantener la imagen de precio, o igualar el precio más bajo cuando sea necesario). Eso es un plus en la optimización conjunta de precios. En los marketplaces, Blue Yonder no tiene específicamente un módulo de gestión de marketplaces como lo hacen algunos proveedores específicos de e-comm (como herramientas tipo channel advisor para Amazon). Así que se podría usar Blue Yonder para la planificación central, pero aún necesitarías una herramienta separada para gestionar tácticas específicas de marketplaces (publicidad, buy-box, etc.). Esto está fuera del alcance de Blue Yonder y no es una crítica, solo una nota de que el ecommerce tiene facetas que estos proveedores tradicionales no abordan (Lokad o RELEX tampoco cubren la puja de anuncios, etc., para ser justos).

Dada la escala y el legado de Blue Yonder, también se debe examinar las contradicciones internas en su comunicación. Por ejemplo, Blue Yonder podría promocionar “real-time personalization and pricing” en su plataforma de comercio, sin embargo, sus soluciones de planificación históricamente se ejecutaban en ciclos batch (planificación nocturna, replanning semanal, etc.). Se están moviendo hacia el uso de datos en tiempo real (su asociación con Snowflake es en parte para habilitar el intercambio de datos casi en tiempo real). Pero si un proveedor afirma “real-time dynamic pricing and inventory optimization”, pregúntate: ¿significa que el sistema se recalcula de forma continua o simplemente que puede responder rápidamente si se le activa? ¿Y realmente se necesita tiempo real para decisiones de surtido? Probablemente no – eso es más estratégico. Así que un oído crítico notará cuando el lenguaje de marketing sea incoherente. El amplio marketing de Blue Yonder a veces cae en la trampa de prometerlo todo (desde estrategia a largo plazo hasta ejecución instantánea).

Preocupación por el costo de Snowflake: Debemos resaltar un punto sutil pero importante: que Blue Yonder se construya sobre Snowflake podría cambiar el modelo de costos para los clientes. En lugar de licencias tradicionales, los clientes podrían terminar pagando por el uso de la nube (créditos de Snowflake) basado en el volumen de datos y la frecuencia de consultas. Si las aplicaciones de Blue Yonder realizan cálculos intensivos en Snowflake, la factura de Snowflake del cliente podría dispararse. Es análogo a la antigua facturación de IBM mainframe por MIPS: pagas más cuanto más lo usas, lo que puede desincentivar el uso completo del sistema. Blue Yonder y Snowflake presumiblemente acordarán algún esquema de precios, pero el usuario debe estar atento a “bill shock” si los escenarios de planificación se ejecutan muy a menudo sobre grandes volúmenes de datos. Es una consideración muy real porque la planificación de supply chain puede ser computacionalmente intensiva (especialmente si se realizan simulaciones de escenarios o cálculos probabilísticos). Un proceso ineficiente en Snowflake podría consumir muchos créditos. Probablemente Blue Yonder ha pensado en esto (tienen que hacerlo funcionar comercialmente), pero es algo a tener en cuenta. Un modelo de costo desalineado con el valor empresarial (como cobrar por los datos procesados en lugar de por el resultado) recuerda a las trampas de épocas anteriores.

En conclusión, Blue Yonder se sitúa justo por debajo de las nuevas soluciones pure-play en términos de cumplir con la visión “next-gen”. Indudablemente tiene una funcionalidad rica y muchos despliegues exitosos, pero desde una perspectiva escéptica y técnica, vemos una empresa en transición. Están tratando de modernizarse y, al hacerlo, hablan bien sobre IA, integración y automatización. Sin embargo, hasta que esa transformación se realice completamente, los clientes deben ser cautelosos respecto a las brechas entre los módulos y el esfuerzo real requerido para alcanzar los resultados prometidos. El conjunto de herramientas de Blue Yonder sin duda puede apoyar las operaciones de ecommerce (muchos grandes minoristas con negocios omnicanal usan BY también para su lado e-com), y su amplitud es inigualable (ninguno de los otros proveedores tiene un alcance tan amplio, incluyendo aspectos como logística). Sin embargo, si una empresa de ecommerce solo necesita optimización de demanda y de supply, Blue Yonder podría ser demasiado pesado a menos que necesiten específicamente esa robustez empresarial o ya lo usen en otras áreas. Nuestro estudio escéptico encuentra que las afirmaciones de Blue Yonder de ser de vanguardia son algo dudosas hasta que se demuestre lo contrario – la tecnología tiene linaje, pero la carga recae sobre ellos para demostrar que un software de décadas realmente se ha convertido en “AI-first” y unificado. A día de hoy, aconsejamos ver a Blue Yonder como una opción poderosa pero engorrosa, una que eliges si necesitas una solución muy extensa y tienes los recursos para implementarla, y quizás no la primera opción si la agilidad y un ROI rápido son prioritarios.

4. ToolsGroup – Pionero en Optimización de Inventario Expandiéndose a Retail Completo

ToolsGroup es un veterano en el ámbito de la planificación de supply chain, conocido particularmente por su experiencia en forecast de demanda y optimización de inventario (stock). Su solución insignia, históricamente llamada SO99+ (Service Optimizer 99+), fue ampliamente utilizada para la planificación de inventario orientada al nivel de servicio y la optimización de múltiples niveles. En términos simples, ToolsGroup sobresalía en ayudar a las empresas a determinar “¿cuál es el inventario mínimo que necesito en cada ubicación para alcanzar un nivel de servicio X?” en condiciones de incertidumbre – un problema crítico tanto para la distribución como para el ecommerce. ToolsGroup fue de los primeros en implementar comercialmente probabilistic forecasting, y durante mucho tiempo abogó por alejarse de los forecasts deterministas y utilizar la distribución completa de la demanda ⁴³ ².

En un contexto de ecommerce, la fortaleza de ToolsGroup significa que puede manejar altos recuentos de SKU con demanda errática, y aún así producir objetivos de stock óptimos. Muchos e-tailers tienen artículos de “long tail” que se venden raramente – los modelos probabilísticos de ToolsGroup están naturalmente adaptados para planificar esos casos (capturando la naturaleza esporádica de la demanda en lugar de promediarla de forma incorrecta). También manejan introducciones de nuevos productos, estacionalidad y promociones a través de sus modelos de forecast que incorporan aprendizaje automático. Por ejemplo, podrían usar analogías (encontrar el historial de un artículo similar) o modelado basado en atributos para forecast un nuevo SKU.

Mientras que ToolsGroup históricamente se enfocó en inventario y demanda, en los últimos años reconoció que pricing, promotions, y assortment son piezas complementarias que no ofrecía. Para abordar esto, ToolsGroup adquirió una empresa llamada JustEnough en 2018/2019 (JustEnough fue posteriormente parte de Mi9 Retail y luego vendida a ToolsGroup). El software de JustEnough cubría planificación financiera de merchandising, planificación de surtido, asignación y optimización de markdowns – esencialmente funciones de merchandising retail, incluyendo rebajas de precios. Con esta adquisición, ToolsGroup expandió su presencia de un enfoque puramente en supply chain hacia lo que se podría llamar planificación de retail. Ahora comercializan una suite integrada que puede hacer de todo, desde la planificación en alto nivel hasta la ejecución, con la combinación de capacidades de SO99+ y JustEnough.

Sin embargo, la integración de estos productos es un punto clave de escepticismo. Fusionar dos plataformas de software diferentes no es trivial. ToolsGroup ha trabajado para integrar modelos de datos (mencionan tener “el mismo modelo de datos para la planificación táctica y operativa” para asegurar una única versión de la verdad ⁴⁴). Incluso lanzaron algo denominado “Real-Time Retail” que conecta el sistema de planificación de JustEnough con un Inventory Hub para obtener flujos de datos casi en tiempo real ⁴⁵ ⁴⁶. La idea es que, a medida que se realizan ventas (o a medida que el inventario se mueve), esos eventos fluyen instantáneamente hacia el sistema de planificación, permitiéndole replanificar la asignación o reposición sobre la marcha. Esto sugiere que ToolsGroup está tratando de posibilitar una planificación más dinámica y continua en lugar de ciclos periódicos fijos, un objetivo similar al de otros proveedores modernos.

Pero desglosémoslo: que ToolsGroup llame a su solución “Real-Time Retail, the only solution that responds to shopping behavior in the moment” ⁴⁵ es una afirmación contundente. Básicamente implica que pueden ajustar el plan tan pronto como algo cambia. Quizás el sistema pueda desencadenar automáticamente un traslado de stock o acelerar un pedido si las ventas se disparan inesperadamente hoy. Si es cierto, eso es poderoso: difumina la línea entre la planificación y la ejecución. Sin embargo, la visión escéptica es que “real-time” probablemente se limite a ciertas funciones (como la re-asignación de inventario, que es más fácil de realizar rápidamente) y no a otras (como re-optimizar completamente un surtido, lo cual no se haría en tiempo real). También vale la pena señalar que ahora todos los proveedores usan “real-time” en marketing (a menudo refiriéndose a una actualización cada pocos minutos o cada hora, lo cual está bien). La propia CEO de ToolsGroup señaló que los minoristas necesitan pivotar rápidamente para evitar la erosión de márgenes cuando cambia la demanda ⁴⁷, lo cual es cierto. Supuestamente, el sistema recalcula automáticamente y recomienda pedidos o traslados tan pronto como llega nueva información ⁴⁸.

Asumiendo que ToolsGroup ha integrado efectivamente JustEnough, un usuario de su sistema podría, por ejemplo, planificar un surtido por tienda o canal utilizando el módulo de JustEnough, luego hacer que eso alimente los objetivos de inventario en SO99+, y además planificar markdown pricing para productos en fin de vida utilizando su optimización. Eso abarca aspectos de optimización conjunta, especialmente si los forecast de demanda y los parámetros de inventario tienen en cuenta el calendario de markdown planificado. Todavía es posiblemente un proceso secuencial (primero se deciden los markdowns, luego se observa el resultado en el inventario) a menos que hayan construido un modelo de optimización combinado (lo cual es poco probable dada su amplitud). Pero es una solución unificada en términos de flujo de datos.

Donde ToolsGroup claramente cumple con los criterios de vanguardia es en el forecast probabilístico y la optimización del nivel de servicio. Durante años han insistido en que los forecast de un solo número son insuficientes y que hay que planificar con probabilidades. Por ejemplo, producirán no solo “expected demand = 100” sino una curva que muestra que hay un 10% de probabilidad de que la demanda supere 120, etc. Luego, su optimización utiliza eso para decidir los niveles de stock de tal manera que, por ejemplo, en el 95% de los casos se pueda satisfacer la demanda ⁴⁹ ⁵⁰. Este enfoque maneja inherentemente la incertidumbre e incluso la cannibalización hasta cierto punto (especialmente si se utiliza su modelado para artículos correlacionados). Un aspecto interesante: ToolsGroup a menudo argumentaba que el uso del forecast probabilístico puede extender la vida de los sistemas de planificación ERP heredados (como SAP APO) al proporcionarles mejor información ¹ ⁵¹. Esto subraya que el diferenciador de ToolsGroup radicaba principalmente en las matemáticas del forecast y del inventario en lugar de ser una interfaz de usuario de planificación todo en uno.

Ahora, ¿qué hay de la automatización y facilidad de uso? Tradicionalmente, ToolsGroup era más un “motor de back-end” con una interfaz algo torpe, según algunos usuarios. Desde entonces han mejorado la interfaz (nueva web UI, etc.). Pero, más importante aún, enfatizan la automatización en la planificación. Sus materiales afirman, por ejemplo, “built-in automation cuts the planning workload by up to 90%” ⁵². También suelen citar a clientes que han logrado una “reducción del 40-90% en la carga de trabajo de los planificadores” y una “reducción del 20-30% en inventario” tras usar ToolsGroup ⁵³ ⁵⁴. Esos son números grandes. La afirmación de reducción de inventario es plausible si una empresa era muy ineficiente anteriormente o mantenía buffers excesivos por falta de confianza en los forecast. La reducción de la carga de trabajo de los planificadores implica que el sistema hace mucho más automáticamente. Esto se alinea con lo que esperamos: un sistema probabilístico debería reducir los fuegos artificiales (dado que se planifica para la incertidumbre, ocurren menos sorpresas, por lo que los planificadores no tienen que acelerar tanto o reasignar manualmente el stock en el último minuto). Sin embargo, un escéptico señalaría que una reducción del 90% en la carga de trabajo es probablemente el extremo superior (quizás un caso en que una empresa pasó de 10 planificadores a 1 tras la implementación, posible pero no típico). Y una reducción del 20-30% en inventario podría ser el resultado de que inicialmente la empresa llevaba un stock “just in case” demasiado elevado. En supply chain, una vez que optimizas, a menudo ves reducciones de tal vez 10-15% si las cosas estaban moderadamente bien antes. Así que sospechamos que los rangos anunciados por ToolsGroup ⁵³ son escenarios de mejor caso. Es ilustrativo que los presenten como rangos: implica que los resultados varían considerablemente según el cliente.

Una cosa a favor de ToolsGroup es su estabilidad y enfoque específico. Han estado realizando optimización de supply chain durante 30 años (fundados en 1993). No son tan grandes como Blue Yonder ni tan modernos como RELEX, pero cuentan con una base de clientes leal y una profunda experiencia en el dominio. Para una empresa de eCommerce preocupada principalmente por la rentabilidad del inventario – es decir, por no tener demasiados faltantes de stock o excesos – la solución de ToolsGroup es muy madura. Su optimización multi-echelon podría beneficiar especialmente a los e-tailers con múltiples centros de cumplimiento o aquellos que también almacenan en 3PL warehouses, etc. Impulsará adecuadamente el inventario hacia donde se necesite más, al mismo tiempo que mantiene los buffers centrales ajustados.

Sin embargo, el punto débil de ToolsGroup era la optimización de precios. La adquisición de JustEnough les proporcionó optimización de markdown (decidir los calendarios de descuento para liquidación). Esto es útil para eCommerce con productos estacionales o de moda. Pero aún carecen de una verdadera optimización de dynamic pricing similar a la que ofrecen Revionics/Blue Yonder u otros proveedores especializados en pricing. La optimización de markdown se refiere a la fijación de precios para productos en fin de vida o en promoción. La optimización de precios diaria regular (para el margen o para el posicionamiento competitivo) no es una fortaleza bien conocida de ToolsGroup. Podrían tener capacidades básicas o aprovechar socios. Esto significa que, si la optimización conjunta de precio + inventario es una prioridad, ToolsGroup podría no ser tan fuerte como Blue Yonder o RELEX, que cuentan con motores de pricing dedicados. ToolsGroup aún podría optimizar el inventario asumiendo un precio dado, pero no te indicará el mejor precio para maximizar el beneficio (aparte de escenarios de liquidación de productos en fin de vida). Esta es una distinción importante: su “optimización” es primordialmente orientada al supply (niveles de stock, reposición) en lugar de estar orientada a moldear la demanda (pricing, promoción) – a pesar de haber incorporado algunas herramientas de moldeado de la demanda mediante adquisición.

En términos de technology stack, ToolsGroup ahora ofrece una opción cloud SaaS e incluso posiciona algunas de sus ofertas bajo nombres llamativos como “Inventory Hub” y “Fulfill.io”. Esto demuestra que están tratando de modernizarse y quizás de atraer a un mercado más amplio, incluyendo empresas eCommerce medianas. El motor subyacente sigue utilizando métodos estadísticos avanzados y, probablemente, C++ o similar para el cómputo. No hemos escuchado historias de que ToolsGroup haya alcanzado límites de rendimiento; tienen referencias de clientes con millones de combinaciones SKU-location. Si acaso, el talón de Aquiles de ToolsGroup podría ser que se percibe como una “herramienta de optimización” – poderosa pero que requiere configuración por expertos. Han intentado simplificar con más ML out-of-the-box. Por ejemplo, incorporan demand sensing (utilizando tendencias a corto plazo para ajustar los forecast) y afirman usar machine learning para identificar qué factores influyen más en la demanda ⁵⁵. También derribaron un mito en su blog de que los forecast probabilísticos no pueden ser ajustados por humanos, aclarando que pueden incorporar juicio, pero las matemáticas tendrán en cuenta los sesgos históricamente ⁵⁶. Esto refleja un enfoque equilibrado: no eliminan totalmente al humano, sino que lo guían con mejor información.

Efectos de canibalización: El modelo probabilístico de ToolsGroup puede, si se configura, capturar la canibalización (por ejemplo, si se introduce una relación de sustitución, pueden modelar escenarios en los que, si un artículo se agota, parte de la demanda se traslada a otro). Sin embargo, esto probablemente requiere esfuerzo para configurar las relaciones o utilizar su ML para agrupar artículos. No está claro cuán automático es esto. Pero ToolsGroup enfatizó el manejo de “long tail, intermittent demand, and more channels” en un blog de 2017, básicamente afirmando que estas condiciones rompen las herramientas tradicionales y requieren métodos probabilísticos ⁵⁷. Específicamente mencionan “more channels to market, with aggregated demand coming from multiple streams” como un escenario en el que los forecast de un solo número fallan, insinuando que su solución gestiona mejor el multi-channel ⁵⁷. Así que un e-tailer que venda en su sitio web y en Amazon, por ejemplo, podría usar ToolsGroup para planificar una demanda combinada. La herramienta produciría un forecast total y quizás permitiría asignar inventario por canal de manera óptima (aunque la asignación por canal suele ser más sencilla cuando todo se envía desde los mismos centros de cumplimiento, pero en caso de pools de stock separados, importa).

Un aspecto a observar con ToolsGroup (como con cualquier proveedor de suite adquirida) es la consistencia en la experiencia de usuario. ¿Se encuentran ahora todos los módulos de forecast, inventario y surtido en una sola UI, o se siente como si se saltara entre sistemas? Han trabajado en unificar la interfaz, pero sería necesario el feedback de los usuarios. No es tan unificada como la plataforma única desarrollada internamente de RELEX, presumiblemente.

En términos de historial de éxitos, ToolsGroup tiene muchos casos de estudio exitosos, a menudo destacando la reducción de inventario y la mejora del nivel de servicio. No tienen un gran fiasco conocido públicamente como ocurrió con SAP o JDA. Son más pequeños, por lo que cada proyecto podría recibir más atención. Dicho esto, debido a que a menudo vendían a empresas de manufactura/distribución, algunas personas del retail/ecomm no los conocen tan bien. Su incursión en el retail a través de JustEnough significa que algunos clientes antiguos de JustEnough ahora usan ToolsGroup. JustEnough en sí tuvo críticas mixtas (fue decente en planificación pero quizás limitada en escalabilidad – no está claro). Así que ToolsGroup tuvo que reforzar esos módulos. Como escépticos, recomendaríamos verificar cuán integrados están realmente los análisis. Por ejemplo, ¿puede el sistema reconocer automáticamente que una promoción planificada en el módulo de JustEnough debe ajustar el forecast de demanda en SO99+? Probablemente sí, habrán integrado los aumentos promocionales. Mencionan que “demand sensing insights help fine-tune the statistical forecast” ⁵⁸, lo que implica que tienen en cuenta elementos como promociones o tendencias recientes para ajustar los forecast base.

Para resumir la evaluación de ToolsGroup: Es muy fuerte en su nicho original (forecast y inventario) – posiblemente el mejor en la optimización probabilística de inventario – y está ampliándose para cubrir optimización de precios y surtido, aunque esas capacidades más nuevas pueden no rivalizar aún con competidores especializados. ToolsGroup cumple con muchos de nuestros criterios de vanguardia:

¿Forecasts probabilísticos? Sí, lo han defendido ⁴⁹ ⁴³.
¿Optimización económica? Implícitamente sí para el inventario (optimizan en función de los compromisos entre servicio y costo), aunque no de forma tan explícita en términos de beneficio como lo hace Lokad. Es más bien “alcanzar el objetivo de servicio con el mínimo inventario”, lo que es una forma de optimización de costos.
¿Escalabilidad? Generalmente sí, sin señales de alerta. Y su enfoque es eficiente (no es de fuerza bruta).
¿Canibalización? Posiblemente, mediante modelado avanzado, pero no es su principal fortaleza.
¿Marketplace/competitividad? No de manera inherente – se manejaría externamente o mediante insumos. ToolsGroup no rastreará los precios de los competidores por ti ni nada parecido.
¿Automatización? Sí, alta. Después de la configuración, muchas tareas de planning pueden automatizarse con su sistema emitiendo propuestas de pedido que los planificadores simplemente aprueban. Promocionan enormes reducciones de la carga de trabajo y menos sesgo humano.
Escepticismo sobre las afirmaciones del proveedor: El marketing de ToolsGroup es en realidad algo moderado en comparación con otros, aparte de esas estadísticas de mejora que ya analizamos con precaución. Se centran en lo que la tecnología hace (sus blogs que educan sobre forecast probabilístico son sustanciales, no solo palabrería). Pero sí se unen ahora al juego de las palabras de moda sobre AI, llamando a todo “AI-powered”. Cabe señalar, sin embargo, que mantienen un pie en la OR tradicional (investigación operativa) y otro en ML, lo cual es una mezcla saludable.

Un dato externo: Las evaluaciones de firmas analistas (como Gartner) a menudo sitúan a ToolsGroup como líder en Supply Chain Planning, pero podrían comentar que la capacidad de ToolsGroup es más profunda que amplia, y que la UI históricamente era menos moderna. Esto se ha abordado parcialmente ahora (nueva UI, integración).

Para un eCommerce pure-player, la decisión de optar por ToolsGroup probablemente dependerá de si la optimización de inventario es el principal problema y de si necesitan una solución probada y algo autónoma para ello. Si es así, ToolsGroup podría ser una opción excelente, ofreciendo victorias rápidas en la reducción de stock y la mejora del servicio. Sin embargo, si el negocio eCommerce también busca optimizar fuertemente el pricing o implementar estrategias de markdown omnicanal de vanguardia, ToolsGroup podría no ser tan completo en ese aspecto como Blue Yonder, RELEX o una herramienta de pricing dedicada. Podría requerir complementarse con otra solución de pricing, lo cual trae consigo desafíos de integración. (Curiosamente, ToolsGroup podría no oponerse a eso – históricamente a veces coexistieron con otros, centrándose en inventory mientras otro sistema se encargaba del pricing).

En conclusión, ToolsGroup se posiciona como un proveedor sólido técnicamente, pasado de especialista a suite. Apreciamos su rigor ingenieril en el forecast y su enfoque directo al abordar la incertidumbre (hace tiempo que desacreditan el problema de que “el forecast siempre está equivocado” planificando con probabilidades). Permanecemos cautelosos respecto a la expansión reciente: si sus módulos de retail recién integrados funcionan al mismo nivel que su núcleo. La contradicción interna que observamos es su afirmación de estar completamente integrados ahora – si aparecen grietas (como la necesidad de exportar/importar datos manualmente entre módulos), eso socavaría la propuesta. Pero según la información disponible, ToolsGroup parece estar ofreciendo una experiencia más unificada tras JustEnough. Incluso se alinean con la tendencia de uso de datos en tiempo real en la planificación, lo cual es encomiable.

Finalmente, tal como hicimos con otros: examen de afirmaciones de proveedores para ToolsGroup. Cuando dicen, por ejemplo, “90+% de disponibilidad de producto, 20-30% menos inventario, 40-90% de carga de trabajo reducida” ⁵³ ⁵⁴ – un sano escepticismo consiste en ver estos resultados como alcanzables pero no garantizados. Es probable que esos números provengan de diferentes clientes, cada uno alcanzando uno de esos altos valores, y no de un solo cliente alcanzándolos todos simultáneamente. Nadie debería esperar que su inventario disminuya un 30% mientras el servicio salta a >90% y se recorta a los planificadores en un 90% de una vez. La realidad suele implicar compensaciones y mejoras incrementales. La metodología de ToolsGroup sin duda puede impulsar una mejora significativa, pero aconsejamos fijar objetivos realistas y medir a medida que se avanza. La buena noticia es que el enfoque de ToolsGroup en resultados medibles (servicio %, inventario $$) se ajusta a un método de búsqueda de la verdad: es muy claro si está funcionando o no con solo observar esos indicadores.

Desenmascarando el bombo: Lecciones & Recomendaciones

Entre estos proveedores, surgieron algunos temas comunes sobre el bombo versus la realidad que un tomador de decisiones en eCommerce debería tener en cuenta:

Cuidado con las palabras de moda: Términos como “AI-driven, cognitive, demand sensing, real-time, autonomous” se utilizan de manera desenfrenada. Asegúrate de que estén respaldados por capacidades concretas. Por ejemplo, “demand sensing” suele sonar bien – usar las ventas de ayer o el bullicio en redes sociales para ajustar el forecast de hoy – pero en la práctica puede solo modificar ligeramente los números y básicamente es simplemente forecasting a corto plazo. Los expertos de la industria han calificado el demand sensing como posiblemente “mootware” – algo que existe pero que no aporta un valor material más allá de lo que ya hace un buen forecast ⁵⁹. No te dejes engañar por conceptos de “vaporware” sin evidencia. Pregunta al proveedor: ¿qué exactamente hace tu AI que mi proceso actual no puede, y puedes demostrarlo? Si dicen “consideramos 300 factores”, desafíalos sobre si esos factores realmente marcan la diferencia o solo hacen una buena diapositiva.
Referencia y puntos de comparación: Siempre establece una línea base clara (por ejemplo, la rotación de stock del año pasado, tasa de cumplimiento, margen bruto) y verifica si el proveedor está de acuerdo en medir la mejora con respecto a ella. Muchos afirman mejoras porcentuales que suenan enormes pero carecen de significado sin contexto. Además, busca cualquier participación en benchmarks externos (como competiciones de forecast o estudios de caso públicos con cifras concretas). La competencia M5 fue uno de esos benchmarks que separó lo bueno de lo malo en forecast – notablemente, ninguno de los grandes proveedores tradicionales publicó resultados allí, mientras que un competidor más pequeño (Lokad) lo hizo y destacó ⁶⁰. Eso te indica quién confía en su tecnología.
Complejidad de la integración: Si un proveedor creció a través de adquisiciones (Blue Yonder, ToolsGroup), ten cuidado con las promesas de que “ahora es todo una sola plataforma”. A menudo toma años integrar de verdad. Durante ese tiempo, podrías estar usando sistemas separados con algunas interfaces. Pueden existir costos ocultos en la implementación para conectar todo. Además, dos componentes adquiridos podrían no compartir la misma noción de ciertos datos (por ejemplo, uno utiliza intervalos semanales, otro diarios, o definiciones diferentes de jerarquía de productos). Esto puede llevar a compromisos o desalineaciones. Es aconsejable hablar con clientes de referencia sobre su experiencia integrando módulos.
Estructura de costos: Evalúa no solo los costos de licencia/suscripción del software, sino también los costos de runtime (si aplican) y la infraestructura requerida. Como se señaló, una solución que dependa de algo como Snowflake podría transferirte esos costos de ejecución en la nube. O una solución que requiera mucha memoria podría obligarte a usar instancias de nube de alto nivel. Un proveedor podría cotizar una tarifa de suscripción más alta pero incluir todo el cómputo; otro podría ser más barato, pero tú asumirías una gran factura de AWS/Azure por la computación necesaria. Asegúrate de comparar el costo total de propiedad. Mencionamos cómo el modelo de Snowflake podría hacer eco de las desventajas del mainframe de IBM – mantén un ojo en las tarifas basadas en uso y exige transparencia a los proveedores que utilizan ese modelo.
Cada proveedor tiene fracasos: Es importante recordar que ningún proveedor resaltará sus proyectos fallidos, pero todos los tienen. La implementación es tan importante como la herramienta. Vimos cómo incluso proveedores de primer nivel como SAP o i2 (ahora bajo Blue Yonder) tuvieron fracasos de millones de dólares ³⁹ ³³. A menudo, las razones son datos deficientes, expectativas desalineadas o la falta de adopción de los resultados del sistema. Al evaluar, pregunta a los proveedores cómo manejan los proyectos que no alcanzan los objetivos. ¿Tienen ejemplos (anonimizados) de lecciones aprendidas? Blue Yonder mostró algo de humildad al reconocer las causas comunes de fracaso ²⁶. Un proveedor que dice “tenemos una tasa de éxito del 100%” no está siendo realista. Insiste en discutir lo que podría salir mal y cómo lo mitigan.
Contradicciones entre el tiempo real y la profundidad analítica: Como se señaló, algunas analíticas (como la planificación de surtido a nivel de red) no pueden ser verdaderamente en tiempo real – requieren de un análisis sustancial de datos y deliberación empresarial. Si un proveedor afirma tanto “respuesta en tiempo real” como “optimización holística”, necesitas discernir qué partes de su solución corresponden a cada promesa. Por ejemplo, ToolsGroup puede actualizar las posiciones de inventario en tiempo real, pero su optimización central podría ejecutarse diariamente. RELEX puede ingerir datos en casi tiempo real, pero la planificación de ciertos aspectos (como la optimización de precios basada en AI) aún podría ser un proceso por lotes durante la noche. Comprende la cadencia de cada parte de la solución en relación con las necesidades de tu negocio. El tiempo real es crucial para la ejecución (como actualizar el inventario disponible para prometer o precios dinámicos al instante), pero para decisiones estratégicas, la profundidad y el rigor importan más que la velocidad.
Intervención humana vs autonomía: Todos los proveedores afirman tener cierto nivel de autonomía, pero también permiten la entrada humana. Es un espectro. La pregunta clave es: ¿El sistema opera por defecto de manera automática con solo excepciones señaladas, o por defecto requiere revisión por parte del usuario para cada decisión? Para lograr verdaderas ganancias de eficiencia, deseas lo primero. Una señal de alerta es si el proveedor enfatiza cuántas palancas y opciones de configuración tiene el usuario – eso puede indicar que la herramienta podría necesitar mucha supervisión para obtener buenos resultados (lo que contradice la promesa de automatización). Idealmente, la herramienta debería ajustar automáticamente esas palancas (como Blue Yonder eliminando la necesidad de establecer manualmente perfiles estacionales mediante ML ³⁶). Confía pero verifica: durante las demostraciones o pruebas, observa cuánto ajuste manual se requirió para que los resultados se vieran bien.
Especificaciones de AI/ML: Profundiza en las afirmaciones de AI del proveedor. Pregunta: ¿Están utilizando machine learning para el forecast? ¿Qué algoritmos (si pueden decirlo)? ¿Usan alguna biblioteca de código abierto? (Si todo es propietario, a veces es señal de que no se han mantenido al día con las últimas técnicas; todas las principales soluciones de AI incorporan código abierto como TensorFlow/PyTorch o al menos algoritmos reconocidos). Si un proveedor se limita a mencionar un “motor de AI propietario” pero no puede explicarlo en términos sencillos, sé escéptico. Por el contrario, si pueden articular, por ejemplo, “usamos gradient boosting para los forecast baseline y un modelo de reinforcement learning para precios,” eso demuestra una inversión concreta en tecnología. Además, verifica si su equipo ha publicado o participado en foros académicos o de la industria sobre sus métodos – una señal de seriedad.

Finalmente, subrayamos una mentalidad de búsqueda de la verdad: insiste en datos y resultados de pruebas sobre promesas superficiales. Si es posible, realiza un piloto o prueba de concepto donde a cada proveedor se le entregue un subconjunto de tus datos para forecast o optimizar, y evalúa los resultados de forma cuantitativa. Por ejemplo, alimenta con dos años de historial y déjalos forecast el tercer año (para el cual tienes datos reales) – observa quién se acerca más o quién identifica los patrones de demanda complicados. O haz que optimicen un escenario y luego simula los resultados en costo/servicio usando tu demanda real para validar. Pocos proveedores se ofrecerán voluntariamente para una competencia práctica, pero los buenos a menudo lo harán porque respaldan su ciencia. Lokad, por ejemplo, suele participar mediante proyectos piloto. Blue Yonder y RELEX a veces realizan fases de “discovery” que se asemejan a pilotos. Solo asegúrate de tener criterios de éxito claros para esos.

Al final, el mercado de software de optimización en eCommerce no carece de “milagros de AI” autoproclamados, pero aplicando un profundo escepticismo y exigiendo evidencia de ingeniería, se puede filtrar el ruido. Este estudio encontró que Lokad lidera en innovación técnica y enfoque, RELEX en funcionalidad minorista unificada (con algo de bombo que vigilar), Blue Yonder en amplitud y experiencia (en medio de una desafiante renovación tecnológica), y ToolsGroup en fortalezas de optimización especializadas (con integración en crecimiento). Cada uno puede ofrecer beneficios significativos – sin embargo, ninguno es una panacea plug-and-play. La verdad es que la optimización exitosa proviene de la herramienta adecuada y de la estrategia de implementación correcta. Con los conocimientos y puntos de precaución expuestos arriba, una empresa de eCommerce puede acercarse a estos proveedores con los ojos bien abiertos y tomar una decisión basada en hechos y un razonamiento sólido, no solo en el atractivo del marketing.