7.9 Gestión de datos maestros y de referencia

Presentación y motivación

Pregunta a cinco sistemas cuántos clientes tiene la organización, y obtienes cinco números distintos. Uno cuenta direcciones de correo, uno cuenta contratos, uno cuenta inicios de sesión, y dos discrepan sobre si «Acme Corp» y «ACME Corporation» son la misma empresa. La gestión de datos maestros (MDM) es la disciplina de reconciliar las entidades centrales que tu negocio comparte, cliente, producto, proveedor, empleado, ubicación, en una única versión autorizada en la que cada sistema puede confiar.

Empieza clasificando tus datos en tres tipos, porque necesitan un trato distinto. Los datos maestros describen los sustantivos de tu negocio: las personas, lugares, y cosas a las que muchos procesos se refieren. Los datos de referencia son el vocabulario controlado que esos procesos usan: códigos de moneda, códigos de país, listas de unidades de medida, categorías de producto. Los datos transaccionales registran los verbos: un pedido realizado, un pago hecho, un envío enviado. Los datos maestros y de referencia tienen menor volumen que las transacciones pero se referencian en todas partes, así que un error en ellos contamina todo lo posterior.

El costo de equivocarse en esto es concreto. Cuando el mismo cliente existe como cuatro registros ligeramente distintos, envías cuatro catálogos por correo, no puedes ver una relación que vale la pena conservar, y tu número de ingresos por cliente está silenciosamente equivocado. Un registro dorado, la única versión confiable de una entidad ensamblada a partir de muchas fuentes, es lo que reemplaza esas copias en conflicto, para que cada integración deje de resolver de nuevo el mismo problema de emparejamiento.

Para las empresas que reconcilian sistemas acumulados a través de décadas de crecimiento y adquisición, la MDM es la diferencia entre una vista coherente del cliente y un impuesto de reconciliación permanente. Para el gobierno, las apuestas suben: un ciudadano que aparece como tres personas distintas en tres agencias puede ser negado un beneficio, gravado dos veces, o perdido entre departamentos. Este capítulo complementa la estrategia y gobernanza de datos (capítulo 7.1), que fija la propiedad y la política; el modelado de datos y la capa semántica (capítulo 7.7), que define qué significan las entidades; y la calidad y observabilidad de datos (capítulo 7.8), que mantiene los registros limpios con el tiempo.

Principios fundamentales

Clasifica tus datos en maestros, de referencia, y transaccionales; cada uno necesita un manejo distinto.
Un registro dorado por entidad del mundo real, ensamblado deliberadamente, no descubierto por accidente.
Elige un estilo de arquitectura de MDM que se ajuste a tus necesidades de control y latencia, no a la moda.
El emparejamiento y la supervivencia son reglas de negocio, así que escríbelas y deja que los administradores las ajusten.
Los datos de referencia son vocabulario compartido; versiónalos y publícalos como una API.
La gobernanza y la administración son el motor de la MDM; el software es solo la herramienta.
Propaga los registros dorados como eventos para que los sistemas posteriores se mantengan sincronizados, no obsoletos.
Mide la MDM por decisiones mejoradas y duplicados eliminados, no por registros cargados.

Recomendaciones

Clasifica primero los datos maestros, de referencia, y transaccionales

No puedes gestionar lo que no has clasificado, así que empieza clasificando tus dominios de datos. Una prueba útil para los datos maestros es si un valor equivocado se propaga: si una dirección mala se propaga hacia la facturación, el envío, y los avisos legales, estás mirando datos maestros. Esto impulsa tu inversión: construyes un motor de emparejamiento para la entidad cliente, no para las líneas de artículo de pedido. Nombra los dominios explícitamente, clasifícalos por cuánto dolor causa su duplicación, y empieza con el uno o dos que más duelen, usualmente cliente y producto porque tocan los ingresos directamente.

Elige un estilo de arquitectura de MDM deliberadamente

Hay cuatro estilos de arquitectura comunes, y el correcto depende de cuánta autoridad puedes centralizar y con qué rapidez deben propagarse los cambios. El estilo de registro deja los datos en los sistemas fuente y construye solo un índice de identificadores emparejados, así que puede responder «estos cinco registros son el mismo cliente» sin mover ningún dato; es barato y de bajo riesgo, pero de solo lectura, así que no puede arreglar las fuentes. El estilo de consolidación extrae copias hacia un centro central y las fusiona en registros dorados para el reporte, pero no empuja las correcciones de vuelta, así que las fuentes se mantienen desordenadas. El estilo de coexistencia va más allá: sincroniza los valores limpiados de vuelta a los sistemas fuente, así que las fuentes mejoran con el tiempo mientras siguen operando independientemente. El estilo de centro centralizado o transaccional hace que el centro de MDM sea el sistema de registro en sí, donde las entidades se crean y editan directamente y cada otro sistema consume de él; esto da la consistencia y el control más fuertes, y es el más difícil de adoptar porque cambia dónde ocurre el trabajo. Muchas organizaciones progresan de un registro que prueba el valor hacia la coexistencia a medida que crece la confianza, y ejecutan más de un estilo a través de distintos dominios.

Empareja, fusiona, y fija reglas de supervivencia explícitamente

El corazón de la MDM es decidir cuándo dos registros describen la misma cosa del mundo real. Esto es la vinculación de registros, rara vez tan simple como una coincidencia exacta de clave porque los datos reales están llenos de errores tipográficos, abreviaturas, y campos faltantes. El emparejamiento determinista usa reglas exactas sobre campos elegidos (mismo ID fiscal, o mismo correo más código postal). El emparejamiento probabilístico puntúa la similitud a través de muchos campos usando coincidencia aproximada de cadenas y pesos, así que «Bob Smith, 12 Main St» y «Robert Smith, 12 Main Street» pueden juzgarse como un emparejamiento probable por encima de un umbral. Decidir qué registros se refieren a la misma entidad se llama resolución de identidad, y impulsa todo, desde las vistas de cliente hasta la detección de fraude.

Una vez que los registros coinciden, debes decidir qué valores sobreviven al registro dorado. Estas reglas de supervivencia son lógica de negocio, así que hazlas explícitas: prefiere el valor más reciente para un número de teléfono, el valor más completo para una dirección, la fuente más confiable para un nombre legal. Fija una banda de umbral donde los emparejamientos se fusionan automáticamente, una banda inferior donde se rechazan automáticamente, y una banda intermedia donde decide un humano, que es donde vive la administración. Mantén cada fusión reversible y registrada, porque una fusión equivocada que une a dos clientes reales es peor que una que se pierde.

Trata los datos de referencia como vocabulario compartido y versionado

Los datos de referencia son el vocabulario compartido que hablan tus sistemas, y el vocabulario que deriva causa desalineación silenciosa: cuando un sistema usa el código de país ISO «GB» y otro usa «UK», las uniones fallan y los conteos divergen. Mantén cada lista de referencia en un único lugar gobernado, publícala para cada consumidor, y, crucialmente, versiónala. Los códigos se añaden, retiran, dividen, y fusionan con el tiempo, y si sobrescribes la lista en su lugar, rompes los informes históricos que eran correctos bajo los códigos antiguos.

Trata un conjunto de datos de referencia como una API con un contrato. Publícalo con fechas de vigencia para que un consumidor pueda preguntar «¿cuáles eran los códigos de región válidos en esta fecha?», mantén los códigos retirados en lugar de borrarlos, y registra el mapeo cuando un código cambia de significado. Prefiere los estándares externos reconocidos donde existan, como los códigos ISO de país y moneda, porque los estándares te dan interoperabilidad gratis y se conectan con la disciplina de estándares abiertos del capítulo 3.8.

Modela jerarquías y relaciones, no solo registros planos

Los datos maestros no son un montón de filas independientes; son una red de relaciones. Un cliente pertenece a un hogar y a una empresa matriz. Un producto se agrupa en una categoría y una marca. Estas jerarquías llevan un significado de negocio real: agrupar las ventas por empresa matriz y la imagen cambia por completo respecto a agruparlas por cuenta individual. Modela estas relaciones explícitamente para que los consumidores las recorran de manera consistente en lugar de que cada equipo invente su propia agrupación.

Vigila el caso donde una entidad necesita varias jerarquías a la vez. Un producto puede agruparse de una manera para finanzas y de otra para mercadeo, y ambas son legítimas, así que soporta múltiples jerarquías nombradas en lugar de forzar un único árbol verdadero. Las relaciones entre dominios también importan, como qué proveedor suministra qué producto.

Conecta los registros dorados a la capa semántica y la calidad de datos

Los registros dorados que produce la MDM son las entidades confiables a las que hace referencia la capa semántica del capítulo 7.7 cuando define métricas: «clientes activos» solo significa algo cuando «cliente» no es ambiguo. Alimenta tus registros dorados a la capa semántica para que cada métrica cuente las mismas entidades deduplicadas y resueltas.

La MDM y la calidad de datos (capítulo 7.8) son dos caras de una moneda: las comprobaciones de calidad detectan los duplicados, nulos, y violaciones de formato que la MDM luego resuelve, y el emparejamiento de la MDM expone problemas de calidad que las comprobaciones pasaron por alto. Ejecuta monitoreo continuo de calidad en tus datos maestros específicamente: tasas de duplicados, distribuciones de confianza de emparejamiento, completitud de campos clave, y el tamaño de la cola de revisión, para que la deriva aparezca antes de que la vean los consumidores.

Propaga los registros dorados a través de eventos

Un registro dorado que ningún sistema posterior ve no ayuda a nadie. El patrón más fuerte es la propagación impulsada por eventos: cuando una entidad se crea, fusiona, o corrige, el centro de MDM publica un evento de cambio, y los sistemas suscritos actualizan su copia local. Esto se construye sobre la arquitectura impulsada por eventos y los patrones de flujo del capítulo 7.2, manteniendo docenas de sistemas consistentes sin sincronizaciones por lotes nocturnas frágiles que dejan a todos con un día de retraso.

Publica los eventos con suficiente contexto para ser útiles: el identificador de la entidad, qué cambió, los nuevos valores sobrevivientes, y una versión para que los consumidores puedan ordenar las actualizaciones y detectar las que se perdieron. Haz que los consumidores sean idempotentes para que reproducir un evento no haga daño, y ofrece una API para los sistemas que no pueden suscribirse. El principio de la arquitectura de datos y almacenamiento (capítulo 3.4) se aplica: diseña para que el registro dorado fluya, porque uno que nadie consume es solo una hoja de cálculo costosa.

Asigna la administración y gobernanza antes que las herramientas

La MDM fracasa como proyecto tecnológico y tiene éxito como uno de gobernanza. El rol crítico es el administrador de datos, una persona responsable de la calidad y las reglas de un dominio específico, que resuelve emparejamientos ambiguos, ajusta las reglas de supervivencia, y arbitra cuando dos departamentos discrepan sobre qué significa «proveedor». Los administradores usualmente son gente de negocio con conocimiento profundo del dominio, no ingenieros, y necesitan autoridad real y tiempo asignado, porque la administración a tiempo parcial sin mandato produce exactamente la deriva que la MDM se suponía que debía detener.

Envuelve a los administradores en las estructuras de gobernanza del capítulo 7.1: un dueño de datos responsable de cada dominio, un consejo para resolver disputas entre dominios, y políticas claras sobre quién puede crear o fusionar registros maestros. Documenta las decisiones, porque las reglas para emparejar a un cliente son conocimiento institucional que debe sobrevivir la rotación de personal. Las herramientas sirven a la gobernanza; comprar una plataforma de MDM antes de nombrar a tus administradores es comprar un motor sin conductor.

Ventajas y desventajas

Estilo de MDM	Ventajas	Desventajas
Registro (solo índice)	Barato, bajo riesgo, fuentes intactas	Solo lectura; no puede arreglar los datos fuente
Consolidación (copias centrales)	Registros limpios para analítica rápidamente	Las fuentes se mantienen desordenadas; sin escritura de vuelta
Coexistencia (sincronización de vuelta a las fuentes)	Las fuentes mejoran; control equilibrado	Más integración; conflictos de sincronización que gestionar
Centro centralizado / transaccional	Consistencia y control más fuertes	Costo más alto; cambia dónde ocurre el trabajo
Emparejamiento determinista	Predecible, explicable, auditable	Se pierde errores tipográficos, variantes, y datos desordenados
Emparejamiento probabilístico	Atrapa la variación del mundo real	Necesita ajuste; fusiones falsas si se es descuidado

La tensión central en la MDM es control frente a disrupción. Los estilos que te dan los datos más limpios y consistentes (coexistencia y centros centralizados) son exactamente los que más se entrometen en cómo trabajan los sistemas fuente y sus dueños, y esa intromisión es donde se estancan los programas de MDM. El camino pragmático es ganar confianza con un estilo de bajo riesgo y moverse hacia un control más fuerte solo donde el caso de negocio es claro. La contrapartida de emparejamiento corre en paralelo: las reglas deterministas son auditables pero frágiles, la puntuación probabilística es poderosa pero exige administración y una tolerancia para la fusión equivocada ocasional. La mayoría de los programas maduros mezclan ambos.

Preguntas para discutir con tu equipo

¿Qué dominios de datos maestros realmente nos causan dolor, y los hemos clasificado por costo en lugar de tratarlos todos a la vez? Muchos programas de MDM colapsan bajo su propia ambición, intentando dominar cada entidad de la empresa a la vez y no entregando nada durante dos años. El movimiento productivo es encontrar el uno o dos dominios donde la duplicación y el conflicto te cuestan dinero o confianza reales, usualmente cliente o producto, y cuantificar ese costo: los envíos de correo desperdiciados, las horas de reconciliación, los números de ingresos equivocados, los hallazgos de auditoría. Trae ejemplos concretos de la misma entidad apareciendo de múltiples formas a través de tus sistemas, y deja que esa clasificación te diga por dónde empezar, porque una victoria estrecha y medible construye la credibilidad que necesitas para expandirte.
¿Quién es dueño de cada dominio de datos maestros, y nuestros administradores tienen la autoridad y el tiempo para realmente hacer el trabajo? Las herramientas de MDM sin administración empoderada son un auto sin conductor, y el modo de fallo más común es nombrar a un administrador en una diapositiva mientras no se le da mandato real ni horas asignadas. Las personas que resuelven emparejamientos ambiguos y resuelven disputas sobre «qué cuenta como cliente» necesitan experiencia de dominio, autoridad de decisión, y tiempo protegido. Trae tu organigrama y pregunta, para tu dominio principal, exactamente quién decide cuándo dos registros son la misma persona y quién arbitra cuando ventas y finanzas discrepan. Si no puedes nombrar a esa persona y señalar su tiempo asignado, has encontrado la brecha que hundirá el programa.
Cuando fusionamos dos registros en un registro dorado, ¿podemos explicar y revertir la decisión, y de dónde vienen los valores sobrevivientes? Las reglas de supervivencia son lógica de negocio que la mayoría de los equipos nunca ha escrito, lo cual significa que las fusiones ocurren por accidente del orden de carga o los valores predeterminados de la herramienta, y una fusión equivocada que une a dos clientes reales es dolorosa de deshacer. Trae un registro fusionado real y rastrea cada campo sobreviviente hasta su fuente y regla: por qué esta dirección, por qué este nombre, por qué este número de teléfono. Confirma que cada fusión se registra y es reversible, y que una banda intermedia de emparejamientos inciertos va a un humano en lugar de fusionarse automáticamente. Si no puedes explicar un registro dorado específico, tus administradores no pueden defenderlo ante un auditor o un cliente agraviado.
¿Qué estilo de arquitectura de MDM se ajusta a cada dominio que planeamos dominar, y podemos defender esa elección contra la disrupción que impone a los dueños de los sistemas fuente? El estilo que eliges decide cuánto puedes limpiar los datos y cuánto te entrometes en los equipos que son dueños de las fuentes, y elegir por moda o discurso de proveedor en lugar de por la realidad de control frente a disrupción es cómo los programas se estancan a mitad de camino. Un registro prueba el valor barato pero nunca arregla una fuente; un centro centralizado da la consistencia más fuerte pero reubica dónde se crean los registros, lo cual es un cambio organizacional disfrazado de uno técnico. Trae, para cada dominio candidato, una lectura honesta de cuánta autoridad realmente tienes sobre los dueños de las fuentes, cuán fresca debe ser la copia posterior, y qué rompería una escritura de vuelta en los flujos de trabajo existentes. En entornos empresariales y gubernamentales, añade el costo de migración y gestión del cambio de mover el sistema de registro, porque los equipos cuyo trabajo diario se mueve resistirán un centro sobre el que no fueron consultados, y un despliegue de coexistencia estancado es más costoso que un registro modesto que se entrega.
¿Cómo ajustamos los umbrales de emparejamiento, y hemos acordado qué tasa de fusiones falsas y emparejamientos perdidos podemos tolerar en cada dominio? Cada motor de emparejamiento probabilístico intercambia fusiones falsas (fusionar dos entidades reales) contra emparejamientos perdidos (dejar una entidad dividida), y el equilibrio es una decisión de negocio, no un valor predeterminado que alguien dejó en la herramienta. Fija las bandas de fusión automática y rechazo automático demasiado anchas y corrompes registros dorados silenciosamente; fíjalas demasiado estrechas y la cola de revisión humana crece más rápido de lo que los administradores pueden despejarla. Trae la distribución de confianza actual, el tamaño y la antigüedad de la cola de revisión, y errores de muestra de ambos tipos para que la sala pueda ver el costo real de cada dirección. En un dominio de identidad gubernamental, inclínate fuertemente hacia los emparejamientos perdidos y la revisión humana, porque una fusión equivocada puede negar un beneficio o exponer los datos de un ciudadano a otro, y el costo de apelación y auditoría de ese error empequeñece el costo de un duplicado que un administrador resuelve la próxima semana.
¿Cómo se enteran los sistemas posteriores de que un registro dorado cambió, y cuán obsoleto puede estar cada uno antes de que una decisión salga mal? Un registro dorado perfectamente resuelto que ningún sistema consume es una hoja de cálculo costosa, y el mecanismo de propagación, ya sean eventos de cambio, una API de suscripción, o un lote nocturno, fija silenciosamente cuán actual es cada decisión dependiente. La propagación impulsada por eventos mantiene a docenas de consumidores casi en tiempo real pero exige consumidores idempotentes y eventos versionados; una sincronización nocturna es más simple pero deja a todos con un día de retraso, lo cual puede estar bien para una lista de marketing y ser peligroso para una comprobación de fraude. Trae la lista de sistemas consumidores, la frescura que cada uno realmente necesita, y cómo se recupera un consumidor que se pierde una actualización hoy. Para una organización grande o pública, nombra quién es dueño del contrato de estos eventos y cómo un suscriptor detecta un mensaje perdido, porque un cambio de entidad que silenciosamente no llega a una agencia recrea la misma fragmentación que la MDM fue financiada para eliminar.

Perspectiva sectorial

Startup. Con un puñado de ingenieros y sin fondos de sobra, no compres una plataforma de MDM. Domina la única entidad que está corrompiendo tus números, usualmente el cliente duplicado entre el autoservicio y las ventas, con un trabajo de emparejamiento en el almacén que ya operas y una persona revisando semanalmente los emparejamientos inciertos. Mantén cada fusión registrada y reversible para que una mala regla cueste una tarde, no una relación con el cliente, y reconsidera herramientas más pesadas solo cuando la cola de revisión manual supere a un único revisor.

Pequeña empresa. No tienes un administrador de datos y tienes un presupuesto ajustado, así que trata esto como una decisión de comprar en lugar de construir y apóyate en los estándares que obtienes gratis. Prefiere herramientas que ya deduplican contactos y hablan los códigos ISO de país y moneda en lugar de un centro a medida que no puedes mantener, y elige el único dominio, típicamente clientes o productos, donde los duplicados te cuestan dinero real. Asigna la responsabilidad a un dueño nombrado incluso si es una fracción de la semana de una persona, porque el vocabulario que deriva sin que nadie lo vigile es lo que silenciosamente rompe tus informes.

Empresa. A través de una docena de sistemas ERP y CRM acumulados por adquisición, el trabajo es gobernanza de cartera: clasifica los dominios por el costo de su duplicación, levanta administradores empoderados en el negocio, y estandariza las reglas de supervivencia y el versionado de datos de referencia para que los grupos dejen de resolver de nuevo el mismo problema de emparejamiento. Presupuesta explícitamente el costo de integración y administración permanente, propaga los registros dorados como eventos versionados para que las fuentes mejoren con el tiempo, y gestiona la MDM como un programa medido con tasas de duplicados y métricas de cola de revisión en lugar de una limpieza única.

Gobierno. Las reglas de contratación pública, la ley estricta de intercambio de datos, y la rendición de cuentas pública moldean cada elección. Fija la clave de la entidad persona en un identificador nacional gobernado, versiona los datos de referencia por fecha de vigencia para que los registros históricos se mantengan correctos, y haz que la resolución de identidad sea deliberadamente conservadora: los emparejamientos inciertos van a administradores capacitados, nunca a fusiones automatizadas, porque una fusión equivocada puede negar un beneficio o filtrar los datos de un ciudadano a otro. Registra cada emparejamiento para la auditoría y la apelación, exige portabilidad de datos y lógica de emparejamiento divulgada de los proveedores, y mantén toda la capacidad dentro de los estándares de interoperabilidad a los que ya se compromete el sector público.

Ejemplos

Startup. Una empresa de software de rápido crecimiento vende tanto por registro de autoservicio como por un equipo de ventas, y los dos canales crean al mismo cliente dos veces bajo nombres de empresa ligeramente distintos. Los ingresos por cuenta se ven mal y el equipo de ventas sigue llamando en frío a usuarios existentes. En lugar de comprar una plataforma pesada, empiezan con un registro ligero: un trabajo de emparejamiento en su almacén de datos que vincula registros por dominio de correo y nombre de empresa normalizado, con un administrador a tiempo parcial revisando semanalmente los emparejamientos inciertos. Cuesta poco, arregla el error de reporte, y prueba el valor que justifica más inversión a medida que crecen.

Empresa. Un fabricante global ha crecido por adquisición y opera una docena de sistemas ERP y CRM, cada uno con sus propios registros de proveedores, así que el mismo proveedor aparece de quince maneras y la empresa no puede negociar como un único comprador ni ver su gasto real. Levanta un centro de MDM de estilo coexistencia para los dominios de proveedor y producto, usando emparejamiento determinista en identificadores fiscales y de registro más puntuación probabilística en nombres y direcciones. Administradores nombrados en adquisiciones ajustan las reglas de supervivencia y trabajan la cola de revisión, y los registros dorados se publican como eventos de cambio que fluyen de vuelta a cada ERP para que los datos limpiados mejoren las fuentes. La visibilidad consolidada del gasto desbloquea mejores términos contractuales, y el impuesto de reconciliación que consumía a finanzas cada trimestre cae drásticamente.

Gobierno. Un gobierno nacional quiere que las agencias traten a un ciudadano como una sola persona en lugar de un extraño en cada mostrador, mientras respetan límites legales estrictos sobre el intercambio de datos. Construye un centro de datos maestros centralizado para la entidad persona, con clave en un identificador nacional gobernado, con datos de referencia versionados por fecha de vigencia para que los registros históricos se mantengan correctos. La resolución de identidad es deliberadamente conservadora: los emparejamientos inciertos van a administradores capacitados en lugar de fusiones automatizadas, porque una fusión equivocada podría negarle a alguien un beneficio o exponer sus datos, y cada emparejamiento se registra para la auditoría y la apelación. El beneficio son menos registros duplicados, menos fraude por identidades divididas, y un ciudadano que no tiene que probar quién es en cada puerta, dentro de los estándares de interoperabilidad del capítulo 3.8.

Caso de negocio: motivaciones, ROI y TCO

El retorno de la MDM viene de eliminar un impuesto que la mayoría de las organizaciones pagan sin nombrarlo. Los registros duplicados y en conflicto cuestan dinero de maneras obvias (marketing desperdiciado a la misma persona cinco veces, errores de envío por direcciones obsoletas, descuentos por volumen perdidos) y de maneras menos obvias (analistas reconciliando conteos, ejecutivos decidiendo sobre números que están silenciosamente equivocados, auditores facturando horas para desenredar qué registro es real). Una vista consolidada de proveedores frecuentemente paga por todo el programa solo a través de mejores términos contractuales.

El costo total de propiedad tiene tres partes: la plataforma o construcción, la integración a fuentes y consumidores, y, la más grande con el tiempo, la administración continua. El costo de integración es fácil de subestimar, porque conectar una docena de sistemas fuente envejecidos es donde los programas de MDM sangran cronograma y presupuesto, y el costo de administración es fácil de olvidar, porque es un gasto operacional permanente, no una construcción única. Para presentar el caso al liderazgo, vincula la MDM a números que ya rastrean: exactitud de ingresos, eficiencia de marketing, ahorros de adquisiciones, costo de auditoría, y riesgo regulatorio, luego empieza estrecho y deja que una victoria medida en un dominio de alto dolor financie la expansión.

Antipatrones y trampas

Alcance de hervir el océano: dominar cada dominio a la vez, no entregando nada durante años, y perdiendo el patrocinio antes de la primera victoria.
Herramientas antes que gobernanza: comprar una plataforma de MDM antes de nombrar administradores y dueños, así el motor no tiene conductor.
Administradores a tiempo parcial sin autoridad: asignar la administración en una diapositiva sin dar mandato real ni tiempo protegido.
Supervivencia silenciosa: fusionar registros por valor predeterminado de la herramienta u orden de carga, sin reglas escritas ni forma de explicar un registro dorado.
Fusiones irreversibles: fusionar automáticamente emparejamientos inciertos sin deshacer, así una fusión equivocada de dos entidades reales se convierte en daño permanente.
Datos de referencia sobrescritos en su lugar: editar listas de códigos sin versionado, rompiendo cada informe histórico que era correcto bajo los códigos antiguos.
Registros dorados que nadie consume: construir un centro impecable al que ningún sistema posterior se suscribe, así los datos limpios nunca llegan a las decisiones.
Reinventar códigos estándar: acuñar tus propias listas de país o moneda cuando existen estándares ISO, y perder interoperabilidad sin razón.

Modelo de madurez

Nivel 1, Iniciar: Los datos maestros y de referencia no se gestionan. La misma entidad existe muchas veces sin versión autoritativa, las listas de códigos divergen, el emparejamiento es manual y reactivo, y nadie es dueño del problema, así que los conteos de entidades centrales discrepan y nadie puede decir cuál es correcto.
Nivel 2, Desarrollar: Los dominios clave se reconocen y alguien los deduplica, a menudo en el almacén para el reporte. Existe emparejamiento determinista básico, las listas de referencia se recopilan, y unas pocas personas actúan como administradores informales, pero la práctica varía equipo por equipo, las fuentes se mantienen desordenadas, y las reglas viven en la cabeza de la gente en lugar de en papel.
Nivel 3, Estandarizar: La MDM es un programa gobernado aplicado de manera consistente en toda la organización. Los dominios maestros tienen dueños nombrados y administradores empoderados, las reglas de emparejamiento y supervivencia están documentadas y se aplican, los registros dorados se producen y propagan a los consumidores, y los datos de referencia se versionan y publican con fechas de vigencia como una API.
Nivel 4, Gestionar: El programa se mide y controla contra líneas base. Las tasas de duplicados, las distribuciones de confianza de emparejamiento, las tasas de fusión falsa y emparejamiento perdido, la completitud de campos clave, y el tamaño y antigüedad de la cola de revisión se rastrean como métricas; los umbrales se ajustan contra esos números en lugar de por intuición; y el valor de la MDM (exactitud de ingresos, ahorros de adquisiciones, costo de revisión) se cuantifica y reporta a los dueños en una cadencia fija.
Nivel 5, Orquestar: Los registros dorados fluyen como eventos versionados casi en tiempo real, alimentan la capa semántica, y son confiables en toda la organización. El emparejamiento se mejora continuamente contra resultados medidos, el dominio se extiende a nuevos dominios como una capacidad repetible, y la MDM está integrada con la planificación de gobernanza y riesgo para que el programa se adapte a medida que cambian las fuentes, los estándares, y el panorama de entidades.

Ideas para el debate

Si dos de tus sistemas discrepan sobre cuántos clientes tienes, ¿cuál es correcto, y cómo lo probarías?
¿Qué dominio de datos maestros entregaría la mayor victoria medible si lo dominaras primero, y cuánto vale esa victoria?
¿Dónde te ayudaría hoy el emparejamiento probabilístico, y estás cómodo con la fusión equivocada ocasional que implica?
¿Cómo versionas tus datos de referencia, y qué se rompe en tus informes históricos cuando un código cambia de significado?
¿Quién es el administrador nombrado para tu entidad más importante, y tiene la autoridad y el tiempo para realmente hacer el trabajo?
Cuando un registro dorado cambia, ¿cómo se enteran tus sistemas posteriores, y cuán obsoletos pueden estar antes de que duela?

Puntos clave

Clasifica tus datos en maestros, de referencia, y transaccionales; invierte en emparejamiento y gobernanza donde la duplicación cueste más.
Produce un registro dorado por entidad del mundo real, ensamblado mediante reglas de supervivencia explícitas, reversibles, y registradas.
Elige un estilo de arquitectura de MDM (registro, consolidación, coexistencia, o centro centralizado) que se ajuste a tu apetito por el control y la disrupción.
Trata los datos de referencia como vocabulario compartido y versionado, prefiere los estándares reconocidos, y nunca sobrescribas las listas de códigos en su lugar.
La MDM tiene éxito por la gobernanza y la administración, no por las herramientas; propaga los registros dorados como eventos y mide el programa por las decisiones mejoradas.

Referencias y lecturas adicionales

David Loshin, Master Data Management
Alex Berson y Larry Dubov, Master Data Management and Data Governance
Dan Power, The Definitive Guide to Master Data Management
John Talburt, Entity Resolution and Information Quality
Peter Christen, Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection
Ivan P. Fellegi y Alan B. Sunter, «A Theory for Record Linkage», Journal of the American Statistical Association
DAMA International, DAMA-DMBOK: Data Management Body of Knowledge
Ralph Kimball y Margy Ross, The Data Warehouse Toolkit