En este artículo
El primero de cada mes, a las ocho y media de la mañana, el controller de una empresa industrial mediana empieza con el mismo ritual. Abre el ERP, navega hasta el módulo de contabilidad, selecciona el período anterior y exporta el CSV. Lo importa en Excel. Abre la hoja de gastos de tarjetas corporativas que le ha mandado el departamento de RRHH. Cruza los centros de coste. Descarga el extracto bancario para conciliar los pagos que no han pasado todavía por el ERP. Actualiza las fórmulas de la cuenta de resultados. Quita los duplicados que siempre aparecen en la línea de servicios profesionales. Construye el cuadro de mando manual con los KPIs del mes. Lo formatea. Lo manda a dirección.
El proceso toma entre dos y tres horas cada primer día del mes. Son entre 24 y 36 horas al año. Multiplicadas por el coste horario de un controller cualificado. Más el tiempo de dirección que espera el informe para empezar la reunión de seguimiento del lunes. Más el riesgo de error humano en cada paso manual — que es real, y que alguna vez ha provocado que una cifra incorrecta llegue al consejo de administración y haya que corregirla a posteriori con la incomodidad que eso genera.
El mayor desperdicio no es solo el tiempo. Es que el controller, que es uno de los perfiles más valiosos del equipo financiero, pasa ese tiempo siendo una tubería de datos en lugar de analizando qué significan los datos y qué decisiones implican. El trabajo de mover datos de un sistema a otro puede automatizarse. El trabajo de interpretar los datos y convertirlos en recomendaciones no puede.
La lentitud del cierre mensual manual tiene una causa estructural: demasiadas fuentes de datos desconectadas que no hablan entre sí. El ERP tiene los asientos contables, pero no tiene los gastos de tarjeta que gestionan otras plataformas. El banco tiene los movimientos reales, pero no están integrados con el ERP. El CRM tiene la facturación prevista, pero no está conectado con lo que realmente se ha facturado en el período. El Excel de control presupuestario lo mantiene manualmente el controller y se actualiza cuando alguien se acuerda.
Cada exportación manual es un punto de error potencial. El formato del CSV del ERP cambia cuando el proveedor hace una actualización y las fórmulas de Excel dejan de funcionar. Los filtros de fecha se aplican de forma diferente según quién hace la exportación. La persona que normalmente hace el cierre está de vacaciones y su sustituto no conoce todos los pasos del proceso, que además no están documentados en ningún sitio porque "siempre lo ha hecho la misma persona".
La lentitud también viene de la secuencialidad del proceso. El cierre no puede empezar hasta que el ERP cierra el período contable, lo que a veces ocurre el día dos o el día tres del mes siguiente. Luego hay que esperar a que todos los departamentos manden sus datos adicionales. Luego hay que consolidar y revisar. El resultado es que la dirección recibe los datos del mes anterior entre el día cinco y el día diez — cuando ya estamos a mitad de la segunda semana del mes nuevo y las decisiones que requieren esos datos ya se han tomado sin ellos, o se han retrasado esperándolos.
La integración del ERP con Power BI no es una conexión directa en el sentido de que Power BI lee directamente de la base de datos de producción del ERP. Esa aproximación existe y técnicamente funciona, pero tiene problemas serios: sobrecarga el servidor del ERP, los datos no están transformados para el análisis y cualquier cambio en el esquema del ERP rompe el modelo de Power BI. La arquitectura correcta es un pipeline de datos que mueve la información del ERP a una capa analítica separada, donde se transforma y se prepara para el análisis.
El pipeline conecta con la base de datos del ERP a través de conectores nativos — en el ecosistema Microsoft, esto se hace con Azure Data Factory o directamente con las capacidades de ingesta de Microsoft Fabric. Los datos se copian al OneLake de Fabric con una frecuencia configurada: puede ser cada hora, cada noche, o en tiempo real para los datos más críticos. Esta copia es transparente para los usuarios del ERP y no afecta al rendimiento del sistema transaccional.
Una vez en el OneLake, los datos siguen una arquitectura Medallion de tres capas. La capa Bronze contiene los datos en bruto tal como llegan del ERP, sin transformar. La capa Silver los limpia, normaliza y estandariza: unifica los formatos de fecha, resuelve los problemas de codificación de caracteres, elimina duplicados, homogeneiza los nombres de centros de coste que en el ERP histórico tienen variaciones por cambios de codificación a lo largo del tiempo. La capa Gold construye el modelo de negocio: la cuenta de resultados con la estructura que usa la empresa, los KPIs financieros calculados con las definiciones acordadas, las comparativas versus presupuesto con los datos del plan cargados en el mismo modelo.
Power BI lee del modelo semántico construido sobre la capa Gold. El modelo semántico tiene todas las relaciones entre tablas definidas, todas las medidas DAX precomputadas para las métricas más comunes, y todas las reglas de seguridad a nivel de fila para que cada usuario vea solo los datos de su ámbito. El resultado es que el dashboard del CFO se actualiza automáticamente cuando el ERP cierra el período contable — sin ninguna acción manual.
No todos los ERPs se integran de la misma forma, y es importante entender las opciones disponibles para cada sistema antes de diseñar la arquitectura de datos.
SAP Business One es uno de los ERPs más extendidos en PYMEs industriales y de distribución en España. Tiene un conector directo con Microsoft Fabric que permite leer las tablas de la base de datos HANA o SQL Server de forma nativa. La integración es relativamente sencilla porque SAP tiene documentado el esquema de datos y existen plantillas de ingesta predefinidas para las tablas más comunes: movimientos contables, maestro de clientes, líneas de pedido, albaranes.
Microsoft Dynamics 365 Business Central es quizás el caso más sencillo de integrar con Power BI porque ambos son productos de Microsoft y el conector es nativo. Dynamics BC expone una API OData que Fabric puede consumir directamente, y además hay un conjunto de tablas y entidades predefinidas específicamente para BI. La integración puede estar operativa en días en lugar de semanas.
Sage 200 y Sage X3 requieren una aproximación diferente. Sage no tiene conectores nativos con Fabric, por lo que la integración se hace a través de Azure Data Factory con un conector ODBC a la base de datos SQL Server subyacente, o bien a través de la API REST que Sage ha ido exponiendo en versiones recientes. La complejidad es media — requiere más configuración que Dynamics BC pero menos trabajo custom que otros sistemas.
A3 ERP es especialmente común en empresas con gestión de nóminas y contabilidad integrada. Al no tener conector nativo con plataformas cloud, la integración más habitual es la exportación automática programada de archivos hacia un Azure Blob Storage, desde donde Fabric los ingesta. Es un patrón menos elegante que una conexión directa a base de datos, pero funciona bien con una cadencia de actualización diaria.
Odoo es el ERP open source más adoptado en PYMEs tecnológicas y startups. Su integración es limpia gracias a la API REST que expone de forma nativa. Fabric puede consumir esta API directamente con un pipeline estándar, y el modelo de datos de Odoo, aunque complejo, está bien documentado. Para integraciones más complejas con módulos customizados de Odoo, puede ser necesario mapear las tablas adicionales que el cliente ha creado.
La integración del ERP con Power BI es el núcleo del modelo financiero automatizado, pero para tener una visión financiera completa es necesario conectar otras fuentes que contienen datos que el ERP no captura.
Las plataformas de gastos de empresa — Soldo, Pleo, Tickelia y similares — gestionan los gastos con tarjeta corporativa, los tickets de desplazamiento y los gastos del equipo comercial. Estos gastos representan en muchas empresas entre el cinco y el quince por ciento de los costes operativos, y hasta hace poco solo entraban al ERP cuando el controller hacía la importación manual mensual. Con la integración directa vía API, estos gastos fluyen al modelo en tiempo real, categorizados y asignados al centro de coste correcto.
Los datos bancarios a través de Open Banking son quizás la integración de mayor impacto para la gestión de tesorería. La PSD2 europea obliga a los bancos a exponer APIs que permiten leer el saldo y los movimientos de cuentas corrientes en tiempo real. Con esta integración, el dashboard de tesorería muestra el saldo actual en todos los bancos consolidado, la previsión de las próximas semanas basada en los cobros y pagos previstos en el ERP, y las alertas cuando el saldo previsto cae por debajo de un umbral definido.
El CRM — sea Salesforce, HubSpot, Dynamics 365 Sales o cualquier otro — aporta la dimensión de previsión de ingresos al modelo financiero. El pipeline de ventas valorado por probabilidades es el input para el forecast de facturación, que se conecta con el presupuesto de ventas para calcular la desviación esperada antes de que el mes cierre. Esta capacidad predictiva es la que da mayor valor añadido: no solo ver lo que ha pasado, sino anticipar lo que va a pasar.
Los datos de nóminas y coste de personal son habitualmente el bloque de coste más grande en empresas de servicios. Integrar la plataforma de nóminas — Sage HR, A3 Nóminas, Factorial, Personio — permite tener el coste de personal mensual desagregado por departamento, centro de coste y tipo de contrato, actualizado automáticamente cuando se procesa la nómina, sin esperar a que el proveedor externo mande el resumen.
Una pregunta frecuente y legítima: ¿cuánto tarda en estar operativo este sistema? La respuesta depende de la complejidad del ERP, del número de fuentes adicionales que se quieran integrar y del nivel de detalle del modelo financiero que se quiera construir.
En un escenario estándar — un ERP con conector maduro como Dynamics BC o SAP B1, sin fuentes adicionales complejas y con un modelo financiero de cuenta de resultados y KPIs básicos — la integración y el primer dashboard están operativos en dos a tres semanas. El modelo completo con todas las fuentes integradas, las comparativas versus presupuesto y los análisis de desviación suele estar terminado en cuatro a ocho semanas.
La mejora en el tiempo de cierre es inmediata. En la primera quincena de uso, el proceso que tomaba dos o tres horas el primer día del mes se reduce a menos de veinte minutos de revisión y validación. En los ciclos siguientes, cuando el equipo ha ganado confianza en el proceso automatizado, muchos controllers optan directamente por revisar el dashboard en lugar de reconstruir el informe — y el tiempo de cierre pasa a ser el tiempo de validación del ERP más el tiempo de revisión del dashboard, que juntos raramente superan las veinticuatro horas.
¿Quieres ver cuánto tardaríamos en automatizar el cierre mensual de tu empresa? Agenda una demo y te damos una estimación concreta con tu ERP.
// escrito por
Director de 480 Analytics
En 480 Analytics, la unidad de datos de Cuatroochenta, ayuda a empresas a ordenar y explotar sus datos con Power BI, Microsoft Fabric e IA. Escribe sobre lo que aprende por el camino.
Un modelo semántico no es un dashboard: es el diccionario común de tu empresa —qué es 'ventas', cómo se calcula el margen— y la base de la IA sobre tus datos.
Un buen dashboard financiero no son 40 gráficos: son 8-10 métricas críticas que responden a lo que se pregunta la dirección cada semana. Cómo debe ser.
Tener el P&L del mes el día 5 no es un lujo: es gestionar con información en vez de explicar lo que ya pasó. El porqué y las 5 causas que retrasan el cierre.
Te lo cuantificamos. Empezamos por descubrir y ordenar tus datos, y los convertimos en decisiones — empezando por el reporting financiero (FP&A).