El informe de captación sigue cargando, pero el coste por cliente parece haberse reducido de golpe. Tras varias horas de revisión, descubres que el CRM ha cambiado el significado de «cliente activo»: ahora incluye cuentas de prueba. Ninguna columna ha desaparecido y la conexión funciona. El error está en lo que significa el dato.
Los contratos de datos permiten acordar esas condiciones antes de que un equipo cambie lo que otro utiliza. Concretan qué se entrega, qué significa, con qué calidad y quién responde cuando algo falla. Dentro de una estrategia de gobierno del dato, sirven para gestionar dependencias entre aplicaciones, informes y automatizaciones.
La utilidad aparece cuando el acuerdo se convierte en controles y avisos. Un documento que nadie mantiene puede quedar tan desactualizado como el diccionario de campos que pretendía sustituir.
Qué es un contrato de datos
Un contrato de datos, o data contract, es un acuerdo entre quien produce información y quienes la consumen. Puede describir una tabla, un archivo, un flujo de eventos o los datos que entrega una interfaz. Su alcance debe ser reconocible: «pedidos confirmados de la tienda» resulta más manejable que «todos los datos de ventas».
El Open Data Contract Standard de Bitol, conocido como ODCS, propone una estructura abierta para expresar estos acuerdos. Incluye apartados sobre esquema, calidad, equipo responsable, soporte y niveles de servicio. Permite que distintas herramientas interpreten una definición compartida, siempre que implementen la especificación y las funciones necesarias.
En este contexto, «contrato» designa un acuerdo operativo. Su adopción técnica no equivale por sí sola a formalizar un contrato jurídico, autorizar un tratamiento de datos personales o conceder acceso a una base de datos. Esas decisiones requieren sus propios mecanismos.
El contenido mínimo del acuerdo
Antes de elegir un formato o una herramienta, reúne al equipo que entrega los datos y al que necesita utilizarlos. Estas son las preguntas que conviene resolver para un primer contrato:
- Finalidad: qué decisiones o procesos dependen de los datos y qué usos quedan fuera.
- Significado: qué representa cada registro y cómo se interpretan los campos relevantes.
- Estructura: nombres, tipos, identificadores, campos obligatorios y valores admitidos.
- Calidad y entrega: comprobaciones, tolerancias, frecuencia y momento de disponibilidad.
- Responsabilidad: quién mantiene la fuente, quién aprueba cambios y dónde se comunican incidencias.
- Evolución: versión vigente, consumidores afectados y procedimiento para retirar campos o modificar definiciones.
La documentación de esquemas de ODCS distingue la representación de negocio de su implementación física. Esa separación ayuda a explicar, por ejemplo, que «importe neto» representa una cantidad sin impuestos aunque en una base de datos se almacene como un decimal llamado net_amount. Mantener ambos niveles permite discutir el significado sin perder la conexión con el campo real.
Ejemplo entre marketing y el CRM
Imagina una empresa ficticia que vende software por suscripción. Marketing recibe cada mañana una extracción del CRM para calcular la conversión de oportunidades a clientes. El equipo comercial quiere incorporar las pruebas gratuitas al mismo sistema. Para evitar que ese cambio altere el informe, ambos equipos acuerdan este contrato simplificado.
| Elemento | Acuerdo del ejemplo |
|---|---|
| Conjunto de datos | Una fila por cuenta con su primer contrato de pago confirmado. |
| Identificador | account_id obligatorio y único en la entrega. |
| Fecha de conversión | Fecha y hora de la primera contratación de pago, expresadas en UTC. |
| Importe | Importe inicial sin impuestos, acompañado de su moneda; no mezclar divisas al sumar. |
| Exclusiones | Cuentas internas, registros de prueba y suscripciones gratuitas. |
| Entrega | Datos del día anterior disponibles antes de las 08:00, hora de Madrid. |
| Incidencia crítica | Identificadores duplicados o ausencia de la fecha de conversión: detener la actualización del informe y avisar al responsable. |
| Responsable | Operaciones comerciales mantiene la extracción; Analítica valida su consumo. |
Las condiciones son hipotéticas y deben adaptarse al proceso real. Una empresa con cobro mensual, cancelaciones o reactivaciones necesitará acordar cómo representa esos eventos. Si cada reactivación genera otra fila, el conjunto deja de tener una fila por cuenta y cambia su granularidad: el nivel de detalle de cada registro.
También conviene separar la fecha del hecho de la fecha de carga. Una contratación del viernes incorporada al CRM el lunes debe conservar ambas si el informe necesita distinguir ventas ocurridas de registros recibidos. De lo contrario, el equipo podría atribuir al lunes una mejora que responde a un retraso administrativo.
Cambios compatibles y cambios que rompen
Renombrar una columna utilizada por un informe puede provocar un fallo visible. Cambiar su significado puede producir un resultado incorrecto que parezca perfectamente normal. Por eso la revisión debe cubrir tanto la estructura como la semántica.
Añadir un campo opcional suele ser menos arriesgado que eliminar uno, pero tampoco garantiza compatibilidad: algunos consumidores rechazan atributos desconocidos o importan columnas por posición. Cambiar un número por texto, introducir valores nuevos en un estado o pasar de euros a céntimos exige revisar los usos afectados.
Para un cambio incompatible, prepara una versión nueva, identifica los consumidores y acuerda una transición. Cuando sea viable, mantén temporalmente ambas versiones y compara sus resultados. La retirada de la anterior debe tener fecha, responsable y confirmación de los equipos que dependen de ella. El plazo se decide según el impacto; asignar siempre siete o treinta días carece de sentido si desconoces esas dependencias.
Controles que se puedan ejecutar
Empieza por pocas reglas que protejan decisiones importantes. En el ejemplo del CRM, comprobar identificadores, exclusiones y fechas aporta más que vigilar cincuenta campos que nadie usa. Una regla debe indicar qué se examina y qué ocurre si falla.
ODCS contempla reglas de calidad vinculadas a los datos. La definición escrita necesita después una herramienta capaz de ejecutarla. Guardar un archivo de contrato no activa automáticamente pruebas, alertas o bloqueos.
Separa los errores que impiden continuar de las anomalías que requieren investigación. Un identificador ausente puede impedir relacionar dos tablas. Una caída del volumen puede responder a una campaña terminada, un festivo o una incidencia. Bloquear por cualquier desviación genera interrupciones innecesarias; ignorarlas todas permite que los errores se propaguen.
Los niveles de servicio de ODCS permiten representar expectativas de entrega y otras propiedades operativas. Para tu equipo, concreta además cómo se mide el retraso: una carga ejecutada a tiempo puede seguir conteniendo información antigua. Comprueba la actualidad de los datos entregados, no únicamente que el proceso haya terminado sin errores.
Implantación en un flujo real
Elige un informe o una automatización cuyo fallo puedas describir. Revisa una incidencia reciente, localiza dónde se produjo el malentendido y utiliza ese caso para redactar el primer acuerdo. El productor debe poder cumplirlo y el consumidor debe explicar por qué necesita cada condición.
Después prueba los controles con muestras representativas y datos deliberadamente incorrectos. Introduce un duplicado, elimina un campo obligatorio y retrasa una entrega en un entorno de prueba. Verifica que el aviso llegue a quien puede intervenir y que el proceso adopte el comportamiento previsto.
Conserva la versión del contrato junto a los cambios técnicos relacionados. Antes de modificar la extracción, revisa si contradice el acuerdo. Tras desplegar, sigue comprobando las entregas: las pruebas previas no anticipan todos los errores de captura ni todas las incidencias de los sistemas de origen.
Para evaluar el piloto, registra las incidencias detectadas antes de llegar al informe, el tiempo de resolución y las falsas alarmas. Añade el trabajo necesario para mantener el contrato. Si exige más esfuerzo que el problema que resuelve, reduce el alcance o ajusta las reglas antes de extenderlo.
Datos para automatizaciones e IA
Estas mismas condiciones importan cuando los datos alimentan un sistema de inteligencia artificial. Un asistente que consulta ventas necesita saber qué mide cada campo, de qué periodo procede y qué restricciones tiene su uso. Una definición ambigua puede acabar convertida en una respuesta convincente pero equivocada.
El contrato ayuda a describir la información de entrada. No garantiza que el modelo interprete bien los datos, produzca una respuesta correcta o tenga autorización para actuar. Hay que comprobar esas capacidades por separado y aplicar los permisos en los sistemas que sirven la información.
Si quieres trabajar esta relación entre datos, métricas y decisiones, puedes consultar el Máster en Business Analytics y Business Intelligence de IEBS y solicitar orientación sobre su encaje con tu experiencia profesional.