Antes de mover un dato, nombre a su dueño
Por Dorian Chávez · cofundador y Chief Executive Officer de Hábil ·
Una plataforma de datos no sustituye el acuerdo sobre quién responde por cada dato. Dueño, acuerdo y reglas de calidad, antes de cargar.
En 1 minuto
Cuando una empresa reúne sus datos en un solo lugar, la tecnología no sustituye el acuerdo sobre quién responde por cada conjunto de datos. Si una cifra sale mal, ¿quién la corrige, en qué sistema y con qué prioridad acordada? La práctica de la industria pide tres cosas antes de cargar un dato: un dueño con nombre, un acuerdo escrito entre quien produce el dato y quien lo usa, y unas pocas reglas de calidad que se puedan comprobar en cada carga. No todo exige el mismo rigor: con una sola fuente y un uso acotado, puede empezar ligero.
Imagine una empresa de distribución de tamaño mediano. Es ficticia, pero se parece a muchas. Vende por tres canales, factura en un sistema, lleva el inventario en otro y las cobranzas en un tercero. Cada fin de mes, Finanzas y Comercial llegan a la junta con un número distinto de ventas netas.
La dirección decide resolverlo de una vez: reunir todos los datos en una plataforma, con tableros para cada área. El proyecto arranca bien. A los tres meses los datos ya llegan, los tableros se ven y la junta… sigue igual. Ahora discuten frente a una pantalla más grande.
¿Qué pasó? Nadie hizo una pregunta sencilla antes de mover el primer dato: ¿quién responde por él?
Este artículo es para quien va a aprobar —o ya aprobó— un proyecto para reunir los datos de su empresa. Sostiene una idea: antes de mover un dato, se nombra a su dueño, se escribe qué promete y se decide cómo se comprueba. La tecnología viene después.
Por qué los datos sin dueño se descomponen
Un dato de ventas lo produce un área (la que factura), lo transforman otras (la que concilia, la que arma el reporte) y lo usan muchas. Cuando algo sale mal, cada una puede señalar a la siguiente. Si nadie tiene la responsabilidad de que ese dato sea correcto, el error se corrige a mano en el reporte, cada mes, y vuelve a aparecer el siguiente.
La industria lleva años nombrando este problema. Zhamak Dehghani, en el texto que dio origen a la idea de data mesh, propone repartir la responsabilidad de los datos entre «las personas más cercanas a los datos» y tratar cada conjunto de datos como un producto, con sus usuarios tratados como clientes (Referencia 1). No hace falta adoptar todo ese enfoque para quedarse con lo esencial: un dato que se comparte necesita a alguien que responda por él, igual que un producto necesita a alguien que responda por su calidad.
Tres cosas que se definen antes de cargar
1. Un dueño con nombre, no un área
«Lo ve Finanzas» no es un dueño. Un dueño es una persona con nombre, en el área que produce el dato o la que mejor lo entiende, que tiene tres responsabilidades:
- Decir qué significa el dato. Qué es una «venta neta»: ¿con o sin devoluciones?, ¿con o sin notas de crédito?, ¿a la fecha de factura o a la de cobro?
- Aprobar los cambios. Si el sistema de origen cambia una regla, el dueño decide si la definición cambia también y avisa a quien usa el dato.
- Atender cuando no cuadra. Cuando una comprobación falla, alguien tiene que contestar, en un plazo acordado.
El marco de calidad de datos del gobierno del Reino Unido asigna al dueño del dato decisiones como si un dato que ya no se usa se archiva o se destruye, y pide que la información sobre su calidad se guarde junto con el dato (Referencia 3). Es una guía pública, no una norma para su empresa, pero el principio sirve igual: las decisiones sobre un dato tienen un responsable.
2. Un acuerdo escrito entre quien produce y quien usa
El segundo paso es poner por escrito qué promete ese conjunto de datos. La industria le llama contrato de datos: un acuerdo entre quien produce el dato y quien lo consume. El estándar abierto para estos contratos, Open Data Contract Standard (proyecto Bitol, en la fundación LF AI & Data), los organiza en secciones: lo fundamental, la estructura de los datos, las reglas de calidad y los canales de soporte, entre otras (Referencia 2).
Para un comité no hace falta un formato técnico. Basta con que el acuerdo conteste, en una página:
- Qué contiene: qué campos, con qué significado y en qué unidad.
- Cada cuánto llega: al cierre del día, cada hora, al momento.
- Qué calidad promete: las reglas de la sección siguiente.
- A quién se avisa cuando algo cambia o falla, y en cuánto tiempo se atiende.
El acuerdo protege a los dos lados. Quien usa el dato sabe qué puede esperar; quien lo produce sabe qué no puede cambiar sin avisar.
3. Unas pocas reglas de calidad que se comprueben en cada carga
La calidad no se declara; se comprueba. El marco del Reino Unido usa seis dimensiones definidas por DAMA UK: completitud, unicidad, consistencia, oportunidad, validez y exactitud (Referencia 3). Su ejemplo es útil: 300 alumnos, 294 teléfonos de emergencia capturados; el campo está completo al 98 %, pero eso no dice que los teléfonos sean correctos. Completo no es lo mismo que correcto.
Traducido a una empresa, las primeras reglas suelen ser sencillas:
| Dimensión | Pregunta para el dueño | Regla de ejemplo |
|---|---|---|
| Completitud | ¿Llegaron todos los registros? | Las facturas del día coinciden en número con las del sistema que factura |
| Unicidad | ¿Hay duplicados? | Cada folio aparece una sola vez |
| Consistencia | ¿Cuadra con su origen? | La suma del día coincide con el total del sistema que factura |
| Oportunidad | ¿Llegó a tiempo? | Los datos del día están cargados antes de la hora acordada |
| Validez | ¿Respeta el formato y el catálogo? | Cada RFC tiene la forma correcta; cada sucursal existe en el catálogo |
Reglas de ejemplo para ilustrar; las de su empresa las define cada dueño.
Como punto de partida, elija las reglas que cubran los riesgos más relevantes de ese dato —registros faltantes, duplicados, diferencias contra el origen—, acuerde cuándo se comprueban y quién atiende una falla, y haga que el resultado lo vea quien usa el dato antes de usarlo.
Cuándo sí y cuándo no hace falta todo esto
Nombrar dueños y escribir acuerdos cuesta tiempo de personas ocupadas. No en todos los casos conviene.
Puede empezar ligero si:
- Sus reportes salen de un solo sistema, con un uso acotado y un responsable identificado.
- Es un análisis de una sola vez, que nadie va a repetir ni a usar para decidir dinero.
- Es un experimento con datos de prueba, sin efecto en la operación.
Aun en esos casos, y más si hay datos personales o una obligación regulatoria de por medio, deje por escrito qué significa el dato, quién responde por él y quién puede verlo.
Conviene hacerlo antes de cargar si:
- El mismo número se arma con datos de dos o más sistemas.
- Dos áreas ya llegan a la junta con cifras distintas de lo mismo.
- El dato alimenta una decisión de dinero, un reporte a una autoridad o un modelo de IA.
- Van a entrar nuevas fuentes cada año: cada una multiplica las formas de equivocarse.
Lo que descartamos, y por qué
- «Primero cargamos todo y luego vemos.» Es la tentación más común, porque se siente como avance. El problema es que el gobierno agregado después, sobre datos que ya se usan, se negocia con áreas que ya construyeron reportes sobre definiciones distintas.
- «Que el área de sistemas sea la única dueña del dato.» Sistemas puede responder por la operación, la seguridad y los accesos, pero no le toca decidir si una devolución resta en el mes de la venta o en el de la nota de crédito. Ese significado, su uso y su calidad son del área de negocio. Deje los dos papeles escritos, y quién resuelve cuando no coinciden.
- «Un comité de datos decide todo.» Un comité ayuda a resolver conflictos entre áreas, pero si cada cambio espera su sesión mensual, la gente vuelve a la hoja de cálculo. El dueño decide los cambios dentro de su ámbito; si un cambio toca una definición compartida, los accesos, la privacidad u otra área, el comité lo resuelve, con responsable y fecha.
- «Comprar una herramienta de catálogo resuelve el gobierno.» Una herramienta guarda las definiciones; no las escribe ni las hace cumplir. Sin dueños, el catálogo se llena de campos sin descripción.
Cinco preguntas para su próximo comité
- ¿Quién, con nombre, responde por cada uno de los cinco números que más se discuten en la junta?
- ¿Está escrito qué significa cada uno, y lo aprobó su dueño?
- ¿Qué reglas se comprueban en cada carga, y quién ve el resultado antes de usar el número?
- Cuando una regla falla, ¿a quién se avisa y en cuánto tiempo se atiende?
- Si el sistema de origen cambia una regla, ¿quién se entera antes de que el reporte salga mal?
Si la mayoría de las respuestas es «nadie» o «depende», el proyecto de datos todavía no está listo para crecer.
Por dónde empezar esta semana
Tome los tres conjuntos de datos detrás de los números que más se discuten —las facturas, los pagos, el inventario, el que sea— y llene una hoja por cada uno:
- Dueño: nombre y área; y, aparte, quién lo opera en el área de sistemas.
- Quién lo usa: qué áreas y para qué decisiones.
- Qué promete: qué contiene y cada cuánto llega.
- Reglas: cómo se sabe que está completo, sin duplicados y cuadrado contra su origen.
- Accesos: quién puede verlo.
- Aviso: a quién se le dice cuando no cuadra, y con qué prioridad se atiende.
Si alguna casilla queda vacía, ésa es la primera tarea, antes de comprar o construir nada.
Qué hace Hábil
En Hábil construimos a la medida los sistemas y las integraciones que mueven los datos de su empresa, y operamos la plataforma donde esos datos se reúnen.
Si su empresa necesita una sola versión de sus números, la propuesta está en Hábil Lake. Elegimos con usted las tres a cinco preguntas que más le cuestan hoy y, para cada una, dejamos por escrito de qué sistema sale cada dato, cómo se calcula y contra qué se cuadra. Cada carga se compara contra el sistema de origen —conteos, sumas, totales por fecha— y el resultado queda a la vista, como un semáforo: cuadra o no cuadra. Cada tabla tiene su descripción, su sistema de origen y el registro de las tablas de las que sale, y los accesos se dan por rol.
La conversación puede empezar con sus tres hojas, aunque estén a medias: qué datos, quién los produce y dónde se separan las cifras. Con eso revisamos juntos por dónde conviene empezar. Escríbanos por WhatsApp; para proteger su información, no comparta por ese medio datos de sus clientes ni de sus sistemas: acordaremos en la conversación el canal para el caso.
Pida su primera conversación, sin costo.
Consultadas el 13 de noviembre de 2026. Cada referencia lleva su confianza: alta (fuente primaria leída).
Referencias
- Zhamak Dehghani, «Data Mesh Principles and Logical Architecture», martinfowler.com. Domain Ownership: «decentralization and distribution of responsibility to people who are closest to the data»; Data as a product: «Analytical data provided by the domains must be treated as a product, and the consumers of that data should be treated as customers». Citado como práctica de la industria. Abierta en vivo el 13-nov-2026. Confianza: alta. https://martinfowler.com/articles/data-mesh-principles.html
- Bitol (LF AI & Data Foundation, según la cita que pide el propio repositorio), «Open Data Contract Standard (ODCS)», v3.2.0, licencia Apache 2.0. «A data contract defines the agreement between a data producer and consumers»; secciones: Fundamentals, Schema, References, Data quality, Support & communication channels, entre otras. Citado como práctica de la industria. Abierta en vivo el 13-nov-2026. Confianza: alta. https://bitol-io.github.io/open-data-contract-standard/latest/ · https://github.com/bitol-io/open-data-contract-standard
- Government Data Quality Hub (Reino Unido), «The Government Data Quality Framework». Seis dimensiones «as defined by DAMA UK»: completeness, uniqueness, consistency, timeliness, validity y accuracy; ejemplo de 294 de 300 registros (98 % completo, no necesariamente correcto); «the data owner should determine whether it should be archived … or destroyed. Information about the quality should be stored with the data». Es una guía para el gobierno británico, citada como referencia. Abierta en vivo el 13-nov-2026. Confianza: alta. https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework
- Hábil Lake →
- Su tablero dice que todo va bien. ¿De dónde salen esos números? →
- Target Canadá: anaqueles vacíos, bodegas llenas y un dato que nadie pidió que estuviera bien →
¿Su operación tiene estos desafíos?
¿Prefiere correo? Escríbanos a hola@habil.mx