Cómo construyo un diagnóstico de calidad de datos en los primeros 30 días de un proyecto
El diagnóstico inicial es la base de cualquier implementación exitosa. En los primeros 30 días mido qué tan confiable es el dato, dónde están los errores que más pesan y qué conviene priorizar antes de tocar procesos, integraciones o herramientas.
En los primeros 30 días de un proyecto no intento arreglar todo. Intento entender con precisión qué tan sano o qué tan frágil está el catálogo. Para eso construyo un diagnóstico que me permita responder cinco preguntas:
- qué datos faltan,
- qué datos se contradicen,
- qué parte del problema ya afecta la operación,
- qué errores no van a escalar bien,
- y qué conviene corregir primero.
No empiezo por la herramienta. Empiezo por la calidad del dato.
IBM resume la calidad de datos en seis dimensiones muy útiles para ordenar este análisis: exactitud, completitud, consistencia, puntualidad, validez y unicidad. Ese marco me sirve porque convierte una sensación general de desorden en variables observables y medibles.
Por qué el primer mes define el resto del proyecto
Hay una idea que para mí es bastante simple: si el diagnóstico es débil, el resto del proyecto también lo va a ser.
Desde afuera, muchas implementaciones parecen empezar cuando se elige una plataforma o se configura una integración. En la práctica, no. Empiezan mucho antes: cuando alguien se toma el tiempo de mirar qué información existe, cómo está organizada, cuánto se contradice, dónde falla y qué impacto real está teniendo sobre la operación.
Por eso, durante el primer mes, mi objetivo no es prometer velocidad. Mi objetivo es construir una lectura confiable del estado real del dato.
Akeneo insiste en algo parecido cuando habla de calidad de datos de producto: antes de enriquecer o publicar, hace falta reunir, preparar y depurar información que suele venir de múltiples fuentes, como ERP, proveedores y sistemas internos.
Qué necesito poder responder al final de esos 30 días
Cuando cierro esa primera etapa, necesito haber respondido esto:
1. Qué tan completo está el catálogo
No solo si tiene datos, sino si tiene los datos necesarios para operar, enriquecer y publicar.
2. Qué tan consistente es
Si un mismo tipo de producto está descrito con criterios parecidos o si cada familia parece escrita por un sistema distinto.
3. Qué errores ya están afectando al negocio
Productos que no publican, retrabajo, tickets, devoluciones, demoras o campañas frenadas.
4. Qué parte del problema es estructural
Errores que no se corrigen editando un par de celdas, sino revisando atributos, taxonomía, reglas o gobernanza.
5. Qué conviene atacar primero
Porque no todo pesa igual, no todo cuesta lo mismo y no todo merece prioridad en la misma fase.
En los primeros 30 días no intento arreglar el catálogo. Intento dejar de adivinar qué le pasa.
Qué mido en un diagnóstico de calidad de datos
Para no quedarme solo con síntomas sueltos, organizo la lectura del catálogo en dimensiones bastante claras.
1. Completitud: qué parte del dato directamente no está
Acá mido ausencia.
Reviso:
- atributos vacíos,
- productos sin imágenes,
- fichas sin descripción,
- variantes incompletas,
- campos obligatorios ausentes,
- y familias que no llegan al mínimo necesario para canal.
La pregunta no es “¿hay información?”. La pregunta es: ¿hay suficiente información útil para operar y publicar bien?
2. Consistencia: qué parte del catálogo se contradice a sí misma
Este bloque me muestra cuánta coherencia interna tiene el dato.
Busco:
- una misma marca escrita de formas distintas,
- valores equivalentes cargados como si fueran diferentes,
- diferencias arbitrarias entre familias comparables,
- o conflictos entre ERP, planillas, PIM y canal.
Cuando la consistencia falla, el catálogo deja de comportarse como un sistema y empieza a comportarse como una acumulación de excepciones.
3. Exactitud: qué parte del dato parece existir, pero no es confiable
Acá ya no me alcanza con que el valor esté cargado. Necesito saber si es correcto.
Miro:
- medidas improbables,
- unidades incoherentes,
- imágenes que no corresponden,
- atributos incompatibles con el producto,
- y descripciones que no representan bien lo que se vende.
Un dato incorrecto es más peligroso que un dato ausente, porque da una falsa sensación de completitud.
4. Validez: qué parte del dato no respeta la forma que debería tener
En este punto reviso si el dato está bien cargado desde la lógica del sistema:
- formatos inválidos,
- listas cerradas mal usadas,
- campos de texto donde debería haber opciones controladas,
- números cargados como texto,
- o estructuras que después rompen filtros, integraciones o validaciones.
Esto parece técnico, pero impacta directamente en escalabilidad.
5. Unicidad: cuántas veces el mismo producto aparece como si fuera más de uno
Acá me concentro en:
- duplicados,
- duplicados parciales,
- variantes mal separadas,
- productos padre e hijo mal modelados,
- y entidades que deberían consolidarse pero hoy compiten entre sí.
La falta de unicidad no solo ensucia el catálogo. También fragmenta la verdad del producto.
6. Vigencia: qué parte del catálogo ya no representa la realidad actual
Este bloque me sirve para detectar desgaste acumulado:
- productos discontinuados aún activos,
- atributos viejos,
- estructuras heredadas que ya no responden al negocio,
- contenidos que quedaron desactualizados,
- y reglas que alguna vez sirvieron, pero hoy solo agregan ruido.
Ese marco coincide bastante con las dimensiones que IBM propone para evaluar calidad de datos y me ayuda a mantener el diagnóstico ordenado, comparable y defendible.
Cómo hago ese diagnóstico en la práctica
No construyo este análisis desde una sola planilla ni desde una sola pantalla. Lo armo cruzando capas distintas.
1. Relevo fuentes y responsables
Primero identifico de dónde viene la información y quién la toca.
Necesito mapear:
- qué sistema origina cada dato,
- quién lo modifica,
- quién lo valida,
- quién lo consume,
- y en qué punto del flujo se empieza a degradar.
Si no entiendo eso, cualquier hallazgo queda aislado.
2. Trabajo con volumen y con muestra
Hay veces en que reviso el catálogo completo. Otras veces trabajo con muestras representativas por familia, marca, canal o tipo de producto.
Las dos cosas son necesarias:
- el volumen me da dimensión,
- la muestra me da criterio.
Una me dice cuánto pesa el problema. La otra me ayuda a entender su lógica.
3. Armo una matriz de atributos
Esta es una de las herramientas que más uso al principio.
La matriz me permite ver:
- qué atributos existen,
- cuáles son obligatorios,
- cuáles están vacíos,
- cuáles están duplicados,
- cuáles están mal tipados,
- y cuáles ya no responden a ninguna necesidad clara.
Ahí suele aparecer bastante rápido si el problema es de carga, de diseño, de gobernanza o de todo un poco.
4. Hago una revisión semántica, no solo estructural
Este punto para mí es clave.
No miro solo si el dato está o no está. También miro cómo está nombrado y qué estabilidad semántica tiene.
Reviso:
- sinónimos no controlados,
- vocabulario inestable,
- naming incoherente,
- categorías ambiguas,
- y opciones de atributo que compiten entre sí sin necesidad.
La documentación interna sobre vocabularios controlados insiste justamente en eso: un vocabulario controlado asegura univocidad, mantenibilidad e interoperabilidad. Cuando esa capa falla, el problema no es editorial. Es estructural.
5. Cruzo el dato con la operación real
Después conecto calidad con impacto.
No me interesa solo saber que un atributo está mal. Me interesa saber qué genera eso:
- productos que no publican,
- errores de categorización,
- retrabajo entre áreas,
- fichas que tardan demasiado,
- tickets de soporte,
- o decisiones comerciales apoyadas en información poco confiable.
Ese cruce es el que convierte el diagnóstico técnico en diagnóstico de negocio.
Un buen diagnóstico no consiste en encontrar todo lo que está mal. Consiste en entender qué parte del problema está frenando hoy al negocio y qué conviene mover primero.
Qué entrego al final de ese primer mes
No cierro esa etapa con una lista desordenada de observaciones. Entrego una lectura útil para decidir.
1. Un estado general del catálogo
Una síntesis clara de salud del dato:
- fortalezas,
- riesgos,
- debilidades,
- y áreas más afectadas.
2. Hallazgos priorizados
No todos los problemas tienen el mismo peso. Por eso separo:
- hallazgos críticos,
- hallazgos importantes,
- y hallazgos que pueden esperar otra fase.
3. Métricas base
Defino el punto de partida para medir mejora después:
- completitud,
- duplicados,
- atributos inconsistentes,
- productos no listos para canal,
- familias mal estructuradas,
- o cualquier otro indicador que haga sentido para el proyecto.
4. Hipótesis de causa
No me interesa solo decir qué está mal. Me interesa entender por qué pasa:
- falta de gobernanza,
- mal diseño de atributos,
- taxonomía débil,
- procesos manuales,
- integración incompleta,
- o superposición de responsabilidades entre sistemas.
5. Un plan de ataque inicial
A partir de eso, propongo una secuencia:
- qué corregir primero,
- qué necesita rediseño,
- qué requiere validación con negocio,
- y qué conviene postergar para no abrir demasiados frentes a la vez.
Qué no hago en los primeros 30 días
También me importa dejar esto claro, porque evita falsas expectativas.
En esa primera etapa no intento:
- rediseñar todo el modelo sin evidencia,
- crear atributos por intuición,
- prometer automatizaciones sobre una base que todavía no entendí,
- ni proponer una herramienta como si el problema fuera solo tecnológico.
Tampoco intento “limpiar todo” de una vez. Cuando el catálogo está muy desordenado, eso casi siempre empeora el foco.
La documentación sobre modelado y normalización también empuja en esa dirección: antes de escalar o integrar, hace falta una estructura lógica que reduzca redundancia y le dé estabilidad al dato. Sin esa base, cualquier mejora posterior hereda fragilidad.
Qué hago con los resultados después
Una vez terminado el diagnóstico, recién ahí el proyecto empieza a tomar forma de verdad.
Con esa base puedo decidir con más criterio:
- si el problema es principalmente de calidad de contenido,
- si hay que revisar primero taxonomía,
- si el cuello está en atributos y modelado,
- si el dolor está en la operación,
- o si la empresa ya llegó a un punto donde un PIM tiene sentido real.
También me sirve para alinear expectativas. Porque una cosa es decir “hay que ordenar el catálogo” y otra muy distinta es saber:
- cuánto hay que corregir,
- cuánto esfuerzo va a requerir,
- en qué secuencia conviene hacerlo,
- y qué mejoras pueden esperarse en cada fase.
Cómo sé que el diagnóstico estuvo bien hecho
Para mí, un buen diagnóstico inicial deja tres cosas claras.
1. El problema ya no es abstracto
Deja de ser “los datos están mal” y pasa a ser algo más visible, medible y explicable.
2. El orden de prioridades se vuelve claro
No todo parece urgente al mismo tiempo.
3. La solución deja de ser genérica
El proyecto empieza a pedir una respuesta proporcional a su problema real, no una receta estándar.
Si esas tres cosas no quedaron claras, entonces el diagnóstico todavía no tuvo suficiente profundidad.
En los primeros 30 días no busco respuestas espectaculares. Busco hacer buenas preguntas y sostenerlas con evidencia. Para mí, un diagnóstico de calidad de datos sirve cuando logra algo muy simple y muy difícil al mismo tiempo: dejar de mirar el catálogo como un caos inevitable y empezar a verlo como un sistema que ya se puede entender, priorizar y mejorar.
