SAP acaba de actualizar su BI Maintenance Strategy (octubre 2026), y el mensaje es claro: SAP BusinessObjects BI sigue vivo y con hoja de ruta.
SAP reafirma su modelo:
Una nueva versión cada 2 años:BI 2025, BI 2027, BI 2029…
3 años de mantenimiento estándar para cada versión.
Después, Customer-Specific Maintenance: el primer año con correcciones de seguridad (CVSS ≥ 7.0) y, a partir de ahí, solo soporte, sin nuevas entregas de software.
Si sigues en BI 4.3, ten en cuenta que su mantenimiento estándar termina el 31 de diciembre de 2026.
La buena noticia es que no hace falta cambiar de herramienta. Basta con renovarla. BI 2025 incorpora en Web Intelligence (WebI) nuevos gráficos y filtros interactivos, informes offline (WIDX) y KPIs en la página de inicio del Launch Pad.
Tus informes, tus universos y tus usuarios siguen siendo los mismos, ahora con soporte asegurado y nuevas funcionalidades.
Quien oye hablar de SAP Group Reporting por primera vez suele imaginar una batería de informes y consultas listas para usar. No es así. SAP Group Reporting es la herramienta de S/4HANA que automatiza el proceso de elaboración de los Estados Financieros consolidados.
El estándar incluye las CDS del modelo de datos virtual (VDM) sobre las que se construye el reporting. Estas CDS se pueden ampliar, o tomarse como base de otras nuevas, para incorporar dimensiones o datos maestros adicionales, estándar o custom. Las Best Practices y la instalación estándar aportan además algunos libros de Analysis for Office y varias aplicaciones Fiori. Pero todo esto no basta para cubrir el reporting básico que se pide en cualquier implantación o, simplemente, nada de eso resulta útil en la mayoría de las circunstancias.
NOTA: CDS (Core Data Services): Es una definición lógica de los datos y de su semántica (qué representan, cómo se relacionan y cómo se consumen). No almacena datos: el sistema la traduce a lenguaje SQL y ejecuta estas instrucciones directamente en la capa de la base de datos.
Alternativas para el reporting
En nuestra opinión, hay cuatro vías para cubrir los informes y las visualizaciones de los datos de consolidación (también aplicable sobre cualquier otra fuente SAP).
Herramienta
Facilidad de uso
Capacidad gráfica
Integración con Excel
Navegación por jerarquías
Uso recomendado
SAP Analysis for Office
●●●●●
●○○○○
●●●●●
●●●●●
Análisis operativo y conciliaciones
Aplicaciones Fiori
●●●○○
●●○○○
●●●○○
●●●●○
Consulta rápida integrada en S/4HANA
SAP Analytics Cloud (Live)
●●●○○
●●●●●
●●○○○
●●●●●
Informes de dirección, semestrales y anuales
Web Intelligence
●●●●○
●●●●○
●●●●○
●●●○○
Informes formateados y distribución masiva
Herramientas no SAP (Power BI, Tableau…)
●●●○○
●●●●●
●●●○○
●○○○○
Solo como referencia: suelen manejar mal todo tipo de jerarquías SAP
Escala de 1 a 5, según nuestra experiencia.
Nota: no se incluye SAC con Import Connection. Salvo que haya que combinar los datos de GR con otras fuentes, realizar cálculos complejos o que exista un problema de rendimiento por una granularidad elevada (número de dimensiones utilizadas), no se justifica replicar los datos en distintas plataformas.
Analysis for Office (AfO). Se adopta con facilidad porque funciona sobre Excel. Si defines jerarquías, se navega muy bien por ellas. Es práctico e inmediato. Tiene gráficos, pero de calidad limitada.
Aplicaciones Fiori. El estándar incluye varias aplicaciones analíticas basadas en consultas CDS, como Group Data Analysis, con y sin reglas de reporting. Para tus propias consultas, defines la CDS de tipo query y la localizas con el Explorador de consultas (Query Browser). Desde ahí la ejecutas y puedes crear un tile o mosaico en el Launchpad de Fiori, con acceso similar al de cualquier otra aplicación Fiori. Los gráficos son limitados y los datos se pueden exportar a Excel.
SAP Analytics Cloud. Hay que distinguir entre Live Connection e Import Connection.
Live: consume la misma query que AfO y Fiori, así que el modelo de datos y las jerarquías se comportan igual, con mucha agilidad. El rendimiento depende de la CDS, por lo que es recomendable diseñar una específica para SAC con las dimensiones, medidas y textos estrictamente necesarios.
Import: obliga a replicar el modelo, los datos y las jerarquías, lo que duplica el esfuerzo de construcción y mantenimiento.
La calidad gráfica es muy superior a la del resto. En cambio, es poco práctico para analizar al detalle la operativa de la consolidación. Encaja mejor en informes semestrales o anuales, donde pesan más los gráficos que las tablas.
Web Intelligence. Es la alternativa en la que menos se piensa hoy, pero es viable. La versión BI 2025 mejora la conectividad BICS, que permite consumir las consultas de CDS, e incorpora gráficos nuevos y más opciones de exportación. En formato de informe y exportación a Excel, WebI no tiene rival.
Una única fuente
Las cuatro vías pueden convivir en la misma implantación y usar la misma fuente lógica: una CDS de tipo query. No hace falta replicar los datos en BW, SAC o Datasphere (salvo que exista la necesidad de ampliar o complementar la información).
Al activar la CDS, el sistema genera una query transitoria con el prefijo 2C más el nombre de su SQL view. Por ejemplo, si defino una CDS con el nombre ZGR_CONSO_MAT_10_SAC y el identificador de SQL view ZCCSMAT10SAC, se genera la query 2CZCCSMAT10SAC. Se llama transitoria porque no se persiste, es decir, no existe como un objeto físico, el motor analítico la construye al vuelo a partir de la CDS.
Fiori la localiza por el nombre de la CDS.
AfO, SAC Live y Webi la consumen por su nombre 2C*.
Por debajo, todas estas herramientas ejecutan exactamente la misma consulta.
Cómo viaja el dato: cinco capas
Presentación.Fiori, SAC, AfO o WebI muestran los datos y permiten navegar por ellos. Pueden añadir cálculos propios, como fórmulas en WebI, medidas calculadas en SAC o miembros locales en AfO, pero la lógica principal de la consulta la resuelve el motor analítico.
Protocolo. Transporta la petición: de tipo InA (HTTP y JSON) para Fiori y SAC, y de tipo BICS (RFC) para AfO y WebI.
Motor analítico (BW embebido). Ejecuta la query 2C*: jerarquías, agregaciones, cálculos, variables y autorizaciones.
ABAP CDS. Es el modelo semántico: la CDS de tipo query definida sobre otra CDS de tipo cube, en este ejemplo I_MatrixConsolidationReportC. Solo contiene definiciones, no datos.
Base de datos (HANA). Lee físicamente los datos a través de las vistas SQL encadenadas hasta la tabla ACDOCU.
Aviso práctico: no cambies el sqlViewName de una CDS en uso. Al cambiarlo cambia el nombre 2C*, y se rompen los libros de AfO y los modelos de SAC que apuntan a él.
Si el dato no necesita transformaciones ni combinarse con otras fuentes, la CDS es la mejor alternativa.
Conclusión
El reporting no viene resuelto con SAP Group Reporting: hay que diseñarlo. La clave no es elegir una herramienta, sino diseñar bien las CDS de tipo query desde el inicio, según lo que requiere el proyecto. Con una CDS sólida, se puede proponer una herramienta según el perfil del usuario:
El consolidador, AfO;
El controller, Fiori;
La dirección, SAC;
La distribución, Webi.
Y todos consultan la misma fuente.
Este enfoque no es exclusivo de SAP Group Reporting: cualquier dato de S/4HANA expuesto mediante una CDS de tipo query puede seguir el mismo camino.
¿Cómo repartimos los costes y cómo explicamos la rentabilidad? Ante esta necesidad, seguro que inmediatamente, pensamos en una solución a medida con ABAP, BW o, más recientemente, Datasphere o SAC.
Hay otra opción que conviene valorar: SAP Profitability and Performance Management (PaPM). Es una aplicación para modelar cálculos y procesos de negocio complejos, con funcionalidades específicas de asignación de costes y análisis de rentabilidad. Su alcance incluye también escenarios fiscales y de precios de transferencia operativos (los importes que unas sociedades de un grupo cobran a otras por productos o servicios).
Un ejemplo: repartir los costes centrales de una constructora entre sus proyectos según empleados, insumos, maquinaria o servicios consumidos, y analizar cómo cambia el margen de cada uno.
No es un producto nuevo. La versión 1.0 salió en 2015 y la 3.0 en 2018 (versión vigente en on-premise). Además, toma el relevo funcional de SAP BusinessObjects Profitability and Cost Management (PCM) en costes y rentabilidad, incluido el cálculo basado en actividades. PCM 10.0 está en mantenimiento específico de cliente desde enero de 2024, y SAP recomienda PaPM como alternativa. Incluso proporciona contenido para migrar reglas de PCM a PaPM.
¿Qué opciones existen hoy?
PaPM 3.0 on-premise (add-on NXI 300): se instala sobre NetWeaver 7.50, S/4HANA, BW/4HANA o ERP 6.0 EHP8, siempre sobre SAP HANA Database. Su mantenimiento sigue al de la plataforma que lo contiene.
PaPM Cloud: disponible desde 2021, ofrece dos aplicaciones de modelado: Standard Model, orientado a repartos con grandes volúmenes, y Universal Model, que requiere una activación específica.
On-premise sigue evolucionando. La SP28, publicada en septiembre de 2026, incorpora un Runtime Analysis Cockpit, nuevos tipos de particionado (Hash y Hash-Range), soporte de CDS View entities en conexiones y carga masiva de instancias de proceso desde Excel.
Sin embargo, el roadmap concentra las innovaciones más destacadas en Cloud, con fuerte apuesta por la IA. Está previsto, por ejemplo:
Asistencia en el mantenimiento de reglas de derivación en Universal (Q4 2026).
Asistencia en la configuración de funciones de reparto en Standard (Q2 2027).
Un LLM entrenado por SAP para este dominio (Q3 2027).
Son funcionalidades previstas y sujetas a cambios.
Alternativas SAP y no-SAP
Dentro de SAP, según la complejidad de los requisitos, existen alternativas con alcances distintos: Universal Allocation en S/4HANA y los repartos de SAC Planning. También pueden construirse soluciones a medida con ABAP, BW, SAC o Datasphere. En ese caso, hay que valorar bien su coste de diseño y mantenimiento.
Fuera de SAP destacan Oracle Enterprise Profitability and Cost Management y CCH Tagetik Profitability Analysis, ambas con capacidades específicas de asignación de costes y análisis de rentabilidad.
Antes de desarrollar otro reparto a medida, contrasta tus reglas, volúmenes y necesidades de trazabilidad con las soluciones disponibles. Y pregúntate: ¿la solución propuesta ayudará a explicar el negocio hoy y mañana?
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.
El 31 de diciembre de 2027 termina el mantenimiento estándar de SAP BW 7.5. Queda poco más de un año, y muchas empresas están decidiendo su siguiente paso.
SAP apuesta por SAP Business Data Cloud, con Datasphere como pieza central. Sin embargo, muchas organizaciones prefieren ir con cautela y optar por lo conocido: SAP BW/4HANA. Mantiene la filosofía de BW, aprovecha el conocimiento del equipo y tiene soporte garantizado hasta 2040. Datasphere queda como una evolución posterior o como un proyecto propio, cuando el negocio esté preparado y tenga el reto de un nuevo desarrollo.
Requisitos técnicos de partida
Conversión in-place (sobre el mismo sistema): BW 7.5 SP05 o superior, ya sobre SAP HANA.
Conversión remote o shell (sistema nuevo): desde BW 7.0, con cualquier base de datos.
Revisión de HANA 2.0: la que exija la versión destino de BW/4HANA, que hay que comprobar en el PAM de SAP.
Herramientas necesarias: SAP Readiness Check, BW/4HANA Starter Add-on y Transfer Cockpit.
Estrategia en tres fases
1. Antes de la migración (la clave)
Diagnóstico con el Readiness Check, el análisis de código propio y el uso real de informes.
Limpieza: comprimir cubos, depurar los históricos de cambios de los DSO, vaciar las PSA y eliminar objetos sin uso y restos de flujos 3.x.
Adaptación: rehacer las conexiones DB Connect, pasar las fuentes SAP a ODP, sustituir InfoPaquetes por DTP y corregir rutinas y código Z.
Banco de pruebas: guardar datos e informes de referencia para validar el resultado.
Ensayo completo en un sandbox, copia de producción, para medir la parada real.
2. La migración
Conversión de objetos con el Transfer Cockpit, modo B4H y conversión técnica con SUM.
Secuencia desarrollo → calidad → producción, con una copia de seguridad antes de cada paso irreversible.
3. Después de la migración
Adaptar los informes que desaparecen (plantillas web y BEx Analyzer).
Comprobar con el banco de pruebas que los resultados coinciden.
Conclusión
El éxito no se decide el día de la migración, sino en los meses anteriores. Cada objeto limpiado o adaptado antes es un posible fallo menos, menos horas de proceso y menos ajustes después. Cuanto mejor preparado llegue el sistema, menor será el impacto en el negocio y menor el riesgo de sobrecostes.