← Perspectivas

Serie · Dos estrategias sobre el mismo patrimonio · Parte 6 de 7

gobierno de datos · sistema de registro · contratos de datos · operaciones

Un gobierno de datos que obtiene resultados (I)

Qué separar y quién responde: registro contra corriente, rigor por consecuencia, cada dominio dueño de sus datos.

Estudio RGC · 5 minutos

Esta nota es parte de la serie Dos estrategias sobre el mismo patrimonio. Vimos por qué el rigor de libro contable ahoga la corriente operativa. Acá va la primera mitad de un gobierno que sí se puede poner a correr. La idea rectora: un buen gobierno no es el que más controla, es el que hace fluir datos confiables.

Separar el sistema de registro de la corriente operativa. Es la distinción que ordena todo lo demás. El sistema de registro necesita rigor, inmutabilidad, auditabilidad, y puede ser más lento: es la verdad oficial de la que después nadie va a poder discutir. La corriente operativa necesita fluir a la velocidad del campo: oportuna, suficientemente buena, corregida aguas abajo. Cada una tiene su régimen. El pecado es aplicarle a la corriente el rigor del registro, y el pecado espejo es dejar que la corriente rápida se haga pasar por registro oficial. Se separan los dos mundos, con una frontera clara de dónde y cómo un dato operativo, una vez asentado, se promueve a registro.

Rigor por consecuencia. No todos los datos merecen el mismo control. Un dato que alimenta una decisión de inversión de millones no se gobierna igual que uno que alimenta un tablero de seguimiento intradía. La clave es clasificar los datos por cómo se usan y por la consecuencia de que estén mal, y aplicar rigor en proporción a esa consecuencia. Tratar todo con el máximo rigor no es prudencia, es desperdicio, y encima entrena a la gente a esquivar el gobierno porque lo vive como un obstáculo indiscriminado. En una palabra, el control se ajusta según su propósito.

Gobierno que habilita, y cada dominio dueño de sus datos. El trabajo del gobierno es hacer que el dato confiable fluya, no frenar la operación. Eso cambia dónde vive la responsabilidad. La propiedad del dato tiene que estar en el dominio que lo produce, cerca de donde el dato se genera y donde se entiende lo que significa, no en un comité central lejano que aprueba de a un ticket por vez. El comité central define las reglas del juego y las mide; el dueño del dominio responde por su dato. Un gobierno centralizado que se vuelve cuello de botella es un gobierno que la organización va a aprender a evitar.

Contratos de datos entre sistemas. Un contrato de datos es un acuerdo explícito en la interfaz entre dos sistemas: qué esquema tiene el dato, qué significa cada campo, y qué se garantiza sobre su calidad y su frecuencia. Cuando el productor y el consumidor acuerdan un contrato, se desacoplan: cada uno puede evolucionar por dentro sin romperle al otro, mientras respete lo pactado en la interfaz. Es el mismo enchufe normalizado, ahora aplicado a los datos: cambiás el aparato sin rehacer la instalación. Separado el registro de la corriente y con cada dominio dueño de sus datos, queda la otra mitad: calidad donde importa, rigor progresivo, y trazabilidad para la analítica y para la IA. Cierra en la próxima nota.

Glosario
Sistema de registro (system of record)
La fuente oficial y auditable de un dato: contabilidad, activos, contratos. Necesita rigor, inmutabilidad y trazabilidad, y puede permitirse ser más lento porque su valor es que nadie pueda discutirlo después.
Corriente operativa de datos
El flujo de datos que nace en el campo y tiene que moverse a la velocidad de la operación: partes, lecturas de sensor, avances, eventos de cuadrilla. Sirve aunque esté incompleto y se corrige aguas abajo; exigirle rigor de registro la asfixia.
Contrato de datos
Acuerdo explícito en la interfaz entre dos sistemas sobre el esquema del dato, el significado de cada campo, y las garantías de calidad y frecuencia. Desacopla al productor del consumidor, de modo que cada uno puede evolucionar por dentro sin romperle al otro.
Gobierno fit-for-purpose (según su propósito, por consecuencia)
Modelo de gobierno que clasifica los datos por cómo se usan y por la consecuencia de que estén mal, y aplica rigor en proporción a esa consecuencia. Evita tanto el descontrol donde la decisión es grave como el ritual inútil donde no lo es.
Calidad en la fuente de información
Validar el dato donde nace, con reglas simples y feedback inmediato a quien lo carga. Cuesta mucho menos que reconstruir la calidad aguas abajo y es la forma más barata de evitar que un error se propague.
Rigor progresivo
Estrategia de gobierno que empieza liviana, con visibilidad y contratos sobre los pocos flujos de mayor consecuencia, y agrega control donde la consecuencia lo justifica. Es lo contrario de un programa total que intenta gobernar todo de una vez y nunca termina.
Rehén de proveedor (vendor lock-in)
Situación en la que la operación queda atada a la hoja de ruta, los precios y los tiempos de un único proveedor o plataforma, porque apostó todo a él. Estandarizar el tejido conectivo en lugar de la aplicación es lo que preserva la opcionalidad y evita quedar rehén.
Tejido conectivo
El conjunto de conexiones por donde las piezas del ecosistema conversan: interfaces, identidad, contratos de datos, observabilidad. Estandarizar el tejido conectivo, y no la aplicación, es lo que permite cambiar cualquier pieza sin rehacer el conjunto.
AS-IS (estado actual)
El mapa honesto de cómo está hoy el patrimonio de aplicaciones: qué hay, qué está obsoleto, qué depende de qué. El punto de partida real, sin maquillar.
TO-BE (estado objetivo)
La dirección hacia donde se quiere llevar el ecosistema, dibujable y discutible, que se corrige sobre la marcha. No una foto fija, sino un rumbo firme.

La implementación del cambio que impulsa su operación.

Contactanos