Anatomía de un programa de gobernanza

El DAMA-DMBOK es el cuerpo de conocimiento de gestión de datos de DAMA International, una asociación profesional sin ánimo de lucro que existe desde 1980 y trabaja con voluntarios. Eso importa más de lo que parece: el libro no lo escribió una firma que vende algo, y por eso nombra tipos de herramienta y nunca marcas. La referencia vigente es la segunda edición (2017), con una edición revisada de 2024 que unificó terminología, corrigió figuras, precisó la definición de dueño de datos y reescribió el capítulo de calidad. El marco no cambió. La tercera edición está en proyecto, con publicación prevista para 2027.

El DAMA-DMBOK dibuja once áreas de conocimiento alrededor de un centro: la gobernanza. La imagen es deliberada. Calidad, arquitectura, metadatos, seguridad, integración: cada una es una disciplina con su propia literatura. Ninguna funciona si en el centro no hay alguien con derecho a decidir.

Quitarle el centro a la rueda es el experimento que vale la sesión. Las diez áreas de afuera no se apagan: siguen funcionando, cada una razonablemente bien dentro de su frontera. Por eso la ausencia de gobierno casi nunca se siente como una falla — se siente como autonomía, y se descubre tarde, cuando dos cifras correctas no cuadran.

Segunda cosa que la rueda esconde: el libro tiene diecisiete capítulos y la rueda dibuja once. Los seis que quedan afuera son ética en el manejo de datos, big data y ciencia de datos, evaluación de madurez, organización y roles, gestión del cambio, y el capítulo 1 con los trece principios. Es decir: casi todo lo que decide si el programa sobrevive. Quien conoce el DMBOK sólo por la rueda se saltó justamente la parte que no se puede delegar en un proveedor.

La trampa del marco es tratarlo como una lista de compras. Ninguna organización implementa once áreas a la vez. La pregunta útil no es "¿qué nos falta?" sino "¿cuál de estas once, si mejora, desbloquea a las otras diez?" — casi siempre es metadatos o calidad, y casi nunca es la que el proveedor de turno está vendiendo.

Un marco sirve cuando permite mirar un desastre y saber a qué frente pertenece cada pedazo. Estos once síntomas son los de PagoYa, tal como llegan en la vida real: ninguno viene etiquetado y todos suenan a "problema de datos". Cada uno lo resuelve exactamente un área del DMBOK, y ninguna se repite.

El marco se sostiene en tres figuras. La rueda de las once áreas, que todo el mundo cita. El hexágono de los siete elementos ambientales —metas y principios, actividades, entregables, roles, prácticas, herramientas, cultura— clasificados en gente, proceso y tecnología, que casi nadie recuerda. Y el diagrama de contexto con que abre cada capítulo de área: entradas y proveedores a la izquierda, actividades en el centro, entregables y consumidores a la derecha, y al pie participantes, herramientas, técnicas y métricas.

De los tres, el diagrama de contexto es el único que se usa de verdad, porque cabe en una hoja y se llena hablando. No hay que leer seiscientas páginas para aplicarlo: se dibujan las ranuras y se reparte lo que ya existe en la organización. Cuando una ranura queda vacía —normalmente consumidores o participantes— eso ya es el hallazgo de la reunión.

Es la confusión más frecuente al citar el DMBOK, y hace que dos personas crean estar de acuerdo cuando no lo están.

1. Las once áreas — las dimensiones del oficio: los once frentes en que se reparte la gestión de datos. Sirven para no olvidar un frente, no para decidir por dónde empezar.
2. Los siete elementos ambientales — las dimensiones con que el marco describe cada área. Son las columnas del diagrama de contexto.
3. Las nueve dimensiones de calidad del capítulo 13 — de lo que habla casi todo el mundo cuando dice "dimensiones". Eran ocho en 2017; la revisión de 2024 agregó currency (vigencia) y cambió reasonability por reasonableness.

La norma ISO/IEC 38505 traslada al dato el modelo EDM de gobernanza corporativa de TI: Evaluate, Direct, Monitor. La junta evalúa el entorno, dirige mediante políticas y monitorea el cumplimiento. No opera. Esa separación es la que permite decir, sin contradicción, que la gobernanza de datos es responsabilidad de la junta directiva aunque ningún miembro de la junta sepa escribir SQL.

Confundir gobernanza con gestión es la razón por la que tantos comités de datos terminan revisando tickets.

Dicho eso, la separación se vuelve real cuando hay que escribirla sobre personas concretas. El comité de crisis de PagoYa es exactamente ese momento: cinco roles de gobierno, seis decisiones críticas y una sola regla dura — exactamente un aprobador por decisión. La bomba 3 no estuvo bloqueada seis semanas por falta de criterio, sino por falta de una firma identificable.

Aquí está el hueco real del marco, y conviene decirlo sin rodeos: el DMBOK describe qué existe, no en qué orden hacerlo. Ese vacío es el que llenan las consultoras, y explica por qué dos hojas de ruta para la misma organización pueden verse completamente distintas y las dos estar bien.

Lo que sí es objetivo son las dependencias. No se nombra dueño de un dominio que nadie ha delimitado; no se escribe un umbral sobre un término que no está definido; no se configura una herramienta con una política que no existe. Diez movimientos, unas cuantas dependencias duras — y de los diez, exactamente uno tiene proveedor.