La mayoría de los programas de gobierno fallidos que me han pedido rescatar no fallaron en la ejecución. Fallaron en la definición. Alguien en la sala creía que gobernar datos era una plataforma, otra persona creía que era un ejercicio de cumplimiento, una tercera creía que era un proyecto con fecha de fin, y el programa se financió con el promedio de esas creencias. Dieciocho meses después había una herramienta, una biblioteca de políticas y ningún cambio en cómo nadie tomaba decisiones.
Así que vale la pena ser preciso, y aquí precisión significa decir qué no es la gobernanza con el mismo cuidado que qué sí es. Una definición que solo se expande es inútil: si la gobernanza incluye todo, nadie puede saber si la está haciendo.
Qué SÍ es la gobernanza de datos
La gobernanza de datos es el ejercicio de autoridad sobre los datos: decidir quién puede decidir qué, con qué evidencia y quién responde por el resultado. Tiene cuatro partes que funcionan.
Reglas con alcance
La gobernanza produce políticas y estándares de datos: afirmaciones que se sostienen mire alguien o no. Los atributos sensibles se clasifican y se tratan en consecuencia. La retención tiene un plazo y un disparador. Los nombres tienen convención. Un término de negocio tiene una única forma aprobada, guardada en un glosario de negocio, y se espera que los informes que lo usan coincidan con ella.
La prueba útil de una regla es si podrías saber, con evidencia, que se ha incumplido. "Valoramos la calidad del dato" no es una regla. "El email del cliente es obligatorio en cuentas activas, se mide semanalmente y el propietario del dominio acepta cualquier mes por debajo del 98 %" sí lo es.
Responsabilidad con nombre y apellido
La gobernanza asigna un propietario de datos por dominio —una persona responsable, no un comité— y lo apoya con custodios de datos que hacen el trabajo definicional y de calidad del día a día. Los custodios técnicos sostienen el almacenamiento y los controles.
La palabra que importa es persona. La propiedad repartida entre un foro es propiedad que nadie siente.
Un lugar donde los desacuerdos terminan
Dos equipos definirán "cliente activo" de forma distinta y ambos tendrán razón para su propósito. La gobernanza aporta el foro —un consejo de gobierno de datos o equivalente— donde eso se resuelve con una decisión, una fecha y un registro, en lugar de escalarse hasta que alguien se cansa.
El registro es la parte que hace el trabajo. La mayoría de las discusiones sobre definiciones en organizaciones grandes son la misma discusión repitiéndose, porque la resolución anterior se tomó en una reunión y nunca se escribió donde alguien nuevo la encontrara. Un registro de decisiones con diez entradas evita más retrabajo que un cuerpo de políticas de cien páginas.
Una práctica, no un estado
Las definiciones derivan, los sistemas cambian, la regulación se mueve y cada reorganización deja huérfano un conjunto de propietarios. La gobernanza es la rutina que se da cuenta. Eso implica una cadencia de revisión, derechos de decisión que se revisan y controles que se retiran cuando dejan de ganarse su sitio.
Mito 1: la gobernanza es algo que se compra
Este es el caro. Los catálogos, los motores de calidad y las herramientas de linaje son genuinamente útiles: hacen visibles, aplicables y baratas de comprobar las decisiones de gobierno. Lo que no pueden hacer es tomar la decisión.
Un catálogo de datos alojará encantado cuatro definiciones rivales de "ingresos" sin queja alguna. La herramienta no tiene opinión sobre cuál es correcta ni autoridad para hacer vinculante ninguna. Cuando un programa de gobierno empieza con un proceso de compra, lo que suele entregarse es un catálogo vacío y la lenta comprensión de que poblarlo exige exactamente las conversaciones que la herramienta se compró para evitar.
Hay una señal fiable de este fracaso. Pregunta qué porcentaje de los activos del catálogo tiene a la vez propietario y definición aprobada. Con una función de gobierno bien llevada el número es pequeño pero creciente, y alguien puede decirte qué dominios están cubiertos. En un programa que empezó por la herramienta el número es desconocido, y la respuesta honesta es que el rastreador pobló el inventario y nadie lo ha revisado desde entonces.
Compra la herramienta en segundo lugar. Decide primero quién decide.
Mito 2: es un proyecto que termina
Los proyectos se acotan, se financian, se entregan y se cierran. La gobernanza se comporta como una operación: tiene coste de funcionamiento, un turno y una cola de trabajo que nunca se vacía. Tratarla como proyecto produce un arco predecible: una carta constitutiva, una explosión de actividad, un informe de cierre y una decadencia silenciosa a medida que los propietarios que nombró cambian de puesto y nadie los reemplaza.
He visto llegar el informe de cierre con el problema de fondo intacto: once políticas aprobadas, un consejo constituido, un catálogo desplegado, y los equipos de finanzas y comercial siguiendo con cifras de ingresos distintas en la misma revisión mensual, porque ninguna política había nombrado nunca a quién le corresponde arbitrar eso. El proyecto terminó. La gobernanza no había empezado.
La versión que sobrevive tiene una casa permanente y un presupuesto corriente pequeño. También tiene un criterio de salida para cada control individual, no para la función entera: cada control tiene dueño y fecha de revisión, y en la revisión o se justifica con evidencia o se elimina. Ese hábito es lo que evita que la gobernanza se sedimente en la burocracia de la que todo el mundo se queja.
Mito 3: es otra palabra para gestión de datos
La gobernanza decide; la gestión de datos construye y opera. La política de clasificación es gobierno, el cifrado y la configuración de acceso son gestión. La tolerancia de calidad es gobierno, la regla de calidad y el enrutado de la alerta son gestión.
Confundirlas provoca un fallo específico y frecuente: la gobernanza se financia dentro de TI, se dota con ingenieros y se le pide producir una autoridad que no tiene. Los ingenieros pueden implementar cualquier regla que les des. No pueden hacer que el director financiero acepte una definición, y pedírselo es la forma en que "gobierno" se gana su reputación de obstáculo. Si la frontera no está clara en tu organización, Gobernanza de Datos vs. Gestión de Datos la recorre en detalle.
Mito 4: existe para reducir riesgo
El riesgo y el cumplimiento son la manera más fácil de financiar el gobierno, y por eso tantos programas se enmarcan así, pero ese encuadre limita el valor sin que nadie lo note.
Una función de gobierno juzgada solo por riesgo optimiza para cobertura de controles. Añade aprobaciones, porque una aprobación es auditable. Y nunca quita ninguna, porque quitarla crea exposición sin crédito equivalente. El resultado es una función segura, lenta y mal recibida, y la primera que se recorta cuando aprieta el presupuesto.
Los programas que duran miden también el lado habilitador: cuánto tarda alguien en obtener acceso a un conjunto de datos, cuántas métricas certificadas se reutilizan en lugar de reconstruirse, cuánta reconciliación manual se ha eliminado, con qué rapidez puede lanzarse un nuevo producto de datos con propiedad y calidad ya resueltas. Esos números cuestan más de recoger y son la razón por la que a alguien fuera de auditoría le importa. Si nunca has puesto una cifra al lastre operativo, la calculadora del coste de los datos malos es una primera estimación razonable.
Mito 5: se puede añadir después
La gobernanza puesta a posteriori sobre un patrimonio en producción no es el mismo trabajo que la gobernanza diseñada desde el principio, y cuesta varias veces más. Asignar propiedad después de construir el almacén significa reconstruir la intención leyendo SQL. Clasificar después de la ingesta significa un proyecto de descubrimiento en sistemas que nunca se etiquetaron. Acordar definiciones cuando ya existen doce cuadros de mando significa una migración, no una decisión.
La versión ligera al principio es genuinamente barata: un propietario y una clasificación antes de que un conjunto de datos entre en la hoja de ruta, una definición de "terminado" que incluya umbral de calidad y ruta de alerta, y un decisor con nombre para el puñado de preguntas donde la organización se atasca. Nada de eso exige plataforma ni consejo. Exige la disciplina de hacer tres preguntas antes de construir, no después.
Los cinco mitos, uno al lado del otro
| No es | Porque | Qué es en realidad |
|---|---|---|
| Una herramienta que compras | El software guarda decisiones; no puede tomarlas ni exigir responsabilidad | La autoridad que decide qué registra la herramienta |
| Un proyecto que termina | Las definiciones derivan, los sistemas cambian, los propietarios se van | Una práctica operativa con coste corriente y cadencia de revisión |
| Un sinónimo de gestión de datos | Una produce reglas y responsabilidad, la otra sistemas y operación | La capa de decisión que la gestión de datos implementa |
| Solo cuestión de riesgo | Un gobierno centrado solo en el control añade aprobaciones y nunca las quita | Una función medida por protección y por habilitación |
| Algo para añadir luego | Ponerlo a posteriori obliga a reconstruir la intención desde sistemas vivos | Un pequeño conjunto de preguntas hechas antes de construir |
Qué hacer con esto
Si estás intentando financiar un programa de gobierno, o explicar por qué el anterior no funcionó, los mitos de arriba suelen ser el lugar donde realmente está el desacuerdo. Conseguir que una sala se ponga de acuerdo en qué no es la gobernanza cuesta más o menos una hora y le ahorra un año al programa medio.
Después empieza lo bastante pequeño para ser creíble. Tres dominios con propietarios con nombre, diez decisiones escritas, un foro con mandato real y una medida publicada de si las decisiones se están acelerando. Eso es una función de gobierno. Todo lo demás —la plataforma, la estructura de consejos, la hoja de ruta de madurez— es una elaboración que puedes permitirte cuando lo básico ya funciona.
Si quieres ver dónde está hoy tu organización, la evaluación de madurez en gobierno de datos cubre las cuatro dimensiones que predicen si un programa aguantará. Para la mecánica de convertir estos principios en rutinas que funcionan, Cómo construir un modelo operativo de gobierno de datos es el paso siguiente, y Introducción a las bases de un programa de gobierno de datos cubre los fundamentos en orden.