La calidad de datos no es un proyecto con fecha de cierre. Es una capacidad que se desarrolla, se sostiene y se mejora día a día.
Hay una expresión que se escucha en casi todas las etapas de un proyecto de transformación: “una vez que tengamos los datos limpios, vamos a poder…”. Se dice antes de implementar un CRM, antes de lanzar un proyecto de analytics, antes de automatizar un proceso, antes de incorporar inteligencia artificial a cualquier flujo de trabajo.
En mi experiencia personal, en la enorme mayoría de los casos, ese momento de “datos limpios” nunca llega, porque se lo está imaginando como un estado final que se alcanza una vez y luego se mantiene solo. Esa expectativa es la raíz del problema.
Los datos no se limpian una vez. Se ensucian de forma continua, todos los días, en cada interacción, en cada carga manual, en cada integración entre sistemas que pincha, en cada cambio de proceso que no se reflejó a tiempo en la estructura de datos.
La calidad de datos no es un proyecto con fecha de cierre. Es una capacidad organizacional que hay que sostener de forma permanente, igual que se sostiene la seguridad informática.
Por qué se subestima este problema
La gestión de datos rara vez es la parte visible o atractiva de un proyecto de transformación. Cuando se está diseñando una implementación la atención y el presupuesto tienden a concentrarse en la funcionalidad final: los dashboards, las automatizaciones, los modelos.
La calidad de los datos que van a alimentar todo eso se trata como algo que “el equipo va a resolver” en paralelo.
El problema se hace visible recién cuando el sistema ya está en producción y los resultados no coinciden con lo esperado: el dashboard muestra números que nadie cree, el modelo predictivo da resultados que no tienen sentido de negocio, la automatización toma decisiones erróneas basadas en información incompleta o duplicada.
En ese punto, corregir el problema es mucho más caro que si se hubiera abordado desde el diseño inicial del proyecto.
Los tipos de problemas de datos que sabotean proyectos
No todos los problemas de calidad de datos son iguales, y vale la pena distinguirlos porque requieren soluciones distintas.
Está la duplicación: el mismo cliente, la misma cuenta, el mismo contacto, registrado varias veces con variaciones menores, generando reportes que sobreestiman o fragmentan la realidad.
Está la incompletitud: campos obligatorios que se llenan con valores por defecto sin sentido solo para poder guardar el registro, porque el usuario no tenía la información en el momento de la carga y el sistema no permitía continuar sin completarlo.
Está la inconsistencia: el mismo concepto de negocio definido de forma distinta según el área o el sistema de origen, es decir, el entendimiento de qué cuenta como cliente activo, o como oportunidad calificada, generando comparaciones que en realidad están sesgadas.
Y está la obsolescencia: información que fue correcta en algún momento pero que nadie actualizó, y que sigue siendo usada como si fuera vigente.
Cada uno de estos problemas requiere una intervención distinta: reglas de deduplicación y matching para el primero, validaciones y rediseño de formularios para el segundo, gobierno de datos y definiciones estándar para el tercero, procesos de actualización periódica para el cuarto. Tratarlos todos como “un problema de calidad de datos” genérico suele llevar a soluciones genéricas que no atacan la causa específica.
La calidad de datos como fase cero
La recomendación más concreta que se puede hacer a cualquier organización que está encarando un proyecto de transformación —ya sea de CRM, de analytics o de automatización con IA— es tratar la calidad de datos como una fase cero explícita, con presupuesto y tiempo asignado, antes de comprometerse con fechas de entrega de la funcionalidad final.
Esta fase cero implica varias cosas concretas. Implica un diagnóstico honesto del estado actual de los datos que van a alimentar el proyecto, sin asumir que están mejor de lo que están. Implica definir estándares y reglas de negocio compartidas entre las áreas que van a usar esos datos, resolviendo antes las discrepancias de definición que inevitablemente van a aparecer. E implica diseñar, desde el inicio, los mecanismos de gobierno que van a mantener la calidad en el tiempo: quién es responsable de cada dominio de datos, qué validaciones existen en el punto de entrada, y con qué frecuencia se revisa la salud de la información.
Gobierno de datos como capacidad permanente
El componente que más frecuentemente falta, incluso en organizaciones que sí invirtieron en limpiar datos alguna vez, es el gobierno permanente: la estructura de responsabilidades, procesos y controles que evita que los datos vuelvan a degradarse con el tiempo.
Esto requiere roles claros, requiere procesos de revisión periódica que detecten degradación antes de que se vuelva crítica, y requiere que la calidad de datos esté integrada en el diseño de cualquier proceso nuevo, y no como una revisión posterior.
Cada vez que se diseña un nuevo formulario, una nueva integración o un nuevo flujo de trabajo, la pregunta sobre qué controles de calidad de datos incluye debería ser parte del diseño, no un parche que se agrega después de que aparecen los problemas.
Un ejemplo de cómo se traduce en la práctica
Consideremos una organización que se prepara para lanzar un proyecto de analytics predictiva sobre su base de clientes, con el objetivo de anticipar cuáles tienen mayor probabilidad de comprar.
Si el proyecto arranca directamente con el diseño del modelo, es muy probable que el equipo de datos descubra, ya avanzado el trabajo, que existen múltiples registros duplicados del mismo cliente bajo distintos identificadores, que el campo de “fecha de última compra” no se completa de forma consistente entre las distintas líneas de negocio, y que buena parte de la información histórica que sería más valiosa para el modelo nunca se registró de forma estructurada, sino en comentarios de texto libre difíciles de aprovechar.
Descubrir esto a mitad del proyecto implica, en la práctica, detener el desarrollo del modelo para resolver un problema que debería haberse abordado antes. Descubrirlo como parte de una fase cero explícita, antes de comprometerse con fechas de entrega del modelo, permite dimensionar correctamente el esfuerzo real del proyecto desde el principio, y evita la frustración de un cronograma que se extiende varias veces porque cada extensión revela un nuevo problema de datos que no fue anticipado.
Quién debería ser responsable de la calidad de los datos
Una pregunta que suele generar ambigüedad dentro de las organizaciones es quién es, en definitiva, el responsable de que los datos estén en condiciones razonables. La respuesta más funcional no es “el equipo de IT” ni “el equipo de data” de forma exclusiva, sino un esquema de responsabilidad distribuida donde cada dominio de información tiene un dueño de negocio claramente identificado.
El dueño de los datos de clientes, por ejemplo, debería ser alguien del área comercial, ya que es quien entiende el significado de negocio de esa información y puede definir qué constituye un registro correcto.
El equipo de tecnología provee las herramientas, las validaciones automáticas y los procesos de detección de anomalías, pero la definición de qué es correcto y qué no lo es, en términos de negocio, no puede delegarse completamente en un equipo técnico que no tiene ese contexto.
Esta distinción de responsabilidades, cuando no está clara, es una de las causas más comunes de que los problemas de calidad de datos se discutan durante años sin que nadie con la autoridad y el conocimiento adecuados los resuelva de forma definitiva.
Una expectativa más realista
Ninguna organización va a tener datos perfectos, y perseguir esa idea como objetivo probablemente sea una pérdida de tiempo y esfuerzo.
El objetivo razonable es definir un nivel de calidad suficiente y sostenido para las decisiones que se necesitan tomar, con visibilidad clara sobre dónde están las debilidades restantes.
Aceptar esto de entrada cambia la conversación sobre cualquier proyecto de transformación: en lugar de esperar un momento futuro de datos limpios que nunca llega, la organización puede empezar a construir sobre una base de datos razonable, con un plan explícito para mejorarla de forma continua, en paralelo al resto del proyecto.
