Datos y Analítica
¿Qué sistema debe ser la fuente de verdad de los datos?
Respuesta directa
No hay un sistema único: cada tipo de dato tiene su propio sistema con autoridad para crearlo y modificarlo, y todos los demás sistemas solo lo consumen. El cliente puede vivir en el CRM o en un CDP según la arquitectura, la factura en el ERP o contabilidad, el pedido en el sistema de comercio o el ERP, y la campaña en la plataforma de marketing. La pregunta correcta no es 'cuál sistema manda en todo', sino 'quién tiene autoridad sobre cada entidad de dato'.
Cuando dos sistemas muestran cifras distintas del mismo cliente, la reacción habitual es preguntar 'cuál es el correcto', como si existiera un único repositorio destinado por naturaleza a ser la verdad. Esa forma de plantear el problema confunde tres conceptos que, aunque relacionados, no son intercambiables: system of record, source of truth y master data. Un system of record es el sistema donde una transacción o entidad se crea originalmente; una source of truth es la referencia que se declara autorizada para un dato específico, que puede o no coincidir con el system of record; y master data es el conjunto de atributos centrales de una entidad (cliente, producto, proveedor) que debe mantenerse consistente entre sistemas mediante gobierno, no necesariamente residiendo en un solo lugar físico. Tratarlos como sinónimos lleva a decisiones de arquitectura equivocadas, como asumir que el CRM debe ser automáticamente la fuente maestra de todo lo relacionado con el cliente, cuando en muchas arquitecturas esa autoridad corresponde a un CDP, al ERP o incluso a un data warehouse que resuelve conflictos entre ambos. Este artículo explica cómo declarar autoridad de datos entidad por entidad, con un criterio de decisión de negocio y no una preferencia tecnológica.
System of record, source of truth y master data: tres conceptos distintos
El system of record es una noción operativa: identifica dónde nace un dato y dónde se registra su transacción original. Un pedido nace en el sistema de comercio o en el ERP; una factura nace en contabilidad; un ticket de soporte nace en la plataforma de servicio. El system of record no siempre es el sistema más visible ni el más usado por el equipo comercial, y confundirlo con la 'fuente de verdad' ignora que un dato puede nacer en un sistema y ser gobernado, enriquecido o corregido en otro.
La source of truth es una decisión declarada, no un hecho técnico automático: es el sistema o vista que la organización designa como referencia autorizada para un dato concreto, en caso de conflicto entre registros. Master data, por su parte, es el conjunto de atributos centrales y compartidos de una entidad —nombre legal, identificación fiscal, dirección de entrega de un cliente— que idealmente se gestiona con reglas de gobierno (Master Data Management) para que todos los sistemas trabajen con la misma versión, sin importar dónde se originó cada atributo. Un cliente puede tener su system of record en el CRM para datos comerciales y su master data gobernado desde un hub de MDM que sincroniza ERP, CRM y CDP.
- Master Data Management (MDM)
- Disciplina y conjunto de procesos que garantizan que los atributos centrales de una entidad (cliente, producto, proveedor) sean consistentes, únicos y gobernados entre los sistemas que los usan, sin importar en cuál se originaron.
Relacionado: ¿Qué sistemas necesita realmente una empresa?
La pregunta fundamental: ¿quién tiene autoridad sobre cada dato?
En lugar de preguntar 'qué sistema es la fuente de verdad', la pregunta operativa es 'quién tiene autoridad para crear, modificar y corregir este dato específico, y quién solo puede leerlo'. Esta autoridad se declara por entidad de dato, no por sistema completo: un mismo CRM puede tener autoridad sobre el estado de una oportunidad comercial y, al mismo tiempo, no tener ninguna autoridad sobre el estado de una factura, que corresponde al ERP o al sistema contable.
Esta autoridad varía según la arquitectura de cada empresa y no según una regla universal. En un ecosistema con CDP maduro, la identidad unificada del cliente —su perfil resuelto, sus consentimientos y su segmentación— puede tener autoridad en el CDP, mientras el CRM sigue teniendo autoridad sobre el ciclo de venta. En un ecosistema sin CDP, el CRM puede asumir esa autoridad de identidad por defecto, no porque sea la mejor práctica universal, sino porque es el único sistema disponible para esa función. Declarar autoridad exige, entonces, mirar la arquitectura real antes de aplicar una plantilla genérica.
Relacionado: ¿Cómo saber cuál debe ser el sistema principal de una empresa?
Si necesitas indicadores confiables para dirigir el negocio, conoce nuestro servicio de medición y analítica de negocio.
Autoridad por entidad de dato: ejemplos y reglas de escritura
La tabla siguiente ilustra cómo se distribuye la autoridad entre entidades típicas de un ecosistema digital, distinguiendo el sistema con autoridad para escribir del conjunto de sistemas que solo consumen esa información. La columna 'regla de escritura' expresa el principio operativo que evita conflictos: solo el sistema con autoridad puede crear o corregir el dato; los demás lo replican mediante integración, nunca lo editan directamente.
Esta distribución no es fija para siempre: cambia cuando la empresa incorpora un nuevo sistema (por ejemplo, un CDP o un data warehouse que centraliza la resolución de identidad) o cuando madura su gobierno de datos. Lo importante es que el cambio de autoridad sea una decisión explícita y documentada, no una consecuencia accidental de qué sistema resultó más fácil de integrar.
| Entidad de dato | Sistema con autoridad | Sistemas que solo consumen | Regla de escritura |
|---|---|---|---|
| Identidad de cliente | CRM o CDP, según exista resolución de identidad centralizada | ERP, plataforma de marketing, data warehouse | Solo el sistema designado crea o fusiona perfiles; los demás reciben el ID vía integración |
| Factura | ERP o sistema contable | CRM, dashboards de finanzas, portal de cliente | Ningún otro sistema genera ni modifica el estado contable de una factura |
| Pedido | Plataforma de comercio o ERP, según dónde se origina la transacción | CRM, logística, atención al cliente | El estado del pedido se actualiza solo en el sistema de origen y se propaga por evento |
| Campaña de marketing | Plataforma de marketing o herramienta de analítica | CRM, data warehouse, reportes ejecutivos | Las métricas de campaña se leen desde la plataforma de origen, nunca se recalculan manualmente aguas abajo |
| Ticket de soporte | Plataforma de servicio al cliente | CRM, CDP, panel de retención | El historial de resolución solo se edita en la plataforma de servicio |
Relacionado: ¿Cuál es la diferencia entre CRM, ERP, CDP y data warehouse?
Cuándo conviene un hub de datos y cuándo basta con reglas claras
En empresas con pocos sistemas y volumen moderado, declarar autoridad por entidad y aplicar integraciones punto a punto suele ser suficiente: no hace falta un data warehouse ni un hub de MDM para tener consistencia si la cantidad de sistemas es baja y los conflictos de datos son poco frecuentes. Forzar un hub centralizado en esta etapa añade costo y complejidad de mantenimiento sin un beneficio proporcional.
La necesidad de un hub de datos —un data warehouse que resuelve identidad, o una capa de MDM dedicada— aparece cuando el número de sistemas con autoridad parcial crece y las integraciones punto a punto se vuelven difíciles de mantener, cuando distintas áreas reportan cifras distintas del mismo indicador de negocio, o cuando el volumen de conflictos de datos supera lo que un equipo puede resolver manualmente. En ese punto, centralizar la resolución de identidad y de conflictos en una capa dedicada reduce el riesgo de que cada integración nueva se convierta en una fuente adicional de inconsistencia.
Relacionado: ¿Cómo detectar datos inconsistentes entre CRM, ERP y otras plataformas?
Checklist para declarar autoridad de datos
Declarar autoridad de datos es un ejercicio de gobierno, no un proyecto técnico aislado: requiere acuerdo entre las áreas dueñas de cada sistema y documentación accesible para todo el equipo que integra o consulta esos datos. El siguiente checklist resume los pasos mínimos para hacerlo de forma sostenible.
Pasos para declarar autoridad de datos por entidad
- Listar las entidades de dato críticas del negocio (cliente, pedido, factura, campaña, ticket) antes de discutir sistemas
- Para cada entidad, identificar el system of record real: dónde nace la transacción, no dónde se visualiza más
- Declarar explícitamente qué sistema tiene autoridad de escritura y documentarlo en un lugar accesible al equipo técnico y de negocio
- Definir la regla de propagación: cómo y con qué frecuencia el dato autorizado llega a los sistemas que solo lo consumen
- Revisar la autoridad declarada cada vez que se incorpora un nuevo sistema al ecosistema
- No asumir que el CRM u otro sistema es la fuente maestra de todo por defecto: verificar entidad por entidad
De la autoridad de datos a la inteligencia conectada
Declarar autoridad de datos no es un fin en sí mismo: es la base que permite que un ECOSISTEMA DIGITAL funcione con información confiable en cada capa, desde la captura de un lead hasta la facturación y el servicio postventa. Sin esta claridad, cualquier iniciativa de automatización o de IA hereda las inconsistencias de origen, porque un flujo automatizado o un modelo de decisión inteligente no pueden corregir un dato mal gobernado, solo pueden propagarlo más rápido.
En la metodología Connected Intelligence™ de Inovática Digital, este ejercicio de gobierno es un prerrequisito antes de conectar capacidades de automatización e inteligencia artificial: primero se acuerda quién tiene autoridad sobre cada dato, luego se integra y solo después se automatiza. Ese orden evita que la velocidad operativa que da la automatización amplifique errores que nacieron en una decisión de gobierno nunca tomada de forma explícita.
Preguntas frecuentes
- ¿System of record y fuente de verdad son lo mismo?
- No. El system of record es donde nace la transacción original; la source of truth es la referencia que la organización declara autorizada en caso de conflicto, y puede residir en un sistema distinto al de origen.
- ¿El CRM siempre debe ser la fuente maestra del cliente?
- No necesariamente. En arquitecturas con CDP, la identidad unificada del cliente puede tener autoridad en el CDP mientras el CRM conserva autoridad solo sobre el ciclo comercial. La autoridad depende de la arquitectura, no de una regla fija.
- ¿Qué es master data y en qué se diferencia de un dato transaccional?
- Master data son los atributos centrales y relativamente estables de una entidad, como el nombre legal o la dirección de un cliente. El dato transaccional registra un evento puntual, como una compra o un ticket, y cambia con cada interacción.
- ¿Es obligatorio tener un hub de MDM para gobernar los datos?
- No. Con pocos sistemas y bajo volumen de conflictos, declarar autoridad por entidad y usar integraciones punto a punto puede ser suficiente. Un hub de MDM se justifica cuando crecen los sistemas con autoridad parcial o los conflictos entre reportes.
- ¿Qué pasa si dos sistemas modifican el mismo dato sin regla de autoridad?
- Se generan inconsistencias que se acumulan silenciosamente hasta que un reporte crítico las expone, típicamente en cifras de facturación o segmentación de clientes. Declarar autoridad previene ese costo evitando ediciones simultáneas sobre el mismo dato.