La inteligencia artificial también está transformando la logística de almacén. Lo decisivo, sin embargo, no es dónde la IA sería técnicamente posible, sino qué problema concreto se puede resolver mejor con IA que con el estándar de SAP.
Esta página sitúa el tema: desde el Reality Check para casos de uso operativos en SAP EWM y SAP MFS, pasando por el papel de Joule, los skills y los agentes, hasta la pregunta de quién asume la responsabilidad de los agentes que actúan de forma autónoma. Para profundizar, remite a nuestros tres Executive Whitepapers.
No todo problema recurrente es automáticamente un caso de uso razonable para la IA. Antes de seguir adelante con un caso de uso, conviene plantearse cinco preguntas:
Los campos de potencial típicos en los procesos de SAP EWM y SAP MFS son la detección de errores y el análisis de causas, la priorización y el apoyo a la toma de decisiones operativas, la planificación de personal y de capacidad, la detección temprana de cuellos de botella operativos y el aseguramiento de la calidad basado en riesgos.
No todas las empresas necesitan actuar en las cinco áreas. Por ello, el Reality Check no pretende generar el mayor número posible de ideas de IA, sino identificar los pocos temas en los que un análisis más profundo realmente tiene sentido.
Con Clean Core, el estándar de SAP se convierte cada vez más en la base común de todas las empresas. También el acceso a SAP Joule y a otros copilotos será en pocos años algo natural.
La diferenciación surge por encima del estándar: mediante skills propios, agentes y ampliaciones a medida en SAP BTP que reflejen el conocimiento de procesos de la propia empresa.
Por eso conviene seguir un orden fijo. Primero se comprueba si el estándar de SAP o un agente nativo de SAP ya cubre la necesidad. Solo si queda una brecha relevante se plantea si debe cerrarse con Joule Studio o con una ampliación a medida. Cuanto más cerca del estándar de SAP se mantenga una solución, menores suelen ser el esfuerzo y el riesgo.
Tres Executive Whitepapers para CIOs y responsables de logística que se complementan entre sí: desde el Reality Check, pasando por el papel de Joule, los skills y los agentes, hasta la gobernanza de los agentes autónomos.
¿Qué casos de uso de IA en SAP EWM y SAP MFS tienen sentido económico en los próximos dos o tres años?
Con un escenario concreto de Reality Check de un almacén altamente automatizado.
Por qué SAP Joule por sí solo todavía no es una ventaja competitiva.
Dónde surge la diferenciación con skills y agentes propios en la capa personalizada por encima del estándar de SAP.
¿Quién puede conceder autonomía a un agente de IA en SAP?
Gobernanza por clase de decisión, cadena de responsabilidad y el Reglamento de IA de la UE como marco.
El primer whitepaper de la serie se pregunta qué aplicaciones de IA en SAP EWM y SAP MFS crearán realmente valor económico en los próximos dos o tres años y dónde las empresas deberían esperar todavía. Va dirigido a CIOs y a responsables de TI y de logística, y se apoya en la experiencia de proyectos en almacenes altamente automatizados.
Por qué SAP EWM ya hace innecesaria buena parte de la IA: la automatización aplica reglas, la IA evalúa relaciones. El mayor valor se encuentra, por tanto, allí donde actúan simultáneamente muchos factores, la información es incompleta y las decisiones tienen consecuencias distintas, no allí donde SAP EWM ya es fuerte de por sí.
La IA reconoce patrones en los mensajes de error, relaciona incidentes similares y propone causas y medidas probables. El beneficio reside menos en la corrección automática de errores que en tiempos de diagnóstico más cortos y en poner a disposición de todos la experiencia de cada experto.
Las reglas marcan los límites, la IA optimiza dentro de ellos. Puede simular opciones de actuación y evaluar las consecuencias para el resto del turno, para los turnos siguientes y para los pedidos de clientes abiertos.
Ambos casos de uso evolucionan por etapas: observar, apoyar, automatizar parcialmente.
Tienen éxito las iniciativas en las que confluyen el conocimiento de procesos, la competencia en arquitectura en SAP BTP y el know-how de IA.
Quien se encuentre en plena migración a SAP S/4HANA suele hacer bien en empezar entre seis y doce meses después del go-live. Con una operación estable, la detección de errores suele ser el mejor punto de partida.
El segundo whitepaper somete a prueba la tesis de la primera parte en condiciones nuevas: con la Autonomous Enterprise que SAP presentó en Sapphire 2026, el propio estándar incorpora asistentes y agentes.
El documento separa lo disponible de lo meramente anunciado y sitúa Joule, los skills y los agentes en un marco conceptual claro.
Las funciones pueden clasificarse como disponibles, piloto, hoja de ruta o visión.
En el ámbito logístico, SAP aborda sobre todo la planificación y las excepciones. En la planificación oficial no figura ningún agente que intervenga directamente en el control de SAP MFS o de la automatización del almacén. El control de las instalaciones sigue siendo deliberadamente basado en reglas y determinista.
Comunicación (la IA informa), acción (la IA ejecuta pasos definidos tras la aprobación humana) y autonomía (la IA decide dentro de límites establecidos).
Con cada nivel aumentan el beneficio y el riesgo, pero también las exigencias de gobernanza.
Los agentes estándar generan ganancias de productividad, pero no diferenciación.
Los agentes necesitan Clean Core, datos maestros y de movimientos fiables, reglas de decisión documentadas, señales limpias de la automatización, así como aprobaciones y un presupuesto para AI Units.
Con Joule Studio baja la barrera técnica para crear skills propios, pero la barrera funcional se mantiene.
Siete reglas de arquitectura, desde un responsable designado para cada agente hasta un registro central de agentes y una desconexión de emergencia, evitan el crecimiento descontrolado.
El documento describe además un ejemplo práctico de gestión de incidencias en la automatización del almacén, los nuevos roles en la empresa, como el SAP AI Architect, y concluye con diez preguntas que conviene responder antes del primer agente productivo.
El tercer whitepaper plantea la pregunta que resulta ineludible tras la segunda parte: ¿quién determina qué pueden decidir por sí solos los agentes en los panoramas logísticos de SAP y quién asume la responsabilidad cuando lo hacen?
La curva de madurez se convierte así en una curva de responsabilidad. En el nivel 1 (observar) prima la calidad de la información; en el nivel 2 (apoyar) existe el riesgo de que la aprobación se reduzca a una mera rutina; y en el nivel 3 (autonomía condicionada) el propio límite de actuación pasa a ser objeto de responsabilidad.
La responsabilidad no desaparece, se desplaza de la ejecución al diseño. El Reglamento de IA de la UE establece el marco para ello, entre otros con requisitos de gestión de riesgos, registro y supervisión humana. Esto no sustituye al asesoramiento jurídico.
El registro de agentes pasa así de ser una buena idea a ser una obligación de acreditación. Documenta por cada agente su finalidad, el responsable, el nivel de autonomía, los límites de actuación, los accesos a datos, el marco de costes, la desconexión de emergencia y la versión. Si no rige la regla «ningún agente productivo sin entrada en el registro», se corre el riesgo de una Shadow IT 2.0.
Un ejemplo práctico muestra cómo dos agentes que funcionan correctamente desde el punto de vista técnico, uno de reposición y otro de mantenimiento, compiten por los mismos pasillos sin que nadie fuera responsable de antemano de ese conflicto. La estructura necesaria se sustenta en nuevos roles como el SAP AI Architect, AI Governance y Compliance, y el Skill Portfolio Owner.
El documento ofrece recomendaciones de actuación según la situación de partida («Construir la gobernanza antes de que el primer agente entre en producción») y diez preguntas previas al traspaso de responsabilidad a un agente.
Su respuesta a la cuestión de la confianza: la confianza no nace de la ausencia de errores, sino de la trazabilidad y de la responsabilidad clarificada para el caso de que algo falle.
Las ampliaciones de IA se basan en el modelo de operación de SAP EWM. Las posibilidades de personalización y ampliación dependen de si SAP EWM se opera en la Public Cloud o en la Private Cloud y de en qué forma funcional, Basic o Advanced, se utiliza.
Quien planifique casos de uso de IA debería, por tanto, tener en cuenta estas decisiones desde el principio.
Especialmente en el almacén automatizado, los sistemas de reglas clásicos llegan a su límite. El whitepaper «IA en SAP EWM» lo muestra con un jueves típico a las 14:30: un sistema shuttle se avería, al mismo tiempo falta un empleado y doce pedidos urgentes y críticos en el tiempo tienen una hora de corte a las 20:00.
Dónde llegan a su límite los sistemas de reglas clásicos de SAP EWM y dónde la IA ya puede marcar hoy la diferencia es el núcleo de este escenario de Reality Check.
Qinlox ayuda a las empresas a valorar con sobriedad el potencial de la IA en SAP EWM y SAP MFS: con diagnóstico en profundidad, calificación por semáforo y un filtro de realidad que separa el potencial real del aparente.
Sobre esta base se puede decidir qué casos de uso son viables y qué requisitos de arquitectura, datos y gobernanza deben crearse para ellos.
En un intercambio sin compromiso valoramos conjuntamente si y dónde la IA puede aportar valor en su logística de almacén frente al estándar de SAP. Para ello consideramos los campos de potencial típicos, su situación de datos y las condiciones de su panorama de sistemas.
¿Tiene preguntas? En las siguientes preguntas frecuentes hemos reunido para usted las respuestas más importantes. Si su pregunta no figura, póngase en contacto con nosotros directamente.
Allí donde un problema se produce con frecuencia, tiene consecuencias económicas medibles, se dispone de datos estructurados suficientes y el estándar de SAP no cubre ya la necesidad. Los campos de potencial típicos son la detección de errores y el análisis de causas, la priorización, la planificación de personal y de capacidad, la detección temprana de cuellos de botella y el aseguramiento de la calidad basado en riesgos.
Primero se comprueba si el estándar de SAP o un agente nativo de SAP cubre la necesidad. Si queda una brecha relevante, pueden tener sentido Joule Studio o una ampliación a medida en SAP BTP. Cuanto más cerca del estándar se mantenga una solución, menores suelen ser el esfuerzo y el riesgo.
Con cada nivel de autonomía se desplaza la responsabilidad. Por eso conviene regularla de antemano, por ejemplo mediante un registro de agentes, roles claramente asignados y una rutina de revisión antes del traspaso de responsabilidad. El Reglamento de IA de la UE establece el marco para ello. Esto no sustituye al asesoramiento jurídico.
Sí. Los tres Executive Whitepapers pueden descargarse de forma gratuita.
Descubra los análisis, artículos y perspectivas más recientes sobre SAP, la cadena de suministro y la transformación empresarial. Conocimiento práctico, directamente de nuestros consultores para su empresa.
