Modelo operativo de gobernanza de datos: centralizado, federado o híbrido

El modelo operativo de gobernanza de datos es la forma en que la empresa organiza quién decide, quién ejecuta y quién fiscaliza las reglas de los datos maestros. No es un software. No es un cargo. Es la estructura que define si la gobernanza se vuelve rutina o se vuelve una política bonita guardada en una carpeta que nadie abre.

Implementé SAP en grandes empresas durante casi dos décadas y vi repetirse el mismo error: la empresa compra la herramienta correcta, escribe la política correcta, arma el comité correcto, y aun así los datos maestros siguen sucios seis meses después. Falta decidir quién manda sobre el dato cuando compras discrepa del área fiscal sobre cómo clasificar un material.

Existen tres modelos operativos de gobernanza de datos: centralizado, federado e híbrido. Cada uno resuelve un problema y crea otro. Voy a explicar los tres como aparecen en la vida real de una empresa, no como aparecen en la diapositiva de una consultora.

Qué es un modelo operativo de gobernanza de datos

Es el diseño que responde tres preguntas. Quién es dueño de la regla de los datos maestros. Quién aprueba un cambio en esa regla. Y quién resuelve el conflicto cuando dos áreas quieren registrar el mismo dato de formas distintas.

Sin esa respuesta, la política de gobernanza se vuelve letra muerta. Ya vi una empresa con un documento de treinta páginas sobre dimensiones de calidad, roles y responsabilidades, y ni una línea que dijera quién decide cuando el alta automática trae la situación registral equivocada de un proveedor desde la Receita Federal (la autoridad tributaria de Brasil). El modelo operativo resuelve eso un martes por la mañana, no en la reunión trimestral del comité.

Modelo centralizado: un área manda en todo

En el modelo centralizado existe un único equipo de datos maestros, normalmente dentro de TI o de gobernanza corporativa, que da de alta, aprueba y sostiene la regla para toda la empresa. Compras no da de alta proveedores. Comercial no da de alta clientes. Todo pasa por la central.

La ventaja es la consistencia: un único criterio de clasificación de material, un único estándar de nombre de proveedor, un único estándar de calidad. Funciona bien en una empresa de tamaño medio, con pocas unidades y un único ERP, porque la central acompaña el volumen sin convertirse en cuello de botella.

El problema aparece con la escala. En una compañía con varias unidades, cada una con su manera de comprar y vender, la central se convierte en una fila. La planta del interior espera tres días para dar de alta un material urgente porque el equipo central está sobrecargado con pedidos de otras cuatro unidades. El negocio siente la gobernanza como un freno, no como una protección, y aparece el atajo: el área registra por fuera, en una hoja de cálculo paralela, y la central pierde el control que tenía.

Modelo federado: cada área cuida de su dato

En el modelo federado, la gobernanza central define el estándar, la taxonomía y la regla de calidad, pero quien da de alta y mantiene el dato día a día es la propia área de negocio. Compras tiene su data steward de proveedores, comercial tiene el de clientes, ingeniería tiene el de material técnico.

La ventaja es la velocidad y el conocimiento del dominio. Quien entiende de un tornillo hexagonal de acero inoxidable clasifica mejor un ítem técnico que un analista de datos maestros genérico de la central, y el volumen se distribuye entre equipos, reduciendo la fila.

El riesgo es la fragmentación. Sin una gobernanza central lo bastante fuerte para imponer el estándar, cada área crea su propia taxonomía y la empresa vuelve a tener el mismo material registrado tres veces, cada vez con un criterio distinto. Lo vi en un proyecto de migración a S/4HANA, donde cada planta había desarrollado a lo largo de los años su propia manera de describir los materiales, y a la hora de migrar la carga de datos quedó tan lenta y llena de inconsistencias que casi comprometió el go-live. El federado solo funciona con un dueño central de la política fuerte e indicadores que muestren cuándo un área se está desviando del estándar.

Modelo híbrido: el que la mayoría de las grandes empresas termina usando

El híbrido combina los dos. Existe una gobernanza central que define taxonomía, regla de calidad, política e indicadores, y existen data stewards distribuidos en las áreas, que ejecutan el alta dentro de esa regla y responden por la calidad del dato de su dominio.

La central no da de alta, pero audita, define el flujo de aprobación e interviene cuando el indicador de calidad cae. Es el modelo que el workflow de datos maestros materializa en la práctica: la solicitud nace en el área, pasa por las reglas definidas centralmente, y solo se convierte en dato maestro aprobado después de ser validada.

El híbrido exige más madurez. Necesita una matriz de responsabilidades clara, del tipo RACI, que diga dónde termina la autonomía del área y dónde empieza la última palabra de la gobernanza central. Sin esa línea trazada, el híbrido se convierte en lo peor de los dos mundos: lento como el centralizado en las excepciones y fragmentado como el federado en el día a día.

Quién participa en este modelo

El Chief Data Officer define la política y arbitra el modelo operativo. El data owner, normalmente un gestor de negocio, responde por las decisiones sobre el dominio del dato, como proveedor o material. El data steward ejecuta, da de alta, corrige y mantiene la calidad en el día a día. El comité de datos resuelve los conflictos que el modelo operativo no resolvió por sí solo, como la divergencia entre compras y fiscal sobre la clasificación de un ítem.

TI entra como proveedora de la plataforma, pero en ninguno de los tres modelos debería ser dueña de la regla de negocio de los datos maestros. Ya vi una empresa tercerizar la decisión de clasificación de materiales al equipo de sistemas simplemente porque era quien tocaba el ERP. El resultado fue un registro técnicamente correcto y operativamente inútil.

Qué herramientas sostienen cada modelo

Las plataformas de MDM como SAP MDG, Informatica MDM, Stibo Systems, Reltio, Semarchy y Profisee automatizan el workflow de aprobación y registran quién hizo qué, independientemente del modelo elegido. Son las que vuelven operable el híbrido a escala, porque el sistema aplica el control que el proceso manual no sostiene por sí solo. Las herramientas de catálogo como Collibra, Alation y Microsoft Purview le dan a la central visibilidad sobre lo que cada área hace con el dato, incluso en el federado, y soluciones como Ataccama e Informatica Data Quality hacen el profiling que alimenta el indicador que el comité va a exigir después.

Ninguna herramienta resuelve un modelo operativo mal diseñado. Conozco una empresa que compró la plataforma más cara del mercado y mantuvo la misma indefinición de roles que tenía en la hoja de cálculo. El software automatiza la decisión, no sustituye la decisión.

Cómo aprender a diseñar este modelo

El camino pasa por entender primero los fundamentos de la gobernanza de datos y la diferencia entre dato maestro y dato transaccional, antes de entrar en la arquitectura organizacional. El DAMA-DMBOK organiza ese conocimiento, y la certificación CDMP es el reconocimiento de mercado para quien ya domina el tema. Un curso que trae casos reales de compras, de SAP, de maestro de proveedores y de materiales vale más que la teoría pura de frameworks, como abordo en el libro Master Data Management: Fundamentos e Aplicações (libro en portugués), publicado por la Editora Brasport.

Las oportunidades de carrera en esta área

Diseñar y operar un modelo de gobernanza de datos es uno de los frentes más disputados dentro del MDM, porque exige a la vez conocimiento técnico de datos y comprensión del proceso de negocio. Data steward, data owner, analista de gobernanza y, en la cima, Chief Data Officer son posiciones que crecen a medida que la empresa madura de una central sobrecargada a un híbrido bien diseñado. El profesional que habla el idioma de TI y el idioma del negocio al mismo tiempo, sin trabar el negocio con burocracia innecesaria, es raro y está bien remunerado.

Principales dudas sobre el modelo operativo de gobernanza de datos

¿Cuál es el mejor modelo operativo de gobernanza de datos? No existe el mejor en abstracto. Una empresa pequeña, con un único ERP y pocas unidades, tiende a funcionar bien con el centralizado. Una empresa grande, multinacional, con varias unidades de negocio, generalmente necesita el híbrido.

¿Se puede migrar de centralizado a híbrido sin reestructurar todo? Se puede, y es el camino más común. Se empieza definiendo la matriz RACI para los dominios más críticos, como proveedor y material, y después se expande el modelo de data steward federado dominio por dominio.

¿El modelo federado funciona sin una plataforma de MDM? Por un tiempo, pero sin una herramienta que aplique la regla de forma automática la fragmentación llega rápido, porque el federado sin automatización depende de la disciplina individual de cada área, y la disciplina individual no escala.

¿Cómo medir si el modelo operativo está funcionando? Mediante los indicadores de gobernanza: tiempo promedio de aprobación de altas, tasa de duplicidad, porcentaje de datos completos y número de excepciones que el comité tuvo que resolver fuera del flujo normal. Si los indicadores no existen, el modelo tampoco existe de verdad, solo existe en el papel.

MDM Academy: dónde aprender a estructurar la gobernanza de datos en la práctica

MDM Academy es la escuela de gobernanza de datos maestros de 4MDG, creada para formar al profesional que el mercado brasileño todavía produce poco: alguien que entiende de datos maestros, de proceso de negocio y de tecnología al mismo tiempo, con cursos que tratan ese puente entre el modelo operativo en el papel y el modelo funcionando dentro de un SAP, un Oracle o un TOTVS de verdad.

Quien quiere avanzar en la carrera de gobernanza, convertirse en data steward, data owner o liderar algún día el área de datos de la empresa, encuentra en MDM Academy el camino estructurado que falta en gran parte del mercado. Recomiendo también el Club de los Datos, nuestra comunidad de profesionales de datos maestros y gobernanza, donde estas discusiones ocurren en la práctica.

Conclusión

El modelo operativo de gobernanza de datos no es el capítulo más bonito de la política de datos, pero es lo que decide si esta sale del papel. Un comité sin modelo operativo se vuelve una reunión. Una política sin modelo operativo se vuelve un archivo. Una plataforma sin modelo operativo se vuelve un gasto.

Antes de comprar la próxima herramienta o escribir la próxima política, vale la pregunta más simple de todas: en tu empresa, cuando dos áreas discrepan sobre cómo registrar el mismo dato, ¿quién decide?