Al integrar ERP, CRM y un data lake, ¿cómo defino de forma

Respuesta

Define la autoridad del dato por dominio y por caso de uso, no por el nombre del sistema. En la práctica, el ERP suele mandar en lo financiero y operativo, el CRM en la relación comercial y el data lake en el consumo analítico, pero con excepciones por atributo. La clave es documentar, a nivel de atributo, quién crea, quién valida y quién puede corregir cada dato, y luego alinear la integración para que respete ese camino de escritura.

Principio práctico: manda por dominio y por caso de uso, no por sistema

El error de arranque más frecuente es intentar declarar un ganador único, tipo el ERP manda de todo o el CRM manda de clientes, y luego descubrir que cada área tiene una definición distinta de cliente, producto o estado de pedido. La forma que sí funciona es separar dominios de datos y casos de uso. Un mismo objeto de negocio puede tener atributos con autoridades distintas según el riesgo y el momento del proceso.

Piensa en tres etiquetas simples. Sistema de registro, donde se crea y se mantiene operativamente. Sistema de autoridad, el que se considera verdad para un atributo específico. Sistema de experiencia, donde la gente lo usa y lo enriquece para operar. Si no haces esta distinción, terminas con “doble escritura” y el dato se convierte en un volante con tres personas girándolo a la vez, que siempre acaba en la banqueta.

Marco de decisión en 6 criterios para asignar el sistema que manda

Usa estos seis criterios como checklist ejecutivo. La idea no es discutir arquitectura, sino proteger el negocio de inconsistencias previsibles.

Origen del proceso. ¿Dónde nace el dato porque ahí ocurre el trabajo real? Si el dato se genera como parte del ciclo comercial, es más probable que nazca en CRM. Si nace al ejecutar la entrega y la facturación, tiende al ERP.
Responsabilidad legal y financiera. Cuando hay implicación fiscal, contable o de auditoría, la autoridad normalmente debe estar en el ERP o en el sistema que soporta controles equivalentes. Es la diferencia entre “me lo dijo ventas” y “me lo firmó contabilidad”.
Frecuencia de cambio y latencia aceptable. Algunos atributos toleran sincronización diaria, otros requieren minutos. Si el negocio necesita ver el estado casi en tiempo real para prometer fechas o para cobrar, define la autoridad donde se actualiza primero y replica a los demás con un SLA explícito.
Necesidad de validación y controles. ¿Dónde existen reglas obligatorias, catálogos cerrados, aprobaciones o trazabilidad de cambios? El sistema con mejores guardas suele ser el mejor candidato a mandar, porque evita propagar errores.
Impacto operativo si hay inconsistencia. Si un error para el atributo detiene operaciones, genera notas de crédito o rompe inventario, la autoridad debe estar en el sistema más cercano a la ejecución operativa y con mejor disciplina de cambios.
Cobertura y calidad actual. A veces el criterio decisivo es simple: el sistema que realmente tiene el dato más completo y confiable hoy. Eso no significa que se quede así para siempre, pero evita intentar “arreglar el mundo” antes de poder cerrar el mes.

Tip práctico 1: decide autoridad por atributo, no por entidad. No digas “cliente manda en CRM”, di “nombre comercial y contacto mandan en CRM; razón social y régimen fiscal mandan en ERP”. Esta precisión reduce discusiones y acelera integraciones.

Tip práctico 2: define el camino de corrección. Si el dato está mal en un reporte, ¿quién lo corrige y en qué pantalla? Si tu respuesta es “depende” o “en el Excel”, todavía no hay autoridad real.

Asignación típica por dominios (cliente, producto, precio, pedido) más variaciones comunes

Cliente

En B2B, suele funcionar así: el CRM manda en datos de relación y engagement, como contactos, teléfonos, correos, preferencias, potencial, etapas de oportunidad y actividades. El ERP manda en datos de identidad fiscal y de crédito, como razón social legal, dirección fiscal, condiciones de pago, límite de crédito, estatus de cobranza y los identificadores necesarios para facturar.

Variación común: si tienes un proceso fuerte de alta de clientes con validación fiscal y antifraude fuera del ERP, ese sistema o un hub de datos puede ser la autoridad de identidad, mientras CRM conserva el enriquecimiento comercial.

Producto

En empresas industriales y retail, el ERP suele mandar en el maestro transaccional, como SKU, unidad de medida, impuestos, costo estándar, reglas de inventario y disponibilidad. El CRM o un PIM suele mandar en atributos de marketing, como descripciones comerciales, fotos, bundles, categorías orientadas a canal y material de ventas.

Variación común: en ecommerce maduro, el PIM o la plataforma digital puede ser la autoridad de contenido, mientras ERP se queda con el núcleo transaccional. En suscripciones, “producto” se parece más a “plan”, y puede vivir en un sistema de billing.

Precio

El ERP suele mandar en listas base, reglas contables y condiciones de facturación. El CRM suele proponer precios en cotización, descuentos por oportunidad y excepciones comerciales, pero idealmente no debe ser la última palabra si el precio afecta margen y control.

Variaciones comunes: con CPQ, motor de pricing o revenue management, ese motor puede ser autoridad de reglas y cálculo, mientras ERP registra lo final facturable. El truco es distinguir precio calculado, precio aprobado y precio facturado.

Pedido y estado de pedido

Aquí está la guerra cultural clásica. Ventas quiere que el CRM muestre estados para el cliente y finanzas quiere que ERP defina la verdad. La salida práctica es separar estados por intención.

El CRM manda en el estado comercial, como propuesta enviada, negociación, ganado, perdido, y en el compromiso hacia el cliente, como fecha prometida comunicada. El ERP manda en el estado operativo y financiero, como liberación de pedido, surtido, embarcado, entregado, facturado, pagado, cancelado, y en sus subestados de crédito y logística.

Variación común: si el fulfillment ocurre en un WMS o TMS, ese sistema puede mandar en estados logísticos, y el ERP se vuelve agregador financiero. Lo importante es que alguien mande en cada tramo y que el CRM consuma ese estado sin reinterpretarlo.

Gobernanza mínima viable: quién decide, quién aprueba y quién opera

No necesitas un comité pesado, necesitas roles claros y un ritmo constante.

Data Owner, del negocio, decide definiciones y prioridades. Por ejemplo, finanzas para datos fiscales y pricing base, operaciones para estados logísticos, comercial para atributos de relación.

Data Steward, operación de datos, asegura calidad, gestiona duplicados, define reglas de limpieza y coordina correcciones. Es el rol que evita que el dato se muera de vergüenza en un tablero.

System Owner, normalmente TI o producto digital, opera la plataforma, gestiona cambios y disponibilidad.

Architecture Owner, suele ser arquitectura empresarial o data lead, asegura que las decisiones no se contradigan entre dominios y que los patrones de integración se mantengan coherentes.

Una práctica ligera que funciona es un foro mensual de 45 minutos por dominio crítico. Se revisan incidentes, cambios de reglas y nuevos atributos. Y un mecanismo de aprobación asíncrona para cambios menores, con un registro simple.

Artefactos obligatorios para que no quede en teoría

Si no queda escrito y versionado, no existe. Mantén estos artefactos pequeños, pero obligatorios.

Data Domain Map. Un mapa de dominios y entidades, con qué equipos los usan y qué sistemas participan.
Business Glossary y diccionario de datos. Definiciones en lenguaje de negocio, más campos, formatos y ejemplos. Si hay dos definiciones de “cliente activo”, decláralo y nómbralas distinto.
Matriz de autoridad por entidad y atributo. Para cliente, producto, precio, pedido, define sistema de registro y sistema de autoridad, además de quién puede editar y quién solo consume.
Contratos de datos. Qué se publica, con qué estructura, con qué frecuencia, con qué claves, con qué reglas mínimas de calidad y qué pasa si falla.
Reglas de matching y supervivencia. Cómo identificas duplicados y qué atributo sobrevive cuando hay conflicto. Incluso si no tienes MDM formal, necesitas reglas.
Lineage y catálogo. Aunque sea sencillo, debes poder responder de dónde salió un número y quién lo tocó.
Plan de reconciliación. Reportes regulares que comparan ERP vs CRM vs lake para detectar diferencias y tratarlas como incidencias, no como “cosas de datos”.

A continuación verás una tabla de controles operativos que conviene configurar desde el inicio para que la integración no dependa de héroes.

Set: Establecer la Frecuencia de Sincronización Set: Manejo de Excepciones y Errores Set: Definir el Sistema de Registro (SoR) Set: Validación de Datos en el Punto de Entrada Set: Definir el Sistema de Autoridad (SoA)

Reglas de resolución de conflictos y golden record sin fricción

Golden record no significa que todo viva en un solo lugar. Significa que, para un consumo específico, existe una versión consolidada y trazable con reglas claras. Puedes tener un golden record operativo, típico de MDM, y un golden record analítico en el lakehouse para reportes y segmentación, siempre que no intentes escribir de vuelta sin un proceso.

Define reglas de conflicto por atributo. Prioridad por sistema para campos específicos, por ejemplo dirección fiscal desde ERP y correo desde CRM. Regla por timestamp solo si confías en relojes y procesos, porque “el último que guardó” suele ser el último que rompió algo. Regla por canal también funciona, por ejemplo web manda para preferencias, call center manda para teléfono.

Gestiona duplicados con tres acciones permitidas: merge, split y quarantine. Merge cuando dos registros son lo mismo. Split cuando uno era mezcla de dos. Quarantine cuando no hay certeza y se bloquea su propagación a procesos críticos.

Error común: sincronización bidireccional sin reglas de supervivencia. Eso crea bucles, sobrescritura silenciosa y discusiones infinitas. En su lugar, define un solo camino de escritura para cada atributo y permite retroalimentación solo como solicitud, no como actualización automática.

Patrones de integración y su impacto en la autoridad del dato

El patrón de integración decide quién puede escribir qué, y por lo tanto decide la autoridad en la práctica.

Punto a punto puede funcionar al inicio, pero escala mal y suele terminar en un “nadie sabe por qué cambió ese campo”. Si lo usas, limítalo a dos o tres flujos críticos y con contrato claro.

Hub and spoke con un bus o una plataforma de integración ayuda a centralizar validaciones, trazas y manejo de errores. Aquí es más fácil imponer políticas de autoridad por atributo.

APIs van bien para consultas y para escrituras controladas. Eventos sirven para propagar cambios y sostener consistencia eventual sin frenar operación.

Batch y ETL son útiles para analítica y para dominios con baja urgencia. CDC, captura de cambios, reduce latencia y evita cargas completas, pero exige más disciplina de monitoreo.

Una regla de oro simple: si un sistema no es autoridad para un atributo, no debería aceptar actualizaciones directas de ese atributo, salvo vía un flujo de corrección gobernado.

Rol del data lake o lakehouse: consumo, estandarización y observabilidad

El data lake no debería ser el lugar donde “manda” el dato operativo. Su fortaleza es otra: consolidar, estandarizar y observar. En una arquitectura sana, el lakehouse es donde certificas métricas, comparas fuentes y detectas anomalías.

Trabaja por capas. Una capa de aterrizaje conserva lo que llega. Una capa estandarizada limpia formatos, claves y tipos. Una capa de consumo publica data products, como cliente 360 analítico, ventas netas certificadas o cumplimiento de promesa de entrega.

Aquí el lakehouse sí puede tener un golden record analítico, útil para segmentación, BI y modelos. Pero el límite es claro: no se convierte en el lugar donde un usuario “arregla” una razón social. Si detectas un error en el lake, el flujo correcto es abrir un caso al steward y corregir en el sistema autoridad, con trazabilidad.

Cómo implementarlo en 30 60 90 días sin megaproyecto

Días 0 a 30

Elige dos dominios con dolor real, normalmente cliente y pedido, o producto y precio si hay problemas de margen. Haz inventario de atributos críticos y decide autoridad por atributo con los seis criterios. Define SLAs de sincronización y un tablero mínimo de calidad. Cierra con un documento de una página por dominio: qué manda dónde, quién aprueba cambios, y cómo se corrige.

Días 31 a 60

Implementa contratos de datos para los flujos priorizados. Agrega validaciones en el punto de entrada del sistema autoridad, para que no entren valores imposibles. Monta monitoreo de integración con alertas de fallas y cuarentena de registros con error. Publica en el lake una vista estandarizada para consumo ejecutivo y reconciliación.

Días 61 a 90

Extiende a un tercer dominio y formaliza reglas de supervivencia y deduplicación. Establece cadencia mensual de revisión de incidencias y cambios. Documenta lineage para los indicadores críticos y certifica dos o tres métricas. Si el volumen de conflictos lo justifica, evalúa un MDM ligero o un data hub para maestro de cliente o producto.

Un criterio de éxito al día 90 es que, ante una discrepancia, el equipo sepa responder en menos de una hora: cuál es la fuente autoridad, cuál fue el último cambio y cuál es el procedimiento de corrección.

KPIs y controles para demostrar confianza operativa

Mide lo que reduce fricción y riesgo, no solo lo que suena bien.

Primero, cobertura de gobernanza. Porcentaje de atributos críticos con owner definido y sistema de autoridad asignado. Si no pasa de 80 por ciento, seguirás discutiendo casos sueltos.

Segundo, calidad y duplicados. Tasa de duplicados en cliente, match rate en procesos de deduplicación, completitud de campos obligatorios, y validez de formatos. No necesitas cien reglas, necesitas las diez que rompen operaciones.

Tercero, sincronización y confiabilidad. Latencia real contra el SLA, número de fallas de integración, reintentos, y volumen en cuarentena. Si la latencia se vuelve variable, la gente deja de confiar y regresa al “pregúntale a Juan”.

Cuarto, reconciliación cruzada. Diferencias de pedidos entre CRM y ERP por estado y por importe, diferencias de precios facturados vs cotizados, y ajustes manuales. Estas métricas conectan directo con dinero.

Quinto, adopción. Cuántos equipos usan las definiciones del glosario, cuántas consultas van a datasets certificados, y cuántas incidencias se cierran corrigiendo en el sistema autoridad, no parcheando reportes.

Si tuviera que priorizar una sola cosa para empezar mañana, sería esto: decide autoridad por atributo para cliente y pedido, define el camino de corrección, y pon un SLA de sincronización con monitoreo. Es lo mínimo para que ERP, CRM y lake trabajen como una orquesta y no como tres bandas tocando canciones distintas en el mismo escenario.

Control	Dónde vive	Qué configurar	Qué se rompe si está mal
Set: Establecer la Frecuencia de Sincronización	Acuerdos de Nivel de Servicio (SLA) de Integración	Definir la latencia aceptable para la propagación de datos entre sistemas — ej. tiempo real, diario, semanal.	Información desactualizada, procesos de negocio lentos, oportunidades perdidas.
Set: Manejo de Excepciones y Errores	Plataforma de Integración (iPaaS/ESB)	Definir flujos para reintentos, notificaciones y cuarentena de datos con errores.	Pérdida de datos, interrupciones operativas, necesidad de intervención manual constante.
Set: Definir el Sistema de Registro (SoR)	Documento de Arquitectura de Datos	Para cada entidad — ej. Cliente, Producto, identificar el sistema primario que la crea y mantiene.	Datos inconsistentes, duplicados, decisiones de negocio erróneas.
Set: Validación de Datos en el Punto de Entrada	Reglas de Negocio en el sistema de origen	Implementar validaciones estrictas en el sistema SoR para asegurar la calidad antes de la integración.	Propagación de datos erróneos, fallos en procesos downstream, baja confianza en los datos.
Set: Definir el Sistema de Autoridad (SoA)	Matriz de Gobernanza de Datos	Para cada atributo — ej. Nombre de Cliente, Precio, identificar el sistema que tiene la versión 'verdadera'.	Conflictos de datos, reportes financieros incorrectos, problemas de cumplimiento.
Set: Auditoría y Trazabilidad de Datos	Logs de Integración, Data Lake	Registrar quién, cuándo y cómo se modificó un dato en cada sistema.	Imposibilidad de depurar problemas, falta de cumplimiento regulatorio, baja confianza en la auditoría.

Fuentes

Última actualización: 2026-06-02 | Calypso

Al integrar ERP, CRM y un data lake, ¿cómo defino de forma práctica qué sistema manda para cada dato (cliente, producto, precio, estado de pedido)?

Respuesta

Fuentes

Etiquetas