Nadie carga mal a propósito. Y sin embargo la conversación sobre errores de carga arranca casi siempre por el lado equivocado: falta de atención, gente nueva, hace falta otra capacitación. Se hace, la tasa de error baja dos semanas y después vuelve. La validación automática de datos corre el problema de lugar: en vez de pedirle a una persona que no se equivoque nunca, pone la regla en el punto de ingreso, para que el dato mal formado no pueda entrar.
La objeción es previsible: "eso lo tendría que hacer el sistema, y el nuestro no lo hace". Es cierto, y cambiar el sistema de gestión no está en los planes de nadie este año. No hace falta: las reglas, los cruces y las alertas se montan encima del sistema que la empresa ya usa. Esta guía explica cómo, y también qué no conviene automatizar.
Lo que un error de carga cuesta de verdad
El costo visible es el retrabajo: alguien lo detecta, lo corrige, listo. Es el más barato y el único que suele estar medido. Los otros tres importan más.
El primero es el tiempo hasta el descubrimiento. Un CUIT mal tipeado no molesta el día que se carga: molesta tres semanas después, cuando el caso ya pasó por análisis y hay que deshacer el camino. Cuanto más tarde aparece, más caro sale, y la curva no es lineal. El segundo es el costo de reputación operativa: cada error que llega al cliente final o a un organismo genera un reclamo, y los reclamos consumen tiempo de gente más senior que la que cargó el dato. El tercero es el más silencioso: la desconfianza en el dato agregado. Cuando el equipo sabe que la base tiene errores, deja de mirar los reportes y vuelve a las planillas propias.
De dónde salen los errores, en orden de frecuencia
Antes de automatizar un control conviene mirar los errores reales de un mes y clasificarlos. En entidades financieras, SGRs y planes de ahorro el patrón se repite.
El grupo más numeroso son los campos libres donde debería haber una lista: rubro, tipo de garantía, motivo de rechazo, provincia. Si el campo es de texto, en seis meses hay once formas de escribir lo mismo y ningún reporte cierra. Después vienen los errores de transcripción: alguien lee un estatuto, un balance o un DNI y lo pasa a mano al sistema. Ahí el error es de tipeo y no de criterio, y es justo la tarea donde la lectura automatizada rinde —lo tratamos en la guía sobre validación documental con OCR en Argentina.
El tercer grupo es la doble carga: el mismo dato se ingresa en dos lugares —el sistema y una planilla, o dos módulos que no se hablan— y tarde o temprano difieren. El cuarto son las reglas de negocio que viven en la cabeza de una persona: el analista con diez años sabe que si el plazo pasa de tal límite hay que pedir una garantía adicional, pero eso no está escrito en ningún lado. Ese último grupo es el más caro y el más subestimado, porque no parece un error de carga: parece un criterio distinto.
Validación automática de datos: qué se valida y en qué momento
La segunda decisión, después de saber qué falla, es cuándo intervenir. Hay tres momentos y sirven para cosas distintas.
Al ingreso, bloqueando. Es la validación más efectiva y hay que reservarla para lo que es inequívocamente un error: un CUIT que no cumple el dígito verificador, una fecha de vencimiento anterior a la de emisión, un campo obligatorio vacío. Si el dato no puede ser correcto, no tiene sentido dejarlo pasar.
Al ingreso, avisando. Para lo sospechoso pero posible: un monto tres veces mayor al promedio de ese tipo de operación, un domicilio que no coincide con la provincia declarada. Bloquear ahí sería peor que el error porque frena casos legítimos; el aviso deja la decisión en la persona y registra que se vio.
Después, por barrido. Corre sobre lo ya cargado, todas las noches o cada vez que entra un lote, y busca inconsistencias que solo se ven mirando el conjunto: duplicados, casos huérfanos, estados imposibles. Es el que permite empezar a validar sin tocar nada de la pantalla de carga.
Una regla que se puede saltear "por esta vez" no es una regla: es una sugerencia. Antes de definir un control, decidí si es bloqueante o informativo y bancá esa decisión. La mezcla —bloqueante en el papel, salteable en la práctica— es lo que enseña al equipo a ignorar todos los avisos, incluidos los que importan.
Controles cruzados: cuando el dato tiene que coincidir con otro
Las reglas de formato atajan lo grosero. Lo que baja la tasa de error en serio es el cruce: comparar el dato cargado contra otra fuente que ya lo tiene. Hay tres tipos que cubren casi todo.
El cruce contra una fuente externa confirma identidad y situación: padrones, registros públicos, listados de control. El cruce contra el documento respaldatorio compara lo cargado con lo que dice el papel —montos, plazos, razón social— y es el que hace defendible un legajo ante una auditoría. Y el cruce interno de consistencia compara campos entre sí dentro del mismo caso: que la suma de las cuotas dé el total, que el titular del pago sea el del contrato, que la garantía cubra el monto aprobado.
Ese último es la regla que vivía en la cabeza del analista senior, y escribirla como control tiene un beneficio extra: obliga a explicitar el criterio. Definir la validación suele revelar que dos áreas venían aplicando reglas distintas sin saberlo.
Alertas: avisarle al que puede resolver
Una alerta que llega a quien no puede hacer nada con ella es ruido, y el ruido se aprende a ignorar rápido. El criterio es simple: cada alerta necesita un destinatario que pueda resolverla y una acción concreta.
Eso significa separar tres flujos. Lo que el operador puede corregir se le muestra a él, en el momento. Lo que necesita una definición del cliente —una excepción, una autorización, un dato que el equipo tercerizado no tiene— va a una bandeja con su plazo, y pasa a ser parte de lo que hay que poder ver en un tablero, como planteamos en la guía sobre qué tenés que poder ver de tu operación tercerizada. Y lo que es tendencia y no caso —subió la tasa de rechazo de un tipo de operación— va a la revisión semanal: no se resuelve corrigiendo un registro sino cambiando el proceso.
Cómo se monta encima del sistema que ya tenés
Acá está la parte que suena difícil y no lo es tanto. No hablamos de modificar el sistema de gestión del cliente: hablamos de agregar una capa que valida antes o después de él, dejando el sistema como registro definitivo.
Cuando el sistema expone una API, las reglas corren contra ella. Cuando no —y con sistemas de veinte años es lo habitual— hay tres caminos: un formulario de ingreso propio que valida y recién después escribe en el sistema, un control que corre sobre las exportaciones periódicas y devuelve un listado de casos a revisar, o una capa intermedia que concentra la validación sin tocar el core. El criterio para elegir es el mismo que usamos para integrar un BPO a los sistemas del cliente sin romper procesos.
La restricción de diseño no se negocia: nada de doble carga. Si para que la validación funcione alguien tiene que copiar datos a otra pantalla, el control genera el mismo problema que vino a resolver.
Qué no se automatiza
Vale decirlo con la misma claridad. La validación automática detecta lo que se puede definir como regla; no reemplaza el criterio. Si un balance es razonable, cómo se lee una excepción atípica, si un caso en el borde se aprueba o se rechaza: eso sigue siendo humano, y pretender lo contrario es la forma más rápida de automatizar un error.
Tampoco reemplaza el muestreo. Las reglas cubren lo previsible; el control de calidad sobre procesos tercerizados encuentra lo que a nadie se le ocurrió validar y dice si las reglas siguen teniendo sentido después de que el proceso cambió. Un set de validaciones que nadie revisó en un año empieza a rechazar casos buenos y a dejar pasar los malos.
Cómo se financia: no se cotiza aparte
Planteado como proyecto —relevamiento, especificación, desarrollo, licencias— el número queda en una carpeta esperando el presupuesto del año que viene. Es lo que le pasa a casi toda mejora de proceso: se posterga no porque no convenga, sino porque es un proyecto.
Nosotros lo tomamos al revés. Las reglas de validación, los cruces y las alertas los construimos sobre la operación que estamos corriendo y están incluidos en el costo del servicio: no hay licencia que el cliente compre, no hay cotización aparte, no hay aprobación de directorio. Cuando aparece un tipo de error nuevo —y aparece, porque el negocio cambia— se agrega el control y sigue la operación. Es la misma lógica del software a medida incluido en el servicio: si el proceso lo necesita, se desarrolla.
El efecto práctico es que el cliente gana tecnología sin invertir en tecnología, y que el dato validado sigue siendo suyo: exportable, trazable y utilizable el día que decida llevarse el proceso a otro lado.
Siete preguntas antes de automatizar un control
- ¿Cuáles son los cinco errores de carga más frecuentes del último mes, con números?
- ¿Cuánto tarda hoy en descubrirse cada uno de esos errores?
- ¿Qué campos son de texto libre y deberían ser una lista cerrada?
- ¿Qué reglas de negocio no están escritas en ningún lado?
- ¿Cada control va a bloquear o va a avisar, y quién recibe el aviso?
- ¿Alguien tiene que cargar algo dos veces para que la validación funcione?
- ¿Los controles se desarrollan dentro del servicio o se cotizan como proyecto aparte?
La respuesta a la primera suele ser "no lo tengo medido", y ese ya es el primer hallazgo: no se puede bajar una tasa de error que no se conoce. La línea de base es parte del trabajo y conviene armarla antes de tocar nada.
En éxodo bpo las validaciones no son un módulo aparte: son parte de cómo operamos. Se construyen sobre el proceso del cliente con las herramientas de desarrollo, IA y OCR que tenemos adentro de casa, se ajustan cuando el negocio cambia y se sostienen desde las operaciones a medida y el análisis de riesgo. Bajar los errores de carga no es un problema de atención: es de diseño del proceso, y se resuelve poniendo la regla donde se carga el dato.