aníbal goicochea

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.

Preparation Ledger de SAP S4GR: mapeo y realineación de datos

El mapeo entre cuentas contables y posiciones de consolidación es la pieza clave: fundamenta tanto la derivación en tiempo real como la realineación de los datos.

Preparation Ledger: mapeo y realineación de datos

En el post anterior comentábamos el uso del Preparation Ledger en SAP Group Reporting (GRPL). Conviene completar aquella explicación con dos aspectos prácticos: cómo se deriva la posición de consolidación correspondiente a cada cuenta contable y en qué situaciones es necesario realinear los datos.

El mapeo entre cuentas contables y posiciones de consolidación, definido inicialmente por los consultores y mantenido después, en muchos casos, por los propios usuarios, alimenta la derivación en tiempo real. Cuando el Preparation Ledger está activo, este mapeo determina qué posición de consolidación corresponde a cada cuenta contable en el momento de la contabilización.

Realineación de los datos del Preparation Ledger

La realineación resulta necesaria en dos situaciones: cuando el Preparation Ledger se activa después del inicio del ejercicio y cuando cambia el mapeo entre cuentas contables y posiciones de consolidación.

La activación del Preparation Ledger no tiene por qué coincidir con el inicio del ejercicio. En una implementación on-premise puede ponerse en marcha a mitad de ejercicio, aunque hasta ese momento se haya utilizado la integración clásica; posteriormente, es posible realinear la información de los periodos contabilizados sin la funcionalidad activa. En la edición Cloud, en cambio, SAP indica que el paso de la integración clásica al Preparation Ledger solo puede realizarse con el cambio de ejercicio.
Si cambia el mapeo entre cuentas contables y posiciones de consolidación, también será necesario ejecutar de nuevo la realineación para que los datos ya contabilizados reflejen la nueva correspondencia.

En ambos casos, la realineación se ejecuta como un proceso en lote y conviene programarla en franjas de baja actividad. Si la organización gestiona un volumen elevado de información, el proceso puede dividirse en bloques, por periodos e incluso por sociedades, para controlar mejor el consumo de recursos del sistema.

Preparation Ledger en SAP Group Reporting: beneficios, impacto y criterios de adopción

El Preparation Ledger de SAP Group Reporting incorpora al Diario Universal, en el momento de contabilizar, la información que necesita la consolidación: unidad de consolidación, posición de consolidación y sociedad contraparte. Analizamos sus beneficios reales, como el acceso en tiempo real a los datos con visión de consolidación, el tratamiento correcto de los periodos especiales y las reglas de validación, junto con su impacto técnico y los criterios para decidir si la organización está preparada para adoptarlo

El artículo está pensado para dos tipos de lectores: el consultor funcional, responsable de la parametrización, y el responsable financiero, que necesita consultar los datos en tiempo real desde una perspectiva de consolidación. La decisión es técnica, pero el beneficio es de negocio.

La configuración de SAP Group Reporting se apoya en numerosas tablas, muchas de ellas gestionadas mediante transacciones que actúan como vistas de mantenimiento. Entre ellas destacan las que contienen los parámetros globales: valores que, una vez establecidos, determinan el comportamiento general de la plataforma y condicionan la parametrización de todo el módulo.

PREPARATION LEDGER

El Preparation Ledger es uno de esos parámetros globales y se activa fijando el ejercicio a partir del cual entra en funcionamiento. Desde ese momento, al contabilizar cada documento se determinan datos relevantes para la consolidación, como la unidad de consolidación, la posición de consolidación y la sociedad contraparte, y se registran en tiempo real en el Diario Universal (ACDOCA).

Aunque SAP indica que los parámetros globales no pueden modificarse una vez establecidos, en la práctica algunos ajustes pueden gestionarse mediante SAP Support. Quien conozca en profundidad el funcionamiento de estos parámetros y la relación entre las tablas implicadas también puede identificar y actualizar las tablas correspondientes mediante vistas de mantenimiento creadas específicamente para ello. Esta alternativa no está soportada, debe aplicarse bajo la propia responsabilidad y, siempre que sea posible, conviene validarla previamente con SAP Support.

BENEFICIOS DEL PREPARATION LEDGER

El beneficio principal es disponer en tiempo real de los datos necesarios para la consolidación. En el momento de la contabilización, las cuentas contables quedan vinculadas a las posiciones de consolidación, las sociedades a las unidades de consolidación y las contrapartes a las sociedades contraparte. Una vista CDS permitiría consultar estos datos de inmediato en la herramienta de reporting elegida, sin esperar a ejecutar el volcado a consolidación.
Otro beneficio relevante afecta al tratamiento de los periodos especiales. Sin el Preparation Ledger, los importes contabilizados en los periodos del trece al dieciséis se vuelcan a consolidación agrupados en el periodo doce, un resultado que no siempre responde a las necesidades del proceso. Con el Preparation Ledger activado, la información se traslada al periodo en el que se contabilizó originalmente, por lo que se conserva el detalle temporal.
Un tercer beneficio es la posibilidad de establecer reglas de validación y sustitución sobre el Diario Universal. Por ejemplo, en función de la sociedad, la cuenta contable u otros criterios, estas reglas podrían exigir que se informe la sociedad contraparte o impedir la contabilización de determinadas combinaciones de datos maestros. No obstante, no recomendaría gestionar estas reglas desde el Preparation Ledger, ya que podrían solaparse con las validaciones definidas en FI y generar redundancias o incluso contradicciones entre ambos módulos.

CONCLUSIÓN

El Preparation Ledger no es solo un cambio técnico de configuración: adelanta el momento en que la información adquiere significado para la consolidación. Este enriquecimiento deja de ejecutarse como un paso posterior durante el cierre y pasa a incorporarse al dato desde el momento de su contabilización.

Por tanto, la cuestión no es si el Preparation Ledger aporta beneficios, sino si la organización está preparada para integrar la consolidación en la operativa diaria. Adoptarlo implica tratar la consolidación no solo como una actividad de cierre, sino como un proceso continuo que exige reglas de derivación fiables y coordinación entre los equipos implicados.

Apuntes técnicos:

En SAP S/4HANA Cloud, según las funcionalidades utilizadas, la activación del Preparation Ledger puede dejar de ser opcional (KBA 3542410).
No hemos identificado incidencias atribuibles a la duplicidad de la información: los datos con visión de consolidación residen en ACDOCA y, tras el volcado a SAP Group Reporting, también en ACDOCU. En el Diario Universal, además, el incremento de almacenamiento no se debe a la creación de nuevos registros, sino a la incorporación de campos en las líneas existentes.

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:

SAP BTP NEO, con «sunset» (retirada programada) muy próxima

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.