Modelo operativo: quién decide sobre qué

En la primera sesión quedó enunciada la tesis del curso: la gestión de datos responde cómo hacemos que el dato funcione y la gobernanza responde quién tiene derecho a decidir sobre el dato y qué le pasa si decide mal. Enunciarla es fácil. Sostenerla en una reunión de martes, cuando alguien propone «montemos el catálogo y con eso gobernamos», es otra cosa. Por eso vale la pena separarlas de manera operativa, con una diferencia que se pueda aplicar a una frase concreta en cinco segundos.

La distinción no es de importancia ni de jerarquía. Una organización puede tener una gestión de datos impecable —pipelines verdes, latencia de segundos, respaldo probado— y cero gobernanza. Ese es, de hecho, el caso más común y el más caro: el dato existe, es correcto, está disponible, y aun así nadie lo usa para decidir porque nadie estableció que fuera la fuente de la verdad. El Excel de la vicepresidencia es el síntoma clínico de una organización que gestiona bien y no gobierna.

Los dos marcos que va a ver en la sesión 5 hacen esta misma separación, cada uno a su manera, y conviene anticiparla porque explica muchas confusiones de vocabulario. La ISO/IEC 38505-1 la corta con el modelo EDM: el cuerpo de gobierno evalúa, dirige y monitorea; la gerencia planea, construye y opera. Son dos planos distintos, y por eso un comité de datos que termina revisando tickets dejó de gobernar sin darse cuenta.

La pregunta que sigue es sobre qué se ejerce cada uno de los dos oficios. La respuesta es el ciclo de vida del dato: la secuencia que va desde antes de que el dato exista hasta después de que dejó de servir. El DAMA-DMBOK la dibuja en siete fases —planear, diseñar y habilitar, crear u obtener, almacenar y mantener, usar, enriquecer y disponer— y esa es la que vamos a usar. La ISO/IEC 38505-1 corta el mismo terreno con otro mapa, el de rendición de cuentas: recolectar, almacenar, reportar, decidir, distribuir y disponer. Los nombres cambian; el punto no: el dato tiene una biografía, y en cada capítulo hay algo que se hace y algo que se decide.

Ese es el uso que le vamos a dar al ciclo en este curso: no como diagrama de proceso, sino como el eje sobre el que se separan las dos capas de la sesión. Cada fase se puede leer dos veces —una en clave de gestión, otra en clave de gobernanza— y en cada fase hay un rol distinto que responde. Lea la fila de arriba y verá un manual de operación; lea la de abajo y verá el mapa de decisiones que la organización toma sobre sus datos, casi siempre sin saber que las está tomando.

La otra razón para mirar el ciclo completo es económica, y es la que conviene llevar al comité: un defecto cuesta distinto según la fase en la que se corrige. Una definición ambigua atrapada en la fase 2 se arregla con una reunión. La misma ambigüedad detectada en la fase 5, cuando ya hay cuatro tableros construidos sobre ella, se arregla con un proyecto. Y si llega hasta la fase 6, cuando un modelo se entrenó con ese dato y alguien tomó decisiones sobre personas, ya no se arregla: se explica.

No existe un modelo operativo correcto. Existe un modelo operativo que resuelve el conflicto que su organización tiene. Centralizar reduce la ambigüedad y multiplica los cuellos de botella. Federar acelera a los equipos y multiplica las versiones de la verdad. La malla de datos promete lo mejor de ambos y cobra su precio en madurez de plataforma: sin autoservicio real, una malla es solo un silo con nombre nuevo.