Conectar tu ERP y CRM a un dashboard en tiempo real: guía técnica

El dato fragmentado es el mayor enemigo de la toma de decisiones

Tu ERP tiene datos financieros y de inventario. Tu CRM tiene datos comerciales y de clientes. Tu ecommerce tiene datos de ventas online. Tu herramienta de marketing tiene datos de campañas. Mientras estos datos estén en silos, las decisiones se toman con información parcial e incompleta. Un dashboard que conecte todas estas fuentes cambia la forma de gestionar tu negocio.

El síntoma clásico lo reconocerás enseguida: alguien dedica los tres primeros días de cada mes a montar un Excel cruzando exportaciones de tres sistemas, y en el comité de dirección se discute si la cifra de ventas es la del ERP o la del CRM. Ese trabajo manual no solo cuesta horas, cuesta confianza: cuando un número se pone en duda, la decisión se aplaza.

Arquitectura de integración

Hay tres patrones principales para conectar fuentes de datos a un dashboard: conexión directa a las bases de datos (rápido pero rígido), ETL (Extract, Transform, Load) que copia y transforma datos a un data warehouse central, y APIs en tiempo real que consultan los sistemas origen bajo demanda. Para la mayoría de pymes, un enfoque ETL ligero es el más equilibrado entre complejidad y resultado.

ETL o ELT: qué ha cambiado

La diferencia práctica es dónde ocurre la transformación. En el ETL clásico se transforma antes de cargar; en ELT se carga el dato en crudo en el almacén y se transforma allí con SQL. El segundo enfoque se ha impuesto porque el almacenamiento es barato, porque permite reprocesar el histórico cuando cambias una definición de métrica y porque deja una traza auditable de la transformación.

El stack open source más habitual en pymes es Airbyte (o conectores propios) para la extracción y dbt Core para las transformaciones, con el almacén en PostgreSQL o BigQuery. Airbyte supera ya los 600 conectores y su ecosistema se ha movido en 2026 hacia infraestructura de datos pensada también para agentes de IA. Si el volumen es pequeño y las fuentes son dos o tres, un puñado de scripts programados y bien monitorizados sigue siendo una respuesta perfectamente razonable: no montes una plataforma de datos para sincronizar 4.000 facturas al mes.

Cuándo cada patrón

• Conexión directa: una sola fuente, informes sencillos, poca concurrencia. Siempre contra una réplica de solo lectura, nunca contra la base de datos de producción.
• ETL/ELT programado: el caso mayoritario. Varias fuentes, necesidad de cruzar datos e histórico propio.
• API en tiempo real o webhooks: para lo que de verdad debe reaccionar al instante —stock, alertas, disponibilidad—. Combínalo con el anterior, no lo uses como sustituto.

Conectar ERPs habituales

Los ERPs más comunes en España son Holded, A3, Sage, SAP Business One y Odoo. Holded y Odoo ofrecen APIs REST bien documentadas que facilitan la extracción de datos. SAP y Sage suelen requerir conectores específicos o acceso directo a la base de datos. Para cada ERP, los datos clave a extraer son: facturación, gastos, inventario, cuentas por cobrar/pagar, y movimientos de tesorería.

El ERP en 2026: VeriFactu, SII y factura electrónica

Hay un motivo nuevo, y muy concreto, para poner orden en la integración del ERP: el calendario fiscal español. VeriFactu —los requisitos de inalterabilidad, trazabilidad y código QR que impone el RD 1007/2023— será obligatorio desde el 1 de enero de 2027 para sociedades sujetas al Impuesto sobre Sociedades y desde el 1 de julio de 2027 para autónomos. Por su parte, la factura electrónica B2B de la Ley Crea y Crece arranca en octubre de 2027, con un año de plazo para las empresas de más de 8 millones de facturación y dos años para el resto.

¿Qué tiene esto que ver con tu dashboard? Dos cosas. La primera, que en los próximos meses vas a tocar el ERP igualmente para adaptarlo, y es el momento natural para dejar resuelta la extracción de datos. La segunda, que la factura estructurada obligatoria mejora muchísimo la calidad del dato de origen: cuando el documento nace normalizado, los cuadros de mando financieros dejan de depender de conciliaciones manuales.

Notas por ERP

• Odoo: la versión 19, presentada en septiembre de 2025, trae IA integrada y una localización española que cubre VeriFactu, SII, TicketBAI, PEPPOL y SEPA. Su API XML-RPC/JSON-RPC permite leer prácticamente cualquier modelo, lo que la convierte en la más cómoda de integrar. Si estás valorando implantarlo, lo tratamos a fondo en la guía de implantación de Odoo en pymes.
• Holded: API REST sencilla y bien documentada, ideal para pymes; ojo a los límites de peticiones si vas a hacer cargas históricas.
• Sage y A3: según versión, la vía práctica suele ser acceso a base de datos o ficheros de exportación programados. Documenta bien el esquema porque cambia entre versiones.
• SAP Business One: Service Layer (OData) es la vía moderna; requiere licencias y usuarios técnicos bien definidos.

Conectar CRMs

HubSpot, Salesforce, Zoho y Pipedrive son los CRMs más habituales. Todos ofrecen APIs REST que permiten extraer: pipeline de ventas, actividad comercial, contactos y empresas, deals cerrados y perdidos, y métricas de seguimiento. La conexión con estos CRMs suele ser más sencilla que con ERPs gracias a sus APIs modernas y bien documentadas.

Cinco detalles técnicos que evitan sorpresas

1. Paginación y sincronización incremental. No descargues todo cada noche: filtra por fecha de modificación y guarda una marca de agua. Ahorra tiempo, cuota de API y disgustos.

2. Límites de peticiones. Todos los CRMs los tienen. Implementa reintentos con espera exponencial y respeta las cabeceras de límite; si no, la carga histórica te bloqueará la cuenta el primer día.

3. Idempotencia. Un proceso que se reintenta no puede duplicar registros. Usa la clave del sistema origen como identificador único en destino.

4. Webhooks para lo urgente. Para eventos que deben reflejarse al momento —una oportunidad ganada, un pedido nuevo— el webhook es más barato que consultar cada minuto. Necesita un endpoint fiable, con verificación de firma y cola por detrás.

5. Borrados y fusiones. El caso que casi nadie contempla: un contacto que se elimina o se fusiona en el CRM y sigue vivo en tu almacén, inflando las métricas durante meses.

Si vas a exponer o consumir APIs propias en este flujo, revisa también los fundamentos de seguridad en APIs REST: autenticación, autorización y rate limiting, porque una integración mal protegida es una puerta abierta a toda la información comercial de la empresa.

El data warehouse intermedio

En lugar de conectar el dashboard directamente a cada sistema, recomendamos un data warehouse intermedio: una base de datos (PostgreSQL es ideal) donde se consolidan y transforman los datos de todas las fuentes. Esto te da independencia de los sistemas origen, mejor rendimiento (no sobrecargas los sistemas productivos), y la capacidad de cruzar datos entre fuentes.

El problema de las claves: cómo se cruzan de verdad los datos

Aquí es donde se atascan la mayoría de proyectos. El cliente «Industrias López S.L.» es el registro 4471 en el ERP, la empresa 88213 en el CRM y el email compras@ en la herramienta de marketing. Sin una tabla de correspondencias —lo que en jerga se llama entidad maestra— no hay forma de responder a la pregunta que realmente importa: cuánto margen deja cada cliente contando lo que costó captarlo.

La solución no es glamurosa pero funciona: elegir un sistema como fuente de verdad para cada entidad (normalmente el ERP para clientes y productos, el CRM para oportunidades), definir una clave de negocio estable —el CIF, el SKU— y mantener una tabla de mapeo con los identificadores de cada sistema. Cuanto antes se haga, más barato sale.

Modelado y glosario de métricas

Encima de los datos en crudo conviene construir un puñado de tablas limpias y comprensibles: ventas por día y cliente, oportunidades por etapa, márgenes por producto. Y junto a ellas, un documento —una hoja de cálculo basta— donde esté escrito qué significa cada métrica: si «facturación» incluye IVA, si «cliente activo» es el que compró en 12 meses, si las devoluciones restan. Ese glosario evita el 90 % de las discusiones y es lo primero que pide cualquier auditoría.

Actualización y tiempo real

No todo necesita ser en tiempo real. Los datos financieros del ERP pueden actualizarse una vez al día. Los datos del CRM cada hora. Los datos de ecommerce y marketing pueden ser en tiempo real si es necesario. Define la frecuencia de actualización según la necesidad real de cada tipo de dato, no asumas que todo necesita ser real-time.

Una precisión sobre el término «tiempo real»: en la práctica casi siempre significa casi en tiempo real, con una latencia de segundos o pocos minutos. El tiempo real estricto —eventos que se propagan al instante— exige colas de mensajes, procesamiento continuo y una operación que hay que sostener. Merece la pena cuando la latencia cambia una decisión operativa: reservar el último artículo de stock, avisar de una incidencia en producción, cortar una campaña que se está disparando. Para el seguimiento de negocio, no.

Calidad del dato: la parte aburrida que salva el proyecto

Un panel deja de usarse el día que alguien encuentra una cifra que no cuadra y nadie sabe explicar por qué. Para que eso no pase hacen falta tres mecanismos sencillos:

• Controles automáticos tras cada carga: ¿ha llegado un número razonable de registros?, ¿hay campos obligatorios vacíos?, ¿cuadra la suma de facturación con el total del ERP? Si falla, aviso al responsable antes de que lo vea el director general.
• Conciliación periódica: una comparación mensual entre el total del sistema origen y el del almacén. Cinco minutos que dan credibilidad al resto del año.
• Marca de frescura visible en el panel: «datos actualizados a las 06:15 de hoy». Elimina de golpe la pregunta más frecuente y, sobre todo, hace evidente cuándo una carga ha fallado.

Y un principio que repetimos en cada proyecto: si un dato está mal en el origen, no lo arregles en el dashboard. Corrígelo en el sistema de origen o documenta explícitamente la corrección en la capa de transformación. Los parches invisibles en la capa de presentación son deuda técnica que estalla meses después.

Seguridad y protección de datos de la integración

Una integración ERP-CRM mueve, por definición, lo más sensible de la empresa: facturación, márgenes, datos personales de clientes y, según el caso, información de empleados. Merece el mismo trato que cualquier sistema crítico.

• Credenciales de solo lectura y de mínimo privilegio. El usuario de integración accede a las tablas o endpoints que necesita y a nada más. Nunca el usuario administrador «porque es más rápido».
• Secretos fuera del código. Gestor de secretos o variables de entorno, con rotación periódica y registro de quién las usa. Un token de API en un repositorio es una brecha esperando su turno.
• Cifrado en tránsito y en reposo. TLS siempre, cifrado del almacén y de las copias de seguridad.
• Minimización de datos personales. ¿De verdad necesitas el DNI y el teléfono de cada cliente en el almacén analítico para calcular ventas por provincia? Seudonimizar o excluir campos reduce el impacto de un incidente y es exactamente lo que pide el RGPD.
• Registro y retención. Traza de cada sincronización y política de cuánto tiempo se guarda el histórico, escrita y aplicada.

Si tu empresa está trabajando un marco de seguridad formal, todo lo anterior encaja con los controles de acceso, criptografía y relaciones con proveedores de la ISO 27001. Y si la integración conecta plantas, almacenes o maquinaria además del ERP, el enfoque por fases que describimos al hablar de digitalización industrial es el que mejor funciona.

Errores que vemos una y otra vez

Empezar por el panel y no por las preguntas. Sin cinco decisiones concretas escritas en un folio, el proyecto se convierte en un catálogo de gráficos que nadie mira.

Conectar el dashboard contra producción. Funciona en la demo y provoca la primera incidencia grave el día de más carga del año.

No asignar un responsable del dato. Alguien tiene que decidir qué significa cada métrica y arbitrar cuando dos áreas no coinciden. Si ese papel no existe, el panel pierde autoridad.

Sincronizar todo «por si acaso». Multiplica el coste, el tiempo de carga y la superficie expuesta, para acabar usando el 10 % de los campos.

Olvidar el mantenimiento. Las APIs cambian de versión, los campos se renombran, los tokens caducan. Una integración sin mantenimiento planificado se rompe silenciosamente, y lo peor no es que deje de cargar: es que cargue mal.

Confundir integración con migración. Sincronizar datos para analizarlos no es lo mismo que unificar sistemas. Conviene decir en voz alta cuál de las dos cosas se está haciendo antes de firmar el presupuesto.

Coste y plazos

Un dashboard conectado a ERP y CRM con un data warehouse intermedio tiene un coste de desarrollo de entre 8.000€ y 25.000€ dependiendo de la complejidad de las integraciones y el número de fuentes. El plazo típico es de 2-4 meses. El ROI viene de la mejora en la toma de decisiones, la reducción de tiempo en generación de informes manuales, y la detección temprana de problemas.

Qué añadir a ese presupuesto en 2026

La horquilla anterior sigue siendo representativa del desarrollo inicial, pero conviene presupuestar tres partidas que suelen quedarse fuera:

• Infraestructura: entre 50 y 300 €/mes para el almacén y la orquestación en un escenario de pyme. Si usas herramientas ELT gestionadas, el coste crece con el volumen de filas sincronizadas, así que conviene revisar la previsión antes de firmar.
• Mantenimiento evolutivo: entre un 15 % y un 20 % anual del coste inicial. No es opcional: es lo que mantiene la integración viva cuando cambian las APIs.
• Formación y adopción: media jornada por grupo de usuarios. Es la partida más barata y la que más determina si el proyecto se usa.

Hoja de ruta en cuatro fases

Si tuviéramos que resumir en cuatro pasos cómo se hace esto sin quemar presupuesto:

Fase 1 — Preguntas y fuente de verdad (1-2 semanas). Escribe las decisiones que quieres tomar, las métricas que las soportan y de qué sistema sale cada una. Decide quién manda sobre cada entidad (clientes, productos, pedidos) y define las claves de negocio.

Fase 2 — Una sola fuente conectada (2-4 semanas). Normalmente el ERP, que es donde está el dinero. Extracción incremental, almacén con las tablas mínimas y un panel con cinco indicadores. Que funcione y se use antes de añadir nada.

Fase 3 — Cruce con el CRM y el ecommerce (3-6 semanas). Aquí aparece el valor real: coste de captación frente a margen, ciclo de venta, previsión con pipeline y facturación en la misma pantalla. Es también donde se paga el trabajo de claves de la fase 1.

Fase 4 — Operación y mejora continua. Controles de calidad, alertas, revisión trimestral de qué indicadores se miran y cuáles sobran. Un panel que no se poda acaba siendo ruido.

Este orden tiene una ventaja fundamental sobre el enfoque «lo conectamos todo y luego vemos»: cada fase entrega algo utilizable, y si el proyecto se para —pasa— lo entregado sigue sirviendo. Es el mismo principio de entrega incremental que aplicamos al diseñar la arquitectura de plataformas de negocio.

Preguntas frecuentes

¿Necesito un data warehouse si solo tengo dos fuentes?

Probablemente no al principio. Con dos fuentes pequeñas puedes tirar de réplicas de solo lectura y una herramienta de BI que cruce ambas. El almacén se vuelve necesario en cuanto necesitas histórico propio, cruzar entidades entre sistemas o dejar de castigar a la base de datos de producción. Nuestra recomendación práctica: si prevés una tercera fuente en menos de un año, móntalo desde el principio; migrar después cuesta más que hacerlo bien de entrada.

¿Puedo hacerlo con las integraciones nativas de mi ERP o CRM?

A veces sí, y es la primera opción a explorar. Muchos ERPs y CRMs traen conectores hacia herramientas de BI o exportaciones programadas que resuelven el 80 % de las necesidades de una pyme. El límite aparece cuando necesitas cruzar datos entre sistemas o transformar de una forma que el conector no contempla.

¿Cuánto tarda en verse el retorno?

El primer retorno, el más fácil de medir, son las horas que dejan de dedicarse a cuadrar Excel: suele notarse en el primer o segundo mes tras la fase 2. El retorno de fondo —decisiones mejores y más rápidas— tarda uno o dos trimestres, porque exige que los datos entren en la rutina de las reuniones. Si el panel no se abre en el comité, no habrá retorno por muy bien construido que esté.

¿Qué pasa si cambio de ERP dentro de dos años?

Si has separado bien las capas, cambias la extracción y mantienes el almacén, las métricas y el panel. Ese es precisamente el argumento más fuerte a favor del almacén intermedio: te desacopla del proveedor. Sin él, un cambio de ERP obliga a rehacer todo el reporting desde cero.

¿Y la IA? ¿Puede consultar mis datos directamente?

Sí, y cada vez mejor: los asistentes integrados en las herramientas de BI generan consultas en lenguaje natural sobre el modelo. Pero la calidad de la respuesta depende de que las tablas y las métricas estén bien definidas; sobre datos en crudo mal nombrados, un asistente produce respuestas plausibles y equivocadas. Es la misma conclusión a la que llegábamos analizando la IA aplicada al CRM: la herramienta amplifica la calidad de lo que tiene debajo.

¿Qué herramienta de visualización elijo al final?

Depende de dónde estén tus datos, cuánta gente los va a mirar y quién mantiene el sistema. Lo comparamos con precios actualizados en Power BI vs Metabase vs dashboard a medida.

Conclusión

Conectar ERP y CRM a un cuadro de mando no es un proyecto de gráficos: es un proyecto de acuerdos. Acordar qué significa cada métrica, qué sistema manda sobre cada dato, con qué frecuencia se refresca y quién responde cuando algo no cuadra. La tecnología —ETL o ELT, PostgreSQL o BigQuery, Power BI o Metabase— es la parte fácil y la que siempre se puede cambiar.

Empieza pequeño y con una sola fuente, deja el almacén intermedio montado desde el principio y no comprometas tiempo real donde una carga nocturna resuelve el problema. Con ese enfoque, en dos o tres meses tienes un panel que la dirección abre cada lunes; con el enfoque contrario, en seis meses tienes una plataforma impecable que nadie usa.