Para ver el ERP y el CRM en un solo lugar, no copias todo a una base nueva. Consolidas ambas fuentes en OneLake, el almacén único de Microsoft Fabric, y por cada sistema eliges el mecanismo de entrada más simple que cumpla tu latencia y tu seguridad: un shortcut si el dato puede quedarse donde está, mirroring si necesitas una réplica de baja latencia, un copy job para copias incrementales o un pipeline cuando el flujo tiene varios pasos. Así dirección y equipo trabajan sobre la misma verdad, en Excel, Power BI o cualquier IA.
Por qué el ERP y el CRM viven separados (y qué duele)
El ERP guarda la operación: facturas, inventario, costos, órdenes. El CRM guarda la relación comercial: oportunidades, clientes, etapas del embudo. Son dos sistemas distintos, con dos modelos de datos distintos, y cada uno responde bien a su propia pregunta.
El problema aparece cuando la dirección quiere una pregunta que cruza ambos: ¿cuánto margen real deja cada cliente? ¿Qué vendedor trae clientes que después pagan tarde? Nadie puede responder sin exportar dos planillas, pegarlas a mano y rezar para que los identificadores coincidan. Es el mismo desafío de fondo que aparece al unificar los datos de ventas, finanzas y operaciones: sin un punto común, cada pregunta que cruza áreas termina en una planilla pegada a mano. Cada reunión empieza discutiendo de qué cifra hablamos, no qué decisión tomamos.
Conectar ERP y CRM en un solo lugar resuelve exactamente eso: un punto único donde ambos datos conviven, con las mismas definiciones, listo para que cualquiera consulte.
Consolidar no es copiar todo a un servidor nuevo
El error clásico es pensar que unificar significa volcar ambos sistemas dentro de una tercera base de datos gigante. Eso duplica datos, multiplica el mantenimiento y crea una copia que envejece.
En Microsoft Fabric, el punto de encuentro es OneLake: un único almacén lógico para toda la organización. La decisión importante no es *dónde* guardar, es *cómo entra* cada fuente. Y esa es una decisión por sistema, no una sola para todo.
Primero se decide si el dato se referencia, se replica, se copia o se transforma. Cuatro preguntas ordenan esa decisión: en qué sistema reside hoy el dato, qué retraso tolera el negocio, si hace falta transformarlo antes de usarlo y cuántas actividades encadenadas exige la carga. La guía de opciones de ingesta de Microsoft ordena esos criterios. Data Factory, dentro de Fabric, no es una sola herramienta: es un conjunto de mecanismos, y elegir bien es la mitad del trabajo.
Los cinco mecanismos para traer datos a OneLake
Estos son los criterios para elegir la estrategia de entrada y movimiento, según la guía de Microsoft:
| Mecanismo | Cuándo usarlo | Qué debe quedar definido |
|---|---|---|
| OneLake Shortcut | La fuente sigue operando en su sitio y a Fabric le alcanza con apuntar a ella, sin generar una segunda copia | Origen, credencial, dependencia externa, seguridad y comportamiento si la fuente deja de estar disponible |
| Mirroring | Hay una base operacional soportada cuya réplica en OneLake debe llegar casi al instante, sin que nadie construya un ETL a medida | Fuente soportada, alcance de tablas, latencia aceptada, seguridad y controles de replicación |
| Copy Job | El requisito se limita a trasladar registros, sea en carga total, por incremento o leyendo cambios con CDC, sin orquestar nada alrededor | Modo de copia, marca de control o CDC, destino, frecuencia, reanudación y columnas de auditoría |
| Data Pipeline | El proceso necesita dependencias, condiciones, varias actividades, notebooks, funciones, alertas o pasos entre sistemas | Orden, parámetros, identidad, reintentos, notificaciones, SLA y responsable de cada fallo |
| Dataflow Gen2 | El equipo necesita preparar y transformar datos tabulares con Power Query en bajo código, como describe la documentación de Dataflow Gen2 | Consultas reutilizables, destino, esquema de salida, historial de actualizaciones y reglas de calidad |
La regla de decisión es sencilla de enunciar y difícil de respetar: no se elige Pipeline por costumbre ni Mirroring por novedad. Se selecciona el mecanismo más simple que cumple latencia, seguridad, trazabilidad y operación.
Cómo se aplica esto a un ERP y un CRM reales
Cada sistema pide un tratamiento distinto, y esa es la parte que un enfoque genérico ignora.
- CRM en la nube (por ejemplo con datos ya en un lago externo): muchas veces basta un OneLake Shortcut. El dato se queda donde vive, Fabric lo referencia y evitas una copia que habría que sincronizar. Define bien qué pasa si esa fuente externa deja de responder.
- ERP sobre una base operacional compatible: si necesitas ver la operación casi en tiempo real, Mirroring replica esas tablas hacia OneLake con baja latencia y sin que tengas que construir un ETL propio. Acota qué tablas entran, no toda la base.
- ERP o CRM del que solo necesitas cargas periódicas: un Copy Job con modo incremental o CDC trae los cambios sin sobrecargar la fuente ni recopiar todo cada noche. Agrega columnas de auditoría para saber qué se cargó y cuándo.
- Cuando la carga cruza sistemas y tiene condiciones: un Data Pipeline orquesta el orden, los reintentos y las notificaciones. Aquí cada actividad conserva un propósito claro y cada fallo tiene un responsable.
- Cuando los datos llegan sucios y hay que emparejarlos: un Dataflow Gen2 con Power Query limpia, estandariza y prepara antes de que el modelo los consuma.
Si el flujo combina varias de estas piezas, el Pipeline actúa como orquestador y cada actividad conserva su propósito. No es raro que un ERP entre por Mirroring, un CRM por Shortcut y una tabla de referencia por Copy Job: tres mecanismos, un solo destino.
Traer los datos no es lo mismo que unificarlos
Aquí está el matiz que separa un proyecto que funciona de uno que solo mueve archivos. Que el ERP y el CRM aterricen en OneLake resuelve la logística, no el significado. Todavía hay que responder: ¿qué es un cliente cuando el ERP lo identifica por RUC y el CRM por correo? ¿Qué venta cuenta, la de la orden o la de la factura?
Ese acuerdo sobre lo que significa cada métrica es el modelo semántico. Es donde defines, una sola vez, qué significa cada número para que Excel, Power BI y cualquier IA respondan igual. Sin ese modelo, tienes dos sistemas en la misma carpeta, no una única verdad. En sectores con requisitos estrictos, como al aplicar la consolidación de fuentes de datos en finanzas y banca, ese acuerdo sobre las definiciones pesa todavía más. Y conviene recordarlo: una IA que consulta datos mal definidos repite esas inconsistencias con más velocidad y más confianza.
Por eso el orden importa. Primero se ordenan las métricas y las decisiones; después se eligen los mecanismos de entrada. Traer datos con Mirroring o Copy Job es la parte mecánica; acordar qué significan es la parte que sostiene las decisiones.
Una arquitectura por capas para no ensuciar la verdad
Un patrón probado para organizar todo esto es la arquitectura medallion, en tres capas:
- Bronze: el dato tal como llega del ERP y del CRM, crudo, sin tocar. Es tu registro fiel del origen.
- Silver: el dato limpio, emparejado y estandarizado. Aquí el cliente del ERP y el del CRM se reconcilian en una sola entidad.
- Gold: el dato listo para decidir, ya modelado con las métricas del negocio que consume dirección.
Los mecanismos de entrada alimentan Bronze. Dataflow Gen2 y las transformaciones construyen Silver. El modelo semántico vive sobre Gold. Separar así evita que una corrección de última hora contamine el dato original y hace que el sistema sea auditable.
Errores frecuentes al conectar ERP y CRM
- Copiar todo por defecto cuando un shortcut habría bastado, y terminar manteniendo réplicas que envejecen.
- Elegir Pipeline para una carga simple, sumando complejidad que nadie va a operar.
- Traer los datos y saltarse el modelo semántico, con lo que cada informe vuelve a inventar sus propias definiciones.
- No definir qué pasa cuando una fuente externa deja de responder, y descubrirlo el día que el tablero aparece vacío.
- Mezclar dato crudo y dato corregido en la misma capa, perdiendo la trazabilidad.
Por dónde empezar
Conectar el ERP y el CRM en un solo lugar es, antes que una tarea técnica, una decisión de arquitectura: qué mecanismo por fuente, qué significa cada métrica y qué capa sostiene la verdad. Puedes recorrer ese camino con formación para tu equipo o con consultoría sobre tus propias fuentes; en ambos casos conviene arrancar igual: ver cómo se resuelve con datos reales. Si quieres verlo aplicado, mira la demo gratuita.
Regla que resume todo: no se elige la herramienta por costumbre ni por novedad. Se elige el mecanismo más simple que cumple latencia, seguridad, trazabilidad y operación, y recién después se acuerda qué significa cada número.
Preguntas relacionadas
¿Necesito copiar mi ERP y mi CRM a una base de datos nueva para unificarlos?
No siempre. En Microsoft Fabric el punto de encuentro es OneLake, y por cada fuente eliges cómo entra: un OneLake Shortcut referencia el dato sin copiarlo, mientras que Mirroring o Copy Job lo replican cuando de verdad hace falta una copia.
¿Cuál es la diferencia entre Mirroring y Copy Job para traer datos?
Con Mirroring, una base operacional soportada queda replicada en OneLake casi al instante y sin que nadie arme un ETL a medida. Copy Job mueve datos por copia completa, incremental o CDC cuando solo necesitas la copia y no un flujo complejo con dependencias.
¿Cuándo conviene usar un Data Pipeline en lugar de un mecanismo simple?
Cuando el proceso necesita dependencias, condiciones, varias actividades, notebooks, funciones, alertas o pasos entre sistemas. El Pipeline orquesta el orden, los reintentos y las notificaciones, y cada actividad conserva un propósito claro.
¿Con traer los datos a un solo lugar ya tengo cifras consistentes?
No. Traer los datos resuelve la logística, no el significado. Falta el modelo semántico, el acuerdo que define qué es un cliente o qué venta cuenta, para que Excel, Power BI y cualquier IA respondan lo mismo.
¿Qué es la arquitectura medallion y por qué usarla al conectar ERP y CRM?
Es organizar los datos en tres capas: Bronze (dato crudo tal como llega), Silver (limpio y emparejado) y Gold (listo para decidir). Separa el dato original del corregido, evita contaminar la verdad y hace el sistema auditable.