Gobierno del dato en programas multipaís: por dónde empezar

Por qué un programa multipaís no puede gobernar el dato "por país"

En un programa de un solo país, un modelo de datos débil es un problema local: se detecta, se corrige, se sigue. En un programa multipaís, el mismo modelo débil se replica en cada ola de implementación, y cada país lo adapta a su manera porque nadie definió un estándar común antes de empezar. El resultado, dos años después, no es un sistema con datos imperfectos: son N sistemas con N interpretaciones distintas de qué es un cliente, un producto o una transacción, todos técnicamente "correctos" y todos incompatibles entre sí.

DAMA-DMBOK (el Data Management Body of Knowledge) da un marco completo de once áreas de conocimiento. Para un programa multipaís, en la práctica, cinco de esas áreas concentran casi todo el riesgo real. Este artículo es sobre esas cinco, en el orden en que conviene abordarlas; no sobre el marco completo, que ya está bien documentado en otros lados.

Las cinco áreas que mueven la aguja

Área DAMA	Por qué importa en un programa multipaís
Gobierno de datos	Define quién decide sobre el modelo canónico cuando dos países discrepan. Sin esto, cada disputa se resuelve caso a caso y el modelo se fragmenta.
Arquitectura y modelado	El modelo de datos canónico es lo que hace que "cliente" signifique lo mismo en todos los países. Se define una vez, antes de la primera ola.
Datos maestros y de referencia	Monedas, unidades, códigos de producto, catálogos regulatorios; si no se armonizan, cada país migra su propia versión y la consolidación se vuelve manual para siempre.
Calidad de datos	Reglas de calidad medibles y con dueño, no una aspiración. Sin esto, "limpiar los datos" es una tarea sin fin ni criterio de éxito.
Metadatos y linaje	Poder responder "de dónde salió este número" es lo que hace auditable el programa frente a un regulador o un comité, país por país.

El orden importa más que la lista

El error que veo más seguido no es ignorar estas áreas. La mayoría de los programas tiene, en algún documento, una sección sobre cada una. El error es trabajarlas en paralelo sin secuencia, o peor, después de que la primera ola ya migró datos. El orden que uso:

Gobierno primero, aunque parezca lento. Definir quién es el dueño de cada dominio de datos (cliente, producto, transacción) y quién resuelve una disputa entre países, antes de que exista una disputa real que resolver bajo presión de cronograma.
Modelo canónico antes de la primera ola. No un modelo perfecto; un modelo suficiente, documentado, con las entidades centrales definidas de forma que cualquier país nuevo se pueda mapear contra él, no reinventarlo.
Datos de referencia armonizados desde el diseño. Monedas, unidades y catálogos regulatorios se acuerdan una vez, a nivel de programa, no una vez por país.
Reglas de calidad con dueño y umbral medible. No "los datos deben estar limpios" sino, por ejemplo, "menos de 2% de registros de cliente sin identificador fiscal válido antes del corte de migración", con un responsable de ese número.
Linaje desde el primer día, no reconstruido después. Documentar de dónde viene cada dato mientras se migra es barato. Reconstruirlo un año después, para responder a una auditoría, es carísimo.

El error más caro Tratar el gobierno de datos como un anexo técnico que se resuelve después del go-live. Si el modelo canónico y los dueños de dato no están definidos antes de la primera ola, cada ola siguiente hereda el mismo problema, multiplicado por país, y para la tercera ola, ya no es un problema técnico, es un problema político entre equipos que no quieren ceder su versión del dato.

Qué es razonable tener antes de la primera ola

No hace falta un programa de gobierno de datos maduro para arrancar; hace falta lo suficiente para no heredar deuda estructural. En términos concretos, antes de migrar el primer país:

Un modelo canónico documentado para las entidades centrales (cliente, producto, transacción, o las que apliquen al programa).
Un dueño nombrado por dominio de datos, con autoridad real para resolver discrepancias entre países.
Catálogos de referencia armonizados para los campos que más se repiten entre países: monedas, unidades, códigos regulatorios.
Al menos tres o cuatro reglas de calidad medibles para los campos más críticos del negocio, con umbral y responsable.

Todo lo demás (un catálogo de datos completo, un programa de calidad exhaustivo, metadatos para cada tabla) se construye en paralelo a las siguientes olas. Pero esos cuatro puntos, si no están antes de la primera ola, se vuelven exponencialmente más caros de instalar después.