Aplicarle a los datos del campo el rigor de un libro contable no los protege: los ahoga.
Esta nota es parte de la serie Dos estrategias sobre el mismo patrimonio. Sobre la tensión entre las dos estrategias suele bajar una tercera fuerza, presentada como la solución sensata: un gobierno de datos. La intención es buena y la necesidad es real. El problema es cómo suele venir diseñado.
Casi siempre viene modelado como un libro contable. Rigor máximo, inmutabilidad, aprobaciones, todo el dato validado y firmado antes de existir, un único camino oficial para cada número. Esa lógica es exactamente la correcta para un sistema de registro: la contabilidad, los activos, los contratos, todo lo que tiene que ser auditable y no puede cambiar sin dejar rastro. Ahí el rigor no estorba, protege.
Pero esa misma lógica, aplicada a la corriente operativa de datos, la asfixia. Los datos del campo no nacen perfectos y no pueden esperar a serlo. Un parte de perforación, una lectura de sensor, un avance de completación, un evento de una cuadrilla: eso tiene que fluir en minutos, no en aprobaciones. Sirve aunque esté incompleto, y se corrige aguas abajo.
Si le exigís al dato operativo el mismo rigor que le exigís al asiento contable, pasa una de dos cosas. O la operación se frena a esperar la validación. O la gente arma un camino paralelo por fuera del gobierno para poder trabajar, y volvés a tener las planillas en la sombra que querías eliminar, ahora con la bendición de haber "implementado gobierno".
Ese es el error central. No es que el rigor esté mal. Es que se aplica el rigor de una cosa a la naturaleza de otra. Un libro contable y un caudalímetro miden realidades distintas. Nadie querría que el caudalímetro se detuviera en cada lectura a pedir tres firmas. El gobierno de datos que no distingue entre el registro y la corriente termina imponiéndole al caudal la cadencia del libro, y ahoga la operación en nombre de protegerla.
La salida no es tener menos gobierno. Es tener el gobierno correcto para cada tipo de dato: rigor donde la consecuencia lo pide, velocidad donde la operación lo exige. Con la trampa a la vista, empieza el camino del medio, y empieza por lo más terrenal: cómo entregar valor visible pronto y cómo mapear con honestidad lo que hay. Sigue 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.
