Calidad de datos: como mejorarla sin parar la operacion

El 30% que nadie quiere mirar

Un ejecutivo de una empresa logistica nos dijo una vez: “Nuestros datos estan bien, simplemente no siempre cuadran.” Esa frase resume el estado de la calidad de datos en la mayoria de las organizaciones. Nadie dice que los datos son malos. Dicen que “hay algunas inconsistencias” o que “a veces hay que ajustar manualmente.”

La realidad es menos amable. IBM estima que los datos de baja calidad cuestan a las empresas estadounidenses 3.1 billones de dolares al ano. Gartner calcula que el 30% de los datos criticos de negocio de una organizacion tipica son inexactos, incompletos o duplicados. No estamos hablando de datos historicos enterrados en un data warehouse que nadie consulta. Estamos hablando de los datos que alimentan decisiones operativas diarias: direcciones de envio, precios de productos, estados de pedidos, informacion de clientes.

El impulso natural cuando alguien reconoce el problema es proponer un “proyecto de limpieza de datos.” Reunir un equipo, limpiar la base de datos durante tres meses, declarar victoria y volver a lo normal. El problema es que los datos se ensucian continuamente. Sin mecanismos que prevengan y detecten la degradacion, tres meses despues del proyecto estaras en el mismo punto. O peor, porque la organizacion pensara que el problema esta resuelto.

Profiling: medir antes de actuar

No puedes mejorar lo que no mides. El data profiling es el diagnostico que precede al tratamiento. Consiste en analizar sistematicamente los datos existentes para entender su estructura real (no la documentada, la real), sus patrones, sus anomalias y sus vacios.

Un profiling basico cubre cuatro dimensiones:

Completitud. Que porcentaje de registros tiene cada campo relleno? Si tu tabla de clientes tiene 50.000 registros pero el campo “email” esta vacio en 12.000, tu completitud de email es del 76%. Eso puede ser aceptable o catastrofico dependiendo del caso de uso.

Unicidad. Cuantos duplicados existen? Duplicados exactos son faciles de detectar. Duplicados fuzzy (Juan Garcia y J. Garcia Martinez que son la misma persona) requieren algoritmos de matching mas sofisticados. Herramientas como dedupe de Python o la funcion SOUNDEX de SQL ayudan, pero el matching fuzzy siempre requiere validacion humana en los casos ambiguos.

Consistencia. Los mismos datos representados de formas diferentes. “Madrid” vs. “MADRID” vs. “28001 Madrid” en un campo de ciudad. “Espana” vs. “ES” vs. “Spain” en un campo de pais. Fechas en DD/MM/YYYY vs. MM/DD/YYYY (pesadilla clasica). La inconsistencia no es un error en si misma; es un multiplicador de errores en cualquier proceso que consuma esos datos.

Validez. Los datos cumplen las reglas de negocio? Un NIF tiene un formato definido. Un codigo postal espanol tiene 5 digitos. Un email tiene una estructura validable. Un precio no puede ser negativo. Estas reglas parecen obvias, pero sin validacion activa, los datos invalidos entran y se propagan.

Herramientas de profiling van desde lo basico (pandas profiling en Python, que genera un informe HTML completo en una linea de codigo) hasta plataformas dedicadas como Great Expectations, Soda, o Monte Carlo. La herramienta importa menos que la disciplina de ejecutar el profiling periodicamente y actuar sobre los resultados.

Reglas de validacion: la primera linea de defensa

Las reglas de validacion actuan en el punto de entrada de los datos. Antes de que un registro se escriba en la base de datos, pasa por un conjunto de validaciones. Si falla, se rechaza o se marca para revision.

Las reglas se organizan en tres niveles:

Reglas de esquema. El tipo de dato es correcto, el campo obligatorio esta presente, el valor esta dentro de un rango aceptable. Estas reglas son deterministas y pueden implementarse en la capa de base de datos (constraints, check clauses) o en la capa de aplicacion (validacion de formularios, validacion de API). Implementarlas en la base de datos es mas seguro porque es imposible saltarselas. Implementarlas solo en la aplicacion deja la puerta abierta a imports directos o integraciones que bypasean la validacion.

Reglas de negocio. El pedido tiene al menos una linea. El descuento no supera el 40%. La fecha de entrega es posterior a la fecha de pedido. Estas reglas codifican conocimiento de dominio y cambian con el negocio. Deben ser configurables, no hardcodeadas, para que el equipo de negocio pueda ajustarlas sin cambios de codigo.

Reglas estadisticas. El valor esta dentro de N desviaciones estandar de la media historica. Una factura de 50.000 euros cuando la media es de 500 requiere revision, aunque sea tecnica y legalmente valida. Estas reglas detectan anomalias que las reglas deterministas no capturan.

Great Expectations es el estandar de facto para implementar estas reglas en pipelines de datos. Define “expectations” (reglas) sobre los datos, las ejecuta contra cada batch, y genera un informe de validacion. Las expectations se versionan en Git como cualquier otro codigo, lo que proporciona auditabilidad y colaboracion.

Pipelines de limpieza automatica

Las reglas de validacion previenen la entrada de datos malos. Los pipelines de limpieza corrigen los datos malos que ya existen (o que entran por canales que no pasan por las validaciones).

Un pipeline de limpieza tipico tiene tres fases:

Deteccion. Identificar registros que no cumplen los estandares de calidad. Puede ser un job programado que ejecuta las mismas reglas de validacion sobre datos existentes, o un proceso mas sofisticado que usa matching fuzzy para detectar duplicados.

Correccion. Para correcciones deterministas (normalizar mayusculas, formatear telefonos, corregir codigos postales), la automatizacion es segura. Para correcciones ambiguas (fusionar duplicados, corregir nombres), la automatizacion debe proponer y un humano debe aprobar. Automatizar la fusion de duplicados sin revision humana es una receta para perder datos.

Verificacion. Despues de cada ciclo de limpieza, las metricas de calidad deben recalcularse para confirmar que la limpieza fue efectiva y no introdujo nuevos problemas. Un pipeline que corrige 500 registros pero corrompe 50 es un pipeline roto.

La cadencia de limpieza depende del volumen y la tasa de degradacion. Para bases de datos con alta ingesta (miles de registros diarios), la limpieza debe ser continua. Para bases de datos mas estables, una ejecucion semanal puede ser suficiente.

El error mas comun es ejecutar el pipeline de limpieza una vez, celebrar la mejoria en las metricas, y no volver a ejecutarlo. Los datos se ensucian continuamente. El pipeline debe ser una operacion recurrente, no un evento.

Data stewards: el rol que falta

La tecnologia resuelve la mitad del problema. La otra mitad es organizativa. Quien decide que un 76% de completitud en emails es inaceptable? Quien define la regla de que un descuento no puede superar el 40%? Quien decide si dos registros ambiguos son duplicados o personas diferentes?

El data steward es el rol que responde a esas preguntas. No es un perfil tecnico puro ni un perfil de negocio puro. Es alguien que entiende los datos, entiende el negocio, y tiene la autoridad para tomar decisiones sobre calidad.

En organizaciones pequenas (menos de 50 personas), el data steward suele ser un rol parcial asumido por alguien de operaciones o de producto. En organizaciones medianas, es un rol dedicado o un equipo pequeno. En grandes empresas, es una estructura con stewards por dominio de datos (clientes, productos, transacciones) coordinados por un data governance officer.

Lo que no funciona es no tener a nadie. Sin un responsable definido, las reglas de calidad no se actualizan, los casos ambiguos no se resuelven, y las metricas de calidad se convierten en dashboards que nadie mira.

Dashboards de calidad: visibilidad continua

Un dashboard de calidad de datos muestra el estado de las metricas de calidad en tiempo real (o casi real). Las metricas fundamentales son:

• Completitud por campo y por tabla. Trending semanal.
• Tasa de duplicados detectados y resueltos.
• Tasa de registros invalidos que entran al sistema (por fuente).
• Tiempo medio de resolucion de incidencias de calidad.
• Score global de calidad (un indice compuesto que pondera las dimensiones relevantes para el negocio).

El dashboard no es para tecnologia. Es para negocio. Si el director comercial puede ver que el 8% de las direcciones de envio estan incompletas, y eso se correlaciona con una tasa de devolucion del 12%, la calidad de datos deja de ser un problema tecnico y se convierte en un problema de negocio con un coste visible.

Grafana con datos de Great Expectations, o herramientas dedicadas como Monte Carlo o Bigeye, proporcionan la visualizacion. Lo importante es que el dashboard sea visible, actualizado y accionable. Un dashboard que nadie revisa es decoracion.

Calidad de datos y fuentes externas

Un aspecto que los equipos suelen ignorar es que la calidad de datos no depende solo de tus sistemas internos. Una parte significativa de los datos entra desde fuentes externas: APIs de proveedores, imports de clientes, integraciones con marketplaces, datos scraped de webs publicas.

Cada fuente externa es un vector de degradacion. Un proveedor que cambia el formato de sus codigos de producto sin avisar. Un cliente que envia un CSV con codificacion Latin-1 cuando tu sistema espera UTF-8. Un marketplace que empieza a incluir caracteres especiales en los nombres de producto.

La defensa es tratar cada punto de integracion como un boundary de validacion. Los datos que entran desde fuera pasan por las mismas reglas de validacion (o mas estrictas) que los datos generados internamente. Un pipeline de ingesta que acepta todo lo que le llega sin validar es una invitacion al caos.

En la practica, construimos un staging area para datos externos. Los datos llegan, se validan, se normalizan, y solo entonces se escriben en las tablas de produccion. Los registros que no pasan la validacion van a una cola de revision donde un operador (o un proceso automatizado) los corrige o los rechaza. Este patron anade latencia a la ingesta (segundos, no minutos), pero evita que datos corruptos contaminen la base de datos principal.

El coste de no hacerlo es real y medible. Un cliente nuestro del sector retail descubrio que el 23% de los errores en su catalogo de productos provenian de un solo proveedor que enviaba datos en un formato inconsistente. Implementar validacion en la ingesta de ese proveedor redujo los errores del catalogo un 18% en el primer mes.

Gobernanza de datos vs. calidad de datos

Es facil confundir gobernanza y calidad, pero son conceptos complementarios. La calidad se ocupa de que los datos sean correctos, completos y consistentes. La gobernanza se ocupa de quien puede acceder a que datos, como se clasifican, como se retienen y como se eliminan.

Sin gobernanza, la calidad es insostenible. Si cualquiera puede modificar cualquier tabla sin control de acceso, las reglas de validacion se bypasean por conveniencia. Si no hay politicas de retencion, los datos obsoletos se acumulan y diluyen las metricas de calidad. Si no hay clasificacion de sensibilidad, los datos personales se copian en entornos de desarrollo sin proteccion.

La recomendacion practica es empezar por la calidad (tiene ROI inmediato) y construir la gobernanza de datos incrementalmente. Pero no ignores la gobernanza indefinidamente. Un marco basico de gobernanza (catalogo de datos, control de acceso, politica de retencion) es necesario antes de que la complejidad de los datos supere la capacidad del equipo para gestionarlos manualmente.

Implementacion incremental

No intentes arreglar toda la calidad de datos de una vez. El enfoque que funciona es incremental.

Semana 1-2: Ejecutar profiling sobre las tablas mas criticas. Identificar los tres problemas con mayor impacto en el negocio.

Semana 3-4: Implementar reglas de validacion en los puntos de entrada para prevenir nuevos datos malos. Esto detiene la hemorragia.

Mes 2: Construir el pipeline de limpieza para los datos existentes, empezando por los tres problemas identificados. Medir el antes y el despues.

Mes 3: Desplegar el dashboard de calidad y asignar un data steward (aunque sea un rol parcial). Establecer una revision semanal de metricas.

Ongoing: Expandir las reglas de validacion, anadir nuevas fuentes al profiling, refinar el pipeline de limpieza basandose en los patrones que emerge.

El objetivo no es la perfeccion. Es la mejora continua con mecanismos que previenen la regresion. Un 95% de completitud mantenido consistentemente es mejor que un 100% que dura una semana y cae al 80%.

Los datos son el activo mas subestimado de la mayoria de las empresas. No porque no tengan datos, sino porque los datos que tienen no son fiables. Mejorar la calidad de datos no es sexy, no genera titulares, y no impresiona en una demo. Pero es lo que permite que todo lo demas (analytics, IA, automatizacion, decisiones de negocio) funcione sobre una base solida en lugar de sobre arenas movedizas.