La respuesta breve
La Gestión de Datos Maestros (MDM, por sus siglas en inglés) no es un repositorio, es un acuerdo. Este acuerdo establece quién define la entidad, quién está autorizado a modificarla, cómo se identifican dos registros como la misma entidad y qué sucede cuando los sistemas discrepan. La tecnología solo aplica lo acordado.
El error común es empezar por la selección de una herramienta. Una organización que no ha decidido qué define a un "cliente" obtendrá una herramienta que unifica exactamente esa misma ambigüedad, pero más rápidamente y con un coste más elevado.
Qué se incluye en los Datos Maestros y qué no
| Tipo de Dato | Ejemplo | ¿Es Dato Maestro? |
|---|---|---|
| Datos Maestros | Cliente, producto, proveedor, sitio | Sí |
| Datos de Referencia | Países, monedas, códigos de industria | Gestión separada y más sencilla |
| Transaccional | Pedido, factura, caso | No |
| Analítico | Segmentación, puntuación, previsión | No - es derivado |
Esta distinción es crucial porque cada tipo requiere un gobierno diferente. Los Datos de Referencia se controlan en una tabla pequeña con un único propietario; los Transaccionales permanecen en el sistema que los creó; los Analíticos no deben convertirse en una fuente de verdad, ya que son el resultado de un cálculo variable.
Los tres estilos de implementación
Registro (Registry) - Se gestiona únicamente una tabla de identificadores que vincula registros de diferentes sistemas. Es económico, rápido, no modifica ningún sistema existente y proporciona una visión unificada para la lectura. Casi siempre es adecuado como primera fase.
Consolidación (Consolidation) - Se genera un "Golden Record" para fines de informes y análisis, sin retroalimentarlo. Es adecuado cuando el principal problema son los informes duplicados.
Centralizado (Centralized) - El Maestro se convierte en la fuente vinculante y los sistemas consumen de él. Ofrece el mayor valor, pero también la mayor exigencia en cuanto a gobierno y procesos de aprobación. Las organizaciones que directamente saltan a esta fase descubren que no tienen Stewards para operarlo.
El enfoque práctico es una escalera: un Registro para una entidad, y luego la expansión —según el valor demostrado y no según un plan maestro.
Survivorship: las reglas que determinan qué prevalece
El núcleo del "Golden Record" son las reglas de Survivorship a nivel de campo: para cada campo, existe una fuente preferida y una regla de respaldo cuando la fuente preferida está vacía. Junto a esto, siempre se mantienen los identificadores de los sistemas de origen, para poder explicar cada valor.
Un principio que evita discusiones: el "Golden Record" no elimina los registros de origen ni pretende reemplazarlos. Es una capa que los referencia. Esto significa que se puede corregir una regla y recalcular, una capacidad que no tienen quienes lo fusionaron todo en la fase de carga.
Una mayor profundización en la determinación de la propiedad se encuentra en Fuente de Verdad en la Organización, y en la deduplicación que la precede en Deduplicación de Datos en Salesforce.
Stewardship: el rol que determina el éxito
Todo régimen de MDM genera una cola de decisiones: coincidencias sobre las que el sistema no está seguro, solicitudes para crear una nueva entidad y conflictos entre fuentes. Si no hay una persona con tiempo asignado para gestionar la cola, esta crece hasta que deja de ser revisada.
Un alcance realista: en una organización mediana, esto implica unas pocas horas a la semana para una sola entidad, generalmente por parte de alguien del ámbito empresarial y no de TI. Esta es la inversión que determina si el MDM vive o se convierte en una infraestructura silenciosa.
Escenario: un fabricante con tres sistemas y un cliente
Un fabricante industrial gestionaba clientes en tres lugares: ERP, Salesforce y un sistema de servicio. Una misma corporación aparecía como tres entidades diferentes, y un informe de "ingresos por cliente" se construía manualmente en Excel cada trimestre.
En lugar de un proyecto MDM completo, la organización comenzó con un Registro: se construyó una tabla de identificadores en Data 360 que vinculaba los tres registros mediante la identificación fiscal y una clave secundaria, y solo después se edificó un "Golden Record" para la lectura. Salesforce no cambió su estructura; recibió un campo de identificador global y una vista de "toda la actividad del grupo".
El resultado después de un trimestre: el informe manual fue eliminado, y los comerciales vieron por primera vez la exposición crediticia a nivel de grupo, lo que impulsó una decisión de precios que recuperó el coste de esa fase. La expansión a un sistema Centralizado se consideró solo después de que se demostró que había un Steward que gestionaba activamente la cola.
Riesgos comunes y acciones de prevención
| Riesgo | Cómo se manifiesta en la práctica | Acción de prevención |
|---|---|---|
| Empezar por la herramienta | Un repositorio unificado que refleja la ambigüedad existente | Definiciones de entidad y propiedad antes de elegir la herramienta |
| Demasiadas entidades | Un proyecto largo sin valor visible | Una entidad hasta la producción, y luego la expansión |
| Ausencia de Steward | Una cola de conciliaciones que crece y es abandonada | Un rol con tiempo asignado y SLA |
| Fusión destructiva | Imposibilidad de explicar o recuperar un valor | Guardar identificadores de origen y recalcular |
| Centralizado prematuramente | Todos los sistemas dependen de una infraestructura inmadura | Comenzar con un Registro (Registry) |
Cómo medir el éxito
| Área | Qué se mide | Frecuencia de revisión |
|---|---|---|
| Cobertura | Porcentaje de registros vinculados a un identificador global | Mensual |
| Precisión | Tasa de vínculos cancelados o corregidos | Mensual |
| Cola de Stewardship | Elementos abiertos y tiempo medio de cierre | Semanal |
| Valor de negocio | Informes manuales eliminados, decisiones a nivel de grupo | Trimestral |
La construcción de un régimen de MDM gradual se realiza en el marco de Servicios de Integraciones y Datos.
Lista de verificación antes de iniciar MDM
- ☐ Se han seleccionado hasta tres entidades para la primera fase.
- ☐ Para cada entidad, existe una definición de negocio escrita.
- ☐ Se ha elegido el estilo de implementación: Registro, Consolidación o Centralizado.
- ☐ Se han identificado claves de identificación robustas para cada fuente.
- ☐ Se han redactado las reglas de Survivorship a nivel de campo.
- ☐ Los identificadores de origen se conservan y permiten el recálculo.
- ☐ Se ha nombrado un Steward con tiempo asignado y un SLA.
- ☐ Se ha definido un proceso de aprobación para la creación de nuevas entidades.
- ☐ Se ha establecido una métrica de valor para la primera fase.
- ☐ Existe una decisión sobre cuándo considerar una herramienta dedicada.
Recursos profesionales
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data