Catálogo de datos: qué documentar y cómo evitar que se abandone

Un catálogo de datos es el inventario de lo que una empresa tiene guardado: qué conjuntos de datos existen, dónde viven, qué significa cada campo, de dónde vienen y quién responde de ellos. Dicho así suena a documentación aburrida, y por eso la mayoría de catálogos de datos acaban en una carpeta compartida que nadie abre. Pero el problema que resuelven es muy concreto y muy caro: el analista que tarda tres días en encontrar la tabla buena, los dos informes de ventas que dan cifras distintas y nadie sabe cuál creer, el proveedor nuevo que pregunta «¿y esto qué es?» y no hay nadie capaz de contestarlo con certeza.

Esta guía es para quien tiene que montar uno en una empresa mediana, sin equipo de gobierno dedicado y sin comprar una plataforma de seis cifras. Va de acotar, de documentar lo mínimo útil y, sobre todo, de diseñarlo para que siga vivo dentro de un año. Porque un catálogo desactualizado es peor que no tener catálogo: da respuestas con apariencia de verdad.

¿Qué es un catálogo de datos y qué no es?

Un catálogo de datos es un índice consultable de los activos de datos de la organización, con metadatos suficientes para que alguien que no construyó la tabla pueda decidir si le sirve. Tiene tres capas:

• Metadato técnico: nombre de la tabla, esquema, tipos de campo, volumen, frecuencia de carga, sistema origen. Esto se extrae solo del catálogo de la base de datos o del data warehouse.
• Metadato de negocio: qué significa este conjunto, qué significa cada campo en lenguaje de persona, qué filtro hay que aplicar para que cuadre con el informe oficial. Esto lo escribe una persona. No hay atajo.
• Metadato de gobierno: quién es el dueño, qué nivel de sensibilidad tiene, qué base legal lo ampara si hay datos personales, cuánto tiempo se conserva.

Conviene decir también lo que no es. No es un diccionario de datos exportado del ERP: eso es una lista de columnas, no un catálogo. No es la herramienta de BI: el cuadro de mando enseña indicadores, no explica de dónde salen. No es un proyecto de IA: el catálogo es anterior y se nota mucho cuando falta, porque cualquier iniciativa de IA empieza preguntando qué datos hay y en qué estado están. Y no es, bajo ningún concepto, un documento de 200 páginas en Word.

Un catálogo sirve si responde en menos de un minuto a «¿dónde está el dato de X y me puedo fiar?». Si tarda más, el equipo vuelve a preguntar por chat y el catálogo ya está muerto.

¿Por qué se abandona la mayoría de catálogos de datos?

Hemos visto el mismo patrón en empresas muy distintas. El catálogo se lanza con energía —tres semanas de reuniones, una plantilla preciosa, 180 tablas documentadas— y a los seis meses está desfasado. Las causas se repiten:

Se documentó todo. Alguien decidió catalogar las 400 tablas del ERP, incluidas las 250 que nadie consulta jamás. El esfuerzo se diluyó en lo irrelevante y las 20 tablas que de verdad se usan quedaron igual de mal explicadas que antes.

No hay dueño real, hay un responsable nominal. Se asignó el dueño en una casilla porque la plantilla lo pedía, pero esa persona no se enteró, no tiene tiempo asignado y no se le pregunta nunca. Un dueño que no recibe una notificación cuando cambia su tabla es un nombre en una celda.

El catálogo vive aparte del trabajo. Si para documentar un cambio hay que entrar en otra herramienta, con otra contraseña, y rellenar un formulario de doce campos, no se hace. La documentación tiene que estar donde ya se trabaja: en el repositorio de transformaciones, en el mismo sitio donde se define la tabla.

Nadie mide si se usa. Nunca se miró cuántas consultas tiene el catálogo al mes ni cuántos campos siguen sin descripción. Lo que no se mide se abandona en silencio.

Se confundió con un proyecto, no con un proceso. Un catálogo no se «termina». Se mantiene. Si no hay una rutina —quince minutos en la reunión semanal de datos, una revisión trimestral de los activos críticos—, la entropía gana.

La conclusión práctica: mejor 25 conjuntos de datos bien documentados y actualizados que 400 fotografiados una vez. La cobertura total es una trampa.

¿Qué hay que documentar de cada conjunto de datos?

Nuestra ficha mínima cabe en una pantalla. Si un campo no cambia una decisión de quien consulta, sobra.

| Campo | Qué resuelve | Ejemplo | |---|---|---| | Nombre de negocio | Que se encuentre buscando en lenguaje normal | «Ventas por línea de pedido» | | Ubicación técnica | Dónde está de verdad | `dwh.ventas.fact_pedido_linea` | | Descripción (3 líneas) | Qué contiene y qué NO contiene | «Una fila por línea de pedido facturada. No incluye presupuestos ni abonos» | | Origen y frecuencia | Si el dato de hoy está o no | ERP, carga diaria a las 05:00 | | Dueño de negocio | A quién se pregunta | Responsable de Administración | | Responsable técnico | Quién arregla la carga si falla | Equipo de datos | | Sensibilidad | Si lleva datos personales y de qué tipo | Contiene CIF y contacto: nivel medio | | Definición de 5-10 campos clave | Lo que de verdad confunde | `importe_neto` = base imponible sin IVA ni portes | | Métricas de calidad | Si te puedes fiar hoy | Completitud de `sector`: 71 % | | Consulta de ejemplo | Que se use bien desde el minuto uno | SQL con el filtro oficial aplicado |

Dos detalles que marcan la diferencia. El primero: documentar lo que el conjunto no incluye evita la mitad de los errores de interpretación; casi todas las discusiones de «este informe no cuadra» nacen de un alcance implícito que nadie escribió. El segundo: enlazar las métricas de calidad —completitud, unicidad, actualidad— convierte el catálogo en algo que se consulta antes de usar un dato, no solo cuando uno se pierde. Si aún no las tienes, en calidad de datos explicamos cómo calcularlas con SQL y sin comprar nada.

¿Cómo se mantiene vivo un catálogo de datos?

La respuesta corta: automatizando todo lo que es mecánico y ritualizando lo poco que queda. El reparto que funciona:

Automático, sin excepción. El inventario de tablas, los esquemas, los tipos, el volumen, la fecha de última carga y el linaje básico (qué tabla alimenta a cuál) salen de leer los metadatos del warehouse y las transformaciones. Si alguien está copiando a mano nombres de columnas a una hoja, el catálogo tiene fecha de caducidad.

Manual, pero dentro del flujo de trabajo. Las descripciones de negocio las escribe una persona, sí; pero en el mismo sitio donde se define la tabla, no en una herramienta aparte. En la práctica: un fichero de metadatos junto al código de transformación, que se revisa en el mismo pull request que el cambio. Si cambias la lógica y no tocas la descripción, el cambio no pasa.

Reglas de mantenimiento que se cumplen solas. Tres que recomendamos: un activo nuevo no sube a producción sin ficha mínima; un campo sin descripción aparece marcado en la vista del catálogo (la vergüenza pública funciona mejor que los recordatorios); una revisión trimestral de los 20-30 activos críticos con sus dueños, con acta de una página.

Dos indicadores y basta. Porcentaje de activos críticos con ficha completa y revisada en los últimos seis meses, y número de consultas al catálogo por mes. El primero mide salud, el segundo mide utilidad. Si el primero sube y el segundo no, el catálogo está bonito y es inútil: pregunta a tres analistas por qué no lo abren.

¿Qué herramienta hace falta para empezar?

Menos de la que te van a intentar vender. El criterio es el tamaño del problema, no el tamaño del catálogo ideal.

| Arquetipo | Cuándo tiene sentido | Coste y riesgo | |---|---|---| | Hoja de cálculo compartida | Menos de 30 activos, un equipo | Coste cero. Se desactualiza rápido; solo vale como arranque de semanas, no de años | | Wiki interna o documentación del repositorio | Hay equipo técnico y transformaciones versionadas | Muy barato. Requiere disciplina de pull request, pero es lo que mejor sobrevive | | Catálogo abierto autoalojado | 100+ activos, varias fuentes, linaje automático | Licencia cero, pero exige mantener la instalación: cuenta medio técnico | | Plataforma de gobierno comercial | Obligaciones regulatorias, varias unidades de negocio, cientos de usuarios | Licencia alta y proyecto de implantación: solo si ya hay proceso que soportar |

El error caro es comprar la plataforma para que ella cree el proceso. No lo hace. La herramienta recoge metadatos automáticamente y hace bonito el linaje, pero las descripciones de negocio y la responsabilidad sobre cada dato siguen siendo trabajo humano. Empresas con un buen catálogo en una wiki las hemos visto; con una plataforma cara y vacía, también.

Si estás más atrás en el camino —todavía discutiendo qué sistema es la fuente de verdad—, el orden correcto está en gobierno del dato y en estrategia de datos. El catálogo es la pieza que hace visible ese gobierno, no la que lo sustituye.

¿Por dónde empezar: un plan de 60 días?

Sin equipo nuevo y sin parar lo que ya está en marcha.

| Semanas | Qué se hace | Qué queda al final | |---|---|---| | 1-2 | Listar las 10 preguntas de negocio que más se repiten y rastrear qué tablas las responden | Lista corta de activos críticos reales, no teóricos | | 3-4 | Extraer el metadato técnico automáticamente y montar la ficha vacía de cada activo | Inventario que ya se actualiza solo | | 5-6 | Entrevistas de 30 minutos con quien usa cada activo; escribir descripciones y alcance | 20-30 fichas con negocio documentado | | 7-8 | Asignar dueños con nombre, conectar métricas de calidad y publicar | Catálogo consultable y dos indicadores en marcha |

Dos trampas en este plan. La entrevista de 30 minutos es más valiosa que la plantilla: casi siempre descubre que dos áreas llaman «cliente activo» a cosas distintas, y esa conversación vale más que cien fichas. Y la publicación necesita un empujón: anunciarlo en el canal no basta, hay que responder las tres siguientes preguntas de datos con un enlace al catálogo en vez de con la respuesta. Se aprende por uso.

Preguntas frecuentes

¿Cuánto cuesta montar un catálogo de datos?

En herramienta puede costar cero si arrancas sobre la wiki o el repositorio que ya usas. El coste real es tiempo: unas 60-80 horas repartidas entre el equipo de datos y los responsables de negocio para dejar 25-30 activos críticos bien documentados, más un mantenimiento de unas dos horas al mes.

¿Quién debe ser el dueño de un conjunto de datos?

Quien toma decisiones con ese dato, no quien lo almacena. El dueño del maestro de clientes es Comercial o Administración, no el equipo técnico. El responsable técnico es una figura distinta y complementaria: arregla la carga cuando falla, pero no decide qué significa «cliente activo».

¿Hace falta un catálogo antes de un proyecto de IA?

No hace falta el catálogo completo, pero sí la parte que toca el proyecto. Cualquier iniciativa seria empieza inventariando qué datos existen y en qué estado están; si eso no está escrito, se hace igualmente durante el proyecto, solo que más caro y sin que quede para la siguiente vez.

¿Y si los datos están repartidos en Excel y varios sistemas?

Es lo normal y no impide catalogar. Se documenta el Excel como un activo más, con su ubicación, su dueño y su riesgo —un fichero en un portátil es un riesgo, y ponerlo por escrito suele ser lo que desbloquea su migración a un sitio decente, sea un data warehouse o algo más sencillo.

Si estás decidiendo si vuestro problema es de catálogo, de calidad o de arquitectura, la respuesta suele aparecer mirando las fuentes durante una mañana: en la auditoría hacemos exactamente ese inventario y os decimos qué merece documentarse ya y qué puede esperar. Y si lo que queréis es contrastar un plan que ya tenéis escrito, hablemos media hora: en ese rato suele verse si el catálogo va a sobrevivir al primer trimestre o no.