Cómo mejorar la calidad de los datos antes de automatizar procesos

Introducción

La calidad de los datos determina qué decisiones puede ejecutar una automatización sin multiplicar errores ni perder control. Una tabla puede parecer ordenada y, sin embargo, no ser una entrada fiable para crear pedidos, asignar trabajos o enviar comunicaciones. El problema no siempre se ve en las celdas: a veces está en una identidad ambigua, una actualización retrasada o una regla que nadie ha definido.

Imagina un taller que quiere programar automáticamente revisiones de equipos. Dispone de clientes, números de serie y fechas de intervención, pero algunos equipos han cambiado de propietario y varias fechas indican cuándo se registró el trabajo, no cuándo se realizó. Automatizar directamente produciría un calendario aparentemente preciso construido sobre interpretaciones equivocadas.

Mejorar la calidad de los datos antes de automatizar procesos consiste en preparar la información para una acción concreta y demostrar que las entradas defectuosas no provocarán salidas indebidas. No exige limpiar todo el histórico ni esperar a una perfección inalcanzable. Exige definir qué se puede ejecutar, con qué evidencias y qué debe quedar pendiente.

El recorrido siguiente propone un método de trabajo para profesionales y pequeñas empresas: delimitar los datos críticos, acordar reglas, corregir el origen, separar excepciones y probar el comportamiento antes de habilitar acciones reales.

Índice

• Datos limpios y datos preparados para actuar no son lo mismo
• Empezar por la acción automática y sus datos imprescindibles
• Construir una línea de partida con evidencias, no con impresiones
• Definir un contrato de datos que pueda verificarse
• Elegir controles según el riesgo y el momento del proceso
• Corregir la captura y no limitarse a reparar exportaciones
• Normalizar sin inventar hechos ni borrar diferencias importantes
• Controlar identidad, actualidad y cambios entre la validación y la acción
• Diseñar una cola de excepciones que no se convierta en un almacén olvidado
• Probar los datos y las decisiones antes de activar efectos reales
• Caso práctico: preparar 200 equipos para propuestas de revisión
• Decidir cuándo avanzar sin esconder problemas detrás de un porcentaje
• Convertir la preparación en una práctica mantenible
• Preguntas frecuentes
• Conclusión

Datos limpios y datos preparados para actuar no son lo mismo

Una limpieza puede unificar formatos y eliminar espacios sin resolver el problema que impide automatizar. Un teléfono bien escrito puede corresponder a otra persona. Un código de producto existente puede identificar una referencia retirada. Una fecha válida puede representar un evento diferente del que necesita el proceso.

Conviene distinguir tres preguntas: si el dato puede leerse, si describe correctamente la realidad y si resulta adecuado para la acción prevista. Las tres importan, pero no se responden con la misma comprobación. Convertir una columna a fecha resuelve una cuestión de representación; comprobar qué evento fecha exige conocer el proceso.

El marco de calidad de datos del Gobierno británico plantea la calidad en términos de adecuación al uso: una información puede ser suficiente para una finalidad y no para otra. Aquí aplicaremos ese criterio a decisiones automáticas, no a obtener una puntuación abstracta de perfección.

La exigencia debe aumentar con la consecuencia

Mostrar un aviso interno permite corregir una interpretación antes de actuar. Cambiar una asignación o enviar un documento a un cliente tiene consecuencias más directas. Por eso una misma fuente puede servir para sugerir una revisión y no para ejecutarla sin confirmación.

La primera mejora puede consistir en limitar lo que hace la automatización. Preparar una propuesta en lugar de confirmar una operación reduce la dependencia de datos todavía inciertos, aunque sigue siendo necesario mostrar esa incertidumbre al revisor.

Cuando el objetivo inmediato es localizar defectos, el artículo sobre detección de errores frecuentes en datos empresariales desarrolla esa revisión. El paso adicional que nos ocupa es decidir cuáles de esos defectos bloquean una acción y cómo impedir que lleguen a ella.

Empezar por la acción automática y sus datos imprescindibles

Antes de revisar una base completa, describe la acción con un verbo y un resultado verificable. “Automatizar clientes” es demasiado amplio. “Crear una propuesta de visita para equipos con revisión vencida y contrato vigente” permite identificar dependencias concretas.

En ese ejemplo son necesarios el identificador del equipo, la relación vigente con el cliente, el contrato aplicable, la última revisión efectiva y la regla de periodicidad. Una nota comercial antigua puede aportar contexto, pero no debería bloquear el cálculo si no interviene en ninguna decisión.

Clasificar los campos por su función

Los campos de identidad determinan sobre qué objeto se actúa; los de decisión determinan si corresponde actuar; los de ejecución indican cómo hacerlo; los informativos ayudan a interpretar el resultado. Esta clasificación evita dedicar el mismo esfuerzo a todos los huecos de una tabla.

Documenta también el perímetro: equipos activos, contratos vigentes y un periodo de referencia definido. No confundas excluir datos fuera de alcance con descartar casos problemáticos para mejorar una estadística. Los casos elegibles que no pueden procesarse deben seguir visibles.

Si todavía no está claro qué resultado debe producir el proceso, conviene simplificarlo antes de automatizarlo. La calidad de entrada no puede compensar una decisión mal planteada.

Construir una línea de partida con evidencias, no con impresiones

La frase “los datos están bastante bien” no ayuda a decidir. Hace falta una fotografía inicial que indique qué conjunto se revisó, cuándo se obtuvo, qué reglas se aplicaron y qué problemas aparecieron. Sin ese registro, una mejora posterior puede deberse simplemente a haber cambiado de muestra.

Empieza por una extracción controlada o una vista de solo lectura. Conserva la procedencia y la fecha de corte. Cuando intervienen varias fuentes, anota la fecha de extracción de cada una: un listado de contratos de ayer y una tabla de equipos de hace un mes no describen necesariamente la misma situación.

Combinar controles completos y revisión contextual

Los controles sencillos, como claves ausentes o categorías no admitidas, pueden comprobarse sobre todo el conjunto cuando sea viable. La correspondencia con la realidad requiere a menudo revisar documentos de origen o consultar a quien conoce el trabajo. Una muestra sirve para descubrir problemas, pero no demuestra que todos los registros sean correctos.

Incluye casos normales y casos difíciles: cambios recientes de cliente, equipos dados de baja, importaciones antiguas, revisiones anuladas y registros corregidos manualmente. Revisar únicamente las fichas más completas proporciona una imagen demasiado favorable.

Cuenta por separado registros afectados e incidencias. Un equipo puede tener tres defectos y seguir siendo un único equipo pendiente. Sumar todos los errores como si pertenecieran a objetos diferentes sobredimensiona el problema; contar solo un error por registro puede ocultar su complejidad.

La salida útil es un registro de hallazgos con identificador, regla incumplida, evidencia, fuente y responsable de revisión. No necesita contener todos los datos personales del cliente. Debe permitir localizar el caso sin generar otra copia innecesaria de la información.

Finalmente, conserva algunas entradas problemáticas como casos de prueba sintéticos o adecuadamente protegidos. Serán la referencia para comprobar que una corrección posterior no vuelve a introducir el mismo fallo.

Definir un contrato de datos que pueda verificarse

Un contrato de datos es, en este contexto, un acuerdo operativo sobre lo que debe recibir el proceso: campos, significado, formatos, relaciones, vigencia y comportamiento ante incumplimientos. No se trata de un contrato jurídico ni de una herramienta concreta.

Puede empezar en una ficha breve. Lo decisivo es que la persona que mantiene el origen y la que desarrolla la automatización interpreten lo mismo. Escribir “fecha correcta” deja demasiadas posibilidades; escribir “día de finalización de la intervención, no día de introducción en la aplicación” resuelve una ambigüedad real.

El contenido mínimo del acuerdo

Para cada campo crítico, define el nombre, el significado, la procedencia autorizada y la condición que lo hace aceptable. Para el conjunto, define qué representa un registro, qué lo identifica y qué población debería estar incluida. Añade la versión de las reglas y la persona que puede aprobar cambios.

Proceso: propuesta de revisión de equipos
Unidad: un equipo activo vinculado a un contrato vigente
Identidad: sistema de origen + identificador estable del equipo
Fecha de referencia: fecha efectiva de la última revisión completada
Periodicidad: regla del contrato, con unidad explícita
Resultado permitido: propuesta interna; no confirmación al cliente
Dato crítico ausente: pendiente de revisión, sin propuesta automática
Versión de reglas: revisión-1

Este ejemplo es una propuesta didáctica. Cada empresa debe ajustarlo a sus objetos y responsabilidades; no es un estándar que deba copiarse literalmente.

Incluir también lo que no se garantiza

Una fuente puede no contener bajas anteriores a una migración o puede actualizarse solo al cierre de la jornada. Esas limitaciones forman parte del contrato. Ocultarlas obliga al consumidor a descubrirlas mediante errores.

Conviene distinguir validez estructural y aceptación operativa. Que exista una columna llamada cliente_id no demuestra que su valor se corresponda con un cliente vigente ni que la relación con el equipo siga activa.

El contrato debe servir para diseñar pruebas y para resolver discrepancias. Si una regla no puede explicarse con un caso válido, uno inválido y la acción esperada, todavía necesita precisión. Para distribuir las decisiones sin ambigüedad, puede apoyarse en propietarios y responsables de los datos.

Elegir controles según el riesgo y el momento del proceso

No todas las reglas deben ejecutarse en el mismo lugar. Algunas protegen la captura; otras comprueban que una importación está completa; otras deben repetirse inmediatamente antes de una acción porque la realidad puede haber cambiado.

Una distribución útil consiste en revisar la identidad al recibir el registro, la coherencia al preparar la decisión y la vigencia antes de ejecutar. Con ello se evita pensar que un dato validado una vez permanece autorizado indefinidamente.

Una advertencia no debe comportarse como un bloqueo si no protege una condición necesaria. Exigir una descripción perfecta puede detener trabajo válido. En cambio, una identidad dudosa no debería degradarse a simple aviso para que el flujo parezca más productivo.

También importa la unidad del bloqueo. Un error aislado puede permitir continuar con otros equipos independientes; una regla de periodicidad mal interpretada afecta a todos los casos y exige detener el flujo completo. Esta diferencia debe decidirse de antemano.

La revisión previa del diseño general del proceso se desarrolla en cómo evitar automatizar procesos mal diseñados. Aquí la decisión concreta es qué entradas pueden avanzar y cuáles deben quedar aisladas.

Corregir la captura y no limitarse a reparar exportaciones

Una exportación limpia no protege el siguiente lote si la aplicación de origen sigue admitiendo los mismos errores. Conviene investigar cómo nace cada defecto: campo libre donde se necesita una referencia, opción poco clara, importación que pierde ceros iniciales o usuario obligado a inventar valores para poder guardar.

Si los números de equipo son identificadores y no cantidades, deben conservar su representación. Convertir 00073 en 73 puede destruir una clave. La mejora no es volver a añadir ceros en cada informe, sino asegurar que la captura y el intercambio respeten la identidad acordada.

Validar donde se pueda impedir el error

Un formulario puede pedir datos mínimos; la aplicación puede limitar transiciones de estado; la base de datos puede imponer ciertas restricciones. Estas capas no son intercambiables. Una lista desplegable mejora la entrada manual, pero no controla necesariamente una importación que elude el formulario.

En PostgreSQL, una restricción CHECK se considera satisfecha si la expresión produce verdadero o nulo. Por tanto, CHECK (periodicidad_meses > 0) no impide por sí sola que falte el valor; para exigirlo se necesita además una restricción de no nulidad. La documentación oficial de restricciones explica esta distinción. Es un ejemplo de por qué una regla funcional debe traducirse y probarse técnicamente, no solo escribirse.

No conviertas cada campo en obligatorio. Primero permite registrar el caso incompleto en un estado que no habilite acciones posteriores. Obligar a introducir cualquier valor para guardar una solicitud puede mejorar la apariencia de completitud a costa de empeorar la veracidad.

Cuando la fuente es externa y no puedes modificarla, sitúa una validación en la frontera de entrada. Registra el defecto y comunica ejemplos concretos al proveedor de datos. No cambies silenciosamente el significado para que la importación termine sin errores.

Normalizar sin inventar hechos ni borrar diferencias importantes

Normalizar representaciones y corregir hechos son actividades distintas. Eliminar espacios de un código conforme a una convención documentada puede ser una transformación mecánica. Elegir cuál de dos direcciones representa la ubicación actual de un equipo exige evidencia.

Trabaja sobre una copia o una zona de preparación y conserva la relación con el valor recibido. Si la transformación resulta incorrecta, debe poder reconstruirse qué se cambió y qué registros se vieron afectados. La reversibilidad importa especialmente en modificaciones masivas.

Dar significado a las ausencias

Una fecha de revisión vacía puede significar que el equipo nunca se revisó, que el histórico no se importó o que alguien olvidó registrar la intervención. Esas situaciones no conducen a la misma acción. Sustituir todas por la fecha de alta produce un calendario ordenado, pero inventado.

Cuando la diferencia influya en el proceso, conserva un estado de información como “sin intervención previa confirmada”, “histórico pendiente” o “dato por verificar”. No hace falta añadir una categoría a cada columna: basta con representar las incertidumbres que cambian decisiones.

Separar anomalía y error confirmado

Una intervención muy antigua puede ser correcta. Una periodicidad excepcional puede responder a un contrato especial. Las reglas de plausibilidad deben seleccionar casos para revisión, no reescribirlos para acercarlos al promedio.

Las fechas ambiguas tampoco deben interpretarse según la configuración casual de un ordenador. Antes de transformar un valor como 04/05/2026, confirma el convenio de origen. Cuando no pueda confirmarse, marca la incertidumbre; una conversión técnicamente aceptada no demuestra que se haya entendido el día correcto.

El procedimiento general de limpieza de datos empresariales puede servir como apoyo. Para automatizar, añade una decisión más: qué transformaciones son suficientemente seguras para repetirse sin revisión y cuáles deben mantenerse supervisadas.

Controlar identidad, actualidad y cambios entre la validación y la acción

Dos fichas parecidas no son necesariamente el mismo objeto. Dos equipos del mismo modelo pueden compartir descripción y pertenecer a un mismo cliente. La automatización necesita una identidad estable, no una semejanza textual que parezca convincente.

Cuando intervienen varias aplicaciones, conserva la correspondencia entre sus identificadores. El número 418 de una herramienta no identifica necesariamente al mismo cliente que el número 418 de otra. La fuente forma parte de la identidad mientras no exista una correspondencia validada.

El artículo sobre prevención de duplicados entre aplicaciones desarrolla ese gobierno. En la preparación del flujo, lo importante es convertir una coincidencia dudosa en un bloqueo de la acción, no en una fusión automática.

La información correcta también caduca

Una ficha validada el lunes puede dejar de ser adecuada el martes si el equipo se traslada. Define qué cambios invalidan una propuesta y qué datos deben consultarse nuevamente antes de ejecutarla. No todos necesitan actualización en tiempo real: depende de lo que el proceso promete hacer.

Separa fecha del evento, fecha de registro y fecha de extracción. La primera explica cuándo ocurrió algo; la segunda, cuándo lo conoció el sistema; la tercera, qué fotografía recibió la automatización. Utilizar una sola marca temporal para las tres preguntas oculta retrasos.

También debe existir un comportamiento cuando cambia el dato entre comprobación y ejecución. Puede consistir en verificar una versión, repetir una consulta autorizada o devolver la propuesta a revisión. La solución concreta depende de las capacidades del sistema, pero el riesgo debe reconocerse antes de construirlo.

Finalmente, una entrada repetida no debe confundirse con un hecho nuevo. La calidad del registro y la seguridad del reintento son controles diferentes: el primero valida la información; el segundo evita repetir una acción ya realizada.

Diseñar una cola de excepciones que no se convierta en un almacén olvidado

Aislar registros defectuosos permite avanzar con los casos válidos, pero solo funciona si alguien puede resolver lo apartado. Una carpeta llamada “errores” sin responsable ni seguimiento no es una solución de calidad: es una forma de aplazar el problema.

Para cada caso pendiente registra el identificador, la fuente, la regla incumplida, el momento de detección y la acción detenida. Añade quién debe revisar el dato y qué evidencia permitiría liberarlo. Cuando un caso tiene varios defectos, deben permanecer relacionados con la misma entidad.

Distinguir pendiente, rechazado y fuera de alcance

Un pendiente podría convertirse en válido tras una corrección. Un rechazado incumple una condición que impide utilizarlo en ese proceso. Un caso fuera de alcance no debía participar. Mezclarlos impide saber si el sistema está mejorando o simplemente procesando una población cada vez menor.

La cola no debe modificar automáticamente los originales. La persona responsable corrige en la fuente autorizada o documenta una excepción aprobada. Después se vuelve a evaluar el registro con las reglas vigentes. Cambiar una bandera a “correcto” sin conservar el motivo debilita la revisión.

El reprocesamiento necesita protección contra efectos duplicados. Una propuesta creada antes de descubrir otro defecto no debería volver a generarse solo porque el caso reentra en el circuito. Hay que conocer el estado de la acción, además del estado del dato.

Mide la edad de los pendientes y su causa. Si todos esperan que una misma persona aclare una definición, el cuello de botella no está en el validador. Si la misma importación genera repetidamente el mismo error, la prioridad debe ser reparar ese origen.

Una buena cola también ayuda a aprender: transforma incidencias repetidas en requisitos de captura, explicaciones más claras o pruebas nuevas. Su finalidad es reducir trabajo futuro, no normalizar una limpieza manual perpetua.

Probar los datos y las decisiones antes de activar efectos reales

La prueba no debe limitarse a comprobar que el programa termina. Hay que comparar, para entradas conocidas, la acción esperada con la acción que propone el sistema. Un flujo que finaliza sin excepciones técnicas puede haber tomado decisiones incorrectas en todos los casos.

Empieza en modo de simulación: el sistema calcula y registra propuestas sin enviar comunicaciones ni cambiar estados operativos. La simulación debe impedir realmente esos efectos, no depender de que el operador recuerde omitir un botón.

Introduce también errores deliberados en datos de prueba: una categoría desconocida, una clave inexistente o una revisión anulada. Es tan importante comprobar que el sistema acepta lo correcto como que rechaza lo que no puede interpretar.

No existe un número universal de pruebas suficiente. Busca cobertura de las reglas, de sus límites y de las excepciones conocidas. Cuando cambie una regla, repite los casos afectados y conserva la versión probada.

Caso práctico: preparar 200 equipos para propuestas de revisión

Consideremos un ejemplo completamente hipotético. Un pequeño servicio de mantenimiento define un conjunto de 200 equipos activos para evaluar si necesitan una propuesta de revisión. El objetivo inicial es generar borradores internos; la confirmación de visitas seguirá siendo humana.

Diagnóstico inicial

La revisión identifica 18 equipos con fecha de intervención ambigua, 10 con contrato sin correspondencia confirmada y 8 con posible duplicidad. En este ejemplo, los grupos no se solapan: son 36 equipos diferentes. Los otros 164 cumplen las reglas mínimas de entrada.

Esto no significa que el 82 % de toda la base de datos sea correcto. Significa que 164 de los 200 equipos del perímetro son elegibles con las comprobaciones definidas. Tampoco significa que deban generarse 164 visitas: después hay que aplicar la regla de vencimiento.

Corrección focalizada

El responsable contrasta las 18 fechas con partes de intervención y resuelve 12; los otros 6 siguen pendientes. Confirma la correspondencia contractual de 7 equipos y deja 3 en revisión. En los 8 casos de posible duplicidad determina que 5 son equipos distintos con descripciones parecidas; los otros 3 necesitan investigación.

Ahora existen 188 equipos con entradas aceptables y 12 pendientes. Ninguna fila se ha eliminado para mejorar la cifra. Las correcciones confirmadas se han aplicado en las fuentes correspondientes y se conserva evidencia de la revisión.

Aplicación de la regla de negocio

De los 188 elegibles, 70 tienen revisión vencida según su periodicidad; 118 todavía no la necesitan. La simulación debe producir 70 propuestas internas y ningún efecto para los 12 pendientes. Es una distinción importante: calidad de entrada, elegibilidad temporal y ejecución son resultados distintos.

Una segunda ejecución sobre la misma fotografía no debe crear otras 70 propuestas. El sistema necesita reconocer cuáles ya existen. Si se corrige uno de los 12 pendientes, solo ese caso debe volver a evaluarse, sin repetir las operaciones anteriores.

Criterio de aceptación

El equipo decide habilitar únicamente la creación de borradores cuando las pruebas demuestran que las identidades ambiguas quedan bloqueadas, los reintentos se reconocen y cada equipo tiene una salida explicable. No autoriza la confirmación automática de visitas porque aún no ha probado todos los cambios de disponibilidad y contacto.

La mejora conseguida no consiste en proclamar que la base está limpia. Consiste en establecer un perímetro conocido, resolver defectos relevantes y limitar la automatización a una capacidad que ha sido contrastada. Las cifras ilustran el método; no constituyen una promesa de ahorro ni una proporción esperable en otras empresas.

Decidir cuándo avanzar sin esconder problemas detrás de un porcentaje

Una media global puede ocultar un defecto crítico. Que muchas columnas secundarias estén completas no compensa una identidad incierta en los registros sobre los que se va a actuar. La autorización debe basarse en condiciones necesarias por caso, además de indicadores de conjunto.

Como punto de partida, separa cuatro medidas: cobertura de revisión, proporción de casos elegibles, incidencias que escapan a los controles y carga de resolución manual. No significan lo mismo ni deberían combinarse sin explicar su interpretación.

Elegibilidad de entrada = casos que cumplen todas las reglas críticas / casos dentro del alcance
Pendientes de entrada = casos dentro del alcance - casos elegibles
Cobertura de resultado = casos con salida explicada / casos recibidos dentro del alcance

Estas fórmulas son una propuesta operativa para el método descrito. Si no hay casos en el denominador, informa “sin casos evaluados”; no conviertas la ausencia de actividad en un 100 % de calidad. Mantén el mismo perímetro y la misma versión de reglas cuando compares periodos.

Avanzar, limitar o detener

Puede avanzarse con una automatización acotada si los registros admitidos cumplen las condiciones críticas, las excepciones están aisladas y existe capacidad para atenderlas. La calidad global del archivo puede no ser perfecta y aun así permitir una operación segura sobre un subconjunto explícito.

Conviene limitar el resultado a sugerencias cuando falta evidencia para ejecutar. Debe detenerse el flujo si falla una condición común, como la interpretación de una unidad o la integridad de la extracción. No se resuelve un problema general bajando el umbral de aceptación.

Tras el arranque, revisa si aparecen nuevos tipos de error o si aumenta la antigüedad de los pendientes. Para separar calidad de datos, fallos técnicos y productividad del proceso, resulta útil complementar esta revisión con la medición del rendimiento de una automatización.

Convertir la preparación en una práctica mantenible

La primera versión puede centrarse en un único proceso y un conjunto reducido de reglas. El entregable no es una gran política corporativa: es una ficha de entrada, un conjunto de pruebas, una cola de excepciones y una persona que sabe cuándo detener o reanudar el flujo.

Ordena el trabajo por dependencias. Primero aclara la acción; después fija el significado y el origen de los datos; a continuación corrige los defectos repetidos; finalmente comprueba los efectos de la automatización. Empezar por programar obliga a reconstruir reglas mientras el proceso ya está funcionando.

Reserva un mecanismo de revisión cuando cambien formularios, aplicaciones, catálogos o condiciones del servicio. Un campo nuevo puede ser irrelevante; un cambio en el significado de “cerrado” puede invalidar todas las decisiones posteriores aunque el archivo conserve las mismas columnas.

La continuidad también requiere que otra persona pueda interpretar una incidencia sin recurrir a la memoria del creador. Documenta los casos límite que han producido decisiones difíciles y enlázalos con la regla correspondiente.

El aprendizaje técnico útil combina modelado de información, consultas de comprobación, comprensión de procesos y diseño de pruebas. Dominar una herramienta de automatización sin estas bases puede acelerar la ejecución, pero no permite justificar que los datos autorizan la acción realizada.

Preguntas frecuentes

Conclusión

Mejorar la calidad de los datos antes de automatizar procesos significa construir una relación verificable entre información y acción. El objetivo no es que el archivo parezca limpio, sino que cada caso admitido disponga de identidad, significado, vigencia y reglas suficientes para justificar lo que hará el sistema.

El método empieza con un perímetro pequeño y continúa con controles de entrada, correcciones en origen, tratamiento de excepciones y pruebas sin efectos reales. La decisión de avanzar depende de esas evidencias, no de una media que oculte defectos críticos.

Una automatización bien preparada también sabe no actuar. Reconoce lo que desconoce, conserva los pendientes y permite corregir sin repetir efectos. Esa capacidad de detenerse con un motivo claro forma parte del control, no es un fracaso de la automatización.