La automatización de procesos BPO que sirve casi nunca sale de una reunión de relevamiento. Sale de un martes cualquiera, cuando alguien del equipo nota que lleva tres semanas copiando el mismo número de un mail a un sistema, o que todos los jueves hay que rehacer una planilla porque el archivo que manda el banco cambió de formato y nadie avisó. Ese hallazgo no estaba en ningún documento de alcance. Apareció operando.
Ahí está la diferencia práctica entre comprar una herramienta y contratar a alguien que opere el proceso. La herramienta se compra con la lista de funcionalidades que uno imaginó antes de empezar; el servicio se ajusta a lo que el proceso muestra cuando ya está en marcha. Esta guía explica cómo funciona eso en concreto: cómo se detecta un candidato a automatizar, qué se construye, cómo se desarrolla sin frenar la operación, qué no automatizamos y —la pregunta que siempre llega— cómo se financia.
Por qué lo que hay que automatizar no se sabe antes de empezar
Un proyecto de sistemas tradicional invierte el orden natural del conocimiento. Primero se define el alcance, después se aprueba el presupuesto, después se desarrolla y recién al final la operación se encuentra con lo que se construyó. El problema es que el alcance queda fijado en el momento de menor información disponible: todavía no se conoce el volumen real por tipo de caso, ni cuáles son las excepciones que se comen el día, ni qué proveedor manda los archivos incompletos, ni en qué paso se acumula la cola.
En una operación tercerizada el orden es el inverso. Los primeros meses se dedican a tomar el proceso, estabilizarlo y medirlo —buena parte de lo que pasa en los primeros 90 días de una implementación—, y en ese período el proceso empieza a mostrar sus propios costos. Cuando un patrón se repite lo suficiente como para ser evidente, se automatiza. No antes, porque antes es adivinar; no mucho después, porque para entonces ya lleva meses cobrando horas.
Eso explica también por qué no hay un catálogo cerrado de funcionalidades para mostrar: lo que necesita una financiera que origina préstamos no se parece a lo que necesita una SGR que arma legajos societarios.
Las señales de que un paso está pidiendo una automatización
El equipo que opera no busca oportunidades de automatización en abstracto: se topa con ellas. Con el tiempo, las señales que valen la pena se volvieron bastante estables.
Cinco señales que miramos mientras operamos
- El mismo dato tipeado dos veces. Un CUIT que se carga en el sistema, en la planilla de seguimiento y en el formulario. Cada repetición es una chance de que no coincida.
- Un control que siempre encuentra lo mismo. Si el 30% de los casos vuelve por el mismo campo mal cargado, no es un problema de atención: es una regla que falta.
- Espera pura. Tramos donde el caso no avanza porque alguien tiene que darse cuenta de que le toca. Eso se resuelve con una cola y un aviso, no con más gente.
- Retrabajo por formato. Archivos que llegan de una manera y hay que convertirlos a mano antes de poder usarlos. Es el candidato más barato de todos.
- La excepción que dejó de serlo. El caso raro que hoy es el 20% del volumen y se sigue tratando como excepción manual.
Ninguna de esas señales aparece en un relevamiento de dos semanas: se ven operando todos los días, que es exactamente la posición donde está el equipo.
Qué se construye: cuatro tipos de desarrollo que salen de la operación
Los desarrollos que nacen de una operación en marcha se repiten en cuatro familias. Cambia el proceso, cambia el sistema del cliente, cambia el dato; la familia es siempre alguna de estas.
Integraciones y traspaso de datos. Que la información viaje sola entre el sistema del cliente, el core, el portal del proveedor y lo que el equipo usa para trabajar. Es lo que elimina el copiar y pegar, y se hace con lo que haya disponible —API, archivos, base intermedia—, sin pedirle al cliente que cambie de sistema. Está desarrollado en detalle en la guía sobre cómo integrar un BPO a tus sistemas sin romper procesos.
Reglas de validación y controles. Formatos, obligatoriedades, cruces entre campos, umbrales, duplicados. Se montan encima del sistema que ya está en uso: no hay migración ni licencia nueva. Es el enfoque de las validaciones automáticas para bajar los errores de carga, y suele ser el desarrollo con mejor relación entre esfuerzo y minutos ahorrados.
Lectura y extracción de documentos. Cuando el insumo del proceso son PDFs, escaneos o fotos, la transcripción manual es el gasto principal. Extraer los campos y proponerlos precargados para que una persona confirme convierte al operador en revisor: más rápido y con menos error que tipear. Es la validación documental con OCR e IA aplicada al proceso concreto.
Tableros e indicadores en vivo. Estado de la cola, antigüedad, productividad, retrabajo, cumplimiento de plazos. No se arma como proyecto de BI: se construye sobre la traza que la operación ya genera y queda a la vista del cliente. Es lo que tenés que poder ver de tu operación tercerizada sin depender de un reporte mensual que llega tarde.
Hay una quinta categoría menos vistosa y muy frecuente: herramientas internas chicas —una pantalla con la cola priorizada, un generador de documentos, un checklist que no deja cerrar un caso incompleto—. No impresionan en una presentación, pero son las que devuelven horas.
Cómo se desarrolla sobre un proceso en marcha
La parte delicada no es construir: es construir sin frenar lo que ya está funcionando. El ciclo que usamos tiene cinco pasos y está pensado para eso.
Uno: se documenta el caso real, con números. Cuántas veces por semana pasa, cuántos minutos consume, qué error produce. Sin ese dato no se prioriza nada, porque toda molestia parece urgente cuando la sufrís.
Dos: se construye chico. La primera versión resuelve el caso principal, no los quince derivados. Sale en días, no en meses, y por eso se puede corregir sin drama si el supuesto estaba mal.
Tres: corre en paralelo al método manual. Durante un tiempo conviven los dos y se comparan resultados. Si difieren, gana el manual y se ajusta el desarrollo. La operación nunca queda expuesta a algo nuevo sin red.
Cuatro: se mide contra la línea de base. Minutos por caso, tasa de error, casos que avanzan sin intervención. Si no mueve ninguno de los tres, se descarta sin ceremonia.
Cinco: queda documentado y monitoreado. Una automatización sin dueño se rompe en silencio el día que cambia un formato. Se le pone alerta y se revisa como parte del control de calidad sobre el proceso tercerizado.
Nada se automatiza sobre un proceso que todavía no está estabilizado: si el circuito cambia todas las semanas, automatizarlo es fijar en código una forma de trabajar que va a durar quince días. Primero se ordena, después se mide, recién ahí se construye.
Qué no automatizamos
Decirlo importa tanto como lo otro, porque el mercado está lleno de promesas que no se sostienen.
No se automatiza el criterio. La decisión crediticia, la evaluación de un caso dudoso, la interpretación de una situación que no encaja en ninguna categoría: eso lo hace una persona, y en general una persona con experiencia. Lo que sí se hace es sacarle de encima todo lo que la distraía, para que llegue al caso con la información ordenada y completa.
No se automatiza lo que pasa poco y cuesta poco. Un trámite excepcional que aparece dos veces al mes no justifica un desarrollo ni el mantenimiento que arrastra después.
No se automatiza lo que nadie puede explicar. Si el proceso vive en la cabeza de dos personas y cada una lo cuenta distinto, primero hay que definirlo. Automatizar sobre una definición ambigua no ahorra tiempo: hace el error más rápido y más difícil de ver.
Por qué no llega una cotización aparte
Acá está el punto que más nos preguntan, y es el que distingue al modelo. Todo lo anterior, presentado como proyecto de sistemas, tendría relevamiento, presupuesto, licencias, un cronograma y una aprobación de directorio. Por eso las mejoras obvias se postergan durante años: no porque no convengan, sino porque cada una es un expediente.
Nosotros no vendemos un sistema, vendemos el servicio de operar el proceso. Lo que ese proceso necesita para funcionar mejor lo construimos nosotros y está incluido en el costo del servicio: sin licencia que el cliente compre, sin cotización por desarrollo, sin proyecto que justificar. El incentivo, además, está alineado: cada automatización nos hace más eficientes a nosotros y le baja el error al cliente. Es la lógica del software a medida incluido en el servicio, y el resultado es que el cliente gana tecnología sin invertir en tecnología.
Y la contracara, que es la que hace creíble todo lo demás: el dato es del cliente. Lo que construimos opera sobre su información, la trazabilidad es exportable en cualquier momento y si algún día se lleva el proceso a otro lado, se lo lleva con su historia. Sin lock-in y sin sorpresas en la salida.
Cómo saber si valió la pena
Una automatización que no se mide es una anécdota. Cuatro números alcanzan, y conviene tenerlos antes de construir para poder comparar después.
Los cuatro números de cada automatización
- Minutos por caso antes y después, sobre el mismo tipo de caso.
- Tasa de error o retrabajo en el paso intervenido.
- Porcentaje de casos que pasan sin intervención humana, que muestra cuánto sigue siendo manual.
- Tiempo de espera del caso en ese tramo, que suele mejorar más que el tiempo de trabajo efectivo.
Si los cuatro se mueven poco, la automatización estaba mal elegida y hay que decirlo. Es preferible descartar un desarrollo de dos semanas que sostener para siempre una herramienta que nadie usa.
Por dónde empezar
No hace falta una iniciativa de transformación digital para arrancar. Alcanza con una pregunta concreta hecha a quien opera todos los días: ¿qué parte de tu trabajo hacés a mano sabiendo que una máquina lo haría igual? La respuesta suele estar lista hace rato, y casi nunca es la que aparece en un relevamiento formal.
En éxodo bpo tomamos el proceso completo con equipos dedicados desde operaciones a medida, con la verificación y los controles documentales a cargo de análisis de riesgo, y construimos lo que la operación vaya pidiendo con el equipo de desarrollo, OCR e IA que tenemos adentro de casa. No hay catálogo: hay un proceso que se opera y un equipo que lo mejora mientras lo opera. Si es un problema de proceso, lo podemos resolver.