Software de Optimización de eCommerce

Por Léon Levinas-Ménard

Última modificación: 2 de febrero de 2025

Introducción

El mercado del software de optimización de ecommerce está lleno de audaces afirmaciones de magia impulsada por IA, pero una mirada detallada revela que solo unos pocos proveedores cumplen realmente con la promesa de optimizar conjuntamente el inventario, los precios y los surtidos con tecnología de última generación. En este estudio, evaluamos las soluciones líderes para ecommerce puro (minoristas en línea sin tiendas físicas) y clasificamos a los proveedores más relevantes, incluyendo Lokad, RELEX Solutions, Blue Yonder y ToolsGroup, por sus méritos técnicos y desventajas. Lokad emerge 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 completas atenuadas por la complejidad de la IA de caja negra y el lastre heredado, respectivamente. ToolsGroup proporciona una optimización de inventario probada basada en matemáticas sólidas pero enfrenta desafíos de integración a medida que se expande hacia la fijación de precios y el surtido. A lo largo de todo, aplicamos una lente profundamente escéptica: cortando el bombo publicitario, escrutando las afirmaciones de los proveedores contra evidencia independiente, y destacando las advertencias a menudo no dichas (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 impulsado por la narrativa que pone la verdad sobre el bombo publicitario, para que los jugadores de ecommerce puedan entender quién avanza genuinamente el estado del arte, y quién se queda corto.

Los Criterios Estándar de Oro: Optimización Conjunta y Tecnología Avanzada

Cualquier proveedor puede jactarse de IA o big data, pero optimizar verdaderamente un negocio de ecommerce requiere cumplir con un alto estándar de criterios técnicos y funcionales. Lo más importante es la optimización conjunta: la capacidad de optimizar simultáneamente las decisiones de niveles de inventario, precios y surtido de productos. Tratar estos aspectos de forma aislada, como lo hacen muchos sistemas antiguos, es fundamentalmente defectuoso, ya que están estrechamente interdependientes (la fijación de precios afecta la demanda que afecta el inventario, los cambios de surtido afectan a ambos, etc.). Una solución de optimización de ecommerce debe coordinar los tres; por ejemplo, podría decidir tener menos stock de un producto y descontarlo antes si los forecast revelan ventas lentas, o subir los precios de ciertos artículos para evitar faltantes 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 las técnicas y arquitecturas modernas:

Forecast probabilístico: En lugar de forecast de demanda de un solo punto, usar distribuciones de probabilidad para capturar la incertidumbre de la demanda. Esto es crucial para el ecommerce con sus patrones de demanda volátiles y su “cola larga” de SKUs. Las herramientas tradicionales (por ejemplo, los antiguos módulos de SAP o Oracle) que producen un número y un stock de seguridad a menudo juzgan mal 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 ser impulsadas por objetivos económicos (beneficio, coste, objetivos de nivel de servicio) y no solo 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 decidir los niveles de stock y los precios. Priorizará las acciones que maximicen el beneficio esperado o minimicen el costo total, en lugar de lograr ciegamente una tasa de llenado. Esto requiere incrustar parámetros de costo/ingresos en los algoritmos.
Escalabilidad y eficiencia de 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 de hardware exorbitantes o un rendimiento lento. Las arquitecturas que ingenuamente mantienen todo en memoria (RAM) pueden volverse prohibitivamente caras a escala. Los diseños modernos utilizan la computación en la nube de manera inteligente, por ejemplo, procesamiento distribuido, almacenes de datos basados en disco y algoritmos eficientes. Una solución que necesita una granja de servidores gigante 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 de escala de terabytes en unas pocas horas en instancias de nube de productos básicos ³ ⁴.
Efectos de canibalización y sustitución: En las decisiones de surtido y precios, el sistema debe tener en cuenta que los productos afectan la demanda de cada uno. Por ejemplo, si dos productos son sustitutos cercanos, eliminar uno desplazará la demanda al otro (un efecto de canibalización). Manejar esto requiere más que un simple análisis OLAP o grupos de productos definidos manualmente; requiere modelos que aprendan las elasticidades cruzadas o las tasas de adhesión. Muchas herramientas heredadas asumen que la demanda de cada producto es independiente, lo que lleva a errores tanto en la previsión 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 de productos).
Impactos del mercado y la competencia: Los jugadores puros de ecommerce a menudo están influenciados por la dinámica del mercado - por ejemplo, la competencia en Amazon o eBay, vendedores de terceros, etc. El software de optimización idealmente debería incorporar señales como los precios de la competencia o los faltantes de stock en el mercado. Pocos lo hacen bien. Es un frente complejo pero cada vez más relevante: por ejemplo, si un competidor se queda sin stock de 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 directamente y en mercados, el sistema debería optimizar a través de los canales (evitando, por ejemplo, el sobreabastecimiento para 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 (sitio web propio, mercados, quizás sitios regionales). El motor de optimización debería manejar la demanda y el inventario multicanal de manera integral, reconociendo, por ejemplo, que el inventario es compartido o que las decisiones de precios en un canal podrían afectar a otro. La planificación “de extremo a extremo” no es solo una palabra de moda; significa que el software ve el panorama completo (de proveedores a clientes, a través de todos los flujos de ventas).
Alto grado de automatización (“robotización”): La promesa final de estos sistemas es la toma de decisiones autónoma. Teóricamente deberían poder funcionar sin supervisión, produciendo pedidos de reposición, actualizaciones de precios, etc., sin que los usuarios ajusten los diales todos los días. En realidad, todos los proveedores aún permiten la configuración del usuario, pero favorecemos a aquellos que minimizan la necesidad de ajustes humanos. Cuidado con las soluciones que presumen de automatización pero exponen docenas de perillas (parámetros, factores de ponderación, reglas) - eso es una contradicción interna. La verdadera automatización proviene de permitir que los algoritmos encuentren la configuración óptima, no de pedir a los usuarios que recalibren constantemente. Los mejores sistemas utilizan técnicas como modelos de autoaprendizaje que se ajustan a medida que llegan nuevos datos, de modo que con el tiempo las decisiones siguen siendo óptimas sin intervención manual ⁵. Cuantos menos ajustes “del conductor” deba mantener un usuario, más creíble será la automatización.
Arquitectura robusta y rentable: Hemos hablado de la eficiencia de costos, pero vale la pena mencionarlo 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 datos en una plataforma como Snowflake, los costos pueden dispararse (similar a la tarificación basada en MIPS de IBM en la década de 1990, donde un mayor uso de la CPU significaba tarifas exponencialmente más altas). Una solución ideal maneja big data con algoritmos inteligentes para mantener el uso de la nube (y por lo tanto el costo) razonable ⁴. De manera similar, las soluciones construidas a través de adquisiciones pueden terminar siendo un mosaico de módulos en diferentes pilas tecnológicas, lo que lleva a altos costos de integración para el cliente (ya sea en dinero o en latencia del sistema). Ser nativo de la nube e integrado desde cero es una ventaja, pero solo si la arquitectura realmente elimina el movimiento de datos redundantes sin introducir nuevos cuellos de botella.

Con estos criterios establecidos, ahora nos volvemos hacia los proveedores. Clasificamos a Lokad, RELEX, Blue Yonder y ToolsGroup como los jugadores más relevantes para la optimización de ecommerce, y evaluamos a cada uno contra los puntos de referencia anteriores. El análisis es narrativo en estilo, centrándose en cómo cada proveedor aborda el problema y dónde se justifica el escepticismo, en lugar de una lista de características. Importante, nos apoyamos en evidencia creíble (y citas directas) siempre que sea 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 Estructura Probabilística

Lokad se destaca como un proveedor construido explícitamente en torno a la idea de optimización conjunta utilizando tecnología de vanguardia. A diferencia del software tradicional de supply chain, Lokad no viene como un conjunto de módulos (forecasting, MRP, etc.) para ser ajustados, sino como una plataforma programática donde 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 por adelantado, pero produce una solución hecha a la medida para optimizar todas las decisiones juntas - inventario, precios, reposición, todo en uno. La filosofía de Lokad es que los forecast son solo un medio para un fin; el verdadero objetivo es optimizar las decisiones (por ejemplo, cuánto comprar, qué precio establecer) considerando todas las restricciones y compensaciones económicas.

En el núcleo está el forecast probabilístico. Lokad fue un pionero temprano en el uso de distribuciones de probabilidad completas para la demanda, e incluso demostró su habilidad en el campo neutral de las competencias de forecasting. En la prestigiosa Competencia de Forecasting M5 (2020), un equipo de Lokad se ubicó en el 6to lugar a nivel mundial de 909 equipos ⁶ - una validación impresionante de su tecnología dado que M5 se centró en datos minoristas granulares (el tipo de datos que enfrentan las empresas de ecommerce). Es notable que M5 requería forecast cuantiles, que se alinea con la fortaleza de Lokad. Este resultado indica no solo habilidad académica sino relevancia práctica: sus forecast estaban entre los mejores, lo que respalda cualquier optimización de inventario y precios. Además, el CEO de la empresa ha destacado que más allá de cierto punto, las ganancias en precisión del forecast dan rendimientos decrecientes en comparación con una mejor modelización de 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 manejar cosas 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 ⁷.

Tecnológicamente, Lokad es de última generación y altamente impulsado por la ingeniería. Han construido su propia pila de tecnología nativa en la nube (incluyendo un lenguaje de dominio específico personalizado llamado “Envision” para escribir scripts de optimización). Esta pila está diseñada para procesar grandes datos de manera eficiente y económica. Por ejemplo, el sistema de Lokad procesa rutinariamente gigabytes a terabytes de datos de clientes (pedidos, clics, etc.) en unas pocas horas durante la noche, para emitir decisiones para el día siguiente ⁸ ³. Para hacer esto, evitan cargar todo en la RAM; en su lugar, utilizan archivos mapeados en memoria y almacenamiento en columnas en disco, permitiendo que los conjuntos de datos más grandes que la memoria de una máquina sean manejados de manera transparente al desbordar a los SSD rápidos ³ ⁹. Notan explícitamente que Envision (su motor) soporta conjuntos de datos más grandes que la memoria de incluso todo el clúster al “desbordar inteligentemente a las unidades NVMe”, y que las operaciones paralelas embarazosamente son distribuidas automáticamente a través de núcleos/máquinas ³. El efecto neto: Lokad puede escalar a surtidos de SKU extremadamente grandes sin requerir que el cliente invierta en cantidades absurdas de RAM o aparatos especializados. De hecho, enfatizan que se requiere poco hardware para funcionar - evitando situaciones donde “hacer clic en un botón de ejecución cuesta cientos de dólares” en tarifas de la nube ⁴. Este es un punto sutil pero crucial: los diferencia de algunos sistemas empresariales pesados que podrían manejar técnicamente big data pero a un gran costo. El enfoque de Lokad es más cercano a una tubería de big data optimizada, similar a Apache Spark o Google BigQuery, pero construida específicamente para cálculos de supply chain. 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 precios y surtido de Lokad no es a través de módulos separados sino a través de la misma lógica de optimización. Como la plataforma es esencialmente impulsada por código, se pueden modelar las interacciones. Por ejemplo, se puede escribir un script que diga: “para cada producto, considera la demanda probabilística en diferentes puntos de precio, ten en cuenta la disponibilidad de stock y el tiempo de reordenamiento, luego elige el precio que maximiza el margen esperado menos el costo de mantenimiento, sujeto a no tener faltantes de stock demasiado a menudo” - esta es una descripción simplificada, pero ilustra que el precio y el inventario pueden decidirse juntos. Si un producto está sobreabastecido, el código podría decidir un descuento para acelerar las ventas; si es escaso, podría subir el precio para asignar el inventario a los clientes que más pagan. 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 de los datos del comerciante.

Los efectos de canibalización y sustitución se manejan de forma natural si se alimenta con los datos correctos. Por ejemplo, se puede incorporar una entrada de “si el artículo A no está disponible, cuánto de su demanda va al artículo B” - tales relaciones pueden aprenderse de los datos históricos (analizando faltantes de stock pasados o cambios de surtido) y luego alimentarse en la optimización. Como Envision es un lenguaje de programación completo, estas dinámicas de demanda complejas pueden codificarse. La literatura de Lokad indica que hacen esto activamente: el sistema “descubre correlaciones entre productos, canales y períodos de tiempo” y toma decisiones en consecuencia, en lugar de asumir que cada SKU es independiente ¹⁰. No se basa en la extrapolación simplista de series de tiempo; calcula distribuciones de probabilidad completas para la demanda que tienen en cuenta las promociones, los faltantes de stock, los cambios de estacionalidad, etc. ¹¹. Al capturar estos factores (incluyendo cuando la demanda se perdió debido a estar fuera de stock), Lokad evita el clásico problema de basura en la predicción de datos de ventas sesgados.

Otra área donde Lokad brilla es la inteligencia competitiva e integración de datos externos. La plataforma puede ingerir cualquier dato que sea relevante, por ejemplo, precios de la competencia, 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 la fijación de precios de la competencia” y calendarios de marketing, y experimentar con nuevos algoritmos o entradas fácilmente debido al diseño programático ¹². En un sentido práctico, si una empresa de ecommerce tiene, digamos, datos raspados de precios de la competencia o sabe que el nivel de stock de un socio del mercado es un indicador, pueden conectar eso al modelo de Lokad para refinar las decisiones. Esto es mucho más flexible que la mayoría de las soluciones listas para usar que solo podrían manejar datos internos. Habla de un enfoque de “caja de cristal”: en lugar de ocultar la lógica, Lokad te permite personalizarla. Dicho esto, el enfoque de Lokad requiere un Supply Chain Scientist para configurarlo, no es una interfaz de usuario de punto y 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 al negocio y puede automatizar realmente las decisiones dadas las reglas únicas del negocio.

Automatización y autonomía: Lokad es posiblemente el más cercano a un planificador de supply chain “totalmente robotizado” en 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 intra-día) y producir decisiones recomendadas sin intervención humana. Muchos usuarios de Lokad confían efectivamente en él para producir órdenes de compra y sugerencias de precios que los planificadores luego revisan brevemente o incluso ejecutan automáticamente. Como el sistema es autoadaptativo (reentrena los forecast cada día con los últimos datos y reoptimiza en consecuencia), no requiere ajuste manual de parámetros. De hecho, Lokad critica bastante puntualmente el hábito de la industria de afinar sin cesar, destacan que su sistema “no se basa en métodos simplistas de series de tiempo” y funciona sin ajuste manual constante por parte de los usuarios ¹⁰. El trabajo pesado de ajustar la estacionalidad, los eventos, la demanda errática lo hacen los algoritmos, no los planificadores ajustando los forecast. Un aspecto clave es la accionabilidad: 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 lo hacen algunos paneles de “torre de control”), recomendará directamente una cantidad de pedido o un cambio de precio para abordarlo. Su objetivo es “recomendar acciones correctivas en lugar de simplemente emitir una alerta”, lo cual es crucial si se desea una operación desatendida ¹³. En un entorno de ecommerce de rápido movimiento, un sistema que simplemente te dice que hay un problema no es suficiente, quieres que te diga qué hacer al respecto, o incluso que lo haga. Lokad está construido para hacer lo último.

Dado este elogio, ¿dónde debería uno ser escéptico acerca de Lokad? La principal precaución 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 de los datos y confianza en los métodos cuantitativos por parte de la empresa usuaria. También existe una dependencia implícita del equipo de Lokad (“Supply Chain Scientists”) especialmente durante la configuración inicial - efectivamente, actúan como su equipo extendido para implementar la solución. Este es un modelo diferente de, digamos, instalar un software bien definido. Si un cliente no está preparado para participar en ese proceso colaborativo y cargado de ingeniería, podría tener dificultades. Sin embargo, este modelo también es lo que permite la profundidad de la optimización. Es un clásico compromiso: flexibilidad y potencia vs. facilidad de uso. Lokad claramente optimiza para potencia y flexibilidad.

Desde una perspectiva de mercado, la propuesta de valor de Lokad parece particularmente alineada con las necesidades del ecommerce. Las empresas de ecommerce manejan muchos desafíos - faltantes de stock, sobre stocks, picos de demanda volátiles por promociones o influencer hits, etc. - y a menudo recurren a juntar herramientas (paneles de BI, scripts ad-hoc de Python, etc.) para llenar los huecos dejados por su ERP o WMS. Lokad esencialmente se posiciona como la capa especializada que toma todas esas señales y produce un plan casi óptimo. Se contrastan explícitamente con las herramientas simplistas proporcionadas por los mercados o los ERPs, señalando que estos “sólo abordan una fracción” de lo que las empresas de ecommerce manejan ¹⁴ ¹⁵. Por ejemplo, un mercado de Amazon podría darte un forecast de demanda para la próxima semana - pero no integrará tus costos de supply chain o tu inventario multi-almacén. La tecnología de Lokad está diseñada para manejar cada señal relevante hasta el nivel de SKU, sin romperse, y sin que los usuarios tengan que manejar manualmente las hojas de cálculo ¹⁶. Esta es una fuerte propuesta de valor si se entrega como se anuncia.

Para resumir Lokad: Se sitúa en la cima de nuestra lista por su capacidad de optimización holística y tecnología avanzada. Cumple de frente con el criterio de optimización conjunta - inventario, precios, y más pueden ser optimizados juntos a través de su plataforma programática. Aprovecha el forecast probabilístico y los impulsores económicos (estaban haciendo forecasts cuantiles antes de que fuera cool, como lo demuestra su éxito en la competencia M5 ⁶) y no se aleja de efectos complejos como la sustitución o las correlaciones multicanal. Su arquitectura es escalable y consciente de los costos, evitando la trampa de la computación en memoria de fuerza bruta ³ ⁴. La automatización es muy alta, con una mínima necesidad de ajuste manual y un enfoque en producir decisiones, no sólo insights ¹³. El escepticismo que uno podría aplicar a Lokad es menos acerca de si la tecnología funciona - la evidencia sugiere que sí - pero más acerca de si una organización está lista para adoptar una solución tan pesada en ciencia de datos. También está la cuestión del historial a escalas más grandes; Lokad es más pequeño que algunos competidores, aunque tiene clientes notables (por ejemplo, distribuidores de repuestos industriales, eTailers de moda, etc., según sus estudios de caso). Dado todo lo anterior, Lokad se gana un alto ranking como un proveedor de optimización de ecommerce verdaderamente de vanguardia en nuestro estudio.

2. RELEX Solutions - Optimización de Retail impulsada por IA (con Reservas)

RELEX Solutions es un proveedor nacido en Finlandia que ha ascendido rápidamente en el espacio de planificación de retail, a menudo mencionado en la misma respiración que los gigantes legados para el forecasting y la reposición. RELEX ofrece una plataforma unificada que cubre el forecasting de demanda, la reposición de inventario, la asignación, el surtido, la programación de la fuerza laboral, y recientemente la optimización de precios y promociones. Su fortaleza central ha sido en alimentación y retail (incluyendo brick-and-mortar), pero también se comercializan activamente a los jugadores de ecommerce, enfatizando su capacidad para planificar a través de canales online y offline. Para los usuarios puros de ecommerce, el valor de RELEX radica en su planificación de extremo a extremo - asegurando el inventario correcto en el lugar correcto, con el precio y las promociones correctas, utilizando algoritmos avanzados para reaccionar a los cambios de demanda.

RELEX promueve intensamente su uso de IA y machine learning. De hecho, su CEO Mikko Kärkkäinen es un defensor abierto de la “IA pragmática” en el retail. Según Kärkkäinen, los “sistemas de gestión de inventario impulsados por IA procesan cientos de factores que influyen en la demanda” para aumentar la precisión del forecast ¹⁷. Incluso destaca que algo como los datos del clima no es un 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 señales predictivas (clima, promociones, festivos, tendencias en redes sociales, etc.) y usar ML para correlacionarlas con las ventas. La ventaja 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 el hecho de 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 el forecasting, después de un punto, agregar más entradas produce rendimientos decrecientes o incluso puede degradar la precisión si el modelo se ajusta demasiado al ruido. También 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 la IA). Han hablado de proporcionar visibilidad en los forecasts y no solo un resultado, permitiendo a los planificadores ver los impulsores clave. Pero en la realidad, una red neuronal o un modelo de boosting de gradiente con cientos de características no será completamente interpretable. Los planificadores tendrán que confiar en el sistema. Este es un compromiso general con la IA/ML: RELEX está del lado de “lanzar muchos datos al problema y dejar que los algoritmos lo resuelvan”.

¿Esto produce resultados? Los clientes de RELEX a menudo informan de una mejora en el forecasting y menos faltantes de stock, especialmente en situaciones promocionales y estacionales donde los métodos tradicionales tenían dificultades. Por ejemplo, RELEX integra los forecasts del clima y ha afirmado una reducción de hasta el 75% en el error de forecast para ciertos productos sensibles al clima durante condiciones climáticas inusuales ¹⁹. Tomamos tales afirmaciones específicas con un grano de sal - podrían ser seleccionadas cuidadosamente. Sin embargo, es probable que el enfoque de RELEX sí añada valor en el forecasting a corto plazo (“sensibilidad a la demanda”) ajustando los forecasts en función de la información más reciente. En esencia, sus modelos de ML están ajustando continuamente el forecast base con nuevas señales de datos. Esto es similar a lo que algunos llaman sensibilidad a la demanda (usar datos casi en tiempo real para actualizar los forecasts a corto plazo). RELEX, en sus materiales, fusiona la sensibilidad a la demanda en su forecasting de ML más amplio en lugar de tratarlo como un módulo separado. Ellos defienden el “reforecasting continuo y automatizado” a medida que cambian las situaciones.

En el frente de la optimización conjunta, ¿qué tan bien cubre RELEX la fijación de precios y el surtido además del inventario? Históricamente, RELEX fue más fuerte en la reposición y asignación (asegurando que las tiendas o los centros de distribución no se queden sin stock). La planificación del surtido (decidir qué productos van a qué tiendas o qué SKUs llevar) también era parte de su suite, al igual que la optimización del planograma (planificación del espacio). La optimización de precios fue una brecha hasta hace poco, pero en 2022, RELEX introdujo una capacidad de optimización de precios impulsada por IA ²⁰ ²¹. La están posicionando como unificada sin problemas con su planificación de promociones. Por ejemplo, su herramienta de planificación de promociones y la herramienta de optimización de precios comparten los mismos datos y UI, por lo que un minorista puede planificar una promoción y el sistema puede recomendar la profundidad de descuento óptima, el tiempo, etc., y luego se consideran automáticamente las implicaciones de inventario. Esto ciertamente se dirige hacia la optimización conjunta. Sin embargo, no está claro si RELEX realmente optimiza el precio y el inventario juntos o si todavía lo hace de manera secuencial (primero decide el precio, luego se ajusta el flujo de inventario). En una optimización conjunta ideal, considerarías las restricciones de inventario al establecer los precios (por ejemplo, no promociones agresivamente un artículo si el suministro está restringido). La plataforma integrada de RELEX probablemente sí permita este tipo de pensamiento interfuncional, por ejemplo, su sistema notaría “no tenemos suficiente stock en el DC para soportar esta promoción en todas las tiendas” y podría marcarlo o ajustarlo. Mencionan la alineación de los precios y las 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 trae todo (demanda, suministro, operaciones) a una sola plataforma para el usuario. Por ejemplo, los planificadores de mercancías pueden ver los forecasts y las restricciones compartidas entre los 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 la optimización completamente algorítmica. Sospechamos que mientras RELEX proporciona una experiencia de usuario y un modelo de datos muy coherentes, algunas de las decisiones todavía podrían ser secuenciales. La optimización de precios podría generar un precio ideal, luego el módulo de inventario planifica en torno a él. La integración estrecha asegura que no entran en conflicto, pero no necesariamente está resolviendo un único problema de optimización que maximiza 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 explícitamente.

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 base de datos columnar optimizada para series de tiempo y datos jerárquicos) que les permitió calcular forecasts para miles de tiendas x SKUs rápidamente. Muchos estudios de caso citan a RELEX reemplazando hojas de cálculo y sistemas heredados y siendo capaces de manejar mucha más granularidad de datos de inmediato (como pasar de la planificación semanal a la diaria, o de la planificación específica de la tienda en lugar de una talla única para todos). Para el ecommerce, esto significa que RELEX probablemente puede manejar los forecasts a nivel de 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 cálculo eficiente (sus fundadores académicos optimizaron mucho los algoritmos). Una cosa que tienen es un concepto de “base de datos en vivo” 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 bandera roja en el mercado; sirven a grandes cadenas de supermercados con decenas de miles de SKUs y muchas tiendas, lo cual es un volumen de datos análogo o mayor que el que tienen muchos minoristas electrónicos.

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 facilidad de uso, por ejemplo, su interfaz de usuario, paneles de control 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 primeras etapas de adopción). RELEX tiene un concepto de “excepciones de forecast” donde si el forecast de la IA se desvía demasiado debido a alguna anomalía, lo señala. También tienen una capacidad de simulación donde los planificadores pueden ver por qué el sistema está sugiriendo algo (al menos en términos generales, como “debido a que el clima estaba caliente, predecimos un aumento del +50%”). Mikko Kärkkäinen ha declarado: “las soluciones de primera clase aprovechan la IA pragmática y el poder computacional para optimizar tareas… autónomamente sin intervención humana” ²³, y también describe “la planificación minorista autónoma que es autoaprendizaje y autoajuste rompe los silos” ⁵. Así que al menos en visión, RELEX apunta a un sistema en gran medida autónomo. Seguimos siendo ligeramente escépticos de la autonomía completa aquí: los grandes minoristas que utilizan RELEX todavía tienen equipos de planificación. Pero esos equipos probablemente gestionan por excepción ahora, lo cual es una forma de autonomía parcial.

Una de las contradicciones a observar con RELEX (y proveedores similares) es la promesa de una flexibilidad extrema y una automatización extrema. Afirman que el sistema es muy flexible (por ejemplo, uno puede configurar cómo funcionan las reglas de precios, o ajustar los modelos de forecast), pero también afirman que se autoajusta. Hay una tensión: si un usuario puede anular manualmente muchas cosas, el sistema en la práctica podría depender de esos ajustes manuales. Si realmente confían en la IA, deberían tener que anular cada vez menos. La referencia de RELEX a “autoajuste” implica lo último, que el sistema necesitará menos ajustes manuales de parámetros con el tiempo ⁵. Vimos que se menciona que el enfoque de RELEX hace que los planificadores sean 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 ²⁴. Sin embargo, una fuente de SelectHub que agregó revisiones dijo que algunos usuarios encontraron partes de RELEX “torpes” y tuvieron problemas como prever ciertas restricciones (límites de carga) que requerían soluciones alternativas ²⁵. Esto indica que no todo es mágico; los usuarios todavía encuentran límites donde tienen que intervenir o donde la herramienta no es tan fluida.

Problemas o preocupaciones conocidas: No hay casos de “fracaso” documentados públicamente para RELEX como los hay para algunos (no hay titulares de demandas). La empresa generalmente tiene un zumbido positivo. Sin embargo, el chismorreo interno anónimo a veces menciona que implementar RELEX en entornos muy grandes y complejos puede generar problemas. Por ejemplo, la integración de datos puede ser un desafío (basura entra, basura sale: si los datos del cliente son un desastre, RELEX podría generar malos planes, y la culpa recae 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 pueden no recibir la misma atención personalizada que, digamos, proporciona Lokad. Esto no es una crítica del software per se, sino de los resultados del mundo real: ¿cuántos proyectos de RELEX cumplen con los KPI prometidos? A los proveedores les encanta citar las mejoras del mejor caso ("¡Reducción de stock del X% en el cliente Y!"), pero rara vez mencionan casos en los que los números no se materializaron. Sospechamos que RELEX, como 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 confía lo suficiente en el sistema para actuar en consecuencia. En una cumbre de socios, incluso Blue Yonder admitió que una gestión del cambio ineficaz y problemas de datos causan la mayoría de los fracasos de los proyectos ²⁶ - lo mismo probablemente se aplica 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 afluencia de público, etc. Para un jugador de ecommerce, algunos de estos (como la afluencia de público) son irrelevantes, pero otros (clima, tendencias) sí lo son. Uno debería preguntarse: ¿realmente necesito todos estos feeds de datos? Para algunos negocios electrónicos, los modelos simples sobre el historial de ventas podrían ser casi tan buenos. RELEX ciertamente venderá la idea de que más datos producen mejores forecasts. Los resultados de la competencia M5 (en la que RELEX no participó públicamente, que sepamos) mostraron que los modelos sofisticados sí superaron a los más simples, pero a menudo por márgenes pequeños. Los métodos más destacados a menudo eran conjuntos de muchos modelos, no muy diferentes a lo que RELEX podría estar haciendo internamente. Pero curiosamente, un enfoque de machine learning puro no aplastó categóricamente los métodos tradicionales en esos concursos: una combinación de modelos estadísticos cuidadosamente ajustados tendía a ganar. Entonces, si comparamos las afirmaciones de RELEX con benchmarks como M5: vemos que el forecast probabilístico es de hecho valioso (lo cual ellos hacen), pero también vemos que no hay una única salsa secreta entre los enfoques más destacados: se trata de modelar con cuidado. En ausencia de que RELEX publique su precisión en tales conjuntos de datos estándar, permanecemos cautelosos. El consejo del escéptico para cualquiera que esté considerando RELEX es: pida evidencia específica de mejora, y defina un punto de referencia claro. Por ejemplo, si RELEX dice “mejoramos la precisión del forecast en un 30%”, aclare “¿30% en relación con qué métrica y punto de referencia?” Muchas veces los proveedores miden el aumento en comparación con un escenario que favorece a su herramienta (digamos, en comparación con forecasts ingenuos o con un mal año). La orientación de este estudio: exija claridad en los puntos de referencia para cualquier afirmación de rendimiento.

En resumen, RELEX Solutions se clasifica como un proveedor líder porque aborda las áreas clave (demanda, inventario, precios) de manera integrada y utiliza técnicas modernas de AI/ML de manera extensa. Sus fortalezas incluyen un pronóstico muy detallado que tiene en cuenta una miríada de factores, fuertes capacidades de planificación de promociones y temporadas, y una plataforma unificada que proporciona a todas las partes interesadas una única fuente de verdad. Cumple con la escalabilidad (probada en el comercio minorista grande), con el manejo de la canibalización (a través de modelos de forecast avanzados que consideran los efectos cruzados del producto ²⁷), con el marketplace/omni-canal (el sistema puede planificar en línea y fuera de línea simultáneamente y probablemente ingiera datos de la competencia si se proporcionan). RELEX también se inclina hacia la automatización, con afirmaciones de modelos de autoajuste y decisiones autónomas, aunque en la práctica sigue siendo necesaria cierta supervisión del usuario. Las principales advertencias son la complejidad y opacidad que vienen con 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. Clasificamos a RELEX en una posición alta, pero con un asterisco: es una herramienta poderosa, pero que requiere una implementación cuidadosa y una cultura basada en datos para aprovecharla completamente. También alentamos a los usuarios potenciales a estar atentos al “lavado de IA” en la industria; el mensaje de RELEX es uno de los más creíbles (ya que tienen tecnología real debajo del capó), pero incluso las declaraciones de Mikko sobre “cientos de factores” ¹⁷ deben ser vistas como entusiasmo por la IA más que como una garantía de resultados drásticamente mejores que un competidor. En un contexto de ecommerce, RELEX ciertamente puede hacer el trabajo, solo asegúrate de medir sus resultados rigurosamente y mantener un ojo en si todas esas características elegantes realmente se están utilizando en tu caso o simplemente están inactivas en el software.

3. Blue Yonder - Gigante Legado en Transformación (Reclamaciones vs. Realidad)

Blue Yonder (anteriormente conocido como JDA Software) es un gigante en el software de supply chain, con décadas de historia en sistemas de planificación de retail y manufactura. Tiene una suite completa que cubre forecasting, reabastecimiento, gestión de almacenes, transporte, fuerza laboral y precios (después de adquirir al especialista en precios Revionics en 2020). Para los jugadores de ecommerce, Blue Yonder ofrece soluciones originalmente construidas para grandes minoristas y empresas de CPG, piénselo como el gigante empresarial en este espacio. Sin embargo, con ese legado vienen tanto fortalezas (funcionalidad robusta, escalabilidad, experiencia en el dominio) como debilidades significativas (tecnología obsoleta en partes, problemas de integración 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 un poco mixta. Sí tienen componentes para todas las piezas: por ejemplo, su Luminate Demand Edge para forecasting, Luminate Allocation/Replenishment para inventario y Revionics para precios. En teoría, podrías usar los tres y lograr una estrategia coordinada, por ejemplo, el forecasting alimenta tanto el plan de inventario como los modelos de optimización de precios, y la optimización de precios puede tener en cuenta la elasticidad de la demanda (que es esencialmente prever la demanda en diferentes puntos de precio). Blue Yonder ciertamente comercializa la idea de de principio a fin, “de la planificación a la ejecución” unificada bajo su plataforma Luminate. En la práctica, sin embargo, muchos de estos módulos evolucionaron por separado y solo recientemente se unieron. El motor de optimización de precios de Revionics, por ejemplo, tiene su propio patrimonio y se integró después de la adquisición. El desafío de Blue Yonder es hacer que esto se sienta como una solución coherente. La compañía reconoció que históricamente tenían una suite fragmentada; como resultado, en 2023 anunciaron una gran transformación arquitectónica: pasar a un “modelo de datos único y plataforma de aplicaciones” en la nube de Snowflake ²⁸. Esto es un gran problema, esencialmente reingeniería de sus productos para que todos lean/escriban desde un gran repositorio de datos en la nube (Snowflake) para que los silos de datos desaparezcan. El CEO declaró una visión de un “sistema operativo de supply chain para el mundo” donde todas las aplicaciones de BY comparten datos fluidamente ²⁸.

Vemos esta visión como algo prometedor y problemático. Prometedor porque si se logra, de hecho, resolvería muchos dolores de cabeza de integración (no más interfaces por lotes entre la planificación de la demanda y la fijación de precios, por ejemplo, literalmente mirarían los mismos datos en Snowflake). Problemático porque es enormemente ambicioso y riesgoso. Incluso la firma de consultoría asociada de Blue Yonder señaló, “Aunque visionario, creemos que eliminar completamente las integraciones puede ser demasiado optimista para la mayoría de los clientes.” ²⁹. Los clientes tienen datos en muchos lugares, no todo se ubicará ordenadamente en Snowflake, por lo que aún se necesitará una integración personalizada para los sistemas no Blue Yonder ²⁹. En resumen, la estrategia de Blue Yonder es un trabajo en progreso - una respuesta a ser visto como “legado”. Dijeron explícitamente que no forzarán “eventos de acantilado” (abandonar la antigua tecnología de la noche a la mañana) sino que gradualmente convertirán en microservicios los módulos heredados, permitiendo a los clientes migrar a su propio ritmo ³⁰ ³¹. Esto significa que actualmente, un cliente de Blue Yonder todavía podría estar usando, digamos, la antigua planificación de demanda de JDA en prem, con una integración a Revionics en la nube. La plataforma completamente unificada podría estar a un par de años de disponibilidad general. Mientras tanto, la optimización conjunta es más manual con Blue Yonder: podrías usar sus herramientas en conjunto, pero a menudo depende del usuario coordinar (por ejemplo, asegurarse de que las acciones del equipo de precios se alimenten en el plan de inventario).

Blue Yonder sí cumple con muchas casillas de tecnología en papel: ahora incorporan machine learning en el forecast (aprovechando la tecnología de la empresa Blue Yonder GmbH que adquirieron en 2018, que se especializaba en IA para retail). Afirman usar “IA explicable, machine learning e incluso IA generativa” en varias aplicaciones ³². Ciertamente tienen algoritmos avanzados para cosas como optimización de reposición, asignación, etc., desarrollados durante décadas. Pero uno debe ser escéptico porque Blue Yonder también tiene mucha deuda técnica. Muchos de sus algoritmos centrales fueron desarrollados en los años 90 o principios de los 2000 por i2 Technologies o JDA. Han sido mejorados, sí, pero hasta la reciente reescritura en la nube, gran parte de ello se ejecutaba en arquitecturas antiguas (algunas soluciones necesitaban bases de datos Oracle, etc.). Entonces, cuando Blue Yonder comercializa “planificación cognitiva, impulsada por ML”, uno debería preguntarse: ¿es realmente una nueva tecnología o solo una nueva marca? Por ejemplo, su planificación de demanda ahora podría usar ML para estimar los aumentos de forecast para las vacaciones, lo cual es bueno, pero ¿la arquitectura subyacente realmente aprovecha el poder de cálculo en la nube de hoy, o está limitada por haber sido adaptada a un sistema heredado?

Un problema histórico concreto: Blue Yonder (JDA) adquirió i2 Technologies en 2010. i2 era conocido por soluciones pesadas en optimización, pero también conocido por implementaciones fallidas en ocasiones. Famosamente, después de que JDA compró i2, Dillard’s (un gran almacén) ganó una demanda por $246M alegando que el software de i2 no cumplió con las promesas ³³ ³⁴. Esto fue un gran golpe - esencialmente el software y el proyecto fallaron tan mal que el cliente obtuvo daños que excedían 30 veces lo que pagaron por el software. Esa saga, aunque hace 15 años, destaca que incluso los proveedores de alta reputación pueden tener grandes fallos si la tecnología promete demasiado o no se implementa bien. Blue Yonder tuvo que absorber ese costo y aprender lecciones (se espera). Subraya por qué mantenemos escepticismo: los grandes proveedores pueden promocionar “productos de clase mundial” pero existe evidencia de que no funcionan como se anuncia en algunos casos. Todos los proveedores tienen fracasos; Blue Yonder al menos tuvo uno arrastrado por los tribunales públicos.

En crédito de Blue Yonder, se han vuelto más abiertos para abordar los problemas. En su cumbre de socios de 2023, discutieron abiertamente los “proyectos rojos” (implementaciones problemáticas) y encontraron que las principales causas no eran los algoritmos per se, sino “una gestión del cambio ineficaz y problemas con la migración/integración de datos” ²⁶. Señalaron que acertar con los datos y apoyar al cliente en la adaptación de los procesos eran críticos. Esta introspección es buena: significa que Blue Yonder no está ciego a por qué fallan los proyectos. También se alinea con nuestro tema general de análisis: a menudo no es que las matemáticas estén mal, es que la integración en el mundo real es difícil. Que Blue Yonder señale los desafíos de integración de datos es revelador: refleja la complejidad de su suite. Porque si sus módulos estuvieran verdaderamente integrados sin problemas, la migración de datos no sería un dolor de cabeza tan grande. El hecho de que lo sea implica que los clientes pueden haber tenido que hacer una gran reconciliación de datos para usar la suite completa. La capa de datos unificada de Snowflake tiene como objetivo resolver eso, pero como se dijo, es temprano.

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

Demand Forecasting: Blue Yonder Luminate Demand (especialmente con Demand Edge) utiliza machine learning para incorporar muchos factores (clima, eventos, precios). Se han movido hacia los forecast probabilísticos también; al menos admiten el uso de intervalos de confianza o cuantiles en la planificación. Un ejemplo de su blog: no utilizan IA para simplemente superponer factores en una línea de base, sino para reconstruir el forecast desde cero diariamente utilizando los últimos datos, contabilizando automáticamente cosas como los cambios de calendario y autocorrigié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/sub-forecast y los trade-offs de costos ³⁷), y el uso de ML para detectar relaciones complejas (como cómo diferentes climas o promociones impulsan la demanda, sin que un humano codifique explícitamente esas relaciones).
Inventario y Reposición: Esto ha sido durante mucho tiempo una fortaleza de JDA/Blue Yonder. Ofrecen optimización de inventario multi-escalonada (MEIO), lo que significa que pueden optimizar los niveles de stock en los centros de distribución y centros de cumplimiento para ecommerce, teniendo en cuenta los tiempos de entrega, la variabilidad de la demanda, etc., para cumplir con los niveles de servicio objetivo. Las herramientas de Blue Yonder pueden generar cantidades de pedido recomendadas, stocks de seguridad, y así sucesivamente. Históricamente, estos algoritmos eran más basados en reglas/heurísticas o utilizaban programación lineal para problemas específicos. Es probable que ahora estén siendo mejorados con predicciones basadas en ML, pero la optimización central probablemente sea una mezcla de investigación de operaciones y simulación. BY puede manejar sin duda la planificación de SKU a gran escala; muchos minoristas de Fortune 500 utilizaban JDA para la reposición de tiendas, lo cual es análogo en escala a un gran almacén de e-comm que suministra a los clientes.
Surtido: Blue Yonder tiene herramientas de gestión de categorías que ayudan a decidir los surtidos (qué mezcla de productos en qué tiendas). Para un jugador de ecommerce solamente, la planificación del surtido podría significar decidir qué nuevos productos listar o eliminar. Las herramientas de BY pueden utilizar atributos y datos de rendimiento para evaluar los cambios de surtido. Sin embargo, normalmente es 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 comercio minorista (especialmente en las cadenas de supermercados y mercancías generales) para establecer precios base, descuentos promocionales y reducciones de precios. Revionics utiliza IA para modelar la elasticidad de precios e incluso los impactos de la fijación de precios competitiva, luego recomienda cambios de precios que logren objetivos como el crecimiento del margen o los ingresos mientras considera las reglas de precios (por ejemplo, terminar los precios 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 “precios autónomos impulsados por IA”, capaces de funcionar tan a menudo como sea necesario (incluso intradía para ecommerce si se desea).

Una gran pregunta: ¿Qué tan bien funcionan realmente estas piezas juntas hoy en día? Blue Yonder afirma que sí. Por ejemplo, podrían decir que su solución de precios puede tomar los 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 de TI personalizado, el ciclo puede no ser tan estrecho como uno esperaría. Realísticamente, un usuario de ecommerce de Blue Yonder en 2023 podría usar la herramienta de precios por separado de la herramienta de suministro, quizás con actualizaciones semanales por lotes 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 IA/ML, Blue Yonder a veces sufre de bingo de palabras de moda en marketing. Utilizan términos como “cognitivo”, “impulsado por el aprendizaje automático”, etc. Deberíamos inspeccionar si hay sustancia. Hay alguna evidencia de sustancia: por ejemplo, Blue Yonder (la subsidiaria alemana originalmente) había desarrollado algoritmos que se publicaron (su equipo ganó una competencia de forecast de retail temprana en 2014 utilizando redes neuronales). Además, la cartera de patentes de Blue Yonder es grande (más de 400 patentes) lo que indica mucha I+D ³⁸. Sin embargo, la cantidad de patentes no equivale a la calidad del producto, solo muestra 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 números concretos de antes y después? Tienen algunos, pero a menudo los estudios de caso de los proveedores son optimistas y carecen de claridad de línea de base. Blue Yonder dice cosas como “El minorista X vio un aumento del Y% en las ganancias usando nuestros precios”, 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 del proceso empresarial. Blue Yonder normalmente requiere sus servicios profesionales o una empresa asociada para implementar. El costo total de propiedad puede ser muy alto (licencia + servicios + TI). Para un jugador de ecommerce puro, especialmente uno de tamaño mediano, Blue Yonder podría ser excesivo o demasiado lento para implementar en comparación con soluciones SaaS más ágiles. Incluso las grandes empresas a veces se resisten: un evento de la industria revelador fue Lidl (el gran minorista global) cancelando un proyecto de SAP de €500M en 2018 después de que no cumplió con las necesidades ³⁹. Eso fue SAP, no Blue Yonder, pero ilustra que los grandes proyectos pueden fracasar, consumiendo enormes presupuestos. 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 (requiriendo la reimplantació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 la nueva tecnología” sugiere que estas transiciones no son triviales. Blue Yonder está tratando de evitar actualizaciones pesadillescas evolucionando lentamente, pero eso también significa que los clientes pueden estar en una tecnología no del todo moderna ahora, esperando las novedades.

Desde el punto de vista de la automatización, es probable que Blue Yonder hoy en día esté menos automatizado que lo que aspiran a ser Lokad o RELEX. Muchos clientes de BY utilizan las herramientas para generar recomendaciones que luego los planificadores aprueban o ajustan. Blue Yonder promueve el concepto de una “supply chain autónoma” (especialmente desde que fue adquirida por Panasonic en 2021, hablan de conectar los datos de IoT con decisiones automatizadas) ⁴¹. Pero es seguro decir que gran parte de su base de clientes todavía está en un modo híbrido: confiando en el sistema para algunas decisiones, anulando manualmente otras. Por ejemplo, un escenario común es que el sistema sugiere pedidos pero un planificador revisa las excepciones (al igual que con RELEX). O el sistema de precios sugiere cambios de precios, pero un gerente de mercancías los revisa, quizás rechazando algunos que no se alinean 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 mercados: La solución de precios de Blue Yonder (Revionics) incorpora datos de precios competitivos, tiene una función para la respuesta competitiva y puede ingerir los precios de los rivales para ajustar los propios ⁴². Por lo tanto, para el ecommerce, si tienes un feed de precios de la competencia, Revionics puede incluirlo en su optimización (por ejemplo, no tener precios superiores a los de un competidor en más de un 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 mercados, Blue Yonder no tiene específicamente un módulo de gestión de mercado como lo hacen algunos proveedores específicos de e-comm (como las herramientas tipo asesor de canal para Amazon). Por lo tanto, uno podría usar Blue Yonder para la planificación central pero aún necesitaría una herramienta separada para gestionar tácticas específicas del mercado (publicidad, buy-box, etc.). Esto está fuera del alcance de Blue Yonder y no es un golpe para ellos, solo una nota de que el ecommerce tiene facetas que estos proveedores tradicionales no abordan (Lokad o RELEX tampoco cubren la oferta de anuncios, etc., para ser justos).

Dada la escala y el legado de Blue Yonder, también se debe escrutar las contradicciones internas en su mensaje. Por ejemplo, Blue Yonder podría promocionar la “personalización y precios en tiempo real” en su plataforma de comercio, pero sus soluciones de planificación históricamente se ejecutaban en ciclos por lotes (planificación nocturna, replanificación semanal, etc.). Se están moviendo hacia un uso de datos más 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 “precios dinámicos en tiempo real y optimización de inventario”, pregunte: ¿quieren decir que el sistema recalcula continuamente, o simplemente que puede responder rápidamente si se activa? ¿Y realmente necesita tiempo real para las decisiones de surtido? Probablemente no, eso es más estratégico. Por lo tanto, un oído crítico captará cuando el lenguaje de marketing es incoherente. El marketing amplio de Blue Yonder a veces cae en esa trampa de prometer todo (desde la estrategia a largo plazo hasta la ejecución instantánea). Es prudente delinear qué funciones son verdaderamente en tiempo real (por ejemplo, su enrutamiento de transporte podría reaccionar a un pedido en minutos) versus cuáles son inherentemente por lotes (como la planificación de surtido es estacional).

Preocupación por el costo de Snowflake: Deberíamos destacar 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) en función del volumen de datos y la frecuencia de las consultas. Si las aplicaciones de Blue Yonder hacen un gran procesamiento en Snowflake, la factura de Snowflake del cliente podría dispararse. Esto es análogo a la antigua facturación de los mainframes de IBM por MIPS: pagas más cuanto más lo usas, lo que puede desincentivar el uso completo del sistema. Presumiblemente, Blue Yonder y Snowflake acuerdan algún precio, pero el usuario debe estar atento al “shock de factura” si los escenarios de planificación se ejecutan muy a menudo en grandes datos. Es una consideración muy real porque la planificación de la supply chain puede ser computacionalmente intensiva (especialmente si se hacen simulaciones de escenarios o cálculos probabilísticos). Un proceso ineficiente en Snowflake podría consumir muchos créditos. Es probable que Blue Yonder haya pensado en esto (tienen que hacerlo funcionar comercialmente), pero es algo de lo que hay que estar consciente. Un modelo de costos desalineado con el valor empresarial (como cobrar por los datos procesados en lugar del resultado) recuerda las trampas de épocas anteriores.

En conclusión, Blue Yonder se clasifica justo por debajo de las soluciones más nuevas de juego puro en términos de cumplir con la visión “next-gen”. Indudablemente tiene una rica funcionalidad y muchas implementaciones exitosas, pero desde una perspectiva técnica y escéptica, vemos una empresa en transición. Están tratando de modernizarse y al hacerlo hablan muy bien sobre AI, integración y automatización. Sin embargo, hasta que esa transformación se realice completamente, los clientes deben ser cautelosos acerca de las brechas entre los módulos y el esfuerzo real requerido para lograr los resultados prometidos. El conjunto de herramientas de Blue Yonder ciertamente puede soportar operaciones de ecommerce (muchos minoristas grandes con negocios omni-canal utilizan BY para su lado de e-com también), y su amplitud es inigualable (ninguno de los otros proveedores tiene un alcance tan amplio, incluyendo cosas como la logística). Sin embargo, si una empresa de ecommerce solo necesita optimización de demanda y suministro, Blue Yonder podría ser demasiado pesado a menos que específicamente necesiten esa robustez empresarial o ya lo usen en otras áreas. Nuestro estudio escéptico encuentra que las afirmaciones de Blue Yonder de ser de última generación son algo dudosas hasta que se demuestren - la tecnología tiene pedigrí, pero la carga recae en ellos para demostrar que el software de décadas de antigüedad se ha convertido verdaderamente en “AI-first” y unificado. Por ahora, 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 sea la primera opción si la agilidad y el rápido ROI son lo más importante.

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

ToolsGroup es un veterano en el espacio de planificación de la 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 basada en el nivel de servicio y la optimización de múltiples niveles. En términos más simples, ToolsGroup se destacó por ayudar a las empresas a determinar “¿cuál es el inventario mínimo que necesito en cada ubicación para alcanzar el nivel de servicio X?” bajo incertidumbre - un problema crítico para la distribución y el ecommerce por igual. ToolsGroup fue uno de los primeros en implementar forecast probabilístico comercialmente, y durante mucho tiempo abogó por alejarse de los forecast determinísticos y usar la distribución completa de la demanda ⁴³ ². Este enfoque está muy alineado con lo que consideramos de última generación hoy (y que otros proveedores adoptaron más tarde).

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

Aunque históricamente ToolsGroup se centró en el inventario y la demanda, en los últimos años reconoció que los precios, las promociones y el surtido son piezas complementarias que no ofrecía. Para abordar esto, ToolsGroup adquirió una empresa llamada JustEnough en 2018/2019 (JustEnough fue luego parte de Mi9 Retail y luego vendida a ToolsGroup). El software de JustEnough cubría planificación financiera de mercancías, planificación de surtido, asignación y optimización de reducción de precios - esencialmente funciones de merchandising minorista incluyendo reducciones de precios. Con esta adquisición, ToolsGroup expandió su huella desde la supply chain pura a lo que podrías llamar planificación minorista. Ahora comercializan una suite integrada que puede hacer todo, desde la planificación de alto nivel hasta la ejecución, con la combinación de las 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 versión de la verdad ⁴⁴). Incluso lanzaron algo llamado “Retail en Tiempo Real” que conecta el sistema de planificación de JustEnough con un Hub de Inventario para obtener feeds de datos casi en tiempo real ⁴⁵ ⁴⁶. La idea es que a medida que ocurren las ventas (o a medida que se mueve el inventario), esos eventos fluyen instantáneamente al sistema de planificación, y puede replanificar la asignación o reposición al vuelo. Esto sugiere que ToolsGroup está tratando de habilitar 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 desempaquemos eso: ToolsGroup llamando a su solución “Retail en Tiempo Real, la única solución que responde al comportamiento de compra en el momento” ⁴⁵ es una afirmación fuerte. Básicamente implica que pueden ajustar el plan tan pronto como algo cambie. Quizás el sistema pueda desencadenar automáticamente una transferencia de stock o acelerar un pedido si las ventas aumentan inesperadamente hoy. Si es cierto, eso es poderoso - difumina la planificación y la ejecución. Sin embargo, la interpretación escéptica es que “en tiempo real” probablemente esté limitado a ciertas funciones (como la reasignación de inventario, que es más fácil de hacer rápidamente) y no a otras (como reoptimizar completamente un surtido, que no harías en tiempo real). También vale la pena señalar que cada proveedor está usando “en tiempo real” en marketing ahora (a menudo significando una actualización cada pocos minutos o cada hora, lo cual está bien). La CEO de ToolsGroup misma señaló que los minoristas necesitan pivotar rápidamente para prevenir la erosión del margen cuando la demanda cambia ⁴⁷, lo cual es cierto. Se dice que el sistema recalcula automáticamente y recomienda pedidos o transferencias 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 JustEnough, luego alimentar eso en los objetivos de inventario en SO99+, y también planificar precios de liquidación para productos de fin de vida utilizando su optimización. Eso cubre aspectos de optimización conjunta, especialmente si las previsiones de demanda y los parámetros de inventario tienen en cuenta el calendario de liquidación planificado. Todavía es posiblemente un proceso secuencial (primero decidir las liquidaciones, luego ver el resultado del inventario) a menos que hayan construido un modelo de optimización combinado (lo cual es poco probable en esa amplitud). Pero es una solución unificada en términos de flujo de datos.

Donde ToolsGroup claramente cumple con los criterios de estado del arte es en forecast probabilístico y optimización del nivel de servicio. Han insistido durante años en que las previsiones de un solo número son insuficientes y que se debe planificar con probabilidades. Por ejemplo, producirán no solo “demanda esperada = 100” sino una curva que muestra que hay un 10% de posibilidad de que la demanda sea >120, etc. Luego, su optimización utiliza eso para decidir los niveles de stock de manera que, digamos, el 95% del tiempo se pueda satisfacer la demanda ⁴⁹ ⁵⁰. Este enfoque maneja inherentemente la incertidumbre e incluso la canibalización hasta cierto punto (especialmente si usas su modelado para artículos correlacionados). Un aspecto interesante: ToolsGroup a menudo argumentó que el uso de forecast probabilístico puede extender la vida de los sistemas de planificación ERP heredados (como SAP APO) al alimentarlos con mejor información ¹ ⁵¹. Esto subraya que el diferenciador de ToolsGroup estaba principalmente en la matemática de forecast e inventario en lugar de ser una interfaz de planificación todo en uno.

Ahora, ¿qué pasa con la automatización y facilidad de uso? Tradicionalmente, ToolsGroup era más un “motor de back-end” con una interfaz de usuario algo torpe, según algunos usuarios. Desde entonces han mejorado la interfaz (nueva interfaz web, etc.). Pero más importante aún, enfatizan la automatización en la planificación. Sus materiales afirman, por ejemplo, “la automatización incorporada reduce la carga de trabajo de planificación hasta en un 90%” ⁵². También citan a menudo a clientes que logran una “reducción de la carga de trabajo del planificador del 40-90%” y una “reducción del inventario del 20-30%” después de usar ToolsGroup ⁵³ ⁵⁴. Esos son números grandes. La afirmación de reducción de inventario es plausible si una empresa era muy ineficiente antes o mantenía excesivos buffers debido a la falta de confianza en los forecast. La reducción de la carga de trabajo del planificador implica que el sistema está haciendo mucho más automáticamente. Esto se alinea con lo que esperamos: un sistema probabilístico debería reducir la lucha contra incendios (ya que planificas para la incertidumbre, ocurren menos sorpresas, por lo que los planificadores no están acelerando tanto ni reasignando stock manualmente a último minuto). Sin embargo, un escéptico notaría que la reducción de la carga de trabajo del 90% probablemente sea el extremo superior (quizás un caso en el que una empresa pasó de 10 planificadores a 1 después de implementar, posible pero no típico). Y 20-30% menos de inventario podría ser el resultado de que inicialmente la empresa llevaba demasiado “por si acaso”. En supply chain, una vez que optimizas, a menudo ves quizás reducciones del 10-15% si las cosas estaban moderadamente bien antes. Así que sospechamos que los rangos publicitados por ToolsGroup ⁵³ son escenarios de mejor caso. Es instructivo que los presenten como rangos, implica que los resultados varían ampliamente por cliente.

Una cosa que ToolsGroup tiene a su favor es la estabilidad y enfoque específico. Han estado haciendo optimización de supply chain durante 30 años (fundada en 1993). No son tan grandes como Blue Yonder o tan modernos como RELEX, pero tienen una base de clientes leales y una profunda experiencia en el dominio. Para una empresa de ecommerce principalmente preocupada por la rentabilidad del inventario - es decir, no tener demasiados faltantes de stock o sobre stocks - 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 almacenes 3PL, etc. Apropiadamente empujará el inventario a donde más se necesita mientras mantiene los buffers centrales delgados.

Sin embargo, el punto más débil de ToolsGroup fue la optimización de precios. La adquisición de JustEnough les dio la optimización de markdown (decidir los horarios de descuento para la liquidación). Eso es útil para el ecommerce con productos de temporada o de moda. Pero todavía carecen de una verdadera optimización de precios dinámicos como la que tienen Revionics/Blue Yonder o algunos proveedores de precios especializados. La optimización de markdown es sobre el precio de fin de vida o promocional. La optimización regular del precio diario (para el margen o la posición competitiva) no es una fortaleza bien conocida de ToolsGroup. Podrían tener capacidades básicas o aprovechar a los 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 tienen motores de precios dedicados. ToolsGroup todavía podría optimizar el inventario asumiendo un precio dado, pero no te dirá el mejor precio para establecer para maximizar el beneficio (aparte de los escenarios de liquidación de fin de vida). Esta es una distinción importante: su “optimización” es principalmente orientada al suministro (niveles de stock, reposición) en lugar de formar la demanda (precios, promoción) - a pesar de agregar algunas herramientas de formación de demanda a través de la adquisición.

En términos de tecnología stack, ToolsGroup ahora ofrece una opción de SaaS en la nube e incluso posiciona algunas de sus ofertas bajo nombres geniales como “Inventory Hub” y “Fulfill.io”. Esto muestra que están tratando de modernizarse y quizás atraer a un mercado más amplio, incluyendo empresas de comercio electrónico de tamaño medio. El motor subyacente todavía utiliza métodos estadísticos avanzados, y probablemente C++ o similar para el cálculo. No hemos oído hablar de que ToolsGroup haya golpeado muros de rendimiento; tienen referencias de clientes con millones de combinaciones de SKU-ubicación. Si acaso, el talón de Aquiles de ToolsGroup podría ser que se vea como una “herramienta de optimizador” - poderosa pero que requiere configuración por expertos. Han intentado simplificar con más ML listo para usar. Por ejemplo, incorporan demand sensing (usando 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 desmintieron 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 el sesgo históricamente ⁵⁶. Esto refleja un enfoque equilibrado: no eliminan totalmente al humano, pero guían al humano 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 está agotado, parte de la demanda se traslada a otro). Sin embargo, esto probablemente requiere esfuerzo para establecer relaciones o usar su ML para agrupar artículos. No está claro cuán automático es esto. Pero ToolsGroup sí enfatizó lidiar con “long tail, demanda intermitente, y más canales” en un blog de 2017, básicamente diciendo que estas condiciones rompen las herramientas tradicionales y requieren métodos probabilísticos ⁵⁷. Mencionan específicamente “más canales para llegar al mercado, con demanda agregada proveniente de múltiples corrientes” como un escenario donde los forecast de un solo número se rompen, insinuando que su solución maneja mejor el multi-canal ⁵⁷. Así que un e-tailer que vende en su sitio web y en Amazon, por ejemplo, podría usar ToolsGroup para planificar la demanda combinada. La herramienta produciría un forecast total y quizás te permita asignar el inventario por canal de manera óptima (aunque la asignación de canales suele ser más sencilla cuando todo se envía desde los mismos centros de cumplimiento, pero en caso de existir pools de stock separados, importa).

Un aspecto a tener en cuenta con ToolsGroup (como con cualquier proveedor de suite adquirida) es la consistencia de la experiencia del usuario. ¿Están los módulos de forecast, inventario y surtido todos en una UI ahora, o se siente como saltar entre sistemas? Han trabajado en unificar la interfaz, pero se necesitaría retroalimentación del usuario. No está tan unificado como la única plataforma de RELEX construida en casa, presumiblemente.

En términos de historial, ToolsGroup tiene muchos estudios de caso 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 lo hicieron 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 fabricación/distribución, algunas personas de retail/ecommerce no los conocen tan bien. Su incursión en el retail a través de JustEnough significa que algunos clientes más antiguos de JustEnough ahora usan ToolsGroup. JustEnough en sí tenía críticas mixtas (era decente en la planificación pero quizás limitado en escalabilidad - no está claro). Entonces, ToolsGroup tuvo que reforzar esos módulos. Como escépticos, aconsejaríamos verificar cuán integradas están realmente las analíticas. Por ejemplo, ¿puede el sistema reconocer automáticamente que una promoción planificada en el módulo JustEnough debería ajustar el forecast de demanda en SO99+? Probablemente sí, habrían integrado aumentos promocionales. Mencionan que “los insights de demand sensing ayudan a afinar el forecast estadístico” ⁵⁸ lo que implica que tienen en cuenta cosas como promociones o tendencias recientes para ajustar los forecast base.

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

¿Forecasts probabilísticos? Sí, ellos han sido los campeones de eso ⁴⁹ ⁴³.
¿Optimización económica? Implícitamente sí para el inventario (optimizan el servicio frente a los trade-offs de costos), aunque no tan explícitamente en ganancias como lo hace Lokad. Es más “alcanzar el objetivo de servicio con el mínimo inventario” que es una forma de optimización de costos.
¿Escalabilidad? Generalmente sí, no hay alarmas. Y su enfoque es eficiente (no es a la fuerza bruta).
¿Canibalización? Posiblemente, a través de modelado avanzado, pero no es su principal reclamo de fama.
¿Mercado/competitivo? No inherentemente - eso lo manejarías externamente o a través de entradas. ToolsGroup no rastreará los precios de la competencia por ti o algo así.
¿Automatización? Sí, alta. Después de la configuración, muchas tareas de planificación pueden ser automatizadas con su sistema emitiendo propuestas de pedidos que los planificadores simplemente aprueban. Ellos promocionan grandes recortes de 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 tomamos con precaución. Se centran en lo que hace la tecnología (sus blogs educativos sobre planificación probabilística son sustanciales, no solo relleno). Pero se unen al juego de palabras de moda de la IA ahora, llamando a todo “impulsado por la IA”. Sin embargo, notamos que mantienen un pie en la OR tradicional (investigación de operaciones) y otro en ML, que es una mezcla saludable.

Un punto de datos externo: Las revisiones de firmas de analistas (como Gartner) a menudo ponen a ToolsGroup en el liderazgo para la Planificación de la Supply Chain, pero podrían comentar que la capacidad de ToolsGroup es más profunda que amplia, y la UI era históricamente menos moderna. Esto se ha abordado parcialmente ahora (nueva UI, integración).

Para un jugador puro de eCommerce, la decisión de ir con ToolsGroup probablemente dependería de si la optimización de inventario es el principal punto de dolor y si necesitan una solución probada, algo autónoma para eso. Si es así, ToolsGroup podría ser una gran opción, ofreciendo victorias rápidas en la reducción de stock y la mejora del servicio. Sin embargo, si el negocio de eCommerce también está buscando optimizar mucho los precios o hacer estrategias de reducción de precios omnicanal de vanguardia, ToolsGroup podría no ser tan rico en características allí como un Blue Yonder o RELEX o una herramienta de precios dedicada. Podría requerir emparejarse con otra solución de precios, lo que luego trae desafíos de integración. (Curiosamente, ToolsGroup podría no oponerse a eso: históricamente a veces coexistían con otros, centrándose en el inventario mientras otro sistema hacía los precios.)

En conclusión, ToolsGroup se clasifica como un proveedor especialista convertido en suite técnicamente sólido. Apreciamos su rigor de ingeniería en el forecast y su abordaje sin tonterías de la incertidumbre (hace tiempo que desacreditaron el problema de “el forecast siempre está equivocado” planificando con probabilidades). Nos mantenemos cautelosos acerca de la reciente expansión: 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 se muestran grietas (como datos que necesitan exportación/importación manual entre módulos), eso socavaría el argumento. Pero a partir de la información disponible, ToolsGroup parece estar ofreciendo una experiencia más unificada después de JustEnough. Incluso se alinean con la tendencia del uso de datos en tiempo real en la planificación, lo cual es encomiable.

Finalmente, tal como lo hicimos con otros: escrutinio de las afirmaciones del proveedor para ToolsGroup. Cuando dicen, por ejemplo, “90+% de disponibilidad de producto, 20-30% menos de inventario, 40-90% de reducción de carga de trabajo” ⁵³ ⁵⁴ – un escepticismo saludable es ver estos como resultados alcanzables pero no garantizados. Esos números probablemente provienen de diferentes clientes que alcanzan cada uno de esos altos niveles, no un cliente que alcanza todos simultáneamente. Nadie debería esperar que su inventario caiga un 30% mientras el servicio salta a >90% y los planificadores se reducen en un 90% todo de una vez. La realidad suele implicar compromisos y mejoras incrementales. La metodología de ToolsGroup absolutamente puede impulsar una mejora significativa, pero aconsejaríamos establecer objetivos realistas y medir a medida que avanzas. La buena noticia es que el enfoque de ToolsGroup en resultados medibles (porcentaje de servicio, inventario $$) se ajusta a un enfoque de búsqueda de la verdad: es muy claro si está funcionando o no al mirar esas métricas.

Cortando el Hype: Lecciones y Recomendaciones

Entre estos proveedores, surgieron algunos temas comunes de hype vs realidad que un tomador de decisiones de eCommerce debería tener en cuenta:

Cuidado con las Palabras de Moda: Términos como “impulsado por IA, cognitivo, detección de demanda, en tiempo real, autónomo” se usan con liberalidad. Asegúrate de que estén respaldados por capacidades concretas. Por ejemplo, “detección de demanda” a menudo suena genial: usa las ventas de ayer o el parloteo en las redes sociales para ajustar el forecast de hoy, pero en la práctica puede que solo ajuste ligeramente los números y básicamente es solo un forecast a corto plazo. Los expertos de la industria han etiquetado la detección de demanda como posiblemente “mootware” – algo que existe pero no entrega valor material más allá de lo que ya hace un buen forecast ⁵⁹. No compres conceptos de “vaporware” sin evidencia. Pregunta al proveedor: ¿qué hace exactamente tu IA que mi proceso actual no puede hacer, y puedes demostrarlo? Si dicen “consideramos 300 factores”, desafíalos sobre si esos factores realmente mueven la aguja o simplemente hacen una diapositiva bonita.
Línea de Base y Referencias: Siempre establece una línea de base clara (por ejemplo, las rotaciones de stock del año pasado, la tasa de cumplimiento, el margen bruto) y ve si el proveedor aceptará medir la mejora contra ella. Muchos reclaman mejoras porcentuales que suenan enormes pero son insignificantes sin contexto. Además, busca cualquier participación en referencias externas (como competencias de forecast o estudios de caso públicos con números duros). La competencia M5 fue una de esas referencias que separó el trigo de la paja en el forecast: notablemente, ninguno de los grandes proveedores tradicionales publicó resultados allí, mientras que un jugador más pequeño (Lokad) lo hizo y sobresalió ⁶⁰. Eso te dice quién tiene confianza en su tecnología.
Complejidad de Integración: Si un proveedor creció a través de adquisiciones (Blue Yonder, ToolsGroup), desconfía de las promesas de que “ahora es una sola plataforma”. A menudo, lleva años integrar verdaderamente. Durante ese tiempo, podrías estar utilizando efectivamente sistemas separados con algunas interfaces. Puede haber costos ocultos en la implementación para conectar las cosas. Además, dos componentes adquiridos pueden no compartir la misma noción de ciertos datos (por ejemplo, uno usa cubos semanales, otro diario, o diferentes definiciones de jerarquía de productos). Esto puede llevar a compromisos o desalineaciones. Es prudente 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 ejecución (si corresponde) y la infraestructura requerida. Como se mencionó, una solución que depende de algo como Snowflake puede pasar esos costos de ejecución en la nube a ti. O una solución que es muy pesada en memoria podría obligarte a entrar en instancias de nube de alto nivel. Un proveedor podría cotizar una tarifa de suscripción más alta pero incluye todos los cálculos; otro podría ser más barato pero tú pagas una gran factura de AWS/Azure por la computación necesaria. Asegúrate de estar comparando el costo total de propiedad. Mencionamos cómo el modelo de Snowflake podría hacer eco de las trampas de la mainframe de IBM: mantén un ojo en las tarifas basadas en el uso y exige transparencia a los proveedores que utilizan ese modelo.
Todos los Proveedores Tienen Fracasos: Es importante recordar, ningún proveedor destacará sus proyectos fallidos, pero todos los tienen. La implementación es tan importante como la herramienta. Vimos cómo incluso los principales proveedores como SAP o i2 (ahora bajo Blue Yonder) tuvieron fracasos multimillonarios ³⁹ ³³. A menudo las razones son datos deficientes, expectativas desalineadas, o la empresa no adopta las salidas del sistema. Al evaluar, pregunta a los proveedores cómo manejan los proyectos que no están alcanzando los objetivos. ¿Tienen ejemplos (anonimizados) de lecciones aprendidas? Blue Yonder mostró cierta 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 discusiones sobre qué podría salir mal y cómo lo mitigan.
Contradicciones en Tiempo Real vs Profundidad Analítica: Como se mencionó, algunas analíticas (como la planificación de surtido a nivel de red) no pueden ser verdaderamente en tiempo real: requieren un procesamiento de datos sustancial 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 se corresponden con qué 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 tiempo casi real, pero planificar ciertas cosas (como la optimización de precios basada en IA) podría seguir siendo 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 la fijación de precios dinámica sobre la marcha), pero para las decisiones estratégicas, la profundidad y rigor importan más que la velocidad.
Anulación Humana vs Autonomía: Todos los proveedores reclaman algún nivel de autonomía, pero también que permiten la entrada humana. Es un espectro. La pregunta clave: ¿El sistema por defecto opera sin atención con solo excepciones señaladas, o por defecto necesita revisión del usuario para cada decisión? Para verdaderas ganancias de eficiencia, quieres lo primero. Una señal de alarma 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 mucho cuidado para obtener buenos resultados (lo que contradice la promesa de automatización). Idealmente, la herramienta debería autoajustar esas palancas (como Blue Yonder eliminando la necesidad de perfiles estacionales establecidos manualmente usando ML ³⁶). Confía pero verifica: durante las demostraciones o pruebas, ve cuánto ajuste manual se requirió para que los resultados de la demostración se vean bien.
Especificaciones de IA/ML: Profundiza en las afirmaciones de IA del proveedor. Pregunta: ¿Están utilizando machine learning para el forecast? ¿Qué algoritmos (si pueden decir)? ¿Utilizan alguna biblioteca de código abierto (si todo es propietario, a veces eso es una señal de que no han seguido las últimas técnicas; todas las soluciones líderes de IA incorporan código abierto como TensorFlow/PyTorch o al menos algoritmos bien conocidos)? Si un proveedor hace gestos sobre un “motor de IA 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 de base y un modelo de aprendizaje por refuerzo para la fijación de precios”, eso muestra 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 en busca de la verdad: insiste en datos y resultados de pruebas sobre promesas brillantes. Si es posible, realiza un piloto o prueba de concepto donde a cada proveedor se le da un subconjunto de tus datos para hacer un forecast o optimizar, y evalúa los resultados cuantitativamente. Por ejemplo, alimenta dos años de historia y déjalos hacer el forecast del tercer año (para el cual tienes datos reales): ve 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 de coste/servicio utilizando tu demanda real para validar. Pocos proveedores se ofrecerán voluntariamente a un enfrentamiento, pero los buenos a menudo lo harán porque respaldan su ciencia. Lokad, por ejemplo, a menudo se involucra a través de proyectos piloto. Blue Yonder y RELEX a veces hacen fases de “descubrimiento” que se asemejan a los pilotos. Solo asegúrate de tener criterios de éxito claros para estos.

Al final, el mercado de software de optimización de ecommerce no tiene escasez de autoproclamados “milagros de IA”, pero aplicando un profundo escepticismo y requiriendo 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 unificada de retail (con algo de exageración a tener en cuenta), Blue Yonder en amplitud y experiencia (en medio de una difícil revisión tecnológica), y ToolsGroup en fortalezas de optimización especializadas (con integración creciente). Cada uno puede ofrecer beneficios significativos, pero ninguno es una panacea plug-and-play. La verdad es que la optimización exitosa proviene de la herramienta correcta y la estrategia de implementación correcta. Con los puntos de vista y advertencias expuestos anteriormente, una empresa de ecommerce puede acercarse a estos proveedores con los ojos claros y tomar una decisión basada en hechos y razonamientos sólidos, no solo en el atractivo del marketing.