Gobernanza de datos maestros (MDG): de la política al proceso que la aplica
En resumen
La gobernanza de datos maestros es el conjunto de reglas, roles y decisiones que rigen cómo se crean, mantienen y retiran las entidades centrales de una empresa: clientes, proveedores, productos, materiales.
No es lo mismo que el MDM. El MDM es la implementación técnica; la gobernanza es quién decide qué, bajo qué criterio y con qué autoridad.
Y casi ningún programa falla por falta de políticas. Falla porque las políticas viven en un documento y el dato se crea en otro sistema, donde nadie abre ese documento.
Qué es la gobernanza de datos maestros
La gobernanza de datos maestros es el conjunto de políticas, roles y procesos de decisión con los que una organización define cómo deben crearse, mantenerse y retirarse sus datos maestros, y quién responde por cada uno de esos momentos.
Vale la pena ser preciso sobre qué decide y qué no. Decide cuál es la definición válida de cliente, qué atributos son obligatorios para dar de alta un material, quién aprueba un cambio en la jerarquía de productos y bajo qué condiciones se retira un registro. No decide cómo se almacena, cómo se replica ni con qué herramienta se consolida: eso es implementación.
Gobernanza de datos, MDM y gobernanza de datos maestros
Los tres términos se usan como sinónimos y no lo son. La confusión importa porque lleva a comprar una herramienta cuando el problema era de decisión, o a montar un comité cuando el problema era técnico.
Alcance | Qué resuelve | |
|---|---|---|
Gobierno de datos | Todos los datos de la organización | Políticas, roles y estándares generales: privacidad, acceso, calidad, cumplimiento |
Gobernanza de datos maestros | Solo las entidades maestras | Quién define, quién aprueba y bajo qué criterio se crea o cambia un registro maestro |
MDM | Solo las entidades maestras | La implementación: modelo, consolidación, golden record, distribución a sistemas |
La relación es de encaje, no de jerarquía. El gobierno de datos es el marco general y lo explicamos a fondo en nuestro artículo sobre qué es el data governance y cómo implementarlo. La gobernanza de datos maestros es ese marco aplicado a un dominio concreto. Y el MDM con sus modelos de implementación es la maquinaria que hace cumplir lo que la gobernanza decidió.
Dicho corto: la gobernanza decide, el MDM ejecuta.
Los componentes y quién responde por cada uno
Hay cuatro componentes en cualquier programa, y lo útil no es listarlos sino aclarar quién decide qué dentro de cada uno.
Componente | Quién responde | Qué decide | Qué no puede decidir |
|---|---|---|---|
Marco y órganos de decisión | Comité de datos | Prioridades y resolución de conflictos entre dominios | El detalle operativo de cada dominio |
Propiedad y stewardship | Data owner y data steward | El owner, qué significa el dato para el negocio. El steward, que esa definición se cumpla día a día | Cambiar la definición por su cuenta |
Normas y definiciones | Owner, con validación del comité | Atributos obligatorios, nomenclatura, reglas de validación, jerarquías | Excepciones sin registro |
Cumplimiento y seguridad | Compliance y el custodio técnico | Controles de acceso, retención, trazabilidad | El criterio de negocio sobre el dato |
Esa última columna es la que casi nadie escribe y es donde se resuelve el malentendido más común: el steward no es dueño del dato. Es responsable de que la definición acordada se cumpla. Cuando se le trata como dueño, termina tomando decisiones de negocio que no le corresponden; cuando se le trata como capturista, el rol se vuelve administrativo y el programa pierde su única figura operativa.
Dónde se rompe la gobernanza de datos maestros
Los programas no fracasan en el diseño. Casi siempre hay un documento de políticas bien hecho, un comité constituido y stewards nombrados. Se rompen en tres puntos concretos.
La política vive separada del proceso que crea el dato. El documento dice que todo proveedor nuevo debe tener verificación fiscal vigente y aprobación de compliance. El formulario donde alguien da de alta a ese proveedor no sabe nada de eso. Nadie abre el documento a las diez de la mañana de un martes para capturar un registro, así que la política es una recomendación con la que el sistema no está de acuerdo ni en desacuerdo: simplemente la ignora.
El steward revisa después. Su trabajo está diseñado como auditoría posterior: entra al sistema, revisa los registros creados, encuentra los que no cumplen y abre una corrección. El problema es el momento. Para cuando detecta el error, el registro ya está en el ERP, ya se le emitió una orden de compra y ya se registró un pago. Corregirlo ahora significa tocar transacciones, no solo un campo.
Las políticas también caducan, y eso nadie lo revisa. Los programas revisan datos contra reglas. Casi ninguno revisa si las reglas siguen vigentes. Una norma aprobada hace dos años puede haber quedado atrás respecto a un cambio regulatorio, a una fusión o a un sistema nuevo, y seguir aplicándose con toda disciplina. El resultado es un programa que cumple rigurosamente un criterio que ya no corresponde.
De la política al control ejecutable
La diferencia entre una política y un control no es de rigor. Es de momento.
Una política escrita se verifica después de que el dato existe. Un control se ejecuta antes de que exista. La primera produce una lista de hallazgos; el segundo produce la ausencia del problema.
Política escrita | Control ejecutable |
|---|---|
Todo proveedor debe tener verificación contra listas de restricción | La consulta corre dentro del flujo y si el resultado es positivo el registro no avanza |
Los datos bancarios deben corresponder al país del proveedor | El formulario solo muestra los bancos del país seleccionado |
Compliance debe aprobar las altas de proveedores críticos | El registro no se escribe en el ERP hasta que compliance aprueba, y queda su nombre y la fecha |
Las certificaciones deben estar vigentes | El vencimiento dispara una revalidación y, si no se actualiza, una suspensión |
Mira la cuarta fila, porque resume el punto. En su versión escrita, alguien tiene que acordarse de revisar vencimientos. En su versión ejecutable, el vencimiento es el que avisa.
Esto no elimina la política. La política sigue siendo necesaria: define qué se verifica y por qué, y es lo que se presenta en una auditoría. Lo que cambia es que deja de ser el mecanismo de cumplimiento y pasa a ser la especificación de un control que corre solo.
Caso de éxito: stewardship ejecutándose
Un líder global en alimentos gestionaba el alta de proveedores por correo, papel y fotocopias. Existían criterios y existían responsables, pero el cumplimiento dependía de que cada persona recordara aplicarlos. Un proveedor en listas negras podía entrar sin pasar por ninguna evaluación, y no quedaba registro de quién había verificado qué.
Arkon Data llevó el proceso completo a su plataforma. Las verificaciones se volvieron validaciones bloqueantes, las aprobaciones quedaron repartidas entre compras, fiscal y compliance con visibilidad del estado de cada solicitud, y el registro aprobado se escribe directamente en el ambiente de Oracle Cloud del cliente.
Hoy el proceso acumula más de 18,000 ejecuciones mensuales con trazabilidad completa, operando en 7 organizaciones, 4 idiomas y 2,800 usuarios.
Lo relevante para la gobernanza no es el volumen. Es que cada una de esas ejecuciones dejó constancia de qué se verificó, cuándo y quién aprobó. Eso es lo que un programa de gobernanza necesita presentar cuando llega una auditoría, y es lo que un documento de políticas, por bien escrito que esté, no puede entregar.
Preguntas frecuentes
1. ¿Cuál es la diferencia entre gobernanza de datos y gobernanza de datos maestros?
El gobierno de datos cubre todos los datos de la organización, con políticas generales de acceso, privacidad, calidad y cumplimiento. La gobernanza de datos maestros aplica ese marco solo a las entidades centrales, como clientes, proveedores y productos, donde las reglas son más estrictas porque el dato lo consumen varios sistemas a la vez.
2. ¿Qué es un data steward de datos maestros?
Es la persona responsable de que la definición acordada de una entidad se cumpla en el día a día. No es dueño del dato ni decide qué significa; se encarga de que lo que se decidió se respete al crear y mantener registros.
3. ¿Se puede gobernar datos maestros sin una herramienta de MDM?
Sí, con políticas y revisiones manuales, pero el cumplimiento depende de la disciplina de las personas. Lo que una herramienta aporta no es la gobernanza, es la capacidad de ejecutar las reglas en el momento de la captura en lugar de verificarlas después.
4. ¿Por dónde se empieza?
Por un dominio, no por todos. Normalmente proveedores o materiales, porque son los que más áreas tocan. Y por una pregunta concreta: de las políticas que ya tienes escritas, cuántas se ejecutan solas hoy.
De la política al control
De tus políticas de datos maestros, cuántas están escritas en un documento y cuántas se ejecutan al momento de crear un registro.
Arkon Data convierte esas políticas en reglas que corren dentro del proceso: el registro que no cumple no avanza, cada aprobación queda con fecha y responsable, y el resultado es una fuente única de verdad, un golden record de tus datos maestros.
Agendemos una conversación corta para revisar cuáles de tus reglas se pueden ejecutar hoy.
