Sacar datos de SAP hacia Power BI sin romper nada por el camino

Cuando una organización con SAP quiere analítica moderna, la primera propuesta que suele recibir es conectar Power BI directamente contra las tablas. Funciona en la demostración. Los problemas aparecen después, y son de tres tipos distintos.

Por qué leer tablas directamente se rompe

El modelo de datos de SAP no está pensado para que lo lea nadie de fuera. Un dato de negocio que usted ve como una línea de pedido vive repartido en varias tablas con nombres técnicos, con lógica de interpretación que está en el código de la aplicación, no en la base de datos.

Eso trae dos consecuencias:

• La lógica se duplica. Usted reimplementa en DAX o en SQL reglas que SAP ya aplica. Cuando SAP cambia la regla y usted no se entera, sus números dejan de cuadrar con los suyos y nadie sabe cuál es el bueno.
• Una actualización lo tumba. Las estructuras internas pueden cambiar entre versiones. Lo que era estable durante dos años deja de funcionar un lunes por la mañana.

El tercer problema, que es el caro

Acceder a datos de SAP desde un sistema externo puede tener implicaciones en su contrato de licencia, según cómo se acceda y quién consuma el resultado. No es un detalle técnico: es una conversación contractual.

Antes de elegir el método de extracción, pregunte a su responsable de contrato con SAP qué implica cada vía. Es media hora que puede evitar una revisión de licencias muy desagradable.

Ningún integrador serio debería diseñarle la extracción sin haber tenido esa conversación primero. Si alguien se la propone sin mencionarlo, desconfíe.

Las vías que sí aguantan

• Servicios OData publicados desde SAP. El equipo de SAP expone lo que quiere exponer, con la lógica de negocio ya aplicada. Es la opción más limpia: usted consume un contrato estable, no una tabla interna.
• Vistas analíticas del propio SAP. Pensadas justamente para consumo externo, mantienen la semántica de negocio.
• Extracción a una capa intermedia. Los datos aterrizan en un almacén propio — Fabric, Azure SQL — y a partir de ahí usted manda. Es lo que recomendamos cuando el volumen es alto o cuando hay que cruzar SAP con otras fuentes.

La decisión que casi nadie plantea a tiempo

¿Cada cuánto necesita el dato de verdad? La respuesta instintiva es «en tiempo real», y casi nunca es cierta. Un cierre contable no cambia cada minuto; un inventario, según el negocio, quizá sí.

La diferencia importa porque una extracción incremental nocturna es un orden de magnitud más barata y más estable que una sincronización continua. Pagar por tiempo real para mirar el tablero una vez al día es el desperdicio más común en estos proyectos.

Dónde encaja alguien como nosotros

Seamos claros sobre el reparto: la parte de SAP la lleva quien conoce su SAP, que suele ser su equipo interno o su consultora de SAP. Nosotros entramos del punto de extracción hacia adelante: modelar, almacenar, calcular y presentar. Esa frontera conviene dejarla escrita antes de empezar, porque los proyectos que fracasan suelen hacerlo justo ahí, en la tierra de nadie entre los dos equipos.