Volver a Investigación de mercado
Algonomy ofrece software minorista para previsión de demanda, reabastecimiento, gestión comercial, colaboración con proveedores, datos de clientes y personalización de ecommerce. Order Right genera recomendaciones de compra y traslado; Vendor Link conecta a minoristas y proveedores. ADA completó la adquisición de Algonomy en julio de 2026 y está reuniendo el negocio combinado bajo la marca ADA. (1, 2)
Puntuación global en supply chain: 3,9/10
| Dimensión | Puntuación |
|---|---|
| Profundidad en supply chain | 3,6/10 |
| Sustancia de las decisiones y la optimización | 4,4/10 |
| Integridad del producto y la arquitectura | 4,2/10 |
| Transparencia técnica | 4,2/10 |
| Seriedad del proveedor | 3,2/10 |
Order Right sigue un proceso identificable: prever la demanda de productos, aplicar restricciones de reabastecimiento y devolver recomendaciones de pedido. El material público describe restricciones minoristas e integraciones operativas, pero deja sin explicar el cálculo económico central. No establece cómo se valoran pedidos que compiten entre sí bajo incertidumbre conjunta de demanda y suministro. Una gran colección de algoritmos de previsión no puede suplir esa carencia.
La comunicación agrava esta debilidad. ADA anuncia una precisión del 97 % en la previsión de demanda sin la definición necesaria para interpretarla. La historia de Algonomy también abarca desde un asistente analítico similar a un humano anunciado en 2017 hasta el posicionamiento agéntico actual, con escasa continuidad medida entre la promesa y el trabajo eliminado. La evidencia más clara de productividad concierne a la administración de proveedores, mientras que el motor numérico de reabastecimiento sigue siendo difícil de examinar. (3, 5, 10, 15)
Algonomy frente a Lokad
La diferencia práctica reside en quién escribe y mantiene la lógica que decide qué comprar, trasladar o rebajar. Algonomy ofrece módulos empaquetados de previsión y reabastecimiento, configurados por sus ingenieros y respaldados por especialistas en datos, aplicaciones y modelización. Los minoristas aportan las políticas operativas y pueden modificar las recomendaciones. Su oferta de gestión comercial añade interfaces analíticas y conversacionales para los equipos de categorías. (2, 13)
El enfoque de Supply Chain Quantitativa de Lokad organiza el trabajo alrededor de decisiones ejecutables valoradas monetariamente bajo incertidumbre. Un Supply Chain Scientist prepara los datos, formaliza la lógica de decisión, implementa la supervisión y mantiene el proceso de producción dentro del servicio gestionado. Las prioridades económicas y las acciones disponibles forman parte de ese cálculo mantenido.
Pensemos en productos frescos que comparten espacio de estantería y una entrega del proveedor. Pedir con mayor frecuencia puede reducir el desperdicio y aumentar los costes de transporte y recepción; rebajar un producto puede desviar la demanda de otro. El problema de ingeniería consiste en comparar estas acciones acopladas y sus consecuencias financieras inciertas. Algonomy documenta entradas de previsión, restricciones de pedidos y funciones comerciales, pero no expone un cálculo común que resuelva esas compensaciones.
Ambas ofertas requieren mantenimiento cuando cambia el negocio. El coste relevante es el esfuerzo de corregir una regla de decisión defectuosa, probarla en todo el surtido y desplegar la corrección. Introduction to Supply Chain de Lokad explica esta perspectiva económica; su implementación también debe justificar el coste del servicio mediante mejores decisiones y menor trabajo recurrente.
Qué calcula Order Right
Las preguntas frecuentes de Order Right describen previsiones multivariantes por SKU y ubicación, con métodos jerárquicos para series dispersas y selección automática entre modelos candidatos. Los resultados abarcan compras de tiendas, compras de almacenes y traslados, entregados mediante Excel o una interfaz de órdenes de compra del ERP. (2)
La ficha técnica de 2022 aporta más detalle sobre la etapa de decisión. Las previsiones alimentan algoritmos propios de reabastecimiento que consideran caducidad, vida útil, tiempo de entrega, cantidades mínimas de pedido y exposición, y frecuencia de pedido. Los usuarios eligen un nivel de riesgo; el posible desperdicio puede intervenir en la selección del modelo. Son controles útiles, pero el documento no aporta un objetivo monetario, un modelo probabilístico detrás del ajuste de riesgo ni un algoritmo para conciliar recursos escasos entre productos. (3)
Esta distinción importa cuando la previsión es razonable y la recomendación sigue siendo mala. Una caja completa puede superar la cantidad económicamente conveniente. Aceptar una pequeña pérdida de disponibilidad puede ahorrar más desperdicio de lo que cuesta en margen perdido. Un camión o presupuesto compartido puede convertir el mejor pedido individual en un uso inferior de los recursos. Un motor de reabastecimiento necesita valoraciones explícitas para esas decisiones; mejorar únicamente la previsión no las proporciona.
La página del producto para alimentación describe cambios por promociones, predictores meteorológicos, calendarios de entrega configurables y alertas de caducidad por producto. La página de previsión también afirma predecir la canibalización entre productos similares. Ningún experimento publicado separa la demanda promocional incremental de las ventas trasladadas entre productos. Esa separación determina si abastecer una línea promocionada genera beneficio o simplemente desplaza la misma venta. (4, 5)
La incertidumbre del suministro sigue sin resolverse
Las preguntas frecuentes públicas identifican el tiempo de entrega contractual y las fechas previstas de llegada como entradas. El caso del minorista alimentario del sudeste asiático afirma que la aplicación modeliza dinámicamente parámetros de suministro y coordina inventario entre varios escalones. Ninguna fuente explica distribuciones de fechas reales de recepción, faltantes correlacionados ni cómo la incertidumbre aguas arriba cambia las compras aguas abajo. (2, 6)
Una entrega tardía del proveedor puede afectar a varias tiendas a la vez, mientras una promoción cambia tanto la demanda como la sustitución. Calcular una previsión de demanda para cada ubicación y actualizar un parámetro de tiempo de entrega no demuestra un tratamiento económico de esos riesgos conjuntos. Falta la evidencia de un modelo calibrado de resultados posibles conectado al cálculo de pedidos.
Algonomy anuncia modelos probabilísticos de demanda en su oferta de consultoría Databricks. Este servicio a medida no publica detalles distributivos ni de calibración, y no identifica el modelo utilizado dentro de Order Right. La conexión entre esos modelos y los cálculos de pedidos en producción permanece sin explicar. (9)
Afirmaciones de precisión que ocultan el problema de planificación
La página de previsión de ADA muestra 97 % de precisión en la previsión de demanda. No aporta fórmula de error, horizonte, agregación, ponderación, exclusiones ni evaluación fuera de muestra. Un segundo caso afirma superar el 95 % de precisión por tienda, producto y SKU, de nuevo sin definir la medición. Son deficiencias graves en un producto vendido por la calidad de sus previsiones. (5, 23)
La competición histórica M5 de comercio minorista ilustra por qué importa esa definición. Recalcular 100 × (1 − WAPE) sobre los últimos 28 días de las 50 mejores propuestas de previsión puntual publicadas por los organizadores da aproximadamente 22,1–25,1 % por SKU/tienda/día, frente a 95,8–98,2 % al agrupar productos y tiendas por día. El ganador global alcanza aproximadamente 99,8 % si también se agrupan esos días. Son recálculos diagnósticos de las previsiones publicadas, no la métrica oficial de puntuación de M5. (8)
La agregación permite que un porcentaje impresionante coexista con grandes errores donde se toman las decisiones de reabastecimiento. Compensa faltantes con excedentes que físicamente no pueden compensarse: más yogur en una tienda no satisface al cliente que busca pan en otra. El 97 % de Algonomy no puede situarse en este espectro y, por tanto, no demuestra ni precisión útil por SKU ni retornos económicos.
El caso del sudeste asiático hace una afirmación diferente: la previsión mejoró para el 90 % de los SKU. Eso mide la proporción de series mejoradas, no un 90 % de precisión. El caso también describe menos faltantes de stock e inventario, pero no ofrece una evaluación reproducible que conecte los cambios de previsión con esos resultados. (6)
Una validación útil congelaría las previsiones antes del plazo de pedido relevante, las evaluaría en el horizonte producto-ubicación de la acción y seguiría los pedidos resultantes hasta el margen, desperdicio, disponibilidad y costes de manipulación. Un porcentaje elevado de precisión despojado de ese contexto incentiva precisamente el criterio de compra equivocado.
Historia tecnológica: de la inteligencia conversacional a los agentes
2017: Maya y la promesa de una analítica similar a la humana
Manthan anunció Maya en enero de 2017 como agente conversacional impulsado por IA para analítica empresarial. El comunicado describía una interacción con la analítica de empresa como si fuera con una persona, respuestas adaptadas al rol, aprendizaje continuo e integración con Amazon Alexa. La presentación anunciada tendría lugar en la convención minorista NRF. (10)
El mecanismo divulgado era una entrada conversacional a la analítica. El comunicado no documentaba cobertura fiable de tareas, tasas de fallo, decisiones empresariales autónomas ni ahorros de trabajo medidos. El lenguaje sobre inteligencia excedía ampliamente la evidencia aportada. Las capacidades actuales de los LLM no pueden validar retroactivamente aquellas afirmaciones.
2021–2022: una plataforma unificada y miles de algoritmos
El anuncio de fusión de RichRelevance y Manthan en 2021 promovía una plataforma unificada de decisiones minoristas y más de 300 algoritmos preconstruidos para el negocio. Sus ejemplos concretos se centraban en personalización, activación de clientes, analítica y procesos comerciales. (11)
En enero de 2022, Algonomy anunció su intención de adquirir el negocio de previsión de Linear Squared, sujeta a autorizaciones. Ese mismo año, la ficha de Order Right describía un reabastecimiento automatizado basado en previsiones. (12, 3) Esto concretó la propuesta de producto para supply chain, pero no publicó la formulación de optimización ni la regla financiera de decisión.
Las preguntas frecuentes actuales promueven más de 2.000 algoritmos de previsión candidatos y una ventaja general de al menos 20 puntos porcentuales frente a métodos tradicionales. (2) Contar algoritmos no revela ni diversidad de métodos ni rendimiento con datos no vistos. Elegir entre más candidatos puede aumentar el trabajo de validación y mantenimiento, especialmente cuando muchos historiales de productos contienen poca información.
2026: lenguaje agéntico, pasos operativos conocidos
La página actual de planificación de suministro de ADA describe a Maya respondiendo preguntas empresariales y recomendando acciones. La página de reabastecimiento ahora denomina sus previsiones impulsadas por GenAI, aunque sigue describiendo la secuencia de integrar datos, prever demanda, generar pedidos y actuar sobre alertas. Ninguna explicación técnica publicada identifica la contribución del modelo generativo a la predicción numérica de demanda. (13, 25)
La colaboración con proveedores se promueve por separado mediante Vendor Link y ATLAS: incorporación, previsiones compartidas, intercambio de órdenes de compra, validación de envíos, conciliación de facturas y colaboración promocional. (14) Estas actividades pueden automatizarse, pero atribuir productividad adicional a los agentes exige compararla con la automatización de procesos ya entregada.
El problema histórico es la responsabilidad no resuelta por afirmaciones sucesivas. La premisa conversacional de Maya sigue presente nueve años después; la evidencia aún no muestra cuánto trabajo total de planificación elimina. La transición de machine learning a etiquetas generativas y agénticas es mucho más explícita que el cambio correspondiente en el cálculo de reabastecimiento.
Productividad, mantenimiento de la configuración y coste de propiedad
Hay evidencia concreta de trabajo administrativo eliminado. El caso de Keells describe KANE, su implementación de la plataforma de proveedores de Algonomy, que sustituye extracciones repetidas de datos, correos y conciliación manual por datos compartidos y procesos electrónicos. Informa de una incorporación de proveedores un 92 % más rápida y de productos un 85 % más rápida. (15)
Esas mejoras importan en un minorista que coordina cientos de proveedores. Afectan a la administración transaccional y se documentaron antes del posicionamiento actual de ATLAS. No demuestran una reducción del trabajo humano necesario para mantener la lógica de previsión y compras.
En Order Right, el usuario define la frecuencia de pedido. La oferta alimentaria también expone reglas de programación, criterios de selección de modelos y umbrales de alerta por producto. (2, 4) Cada uno se convierte en un supuesto que debe mantenerse. Un cambio en los calendarios del proveedor puede alterar la cobertura de stock, la exposición a caducidad y el número de alertas. Mejorar el ajuste de un producto puede aumentar trabajo en otro lugar.
El coste incluye, por tanto, a quienes investigan cambios de datos, revisan restricciones, comprueban la calidad de las recomendaciones y mantienen correspondencias con el ERP. Los especialistas del proveedor pueden realizar parte de ese trabajo; su esfuerzo recurrente sigue perteneciendo al coste total de propiedad. El material público no cuantifica las horas restantes de los planificadores ni el esfuerzo de ingeniería por cambio.
Una respuesta conversacional puede acelerar una investigación. La mejora mayor de productividad llega cuando la corrección se convierte en lógica ejecutable probada y aplicada a todos los productos afectados. El material público de planificación de Algonomy no expone cambios de políticas versionados, reproducción histórica de decisiones revisadas ni reversión controlada del motor numérico. Esto limita la evidencia de una mejora continua poco costosa.
Lista de componentes de software
La evidencia identifica varios entornos diferentes de producto y prestación.
| Producto o actividad | Componentes documentados | Fecha y alcance |
|---|---|---|
| Order Right | Microsoft Azure; aprovisionamiento de un entorno cliente específico | Preguntas frecuentes actuales del producto. (2) |
| Despliegue de productos y almacenes analíticos de datos | Procedimientos SQL, ajuste de bases de datos, ETL; T-SQL/PL-SQL y SSIS entre las competencias solicitadas | Vacante de Database Programmer del empleador consultada en noviembre de 2026; módulo no especificado. (16) |
| Ingeniería de CDP en tiempo real | Servicios Java/Scala y servicios AWS, incluidos DynamoDB, SQS, S3, Lambda y EC2 | Publicación histórica de selección de personal de Algonomy para el equipo rCDP. (17) |
| Consultoría de datos e IA | Databricks sobre Azure, Delta Lake, Unity Catalog, Workflows y búsqueda vectorial | Arquitectura actual del servicio, incluidos proyectos de plataformas de datos de clientes. (9) |
| Extensiones de Active Content | JavaScript, API HTTP externas y Data Model Extensions internas | Documentación actual para desarrolladores de CodeFusion. (19, 20) |
La carga operativa está en las fronteras entre estos entornos. Las transacciones minoristas deben conservar identidades de productos, unidades, fechas promocionales y semántica de stock coherentes al pasar a la analítica y al reabastecimiento. Cada copia o transformación adicional necesita supervisión, recuperación y un responsable cuando las cifras discrepan.
El conjunto tecnológico de consultoría introduce un ciclo de vida separado para la plataforma de datos: ingesta, almacenamiento, políticas de acceso, orquestación de cómputo y despliegue de modelos. Su coste debe justificarse por las decisiones mejoradas. La infraestructura y las capacidades de Databricks pertenecen a Databricks; la contribución de ingeniería de Algonomy debe aparecer en sus modelos minoristas, integraciones y mejoras operativas medidas.
El material público de arquitectura no sigue un cálculo completo de promoción a pedido entre los productos de datos de clientes y de supply chain. Compartir marca e intercambiar datos deja abierta la pregunta crítica: ¿qué componente es responsable de la decisión económica cuando entran en conflicto la generación de demanda, el inventario y las prioridades de rebajas?
Seguridad: el código de extensión necesita límites impuestos
La API de perfiles de clientes documenta tokens OAuth con ámbitos de recursos y caducidad. Son controles específicos sobre el acceso a datos. (18) La declaración de entornos cliente de Order Right aporta contexto de despliegue, pero pocos detalles sobre acceso privilegiado de soporte, recuperación tras cambios destructivos o imposición del aislamiento.
Active Content introduce una preocupación más concreta. Su editor CodeFusion permite escribir JavaScript, acceder a modelos de datos internos y llamar a API externas. La guía de creación muestra un ejemplo de recuperación de un perfil de cliente; la guía de pruebas indica que se inspeccionen los resultados y después se guarde y publique. (19, 20, 21)
El acceso documentado a red y datos hace esencial la contención. Un script erróneo o una integración comprometida puede divulgar información de clientes aunque nunca modifique un registro empresarial. Las guías públicas no explican restricciones impuestas de destinos, separación de secretos, privilegios de datos por script, aislamiento de ejecución entre clientes, límites de recursos ni aprobación independiente para producción.
La guía de la API POST afirma que su finalidad es recuperar datos en lugar de modificar sistemas remotos. No explica cómo se impone esa restricción frente al servicio de destino y expone funciones de registro de solicitudes y respuestas. (22) Los servicios remotos determinan los efectos de las solicitudes entrantes; declarar un uso previsto no sustituye los límites de acceso.
Esta preocupación se aplica a la superficie de extensión de Active Content. La documentación no demuestra que los usuarios de Order Right ejecuten JavaScript. Sí muestra por qué la programabilidad del conjunto de productos exige una explicación de seguridad más sólida que instrucciones de prueba y cuidado del usuario.
Resultados de clientes y responsabilidad económica
El caso del minorista alimentario de Oriente Medio es especialmente útil porque separa el piloto de la extrapolación del titular. Según el relato, tres departamentos de una tienda insignia redujeron el inventario un 21 % y las incidencias de faltantes de stock un 9 %. El titular de $60 millones se proyecta sobre más de 300 tiendas. (7)
Es un piloto potencialmente valioso, pero la cifra para toda la red no es un retorno realizado. Los departamentos seleccionados habían experimentado aumentos de inventario especialmente grandes, por lo que una implantación más amplia necesita evidencia de que la mejora inicial se generaliza. El relato no publica periodo de observación, base financiera, costes de implementación y operación ni un método que separe los efectos del software de otros cambios.
El mismo caso sitúa la puesta en funcionamiento dos semanas después de integrar los datos. Eso excluye del intervalo anunciado una parte de implementación potencialmente considerable. Una evaluación de tiempo y coste debe incluir la preparación de datos y el mantenimiento continuo.
El caso del minorista multiformato informa de mejoras en rebajas y traslados junto con su indefinido 95 % de precisión. Trasladar inventario a tiendas con demanda es una acción significativa, pero el valor declarado del stock trasladado no es beneficio; tampoco lo es la pérdida estimada de ventas evitada. (23) El margen incremental debe considerar gastos de traslado, ventas desplazadas, rebajas e inventario sin vender.
Los relatos públicos de Algonomy no definen una condición de fracaso económico neto, obligaciones acotadas del cliente ni responsabilidad por corregir resultados decepcionantes. Esto hace difícil refutar la propuesta económica. También impide que los éxitos publicados sustenten una estimación fiable del retorno esperado entre implantaciones.
Puntuación de supply chain
Profundidad en supply chain
| Criterio | Puntuación |
|---|---|
| Planteamiento económico | 3/10 |
| Resultado final de la decisión | 6/10 |
| Rigor conceptual sobre supply chain | 4/10 |
| Independencia de doctrinas centrales obsoletas | 4/10 |
| Resistencia a la teatralización de KPI | 1/10 |
Media: 3,6/10
Planteamiento económico — 3/10. El desperdicio y los costes de inventario figuran en la propuesta, pero no se publica el objetivo monetario del motor de pedidos. Por tanto, los usos en conflicto de efectivo, estantería y transporte carecen de una regla de valoración examinable. (3)
Resultado final de la decisión — 6/10. Las recomendaciones de compra y traslado tienen una vía de ejecución hacia el ERP. Es un resultado operativo práctico; la evidencia pública no establece cuánto trabajo de aprobación y gestión de excepciones permanece entre implantaciones. (2)
Rigor conceptual sobre supply chain — 4/10. Vida útil, restricciones de embalaje, promociones y sustitución reciben un tratamiento específico. Tratarlas como entradas y funciones deja sin resolver las interacciones económicas del conjunto del sistema. (3, 4)
Independencia de doctrinas centrales obsoletas — 4/10. La generación automática de pedidos reduce la dependencia de hojas de cálculo. El diseño central sigue priorizando previsiones seguidas de reabastecimiento configurado, con elecciones de políticas que soportan gran parte de la carga económica. (2, 25)
Resistencia a la teatralización de KPI — 1/10. Las afirmaciones indefinidas del 97 % y 95 % de precisión obstaculizan una evaluación significativa. No pueden acreditar precisión en el horizonte de pedido SKU-ubicación ni mejores decisiones económicas. (5, 23)
Sustancia de las decisiones y la optimización
| Criterio | Puntuación |
|---|---|
| Profundidad de modelización probabilística | 2/10 |
| Sustancia distintiva de optimización o aprendizaje automático | 4/10 |
| Tratamiento de restricciones reales | 6/10 |
| Automatización de decisiones y productividad laboral | 6/10 |
| Resiliencia ante la complejidad operativa real | 4/10 |
Media: 4,4/10
Profundidad de modelización probabilística — 2/10. Una oferta de consultoría menciona modelos probabilísticos de demanda. Ninguna descripción pública de Order Right establece resultados conjuntos calibrados de demanda y suministro que alimenten la valoración de pedidos. (9, 3)
Sustancia distintiva de optimización o aprendizaje automático — 4/10. La modelización jerárquica y la selección automática de modelos ofrecen un enfoque de previsión identificable. El número de candidatos y un optimizador propietario dificultan evaluar la contribución numérica distintiva. (2)
Tratamiento de restricciones reales — 6/10. La documentación de reabastecimiento cubre varias restricciones minoristas concretas. Sigue sin resolverse cómo el software pondera restricciones flexibles y asigna recursos comunes cuando compiten planes individualmente factibles. (3)
Automatización de decisiones y productividad laboral — 6/10. La generación de pedidos y los procesos de proveedores documentados en Keells eliminan trabajo recurrente. Los asistentes nuevos carecen de mediciones que muestren ahorros laborales adicionales a esa automatización existente. (2, 15)
Resiliencia ante la complejidad operativa real — 4/10. Los ajustes del ciclo de vida del producto y predictores configurables ofrecen vías de adaptación. Los cambios en objetivos, significado de datos o acciones disponibles siguen dependiendo de la intervención del proveedor sin una explicación pública de pruebas y despliegues reproducibles. (2)
Integridad del producto y la arquitectura
| Criterio | Puntuación |
|---|---|
| Coherencia arquitectónica | 4/10 |
| Claridad de los límites del sistema | 5/10 |
| Seriedad en seguridad | 3/10 |
| Sobriedad del software y coste de propiedad | 4/10 |
| Compatibilidad con operaciones programáticas y asistidas por agentes | 5/10 |
Media: 4,2/10
Coherencia arquitectónica — 4/10. La documentación específica de productos identifica componentes funcionales. Sus distintos entornos de datos y ejecución carecen de una explicación publicada de lógica económica de decisión compartida. (16, 17)
Claridad de los límites del sistema — 5/10. Se entienden la entrega de pedidos y las funciones de transacción con proveedores. La responsabilidad por conciliar datos y resolver decisiones comerciales en conflicto entre módulos es menos explícita. (2, 14)
Seriedad en seguridad — 3/10. Se documenta autenticación con ámbitos para los datos de clientes. El código de extensión escrito por usuarios de negocio tiene límites de contención mal explicados, mientras que los mecanismos de recuperación y acceso privilegiado específicos de planificación siguen siendo opacos. (18, 19, 20, 21)
Sobriedad del software y coste de propiedad — 4/10. Las descripciones de despliegue y servicio revelan considerable trabajo de ingeniería de datos y configuración. Los casos públicos no cuantifican ese trabajo continuo ni justifican su coste frente al valor incremental de las decisiones. (2, 9)
Compatibilidad con operaciones programáticas y asistidas por agentes — 5/10. API, exportaciones e integraciones comerciales mediante scripts ofrecen superficies de automatización. Los objetivos y el proceso de revisión del motor de planificación son mucho menos accesibles para una mejora programática. (18, 20, 24)
Transparencia técnica
| Criterio | Puntuación |
|---|---|
| Documentación técnica pública | 5/10 |
| Posibilidad de inspección sin mediación del proveedor | 4/10 |
| Visibilidad de portabilidad y dependencia | 4/10 |
| Transparencia del método de implementación | 5/10 |
| Densidad de evidencia tras las afirmaciones técnicas | 3/10 |
Media: 4,2/10
Documentación técnica pública — 5/10. Las API de datos de clientes y Active Content están ampliamente documentadas. Los métodos de supply chain reciben preguntas frecuentes y fichas técnicas, en lugar de documentación numérica comparable. (18, 2, 3)
Posibilidad de inspección sin mediación del proveedor — 4/10. El comportamiento de integración puede examinarse públicamente. La valoración de pedidos, la calibración de incertidumbre y los cambios de algoritmos no pueden reproducirse de manera independiente a partir del material publicado. (2, 18)
Visibilidad de portabilidad y dependencia — 4/10. Las exportaciones de pedidos y los destinos documentados de datos de clientes facilitan mover registros. No se explica de forma similar cómo exportar la lógica aprendida de reabastecimiento, dependencias de configuración y el historial completo de decisiones. (24)
Transparencia del método de implementación — 5/10. La documentación de producto y los relatos de clientes describen integración de datos y cambios de procesos. Ofrecen menos visibilidad sobre mantenimiento continuo, pruebas de aceptación y responsabilidad por subsanar problemas. (2, 15)
Densidad de evidencia tras las afirmaciones técnicas — 3/10. Los ejemplos operativos respaldan capacidades específicas. Las afirmaciones más ambiciosas de precisión e inteligencia cuentan con poca evidencia experimental. (6, 7, 5)
Seriedad del proveedor
| Criterio | Puntuación |
|---|---|
| Seriedad técnica de la comunicación pública | 3/10 |
| Integridad de la hoja de ruta tecnológica | 3/10 |
| Rigor conceptual | 3/10 |
| Responsabilidad económica | 3/10 |
| Defensibilidad en un mundo de software agéntico | 4/10 |
Media: 3,2/10
Seriedad técnica de la comunicación pública — 3/10. Descripciones útiles de producto coexisten con precisión indefinida, recuentos de algoritmos y afirmaciones inexplicadas sobre previsión generativa. Esas afirmaciones impiden evaluar cuidadosamente la propuesta central del producto. (5, 11, 25)
Integridad de la hoja de ruta tecnológica — 3/10. El historial fechado establece productos de reabastecimiento y proveedores entregados. Las promesas sucesivas de inteligencia conversacional carecen de una explicación medida de cómo avanzaron capacidad y productividad. (10, 13, 14, 15)
Rigor conceptual — 3/10. El relato público trata repetidamente la precisión predictiva, las sugerencias de siguiente acción y la optimización económica como intercambiables. Sus distintos requisitos son centrales para un motor de compras fiable. (13, 25)
Responsabilidad económica — 3/10. Los casos de clientes informan de cambios en medidas operativas, pero retornos netos y condiciones de fracaso siguen indefinidos. Proyecciones de pilotos y valores de stock trasladado no satisfacen la promesa económica más amplia. (7, 23)
Defensibilidad en un mundo de software agéntico — 4/10. Las integraciones instaladas y los procesos del dominio conservan valor. Una interfaz conversacional resulta cada vez más fácil de reproducir; una diferenciación duradera exige mejores decisiones y un mantenimiento más barato de la lógica que las produce. (14, 15)
Fuentes
Todas las fuentes se consultaron el 4 de noviembre de 2026. Se indican las fechas de publicación cuando están disponibles; la documentación sin fecha refleja la versión pública revisada.
ADA adquiere Algonomy. 2026-07-30. Adquisición completada y marca ADA.
[2] Preguntas frecuentes de Order Right
Preguntas frecuentes de Order Right. Sin fecha; consultado el 2026-11-04. Previsión, vías de ejecución, configuración, soporte y despliegue.
[3] Ficha técnica de Order Right
Ficha técnica de Order Right. Directorio de URL 2022-06. Reabastecimiento basado en previsiones, restricciones, selección de riesgo y criterios de desperdicio.
[4] Order Right para alimentación
Order Right para alimentación. Sin fecha. Programación alimentaria, efectos promocionales y configuración de alertas.
[5] Previsión de demanda con precisión hiperlocal
Previsión de demanda con precisión hiperlocal. Sin fecha. Afirmación indefinida del 97 % de precisión y proceso de previsión.
[6] Minorista alimentario del sudeste asiático
Minorista alimentario del sudeste asiático. Sin fecha. Cobertura de mejoras de previsión y caso de reabastecimiento multiescalón.
[7] Minorista alimentario de Oriente Medio proyecta $60M de ahorro en inventario
Minorista alimentario de Oriente Medio proyecta $60M de ahorro en inventario. Sin fecha. Piloto en una tienda, mejoras declaradas y proyección para toda la red.
[8] Métodos y propuestas de la competición M5
Métodos y propuestas de la competición M5. Commit fijo del repositorio. Propuestas de previsión de los organizadores utilizadas para comparar la agregación.
[9] Servicios de inteligencia de decisiones con datos e IA
Servicios de inteligencia de decisiones con datos e IA. Sin fecha. Previsión probabilística específica de consultoría y arquitectura Databricks.
Manthan presenta Maya. 2017-01-16. Anuncio contemporáneo de Maya e interfaz Alexa.
Lanzamiento de Algonomy. 2021-01-19. Fusión completada, alcance de la plataforma y afirmaciones sobre algoritmos.
[12] Intención de adquirir el negocio de Linear Squared
Intención de adquirir el negocio de Linear Squared. 2022-01-05. Adquisición propuesta y ampliación prevista de previsión.
[13] Planificación de suministro y Maya
Planificación de suministro y Maya. Sin fecha. Maya y proceso comercial actuales.
[14] Colaboración con proveedores y ATLAS
Colaboración con proveedores y ATLAS. Sin fecha. Afirmaciones de procesos de Vendor Link y ATLAS.
[15] Caso de colaboración con proveedores de Keells
Caso de colaboración con proveedores de Keells. Directorio de URL 2024-06. Implantación identificada, administración de proveedores y cambios de procesos.
[16] Contratación de Database Programmer de Algonomy
Contratación de Database Programmer de Algonomy. Sin fecha; consultado el 2026-11-04. Requisitos del empleador para almacenes analíticos y despliegue de productos.
[17] Contratación de ingeniería rCDP de Algonomy
Contratación de ingeniería rCDP de Algonomy. Publicación histórica de selección de personal. Evidencia histórica de contratación sobre nube y software específica del equipo.
[18] Descripción general de la API de perfiles de clientes
Descripción general de la API de perfiles de clientes. Documentación actual. Ámbitos de autorización de perfiles y comportamiento de tokens.
[19] Creación de un script CodeFusion
Creación de un script CodeFusion. Documentación actual. JavaScript escrito por usuarios y proceso de publicación.
[20] Desarrollo de un script CodeFusion
Desarrollo de un script CodeFusion. Documentación actual. Acceso interno a datos y capacidades de API externas.
[21] Pruebas de un script CodeFusion
Pruebas de un script CodeFusion. Documentación actual. Pasos manuales de prueba, guardado y publicación.
API POST de CodeFusion. Documentación actual. Finalidad declarada de solo recuperación y comportamiento de registro.
[23] Planificación comercial de un minorista multiformato
Planificación comercial de un minorista multiformato. Sin fecha. Afirmaciones sobre precisión, rebajas y traslados de inventario.
[24] Configuración de destino de Amazon S3
Configuración de destino de Amazon S3. Documentación actual. Configuración del destino de exportación de datos.
[25] Previsión de demanda y reabastecimiento actuales
Previsión de demanda y reabastecimiento actuales. Sin fecha. Etiqueta actual de IA generativa y proceso de reabastecimiento.