SAP Datasphere – aníbal goicochea

Una CDS, cuatro miradas: el reporting de SAP Group Reporting… y casi cualquier otra fuente de SAP

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.

De SAP BW 7.5 a SAP BW/4HANA, la otra opción: claves para una buena estrategia de migración

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.

SAP BW 7.5: cómo preparar la transición antes de 2027

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 es el nuevo SAP BW, es otra forma de tratar a los datos

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.

Enlaces de interés: