Datos y Analítica
¿Cómo detectar datos inconsistentes entre CRM, ERP y otras plataformas?
Respuesta directa
Se detecta comparando el mismo campo (nombre, email, estatus, monto, owner) entre sistemas que deberían representar la misma realidad. Si dos plataformas muestran valores distintos para el mismo cliente o pedido, hay inconsistencia. El diagnóstico exige definir qué sistema es la fuente maestra de cada campo, revisar timestamps de última actualización y auditar con consultas periódicas que crucen registros por un identificador único.
Cuando una empresa opera con varios sistemas, es normal que el mismo cliente, el mismo pedido o el mismo contrato aparezcan registrados en más de una plataforma. El problema no es que existan copias del dato, sino que esas copias dejen de coincidir con el tiempo: el nombre del contacto se actualizó en el CRM pero no en el ERP, el estatus de un pedido cambió en logística pero marketing sigue viendo el estatus anterior, o el monto de una factura difiere entre el sistema contable y el sistema comercial. Detectar estas inconsistencias no requiere adivinar; requiere comparar sistemáticamente los mismos campos entre plataformas, saber cuál sistema debería mandar sobre cada dato y revisar cuándo se actualizó por última vez cada registro. Este artículo explica cómo montar ese proceso de detección sin asumir de entrada que un sistema es siempre la fuente de verdad.
Qué es exactamente una inconsistencia de datos entre sistemas
Una inconsistencia de datos ocurre cuando un mismo campo, referido a la misma entidad (el mismo cliente, el mismo pedido, el mismo contrato), tiene valores distintos en dos o más sistemas que deberían reflejar la misma realidad. Los ejemplos más comunes son el nombre o razón social escrito de forma diferente en CRM y ERP, el correo de contacto desactualizado en un sistema pero vigente en otro, el estatus de una oportunidad marcado como 'ganada' en ventas mientras finanzas todavía la ve como 'pendiente de facturar', el monto de una cotización que no coincide con el monto final facturado, y el owner o responsable de una cuenta que cambió en un sistema sin propagarse al resto.
Estas inconsistencias no son un detalle cosmético: alimentan reportes contradictorios, generan que dos áreas discutan sobre cuál número es el correcto, y erosionan la confianza en los datos hasta el punto en que las personas dejan de consultarlos y vuelven a decidir por intuición. Por eso detectarlas de forma sistemática, y no solo cuando alguien se queja, es un paso necesario antes de automatizar cualquier proceso que dependa de esos datos.
Relacionado: ¿Cómo saber si una automatización está resolviendo el problema correcto?
System of record y master data: quién manda sobre cada campo
El 'system of record' de un campo es el sistema designado como fuente autoritativa para ese dato específico: el lugar donde, si hay una discrepancia, se asume que ese valor es el correcto hasta que se demuestre lo contrario. El error más frecuente es asumir que el CRM es siempre el system of record de todo, cuando en la práctica cada campo puede tener un dueño distinto: el ERP suele ser la fuente maestra para montos facturados, impuestos e inventario porque ahí vive la contabilidad formal; el CRM suele ser la fuente maestra para el estatus de la relación comercial y el owner de la cuenta; y una plataforma de soporte puede ser la fuente maestra del estatus de un ticket o incidencia.
El 'master data' es el conjunto de datos de referencia que identifica de forma única a una entidad —cliente, producto, empleado— y que idealmente se gestiona en un solo lugar (o se sincroniza con reglas claras) para evitar que cada sistema mantenga su propia versión sin coordinación. Definir el master data de una empresa no es un ejercicio técnico exclusivamente: requiere que las áreas de negocio se pongan de acuerdo sobre qué campo importa más para su trabajo diario y acepten que ese campo se gestione en un solo lugar.
| Campo | Sistema maestro sugerido | Regla de precedencia |
|---|---|---|
| Nombre/razón social del cliente | ERP (registro fiscal) | Gana el valor del ERP; el CRM se sincroniza contra él, salvo error fiscal comprobado. |
| Email de contacto | CRM (interacción comercial) | Gana el valor más reciente por timestamp, priorizando CRM si hay empate. |
| Estatus de la oportunidad/pedido | CRM para venta, ERP para facturación | Cada sistema manda en su etapa; se documenta el punto de traspaso entre ambos. |
| Monto final | ERP (facturación) | El monto facturado en el ERP es el definitivo; el CRM registra el monto cotizado como histórico. |
| Owner de la cuenta | CRM | El CRM es la única fuente; cualquier cambio se propaga a los demás sistemas por integración. |
Relacionado: ¿Cómo saber dónde se rompe un proceso entre departamentos?
Si necesitas indicadores confiables para dirigir el negocio, conoce nuestro servicio de medición y analítica de negocio.
Sincronización, timestamps y resolución de conflictos
Una sincronización bien diseñada no copia datos una sola vez: define con qué frecuencia se actualizan los sistemas entre sí (en tiempo real por evento, cada hora, una vez al día) y qué pasa cuando dos sistemas modifican el mismo campo casi al mismo tiempo. Ahí es donde entran los timestamps: cada registro debería guardar la fecha y hora exacta de su última modificación, para que la regla de resolución de conflictos pueda apoyarse en un criterio objetivo —por ejemplo, 'gana el cambio más reciente'— en lugar de en una suposición.
Cuando la regla de 'el más reciente gana' no es suficiente porque un cambio manual reciente puede ser un error de captura, conviene añadir una segunda capa: registrar quién hizo el cambio y desde qué sistema, para poder auditar después casos dudosos sin depender de la memoria de las personas. Esta trazabilidad es también la base para calcular con precisión cuánta información se pierde al pasar de un sistema a otro, un tipo de fuga que rara vez se mide porque no se ve hasta que dos reportes no cuadran.
El orden de las integraciones se decide con qué sistemas conviene conectar primero.
Relacionado: ¿Cómo medir el tiempo que pierde un proceso esperando entre áreas?
Cómo montar una auditoría periódica de consistencia
Una auditoría de consistencia no requiere herramientas costosas para empezar: puede ejecutarse con una consulta que cruce registros de dos sistemas por un identificador único (el ID de cliente, el número de pedido, el RFC o NIT) y compare campo por campo los valores encontrados, marcando como discrepancia cualquier diferencia que no esté explicada por una regla de negocio conocida. Lo importante es que esta comparación se ejecute con una frecuencia definida —semanal o mensual, según el volumen de cambios— y que sus resultados lleguen a una persona responsable de resolverlos, no solo a un archivo que nadie revisa.
Con el tiempo, esta auditoría también sirve para medir si el problema está mejorando o empeorando: contar cuántos registros presentan discrepancia en cada corte permite ver si las causas raíz —integraciones frágiles, capturas manuales duplicadas, falta de reglas claras— se están corrigiendo o simplemente se están parchando caso por caso.
Checklist de auditoría de consistencia entre sistemas
- ¿Existe un identificador único compartido entre los sistemas (ID de cliente, número de pedido) para cruzar registros?
- ¿Está documentado, campo por campo, cuál sistema es el maestro y cuál regla de precedencia aplica?
- ¿Cada registro guarda un timestamp de última modificación confiable en todos los sistemas involucrados?
- ¿Existe una consulta o reporte que compare los mismos campos entre sistemas con frecuencia definida?
- ¿Hay una persona o rol responsable de revisar y resolver las discrepancias detectadas?
- ¿Se lleva un conteo histórico de discrepancias para saber si la tendencia mejora o empeora?
Relacionado: ¿Cómo crear trazabilidad de principio a fin en un proceso?
Referencias sobre gestión de datos maestros
Los conceptos de system of record, master data y resolución de conflictos entre sistemas están documentados por proveedores de plataformas empresariales que gestionan integraciones a gran escala. Estas referencias son un punto de partida útil para profundizar en el tema con criterios técnicos verificables.
Fuentes primarias
Relacionado: ¿Cómo medir cuánto cuesta realmente un proceso manual?
Preguntas frecuentes
- ¿El CRM debería ser siempre el sistema maestro de todos los datos?
- No. El CRM suele ser buena fuente para el estatus comercial y el owner de la cuenta, pero el ERP normalmente manda sobre montos facturados e inventario, porque ahí vive el registro contable formal. Asignar el sistema maestro debe hacerse campo por campo, no por plataforma completa.
- ¿Qué hago si dos sistemas se actualizaron casi al mismo tiempo con valores distintos?
- Compara los timestamps exactos de ambas modificaciones y aplica la regla de precedencia definida (por ejemplo, el cambio más reciente gana). Si el caso sigue siendo dudoso, registra quién hizo cada cambio y revísalo manualmente antes de sobrescribir cualquier valor de forma automática.
- ¿Con qué frecuencia debería correr una auditoría de consistencia de datos?
- Depende del volumen de cambios: procesos con alta rotación de datos (ventas, soporte) se benefician de auditorías semanales, mientras que datos más estables (catálogo de productos, información fiscal) pueden auditarse mensualmente. Lo esencial es que la frecuencia sea fija y no dependa de que alguien note un error primero.
- ¿Puedo automatizar la sincronización sin definir antes las reglas de precedencia?
- Técnicamente sí, pero es arriesgado: sin reglas de precedencia, una automatización puede sobrescribir un dato correcto con uno desactualizado y propagar el error a más sistemas, más rápido. Definir las reglas primero evita que la automatización empeore la inconsistencia en lugar de resolverla.