Hay dos formas de arrancar un programa de gobierno de datos. Puedes partir de un marco, deducir qué capacidades te faltan y construir una hoja de ruta hacia un estado objetivo. O puedes partir de las cosas que visiblemente le están costando dinero y tiempo a la organización, arreglar unas cuantas con gobierno y dejar que el marco se rellene por detrás.
El primer enfoque produce mejores documentos. El segundo produce programas que sobreviven a su primera revisión de presupuesto.
Esto no es un argumento contra los marcos —uso DAMA DMBOK constantemente, y un modelo de capacidades es la herramienta correcta para planificar el segundo año—. Pero un programa de gobierno tiene que ganarse su credibilidad antes de poder gastarla, y la única moneda que reconoce alguien de fuera del equipo de datos es un problema del que ya se había quejado, ahora desaparecido.
Así que empieza por el dolor. Aquí va cómo encontrarlo y qué puede hacer el gobierno realmente con cada variedad.
Los seis puntos de dolor que justifican un programa
A lo largo de distintos proyectos, casi todo lo que las organizaciones describen como "un problema de datos" se resuelve en uno de seis patrones.
Silos de datos
Los departamentos guardan su propia copia de información compartida, porque en algún momento conseguirla de forma central fue más difícil que reconstruirla localmente. El síntoma visible es el esfuerzo duplicado; el síntoma caro es que las copias divergen y nadie puede decir cuál es la correcta.
La respuesta de gobierno no es "consolidar todo": eso es un programa de plataforma de varios años, no un acto de gobierno. Es nombrar la fuente autoritativa por entidad compartida, declarar derivadas las demás y publicar esa decisión donde se pueda encontrar. Un catálogo de datos ayuda, pero la decisión importa más que la herramienta.
Problemas de calidad
Los registros están incompletos, obsoletos, duplicados o mal. Todo el mundo lo sabe, y ese conocimiento vive en apaños: el analista que siempre filtra las cuentas de prueba, el equipo de operaciones que reescribe las direcciones antes de enviar.
El gobierno aporta la parte que ingeniería no puede suministrar: qué atributos importan lo suficiente para medirse, qué tolerancia es aceptable, quién acepta el riesgo cuando se incumple y quién responde por la corrección. Sin esas cuatro respuestas, las herramientas de calidad de datos producen cuadros de mando que miden todo y no cambian nada.
Falta de propiedad clara
Nadie responde, así que los problemas se discuten y no se resuelven. Es el punto de dolor que con más fiabilidad indica una brecha real de gobierno y no una técnica, y también el más barato de atacar: nombrar un propietario de datos por dominio cuesta una decisión, no un presupuesto.
La prueba que uso en un primer taller: nombra al responsable de tus cinco dominios principales. Si tarda más de un minuto, o produce el nombre de un equipo en lugar de una persona, ahí tienes tu hallazgo.
Definiciones inconsistentes
Dos equipos informan de "clientes activos" y los números difieren un once por ciento, porque uno cuenta un acceso en los últimos 90 días y el otro cuenta cualquier cuenta sin baja. Ambos son defendibles. Ninguno es autoritativo.
Para esto existe un glosario de negocio, aunque el glosario es el artefacto y no la solución. La solución es que alguien tenga autoridad para aprobar una definición y que los informes se cambien para cuadrar con ella.
Datos a los que es difícil llegar
El acceso tarda tres semanas y dos escalados, así que la gente construye copias en la sombra. Controles de acceso restrictivos sin un flujo alrededor no reducen el riesgo; lo trasladan a hojas de cálculo que nadie puede auditar.
Aquí el trabajo del gobierno es un esquema de clasificación, una regla de aprobación permanente por nivel y un nivel de servicio sobre la decisión. La mayor parte de la fricción de acceso no es un requisito de seguridad: es la ausencia de alguien facultado para decir sí.
Exposición de cumplimiento y seguridad
Hay datos sensibles en sitios que nadie ha mapeado, retenidos más tiempo del que permite cualquier política y copiados a entornos con controles más débiles. Esto se descubre normalmente en una auditoría y no en un incidente, que es el desenlace bueno.
El gobierno aporta clasificación de datos, reglas de retención con disparador y un propietario con nombre para cada dominio con información personal. El trabajo de ingeniería se deriva de esas decisiones y no puede precederlas.
| Punto de dolor | Qué te cuesta | El remedio de gobierno |
|---|---|---|
| Silos de datos | Esfuerzo duplicado, copias divergentes, disputas sin cierre | Fuente autoritativa por entidad, publicada y aplicada |
| Problemas de calidad | Retrabajo, reconciliación manual, desconfianza en el reporting | Lista de elementos críticos, tolerancias, propietario responsable |
| Falta de propiedad | Problemas discutidos y nunca cerrados | Una persona responsable por dominio |
| Definiciones inconsistentes | Cifras contradictorias en la misma reunión | Definiciones aprobadas con un árbitro |
| Acceso deficiente | Datos en la sombra, análisis lento, copias no auditables | Niveles de clasificación con reglas de aprobación permanentes |
| Exposición normativa | Hallazgos de auditoría, multas, proyectos de remediación | Clasificación, retención, propiedad nombrada de datos personales |
Por qué empezar por el dolor gana a empezar por el marco
Dos cosas marcan la diferencia en la práctica.
La primera es que un punto de dolor viene con patrocinador incluido. A alguien ya le importa, ya lo ha escalado y ya responderá por ti si se arregla. Las brechas de capacidad identificadas desde un marco no tienen esa clientela: tienes que fabricar el interés, que es buena parte de la razón por la que los programas de gobierno se pasan sus primeros seis meses en comunicación interna.
La segunda es que el remedio es comprobable. "Reducir el tiempo de resolución de una disputa de definiciones de tres semanas a tres días" pasó o no pasó. "Alcanzar el nivel 3 en gestión de metadatos" es una afirmación que solo el equipo de datos puede evaluar, lo que significa que es una afirmación que solo el equipo de datos se cree.
Encontrar el tuyo en dos semanas
No necesitas una evaluación de madurez para localizar el dolor. Necesitas cuatro entradas y quince días.
Entrevista a quien se queja. De diez a quince conversaciones, media hora cada una, repartidas entre perfiles de negocio y técnicos. La pregunta que da mejores respuestas no es "¿cuáles son tus problemas de datos?", sino "¿qué hiciste la semana pasada que no deberías haber tenido que hacer?". La gente describe los apaños con viveza y los problemas en abstracto.
Lee los escalados. Lo que use tu organización para incidentes, tickets o hallazgos de auditoría: saca los últimos doce meses y clasifícalos. La mayoría descubre que cuatro o cinco causas raíz explican la mayor parte, y que al menos una se repite trimestralmente desde hace años sin que nadie la asuma.
Muestrea los datos. Coge tus tres conjuntos más usados y ejecuta un perfilado básico: completitud por atributo, tasa de duplicados sobre la clave natural, distribución de valores frente a lo esperado, frescura frente al calendario declarado. Dos días de esto convierten "la calidad es mala" en un número, y un número es lo que se financia.
Encuesta a los consumidores. Corta y cuantitativa: cuánto confías en este informe, cuánto tardas en conseguir los datos que necesitas, con qué frecuencia reconstruyes algo que ya existe. Diez preguntas, distribución a todo el equipo. El valor está en la dispersión: un departamento que no confía en nada es un problema distinto de una organización que confía en todo igual de poco.
Convertir los hallazgos en un backlog
De ese ejercicio saldrán quince problemas, y la tentación es escribir una hoja de ruta que los aborde todos. Puntúalos en su lugar, en tres ejes:
- Frecuencia: cada cuánto muerde. Semanal gana a anual.
- Coste: qué consume en horas, retrabajo o riesgo. Si no puedes estimarlo, la calculadora del coste de los datos malos te llevará a un orden de magnitud defendible.
- Atacable por gobierno: si una decisión puede arreglarlo o si hace falta una migración de plataforma. Sé honesto aquí. El dolor que exige dieciocho meses de ingeniería es real, pero no demostrará nada este trimestre.
Coge los dos o tres que puntúan alto en los tres ejes y hazlos primero. Publica la cifra del antes y el después. Y usa ese resultado para pedir el trabajo estructural.
Cómo se ve esto cuando funciona
Un retailer con datos de producto inconsistentes. Los sistemas regionales y el comercio electrónico discrepaban en descripciones, precios y stock. Los clientes veían precios erróneos; los pedidos se cancelaban después de la compra. El remedio fue gestión de datos maestros de producto, pero el acto de gobierno que lo hizo posible fue decidir qué sistema era autoritativo para cada atributo y conseguir que el director comercial fuera dueño de esa decisión. El proyecto de MDM se había propuesto dos veces antes y había fracasado las dos por exactamente esa pregunta.
Una entidad financiera con datos sensibles sin mapear. Una auditoría interna encontró datos de cliente en sistemas fuera del alcance de cualquier control, sin propietario responsable. El remedio fue clasificación, captura de linaje y propiedad nombrada del dominio de cliente. Lo que lo hizo cuajar fue que el hallazgo de auditoría le puso fecha límite a la pregunta de propiedad, que es lo único que convierte con fiabilidad una recomendación de gobierno en una decisión de gobierno.
La trampa que hay que evitar
Hay un modo de fallo en el gobierno que empieza por el dolor, y conviene nombrarlo: el punto de dolor de vanidad. Alguien con rango tiene una queja concreta —normalmente sobre un informe que usa personalmente— y se convierte en la primera iniciativa del programa porque viene con patrocinio.
A veces está bien. A menudo es un problema estrecho que afecta a una persona, y resolverlo no le enseña nada a la organización ni demuestra nada sobre el valor del gobierno. Si el tema favorito de un directivo no puntúa bien en frecuencia y coste, arréglalo discretamente como favor y elige otra cosa como caso demostrativo.
Por dónde seguir
Diagnostica, puntúa, arregla dos cosas, publica el resultado. Ese es un primer trimestre que te gana el segundo.
Cuando ya sabes qué duele y por qué, las preguntas estructurales se vuelven contestables: qué dominios necesitan propietario, qué decisiones necesitan una casa y cuánto gobierno puede dotar realmente tu organización. Cómo construir un modelo operativo de gobierno de datos cubre ese paso siguiente, e Introducción a las bases de un programa de gobierno de datos expone los fundamentos en orden. Si prefieres empezar con una lectura estructurada de dónde estás en las cuatro dimensiones, la evaluación de madurez lleva unos diez minutos.