Limpiar datos: cuándo compensa y cuándo es tirar horas

«Primero habría que limpiar los datos.» Es una frase que suena prudente y que puede tragarse una cantidad de horas difícil de justificar después. La prudencia real no está en limpiar más, sino en decidir bien: qué se limpia, hasta qué punto, y qué se deja exactamente como está. Este artículo es para tomar esa decisión con criterio, porque limpiar por limpiar no es rigor: es trabajo sin destinatario.

«Limpio» no existe; existe «suficientemente bueno para esto»

La primera trampa es tratar la limpieza como un estado que se alcanza: la base de datos impecable, todo deduplicado, todo completo. Ese estado no existe, y si existiera no duraría. Los datos se degradan cada día que la operación funciona: clientes que cambian de dirección, un comercial que teclea con prisa, un proveedor que se fusiona con otro. Perseguir la base perfecta es fregar una cocina en la que se sigue cocinando.

La pregunta útil no es «¿están limpios los datos?», sino «¿son suficientemente buenos para lo que tienen que alimentar?». Un teléfono mal escrito es grave en la lista de clientes con pedidos en curso e irrelevante en un histórico de contactos de hace años. La calidad no es una propiedad del dato: es una relación entre el dato y su uso. Sin uso, no hay calidad que discutir.

El criterio: limpia lo que alimenta decisiones

De ahí sale el criterio central, que cabe en una frase: se limpia lo que alimenta decisiones y procesos; lo demás, no. Antes de tocar un solo registro, la pregunta es qué consume esos datos:

• Decisiones. Los informes que dirección mira de verdad, las cifras con las que se fijan precios, se compra o se contrata.
• Procesos. Todo lo que funciona solo sobre esos datos: facturación, envíos, avisos automáticos. Un proceso automático con datos malos no falla: ejecuta el error con total eficiencia.
• Obligaciones. Lo que la contabilidad, la facturación o la normativa de protección de datos exigen tener en orden.

Si un campo no alimenta ninguna de las tres cosas, limpiarlo produce exactamente nada. Puede doler admitirlo, porque ese campo costó esfuerzo rellenarlo en su día. Pero el esfuerzo pasado no es un motivo: es la definición de coste hundido.

Tres destinos: limpiar, archivar, dejar morir

Con el criterio anterior, cada bloque de datos acaba en uno de tres destinos, y los tres son legítimos:

• Limpiar lo que alimenta decisiones y procesos activos. Aquí sí compensa invertir: deduplicar, completar, corregir, con una definición clara de qué es «correcto».
• Archivar lo que no se usa pero puede pedirse: histórico contable, documentación con obligación de conservación, datos de clientes antiguos que la normativa permite y conviene guardar. Fuera del sistema operativo del día a día, pero accesible si alguien lo reclama. Archivar no es limpiar a medias: es reconocer que algo tiene valor de consulta y no valor de operación.
• Dejar morir los campos que nadie rellena desde hace tiempo, las listas que nadie consulta, las bases paralelas de proyectos que ya no existen. Congelarlas o eliminarlas —con cabeza y cumpliendo lo que la protección de datos exija— también es limpieza, y es la más barata de todas.

La mayoría de los proyectos de limpieza que se eternizan lo hacen porque intentan aplicar el primer destino a datos que merecían el segundo o el tercero.

Cierra el grifo antes de fregar

Hay una comprobación previa que ahorra más que cualquier técnica de limpieza: preguntarse por qué se ensucian los datos. Si el proceso que los genera sigue produciendo duplicados —un campo libre donde debía haber una lista cerrada, la misma alta tecleada en dos sistemas, nadie responsable de la ficha de cliente—, la limpieza no es un proyecto puntual: es un gasto recurrente disfrazado de proyecto puntual. Limpiarás, y en unos meses estarás donde empezaste, con la moral algo peor.

Arreglar el origen suele rendir más que la limpieza en sí, y a veces la hace casi innecesaria. Y hay una condición que no se puede saltar: limpiar exige una definición de «correcto». Si nadie ha decidido qué formato tiene un cliente bien dado de alta, o cuál de los tres registros duplicados es el bueno, la persona que limpia no está limpiando: está adivinando, registro a registro, decisiones que no le corresponden.

Cuándo sí compensa una limpieza a fondo

Hay momentos en los que la limpieza deja de ser opcional y pasa a ser la parte barata de algo más grande: antes de migrar a un sistema nuevo (mover basura a una casa recién estrenada es pagar dos veces), antes de automatizar un proceso que va a consumir esos datos sin que nadie los mire, o antes de un proyecto de reporting o de IA que se alimenta directamente de ellos.

En esos casos, además, el alcance viene decidido de fábrica: se limpia lo que el proyecto va a usar, no toda la base. El proyecto define qué datos importan, qué significa «correcto» para cada uno y cuándo se ha terminado. Una limpieza sin proyecto detrás no tiene ninguna de las tres cosas, y por eso no termina nunca.

Cinco preguntas antes de lanzar una limpieza de datos

1. ¿Qué decisión, proceso u obligación consume estos datos? Si la respuesta es «ninguno», ahí acaba la limpieza.
2. ¿Sabemos qué significa «correcto» para cada campo, y quién lo decide cuando haya dudas?
3. ¿Hemos cerrado el grifo, o dentro de unos meses estaremos igual?
4. ¿Qué parte podemos archivar o dejar morir en lugar de limpiar?
5. ¿Cómo sabremos que hemos terminado?

Si puedes responder las cinco, la limpieza que hagas será corta, con destinatario y con final. Si no puedes, el problema todavía no es de limpieza: es de criterio, y ese conviene resolverlo antes de tocar un solo registro.