Conectividad e interoperabilidad
Interoperabilidad de datos: contratos, validación, trazabilidad y gobernanza
01 · Definición
- Esquema y significado de cada campo
- Responsable del dato y consumidores registrados
02 · Validación en la entrada
- Estructura y tipos
- Reglas de negocio y referencias a maestros
- Cuarentena con motivo de rechazo
03 · Trazabilidad
- Origen y versión de transformación
- Indicadores de calidad por lote
04 · Gobierno del cambio
- Propuesta revisada con consumidores
- Pruebas de contrato antes de publicar
El problema
Por qué hay que decidirlo bien
Los informes de dirección que no cuadran entre departamentos, las auditorías que piden justificar una cifra y nadie sabe de qué sistema salió, o los indicadores que cambian de golpe porque alguien modificó una regla de cálculo sin avisar tienen el mismo origen: datos que circulan sin definición compartida ni responsable. Corregirlo después cuesta mucho más que acordarlo antes. El problema de negocio es poder tomar decisiones y rendir cuentas sobre datos cuyo significado, calidad y procedencia están documentados y se pueden comprobar.
Escenarios
Situaciones en las que se plantea
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Consolidación de datos de varias plantas
Cada planta registra consumos y producción con sus propias unidades y códigos de motivo. Un contrato de datos común fija unidades, tablas de referencia y reglas de conversión, y los datos que no se pueden convertir quedan señalados en lugar de sumarse mal.
02
Validación semántica antes de aceptar un lote
Además de comprobar tipos y campos obligatorios, se aplican reglas de negocio: fechas de entrega posteriores a la de pedido, cantidades positivas, referencias que existen en el maestro. Los registros que fallan pasan a cuarentena con su motivo y no contaminan el resto.
03
Justificar una cifra ante una auditoría
Cada registro conserva su origen, la fecha de extracción y la versión de la transformación que lo produjo. Ante una pregunta sobre un indicador, se puede reconstruir de qué sistema y de qué lote salió cada valor y qué reglas se le aplicaron.
04
Cambio de significado detectado antes de publicar
Un equipo quiere redefinir qué cuenta como «pedido activo». Las pruebas de contrato con los consumidores registrados muestran qué informes y procesos cambiarían, y el cambio se aprueba, se comunica y se fecha antes de llegar a producción.
Decisiones técnicas
Qué hay que decidir y con qué criterio
01
Qué contiene un contrato de datos
Esquema y tipos, significado de cada campo con unidades y formatos, valores admitidos, reglas de calidad mínimas, frecuencia de entrega, responsable del dato y lista de consumidores. Se versiona junto al código que lo produce.
02
Validación por niveles y destino de lo inválido
Estructura, reglas de negocio y coherencia con maestros se comprueban en la entrada. Para cada nivel se decide si se rechaza el lote, se aparta el registro a cuarentena o se acepta con aviso, según el coste de cada error.
03
Tablas de referencia compartidas
Unidades, países, monedas, motivos de rechazo o estados se mantienen en tablas con responsable y versión, en lugar de copiarse en cada sistema. Cuando existe una codificación estándar reconocida, se evalúa adoptarla.
04
Linaje y metadatos
Se decide qué procedencia se guarda por registro o por lote: sistema de origen, momento de extracción, versión de transformación. Guardar más permite explicar más, a cambio de almacenamiento y disciplina en el proceso.
05
Gobernanza del cambio
Quién propone cambios en un contrato, quién los aprueba, cómo se avisa a los consumidores y con qué antelación. Un proceso ligero pero escrito evita que una mejora local rompa un informe ajeno.
06
Medición de la calidad
Indicadores por lote y por fuente, como porcentaje de registros en cuarentena, campos vacíos o retrasos de entrega, visibles para el responsable del dato. Lo que no se mide tiende a degradarse sin que nadie lo note.
Riesgos y límites
Lo que conviene tener presente
- La gobernanza de datos es sobre todo organizativa: sin responsables con tiempo asignado, los contratos se quedan desactualizados.
- Unas validaciones demasiado estrictas pueden bloquear la operación por errores menores; el nivel de exigencia se ajusta con los usuarios del dato.
- Adoptar un estándar sectorial puede ser obligatorio en algunos ámbitos; esa obligación la determina quien conoce la normativa aplicable, no el diseño técnico.
- En sectores regulados, el linaje y los registros apoyan la recogida de evidencias, pero la validación y conformidad corresponden a la organización y a los procesos pertinentes.
Preguntas frecuentes
¿Qué diferencia hay entre un esquema y un contrato de datos?
El esquema dice qué estructura y tipos son válidos. El contrato añade lo que el esquema no expresa: qué significa cada campo, quién responde de él, qué calidad mínima se espera, con qué frecuencia llega y quién depende de él.
¿Hace falta una herramienta de catálogo de datos?
Para empezar, no. Contratos versionados en un repositorio y validaciones automáticas cubren mucho. Una herramienta de catálogo compensa cuando el número de fuentes y consumidores hace difícil encontrar y mantener esa información a mano.
¿Qué hacemos con los registros que quedan en cuarentena?
Se revisan con el responsable del dato en origen, se corrigen allí cuando es posible y se reprocesan. Si el mismo motivo se repite, suele indicar que la regla está mal planteada o que el sistema de origen necesita un control en la captura.
Sectores, capacidades y lecturas relacionadas
Sectores donde se plantea
Capacidades relacionadas
- InteroperabilidadIntercambios entre organizaciones basados en contratos y esquemas explícitos, preparados para cambiar de versión sin romper a nadie.
- Analítica operativaIndicadores, alertas e históricos construidos sobre datos depurados y con definiciones acordadas, para que todos discutan la misma cifra.
- Calidad y no conformidadesNo conformidades, acciones correctivas, auditorías internas e inspecciones en un flujo único, con cada evidencia vinculada a su origen.
Cuéntanos qué datos no cuadran entre tus sistemas o informes
Ninguna modalidad está disponible por defecto en todos los proyectos: se elige tras evaluar requisitos, sistemas existentes y riesgos.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.