El ERP no es el problema: el problema es que los datos no salen de él. Conectamos Oracle, Oracle SIGES, SAP, Dynamics, Navision o SAGE con Power BI mediante extracción en solo lectura y cargas incrementales cada hora. Tu ERP sigue funcionando exactamente igual el día después.
Los ERP con los que trabajamos
Cambia el origen, no el planteamiento: identificar las tablas que importan, leerlas sin escribir y construir fuera del ERP el modelo que el ERP no puede darte.
La integración Oracle Power BI se resuelve con un usuario de solo lectura y consultas acotadas a las tablas de movimientos, maestros y documentos que alimentan los indicadores. Nada de vistas nuevas dentro del ERP si no hacen falta.
Oracle SIGES BI en producción. Es el caso donde mejor se ve el retorno de integrar: la misma extracción se ha reutilizado en cuatro sistemas distintos del mismo grupo, sin volver a abrir el ERP para cada uno.
Conectar SAP con Snowflake es una cadena que tenemos en producción en un laboratorio farmacéutico: extracción desde SAP, carga en Snowflake, modelado con dbt y Power BI como capa de consumo.
Para la integración Dynamics BI desarrollamos un conector HTTP propio contra el ERP en una empresa del sector industrial, con el que sincronizamos tarifas y conciliamos albaranes respetando sus reglas de negocio.
Instalaciones con años de historia y campos reaprovechados para usos que nadie documentó. El trabajo previo no es técnico: es sentarse con quien graba los movimientos y averiguar qué significa realmente cada columna.
Contabilidad, facturación y cartera leídas en modo consulta para cruzarlas con compras y stock. El objetivo no es replicar el ERP, es poder comparar lo que el ERP guarda en módulos separados.
¿Tu ERP no está en la lista? También leemos PostgreSQL y MS SQL Server directamente. Lo que importa no es la marca, sino si podemos leer sus datos sin interferir en su funcionamiento.
Cómo extraemos
La objeción habitual de un director de sistemas no es el precio: es el miedo a que alguien toque el ERP que sostiene la operación diaria. Esta es la respuesta, punto por punto.
La integración usa usuarios dedicados sin permisos de escritura. No creamos tablas dentro del ERP, no añadimos campos y no alteramos sus índices. Si el día de mañana se corta la integración, el ERP se queda exactamente igual que antes de conocernos.
Cada ejecución lee únicamente lo creado o modificado desde la anterior, no la tabla entera. Airflow orquesta las dependencias, reintenta lo que falla y deja traza de cada carga, de modo que siempre se sabe qué dato entró y cuándo.
Nadie tiene que cambiar cómo graba un albarán, cómo cierra un inventario o cómo emite una factura. El modelo analítico se adapta al ERP y a sus costumbres, no al revés. Si un dato se introduce mal, lo detectamos y lo decimos, pero el procedimiento sigue siendo vuestro.
Las consultas se acotan, se programan y se vigilan. Un ERP grande puede tener miles de tablas: el mérito no es extraerlas todas, es identificar las que importan. Leer menos y mejor es lo que hace que la integración sea invisible para quien trabaja en el ERP.
La parte difícil de una integración de ERP con Power BI casi nunca es técnica. Es entender qué significa cada tabla en esa empresa concreta: qué series de documentos se usan de verdad, qué campo marca una devolución, qué almacenes son reales y cuáles solo existen para cuadrar. Ese trabajo se hace una vez y se amortiza en cada sistema que venga después.
La arquitectura
Cada capa tiene una responsabilidad y se puede sustituir sin rehacer las demás. Esa separación es lo que permite reutilizar la extracción en varios sistemas.
Cuando además hay varias sedes, la red forma parte del problema: lo contamos en la red que permite trabajar contra el ERP desde varias sedes.
Oracle, SIGES, SAP, Dynamics, Navision o SAGE, tal y como está hoy. Se mapean las tablas que alimentan cada indicador y se documenta el significado real de cada campo.
Consultas de solo lectura o conector HTTP contra los servicios del ERP cuando no hay acceso a la base. Cargas incrementales horarias orquestadas con Airflow, con reintentos y alertas.
Almacén analítico en PostgreSQL gestionado sobre AWS (Aurora) o en Snowflake, con el modelado y las transformaciones versionadas en dbt. Aquí viven las reglas de negocio, fuera del ERP.
Los cuadros de mando leen del modelo analítico, nunca del ERP. Un informe pesado no puede ralentizar a quien está facturando, porque ni siquiera se conecta a la misma base.
La consecuencia práctica de separar capas: cambiar de herramienta de visualización, añadir un segundo ERP o abrir el modelo a otra área del grupo no obliga a rehacer la extracción.
Qué se consigue
Un ERP sabe lo que ha pasado, documento a documento. Lo que cuesta es la vista agregada, la comparación entre periodos y el cálculo que cruza compras, stock y ventas.
Calculamos el precio medio ponderado de forma automatizada sobre los movimientos de stock, no sobre la última compra. El PMP se distorsiona con las devoluciones valoradas a precio de venta, con las regularizaciones de inventario y con los descuentos retroactivos de proveedor: los tres casos se tratan de forma explícita.
Con un coste fiable, el margen deja de ser una estimación. Se puede bajar a la referencia concreta, al cliente concreto y al territorio concreto, que en Canarias es una dimensión de negocio y no un detalle geográfico.
El ERP muestra la foto de hoy. El modelo analítico guarda la serie: rotación, cobertura, inmovilizado y lo que entró y salió de cada almacén en cada periodo, comparable mes a mes.
Albaranes contra facturas, tarifas aplicadas contra tarifas pactadas, movimientos de almacén contra contabilidad. Las discrepancias aparecen solas en vez de descubrirse al cierre.
Un ERP, cuatro sistemas
Un Oracle SIGES integrado una vez ha alimentado cuatro sistemas distintos dentro del mismo grupo. Ninguno obligó a volver a abrir el ERP ni a repetir el trabajo de entenderlo.
Coste real por artículo y lote, y margen por referencia, cliente e isla a partir de los mismos movimientos de stock y de venta.
Los documentos de reparto del ERP se cruzan con la operativa de vehículos para analizar rutas, entregas y costes de distribución.
Cartera de cobros y pagos sobre los mismos maestros de clientes y proveedores, sin mantener un segundo listado en paralelo.
Control de lo facturado contra lo servido y contra la tarifa que correspondía, con las diferencias señaladas antes del cierre.
Es el argumento más honesto a favor de integrar en lugar de sustituir: el ERP ya contiene la información: lo que falta es una capa que la deje usar cuatro veces.
Casos
Casos reales, descritos sin identificar al cliente. Lo que se cuenta es el planteamiento técnico, no sus datos ni su infraestructura.
En un laboratorio farmacéutico tenemos en producción la cadena completa: extracción desde SAP, carga en Snowflake como almacén analítico, modelado y transformaciones versionadas con dbt, y Power BI como capa de consumo. SAP no se modifica en ningún punto del recorrido.
El proyecto tiene entornos de preproducción y producción separados: ningún cambio en el modelo llega a los cuadros de mando sin haberse probado antes. Las incidencias de carga generan alertas a Slack, de forma que el equipo se entera de un fallo por el aviso y no porque alguien note un número raro en un informe.
En una empresa del sector industrial construimos un conector HTTP propio contra su ERP Dynamics. Con él sincronizamos las tarifas, de manera que el precio que se aplica fuera del ERP es siempre el que el ERP considera vigente, sin listados paralelos que se quedan viejos.
Sobre esa misma integración se monta la conciliación de albaranes: lo servido se compara con lo facturado y con la tarifa que correspondía, y las diferencias se señalan para revisión. Es el ejemplo de que, cuando no hay acceso directo a la base de datos, la integración sigue siendo posible por los servicios del propio ERP.
Seguridad y entornos
Todo funciona el primer día. La diferencia aparece el día que una carga falla, que cambia una contraseña o que alguien quiere probar un cambio en el modelo.
Los cambios en el modelo se prueban en preproducción antes de tocar los cuadros de mando que mira el comité de dirección. Es la práctica que tenemos en producción en el proyecto del laboratorio farmacéutico.
Usuarios de solo lectura dedicados a la integración y credenciales gestionadas fuera del código, nunca escritas en un script ni compartidas por correo. Rotarlas no obliga a reescribir nada.
Cada carga deja traza y cada fallo genera un aviso. Un informe que no se ha actualizado es más peligroso que un informe que no existe, porque nadie duda de él.
FAQ
Hablemos
Cuéntanos tu ERP y los indicadores que necesitas. Te proponemos cómo extraerlos sin tocarlo, sin compromiso.