La migración a la nube no elimina la necesidad de mantener actualizados nuestros sistemas SAP on-premise. Fechas de mantenimiento de S/4HANA, BW/4HANA y ECC.
Toda la atención parece estar en las soluciones cloud de SAP. Mientras hablamos de nuevas plataformas y proyectos de transformación, nuestros sistemas on-premise siguen necesitando atención regular.
Tener prevista una migración a la nube no elimina esa necesidad. Hasta completar la transición, esos sistemas siguen soportando operaciones, cierres financieros y procesos de negocio.
¿Por qué mantenerlos actualizados?
Las actualizaciones incorporan correcciones de errores y de seguridad. SAP publica notas de seguridad el segundo martes de cada mes y recomienda aplicar Support Package Stacks al menos una vez al año. Los parches críticos requieren una evaluación específica según su urgencia y aplicabilidad.
Pero actualizar también exige comprobar compatibilidades. Si utilizamos un add-on, una solución sectorial o un componente específico, debemos verificar que sea compatible con la versión y el stack de destino. La revisión debe incluir dependencias técnicas, integraciones y pruebas de los procesos afectados. La Product Availability Matrix (PAM), Maintenance Planner y las notas de versión son referencias esenciales.
¿Dónde estamos con las principales plataformas?
SAP S/4HANA: estar en S/4HANA no garantiza mantenimiento indefinido. Desde la versión 2023, cada release tiene siete años de mantenimiento estándar (la 2023, hasta finales de 2030). El compromiso hasta 2040 exige ir evolucionando entre versiones.
SAP BW/4HANA: el mantenimiento estándar de 2.0 terminó el 31/12/2025; el de 2021 finaliza el 31/12/2027 y el de 2023, el 31/12/2030. La siguiente versión planificada es BW/4HANA 2027, prevista para noviembre de 2027.
SAP BW 7.5 y NetWeaver 7.5: mantenimiento estándar hasta el 31/12/2027, con ampliación opcional hasta 2030.
SAP ERP 6.0/ECC: las versiones sin EHP y con EHP1–EHP5 terminaron su mantenimiento estándar el 31/12/2025. EHP6, EHP7 y EHP8 lo mantienen hasta el 31/12/2027, con ampliación opcional y de pago hasta el 31/12/2030. Pasar de EHP7 a EHP8 no amplía esas fechas.
Conviene revisar dos cosas por separado: si la versión sigue en mantenimiento y si la instalación incorpora las actualizaciones necesarias.
Antes de cerrar el próximo presupuesto o calendario de proyectos, revisemos el inventario de versiones, los parches pendientes y las compatibilidades. Asignemos responsables y ventanas de pruebas y actualización.
La estrategia cloud también debe contemplar cómo mantenemos los sistemas que nos llevan hasta ella.
Anexo 1. SAP S/4HANA: versiones y mantenimiento
Versión
Release S4CORE
Lanzamiento
Fin mant. estándar
Fin mant. ampliado opcional
1511
100
2015
31/12/2020
—
1610
101
2016
31/12/2021
—
1709
102
2017
31/12/2022
31/12/2025
1809
103
2018
31/12/2023
31/12/2025
1909
104
2019
31/12/2024
31/12/2025
2020
105
2020
31/12/2025
—
2021
106
2021
31/12/2026
—
2022
107
2022
31/12/2027
—
2023
108
2023
31/12/2030
—
2025
109
2025
31/12/2032
—
«—»: sin ampliación general confirmada. Versiones on-premise; Public Edition sigue otro calendario. SAP Safekeeper: servicio de pago solo para clientes RISE with SAP (1503, 1605 y 1709–2020, desde el 01/01/2026, máximo 27 meses por release).
Anexo 2. SAP BW/4HANA: versiones y mantenimiento
Versión
Release DW4CORE
Lanzamiento
Fin mant. estándar
Fin mant. ampliado opcional
1.0
100
2016
31/12/2021
—
2.0
200
2019
31/12/2025
—
2021
300
2021
31/12/2027
—
2023
400
2023
31/12/2030
—
2027 (planificada)
Pendiente
Nov 2027 (previsto)
Dic 2034 (previsto)
—
Fechas de BW/4HANA 2027 sujetas a cambio. El compromiso con la familia hasta 2040 no amplía el mantenimiento de cada versión instalada.
Anexo 3. SAP ERP 6.0 / ECC: versiones y mantenimiento
Versión
Release SAP_APPL
Fin mant. estándar
Fin mant. ampliado opcional
ERP 6.0 sin EHP
600
31/12/2025
—
ERP 6.0 EHP1
601
31/12/2025
—
ERP 6.0 EHP2
602
31/12/2025
—
ERP 6.0 EHP3
603
31/12/2025
—
ERP 6.0 EHP4
604
31/12/2025
—
ERP 6.0 EHP5
605
31/12/2025
—
ERP 6.0 EHP6
606 (616 on HANA)
31/12/2027
31/12/2030
ERP 6.0 EHP7
617
31/12/2027
31/12/2030
ERP 6.0 EHP8
618
31/12/2027
31/12/2030
La ampliación de EHP6–EHP8 hasta 2030 requiere contratación adicional (+2% sobre la base de mantenimiento). ERP 6.0 sin EHP y EHP1–EHP5 pasaron a mantenimiento específico del cliente.
La prioridad no es retirar SAP BW de inmediato, sino identificar el producto y las versiones utilizadas, establecer su horizonte real de mantenimiento y determinar qué dependencias deberán conservarse o sustituirse. A partir de ese diagnóstico, la organización puede optar o combinar las siguientes vías: (1) Ganar tiempo mediante mantenimiento extendido, (2) Evolucionar hacia SAP BW/4HANA o (3) Modernizar progresivamente con SAP Business Data Cloud y SAP Datasphere.
La decisión debe basarse en pruebas de transferencia funcional, seguridad, rendimiento y compatibilidad, no solo en la copia de los datos.
Si tu organización dispone de una plataforma SAP BW, es posible que hayas oído que “se acerca el fin de su vida útil”. Antes de tomar una decisión, identifica el producto y las versiones utilizadas, dónde están instalados y qué aplicaciones, procesos e interfaces dependen de ellos.
El fin del mantenimiento no provoca que el sistema deje de funcionar automáticamente. Implica un cambio en la cobertura de soporte, la disponibilidad de correcciones y, según el contrato, el coste y las condiciones del servicio. El impacto concreto depende del producto, la versión, los componentes instalados y las condiciones contractuales.
Fin del mantenimiento: no todas las versiones tienen el mismo horizonte
Debemos distinguir SAP BW NetWeaver independiente, SAP BW/4HANA y las implementaciones BW embebidas sobre SAP ERP ECC o SAP S/4HANA.
SAP BW 7.5 independiente: el mantenimiento principal termina el 31 de diciembre de 2027. Existe una opción de mantenimiento extendido hasta finales de 2030, sujeta a condiciones.
SAP BW/4HANA: SAP establece un horizonte general de mantenimiento hasta 2040. Este horizonte no garantiza que cada versión concreta reciba mantenimiento hasta esa fecha; es necesario comprobar el ciclo de vida de la versión instalada y planificar las actualizaciones correspondientes.
BW Embebido: su horizonte de mantenimiento depende del ciclo de vida del sistema SAP ERP ECC o SAP S/4HANA que lo contiene, por lo que debe comprobarse conjuntamente con el producto y la versión del sistema anfitrión.
SUGERENCIA: Para comprobar posibles actualizaciones de estas fechas, consulta las notas SAP 2741041, 2934895 y 2952947, así como el Product Availability Matrix (PAM) de SAP BW.
Estrategia: asegurar continuidad y definir el destino
Ante el horizonte de 2027 para SAP BW 7.5, la organización debe definir cuanto antes una estrategia que combine continuidad operativa, destino tecnológico, calendario, costes, responsables y criterios de validación.
Las rutas deben evaluarse según el tiempo disponible, el grado de reutilización requerido, el destino tecnológico, el coste de la transición y la capacidad de validar la funcionalidad transferida:
Mantenimiento extendido hasta 2030, como continuidad temporal mientras se ejecuta la transformación.
SAP BW NetWeaver en private cloud edition (PCE), previa comprobación de las condiciones de elegibilidad y cobertura de la oferta. La opción de transición para 2031–2033 está sujeta a requisitos y restricciones específicos; migrar BW a una nube privada no concede por sí solo esa cobertura. Se debe contar con un BW 7.5 SPS24 como mínimo, con base de datos SAP HANA.
Conversión a SAP BW/4HANA, cuando se quiera conservar y evolucionar sobre una arquitectura BW.
Modernización hacia SAP Business Data Cloud / SAP Datasphere, mediante coexistencia o sustitución progresiva de las funciones actuales.
SUGERENCIA: Para definir la hoja de ruta, consulta las versiones actualizadas de las notas SAP 3590297 y 3768400, así como la documentación de SAP Business Data Cloud.
Herramientas: elegir según lo que se quiere trasladar
Si el destino final es SAP Business Data Cloud / SAP Datasphere, SAP ha desarrollado varios mecanismos con objetivos diferentes:
Data Product Generator (DPG): aprovisiona datos desde proveedores BW admitidos hacia el Object Store de SAP Datasphere mediante suscripciones. Cada suscripción identifica el InfoProvider de SAP BW que se replicará en SAP Business Data Cloud, materializa sus datos en una tabla local de SAP Datasphere y, una vez activada, puede ejecutarse cuando sea necesario.
Query Template Generator (QTG): transfiere la semántica admitida de las consultas y sus dependencias, lo que puede reducir parte del esfuerzo de reconstrucción.
BW/4HANA Model Transfer e Import Entities: permiten reutilizar consultas y modelos de soporte procedentes de BW/4HANA.
Shell y Remote Conversion hacia BW Bridge: ambas opciones permiten trasladar determinados modelos y procesos BW. Shell transfiere los metadatos sin los datos existentes, mientras que Remote Conversion incorpora también la transferencia de datos.
Import Entities desde S/4HANA, tablas remotas y Replication Flows: permiten integrar datos y, según el mecanismo, semántica del origen para construir modelos en Datasphere.
Una transferencia técnica correcta no garantiza que se conserve toda la funcionalidad. Por ejemplo, QTG puede omitir funciones no admitidas y el modelo transferido no incorpora automáticamente los cambios posteriores realizados en BW. Además, las transformaciones y las rutinas ABAP requieren un análisis independiente.
BW Bridge permite conservar el procesamiento BW en un entorno cloud, pero no convierte automáticamente esa lógica en procesamiento nativo de SAP Datasphere.
Si se tiene SAP BPC o BW-IP sobre BW 7.5, soluciones de planificación y consolidación, ninguno de estos mecanismos lo traslada. El destino natural es SAC Planning o SAP Group Reporting.
SUGERENCIA: Para profundizar en estos mecanismos, consulta las guías de SAP sobre DPG y QTG, BW Bridge e Import Entities, así como las versiones actualizadas de las notas SAP 3724724 y 3774419.
Plan de transición: validar antes de retirar
El proyecto debería comenzar con un inventario de las versiones de los componentes, las fuentes de datos, las consultas, las cargas, las rutinas, las autorizaciones, las interfaces y las aplicaciones de planificación o consolidación.
Después, conviene probar flujos representativos y comparar cifras, filtros, jerarquías, unidades, procesos delta, controles de seguridad y rendimiento. Si el origen también cambia de SAP ERP ECC a SAP S/4HANA, deben comprobarse individualmente los extractores y el Business Content afectados.
Se debe tener presente que los principales elementos que se “romperán” serán los elementos de SAP Analysis for Office y SAP BusinessObjects o BEx Analyzer, si aun se utiliza. Son los consumidores directos de la consultas BW.
Aplazar esta evaluación puede dejar a la organización con menos margen para resolver incompatibilidades, sustituir interfaces o reconstruir lógicas que no se pueden transferir vía ningún mecanismo conocido.
La retirada del sistema BW original debe producirse únicamente cuando se hayan sustituido y validado sus funciones y dependencias. Una copia de los datos en SAP Datasphere no demuestra por sí sola que la migración haya concluido: también deben verificarse la lógica, la seguridad, el rendimiento y las integraciones.
SUGERENCIA: Por último revisar las versiones actualizadas de la notas SAP 2500202, 2548065 y 3774419.
SAP Datasphere no debe verse como el simple sucesor de SAP BW, sino como una plataforma que exige pensar la arquitectura de datos desde el inicio de cada iniciativa. La aparente simpleza y rapidez de SAP BW no debe hacernos perder de vista el valor que se puede obtener con SAP Datasphere si se hacen bien las cosas, con modelos de datos bien estructurados y perfectamente vinculados con la capa de negocio.
Quienes trabajamos en análisis de datos dentro del mundo SAP tendemos, en ocasiones, a definir SAP Datasphere simplemente como el sucesor de SAP BW o como un nuevo data warehouse en la nube. Sin embargo, su alcance es bastante mayor. La plataforma se apoya en SAP HANA como motor de datos y combina capacidades de integración, modelado y analítica con una capa semántica orientada al negocio.
Este último concepto resulta especialmente familiar para quienes procedemos de SAP BusinessObjects y del trabajo con universos, donde uno de los objetivos principales era abstraer la complejidad técnica de las fuentes de datos y presentarla mediante conceptos, relaciones y terminología comprensibles para los usuarios de negocio.
MUCHOS TIPOS DE OBJETOS, NADA SOBRA (o casi nada)
En SAP Datasphere, tanto en Data Builder como en Business Builder, conviven distintos tipos de objetos que se relacionan entre sí y cumplen funciones complementarias. Su valor no está en usarlos de forma aislada, sino en entender cómo encajan dentro de un modelo coherente: cada componente aporta una pieza necesaria para construir soluciones más sólidas, evolutivas y reutilizables.
El recorrido típico comienza en las tablas, que pueden representar dimensiones, como datos maestros, o hechos, como movimientos. Cuando es necesario, las dimensiones se enriquecen con jerarquías y textos dependientes del idioma. A partir de ahí se construyen las vistas, que agrupan subconjuntos lógicos de información y permiten combinar hechos, jerarquías y textos en modelos analíticos. Finalmente, la información se expone mediante una capa semántica o de consulta, por ejemplo, Analytic Models o Perspectivas basadas en Consumption Models, que actúa como punto de acceso para herramientas como SAP Analytics Cloud (SAC), SAP BusinessObjects, SAP Analysis for Office u otras soluciones externas a SAP.
EN SAP BW PARECÍA TODO MÁS FÁCIL
En SAP Business Warehouse (SAP BW), construir un modelo podía resultar más directo. No era necesario crear tantos elementos ni definir tantas asociaciones entre ellos, y el margen de maniobra era mayor. En muchos casos bastaba con preparar una serie de objetos, incorporarlos a un DSO (o a un cubo en versiones más antiguas) y disponer en poco tiempo de un modelo prácticamente operativo.
En SAP Datasphere, en cambio, el modelo se descompone en más piezas y exige definir un mayor número de asociaciones. Esa separación puede ralentizar una necesidad puntual, pero también permite reutilizar componentes en escenarios posteriores. Por eso, frente a la rapidez inicial de SAP BW, el valor de SAP Datasphere aparece con más claridad a medio y largo plazo, cuando las mismas piezas sirven para responder a nuevas necesidades de negocio sin reconstruir el modelo desde cero.
CÓMO SE ESTÁN HACIENDO LAS COSAS (nuestro parecer)
En nuestra experiencia con SAP Datasphere, hemos participado en algunos proyectos y, en ocasiones, hemos encontrado desarrollos ya iniciados con una organización poco clara. Esta situación puede deberse a la cantidad de objetos disponibles en la plataforma, a la relativa novedad de la herramienta o a hábitos heredados de SAP BW y de otras tecnologías.
Lo que observamos habitualmente es un patrón parecido: se importa una fuente de datos basada en una CDS estándar, normalmente con un número elevado de columnas; en algunos casos se construyen megatablas; y desde ahí se crean vistas que se consumen directamente, sin aprovechar buena parte de los objetos y funcionalidades que ofrece la plataforma. Las fuentes de información suelen provenir directamente de sistemas SAP mediante CDS estándar, cuando podrían definirse CDS a medida para reducir el volumen de datos y concretar mejor las necesidades reales del negocio.
Como sugerencia, planteamos lo siguiente:
Identificar bien las fuentes de datos y optimizarlas en origen, por ejemplo mediante CDS personalizadas que incluyan solo las columnas necesarias para la explotación y realicen las combinaciones lógicas requeridas entre las tablas fuente. Hay que tener presente que las CDS son definiciones lógicas y que, si están bien construidas, pueden reducir los tiempos de ingesta y mejorar la claridad del modelo.
Definir estándares para la identificación técnica de la serie de objetos que se van a construir.
Hacer uso de paquetes y carpetas para organizar los objetos.
Evitar el abuso de tablas o vistas definidas directamente por importación, para mantener mayor control sobre la naturaleza de los datos que se van a tratar.
Hacer un uso adecuado de los distintos objetos disponibles para almacenar los datos, en lugar de recurrir siempre al mismo por comodidad.
Ofrecer al usuario final el acceso a los datos mediante modelos analíticos o perspectivas, y no a través de tablas o vistas técnicas. Estas últimas no están pensadas como capa de consumo final y, si se utilizan de ese modo, se desaprovechan capacidades importantes de análisis multidimensional de la plataforma.
En conclusión, SAP Datasphere no debe abordarse como una simple evolución de SAP BW, sino como una plataforma que exige plantear mejor la arquitectura desde el inicio. Su mayor valor aparece cuando se entienden sus objetos, se ordena el modelo desde el inicio y se construyen soluciones pensadas para ser reutilizadas, gobernadas y consumidas por el negocio.
SAP BTP NEO se retira: 31/12/2028 es el cierre general (BTP completo), pero SAP Analytics Cloud en NEO tiene plazo propio, finales de 2026, con excepciones muy limitadas. Tres documentos SAP publicados en ocho semanas de 2026 (FAQ, KBA 3663574 y KBA 3663573) dan versiones distintas de ese segundo plazo, así que conviene verificar la nota vigente en «SAP for Me» antes de comunicar una fecha a un cliente.
SAP BTP (Business Technology Platform) es la plataforma en la nube (PaaS) de SAP que permite ejecutar aplicaciones, servicios e integraciones entre sistemas SAP y no SAP. Sobre esta plataforma se apoyan soluciones como SAP Analytics Cloud (SAC), SAP Datasphere o SAP Integration Suite.
A lo largo de su evolución, SAP BTP ha utilizado distintos entornos tecnológicos. El primero fue NEO, desarrollado sobre tecnología propia de SAP. Actualmente, SAP utiliza como plataforma base la Multi-Cloud Foundation, tecnologías cloud más modernas como Cloud Foundry, Kyma y ABAP Environment.
Por este motivo, SAP está retirando progresivamente el entorno NEO, trasladando los servicios y aplicaciones hacia la Multi-Cloud Foundation, donde está incluyendo todas las mejoras e innovaciones de sus productos.
¿Quién está afectado?
La pregunta correcta no es “¿utilizamos SAP BTP?” sino “¿tenemos algún tenant, subaccount, aplicación, servicio o integración ejecutándose todavía en NEO?”.
SAC
En el caso de SAP Analytics Cloud, la comprobación puede realizarse directamente a partir de la URL del tenant. Los identificadores regionales de un solo dígito, como EU1 o US1, están asociados al entorno NEO, mientras que los identificadores de dos dígitos, como EU10 o US10, corresponden a regiones utilizadas en Cloud Foundry.
Datasphere
Todo tenant de SAP Datasphere se ejecuta sobre Cloud Foundry, por lo que no requiere una migración de entorno. No obstante, deben revisarse sus dependencias, ya que puede integrarse con SAC en NEO, Integration Suite/CPI en NEO u otros servicios BTP heredados.
BTP
Para SAP BTP se requiere un inventario del Global Account y de sus subaccounts:
Identificar Global Account, directories y subaccounts.
Localizar subaccounts y servicios que todavía pertenecen al entorno Neo.
Inventariar aplicaciones, servicios, integraciones y dependencias.
NOTA: El Global Account de SAP BTP de un cliente puede contener uno o varios Subaccounts, utilizados para separar entornos, proyectos, regiones o servicios
¿Qué se hace después del inventario?
Inventariar los elementos a migrar es el primer paso que deberías realizar, luego de manera progresiva deberías acometer las siguientes acciones:
Preparar el destino. Aprovisionar el tenant/subaccount/servicio equivalente en Multi-Cloud Foundation.
Trasladar contenido. Copiar o recrear aplicaciones, iFlows, APIs, modelos, configuraciones, datos u otros artefacto.
Reconstruir lo que no se migra automáticamente. Credenciales, certificados, destinations, passwords, security material, conexiones, etc.
Reconectar el escenario. Cambiar URLs, endpoints, DNS, Cloud Connector, IdP, OAuth, sistemas emisores/receptores, allowlists, etc.
Validar. Pruebas técnicas, integración end-to-end y pruebas funcionales.
Cutover. Hacer que los usuarios y sistemas utilicen el nuevo entorno.
Retirar NEO. Una vez validado el nuevo entorno y eliminadas las dependencias, dejar de utilizar el origen Neo.
SAC es el caso más sencillo y automatizado: El tenant SAC situado en NEO se copia a una nueva instancia SAC situada en Cloud Foundry. Lo que SAP denomina como una SAP led migration, o migración gestionada/liderada por SAP. Para el resto de componentes se señala una migración manual.
En el caso de SAC, el trabajo del consultor se concentra mucho más en la preparación, revisar conexiones, autenticación, seguridad y validación del resultado. Se puede optar por una migración manual, vía exportación/importación de algunos elementos que no considerase el proceso automático.
Tradicionalmente, el consultor SAP aportaba valor por su experiencia para localizar, interpretar y aplicar conocimiento técnico. Joule for Consultants busca acelerar ese trabajo mediante IA generativa conectada a una base de conocimiento SAP especializada, incluida información de acceso restringido.
Una parte importante de la experiencia de un consultor SAP ha consistido en saber qué Note/KBA revisar, qué transacción utilizar, qué alternativa recomienda el fabricante, qué implicaciones podía tener una configuración o cómo interpretar un programa ABAP que nadie del equipo más sabía cómo analizarlo.
Ese conocimiento sigue teniendo valor, pero SAP está intentando cambiar radicalmente la forma de acceder a este conocimiento mediante SAP Joule for Consultants.
No es otro “Chat” incorporado al portfolio de SAP. Su principal interés reside en la combinación de inteligencia artificial generativa con una base de conocimiento específicamente preparada para proyectos SAP, incluyendo información que no está disponible públicamente.
Soluciones SAP Joule
SAP define actualmente Joule como su interfaz de inteligencia artificial empresarial, capaz de combinar asistentes y agentes para consultar información, ejecutar tareas y coordinar procesos dentro del ecosistema SAP.
Pero bajo el nombre Joule conviven distintas capacidades con objetivos diferentes.
¿Qué es exactamente SAP Joule for Consultants?
SAP lo define como una solución de IA conversacional diseñada para acelerar proyectos y transformaciones SAP proporcionando orientación basada en conocimiento SAP especializado y actualizado.
Puede asistir en tareas tales como:
Configuración;
Diseño de soluciones/arquitectura;
SAP Best Practices;
Resolución de errores/problemas;
SAP Notes y KBAs;
Desarrollos ABAP y CDS;
Integraciones;
Procedimientos de implementación.
Su propósito no es únicamente responder preguntas, sino reducir el esfuerzo necesario para localizar, interpretar y utilizar información relevante durante un proyecto.
¿Desde cuándo está disponible?
SAP Joule for Consultants es una solución relativamente reciente. Durante los primeros meses de 2025 estuvo disponible para determinados partners y clientes mediante programas de acceso anticipado.
Posteriormente alcanzó General Availability durante el segundo trimestre de 2025. Desde entonces SAP ha continuado ampliando sus capacidades, especialmente durante 2026, incorporando funciones relacionadas con conocimiento corporativo propio y espacios de trabajo especializados.
Su principal factor diferencial: la información de la que dispone
Probablemente la mayor diferencia respecto a una herramienta pública de inteligencia artificial se encuentre en el conocimiento al que tiene acceso.
SAP declara que Joule for Consultants se apoya en más de 12 TB de conocimiento, con más de 25 millones de documentos, incluidos más de 3 millones de documentos no públicos; seleccionados, organizados y clasificados (lo que en la IA se denominada curated knowledge).
Esto supone una ventaja importante frente a una IA pública. Una herramienta generalista puede consultar SAP Help, SAP Learning, SAP Community y otras fuentes abiertas, pero no dispone automáticamente del contenido completo de documentación protegida por autenticación tales como Notes/KBAs o Best Practices.
¿Puede generar documentación?
Sí. SAP Joule for Consultants puede ayudar a preparar contenido para:
Diseños funcionales y técnicos;
Procedimientos;
Análisis de incidencias;
Documentación de arquitectura;
Planes de pruebas;
Checklists;
Documentación de migración;
Explicaciones de código;
Resúmenes de SAP Notes y KBAs.
Pero conviene diferenciar entre generar contenido y producir un entregable completamente terminado. La revisión funcional, adaptación al estándar documental del cliente, diagramas, formato y validación final siguen formando parte del trabajo del equipo de proyecto.
¿Puede SAP Joule for Consultants construir automáticamente una solución?
Actualmente no se puede entregar a Joule for Consultants, por ejemplo, un fichero Excel o una especificación funcional y obtener automáticamente una solución productiva completa, sin intervención del equipo de implementación.
Joule for Consultants está orientado principalmente a asistir en el diseño, configuración, investigación y toma de decisiones.
Esto no significa que SAP no avance hacia una mayor automatización.
Joule Studio permite crear skills y agentes personalizados capaces de participar en procesos complejos y multietapa, y SAP está ampliando sus capacidades de automatización empresarial.
Pero conviene separar claramente las capacidades actuales de las posibilidades futuras.
Conocimiento corporativo: el siguiente paso
Una de las capacidades más interesantes incorporadas recientemente es Custom Knowledge Grounding. Esta característica permitirá complementar el conocimiento estándar de Joule for Consultants con documentación propia de una organización. Vale decir metodología interna, documentación del cliente, estándares y plantillas corporativas o el conocimiento de proyectos anteriores.
Para una gran consultora o una organización con mucha documentación interna, este escenario puede ser especialmente relevante.
¿Dónde seguirá siendo necesario el consultor?
La automatización puede reducir considerablemente el trabajo necesario para comprender documentación, analizar configuraciones o construir componentes técnicos.
Pero una implementación sigue comenzando con preguntas que no son puramente tecnológicas:
¿qué problema intenta resolver el negocio?;
¿qué procesos deben mantenerse?;
¿qué procesos deberían simplificarse?;
¿qué información necesita realmente el usuario?;
¿qué KPIs permiten tomar decisiones?;
¿qué nivel de detalle es necesario?;
¿qué usuarios deben acceder a qué información?;
¿qué reglas o workflows deben aplicarse?
A partir de esas decisiones se construye después la solución técnica, en dónde la IA puede ser un gran apoyo, pero la definición del problema y la responsabilidad sobre el diseño siguen dependiendo en gran medida del consultor y de los expertos de negocio.
Joule for Consultants no sustituirá al consultor. Sustituirá parte del trabajo tradicional.
Esta distinción es importante. Una parte del trabajo tradicional abarca lo siguiente:
buscar → leer → resumir → documentar → repetir
puede reducirse considerablemente. Eso dejará más tiempo para:
También puede conllevar a que determinadas tareas sean realizadas por equipos más pequeños.
Pero comprender documentación SAP no equivale a comprender una organización, sus procesos, sus restricciones o sus prioridades. Por eso, el efecto más probable no parece ser la desaparición inmediata del consultor, sino una transformación de las tareas por las que aporta valor.
¿Amenza para los juniors?
Tradicionalmente, parte del aprendizaje de un consultor junior consistía en buscar documentación, revisar Notes/KBAs, probar configuraciones y consultar a perfiles senior.
Joule for Consultants puede acelerar el aprendizaje y aumentar la productividad de perfiles menos experimentados. Pero también puede reducir la necesidad de determinados trabajos que históricamente se asignaban a juniors, especialmente tareas de investigación, documentación o configuración repetitiva.
Al mismo tiempo, el senior pierde parte de un diferencial tradicional: recordar dónde estaba la información.
¿Cuánto cuesta?
Joule for Consultants no es una herramienta gratuita. SAP lo clasifica como una capacidad Premium AI que consume SAP AI Units. El modelo comercial publicado actualmente establece: 35 AI Units por usuario y mes. SAP publica además un precio de referencia de: 1 AI Unit = 7 €.
SAP indica además que los AI Units se adquieren en determinados bloques y forman parte de un pool que puede utilizarse para diferentes capacidades Premium AI.
Por ello, el coste contractual efectivo puede no coincidir exactamente con los 2.940 € anuales teóricos. Las condiciones comerciales y ratios de consumo pueden cambiar y deben verificarse antes de contratar el servicio.
CONCLUSION
SAP Joule for Consultants no debe entenderse simplemente como otro Chat con IA.Su principal diferencia se encuentra en la combinación de inteligencia artificial con un volumen muy amplio de conocimiento y, en determinados casos, restringido.
Esto puede reducir de forma significativa el tiempo dedicado a buscar documentación, interpretar código, investigar errores o preparar determinados entregables.
El efecto profesional puede ser importante. Memorizar SAP Notes tendrá menos valor. Saber dónde encontrar determinada documentación también. Incluso conocer ciertas configuraciones estándar puede dejar de ser un factor diferencial.
A cambio, aumentará el valor de conocer diversos tipos negocio, saber gestionar adecuadamente las reuniones con los usuarios, modelar procesos, diseñar arquitecturas, evaluar alternativas o saber anticipar riesgos.
